Doug,
>>>
The basic concept is to permit a scheme where not every domain needs to
separately publish a list. Their domain at their "_tpa" leaf could simply
reference another domain that tracks third-party abuse. In general, someone
(perhaps the community or Yahoo in this case) would need to make that effort.
<<<
This is more or less John Levine's suggestion from several days ago: it is a
whitelist. The difference here is that policy is queried via DNS (along with a
different alignment than the From: addres) rather than distributed and applied
internally as a domain/IP DMARC exclusion list.
The technical implementation of this is not that difficult, I don't think.
Instead, I think the biggest obstacle is who signs up to maintain and support
such a list, perhaps indefinitely.
-- Terry
________________________________________
From: Douglas Otis <doug.mtv...@gmail.com>
Sent: Tuesday, May 06, 2014 6:20 PM
To: Terry Zink
Cc: dmarc-discuss@dmarc.org
Subject: Re: [dmarc-discuss] DMARC woes - forwarding signed / encrypted e-mail
On May 6, 2014, at 6:04 PM, Terry Zink <tz...@exchange.microsoft.com> wrote:
>> Dear Terry,
>>
>> A few of us hope to be publishing a draft aimed at safely extending
>> third-party authorizations in a highly scalable fashion that answers these
>> questions. Replace the l= with tpa=(yes, no); The tpa entry can then apply
>> additional restrictions in the hashed-accessed resource record used to
>> authorize a third-party domain. This might involve list-id header
>> alignment, etc. Since this scheme can be generalized, it seems the
>> "{hash-label}._tpa" resource should include related protocols as well. In
>> this way, if there is any abuse, the Author-Domain from DMARC's perspective
>> will not enable just any message with a list-id header or those purporting
>> to be from a mailing-list. This also removes replay concerns, since the
>> Author-Domain is able to delist any third-party domain failing to respond to
>> reports of abuse.
>>
>> There would be an additional benefit beyond restoring use of third-party
>> services. When requested policies are used in conjunction with user
>> accounts, the fact that their account has been disabled to prevent delisting
>> would act as a type of notification that the user's account or system has
>> become compromised. Just as your organization does, we also offer free
>> cleanup tools to assist when their system is affected. Otherwise users
>> should be able to simply change their account passwords and security
>> information. Perhaps we could even standardize the forwarding of cleanup
>> results to help facilitate service restorations.
> Doug,
> A few of us hope to be publishing a draft aimed at safely extending
> third-party authorizations in a highly scalable fashion that answers these
> questions. Replace the l= with tpa=(yes, no); The tpa entry can then apply
> additional restrictions in the hashed-accessed resource record used to
> authorize a third-party domain. This might involve list-id header alignment,
> etc. Since this scheme can be generalized, it seems the "{hash-label}._tpa"
> resource should include related protocols as well
> <<<
>
> How would this work in real life? Would Yahoo need to publish in DNS a list
> of all the mailing lists their users subscribe to?
Dear Terry,
There is a serious compromised system/account problem that needs to be
mitigated in some fashion. The basic concept is to permit a scheme where not
every domain needs to separately publish a list. Their domain at their "_tpa"
leaf could simply reference another domain that tracks third-party abuse. In
general, someone (perhaps the community or Yahoo in this case) would need to
make that effort. When the TPA scheme is used in conjunction with the
application of requested DMARC alignment policy, nothing would need to change
in any of the third-party services. This seems like a win-win for all those
involved without introducing any excessive overhead.
Regards,
Douglas Otis
_______________________________________________
dmarc-discuss mailing list
dmarc-discuss@dmarc.org
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)
