The real world example IS anti-spam and anti-virus software.
If you don't see spam as a big problem that needs solving, then you're
living in a different world to the rest of us..
SPAM problem should be solved but not in cost of everybody.
There is no common criteria for SPAM so we can not write in RFC that
mail corresponding to that or that criteria should not be accepted.
If you cannot reject mail immediately you have to accept it and then you can
spend weeks analyzing it and doing what you want. This delay will became
internal problem of your anti-spam solution.
Just imagine for one second impact on world mail infrastructure if average
delay for ordinary mail trip will change from few seconds today to few
minutes tomorrow.
Can you precise me what do you consider to be "short timeouts" ?
Anything less than 2 or 3 minutes IMHO, or less than 10 minutes according
to RFC 2821.
2-3 or even 10 minutes is normal delay but only if average delay is of order
of few seconds.
The other option is to close the connection abruptly, and keep a note of
the message so you can reject it quickly next time.
That's close to my other idea - I was thinking of sending a 450- 450- etc
followed by 450 , and then waiting for the retry, having already decided
what to do with the message when it comes through again.
However, your idea is "sort of" better, in that it doesn't require a resend
for accepted messages. I'm not sure I like the idea of deliberately
dropping a connection though :)
If you insist in "long treatment", why not make proper schema, as for example:
C: DATA
S: 45?-Your mail was accepted for pretreatment.
S: 45? AverageDelay MaxDelay LifetimeDelay ID
AverageDelay - average reaction time
MaxDelay - maximum timeout of your treatment software
LifetimeDelay - Mail return delay for your server
ID - message id.
At this point client disconnects or says:
C: WAIT ID
S: 250 Accepted : Or S: 550 SPAM|Virus etc :
If client was disconnected by his own decision or by server at first stage,
next time it just says:
C: WAIT ID
S: 250 Accepted : Or S: 550 SPAM|Virus etc :
This kind of treatment is compatible with old generation client (4?? code) and
new generation client will have big advantage: If client can run without
neither
keeping open hundreds of sockets nor having to resent every mail twice.
TBP