Re: Recognizing Sendmail's authentication -- patch included (WAS: How is LOCAL_AUTH_RCVD used?)
Daryl C. W. O'Shea wrote:
[snip]
> 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.
Let's start by saying two things:
1) LOCAL_AUTH_RCVD doesn't do anything useful, just to clarify what happened to
the original subject.
2) SA 3.1.7 (and 3.1.5) doesn't seem to recognize Sendmail's authentication
under some circumstances. I assume that it does recognize it for other
messages, even if I have not seen evidence to that effect.
If I change Received.pm, line 414, like this:
# Sendmail, MDaemon, some webmail servers, and others
- elsif (/^from .*?(?:\]\)|\)\]) .*?\(.*?authenticated.*?\).*? by/) {
+ elsif (/^from .*?(.*?authenticated.*?\).*? by/) {
It does recognize the authentication line I showed before, and the message is
not scored by Botnet which is what I wanted.
The relevant debug output:
...
[2932] 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=Sendmail ]
[2932] dbg: received-header: relay 189.149.70.163 trusted? yes internal? yes
[2932] 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= ] [ 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=1 id=kB3G26P6019032 auth=Sendmail ]
...
The full path to the patched file is
/usr/lib/perl5/site_perl/5.8/Mail/SpamAssassin/Message/Metadata/Received.pm
--
René Berber
Re: Recognizing Sendmail's authentication -- patch included (WAS: How is LOCAL_AUTH_RCVD used?)
René Berber wrote:
If I change Received.pm, line 414, like this:
# Sendmail, MDaemon, some webmail servers, and others
- elsif (/^from .*?(?:\]\)|\)\]) .*?\(.*?authenticated.*?\).*? by/) {
+ elsif (/^from .*?(.*?authenticated.*?\).*? by/) {
This can't be right. You have mismatched parens. Perl agrees with me:
perl -wc
/usr/local/lib/perl5/site_perl/5.8.7/Mail/SpamAssassin/Message/Metadata/Received.pm
Unmatched ( in regex; marked by <-- HERE in m/^from .*?( <-- HERE
.*?authenticated.*?\).*? by/ at
/usr/local/lib/perl5/site_perl/5.8.7/Mail/SpamAssassin/Message/Metadata/Received.pm
line 415.
--
Jo Rhett
Network/Software Engineer
Net Consonance
Re: Recognizing Sendmail's authentication -- patch included (WAS: How is LOCAL_AUTH_RCVD used?)
So I did some digging, and by deliberately breaking the REGEX (adding
NOMATCH to the middle of the line) I confirmed several things:
1. The line works properly on my system with the patch
2. If the line matches then ALL_TRUSTED is applied
3. ALL_TRUSTED does nothing to negate SPF checks
René Berber wrote:
Daryl C. W. O'Shea wrote:
[snip]
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.
Let's start by saying two things:
1) LOCAL_AUTH_RCVD doesn't do anything useful, just to clarify what happened to
the original subject.
2) SA 3.1.7 (and 3.1.5) doesn't seem to recognize Sendmail's authentication
under some circumstances. I assume that it does recognize it for other
messages, even if I have not seen evidence to that effect.
If I change Received.pm, line 414, like this:
# Sendmail, MDaemon, some webmail servers, and others
- elsif (/^from .*?(?:\]\)|\)\]) .*?\(.*?authenticated.*?\).*? by/) {
+ elsif (/^from .*?(.*?authenticated.*?\).*? by/) {
It does recognize the authentication line I showed before, and the message is
not scored by Botnet which is what I wanted.
The relevant debug output:
...
[2932] 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=Sendmail ]
[2932] dbg: received-header: relay 189.149.70.163 trusted? yes internal? yes
[2932] 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= ] [ 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=1 id=kB3G26P6019032 auth=Sendmail ]
...
The full path to the patched file is
/usr/lib/perl5/site_perl/5.8/Mail/SpamAssassin/Message/Metadata/Received.pm
--
Jo Rhett
Network/Software Engineer
Net Consonance
Re: Recognizing Sendmail's authentication -- patch included (WAS: How is LOCAL_AUTH_RCVD used?)
Jo Rhett wrote:
René Berber wrote:
If I change Received.pm, line 414, like this:
# Sendmail, MDaemon, some webmail servers, and others
- elsif (/^from .*?(?:\]\)|\)\]) .*?\(.*?authenticated.*?\).*? by/) {
+ elsif (/^from .*?(.*?authenticated.*?\).*? by/) {
This can't be right. You have mismatched parens. Perl agrees with me:
I think, given one of the escaped parens, he meant this:
+ elsif (/^from .*?\(.*?authenticated.*?\).*? by/) {
Though, CommuniGate Pro's authenticated received header looks like this:
from [$ipaddr] (acccount $account HELO $helostring) by $host
(CommuniGate Pro
So, you could match that with:
/^from \[\S+\] \(account [EMAIL PROTECTED] .*\) by \S+ \(CommuniGate Pro/
Re: Recognizing Sendmail's authentication -- patch included (WAS: How is LOCAL_AUTH_RCVD used?)
Sorry, in my reply I meant to point out that the original line was
working properly for me (Sendmail environment) but that the line working
did not solve my problem.
John Rudd wrote:
Jo Rhett wrote:
René Berber wrote:
If I change Received.pm, line 414, like this:
# Sendmail, MDaemon, some webmail servers, and others
- elsif (/^from .*?(?:\]\)|\)\]) .*?\(.*?authenticated.*?\).*? by/) {
+ elsif (/^from .*?(.*?authenticated.*?\).*? by/) {
This can't be right. You have mismatched parens. Perl agrees with me:
I think, given one of the escaped parens, he meant this:
+ elsif (/^from .*?\(.*?authenticated.*?\).*? by/) {
Though, CommuniGate Pro's authenticated received header looks like this:
from [$ipaddr] (acccount $account HELO $helostring) by $host
(CommuniGate Pro
So, you could match that with:
/^from \[\S+\] \(account [EMAIL PROTECTED] .*\) by \S+ \(CommuniGate Pro/
--
Jo Rhett
Network/Software Engineer
Net Consonance
Re: Recognizing Sendmail's authentication -- patch included (WAS: How is LOCAL_AUTH_RCVD used?)
Jo Rhett wrote:
> René Berber wrote:
>> If I change Received.pm, line 414, like this:
>>
>> # Sendmail, MDaemon, some webmail servers, and others
>> - elsif (/^from .*?(?:\]\)|\)\]) .*?\(.*?authenticated.*?\).*? by/) {
>> + elsif (/^from .*?(.*?authenticated.*?\).*? by/) {
>
> This can't be right. You have mismatched parens. Perl agrees with me:
Yes, it's a typo, should be:
elsif (/^from .*?\(.*?authenticated.*?\).*? by/) {
--
René Berber
Re: Recognizing Sendmail's authentication -- patch included (WAS: How is LOCAL_AUTH_RCVD used?)
René Berber wrote:
Jo Rhett wrote:
René Berber wrote:
If I change Received.pm, line 414, like this:
# Sendmail, MDaemon, some webmail servers, and others
- elsif (/^from .*?(?:\]\)|\)\]) .*?\(.*?authenticated.*?\).*? by/) {
+ elsif (/^from .*?(.*?authenticated.*?\).*? by/) {
This can't be right. You have mismatched parens. Perl agrees with me:
Yes, it's a typo, should be:
elsif (/^from .*?\(.*?authenticated.*?\).*? by/) {
So just FYI, with both plain sendmail and with amavisd-milter, the
original line worked fine for me.
If you are using a different MTA then perhaps you should submit this as
a patch with its own elsif {} container for that mailer?
Or send me a copy of your recieved line and I'll do the patch for you.
--
Jo Rhett
Network/Software Engineer
Net Consonance
Re: Recognizing Sendmail's authentication -- patch included (WAS: How is LOCAL_AUTH_RCVD used?)
Jo Rhett wrote:
> René Berber wrote:
>> Jo Rhett wrote:
>>
>>> René Berber wrote:
If I change Received.pm, line 414, like this:
# Sendmail, MDaemon, some webmail servers, and others
- elsif (/^from .*?(?:\]\)|\)\]) .*?\(.*?authenticated.*?\).*? by/) {
+ elsif (/^from .*?(.*?authenticated.*?\).*? by/) {
>>> This can't be right. You have mismatched parens. Perl agrees with me:
>>
>> Yes, it's a typo, should be:
>>
>> elsif (/^from .*?\(.*?authenticated.*?\).*? by/) {
>
> So just FYI, with both plain sendmail and with amavisd-milter, the
> original line worked fine for me.
Thanks for the info; more comments below.
> If you are using a different MTA then perhaps you should submit this as
> a patch with its own elsif {} container for that mailer?
I'm using sendmail 8.13.8, the line before the one I changed says it is for
sendmail and others (that's why I included the original comment in the code) so
that is the correct line.
> Or send me a copy of your recieved line and I'll do the patch for you.
The change I made works on a test from someone that was on vacation and sending
a message (to me) using his ISP account, the header includes a lot of extra text
with the usual dynamic IP stuff and "may be forged" and there was no way it
would be a match by the original line. With my change, there is a match.
It is probable that other, fixed, IPs can be matched by that original line, but
I haven't even look at them since the sendmail configuration I'm using is some
fixed IPs defined in relay-domains and access db, those don't need to use
authentication, every other IP (all dynamic) does need authentication if they
want to relay from the server.
A comment, the original line looks suspicious to me first because it looks like
a modified copy of the previous match on the code (for qmail), that one used a
match field that is unnecessary on the sendmail's line. But if you say it
works, then I must be mistaken; anyway the modified line should also work so
there is no damage in my change.
--
René Berber
Re: Recognizing Sendmail's authentication -- patch included (WAS: How is LOCAL_AUTH_RCVD used?)
René Berber wrote: Or send me a copy of your recieved line and I'll do the patch for you. The change I made works on a test from someone that was on vacation and sending a message (to me) using his ISP account, the header includes a lot of extra text with the usual dynamic IP stuff and "may be forged" and there was no way it would be a match by the original line. With my change, there is a match. Can you post the line with the hostnames obscured? I'd like to see it. -- Jo Rhett Network/Software Engineer Net Consonance
Re: Recognizing Sendmail's authentication -- patch included (WAS: How is LOCAL_AUTH_RCVD used?)
Jo Rhett wrote: > René Berber wrote: >> >> The change I made works on a test from someone that was on vacation and >> sending >> a message (to me) using his ISP account, the header includes a lot of extra >> text >> with the usual dynamic IP stuff and "may be forged" and there was no way it >> would be a match by the original line. With my change, there is a match. > > Can you post the line with the hostnames obscured? I'd like to see it. It's the same one I posted before: 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 original test is looking for a pair of closing parenthesis ")]" or "])" which is not there (not together, but a fixed IP probably has those), or something followed by colon and there is no colon at all (the test is done starting with "from"). -- René Berber
Re: Recognizing Sendmail's authentication -- patch included (WAS: How is LOCAL_AUTH_RCVD used?)
René Berber wrote: Jo Rhett wrote: René Berber wrote: The change I made works on a test from someone that was on vacation and sending a message (to me) using his ISP account, the header includes a lot of extra text with the usual dynamic IP stuff and "may be forged" and there was no way it would be a match by the original line. With my change, there is a match. Can you post the line with the hostnames obscured? I'd like to see it. It's the same one I posted before: 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 original test is looking for a pair of closing parenthesis ")]" or "])" which is not there (not together, but a fixed IP probably has those), or something followed by colon and there is no colon at all (the test is done starting with "from"). Do you know why the SMTP authenticating server was forging the HELO name? Normal mail clients will give their IP address, right? And the "may be forged" only appears if they gave a full name and resolution succeeded *and* none of the addresses returned matched the helo name. In short, this may have been a deliberate choice to prevent a match on hosts with forged helo names. It would make sense. -- Jo Rhett Network/Software Engineer Net Consonance
Re: Recognizing Sendmail's authentication -- patch included (WAS: How is LOCAL_AUTH_RCVD used?)
Jo Rhett wrote: > René Berber wrote: >> Jo Rhett wrote: >> >>> René Berber wrote: The change I made works on a test from someone that was on vacation and sending a message (to me) using his ISP account, the header includes a lot of extra text with the usual dynamic IP stuff and "may be forged" and there was no way it would be a match by the original line. With my change, there is a match. >>> Can you post the line with the hostnames obscured? I'd like to see it. >> >> It's the same one I posted before: >> >> 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 original test is looking for a pair of closing parenthesis ")]" or "])" >> which is not there (not together, but a fixed IP probably has those), or >> something followed by colon and there is no colon at all (the test is done >> starting with "from"). > > Do you know why the SMTP authenticating server was forging the HELO > name? Normal mail clients will give their IP address, right? And the > "may be forged" only appears if they gave a full name and resolution > succeeded *and* none of the addresses returned matched the helo name. > > In short, this may have been a deliberate choice to prevent a match on > hosts with forged helo names. It would make sense. I don't agree, there is no HELO forging, the name MARISELA is the laptop's name (set in Windows), the address is the dynamic IP given by the ISP. The IP does have a reverse but no name for the IP which is normal for the big pool of addresses from that ISP and produces the "may be forged" part. You say "normal clients", well this client is Microsoft Outlook (Office 200x edition), I don't see anything abnormal in what it is doing. Giving the IP address is probably useless if they are, most of the time, inside a private network (no name resolution at all). The test in question is doing only one thing: check if there was authentication or not. No attempt is made, and IMO should be made, to check if the HELO is forged; that is another test done somewhere else. Remember the context, SA only takes authentication in consideration if it was done with a trusted server, in this case it was so it counts. -- René Berber
Re: Recognizing Sendmail's authentication -- patch included (WAS: How is LOCAL_AUTH_RCVD used?)
On Tue, 5 Dec 2006, Jo Rhett wrote:
> René Berber wrote:
> > It's the same one I posted before:
> >
> > 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 original test is looking for a pair of closing parenthesis ")]" or "])"
> > which is not there (not together, but a fixed IP probably has those), or
> > something followed by colon and there is no colon at all (the test is done
> > starting with "from").
>
> Do you know why the SMTP authenticating server was forging the HELO
> name? Normal mail clients will give their IP address, right? And the
> "may be forged" only appears if they gave a full name and resolution
> succeeded *and* none of the addresses returned matched the helo name.
>
> In short, this may have been a deliberate choice to prevent a match on
> hosts with forged helo names. It would make sense.
Jo you are mistaken. Sendmail adds the "(may be forged)" comment when
the client's IP rDNS and DNS don't match, it has -nothing- to do with the
HELO name.
It still should not matter. So long as the client can authenticate to
the server's statisfaction, SA should honor its decision regardless of
how bogus the HELO or client's DNS entrys look.
--
Dave Funk University of Iowa
College of Engineering
319/335-5751 FAX: 319/384-0549 1256 Seamans Center
Sys_admin/Postmaster/cell_adminIowa City, IA 52242-1527
#include
Better is not better, 'standard' is better. B{
Re: Recognizing Sendmail's authentication -- patch included (WAS: How is LOCAL_AUTH_RCVD used?)
René Berber wrote:
Daryl C. W. O'Shea wrote:
[snip]
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.
Let's start by saying two things:
1) LOCAL_AUTH_RCVD doesn't do anything useful, just to clarify what happened to
the original subject.
It's solely a workaround, suggested by Dana from UW's CIS dept before
there was any support at all for detecting authenticated relays, for how
you might workaround the problem. As I said yesterday, I updated the
wiki page to hopefully make this clear. If it's still somehow not clear
that it's only a workaround please let me know, or take a shot at making
it clearer yourself.
2) SA 3.1.7 (and 3.1.5) doesn't seem to recognize Sendmail's authentication
under some circumstances. I assume that it does recognize it for other
messages, even if I have not seen evidence to that effect.
If I change Received.pm, line 414, like this:
# Sendmail, MDaemon, some webmail servers, and others
- elsif (/^from .*?(?:\]\)|\)\]) .*?\(.*?authenticated.*?\).*? by/) {
+ elsif (/^from .*?(.*?authenticated.*?\).*? by/) {
Yeah, as you've found, the regex doesn't match when Sendmail adds a
comment about a connection's funky DNS entries. Amazingly nobody has
had the same problem and brought it to our attention in the more than
two years since I wrote that code.
It'll be fixed in the next version of SpamAssassin to be released.
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=5223
Daryl
Re: Recognizing Sendmail's authentication -- patch included (WAS: How is LOCAL_AUTH_RCVD used?)
John Rudd wrote: Though, CommuniGate Pro's authenticated received header looks like this: from [$ipaddr] (acccount $account HELO $helostring) by $host (CommuniGate Pro So, you could match that with: /^from \[\S+\] \(account [EMAIL PROTECTED] .*\) by \S+ \(CommuniGate Pro/ Cool, I don't think we currently support that. Daryl
Re: Recognizing Sendmail's authentication -- patch included (WAS: How is LOCAL_AUTH_RCVD used?)
David B Funk wrote: On Tue, 5 Dec 2006, Jo Rhett wrote: In short, this may have been a deliberate choice to prevent a match on hosts with forged helo names. It would make sense. Jo you are mistaken. Sendmail adds the "(may be forged)" comment when the client's IP rDNS and DNS don't match, it has -nothing- to do with the HELO name. It still should not matter. So long as the client can authenticate to the server's statisfaction, SA should honor its decision regardless of how bogus the HELO or client's DNS entrys look. Yeah, simply an oversight on my part. I get extremely little ham with "(may be forged)" and zero that also is authenticated at that relay. I'll be fixed. Daryl
Re: Recognizing Sendmail's authentication -- patch included (WAS: How is LOCAL_AUTH_RCVD used?)
Jo Rhett wrote: Do you know why the SMTP authenticating server was forging the HELO name? Normal mail clients will give their IP address, right? And the "may be forged" only appears if they gave a full name and resolution succeeded *and* none of the addresses returned matched the helo name. Actually, there are a number of SMTP clients that will use the local system's hostname (either partial or FQDN) as the HELO string. Outlook Express, Opera, and KMail are examples. Eudora has an annoying habit of using the local hostname plus the domain name of the email address, which often results in a nonexistent FQDN. -- Kelson Vibber SpeedGate Communications
Re: Recognizing Sendmail's authentication -- patch included (WAS: How is LOCAL_AUTH_RCVD used?)
Daryl C. W. O'Shea wrote: John Rudd wrote: Daryl C. W. O'Shea wrote: John Rudd wrote: Though, CommuniGate Pro's authenticated received header looks like this: from [$ipaddr] (acccount $account HELO $helostring) by $host (CommuniGate Pro So, you could match that with: /^from \[\S+\] \(account [EMAIL PROTECTED] .*\) by \S+ \(CommuniGate Pro/ Cool, I don't think we currently support that. Daryl That works for CGP's SMTP-AUTH, but not for CGP's webmail (which are also, technically, authenticated users, just not SMTP-AUTH authenticated). The following regexp will catch both: /^from \[\S+\] \(account [EMAIL PROTECTED]( .*)?\) by \S+ \(CommuniGate Pro/ Could you provide me with some sample headers so that I can add these? I can't add them without regression tests. SMTP-AUTH: Received: from [128.114.2.223] (account [EMAIL PROTECTED] HELO [128.114.2.223]) by silver.ucsc.edu (CommuniGate Pro SMTP 4.3.7) with ESMTPSA id 88402416 for [EMAIL PROTECTED]; Mon, 04 Dec 2006 13:15:07 -0800 Webmail: Received: from [128.114.2.223] (account [EMAIL PROTECTED]) by tin.ucsc.edu (CommuniGate Pro WebUser 4.3.7) with HTTP id 109780632 for [EMAIL PROTECTED]; Tue, 05 Dec 2006 11:17:51 -0800 (CGP does this odd thing of putting the relay's IP addr out front, instead of the HELO string.. and then putting the Helo string, for SMTP, inside the ()'s ... and it doesn't appear to ever put the relay's RDNS)
Re: Recognizing Sendmail's authentication -- patch included (WAS: How is LOCAL_AUTH_RCVD used?)
John Rudd wrote: Daryl C. W. O'Shea wrote: John Rudd wrote: Though, CommuniGate Pro's authenticated received header looks like this: from [$ipaddr] (acccount $account HELO $helostring) by $host (CommuniGate Pro So, you could match that with: /^from \[\S+\] \(account [EMAIL PROTECTED] .*\) by \S+ \(CommuniGate Pro/ Cool, I don't think we currently support that. Daryl That works for CGP's SMTP-AUTH, but not for CGP's webmail (which are also, technically, authenticated users, just not SMTP-AUTH authenticated). The following regexp will catch both: /^from \[\S+\] \(account [EMAIL PROTECTED]( .*)?\) by \S+ \(CommuniGate Pro/ Could you provide me with some sample headers so that I can add these? I can't add them without regression tests. Thanks, Daryl
Re: Recognizing Sendmail's authentication -- patch included (WAS: How is LOCAL_AUTH_RCVD used?)
John Rudd wrote: Daryl C. W. O'Shea wrote: Could you provide me with some sample headers so that I can add these? I can't add them without regression tests. SMTP-AUTH: Received: from [128.114.2.223] (account [EMAIL PROTECTED] HELO [128.114.2.223]) by silver.ucsc.edu (CommuniGate Pro SMTP 4.3.7) with ESMTPSA id 88402416 for [EMAIL PROTECTED]; Mon, 04 Dec 2006 13:15:07 -0800 Great, already handled via the RFC 3848 with protocol type of ESMTPSA and I assume ESMTPA. Webmail: Received: from [128.114.2.223] (account [EMAIL PROTECTED]) by tin.ucsc.edu (CommuniGate Pro WebUser 4.3.7) with HTTP id 109780632 for [EMAIL PROTECTED]; Tue, 05 Dec 2006 11:17:51 -0800 Also handled via the HTTP with protocol type. Thanks! Daryl
Re: Recognizing Sendmail's authentication -- patch included (WAS: How is LOCAL_AUTH_RCVD used?)
Daryl C. W. O'Shea wrote: John Rudd wrote: Though, CommuniGate Pro's authenticated received header looks like this: from [$ipaddr] (acccount $account HELO $helostring) by $host (CommuniGate Pro So, you could match that with: /^from \[\S+\] \(account [EMAIL PROTECTED] .*\) by \S+ \(CommuniGate Pro/ Cool, I don't think we currently support that. Daryl That works for CGP's SMTP-AUTH, but not for CGP's webmail (which are also, technically, authenticated users, just not SMTP-AUTH authenticated). The following regexp will catch both: /^from \[\S+\] \(account [EMAIL PROTECTED]( .*)?\) by \S+ \(CommuniGate Pro/
Re: Recognizing Sendmail's authentication -- patch included (WAS: How is LOCAL_AUTH_RCVD used?)
Daryl C. W. O'Shea wrote:
> René Berber wrote:
[snip]
>> 1) LOCAL_AUTH_RCVD doesn't do anything useful, just to clarify what
>> happened to
>> the original subject.
>
> It's solely a workaround, suggested by Dana from UW's CIS dept before
> there was any support at all for detecting authenticated relays, for how
> you might workaround the problem. As I said yesterday, I updated the
> wiki page to hopefully make this clear. If it's still somehow not clear
> that it's only a workaround please let me know, or take a shot at making
> it clearer yourself.
OK, but it would be better if you showed the full workaround (i.e. add a line
with "score LOCAL_AUTH_RCVD -10.0").
>> 2) SA 3.1.7 (and 3.1.5) doesn't seem to recognize Sendmail's
>> authentication
>> under some circumstances. I assume that it does recognize it for other
>> messages, even if I have not seen evidence to that effect.
>>
>> If I change Received.pm, line 414, like this:
>>
>> # Sendmail, MDaemon, some webmail servers, and others
>> - elsif (/^from .*?(?:\]\)|\)\]) .*?\(.*?authenticated.*?\).*? by/) {
>> + elsif (/^from .*?(.*?authenticated.*?\).*? by/) {
---^
watch out for the typo, it should be \(
> Yeah, as you've found, the regex doesn't match when Sendmail adds a
> comment about a connection's funky DNS entries. Amazingly nobody has
> had the same problem and brought it to our attention in the more than
> two years since I wrote that code.
>
> It'll be fixed in the next version of SpamAssassin to be released.
>
> http://issues.apache.org/SpamAssassin/show_bug.cgi?id=5223
Thanks!
--
René Berber
Re: Recognizing Sendmail's authentication -- patch included (WAS: How is LOCAL_AUTH_RCVD used?)
On Dec 5, 2006, at 2:02 AM, David B Funk wrote: Jo you are mistaken. Sendmail adds the "(may be forged)" comment when the client's IP rDNS and DNS don't match, it has -nothing- to do with the HELO name. RTFC(...code) If the hello is numeric or non a domain name, the "may be forged" is *NOT* added to the Received line. It's only added when what Sendmail was told appears to be false. It still should not matter. So long as the client can authenticate to the server's statisfaction, SA should honor its decision regardless of how bogus the HELO or client's DNS entrys look. That's your argument. That may not have been the thought process of the person who wrote that rule, was all I was trying to say. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness
Re: Recognizing Sendmail's authentication -- patch included (WAS: How is LOCAL_AUTH_RCVD used?)
Jo Rhett wrote: Do you know why the SMTP authenticating server was forging the HELO name? Normal mail clients will give their IP address, right? And the "may be forged" only appears if they gave a full name and resolution succeeded *and* none of the addresses returned matched the helo name. On Dec 5, 2006, at 12:47 PM, Kelson wrote: Actually, there are a number of SMTP clients that will use the local system's hostname (either partial or FQDN) as the HELO string. Outlook Express, Opera, and KMail are examples. Eudora has an annoying habit of using the local hostname plus the domain name of the email address, which often results in a nonexistent FQDN. Heh, got me on assumptions. I use 7 different mail clients and have never seen this problem with my mail but you've just named 4 clients I don't use :-) FYI partial names are fine by my reading of the sendmail code. "forged" only appears when a FQDN is provided but isn't valid. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness
Re: Recognizing Sendmail's authentication -- patch included (WAS: How is LOCAL_AUTH_RCVD used?)
While you are fixing bugs related to authentication, any chance
you'll fix the SPF plugin to skip checks on authenticated delivery?
Or have an option to enable this behavior?
Or do you want a patch from me? It'll take me a lot longer than you,
since I'll spend hours just tracing down the data structures
On Dec 5, 2006, at 11:22 AM, Daryl C. W. O'Shea wrote:
René Berber wrote:
Daryl C. W. O'Shea wrote:
[snip]
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.
Let's start by saying two things:
1) LOCAL_AUTH_RCVD doesn't do anything useful, just to clarify
what happened to
the original subject.
It's solely a workaround, suggested by Dana from UW's CIS dept
before there was any support at all for detecting authenticated
relays, for how you might workaround the problem. As I said
yesterday, I updated the wiki page to hopefully make this clear.
If it's still somehow not clear that it's only a workaround please
let me know, or take a shot at making it clearer yourself.
2) SA 3.1.7 (and 3.1.5) doesn't seem to recognize Sendmail's
authentication
under some circumstances. I assume that it does recognize it for
other
messages, even if I have not seen evidence to that effect.
If I change Received.pm, line 414, like this:
# Sendmail, MDaemon, some webmail servers, and others
- elsif (/^from .*?(?:\]\)|\)\]) .*?\(.*?authenticated.*?\).*?
by/) {
+ elsif (/^from .*?(.*?authenticated.*?\).*? by/) {
Yeah, as you've found, the regex doesn't match when Sendmail adds a
comment about a connection's funky DNS entries. Amazingly nobody
has had the same problem and brought it to our attention in the
more than two years since I wrote that code.
It'll be fixed in the next version of SpamAssassin to be released.
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=5223
Daryl
--
Jo Rhett
Net Consonance : consonant endings by net philanthropy, open source
and other randomness
Re: Recognizing Sendmail's authentication -- patch included (WAS: How is LOCAL_AUTH_RCVD used?)
> SMTP-AUTH: > Received: from [128.114.2.223] (account [EMAIL PROTECTED] HELO > [128.114.2.223]) by silver.ucsc.edu (CommuniGate Pro SMTP 4.3.7) >with ESMTPSA id 88402416 for [EMAIL PROTECTED]; Mon, 04 Dec 2006 13:15:07 > -0800 > > Webmail: > Received: from [128.114.2.223] (account [EMAIL PROTECTED]) >by tin.ucsc.edu (CommuniGate Pro WebUser 4.3.7) >with HTTP id 109780632 for [EMAIL PROTECTED]; Tue, 05 Dec 2006 11:17:51 > -0800 Not sure if the following one is relevant, but it just fell into my hands: Received: from 10.235.209.117 (SquirrelMail authenticated user sername) by xxx.ijs.si with HTTP; Tue, 5 Dec 2006 15:31:13 +0100 (CET) Mark
Re: Recognizing Sendmail's authentication -- patch included (WAS: How is LOCAL_AUTH_RCVD used?)
Mark Martinec wrote: Not sure if the following one is relevant, but it just fell into my hands: Received: from 10.235.209.117 (SquirrelMail authenticated user sername) by xxx.ijs.si with HTTP; Tue, 5 Dec 2006 15:31:13 +0100 (CET) Thanks Mark. Anything with a with protocol type of HTTP is considered authenticated and in the case of SquirrelMail we ignore the relay altogether (a hold over from before we did any auth detection). Daryl
Re: Recognizing Sendmail's authentication -- patch included (WAS: How is LOCAL_AUTH_RCVD used?)
Jo Rhett wrote: While you are fixing bugs related to authentication, any chance you'll fix the SPF plugin to skip checks on authenticated delivery? Or have an option to enable this behavior? Or do you want a patch from me? It'll take me a lot longer than you, since I'll spend hours just tracing down the data structures I know for sure that if there are no external relays detected there will be no SPF checks. There might be checks done (read I'm almost certain there is) if all the relays are trusted, but one or more of them are external. Your other email about this didn't include the necessary debug info to confirm the bug as you reported it. If you'd like me to look at it, I'd need a full debug output, including the complete message headers, of a message that exhibits the bug. Daryl
Re: Recognizing Sendmail's authentication -- patch included (WAS: How is LOCAL_AUTH_RCVD used?)
Jo Rhett wrote: On Dec 5, 2006, at 2:02 AM, David B Funk wrote: It still should not matter. So long as the client can authenticate to the server's statisfaction, SA should honor its decision regardless of how bogus the HELO or client's DNS entrys look. That's your argument. That may not have been the thought process of the person who wrote that rule, was all I was trying to say. Just an oversight. I have no ham that is both authenticated and includes the "may be forged" comment so I missed considering it in the regex. Daryl
Re: Recognizing Sendmail's authentication -- patch included (WAS: How is LOCAL_AUTH_RCVD used?)
On Dec 5, 2006, at 4:17 PM, Daryl C. W. O'Shea wrote: Jo Rhett wrote: While you are fixing bugs related to authentication, any chance you'll fix the SPF plugin to skip checks on authenticated delivery? Or have an option to enable this behavior? Or do you want a patch from me? It'll take me a lot longer than you, since I'll spend hours just tracing down the data structures I know for sure that if there are no external relays detected there will be no SPF checks. There might be checks done (read I'm almost certain there is) if all the relays are trusted, but one or more of them are external. I can show you extensive logs of SPF checks against me, submitting authenticated mail for my own domain to my relayhost using SA :-) I guess my host is considered external, but it is also TRUSTED so in my opinion the logic should be fixed to handle this. Your other email about this didn't include the necessary debug info to confirm the bug as you reported it. If you'd like me to look at it, I'd need a full debug output, including the complete message headers, of a message that exhibits the bug. Here it is again, first the received headers then the entire, very verbose debug including SA startup From: [EMAIL PROTECTED] Subject:testing SPF relay Date: December 7, 2006 12:38:32 PM PST To: [EMAIL PROTECTED] Return-Path:<[EMAIL PROTECTED]> Received: from triceratops.lizardarts.com ([unix socket]) by triceratops.lizardarts.com (Cyrus v2.3.7) with LMTPA; Thu, 07 Dec 2006 12:38:40 -0800 Received: from [10.66.240.106] (public-wireless.sv.svcolo.com [64.13.135.30]) (authenticated bits=0) by triceratops.lizardarts.com (8.13.8/8.13.8) with ESMTP id kB7Kcc5v015458 for <[EMAIL PROTECTED]>; Thu, 7 Dec 2006 12:38:38 -0800 (PST) (envelope-from [EMAIL PROTECTED]) Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: <[EMAIL PROTECTED]> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed X-Mailer: Apple Mail (2.752.2) X-Spam-Status: No, score=-3.776 tagged_above=-999 required=4 tests= [ALL_TRUSTED=-1.44, AWL=4.164, LOCAL_AUTH_RCVD=-10, SPF_FAIL=3.5] X-Spam-Level: X-Spam-Score: -3.776 X-Virus-Scanned:amavisd-new at netconsonance.com [15504] dbg: logger: adding facilities: all [15504] dbg: logger: logging level is DBG [15504] dbg: generic: SpamAssassin version 3.1.7 [15504] dbg: config: score set 0 chosen. [15504] dbg: util: running in taint mode? yes [15504] dbg: util: taint mode: deleting unsafe environment variables, resetting PATH [15504] dbg: util: PATH included '/usr/local/sbin', keeping [15504] dbg: util: PATH included '/usr/local/bin', keeping [15504] dbg: util: PATH included '/usr/sbin', keeping [15504] dbg: util: PATH included '/sbin', keeping [15504] dbg: util: PATH included '/usr/bin', keeping [15504] dbg: util: PATH included '/bin', keeping [15504] dbg: util: final PATH set to: /usr/local/sbin:/usr/local/bin:/ usr/sbin:/sbin:/usr/bin:/bin [15504] dbg: message: MIME PARSER START [15504] dbg: message: main message type: text/plain [15504] dbg: message: parsing normal part [15504] dbg: message: added part, type: text/plain [15504] dbg: message: MIME PARSER END [15504] dbg: dns: is Net::DNS::Resolver available? yes [15504] dbg: dns: Net::DNS version: 0.58 [15504] dbg: ignore: test message to precompile patterns and load modules [15504] dbg: config: using "/usr/local/etc/mail/spamassassin" for site rules pre files [15504] dbg: config: read file /usr/local/etc/mail/spamassassin/init.pre [15504] dbg: config: read file /usr/local/etc/mail/spamassassin/v310.pre [15504] dbg: config: read file /usr/local/etc/mail/spamassassin/v312.pre [15504] dbg: config: using "/var/lib/spamassassin/3.001007" for sys rules pre files [15504] dbg: config: read file /var/lib/spamassassin/3.001007/ updates_spamassassin_org.pre [15504] dbg: config: using "/var/lib/spamassassin/3.001007" for default rules dir [15504] dbg: config: read file /var/lib/spamassassin/ 3.001007/70_sare_adult_cf_sare_sa-update_dostech_net.cf [15504] dbg: config: read file /var/lib/spamassassin/ 3.001007/70_sare_evilnum0_cf_sare_sa-update_dostech_net.cf [15504] dbg: config: read file /var/lib/spamassassin/ 3.001007/70_sare_evilnum1_cf_sare_sa-update_dostech_net.cf [15504] dbg: config: read file /var/lib/spamassassin/ 3.001007/70_sare_evilnum2_cf_sare_sa-update_dostech_net.cf [15504] dbg: config: read file /var/lib/spamassassin/ 3.001007/70_sare_genlsubj_cf_sare_sa-update_dostech_net.cf [15504] dbg: config: read file /var/lib/spamassassin/ 3.001007/70_sare_genlsubj_eng_cf_sare_sa-update_dostech_net.cf [15504] dbg: config: read file /var/lib/spamassassin/ 3.001007/70_sare_header_cf_sare_sa-update_dostech_net.cf [15504] dbg: config: read file /var/lib/spamassassin/
Re: Recognizing Sendmail's authentication -- patch included (WAS: How is LOCAL_AUTH_RCVD used?)
This is now bug 5235 http://issues.apache.org/SpamAssassin/show_bug.cgi?id=5235
