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/
