Subject: [Asrg] 6. Proposals - Challenge/response - CRI

From: Andrew Akehurst <[email-masked]>
Date: Fri, 15 Aug 2003 16:43:01 +0100 (BST)

In what follows, I'm referring to the CRI draft proposal as posted in:
  http://www1.ietf.org/mail-archive/working-groups/asrg/current/msg06731.html

This is my initial reaction, I'm going to re-read in detail and
provide some more detailed feedback later next week.

The use of CRI MIME message headers described in section 1.3
looks interesting. This seems good because it's transparent
to non-CRI MTAs which will just pass the message on, presumably
leaving the issuing of a challenge to a later stage, e.g. use
of a CRI-enabled MUA.

Out of these headers, this one caught my eye:

  "CRI-Sender-Exempt: identifies that the sender desires to not 
   receive a CRI message. i.e. mailing list"

I'm glad you've included support for mailing lists. I'd like to
know how you envisage this being used in practice. In section 4.2
you state that:

  "Mailing lists may include CRI-Sender-Exempt headers to 
   indicate that challenge messages should not be posted to
   the mailing list..."

What will be the content of such a header? Is it just a flag
such as "CRI-Sender-Exempt: 1"? If so, what would stop a 
spammer from adding such headers to their messages?

Is it true that a spammer who used such headers simply wouldn't
be sent a challenge message? If so I guess they wouldn't have the
opportunity to answer a challenge and thus get themselves 
permission to send to the receiver. So maybe it's not in their
interests to try and use such a header.

The need to rewrite mailing list software to generate such headers
is potentially more of an issue. Supposing I decided to use CRI
yet subscribed to some mailing lists which didn't generate such
headers. How could I ensure such messages got through?

My other "first reaction" to the proposal is that the SMTP idea is
interesting although the use of a 4xx temporary failure code for a 
challenge will of course result in non-compliant sender MTAs
retrying and repeatedly failing. Of course in the end they'll
give up and then will the sender's original message bounce back?

I'm interested here in the interoperability issues between MTAs
which support CRI and those which don't. Some more discussion in
that area would be helpful.

As an aside, I'll be away for several days so I won't be checking
e-mail for a while. But I'll leave everyone to debate the issues
and will join in again when I return.

Andrew

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

---

From: "Eric Dean" <[email-masked]>
Date: Fri, 15 Aug 2003 16:40:39 -0400

> know how you envisage this being used in practice. In section 4.2

Most CR systems support a variety of mailing list identification methods
that have been discussed in prior threads.  For example, sender header

> What will be the content of such a header?

Good question...it could be blank..like an HTTP no-cache header..or maybe
have some content.

It should probably identify the mailing list i.e.

CRI-Sender-Exempt: [email-masked]

That way the recipient could whitelist the header for now and always.

> Is it just a flag

Nothing.  However, a well-implemented CR system should simply suppress a
challenge message to the sender...but should probably not forward the
message as a trusted source unless the recipient whitelists.

I'm not trying to dictate how a CR system should be designed..but am trying
to provide a basic set of interoperability procotol messages to automate
interaction

> be sent a challenge message?

Possibly..it's probably not a must...but is the intention

> If so I guess they wouldn't have the

That's what I'm thinking

> headers.

Yes, however, many CR systems today identify lists.  Also, mailing lists
would eventually add the header..it's not necessary day 1.  There are other
uses...a CR system should also add the header to it's CR
messages...ecommerce receipts too...

> How could I ensure such messages got through?

I don't believe you can.

> give up and then will the sender's original message bounce back?

I'll let Yakov reply

> that area would be helpful.

Well..the MIME headers should be transparent...then you still have to write
a clear email message explaining what to do.

---

From: Andrew Akehurst <[email-masked]>
Date: Wed, 20 Aug 2003 10:52:03 +0100 (BST)

> Good question...it could be blank..like an HTTP no-cache header..or
> maybe have some content.
> 

This seems like a reasonable suggestion.

I'm not sure what would be reasonable software behaviour when
such a header is seen in an incoming message. To whitelist
automatically based on the presence of such a header would open
the system to abuse by spammers. I suppose well-behaved software
would ask the user whether they want to whitelist the address
and let the user decide.

I know we're only specifying interoperability rather software 
behaviour, but it's useful to think about how software would
interpret such headers.

>> If so, what would stop a
 
> Nothing.  However, a well-implemented CR system should simply suppress
> a challenge message to the sender...but should probably not forward the

The issue of trust between one stage of delivery and the next is 
one which does concern me with CR systems.

In general, when a CR-compliant MTA receives an incoming message
which claims to have been challenged and accepted... how can the MTA 
at this stage ensure that such headers were not forged?

I suppose it comes down to which systems have access to the consent
tokens for that specific sender/receiver pair: only the systems which 
have access to those tokens can verify if they are valid. This could
be done using a cache scheme such as that raised recently by Danny 
Angus:

  http://article.gmane.org/gmane.ietf.asrg/5760

As I'm sure everyone recalls, that idea was in the context of
cacheing consent policy rules to allow messages to be dropped
earlier in the delivery chain (close to the sender) with the
intention of reducing the spread of network traffic due to spam.

In the worst case, even if no such cache scheme were implemented, 
I'm sure the end-reciever's MUA would know all of the relevant 
consent tokens and could therefore accept or block messages at 
the last stage of the delivery chain. If this is true then 
delivery of "bad" messages (with possibly invalid CRI headers)
earlier on could still be detected at the final step before such
messages appear in the recipient's in-box.
 
> I'm not trying to dictate how a CR system should be designed..but am
> trying to provide a basic set of interoperability procotol messages 
> to automate interaction

Ok, thanks for pointing that out.

> Yes, however, many CR systems today identify lists.  Also, mailing
> lists would eventually add the header..it's not necessary day 1.

I'll admit this is one of the reasons the CRI proposal does seem
promising because it doesn't require the whole internet to change
overnight. Of course, like most proposals, it would benefit much
more if it were widely implemented.

>> [Supposing I decided to use CRI
>> headers.] How could I ensure such messages got through?
 
> I don't believe you can.

Therein lies a major problem for CRI and indeed CR systems in general.
To find a way around the issue, it might be worth thinking about 
the possible format of mailing list messages.

Generally speaking, most mailing lists have these delivery options:
 - digest
 - single-message
 - no delivery (web archive - irrelevant here)

The characteristics of a digest message are that:
 - it usually arrives "from" the same e-mail address
   e.g. [email-masked], [email-masked] etc.

 - its reply-to address is usually the same as the "from" address

 - it may contain multiple actual messages, although these will
   probably not be separated in a format which allows automatic
   parsing (so this property is of little use in practice)
 
The characteristics of a single list message are:
 - its "from" address is that of the sender, which could be anyone
   authorised to post messages to the mailing list

 - its "reply-to" address may or may not be set to that of the list
   address (I think this depends on the configuration of the list
   software)

By convention, the subject line of such messages often (not always)
contains the name of the list from which the message originated,
as with [ASRG] here.

There are some standards proposed which are relevant. Aside from
the usual RFC 2822, RFC 2919 proposes a "List-Id:" header which 
can be used to recognise mailing list messages. RFC 2369 also 
defines additional headers for mailing lists which might be of 
some help in recognising mailing list messages. 

Of course, as with any headers, these could be forged by a spammer.
The question is whether it would be sufficiently difficult to forge
such headers? This is why the use of a unique consent token in a
header is difficult to forge, because it's hard to guess for anyone
who doesn't know it in advance.

If messages from mailing lists can be reliably recognised by a
machine then they can be dealt with in a way which is "as automated
as possible". I'm thinking about how to reduce the pain for the
users of CRI during the time when mailing list software has yet to
be rewritten.

Andrew

---

From: "Eric Dean" <[email-masked]>
Date: Wed, 20 Aug 2003 11:45:44 -0400

> would ask the user whether they want to whitelist the address

Yes, whitelisting could be easily abused.  The intent is to prevent a
challenge message from being returned...adding a mail list identifier
would be convenient for identifying subsequent messages for whitelisting
per user request.
 
> at this stage ensure that such headers were not forged?

You have to respond with a corresponding string that is either static or
algorithmic.
 
>   http://article.gmane.org/gmane.ietf.asrg/5760

We are not trying to be restrictive as to which algorithm to use...but
instead produce a protocol that would accommodate many different
approaches.
 
> the possible format of mailing list messages.

We have an archive of such a detailed discussion a few months ago