Subject: [Asrg] ASRG work items

From: Paul Judge <[email-masked]>
Date: Mon, 24 Mar 2003 19:43:38 -0500

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.
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: [email-masked]
Date: Mon, 24 Mar 2003 15:22:29 -0800 (PST)

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?

---

From: [email-masked]
Date: Mon, 24 Mar 2003 15:25:30 -0800 (PST)

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

---

From: [email-masked]
Date: Mon, 24 Mar 2003 16:03:12 -0800 (PST)

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.

---

From: [email-masked]
Date: Mon, 24 Mar 2003 17:13:44 -0800 (PST)

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 [email-masked]. 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.

---

From: Brad Templeton <[email-masked]>
Date: Mon, 24 Mar 2003 22:50:46 -0800

> 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 [email-masked]  (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 [email-masked].  All
sendmail users get all mail to [email-masked].  All qmail users
get all mail to [email-masked].  There are many other examples.

Also, [email-masked] 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.

---

From: [email-masked]
Date: Mon, 24 Mar 2003 23:22:52 -0800 (PST)

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.

---

From: Kee Hinckley <[email-masked]>
Date: Tue, 25 Mar 2003 15:15:14 -0500

>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:[email-masked]?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 [email-masked] 
(with subject unsubscribe) and [email-masked].

-- 
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.
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Kee Hinckley <[email-masked]>
Date: Tue, 25 Mar 2003 15:08:53 -0500

>     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.
-- 
Kee Hinckley
http://www.puremessaging.com/        Junk-Free Email Filtering
http://commons.somewhere.com/buzz/   Writings on Technology and Society

---

From: [email-masked]
Date: Tue, 25 Mar 2003 16:47:23 -0500

> 	<mailto:[email-masked]?subject=unsubscribe>

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)

---

From: [email-masked]
Date: Tue, 25 Mar 2003 12:03:01 -0800 (PST)

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.

---

From: J C Lawrence <[email-masked]>
Date: Tue, 25 Mar 2003 16:29:16 -0800

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

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

> <mailto:[email-masked]?subject=unsubscribe>

RFC 2369.

-- 
J C Lawrence                
---------(*)                Satan, oscillate my metallic sonatas. 
[email-masked]               He lived as a devil, eh?		  
http://www.kanga.nu/~claw/  Evil is a name of a foeman, as I live.
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Vernon Schryver <[email-masked]>
Date: Tue, 25 Mar 2003 22:51:07 -0700 (MST)

> From: Kee Hinckley <[email-masked]>

>                     ...  This is the only hope we have of getting 

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    [email-masked]
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: [email-masked]
Date: Wed, 26 Mar 2003 00:00:47 -0800 (PST)

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.

---

From: Matt Sergeant <[email-masked]>
Date: Wed, 26 Mar 2003 12:20:49 +0000

> maillist email and has to contain proper maillist headers and opt-out

I consider it wishful thinking ;-)

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

Matt.

---

From: [email-masked]
Date: Wed, 26 Mar 2003 03:07:18 -0800 (PST)

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-masked]
     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. 
[email-masked]

---

From: [email-masked]
Date: Wed, 26 Mar 2003 03:14:03 -0800 (PST)

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?

---

From: Matt Sergeant <[email-masked]>
Date: Wed, 26 Mar 2003 13:18:12 +0000

> friends and depending on size of isp they may very well be on the same

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.

---

From: Kee Hinckley <[email-masked]>
Date: Wed, 26 Mar 2003 11:20:32 -0500

>maillist email and has to contain proper maillist headers and opt-out

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 
[email-masked] that I can offer as evidence.)  Those 
messages are very likely to exceed that per-server limit.
-- 
Kee Hinckley
http://www.puremessaging.com/        Junk-Free Email Filtering
http://commons.somewhere.com/buzz/   Writings on Technology and Society

---

From: Kee Hinckley <[email-masked]>
Date: Wed, 26 Mar 2003 11:16:08 -0500

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

???

---

From: Chuq Von Rospach <[email-masked]>
Date: Wed, 26 Mar 2003 09:00:56 -0800

On Wednesday, March 26, 2003, at 08:20  AM, Kee Hinckley wrote:

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

---

From: Vernon Schryver <[email-masked]>
Date: Wed, 26 Mar 2003 10:36:28 -0700 (MST)

> ...

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.

---

From: Brad Templeton <[email-masked]>
Date: Wed, 26 Mar 2003 10:28:32 -0800

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

---

From: Kee Hinckley <[email-masked]>
Date: Wed, 26 Mar 2003 13:34:22 -0500

>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.
-- 
Kee Hinckley
http://www.puremessaging.com/        Junk-Free Email Filtering
http://commons.somewhere.com/buzz/   Writings on Technology and Society

---

From: Chuq Von Rospach <[email-masked]>
Date: Wed, 26 Mar 2003 11:04:58 -0800

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

---

From: Tony Finch <[email-masked]>
Date: Wed, 26 Mar 2003 19:07:59 +0000

>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.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
NORTH FORELAND TO SELSEY BILL: EAST TO NORTHEAST 3 OR 4 LOCALLY 5. HAZY WITH
MIST PATCHES, AND A RISK OF FOG PATCHES. MODERATE OR POOR WITH A RISK OF FOG
PATCHES. SLIGHT.
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Chuq Von Rospach <[email-masked]>
Date: Wed, 26 Mar 2003 11:10:18 -0800

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

---

From: Brad Templeton <[email-masked]>
Date: Wed, 26 Mar 2003 11:32:26 -0800

> 	   later on and as such allow to get clear list of all opted-out 

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.)
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Vernon Schryver <[email-masked]>
Date: Wed, 26 Mar 2003 12:34:15 -0700 (MST)

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

---

From: Brad Templeton <[email-masked]>
Date: Wed, 26 Mar 2003 11:42:34 -0800

> argument for count=1 exists, even if it's going out to 10,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.
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Chuq Von Rospach <[email-masked]>
Date: Wed, 26 Mar 2003 11:40:58 -0800

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

---

From: Chuq Von Rospach <[email-masked]>
Date: Wed, 26 Mar 2003 11:56:50 -0800

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

---

From: Brad Templeton <[email-masked]>
Date: Wed, 26 Mar 2003 12:22:04 -0800

> 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.
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: "Jon Kyme" <[email-masked]>
Date: Wed, 26 Mar 2003 20:36:04 +0000

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

---

From: Chuq Von Rospach <[email-masked]>
Date: Wed, 26 Mar 2003 12:41:11 -0800

> Only humans break rules.  Computers simply execute commands.

okay, we'll agree to disagree.

> difference among the messages, or what percentage of the text was the 

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

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

---

From: Chuq Von Rospach <[email-masked]>
Date: Wed, 26 Mar 2003 12:51:28 -0800

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

> There's probably too much in the way of "voice from the mount"

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

---

From: Vernon Schryver <[email-masked]>
Date: Wed, 26 Mar 2003 20:05:39 -0700 (MST)

> From: "Jon Kyme" <[email-masked]>

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

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

---

From: Vernon Schryver <[email-masked]>
Date: Wed, 26 Mar 2003 20:32:10 -0700 (MST)

> From: Chuq Von Rospach <[email-masked]>

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

---

From: "Jon Kyme" <[email-masked]>
Date: Thu, 27 Mar 2003 08:48:06 +0000

> >>   Advertisers will never entirely honor anything but "tell me more."

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

---

From: "Jon Kyme" <[email-masked]>
Date: Thu, 27 Mar 2003 09:07:13 +0000

VS>> >  - I think communicating consent is hopeless and even a bad idea.  
>> My organisation, my ISP, a legitimate mass mailer, the courts.
VS>The needs of the courts to determine your consent have nothing to do
>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).

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

---

From: Kee Hinckley <[email-masked]>
Date: Thu, 27 Mar 2003 09:39:03 -0500

>>for humans--but for computers.

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

>      (Format: TXT=76076 bytes) (Obsoletes RFC1891) (Status: DRAFT

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

>      (Format: TXT=31832 bytes) (Obsoletes RFC1893) (Status: DRAFT

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.

>      (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.
-- 
Kee Hinckley
http://www.puremessaging.com/        Junk-Free Email Filtering
http://commons.somewhere.com/buzz/   Writings on Technology and Society

---

From: Kee Hinckley <[email-masked]>
Date: Fri, 28 Mar 2003 00:06:14 -0500

>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.
-- 
Kee Hinckley
http://www.puremessaging.com/        Junk-Free Email Filtering
http://commons.somewhere.com/buzz/   Writings on Technology and Society

---

From: [email-masked]
Date: Sat, 29 Mar 2003 00:08:25 -0500

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

[ ...Vernon said... ]
> >from us.  surely you've changed your mind?"

[ ...Jon said... ]
> 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.

-- 
Walter Dnes <[email-masked]>
An infinite number of monkeys pounding away on keyboards will
eventually produce a report showing that Windows is more secure,
and has a lower TCO, than linux.
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: J C Lawrence <[email-masked]>
Date: Fri, 28 Mar 2003 22:50:41 -0800

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

> Even a system that generates 1000 requests per day that you can ignore

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

---

From: "Jon Kyme" <[email-masked]>
Date: Sat, 29 Mar 2003 14:09:47 +0000

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

---

From: "Jon Kyme" <[email-masked]>
Date: Sat, 29 Mar 2003 14:09:50 +0000

---

From: "Jon Kyme" <[email-masked]>
Date: Sat, 29 Mar 2003 14:10:49 +0000