[OpenID] XRI and OpenID mailers

[SitG Admin]

>I notice that a goodly percentage of posted emails to 
><mailto:general at openid.net>general at openid.net are not distributed by 
>the openid.net pipermailer to my particular registered mailbox. I 
>don't know if this same phenomenon occurs for others.

At first I thought the list wasn't sending me copies of messages that 
already had my address in the To/cc list (which made sense, to save 
bandwidth, but it was still annoying since I didn't realize messages 
were posted to the list rather than addressed to me personally). This 
turned out to be fixable by setting my filters to look for the list's 
address in either of those two areas; previously I'd been looking for 
an X-BeenThere header.

An annoyance that requires my constant attention to fix is the list's 
Reply-To (Sender) header; on at least one occasion I have not only 
forgotten to add the list's address to my outgoing mail, but missed 
this omission for some time thereafter.

>applying microIDs and openIDs to listing archive and email 
>distribution! Prove that you are getting the stream in a timely 
>fashion, as are others, in an era that acknowledges that military 
>dis-information campaigns are rife in mainstream media.

I'm not sure that's the exact proof we need to be worried about. How 
important is it to prove that we *did* receive something? And even if 
we *can* prove that X did receive something, we still can't prove 
that X *read* it. (Unless we use Receipts, not to re-invent the 
wheel, but even that still won't prove that X *understood* any of it. 
For instance; I open your messages, Peter, and often can't understand 
them, but I still need to read at least a few lines to know that it's 
more XR*, of which I know nothing.) A more interesting question would 
be proving that we *didn't* receive it, or, since proving a negative 
can be tricky, proving that we received it *at a particular time*.

A bit of extra negotiation between mail servers might accomplish 
that; each transmitting node must accept a datestamp from the 
receiving node, (verify that it is correct and) sign it, then send it 
on to the receiving node before that node will accept delivery. Each 
receiving node must reject delivery if the message actually arrived 
(in full) much later than the agreed-upon datestamp. These signed 
datestamps could be included in the message headers, giving its 
ultimate recipient the power to prove when the message was 
sent/received on a per-node basis.

This seems like it would be better implemented with an E-mail spec 
than microID/openID, though. I think the main problem with getting 
OpenID to play nicely with E-mail is that they're different systems; 
sure, E-mail *can* be web-based, but I for one download it to my 
computer. Still, until then it's stored in a way that *can* have a 
web interface to it, so it's just a matter of getting all the parts 
to talk to one another.

Proving that I *have* a message can be done in a fairly 
straightforward manner, and even as a zero-knowledge proof; anyone 
curious about it generates a random string, sends it to me, and I 
append it to the message I've received before hashing them; the 
problem with this is that any differences in auto-formatting 
(line-wrap, type of line return, and HTML being some obvious 
culprits) between mail clients will break it, and we're *still* 
working out the problems with *those* differences ;)

To prove that you're *not* getting it, you need to be able to 
demonstrate that the *list* cannot prove that you *have* received it. 
Because, really, *you* could just pretend to have not received 
anything, and deny that you had. The list could, I suppose, refuse to 
send you any further messages until you admitted to having received 
the last, but then that would slow down reception of many messages, 
which would normally be sent all at once. At that point you 
*wouldn't* be receiving messages in a timely manner, which would 
defeat the purpose ;)

-Shade
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20080426/440c936e/attachment-0001.htm>