-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Frank Ellermann wrote:
You added the concept of the "validating implementation", i.e. report
errors within a policy as a PermError, with the intent of a 5xx where
appropriate,
Given numerous cases of a:1.2.3.4 or mx=an.example that was so convincing
and so obviously the best possible solution for all parties, senders and
receivers, that going back to a "do what you like" is no option.
Not being able to parse a policy record and not learning from the spec how
to relate the HELO and MAIL FROM results are two entirely different
things. The former situation cannot, ever, be resolved intelligently by
an implementor, but the latter can (and should).
The last Council meeting ignored a corresponding "For Council review -
FAIL PermError vs. NONE NXDOMAIN". Plus rationale in a separate article.
It seems we lost track of the many council review requests, which indeed
have reached a somewhat inflationary use. We will try better next time,
but in the meantime please try to stick to discussing things
systematically and objectively. If at all possible, we really should
decide things by argument, not by voting.
Not using RfC 2828 for the "authorize" question strikes me as odd, after
William agreed that it's a good idea.
Please give more context.
Again, we are constrained by what mengwong-spf-* and current
implementations do.
Is that why you added new stuff like the scope= ?
Adding "new stuff" is unproblematic if it doesn't conflict with legacy
behavior.
There are political reasons why not mentioning "mfrom" or "scope" in the
v=spf1 spec. is a plan, [...]
SPFv1 _does_ support multiple scopes, just not in a way that's as
controllable as "v=spf2.0/...". Therefore I think it is useful to support
the "scope" key in "Received-SPF:" headers. Also, I doubt this will cause
any political harm.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
iD8DBQFCl4w+wL7PKlBZWjsRAnnrAJ0bsgzQgaAypPbfHKSRo+kkobgviACeLw7v
tLzSbVku2NMEZo7GbqK1KYE=
=eYA3
-----END PGP SIGNATURE-----