header_checks - replace and flip mail addreses in To field for multiple recipients
Dear Users, I'm facing a problem with the header_checks. I want to flip the domainpart / userpart in the To: field of the mail header, strip off spaces/parentheses, add a custom domainpart and replace international number scheme ++49 -> 0049. My input string is, recipients can vary - it might be only 1 or 50. To: =?windows-1252?Q?LHG_1_=28Fax_Gesch=E4ft=29?= , =?windows-1252?Q?LHG_2_=28Fax_Gesch=E4ft=29?= My output string should be: To: =?windows-1252?Q?LHG_1_=28Fax_Gesch=E4ft=29?= <004986219960237@fax.local>, =?windows-1252?Q?LHG_2_=28Fax_Gesch=E4ft=29?= <004932121150047@fax.local> I have a working pcre but that only works for a single To: field recipient: /^To:\s*(.*)<.*@\+(\d+).*?(\d+).*?(\d+)>/ To: $1 <00$2$3$4@fax.local> root@srv1:/home/stefan# postmap -q "To: =?windows-1252?Q?LHG_1_=28Fax_Gesch=E4ft=29?= , =?windows-1252?Q?LHG_2_=28Fax_Gesch=E4ft=29?= " pcre:/etc/postfix/rewrite_tofield To: =?windows-1252?Q?LHG_1_=28Fax_Gesch=E4ft=29?= , =?windows-1252?Q?LHG_2_=28Fax_Gesch=E4ft=29?= <004932121150047@fax.local> Any help is greatly appreciated. Stefan
Re: header_checks - replace and flip mail addreses in To field for multiple recipients
Am 09.06.2014 13:22, schrieb Stefan Bauer: > I'm facing a problem with the header_checks. I want to flip the domainpart / > userpart in the To: field of the mail > header, strip off spaces/parentheses, add a custom domainpart and replace > international number scheme ++49 -> 0049 header_checks can't do that you need complexer filters for such things and the manpage states that pretty clear
Re: header_checks - replace and flip mail addreses in To field for multiple recipients
Stefan Bauer: > Dear Users, > >I'm facing a problem with the header_checks. I want to flip the >domainpart / userpart in the To: field of the mail header, strip >off spaces/parentheses, add a custom domainpart and replace >international number scheme ++49 -> 0049. ... >I have a working pcre but that only works for a single To: field >recipient: As documented Postfix header_checks examines each header line once, therefore it cannot perform multiple actions on the same header line. This reflects their original purpose: to block email that was sent by malware. Wietse
DNSBL/DNSWL lookup table
Wietse Venema: > I could rip out the DNSBL client code from the Postfix SMTP daemon > source code and make it available as 1) a lookup table to all programs > 2) a library module that implements the underlying DNS client code. I played with this idea over the weekend while taking breaks from chores around the house. Here is an example: $ postmap -q 127.0.0.2 dnsxl:zen.spamhaus.org 127.0.0.4 127.0.0.10 127.0.0.2 $ postmap -q 168.100.189.2 dnsxl:list.dnswl.org 127.0.9.3 $ Instead of IP addresses it also takes queries with domain names or email addresses (in the latter case it queries with the domain portion of the email address). The lookup result contains all the IP addresses in the DNSBL/DNSWL response. Just like reject_rbl_client and reject_rhsbl_sender, this map understands filters. For example: dnsxl:list.dnswl.org=127.0.[0..255].[1..3] will return "not found" unless the result IP address matches the pattern. By itself, dnsxl maps may be useful in contexts that perform "list membership" lookup such as smtpd_client_event_limit_exceptions, where the lookup result value is ignored, For example, to prevent password brute-forcing from bot-infected systems: smtpd_client_event_limit_exceptions = dnsxl:xbl.spamhaus.org In contexts where the action depends on the content of a lookup result such as SMTPD access maps, the raw result (one or more IP addresses), would have to be transformed into a specific action such as "reject" or "permit". That requires some syntax for map stacking. Wietse
Re: DNSBL/DNSWL lookup table
Wietse Venema: > By itself, dnsxl maps may be useful in contexts that perform "list > membership" lookup such as smtpd_client_event_limit_exceptions, > where the lookup result value is ignored, For example, to prevent > password brute-forcing from bot-infected systems: > > smtpd_client_event_limit_exceptions = dnsxl:xbl.spamhaus.org Except that this does not block AUTH commands. Currently all that smtpd_client_event_limit_exceptions does is not announce AUTH support in the EHLO response. Wietse
Re: DNSBL/DNSWL lookup table
Wietse Venema schrieb: > Wietse Venema: >> By itself, dnsxl maps may be useful in contexts that perform "list >> membership" lookup such as smtpd_client_event_limit_exceptions, >> where the lookup result value is ignored, For example, to prevent >> password brute-forcing from bot-infected systems: >> >> smtpd_client_event_limit_exceptions = dnsxl:xbl.spamhaus.org > > Except that this does not block AUTH commands. Currently all that > smtpd_client_event_limit_exceptions does is not announce AUTH support > in the EHLO response. Hey thanks, I love the potential of this. But how could I block AUTH altogether then? Because that way postfix could be made stop disclosing information about wrong or false credentials to unwanted clients. BTW: Why does smtpd_client_event_limit_exceptions stop announcing AUTH commands? From the docs I would never understand that it acts this way: | smtpd_client_event_limit_exceptions (default: $mynetworks) | SMTP clients that are excluded from connection and rate limits specified | above. This sounds more like a performance tuning option. And OTOH, I'd rather not put malicious clients on that exception list... Hmm... -- Replies to list only preferred.
Re: DNSBL/DNSWL lookup table
On 06/09/2014 11:48 AM, Wietse Venema wrote: > Wietse Venema: >> By itself, dnsxl maps may be useful in contexts that perform "list >> membership" lookup such as smtpd_client_event_limit_exceptions, >> where the lookup result value is ignored, For example, to prevent >> password brute-forcing from bot-infected systems: >> >> smtpd_client_event_limit_exceptions = dnsxl:xbl.spamhaus.org > > Except that this does not block AUTH commands. Currently all that > smtpd_client_event_limit_exceptions does is not announce AUTH support > in the EHLO response. Hello Wietse, Is it possible to use this to DNSBL check URLs present in the body of an email? (pre-queue) Thank you! johnea p.s. Sorry to diverge from the topic. I hope this isn't so far off as to constitute thread hijacking.
Re: DNSBL/DNSWL lookup table
Am 09.06.2014 22:17, schrieb johnea: > On 06/09/2014 11:48 AM, Wietse Venema wrote: >> Wietse Venema: >>> By itself, dnsxl maps may be useful in contexts that perform "list >>> membership" lookup such as smtpd_client_event_limit_exceptions, >>> where the lookup result value is ignored, For example, to prevent >>> password brute-forcing from bot-infected systems: >>> >>> smtpd_client_event_limit_exceptions = dnsxl:xbl.spamhaus.org >> >> Except that this does not block AUTH commands. Currently all that >> smtpd_client_event_limit_exceptions does is not announce AUTH support >> in the EHLO response. > > Is it possible to use this to DNSBL check URLs present in the body of an > email? (pre-queue) postfix is a MTA and only a MTA which is good one tool one job you can plug contentfilters but that's not the job of postfix itself
Re: DNSBL/DNSWL lookup table
Kai Krakow: > >> smtpd_client_event_limit_exceptions = dnsxl:xbl.spamhaus.org > > > > Except that this does not block AUTH commands. Currently all that > > smtpd_client_event_limit_exceptions does is not announce AUTH support > > in the EHLO response. > > Hey thanks, I love the potential of this. But how could I block AUTH > altogether then? Because that way postfix could be made stop disclosing > information about wrong or false credentials to unwanted clients. Currently, you can turn off the AUTH announcement only. > BTW: Why does smtpd_client_event_limit_exceptions stop announcing AUTH > commands? From the docs I would never understand that it acts this way: Sorry, that should have been smtpd_sasl_exceptions_networks. Wietse
Re: DNSBL/DNSWL lookup table
johnea: > Hello Wietse, > > Is it possible to use this to DNSBL check URLs present in the body of an > email? (pre-queue) As described in my posting, the dnxsl query is an IP address, a domain name, or an email address. So the answer is "yes" when your email contains only lines of text with exactly one IP address, one domain name, or one email address. Wietse
Re: How to block offering SASL auth to clients based on RBL
On 06/09/2014 04:56 PM, li...@rhsoft.net wrote: >>> well, one could say: block them from submission port and don't allow >>> SASL on 25, but that works only if you are a startup beginning from >>> scratch, >> >> If that's the case then you can put submission on a separate IP address, >> so that your users can continue to submit to port 25 > > "so that your users can continue to submit to port 25" > > and how will that lead to "close port 25 completly"? So on the one hand you complain about how difficult it is to switch users off of port 25, but then when I give you a solution that means you don't have to you complain because you don't want them on port 25? Make up your mind, please. > my server has not to handle *any* MX traffic from outside, Then I fail to see what the problem is. > besides that you gain nothing why in the world should admins > deal with all sort of workarounds because MUA developers are > too stupid for sane defaults and insist in use 25? Please, go to Microsoft, Apple, Google, etc, and convince all of them to write their software the way you want. Unfortunately we live in the real world and this is what we have to deal with. Depending on your specific situation you may or may not have to cater to those MUAs. > frankly *all* ISP's should start to block outgoing port 25 I would love to see that, but again, we live in the real world. > and the problem would go away at the same time as 90% of > attempted spam delivery would disappear because all the > infected zombies have no longer a way to send their crap > without hacking the acount data and use real submission PBLs, FCRDNS, etc help a lot with this as well. Postscreen, when properly configured, is great at filtering zombie SPAM. The harder SPAM to filter tends to be SPAM that originates from legitimate servers, as you have said. > the difference ISP is blocking 25 or i do the same is simply > that nobody calls the ISP but anybody blames his mail admin > which can help in both cases but in one point to the ISP :-) Regardless of who is blocking it you have to deal with the results. As I said earlier you may be in a position where you can just block 25 outright and be able to push all your users to submission, or this may be too overwhelming of a task. The difference is that if the ISP blocks it then the user is *already* on 587. Peter
Re: How to block offering SASL auth to clients based on RBL
On 06/08/2014 08:17 PM, Kai Krakow wrote: > MX and Submission machine are the same postfix instance (and even the same > worker process on port 25), it won't work. I'm planning to maybe change this > in the future. But as with migrating all people to not submit on port 25 it > is a long way to go. If you can't force your users off of port 25, then the next best thing is to separate our your submission by IP address, if done correctly your users will be able to stay on port 25, not have to change the hostname (or any other settings in their MUA) and you will have separated out submission from MX traffic and can treat the two with different configs. Peter
CIDR Whitelist ?
I really should have figured this out ages ago, but... Quite simply, there exits a small number of organizations that run afoul of my various smtpd_recipient_restrictions and/or my smtpd_helo_restrictions, but from which I need to be able to receive mail anyway. (A small number of companies get snagged on reject_unknown_helo_hostname due to having botched the HELO strings on their outbound mail servers, and also, in the case of Microsoft, they seem to have managed to get numerous of their IPs listed on Spamcop.) So anyway, I just now added the following to my pre-existing list of smtpd_recipient_restrictions: check_client_access cidr:/usr/local/etc/postfix/blacklists/cidr-whitelist where my cidr-whitelist file currently contains just: # Microsoft 65.52.0.0/14 OK Of course, I placed this new check_client_access clause above all of the other/pre-existing clauses in my smtpd_recipient_restrictions. I just want to ask if I have done the proper thing here, because I've never done this before. My hope is that I haven't inadvertantly opened up a relaying hole or anything awful like that. One other question... Currently, I have the following: smtpd_helo_restrictions = permit_mynetworks reject_non_fqdn_helo_hostname reject_invalid_helo_hostname reject_unknown_helo_hostname In order to make sure that my new CIDR whitelist will allow in even mail from goofed-up sites that have botched their HELO strings, should I be moving the three reject_*helo_hostname clauses shown above down into my smtpd_recipient_restrictions... you know... to a position that comes *after* my new check_client_access clause?
Re: CIDR Whitelist ?
On 6/9/2014 7:12 PM, Ronald F. Guilmette wrote: > I really should have figured this out ages ago, but... > > Quite simply, there exits a small number of organizations that > run afoul of my various smtpd_recipient_restrictions and/or my > smtpd_helo_restrictions, but from which I need to be able to > receive mail anyway. (A small number of companies get snagged > on reject_unknown_helo_hostname due to having botched the HELO > strings on their outbound mail servers, and also, in the case of > Microsoft, they seem to have managed to get numerous of their > IPs listed on Spamcop.) > > So anyway, I just now added the following to my pre-existing > list of smtpd_recipient_restrictions: > > check_client_access cidr:/usr/local/etc/postfix/blacklists/cidr-whitelist > > where my cidr-whitelist file currently contains just: > > # Microsoft > 65.52.0.0/14 OK > > Of course, I placed this new check_client_access clause above all of > the other/pre-existing clauses in my smtpd_recipient_restrictions. > > I just want to ask if I have done the proper thing here, because I've > never done this before. > > My hope is that I haven't inadvertantly opened up a relaying hole or > anything awful like that. > > One other question... > > Currently, I have the following: > > smtpd_helo_restrictions = > permit_mynetworks > reject_non_fqdn_helo_hostname > reject_invalid_helo_hostname > reject_unknown_helo_hostname > > In order to make sure that my new CIDR whitelist will allow in even > mail from goofed-up sites that have botched their HELO strings, should > I be moving the three reject_*helo_hostname clauses shown above down > into my smtpd_recipient_restrictions... you know... to a position > that comes *after* my new check_client_access clause? Yes. And if you have other separate smtpd_foo_restrictions sections you should move those restriction parameters under smtpd_recipient_restrictions as well. This will give you precise control over whitelisting and blacklisting order. Cheers, Stan
Re: CIDR Whitelist ?
10.06.2014 05:02, Stan Hoeppner wrote: > On 6/9/2014 7:12 PM, Ronald F. Guilmette wrote: >> I really should have figured this out ages ago, but... >> >> Quite simply, there exits a small number of organizations that >> run afoul of my various smtpd_recipient_restrictions and/or my >> smtpd_helo_restrictions, but from which I need to be able to >> receive mail anyway. (A small number of companies get snagged >> on reject_unknown_helo_hostname due to having botched the HELO >> strings on their outbound mail servers, and also, in the case of >> Microsoft, they seem to have managed to get numerous of their >> IPs listed on Spamcop.) >> >> So anyway, I just now added the following to my pre-existing >> list of smtpd_recipient_restrictions: >> >> check_client_access cidr:/usr/local/etc/postfix/blacklists/cidr-whitelist >> >> where my cidr-whitelist file currently contains just: >> >> # Microsoft >> 65.52.0.0/14 OK >> >> Of course, I placed this new check_client_access clause above all of >> the other/pre-existing clauses in my smtpd_recipient_restrictions. >> >> I just want to ask if I have done the proper thing here, because I've >> never done this before. >> >> My hope is that I haven't inadvertantly opened up a relaying hole or >> anything awful like that. It depends on the postfix version. Older postfix, which didn't have smtpd_relay_restrictions, will act as an open relay for these networks, because you allow them the same way you accept_mynetworks, so it becomes more or less your networks. You should put reject_unauth_destination before accepting these. More recent postfix, which has separate smtpd_relay_restrictions, will be saner (provided you don't prepend this whietelist to relay_restrictions too :). For other smtpd_*_restrictions, it does not really matter. >> One other question... >> >> Currently, I have the following: >> >> smtpd_helo_restrictions = >> permit_mynetworks >> reject_non_fqdn_helo_hostname >> reject_invalid_helo_hostname >> reject_unknown_helo_hostname >> >> In order to make sure that my new CIDR whitelist will allow in even >> mail from goofed-up sites that have botched their HELO strings, should >> I be moving the three reject_*helo_hostname clauses shown above down >> into my smtpd_recipient_restrictions... you know... to a position >> that comes *after* my new check_client_access clause? > > > Yes. And if you have other separate smtpd_foo_restrictions sections you > should move those restriction parameters under > smtpd_recipient_restrictions as well. This will give you precise > control over whitelisting and blacklisting order. I'm sorry to say that, but this is wrong. All smtpd_*_restrictions give precise control over all the restrictions and their order, if you move it all to one stage it becomes clumsier. Also, moving stuff which should be run at connect or hello time to recipient time is kinda wrong. Such a suggestion - to move everything to recipient_restriction - can be given to a novice postfix user (or by novice postfix user), who does not understand smtp protocol stages and this smtpd_*_restrictions mechanics, both of which are kinda trivial. Thanks, /mjt
