On Tue 19/Mar/2024 12:33:07 +0100 Scott Kitterman wrote:
On Tuesday, March 19, 2024 5:23:52 AM EDT Alessandro Vesely wrote:
On Mon 18/Mar/2024 21:37:02 +0100 Scott Kitterman wrote:
> On March 18, 2024 6:40:54 PM UTC, Alessandro Vesely <ves...@tana.it> wrote:
On Mon 18/Mar/2024 09:14:26 +0100 Dotzero wrote:
On Mon, Mar 18, 2024 at 2:38 AM John R Levine <jo...@taugh.com> wrote:
On Sun, 17 Mar 2024, Dotzero wrote:
Whenever mail is sent, there is a risk that an overly permissive source
may send mail which will receive a DMARC pass result that was not, in
fact, authorized by the Domain Owner. These false positives may lead
to issues when systems interpret DMARC pass results to indicate
a message is in some way authentic. They also allow such unauthorized
senders to evade the Domain Owner's requested message handling for
authentication failures.
I have a problem with this 2nd paragraph and believe it is factually
incorrect. The Domain Owner has in fact authorized the message(s) as
a result of an overly permissive approach. I would suggest that in
fact any resulting DMARC pass is technically NOT a false positive
because it is authorized by the overly permissive approach.
Seems to me we it depends on what you think "authorized" means. My
sense is I told you it's OK to send the message, yours seme to be that
any host on an IP in the SPF record or anyone who steals your DKIM key
is authorized by definition.
Is there some other wording that can make the difference clear?
Here's a quick stab at some modified wording for the second paragraph:
Whenever mail is sent, there is a risk that an overly permissive source
may send mail which will receive a DMARC pass result that was not, in
fact, intended by the Domain Owner. These results may lead
to issues when systems interpret DMARC pass results to indicate
a message is in some way authentic. They also allow such unauthorized
senders to evade the Domain Owner's intended message handling for
authentication failures.
That's better. At least it's formally correct. Still, it is rather
obscure for an average reader.
The attempt to make this issue general, in the sense that it is valid for
SPF and DKIM alike, makes no sense. Stealing a DKIM key is not
comparable to an overly permissive SPF record.
The text should be terser and clearer, possibly with an example.
No one said anything about stealing a DKIM key.
"anyone who steals your DKIM key is authorized by definition"
https://mailarchive.ietf.org/arch/msg/dmarc/h_ytb51KHHkQTyCMfGMs9NPXmQo
OK. That's not what I described. Here's a more detailed exposition.
Let's take a case where a provider sends mail on behalf of multiple customers,
for whatever reason. Customer A uses example.biz and customer B uses
example.com.
When the provider receives an email for transmission on behalf of a customer
it has to determine if it should send it or not, so it has controls in place.
First, it determines if the mail was submitted by a customer and in our
example it is, but it is Customer A sending the message, but the 5322.From in
the message is in example.com. At this point a well managed provider would
exercise another control and determine that while Customer A is a customer and
example.com is a domain for which they send mail, Customer A is not authorized
to use example.com and decline to send the mail.
In the cases people have described seeing, the provider does not have such a
control and sends the mail. Since Customer B has listed the provider's MTAs
in their SPF record, if the provider sends the mail, it passes SPF (and
DMARC), which is bad.
Let's take that a step further:
Customer B, realizing that this provider is not so well ordered uses the "?"
qualifier in example.com's SPF record, so the mail doesn't pass SPF (and DMARC)
any more. This is great, except:
Let's look at the case where this provider also does DKIM signing for their
customer's mail and have arranged to have secret keys for signing mail for
both example.biz and example.com and both Customer A and Customer B have
published DKIM key records in DNS for their domains.
Is this a common pattern?
So, again, Customer A is sending mail through the provider with 5322.From of
example.com. We've already established that the provider does not have a
control in place to prevent this. The provider has an appropriate secret key
available to sign the mail (no one stole anything). If the provider signs the
mail and sends it, it has a valid signature and passes DKIM (and DMARC), which
is bad.
How does the provider sign?
* apply multiple signatures, one for each key it has,
* match the From: domain, or
* match the SMTP AUTH domain?
Does the provider generate their own keys and have clients put a CNAME?
This is all about internal controls that appear to be missing on an
unfortunately common basis. The SPF part of the above is pretty simple and is
a problem today for domains that haven't bothered with DKIM because it's "too
hard". Once they do bother with DKIM, then I don't see any reason to believe
that you won't see the DKIM part of this as well. It's a foreseeable result
of using providers without appropriate internal controls.
Again, if we want to cover DKIM, we should be clearer about the mechanism used,
consider the risk, perhaps citing Section 8.3 of DKIM. Folding both subject
under a common frame forces the text to be overly general, and thus less
comprehensible.
Best
Ale
--
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
