Royce Williams wrote:
On Fri, Apr 9, 2010 at 3:46 AM, RW <rwmailli...@googlemail.com> wrote:
msa_networks defines the MSA by IP address. If SA runs on an MSA its
address is unlikely to be in the received headers. In that case SA has
no way of distinguishing an MSA from an MX server.
Yes! That's what Daryl was referring to here
http://old.nabble.com/ALL_TRUSTED-and-DOS_OE_TO_MX-td15659736.html
... where he says:
"So if (and I'll admit I don't think this occurred to me before) you're
running SA on outgoing mail on your MSA right after you receive it (it's
not relayed to an intermediate machine) SA can't detect the MSA and the
whole msa_networks thing doesn't work."
*nod* I'm seeing the logic there... now I'm trying to figure out what
kind of magic chicken I must have sacrificed to get things to work here.
<g>
I would think that in this case the dynamic address blocks would need to
be explicitly defined.
That's why I starting this thread by saying that I went hunting for a
"mua_networks" equivalent, and couldn't find one.
OK, think about this: What do you do about relay IPs outside your
network, from which your customers are sending mail through your MSA via
SMTP AUTH? There's a good chance they're listed on eg Spamhaus PBL -
and there's *no* way you'll ever predict them.
Henrik and RW have both suggested that I should put my customer-only
MSAs into msa_networks and internal_networks (which implies
trusted_networks). I can state definitively that in this setup, all
of the you-look-like-a-MUA rules (RDNS, Outlook, etc.) are happily
applied to my dialup customers, which is consistent with RW's
statement above.
Ahhh, here's a code comment:
Mail/SpamAssassin/Conf/Parser.pm: line ~1040
# validate trusted_networks and internal_networks, bug 4760.
# check that all internal_networks are listed in trusted_networks
# too. do the same for msa_networks, but check msa_networks against
# internal_networks if trusted_networks aren't defined
So msa_networks *may* be a subset of internal, but it's not required,
and not quietly forced either *unless* trusted_ isn't defined.
All I can say is "WorksForMe(TM)". :/ I have three different systems
with several different SA versions, and several integration methods...
and none of them trigger on direct-to-MX-ish rules inappropriately.
One is our primary mail cluster; the SA filter subcluster is used for
both inbound scanning and outbound. On the outbound side, a Postfix
subcluster calls SA via custom Postfix content filter (which does not
generate a Received: header). Currently it's running SA3.3.1, but the
trust config was set with 3.2.5 - the last update just added a machine
to msa_networks when I discovered the occasional customer mail tripping
the outbound filter with ... yep, direct-to-MX-ish rules. (The Speed
Dial SMTP proxy running on that machine added a Received: header while
streaming the message to the "real" MSA cluster, and the message ended
up looking like direct-to-MX because there was a trusted non-MSA host in
between the MUA and SA.)
SA scan result:
spamd: result: . 0 - AWL,BAYES_20,NO_RECEIVED,NO_RELAYS
The other two are legacy all-in-one domain-hosting servers. One runs SA
via amavisd-new as a Postfix content filter (post-queue; no SMTP-time
rejections). The other calls SA from MIMEDefang. .... hmm, now that I
poke and think, both systems likely pass either a real live Received:
header (Postifx+Amavis) or a synthetic one (MIMEDefang) to SA.
SA scan results:
Amavis:
X-Spam-Status: No, score=-101.378 tagged_above=-9999 required=6.31
tests=[ALL_TRUSTED=-1.8, AWL=-1.298, BAYES_50=0.001,
TVD_SPACE_RATIO=1.719, USER_IN_WHITELIST=-100]
MIMEDefang:
X-Spam-Score: -99.21 () req=5 BAYES_50,T_RP_MATCHES_RCVD,USER_IN_WHITELIST
(Both delivered to test accounts I set up local to each system.)
Here's an obfuscated version of the live config (used on all three systems):
clear_trusted_networks
# core servers
trusted_networks 192.168.0.0/24
# legacy the first
trusted_networks 192.168.1.0/26
trusted_networks 192.168.3.0/26
# legacy the second
trusted_networks 192.168.4.232/29
# and third
trusted_networks 192.168.5.0/26
# inherited Plesk
trusted_networks 192.168.6.160/27
# colo(ish) customer server
trusted_networks 192.168.7.122/32
# postini. *sigh*
trusted_networks 64.18.0.0/20
# messagelabs (amsterdam)
trusted_networks 195.245.231.0/24
# customer's third-party webhost I'm willing to trust
# server.superhost2.nl
trusted_networks 91.192.36.238/32
# willing to believe UBC has someone halfway
# competent running their mail systems...
trusted_networks 137.82.45.0/28
# observed: .1, .5, .7, .15
# rDNS shows .1 -> .17 or so as MTA-ish
## internal
clear_internal_networks
internal_networks 192.168.0.21
internal_networks 192.168.0.22
internal_networks 192.168.0.23
internal_networks 192.168.0.24
internal_networks 192.168.0.119
# put Postini here so eg Spamhaus rules hit properly - otherwise
# they'll run on the Postini relay IP.
internal_networks 64.18.0.0/20
# gotta get RBL hits on these guys' headers...
internal_networks 91.192.36.238/32
# this should ONLY be machines that act as
# outbound relays; never inbound.
clear_msa_networks
msa_networks 192.168.0.17
msa_networks 192.168.0.18
msa_networks 192.168.0.19
# this machine handles "speed dial" mail; it adds
# a Received: header but not one of much use.
msa_networks 192.168.0.9
-kgd
