著者: Sebastian Arcus 日付: To: exim-users 題目: Re: [exim] Possibly unclear logging after connection is closed by
the far end during DELAY
On 27/12/17 17:00, Jeremy Harris wrote: > On 27/12/17 16:24, Sebastian Arcus via Exim-users wrote:
>> I've spotted this while investigating issues with DELAY in in acl's, in
>> my other recent thread. It would seem that if a DROP acl has a long
>> DELAY set, and if during that DELAY the remote end just gets fed up and
>> closes the connection, Exim somehow still treats this as the ACL
>> processing has succeed and writes appropriate messages to the log and
>> claims the ACL worked. This can be somewhat confusing.
>
> You're effectively asking the delay= to be handled as an ACL condition,
> the result being whether it reaches the end of its defined time without
> being preempted by external forces. Currently is is not a condition,
> it is an ACL _modifier_.
>
> I don't think we care enough to change it, really. Actually spotting
> that the SMTP connection went away was a bonus added long after the
> genesis of the delay= modifier... and the result is the same; you
> had decided to drop the connection, the connection is dropped. The
> success of the ACL verb is not really relevant. The handling process
> goes away a bit quicker now, which I assume is preferred.
Ok - bear with me if you will. According to the documentation, DELAY =
<time> "causes Exim to wait for the time interval before proceeding".
Now, unless, I misunderstand things (which is perfectly possible), this
means the following:
1. Exim evaluates the conditions
2. Exim waits for <time>
3. Exim acts on the action of the acl, which in this case is DROP.
But if while waiting for <time>, the connection went away because the
far end dropped it, how could Exim possibly do a DROP on a non-existent
connection? I think that's where the confusion arises. I would have
thought the logical thing to do would be to check the connection is
still there before proceeding, and if it isn't, to abort the whole thing
and output to the log relevant information (and not output the message =
or log_message = any more). In other words, the connection going away
should be treated as some sort of disrupting event - instead of Exim
carrying on with the action of the acl like nothing happened. Maybe
looking at things from the programming end things makes sense the way
they are now, but from the perspective of someone trying to configure
and work with Exim, it is illogical and unexpected behaviour.
And a little explanation, which might throw a bit of light on how I got
here. I've inserted this particular acl to wait for a long time on
connections which are blatantly spam bots, in order to make them go
away. However, I find it very hard to work out when the bots go away by
themselves, and when they are dropped by Exim - as Exim always claims
"connection dropped by ACL" - which is plainly not true when the remote
end actually disconnected first. Again, I'm not an Exim expert, so I
welcome the enlightened comments of others who are :-)
