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:
- Re: But Facebook are not spammers - here's a screenshot, (continued)
- Re: But Facebook are not spammers - here's a screenshot rackow (Jun 03)
- Re: But Facebook are not spammers - here's a screenshot David M Chess (Jun 03)
- Re: But Facebook are not spammers - here's a screenshot Valdis . Kletnieks (Jun 03)
- Re: But Facebook are not spammers - here's a screenshot David M Chess (Jun 04)
- Re: But Facebook are not spammers - here's a screenshot der Mouse (Jun 04)
- Re: But Facebook are not spammers - here's a screenshot Rich Kulawiec (Jun 05)
- Re: But Facebook are not spammers - here's a screenshot Tomas L. Byrnes (Jun 19)
- Re: But Facebook are not spammers [was: And Facebook sells user data, too ...] Valdis . Kletnieks (May 23)
- Re: But Facebook are not spammers [was: And Facebook sells user data, too ...] Rich Kulawiec (May 25)
- Re: But Facebook are not spammers [was: And Facebook sells user data, too ...] Gadi Evron (May 25)
- Re: But Facebook are not spammers Paul Vixie (May 27)