Bug Tracker item #3572691, was opened at 2012-09-28 01:29 Message generated for change (Comment added) made by robotux You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1126467&aid=3572691&group_id=250683
Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: daemon Group: GIT Status: Open Resolution: None Priority: 5 Private: No Submitted By: Thomas Preud'homme (robotux) Assigned to: Nobody/Anonymous (nobody) Summary: long line in message body causes error 530 Initial Comment: 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 ---------------------------------------------------------------------- Comment By: Thomas Preud'homme (robotux) Date: 2012-10-12 08:35 Message: 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 ---------------------------------------------------------------------- Comment By: Thomas Preud'homme (robotux) Date: 2012-10-12 08:10 Message: 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 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1126467&aid=3572691&group_id=250683 ------------------------------------------------------------------------------ Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev _______________________________________________ Dspam-devel mailing list Dspam-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspam-devel
