Re: DMARC and yahoo

Hi, Doug,

On 04/21/2014 09:20 PM, Douglas Otis wrote:
> On Apr 21, 2014, at 9:42 AM, Dave Crocker <dhc(_at_)dcrocker(_dot_)net 
> <mailto:dhc(_at_)dcrocker(_dot_)net>> wrote:
> > On 4/21/2014 9:36 AM, John Levine wrote:
> > > They could fix it if they
> > > wanted, e.g., by arranging to whitelist mail sources that don't match
> > > DMARC's authentication model but send mail people want.  This is not
> > > just mailing lists, of course.
> >
> > Sorry, but I'm not quite understanding what additional mechanism you 
> > have in mind.
> > Exactly who does exactly what?
> >
> > Who has to adopt it?
> >
> > How will it scale?
> Dear Dave,
>
> Each domain can simply point to their desired white-list. This can be 
> one published directly or simply referenced as described in:
> http://tools.ietf.org/html/draft-otis-dkim-tpa-label-06#page-8
>
> This has elements from the moribund ADSP.  The sender wishing to 
> protect a domain while also applying policy like that of ADSP or DMARC 
> can offer receivers a rapid and scalable method to check third-party 
> domain authorizations.  This means senders are always able to defend 
> recipients who trust messages from their domain.  Please note, 
> authorizations can also require presence of a List-ID.
This doesn't answer Dave's questions: who has to adopt it and how will 
it scale.
Adoption: of course the owner of the sending domain has to adopt it, but 
is there also a role for the owners of mailing lists, invite services 
etc.? How will the sending domain ever know whether a mailing list is 
open or closed for example? How will it know which invite services will 
need a TPA exemption?
Scaling: how does the owner of the sending domain (potentially very 
large numbers of users) know to what mailing lists its users are 
subscribed, what invite services will potentially need this TPA 
authorization etc.? Furthermore, will it scale if mailing lists can be 
members of mailing lists and how will the sending domain know about this 
hierarchy or chain of mailing lists? So the technical howto might be the 
easy part of the solution, while the organizational howto will 
definitely be the difficult part...
/rolf