taylor@THINK.COM (10/23/88)
A local user is complaining about the In-Reply-To fields generated by MH
-- it appears that the default in-reply-to field (as specified in the
replcomps file) causes problems for LispM's.
While I can fix his complaint (he's complaining about the '.' that
separates the ``Your message of...'' part and the msg-id part), I'm
wondering if it's legal to put the date into the In-reply-to field in
the first place.
I looked, briefly, at rfc822 (is there a later standard?) and it says
that the In-Reply-To field consists of *(phrase / msg-id) and ``phrase''
*appears* to not only not allow '.'s, but also not allow ':'s.
But, I've noticed that some other mailers also put the date into the
In-Reply-To field.
Is this legal?
Here's his objection:
<I looked into why ZMAIL is barfing on your in-reply-to field:
<
<In-Reply-To: Your message of Mon, 10 Oct 88 15:44:20 -0400.
< <8810101944.AA10760@balder.think.com>
<
<It turns out the `.' at the end is what confuses it.
And here's our replcomps file (which is unedited from the MH 6.6
distribution which we ftp'ed):
%(lit)%(formataddr %<{reply-to}%|%<{from}%|%<{sender}%|%{return-path}%>%>%>)\
%<(nonnull)%(void(width))%(putaddr To: )\n%>\
%(lit)%(formataddr{to})%(formataddr{cc})%(formataddr(me))\
%<(nonnull)%(void(width))%(putaddr cc: )\n%>\
%<{fcc}Fcc: %{fcc}\n%>\
%<{subject}Subject: Re: %{subject}\n%>\
%<{date}In-reply-to: Your message of \
%<(nodate{date})%{date}%|%(tws{date})%>.%<{message-id}
%{message-id}%>\n%>\
--------
David
--
David Taylor
taylor@think.com, ...!think!taylorwisner@killer.DALLAS.TX.US (Bill Wisner) (10/24/88)
The appropriate portions of RFC822:
optional-field =
/ "In-Reply-To" ":" *(phrase / msg-id)
phrase = 1*word ; Sequence of words
word = atom / quoted-string
atom = 1*<any CHAR except specials, SPACE and CTLs>
An in-reply-to field can, therefore, consist of just about anything,
if you interpret it as being a string of atoms.taylor@THINK.COM (10/24/88)
<Date: 23 Oct 88 18:02:52 GMT
<From: Bill Wisner <killer!wisner@eddie.mit.edu>
<
<The appropriate portions of RFC822:
<
<optional-field =
< / "In-Reply-To" ":" *(phrase / msg-id)
<phrase = 1*word ; Sequence of words
<word = atom / quoted-string
<atom = 1*<any CHAR except specials, SPACE and CTLs>
<
<An in-reply-to field can, therefore, consist of just about anything,
<if you interpret it as being a string of atoms.
But, specials includes ".", ":", and "," among other things.
And therefore it looks like the In-Reply-To field that I showed is not
in compliance. But, it's fairly similar to the In-Reply-To field
generated by other mailers -- such as GNU Emacs's Rmail.
For reference, the In-Reply-To field is:
<In-Reply-To: Your message of Mon, 10 Oct 88 15:44:20 -0400.
< <8810101944.AA10760@balder.think.com>
[and was generated by the default replcomps file supplied with MH 6.6]
and since ",", ":", and "." are `specials', they can't appear in atoms.
Now, when I look at the outputs of other mailers, I find some variation.
Some just have the msg-id field. That is, they have:
In-Reply-To: <8810101944.AA10760@balder.think.com>
Others render the above as:
In-Reply-To: Your message of Mon, 10 Oct 88 15:44:20 EDT,
<8810101944.AA10760@balder.think.com>
That is, they use `EDT' instead of the `-0400' and a `,' instead of a
`.'.
And others render it as:
In-Reply-To: Your message of Mon, 10 Oct 88 15:44:20 EDT <8810101944.AA10760@balder.think.com>
That is, as one long line -- and don't seem to care if it's longer than
80 characters.
And I'm sure I could find yet more variations if I tried.
Now, looking at the date stuff in rfc822, `-0400' and `EDT' are equally
valid. But, it appears to me, that both the `.' and the `,' are illegal
-- they're not legal constituents of atoms and the string is not
quoted.
So, it looks like it's illegal. But, commonly violated. And, I was
wondering -- am I overlooking something? Or is there a later standard?
Or an addendum to rfc822? Or, is it illegal, just as it appears?
Davidbd@SDE.HP.COM (Bob Desinger) (10/26/88)
> So, it looks like it's illegal. But, commonly violated.
This is The Recurring Theme in the rfc822 world. The moral of the
story is that you should try to accomodate other people's (broken)
formats in your mail agent---you have control over your agent, but
you'll never be able to get the rest of the world to change theirs.
-- bd