This is a follow up:
Never mind that the standard specification is not being followed by this
perl script.
Here is what it basically assuming:
Check SPF(2821.MailFrom)
Check SPF(2821.Helo)
--- none SPF condition ---
if HELO domain matches IP then SPF=PASS
This is wrong from a SPF and LMAP specification standpoint. For this to be
accepted, then we are changing of SPF to one that closely follows the
CSV/CSA design. You remove all incentive for systems to use SPF including
the bad actors because you know have a LOOPHOLE into the SPF spec - simply
make sure the HELO domain is valid with the IP address.
What makes this really bad is that the notification (Received-SPF) is now
used to indicate a PASS result for a non-SPF logic.
So you have the following issues:
1) Promotion of a non-standard feature,
2) Breaks standard SFP implementations,
3) Provides false illusion to users,
4) Reduce incentive to use SPF because you don't need to,
5) Promote competitive specs like CSV/CSA
All because the SPF result was changed to PASS using a non-SPF technology or
non-SPF policy.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
----- Original Message -----
From: "Stuart D. Gathman" <stuart(_at_)bmsi(_dot_)com>
Newsgroups: spf.-.sender.policy.framework.discussion
To: <spf-discuss(_at_)v2(_dot_)listbox(_dot_)com>
Sent: Friday, November 18, 2005 2:02 PM
Subject: Re: [spf-discuss] Re: Is best guess moronic?
On Fri, 18 Nov 2005, Hector Santos wrote:
The issue is that this non-standard feature CHANGES the meaning of a
standard SPF specification. It should not CHANGE the meaning of PASS.
A
SPF NONE is a SPF NONE, not a SPF PASS.
Is this a difficult concept to grasp?
Your issue is only relevant when the header could be seen by outside
software. What cockamany headers I choose to decorate my own incoming
email with for my own purposes has nothing to do with any standard.
(Unless I stupidly install something like SpamAssasin and expect it
to work correctly with my custom Received-SPF header.)
Your issue is highly relevant for a mail gateway, that adds Received-SPF
headers that are used by mail software behind the gateway. Mail software
behind the gateway has no other way of getting the real SPF result.
(Using the Received header is unreliable.) You are correct that
such a gateway, if it enables guessing (which is essential to the
effective
use of SPF in my operation), should put the guessed result in another
header
and preserve the original SPF result of None. I am sorry if my
software set a bad example, and will change pymilter to add an
X-Guessed-SPF
header instead of modifying the Received-SPF header.
I think we all agree that gmail.com should not be guessing, or should
put the guessed result in its own header. This is not because gmail.com
is stupid. They were only following what appeared to be best practice.
Those of us doing the best guess thing were not thinking about our little
hack setting a bad example for a big ISP.
--
Stuart D. Gathman <stuart(_at_)bmsi(_dot_)com>
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703
591-6154
"Confutatis maledictis, flamis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.
-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com