[ietf-dkim] DKIM signature can mean it's safe to generate bounce?

Steve Atkins steve at blighty.com
Fri Jul 6 19:14:14 PDT 2007


On Jul 6, 2007, at 6:56 PM, Dave Crocker wrote:

>
>
> Steve Atkins wrote:
>>> so, perhaps, an SSP record by the signing domain that says  
>>> MailFrom is valid?
>> Possibly. What's the problem you're trying to solve?
>
> I really hate it when people ask pragmatic questions like that.  I  
> mean, really Steve, didn't you know that value propositions are  
> soooo pasé?
>
> But I suppose I have to answer it:
>
> I'm about to generate a bounce-category message.  If I'm suspicious  
> enough of the original message, I might decide not to.  By way of  
> trying to squelch bad bounce traffic at its source.
>
> Given the DKIM sig and the "Return" SSP record, I'll generate it  
> since the return address domain has said it's valid.

It really depends on the threat model.

If you're just trying to avoid random backscatter, then a header that  
says "X-Really-From: dick at earthlink.net" in a mail with a return path  
address of dick at earthlink.net and a DKIM signature that explicitly  
covers the "X-Really-From" header would be adequate.

The only case that won't catch effectively is the case where all the  
following are true:

   1. The return path is not that of the sender
   2. The sender maliciously adds an X-Really-From header that is  
identical to the return path
   3. The sender is an authorized user of the same domain as the  
claimed return path
   4. The ISP stamping DKIM is not aware of the X-Really-From header  
convention (so isn't removing or replacing it)
   5. The ISP stamping DKIM is signing all headers, rather than a  
fixed list

Whether that's adequate or not depends on the threat you're trying to  
defend against.


> John Levine wrote:
> > Personally, I'd rather use BATV.
>
> That filters at the destination, not the source.

Unless you use the near-mythical public-key version, but that does  
just move around where you want to do the cryptography.

Cheers,
   Steve




More information about the ietf-dkim mailing list