Subject: [Asrg] MAC Constructed Message Ids.

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Sun, 6 Apr 2003 19:35:20 -0700

> >> Filtering returning bounces based on Message-ID requires 
> that the MX
> >> keep a DB of known-valid IDs.  This is a non-trivial expense.

No it does not.

Let the MUA choose a random value X, store it in a place that
is persistent.

Each time a MessageID is constructed the following algorithm 
is used:

stem = date + serial + '@'
checksum = MAC (stem, X)
ID = stem + base32 (checksum)

We thus end up with an id that is guaranteed unique (to a much 
higher degree of confidence than ordinary IDs, especially the
ones my behind 3 NATs MUA constructs). It also leaks a lot less
info than the recommended construction with the domain name
which these days looks to me like a privacy bug.

It also has the property that anyone who knows X can check that
the message ID was in fact generated by the client.

So basically simple rules for whitelisting could be something 
like:

	Accept if the reply-to has a message-ID you sent
	Accept if one of the references has a message-ID you sent
	otherwise filter through spamfilter

Bounces are a special case since it would be nice if we could
create a construction so that we could reject mail bounces
from malfunctioning MTAs that are bouncing to the original
author of a message on a mailing list.

If we combine with authentication we could automatically 
white, better greylist by domain.

Score    Message that is

100pts - a direct reply-to one you sent
 80pts - a reference to one you sent
 50pts - from someone you got a reply from in the past
 30pts - same domain as someone you got a reply from

+40pts if IP address authentication
+60pts if Certificate authentication

[Can tune these via minimum least square optimization]

Another thing you can do with this is to automatically 
file lists using the opt-in message reply-to.

So imagine this, you get an email of the opt-in variety,
you reply to it and when the mail comes from that list
it is automatically filled in a folder just for that
list.

This can be done quite easily if you can recognize an
opt-in challenge, easily done with a custom header. It
should not cause any intrusive GUI interaction since it
could be spam until responded to affirmatively.

From then on you filter on the basis of the List: headers.

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

---

From: J C Lawrence <[email-masked]>
Date: Sun, 06 Apr 2003 19:52:44 -0700

On Sun, 6 Apr 2003 19:35:20 -0700 
Phillip Hallam-Baker <Hallam-Baker> wrote:

>>>> Filtering returning bounces based on Message-ID requires that the

> Let the ....

...description of shared secret hash calculation between MUA and MTA
deletia...

Accepted, however the cost barrier to getting all the MUAs and the MTAs
upgraded is prohibitive.

> So basically simple rules for whitelisting could be something like:

> 	Accept if the reply-to has a message-ID you sent Accept if one
> of the references has a message-ID you sent otherwise filter through
> spamfilter

If we could magic wand upgrade the MUA world so that they all properly
generated In-Reply-To and References, quite a few things would be
easier.  Similarly, from a standards and deployment perspective if we
could magic wand decide whether lists should use new Message-IDs or
retain the originals for their broadcast messages...

> So imagine this, you get an email of the opt-in variety, you reply to
> it and when the mail comes from that list it is automatically filled
> in a folder just for that list.

> This can be done quite easily if you can recognize an opt-in
> challenge, easily done with a custom header. It should not cause any
> intrusive GUI interaction since it could be spam until responded to
> affirmatively.

> From then on you filter on the basis of the List: headers.

I've been advocating this for years.  My hope is that I can scrape
enough time etc to what MozillaMail (or whatever the new project is
called), to do this.

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

---

From: "Alan DeKok" <[email-masked]>
Date: Mon, 07 Apr 2003 12:29:45 -0400

> ID = stem + base32 (checksum)

  Alternately, use public/private gets to do something similar.  The
benefit there is that the public keys can be put into DNS, and
*anyone* can verify the validity of the Message-ID.

  Alan DeKok.

---

From: J C Lawrence <[email-masked]>
Date: Mon, 07 Apr 2003 13:01:52 -0700

On Mon, 07 Apr 2003 12:29:45 -0400 

> *anyone* can verify the validity of the Message-ID.

That would require MTAs to detect MUA added Message-IDs and remove them
or to share the secret with the MUAs so they can correctly generate the
tokens.

There are two basic questions for such IDs:

  Who generated them and can that be shown?

  Was that ID generated for this specific message or some other (ie
  possibly re-used)?

Not a trivial problem.