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
