Re: [lemonade] streamlined message submission

[Ned Freed <[e-mail]>]

> The talk about round-trip times on the main IETF list (combined with some
> other things I have been thinking abou recently) got me interested. How
> much can you streamline message submission? Current securely authenticated
> message submission requires at least eleven round trips (including TCP
> startup and shutdown). BURL can reduce this to nine. The non-standard but
> popular smtps reduces it to six. A further tweak to SMTP's start sequence
> could reduce it to five. This seems pretty good.

> I've written this up in more detail. The following are all fairly short,
> and where they aren't they are formulaic.

> http://www.cus.cam.ac.uk/~fanf2/hermes/doc/antiforgery/draft-fanf-submission-streamlined.txt

This is effectively a description of how to combine the remaining mechanisms
plus BURL.

> http://www.cus.cam.ac.uk/~fanf2/hermes/doc/antiforgery/draft-fanf-smtp-tls-on-connect.txt

I have to say I agreed with the decision not to go with separate ports and with
STARTTLS instead. And although this does reduce round trips significantly I'm
fairly unenthusiastic it, but less because I agreed with the prior decision and
more because  I predict there will be opposition to moving back to the smtps
approach from the security folks. And although we've supported smtps in our
product for a long time, I don't in practice see the large amounts of lingering
use of it you do.

> http://www.cus.cam.ac.uk/~fanf2/hermes/doc/antiforgery/draft-fanf-smtp-quickstart.txt

This extension seems quite reasonable to me. I would suggest that you point out
in the security considerations that logging of the client's IP address is more
useful in practice than logging of the EHLO value. (This is mentioned in
section 1 but bears repeating. Or perhaps some of the discussion in the
introduction should be moved to the security considerations section.)

You probably do need to include an SMTP service extension registration
template, even though as you say this doesn't really conform to the
EHLO extension announcement model.

> http://www.cus.cam.ac.uk/~fanf2/hermes/doc/antiforgery/draft-fanf-smtp-rcpthdr.txt

First an editorial comment - the draft refers repeatedly to RFC 2476. This RFC
is obsolete, having been replaced by draft-gellens-submit-bis-02.txt, which has
already been approved as a draft standard.

As the draft points out, this doesn't reduce the number of round trips except
in the case where more than 4K of recipient data is involved, which is quite
rare in practice. I therefore see little value in it. I also see lots of
problems with it, including but not limited to:

(0) How are malformed or unparseable To:/Cc:/Bcc: fields supposed to be
    handled? There's no place to report such an error in the dialogue and
    a DSN isn't designed to report such issues.

(1) How are problems with specific recipient addresses supposed to be handled?
    The draft seems to say that this is covered in RFC 2476. But it isn't -
    in fact RFC 2476 specifically talks about using RCPT TO command
    responses to report this sort of thing - the facility you have eliminated.
    AFAICT the best that could be done is to return a DSN later. But after
    having seen this model used elsewhere I can tell you that users absolutely
    hate it. If there's a problem with a recipient they've specified they
    want to see it right there on the screen when they send a message.
    Getting back a DSN later is nowhere near as good, and as joe-jobs
    and blowback spam continues to grow DSNs stand an ever-increasing
    chance of being lost in the shuffle.

(2) The reliance on header ordering to handle Resent- is something I find
    to be quite problematic, language about it in RFC 2822 notwithstanding.

I also have to say I find the argument that traffic analysis of a pipelined
session often reveals the number of recipients and this mechanism protects
against it to be pretty dubious. There's a lot of variably sized stuff in the
various commands and it would be very difficult to track its cumulative effect.
Additionally, in the case where recipients are scattered around on different
destination systems, a message is going to be split and sent multiple times
to different destinations. In this case even if TLS is used for everything
tracking the overall size and temporal adjacency of the messages sent by a
given system will let you correlate things to the point where you'll know
at least how many different destinations for a given message was sent to,
regardless of whether or not this mechanism is used.

In short, I really don't think this one's a keeper.

				Ned

_______________________________________________
lemonade mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/lemonade