Richard, let's start with the basics:
My core observation is that:
"SPF and DKIM can only indicate the original authentication state of
the message when the test is based on the state of the message at
origination."
Are you taking issue with this problem statement, or simply taking issue
because the solution to the problem is difficult?
>From my reading of the DKIM2 plan, they accept my problem statement and are
intending to solve the missing information problem by requiring
documentation of message state at each hop, and mitigate the trust problems
by adding stronger signatures at each hop.
In the meantime, we do have a problem with credential upgrade and
downgrade, and DMARCbis needs to speak to it in a unified manner. I see
no reason to pretend that DMARC can produce useful results when it is
applied using incorrect parameters. The incorrect parameter problem
applies to any message involving more than two organizations (the sender
and receiver), and a large share of current mail uses an outbound gateway.
The test is then undermined by domain owners who currently assume that no
one will ever look at the handoff between their servers and their vendor's
server, so the originating servers are not in the domain's SPF policy.
Implementations that look at that boundary will have to deal with those
omissions using local policy. We can mitigate the expected problems by
advising domain owners to ensure that their SPF policy includes originating
servers.
My faith in outbound gateways has been shattered by impersonation emails
that have been allowed through one or more outbound gateway services. One
result of that shattering is that a DKIM signature which is applied by an
outbound gateway is useless, until I know that the outbound gateway service
was not deceived into accepting an impersonation.
Assigning a DKIM signature to a server can be done if one assumes that DKIM
signatures will be added as trace fields. This is commonly the case,
especially when added by an outbound gateway service. So it is pretty
easy to tell whether a signature was added by a gateway service or the
originator.
My implementation of a solution may not be robust enough to meet standards
track criteria, but the problem that creates the solution needs to be
clearly documented, and the general nature of a solution should be
sketched. Do you have a problem with that?
Doug Foster
Doug Foster
Doug Foster
On Mon, Nov 11, 2024 at 6:49 AM Richard Clayton <[email protected]>
wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> In message <[email protected]
> il.com>, Douglas Foster <[email protected]> writes
>
> >Outbound gateways typically increase the perceived message authentication
> >state. This can occur:
> >
> >· Because the outbound gateway organization is included in the
> Mail
> >>From domain’s SPF records, or
>
> I don't see how you can tell that is the case except in special
> circumstances.
>
> >Authentication using login credentials should be
> >documented using the protocol data in the Received header field and using
> >an ARC Set with an AUTH=PASS term in the ARC-Authentication-Results header
> >field.
>
> assuming that is a SHOULD, is it appropriate for this document to
> mandate the use of an experimental protocol ?
>
> > Authentication using trusted IP should be verifiable by SPF,
> >when applied to the IP address in the Received field which documents
> >handoff from client organization to Outbound Gateway organization.
>
> That sentence implies that the use of many SPF macros is no longer to be
> endorsed (which is fine by me, but doubtless not what you intend)
>
> > For
> >similar reasons, DKIM signatures should be applied by the originating
> >organization and placed in the Trace fields.
>
> earlier you said that it was OK for an outgoing gateway to do that. I
> think you SHOULD make up your mind.
>
> > A DKIM signature added by
> >the Outbound Gateway organization has a lower trust value because it does
> >not prove that the handoff between client and gateway organizations was
> >authenticated.
>
> ... and you revisit it with a different point of view. I expect what you
> want to say is that if a gateway applies a DKIM signature on behalf of a
> client then it MUST assure itself that the mail is genuine. BTW I am
> not sure how you can tell who applied a DKIM signature or when.
>
> >Forwarding always causes loss of SPF authentication for purposes of
> >DMARC.
>
> nope ... some people (unwisely perhaps) have very widely cast SPF
>
> >Forwarding falls into two main groups:
> >
> >· Simple forwarders transmit a general mail stream to a single
> >alternate recipient. DKIM signatures are usually preserved, but not all
> >messages will have DKIM signatures. As a result, a significant portion
> of
> >the received mail stream will appear to be unauthenticated.
> >
> >· Mailing lists transmit accepted message to a list of
> >subscribers. The list typically adds content to the message subject,
> >message body, or both. Since it is a forwarder, SPF authentication is
> >lost. Because it changes the signed content, DKIM authentication is also
> >lost. Consequently, content-altering mailing list messages appear to lack
> >any authentication.
>
> "Alumni" forwarders send to single recipients, but many alter the
> message... also some mailing lists go out of their way not to break
> DKIM signatures. So there's four groups.
>
> >To promote favorable consideration, forwarders should apply
> >an ARC set to forwarded messages.
>
> again you have a SHOULD for an experimental protocol
>
> - --
> 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/AwUBZzHuot2nQQHFxEViEQKEugCeJBFXm5DXHjC6ZKEk9ZBtR72fStIAn2xu
> D5Tx/iYz1zWD9T1nlvrJ7MGd
> =WPF5
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> dmarc mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
>
_______________________________________________
dmarc mailing list -- [email protected]
To unsubscribe send an email to [email protected]
