INN 2.2.1 rejects Message-IDs ending in dot
rra at stanford.edu
Mon Dec 6 22:39:23 UTC 1999
Patrick J LoPresti <patl at cag.lcs.mit.edu> writes:
> One of our user's mail clients is generating Message-IDs like this (note
> the trailing dot):
> <some-stuff at host.com.>
Yeah, INN's rejected those for a while. That plus doubled @-signs are
probably the most common invalid message ID rejections that I see.
> His machine is configured with a fully-qualified hostname, complete with
> trailing dot. The trailing dot is causing INN to reject the Message-ID
> as malformed.
> I have asked him to change his configuration, but INN's behavior here
> looks overly stringent to me. As I read RFC 1036, it should be legal to
> use a fully-qualified name after the @. (Heck, pedantically speaking,
> the trailing dot is required for a name to be fully-qualified in the
> first place.) So I think INN ought to accept Message-IDs like this.
INN expects message IDs to be RFC 822 addr-spec's surrounded by <>, which
is the definition of the Message-ID header from RFC 822. RFC 1036 also
refers to RFC 822 for the canonical definition of a message ID, but adds
some additional restrictions. An RFC 822 addr-spec is:
addr-spec = local-part "@" domain ; global address
domain = sub-domain *("." sub-domain)
sub-domain = domain-ref / domain-literal
domain-ref = atom ; symbolic reference
atom = 1*<any CHAR except specials, SPACE and CTLs>
domain-literal = "[" *(dtext / quoted-pair) "]"
specials = "(" / ")" / "<" / ">" / "@" ; Must be in quoted-
/ "," / ";" / ":" / "\" / <"> ; string, to use
/ "." / "[" / "]" ; within a word.
So a period is a special, and therefore a period may not be an atom. A
sub-domain is required to be an atom, and sub-domains must be
period-separated in the domain part of an addr-spec. My reading of the
above grammar disallows a trailing period.
I believe that adding a trailing period to indicate a fully qualified name
is internal to the DNS resolver and isn't considered part of the standard
representation of the name, and that Internet standards are pretty uniform
in assuming that all names they deal with are already fully-qualified.
That's the theoretical answer; the practical answer, if you want to loosen
INN's restrictions on message IDs, is that unfortunately this isn't
confiugurable at the present time. The code in question is ARTidok() in
innd/art.c and says that it was written in November of 1990.
Russ Allbery (rra at stanford.edu) <URL:http://www.eyrie.org/~eagle/>
More information about the inn-bugs