Re: does dbmail mangle the position of return-path header?

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: <[email protected]>
>>
>> Return-Path: [email protected]
>> 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