On Fri, 2006-08-25 at 22:10 -0700, Jim Fenton wrote: > Douglas Otis wrote: > > > It MUST always be the provider offering outbound services, not the > > provider receiving messages held accountable. The designators are > > the receivers of email. Not the senders and signers. Reputation > > is about watching for abuse when it is sent by your customer, even > > when they are using their email-address of the day. > > In that case, you must believe that key delegation and NS delegation do > the wrong thing.
A naive provider may hope a signature not bound in any way to the message envelope will be used exclusively to block spam. They will be in for a rude awakening. It does not matter who signed what, the IP address WILL be blocked! DKIM is excellent at identifying who sent the message based upon the 2822.From, where 2822.From policy name associations can be extremely useful at better enabling this genuine benefit using inexpensive autonomous administrative techniques. A name association list is done by one entity. Key exchanges or zone delegations MUST be done by two. Administration by one is far better than two when scaling is considered. > SSP Designated Signing Domains have been promoted as making it easier > for some domains, particularly small domains, to obtain a first-party > signature. But that otherwise the end result is the same. 2822.From policy is not graphing DNS name trees together, or in any way affecting the integrity of the signature. Attempting to exchange keys on a large scale WILL affect the integrity of the signature. 2822.From policy can list associated domains, and is extremely simple in comparison. With the delegation approach: - A user must forgo being recognized when using an email-address outside of the signing domain. - Send their messages through one provider offering combined domain/email services. - Run their own signing MTA and obtain relay services. - Establish arrangements for routinely exchanging keys with several providers to ensure a robust service. Exchanging keys with a several providers who in turn must recognize and sign messages for millions of customers using different keys is not without its own risks. The alternative to this absurdity would be to sign with a common signature, ensure only validated 2822.From addresses are signed within a protected domain, and let the millions of customers make an effort on their own when needed. This effort would allow the recognition of any email-address operated under a domain controlled by the users. This effort could ensure their business associates, friends and family by allowing their messages to be properly annotated as being from them. This annotation process first validates signatures for addresses found within the address book, and then annotates messages where either the i= syntax or the 2822.From policy has assured the 2822.From address. The i= syntax should already indicate the provider has restricted use of the 2822.Form address. The next step is to allow customers a means to request the use of other email-addresses, signed under the provider's common domain. This would be no different than subscribing to a mailing list or obtaining an email-address certificate. Market forces alone will likely see that this happens. > My point is it isn't: the point of responsibility is different for SSP > Designated Signing Domains from the other forms of delegation. No. DKIM may allow being able to uniquely recognizing a source within a domain. DKIM offers no means to prevent replay abuse. Reputation based upon signatures or keys won't work either. DKIM does not offer a means to prevent spam. It is as simple as that. DKIM does not offer a practical means to hold an email provider accountable based solely upon the signature. Providers who think DKIM fulfills a dream where they no longer need to concern themselves about the content of their networks are sadly mistaken. DKIM is a practical tool for reporting abuse. DKIM is an excellent tool for conveying assurances about the 2822.From domain. The signing and address domains do not need to match for this to be done safely. In fact, allowing these to differ is likely the ONLY practical and safe solution where DKIM offers significant value. -Doug _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
