We need to update DMARC or any other DKIM Policy proposal to seriously
consider 3rd party signature Authorization methods.
We have wasted so much time avoiding it. Sure, it may not apply to
all, but neither does DMARC and the push to embed a "half-baked" DMARC
into our mail network has created a market of kludges and new security
problems with the endorsement of the horrible RFC5322.From rewriting
and the creation of a super complex, solve nothing, ARC concept.
The DKIM Policy needs additional tags, call it "aim=" if you like,
thats publishes and publicly exposes the following ideas:
1) Look, I really mean it, p=reject means NO rewriting. Reject!!
2) Eh, we are flexible, please allow following domains; ietf.org,
resign our mail. If you see "ATPS=1" that means we support
3rd party signatures from specific and exclusive domains.
3) Please do not bypass 1 and 2 and perform a RFC5322.From destruction
and rewrite violating our published policy and the intent of having
DKIM Policy for exclusive mail operations. However, if you see a
"rewrite=1" tag, then we don't mind if you rewrite the RFC5322.From
field IFF the resigner has an exclusive policy.
Simple!
Nothing will satisfy everyone. Not DMARC or even a ATPS or TPA or
even the DKIM Conditional Signature draft proposal.
But we need to offer it to the market to see how it will work. It has
already been proven that it
works. My package does not allow restrictive domains to sign up to
mailing lists, not can existing subscribers can post into the list. It
becomes an Read-Only list for them. I am not going to Rewrite. I
want to sleep at night. But if ATPS or something like is supported, I
am extremely confident it will give DMARC an immediate security boost.
I am still around here because I have a strong feeling someone more
important than me, Maybe Valimail or some other, maybe even google,
will eventually get the "Ah Ha" and say "hmmm, there might be
something here, let's explore it. It may not work for all domains,
but I see where it can have it place with other domains." If these
companies, who have such a high investment and product dependency on
DMARC as a business, I have been scratching my head why their Project
and/or Product R&D guy is not exploring ATPS which exist today.
Those wishing to explore ATPS, use this wizard and simulator:
https://secure.winserver.com/public/wcDMARC
--
HLS
On 5/11/2020 1:21 PM, Alessandro Vesely wrote:
Hi all,
consider the famous incipit:
DomainKeys Identified Mail (DKIM) permits a person, role, or
organization to claim some responsibility for a message by
associating a domain name [RFC1034] with the message [RFC5322], which
they are authorized to use.
The question is, what responsibility is being claimed? Some sites allow
authenticated users to use any From:, but are able to find out who the actual
author was, if needed. Other sites only sign if the From: matches the actual
user, or at least its domain part. Still others just sign everything.
Discussions about what kind of assurance would a signature imply are rather
frequent. At least, specifying an aim= tag should shred some light on the
various possibilities.
Tagging keys with aim= would allow senders to choose an appropriate selector
under different circumstances. Some mail sites use different sending IP
addresses to meet a similar purpose. Others use different domain names, opaque
chunks of base64 data, or X-Google-DKIM-Signatures. An aim= would serve a
similar purpose in a more open manner, introducing yet another means to discern
among different mail flows.
Comments?
_______________________________________________
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim
