On Wed, Mar 11, 2009 at 4:41 PM, Steve Atkins <[email protected]>wrote:
> > On Mar 11, 2009, at 1:38 PM, HLS wrote: > > > > > > > On Wed, Mar 11, 2009 at 3:33 PM, Steve Atkins > > <[email protected]> wrote: > > > > This was touched upon back in 2007/2008 holidays with a WG > > suggestion to add a DKIM-Signature tag thats says *first party only, > > neutral, etc* which can be viewed as an optimization. > > > > I think it is a great idea. But the issue is legacy mail. The > > issue is not the good mail. The issue is the bad mail - the one that > > don't have the "extra" DNA genes to detect. > > If the flaw is bad mail being sent to recipients who have never > received good mail, what's the threat that's being defended against? > Bad mail? Caching and recording is good. But what if you never saw this before and don't have information recorded? An example: corp.xyz.com is a company that would like to do online commerce or billing with their customers (B2U). A rare market scenario <g> They use "customer-support.xyz.com" as a special 2822.From address in all their correspondence to their user base. Pre-DKIM: Legacy mail From: [email protected] To: layman_user @ someisp.com As we know, this is subject to spoofing and phishing. There are indeterminate results that simply ends up getting passed to the users. I think we can all agree this one the motives and reasons why we are here. DKIM: 1st party signature DKIM-Signature: d=customer-support.xyz.com From: [email protected] To: layman_user @ someisp.com And a ADSP DKIM=DISCARDABLE record is available. Now, with immediate short-term and long term benefits, this company will be protected at all ADSP compliant receivers. No more or a greatly diminished legacy spoofing problem for this domain. Domains, receivers and users benefits. So the concern is, "is this too much DNS overhead?" Well, we already covered two aspects for optimization per SSP design requirements guide and the TA (threats analysis) guide. 1) Valid 1st party signatures do no not policy lookups. 2) Only with no signatures (invalid), is ASDP recommended. This is where the issue regarding the 4871 "Failure = No Signature" comes to play Not trying to rehash it. Just analyzing it from an implementation standpoint: For #2 above, it means two things: 2) Only with no signatures (invalid), is ASDP recommended. 2.1 No (physical) signature exist 2.2. An failure signature promoted to no signature. Well, the in-band policy tag idea will only work for 2.2 and in this vain, I think it is a good idea as we move into the long term operations of DKIM/ADSP. But you still need to deal with 2.1 when there is no recording information, no signature. This is the only way to protect corp.xyz.com with its vendor/user communications. The idea discussed is that this ADSP policy would need to be duplicated in the DKIM-SIGNATURE as an optimized long term operation. Jim Fenton pointed out that this is good, but it may further complex DNS key/policy management. -- hls
_______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
