Subject: [Asrg] draft-irtf-asrg-criteria (was Re: request for review for a non FUSSP proposal)

From: "J.D. Falk" <[email-masked]>
Date: Thu, 25 Jun 2009 11:40:38 -0600

Danny Angus wrote:

> I tried some time ago to articulate some tests which any proposal ought
> to at least acknowledge, which you can find here..
> http://www.killerbees.co.uk/draft-irtf-asrg-criteria-00.html
>
> You may find them helpful.

Nicely done; I think this could be the start of a very useful document.  Any 
interest in starting up work on it again?

First steps could be:
- update terminology to match draft-crocker-email-arch
- include some examples taken from other RFCs, both successful and non-

-- 
J.D. Falk
Return Path Inc
http://www.returnpath.net/

---

From: Douglas Otis <[email-masked]>
Date: Thu, 25 Jun 2009 12:40:19 -0700

On Jun 25, 2009, at 10:40 AM, J.D. Falk wrote:

> Nicely done; I think this could be the start of a very useful  
> document.  Any interest in starting up work on it again?
>
> First steps could be:

This draft overlooked an important area.  It assumes a viable and  
scaleable means to identify initial senders when confronting massive  
levels of abuse.  Simply put, without a two tier approach to abuse  
that begins by identifying outbound MTAs, email will not remain  
viable.  This paper overlooks that need.

- Include a means for efficient and efficacious host name  
identification and domain level authorization of systems granting  
access for outbound public (non-authenticated port 25) SMTP messages.

Even reverse DNS queries often impose a too great of a burden on  
resources due to bot-net related abuse. :^(

Reducing the number of systems that need vetting are best consolidated  
by identifying the outbound MTA explicitly signified as providing this  
service within the forward facing name space.  A means to explicitly  
facilitate this function becomes more necessary with increased  
inclusion of IPv6 and further growth of bot-nets.  Once outbound MTAs  
provide stable and specific identifications within the domain name  
space, the immediate vetting this allows provides a much needed  
reduction on the resource burdens imposed upon SMTP by abuse.   These  
schemes should also not cause undue burden on DNS either.

-Doug

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 26 Jun 2009 11:53:00 +0200

>> http://www.killerbees.co.uk/draft-irtf-asrg-criteria-00.html

That paper thickens the ranks of anti-anti-spam trenches. It is good 
as it avoids an excess of proposal that would possibly result in a 
waste of time for evaluating proposed techniques that don't come quite 
close to the point. However, I think an it could, and should, go 
beyond that. For example, why is it not in the scope of that document 
"to attempt to distinguish or justify any more detailed definition of 
[the term spam]"? [1.1.1]

The given definition is subjective and should be amended. Recipients' 
fickle wishes won't lead to a reliable transport. The second 
definition is better, although it leaves the _necessity of transport_ 
undefined. You don't have to query recipients to know that a sender is 
going to abuse the mail system. The definition of spam can be worded 
in terms of the senders: where do they get recipients' addresses from, 
and how well they comply with existing privacy laws, including 
opt-in/out issues.

> Nicely done; I think this could be the start of a very useful document.  
> Any interest in starting up work on it again?

Hey, that implies interest in finding new anti-spam techniques! Good, 
but I think the assumption "that there will be early adopters" [2.3.9] 
might be misunderstood as an overpromising statement.

> - update terminology to match draft-crocker-email-arch

As it is transport-centric, just updating 2821->5321 might suffice...

> - include some examples taken from other RFCs, both successful and non-

Absolutely agreed.

---

From: Rich Kulawiec <[email-masked]>
Date: Fri, 26 Jun 2009 06:07:36 -0400

On Fri, Jun 26, 2009 at 11:53:00AM +0200, Alessandro Vesely wrote:
>
> That paper thickens the ranks of anti-anti-spam trenches. It is good as 
> it avoids an excess of proposal that would possibly result in a waste of 
> time for evaluating proposed techniques that don't come quite close to 
> the point. However, I think an it could, and should, go beyond that. For 
> example, why is it not in the scope of that document "to attempt to 
> distinguish or justify any more detailed definition of [the term spam]"? 

The canonical definition of spam (in the context of email) was settled
on a very long time ago ("unsolicited bulk email") and is NOT in need of
tinkering or refinement.  It's served us very well -- and one reason
why is that it's *deliberately* silent on a number of points.  It would
be a very serious mistake -- one that would greatly assist spammers --
to change that situation.

---Rsk

---

From: Ian Eiloart <[email-masked]>
Date: Fri, 26 Jun 2009 11:47:15 +0100

--On 25 June 2009 12:40:19 -0700 Douglas Otis <[email-masked]> wrote:

> levels of abuse.

Which section assumes that.

> Simply put, without a two tier approach to abuse that
> begins by identifying outbound MTAs, email will not remain viable.  This
> paper overlooks that need.

I think that's a different level, isn't it? That's a proposal to be judged 
by the criteria in this paper. The paper shouldn't make any claims about 
how to prevent spam. It's just trying to outline the problem space.

> - Include a means for efficient and efficacious host name identification
> and domain level authorization of systems granting access for outbound
> public (non-authenticated port 25) SMTP messages.
>
> Reducing the number of systems that need vetting are best consolidated by
> identifying the outbound MTA explicitly signified as providing this
> facilitate this function becomes more necessary with increased inclusion
> of IPv6 and further growth of bot-nets.  Once outbound MTAs provide
> stable and specific identifications within the domain name space, the
> immediate vetting this allows provides a much needed reduction on the
> resource burdens imposed upon SMTP by abuse.   These schemes should also
> not cause undue burden on DNS either.
>
> -Doug
>
> _______________________________________________
> Asrg mailing list
> [email-masked]
> http://www.irtf.org/mailman/listinfo/asrg

-- 
Ian Eiloart
IT Services, University of Sussex
01273-873148 x3148
For new support requests, see http://www.sussex.ac.uk/its/help/

---

From: Ian Eiloart <[email-masked]>
Date: Fri, 26 Jun 2009 11:53:18 +0100

--On 26 June 2009 11:53:00 +0200 Alessandro Vesely <[email-masked]> wrote:

>
> Hey, that implies interest in finding new anti-spam techniques! Good, but
> I think the assumption "that there will be early adopters" [2.3.9] might
> be misunderstood as an overpromising statement.

It's simply saying that not everyone will adopt the proposal at the same 
time. The alternatives are "everyone will adopt it at once" (a common 
pitfall), and "nobody will ever adopt it" (a risk for any proposal).  A 
common counter to many proposals is that they won't work unless everyone 
adopts the proposal at the same time. 2.3.9 tries to warn of this 
possibility.

Perhaps it should read "there will be early adopters (if any at all)".

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 26 Jun 2009 12:55:06 +0200

Rich Kulawiec wrote:
>> For example, why is it not in the scope of that document "to attempt to 

UBE is still better than "the class of Messages which the Recipient 
wishes to prevent from ever being presented with." In particular, it 
allows to determine a message's spaminess *on sending*.

However, expanding on that definition may be useful for a number of 
purposes. I mention two:

1. Many countries now have laws that address privacy, and it would be 
informative for postmasters, managers, and lawyers to know what each 
one's neighbor is talking about.

2. We don't fight spam as a uniform diffused phenomenon, and some 
tools are better than others in specific areas. For example, 
discerning direct marketing from zombies is just practical. How would 
that assist which kind of spammer?

---

From: Ian Eiloart <[email-masked]>
Date: Fri, 26 Jun 2009 12:13:02 +0100

> to change that situation.

Frankly, I don't like that definition. Specifically it misses an important 
class of spam - well targeted, individualised, unsolicited marketing 
messages which are necessarily unique (and hence not bulk).

The problem comes with trying to define spam succinctly. It's like trying 
to define "mammal" succinctly - the more succinct the definition, the more 
likely it is that you'll get false positives or false negatives.

---

From: Seth <[email-masked]>
Date: Fri, 26 Jun 2009 10:03:20 -0400 (EDT)

> allows to determine a message's spaminess *on sending*.

Definitionally, yes.  Effectively, no.  There's no way for anyone
other than the sender (e.g. the sender's ISP) to determine that I
asked someone I met at a party last week to send me some information
by email.  (Sure, they could ask me; but I _didn't_ solicit that.)

Seth

---

From: Seth <[email-masked]>
Date: Fri, 26 Jun 2009 10:11:49 -0400 (EDT)

Ian Eiloart <[email-masked]> wrote:

> Frankly, I don't like that definition. Specifically it misses an
> important class of spam - well targeted, individualised, unsolicited
> marketing messages which are necessarily unique (and hence not
> bulk).

What makes them unique?  If the individualisation is merely a mail
merge, they're still bulk.  If the salescritter spent an hour
investigating me in order to determine that I'm a good prospect and
figure out the best way to entice me, the problem scales just fine.

Seth

---

From: Ian Eiloart <[email-masked]>
Date: Fri, 26 Jun 2009 15:39:55 +0100

> figure out the best way to entice me, the problem scales just fine.

And how would I, as a recipient, know which had happened? How would I know 
whether to report the message as spam?

---

From: Seth <[email-masked]>
Date: Fri, 26 Jun 2009 10:42:55 -0400 (EDT)

Ian Eiloart <[email-masked]> wrote:
> And how would I, as a recipient, know which had happened? How would
> I know whether to report the message as spam?

If it isn't apparent from the message itself, you probably shouldn't
be on the net without adult supervision.

Seth

---

From: der Mouse <[email-masked]>
Date: Fri, 26 Jun 2009 10:36:26 -0400 (EDT)

>> The canonical definition of spam (in the context of email) was
>> settled on a very long time ago ("unsolicited bulk email") [...]
> marketing messages which are necessarily unique (and hence not bulk).

The "bulk" in UBE is the same one in the Briedbart Index for Usenet:
they have to be substantively identical.  Form-letter "personalization"
of the "Dear %s, [invariant text]" kind does not make them non-bulk.
Neither do hashbusters or randomized spelling errors.

However, if they are individualized in the sense that they don't use
invariant text, each one being written for the particular recipient,
then they're not spam, even if they are unsolicited and/or unwanted:
they may be problematic, but at worst they are abuse _on_ the net, not
abuse _of_ the net - that is to say, that problem, even if it _is_ a
problem, scales just fine.

Just don't think "spam" needs to include all problematic email (or
something equivalent, such as "if it's not spam it must be OK").

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		[email-masked]
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

---

From: der Mouse <[email-masked]>
Date: Fri, 26 Jun 2009 10:45:22 -0400 (EDT)

> And how would I, as a recipient, know which had happened?

It's usually pretty obvious from the mail itself.

And I do have some basis for that.  I get spam through at least a
half-dozen different addresses, and I can count on the fingers of one
hand the number of times _ever_ that I've gotten a spam and failed to
recognize it as spam until I saw additional copies spammed to other
addresses.  (And that's just considering the content.  When looking at
the headers reveals that it was sent from an anonymous African host
through an unsecured Web form in Singapore, for mail that's supposedly
Canadian-to-Canadian, the chance that it's ham is ignorably low.)

/~\ The ASCII				  Mouse
\ / Ribbon Campaign

---

From: Ian Eiloart <[email-masked]>
Date: Fri, 26 Jun 2009 16:14:38 +0100

> be on the net without adult supervision.

Really, SMTP has some feature that lets me determine -from the content of 
an email- exactly how that email was constructed and who spent what amount 
of time putting it together? Neat. Is that in RFC 2821 of 2822. Must be 
2822, since you said "from the message itself".

Well, there's our solution then. We just need to examine the content of the 
X-i-struggled-for-half-an-hour-to-discover-whether-you'd-be-likely-to-be-interested-in-this-offer 
header.

---

From: Seth <[email-masked]>
Date: Fri, 26 Jun 2009 11:51:35 -0400 (EDT)

> of time putting it together?

No, the English language and typical adult ability to read for content
provide the capability of determining whether a message appears to be
(lightly-customized) boilerplate or individually crafted.

For instance, it's apparent to me that all of the earlier messages in
this thread were hand-crafted.

It's likewise apparent that "Hi, this is <female name>.  I saw your
profile and I'd like to get to know you better.  I borrowed my
friend's account to send this, so you should reply to me on
<website>." is spam.

Seth

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 26 Jun 2009 18:02:11 +0200

> by email.  (Sure, they could ask me; but I _didn't_ solicit that.)

Likewise, a recipient's ESP has no way to determine what the recipient 
_wishes_. Even asking may result in ambiguous answers, possibly 
affected by unexpected unconscious evocations. In addition, to surmise 
that a recipient's wishes can be partitioned into classes according to 
some standard is beyond any residual trace of objectivity. When 
interpreted operatively, it calls for inconsistent behavior -which 
indeed is what we currently have.

Even if we may be skeptical about the effectiveness of meatspace laws 
for limiting spam, we should give them credit for defining and 
describing a number of useful terms. Privacy laws are aimed at 
protecting people against undiscriminated usage of collected 
personally identifiable information, a.k.a. personal data. For 
example, European privacy directives' definitions[1] don't use the 
term "spam", but pin unauthorized usage of email addresses. 
Technically, UBE is covered in section 6.2 of rfc5321, loosening up on 
delivering or bouncing. According to privacy criteria, it should be 
covered in section 3.9, which is where the lists of addresses come 
into play. Is that the difference between coping and fixing?

[1] http://www.cdt.org/privacy/eudirective/EU_Directive_.html#HD_NM_28

---

From: Douglas Otis <[email-masked]>
Date: Fri, 26 Jun 2009 11:37:21 -0700

On Jun 26, 2009, at 3:47 AM, Ian Eiloart wrote:
>> scaleable means to identify initial senders when confronting  
>> massive levels of abuse.
>

http://www.killerbees.co.uk/draft-irtf-asrg-criteria-00.html
Section 1.3.1 defines "Sender" as something responsible for creation  
and initial entry of a message into the Transport System and should be  
identified by RFC 5321.

The 1.3.1 definition necessitates indirect assessments of the outbound  
MTA which is not good.  Section 2.1.2.1, when followed, precludes most  
"Sender" IP address authorization schemes as potentially burdening  
innocent third party DNS servers or their networks.  For example,  
DNSSEC expects EDNS0@4096.

This draft fails to include a definition that encompasses a crucial  
and safe point of control essential for effective spam mitigation.   
The missing definition is that of the Outbound MTA, the entity  
granting access and facilitating public SMTP exchanges to other  
domains.  Email-Arch's definition tends to understate the role with:  
Outbound MTA, an MTA that relays messages to other ADMDs.

>> Simply put, without a two tier approach to abuse that begins by  
>> identifying outbound MTAs, email will not remain viable.  This  
> I think that's a different level, isn't it? That's a proposal to be  
> judged by the criteria in this paper. The paper shouldn't make any  
> claims about how to prevent spam. It's just trying to outline the  
> problem space.

What level? This paper is about the management of spam.  Failing to  
offer a definition of a crucial and safe management point suggests a  
desire to ignore this aspect of control.  Today's spam levels  
necessities exclusion of messages from outbound MTAs demonstrating  
poor stewardship at removing access from abusive message sources.   
This approach scales since it expects a hierarchy of spam management.

Often assessments of stewardship is measured in many ways, which might  
include responsiveness to reports of abuse.  It is no longer  
reasonable to assume spam can be filtered based upon purported message  
sources.  The existence of bot-nets necessitates MTA triage, where the  
entire MTA message stream is handled as one.  For the MTAs accepted,  
only then individual message assessment becomes possible.

As email begins to accept IPv6 exchanges, traditional IP address  
blocking strategies are unlikely to scale in a manner that offers  
efficacy.  Expecting stable and verifiable host name EHLO  
announcements will dramatically reduce the efforts of collecting  
stewardship histories which can be immediately applied during initial  
SMTP connections.  This requirement tends to exclude the use of a  
large number of MTAs behind a common NAT.  Often such instances  
represent networks containing uncontrolled, compromised systems.   
However, the current use of IP address block-lists are also likely to  
exclude the use of a large number of MTAs behind a common NAT.

At Today's level of abuse, it is not reasonable nor safe to execute  
hundreds of DNS transactions to verify possible MTA authorizations in  
response to every SMTP connection.  It should also be noted that SPF  
schemes include macros that might negate DNS caching effectiveness.

A reasonable and scaleable approach that should take email safely into  
IPv6 is described in:
http://mipassoc.org/csv/

-Doug

---

From: "J.D. Falk" <[email-masked]>
Date: Fri, 26 Jun 2009 14:05:38 -0600

Alessandro Vesely wrote:

> However, I think an it could, and should, go beyond that. For

Because attempting to define "spam" is the very best way to ensure that a 
document is never finished.

---

From: Douglas Otis <[email-masked]>
Date: Fri, 26 Jun 2009 13:29:01 -0700

On Jun 26, 2009, at 1:05 PM, J.D. Falk wrote:

> Because attempting to define "spam" is the very best way to ensure  
> that a document is never finished.

Agreed.

-Doug

---

From: Alessandro Vesely <[email-masked]>
Date: Sat, 27 Jun 2009 14:37:52 +0200

J.D. Falk wrote:
> Because attempting to define "spam" is the very best way to ensure that 
> a document is never finished.

Finishing a document, by itself, is not a progress in the anti-spam 
endeavor, unless it contains useful knowledge for countering spam. I 
suspect that if we are not even able to agree on a definition of spam, 
there will never be much efficient anti-spam research by our group. 
And if people were to judge such research by the spam levels out 
there, they'd conclude it's all hot air.

Could we start again, please?

Let me try the following variation on UBE, in order to see if we can 
classify the objections against adopting it as a working definition.

  *Spam* is a message or a class of messages composed automatically,
  possibly using templates and databases of names or words, using a
  list of destination mailbox addresses, and failing to meet both the
  following conditions:
  * There is a record or evidence whatsoever, even implied, that the
    recipient has registered, subscribed, or otherwise solicited the
    message; and
  * it is obvious from the message content, including the headers,
    who is in charge of controlling the processing, and how the
    recipients can amend or delete their addresses from the list (as
    well as any other part of their personally identifiable data from
    any database used to compose the message), where "obvious" means
    the relevant entity is indicated, exists, is normally reachable by
    the recipient, and is effectual to the purpose it is referred for.

---

From: Claudio Telmon <[email-masked]>
Date: Sat, 27 Jun 2009 17:21:31 +0200

First, let me say, from the point of view of one that just submitted a
proposal, that I've been looking for such a document for days before
submitting my proposal to the list, and (once finished) this document
should definitely be cited in the faq.

I don't think that spam should be redefined in this kind of document,
since it wouldn't be of much help to prospective proposers. I don't
think that having a proposer think at whether a specific class of
messages is spam or not would help in getting better proposals,
especially since even this knowledgeable group can't agree on the term.
Said that, I don't think that the definition in the document is
appropriate, since a lot of messages, including harassment messages and
messages from some co-workers or bosses :) are messages one wouldn't
definitely like to be presented, but unfortunately they can hardly be
classified as spam :)

Some additional information in the document could help in preparing a
better proposal, e.g. a list of "cases" and "issues" to be considered: I
spent a lot of time trying to "imagine" some, but still missed e.g. the
shared address issue. Some could be:
- multiple recipients in messages;
- webmail vs. personal MUA vs. both;
- message forwarding
- mailing lists
- incoming MTA different from outgoing MTA
- legacy protocol versions
- ...

This would avoid proposals that miss some key situations where they will
break. While it is reasonable to expect that proposers are willing to
understand the difficulties and internals of email before proposing
anything, I think it's not reasonable to expect them to have a good
understanding from the beginning: it often happen that truly innovative
proposals come from people who look at a system "from the outside".

Maybe also a reference to  a description of current techniques, both
implemented and failed. Many of you pointed me to e.g. different address
tagging services/proposals. While I had already seen most, I spent a lot
of time in this search too (not that this has been wasted time). But,
while I've seen that the ASRG moved to non-consent research, I didn't
find anywhere why, so I was left guessing why it happened.

Also, the critical requirement that it should reduce the effort of
managing spam for the recipient is not very clear. Many solutions may
reduce the burden for some, and increase it for others. Also, for many
it will reduce the bured of some tasks but will add some other tasks. My
discussion with Rich about MUAs, address books etc. is a clear example.
So, I suggest that being able to classify users with respect to
increase/decrease of burden, and to clearly state what additional tasks
are required, would be more useful. Also, just stating that it would
decrease the burden for the majority of users is not enough, or else
anything that works for Outlook and a couple of ESP would suffice.
Another point is the "voluntary participation", which may also be
unclear. As an example, one can "voluntarily" enable the consent
framework, but without some care this would force its correspondent to
deal with the framework too. This may seem a violation of the rule, but
many protocols have the same requirement. As an example, if I protect my
http service with TSL, users willing to access it will need to implement
TSL, and I won't usually offer the same service, and this is common to
most security protocols (e.g. VPNs). One could argue that with email,
one could not know that the security/antispam protocol until a message
is rejected. As Alessandro suggested, I'm interested especially in this
final issue.

-- 

Claudio Telmon
[email-masked]
http://www.telmon.org

---

From: Dave CROCKER <[email-masked]>
Date: Sat, 27 Jun 2009 09:34:37 -0700

> a document is never finished.

+1

A long time ago, it was observed that other disciplines make progress because 
the latest round of workers stand on the shoulders of the giants who came 
before, but in computer science, we stand on their feet.

Constantly starting over to debate first principles and first definitions isn't 
just standing on those feet, it's stomping on them.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: Claudio Telmon <[email-masked]>
Date: Sat, 27 Jun 2009 19:39:45 +0200

>> that a document is never finished.

Why not take the opposite approach? Any relevant antispam technique must
at least significantly affect some UBE, or else it is probably useless.
Also, any approach that relevantly affects UBE can be considered
antispam. So, instead of trying to define spam, the document can simply
state that the proposal must at least relevantly affect UBE, while it
can affect other categories of spam.

-- 

Claudio Telmon
[email-masked]
http://www.telmon.org

---

From: Michael Thomas <[email-masked]>
Date: Sat, 27 Jun 2009 12:51:19 -0700

Dave CROCKER wrote:
> A long time ago, it was observed that other disciplines make progress 
> because the latest round of workers stand on the shoulders of the giants 
> who came before, but in computer science, we stand on their feet.

   Which nicely explains the existence of the Internet instead of the
   Interbell.

> Constantly starting over to debate first principles and first 
> definitions isn't just standing on those feet, it's stomping on them.

   Ossified feet become more and more sensitive, I take it.

		Mike

---

From: John Levine <[email-masked]>
Date: 27 Jun 2009 23:15:52 -0000

>I suspect that if we are not even able to agree on a definition of
>spam, there will never be much efficient anti-spam research by our
>group.

The world hasn't agreed on a definition of spam in 20 years, and I see
no reason to think that anything has changed that would make it
possible to do so now.

Fortunately, all of the popular definitions (UBE, UCE, UBCE, mail
recipients don't want) in practice tend to describe roughly the same
mail.  So my suggestion is that documents discussing anti-spam
techniques say which definition they're using, if it matters, and
leave it at that.  Readers specifically don't get to complain that
it's the wrong definition.

R's,
John

---

From: Ian Eiloart <[email-masked]>
Date: Mon, 29 Jun 2009 09:12:37 +0100

--On 26 June 2009 11:37:21 -0700 Douglas Otis <[email-masked]> wrote:

> This draft fails to include a definition that encompasses a crucial and
> safe point of control essential for effective spam mitigation.  The
> missing definition is that of the Outbound MTA, the entity granting
> access and facilitating public SMTP exchanges to other domains.
> Email-Arch's definition tends to understate the role with: Outbound MTA,
> an MTA that relays messages to other ADMDs.

Defining an "outbound MTA" would be useful, I guess.

> What level?

The paper isn't discussing particular proposals, but you seem to be saying 
that it should. It's discussing certain desirable properties of proposals. 
Perhaps you're looking for more detail, or something closer to an actual 
solution.

If you want to say that a desirable proposal would be scalable, then that's 
fine. If you want to say that SPF doesn't scale for a particular reason, 
then that's outside the scope of this proposal.

---

From: Ian Eiloart <[email-masked]>
Date: Mon, 29 Jun 2009 09:25:40 +0100

--On 26 June 2009 18:02:11 +0200 Alessandro Vesely <[email-masked]> wrote:

>
> Even if we may be skeptical about the effectiveness of meatspace laws for
> limiting spam, we should give them credit for defining and describing a
> number of useful terms. Privacy laws are aimed at protecting people
> against undiscriminated usage of collected personally identifiable
> information, a.k.a. personal data.

You're missing an important definition of "privacy" - the right to be 
undisturbed (for example, by unsolicited advertising in your INBOX or on 
your doormat).

Many people consider privacy to be simply the right to remain unobserved 
(secrecy), but the right to be let alone is the basis of the UK's "Privacy 
and Electronic Communications (EC Directive) Regulations 2003". Those 
regulations are subsidiary to our Data Protection Act of 1998, but don't 
arise from it.

Once upon a time, the two aspects of privacy were entwined by mass 
illiteracy and slow communications. Nowadays, near ubiquitous 
communications mean it's harder to voluntarily avoid interference by 
keeping your location secret - partly because it's harder to keep it 
secret, and partly because for many modern communications methods your 
physical location doesn't matter.

---

From: Ian Eiloart <[email-masked]>
Date: Mon, 29 Jun 2009 09:41:42 +0100

--On 27 June 2009 14:37:52 +0200 Alessandro Vesely <[email-masked]> wrote:

> there will never be much efficient anti-spam research by our group. And
> if people were to judge such research by the spam levels out there,
> they'd conclude it's all hot air.
>

The mistake below is to assume that "spam" is a single category that can be 
tidily defined. It can't.

The best one could do is to try to enumerate some types of spam. I'd 
suggest two, that look very different from each other: (a) submission of 
large quantities of electronic messages to an electronic messaging service 
with the deliberate aim of reducing the usability of that service, and (b) 
transmission of unsolicited communications by means of electronic mail for 
direct marketing purposes.

These are very different - the content is irrelevant in the first, but 
highly relevant in the second. The threat to the system is the motivation 
of the first, but would be harmful to the sender in the second. A recipient 
might welcome the second, but is unlikely to welcome the first.

One might wish to add other types of spam (phishing, viruses, chain 
letters...) but it's unlikely that even the longest list constructed today 
will cover all future types of spam.

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 29 Jun 2009 12:21:01 +0200

Ian Eiloart wrote:
>> Privacy laws are aimed at protecting people 

No, I'm not. Since email addresses and doormat locations are part of a 
recipient's personal data, recipients can exercise their right on 
whether that piece of information may be used to deliver that piece of 
advertising.

Let me exemplify: my email address is on my town's public directory, 
and some used cars sellers want to advertise by email special deals in 
each town. An interpretation of "privacy" may imply that when the 
sellers copy my address into their list, at the same time notify me 
the details of their data processing. I don't want an email for that 
notification, just a machine readable note at my MX server. That note 
should arrive _before_ any email message, so that I can automatically 
delete my address from the sellers' list even before they send me any 
advertisement, if that's how I've configured the server.

> (secrecy), but the right to be let alone is the basis of the UK's 
> "Privacy and Electronic Communications (EC Directive) Regulations 2003". 
> Those regulations are subsidiary to our Data Protection Act of 1998, but 
> don't arise from it.

They are too abstract to be useful for any practical purpose. 
Nevertheless, they provide guidance.

> physical location doesn't matter.

It's not secrecy, it's usage. I have the right to allow my address to 
stay on one list and delete it from another one. Even if both lists 
are public, my data is mine.

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 29 Jun 2009 12:25:10 +0200

> no reason to think that anything has changed that would make it

The European directives on privacy arrived around the turn of the 
century, so they are new in that respect. They may have all the 
defects that European directives usually have, but provide 
definitions. Not for spam, as I mentioned upthread; however, spam can 
be treated in that framework.

> mail.

I'd say they just largely overlap. I'd guess one line of disagreement 
would be what kind of well behaved direct marketing, if any, should be 
considered non-spam. That is, whether the "U" in the above definition 
may be considered implicit, on the argument that recipients cannot 
solicit something whose existence they ignore.

MRDW (I'd propose to pronounce it "mérde-u", if that's the correct 
acronym for the last definition), although practical, is horrible.

I'd also add botnet/zombie generated, spam to that list.

>  So my suggestion is that documents discussing anti-spam

+1

That way, at least, we know what we're talking about. In addition, 
this suggestion leaves room for an eventual informative paper listing 
those popular definitions.

---

From: Claudio Telmon <[email-masked]>
Date: Mon, 29 Jun 2009 12:41:57 +0200

Alessandro Vesely wrote:

> Let me exemplify: my email address is on my town's public directory, and
> some used cars sellers want to advertise by email special deals in each
> town. An interpretation of "privacy" may imply that when the sellers
> copy my address into their list, at the same time notify me the details
> of their data processing. I don't want an email for that notification,
> just a machine readable note at my MX server. That note should arrive
> _before_ any email message, so that I can automatically delete my
> address from the sellers' list even before they send me any

This is another interesting example of "consent". Now, suppose that the
"details" require some lines of free text description, so that you can
properly decide if you like "how and why" they are using your address.
There, you have a consent request.
But the problem is, spammers won't be that polite, not even in Europe
with our EU Directive :) So you will need to find a way to enforce
compliance with this requirement for your address, that is, a way for
the MTA to know who you authorized...

-- 

Claudio Telmon
[email-masked]
http://www.telmon.org

---

From: Rich Kulawiec <[email-masked]>
Date: Mon, 29 Jun 2009 07:22:24 -0400

> marketing messages which are necessarily unique (and hence not bulk).

Two points:

1. Anything that's not bulk isn't spam, and is thus outside the consideration
of this working group.  It may be unwelcome or annoying or any number of
other things, but none of that matters.

2. That definition does not miss any classes of [email] spam: it covers
them all beautifully, which is one reason why it's not in need of revision.
It is silent on the point of "targeting", for example, because it doesn't
matter whether spam is targeted or not.  It's silent on the point of whether
messages are individualized, because *that* doesn't matter either.  So, 
for example, suppose some spammer went through the trouble to enumerate
which MTA you and I and 5000 other folks are using, and sent us UBE which
(a) was targeted on a per-MTA basis and (b) addressed us by full name in
the body.  It's obviously UBE, thus obviously spam -- and equally obviously,
covered the same long-standing definition that has served us well.

---Rsk

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 29 Jun 2009 15:38:04 +0200

> There, you have a consent request.

Well, having to collect agreements for data processing from each 
subject is one of the most annoying applications of EU privacy 
directives. It is as when one says: "May I ask you XYZ?" And the other 
one replies: "Yes, you already did!" For email, it is possible to 
avoid that _that kind_ of consent requests become entries in the 
recipient's INBOX. One way to do so, considering multi-destination 
delivery a kind of forwarding (see sec. 3.9 of rfc5321), is being 
tentatively described at http://fixforwarding.org/.

> the MTA to know who you authorized...

It may be enough to provide a convenient way to do it, without 
enforcing it with blocking policies.

While it seems self-evident that spammers are exempted from complying 
with anti-abuse message sender common practices, many careful senders 
may be classified as spammers according to the MRDW acceptation of the 
term spam. "Spammers" of the latter kind are sensible to reputation 
concepts and make a good faith effort to comply with common practices, 
because they reason that going along with prospects' desires is more 
remunerative than loosing their own reputation on questionable deeds.

---

From: Douglas Otis <[email-masked]>
Date: Mon, 29 Jun 2009 11:53:47 -0700

> Defining an "outbound MTA" would be useful, I guess.

See:
http://www.killerbees.co.uk/draft-irtf-asrg-criteria-00.html#anchor9

A definition for spam sources should acknowledge RFC 5321 Sender is  
not the _only_ identifier that might be used to manage spam.  It may  
even prove impractical or unsafe to attempt to check where a message  
may have been created and initially entered, as Section 1.3.1  
definition for Sender seems to imply.

This Sender definition runs afoul of several SMTP concepts.  The RFC  
5321 Sender does not define persons, automated-systems, or groups that  
create or enter messages.   The Mail command defines an error  
notification path (reverse-path) and not a person, automated-system,  
or group responsible for having created or entered the message.  In  
fact, the error notification path might be NULL in some cases.  This  
can not be referring to the EHLO command, since this would be the SMTP  
client, and not not a person, automated-system, or group responsible  
for having created or entered the message.  By even using the word  
"Sender" and implying this identifies a person, automated-system, or  
group responsible for having created or entered the message confuses  
RFC 5321 identifiers with those of RFC 5322.  One might assume that  
redefinition of RFC 5321 is the underlying intent of this draft.

Rather than misusing the term "Sender",  perhaps the term "RFC 5321  
Originating Identifiers" would be better.  A list of Originating  
Identifiers could include those expressed by either RFC 5321 MAIL or  
EHLO commands.

Omission and erroneous definition may have a tendency to preclude  
other options.  While no one likes to find the outbound MTA they are  
using has been blocked for policy reasons, it is often possible to  
rectify this by obtaining access to a different outbound MTA.  When  
the domain used in an email-address is blocked for policy reasons,  
rectification may require abandonment of the email-address domain  
instead.  There are no perfect solutions.  Policy based upon the EHLO  
command, rather than the Mail command, may provide more efficacious,  
practical, and scalable solutions than policies based upon the MAIL  
command.  This draft should not preclude the use of the EHLO identity,  
nor misconstrue MAIL command assertions.

>> What level?
>
> The paper isn't discussing particular proposals, but you seem to be  
> saying that it should. It's discussing certain desirable properties  
> of proposals. Perhaps you're looking for more detail, or something  
> closer to an actual solution.

The draft should drop its current definition of Sender.  Spam does not  
just originate from purported RFC 5321 Senders, nor is it safe to  
assume that an MTA authorization referenced by an RFC 5321 Sender  
asserts where a message was initially created and entered.   
Authorization does not provide this property.

> If you want to say that a desirable proposal would be scalable, then  
> that's fine. If you want to say that SPF doesn't scale for a  
> particular reason, then that's outside the scope of this proposal.

Stronger statements along the lines of scaling might be helpful.  It  
seems increasing potential DNS transactions by an order of magnitude  
or more has not been given adequate consideration in some anti-spam  
efforts. :^(

-Doug

---

From: John Levine <[email-masked]>
Date: 29 Jun 2009 21:05:37 -0000

>>> settled on a very long time ago ("unsolicited bulk email") and is
>>> NOT in need of tinkering or refinement.

It's a perfectly good definition, but it's not the only one.  It is
not, for example, the one used in any law that regulates spam (they
all use some version of UCE), nor is it the one used by ISPs who
provide a junk mail button to their users (some version of mail their
users don't want.)

We've all seen all the arguments about the reasons to prefer one
definition over another so DO NOT rehash them here.

I can think of few things less productive than to argue about whether
people over whom we have no influence are using the "wrong" definition
of spam, so don't.

Like I said, in contexts where it matters which definition you're using,
tell us.

R's,
John

---

From: Danny Angus <[email-masked]>
Date: Tue, 30 Jun 2009 07:46:39 +0100

Ok, point taken about outbound MTA

I'm not sure what this is about..

> The draft should drop its current definition of Sender.  Spam does not just
> originate from purported RFC 5321 Senders, nor is it safe to assume that an
> MTA authorization referenced by an RFC 5321 Sender asserts where a message
> was initially created and entered.  Authorization does not provide this
> property.

> Stronger statements along the lines of scaling might be helpful.  It seems
> increasing potential DNS transactions by an order of magnitude or more has
> not been given adequate consideration in some anti-spam efforts. :^(

I think the statements about scaling are clear, do you not?

d.

---

From: Danny Angus <[email-masked]>
Date: Tue, 30 Jun 2009 08:04:48 +0100

> document is never finished.

In fact trying to define spam would ensure it never got started!

Actually I would have liked to have included *some* definition, but
because members of this group hold pretty entrenched opinions covering
most possible definitions I felt that on the one hand it would be
impossible and on the other hand it would be unecessary.

I believe that it is unnecessary for two reasons, the first being that
this group cannot agree a definition, yet operates reasonably
successfully, and secondly there can be an empirical test for a
solution, even if there is no agreed definition of spam itself.

d.

---

From: Steve Atkins <[email-masked]>
Date: Tue, 30 Jun 2009 16:04:51 -0700

On Jun 30, 2009, at 12:04 AM, Danny Angus wrote:

> On Fri, Jun 26, 2009 at 9:05 PM, J.D. Falk<[email-masked] 
> > wrote:
>> Alessandro Vesely wrote:
>>

One issue is that there are a number of definitions of spam that
are useful in different contexts. The definition that's useful for
operational handling at an abuse desk is different to that for
operational handling of inbound mail filters, different again to
that useful for someone developing content based filters, different
again for someone drafting legislation and very different again
for someone litigating.

All of these definitions are fairly well defined and extremely useful
in the context in which they're used. And they'll generally agree
on the categorization of the vast majority of emails, but there are
emails where they'll disagree. This isn't a problem.

The problem arises when someone, anyone, claims that there is
One True Definition of spam. The fact that that's blatantly false
isn't the problem. That it causes hordes of people to come out of
the woodwork to argue for their One True Definition of spam, causing
yet another rerun of the Thread That Would Not Die is the problem.

(A problem that's usually best solved by killfiling anyone participating
in that sort of thread).

Cheers,
   Steve

---

From: Seth <[email-masked]>
Date: Wed, 1 Jul 2009 00:53:36 -0400 (EDT)

It seems clear that different definitions are useful for different
things; in particular, different methods are better or worse depending
on the definition used.

For instance, it seems apparent that using "This Is Spam" buttons hit
by users to train filters will do best under a definition like "email
users say is spam".

My suggestion of filtering confirmations through the ISP (so the site
clicked on is theirs rather than the sender's, and they record the
click and notify the sender) works really well using an "unsolicited"
definition, and less well using a "user complaints" definition (since
it's well known that users sometimes complain about mail they
solicited).

So, it can be worthwhile to specify which definition you're using when
you suggest a method to optimize under that definition.  But that's
pure practicality, it has nothing to do with "right" or "wrong".
There's no such thing with definitions.  Rather, the purpose of a
definition is to enable discussion about something without having to
describe it in full each time it's mentioned.

Seth