On 6/30/2006 9:29 PM, Mark Martinec wrote:
Daryl,
You've told SA that your users aren't a part of your internal network
though. If you configure SA to treat your users as part of your
internal network then it won't do net tests on them.
For clarity, I should have said RBL and SPF tests here not net tests.
SA should also skip DK/DKIM/SIQ tests in this case, but it currently
doesn't. :(
I forgot what was the original reason that it became a must to treat
MSA as non-internal. Was it firing DUL on mail from roaming users
back in 3.0.5?
It's always been necessary, right back to 3.0.0. I'm not sure if it's
been documented explicitly that long though.
Your MSA is configured as trusted but not internal. As the
documentation says, that means you trust it to not forge a header,
but don't trust it not to relay spam.
I don't like/understand the wording 'trust it (not) to relay spam'.
Any mail can be spam, being from internal user, or from a roaming
user or from outside. If it is spam, it'd better be labeled as such,
regardless of where it is coming from. All classical rules and
Bayes/Razor/DCC/URIBL rules should be active on all mail.
Yeah, that wordings not great. I'm pretty sure I was just regurgitating
the docs too, not good. Classical rules and Bayes/Razor/DCC/URIBL rules
are active on all mail. I'd actually forgotten that all of the various
net tests were still run no matter what.
The only distinction is in activation of RBL and SPF rules,
which should not be firing on our own IP addresses and on
IP addresses of authorized roaming users.
That was the use of keeping your MSA out of internal_networks. It
forced SA to do those checks on your MSA rather than roaming users who
you couldn't add to your trusted/internal networks in advance. It works
fine for people who use their MSA host to send out all mail. Not so
good when you first pass mail off to another internal MTA.
There was no way to just not do the RBL and SPF checks since the same
configuration methods had to work for "outside" mail too.
I think having msa_networks is the best way to go to resolve this.
Let's see whether specifying an explicit list of MSAs would help?
Received header fields beyond MSA would be ignored
(compatible with current behaviour that DUL is not consulted
for roaming users, and would solve the SPF misuse/problem in my
original case, and could also avoid submitting our own MSAs
to RBL tests).
OK, I see now that you want to unconditionally trust the MSA *and* all
hosts after it. Which is reasonable if the MSA is just an MSA. For
whatever reason you don't want to rely on auth tokens, etc. Seems
reasonable to me.
Right. There may be no auth tokens, either because mailer does not want
to insert them, or if some other authorization mechanism is being used
(including the most straightforward one: mynetworks).
I'm not disputing this, instead I'm just stating how such a config can
be usually made to work, for those following along...
mynetworks are easy... you can just add them to your trusted_networks,
just like you did to your mail server config.
SMTP auth is harder since, as you've noted, some software doesn't like
to add the tokens. I find that annoying myself, regardless of SA
wanting to use it, solely because it doesn't make clear why a mail was
accepted by looking at the headers and if necessary your config. To
know why auth'd mail was accepted you've got to look through logs. No
thanks. Way more work than looking at the message headers and
remembering what your config is.
POP-before-SMTP can be trickier, but hey it's already hackish anyway.
VPNs and such are simply too, you just add them to your
trusted_networks, just like you would your mail server config.
I considered now how SA should treat Received header fields (if any)
beyond the one inserted by MSA. Any mail coming from MSA should be
treated the same in this respect, being from internal networks or
from roaming users. There will usually be no such addition Received
header fields. If there are, it could be because of:
- being maliciously inserted by our own user (or his zombiezed PC),
they should best be ignored;
- being inserted by some internal MTA on some internal Unix host, which
uses our MSA as its 'smart host'. There is no harm in ignoring them,
they would/should not hit any interesting RBL/DUL test
(even if they did, RBL/DUL test should not be done on them anyway);
- being kept by some internal host on re-sending or forwarding some mail;
such Received fields could carry some spam-relevant information, and
by ignoring them you lose some score points. But I claim it does not matter,
because such mail had to come-in somehow in the first place, and if
it was spam, it would have been caught on its way in.
So I conclude that any Received header fields beyond the one inserted
by MSA can be safely ignored, and are best to be ignored to avoids
some false triggers in DUL and RBL tests.
I'm not yet sure if relays preceding the MSA relay should be ignored or
just classified trusted/internal the same way the MSA relay was.
One possible advantage to parsing the relays instead of just ignoring
them is that you can detect unparseable relays which could indicate a
client is spewing spam.
I'd considered before proposing such functionality. The thought of
adding a third network configuration option didn't really sit well given
that people seem to have a problem with two options in the most trivial
of setups.
Prod me if I don't provide a patch for this soon. It's quite trivial.
Thanks for considering my blurb. If you don't hear from me soon,
it would be because of my vacation, not because I lost interest :)
Vacation. Now there's the best idea I heard all day!
Have fun,
Daryl
