On Oct 22 2004, Bruce Lilly wrote:
Two problems:
1. date-time is pervasive; it is used in many places in addition to
time stamp lines
Good point. This change would impact other header lines.
2. while providing seconds was once mandatory (RFC 821), it is
now optional (RFCs 2821/2822). So you might not even have
seconds. You seem to want to buck the trend.
I hadn't realized that (I thought it was just for reading obsolete
messages). Slightly off topic, I wonder why the trend would be towards
less precision in time stamps? Doesn't that go against the purpose of
time stamps in the first place?
Yes. From the RFC, this is optional. Do you know any good reasons
why the ID might not be added to a Received line sometimes?
Umm, because it is optional. Past implementations have associated
the identifier with a set of files used in store-and-forward
processing. In some cases, messages might be handled w/o
any associated file storage, therefore no need for an id.
This is interesting. Presumably, when used for such a purpose, IDs would
be fairly random and unique in practice. On the other hand,
if the IDs are no longer used much, then repurposing them as random
tokens in future would not be met with too much opposition from MTA
implementors.
There also appears to be some confusion between "with"
(which specifies a protocol (SMTP, ESMTP, LMTP, etc.) and
"id" which provides an identifier of some sort (RFCs
821/822/2821/2822 all differ on what is allowed).
There is another way to include an "unguessable" token in Received lines
which doesn't do damage to the existing structure. MTA implementors
could include a specially formatted comment, which would contain
a random string.
There is precedent for this in RFC 2821, for example:
Extended-Domain = Domain /
( Domain FWS "(" TCP-info ")" ) /
( Address-literal FWS "(" TCP-info ")" )
The comment could be formatted in such a way that it's easy to scan
the Received line without needing to parse it. The presence of the
comment would be a guarantee from the MTA that the associated random
token is "unguessable", and there would be no need for others to rely on
assumptions about ID or date-time.
For example, we could have
Received: from 185129182.virtua.com.br (185129182.virtua.com.br
[200.185.129.182]) by smtpin-3211.bay.webtv.net (WebTV_Postfix+sws)
with SMTP id 7280B11DCC; Fri, 5 Mar 2004 19:00:48 -0800 (PST)
(random-seed ABCDEFGHIJKLMNOP)
where the unguessable value is ABCDEFGHIJKLMNOP, and a scanner looks
for the string "(random-seed ".
The downside is that existing MTAs don't include such a token, so there's
a natural delay in adoption. Of course, quoting the ID if present or the
date-time could be considered low grade protection intended for a transition
period, while the world upgrades its MTAs over time.
--
Laird Breyer.