----- Original Message -----
From: "Keith Moore" <moore(_at_)cs(_dot_)utk(_dot_)edu>
From my standpoint 2476 "legalized" the strong authentication
requirement
that removed all user privacy rights.
I believe this needs to be revisited, as the ability to send anonymous
mail is socially valuable. Recipients need to be able to block
anonymous mail if they wish to do so, but the MTS should not block it
for them.
Would it be useful to define what "anonymous" means? How much
accountability applies? How much tracing is enough? It is verifible?
But if ESMTP AUTH or IP relay checking is enforced for ISP
users, then port 587 is a mute point.
No it's not, first because source IP address checking and many forms of
SMTP AUTH are broken for reasons mentioned earlier;
second because it's not reasonable to assume that either all
transactions from a particular IP address are submissions or all of
them are relays. Submission is (or should be) a different operation than
relaying in many respects, and it's important that there be a clear
indication of which operation is being requested.
I agree, took me a while to put all the tangents in context to see what you
mean. :-)
I guess I can only speak for how our server is design and how it fits and
works with other standard mail servers.
Usually this is determined at the RCPT TO state. I mean the RCPT TO state
usually defines the personality of the receiving MTA server (RMTA) and the
level of security required.
My point above regarding Port 587 was in regards to "allowing" routing, you
typically have a implicit or explicit set of rules or requirements. If a
route requirement is already satisfied than the implicity port 587 usage is
a mute point.
In my view, at the top level, ESMTP AUTH vs 2476 is basically a "Explicit
vs. Implicit" authorization concept similar to FTP Implicit and Explicit
SSL.
Implicit uses a specific port with an implied security level defined
requirement. The MTA has no choice. Security is presumed.
Explicit uses the standard port with an optional security level defined. The
MTA has a choice to use ESMTP AUTH or not. If he doesn't, then only local
mail is allowed. The Receiver MTA is essentially a MDA.
2476 is basically implicit ESMTP AUTH. Yes, 2476 imposes other things too,
like 2822 checking and/or modification/setting concepts and I think this is
where we are at as it relates to user privacy or anonymity and also now,
possibly helping to address transition points for LMAP based protocols (SPF,
SENDERID).
In my interpretation, Implicit ESMTP AUTH (2874) legalizes the 2822
analysis and changes if necessary. Currently it removes all user privacy if
the MSA enforces Sender, etc. Explicit ESMTP AUTH does not as it only
currently uses for routing purposes.
But in both cases when it comes to routing, they both satisfy one of the
authorization requirements needed for routing.
Again, I am describing how our system is currently is designed and place to
interoperate with other similar systems. I think to think it is following
the BCP to the highest degree.
Above all, backward compatibility is paramount and when you reduce it down
to what means it to make it backward compatible it boils down to:
Local Mail --> No authorization required (the MTA is now a MDA)
Remote Mail --> Authorization required (the MTA is now a MSA)
The issues with LMAP protocols, SPF/SENDERID for the most part, these are
protocols that are designed to fit into the current model with hopefully the
highest regard to backward compatibility with the hope for the highest form
of easy adoption and acceptance.
The problem?
The transition points, the routing points where the originating IP and
originating domain association (IP::DOMAIN) is no longer intact.
The proposed solutions are:
SUBMITTER (2821)
SENDERID (2822, PAYLOAD)
SRS (2821)
SUBMITTER addresses the persistent nature of MAIL FROM so that when the mail
reaches its final destination point, the IP::DOMAIN association may not be
intact in a multi-hop path. So SUBMITTER is used as an ESMTP Mail From
keyword modifier:
MAIL FROM <address> SUBMITTER=original_address
This has a privacy problem. My change recommendation was to use only the
domain since SPF only needs the domain to validate the IP::DOMAIN
association.
SENDERID addresses the problem when the MTA is not SUBMITTER compliant and
when use the payload to check the 2822 headers for the originating address.
This is where 2476 comes into play where it could add the SENDER: header to
assist the downlink MDA SenderID ready server.
Again, this presents a privacy issue. A suggestion is to add a new header:
SENDER-DOMAIN:
for SPF lookup purposes.
and finally, SRS modifies the return path (MAIL FROM) so that it is
consistent with the IP::DOMAIN at the final destination. I don't think SRS
raises a privacy problem, but in general I don't like the idea of modifying
the MAIL FROM.
So when you put it all together, we are really still at square one because
we still need to have backward compatible explicitly support for anonymous
transactions.
The question is then, what is anonymous transactions? and what can be done
for the legacy client who may not be using any of the new stuff?
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com