Re: Re: FUD on DNS Abuse

David MacQuigg wrote:
> > > 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.
My prediction would be that domains such as AOL, Yahoo and Hotmail will 
implement SPF checking, but put a limit on the number of queries allowed 
to 1 or 2. This means that everyone who wants to send mail to those 
services reliably will have to publish very efficient records. (Yes, 
ebay, that means you too!).
Currently, Yahoo does not do ANY DNS queries on incoming email, as far 
as I can tell. Any increase in DNS traffic would be expensive for them, 
because they'd have to invest in caching nameservers (which they don't 
currently need).
If SPF will have any success, it's form will be dictated to a large 
extent by those services named above, and perhaps a few others.
So, why allow 10 queries, when the market is unlikely to allow more than 
1 or two in the future ?
Is allowing a high limit anything more than narrow-sightedness ?

The above trend will be especially evident once I release the first 
implementation of MyDNS with compiler support built-in. Companies like 
easydns, zoneedit and so on will be very interested, and when they start 
adopting, there will be no excuse for expensive records.
> 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.
Actually... 99.98% of records that require multiple queries will be 
correctly after only 1 query, since in a DNS storm the email comes from 
everywhere but the few places that the mask specifies. So the incoming 
MTAs don't need to change behaviour, as they will only do the 2nd query 
for those 0.02% of emails that actually come from the neighbourhood of 
the mask.
This makes a mask-enabled SPF record extremely resilient to DoS attacks, 
while maintaining full function of the SPF record.
So don't worry, if you have the mask, your email will not be bounced 
even at the high of a DoS storm. (unless the storm is coming from you 
... LOL).
> ???  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.
Not quite so. the -all and m=~ are in conflict. The mask result will be 
the same as the "all" prefix.
Also, the mask is evaluated before the first redirect=, no sooner. So 
the IP4:'s in the first record are checked against the sender's IP 
*WITHOUT LOOKING AT THE MASK*. This is because the mask refers *ONLY* to 
IP4: mechanisms which are not in the current record. It would be a waste 
of space for the mask to also cover the mechanisms which are clearly 
visible in the first record.
Also, I would prefer to sticking to a mask representation that is easily 
human readable, so you can look at a record *set* and be able to easily 
tell if the mask is right or wrong, just by visual inspection and some 
simple arithmetic. If you can't easily tell, the trust in the mask is 
undermined (by humans). So when there are problems with the record, the 
first thing they do is disable mask generation.
PS. The MyDNS integration of the libspf2 is beginning to look very slick 
and reliable. I hesitate to release libspf2 yet because I'm still adding 
a few compiler-related functions to the interface, and I'd rather wait 
till the interface is stable. Another week or so should do it.
Greetings,
Radu.