On 2024-08-15, Viktor Dukhovni via Exim-users <exim-users@???> wrote:
> On Wed, Aug 14, 2024 at 08:25:30PM +0100, Julian Bradfield via Exim-users wrote:
>
>> > I do not agree.
>> > The DKIM RFC says that anyone can sign a message.
>>
>> Yes, but it also says very clearly that it's up to the Identity
>> Assessor to decide what, if any, trust to place in a message signed by
>> a domain that is not aligned to the From: header (or other header).
>>
>> The obvious assessment to make is that it is a forgery signed by the
>> forger, unless you have particular knowledge of a trust connection
>> between the originating domain and the signing domain.
>
> No. Alignment, etc., is DMARC not DKIM. Absent a DMARC policy for
> the "From:" domain, any the DKIM signature allows the receiving system
> to use the "d=" value as a key into a reputation system, but questions
> of "forgery" do not arise.
DKIM simply says "this message has been signed by this domain". An
Identity Asessor is trying to work out what, if anything, it knows
about the message. If it sees a message signed by a non-aligned
domain, then it knows nothing useful, and might indeed choose to infer
that the message is a forgery.
As it says in the introduction to DKIM: "DKIM separates the question
of the identity of the Signer of the message from the purported author
of the message. In particular, a signature includes the identity of
the Signer. Verifiers can use the signing information to decide how
they want to process the message."
And later:
INFORMATIVE DISCUSSION: This document does not require the value
of the SDID or AUID to match an identifier in any other message
header field. This requirement is, instead, an Assessor policy
issue. The purpose of such a linkage would be to authenticate the
value in that other header field. This, in turn, is the basis for
applying a trust assessment based on the identifier value. Trust
is a broad and complex topic, and trust mechanisms are subject to
highly creative attacks. The real-world efficacy of any but the
most basic bindings between the SDID or AUID and other identities
is not well established, nor is its vulnerability to subversion by
an attacker. Hence, reliance on the use of such bindings should
be strictly limited. In particular, it is not at all clear to
what extent a typical end-user recipient can rely on any
assurances that might be made by successful use of the SDID or
AUID.
--
## subscription configuration (requires account):
##
https://lists.exim.org/mailman3/postorius/lists/exim-users.lists.exim.org/
## unsubscribe (doesn't require an account):
## exim-users-unsubscribe@???
## Exim details at
http://www.exim.org/
## Please use the Wiki with this list -
http://wiki.exim.org/
