Dave Crocker <dhc(_at_)dcrocker(_dot_)net> wrote:
It is one more nail into something, yes. But there has not yet been any
detailed description of what it accomplishes that is useful. It adds
overhead, but no one has yet stated what it enables that is useful in
the prevention, detection, or handling of spam.
Which leaves out the previously stated utility of the proposal:
tracing and accounting.
Once more spam is traceable and accountable (where RMX may help), we
can apply other methods to prevent/detect/handle spam (where RMX
may not help.)
when you add mechanism, you make things worse -- more complicated and
more effort. this is only acceptable when you are also making things
significantly better. so far, no one has provided a clear and compelling
case in favor of using rmx for anything that will prevent or reduce
spam.
RMX is a low-cost mechanism for both the sender and receiver, so any
requirements on it "making things significantly better" are similarly
expected to be low.
so the benefit is post-hoc filtering of spam that has previously
purported to be from a particular host and continues to falsely claim to
be from that host?
That's one benefit, yes.
unfortunately, spammers will work around that block within hours. they
are very clever and adaptable. so you will have spent a great deal of
time and energy to create a mechanism that will prevent spammers for,
perhaps, a few days. total.
I'm not sure why RMX would be "a great deal of time and energy" to
implement.
As for utility, let's suppose that all spammers implement RMX on
their originating MTA's. In addition to Hadmut's recent comments,
this has other benefits for the recipient:
- we can now blacklist by domain, in addition to IP.
There are fewer domains than IP's, by probably 2 orders of
magnitude.
- the spammers choice of originating IP will be more limited,
which decreases the work required for IP blacklists.
(A newly discovered open relay which is added to a spammers DNS
as RMX will take more time to fully propogate throughout the net
than TCP connections from that relay)
RMX can help moderate the work required to deal with spam, and can
help to slow down the rate of sending spam.
there are some other drafts floating that also do as you suggest. have
you read them yet? what about them is insufficient?
Some. I don't have specific objections right now, otherwise I would
have said something.
As for your draft, I think it's very good. But it's much looser on
the requirements for proposed solutions than the discussions on this
list have been. So until the draft becomes more restrictive on the
requirements, I'm left addressing opposition/requirements on the list,
and not in the draft.
AD> I agree. But most of the opposition to change I've seen doesn't
AD> appear stem for history lessons.
you must be reading different mail than I.
<shrug> The messages don't quote history, and say "we tried this in
1998, and that doesn't work for reasons given <here>." Instead, the
messages say things like "It takes significant time before protocols
are widely adopted."
For some protocols, yes. For others, no. See:
http://www.freeradius.org/rfc/radius-minutes-95apr.txt
RADIUS was designed and originally implemented around 1993. By
1998, it had acheived wide-spread adoption. Similar things may be
said for HTTP. Sub-decade widespread adoption of new protocols is the
reality of the net, given:
Incentive: high.
Implementation cost: low.
We're now at the point where we have high incentive to fight spam.
If there's a low-cost solution which will help recipient MTA's, then
my prediction is that it will achieve wide-spread adoption within 3
years. That is, at least 30% of sites will use it. (By number of
users, not domains, as there are millions of domain squatters.)
That's a testable prediction. If I'm wrong, then 3 years from now,
I'll buy people a beer (or other beverage) at IETF. If I'm right,
then I ask that people predicting otherwise buy *me* a beverage.
Until then, it's all "he said, she said" for whether or not any
proposal will achieve wide-spread acceptance.
The original assertion was that there were alternatives to SMTP, not
simply alternatives to "naked, unaccountable SMTP".
AD> Not at all. Or, at least, not from me:
SMTP is only one of many protocols used to send/receive email.
Again, you've snipped the previous sentence, which gives additional
context.
I can't help your misunderstanding what I say, if you insist on
taking things out of context.
SMTP over VPN is SMTP. Hence it is not "only one of many protocols used
to send/receive email". It is SMTP.
Wonderful. So you have no opposition to a BCP document which says
that mobile users SHOULD use SMTP over VPN's to their home domains,
and SHOULD NOT send SMTP traffic directly to the final recipient.
As I've tried to explain in many messages, I don't oppose all of
SMTP design, implementation, or practice. In the context of mobile
users, I oppose some current practices involving SMTP, and believe
that there are viable alternative to those practices. But I've never
claimed that we should throw away SMTP entirely.
Alan DeKok.
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg