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 <[EMAIL PROTECTED]>; 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
