SPF_PASS with S/O ratio for the domain of less than 0.5:
S/O count domain
-- -
0.1283 491 lists.sourceforge.net
0.0197 254 incubator.apache.org
0.0148 203 securityfocus.com
0.0050 199 nl.linux.org
0. 194
SPF_PASS with S/O ratio for the domain of more than 0.5:
S/O count domain
-- -
0.6381 16193 bounce2.pobox.com
0.9971 347 excite.com
1. 344 aol.com
1. 233 earthlink.net
1. 167 caleandb.us
1. 153
First, large ISPs seem to be the origination point for a *lot* of spam.
Second, here's my list of the domains we could potentially whitelist for
SPF_PASS results (high count, good ratio, not biased towards open source
folks).
0. 90 health.webmd.com
0. 27 foolsubs.com
0.
http://bugzilla.spamassassin.org/show_bug.cgi?id=4072
Summary: SPF_PASS false match
Product: Spamassassin
Version: SVN Trunk (Latest Devel Version)
Platform: Other
OS/Version: other
Status: NEW
Severity: normal
http://bugzilla.spamassassin.org/show_bug.cgi?id=4072
--- Additional Comments From [EMAIL PROTECTED] 2005-01-09 18:50 ---
Created an attachment (id=2595)
-- (http://bugzilla.spamassassin.org/attachment.cgi?id=2595action=view)
spam message
--- You are receiving this mail
Do we have a mailing list yet ;) or are we using large CC's for the
near future. I just noticed
http://wiki.apache.org/spamassassin/BlogSpamAssassin/
and thought a public mailing list might save Henry some time.
=
Harry
Join team plico.
http://www.hjackson.org/cgi-bin/folding/index.pl
http://bugzilla.spamassassin.org/show_bug.cgi?id=4024
--- Additional Comments From [EMAIL PROTECTED] 2005-01-09 19:01 ---
What I'm suggesting has nothing to do with SPF checks. It only has to do with
determining when we can trust the X-Envelope-From, Envelope-Sender and/or Return
http://bugzilla.spamassassin.org/show_bug.cgi?id=4072
--- Additional Comments From [EMAIL PROTECTED] 2005-01-09 19:10 ---
Subject: Re: SPF_PASS false match
It should pass, AOL's spf records (v1 and 2) both end in ?all
Well, at least it shouldn't fail. I can't remember how ?all is
http://bugzilla.spamassassin.org/show_bug.cgi?id=4072
--- Additional Comments From [EMAIL PROTECTED] 2005-01-09 19:16 ---
Subject: Re: SPF_PASS false match
Right, doh! Weird.
--- You are receiving this mail because: ---
You are the assignee for the bug, or are
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Daniel Quinlan writes:
Rules with the largest RANK drops from 3.0 to now. The body and
Subject: ones probably need the most work. The rest are probably lost
causes.
I suggest we drop them, if their RANK is sufficiently low and nobody steps
up
http://bugzilla.spamassassin.org/show_bug.cgi?id=4072
--- Additional Comments From [EMAIL PROTECTED] 2005-01-09 20:20 ---
Subject: Re: SPF_PASS false match
It's not the SPF plugin, it's Mail::SPF::Query returning:
passPlease see
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Daniel Quinlan writes:
First, large ISPs seem to be the origination point for a *lot* of spam.
Large ISPs' outbound relays, or direct from their dynamic pools?
e.g. blueyonder.co.uk list their dyn pools in their SPF record,
which is unfortunate but
Large ISPs' outbound relays, or direct from their dynamic pools?
e.g. blueyonder.co.uk list their dyn pools in their SPF record,
which is unfortunate but legal.
I suspect some of that, plus a lot of whatever bug is causing that AOL
SPF_PASS false match I reported. That was the first
http://bugzilla.spamassassin.org/show_bug.cgi?id=3998
--- Additional Comments From [EMAIL PROTECTED] 2005-01-09 21:30 ---
H... okay, then, I revoke my -1. It might be clearer and cleaner to have
a single entry point (eval test) for all of the Habeas rules.
Can you please
http://bugzilla.spamassassin.org/show_bug.cgi?id=3998
--- Additional Comments From [EMAIL PROTECTED] 2005-01-09 21:32 ---
Carl,
Can you submit an individual CLA so we can accept this patch? Note: we have
received the corporate CLA for Habeas, so we just need CLAs for any
http://bugzilla.spamassassin.org/show_bug.cgi?id=4072
--- Additional Comments From [EMAIL PROTECTED] 2005-01-09 21:42 ---
yeah. basically, it looks like we're passing trusted = 1 to
Mail::SPF::Query, and according to the perldoc:
The default mechanism for trusted=1 is
http://bugzilla.spamassassin.org/show_bug.cgi?id=4052
[EMAIL PROTECTED] changed:
What|Removed |Added
CC|[EMAIL PROTECTED]|
--- Additional Comments From
http://bugzilla.spamassassin.org/show_bug.cgi?id=4052
--- Additional Comments From [EMAIL PROTECTED] 2005-01-09 23:39 ---
Would it be possible for you to sign and fax an Apache CLA so that we can
incorporate these (or at least test them)?
We have faxed a signed CCLA (Duan Haixin
http://bugzilla.spamassassin.org/show_bug.cgi?id=4052
--- Additional Comments From [EMAIL PROTECTED] 2005-01-10 00:47 ---
Subject: Re: SpamAssassin rules file: Chinese subject and body tests
We have faxed a signed CCLA (Duan Haixin signed) to the ASF. Please
notify me when you
http://bugzilla.spamassassin.org/show_bug.cgi?id=3968
--- Additional Comments From [EMAIL PROTECTED] 2005-01-10 00:59 ---
Just spent a couple of hours trying to understand why SA 3.0.0 was giving -2.8
to some spam from a 72/8 network (not being overly familiar with the inner
http://bugzilla.spamassassin.org/show_bug.cgi?id=3968
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Harry,
I wanted to say thank you for starting this and a thank you to everyone
who's interested. I'm just now catching up on all of my mailing list
email back from around Christmas and Matt Mullenweg had forwarded the
original announcement
http://bugzilla.spamassassin.org/show_bug.cgi?id=3968
[EMAIL PROTECTED] changed:
What|Removed |Added
AssignedTo|[EMAIL PROTECTED] |[EMAIL PROTECTED]
--- Jason Hoffman [EMAIL PROTECTED] wrote:
Hi Harry,
I wanted to say thank you for starting this and a thank you to
everyone who's interested.
I believe that thanks belongs to Henry.
Then before the holidays, I set up a server with a Trac installation,
Subversion repositories,
http://bugzilla.spamassassin.org/show_bug.cgi?id=4055
--- Additional Comments From [EMAIL PROTECTED] 2005-01-10 03:42 ---
SpamAssassin trusts the first public IP as it assumes that it is your border
gateway.
Would it be possible then to get the server IP address not by resolving
I would like to suggest that having a Target Milestone of Future for a
bug is harmful. It was probably necessary when you were trying to get
3.0.0 out and you were not sure what the next verson number would be,
but now it seems to be a way for a bug to fall into a black hole. It
seems that if a
On Mon, Jan 10, 2005 at 02:25:43AM -0800, Harry wrote:
I am not sure what Henry's plans are. I believe we are awaiting Apache
approval and then the project is on the move.
I think that it is very important to NOT wait for approval to being
the process of getting something working. In fact,
Michael Parker [EMAIL PROTECTED] writes:
I think that it is very important to NOT wait for approval to being
the process of getting something working. In fact, I'm sure that any
sort of approval will come much faster when there is a defined set
of goals and people already working towards
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Thomas Schulz writes:
I would like to suggest that having a Target Milestone of Future for a
bug is harmful. It was probably necessary when you were trying to get
3.0.0 out and you were not sure what the next verson number would be,
but now it
http://bugzilla.spamassassin.org/show_bug.cgi?id=4072
--- Additional Comments From [EMAIL PROTECTED] 2005-01-10 10:43 ---
trusted=1 was recommended usage, at one stage. I suggest we drop it, since
that'll also save a DNS lookup.
--- You are receiving this mail because:
http://bugzilla.spamassassin.org/show_bug.cgi?id=4055
--- Additional Comments From [EMAIL PROTECTED] 2005-01-10 10:45 ---
'Would it be possible then to get the server IP address not by resolving it's
name but by enumerating it's interfaces? I don't know if it is possible to
implement
http://bugzilla.spamassassin.org/show_bug.cgi?id=4024
--- Additional Comments From [EMAIL PROTECTED] 2005-01-10 10:48 ---
daryl -- I'm not sure your position is correct.
it's entirely plausible that a *trusted* relay could forward the mail with a new
envelope-sender address. my
http://bugzilla.spamassassin.org/show_bug.cgi?id=4068
--- Additional Comments From [EMAIL PROTECTED] 2005-01-10 11:36 ---
If this is really an issue (all places where I used SA till now converted the
CRLF to Unix LF first), we could look at the newline of the first header (most
Justin Mason said:
It's a manageability thing.
Another way to look at is that the only person you can be certain has an
interest in a new bug report is the one who submitted it. If the target
milestone is still Future and you feel strongly about it, then it is up
to you to evangelize the bug
http://bugzilla.spamassassin.org/show_bug.cgi?id=4068
--- Additional Comments From [EMAIL PROTECTED] 2005-01-10 12:00 ---
as Tony said -- it's not simply a matter of RFC-2822 compliance, as a lot of
UNIX mail software will barf on input messages that contain CR-LFs instead of
just
http://bugzilla.spamassassin.org/show_bug.cgi?id=3968
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
http://bugzilla.spamassassin.org/show_bug.cgi?id=4072
[EMAIL PROTECTED] changed:
What|Removed |Added
CC||dev@spamassassin.apache.org
http://bugzilla.spamassassin.org/show_bug.cgi?id=4072
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
http://bugzilla.spamassassin.org/show_bug.cgi?id=4072
--- Additional Comments From [EMAIL PROTECTED] 2005-01-10 13:40 ---
Subject: Re: SPF_PASS false match
On Mon, Jan 10, 2005 at 01:27:59PM -0800, [EMAIL PROTECTED] wrote:
done, checked into trunk
Do we want to fix this for
http://bugzilla.spamassassin.org/show_bug.cgi?id=4068
--- Additional Comments From [EMAIL PROTECTED] 2005-01-10 13:43 ---
SA should just use whatever the input used.
No way this should be an option. -1 to a new option.
--- You are receiving this mail because: ---
You
http://bugzilla.spamassassin.org/show_bug.cgi?id=4024
--- Additional Comments From [EMAIL PROTECTED] 2005-01-10 13:53 ---
Subject: Re: SPF and X-Envelope-From and sendmail
I would say we should use the first envelope-sender header encountered
above the last trusted received line.
So something automatic like the following pseudo-code in the input routine?
if (!$self-crlf) {
$line =~ /(\012\015|\015|\012)$/
$self-crlf = $1
}
Yeah, but I'd only use the first line of the input, or maybe the last
line in the headers, for setting the parameter.
--
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Daniel Quinlan writes:
Do we want to fix this for 3.0.3, or just leaving it for 3.1?
I'm okay with backporting, but I think we're nearing the point at which
we buckle down on 3.1 and focus on it. The tree is remarkably stable
right now and
http://bugzilla.spamassassin.org/show_bug.cgi?id=4072
--- Additional Comments From [EMAIL PROTECTED] 2005-01-10 14:21 ---
Subject: Re: SPF_PASS false match
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Daniel Quinlan writes:
Do we want to fix this for 3.0.3, or just leaving it
http://bugzilla.spamassassin.org/show_bug.cgi?id=4068
--- Additional Comments From [EMAIL PROTECTED] 2005-01-10 14:21 ---
Subject: Re: SpamAssassin doesn't follow RFCs 822, 2045, and 2046
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Daniel Quinlan writes:
So something
http://bugzilla.spamassassin.org/show_bug.cgi?id=4068
--- Additional Comments From [EMAIL PROTECTED] 2005-01-10 15:05 ---
Subject: Re: SpamAssassin doesn't follow RFCs 822, 2045, and 2046
The reason I jumped in on this one is because Exim has gone through a lot
of problems in this
http://bugzilla.spamassassin.org/show_bug.cgi?id=3998
--- Additional Comments From [EMAIL PROTECTED] 2005-01-10 15:51 ---
H... okay, then, I revoke my -1. It might be clearer and cleaner to have
a single entry point (eval test) for all of the Habeas rules.
Agreed, but I coded
47 matches
Mail list logo
