On Sat, 4 Dec 2004, Frank Ellermann wrote:
Use MAIL FROM:<user(_at_)domain>, and HELO mail2.domain or another
subdomain with its own sender policy resp. a dummy "v=spf1" to
bypass the "zone cut" default.
Well, perhaps you can lead by example and stop using "xyzzy" for HELO name
(its not FQDN)....
1. Ignore the problem completely for now: (fastest option)
Before you do this let's first _identify_ the problem, IMHO it
doesn't exist.
2. Completely handle the problem right now: (slowest option)
That's impossible, v=spf1 exists, you can only make compatible
changes, where new policies work with old implementations, and
old policies work with new implementations, without destroying
a single mail _by design_ (not counting erroneous policies and
implementation bugs)
Yes and that calls for SCOPE syntax that is compatible with SPF1
Make more major edits to the spf1 spec to incorporate
scoping, including a specific helo scope.
Omigod, no, positional modifiers are much better and already a
part of spf2.0/pra and spf2.0/mfrom as far as these beasts
exist at all. Not in v=spf1.
But I don't think positional modifiers would break spf1.
Allow for the "scope/scopename/version=Result" syntax in
Received-SPF
Doing wild and wonderful things with Received-SPF shouldn't be
a big issue, or at least I don't know any MUA or tool trying to
evaluate this header automatically.
Same as it would not be an issue if we grandfathered Received-SPF and
recommended use of Authentication-Results for future. As I recommend
we do it as MAY for Received-SPF and SHOULD for Authentication-Results
in the draft text (thus keeping current all v1 implementations still
fully compatible with standard even if they do just Received-SPF or
just Authentication-Results or both).
perhaps the scope/... keyword could be reserved
For whom and why ? v=spf2 is free to be as incompatible with
v=spf1 and spf2.0 as it wishes, it will have its own chapter
about "backwards compatibility".
Currently SPF2.0 does not exist at all (well, its marid-protocol draft,
but that can be considered to be abandoned at this point) and the drafts
that MS is pushing through are basicly saying that SPF2.0 has exactly the
same syntax as SPF1 (except version number is different).
it would be nice if MUAs written now could parse scopes
written two years from now.
IMHO something based on draft-kucherawy should be used in a
future "spf2", the Received-SPF header is a hack for v=spf1,
only RECOMMENDED (SHOULD) in schlitt-01, and not mentioned in
lentczner-00 (= rough consensus at that time here to drop it).
I would argue that it needs to be changed to "MAY" in sclitt-01
and preferably moved to its own draft text.
And I personally have not seen change of consensus on the list to
indicate that Received-SPF should be mentioned in spf draft. What
happened is that Wayne documented how his library works and that
happens to be adding Received-SPF (that does not mean there is a
consensus from SPF Communithy that it should be used for the future
or be included and be documented in main spf draft)
Elan Networks
william(_at_)elan(_dot_)net