Hmmm... Another potential SPF issue... I have a customer with AMEX, received an email from them, and the SPF checks conflict with each other:
helo=<mta301.email.americanexpress.com> Received: from mta301.email.americanexpress.com (mta301.email.americanexpress.com [206.132.204.250]) From: [EMAIL PROTECTED] And the scores: 3.14 SPF_HELO_SOFTFAIL -0.00 SPF_PASS Why did the helo softfail? I tested their SPF record, and the test turned out a pass: http://www.dnsstuff.com/tools/[EMAIL PROTECTED]&ip=206.132.204.250 Now I am really confused :) > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > Daryl C. W. O'Shea writes: >> Brian Taber wrote: >> > As for the scores, score of 0 for PASS makes perfect sense, but a FAIL >> > should receive at least the same score as a SOFTFAIL, because a FAIL >> means >> > the email is definately from a forged sender (on the other hand the >> FAIL >> > may be because the person who created the SPF records had no idea what >> > they were doing)... catch 22.... oh well.... >> >> When the 3.0 scoring mass-checks were done a lot of ham (more than the >> SPF_SOFTFAIL) hit SPF_FAIL, hence the low score. >> >> I expect the reason this happened was because of old ham in people's >> corpus that no longer matched various domains' SPF records due to >> changes in their networks (and of course the occasional screwup by the >> publishing domain). >> >> I'd expect that this week's 3.1 scoring mass-check will show that the >> score can be increased slightly, but probably not by a lot. > > yep. fingers crossed. (we should really attempt to only use SPF records > from --reuse mass-checks.) > > There is still the SPF-vs-forwarder issue that SES/SRS was created to > resolve, too. > > - --j. > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.5 (GNU/Linux) > Comment: Exmh CVS > > iD8DBQFCyyFoMJF5cimLx9ARAvlLAKCcCVJmRzmGwBfiyQ4EvlbLGT8YZgCfUvin > UJIBCdzNWGejmRFhnDX2078= > =anfE > -----END PGP SIGNATURE----- > >
