Sandro Tosi wrote:
> Hi,
>
> On 12/06/2010 09:49 AM, W B Hacker wrote:
>
>> This works for us:
>>
>> # DATA_SCAN_12: Modify Subject line with *Suspect* when score is over limit
>> # and prep for divert to quarantine if per-recipient pg_quarantine is set
>> #
>> warn
>> !condition = ${if eq{$acl_m0}{1}}
>> condition = ${if>{$spam_score_int}{${eval:$acl_m7}}{1}{0}}
>> spam = spamd:true
>> message = Subject: *Suspect* $h_Subject:
>
> Yep that works, mut sadly we allow users to define what to do with spam
> emails f.e.:
>
> - do nothing
> - add a "tag" to the subject
> - forward to another email address
> - simply drop the mail
There are, IIRC, about 3 times that many options in our system, though only four
get the most use:
- minor heads-up flag
- Quarantine to checked 'usually' every day or so IMAP folder
- Quarantine 'deeper' to read maybe, sometime ...never? IMAP folder.
- Reject during smtp time
(we don't generally allow forwarding, but use rather the original smtp device of
supplying the new address in an error message. Or NOT)
.. each user has personal tolerance levels for several pre-SA tests as well.
RBL's used, HELO mismatch, their own LWL and LBL.
>
> Now, while I can define several routers and "somehow" let only one be
> used to "handle spam emails", I find it a quite awkward solution (and
> very badly scalable, since it needs changes to exim config each time a
> new action is allowed for users).
>
Not needed.
> We want to use filters because we can simply write them in a mysql
> table, read them from the db and execute them, and the add of a new
> filters doesn't change anything in the exim config but only on the
> users' UI.
>
All the above - done at smtp time, IS resident in a DB. No restart required,
Sometimes not even in a year or more.
PostgreSQL, not MySQL, but that matters not a wit to Exim.
> But then we're facing the problem of user filters not allowed to change
> message headers.
>
As above. NEITHER user filters NOR header changes are actually required to
accomplish the goal. Router/transports build a path to the selected IMAP folder
from PostgreSQL DB sourced components, creating the 'Suspect' folder(s) anew
if/as/when an annoyed user has deleted the whole damned folder, not just the
junk it contains.
IOW 'Bulletproof'. Idiot 'resistant', even.
The only 'need' is to limit each Exim child-process to one single recipient at a
time.
===
# RCPT_5: IF multiple recipients THEN defer all after first one.
# UNLESS for a domain that uses only per-domain preferences
#
defer
message = \n Limit one recipient at a time. Try again soon!
log_message = R5 $acl_m3 Second Recipient deferred.
!condition = ${if ge{$acl_m0}{2}}
!condition = ${if ge{$acl_m1}{2}}
!hosts = <redacted>
condition = $recipients_count
====
CAVEAT: Yes, that breaks an RFC requirement to handle at least 100 recipients
per message.
BUT *until* there is a wider use of some form of EXDATA to allow selective
per-recipient handling in DATA phase than just between/among courier-mta servers
(since 1999), there is no second-place choice.
Simply a legacy smtp flaw/oversight that is still awaiting correction..
No one *expected* spam/malware, nor differing tolerance levels within a given
domain when the standard was written. The world has changed since then.
Bigtime.
Besides Sam's actual implementation, Tony Finch proposed a similar scheme for
Exim. Long ago.
But all that needs reconciled, made compatible, and *at latest* sendmail &
postfix brought on board before it becomes usable. FWIW, Qmail doesn't have the
issue in the first place, as it normally tries to deliver ALL traffic one
message, one recipient per-connection. Which is suboptimal nowadays, as it
merely creates a *different* problem... multiple near-as-dammit-simultaneous
arrivals from ONE IP ...which, behaviour-wise, looks like a botnet..
So - answers, yes.
EASY or 'standard' answers?
Not YET. Workarounds only.
Wot was it one vulture said to the other about 'patience'?
;-)
Bill
>> Wot's wot:
>>
>> The first '!condition' is granting SA exemptions to the anointed ones for whom
>> acl_m0 has been set. May or may not be of interest...
>>
>> The second 'condition' uses a value in acl_m7 - one of MANY pulled from a
>> PostgreSQL DB at the time of acl_smtp_rcpt_to. *see caveat below*
>>
>> Router/transport sets act on acl_m7, not on the (modified) header.
>>
>> While a user-filter may not alter a header, might it not be able to 'see' an
>> acl_m variable and act on that instead?
>
> yes, we already use acl_m vars
>
>> The snippet above is but one of many per-reciint acl's, is not a 'user filter'
>> but has a comparable effect.
>>
>> NB:
>>
>> Unless stripped, headers survive all the way out to the MUA, may be considered
>> relatively 'permanent', and may (also) be utilized by end-user MUA filters.
>
> indeed, but why disable headers changes in user filters?
>
> Regards,
