Hello DKIM/DMARC list,

I would like to propose a method for "fixing" the real-world problems
that currently break DKIM.  I am aware of the work on ARC, but in
comparison this appriach:

 1. is much simpler, with a simple cryptographic foundation
 2. works without explicit support from message-modifying intermediates
 3. locates message parts that have changed [within practical bounds]
 4. allows training on acceptable changes for given senders/intermediates
 5. pins down rogue senders/intermediates more accurately

The idea isn't completely worked out yet, but the approach should be
crystal clear from the current text.  I believe that this leads to
better email user experiences than possible with ARC.

I am looking forward to your responses.  Please keep me in Cc: if possible?


Best wishes,

Rick van Rein
ARPA2.net / InternetWide.org
> *From:* [email protected]
> *Date:* 25 September 2017 at 11:49
> *To:* "Rick van Rein" <[email protected]>
> *Subject:* New Version Notification for draft-vanrein-dkim-lenient-00.txt
> A new version of I-D, draft-vanrein-dkim-lenient-00.txt
> has been successfully submitted by Rick van Rein and posted to the
> IETF repository.
>
> Name:         draft-vanrein-dkim-lenient
> Revision:     00
> Title:                Lenient DKIM
> Document date:        2017-09-25
> Group:                Individual Submission
> Pages:                7
> URL:            
> https://www.ietf.org/internet-drafts/draft-vanrein-dkim-lenient-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-vanrein-dkim-lenient/
> Htmlized:       https://tools.ietf.org/html/draft-vanrein-dkim-lenient-00
> Htmlized:       
> https://datatracker.ietf.org/doc/html/draft-vanrein-dkim-lenient-00
>
>
> Abstract:
>    DKIM is a framework for signed messages, especially for email.  While
>    in transit, changes are sometimes made, and these break the DKIM-
>    Signature.  This specification makes DKIM more lenient, without
>    changes to its core.  It adds leniency towards MIME body rewrites,
>    removal of alternatives and annotation with bits of text.  The
>    intention is to allow these changes such that they can be clearly
>    shown to the user, while indicating that the remainder of the
>    signedmessage is still in tact.
>
>                                                                               
>     
>
>
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat
>

_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc

Reply via email to