Re: [Asrg] Misconceptions about SPF (was: Unique innovations made to anti-spam system)

[Douglas Otis <dotis at mail-abuse.org>]

On Wed, 2006-01-25 at 07:11 +0100, Frank Ellermann wrote:
> Douglas Otis wrote:
> 
> > I suppose this means any policy of '-all' would be in error
> > then?

This was about unintended failures being due to a policy that ends with
'-all'.  This depends upon how changes are made for forwarding to
accommodate path registration.  When there is no local mailbox, what
change to the return-path is made?


>  Does CSV also offer a "never used as HELO" somehow ?

The Priority field is always 1 for version.  The Weight field of the
_smtp._client.<ehlo> SRV RR can be either 1 no target, or 2 authorized
and target defined.  There is also the Port field where a value of 1
indicates all clients within this domain must have a corresponding CSV
record.


> > There are at least two types of open-ended lists, '?all' and
> > '~all'.  It is rather common to see both.  The first would
> > be what is described as neutral, and the second would be
> > soft-fail.
> 
> The latter is mainly for testing purposes while a domain tries
> to figure out where its out-going routes are.  If that turns
> out to be too difficult they should pick '?all', and otherwise
> they can go for '-all'.

These multiple methods of open-ending the authorization however was the
reason for using the more general terms of open-ended or closed.


> You still missed the point that SPF policies simply places each
> and every IP into precisely one of the four sets +, ?, ~, -

Nevertheless, these four sets do not provide clarity what the qualifier
means to the sender or the recipient.  A PASS may mean many things, and
a NEUTRAL could be treated as a PASS because there was a record and it
did not indicate a FAIL.  Even assuming everything is interpreted
correctly by the recipient, there remains a fair amount of risk when
reputations are justified using these results.  


> SPF records with "+all" at the end are not only legal, they can also
> make sense if it's an "included" policy:
> 
>       x.example. "v=spf1 -include:not.x.example tons=of-stuff"
>   not.x.example. "v=spf1 -ip4:1.0.0.0/8 -ip4:2.0.0.0/8 +all"
> 
> That's a fast way to say that any IP not starting with 1.*.*.*
> or 2.*.*.* is a FAIL (the "-" for the include) after it matched
> the "+all" at the end of the not.x.example policy.

Indeed include is a mechanism, it terminates (matches) on a PASS, which
with a '-' qualifier, upon finding a PASS within the include, would
terminate processing and then result in FAIL.  The include would ignore
the -ip: mechanisms and only see the +all (a mechanism that always
matches.)  The default of no match is '?'.  I understand how this works.

> Nothing's "open-ended" in SPF policies.  You can get the effect
> of "?all" without using it, e.g. "?include:not.x.example" would
> result in NEUTRAL for any IP that's not 1.*.*.* or 2.*.*.*

But a NEUTRAL or PASS policy both expect the message to be accepted.
This would be an open-ended policy where perhaps any IP address would
still obtain the acceptable NEUTRAL result.

> And as you also pointed out some domains might not like to use
> FAIL at all, but still offer a PASS for some IPs, to be used
> in white-listing up to reputation.

There would be some concern regarding whether this public record becomes
abused by other systems with access to a shared server, or whether the
accrual of behavior only assesses PASS results.  Clearly, some have
elected to treat no records with a lower rating than the '?' qualifier.
Offering any value for just having a record means there must be some
method to adjust for abuse, and that adjustment will likely represent an
unfair reputation.


> So nothing's technically wrong with NEUTRAL, and DKIM SSP also
> has a similar concept 'o=~' "some mails signed".  I'm too lazy
> to dig if CSV also offers a kind of explicit DUNNO, does it ?

Things are rather cut an dry with CSV.  There are modes that have been
defined, but I doubt if they would ever be used.  These were defined
assuming someone may develop a new way to authenticate, but still would
want the authorization mechanism.


> I'd certainly like to see the results of investigations by some
> other agencies and commissions about this "opt out" scheme.  In
> practice it's probably moot.  SMTP folks know why MAIL FROM and
> PRA can be different.  Therefore it's bogus to use algorithm B
> for identity B with a policy for identity A (or vice versa).

Agreed.


> > The SPF draft calls for a _minimum_ number of 112 lookups
> 
> | To prevent DoS attacks, more than 10 MX names MUST NOT be
> | looked up during the evaluation of an "mx" mechanism
> [... dito "ptr"  ...]
> | SPF implementations MUST limit the number of mechanisms and
> | modifiers that do DNS lookups to at most 10 per SPF check,
> | including any lookups caused by the use of the "include"
> | mechanism or the "redirect" modifier.
> 
> MUSTard _maximum_  1 SPF + 1 TXT + 10 MX + 10 A * 10 MX = 112.
>
> How many years didn't you look into a SPF spec. ?  That's state
> of the art for years after one Doug Otis whined about the vague
> processing limits in early 2004 SPF drafts in MARID.

The maximum that should be found in a record, would also be the minimum
that should be examined before quiting.  The concern is with respect to
what is being asked of the recipient, and less about what is being
allowed the sender.  A lookup may represent many queries.  From this
perspective, the SPF draft demands a minimum of more than one hundred
lookups by the recipient if needed. Of course, there may be less needed.


> > There are configuration unable to fit within 112 lookups,
> 
> Well, if they have more than 100 IPs for their 10 MXs they
> should try something simple like ip4:111.222.33.0/24 (256 IPs)
> that doesn't need any lookup.

A provider has better control of their address space in many cases.

The problem presents itself when there is a diverse configuration of
MTAs, perhaps as a kiosks sending information in the mail to friends and
family from diverse addresses, then combined with corporate and other
related MTAs, all attempting to utilize the same email-address domain.


> > The need for the 112 minimum lookup requirement also
> > suggests there is a fundamental problem with this approach.
> 
> That would be true if there is any minimum 112, but that's not
> the case.  It's a _maximum_ involving 10 MXs each with 10 IPs.

A maximum to publish is also the minimum to lookup when needed.

-Doug  





_______________________________________________
Asrg mailing list
Asrg at ietf.org
https://www1.ietf.org/mailman/listinfo/asrg