Daryl C. W. O'Shea wrote:
> René Berber wrote:
>>
[snip]
>> So the problem is that SA doesn't recognize that users are
>> authenticated, I saw
>> this document: http://wiki.apache.org/spamassassin/DynablockIssues
>> which just
>> says to add a LOCAL_AUTH_RCVD rule that matches your mail server, I
>> did and it
>> doesn't work as expected: SA matches the rule and adds a 1.0 score, the
>> pseudo-header shows no authentication was recognized:
>
> That's not what it "just says". The info before it talks about how
> SpamAssassin will attempt to detect RFC 3848 style auth tokens (it'll
> also detect Sendmail and a few other styles of auth tokens) and how
> Postfix is a pain in the ass about this (but finally, optionally,
> provides the info in Postfix 2.3).
I read all the page before asking, and I understand that it follows the trust
path page. The fact is SA is not detecting the authentication, and there is
nothing in that page that gives a clue as to why, it just mentions that
LOCAL_AUTH_RCVD rule and it certainly doesn't say it's not needed for sendmail.
>
>> dbg: metadata: X-Spam-Relays-Untrusted: [ ip=200.52.129.137
>> rdns=mail.legosoft.com.mx helo= by=cactus-soft.dyndns.org ident=
>> [EMAIL PROTECTED] intl=0 id=J9POUJ-0001MC-JY auth= ] [
>> ip=189.149.70.163 rdns=dsl-189-149-70-163.prod-infinitum.com.mx
>> helo=MARISELA
>> by=mail.legosoft.com.mx ident= envfrom= intl=0 id=kB3G26P6019032 auth= ]
>
> It doesn't look like you have your trusted_networks configured
> correctly. Fix that before you even attempt to get auth token detection
> working.
It is configured correctly (don't assume something you don't know), it is in my
mailscanner.cf, like this :
trusted_networks 192.168.10/24
trusted_networks 200.52.129.137
>> Any help clarifying how the LOCAL_AUTH_RCVD rule is used, or an
>> alternative to
>> make SA recognize the authenticated user, will be appreciated.
>
> I've updated the DynablockIssues wiki page to be clear that custom rules
> are only a workaround for less than helpful MTAs.
I've ran SA with -D, it sees the (standard sendmail) header and created the 2
trusted pseudo-headers, but doesn't detect the authentication:
$ spamassassin -x -D -t < S.eml
[824] dbg: logger: adding facilities: all
[824] dbg: logger: logging level is DBG
[824] dbg: generic: SpamAssassin version 3.1.7
...
[824] dbg: received-header: unknown format: via tmail-2002(14) (invoked by user
rberber) for rberber; Sun, 3 Dec 2006 13:01:33 -0600
[824] dbg: received-header: unparseable: via tmail-2002(14) (invoked by user
rberber) for rberber; Sun, 3 Dec 2006 13:01:33 -0600
[824] dbg: received-header: parsed as [ ip=200.52.129.137
rdns=mail.legosoft.com.mx helo= by=cactus-soft.dyndns.org ident=
[EMAIL PROTECTED] intl=0 id=J9POUJ-0001MC-JY auth= ]
[824] dbg: received-header: relay 200.52.129.137 trusted? yes internal? yes
[824] dbg: received-header: parsed as [ ip=189.149.70.163
rdns=dsl-189-149-70-163.prod-infinitum.com.mx helo=MARISELA
by=mail.legosoft.com.mx ident= envfrom= intl=0 id=kB3G26P6019032 auth= ]
[824] dbg: received-header: relay 189.149.70.163 trusted? no internal? no
[824] dbg: metadata: X-Spam-Relays-Trusted: [ ip=200.52.129.137
rdns=mail.legosoft.com.mx helo= by=cactus-soft.dyndns.org ident=
[EMAIL PROTECTED] intl=1 id=J9POUJ-0001MC-JY auth= ]
[824] dbg: metadata: X-Spam-Relays-Untrusted: [ ip=189.149.70.163
rdns=dsl-189-149-70-163.prod-infinitum.com.mx helo=MARISELA
by=mail.legosoft.com.mx ident= envfrom= intl=0 id=kB3G26P6019032 auth= ]
[824] dbg: metadata: X-Spam-Relays-Internal: [ ip=200.52.129.137
rdns=mail.legosoft.com.mx helo= by=cactus-soft.dyndns.org ident=
[EMAIL PROTECTED] intl=1 id=J9POUJ-0001MC-JY auth= ]
[824] dbg: metadata: X-Spam-Relays-External: [ ip=189.149.70.163
rdns=dsl-189-149-70-163.prod-infinitum.com.mx helo=MARISELA
by=mail.legosoft.com.mx ident= envfrom= intl=0 id=kB3G26P6019032 auth= ]
...
The message headers are :
Received: via tmail-2002(14) (invoked by user rberber) for rberber; Sun, 3 Dec
2006 13:01:33 -0600
...
Received: from mail.legosoft.com.mx ([200.52.129.137])
by cactus-soft.dyndns.org with esmtps (TLSv1:AES256-SHA:256)
(Exim 4.63)
(envelope-from <[EMAIL PROTECTED]>)
id J9POUJ-0001MC-JY
for [EMAIL PROTECTED]; Sun, 03 Dec 2006 13:01:32 -0600
Received: from MARISELA (dsl-189-149-70-163.prod-infinitum.com.mx
[189.149.70.163] (may be forged))
(authenticated bits=0)
by mail.legosoft.com.mx (8.13.8/8.13.8) with ESMTP id kB3G26P6019032
for <[EMAIL PROTECTED]>; Sun, 3 Dec 2006 10:02:16 -0600 (CST)
...
The result is that twice SA didn't recognize the authentication, first in the
company server, and later on my home server with the received message which I'm
testing again.
>> Using SA 3.1.7, under Solaris 9 with sendmail 8.13.8 and Windwos XP
>> manually for
>> testing.
>
> Sendmail should be putting a "(authenticated bits=0)" line in its
> Received header when the user authenticates. SA will automatically use
> this to extend the trust path if the header above it is trusted.
And that is probably the cause of the problem, not SA, but the "header above" is
not the first, tmail added one which is marked as unparseable. I can get rid
of that one easy... but testing results in no change.
How can I debug SA not detecting the authentification?
--
René Berber
