[TriLUG] simple mail filter. best option?

[Cristobal Palmer]

Should've summarized this back when I finally picked a solution, but
better late than never, I hope.

I ended up going with something very close to what's described in
http://www.postfix.org/RESTRICTION_CLASS_README.html under "protecting
internal email..."

in /etc/postfix/main.cf I have something like this:

smtpd_recipient_restrictions =
  [...]
  permit_mynetworks
  check_recipient_access hash:/etc/postfix/protected

smtpd_restriction_classes = clients_only
clients_only = check_sender_access hash:/etc/postfix/clients, reject

and then in /etc/postfix/clients I have lines like:

baz.com   OK

and then in /etc/postfix/protected I have lines like:

baz at my.subdomain.com   clients_only

After getting all those configs in place, I "sudo postmap
hash:clients" (same for "protected") and restart postfix. Huzzah!

Now obviously this means that everybody in /etc/postfix/clients will
be whitelisted for all the addresses in /etc/postfix/protected, but I
can live with that, since really it was paranoia that inspired me to
want to isolate all the clients from each other. In this setup the
likelihood of mail from one client affecting another is negligible. If
that paranoia turns out to be well-founded, I'll have to change things
a bit. :)

For now, I'm rather happy with my filter.

Thanks very much to Aaron for sending me down the right path.

On 7/27/06, Aaron S. Joyner <aaron at joyner.ws> wrote:
> Cristobal Palmer wrote:
>
> > Looking at smtpd_sender_restrictions led me to the ACCESS(5) manpage,
> > which in turn led me (back) to REGEXP_TABLE(5).
> >
> > Do I retain the advantages you described if I use regexp or pcre (I
> > see postfix-pcre is a package in the distro we're using) instead of
> > 'smtpd_sender_restrictions = hash:/etc/postfix/access,
> > reject_unknown_sender_domain' in /etc/postfix/man.cf?
>
>
> Pardon the slow responses, but checking my home email is a luxury I
> don't make enough time for these days.  The parents being in town for
> two weeks takes extra cycles out of my day as well.
>
> So it seems from your previous two messages that you didn't define / I
> didn't understand the problem space sufficiently.  You're not setting up
> a small system that only deals with a couple domains as originally
> suggested to keep the explanation simple, you're wanting a general
> solution that will work for lots of domains, ie. such as selling a
> service for custom email where users of foo.com have an isolated system
> from all of the other customers of said system, and all others have the
> same.  It seems both solutions suggested will have the same problem as
> they were proposed, although as you've likely discovered by now you
> could make both generalized to fit the task.  I still suggest that doing
> it at the MTA is the better way, for all of the reasons previously
> given.  Thus, on with the answering.
>
> Solving this problem with postfix can't be easily done with the built-in
> rules.  The reason is you want to match against both the recipient
> domain and the sender domain, to ensure they are the same.  There for
> neither smtpd_recipient_restrictions or smtpd_sender_restrictions are
> sufficient, and postfix doesn't support any kind of concept of state
> between the two in it's config files.  I have done basically this exact
> setup for a former employer, by writing a small daemon which listens for
> a connection from postfix, evaluates variables corresponding to the
> message, does some comparisons to see if it matches your access policy,
> and returns a result to postfix.  This is done through the access policy
> delegation (check_policy_service)..  This feature-set was added for
> greylist-type daemons, but works quite well for your particular problem
> space.  The connection from Postfix is well defined and light weight,
> and is documented here:
> http://www.postfix.org/SMTPD_POLICY_README.html
>
> You can roll your own, or if you do not have the nack for programming,
> google for something similar, or perhaps enlist someone in TriLUG to
> create one for you for appropriate compensation (small fee, copious
> quantities of alcohol, etc).  Adapting the greylist policy server
> example that comes with Postfix should be an easy place to start.  A
> simple substring match between sender= and recipient= is all that's
> required.  If both lines exist, and they violate your policy, send an
> appropriate rejection, otherwise send a 'dunno' (aka don't do anything
> different, so the filter has not unintended effects).
>
> As a side note, for any of this to be effective against malicious users,
> you need to require authentication of your users, and then also turn on
> reject_authenticated_sender_login_mismatch, so that an authenticated
> user from domain foo.com can't forge mail as a sender from baz.com, as
> you mentioned previously.  Even if you don't require authentication,
> it's still useful to cut down on 99% of the email that would mistakenly
> find it's way into your system, and deal with that 1% of abusive users
> who understand your system with your handy Iron Fist.
>
> Let us know how it goes, or if you need help with the above,
> Aaron S. Joyner
> --
> TriLUG mailing list        : http://www.trilug.org/mailman/listinfo/trilug
> TriLUG Organizational FAQ  : http://trilug.org/faq/
> TriLUG Member Services FAQ : http://members.trilug.org/services_faq/
>


-- 
Cristobal M. Palmer
UNC-CH SILS Student
TriLUG Vice Chair
cristobalpalmer at gmail.com
cmpalmer at ils.unc.edu
ils.unc.edu/~cmpalmer
"Television-free since 2003"

<tarheelcoxn> iank has trouble with English. his native language is Python
<iank> Yeah
<iank>   I'm forced
<iank>     To indent
<iank>   My sentences