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:dotis(_at_)mail-abuse(_dot_)org]
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:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] 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