Topic: Mail with no Date header not accepted here

[Smitro]

I've run into this problem where I have a couple of devices that are trying to send me notification emails, but the devices I know is not made properly, and the emails are rejected with the following errors.

"Mail with no Date header not accepted here".

I've found a way for allowing these emails through (although I havn't tried it yet)
http://wiki.contribs.org/Email#I_can.27t_receive.2Fsend_email_from_my_application_.28ACT.21.2C_vTiger.2C_MS_Outlook.2C_etc.29

But, I realise this is a good rule to have in place so I don't want to remove it completely. At the moment the devices that are trying to send email are my Scanner and also my Router. One is for notifications, and the other scanned jobs.

Is it possible to make the rule only apply to that device's IP address? I've tried putting the device's IP address in the Mail Server's white list, but that didn't work. Is there anything else I can try?

[janet]

Smitro

Please lodge a New Feature Request (NFR) in bugzilla. You might get lucky.

[Smitro]

Thanks Mary, as suggested. I've created Bug 6116
http://bugs.contribs.org/show_bug.cgi?id=6116

Interesting thing is... I've been googling this to see how the rest of the world deals with such an issue. It seems that most search results are coming back with the contribs site (forums, bugs and wiki). There are some others but not as many. Is this a SME thing? or is this standard practice? or does SME word it's error different to others and my search term is too specific.

[CharlieBrady]

Is this a SME thing? or is this standard practice?

Neither.  It's a spam detection feature which is specific to qpsmtpd, which is used by SME server, and some hundreds or thousands of other mail servers, including such big sites as perl.org and apache.org. It can't be called 'standard practice', because qpsmtpd isn't used by most mail servers, which continue to accept illegally formatted messages (ones which don't contain a Date or From header).

[BossHog]

Howdy,
Smitro, FWIW, the suggestion in the wiki works as expected.
I have a device on my LAN which shows the same poor Date Header antics.
After following the How To, it works fine.
However, this device is on the LAN behind an SME, not sure I would be
so adventurous with opening up the WAN side in such a manner.
Joe

[mrkiwi]

Neither.  It's a spam detection feature which is specific to qpsmtpd, which is used by SME server, and some hundreds or thousands of other mail servers, including such big sites as perl.org and apache.org. It can't be called 'standard practice', because qpsmtpd isn't used by most mail servers, which continue to accept illegally formatted messages (ones which don't contain a Date or From header).

Also, and more importantly ... Having a date header is MANDATORY - microsoft, ricoh, PABX manufacturers and everyone else who writes a poor mail implementation need a slap with the RFCs. If anyone asks you to reconfigure your email server to accept their malformed mail, tell them to read the RFCs.

[Michail Pappas]

Sorry to open up this thread, but it seems it's spot on (although my platform is SME 8 and not 7):

Also, and more importantly ... Having a date header is MANDATORY ...

Is it? I've stumbled upon the exact same scenario. There are a number of apps, which send mail without a Date field. I also was under the impression that the date field was mandatory. But then I came upon this passage in the SMTP standard (RFC2812, section 3.3)

When RFC 822 format [7, 32] is being used, the mail data include the
memo header items such as Date, Subject, To, Cc, From. Server SMTP
systems SHOULD NOT reject messages based on perceived defects in the
RFC 822 or MIME [12] message header or message body. In particular,
they MUST NOT reject messages in which the numbers of Resent-fields
do not match or Resent-to appears without Resent-from and/or Resent-
date.

If I understand correctly, does this mean that sme should not reject messages if the Date field is absent? Am I correct in assuming Charlie's response summarizes what happens here? That is, the specific qpsmtpd plugin enforces an non-SMTP compliant behaviour, in order to gain other benefits (ie anti-spam improvements)?

[mrkiwi]

My 2c ...

Given that you were looking in RFC2812 (Internet Relay Chat) i wouldn't have thought that directives such as "SHOULD NOT" in there apply to RFC 822. It seems to me
that IRC borrows the email RFC and then relaxes a rule, which would not relax the rule in 822?

[CharlieBrady]

Given that you were looking in RFC2812 (Internet Relay Chat) i wouldn't have thought that directives such as "SHOULD NOT" in there apply to RFC 822.

RFC2812 is a typo - Michail quoted from RFC2821 (as you could have quickly confirmed).

RFC2821 dates from 2001, when the spam problem was relatively new. I don't think we should be bound by the "SHOULD NOT" recommendation, which is questionable anyway - is total absence "a perceived defect" in the Date header?

[Michail Pappas]

I don't think we should be bound by the "SHOULD NOT" recommendation, which is questionable anyway - is total absence "a perceived defect" in the Date header?

Not sure here, hence for my question. To provide some more details here, I have this application which sends personalized reports to each employee by email. This application calls Outlook Express (AFAIK) via MAPI calls to send email. End result is that no Date field exists and, as such, users do not receive email on SME.

Here's the deal: the program developers insist that this is not a bug per se, since according to RFC2821 these mails SHOULD NOT be blocked in the first place. Therefore, "deviation" of qpsmtpd from the standard gives the developer the capability to avoid having to do the right thing...

Don't get me wrong, I do agree with Charlie that spam is a huge problem. OTOH, Postel's law would dictate the need to accept the specific Date-lacking messages. spamassassin and qpsmtpd's greylisting functionality are killers here. In my case, I followed the wiki link to disable the specific qpsmptd plugin, so I do not have any issues.

Still the question holds: should perhaps this plugin be disabled by default on new SME installations?

[Jáder]

I don't think so... SME is target to small companies. And those will be best supported by a more secure server.
Anyone with problems with bad mail headers (lack of DATE field) has an option to turn it off if they read docs.
All others remains safer by default.

[CharlieBrady]

OTOH, Postel's law would dictate the need to accept the specific Date-lacking messages.

That 'law' also predates the spam problem. Spam filtering is all about rejecting messages which have something 'fishy' about them; we can't just accept anything. as Postel recommends.

As to your problem with your developers, the fact that qpsmtpd perhaps does not follow an RFC recommendation in no way justifies them ignoring a mandatory requirement. Hit them with your clue-stick.

There's a method for creating an IP whitelist for that plugin outlined at:

http://bugs.contribs.org/show_bug.cgi?id=6116#c2

[Michail Pappas]

As to your problem with your developers, the fact that qpsmtpd perhaps does not follow an RFC recommendation in no way justifies them ignoring a mandatory requirement. Hit them with your clue-stick.

This is what I'm looking for, but have failed so far to find. Where exactly is the mandatory requirement cited at? Trust me, if I get it I'll bash them skulls aight.

There's a method for creating an IP whitelist for that plugin outlined at:

http://bugs.contribs.org/show_bug.cgi?id=6116#c2

I had read the ticket before posting here, unfortunately a reconfiguration breaks the mechanism and since I am the only (somewhat) competent in Linux here, this might present problems during my absences.

[CharlieBrady]

Where exactly is the mandatory requirement cited at?

RFC2822:

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

[Michail Pappas]

On spot, thank you!