You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Dan Schwartz <Da...@Lehigh.EDU> on 2007/05/09 16:22:30 UTC
Authenticated SMTP and SA
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I'm running sendmail 8.14.1 configured to do authenticated e-mail
relaying with port 587 and TLS encryption. When our users authenticate
and send a message sendmail changes the received header line to look
like this -
> Received: from dyn041100.cc.lehigh.edu (Dyn041100.CC.Lehigh.EDU [128.180.41.100])
> (authenticated bits=0)
> by rain.CC.Lehigh.EDU (8.14.1/8.14.1) with ESMTP id l49DkUi3019835
> (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT)
> for <us...@spamassassin.apache.org>; Wed, 9 May 2007 09:46:30 -0400
Anyway, SA 3.2 doesn't appear to recognize this as being a "trusted"
message based on the authenticated portion, and SPF_FAIL gets triggered
if the message is coming from a source which wouldn't normally be
allowed (but is allowed because the message was sent via an
authenticated connection).
So my question is, did I miss something in configuring SA so that
authenticated e-mail messages are trusted and won't trigger the SPF_FAIL
and other rules, or do I need to set up spamass-milter or spamc
differently so that authenticated messages simply bypass SA checking
altogether?
Thanks -
Dan Schwartz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFGQdkhhCibbju3xzcRAjqfAJ9CLaa4bgOkmJkvrJt9JWWjDYxjcwCeO814
gUULw1uy/IgS+d/hAQrVtXQ=
=Rv1y
-----END PGP SIGNATURE-----
Re: Authenticated SMTP and SA
Posted by "Daryl C. W. O'Shea" <sp...@dostech.ca>.
Dan Schwartz wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> I'm running sendmail 8.14.1 configured to do authenticated e-mail
> relaying with port 587 and TLS encryption. When our users authenticate
> and send a message sendmail changes the received header line to look
> like this -
>
>> Received: from dyn041100.cc.lehigh.edu (Dyn041100.CC.Lehigh.EDU [128.180.41.100])
>> (authenticated bits=0)
>> by rain.CC.Lehigh.EDU (8.14.1/8.14.1) with ESMTP id l49DkUi3019835
>> (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT)
>> for <us...@spamassassin.apache.org>; Wed, 9 May 2007 09:46:30 -0400
>
> Anyway, SA 3.2 doesn't appear to recognize this as being a "trusted"
> message based on the authenticated portion, and SPF_FAIL gets triggered
> if the message is coming from a source which wouldn't normally be
> allowed (but is allowed because the message was sent via an
> authenticated connection).
Try running a message that exhibits this problem through 'spamassassin'
on the command line after first removing any received headers that are
added after SA sees the message. I expect that you won't see the
problem if there are either no relays (and thus received headers)
between the received header quoted above and what SA sees or if there
is, you've got your trusted_networks configured correctly.
> So my question is, did I miss something in configuring SA so that
> authenticated e-mail messages are trusted and won't trigger the SPF_FAIL
> and other rules, or do I need to set up spamass-milter or spamc
> differently so that authenticated messages simply bypass SA checking
> altogether?
If the command line test above doesn't exhibit the problem I would
expect that spamass-milter isn't including the auth line when it fakes
the received header. A quick look at the spamass-milter code would
confirm whether this is the case or not (it should be easy to find,
there's not much to the milter).
Daryl