[Top] [All Lists]

Re: Keep Alive Response Codes

2005-09-16 04:11:20

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:
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:
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:
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 
keeping open hundreds of sockets nor having to resent every mail twice.


<Prev in Thread] Current Thread [Next in Thread>