Emails sent to Gmail domain suddenly not RFC 2822 compliant, Possible to bypass with Google Apps?

Question

Four days ago emails sent to our Gmail accounts via our ISP's mail servies started being rejected due to not being RFC 2822 complainant.

The following message to was undeliverable. The reason for the problem:
5.3.0 - Other mail system problem 550-'5.7.1 [2001:44b8:8060:ff02:300:1:6:6 11] Our system has detected that\n5.7.1 this message is not RFC 2822 compliant. To reduce the amount of spam\n5.7.1 sent to Gmail, this message has been blocked. Please review\n5.7.1 RFC 2822 specifications for more information.
iw4si27447595pac.153 - gsmtp'

It’s frustrating because these emails have been working fine for over a year—I'm assuming Google has upped their filters in the last week.

The email address we are trying to send to belongs to our Google Apps for Business account. I'm wondering, is there a way to override the RFC 2822 compliance filter to allow the emails to come through?

So far, adding the ISPs domain name to the spam whitelist in Gmail settings (in the Apps control panel) hasn’t worked.

---

The telnet log for the rejected message in question is:

220-ipmail06.adl6.xxxxx.net ESMTP 220 ESMTP; eth2958.xxx.adsl.OurISP.net [150.xxx.xxx.xx1] in MTA
HELO WINDOWS-xxxxx (<- this is our server name) 
250 ipmail06.adl6.OurISP.net 
MAIL FROM: [email protected]
250 sender ok 
RCPT TO: [email protected]
250 recipient ok 
RCPT TO: [email protected]
250 recipient ok 
DATA 
354 go ahead 
Subject: Test email from the Avid ISIS Notification Application This message was generated by Avid ISIS Notification Application. . 
QUIT 
250 ok: Message 716893804 accepted

Answer 1

RFC2822 says Date: and From: headers are required (section 3.6). It looks like Google will let you get away with just adding a From: header though, e.g.:

[..]
DATA 
354 go ahead 
From: <[email protected]>   <-- add this
Subject: Test email from the Avid ISIS Notification Application This message was generated by Avid ISIS Notification Application.
.
QUIT 
250 ok: Message 716893804 accepted 

Answer 2

Watch for duplicate From: headers or Reply-to: headers that don't match each other. This same problem was experienced by a number of users of Outlook for Mac who had extra header information erroneously migrated from previous mail client accounts. See http://hintsforums.macworld.com/showthread.php?p=718579

Answer 3

I have a PHP script that sends notifications every day, with fields built from a database. At the end of each field, the programmer had used \r\n to end the lines (both carriage return and line feed characters). This doesn't make any sense, but it worked until now.

I took out the \r character and suddenly my mails are now RFC 2822 compliant.

Answer 4

This a bug whatever is doing the validation. RFC 822 theoretically allowed separate CR and LF characters, which are not line ends, but RFC 2822 removes this feature. RFC 2822 section 2.3 says "CR and LF MUST only occur together as CRLF; they MUST NOT appear independently in the body."

What the programmer did is RFC 2822 complaint and your version is not. As a developer I prefer single line feeds but using CRLF in email is an absolute requirement. Ideally a MUA will understand any reasonable line ends.