On 10/1/10 1:19 PM, Jeff Macdonald wrote:
On Fri, Oct 1, 2010 at 1:05 PM, Dave CROCKER<dhc(_at_)dcrocker(_dot_)net>
wrote:
Oh. Sorry. I didn't get that. It's an interesting idea but I'd want to
hear
it explored quite a lot, since the idea of value is pretty broad. For
example,
if 3rd party signatures allow an ESP to get mail delivered better and,
therefore, to stay in business, I'd be hard-pressed to call DKIM's 'value'
lower
than for a first-party signer.
I find this exchange very interesting. I though the value of DKIM was
to provide a stable identifier. I find 1st party signing to be rather
constrained. It seems to defeat the purpose of DKIM. One might as well
resurrect DomainKeys, because it seems to have the same goals as 1st
party signers.
I'd like to propose Author Domain Signatures as signatures that the
author domain authorized. The ATPS and ALS proposals are ways of doing
that. Update ADSP to use this definition instead of "d= matches the
RFC5322:From domain".
I believe this allows everyone to get the best value of DKIM.
Jeff,
The ALS extension is fine for signing with sub-domains just to isolate
different mail streams. You should also consider the TPA-Label draft
which includes authentication and header field requirements in addition
to the third-party domain authorization, as found in the simpler ATPS draft.
The ability to include added compliance requirements provides two
significant benefits:
1) When DKIM signatures are required by policy (i.e. ADSP), then when
another domain offers authentication based upon DKIM, SPF, TLS, EHLO,
etc. the Author Domain would be able to rely upon these other methods
to safely recover from damaged or missing signatures. As it now stands,
there is a good chance these messages will be otherwise discarded when
the Author Domain attempts to keep their recipients from being flooded
with spoofed messages by using the "discardable" assertion.
2) When the Author Domain wishes to exchange messages with typical
mailing-lists, additional header field and authentication requirements
communicates to receivers which specific methods should be used, and
when these are not met, the message can be rejected. This approach
retains protection for the entire domain otherwise exposed to phishing
attempts.
Murray expressed a concern that these options are not allowed in a DKIM
working group document. However, implementation of these alternative
methods are not specified by the working group, and the TPA-Label draft
and can simply cite existing work. For example RFC 5321 section 4.1.4
states:
,---
An SMTP server MAY verify that the domain name argument in the EHLO
command actually corresponds to the IP address of the client.
However, if the verification fails, the server MUST NOT refuse to
accept a message on that basis.
'---
In other words, rather than seeing third-party policy only in terms of
DKIM verification, robust handling must not exclude other existing
methods. The ability to specify these additional compliance options
allows improved delivery rates and can extend policy specifications to
non-participating mailing-lists not otherwise covered by ADSP.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html