Subject: [Asrg] Mail Cookies Was: Single-User Addresses

From: Hadmut Danisch <[email-masked]>
Date: Mon, 3 Mar 2003 21:43:20 +0100

Just a different flavour of the Single-User Address
idea:

Leave the sender and recipient's address untouched.
Just invent an opaque cookie which has to be presented
in the header when sending a message.

Have a Header

  Mail-Cookie: ...

which presents a required cookie and a

  Mail-Set-Cookie: ...

to give the recipient a cookie to use for replying.

It is the receiving MTA's private thing to evaluate the
cookie and do with it whatever it wants, like a HTTP server.

Examples uses:

- A cookie is good for anyone to send mail to a certain
  address B, but is valid only for a limited amount of time.

  A news posting could contain such a cookie.

  A HTTP link could contain this:

  <a href="mailto:..." cookie="..."> with a cookie valid only
  for an hour. You always can directly send email by just clicking
  on the link, but taking the address and cookie into an address
  list is useless.

- A cookie is good for sending mail from address A to address B

- A cookie is good for sending not more than n messages

- A cookie could even be sold through some kind of micro payment.

regards
Hadmut

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

---

From: "David F. Skoll" <[email-masked]>
Date: Mon, 3 Mar 2003 15:53:53 -0500 (EST)

> in the header when sending a message.

Well, then you have to receive the message.  If you only base it
on sender and recipient address, you can make a decision at RCPT TO:
time.

--
David.

---

From: "Bob Wyman" <[email-masked]>
Date: Mon, 3 Mar 2003 16:00:29 -0500

> in the header when sending a message.
	Such cookies would be inferior, I believe, to a system such as
Single-user addresses since they require both sender and receiver to
have mail systems that understand the additional header fields. On the
other hand, handling of a single-user address of the form
"[email-masked]" is something that can be deployed
immediately by any mail recipient who has a mail server capable of
ignoring the signature part when determing who the mail is destined for.
Thus, if you use sendmail for SMTP, or you use Earthlink or a number of
other mail providers, you can create and use single-user addresses NOW.
All you have to do is put the single-user email address into the
"reply-to" and "From" fields of your messages.
	There are all sorts of things that can be done if we are free to
redesign the mail protocols. For instance, we could get into the whole
PKI issue... However, the reality is that such efforts will take a great
deal of time to design and they will take even longer to propogate
through the internet. Thus, it makes sense to consider methods that will
result in minimal disruption to the existing protocols. The single user
address (especially if based on the "+" convention) allows the method to
be used with NO modifications to existing protocols.

		bob wyman

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Hadmut Danisch
Sent: Monday, March 03, 2003 3:43 PM
To: [email-masked]
Subject: [Asrg] Mail Cookies Was: Single-User Addresses

Have a Header

  Mail-Cookie: ...

  Mail-Set-Cookie: ...

Examples uses:

regards
Hadmut

---

From: Hadmut Danisch <[email-masked]>
Date: Mon, 3 Mar 2003 22:38:35 +0100

> "reply-to" and "From" fields of your messages.

...

> be used with NO modifications to existing protocols.

I disagree.

There are many MUAs and mail handling programs which can't cope with
+ mail addresses and fail to sort mails, recognize senders etc. 
Maybe your MTA can transport these mails, but lots of mail programs
will fail. E.g. the complete mail routing software running on 
the rackland server will fail. 

Just as an experiment: 

I just sent this message to the [email-masked] mailing list with 
a sender address

From: [email-masked]

The mailing list processor didn't accept it and queued it
for approval. So these + mail addresses don't even work on this 
mailing list. So your assumption of "minimal disruption" is wrong.

In contrast, a new header line is fully transparent and really can 
be handled by any MTA and MUA.

Hadmut

---

From: Fred Condo <[email-masked]>
Date: Mon, 3 Mar 2003 13:51:05 -0800

>   on the link, but taking the address and cookie into an address

This is inadvisable as it would require a change to the [X]HTML 
document type definitions, because "cookie" would be a new attribute of 
the "a" element. One can neatly solve this by defining an XML namespace 
for this purpose, say, "spam". The code then becomes this:

<a href="mailto:..." spam:cookie="...">...

--
Fred

---

From: Roland <[email-masked]>
Date: Mon, 03 Mar 2003 22:40:12 +0000

> From: [email-masked]

I dont understand the nitpicking on '+'.

If you cant subscribe to a mailing-list because the address
contains this character the software is obviously broken.

Such an extension-character (which is a simple dash on qmail
and courier for example, and might be even a dot on others)
should have no effect except for local delivered mail where
explicitely configured.

> be handled by any MTA and MUA.

The invocation would have to follow this semantic:

<a href="mailto:...?cookie=...&subject=...">

but this wont be recognized by any existing client out there,
and the only use will be for those clicking on mailto-links.

Such a cookie will have to be included within either the local
part or in the domain-part (as subdomain) to be compatible.

Roland