[Rspamd-Users] Weird behaviour on Return-Path header processing

[Vsevolod Stakhov]

On 11/09/2024 14:34, G.W. Haywood wrote:
> Hi there,
> 
> On Wed, 11 Sep 2024, jose.celestino at gmail.com wrote:
> 
>> Noticed what seems a weird behaviour with rspamd processing of the
>> return-path header: the setting of the from_envelope seems to depend
>> on where the return-path is located on the headers:
>>
>> - if the return-path is seen earlier (that is, added later and on top
>> of the headers), it is properly processed and from_envelope set
>> accordingly
>>
>> - if the return-path is later in the headers (after the from?) then
>> from_envelope is not set from its value ...
> 
> 'Return-Path:' is what's called a 'trace header':
> 
> https://datatracker.ietf.org/doc/html/rfc2822#section-3.6.7
> 
>> So, is this a side-effect or on purpose?
> 
> My (er, educated) guess is that it's on purpose.  If a header can be
> confidently assumed to have been applied by the local MTA then it can
> probably be trusted.  For the 'Return-Path:' header, this effectively
> means that it's expected to be the *first* header in the message.
> 
> Unfortunately forged headers are very common.
> 
> If it's way down in the weeds it may be forged and should be ignored.
> It's permitted for your mail system to delete it but you may need to
> be able to cope with any side effects that might possibly have.
> 

In fact, it's just a coincidence that has nothing to R-P header. If this 
header is added by a local MTA, then SMTP from is known and is the same, 
it also means that R-P header will be on top of the headers. Otherwise, 
it is not.

Rspamd has no special handling of the Return-Path header and it is 
intentional for the reasons you've explained above.