Re: A better backscatter killer?
Dennis Carr wrote: Looking at options here for eliminating backscatter. I've reviewed the Howto for this, but it only seems to be effective against backscatter where one's home domain is forged - not too useful, IMNSHO, because spammers aren't always going to forge the home domain. One thing I've been looking at doing is basically checking headers, and if the From: header is null, then reject it immediately. Other approach is to eliminate my 2ary MX from DNS - most of my spam comes from that. I don't really want to do that, though, because the idea of a 2ary MX is for a fallback. Do recipient verification on your secondary MX. Or even better, don't use a secondary MX. Real servers sending to you, will try again. If you expect to have more than four odd days at a time, you have bigger things to worry about anyway. --kj
Re: Now OT. Terminating thread (was Re: A better backscatter killer?)
W dniu 2009-04-15 04:21, Rod Whitworth pisze: --Original Message Text--- *From:* Pawe+‚ Le+›niak *Date:* Tue, 14 Apr 2009 14:50:57 +0200 8 snip- I don't like top-posting but.. Due to your message formatting it is not possible for someone to easily see who said what in your reply. So simply for the benefit of others who may have had a passing interest, I'll make closing comments. Talking about formatting - try to use somewhat newer client, with good message formatting. I have no problem to follow the thread. All talk about RFCs in your message is irrelevant because messages from the null sender addressed to a fictitious recipient will NEVER be delivered anyway. RFC3834 is NOT a standard BTW, and we should hope it never is as it contemplates things like sending virus notifications. Echhhk! Have a look at http://www.postfix.org/bounce.8.html. Specially part STANDARDS. So it looks like RFC3834 IS a standard indeed. So we trapit to invalid addresses and reading the logs shows that the probability of those messages being bounces from servers configured by amateurs is something like .77. You can do whatever you want. But do not enforce others to break RFCs. Talking about amateurs ... I do agree with that. But you won't do any good by messing. It would give better effect if you'd report them to some RBLs. If they get blacklisted with zen, they'll have to think over their configuration. You have no idea how little load this places on our firewall. It is not even measurable when there is a spambot storm in progress. It does not consume any Postfix resources. It also seems that the tarpitting we do on other spammy senders is noticed by some of them as the number of trapped IPs at any instant is now about a quarter of what it was a year ago. We don't slow down our network by tarpitting. The sender gets 1 char/ 4 seconds and typically gives up after about 1500 seconds with the settings I use. I did not mean your network. If there were many sites like your, it would be simple to fill up network attacked by few spambots. Have you ever thought that some sites share network connection? Of course it gives up after first limit (client or server side) occurs. So it can be 300 seconds when sender stops (5 minutes limit is proposed in standard), or any other limit configured at the other side. For more info see http://www.openbsd.org/cgi-bin/man.cgi?query=spamdapropos=0sektion=0manpath=OpenBSD+Currentarch=i386format=html And that's all folks! Back to lurking for me. One more thing... you forgot to comment the part about what kind of emails can be sent with null sender address. - SAV - Auto-replies- - (...)Since in most cases it is not appropriate to respond to an automatic response, and the responder is not interested in delivery status messages, a MAIL FROM address of MAY be used for this purpose.(...)- RFC3834 - Any type of automated notifications (...)In some types of reporting messages for which a reply is likely to cause a mail loop (for example, mail delivery and nondelivery notifications), the reverse-path may be null (see section 3.7).(...)- RFC2821 Still - you can do whatever you want. Pawel Lesniak
Re: A better backscatter killer?
* MacShane, Tracy tracy.macsh...@airservicesaustralia.com: Then you won't receive some genuine messages, both bounce and non-bounce. Try the ips.backscatterer.org RBL; it works well for us. http://www.mailinglistarchive.com/postfix-users@postfix.org/msg57402.html They are retarded. mail.charite.de is listed in it. -- Ralf Hildebrandt Postfix - Einrichtung, Betrieb und Wartung Tel. +49 (0)30-450 570-155 http://www.computerbeschimpfung.de MMDF: A jumped up mailroom boy with a chip on his shoulder. Loves the bureaucracy and takes great pride in stamping illegal address in red ink on any mail it passes. Unpacks all the mail and repacks it in his own special envelopes before delivery to end users.
Re: A better backscatter killer?
On Tue, 14 Apr 2009 09:24:09 +0200, Pawe+ Le+niak wrote: W dniu 2009-04-14 08:06, Ralf Hildebrandt pisze: They are retarded. mail.charite.de is listed in it. You're definitely not right. Testresult for 141.42.4.200: This IP IS CURRENTLY NOT LISTED in our Database. B U T, it was listed in the past ! History: 2008/05/13 08:49listed 2008/06/10 09:30expired 2008/07/08 09:38listed 2008/08/22 11:30expired 2009/03/02 17:00listed 2009/04/12 13:07expired If they send too many bounces, or do SAV, they are listed on backscatterer.org. That's simple. Further - BECAUSE they are sending too many bounces it's quite good to stop receiving bounces from them. Anyways, I've found that backscatterer.org is able to stop large flows of backscatter if they happen. When I was getting backscatter from many different IPs, backscatterer.org was not helping at all. But that's when body_checks work perfectly. As long as I'm a small site with ~10-20k SMTP connections daily, I'm fine with this configuration. Also I've found that 2 months after starting to use body_checks, the number of rejects lowered dramatically from ~15-45k daily to ~10-18k daily. More precisely number of rejects lowered from ~850k in january to ~410k in march. Pawel Lesniak Oh dear, that's all really too much trouble. I have OpenBSD's spamd running in front of my MTA. A script checks all greylisted entries for invalid recipients with sender and tarpits them. You cannot have a legitimate bounce going to an invalid sender for bleedin' obvious reasons. So stick it to 'em. It wastes resources on all the misconfigured bounce-instead-of-reject dummies out there and places no load on my lovely Postfix server. Heh! *** NOTE *** Please DO NOT CC me. I am subscribed to the list. Mail to the sender address that does not originate at the list server is tarpitted. The reply-to: address is provided for those who feel compelled to reply off list. Thankyou. Rod/ /earth: write failed, file system is full cp: /earth/creatures: No space left on device
Re: A better backscatter killer?
On Tue, 14 Apr 2009 12:27:55 +0200, Pawe+ Le+niak wrote: W dniu 2009-04-14 11:56, Rod Whitworth pisze: Oh dear, that's all really too much trouble. I have OpenBSD's spamd running in front of my MTA. A script checks all greylisted entries for invalid recipients with sender and tarpits them. If mail goes to invalid recipient it can be *rejected*. It's not really dependent on sender. Of course, but it is a low cost way of punishing the dills who don't configure their MX properly. You cannot have a legitimate bounce going to an invalid sender for bleedin' obvious reasons. So stick it to 'em. I hope you mean recipient not sender. It was a forged sender (to the backscatter source) and in our case they could not have been the true sender because they do not exist as valid recipients of incoming mail. i.e. they are not our users. Remember I did say that I was applying this to null sender to non-existing recipients (who were purported to be the original senders). We have about 60 spamtrap addresses. Most invented by spammers. Are you sure that null sender is only used in bounces? What else? It wastes resources on all the misconfigured bounce-instead-of-reject dummies out there and places no load on my lovely Postfix server. Heh! Could you explain how? If you greylist those mails instead of rejecting, you are getting additional SMTP connection(s). If you reject them, they are discarded. What am I missing? They are detected whilst they are in the greylist and then they are grey-trapped (tar-pitted in other words) Rod/ /earth: write failed, file system is full cp: /earth/creatures: No space left on device Check your storage. Check the population of /earth for yourself ... ;-( *** NOTE *** Please DO NOT CC me. I am subscribed to the list. Mail to the sender address that does not originate at the list server is tarpitted. The reply-to: address is provided for those who feel compelled to reply off list. Thankyou. Rod/ /earth: write failed, file system is full cp: /earth/creatures: No space left on device
Re: A better backscatter killer?
W dniu 2009-04-14 11:56, Rod Whitworth pisze: Oh dear, that's all really too much trouble. I have OpenBSD's spamd running in front of my MTA. A script checks all greylisted entries for invalid recipients with sender and tarpits them. If mail goes to invalid recipient it can be *rejected*. It's not really dependent on sender. You cannot have a legitimate bounce going to an invalid sender for bleedin' obvious reasons. So stick it to 'em. I hope you mean recipient not sender. Are you sure that null sender is only used in bounces? It wastes resources on all the misconfigured bounce-instead-of-reject dummies out there and places no load on my lovely Postfix server. Heh! Could you explain how? If you greylist those mails instead of rejecting, you are getting additional SMTP connection(s). If you reject them, they are discarded. What am I missing? Rod/ /earth: write failed, file system is full cp: /earth/creatures: No space left on device Check your storage. Pawel Lesniak
Re: A better backscatter killer?
W dniu 2009-04-14 13:54, Rod Whitworth pisze: Remember I did say that I was applying this to null sender to non-existing recipients (who were purported to be the original senders). We have about 60 spamtrap addresses. Most invented by spammers. I'd imagine somewhat better usage of spam-traps then grey-jail. And if it's system-wide - read on. Are you sure that null sender is only used in bounces? What else? - SAV - Auto-replies (...)Since in most cases it is not appropriate to respond to an automatic response, and the responder is not interested in delivery status messages, a MAIL FROM address of MAY be used for this purpose.(...) RFC3834 - Any type of automated notifications (...)In some types of reporting messages for which a reply is likely to cause a mail loop (for example, mail delivery and nondelivery notifications), the reverse-path may be null (see section 3.7).(...) RFC2821 It wastes resources on all the misconfigured bounce-instead-of-reject dummies out there and places no load on my lovely Postfix server. Heh! Could you explain how? If you greylist those mails instead of rejecting, you are getting additional SMTP connection(s). If you reject them, they are discarded. What am I missing? They are detected whilst they are in the greylist and then they are grey-trapped (tar-pitted in other words) IMHO: You are wasting also your resources, and you are slowing down the network. While it's almost sure the other side will not correct configuration, the prize is smaller than the price. Rod/ /earth: write failed, file system is full cp: /earth/creatures: No space left on device Check your storage. Check the population of /earth for yourself ... ;-( There's still some room ;-) Pawel Lesniak
Re: A better backscatter killer?
Ralf Hildebrandt a écrit : * MacShane, Tracy tracy.macsh...@airservicesaustralia.com: Then you won't receive some genuine messages, both bounce and non-bounce. Try the ips.backscatterer.org RBL; it works well for us. http://www.mailinglistarchive.com/postfix-users@postfix.org/msg57402.html They are retarded. mail.charite.de is listed in it. and I guess postfix members would be bothered to block: camomile.cloud9.net[168.100.1.3] english-breakfast.cloud9.net[168.100.1.7] $ host 3.1.100.168.ips.backscatterer.org 3.1.100.168.ips.backscatterer.org has address 127.0.0.2 $ host 7.1.100.168.ips.backscatterer.org 7.1.100.168.ips.backscatterer.org has address 127.0.0.2 so if one uses this list, then - use a whitelist (dnswl and possibly local WL) - use it in smtpd_data_restrictions to avoid blocking SAV sources. while you may hate SAV, it's different than backscatter.
Re: A better backscatter killer?
Noel Jones a écrit : Dennis Carr wrote: Looking at options here for eliminating backscatter. I've reviewed the Howto for this, but it only seems to be effective against backscatter where one's home domain is forged - not too useful, IMNSHO, because spammers aren't always going to forge the home domain. and how do you receive it otherwise? I guess he meant they don't forge the Received header. [snip]
Re: A better backscatter killer?
W dniu 2009-04-14 23:11, mouss pisze: Ralf Hildebrandt a écrit : * MacShane, Tracytracy.macsh...@airservicesaustralia.com: Then you won't receive some genuine messages, both bounce and non-bounce. Try the ips.backscatterer.org RBL; it works well for us. http://www.mailinglistarchive.com/postfix-users@postfix.org/msg57402.html They are retarded. mail.charite.de is listed in it. and I guess postfix members would be bothered to block: camomile.cloud9.net[168.100.1.3] english-breakfast.cloud9.net[168.100.1.7] $ host 3.1.100.168.ips.backscatterer.org 3.1.100.168.ips.backscatterer.org has address 127.0.0.2 $ host 7.1.100.168.ips.backscatterer.org 7.1.100.168.ips.backscatterer.org has address 127.0.0.2 so if one uses this list, then - use a whitelist (dnswl and possibly local WL) - use it in smtpd_data_restrictions to avoid blocking SAV sources. while you may hate SAV, it's different than backscatter. I think that you're missing something. I'm getting emails from this list as: owner-***...@.org - warl...@lesniakowie.com Where's the place where emails would be rejected? Is this list doing SAV? I'd even ask - is ANY list doing SAV? It's hard for me to imagine sending thousands of emails to users who had already confirmed email address during registration. Pawel Lesniak
Re: A better backscatter killer?
Paweł Leśniak a écrit : W dniu 2009-04-14 23:11, mouss pisze: Ralf Hildebrandt a écrit : * MacShane, Tracy tracy.macsh...@airservicesaustralia.com: Then you won't receive some genuine messages, both bounce and non-bounce. Try the ips.backscatterer.org RBL; it works well for us. http://www.mailinglistarchive.com/postfix-users@postfix.org/msg57402.html They are retarded. mail.charite.de is listed in it. and I guess postfix members would be bothered to block: camomile.cloud9.net[168.100.1.3] english-breakfast.cloud9.net[168.100.1.7] $ host 3.1.100.168.ips.backscatterer.org 3.1.100.168.ips.backscatterer.org has address 127.0.0.2 $ host 7.1.100.168.ips.backscatterer.org 7.1.100.168.ips.backscatterer.org has address 127.0.0.2 so if one uses this list, then - use a whitelist (dnswl and possibly local WL) - use it in smtpd_data_restrictions to avoid blocking SAV sources. while you may hate SAV, it's different than backscatter. I think that you're missing something. I'm getting emails from this list as: owner-***...@.org - warl...@lesniakowie.com it doesn't matter. if you block bounces from the server, you'll block all bounces, be them legitimate or backscatter. the problem with backscatterer.org is that we have no idea why IPs are listed. mixing SAV and backscatter sources is a bad idea. I am not a fan of SAV, but this is a different problem than backscatter. anyway, let's not discuss this here as it is off topic. feel free to contact me offlist if you want. Where's the place where emails would be rejected? Is this list doing SAV? I'd even ask - is ANY list doing SAV? It's hard for me to imagine sending thousands of emails to users who had already confirmed email address during registration. unfortunately, there are a few issues: - membership validation is done by the list manager software, at delivery time, long after the first relay has accepted the message. - most list managers use the From: header to validate membership sure, the list of valid members may be exported to be used by the relay, but it's not how things are done, and MLMs don't make it easy (the only free one I know of that makes this easy is sympa).
Re: A better backscatter killer?
Paweł Leśniak wrote: I'd even ask - is ANY list doing SAV? It's hard for me to imagine sending thousands of emails to users who had already confirmed email address during registration. Some lists accept posts from un sub scribed senders. Some of those lists do SAV. Some of the sourceforge lists fall in this category. And yes, they probe registered senders too. If you want to play with them, you need to accept their probes. -- Noel Jones
RE: A better backscatter killer?
-Original Message- From: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] On Behalf Of mouss Sent: Wednesday, 15 April 2009 7:11 AM To: postfix-users@postfix.org Subject: Re: A better backscatter killer? Ralf Hildebrandt a écrit : * MacShane, Tracy tracy.macsh...@airservicesaustralia.com: Then you won't receive some genuine messages, both bounce and non-bounce. Try the ips.backscatterer.org RBL; it works well for us. http://www.mailinglistarchive.com/postfix-users@postfix.org/msg57402. html They are retarded. mail.charite.de is listed in it. and I guess postfix members would be bothered to block: camomile.cloud9.net[168.100.1.3] english-breakfast.cloud9.net[168.100.1.7] $ host 3.1.100.168.ips.backscatterer.org 3.1.100.168.ips.backscatterer.org has address 127.0.0.2 $ host 7.1.100.168.ips.backscatterer.org 7.1.100.168.ips.backscatterer.org has address 127.0.0.2 so if one uses this list, then - use a whitelist (dnswl and possibly local WL) - use it in smtpd_data_restrictions to avoid blocking SAV sources. while you may hate SAV, it's different than backscatter. I do whitelist one of our backscatterers, since it's our Defence department. As it happens, it seems all of the backscatter I've trapped from them *is* backscatter, because they're bounces to non-existent addresses or evident spam messages. But I accept it all from them just in case. And yes, my restriction is in smtpd_data_restrictions, as shown in the original message I linked to. Frankly, I'm not that fussed about blocking potential bounces from list mail. Also, if I were running an ISP rather than a corporate email system, I probably wouldn't use this RBL. I do wish there were a slightly less problematic one - ie. one that would respond promptly to requests for removal without gouging 50 euro, and which didn't care so much about SAV - but I don't think it's *that* problematic. Our main source of spam that was getting through our header checks was from backscatter, and since I've instituted the RBL, it has entirely gone. Only a couple of hundred or so messages a day currently, but it makes a difference to our end-users, some of whom were disproportionally affected by the problem (we have a tag-and-forward content scanner, and some of these individuals were having to review and discard hundreds of messages a week).
Now OT. Terminating thread (was Re: A better backscatter killer?)
--Original Message Text--- From: Pawe+ Le+niak Date: Tue, 14 Apr 2009 14:50:57 +0200 8 snip- I don't like top-posting but.. Due to your message formatting it is not possible for someone to easily see who said what in your reply. So simply for the benefit of others who may have had a passing interest, I'll make closing comments. All talk about RFCs in your message is irrelevant because messages from the null sender addressed to a fictitious recipient will NEVER be delivered anyway. RFC3834 is NOT a standard BTW, and we should hope it never is as it contemplates things like sending virus notifications. Echhhk! So we trapit to invalid addresses and reading the logs shows that the probability of those messages being bounces from servers configured by amateurs is something like .77. You have no idea how little load this places on our firewall. It is not even measurable when there is a spambot storm in progress. It does not consume any Postfix resources. It also seems that the tarpitting we do on other spammy senders is noticed by some of them as the number of trapped IPs at any instant is now about a quarter of what it was a year ago. We don't slow down our network by tarpitting. The sender gets 1 char/ 4 seconds and typically gives up after about 1500 seconds with the settings I use. For more info see http://www.openbsd.org/cgi-bin/man.cgi?query=spamdapropos=0sektion=0m anpath=OpenBSD+Currentarch=i386format=html And that's all folks! Back to lurking for me. - W dniu 2009-04-14 13:54, Rod Whitworth pisze: Remember I did say that I was applying this to null sender to non-existing recipients (who were purported to be the original senders). We have about 60 spamtrap addresses. Most invented by spammers. I'd imagine somewhat better usage of spam-traps then grey-jail. And if it's system-wide - read on. Are you sure that null sender is only used in bounces? What else? - SAV - Auto-replies- - (...)Since in most cases it is not appropriate to respond to - - an automatic response, and the responder is not interested in - - delivery status messages, a MAIL FROM address of MAY be used for - - this purpose.(...)- RFC3834 - Any type of automated notifications (...)In some types of - - reporting messages for which a reply is likely to cause a mail loop - - (for example, mail delivery and nondelivery notifications), the - - reverse-path may be null (see section 3.7).(...)- RFC2821 It wastes resources on all the misconfigured bounce-instead-of-reject dummies out there and places no load on my lovely Postfix server. Heh! Could you explain how? If you greylist those mails instead of rejecting, you are getting additional SMTP connection(s). If you reject them, they are discarded. What am I missing? They are detected whilst they are in the greylist and then they are grey-trapped (tar-pitted in other words) IMHO: You are wasting also your resources, and you are slowing down the network. While it's almost sure the other side will not correct configuration, the prize is smaller than the price. Rod/ /earth: write failed, file system is full cp: /earth/creatures: No space left on device Check your storage. Check the population of /earth for yourself ... ;-( There's still some room ;-) Not enough for all the irresponsible breeders. Pawel Lesniak *** NOTE *** Please DO NOT CC me. I am subscribed to the list. Mail to the sender address that does not originate at the list server is tarpitted. The reply-to: address is provided for those who feel compelled to reply off list. Thankyou. Rod/ /earth: write failed, file system is full cp: /earth/creatures: No space left on device
