Do you obfuscate email headers when reporting spam issues to clients?

Nonaht Leyte alif.terranson at gmail.com
Thu Nov 7 20:06:13 UTC 2013


>> 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 at 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 at 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
> >
> >
>



More information about the NANOG mailing list