NOTE: This thread is clearly off-topic with respect to publication. Yet, it
may help convergence toward a community vision of the possible future of DMARC,
which, in turn, can help finding out a statement about today's limits of DMARC,
its interoperability damage, and From: rewriting.
On Sat 22/Apr/2023 15:53:40 +0200 Jesse Thompson 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?
The local part of an email address has always been something that can be
understood only inside the domain it belongs to. Then, it is true that the
<local part, domain> pair can be used as a globally unique identifier.
However, publishing lists thereof, so as to allow their global interpretation
breaks the premise.
Here's what I see in the real world:
* Organization's policy dictates "use a subdomain" for non-general-purpose use
cases.
Some organization choose cousin domains instead of subdomains, e.g. yahoo-inc.
* 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.
Sometimes a subdomain is used for functional requirements, such as using
different mail servers. Other times it can be categorized as DMARC damage.
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
The substantial difference is that every MLM subscriber can post, while ESP
communication is one way. In addition, even it both ESPs and MLMs presuppose
user's opt-in, verification mechanisms usually differ.
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.
Yes, it is applicable. But ESPs are also characterized by featuring an
appointment by the domain owner. Sender-side authorizations, for example
publishing the ESP's public key in a purposely created appointer's subdomain,
take advantage of that.
"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?
Interesting point. Address portability by forwarding does not actually change
the subscription address, so you end up with two agreements. The first is the
former domain agreeing to trust a ML where the user subscribed. The second,
more critical, agrees to trust MLM messages that the former forwards. These
are likely failing DMARC, possibly having a sensible From: domain. In that
case, the final receivers could face an ARC chain of two sets, having:
Arc-Authentication-Results: i=2; former-isp; dmarc=fail ...
That way the former ISP has a permit to send real phishing. The final mailbox
provider must really trust the first. Perhaps, the ability to recover a
percentage of the author's domain DKIM signatures, albeit not a reliable tool,
can play a role in reinforcing that trust.
Best
Ale
--
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
