Re: [lemonade] streamlined message submission

[Ned Freed <[e-mail]>]

> On Wed Feb 22 00:54:25 2006, Tony Finch wrote:
> > 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

> BURL doesn't allow clients to pipeline AUTH - that's just possible
> anyway with a server that supports PIPELINING. I have no idea why
> you'd want to pipeline QUIT - it's never going to be a good idea. You
> leave the connection open until it times out, in case you need to
> reuse it later. (Yes, this isn't nice to the server.)

The thing a lot of clients do is simply drop the connection without ever
sending a QUIT, rules to the contrary notwithstanding.

Of course the user can be told that the message was successfully sent the
instant the response to the final DATA/BURL/BDAT has been received. The QUIT
can then be handled asynchronously in the background. So if the goal is to
improve user experience, QUIT handling doesn't have to be relevant.

> Oh, and I believe that it's possible to include the banner in the TCP
> SYN+ACK packet coming from the server, but I couldn't swear to it.
> That one just got told to me in the pub once. I *think* Linux's TCP
> stack allows you to write the banner to a listening socket or
> something odd to get the behaviour, but I'd have to ask about.

Wow, you sure have more interesting conversations at the pub than I do ;-)

Anyway, I know of a couple of tricks in this space. One is the technique
described in RFC 1644, which eliminates the three way handshakes for repeated
connections between the same two machines. It isn't clear to me that this would
be useful in SMTP, however. Often as not there are a whole bunch of front end
machines a client can connect to, and arranging things so the client would have
an affinity for the last server would be tricky.

The other is to piggyback data on either the syn, syn-ack, or both. This has
been discussed many times on various lists but if there's an RFC discussing it
in detail I don't know the number. Piggyback data on syn isn't interesting in
SMTP since the server speaks first, but returning the server banner on the
syn-ack would represent some savings. The problem lies in implementation - most
(all?) TCP APIs don't allow data to be specified in the accept call. Some
stacks offer a way to delay sending acks in hopes they can be piggybacked on
returned data, but I don't know if this ever extends to syn-ack or not. The
trick you described of writing data to the socket before calling accept is not
one I've heard of before. I may try it and see if it works.

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

> A round-trip saved, that's good. This is a rough analogue of the IMAP
> CAPABILITY response code.

> The question is, is it possible that some ESMTP clients might be
> confused by a multiline response? I'm mildly concerned by that.

This used to be a problem in practice, but several years ago some fairly
popular SMTP server started spitting out multiline banners (something sort of
"no trespassing" sign, I think) and refused to provide an option to disable it,
which then got a lot of the incompliant gunk cleaned up. (It is always nice
when something that's widely deployed pushes the envelope this way.) At this
point I think compliance is pretty good - as it happens I forgot to dismantle a
test a few months back and inadvertently ran with a mulitline banner for a
while and noticed no problems.

> There's an alternate model for this sort of thing - you can issue a
> server configuration indicator in the banner, which changes whenever
> the configuration does, such that if you recognise it, then the EHLO
> becomes redundant, because you know the capabilities. Moreover,
> you've cached them *after* the secure channel setup, of course, so
> you needn't ever fetch them until you see that change.

We actually use a similar trick in our SMTP in order to avoid having to
code the list of supported extensions into the proxy. This is one of those
things that sounds simple but it is actually surprisingly hard to implement
correctly. I forget exactly what bugs we had, but we definitely had a couple.
I actually worry more about implementors getting this right than I do about
getting multiline banner processing right.

				Ned

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