[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