Re: mysql local_recipient_map
I changed the line hosts = server-1.example.com to use an IP address instead hosts = 192.168.1.200 and everything started working. Does anyone know what I am missing in that it seems postfix did resolve the IP address when communicating with the mysql database? On 06/13/2016 07:52 PM, Paul R. Ganci wrote: I have setup a mysql data baseto provide a list of of local email recipients for a gateway email server. The configuration file looks like this: > cat /etc/postfix/local_recipient_map.cf user = postfix password = Secret hosts = server-1.example.com dbname = postfix query = SELECT destination FROM postfix_virtual WHERE email = '%s' If I do a test query ala: > postmap -q sa...@example.com mysql:/etc/postfix/local_recipient_map.cf sallysemail This last command seems to indicate that the query completes successfully. So I then configured the main.cf per this extracted stanza: # REJECTING MAIL FOR UNKNOWN LOCAL USERS # # The local_recipient_maps parameter specifies optional lookup tables # with all names or addresses of users that are local with respect # to $mydestination, $inet_interfaces or $proxy_interfaces. # # If this parameter is defined, then the SMTP server will reject # mail for unknown local users. This parameter is defined by default. # # To turn off local recipient checking in the SMTP server, specify # local_recipient_maps = (i.e. empty). # # The default setting assumes that you use the default Postfix local # delivery agent for local delivery. You need to update the # local_recipient_maps setting if: # # - You define $mydestination domain recipients in files other than # /etc/passwd, /etc/aliases, or the $virtual_alias_maps files. # For example, you define $mydestination domain recipients in # the $virtual_mailbox_maps files. # # - You redefine the local delivery agent in master.cf. # # - You redefine the "local_transport" setting in main.cf. # # - You use the "luser_relay", "mailbox_transport", or "fallback_transport" # feature of the Postfix local delivery agent (see local(8)). # # Details are described in the LOCAL_RECIPIENT_README file. # # Beware: if the Postfix SMTP server runs chrooted, you probably have # to access the passwd file via the proxymap service, in order to # overcome chroot restrictions. The alternative, having a copy of # the system passwd file in the chroot jail is just not practical. # # The right-hand side of the lookup tables is conveniently ignored. # In the left-hand side, specify a bare username, an @domain.tld # wild-card, or specify a u...@domain.tld address. # #local_recipient_maps = unix:passwd.byname $alias_maps #local_recipient_maps = proxy:unix:passwd.byname $alias_maps #local_recipient_maps = #local_recipient_maps = local_recipient_maps = mysql:/etc/postfix/local_recipient_map.cf However after I issue >postfix reload I get the following warning in the /var/log/maillog file: Jun 13 17:02:33 mx02 postfix/smtpd[24400]: warning: mysql:/etc/postfix/local_recipient_map.cf lookup error for "sa...@example.com" Jun 13 17:02:33 mx02 postfix/smtpd[24400]: NOQUEUE: reject: RCPT from unknown[50.31.61.193]: 451 4.3.0: Temporary lookup failure; from= to= proto=ESMTP helo= Can somebody tell me what I am doing wrong? Why does the postmap -q command line query successfully return a result but fail from postfix? Thank you for your help. -- Paul (ga...@nurdog.com) Cell: (303)257-5208
mysql local_recipient_map
I have setup a mysql data baseto provide a list of of local email recipients for a gateway email server. The configuration file looks like this: > cat /etc/postfix/local_recipient_map.cf user = postfix password = Secret hosts = server-1.example.com dbname = postfix query = SELECT destination FROM postfix_virtual WHERE email = '%s' If I do a test query ala: > postmap -q sa...@example.com mysql:/etc/postfix/local_recipient_map.cf sallysemail This last command seems to indicate that the query completes successfully. So I then configured the main.cf per this extracted stanza: # REJECTING MAIL FOR UNKNOWN LOCAL USERS # # The local_recipient_maps parameter specifies optional lookup tables # with all names or addresses of users that are local with respect # to $mydestination, $inet_interfaces or $proxy_interfaces. # # If this parameter is defined, then the SMTP server will reject # mail for unknown local users. This parameter is defined by default. # # To turn off local recipient checking in the SMTP server, specify # local_recipient_maps = (i.e. empty). # # The default setting assumes that you use the default Postfix local # delivery agent for local delivery. You need to update the # local_recipient_maps setting if: # # - You define $mydestination domain recipients in files other than # /etc/passwd, /etc/aliases, or the $virtual_alias_maps files. # For example, you define $mydestination domain recipients in # the $virtual_mailbox_maps files. # # - You redefine the local delivery agent in master.cf. # # - You redefine the "local_transport" setting in main.cf. # # - You use the "luser_relay", "mailbox_transport", or "fallback_transport" # feature of the Postfix local delivery agent (see local(8)). # # Details are described in the LOCAL_RECIPIENT_README file. # # Beware: if the Postfix SMTP server runs chrooted, you probably have # to access the passwd file via the proxymap service, in order to # overcome chroot restrictions. The alternative, having a copy of # the system passwd file in the chroot jail is just not practical. # # The right-hand side of the lookup tables is conveniently ignored. # In the left-hand side, specify a bare username, an @domain.tld # wild-card, or specify a u...@domain.tld address. # #local_recipient_maps = unix:passwd.byname $alias_maps #local_recipient_maps = proxy:unix:passwd.byname $alias_maps #local_recipient_maps = #local_recipient_maps = local_recipient_maps = mysql:/etc/postfix/local_recipient_map.cf However after I issue >postfix reload I get the following warning in the /var/log/maillog file: Jun 13 17:02:33 mx02 postfix/smtpd[24400]: warning: mysql:/etc/postfix/local_recipient_map.cf lookup error for "sa...@example.com" Jun 13 17:02:33 mx02 postfix/smtpd[24400]: NOQUEUE: reject: RCPT from unknown[50.31.61.193]: 451 4.3.0: Temporary lookup failure; from= to= proto=ESMTP helo= Can somebody tell me what I am doing wrong? Why does the postmap -q command line query successfully return a result but fail from postfix? Thank you for your help.
Re: simple greylisting by geoip? milter or policy server?
list...@tutanota.com: > But then I also read that that 'Policy delegation is now the preferred method > for adding policies to Postfix.' Milter support was added later, because some things can't be done with policy servers. As for greylisting, you could use postscreen's deep protocol tests instead - those tests require that clients disconnect and come back before they can send mail. Wietse
simple greylisting by geoip? milter or policy server?
I am considering the installation of Greylisting with Postfix. I want it only for one condition, to greylist mail originating from certain countries. I use Postfix 3.1 with postscreen. I am already using milters for dkim and dmarc and a policy server for spf. So looking through the addons and some posts I came to 'milter-greylist'. milter-greylist postfix http://hcpnet.free.fr/milter-greylist It is a milter so I think it can be used in Postfix. And it has a very simple easy ability to greylist only for specific countries milter-greylist+GeoIP http://milter-greylist.wikidot.com/geoip But then I also read that that 'Policy delegation is now the preferred method for adding policies to Postfix.' (1) For such only-geoip greylisting is the milter-greylist a recommendation ? I do not want any complicated rules, only the "greylist this country" ones. (2) Is the postfix documentation saying there that we should use policy servers instead of milters? I think I am maybe not fully clear with the terminology.
Re: postfix virtual domain walking
On Mon, June 13, 2016 16:42, Wietse Venema wrote: > James B. Byrne: >> These delivery names are only found in /etc/postfix/virtual. > > What about an email "address book" on a user machine? > > Wietse > It is certainly a possibility. However, my difficulty with that explanation is that: 1. Our users employ webmail (squirrelmail) so their address books are maintained on a sealed server. There are no user accounts on it. And we run aide on it. And we have fail2ban running. And ssh is blocked at the firewall. 2. Some of these addresses like .bugzilla and .redhat are only used for bug reporting. They would be found on the respective sites but it seems to me doubtful that they would end up in a user address book. 3. If there is nothing that involves Postfix then something like what you propose must be the case. Or someone has gone to some lengths to scan for these addresses using our domain name as a search term. -- *** e-Mail is NOT a SECURE channel *** Do NOT transmit sensitive data via e-Mail Do NOT open attachments nor follow links sent by e-Mail James B. Byrnemailto:byrn...@harte-lyne.ca Harte & Lyne Limited http://www.harte-lyne.ca 9 Brockley Drive vox: +1 905 561 1241 Hamilton, Ontario fax: +1 905 561 0757 Canada L8E 3C3
Re: postfix virtual domain walking
James B. Byrne: > These delivery names are only found in /etc/postfix/virtual. What about an email "address book" on a user machine? Wietse
Re: postfix virtual domain walking
On Mon, June 13, 2016 14:25, Wietse Venema wrote: > James B. Byrne: >> However, the question arises as to how these local delivery >> addresses >> are being harvested? Some of these are used very infrequently and >> some of them have not been active for years. It seems remarkable >> that >> addresses that are known to only be used for one purpose, say >> bugzilla >> or readhat network, are found in these attacks. > > The names may have been harvested from a compromised user machine. > >> Is there some way for remote unauthenticated users to query postfix >> in >> such a fashion as to effectively walk the virtual domain list for >> local delivery addresses? If so then what is it and how can it be >> prevented. Or should it? > > As far as I know, there is no SMTP command to 'list' a local database. > That is, unless there is some kind of LDAP or SQL injection bug. > > Wietse > These delivery names are only found in /etc/postfix/virtual. There is no LDAP service or RDBMS involved whatsoever. As far as I can tell there would be no reason for any user machine to have them listed as they exist solely to map incoming mail to specific imap subfolders. It may very well be that these people attempting to break in have gone to the internet hunting for every revealed variant address. But that in itself seems even more worrying. -- *** e-Mail is NOT a SECURE channel *** Do NOT transmit sensitive data via e-Mail Do NOT open attachments nor follow links sent by e-Mail James B. Byrnemailto:byrn...@harte-lyne.ca Harte & Lyne Limited http://www.harte-lyne.ca 9 Brockley Drive vox: +1 905 561 1241 Hamilton, Ontario fax: +1 905 561 0757 Canada L8E 3C3
Re: postfix virtual domain walking
James B. Byrne: > However, the question arises as to how these local delivery addresses > are being harvested? Some of these are used very infrequently and > some of them have not been active for years. It seems remarkable that > addresses that are known to only be used for one purpose, say bugzilla > or readhat network, are found in these attacks. The names may have been harvested from a compromised user machine. > Is there some way for remote unauthenticated users to query postfix in > such a fashion as to effectively walk the virtual domain list for > local delivery addresses? If so then what is it and how can it be > prevented. Or should it? As far as I know, there is no SMTP command to 'list' a local database. That is, unless there is some kind of LDAP or SQL injection bug. Wietse
postfix virtual domain walking
We are currently subjected to a persistent penetration attempt that apparently is directed against our smtp authentication. The user names employed at the present time are all local address portions of a single user's virtual domain which have no means of authentication. So the attack is futile in that sense. However, the question arises as to how these local delivery addresses are being harvested? Some of these are used very infrequently and some of them have not been active for years. It seems remarkable that addresses that are known to only be used for one purpose, say bugzilla or readhat network, are found in these attacks. Is there some way for remote unauthenticated users to query postfix in such a fashion as to effectively walk the virtual domain list for local delivery addresses? If so then what is it and how can it be prevented. Or should it? -- *** e-Mail is NOT a SECURE channel *** Do NOT transmit sensitive data via e-Mail Do NOT open attachments nor follow links sent by e-Mail James B. Byrnemailto:byrn...@harte-lyne.ca Harte & Lyne Limited http://www.harte-lyne.ca 9 Brockley Drive vox: +1 905 561 1241 Hamilton, Ontario fax: +1 905 561 0757 Canada L8E 3C3