On 9/10/10 6:50 AM, McDowell, Brett wrote: > On Sep 9, 2010, at 5:40 PM, Douglas Otis wrote: > > I didn't mean to suggest MLM's should stop doing the things they do > that breaks DKIM signatures. I'm actually a fan of the A-R header > (or perhaps a new one) approach -- used in a clear (profiled?) way -- > so MLM's can assert to receivers that they verified the senders > signature before processing and re-signing it.
Even when every MLM properly handles and inserts A-R header fields, bad actors are still able to spoof this information. To sustain acceptance policy, the domain making the assertion needs to provide authorization whenever third-party services are included. Authorization by-name works well for DKIM and would be suitable within an emerging IPv6 environment. Authorization by IP address will consume too many transactions and will likely be unable to deal with an upcoming 4 to 6 transition. > > On the other hand, the TPA-Label concept is premised upon > > third-party sources being recognized by senders. As the diversity > > of sources increase, identifying good rather than bad becomes a > > more productive strategy. For this scheme to function, the sender > > will need to reference a third-party list that meets their > > requirements, or generate their own. > > > > By placing the DKIM signature within a subdomain, the TPA-Label can > > also indicate to recipients how _any_ authorized message with From > > header fields containing an address from their domain is to be > > authenticated. This scheme should help email transition gracefully > > to stronger methods. This scheme should also allow phished domains > > the ability to use a single domain for all of their email, > > including messages from unmodified mailing-lists, while also > > offering the strongest protection available from each source. > > I reviewed the TPA-lable I-D awhile back but lost track of the URL. > Please resend and I'll take another look. But as I recall it just > seemed "too hard". https://datatracker.ietf.org/doc/draft-otis-dkim-tpa-label/ In comparison, ADSP dkim=discardable represents the only actionable assertion that is not only "too hard" it is "impossible" when typical third-party services are used. Since so few domains can use ADSP to provide an actionable result, not even for ~20,000 phished domains, the few that do are likely to have these assertions converted to filtering rules to avoid unproductive transactions. While there are no specific tools available to allow an organization such as yours to create their own TPA-Label list, an internal TPA-Label request web-site would be a method for ensuring only third-party services being utilized by employees are authorized. The requests should be processed with scripts that explore how email from the third-party domain can be authenticated, and whether the message contains List-ID or Sender header fields. The support of TPA-Label lists represents a "blue-ocean" opportunity as a service designed specifically to ensure email remains a safe, productive, and unconstrained instrument for conducting business. This scheme is not limited to only DKIM, but can include any new scheme, such as those that might emerge from the keyassure efforts. -Doug _______________________________________________ dkim-ops mailing list [email protected] http://mipassoc.org/mailman/listinfo/dkim-ops
