[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: changing the SPF record version number?
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