Hello,
for fo=d is written:
Generate a DKIM failure report if the message had a signature
that failed evaluation, regardless of its alignment. DKIM-
specific reporting is described in [AFRF-DKIM].
Once From: is rewritten by MLM, DKIM-Signature is preserved and does
not align anymore, fo=d;ruf=mailto: will generate a report.
How is fo=d different than having r=y? I want to get repors about
failed DKIM validation only when the email was unintentionally
modified, or sender and verifier are not implemented correct and use
different logic to calculate the hashes.
Do you suggest to include in RFC 7489bis (DMARC) everything from RFC
6651, except r=y and ADSP?
Removing r=y from DKIM-Signature is indeed untrackable operation, but
why should it be? DKIM-Signatures are partially self-signed, however
I proposed to remove r=y only when DKIM-Signature is intentionally
invalidated and in this case the signature is not damaged additionally
by removing r=y.
I do not insist on removing r=y from DKIM-Signature. I am looking for
a way to get reports only when somebody unintentionally modifies an
email. The reason for this is to have a system without unexplainable
failures that makes it easy to fix broken DKIM signing/validating
software. Repeating myself, when the aggregate reports show that 1%
of the emails are signed wrongly, there is no way to debug the problem
and fix. Before this fixed DMARC cannot be introduced, neither for
incoming nor for outgoing mails.
Some suggest to remove DKIM-Signature when the mail is modified
intentionally (by MLM), mailman logic is to keep the invalidated
DKIM-Signatures on their path to implement ARC
I don't like the idea of sending reports about unaligned
DKIM-Signatures (rewritten From: by MLM), as this allow a mailing list
subscriber posting to the list to get a list of all subscribers, but
the list of subscribers might be private.
How about introducing fo=da for sending reports on failed
DKIM-Signatures, only when they align? This is much like having r=a
in DKIM-Signature that only sends reports, when From: aligns. This
way, once an email is intenionally modifed, the modifying software is
aware that DMARC will trigger and rewrite From: so no distracting
reports will be sent.
Greetings
Дилян
----- Message from Alessandro Vesely <[email protected]> ---------
Date: Mon, 20 Aug 2018 11:31:09 +0200
From: Alessandro Vesely <[email protected]>
Subject: Re: [Ietf-dkim] DKIM-Signature: r=y and MLM
To: [email protected]
Hi!
On Fri 17/Aug/2018 23:48:34 +0200 Dilyan Palauzov wrote:
I cannot provide very useful experience:
Thank you for the overview. Albeit low-volume, it confirms my feeling that
rfc6651 is not widely adopted.
[...]
- state explicitly that providers who want reports about mismatched
DKIM-Signature have to use p=reject;pct=0;fo=d;ruf=...
ruf= suffices. p=reject;pct=0; is to force MLMs to rewrite From:, so as to
avoid useless reports. However, what one deems useless could be interesting
for another; for example, one might use aggregate reports triggered by MLM
sending as a sort of delivery notification, thereby achieving a
partial list of
subscribers' domains. One-man-and-for-fun provider's subscription is easily
betrayed that way.
Why shall software that knows r=y is old-fashion not remove it from
DKIM-Signature:, in order to ensure that r=y is not interepreted later by
software, that doesn't know r=y was moved to historic?
Let me recall that the DKIM-Signature header field is implicitly signed; that
is, if you alter it any way, it won't verify any more. Removal of
r=y would be
nearly impossible to undo, unless you know r=y was present and where
exactly it
was placed. Remove the whole field or rename it to, say, Old-DKIM-Signature.
BTW, some signatures are weak enough to survive boilerplate changes. In that
case, the signer might be interested in verification failures even after MLM
changes. How would you treat that instance?
Best
Ale
--
_______________________________________________
Ietf-dkim mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ietf-dkim
----- End message from Alessandro Vesely <[email protected]> -----
_______________________________________________
Ietf-dkim mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ietf-dkim
