On Tue, Oct 15, 2013 at 2:25 PM, Timo Sirainen <tss(_at_)iki(_dot_)fi> wrote:
On 15.10.2013, at 21.31, Wei Chuang <weihaw(_at_)google(_dot_)com> wrote:
Request for discussion (draft-wchuang-msmd) of a proposal to secure mail
from eavesdropping and MitM attacks. All comments welcome on this thread.
I'm mentioning the proposal also to apps-discuss@ and saag@ lists as
this may be of interest to them too, but redirecting discussion to this
list so its all happening in one place.
The SMTP side is mostly what I had been thinking about earlier (although I
was thinking about MAIL FROM parameter instead of a header, but I'm not
sure if there's a big difference). The IMAP side of the draft makes the
security "complete", but it would also seriously slow down the deployment,
which is especially annoying because most of the target users are already
using IMAP and SMTP with TLS, making the MSMD command requirement mostly
irrelevant. If the IMAP server simply checked that the IMAP client was
connected with TLS, that would make it very likely that the SMTP submission
would also be done with TLS, I think?
Today I think this is not the case. Though the big webmail providers offer
IMAP w/TLS (certainly Gmail, but also I believe for example Yahoo and
Outlook), mail delivery over SMTP is typically not over TLS. Only a small
subset of providers actually offers SMTP STARTTLS and even then there's no
guarantee it will successfully deliver over TLS due to the SMTP STARTTLS
Unless maybe Google has statistics that this isn't the case?
Yes, statistics for mail delivery to/from Gmail indicates that most
deliveries are over SMTP w/o TLS though Gmail offers SMTP STARTTLS.
Agreed that the more constrained mode called Secure Conversation and Access
("SCA") option is more difficult to deploy since requires modification of
MUA's. That's why it is an option. Without the additional requirements
its difficult to see how unmodified MUA's could honor the header
propagation requirement. We believe an appropriate deployment strategy is
to incrementally take on pieces of this protocol starting from a fairly
easily achievable baseline.
Anyway, if the idea behind MSMD IMAP command survives, it should be done
with ENABLE MSMD instead.
Thanks for the pointer to RFC5161.
ietf-smtp mailing list