ASRG work items

[Paul Judge]

Here is the list of work items that have been identified. If there are other
items that should be added to the list, please propose them. All
conversation on this mailing list must be regarding one of these items. The
subject of each email should begin with the number of the appropriate work
item. For example, "2.a - Spam Measurement Survey Requirements" or "6 -
Proposal for hash-based traceback system". The list volume makes it
difficult to follow individual conversations and to filter the noise. This
will help eliminate both problems. If anyone has a problem following this
convention, please let me know. This is a research group. If you have
constructive feedback, please share it. If you just feel like saying that
"spam can not be stopped" or "this group will fail because I said so", then
you should state those things elsewhere. This mailing list is for the
discussion of ideas that make progress towards the goals of these group as
stated in the charter. I have the option of changing this research group
into a closed research group. If we decide that the noise continues to
affect persons making contributions, then we will exercise that option.



-----Part 1. Understanding the Problem:

1. Inventory of problems. started by Liudvikas Bukys. I will distribute the
latest version. Liudvikas, would you like to resume ownership of this
document?

2. Characterization of the problems

2.a. Spam Measurements. This works needs to be focused on immediately. This
data will help us understand the current weaknesses in the system and where
efforts should be focused. Requirements need to be set and then we have to
gather the data. I see two separate paths here: One is based on user survey
input. Ted Gavin has volunteered to conduct this. The other data is based on
real spam measurements. Once the requirements are gathered, Brightmail,
CipherTrust, CloudMark and MessageLabs have each volunteered to contribute
information. Any other volunteers?

2.b. Public Trace Data - www.spamarchive.org

2.c. Spam Categorization

2.c.1.where it comes from - there was a thread started by someone on this.
Anyone remember the title? This feeds into 7.b. threat model. 2.c.2.
different types - Brightmail has a high-level classification. SurfControl
might also have something here. Ken S. and Susan G., do either of you have
some more granular classifications that you would like to share? Volunteer
to lead this effort?

-----Part 2. Propose Solutions:

3. Requirements for solutions: Started by Keith Moore. I distributed Draft 1
based on feedback. Keith, would you like to take over moving this forward?

4. Survey of solution

4.a. Taxonomy. Draft three was distributed. There was only one comment. So I
assume we are getting close. 4.b. Survey. Summarize set of solutions and
place into taxonomy. 4.c Bibliography of spam research related work. Frank
de Lange has started this effort.

5. Identification of need for interoperable systems

5.a. Spam Test Message. led by Matt Sergeant

5.b. Opt-out. The idea here is that there should be a standard method of
opting-out so that it can be done by a program. There should also be a way
to systemically verify compliance. volunteer?

5.c. Filtered Message Status. The point here is that messages are dropped by
filters with either no status indication or inconsistent ones. The goal is
to agree on a set of acceptable responses. Perhaps this information is
already specified in SMTP standards and the community needs to be reminded
(best practices?) or perhaps new codes new to be suggested. volunteer?

6. Proposals of new solutions: We have seen a number of proposals including
those from : Alejandro, Bala, Hadmut. This solutions and others need to be
mentioned in the taxonomy. Other proposals may still be submitted.

7. Best Practices documents

7.a. End-users

7.b. Mail administrators.

7.c. Mass Mailers

-----Part 3. Evaluate Solutions:

8. Evaluation of proposals

8.a. create evaluation model. usefulness and cost. We have a start here
mentioned in the charter. Vernon also made good suggestion based on
deployment needed for effectiveness. This should tie in with requirements.
Volunteer? 8.b. threat model and analysis. Volunteer? 8.c. do evaluations.
Not ready for this yet.

[w***@elan.net]

I'll take opt-out. I had notes on that and identified 3 automated out-out
paths (sorted by type of distribution/access to such lists):

1. Distributed lists which use some type of encryption to allow validation
of particular address but not see enter list. Please comment here on all
types of encryption methods that are available.

2. Opt-out server. Here a special service/server (maybe more then one) is
located somewhere. Anybody wishing to check of address is opt-out or not
can connect to that server (with proper authentication if necessary) and
check validity of particular email address.

3. Opt-out system as part of each mail server. Here new command is added
to mail server which allows to check if email is opted out or not.
Separate lists are run by every isp/every email server and are particular
only to email addresses handled by mail server. Its assumed that before or
during email connection command would be issues to verify opt-out
preferences before delivering email.

Any other distribution means I missed?

Post by Paul Judge
Here is the list of work items that have been identified. If there are other
items that should be added to the list, please propose them. All
conversation on this mailing list must be regarding one of these items. The
subject of each email should begin with the number of the appropriate work
item. For example, "2.a - Spam Measurement Survey Requirements" or "6 -
Proposal for hash-based traceback system". The list volume makes it
difficult to follow individual conversations and to filter the noise. This
will help eliminate both problems. If anyone has a problem following this
convention, please let me know. This is a research group. If you have
constructive feedback, please share it. If you just feel like saying that
"spam can not be stopped" or "this group will fail because I said so", then
you should state those things elsewhere. This mailing list is for the
discussion of ideas that make progress towards the goals of these group as
stated in the charter. I have the option of changing this research group
into a closed research group. If we decide that the noise continues to
affect persons making contributions, then we will exercise that option.
1. Inventory of problems. started by Liudvikas Bukys. I will distribute the
latest version. Liudvikas, would you like to resume ownership of this
document?
2. Characterization of the problems
2.a. Spam Measurements. This works needs to be focused on immediately. This
data will help us understand the current weaknesses in the system and where
efforts should be focused. Requirements need to be set and then we have to
gather the data. I see two separate paths here: One is based on user survey
input. Ted Gavin has volunteered to conduct this. The other data is based on
real spam measurements. Once the requirements are gathered, Brightmail,
CipherTrust, CloudMark and MessageLabs have each volunteered to contribute
information. Any other volunteers?
2.b. Public Trace Data - www.spamarchive.org
2.c. Spam Categorization
2.c.1.where it comes from - there was a thread started by someone on this.
Anyone remember the title? This feeds into 7.b. threat model. 2.c.2.
different types - Brightmail has a high-level classification. SurfControl
might also have something here. Ken S. and Susan G., do either of you have
some more granular classifications that you would like to share? Volunteer
to lead this effort?
3. Requirements for solutions: Started by Keith Moore. I distributed Draft 1
based on feedback. Keith, would you like to take over moving this forward?
4. Survey of solution
4.a. Taxonomy. Draft three was distributed. There was only one comment. So I
assume we are getting close. 4.b. Survey. Summarize set of solutions and
place into taxonomy. 4.c Bibliography of spam research related work. Frank
de Lange has started this effort.
5. Identification of need for interoperable systems
5.a. Spam Test Message. led by Matt Sergeant
5.b. Opt-out. The idea here is that there should be a standard method of
opting-out so that it can be done by a program. There should also be a way
to systemically verify compliance. volunteer?
5.c. Filtered Message Status. The point here is that messages are dropped by
filters with either no status indication or inconsistent ones. The goal is
to agree on a set of acceptable responses. Perhaps this information is
already specified in SMTP standards and the community needs to be reminded
(best practices?) or perhaps new codes new to be suggested. volunteer?
6. Proposals of new solutions: We have seen a number of proposals including
those from : Alejandro, Bala, Hadmut. This solutions and others need to be
mentioned in the taxonomy. Other proposals may still be submitted.
7. Best Practices documents
7.a. End-users
7.b. Mail administrators.
7.c. Mass Mailers
8. Evaluation of proposals
8.a. create evaluation model. usefulness and cost. We have a start here
mentioned in the charter. Vernon also made good suggestion based on
deployment needed for effectiveness. This should tie in with requirements.
Volunteer? 8.b. threat model and analysis. Volunteer? 8.c. do evaluations.
Not ready for this yet.
_______________________________________________
Asrg mailing list
https://www1.ietf.org/mailman/listinfo/asrg

[Brad Templeton]

Post by w***@elan.net
I'll take opt-out. I had notes on that and identified 3 automated out-out
1. Distributed lists which use some type of encryption to allow validation
of particular address but not see enter list. Please comment here on all
types of encryption methods that are available.
2. Opt-out server. Here a special service/server (maybe more then one) is
located somewhere. Anybody wishing to check of address is opt-out or not
can connect to that server (with proper authentication if necessary) and
check validity of particular email address.
3. Opt-out system as part of each mail server. Here new command is added
to mail server which allows to check if email is opted out or not.
Separate lists are run by every isp/every email server and are particular
only to email addresses handled by mail server. Its assumed that before or
during email connection command would be issues to verify opt-out
preferences before delivering email.
Any other distribution means I missed?

Unfortunately, distributed lists of hashes of e-mails don't work for secrecy.
Spammers have lists of millions of email addresses. They can just compare
the hashes against them and turn the list of hashes into a list of real
addresses. At least for those on the lists. Which is most of us. If you
get spam, you're on these lists. If you don't get spam, you don't have
much reason to get on the opt-out list.

In fact, anything that will "clean" a list of opted-out people is a way to,
using the 50 million email address spammer's database, get almost all the
list of people who opted out.

Now the question is, do you need secrecy of the names? It certainly would
be nice, since you should ideally not have to declare your address in public
in order to get your privacy! But there is no great solution here.

In fact, the only solution I have come up with requires us to all get new
E-mail addresses. This would be a pattern, such as a reserved word lower
level domain part. Thus ***@ns.elan.net (with "ns" in it) would be
an address declared to have opted out.

That's not very exciting but I am open to other solutions for an opt out list.

The other reason it's necessary is that email addresses are not unique.
Many people own whole domains and get all mail to *@domain.com. All
sendmail users get all mail to username+*@domain.com. All qmail users
get all mail to username-*@domain.com. There are many other examples.

Also, user%***@otherdomain.com is a valid e-mail for you if otherdomain
relays. There are an infinite number of variations.

That leaves us with option 3, which can deal with that. Problem is (legit)
relaying. This requires every MX server to know the policy of every user it
MXs for.


I think it sucks, but a reserved word domain is the only solution I have been
able to come up with. Thus plus is that while we all have to get new emails
if you want such a system, it's pretty easy to guess the new address from the
old one.


However, in the end, opt-out and opt-in laws are pretty demonstrably fruitless.
We have 25 laws already, and leaving aside their highly debatable
constitutionality, that they are entirely ineffective does not seem subject
to debate any more.

[w***@elan.net]

Ok, I'm going to add "Modification of email address to show opt-out
choice" as #4 in my list. And to a degree this system is already widely
used when somebody adds "#listname" as part of email address, they show
choice to be opt-in to specific mail list but not others and afterwards
they filter based on this choice.

Regarding #1 (distributed hash list of email address). I'd like somebody
who has exact proposal on this issue speak up and explain this in detail,
especially cipher algorithms used, why its safe, etc. (did Verisign
had some paper, anybody wants to point me?). Then whoever is in
opposition and think this will not work, should explain problems and
technical issues in proposal.

Also regarding #3 where there maybe a problem that all mail servers (even
backups mxs) would need to answer if user is opted out or not, the
solution to this is to build separate opt-out choice report protocol
and have separarte SRV record for it. To be honest this is actually my
preferable choice, I thought to make it a part of "filtering configuration"
database as public information available from such database where as
actual filters to be used would be private information. But I consider
this approach to be subpart of #3 and in the future iteration of choices
for opt-out will list it as subsection.

Also should I mention as separate topic for opt-out an enforcement of
opt-out choices? These can include laws in support of opt-out, distributed
black lists of those companies that did not honor opt-out, etc.

Post by Brad Templeton

Post by w***@elan.net
I'll take opt-out. I had notes on that and identified 3 automated out-out
1. Distributed lists which use some type of encryption to allow validation
of particular address but not see enter list. Please comment here on all
types of encryption methods that are available.
2. Opt-out server. Here a special service/server (maybe more then one) is
located somewhere. Anybody wishing to check of address is opt-out or not
can connect to that server (with proper authentication if necessary) and
check validity of particular email address.
3. Opt-out system as part of each mail server. Here new command is added
to mail server which allows to check if email is opted out or not.
Separate lists are run by every isp/every email server and are particular
only to email addresses handled by mail server. Its assumed that before or
during email connection command would be issues to verify opt-out
preferences before delivering email.
Any other distribution means I missed?

Unfortunately, distributed lists of hashes of e-mails don't work for secrecy.
Spammers have lists of millions of email addresses. They can just compare
the hashes against them and turn the list of hashes into a list of real
addresses. At least for those on the lists. Which is most of us. If you
get spam, you're on these lists. If you don't get spam, you don't have
much reason to get on the opt-out list.
In fact, anything that will "clean" a list of opted-out people is a way to,
using the 50 million email address spammer's database, get almost all the
list of people who opted out.
Now the question is, do you need secrecy of the names? It certainly would
be nice, since you should ideally not have to declare your address in public
in order to get your privacy! But there is no great solution here.
In fact, the only solution I have come up with requires us to all get new
E-mail addresses. This would be a pattern, such as a reserved word lower
an address declared to have opted out.
That's not very exciting but I am open to other solutions for an opt out list.
The other reason it's necessary is that email addresses are not unique.
relays. There are an infinite number of variations.
That leaves us with option 3, which can deal with that. Problem is (legit)
relaying. This requires every MX server to know the policy of every user it
MXs for.
I think it sucks, but a reserved word domain is the only solution I have been
able to come up with. Thus plus is that while we all have to get new emails
if you want such a system, it's pretty easy to guess the new address from the
old one.
However, in the end, opt-out and opt-in laws are pretty demonstrably fruitless.
We have 25 laws already, and leaving aside their highly debatable
constitutionality, that they are entirely ineffective does not seem subject
to debate any more.

[Kee Hinckley]

Post by w***@elan.net
Any other distribution means I missed?

There are psuedo standards (Maybe there's an RFC? I haven't checked.
Probably.) such as the one followed by this list:

List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/asrg>,
<mailto:asrg-***@ietf.org?subject=unsubscribe>

I should note that there seems to be some variation in the format of
that field (I had to write a parser for it last month).

I'm not sure where mail-based opt-out systems fall in what you are
putting together.

The other two semi-standards are the listname-***@example.com
(with subject unsubscribe) and listname-***@example.com.

[V***@vt.edu]

Post by Kee Hinckley

Post by w***@elan.net
Any other distribution means I missed?

There are psuedo standards (Maybe there's an RFC? I haven't checked.
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/asrg>,

2369 The Use of URLs as Meta-Syntax for Core Mail List Commands and
their Transport through Message Header Fields. G. Neufeld, J. Baer.
July 1998. (Format: TXT=30853 bytes) (Status: PROPOSED STANDARD)

2919 List-Id: A Structured Field and Namespace for the Identification
of Mailing Lists. R. Chandhok, G. Wenger. March 2001. (Format:
TXT=18480 bytes) (Status: PROPOSED STANDARD)

[w***@elan.net]

This is slightly different, for once it applies only to mailinglists and
2nd is that its HOW TO opt out if mailing list you're already on and not
a system indicating global opt-in/out choice.

But I guess I might need to separate into the section of how to indicate
that you want to be opt-out for new senders of commercial email and
section on how to actually opt-out when you're already receiving email.

Or possibly sections should be for global opt-out and specific opt-out to
particular maillist or particular domain.

P.S. Yes, there is an RFC 2369 on mailing list headers.

Post by Kee Hinckley

Post by w***@elan.net
Any other distribution means I missed?

There are psuedo standards (Maybe there's an RFC? I haven't checked.
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/asrg>,
I should note that there seems to be some variation in the format of
that field (I had to write a parser for it last month).
I'm not sure where mail-based opt-out systems fall in what you are
putting together.

[J C Lawrence]

On Tue, 25 Mar 2003 15:15:14 -0500

Post by Kee Hinckley

Post by w***@elan.net
Any other distribution means I missed?

There are psuedo standards (Maybe there's an RFC? I haven't
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/asrg>,

RFC 2369.

[w***@elan.net]

Here are my updated notes on Opt-Out:

I. Use of Opt-Out
1. How far is opt out applied
a. To do global opt-out for all commercial email services
b. To do opt-out for some special email-list or particular types of email
2. Timing reference for opting out
a. For existing ones that already send you email and participate in
the system.
b. For future ones that may want to send you email
c. For certain period of time (when you're on vacacation)
and can not receive as much email

I could not yet formulate what is to be said in this section, please help!

II. How opt-out is delivered

1. Distributed lists which use some type of encryption to allow validation
of particular address but not see enter list.
Pros:
a. Opt-out lists can be easily cleaned up before the transmission
b. Distribution of lists can be controlled by tightly controlled
Cons:
a. Serious issues that the encryption technology maybe broken
later on and as such allow to get clear list of all opted-out
email addresses
b. Distribution lists can easily go sub-distributed and go beyoned
authenticated base and thereafter abused
c. Patents relating to the encryption technologies exists
d. Concerns about who and how will make opt-out lists and distribute
them
e. Concerns that opt-out lists will instead be used to verify if
email address in spammer database is real

2. Opt-out server. Here special service/server is made available to
legit bulk-mailers. Anybody wishing to check if the address is
opt-out or not can connect to that server and check
Variations:
2a. One unified service is made available by the goverment or icann, etc
2b. A number of special opt-out servers exist in parallel which

are used/run by different groups of commercial mailers
Pros:
a. Opt-out lists can be cleaned up before the transmission begins
b. Distribution of lists can be controlled by tightly controlled
the authentication means can be well controlled to not allow
distribution certain allowed list of entities
Cons:
a. Special opt-out verification protocol may have to be developed
b. Concerns about who and how will run opt-out service
c. Concerns that opt-out service will instead be used to verify if
email address in spammer database is real

3. Opt-out system maintained together with mail servers on per-domain basis.
Variations:
3a. Service made available as part of mail server, new command added
to SMTP to check opt-out preference of user on email server
3b. Service made available as part of mail transmission and is more
tightly integrated with actually sending email, i.e. email being
sent contains some preference for opt-out check and email server
can based on that return email back with proper error code
Note: to a degree this is what some filters already do ...
3c. Service made available through separate protocol to be run by ISP
on per-domain basis.
Pros:
a. An opt-out is controlled by mail server operator and not any
questinable central agency.
b. Depending on how system is implemented it maybe a lot harder to
actually gather list of valid email addresses (mail server
operator may choose to answer opted-out for any email address
that does not exist, for example)
Cons:
a. A new protocol (or extensions to SMTP) need to be developed
b. It maybe a lot harder to clean up lists before emailing
(maybe this this also good thing?)
c. If implemented as in 3a all MX servers (even backups) may need
to answer yes on question of opt-out, this created
implementation problems and seems unnecessary

4. Modification of Email address to show opt-out choice.
Variations:
4a. General opt-out choice recognized by everybody, which may
actually be some variation of mail service domain/subdomain
4b. Opt-in choice specific to particular situation or mailing list
example - email+***@domain.com
Pros:
a. Very easy to implement and does not require new technology, 4b
is already actively used by many
b. Address itself shows optout choice, so spammers can not do
email address cleanup for purposes of finding valid address
Note: this is also a Con!
c. Opt-out choice is controlled by each individual user and not by
external entity (be it central agency or mail service provider)
Cons:
a. This generally requires us to use different email address then
what we already do, often even more then one. It does not address
issues with existing currently use email addresses (see
section I on what we want to do), this is a BIG Con.
b. Use of "special" email address may also be taken by spammers as
verification that email address is valid!

III. Enforcement of Opt-Out
Note: #1 and #2 below may well be done in parallel
1. Done by goverment by legislation to have all commercial email marketers
participate in some system or abide by specific protocol standards
Enforcement is afterwards left to courts
Pros:
a. There would be clear guidelines for commercial email senders to
follow and if they do not they will pay an actual price for it
b. Its a lot more likely commercial businesses will follow the law
Cons:
a. This maybe problematic when considering email as global system
and not specific to US or EU laws
b. It takes some time for laws to be passed and then be verified
in courts to be workable
2. Enforcement is left to ISP/mail server operators through use of
filters if email is found to be from commercial email marketer
that is known to mail server operator
Pros:
a. Filtering is already well adapted technology
b. When email is found to have violated opt-out choice, stopping
future email from the particular marketer is easy and fast
(blacklist) but it does require marketers to be well identified
Cons:
a. Use of filtering means some email will inevitably be filtered
b. Filters will never completed stop unwanted email even with
opt-out choice, some email marketers may choose not to follow it


------
William Leibzon
Elan Communications Inc.
***@elan.net

[Brad Templeton]

Post by w***@elan.net
a. Serious issues that the encryption technology maybe broken
later on and as such allow to get clear list of all opted-out
email addresses

Alas, there is no maybe about it.

Spammer's List of 50 million E-mail addresses | cleaning service | diff

Will get you effectively all the email addresses that have gone on
the opt-out list. I mean, if you aren't on the spammer's lists, you have
minimal reasons to go on the opt-out list so it is effectively complete.
(Though corporate sites can put their entire population on the list
with safety, but in that case why not just list the domain rather than
the individuals.)

[w***@elan.net]

Also this must be added to the list as separate item -

Proposal for new topic to be added to list of ASRG work items (discussion
topics list) and/or modifications to ASRG work items list. Might want to
put this as "item 0".

Post by Paul Judge
Here is the list of work items that have been identified. If there are other
items that should be added to the list, please propose them. All
conversation on this mailing list must be regarding one of these items. The
subject of each email should begin with the number of the appropriate work
item. For example, "2.a - Spam Measurement Survey Requirements" or "6 -
Proposal for hash-based traceback system". The list volume makes it
difficult to follow individual conversations and to filter the noise. This
will help eliminate both problems. If anyone has a problem following this
convention, please let me know. This is a research group. If you have
constructive feedback, please share it. If you just feel like saying that
"spam can not be stopped" or "this group will fail because I said so", then
you should state those things elsewhere. This mailing list is for the
discussion of ideas that make progress towards the goals of these group as
stated in the charter. I have the option of changing this research group
into a closed research group. If we decide that the noise continues to
affect persons making contributions, then we will exercise that option.
1. Inventory of problems. started by Liudvikas Bukys. I will distribute the
latest version. Liudvikas, would you like to resume ownership of this
document?
2. Characterization of the problems
2.a. Spam Measurements. This works needs to be focused on immediately. This
data will help us understand the current weaknesses in the system and where
efforts should be focused. Requirements need to be set and then we have to
gather the data. I see two separate paths here: One is based on user survey
input. Ted Gavin has volunteered to conduct this. The other data is based on
real spam measurements. Once the requirements are gathered, Brightmail,
CipherTrust, CloudMark and MessageLabs have each volunteered to contribute
information. Any other volunteers?
2.b. Public Trace Data - www.spamarchive.org
2.c. Spam Categorization
2.c.1.where it comes from - there was a thread started by someone on this.
Anyone remember the title? This feeds into 7.b. threat model. 2.c.2.
different types - Brightmail has a high-level classification. SurfControl
might also have something here. Ken S. and Susan G., do either of you have
some more granular classifications that you would like to share? Volunteer
to lead this effort?
3. Requirements for solutions: Started by Keith Moore. I distributed Draft 1
based on feedback. Keith, would you like to take over moving this forward?
4. Survey of solution
4.a. Taxonomy. Draft three was distributed. There was only one comment. So I
assume we are getting close. 4.b. Survey. Summarize set of solutions and
place into taxonomy. 4.c Bibliography of spam research related work. Frank
de Lange has started this effort.
5. Identification of need for interoperable systems
5.a. Spam Test Message. led by Matt Sergeant
5.b. Opt-out. The idea here is that there should be a standard method of
opting-out so that it can be done by a program. There should also be a way
to systemically verify compliance. volunteer?
5.c. Filtered Message Status. The point here is that messages are dropped by
filters with either no status indication or inconsistent ones. The goal is
to agree on a set of acceptable responses. Perhaps this information is
already specified in SMTP standards and the community needs to be reminded
(best practices?) or perhaps new codes new to be suggested. volunteer?
6. Proposals of new solutions: We have seen a number of proposals including
those from : Alejandro, Bala, Hadmut. This solutions and others need to be
mentioned in the taxonomy. Other proposals may still be submitted.
7. Best Practices documents
7.a. End-users
7.b. Mail administrators.
7.c. Mass Mailers
8. Evaluation of proposals
8.a. create evaluation model. usefulness and cost. We have a start here
mentioned in the charter. Vernon also made good suggestion based on
deployment needed for effectiveness. This should tie in with requirements.
Volunteer? 8.b. threat model and analysis. Volunteer? 8.c. do evaluations.
Not ready for this yet.
_______________________________________________
Asrg mailing list
https://www1.ietf.org/mailman/listinfo/asrg

[w***@elan.net]

Also I'd like to add additional topic - IPR. I know IRTF currently does
not have IPR policy, but I'd like one established just for this research
group. I think we can do the following:

1. Whenever somebody mentions technology where they know some patent exist
or may possibly apply to the technology, the person should make statement
about IPR rights. If this patent has not been mentioned before on list,
there should be information either together with IPR statement or at the
end of message with either:
a. If patent is received: US (or other country), Patent#, possibly link
to the patent website
b. If patent is pending - Name of person or organization that filed it
and date it was filed, possibly application#

2. I would like to see somebody on the list volunteer to maintain list
of all patents mentioned (see abobve) and this list provided either
regularly to email list or located and updated on rg website.

Post by Paul Judge
Here is the list of work items that have been identified. If there are other
items that should be added to the list, please propose them. All
conversation on this mailing list must be regarding one of these items. The
subject of each email should begin with the number of the appropriate work
item. For example, "2.a - Spam Measurement Survey Requirements" or "6 -
Proposal for hash-based traceback system". The list volume makes it
difficult to follow individual conversations and to filter the noise. This
will help eliminate both problems. If anyone has a problem following this
convention, please let me know. This is a research group. If you have
constructive feedback, please share it. If you just feel like saying that
"spam can not be stopped" or "this group will fail because I said so", then
you should state those things elsewhere. This mailing list is for the
discussion of ideas that make progress towards the goals of these group as
stated in the charter. I have the option of changing this research group
into a closed research group. If we decide that the noise continues to
affect persons making contributions, then we will exercise that option.
1. Inventory of problems. started by Liudvikas Bukys. I will distribute the
latest version. Liudvikas, would you like to resume ownership of this
document?
2. Characterization of the problems
2.a. Spam Measurements. This works needs to be focused on immediately. This
data will help us understand the current weaknesses in the system and where
efforts should be focused. Requirements need to be set and then we have to
gather the data. I see two separate paths here: One is based on user survey
input. Ted Gavin has volunteered to conduct this. The other data is based on
real spam measurements. Once the requirements are gathered, Brightmail,
CipherTrust, CloudMark and MessageLabs have each volunteered to contribute
information. Any other volunteers?
2.b. Public Trace Data - www.spamarchive.org
2.c. Spam Categorization
2.c.1.where it comes from - there was a thread started by someone on this.
Anyone remember the title? This feeds into 7.b. threat model. 2.c.2.
different types - Brightmail has a high-level classification. SurfControl
might also have something here. Ken S. and Susan G., do either of you have
some more granular classifications that you would like to share? Volunteer
to lead this effort?
3. Requirements for solutions: Started by Keith Moore. I distributed Draft 1
based on feedback. Keith, would you like to take over moving this forward?
4. Survey of solution
4.a. Taxonomy. Draft three was distributed. There was only one comment. So I
assume we are getting close. 4.b. Survey. Summarize set of solutions and
place into taxonomy. 4.c Bibliography of spam research related work. Frank
de Lange has started this effort.
5. Identification of need for interoperable systems
5.a. Spam Test Message. led by Matt Sergeant
5.b. Opt-out. The idea here is that there should be a standard method of
opting-out so that it can be done by a program. There should also be a way
to systemically verify compliance. volunteer?
5.c. Filtered Message Status. The point here is that messages are dropped by
filters with either no status indication or inconsistent ones. The goal is
to agree on a set of acceptable responses. Perhaps this information is
already specified in SMTP standards and the community needs to be reminded
(best practices?) or perhaps new codes new to be suggested. volunteer?
6. Proposals of new solutions: We have seen a number of proposals including
those from : Alejandro, Bala, Hadmut. This solutions and others need to be
mentioned in the taxonomy. Other proposals may still be submitted.
7. Best Practices documents
7.a. End-users
7.b. Mail administrators.
7.c. Mass Mailers
8. Evaluation of proposals
8.a. create evaluation model. usefulness and cost. We have a start here
mentioned in the charter. Vernon also made good suggestion based on
deployment needed for effectiveness. This should tie in with requirements.
Volunteer? 8.b. threat model and analysis. Volunteer? 8.c. do evaluations.
Not ready for this yet.
_______________________________________________
Asrg mailing list
https://www1.ietf.org/mailman/listinfo/asrg

[Brian Witwicki]

Intellectual Property, Legal cases and Patents

I would be prepared to keep track of patents, IP and spam cases and report
on them.
I have experience in IP law (Class of '76 - PunchCard 301) and am very
interested in how this mail problem will be solved. The law approach itself
is severely limited in its jurisdiction, and is most often geographically
applied. Reliable evidence is also a problem ie. how and from whom can it be
obtained
It may be that a spam solution will be almost exclusively, a technical one.
There are many patents in the Internet space and some covering commerce
systems may have aspects which have partial application in the solution of
this problem.

Brian

----- Original Message -----
From: <***@elan.net>
To: "Paul Judge" <***@ciphertrust.com>
Cc: <***@ietf.org>
Sent: Monday, March 24, 2003 6:03 PM
Subject: Re: [Asrg] ASRG work items

Post by w***@elan.net
Also I'd like to add additional topic - IPR. I know IRTF currently does
not have IPR policy, but I'd like one established just for this research
1. Whenever somebody mentions technology where they know some patent exist
or may possibly apply to the technology, the person should make statement
about IPR rights. If this patent has not been mentioned before on list,
there should be information either together with IPR statement or at the
a. If patent is received: US (or other country), Patent#, possibly link
to the patent website
b. If patent is pending - Name of person or organization that filed it
and date it was filed, possibly application#
2. I would like to see somebody on the list volunteer to maintain list
of all patents mentioned (see abobve) and this list provided either
regularly to email list or located and updated on rg website.
_______________________________________________
Asrg mailing list
https://www1.ietf.org/mailman/listinfo/asrg

[w***@elan.net]

Regarding of failure of delivery due to spam, this is currently what
systems do:

I. Abort during tranmission by giving usually 5xx error message. Often
providing comments as part of 5xx error code on that email is not
accepted because its suspected to be spam.
Topic to work on:
a. Check to see what 5xx messages various systems give.
b. Identify if we need additional 5xx message just for message not
accepted dur to content problems (spam)
c. Identify if we need extended error codes for anti-spam filters and if
so only one or multiple ones
d. Identify if we need to standartize on comments as well (i.e. not
accepted because listed in xxxx blacklist with comments used to
indicate what blacklist in universally accepted format, etc).

II. Return email after it has been scannded by the filter and found to be
unacceptable to system/user.

1. These is what included in return email as far as its original:
a. Only says that particular email (usually identfied by subject) is not
accepted but does not include actual email with it
b. Return email and headers but not content of the email.
c. Return entire email including content

2. What is included in addition to returned email:
a. Return email without any information on why this was done
b. Provide information that email was stopped because its spam with
various levels or reporting up to indicating what exactly is wrong
or what filter was used
c. Return not the email but request for authentication (such website
address where only human would be able to authenicate) so that
sender's email address is added to some kind of whitelist

3. There several addesses used for returning email:
a. MAIL-FROM - most use this and this is appropriate
b. "From:" - used by some filters that do not see MAIL-FROM or for some
reason choose to ignore it
c. "Reply-To:". Same as above, but this is rare
d. Send email (even returned ones) to ***@abuse.net. Not recommended
for automated system to do this, but some users configure that anyway.
But this is done in part because of in many spam emails "MAIL-FROM" is
invalid and automated system does need some valid email address to
return to.

4. Topics to work on:
a. What possible formats are used for returning email
b. Should we standartize format
c. If standardize what options as far as what information is included
d. Need to discuss regarding return email address in particular due to
spammers using invalid mail form and arrive at standards on what
email address is to be used for unaccepted spam emails
e. For requests for authentication, should we standartize that? Is that
possible? How?

Please comment on anything above.

Post by Paul Judge
Here is the list of work items that have been identified. If there are other
items that should be added to the list, please propose them. All
conversation on this mailing list must be regarding one of these items. The
subject of each email should begin with the number of the appropriate work
item. For example, "2.a - Spam Measurement Survey Requirements" or "6 -
Proposal for hash-based traceback system". The list volume makes it
difficult to follow individual conversations and to filter the noise. This
will help eliminate both problems. If anyone has a problem following this
convention, please let me know. This is a research group. If you have
constructive feedback, please share it. If you just feel like saying that
"spam can not be stopped" or "this group will fail because I said so", then
you should state those things elsewhere. This mailing list is for the
discussion of ideas that make progress towards the goals of these group as
stated in the charter. I have the option of changing this research group
into a closed research group. If we decide that the noise continues to
affect persons making contributions, then we will exercise that option.
1. Inventory of problems. started by Liudvikas Bukys. I will distribute the
latest version. Liudvikas, would you like to resume ownership of this
document?
2. Characterization of the problems
2.a. Spam Measurements. This works needs to be focused on immediately. This
data will help us understand the current weaknesses in the system and where
efforts should be focused. Requirements need to be set and then we have to
gather the data. I see two separate paths here: One is based on user survey
input. Ted Gavin has volunteered to conduct this. The other data is based on
real spam measurements. Once the requirements are gathered, Brightmail,
CipherTrust, CloudMark and MessageLabs have each volunteered to contribute
information. Any other volunteers?
2.b. Public Trace Data - www.spamarchive.org
2.c. Spam Categorization
2.c.1.where it comes from - there was a thread started by someone on this.
Anyone remember the title? This feeds into 7.b. threat model. 2.c.2.
different types - Brightmail has a high-level classification. SurfControl
might also have something here. Ken S. and Susan G., do either of you have
some more granular classifications that you would like to share? Volunteer
to lead this effort?
3. Requirements for solutions: Started by Keith Moore. I distributed Draft 1
based on feedback. Keith, would you like to take over moving this forward?
4. Survey of solution
4.a. Taxonomy. Draft three was distributed. There was only one comment. So I
assume we are getting close. 4.b. Survey. Summarize set of solutions and
place into taxonomy. 4.c Bibliography of spam research related work. Frank
de Lange has started this effort.
5. Identification of need for interoperable systems
5.a. Spam Test Message. led by Matt Sergeant
5.b. Opt-out. The idea here is that there should be a standard method of
opting-out so that it can be done by a program. There should also be a way
to systemically verify compliance. volunteer?
5.c. Filtered Message Status. The point here is that messages are dropped by
filters with either no status indication or inconsistent ones. The goal is
to agree on a set of acceptable responses. Perhaps this information is
already specified in SMTP standards and the community needs to be reminded
(best practices?) or perhaps new codes new to be suggested. volunteer?
6. Proposals of new solutions: We have seen a number of proposals including
those from : Alejandro, Bala, Hadmut. This solutions and others need to be
mentioned in the taxonomy. Other proposals may still be submitted.
7. Best Practices documents
7.a. End-users
7.b. Mail administrators.
7.c. Mass Mailers
8. Evaluation of proposals
8.a. create evaluation model. usefulness and cost. We have a start here
mentioned in the charter. Vernon also made good suggestion based on
deployment needed for effectiveness. This should tie in with requirements.
Volunteer? 8.b. threat model and analysis. Volunteer? 8.c. do evaluations.
Not ready for this yet.
_______________________________________________
Asrg mailing list
https://www1.ietf.org/mailman/listinfo/asrg

[Kee Hinckley]

Post by w***@elan.net
c. Identify if we need extended error codes for anti-spam filters and if
so only one or multiple ones
d. Identify if we need to standartize on comments as well (i.e. not
accepted because listed in xxxx blacklist with comments used to
indicate what blacklist in universally accepted format, etc).

I think that some type of extended response would be very valuable.
If people are really going to implement challenge/response systems of
one kind or another, they need a standard mechanism for instructing a
sender. This is going to involve, at minimum, some text followed by
a URL (which might be as simple as a mailto: for a "white hole"
address that the sender can send to complain about a blacklist).
Possibly the text should be split into human readable and machine
readable sections.

I think this should be specified at both the SMTP and
returned-message level. This is the only hope we have of getting
mailing lists and automated mail systems to work in an environment
with lots of different anti-spam systems. We *really* don't want to
go back to the mess that existed 10-15 years ago with zillions of
different mail systems providing completely different bounce
messages. Been there, done that.

[Vernon Schryver]

... This is the only hope we have of getting
mailing lists and automated mail systems to work in an environment
with lots of different anti-spam systems. We *really* don't want to
go back to the mess that existed 10-15 years ago with zillions of
different mail systems providing completely different bounce
messages. Been there, done that.

Why wouldn't RFC 2919 and RFC 2369 headers be sufficient?

Why wouldn't yet more new SMTP gadgets only make things worse?


Vernon Schryver ***@rhyolite.com

[w***@elan.net]

I'd like to ask what people feel about making it a part of anti-spam
system such that if say somebody is sending same content message to more
then 5-10 recepients on your server, then it has to be considered
maillist email and has to contain proper maillist headers and opt-out
information.

Of course, spammers can add all these headers as well but we can make some
kind of black/whitelist of good well known mailing lists or even do some
kind of stamp-like system to verify the email is sent from good maillist.

Post by Vernon Schryver

... This is the only hope we have of getting
mailing lists and automated mail systems to work in an environment
with lots of different anti-spam systems. We *really* don't want to
go back to the mess that existed 10-15 years ago with zillions of
different mail systems providing completely different bounce
messages. Been there, done that.

Why wouldn't RFC 2919 and RFC 2369 headers be sufficient?
Why wouldn't yet more new SMTP gadgets only make things worse?
_______________________________________________
Asrg mailing list
https://www1.ietf.org/mailman/listinfo/asrg

[Matt Sergeant]

Post by w***@elan.net
I'd like to ask what people feel about making it a part of anti-spam
system such that if say somebody is sending same content message to more
then 5-10 recepients on your server, then it has to be considered
maillist email and has to contain proper maillist headers and opt-out
information.

I consider it wishful thinking ;-)

Try it as a heuristic on an ISP's mail server and you'll soon see why.

Matt.

[w***@elan.net]

Do you mean that emails by spammers are different between what user they
are sent (personalized, etc) to and would not be classifiable as mass
mailing?

Or did you mean that users do send one email to multitude of their
friends and depending on size of isp they may very well be on the same
domain?

Post by Matt Sergeant

Post by w***@elan.net
I'd like to ask what people feel about making it a part of anti-spam
system such that if say somebody is sending same content message to more
then 5-10 recepients on your server, then it has to be considered
maillist email and has to contain proper maillist headers and opt-out
information.

I consider it wishful thinking ;-)
Try it as a heuristic on an ISP's mail server and you'll soon see why.
Matt.
_______________________________________________
Asrg mailing list
https://www1.ietf.org/mailman/listinfo/asrg

[Matt Sergeant]

Post by w***@elan.net
Do you mean that emails by spammers are different between what user they
are sent (personalized, etc) to and would not be classifiable as mass
mailing?
Or did you mean that users do send one email to multitude of their
friends and depending on size of isp they may very well be on the same
domain?

I meant that lots of people regularly post to multiple recipients and
it's not a mailing list. Business mails and personal mails. If you make
this a heuristic in a spam detection mechanism it will be next to
useless. If you make this a *requirement* in a mail system it will
catch almost nothing but false positives.

PS: Please try not to top post - I had to completely snip the context
in this reply as I couldn't get it to make sense any more.

[Kee Hinckley]

Post by w***@elan.net
I'd like to ask what people feel about making it a part of anti-spam
system such that if say somebody is sending same content message to more
then 5-10 recepients on your server, then it has to be considered
maillist email and has to contain proper maillist headers and opt-out
information.

Well, first of all it doesn't scale. Someone who sends to 5-10
recipients at somewhere.com just exceeded the number of humans with
addresses there. Someone who sends to 5-10 AOL users is just in the
noise.

But more critically. People send mail to everyone in their address
book a lot. (And I've got 40,000+ email messages to
***@somewhere.com that I can offer as evidence.) Those
messages are very likely to exceed that per-server limit.

[Chuq Von Rospach]

Post by Kee Hinckley

Post by w***@elan.net
I'd like to ask what people feel about making it a part of anti-spam
system such that if say somebody is sending same content message to more
then 5-10 recepients on your server, then it has to be considered
maillist email and has to contain proper maillist headers and opt-out
information.

Well, first of all it doesn't scale. Someone who sends to 5-10
recipients at somewhere.com just exceeded the number of humans with
addresses there. Someone who sends to 5-10 AOL users is just in the
noise.
But more critically.

But more critically, off the top of my head.

It breaks all majordomo installations out there. (all of them would
have to be updated to either the unreleased Majordomo II, Mailman,
Sympa, or something). It also breaks any mail list where an admin has
disabled those headers because he doesn't like them (which, if you
check out the mailman archives, has been a continuing discussion,
mostly because, it seems, eudora for windows doesn't hide those
headers, and admins therefore break the mail list software instead of
fixing the client. But I'm not bitter)

It breaks all of those people who have extended announce lists in their
address books.

It breaks all people who set up informal lists via sendmail aliases or
their equivalent in other MTAs.

It breaks 5-6 emails I send a day to a bunch of individuals. Never does
it seem to be the same 5-6 individuals.

It breaks all sorts of things. Does it solve anything? No. spammers
will simply start adding those lines, since there seems to be no intent
to see if the lines actually are valid or relevant (and how would you?)

In other words, we've re-invented the "Approved: header" in the
NNTP/USENET protocol, meaning we haven't really invented anything
useful unless the user population agrees to manage it voluntarily or
there's some form of cyber-cancel bot to retro-delete the stuff.

Sorry, not a good proposal.

[Brad Templeton]

Post by w***@elan.net
I'd like to ask what people feel about making it a part of anti-spam
system such that if say somebody is sending same content message to more
then 5-10 recepients on your server, then it has to be considered
maillist email and has to contain proper maillist headers and opt-out
information.
Of course, spammers can add all these headers as well but we can make some
kind of black/whitelist of good well known mailing lists or even do some
kind of stamp-like system to verify the email is sent from good maillist.

This is a reasonable step, but spammers are already quite adept at altering
the content of their emails to individualize them sufficiently to avoid
such tests, as we know. There is at best an arms race at that.

I do agree that bulk mail should be tagged as bulk mail, and the email specs
already specify the Precedence header though I would have named it differently.

It is risky however to reject untagged mail with just 5-10 recipients since
there are literally millions of "personal" mailing lists with dozens to
hundreds of recipients, that are often sent by ordinary users not using a
mailing list system. Such mail may not be tagged in such cases. We
could start enforcing that tagging restriction more carefully, which would
behoove MUAs and MTAs to notice when a user is doing a mailing to his address
book to announce his new baby, and putting on the Precedence: bulk tag.

Long ago I even proposed the tag should be extended, so that it would get
attributes such as the relationship of recipient to sender
(stranger/known/subscriber/customer) and the number of entries in the mailing.

But spammers of course would not tag. If the government were to make
a law asking the IETF to come up with a tagging system, that's the sort
of one I would propose:

Precedence: junk; relation=stranger; count=50000

Would be how you tag a spam

Precedence: bulk; relation=known; count=150

Would be how you tag a baby announcement

Precedence: bulk; relation=customer; count=10000

Would be how you tag a mailing to customers.

And do on.

[Chuq Von Rospach]

Post by Brad Templeton
Precedence: bulk; relation=customer; count=10000
Would be how you tag a mailing to customers.

the e-marketers would have an issue with disclosing sizes of mailings.
That'd be hard to fly. Besides, what about personalized stuff? Less and
less of the legitimate e-marketing stuff is bulk any more, so a good
argument for count=1 exists, even if it's going out to 10,000
individuals, or 100,000.

[Brad Templeton]

Post by Chuq Von Rospach

Post by Brad Templeton
Precedence: bulk; relation=customer; count=10000
Would be how you tag a mailing to customers.

the e-marketers would have an issue with disclosing sizes of mailings.
That'd be hard to fly. Besides, what about personalized stuff? Less and
less of the legitimate e-marketing stuff is bulk any more, so a good
argument for count=1 exists, even if it's going out to 10,000
individuals, or 100,000.

Sorry, I drafted these plans many years ago so I didn't give a complete
description on them. I actually am not supporting tagging at this time,
simply suggesting that if you are going to do it, these are possible ways
to do it. (What a nice guy I am :-)

My 5 year old essay, which I need to revise because I no longer endorse all
of it is at...

http://www.templetons.com/brad/spume/tag.html

However, the key point is that when I use the term "bulk" in dealing with
spam I normally use it from a human sense, not a technical sense of
"identical messages."

What matters in the definition of bulk is did a human being command a mass
mailing. Even if each message is different in some way, personalized to
the customer, it is still a mass mailing.

It is a more interesting question if, "Ok, sales staff, I want you to all
write personal thank-you letters to all of your customers, and don't cut
and paste text in any of them" is a mass mailing or not. Fortuantely it's
rare enough (and inherently low volume enough) that I am not worried about
including it in definitions.

However, "Have the computer send a mailing to all customers with recommendations
based on their past purchases" is a mass mailing, even though each message
is different. It's not a spam, though, because these are customers.

But "Grab a database from Experian with demographic data on each person, and
customize a message to them based on what is known about them in the databases"
is a mass mailing and it is a spam.

[Chuq Von Rospach]

Post by Brad Templeton
It is a more interesting question if, "Ok, sales staff, I want you to all
write personal thank-you letters to all of your customers, and don't cut
and paste text in any of them" is a mass mailing or not. Fortuantely it's
rare enough (and inherently low volume enough) that I am not worried about
including it in definitions.
However, "Have the computer send a mailing to all customers with recommendations
based on their past purchases" is a mass mailing, even though each message
is different. It's not a spam, though, because these are customers.

Is it? Even if only 20% of the message content is common?

I'm not talking about adding "Dear [[ first name ]] [[ last name ]]" to
the top and calling it personalized; that's really not.

Where this stuff is headed is in that direction, too. from bulk (50,000
pieces of email, all alike -- the e-newsletter model) to mass (50,000
pieces of email, personally addressed but quite similar, sort of like
the e-newsletter with an auto-pen (smirk)), to, well, something. Not
sure what term to give it, but it's 50,000 individual emails that work
from some template but which are customized to the specifics of the
customer.

To throw an analogy to the wolves, the difference is, well, McDonalds
(bulk), Subway (mass), and your local italian restaurant (where
personal email is your home kitchen). It's still turning out volume
cooking, but...

[Brad Templeton]

Post by Chuq Von Rospach
Is it? Even if only 20% of the message content is common?

Yup. When it comes to definitions and rules, computers don't break rules.
Only humans break rules. Computers simply execute commands.

So what matters in all rule making when it comes to definitions for humans is
action by humans. If a human orders 50,000 mails sent, that's a mass mailing.

I personally feel that attempts to fine tune the defintion get pretty murky
after that. You don't want to have to answer questions like a threshold of
difference among the messages, or what percentage of the text was the same
from message to message.

You want to use only objective facts where you can. This particular objective
fact may be one that requires human analysis in some cases, but the goal of
the analysis is an objective fact, not an opinion. As such it's better. I
recommend all definitions try to stay as close to factual judgements as
possible. That's why in past threads I advocated not attempting to judge
the quality of the relationship the recipient has to the sender, just making
a basic judgement of whether the recipient has had voluntary communication in
the past to the sender. He either has or he hasn't, I think.

And, as it turns out, pure volume is something computers can detect, and it
is the root cause of spam. "Did this user send out mail to 50,000 destinations"
is a factual question which, for example, their ISP could answer, or a
pooled MX server for many large sites could answer without ambiguity. Without
having to look at the contents of the message.

[Chuq Von Rospach]

Post by Brad Templeton

Post by Chuq Von Rospach
Is it? Even if only 20% of the message content is common?

Yup. When it comes to definitions and rules, computers don't break rules.
Only humans break rules. Computers simply execute commands.

okay, we'll agree to disagree.

Post by Brad Templeton
after that. You don't want to have to answer questions like a
threshold of
difference among the messages, or what percentage of the text was the same
from message to message.

because it's hard to determine via a program, even if it's important.

Post by Brad Templeton
And, as it turns out, pure volume is something computers can detect, and it
is the root cause of spam.

It's easy to detect, even if it's the wrong thing. I disagree that
volume is the root cause of spam. consent and the issues surrounding it
are. Volume is an issue because spam is easy to send and because the
large amount we're getting creates a high level of frustration -- but
you're focussing on volume because it's easy to count, not because it's
the right measure for the job. IMHO, of course.

There are lots of legitimate large volume mailings out there, and lots
of low volume spam setups, too. Just because someone sends out 10,000
copies of "Jesus tells you to stop the war" doesn't mean it's more
legitimate than 1,000,000 copies of your favorite hair restoration
e-mail....

[Kee Hinckley]

Post by Vernon Schryver

... This is the only hope we have of getting
mailing lists and automated mail systems to work in an environment
with lots of different anti-spam systems. We *really* don't want to
go back to the mess that existed 10-15 years ago with zillions of
different mail systems providing completely different bounce
messages. Been there, done that.

Why wouldn't RFC 2919 and RFC 2369 headers be sufficient?

We were discussing error codes for why a message was rejected and
what to do about. Those are list identification RFCs (which ties in
with another simultaneous discussion--but not this one).

???

[Vernon Schryver]

Post by Kee Hinckley
...

Post by Vernon Schryver
Why wouldn't RFC 2919 and RFC 2369 headers be sufficient?

We were discussing error codes for why a message was rejected and
what to do about. Those are list identification RFCs (which ties in
with another simultaneous discussion--but not this one).
???

Oh, I was confused. I think spending time on bounce formats is a
bigger waste of time than "internationalizing" error messages from
programs. In practice, computer error messages are always opaque
cybercrud to everyone except the priesthood. "ABEND 12345" may be a
bad joke, but not as bad as the jokes that claim to communicate computer
problems to people who are not experts. No matter what you put in
mail rejection messages, 99% of their recipients will have no clue
what is intended. However, I also know that I'm be in the minority
on all variations of this issue. Besides, even I agree that as long
as newly formalized bounces can be implemented, they're no worse than
a minor distraction and might even do a little good.

That leads to the purpose and future of this mailing list and group.

IRTF groups do not appear, deliver a solution in a few weeks, and
disappear. Research is not a short term effort. If it is successful,
this list will endure for years like the end-to-end list, with varyng
relevance and effects. The best that can be hoped is that it will
collect good ideas and support their developement or at least publication,
like ECN in end2end. There will always be other sorts of contributions
like IPv8 advocacy and notes from people who confuse TCP with TP0.

I think the immediate official goals have significantly been met:

- Paul has produced a taxonomy
I'm not sure how important it will be but it was necesary. The
many anti-spam product developers will not use it very precisely.
We are in competition with each other and spammers, and so will
keep some things more or less secret.

- I think communicating consent is hopeless and even a bad idea.
Advertisers will never entirely honor anything but "tell me more."
The only person who can be trusted to honor consent is the end user.
However, there might be something that could be done in a few months.

Other things that should be done include:

- words and definitions for common concepts such as mismatches between
reverse DNS name and envelope sender (Please not "forged")

- common practices such as ways that bulk mail should be identified
for white-listing.

- ideas for SMTP headers indicating filter results.
I've doubts that all of the many mail filter/markers can agree, but
maybe something is possible.

- improved mechanisms for opting-out of spam.

- provide a focus for IETF/IRTF attention to spam.

A problem is tha some of the work this list might do might belong in
one of the IETF WGs.


Vernon Schryver ***@rhyolite.com

[Kee Hinckley]

Post by Vernon Schryver
Oh, I was confused. I think spending time on bounce formats is a
bigger waste of time than "internationalizing" error messages from
programs. In practice, computer error messages are always opaque
cybercrud to everyone except the priesthood. "ABEND 12345" may be a

I would take this as a *reason* to standardize them. Given that they
are getting even more confusing. The point isn't to standardize them
for humans--but for computers.

[Chuq Von Rospach]

Post by Kee Hinckley
I would take this as a *reason* to standardize them. Given that they
are getting even more confusing. The point isn't to standardize them
for humans--but for computers.

Exactly. The system I built, though, is getting ~99.6% accuracy in
auto-processing now, so it can be done with a few hacks. What's left is
mostly places that are going out of their way to try to "help" (Adobe
and LLNL both have very helpful 'they aren't here any more' messages
that are useless for auto-processing) and people building their own
scripts badly, and a couple of systems like First Class (grr) that
still seem to think the entire e-mail universe is a local network
running phonenet or something. First Class is probably half of my
un-automated bounces, but I'm working on figuring out ways to outsmart
their stupid mailer short of unsubscribing entire domains in disgust
(since First Class also tends to bounce stuff to the sender, not the
envelope, and we've talked to Centrinity about it and they don't see
this as a problem, when one of them pops up on our list server sites,
that domain DOES get blacklisted until it gets fixed, preferably with
real server software...)

[Vernon Schryver]

Post by Kee Hinckley

Post by Vernon Schryver
Oh, I was confused. I think spending time on bounce formats is a
bigger waste of time than "internationalizing" error messages from
programs. In practice, computer error messages are always opaque
cybercrud to everyone except the priesthood. "ABEND 12345" may be a

I would take this as a *reason* to standardize them. Given that they
are getting even more confusing. The point isn't to standardize them
for humans--but for computers.

I think standardized error messages for computers has worse problems.
Consider the example of SMTP response coes. There are only 3 results
answers that computers can deal with, "it worked," "it failed but
might work if you try again later," and "it failed--go away." In
practice the other literally millions of status codes and extended
status values are wasted bandwidth for humans and computers.

Maybe I'm wrong and you can make something more, such as a super 5yz
that says "not only forget this message and this target address, but
never again send a SYN to this IP address or any related TLD."


Vernon Schryver ***@rhyolite.com

[Chuq Von Rospach]

Post by Vernon Schryver
I think standardized error messages for computers has worse problems.
Consider the example of SMTP response coes. There are only 3 results
answers that computers can deal with, "it worked," "it failed but
might work if you try again later," and "it failed--go away." In
practice the other literally millions of status codes and extended
status values are wasted bandwidth for humans and computers.

Not true.

for humans, it's very useful. At least in theory, they can get on the
phone or send e-mail to a site to say "do you know that your mail is
returning with xxxxx" -- and some of us still, in fact, do that when we
can.

for computers, it's less useful but not useless. If anything, I'd like
to see the standardization for "hard bounce", "soft bounce",
"processing bounce" to be improved, because we do try to read the tea
leaves and handle soft bounces (over quota, for instance) differently
than hard bounces (user unknown), because a soft bounce implies mail
might stop bouncing sometime in the future, while hard bounce implies
game over (even though we find hard bounces to actually be soft, and
soft bounces to actually be hard). And anything that's a "processing
bounce" (disk full, as opposed to over quota, although many sites
misrepresent these) ought to be considered very temporary, so they
ought to be a third category, but for practicality, should be
considered at least soft bounces. And yes, there are different
processing regimens for soft and hard bounces, so it matters...

[Kee Hinckley]

Post by Vernon Schryver
I think standardized error messages for computers has worse problems.
Consider the example of SMTP response coes. There are only 3 results
answers that computers can deal with, "it worked," "it failed but
might work if you try again later," and "it failed--go away." In
practice the other literally millions of status codes and extended
status values are wasted bandwidth for humans and computers.

The point of extending status codes would not be to give the MTA more
options--but to allow it to return something intelligent to the MUA.
A large number of the proposals we have seen have weird return values
like:
- insufficient cpu - run this java applet
- insufficient funds - go to the bank
- blocked due to naughty word - send here to bypass
- blocked due to rogue RBL - click here to complain
- blocked due to lack of intelligence - prove you are a human
and so on.

As you may have gathered from my examples, I'm not fond of these
ideas. Nonetheless, they exist now, and they are growing.

If these systems are going to interoperate with existing transports,
they need to provide some kind of response which the transport can
pass back to the human or back to an MTA or MUA which actually does
understand them.

I think we run the risk of having hundreds of systems all using
different mechanisms. So the question is....

Can we specify a standard MTA response format which will let us
modify MTAs *once*, regardless of the particular scheme the recipient
(and possibly sender) are using? Bonus points if we can degrade
gracefully for non-enhanced MTAs (e.g. specify a standard format for
the text portion that goes along with an existing numeric response).

Like my proposal for a new whitelisting scheme, I'm proposing this
not because I like the systems people are implementing--but because I
don't want to live in a world where everyone implements incompatible
solutions.

[Tony Finch]

Post by Kee Hinckley

Post by Vernon Schryver
Oh, I was confused. I think spending time on bounce formats is a
bigger waste of time than "internationalizing" error messages from
programs. In practice, computer error messages are always opaque
cybercrud to everyone except the priesthood. "ABEND 12345" may be a

I would take this as a *reason* to standardize them. Given that they
are getting even more confusing. The point isn't to standardize them
for humans--but for computers.

What's wrong with these?

3461 Simple Mail Transfer Protocol (SMTP) Service Extension for
Delivery Status Notifications (DSNs). K. Moore. January 2003.
(Format: TXT=76076 bytes) (Obsoletes RFC1891) (Status: DRAFT
STANDARD)

3462 The Multipart/Report Content Type for the Reporting of Mail
System Administrative Messages. G. Vaudreuil. January 2003. (Format:
TXT=12186 bytes) (Obsoletes RFC1892) (Status: DRAFT STANDARD)

3463 Enhanced Mail System Status Codes. G. Vaudreuil. January 2003.
(Format: TXT=31832 bytes) (Obsoletes RFC1893) (Status: DRAFT
STANDARD)

3464 An Extensible Message Format for Delivery Status Notifications.
K. Moore, G. Vaudreuil. January 2003. (Format: TXT=83060 bytes)
(Obsoletes RFC1894) (Status: DRAFT STANDARD)

Tony.

[Kee Hinckley]

Post by Tony Finch

Post by Kee Hinckley

Post by Vernon Schryver
Oh, I was confused. I think spending time on bounce formats is a
bigger waste of time than "internationalizing" error messages from
programs. In practice, computer error messages are always opaque
cybercrud to everyone except the priesthood. "ABEND 12345" may be a

I would take this as a *reason* to standardize them. Given that they
are getting even more confusing. The point isn't to standardize them
for humans--but for computers.

What's wrong with these?

Bear in mind that I've just gone and skimmed these. So if I've
misrepresented one, let me knomw.

Post by Tony Finch
3461 Simple Mail Transfer Protocol (SMTP) Service Extension for
Delivery Status Notifications (DSNs). K. Moore. January 2003.
(Format: TXT=76076 bytes) (Obsoletes RFC1891) (Status: DRAFT
STANDARD)

This requires that the sending MTA request extended result codes
which makes widespread deployment more difficult.

Post by Tony Finch
3463 Enhanced Mail System Status Codes. G. Vaudreuil. January 2003.
(Format: TXT=31832 bytes) (Obsoletes RFC1893) (Status: DRAFT
STANDARD)

Right idea, but the semantics we are looking for aren't covered
there, and I think they are complex enough that we're going to have
to specify standard contents for the text part of the response as
well as the numeric code.

Post by Tony Finch
3464 An Extensible Message Format for Delivery Status Notifications.
K. Moore, G. Vaudreuil. January 2003. (Format: TXT=83060 bytes)
(Obsoletes RFC1894) (Status: DRAFT STANDARD)

This looks like a good base for the replies. What we need to do is
standardize on a set of headers that fit within the framework.

[Jon Kyme]

Post by Vernon Schryver
- I think communicating consent is hopeless and even a bad idea.
Advertisers will never entirely honor anything but "tell me more."
The only person who can be trusted to honor consent is the end user.
However, there might be something that could be done in a few months.

Oh. That's that then. No, hang on, I can think of a number of entities who
might *consult* my consent - including (in a particular order):

My organisation, my ISP, a legitimate mass mailer, the courts.

And why (I know I shouldn't bite) a "bad idea"?

There's probably too much in the way of "voice from the mount"
assertions on this list.





--

[Chuq Von Rospach]

Post by Jon Kyme

Post by Vernon Schryver
- I think communicating consent is hopeless and even a bad idea.
Advertisers will never entirely honor anything but "tell me more."

This is bogus. It's like saying because there are hackers out there,
all programmers can't be trusted. Let's use an even wider brush for the
painting, and simply go for the entire human race in one swath.

Smart advertisers have figured out that stuffing messages down user's
throats when they don't want them makes them a lot more likely to buy
your products (yeah, right).

Please don't assume that since some sites (like real) are deceptive in
how they do their consent management and others are outright frauds
that everyone's like that. that simply polarizes a discussion into
camps that fight when cooperation is in fact needed.

Post by Jon Kyme
There's probably too much in the way of "voice from the mount"
assertions on this list.

"She is a witch! May we burn her?"

[Vernon Schryver]

Post by Chuq Von Rospach

Post by Vernon Schryver
- I think communicating consent is hopeless and even a bad idea.
Advertisers will never entirely honor anything but "tell me more."

This is bogus. It's like saying because there are hackers out there,
all programmers can't be trusted. Let's use an even wider brush for the
painting, and simply go for the entire human race in one swath.
Smart advertisers have figured out that stuffing messages down user's
throats when they don't want them makes them a lot more likely to buy
your products (yeah, right).
Please don't assume that since some sites (like real) are deceptive in
how they do their consent management and others are outright frauds
that everyone's like that. that simply polarizes a discussion into
camps that fight when cooperation is in fact needed.

Have you ever worked with or otherwise encountered a marketing
organization that will never have an enthusiastic member who will dig
out the old lists to see if any contacts might have changed their
minds? I've know several marketing organizations up close, including
at very strongly anti-Internet-abuse over the decades, but they've
all had similar problems.

Have you heard of any marketing organization of more than ~50 people
or for a company of more than 1000 employees that has not had and will
not always have occassional spam problems? I've not. The difference
between hopelessly enthusiastic spammers like RealNetworks and the
rest of the Fortune 100,000 is in a matter of degree.

In fact no prgrammers can be entirely trusted because some of us are
bad guys. That is why we have all sorts of access control mechanisms.
I think that any non-trivial "consent mechanisms" would be like root
accounts without passwords, sendmail "debug" switches, and gets() or
sprintf() functions.


Vernon Schryver ***@rhyolite.com

[Jon Kyme]

Post by Vernon Schryver
- I think communicating consent is hopeless and even a bad idea.
Advertisers will never entirely honor anything but "tell me more."

Ooh - please sort out your ascribing - it was V.S. said that.
Thank you.





--

[Vernon Schryver]

Post by Jon Kyme

Post by Vernon Schryver
- I think communicating consent is hopeless and even a bad idea.
Advertisers will never entirely honor anything but "tell me more."
The only person who can be trusted to honor consent is the end user.

My organisation, my ISP, a legitimate mass mailer, the courts.

The needs of the courts to determine your consent have nothing to do
with network protocols, the IETF, or the IRTF. That extreme case
illustrates some problems with the other cases.

Post by Jon Kyme
And why (I know I shouldn't bite) a "bad idea"?

It's a bad idea because saying "ok, you're ok but no thanks" will get
you more spam. Any expression sent to almost any mass mailer, no
matter how legitimate, is likely to be "checked," as in "6 months
(weeks, days, or hours) ago you said you didn't want to hear everything
from us. surely you've changed your mind?"


Vernon Schryver ***@rhyolite.com

[Jon Kyme]

VS>> > - I think communicating consent is hopeless and even a bad idea.

Post by Vernon Schryver

Post by Jon Kyme

Post by Vernon Schryver
Advertisers will never entirely honor anything but "tell me more."
The only person who can be trusted to honor consent is the end user.

My organisation, my ISP, a legitimate mass mailer, the courts.

VS>The needs of the courts to determine your consent have nothing to do

Post by Vernon Schryver
with network protocols, the IETF, or the IRTF. That extreme case
illustrates some problems with the other cases.

Sorry, what? Again the non sequitur. You imply consent expression is
useless.
I point out 4 examples of entities who might consult it. The needs of *any*
entity to consult consent are *clearly* a consideration in the formulation
of a consent expression framework (be it expressed through a network
protocol,
proposed through the IETF, the IRTF or written on a matchbook).

Post by Vernon Schryver

Post by Jon Kyme
And why (I know I shouldn't bite) a "bad idea"?

It's a bad idea because saying "ok, you're ok but no thanks" will get
you more spam. Any expression sent to almost any mass mailer, no
matter how legitimate, is likely to be "checked," as in "6 months
(weeks, days, or hours) ago you said you didn't want to hear everything
from us. surely you've changed your mind?"

Yes maybe - so they consult your consent again.
Is there some problem with this?

I can only assume that you see problems (unspecified) with some
particular mechanism (unspecified) of consent expression - and then
make the logical false step which leads you to conclude that
consent expression in general must have those flaws.

This is bad reasoning, and makes for bad argument.






--

[w***@waltdnes.org]

On Thu, Mar 27, 2003 at 09:07:13AM +0000, Jon Kyme wrote

[ ...Vernon said... ]

Post by Jon Kyme

Post by Vernon Schryver
It's a bad idea because saying "ok, you're ok but no thanks" will get
you more spam. Any expression sent to almost any mass mailer, no
matter how legitimate, is likely to be "checked," as in "6 months
(weeks, days, or hours) ago you said you didn't want to hear everything
from us. surely you've changed your mind?"

[ ...Jon said... ]

Post by Jon Kyme
Yes maybe - so they consult your consent again.
Is there some problem with this?

Yes. It doesn't scale. Imagine several million businesses on this
planet "just checking" with you every six months. I don't really see
any difference between my inbox overflowing with a thousand spams per
day or a thousand "requests-for-you-to-please-opt-in,-pretty-please".

To summarize... I'd love to see a truly working "Global opt-out list"
where I could say "No" once, and be done with bulk solicitions until
such time as I log in and change my prefs. What I do *NOT* want is a
system where I have to say "No, no, a thousand times no" every day.
Even a system that generates 1000 requests per day that you can ignore
is still mailbombing.

[J C Lawrence]

On Sat, 29 Mar 2003 00:08:25 -0500

Post by w***@waltdnes.org
To summarize... I'd love to see a truly working "Global opt-out list"
where I could say "No" once, and be done with bulk solicitions until
such time as I log in and change my prefs. What I do *NOT* want is a
system where I have to say "No, no, a thousand times no" every day.
Even a system that generates 1000 requests per day that you can ignore
is still mailbombing.

I'm uncomfortable with global-queryable state for me in almost any
regard. Too reminiscent of a slippery slope. I'd much rather see
something at the MX level which can be queried, with the MX config
optionally storing state or forwarding the query on to the MUA/LDA
(ie an asynchronous query).

[Jon Kyme]

Post by w***@waltdnes.org
[ ...Jon said... ]

Post by Jon Kyme
Yes maybe - so they consult your consent again.
Is there some problem with this?

VS> Yes. It doesn't scale. Imagine several million businesses on this
VS> planet "just checking" with you every six months. I don't really see
VS> any difference between my inbox overflowing with a thousand spams per
VS> day or a thousand "requests-for-you-to-please-opt-in,-pretty-please".

No - of course it doesn't scale.
Who said that your consent can only be consulted by sending an email?

Clearly - another mechanism for expressing and consulting consent is
desirable.






--

[Jon Kyme]

Post by w***@waltdnes.org
[ ...Jon said... ]

Post by Jon Kyme
Yes maybe - so they consult your consent again.
Is there some problem with this?

Yes. It doesn't scale. Imagine several million businesses on this
planet "just checking" with you every six months. I don't really see
any difference between my inbox overflowing with a thousand spams per
day or a thousand "requests-for-you-to-please-opt-in,-pretty-please".

No - of course it doesn't scale.
Who said that your consent can only be consulted by sending an email?

Clearly - another mechanism for expressing and consulting consent is
desirable.






--

[Jon Kyme]

Post by w***@waltdnes.org
[ ...Jon said... ]

Post by Jon Kyme
Yes maybe - so they consult your consent again.
Is there some problem with this?

VS> Yes. It doesn't scale. Imagine several million businesses on this
VS> planet "just checking" with you every six months. I don't really see
VS> any difference between my inbox overflowing with a thousand spams per
VS> day or a thousand "requests-for-you-to-please-opt-in,-pretty-please".

No - of course it doesn't scale.
Who said that your consent can only be consulted by sending an email?

Clearly - another mechanism for expressing and consulting consent is
desirable.






--

[Hallam-Baker, Phillip]

This is why I like the definition of what we want to eliminate to be
'unwanted messages that are sent indiscriminately'.

The weasel word here being indiscriminately, there are a few messages that
could be sent indiscriminately that could be mostly wanted. For example on
9/11 someone could have sent a broadcast to all RIM pagers in the US with
emergency information, I doubt it would have been unwanted in many cases.

The word indiscriminate is of course subjective, just like the term spam.
However a salesperson that sends messages to 10,000 existing customers can
hardly be considered indiscriminate, nor is a salesperson who sends
targetted messages to 100 sales prospects, nor is a message with a CFP for
an anti-spam conference sent to this list.

However sending the message to every IETF list, or to 10,000 sales prospects
etc. is indiscriminate.

Phill

[Chuq Von Rospach]

Post by Hallam-Baker, Phillip
The word indiscriminate is of course subjective, just like the term spam.
However a salesperson that sends messages to 10,000 existing customers can
hardly be considered indiscriminate, nor is a salesperson who sends
targetted messages to 100 sales prospects, nor is a message with a CFP for
an anti-spam conference sent to this list.

but I tend to go further: you can be discriminate here, but still not
have consent.

This is a rewrite of something I just sent to Brad privately that might
illuminate what I mean. To preface it, I'll note I think people abuse
the word spam horribly, to the point where it almost has no meaning any
more, so any attempt to "stop spam" is going to fail because nobody can
agree how to define it.

going down the rabbit hole of defining this stuff, I make a hard
delineation between:

1) spam, which in my mind are those idiots that send stuff fraudulently
with forged return addresses and all that other stuff.

2) legitimate marketing stuff, where the real issue is a consent issue,
not a fraud issue.

for (1), the root cause is the easy ability to forge spam and the
difficulty of stopping people. Since I see this kind of crap as 90% of
the overall problem (or more), finding ways to lock them out of the
universe is my top priority.

2) where you have real companies doing stupid things, gets lumped in
with 1, but is really a different problem, and has nothing to do with
cheap costs or whatever. It has to do with marketing people who ought
to be kneecapped for being more worried about how many messages got
sent and not about how many sales were generated...

In both cases, volume is an accelerator to the process, not a cause.

I think the issues of "solving spam" and "dealing with e-marketing
consent issues" are skew. One is shutting down fraudulent operations,
the other is regulating legitimate businesses who's practices might or
might not be up to snuff. But they tend to get lumped together, and
that adds complexity to the the problem and confuses the issues, and we
end up going round and round and accomplishing nothing.

They're separate issues, needing separate solutions. I realize there's
a segment that thinks all e-marketing is by definition spam, but the
moderate position understands it's not. And no, I'm not excusing badly
build e-marketing systems, not at all. but the amount of hassle they
cause is nothing compared to the spam that's fraudulently stuffed down
out throats every day. And the solutions are different.

but IMHO, you could fix every freaking e-marketer to have perfect
systems with perfect consent that updates based on telepathy two days
before the end-user thinks of unsubscribing -- and the typical user
wouldn't notice because of all the noise and pain caused by the fraud
spammers. Worse, the e-marketing stuff keeps getting dumped onto the
same bonfire by the "burn witches! more witches!" crowd, which
basically derails the process from allowing anyone to focus on solving
the first, major problem.

I'd like to suggest that we focus on the first, big problem: the group
of mass mailers that are overtly avoiding allowing users to define
consent through various fraudulent means. Until that issue is solved,
nothing else matters. If folks want to start a sub-group to hash out
issues of consent and try to work with the legitimate e-mailers to
build a standard, great, but even if that gets resolved to everyone's
satisfaction, it won't matter if we all wake up to 45 messages every
morning with pretty pictures of zebras in them.

I keep thinking this group sidetracks itself by being unable to really
define the problems it's trying to solve (instead, looking for *a*
problem and defining *a* solution), and not setting priorities among
them. In all honesty, if we could cut those 45 messages with zebras to
20 messages with little bluu pills, this group would still be
considered massive heroes, but there doesn't seem to be any interest or
motivation towards fixing a chunk of the problem, and instead we turn
around and chase our tails.

Don't think for a second I think this group's been useless, by the way.
There are lots of useful things being done and lots of good mixing and
sharing and considering. But I'm not seeing it moved to the next step,
and the group itself seems to be somewhat passive about moving itself.
And I think that's why the frustration level on the group is building,
because we're tail chasing now, and nobody's defined which rabbit gets
chased first...

And the reality is, there are a lot of rabbits and a lot of holes, and
we need to be careful lest we step in a hole and break our ankle -- but
right now, I feel like we're sitting in the kennel chasing each other.

[w***@waltdnes.org]

Post by Chuq Von Rospach
going down the rabbit hole of defining this stuff, I make a hard
1) spam, which in my mind are those idiots that send stuff fraudulently
with forged return addresses and all that other stuff.
2) legitimate marketing stuff, where the real issue is a consent issue,
not a fraud issue.

I don't consent to 1) and I don't consent to 2). I do not see any
difference.

Post by Chuq Von Rospach
I think the issues of "solving spam" and "dealing with e-marketing
consent issues" are skew. One is shutting down fraudulent operations,
the other is regulating legitimate businesses who's practices might or
might not be up to snuff. But they tend to get lumped together,

Waddles like a duck, quacks like a duck, flies like a duck, it *IS* a
duck. A pearl of wisdom from "The Rules of Spam"...
Sharp's Corollary: Spammers attempt to re-define "spamming" as that
which they do not do.

Post by Chuq Von Rospach
They're separate issues, needing separate solutions. I realize there's
a segment that thinks all e-marketing is by definition spam, but the
moderate position understands it's not. And no, I'm not excusing badly
build e-marketing systems, not at all. but the amount of hassle they
cause is nothing compared to the spam that's fraudulently stuffed down
out throats every day. And the solutions are different.

The *ONLY* difference is that the people behind "legitimate marketing
stuff" make campaign contributions, and there's less liklihood of the
"legitimate" spam advertising stuff that's blatantly illegal. Folks,
it's about *CONSENT* not *CONTENT*.

Post by Chuq Von Rospach
Worse, the e-marketing stuff keeps getting dumped onto the same
bonfire by the "burn witches! more witches!" crowd, which basically
derails the process from allowing anyone to focus on solving the
first, major problem.

It's *ALL* non-consensual e-marketing. Whether it's a guy in a suit
or a guy in sleazy spamhaus makes no difference. Fraud-artists at Enron
are really no different from a career criminal kiting cheques.

[p***@gammon.com]

Post by w***@waltdnes.org
I don't consent to 1) and I don't consent to 2). I do not see any
difference.

Ah, but some people *do* consent to 2), and they would like to receive
the weekly cheez-wiz recipes that they've otped into.

Post by w***@waltdnes.org
The *ONLY* difference is that the people behind "legitimate marketing
stuff" make campaign contributions, and there's less liklihood of the
"legitimate" spam advertising stuff that's blatantly illegal. Folks,
it's about *CONSENT* not *CONTENT*.

False. The difference is that legitimate email marketers try pretty
hard to only send mail to people who want to receive it. Just because
you don't want to know what's on sale over at piggly wiggly doesn't
mean that I don't. In fact, I subscribe to somewhere between one and
two dozen separate email marketing streams right now.

Legitimate honest-to-goodness email marketers exist, and while they aren't
always perfect, they can do a pretty damned good job. I can count on
one hand the number of unsolicited messages I've received from Digital
Impact in the last few years, for example, and I never got a single
piece from my former employer. That's not just because I worked there...
none of their clients ever brought in a dirty list that I was on.
I consider that quite remarkable, since my various email addresses have
been well-publicized over the years.

An opt-in email marketer who tries very hard never to send unsolicited
email, and who responds promptly and correctly if there is an
occasional screw-up, is not a spammer.


I will grant you, however, that there's a decent-sized grey area in
between hot-teen-lolitas spammers and the best of the bunch.

-Patti

[Brad Templeton]

Post by w***@waltdnes.org
The *ONLY* difference is that the people behind "legitimate marketing
stuff" make campaign contributions, and there's less liklihood of the
"legitimate" spam advertising stuff that's blatantly illegal. Folks,
it's about *CONSENT* not *CONTENT*.

This phrase may be the crux of one large division in the anti-spam
community.

There are a number of people who do believe it's about consent. If
they simply meant "explicit consent", it would be something which could
be the subject of debate, but unfortunately when I have seen this used
it is always about a fairly unspecified sort of implicit consent, whose
definition varies from person to person.

Now, that alone would be reason to avoid trying to work in terms of
consent, but there is a much greater fundamental flaw with this concept.

One which will shock some anti-spam folks at first.

In free societies, you don't need advance consent to communicate with
somebody else. Consent can be rescinded, as in "go away" but it is always
on by default.

And since, on the internet, there is _no_ communication without use of the
private property of the other party to the communication, it means you don't
need advance consent to use somebody else's property to communicate with
them. We have declared many times we don't have a right to be annoyed, only
a right not be harassed.

To define communication without advance consent as some sort of offence
would turn our definitions of a free society and an open communications system
upside-down. If somebody gave you a URL, you could not click on it without
knowing if the web host consented to you clicking on it. If you got a referral
where I told you to e-mail my friend, you could not mail him for fear you did
not have his consent. And If I want to mail you to flame you about how stupid
the opinion you posted on your web site is, well, who would suspect you give
your consent to be flamed?

In our society you can, by default, go up to somebody on the street and
talk to them. That is sometimes annoying, but it's a right we actually
fight hard to protect. You can send them postal mail, without their consent.
It is always assumed to exist in advance. It can be rescinded -- through
restraining orders, harassment charges, blockages at the post office etc. but
it is always on by default. People can even come onto your private land to
come to talk to you unless you explicitly mark it no trespassing.

So because consent would be incredibly difficult to define, and it's a bad idea
to bring it into the spam definition, I respectfully submit that other
courses should be followed.

[Chuq Von Rospach]

mark me down for agreeing with every word Brad says here...

On Saturday, March 29, 2003, at 08:33 PM, Brad Templeton wrote:

[Jon Kyme]

Post by Brad Templeton
In free societies, you don't need advance consent to communicate with
somebody else. Consent can be rescinded, as in "go away" but it is always
on by default.

Arrgh - freedom of speech! interesting field - look out for cowpats.

You may not need advance consent to attempt to initiate a communication.

A: "Knock, knock..."

But for the communication to proceed consent is required...

B: "Go away"

Post by Brad Templeton
And since, on the internet, there is _no_ communication without use of the
private property of the other party to the communication, it means you don't
need advance consent to use somebody else's property to communicate with
them. We have declared many times we don't have a right to be annoyed,
only
a right not be harassed.

That's a non sequitur. You might just as easily turn it around: Because you
don't have a right to
use someones private property without their consent, you don't have a right
to communicate with them.

I can't believe that there's anywhere where my right to "free speech" gives
me the right to stage a political demonstration in your kitchen.

This is not a profitable line of argument.

Post by Brad Templeton
To define communication without advance consent as some sort of offence
would turn our definitions of a free society and an open communications system
upside-down. If somebody gave you a URL, you could not click on it without
knowing if the web host consented to you clicking on it. If you got a
referral
where I told you to e-mail my friend, you could not mail him for fear you did
not have his consent. And If I want to mail you to flame you about how
stupid
the opinion you posted on your web site is, well, who would suspect you give
your consent to be flamed?
In our society you can, by default, go up to somebody on the street and
talk to them. That is sometimes annoying, but it's a right we actually
fight hard to protect. You can send them postal mail, without their
consent.
It is always assumed to exist in advance. It can be rescinded -- through
restraining orders, harassment charges, blockages at the post office etc. but
it is always on by default. People can even come onto your private land to
come to talk to you unless you explicitly mark it no trespassing.
So because consent would be incredibly difficult to define, and it's a bad idea
to bring it into the spam definition, I respectfully submit that other
courses should be followed.
_______________________________________________
Asrg mailing list
https://www1.ietf.org/mailman/listinfo/asrg

--

[wayne]

There are a number of people who do believe it's about consent. [... ]
In free societies, you don't need advance consent to communicate with
somebody else. Consent can be rescinded, as in "go away" but it is always
on by default.

I don't know many people who define spam as mearly "unsolicited
email". They usually add things like "bulk" or "commercial" to the
requirements.

In our society you can, by default, go up to somebody on the street and
talk to them. That is sometimes annoying, but it's a right we actually
fight hard to protect.

There are restrictions on how you can "talk" to people. You can't
talk in an intimidating way. You can't use a megaphone. Political
speech has far more protections than commercial speech. You can't
yell "fire" in a crowded theater.

The nature of email is that it is extremely cheap to send. In order
to preserve the usefulness of email, people can only receive a certain
number of emails per day and that means there has to be some
prioritizing.

Even if there is a legal right to send UBE and/or UCE, people are
still going to try hard to filter it out. They have to. There are
just so many minutes in the day.


-wayne

[Kee Hinckley]

Post by Brad Templeton
So because consent would be incredibly difficult to define, and it's a bad idea
to bring it into the spam definition, I respectfully submit that other
courses should be followed.

I think it follows from this argument that the appropriate definition
of spam is very simple. Harassment. That's why I asked a while
back on this list whether harassment law and restraining orders (both
of which are based to a certain degree on the perceptions of the
recipient) might not be the best model.

[matthew richards]

sounds like a good place to start (harassment law and restraining
orders) but keep in mind that this type of legislation has been
abused- it's very easy to accuse someone of harassment, even if they
are innocent. what it amounts to is social blacklisting and i'd hate
to see something like that happen to email. i favor a more passive
approach, control can be a good thing but wouldn't it be better if
there was a way to eliminate the possibility of a harassment
situation to begin with?

harassment:
To irritate or torment persistently.
To wear out; exhaust.
To impede and exhaust (an enemy) by repeated attacks or raids.

haha! if that isn't spam then i don't know what is! good call Kee.

Post by Kee Hinckley

Post by Brad Templeton
So because consent would be incredibly difficult to define, and it's a bad idea
to bring it into the spam definition, I respectfully submit that other
courses should be followed.

I think it follows from this argument that the appropriate
definition of spam is very simple. Harassment. That's why I asked
a while back on this list whether harassment law and restraining
orders (both of which are based to a certain degree on the
perceptions of the recipient) might not be the best model.
--
Kee Hinckley
http://www.messagefire.com/ Junk-Free Email Filtering
http://commons.somewhere.com/buzz/ Writings on Technology and Society
I'm not sure which upsets me more: that people are so unwilling to accept
responsibility for their own actions, or that they are so eager to regulate
everyone else's.
_______________________________________________
Asrg mailing list
https://www1.ietf.org/mailman/listinfo/asrg

[Vernon Schryver]

Post by Kee Hinckley
I think it follows from this argument that the appropriate definition
of spam is very simple. Harassment. That's why I asked a while
back on this list whether harassment law and restraining orders (both
of which are based to a certain degree on the perceptions of the
recipient) might not be the best model.

Doesn't harassment require some sort of repetition and some kind of
obnoxiousness, threat, or other objectionable quality?
http://www.m-w.com/cgi-bin/dictionary?va=harassment says
it means "to annoy persistently."
http://www.safetyed.org/help/stalking/stalkusa.html and the rest of
http://www.google.com/search?q=harassment+legal
seem to suggest some notion of repetition is involved.

Would one polite, short, unsolicited bulk email message every 6 months
be seen as harassment by a court or other sane authority?--I doubt it.

How many individuals and organizations in the world might reasonably
send you an annual reminder of their existence and request for
permission to send more mail? How many bulk unsolicited non-harresmment
email messages would you like in your mailbox daily?

It is counter-productive to take with interesting connotations and
then pretend that their definitions are whatever is convenient. This
is as true of calling the use of surprising mail return addresses
"forgery" as would be of squeezing "spam" into a "harrassment" box.


Vernon Schryver ***@rhyolite.com

[Kee Hinckley]

Post by Vernon Schryver
Would one polite, short, unsolicited bulk email message every 6 months
be seen as harassment by a court or other sane authority?--I doubt it.

Point taken. The harassment solution might work well against bulk
spammers. But it doesn't solve the opt-in vs. opt-out problem.
However... it might be a better tool for going after spammers than
the $500/spam solutions. Maybe.

[matthew richards]

if spammers were only spamming once very six months i doubt the ASRG
would exist, i doubt the term SPAM would exist.

Post by Kee Hinckley

Post by Vernon Schryver
Would one polite, short, unsolicited bulk email message every 6 months
be seen as harassment by a court or other sane authority?--I doubt it.

Point taken. The harassment solution might work well against bulk
spammers. But it doesn't solve the opt-in vs. opt-out problem.
However... it might be a better tool for going after spammers than
the $500/spam solutions. Maybe.
--
Kee Hinckley
http://www.messagefire.com/ Junk-Free Email Filtering
http://commons.somewhere.com/buzz/ Writings on Technology and Society
I'm not sure which upsets me more: that people are so unwilling to accept
responsibility for their own actions, or that they are so eager to regulate
everyone else's.
_______________________________________________
Asrg mailing list
https://www1.ietf.org/mailman/listinfo/asrg

[Kee Hinckley]

Post by matthew richards
if spammers were only spamming once very six months i doubt the ASRG
would exist, i doubt the term SPAM would exist.

The point was that we need to be careful not to solve one problem and
create another. In particular, we don't want to legitimize sending
unsolicited bulk email, even if it isn't done frequently. Right now
we're being nailed by a large number of messages from a few people.
The opposite situation is actually far harder to control. And
legitimizing unsolicited bulk mail (with or without opt-out) could
easily create it.

Or to put it in a slightly more flip way. It's possible that the
fact that spammers make legitimate bulk email senders look bad is a
good thing. The only thing holding them back is that they'd get
grouped with the slime.

[Brad Spencer]

Or to put it in a slightly more flip way. It's possible that the fact
that spammers make legitimate bulk email senders look bad is a good
thing. The only thing holding them back is that they'd get grouped with
the slime.

I agree. The DMA-types still believe in the legitimacy of first-contact
email. They probably want to restrict that to targeted lists rather than
the spam-everyone approach of the current abusive spammers (and claim that
"targeted" first-contact email isn't spam - they'll gladly remove the
unwilling from THAT list.) The DMA-type spam is, ultimately, the bigger
threat, and legitimatizing it is greatly to be avoided.

It is still very worthwhile to end the abusive spam. Stopping the DMA-type
spam is a more complex problem - they surely have legislators convinced
that they are innovative ethical businesspeople.

[Troy Rollo]

Post by Brad Templeton
In free societies, you don't need advance consent to communicate with
somebody else. Consent can be rescinded, as in "go away" but it is always
on by default.

This is not entirely accurate. In common law jurisdictions, no amount of
consent or withdrawal of consent can affect the right to communicate per
se. If you are in public, somebody can yell at you all they like, subject
to any statutes to the contrary (such as statutes establishing public order
offences), and you can't do anything about it. On the other hand, if you
are on your own land, and somebody is yelling at you in such a way that it
interferes with your use of the land (complications arise here), then the
person doing the yelling commits a nuisance, and if they refuse to stop you
are legally entitled to slap them around until they do stop (of course I
wouldn't recommend this approach because in an individual case you may be
mistaken about the extent of their act and the extent of your right to abate).

Post by Brad Templeton
And since, on the internet, there is _no_ communication without use of the
private property of the other party to the communication, it means you don't
need advance consent to use somebody else's property to communicate with
them.

Now here you come closer - when you use the private property of another you
do need consent to use the property, but the consent is implied in the
cases you appear to be worried about. Elsewhere, YMMV, for example in
Scotland there appears to be no requirement for consent to merely use
another person's chattels.

Post by Brad Templeton
To define communication without advance consent as some sort of offence
would turn our definitions of a free society and an open communications system
upside-down.

Well yes, if you mean "all communication", but it's not an "all or nothing"
rule. Implied consent as understood by the law deals very well with this.
To determine what is covered by implied consent you look at:

a. What is necessary for the function of society in
the circumstances;
b. What is accepted by society; and
c. What can reasonably be inferred by the actions of
the possessor of the property.

These are not necessarily exclusive factors. There may be other relevant
factors in individual cases, but these factors cover most everyday
situations, and the factors in individual cases will often be referable
back to one or more of these. For example, in the case of email, the fact
that SMTP as a protocol demonstrates a design centred on person to person
messages and another protocol (NNTP) demonstrates a design centred on
broadcast messages (even having substantially the same message format)
would be a relevant factor for determining what is necessary, and what can
be inferred.

For example, having an open shop front entails implied consent to enter for
the purpose of shopping, but if you enter for the purpose of shoplifting,
you enter as a trespasser. If you enter for the purpose of soliciting
customers to your nearby competing shop, you also enter as a trespasser.
The implied consent is not an unbounded consent to enter, but is a consent
limited to the purpose that is in that case necessary, accepted, and
reasonably inferred.

In the case of a private residence, there is implied consent to enter via a
marked path to knock on the front door, but if you enter for the purposes
of breaking in, or if the path goes past the main bedroom window and you
enter for the purpose of peeping, then you trespass as soon as you set foot
on the private land.

Post by Brad Templeton
If somebody gave you a URL, you could not click on it without
knowing if the web host consented to you clicking on it.

This is clearly within the scope of implied consent, because it is (a)
necessary, (b) accepted, and (c) reasonably inferred by the actions in
putting up a web site.

Post by Brad Templeton
If you got a referral where I told you to e-mail my friend, you could not
mail him for fear you did not have his consent.

Person to person email is clearly within the scope of implied consent and
testing against the three criteria clearly indicates that this would be so.

Post by Brad Templeton
And If I want to mail you to flame you about how stupid
the opinion you posted on your web site is, well, who would suspect you give
your consent to be flamed?

This one is a little more difficult. Arguments on the "necessity" of this
could go either way. It is probable that inference from conduct would go
against, since most people don't like to be flamed. The acceptance test
would suggest that society accepts the need to infer implied consent for
flames, although this may vary depending on the free speech beliefs of the
particular society.

I would come down on the side of personal flames being within the scope of
implied consent, even though the recipient probably doesn't want them.

Post by Brad Templeton
it is always on by default. People can even come onto your private land to
come to talk to you unless you explicitly mark it no trespassing.

"No trespassing" is probably insufficient for this purpose. The sign would
have to make it clear that implied consent is withdrawn, or withdrawn for a
particular class. For example, "No hawking" clearly withdraws consent for
door-to-door salespeople, but "No trespassing" per se is redundant, since
if there is consent (even implied consent) there is no trespass.

Post by Brad Templeton
So because consent would be incredibly difficult to define, and it's a bad
idea to bring it into the spam definition

If you define spam as "unsolicited bulk", then it fails the necessity,
acceptance and inference tests.

If you define spam as "unsolicited commercial" (such that an individual
message is spam), then you are in a less certain area. All three criteria
can be argued either way, and I suspect acceptance is diminishing over
time. I would still come down on the side of "unsolicited commercial" but
"personal" as being within the scope of implied consent.
--
Troy Rollo Chairman, CAUBE.AU
***@troy.rollo.name Executive Director, iCAUCE

[Brad Templeton]

Post by Troy Rollo
c. What can reasonably be inferred by the actions of
the possessor of the property.

You make a number of good points, so let me drop to the other problem
I pointed out with consent issues, which is the difficult technical
challenge of finding a way to figure out consent when we have all sorts
of vague definitions of implied consent, and so many different preferences
among individuals as to what consents they wish to give.

Even in this group we have seen many people express different views over
what they think is spam, vs. mail they think they have implicitly consented
to receive. Just this week we've debated the suggestion that if you post
to a mailing list you consent to replies to your messages from others, but
not to automatic replies from broken bots, and possibly not to off-topic
replies -- for example most would say that posting here doesn't allow me to
reply to them to offer them cheap blue sex pills.

I see it as intractable to define a mechanism for definition of advance
consent. As in, "I don't know who you are or what your message is about but
I rescind consent in advance if it meets criteria X." If we could come up
with a language that workably described all the "X" people are interested
in which could also be handled well by people mailing material that might
meet criteria X, that would be interesting but I don't hold much hope for
such a language.

Post by Troy Rollo
that SMTP as a protocol demonstrates a design centred on person to person
messages and another protocol (NNTP) demonstrates a design centred on
broadcast messages (even having substantially the same message format)

Unfortunately bulk mail has a long history, predating even newsgroups by
many years. I have gone down this course before, but I can't escape the
conclusion that bulk mail is considered one of the legitimate uses of
mail. How can we as we discuss it on a mailing list? However, it is definitely
secondary.

Post by Troy Rollo
This is clearly within the scope of implied consent, because it is (a)
necessary, (b) accepted, and (c) reasonably inferred by the actions in
putting up a web site.

Unfortunately it is not so "clear" as there are many court cases about this,
about issues such as deep linking, inlining and spidering in various forms.
People want to give consent to some (google) but not to others (shopping bots
or deep linkers) and so on.

If only this were clear.

Post by Troy Rollo
Person to person email is clearly within the scope of implied consent and
testing against the three criteria clearly indicates that this would be so.

I thinks so but again, I have seen many in the anti-spam community offer
extreme definitions which include person to person mail. CAUCE, a fairly
major organization in the anti-spam community, has pushed its lobbying
efforts around single e-mails from the start, and so have many others.

It is alas, not clear.

Post by Troy Rollo
This one is a little more difficult. Arguments on the "necessity" of this
could go either way. It is probable that inference from conduct would go
against, since most people don't like to be flamed. The acceptance test
would suggest that society accepts the need to infer implied consent for
flames, although this may vary depending on the free speech beliefs of the
particular society.

I think you aptly demonstrate the technological impossiblity of making a
protocol based way to define advance consent.

Rescinded consent is of course much easer (and implementable at the endpoint)
A blacklist is rescinded consent -- if only blacklists didn't have all their
other problems.

Post by Troy Rollo
"No trespassing" is probably insufficient for this purpose. The sign would
have to make it clear that implied consent is withdrawn, or withdrawn for a
particular class. For example, "No hawking" clearly withdraws consent for
door-to-door salespeople, but "No trespassing" per se is redundant, since
if there is consent (even implied consent) there is no trespass.

These signs rely on being in human natural languages. So people have a wide
scope on what they can put on the sign, and it is handled by another natural
intelligence. No such luck in SMTP.

[w***@waltdnes.org]

Post by p***@gammon.com

Post by w***@waltdnes.org
I don't consent to 1) and I don't consent to 2). I do not see any
difference.

Ah, but some people *do* consent to 2), and they would like to receive
the weekly cheez-wiz recipes that they've otped into.

That's the "human-shield effect" that some e-marketers rely on.
Outfits like PennMedia/Shagmail and Topica send newsletters/whatever to
known unconfirmed lists. Like you said, there are some people who do
subscribe to them, but others who don't want the stuff still end up
getting it. The sending outfits rely on the fact that the few willing
subscribers will complain if their ISPs blocking them outright. When you
get *THE SAME CONTENT FROM THE SAME IP ADDRESS* being sent to both willing
and unwilling recipients, it becomes more difficult to block. This tends
to happen most often with "advertiser-supported" newsletters, where the
number of "subscribers" determines how much the mailing company gets
paid by advertisers.

Post by p***@gammon.com

Post by w***@waltdnes.org
The *ONLY* difference is that the people behind "legitimate marketing
stuff" make campaign contributions, and there's less liklihood of the
"legitimate" spam advertising stuff that's blatantly illegal. Folks,
it's about *CONSENT* not *CONTENT*.

False. The difference is that legitimate email marketers try pretty
hard to only send mail to people who want to receive it. Just because
you don't want to know what's on sale over at piggly wiggly doesn't
mean that I don't. In fact, I subscribe to somewhere between one and
two dozen separate email marketing streams right now.

And I'm sure that you're not interested in a mailing list on the CRUX
distro of linux, plus various other stuff that I subscribe to. I *OPTED
IN* to those lists, versus havimg to *OPT OUT* of a gazillion others.
And if e-marketers adopted *OPT-IN*, we wouldn't have today's problems.

Post by p***@gammon.com
Legitimate honest-to-goodness email marketers exist, and while they
aren't always perfect, they can do a pretty damned good job.

Unfortunately, they're damn hard to find. Companies that have a real
product to sell, and do things in-house, tend to be better. The hired
guns, who get lists of target addresses from customers, aren't in a
position to verify the lists.

Post by p***@gammon.com
I can count on one hand the number of unsolicited messages I've
received from Digital Impact in the last few years, for example,

Does that include all the following aliases?

merchantmail.net
m0.net
digital-impact.com
digitalimpact.com
digitalimpact.net
merchantmail.com
emailexchange.net
emarketingscience.com
responsiblemail.com
mm3.net
mm4.net
mm5.net
mm6.net
mm7.net
mm8.net
mm9.net

Now why would they send out their stuff under an assumed name, or
several assumed names? People are known by the company they keep.
Digital Impact is a member of the ESP ("Email Service Providers")
coalition. Who are these people? According to their press release
at http://www.networkadvertising.org/NAIESPRelease.pdf

Post by p***@gammon.com
Current membership in the ESP Coalition includes all of the major
companies in the email service provider industry: Digital Impact,
DoubleClick, Experian, iMakeNews, Aptimus, Avenue A, BlueHornet
Networks, Britemoon, Cheetahmail, Clickaction, eDialog, Eversave,
ExactTarget, GotMarketing, MindShare Design, Roving Software, Topica,
Virtumundo, and Yesmail.

This is an honour roll of past residents of MAPS RBL, some of whom
have used their money and their lawyers to sue their way out of the RBL.
Not exactly a glowing recommendation.

Post by p***@gammon.com
An opt-in email marketer who tries very hard never to send unsolicited
email, and who responds promptly and correctly if there is an
occasional screw-up, is not a spammer.

The problem is that there are tons of opt-out marketers who claim to
be opt-in. Here is a scenario that has been repeated too many times in
NANAE (news.admin.net-abuse.email)...
CR = Company Representative
NI = NANAE inhabitants

Company rep comes to NANAE

CR> Wahhhh, wahhh, we've been blacklisted. Why ?

NI> Because you spam.

Begin loop (repeats several times)

CR> No we don't.

NI> Yes you do.

End loop

CR> But, but, but, we're double-opt-in, blah, blah, blah

NI> (A NANAE inhabitant, who happens to be a sysadmin, trots out logs of
repeated attempts over the years by the company to deliver email ads
to postmaster@, abuse@, domain admin contact, and a slew of
non-existant addresses)
Explain that.

CR> (Comes back a couple of days later) But, but, but, our customer that
we emailed those out for *SAID* those were double-opt-in addresses

NI> And the National Enquirer says...

CR> (Comes back a couple of days later) But, but, but, the guy who sold
our customer the list of addresses *SAID* they were double-opt-in

NI> And the National Enquirer says...

If I sound cynical, yes I am. I've seen this finger-pointing garbage
as often as a teacher hears "the dog ate my homework". And I'm just as
likely to believe it. E-marketers' reputations are badly damaged, and
they will *NOT* get the benefit of the doubt.

Post by p***@gammon.com
I will grant you, however, that there's a decent-sized grey area in
between hot-teen-lolitas spammers and the best of the bunch.

One more time... it's about *CONSENT*, not *CONTENT*. I don't care
what the unwanted garbage in my inbox is.

[Kee Hinckley]

Post by w***@waltdnes.org
And if e-marketers adopted *OPT-IN*, we wouldn't have today's problems.

How do you define opt-in? Paper mail, fax, phone, web-site, email
message or any of the above with confirmation via any of the above?

[w***@waltdnes.org]

Post by Kee Hinckley

Post by w***@waltdnes.org
And if e-marketers adopted *OPT-IN*, we wouldn't have today's problems.

How do you define opt-in? Paper mail, fax, phone, web-site, email
message or any of the above with confirmation via any of the above?

For a mailing-list, email seems logical...

- Original contact by would-be subscriber via email or web-form
- List-owner sends confirmation request via e-mail stating which list
is being checked for subscription confirmation. Should include a
random-string/key/token which would not be guessable. Date-time
and IP address of the original request would also be nice.
- The would-be subscriber replies, including token. (Would MS Outlook
"out-of-office" messages auto-confirm you?)

I can tell when a marketer writes a column about opt-in; he does one
short paragraph about confirmed opt-in (see above) and then spends the
rest of a long article tap-dancing to find ways to extend the definition
to include sending stuff to people who didn't ask for it.

[Troy Rollo]

...so let me drop to the other problem
I pointed out with consent issues, which is the difficult technical
challenge of finding a way to figure out consent when we have all sorts
of vague definitions of implied consent

I don't think it's correct to say that there are many definitions of
implied consent - rather that there is some grey area in which it is not
necessarily clear if particular conduct comes within the scope of implied
consent.

On the other hand, there are areas where it is clear - person to person is
within, bulk is outside.

, and so many different preferences
among individuals as to what consents they wish to give.

This is a separate issue of expressing explicit consent. Explicit consent
what BMPP (and to a lesser extent BMTP) aim to facilitate. Implied consent
has nothing to do with the actual preferences of the recipient.

..many people express different views over what they think... they have
implicitly consented to receive. Just this week we've debated the
suggestion that if you post to a mailing list you consent to replies to
your messages from others, but not to automatic replies from broken bots,
and possibly not to off-topic replies -- for example most would say that
posting here doesn't allow me to reply to them to offer them cheap blue
sex pills.

From a legal perspective (and since consent is really a legal concept the
legal perspective is the relevant one), none of these questions involves
implied consent. What they do involve is an attempt to imply terms into
some contract. Leaving aside the question of whether signing up to a
mailing list can amount to a contract (which is doubtful in itself),
implying terms into a contract is something that the law is reluctant to do
unless it is necessary to do so to give effect to the contract. Thus the
mailing list really doesn't come into the question when analysing consent
in those situations.

I see it as intractable to define a mechanism for definition of advance
consent.

Well yes, an attempt to cover the whole field of explicit consent in a
protocol is doomed to failure, however limiting scope to things that are
towards the "no implied consent" side of the line make this easier. The "NO
UCE/NO UCE" banners have such limited scope. BMTP has a slightly wider
scope, and BMPP wider still. In each case, however, the domain in which
they attempt to deal with consent is such that it does become possible to
cover the domain. I would venture to say that BMPP goes as far as you can
reasonably go when the domain is "Bulk".

Post by Troy Rollo
that SMTP as a protocol demonstrates a design centred on person to person
messages and another protocol (NNTP) demonstrates a design centred on
broadcast messages (even having substantially the same message format)

...I can't escape the conclusion that bulk mail is considered one of the
legitimate uses of mail.

The nature of the protocol is relevant for a consideration of implied
consent. A mailing list such as this one involves explicit consent. The
reason that the orientation of the protocols becomes relevant is that it
suggests that unsolicited bulk email is not "necessary" (there being an
alternative mechanism for broadcast messaging), it may be relevant to what
is accepted, and it is also relevant to what can be implied from the user's
actions (don't read news == probably don't want broadcast messaging, so if
somebody does want bulk messaging the applicable mechanism should be used).

Post by Troy Rollo
[one-to-one messaging on the basis of a referral] is clearly
within the scope of implied consent, because it is (a)
necessary, (b) accepted, and (c) reasonably inferred by the actions in
putting up a web site.

Unfortunately it is not so "clear" as there are many court cases about this,
about issues such as deep linking, inlining and spidering in various forms.
People want to give consent to some (google) but not to others (shopping bots
or deep linkers) and so on.

Every court case I am aware of (except perhaps the recent Verio/Ralsky one,
although I think that settled anyway) that was taken to judgement so far
has involved an explicit withdrawal of implied consent - or at least an
explicit notice that the traffic was unwelcome, which amounts to the same
thing.

Post by Troy Rollo
Person to person email is clearly within the scope of implied consent and
testing against the three criteria clearly indicates that this would be so.

I thinks so but again, I have seen many in the anti-spam community offer
extreme definitions which include person to person mail. CAUCE, a fairly
major organization in the anti-spam community, has pushed its lobbying
efforts around single e-mails from the start, and so have many others.

CAUCE's efforts were focused in this way for practical reasons, and this is
no longer the CAUCE position. CAUCE has shifted the focus back to bulk. It
may be that the focus goes back to (bulk && commercial), but that's a
matter for the CAUCE (USA) board.

Post by Troy Rollo
[notes on the bordeline status of implied consent in
person-to-person flames]

I think you aptly demonstrate the technological impossiblity of making a
protocol based way to define advance consent.

As noted, I agree that it is impossible to define a protocol to
exhaustively cover the domain of explicit consent. The only domain I see as
relevant to such mechanisms is bulk.

______________________________________________________________________________
***@rollo.com IANALY,TINLA Troy Rollo, Sydney, Australia
Fight spam in Australia - Join CAUBE.AU - http://www.caube.org.au/

[w***@waltdnes.org]

For example on 9/11 someone could have sent a broadcast to all RIM
pagers in the US with emergency information, I doubt it would have
been unwanted in many cases.

And what would it have accomplished that CNN couldn't ? Asides from
tying up bandwidth which could've been used by people to let relatives
know they were safe ?

The word indiscriminate is of course subjective, just like the term spam.
However a salesperson that sends messages to 10,000 existing customers can
hardly be considered indiscriminate,

Except that some of them will quickly become ex-customers.

nor is a salesperson who sends targetted messages to 100 sales prospects,

Most participants in this group seem to be male. Therefore, ads for
penis enlargement, meet-lonely-women, and viagra would definitely be
"targetted messages" by your criteria.

nor is a message with a CFP for an anti-spam conference sent to
this list.

It would be on-topic for this group.

[Hallam-Baker, Phillip]

Post by w***@elan.net

Post by w***@elan.net
a. Serious issues that the encryption technology

maybe broken

Post by w***@elan.net
later on and as such allow to get clear list of all

opted-out

Post by w***@elan.net
email addresses

Alas, there is no maybe about it.
Spammer's List of 50 million E-mail addresses | cleaning
service | diff
Will get you effectively all the email addresses that have gone on
the opt-out list. I mean, if you aren't on the spammer's
lists, you have
minimal reasons to go on the opt-out list so it is
effectively complete.
(Though corporate sites can put their entire population
on the list
with safety, but in that case why not just list the
domain rather than
the individuals.)

We could add to the list addresses that are not actually valid - like
the striker addresses for example.

This would mean that the results of the diff would be a mixture of
good and bad emails. If anything the result of a check would be more
likely to give a bad email than a good one.

Phill

[Kee Hinckley]

Post by Hallam-Baker, Phillip
We could add to the list addresses that are not actually valid - like
the striker addresses for example.

How would you validate them? And if you don't, why wouldn't some
helpful person do a dictionary attack on the opt-out list in order to
remove everyone.

[w***@elan.net]

Post by Kee Hinckley

Post by Hallam-Baker, Phillip
We could add to the list addresses that are not actually valid - like
the striker addresses for example.

I think this is called "poison pill" and different pills can be inserted
into lists that are distributed to different parties. Then if unwanted email
appears on this email, that can be used as verification that they
decryppted entire opt-out list.

Post by Kee Hinckley
How would you validate them? And if you don't, why wouldn't some
helpful person do a dictionary attack on the opt-out list in order to
remove everyone.

Similar "poison pill" system can also work for central server that
provides authentication to get opt-out list. In this case you invent some
easily guessable email addresses but not actually use it in any email. If
somebody querries for it and gets opt-out no answer but then there are
unsolicited emails coming to it, you know who did something wrong.

----
William Leibzon
Elan Communications Inc.
***@elan.net

[Hallam-Baker, Phillip]

Validate them???

Like folk might not want to be on the opt-out list???

Wouldn't *.com, *.edu ... be likely a correct first guess :-)

There are plenty of ISPs complaining that they are getting tons of spam sent
to non-existent addresses. It is not a bad idea to have a way to exclude
them.

I guess someone could inherit an email address and complain that they are
not getting the spam they wanted...

Phill

-----Original Message-----
Sent: Wednesday, March 26, 2003 4:34 PM
To: Hallam-Baker, Phillip
Subject: RE: [Asrg] 5b. Opt-Out, 2nd version

Post by Hallam-Baker, Phillip
We could add to the list addresses that are not actually valid - like
the striker addresses for example.

How would you validate them? And if you don't, why wouldn't some
helpful person do a dictionary attack on the opt-out list in order to
remove everyone.
--
Kee Hinckley
http://www.puremessaging.com/ Junk-Free Email Filtering
http://commons.somewhere.com/buzz/ Writings on Technology
and Society
I'm not sure which upsets me more: that people are so
unwilling to accept
responsibility for their own actions, or that they are so
eager to regulate
everyone else's.

[Hallam-Baker, Phillip]

Hang on a second here, I don't think anyone in the crypto world I'd
seriously worried about an atack which woud allow an attacker to find an
eficient inverse function for sha1 and I they did we would be sooo screwed
every other way it would not be funny.

I was thinking we would add boogus email addresses that have already found
their way to the lists...


-----Original Message-----
From: ***@elan.net
Sent: Wed Mar 26 14:59:08 2003
To: Kee Hinckley
Cc: Hallam-Baker, Phillip; 'Brad Templeton'; 'Asrg (***@ietf.org)'
Subject: RE: [Asrg] 5b. Opt-Out, 2nd version

Post by Kee Hinckley

Post by Hallam-Baker, Phillip
We could add to the list addresses that are not actually valid - like
the striker addresses for example.

I think this is called "poison pill" and different pills can be inserted
into lists that are distributed to different parties. Then if unwanted email

appears on this email, that can be used as verification that they
decryppted entire opt-out list.

Post by Kee Hinckley
How would you validate them? And if you don't, why wouldn't some
helpful person do a dictionary attack on the opt-out list in order to
remove everyone.

Similar "poison pill" system can also work for central server that
provides authentication to get opt-out list. In this case you invent some
easily guessable email addresses but not actually use it in any email. If
somebody querries for it and gets opt-out no answer but then there are
unsolicited emails coming to it, you know who did something wrong.

----
William Leibzon
Elan Communications Inc.
***@elan.net

[Brad Templeton]

Post by Hallam-Baker, Phillip
Hang on a second here, I don't think anyone in the crypto world I'd
seriously worried about an atack which woud allow an attacker to find an
eficient inverse function for sha1 and I they did we would be sooo screwed
every other way it would not be funny.
I was thinking we would add boogus email addresses that have already found
their way to the lists...

The privacy goals are twofold. We would like to avoid having to declare
publicly your desire to opt-out, though frankly this is not that much of
a killer.

Secondly, we would want to avoid spammers deliberately spamming all the people
who opted out because they can get a list of all of them.


The seeding idea is interesting. It doesn't solve the first problem, your
name will still go on a list that can be made public, but as I said we can
probably survive that, it's just somewhat ironic to have to go public to
protect your privacy.

You would need to seed the opt-out list with hashes of tens of millions of fake
addresses, and those fake addresses would need to be ones that can't be
spotted as fake (they don't bounce) and which occur on popular spamming lists,
but which are not anybody's mailbox.

That's a bit of a tall order!


Reversing a secure hash is (of course) not an issue here, you don't need to
do it to turn the list of hashed addresses into real addresses when you have
the database of 50 million valid emails on CD the spammers trade around. If
you get spam, you're on their lists, so they can make a list of everybody
on the opt-out list who is on a common spammer's list.

Now why they want to spam it I don't know, possibly for spite. Only well hidden
overseas spammers would do it, but they would.

It is also a DoS attack on people. If you hate somebody, extract the list of
opted out people, then fake mail from the hated person to thousands of opted
out people. Presuming the opt-out is working, the recipients will be extra
angry, this would bring down a rain of trouble on the poor soul.

Perhaps this is the greatest danger of the opt-out list. It also applies to
the special domain I described and all other systems though. If opt-in were
morally acceptable, it would certainly be easier to implement, but it isn't.

[Chuq Von Rospach]

Post by Brad Templeton
Secondly, we would want to avoid spammers deliberately spamming all the people
who opted out because they can get a list of all of them.
The seeding idea is interesting.

if we revisit something I mentioned a while ago -- the idea of a
"robots.txt" for e-mail, to allow a domain to define usage/consent
rules in a standardized way. It's fairly trivial to extend that concept
to include traps addresses, ones placed into that file specifically to
catch people attempting to harvest and use the concent addresses. And
any IP that mails to a trap address gets blackholed for a period of
time.

It creates the problem of people using those addresses as an attack
mode, but the attacks are fairly limited and can be handled:
subscribing ***@foo.com to ***@bar.com only gets people in
trouble to the degree they try to mail to bar.com, and only to the
degree that the trap address becomes known outside of the folks
controlling the domain -- and as it becomes known, its usefulness goes
away and it should be changed, since the spammers will figure it out
and wash it, leaving behind only something useful for the trolls...

this is a fairly common way to trap the web robots that misbehave, it'd
be a reasonable way to both extend consent out for email and protect
the addresses in the file, since it wouldn't be obvious what addresses
are the traps, only that there are traps there. and yes, trap discovery
is an issue, but there are ways to deal with that, also.

[Vernon Schryver]

Post by Brad Templeton
...
Secondly, we would want to avoid spammers deliberately spamming all the people
who opted out because they can get a list of all of them.
The seeding idea is interesting. It doesn't solve the first problem, your
name will still go on a list that can be made public, but as I said we can
probably survive that, it's just somewhat ironic to have to go public to
protect your privacy.
...
you get spam, you're on their lists, so they can make a list of everybody
on the opt-out list who is on a common spammer's list.
Now why they want to spam it I don't know, possibly for spite. Only well hidden
overseas spammers would do it, but they would.
...

Why do some spammers curently test 10,000 arbitrary user names at many
domain names to see if they are valid with either Rcpt_To "vrfy" or
trial spam? Whatever their reasons, wouldn't it be far faster and
easier for them to get the same information using the opt-out system?

Imagine that you are a spammer and do not have a current list of
targets. What if you test against the opt-out system a list of 10,000
or 1,000,000 user names, starting with "tom", "dick, and "harry," and
continuing with zillions of other names including message-IDs and
other strings, all combined with a few 1000 or 1,000,000 domain names?
That would give you a list of many of the entries in the opt-out list.
If you were a spammer who doesn't believe the opt-out list applies
to your important message, could you use such a list?


Vernon Schryver ***@rhyolite.com

[Brad Templeton]

Post by Vernon Schryver
Why do some spammers curently test 10,000 arbitrary user names at many
domain names to see if they are valid with either Rcpt_To "vrfy" or
trial spam? Whatever their reasons, wouldn't it be far faster and
easier for them to get the same information using the opt-out system?

That is indeed the problem I am pointing out. I noted dictionary attacks
as another possible avenue. That's less likely with a cleaning "service"
in that the service could notice that you're trying to clean a dictionary
list, but even then it's hard to fully protect.

One way or another, if there is an opt out list, the spammers will get
ahold of most of it, and presumably abuse it.

However, it should be noted that this would be a particularly strong
offence, sent to people who are known hostile to spam, so doing this would
bring down even harsher penalties, but I wouldn't bank on their effectiveness.

If the list is seeded with tens of millions of addresses which are bogus, it
it becomes harder, but there must be no way for them to find out if those
addresses are bogus -- ie. you must not be able to verify them with vrfy,
and mail servers must accept delivery for them, or they will be quickly
weeded out. The seeded addresses would of course contain lots of dictionary
style addresses (common names, initial plus common last name etc.)

But it would possibly result in a lot of spams you have to eat just to make
this tactic ineffective.

It was for this reason that I decided that the rather unsatisfactory approach
of getting a new mailing address that had a reserved word in the domain to
indicate opt-out was all that could be done to be immune to this particular
attack. But it's pretty dramatic, having to get a new email. (though you
could have an autoresponder on your old email to tell people about your
new one, and even forward the old one for a time etc.)

[Vernon Schryver]

Post by Brad Templeton

Post by Vernon Schryver
Why do some spammers curently test 10,000 arbitrary user names at many
domain names to see if they are valid with either Rcpt_To "vrfy" or
trial spam? Whatever their reasons, wouldn't it be far faster and
easier for them to get the same information using the opt-out system?

That is indeed the problem I am pointing out. I noted dictionary attacks
as another possible avenue. That's less likely with a cleaning "service"
in that the service could notice that you're trying to clean a dictionary
list, but even then it's hard to fully protect.

I don't understand that. I am talking about a dictionary attack on
the opt-out list. Separately, anyone running an SMTP server and paying
any attention notices some current dictionary attacks. Some dictionary
attack spamware seems to be multi-threaded and hits SMTP servers with
100s of names per second.

Post by Brad Templeton
...
If the list is seeded with tens of millions of addresses which are bogus, it
it becomes harder, but there must be no way for them to find out if those
addresses are bogus -- ie. you must not be able to verify them with vrfy,
and mail servers must accept delivery for them, or they will be quickly
weeded out. The seeded addresses would of course contain lots of dictionary
style addresses (common names, initial plus common last name etc.)
...

Enough people already use trap lists such as
http://www.rhyolite.com/anti-spam/dict-attack.html so that there are
millinos of such traps. They are somewhat effective for things like
the DCC, but they're certainly not The Final Solution To Spam.

Post by Brad Templeton
...
It was for this reason that I decided that the rather unsatisfactory approach
of getting a new mailing address that had a reserved word in the domain to
indicate opt-out was all that could be done to be immune to this particular
attack. But it's pretty dramatic, having to get a new email. (though you
could have an autoresponder on your old email to tell people about your
new one, and even forward the old one for a time etc.)

I don't understand that because it seems to imply that people either
opt-out of everything or nothing. Anyone who want's to opt-out of
everything is best served by not having an address, or at least not
having an address that is ever given to anyone but very close personal
friends who won't pass it on.


Vernon Schryver ***@rhyolite.com

[Markus Stumpf]

Post by Vernon Schryver
Why do some spammers curently test 10,000 arbitrary user names at many
domain names to see if they are valid with either Rcpt_To "vrfy" or
trial spam?

What evidence do you have they do?
I can't see this happen. We host about 10000 domains and we do log VRFY
commands. I see about one VRFY a day and and checking the session it's not
from spammers but someone using a telnet connection to speak SMTP and
playing around.

If you mean by verify that they use
mail1.asp-platform.com:216.109.92.216 rejected:
<NOLIST-v1-2667199534-7346-78-ROBHERBER**BAYERN****@MAIL2.ASP-PLATFORM.COM>
to <***@BAYERN.NET>
this would mean that they care for the results. They don't. Although the
above inject results in a permanent error every time, they did exactly
the same sender/recipient pair about 70 times within the last 12 hours.
Probing would mean doing it once, ok maybe 2-3 times to be sure, but not
70 times within 12 hours or 208 times within the last 36 hours or 368
times within the last 60 hours

The last "massive spam attack" were about 5 million bounces where the
spammers used the same username as sender name they used for the recipient,
i.e.
from ***@bouncevictim.domain
to ***@target.domain
they didn't get the bounces back. We got them.
They simply don't care and why should they?

I have yet to see a reason why spammers should honor an opt-out list at all.
With snail mail it a massive cost factor, so "robinson lists" save a lot
of money for the sender.
With email nobody cares. And you will never get a law to enforce this
policy. And if you get it in country one they abuse it in country two.
And what worldwide resolutions/agreements mean this days can be seen in
tv and every newspapers for the last few days.

Discussing opt-out list strategies is IMHO a waste of time.

\Maex

[Chuq Von Rospach]

Post by Markus Stumpf
I have yet to see a reason why spammers should honor an opt-out list at all.
With snail mail it a massive cost factor, so "robinson lists" save a lot
of money for the sender.

It's yet another example of lumping the e-marketers in with the
fraudulent spammers, and assuming they're one in the same in search of
"a solution". The e-marketing segment is a different beast (and a much
tinier problem) to the problem of all that forged garbage. The folks
who are already hiding themselves won't deal with opt-out lists, other
than to grab them to spam to them, also. Opt-out lists would be great
with the e-marketing segment, but 100% compliance in that segment
woldn't even be noticed if we don't fix the bigger problem.

[Vernon Schryver]

Post by Markus Stumpf
...

Post by Vernon Schryver
Why do some spammers curently test 10,000 arbitrary user names at many
domain names to see if they are valid with either Rcpt_To "vrfy" or
trial spam?

What evidence do you have they do?
I can't see this happen. We host about 10000 domains and we do log VRFY
commands. I see about one VRFY a day and and checking the session it's not
from spammers but someone using a telnet connection to speak SMTP and
playing around.

I see almost no use of the SMTP VRFY or EXPN commands. Instead I and
many others see uses of the SMTP RCPT_To command (sometimes followed by
DATA) to get the same effect as VRFY. Note that sendmail does not
normally log RCTP_To commands used in place of VRFY.

Post by Markus Stumpf
...
I have yet to see a reason why spammers should honor an opt-out list at all.

Spammers vary. Some don't want to offend prospective customers and
see everyone as a prospect. Others don't have as as much foresight
and don't care if they offend non-customers.

Post by Markus Stumpf
...
Discussing opt-out list strategies is IMHO a waste of time.

I think "arranging deck chairs on the Titanic" fits. It's not a
complete waste, but so far the benefits seem unlikely to be enduring.


Vernon Schryver ***@rhyolite.com

[Markus Stumpf]

Post by Vernon Schryver
DATA) to get the same effect as VRFY. Note that sendmail does not
normally log RCTP_To commands used in place of VRFY.

I use a heavily patched qmail and I see everything ;-) like
12-247-32-83.client.attbi.com:12.247.32.83
allowed: <***@optinnow.net> to <***@space.net>
using this method against a qmail smtpd doesnt make sense at all, as
qmail will accept all messages, except for blocked sender addresses
(badmailfrom).

Post by Vernon Schryver
Spammers vary. Some don't want to offend prospective customers and
see everyone as a prospect. Others don't have as as much foresight
and don't care if they offend non-customers.

I have talked to a former customer (a publisher of computer magazines)
who did a spam mailing to about 50000 addresses to get new subscribers.
He said he doesn't care much about offending. The users that read it
and find it interesting aren't offended and do a trial or become
subscribers at once. The ones that are not interested may be offended,
but he doesn't care about them.
IMHO the problem with spam is that it still works, 'cause if they are
interested they say "damn, it's spam, but it's interesting" and they
but it.

I also know about a smaller ISP that fought (and fights) spam whenever
possible. But when one of the admins was spammed with a offering for
cheap USENET news service via satellite they signed the contract with
that company. *sigh*

\Maex

[w***@elan.net]

Post by Hallam-Baker, Phillip
Hang on a second here, I don't think anyone in the crypto world I'd
seriously worried about an atack which woud allow an attacker to find an
eficient inverse function for sha1 and I they did we would be sooo screwed
every other way it would not be funny.

Technology advances, both in terms of scientific research on cryptography
and just pure computational force power. You can never assume it'll not be
broken...

In reality I was thinking more in terms of trying to add somewhat easily
guessable poison email address to catch those doing dictionary attacks
and using the results improperly.

But Brad is also right, if somebody has 100 million email addresses
gathered from everywhere else and they wanted to clean it up to real
addresses, they would check with this opt-out list of 20million addresses,
there is good bet 99% of those 20million are contained in those 100million
(people would opt-out when they are already receiving too much unwanted
email and their email is already known), that however does not mean there
are no valid email addresses in remaining 80million so spammer would
probably continue to send to all 100million anyway.

But this does expose the problem that if you distribute list and let
email marketing company do all validation on their own, they will get
almost entire list. With cental server, while this is still also possible,
at least the authority providing the service can gather statistics of how
many queries each particulr authorized client is doing and if they see
somebody doing brutal force check of their 100million addresses, they
probably know its not a legit bulk mailer company. With opt-out specific
to each domain, the ability to do central verification is gone so even if
you see somebody doing this kind of check (which is difficult - you only
know statistics for your domain), its unclear if you can have any serious
response to it.

Post by Hallam-Baker, Phillip
I was thinking we would add boogus email addresses that have already found
their way to the lists...
-----Original Message-----
Sent: Wed Mar 26 14:59:08 2003
To: Kee Hinckley
Subject: RE: [Asrg] 5b. Opt-Out, 2nd version

Post by Kee Hinckley

Post by Hallam-Baker, Phillip
We could add to the list addresses that are not actually valid - like
the striker addresses for example.

I think this is called "poison pill" and different pills can be inserted
into lists that are distributed to different parties. Then if unwanted email
appears on this email, that can be used as verification that they
decryppted entire opt-out list.

Post by Kee Hinckley
How would you validate them? And if you don't, why wouldn't some
helpful person do a dictionary attack on the opt-out list in order to
remove everyone.

Similar "poison pill" system can also work for central server that
provides authentication to get opt-out list. In this case you invent some
easily guessable email addresses but not actually use it in any email. If
somebody querries for it and gets opt-out no answer but then there are
unsolicited emails coming to it, you know who did something wrong.
----
William Leibzon
Elan Communications Inc.

[Hallam-Baker, Phillip]

The list maintainer need not be one entity. All we need is agreement on the
hash function. I sugest a keyed digest with the key sha1("asrg")

You could give your email address to your participating isp, verisign, the
uspostal service or alan ralsky as you choose.

Most registrars would not keep any record of the addresses listed.


-----Original Message-----
From: Brad Templeton
Sent: Wed Mar 26 17:11:20 2003
To: Hallam-Baker, Phillip
Cc: '***@elan.net'; 'Kee Hinckley'; 'Brad Templeton'; 'Asrg
(***@ietf.org)'
Subject: Re: [Asrg] 5b. Opt-Out, 2nd version

Post by Hallam-Baker, Phillip
Hang on a second here, I don't think anyone in the crypto world I'd
seriously worried about an atack which woud allow an attacker to find an
eficient inverse function for sha1 and I they did we would be sooo screwed
every other way it would not be funny.
I was thinking we would add boogus email addresses that have already found
their way to the lists...

The privacy goals are twofold. We would like to avoid having to declare
publicly your desire to opt-out, though frankly this is not that much of
a killer.

Secondly, we would want to avoid spammers deliberately spamming all the
people
who opted out because they can get a list of all of them.


The seeding idea is interesting. It doesn't solve the first problem, your
name will still go on a list that can be made public, but as I said we can
probably survive that, it's just somewhat ironic to have to go public to
protect your privacy.

You would need to seed the opt-out list with hashes of tens of millions of
fake
addresses, and those fake addresses would need to be ones that can't be
spotted as fake (they don't bounce) and which occur on popular spamming
lists,
but which are not anybody's mailbox.

That's a bit of a tall order!


Reversing a secure hash is (of course) not an issue here, you don't need to
do it to turn the list of hashed addresses into real addresses when you have
the database of 50 million valid emails on CD the spammers trade around. If
you get spam, you're on their lists, so they can make a list of everybody
on the opt-out list who is on a common spammer's list.

Now why they want to spam it I don't know, possibly for spite. Only well
hidden
overseas spammers would do it, but they would.

It is also a DoS attack on people. If you hate somebody, extract the list
of
opted out people, then fake mail from the hated person to thousands of opted
out people. Presuming the opt-out is working, the recipients will be extra
angry, this would bring down a rain of trouble on the poor soul.

Perhaps this is the greatest danger of the opt-out list. It also applies to
the special domain I described and all other systems though. If opt-in were
morally acceptable, it would certainly be easier to implement, but it isn't.

[Brad Templeton]

Post by Hallam-Baker, Phillip
The list maintainer need not be one entity. All we need is agreement on the
hash function. I sugest a keyed digest with the key sha1("asrg")
You could give your email address to your participating isp, verisign, the
uspostal service or alan ralsky as you choose.
Most registrars would not keep any record of the addresses listed.

Can you be more specific as to how that solves the problem?

My issue is this. If you have a system -- any system at all -- which
will "clean" (ie. remove opted out addresses) from a large spammer's master
list (such as the lists they trade around on CD, you all have gotten spams
to buy them) then it is inherent that you will be giving them back a list
of all people on their list not in the opt-out list, and thus a list of
all people on their list who _are_ on the opt-out list.

The only way to avoid that would be what direct marketers do. The cleaner
also delivers the spam! You would need bonded companies which send
spam, but remove any opted out address from the mailing. They are bonded
to not reveal the contents of the list.

This may seem bizarre but in fact is not out of the question. This is how
the direct marketing business works. Of course the postal service is the
only company which delivers the mail.

But if you want to do a direct mailing, the list sellers don't give you a
copy of their list. They prefer to give it to a trusted 3rd company that
is mailing your ads for you. (Often they print, stuff and address for you.)
You hand them the ad, and tell them what lists you are buying, and they
clean the lists (of dups) print, stuff, address and take it to the post
office for you.)

However, larger mailers are trusted to get lists, and for a price you can buy
them.

To avoid people "stealing" the lists, they seed them with special trap addresses.
If they get a direct mailing that they didn't rent the list for, they come and
get you.



So if there were a "official" spamhuases, which respected the opt-out list,
you would not even need to blacklist it, because you could just opt-out and
encourage your users to opt-out.

Spammers who wanted to deliver their own spam would not be able to clean their
lists, and would be subject to the full wrath of anti-spam systems.

This sort of thing has been proposed by spammers in the past, and quite
correctly we have not trusted them. If the mailing houses however were
approved by us (meaning IETF folks and major ISPs) it's not as silly as it
sounds. At least until everybody gets on the opt-out list, and the company
becomes moot, and we start over again, unfortunately.

[Hallam-Baker, Phillip]

Post by Brad Templeton
My issue is this. If you have a system -- any system at all -- which
will "clean" (ie. remove opted out addresses) from a large
spammer's master
list (such as the lists they trade around on CD, you all have
gotten spams
to buy them) then it is inherent that you will be giving them
back a list
of all people on their list not in the opt-out list, and thus
a list of
all people on their list who _are_ on the opt-out list.

What is the risk that you are concerned about here? That the spam
sender might send MORE email to people that don't want it?

If the list has at least as high a percentage of garbage addresses
as the lists do on average it will be useless as a mechanism for
validating addresses. Trying to send mail to the junk addresses will
cause bounces.

In fact ISPs receiving lots of email to closed accounts would have an
incentive to list so the list might well end up having more closed
accounts and other bogus emails than addresses of genuine folk who
want to opt out.


Phill

[Hallam-Baker, Phillip]

Post by w***@waltdnes.org
And what would it have accomplished that CNN couldn't ? Asides from
tying up bandwidth which could've been used by people to let relatives
know they were safe ?

Try getting CNN in the aftermath of an earthquake when the power is
out.

Post by w***@waltdnes.org

nor is a salesperson who sends targetted messages to 100

sales prospects,
Most participants in this group seem to be male. Therefore, ads for
penis enlargement, meet-lonely-women, and viagra would definitely be
"targetted messages" by your criteria.

No, some of us don't suffer from the problems these products purport
to cure and if we did we would not buy quack remedies sold in this
fashion. So yes, the messages are indiscriminate. They are sent in
the knowledge that they will be unwanted by the vast majority of
the people receiving them.

We could use that as an alternative definition if you like, a
message is spam if the sender knows or should know that there
is a very high probability that the recipient will not want
to receive it. I don't like that quite as much though because
it allows weasel room for our friend ***@mailkey.spam and
folk who send email to private, off-list addresses and don't
bother to accept replies.

I worked out that if the remedies actually worked as promised and
I bought and used all the products spammed to me over a year a
certain part of my anatomy would be the size of the empire state
building. as for the breast enlargement products, has anyone
seen Woody Allen's film Sleeper?

Post by w***@waltdnes.org

nor is a message with a CFP for an anti-spam conference sent to
this list.

It would be on-topic for this group.

Exactly, it would be discriminating, but sending the same announcement
to the IPSEC list would not be on topic.


Phill

[Eric D. Williams]

Post by Jon Kyme

Post by Brad Templeton
In free societies, you don't need advance consent to communicate with
somebody else. Consent can be rescinded, as in "go away" but it is always
on by default.

Arrgh - freedom of speech! interesting field - look out for cowpats.
You may not need advance consent to attempt to initiate a communication.
A: "Knock, knock..."
But for the communication to proceed consent is required...
B: "Go away"

I think that is the point, this is not a freedom of speech issue. I disagree
with your premise, respectfully.

Post by Jon Kyme

Post by Brad Templeton
And since, on the internet, there is _no_ communication without use of the
private property of the other party to the communication, it means you
don't
need advance consent to use somebody else's property to communicate with
them. We have declared many times we don't have a right to be annoyed,
only
a right not be harassed.

That's a non sequitur. You might just as easily turn it around: Because you
don't have a right to
use someones private property without their consent, you don't have a right
to communicate with them.

I don't think so, a non sequitur would have to involve some element that was
unrelated to the premise, in this case the technical framework of the network
is (at its base) such a construction as was presented. So no I do not agree
that is a non sequitur.

Post by Jon Kyme
I can't believe that there's anywhere where my right to "free speech" gives
me the right to stage a political demonstration in your kitchen.

There is your right to ask to give a demonstration where ever, and my right to
refuse to allow you to give it in my kitchen. But that is I think a little far
off of the path that was being presented as a case for using consent as a basis
for a solution (although it is an integral element in enforcement of any
solution).

my $.02

-e

Post by Jon Kyme
This is not a profitable line of argument.

Post by Brad Templeton
To define communication without advance consent as some sort of offence
would turn our definitions of a free society and an open communications
system
upside-down. If somebody gave you a URL, you could not click on it without
knowing if the web host consented to you clicking on it. If you got a
referral
where I told you to e-mail my friend, you could not mail him for fear you
did
not have his consent. And If I want to mail you to flame you about how
stupid
the opinion you posted on your web site is, well, who would suspect you
give
your consent to be flamed?
In our society you can, by default, go up to somebody on the street and
talk to them. That is sometimes annoying, but it's a right we actually
fight hard to protect. You can send them postal mail, without their
consent.
It is always assumed to exist in advance. It can be rescinded -- through
restraining orders, harassment charges, blockages at the post office etc.
but
it is always on by default. People can even come onto your private land to
come to talk to you unless you explicitly mark it no trespassing.
So because consent would be incredibly difficult to define, and it's a bad
idea
to bring it into the spam definition, I respectfully submit that other
courses should be followed.
_______________________________________________
Asrg mailing list
https://www1.ietf.org/mailman/listinfo/asrg

--
_______________________________________________
Asrg mailing list
https://www1.ietf.org/mailman/listinfo/asrg

[Jon Kyme]

Post by Eric D. Williams

Post by Jon Kyme

Post by Brad Templeton
And since, on the internet, there is _no_ communication without use of

the

Post by Jon Kyme

Post by Brad Templeton
private property of the other party to the communication, it means you
don't
need advance consent to use somebody else's property to communicate

with

Post by Jon Kyme

Post by Brad Templeton
them. We have declared many times we don't have a right to be annoyed,
only
a right not be harassed.

That's a non sequitur. You might just as easily turn it around: Because

you

Post by Jon Kyme
don't have a right to
use someones private property without their consent, you don't have a

right

Post by Jon Kyme
to communicate with them.

I don't think so, a non sequitur would have to involve some element that was
unrelated to the premise, in this case the technical framework of the network
is (at its base) such a construction as was presented. So no I do not
agree
that is a non sequitur.

Non sequitur
n.
An inference which does not *follow* from the premises.
(not "unrelated")

It's possible (as demonstrated) to infer the contrary
from the same premises.





--

[Hallam-Baker, Phillip]

While ignoring the deliberate forgery troll I think we haveto be carefull
using consent to define spam.

The problem as I see it is that this ends up substituting one ill defined
term for another.

I don't think we should try to come to a mechanistic definition of consent.
After all there are plenty of disareements here. I may think X consented
because a box was clicked. They may think otherwise because they never saw
it.

I think the test needs to be meaningfull consent. So the weasel consent of
spam semders counteth not.


-----Original Message-----
From: Vernon Schryver
Sent: Thu Apr 03 15:49:46 2003
To: ***@ietf.org
Subject: Re: [Asrg] Consent

Post by Kee Hinckley
I think it follows from this argument that the appropriate definition
of spam is very simple. Harassment. That's why I asked a while
back on this list whether harassment law and restraining orders (both
of which are based to a certain degree on the perceptions of the
recipient) might not be the best model.

Doesn't harassment require some sort of repetition and some kind of
obnoxiousness, threat, or other objectionable quality?
http://www.m-w.com/cgi-bin/dictionary?va=harassment says
it means "to annoy persistently."
http://www.safetyed.org/help/stalking/stalkusa.html and the rest of
http://www.google.com/search?q=harassment+legal
seem to suggest some notion of repetition is involved.

Would one polite, short, unsolicited bulk email message every 6 months
be seen as harassment by a court or other sane authority?--I doubt it.

How many individuals and organizations in the world might reasonably
send you an annual reminder of their existence and request for
permission to send more mail? How many bulk unsolicited non-harresmment
email messages would you like in your mailbox daily?

It is counter-productive to take with interesting connotations and
then pretend that their definitions are whatever is convenient. This
is as true of calling the use of surprising mail return addresses
"forgery" as would be of squeezing "spam" into a "harrassment" box.


Vernon Schryver ***@rhyolite.com

[Hallam-Baker, Phillip]

Actually the term spam was coined after a bot that went bad, Dick
Depew's ARMM bot that ran amok on comp.news.admin. Ten years ago
to the month as Brad will probably remind us.

Post by matthew richards
if spammers were only spamming once very six months i doubt the ASRG
would exist, i doubt the term SPAM would exist.

I doubt that we would have companies prepared to pay very large sums
to be rid of spam if the frequency was that low.

My employer pays $50 a month for a RIM papger to make email access
more convenient. Usefull though the RIM is, I would much rather have
no spam anywhere if I had to choose.

Phill

[Jon Kyme]

Post by Paul Judge
Here is the list of work items that have been identified. If there are other
items that should be added to the list, please propose them. All
conversation on this mailing list must be regarding one of these items. The
subject of each email should begin with the number of the appropriate work
item. For example, "2.a - Spam Measurement Survey Requirements" or "6 -

Ah, those were the days.
Seriously, I'd like to propose a work item that we need adding to the list:

Consent - definition and determination

This is a key term for which we need a broadly agreed definition.
Particularly since the group is chartered to deal with consent-based
communication
(or rather communication which isn't consent based)

I look forward to your response.

Regards,
Jon Kyme




--

[Liudvikas Bukys]

I have been thinking about explicit consent models and representations.

The one place that I think is crying out for explicit machine-verifiable
consent is opt-in and opt-out. Because current practice is so free-form
and unconstrained, there is a (growing) grey area of deniability where
even well-meaning mailers make it too hard to opt out, are too tempted to
share their opted-in information.

As I composed this note, I noticed that it touches on work item 5.b.:
5.b. Opt-out. The idea here is that there should be a standard method of
opting-out so that it can be done by a program. There should also be a way
to systemically verify compliance. volunteer?

HOWEVER, I'm thinking larger: codify both opt-in and opt-out practice to
(1) make consent creation explicit,
(2) make opt-out uniform and unequivocal,
(3) reduce the inventives to share indiscrimately, by making it obvious
who shared what.


Here is a minimal consent model, that happens to map cleanly onto current
"best practice" confirmed opt-in, while extending it in desirable ways.
Automated support at the MUA is not required (but is a desirable outcome).

a. Consent means that a proposal has been presented and accepted.
b. Initial email contact is not really known to be consented to, but
recipients can help senders through their filters by supplying
a proto-token as a free pass through incoming filters.
c. A consent token (representing a security association) should contain
opaque data from both proposed sender and accepting recipient.
Both ends have the opportunity to encode information for future reference.
d. The handshake between sender and receiver also offers the opportunity
to generate a shared secret (e.g. via Diffie-Hellman protocol), which
may be useful for HMAC or other purposes.
e. Every message should provide the consent token, AND annotate it with
URIs (at least mailto, optionally other methods) for (i) unequivocally
revoking consent [no dialogs, are-you-sures, checkboxes, etc] and
(ii) examining the sender's current understanding of what is consented
to.
f. A DSN-like structured representation of proposal text may be a good idea.
g. Potentially automated management of all those emailed passwords
(initial password and output of "forgot-your-password?" resets) should
probably be included, as it is a common feature of email-based authentication.

This would be attractive to legitimate list owners, as a (standardized
non-proprietary) legitimizing technology to avoid overzealous filters.
It is not hard to implement, is not different in principal from the numerous
implementations already in place, and confirmed opt-in sofwtare could adopt
as a "small matter of programming".

This is an end-to-end idea (tokens contain opaque data), but there are
opportunities for delegating processing, by sharing some information with
MSAs/MTAs. (E.g. recipients share information with MTAs too, and embed
MTA-useful information in what the sender thinks is opaque data). That's
similar to the HMAC Message-ID ideas already succinctly summarized by Phillip
Hallam-Baker and others.

It does not require any third-parties, trusted or otherwise.


I have much more specific ideas, and after hearing some feedback will decide
whether to write this up more formally myself or in a small offline group.

Of course, if someone says it's not worthwhile, I guess that'll be it ;-}.
Keep those cards and letters coming.


Liudvikas Bukys
***@cs.rochester.edu

[w***@waltdnes.org]

Post by Liudvikas Bukys
b. Initial email contact is not really known to be consented to, but
recipients can help senders through their filters by supplying
a proto-token as a free pass through incoming filters.

Can't the mailing list mention on its website what (sub)domain or
machine their mail is coming from ? rDNS can be forged, as can
envelope-sender. However, if you say that email will be coming from
machine bad.example.com, then it's a simple matter of comparing output
from a domain lookup of bad.example.com against the IP address of the
MTA sending you the email. Note the following...

[m1800//home/waltdnes]host cnn.com
cnn.com has address 64.236.16.84
cnn.com has address 64.236.16.116
cnn.com has address 64.236.24.4
cnn.com has address 64.236.24.12
cnn.com has address 64.236.24.20
cnn.com has address 64.236.24.28
cnn.com has address 64.236.16.20
cnn.com has address 64.236.16.52

..yes, one name can return multiple addresses. This allows backup MTAs
and load-balancing. Going via DNS also means that...

1) You can change IP addresses, and DNS will still get you there.

2) During a switchover, you can list both old and new addresses.