Re: [OT?] blocking replies (WAS: whitelisting problem)
Hi Stan, On Wed, 09 Dec 2009 21:24:53 -0600 Stan Hoeppner s...@hardwarefreak.com wrote: Mikael Bak put forth on 12/9/2009 4:18 AM: I understand why you avoid the real question. But hey - it's your server :-) Do you? I have avoided it because these threads can quickly delve into childish mud slinging if the participants aren't civil thoughtful adults. I'm assuming we are all civil adults, and can have a valid thoughtful discussion. So, I will explain my configuration and the reasons for it. [snipped technical details] Thanks for the technical details and the explanation. I have no intension starting holy wars on the list. I'm too old for that. This setup works for you, and you are happy with it. May I suggest that you add a postmaster address to the 550 rejection message that one can contact even from a blacklisted country. This way one could apply to be added on a white list. I don't use SA or any other content filtering. IMHO content filtering is a dead end. As only solution yes. Together with DNSBL, it could be quite effective. This works well for my site. YMMV. I'm glad to hear that. Have a nice day. Mikael
Re: [OT?] blocking replies (WAS: whitelisting problem)
Mikael Bak put forth on 12/8/2009 3:31 AM: mouss wrote: I'm looking through you, where did you go: s...@hardwarefreak.com: host greer.hardwarefreak.com[65.41.216.221] said: 554 5.7.1 imlil.netoyen.net[91.121.103.130]: Client host rejected: Access denied (in reply to RCPT TO command) It is nice to not reject mail from people who help you... I could not agree more. I got this from him: s...@hardwarefreak.com: host greer.hardwarefreak.com[65.41.216.221] said: 554 5.7.1 thor.iszerviz.hu[62.77.131.9]: Client host rejected: Mail not accepted from Hungary (in reply to RCPT TO command) Maybe he thinks nobody in Hungary can help him ;-) Mikael Two words: LIST MAIL. When you reply directly to senders, all kinds of unpleasant things can happen. Keep replies on list only and you can avoid seeing some of the draconian things folks do. If you want to bitch about such draconian things folks do, this isn't the appropriate forum. -- Stan
Re: [OT?] blocking replies (WAS: whitelisting problem)
Stan Hoeppner wrote: Mikael Bak put forth on 12/8/2009 3:31 AM: mouss wrote: I'm looking through you, where did you go: s...@hardwarefreak.com: host greer.hardwarefreak.com[65.41.216.221] said: 554 5.7.1 imlil.netoyen.net[91.121.103.130]: Client host rejected: Access denied (in reply to RCPT TO command) It is nice to not reject mail from people who help you... I could not agree more. I got this from him: s...@hardwarefreak.com: host greer.hardwarefreak.com[65.41.216.221] said: 554 5.7.1 thor.iszerviz.hu[62.77.131.9]: Client host rejected: Mail not accepted from Hungary (in reply to RCPT TO command) Maybe he thinks nobody in Hungary can help him ;-) Mikael Two words: LIST MAIL. When you reply directly to senders, all kinds of unpleasant things can happen. Keep replies on list only and you can avoid seeing some of the draconian things folks do. If you want to bitch about such draconian things folks do, this isn't the appropriate forum. I agree. Answers should go to the list. I discovered your unpleasant setup by mistake when I send reply to you directly AND cc to the list. I understand why you avoid the real question. But hey - it's your server :-) Mikael
Re: [OT?] blocking replies (WAS: whitelisting problem)
On Wed, 09 Dec 2009 03:58:28 -0600 Stan Hoeppner s...@hardwarefreak.com wrote: [snip] Two words: LIST MAIL. When you reply directly to senders, all kinds of unpleasant things can happen. Keep replies on list only and you can avoid seeing some of the draconian things folks do. setting the reply-to header helps that enormously -- John
THREAD's DEAD Baby (Was: blocking replies (WAS: whitelisting problem))
Stan Hoeppner a écrit : Mikael Bak put forth on 12/8/2009 3:31 AM: mouss wrote: I'm looking through you, where did you go: s...@hardwarefreak.com: host greer.hardwarefreak.com[65.41.216.221] said: 554 5.7.1 imlil.netoyen.net[91.121.103.130]: Client host rejected: Access denied (in reply to RCPT TO command) It is nice to not reject mail from people who help you... I could not agree more. I got this from him: s...@hardwarefreak.com: host greer.hardwarefreak.com[65.41.216.221] said: 554 5.7.1 thor.iszerviz.hu[62.77.131.9]: Client host rejected: Mail not accepted from Hungary (in reply to RCPT TO command) Maybe he thinks nobody in Hungary can help him ;-) Mikael Two words: LIST MAIL. When you reply directly to senders, all kinds of unpleasant things can happen. Keep replies on list only and you can avoid seeing some of the draconian things folks do. If you want to bitch about such draconian things folks do, this isn't the appropriate forum. For the benefit of Mister Kite, this thread is declared as dead. offenders will have to face Mr Wallace.
Re: [OT?] blocking replies (WAS: whitelisting problem)
John Peach put forth on 12/9/2009 7:03 AM: On Wed, 09 Dec 2009 03:58:28 -0600 Stan Hoeppner s...@hardwarefreak.com wrote: [snip] Two words: LIST MAIL. When you reply directly to senders, all kinds of unpleasant things can happen. Keep replies on list only and you can avoid seeing some of the draconian things folks do. setting the reply-to header helps that enormously For list mail, that's up to the list manager configuration, not individual users sending mail to the list. postfix-users does not do this, afaict, so I use the reply-to-list plugin for T-Bird. Works flawlessly. -- Stan
Re: [OT?] blocking replies (WAS: whitelisting problem)
Mikael Bak put forth on 12/9/2009 4:18 AM:
I understand why you avoid the real question. But hey - it's your server :-)
Do you? I have avoided it because these threads can quickly delve into
childish mud slinging if the participants aren't civil thoughtful
adults. I'm assuming we are all civil adults, and can have a valid
thoughtful discussion. So, I will explain my configuration and the
reasons for it.
I smtp block a number of countries' IP space using ipdeny data
(http://ipdeny.com/) and ccTLDs. The reason is simple mathematics. I
receive or have received large amounts of spam from these netblocks.
Given I have no legit direct senders (or 1, now, in the case of hungary)
in those countries, it is simply a more efficient and more complete way
to block spam from said sources without wasting time playing
whack-a-mole. Just so you don't feel I'm singling out Hungary for some
dishonorable or nefarious reason, here's my current country blocking
scheme. Each entry was prompted by copious inbound spam attempts. Note
that I'm not blocking every country in the world but the US, but
countries that have been irritating sources of spam here.
cidr=cidr:/etc/postfix/cidr_files
smtpd_client_restrictions =
check_client_access ${cidr}/china
check_client_access ${cidr}/korea
check_client_access ${cidr}/russia
check_client_access ${cidr}/ukraine
check_client_access ${cidr}/malaysia
check_client_access ${cidr}/belarus
check_client_access ${cidr}/indonesia
check_client_access ${cidr}/hongkong
check_client_access ${cidr}/africa
check_client_access ${cidr}/romania
check_client_access ${cidr}/thailand
check_client_access ${cidr}/panama
check_client_access ${cidr}/poland
check_client_access ${cidr}/hungary
check_client_access ${cidr}/spammer
check_client_access ${cidr}/syptec
check_client_access ${cidr}/hurricane-electric
check_client_access ${cidr}/richk-1
check_client_access hash:/etc/postfix/coolsavings.access
check_client_access hash:/etc/postfix/richk-1.access
check_client_access pcre:/etc/postfix/access.pcre
/etc/postfix/access.pcre
# ban the following country TLDs in FQrDNS names
/^.*?(an|lv|ec|id|ph|at|hu|tr|ee|dk|pl|ro|my|co|tw|br|za|do|cz|bg|by|kr|jp|fr|cn|ru)$/i
550 We do not accept mail from .$1 domains
I've got some overlap, but they're checking different things. I've seen
sending hosts in US colo facilities with .ru, .br, etc CCtLDS in FQrDNS
and there's no legit reason I'd be receiving email from such anonymous
web hosts.
I've been running this config for many months now, parts of it for
years. Your email was the first false positive generated by this
configuration out of hundreds of thousands of connection attempts.
../spammer is my main US block file. The 5 following it are also deal
with US spammers or spam supporting ISPs. Currently spammer has almost
1000 CIDRs ranging from /12s to /27s. It also has a few entries in
other countries not covered by the method above.
I don't use SA or any other content filtering. IMHO content filtering
is a dead end.
This works well for my site. YMMV.
--
Stan
Re: [OT?] blocking replies (WAS: whitelisting problem)
mouss wrote: I'm looking through you, where did you go: s...@hardwarefreak.com: host greer.hardwarefreak.com[65.41.216.221] said: 554 5.7.1 imlil.netoyen.net[91.121.103.130]: Client host rejected: Access denied (in reply to RCPT TO command) It is nice to not reject mail from people who help you... I could not agree more. I got this from him: s...@hardwarefreak.com: host greer.hardwarefreak.com[65.41.216.221] said: 554 5.7.1 thor.iszerviz.hu[62.77.131.9]: Client host rejected: Mail not accepted from Hungary (in reply to RCPT TO command) Maybe he thinks nobody in Hungary can help him ;-) Mikael
Re: [OT?] blocking replies (WAS: whitelisting problem)
Zitat von Mikael Bak mik...@t-online.hu: mouss wrote: I'm looking through you, where did you go: s...@hardwarefreak.com: host greer.hardwarefreak.com[65.41.216.221] said: 554 5.7.1 imlil.netoyen.net[91.121.103.130]: Client host rejected: Access denied (in reply to RCPT TO command) It is nice to not reject mail from people who help you... I could not agree more. I got this from him: s...@hardwarefreak.com: host greer.hardwarefreak.com[65.41.216.221] said: 554 5.7.1 thor.iszerviz.hu[62.77.131.9]: Client host rejected: Mail not accepted from Hungary (in reply to RCPT TO command) Maybe he thinks nobody in Hungary can help him ;-) Mikael Funny that the attitude to block other countries because of spam is mostly present in the USA where most of the spam orginates... Andreas smime.p7s Description: S/MIME krytographische Unterschrift
Re: [OT?] blocking replies (WAS: whitelisting problem)
lst_ho...@kwsoft.de wrote: Zitat von Mikael Bak mik...@t-online.hu: I could not agree more. I got this from him: s...@hardwarefreak.com: host greer.hardwarefreak.com[65.41.216.221] said: 554 5.7.1 thor.iszerviz.hu[62.77.131.9]: Client host rejected: Mail not accepted from Hungary (in reply to RCPT TO command) Maybe he thinks nobody in Hungary can help him ;-) Mikael Funny that the attitude to block other countries because of spam is mostly present in the USA where most of the spam orginates... Andreas Yes. If I was to block one single country based on how much spam I block from it, that could only be the USA. Mikael
Re: whitelisting problem
Stan Hoeppner a écrit : /dev/rob0 put forth on 12/5/2009 8:44 PM: This post might seem like a gratuitous me-too, and it partly is, but the thing that concerned me, as one of the people responsible for the Spam-L list, was the rejection, in the original post: Dec 4 13:39:15 greer postfix/smtpd[7124]: NOQUEUE: reject: RCPT from unknown[204.238.179.8]: 450 4.7.1 mx1.mfn.org: Helo command rejected: Host not found; from=spam-l-boun...@spam-l.com to=s...@hardwarefreak.com proto=ESMTP helo=mx1.mfn.org Unknown? Here's what I get: 8.179.238.204.in-addr.arpa. 3600 IN PTR mx1.mfn.org. mx1.mfn.org.14400 IN A 204.238.179.8 That looks like perfect FCrDNS to me. So another issue you ought to look at: why is your resolver failing on this? Is it consistent? Yeah, I know. Already chatted with Alif about it. This 450 temp fail is what started all of this. I only whitelist 3 IPs of spam-l, and even before, I've never had a problem. I still got the mail obviously, but I wanted to figure out why my white list entry for spam-l didn't trigger. Thanks to many here, I now know why and am fixing it. It's looking like I was having transient issues with my resolvers. I did some more log digging and found more dns related temp fails than I should be having given my mail volume. I've since switched from the old resolvers to the new free Google resolvers. So far so good. If I run into problems there, I'll switch again or setup my own caching resolver. Use your own resolver. a default BIND setup does this. why do you ask someone else? your ISP, google, ... won't give you a reliable DNS service. I have stopped using mine (free.fr, i.e. the best in .fr when it comes to network ability) when my postfix rejected my own mail because the client IP was listed in spamhaus. after checking, it was obviously not. and the last poison story (the famous bug) shows that it is better to use one's own resolver (of course, this goes against the cache story, but...).
Re: whitelisting problem
Stan Hoeppner a écrit : mouss put forth on 12/5/2009 7:50 AM: you need to read the docs :) Isn't that always the case here. :) an OK in an smtpd_foo_restrictions skips further checks in _that_ restriction. so an OK in smtpd_client_restrictions skips further checks and goes to smtpd_helo_restrictions. Aha! Thanks mouss. I was under the assumption that first match wins means exactly that. I thought _all_ other checks were skipped after an OK. for mail to be accepted, it needs to get an OK in _each_ restriction. by default, all but smtpd_recipient_restrictions return OK, but since you edited yours... So, first match wins only applies within a restriction class. Missed that in the docs during previous reads. postfix access allow implementing AND friends linearly, which is nice. it gives you the ability to say: - if their head is square, reject. else continue - if they have 3 hands, reject. else continue. - if they have 3 eyes, reject. else continue. ... so at each step/stage, you get rid of a group of offenders. This is far better than having to deal with complex logic. NOT, OR and AND are much more complex to deal with in general. This is why I suggested (in my previous post) that you put all your checks under smtpd_recipient_restrictions. Among other things, this avoids the need to duplicate whitelisting actions. Sanity checking and ease of troubleshooting is precisely why I'd kept them separated for years, so each check type was in its respective class heading. I guess given the things I'm doing with my static lists, it makes no sense to continue my current method, given it makes the troubleshooting _more_ difficult... I prefer to use a linear sequence. it's easier to manage, and it's also easier to test (why this wasn't blocked and why was this blocked). It can even be scripted (I yet to publish the script...).
[OT?] blocking replies (WAS: whitelisting problem)
Sta[snip] Sanity checking and ease of troubleshooting is precisely why I'd kept them separated for years, so each check type was in its respective class heading. I guess given the things I'm doing with my static lists, it makes no sense to continue my current method, given it makes the troubleshooting _more_ difficult... Thanks again mouss. I'm looking through you, where did you go: s...@hardwarefreak.com: host greer.hardwarefreak.com[65.41.216.221] said: 554 5.7.1 imlil.netoyen.net[91.121.103.130]: Client host rejected: Access denied (in reply to RCPT TO command) It is nice to not reject mail from people who help you...
Re: [OT?] blocking replies (WAS: whitelisting problem)
mouss put forth on 12/7/2009 3:52 PM: I'm looking through you, where did you go: s...@hardwarefreak.com: host greer.hardwarefreak.com[65.41.216.221] said: 554 5.7.1 imlil.netoyen.net[91.121.103.130]: Client host rejected: Access denied (in reply to RCPT TO command) It is nice to not reject mail from people who help you... Sorry 'bout that mouss. Had blocked part of your parent (OVH) long ago and it snagged you. Fixed. Maybe hold off a little before sending me anything as I'm getting ready to take my MX down for a bit for some hardware maintenance (and I don't run a backup MX). -- Stan
Re: [OT?] blocking replies (WAS: whitelisting problem)
On Mon, 07 Dec 2009, Stan Hoeppner wrote: mouss put forth on 12/7/2009 3:52 PM: I'm looking through you, where did you go: s...@hardwarefreak.com: host greer.hardwarefreak.com[65.41.216.221] said: 554 5.7.1 imlil.netoyen.net[91.121.103.130]: Client host rejected: Access denied (in reply to RCPT TO command) It is nice to not reject mail from people who help you... Sorry 'bout that mouss. Had blocked part of your parent (OVH) long ago and it snagged you. Fixed. I hoped the block was not based on something stupid like country (in this case, France). Maybe hold off a little before sending me anything as I'm getting ready to take my MX down for a bit for some hardware maintenance (and I don't run a backup MX). Shouldn't matter. His server will retry if it cannot reach yours during downtime. :-) -- Sahil Tandon sa...@tandon.net
Re: whitelisting problem
On Sat, 05 Dec 2009 21:32:02 -0600 Stan Hoeppner s...@hardwarefreak.com wrote: It's looking like I was having transient issues with my resolvers. I did some more log digging and found more dns related temp fails than I should be having given my mail volume. I've since switched from the old resolvers to the new free Google resolvers. So far so good. If I run into problems there, I'll switch again or setup my own caching resolver. Stan, I don't know anything about Google's resolvers. I only know you'd be better off with reliable resolvers you can control when running an MX and rely on reverse DNS to be OK and use DNS blocklists. We use only local DNS resolvers, and do not have problems many others have. It's not difficult to set up, so there's no point rely on a third party for such basic and important service. Mikael
Re: whitelisting problem
Michael Orlitzky put forth on 12/5/2009 1:38 AM: Stan Hoeppner wrote: I can't figure out why my whitelist entry for 204.238.179.0/24 is being ignored. If not for a transient DNS failure this afternoon I'd not have known this was broken. The check_client_access whitelist entry _should_ have triggered before reject_unknown_client_hostname. Any ideas why is doesn't/didn't? ... Dec 4 13:39:15 greer postfix/smtpd[7124]: NOQUEUE: reject: RCPT from unknown[204.238.179.8]: 450 4.7.1 mx1.mfn.org: Helo command rejected: Host not found; from=spam-l-boun...@spam-l.com to=s...@hardwarefreak.com proto=ESMTP helo=mx1.mfn.org Any clues as to what's wrong? You rejected the HELO hostname, not the IP address. What is reject_unknown_helo_hostname going to do when your DNS is broken? You missed the point entirely because you went after the low hanging fruit, calling out you read the rejection wrong!. Re-read my email and tell me why there was a rejection at all; why the email wasn't accepted as it should have been. If you'd actually read my entire email the first time, you wouldn't have answered as you did. You'll likely have to go for the fruit at the top of the tree to get the right answer. I've been on the top branch all day and can't figure it out, thus my email to the list. -- Stan
Re: whitelisting problem
* Stan Hoeppner s...@hardwarefreak.com: smtpd_helo_required = yes smtpd_helo_restrictions = check_recipient_access hash:/etc/postfix/access Did you mean check_helo_access? Stefan reject_non_fqdn_helo_hostname reject_invalid_helo_hostname reject_unknown_helo_hostname smtpd_recipient_restrictions = permit_mynetworks reject_unauth_destination reject_unlisted_recipient check_recipient_access hash:/etc/postfix/access reject_rbl_client zen.spamhaus.org check_policy_service inet:127.0.0.1:6 /etc/postfix/access ... 66.135.197 OK 168.100.1 OK 204.238.179 OK spam-l-boun...@spam-l.com OK owner-postfix-us...@cloud9.net OK majordomo-ow...@cloud9.net OK owner-postfix-us...@postfix.org OK ... Dec 4 13:39:15 greer postfix/smtpd[7124]: NOQUEUE: reject: RCPT from unknown[204.238.179.8]: 450 4.7.1 mx1.mfn.org: Helo command rejected: Host not found; from=spam-l-boun...@spam-l.com to=s...@hardwarefreak.com proto=ESMTP helo=mx1.mfn.org Any clues as to what's wrong? -- Stan
Re: whitelisting problem
Stefan Förster put forth on 12/5/2009 5:46 AM: * Stan Hoeppner s...@hardwarefreak.com: smtpd_helo_required = yes smtpd_helo_restrictions = check_recipient_access hash:/etc/postfix/access Did you mean check_helo_access? What does this have to do with the question I asked? How would this cause the problem I'm inquiring about? Why have two members now completely missed the problem? -- Stan
Re: whitelisting problem
Hallo Stan, * Stan Hoeppner s...@hardwarefreak.com: Stefan Förster put forth on 12/5/2009 5:46 AM: * Stan Hoeppner s...@hardwarefreak.com: smtpd_helo_required = yes smtpd_helo_restrictions = check_recipient_access hash:/etc/postfix/access Did you mean check_helo_access? What does this have to do with the question I asked? How would this cause the problem I'm inquiring about? Why have two members now completely missed the problem? Rejection message: | Dec 4 13:39:15 greer postfix/smtpd[7124]: NOQUEUE: reject: RCPT from | unknown[204.238.179.8]: 450 4.7.1 mx1.mfn.org: Helo command rejected: | Host not found; from=spam-l-boun...@spam-l.com | to=s...@hardwarefreak.com proto=ESMTP helo=mx1.mfn.org Obviously triggered by the reject_unknown_helo_hostname in: |smtpd_helo_restrictions = |check_recipient_access hash:/etc/postfix/access |reject_non_fqdn_helo_hostname |reject_invalid_helo_hostname |reject_unknown_helo_hostname Whitelist doesn't trigger because you are performing a check for the value of the RCPT TO parameter, not the HELO or EHLO. If this isn't what you were looking for I don't have any idea what your question is. Stefan
Re: whitelisting problem
* Stefan Förster cite+postfix-us...@incertum.net: Rejection message: | Dec 4 13:39:15 greer postfix/smtpd[7124]: NOQUEUE: reject: RCPT from | unknown[204.238.179.8]: 450 4.7.1 mx1.mfn.org: Helo command rejected: | Host not found; from=spam-l-boun...@spam-l.com | to=s...@hardwarefreak.com proto=ESMTP helo=mx1.mfn.org Obviously triggered by the reject_unknown_helo_hostname in: |smtpd_helo_restrictions = |check_recipient_access hash:/etc/postfix/access |reject_non_fqdn_helo_hostname |reject_invalid_helo_hostname |reject_unknown_helo_hostname Whitelist doesn't trigger because you are performing a check for the value of the RCPT TO parameter, not the HELO or EHLO. Addendum: You can use check_client_access here. Stefan
Re: whitelisting problem
Stefan Förster put forth on 12/5/2009 6:16 AM: Whitelist doesn't trigger because you are performing a check for the value of the RCPT TO parameter, not the HELO or EHLO. If this isn't what you were looking for I don't have any idea what your question is. You're not seeing the forest for the trees. Look at my original post again. Within /etc/postfix/access there is a class C network listed with OK that matches the IP address of the rejected sending host. That should have caused the email to be accepted. Also, in smtpd_sender_restrictions, there is a whitelist entry in /etc/postfix/access that matches the sender address in the mail that was rejected. Once again, smtpd_sender_restrictions comes before smtpd_helo_restrictions in my main.cf, so even if for some unknown reason the client check whitelist entry failed, the sender check whitelist entry should have caused the email to be accepted. Two classes before smtpd_helo_restrictions should have triggered accepting the email. The message should have never made it to the HELO checks. It should have been accepted in smtpd_client_restrictions or smtpd_sender_restrictions. Both classes come before smtpd_helo_restrictions in my main.cf. How is everyone missing this? You're fixated on the darn error message. We all know what caused the error, a DNS lookup failure. That's not rocket science and has nothing to do with the problem. The problem is that the restriction processing order isn't being followed for some reason. Why isn't it? _THAT_ is the problem I'm asking for help with. That was clear in my first email, was it not? -- Stan
Re: whitelisting problem
Stan Hoeppner a écrit : I can't figure out why my whitelist entry for 204.238.179.0/24 is being ignored. If not for a transient DNS failure this afternoon I'd not have known this was broken. The check_client_access whitelist entry _should_ have triggered before reject_unknown_client_hostname. Any ideas why is doesn't/didn't? [snip] smtpd_helo_restrictions = check_recipient_access hash:/etc/postfix/access reject_non_fqdn_helo_hostname reject_invalid_helo_hostname Look at this one: reject_unknown_helo_hostname [snip] ... Dec 4 13:39:15 greer postfix/smtpd[7124]: NOQUEUE: reject: RCPT from unknown[204.238.179.8]: 450 4.7.1 mx1.mfn.org: Helo command rejected: Host not found; from=spam-l-boun...@spam-l.com to=s...@hardwarefreak.com proto=ESMTP helo=mx1.mfn.org Any clues as to what's wrong? there is no check_client_access wihtelist in your smtpd_helo_restrictions, (before reject_unknown_helo_hostname). to avoid having to repeat your whitelists under every smtpd_mumble_restrictions, consider putting all your anti-spam checks under smtpd_recipient_restrictions. Also, avoid using a single /etc/postfix/access for different check_mumble_access. use one file per check (the checks are not looking for the same thing. so mixing the maps is not clean, and makes troubleshooting harder). smtpd_recipient_restrictions = reject_non_fqdn_sender reject_non_fqdn_recipient permit_mynetworks reject_unauth_destination # reject_unlisted_recipient reject_unlisted_sender # check_recipient_access hash:/etc/postfix/access_recipient check_client_access hash:/etc/postfix/access_client check_helo_access hash:/etc/postfix/access_helo check_sender_access hash:/etc/postfix/access_sender ... reject_unknown_client_hostname reject_non_fqdn_helo_hostname reject_invalid_helo_hostname reject_unknown_helo_hostname # reject_rbl_client zen.spamhaus.org check_policy_service inet:127.0.0.1:6
Re: whitelisting problem
Stan Hoeppner a écrit : Stefan Förster put forth on 12/5/2009 6:16 AM: Whitelist doesn't trigger because you are performing a check for the value of the RCPT TO parameter, not the HELO or EHLO. If this isn't what you were looking for I don't have any idea what your question is. You're not seeing the forest for the trees. Look at my original post again. Within /etc/postfix/access there is a class C network listed with OK that matches the IP address of the rejected sending host. That should have caused the email to be accepted. Also, in smtpd_sender_restrictions, there is a whitelist entry in /etc/postfix/access that matches the sender address in the mail that was rejected. Once again, smtpd_sender_restrictions comes before smtpd_helo_restrictions in my main.cf, so even if for some unknown reason the client check whitelist entry failed, the sender check whitelist entry should have caused the email to be accepted. Two classes before smtpd_helo_restrictions should have triggered accepting the email. The message should have never made it to the HELO checks. It should have been accepted in smtpd_client_restrictions or smtpd_sender_restrictions. Both classes come before smtpd_helo_restrictions in my main.cf. you need to read the docs :) an OK in an smtpd_foo_restrictions skips further checks in _that_ restriction. so an OK in smtpd_client_restrictions skips further checks and goes to smtpd_helo_restrictions. for mail to be accepted, it needs to get an OK in _each_ restriction. by default, all but smtpd_recipient_restrictions return OK, but since you edited yours... This is why I suggested (in my previous post) that you put all your checks under smtpd_recipient_restrictions. Among other things, this avoids the need to duplicate whitelisting actions. [snip]
Re: whitelisting problem
* Stan Hoeppner s...@hardwarefreak.com: Two classes before smtpd_helo_restrictions should have triggered accepting the email. The message should have never made it to the HELO checks. It should have been accepted in smtpd_client_restrictions or smtpd_sender_restrictions. Both classes come before smtpd_helo_restrictions in my main.cf. The order in which checks are evaluated is the one in which the criterion to be checkd is made available to Postfix: 1. client IP address 2. HELO hostname 3. MAIL FROM aka sender 4. RCPT TO, aka recipient(s) 5. DATA 6. . How is everyone missing this? You're fixated on the darn error message. We all know what caused the error, a DNS lookup failure. That's not rocket science and has nothing to do with the problem. The problem is that the restriction processing order isn't being followed for some reason. Why isn't it? _THAT_ is the problem I'm asking for help with. That was clear in my first email, was it not? Postfix behaves according to the documentation. The documentation doesn't say that an OK from a check_client_access results in an OK for the HELO restrictions. And no, it was not clear from your first posting that you had a serious misunderstanding of how Postfix access control works. Your first posting simply suggested that you worked a whole night, couldn't barely keep your eyes open (5:46am) and therefore mixed check_recipient_access with check_client_access in your smtpd_helo_restrictions. Stefan
Re: whitelisting problem
Stan Hoeppner wrote: Michael Orlitzky put forth on 12/5/2009 1:38 AM: Stan Hoeppner wrote: I can't figure out why my whitelist entry for 204.238.179.0/24 is being You rejected the HELO hostname, not the IP address. What is reject_unknown_helo_hostname going to do when your DNS is broken? You missed the point entirely because you went after the low hanging fruit, calling out you read the rejection wrong!. Re-read my email and tell me why there was a rejection at all; why the email wasn't accepted as it should have been. If you'd actually read my entire email the first time, you wouldn't have answered as you did. You'll likely have to go for the fruit at the top of the tree to get the right answer. I've been on the top branch all day and can't figure it out, thus my email to the list. -- Stan Let's start from the beginning. Here's your access map: /etc/postfix/access ... 66.135.197 OK 168.100.1 OK 204.238.179 OK spam-l-boun...@spam-l.com OK owner-postfix-us...@cloud9.net OK majordomo-ow...@cloud9.net OK owner-postfix-us...@postfix.org OK ... Now, a client connects. Your restrictions begin to be evaluated. The first class to get evaluated is smtpd_client_restrictions: smtpd_client_restrictions = check_recipient_access hash:/etc/postfix/access check_client_access hash:/etc/postfix/access ... ... reject_unknown_client_hostname reject_unauth_pipelining Here, check_recipient_access does nothing, because the recipient (you) is not listed in the access map. The next restriction, check_client_access, matches on the client, 204.238.179.8. A result of OK is returned for smtpd_client_restrictions, and we move on to smtpd_helo_restrictions. smtpd_helo_restrictions = check_recipient_access hash:/etc/postfix/access reject_non_fqdn_helo_hostname reject_invalid_helo_hostname reject_unknown_helo_hostname The first restriction, check_recipient_access, looks up the RECIPIENT'S ADDRESS in your access map. Since the recipient's address is not listed, this check does nothing, and we move on the next one. The non_fqdn/invalid checks pass, but then when we get to reject_unknown_helo_hostname, the message is rejected, because you can't look up the host name. I think what you mean to do here is check_client_access (as opposed to check_recipient_access). You could also use check_helo_access, but then you'd have to add that machine's HELO hostname to the access map.
Re: whitelisting problem
On Sat, Dec 05, 2009 at 05:34:03AM -0600, Stan Hoeppner wrote: You'll likely have to go for the fruit at the top of the tree to get the right answer. I've been on the top branch all day and can't figure it out, thus my email to the list. Climb down from the tree. Your answer was among the fallen fruit laying on the ground. Everyone in this thread but you seems to understand what happened. This is a classic example of why it's generally better to keep your restrictions in ONE STAGE unless you have a good reason not to, and of course, a good understanding of how multiple restriction stages wok (independently of one another: the simple fact that was lying beneath the tree, rotting.) ANY rejection in ANY stage means the mail is rejected. Doesn't matter how many whitelists you check in other stages. You forgot it in one that mattered. When whitelisting in smtpd_recipient_restrictions, be careful with how it's done. Use permit_auth_destination rather than OK unless you really did intend to allow relaying. The same thing can be done with whitelisting restrictions after reject_unauth_destination. Also give heed to mouss' advice about splitting up the access maps by type of lookup. No point in listing IP addresses in a sender or HELO lookup map. No point in listing email addresses in a client lookup map. Domain names can be in any, but are you sure you want to do the same thing for any of client, helo, sender and recipient lookups? This post might seem like a gratuitous me-too, and it partly is, but the thing that concerned me, as one of the people responsible for the Spam-L list, was the rejection, in the original post: Dec 4 13:39:15 greer postfix/smtpd[7124]: NOQUEUE: reject: RCPT from unknown[204.238.179.8]: 450 4.7.1 mx1.mfn.org: Helo command rejected: Host not found; from=spam-l-boun...@spam-l.com to=s...@hardwarefreak.com proto=ESMTP helo=mx1.mfn.org Unknown? Here's what I get: 8.179.238.204.in-addr.arpa. 3600 IN PTR mx1.mfn.org. mx1.mfn.org.14400 IN A 204.238.179.8 That looks like perfect FCrDNS to me. So another issue you ought to look at: why is your resolver failing on this? Is it consistent? -- Offlist mail to this address is discarded unless /dev/rob0 or not-spam is in Subject: header
Re: whitelisting problem
mouss put forth on 12/5/2009 7:50 AM: you need to read the docs :) Isn't that always the case here. :) an OK in an smtpd_foo_restrictions skips further checks in _that_ restriction. so an OK in smtpd_client_restrictions skips further checks and goes to smtpd_helo_restrictions. Aha! Thanks mouss. I was under the assumption that first match wins means exactly that. I thought _all_ other checks were skipped after an OK. for mail to be accepted, it needs to get an OK in _each_ restriction. by default, all but smtpd_recipient_restrictions return OK, but since you edited yours... So, first match wins only applies within a restriction class. Missed that in the docs during previous reads. This is why I suggested (in my previous post) that you put all your checks under smtpd_recipient_restrictions. Among other things, this avoids the need to duplicate whitelisting actions. Sanity checking and ease of troubleshooting is precisely why I'd kept them separated for years, so each check type was in its respective class heading. I guess given the things I'm doing with my static lists, it makes no sense to continue my current method, given it makes the troubleshooting _more_ difficult... Thanks again mouss. -- Stan
Re: whitelisting problem
Stefan Förster put forth on 12/5/2009 8:51 AM: * Stan Hoeppner s...@hardwarefreak.com: Two classes before smtpd_helo_restrictions should have triggered accepting the email. The message should have never made it to the HELO checks. It should have been accepted in smtpd_client_restrictions or smtpd_sender_restrictions. Both classes come before smtpd_helo_restrictions in my main.cf. The order in which checks are evaluated is the one in which the criterion to be checkd is made available to Postfix: 1. client IP address 2. HELO hostname 3. MAIL FROM aka sender 4. RCPT TO, aka recipient(s) 5. DATA 6. . How is everyone missing this? You're fixated on the darn error message. We all know what caused the error, a DNS lookup failure. That's not rocket science and has nothing to do with the problem. The problem is that the restriction processing order isn't being followed for some reason. Why isn't it? _THAT_ is the problem I'm asking for help with. That was clear in my first email, was it not? Postfix behaves according to the documentation. The documentation doesn't say that an OK from a check_client_access results in an OK for the HELO restrictions. And no, it was not clear from your first posting that you had a serious misunderstanding of how Postfix access control works. Your first posting simply suggested that you worked a whole night, couldn't barely keep your eyes open (5:46am) and therefore mixed check_recipient_access with check_client_access in your smtpd_helo_restrictions. Nah, as I said to mouss, I was under the assumption that first match wins meant all other class checks were ignored. Given that, you can understand why I was pulling my hair out trying to identify the problem. Thanks for your patience. -- Stan
Re: whitelisting problem
Michael Orlitzky put forth on 12/5/2009 9:03 AM: I think what you mean to do here is check_client_access (as opposed to check_recipient_access). You could also use check_helo_access, but then you'd have to add that machine's HELO hostname to the access map. The reason for the check_recipient_access everyone is for two spam trap addresses that are intentionally omitted from my post. I did that upon someone's recommendation long ago without realizing the reason for it: first match wins is _per_ restriction class, not across all classes. Thanks for assisting. -- Stan
Re: whitelisting problem
Sahil Tandon put forth on 12/5/2009 1:49 PM: Why the hostility? Frustration, lack of rest, likely. Apologies. The others are just trying to help. :) Mouss already answered your question correctly, but you should review: http://www.postfix.org/SMTPD_ACCESS_README.html to understand how restriction lists are evaluated. I understand now, didn't then. Thanks for the link. Have read it at least twice (man) but apparently never grasped the per class issue. I've definitely got it now lol! -- Stan
Re: whitelisting problem
/dev/rob0 put forth on 12/5/2009 8:44 PM: This post might seem like a gratuitous me-too, and it partly is, but the thing that concerned me, as one of the people responsible for the Spam-L list, was the rejection, in the original post: Dec 4 13:39:15 greer postfix/smtpd[7124]: NOQUEUE: reject: RCPT from unknown[204.238.179.8]: 450 4.7.1 mx1.mfn.org: Helo command rejected: Host not found; from=spam-l-boun...@spam-l.com to=s...@hardwarefreak.com proto=ESMTP helo=mx1.mfn.org Unknown? Here's what I get: 8.179.238.204.in-addr.arpa. 3600 IN PTR mx1.mfn.org. mx1.mfn.org.14400 IN A 204.238.179.8 That looks like perfect FCrDNS to me. So another issue you ought to look at: why is your resolver failing on this? Is it consistent? Yeah, I know. Already chatted with Alif about it. This 450 temp fail is what started all of this. I still got the mail obviously, but I wanted to figure out why my white list entry for spam-l didn't trigger. Thanks to many here, I now know why and am fixing it. It's looking like I was having transient issues with my resolvers. I did some more log digging and found more dns related temp fails than I should be having given my mail volume. I've since switched from the old resolvers to the new free Google resolvers. So far so good. If I run into problems there, I'll switch again or setup my own caching resolver. -- Stan
whitelisting problem
I can't figure out why my whitelist entry for 204.238.179.0/24 is being ignored. If not for a transient DNS failure this afternoon I'd not have known this was broken. The check_client_access whitelist entry _should_ have triggered before reject_unknown_client_hostname. Any ideas why is doesn't/didn't? parent_domain_matches_subdomains = debug_peer_list smtpd_access_maps smtpd_client_restrictions = check_recipient_access hash:/etc/postfix/access check_client_access hash:/etc/postfix/access ... ... reject_unknown_client_hostname reject_unauth_pipelining smtpd_sender_restrictions = check_sender_access hash:/etc/postfix/access reject_non_fqdn_sender smtpd_helo_required = yes smtpd_helo_restrictions = check_recipient_access hash:/etc/postfix/access reject_non_fqdn_helo_hostname reject_invalid_helo_hostname reject_unknown_helo_hostname smtpd_recipient_restrictions = permit_mynetworks reject_unauth_destination reject_unlisted_recipient check_recipient_access hash:/etc/postfix/access reject_rbl_client zen.spamhaus.org check_policy_service inet:127.0.0.1:6 /etc/postfix/access ... 66.135.197 OK 168.100.1 OK 204.238.179 OK spam-l-boun...@spam-l.com OK owner-postfix-us...@cloud9.net OK majordomo-ow...@cloud9.net OK owner-postfix-us...@postfix.org OK ... Dec 4 13:39:15 greer postfix/smtpd[7124]: NOQUEUE: reject: RCPT from unknown[204.238.179.8]: 450 4.7.1 mx1.mfn.org: Helo command rejected: Host not found; from=spam-l-boun...@spam-l.com to=s...@hardwarefreak.com proto=ESMTP helo=mx1.mfn.org Any clues as to what's wrong? -- Stan
Re: whitelisting problem
Stan Hoeppner wrote: I can't figure out why my whitelist entry for 204.238.179.0/24 is being ignored. If not for a transient DNS failure this afternoon I'd not have known this was broken. The check_client_access whitelist entry _should_ have triggered before reject_unknown_client_hostname. Any ideas why is doesn't/didn't? ... Dec 4 13:39:15 greer postfix/smtpd[7124]: NOQUEUE: reject: RCPT from unknown[204.238.179.8]: 450 4.7.1 mx1.mfn.org: Helo command rejected: Host not found; from=spam-l-boun...@spam-l.com to=s...@hardwarefreak.com proto=ESMTP helo=mx1.mfn.org Any clues as to what's wrong? You rejected the HELO hostname, not the IP address. What is reject_unknown_helo_hostname going to do when your DNS is broken?
