funsec mailing list archives

Re: But Facebook are not spammers


From: Paul Vixie <vixie () isc org>
Date: Thu, 27 May 2010 07:52:09 +0000

rsk () gsp org (Rich Kulawiec) writes:

...

As to the proper definition of spam (unsolicited bulk email): it's served
us very well for a long time.  It's proved itself to be a more-than-worthy
replacement for earlier extant terminology such as "mass mail abuse".
During that time, I've seen many assertions that it needs modification.
Those assertions, without exception, comes from two types of sources:

      1. Spammers and their associates/enablers
      2. Well-meaning but insufficiently-experienced people

i don't know which of those i'd be. i'm comfortable with u-b-e as a label
but it's not in and of itself a definition. here's what i wrote in

http://www.amazon.com/Sendmail-Second-Practice-Paul-Vixie/dp/155558229X

.sh +0 "Definition
.lp
But what exactly _IT(is) e-mail spam, anyway?  You'll need a consistent
definition that you use classify both inbound and outbound traffic.  One of
the questions which is still very much open in the minds of many folks is
whether an e-mail message must be provably ``bulk'' before it can be
considered spam.  If you adhere to the ``bulk'' standard, you won't be able to
act on incoming complaints until you have more than one complaint about the
same outbound e-mail message, and you'll be in infinite regress trying to
determine what ``the same'' means.
.pp
Far better, in the authors' view, to let a message be provably and
deterministically ``spam'' or ``not spam'' based entirely on knowledge gained
from a single complainer.  The standard for ``spamness'' which most embodies
this principle was found at _EX(http://mail-abuse.org/standard.html) and is
reproduced here:
.(q
STANDARD:
.sp 0.5v
An electronic message is ``spam'' _SM(IF): (1) the recipient's personal
identity and context are irrelevant because the message is equally applicable
to many other potential recipients; _SM(AND) (2) the recipient has not
verifiably granted deliberate, explicit, and still-revocable permission for it
to be sent; _SM(AND) (3) the transmission and reception of the message appears
to the recipient to give a disproportionate benefit to the sender.
.sp 0.5v
DISCUSSION:
.sp 0.5v
(i) Trivial or mechanised personalization such as ``Dear Mr. Jones, we see
that you are the holder of the _SM(JONES.COM) domain'' does not make the
personal identity of the recipient relevant in any way.
.sp 0.5v
(ii) Failing to click the ``do not send me marketing literature by e-mail''
button in a web sign-up form does not convey explicit permission.  Only when
the default result is ``no followup e-mail'' _SM(AND) the inbox impact is
clearly stated before any action which changes this result, can permission of
this kind be conveyed.
.sp 0.5v
(iii) The appearance of disproportionate benefit to the sender, and the
relevancy of the recipient's specific personal identity, are authoritatively
determined by the recipient, and is not subject to argument or
reinterpretation by the sender.
.sp 0.5v
(iv) Non-personal e-mail always places a disproportionate cost burden on the
recipient, and is considered to disproportionately benefit the sender unless
it was verifiably solicited or by the recipient's willing exception.
.sp 0.5v
(v) A message need not be offensive or commercial in order to fit the
definition of ``spam.''  Content is irrelevent except to the extent necessary
to determine personal applicability, consent, and benefit.
.)q
.pp
We've heard of arguments that such a standard places too much power in the
hands of recipients.  In our view, recipients are paying the majority of the
cost of e-mail transport, and thus ought to have the strongest voice in what's
sent (or not) to them.  Besides which, such an argument presumes that there's
a piece of mail that a sender isn't certain was solicited.  Our advice is:
_IT(don't send it then!).
-- 
Paul Vixie
KI6YSY
_______________________________________________
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.


Current thread: