Re: Processing after the end of DATA

Hi Paul,

Good idea, but I am not sure a 2nd SMTP "status" call is really 
necessary here.
Overall, Extensions means Change (client and server), and Change means 
software can be adapted in any nice way for a better fit.  Of course, 
it excludes supporting legacy software.
Probably the most backward compatible way is to use a temporary 45x 
rejection if the server sees that a lengthy delay is possible, 
complete the SMTP session (get the QUIT etc), but continue the 
processing in the background and record the results (250, 55x).  If 
and when the retransmit takes place, the data processing is 
preempted/skipped and the real final reply code can be immediately 
provided.
Very similar to a Grey List concept.

Maybe using a 1 minute data processing limit before a deferred status 
is triggered  with a 451 response.
Your idea is good in that it eliminates the retransmission, but the 
software coding is more complex and its not backward compatible with 
legacy clients.
Maybe a combination of the your DEFERREDSTATUS idea with recommended 
processing suggestion for legacy clients would work nicely. :)  Modern 
clients don't have to do a retransmission, but legacy clients will 
work the same with retransmissions.
Interested in working together on an SMTP extension I-D for this?


--
Sincerely

Hector Santos
http://www.santronics.com


Paul Smith wrote:
>  On 11/08/2010 15:30, Hector Santos wrote:
> > +1. If we are looking for insights for "adjusted" recommendations, 
> > this would be a good time as there is no doubt the direction and 
> > growth of DATA level processing is permanent now.  The hardware allows 
> > for these new framework feasible in a scaled up manner and there is no 
> > way we can tell people "don't do that" and go back to old school 
> > methods of having post-SMTP (post acceptance) only data processing.
> > Probably a BCP or a new I-D for SMTP DATA Processing Filtering 
> > Guidelines would be very welcome and useful.
> > I would not mind drafting it if people think it is a good idea.
> Daft question, but is there room for an SMTP extension here, given that 
> some senders really don't like waiting 10 minutes (or even 1 minute in 
> some cases) for a response for some reason:
> - EHLO keyword 'DEFERREDSTATUS <x seconds>
>
> - SENDER commands 'DEFERSTATUS' and 'GETDEFERRED'
>
> Transaction
>
> S: 220 ESMTP server ready
> C: EHLO mydomain.com
> S: 220-DEFERREDSTATUS 600
> S: 220 HELP
> C: DEFERSTATUS
> S: 250 OK
> C: MAIL FROM, RCPT TO, DATA etc
> C: .
> S: 250 2.5.6 Message accepted for now - id: bibblebobble237
> (or could give other 2/4/5xx response immediately)
> C: QUIT
>
> <at least 10 minutes (600 seconds) later>
>
> S: 220 ESMTP server ready
> C: EHLO mydomain.com
> S: 220-DEFERREDSTATUS 600
> S: 220 HELP
> C: GETDEFERRED bibblebobble237
> S: 550 Don't like that message
> C: QUIT
>
> So, the sender could choose to have a quick turnaround and get responses 
> later, or wait and get them now. When the client choose deferred status 
> notification the server can process later, but has no responsibility to 
> generate a DSN.
> Servers could still give immediate failures if they want, but if they 
> give a "deferred" code (I chose 2.5.6 out of thin air), then the sender 
> comes back later to find out what happened to the message.
> Obviously the server could still lie about the response (eg give a 2xx 
> response when it really threw away spam) or take a few seconds before 
> deciding whether to give an immediate or deferred response, as they do 
> now, it could just cut down on duplicate processing.