--On Thursday, October 17, 2013 18:03 -0700 Ned Freed
<ned(_dot_)freed(_at_)mrochek(_dot_)com> wrote:
Beyond that there are a lot of isses with the draft,
including, but not limited to:
(1) The idea of sending a forward nondelivery notification to
the recipient was tried in X.400. It did not work out well
at all - for better or worse people just don't grok
notifications about messages they never sent or received.
I'm also fairly confident that our current spammy environment
will make this problem worse, not better. As such, I think
this needs to be dropped from the specification, and if it
is retained, a specific format for such things needs to be
specified along the lines of a DSN or MDN so that they can
be detected and handled appropriately by an MUA.
In addition to the X.400 experience, I would encourage anyone
who wants to go down that path to try to review and understand
the EAI discussions, especially in the experimental round, about
trying to fix up messages in transit and what could be done if
that were not feasible. The X.400 experience was much more
fully developed and the general problems more obvious; the EAI
analysis was more specific to the characteristics of Internet
email and the strengths and limitations of the SMTP extension
model.
In addition, even if there were no other issues with forward
notifications, if the idea behind this proposal is to encrypt
and thereby hide information in transit, the specific format to
which Ned refers would have to provide enough information to be
useful without disclosing anything that was supposed to be
hidden. If it did disclose that information, we would be
essentially back to the problem of SASL fallback. It is not
clear to me --especially in the context of the notification
coming as a surprise to the recipient that Ned mentions-- that
the resulting redacted notification would contain enough
information to be either useful or comprehensible.
(2) Given that this is an SMTP extension, carrying information
about transport requirements in a header is a mistake.
...
Yes. Mentioned earlier.
(3) I assume the purpose of the MSMD indicator in POP3 and
IMAP4 is so that security assurances can be continued
across the mail access layer. If so, this needs to be
explained in more detail, because in that case the
parameter really doesn't offer any sort of capability to the
client. Rather, it is saying that certain operations the
client attempts may fail unless the client enables the
necessary level of security.
Again, some of the EAI discussions may help illuminate the
tradeoffs and issues with this. Or perhaps not.
(4) You need to define a way to inform POP3 and IMAP4 clients
that the reason they cannot access a given message is due
to security requirements not being met. It may also be
appropriate to provide an indication of what those
security requirements are. Or not; this is a tricky one.
Very. And, especially for POP3, the whole question of how to
tell a client that it cannot access a message (but that some
other client might be able to do so) is a very tricky one.
Again, a similar problem was necessarily explored as part of the
EAI work and a review by the authors of this document of that
work might be helpful.
...
The EAI work also identifies another concern that wasn't on
Ned's list. Until EAI, there were, as far as I know, no cases
(at least no standardized ones), in which a message could be
successfully delivered to the delivery server and mail store but
a POP3 or IMAP client could find itself in a position of not
being able to retrieve that message because it lacked some
important capability. EAI necessarily introduced one such case
-- one in which the mail store could handle non-ASCII header
information (in other than encoded word form) -- but the client
could not. Part of what made that work more complicated was the
realization that a user might use one client, with one set of
capabilities, one day and a different one the next: assumptions
that a delivery MTA can know the intended recipient's
capabilities are quite problematic.
There is one sense in which the problem posed by this draft is
even more complex than the EAI one. Because EAI doesn't promise
any security above that of "bare" SMTP and IMAP/POP3, it is ok
for a POP3 or IMAP server to display a mailbox table of contents
to a client that may not be able to retrieve all of the messages
in it (even if it has to do some conversions or conventional
representations to do so). With this new set of ideas,
displaying such a TOC in the clear might disclose information
then sender intended be kept encrypted.
best,
john
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp