On Apr 6, 2013, at 2:41 AM, J. Gomez <[email protected]> wrote:
> On Saturday, April 06, 2013 2:20 AM [GMT+1=CET], Douglas Otis wrote:
>
>> There has been some discussion regarding often violated third-party
>> limitations of DMARC policy. A modified version of
>> http://tools.ietf.org/html/rfc6541 where DMARC is used to signal ATPS
>> support rather than inclusion of 'atps' tags within the DKIM
>> signature can offer fewer use constraints.
>> (...)
>> For example say some social network wishes to protect users messages
>> using DMARC while allowing participation with various third-party
>> relay services, such as well managed mailing-lists. ATPS provides a
>> means for DMARC domains to make explicit exceptions and to react
>> quickly when a problem is reported.
>
> Will that mean that for every mailing list that your users subscribe to, you
> would have to update/amend your DMARC DNS RR to declare the Organizational
> Domain on which said mailing list is hosted?
Dear J. Gomez,
The suggestion is simpler than you imagine. The DMARC record can
remain fairly static.
Rather than modifying DKIM signatures to signal use of third-party
DMARC authorization for otherwise uninvolved third-parties (such as a
mailing-list), the DMARC record would serve this purpose instead.
To support the third-party extension for DMARC, the domain would publish:
_dmarc IN TXT
"v=DMARC1; p=none; "
"atps=v2;"
"rua=mailto:[email protected]; "
"ruf=mailto:[email protected]"; )
Authorization labels would then be published below _atps such as:
"QSP4I4D24CRHOPDZ3O3ZIU2KSGS3X6Z6._atps" TXT "v=ATPS2;
d=[*.]<authorized_domain>;
scope=F"
...
Since this approach will not require coordination between those offering
authorization and those adding the means designated in the specified scope
parameter. i.e. DKIM. The prior specification included code needed to
generate the hash labels. For good reasons only a single hash algorithm
should be used. I would also recommend reintroducing a scope tag since this
permitted greater control and accommodated other verification methods such
as StartTLS.
http://tools.ietf.org/html/draft-otis-dkim-tpa-label-06
This older draft also added a few enhancements such as:
Confirming the authorized domain using a left-hand wildcard shorthand.
The goal was to arrive at an industry standard method for noting
trustworthy third-party domains. In that case, the domain using DMARC
could delegate the listing of third-party services to a different
administrative domain. Ideally, this would be accomplished by delegating
the _atps domain. Delegation could also be done unilaterally using
a DNAME resource record as well.
Of course, users within the DMARC domain could be provided a portal that
allowed them to request authorization of a mailing-list. That request
could then be automatically vetted or reviewed manually.
In any case, inclusion of a new domain is done by simply adding a new hash
labeled resource record below _atps.
> If so, I see it as not very scalable, error prone, intensive in human labour,
> and a reactive solution instead of a proactive one (i.e, only after you
> discover your users have subscribed to a mailing list, and DMARC is causing
> them pain, you enter the picture and amend your DMARC DNS RR to solve the
> problem which already has happened).
>
> On the other hand, if I am misunderstanding your proposal, please disregard
> this message.
Thank you for the question. I am sure many do not understand this mechanism.
Changes required for adoption of rfc6541 made deployment impossible, but can be
fixed when used in conjunction with DMARC. Both myself and likely Daniel Black
would welcome making any necessary changes to merge this mechanism with DMARC.
Regards,
Douglas Otis
_______________________________________________
dmarc-discuss mailing list
[email protected]
http://www.dmarc.org/mailman/listinfo/dmarc-discuss
NOTE: Participating in this list means you agree to the DMARC Note Well terms
(http://www.dmarc.org/note_well.html)
