Please piss on me, not the other Eric. All he was doing was reviewing
the draft. It's not his fault. Please don't punish him for doing good.
It is my fault that I did not copy the response to your comments
directly to you. The message is here:
You are absolutely correct: Message-ID *is* supposed to be like RFC
2822 Message-ID, which means that it is supposed to be globally
unique, which means the text is under specified and I need to fix
that. Thanks for catching that one.
On May 15, 2008, at 2:53 PM, Eric Rescorla wrote:
At Thu, 15 May 2008 18:37:51 +0200,
Frank Ellermann wrote:
Eric Rescorla wrote:
As I understand the situation, the sender the only person
who has to rely on the uniqueness of this header, right?
Hi, I have not the faintest idea what you are talking about,
but if it is in any way related to the 2822upd concept of
a Message-ID "worldwide unique forever" is no nonsense as
soon as a Message-ID passes mail2news gateways, and/or is
used in an Archived-At URL.
I admit that I only spent a little while examining this, so
perhaps Eric Burger can give a more definitive answer. However,
looking at the examples in -07, it sure looks to me like
message ids are not intended to be globally unique forever,
since, since they're way too short.
| The Message-ID header field contains a unique message identifier.
| Netnews is more dependent on message identifier uniqueness and fast
| comparison than Email is
| The global uniqueness requirement for <msg-id> in [RFC2822]
| is to be understood as applying across all protocols using
| such message identifiers, and across both Email and Netnews
| in particular.
(2) It is prohibitive for an attacker who has seen one or more
valid Message-IDs to generate additional valid Message-IDs.
That would match pseudo-random number, but a "worldwide unique
forever" Message-ID can boil down to timestamp @ domain (plus
magic to avoid collisions for various Message-ID generators
for a given domain or subdomain).
I'm not sure I get the point you're trying to make here. Yes,
if you want to have unforgeability this is a stronger requirement
than worldwide uniquness.
IETF mailing list
IETF mailing list