[ Home page | Things which suck ]
(An apology is probably in order here: this is in large part a deeply technical rant, which will probably bore you. Part of the reason for its appearance here is so that I can quote its URL the next time it looks like I might get bogged down in another tedious USENET message-header flame war. The best that can be said for these things is that they keep people safely off the streets.)
(In the true spirit of USENET, extracts from actual articles below are reproduced without the permission of their authors.)
Me: Has anyone the answer to the following question?
USENET weenies [as one]: The headers of your article are incorrectly formatted!
Me [sighing]: No they're not.
[Fade to red.]
The second one may need some explanation. If you are presented with an article to which you wish to reply, and you have not read it in enough detail to see that the email address in the From: line has been obscured, how likely is it that you have read it well enough to make a useful point in reply?
I argue, based on my experience, that the answer is `not very'. For information, here is part of the last posting I recall making on this matter:
Date: Wed, 26 Sep 2001 19:10:54 +0100
From: Chris <chris@x.invalid>
[...]
Jonathan Amery wrote:
[...]
> Usually when I do this (I don't read signatures after the first
> time), they're part of the medium, not the message, I'm about to be
> useful to the person I'm sending the mail to. When I get the bounce I
> think 'fuck it' and rant a bit on IRC about idiots who spamblock their
> addresses.
One of the things least likely to convince me to change
my view on this is a parade of people with arguments such
as the above. I cannot see how you expect me to believe
that your email to me will be worth reading if you are
too lazy to find out my email address.
I do not know how often you send useful emails to `idiots'
about whom you later `rant' on IRC. But I would estimate,
based upon my experience of unsolicited email, rants and
IRC, that it is not very often.
[...]
The purpose of a message-id is to make messages globally unique, so that USENET's global flood-fill algorithm for exchanging messages between sites correctly propagates them. Unfortunately, the description of this field in the relevant RFC is not tremendously helpful. It says,
In order to conform to RFC-822, the Message-ID must have the format:
<unique@full_domain_name>
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).
How should this be interpreted? This is, surprisingly enough, often a source of weeniedom, viz.:
In article <3AA63F8C.F703B0CF@x.invalid>, Chris <chris@x.invalid> wrote:
>Well, in particular, my last article
> <3AA61C7A.DCB3D51D@x.invalid>
^^^^^^^^^
Can I suggest that you fix that?
There's a serious problem with the concept of `the host at which the message entered the network'. Does it mean the host at which the message was physically entered -- the one running the user's news reader? Or the first news server host which the message encountered? Or the first public host which it encountered? Clearly, this is a specification from an earlier age, when hosts were fixed and their names public. What should I do if I am submitting an article to an internal news server with no public name? Or from a dynamically-assigned IP address? Note that in the latter case, two articles from unrelated users may appear with the same domain-part in the message-id, depending on when they acquired their IP addresses from a dynamic name server. (A standard answer to this from the technical bigot and the pseudotechnical idiot is that you should permit the server to which you submit the article to pick a message-id. Apart from the fact that this merely shifts the problem, it is very helpful for the message-id of a posted article to be known to the news reading software itself.)
It's customary for the user to use the domain-part of the email address specified in their From: line for the domain-part of the message-id. This is a perfectly reasonable work-around for the obsolescence of the RFC. Does it pose a threat to uniqueness?
The answer, is, of course, `no'. Typical news readers use ten or more characters of message-id, and those characters may be distributed over any `printing ASCII character, not including [3 characters]', something like 90 characters. For ten character message-ids, this gives 3.5×10**19 messages per domain per two years. Given that (a) most message-ids are longer than this; and (b) Google's archive of all of USENET is only 700,000,000 messages, this ought to do.
(Ben Harris points out that there's a birthday paradox issue here, since the numbers we should compare are the size of the message-id space and the number of pairs of messages. 7×10**8 messages gives 4.9×10**17 pairs and a collision probability of a bit over 1%. Since USENET is getting busier, larger message-ids are warranted; current practice recommends 128 random bits for unique tokens, or 20 characters from the set described above. This would allow more than 3×10**17 messages per domain per two years with a 1% chance of collision.)
(Note that, of course, this only works if news readers employ a competently implemented random-number generator sanely used. But I'm only making an assertion about my software. And your implementation would have to be spectacularly bogus to throw away the numeric advantage shown above.)
The ideal? Minimum message-ids, of the form
<Z*21a094n.qwxI.D71ig@x>, still have sane uniqueness and
don't waste so much bandwidth.
Get a better newsreader or shut up, then.
For fuck's sake. This is a totally fucking stupid complaint. The purpose of a signature separator -- two dashes followed by a space at the beginning of a line -- is to make it easier for some news reading software to strip off or otherwise distinguish the signature from the posting. A noble aim. But that's no reason to bawl into your cornflakes if someone's posting lacks it.
This is shorthand for `I am programming my news reading software not to display posts you have made'. Why on earth would you want to publish this piece of information? As part of some sort of malign dick-size-war? Because you expect that your friends will follow suit? Because you think that it's an effective insult? Or is it because you're a childish prick: ``shan't come to your birthday party!''
(It has been drawn to my attention that the term `dick-size-war' is, so to speak, gender specific. All I can do here is to plead `guilty' and argue in mitigation that,
I'd be pleased to hear an alternative non-gender-specific suggestion.)
A stock weenie response to this complaint is to claim that it is only polite to inform your interlocutor that you are no longer reading their articles. This, of course, is nonsense: if this were actually their motive they would send the ``plonk'' by email, and not in a public forum. (This, of course, discounts weenies who can't read.) Thanks to Martin Keegan for this observation.
This speaks of an idiocy almost too deep to contemplate. You've published the bloody thing on USENET! How can you expect to impose conditions on its redistribution? And in any case it's only five fucking lines long!
Now, top-posting -- posting your response above the quoted message to which you are following up -- really is irritating. But then you knew that already.
`Godwin's Law' states that--
As a Usenet discussion grows longer, the probability of a comparison involving Nazis or Hitler approaches one.
There is a tradition in many groups that, once this occurs, that thread is over, and whoever mentioned the Nazis has automatically lost whatever argument was in progress.
-- but he's a crazed gun-toting loon, so we probably oughtn't to pay him too much attention.
Don't want people to publically comment on your advert? Buy a spot on TV.
To summarise with a well-worn phrase: if you can't get a life -- or believe that you already have one -- at least get a clue. And if you're not going to contribute, don't bother to flame. On a lighter note, caricatures!
Copyright (c) 2002 Chris Lightfoot. All rights reserved.