[Gateway ML->NG] Sam

[daz]

(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: <[email protected]>
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: <[email protected].>
X-Mail-Count: 103617


-------------------

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.
The first two personal emails I checked (from different
addresses), both had Id: .
If the g/way news host was rejecting Id:, I feel that /no/
ML would get to NG. I just mention it for information.

-------------------

In the other direction, a NG post from Dan Tapp was not
received by email (ML), although it is in the ML archive:
If one list subscriber did receive this, my mail server
must have dropped it. Otherwise, perhaps, it was not
remailed.

Subject: Ruby /.'ted (Opens thread)
Message-ID: <40Qyc.64500$tI2.13110@fed1read07>
Date: Sat, 12 Jun 2004 20:39:45 -0700

( http://www.ruby-talk.org/103381 )


daz

 

[Florian Gross]

[Minor gateway problems]

This message also seemed not to get through from the Mailing List to the
Gateway:

http://www.ruby-talk.org/ruby/ruby-talk/102642

The Message-Id got wrapped to the second line like this:

Message-Id:
<26CF528AC99FB044A17A507AD9EC36C20D0E4A87@iblonce112.gb.ad.drkw.net>

The Subject also looks a bit mangled:

Subject: Re: [ANN] Instiki 0.9.0: Rendering improvements, Latex integratio n,
OS X version

Regards,
Florian Gross

 

[Sam Roberts]

Hey, that's my name!

(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: <[email protected]>
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: <[email protected].>
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]

[Minor gateway problems]

This message also seemed not to get through from the Mailing List to the
Gateway:

http://www.ruby-talk.org/ruby/ruby-talk/102642

The Message-Id got wrapped to the second line like this:

Message-Id:
<26CF528AC99FB044A17A507AD9EC36C20D0E4A87@iblonce112.gb.ad.drkw.net>

Btw, this is a validly encoded header field.

The Subject also looks a bit mangled:

Subject: Re: [ANN] Instiki 0.9.0: Rendering improvements, Latex integration,
OS X version

This is, too. Long lines are supposed to be wrapped, and padded with
leading whitespace.

The g/way script should maybe use one of the mail/rfc822 decoding
libraries, they should deal with this kind of stuff.

Cheers,
Sam

 

[Mark Hubbart]

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.

`sudo hostname ensemble`? I had a similar thing going on on my mac box
a while back, I think that's the way I did it. It will only last until
the box is restarted, though, so it should go in the boot.rc or
something. I think you can also edit the /etc.hostconfig file, change
"HOSTNAME=-AUTOMATIC-" to "HOSTNAME=ensemble".

Or I could be completely misunderstanding the problem. If so, please
ignore.

HTH,
Mark

 

[daz]

Wrote daz:

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
[...]
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

Hey, thanks for the correction, Sam!
It looks so *big* now that it's exposed


daz

 

[Thomas Fini Hansen]

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.

Uhm, not to be a RFC nazi, but what do you base that on? Ol' 822
define Message-Id as addr-spec, which is pretty much an 'email
address', which obviously ends in a domain name. And, say,
'ruby-lang.org.' is a valid domain name, as domains in fact are routed
in '.' (much like the filesystem starts at /). Something you learn the
hard way when fiddling with BIND zone files, forget the ending dot and
find out that your alias to another domain name instead points at a
subdomain of the same name.

But if something doesn't like that, we should probably fix it on the
way..

By the way, this is valid, too:

Message-iD :

Oh, thanks for pointing that out, gotta remember that the next time I
do something header munging...

 

[daz]

[Minor gateway problems]

This message also seemed not to get through from the Mailing List to the
Gateway:

http://www.ruby-talk.org/ruby/ruby-talk/102642

The Message-Id got wrapped to the second line like this:

Message-Id:
<26CF528AC99FB044A17A507AD9EC36C20D0E4A87@iblonce112.gb.ad.drkw.net>

The Subject also looks a bit mangled:

Subject: Re: [ANN] Instiki 0.9.0: Rendering improvements, Latex integratio n,
OS X version

Regards,
Florian Gross

Right. It's from Jun07 (a reply with no refs.) and would have been fixed by
changes made around Jun10-11. The original g/way script handles it OK but it
would be rejected by the news host (probably running another script written
using the Practical Extension and Report Language? I took a look at some
example scripts -- sheesh!, someone ought to write a cleaner version of that
language.


daz

 

[daz]

Wrote daz:

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.


Cheers,
Sam

AFAIK, Message-ID: is assigned by your ISP's mail server.
Mutt, or other MUAs compose headers that they know about
and sendmail sounds like the SMTP bit that takes care of
the journey between Mutt and your ISP.
So I don't think there's anything you can do apart from
pointing it out to your help desk.

What's weird is that your "invalid" message arrived
successfully at ruby-talk where it was remailed to the
list (again successfully), then posted as a news message
but rejected by the news host.
The only evidence I have of that is from my email inbox
but if, say, the remailer had invalidated the message -
I still received it.

If there's no other solution, I guess the g/way script
could change ID:s with trailing dot to (e.g.) dot invalid
(e-mail address removed)


daz

 

[Aredridel]

Uhm, not to be a RFC nazi, but what do you base that on? Ol' 822

define Message-Id as addr-spec, which is pretty much an 'email
address', which obviously ends in a domain name. And, say,
'ruby-lang.org.' is a valid domain name, as domains in fact are routed
in '.' (much like the filesystem starts at /). Something you learn the
hard way when fiddling with BIND zone files, forget the ending dot and
find out that your alias to another domain name instead points at a
subdomain of the same name.

Actually, that's a bindism. The whole trailing dot thing only pertains
to zone files. Really, the root is "" -- nothing at all. You just
signify that to Bind with the dot.

Ari

 

[Aaron Schrab]

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.

Mutt generates its own Message-ID headers so that they'll be present in
FCCed copies. It *is* working with invalid data, but the hostname that
it gets from the OS is only used as the default for the $hostname
variable. If you provide your own value for that, it will be used
instead. You can do that by putting a line like the following in
your .muttrc file:

set hostname="valid.domain"

 

[Sam Roberts]

Uhm, not to be a RFC nazi, but what do you base that on? Ol' 822
define Message-Id as addr-spec, which is pretty much an 'email
address', which obviously ends in a domain name. And, say,
'ruby-lang.org.' is a valid domain name, as domains in fact are routed
in '.' (much like the filesystem starts at /). Something you learn the
hard way when fiddling with BIND zone files, forget the ending dot and
find out that your alias to another domain name instead points at a
subdomain of the same name.

The DNS specifications talk about DNS domain names ending in an
(explicit or implicit) dot, but it isn't allowed by RFC822.

RFC 822 says:

domain = sub-domain *("." sub-domain)

And no, sub-domain is not allowed to include a "." character. So,
addr-specs may "pretty much end in a DNS domain name", but not in "any
valid DNS domain name".

This may be a mismatch between the DNS and email address specifications,
but c'est la vie.

Cheers,
Sam