Daniele Gallarato wrote:
> thanks a lot, it works!
> Daniele
You can do better, actually.
IF you pull per-user prefs during acl_smtp_recpt
AND store them in an acl_m variable
.. as a mini-DB, eg: sequential user:pref 'records' within a string you
concatenate as each of potentially 'many' users are parsed....
(impractical to use a different acl_m for each user, 'coz there could
easily be more recipients than available acl_m variables..)
- You can read that out during the router/transport phase and make
delivery accordingly.
- Which would protect users NOT wanting .wav. files from a given source
that you have had to pass 'globally' in order to satisfy one or more
OTHER users who DO want .wav files from that source.
Capiche?
The complexity is because an MTA is 'blind' to the presence of the .wav
file until into acl_smtp_data, when it first has actual sight of the
body and attachments, but by which point it is too late to reject based
on per-user prefs. Unless BOTH NTA are courier-MTA, which can do.
Ergo, your router/transports hand the .wav off to those who want them,
quarantine or even blackhole for those who do not.
CAVEAT1: Similar tricks w/r selecting-out the user:pref seen here
(search the archives) but not tested or in use at our shop, as we use
SQL for this...
CAVEAT2: DON'T go to SQL-driven unless you have light loads and good SQL
skills. The resources needed are significant, and the admin can be a RPITA.
CAVEAT3: Within an environment where multiple-recipient incoming is
*seriously* rare, if not non-existent, (and there are *many* such), it
is far easier to simply 'defer' second and subsequent recipients, at
which point the acl-smtp_data phase IS 'per recipient' if only 'coz
there is only ever one recipient at a time.
;-)
BFBI, but it can work wonders in a small shop....
Bill
>
> W B Hacker wrote:
>
> Daniele Gallarato wrote:
>
>
> Thanks Eduardo.
> This is my configuration:
> deny message = Questo messaggio contiene attachment non consentiti:
> (.$found_extension)
> demime =
> m3u:acm:avb:bat:bin:chm:cmd:com:dll:exe:gms:hta:inf:lnk:mht:ocx:pif:wa
> v
> How can I modify it?
> Daniele
> Eduardo M KALINOWSKI wrote:
>
> Daniele Gallarato escreveu:
>
>
> Hello all.
> I've this problem.
> I've configured exim to block mails whose contain wav attachment.
> But I've a voice mail server that send messages with this type of file,
> and I want to configure an exception to permit this.
> Is it possible to obtain this?
> Using some type of acl? With ip address would be great.
>
>
>
>
> It certainly is possible. How are you blocking the .wav attachments?
> Providing the configuration snippet responsible for that would help.
>
> I'd guess you need something like
> !hosts = ip.of.whitelisted.server
> in the ACL that blocks the attachments.
>
>
>
>
>
> First, split into two acl clauses so as to not lose the other protections.
>
> A) Remove the /wav extension in your original:
>
>
> ====
>
> deny
> message = Questo messaggio contiene attachment non consentiti \
> (.$found_extension)
> demime = m3u:acm:avb:bat:bin:chm:cmd:. . . . (all EXCEPT .wav)
>
> ====
>
> B) Add a new acl clause ONLY looking ONLY for .wav:
>
> ====
> deny
> message = Questo messaggio contiene attachment non consentiti \
> (.$found_extension)
> !hosts = { a hostlist of those permitted}
> ==
> and/or
> ==
> !condition = {an lsearch of a flat file of those permitted}
> demime = .wav
>
> ====
>
> CAVEATS:
>
> A 'hostlist', unless it is itself a lookup, needs editing WITHIN the
> ~/exim/comnfigure file AND a 'restart' to accomodate changes.
>
> An lsearch (or similar search) of an external DB or falt file of IP or
> hostnames requires neither ~/configure editing nor restart.
> Any changes made to it will automagically be effective at the next
> incoming message.
>
> Specifics for how to match on IP, hostname or other are well covered in
> the docs and archives, not reproduced above.
>
> HTH,
>
> Bill Hacker
>
>
