[Top] [All Lists]

Re: [ietf-smtp] Fwd: New Version Notification for draft-fenton-smtp-require-tls-00.txt

2016-01-11 08:08:35
At 20:49 -0500 on 01/10/2016, John C Klensin wrote about Re: [ietf-smtp] Fwd: New Version Notification for draft-fen:

(3) The EAI WG struggled for a long time with the relationship
between a requirement for certain SMTP options (i.e., if the
option is requested (or required) by the client but the server
will not accept it, the message content must not be sent) and
our MX structure.  For example, suppose (to generalize, the XYY
option is at issue and required.   Suppose we have IN MX 10   A.EXAMPLE.COM.
                IN MX 10   B.EXAMPLE.COM.

A supports XYZ and B does not.

Now, suppose wants to send a message to
user(_at_)example(_dot_)com and wants to send it with transport encryption.
RFC 5321 is fairly clear that it is to pick arbitrarily between
A and B.  If it happens to select A, then all is well.   But, if
it selects B and successfully opens the SMTP connection, B will
not advertise REQUIRETLS and your spec, as I read it, then
requires that D stop, close the session, and tell the originator
that delivery was not possible.  More complex versions of that
scenario with, e.g., choices at different preferences or names
with multiple addresses but different services supported at each
address, can create even more interesting solutions, different
paths, etc.

There is another way to handle this situation that we already use for connect fails. When I try B and can not connect I can try A and if that also fails go to some MX with a higher priority value number.

In this case of B not returning XYZ, in lieu of giving up immediately, why not try A FIRST? Only when ALL the first priority MXs get rejected would we give up and bail out. I note that this may not cover the complex scenario version you reference but it can handle some simple versions such as the single setting support one.

ietf-smtp mailing list

<Prev in Thread] Current Thread [Next in Thread>