Re: [dmarc-ietf] Debugging and preventing DKIM failures- suggestion

[Dotzero <[e-mail]>]

On Fri, May 31, 2019 at 6:59 AM Douglas E. Foster <
[e-mail]> wrote:

> I cannot speak to IETF consensus, since I am new to that process and I
> seem to be an  outlier already.
>

Perhaps the onus is on you to take the time to understand  IETF and it's
processes before demanding changes. Just a thought.

>
> Agency and signatures are well understood legal concepts.   3000 years
> ago, people sealed their letters with a signet ring stamped in warm clay.
>  Signing technologies have changed in that time, but the principle has
> not.   A courier is responsible for keeping the signed and sealed part of a
> message unaltered.   Envelope marks are acceptable.
>
>

Perhaps you should go back and read the history and purpose of DKIM.


> A digital signature is supposed to provide non-repudiation.  If I submit a
> signed message to a list processor, and the list processor voids the
> signature, it has given me verifiable repudiation, the opposite of what
> either sender or receiver want.
>

Non-repudiation is not the purpose of DKIM signing. The purpose was (and
is) to provide a mechanism for mailbox providers to evaluate whether an
email message was authorized by a particular domain.


>
> A closed group on a single server can use whatever rules they choose to
> implement in that community.  For example, a web forum operates on the
> rules of the forum operator.   However, an open group using the email
> infrastructure has to work within the infrastructure it uses.   In the
> email infrastructure, the recipient has to deal with fraud, and any
> recipient accommodation to "harmless" fraud facilitates the people who are
> doing "harmful" fraud to that recipient.
>

You are certainly entitled to your opinion.

>
> There are some obvious use-cases for MTA changes to a message, and we
> would do well to document and address them.
>

Perhaps the you part of "we" should submit an Internet Draft undertaking
the work you want done.

>
> The first that comes to mind is MTA comment fields.
> - A list processor wants to add a comment indicating something about the
> list that sent it.
> - A spam filter wants to add a tag indicating that the message is
> suspicious, but not sufficiently suspicious to be blocked.
>
> IETF would do well to specify a mechanism for MTAs to add information
> which MUAs present to the user, while identifiying that that the
> information came from the MTA rather than the original sender.
>

> Another use-case is related to body sections.   IETF only forwards plain
> text, while most email solutions send messages in HTML+Text.   I assume
> that IETF also drops attachments.   DKIM cannot handle this because it
> hashes the entire body.   A signature system that signed each section
> individually would allow sections to be dropped, with notification to the
> user, without breaking the signatures on the other MIME types.
>
> DKIM was supposed to provide sender authentication when SPF was
> invalidated by forwarding, so DMARC said that the two techniques should be
> evaluated together.   I am realizing that if SPF is invalidated, DKIM is
> probably invalidated as well, so we have no usable sender authentication
> technology.   This may explain why so many products that I have examined
> lack support for DMARC or lack good exception mechanisms for SPF, DKIM, and
> DMARC.
>

Can you please show us the documentation that supports your assertion that
" DKIM was supposed to provide sender authentication when SPF was
invalidated by forwarding"? When I read the DKIM RFC I find nothing to
support your assertion. DKIM was the result of the merging of Internet
Identified Mail (IIM) and Domain Keys (DK) proposals. Quite a few of us
were around at the time it happened. These things happened in parallel to
SPF and not as a "fix" to SPF. Thank you for your creative attempt to
rewrite history.

>
> It seems that email needs something like "DNS Flag Day", where major
> players announce a date after which certain behaviors that will no longer
> be tolerated.   But as others have said, IETF is not that organization, and
> the organization may not exist.
>
>
Thank you for your proposal. To channel a long time participant, I invoke
King Canute. If you believe major players should take a particular action
in unison then perhaps you should be reaching out to those major players.
(Side note to major players, no need to thank me for pointing this out)


> More discouraged than ever,
>

Hope springs eternal.

Michael Hammer

>