Re: ISP being blocked by us
Ignacio Garcia a écrit : Jorey Bump escribió: Ignacio Garcia wrote, at 06/26/2009 08:38 AM: FROM/MX_MATCHES_NOT_HELO(DOMAIN)=2.9 CLIENT_NOT_MX/A_FROM_DOMAIN=9.1 Both of these rules are absurd. An MX record is only relevant when determining the destination for a domain's email. It has *nothing* to do with relaying to other sites. You should remove these silly checks. or at least, set a decent score. I doubt the default config has these scores. also, use dnswl to skip checking whitelisted IPs. see dsnwl.org. yeah. To be honest, I was thinking the same, but since this problem has appeared only once in 5 years, I guess I was too lazy to get into the policyd-weight script and modify it to disable those tests. I just finally did. Nevertheless, terra.es seems to have some dns problems. ix.dnsbl.manitu.net confirms it. They should fix their problems as well. how? like many large ISPs, they relay both ham and spam. Blocking outbound spam is a hard problem. Thanks to everybody Ignacio
Re: ISP being blocked by us
Hi, Ignacio Garcia wrote: Hi there. We use in our postfix servers several programs to prevent spam (amavisd-new + spamassassin, postgrey, and policyd-weight). We like very much policyd-weight because it bases its blocking decissions on a score calculated by the number of blacklists a server is in. We are, however, puzzled by the fact that we are blocking all incoming email from terra.es, a division of telefonica, the largest ISP in Spain. Before we contact terra's postmaster, Just forget about that... they won't even hear you since they are the largest (and so, must do everything right -- bullshit) we are trying to figure out where the problem is. Although this is a postfix list (and not policyd-weight's), I humbly ask you all email gurus for help since this is more related to rbl and dns stuff than policyd-weight malfunctioning. Here's the log: Not a mail guru, but the approach below does work [snip] Please know that although terra.es show listed twice in rbl lists, we do not block them for that particular reason (we block when anyone is listed 3 times in rbl lists). We are blocking them because of this line: FROM/MX_MATCHES_NOT_HELO(DOMAIN)=2.9 CLIENT_NOT_MX/A_FROM_DOMAIN=9.1 we have checked their dns entries and seem normal (I'm no dns expert though) What we do (without policyd-weight, however): Redirect these problematic domains to a special restriction class (we call it from_freemail) Then, we match the sending server with *any* valid sending server for that domain. Something along the lines: ACCESS (check_sender_access somewhere) terra.es from_telefonica from_telefonica = check_client_access hash:$config_directory/access_from_telefonica /etc/postfix/access_from_telefonica terra.es reject_unauth_destination telefonica.net reject_unauth_destination Any help is much appreciated. That will do the trick, when placed BEFORE check_policy_service (in the recipient_restrictions list, in order to have as much info available for the checks) Cheers,
Re: ISP being blocked by us
Ignacio Garcia schrieb: FROM/MX_MATCHES_NOT_HELO(DOMAIN)=2.9 The helo_name (IMPaqm2.telefonica.net) did not match the sender_domain (terra.es) nor the mx (mx.terra.es). CLIENT_NOT_MX/A_FROM_DOMAIN=9.1 The client_name (IMPaqm2.telefonica.net) did not match the sender_domain (terra.es) nor the mx (mx.terra.es). If you ask me, both tests score by far too high. Afaik it is perfectly valid that sending and receiving hosts differ and that the sender_domain is not related to them.
Re: ISP being blocked by us
José Luis Tallón schrieb: What we do (without policyd-weight, however): Redirect these problematic domains to a special restriction class (we call it from_freemail) Then, we match the sending server with *any* valid sending server for that domain. Something along the lines: ACCESS (check_sender_access somewhere) terra.es from_telefonica from_telefonica = check_client_access hash:$config_directory/access_from_telefonica /etc/postfix/access_from_telefonica terra.es reject_unauth_destination telefonica.net reject_unauth_destination Is it possible that you meant permit_auth_destination instead of reject_unauth_destination? Also this requires that you (manually) determine the valid sending hosts of terra.es which can not be compared to the things policyd-weight does.
Re: ISP being blocked by us
Ignacio Garcia wrote, at 06/26/2009 08:38 AM: FROM/MX_MATCHES_NOT_HELO(DOMAIN)=2.9 CLIENT_NOT_MX/A_FROM_DOMAIN=9.1 Both of these rules are absurd. An MX record is only relevant when determining the destination for a domain's email. It has *nothing* to do with relaying to other sites. You should remove these silly checks.
Re: ISP being blocked by us
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 José Luis Tallón escribió: Hi, Ignacio Garcia wrote: Hi there. We use in our postfix servers several programs to prevent spam (amavisd-new + spamassassin, postgrey, and policyd-weight). We like very much policyd-weight because it bases its blocking decissions on a score calculated by the number of blacklists a server is in. We are, however, puzzled by the fact that we are blocking all incoming email from terra.es, a division of telefonica, the largest ISP in Spain. Before we contact terra's postmaster, Just forget about that... they won't even hear you since they are the largest (and so, must do everything right -- bullshit) we are trying to figure out where the problem is. Although this is a postfix list (and not policyd-weight's), I humbly ask you all email gurus for help since this is more related to rbl and dns stuff than policyd-weight malfunctioning. Here's the log: Not a mail guru, but the approach below does work [snip] Please know that although terra.es show listed twice in rbl lists, we do not block them for that particular reason (we block when anyone is listed 3 times in rbl lists). We are blocking them because of this line: FROM/MX_MATCHES_NOT_HELO(DOMAIN)=2.9 CLIENT_NOT_MX/A_FROM_DOMAIN=9.1 we have checked their dns entries and seem normal (I'm no dns expert though) What we do (without policyd-weight, however): Redirect these problematic domains to a special restriction class (we call it from_freemail) Then, we match the sending server with *any* valid sending server for that domain. Something along the lines: ACCESS (check_sender_access somewhere) terra.es from_telefonica from_telefonica = check_client_access hash:$config_directory/access_from_telefonica /etc/postfix/access_from_telefonica terra.es reject_unauth_destination telefonica.net reject_unauth_destination Any help is much appreciated. That will do the trick, when placed BEFORE check_policy_service (in the recipient_restrictions list, in order to have as much info available for the checks) Cheers, Thanks all for your reply. Ok, terra.es sends through telefonica.net. However, emails coming from telefonica.net go through policyd-weight without any trouble, so I guess the second entry in $config_directory/access_from_telefonica (telefonica.net ...) is not necessary, right? our smtpd_recipient_restrictions is as follows: smtpd_recipient_restrictions = reject_unauth_pipelining, reject_unknown_recipient_domain, permit_mynetworks, permit_sasl_authenticated, check_recipient_access mysql:/etc/postfix/mysql-virtual_recipient.cf, reject_unauth_destination, check_client_access hash:/etc/postfix/host_whitelist, check_client_access hash:/etc/postfix/relay_whitelist, check_policy_service inet:127.0.0.1:12525, check_client_access regexp:/etc/postfix/check_client_fqdn, check_sender_access regexp:/etc/postfix/filter_catchall_10024 where heck_policy_service inet:127.0.0.1:12525 is policyd-weight Therefore, after declaring in main.cf: from_telefonica = check_client_access hash:$config_directory/access_from_telefonica I'd leave it like this: mtpd_recipient_restrictions = reject_unauth_pipelining, reject_unknown_recipient_domain, permit_mynetworks, permit_sasl_authenticated, check_recipient_access mysql:/etc/postfix/mysql-virtual_recipient.cf, reject_unauth_destination, check_client_access hash:/etc/postfix/host_whitelist, check_client_access hash:/etc/postfix/relay_whitelist, from_telefonica, check_policy_service inet:127.0.0.1:12525, check_client_access regexp:/etc/postfix/check_client_fqdn, check_sender_access regexp:/etc/postfix/filter_catchall_10024 I added from_telefonica right before policyd-weight Now, I understand that after going to from_telefonica, the rest of the declarations will be ignored. If that is correct, I'll have to add them to the file /etc/postfix/access_from_telefonica. In that case, can I add several statements for terra.es as in? terra.escheck_client_access regexp:/etc/postfix/check_client_fqdn, check_sender_access regexp:/etc/postfix/filter_catchall_10024 (all in one line, of course) Thanks very much in advance Ignacio -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkpE2fAACgkQoYMx3fsuWuq0/ACgj8oS0CbU7i2ieFsw0QAfa7VR 3OQAn3ZghzY/tGKyt1EFBulXtUiNDYbe =TunR -END PGP SIGNATURE-
Re: ISP being blocked by us
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jorey Bump escribió: Ignacio Garcia wrote, at 06/26/2009 08:38 AM: FROM/MX_MATCHES_NOT_HELO(DOMAIN)=2.9 CLIENT_NOT_MX/A_FROM_DOMAIN=9.1 Both of these rules are absurd. An MX record is only relevant when determining the destination for a domain's email. It has *nothing* to do with relaying to other sites. You should remove these silly checks. yeah. To be honest, I was thinking the same, but since this problem has appeared only once in 5 years, I guess I was too lazy to get into the policyd-weight script and modify it to disable those tests. I just finally did. Nevertheless, terra.es seems to have some dns problems. ix.dnsbl.manitu.net confirms it. They should fix their problems as well. Thanks to everybody Ignacio -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkpE7RAACgkQoYMx3fsuWupTMQCfeUSP2VSYaNWa0yICcBZYTRDi wiEAoM1ki35dGmYSg4W6vG22VDOXZl0C =YV7u -END PGP SIGNATURE-
