Subject: [Asrg] C/R Thoughts: Take 1

From: "Eric Dean" <[email-masked]>
Date: Sun, 11 May 2003 19:02:58 -0400

Per the request to put together ideas regarding C/R systems below is a brief
inventory of some possible areas for a C/R standardization effort.  I'm not
advocating standardization of any of these...but rather identifying areas
that to some are obvious.  The MUST, SHALLs, and MAY's can follow later:

There are a few general components to C/R or any email system
1) Message receipt:
-Permit: Whitelist sender, message scoring...automatically delivers to
user's Inbox
-Drop: Blacklist, message scoring...drops message
-Pend: Hold message in queue for further C/R validation

2) Sender Challenge
-Sender name: Should the original sender's name be sent in the reply to of a
challenge message or should a common name be used.  For examples, bounces
use <>.  C/R systems might avoid C/R loops using a convention.
-Subject header: Should the original subject header be preserved or a new
subject header be sent.  C/R systems might avoid C/R loops using a
convention.
-Actions: Should a sender be allowed to merely confirm or can they also
report that they did not originate the message..or possibly report to an
authority
-Challenge Bounce: There are a variety of SMTP errors that can be
returned...should some be considered to result in an automatic message drop?
Blacklisting a sender may result in a later valid user actual taking that
user namespace.

3) List Detection
-Sender Header: What methods other than the sender header should be used to
detect a mailing list thus disabling C/R messages?

4) Sender Response
-HTTP: Are there recommended methods for producing verification URLs?
Certainly they should be unguessable.  Should they have a short TTL or have
a persistent convention?
-Access Codes: Should a barely legible, anti-bot access code also be
supplied?
-SMTP: Should SMTP responses be supported?

_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Yakov Shafranovich <[email-masked]>
Date: Mon, 12 May 2003 16:45:27 -0400

I have been in touch with a company called MailCurcuit.com, who currently 
operates a C/R system. They are willing to provide information on their own 
experience with different aspects of C/R systems, as well as statistics. I 
will be passing along some statistical information from them.

Yakov

---

From: Richard Rognlie <[email-masked]>
Date: Mon, 12 May 2003 16:56:53 -0400

My question for C/R mechanisms (which may have been answered already, but...)

What does this do to automated relay system?

e.g.  I run a game server that let's people play various games via email.

You send your message to [email-masked], it parses/validates the request
It then sends the results to all affected parties (e.g. the N players) of 
the game.

A C/R system would lookup [email-masked] (or perhaps
[email-masked]).  so... I suppose it's up to me, as the
admin/author to make my system smart enough to see "oh... here's a message
I don't understand... can you read it, Richard?"

-- 
 /  \__  | Richard Rognlie / Oracle Prophet / Gamerz.NET Lackey
 \__/  \ | http://www.gamerz.net/rrognlie/    <[email-masked]>
 /  \__/ | Today is the first day of the rest of your life.  Of course,
 \__/    |    so was yesterday, and look how you screwed *that* up...
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Yakov Shafranovich <[email-masked]>
Date: Mon, 12 May 2003 17:42:07 -0400

>that to some are obvious.  The MUST, SHALLs, and MAY's can follow later:

We probably cannot recommend any specific implementation details like which 
filters should be used for message scoring,  just general guidelines. 
However, one problem with C/R systems is that spammers do not currently 
have an incentive to break them since there are many other ways to send 
spam. If C/R systems become wide spread, spammers will have an incentive to 
attack them and perhaps (gasp) even manage to break them. We need some 
input from live C/R systems.

>-Pend: Hold message in queue for further C/R validation

Would message scoring automatically drop messages below a certain 
threshold? Spam filters are not fool-proof and some messages might be lost. 
Perhaps all incoming email should be challenged or giving that as an option 
to the user?

Also, maybe a C/R system should be combined with a rDNS/RMX system to weed 
out invalid email addresses BEFORE a challenge is sent, in order to save on 
the use of computer resources.

How would a whitelist handle mailing lists? What about automated computer 
programs that notify users, like Ebay's auction bots? And what about 
anonymous email, if C/R is implemented everywhere, can anyone send 
anonymous email anymore? What about opt-in email that the receiver forgot 
about the original opt-in? And email that is sent from different email 
addresses everytime (like some mailing lists)?

>use <>.  C/R systems might avoid C/R loops using a convention.

It is not important to send the sender's name back, the email address is 
sufficient. As for bounces, a header might be used to catch that like the 
"X-BeenThere:" header used for our mailing list.

>subject header be sent.  C/R systems might avoid C/R loops using a

The challenge should contain at the least a copy of the header somewhere 
within the message so the sender can figure out what the challenge is in 
relation to. As for loops, use headers.

>report that they did not originate the message..or possibly report to an

Implementation-specific but at the least an admin email should be provided 
(that DOES NOT need C/R) where the users can email for with questions.

>Blacklisting a sender may result in a later valid user actual taking that

A C/R system should whitelist a sender when response received, not do 
anything otherwise. Blacklists should be used when the receiver wants to 
block an already verified sender.

>detect a mailing list thus disabling C/R messages?

For starters look for "List-Id:" and other "List-*" headers. Perhaps a 
standard way can be setup for a C/R system and mailing list software to be 
able to talk to each other automatically without a need for a human being 
to reply. Of course that will allow a hole for spammers to sneak through.

>Certainly they should be unguessable.  Should they have a short TTL or have

No persistent convention since that might allow spammers to build automated 
software. TTL is implementation specific, we cannot force everyone to use 
the same value. Preferably the challenge message should not be in HTML but 
plain text since not everyone has HTML or displays it differently. The 
response message might not via an HTTP url but could be just a response 
email - some people might only have email and not http (think mobile 
devices). It is best to support both - an HTTP url and a return email. 
Recommended methods for producing verification should utilize secure random 
generators with a large enough number of bits.

For verification purposes, special graphic images that are not parsable via 
OCR should be used on web pages much like the ones used by HotMail and 
Yahoo on account signups.

>-Access Codes: Should a barely legible, anti-bot access code also be

Explain.

>-SMTP: Should SMTP responses be supported?

Perhaps but we should probably avoid making changes to basic protocols as 
much as possible.

---------------------------------------------------------------------------------------------------
Yakov Shafranovich / <[email-masked]>
SolidMatrix Research, a division of SolidMatrix Technologies, Inc.
---------------------------------------------------------------------------------------------------
"One who watches the wind will never sow, and one who keeps his eyes on
the clouds will never reap" (Ecclesiastes 11:4)
---------------------------------------------------------------------------------------------------

---

From: Yakov Shafranovich <[email-masked]>
Date: Mon, 12 May 2003 17:51:07 -0400

>I don't understand... can you read it, Richard?"

If there is an automated protocol possible in place that allows your MTA to 
respond to incoming challenges that might solve the problem. But of course 
anything automated will let spammers do it to but at the least they would 
have to have a valid email address to do so. Once they have a valid email 
address, then they can be blocked or traced.

Yakov

---

From: "Eric Dean" <[email-masked]>
Date: Mon, 12 May 2003 22:05:41 -0400

> filters should be used for message scoring,  just general guidelines.

ok..again, I'm merely inventorying the potential areas of interest..not
advocating anything in particular

> attack them and perhaps (gasp) even manage to break them.

Well, we better build something they can't break.  There are many, many
smart people on this list that can surely put something  together over time

> We need some

We have a live C/R system and Mailcircuit is also a good source...not sure
how many other people on the list use C/R...but just about everyone knows
the vulnerabilities and limitations...often standards are discussed prior to
implementation...we have an advantage here.  I believe all would agree that
C/R should probably be tighter than current implementations..what that
results in..don't know.

> Perhaps all incoming email should be challenged or giving that as

ok..not trying to jump into the pool yet...just trying tom set
dimensions...not looking to take anythign off the table..jsut determing what
should be on the table

> the use of computer resources.

Not sure any measures would be in conflict with one another.

> addresses everytime (like some mailing lists)?

All of these are important tactical issues..any more?

> "X-BeenThere:" header used for our mailing list.

ok..that's one approach

> relation to. As for loops, use headers.

ok..as for the rest of your contributions.  I'm not particularly interested
in debating issues but rather discuss what issues we should debate.  I'm
sure  there will be spirited discussions to come..but for now..I want to
know what should get included within in a draft framework.

---

From: "Jon Kyme" <[email-masked]>
Date: Tue, 13 May 2003 10:48:03 +0100

> that to some are obvious.  The MUST, SHALLs, and MAY's can follow later:

I wonder if there's a case for taking some position on the privacy issues
involved in CR systems?

Issues like this:
http://www.toyz.org/SpamArrestSpams.html

Summary: Alleges SpamArrest harvests sender addresses

---

From: Vernon Schryver <[email-masked]>
Date: Tue, 13 May 2003 06:51:27 -0600 (MDT)

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

> Summary: Alleges SpamArrest harvests sender addresses

I see privacy issues for challenge/response systems, but that's not
one.  Ths SpamArrest abuse is a potential problem in any system where
you let a third party with handle your mail.  It is a consideration
in any system where that involves asking a third party anything about
mail, including DNS blacklists.

I think the obvious challenge/response privacy leaks are:

  - more messages slopping around the net indicating that two people
   are conversing and probably something about the subject of their mail.
     A bad guy that cannot see the original mail might still be able 
     to see the challenge or the response.

  - inferences that can be made by sending one message to two addresses,
   one of which the bad guy knows will generate a challenge and one
   that won't.
     Depending on how the system works, the extra target address might
     affect how quickly or even whether the challenge is produced.

  - leaks from queues or whatever containing mail awaiting responses.

None seem major, but they ought to be mentioned.

I think any spam filtering RFC ought to have a section on privacy
like the required section on security.

Vernon Schryver    [email-masked]
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: "Jon Kyme" <[email-masked]>
Date: Tue, 13 May 2003 15:30:17 +0100

Please ignore accidental attachment of managers phone number to
last message. It'll be funny right up to the moment he finds out.

---

From: "Eric Dean" <[email-masked]>
Date: Tue, 13 May 2003 13:13:15 -0400

> >What does this do to automated relay system?

Most use a subscription method.  Messages from unsubscribed senders would
not be permited.  A CR system should not subscribe and if we used a
convention for the CR sender, then that could easily be filtered as well.

---

From: Yakov Shafranovich <[email-masked]>
Date: Tue, 13 May 2003 14:14:00 -0400

>Summary: Alleges SpamArrest harvests sender addresses

SpamArrest behavior is no different from a regular MTA operator or an ISP 
harvesting email addresses from all incoming and outgoing email. The only 
difference is since a C/R system must keep a list of verified email 
addresses, this makes it easier.

There are a few additional concerns. For example, the entire "verified" 
sender list as related to a specific email account is essentially a record 
of all people who sent emails to that user (its his address book 
essentially). What keeps the government from issuing subpoena against that 
information or some hacker breaking in and stealing it? I can easily hear 
an industry executive, lets say [email-masked], being fired for 
flirting with competitors via some email system after Microsoft obtained 
the his verified senders list via a subpoena. Or a Chinese dissedent being 
executed after a government hacker steals his "verified" senders database. 
One other possible concern is the possibility of spammer stealing the 
entire "white list" database. The same concerns also apply to a block list 
that is kept by users. Even though it is possible to avoid SOME issues by 
using a system wide white-list of verified senders instead of user-specific 
white-lists, a block or blacklist must be specific to each user.

A possible way around might be is based on approaches outlined by Peter 
Wayner in his book "Translucent Databases" regarding storing private data. 
Instead of storing the actual email address in the database, we might store 
a one-way hash of it, lets say MD5. When emails are sent and received, the 
sender's email address is hashed and compared against the database. This 
way if anyone ends up wanting to use the database, it would be impossible 
since there will be no email addresses in it. Of course it would still be 
possible to check a specific email address against or use some form of a 
dictionary attack, but that is left to be discussed (using a salt value 
will not help since we are trying to avoid the possibility of someone who 
has access to the database from using the data).

And last, another concern that has been bothering me with C/R, is the 
possible death of anonymous remailers with such system. There are numerous 
one-way anonymous remailers in existence, many of which are 
mixmaster-based. They allow people to send anonymous email one way which 
may be very important for people in countries with oppressive regimes. With 
a C/R system these remailers would essentially be killed unless their 
administrator starts replying to each message individually. Spammers 
currently do not use anonymous remailers (at least I am not aware of it) 
since they have many other ways to send spam. Will they start using them, 
if other tactics will not work?

Yakov

---

From: Yakov Shafranovich <[email-masked]>
Date: Tue, 13 May 2003 14:47:00 -0400

>All of these are important tactical issues..any more?

What is the intent of a C/R system? Is it merely to double-check the 
sender's email address to make sure it is working and valid, or is it also 
to make sure that the sender is a human being and not a computer? If it is 
only the first, that we are trying to make sure that the sender has a valid 
email address, then it might make sense to develop an automated C/R 
protocol that can be used by email clients and senders' MTAs to reply to 
the challenge. This will take care of issues like dealing with lists, 
automated bots and anonymous remailers - the list server will simply reply 
to the response via this automated protocol. It will also hide the C/R 
process from users. The obvious flaw is that the spammer will use it too - 
but they will have to use a valid email address to do it, or own their own 
MTA and domain (which is not a problem since we already see spammers owning 
name servers). However, if the intent of C/R systems is to make sure that 
the sender is human, than it essentially must perform a Turing test. 
Current techniques include using specially coded graphic images, etc.

I personally think that the intent of the C/R systems is to make sure that 
the originating email is valid. Thus it would make sense to have an 
automatic protocol for verification which can be utilized by systems to do 
so. This way we will undo one of the problems that the open nature of the 
Internet currently has - lack of checking who sent email, without disabling 
ability for machines to send emails. I don't think we should be seeking to 
create systems that verify whether the sender is human since the Net is 
full of computers sending email too - many of which are very useful and are 
not spammers.

One way to implement this automated C/R protocol is by using headers 
similar to the "return receipt" feature defined in RFCs 1894 and 2298.

Yakov

---

From: Vernon Schryver <[email-masked]>
Date: Tue, 13 May 2003 13:33:16 -0600 (MDT)

> From: Yakov Shafranovich <[email-masked]>

> ...
> dictionary attack, ...

Which implies that in the cases that matter, nothing is hidden.  Dictionary
attacks are easy when you know what you're looking for.  This is one
reason why the DCC procotol does not include a checksum for the target.
That's not a complete solution, but it's not as bad as the C/R case
where the database would consist of a recipient and a set of senders.

It seems me that the right answer for a C/R system is to treat the
data as equally sensitive as users' addressbooks.  Do not use
crypto-hashes, lest you tempt the unthinking or salescritters into
claiming that the data is not sensitive.  Never unthinkingly trust
third parties with the C/R database.

> ...
> possible death of anonymous remailers with such system. ...

Such concerns assume that C/R systems might be used by a majority of
users.  Doesn't experience with existing C/R systems show that is unlike?

One of the saving graces of a C/R system is that it does not need to
be deployed over most of the Internet before it has any effect.  Don't
waste that advantage by treating it as if it were or could be the final
solution against spam.

---

From: Yakov Shafranovich <[email-masked]>
Date: Tue, 13 May 2003 16:33:15 -0400

>where the database would consist of a recipient and a set of senders.

Nevertheless using hashes instead of password will not allow the owner of 
the C/R system to spam all the senders like SpamArrest did. I am not 
advocating a specific solution, just a need for one - more thought must go 
into this area.

Yakov

---

From: Yakov Shafranovich <[email-masked]>
Date: Tue, 13 May 2003 17:26:12 -0400

Here are a few links to some interesting articles on possible problems with 
C/R systems:

http://db.tidbits.com/getbits.acgi?tbart=07181
http://www.politechbot.com/p-04746.html

The biggest problem seem to be dealing with mailing lists. An interesting 
quote from one article on existing solutions and rules:

"A relatively easy to solve problem with challenge systems is that most of
them are written by dimwits who don't understand the way that e-mail
really works.  In 1983 the 4.3BSD Berkeley Unix "vacation"  program
correctly dealt with mail from lists and other mechanical sources, yet 20
years later I still see out-of-office replies from Lotus Notes and MS
Exchange to list mail every day."

---

From: "Eric Dean" <[email-masked]>
Date: Tue, 13 May 2003 17:30:14 -0400

> so.

Yes, if we could come up with a standard for C/R, then it would seem
appropriate that a mail client would be able to auto-verify any challenge
that came in response to a recipient that had been recently sent a message.
I'll throw out a light framework within the next day or two that we can
start insulting.  Requires coffee and post-midnight to truly think.

---

From: "Eric Dean" <[email-masked]>
Date: Tue, 13 May 2003 19:06:35 -0400

Well, I use a CR system and am subscribed to various mailing lists.  We use
the Sender header to exempt challenges.

The problems are generally related to the effectiveness CR but I have some
ideas of how stateful servers and/or client software can help improve that.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of Yakov
> Shafranovich
> Sent: Tuesday, May 13, 2003 5:26 PM
> To: Eric Dean; [email-masked]
> Subject: [Asrg] C/R - What people say
>
>

---

From: Dave Crocker <[email-masked]>
Date: Tue, 13 May 2003 16:31:11 -0700

Eric,

ED> Well, I use a CR system and am subscribed to various mailing lists.  We use
ED> the Sender header to exempt challenges.

What is the procedure to "exempt" challenges?

Does it require whitelisting the sender field value ahead of time?

Do we expect the general user population to do this kind of procedure?

Do we expect spammers not to use these exempted values?

And then there is the matter of spam sent TO the mailing list.

d/
--
 Dave Crocker <mailto:[email-masked]>
 Brandenburg InternetWorking <http://www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>, <fax:+1.866.358.5301>

---

From: Vernon Schryver <[email-masked]>
Date: Tue, 13 May 2003 18:52:15 -0600 (MDT)

> From: "Eric Dean" <[email-masked]>

> the Sender header to exempt challenges.

How does that operate?  What Sender values garner exceptions, and why
won't more spammers use them if there are any?  Or by "exception,"
do you mean that the mail is immediately discarded unchallenged?

About 5% of the last 29,319 spam caught in my traps have Sender headers.
Some of the streams of spam follow all of the forms that I know of
for a mailing list.  Here is a sample from a stream that you should
recognize, since it's from the hard working entity that sometimes
calls itself "Drew Lanzetta":

    From: Spec Sheet <[email-masked]>
    To: [email-masked]
    Subject: Stockgroup Signs Licensing Agreement with Time Warner
    Date: Mon, 12 May 2003 13:56:33 -0700
    MIME-Version: 1.0
    Content-Type: text/html
    List-Unsubscribe: <mailto:[email-masked]>
    List-Subscribe: <mailto:[email-masked]>
    List-Owner: <mailto:[email-masked]>
    X-List-Host: Main site
    Reply-To: [email-masked]
    Sender: [email-masked]
    Message-Id: <LYRIS-634245-31612-2003.05.12-13.56.34--vj#calcite.rhyolite.com@fin
    ancepages.com>
    MIME-Version: 1.0
    Content-Type: text/html

Note that those headers are exactly as they appeared on the wire before
my MTA did anything to them, including adding a Received: header.

Well, "Drew Lanzetta" doesn't include List-ID header, and I don't see
any recent spam in my traps that does.  
However, there is plenty in NANAS.  See
http://groups.google.com/groups?q=+%22list-id%22+group%3A*abuse.sightings

---

From: "Eric S. Johansson" <[email-masked]>
Date: Tue, 13 May 2003 21:16:54 -0400

> start insulting.  Requires coffee and post-midnight to truly think.

we went over this terrain in the camram project a couple of years ago.  Anytime 
you make a response something that can be auto responded to, you create a hole 
for spammers.  one thing I believe to be very important is a list of signatures 
for messages recently sent and the challenge should contain a matching signature 
for the message it is challenging.  That way, when the challenge is handled, the 
mail user agent can verify that the client really did send a message the 
challenge was returned for by matching signature and destination address.

This is part of protocol I'm using for handling postage due notices 
automatically within camram.  I'll elaborate more tomorrow if folks are interested.

---eric

---

From: Yakov Shafranovich <[email-masked]>
Date: Tue, 13 May 2003 22:07:11 -0400

At 09:16 PM 5/13/2003 -0400, Eric S. Johansson wrote:

>we went over this terrain in the camram project a couple of years 
>ago.  Anytime you make a response something that can be auto responded to, 
>you create a hole for spammers.  one thing I believe to be very important 
>is a list of signatures for messages recently sent and the challenge 
>should contain a matching signature for the message it is 
>challenging.  That way, when the challenge is handled, the mail user agent 
>can verify that the client really did send a message the challenge was 
>returned for by matching signature and destination address.
>

As I mentioned before what we are trying to figure out is the intent of C/R 
systems. We are aware that an automatic procotol can create a hole for 
spammers but at least the spammers must have a valid return address. The 
question remains: are C/R systems intended to verify that the message 
arrived from a valid email address or are they intended to make sure the 
sender is human?

Yakov

---

From: "Eric Dean" <[email-masked]>
Date: Tue, 13 May 2003 22:47:03 -0400

> ago.  Anytime

Well...what I'm thinking would allow for both.  I'm in the midst of writing
this up.  But we should support both an automated method of challenge
response verification as well as a manual method handled by the user.  In
this manner we would eliminate a certain type of spam..that which is forged.
Other types of spam would get handled in a different manner.

---

From: "Eric Dean" <[email-masked]>
Date: Tue, 13 May 2003 22:52:54 -0400

> How does that operate?

If we see a Sender header, we don't return a challenge.  The user will
verify the sender or block it.  For a list, the very first email from the
list requires verification and then the mail flows.

> What Sender values garner exceptions, and why
> won't more spammers use them if there are any?

They are more than welcome to use Sender headers...messages will sit in
quarantine as do any spam.

> Or by "exception,"

The messages sit in quarantine awaiting the user's action as do all spams.

---

From: "Eric Dean" <[email-masked]>
Date: Tue, 13 May 2003 22:52:55 -0400

> What is the procedure to "exempt" challenges?

Just simply look for the Sender header..if it's present then we don't send a
challenge...the user must verify the sender.

> Does it require whitelisting the sender field value ahead of time?

or afterwards.  We have white, black, and greylists.  By default, user's get
greylisted.

> Do we expect the general user population to do this kind of procedure?

Good question...I asked what other list detection methods are used?

> Do we expect spammers not to use these exempted values?

I don't think we can expect anything from spammers..other than they will end
spam

> And then there is the matter of spam sent TO the mailing list.

Yeah..well..that always sucks.

---

From: Vernon Schryver <[email-masked]>
Date: Tue, 13 May 2003 21:02:22 -0600 (MDT)

> The messages sit in quarantine awaiting the user's action as do all spams.

There should be a difference between "quarantine" and the user's
mailbox.  Spam you must read is not spam that has been filtered.  You
never see filtered spam.  So what is the false positive rate for a
user typical who very rarely if ever subscribes to mailing lists and
only checks "quarantine" hen expecting the first messages from a newly
subscribed mailing list?

Too many so called spam defense are are merely computer games in which
the goal is to make software identify spam.  These games not only do
not save any user time, CPU cycles, disk space, or bandwidth, but
increase the consumption of all those.  A spam system that requires you
to check all supposed spam to see that it really is is not a spam defense.
The spammer doesn't care whether you see its ad in your main mailbox
or your "spam folder," and neither should you.

---

From: "Eric Dean" <[email-masked]>
Date: Wed, 14 May 2003 00:19:59 -0400

> mailbox.

Agreed...sorry if I'm confusing.

> Spam you must read is not spam that has been filtered.

In the same breath..we should distinguish between filtered and quarantined.

>  You

Well...without getting into  our in-house implementation specifics (not
because I'm shy or find it to be proprietary but because this is a research
group), we find that users check their quarantine quite regularly..in fact
we send them a digest of the quarantine periodically.

> to check all supposed spam to see that it really is is not a spam defense.

Let's see, we save time when the challenges bounce..and drop the spam before
it's ever presented to the user.  We also save time by not downloading the
spam from the quarantine server to the user.

CPU cycles..never counted them..might save them..might not...my CPU runs
really, really low anyway.  But I don't get the pop-ups and other annoying
things from spam that probably take a cycle or two.

Disk space...spam is dropped before it's downloaded to your computer.  We
save disk space.

Bandwidth...it's dropped before it's downloaded

I would also add the offensiveness...I'm not aware of a case, but you'd
think some companies might get sued for harassment if employees are
bombarded with endless spam and don't take countermeasures.

> or your "spam folder," and neither should you.

We present only the Sender, Date, Subject, and a small text block to let the
user determine whether they want to permit, block the sender or forward,
drop the message.  Because the HTML never executes, the spammer has no idea
whether the email account is valid or not.  But these are specific to our
implementation.  In short, I can claim that the user never reads the
spam..therefore the spammer never gets paid...I'm tip-toeing a line here
that I'm probably already on the wrong side of...but I will be more than
interested in discussing this off-the-list where I can take off my research
hat and put on my shameless sales hat.

---

From: "Eric S. Johansson" <[email-masked]>
Date: Wed, 14 May 2003 08:01:19 -0400

Yakov Shafranovich wrote:
> As I mentioned before what we are trying to figure out is the intent of 
> C/R systems. We are aware that an automatic procotol can create a hole 
> for spammers but at least the spammers must have a valid return address. 
> The question remains: are C/R systems intended to verify that the 
> message arrived from a valid email address or are they intended to make 
> sure the sender is human?

fair enough.  Obviously, I am coming into the middle of the conversation and am 
trying to catch up.

I would argue that any form[1] of a challenge/response system is trying to 
determine that the e-mail address is valid.  It is unimportant and irrelevant as 
to whether or not the sender was human.  Any notification system (invoice from 
sales, billing etc.) is not sent by human and will not have a usable return address.

A long-winded example of this was pointed out to me by a potential customer. 
They were a financial house and they got notice of transaction completions by 
e-mail from automated systems.  They could not enumerate all of the systems they 
get e-mail from so white lists were out of the question.  They themselves were 
unwilling to provide a real address for bounces from their own automated system 
because they would not dedicate the personnel to sit there and handle all of the 
messages[2].  For them, challenge response without automated handling was 
completely unacceptable.

so, I'll argue for system that will allow automated systems to talk to each 
other by e-mail without any human interaction.

---eric

[1] in their best forms, stamp and challenge/response systems are functionally 
identical.  A stamp can be thought of as a generated answer to an anticipated 
question/challenge.

[2] on the other hand, they could justify spending a couple of salaries on 
rooting through the spamtrap because they had once lost 1.5 million dollars on a 
message that was stuck in the spamtrap for about an hour.  If you ever want to 
know why about something, follow the money.

---

From: "Eric Dean" <[email-masked]>
Date: Wed, 14 May 2003 09:18:47 -0400

> other by e-mail without any human interaction.

In fact, we'll have to support both.  Newer software can automate this
process while we'll have to rely on plain old SMTP for legacy use.

---

From: "Eric S. Johansson" <[email-masked]>
Date: Wed, 14 May 2003 11:46:28 -0400

> process while we'll have to rely on plain old SMTP for legacy use.

why differentiate?  Or at least, why differentiate on the basis of target or 
protocol?  You can handle both automated and manual responses in the same 
message without working hard or increasing complexity in the network.

By placing sufficient information for automatic handling in the headers, and 
human oriented information in the body, you can satisfy the demands of both 
automatic handling in human handling in one message.

example: in camram, I include an instance of a stamp with every message.  In 
this message, I will generate two stamps one to asrg and the second one to 
[email-masked].  They look something like to stand generated for an earlier 
posting:

X-Camram: stamp; 0:030514:[email-masked]:c407927fbaad1fa8

In the body of the message is the human oriented material i.e. content for the 
mailing list.  The receiving filter sees the stamp, verifies that it is 
"correct" (i.e. 20 bit string of zeros collision) and that it is addressed for 
the recipient (one type of double spending) with the date that isn't too old 
(second type of double spending).  On receipt of a valid stamp, the filter knows 
to pass the message on to my inbox.  The same model can apply to other forms of 
automated challenge/response.

part of the reason I take this approach is because I realized a while ago that 
e-mail is a two-level protocol.  You have the lower-level transport protocol 
(SMTP) which is content independent.  Then you have the higher level protocol as 
represented by the message format which is instructions given by one e-mail 
client to another.  By modifying the higher level protocol by adding stamps or 
other action triggers, you can improved e-mail system functionality without 
destroying the existing infrastructure.

and yes I will be working on a working draft describing a stamp based protocol 
as soon as I can clear the decks a little bit.

it would help if I could resist answering e-mail... ;-)

---eric

---

From: "Tom Thomson" <[email-masked]>
Date: Wed, 14 May 2003 16:58:46 +0100

> addresses, this makes it easier.

One way it is different - it claims the right to sell your address on
(although that of course is common US practise).  A lot of people willingly
offer terms of use which doesn not give them that right.  If Spam-Arrest
operated in the EU, its operation would be illegal (not the anti-spamming
law, the data protection laws) and I'm not sure that this policy doesn't
make it illegal to make commercial use of their product in most places in
the EU. Maybe they'd better change if they don't want the data protection
squad causing trouble for their customers - it just needs one highly
publicised case to ensure that they never again have a customer in most of
the civilised world.

Tom

---

From: Yakov Shafranovich <[email-masked]>
Date: Wed, 14 May 2003 13:32:34 -0400

>publicised case to ensure that they never again have a customer in most of

The point I was trying to make is that from the technical viewpoint any ISP 
or MTA operator can harvest addresses just like SpamArrest did.

Yakov

---

From: "Eric Dean" <[email-masked]>
Date: Wed, 14 May 2003 14:06:32 -0400

I agree.

> From: [email-masked] [mailto:[email-masked]]On Behalf Of Eric
> S. Johansson
> Sent: Wednesday, May 14, 2003 11:46 AM
> To: Eric Dean
> Cc: [email-masked]
> Subject: Re: [Asrg] C/R Thoughts: Take 1
>
>
> Eric Dean wrote:
>

---

From: "Jon Kyme" <[email-masked]>
Date: Wed, 14 May 2003 22:12:11 +0100

> If Spam-Arrest
> >law, the data protection laws) 

I believe this is correct.

> or MTA operator can harvest addresses just like SpamArrest did.

yes, of course. The point I was trying to make is that these concerns
should perhaps be addressed in any work to produce standards or BCP on C/R

Most MTA operators only keep "traffic data" for a short time. A C/R
operator must keep some traffic data "forever".

The C/R operator can choose from a range of behaviours ... producing a
simple challenge, puffing the challenge up with unsolicited merchandising
material right up to using (or selling) addresses like any other spammer.

Since the Sender address data is longlived, the policy might change -
imagine Mr Nice C/R systems Inc. gets bought up by Black hat Megacorp.

Whatever..

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Wed, 14 May 2003 17:13:01 -0400

> I believe this is correct.

I don't play an EU Data Commissioner on the net, though I have periodically 
spoken at length with several (Berlin chiefly). "Illegal" is not something
I'd buy or sell, however, the retention, recipient, access and possibly a
few other aspects of Spam-Arrest-the-data-collector behavior are, IMO, likely
to be of interest to the DatenSchutz, for any non-sonombulist local value of
DatenSchutz. Anglophones can stick with the UK DP rules.

See the P3P schema, we put all of it there we knew about.

> operator must keep some traffic data "forever".

See <retention>, but see also <purpose> elements in the P3P schema.

Eric

---

From: Dave Crocker <[email-masked]>
Date: Wed, 14 May 2003 14:39:45 -0700

Eric,

ED> If we see a Sender header, we don't return a challenge.
...
ED> They are more than welcome to use Sender headers...messages will sit in
ED> quarantine as do any spam.

Your policy is to interpret the presence of the Sender header as being
"interesting".

However, its presence or absence has nothing to do with anything else
about the message.

Nothing.

Not one thing.

d/

---

From: "Eric Dean" <[email-masked]>
Date: Wed, 14 May 2003 21:02:12 -0400

ok..very nice..so what do you propose for list detection?

> From: Dave Crocker [mailto:[email-masked]]
> Sent: Wednesday, May 14, 2003 5:40 PM
> To: Eric Dean
> Cc: [email-masked]
> Subject: Re: [Asrg] C/R - What people say
> 
> 
> Eric,
> 
>

---

From: "Eric Dean" <[email-masked]>
Date: Wed, 14 May 2003 22:23:41 -0400

Attached, you'll find a proposed framework I have put together for a C/R
discussion.  Please excuse the formating..I'll groff it soon..assuming it
lives.

I have attempted to capture some of the key areas and concerns that have
been discussed over the past couple of weeks as well as incorporate some of
my own ideas.  My intent is to throw something down on the table that's at
least wrong and allow for an exchange of ideas regarding how to proceed if
at all.

---

From: Vernon Schryver <[email-masked]>
Date: Wed, 14 May 2003 20:42:56 -0600 (MDT)

"Dave Crocker" <[email-masked]>

> > However, its presence or absence has nothing to do with anything else

I think that's an overstatement or beside the point.  While according
to standards theory, Sender: headers may have nothing to do with
whether the message is bulk, practice may differ.  I'd want to look
at a few 1,000,000 private messages in a variety of locations and
check the behavior of a bunch of MTAs and MUAs before guessing whether
in practice "Sender" headers indicate "bulk."

> ok..very nice..so what do you propose for list detection?

It's not Dave Crocker's fault that Sender headers do not necessarily
indcate "bulk," and neither is it his responsibility to find a solution
to your problem if they don't.  You could but don't absolutely need to
thank him for pointing out a hole.  You certainly should not snarl.
In your position, I'd hope to offer evidence showing that in practice
Sender: headers do work or some (real, not invented) words in an RFC
showing that Dave Crocker is mistaken.  Failing that, I'd probably
fall back on "well, C/R isn't perfect, but it's good enough to help"
(if that were my opinion, which it isn't).

Contrary to other contributors to this mailing list, pointing out that
an anti-spam mechanism cannot possibly work according to its specifications
not only is not a bad thing, but entirely constructive.  In the real
world outside sports bars, chatrooms, and netnews, the purpose of
proposing a mechanism is not some sort of chest thumping proof of
manhood.  Playing the Cliff The Mailman characer from the old "Cheers"
TV-sitcom gains no points here.  The only appropriate response to a
claim that one's proposed mechanism has a hole is changing the proposal
to close the hole or offering proof that the hole does not exist or
does not matter in practice.  And that proof has nothing to do with
indignant remarks about one's supposed enormous experience and insight,
physics or math education, or friends who were once in high places.

---

From: Yakov Shafranovich <[email-masked]>
Date: Thu, 15 May 2003 01:22:32 -0400

Just wanted to mention a few statistical facts I got from someone over at 
MailCircuit (they have been running a C/R system for sometime):

1. Server loads are increased by almost 50% when the verification system is 
implemented.
2. Number of spammers that have been reported verifying themselves has only 
been 4 in the past 2 years.
3. We weed out approximately 12% of spammers thru reverse DNS.

I think the first factor would be a major issue with all C/R systems and is 
something we should take into account.

---

From: Dave Crocker <[email-masked]>
Date: Wed, 14 May 2003 22:37:13 -0700

Vernon,

VS> I think that's an overstatement or beside the point.  While according
VS> to standards theory, Sender: headers may have nothing to do with
VS> whether the message is bulk, practice may differ.  I'd want to look
VS> at a few 1,000,000 private messages in a variety of locations and
VS> check the behavior of a bunch of MTAs and MUAs before guessing whether
VS> in practice "Sender" headers indicate "bulk."

a reasonable,empirical approach.  my assessment was based on knowing
that all sorts of different software sets the sender field, often quite
unecessarily.  on the other hand, there is no rule against setting it
unecessarily (that is, when it is wholly redundant with the From field)
and email users agents often do.

>> ok..very nice..so what do you propose for list detection?

VS> It's not Dave Crocker's fault that Sender headers do not necessarily
VS> indcate "bulk," and neither is it his responsibility to find a solution
VS> to your problem if they don't.  You could but don't absolutely need to
VS> thank him for pointing out a hole.

There are some explicit conventions involving mailing lists, though
conformance is extremely spotty.  As a simple example of headers that
are explicitly and exclusively used for mailing headers, folks might
want to look at the headers that are attached by the list mailer for
this very list...

d/

---

From: "Jon Kyme" <[email-masked]>
Date: Thu, 15 May 2003 10:59:44 +0100

> of
> My intent is to throw something down on the table that's at
<quote>
Privacy
Concerns exist regarding data collection of correspondences between certain
senders and recipients however such information is available in most
mailing systems
</quote>

Well, that's just a red rag to *some* bulls :-)

I don't think that asserting that the same concerns apply to *other*
systems
adequately addresses concerns applying to *these* systems. Plus also - it's
not strictly true, since the *necessarily* long life of this data in a C/R
system has implications.

Another thing, may be I misread the text, but I can't see how (if multiple)
 X-CM-Recipient / X-CM-URI header pairs are kept together. 

Do you really need two headers? couldn't all this data be parameters in one
header? Or have I really missed the point?

---

From: "Eric Dean" <[email-masked]>
Date: Thu, 15 May 2003 09:30:42 -0400

> not strictly true, since the *necessarily* long life of this data in a C/R

Yeah..that was just a placheolder...however, my thinking is that we should
be addressing the protocol..not how some systems implement persistent data.
For example, some systems may not use C/R to build whitelists.  Some may
just challenge very message..it would be stupid..but they could.  Within
client email software,, the C/R mechansim would have much less privacy
concerns.  So, I'm trying to divorce myself from implementations but rather
focus on seucrity implications of the protocol itself...could be wrong about
that..but that was my thinking.

>  X-CM-Recipient / X-CM-URI header pairs are kept together.

They would be subsequent line items within the header file.

> header? Or have I really missed the point?

You have a point.  They very well could be a single line.  The thing to
consider is a case whereby I send a message to 20 recipients in a company.
Each one of those recipients will challenge me with a unique authenticator.
So, the recipients should be listed individually...whether we can use a
delimeter with the authenticator following..might be a better method.

---

From: "Eric Dean" <[email-masked]>
Date: Thu, 15 May 2003 09:38:33 -0400

> in practice "Sender" headers indicate "bulk."

Considering that we are a research group and not a standard's group, that
would be an excellent approach.  We've found that the Sender header works in
many cases but many people pointed out additional methods...this isn't a
trivial issue.

> to your problem if they don't.

>  You could but don't absolutely need to
> thank him for pointing out a hole.

Thanks Dave

> You certainly should not snarl.

Indeed...I did snarl as I wrote that response.

> (if that were my opinion, which it isn't).

Well, I believe there is more work to be done in this area.  We use Sender
but it appears that many other mechanisms are available..yet nothing
standard.

---

From: "Eric Dean" <[email-masked]>
Date: Thu, 15 May 2003 09:41:25 -0400

> want to look at the headers that are attached by the list mailer for

ok..well should we try to identify those methods, or should we just say
"don't challenge lists"?

---

From: "Jon Kyme" <[email-masked]>
Date: Thu, 15 May 2003 15:31:54 +0100

> delimeter with the authenticator following..might be a better method.
like:
X-something: recipient-1 ; auth-string-1
X-something: recipient-2 ; auth-string-2
etc...

Regarding the length of the authentication string, is there an issue with
header line length?

---

From: Vernon Schryver <[email-masked]>
Date: Thu, 15 May 2003 08:39:29 -0600 (MDT)

> ok..well should we try to identify those methods, or should we just say

If I were in your position, I'd write "trying not to challenge
lists by not challenging messages with any of the following 37
characteristics..."

---

From: "Eric Dean" <[email-masked]>
Date: Thu, 15 May 2003 10:59:55 -0400

Hell..there's some ridiculously long email addresses out there too.

> From: Jon Kyme [mailto:[email-masked]]
> Sent: Thursday, May 15, 2003 10:32 AM
> To: Eric Dean
> Cc: ASRG
> Subject: Re: RE: [Asrg] C/R Framework
> 
>

---

From: Yakov Shafranovich <[email-masked]>
Date: Thu, 15 May 2003 11:47:39 -0400

>Regarding the length of the authentication string, is there an issue with

We can fold the headers onto extra lines  - see section 2.2.3 of RFC 2822:

---snip----

2.2.3. Long Header Fields

    Each header field is logically a single line of characters comprising
    the field name, the colon, and the field body.  For convenience
    however, and to deal with the 998/78 character limitations per line,
    the field body portion of a header field can be split into a multiple
    line representation; this is called "folding".  The general rule is
    that wherever this standard allows for folding white space (not
    simply WSP characters), a CRLF may be inserted before any WSP.  For
    example, the header field:
            Subject: This is a test
    can be represented as:
            Subject: This
             is a test
    Note: Though structured field bodies are defined in such a way that
    folding can take place between many of the lexical tokens (and even
    within some of the lexical tokens), folding SHOULD be limited to
    placing the CRLF at higher-level syntactic breaks.  For instance, if
    a field body is defined as comma-separated values, it is recommended
    that folding occur after the comma separating the structured items in
    preference to other places where the field could be folded, even if
    it is allowed elsewhere.
    The process of moving from this folded multiple-line representation
    of a header field to its single line representation is called
    "unfolding". Unfolding is accomplished by simply removing any CRLF
    that is immediately followed by WSP.  Each header field should be
    treated in its unfolded form for further syntactic and semantic
    evaluation."

---

From: Yakov Shafranovich <[email-masked]>
Date: Thu, 15 May 2003 11:49:33 -0400

>least wrong and allow for an exchange of ideas regarding how to proceed if

Below is a copy of some of the comments on this proposal that I previously 
emailed to Eric. He agreed that they should be posted to the entire list.

--------------------------------

>Abstract
>RFC821 was not designed to authenticate sources or senders of email 
>messages.  In an effort to reduce spam on the Internet, this document 
>defines a method by which email senders may be authenticated and 
>determined if that sender originated a message to a designated recipient.

In the purposes section, we state that this is "-Not an authentication 
method for email delivery or security protocol". Is our intent to make sure 
that the sender's email address is valid but not to authenticate the actual 
identity of the sender? I am not readily understanding the different 
between this statement and the conflicting statement in the purposes 
section. Is making sure that the original sender exists called 
"authentication" or perhaps a different term should be used?

Also, I came across an interesting quote in section 7.1 of RFC 2821:

    "Efforts to make it more difficult for users to set envelope return
    path and header "From" fields to point to valid addresses other than
    their own are largely misguided: they frustrate legitimate
    applications in which mail is sent by one user on behalf of another
    or in which error (or normal) replies should be directed to a special
    address.  (Systems that provide convenient ways for users to alter
    these fields on a per-message basis should attempt to establish a
    primary and permanent mailbox address for the user so that Sender
    fields within the message data can be generated sensibly.)
    This specification does not further address the authentication issues
    associated with SMTP other than to advocate that useful functionality
    not be disabled in the hope of providing some small margin of
    protection against an ignorant user who is trying to fake mail."

>   This document proposes the use of MIME experimental content-type values 
> for automated C/R control.

We need to define more precisely exactly which header we are using. We ARE 
NOT using the "Message-Context" defined in RFC3458 since that is 
presentation logic, and not the "Content Disposition" header either (RFC 
2183) for the same reason. So are we using the "Content-Type:" header 
defined in RFC 2045? If so should we be suggesting a custom type starting 
with "X-" or should we specify a new type: probably something like 
"message/challenge" (see 
http://www.iana.org/assignments/media-types/message/ for current 
assignments in the "message" category)? The "message" type is defined in 
RFC 2046.

In general the purpose of MIME as outline in RFC 2045 is:

"This set of documents, collectively called the Multipurpose Internet Mail 
Extensions, or MIME, redefines the format of messages to allow for
     (1)   textual message bodies in character sets other than US-ASCII,
     (2)   an extensible set of different formats for non-textual message 
bodies,
     (3)   multi-part message bodies, and
     (4)   textual header information in character sets other than US-ASCII."

All of these do not apply in our case, all of our information is stored in 
headers only (for the automatic protocol, the manual protocol includes 
links in the message body. Headers are defined in sections 2.1 and 2.2 of 
RFC 2822 and we must decide if we are going to define standard headers or 
extension headers ("CM: or X-CM"). If we are using custom headers, then 
reference to sections 4.7.4 and 4.7.5 of RFC 822 should be made.

>   In addition, this document proposes a manual C/R method that interworks 
> with existing mail systems and clients.

Its more like guidelines then a method. We cannot enforce implementation 
details.

>Introduction
>This document identifies a MIME experimental content-type that may be used 
>by a message as well as a user interaction method for authenticating 
>sender identity and determining whether a sender originated a message to a 
>recipient.

Same as above - we need to define more precisely - are we using a MIME 
type, custom headers, etc. And we are not giving a method, just suggesting 
some guidelines. Do we authenticate or determine sender - we need a better 
definition here.

>   A Challenge/Response system can be used to determine whether a sender 
> exists and whether that sender intended to send a message to a designated 
> recipient.

We need a more clear view - there are two things being defined in this 
document - one is an automated protocol for machines and two - a set of 
guidelines for manual systems. An automated protocol will only allow 
machines to check is the sender exists, whether he wanted to send a message 
or not, is not really for us to decide unless you intend on using the 
"X-CM-Recipient:" header field for that purpose. However in that case the 
sender's system would have to keep track of all the people he sent mail to 
and then check that against the "X-CM-Recipient:" field in the challenged. 
I do not know if this should part of the protocol - may be more of an 
optional feature.

>  A C/R system or client software supporting the C/R MIME experimental 
> content-type values would have the option of automatically responding to 
> the challenge message or forwarding to the original sender to perform the 
> action.

What does "forwarding" to original sender mean? That only applies to the 
case of an MTA doing handling the C/R, not the user client. We need to make 
this paragraph more clear - a system or MTA would have such option, the 
client software would either responde automatically or do nothing.

>  This document identifies the C/R MIME experimental content-type values 
> for possible automated C/R systems as well as provides guidelines for a 
> manual user C/R method.

Good, we probably should split the document into two parts -one to 
automatic protocol and second for manual guidelines.

>Purposes
>-Used to dynamically build user whitelists.  In some implementations, the 
>C/R system is used to determine is a sender is real and allow for that 
>sender to verify that he intended to send a message to the 
>recipient.  Upon responding to the challenge, the sender will then get 
>added to the user's personal whitelist.

Again - sender being real and sender sending the message are different 
goals. We need to make that more clear. And also, "some implementations"? I 
am not getting that - aren't we defining guidelines for all implementation. 
Rather we should list required features and optional features of the protocol.

>-Reduce spam from spoofed senders.  In the event that a challenge message 
>is without an response for an extended period of time,
>-Reduce spam from invalid senders.  In the event that a challenge message 
>rejects or bounces via one or more SMTP errors, some C/R implementations 
>will automatically drop the message.

We should move the implementation details from the purposes section - 
things like "what C/R system does in case A", are not a purpose - they are 
the solution.

>-Not an authentication method for email delivery or security protocol

As mentioned above, we need to clarify this.

>Challenge Response Model
>The C/R model is based upon an approach whereby a sender sends a message 
>to a recipient's SMTP server.  The recipient's  SMTP server either 
>produces a challenge message or forwards the original message to a 
>recipient's client system that produces a challenge message. The resulting 
>challenge message is sent to the original sender.

Perhaps we should check if the original's sender's domain actually exists, 
before sending the message? Also, if that happens do we drop the message 
automatically?

>   If the sender's C/R SMTP server supports C/R methods, then the original 
> sender's SMTP server may automatically respond to the challenge request.

This line bothers me - restricting to SMTP. Who will implement 
challenge/response - the incoming SMTP server or system that is actually 
storing the mail? The incoming SMTP server might not possess a list of all 
the recipients and may not be able to automatically decide if the " 
X-CM-Recipient" matches someone that the sender sent mail to (if we are 
doing that).

>   Otherwise, the original sender's server should forward the message to 
> the original sender.  If the original sender's client system supports C/R 
> methods, then the original sender's client software may automatically 
> respond to the challenge message.  In the event that neither the server 
> nor client software are C/R compatible, the C/R message should contain 
> clear instructions to the original sender describing how to appropriately 
> respond to the challenge request.

Good.

>-------------------------------------------------------------
>
>
>        ----------------------------------------
>        |                                       |
>        |                                       v
>        v       +----------+                +----------+
>    +------+    |          |                |          |    +------+
>    | User |<-->|          |       C/R      |          |<-->| User |
>    +------+    |  Sender- |Commands/Replies| Receiver-|    +------+
>    +------+    |SMTP/HTTP |<-------------->|SMTP/HTTP |    +------+
>    |Client|<-->|          |                |          |<-->|Client|
>    |System|    |          |                |          |    |System|
>    +------+    +----------+                +----------+    +------+
>
>
>                 Sender-SMTP                Receiver-SMTP
>
>                            Model for C/R Use
>
>                                 Figure 1
>
>      -------------------------------------------------------------
>
>
>Challenge Message
>The Challenge Message should contain both the MIME experimental 
>content-type values defined herein.  The following MIME experimental 
>content-type values are required for C/R interoperability:
>X-CM-Recipient: - This C/R header should identify the original recipient 
>of the message that is issuing the challenge.

What format, is this in a standard email address format? Then the relevant 
section of RFC 822 or 2822 should be referenced here.

>X-CM-URI: - This C/R header identifies an authentication string unique to 
>that sender-recipient pair that ensures that the challenge response is 
>from the original sender.

What format? Is this simply a URI? or some kind of code? Or implementation 
specific? Should we be naming it "URI" if it is not.

>If an original sender sends to multiple recipients on the same C/R server, 
>then the server can issue the challenge message with each X-CM-Recipient 
>listed with corresponding URIs.
>
>The sender of the C/R message must be a valid sender address.  In the 
>event that a server-based mail system is performing C/R, then the 
>challenge should be sent with an email address local to that server.  If 
>multiple servers are used, then the Challenge Message can be forwarded to 
>peer servers if other synchronization mechanisms are not in place.
>
>If client software is performing the C/R, then the challenge should be 
>sent with an email address local to that email client.  If neither the 
>original sender's server or client software support C/R interoperability, 
>then the challenge message should contain as well as a message that 
>clearly instructs the user how to perform a manual challenge 
>response.  Typically, clicking on an embedded HREF or a simple reply-to is 
>sufficient for the original sender to manually reply.

The reply-to ability MUST BE present - not everyone who has email, 
necessarily has HTTP. Also, for the same reason, the challenge message 
should not be MIME encoded, or in some form of HTML format - just simple text.

As someone mentioned on the mailing list, there should be an email address 
of the recipient's administrator included just in case. That address SHOULD 
NOT issue challenges. Perhaps we also need a custom header or use a 
standard one defined somewhere like "Errors-To" for this.

>Challenge Response
>For C/R compatible systems that support the MIME experimental content-type 
>values, the challenge response mechanism could be automated.  The 
>following MIME experimental content-type values are required for C/R 
>interoperability:
>
>X-CR-URI: V=X-CM-URI  This C/R header is sent to the originating C/R 
>system to validate that the original sender had sent a message to the 
>X-CM-Recipient.  The X-CM-URI authentication string that was supplied with 
>the challenge message is sent along with a key "V=" to signify that the 
>original sender is intending on delivering a message to the recipient.
>X-CR-URI: U=X-CM-URI  This C/R header is sent to the originating C/R 
>system to invalidate that the original sender had sent a message to the 
>X-CM-Recipient.  The X-CM-URI authentication string that was supplied with 
>the challenge message is sent along with a key "U=" to signify that the 
>original sender did not intend to deliver a message to the recipient.

What's V and U stand for? We need to rethink this a bit - maybe we should 
have "X-CR-Challenge" and "X-CR-Response" fields? The sender will add the 
response field. Should there be a standard token format? What about 
possible support for hashcash type systems via these tokens?

>Mail Lists
>Proper identification and handling of user subscribed mailing lists is 
>essential for C/R deployment.  While no standard exists for identifying 
>lists, many common methods include using the following headers:
>
>"sender:",
>"X-BeenThere:",
>"mailing-list:",
>"list-help:",
>"list-unsubscribe:",
>"precedence: bulk",
>"precedence: list",

More research into this is needed, I think some RFCs provide guidelines on 
this.

>Challenge messages should not be sent to mailing lists.

Why not? If we have an automated protocol and the mailing list supports 
C/R, then it should be able to detect the incoming challenge. This is not 
so simple, we need more work on this.

>Loop avoidance
>C/R systems should use a local address on the C/R system or an actual 
>email address within client software.  In either case, the C/R system 
>should remain stateful in monitoring outstanding Challenge Messages and 
>should not continue issuing challenge messages when an existing request is 
>outstanding.  Additional methods used for double-bounces and vacation 
>responders would also be appropriate.

Perhaps using "X-Been-There" header or something like that. This is also 
interesting - section 6.2 of RFC 2821:

"6.2 Loop Detection.

    Simple counting of the number of "Received:" headers in a message has
    proven to be an effective, although rarely optimal, method of
    detecting loops in mail systems.  SMTP servers using this technique
    SHOULD use a large rejection threshold, normally at least 100
    Received entries.  Whatever mechanisms are used, servers MUST contain
    provisions for detecting and stopping trivial loops."

>Security
>URI length to prevent brute force attacks

Also how to prevent spammers from spoofing an address on the white list. If 
the sender checks the "X-CR-Receipient" field against the list of people he 
sent email to, that might be avoided.

>-Data Collection

There are plenty of messages on that in the list. Legal issues must be left 
aside, although we may mention them. Like I mentioned perhaps some form of 
a checksum should be used, to avoid storing real email addresses in the 
database. Also, perhaps the "X-CR-Recipient" header above should be a 
checksum (MD5?) instead of the real email address.

>References
>
>    [RFC-821] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC
>    821, USC/Information Sciences Institute, August 1982.
>
>    [RFC-822] Crocker, D., "Standard for the Format of ARPA Internet Text
>    Messages", STD 11, RFC 822, UDEL, August 1982.

These were supplemented by RFCs 2821 and 2822.

>    [RFC-934] Rose, M., and E. Stefferud, "Proposed Standard for Message
>    Encapsulation", RFC 934, Delaware and NMA, January 1985.

What are we getting from RFC-934 or is this is here just in case for the 
future?

>    [RFC-1049] Sirbu, M., "Content-Type Header Field for Internet
>    Messages", STD 11, RFC 1049, CMU, March 1988.
>
>    [RFC-1341] Borenstein, N., and N. Freed, "MIME (Multipurpose Internet
>    Mail Extensions): Mechanisms for Specifying and Describing the Format
>    of Internet Message Bodies", RFC 1341, Bellcore, Innosoft, June 1992.

These was obsoleted by RFC 1521, which in turn was obsoleted by RFC 2045 
which I think is current. We should probably reference the most recent one. 
Also take a look at the whole MIME series of RFCs: 2045 through 2049 (2047 
is not relevant to us, it deals with non-ASCII text,

>    [RFC-1344] Borenstein, N., "Implications of MIME for Internet
>    Mail Gateways", RFC 1344, Bellcore, June 1992.

---

From: Yakov Shafranovich <[email-masked]>
Date: Thu, 15 May 2003 11:53:08 -0400

>ok..well should we try to identify those methods, or should we just say

If an automated protocol for C/R is in place, why shouldn't we challenge 
lists? If the list software supports the protocol, it will response to the 
challenge automatically. However, this perhaps is needed for dealing with 
list software that does not support it but this should be made more clear.

---

From: Yakov Shafranovich <[email-masked]>
Date: Thu, 15 May 2003 11:55:32 -0400

>not strictly true, since the *necessarily* long life of this data in a C/R

There are several privacy concerns - the whitelist primarily. Also, if the 
challenge message contains the receivers email address that might be a 
problem too. As I mentioned before, perhaps we should not store plain email 
addresses - but some form of checksum or something. Even though that is 
susceptible to dictionary attacks, the attacker must know what he is 
looking for. This will at least protect against people snooping at messages.

---

From: "Jon Kyme" <[email-masked]>
Date: Thu, 15 May 2003 17:00:09 +0100

> We can fold the headers onto extra lines - see section 2.2.3 of RFC 2822:

Yes, I've read that... are we expecting much whitespace inside the
authentication string?

---

From: Yakov Shafranovich <[email-masked]>
Date: Thu, 15 May 2003 12:00:47 -0400

>that..but that was my thinking.

If you mandate the use of an MD5 checksum in the X-CM-Receipient field or 
some similar mechanism instead of a plain email address, this might reduce 
the problem.

---

From: "Jon Kyme" <[email-masked]>
Date: Thu, 15 May 2003 17:05:57 +0100

> looking for. This will at least protect against people snooping at

I don't think it's necc. to specify what steps an implementer needs to take
to protect/hide the data - just an recommendation that they should take
steps is probably enough. Maybe?

---

From: Yakov Shafranovich <[email-masked]>
Date: Thu, 15 May 2003 12:08:18 -0400

>steps is probably enough. Maybe?

In order to different C/R systems to interoperate they must know whether a 
plain email address is used or a checksum - leaving this to implementors 
will kill interoperability. Perhaps this should be an optional feature of 
the protocol?

---

From: Yakov Shafranovich <[email-masked]>
Date: Thu, 15 May 2003 12:09:17 -0400

>Yes, I've read that... are we expecting much whitespace inside the

Even if there is whitespace within the authentication string, which I am 
not expecting really - we can still work around it. We'll provide some 
guidelines based on RFC 2822.

Yakov

---

From: "Jon Kyme" <[email-masked]>
Date: Thu, 15 May 2003 19:49:48 +0100

> will kill interoperability. Perhaps this should be an optional feature of

I think you'll find the point raised was regarding stored data.

---

From: "Jon Kyme" <[email-masked]>
Date: Thu, 15 May 2003 19:54:18 +0100

> guidelines based on RFC 2822.

I look forward to that.

---

From: Vernon Schryver <[email-masked]>
Date: Thu, 15 May 2003 14:59:53 -0600 (MDT)

> challenge automatically. ...

Is that a joke?   I guess not.

What is the real goal a C/R system?  I thought it had something to do
with reducing "spam."  How does spam differ from any other bulk mail
except in whether it is solicited?

As I've pointed out, a substantal amount of the unsolicited bulk
mail in my traps has headers just like mail from other "lists"
including this one.

If a C/R system only stops spam from transient, "hit-and-run" systems
that do not stand still long enough to receive and answer a challenge,
it won't be very impressive.

---

From: Daniel Feenberg <[email-masked]>
Date: Thu, 15 May 2003 18:14:07 -0400 (EDT)

> it won't be very impressive.

I was hoping someone would bring this up. I didn't because it seemed like
I was missing something. Did I also miss the discussion of how two C/R
systems would interact if both sender and receiver have them? This must
have come up in real life - do the users of these systems have experience
to relate? 

I would have thought the role of standardization in the C/R system would
not be to standardize the challenge, which needs to be non-standardized so
that automated systems can't respond effectively, but rather to provide an
effective route around the C/R system for legitimate lists. 

For example, if a program running on the user's machine could handle the
subscription request, and simultaneously put the necessary information
about the list in the user's own whitelist, that would be helpfull.
Standardization would be usefull to allow a single program on the user's
machine to interact with many different list processors. I imagine a
program that would be called by the browser when the user visited a
list-subscribe web page that would send the list the user's email address,
and obtain and store the list name and IP address from which that list
will be sent. There should also be a way for the sending IP to be changed
with limited or no user intervention.

I note that a secure Java applet can't be asked to write in the whitelist
file (that wouldn't be secure) so that the program imagined here would
have to be part of the user's computer before the list-subscription page
was visited. The IP address of the sending machine is used so that a
spammer can't just adopt the name of a popular list and hide behind it.
There must be many other ways to accomplish that, though.

---

From: Yakov Shafranovich <[email-masked]>
Date: Thu, 15 May 2003 18:52:15 -0400

>except in whether it is solicited?

Actually its not a joke. As outlined in the Eric's C/R draft:

"This document proposes the use of MIME experimental content-type values 
for automated C/R control at either the server or client software 
level.  In addition, this document proposes a C/R method that requires user 
manual intervention with existing mail systems and clients that may not be 
compatible with automated C/R methods."

There are two separate things here - an automated protocol and some 
guidelines. The primary intent of C/R is to make sure that email comes from 
a valid email address. As pointed out prior on the list 
(https://www1.ietf.org/mail-archive/working-groups/asrg/current/msg04700.html):

 >>"What is the intent of a C/R system? Is it merely to double-check the 
sender's email address to make sure it is working and valid, or >>is it 
also to make sure that the sender is a human being and not a computer? If 
it is only the first, that we are trying to make sure >>that the sender has 
a valid email address, then it might make sense to develop an automated C/R 
protocol that can be used by email >>clients and senders' MTAs to reply to 
the challenge. This will take care of issues like dealing with lists, 
automated bots and >>anonymous remailers - the list server will simply 
reply to the response via this automated protocol. It will also hide the 
C/R process >>from users. The obvious flaw is that the spammer will use it 
too - but they will have to use a valid email address to do it, or own 
their >>own MTA and domain (which is not a problem since we already see 
spammers owning name servers). However, if the intent of C/R >>systems is 
to make sure that the sender is human, than it essentially must perform a 
Turing test. Current techniques include using >>specially coded graphic 
images, etc."

Making Turing tests would be highly impractical. Even now, TDMA and 
MailCircuit systems do not use them, instead a simple reply to any 
challenge message will verify the sender. However, in the last two years 
according to MailCircuit only 4 spammers did so.

Yakov

---

From: Yakov Shafranovich <[email-masked]>
Date: Thu, 15 May 2003 19:48:50 -0400

>effective route around the C/R system for legitimate lists.

At this point, as outlined, Eric is proposing an automated protocol for C/R 
not for internal use but for actually responding to challenges 
automatically. As I mentioned before, we need to better define the goals of 
C/R. Is is to make sure that senders are legit, or is it going to an extra 
level to making sure the sender is human (essentially creating a Turing 
Test). As for having spammers set up automatic responders, see TDMA FAQ, 
section 1.1 (http://tmda.net/faq.cgi?req=all):

------snip--------
"1.1. Can't spammers just setup an auto-responder to defeat TMDA? *

In theory yes, but in practice this is not likely to happen. Most SPAM is 
unrepliable, so TMDA's confirmation requests are never delivered to them. 
They use non-valid return addresses as to not incur the cost of the 
tremendous number of bounces they generate. Using a valid return address to 
process all the bounces looking for confirmation messages to auto-reply to 
would defeat their economies of scale. It would also make them easy to 
block, track down and report, sue, etc. In short, trying to thwart TMDA in 
this manner would defeat the cost-effectiveness of the bulk-mailing 
process. Simple economics keep us safe.

But should these facts change, TMDA could modify its (currently very 
simple) challenge/response to make it more difficult for a computer to 
auto-reply to. The level of difficulty could increase as much as is 
necessary for the sender to prove their humanity and legitimacy.

The idea is to keep the challenge/response as simple as possible to avoid 
inconveniencing legitimate senders, while at the same time difficult enough 
to thwart an automated response system. At the present time, TMDA offers 
the ability to confirm by a simple e-mail reply, or by clicking on a URL. 
There is no evidence to suggest that a more challenging procedure is even 
close to necessary.

If spammers do resort to auto-confirmation however, we've won a huge battle 
for the community by raising the bar and forcing them to leave a breadcrumb 
trail leading back to their lair. As the focus on legislation continues, 
and spamming becomes an increasingly illegal activity, who will take these 
great risks for such a little reward? "
-----snip--------

Perhaps the primary purpose of C/R should be counteracting the basic flaw 
in SMTP that allows anyone to send email without verifying who the sender 
is? Or perhaps not? Disabling the ability for automated systems to be able 
to send email is something we might not want to do. There are also various 
other issues, such as the ones raised in section 7.1 of RFC 2821 which as 
we mentioned apply to mailing lists.

Yakov

---

From: mathew <[email-masked]>
Date: Thu, 15 May 2003 21:09:45 -0400

On Tuesday, May 13, 2003, at 22:52 US/Eastern, Eric Dean wrote:
> Just simply look for the Sender header..if it's present then we don't 
> send a challenge...the user must verify the sender.

Well, I guess on the plus side, that means I'll never get stupid 
challenge spam from your system...

mathew

---

From: mathew <[email-masked]>
Date: Thu, 15 May 2003 21:35:27 -0400

> mail in my traps has headers just like mail from other "lists"

Indeed, mailing lists run by idiots are a major source of spam. I've 
lost count of the number of times I've been subscribed to a mailing 
list without asking, often a mailing list I've never even heard of. I 
get subscribed to lists that anyone who knows me would *instantly* know 
I would never be interested in. (Most recent example: Christian 
bookstore.)

Some people have even been stupid enough to subscribe me to discussion 
lists without asking me. I try to make sure they regret it.

mathew

---

From: Kee Hinckley <[email-masked]>
Date: Fri, 16 May 2003 20:07:10 -0400

>subject header be sent.  C/R systems might avoid C/R loops using a

Having recently tried to communicate with a customer who is using 
SpamArrest, I have a strong opinion there.  You *must* preserve the 
subject.  SpamArrest almost gets it right.

1. Customer sends mail to our support staff.
2. Our support system replies, with a ticket in the subject.
3. SpamArrest replies with the ticket in the subject.
4. The SpamArrest message gets properly placed in the correct support queue.
5. Support person clicks on link.
6. Customer gets our auto-reply.
[Here's where they blow it]
7. SpamArrest sends a confirmation message telling us that the 
message got through.  It doesn't have the same subject.  It doesn't 
even have any information in the body telling us *which* message go 
through.  (Frankly, this "confirmation" message looks a lot more like 
an Ad to me than anything else.  There was no need for it--I got the 
same information when I clicked on their web site.)
8. We create a new ticket and send an auto-reply.  *This* one goes to 
SpamArrest's support, since that was the from address.
9. SpamArrest support sends us a challenge.
10. The challenge goes into the new queue.
11. Our support person clicks on the link to validate the message.
12. SpamArrest support gets our message.
13. Our support person sends them a nasty-gram :-).

Needless to say, this increases the cost of our customer support.

 From it, I get the following feelings.

1. C/R systems should preserve subjects through the process.  They 
can add to them if they want, but the original should be there.
2. C/R systems need to have a standard way of identifying themselves 
as such.  This avoids loops, and it let's us shunt them into an 
appropriate handling queue.
3. As I've said before--any system that requires you to do something 
other than just reply (e.g. read a graphic) needs to meet 
accessibility standards.
4. If you have a web based confirmation system, you should also have 
an email-based one.  The fact that I can send you email does not mean 
that I can access your web site.  (Think China, think road-warrier, 
think third world.)
-- 
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
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Kee Hinckley <[email-masked]>
Date: Fri, 16 May 2003 20:44:36 -0400

I confess I've been playing catch-up, so I may have missed this 
(although I'll put in a plug here for Eudora 6 Beta's ability to 
present a summary of a conversation with all the quoted text 
elided--incredibly useful).

I've seen two issues going by on C/R.  One is where the response goes 
(normal email reply, or delivery notification reply).  And the other 
is dealing with mailing lists.

My gut says that C/R is a delivery notification.  But the problem is 
more complicated.

I'm not so worried about mailing lists.  What worries me is what 
happens when Amazon sends me an out-of-stock notice and I send a C/R 
to the envelope from.  What are the odds that it's going to be 
treated as a bounce, and I get taken off their list?

Commercial "transactional" email worries me more than mailing lists. 
It's not just that the mail's more critical, but updating it to some 
new standard is harder.  Those systems are largely homegrown, whereas 
lists tend to use standard software and/or services.  Lists are 
easier to change to a new standard.

Thoughts?

---

From: Vernon Schryver <[email-masked]>
Date: Sat, 17 May 2003 09:39:48 -0600 (MDT)

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

> treated as a bounce, and I get taken off their list?

From what list would Amazon remove your address?  Why would they do
anything but ignore an apparent bounce or an SMTP rejection status
for an out-of-stock, shipping, or other routine transaction notice?

On the other hand, if mailing list software recognizes a challenge at
all, you must expect it to be treated like a non-delivery notice.
There are too many idiosyncratic, "nationalized," customized, and
"improved" forms of bounces for mailing list software to do anything
else for the foreseeable future.

> easier to change to a new standard.

I think that's backwards.  Those largely homegrown transactional
systems have paid tenders who continually maintain it.  While mailing
list software is usually installed by people who barely (if at all)
read the manual and forgotten.  You might change next versions of the
most 3 most common mailing list packages, but that won't get them
installed.  Even people who read the manuals are reluctant to touch
working software.

For example, I'm using version 2.0.5 of Mailman.  It is distinctly
older than the current 2.0 version, not to mention the current 2.1
version.  (See http://ftp.gnu.org/gnu/mailman/ ) I'm reluctant to
switch to because I'd lose or have to port some of the tweaks I've
made, and because I'd have to worry about new problems.  Before worrying
about Mailman, I should deal with a bunch of other things.  I'm probably
unusual because I not only read the documentation, but spent time
trying to understand some of the code and even checked some of the
release notices of new versions to see if I'm wrong.  Most users of
Mailman probably have no idea how many new releases they've ignored.
Like me, but unlike those transactional system tenders, they have more
urgent business.

---

From: Kee Hinckley <[email-masked]>
Date: Sun, 18 May 2003 02:04:14 -0400

>for an out-of-stock, shipping, or other routine transaction notice?

I would hope that after some number of bounces a vendor would stop 
sending email to that account, and at the very least, flag it for 
attention of the user the next time they log in.  In an ideal world 
they'd send periodic confirmation requests--but they don't.

Does anyone have any facts there?  I know that some sites ignore 
them--I can offer easy proof of that in my bounce lists.  But is that 
standard practice?  Can any of the C/R folks give their experiences?
-- 
Kee Hinckley
http://www.messagefire.com/          Junk-Free Email Filtering
http://commons.somewhere.com/buzz/   Writings on Technology and Society

---

From: "Eric Dean" <[email-masked]>
Date: Sun, 18 May 2003 10:34:06 -0400

> can add to them if they want, but the original should be there.

I'm not sure that they should..and not sure they shouldn't.  It should be a
configuration option by the administrator to preserve the subject or
originate a new one.  Such a method would be implementation-specific and not
determined by a standard if mentioned at all.

> appropriate handling queue.

Yes, if a message has the C/R headers..it shouldn't be challenged.  Only
challenge messages should use C/R headers.  We've discussed the issue
regarding spammers using them...not using them.  The other recommendation is
that the system be stateful and not constantly return the challenge
messages.  If you send my demo account 20 messages, you get one challenge
back.  Now, that's implementation-specific.  I would not suggest that a
protocol require a system to be stateful..if mentioned at all.  However, I
would recommend that C/R headers result in a suppressed challenge to avoid
loops.

> other than just reply (e.g. read a graphic) needs to meet

Yes, agreed.  And therefore, vendors that do stupid things will not sell
their product and Darwinian nature will run it's course.  I'm not sure that
we want to address the body or content of the challenge message..just the
challenge headers.  Again, these are just my thoughts and am widely open to
counter-thoughts.

> that I can access your web site.  (Think China, think road-warrier,

Agreed.  I'm not trying to specify a web-based authentication method here or
an SMTP-reply one.  I agree there should be such methods.  I guess, if the
industry is naturally going in a certain direction, I would not intrude on
their liberties.  However, if we all want to interwork...which is really
what I am looking to define...an Interworking for C/R Systems...then  we
should identify the criteria.  Come to think of it, that's ALL I'm
considering.  I just to provide an interworking method and not dictate to
vendors how they should build their own systems...the market will figure
that out.

As a result, I will probably rename the draft to a C/R System Interworking
document.

---

From: Yakov Shafranovich <[email-masked]>
Date: Sun, 18 May 2003 14:58:46 -0400

>would recommend that C/R headers result in a suppressed challenge to avoid

One thing I wanted to mention is that a C/R system that has a white-list of 
verified senders, should probably verify the senders again every X months.

>challenge headers.  Again, these are just my thoughts and am widely open to

A Turing test may not be able to meet accessibility standards but again are 
we seeking to distinguish between man and machine, or verify the email address.

>As a result, I will probably rename the draft to a C/R System Interworking

Since the C/R systems operate over SMTP, all parts of it should operate 
over SMTP including the replies.

Yakov

---

From: "Eric Dean" <[email-masked]>
Date: Mon, 19 May 2003 13:02:29 -0400

> some similar mechanism instead of a plain email address, this

Not sure this is soemthing we would mandate here...may advise..or would see
successful implementations use..but not sure it should be mandated.

---

From: "Eric Dean" <[email-masked]>
Date: Mon, 19 May 2003 13:13:42 -0400

Ok, this is still a framework document..not to be considered a proposed
draft...just a tumbleweed.  If this initiative progresses, then I'll format
it and discuss with the chair about proposing it as a draft.  Until then,
it's intentionally left in it's current unambiguous form.

The scope keeps narrowing down from a C/R system model to a C/R system
interworking model.  I'm happy with that.  In fact, I believe there is still
more fat to trim..but we'll get there.  In the spirit of Kee Hinckley's
signature quote, less is more.

I am not interested in placing restrictions on C/R systems...I am interested
in having them interoperate..and even more so in having them interoperate
automatically. If vendors can't find smart ways to implement systems using
the guidelines we propose then they won't be vendors for long.

There were some questions about the size of recipient email addresses:
RFC2821 says 64 char for username, 256 char for domain and 512 for the
command line is 512 chars..though MIME doesn't have such
restrictions..except 1000 chars for line...regardless..there isn't a
problem..

-Eric

---

From: "Jason R. Mastaler" <[email-masked]>
Date: Mon, 19 May 2003 15:52:09 -0600

Yakov Shafranovich <[email-masked]> writes:

> The biggest problem seem to be dealing with mailing lists. 

Why are people mixing their C/R system with mailing lists then?
Since there isn't a standard for identifying a mailing list message,
all one can use is heuristics, which are not completely reliable.

Since the C/R system doesn't filter based on content, it can't help
you with spam on the list anyway.  Once the spam gets distributed to
the list, it's now just another list message as far as the C/R system
is concerned.

Instead, either use Gmane (http://gmane.org/), or filter your list
traffic before it hits the C/R system.

As an aside, I think that as mail environments get increasingly more
complex to deal with previously undreamt of issues like spam, the need
to decouple "services" such as mailing lists from your mailbox will
become more and more necessary.  The practice of forcing your mailbox
into every possible shape and size will be a historical artifact.

---

From: Yakov Shafranovich <[email-masked]>
Date: Sun, 25 May 2003 00:40:38 -0400

>[...]
 >This document identifies MIME experimental content-type values for 
allowing automated C/R system interworking.
 >[..]

Aren't we using headers?

 >[..]
 >The following MIME experimental content-type values are required for C/R 
interworking:
 >
 >X-CM:'Recipient','Response String'
 >
 >The X-CM values are defined as follows:
 >Recipient: Identifies the original recipient of the message that is 
issuing the challenge message.
 >Response String: Identifies an authentication string unique to that 
sender-recipient pair that ensures the challenge response is from >the 
original sender.
 >[...]

Is there room in the specifications for the following:
1. Tag or certification systems which will send their seal or certificate 
as a response.
2. Economic systems which will use the cryptographics or some other methods 
like hashcash to add costs to email.

 >[..]
 >Loop avoidance
 >C/R systems should not issue challenge messages when C/R headers are 
present.  In order to maintain compatibility with non-C/R >interworking 
systems, it is recommended that each C/R system remain stateful in 
monitoring challenge message sent to original >senders.  For C/R systems 
that issue challenge messages, it is also recommended that each C/R system 
use a local user for issuing >challenges rather than preserving the 
original sender's email address as the sender of the challenge 
message.  Doing so, allows for >loop avoidance to be handled using standard 
double-bounce methods where appropriate.  For client-based C/R software, 
loop >avoidance may be handled using additonal stateful means of tracking 
outgoing mail.

What will stop a spammer from putting X-CM headers into the message and 
what happens in that case - is there message let through or the C/R system 
responds to it, thus validating the receiver's email?

Yakov