Alan,
AD> I agree, but it does mean that we can account for whether or not the
AD> originator is conforming to good policies. It's just one more nail in
AD> the coffin of spammers.
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.
In any event, the remaining pool consists of good guys and bad guys and
we are not in a better position to distinguish them.
AD> I agree, but for that pool, we're no worse off than we were before.
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.
Why? What makes it likely or certain that someone coming through an RMX
host is not sending spam?
AD> Nothing. But having proven to be a spammer, it's easier to hold
AD> them to account, and to block/filter their traffic.
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?
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.
AD> At the minimum, RMX will alleviate the need for DUL blocks. RMX can
AD> alleviate the "forged sender" problem,
no it will not. not until the entire internet uses it, and that will
not occur for a very long time.
You are confusing "be very careful with the design of changes and the
assumptions about their adoption" with "do not make any changes."
AD> That's probably because ANY change which is proposed gets responses
AD> like:
AD> "That feature is a design requirement of the protocol."
AD> Such responses are, quite frankly, idiotic. If NONE of the proposed
AD> changes are acceptable, then why are we wasting our time talking about
AD> trying to fix the problem?
If you need to cook some food and you propose to hold the food in your
hand while it is cooking, do not blame the person who observes that
there is a basic, serious problem with your approach.
look for a better approach.
AD> Why can't the people shooting down the proposed changes come up with
AD> a list of requirements that the changes must satisfy?
please read the internet draft I submitted last week.
there are some other drafts floating that also do as you suggest. have
you read them yet? what about them is insufficient?
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.
2. Ugly and awkward are usually terms that apply to failed proposals.
AD> Like IPSec. It's ugly, awkward, but it appears to currently be the
AD> best of ugly and awkward alternatives.
actually, there is frequently a stronger case for TLS, when needing
connection-based privacy and authentication.
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.
Apparently we read your original statement very differently. I cannot
guess how you interpret it as meaning anything other than claiming there
are alternatives to SMTP. (And we can ignore the error in claiming that
SMTP is used to receive mail, although it is only used to send it.)
So far, no protocol other than SMTP has been citing for sending email,
other than a couple of ancient protocols that long-ago failed to be
enhanced and failed to be widely adopted.
I believe no one else selling and email protocol other than SMTP and making a
living at it.
AD> My claim was for SMTP over VPN.
SMTP over VPN is SMTP. Hence it is not "only one of many protocols used
to send/receive email". It is SMTP.
d/
--
Dave Crocker <mailto:dcrocker(_at_)brandenburg(_dot_)com>
Brandenburg InternetWorking <http://www.brandenburg.com>
Sunnyvale, CA USA <tel:+1.408.246.8253>, <fax:+1.866.358.5301>
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg