On 5/7/2015 5:09 PM, Murray S. Kucherawy wrote:
On Thu, May 7, 2015 at 1:27 PM, Scott Kitterman <[email protected]
<mailto:[email protected]>> wrote:
I think it's wrong to describe that as a DMARC result. For DMARC
as specified, that's a fail.
More precisely, for both DKIM and DMARC it's a fail. For
DKIM+ATPS-04, it's a pass, but DMARC doesn't pay attention to that.
Now we are getting into definition and software engineering.
DMARC result is a PASS when it is an extension, and in this case, it
is an extension, and it is noted as an extension:
dmarc=pass policy=none author.d=isdg.net signer.d=ietf.org (atps
signer);
In other words, does the AUTH-RES protocol allow it itself to be
extended, it is flexible enough? If not, then AUTH-RES will need to
be updated again.
I think it's also important to note that this only proves
interoperability with a single implementation (granted, in multiple
roles),
Running code.
unless there's data indicating multiple implementations are
involved.
The more the merrier, but it is running code.
This seems unlikely, since as far as I know there aren't
any other implementations of ATPS-04 or even the RFC version.
OpenDKIM did the RFC version, and it's not compatible with -04.
I wish I was there to "protest" making it extend off the DKIM code
which required a change to it. That is enough reason to not support
it. I wouldn't either. That should be noted.
Also, this is only part of the whole story. There's still that pesky
registration problem to address.
Separate issue. SPF would not be here if you used this same criteria.
None of the big domains you are concern about have hard fails for SPF
for the same reason -- it can not "register" their SPF network of
possible users. Same problem. Didn't stop SPF from moving forward,
first externally, and then as an IETF "experiment" because making it
a "proposed standard" back then during MARID would of cause much protest.
I think for ATPS or anything like it
to be considered a plausible thing to pursue, that's critical.
Its important for its success, but I don't buy its a problem nor
should it be barrier to establish the DNS-base protocol. DNSSEC is
problematic for the same reasons (lack of record support) Don't stop
people from moving forward with it despite its pretty much useless to
the general market as a whole.
It
might be interesting to know some of the characteristics of the
largest operator involved in that report (total domains, total users,
details about MLM traffic, etc.).
It would be interesting but I don't think that proves anything whether
it was a million, thousand or just one -- Dimensional Analysis is
applicable.
When you design the protocol properly, it applicable to all sizes.
Thats the mark of a good IETF protocol -- it doesn't choose size and
its doesn't create conflicts of interest. You and scott don't believe
it is and I believe that is somewhat hypocritical of the fact that SPF
has the same exact registration issue that prevented many of the
larger public service domains from using the "-ALL" policy.
Whatever is done, you will always need the "Data" but you need the
protocol in place and by far, the most feasible way to do this, is by
leaving DKIM alone and work on the policy layer. If the alternative
requires DKIM changes for the same purpose and you going to nix ATPS
and go with some double signature method, I think it is necessary from
an IETF standpoint that you also offer the baseline solution which is
the DNS call method.
--
HLS
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
