RE: I've just found a new and interesting spam source - legitimatebounce messages
The term coined for this type of mail is backscatter. There is no easy solution for this. The backscatter article on postfix.org, for example, caused our mail servers to start rejecting mail that was generated from PHP scripts and CGIs on our own systems, which makes no sense. The article: http://www.postfix.org/BACKSCATTER_README.html If the backscatter is all directed to a single Email address (rather than a series of addresses, e.g. [EMAIL PROTECTED], and you have [EMAIL PROTECTED] accepted), then a solution is to reject mail with an RCPT TO of an account or virtual address that does not exist on your machine. This, of course, has a wonderful side effect: spammers now have a way to detect what Email addresses on your box legitimately accept mail, thus once they find one which never gets a bounceback, will start pounding that address to kingdom come. Let me know if you do find a reliable, decent solution that does not involve SPF or postfix header_checks or body_checks. The following doesn't fix the problem but it does help mitigate the deluge. We use a PERL script to tail our maillogs looking for any source IP that tries to send mail to more than 4 invalid addresses. When flagged, that IP is then added to a PF table that blocks the address and issues RST's for 12 hours. Of course, we also have a whitelist for valid SMTP servers. Like I said, it doesn't catch it all, but it catches *a lot* and generates almost no complaints. This does help obfuscate the valid/invalid addresses because all mail is accepted as far as the sender is concerned until the IP is blocked at the network layer. The usual complaint is from an remote office that has 12 real estate agents behind a single IP, all with Outlook set to check mail sooner than now. :-) Mike PGP.sig Description: PGP signature
Re: I've just found a new and interesting spam source - legitimatebounce messages
On Monday 20 October 2008, Michael K. Smith - Adhost said: The term coined for this type of mail is backscatter. There is no easy solution for this. The backscatter article on postfix.org, for example, caused our mail servers to start rejecting mail that was generated from PHP scripts and CGIs on our own systems, which makes no sense. The article: http://www.postfix.org/BACKSCATTER_README.html If the backscatter is all directed to a single Email address (rather than a series of addresses, e.g. [EMAIL PROTECTED], and you have [EMAIL PROTECTED] accepted), then a solution is to reject mail with an RCPT TO of an account or virtual address that does not exist on your machine. This, of course, has a wonderful side effect: spammers now have a way to detect what Email addresses on your box legitimately accept mail, thus once they find one which never gets a bounceback, will start pounding that address to kingdom come. Let me know if you do find a reliable, decent solution that does not involve SPF or postfix header_checks or body_checks. The following doesn't fix the problem but it does help mitigate the deluge. We use a PERL script to tail our maillogs looking for any source IP that tries to send mail to more than 4 invalid addresses. When flagged, that IP is then added to a PF table that blocks the address and issues RST's for 12 hours. Of course, we also have a whitelist for valid SMTP servers. Like I said, it doesn't catch it all, but it catches *a lot* and generates almost no complaints. This does help obfuscate the valid/invalid addresses because all mail is accepted as far as the sender is concerned until the IP is blocked at the network layer. The usual complaint is from an remote office that has 12 real estate agents behind a single IP, all with Outlook set to check mail sooner than now. :-) Mike SpamAssassin also has a backscatter feature, you just have to enable it. It tags backscatter and hands it off to procmail. From there you can easily do whatever you want with the tagged mail including kick off a script to block the offending IP. In my case I just dump it along with any spam to /dev/null. It works so well I had to bounce a couple of emails just to make sure it wasn't also grabbing mine. Nope, anything I bounce gets delivered. My backscatter is now virtually zero. Of course like everything else SpamAssassin it's tuneable. It's a very good solution without a lot of heavy lifting. Beech -- --- Beech Rintoul - FreeBSD Developer - [EMAIL PROTECTED] /\ ASCII Ribbon Campaign | FreeBSD Since 4.x \ / - NO HTML/RTF in e-mail | http://people.freebsd.org/~beech X - NO Word docs in e-mail | Skype: akbeech / \ - http://www.FreeBSD.org/releases/7.0R/announce.html --- ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: I've just found a new and interesting spam source - legitimatebounce messages
--On Monday, October 20, 2008 10:24:28 -0500 Michael K. Smith - Adhost [EMAIL PROTECTED] wrote: Let me know if you do find a reliable, decent solution that does not involve SPF or postfix header_checks or body_checks. The following doesn't fix the problem but it does help mitigate the deluge. We use a PERL script to tail our maillogs looking for any source IP that tries to send mail to more than 4 invalid addresses. When flagged, that IP is then added to a PF table that blocks the address and issues RST's for 12 hours. Of course, we also have a whitelist for valid SMTP servers. Like I said, it doesn't catch it all, but it catches *a lot* and generates almost no complaints. This does help obfuscate the valid/invalid addresses because all mail is accepted as far as the sender is concerned until the IP is blocked at the network layer. The usual complaint is from an remote office that has 12 real estate agents behind a single IP, all with Outlook set to check mail sooner than now. :-) The best solution *by far* that I have found for spam (using Postfix) is mail/postfix-policyd-weight. It routinely rejects 50 to 70% of incoming mail with no false positives. It took *very* little tweaking to get it to this point, and it rejects the mail before postfix even deals with it. I use spamassassin as well, but policyd-weight does the heavy lifting. Here's one example of a rejected email: Oct 20 11:11:16 mail postfix/policyd-weight[77973]: weighted check: IN_DYN_PBL_SPAMHAUS=3.25 NOT_IN_SBL_XBL_SPAMHAUS=-1.5 NOT_IN_SPAMCOP=-1.5 NOT_IN_BL_NJABL=-1.5 CL_IP_NE_HELO=4.75 REV_IP_EQ_HELO=-1.25 NOK_HELO_SEEMS_DIALUP=5 (check from: .hinet. - helo: .dsl.dynamic8121373125.ttnet. - helo-domain: .ttnet.) FROM/MX_MATCHES_NOT_UNVR_HELO(DOMAIN)=4.85 CLIENT_NOT_MX/A_FROM_DOMAIN=4.75 CLIENT/24_NOT_MX/A_FROM_DOMAIN=4.75; client=81.213.73.125 helo=dsl.dynamic8121373125.ttnet.net.tr [EMAIL PROTECTED] [EMAIL PROTECTED]; rate: 21.6 Oct 20 11:11:16 mail postfix/policyd-weight[77973]: decided action=550 Mail appeared to be SPAM or forged. Ask your Mail/DNS-Administrator to correct HELO and DNS MX settings or to get removed from DNSBLs; please relay via your ISP (ms35.hinet.net); Please use DynDNS; client=81.213.73.125 helo=dsl.dynamic8121373125.ttnet.net.tr [EMAIL PROTECTED] [EMAIL PROTECTED]; delay: 8s Anything above 1 is rejected. This email scored 21.6, which is off the charts. It even does greylisting. Oct 20 10:45:47 mail postfix/policyd-weight[28339]: decided action=550 temporarily blocked because of previous errors - retrying too fast. penalty: 30 seconds x 0 retries.; client=189.141.58.189 helo=dsl-189-141-58-189.prod-infinitum.com.mx [EMAIL PROTECTED] [EMAIL PROTECTED]; delay: 0s Oct 20 10:46:51 mail postfix/policyd-weight[28339]: decided action=550 temporarily blocked because of previous errors - retrying too fast. penalty: 30 seconds x 0 retries.; client=65.110.50.188 helo=boomfm.dnsalias.com [EMAIL PROTECTED] [EMAIL PROTECTED]; delay: 0s It does let some spam through, which spamassassin catches, but it rejects all the bogus stuff (fake hostnames, bogus MTAs, forged from addresses, etc., etc.) -- Paul Schmehl ([EMAIL PROTECTED]) Senior Information Security Analyst The University of Texas at Dallas http://www.utdallas.edu/ir/security/
Re: I've just found a new and interesting spam source - legitimatebounce messages
On Mon, Oct 20, 2008 at 11:16:31AM -0500, Paul Schmehl wrote: --On Monday, October 20, 2008 10:24:28 -0500 Michael K. Smith - Adhost [EMAIL PROTECTED] wrote: Let me know if you do find a reliable, decent solution that does not involve SPF or postfix header_checks or body_checks. The following doesn't fix the problem but it does help mitigate the deluge. We use a PERL script to tail our maillogs looking for any source IP that tries to send mail to more than 4 invalid addresses. When flagged, that IP is then added to a PF table that blocks the address and issues RST's for 12 hours. Of course, we also have a whitelist for valid SMTP servers. Like I said, it doesn't catch it all, but it catches *a lot* and generates almost no complaints. This does help obfuscate the valid/invalid addresses because all mail is accepted as far as the sender is concerned until the IP is blocked at the network layer. The usual complaint is from an remote office that has 12 real estate agents behind a single IP, all with Outlook set to check mail sooner than now. :-) The best solution *by far* that I have found for spam (using Postfix) is mail/postfix-policyd-weight. It routinely rejects 50 to 70% of incoming mail with no false positives. It took *very* little tweaking to get it to this point, and it rejects the mail before postfix even deals with it. I use spamassassin as well, but policyd-weight does the heavy lifting. Here's one example of a rejected email: Oct 20 11:11:16 mail postfix/policyd-weight[77973]: weighted check: IN_DYN_PBL_SPAMHAUS=3.25 NOT_IN_SBL_XBL_SPAMHAUS=-1.5 NOT_IN_SPAMCOP=-1.5 NOT_IN_BL_NJABL=-1.5 CL_IP_NE_HELO=4.75 REV_IP_EQ_HELO=-1.25 NOK_HELO_SEEMS_DIALUP=5 (check from: .hinet. - helo: .dsl.dynamic8121373125.ttnet. - helo-domain: .ttnet.) FROM/MX_MATCHES_NOT_UNVR_HELO(DOMAIN)=4.85 CLIENT_NOT_MX/A_FROM_DOMAIN=4.75 CLIENT/24_NOT_MX/A_FROM_DOMAIN=4.75; client=81.213.73.125 helo=dsl.dynamic8121373125.ttnet.net.tr [EMAIL PROTECTED] [EMAIL PROTECTED]; rate: 21.6 Oct 20 11:11:16 mail postfix/policyd-weight[77973]: decided action=550 Mail appeared to be SPAM or forged. Ask your Mail/DNS-Administrator to correct HELO and DNS MX settings or to get removed from DNSBLs; please relay via your ISP (ms35.hinet.net); Please use DynDNS; client=81.213.73.125 helo=dsl.dynamic8121373125.ttnet.net.tr [EMAIL PROTECTED] [EMAIL PROTECTED]; delay: 8s Anything above 1 is rejected. This email scored 21.6, which is off the charts. It even does greylisting. Oct 20 10:45:47 mail postfix/policyd-weight[28339]: decided action=550 temporarily blocked because of previous errors - retrying too fast. penalty: 30 seconds x 0 retries.; client=189.141.58.189 helo=dsl-189-141-58-189.prod-infinitum.com.mx [EMAIL PROTECTED] [EMAIL PROTECTED]; delay: 0s Oct 20 10:46:51 mail postfix/policyd-weight[28339]: decided action=550 temporarily blocked because of previous errors - retrying too fast. penalty: 30 seconds x 0 retries.; client=65.110.50.188 helo=boomfm.dnsalias.com [EMAIL PROTECTED] [EMAIL PROTECTED]; delay: 0s It does let some spam through, which spamassassin catches, but it rejects all the bogus stuff (fake hostnames, bogus MTAs, forged from addresses, etc., etc.) We used to use numerous features in postfix to block mail during different phases of the SMTP handshake, requiring strings meet RFC standards, comply with being FQDNs, resolve, blah blah... It worked great... until... One day, one of my users mailed me stating they were in a lot of trouble: they hadn't been receiving any mails from eBay, specifically contact from buyers/sellers (to negotiate payment means, etc.), and outbid notifications. I went digging through logs, and sure enough found the cause: eBay's HELO strings were what pedants would call absolutely preposterous. They violated 3 or 4 different checks postfix had. At first I tuned postfix to allow certain IP blocks through that check, only to find that it's nearly impossible to determine all of the IP blocks eBay has -- in fact, some of their mail gets siphoned through a third-party mailer, and it looks like that mailer uses IPs all over the place. Meaning: administrative nightmare. There is nothing worse than telling your users Okay, I've fixed it, only to get mail from them 24 hours later stating Umm, no you didn't, and this is really starting to piss me off. I went through the same ordeal with other users and their LiveJournal mail notifications being blocked. The point I'm trying to make is that all this overly-aggressive filtering might work great if you're one guy maintaining your own box only used by you -- and I have a feeling a lot of people who post on this list are exactly that. It's a **completely** different game when you've got other people reliant upon your mail filtering decisions. The problem with blocking mail early on (meaning before it's queued, e.g. SMTP 5xx or 4xx rejections) is
Re: I've just found a new and interesting spam source - legitimatebounce messages
--On Monday, October 20, 2008 10:11:36 -0700 Jeremy Chadwick [EMAIL PROTECTED] wrote: On Mon, Oct 20, 2008 at 11:16:31AM -0500, Paul Schmehl wrote: The best solution *by far* that I have found for spam (using Postfix) is mail/postfix-policyd-weight. It routinely rejects 50 to 70% of incoming mail with no false positives. It took *very* little tweaking to get it to this point, and it rejects the mail before postfix even deals with it. I use spamassassin as well, but policyd-weight does the heavy lifting. We used to use numerous features in postfix to block mail during different phases of the SMTP handshake, requiring strings meet RFC standards, comply with being FQDNs, resolve, blah blah... It worked great... until... One day, one of my users mailed me stating they were in a lot of trouble: they hadn't been receiving any mails from eBay, specifically contact from buyers/sellers (to negotiate payment means, etc.), and outbid notifications. I went digging through logs, and sure enough found the cause: eBay's HELO strings were what pedants would call absolutely preposterous. They violated 3 or 4 different checks postfix had. At first I tuned postfix to allow certain IP blocks through that check, only to find that it's nearly impossible to determine all of the IP blocks eBay has -- in fact, some of their mail gets siphoned through a third-party mailer, and it looks like that mailer uses IPs all over the place. Meaning: administrative nightmare. There is nothing worse than telling your users Okay, I've fixed it, only to get mail from them 24 hours later stating Umm, no you didn't, and this is really starting to piss me off. I went through the same ordeal with other users and their LiveJournal mail notifications being blocked. The point I'm trying to make is that all this overly-aggressive filtering might work great if you're one guy maintaining your own box only used by you -- and I have a feeling a lot of people who post on this list are exactly that. It's a **completely** different game when you've got other people reliant upon your mail filtering decisions. The problem with blocking mail early on (meaning before it's queued, e.g. SMTP 5xx or 4xx rejections) is that the end-user has no knowledge of this. They simply do not get the mail. They're left in the dark, wondering Did person send the mail? Are they lying to me? What's going on???. It's a very sensitive thing when you're a hosting provider. In the case of my users, they would much rather get the mail and have it incorrectly flagged as spam, than not get it at all. I personally believe this directly reflects on the state of anti-spam affairs: we've gotten so aggressive that *who KNOWS* what kind of legitimate mail we're blocking. That's why it's critically important that whatever tools you use be highly configurable. In the case of policyd-weight, you can configure it so that it passes *everything* through but marks it in such a way that you can filter it appropriately. In my case, I run a small hobby website with a minimal number of email addresses. When I first installed policyd-weight, I watched it closely and discovered it was blocking legitimate mail from sbcglobal because they didn't have their mail servers' dns properly configured. The result was a score just slightly higher than the threshold for rejection (a tenth of a point or two.) I decided to make that particular check worth less overall, and that solved the problem. I have yet to receive a single complaint about mail not getting through, and, although there's only a handful of accounts on the server, we get mail from our website users constantly. I fully understand where you're coming from, Jeremy. We have the same issues at UTD. But for many smaller sites, policyd-weight would be a godsend. -- Paul Schmehl, Senior Infosec Analyst As if it wasn't already obvious, my opinions are my own and not those of my employer. *** Check the headers before clicking on Reply. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: I've just found a new and interesting spam source - legitimatebounce messages
Paul Schmehl wrote: --On Monday, October 20, 2008 10:11:36 -0700 Jeremy Chadwick [EMAIL PROTECTED] wrote: On Mon, Oct 20, 2008 at 11:16:31AM -0500, Paul Schmehl wrote: The best solution *by far* that I have found for spam (using Postfix) is mail/postfix-policyd-weight. It routinely rejects 50 to 70% of incoming mail with no false positives. It took *very* little tweaking to get it to this point, and it rejects the mail before postfix even deals with it. I use spamassassin as well, but policyd-weight does the heavy lifting. We used to use numerous features in postfix to block mail during different phases of the SMTP handshake, requiring strings meet RFC standards, comply with being FQDNs, resolve, blah blah... It worked great... until... One day, one of my users mailed me stating they were in a lot of trouble: they hadn't been receiving any mails from eBay, specifically contact from buyers/sellers (to negotiate payment means, etc.), and outbid notifications. I went digging through logs, and sure enough found the cause: eBay's HELO strings were what pedants would call absolutely preposterous. They violated 3 or 4 different checks postfix had. At first I tuned postfix to allow certain IP blocks through that check, only to find that it's nearly impossible to determine all of the IP blocks eBay has -- in fact, some of their mail gets siphoned through a third-party mailer, and it looks like that mailer uses IPs all over the place. Meaning: administrative nightmare. There is nothing worse than telling your users Okay, I've fixed it, only to get mail from them 24 hours later stating Umm, no you didn't, and this is really starting to piss me off. I went through the same ordeal with other users and their LiveJournal mail notifications being blocked. The point I'm trying to make is that all this overly-aggressive filtering might work great if you're one guy maintaining your own box only used by you -- and I have a feeling a lot of people who post on this list are exactly that. It's a **completely** different game when you've got other people reliant upon your mail filtering decisions. The problem with blocking mail early on (meaning before it's queued, e.g. SMTP 5xx or 4xx rejections) is that the end-user has no knowledge of this. They simply do not get the mail. They're left in the dark, wondering Did person send the mail? Are they lying to me? What's going on???. It's a very sensitive thing when you're a hosting provider. In the case of my users, they would much rather get the mail and have it incorrectly flagged as spam, than not get it at all. I personally believe this directly reflects on the state of anti-spam affairs: we've gotten so aggressive that *who KNOWS* what kind of legitimate mail we're blocking. That's why it's critically important that whatever tools you use be highly configurable. In the case of policyd-weight, you can configure it so that it passes *everything* through but marks it in such a way that you can filter it appropriately. In my case, I run a small hobby website with a minimal number of email addresses. When I first installed policyd-weight, I watched it closely and discovered it was blocking legitimate mail from sbcglobal because they didn't have their mail servers' dns properly configured. The result was a score just slightly higher than the threshold for rejection (a tenth of a point or two.) I decided to make that particular check worth less overall, and that solved the problem. I have yet to receive a single complaint about mail not getting through, and, although there's only a handful of accounts on the server, we get mail from our website users constantly. I fully understand where you're coming from, Jeremy. We have the same issues at UTD. But for many smaller sites, policyd-weight would be a godsend Is there an opinion on the end of policyd-weight? Specifically on the alternative listed on the main page, postfwd. Peter ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
