Mark Shewmaker wrote:
It would *would* be nice if I could publish different records
to be used for MAIL FROM tests and HELO tests.
Actually you can if you are the domain owner and postmaster@:
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.
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)
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.
I think (3) would be nice if possible.
What exactly do you want, can it be covered by an op=helo (and
that means ignored by old implementations) ?
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.
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".
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).
If something parses it then that's some simple script which
could handle other headers resp. better alternatives as well.
Hardwiring a specific format in a MUA would be very dubious.
Bye, Frank