long line in message body causes error 530
Brought to you by:
paulcockings,
sbajic
Menu
▾
▴
#154 long line in message body causes error 530
As reported in Debian [BR], long line in message body causes error "530 5.2.0 Message is empty. Aborting.". This in turn can causes MTA (exim is cited in the bug report) to fail with 'Broken pipe' message for dspam router and use retries to send other emails to other recepients, so messages are deferred and delivered with delay.
[BR] http://bugs.debian.org/688853
The error stems from the fact that pop_buffer returns NULL when no newline is found (which is systematic for a line longer than 1023 bytes, the size of the buffer used in client_getline()). When this happens, the NULL is propagated from pop_buffer to client_getline, then to read_sock and finally process_connection returns the aformentioned error. Attach a patch to truncate line at 1023 bytes in pop_buffer by adding a newline just before the \0 when none is found. Note that I didn't try the patch so review are more than welcome.
Best regards,
Thomas Preud'homme
Sorry for the wrong analysis above. Dspam does read chunk of 1023 bytes until it reach a newline or the timeout is expired. The timeout is reasonable, probably even too nice since RFC 5321 mandates that "The maximum total length of a text line including the <CRLF> is 1000 octets (not counting the leading dot duplicated for transparency)". However, I believe first the message should be more meaningful and second that maybe dspam should not be more picky than the MTA. After all, dspam's role is to tag message according to their spam likeliness, am I wrong? Hence dspam should not refuse an email which a MTA accepted. As to the error message I suggest that in the case of timeout expiration, the following message is used: "5.3.4 Message too big for system".
Best regards,
Thomas Preud'homme
According to [rfc5321] it should be "500 Line too long". It's indeed more meaningful since the size of the message is not at fault but the line is.
[rfc5321] http://tools.ietf.org/html/rfc5321#section-4.5.3.1.9
Regards,
Thomas Preud'homme