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

On Mon, Jan 24, 2011 at 9:21 PM, Paul Ferguson 
<fergdawgster(_at_)gmail(_dot_)com> wrote:
> On Mon, Jan 24, 2011 at 6:14 PM, Dotzero <dotzero(_at_)gmail(_dot_)com> wrote:
>
> > On Mon, Jan 24, 2011 at 5:37 PM, Douglas Otis 
> > <dotis(_at_)mail-abuse(_dot_)org> wrote:
> > > 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?
> Hi Mike,
>
> While I'm just catching up on this thread, I can also chime in that --
> as far as I can tell, neither spf or dkim has had any impact on spam,
> at least from what I can determine.
>
> If that was the original intent of spf and/or dkim, then I would be
> inclined to say that neither have properly addressed the spam problem.
Hey Paul,

Thanks for chiming in. As I pointed out in my original response to
Doug, I inicated that in and of themselves, SPF or DKIM
succeses/failures do not tell you about whether a message is SPAM.
What they do allow you to know is whether that message is tied to a
particular IP Address or Domain. The best description might be that
they are enabling technologies.

For domains that have good control over their mail flows (which
mailbox providers can determine for themselves without relying on 3rd
party reputation services), my experience and the experience of others
is that one can (for example) recommend to mailbox providers that they
can drop mail on a double fail (SPF/DKIM) with very little risk of
dropping legitimate mail. Because each of these approaches break in
tehir own ways, they are actually somewhat complimentary. This does
have the side effect of reducing SPAM purporting to be from those
domains at mailbox providers using this approach. There are other
permutations/combinations that allow varying degrees of whitelisting
(confidence) or skepticism that the message really did/did not come
from the purported domain.

Without naming any names, I am comfortable stating that a number of
financial organizations have been working on this sort of
implementation in conjunction with various large receivers with
successful outcomes. I know that folks from some of those
organizations lurk here (jump right in, the water's fine). The focus
is more on phishing attacks and less on generic spam.

Part of the issue that has been percolating for a while is that most
of the interaction has been through private peering arrangements
rather than through open standards that allow anyone to play. This
also means that the data isn't publicly available. I (and others) get
feeds on authentication failures from various receivers. Some of the
senders are comparing notes and we are seeing similar outcomes. Again,
mileage may vary based on the specific mail flows and the control
exercised by those controlling the domain.

Unfortunately, because the data is being shared under contractual
arrangements you just aren't going to see detailed data being
disclosed in public forums.  Particularly sensitive data would be data
on individual message authentication failures provided in ARF format.
The best I have seen is including "cleansed" headers (RFC5322 To and
Return Path redacted) with links from the message body included. At
least for me, if I remove from the dataset our own legitimate links (a
relatively small number), all I am left with is maliciousness. I guess
the crude way to put it is that nobody is accidently purporting to
send mail using our domains and accidently putting in links. (This
case would be described as DKIM None and SPF fail.) If you want to
hook up during RSA we can share notes. I could also make an
introduction to some folks (I know some of them you already know) who
could be in a position to make much more extensive data sets available
to you.

I will qualify my statements by pointing out that I play in the space
known as potentially highly abused brands. Mileage may vary
significantly for domains that allow their users to send mail from
whatever mail server is handy.

This of course does not address the issue of subversion of the
emitting domains systems which would be problematic under any
scenario.

To sum up, this approach works well for some domains but is not a
general solution to the problem of SPAM (or phishing). To the extent
someone suceeds in controlling abuse against domains their work, the
abusers simply move on to abuse another domain which is not as
aggressively defended.

I think the difference between what Doug is saying and what I am
saying is that he is only willing to accept a solution which is works
across the board.

 I'll take the wins where I can get them and accept that the abusers
will go commit their abuse somewhere else. From your perspective, this
approach may not be particularly useful because it might be considered
a wash (substitute one abused domain for another). For a mailbox
provider/ISP this approach is one more tool in their toolkit.

What can I say, Darwin was right.

I think we can also all agree that there are no magic bullets.

In closing, the reason I'm saying things on the list that are directed
to you is that I think it is useful for the wider group to understand
that data is out there even if the detailed data is not openly
available.

Mike
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg