Nylas-mail: BAD HEADER SECTION Missing required header field: "Date"

[gldtn]

Sometimes when I send e-mails It gets quarantine due to header 'date' field.

X-Envelope-To: <***@*****.com>
X-Envelope-To-Blocked: 
X-Quarantine-ID: <wXS5tLFPz6pb>
X-Amavis-Alert: BAD HEADER SECTION, Missing required header field: "Date"
X-Spam-Flag: NO
X-Spam-Score: -1
X-Spam-Level: 
X-Spam-Status: No, score=-1 tag=-5 tag2=6.2 kill=6.9 tests=[ALL_TRUSTED=-1,
    SHORTCIRCUIT=-0.0001] autolearn=disabled
Received: from mail.******.org ([127.0.0.1])
    by localhost (mail.******.org [127.0.0.1]) (amavisd-new, port 10024)
    with LMTP id wXS5tLFPz6pb for <info@*****.com>;
    Mon,  1 Feb 2016 11:24:40 +0900 (JST)
Received: from [127.0.0.1] (ec2-52-32-74-203.us-west-2.compute.amazonaws.com [52.32.74.203])
    (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
    (No client certificate requested)
    (Authenticated sender: ***@*****.org)
    by mail.****.org (Postfix) with ESMTPSA id 4C25DA4
    for <***@*****.com>; Mon,  1 Feb 2016 11:24:38 +0900 (JST)
Authentication-Results: dkim.*****.org; dkim=permerror (bad message/signature format)
User-Agent: NylasMailer/0.4
Message-Id: <[email protected]>
X-Inbox-Id: 5no4n44e9mmp825j3qeepmkwa-0
To: "info@*****.com" <info@*****.com>
From:  Gldtn <gldtn@******.org>
Subject: J********* N******
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="a1db34d4c2a34e7893865c11cbea56b2"

I did not find anything in the setting about this.. How can I solve this?

Thanks!

[dionysius]

Just discovered this too. This is a quite hurrying IMO because this field is defined mandatory by RFC5322 (section 3.6):

The only required header fields are the origination date field and the originator address field(s). All other header fields are syntactically optional.

[stark-dev]

Same problem here! It happens only with IMAP accounts, GMail works fine for me

[elehcim]

Also for me for my IMAP account.

[JoshHarmon]

This is a major issue because not adding a Date header causes any server running SpamAssassin to apply a -1.396 rule (see), which is rather damaging unless you have other positive tests making up for it (thank god I'm listed on DNSWL). If you do anything else that could _seem_ spammy, you run a realistic risk of messages going to spam folders.

I suspect Gmail accounts don't have this issue because Google tries to fix broken headers for you.

[grinich]

Thanks for the detail here! We were in fact depending on the MTA to add this header. (Gmail and others do.)

I just pushed a patch which manually adds this on all outgoing mail for SMTP accounts.

[JoshHarmon]

Thank you @grinich! Super thankful for your quick response to this. At any rate, depending on the MTA to add the header is in fact not what the RFC 2822 demands. The MUA is supposed to add it so that if the user is offline or a message is queued, the "intended" send time is in the Date header, rather than the time it entered transport.

Source - RFC 2822 Sec. 3.6.1:

The origination date specifies the date and time at which the creator
of the message indicated that the message was complete and ready to
enter the mail delivery system. For instance, this might be the time
that a user pushes the "send" or "submit" button in an application
program. In any case, it is specifically not intended to convey the
time that the message is actually transported, but rather the time at
which the human or other creator of the message has put the message
into its final form, ready for transport. (For example, a portable
computer user who is not connected to a network might queue a message

[grinich]

In practice, it seems that a decent number of mail apps will use the received date to sort mail since there's no way to actually verify a user-set Date header. This is what we do in N1.

For all IMAP accounts, we actually used the received date to set the date value returned by the sync engine's API. Although allowing senders to set an "intended sent time" is a cool feature, we have only seen it used for abuse or confusion.

If you need a custom date header to be set for messages which are queued when you are offline (as opposed to setting them to the sending time when you come back online) then you should use a different app. We've made a design compromise not to support that use case.

[JoshHarmon]

I'm not personally worried about the implementation of the Date header (I'm just glad it's added!). I just wanted to bring up the RFC because I had no idea that previous abuse led to the actual received time being used by applications (although the logic for that does make sense).

Once again, thank you for your time to resolve this. I'm glad that I can continue to use N1 without it hurting the deliverability of my emails.