spamassassin-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jones <>
Subject Re: Doc Bug: Trusted_networks versus internal
Date Fri, 16 Mar 2018 13:03:02 GMT
On 03/15/2018 08:08 PM, Dan Mahoney (Gushi) wrote:
> Hey there,
> I'm seeing conflicting information about what 
> trusted_networks/internal_networks means.
> One of $dayjob's emails tripped off our internal spamassassin, which was 
> scanning outbound mail as well.  Apparently we used a URL in our mail 
> (talking about a security issue) and caused URIBL to go crazy, causing 
> the message to be still flagged as spam:
> spamd: result: Y 9 - 

> We're fixing this to not scan our outbound mail, since we work in 
> security and need to occasionally send a mail that looks spammy.

This doesn't make a lot of sense for a security company to knowingly 
send out emails that are going to hit a lot of URIBLs.  Many of the 
recipient's SA instances are going to block these emails.  Surely there 
is a better way to send out these emails so they don't hit all of those 

Also, it's not wise to not scan your outbound mail for a number of 
reasons if there are any human mailboxes being filtered outbound. 
Compromised passwords happen and you need to be able to 
catch/detect/block the outbound spam before it causes your mail servers 
to become listed on RBLs.

> Here's my problem with the somewhat unclear docs:
> One Apache page 
> (

> Says:
> "Trusted" does not mean "trusted to not send spam." It means "trusted to 
> not forge Received: headers."
> And another page (
> Says:
> "Note that it doesn't matter if the server relays spam to you from other 
> hosts; that still means you trust the server not to originate spam, 
> which is what 'trusted_networks' specifies."
> Could someone who really understands the internals fix one of these? 
> These two pages are directly offering conflicting information.

 From my experience and what has been posted on this list, basically 
it's recommended to set internal_networks and trusted_networks to be the 
same or very close.  The internal_networks will tell SA how far back to 
skip in the Received: headers to find the "last external" where RBLs 
checks will be done against that IP.  Trusted_networks are networks that 
you control or know they won't forge any headers so the ALL_TRUSTED rule 
will hit.  Then you can make meta rules or even shortcircuit (dangerous 
to not scan outbound) the ALL_TRUSTED rule.

I have the Shortcircuit plugin enabled but have disabled 
shortcircuit'ing for the ALL_TRUSTED rule and only subtract a point.  I 
have meta rules to combine the ALL_TRUSTED hits with other bad rules to 
amplify the score to help detect compromised accounts from my customer 
mail servers that smarthost back out through the same as the inbound MX 
record of my SA platform.

David Jones

View raw message