spf-discuss
[Top] [All Lists]

Re: IESG evaluation of SPF

2005-04-06 18:47:22
Mark wrote:

I might be persuaded to have the sentence say:
"Checking other identities against SPF records is
 undocumented."

Maybe you might be also persuaded, that "undocumented" is the
same bullshit as "undefined".  For spf2.0/pra it's perfectly
okay to check the PRA, and this is of course "documented" in
draft-lyon-senderid-core-00, which is based on v=spf1.

The three things that simply *cannot* generally work are:

1 - check PRA       against v=spf1     or spf2.0/mfrom policies
2 - check MAIL FROM against spf2.0/pra policies
3 - check HELO      against spf2.0/pra or spf2.0/mfrom policies

"undocumented", AFAICT, has a subtle connotation, within the
technical world, which rings close to: "You could probably do
it, but the procedure is not recommended; so, go ahead, but
at your own risk."

The technical connotation of "undocumented" in conjunction with
draft-lyon-senderid-core-00 "3.4 Backward Compatibility" would
be "untrue".  Exactly this abuse *is* a _documented_ SHOULD in
this memo, and it's the duty of the SPF Council to prevent the
foreseeable damage by a clear statement, no vague "undefined"
or wrong "undocumented".

OTOH it's not the job of a v=spf1 draft to say what PRA does
with spf2.0/pra policies, that's why I proposed to use "v=spf1"
and "MUST NOT" instead of "NOT RECOMMENDED":

| "Other identities MUST NOT be checked against v=spf1 records,
|  this can have misleading or unintended results."

For spf2.0 it's clear that PRA cannot be used with spf2.0/mfrom
and MAIL FROM cannot be used with spf2.0/pra, unless it's a
hybrid sender policy (spf2.0/mfrom,pra or spf2.0/pra,mfrom).

This problem only affects misguided attempts to abuse v=spf1,
it's no general SPF issue.
                          Bye, Frank