On 4/9/2015 10:17 AM, Rolf E. Sonneveld wrote:
On 04/09/2015 03:24 PM, Anne Bennett wrote:
Hector Santos <hsan...@isdg.net> writes:

A database is still needed of which domains will have an
outbound mail stream with two signatures.  Some how the list domains
will still need to register with the Yahoos and tell the Yahoos,
"Please send us two signatures authorizing out list domain."    I
would like to call this a "registration" problem because thats seems
to be the area of disagreement as a real problem.

I have to agree; if this is the case, to me, it is a
show-stopper.  The genius of the DKIM and SPF and DMARC
approaches is that they are DNS-based, and thus completely
decentralized.  The idea that lists would have to register with
the e-mail providers of all of their contributors, or that I
as a (very small!) e-mail provider would have to figure out
what is and isn't a list, doesn't scale.

This can be solved by having the owners of mailing lists publish a
yet-to-be-defined DNS record in which they proclaim the presence of a
mailing list within that domain. I'm contemplating to write a draft
for this, as more than one of the  suggested solutions to the mailing
list problem might benefit from this.

Its either going to be a internal database or a public database, and with internal, we begin to have targeted sites (those without a database).

Having said that, I don't like the idea of designing all sorts of
auxilliary technologies to solve the problems introduced by DMARC, or
better said: if we'd come up with such helper technologies we should
try to address as many use cases, presented in [1], as possible. If we
do not, at the the end of the day we'll have created a myriad of new
technologies, considerably increased the complexity of the e-mail
ecosystem worldwide with a net result of zero as long as senders still
treat p=reject as p=none/quarantine.

/rolf

[1] https://tools.ietf.org/id/draft-ietf-dmarc-interoperability-01.txt

+1

Following john's example, he wishes for "taugh.com" to authorize "ietf.org" as a 3rd party signer. Using ATPS, he would create a DNS record:

   base32(sha1("ietf.com"))._atps.taugh.com

This would be it. The receiver will just check for this ATPS record. The only reason for the base32(sha1()) hashed subdomain was because there was a domain name length concern or some possible INTL character concern, as I recall. But I am not sure we need it, it would certainly remove API complexity when the record is simplified to:

     ietf.org._atps.taugh.com

In any case, this would be it.  The receivers will see:

  From: jo...@taugh.com
  To: dmarc@ietf.org
DKIM-Signature: ...; d=ietf.org; ... new good strong 3rd party signature

This provides the two variables for the DMARC+ATPS lookup:

   POLICY = DKIM_DMARC_ATPS(ADID, SDID)

We can't be using a DNS lookup as a reason for not using ATPS and continue to investigate these alternatives which have even higher overhead. In DMARC+ATPS, you would have 1 additional DNS lookup. With the @FS=1 lookup ideas, you also have 1 additional signature key lookup.

I agree that the "database" is the key issue here. But the above Protocol model is the same with a blackbox functionality where we have known inputs (ADID, SDID) and known outputs (ACCEPT, REJECT, QUARANTINE, DISCARD) we want to have. There are boundary limits here. All possible input and actions are known, including doing nothing.


PS: This is what we have for our authorized signers under my isdg.net zone:

e4qssg6j6f6vggflfwk56n6ppxlbglmu._atps TXT ( "v=atps01; d=megabytecoffee.com;" ) jchjykxmwknbyfge2bg4td6add264olh._atps TXT ( "v=atps01; d=winserver.com;" )
kjshf2duqstols65zbhuytbbyr3zdecf._atps TXT      ( "v=atps01; d=gmail.com;" )
n3lsehml2wgbfxov7hsak2qzsubsefhb._atps TXT      ( "v=atps01; d=mipassoc.org;" )
pq6xadozsi47rluiq5yohg2hy3mvjyoo._atps TXT      ( "v=atps01; d=ietf.org;" )
q42vdaxs6p26zflt3hcvqey3zp5aivxj._atps TXT      ( "v=atps01; d=isdg.net;" )
rni5mcktu7c46wfgxg4mhhnv4t62bi3y._atps TXT ( "v=atps01; d=mapurdy.com.au;" ) tudfisabn5dz3vjm2kxcehc5attdbqh6._atps TXT ( "v=atps01; d=santronics.com;" )

Is it really a DNS concern these days if a textual zone file has 30k or 50K subdomain records? Is it a limit due to their text editor? I'm sure a GUI will help, but the text guys are still going to popup their editor too. Is that still a problem today? I don't think so. New tools can be written to automatic the process. This should not be a DNS or Configuration/Setup limitation issue.


--
HLS


_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Reply via email to