[dmarc-ietf] Re: Authentication: what is needed and why ARC is needed to acheive it.

[Dotzero <[e-mail]>]

On Mon, May 11, 2026 at 7:51 PM Douglas Foster <
[e-mail]> wrote:

> Since Michael's Hammer complaint that I was taking the discussion off
> topic, I have been trying to focus my thoughts and words to explain what
> ARC does that cannot be replaced by DKIM2.   This is the result.
>
> There are three types of authentication used when messages are passed
> between organizations:   ARC suffers from a failure to distinguish these
> three types of authentication, and fails to provide sufficient tools to
> document them.   ARC needs to be fixed, not scrapped.
>
>    - Client authentication applies to the initial connection between a
>    submitting agent and a submission server.   An ARC set that documents
>    client authentication must be the originating organization.   The client
>    authentication ARC set will either preceed the first Received header field,
>    or will follow a Received header that documents the submission connection.
>     The known types of authentication are login credentials or trusted IP
>    address, but the technique does not need to be documented because the
>    originating organization is always assumed responsible for authenticating
>    its submission clients.   The ARC set needs to include the RFC5321.MailFrom
>    address, the RFC5322.From address, an authentication Pass indicator, and
>    the Client Authentication indicator.
>
>    - Server authentication applies to the connection between a client
>    organization and an outbound gateway service.   The service needs to
>    authenticate the client connection to ensure that it can properly invoice
>    the client for services rendered.    The authenticated server is authorized
>    to send messages for any address in the client domain(s).   The ARC set
>    needs to include the Source IP and Helo name of the client's server and the
>    Received-By name of the accepting server, so that the ARC set can be linked
>    to the ARC set which documents the connection.  The ARC set also needs to
>    include the RFC5321.MailFrom address, the RFC5322.From address, an
>    authentication Pass indicator, the Server Authentication indicator, and the
>    type of authentication.     The known types of authentication are server
>    credentials, trusted IP, SPF Pass, and DMARC Pass based on DKIM.
>
>    - Message authentication applies to all other intermediary
>    connections.   The ARC set needs to include the Source IP and Helo name of
>    the client's server and the Received-By name of the accepting server, so
>    that the ARC set can be linked to the ARC set which documents the
>    connection.  The ARC set also needs to include the RFC5321.MailFrom
>    address, the RFC5322.From address, an authentication Pass indicator, the
>    Message Authentication indicator, and the basis of authentication.   The
>    known types of authentication are SPF Pass, DMARC Pass based on DKIM,
>    trusted forwarder, and local policy/private knowledge.   An example of
>    private knowledge is a server that knows that Example.Com is hosted on
>    Outlook.com, even though the domain has an SPF Policy that is missing,
>    malformed, or incomplete.
>
> DKIM2 will only provide a form of Message Authentication, so it is
> inherently inadequate.   When I am evalauating an intermediary, I am
> looking for evidence that the intermediary cannot be duped into accepting a
> fraudulent impersonation.   ARC can do that, DKIM2 cannot.   As a necessary
> result of its design, ARC sets are created by server organizations, not by
> their hosted clients, so it reveals the operating practices of the server
> organization.   Organizations that provide ARC Sets which indicate good
> authentication practices will become trusted.   Organiztions that provide
> ARC Sets which indicate poor authentication practices, and those which
> report nothing, will be treated with the skepticism that they deserve.
>
> There are features of this design that faciliatate detection of fraudulent
> ARC data, but that is a longer discussion.   At present, the problem is
> that most ARC data is useless because it does not communicate sufficient
> information to document these three types of authentication methods fully.
>
> Doug Foster
>
>
I was not complaining specifically about Doug Foster.

I was against the recharter in generally on the grounds that it would
devolve into "re-litigation" of all sorts  of issues like forwarding and
maillists, etc.I was perfectly willing to let ARC stand or fall on it's own
merits (or lack) However, the recharter of the working group was about
ending the experiment and deprecating ARC. It is supposed to be focused on
the draft submitted by Trent. To me that means assertions like " in section
X the verbiage needs to be changed as follows" or paragraph Y should be
dropped.

I would be perfectly fine if the group were to have a rough consensus to
shut down without adopting Trent's draft. However, the discussions are not
even referencing the draft and what is right or wrong with that draft..
Trent's most recent post clearly states that if there is anything of value
in ARC then the discussions about using it or leveraging it should happen
in the DKIM working group and be incorporated in DKIM2 (assuming there is
consensus).

If all of a sudden there was a groundswell of support to save ARC and a
rough consensus to recharter to address whatever problems there are, I
could live with that. The charter defines the scope of what the working
group should be and right now, that is Trent's draft.

Michael Hammer