On Tue, Dec 31, 2013 at 3:48 PM, John C Klensin <john-ietf(_at_)jck(_dot_)com>
wrote:
To take an example I hope is not taken as a proposal, the
security of SMTP against in-transit interception and monitoring
of messages could a considerably improved by eliminating
relaying (i.e., the application-level store and forward design
of the protocol).
I like that idea a lot actually.
A lot of the limitations on mail come from the assumption that I will
accept a 4Mb mail message (current Gmail max) from anyone who wants to send
it to me.
If we were designing a new mail protocol for sending huge blobs of data we
would probably start with the rule that the sender is responsible for
storing the bulk of the message until the recipient has decided that they
want to accept it.
Essentially this would be merging dropbox type capabilities into mail.
That would have a number of profoundly bad
effects, at least IMO, but it would enable some rather simple
methods of mitigating the threat that are of arguable or complex
utility if relaying is permitted.
I can't see that it would have bad effects. It would only be possible in a
completely different mail infrastructure that was not SMTP.
OK, it is technically possible to do just that with current SMTP
extensions, all that would be required is for an SMTP server to start
accepting some options that are currently reserved for SUBMIT.
But I would not want to do that in SMTP because the only infrastructure
that could benefit from the change in the model would have to be written
from scratch anyway (But it is still significant prior art.)
If the Apps ADs ever get
around to getting back to me about a months-old request to
discuss practical methods of moving RFCs 5321 and 5322 forward
to Internet Standard, I don't think it is reasonable to
legitimize an attempt to impose a requirement that starts with
"RFCnnnn says that monitoring threats should be mitigated where
possible, so we have to return to first principles and debate
whether SMTP should have relaying" when, without such a
statement, we'd be able to say "widely deployed, useful, and
working that way for a few decades, we just don't need to have
that discussion about the base protocols".
I think trying to retrofit such features to SMTP would be a very bad plan.
There are times to start from a clean slate and this would be one of them.
Every part of a privacy protected email transport would have to be audited
for privacy protection. There would be no way to leverage the legacy base.
So it would be an entirely new protocol. Probably building on JSON/REST
style of design rather than RFC821.
Now we could argue over whether such a scheme is practical at all. But I
don't think building on top of SMTP would help in this particular case.
So no, I don't see that the pervasive surveillance document should impact
RFC5381 going to STANDARD. Just do it already.
--
Website: http://hallambaker.com/