On 4/20/2023 6:34 AM, Douglas Foster wrote:
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 <z...@fastmail.com
<mailto:z...@fastmail.com>> 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
The only technical requirement for the "i=" tag is for the User Agent
Identity (UAID) to equal the ADID (Author Domain) (don't recall
without looking at code).
The assessment equation extractable by reading DKIM-BASE is:
Assessment = ASSESSOR(SDID, UAID="")
where the UAID is optional.
I argued during the drafting of DKIM-BASE to add back ADID by passing
the ADID with SDID which is how the original DKIM modeled it:
Assessment = ASSESSOR(ADID, SDID, UAID="")
Unfortunately, I was the only DKIM Policy advocate objecting to
DKIM-BASE trying to, as its abstract says:
DKIM separates the question of the identity
of the Signer of the message from the purported author of the
message. Assertion of responsibility is validated through a
cryptographic signature and by querying the Signer's domain directly
to retrieve the appropriate public key.
So not even this backward compatible assessment was acceptable to have
in the DKIM-BASE standard.
Assessment = ASSESSOR(SDID, UAID="", ADID="")
For many here, the reputation of the signer trumps everything. I
don't think the DKIM Policy advocates ever disputed the need for
reputation but as a final layer, not the first layer.
This is why we have had 17 years of a DKIM Policy vs DKIM Reputation
modeling conflicts in the DKIM-related working groups. Just keep in
mind we have no public domain, not proposed method to do a SDID only
assessment. But we certainly do have a several ADID::SDID assessment
proposals!
We can't totally separate the ADID from the any SDID assessment. The
Author ADID, From: header, is the only required header to be hashed
bound to DKIM-Signature. It is impossible to be separated from
consideration, and the irony is, if the assessment of the signer is
negative, it is the Author address, its MTA, its delivery agent
(return-path) who gets hurt.
ADID can not be separated. It is a complex situation when you are
dealing with unsolicited mail when ADID does not equal SDID. This is
why DMARC can only focus with a ADID=SDID policy.
Now throw in the UAID and we have additional, complex, extended
policies to deal with. We don't know how to use it, optimally,
especially for a mailing list where thousands of emails need to be
signed. Do you sign 1 list distribution for all or do you sign each
list outbound message? Those are big scaling optimization
considerations.
For the most exclusive policy, via DMARC:
p=reject; adkim=s; aspf=s
everything must match.
for:
p=reject; adkim=r; aspf=r
A little more relaxed for subdomains.
I think what is there is enough for this limited policy which does not
care for users using the domain outside the main stream.
--
Hector Santos,
https://santronics.com
https://winserver.com
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
