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:
René Berber wrote:
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
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
René Berber wrote:
Hi,
I have a similar problem as the one recently reported by J. Rhett in thread
skipping SPF checks for authenticated users. I'm trying to use Botnet plugin
and make it not score for authenticated users; having the same for SPF and RBL
would be even better.
So the problem
On Dec 4, 2006, at 1:03 PM, Daryl C. W. O'Shea wrote:
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
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
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
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
Hi,
I have a similar problem as the one recently reported by J. Rhett in thread
skipping SPF checks for authenticated users. I'm trying to use Botnet plugin
and make it not score for authenticated users; having the same for SPF and RBL
would be even better.
So the problem is that SA doesn't
Rene, you can score the rule to be lower. For instance, a score of
-10 will probably do what you need.
It doesn't prevent the utilization, but does solve the problem of having
your local users get +1 points for authenticating.
The long-term problem needs a real fix.
René Berber wrote:
Hi,
Jo Rhett wrote:
Rene, you can score the rule to be lower. For instance, a score of
-10 will probably do what you need.
I know that, I saw your post and I have been changing scores to fine tune my
installation (for instance I give -2.5 points to any SPF validated server).
It doesn't prevent
36 matches
Mail list logo