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=, 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=, 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 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 said: > On Thu, Aug 21, 2014 at 12:37:33PM CEST, Joe Acquisto-j4 > 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 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 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 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=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=, 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: " 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 wrote: > Some mail from local (mynetworks) machines are getting mail rejected with > "warning: Illegal address syntax from blah in MAIL command: " > 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: " > 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" 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: " > 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: " That's all there is on that line. Thanks for the assistance. joe a. >>> DTNX Postmaster 08/21/14 1:52 PM >>> On 21 Aug 2014, at 19:32, Joe Acquisto-j4 wrote: > Some mail from local (mynetworks) machines are getting mail rejected with > "warning: Illegal address syntax from blah in MAIL command: " > 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 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: 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" 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: " >> 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. As you say, tho, there are limits. joe a. >>> Wietse Venema 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" 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. . 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 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 . 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. . > > 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 > 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 . > > 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. . 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 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 . 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: 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. . 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 > 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 . > > 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 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 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 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?
