Empty 'local_recipient_maps =' and security
in [Postfix]
|
From: Aniruddha on 12 May 2010 02:56 Hi, I have set up postfix with a mail_transport to Zarafa. To fix an ' Recipient address rejected: User unknown in local recipient table' error I have to put an empty 'local_recipient_maps =' in postfix's main.cf. I do wonder about the security implications of setting this option. If I understand the documentation correctly it isn't wise to set this option to empty. Is this correct? Besides the information below I can't find much information about this option.Thanks in advance! Documentation To turn off unknown local recipient rejects by the SMTP server, specify: /etc/postfix/main.cf: local_recipient_maps = That is, an empty value. With this setting, the Postfix SMTP server will not reject mail with "User unknown in local recipient table". Don't do this on systems that receive mail directly from the Internet. With today's worms and viruses, Postfix will become a backscatter source: it accepts mail for non-existent recipients and then tries to return that mail as "undeliverable" to the often forged sender address. http://www.postfix.org/LOCAL_RECIPIENT_README.html
From: Noel Jones on 12 May 2010 10:36 On 5/12/2010 1:56 AM, Aniruddha wrote: > Hi, > > I have set up postfix with a mail_transport to Zarafa. To fix an ' > Recipient address rejected: User unknown in local recipient table' > error I have to put an empty 'local_recipient_maps =' in postfix's > main.cf. The correct solution is to point that parameter at a map containing all your valid users. Often this is caused by listing a virtual_mailbox_domain in mydestination. Don't do that. > I do wonder about the security implications of setting this > option. If I understand the documentation correctly it isn't wise to > set this option to empty. Is this correct? Besides the information > below I can't find much information about this option.Thanks in > advance! Accepting mail for undeliverable recipients will cause postfix to send non-delivery notices -- bounces -- to the reported envelope sender. The envelope sender on spam is frequently either a non-working address or an innocent third party. This has two results; your queue is filled with undeliverable bounces, and you send bounces to innocent third parties. The full queue will badly affect delivery of legit mail, and the backscatter you send to innocent people will get you blacklisted. Rejecting the mail during the initial SMTP session avoids these problems. -- Noel Jones
From: Nataraj on 13 May 2010 14:19 Noel Jones wrote: > On 5/12/2010 1:56 AM, Aniruddha wrote: >> Hi, >> >> I have set up postfix with a mail_transport to Zarafa. To fix an ' >> Recipient address rejected: User unknown in local recipient table' >> error I have to put an empty 'local_recipient_maps =' in postfix's >> main.cf. > > The correct solution is to point that parameter at a map containing > all your valid users. > > Often this is caused by listing a virtual_mailbox_domain in > mydestination. Don't do that. > > >> I do wonder about the security implications of setting this >> option. If I understand the documentation correctly it isn't wise to >> set this option to empty. Is this correct? Besides the information >> below I can't find much information about this option.Thanks in >> advance! > > Accepting mail for undeliverable recipients will cause postfix to send > non-delivery notices -- bounces -- to the reported envelope sender. > > The envelope sender on spam is frequently either a non-working address > or an innocent third party. > > This has two results; your queue is filled with undeliverable bounces, > and you send bounces to innocent third parties. The full queue will > badly affect delivery of legit mail, and the backscatter you send to > innocent people will get you blacklisted. > > Rejecting the mail during the initial SMTP session avoids these problems. > > -- Noel Jones Postfix provides many different mechanisms to access different formats of tables and/or define policy agents that can check things like this, even if the database is part of another software package. For example, I have my user database in the vpostmaster package and my smtpd_recipient_restrictions include (directly after the permit_sasl_authenticated and permit_mynetworks), check_recipient_access proxy:pgsql:/etc/postfix/vpm_recipient_access The file vpm_recipient_access contains a single rather complex nested postgres sql statement which checks the data base and verifies both the existance of the domain and username on the local mail server. It then returns DUNNO if the recipient address is valid or "REJECT No such domain %d" or "REJECT No such user %u in domain %d" You could also, of course, implement this with simple berkely db files, or by writing a policy agent. Previously the vpostmaster policy daemon was validating the recipients, however I moved this into the postfix sql interface because it is much faster and causes sooner rejection of bad reciepients in the smtpd session, increasing the performance of my mail server. Nataraj Nataraj
From: Aniruddha on 15 May 2010 07:15 On Thu, May 13, 2010 at 8:19 PM, Nataraj <incoming-postfix(a)rjl.com> wrote: > Noel Jones wrote: >> >> On 5/12/2010 1:56 AM, Aniruddha wrote: >>> >>> Hi, >>> >>> I have set up postfix with a mail_transport to Zarafa. To fix an ' >>> Recipient address rejected: User unknown in local recipient table' >>> error I have to put an empty 'local_recipient_maps =' in postfix's >>> main.cf. >> >> The correct solution is to point that parameter at a map containing all >> your valid users. >> >> Often this is caused by listing a virtual_mailbox_domain in mydestination. >> Don't do that. >> >> >>> I do wonder about the security implications of setting this >>> option. If I understand the documentation correctly it isn't wise to >>> set this option to empty. Is this correct? Besides the information >>> below I can't find much information about this option.Thanks in >>> advance! >> >> Accepting mail for undeliverable recipients will cause postfix to send >> non-delivery notices -- bounces -- to the reported envelope sender. >> >> The envelope sender on spam is frequently either a non-working address or >> an innocent third party. >> >> This has two results; your queue is filled with undeliverable bounces, and >> you send bounces to innocent third parties. The full queue will badly >> affect delivery of legit mail, and the backscatter you send to innocent >> people will get you blacklisted. >> >> Rejecting the mail during the initial SMTP session avoids these problems.. >> >> -- Noel Jones > > Postfix provides many different mechanisms to access different formats of > tables and/or define policy agents that can check things like this, even if > the database is part of another software package. For example, I have my > user database in the vpostmaster package and my smtpd_recipient_restrictions > include (directly after the permit_sasl_authenticated and > permit_mynetworks), > check_recipient_access proxy:pgsql:/etc/postfix/vpm_recipient_access > > The file vpm_recipient_access contains a single rather complex nested > postgres sql statement which checks the data base and verifies both the > existance of the domain and username on the local mail server. It then > returns DUNNO if the recipient address is valid or "REJECT No such domain > %d" or "REJECT No such user %u in domain %d" You could also, of course, > implement this with simple berkely db files, or by writing a policy agent.. > > Previously the vpostmaster policy daemon was validating the recipients, > however I moved this into the postfix sql interface because it is much > faster and causes sooner rejection of bad reciepients in the smtpd session, > increasing the performance of my mail server. > > Nataraj Thanks for the help! I understand that the main risk of setting 'local_recipient_maps =' to empty is 'bouncing unsolicited messages back to (spoofed) domains which gets you blacklisted. In the end I fixed this by pointing postfix to the mysql database where the user information is stored. Thanks again.
|
Pages: 1 Prev: Invitation to connect on LinkedIn Next: Best practice to drop spam with virtual mailboxes |