Re: Welcome to the ietf-apps-tls mailing list

> >If two parties permit a given set of all types, e.g., they
> >support all three types, and the set is altered by a MIM, then the
> >selected type will probably be the strongest of the altered
> >set.
> 
> In my mind, this still fits in the category of "OK", since both sides
> decide after the handshake if they are happy with where they ended up (and
> possibly how they ended up there).
> 
> >If two parties support non-TLS connections and TLS
> >connections and the TLS keyword is nuked, then a non-TLS
> >connection may be established.
> 
> True. I'll add this to the next draft.

	This is one of the conditions that gave us problems for TLS/IMAP. There
doesn't seen to be any way out of this without prior client knowledge - or a
separate port (which isn't an option for TLS/SMTP).
	It would seem that the submission agent needs to be configured for
minimum security level. That's not a difficult problem. In the case of relays, 
it does get a bit more complicated. 
	This appears to be ripe for a RCPT To: extension which can get passed
along and provides an indication of what security level should be achieved, and
how to react if it can't. We've come from a world where SMTP does everything in
its power to get the message to the destination, but this is one place where it
would be entirely reasonable for the sender to indicate that an abort was the
only appropriate action if a secure channel could not be negotiated. This could
be linked with DSN's for reporting.

RCPT TO: <[email protected]> TLS=TLS1.0,SSL3.0,ABORT NOTIFY=FAILURE \
ORCPT=rfc822;[email protected]

	indicates we try tls1.0, then sslv3 and drop the message (with a return
DSN) if this cannot be achieved. Without the NOTIFY parameter, we just RTS.

RCPT TO: <[email protected]> TLS=TLS1.0,SSL3.0

	indicates we try tls1.0, then sslv3 but allow the delivery to continue
in any event with no reports.