Ben Allen wrote:
> Hi exim-users.
>
> I've hit a snag trying to implement some countermeasures for compromised local
> accounts. What I would like to be able to do is temporarily queue a message if
> it matches certain criteria (e.g. there's a lot of recipients in it, or the
> RCPT rate is fast). Having queued this suspicious message, when it comes time
> to deliver it I check the sender's status again, and if things've got worse
> (i.e. even more messages have been sent), I want to freeze the message on the
> queue so admins can take a look at it.
>
> The problem is that there's no guarantee that a message will remain on the
> queue for any length of time. If it happens to be placed on the queue one
> second before a queue run starts then it won't give the sender (phisher) time
> to exceed the limit.
>
> So my idea was to use a system filter to just defer the first delivery, and
> then check status for subsequent queue runs to see if it's exceeded the limits
> and freeze if it has, otherwise deliver as normal. This will guarantee that
> message stays on the queue at least as long as the time between queue runs.
>
> The problem is that the 'freeze' filter command doesn't seem to work on a
> message that's been deferred already. What happens is that the message just
> defers again (this actually isn't too much of a problem in my case, 'cause at
> least it's not getting delivered).
>
> The following simple system filter shows the problem:
>
> if first_delivery
> then
> defer
> else
> freeze
> endif
>
> This will just continually defer the message, it never gets frozen. I've had a
> quick look at the code, and it seems the problem is caused by not setting a
> flag to cause the message headers to be updated. On a first delivery, the
> flags are updated successfully because freeze and defer share common code.
> Subsequent runs through don't write an updated spool file.
>
> A simple fix looks to me to be to add an 'update_spool=TRUE' around line 4860
> of deliver.c:
>
> diff -r -c exim-4.72/src/deliver.c exim-4.72-freeze-fix/src/deliver.c
> *** exim-4.72/src/deliver.c 2009-11-16 19:50:36.000000000 +0000
> --- exim-4.72-freeze-fix/src/deliver.c 2010-11-26 13:12:57.294265558 +0000
> ***************
> *** 4863,4868 ****
> --- 4863,4869 ----
> frozen_info = string_sprintf(" by the system filter%s%s",
> (filter_message == NULL)? US"" : US": ",
> (filter_message == NULL)? US"" : filter_message);
> + update_spool = TRUE;
> }
>
> /* The filter can request that a message be failed. The error message may
> be
>
> As far as I can tell, this'd force the spool file to be updated if there's a
> filter 'freeze' command.
>
>
> I'm wondering if :
> a). This is actually a bug, or if it's by design.
> b). The embarrassingly simple fix above will work, or would something else
> break.
> c). Will it be fixed in subsequent exims?
>
>
>
> Regards
>
> Ben
>
>
>
Ben,
You might wish to submit that proposed patch via the exim-dev list where
developers may see it sooner...
Meanwhile - have you considered using 'acl_not_smtp' instead?
AFAICS, that would give you a richer set of well-proven tools.
'Rich' enough that I've never needed to use a system filter at all.
JM2CW
Bill
