Bug 6357 - AWL allows inheritance of good score for spammers if private/local adresses are used.
Summary: AWL allows inheritance of good score for spammers if private/local adresses a...
Status: NEW
Alias: None
Product: Spamassassin
Classification: Unclassified
Component: Plugins (show other bugs)
Version: 3.2.5
Hardware: All All
: P5 normal
Target Milestone: Undefined
Assignee: SpamAssassin Developer Mailing List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-03-01 18:17 UTC by Andreas Mager
Modified: 2016-04-05 10:50 UTC (History)
2 users (show)



Attachment Type Modified Status Actions Submitter/CLA Status
The patch application/octet-stream None Andreas Mager [NoCLA]
Patch to remove AWL fallback to none patch None Rodolfo Saccani [NoCLA]

Note You need to log in before you can comment on or make changes to this bug.
Description Andreas Mager 2010-03-01 18:17:46 UTC
Created attachment 4681 [details]
The patch

given this setup:

mailserver receives company email via private IPs (e.g. 10.0.0.0/8)
and also gets mails from outside.

this error happens:
mails from local users have only private IPs in them.
they all get removed by "check_from_in_auto_whitelist".
so a pretty solid negative score develops under the address: user@company.com|ip=none

if a spam mail arrives, it inherits this good score for a spammy IP address.
this leaves an open door for more spam until the mean value has risen high enough.
see Mail/SpamAssassin/AutoWhitelist.pm "sub check_address" for details.

remedy: configure the internal ips as trusted networks
and disable the removal of internal ips.

additionally I have some concerns about reversing the ip list.
as of the current state the first public ip the mail passed through is used.
this could be a problem because this information is passed through untrusted servers and could be easily forged to sneak by the filter using good IPs and discredit them in the process.

so I changed this to use the IP that is right next to the trusted networks.

I kept the reversing of the trusted IPs so company mails get filed under their most specific IP.

please see the small patch I've attached for details
Comment 1 Ivo Truxa 2014-03-08 11:24:20 UTC
If I am reading the report correctly, I'd tell that the real problem is not with AWL, or with SA, but with the mail server configuration. Forged addresses on own domain should never reach SpamAssassin, they should be rejected in a an early stage when processing the mail, to save resources. It can be easily done either using DKIM or SPF, or simpler even without them by rejecting all email using local domains and not originating on authorized networks. DKIM signature would fix it with AWL even without rejecting the email prior SA.

To address the issue anyway, I made a modification in the TxRep plugin (a proposed replacement for AWL). Now, messages originating on internal networks, will be assigned the address 127.0.0.1 (regardless what the real internal IP address was). The fix is in the revision 1.0.6 of TxRep. See https://issues.apache.org/SpamAssassin/show_bug.cgi?id=7021 for more details.

As for the reversing the IP list, that is addressed in the bug 6908 (https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6908), and fixed in TxRep too, although the simple reversal is not the right solution.
Comment 2 Rodolfo Saccani 2016-04-05 10:43:35 UTC
Created attachment 5383 [details]
Patch to remove AWL fallback to none

This patch removes the fallback to from-none when from-ip doesn't have a history record.

ip=none for emails originated from private subnets
Comment 3 Rodolfo Saccani 2016-04-05 10:50:41 UTC
About comment #1:

In an ISP configuration there are many legit reasons for anti-spoofing measures to be kept disabled and there is often no control over the SPF-DKIM configuration of all the client domains.

So, incoming emails with forged "from" cannot always be stopped at an early stage.

In any case there is no good reason to allow an email from an external ip class to inherit reputation from emails originated by private ip classes. Reputation should be kept separate in any case.

My proposed patch removes the fallback.