Re: [lemonade] streamlined message submission

At 5:09 PM -0800 2/21/06, Ned Freed wrote:

>   > 
> 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.

One of the main arguments against alternate-port-TLS is what happens 
if/when we deploy something else that replaces TLS?  Does each 
protocol then need three ports?

I wonder if it would be worth trying an approach that connects on the 
standard port, but immediately tried to negotiate TLS, without 
waiting for the usual greeting and extension list?  As long as 
existing servers send an error when they see the start of a TLS 
negotiation, it might be OK.

>   > 
> http://www.cus.cam.ac.uk/~fanf2/hermes/doc/antiforgery/draft-fanf-smtp-quickstart.txt
>
>  This extension seems quite reasonable to me.

I'm bothered by a few things:
	(1) would there be problems with clients connecting to servers 
and getting unexpected multi-line greetings?  [Ned seems to think 
this would be fine, so maybe we don't worry here.]
	(2) this business of the client using something extended as its 
first command to signal to the server that it is fine seems fragile
	(3) the burden on the client of correctly caching the server's 
extensions at the right time doesn't seem to be clearly described: in 
one place it says the client uses its most recent cache, yet in 
another it says that the client can't use SMTP AUTH if the server 
didn't advertise it prior to TLS; the most recent cache is likely to 
be post-TLS.
	(4) why would a server advertise PIPELINING in the greeting yet 
not in an EHLO response?  Or is there another reason the client can't 
assume PIPELINING if it sees it in the greeting yet issues an EHLO?

If we do proceed with this, I'd suggest that it MUST NOT be used on 
port 25; it MUST be a port 587 mechanism only.  This is because some 
servers have adopted anti-spam techniques that in some cases detect 
extra commands that are sent with the HELO/EHLO command (or otherwise 
look at client use of PIPELINING without having negotiated it).

I'd suggest that, while logging of client IP address is useful, 
reverse DNS information may be misleading and is generally much less 
useful.  They are certainly not equivalent.  It is fairly trivial for 
someone to setup their own PTR entries for IP addresses they own, 
containing any host names they choose; even when no malice is 
intended, the reverse zone is the most likely to be misconfigured.

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

>  (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?

If we do proceed with this draft, I'd suggest that malformed and 
unparseable address headers, as well as errors for a specific 
address, be handled by a new extended SMTP response code and 
including the bad address (or the entire header if it is bad) in 
square brackets in the text.  This would have to be a response after 
end of data, of course.

It's still a lot tricker for clients to get this right than an 
immediate error after the specific RCPT TO, but it's much, much, much 
better than accepting the message and generating a DSN.

At 5:16 PM +0000 2/22/06, Tony Finch wrote:

>  On Wed, 22 Feb 2006, Dave Cridland wrote:
>
>   > > 
> 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.
>
>  The BURL spec is the only document that gives permission to do it.

This is something we could likely tighten up in profile-bis.

>  Pipelined QUIT is included in an example in RFC 2920. It shouldn't be a
>  problem if the client waits for all the server's responses.

The client would pipeline QUIT and check the responses after the 
connection closes, right?  I suppose we'd want an extension that said 
"if any RCPT is bad then please ignore any subsequent ones because I 
don't really want it sent even though it might seem so but that is 
just because I am pipelining everything".  It would be the moral 
equivalent of the compiler flags to treat all warnings as errors. 
The client would include this new keyword on MAIL FROM (maybe 
ABORTONBADRCPT), the server would generate usual responses to every 
RCPT TO, then if any were bad, it would send a failure after 
end-of-data.

>  You can't reliably auto-detect plaintext SMTP (or IMAP) versus
>  TLS-on-connect on the same port, because there's a mismatch between who
>  talks first. If it was consistently the client that talked first then the
>  server could autodetect, but the SMTP or IMAP server banner prevents this.

But the server can check before it sends the greeting to see if the 
client sent any data and if so if it is a TLS initiation, couldn't 
it?  They way some servers now check if the client sent commands 
without waiting for the EHLO response?
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
Get your facts first, and then you can distort them as much as you please.
--Mark Twain

_______________________________________________
lemonade mailing list
lemonade@ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade