Author: Alan J. Flavell Date: To: Exim users list Subject: Re: [Exim] MAIL ACL and sender verification
On Mon, 23 Dec 2002, Giuliano Gavazzi wrote:
> At 18:10 +0000 2002/12/23, Alan J. Flavell wrote:
> >So far, it seems that the best chance for getting rid of bad mail
> >detected in earlier phases is to postpone the 5xx response until the
> >RCPT TO phase.
>
> are you really postponing?
Yes, we postpone the tests... ;-)
> Can you preserve a state from the MAIL FROM acl to the RCPT TO acl?
For the testable things that I had in mind, one can postpone testing
them until the RCPT TO phase: it isn't necessary to perform the tests
at the first possible moment and then need to remember the result.
If you see what I mean.
There's also a class of abusive sender that disregards our rejection
of their invalid HELO, and just goes right on with the other phases:
but there's a recipe at the RCPT TO phase which detects the situation
again, and gives 5xx to the RCPT TO. (We got the recipe off this
mailing list as I recall).
This of course is no use for problems which happen in the DATA phase.
By then it's too late to send 5xx to RCPT TO. If the sending MTA
misbehaves by treating a 5xx at that stage as retryable, the only cure
would seem to be to set some kind of block which will catch it in an
earlier phase as it comes around again. At the moment, with us, that
only gets done manually (e.g by blocking the IP if we happen to spot
it happening in the rejectlog - I guess most of them just play out
their retry strategy to the end), but if it got to be too much of a
nuisance I suppose it could be automated. Though, it seems to me that
having exim directly updating its own blocking lists via recipes
written by us (i.e non-specialists and not peer reviewed) would be a
potentially risky thing to do.