Mailing List Archive

On 22/06/07 19:13, Robert Millan wrote:
> When processing incoming connections, ACLs that take too long to evaluate
> are usually a problem, since these tend to trigger a timeout in the sender
> and lose the message. In a server with too much load this prevents
> interesting setups like running spamassassin during delivery.

They have their timeouts set too low, and you need to defer delivery if load is too high to spam-check the message... (I do this in predata).

> However, I have the impression that one could workaround this by having
> exim print dummy continuation lines (such as those sent in teergrubing)
> untill our check has finished.

I have looked into doing this before, even to the point of adding an ACL command to send a "1xx-" line - exim and other MTAs will likely either complain about the response code changing, or take the response code from the first line. Every line must have the same response code if you want it to work in every MTA.

> I'm not sure if this would work, though, since the response code might not
> be determined untill our check has finished. RFC 821 isn't very explicit
> about this. Anyone knows if this kind of feature is viable? I could try
> to send a patch if so.

Even in RFC 2821 it's not properly defined, there's no MUST for using the last line. Unfortunately there's no definition of 1xx in that RFC other than it's something for ESMTP to consider making use of - and it's not a proper "processing..." like HTTP 1xx either.

"might not be determined"? if you knew it in advance you could avoid doing the long operation ;)

Sender verification is worse than anything else because you need to fit a whole SMTP session into the RCPT timeout of the sender and your own verify timeout - but this will work great if your timeout is quite large because it'll be cached for the next retry.

--
Simon Arlott