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: [EMAIL PROTECTED] 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 <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] [EMAIL PROTECTED] 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 -- 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/
