Re: trusted_networks confusion--authentication

[Ross Boylan <ro...@biostat.ucsf.edu>]

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:
[..]
> Mail Submission Agent... accepts mail from your own clients' MUAs (also 
> known as UAs).
> 
> 
> >> 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 ross@biostat.ucsf.edu; 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?

[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.

For completeness, here's what I did to find out what the requirements
were:  I looked at RFC 3848; it seems to be mostly a pointer to other
RFCs, and none of those said what should go in the received headers
specifically for SMTP auth (as far as I can tell, checking 2554, 2821,
2822).  google with sendmail also didn't help, nor did the exim spec
provide any details about what it does with the received lines for AUTH.
exim's standard Received: template includes
       ${if def:received_protocol {with $received_protocol}} \
       ${if def:tls_cipher {($tls_cipher)\n\t}}\
which seems to provide info on whether authentication occurred and any
TLS use, but no particular cryptographic tokens.

However, 3848 does specify the names ESMTPA and ESMTPSA, which is exim's
$received_protocol.


> >>
> >>   - 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?

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?


Ross

Re: trusted_networks confusion--authentication

["Daryl C. W. O'Shea" <sp...@dostech.ca>]

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 ross@biostat.ucsf.edu; 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