On 6/30/2006 10:46 PM, Ross Boylan wrote:
Now for the "3 tests" as they apply to my non-hypothetical case.
On Wed, 2006-06-28 at 01:45 -0400, Daryl C. W. O'Shea wrote:
You can not add your MSA to your internal_networks unless you can do one
of the following:
- have all your MSA users use SMTP auth AND use mail server software
that includes RFC 3848 or Sendmail-style auth tokens in it's received
headers
Although my simple example didn't involve this, I have a feeling one of
the real servers I'm dealing with does. I've been unable to find out
exactly what it would mean to meet the requirement above (specifically
the requirement for "mail server software that includes RFC 3848 or
Sendmail-style auth tokens in it's received headers"). The received
headers from that system do look like (edited slightly for security)
Received: from x.y.z.net ([64.1.2.3]
helo=[10.0.11.25]) by biostat.ucsf.edu with esmtpsa
(TLSv1:RC4-SHA:128) (Exim
4.50) id 1FtS7g-0004tO-BY for [EMAIL PROTECTED]; Thu, 22 Jun
2006
09:33:40 -0700
so this particular connection was encrypted as well as authenticated.
It does say "with esmtpsa". Is that sufficient?
YES. RFC3848 describes the "with types", some of which indicate that
the client authenticated in some way. ESMPTSA is secure and
authenticated, while ESMPTA would just we authenticated. Either would
suffice.
[The next 3 paragraphs explain why I have doubts that it is sufficient,
as well as some evidence it is. Readers may wish to skip ahead.]
From the phrase "auth tokens" I thought the line was supposed to include
some cryptographic signature. The material in parens
(TLSv1:RC4-SHA:128) seems simply to indicate the details of the
encryption mechanism (maybe RC4-SHA refers to authentication?), but not
any particular key.
By auth tokens, I simply mean some indication that the client
authenticated. One of the RFC3848 with types indicating authentication
would be an auth token. Another would be the "(authenticated bits="
line that Sendmail inserts when a client authenticates. See the headers
of any email from me for an example.
Currently the four groups of auth tokens (or authentication indicators)
that SA will parse are:
- Critical Path's "(authenticated as" line
- Courier's "AUTH: auth-type" lines
- with types: ESMTPA|ESMTPSA|LMTPA|LMTPSA|ASMTP|HTTP
- Sendmail's "(authenticated bits=" line
For a whole bunch of background on why this was necessary see:
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=2462
- include ALL of your MSA users' IP addresses in your trusted_networks
and internal_networks -- you can only do this if you control all of
the IP space in question and never have roaming users sending mail
from remote IP space (which is nearly never the case)
- use the POPAuth plugin to extend trusted_networks to POP-before-SMTP
clients if you use POP-before-SMTP for user authentication
Note: Only configure trusted_networks if you're using this plugin,
do not configure internal_networks
If you can do any of the above, you can include your MSA in your
internal_networks config (except for the POPAuth case). Since most
people will only include their own MXes, internal relays and MSA in
their trusted_networks this means that the internal_networks config
would be the same as the trusted_networks config. In this case you'd
only have to set one of them (and it's recommended that you'd set the
trusted_networks).
[...]
And later you wrote
Some people may use more than one of the solutions. It all depends
on how your users authenticate with your MSA.
So, in particular, if the mail server were to accept mail from our own
clients either if they came from a recognized one of our IP's or if they
used SMTP auth from elsewhere, SA would be OK if I set trusted_networks
to be the address of the server and of all our IPs. internal_networks
will automatically use the same list. And SA will handle things as it
should. Right?
You've got it.
It'll work right, and you're right that you don't need to also set
internal networks manually. In fact, you're probably better of that way
(not setting it).
In particular, if our IP's include non-public ranges (e.g.,
192.168.1.0/24), I should include those in the trusted_networks list as
well, right?
Yes.
Also, more relevant info to all of this:
http://wiki.apache.org/spamassassin/DynablockIssues
Daryl
