Frank Ellermann writes:
The result would contain many technical points of the two
appeals, explaining this for average admins and implementors,
not SPF- / PRA-geeks. The MAAWG has a table claiming that the
(non-existing) spf2.0/mfrom would be without spf2.0/helo (also
not existing)
What do you mean when you describe spf2.0/mfrom as "non-existing"?
It's part of draft-lyon-senderid-core-01.txt, and it appears in some
domains' spf2.0 records.
We're free to _define_ that spf2.0/mfrom _is_ compatible with
v=spf1 incl. HELO, because it was always MAY (and now SHOULD).
We're in the position to say that spf2.0/mfrom is pointless in
the situation as it is, no matter that I liked the concept of
positional modifiers, or that others might prefer that HELO is
independent of MAIL FROM. Fact is, it's not, MARID failed to
deliver, and for HELO it's no real problem.
This sounds to me almost like your goal is to pick a deliberate fight.
What would be your purpose in adding new conflict between SPF and
SenderID?
I consider that separating scopes is a big advantage of the SenderID
approach. Imagining that mfrom and helo scopes can be described by a
single SPF policy is ludicrous IMO.
SenderID's spf2.0 records allow domains to specify what scope(s) their
SPF records cover. If you don't want your MFROM scope used for PRA, you
can say so. Is there anybody who thinks this is not a big advantage?
--
Dick St.Peters, stpeters(_at_)NetHeaven(_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