Mark Martinec wrote:
Daryl C. W. O'Shea writes:
Yeah, and correct. Your MSA is the host responsible for sending the
mail to your server running SA. Your SPF record must cover the MSAs IP.
Ok, as a stop-gap solution this works, thanks.
But it is not the right general-purpose solution. This is about
internal->external or internal->internal mail. SPF describes the domain
fan-out perimeter to the outside world. It is not intended to describe
internal topology to internal mailers:
- it is nobody's business to be aware of our internal topology,
There's always split views.
- SPF may even be unable to describe some more convoluted internal solutions,
You're not treating your users as internal though. Even still, I can't
think of a setup that couldn't be described with an SPF record. If you
had to describe mail flow, sure there'd be problems galore, but you only
have to declare what hosts may hand off mail to your internal network
(internal in the sense of your SPF checking config, not physical).
That's trivial, and always doable.
- using split-view DNS just for SPF seems like an overkill.
Well, you're already using split views of your internal network. :)
You've told SA to treat it one way (you've split it between your servers
and your end users) and you want to treat it another way (as a whole).
Looking at the options, SA could either check the IP of your MSA or the
IP of the remote client. Obviously checking the remote client IP is wrong.
If mail is coming from our own genuine user through our own internal
mail infrastructure, SPF should not be checking anything at all.
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.
Radoslaw Zielinski writes:
Disagreed. Mark's MSA <-> SA+MTA distinction is a matter of internal
configuration, which does not need to be revealed to the public in a
SPF record.
Right.
Let's try to clear some concepts on an imaginary topology:
MX1 MX2
| |
roaming v v MX3
users MTA3 /
| | /
v v v
MSA ---> MTA1 --> MTA2 --> MTA+SA --> MTA-TX1 --> outside
^ | --> MTA-TX2 --> outside
| v
internal MDA
networks
SPF should only list MTA-TX1 and MTA-TX2.
If it happens this coincides with some other mailer, so be it.
SA needs to know which Received header lines to trust to be genuine.
For mail coming from outside it should trust all listed MX hosts
for our domains, plus all MTAs in the path to our SA,
i.e. MTA3 and MTA+SA.
For mail coming from our users (destined for outside or to another
internal user) it should trust unconditionally our MSA hosts,
plus all MTAs in the path to our SA, i.e. MTA1, MTA2 and MTA+SA.
SA should not second-guess the decision taken by MSA to accept mail!!!
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.
If you do trust it to not relay spam then you need to add it to your
internal networks. You'd then also have to add your end users to your
trusted and internal networks too, since (by definition of you trusting
your MSA not to send spam when it's only accepting mail from your users)
you'd be trusting them not to send spam to the MSA.
MSA *must* be assumed not to be an open relay (if it is, there will
be more serious things to worry about). MSA makes its decision to
accept mail usually by checking if client IP address belongs to
internal networks, or is authenticated (SASL, or POP-before-SMTP),
or by a firewall protection or VPN or whatever. It is simply
wrong for SA to try to re-check and second-guess desicions taken
by MSA - if we are lucky SA would just be doing unnecessary work,
but if we are unlucky it would come to a wrong conclusion (like in
my original case), simply because it lacks sufficient information.
Exactly, it's lacking the info. You told it that your MSA was not a
part of your internal networks, so it's treating it as if it wasn't.
So where does internal_networks come into play at all?
In the above example - nowhere, except if it is a (possibly too blunt)
tool to list internal relaying MTAs.
Only MSA needs this information (mynetworks).
If you don't want to declare internal networks you don't need to since
it sounds like the config you want has the exact same trusted and
internal networks config. SA will just copy the trusted networks over
to the internal networks.
Now what happens if some of the above functions are merged.
As far as SPF is concerned, nothing unexpected happens, one would
just list all hosts that are able to officially send mail to the
outside world, as per SPF definition.
It gets more interesting when MSA gets merged with MX, so that
such MTA handles both incoming mail, as well as mail from our users.
In my opinion the core or the SA confusion is right here: SA tries
to be very clever (based on internal/trusted networks and SASL
headers and what not) to guess where mail is coming from and to what
extent can it be trusted and what should be checked. It other words,
it tries to determine if for a particular mail this MTA+SA is acting
as MSA or as MX (or perhaps as an intermediate relaying MTA).
The sole purpose of internal_networks currently is to help
SA figure out this puzzle - is MTA+SA also a MSA right now, or not.
I'm not sure what your point is here. Yeah, SA tries to do the right
thing. When all the relevant info is provided to SA, I've yet to see a
case where it gets it wrong.
Perhaps if we manage to describe the topology in other terms,
it would be more natural to administrators to configure it correctly,
and with some luck also for SA to make better decisions.
As far as trusted_networks are concerned, it seems the current
solution is just fine: every MTA in the above picture is listed
as trusted and this is it. Adding internal_networks to trusted_networks
would be unnecessary if MSAs would be unconditionally trusted.
By not including the MSA in your internal networks you told it not to
unconditionally trust it. I don't see what the problem with this is.
If you want the host unconditionally trusted then include it in your
trusted networks. That's what internal networks are for.
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.
MSA list would be implied in trusted networks (or merged into it).
Only if MSA would happen to coincide with MTA+SA, then internal_networks
and testing for authentication headers would come into play, letting
SA re-trace steps already taken by MTA when it considered accepting a mail.
I'll stop here, without proposing a specific solution.
I hope some alternative and more intuitive approach
would evolve from this thread. Food for thought.
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.
Daryl
