INN 2.2.1 rejects Message-IDs ending in dot

[Patrick J. LoPresti]

 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