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 PROTECTED] > 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 PROTECTED] 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
