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

[Douglas Foster <[e-mail]>]

Has ARC solved the mailing list problem?  No
Can the mailiing list problem be solved while mailing lists fail to
authenticate the source of incoming posts? No.  At best, a hypotheized
solution can only ensure that legitimate mailing list posts are allowed
while also ensuring that fraudulent mailing list posts are allso allowed.

What is the end goal?   The goal of every participant should be to
eliminate fraudulent impersonation without blocking legitimate traffic, but
I doubt that goal is widely accepted.

Right now, we have a DMARC solution that declares malicious impersonation
of Citibank unacceptable, but impersonation of Yale.Edu perfectly
acceptable.    The attackers have responded accordingly.    Yale.Edu is the
most frequent impersonation target in my mail stream, and has been for a
long time.   I cannot remeber when I last saw a direct impersonation of
Citibank or any other financial institution.   So DMARC works, it just does
not do what I need, which is to block all impersonation.   So I have built
my own solution, which works well, but was vigorously discarded by this
working group.

However, my solution is vulnerable when the Received chain is complex.
 Before I can assess whether the Received chain can be trusted, I have to
figure out what is being asserted.  At present, the Received chain has too
much ambiguity, so I don't know what is being asserted.   ARC could help to
remove that ambiguity, but attempts to use it for that purpose have been
disappointing.   Insufficient participation is part of the problem, but
there is also not enough of the right information even when participation
occurs.   This leabves in a dilemma about this charter.   I believe ARC has
potential, but it is minimally useful at present.   I cannot be sure that
it will gain acceptance even if improved, because a lot of participants
feel no obligation to ensure an impersonation-free environment.   The
charter indicates where a lot of people want this to go, while my ability
to influence this group has been trivial.

DKIM2, like DMARC, allows a domain owner to take extra measures to show
that his messages are more trustworthy than the average message.   I am not
looking for the most trustworthy; I am lookinig for the scum so that I can
get it blocked.   To that end, I want to push every participant to thinking
about their obligation to authentication before relaying.

Doug Foster



On Mon, May 11, 2026 at 9:33 PM Dotzero <[e-mail]> wrote:

>
>
> 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
>