GNOME Bugzilla – Bug 776825
mangeled mail headers
Last modified: 2017-02-07 19:36:58 UTC
dbmail heavily relies on gmime i am really tired after years that spamassassin report headers are unredable here X-Spam-Report: Flag: No, * -0.2 CUST_DNSWL_8_TL_N RBL: dnswl-aggregate.thelounge.net (No Trust) * [69.195.222.219 listed in dnswl-aggregate.thelounge.net] * -100 USER_IN_WHITELIST From: address is in the user's white-list * -0.0 SHORTCIRCUIT Not all rules were run, due to a shortcircuited rule * -0.0 CUST_SHORTCIRCUIT1 Skip tests for whitelists and local relays X-Virus-Scanned: Yes -------- Weitergeleitete Nachricht -------- Betreff: Re: [Dbmail] does dbmail mangle the position of return-path header? Datum: Sun, 4 Dec 2016 10:54:01 +0100 Von: Paul J Stevens <paul@nfg.nl> Antwort an: DBMail mailinglist <dbmail@dbmail.org> An: DBMail mailinglist <dbmail@dbmail.org> > BTW: it would also be nice when dbmail could stop reformat existing > headers - spam reports are horrible to read - they are supposed to have > * starting in a new line with a space before I dunno. This is deep gmime stuff.
Thanks for taking the time to report this. This bug report isn't very useful because it doesn't describe the bug well. What "is unreadable here" exactly and which output or behavior would you expect instead? If you have time and can still reproduce the bug, please read https://bugzilla.gnome.org/page.cgi?id=bug-writing.html and add a more useful description to this bug. When providing a better description, please reset the status of this bug report from NEEDINFO to its previous status.
what is unreadale here? "X-Spam-Report" are supposed to be formatted and they are until they pass dbamil / gmime - compare the above header (one ugly line) with the header below X-Spam-Report: Flag: Yes, * 1.0 CUST_DNSBL_27_UCE2 RBL: dnsbl-uce-2.example.com * (dnsbl-2.uceprotect.net) * [5.230.102.152 listed in dnsbl-uce-2.example.com] * -0.1 SPF_PASS SPF: sender matches SPF record * 0.5 CUST_BODY_BEGINS_VL BODY: Begins Very Low * 0.3 HTML_FONT_LOW_CONTRAST BODY: HTML font color similar or identical to * background * 0.0 HTML_MESSAGE BODY: HTML included in message * 1.5 BAYES_50 BODY: Bayes spam probability is 40 to 60% * [score: 0.5031] * 1.5 PYZOR_CHECK Listed in Pyzor (http://pyzor.sf.net/) * 2.5 RDNS_NONE Delivered to internal network by a host with no rDNS * 0.0 T_REMOTE_IMAGE Message contains an external image X-Virus-Scanned: Yes
*that* is unreadable X-Spam-Report: Flag: No, * -0.1 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2) * [157.55.234.79 listed in wl.mailspike.net] * -0.2 CUST_DNSWL_5 RBL: dnswl-aggregate.thelounge.net (No Trust) * [157.55.234.79 listed in dnswl-aggregate.thelounge.net] * -0.0 CUST_DNSWL_2 RBL: list.dnswl.org (No Trust) * [157.55.234.79 listed in list.dnswl.org] * 0.1 CUST_DNSBL_26 RBL: dnsbl-backscatterer.thelounge.net * (ips.backscatterer.org) * [157.55.234.79 listed in dnsbl-backscatterer.thelounge.net] * -0.1 SPF_PASS SPF: sender matches SPF record * -3.5 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] X-Virus-Scanned: Yes
I understand what Reindl's issue is. It's an issue I've been meaning to fix for a long time, but unfortunately it requires API/ABI breakage. GMime is probably due for an API/ABI change, though.
imho it was a (bad) API change from 2.4 to 2.6 because a freind until recently ran the same dbmail source (until he switched to dovecot at all) with gmime 2.4 and hat proper formatted headers
Header formatting didn't change between 2.4 and 2.6. The problem you are having has existed since day 1.
Perhaps GMIME_FOLD_LEN should either be 998 or configurable as headers can be very long with signatures. rfc 2822 says should 76, must 998, see https://www.ietf.org/rfc/rfc2822.txt 2.1.1. Line Length Limits. --- gmime-2.6.20/gmime/gmime-table-private.h.orig 2017-01-04 18:01:10.047320423 +0000 +++ gmime-2.6.20/gmime/gmime-table-private.h 2017-01-04 18:01:29.043905537 +0000 @@ -68,4 +68,4 @@ #define CHARS_PSPECIAL "!*+-/=_" /* encoded phrase specials (rfc2047 5.3) */ #define CHARS_ATTRCHAR "*'% " /* attribute-char from rfc2184 */ -#define GMIME_FOLD_LEN 76 +#define GMIME_FOLD_LEN 998
That's not the issue.
So finally had some free time last night and got most of the work done to fix this, but it required API/ABI breakage. I hope to commit the patch tonight once I work out the last few remaining details.
This is technically a duplicate of bug #635445, so marking as such. *** This bug has been marked as a duplicate of bug 635445 ***
sounds good - how large are that changes? do they need consumers to be changed or is it enough to re-compile them against a current gmime-devel?
They are pretty substantial. I tried to keep the API changes to a minimal and a recompile *may* be all you need, but that all depends on what API's your app was using. You can get a picture of what changed by looking here: https://github.com/GNOME/gmime/commit/6fff6564e21a1aba79fe5d86b3e8035c48a653c1
The next release of GMime will be 3.0 and will contain a number of other API changes that I've been detailing on the PORTING document as well as on the gmime-devel-list@lists.gnome.org via emails as I make progress. In the end, 3.0 should be a big improvement for dbmail.