SPF ignore mail clients connecting with SMTP auth

[a....@ukgrid.net]

Hi,

   I have another question on SPF :)
Thanks to those who helped me get it working. Now its working I have a  
problem that Im getting fails (for the moment softfails due to my SPF  
config) of users sending mail from Outlook or whatever client that is  
connecting using SMTP Auth (simple auth no SASL etc). This page says  
thats a good idea (perhaps its taking about SASLS tho) but doesnt  
really explain how its meant to work:

http://www.openspf.org/Best_Practices/SMTP_Authentication

Also the SpamAssassin documentation mentions configuring msa_networks  
which sounds relevant. Can I just list my SMTP server IP in here an  
SMTP Auth connections will be trusted? Or will that cause all  
connections to be trusted, as it sounds possible reading this
"Warning: Never include an MSA that also acts as an MX (or is also an  
intermediate relay for an MX) or otherwise accepts mail from  
non-authenticated users in msa_networks. Doing so will result in  
unknown external relays being trusted"

thanks for any ideas,

Andy.

RE: SPF ignore mail clients connecting with SMTP auth

[Giampaolo Tomassoni <Gi...@Tomassoni.biz>]

> Open a bug.

To whom it may concern:
	https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6430

RE: SPF ignore mail clients connecting with SMTP auth

[John Hardin <jh...@impsec.org>]

On Thu, 6 May 2010, Giampaolo Tomassoni wrote:

> Hello! Any SA developer here?

Open a bug.

-- 
  John Hardin KA7OHZ                    http://www.impsec.org/~jhardin/
  jhardin@impsec.org    FALaholic #11174     pgpk -a jhardin@impsec.org
  key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C  AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
   USMC Rules of Gunfighting #9: Accuracy is relative: most combat
   shooting standards will be more dependent on "pucker factor" than
   the inherent accuracy of the gun.
-----------------------------------------------------------------------
  2 days until the 65th anniversary of VE day

RE: SPF ignore mail clients connecting with SMTP auth

[Giampaolo Tomassoni <Gi...@Tomassoni.biz>]

> So is it the case according to what you´ve said below that with your
> modified logic that setting your MX servers as trusted and MSA will no
> longer result in all mail being trusted? And will that then trust mail
> recieved via SMTP Auth and therefore solve my problem?

I actually only placed a patch in bugzilla for a possible SA enhancement, so
it is not something is going to be published tomorrow. Also, you see RW
already raised a reasonable concern about it. I don't think this or future
patches will get into any SA release before wide acceptance by developers.
You may try to use the patch, anyway. But please note that RW exception is
correct: if your MXes relay incoming mail to your core SA boxes via
authenticated LMTP (or ESMTP), all your incoming mail will be ALL_TRUSTED
(which is very bad).


> Also how does SpamAssassin identify mails as being delivered using
> SMTP Authentication? Does it rely on the MTA updating the header
> appropriately? I found in my Exim config this line which I think is
> doing something like this:
> 
> ${if def:authenticated_id {\n\tauth-from $authenticated_id}}

SA identifies that a relay authenticated a submission by inspecting its
"received:" header. Most MSAs in these cases report a specific protocol
after the "with" keyword. In example: "with ESMTP" means the mail was
relayed through the Enhanced (unauthenticated) SMTP protocol, while "with
ESMTPA" would instead mean that the Enhanced SMTP protocol with
Authentication was used.

You may look at the method
Mail::SpamAssassin::Message::Metadata::Received::parse_received_line to
learn more about it.

All this of course only has a meaning as long as one is looking at the
"received:" headers from trustable relays: spammers may easily forge these
headers and their tokens outside of your internal/trust fence...


> thanks for your help, Andy.

You welcome,

Giampaolo

RE: SPF ignore mail clients connecting with SMTP auth

[a....@ukgrid.net]

Hi Giampaolo,

   thanks for the info. Im not an expert on MTAs or SpamAssassin so Im  
trying to understand your mail.
So is it the case according to what you´ve said below that with your  
modified logic that setting your MX servers as trusted and MSA will no  
longer result in all mail being trusted? And will that then trust mail  
recieved via SMTP Auth and therefore solve my problem?

Also how does SpamAssassin identify mails as being delivered using  
SMTP Authentication? Does it rely on the MTA updating the header  
appropriately? I found in my Exim config this line which I think is  
doing something like this:

${if def:authenticated_id {\n\tauth-from $authenticated_id}}

thanks for your help, Andy.

RE: SPF ignore mail clients connecting with SMTP auth

[Giampaolo Tomassoni <g....@libero.it>]

> Also the SpamAssassin documentation mentions configuring msa_networks
> which sounds relevant. Can I just list my SMTP server IP in here an
> SMTP Auth connections will be trusted? Or will that cause all
> connections to be trusted, as it sounds possible reading this
> "Warning: Never include an MSA that also acts as an MX (or is also an
> intermediate relay for an MX) or otherwise accepts mail from
> non-authenticated users in msa_networks. Doing so will result in
> unknown external relays being trusted"

This is the bargain in 3.3.1:

        if (!$relay->{auth} && !$trusted->contains_ip($relay->{ip})) {
          $in_trusted = 0;
          $in_internal = 0;     # if it's not trusted it's not internal
        } else {
          # internal_networks matches?
          if ($in_internal && !$relay->{auth} &&
!$internal->contains_ip($relay->{ip})) {
            $in_internal = 0;
          }
          # msa_networks matches?
          if ($msa->contains_ip($relay->{ip})) {
            dbg('received-header: found MSA relay, remaining relays will
be'.
                ' considered trusted: '.($in_trusted ? 'yes' : 'no').
                ' internal: '.($in_internal ? 'yes' : 'no'));
            $found_msa = 1;
            $relay->{msa} = 1;
          }
        }

it seems to me that if you put your MX in both the trusted_networks *and*
the msa_networks one, you end having every incoming mail from your MX as
MSA-delivered. The paradox is that incoming, authenticated mails would be
regarded as from a trusted relay, not an MSA...

I have difficulties in understanding the logic here. The fact that a
previously received header from a trusted relay had delivered the message
via authentication, seems to me that relay acted after all like an MSA, or
at least that SA should probably trust the relay chain from there on. I
don't see why not (but it could be due to my myopia).

So, if my myopia isn't that bad, I would instead code this way:

        if (!$relay->{auth} && !$trusted->contains_ip($relay->{ip})) {
          $in_trusted = 0;
          $in_internal = 0;     # if it's not trusted it's not internal
        } else {
          # internal_networks matches?
          if ($in_internal && !$relay->{auth} &&
!$internal->contains_ip($relay->{ip})) {
            $in_internal = 0;
          }
          # msa_networks matches?
          if ($relay->{auth} || $msa->contains_ip($relay->{ip})) {
            dbg('received-header: found MSA relay, remaining relays will
be'.
                ' considered trusted: '.($in_trusted ? 'yes' : 'no').
                ' internal: '.($in_internal ? 'yes' : 'no'));
            $found_msa = 1;
            $relay->{msa} = 1;
          }
        }

which should regard a relay as MSA also when a trusted relay did auth the
user.

Hello! Any SA developer here?