RE: e2e

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> Robust for what? Spammers? The simple fact of the matter is 
> that the alternative is to just shut down port 25 given the 
> growth in both volume and complexity to filter.

Finally, a sensible solution!

After all, why should any mail server operator accept incoming email
from another server without a prior mail peering agreement in place? The
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? 

RFC 4409 split off the submission stream from the relay stream,
therefore one can reasonably assume that most of the non-spam port 25
traffic is relay. Some of that is customers of an ISP, who therefore
have an implicit or explicit mail peering agreement, relaying through
the ISP's mailserver. And some of it is anonymous relays delivering
messages to what appears to be the final destination.

If we get rid of the anonymity for relays delivering to final
destination, i.e. gmail.com sending a message for example@xxxxxxx 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. 

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?

Is there an informational RFC that describes the overall email
architecture that is provided by the various IETF protocols? Such a
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. 

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.

--Michael Dillon



_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]