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.
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.
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.
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.
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.
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.
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.)
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.
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
