Subject: [Emailcore] RFC 822 dates considered harmful ?

From: John C Klensin <[email-masked]>
Date: Wed, 14 Apr 2021 12:12:49 -0400

Hi.

I'm not sure what the right answer is to the question I'm about
to ask, but it feels like it is necessary to ask it.

The <date-time> specification of RFC 5322 [1] is, as recently
discussed on the ART list, an artifact of a much earlier time
[2].  It is confusing to both computers and humans and annoying
to parse [3].  The specification itself is often violated, with
<month day year> sometimes appearing instead of <day month year>
as required by the spec language and, more often, local
terminology or abbreviations for <day-name> and <month>
periodically creeping into header fields rather than merely in
presentation in MUAs.  While RFCs 6531 and 6532  do not address
dates at all, it seems likely that the situation will get worse
as we see SMTPUTF8 (EAI) implementations whose authors base them
on what they think the specs say (or should say) rather than
carefully studying those specs and their interactions with 5321
and 5322.

So, what is to be done?  Possibilities include:

(1) Ignore the issue and hope it goes away or, at least, does
not get worse.

(2) Make some comments, probably in the A/S, about the
importance of understanding and following the specs in this area
(and hope someone notices) and probably warning about the
(additional) confusion and other consequences of not doing so..

(3) Strongly encourage the use of an ISO 8601 date-time in a
comment after the required field, specifying that it should use
UTC ("Zulu") time only.

(4) Change the syntax to what we would, I think, specify today,
defining the current syntax as an obsolete feature and perhaps
encouraging its inclusion in a comment.

Personally, I have not reached a conclusion about preferences
among (2)-(4) (much less options that have not come to mind as I
wrote this note), but the more I think about the combination of
Internet Standards we don't expect will be revised again (ever)
and an increasingly global, multilingual, and multicultural
Internet, the more the first option feels irresponsible to me.

And, before the question is raised, I believe the current syntax
has proven itself to be confusing enough and that there is
sufficient non-conforming behavior out there to put
consideration of the issue in scope for the WG.

best,
    john

[1] RFC 5322 and draft-ietf-emailcore-rfc5322bis-01  Section
3.3.  

[2] See
https://mailarchive.ietf.org/arch/msg/art/NXIKnXDxgF7-RIMSUoYV04adMXk/

[3] See, e.g.,
https://mailarchive.ietf.org/arch/msg/art/AHEKrg1Sr98KrLWyAPWCE7umOYM

---

From: "John Levine" <[email-masked]>
Date: 14 Apr 2021 14:30:33 -0400

>(additional) confusion and other consequences of not doing so..

If we were starting over I agree that we should use ISO 8601 dates.
But we aren't, and I don't see how we are going to get MUAs and a
zillion random webmail programs to recognize an incompatible format.

How about if we pare down the definition of date-time to the minimum

  DD Mon YYYY HH:MM:SS +0000

and deprecate everything else including the optional day of week and
anything other than UTC. I would think this would be easier to explain
and easier for people to get correct.

I suppose we could define a conventional comment for the ISO date,
something like this:

  DD Mon YYYY HH:MM:SS +0000 (ISO:yyyy-mm-ddThh:mm:ssZ)

but I don't see much point.  There is tons of code that can parse the existing
date format so the main point is to make it easier for people to generate that
format correctly.  We might also add a note that the date-time is primarily intended
to be handled by software, not displayed directly, and software will generally
display it in a format convenient to users, e.g., in the local time zone.

R's,
John

---

From: "Peter J. Holzer" <[email-masked]>
Date: Wed, 14 Apr 2021 21:50:23 +0200

> to ask, but it feels like it is necessary to ask it.

If you knew the answer you wouldn't have to ask ;-).

> presentation in MUAs.

Is this actually I problem these days? I remember that problems like
this were quite common in the 1990s (probably bacause programmers were
unfamiliar with the concept of locales at the time), but I don't
remember when I last stumbled across a malformed date in an email
header (it is of course possible that I simply don't notice because the
software (including parsing libraries) I use is more forgiving than it
ought to be).

        hp

-- 
   _  | Peter J. Holzer    | Story must make more sense than reality.
|_|_) |                    |
| |   | [email-masked]         |    -- Charles Stross, "Creative writing
__/   | http://www.hjp.at/ |       challenge!"

---

From: "Kurt Andersen (IETF)" <[email-masked]>
Date: Wed, 14 Apr 2021 13:58:57 -0700

On Wed, Apr 14, 2021 at 9:13 AM John C Klensin <[email-masked]> wrote:

> defining the current syntax as an obsolete feature <delete this>and perhaps
> encouraging its inclusion in a comment</delete this>.
>

I'd be strongly in favor of option 4 but strike the idea of the additional
comment. Any mail system/MUA which does not adapt is apparently no longer
being maintained.

We know that there are a plethora of sending systems in that state but
that's what recognizing the old format as obsolete is for :-)

--Kurt

---

From: cketti <[email-masked]>
Date: Thu, 15 Apr 2021 18:41:46 +0200

On 2021-04-14 18:12, John C Klensin wrote:
> So, what is to be done?

How about a slightly different approach?

(5) Define new header fields, move current ones (as far as I can tell 
this concerns "Date" and "Resent-Date") to obsolete syntax. Define a 
transition period where MUAs should use both variants when creating 
messages. After a cutoff date MUAs should only create messages using the 
new header fields.
When reading messages and the new header fields are present MUAs must 
use those (and ignore the old header fields). The fallback behavior in 
case the new header fields contain invalid values and old ones are 
present should probably be defined. My preference would be not to fall 
back to the old header fields. That way problems with generating the new 
header fields are more likely to be detected before MUAs stop including 
both variants.

-cketti

---

From: "John Levine" <[email-masked]>
Date: 15 Apr 2021 14:52:59 -0400

>messages. After a cutoff date MUAs should only create messages using the 

That date would be about 2050, if we're lucky. Our experience with
forcing pepole to change, particularly when the current situation is
not broken in a way that affects meant people, is not encouraging.

R's,
John

---

From: John C Klensin <[email-masked]>
Date: Thu, 15 Apr 2021 23:31:25 -0400

--On Thursday, April 15, 2021 14:52 -0400 John Levine
<[email-masked]> wrote:

>> (5) Define new header fields, move current ones (as far as I
>> can tell  this concerns "Date" and "Resent-Date") to obsolete
>> syntax. Define a  transition period where MUAs should use
>> both variants when creating  messages. After a cutoff date
>> MUAs should only create messages using the  new header fields.
> 
> That date would be about 2050, if we're lucky. Our experience
> with forcing pepole to change, particularly when the current
> situation is not broken in a way that affects meant people, is
> not encouraging.

If I had to make a guess, 2050 is far too optimistic.  That is
why I was guessing that, if we were going to do anything at all,
it would have to be something involving a transition and/or
side-by-side strategy that people could add if they got customer
pressure and/or happened to be opening that area of code anyway.

best,
   john

---

From: John C Klensin <[email-masked]>
Date: Thu, 15 Apr 2021 23:36:50 -0400

--On Wednesday, April 14, 2021 21:50 +0200 "Peter J. Holzer"
<[email-masked]> wrote:

>> I'm not sure what the right answer is to the question I'm
>> about to ask, but it feels like it is necessary to ask it.
> 
>> [2].  It is confusing to both computers and humans and
>> annoying to parse [3].  The specification itself is often
>> violated, with <month day year> sometimes appearing instead
>> of <day month year> as required by the spec language and,
>> more often, local terminology or abbreviations for <day-name>
>> and <month> periodically creeping into header fields rather
>> than merely in presentation in MUAs.
> 
> Is this actually I problem these days? I remember that
> problems like this were quite common in the 1990s (probably
> bacause programmers were unfamiliar with the concept of
> locales at the time), but I don't remember when I last
> stumbled across a malformed date in an email header (it is of
> course possible that I simply don't notice because the
> software (including parsing libraries) I use is more forgiving
> than it ought to be).

I haven't seen the problem since, IIR, this afternoon.  It most
commonly shows up in a case that one can argue is just an MUA
botch rather than a 5322 violation, and that is replies where
the canonical date on the incoming message is localized and then
not un-localized on the way back out.   As I think I mentioned
in my note, I think I've also seen SMTPUFT8 /"EAI"
implementations that have gotten confused and those are, by
definition, a lot more recent than the 1990s.

    john

    john

---

From: cketti <[email-masked]>
Date: Fri, 16 Apr 2021 19:03:08 +0200

> not broken in a way that affects meant people, is not encouraging.

There's no point in picking a date where you estimate a significant 
number of implementations would have switched to the new behavior when 
it's convenient for them. The idea of picking a deadline is to add 
pressure. Maybe there is no pressure to change at first. But when MUAs 
start only using the new header field things will break for clients that 
didn't adapt. At that point they'll either update very quickly or 
they'll be left behind.
Of course this assumes that at least one major player adopts the change 
in order for there to be pressure on others.

But I agree that it's probably not worth it for date-time header fields.

---

From: John C Klensin <[email-masked]>
Date: Fri, 16 Apr 2021 13:51:43 -0400

--On Friday, April 16, 2021 19:03 +0200 cketti <[email-masked]>
wrote:

>> situation is not broken in a way that affects meant people,
>> is not encouraging.
> 
> There's no point in picking a date where you estimate a
> significant number of implementations would have switched to
> the new behavior when it's convenient for them. The idea of
> picking a deadline is to add pressure. Maybe there is no
> pressure to change at first. But when MUAs start only using
> the new header field things will break for clients that didn't
> adapt. At that point they'll either update very quickly or
> they'll be left behind.
> Of course this assumes that at least one major player adopts
> the change in order for there to be pressure on others.

On the one hand, your reasoning is quite consistent with the
decision to hold a "flag day" on January 1 1983 on which
carrying of NCP traffic on the Internet was discontinued.  It is
interesting (although probably not useful) to speculate on where
we would be had the decision to do that not been made.  E.g., if
we look at the rapid and complete conversation to IPv6 and note
that IPv6 has now existed longer than NCP lasted, it is tempting
to conclude that we would probably be running dual-stack or NCP
gateways and NATs to this day, eight bit address space and all.

But there is no way to select and enforce such a deadline today.
In a world of voluntary standards there is every reason to
believe that the response to "those headers are obsolete and you
MUST use this set" would be thanking us for our advice (or
questioning our sanity) and then ignoring the new spec.   And
that is why, at least IMO, changes to existing, widely-deployed,
and already standardized protocols should be documented with the
compelling reasons for making the change.  And the changes
themselves should be designed to make it easy for older and
newer implementations to co-exist.  If the reasons are good
enough, some implementations will add the new facilities and
other implementation will do so, either for the same reason or
for better compatibility with the enhanced features of the early
adopters.  And, then, if it takes the laggard implementations
the 28 years John Levine posited to get around to making the
changes... well, who cares other than their users?... and those
users presumable could decide to vote  with their feet.

> But I agree that it's probably not worth it for date-time

Yeah.  But the fact that it is not should not prevent us from
discussing other types of changes/ improvements to those fields.

best,
   john

---

From: "Peter J. Holzer" <[email-masked]>
Date: Sat, 17 Apr 2021 13:33:40 +0200

On 2021-04-15 23:36:50 -0400, John C Klensin wrote:
> not un-localized on the way back out.

I don't think I understand what you mean. "The way out" for a MUA would
be either displaying a mail (which is outside of the scope of RFC 5322)
or sending a mail (in which case it would generate a new Date header,
not re-use one from a message it received). Can you be a bit more
specific on what (presumably) happens here?

I wrote a litte test script and ran it on about 70000 messages from the
last 30 days (from two sites, mixture of spam and ham).

By far the most common syntax error (202 occurences) was that the hour
was only one digit (e.g. "5:12:34" instead of "05:12:34"). 

8 Messages didn't have a Date header at all.

3 had a negative hour (e.g. "Mon, 29 Mar 2021 -1:01:33 -0400").

2 were missing the time zone.

1 had an invalid time zone ("EEST")

1 had the string "Date:" duplicated.

I found no instances of localized day or month names. Both sites are in
Austria, where English is not the primary language.

> As I think I mentioned in my note, I think I've also seen SMTPUFT8
> /"EAI" implementations that have gotten confused and those are, by

Neither site supports SMTPUTF8, but I don't see how that would change
anything (the Date header is normally created by the client or the
submission server and not changed in transit).

This is of course a very small and non-representative sample. I think it
does illustrate that the problem is at least unevenly distributed,
though.

        hp

---

From: John C Klensin <[email-masked]>
Date: Sat, 17 Apr 2021 11:15:04 -0400

Peter,

First, let me concede, if I had not made it clear already, that
really serious problems with the Date: header field, other than
omitting it entirely, are rare.  What I have seen is by no means
a systematic sample and stretches back at least a year or three.
Even then, your results are, with one exception, consistent with
mine.

And, again, my goal was to ask a question about whether we
wanted to consider doing something in this area, not to advocate
any particular course of action (or even any action).

More inline below.

--On Saturday, April 17, 2021 13:33 +0200 "Peter J. Holzer"
<[email-masked]> wrote:

>> >> The <date-time> specification of RFC 5322 [1] is, as
>> >> recently discussed on the ART list, an artifact of a much
>> >> earlier time [2].  It is confusing to both computers and
>> >> humans and annoying to parse [3].  The specification
>> >> itself is often violated, with <month day year> sometimes
>> >> appearing instead of <day month year> as required by the
>> >> spec language and, more often, local terminology or
>> >> abbreviations for <day-name> and <month> periodically
>> >> creeping into header fields rather than merely in
>> >> presentation in MUAs.
>...
> I don't think I understand what you mean. "The way out" for a
> MUA would be either displaying a mail (which is outside of the
> scope of RFC 5322) or sending a mail (in which case it would
> generate a new Date header, not re-use one from a message it
> received). Can you be a bit more specific on what (presumably)
> happens here?

Maybe fuzzy thinking on my part in interpreting what I have
seen.  Maybe some members of the broad class of MUAs (see below)
that are stranger than you assume.  Probably you should just
ignore that part of my comments.
 
> I wrote a litte test script and ran it on about 70000 messages
> from the last 30 days (from two sites, mixture of spam and
> ham).
> 
> By far the most common syntax error (202 occurences) was that
> the hour was only one digit (e.g. "5:12:34" instead of
> "05:12:34"). 

It that, or omission of the date header fields entirely (which I
see more often but that just demonstrates that we are seeing
different batches of messages), it would, IMO, still be worth a
brief discussion of whether those things were worth pointing out
(probably in the A/s) and either cautioning sending systems
about getting it wrong or encouraging receiving systems to be
extra-liberal.  Again, recommending a discussion, not a
particular decision.

> I found no instances of localized day or month names. Both
> sites are in Austria, where English is not the primary
> language.
 
>> As I think I mentioned in my note, I think I've also seen
>> SMTPUFT8 /"EAI" implementations that have gotten confused and
>> those are, by definition, a lot more recent than the 1990s.
> 
> Neither site supports SMTPUTF8, but I don't see how that would
> change anything (the Date header is normally created by the
> client or the submission server and not changed in transit).

It changes two things.  One is that a few SMTPUTF8
implementations (albeit ones with large numbers of
users/customers) have either been fairly sloppy or have
optimized for the perceived convenience of their users rather
than for adherence to the strict letter of the standards.  That
is further complicated by an operational issue and/or a question
about choices of mail models.  Suppose a mail services operator
runs their own mail repository which their users access only via
web interfaces or clients that they supply.  If one of those
users sends a message to another, they are arguably not sending
"Internet mail" and whatever they do is not constrained by
either 5321 or 5322 (including "Date:".   header field formats
and dates in time-stamp fields if they used the latter at all).
That view of the world would create a situation in which mail
sent so a non-customer would, in the model of 5321, be passing
through a gateway and that provider would be obligated to
convert to standard form at the boundary.  But we know of at
least one large email provider who routinely ignores those
requirements and lets their internal information and formats
leak, so there is not much reason to expect that other providers
will be more careful and scrupulous, especially when a higher
percentage of their mail messages are among their users.  And,
btw, if that is a gateway situation, it is not even clear that,
if time-stamp-like information is supplied for handling of the
message before it passes into the Internet, the syntax and
content of that information are constrained by 5321/5322 such
that reinterpretation and conversion are required.  The second
is that, while I note your comment about English in Austria, the
temptation and incentives for using local month names (and local
day names when supplied) are much higher when those local names
are in non-Latin scripts and especially when the local
populations may not be even vaguely familiar with the English
names.

> This is of course a very small and non-representative sample.
> I think it does illustrate that the problem is at least
> unevenly distributed, though.

Indeed.

It may also suggest something that goes far beyond dates: It
might be wise for 5322bis to be much more clear and forceful
that its field names and keywords are fixed strings and that,
while MUAs (or equivalent) are free to do whatever they like to
present information in user-convenient localized form, their
ability to do that is dependent on everyone following the rules
about what goes over the wire.  It may also suggest that the A/S
offer guidance about what a receiving system should do if
mandatory fields (including any of Date:, From:, and at least
one of To: or Cc:) are missing.  Do we have advice about whether
such a system should make up values and insert those header
fields and, if so, what information should it use to infer those
values?  Or do we prefer that the message be rejected as
incomprehensible or otherwise managed as trash?

best,
   john

---

From: "Peter J. Holzer" <[email-masked]>
Date: Sat, 17 Apr 2021 22:11:33 +0200

> extra-liberal.  Again, recommending a discussion, not a

Putting some emphasis on that in the A/S would certainly be a good idea. 
We could also put a sentence like "Please note that the day and month
names MUST be spelled exactly as specified and MUST NOT be localized" in
RFC5322bis. However, I'm a bit dubious on whether it would help. It's
already rather clear IMHO, and people who ignore what's already there
are likely to ignore that extra sentence, too.

As for a new date format, I don't think that would help at all. The
current format is a bit baroque by current standards, but not that hard
to produce or parse (at least if you ignore the obsolete forms), and as
others have pointed out a new format would just be an additional format
for decades, so it would decrease interoperability. (Speaking of
decades: Can we get rid of the obsolete forms? The only obsolete feature
I see with any frequency is "GMT" as the time zone.)

> Suppose a mail services operator runs their own mail repository which
> their users access only via web interfaces or clients that they
> supply.  If one of those users sends a message to another, they are
> arguably not sending "Internet mail" and whatever they do is not
> constrained by either 5321 or 5322 (including "Date:".   header field
> formats and dates in time-stamp fields if they used the latter at
> all). That view of the world would create a situation in which mail
> sent so a non-customer would, in the model of 5321, be passing through
> a gateway and that provider would be obligated to
> convert to standard form at the boundary.

Gateways are of course always a bit tricky (I remember that it was often
quite obvious that Lotus Notes was internally using a very different
structure than RFC5322). I would generally expect the problem areas to
be elsewhere, though. The date header is just a simple timestamp,
nothing which requires much thought (OTOH, that might be the problem:
Converting the MIME structure was discussed among senior developers;
converting the Date header was probably assigned to the intern).

> But we know of at least one large email provider who routinely ignores
> those requirements and lets their internal information and formats
> leak, so there is not much reason to expect that other providers will
> be more careful and scrupulous, especially when a higher percentage of
> their mail messages are among their users.  And, btw, if that is a
> gateway situation, it is not even clear that, if time-stamp-like
> information is supplied for handling of the message before it passes
> into the Internet, the syntax and content of that information are
> constrained by 5321/5322 such that reinterpretation and conversion are
> required.  The second is that, while I note your comment about English
> in Austria, the temptation and incentives for using local month names
> (and local day names when supplied) are much higher when those local
> names are in non-Latin scripts and especially when the local
> populations may not be even vaguely familiar with the English names.

True. But I notice that most MUAs don't just display headers as they
are: They are parsed into some internal format and then that is
rendered (possibly with localization) onto the screen. So there is no
"From:" but an "Absender", and the email address may not even be
displayed (only the name). Similarily, the Date header is usually
converted to local time and displayed according to local conventions.
(I'm using mutt, which is of course an exception.)

For a system that is mostly an internal messaging system with an
SMTP-Gateway bolted on I would expect that to be the case even more. For
example, most traditional date formats are horrible for sorting. So
internally they would probably use a nice monotonic numerical format
(like Unix time_t or Julian days). But I don't know the internals of any
such system, so this is just speculation.

        hp

---

From: Alessandro Vesely <[email-masked]>
Date: Sun, 18 Apr 2021 20:25:18 +0200

On Wed 14/Apr/2021 18:12:49 +0200 John C Klensin wrote:
> to parse [3].

Is it?  I don't think so.

For one thing, sometimes I have to look at the Date: header in the raw message, 
because my mail client translates dates to the local timezone (see the very 1st 
line of this message).  Thereby, the client hides what was the actual local 
time when the message was composed.  In this respect, RFC5322.Date as-is 
carries more info than if it used UTC ("Zulu") time only.

> (1) Ignore the issue and hope it goes away or, at least, does

Which issue?

jm2c
Ale
-- 

> [1] RFC 5322 and draft-ietf-emailcore-rfc5322bis-01  Section 3.3.  
> 
> [2] See

---

From: John C Klensin <[email-masked]>
Date: Mon, 19 Apr 2021 10:10:47 -0400

Again, not advocating a particular decision, just trying to be
sure we all understand the question in the same way. ...

--On Sunday, 18 April, 2021 20:25 +0200 Alessandro Vesely
<[email-masked]> wrote:

>> annoying to parse [3].
> For one thing, sometimes I have to look at the Date: header in
> the raw message, because my mail client translates dates to
> the local timezone (see the very 1st line of this message).
> Thereby, the client hides what was the actual local time when
> the message was composed.  In this respect, RFC5322.Date as-is

Yep.  Sometimes Zulu is best, sometimes you want to know the
local time of the sender when the message was sent, and
sometimes you want to know your (the recipient's) local time
when the message was sent.  The question I was asking was about
moving to, or supplementing the date with, ISO 8601-formatted
date and time, not eliminating the reference to local time,
which is, at best, a separate question.

> Which issue?

The issue that dates, as specified in RFC5322, have poor
internationalization/localization properties.  Although, as you
more or less point out, if one can parse them, one can convert
to local formats and convert back -- that is about whether it is
important to make a change, not about whether the format is
inconvenient.

best,
   john

---

From: "John Levine" <[email-masked]>
Date: 19 Apr 2021 10:35:22 -0400

>important to make a change, not about whether the format is

It is my impression that most MUAs parse the date header and redisplay it
in a local format.  Even Alpine, which has a pretty minimal user interface,
does that.  I also see that a lot of mail systems seem already to do what
I suggested, use a minimal version of the date  DD Mon YYYY HH:M:SS +0000

If everyone's reparsing the dates anyway, it doesn't much matter what the
internal date format is, so I think it makes sense to recommend the simplest
one consistent with the current spec.

R's,
John

---

From: Ned Freed <[email-masked]>
Date: Mon, 19 Apr 2021 07:38:38 -0700 (PDT)

> one consistent with the current spec.

Agreed. And this needs to be done in the AS document, for several reasons:

(1) It's what applicability statements are *for*.

(2) The idea of moving stuff like the leading weekday to the obsolete
    syntax may seem attractive, but would in fact be an interoperability
    disaster as new implementations appear that fail to accept obsolete
    syntax (no matter that the standard says they're supposed to) and
    the gazillion existing implementations fail to upgrade.

    This is an especially serious concern because right now the stuff
    in the obsolete syntax is for the most part something implementations
    *can* ignore and get away with it. A subsetting of the Date:
    field syntax, OTOH, is nothing of the sort.

(3) The idea of putting an RFC 3339 timestamp in a comment is the very
    definition of a silly state generator. Although I admit it might
    be amusing - for some value of the word "amusing" - to see the
    effect of code written like this:

       time(&currenttime);
       // Use currenttime to generate the RFC 5322 date/time
       time(&currenttime);
       // Use currenttime to generate the RFC 3339 date/time

    on various implementations.

    Implementations that assume the content of the comment is a time
    zone make will also produce some interesting results.

    I will also note that historically parsing of comments in Date:
    fields has been a big source, if not the biggest source, of
    bugs. (The implementation that added the time zone offset
    specified by the comment and the one in the actual date-time
    specification was particularly problematic.)

    I also don't see what this buys us - even assuming we could
    get traction on putting this information in, do we then
    expect it to then be used preferentially? I'm sorry, but
    I don't see that happening, at least not on a timescale
    short enough to matter.

(4) Absent this being a major, ongoing problem - and I've seen no
    evidence that it is or is becoming a major problem - makes
    anything other than AS text out of scope according to our
    current charter.

				Ned

---

From: Steffen Nurpmeso <[email-masked]>
Date: Mon, 19 Apr 2021 18:55:48 +0200

John Levine wrote in
 <[email-masked]>:
 |It appears that John C Klensin  <[email-masked]> said:
 |>The issue that dates, as specified in RFC5322, have poor
 |>internationalization/localization properties.  Although, as you
 |>more or less point out, if one can parse them, one can convert
 |>to local formats and convert back -- that is about whether it is
 |>important to make a change, not about whether the format is
 |>inconvenient.
 |
 |It is my impression that most MUAs parse the date header and redisplay it
 |in a local format.  Even Alpine, which has a pretty minimal user interface,
 |does that.  I also see that a lot of mail systems seem already to do what

The even more minimal POSIX mailx also do this.  (Apple, OpenBSD
etc. do not since their Mail has never stepped beyond the very
basic implementation.)  The one i maintain does not dig obsolete
zone names (as of 4.3), the NetBSD Mail variant even knows about those.
(On the other hand NetBSD's version uses their sophisticated
non-portable strptime() to parse the date as such, whereas we
unroll the code on our own.)

 |I suggested, use a minimal version of the date  DD Mon YYYY HH:M:SS +0000
 |
 |If everyone's reparsing the dates anyway, it doesn't much matter what the
 |internal date format is, so I think it makes sense to recommend the \
 |simplest
 |one consistent with the current spec.

Day of week we simply skip (converting to time_t directly, whereas
NetBSD Mail fills in a struct tm* and uses timegm(3), therefore
verifying validity of wday, too).  Anyhow, we all localtime(3).

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 19 Apr 2021 20:52:41 +0200

On Mon 19/Apr/2021 16:10:47 +0200 John C Klensin wrote:
> --On Sunday, 18 April, 2021 20:25 +0200 Alessandro Vesely wrote:

IMHO, RFC5322.Date has an excellent readability.  I think all the people who 
can understand the meaning of "Date" can also understand the content of average 
header fields bearing than name.

It is a formatted field.  If we change format, we'd better change the name as 
well.  We cannot recommend this:

日期: 2021年4月19日星期一10:10:47 -0400

because field names must be in English.  Breaking compatibility for a 
half-baked internationalization attempt doesn't seem to be good.

To publish an A/S to state that formatted fields should be parsed and their 
meaning rendered in a localized form wood look like an exercise of style.

Best
Ale
--

---

From: Keith Moore <[email-masked]>
Date: Mon, 26 Apr 2021 20:47:43 -0400

> (additional) confusion and other consequences of not doing so..
If it helps to clarify the specification while keeping the format the 
same, by all means do so.   But that's not the same thing as ignoring 
the issue and hoping it will go away.
> comment after the required field, specifying that it should use
Strongly disagree.

The first lesson I learned in engineering school, in an engineering 
drawing class, was (as best I can recall the wording) "don't dimension 
the same point or line relative to more than one reference".   This 
lesson hit home because I had already made that mistake, in naively 
drawing up something to be built (a extra console for a planetarium).   
The result was exquisitely crafted, and simply did not fit and could not 
be made to fit where it needed to fit.   I didn't realize the nature of 
my mistake until I actually started taking engineering classes.   Even 
though I've rarely used the drawing skills they painstakingly taught me, 
that hugely important lesson has stuck with me.   The generalization of 
this is "don't define the same thing in more than one way".

Or there's the old saying "A person with one watch knows what time it 
is, a person with two watches is never certain."

Don't duplicate the date-time in another format, not in a comment, not 
in another header field.   Have exactly one indication of the date that 
the message was sent.

> encouraging its inclusion in a comment.
Strongly discourage this also.   There's nothing wrong with the current 
format.

> and easier for people to get correct.
I could see discouraging the inclusion of the day-of-the-week (while 
still making it optional), as it's redundant at best and creates 
unnecessary errors at worst.

I don't support getting rid of the timezone offset and normalizing 
everything to GMT, first because it's error-prone, and second because 
the timezone of the originator is actually useful to the recipient (even 
though, sadly, many mail readers try to hide such information).

cketti wrote:

> messages. After a cutoff date MUAs should only create messages using 
> the new header fields. 

No, please no.   In addition to having two sources of the same 
information (see above), it would accomplish nothing beyond adding 
additional complexity and failure states.  MUAs need to be able to read 
messages that are decades old because some people keep email around 
forever, and messages can be archived for historical purposes.

If there's any benefit to simplifying the message format, it's in making 
new generators of email less likely to produce errors. It does nothing 
for email readers that generally need to be able to read things at least 
as old as RFC822 format (including pre-DNS email addresses) and maybe 
even RFC733 format (e.g. with " at " permitted between local-part and host).

John Klensin again:

> internationalization/localization properties.
If we wanted to fix this I'd say add the Olsen timezone as a comment 
following the GMT offset.   But there are too many (IMO broken) MUAs 
that already believe it is a Good Thing to hide the original timezone 
from the recipient (as well as much else that is valuable, like the 
sender's and recipients' email addresses).   And large numbers of hosts 
(think both mobile devices and IoT appliances) have a hard enough time 
getting their GMT offset right.   If the value is likely to be wrong, 
it's better to not include it at all than for the sending host (or 
worse, some intermediary) to guess.

John Levine:

> does that.
Just because "most" MUAs do something doesn't mean it's a good idea.  
I'm fairly appalled at the behavior of some MUAs that insist on hiding 
useful information from recipients for the sake of... something.   
Probably to make it fit on tiny screens or something.

IMO the usefulness of email has been seriously degraded by several 
factors, one of which is that MUAs are much less functional than they 
used to be.   Let's not try to encourage more of that.

>      field syntax, OTOH, is nothing of the sort.
There's something to be said for not making the specifications 
(especially the portion that mail readers have to pay attention to) any 
more complex than they already are, because this seems to have the 
effect of making implementations buggier.

Dave Crocker:

> The mere fact that a protocol or format was designed a long time ago 
> does not mean it needs to be replaced. And displacing a specification 
> that has been in global use for 45 years ought to set a very high bar 
> and demand quite a bit of clear and compelling basis for replacing it. 
+1 to both.   And IMO we should consider a specification that has been 
mostly stable for 45 years and continues to be in widespread use a huge 
success story, rather than an indication that something is wrong.   IETF 
needs more success stories like this.

***

Regarding the use of the word "obsolete" to describe once common syntax 
that is less favored today: Consider "legacy" as an alternative, and try 
to make it clear that readers need to continue to support that syntax 
indefnintely.   I agree that "obsolete" conveys the wrong impression.

Alessandro Vesely:

> It is already quite difficult to find correct implementations for the 
> accepted grammar.  Requiring that obs- be also implemented can push 
> compliance so far that no programmers will want to tackle it.  
> Perhaps, proposing a reachable target can improve parsers quality... 

Sounds like we need pointers to some reference implementations.   These 
days it's rare that anyone should need to implement a protocol entirely 
from the specifications.

John Levine:

> I can't recall the last time I saw a route in an address, or a space
> before the colon in a header in non-spambot mail.

I have, on multiple occasions within the past five years, been required 
to read copious volumes of email dating from the 1980s, and testify to 
its likely authenticity or lack thereof.   I can't recall the last 
occasion I saw such a message in current email, but it's still necessary 
to be able to read email dating from decades ago.   And this will become 
even more necessary in the future as more and more of our historical 
records exist only in digital form.

(And just an aside, it's Really Unfortunate when the very program that 
the lawyers use to print out email, corrupts and/or hides the details 
needed to convince the court of a message's authenticity... like 
timezone information.   Then experts get to explain why the presented 
exhibits are wrong and should not be accepted as faithful copies of the 
originals.   Especially when archiving information, but also when 
reading archived information, it's vitally important to preserve the 
information in original format if at all possible.)

Keith

---

From: Ned Freed <[email-masked]>
Date: Mon, 26 Apr 2021 18:23:19 -0700 (PDT)

> the issue and hoping it will go away.

+1. As I said previously, this is what an AS is there to do.

> in another header field.   Have exactly one indication of the date that

As I noted before, it's quite easy to end up with code that usually,
but not always, produces the same time stamp.

> Strongly discourage this also.   There's nothing wrong with the current

And even if there were, it would have to be very very wrong in order to justify
a recharter of the WG in order to have the leeway to do this.

> > and easier for people to get correct.

If we had a mechanism for this, perhaps. But we don't. Obsolete
syntax is not an option.

> though, sadly, many mail readers try to hide such information).

Yep. 

> forever, and messages can be archived for historical purposes.

And they also select messages from archives and forward them.
I've seen decades-old mesages resurrected and forwarded.

The fact that this works is actually a tribute to the quality of the design.
Try doing something similar with decades old word processing files and
see what happens.

Like it or not, there's no way to prevent essentially any part of
the email infrastructure from being exposed to old messages.

> worse, some intermediary) to guess.

It has taken decades for calendar apps to (mostly) get this right, and unlike
MUAs, where date/time displays are a UI detail, they're central to a calendar
app.

> Probably to make it fit on tiny screens or something.

Right, like hiding addresses in favor showing the preceeding phrase.

> days it's rare that anyone should need to implement a protocol entirely

We really need to pay more attention to this fact in our discussions. People
rarely write MUAs from scratch any more; they rely on libraries to do most of
the parsing, message construction, and so on.

This is great when the library is high quality. OTOH, it's terrible when the
library stinks, because libraries can be very difficult to upgrade.

> records exist only in digital form.

It would be "today" for me, but that's because we use source routes
internally. OTOH, I still see %-hacks pretty regularly. Bang paths
seem to have died, thank goodness.

Spaces before the colon still show up from time to time. We notice
because they don't interact well with milter.

				Ned