rra> INN expects message IDs to be RFC 822 addr-spec's surrounded by
rra> <>, which is the definition of the Message-ID header from RFC
rra> 822. RFC 1036 also refers to RFC 822 for the canonical
rra> definition of a message ID, but adds some additional
rra> restrictions. An RFC 822 addr-spec is:
[snip]
rra> So a period is a special, and therefore a period may not be an
rra> atom. A sub-domain is required to be an atom, and sub-domains
rra> must be period-separated in the domain part of an addr-spec. My
rra> reading of the above grammar disallows a trailing period.
You are right. So I guess Microsoft Outlook is broken (surprise,
surprise).
rra> I believe that adding a trailing period to indicate a fully
rra> qualified name is internal to the DNS resolver and isn't
rra> considered part of the standard representation of the name, and
rra> that Internet standards are pretty uniform in assuming that all
rra> names they deal with are already fully-qualified.
I was figuring there would be a syntactic difference between FQ and
non-FQ names, but I guess that is unnecessary if you assume everything
is FQ.
rra> That's the theoretical answer; the practical answer, if you want
rra> to loosen INN's restrictions on message IDs, is that
rra> unfortunately this isn't confiugurable at the present time. The
rra> code in question is ARTidok() in innd/art.c and says that it was
rra> written in November of 1990.
Yeah, I read through it; that is how I figured out what was wrong with
the Message-IDs.
If I contribute patches to make this configurable, might they make it
into an official version of INN? I am thinking of a "looseids"
boolean (or somesuch), which would allow through the common botched
cases...
- Pat