Hey, that's my name!

Wrote daz <dooby / d10.karoo.co.uk>, on Tue, Jun 15, 2004 at 04:08:39PM +0900:
> 
> (For Dennis, mainly)
> 
> Last weekend (12-14), I didn't notice any dropped ML messages.
> 
> Between June 01-15 there are 10 ML msgs from Sam Roberts, but
> only one of them made the NG.
> That one is from his certicom.com account.
> 
>    Message-Id: <20040604152659.GA25134 / certicom.com>
>    X-Mail-Count: 102383
> 
> The other nine are from his uniserve.com account and there
> is a trailing dot in the Message-Id: which may be upsetting
> the g/way news host?  Example:
> 
>    Message-Id: <20040615020507.GA806 / ensemble.local.>
>    X-Mail-Count: 103617

I'm probably slightly out of the "envelope of normal" that
the g/way script is expecting, I use OS X at home, but I use
it like a Unix box, I do all my mail with Mutt.

For what it's worth, it's an invalid Message ID. I don't know
who is generating it, either sendmail or mutt. Both might
claim that there is a bug in whatever call they are making
to the OS to get the host name, but its still wrong.

Not sure what I can do about it, though.

> -------------------
> 
> The Message-Id: headers appear in the ruby-talk archive
> uniformly with a lower case 'd' and appear to be remailed
> in that form.  Strictly, this doesn't conform to RFC
> (which specifies Message-ID:) and it destroys many checks
> because servers which generate ID: or Id: cannot be
> distinguished by looking in the archive - and it forces
> the use of some case-insensitive Regexen.
> However, both seem to be widely accepted and created by
> mail/news servers.

That's because they DO conform to the RFC! The RFCs may spell
it Message-ID, but field names are case insensitive:

  RFC822 3.4.7 CASE INDEPENDENCE

  ...

  When matching any other syntactic unit, case is to be ignored.  For
  example, the field-names "From", "FROM", "from", and even "FroM" are
  semantically equal and should all be treated identically.


By the way, this is valid, too:

  Message-iD   :   

though many cheesy regex-based parsers may choke on it.

Cheers,
Sam

-- 
Sam Roberts <sroberts / certicom.com>