----- Original Message -----
From: "David Mazieres (no direct replies)"
<dm-list-spf(_at_)scs(_dot_)stanford(_dot_)edu>
It is a clear cut voilation if SPF(MFROM) returns anything but a
FAIL or PASS because the client is stating it is inside the
secured autorized sending network.
Not necessarily. Suppose the domain name is the name of a laptop
computer that sends mail from various IP addresses in addition to it's
primary (main) address. The laptop's owner might just publish a
record saying:
v=spf1 ?all
Such a setup is not even as unreasonable as it sounds...
If I understand you, this implies an authenticated transaction requirement
in which case, atleast for our security implementation, SPF does not apply.
More below.
That said, I wouldn't be surprised to hear that a lot of spammers just
issue the same HELO name as the mail-from domain. Thus, I can
understand why this rule might catch a lot of spam.
Its done in a vain attempt to make it look like its come from inside the
same network.
Back in 2004, I did an extensive analysis of the LMAP states to develop a
SPF model that reflects when SPF is necessary (to reduce overhead).
See:
http://www.winserver.com/public/antispam/lmap/draft-lmapanalysis1.htm
For the most part, I was one of the hawks for not ignore the helo domain as
was done during the initial SPF draft specifications. Our implementation
uses most of the logic development from the LMAP analysis.
The specs were updated to better support the HELO domain considerations, but
we have not updated it to reflect the actual SPEC changes.
What this means is that in table 1.0 the group D10, D11, and D12 or in TABLE
2.0 groups DL10, DL11 and DL12 presents the remaining states where SPF is
considered in our implementation. Although the analysis concludes the
group CL7, CL8, and CL9 are also possible SPF consideration, what we do
locally is a NON-SPF LOCAL DOMAIN::IP association check to satisfy this
group.
So we are left with 3 conditions (DL10 to DL12) where you can apply SPF.
These 3 states can now be analyze with the 7 possible SPF results and the
logical combinations possible:
For SPF(MFROM):
Pass
Fail
SoftFail
Neutral
TempError
PermError
None
For SPF(HELO):
Pass
Fail
TempError
PermError
None
As you can imagine the combinations is large and staggering.
However, as done in the LMAP analysis, some dissemination can be done.
Example:
HELO.SPF.FAIL --> SPF.FINAL.RESULT := FAIL
In this theoretical case, it doesn't matter what MFROM.SPF.RESULT says.
The rule I am stating in the original message would be one of them:
IF HELO.REMOTE = MFROM.REMOTE and
MFROM.SPF.RESULT.NEUTRAL THEN
FINAL.RESULT := SPF FAIL
Remember, these is for REMOTE domains, domains you don't have control over
or have knowledge of. So in this case, a LAPTOP consideration would not
apply because in my technical opinion, that would be an authentication
requirement.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.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