Alessandro Vesely wrote:
AFAIK, SPF specs still mandate to add a TXT or SPF record for each
subdomain. IME, that is one of the most frequent omissions in SPF
configurations. The current spec requires an SPF record for each
name that has either an MX or an A record. Except for tiny domains,
that requires a script, which is probably why many admins skip it.
Nobody is forced to publish a sender policy. When folks do it
they will hopefully cover their HELOs and their mail addresses.
They can cover other A or AAAA domains like www.example, but it
is not strictly necessary when www.example has no MX and no SMTP.
"v=spf1 -all" can be good, it allows to reject forged mail from
any(_at_)www(_dot_)example(_dot_) The owners could also decide that misdirected
bounces to any(_at_)www(_dot_)example are no problem from their POV without
MX for or SMTP at www.example.
IMHO, a default more appropriate than "?all" might be preferrable.
Changing the default for v=spf1 would break an unknown number of
existing policies violating the SHOULD in RFC 4408 chapter 4.7.
'More appropriate than "?all"', see ? You dare not say "-all",
it could cause havoc for the idio^Wfolks not reading chapter 4.7.
an additional "default" modifier, appended to a domain's SPF
record, could state that the last mechanism is to be assumed
as the default for subdomains that actually lack any TXT or SPF
record.
Won't fly for various reasons. On the harmless end, in 2003 SPF
already had a "default=", deprecated in 2004, later removed:
<http://tools.ietf.org/html/draft-mengwong-spf-01#section-5>
Then what you want is to cover subdomains. That needs the old
zone cut idea, after all we can't have say verisign define some
sitefind^Wdefault for *.net and *.com. Namedroppers tortured
Wayne to give up on zone cuts, that's why you don't find it in
RFC 4408. Council resolution, flames with Paul Vixie, obscure
op=nosub proposals for a tree walk alternative as in CSV, etc.
Finally the zone cut idea was pulled, and declared to be a very
dead horse in a very big rathole. If you only want wildcards
in parallel to an existing MX wildcard, sure, that's possible.
[For SPF, for DKIM signing practises it's not because they put
their records at an _adsp._dkim.example subdomain below the
real domain.]
For v=spf1 it's also not really necessary, because SPF is not
about anti-phishing as primary goal, it is primarily about good
vs. misdirected bounces, and for that issue it is not necessary
to cover all A / AAAA without SMTP. Admittedly PRA could need
it, but PRA is another long story... ;-)
is there a draft and/or a schedule for next SPF spec update?
No. A possible way forward could go like this: We somehow
figure out what to do with the last pending erratum, based on
that the test suite can be completed. Or vice versa. As soon
as the test suite is ready anybody who feels like it can post
a draft with some "lessons learned" from an implementation POV.
And/or, when the IESG and I'm ready with the news-nntp-uri I-D
I intend to update the spf-eai draft, adding an I18N discussion
for Received-SPF and Murray's Authentication-Results.
After that I promised to do something for the IDNA-alternatives
I-D, and if that doesn't result into other adventures I want to
rewrite the spf-options I-D almost from scratch, deprecating
the spf2.0/* zoo keeping only spf2.0/pra. I already wanted to
do that in 2007, but didn't get a grip on it, now I *think* it
is clear, this draft has to be a BCP creating a IANA registry
of SPF tags, modifiers, and options, for the shared use of the
SPF RR. Allowing to add v=spf3 and/or DKIM ADSP magic later.
Frank
-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Modify Your Subscription: http://www.listbox.com/member/
Archives: http://www.listbox.com/member/archive/735/=now
RSS Feed: http://www.listbox.com/member/archive/rss/735/
Powered by Listbox: http://www.listbox.com