Qmail causing issues with /r/n

SiteWorx General Discussion
1

Well we’ve narrowed down the issue on our missing emails. After running wireshark we have found that some clients do not follow qmail’s requirement to use a /r/n instead of /n for subject and or body text.

Qmail advocates say that it’s a standard and all should follow (but only qmail does) http://cr.yp.to/docs/smtplf.html

Others advocates say:
“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.”

But ultimately I’m stuck because qmail is not sending an OK because it doesn’t like the message and the message just hangs there, never processing through the queue.

The problem is our previous system based on EXIM gladly accepted mail from these clients so I’m being forced to rip out IW and go with another solution… unless someone has a fix… and fast!

Thanks to IW support for leading me through this journey. My IW license reseller wouldn’t even open a ticket for me. Goes to show, buy from IW directly if you want quality support.

2

Hi Mikie

I’ve read this post a few times, and I realised it refers to only accepting emails from other sender mail servers to qmail, not the sending of email from your server.

I think your point is one interpretation, there are others, which is life in the IT world, and I think your extremely lucky if IW support helped you so much, but they do rock, so I am not surprised.

I would think your post also includes how to patch it, if you wanted to, as the following extract:

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.
"); 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() { }

This modification finally let the order confirmation I was expecting arrive successfully.

I recommend that everybody who runs qmail apply this modification. You may be missing mail and not know it.

However, for users who have not seen the links, heres some of the replies (extracted in full from http://hewgill.com/journal/entries/30-qmail-may-be-eating-your-email).

[info]dbaker
2003-12-01T05:35:18Z

This was a big issue in 1997 or so when several major MUAs (Eudora?) would generate message with bare LF characters.

[info]ghewgill
2003-12-01T05:38:13Z

Sure, but as long as the MTA ends the SMTP body with CR LF . CR LF as required, it shouldn’t matter what the MUA creates.

[info]dbaker
2003-12-01T05:41:02Z

Messages are transmitted from a MUA to a MTA via SMTP.

[info]ghewgill
2003-12-01T05:42:02Z

Oh uh yeah, good point. :slight_smile:

[info]davesill : qmail is doing the right thing
2004-02-19T14:31:17Z

Don’t blame qmail for doing the right thing. Blame the broken client.

Many thanks

John

3

Oh, there’s no doubt in my mind that this is a contentious topic. However I’m sticking by the guy who points out that qmail is using a ‘non-standard’ standard for their logic. My Kerio and Exim servers are humming right along with no problems (40,000 emails yesterday). It’s my belief that if 99% (perhaps an exaggeration) of the other mail servers are interpreting it the ‘other’ way qmail should at least allow it to be a configuration parameter.

As far as IW supporting it, well - they don’t support systems that have been modified, so I either dump IW or ask them to consider changing it next time they compile - which as of yesterday is a strong “we’re considering it”

4

Realized I never updated this post. The terrific group at IW installed a qmail patch in my system and we’re working swimmingly for several months. These guys are fantastic and well worth the ‘full’ license fee to get support from them.