On Tue 06/Feb/2024 07:22:49 +0100 Murray S. Kucherawy wrote:
On Mon, Feb 5, 2024 at 10:22 AM Alessandro Vesely <ves...@tana.it> wrote:
On 05/02/2024 00:29, Murray S. Kucherawy wrote:
On Sun, Feb 4, 2024 at 5:25 AM Alessandro Vesely <ves...@tana.it> wrote:
RFC 7489 says this:
In order to be processed by DMARC, a message typically needs to
contain exactly one RFC5322.From domain (a single From: field with a
single domain in it). Not all messages meet this requirement, and
handling of them is outside of the scope of this document.
So I don't know what's different now versus when this was written to compel
a change in posture. So yes, I interpret this as saying "DMARC ignores it
(if it even gets there)", and some other piece of the receiving engine can
deal with it.
To me the more important thing is that this citation and yours:
The case of a syntactically valid multi-valued RFC5322.From field
presents a particular challenge. The process in this case is to
apply the DMARC check using each of those domains found in the
RFC5322.From field as the Author Domain and apply the most strict
policy selected among the checks that fail.
...are in conflict, and that's what needs resolution.
The conflict is mitigated by the term "typically". I understand it as
referring to the subset of email messages that are typically dealt with by
DMARC. If, instead, a filter is going to authenticate /all/ messages, then it
knows how to do it.
In DMARCbis (Section 5.7.1) we appear to have resolved that conflict and
consider such messages out of scope, and DMARC processing ends. I think
that's a reasonable choice.
That choice poses a limit on DMARC that can be used as an attack surface. I'm
asking that we reconsider it. I don't think that would take an immeasurable
amount of time. Why are we so reluctant?
What I don't think is that DMARC is the right place to make any
proclamation that a multi-valued From should be rejected out of hand, or
for any reason that is not derived from the DMARC algorithm.
What should a programmer who is following the RFC to code a DMARC filter do,
then? Exit with a return code saying "out of scope"? I think a spec should
say how to use.
Specify -> Implement -> Devise attacks. It is not circular, although
you can then have DMARCter...
I would prefer to iterate via a future DMARCter than continue to iterate
on, and possibly never ship, DMARCbis.
After some doubts, it is clear that the 2nd RFC 7489 citation above is the only
way to do multi-valued From:s. It doesn't seem to need very long discussions
to be reinserted in the I-D. What problems would that cause?
Excluding multi-valued From: is a gratuitous limitation on DMARC's
applicability.
RFC7489 seems to imply that DMARC is only used for a fraction of email
messages, such as bank transactions.
Where do you observe such an implication?
For example, in the 1st RFC 7489 citation above ("typically"). The limitation
is also anticipated in Section 5, where it talks about "the sorts of mail
typically protected by DMARC participants". It implies there are other sorts
of mail.
If you as a receiver don't like the possible gap that creates, you're
free to do something about it, but you're not doing so under any
normative guidance from DMARC.
Isn't that a specification hole?
No, it's perfectly fine to declare that DMARC only applies to certain
classes of messages.
If we confirm this choice, it must be said loud and clear at the top of the
document. (And you just asked where I observed the implication that DMARC is
only used for a fraction of email...)
Best
Ale
--
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
