On Apr 21, 2014, at 2:07 PM, Rolf E. Sonneveld
<R(_dot_)E(_dot_)Sonneveld(_at_)sonnection(_dot_)nl> wrote:
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>
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