Συντάκτης: W B Hacker Ημερομηνία: Προς: exim users Αντικείμενο: Re: [exim] Persistent storage per-message
Jakob Hirsch wrote: > Quoting Matthew Hodgson:
>
>> ACL based verification only seems to happen currently when the MTA
>> receives a message through SMTP - is there a way to ensure it happens
>> during local submission too? I'd obviously need the same behaviour
>> regardless of the protocol by which the message arrived.
>
> I guess not, as there's no way to individually reject or defer
> recipients with not_smtp.
Quoting the acl_not_smtp_start docs, emphasis mine;
"...The result of this ACL is ignored; it cannot be used to reject a message. If
you really need to, *you could set a value in an ACL variable here and reject
based on that* in the acl_not_smtp ACL...."
Now - 'per recipient?' Challenging, but on 'cross box' traffic, I see little
harm in batching one at a time, as there is no smtp sesson handshake, retry
delay, etc. as there could be if limiting smtp acceptance to one-at-a-time.
(I say 'could' rather that 'would' as singleton smtp arrivals are common anyway.)
Bill
>
>>>> depend on that flag? I'm trying to get the presence of an alias-resolved
>>>> recipient to affect the behaviour of delivery to other recipients of a
>>>> message.
>>> Example?
>> An incoming mail needs to be passed through a transport_filter if it has a
>> particular recipient - but that filter needs to be able to know all the
>> other alias-resolved recipients for that message (so that if it spawns
>> additional mails, it doesn't spam people cc'd or bcc'd on the original).
>
> Sorry, I still don't understand why you need such a flag or what your
> transport filter is for. If all it does is adding additional recipients,
> you could do that in a redirect router with "data = ${run...}".
>
> If you want to prevent duplicates with an external programm, you have to
> check the whole recipient list (which is available in $recipients, but
> not generally, so you may have to save it to acl_m_recipients in
> acl_(smtp_data|not_smtp), but beware of bcc disclosure).
>
>
>