Re: [spfbis] Local macros strike again, was Suggestion...

[Douglas Otis <[e-mail]>]

On 1/13/12 5:42 PM, Hector Santos wrote:
>  Douglas Otis wrote:
> > Dear Hector,
> >
> > This was simply explaining the impact caused by a change Wayne
> > Schlitt made to host name limits in his SPF library. He restricted
> > the number of host names resolved to 5. This caused a problem for
> > t-online.de who never published SPF records but were subjected to
> > "default" SPF records such as "a mx/24" and that had 8 hosts in
> > their MX RRset, for example. :^(
>
>  Doug,
>
>  Since I'm not familiar with the idea of a "default" SPF record, I
>  don't quite understand why a receiver would applied a "SPF default"
>  to a domain that did make any SPF explicit declaration. Why would you
>  not expect to see problems with this? If this part of the
>  specification?

Dear Hector,

AFAIK, t-online.de never published SPF records.  Some implementers 
leveraged SPF built-in functions to make "best guesses" about domains 
lacking SPF records.  This tactic is found in many SPF implementations 
as it will be for years.  When a guess by thousands of recipient 
libraries fail to provide consistent results, as it was for t-online.de, 
users believed the fault was with t-online.de, not realizing the actions 
of SPF foo.  As a result, this created a "defacto" rule for those not 
publishing SPF records, "Do not publish more than 5 hosts in your MX RRset."

>  That said, what we have (in our package) is a macro-based filtering
>  language that includes a macro called DIP for DOMAIN::IP association.
>  Its a lightweight LMAP rule that sysops can add to their filters.
>  We recommend to add them for KNOWN transactions that do not have SPF
>  records and only do so if its clear to them that a DIP would
>  accurately apply. These are the DIP rules I have added over the
>  years for our SMTP server:

The concern is not with sysops using macros, although authenticated 
sources will provide better consistency and security.

The concern is that SPF allows _any_ domain to run SPF macros leveraging 
the powerful resources of recipient's email service providers.  Use of 
local-part macros means SPF results are NOT cache-able and always 
require repeated macro execution.  This is true even for cached SPF 
records!  Whether it is 10 or 100 transactions per message that might be 
generated, these transactions represent a FREE attack for any malefactor.

These additional transactions are unlikely noticed or logged by email 
service providers.  Their trigger is any email message that forwarded 
the malefactor's Mail From parameter as required by SMTP.  When a 
malefactor's SPF record targets some victim domain, messages sent to 
thousands of different domains will trigger their Distributed Denial of 
Service attack with a high level of amplification.  An attack where 
victims never see the messages, and where those reflecting the attack 
will likely remain unaware of their role.  None of the messages or SPF 
records need to contain the victim's domain since even this can be 
synthesized by SPF macros.

Virtually all other services authenticate with a brief exchange 
cryptographically verified within a few transactions that:
  1) factors are cache-able  (spf + local-part macros NOT cache-able)
  2) results are cache-able  (spf + local-part macros NOT cache-able)
  3) minimal demand on recipients (NOT cache-able and 100+ transactions/msg)

After the high resource expenditure, the email provider reflecting their 
resources remains an enigma, and only their IP address have been 
authorized.  The domain involved could be one of the 100K new seen daily.

>  Again these "default", SPF-like rules SHOULD only applied where there
>  is precise knowledge. I can't envision a general "SPF Default" rule
>  applicable to all non-SPF domains. Is there such a thing?

Unfortunately, many consider making a guess is okay.  All of this risk, 
guesswork, and wasteful use of resources disappears with the use of 
normal server authentication.  Email service providers need to 
AUTHENTICATE to protect users, their reputations, and to function 
properly with IPv6.

Regards,
Doug Otis