Re: Mail Cookies

On Wed, Feb 11, 2004 at 02:26:40PM -0800, Dave Crocker wrote:
>
> Oh?
> 
> This is from the message you sent:
> 
>      Message-ID: <[email protected]>
> 
> That thing on the right-hand side looks like a domain name. So if you
> mean something else as being 'not a relation to a particular domain' I
> don't have a guess.  Please clarify.


In this case it does contain the domain name, but there
is no syntax which says that this needs to be the domain. 
I received plenty of mails without.

Here the domain name is not used to form a relation. It is 
used to make the MessageID unique. That's a completely different 
thing. 

And, furthermore, If you do reply to my message and put others on the 
Cc:, then the MessageID will be sent to all of them and not just 
to my domain. Your MUA doesn't make use of the MessageID. 
The MessageID might contain my domain visible for your eyes, but 
your MUA won't make any use of it. So there is no relation.



The MessageID is meant to form a relation to a particular mail, 
disregarding the domain.

The Cookie is meant to form a relation to a particular domain, 
disregarding the thread. 






> HD> The thread-Message-ID is useful only as long as you reply to
> HD> another message of the same thread. When you leave the thread or 
> HD> do send a new message, it's gone.
> 
> I have no idea what you are talking about.  Pleasew clarify.


Look, it's easy. If you do read a e-mail sent from me and press
the "reply" button on your mail program, then your reply will 
contain a reference to my former mail. My MUA will understand that
this reply belongs to the first message. The MessageID is still
intact. 

But when you write a new message, then this message will not contain 
a reference to any of my former e-mails, even if you do reply
to something I wrote. The MessageID forming the thread is gone.

In contrast, once I've sent you a cookie, your MUA would include
this cookie in any Mail you send to me, so even this new message
could be automatically preprocessed by my MUA.

E.g. my customers do send fresh mails. The do not "reply" only. 
So there is no useful MessageID contained in those messages.




> When you reply to a message in a thread, you can use that message's
> message-id or you can use any other message-id, which will thereby
> couple your response to the message with the referenced message-id.

Again: The cookie is not intended to do the MessageID's work. These
are different mechanisms for different purposes. It is not intended
to couple the response to a former message. That's what MessageIDs 
are good for.





> my comment about sub-threads was meant to highlight that threads are not
> nearly as neat and clean a concept as folks might think.  They have
> variable structure and, often, subjective assessment involved.  Even the
> start of a thread can sometimes be difficult to determine.

Aha. So another requirement: Better Thread tracking.




> HD> Furthermore, it is sent to 
> HD> everybody on the same thread. This mechanism is intended to 
> HD> allow the MUA to sort the messages into threads and display them.
> 
> Again, why can't message-ids be used for this?  And why does it need an
> external standard?

You're misquoting me. I was talking about MessageIDs here to show
the difference to Cookies. 

If you reply to my message and Cc: the mail-ng mailing list, everybody
will see the MessageID reference and need it to track the thread.

In contrast, a cookie is confidential and would be sent to me only.



> It will probably help to hear what problem this is intended to solve, in
> terms of the humans who are participating in the exchange.


Some kind of lightweight authorization, non-spam detection, 
customer management, mail delivery priorities, separating messages
into important non less important messages, e.g. to selectively
download them on mobile computers, maybe to accept messages only
from those people I've ever sent a message to. Mailing lists 
might authorize the senders, MTAs may selectively rewrite senders
depending on cookies. I believe there are plenty of uses. 

Hadmut