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

From: "Frank Ellermann" <[email-masked]>
Date: Sun, 23 Sep 2007 02:56:13 +0200

Scott Kitterman wrote ten weeks ago:

> On Friday 06 July 2007 20:09, Dave Crocker wrote:
>> It seems to me that if a message has a DKIM signature and the signing
>> domain matches the domain in the rfc2821.MailFrom command, then it is
>> safe to generate a bounce message to that address.

>> By 'safe' I mean that one can be confident that the mail will not go
>> to an unwitting victim of a spoofed address.
[...]
> I expect if limited to the case where 2821 Mail From domain is the 
> same as the signing domain it would likely be reasonably effective.
 
> SPF Pass would (if available) give you the same or better confidence.

Better because you'd already have this confidence after SMTP MAIL FROM
without DKIM crypto looking at the 2822 header.  SPF also allows to
aggregate more than one "sending provider", that's rather tricky with
DKIM or BATV. 

OTOH you'd never see an SPF PASS behind "taditional" (aka "broken by
1123 5.3.6a") forwarding, where Dave's approach based on DKIM would
still work.  The scenarios aren't equivalent, Dave's method is more
or less limited to cases starting out with 2822-From = MAIL FROM, but
after that it survives forwarding.  

If a mailing list manages to invalidate the DKIM signature Dave's
approach won't work.  But the list could very easily guarantee it's
own SPF PASS, so in practice receivers can handle most sound cases.

 Frank

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Douglas Otis <[email-masked]>
Date: Wed, 26 Sep 2007 15:57:23 -0700

On Sep 22, 2007, at 5:56 PM, Frank Ellermann wrote:

>>> It seems to me that if a message has a DKIM signature and the  
>>> signing domain matches the domain in the rfc2821.MailFrom  
>>> command, then it is safe to generate a bounce message to that  
>>> address.
>
>>> By 'safe' I mean that one can be confident that the mail will not  
>>> go to an unwitting victim of a spoofed address.
> [...]
> Better because you'd already have this confidence after SMTP MAIL  
> FROM without DKIM crypto looking at the 2822 header.  SPF also  
> allows to aggregate more than one "sending provider", that's rather  
> tricky with DKIM or BATV.

This can be done with DKIM using a strategy that can bridge policy  
domains.

See:
http://tools.ietf.org/wg/dkim/draft-otis-dkim-tpa-ssp-01.txt

Unlike SPF, the tpa-ssp method scales without invoking hundreds of  
DNS transactions.  This draft extends the current SSP draft.

> OTOH you'd never see an SPF PASS behind "taditional" (aka "broken  
> by 1123 5.3.6a") forwarding, where Dave's approach based on DKIM  
> would still work.  The scenarios aren't equivalent, Dave's method  
> is more or less limited to cases starting out with 2822-From = MAIL  
> FROM, but after that it survives forwarding.
>

The use of the From is sure to create problems for mailing-lists.  As  
with SPF, SSP also lacks policy scope which is unfortunate.  This  
could be repaired by extending SSP policy with drafts like TPA.   
Unfortunately, these extensions are unlikely to be incorporated and  
more convoluted work-arounds will likely be used.

-Doug

---

From: "Frank Ellermann" <[email-masked]>
Date: Thu, 27 Sep 2007 11:36:32 +0200

Douglas Otis wrote:
 
> See: http://tools.ietf.org/wg/dkim/draft-otis-dkim-tpa-ssp-01.txt

Oops, I didn't know this style of URL, Henrik's tools are amazing.
 
> Unlike SPF, the tpa-ssp method scales without invoking hundreds
> of DNS transactions.  This draft extends the current SSP draft.

As always "hundreds" is nonsense.  Minor nit, maybe s/*FWS/[FWS]/g
in your draft, I think you never want more than one FWS in a row.

Please add some examples, I almost missed the point where you're 
using the base32( sha-1( lcase( signing-domain ))) construct.

Let's say mail "from" (one or more of your scopes) domain.example
is sent via third party signers isp1.example and isp2.example,
what are those signers and later receivers supposed to do, and
when is whatever they do okay from the POV of domain.example ?

> The use of the From is sure to create problems for mailing-lists.
> As with SPF, SSP also lacks policy scope which is unfortunate.

For SPF in the sense of v=spf1 it's fine, it's limited to SMTP,
HELO + MAIL FROM need no complex scopes.  The PRA and 4405 cases
are also clear if publishers stay away from %h (HELO) macros in
their PRA policies.

You only run into problems when you're talking about something 
like 2822-From, neither PRA nor envelope sender.  BTW, I think
you could replace your "O" by PRA with a reference to RFC 4407.

If there's one thing we don't need it's "yet another definition
of 'originator'".

 Frank