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.