Re: But Facebook are not spammers [was: And Facebook sells user data, too ...]

[Rich Kulawiec <rsk () gsp org>]

On Sun, May 23, 2010 at 10:40:18PM -0400, Valdis.Kletnieks () vt edu wrote:
> So tell me Rick - what's the spam-definition difference between what appears
> to be a "please confirm" request from Facebook, from a "please confirm"
> request from a proper mailing list, given that *both* can be caused to happen
> by a third party? I can spam you by sending you a Facebook invite, or I can
> spam you by sending a forged subscribe request to a properly run mailing list.

[ I *know* you already know all of this, Valdis, so while this is a response
to your message, it's written for the broader audience present here. -Rsk ]

If a single instance of this occurs (that is: a single message to a single
recipient), it's not spam -- because it's not bulk.  It's still abusive,
of course, but it's not spam.

If many instances of this occur, then of course it's spam.  As Chris Lewis
often points out, "everybody leaks" -- that is, all operations, even the
best-run ones, have isolated and sporadic spam (and more generically,
abuse) problems.

What distinguishes those operations from both (1) poorly-run ones and
(2) deliberately spamming ones are the words "isolated" and "sporadic".
Those in categories (1) and (2) exhibit systemic and chronic spam issues,
either because they're neligently operated or because they were *designed*
to spam.

As a few decades of practice have shown us, it's these latter operations
(categories 1 and 2) that are our real headaches.  Oh, the former can
occasionally be a brief problem, but because such operations are well-run,
prompt and effective action is the rule rather than the exception.
Such operations maintain appropriate postmaster and abuse addresses and
act swiftly to deal with what shows up at them; they also don't consider
their mitigation effort successful until they have not only dealt with the
current issue, but have made an effort to understand its root cause and
address possible future issues.  There are rarely repeat incidents at such
operations. [1]  The really good operations actively monitor for abuse
and sometimes clobber it before anyone has a chance to complain about it.

It's not difficult at all for sufficiently-experienced personnel to
distinguish the former from the latter, but it can be very difficult even
for senior experts to distinguish (1) from (2) in some circumstances.
But while this distinction is an intriguing intellectual question, it has
almost no operational bearing: the solution to the abuse in either case
is the same: null-route/firewall/blacklist and move on.  (For instance,
VSNL has spent over a decade proving to me that they are either in league
with prolific spammers or are jaw-droppingly inept.  I don't really know,
and at this point, I don't really care, other than perhaps out of morbid
curiosity.  In either case, the same firewall rules are quite effective.)

There's another distinction between the former and latter as well:
the former emit spam (in isolated and sporadic fashion, as I said) as
a result of mechanisms that are being abused by outsiders.  The example
you cited is a common instance of that: it is obvious to everyone that
the Mailman-based subscription mechanism for NANOG (to pick one list) is
not intended to spam.  In fact, it's abundantly clear that is intended to
*prevent* spam by requiring COI prior to the commencement of bulk email
(in this case: NANOG list traffic).  This is in diametrical opposition
to mechanisms such as the Facebook one we're describing here; the ONLY
purpose for those mechanisms is to spam.  (Well, and to harvest addresses
and the relationships between them in order to build usable and saleable
databases, which of course are sold to spammers and other abusers.)
They have absolutely no legitimate use of any kind. [2]

All experienced people working in this field also see another important
distinction: content.  (Remember that we are NOT discussing at this
point whether traffic in the former or latter category is spam or not.
We have already stipulated that both are.  We are now discussing what
*kind* of spam it is and are making an assessments of what its purpose is,
who is responsible for it, whether it is a systemic/chronic problem or
not, and so on.)  It is obvious on inspection that ersatz subscription
confirmation requests generated by the Mailman instance running NANOG
are exactly what they seem to be and are the result of a legitimate,
best-practice mechanism being abused by third parties.  It is equally
obvious on inspection that Facebook invites are the result of Facebook's
designed-to-spam mechanism and Facebook's deceptive practices (of which
this is only one, of course), and that the content of them consists of
Facebook's self-promotion, in an attempt to recruit more marks/victims.

In other words, Facebook are not only spammers, but they're *cowardly*
spammers, as they lack the guts to just send their own effluent out but
instead trick others into pushing the button -- so that they can attempt
to dodge responsibility for their spam and instead blame their "users".
I'll admit some grudging respect for worthy adversaries among spammers,
who at least have the courage to admit what they are; I have no such
respect for Facebook, as they're even lower than most spammers. [3]

Another distinction is mechanism.  Consider: Facebook harvests the entire
address books of the marks it cons into surrendering same.  Does anyone
actually believe that after doing so, and after using it to send spam,
that Facebook discards this valuable information?  Of course they don't.
It's valuable not only to Facebook, but to anyone with enough cash-in-hand
to purchase it. It is patently absurd to even *suggest* that Facebook
discards this goldmine.

Another distinction is forgery.  Any such abuse coming via the NANOG
mailing list mechanism would of course clearly be recognizable as such:
there is no deception involved -- or possible, since the mechanism itself
enforces the envelope and headers.  Facebooks forges the sender of its
spam for two reasons: first, in an attempt to evade responsibility and
deflect blame to third parties, including the owners of the domains
involved.  Second, because Facebook knows full well that many address
books contain mailing list addresses, and that mailing lists use weak
authentication based on the sender address -- thus this maximizes the
probability that Facebook's spam will be delivered to those mailing
lists and thus to all their subscribers. [4]

One more distinction is mitigation action.  Everyone knows that the
keepers of the NANOG mailing list would under such circumstances take
remedial action -- perhaps rate-limiting, perhaps firewalling, perhaps
mail queue deferral, perhaps any number of things.  We know this because
we know that the operators of that list are responsible, and because
we've seen other similarly-responsible operators take similar actions in
the past.  Everyone also knows that Facebook has not taken any remedial
action, and won't, because the spam coming from their mechanism isn't
a problem (from their point of view): it's the primary design goal.

Further analysis along these same lines leads to additional distinctions,
but such discussion has taken place many times on spam-l and in similar
forums, so anyone who is seriously interested in coming up to speed should
seek out the archives of those lists and read them.  The salient point,
though, is that it's quite easy to apply triage principles and conclude
the obvious: it's the latter category which requires our attention,
not the former.  The former is a drop in the river, moreover, it's a
drop which *already* receives attention on a pro-active and reactive
basis from the appropriate set of responsible people.  The latter is an
unceasing torrent and if it receives attention at all, that attention
is directed at increasing it.

Now if, and this is an enormously hypothetical "if", we were able to
do something so globally effective about the latter category that we
shrunk it to the point whether the former category was more than a
wholly-insignificant fraction of the total spam load on the Internet,
then we might have to reconsider this asssessment.  I think this is
extremely unlikely.

---Rsk

[1] I have also taken certain steps which I hope will forestall at least
some of the abuse possible via such mechanisms.  I suppose we'll see in
due course.

[2] Apologists for Facebook and similar spammers will claim that these
are necessary to generate "invitations".  This overlooks multiple points,
among them (a) invitations are not in any sense "necessary", (b) users
of such services are perfectly capable of sending private email messages
should they wish to inform others or invite them.  Occasionally someone
will point out that some (charitably speaking) less-savvy users may not
in fact be capable of sending private email messages; while I strongly
doubt this claim, even if I accept it at face value, I'll then point out
that given such clueless users access to power tools is a recipe for a
mix of security, abuse and privacy problems.  It is as irresponsible as
giving a chainsaw to a 5-year-old.

[3] This is common tactic among Spam Service Providers (SSPs): they spam
on behalf of their clients, then blame those same clients.  Of course
the clients do in fact share a measure of responsibility for this abuse,
but since the spam comes from the SSP's mail servers using the SSP's
domain(s) and located on the SSP's network it is quite clearly their spam.
One would think that entities promoting themselves as "experts" in mail
services would be well aware of best practices, including the mandatory
requirement to use proper COI on all mailing lists, but it seems they
prefer to spam -- and then blame their marks.  This tactic, coupled
with professional, articulate spokesliars who know how to flatter the
egos of the weak-minded and how to make soothing noises appears to work
quite well.

[4] "Maximizing deliverability" is a common spammer strategy, and they
have long since proven themselves to be quite willing to use multiple
methods to do so, no matter whether those methods are deceptive, abusive,
noncompliant or anything else.  For example, recent discussion on spam-l
featured a confession by a Spam Service Provider that they treat SMTP
5xx returns as temporary failures.
_______________________________________________
Fun and Misc security discussion for OT posts.
https://linuxbox.org/cgi-bin/mailman/listinfo/funsec
Note: funsec is a public and open mailing list.