Mail not delivered when sent via Sprint cellphone

[Greg Talbot]

I can see this in the SMTP\current log:

CHKUSER accepted rcpt: from <xxx@xxx.com::> remote <mail1.xxxx.com:unknown:xx.xx.xx.xxx> rcpt <greg@xxxx.com> : found existing recipient

But the message is not making it to my inbox.  The sender gets this notice:

Subject: Delivery Status Notification (Delay)
>>
>>This is an automatically generated Delivery Status Notification.
>>
>>THIS IS A WARNING MESSAGE ONLY.
>>
>>YOU DO NOT NEED TO RESEND YOUR MESSAGE.
>>
>>Delivery to the following recipients has been delayed.

And after a day gets a message that it could not be delivered.

Suggestions on how to proceed?

[matt]

Have a look at the bounce message that states the reason it wasn't delivered.

[Greg Talbot]

They havent sent me the latest one yet, but a previous one was:

#4.0.0 smtp;451 temporary RBL lookup error

[matt]

That means one of their mail servers is listed on one of the RBLs you are using.

[Greg Talbot]

Most of the bounced messages do not have an error message from our server. 

It has:
#4.4.7 from their exchange server

I have their IP whitelisted in tcp.smtp and we do get emails from their server throughout the day.  It is only when the client uses their Sprint cell that then routes through their email server that the messages do not get delivered.

[Greg Talbot]

This issue has been resolved.  It turned out to be a bare LF in the body of email.  Qmail was rejecting the message with an error message: "451 See http://pobox.com/~djb/docs/smtplf.html."

Since qmail was returning a temporary error, the sender's server was constantly trying to resend until its time limit was reached.  The error message in the bounce was usually a vague "server busy"  IMO Qmail should reject this with a permanent error as the email has no chance of being corrected and there is no logging of this rejection in the standard qmail install.

Matt helped track this down by installing a patch on our server to log the entire SMTP transaction.   This sender was a valuable customer of ours and their admin was unwilling to make any changes on their end, so we took this route:

http://hewgill.com/journal/entries/30-qmail-may-be-eating-your-email

<<<<<<
The qmail document refers to a document it calls "822bis", which apparently was an older name for RFC 2822. Section 2.3 of this document does indeed prohibit the use of bare LF characters within the message body. However, this document is not considered a standard; to find a standard relating to email transfer we must look at RFC 822, also known as STD 11. RFC 822 does not specifically prohibit the use of bare LF characters in message bodies.

RFC 821 also requires, in section 4.1.1, that "The receiver should not close the transmission channel until it receives and replies to a QUIT command (even if there was an error)." Based on this, I have concluded that the qmail behaviour is in error and should not be used as is.

The culprit in qmail is the function blast() in the qmail-smtpd.c file. This function scans the message body and if it detects a bare LF character, calls the straynewline() function. This function prints the above 451 message, and abruptly exits:

    void straynewline() { out("451 See http://pobox.com/~djb/docs/smtplf.html.\r\n"); flush(); _exit(1); }


There is no evidence that anything bad will happen if the bare LF characters are permitted in the message body. So, in order to fix this problem in qmail, I modified qmail-smtpd.c so that the straynewline() function takes no action:

    void straynewline() { }

<<<<<<

Thanks again, Matt!