I was aware of this objection.
One of the questions on the table is, "What to say about indirect mail
flows?", and its companion, "What to say about ARC?" We cannot address
those questions until we have a shared understanding of the problem, which
is this:
"When the final identifier state is different from the original
identifier state, we cannot expect to obtain a correct authentication
result using the final identifiers. The only way to determine the correct
authenticator state at origination is to make a judgement about the
original identifiers."
Implications and choices:
- An evaluator could choose to act on the final identifier without
attempting to detect evidence of handling that could cause gain or loss.
He should expect random sender authentication errors, in both directions,
as a result of this willful ignorance. This is the mailing list problem.
- An evaluator could do research to determine that idendentifier state
change occurred, and then choose to ignore sender authentication for those
messages. Non-impersonated mail will not be blocked for sender
authentication failure, but true impersonation will be allowed unless
content filtering blocks the message. This seems reckless.
- An evaluator could parse the entire header data to infer what message
flow and state changes are asserted by the header structure. This is the
only approach that has a possibility of correctly allowing wanted mail and
correctly blocking unwanted mail.
Stated in other terms: More complete information is always preferable to
less complete information. Once I know what the message asserts, and can
associate those assertions with identifiers, I can start making decisions
about what to believe and whom to believe. When a message is judged
unacceptable, I know what identifier to block, and I have the visibility to
that block point in the message chain of future messages. I cannot make
informed decisions without information, and I cannot block identifiers
that I never find because I never looked for them.
There are two types of evaluators, with very different operational
environments:
- Mailbox providers issue mailboxes to consumers, have minimal
administrative authority over those users, and have minimal knowledge of
what those users want in a mail stream. The filtering goal is to minimize
malicious content only.
- Organizations provide mailboxes to organization members, to advance
the purposes of the organization, and have a consequent knowledge of what
messages are or are not consistent with those purposes. The filtering
goal is to make employees effective in their job, by allowing
business-relevant communication and blocking a range of unwanted messages,
ranging from malicious content to nuisance advertising.
Because of these differences, analysis that may be useless to Gmail may be
very useful to a business enterprise. GMail presumably feels a need to
accept auto-forwards from other mailbox providers. As a business filter
operator, I do not expect to receive auto-forwarded traffic unless it has
been pre-approved by management.
While it is true that one can imagine a fraudulent header structure formed
out of pure cloth, I have not observed this in the wild. I think the risk
is much lower than it might appear at first glance:
- Every organization in the Received chain is identifiable by a Received
entry created by the receiving server, so everyone is responsible for
adding correct data and relaying upstream data accurately. If a malicious
actor constructs a wholly fraudulent chain, and is exposed, the evaluator
can correctly attribute the fraud to the first organization with an
uncertain reputation. I don't think fraudulent headers are likely to
succeed with any frequency.
- Attackers have little reason to expect to benefit from fabricating a
false Received chain, unless they have intimate knowledge of how a
particular recipient will use the information. They may be useful to
nation-state attackers with internal espionage data.
Doug
On Mon, Oct 28, 2024 at 9:05 AM Richard Clayton <[email protected]>
wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> In message <[email protected]
> il.com>, Douglas Foster <[email protected]> writes
>
> >SPF is designed
>
> for clarity I am not addressing your comments on DKIM in this response
>
> >for the situation where a message is submitted directly from the
> >originating organization to the final recipient organization, and the SPF
> >record confirms that the source IP address is an authorized message
> >origination server for that specific domain.
>
> I agree with that
>
> [snip]
>
> >The goal of this process is to walk backward through the Received chain to
> >find the first organization to handle the message, after excluding client
> >connections.
>
> [snip the details of the examination of the Received chain]
>
> >Upon completion of this data collection, the originating Mail From domain
> >may be uncertain, but should be constrained to no more than two values.
>
> all very well .. but what this does not do is to demonstrate in any way
> that the body of the message as received after it has been handled by
> intermediaries bears any relationship whatsoever to what was initially
> sent. Additionally, competent forgery of Received header fields (which
> I would agree is beyond some people) means that you cannot even be
> certain that the message took the alleged first hop
>
> That's why doing the sort of analysis you set out is not attempted by
> mail receivers (present company perhaps excepted) apart from occasional
> one-off efforts to attempt to determine "what on earth is going on"
>
> - --
> richard Richard Clayton
>
> Those who would give up essential Liberty, to purchase a little temporary
> Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755
>
> -----BEGIN PGP SIGNATURE-----
> Version: PGPsdk version 1.7.1
>
> iQA/AwUBZx+MCd2nQQHFxEViEQLKYQCfSRc7Y7bp5l5v9yZQtSRwxEmqPagAoMQf
> 968arKFgGdxfUtU/Zg/u0cOK
> =UY9B
> -----END PGP SIGNATURE-----
>
_______________________________________________
dmarc mailing list -- [email protected]
To unsubscribe send an email to [email protected]
