David MacQuigg wrote:
SPF has left itself open to this criticism by not having a
clear policy on forwarding.
This "policy" is clear: Don't forward to 3rd parties with the
old MAIL FROM without prior arrangement.
Forwarders will ask 1) How do I know which name to
authenticate? and 2) How do I pass the result downstream?
Strange. What they should ask is 1 - "Why am I responsible for
my own actions ?", 2 - "What is the idea of SMTP error code 551
user ot local ?", 3 - "Why is there no problem with almost all
mailing lists and SPF ?".
There needs to be a simple, widely accepted answer to these
questions or SPF will fail.
The most simple answer is to shut down the forwarding service.
Some are parasites, they don't want the administrative burden
of a proper mail service, they think that some aliases and a
spool directory for their outbound mail is good enough, and the
rest is the problem of the next hop and the original sender.
For a contrast see forwarders who care about their business,
have a proper abuse desk, implement SRS or similar schemes, and
are a part of the solution instead of a part of the problem.
If SPF fails (and DK doesn't come to the rescue) SMTP fails,
it cannot work if everybody disables bounces or deletes them
automatically.
Looks like the ability of SPF to list many IP blocks instead
of just a few single IPs is a substantial advantage.
Not as far as the HELO is concerned, the typical "HELO policy"
should be a "v=spf1 a -all" where possible. In fact CSV can
now catch cases where SPF would find nothing. If your MTA says
"HELO mail.example.com" with a sender policy "v=spf1 a -all",
then there's no difference to pure CSV (what's the name, CSA ?)
But for a forged "HELO bad.mail.example.com" SPF probably has
no policy (minus zone-cut and excl. wild-cards for the moment),
while CSV could still find the "mail.example.com" stuff in its
second query.
The problem is we need more than just receivers *ignoring*
these complexities. We need senders *avoiding* them when
they write their SPF records.
If the statistics published by Andy (former MARID chair) are
correct, the number of domains grows much faster than the
number of SPF records at the moment, and while all domains
burnt by spammers are irrelevant, we still need more domains
publishing _some_ sender policy, even if it's not "optimal".
In any design it's a golden rule to never start optimizing too
early. First things first, an RfC for SPF as is. Then let's
start to optimize some ugly cases. Not every proud owner of a
mini-domain faces the same problems as RR or MSN or EBAY.
The general SPF standard does not need to cover the problems
of a few huge ISPs, it's possible to do this on a case by case
basis.
Instead of twisting the draft beyond recognition it would be
much more effective to remove "ptr" from the setup wizard, so
that users who don't know what they're doing never try to add
"ptr" to their sender policy.
I don't think its too late for SPF to start a migration
process.
You can always migrate towards a better policy within the old
policy framework, but better don't try to enforce a migration.
If the next release has a one-query "defense mode" for
receivers
If you're talking about m=, Radu already said that it's only
for cases with chained records (2 or more queries). In that
cases a second query for "include:not.me" is rather harmless,
and then you don't need m= at all.
Fact: m= is a bad idea for include:3rd.party. Therefore it's
only relevant for ...long policy... redirect=2nd.part, and so
on (chained redirections or include:same.zone)
This would then be m=... m=... ...long policy... redirect=2nd
part (and so on) plus sometimes redirect=one.more.part, because
the added m= stuff shifted the rest over the right end.
With include:not.me the complete m= suff vanishes in "not me",
and OTOH you probably don't need redirect=one.more.part. Net
effect, the same number of SPF records as with m=, one query
more for include:not.me, as clear and readable as m=, the same
number of DNS queries to get a PASS near the end of the chain.
a strong recommendation for senders to use the compiler and
simplify their records
Not for the average mini-domain owner, it's far more reliable
if they use names (a or mx) instead of IPs, unless they know
exactly what they are doing. If John Doe starts to guess the
IPs used by his ISPs then that's a recipe for later trouble.
there will be strong pressure on the few domains with
expensive SPF records, and not so much blame on SPF.
Sure, do you know any worse cases than spf.pobox.com ? Radu
found some, at least two fixed their policies after he asked.
Bye, Frank