Re: Postscreen and exceptions
On 12/23/2012 7:38 PM, Alex wrote: > Hi, > > I've implemented postscreen with postfix-2.9.4 on fc17 and it is > rejecting mail from alice.it and libero.it, which are apparently two > ISPs in Italy. We receive a large number of messages that are rejected > due to postscreen, but now we have one email address from each domain > that we need to allow the ability to send to us. > > Is there no alternative to creating a postscreen access list that > permits mail from the /24 for these domains just for these two users, > then let spamassassin filter the junk? I'd also then have to whitelist > the users in spamassassin as well. > > It also looks like mail originates from IPs other than those listed as > an MX record for alice.it, so I'm not even sure what the range would > be for the postscreen permit rules. As always it would be helpful if you provided Postfix logging of these rejections so we can see what is actually happening. At this point we don't know if it's the postscreen bot detection that's causing the rejections, or the dnsbls you have configured in postscreen that are causing the rejections. The proper fix to your problem may be different depending on the which is causing the rejections. -- Stan
Re: checking script doesnt work - Re: How to change modified cf files to postconf commands
Le 23/12/2012 15:28, Robert Moskowitz a écrit : > > On 12/23/2012 09:20 AM, Noel Jones wrote: >> On 12/23/2012 7:17 AM, Robert Moskowitz wrote: You can chase these with something like: # postconf -n | while read parameter equal value; do default_value=`postconf -d $parameter 2>&1`; if [ "$value" = "$default_value" ]; then echo "NOTICE: Useless setting: $parameter = $value"; fi; done >>> I have been running this against the base Centos 6 install that has >>> a main.cf with lots of comments and a few parameter lines. >>> >>> postconf -n shows about 20 parameters, and when I compare these >>> against postconf -d only 9 of them are different. >> That sounds about right. A basic postfix install needs only a few >> non-default settings. >> >> >>> parameters like mailq_path is now /usr/bin/mailq.postfix and the >>> default is /usr/bin/mailq >> sounds reasonable. >> >>> I look at the script and I am not able to tell what is wrong; can >>> you help me get it right? I think this is a real useful tool. >> It's unclear what problem you are having. Please explain. > > When I run the script shown above, there is no output. Yet I know > there are lines in the main.cf that differ from the defaults. > That is there are 9 lines shown in the -n option that are different > from shown in the -d option. I would think that the above script > should have printed those lines. No. the only output of the script is the one in the 'echo' line: it only prints anything if the value is the same in main.cf and in `postconf -d`. To see local settings, use 'postconf -n'. that's its job. If you really insist, here is a modified version of the script: postconf -n | while read parameter equal value; do default_value=`postconf -d $parameter 2>&1`; if [ "$value" = "$default_value" ]; then echo "NOTICE: Useless setting: $parameter = $value"; else echo "$parameter = $value" fi; done but this is too complex for the task. > > I ran the script both as me and as root. >
Re: checking script doesnt work - Re: How to change modified cf files to postconf commands
On 12/24/2012 05:26 AM, mouss wrote: Le 23/12/2012 15:28, Robert Moskowitz a écrit : On 12/23/2012 09:20 AM, Noel Jones wrote: On 12/23/2012 7:17 AM, Robert Moskowitz wrote: You can chase these with something like: # postconf -n | while read parameter equal value; do default_value=`postconf -d $parameter 2>&1`; if [ "$value" = "$default_value" ]; then echo "NOTICE: Useless setting: $parameter = $value"; fi; done I have been running this against the base Centos 6 install that has a main.cf with lots of comments and a few parameter lines. postconf -n shows about 20 parameters, and when I compare these against postconf -d only 9 of them are different. That sounds about right. A basic postfix install needs only a few non-default settings. parameters like mailq_path is now /usr/bin/mailq.postfix and the default is /usr/bin/mailq sounds reasonable. I look at the script and I am not able to tell what is wrong; can you help me get it right? I think this is a real useful tool. It's unclear what problem you are having. Please explain. When I run the script shown above, there is no output. Yet I know there are lines in the main.cf that differ from the defaults. That is there are 9 lines shown in the -n option that are different from shown in the -d option. I would think that the above script should have printed those lines. No. the only output of the script is the one in the 'echo' line: it only prints anything if the value is the same in main.cf and in `postconf -d`. To see local settings, use 'postconf -n'. that's its job. If you really insist, here is a modified version of the script: postconf -n | while read parameter equal value; do default_value=`postconf -d $parameter 2>&1`; if [ "$value" = "$default_value" ]; then echo "NOTICE: Useless setting: $parameter = $value"; else echo "$parameter = $value" fi; done but this is too complex for the task. I have since done this 'by hand', but I cannot get any output from this script! Have you tried it? Is it something else to do with my Centos 6.3 environment? No output at all! Thank you for your efforts.
Re: checking script doesnt work - Re: How to change modified cf files to postconf commands
On 12/24/2012 08:24 AM, Robert Moskowitz wrote: On 12/24/2012 05:26 AM, mouss wrote: Le 23/12/2012 15:28, Robert Moskowitz a écrit : On 12/23/2012 09:20 AM, Noel Jones wrote: On 12/23/2012 7:17 AM, Robert Moskowitz wrote: You can chase these with something like: # postconf -n | while read parameter equal value; do default_value=`postconf -d $parameter 2>&1`; if [ "$value" = "$default_value" ]; then echo "NOTICE: Useless setting: $parameter = $value"; fi; done I have been running this against the base Centos 6 install that has a main.cf with lots of comments and a few parameter lines. postconf -n shows about 20 parameters, and when I compare these against postconf -d only 9 of them are different. That sounds about right. A basic postfix install needs only a few non-default settings. parameters like mailq_path is now /usr/bin/mailq.postfix and the default is /usr/bin/mailq sounds reasonable. I look at the script and I am not able to tell what is wrong; can you help me get it right? I think this is a real useful tool. It's unclear what problem you are having. Please explain. When I run the script shown above, there is no output. Yet I know there are lines in the main.cf that differ from the defaults. That is there are 9 lines shown in the -n option that are different from shown in the -d option. I would think that the above script should have printed those lines. No. the only output of the script is the one in the 'echo' line: it only prints anything if the value is the same in main.cf and in `postconf -d`. To see local settings, use 'postconf -n'. that's its job. If you really insist, here is a modified version of the script: postconf -n | while read parameter equal value; do default_value=`postconf -d $parameter 2>&1`; if [ "$value" = "$default_value" ]; then echo "NOTICE: Useless setting: $parameter = $value"; else echo "$parameter = $value" fi; done but this is too complex for the task. I have since done this 'by hand', but I cannot get any output from this script! Have you tried it? Is it something else to do with my Centos 6.3 environment? No output at all! Correction: This changed script prints ALL entries from postconf -n on the else branch. parameters that I now are 'Useless' are not being listed as such. hmmm. I wonder about something that Wietse said about upgrades in postconf. I am running postfix 2.6.6, and that variable in the postconf -d expression might be expanded in my version? Thank you for your efforts.
Script fixed - Re: checking script doesnt work - Re: How to change modified cf files to postconf commands
I added a few echos, guessed at what was happening and below you will see a nice little script which shows "useless" parameters in main.cf On 12/24/2012 05:26 AM, mouss wrote: Le 23/12/2012 15:28, Robert Moskowitz a écrit : On 12/23/2012 09:20 AM, Noel Jones wrote: On 12/23/2012 7:17 AM, Robert Moskowitz wrote: You can chase these with something like: # postconf -n | while read parameter equal value; do default_value=`postconf -d $parameter 2>&1`; if [ "$value" = "$default_value" ]; then echo "NOTICE: Useless setting: $parameter = $value"; fi; done I have been running this against the base Centos 6 install that has a main.cf with lots of comments and a few parameter lines. postconf -n shows about 20 parameters, and when I compare these against postconf -d only 9 of them are different. That sounds about right. A basic postfix install needs only a few non-default settings. parameters like mailq_path is now /usr/bin/mailq.postfix and the default is /usr/bin/mailq sounds reasonable. I look at the script and I am not able to tell what is wrong; can you help me get it right? I think this is a real useful tool. It's unclear what problem you are having. Please explain. When I run the script shown above, there is no output. Yet I know there are lines in the main.cf that differ from the defaults. That is there are 9 lines shown in the -n option that are different from shown in the -d option. I would think that the above script should have printed those lines. No. the only output of the script is the one in the 'echo' line: it only prints anything if the value is the same in main.cf and in `postconf -d`. To see local settings, use 'postconf -n'. that's its job. If you really insist, here is a modified version of the script: postconf -n | while read parameter equal value; do default_value=`postconf -d $parameter 2>&1`; if [ "$value" = "$default_value" ]; then echo "NOTICE: Useless setting: $parameter = $value"; else echo "$parameter = $value" fi; done postconf -n | while read parameter equal value; do default_value=`postconf -d $parameter 2>&1`; if [ "$parameter = $value" = "$default_value" ]; then echo "NOTICE: Useless setting: $parameter = $value"; fi; done But postconf -n | while read parameter equal value; do default_value=`postconf -d $parameter`; if [ "$parameter = $value" = "$default_value" ]; then echo "NOTICE: Useless setting: $parameter = $value"; fi; done also works. But this gets down to your comment that the "2>&1" avoids false postitives. I don't know how to include that in the if statement.
Re: Appending to a parameter using postconf
On 12/23/2012 08:03 PM, Wietse Venema wrote: Robert Moskowitz: Is there a way to append to a parameter using postconf. If it is only in a version later than 2.6.6, oh well. But the example is smtpd_recipient_restrictions which can have a long list and then you want to add a realtime black list check fqdn. With these parameters is more likely that one wants to add something in the middle, so no, there is no append operation for the rare corner case. Also in this vein, can postconf -e 'parameter= ...' be submitted on more than one line, or with a long entry as above, does it have to be just one entry line. You could break long command lines in the shell with backslash-newline. This works on the terminal and in scripts. Perhaps I am doing something wrong in my script, but I tried this and got an error. My script contained the lines: postconf -e 'smtpd_recipient_restrictions = permit_sasl_authentication,\ permit_mynetworks,\ reject_unauth_destinations' And the error I got: postfix: fatal: -e or -# accepts no multi-line input So I am missing something...
Re: Appending to a parameter using postconf
Robert Moskowitz: > got an error. > > My script contained the lines: > > postconf -e 'smtpd_recipient_restrictions = permit_sasl_authentication,\ > permit_mynetworks,\ > reject_unauth_destinations' > > And the error I got: > > postfix: fatal: -e or -# accepts no multi-line input > > So I am missing something... You can pretty much forget about backslash-newline inside strings. You'd have to use " quotes, but those don't prevent $parameter_name expansion. Please FIX YOUR MAIL CLIENT so that it respects the REPLY-TO header. I don't need two copies of your replies. You already send multiple follow-ups at a time, so I am sure that I have deleted some unread. Wietse
Re: Appending to a parameter using postconf
On 12/24/2012 11:30 AM, Wietse Venema wrote: Robert Moskowitz: got an error. My script contained the lines: postconf -e 'smtpd_recipient_restrictions = permit_sasl_authentication,\ permit_mynetworks,\ reject_unauth_destinations' And the error I got: postfix: fatal: -e or -# accepts no multi-line input So I am missing something... You can pretty much forget about backslash-newline inside strings. You'd have to use " quotes, but those don't prevent $parameter_name expansion. Oh well. Will have to live with this. I suppose a skilled script writer could build the single line from multiple input lines in the script. I am good for this time around; will look more into it another time. And I *think* I have postfix configured so on to Dovecot for the next component. Please FIX YOUR MAIL CLIENT so that it respects the REPLY-TO header. I don't need two copies of your replies. You already send multiple follow-ups at a time, so I am sure that I have deleted some unread. I will better train myself to just for list replies, rather than that I have to use in most non-list cases. Sorry about that.
Postfix Virtual users config -- Need Help
Hello, I'm trying to setup a personal mail server with postfix. I'm trying to use postfix virtual users method.. I'm not able to get the mail delivered... I looked through the documentation.. not able to find the issue.. Can some one please help?... Thanks in advance Vijay Rajah Here is my (sanitized config) # postconf -n command_directory = /mail/postfix/sbin config_directory = /etc/postfix daemon_directory = /mail/postfix/libexec data_directory = /mail/postfix/var/lib debug_peer_level = 2 debugger_command = PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin ddd $daemon_directory/$process_name $process_id & sleep 5 html_directory = no inet_protocols = ipv4 mail_owner = postfix mailq_path = /usr/bin/mailq manpage_directory = /mail/postfix/man mydestination = localhost, localhost.localdomain, $myorigin myhostname = vrajah-1.mydomain.tld mynetworks = 127.0.0.0/8 myorigin = $myhostname newaliases_path = /usr/bin/newaliases queue_directory = /mail/postfix/var/spool readme_directory = no sample_directory = /etc/postfix sendmail_path = /usr/sbin/sendmail setgid_group = postdrop unknown_local_recipient_reject_code = 550 virtual_alias_domains = virtual_alias_maps = hash:/mail/postfix/etc/virtual_alias_maps virtual_gid_maps = static:5000 virtual_mailbox_base = /mail/mailbox/vmail virtual_mailbox_domains = /mail/postfix/etc/virtual_domains virtual_mailbox_maps = hash:/mail/postfix/etc/virtual_mailbox_maps virtual_minimum_uid = 1000 virtual_transport = virtual virtual_uid_maps = static:5000 # cat virtual_domains mydomain.tld # cat virtual_alias_maps m...@mydomain.tld me vi...@mydomain.tld vijay # cat virtual_mailbox_maps /mail/postfix/etc/virtual_mailbox_maps m...@mydomain.tldmydomain/me vi...@mydomain.tld mydomain/vijay When i try to send an email (using telnet from local machine for testing) to m...@mydomain.tld.. i get this error in maillog Dec 24 23:01:03 vrajah-1 postfix/cleanup[9612]: 3185A12A302A1: message-id=<20121224173100.3185a12a30...@vrajah-vps-1.mydomain.tld> Dec 24 23:01:03 vrajah-1 postfix/qmgr[9605]: 3185A12A302A1: from=, size=322, nrcpt=1 (queue active) Dec 24 23:01:03 vrajah-1 postfix/local[9617]: 3185A12A302A1: to=, orig_to=, relay=local, delay=16, delays=16/0/0/0, dsn=5.1.1, status=bounced (unknown user: "me") Dec 24 23:01:03 vrajah-1 postfix/cleanup[9612]: 3D0A412A302AA: message-id=<20121224173103.3d0a412a30...@vrajah-1.mydomain.tld> Dec 24 23:01:03 vrajah-1 postfix/bounce[9618]: 3185A12A302A1: sender non-delivery notification: 3D0A412A302AA
Re: Postfix Virtual users config -- Need Help
Vijay Rajah skrev den 2012-12-24 19:04: Hello, I'm trying to setup a personal mail server with postfix. I'm trying to use postfix virtual users method.. I'm not able to get the mail delivered... I looked through the documentation.. not able to find the issue.. Can some one please help?... remove mynetworks line, okay with testing stage, but in production its default from postconf -d should be ok aswell # cat virtual_domains mydomain.tld # cat virtual_alias_maps m...@mydomain.tld me vi...@mydomain.tld vijay it must be fqdn on both sides or local must see the right side be unix user # cat virtual_mailbox_maps /mail/postfix/etc/virtual_mailbox_maps m...@mydomain.tldmydomain/me vi...@mydomain.tld mydomain/vijay ok When i try to send an email (using telnet from local machine for testing) to m...@mydomain.tld.. i get this error in maillog Dec 24 23:01:03 vrajah-1 postfix/cleanup[9612]: 3185A12A302A1: message-id=<20121224173100.3185a12a30...@vrajah-vps-1.mydomain.tld> Dec 24 23:01:03 vrajah-1 postfix/qmgr[9605]: 3185A12A302A1: from=, size=322, nrcpt=1 (queue active) Dec 24 23:01:03 vrajah-1 postfix/local[9617]: 3185A12A302A1: to=, orig_to=, relay=local, relay local is not virtual and local cant have @ in destination as a tump of rules :) delay=16, delays=16/0/0/0, dsn=5.1.1, status=bounced (unknown user: "me") Dec 24 23:01:03 vrajah-1 postfix/cleanup[9612]: 3D0A412A302AA: message-id=<20121224173103.3d0a412a30...@vrajah-1.mydomain.tld> Dec 24 23:01:03 vrajah-1 postfix/bounce[9618]: 3185A12A302A1: sender non-delivery notification: 3D0A412A302AA
Re: Postscreen and exceptions
Hi,
>> I haven't been able to find much available on the proper use for
>> smtpd_mumble_restrictions. It doesn't seem to be documented with
>> postscreen or the postconf page or even my postconf output.
>
> smtpd_mumble_restrictions is shorthand for "use any of
> smtpd_{client, helo, sender, recipient, data,
> end_of_data}_restrictions."
Okay, duh. Maybe it never occurred to me because I thought postscreen
was well before any of the smtpd restrictions.
> I'm curious what postscreen rules you're using that are rejecting
> mail from an ISP. (I'm not familiar with the two you mention, and
> assume they aren't spammer-haven worthy of global blocking.)
Perhaps many of the rejects from users at those domains are really
just spoofed. Here's one reject actually from them, however:
Dec 24 04:23:11 mail02 postfix/postscreen[1468]: NOQUEUE: reject: RCPT
from [212.52.84.101]:54948: 550 5.7.1 Service unavailable; client
[212.52.84.101] blocked using bl.spamcop.net;
from=, to=, proto=ESMTP,
helo=
My postscreen config contains:
postscreen_access_list = permit_mynetworks,
cidr:/etc/postfix/postscreen_access.cidr
postscreen_dnsbl_threshold = 1
postscreen_dnsbl_action = enforce
postscreen_greet_action = enforce
postscreen_blacklist_action = enforce
postscreen_dnsbl_sites = mykey.zen.dq.spamhaus.net*2
bl.spamcop.net*1 b.barracudacentral.org*1 psbl.surriel.com*1
I have a series of IPs in the postscreen_access.cidr file that need to
be permitted, and add to it after we learn mail is being rejected due
to the IP being blacklisted by one of the RBLs.
>> I also understand that organizations use separate IPs from those
>> listed in their MX records -- that was my point. I have no way of
>> knowing what those IPs are, except through trial and error, looking
>> through logs and correlating them with addresses, etc.
>
> Perhaps they publish SPF records, which were invented for this purpose.
> $ host -t txt libero.it
> libero.it descriptive text "v=spf1 ip4:212.52.84.101/32
> ip4:212.52.84.102/31 ip4:212.52.84.104/29 ip4:212.52.84.112/29
> ip4:212.52.84.192/32 ip4:212.52.84.43/32 include:blackberry.com ?all"
Ah, yes. That's still something like 20 IPs. I would assume none of
the blackberry.com IPs would ever be rejected by postscreen, so they
don't need to be added.
I can then just add the single email address to the whitelist_from_spf
in spamassassin.
For alice.it, they don't appear to publish an SPF record, but instead
some kind of google key?
alice.it. 19028 IN TXT
"google-site-verification=fmPX0ewWZ5WfhZ80tP8h-cQb2p0L_KCixRm_UHyK-bw"
Dec 24 08:00:46 mail01 postfix/postscreen[24923]: NOQUEUE: reject:
RCPT from [82.57.200.119]:48396: 550 5.7.1 Service unavailable; client
[82.57.200.119] blocked using bl.spamcop.net; from=,
to=, proto=ESMTP, helo=
We have several IPs from the alice.it domain that appear to be not
blacklisted, including 82.57.200.104.
Thanks,
Alex
Re: Postscreen and exceptions
Hi, >> It also looks like mail originates from IPs other than those listed as >> an MX record for alice.it, so I'm not even sure what the range would >> be for the postscreen permit rules. > > As always it would be helpful if you provided Postfix logging of these > rejections so we can see what is actually happening. At this point we > don't know if it's the postscreen bot detection that's causing the > rejections, or the dnsbls you have configured in postscreen that are > causing the rejections. The proper fix to your problem may be different > depending on the which is causing the rejections. It looks like some from alice.it make it through successfully: Dec 24 07:51:15 mail01 postfix/smtpd[22059]: connect from smtp304.alice.it[82.57.200.93] While others are rejected: Dec 24 08:00:46 mail01 postfix/postscreen[24923]: NOQUEUE: reject: RCPT from [82.57.200.119]:48396: 550 5.7.1 Service unavailable; client [82.57.200.119] blocked using bl.spamcop.net; from=, to=, proto=ESMTP, helo= For libero.it, there are far more rejections, and I don't know if the IPs are actual libero.it IPs or just spoofed emails from that domain, or customers of the ISP: Dec 24 00:28:50 mail02 postfix/postscreen[1468]: NOQUEUE: reject: RCPT from [195.81.140.87]:32798: 550 5.7.1 Service unavailable; client [195.81.140.87] blocked using bl.spamcop.net; from=, to=, proto=SMTP, helo= I know now this one is listed in their SPF records: Dec 24 10:03:07 mail01 postfix/postscreen[24923]: NOQUEUE: reject: RCPT from [212.52.84.101]:49951: 550 5.7.1 Service unavailable; client [212.52.84.101] blocked using bl.spamcop.net; from=, to=, proto=ESMTP, helo= Thanks, Alex
Re: Postscreen and exceptions
On 12/24/2012 2:26 PM, Alex wrote: > Dec 24 00:28:50 mail02 postfix/postscreen[1468]: NOQUEUE: reject: RCPT > from [195.81.140.87]:32798: 550 5.7.1 Service unavailable; client > [195.81.140.87] blocked using bl.spamcop.net; from=, > to=, proto=SMTP, > helo= Here's your problem Alex. You're using spamcop to outright block on hit. This is not advised and is well known to cause FPs. Spamcop hits are best scored with other DNSBL hits inside SA, which does so automatically in a default config. Remove spamcop from your postscreen configuration and that will fix this problem. Happy holidays to Alex, and to everyone. -- Stan
Re: Postscreen and exceptions
Hi, >> Dec 24 00:28:50 mail02 postfix/postscreen[1468]: NOQUEUE: reject: RCPT >> from [195.81.140.87]:32798: 550 5.7.1 Service unavailable; client >> [195.81.140.87] blocked using bl.spamcop.net; from=, >> to=, proto=SMTP, >> helo= > > Here's your problem Alex. You're using spamcop to outright block on > hit. This is not advised and is well known to cause FPs. Spamcop hits > are best scored with other DNSBL hits inside SA, which does so > automatically in a default config. Remove spamcop from your postscreen > configuration and that will fix this problem. Awesome, thanks. So psbl.surriel.com is okay to keep? > Happy holidays to Alex, and to everyone. Happy holidays to you as well! Thanks for helping out on this late holiday eve... btw, Stan, I eventually ordered the proper supermicro trays for the SSD disks and migrated two servers already. Performance is much improved, although I'm sure there's still room for improvement. Project for another day. Thanks, Alex
Re: Postscreen and exceptions
Alex: > Dec 24 04:23:11 mail02 postfix/postscreen[1468]: NOQUEUE: reject: RCPT > from [212.52.84.101]:54948: 550 5.7.1 Service unavailable; client > [212.52.84.101] blocked using bl.spamcop.net; Don't use spamcop, or use it only with small weight in a scoring system. Wietse
Re: Postscreen and exceptions
On Mon, Dec 24, 2012 at 05:34:20PM -0500, Alex wrote: > >> Dec 24 00:28:50 mail02 postfix/postscreen[1468]: NOQUEUE: > >> reject: RCPT from [195.81.140.87]:32798: 550 5.7.1 Service > >> unavailable; client [195.81.140.87] blocked using > >> bl.spamcop.net; from=, to=, > >> proto=SMTP, helo= > > > > Here's your problem Alex. You're using spamcop to outright block > > on hit. This is not advised and is well known to cause FPs. > > Spamcop hits are best scored with other DNSBL hits inside SA, > > which does so automatically in a default config. Remove spamcop > > from your postscreen configuration and that will fix this > > problem. The problem was not the existence of spamcop within the list. The problem was the *scoring* of spamcop and the threshold of 1. If you're going to set scores, USE them. Set the postscreen_dnsbl_threshold *higher* than 1. > Awesome, thanks. So psbl.surriel.com is okay to keep? It's probably safer than spamcop, but the best answer is to check their policies, test its performance, and see if it works for you. The pre-postscreen way was to use "warn_if_reject reject_rbl_client psbl.surriel.com" in your smtpd restrictions. The postscreen way is, again, to raise your threshold score to ensure it's never used: postscreen_dnsbl_threshold = 9 postscreen_dnsbl_sites = zen.spamhaus.org*9, b.barracudacentral.org*9 bl.spameatingmonkey.net*9 dnsbl.njabl.org*7 dnsbl.ahbl.org*7 bl.spamcop.net*3 dnsbl.sorbs.net*3 spamtrap.trblspam.com*3 psbl.surriel.com [ ... other sites such as whitelists with negative scores ... ] In the example above, psbl.surriel.com would never trigger a rejection. The extra one point would never be significant. Note I am not recommending this; I am merely illustrating how the scoring system can work. My own postscreen_dnsbl_threshold is 3, with three tiers of DNSBL sites: Tier 1, 3 points: reject with that site alone Tier 2, 2 points: reject with that site plus any other Tier 3, 1 point: reject with three of these sites I'm not currently using psbl.surriel.com, but I'm sure it would be fine in Tier 3. The whole point of Tier 3 is that it does NOT require much confidence in those sites, but that when three of them agree, there might be good reason to block. -- http://rob0.nodns4.us/ -- system administration and consulting Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
Re: postconf expansion
Viktor Dukhovni:
> Happy new year to you too! Thanks for the holiday present.
>
> It'll make life easier to tell people to report:
>
> $ postconf -q u...@example.com $(postconf -Rh virtual_alias_maps|tr ',' ' ')
>
> (and similar recipes) than to have to explain the details in a series
> of posts...
OK, the 20121224 Christmas edition does this and more, and it also
produces more warnings. As for the latter I wonder if it will freak
out people and would need to be shut up at install/upgrade time.
Below is a fragment from the current RELEASE_NOTES file.
Wietse
Major changes with snapshot 20121224
The postconf command has been updated to make trouble-shooting (and
support) easier. In summary, use "postconf -Mnxf" and "postconf
-nxf" to review master.cf and main.cf parameter settings with
expanded parameter values.
- "postconf -x" now expands $name in main.cf and master.cf parameter
values.
- "postconf -Mn" now shows only master.cf entries with "-o name=value"
parameter settings.
- postconf warns about attempts to modify a read-only parameter
(process_name, process_id) in main.cf or master.cf.
- postconf warns about an undefined $name in a parameter value in
main.cf or master.cf (except for backwards-compatibility parameters
such as $virtual_maps).
Re: Postscreen and exceptions
On 12/24/2012 2:16 PM, Alex wrote:
> Hi,
>
>>> I haven't been able to find much available on the proper use for
>>> smtpd_mumble_restrictions. It doesn't seem to be documented with
>>> postscreen or the postconf page or even my postconf output.
>>
>> smtpd_mumble_restrictions is shorthand for "use any of
>> smtpd_{client, helo, sender, recipient, data,
>> end_of_data}_restrictions."
>
> Okay, duh. Maybe it never occurred to me because I thought postscreen
> was well before any of the smtpd restrictions.
>
>> I'm curious what postscreen rules you're using that are rejecting
>> mail from an ISP. (I'm not familiar with the two you mention, and
>> assume they aren't spammer-haven worthy of global blocking.)
>
> Perhaps many of the rejects from users at those domains are really
> just spoofed. Here's one reject actually from them, however:
>
> Dec 24 04:23:11 mail02 postfix/postscreen[1468]: NOQUEUE: reject: RCPT
> from [212.52.84.101]:54948: 550 5.7.1 Service unavailable; client
> [212.52.84.101] blocked using bl.spamcop.net;
> from=, to=, proto=ESMTP,
> helo=
>
> My postscreen config contains:
> postscreen_access_list = permit_mynetworks,
> cidr:/etc/postfix/postscreen_access.cidr
> postscreen_dnsbl_threshold = 1
> postscreen_dnsbl_action = enforce
> postscreen_greet_action = enforce
> postscreen_blacklist_action = enforce
> postscreen_dnsbl_sites = mykey.zen.dq.spamhaus.net*2
> bl.spamcop.net*1 b.barracudacentral.org*1 psbl.surriel.com*1
I see. Perhaps you intended postscreen_dnsbl_threshold = 2 with the
above RBLs and weights.
Spamcop in particular is not safe and not recommended for outright
rejection. Opinions differ on psbl.surriel and barracudacentral,
but they are frequently used in scoring rather than outright. A
site listed on two of these three is likely spam, a site listed on
only one of them is questionable.
The spamhaus zen list is widely considered safe for outright rejection.
You also might benefit from using dns whitelists with postscreen.
The idea is to "rescue" mostly-good IPs from postscreen and pass
them to SpamAssassin for deeper inspection. Some to consider
list.dnswl.org*-1
hostkarma.junkemailfilter.com=127.0.0.1*-1
swl.spamhaus.org*-2
-- Noel Jones
Merry Christmas to all! And I get my name up in lights all over town!
tool to edit master.cf
I am not finding a tool to edit master.cf similar to 'postconf -e' for main.cf. It seems in my reading that in postfix 2.9, postconf can display master.cf, but not edit it? And, of course, so far I am working with postfix 2.6.6. Just looking for a nice way to build up a script of changes I am making to master.cf (like uncomment submission and add dovecot support). Yes, I suspect I can pull out my SED manual and use it.
