Re: DMARC and yahoo

Douglas Otis <doug.mtview@xxxxxxxxx> · Mon, 21 Apr 2014 18:16:36 -0700

On Apr 21, 2014, at 2:07 PM, Rolf E. Sonneveld <R.E.Sonneveld@xxxxxxxxxxxxx> wrote:

    Hi, Doug,

      On 04/21/2014 09:20 PM, Douglas Otis wrote:

      On Apr 21, 2014, at 9:42 AM, Dave Crocker <dhc@xxxxxxxxxxxx>
      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.

Dear Rolf,

Sorry, I thought the scheme was easy to understand.

The basic white-list hash-label publication scheme is a single and small DNS query referenced at a _tpa subdomain within the sender's domain in much the same manner _dmarc  and other policy schemes operate.  RRs TTL can be set at levels that provide sustainable query burdens.  DNS can also scale using anycast and support very high query rates.  DMARC senders would need to publish their white-list indicating support of this protocol and of course it could also be signaled within DMARC.  Since this list offers a low overhead service for recipients there should be quick implementation at the other end of the exchange by recipient ESPs.  This also affords senders full control over all of their desired policy exceptions. If there is a problem, senders would only have themselves to blame.

Please note, MLM software or From header fields do not change at all.  The major portion of the effort would be by sending domains having a goal of offering better protection while preserving desired use.  The white-list can also be shared with other DMARC domains who trust the list's administration. Technically, this should be seen as a change to DKIM and SPF in a similar manner as ATSP did.  Of course, the change can be appended to existing processes.  There were necessary elements missing from ATPS which also required DKIM signatures to change that made deployment impractical.

    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?

At one time, we provided a reputation list that answered that very question, but there has not been a need for the MLM list for several years now.  If a sender receives any report of abuse, they can notify the list.  If there is not a timely response, the MLM can be de-authorized by the sender. Quick and painless.

    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.? 

Perhaps senders could ask their users which MLM they wish to use.  They could also monitor their DMARC feedback as well.

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...

There is nothing wrong in having all the trusted MLMs listed to then permit list to list traffic.  It would not involve any complex changes to message signing or header field use either.   Use of TPA would have dramatically lower overhead than that caused by reverse DNS queries or that of chained SPF records. 

Regards,
Douglas Otis