On 4/14/2015 10:07 AM, Scott Kitterman wrote:>
If I misunderstood the proposal and it requires someone to be keeping a list
of mailing lists used (either globally or by individual users), then I think
this is not a good idea at all. I don't think any tracking/whitelisting
design is going to succeed at scale.
My view is that either we find a reasonable way to make this idea work without
a list of mailing lists or we toss it on the pile of things that won't work.
Which is why the simple DNS lookup remains to be the ideal baseline
and natural part of the generic DSAP (DKIM Signature Authorization
Protocol) design. You need to cover all process model boundary
conditions which include 1st and 3rd party mail streams. If you
exclude one, its incomplete.
The Publishing and "Registration" problem has been overblown.
Registration basically means to find the domains (your network of
signers) to publish. The latter is a business problem, not a IETF
technical protocol problem. If we had used a "registration/scale
problem" philosophy for other early IETF protocols, they were have
never been completed as well and gotten to where we are at now. SPF
has this same scale concern, and it still currently an extremely high
wasteful DNS calling authorization check method for senders. The
larger domains also had to "find" their network to register them as
SPF machines. So this is not any different.
The DNS "Lookup" algorithm has been the basic backbone idea since
2003, since LMAP ideas, since DNSRBL, since MAPS, well since forever,
etc, the idea of "Looking up" an verified, integrity authenticated id
for authorization, either its for bad or good, it became fashionable
and an acceptable concept overtime by the DNS community. They bemoaned
it but the DNS TXT-BASED applications was on the raise as an fast
entry method to explore many new authorization ideas.
We tried to get the "Good Signer" (SDID) lookup with the DKIM STD
work. It didn't happen in the
market place (it has issues that included the "Batteries Required"
syndrome) and even if it did happen, the "Good Signer" methodology did
not cover rudimentary DKIM signing failures checks (including missing).
In all cases, you need a 3rd party Authorization list somewhere,
whether everyone needs one or not, some will, some won't. That again
is also a implementation and business decision. You can, in theory,
have a more relaxed Signer Engine that double signs all mail or maybe
under some rule that allows only outgoing LIST domains to be double
signed. In all cases, this in-band method is still a registration
concept, global or selective.
The problem has been that some believe everyone will have this a huge
need to "register" many domains, and IMV, this erroneous idea has
crippled the completion of all DSAP protocols (SSP, ADSP, DMARC).
No, only a few have such "registration" issues, whether thats a
million or so, it still a small piece of the total domain space. We
won't know how many for sure, but I have a pretty good feel the
majority of domains will not need such large "list" needs.
How many will you have to collect? I have 10.
e4qssg6j6f6vggflfwk56n6ppxlbglmu._atps TXT ( "v=atps01;
d=megabytecoffee.com;" )
jchjykxmwknbyfge2bg4td6add264olh._atps TXT ( "v=atps01;
d=winserver.com;" )
kjshf2duqstols65zbhuytbbyr3zdecf._atps TXT ( "v=atps01; d=gmail.com;" )
LYKM653KJ7YXEIA665VA7LSZZTHCX7JJ._atps TXT ( "v=atps01;
d=beta.winserver.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;" )
ni5mcktu7c46wfgxg4mhhnv4t62bi3y._atps TXT ( "v=atps01;
d=mapurdy.com.au;" )
tudfisabn5dz3vjm2kxcehc5attdbqh6._atps TXT ( "v=atps01;
d=santronics.com;" )
Are we saying that MOST systems will not be able to handle their
Network of known signers?
As stated above, this issue is no different than with SPF where larger
networks had to learn their network of senders and even then, many
still use weak/relaxed policies (~ALL, ?ALL) lowering the payoff of
the redundant calls with no actionable results, indeterminate
conditions - a high waste most of the time.
The MLM or the site mail receivers just needs to make sure it does a
ADID/SDID check. If the WG wants to spend time on a weaker more
complex double signature "in-band" solution because the DNS
administrator is no longer needed, that still doesn't mean that this
design will be acceptable to all. The weaker alternative is more
code change and if you can avoid code change, the better. DMARC
SHOULD offer the more ideal and simple DNS lookup because it is a
natural part of the DNS lookup model that already exist for DMARC
which currently isolates itself to the ADID==SDID conditions and
automatically failures all other conditions.
--
HLS
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
