On Wednesday 07 October 2009 09:38:37 Doug Otis wrote:
Doug,
I've in favour of a solution to option C) as you describe it: To authorize
mailing lists to better ensure their message's handling while asserting a
(ADSP) policy of "all".
Publishing third party allow records on the author domains seems to be the
most reliable method here.
A simplified record syntax of the following could be used:
mipassoc.org._3p._domainkey.example.com IN TXT "dkim={all|unknown|discard}"
advantages:
* simple
* DNS can be delegated at the _3p level (or any level below)
* same format as ADSP (needed at least dkim= to avoid conflicts with all
wildcard SPF record)
* could apply mail-filtering same as ADSP (only stricter)
disadvantages:
* cannot do full mailbox ietf-dkim(_at_)mipassoc(_dot_)org (don't know if this
is needed)
far left side benefits:
A list archive like gmane or mailarchive could publish a DNS hierarchy in the
same form as a service to verifiers who want the answer to the question "Is
this a email list?"
A simple and static hashed "authentication" record could be applied by
customers at their leisure _without_ modifying how third-party DKIM
providers sign their customer's email.
good
Use of a hashed authentication
record allows all messages to receive the same signature,
I don't know what this means.
where there would be no transitioning concerns with respect to when a
customer's DNS server synchronized with that of the provider's key references.
good.
Extracting cost for this service could occur when allowing customers the
use of their own domain in From headers. After that, no hand holding or
DNS publication coordination would be required. Another benefit could
include an easy ability to authorize mailing-lists that modify messages.
Such authorizations could be added and removed without affecting the
operation of the outbound MTA or the mailing list.
good goal.
Daniel Black
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html