Re: [Asrg] Re: Unique innovations made to anti-spam system

On Jan 23, 2006, at 5:46 PM, Frank Ellermann wrote:

> Douglas Otis wrote:
>
> > SPF is often open-ended.  This may not offer an assurance of the  
> > return-path either, and failure may also be in error.
> The latter would be a case of either an erroneous policy, then it's  
> the problem of the sender, or checking behind the border, then it's  
> a problem of the receiver.  Folks who aren't up to getting it right  
> better stay away from SMTP and DNS, that's no specific SPF isue.
I suppose this means any policy of '-all' would be in error then?


> The former ("open-ended" is your weaselword for MEUTRAL if I  
> finally got it) is no problem.
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.  For  
example, Sender-ID recommends that a "spf2.0/pra ?all" be used as an  
"opt-out" of the PRA algorithm.  This would be one example where a  
"neutral" result is _not_ the same as no record.  Of course, there is  
no real means for the sender to control how these records are used by  
the recipient.

> Receivers only intrerested in FAIL can ignore policies without a  
> single "-" qualifier.  And if they are only interested in PASS they  
> might be also able to optimize the evaluation.
> They can do many interesting things like check only every 112th  
> mail - just in case because Doug says 112 lookups are the norm.
The SPF draft calls for a _minimum_ number of 112 lookups before  
giving up on resolving the records.  When this is attempting to  
resolve some distant domain, timeouts may mean this will be  
reattempted later, perhaps again, and again.  There are configuration  
unable to fit within 112 lookups, even with all the tricks unless  
they include foreign address space or a non-address exists.

> > Rejection based upon SPF has similar problems with erroneous  
> > failures.
> Quite the contrary "drop FAIL" is extremely dangerous, reject is  
> always fine.
While drop fail is not good, rejection may still affect a large  
number of users.

> > SPF depends upon third-parties reading and acting on the record or  
> > perhaps expecting the spammers to have read your record.
> A combination, the spammers can't be sure who does something in the  
> direction of "drop FAIL" like e.g. SpamAssassin.  While it is  
> dangerous it has its uses.  Get around SA is the jackpot for a  
> spammer, trying it with a FAIL-protected address is no plan.
Are you saying a closed policy would be bad, but that only a closed  
policy would offer benefits?

> > Use of SPF also hopes that no one on your domain is sending to a  
> > forwarded account when closed.
> If that's about 1123 5.3.6(a) with both forwarder and next hop  
> ignoring the issue - as it's their right -, and if the next hop  
> checks SPF, then FAIL emulates "551 user not local" and works as  
> designed.  So far I had this once in 20 months, and the 551-bounce  
> (emulation, actually of course not 551) told me where to send the  
> message again directly bypassing the forwarder.
Many individuals cherish the use of an email-address that affiliates  
them with a school or society.  Before attempting to describe the  
valid path an email-address may take based upon the return-path or  
the PRA, these services worked.  It would seem that path registration  
has created the problem.

> The idea behind SPF is pure KISS.
There is very little with respect to SPF that is simple.  The  
combination of macro expansions, includes, redirects, and favors of  
open-ended authorization makes SPF the opposite of KISS.  When the  
parser may make 112 lookups in an attempt to resolve an address also  
suggests that something this complex has not adhered to the KISS  
concept.

> And if you stick to "ip4" in a policy it's also in practice KISS,  
> at worst you have to know what a "CIDR" might be.  If you finally  
> get the idea why you use either "ip4" or "a" or both in a policy  
> you're done.  The rest of the show like macros, "ptr", and what  
> else is for geeks or non-trivial mail setups of bigger ISPs with  
> clueful admins.
Expecting large and complex domains to use CDIR notation for outbound  
hosts ignores how these tools normally work and invites error.   The  
fact that larger domains must struggle to constrain their  
configuration suggests there is a fundamental problem with the  
approach.  The need for the 112 minimum lookup requirement also  
suggests there is a fundamental problem with this approach.
-Doug




_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg