At 06:54 16-08-2007, michael(_dot_)dillon(_at_)bt(_dot_)com wrote:
After all, why should any mail server operator accept incoming email
from another server without a prior mail peering agreement in place? The
Because that is how SMTP works.
email architecture of Simple Mail Transfer Protocol is completely broken
and has been largely superceded. Why not begin to turn off services on
the problem port?
We can if we don't want to receive any mail.
If we get rid of the anonymity for relays delivering to final
destination, i.e. gmail.com sending a message for example(_at_)aol(_dot_)com to
an
aol.com mailserver, then most of the spam stream goes away. At that
point, we only have to worry about spam which subverts the submission
mechanism or some other weakness in the system.
That would be SPF.
It would also restrict you to using a Return-path which is valid for
the network from which you are sending the mail. That may not be
practical in some environments where you don't have an existing
account and you can only send mail through the local mail server (no
access to submission port on home server, e.g. outgoing TCP 587
blocked or network unreachable).
Anonymous relaying on port 25 is a known weakness. Why can't we close
this gap? Do we need a new port assignment for mail peer relaying? Do we
need to fix the SMTP-AUTH weaknesses? Do we need an upgrade to ESMTP
that is incompatible with previous SMTP versions to make a clear break
with the past?
We could require authentication on port 25. This would mean having
prior agreement before exchanging mail between servers. That was not
how SMTP was designed to be and it would mean a clear break from the past.
A start would be restricting mail exchanges to Hotmail, Yahoo and
Gmail. That may sound acceptable to some people. I am not
suggesting doing that.
Is there an informational RFC that describes the overall email
architecture that is provided by the various IETF protocols? Such a
http://tools.ietf.org/html/draft-crocker-email-arch-09
document could help frame the discussion and identify weaknesses that
need further work such as the SPF/DKIM bandaids. We have gotten to the
present situation because various people doing work on the problem have
blinders on as that focus on one narrow area of the problem. We need to
describe the totality of the situation, point out what works fine or has
already been fixed, and suggest a way forward for fixing the problems.
See http://www.irtf.org/charter?gtype=rg&group=asrg
By the way, SPAM is not the problem. The problem is anonymity and lack
of accountability. I believe that the email architecture can be fixed so
that unknown people can still email me anonymously, and I won't be able
to identify them without cooperation from my ISP, but at the same time,
if these people are abusing the system, my ISP can follow a chain of
accountability to the sender, or to the point in the chain where
bilateral trust relationships have broken. In such a scenario, I am
confident that SPAM will still exist, but I am also confident that it
will no longer be such a firehose, just a dribble. SPAM is not a problem
in the email architecture. Lack of a solid chain of accountability
formed with bilateral trust agreements is the root problem with the
email architecture.
Bilateral agreements mean a complete change of the email
landscape. Even then, I don't see how a small provider can afford
blocking a large ESP. Sure, we can make part of the spam problem go
away temporarily by giving up some of the functionality email
provides. Most people may be willing to live with the restrictions
until they experience the drawbacks first-hand.
Regards,
-sm
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf