ldap_table works and doesn't...
:-) I have an openldap server for accounts and other servers use pam_ldap. We'd like to to store e-mail aliases as an LDAP `mail' attribute. A user with a common name `temp1' has the attribute `mail' set to `m.kozlow...@poczta.mini.pw.edu.pl'. Expected behavior: mail sent to `m.kozlow...@poczta.mini.pw.edu.pl' is delivered to the mailbox of `temp1'. It works and it doesn't work. `main.cf' contains the line: -- alias_maps = hash:/etc/postfix/aliases, ldap:/etc/postfix/ldap-aliases.cf -- where `/etc/postfix/ldap-aliases.cf' is as follows: -- server_host = ldaps://my_ldap_server:636 version = 3 search_base = some_container query_filter = mail=%s result_attribute = cn bind = no -- After the `RCPT TO:' command it seems to work. The log: -- 2014-08-20 20:43:10[info,mail]postfix/smtpd[30917]: dict_ldap_lookup: In dict_ldap_lookup 2014-08-20 20:43:10[info,mail]postfix/smtpd[30917]: dict_ldap_lookup: No existing connection for LDAP source /etc/postfix/ldap-aliases.cf, reopening 2014-08-20 20:43:10[info,mail]postfix/smtpd[30917]: dict_ldap_connect: Connecting to server ldaps://to_co_trzeba:636 2014-08-20 20:43:10[info,mail]postfix/smtpd[30917]: dict_ldap_connect: Actual Protocol version used is 3. 2014-08-20 20:43:10[info,mail]postfix/smtpd[30917]: dict_ldap_connect: Cached connection handle for LDAP source /etc/postfix/ldap-aliases.cf 2014-08-20 20:43:10[info,mail]postfix/smtpd[30917]: dict_ldap_lookup: /etc/postfix/ldap-aliases.cf: Searching with filter mail=m.kozlow...@poczta.mini.pw.edu.pl 2014-08-20 20:43:10[info,mail]postfix/smtpd[30917]: dict_ldap_get_values[1]: Search found 1 match(es) 2014-08-20 20:43:10[info,mail]postfix/smtpd[30917]: dict_ldap_get_values[1]: search returned 1 value(s) for requested result attribute cn 2014-08-20 20:43:10[info,mail]postfix/smtpd[30917]: dict_ldap_get_values[1]: Leaving dict_ldap_get_values 2014-08-20 20:43:10[info,mail]postfix/smtpd[30917]: dict_ldap_lookup: Search returned temp1 2014-08-20 20:43:10[info,mail]postfix/smtpd[30917]: maps_find: local_recipient_maps: ldap:/etc/postfix/ldap-aliases.cf(0,lock|fold_fix): m.kozlow...@poczta.mini.pw.edu.pl = temp1 2014-08-20 20:43:10[info,mail]postfix/smtpd[30917]: mail_addr_find: m.kozlow...@poczta.mini.pw.edu.pl - temp1 -- Seems exactly as expected. But then after `DATA' and closing the connection logs show: -- 2014-08-20 20:43:10[info,mail]postfix/local[30922]: A798714259B: to=m.kozlow...@poczta.mini.pw.edu.pl, relay=local, delay=0.23, delays=0.12/0.01/0/0.11, dsn=5.1.1, status=bounced (unknown user: m.kozlowski) 2014-08-20 20:43:10[info,mail]postfix/cleanup[30921]: C5A2D14259E: message-id=20140820184310.c5a2d142...@poczta.mini.pw.edu.pl 2014-08-20 20:43:10[info,mail]postfix/qmgr[30914]: C5A2D14259E: from=, size=3380, nrcpt=1 (queue active) 2014-08-20 20:43:10[info,mail]postfix/bounce[30923]: A798714259B: sender non-delivery notification: C5A2D14259E 2014-08-20 20:43:10[info,mail]postfix/qmgr[30914]: A798714259B: removed 2014-08-20 20:43:10[info,mail]postfix/local[30922]: C5A2D14259E: to=m.kozlow...@mini.pw.edu.pl, relay=local, delay=0.09, delays=0.01/0/0 /0.08, dsn=5.1.1, status=bounced (unknown user: m.kozlowski) 2014-08-20 20:43:10[info,mail]postfix/qmgr[30914]: C5A2D14259E: removed -- It seems it knew that this user is `temp1' and now it doesn't know?? Any idea how to deal with it welcome! Best regards, MArek
Re: ldap_table works and doesn't...
On Thu, Aug 21, 2014 at 08:54:19AM +0200, Marek Kozlowski wrote: :-) I have an openldap server for accounts and other servers use pam_ldap. We'd like to to store e-mail aliases as an LDAP `mail' attribute. A user with a common name `temp1' has the attribute `mail' set to `m.kozlow...@poczta.mini.pw.edu.pl'. Expected behavior: mail sent to `m.kozlow...@poczta.mini.pw.edu.pl' is delivered to the mailbox of `temp1'. It works and it doesn't work. `main.cf' contains the line: -- alias_maps = hash:/etc/postfix/aliases, ldap:/etc/postfix/ldap-aliases.cf -- The documented lookup key for local aliases(5) in the local(8) delivery agent is the bare localpart of the address m.kozlowski not m.kozlow...@poczta.mini.pw.edu.pl. You're likely to have more luck with LDAP-based address to address rewriting via virtual_alias_maps not alias_maps. -- 2014-08-20 20:43:10[info,mail]postfix/local[30922]: A798714259B: to=m.kozlow...@poczta.mini.pw.edu.pl, relay=local, delay=0.23, delays=0.12/0.01/0/0.11, dsn=5.1.1, status=bounced (unknown user: m.kozlowski) Exactly as expected. -- Viktor.
Re: ldap_table works and doesn't...
:-) The documented lookup key for local aliases(5) in the local(8) delivery agent is the bare localpart of the address m.kozlowski not m.kozlow...@poczta.mini.pw.edu.pl. You're likely to have more luck with LDAP-based address to address rewriting via virtual_alias_maps not alias_maps. Exactly! Thank you! /m
Re: ldap_table works and doesn't...
:-) The documented lookup key for local aliases(5) in the local(8) delivery agent is the bare localpart of the address m.kozlowski not m.kozlow...@poczta.mini.pw.edu.pl. You're likely to have more luck with LDAP-based address to address rewriting via virtual_alias_maps not alias_maps. -- 2014-08-20 20:43:10[info,mail]postfix/local[30922]: A798714259B: to=m.kozlow...@poczta.mini.pw.edu.pl, relay=local, delay=0.23, delays=0.12/0.01/0/0.11, dsn=5.1.1, status=bounced (unknown user: m.kozlowski) Exactly as expected. Of course. Rewriting only names via aliases or full addresses via virtuals solves the problem. However, just for my curiosity: Why didn't I have such error during the `RCPT TO:' phase? Why did it partially worked - solved and continued to the `DATA' phase not failed at all? Best regards, Marek
Multiple relay?
New to list, been using postfix for a little while. I would like to point a postfix install to two outbound relay's (all outbound mail to go thru them) so that, should one be unavailable, it will attempt to send via the other. Not round robin but fail over. This is probably simple, but have not found a clear description of how to. Is it as simple as adding a second IP, comma separated? Thanks.
Re: Multiple relay?
Joe Acquisto-j4: New to list, been using postfix for a little while. I would like to point a postfix install to two outbound relay's (all outbound mail to go thru them) so that, should one be unavailable, it will attempt to send via the other. Not round robin but fail over. See: http://www.postfix.org/postconf.5.html#smtp_fallback_relay Wietse This is probably simple, but have not found a clear description of how to. Is it as simple as adding a second IP, comma separated? Thanks.
Re: Multiple relay?
On Thu, Aug 21, 2014 at 12:37:33PM CEST, Joe Acquisto-j4 j...@j4computers.com said: New to list, been using postfix for a little while. I would like to point a postfix install to two outbound relay's (all outbound mail to go thru them) so that, should one be unavailable, it will attempt to send via the other. Not round robin but fail over. This is probably simple, but have not found a clear description of how to. Is it as simple as adding a second IP, comma separated? Use a local DNS with 2 MX entries myrelay.office MX 10 IP1 myrelay.office MX 20 IP2 then use relayhost=myrelay.office (without the square brackets to have a MX resolution)
Re: Multiple relay?
On Thu, Aug 21, 2014 at 01:05:51PM CEST, Erwan David er...@rail.eu.org said: On Thu, Aug 21, 2014 at 12:37:33PM CEST, Joe Acquisto-j4 j...@j4computers.com said: New to list, been using postfix for a little while. I would like to point a postfix install to two outbound relay's (all outbound mail to go thru them) so that, should one be unavailable, it will attempt to send via the other. Not round robin but fail over. This is probably simple, but have not found a clear description of how to. Is it as simple as adding a second IP, comma separated? Use a local DNS with 2 MX entries myrelay.office MX 10 IP1 myrelay.office MX 20 IP2 then use relayhost=myrelay.office (without the square brackets to have a MX resolution) Sorry for the shirtcut : the MX record must be the name of a A record and connat be an IP address.
Re: Multiple relay?
On Thu, 21 Aug 2014 13:05:51 +0200 Erwan David er...@rail.eu.org wrote: Use a local DNS with 2 MX entries myrelay.office MX 10 IP1 myrelay.office MX 20 IP2 MX record shoud point to hostname with A record.. not IP.
Re: ldap_table works and doesn't...
Marek Kozlowski: Why didn't I have such error during the `RCPT TO:' phase? Why did it partially worked - solved and continued to the `DATA' phase not failed at all? That works by accident and is not promised by any documentation, therefore you should not rely on it. Wietse
Re: ldap_table works and doesn't...
On 08/21/2014 02:03 PM, Wietse Venema wrote: Marek Kozlowski: Why didn't I have such error during the `RCPT TO:' phase? Why did it partially worked - solved and continued to the `DATA' phase not failed at all? That works by accident and is not promised by any documentation, therefore you should not rely on it. I don't. But such side-effects highly impede debugging... Best regards, Marek
Re: rewriting from and reply-to headers: milter vs canonical maps/header checks
Venkat: What I am trying to do is: Setup a SMTP relay for outgoing mail where: (a) All From: headers of the form u...@cooldomain1.com (example) are rewritten to be no-re...@cooldomain2.com (b) A Reply-To: header with the original u...@cooldomain1.com is added I have achieved this by using this combination: -- using sender_canonical_maps set to: @cooldomain1.com no-re...@cooldomain2.com -- using header_checks set to: /^From: (.*@cooldomain1\.com)/ PREPEND Reply-To:$1 This seems to work. However, I am not sure if this is a good approach or would using a milter (FILTER action in header_checks) be a better way? If so, is there a pre-existing milter available for this that is recommended? Thanks all. Your configuration should be safe, if I read Postfix documentation carefully. Remember, undocumented Postfix behavior is not covered by any promise of future compatibility. The header_checks manpage promises that PREPENDed text is not subject to header_checks or address rewriting, and that it does not affect the way that Postfix adds missing message headers. So this part of your design is safe. Does Postfix documentation promise that header_checks happen before address rewriting? It makes that promise in a non-obvious manner. The text for the REPLACE action says that the replacement text will be subject to address rewriting (among other things). This suggests that header_checks happen before address rewriting. So there is an implicit promise that header_checks happen before address rewriting. This order should probably be documented, along with the relative timing of Milter activity. Wietse
compromised mail server
Hi, I have inherited a postfix 2.6 mail server which also uses Dovecot 1.1.14 . This is basically a legacy mail server that can't be shutoff because it is now used only to forward the emails sent to a few mailboxes to the new email addresses now being used. This email server has been compromised and from what I can tell. it is sending spam from localhost. I don't know much about postfix. Any suggestions on how to fix this? We don't need the local mailboxes to be able to send messages anymore. We only want messages sent to valid mailboxes to be fowarded as per the forward rules we have setup. Thanks, Charles
Re: compromised mail server
Charles Richard: Hi, I have inherited a postfix 2.6 mail server which also uses Dovecot 1.1.14 . This is basically a legacy mail server that can't be shutoff because it is now used only to forward the emails sent to a few mailboxes to the new email addresses now being used. This email server has been compromised and from what I can tell. it is sending spam from localhost. I don't know much about postfix. Any suggestions on how to fix this? We don't need the local mailboxes to be able to send messages anymore. We only want messages sent to valid mailboxes to be fowarded as per the forward rules we have setup. Before you can stop the spam, you must find out how it enters Postfix. You will have to examine the maillog (mail.log, or whatever) file to find out if it enters via smtpd (network) or via pickup (local submission). It if arrives from the network, perhaps a user account was compromised. If it comes from a local web application, that requires different measures. Wietse
Re: compromised mail server
On 21 Aug 2014, at 14:54, Charles Richard charle...@thelearningbar.com wrote: I have inherited a postfix 2.6 mail server which also uses Dovecot 1.1.14 . This is basically a legacy mail server that can't be shutoff because it is now used only to forward the emails sent to a few mailboxes to the new email addresses now being used. This email server has been compromised and from what I can tell. it is sending spam from localhost. I don't know much about postfix. Any suggestions on how to fix this? We don't need the local mailboxes to be able to send messages anymore. We only want messages sent to valid mailboxes to be fowarded as per the forward rules we have setup. Find what is causing it, and turn off all possible ways of submission; web sites with forms, SASL authentication, and so on. You won't be needing Dovecot either, if there are no local accounts remaining. Mvg, Joni
Re: compromised mail server
Hi, See inline. Thank you! On Thu, Aug 21, 2014 at 10:02 AM, Wietse Venema wie...@porcupine.org wrote: Charles Richard: Hi, I have inherited a postfix 2.6 mail server which also uses Dovecot 1.1.14 . This is basically a legacy mail server that can't be shutoff because it is now used only to forward the emails sent to a few mailboxes to the new email addresses now being used. This email server has been compromised and from what I can tell. it is sending spam from localhost. I don't know much about postfix. Any suggestions on how to fix this? We don't need the local mailboxes to be able to send messages anymore. We only want messages sent to valid mailboxes to be fowarded as per the forward rules we have setup. Before you can stop the spam, you must find out how it enters Postfix. You will have to examine the maillog (mail.log, or whatever) file to find out if it enters via smtpd (network) or via pickup (local submission). It if arrives from the network, perhaps a user account was compromised. If it comes from a local web application, that requires different measures. How can I tell if it enters via smtpd or via pickup? The first message is see starts in the following manner: Aug 21 09:59:49 servername postfix/qmgr[28270]: 158335F: from= x...@x.com, size=2151, nrcpt=14 (queue active) Wietse
Re: compromised mail server
Charles Richard: Before you can stop the spam, you must find out how it enters Postfix. You will have to examine the maillog (mail.log, or whatever) file to find out if it enters via smtpd (network) or via pickup (local submission). It if arrives from the network, perhaps a user account was compromised. If it comes from a local web application, that requires different measures. How can I tell if it enters via smtpd or via pickup? The first message is see starts in the following manner: Aug 21 09:59:49 servername postfix/qmgr[28270]: 158335F: from= x...@x.com, size=2151, nrcpt=14 (queue active) That is NOT the first logfile message. The first logfile message is from pickup or smtpd (on some rare systems, from qmqpd). The first logfile message may be in a different logfile depending on the logfile rotation policy of your particular UNIX distribution, and on the Postfix queue file expiration policy (default 5 days). Wietse
Re: compromised mail server
Am 21.08.2014 um 15:43 schrieb Charles Richard: How can I tell if it enters via smtpd or via pickup? The first message is see starts in the following manner: Aug 21 09:59:49 servername postfix/qmgr[28270]: 158335F: from=x...@x.com mailto:x...@x.com, size=2151, nrcpt=14 (queue active) that's *not* the first line frankly qmgr is a late part of the game cat maillog | grep 158335F shows all lines belonging to that message see below, that on my machine was clearly pickup [root@mail-gw:~]$ cat maillog | grep 3hdpFP3CmgzyPZ Aug 21 03:30:01 mail-gw postfix/pickup[702]: 3hdpFP3CmgzyPZ: uid= from=* Aug 21 03:30:01 mail-gw postfix/cleanup[714]: 3hdpFP3CmgzyPZ: message-id=3hdpFP3CmgzyPZ@* Aug 21 03:30:01 mail-gw postfix/qmgr[703]: 3hdpFP3CmgzyPZ: from=*, size=1352, nrcpt=1 (queue active) Aug 21 03:30:01 mail-gw postfix/smtp[735]: 3hdpFP3CmgzyPZ: to=***, orig_to=root, relay=**, delay=0.06, delays=0.01/0.01/0.03/0.01, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as 3hdpFP3ZzDz2h) Aug 21 03:30:01 mail-gw postfix/qmgr[703]: 3hdpFP3CmgzyPZ: removed
illegal address syntax
Some mail from local (mynetworks) machines are getting mail rejected with warning: Illegal address syntax from blah in MAIL command: a b c This is despite resolve_numeric_domain = yes in main.cf, which I read was supposed to fix bad from address from scripts, etc. Wrong? joe a.
Re: illegal address syntax
On 21 Aug 2014, at 19:32, Joe Acquisto-j4 j...@j4computers.com wrote: Some mail from local (mynetworks) machines are getting mail rejected with warning: Illegal address syntax from blah in MAIL command: a b c This is despite resolve_numeric_domain = yes in main.cf, which I read was supposed to fix bad from address from scripts, etc. Wrong? Post your actual error message, please. Your reinterpretation of it strips too much information. Mvg, Joni
Re: illegal address syntax
Am 21.08.2014 um 19:32 schrieb Joe Acquisto-j4: Some mail from local (mynetworks) machines are getting mail rejected with warning: Illegal address syntax from blah in MAIL command: a b c This is despite resolve_numeric_domain = yes in main.cf, which I read was supposed to fix bad from address from scripts, etc. Wrong? who knows since you don't post real logs http://www.catb.org/esr/faqs/smart-questions.html#beprecise in general: i have not seen illegal address syntax over the last 11 years from any of my scripts or software used inhouse and would throw away any device not fixable
Re: illegal address syntax
Well, I can tell you it is SuSe 10, postfix 2.5 (mumble). Beyond that, I cannot divulge much more without running afoul of local security concerns. The author of the reporting scripts is reluctant, but willing, to correct the known issues, but I was hoping for some simple change that would ignore any syntax problem in the from address of email, from local/trusted sources, as this is likely to surface again as time goes on. Thanks for any assistance you can provide. li...@rhsoft.net li...@rhsoft.net 08/21/14 1:45 PM Am 21.08.2014 um 19:32 schrieb Joe Acquisto-j4: Some mail from local (mynetworks) machines are getting mail rejected with warning: Illegal address syntax from blah in MAIL command: a b c This is despite resolve_numeric_domain = yes in main.cf, which I read was supposed to fix bad from address from scripts, etc. Wrong? who knows since you don't post real logs http://www.catb.org/esr/faqs/smart-questions.html#beprecise in general: i have not seen illegal address syntax over the last 11 years from any of my scripts or software used inhouse and would throw away any device not fixable
Re: illegal address syntax
Please excuse the top posting, if that offends, as I am forced to use a web client that cannot bottom post. Easily. Here it is, only a bit obfuscated: Aug 21 13:18:07 some_machine postfix/smtpd[23306]: warning: Illegal address syntax from somehost.domedomain[aa.bb.cc.dd] in MAIL command: A Web server Script That's all there is on that line. Thanks for the assistance. joe a. DTNX Postmaster postmas...@dtnx.net 08/21/14 1:52 PM On 21 Aug 2014, at 19:32, Joe Acquisto-j4 j...@j4computers.com wrote: Some mail from local (mynetworks) machines are getting mail rejected with warning: Illegal address syntax from blah in MAIL command: a b c This is despite resolve_numeric_domain = yes in main.cf, which I read was supposed to fix bad from address from scripts, etc. Wrong? Post your actual error message, please. Your reinterpretation of it strips too much information. Mvg, Joni
Re: illegal address syntax
On 21 Aug 2014, at 20:04, Joe Acquisto-j4 j...@j4computers.com wrote: Please excuse the top posting, if that offends, as I am forced to use a web client that cannot bottom post. Easily. Here it is, only a bit obfuscated: Aug 21 13:18:07 some_machine postfix/smtpd[23306]: warning: Illegal address syntax from somehost.domedomain[aa.bb.cc.dd] in MAIL command: A Web server Script That's all there is on that line. Thanks for the assistance. No spaces allowed in the address, for one. Mvg, Joni
Re: illegal address syntax
Am 21.08.2014 um 19:52 schrieb Joe Acquisto-j4: Well, I can tell you it is SuSe 10, postfix 2.5 (mumble). Beyond that, I cannot divulge much more without running afoul of local security concerns. so then you are at your own learn to strip only what you *really* need to strip/mask well, and if you mask things do it consistent how do you imagine help with no information? The author of the reporting scripts is reluctant, but willing, to correct the known issues, but I was hoping for some simple change that would ignore any syntax problem in the from address of email, from local/trusted sources, as this is likely to surface again as time goes on. sloppy attitude the way to go is fix issues and not seek how to hide them Thanks for any assistance you can provide. li...@rhsoft.net li...@rhsoft.net 08/21/14 1:45 PM Am 21.08.2014 um 19:32 schrieb Joe Acquisto-j4: Some mail from local (mynetworks) machines are getting mail rejected with warning: Illegal address syntax from blah in MAIL command: a b c This is despite resolve_numeric_domain = yes in main.cf, which I read was supposed to fix bad from address from scripts, etc. Wrong? who knows since you don't post real logs http://www.catb.org/esr/faqs/smart-questions.html#beprecise in general: i have not seen illegal address syntax over the last 11 years from any of my scripts or software used inhouse and would throw away any device not fixable
Re: illegal address syntax
Joe Acquisto-j4: Well, I can tell you it is SuSe 10, postfix 2.5 (mumble). Beyond that, I cannot divulge much more without running afoul of local security concerns. The author of the reporting scripts is reluctant, but willing, to correct the known issues, but I was hoping for some simple change that would ignore any syntax problem in the from address of email, from local/trusted sources, as this is likely to surface again as time goes on. Postfix tolerates many mistakes, but it won't parse an address with unquoted whitespace. There is a limit to what I consider reasonable. People who run Postfix 2.8 or later can use smtpd_command_filter (http://www.postfix.org/postconf.5.html#smtpd_command_filter) to make minor corrections before Postfix parses command input. The documentation shows some examples. Something like: /^RCPT\s+TO:([^[:space:]]+ .+)@([^[:space:]]+.*)/ RCPT TO:$1@$2 would deal with unquoted spaces in an address. One can make it more precise if needed; that's left as an exercise for the reader. Wietse
Re: illegal address syntax
Thanks. We understood that the white space was at least the largest part of the issue, but since this setup was a replacement mail router for different mail system, which tolerated the white space, we were looking to make this change over as transparent to end users, even programmers, as painless as possible. Since we inflicted this burden on the apps community we were attempting to be as fraternal as possible. Seems to require a certain masochism on our part. g As you say, tho, there are limits. joe a. Wietse Venema wie...@porcupine.org 08/21/14 2:36 PM Joe Acquisto-j4: Well, I can tell you it is SuSe 10, postfix 2.5 (mumble). Beyond that, I cannot divulge much more without running afoul of local security concerns. The author of the reporting scripts is reluctant, but willing, to correct the known issues, but I was hoping for some simple change that would ignore any syntax problem in the from address of email, from local/trusted sources, as this is likely to surface again as time goes on. Postfix tolerates many mistakes, but it won't parse an address with unquoted whitespace. There is a limit to what I consider reasonable. People who run Postfix 2.8 or later can use smtpd_command_filter (http://www.postfix.org/postconf.5.html#smtpd_command_filter) to make minor corrections before Postfix parses command input. The documentation shows some examples. Something like: /^RCPT\s+TO:([^[:space:]]+ .+)@([^[:space:]]+.*)/ RCPT TO:$1@$2 would deal with unquoted spaces in an address. One can make it more precise if needed; that's left as an exercise for the reader. Wietse
Re: rewriting from and reply-to headers: milter vs canonical maps/header checks
Thank you very much for the detailed explanation Wietse, it makes more sense to me now re: the order of operations. Cheers, VM On Aug 21, 2014 5:31 AM, Wietse Venema wie...@porcupine.org wrote: Venkat: What I am trying to do is: Setup a SMTP relay for outgoing mail where: (a) All From: headers of the form u...@cooldomain1.com (example) are rewritten to be no-re...@cooldomain2.com (b) A Reply-To: header with the original u...@cooldomain1.com is added I have achieved this by using this combination: -- using sender_canonical_maps set to: @cooldomain1.com no-re...@cooldomain2.com -- using header_checks set to: /^From: (.*@cooldomain1\.com)/ PREPEND Reply-To:$1 This seems to work. However, I am not sure if this is a good approach or would using a milter (FILTER action in header_checks) be a better way? If so, is there a pre-existing milter available for this that is recommended? Thanks all. Your configuration should be safe, if I read Postfix documentation carefully. Remember, undocumented Postfix behavior is not covered by any promise of future compatibility. The header_checks manpage promises that PREPENDed text is not subject to header_checks or address rewriting, and that it does not affect the way that Postfix adds missing message headers. So this part of your design is safe. Does Postfix documentation promise that header_checks happen before address rewriting? It makes that promise in a non-obvious manner. The text for the REPLACE action says that the replacement text will be subject to address rewriting (among other things). This suggests that header_checks happen before address rewriting. So there is an implicit promise that header_checks happen before address rewriting. This order should probably be documented, along with the relative timing of Milter activity. Wietse
Automated personal whitelist (?)
Is there anything which is either a part of, or that works with Postfix that is capable of automagically maintaining a personal whitelist of specific e-mail addresses, to which a given user has previously sent outbound e-mail? To be clear, although I have the local Postfix configured to use many different public blacklists, and also some local domain-based blacklists (in which I have blacklisted all of yahoo.com, for example) what I am looking for is something that would effectively override all those filters for specific e-mail addresses that I have previously sent outbound mail to, e.g. myrfriend...@yahoo.com. I'm guessing that I am far from the first person to have wanted such a thing, but has it already been built? Regards, rfg P.S. I am agnostic with respect to the level of specificity required. For example if I sent something to myrfriend...@yahoo.com and then that address became whitelisted for _all_ local recipient addrsses, I think that would acceptable, even if (as should be obvious) it might possibly be better to have that address only be _selectively_ whitelisted, i.e. just for r...@tristatelogic.com. Either way, an automated whitelisting thing would be useful... ... but only if it works with Postfix.
Apply a redirect before checking other restrictions
I want to rewrite the envelope recipient of a message if it's from a specific sender, but have that rewrite change the envelope before reaching permit_auth_destination (i.e., an immediate, before-queue rewrite). I want this so that I don't have to allow open relay from a given address just to bypass relay restrictions that don't apply anyway because the mail will ultimately redirect to an address within mydestinations. The sender can't authenticate itself, so I'm a bit stuck. Is the above possible?
Re: Automated personal whitelist (?)
On 8/21/2014 4:03 PM, Ronald F. Guilmette wrote: Is there anything which is either a part of, or that works with Postfix that is capable of automagically maintaining a personal whitelist of specific e-mail addresses, to which a given user has previously sent outbound e-mail? To be clear, although I have the local Postfix configured to use many different public blacklists, and also some local domain-based blacklists (in which I have blacklisted all of yahoo.com, for example) what I am looking for is something that would effectively override all those filters for specific e-mail addresses that I have previously sent outbound mail to, e.g. myrfriend...@yahoo.com. I'm guessing that I am far from the first person to have wanted such a thing, but has it already been built? Regards, rfg P.S. I am agnostic with respect to the level of specificity required. For example if I sent something to myrfriend...@yahoo.com and then that address became whitelisted for _all_ local recipient addrsses, I think that would acceptable, even if (as should be obvious) it might possibly be better to have that address only be _selectively_ whitelisted, i.e. just for r...@tristatelogic.com. Either way, an automated whitelisting thing would be useful... ... but only if it works with Postfix. amavisd-new has a penpals feature that integrates nicely with postfix as a pre-queue smtpd_proxy_filter, or a post-queue content_filter. I don't use this particular feature, but amavisd-new is solid software. http://www.ijs.si/software/amavisd/ As an alternative, I don't suppose it would be much trouble to convince fail2ban to add outbound email addresses to a database to use as a postfix check_sender_access map. But I don't know of any existing fail2ban filters for that. This would still be subject to spoofing. -- Noel Jones
Re: Automated personal whitelist (?)
Dear Noel, I think this is a nice feature you ask there. If I follow you, you would request that each time you send an e-mail to a recipient, this recipient has to be automatically whitelisted for whatever email he would send you in the futur. Right? I'll think about an implementation of that in my greylister... Best regards, Nicolas Le 21/08/2014 23:30, Noel Jones a écrit : On 8/21/2014 4:03 PM, Ronald F. Guilmette wrote: Is there anything which is either a part of, or that works with Postfix that is capable of automagically maintaining a personal whitelist of specific e-mail addresses, to which a given user has previously sent outbound e-mail? To be clear, although I have the local Postfix configured to use many different public blacklists, and also some local domain-based blacklists (in which I have blacklisted all of yahoo.com, for example) what I am looking for is something that would effectively override all those filters for specific e-mail addresses that I have previously sent outbound mail to, e.g. myrfriend...@yahoo.com. I'm guessing that I am far from the first person to have wanted such a thing, but has it already been built? Regards, rfg P.S. I am agnostic with respect to the level of specificity required. For example if I sent something to myrfriend...@yahoo.com and then that address became whitelisted for _all_ local recipient addrsses, I think that would acceptable, even if (as should be obvious) it might possibly be better to have that address only be _selectively_ whitelisted, i.e. just for r...@tristatelogic.com. Either way, an automated whitelisting thing would be useful... ... but only if it works with Postfix. amavisd-new has a penpals feature that integrates nicely with postfix as a pre-queue smtpd_proxy_filter, or a post-queue content_filter. I don't use this particular feature, but amavisd-new is solid software. http://www.ijs.si/software/amavisd/ As an alternative, I don't suppose it would be much trouble to convince fail2ban to add outbound email addresses to a database to use as a postfix check_sender_access map. But I don't know of any existing fail2ban filters for that. This would still be subject to spoofing. -- Noel Jones attachment: hahnn.vcf
Re: Apply a redirect before checking other restrictions
On Thu, Aug 21, 2014 at 02:22:46PM -0700, Darren Pilgrim wrote:
I want to rewrite the envelope recipient of a message if it's from a
specific sender, but have that rewrite change the envelope before reaching
permit_auth_destination (i.e., an immediate, before-queue rewrite). I want
this so that I don't have to allow open relay from a given address just to
bypass relay restrictions that don't apply anyway because the mail will
ultimately redirect to an address within mydestinations.
The sender can't authenticate itself, so I'm a bit stuck. Is the above
possible?
There's no need for this.
main.cf:
indexed = ${default_database_type}:${config_directory}/
smtpd_restrictions_classes = redirect_sender
redirect_sender =
check_sender_access ${indexed}sender-redirect
smtpd_recipient_restrictions =
permit_mynetworks,
permit_sasl_authenticated,
check_sender_access ${indexed}redirected-senders,
reject_unauth_destination,
...
sender-redirect:
j...@example.commoe@local.example
redirected-senders:
j...@example.comredirect_sender, permit
Just make sure that new senders are added to sender-redirect before
redirected-senders, and removed after.
--
Viktor.
Re: Automated personal whitelist (?)
On 8/21/2014 4:03 PM, Ronald F. Guilmette wrote: Is there anything which is either a part of, or that works with Postfix that is capable of automagically maintaining a personal whitelist of specific e-mail addresses, to which a given user has previously sent outbound e-mail? To be clear, although I have the local Postfix configured to use many different public blacklists, and also some local domain-based blacklists (in which I have blacklisted all of yahoo.com, for example) what I am looking for is something that would effectively override all those filters for specific e-mail addresses that I have previously sent outbound mail to, e.g. myrfriend...@yahoo.com. I wouldn't recommend this, because many spam zombies access the sender/victim's MUA settings, and they spew to addresses in the address book, AS the sender/victim. But I'm sure you know this. On Thu, Aug 21, 2014 at 04:30:38PM -0500, Noel Jones wrote: amavisd-new has a penpals feature that integrates nicely with postfix as a pre-queue smtpd_proxy_filter, or a post-queue content_filter. I don't use this particular feature, but amavisd-new is solid software. http://www.ijs.si/software/amavisd/ As an alternative, I don't suppose it would be much trouble to convince fail2ban to add outbound email addresses to a database to use as a postfix check_sender_access map. But I don't know of any existing fail2ban filters for that. This would still be subject to spoofing. To me, this sounds more like a policy service feature (or that it should be, I mean.) Check the SASL username and sender address, to whitelist the recipient's reply. I don't know if any of the existing projects (such as cbpolicyd or postfwd) can do this easily, but it shouldn't be hard to add. -- http://rob0.nodns4.us/ Offlist GMX mail is seen only if /dev/rob0 is in the Subject:
Re: Automated personal whitelist (?)
Ronald F. Guilmette: P.S. I am agnostic with respect to the level of specificity required. For example if I sent something to myrfriend...@yahoo.com and then that address became whitelisted for _all_ local recipient addrsses, I think that would acceptable, even if (as should be obvious) it might possibly be better to have that address only be _selectively_ whitelisted, i.e. just for r...@tristatelogic.com. Either way, an automated whitelisting thing would be useful... ... but only if it works with Postfix. Amavisd has a pen pals feature that should work with smtpd_proxy_filter. This requires a shared read/write database (MySQL, I believe). In the case of a Postfix-only solution, whitelist updates could be generated by mis-using smtp_generic_maps, relocated_maps, etc. (add an address if it isn't already known) and they could be queried with check_sender_access (look up a known address). Before lmdb support was added in Postfix 2.11, there was no good way to safely share a persistent Postfix database between read-only processes and read/write processes. So, it should be no surprise that there at thius time no Postfix features that share a database between read/write clients (smtp_generic_maps, relocated_maps, etc.) and read-only clients (check_sender_access). Wietse
Re: Automated personal whitelist (?)
In message 53f664fe.1030...@megan.vbhcs.org, Noel Jones njo...@megan.vbhcs.org wrote: amavisd-new has a penpals feature that integrates nicely with postfix as a pre-queue smtpd_proxy_filter, or a post-queue content_filter. I don't use this particular feature, but amavisd-new is solid software. http://www.ijs.si/software/amavisd/ Hummm... What I had in mind was something rather a lot less heavyweight. I'd prefer not to have to install a whole separate (sizable) monster whose primary purposes isn't even related to the kind of whitelisting I asked about. As an alternative, I don't suppose it would be much trouble to convince fail2ban to add outbound email addresses to a database to use as a postfix check_sender_access map. OK. Not that this is at all relevant to me personally, or to my own (small) local mail setup, but... Question: Assuming that something like that was built, and then deployed on a server with thousands or tens of thousands of e-mail users... How well would it scale? (Just curious.) I'm just wondering about the effects of constant frequent diddling of a data base that Postfix is using to make decisions. This would still be subject to spoofing. Yes, but that possibility really doesn't worry me much. In order to be useful, to spammers, they would have to find some e-mail addresses that _lots_ of people have previously whitelisted (by virtue of their having all sent e-mail to that address). Seems rather difficult and probably not worthwhile... for the spammers.
Re: Automated personal whitelist (?)
In message 20140821215806.gx23...@harrier.slackbuilds.org, /dev/rob0 r...@gmx.co.uk wrote: I wouldn't recommend this, because many spam zombies access the sender/victim's MUA settings, and they spew to addresses in the address book, AS the sender/victim. But I'm sure you know this. I do, and I do not think that the phenomenon you have described renders the general idea of automated whitelist maintenance entirely un-useful. Certainly if the evil spammers manage to get into the address books of any of my personal correspondants, then (with automated whitelisting) they could then spoof those people in order to spam me. But I do think that this would be more the exception than the rule, and also, in case it was not already apparent, a good automated whitelist system should include some sort of revocation feature, in order to allow for exactly such unfortunate (but rare) possibilities (and others). To me, this sounds more like a policy service feature (or that it should be, I mean.) Check the SASL username and sender address, to whitelist the recipient's reply. That sounds about right to me. I don't know if any of the existing projects (such as cbpolicyd or postfwd) can do this easily, but it shouldn't be hard to add. So, nothing already exists along these lines? Regards, rfg P.S. There are certainly sites... mine included... that eschew the complexity of SASL and find in utterly unnecessary and superfluous in the limited local context. (Trust, including the capability to send outbound, is, in my local context, limited to 127.0.0.1 and the RFC 1918 addresses.) I only mention this to emphasize that an optimal solution... should anyone be motivated to venture forth and create one... would not and should not assume that local senders/recipients will be logging in to the local mail server (e.g. via SASL).
Re: Automated personal whitelist (?)
In message 3hfkyf2ty9zj...@spike.porcupine.org, wie...@porcupine.org (Wietse Venema) wrote: Either way, an automated whitelisting thing would be useful... ... but only if it works with Postfix. Amavisd has a pen pals feature that should work with smtpd_proxy_filter. This requires a shared read/write database (MySQL, I believe). As I've mentioned, that seems a bit too heavyweight for my tastes. In the case of a Postfix-only solution, whitelist updates could be generated by mis-using smtp_generic_maps, relocated_maps, etc. (add an address if it isn't already known) Could you be induced to elaborate on the above comment, hopefully at length? I've never used either of those things you mentioned and have no idea how they might be profitably applied to this problem. and they could be queried with check_sender_access (look up a known address). This part, at least, I can easily grok. Before lmdb support was added in Postfix 2.11, there was no good way to safely share a persistent Postfix database between read-only processes and read/write processes. Ah! Yes! For what I am talking about, that exact kind of sharing would quite obviously be most helpful. So, it should be no surprise that there at thius time no Postfix features that share a database between read/write clients (smtp_generic_maps, relocated_maps, etc.) and read-only clients (check_sender_access). Eh? I could not quite parse that. Regards, rfg P.S. I guess that the kind of thing I'm thinking of (an automated whitelisting system, perhaps even with per user data bases) could be done within an external policy daemon. But then again, it often seems to me that virtually every Swell New Idea I think of can likewise be implemented in an external Postfix policy daemon. I'm not sure if that is a tribute to the excellent flexibility of the whole policy daemon concept, or to the meager nature of most of my Swell Ideas. (1/2 :-)
Re: Automated personal whitelist (?)
On Thu, Aug 21, 2014 at 03:51:05PM -0700, Ronald F. Guilmette wrote: In message 20140821215806.gx23...@harrier.slackbuilds.org, /dev/rob0 r...@gmx.co.uk wrote: I don't know if any of the existing projects (such as cbpolicyd or postfwd) can do this easily, but it shouldn't be hard to add. So, nothing already exists along these lines? I'm not experienced enough with either project to answer that. P.S. There are certainly sites... mine included... that eschew the complexity of SASL and find in utterly unnecessary and superfluous in the limited local context. (Trust, including the capability to send outbound, is, in my local context, limited to 127.0.0.1 and the RFC 1918 addresses.) I only mention this to emphasize that an optimal solution... should anyone be motivated to venture forth and create one... would not and should not assume that local senders/recipients will be logging in to the local mail server (e.g. via SASL). I only mention SASL in the context of know who is sending this. Similar results can be had without SASL; just be sure your MX (inbound) stream is completely separate from your submission (outbound) stream. SASL username is one of many attributes which can be examined by policy services. Others include client IP address, envelope sender and recipient, HELO name, and more. For complete details, see: http://www.postfix.org/SMTPD_POLICY_README.html With a client IP from RFC 1918, you could, for example, assign your users specified HELO names, giving you two layers of proof of identity. -- http://rob0.nodns4.us/ Offlist GMX mail is seen only if /dev/rob0 is in the Subject:
Re: Automated personal whitelist (?)
Ronald F. Guilmette: In the case of a Postfix-only solution, whitelist updates could be generated by mis-using smtp_generic_maps, relocated_maps, etc. (add an address if it isn't already known) Could you be induced to elaborate on the above comment, hopefully at length? With a socketmap daemon: /etc/postfix/main.cf: relocated_maps = socketmap:inet:host:port:name relocated_maps = socketmap:unix:pathname:name This queries relocated_maps for every envelope recipient before email delivery. You provide a server that runs on the specified TCP host and port (or UNIX-domain socket) that speaks the socketmap protocol, and that answers all queries with not found. The socketmap protocol is described in the socketmap_table(5) manpage. There is a Python socketmap implementation. This server maintains a persistent database, adding an (address, suitable Postfix access map reply, see below) entry if the database entry does not already exist. The database could be MySQL, LMDB, but not any version of Berkeley DB 1.85 because that does not work with Postfix locks. The database is queried with check_sender_access, and returns the suitable reply value that was stored by the socketmap server. If you use an MySQL database then your server can also maintain a last update time-stamp field with each address and reply so that an inactive address can be recognized as too old. When an active address entry is mid-way towards expiration, the socketmap server updates the time stamp to prevent the address from becoming too old. If you use an LMDB database then your server has to implement the Postfix external locking protocol as described in lmdb_table(5). LMDB built-in locks are not suitable (they require a world-writable lockfile, and that would violate the Postfix security model). Wietse
Re: Automated personal whitelist (?)
Wietse Venema: Ronald F. Guilmette: In the case of a Postfix-only solution, whitelist updates could be generated by mis-using smtp_generic_maps, relocated_maps, etc. (add an address if it isn't already known) Could you be induced to elaborate on the above comment, hopefully at length? With a socketmap daemon: /etc/postfix/main.cf: relocated_maps = socketmap:inet:host:port:name relocated_maps = socketmap:unix:pathname:name This queries relocated_maps for every envelope recipient before email delivery. You provide a server that runs on the specified TCP host and port (or UNIX-domain socket) that speaks the socketmap protocol, and that answers all queries with not found. The socketmap protocol is described in the socketmap_table(5) manpage. There is a Python socketmap implementation. This server maintains a persistent database, adding an (address, suitable Postfix access map reply, see below) entry if the database entry does not already exist. The database could be MySQL, LMDB, but not any version of Berkeley DB 1.85 because that does not work with Postfix locks. This suitable reply can be a time stamp of the last database update for that address. Postfix treats an all-numerical field as OK. Then, you can do the proactive refresh as described below with any database type. Wietse The database is queried with check_sender_access, and returns the suitable reply value that was stored by the socketmap server. If you use an MySQL database then your server can also maintain a last update time-stamp field with each address and reply so that an inactive address can be recognized as too old. When an active address entry is mid-way towards expiration, the socketmap server updates the time stamp to prevent the address from becoming too old. If you use an LMDB database then your server has to implement the Postfix external locking protocol as described in lmdb_table(5). LMDB built-in locks are not suitable (they require a world-writable lockfile, and that would violate the Postfix security model). Wietse
Re: Apply a redirect before checking other restrictions
On 8/21/2014 2:49 PM, Viktor Dukhovni wrote:
On Thu, Aug 21, 2014 at 02:22:46PM -0700, Darren Pilgrim wrote:
I want to rewrite the envelope recipient of a message if it's from a
specific sender, but have that rewrite change the envelope before reaching
permit_auth_destination (i.e., an immediate, before-queue rewrite). I want
this so that I don't have to allow open relay from a given address just to
bypass relay restrictions that don't apply anyway because the mail will
ultimately redirect to an address within mydestinations.
The sender can't authenticate itself, so I'm a bit stuck. Is the above
possible?
There's no need for this.
main.cf:
indexed = ${default_database_type}:${config_directory}/
smtpd_restrictions_classes = redirect_sender
redirect_sender =
check_sender_access ${indexed}sender-redirect
smtpd_recipient_restrictions =
permit_mynetworks,
permit_sasl_authenticated,
check_sender_access ${indexed}redirected-senders,
reject_unauth_destination,
...
sender-redirect:
j...@example.com moe@local.example
redirected-senders:
j...@example.com redirect_sender, permit
Just make sure that new senders are added to sender-redirect before
redirected-senders, and removed after.
That's exactly the hack I was hoping to avoid. I guess Postfix can't do
before-queue envelope rewriting?
