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 [email protected] (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
