[Asrg] Positive assertions vs negative assertions Re: The state of the e

On Nov 17, 2008, at 8:55 AM, David Wall wrote:

> > DKIM is not intended to reduce spam.
> And yet so many have written articles to the contrary, including  
> wikipedia. (search DKIM spam)
> Since DKIM is intended to identify the sender, to ensure sent email  
> is legit and hasn't been forged, then it would reduce spam if all  
> senders did this because reputation matters.  For one thing, sending  
> spam is illegal in many areas, so having proof a spam is yours would  
> not be good from a legal defense perspective.
Someone intentionally sending spam will not use a DKIM identity easily  
associated with a legal identity. Either they'll be quite honest about  
sending the email, or they'll obscure anything that can connect them  
to the email, including a DKIM identity. Scarlet fish.
>  Second, blacklisting with provably bad senders would be be more  
> useful than some of the "random proof" blacklisting that goes on  
> today.
You cannot use DKIM for blacklisting, for reasons discussed later.  
Another scarlet fish.
> Yes, if you are infected by a spambot, you will send signed spam.   
> But if I can prove your system is sending spam, it may be easier and  
> quicker to get resolution to clean that system.
You can do that now. Peer IP address is perfectly good for that  
(despite valiant attempts by NAT vendors to make it less useful).
> When most spam forges the sender, you can't complain to the  
> purported sender that they are sending spam as it's not clear.   
> Furthermore, if your computer is "willfully neglected" and sends out  
> such spam despite notices, you'll get blacklisted, perhaps held  
> accountable as a spammer under the law, and if ISPs don't knock off  
> such abusing users, they will get blacklisted or perhaps held  
> accountable, too.
> With clear identification, spam and virus sending will go down in my  
> opinion, regardless of whether that's the intent of a given  
> technology.
That's, at best, wildly optimistic.

> Of course, like all such solutions, the real key is to get receiving  
> systems to start demanding such security be in place to accept  
> email.  Step 1 is to get senders to use it, to be sure, since you  
> need a good base of senders before anybody would block on the  
> receiving end, but spam won't stop until step 2 is done, which is to  
> block unless the sender is so identified.
Anyone who is familiar with the history of SPF can guess where this  
line of reasoning ends up.
DKIM has a critical feature that seems to consistently confuse people  
who try and use it as part of some anti-spam contraption:
"It is possible for an email to be validly DKIM signed when sent, yet  
not validly DKIM signed when it is received. "
Any number of forwarding systems and some MTAs will, in some cases,  
modify the body of a message, often just by modifying the encoding or  
moving MIME around in order to be able to forward it on correctly.  
Those cases are rare, but they do occur. And they're, to some extent,  
a systemic error specific to a particular sender or recipient (so one  
recipient may never see the problem, while another recipient may see  
it in a large fraction of their email). This is conceptually similar  
to the SPF/.forward problem.
That means that if you receive a message that is DKIM signed, you know  
for sure that the message was signed by someone who was authorized by  
the domain owner to do so - the signing domain takes responsibility  
for the message.
But if you receive a message that is not DKIM signed that doesn't tell  
you anything. Maybe the message wasn't DKIM signed when it was sent.  
Maybe the body was modified in transit, so it was DKIM signed when it  
was sent, but isn't now. (You can't guess which of those cases it was,  
as there's no way to distinguish between a DKIM signature invalidated  
by modification in transit and a cunning forgery intended to look like  
a DKIM signature invalidated by modification in transit)[2].
That means that DKIM is a single positive assertion ("this message was  
authorised by $DOMAIN") about an email, and nothing more. Lack of DKIM  
means nothing, and makes no negative assertion about the email. Any  
attempt to use the inverse of DKIM to mean something (taking some  
subset of email and asserting that any email within that subset that  
is not DKIM signed at receipt is not legitimate email) is based on a  
logical fallacy, and will lead - at best - to false positives if used  
to reject email.
(We really need some simple to remember fairy tale involving scrolls  
and wax seals and the dark and scary woods to simplify this  
explanation).
So, DKIM is useful for spam filters as it provides a persistent  
identifier for a sending entity, *not* because DKIM signed mail is  
unlikely to be spam[1]. Filters can build reputations, positive and  
negative, around those identities.
Any sender can choose to discard their current reputation and start  
over with a new, neutral reputation at any point. That means that  
senders who are sending generally wanted email will use DKIM to build  
and maintain good reputation, and get good delivery rates (even when  
they send similar email from a different IP address) because spam  
filters will recognize them as senders with a good history. Bad  
actors, those who are either knowingly sending spam or who know that  
their mail is not well received and that's leading them to get a  
negative reputation will tend to change DKIM identities, and their  
reputation will float somewhere around neutral.
DKIM is also useful for feedback loops, for the obvious reason that it  
gives a clear identity of someone who provably is responsible for the  
email.
And it would be possible to layer some other forms of shared  
reputation (third-party whitelists, for example) on top of DKIM, as  
long as that's done carefully and with a clear understanding not just  
of what a DKIM signature means but also what lack of such signature  
means. I'm not aware of anyone having done this yet, despite it being  
an obvious thing for phishing targets to consider.
But DKIM is just a device that lets you assert that a particular email  
was sent on behalf of a persistent entity. It's not intended to, and  
will not, reduce spam (even though the data it provides may be useful  
to some spam filter related systems).
Cheers,
  Steve

[1] At various points in the deployment process a DKIM signature may  
well have been a sign of the mail being spam, rather than otherwise,  
for some recipients.
[2] And maybe it's perfectly legitimate email that just wasn't DKIM  
signed for some perfectly good reason, but even ignoring that...
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
https://www.irtf.org/mailman/listinfo/asrg