Bug 8149 - EnvelopeFrom vs Return-Path
Summary: EnvelopeFrom vs Return-Path
Status: NEW
Alias: None
Product: Spamassassin
Classification: Unclassified
Component: Rules (show other bugs)
Version: 4.0.0
Hardware: PC Windows 10
: P2 normal
Target Milestone: Undefined
Assignee: SpamAssassin Developer Mailing List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2023-07-22 06:49 UTC by RvdH
Modified: 2023-10-07 08:16 UTC (History)
3 users (show)


Attachment Type Modified Status Actions Submitter/CLA Status
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description RvdH 2023-07-22 06:49:01 UTC 
Some MTA calling SpamAssassin might not add the Return-Path header until final delivery, meaning the Return-Path might be unavailable to SA while processing rules.

I noticed some of the default rules rely on the Return-Path header being present, eg:

\share\4.000000\updates_spamassassin_org\20_head_tests.cf
__ML5

\share\4.000000\updates_spamassassin_org\20_vbounce.cf
__BOUNCE_RPATH_NULL
__BOUNCE_RPATH_MD 
__BOUNCE_RPATH_ERRMAIL
__CRBOUNCE_RP
__CRBOUNCE_RP_2
__CRBOUNCE_GETRESP
__VBOUNCE_MSGLABS


\share\4.000000\updates_spamassassin_org\72_active.cf
DSN_NO_MIMEVERSION
__RAND_HEADER (this one can be ignored i think)
__USING_VERP1


KAM.cf also uses Return-Path in some instances.

Wouldn't it be better to use EnvelopeFrom or EnvelopeFrom:addr there?
Or add a fallback to use EnvelopeFrom:addr or Return-Path:addr, eg:

describe UNPHISH_FROM_DOMAIN Trigger on valid mails, lower score
header   __UNPHISH_FROM_DOMAIN_A  EnvelopeFrom:addr =~ /\@(domain\.nl)$/i
header   __UNPHISH_FROM_DOMAIN_B  Return-Path:addr =~ /\@(domain\.nl)$/i
ifplugin Mail::SpamAssassin::Plugin::DMARC
    meta     UNPHISH_FROM_DOMAIN      ( (__UNPHISH_FROM_DOMAIN_A + __UNPHISH_FROM_DOMAIN_B >= 1) && DMARC_PASS )
else
    meta     UNPHISH_FROM_DOMAIN      ( (__UNPHISH_FROM_DOMAIN_A + __UNPHISH_FROM_DOMAIN_B >= 1) && ( SPF_PASS || SPF_HELO_PASS && DKIM_VALID ))
endif
tflags   UNPHISH_FROM_DOMAIN net  
score    UNPHISH_FROM_DOMAIN -2.0
Comment 1 RvdH 2023-07-22 07:22:53 UTC 
FYI for this particular MTA the EnvelopeFrom:addr value depends on envelope-from value passed within the Received header, eg: (envelope-from <user@somedomain.com>)
Comment 2 Benny Pedersen 2023-07-22 07:26:51 UTC 
not a spamassassin bug, if spampd (smtp proxy for spamassassin) is used, there is no problem at all

https://github.com/mpaperno/spampd

dokument if it breaks with used glue in use, i use amavisd-new and amavisd-milter in postfix
Comment 3 RvdH 2023-07-22 07:37:17 UTC 
Sorry, that is not a satisfying response, what if i am running a Windows Server? Good luck running spampd on Windows!

I really think these rules should be checked against the EnvelopeFrom:addr because:

1) Return-Path header could be existing header passed on from a previous MTA
2) Return-Path maybe nonexistent until final delivery as outlined above 
3) EnvelopeFrom:addr holds either the envelope-from value passed within the Received header, Return-Path or configured envelope_sender_header in config
Comment 4 Henrik Krohns 2023-10-07 08:16:22 UTC 
There's already Bug 6199 discussing this since ancient times. But as things seem to work for most as is, no one is brave enough to try to change something.