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
example.com. IN MX 10 A.EXAMPLE.COM.
IN MX 10 B.EXAMPLE.COM.
A supports XYZ and B does not.
Now, suppose D.example.net 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
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp