Here is an scenario I long envisioned with high-valued services implementing a DKIM Policy model.
Example: bank and a new online banking customer: Bank: "For online banking we need an email address for secured private email communications." User: "hmm, user.n...@esp1-domain.com <mailto:user.n...@esp1-domain.com>" Bank: "OK, let me check its security………please wait…." Bank does some DNS lookups and finds no DKIM POLICY record. At the time, it was SSP, ADSP, DSAP. Imagine today, the bank checks DMARC and finds no record for esp1-example.com <http://esp1-example.com/>. Bank: "I’m sorry, this email address is not considered secured. Do you have another?" User: "Yes, I have another.n...@esp2-domain.com <mailto:another.n...@esp2-domain.com> try that." Bank sees the domain has a SPF all? neutral policy and a DMARC p=none policy. Bank: "Mr. User, this email address is not secured for our secured banking needs with your new online account. How about we assigned you a new secured bank address. new.u...@secured-users.bank.net <mailto:new.u...@secured-users.bank.net>” User: "Ok, but wow, another address I have to remember?? Can I use my iCloud.com account? Bank: “iCloud.com is a secured domain. You can use that email.” So the user had the option to use a secure domain account or the user would be assigned one by the service. That’s how I saw it high-value transactions and companies moving, That special address MAY BE a 3rd party too bank authorized via ATPS. The unsecured domain ESP user simply can not be used with private services where the data exchanges need to be 100% transported authenticated and authorized. The current practice with the majority of MLM, at least as I experienced with then IETF list, break the security in the name of not stopping the mail flow. --- HLS > On Apr 22, 2023, at 9:53 AM, Jesse Thompson <z...@fastmail.com> wrote: > > On 4/22/2023 6:20 AM, Alessandro Vesely wrote: >> 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. > Does it bloat DNS more than DNSBLs do? Would it make more sense if it were > done via HTTPS? > > Here's what I see in the real world: > * Organization's policy dictates "use a subdomain" for non-general-purpose > use cases. > * Legacy non-general-purpose use of the org domain is tolerated because there > is no easy migration path. > * People within the organization instinctively want to use the org domain. > * They're very confused how it works technically, they try to pull strings to > get what they want. > * Eventually a person high enough in the organization intervenes. > * So, the domain owner has no choice but to authorize the ESP to use the > entire org domain, yet again. > > Why is it improper for a domain owner to have an ability to delegate > per-user? I understand that it may be technically infeasible, but why is it > improper? > > I'm still not certain why ESPs are fundamentally different than mailing lists. > ESP: A message author confirms their identity with the ESP and asks the ESP > to emit mail with their rfc5322.From address > MLM: A message author confirms their identity with the MLM and asks the MLM > to emit mail with their rfc5322.From address > > > >> 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/ > > A scheme like this seems just as applicable to ESPs as it does mailing lists, > insofar as mutual consensus of confirmed opt-in can be achieved between all 3 > parties. > > >> "Upon user confirmation, that MTA itself confirms the subscription to the >> MLM." > > Since you mentioned this enables address portability: If the user changes > mailbox providers, how do they communicate all of their prior confirmed > subscriptions to the MTA? How does the MLM know if the confirmed > subscriptions have not been back-filled? > > Jesse > > _______________________________________________ > 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
