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
dkim-ops(_at_)mipassoc(_dot_)org
http://mipassoc.org/mailman/listinfo/dkim-ops