At 01:15 PM 3/31/2005 +0200, Frank Ellerman wrote:
David MacQuigg wrote:
< postpone discussion on Forwarding Problem, except the part where it
impacts the DNS problem, continue with DNS abuse problem >
> 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.
Looks to me like SPF was optimized too early for versatility and
sophistication. Now we are stuck with having to deprecate some of the
nifty optimizations.
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 agree very little needs to be changed in the draft as far as allowed
syntax. It's all a matter of emphasis. We can leave the syntax as is, but
urge new publishers to use the wizard. The wizard should not offer
features that prevent it from outputting a simple one-query SPF
record. This will be easy for mini-domains. The large ISPs may have to
think about how they want to set up their subdomains.
> 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.
I don't think enforcement will be necessary if we get the voluntary
migration started early. Then if there is abuse, enforcement will come
from receivers who switch to "one-query defense mode" whenever the load
gets heavy.
> 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.
m= enables a "one-query defense mode", even in cases where you have chained
records. Consider what will happen in a DoS storm with a receiver in
defense mode. (Starting to sound like football, although I think of it more
as a chess game. :>)
Records that are already compiled to a simple one-query list will be
processed normally. Records that require multiple queries will not be
evaluated at all and will result in a temporary reject. Adding the m=
syntax allows us to reach a conclusion in *most* of those multi-query
cases, even without the additional queries. In a DoS storm, this could be
*almost all* cases.
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)
??? I assume you are talking about the m= mask getting out-of-sync with
the 3rd.party setup. The compiler will need to pay attention to the TTLs
on any data it uses in generating the mask, or any other part of the record
that depends on 3rd.party data. Whatever problems there might be here
result from including 3rd parties, not from m=. Am I missing something?
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.
??? This seems like an edge case. We have a record that just barely fits
in N packets. Pre-pending the mask pushes it to N+1 packets, but it saves
N queries in *most* cases, which could become *almost all* cases in a DoS
storm.
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.
??? I guess I'll need examples to follow this.
Here is an example of what we could do with a huge domain like rr.com:
m=~24(181ecb,181cc8,181ccc,181eda,185d2f,181909,
411805,185ea6,181d6d,424ba2,181802,412005) ... -all
Existing checkers ignore the m= and process the ... with all the usual
redirects and includes. Upgraded checkers will be able to take advantage
of the new syntax. The ~ means the mask result is ANDed with the remaining
... result. If it fails to match, you are done.
Eventually, the mechanisms and modifiers could be deprecated (at least in
the compiled record), the ~ changed to a +, and the whole record reduced to
a simple mask.
m=+24(181ecb,181cc8,181ccc,181eda,185d2f,181909,
411805,185ea6,181d6d,424ba2,181802,412005) -all
> 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.
John Doe will not likely be operating a public mail server. More likely he
will be simply forwarding through his ISPs mail server. Even my ISP
(gain.com) uses a huge forwarder (mailsystem.us).
Why does *any* public mail server need to authorize its forwarders? ( I
know, SPF currently requires it. I'm asking a more fundamental
question.) gain.com should authenticate daves-garage.com, and then
authorize their own servers. The final link to the public Internet
(mailsystem.us) should authenticate gain.com, and then authorize their own
public mail servers. If I want to send mail directly, without going
through these forwarders, I should get a static IP, create my own DNS
records, and do my best to avoid getting daves-garage.com on any blacklists.
> 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.
Getting companies to update their SPF records should be even easier with a
nicely packaged wizard. The compiler should be built right into that wizard.
-- Dave
************************************************************ *
* David MacQuigg, PhD email: dmquigg-spf at yahoo.com * *
* IC Design Engineer phone: USA 520-721-4583 * * *
* Analog Design Methodologies * * *
* 9320 East Mikelyn Lane * * *
* VRS Consulting, P.C. Tucson, Arizona 85710 *
************************************************************ *