Do you obfuscate email headers when reporting spam issues to clients?
Hello, We (iWeb AS32613) are currently making great strides in getting out from under the volume of reports received and getting on top of things. How much trouble does your abuse department go to in order to obfuscate headers when providing evidence of spamming activity regardless of if it’s intentional/professional spammer activity or some kind of malware infection allowing a third party to spam. Especially for the pro spammers, we don’t want them list washing anything or worse yet becoming privy to spamtrap data if the reporting party wasn’t smart enough to obfuscate their own data before sending in the report. So basically in order to be able to provide some evidence to clients they can use in the case of an infection of some type but not give away too much information to professional spammers we need to find a balance. I’m not sure if it’s worthwhile going to too much trouble on this since basically regardless of the data they get sent they are going to be nuked if they are actual spammers anyway. -- Landon Stewart <LandonStewart@Gmail.com>
On Wed, Nov 6, 2013 at 1:30 PM, Landon <landonstewart@gmail.com> wrote:
How much trouble does your abuse department go to in order to obfuscate headers when providing evidence of spamming activity regardless of if it’s intentional/professional spammer activity or some kind of malware infection allowing a third party to spam. Especially for the pro spammers, we don’t want them list washing anything or worse yet becoming privy to spamtrap data if the reporting party wasn’t smart enough to obfuscate their own data before sending in the report.
Howdy, It depends on the exact situation, but the general-purpose answer is: none. zero. zip. The customer usually can't act on your information unless he can line it up with an entry in his own logs. He needs lots of details in the headers to figure out which computer or which of his users the message came from. And he needs that information to determine whether the message really came from his system -- headers get forged, you know. If he can line it up with an entry in his logs then, if he's a spammer, he knows what address the message was sent to rendering your obfuscation pointless. And by now spammers are very good at list scrubbing from the slightest bit of uniquely identifiable information they can get back. Assuming they bother, which many don't. It does depend on the situation though. You shouldn't be forwarding the customer 200 spam complaints. After a small sample of messages he either has enough information to track the source of the problem or he is the problem. Also, when I bounce spam, I scrub my antispam engine's report from the bounce. No point telling the spammer how he failed to reach me. 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 Wed, Nov 6, 2013 at 1:30 PM, Landon <landonstewart@gmail.com> wrote:
We (iWeb AS32613) are currently making great strides in getting out from under the volume of reports received and getting on top of things.
Incidentally, I'd suggest that an ounce of prevention is worth a pound of cure. Simply block outbound tcp port 25 for new hosting customers on a "tell me if you want it open" basis. Don't make 'em jump through hoops: if they want it open, open it. But for everybody who doesn't tell you they want it open, keep it closed. Then analyze your data traffic for a month or two and close the port on any old customers that haven't sent any email. By doing so, you restrict the potential source of the problem to just those customers who intentionally generate email from their hosted service. Non-email using customers who get hit with worms and spambots will bounce off your shield. Also, you force spammers to bring themselves to your notice before they can send any mail -- something they're disinclined to do. 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 Wed, Nov 6, 2013 at 4:45 PM, William Herrin <bill@herrin.us> wrote:
Incidentally, I'd suggest that an ounce of prevention is worth a pound of cure. Simply block outbound tcp port 25 for new hosting customers on a "tell me if you want it open" basis.
Or to thwart those clever spammers, block inbound SYN/ACK packets with a source port of 25. This catches the ones who send SYNs out other providers with your network's source addresses which bypasses most simple ACLs. --Doug
On Wed, Nov 6, 2013 at 12:30 PM, Landon <landonstewart@gmail.com> wrote:
Hello,
How much trouble does your abuse department go to in order to obfuscate
headers when providing evidence of spamming activity regardless of if it’s intentional/professional spammer activity or some kind of malware infection allowing a third party to spam.
I suggest using separate spam traps for reporting, from spam traps used to develop filters and blacklists, seeded/published at similar places. Don't report spam hitting secret spamtraps; just use what is received at secret spam traps to develop the spam corpus, blacklists, or filtering rules. There are exceptions, but when reporting spam: the recipient needs actionable information. Not just someone claiming that there is spam from them. If they are the upstream IP network abuse contact or operator of a large mail server, they should see who it came from, who it went to, the timestamps, message ids, and full headers. The stuff you could remove to make "list washing" hard or disguise a spam trap, is the same stuff the receiver of your report needs, to efficiently and effectively help identify their outbreak, and put a stop to the spam, so you're also making it hard for legitimate contacts to find the appropriate log entry, and match the e-mail message to the account it came from. -- -JH
On Wed, 6 Nov 2013, Landon wrote:
Hello,
We (iWeb AS32613) are currently making great strides in getting out from under the volume of reports received and getting on top of things.
How much trouble does your abuse department go to in order to obfuscate headers when providing evidence of spamming activity regardless of if its intentional/professional spammer activity or some kind of malware infection allowing a third party to spam. Especially for the pro spammers, we dont want them list washing anything or worse yet becoming privy to spamtrap data if the reporting party wasnt smart enough to obfuscate their own data before sending in the report.
If you know you have pro spammers on your network, the question isn't how much to obfuscate spam complaints you receive...it's why haven't you terminated the customer(s)? As for the rest, if the reporter wants obfuscation, it's on them to do it. ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
On Wed, Nov 06, 2013 at 07:31:54PM -0500, Jon Lewis wrote:
If you know you have pro spammers on your network, the question isn't how much to obfuscate spam complaints you receive...it's why haven't you terminated the customer(s)?
Another question is "why are you relying on third parties to tell you that abuse is outbound from your operation? Why don't you already know?" Alright, two questions. But my point is that all competent operations have their own set of diverse spamtraps AND they not only passively monitor them, but they actively seed them in order to detect spammers. This not only gives them a chance to pro-actively terminate spammers before they have the opportunity to abuse third parties, but it also enables independent, controlled corroboration of reports received -- whether obfuscated or not. (Anything received at those spamtraps other than an attempt to confirm a subscription via a proper COI process is clearly spam or a typo. The incidence rate of the latter can be decreased at will with minimal effort.) ---rsk
Pretty much this. It's your business model to have your email be deliverable, while it is not my business model that your mail is received. If I get spam outside of obvious cases of receiver issues, I just block. I'm not going to bother to jump through hoops to report issues you should be dealing with yourself. Don't expect others to do your work for you, otherwise don't be surprised when your deliverability is impacted, instead of your abuse desk. -Blake On Thu, Nov 7, 2013 at 12:43 PM, Rich Kulawiec <rsk@gsp.org> wrote:
On Wed, Nov 06, 2013 at 07:31:54PM -0500, Jon Lewis wrote:
If you know you have pro spammers on your network, the question isn't how much to obfuscate spam complaints you receive...it's why haven't you terminated the customer(s)?
Another question is "why are you relying on third parties to tell you that abuse is outbound from your operation? Why don't you already know?"
Alright, two questions. But my point is that all competent operations have their own set of diverse spamtraps AND they not only passively monitor them, but they actively seed them in order to detect spammers. This not only gives them a chance to pro-actively terminate spammers before they have the opportunity to abuse third parties, but it also enables independent, controlled corroboration of reports received -- whether obfuscated or not. (Anything received at those spamtraps other than an attempt to confirm a subscription via a proper COI process is clearly spam or a typo. The incidence rate of the latter can be decreased at will with minimal effort.)
---rsk
Savvis had a significant spam problem when I arrived, and until just a few months before I left, had literally none.
Howdy,
Out of curiosity, what changed a few months before you left?
Without retelling the *entire* [very public] story: we acquired another large carrier with several hundered known spammers paying *incredible* premiums for their connectivity. Savvis decided that 2 million $/mo in MRR was just too good to passs up, and made an effort at hiding behind *my* reputation (I was supposed to make noise about how hard I was "working on it" for "as long as possible". At any point where a particular baddie became politically "hot" they would "rebrand" [read: rename, re-ip, etc] and repeat. I wasn't willing to go along, and took extraordinary steps to stop it (first arguing the value of [then] good name, and then finally going public as loudly as possible.
Another question is "why are you relying on third parties to tell you that abuse is outbound from your operation? Why don't you already know?"
The pro spammers were usually know before they got turned up: there's a really great [if informal] intelligence network set up for this: I have turned off [literally] dozens of pro spammers before the contracts made it to circuit-ordering. The pros aren't the problem, it's the little spammers who only send from a few thousand to a few million emails per month. Having POPs in 148 countries, and 7800 routers to deal with [Svvs actually exploded OSPF several years before my arrival, moving to hybrid routing schemes [BGP+ISIS+limited OSPF] makes proactive detection difficult for these little guys: so email complaints can be extremely valuable. Several other made excellent points: a few of those points I'm choosing not to respond to so as not to reveal any hint of trade secrets developed, some are just argumentative and/or not applicable at scale, or so obvious and correct that no further mention needs be made (sorry, I won't separate them out: the systems we put up are still in use AFAIK). As was pointed out earlier, this topic is at best on the very edge of OT here, so any further questions can be made off list :-) //Alif On Thu, Nov 7, 2013 at 1:00 PM, Blake Dunlap <ikiris@gmail.com> wrote:
Pretty much this. It's your business model to have your email be deliverable, while it is not my business model that your mail is received. If I get spam outside of obvious cases of receiver issues, I just block. I'm not going to bother to jump through hoops to report issues you should be dealing with yourself. Don't expect others to do your work for you, otherwise don't be surprised when your deliverability is impacted, instead of your abuse desk.
-Blake
On Thu, Nov 7, 2013 at 12:43 PM, Rich Kulawiec <rsk@gsp.org> wrote:
On Wed, Nov 06, 2013 at 07:31:54PM -0500, Jon Lewis wrote:
If you know you have pro spammers on your network, the question isn't how much to obfuscate spam complaints you receive...it's why haven't you terminated the customer(s)?
Another question is "why are you relying on third parties to tell you that abuse is outbound from your operation? Why don't you already know?"
Alright, two questions. But my point is that all competent operations have their own set of diverse spamtraps AND they not only passively monitor them, but they actively seed them in order to detect spammers. This not only gives them a chance to pro-actively terminate spammers before they have the opportunity to abuse third parties, but it also enables independent, controlled corroboration of reports received -- whether obfuscated or not. (Anything received at those spamtraps other than an attempt to confirm a subscription via a proper COI process is clearly spam or a typo. The incidence rate of the latter can be decreased at will with minimal effort.)
---rsk
Hello NANOG, Just a quick note thanking those that responded to me on and off list. I appreciate the input! -- Landon Stewart <LandonStewart@Gmail.com>
On Thu, Nov 7, 2013 at 1:43 PM, Rich Kulawiec <rsk@gsp.org> wrote:
On Wed, Nov 06, 2013 at 07:31:54PM -0500, Jon Lewis wrote:
If you know you have pro spammers on your network, the question isn't how much to obfuscate spam complaints you receive...it's why haven't you terminated the customer(s)?
Another question is "why are you relying on third parties to tell you that abuse is outbound from your operation? Why don't you already know?"
Because the folks watching packets from Internet customers do have three letters but the three letters are NSA not ISP. 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
participants (8)
-
Blake Dunlap -
Doug Clements -
Jimmy Hess -
Jon Lewis -
Landon -
Nonaht Leyte -
Rich Kulawiec -
William Herrin