Re: New version of SMTP/TLS

On Wed, 5 Nov 1997, Paul Hoffman / IMC wrote:
> I like your wording, but it doesn't get all of what I had. As a different
> replacement, I suggest:
> 
> A publicly referenced SMTP server MUST NOT require use of the STARTTLS
> extension in order to deliver mail locally. This rule prevents this
> extension from damaging the interoperability of the Internet's SMTP
> infrastructure. Any SMTP server MAY refuse to accept messages for
> relay based on authentication supplied during the TLS negotiation. An SMTP
> server that is not publicly referenced MAY refuse to accept any messages for
> relay or local delivery based on authentication supplied during the TLS
> negotiation.

I'm not sure the last sentence is necessary.  It's implicitly permitted by
the first sentence, but I'm not sure it's a good idea to encourage it by
stating it explicitly.  But I could live with this wording.

> An SMTP client can protect against this attack by recording the fact that a
> particular SMTP server offers TLS during one session and generating an alarm
> if it does not appear in the EHLO response for a later session. The lack of
> TLS during a session SHOULD NOT result in the bouncing of email, although
> it could result in delayed processing.

Sounds good to me.

> Again, I disagree. SMTP/TLS is suitable for authenticated delivery of email.

I disagree.  There's no way to know what authentication identity was used
by the initial submittor.  Therefore the final receipient only knows
whether or not the last hop was authenticated.  The SMTP AUTH extension,
on the other hand, does provide for an authentication identity parameter
on MAIL FROM.  This means there is an authentication identity associated
with the message on final delivery, thus one can know who it really came
from.  SMTP/TLS doesn't allow a distinction between last hop 
authentication and valid authentication at every hop.

Now this may be simply that we had different ideas of what "authenticated
delivery" means.  To me it means that I know it came from a specific user,
matches site/inter-site policy and thus is suitable for use with things
like the post ("p") ACL bit in the IMAP ACL extension.

		- Chris