You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by René Berber <r....@computer.org> on 2006/12/05 10:15:09 UTC
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 <rb...@cactus-soft.dyndns.org>; 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?)
Posted by Jo Rhett <jr...@netconsonance.com>.
> 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?)
Posted by Kelson <ke...@speed.net>.
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 <www.speed.net>
Re: Recognizing Sendmail's authentication -- patch included (WAS:
How is LOCAL_AUTH_RCVD used?)
Posted by René Berber <r....@computer.org>.
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 <rb...@cactus-soft.dyndns.org>; 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?)
Posted by "Daryl C. W. O'Shea" <sp...@dostech.ca>.
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?)
Posted by Jo Rhett <jr...@netconsonance.com>.
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?)
Posted by "Daryl C. W. O'Shea" <sp...@dostech.ca>.
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?)
Posted by David B Funk <db...@engineering.uiowa.edu>.
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 <rb...@cactus-soft.dyndns.org>; 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
<dbfunk (at) engineering.uiowa.edu> College of Engineering
319/335-5751 FAX: 319/384-0549 1256 Seamans Center
Sys_admin/Postmaster/cell_admin Iowa City, IA 52242-1527
#include <std_disclaimer.h>
Better is not better, 'standard' is better. B{
Re: Recognizing Sendmail's authentication -- patch included (WAS:
How is LOCAL_AUTH_RCVD used?)
Posted by Jo Rhett <jr...@netconsonance.com>.
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 <rb...@cactus-soft.dyndns.org>; 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