Discussion:
RFC 5322 compliance errors
(too old to reply)
m***@gmail.com
2016-08-04 17:00:49 UTC
Permalink
Hello,

I have a particularly difficult e-mail problem with one of my users.
The problem started to occur when we refreshed our mail relay servers with a new OS and changed from (deprecated) sendmail to Postfix.
So this may have something to do with Postfix. I have had great trouble identifying the problem.

Postfix generally works fine. It is configured well and does what it is supposed to do, except for the combination of ONE sender to ONE destination.
The sender is an internal server that runs batch jobs and it sends e-mail through a java application to my relay.
The relay sends the messages to multiple users at multiple destinations.
ONE of the destinations, Google, rejects the incoming e-mail. Here is the "bounce message":

--------------------------------------------------------------------------------
This is the mail system at host xxx-mailrelay03.xxx.xxx.

I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.

For further assistance, please send mail to postmaster.

If you do so, please include this problem report. You can
delete your own text from the attached returned message.

The mail system

<***@xxx.xxx>: host aspmx.l.google.com[209.85.234.26] said: 550-5.7.1
[<ip address> 11] Our system has detected that this message is
550-5.7.1 not RFC 5322 compliant. To reduce the amount of spam sent to
Gmail, 550-5.7.1 this message has been blocked. Please review 550 5.7.1
RFC 5322 specifications for more information. r2si365183itc.3 - gsmtp (in
reply to end of DATA command)

<***@xxx.xxx>: host aspmx.l.google.com[209.85.234.26] said: 550-5.7.1
[<ip address> 11] Our system has detected that this message is
550-5.7.1 not RFC 5322 compliant. To reduce the amount of spam sent to
Gmail, 550-5.7.1 this message has been blocked. Please review 550 5.7.1
RFC 5322 specifications for more information. r2si365183itc.3 - gsmtp (in
reply to end of DATA command)

<***@xxx.xxx>: host aspmx.l.google.com[209.85.234.26] said: 550-5.7.1
[<ip address> 11] Our system has detected that this message is
550-5.7.1 not RFC 5322 compliant. To reduce the amount of spam sent to
Gmail, 550-5.7.1 this message has been blocked. Please review 550 5.7.1
RFC 5322 specifications for more information. r2si365183itc.3 - gsmtp (in
reply to end of DATA command)

<***@xxx.xxx>: host aspmx.l.google.com[209.85.234.26] said: 550-5.7.1
[<ip address> 11] Our system has detected that this message is
550-5.7.1 not RFC 5322 compliant. To reduce the amount of spam sent to
Gmail, 550-5.7.1 this message has been blocked. Please review 550 5.7.1
RFC 5322 specifications for more information. r2si365183itc.3 - gsmtp (in
reply to end of DATA command)

Part 2:
Content-Description: Delivery report
Content-Type: message/delivery-status


Part 3:
Content-Description: Undelivered Message
Content-Type: message/rfc822

From ***@domain Wed Jul 20 19:00:36 2016
Return-Path: <***@domain>
Date: Wed, 20 Jul 2016 19:00:37 -0600 (MDT)
To: ***@xxx.xxx, ***@xxx.xxx, ***@xxx.xxx,
***@vtext.com, ***@xxx.xxx
Subject: FINISHED 431734.00 WS_OVERDUE_PEND_ASSIGNMNT_RESP Finished [ASJN]
Content-Type: multipart/mixed;
boundary="----=_Part_17734_25564005.1469062837189"


Part 3.1:
Content-Type: text/plain; charset=us-ascii

The job WS_OVERDUE_PEND_ASSIGNMNT_RESP with run_id 431734.00 finished on 20-Jul-16

(lot of other content omitted)
-------------------------------------------------------------------------------------

This suggests that the e-mail header is inadequate.
However, that makes little sense because the very same e-mail gets delivered to destinations other than Google. (See the vtext.com address, it works fine.)

Thus, it could be (albeit unlikely) that the problem is on Google's side.
Since we are paying customers to Google's services, we opened a case with them and have pursued it for the last couple of weeks, completely without success.

Google engineers comment that they "see nothing wrong with our e-mails". Yet, they are rejected.

There is a little more info that is pertinent. I do address rewriting.
Our internal server delivers e-mail to my relay with a sender address of something.somethingelse.some.local.

I use canonical address rewriting where I say:
something.somethingelse.some.local ***@domain

This works also. Note that this changes the "From" address.

I have two fundamental questions:

(1) I do not want to see the failed message AFTER it bounces, I want to see a copy, EXACTLY of what is going on while it is going on, but ONLY for ONE internal sender. We process several GB worth of e-mail a day and I cannot afford to go to some verbose mode that will capture everything. I would not mind just "catching" the incoming message and inspect it byte-by-byte.

Is it possible to do this in Postfix? Again, just for one selected sender address? If not for one address, I could try to do this from 8PM till 4AM or something like that, so I won't catch all the daily "business traffic".

(2) Please note in error example above: in the original (rewritten) From address, it is "From", not "From:" and if this is indeed accurate,
it is a violation of RFC5322?

Questions: who writes this "From" - the original server, or Postfix on the relay? If it is Postfix, then is it written as part of the canonical rewrite?
That is, does the canonical rewrite do just the address or the entire line?

Is this possibly a bug? I lean towards the opinion that it is not a bug because if I do not do a rewrite, the message also does not go through,
but that could happen because there is no valid sender and/or return address.

I can share further details if needed. I felt that the nature of my work suggests (not dictates) that I extensively edit out all identifiers.

Thank you for reading this long topic and for thinking with me.

Mark
Bob Nichols
2016-08-10 19:41:29 UTC
Permalink
Post by m***@gmail.com
The sender is an internal server that runs batch jobs and it sends
e-mail through a java application to my relay. The relay sends the
messages to multiple users at multiple destinations. ONE of the
destinations, Google, rejects the incoming e-mail.
...
This appears to be an mbox (RFC4155) "From"-prefix. As you noted, it is
not a valid RFC5322 header. The fact that most servers accept the
message probably just means that they aren't validating it. The
unwanted header is presumably in the data sent by the Java app, though
why the same message was accepted when sent via sendmail, I cannot imagine.

To catch a copy of mails from a particular sender, you can use the
sender_bcc_maps option in main.cf. For example:

Create a map file:

/etc/postfix/sender_bcc:
***@domain ***@mydomain

then run:

postmap /etc/postfix/sender_bcc

and update main.cf to refer to the new map:

/etc/postfix/main.cf:
...
sender_bcc_maps = hash:/etc/postfix/sender_bcc
...

Whenever Postfix receives a mail from ***@domain, it will then send a
copy to ***@mydomain, which you can check.
--
remove .invalid for e-mail
Loading...