Those kinds of sender-side authorization schemes seem to be designed for
ESP-like businesses, where a domain owner delegates Domain2 to send messages on
its behalf. Using such schemes for mailing lists, thereby going down to
per-user records sounds improper and bloats the amount of DNS stuff.
To address mailing list and forwarding for address portability, I'd rather
devise receiver-side schemes, whereby the final receiver acknowledges that the
email address of a user of its has been written to a file that produces mailing
list of forwarding effects, while the author domain is not involved at all. A
very rough idea here:
https://datatracker.ietf.org/doc/draft-vesely-email-agreement/
Best
Ale
--
On Fri 21/Apr/2023 00:24:56 +0200 Douglas Foster wrote:
Murray's ATSP proposal (https://www.ietf.org/rfc/rfc6541.txt
<https://www.ietf.org/rfc/rfc6541.txt>) and Hector's DSAP proposal
(https://datatracker.ietf.org/doc/html/draft-santos-dkim-dsap-00
<https://datatracker.ietf.org/doc/html/draft-santos-dkim-dsap-00>) have a
similar goal: Allow "Domain2" to send authenticated messages for "Domain1".
This is authorized when
* the message is signed by "Domain2" and
* a DNS entry in "Domain1" is configured to authorizes "Domain2" as a
delegated signer.
(I will use RFC6541 as my primary reference because it seems to have avoided
scaling problems.)
A mailbox account owner cannot benefit from these ideas because he needs the
ability to define a user-authorizes-domain or user-authorizes-user
relationship. Consequently, we should extend the RFC 6541 design to support a
subkey of the form:
<hasheduser>._users.<hashed-domain>._atsp.<parent-domain>..
Query sequence:
* The initial query is for an ATSP policy at
<hashed-domain>._atsp.<parent-domain>. If it returns a result that
authorizes the signatures, the search stops.
* If the query returns NXDOMAIN, no further search is needed because the
_users subkey does not exist.
* Otherwise, a second query is performed for an ATSP policy at
<hasheduser>._Users.<hashed-domain>._atsp .<parent-domain>. If a valid
result is found, the signature is also authorized. T
The DNS entries for user-level authentication would be created automatically by
the mailbox provider upon request from the user.
This approach gives the mailbox provider the ability to control which delegated
domains are allowed. If a third-party signer is badly behaved, the mailbox
domain could remove all of its delegated signing entries and prevent new ones.
A potential downside is that the mailbox provider could use this power to
limit third-party signing to its favorite sister companies or favorite business
partners, possibly in exchange for payment or other favorable actions.
This approach is also a path forward for the mailing list problem. If a
user's domain implements user-level ATSP delegation of signing rights, each
subscriber documents his participation in the mailing list by requesting a
user-level delegation for the list server's domain.
The mailing list can easily check the ATSP entries for its subscribers to see
if delegated signing authority has been granted. The greater difficulty is
knowing whether recipient domains implement support for the concept. But the
design does not require mailing lists to make any changes to benefit from the
design, which has been a big obstacle to other concepts.
What are the objections?
Doug Foster
.
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
