Hi, John,
On 11-01-16 02:49, John C Klensin wrote:
--On Sunday, January 10, 2016 14:27 -0800 Jim Fenton
<fenton(_at_)bluepopcorn(_dot_)net> wrote:
Below is the announcement of a draft I just submitted that may
be of interest to this list. The approach here is
complementary to the other proposals I have seen along these
lines (e.g., smtp-sts).
Thoughts, reviews, etc. welcomed.
Jim,
I have skimmed through this. A few observations, many of which
apply to most or all of the "other proposals along these lines"
that you mention.
(1) I appreciate the last paragraph of your Security
Considerations section. We need to keep in mind that there are
multiple threat models to mail privacy/confidentiality and that,
if mail servers can be compromised, encryption in transit may
not add much value (or may add a false sense of security). As
you point out, certain DNS compromises may not be much better.
(2) The issue of encrypting information on the reverse path (not
just error messages, but delivery and non-delivery notifications
of all types) is a difficult one. Although it is likely in the
common cases, there is no way to guarantee from the presence of
encryption capability on the forward path that encryption on the
reverse path will be supported (and properly configured, etc.)
In particular, if the preferred MX-based route between A and D
is A->B->C->D, nothing at all guarantees that the route from D
to A will go through B and C. In a way, part of this is not
new: A doesn't have to operate an SMTP-receiver in order to send
messages to D, but it certainly needs to have one to receive
error messages (as distinct from SMTP-time rejections).
Even if you decide against it, I think you need to consider that
situation carefully and, in particular, consider whether
parameters that allow the message originator to specify levels
of preference about what should happen if notification messages
cannot be encrypted.
(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.
Isn't this a generic problem when MX hosts for a domain provide
different 'levels of service'? I mean: if MX host A advertises a SIZE of
10 Mbyte and MX host B advertises a SIZE of 15 Mbyte, a message of 12
Mbyte may reach or not reach the destination, dependent on which MX host
is used to transfer the message.
And to a lesser extent, the difference in 'service' applies for support
of DSN and other extensions as well. Isn't it primarily the
responsibility of the domain owner to use MX hosts with equal
characteristics? Granted, the Sender may experience inconsistent
behaviour when the Receiver chooses to use MX hosts with different
characteristics, but the question is: do we have to take this into
account when designing (new) protocols? I think the answer is 'yes, but
to what extent'?
/rolf
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp