Subject: RE: Comment on RE: [ietf-dkim] 1365 yes/no

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Fri, 2 Mar 2007 09:02:15 -0800

I don't see how 'never sends DKIM mail' is of any value since there is a precedence order here. The key record information takes priority over the policy record.

So if I get mail with a valid signature I never bother to check for the policy. 

> -----Original Message-----
> From: Douglas Otis [mailto:[email-masked]] 
> Sent: Friday, March 02, 2007 10:56 AM
> To: Hallam-Baker, Phillip
> Cc: ietf-dkim
> Subject: Re: Comment on RE: [ietf-dkim] 1365 yes/no
> 
> On Fri, 2007-03-02 at 07:00 -0800, Hallam-Baker, Phillip wrote:
> > > [mailto:[email-masked]] On Behalf Of Steve Atkins
> > 
> > > It's been out of scope since day one. The argument for keeping it 
> > > has been "Yeah, it's out of scope, but what the hell, 
> we're throwing 
> > > stuff that's far less useful into the pile of stuff. At 
> least this 
> > > one piece has some conceivable real world use, lets keep it."
> > 
> > I agree, but that is the reason that I don't want to open up that 
> > discussion now.
> 
> Rather than an assertion of "Never Sends Email" an assertion 
> of "Never sends DKIM Signed messages" would be of value to 
> domains. This should also be very much in scope or charter.
> 
> Perhaps this places the domain on an accreditation list as 
> such to preclude DKIM related traffic, while at the same time 
> allowing recipients to immediately reject any signed message 
> as those spoofing their domain.  This would help ensure bad 
> actors are defeated before any damage is done.
> 
> Combining "Always Signs" with "Never sends DKIM Signed 
> messages" may also mean "Never sends messages".  Oh well.
> 
> > What I would like to do is to get a policy framework described that 
> > actually works and then have an open discussion on 
> additional policy 
> > statements. Otherwise what happens is that we end up with a scheme 
> > that only addresses the low hanging fruit that was obvious at the 
> > time. I want a more systematic approach.
> 
> It should also be kept simple, and not evolve into a macro 
> expanded language resulting in hundreds of subsequent DNS 
> transactions consuming none of the sender's resources beyond 
> the initial query. : o
> 
> > I do not think that the argument that SSP/SenderID has 
> precedence here 
> > is actually very convincing. It might have been convincing 
> if they had 
> > adopted a prefix scheme or if they had managed to get to 
> their work to 
> > proposed standard.
> 
> I was unhappy with the WG closing when it did.  The group 
> might have been able to revolve the major DDoS and security 
> threats imposed by the scheme.  As it is now, this past work 
> remains a threat should it ever become widely adopted as experiment.
> 
> > As it is I would prefer to work on the basis that DKIM is going to 
> > define THE authoritative outbound email policy which might in turn 
> > mention the existence of an SPF record. This makes a lot of sense 
> > since we have the opportunity to make the discovery scheme work 
> > properly.
> > 
> > So the sorts of thing I would like to see in the outbound 
> email policy 
> > record is:
> > 
> >     DKIM
> >     DKIM-TEST
> >     NOMAIL
> >     PHISHING-TARGET
> >     SPF
> 
> I can agree with you up to the point where you wish to list 
> SPF.  I would rather see an effort made to replace the 
> dangerous SPF lists with a name based scheme on perhaps the 
> use of APL RRs instead.  By all means don't entrench an idea 
> that has come of the rails.
> 
> -Doug
> 
> 
> 
> 
> 
> 

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

---

From: Douglas Otis <[email-masked]>
Date: Fri, 2 Mar 2007 10:00:02 -0800

On Mar 2, 2007, at 9:02 AM, Hallam-Baker, Phillip wrote:

> I don't see how 'never sends DKIM mail' is of any value since there  
> is a precedence order here. The key record information takes  
> priority over the policy record.
>

I'll wager dollars to doughnuts that when email acceptance is based  
upon a DKIM signature, it will be done in conjunction with some type  
of accreditation.  This saves the expense of checking signatures  
where validity simply does not matter.

For high profile companies that have opted to use web based  
messaging, any DKIM signed email spoofing their domain creates  
queries for some random key, and when that fails, then for their  
policy record.  Hector could be right about which will come first,  
but components of a policy records can be republished with  
accreditation to eliminate unnecessary traffic generated by perhaps  
absorbent levels of fraud.  A message that appears to be signed when  
studied in the raw might mislead enough recipients, where this tactic  
could become common.  Not all providers will ensure these messages  
are blocked.

-Doug