Stopping spam to postmaster@ account?
Guys, How are you handling all of the spam that is being sent to postmaster@ addresses. In order to be RFC compliant, you are supposed to have postmaster active, but since the spammers have now made this a favorite address, how do you handle it? I'm considering blocking it temporarily to generate rejects to see if that helps. Any other thoughts? -- David C. Rankin, J.D., P.E. RANKIN LAW FIRM, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 (936) 715-9333 (936) 715-9339 fax www.rankinlawfirm.com --
On Monday 03 April 2006 14:31, david rankin wrote:
Guys,
How are you handling all of the spam that is being sent to postmaster@ addresses. In order to be RFC compliant, you are supposed to have postmaster active, but since the spammers have now made this a favorite address, how do you handle it? I'm considering blocking it temporarily to generate rejects to see if that helps. Any other thoughts?
I'm using DSPAM which has a 97% catch rate for all spam. And no fiddling with rules like SA has.
david rankin wrote:
Guys,
How are you handling all of the spam that is being sent to postmaster@ addresses. In order to be RFC compliant, you are supposed to have postmaster active, but since the spammers have now made this a favorite address, how do you handle it? I'm considering blocking it temporarily to generate rejects to see if that helps. Any other thoughts?
Stopping Spam for valid and needed accounts is one of the more difficult challenges of spam fighting. First you have to analyse what kind of Spam you are inflicted with. Is is spam from Zombies with dynamic addresses? -> Use according blacklists and greylisting Is it Spam send from free accounts on Webmailers yahoo, msn etc.? much more difficult, that would have to be handled with care. Is it spam send in great numbers from a few clients? -> Use Anvil, policy-restrictions on mail flow. Sandy -- List replies only please! Please address PMs to: news-reply2 (@) japantest (.) homelinux (.) com
From: "Sandy Drobic" <suse-linux-e@japantest.homelinux.com> david rankin wrote:
Guys,
How are you handling all of the spam that is being sent to postmaster@ addresses. In order to be RFC compliant, you are supposed to have postmaster active, but since the spammers have now made this a favorite address, how do you handle it? I'm considering blocking it temporarily to generate rejects to see if that helps. Any other thoughts?
Stopping Spam for valid and needed accounts is one of the more difficult challenges of spam fighting.
First you have to analyse what kind of Spam you are inflicted with.
Is is spam from Zombies with dynamic addresses? -> Use according blacklists and greylisting Is it Spam send from free accounts on Webmailers yahoo, msn etc.? much more difficult, that would have to be handled with care. Is it spam send in great numbers from a few clients? -> Use Anvil, policy-restrictions on mail flow.
Uhh. Ok, Sandy, how do I do that? Do you have any good links that I can look out to try and classify where the spam is coming from? Here are the headers of 2 received over night: Return-Path: <natural900@gmail.com> X-Original-To: postmaster@rankin-bertin.com Delivered-To: david@rbpllc.com Received: from PC01 (unknown [219.142.253.248]) by bonza.rbpllc.com (Postfix) with ESMTP id 08D6C6BF90 for <postmaster@rankin-bertin.com>; Tue, 4 Apr 2006 03:13:52 -0500 (CDT) Received: from unknown (HELO alt1.gmail-smtp-in.l.google.com) (64.233.167.27) by PC01 with SMTP; Tue, 4 Apr 2006 16:13:59 -0800 From: "Major Woodruff" <natural900@gmail.com> To: <majordomo@rankin-bertin.com> Subject: Hey man, you ever try pheromones? Date: Tue, 4 Apr 2006 16:13:59 -0800 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Thread-Index: Mz4gTwmlyK4kQJ55DfPHGZmw8Bne8S0ktDPV Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: 7bit Message-Id: <20060404081352.08D6C6BF90@bonza.rbpllc.com> Return-Path: <sims.gilboyt19h@gmail.com> X-Original-To: postmaster@rankinlawfirm.com Delivered-To: david@rbpllc.com Received: from CHINESE-3483D2B.yiya4.com (unknown [220.180.234.95]) by bonza.rbpllc.com (Postfix) with ESMTP id A603F6BF90; Tue, 4 Apr 2006 03:14:00 -0500 (CDT) Received: from unknown (HELO gsmtp163.google.com) (64.233.163.27) by CHINESE-3483D2B.yiya4.com with SMTP; Tue, 4 Apr 2006 16:14:00 -0800 From: "Rob Hollis" <sims.gilboyt19h@gmail.com> To: <info@rankinlawfirm.com> Subject: Have you ever tried pheromones? Date: Tue, 4 Apr 2006 16:14:00 -0800 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Thread-Index: T2EkBj7smbvzsTxIZz8XCB1K7yo5nJwgbsFv Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: 7bit Message-Id: <20060404081400.A603F6BF90@bonza.rbpllc.com> Looks like the from line is spoofed and that the mail originated from the Chinese site yiya4.com (I'm not an expert at deciphering headers). So how do I approach stopping this stuff? As always, thank you in advance for your insight. -- David C. Rankin, J.D., P.E. RANKIN LAW FIRM, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 (936) 715-9333 (936) 715-9339 fax www.rankinlawfirm.com --
david rankin wrote:
Stopping Spam for valid and needed accounts is one of the more difficult challenges of spam fighting.
First you have to analyse what kind of Spam you are inflicted with.
Is is spam from Zombies with dynamic addresses? -> Use according blacklists and greylisting Is it Spam send from free accounts on Webmailers yahoo, msn etc.? much more difficult, that would have to be handled with care. Is it spam send in great numbers from a few clients? -> Use Anvil, policy-restrictions on mail flow.
Uhh. Ok, Sandy, how do I do that? Do you have any good links that I can look out to try and classify where the spam is coming from? Here are the headers of 2 received over night:
Received: from PC01 (unknown [219.142.253.248]) by bonza.rbpllc.com (Postfix) with ESMTP id 08D6C6BF90 for <postmaster@rankin-bertin.com>; Tue, 4 Apr 2006 03:13:52 -0500 (CDT)
That is the only header line you can trust: it has been added by your postfix server. And that is telling you that your server has accepted the mail from a client that announced itself in HELO as "PC01" with the IP 219.142.253.248. Furthermore that IP has no Reverse DNS so Postfix regards the hostname as "unknown". dig -x 219.142.253.248 +short gives an empty result, which means it has no reverse DNS entry.
Received: from unknown (HELO alt1.gmail-smtp-in.l.google.com) (64.233.167.27) by PC01 with SMTP; Tue, 4 Apr 2006 16:13:59 -0800
Here PC01 claims, that he received the mail from google. The IP and HELO are indeed from google and it is true that that ip has no reverse dns, shame on google! Though I do not believe that he received the mail from google. That is a line the spammer falsified. There is no reason why google would router their mail via that server with the ip 219.142.253.248.
Return-Path: <sims.gilboyt19h@gmail.com> X-Original-To: postmaster@rankinlawfirm.com Delivered-To: david@rbpllc.com Received: from CHINESE-3483D2B.yiya4.com (unknown [220.180.234.95]) by bonza.rbpllc.com (Postfix) with ESMTP id A603F6BF90; Tue, 4 Apr 2006 03:14:00 -0500 (CDT)
The same for this client: no reverse dns -> unknown IP address of client: 220.180.234.95 HELO of client: CHINESE-3483D2B.yiya4.com dig CHINESE-3483D2B.yiya4.com +short Empty result -> invalid domain.
Received: from unknown (HELO gsmtp163.google.com) (64.233.163.27) by CHINESE-3483D2B.yiya4.com with SMTP; Tue, 4 Apr 2006 16:14:00 -0800
Again, a falsified header line. No reason why google would router their mail via that client.
From: "Rob Hollis" <sims.gilboyt19h@gmail.com> To: <info@rankinlawfirm.com> Subject: Have you ever tried pheromones? Date: Tue, 4 Apr 2006 16:14:00 -0800 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Thread-Index: T2EkBj7smbvzsTxIZz8XCB1K7yo5nJwgbsFv Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: 7bit Message-Id: <20060404081400.A603F6BF90@bonza.rbpllc.com>
Looks like the from line is spoofed and that the mail originated from the Chinese site yiya4.com (I'm not an expert at deciphering headers). So how do I approach stopping this stuff? As always, thank you in advance for your insight.
You are lucky, that kind of spam is typical for zombies with dynamic addresses. There are several ways how you can get rid of that pest. 1. greylisting Most spam clients do not queue their spam and thus you will never see most of the spam. Regular servers will retry and have no problem with greylisting. You should still be prepared to whitelist some morons with broken servers. This requires third party software, a policy server or a greylisting daemon. 2. reject clients with invalid HELO and unknown HELO domains. This is also very effective. Also be prepared to whitelist some morons. 3. Reject based on ip address with a RBL that blocks those IPs. Be prepared to whitelist some clients that are wrongly listed in these RBLs. That is the reason why such RBLs are chancy. Use something like pflogsumm for a daily report what kind of mail was delivered or rejected and the reason it was rejected. Sandy -- List replies only please! Please address PMs to: news-reply2 (@) japantest (.) homelinux (.) com
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Tuesday 2006-04-04 at 17:34 +0200, Sandy Drobic wrote:
That is the only header line you can trust: it has been added by your postfix server. And that is telling you that your server has accepted the mail from a client that announced itself in HELO as "PC01" with the IP 219.142.253.248. Furthermore that IP has no Reverse DNS so Postfix regards the hostname as "unknown".
dig -x 219.142.253.248 +short
gives an empty result, which means it has no reverse DNS entry.
But "whois" gives some info: netname: CHINATELECOM-BJ country: CN descr: CHINANET beijing province network
3. Reject based on ip address with a RBL that blocks those IPs. Be prepared to whitelist some clients that are wrongly listed in these RBLs. That is the reason why such RBLs are chancy.
And also some people like me who send email direct. - -- Cheers, Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFEMq7ntTMYHG2NR9URAixtAJ9PPniYLbM6aSwVVCIvj+mJAhFMsACfWHWx QX/yOg5vDmWQWB1Xzuu+Ldo= =wNpY -----END PGP SIGNATURE-----
Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
The Tuesday 2006-04-04 at 17:34 +0200, Sandy Drobic wrote:
That is the only header line you can trust: it has been added by your postfix server. And that is telling you that your server has accepted the mail from a client that announced itself in HELO as "PC01" with the IP 219.142.253.248. Furthermore that IP has no Reverse DNS so Postfix regards the hostname as "unknown".
dig -x 219.142.253.248 +short
gives an empty result, which means it has no reverse DNS entry.
But "whois" gives some info:
netname: CHINATELECOM-BJ country: CN descr: CHINANET beijing province network
Unfortunately Postfix does not care about whois info. (^-^) I could also mention the restriction "reject_unknown_hostname", although only postmaster that really hate spam more than they love their wanted mail would consider to apply that restriction. (^-^) If anyone is thinking about that restriction I strongly advise to test it first with "warn_if_reject reject_unknown_hostname". That will log a warning but not actually reject the mail. You will probably find out that there are a lot of badly misconfigured "professional" mailservers. :((
3. Reject based on ip address with a RBL that blocks those IPs. Be prepared to whitelist some clients that are wrongly listed in these RBLs. That is the reason why such RBLs are chancy.
And also some people like me who send email direct.
True, many here on this list privately use their own server at home. I do that as well, though I am lucky to have the option to use the mailserver of my provider as relay if some ISP rejects mails from dynamic ip addresses. Sandy -- List replies only please! Please address PMs to: news-reply2 (@) japantest (.) homelinux (.) com
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Tuesday 2006-04-04 at 20:21 +0200, Sandy Drobic wrote:
But "whois" gives some info:
netname: CHINATELECOM-BJ country: CN descr: CHINANET beijing province network
Unfortunately Postfix does not care about whois info. (^-^)
I know. I use that when investigating later.
whitelist some clients that are wrongly listed in these RBLs. That is the reason why such RBLs are chancy.
And also some people like me who send email direct.
True, many here on this list privately use their own server at home. I do that as well, though I am lucky to have the option to use the mailserver of my provider as relay if some ISP rejects mails from dynamic ip addresses.
Unfortunately, I know of several ISPs here that do not allow relaying for their clients based on certain restrictions; some do not allow relaying of other "from" addresses than their own. I still have to find out in which category is my new provider. - -- Cheers, Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFEMsJ3tTMYHG2NR9URAtAhAJ9hJIJqJjnk8pw5LEPa4Oe4CtvUlACglynh e/xCxDRrZoDgVLjKQeDeUpo= =iLh6 -----END PGP SIGNATURE-----
From: "Sandy Drobic" <suse-linux-e@japantest.homelinux.com> Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
The Tuesday 2006-04-04 at 17:34 +0200, Sandy Drobic wrote:
That is the only header line you can trust: it has been added by your postfix server. And that is telling you that your server has accepted the mail from a client that announced itself in HELO as "PC01" with the IP 219.142.253.248. Furthermore that IP has no Reverse DNS so Postfix regards the hostname as "unknown".
dig -x 219.142.253.248 +short
gives an empty result, which means it has no reverse DNS entry.
But "whois" gives some info:
netname: CHINATELECOM-BJ country: CN descr: CHINANET beijing province network
Unfortunately Postfix does not care about whois info. (^-^)
I could also mention the restriction "reject_unknown_hostname", although only postmaster that really hate spam more than they love their wanted mail would consider to apply that restriction. (^-^)
Don't laugh, I tested it (^-^)
If anyone is thinking about that restriction I strongly advise to test it first with "warn_if_reject reject_unknown_hostname". That will log a warning but not actually reject the mail. You will probably find out that there are a lot of badly misconfigured "professional" mailservers. :((
Sandy, how would I modify my my main.cf and /etc/postfix/recipient_check.pcre to do this. Right now I have: [root@bonza david]# cat /etc/postfix/recipient_check.pcre /^support@/ REJECT /^info@/ REJECT /^assistance@(rbpllc\.com|rankin-bertin\.com|guillorylaw\.com|garthlawfirm\.com|drrankin\.com)$/ REJECT /^root@/ REJECT /^sales@/ REJECT /^admin@/ REJECT /^accounting@/ REJECT /^majordomo@/ REJECT #/^postmaster@/ REJECT (commented for testing) postconf -n <snip> smtpd_recipient_restrictions = permit_mynetworks, reject_unauth_destination, check_recipient_access pcre:/etc/postfix/recipient_check.pcre smtpd_sasl_path = /etc/postfix/sasl:/usr/lib/sasl2 unknown_local_recipient_reject_code = 550 -- David C. Rankin, J.D., P.E. RANKIN LAW FIRM, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 (936) 715-9333 (936) 715-9339 fax www.rankinlawfirm.com --
david rankin wrote:
I could also mention the restriction "reject_unknown_hostname", although only postmaster that really hate spam more than they love their wanted mail would consider to apply that restriction. (^-^)
Don't laugh, I tested it (^-^)
Okay, I won't... bwa ha ha ha!! I considered it for about 5 minutes myself. A grep on my log for unknown clients and a check if the mail I got from that client was spam or not yielded a sufficient amount of misconfigured systems that we could not reject. I just saw that it should be "reject_unknown_client" or "reject_unknown_client_hostname" for version 2.3.
If anyone is thinking about that restriction I strongly advise to test it first with "warn_if_reject reject_unknown_hostname". That will log a warning but not actually reject the mail. You will probably find out that there are a lot of badly misconfigured "professional" mailservers. :((
Sandy, how would I modify my my main.cf and /etc/postfix/recipient_check.pcre to do this. Right now I have:
[root@bonza david]# cat /etc/postfix/recipient_check.pcre /^support@/ REJECT /^info@/ REJECT /^assistance@(rbpllc\.com|rankin-bertin\.com|guillorylaw\.com|garthlawfirm\.com|drrankin\.com)$/ REJECT /^root@/ REJECT /^sales@/ REJECT /^admin@/ REJECT /^accounting@/ REJECT /^majordomo@/ REJECT #/^postmaster@/ REJECT (commented for testing)
postconf -n <snip> smtpd_recipient_restrictions = permit_mynetworks, reject_unauth_destination, check_recipient_access pcre:/etc/postfix/recipient_check.pcre smtpd_sasl_path = /etc/postfix/sasl:/usr/lib/sasl2 unknown_local_recipient_reject_code = 550
The easiest way would be to insert it directly behind reject_unauth_destination: smtpd_recipient_restrictions = permit_mynetworks, reject_unauth_destination, # for postfix up to version 2.2: # warn_if_reject reject_unknown_client # for postfix version 2.3: # warn_if_reject reject_unknown_client_hostname check_recipient_access pcre:/etc/postfix/recipient_check.pcre You could also try this one if you are already testing: smtpd_helo_restrictions = permit_mynetworks, warn_if_reject reject_invalid_hostname I found that the number of legit servers that violate this rule is much smaller than those rejected by "reject_unknown_client_hostname". The reason is probably that you can configure the HELO yourself but need the help of the provider to set up correct DNS. That is not always the case, the British BT is notorious for refusing to set up correct reverse DNS. Here is some additional information about reject_unknown_client: http://www.postfix.org/postconf.5.html#unknown_client_reject_code The default is a temporary 450, which is probably a very good idea! http://www.postfix.org/postconf.5.html#reject_unknown_client_hostname Only version 2.3: http://www.postfix.org/postconf.5.html#reject_unknown_reverse_client_hostnam... Why don't you grep your log for the unknown clients and check if the clients were indeed spammers or misconfigured servers? Sandy -- List replies only please! Please address PMs to: news-reply2 (@) japantest (.) homelinux (.) com
Sandy Drobic wrote:
david rankin wrote:
I could also mention the restriction "reject_unknown_hostname", although only postmaster that really hate spam more than they love their wanted mail would consider to apply that restriction. (^-^)
Don't laugh, I tested it (^-^)
Okay, I won't... bwa ha ha ha!!
I considered it for about 5 minutes myself. A grep on my log for unknown clients and a check if the mail I got from that client was spam or not yielded a sufficient amount of misconfigured systems that we could not reject. I just saw that it should be "reject_unknown_client" or "reject_unknown_client_hostname" for version 2.3.
reject_unknown_helo_hostname (for postfix v. 2.2 reject_unknown_hostname) will reject the client if the HELO name the client submitted has no mx or a record.
You could also try this one if you are already testing:
smtpd_helo_restrictions = permit_mynetworks, # check_client_access hash:/etc/postfix/client_whitelist warn_if_reject reject_invalid_hostname warn_if_reject reject_unknown_hostname
/etc/postfix/client_whitelist: 10.0.0.12 PERMIT mail.example.com PERMIT Do not use check_helo_access to whitelist a helo name! The helo name is under the control of the submitting client. You can use the same whitelist mechanism for reject_unknown_client. For the HELO restriction it should work. Though there are some regular servers that will be caught by that restriction. Sandy -- List replies only please! Please address PMs to: news-reply2 (@) japantest (.) homelinux (.) com
participants (4)
-
Bruce Marshall -
Carlos E. R. -
david rankin -
Sandy Drobic