View Full Version : Postfix exception
22nd September 2009, 22:06
Hi everybody !
Is there a way to make a recipient in Postfix (ex. email@example.com) receive all mail that arrive on the server ? In other words, I would like to make that a user receive all emails that was sended to him of course, blocking anything (spam, etc), bypassing the helo restrictions, recipient restrictions, etc ..., in the main.cf file ?
22nd September 2009, 22:08
In the topic above, I would like to say that, the internal user mail must receive all emails directing to him, include spams, etc.
25th September 2009, 11:53
Sorry, your posts contradict each other. Do you need to know how to get all emails sent to a server to go to one person (with spam filtering) or do you need just all mail for a particular user (irrespective of spam level) to arrive?
Also, do you have a spam filtering application installed beyond postfix (e.g. spamassassin)?
25th September 2009, 16:11
Hi McFlinn !
Thanks for your replay. The second alternative, I need just all mail for a particular user (irrespective of spam level) to arrive, bypassing the helo, recipient restrictions, etc, in the main.conf file. I don't have any spam filter, neither spamassassin. Do you know a way to do this ?
25th September 2009, 17:08
This is perfectly possible through the use of an access file. I'll talk you through creating and populating the access file and how and where to add it to the main.cf. I apologise if I go over any stages/knowledge that you're already aware of.
cp access recipient_access
Now add (at the bottom of the file) data in the following format:
This will allow any mail sent to this email to pass through postfix unabashed irrespective of where it came from or whether the sender is blaclisted on an RBL etc.
Save the file and now we'll add it to main.cf.
Save the file. Restart postfix and we're done. Any emails sent to your required domain will pass through and anything sent to any other address will follow through the restrictions laid out in main.cf.
Any issues, problems or lack of clarity then let me know.
25th September 2009, 18:32
Ok, but my doubt is that, in the main.cf file I have something like this :
So, my question is, the helo restrictions are applied before or at the same time that the recipient restrictions ? Because, if the helo restrictions are applied before the recipient restrictions, in this case if a email with a non-fqdn-hostname arrive on my server, it will be rejected, and I want that any kind of mail arrive for a person. In other way, if the helo and recipient are checked at the same time, so I believe that you example must really work.
28th September 2009, 10:25
The initial checks will be made after the RCPT TO command. So if the sender has a non-fqdn it won't be rejected until the RCTP TO command completes. This means that if the receipient has a different policy then it should go through.
The only exception to this is if a sender sends the HELO command without a hostname of any kind (assuming that's you're set up).
Give the setup a test either by sending in emails and looking at the mail log or telnet and manually send mail in.
Let me know if you get any issues.
7th October 2009, 18:24
Sorry about the late answer. I think a found the solution. I took a look at "O'Reilly - Postfix The Definitive Guide.pdf" and I read this: "... One important concept that confuses many people at first is that any of these restrictions can be used in any rule. While it may seem logical that check_helo_access should be assigned to smtpd_helo_restrictions, it could equally be assigned to smptd_sender_restrictions or any of the others. This gives you a lot of flexibility in ordering your restrictions when deciding what to accept and what to block."
Based on above, my main.cf stays like this:
The recipient_access file contains:
With this I can whitelist the internal user in the tree levels of restrictions (helo, sender and recipient). So I think that now the user are receiving all mail directiong to him.
I appreciate you help. Thank you very much !
vBulletin® v3.8.7, Copyright ©2000-2014, vBulletin Solutions, Inc.