Re: [lemonade] streamlined message submission

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.

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

Dave.
-- 
           You see things; and you say "Why?"
   But I dream things that never were; and I say "Why not?"
    - George Bernard Shaw

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