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

[J.D. Falk-2]

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/
_______________________________________________
Asrg mailing list
Asrg@...
http://www.irtf.org/mailman/listinfo/asrg

[Douglas Otis]

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

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

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

_______________________________________________
Asrg mailing list
Asrg@...
http://www.irtf.org/mailman/listinfo/asrg

[Ale2008]

J.D. Falk wrote:
> 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

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.

> First steps could be:
> - 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.
_______________________________________________
Asrg mailing list
Asrg@...
http://www.irtf.org/mailman/listinfo/asrg

[Rich Kulawiec]

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
_______________________________________________
Asrg mailing list
Asrg@...
http://www.irtf.org/mailman/listinfo/asrg

[Ian Eiloart]

--On 25 June 2009 12:40:19 -0700 Douglas Otis <dotis@...> wrote:

>
> On Jun 25, 2009, at 10:40 AM, J.D. Falk wrote:
>
>> 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-
>
> This draft overlooked an important area.  It assumes a viable and
> scaleable means to identify initial senders when confronting massive
> 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.
>
> 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
>
> _______________________________________________
> Asrg mailing list
> Asrg@...
> 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/
_______________________________________________
Asrg mailing list
Asrg@...
http://www.irtf.org/mailman/listinfo/asrg

[Ian Eiloart]

--On 26 June 2009 11:53:00 +0200 Alessandro Vesely <vesely@...> 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)".

--
Ian Eiloart
IT Services, University of Sussex
01273-873148 x3148
For new support requests, see http://www.sussex.ac.uk/its/help/
_______________________________________________
Asrg mailing list
Asrg@...
http://www.irtf.org/mailman/listinfo/asrg

[Ale2008]

Rich Kulawiec wrote:
>> 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.

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?
_______________________________________________
Asrg mailing list
Asrg@...
http://www.irtf.org/mailman/listinfo/asrg

[Ian Eiloart]

--On 26 June 2009 06:07:36 -0400 Rich Kulawiec <rsk@...> wrote:

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

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.


> ---Rsk
> _______________________________________________
> Asrg mailing list
> Asrg@...
> 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/
_______________________________________________
Asrg mailing list
Asrg@...
http://www.irtf.org/mailman/listinfo/asrg

[Seth Breidbart]

Alessandro Vesely <vesely@...> wrote:

> 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*.

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

_______________________________________________
Asrg mailing list
Asrg@...
http://www.irtf.org/mailman/listinfo/asrg

[Seth Breidbart]

Ian Eiloart <iane@...> 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
_______________________________________________
Asrg mailing list
Asrg@...
http://www.irtf.org/mailman/listinfo/asrg

[der Mouse-3]

>> The canonical definition of spam (in the context of email) was
>> settled on a very long time ago ("unsolicited bulk email") [...]
> 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 "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 mouse@...
/ \ Email!     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B
_______________________________________________
Asrg mailing list
Asrg@...
http://www.irtf.org/mailman/listinfo/asrg

[Ian Eiloart]

--On 26 June 2009 10:11:49 -0400 Seth <sethb@...> wrote:

> Ian Eiloart <iane@...> 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.

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

> Seth
> _______________________________________________
> Asrg mailing list
> Asrg@...
> 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/
_______________________________________________
Asrg mailing list
Asrg@...
http://www.irtf.org/mailman/listinfo/asrg

[Seth Breidbart]

Ian Eiloart <iane@...> wrote:

> --On 26 June 2009 10:11:49 -0400 Seth <sethb@...> wrote:
>> Ian Eiloart <iane@...> 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.
>
> 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
_______________________________________________
Asrg mailing list
Asrg@...
http://www.irtf.org/mailman/listinfo/asrg

[der Mouse-3]

>> 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.
> 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
 X  Against HTML mouse@...
/ \ Email!     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B
_______________________________________________
Asrg mailing list
Asrg@...
http://www.irtf.org/mailman/listinfo/asrg

[Ian Eiloart]

--On 26 June 2009 10:42:55 -0400 Seth <sethb@...> wrote:

> Ian Eiloart <iane@...> wrote:
>> --On 26 June 2009 10:11:49 -0400 Seth <sethb@...> wrote:
>>> Ian Eiloart <iane@...> 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.
>>
>> 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.

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.



> Seth
> _______________________________________________
> Asrg mailing list
> Asrg@...
> 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/
_______________________________________________
Asrg mailing list
Asrg@...
http://www.irtf.org/mailman/listinfo/asrg

[Seth Breidbart]

> --On 26 June 2009 10:42:55 -0400 Seth <sethb@...> wrote:
>> Ian Eiloart <iane@...> wrote:
>>> --On 26 June 2009 10:11:49 -0400 Seth <sethb@...> wrote:
>>>> Ian Eiloart <iane@...> wrote:

>>>> 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.
>>>
>>> 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.
>
> 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?

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
_______________________________________________
Asrg mailing list
Asrg@...
http://www.irtf.org/mailman/listinfo/asrg

[Ale2008]

Seth wrote:
>> 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*.
>
> 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.)

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
_______________________________________________
Asrg mailing list
Asrg@...
http://www.irtf.org/mailman/listinfo/asrg

[Douglas Otis]

On Jun 26, 2009, at 3:47 AM, Ian Eiloart wrote:
> --On 25 June 2009 12:40:19 -0700 Douglas Otis <dotis@...>  
> wrote:
>>
>> This draft overlooked an important area.  It assumes a viable and  
>> scaleable means to identify initial senders when confronting  
>> massive levels of abuse.
>
> Which section assumes that.

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

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
 
     
_______________________________________________
Asrg mailing list
Asrg@...
http://www.irtf.org/mailman/listinfo/asrg

[J.D. Falk-2]

Alessandro Vesely wrote:

> 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]"?

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

--
J.D. Falk
Return Path Inc
http://www.returnpath.net/
_______________________________________________
Asrg mailing list
Asrg@...
http://www.irtf.org/mailman/listinfo/asrg

[Douglas Otis]

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

> Alessandro Vesely wrote:
>
>> 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]"?
>
> Because attempting to define "spam" is the very best way to ensure  
> that a document is never finished.

Agreed.

-Doug
_______________________________________________
Asrg mailing list
Asrg@...
http://www.irtf.org/mailman/listinfo/asrg