Good evening,
I am using isync/mbsync to fetch my emails, and throws the following error with
Fastmail (that I don't see with others like GMail):
> IMAP error: unable to parse INTERNALDATE format
With the verbose output, I get:
> * 66 FETCH (UID 74 INTERNALDATE " 5-Dec-2023 08:02:58 -0500" BODY[] {53866}
Note how the date begins with a white space (" 5-Dec"). It actually happens only
during the 1-digit days of the month. I traced the error down to this line [1]
in isync:
```
if (!(end = strptime( str, "%e-%b-%Y %H:%M:%S ", &datetime )))
```
The problem is clear: the parser does not expect the date to start with a white
space. The fix, however, is less clear to me: is that a bug in isync, or is the
date badly formatted in the emails I receive through Fastmail?
Let's look at a (redacted) sample header that reproduces the issue:
>Received: from mx5 ([15.102.1.34])
> by compute1.internal (LMTPProxy); Fri, 05 Jan 2024 16:48:38 -0500
> Received: from mx5.messagingengine.com (localhost [127.0.0.1])
> by mailmx.nyi.internal (Postfix) with ESMTP id DACD72720075
> for <m...@mydomain.com>; Fri, 5 Jan 2024 16:48:37 -0500 (EST)
Somehow the date first appears as "Fri, 05 Jan 2024 16:48:38 -0500", and then as
"Fri, 5 Jan 2024 16:48:37 -0500 (EST)". Note that the '0' was replaced by a
white space, ending up with two white spaces between "Fri," and "5 Jan". If this
is a valid date format, then I need to contribute a fix in isync. But is it
valid?
I tried to find the specifications for a date, and ended up on RFC5322 [2],
which defines:
```
date-time = [ day-of-week "," ] date time [CFWS]
```
To me, this looks like only one white space is allowed between `[ day-of-week
"," ]` and `date`.
I contacted Fastmail to have their opinion (because again, I don't get two white
spaces with other providers like GMail), and they closed my issue with the
following:
> RFC 5322 is clear that day is 1-2 digits, preceded by optional folding
> whitespace. If present, the definition of folding whitespace allows it to be
> 1 or more spaces, despite the fact that a single space is recommended.
> Basically, these dates are in a technically valid format irrespective of how
> 3rd party apps parses them.
My understanding of a "folding white space" from (amongst others) RFC2822 [3] is
that it implies a carriage return (CRLF), and it is *not* the same thing as a
white space character:
> The general rule is that wherever this standard allows for folding white space
> (not simply WSP characters), a CRLF may be inserted before any WSP.
In that sense, my current understanding is that the dates that isync fails to
parse are indeed invalid, according to the specifications. Consequently, it
would be wrong for me to "fix the parser in isync", as Fastmail suggests is the
"correct action".
I am writing in this mailing list because the header mentions "(Postfix) with
ESMTP", and I figured that maybe this date conversion happens in Postfix and not
in any Fastmail code.
I would really appreciate if somebody here could tell me whether this date
format that isync fails to parse is valid according to the specs or not. If it
is valid, I will gladly send a patch to isync. If not, then I must say I don't
know what codebase is generating this date (could it be Postfix?) and would be
happy to get advice.
Best Regards,
Jonas Vautherin
[1]: https://sourceforge.net/p/isync/isync/ci/1.4/tree/src/drv_imap.c#l1052
[2]: https://www.rfc-editor.org/rfc/rfc5322#section-3.3
[3]: https://datatracker.ietf.org/doc/html/rfc2822#section-2.2.3
_______________________________________________
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
