Re: [dmarc-ietf] Is From spoofing an interoperability issue or not?

[Douglas Foster <[e-mail]>]

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 <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dmarc
>