ietf-smtp
[Top] [All Lists]

Re: Keep Alive Response Codes

2005-09-16 04:53:38

At 11:58 16/09/2005, Bogdan Tomchuk wrote:

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

BUT, the consensus here is that you should NOT accept the message and then send back a bounce later. So, you need to analyse it at place of entry if possible.

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.

If it meant all the spam stopped as well, everything would be much better... ;)

If spam accounts for 80% of email, then reducing that by using more rigorous filters, even if they take longer is surely a good thing. It will mean a bigger CPU load on the server (where the most impact is), more open, idle, sockets on the client, and less traffic on the Internet.

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

Yes, the average being a few seconds is fine, and I don't have any problem with that (our spam filter can sort out 99% of email in less than 10 seconds, usually 2 or 3), BUT there are occasional big messages, which can take a minute or so (most of the time being spent in the virus scanner IME).

That is why the timeouts need to be longer than 30-60 seconds (AS RFC 2821 SAYS). The timeout doesn't specify the average time that a message can take before acceptance, but the maximum time.

Setting the timeout too small just means that the client needs to resend the message unnecessarily, which adds more load to everything (client, server AND infrastructure) than the client just waiting a bit longer because of a more sensible timeout.

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

I have no problem with making a proper SMTP extension, but it needs to be backwards compatible with old clients for obvious reasons.


Paul                            VPOP3 - Internet Email Server/Gateway
support(_at_)pscs(_dot_)co(_dot_)uk                      http://www.pscs.co.uk/