If a vendor wants to serve a customer, he needs to provide a product that
the customer can use. I don't see that it is IETFs problem to worry about
a vendor with an inadequate email platform, especially since DMARC has been
around awhile.
But I have been thinking further about the constrained delegation issue.
The general goal, at least for a single mailing is:
User2@Domain2 needs to be authorized to email for User1@Domain1.
DKIM authorizes anyone with the private key to email for anyuser@Domain1.
The domain owner has to worry about multiple things:
- Unauthorized Use For: Will domain2 will use the key for any messages
other then User1@Domain1?
- Unauthorized Use By: Will Others@Domain2 use the key for
User2@Domain2?
- Theft: Will be stolen and used by HostileUser@HostileDomain.
Adjusting delegation:
- Hector's ATSP proposal limits the delegation to Domain2.
@HostileDomain cannot steal the delegation, because the delegation only
works if a domain is authenticated by @domain1 and has signed the message.
For a high-sensitivity domain like @WhiteHouse.Gov, they may want to
require both: @Domain2 must have a DKIM private key for @Domain1
AND @Domain2 must have an ATSP delegation from @Domin1.
- DKIMs "I=" clause can be used to limit the "Use For". A signature
configured with "d=domain1; i=user1@domain1" should only authenticate
messages with "From: user1@domain1". This is an upward-compatible
change in the way DMARC interprets DKIM, not a layer violation of DKIM.
This could be used two ways: (a) possession of the private key permits
use to send on behalf of "user1@domain1", and (b) ATSP could provide
user-level delegation to only messages counter-signed by user2@domain2.
- Subdomains can be used to limit scope: Issuing a key for
@subdomain1.domain1 is more limited risk than issuing a key for @domain1.
- Subdomains with p=none can be used to allow a subset of messages to be
sent unauthenticated. In some cases, allowing @subdomain.domain1 to
operate unauthenticated may be perceived as lower risk than issuing a DKIM
private key.
The UseF
On Wed, Apr 19, 2023 at 10:30 PM Jesse Thompson <[email protected]> wrote:
> On Wed, Apr 19, 2023, at 12:35 PM, Alessandro Vesely wrote:
>
> On Wed 19/Apr/2023 15:37:25 +0200 Laura Atkins wrote:
> > To me it’s not so much the company can’t delegate authentication - it’s
> how
> > many SaaS providers (some of which are ESPs and some of which are 3rd
> parties
> > that send through ESPs) are incapable of supporting DMARC alignment. Not
> it’s
> > hard, not it’s challenging, but simply … can’t. They cannot sign with
> foreign
> > DKIM domains, and they cannot support different domains for SPF
> authentication.
> >
> > Should DMARCbis make the recommendation that if you are providing mail
> services
> > that you SHOULD be able to support corporate customers using DMARC?
>
>
> IMHO at least an appendix should say that if you can't do anything better
> you
> have to rewrite From: with examples of legitimate display-phrase,
> expanding a
> bit the first bullet in Section 11.4. That can also be a good place to
> explain
> the kind of damage DMARC causes.
>
>
> That's what I'm getting at. I don't really see any difference between a
> mailing list and someone providing mail services (I won't use the word ESP
> since that seems to be a loaded term) for corporate customers (I would also
> add government customers, who are adhering to BOD 18-01 in droves and they
> are also adopting said companies providing mail services)
>
> The choice for both the mailing list and mail-service company is to:
>
> 1) ignore DMARC and continue to emit mail as the original author intended
> (the author might be ignorant of DMARC too) and assume the mailbox
> providers are smart enough to understand that, like mailing lists,
> mail-service companies and their mail emitting authors shouldn't be caught
> up by a DMARC misdeployment by the domain owner
>
> 2) be cognisant of DMARC's effects, and in the interest of keeping the
> author's mail flowing, use a different domain and put the author's address
> in the friendly from or similar, or just refuse to accept the messages,
> until delegation can be set up.
>
> I can say, anecdotally, that people really really want #1 to be true, but
> they eventually learn #2 leads to a better long term outcome. I'd like that
> "learning" to be less painful by having something unambiguous to point at
> in DMARCbis.
>
> Jesse
> _______________________________________________
> dmarc mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/dmarc
>
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
