Some things i noticed in the May SPF draft, for the editors consideration:
Suspected Error here:
When the <sending-host> is localhost, Designated Sender mechanisms
are not meaningful. Therefore, an SPF client immediately returns
"pass" without evaluating mechanisms.
This is wrong. It should result in an "unknown". Some info:
Some spamware recently started sending using HELO localhost. My
provider started blacklisting
HELO localhost. Several users started complaining because their MUAs
also sent HELO localhost.
I'll find a link to details upon request.
Suggested alternate text;
When the <sending-host> is alleged to be localhost or is the actual
local host, Designated Sender mechanisms are not meaningful.
Therefore, an SPF client immediately returns "unknown" and "pass",
respectively without evaluating mechanisms.
Given the changes of Unified SPF, the following changes are possible:
Re. 9.3 Phased Rollout
Unlike with SPF1, awareness among the domain's userbase is not necessary.
Only awareness among the domain's system administrators is necessary.
When a sufficient majority of its systems are SPF-conformant, a
domain SHOULD change its default to "-all".
Re. 9.4 Verbatim Forwarding
Unlike with SPF1, verbatim email forwarding suffers not.
Anyone think this is a good idea to add?:
xx. Record size.
Domains publishing SPF records should endeavour to make them simple and
compact.
They SHOULD require a small number of DNS UDP packets, each less than
512 bytes.
It is likely that sites will define simple and compact differently.
Re. 8.7 Rejection of non-SPF conformant email
<Tweak first paragraph to read:>
Mail from a domain SHOULD NOT be automatically rejected or discarded
just because the domain doesn't publish SPF records.
instead of
Mail from a domain SHOULD NOT be automatically treated as suspect
just because the domain doesn't publish SPF records.
Apologies if it's been discussed before, but why is this process
optional? Should it be mandatory? :
If a domain has no SPF record, clients MAY substitute SPF data from
a parent domain ONLY IF the appropriate parent domain's SPF record
sets "match_subdomains=yes". For example, if no SPF record is
found for "workstation.example.com", clients MAY proceed to
automatically query "example.com". The appropriate parent domain
to fallback on MUST be determined according to the DNS zone cut.
Often, I think when a MAY can be changed to a SHOULD or MUST NOT, or a
SHOULD can be changed to a MUST, it's a good idea.
It improves stability and interoperability.