Sandro Tosi wrote:
> On 12/06/2010 01:36 PM, Ian Eiloart wrote:
>>
>>
>> --On 6 December 2010 12:21:54 +0100 Sandro Tosi<sandro.tosi@???>
>> wrote:
>>
>>>
>>>> However, we do have a web application that permits users to edit their
>>>> user filters. It presents a simple interface to forwarding and vacation
>>>> messages. You could do something similar for a system filter.
>>>
>>> We thought about doing this way too, but how do you handle the same
>>> email routed to 2 different local users that has different system filters?
>>>
>>> AFAIUI, the system filters are executed just once per delivery
>>> (different from user filters that are executed at each mail routing) so
>>> we are feared that just the system filters of a user (random? the first
>>> rcpt to?) is used instead of the system filters for each user mail
>>> routing.
>>
>> Oh, that'll teach me to think before I write. You're right. The manual does
>> describe something that might be what you want, in section 43.8. However,
>> the documention doesn't specify whether that's a way of running a system
>> filter per user, or a centralised way of running user filters.
>>
>> So, you might want to look at transport options, combined with per user
>> lookups on a file or ldap entry.
>
> Yep, user filtering this way it works, but user filters are not allowed
> (AFAICS, and that's the reason for this thread :) to change message
> headers, but in our configuration (for example) our users would like to
> change the Subject for spam emails to prepend a string and that's not
> possible.
>
> Regards,
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:
=====
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?
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.
acl_m's 'survive' only until last delivery-from-queue has been actioned.
Basically limted to use by Exim.
Sometimes that is as good as or better than parsing a header. Sometimes not.
....might be worth looking into, as it is much less hassle to handle all this
during smtp-session and reduce need for 'out-of-band' DSN/Bounce ELSE
blackhole.....
CAVEAT: Of necessity, arrivals are limited to one recipient per message.
We'll gladly give that up if/as/when some form of EXDATA is adopted by more than
just the one MTA that uses it these ten years past....
Bill
