Re: [lemonade] streamlined message submission

[Randall Gellens <[e-mail]>]

At 9:18 AM +0000 3/5/06, Dave Cridland wrote:

>  On Sat Mar  4 02:33:49 2006, Randall Gellens wrote:
>>  At 5:09 PM -0800 2/21/06, Ned Freed wrote:
>>>    > 
>>> 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.
>>
>  Chris Newman briefly proposed doing it the other way around, that 
> is, generating the headers from the envelope.
>
>  I've written this up as 
> http://dave.cridland.net/draft-cridland-esmtp-headergen-pre.txt 
> with XML source at 
> http://svn.dave.cridland.net/svn/ietf-drafts/draft-cridland-esmtp-headergen.xml
>
>  (This is very rough thus far, just aimed at being a talking point. 
> In particular, as I write this, I note I've not yet seperated out 
> informative and normative references at all.)
>
>  Given the availability of PIPELINING, this seems like a better and 
> easier way to go.

I'd agree that this approach (generating headers from envelope) is 
better than the other way around, since the client can easily 
determine which address is bad, but I'd still question the value.  It 
seems to me that saving round-trips is the key, that as 3G systems 
are deployed, total octet savings isn't as important, while latency 
and round-trips still are.  I could easily be wrong, of course.  But 
I'd like to see better explanations of why the added complexity is 
worth the octet savings.

(By the way, I like that 'foo' is the username for 'Fred Oo' -- clever).


>
>>  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.
>>
>  It's actually saying "If any RCPT is bad then I'm going to waste a 
> stackload of data transmission, and therefore cost and battery 
> life". I think if you want this behaviour, you have to introduce a 
> post-envelope sync point - ie, you send the envelope, and examine 
> responses to decide whether you wish to continue.

I suppose it depends on if we want to optimize for the error case or 
the non-error case.  If we expect at least one RCPT to fail, then we 
don't want to send the data until we know.  But if we expect that all 
RCPTs will be fine, then we don't want to introduce a delay waiting 
for the server response if we can pipeline the entire transaction. 
The size of the message is also significant, of course.  If we have a 
small message, then why have any delay?  But if we have a large 
message, maybe it makes sense to wait.

So perhaps there is use for such an extension plus client advice on 
how and when to use it.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
The reliability of machinery is inversely proportional to the
number and significance of any persons watching it.

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