https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7590
Bug ID: 7590
Summary: Handling of authentication on submission
Product: Spamassassin
Version: 3.4.1
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P2
Component: Libraries
Assignee: [email protected]
Reporter: [email protected]
Target Milestone: Undefined
If I run the following though spamassassin (3.4.1)
Received: from client.someisp.net ([81.171.57.60])
by mail.example.net (Postfix) with ESMTPA id 3183910260
for <[email protected]>; Sun, 17 Jun 2018 11:11:23 -0400 (EDT)
The relay ends up in X-Spam-Relays-Trusted and X-Spam-Relays-Internal.
Without the ESMTPA it would be in Untrusted/External. Any additional headers
below this, that aren't in internal/trusted networks will end up in
External/Untrusted.
This is strange for two reasons. The first is that there are many rules that
check the first section of X-Spam-Relays-External for 'auth= ' to avoid running
last external tests on submission.
The second is that since the first section of X-Spam-Relays-Untrusted normally
contains the trust boundary it's trivial to add a forged header below and get
a hit on RCVD_IN_DNSWL_HI etc. If the submission server allows relaying with
arbitrary from headers, it's also possible to get a USER_IN_DEF_WHITELIST hit
based on the standard def_whitelist_from_rcvd entries (or guess the
whitelist_from_rcvd entries for the full USER_IN_WHITELIST).
--
You are receiving this mail because:
You are the assignee for the bug.
