MH Michael Hammer (5304) wrote: > >> -----Original Message----- >> From: [email protected] [mailto:ietf-dkim- >> [email protected]] On Behalf Of Steve Atkins >> Sent: Monday, March 09, 2009 12:23 PM >> To: ietf-dkim WG >> Subject: Re: [ietf-dkim] Handling the errata after the consensus call >> >> If you have a list of domains to check, you don't need any of the >> ADSP infrastructure, just require valid DKIM signatures for any >> mail coming from those domains on the list. >> >> So any use case that uses a list (private or public) of domains >> to apply the algorithm to is probably out of scope for ADSP. >> > > And this is the reason I like to say that ADSP is the public mechanism > for achieving what is currently being performed through private > agreements.
Exactly. The key reason is not just to get a standard [public] protocol, but when the facet is turn on full blast (the adoption catches on like wild fire), there are going to be a lot of instant legacy spoofing that can now be detected. Once the HVDs or PVDs (high value or private value) begin to implement DKIM, and IMO, I believe most will first explore DKIM with a private exclusive usage mode of operation before applied it in other areas, many compliant receivers will for the first time ever have a new level of standard email information to work with to better deal with the legacy spoofing. I never questioned the idea that valid signatures (from good or bad guys) still needed to be dealt with in other ways. But that classification is what we have today when receivers have no extra information. The concern I always had which was the purpose of the expired DSAP I-D I wrote, was to protect the DKIM domain from the legacy fraud that exist today. This is where the HIGH PAYOFF will be. This is where the DKIM DOMAIN first trying it out will immediately see the benefit when there is LESS fraud on other remote receivers and sites. When users at these other sites are less prone to getting spoofed mail. Thats the payoff. -- Sincerely Hector Santos http://www.santronics.com _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
