Am 21.02.2013 15:02, schrieb Chris Knadle:
> On Thursday, February 21, 2013 07:12:34, ROGERS Richard M wrote:
>>> From: exim-users-bounces+richard.rogers=staffs.ac.uk@???
>>> [mailto:exim-users-bounces+richard.rogers=staffs.ac.uk@exim.org] On
>>> Behalf Of Cyborg
>>> Sent: 21 February 2013 11:57
>>> To: exim-users@???
>>> Subject: Re: [exim] forany() with multiply recipients
>>>
>>> Am 21.02.2013 12:18, schrieb ROGERS Richard M:
>>>> We have a case a bit like this here, where individuals can set their
>>>> own
>>> preferences/whitelist/blacklist, so handling can change even within the
>>> one domain.
>>>
>>>> The way we deal with it is to set the message handling according to the
>>>> first
>>> recipient's preference; then if the handling is different for later ones
>>> they get a 4xx (temporary rejection). It introduces some delays but
>>> everyone gets the message handling they want.
>>>
>>>> Regards
>>> out of curiosity .. how does sending a 4XX help with a logic decision
>>> with opposite outcomes ?
>> I'm not entirely sure I understand the question - but the point of the
>> approach is that only one set of preferences can be applied to an accepted
>> message.
> This also happens with per-user SpamAssassin settings. For instance in the
> instructions below in A.10.3.1 the suggestion is to only accept one recipient
> per message in order to apply the correct user preferences on each message.
> This causes a retry for every local recipient of the message past the first
> one. :-(
>
> https://www.redhat.com/mirrors/LDP/HOWTO/Spam-Filtering-for-MX/exim-sa.html
>
> If someone knows a way to have Exim go through the delivery ACL rules for each
> recipient, I'd like to know.
>
This seems to be a design issue :
Too inform the sender, that his attempt did not work, we have to reject
it on SMTP level, means inside acl_check_data or a similar capable acl.
Otherwise, we have to create a new delivery message and inform the
sender about the "later" failure inside a router. Which will not work
with spams as of the nature of most faked sender addresses.
a new acl "acl_per_recipient" could solve such problems on an elegant way.
Phil? What is your opinion about such an approach ?
