This is now bug 5235
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=5235
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
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.*?\).*?
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
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
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
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
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)
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
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
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.
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+\]
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]
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
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+
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,
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
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
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
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])
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
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
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
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é
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
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,
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
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
28 matches
Mail list logo
