Bug 7590 - Handling of authentication on submission
Summary: Handling of authentication on submission
Status: NEW
Alias: None
Product: Spamassassin
Classification: Unclassified
Component: Libraries (show other bugs)
Version: 3.4.1
Hardware: All All
: P2 normal
Target Milestone: Undefined
Assignee: SpamAssassin Developer Mailing List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-06-17 18:03 UTC by RW
Modified: 2018-06-17 18:03 UTC (History)
0 users


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 RW 2018-06-17 18:03:29 UTC 
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 <foo@bar.com>; 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).