Re: [Asrg] ipv6 macro expansion example in SPF specification, DNS ranges...

[Dotzero <[e-mail]>]

On Mon, Jan 24, 2011 at 10:24 PM, Douglas Otis <[e-mail]> wrote:
> On 1/24/11 6:14 PM, Dotzero wrote:
>>>
>>> Mike,
>>> >
>>> >  An SPF failure can not be trusted to be an indicator of spam.  DKIM
>>> > signing
>>> >  is almost never assured, especially when handled by third-party
>>> > services.
>>> >  As such, these mechanisms failing alone or together still do not offer
>>> > a
>>> >  safe basis for rejection.  Of course both passing means nothing as
>>> > well.
>>
>> Doug, there are plenty of people with real world operational
>> experience that would disagree with you.  You state that failing means
>> nothing and passing means nothing. If that is true, why are there a
>> significant number of implementers using this approach successfully?
>
> Defeating spam requires the reputation of SMTP clients be weighed for
> rejection or acceptance!

Doug, could you share with us what reputation is? As far the mailbox
providers are concerned (that I have spoken with) it is reduced to
"What have you done to me today". Their systems don't care whether you
have had a good reputation for the past 2 years. If you start spewing
badness today and you start generating complaints today then you will
be throttled or blocked. If the time interval of reputation is that
short then reputation systems are not particularly useful as an
absolute requirement for defeating SPAM.

>SPF failures say little about an SMTP client.

They may or may not say something about the client in and of itself
but they do say something  about the relationship of the SMTP client
to the purported Mail From domain when a well constructed SPF record
ends in a -ALL

>  DKIM failures also say little about the SMTP client because either
> mechanism MUST be allowed to fail to retain email delivery integrity.

A purist always brings a smile to my face. I know quite a few folks at
large receivers who would disagree with your "MUST". What they are
concerned about is ensuring the delivery integrity of mail their users
want. As far as delivery integrity of mail their users don't
want.....not so much. And that includes marketing emails their users
don't want. The issue for them is not generic email delivery integrity
but rather, how to find the sweet spot of
rejecting/blocking/discarding while minimizing (not eliminating every
single instance) performing such actions on mail their users actually
want.

>When
> failure of SPF or DKIM offers scant basis for judging an SMTP client, they
> are useless as a mitigation tool.  Ipso facto, their passing therefore
> provides little meaning as well, since mitigation must be based upon
> reliable mechanisms.

Reliability is not a generic. It is a measure. One mailbox provider
may choose a 99.99% reliability level and it's users may find that
acceptable. Another may choose 99.999% reliability and it's users
might find that acceptable. It may be that the mailbox provider
segregates various inbound mail streams in making these
determinations.

Here is a truth for you. Mailbox providers will determine for
themselves what works for them irrespective of any "MUST" you seek to
impose on them. They will use standards based approaches and they will
use non-standards based approaches. They will discard mail in a manner
that offends your sensibilities. At the end of the day it is not about
you....it is about them and their relationship with their customers.

>Overlapping results must be considered a mere
> distraction from what is needed to mitigate spam.  In rare cases, DKIM may
> play a role in preventing spoofing, but this can not be considered a
> significant component of spam mitigation.
>

"cannot" is a very strong word in the manner that you use it.