Scott,
If this is what you are talking about, there should of been an
AUTH-RES line for "atps=", I can understand that valid technical
point, but I don't agree it is absolute.
First, it is a DMARC extension and long as it is an indicated marker
in the DMARC result, then should be ok.
Second, related, one of the problems with AUTH-RES and the reason
there is so many changes to it, is because its doesn't quite satisfy
what an receiver might need. I had that problem with just adding ADSP
to it. It didn't even support getting SPF fully reported.
In other words, the dynamics are still changes in order to get a solid
AUTH-RES reporting header completed. In fact, if your point is taken
serious, then AUTH-RES will need even more updates to support other
results, such as the double signature proposal.
So this is a side issue that really has nothing to do with the overall
basic protocol issue we are dealing with, but it is a good note to
point out because you will run into the same "separation" issue with
any other additional layer you want to add on top of DKIM and into the
AUTH-RES header.
Thanks for the note.
On 5/7/2015 4:36 PM, Hector Santos wrote:
On 5/7/2015 4:27 PM, Scott Kitterman wrote:
On May 7, 2015 3:54:55 PM EDT, Hector Santos <[email protected]> wrote:
Since 05/2014, I have published DMARC records for several of my
domains. Our mail receivers supports ATPS (rev04) where "atps=y" tag
extension was added to my records. For example, for my non-corporate,
"play around" domain isdg.net, I have:
"v=DMARC1; p=none; atps=y; rua=mailto:[email protected];
ruf=mailto:[email protected];";
ATPS draft rev04 was written as a ADSP extension. With Rev05 and the
final ATPS rfc6541, ATPS was made an extension off the DKIM record
instead, not ADSP.
What I did was added ATPS support to the DMARC record as an 3rd party
Extension allowed by DMARC.
I am happy to report that after two years, there is no indication for
an interop problem. The unknown tag to non-supported ATPS receivers
does not interfere with the DMARC processing. The reports received
come from a wide number of domains.
I am also happy to report that the concept works very well in
authorizing third party resigners using the ATPS (rev04) protocol.
Here is an actual Auth-Res for a list message ietf.org resigner. I
put a divider line for better viewing:
Authentication-Results: dkim.winserver.com;
----
dkim=pass header.d=ietf.org header.s=ietf1 header.i=ietf.org;
adsp=pass policy=all author.d=isdg.net asl.d=ietf.org;
dmarc=pass policy=none author.d=isdg.net signer.d=ietf.org (atps
signer);
----
dkim=fail (DKIM_BODY_HASH_MISMATCH) header.d=isdg.net header.s=tms1
header.i=isdg.net;
adsp=pass author.d=isdg.net signer.d=isdg.net (originating signer);
dmarc=pass policy=none author.d=isdg.net signer.d=isdg.net
(originating signer);
The first bottom triplet results are for the original signature. It
fails the DKIM signature with a body hash mismatch. Both ADSP and
DMARC pass as original signers (author == signer). In reality, if the
rejection switch was enabled, this should be a FAIL because the
signature is invalid.
However, for the ietf.org list resigner triplet results, it passed as
an ADSP ASL resigner and ATPS record resigner (author != signer).
DKIM/ATPS (rev05) is part our Wildcat! SMTP component in our
commercial Application Hosting package used by customers in the field.
I think it's wrong to describe that as a DMARC result. For DMARC as
specified, that's a fail.
Oh, you mean, there should be a "atps=" auth-result? oK, I can buy
that but then again the AUTH-RES is for internal consumption not
external, having it a single source result to a DMARC result reader,
would be ok.
Nonetheless, the end result is the same, the ATPS would authorized the
resigner. No other DKIM signature related changes need.
--
HLS
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
