I replied elsewhere, but I was having some strange DNS problems today
that probably caused every other lookup to fail. I THINK that was
what was causing it. I'll watch for a while...
On Aug 15, 2005, at 8:12 PM, List Mail User wrote:
...
Not for me...
* -6.0 USER_IN_WHITELIST_TO User is listed in 'whitelist_to' * 2.4
SPF_HELO_SOFTFAIL SPF: HELO does not match SPF record (softfail)
* [SPF failed: ] * -1.3 AWL AWL: From: address is in the auto
white-list
That is from your message...
On Aug 15, 2005, at 6:17 PM, List Mail User wrote:
...
The first thing I've noticed after running 3.1pre1 for a few
days is
that I'm getting much less bayes auto learning of ham due to the
fact
that most of my messages from mailings lists fail SPF tests and get
penalized 2.4-2.6 points or so for it. They still aren't marked as
spam, but with higher scores than before.
Seems like we should have a way to disable SPF tests for mailing
lists since SPF is known not to work for them.
--
Steve Martin http://www.cheezmo.com/
Smart Calibration, LLC http://www.smartcalibration.com/
The Widescreen Movie Center http://www.widemovies.com/
Letterboxed Movie TV Schedule http://www.widemovies.com/lbx.html
It must be the mailing lists you subscribe to (or some exploder
or forwarder). I find most lists, like this one, pass SPF checks.
Paul Shupak
[EMAIL PROTECTED]
--
Steve Martin http://www.cheezmo.com/
Smart Calibration, LLC http://www.smartcalibration.com/
The Widescreen Movie Center http://www.widemovies.com/
Letterboxed Movie TV Schedule http://www.widemovies.com/lbx.html
I get SPF_PASS; Do you have any internal forwarding happening
that might be upseting the "trusted" path? Also, maybe an exploder
(for
multiple recipients at your site) or a forwarder (generally breaks
SPF,
one of the *real* problems with it). I do forward internally, but
check
SPF in the first machine in the chain, so all the lists I subscribe to
(quite a large number - hence "List Mail User"), give either SPF_PASS,
both SPF_PASS and SPF_HELO_PASS, I can't find any of dezens that give
a FAILURE. But I only run 3.1 for testing and am using 3.0.4 for the
production machines, so there might be a bug
Can you give an example of headers (recipient can be munged away)
and the SPF record (i.e. for this list I see:
% dig spamassassin.apache.org any @ns1.us.bitnames.com
...
spamassassin.apache.org. 1800 IN TXT "v=spf1 mx -all"
...
and
% dig spamassassin.apache.org mx @ns1.us.bitnames.com
...
spamassassin.apache.org. 1800 IN MX 10 asf.osuosl.org.
spamassassin.apache.org. 1800 IN MX 20 mail.apache.org.
...
and the mail is indeed delivered from hermes.apache.org
[209.237.227.199]
% host 209.237.227.199
199.227.237.209.in-addr.arpa domain name pointer hermes.apache.org.
% host mail.apache.org
mail.apache.org has address 209.237.227.199
So everything matches. Possibly I haven't played enough with
"real"
mail and 3.1 to see the problem - it appears that the "double-
lookup" is
required to get the answer correct (again a reason for a possible
code bug).
Simple matching of rDNS will give the wrong result and I haven't
looked at
the SPF code, ever. With the given SPF record the 'MX' RRs must be
fetched
and the mapped to IPs and the resilts checked (because of aliasing
- real in
this case and always possible - i.e. name -> IP is many to one, but
IP -> name
is only one to one).
Also, for the list I don't get any SPF_HELO_xxx, for some lists
I do.
Paul Shupak
[EMAIL PROTECTED]
--
Steve Martin http://www.cheezmo.com/
Smart Calibration, LLC http://www.smartcalibration.com/
The Widescreen Movie Center http://www.widemovies.com/
Letterboxed Movie TV Schedule http://www.widemovies.com/lbx.html