Re: [dmarc-ietf] Overall last-call comments on DMARC

[Douglas Foster <[e-mail]>]

In response to Ale's comment that we describe the mailing list problem
without defining a path forward, I suggest the text below.

Doug Foster


Some legitimate messages are sent on behalf of an individual account, based
on an established relationship between the sender and the account owner,
but without domain owner involvement,  These messages are legitimate in the
sense that the RFC5322.From address represents the true author, but the
messages do not produce DMARC Pass because the sender does not have a DKIM
private key from the domain owner.  Mailing list messages are one example.
We shall call these Special Senders.

The mechanism which evaluators use to determine whether a message source
should be classified as a Special Sender is outside the scope of this
document.  [ARC could be part of the process.]   Once identified, an
alternate authentication technique is needed to distinguish Special Senders
from other sources, particularly malicious actors.  To facilitate this
alternate authentication, senders of such messages SHOULD use their own
domain name for the Mail From address, and SHOULD apply a DKIM signature
corresponding to the Mail From domain, and SHOULD ensure that the messages
produce SPF Pass.  When these identification measures are in place, the
evaluator can authenticate the Special Sender, and use that identification
to override DMARC Fail or DMARC No Policy.

- For messages received directly, the evaluator detects the Special
Sender's Mail From address or domain, and authenticates the message based
on SPF Pass, aligned DKIM Pass, or both.   Other message headers may also
be used, specific to the situation, to ensure precise identification.

- For messages received after secondary forwarding, but without Mail From
rewrite, identification is based on the Mail From address and a verified
DKIM signature aligned with the Mail From address.

- For messages received after secondary forwarding and Mail From rewrite,
authentication is more difficult.  Before any message can be assigned
Special Sender status, the evaluator must be able to detect that Special
Sender status might apply.  A DKIM signature for the Special Sender is the
only verifiable identifier for this purpose.  In most cases, the evaluator
will need to use other message headers to supplement the DKIM signature as
part of the Special Sender authentication, to ensure precise identification
of the Special Sender messages.   Alternatively, the evaluator may have
reason to trust the secondary forwarder's authentication process, and
accept the message on the basis of having been allowed through the
secondary forwarder.








On Wed, Apr 3, 2024 at 7:17 AM Alessandro Vesely <[e-mail]> wrote:

> On 02/04/2024 20:16, Murray S. Kucherawy wrote:
> > On Tue, Apr 2, 2024 at 9:01 AM Alessandro Vesely <[e-mail]> wrote:
> >
> >>>>>> By now, most mailing lists arranged to either rewrite From: or not
> break
> >>>>>> DKIM signatures.  We all hope those hacks are temporary.
> >>>>>
> >>>>> What do you mean by "temporary", given the time scales that have
> already
> >>>>> passed since RFC 7489 saw wide deployment?  Do you envision those
> >>>>> techniques ending sometime soon?
> >>>>
> >>>> Yeah, the time scale is killing us.  Is ten years soon enough?
> >>>
> >>> You tell me.  You say you're hoping they're temporary, yet they've
> been
> >>> around a long time and I'm not sure that there's an alternative on the
> >>> table.  I'm asking you to explain.
> >>
> >> I believe alternatives are possible.  Can't say how long it's going
> >> to take, but I presume when they are available, the nasty hacks
> >> will slowly fade out.>
> > So what are you suggesting should go in this document that's in WGLC?
>
>
> Section 8.6 states the ML problem very well, but it says nothing about the
> way forward.  Section 5.8, cross referenced with 8.6, talks about "other
> knowledge and analysis".  Neither that is forward looking, as it seems to
> suggest some kind of presently available, heuristic content analysis.
>
> Some sort of contract or agreement between sender and receiver seems to me
> to be unavoidable if we want to leverage ARC without having a global domain
> reputation system.  We don't have a precise method to do that.  We need to
> experiment and standardize something to that extent, which I hope this WG
> can do after publishing -bis.
>
> Meanwhile, we can mention ARC, in Section 5.8  (minimal text proposed in
> another thread[*]).  How much can we expand that?  For example, can we
> whisper something about the need to trust specific sealers for specific
> streams?
>
> In Section 8.3 the draft says:
>
>      550 5.7.1 Email rejected per DMARC policy for example.com
>
> I guess it would be too much to say:
>
>      550-5.7.1 Email rejected per DMARC policy for example.com,
>      550-5.7.1 ARC seal by forwarder.example verified but not trusted.
>      550 5.7.1 See https://receiver.example/arc-streams-registration/
>
> Wouldn't it?
>
>
> Best
> Ale
> --
>
> [*]
> https://mailarchive.ietf.org/arch/msg/dmarc/1aPplXPF1cYpnRzYHgxsTCPPzHg
>
>
>
>
>
>
>
> _______________________________________________
> dmarc mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dmarc
>