On 11/3/2016 7:30 AM, Benny Pedersen wrote:
Hector Santos skrev den 2016-11-02 21:05:
ADSP/ATPS actually works very well. Its been in production for a
number of years. I have "ietf.org" as a 3rd party signer assigned to
my ATPS records in DNS. Supportive receivers can then see that I
authorize ietf.org to sign my IETF submissions as my receivers do when
I get a copy. My ADSP record for isdg.net is:
dkim=all; atps=y;
asl=ietf.org,beta.winserver.com,santronics.com,isdg.net,winserver.com,megabytecof
fee.com,mapurdy.com.au,mipassoc.org,gmail.com,googlegroups.com;"
Authentication-Results: linode.junc.eu; dmarc=none header.from=isdg.net
Authentication-Results: linode.junc.eu;
dkim=pass (1024-bit key; secure) header.d=ietf.org
header.i=@ietf.org header.b=vqpaROA9;
dkim=fail reason="signature verification failed" (1024-bit key;
unprotected) header.d=isdg.net header.i=@isdg.net header.b=twhXt8L/;
dkim=fail reason="signature verification failed" (1024-bit key;
unprotected) header.d=beta.winserver.com header.i=@beta.winserver.com
header.b=ubq9bnhD;
dkim-atps=neutral
so it works ?
yes.
So, my original isdg.net message was submitted to my
beta.winserver.com submission server. It was DKIM signed
(d=beta.winserver.com) which then gets routed to my isdg.net machine,
signed again (d=isdg.net) and sent to ietf.org.
The ietf.org list manager destroys my submission integrity by changing
the subject line, adds a footer, etc, as most list systems has done
for many years, thus destroying the first two DKIM signatures.
The DKIM compatible LIST server then properly resigns with d=ietf.org
as we want all list servers to do when they destroy data as long as
the original signatures were valid before it does so (but I doubt the
IETF list server has that logic). It just blindly resigns and begins
to distribute the mail.
Now it gets to a list downlink receiver with ADSP/ATPS support. The
receiver sees at least one valid signature, d=ietf.org and checks the
isdg.net author domain ADSP/ATPS record to see if ietf.org is authorized.
If ietf.org was not in the short asl= list, a ATPS record lookup is
done for in the author-domain zone:
atps-hash("ietf.org").author-domain
yes, it works very well.
The concern has always been how do you "learn" your personal community
of "authorized" 3rd party domains who are allowed to sign on your
author domain behalf. We (or at least I) have called that the
"registration" problem. So it has a scale issue, but I think it
definitely works for the small to mid size individual and/or
organization which is the majority of the market place.
I would like to see adding support to the DMARC record for ATPS
support, i.e. "atps=" and possible also an option for a short
"asl=domain list."
ATPS was an add-on for the then "proposed standard" but not abandoned
ADSP proposal. DMARC had effectively replaced "ADSP" but oddly it
decided to not deal with the 3rd party signer designs leaving us in
limbo for many years and hence the problem you are seeing today.
I added ATPS support to my DMARC implementation, so my DMARC record has:
v=DMARC1; p=none; atps=y; rua=mailto:dmarc-...@isdg.net;
ruf=mailto:dmarc-...@isdg.net;";
with the "atps=y" tag and I can attest that after a few years, there
is no DMARC processor breakage that I am aware of using the "foreign"
extension tag as DMARC allows per specification.
--
HLS
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
