Hello Thomas,
On Wednesday, May 25, 2005 at 4:21:30 PM Thomas [TF] wrote:
[Thesis:]
TF>>> To post in the usenet, you need to own an FQDN (fully-qualified domain
TF>>> name).
[assumed Proof]
TF> OK, let's talk about RFCs. There was one (pertaining to the usenet
TF> only) saying that you need to own the domain if you want to create
TF> mids from it. I'll search for that RFC, but maybe you're faster.
Antithesis:
The "Usenet"-RFC seems to be 1036 "Standard for Interchange of USENET
Messages". If anybody can correct me on this everything that follows
might be wrong, because it bases on my "knowledge" 1036 *is* the
Usenet-RFC.
This very well RFC says in chapter 2.1.5:
,-----
| The "Message-ID" line gives the message a unique identifier. The
| Message-ID may not be reused during the lifetime of any previous
| message with the same Message-ID. (It is recommended that no
| Message-ID be reused for at least two years.) Message-ID's have the
| syntax:
|
| <string not containing blank or ">">
|
| In order to conform to RFC-822, the Message-ID must have the format:
|
| <[EMAIL PROTECTED]>
|
| where full_domain_name is the full name of the host at which the
| message entered the network, including a domain that host is in, and
| unique is any string of printing ASCII characters, not including "<"
| (left angle bracket), ">" (right angle bracket), or "@" (at sign).
`-----
Sounds reasonable. Lets go to RFC-822, which is referred to, and
ignore the fact 822 is superseded by 2822:
,----- [ RFC-822 ]
| 4. MESSAGE SPECIFICATION
| 4.1. SYNTAX
| [...]
| optional-field =
| / "Message-ID" ":" msg-id
| [...]
| msg-id = "<" addr-spec ">" ; Unique message id
`-----
Now lets look how a 'addr-spec' is defined:
,----- [ RFC-822 ]
| 6. ADDRESS SPECIFICATION
| 6.1. SYNTAX
| [...]
| addr-spec = local-part "@" domain ; global address
| [...]
| domain = sub-domain *("." sub-domain)
|
| sub-domain = domain-ref / domain-literal
|
| domain-ref = atom ; symbolic reference
`-----
OK. 'sub-domain.sub-domain.subdomain....'. Looks like a FQDN, somehow.
But hey ... there can be only *one* 'sub-domain', you don't
necessarily need the '.sub-domain' part ... *hmmm* 'domain-ref' =>
'atom' ... What's an 'atom'?
,----- [ RFC-822 ]
| 3.3. LEXICAL TOKENS
| [...]
| atom = 1*<any CHAR except specials, SPACE and CTLs>
`-----
Doesn't help much either. But what's a 'domain-literal'???
,----- [ RFC-822 ]
| 3.3. LEXICAL TOKENS
| [...]
| domain-literal = "[" *(dtext / quoted-pair) "]"
| [...]
| dtext = <any CHAR excluding "[", ; => may be folded
| "]", "\" & CR, & including
| linear-white-space>
| [...]
| quoted-pair = "\" CHAR ; may quote any char
`-----
*ahhh* ... So a 'sub-domain' can be '[', followed by 'any CHAR'
(except some), followed by ']'. So '[123.456.789.10]' seems to be
allowed. But to be honest: this really does not look like a FQDN to
me, but maybe that's only me.
But does it matter? I don't think so. Lets return to the initial
statement in 1036:
| The "Message-ID" line gives the message a unique identifier. The
| Message-ID may not be reused during the lifetime of any previous
| message with the same Message-ID. (It is recommended that no
| Message-ID be reused for at least two years.)
So for two years it should form an unique identifier. Does uniqueness
relies on names? Naaa ... Your IP-Address can be unique too (assuming
you have one of the official addresses, reserved sub net addresses are
per se not intended to be necessarily unique). So there's no problem
having a MID of '<[EMAIL PROTECTED]>', looking at
the pure syntax only.
So what's the matter all about? ...
TF>>> If you use domains like gmx or yahoo, actually they must ensure
TF>>> that the mid is unique.
OK. They must ensure. If I generate the MID, they can't. That's
reasonable.
What else?
PP>> Sorry, this is bu^W nonsense. Either you hold the point "MID is a
PP>> unique message identification entity", than it's same important for
PP>> mail as it is for usenet. Or you're saying "MID on email ain't
PP>> important", that it does not necessarily need to be unique, simply
PP>> because it's not important.
TF> You misunderstand. News postings get propagated across servers, ML
TF> postings don't.
Who says? What's the problem with distributing MLs using several
servers for load balancing reasons? What's the problem of having
'sublist' of regular lists?
PP>> No RFC says you *have* to use the FQDN,
TF> This is the point I'll have to prove to you.
You'll have to. 1036 says something about 'full_domain_name', but
refers to RFC-822 as it's source, which doesn't. As 1036 inherits 822
and does *not* form own rules about syntactical construction of
Message-ID I have to use syntax rules of 822. And 822 definitely
allows square-bracket-enclosed IP-addresses for MID.
TF>>> In fact, I'm pretty sure it doesn't and you'd be flamed in the
TF>>> usenet. Luckily, we are not in the usenet.
PP>> Luckily. Because those who would flame are hidebound geeks, that do
PP>> not want their house of cards fall down. You know one of those
PP>> "paragraph riders", that feel picked to defend even the final period
PP>> and comma in every circumstance, of course as *they* interpret it.
TF> True. Are you on the de.* hierarchy of the usenet?
Occasionally I am. And I know these meta-physic discussions. And I
hate them.
In the last few (or few more *G*) lines I've shown: syntax of
Message-ID allows IP-addresses, so the only thing left is: uniqueness.
You refer to Volkers web site: <http://einklich.net/usenet/netscape.htm>
He constructs an example where two users accidentally generate the
same MID, which could be avoided if both had used different RHS-parts
(e.g. unique FQDNs). Lets step in here, using the example of Tony
having the same IP assigned to his computer as ... *hmmm* Boris?
Think so, but doesn't matter if it was somebody else.
If both would build up the MID using the square-bracket-IP-address
notation for RHS, what needs to come together for both generating the
same MID? The Bat! uses Date-Time-Stamp for LHS plus a little random
data. I don't know the algorithm of Mulberry, but I assume Date and
Time are a basis for their MID-generation too. Plus random data,
because date and time are changing to slow, compared to the speed
messages are created at (seen world wide). The chance two MIDs are
generated in exactly the same second is, looking at all computers in
the world, high. The chance they're generated in the same millisecond
(and both computers have absolute identical time, down to
milliseconds!) is lower, but still mathematical present. The over-all
risk of duplicate MIDs still significantly sunk when 'Date', 'Time'
and 'Millliseconds' are used. Now, what's the chance those two
computers generate the *same* random data? I'd say, mathematical it's
greater than zero, but realistically I tend to say: it's infinitesimal
low, near to zero.
So even if some people use identical 'FQDN's (or RHS-parts, to release
ourselves from the "wrong" term), chances are *really low* they
generate identical MIDs, *IF* they don't use poorly designed software.
The Bat! generates rather good MIDs, IMHO, and I suspect Mulberry
doing the same; I'd be really surprised if they implemented IMAP to
the period and comma, but have not found a reliable way of generating
most random Message-IDs ...
That leads to the conclusion: we can burry the discussion regarding to
TB-lists and e-mail in general, AND: even in Usenet the self-appointed
gurus most the times seems to like nit-picking and self-profiling,
because no matter what they construct: most times the clients software
generates rather good and random MIDs with chances of collision nearly
zero. This *might* have been different in early times of usenet, but
time went by, software improved ;-)
TF> We are discussing an issue, and I need to find that RFC Volker G.
TF> refers to.
Please do. I'd be interested if he refers to a different RFC than I ...
--
Regards
Peter Palmreuther
(The Bat! v3.5.0.17 on Windows XP 5.1 Build 2600 Service Pack 2)
A man's best friend is his dogma.
________________________________________________________
Current beta is 3.5.0.16 | 'Using TBBETA' information:
http://www.silverstones.com/thebat/TBUDLInfo.html
IMPORTANT: To register as a Beta tester, use this link first -
http://www.ritlabs.com/en/partners/testers/
