Mark Baugher <mbaugher(_at_)cisco(_dot_)com> wrote:
We could extend SMTP AUTH to do MTA authentication, but it would
then end up looking like LMAP.
I believe SMTP TLS is intended for MTA authentication.
Yes, it also solves the security/privacy issue. But it's
authentication + security, not just authentication. And I don't think
many MTA's allow STARTTLS with cipher "none".
Section 5.1 of RFC 2487 says:
The decision of whether or not to believe the authenticity of the
other party in a TLS negotiation is a local matter. However, some
general rules for the decisions are:
- A SMTP client would probably only want to authenticate an SMTP
server whose server certificate has a domain name that is the
domain name that the client thought it was connecting to.
- A publicly-referenced SMTP server would probably want to accept
any certificate from an SMTP client, and would possibly want to
put distinguishing information about the certificate in the
Received header of messages that were relayed or submitted from
The second option becomes more useful if the senders certificate is
in DNS somewhere, or is signed with a well-known public key, also
visible in DNS.
Section 7 "Security Considerations" is also useful:
It should be noted that SMTP is not an end-to-end mechanism. Thus,
if an SMTP client/server pair decide to add TLS privacy, they are
not securing the transport from the originating mail user agent to
the recipient. Further, because delivery of a single piece of mail
may go between more than two SMTP servers, adding TLS privacy to
one pair of servers does not mean that the entire SMTP chain has
been made private. Further, just because an SMTP server can
authenticate an SMTP client, it does not mean that the mail from
the SMTP client was authenticated by the SMTP client when the
client received it.
Other methods can potentially extend the authentication of the
message beyond the per-hop limit of STARTTLS.
Asrg mailing list