Folks, I'm looking for comments / suggestions / opinions from any providers that have been contacted by spamhaus about excessive queries originating from their DNS resolvers, typically, as a proxy for customers. I know that certain large DNS providers (i.e. google and level3) have either been banned or have voluntarily blocked spamhaus queries by their resolvers. We're currently in discussion with spamhaus and I wanted to see how others may have handled this. Thanks! --Lou
On Feb 17, 2010, at 5:32 PM, Laczo, Louis wrote:
I'm looking for comments / suggestions / opinions from any providers that have been contacted by spamhaus about excessive queries originating from their DNS resolvers, typically, as a proxy for customers. I know that certain large DNS providers (i.e. google and level3) have either been banned or have voluntarily blocked spamhaus queries by their resolvers. We're currently in discussion with spamhaus and I wanted to see how others may have handled this.
I believe you can pay them a small fee and do a zone transfer so you are not hitting their name servers. If you see value in the service, it should be worth the small fee. And since you are hitting them a lot, I have a feeling that you see value in the service. -- TTFN, patrick
I'm looking for comments / suggestions / opinions from any providers
Yes, at under 12 cents per user per *year* it's definitely worthwhile in my personal opinion... I know several providers who have taken their commercial service either because they wanted an SLA or because they were contacted by Spamhaus because of their traffic levels.... that price is rough and totally depends on how many email accounts you've got.... -p -----Original Message----- From: Patrick W. Gilmore [mailto:patrick@ianai.net] Sent: February-17-10 6:35 PM To: NANOG list Subject: Re: Spamhaus... On Feb 17, 2010, at 5:32 PM, Laczo, Louis wrote: that have been contacted by spamhaus about excessive queries originating from their DNS resolvers, typically, as a proxy for customers. I know that certain large DNS providers (i.e. google and level3) have either been banned or have voluntarily blocked spamhaus queries by their resolvers. We're currently in discussion with spamhaus and I wanted to see how others may have handled this. I believe you can pay them a small fee and do a zone transfer so you are not hitting their name servers. If you see value in the service, it should be worth the small fee. And since you are hitting them a lot, I have a feeling that you see value in the service. -- TTFN, patrick ---------------------------------------------------------------------------- "The information transmitted is intended only for the person or entity to which it is addressed and contains confidential and/or privileged material. If you received this in error, please contact the sender immediately and then destroy this transmission, including all attachments, without copying, distributing or disclosing same. Thank you."
On Wed, 17 Feb 2010 17:32:51 -0500 "Laczo, Louis" <Louis.Laczo@PaeTec.com> wrote:
Folks,
I'm looking for comments / suggestions / opinions from any providers that have been contacted by spamhaus about excessive queries originating from their DNS resolvers, typically, as a proxy for customers. I know that certain large DNS providers (i.e. google and level3) have either been banned or have voluntarily blocked spamhaus queries by their resolvers. We're currently in discussion with spamhaus and I wanted to see how others may have handled this.
Thanks! --Lou
When we licensed Spamhaus a few years back, they required us to set-up a DNS slave server instead of querying against their public server. They had a special DNS client that allowed partial zone updates. Turns out we downloaded huge hourly updates. We no longer use Spamhaus, relying instead upon Sender Base Reputation Scores (IronPort). matthew black e-mail postmaster california state university, long beach
When we licensed Spamhaus a few years back, they required us to set-up a DNS slave server instead of querying against their public server. They had a special DNS client that allowed partial zone updates. Turns out we downloaded huge hourly updates.
They now give you the choice of rsync or queries to non-public servers. Unless you have a humungous mail system, queries are cheaper and certainly less hassle.
We no longer use Spamhaus, relying instead upon Sender Base Reputation Scores (IronPort).
How does the price compare? R's, John
On 2/17/2010 7:35 PM, John Levine wrote:
We no longer use Spamhaus, relying instead upon Sender Base Reputation Scores (IronPort).
How does the price compare
Price comparisons would be difficult; with Ironport (Cisco now) you get hardware to go along with the service. -- Dave
On 2/17/2010 5:32 PM, Laczo, Louis wrote:
Folks,
I'm looking for comments / suggestions / opinions from any providers that have been contacted by spamhaus about excessive queries originating from their DNS resolvers, typically, as a proxy for customers. I know that certain large DNS providers (i.e. google and level3) have either been banned or have voluntarily blocked spamhaus queries by their resolvers. We're currently in discussion with spamhaus and I wanted to see how others may have handled this. Assuming you're already running a local caching server for your mail system...
Based on the spamhaus fee structure (# of e-mail accounts), our policy is to allow spamhaus to block queries from our public resolvers if they choose. The spamhaus folks certainly deserve compensation for their efforts, so customers that need such volume should do so from their own IP and pay a fee. While I believe it might be mutually beneficial for spamhaus to offer some sort of a recursive DNS provider/ISP fee structure, I can see where enforcement would be a problem. The resolution of that particular problem belongs to spamhaus and their individual users/customers. /Jason
Laczo, Louis wrote:
Folks,
I'm looking for comments / suggestions / opinions from any providers that have been contacted by spamhaus about excessive queries originating from their DNS resolvers, typically, as a proxy for customers. I know that certain large DNS providers (i.e. google and level3) have either been banned or have voluntarily blocked spamhaus queries by their resolvers. We're currently in discussion with spamhaus and I wanted to see how others may have handled this.
They seem to be doing that a lot of late. They also contacted my employer and demanded $100k/yr(?) for having a "Use Spamhaus RBL" in our software. Next version will not have the ability to query Spamhaus unless a user configures it themselves in the "Custom RBL" settings. Michelle ? = could have been more, not sure without checking with the CEO, result was the same.
On 2/18/2010 at 2:40 AM, Michelle Sullivan <matthew@sorbs.net> wrote: Laczo, Louis wrote: Folks,
I'm looking for comments / suggestions / opinions from any providers that have been contacted by spamhaus about excessive queries originating from their DNS resolvers, typically, as a proxy for customers. I know that certain large DNS providers (i.e. google and level3) have either been banned or have voluntarily blocked spamhaus queries by their resolvers. We're currently in discussion with spamhaus and I wanted to see how others may have handled this.
They seem to be doing that a lot of late. They also contacted my employer and demanded $100k/yr(?) for having a "Use Spamhaus RBL" in our software. Next version will not have the ability to query Spamhaus unless a user configures it themselves in the "Custom RBL" settings.
Michelle
? = could have been more, not sure without checking with the CEO, result was the same.
We received such a message from a Spamhaus Datafeed reseller and eventually had our DNS servers blocked. What angered me was that I analyzed our usage, and we were well below the thresholds and met the TOS published at the Spamhaus website for no-cost use. However, they said we had to subscribe to the Datafeed despite that because we have a Barracuda appliance. To me, it sounds like Barracuda customers are being singled out in some conflict between Barracuda Networks and Spamhaus. Spamhaus (via the reseller, MXTools) is leaning on Barracuda customers hoping that they'll lean on Barracuda Networks so that Barracuda Networks will do a deal at the corporate level with Spamhaus. Spamhaus does some good work, but being used as a pawn in some conflict between vendors doesn't feel nice. And I want to know how they figured out we had a Barracuda.
On 2/18/2010 12:50 PM, Crist Clark wrote:
On 2/18/2010 at 2:40 AM, Michelle Sullivan<matthew@sorbs.net> wrote:
Laczo, Louis wrote:
Folks,
I'm looking for comments / suggestions / opinions from any providers that
have been contacted by spamhaus about excessive queries originating from their DNS resolvers, typically, as a proxy for customers. I know that certain large DNS providers (i.e. google and level3) have either been banned or have voluntarily blocked spamhaus queries by their resolvers. We're currently in discussion with spamhaus and I wanted to see how others may have handled this.
They seem to be doing that a lot of late. They also contacted my employer and demanded $100k/yr(?) for having a "Use Spamhaus RBL" in our software. Next version will not have the ability to query Spamhaus unless a user configures it themselves in the "Custom RBL" settings.
Michelle
? = could have been more, not sure without checking with the CEO, result was the same.
We received such a message from a Spamhaus Datafeed reseller and eventually had our DNS servers blocked. What angered me was that I analyzed our usage, and we were well below the thresholds and met the TOS published at the Spamhaus website for no-cost use. However, they said we had to subscribe to the Datafeed despite that because we have a Barracuda appliance.
To me, it sounds like Barracuda customers are being singled out in some conflict between Barracuda Networks and Spamhaus. Spamhaus (via the reseller, MXTools) is leaning on Barracuda customers hoping that they'll lean on Barracuda Networks so that Barracuda Networks will do a deal at the corporate level with Spamhaus.
Spamhaus does some good work, but being used as a pawn in some conflict between vendors doesn't feel nice. And I want to know how they figured out we had a Barracuda.
try using barracuda's own barbell(brbl) service..i don't know if it's built into your appliance. I have also found that greylisting(for me via postgrey) has done more than any rbl to nearly eliminate my spam.
Crist Clark wrote:
We received such a message from a Spamhaus Datafeed reseller and eventually had our DNS servers blocked. What angered me was that I analyzed our usage, and we were well below the thresholds and met the TOS published at the Spamhaus website for no-cost use. However, they said we had to subscribe to the Datafeed despite that because we have a Barracuda appliance.
Well aside from I remember reading that they look for Barracuda Appliances*, it does say on: http://www.spamhaus.org/organization/dnsblusage.html *Definition: "non-commercial use" is use for any purpose other than as part or all of a product or service that is resold, or for use of which a fee is charged. For example, using our DNSBLs in a commercial spam filtering appliance that is then sold to others requires a data feed, regardless of use volume. The same is true of commercial spam filtering software and commercial spam filtering services.
And I want to know how they figured out we had a Barracuda.
* well have you considered that the Barracuda may be very specific in it's IP stack, or they signature it produces in queries etc. Might have a very specific open port for administration - and not forgetting that if it's making queries very directly it's exposing it's IP address and therefore can be tested very simply. Many different ways, and I bet I could find out if I were to have a device to look at. Michelle
On 2/18/2010 at 11:47 AM, Michelle Sullivan <matthew@sorbs.net> wrote: Crist Clark wrote: We received such a message from a Spamhaus Datafeed reseller and eventually had our DNS servers blocked. What angered me was that I analyzed our usage, and we were well below the thresholds and met the TOS published at the Spamhaus website for no-cost use. However, they said we had to subscribe to the Datafeed despite that because we have a Barracuda appliance.
Well aside from I remember reading that they look for Barracuda Appliances*, it does say on: http://www.spamhaus.org/organization/dnsblusage.html
*Definition: "non-commercial use" is use for any purpose other than as part or all of a product or service that is resold, or for use of which a fee is charged. For example, using our DNSBLs in a commercial spam filtering appliance that is then sold to others requires a data feed, regardless of use volume. The same is true of commercial spam filtering software and commercial spam filtering services.
We do not fit into that. We are not selling an appliance or service to others (the 'Cuda is for our internal corporate email only, not customers). If we were still using my home-built SpamAssassin system, it'd be OK to use Spamhaus. Now that we've purchased an appliance and manually added a Spamhaus to the user-customizable DNSBL list on it, it's not OK?
And I want to know how they figured out we had a Barracuda.
* well have you considered that the Barracuda may be very specific in it's IP stack, or they signature it produces in queries etc. Might have a very specific open port for administration - and not forgetting that if it's making queries very directly it's exposing it's IP address and therefore can be tested very simply. Many different ways, and I bet I could find out if I were to have a device to look at.
I have considered that, but it would seem it must be some signature in the queries. It does not query directly, but through our own caching DNS servers (I won't name the DNS server software, but its initials are B.I.N.D.).
On 2/18/2010 2:36 PM, Crist Clark wrote:
*Definition: "non-commercial use" is use for any purpose other than as part or all of a product or service that is resold, or for use of which a fee is charged. For example, using our DNSBLs in a commercial spam filtering appliance that is then sold to others requires a data feed, regardless of use volume. The same is true of commercial spam filtering software and commercial spam filtering services.
We do not fit into that. We are not selling an appliance or service to others (the 'Cuda is for our internal corporate email only, not customers).
Would appear to this uninformed ignoramus that Barracuda is using the data for a commercial purpose and should be buying the feed. It appears, therefore, that you have a beef with Barracuda. Do they monitor this list, or is there a better way of contacting them? -- "Government big enough to supply everything you need is big enough to take everything you have." Remember: The Ark was built by amateurs, the Titanic by professionals. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml
On Thu, Feb 18, 2010 at 3:49 PM, Larry Sheldon <LarrySheldon@cox.net> wrote:
On 2/18/2010 2:36 PM, Crist Clark wrote: Would appear to this uninformed ignoramus that Barracuda is using the data for a commercial purpose and should be buying the feed.
According to the Spamhaus web site, Your mail volume is automatically assumed to be very large, if you use a dedicated anti-spam server/appliance of any type. It would appear that the logic is: "everyone who has a low volume of mail MUST perform all spam filtering on the mail server, and not have any separate machine dedicated to spam filtering". http://www.spamhaus.org/faq/answers.lasso?section=Datafeed%20FAQ#153 " If your email volume is big enough that you need a Barracuda or similar spam filter appliance, then you certainly CAN NOT use Spamhaus's free public DNSBL servers. " Except that Baracuda appliances do not use the Spamhaus list, unless the spam firewall admin manually makes a decision to add one of the Spamhaus listss as a custom DNSBL. Baracuda _used_ to use Spamhaus by default. They stopped using it by default in version 3.5.12, in July of 2008. http://www.barracudanetworks.com/ns/support/tech_alert.php "The Barracuda Spam Firewall used to enable Spamhaus external block lists by default when usage of those lists was free to all Internet users. Now that Spamhaus is seeking license fees from some Internet users, this change is being made to remove the previous default settings" -- -J
On Thu, 18 Feb 2010, James Hess wrote:
According to the Spamhaus web site, Your mail volume is automatically assumed to be very large, if you use a dedicated anti-spam server/appliance of any type. It would appear that the logic is: "everyone who has a low volume of mail MUST perform all spam filtering on the mail server, and not have any separate machine dedicated to spam filtering".
If your mail volume is large enough that it made sense to shell out a grand to a few grand for a "spam firewall" and several hundred $ per year for updates, is it wrong for Spamhaus to want you to pay them too (if you want to use their data to improve your spam filtering)? The yearly fee for small corporate query access (up to a few hundred users) is less than you'd pay for a year of updates on a "spam firewall". ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
Crist Clark wrote:
On 2/18/2010 at 11:47 AM, Michelle Sullivan <matthew@sorbs.net> wrote:
Crist Clark wrote:
We received such a message from a Spamhaus Datafeed reseller and eventually had our DNS servers blocked. What angered me was that I analyzed our usage, and we were well below the thresholds and met the TOS published at the Spamhaus website for no-cost use. However, they said we had to subscribe to the Datafeed despite that because we have a Barracuda appliance.
Well aside from I remember reading that they look for Barracuda Appliances*, it does say on: http://www.spamhaus.org/organization/dnsblusage.html
*Definition: "non-commercial use" is use for any purpose other than as part or all of a product or service that is resold, or for use of which a fee is charged. For example, using our DNSBLs in a commercial spam filtering appliance that is then sold to others requires a data feed, regardless of use volume. The same is true of commercial spam filtering software and commercial spam filtering services.
We do not fit into that. We are not selling an appliance or service to others (the 'Cuda is for our internal corporate email only, not customers). If we were still using my home-built SpamAssassin system, it'd be OK to use Spamhaus. Now that we've purchased an appliance and manually added a Spamhaus to the user-customizable DNSBL list on it, it's not OK?
To use a phrase that I use for myself on SORBS... Their list their rules. If you don't like the rules, don't use the list. They've stated you have an appliance and regardless of volume, you are not 'non commercial' and have to pay a license. It's their list and their license, so you cannot fault them for that no matter how much you disagree with it. Michelle Michelle
Crist Clark wrote:
We do not fit into that. We are not selling an appliance or service to others (the 'Cuda is for our internal corporate email only, not customers). If we were still using my home-built SpamAssassin system, it'd be OK to use Spamhaus. Now that we've purchased an appliance and manually added a Spamhaus to the user-customizable DNSBL list on it, it's not OK?
I knew I had read it somewhere... http://www.spamhaus.org/faq/answers.lasso?section=Datafeed%20FAQ#153 Quote:
If you do not have a current Spamhaus Datafeed subscription, then you are abusing Spamhaus's public DNSBL servers. If your email volume is big enough that you need a Barracuda or similar spam filter appliance, then you certainly CAN NOT use Spamhaus's free public DNSBL servers.
Contrary to what you may have been told by the nice appliance salesman, Spamhaus does not have any agreement with Barracuda for the use of Spamhaus DNSBLs with Barracuda appliances.
Because Spamhaus's public DNSBL servers get heavily abused by companies with spam filter appliances, mostly Barracuda appliances, Spamhaus has implemented a control system on the public DNSBL servers to flag and firewall such users and Barracuda appliances in particular.
Michelle
On Thu, Feb 18, 2010 at 09:50:59AM -0800, Crist Clark wrote:
And I want to know how they figured out we had a Barracuda.
It's not that hard, much of the time -- they tend to make themselves visible via their poor behavior. As to Spamhaus policy re appliances in general, their terms are on their web site and while you or I or anyone else may not agree with or like their terms, it *is* their service to offer on the terms that they wish. And given that the Zen DNSBL is far-and-away the highest quality DNSBL available, it's probably worth paying for if one finds oneself in a situation where its use is indicated. An easy way around this is not to use an appliance: it's a straightforward exercise for any competent postmaster to build anti-spam defenses that vastly outperform [1] any appliance in an afternoon. Finally, this discussion should really be on spam-l, not nanog. ---Rsk [1] Where performance is measure in terms of acquisition cost, maintenance cost, FP, FN, bandwidth, memory, CPU, resistance to attack, scalability, etc.
Rich Kulawiec wrote:
On Thu, Feb 18, 2010 at 09:50:59AM -0800, Crist Clark wrote:
And I want to know how they figured out we had a Barracuda.
It's not that hard, much of the time -- they tend to make themselves visible via their poor behavior.
Is there some very specific poor behavior you're referring to?
Finally, this discussion should really be on spam-l, not nanog.
Actually considering the original message was addressed to the 'large DNS server operators' this is probably more appropriate. Whether the non-followups in this thread should be there instead is a different issue. Michelle
Michelle Sullivan <matthew@sorbs.net> writes:
Rich Kulawiec wrote:
On Thu, Feb 18, 2010 at 09:50:59AM -0800, Crist Clark wrote:
And I want to know how they figured out we had a Barracuda.
It's not that hard, much of the time -- they tend to make themselves visible via their poor behavior.
Is there some very specific poor behavior you're referring to?
I don't know what Rich referred to, but Barracudas used to be easy to spot by backscatter levels: http://www.dontbouncespam.org/#barracuda Bjørn
Bjørn Mork wrote:
Michelle Sullivan <matthew@sorbs.net> writes:
Rich Kulawiec wrote:
On Thu, Feb 18, 2010 at 09:50:59AM -0800, Crist Clark wrote:
And I want to know how they figured out we had a Barracuda.
It's not that hard, much of the time -- they tend to make themselves visible via their poor behavior.
Is there some very specific poor behavior you're referring to?
I don't know what Rich referred to, but Barracudas used to be easy to spot by backscatter levels: http://www.dontbouncespam.org/#barracuda
Yes that was what Rich was referring to, however, that I suspect is not what Spamhaus are doing. Regards, Michelle
On Fri, Feb 19, 2010 at 07:18:38PM +0100, Bj??rn Mork wrote:
I don't know what Rich referred to, but Barracudas used to be easy to spot by backscatter levels: http://www.dontbouncespam.org/#barracuda
They're *still* easy to spot by backscatter levels, probably because (a) a lot of people still have that switch set to "on" (b) some people still switch it to "on" (c) Barracuda's engineers apparently think that using SPF stops backscatter -- and it most emphatically does not. Reject gooooood, bounce baaaaaaad. [1] Now whether there are *other* ways to spot them: I don't know. But there are some very sharp people at Spamhaus, and it would not surprise me if they knew. ---Rsk [1] Unless you are bouncing to an authenticated/internal user.
On Fri, Feb 19, 2010 at 3:30 PM, Rich Kulawiec <rsk@gsp.org> wrote:
Barracuda's engineers apparently think that using SPF stops backscatter -- and it most emphatically does not.
Reject gooooood, bounce baaaaaaad. [1]
Whine all you want about backscatter but until you propose a comprehensive solution that's still reasonably compatible with RFC 2821's section 3.7 you're just talking trash. "If an SMTP server has accepted the task of relaying the mail and later finds that the destination is incorrect or that the mail cannot be delivered for some other reason, then it MUST construct an "undeliverable mail" notification message and send it to the originator of the undeliverable mail (as indicated by the reverse-path)." Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
On 2/19/2010 7:20 PM, William Herrin wrote:
On Fri, Feb 19, 2010 at 3:30 PM, Rich Kulawiec <rsk@gsp.org> wrote:
Barracuda's engineers apparently think that using SPF stops backscatter -- and it most emphatically does not.
Reject gooooood, bounce baaaaaaad. [1]
Whine all you want about backscatter but until you propose a comprehensive solution that's still reasonably compatible with RFC 2821's section 3.7 you're just talking trash.
"If an SMTP server has accepted the task of relaying the mail and later finds that the destination is incorrect or that the mail cannot be delivered for some other reason, then it MUST construct an "undeliverable mail" notification message and send it to the originator of the undeliverable mail (as indicated by the reverse-path)."
Does the RFC say what to do if the reverse-path has been damaged and now points to somebody who had nothing what ever to do with the email? Do your SNMP clients respond truthfully to EXPN requests? How about source-routed traffic? ICMP requests? Recursive DNS requests? If not, why not? I don't run any sites anymore, but when I did, unsolicited traffic (traffic not in response to traffic from somebody on my network) was blocked when detected, and remained blocked until somebody inside our boundary complained, and on second occurrence until my management directed me to remove the block. "in response to our traffic" was a situational matter determined by reasonable people on a case by case basis as required. -- "Government big enough to supply everything you need is big enough to take everything you have." Remember: The Ark was built by amateurs, the Titanic by professionals. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml
On Fri, Feb 19, 2010 at 8:35 PM, Larry Sheldon <LarrySheldon@cox.net> wrote:
On 2/19/2010 7:20 PM, William Herrin wrote:
"If an SMTP server has accepted the task of relaying the mail and later finds that the destination is incorrect or that the mail cannot be delivered for some other reason, then it MUST construct an "undeliverable mail" notification message and send it to the originator of the undeliverable mail (as indicated by the reverse-path)."
Does the RFC say what to do if the reverse-path has been damaged and now points to somebody who had nothing what ever to do with the email?
Hi Larry, Re-reading the paragraph I quoted and you repeated, I'm going to say that the answer is "yes." SMTP had been around for a long time when 2821 was written, as had spam. I doubt leaving the "must" in section 3.7 was an oversight. Even if it was, I didn't suggest rote adherence to the RFC. I said, "reasonably compatible with RFC 2821's section 3.7." Dropping all bounce messages on the floor -- the exact opposite of 3.7 -- is not "reasonably compatible."
Do your SNMP clients respond truthfully to EXPN requests?
I assume you mean "SMTP servers" here rather than "SNMP clients." 2821 rightly leaves EXPN as a "should" instead of a "must." And yes, they respond truthfully -- with an prohibited operation error.
I don't run any sites anymore, but when I did, unsolicited traffic (traffic not in response to traffic from somebody on my network) was blocked when detected, and remained blocked until somebody inside our boundary complained, and on second occurrence until my management directed me to remove the block.
I can't resist the set up: Maybe that's why you don't run any sites anymore. Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
Reject gooooood, bounce baaaaaaad. [1] Whine all you want about backscatter but until you propose a comprehensive solution that's still reasonably compatible with RFC 2821's section 3.7 you're just talking trash.
no, rich is talking operation pragmatics. more and more these years, rfcs are where the rubber meets the sky. but if you really like backscatter, i think i can find a few megabytes a day for you. no problem. randy
On Fri, Feb 19, 2010 at 9:02 PM, Randy Bush <randy@psg.com> wrote:
Reject gooooood, bounce baaaaaaad. [1] Whine all you want about backscatter but until you propose a comprehensive solution that's still reasonably compatible with RFC 2821's section 3.7 you're just talking trash.
no, rich is talking operation pragmatics. more and more these years, rfcs are where the rubber meets the sky.
but if you really like backscatter, i think i can find a few megabytes a day for you. no problem.
Randy, Feel free to bounce as much spam forged with my return address as you like, so long as you first follow at least the bounce suppression criteria I do: No bounce if the message claimed to be from a mailing list. No bounce if the spam scored higher than 8 in spamassassin No bounce if the server which you received the spam from doesn't match my domain's published SPF records evaluated as if "~all" and "?all" are "-all" I figure I can handle the additional -zero- messages... And I can manage it without mysteriously dropping false-positives off into the ether. I agree backscatter is a nasty problem but as solutions go, "reject gooooood, bounce baaaaaaad" sucks. Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
On Fri, Feb 19, 2010 at 5:20 PM, William Herrin <bill@herrin.us> wrote:
On Fri, Feb 19, 2010 at 3:30 PM, Rich Kulawiec <rsk@gsp.org> wrote:
Barracuda's engineers apparently think that using SPF stops backscatter -- and it most emphatically does not.
Reject gooooood, bounce baaaaaaad. [1]
Whine all you want about backscatter but until you propose a comprehensive solution that's still reasonably compatible with RFC 2821's section 3.7 you're just talking trash.
In the case of Barracuda's long history of Backscatter the solution is simple, and is implemented by most other mail vendors - it's called "Don't accept incoming mail to an invalid recipient". Barracudas used to have no way of doing address validation for incoming mail, so they would accept it and then bounce it when the next hop (eg, the Exchange server) rejected the recipient address. They finally fixed this a few years ago, and can not integrate with LDAP (and possibly others) for address validation. Of course, it's still down to the admin to implement it... Scott.
On Fri, Feb 19, 2010 at 9:28 PM, Scott Howard <scott@doc.net.au> wrote:
They finally fixed this a few years ago, and can not integrate with LDAP (and possibly others) for address validation. Of course, it's still down to the admin to implement it...
... can NOW integrate... even. Scott.
They also can use SMTP AUTH for what they call Recipient Verification. Barracuda has done some work in the past few years to improve its "out of the box" configuration, but its poor start has permanently tarnished its reputation in the eyes of some in the mail community, especially those who are able to build their own spam filtering solution. As I found in a previous e-mail I wrote in September 2008, Barracuda's next release, as documented in their release notes, will, without asking, turn off all settings that cause backscatter. Customers will have to specifically re-activate those "features" if they want them. The "Send Bounce'' option will be SET TO NO on all systems, regardless of your previous setting. If you wish notifications to go out to any sender whose email was blocked, you can re-enable this option from the "BASIC->Spam Scoring'' page, in the Spam Bounce (NDR) Configuration section. Frank -----Original Message----- From: Scott Howard [mailto:scott@doc.net.au] Sent: Friday, February 19, 2010 11:54 PM To: William Herrin Cc: nanog@nanog.org Subject: Re: Spamhaus... On Fri, Feb 19, 2010 at 9:28 PM, Scott Howard <scott@doc.net.au> wrote:
They finally fixed this a few years ago, and can not integrate with LDAP (and possibly others) for address validation. Of course, it's still down to the admin to implement it...
... can NOW integrate... even. Scott.
On Fri, 19 Feb 2010 21:28:41 -0800 Scott Howard <scott@doc.net.au> wrote:
On Fri, Feb 19, 2010 at 5:20 PM, William Herrin <bill@herrin.us> wrote:
On Fri, Feb 19, 2010 at 3:30 PM, Rich Kulawiec <rsk@gsp.org> wrote:
Barracuda's engineers apparently think that using SPF stops backscatter -- and it most emphatically does not.
Reject gooooood, bounce baaaaaaad. [1]
Whine all you want about backscatter but until you propose a comprehensive solution that's still reasonably compatible with RFC 2821's section 3.7 you're just talking trash.
In the case of Barracuda's long history of Backscatter the solution is simple, and is implemented by most other mail vendors - it's called "Don't accept incoming mail to an invalid recipient".
Barracudas used to have no way of doing address validation for incoming mail, so they would accept it and then bounce it when the next hop (eg, the Exchange server) rejected the recipient address. They finally fixed this a few years ago, and can not integrate with LDAP (and possibly others) for address validation. Of course, it's still down to the admin to implement it...
FUD I had a couple of these when they first came out; it was a much cheaper alternative than the self-maintained postfix/spamassassin combination we were using at that point and proved to be just as efficient. Recipient validation was trivial, it was just not switched on by default. LDAP integration was also trivial. IIRC it was called exchange accelerator. -- John
On Feb 20, 2010, at 12:28 AM, Scott Howard wrote:
On Fri, Feb 19, 2010 at 5:20 PM, William Herrin <bill@herrin.us> wrote:
On Fri, Feb 19, 2010 at 3:30 PM, Rich Kulawiec <rsk@gsp.org> wrote:
Barracuda's engineers apparently think that using SPF stops backscatter -- and it most emphatically does not.
Reject gooooood, bounce baaaaaaad. [1]
Whine all you want about backscatter but until you propose a comprehensive solution that's still reasonably compatible with RFC 2821's section 3.7 you're just talking trash.
In the case of Barracuda's long history of Backscatter the solution is simple, and is implemented by most other mail vendors - it's called "Don't accept incoming mail to an invalid recipient".
Barracudas used to have no way of doing address validation for incoming mail, so they would accept it and then bounce it when the next hop (eg, the Exchange server) rejected the recipient address. They finally fixed this a few years ago, and can not integrate with LDAP (and possibly others) for address validation. Of course, it's still down to the admin to implement it...
I don't know when this was that they didn't do validation. As long as I've worked with their stuff, the boxes can connect to your mail server via SMTP and verify. Many people would put Exchange servers behind the Barracuda, and those Exchange servers would say "sure, that's valid" to any request for validation, so adding LDAP support helped with Exchange server issues (though apparently it's now possible to do verification via SMTP if you set up your Exchange right). Point is, it's unclear what you complain about was entirely the making of the vendor you are complaining about. The Barracuda boxes will accept mail for domains they know about but without validating the email address in the event the target mail server is down. And yes, it'd be nice if they instead sent back a 421 and let the email queue at the point of origination in such cases. So if a mail server is down and comes back up, some emails will likely be present in the queues that shouldn't have been accepted.
On Sat, 20 Feb 2010 09:46:21 EST, Daniel Senie said:
I don't know when this was that they didn't do validation.
So they validate...
The Barracuda boxes will accept mail for domains they know about but without validating the email address in the event the target mail server is down. And yes, it'd be nice if they instead sent back a 421 and let the email queue at the point of origination in such cases. So if a mail server is down and comes back up, some emails will likely be present in the queues that shouldn't have been accepted.
Except for when they don't, and instead of 421'ing they backscatter. Gotcha.
Scott Howard wrote:
On Fri, Feb 19, 2010 at 5:20 PM, William Herrin <bill@herrin.us> wrote:
On Fri, Feb 19, 2010 at 3:30 PM, Rich Kulawiec <rsk@gsp.org> wrote:
Barracuda's engineers apparently think that using SPF stops backscatter -- and it most emphatically does not.
Reject gooooood, bounce baaaaaaad. [1]
Whine all you want about backscatter but until you propose a comprehensive solution that's still reasonably compatible with RFC 2821's section 3.7 you're just talking trash.
In the case of Barracuda's long history of Backscatter the solution is simple, and is implemented by most other mail vendors - it's called "Don't accept incoming mail to an invalid recipient".
Barracudas used to have no way of doing address validation for incoming mail, so they would accept it and then bounce it when the next hop (eg, the Exchange server) rejected the recipient address. They finally fixed this a few years ago, and can not integrate with LDAP (and possibly others) for address validation. Of course, it's still down to the admin to implement it...
Actually they do (did?), as they run postfix, they should be configurable to use LDAP and a whole host of other methods. Michelle
On Fri, Feb 19, 2010 at 08:20:36PM -0500, William Herrin wrote:
Whine all you want about backscatter but until you propose a comprehensive solution that's still reasonably compatible with RFC 2821's section 3.7 you're just talking trash.
We're well past that. Every minimally-competent postmaster on this planet knows that clause became operationally obsolete years ago [1], and has configured their mail systems to always reject, never bounce. [2] For the rest, that are still sending backscatter/outscatter spam on a chronic/systemic basis, we have spammer blacklists, since of course they *are* spamming. It should be obvious on inspection to everyone that one of the very last things we should be doing when we are drowning in useless/junk SMTP traffic is to generate more of it. Doubly so when, as we have seen, abusers have demonstrated the ability to repurpose it as a formidable weapon. ---Rsk [1] Thanks in part to the rise of the zombies, to the ready availability of cheap/free domains in bulk, to anonyous/obfuscated registration, to fast-flux DNS, and to a number of other factors. And no, SPF does not in any way mitigate this problem. Neither does DKIM. Neither does SenderID. Neither does *anything* except not sending it. [2] Yes, there are occasionally some edge cases of limited scope and duration that can be tough to handle. However, well-known methods exist for minimizing these in various mail environments (e.g., front-end/back-end, multiple MX, etc.), and these have been elucidated and discussed at length on the relevant mailing lists, such as spam-l. The key points here are "limited scope" and "limited duration". There is never any reason or need in any mail environment to permit these problems to grow beyond those boundaries.
On Feb 20, 2010, at 8:08 AM, Rich Kulawiec wrote:
On Fri, Feb 19, 2010 at 08:20:36PM -0500, William Herrin wrote:
Whine all you want about backscatter but until you propose a comprehensive solution that's still reasonably compatible with RFC 2821's section 3.7 you're just talking trash.
We're well past that. Every minimally-competent postmaster on this planet knows that clause became operationally obsolete years ago [1], and has configured their mail systems to always reject, never bounce. [2]
So write a BCP that amends RFC2821. This HAS been done before. When directed broadcasts were the hot new way to cause damage, RFC 2644 was born (a.k.a. BCP34). It simply said that since the original document was written, it had been determined that a required default setting was found to damage the Internet and that henceforth, the default value MUST be the opposite. The option is still there for those cases when needed, but damage is avoided. Those coding up new router stacks hopefully heeded the advice. Certainly two of the leading vendors at the time did so. Instead of saying "well, it's obvious to everyone," do something about it.
On Sat, 20 Feb 2010 09:51:33 EST, Daniel Senie said:
Instead of saying "well, it's obvious to everyone," do something about it.
*brrring... brrrrring...brrriiing...* Cluephone. It's for you. 5321 Simple Mail Transfer Protocol. J. Klensin. October 2008. (Format: TXT=225929 bytes) (Obsoletes RFC2821) (Updates RFC1123) (Status: DRAFT STANDARD) It's been done already. It's been quoted in this thread even. There's no sense in Rick re-inventing the wheel when John Klensin and friends already fixed the flat and rebalanced it a year and a half ago.
On 2/20/2010 9:06 AM, Valdis.Kletnieks@vt.edu wrote:
On Sat, 20 Feb 2010 09:51:33 EST, Daniel Senie said:
Instead of saying "well, it's obvious to everyone," do something about it.
*brrring... brrrrring...brrriiing...*
Cluephone. It's for you.
5321 Simple Mail Transfer Protocol. J. Klensin. October 2008. (Format: TXT=225929 bytes) (Obsoletes RFC2821) (Updates RFC1123) (Status: DRAFT STANDARD)
It's been done already. It's been quoted in this thread even. There's no sense in Rick re-inventing the wheel when John Klensin and friends already fixed the flat and rebalanced it a year and a half ago.
I've never been part of the process, but as an observer,it appears to me that unlike the old days where it seems, from the histories, that an RFC could get approved in a matter of days or weeks, the hard part now is not the writing, but the getting approved. So (agreeing with Valdis) it seems unfair to chide people for not writing one when there is a backlog of unapproved ones in the mill (some of them as we see "on topic"). -- "Government big enough to supply everything you need is big enough to take everything you have." Remember: The Ark was built by amateurs, the Titanic by professionals. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml
On Sat, Feb 20, 2010 at 8:08 AM, Rich Kulawiec <rsk@gsp.org> wrote:
On Fri, Feb 19, 2010 at 08:20:36PM -0500, William Herrin wrote:
Whine all you want about backscatter but until you propose a comprehensive solution that's still reasonably compatible with RFC 2821's section 3.7 you're just talking trash.
We're well past that. Every minimally-competent postmaster on this planet knows that clause became operationally obsolete years ago [1], and has configured their mail systems to always reject, never bounce. [2]
Rich, Indeed, and the ones who are more than minimally competent have considered the protocol as a whole and come to understand that at a technical level the "reject don't bounce" theory has more holes in it than you can shake a stick at. Find me a comprehensive solution and I'll help you write the I-D but mere trash-talk about the people who respect SMTP's architecture is unhelpful. On Sat, Feb 20, 2010 at 10:06 AM, <Valdis.Kletnieks@vt.edu> wrote:
5321 Simple Mail Transfer Protocol. J. Klensin. October 2008. (Format: TXT=225929 bytes) (Obsoletes RFC2821) (Updates RFC1123) (Status: DRAFT STANDARD)
It's been done already. It's been quoted in this thread even. There's no sense in Rick re-inventing the wheel when John Klensin and friends already fixed the flat and rebalanced it a year and a half ago.
They didn't exactly fix it. What they did is reinforce the importance of generating a bounce message by keeping the existing "must" language from 2821 but adding: "A server MAY attempt to verify the return path before using its address for delivery notifications" Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
On 2/20/2010 10:36 AM, William Herrin wrote:
They didn't exactly fix it. What they did is reinforce the importance of generating a bounce message by keeping the existing "must" language from 2821 but adding:
"A server MAY attempt to verify the return path before using its address for delivery notifications"
So, if you don't mind having your realm being blocked to stop the spam ("unsolicited bulk email") it emits, bounce away. And feel very pompous and correct while you are at it. In my day, the focus was on what my customers needed and wanted and that included the elimination of unsolicited email (they were not even big on the "bulk" qualifier). As long as the spammers and others that love the bounce are part of the RFC process, it isn't going to get better. We don't send email over facilities consisting of cables as big as your wrist--the world has changed. We don't expose our selves with "finger" and .plan and a number of other things that work in a world of friends and neighbors--the world has changed We don't send notifications and such which depend on people being honest and trust-worthy--the world has changed. RFCs describe protocols that, if followed, will allow the described interoperability. If you don't do everything listed, some stuff won't work as described. But it isn't Holy Writ. If you don't do something you don't need (or nobody you care about needs) you won't burn. And some people may thank you and allow you to be part of their community. -- "Government big enough to supply everything you need is big enough to take everything you have." Remember: The Ark was built by amateurs, the Titanic by professionals. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml
We don't expose our selves with "finger" and .plan and a number of other things that work in a world of friends and neighbors--the world has changed
It's changed all right. Finger is now called IM presence, and .plan is called Facebook. Given that the world now has dozens of alternate channels of communication over the Internet I'm on the side of folks who break the RFCs in order to keep things in some semblance of operational. And maybe someday, email will be known under another name as well. --Michael Dillon
On 2/20/2010 11:41 AM, Michael Dillon wrote:
We don't expose our selves with "finger" and .plan and a number of other things that work in a world of friends and neighbors--the world has changed
It's changed all right. Finger is now called IM presence, and .plan is called Facebook.
The difference is that finger and .plan were part of the base system, IM and FB require you to explicitly expose yourself. And have the same hazards, and more. Some of us don't choose to expose ourselves. Which brings us nicely back on topic. -- "Government big enough to supply everything you need is big enough to take everything you have." Remember: The Ark was built by amateurs, the Titanic by professionals. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml
On Sat, 20 Feb 2010 11:36:37 EST, William Herrin said:
They didn't exactly fix it. What they did is reinforce the importance of generating a bounce message by keeping the existing "must" language from 2821 but adding:
"A server MAY attempt to verify the return path before using its address for delivery notifications"
OK, let's run with that. It is *permitted* to check the address for validity before bouncing to it. So you can do one of two things: 1) Blindly bounce without bothering to verify first. One of two things will happen: a) it doesn't point at a valid mailbox, and it double-bounces and pisses off your postmaster or b) they actually point at some innocent person's mailbox and it pisses them off. To quote Dr Phil, "How's that working out for you?" (And if you're dropping the double-bounces because they're of zero worth to *your* posthamster, there's a special place in Hell for you. If you find them of zero value when they double-bounce, why do you insist on inflicting them on innocent bystanders when you successfully backscatter? 2) We can attempt to verify it first. Now, if it's spam or a virus, what do we know about it? We know a priori that the return path is bogus and should not be used. OK, that was quick. We've tried to verify it, and we've found it's invalid. Want to use a known-invalid address for the bounce? Not if you want to have a reputation as a good network neighbor. Either way, you shouldn't be bouncing spam. They also added this text in section 6.2 Conversely, if a message is rejected because it is found to contain hostile content (a decision that is outside the scope of an SMTP server as defined in this document), rejection ("bounce") messages SHOULD NOT be sent unless the receiving site is confident that those messages will be usefully delivered. The preference and default in these cases is to avoid sending non-delivery messages when the incoming message is determined to contain hostile content. Spam is hostile, by definition. If you get spam, you should not bounce unless it will be "usefully delivered". The only thing you can usefully deliver to a spammer is a fully armed and operational tactical nuke, set to detonate in 4...3...2... Since an NDN isn't a tactical nuke, you shouldn't be bouncing spam. So we've looked at it from 2 different aspects, and in both cases, the RFC says you shouldn't be bouncing spam to where it came from.
On 2/20/2010 11:53 AM, Valdis.Kletnieks@vt.edu wrote:
So we've looked at it from 2 different aspects, and in both cases, the RFC says you shouldn't be bouncing spam to where it came from.
Small nit, which is germane to the whole discussion; "...the RFC says you shouldn't be bouncing spam to where IT SAYS it came from." There is no way in the current universe to know where the item came from by inspecting it. You can only tell where you got it from...and if you can't reject it while you know that, you must discard it. -- "Government big enough to supply everything you need is big enough to take everything you have." Remember: The Ark was built by amateurs, the Titanic by professionals. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml
Larry Sheldon wrote:
On 2/20/2010 11:53 AM, Valdis.Kletnieks@vt.edu wrote:
So we've looked at it from 2 different aspects, and in both cases, the RFC says you shouldn't be bouncing spam to where it came from.
Small nit, which is germane to the whole discussion; "...the RFC says you shouldn't be bouncing spam to where IT SAYS it came from."
There is no way in the current universe to know where the item came from by inspecting it. You can only tell where you got it from...and if you can't reject it while you know that, you must discard it.
s/mime detached signatures rooted in some ca that you trust are actually a rather good way of identifying the sender. it's path or orign mail server is rather irrelevant in that context. i's not a general purpose solution but your statement is false.
On 2/20/2010 6:10 PM, Joel Jaeggli wrote:
Larry Sheldon wrote:
There is no way in the current universe to know where the item came from by inspecting it. You can only tell where you got it from...and if you can't reject it while you know that, you must discard it.
s/mime detached signatures rooted in some ca that you trust are actually a rather good way of identifying the sender. it's path or orign mail server is rather irrelevant in that context. i's not a general purpose solution but your statement is false.
And there is no way in this universe to know that anything in the message (with the possible exception of the Received header your MTA wrote) is not a forgery. My statement is true. And I'm not going around this loop again. If you think spamming is good, I'm not going to change your mind. If you think it is bad, I don't need to. Sending unsolicited bulk email (under any guise) is spamming. -- "Government big enough to supply everything you need is big enough to take everything you have." Remember: The Ark was built by amateurs, the Titanic by professionals. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml
On Sat, Feb 20, 2010 at 12:53 PM, <Valdis.Kletnieks@vt.edu> wrote:
On Sat, 20 Feb 2010 11:36:37 EST, William Herrin said:
They didn't exactly fix it. What they did is reinforce the importance of generating a bounce message by keeping the existing "must" language from 2821 but adding:
"A server MAY attempt to verify the return path before using its address for delivery notifications"
OK, let's run with that. It is *permitted* to check the address for validity before bouncing to it.
Either way, you shouldn't be bouncing spam.
They also added this text in section 6.2
Conversely, if a message is rejected because it is found to contain hostile content (a decision that is outside the scope of an SMTP server as defined in this document), rejection ("bounce") messages SHOULD NOT be sent unless the receiving site is confident that those messages will be usefully delivered. The preference and default in these cases is to avoid sending non-delivery messages when the incoming message is determined to contain hostile content.
Two paragraphs up it says, "silent dropping of messages should be considered only in those cases where there is very high confidence that the messages are seriously fraudulent or otherwise inappropriate." I don't know what your spam intake looks like but in mine, 5% to 10% can't be ranked "high confidence" until checked by an eyeball mark 1. In my system, that fraction is a candidate for a bounce... unless your SPF records have told me that the message has a forged sender. I honor whatever instructions you've made the effort to give me via the sender policy framework. That's the part that really galls me. Instructing my system not to bounce questionable messages related to yours is entirely within your control. You don't even have to know I exist; you just put a simple well-standardized line in your DNS. The instruction you choose to offer, I'll do all the processing necessary to honor it. But a few folks who complain about backscatter would rather whine about it and exhort me to break with the letter and spirit of the smtp standards than architect their own mail systems in a manner compatible with suppressing backscatter from others. Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
I don't know what your spam intake looks like but in mine, 5% to 10% can't be ranked "high confidence" until checked by an eyeball mark 1. In my system, that fraction is a candidate for a bounce...
In mine, it's a candidate for a rejection at SMTP time. I now do nearly all of my spam filtering during the SMTP session. There might once have been a reason to accept quickly and chew through the mail later, but these days it all needs chewing so you might as well do it right away. This has the huge advantage that you can reject unwanted mail after data with 550 FOAD rather than bouncing. R's, John
On Sat, Feb 20, 2010 at 7:10 PM, Joel Jaeggli <joelja@bogus.com> wrote:
s/mime detached signatures rooted in some ca that you trust are actually a rather good way of identifying the sender.
Joel, Unfortunately signatures are more effective at confirming authenticity than they are at refuting it. Even more unfortunately, refuting authenticity is vastly more useful in solving the backscatter problem. The nice thing about SPF is that it offers a practical way to *refute* the authenticity of claimed senders even when its use is less than universal. On Sat, Feb 20, 2010 at 5:57 PM, James Hess <mysidia@gmail.com> wrote:
Spurious DSNs can be discarded easily by the mail server that knows it didn't pass that message.
James, Unfortunately, that's not true. Mailing list software has to use VERP or similar encodings in the from address to successfully map bounces back to the message that caused them. For general-purpose email use, programmaticly mapping bounces back to the original message isn't reliable. On Sat, Feb 20, 2010 at 7:25 PM, Jon Lewis <jlewis@lewis.org> wrote:
IMO, the original question in this thread was on-topic, but unfortunately it got very little discussion
I like spamhaus, they run a quality list, but they want between $1900 and $19000 per year for their rsync service and you have to tell them how many email customers you're supporting in order to pay less than the max. That would be an acceptable price to pay for antispam efforts overall, but I couldn't afford to pay that for *each* of the dozens of services spamassassin consults while analyzing a message. Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
John Levine <johnl@iecc.com> writes:
I now do nearly all of my spam filtering during the SMTP session.
+1.
There might once have been a reason to accept quickly and chew through the mail later, but these days it all needs chewing so you might as well do it right away. This has the huge advantage that you can reject unwanted mail after data with 550 FOAD rather than bouncing.
there was once an argument for silent discard on spam, to keep spammers from being able to tune their entropy to get past one's filters. these days the spammers don't have to tune anything and don't tune anything, so there's no advantage to silent discard or to asynchronous filtering. everything that can be rejected synchronously, should be. there's a small chance that the rejection notice will go to a nonbot nonspammer who can correct their mistake and retry. that chance is worth taking. -- Paul Vixie KI6YSY
[ This discussion really needs to move to spam-l. ] On Sat, Feb 20, 2010 at 03:53:55PM -0500, William Herrin wrote:
I don't know what your spam intake looks like but in mine, 5% to 10% can't be ranked "high confidence" until checked by an eyeball mark 1. In my system, that fraction is a candidate for a bounce... unless your SPF records have told me that the message has a forged sender. I honor whatever instructions you've made the effort to give me via the sender policy framework.
So, "drink the SPF koolaid or I'll abuse your mail system"? No thanks.
That's the part that really galls me. Instructing my system not to bounce questionable messages related to yours is entirely within your control. You don't even have to know I exist; you just put a simple well-standardized line in your DNS. The instruction you choose to offer, I'll do all the processing necessary to honor it.
This is wrong. Use of SPF, as I pointed out previously, *does not stop backscatter spam*. [1] This is very old news to everyone who's been paying attention on spam-l for the past however-many-years. I suggest a thorough reading of the relevant traffic archived there, where any number of nasty attack scenarios -- some of which are history, not speculation -- have been discussed. Hint: nothing stops the spammers from pointing the MX records for their throwaway domains at somebody else's mail servers. Among other things. MANY other things, unfortunately. The only thing that stops backscatter spam is not sending bounces. [2] Period. Full stop. And sending rejects (that is: issuing 5xx responses during the SMTP conversation) fully complies with the applicable RFCs, so there's no issue there. That's why it's a BCP. And that's why people who don't do it often get (correctly) blacklisted for the spam they will inevitably emit. The days of bounces are over. Gone. Buh-bye. Thanks to 100M+ zombies and all the other factors I previously listed, they are NOT coming back. [3] We could lament it ad infinitum and argue about letter/spirit of the RFCs twice as long, but the immediate operational goal is to reduce the amount of abuse on the 'net, not sustain or amplify it. Given that *at least* 95% of the mail traversing the 'net is junk/abusive (more like 98-99%, but let's be a little conservative) the very last thing any operation should be doing is passing it on or generating more of it. Aside: this is part of a more general principle of SMTP abuse control: do not allow attackers to cause *your* operation to generate outbound traffic to arbitrary destinations of *their* choosing. It's unlikely that they will be kind enough to do so for your benefit or for that of your victims. ---Rsk [1] Neither does DKIM or SenderID or anything similar. [2] As before, "not sending bounces unless the sender is an authenticated user". And also as before, modulo the occasional edge cases. [3] I'm starting to think 200M may be a more realistic current estimate, but the exact number really doesn't matter that much. However large the number is, it's still increasing monotonically and there is at present no reason on the table to think that this trend will reverse. And this is only one of several related problems of large scale and scope that we face. My crystal ball is murky, but I see no reason whatsoever to think that ANY of these problems will be fixed, let alone ALL of them.
On Sun, Feb 21, 2010 at 9:10 AM, Rich Kulawiec <rsk@gsp.org> wrote:
Hint: nothing stops the spammers from pointing the MX records for their throwaway domains at somebody else's mail servers. Among other things. MANY other things, unfortunately.
Rich, Clearly I shouldn't respond to any packets at all. After all, a bad actor can originate packets with a forged source address and I wouldn't want to abuse your network with unwanted echo-replies, syn-acks and rejs. Regards, Bill Herrin -- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
On Feb 21, 2010, at 1:01 PM, William Herrin wrote:
On Sun, Feb 21, 2010 at 9:10 AM, Rich Kulawiec <rsk@gsp.org> wrote:
Hint: nothing stops the spammers from pointing the MX records for their throwaway domains at somebody else's mail servers. Among other things. MANY other things, unfortunately.
Clearly I shouldn't respond to any packets at all. After all, a bad actor can originate packets with a forged source address and I wouldn't want to abuse your network with unwanted echo-replies, syn-acks and rejs.
Bill: That is actually somewhat correct. You should not randomly respond to packets at arbitrary rates. If you do, you are being a bad Netizen for exactly this reason. See things like amplification attacks for why. Of course, if you can get proper responses, say TCP sequence numbers, proving the other side really is talking to you, then that limitation is removed. -- TTFN, patrick
On Sun, Feb 21, 2010 at 1:16 PM, Patrick W. Gilmore <patrick@ianai.net> wrote:
You should not randomly respond to packets at arbitrary rates. If you do, you are being a bad Netizen for exactly this reason. See things like amplification attacks for why. ... --
Whether it's SMTP, TCP, or ICMP spam involved the reflection attack result is still the same, and still a DoS, even if there aren't "arbitrary rates of transmission" from any player. Sure, _your_ host A's TCP stack may only respond at a maximum rate of 1 packet per second to ICMP queries from all sources, but there are hosts B, C, D, E, and F, too. Just like mail servers block single IP addresses that hit more than X invalid recipients or graylist on more than Y SMTP transactions/recipients in Z minutes. But the spammer is sending out massive forged ICMP ECHOs or TCP SYNs with 1,000,000+ different spoofed source addresses that correspond to operational internet hosts, with semi-randomized TTL values. No "one host" creates a problem, you have an emergent property, where the attacker abused all the hosts put together. The result is very much from the attacker, not the hosts involved, they have simply propagated the attack. "Backscatter" is spam from the person who created the fake origin, not spam from the fooled mail servers. Obviously SMTP servers should try to do the best they can to stop it. But if the origin domain has not provided SPF records, there are some unusual cases left open, where a bounce to a potentially fake address may still be required. E.g. The recipient was valid at the time the message was accepted, BUT while the message was still queued, their account got deleted, now the user is gone, and the message cannot be delivered to something that no longer exists. Or they ran out of disk quota allocated to their mailbox. This is impossible to know in advance, since they haven't run out until several other queued messages are delivered to them.
TTFN, patrick -- -J
On Sun, Feb 21, 2010 at 10:59:08PM -0600, James Hess wrote:
But if the origin domain has not provided SPF records, there are some unusual cases left open, where a bounce to a potentially fake address may still be required.
Third time: SPF plays no role in mitigating this. Nothing stops an attacker from using a throwaway domain to send traffic to known backscatterers, who will then backscatter it to $throwawaydomain, whose MX's are set to $victim's MX's. This is not a hypothetical, BTW, and there are a number of more interesting attack scenarios that I'll leave as an exercise for the reader. (Some of these have been discussed in detail on spam-l, and may be found in the archives.) However, even if SPF is in play, a surprising (and perhaps disturbing) number of mail operations authenticate users but then do not require that the sender match the authenticated user. This permits the attacker to use joe@example.com to target sue@example.com with backscatter, if the user-part can be set independently. (Even if sue@example.com does not exist, it still permits targeting of example.com.) And if the domain-part can be set independently, then obviously third parties can be targeted. (Again, see the archives of spam-l where all of this has been analyzed and discussed in great depth.) Yes, yes, yes, we can argue that some of this is bad mail system practice on the part of example.com, and we can argue that this is bad security practice on the part of joe, and both of these arguments have merit, but it's one the first principles of abuse control that abuse should always be squelched where possible, never passed on, reflected or even worse, amplified. A little transient schadenfreude might feel good, but it's poor operational practice -- it's never appropriate to respond to abuse with abuse. ---Rsk
On Wed, Feb 24, 2010 at 8:21 AM, Rich Kulawiec <rsk@gsp.org> wrote:
On Sun, Feb 21, 2010 at 10:59:08PM -0600, James Hess wrote:
But if the origin domain has not provided SPF records, there are some unusual cases left open, where a bounce to a potentially fake address may still be required.
Nothing stops an attacker from using a throwaway domain to send traffic to known backscatterers, who will then backscatter it to $throwawaydomain, whose MX's are set to $victim's MX's.
So? You, I and everyone else these days are no longer running open relays. You don't host $throwawaydomain so the session will end at the rcpt command. If someone merely wants to DDOS your server there are far easier ways. Regards, Bill Herrin
it's never appropriate to respond to abuse with abuse.
---Rsk
-- William D. Herrin ................ herrin@dirtside.com bill@herrin.us 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
-----Original Message----- From: Patrick W. Gilmore [mailto:patrick@ianai.net] Sent: Sunday, February 21, 2010 11:17 AM To: NANOG list Subject: Re: Spamhaus...
On Sun, Feb 21, 2010 at 9:10 AM, Rich Kulawiec <rsk@gsp.org> wrote:
Hint: nothing stops the spammers from pointing the MX records for
throwaway domains at somebody else's mail servers. Among other
On Feb 21, 2010, at 1:01 PM, William Herrin wrote: their things.
MANY other things, unfortunately.
Clearly I shouldn't respond to any packets at all. After all, a bad actor can originate packets with a forged source address and I wouldn't want to abuse your network with unwanted echo-replies, syn-acks and rejs.
Bill:
That is actually somewhat correct.
You should not randomly respond to packets at arbitrary rates. If you do, you are being a bad Netizen for exactly this reason. See things like amplification attacks for why.
Of course, if you can get proper responses, say TCP sequence numbers, proving the other side really is talking to you, then that limitation is removed.
[Tomas L. Byrnes] Ok, so now we can agree on something: You should have a POLICY about how you handle packets. Now, while trying very hard to hold my powder since that is what the ThreatSTOP patent is about, how do you propose to define, and implement, that policy efficiently across multiple devices, from multiple vendors, in real time?
-----Original Message----- From: William Herrin [mailto:bill@herrin.us] Sent: Sunday, February 21, 2010 10:02 AM To: Rich Kulawiec Cc: nanog@nanog.org Subject: Re: Spamhaus...
Hint: nothing stops the spammers from pointing the MX records for
throwaway domains at somebody else's mail servers. Among other
On Sun, Feb 21, 2010 at 9:10 AM, Rich Kulawiec <rsk@gsp.org> wrote: their things.
MANY other things, unfortunately.
Rich,
Clearly I shouldn't respond to any packets at all. After all, a bad actor can originate packets with a forged source address and I wouldn't want to abuse your network with unwanted echo-replies, syn-acks and rejs.
Regards, Bill Herrin [Tomas L. Byrnes] Maybe he should avoid any traffic on any non Point to Point only link with no repeaters, as there's always the possibility of a beaconing station or someone with SQE turned on.
Reductio ad absurdam; which, btw, is never a valid argument for, or against. P.S. I once wrote code to change line idle code on Multi-drop X.25 from 7E to FF, because AT&T ignored DTR and had all their MJUs run wide open, thereby destroying a NRZI multidrop 56kbps digital circuit, so the above scenario is not fictitious. Needless to say, pulling the plug was not an option.
Rich Kulawiec <rsk@gsp.org> writes:
On Fri, Feb 19, 2010 at 08:20:36PM -0500, William Herrin wrote:
Whine all you want about backscatter but until you propose a comprehensive solution that's still reasonably compatible with RFC 2821's section 3.7 you're just talking trash.
We're well past that. Every minimally-competent postmaster on this planet knows that clause became operationally obsolete years ago [1], and has configured their mail systems to always reject, never bounce. [2]
for smtp, i agree. yet, uucp and other non-smtp last miles are not dead.
[2] Yes, there are occasionally some edge cases of limited scope and duration that can be tough to handle. ... The key points here are "limited scope" and "limited duration". There is never any reason or need in any mail environment to permit these problems to grow beyond those boundaries.
so, a uucp-only site should have upgraded to real smtp by now, and by not doing it they and their internet gateway are a joint menace to society? that seems overly harsh. there was a time (1986 or so?) when most of the MX RR's in DNS were smtp gateways for uucp-connected (or decnet-connected, etc) nodes. it was never possible to reject nonexistent@uucpconnected at their gateway since the gateway didn't know what existed or not. i'm not ready to declare that era dead. william herrin had a pretty good list of suggested tests to avoid sending useless bounce messages: No bounce if the message claimed to be from a mailing list. No bounce if the spam scored higher than 8 in spamassassin No bounce if the server which you received the spam from doesn't match my domain's published SPF records evaluated as if "~all" and "?all" are "-all" i think if RFC 2821 is to be updated to address the backscatter problem, it ought to be along those lines, rather than "everything must be synchronous." -- Paul Vixie KI6YSY
Paul Vixie wrote:
so, a uucp-only site should have upgraded to real smtp by now, and by not doing it they and their internet gateway are a joint menace to society?
that seems overly harsh. there was a time (1986 or so?) when most of the MX RR's in DNS were smtp gateways for uucp-connected (or decnet-connected, etc) nodes. it was never possible to reject nonexistent@uucpconnected at their gateway since the gateway didn't know what existed or not. i'm not ready to declare that era dead.
I was running a UUCP gateway not so long ago, and might revive it in the future (got an old school BBS with a UUCP gateway and no SMTP still.) The front end still knew the back end valid addresses though and that's going from a PCBoards BBS to a Postfix SMTP gateway via UUCP. That said there are many out there that refuse on the grounds "I don't have the time to fix it" .. and of course one could retort with "I don't have the time to receive mail from you." I'm on the fence, if it's SMTP there *should* be no reason for the front end not to know valid users at the back end... Something will know the valid list of email addresses, so you *should* be able to get that information to the front end. Michelle * should because there will be edge cases where you can't get the information, but then are there that many emails behind that gateway that couldn't be updated manually?
On Sun, 21 Feb 2010 14:57:31 GMT, Paul Vixie said:
Rich Kulawiec <rsk@gsp.org> writes:
We're well past that. Every minimally-competent postmaster on this planet knows that clause became operationally obsolete years ago [1], and has configured their mail systems to always reject, never bounce. [2]
for smtp, i agree. yet, uucp and other non-smtp last miles are not dead.
In exactly the same sense, and for the same reasons, that 36-bit machines are not dead yet.
on Thu, Feb 18, 2010 at 09:50:59AM -0800, Crist Clark wrote:
Spamhaus does some good work, but being used as a pawn in some conflict between vendors doesn't feel nice. And I want to know how they figured out we had a Barracuda.
If it's connected to the 'Net and listening on port 25, it's rather obvious in the SMTP banner. As far as I know, only Barracudas use the parenthized 32-char hex in their banners. 220 ham.globalstar.com ESMTP (025830353ddfaf0a57c33778b8725ad9) HTH, Steve -- hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2553 w: http://hesketh.com/ antispam news and intelligence to help you stop spam: http://enemieslist.com/
On 18/02/2010 10:40, Michelle Sullivan wrote:
They seem to be doing that a lot of late. They also contacted my employer and demanded $100k/yr(?) for having a "Use Spamhaus RBL" in our software.
I sympathise. It's very frustrating when you try to deal with these anti-spam outfits in a reasonable way and you're met with almost completely arbitrary b/s. Nick
On Thu, Feb 18, 2010 at 3:25 PM, Nick Hilliard <nick@foobar.org> wrote:
On 18/02/2010 10:40, Michelle Sullivan wrote:
They seem to be doing that a lot of late. They also contacted my employer and demanded $100k/yr(?) for having a "Use Spamhaus RBL" in our software.
I sympathise. It's very frustrating when you try to deal with these anti-spam outfits in a reasonable way and you're met with almost completely arbitrary b/s.
really? that happens? I'm shocked. Oh wait, you were being ironic! -chris
In article <4B7DA21C.1060608@foobar.org> you write:
On 18/02/2010 10:40, Michelle Sullivan wrote:
They seem to be doing that a lot of late. They also contacted my employer and demanded $100k/yr(?) for having a "Use Spamhaus RBL" in our software.
I sympathise. It's very frustrating when you try to deal with these anti-spam outfits in a reasonable way and you're met with almost completely arbitrary b/s.
Spamhaus has a published price list. If you use them in a separate filtering service you sell, the price is considerably higher than if you use them as part of mail service. R's, John
On Feb 18, 2010, at 2:25 PM, Nick Hilliard wrote:
On 18/02/2010 10:40, Michelle Sullivan wrote:
They seem to be doing that a lot of late. They also contacted my employer and demanded $100k/yr(?) for having a "Use Spamhaus RBL" in our software.
I sympathise. It's very frustrating when you try to deal with these anti-spam outfits in a reasonable way and you're met with almost completely arbitrary b/s.
What's arbitrary about free for non-commerical use, everyone else pays? When you include it in a commercial product, yes, you should have to pay for it. If you're making money by reselling or providing access to the Spamhaus lists, you should have to pay for it. There's a lot of work that goes into it (I'm sure Michelle would agree) and they have very specific criteria under which they will allow free use and under which they will not. If you don't like it, make your own lists. If you *really* don't like it, make your own lists, and provide a free public infrastructure to support billions of requests a day. -- Marc
Marc Powell wrote:
On Feb 18, 2010, at 2:25 PM, Nick Hilliard wrote:
On 18/02/2010 10:40, Michelle Sullivan wrote:
They seem to be doing that a lot of late. They also contacted my employer and demanded $100k/yr(?) for having a "Use Spamhaus RBL" in our software.
I sympathise. It's very frustrating when you try to deal with these anti-spam outfits in a reasonable way and you're met with almost completely arbitrary b/s.
What's arbitrary about free for non-commerical use, everyone else pays? When you include it in a commercial product, yes, you should have to pay for it. If you're making money by reselling or providing access to the Spamhaus lists, you should have to pay for it. There's a lot of work that goes into it (I'm sure Michelle would agree) and they have very specific criteria under which they will allow free use and under which they will not. If you don't like it, make your own lists. If you *really* don't like it, make your own lists, and provide a free public infrastructure to support billions of requests a day.
I can tell you that building infrastructure to support our current load of 30 billion DNS queries per day is not as simple as some people think. That said the difference in infrastructure from 5billion pre day to the 50 billion peak we had was just the number of boxes once the infrastructure was designed and put in place. I can build and deploy a new member of the infrastructure including OS build in around 30 minutes - of which 10 minutes are updating the config the remainder are jump starting the OS. The other points I agree with. If you don't like it or don't agree, don't use it and/or build your own. Michelle
participants (30)
-
Bjørn Mork -
Christopher Morrow -
Crist Clark -
Daniel Senie -
Dave Sparro -
Frank Bulk -
James Hess -
Jason Bertoch -
Joel Jaeggli -
John Levine -
John Peach -
Jon Lewis -
Laczo, Louis -
Larry Sheldon -
Marc Powell -
Matthew Black -
Michael Dillon -
Michelle Sullivan -
Nick Hilliard -
Patrick W. Gilmore -
Paul Stewart -
Paul Vixie -
Randy Bush -
Rich Kulawiec -
Scott Howard -
Steven Champeon -
Tomas L. Byrnes -
Valdis.Kletnieks＠vt.edu -
William Herrin -
William Warren