On 6/4/2020 6:31 AM, Douglas E. Foster wrote:
MAILING LISTS.
The mailing list problem can be stated as follows:
* Domain B wants to operate a mailing list.
* The list owner will accept messages from domain A, alter them,
then re-transmit the altered message to member C.
* List owner B wants the mail filter for member C to guarantee that
his list messages are granted the same trust level as a message
sent directly from A to C without alteration.
This problem is unsolvable because it is unreasonable.
Hi Douglas
-1. I have to respectfully disagree with this.
Using the proper protocol, Domain A can reasonably declare, with
certainty, to explicitly and deterministically authorize the Domain B
resigner where the Domain C receiver can verify whether Author Domain
A 3rd party policy allows Domain B to resign.
It is done with DMARC with the add-on ATPS by adding an extended tag
"atps=y" to your DMARC record. My DMARC record for my domain isdg.net is:
v=DMARC1; p=reject; atps=y; rua=mailto:dmarc-...@isdg.net;
ruf=mailto:dmarc-...@isdg.net;";
The isdg.net domain zone has authorized the following domains with the
ATPS records:
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;" )
rni5mcktu7c46wfgxg4mhhnv4t62bi3y._atps TXT ( "v=atps01;
d=mapurdy.com.au;" )
tudfisabn5dz3vjm2kxcehc5attdbqh6._atps TXT ( "v=atps01;
d=santronics.com;" )
It works very well. If you wish to explore this, this wizard is
available:
https://secure.winserver.com/public/wcDmarc
Use the simulator in the wizard to show proof of concept.
The options for creating trust in indirect mail have been discussed in another
RFC.
Which one?
With the exception of VBR, I am not aware of any IETF-based Signer
Domain DKIM Trust/Vouching Protocol. Until we have a 3rd party
authorization system in play, the Signer Trust can not be established.
It would be unreasonable for Domain C to blindly use some unknown
Trust Authority to all incoming domain As coming from Domain Bs. On
the other hand, if the Domain A, explicitly said something in the
DMARC record such as:
v=DMARC1; p=reject; trust=trust1.example,trust2.example; .....
Then Domain C can check for some "trust" protocol where it will look
up poll a trust service, trust1.example or trust2.example. Maybe the
trust service will give DOMAIN A some zone records specific to the
trusted resigners. Either way, the process model would be:
trust.result = DKIM_TRUST(Author.Domain, Sender.Domain[,
User.Agent.Identity])
Is this unreasonable? I don't think so, but we don't have it. Again,
VBR is similar to this. It has a lookup method where you combine the
author domain with the signer domain plus other spam-based tags
specific to the type of mail, or something like that.
Note, it was always my technical opinion, DKIM std incorrectly
attempted to remove the Author Domain Identity from the DKIM base
protocol, but instead it attempted to replace the DKIM Policy model
was a DKIM Trust model, so the process prototype would be:
trust.result = DKIM_TRUST(Sender.Domain[, User.Agent.Identity])
But as expected, this trust model never materialize but instead the
self-signing DKIM Policy model was too strong to eliminate from the
DKIM picture. Add ATPS or a similar 3rd party authorization protocol,
and we will get a lot further than we have been since DMARC replaced
ADSP without addressing and resolving the 3rd party resigner issue.
Finally, my DKIM modeling contention has always been, DKIM is a two
pass layer model:
- Pass 1, DKIM Policy check using the Author Domain
- Pass 2, iff pass 1 is successful, check the signer domain trust.
I believe that is what the DKIM Service Overview attempt to depict, by
combining two assessment inputs - signing practice/policy and trust info.
DomainKeys Identified Mail (DKIM) Service Overview
https://tools.ietf.org/html/rfc5585#page-14
--
Hector Santos,
https://secure.santronics.com
https://twitter.com/hectorsantos
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
