wayne wrote:
I think that *just* changing the version number and
abandoning the SPF1 records is a bad idea.
At least it's a consequent solution, and if SUBMITTER really
reintroduces bounces to innocent bystanders it's necessary.
Most existing v=spf1 records have one goal: Protect the 2821
MAIL FROM, stop useless bounces to forged MAIL FROM addresses.
That's the one and only purpose of SPF classic, existing exp=
explanations like <http://spf.pobox.com/why.html> are based on
this assumption.
I think we should use SPF1 records
For SPF/MAILFROM, and maybe for a compatible version of PRA,
if we add a rule that MAIL FROM != From: without Sender: is
implicitly handled like MAIL FROM == Sender (near step 4 in
draft-ietf-marid-core-02.txt 4.4).
If domain owners feel that they need different records
when used with the PRA algorithm, they can publish SPF2
records and use the scope variable to make the required
distinctions.
Okay, something like "v=spf2 a -all check=2822" could allow
incompatible header checks, and / or "check=2821" would be
the same as an existing v=spf1 sender policy.
In theory it's possible to add this modifier without changing
the version: A "v=spf1" without "check=2822" would stand for
SPF classic, and a "v=spf1" with "check=2822" would allow new
incompatible checks like SPF/FROM-HDR resp. core-02 Sender-Id.
Something like "forget SPF/MAILFROM, do only new stuff" isn't
possible with protocol-00.txt and v=spf1, implementations are
free to ignore unknown modifiers.
Bye, Frank