Mailing List Archive

Harald,

Sounds valid - some RFC that defines this behavior would be nice though.

Fixing this like you propose is trivial.

Currently dbmail uses g_mime_object_set_header(), but instead this could
be changed to g_mime_object_prepend_header()

We might even get aways with *always* prepend any header we add, but
adding a separate call to do that explicitely seems like the safer choice.



On 03-12-16 16:32, Reindl Harald wrote:
> on our server running postfix "Return-Path" is always at bottom and
> missing the <> but looking on servers running postfix+dovecot as well as
> gmail it's always on top and looks like Return-Path: <a1@aon.at>
>
> Return-Path: users-return-114109-lists=rhsoft.net@spamassassin.apache.org
> Content-Type: text/plain
>
> that's ciritical in case of content-filters because the position of
> received and other headers is the classification if it's trusted or not
> and in case dbmail is the reason that would explain why it's so
> difficult to pipe a message from the inbox to spamassassin and get the
> same results as at recieve time
>
> again:
> it is a MUST that every relay places it's headers ON TOP and if it also
> adds a received-header any other headers are placed above
> _______________________________________________
> DBmail mailing list
> DBmail@dbmail.org
> http://lists.nfg.nl/mailman/listinfo/dbmail
>


--
________________________________________________________________
Paul J Stevens pjstevns @ gmail, twitter, github, linkedin
_______________________________________________
DBmail mailing list
DBmail@dbmail.org
http://lists.nfg.nl/mailman/listinfo/dbmail

Am 03.12.2016 um 17:21 schrieb Paul J Stevens:
> Sounds valid - some RFC that defines this behavior would be nice though

in case of dovecot it looks like "Return-Path:
<bounce-md_30850198.57ea4c6d.v1-faa83b451eba4e4287c81131249b3ead@mandrillapp.com>"
which is always the *first* header and contains also <> which makes it
easier useable for anchored-regex in contentfilters

point is that a contentfilter has only one way to decide if a header is
trustable or mabye faked which makes it unuseable for decisions (at
least for decisions for ham-scrores) and that's the trust-path
internal_networks/trusted_networks

when you place any header on bottom this one is no longer trustable and
the following RFC even when it is talking only about received headers
should aplly to any header

https://www.ietf.org/rfc/rfc2821.txt

An Internet mail program MUST NOT change a Received: line that was
previously added to the message header. SMTP servers MUST prepend
Received lines to messages; they MUST NOT change the order of
existing lines or insert Received lines in any other location

> Fixing this like you propose is trivial.
>
> Currently dbmail uses g_mime_object_set_header(), but instead this could
> be changed to g_mime_object_prepend_header()
>
> We might even get aways with *always* prepend any header we add, but
> adding a separate call to do that explicitely seems like the safer choice.
>
> On 03-12-16 16:32, Reindl Harald wrote:
>> on our server running postfix "Return-Path" is always at bottom and
>> missing the <> but looking on servers running postfix+dovecot as well as
>> gmail it's always on top and looks like Return-Path: <a1@aon.at>
>>
>> Return-Path: users-return-114109-lists=rhsoft.net@spamassassin.apache.org
>> Content-Type: text/plain
>>
>> that's ciritical in case of content-filters because the position of
>> received and other headers is the classification if it's trusted or not
>> and in case dbmail is the reason that would explain why it's so
>> difficult to pipe a message from the inbox to spamassassin and get the
>> same results as at recieve time
>>
>> again:
>> it is a MUST that every relay places it's headers ON TOP and if it also
>> adds a received-header any other headers are placed above
_______________________________________________
DBmail mailing list
DBmail@dbmail.org
http://lists.nfg.nl/mailman/listinfo/dbmail

Thanks for the reference. You might try attached patch where I fix the
generic set_header.


--
________________________________________________________________
Paul J Stevens pjstevns @ gmail, twitter, github, linkedin

Am 03.12.2016 um 17:37 schrieb Paul J Stevens:
> Thanks for the reference. You might try attached patch where I fix the
> generic set_header

does this patch apply to 3.1.17? since it's so silent here e hestitate
to play around with dbmail-3.2 and currently no time anyways since
working day and night on refactoring 250000 lines of code in a 13 years
old base......

dbmail-3.1.17-3.fc24.20161014.rh.2874f497fb429ed139e94342ca1c84325b20b3f1.x86_64


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
___________________________________________________________

X-Spam-Report: Flag: No, * -0.1 CUST_DNSWL_3_JEF_L RBL:
hostkarma.junkemailfilter.com (Low Trust) * [216.34.181.88 listed in
hostkarma.junkemailfilter.com] * -3.5 CUST_DNSWL_13_TL_H RBL:
dnswl-aggregate.thelounge.net (High Trust) * [216.34.181.88 listed in
dnswl-aggregate.thelounge.net] * -0.5 CUST_DNSWL_11_ORG_H RBL:
list.dnswl.org (High Trust) * [216.34.181.88 listed in
list.dnswl.org]
* -100 USER_IN_SPF_WHITELIST From: address is in the user's SPF
whitelist *
0.0 SHORTCIRCUIT Not all rules were run, due to a shortcircuited rule *
0.0 CUST_SHORTCIRCUIT1 Skip tests based on whitelists/blacklists and *

local relays
___________________________________________________________
_______________________________________________
DBmail mailing list
DBmail@dbmail.org
http://lists.nfg.nl/mailman/listinfo/dbmail

On 03-12-16 17:43, Reindl Harald wrote:
>
>
> Am 03.12.2016 um 17:37 schrieb Paul J Stevens:
>> Thanks for the reference. You might try attached patch where I fix the
>> generic set_header
>
> does this patch apply to 3.1.17? since it's so silent here e hestitate
> to play around with dbmail-3.2 and currently no time anyways since
> working day and night on refactoring 250000 lines of code in a 13 years
> old base......
>
> dbmail-3.1.17-3.fc24.20161014.rh.2874f497fb429ed139e94342ca1c84325b20b3f1.x86_64

I'm attaching the same patch for 3.1

> 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.



--
________________________________________________________________
Paul J Stevens pjstevns @ gmail, twitter, github, linkedin

Am 04.12.2016 um 10:54 schrieb Paul J Stevens:
> On 03-12-16 17:43, Reindl Harald wrote:
>>
>>
>> Am 03.12.2016 um 17:37 schrieb Paul J Stevens:
>>> Thanks for the reference. You might try attached patch where I fix the
>>> generic set_header
>>
>> does this patch apply to 3.1.17? since it's so silent here e hestitate
>> to play around with dbmail-3.2 and currently no time anyways since
>> working day and night on refactoring 250000 lines of code in a 13 years
>> old base......
>>
>> dbmail-3.1.17-3.fc24.20161014.rh.2874f497fb429ed139e94342ca1c84325b20b3f1.x86_64
>
> I'm attaching the same patch for 3.1

thanks - that looks way better!

Return-Path: test@testserver.rhsoft.net
X-AT-Envelope-From: <test@testserver.rhsoft.net>
X-AT-Envelope-To: <test@testserver.rhsoft.net>
Received: from rh.thelounge.net (rh.thelounge.net [10.0.0.99]) (using
TLSv1.2
with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate
requested) (Authenticated sender: test@testserver.rhsoft.net)
by testserver.rhsoft.net (MTA) with ESMTPSA id 3tYZpH1jXzz28FV
for <test@testserver.rhsoft.net>; Wed, 7 Dec 2016 11:43:03 +0100 (CET)
To: test@testserver.rhsoft.net

>> 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
_______________________________________________
DBmail mailing list
DBmail@dbmail.org
http://lists.nfg.nl/mailman/listinfo/dbmail

Am 04.12.2016 um 10:54 schrieb Paul J Stevens:
> On 03-12-16 17:43, Reindl Harald wrote:
>> 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

https://bugzilla.gnome.org/show_bug.cgi?id=776825
_______________________________________________
DBmail mailing list
DBmail@dbmail.org
http://lists.nfg.nl/mailman/listinfo/dbmail

On 03/01/2017 17:33, Reindl Harald wrote:
>
>
> Am 04.12.2016 um 10:54 schrieb Paul J Stevens:
>> On 03-12-16 17:43, Reindl Harald wrote:
>>> 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

Easily fixed, change GMIME_FOLD_LEN in gmime-table-private.h to
something sensible. rfc 2822 says should 76, must 998, see
https://www.ietf.org/rfc/rfc2822.txt 2.1.1. Line Length Limits. I've
recently been running with GMIME_FOLD_LEN 998 and all appears well.

IMO GMIME_FOLD_LEN should either be 998 or configurable.

The bug appears to be breaking the line regardless of a space or tab.

--- 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

I've been hit by this bug too as I'm creating tools to implement dmarc,
see http://dmarc.org.uk, where signature comes in ok, but can't be
checked because barfed.

Regards,
Alan

>
> https://bugzilla.gnome.org/show_bug.cgi?id=776825
> _______________________________________________
> DBmail mailing list
> DBmail@dbmail.org
> http://lists.nfg.nl/mailman/listinfo/dbmail
>
_______________________________________________
DBmail mailing list
DBmail@dbmail.org
http://lists.nfg.nl/mailman/listinfo/dbmail