On 10/1/10 1:19 PM, Jeff Macdonald wrote: > On Fri, Oct 1, 2010 at 1:05 PM, Dave CROCKER<[email protected]> 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
