[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Exim conditions for attachments



This one time, at band camp, Craig Schneider said:

(redirecting this back to the list - I read the list, so you can send
replies there.)

> Hi Stephen
> 
> Thanks for the help dude.
> 
> Do you mean like this? Or incorporate it into the condition somehow?
> 
> #  deny  message = User is unable to receive attachments of this nature
> ($found_extension)
> #       domains = ! +local_domains
> #       condition =
> ${lookup{$recipients}lsearch{/etc/mail/extensions}{1}{0}}
> #        demime = jpg:mpg:mpeg:mp3:gif:bmp
> 
> Thanks

That statement will do this:
   if ( the domain of the recipient is not a local domain) and
      ( the recipient is found in a file) and
      ( after unpacking, the message contains one of these mime types)
  then deny the email

Which is not what I think you want.

I am also fairly sure that $recipients is not available in ACL's, but
only in system filters.  There are several problems with the approach
you're trying:

First, you can only unpack a message after the data phase of the smtp
transaction, at which point you may have one or more recipients for a
message.  What do you do with the email if one of the recipients is on
the list, but the others aren't?  If you reject the email, nobody in the
recipient list gets the email, whether they're on your list or not, and
if you accept it, everybody on the recipient list gets the email.

The +local_domain as sender is something that is too easily forged to
allow for exemption, IMHO - it's a not uncommon spammer trick to send
email from you to you, so you might allow a lot of things that you don't
actually want.

If I were you, I would take a moment to decide what you mean by 'the
email comes from the local domain', and then implementation gets easier.
If all local mail is generated on the localhost (e.g., all users use
webmail or have shell accounts), then you can write a condition to check
for an empty host string.  If instead you really plan to use just the
domain part of the sender, you can write a test that looks for sender =
*@+local_domains or whatever domainlist you use.  If you receive mail
from your local domain users in other ways (from a set of known machines,
or via authenticated smtp), write an acl that puts in a header, and test
for that header later in a router or filter.

Per user mime filtering will have to be done later, outside of the smtp
time transaction, though, so you'll want a router or something to do
this work (and you'll want that router to have no-verify in it, since
it will mess up routing in the acl's otherwise)  Overall, I think the
easiest approach would be to use a system filter, rather than an acl.
You'll have to decide what you want to do with these emails if the match
in the system filter (and I recommend not bouncing at this point, but
saving to a special mbox somewhere, to cut down on collateral spam)

I highly recommend reading /usr/share/doc/exim4-base/spec.txt.gz for
this sort of thing.  It makes all of these issues clear.

> From: Stephen Gran [mailto:steve@lobefin.net] On Behalf Of Stephen Gran
> This one time, at band camp, Craig Schneider said:
> > Hi Guys
> > 
> > I have wrtten a condition to check if a user is in a flat text file, 
> > if so then allow them NOT to receive attachments of a certain type. 
> > However I need to put a condition in to allow them to receive from the
> 
> If you mean from 127.0.0.1, then add a
> ! hosts = :
> 
> If you mean from user@$local_domain (trivially forged, and I would avoid
> relying on this test, add a ! senders_domain = +local_domains
> 
> (I may be wrong about sender_domains - check the spec.  It's close to
> that, but I forget and am too lazy to look right now :)
-- 
 -----------------------------------------------------------------
|   ,''`.					     Stephen Gran |
|  : :' :					 sgran@debian.org |
|  `. `'			Debian user, admin, and developer |
|    `-					    http://www.debian.org |
 -----------------------------------------------------------------

Attachment: pgpB752E7j_fm.pgp
Description: PGP signature


Reply to: