Subject: [apps-discuss] DKIM Forwarding History (Provenance) Proposal

From: Wei Chuang <[email-masked]>
Date: Sat, 28 Jun 2014 06:41:14 -0700

We propose the following enhancement to DKIM for tracking message changes
relevant to authentication as a message is forwarded and modified by mail
providers, typically mailing lists. At each SMTP delivery step, starting
with the original sender and through all intermediate forwarders, the
message must be DKIM signed.  Each intermediate forwarder then adds a diff
so that the recipient can recover the message as received by that forwarder
and any earlier version.  This change enables the recipient to verify the
authenticity of the message and allows a more accurate decision for
preventing abuse. In addition, it answers the problem of handling DMARC
domains relayed through mailing lists.  The advantage of this is that the
recipient can recover the DKIM signed and verified message as received by
the intermediate mail provider by reverse patching the diff, and can
repeatedly apply this as necessary to recover the message sent by the
original sender.  Observing all versions of messages is most useful for
Spam and Phishing detection in evaluating the reputation of the message.
 In particular one can observe the original sender's intent, and this is
useful for example to verify that the original sender meant to send along a
particular mail forwarding path or mailing-list.

This proposal would introduce a new MIME CONTENT-TYPE:
multipart/dkim-forwarding-history that would contain the diffs.  Diffs
between successive versions of the message are added sequentially as
subparts to dkim-forwarding-history part.  Diff parts are treated as
attachments so that the user doesn't get confused by the contents.  This
particular proposal only works with 7-bit encoding, and a future proposal
will deal with 8bit and binary.  This process is illustrated in the example
later.

Note this isn't a full proposal as we would like the concept to be
considered first.  If this discussion is successful, we would like to also
discuss a related improvement to SPF and DMARC, as well as the binary
encoding change.  At the conclusion we can have a longer discussion about
the details of CONTENT-TYPE: multipart/dkim-forwarding-history or write a
draft that tightly specifies how this works.

=====

DKIM Forwarding History illustrative example

Message is generated at Mymail and sent to mailing-list Yourgroup.
 Yourgroup modifies the subject line to indicate to the user which
mailinglist the message went through.  Then it is delivered to a
Forwardmail which forwards without visible modifications to its ultimate
destination at [email-masked].  Despite the lack of visible changes,
the message at Forwardmail is likely modified with at least a Received
header appended.

At each intermediate domain, the SMTP server takes a diff of the message as
it is to be sent including any modifications, and the received version
excluding the diff contents and excluding the new DKIM signature since
that's computed after the diff.  The diff content is appended to the any
previous diff content as an attachment.  All diff content resides in a
multipart/dkim-forwarding-history MIME part.  After that, DKIM signing is
done includes the header, original body, and diffs.  If there is a previous
DKIM header, it is removed, so that it is clear what the ownership is. The
new DKIM header is added to the message header.

Here's the message content that would be seen by the user.

Original message:
  From: [email-masked]
  To: [email-masked]
  Subject: I'm testing how DKIM forwarding history versioning works.

 This example illustrates how using diff and patch can obtain the message
versions.
  -Sender

Yourgroup message:
  From: [email-masked]
  To: [email-masked]
  Subject: [big-mailinglist] I'm testing how DKIM forwarding history
versioning works.

  This example illustrates how using diff and patch can obtain the message
versions.
  -Sender

Forwardmail message:
  From: [email-masked]
  To: [email-masked]
  Subject: [big-mailinglist] I'm testing how DKIM forwarding history
versioning works.

  This example illustrates how using diff and patch can obtain the message
versions.
  -Sender

Here's the more detailed description with the abbreviated RFC5322 message.

Original message generated at mymail.com and sent to yourgroup.com.
======
  DKIM-Signature: d=mymail.com ...
  From: [email-masked]
  To: [email-masked]
  Subject: I'm testing how DKIM forwarding history versioning works.
  Content-Type: text/plain; charset=US-ASCII
  Content-Transfer-Encoding: 7bit

  This example illustrates how using diff and patch can obtain the message
versions.
  -Sender

Yourgroup mailing list takes ownership of message and composes the
following which is sent to Forwardmail.
=====
  DKIM-Signature: d=yourgroup.com ...
  From: [email-masked]
  To: [email-masked]
  Subject: [big-mailinglist] I'm testing how DKIM forwarding history
versioning works.
  Content-Type: multipart/mixed;
   boundary="ABC123"

  --ABC123
  Content-Type: text/plain; charset=US-ASCII
  Content-Transfer-Encoding: 7bit

  This example illustrates how using diff and patch can obtain the message
versions.
  -Sender
  --ABC123
  Content-Type: multipart/dkim-forwarding-history;
   boundary="DFH456"

 --DFH456
  Content-Type: text/plain; charset=US-ASCII
  Content-Transfer-Encoding: 7bit
  Content-Disposition: attachment;
   filename="message-25june2014_1301.patch"

 *** original-message-25june2014_1301.txt 2014-06-26 07:21:11.472671000
-0700
  --- yourgroup-message-25june2014_1301.txt 2014-06-26 07:23:18.110909000
-0700
  ***************
  *** 1 ****
  - DKIM-Signature: d=mymail.com ...
  --- 0 ----
  ***************
  *** 4 ****
  ! Subject: I'm testing how DKIM forwarding history versioning works.
  --- 3,7 ----
  ! Subject: [big-mailinglist] I'm testing how DKIM forwarding history
versioning works.
  ! Content-Type: multipart/mixed;
  !       boundary="ABC123"
  !
  ! --ABC123
  ***************
  *** 9 ****
  --- 13,14 ----
  + --ABC123
  + --ABC123--
  --DFH456--
  --ABC123--

Forwarder Forwardmail takes ownership of message, composes the following
and sends to [email-masked].
=====
  DKIM-Signature: d=forwardmail.com ...
  From: [email-masked]
  To: [email-masked]
  Subject: [big-mailinglist] I'm testing how DKIM forwarding history
versioning works.
  Content-Type: multipart/mixed;
   boundary="ABC123"

  --ABC123
  Content-Type: text/plain; charset=US-ASCII
  Content-Transfer-Encoding: 7bit

  This example illustrates how using diff and patch can obtain the message
versions.
  -Sender
  --ABC123
  Content-Type: multipart/dkim-forwarding-history;
   boundary="DFH456"

 --DFH456
  Content-Type: text/plain; charset=US-ASCII
  Content-Transfer-Encoding: 7bit
  Content-Disposition: attachment;
   filename="message-25june2014_1301.patch"

 *** original-message-25june2014_1301.txt 2014-06-26 07:21:11.472671000
-0700
  --- yourgroup-message-25june2014_1301.txt 2014-06-26 07:23:18.110909000
-0700
  ***************
  *** 1 ****
  - DKIM-Signature: d=mymail.com ...
  --- 0 ----
  ***************
  *** 4 ****
  ! Subject: I'm testing how DKIM forwarding history versioning works.
  --- 3,7 ----
  ! Subject: [big-mailinglist] I'm testing how DKIM forwarding history
versioning works.
  ! Content-Type: multipart/mixed;
  !       boundary="ABC123"
  !
  ! --ABC123
  ***************
  *** 9 ****
  --- 13,14 ----
  + --ABC123
  + --ABC123--
  --DFH456
  Content-Type: text/plain; charset=US-ASCII
  Content-Transfer-Encoding: 7bit
  Content-Disposition: attachment;
   filename="message-25june2014_1302.patch"

 *** yourgroup-message-25june2014_1302.txt 2014-06-26 07:43:31.055270000
-0700
  *** forwardmail-message-25june2014_1302.txt       2014-06-26
07:43:13.518164000 -0700
  *** 1 ****
  - DKIM-Signature: d=yourgroup.com ...
  --- 0 ----
  --DFH456--
  --ABC123--

---

From: Hector Santos <[email-masked]>
Date: Sat, 28 Jun 2014 11:22:29 -0400

> draft that tightly specifies how this works.

Wei,

Any "chain of trust" idea will work with a honored client/server 
negotiated protocol steps and ideals.

The problem has always been in dealing with the deviation from the 
ideal protocol steps and compliancy expectations.

So if you have a protocol ABC, what are the benefits of this ABC 
processing?  What is the payoff for the compliant mail receiver?  What 
is the payoff for the originating/author domain?   What happens when 
there is deviation, something broke in the chain of MIME diffs?  What 
do you want receivers to do?

You must think of the massive volume of wasteful mail processing. Not 
everyone is going to do this just for nothing. It has to have a 
meaningful payoff, and today that payoff comes in the form of mail 
filtering policies with rejection/quarantine/discard author domain 
policy concepts.

So if your proposal says:

    "If you follow these steps, the author domain
     is OK with you (because you asked him) honoring
     rejection, if you see a problem, then there is
     something wrong with it and its better (trust the
     author policy) if you just reject it."

then we you got something to consider.

But I think in this case, your proposal is a higher processing 
complexity factor when all you need to do is ask the author if the 
final/last signature in the chain is an trusted and/or authorized 
signer domain.   If you are not asking the author (directly or 
indirectly) if any of this forwarding stuff is ok, then I think you 
have a security conflict (loophole) to consider.

-- 
HLS

---

From: Wei Chuang <[email-masked]>
Date: Sat, 28 Jun 2014 17:01:49 -0700

Hi Hector

On Sat, Jun 28, 2014 at 8:22 AM, Hector Santos <[email-masked]> wrote:

> The problem has always been in dealing with the deviation from the ideal
> protocol steps and compliancy expectations.
>
> processing?  What is the payoff for the compliant mail receiver?  What is
> the payoff for the originating/author domain?

The benefit is that the recipient can authenticate the originating sender
and in particular a particular action such as sending to a mailing list,
yet allow intermediate domains to modify messages.  It may be that a user
has a filter to see all messages from the original sender.  This is jumping
ahead a bit, but the current DMARC paradigm is for the mailing list to own
the message and rewrite the RFC5322.FROM which make this difficult.  In
addition SPAM filters likely can benefit from being able to process the
original message and know message was authenticated by the original sending
domain.

> What happens when there is deviation, something broke in the chain of MIME
> diffs?  What do you want receivers to do?
>

In this proposal, it would be the same as failing DKIM RFC 6376 verification.
 It ought to be treated as information the recipient domain can use for
additional Spam processing etc but not necessarily indicate reject or other
action.  This proposal is meant to build infrastructure that can be used to
enhance DMARC in a subsequent proposal.  By itself this proposal primarily
provides extra information (well a strong guarantee on the authenticity and
modifications) for Spam processing.

> everyone is going to do this just for nothing. It has to have a meaningful
> payoff, and today that payoff comes in the form of mail filtering policies
> with rejection/quarantine/discard author domain policy concepts.
>
> But I think in this case, your proposal is a higher processing complexity
> factor when all you need to do is ask the author if the final/last
> signature in the chain is an trusted and/or authorized signer domain.   If
> you are not asking the author (directly or indirectly) if any of this
> forwarding stuff is ok, then I think you have a security conflict
> (loophole) to consider.
>
>
I'm probably misunderstanding your intent.  Here's a stab at a response:
Passing the DKIM Provenance verification is meant to provide a stronger
verification from a purported original sender.  If intermediates want to
claim that a mail came from some original sender, then they have to provide
evidence.  If they don't due maliciousness or otherwise, they don't have to
include such evidence but they won't get any benefit of claiming the
reputation of the original sender.

-Wei

PS It was mentioned offline that the discussion on dmarc@ietf is currently
restricted to building the WG charter.  First apologies I missed that.
 Second I can restrict subsequent discussion to apps-discuss if that's
preferred by the WG.

---

From: "John Levine" <[email-masked]>
Date: 29 Jun 2014 01:25:52 -0000

>multipart/dkim-forwarding-history that would contain the diffs. 

It's an interesting idea, but I see two immediate issues:

a) it requires extensive changes to both list managers and MUAs, which
history tells us are not likely to happen

b) the problem it solves doesn't seem to be the one we have

It is my impression that a host that appears to be a forwarder will
act pretty consistently, making whatever changes it makes to the
messages coming through.  So if it starts sending spam, that's almost
certainly because for some reason (poor filtering, spoofing, etc) it's
forwarding mail that was already spam when it arrived at the
forwarder.  So if the forwarder can pass through enough info to
reconstruct not the original message, but the original authentication
info, which will say among other things whether the original message
was DMARC aligned.

That's specifically what Original-Authentication-Results is intended
to do, and one of the things you could do with my weak conditional
signatures.  They're not bulletproof, but they don't have to be if you
believe that it's not common for well behaved forwarders to suddenly
turn malicious.

Beyond that, there'd be the issue of deciding how much change was "too
much".  There are some fairly normal changes that lists make that are
semantically minor but cause vast changes to the message text, e.g.,
reordering or deleting parts. recoding from 8bit to base64, or
flattening HTML to text.

R's,
John

---

From: Hector Santos <[email-masked]>
Date: Sun, 29 Jun 2014 10:58:27 -0400

Hi Wei,  

IMO, your proposal is on par with the engineering considerations needed to develop and mold the charter.  Your proposal intent is to preserve the integrity and indirectly, the authorization for forwarding, resigning mail.   The draft charter has its own even higher complex ideas for the same intent.  My intent is to keep it simple with 3rd party authorization framework and I don't see any other better method than a DNS-based lookup method for resigning authorization or allowance.  I believe in strong rejection author domain policies. You can't standardize random, subjective heuristic methods, but you can standardize deterministic protocol methods. This is the wider, network persistent and consistent solution that everyone can use. 

If your offline moderation control messenger intent was to steer the work towards a specific more. complex, DKIM changing direction, and any negative discussion about it or censoring other better alternatives, and specifically authorization methods, are out of scope, then I don't wish to spend any more time, money and resources in what I strongly believe is going to be a big waste of time, doesn't resolve the problem, nor does it eliminate the need to do DNS lookups.  

The ADs need to consider more engineering solutions views that are outside the same typical folks who have long had control of this project.  We are here today because the DKIM project leaders were incorrect in their presumptions about the market needs, directions and they seem to be repeating it again.  I don't want to go thru this costly error again.  The draft charter as written is too complex and IMO, it will not solve the main problem we always had which is how to authorize and scale resigners.   

Your idea is really not that different than what Murray and Dave want to pursue in the draft with a higher level DKIM processing complexity, long term prospects which I believe are not necessary and probably unrealistic to believe people are going to blindly accept with even more expense in long term experimentation. DKIM was just made into an STD document last year and already there is consideration in changing.

Thanks

--
Hector Santos
http://www.santronics.com

> On Jun 28, 2014, at 8:01 PM, Wei Chuang <[email-masked]> wrote:
> 
> Hi Hector
> 
>> Any "chain of trust" idea will work with a honored client/server negotiated protocol steps and ideals.
>> 
>> The problem has always been in dealing with the deviation from the ideal protocol steps and compliancy expectations.
>> 
>> So if you have a protocol ABC, what are the benefits of this ABC processing?  What is the payoff for the compliant mail receiver?  What is the payoff for the originating/author domain?  
> 
> The benefit is that the recipient can authenticate the originating sender and in particular a particular action such as sending to a mailing list, yet allow intermediate domains to modify messages.  It may be that a user has a filter to see all messages from the original sender.  This is jumping ahead a bit, but the current DMARC paradigm is for the mailing list to own the message and rewrite the RFC5322.FROM which make this difficult.  In addition SPAM filters likely can benefit from being able to process the original message and know message was authenticated by the original sending domain.
>  
>> What happens when there is deviation, something broke in the chain of MIME diffs?  What do you want receivers to do?
> 
> In this proposal, it would be the same as failing DKIM RFC 6376 verification.  It ought to be treated as information the recipient domain can use for additional Spam processing etc but not necessarily indicate reject or other action.  This proposal is meant to build infrastructure that can be used to enhance DMARC in a subsequent proposal.  By itself this proposal primarily provides extra information (well a strong guarantee on the authenticity and modifications) for Spam processing.
>  
>> 
>> You must think of the massive volume of wasteful mail processing. Not everyone is going to do this just for nothing. It has to have a meaningful payoff, and today that payoff comes in the form of mail filtering policies with rejection/quarantine/discard author domain policy concepts.
>> 
>> But I think in this case, your proposal is a higher processing complexity factor when all you need to do is ask the author if the final/last signature in the chain is an trusted and/or authorized signer domain.   If you are not asking the author (directly or indirectly) if any of this forwarding stuff is ok, then I think you have a security conflict (loophole) to consider.
> 
> I'm probably misunderstanding your intent.  Here's a stab at a response: Passing the DKIM Provenance verification is meant to provide a stronger verification from a purported original sender.  If intermediates want to claim that a mail came from some original sender, then they have to provide evidence.  If they don't due maliciousness or otherwise, they don't have to include such evidence but they won't get any benefit of claiming the reputation of the original sender.
> 
> -Wei
> 
> PS It was mentioned offline that the discussion on dmarc@ietf is currently restricted to building the WG charter.  First apologies I missed that.  Second I can restrict subsequent discussion to apps-discuss if that's preferred by the WG.
> 
> _______________________________________________
> dmarc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmarc

---

From: Wei Chuang <[email-masked]>
Date: Sun, 29 Jun 2014 16:53:39 -0700

Hi Hector,

On Sun, Jun 29, 2014 at 7:58 AM, Hector Santos <[email-masked]> wrote:

> Hi Wei,
>
> IMO, your proposal is on par with the engineering considerations needed to
> develop and mold the charter.  Your proposal intent is to preserve the
> integrity and indirectly, the authorization for forwarding, resigning mail.
>   The draft charter has its own even higher complex ideas for the same
> intent.  My intent is to keep it simple with 3rd party authorization
> framework and I don't see any other better method than a DNS-based lookup
> method for resigning authorization or allowance.  I believe in strong
> rejection author domain policies. You can't standardize random, subjective
> heuristic methods, but you can standardize deterministic protocol methods.
> This is the wider, network persistent and consistent solution that everyone
> can use.
>
> If your offline moderation control messenger intent was to steer the work
> towards a specific more. complex, DKIM changing direction, and any negative
> discussion about it or censoring other better alternatives, and
> specifically authorization methods, are out of scope, then I don't wish to
> spend any more time, money and resources in what I strongly believe is
> going to be a big waste of time, doesn't resolve the problem, nor does it
> eliminate the need to do DNS lookups.
>
>
The person sending me mail offline was just mentioning the WG status as
justifying why he brought his conversation offline.  I had seen comments
regarding the charter status in some recent emails, but when I looked for
the ground rules for the mailing list, couldn't find it.  I was updated
that a spam filter removed the earlier ground rules email.

> The ADs need to consider more engineering solutions views that are outside
> the same typical folks who have long had control of this project.  We are
> here today because the DKIM project leaders were incorrect in their
> presumptions about the market needs, directions and they seem to be
> repeating it again.  I don't want to go thru this costly error again.  The
> draft charter as written is too complex and IMO, it will not solve the main
> problem we always had which is how to authorize and scale resigners.
>
> Your idea is really not that different than what Murray and Dave want to
> pursue in the draft with a higher level DKIM processing complexity, long
> term prospects which I believe are not necessary and probably unrealistic
> to believe people are going to blindly accept with even more expense in
> long term experimentation. DKIM was just made into an STD document last
> year and already there is consideration in changing.
>

This proposal means to use DKIM as a building block and doesn't call for
changing the DKIM spec.  I think there's an opportunity with DMARC IETF
standardization process to revisit some of the features that restrict its
deployment.  The ultimate direction of these proposals will be advance some
ideas to address them.  I agree that changing the goal posts is a difficult
thing, but then preventing Spam and Phishing on our users is also a pretty
powerful motivator.  I would say that DKIM, SPF, and DMARC are attractive
tools to prevent Spam and Phishing and making changes to facilitating their
deployment is justified.

-Wei

>> What happens when there is deviation, something broke in the chain of
>> MIME diffs?  What do you want receivers to do?
>>
>
> PS It was mentioned offline that the discussion on dmarc@ietf is
> currently restricted to building the WG charter.  First apologies I missed
> that.  Second I can restrict subsequent discussion to apps-discuss if
> that's preferred by the WG.
>

---

From: Wei Chuang <[email-masked]>
Date: Sun, 29 Jun 2014 18:36:51 -0700

> history tells us are not likely to happen

But change is being forced upon list managers in particular by the Yahoo
and AOL DMARC p=reject change.  My understanding is the change though is
fairly suboptimal i.e. fixes the immediate problem but introduces new
issues such as modifying RFC5322.FROM which hurts UX.  I would think these
providers if they have to make a change would prefer something that is
general, doesn't impact the generally understood user experience with
mailing lists e.g. modifying subject lines or footers and provides the
security that DMARC verifies for.  Keep also in mind that the underlying
reason why Yahoo and AOL went to p=reject, Spam and Phishing, are threats
that increase in quantity and sophistication in time.  I would hope that it
is forward looking to assume that some change is necessary to deal with
them.

> believe that it's not common for well behaved forwarders to suddenly

OAR asks the receiver to trust the forwarder / mailing-list.   This is okay
for larger scale providers where the reputation can be well established.
 But smaller forwarder will be at a disadvantage since there's less
evidence of past behavior.  The conditional signatures approach is fairly
general, but the initial sender has know the complete forwarding path
message may take.  This could be a problem in particular with mailing-lists
where there are multiple such paths in the fanout.

> reordering or deleting parts. recoding from 8bit to base64,

Transport encoding changes can be handled by additional MIME metadata I
think.

> or

Agreed. That type of conversion will definitely add more overhead and
increase message size.  I would think in some circumstances this diff is
desired because the change is potentially significant.

> John

thanks for the many insights,
-Wei

---

From: "John R Levine" <[email-masked]>
Date: 29 Jun 2014 22:38:26 -0400

> and AOL DMARC p=reject change.

Forced on list managers, but not on MUA authors.  If we can get MUA 
authors to change the way they display list mail, we could do something 
much simpler like the message wrapping that's an option in recent versions 
of Mailman.

> evidence of past behavior.

If spammers send enough fake forwarded mail that it's an issue for small 
mail systems, I expect the operators will use shared whitelists of known 
forwarders.  I talk to a lot of other small mail system operators, and 
most of them are only dimly aware of DMARC as that thing that screws up 
AOL and Yahoo mail.  On my system, the only use the filters make of DKIM 
is to reject unsigned mail from a fixed list of major phish targets, a 
spamassassin feature that predates DMARC by many years.

I just don't seem them (us, really) implementing something as complex as 
your proposal, particularly if it turns out that it needs a lot of 
tweaking to avoid false positives.

> The conditional signatures approach is fairly general, but the initial 
> sender has know the complete forwarding path message may take.  This 
> could be a problem in particular with mailing-lists where there are 
> multiple such paths in the fanout.

The sender only needs to know the forwarders that break DKIM signatures, 
for lists is just the first one you send to.  On the lists I've seen with 
multiple paths, the fanout just relays the mail without rewriting it.

Do you still see a lot of lists with multiple fanout visible to the 
recipients?  It was common 20 years ago, but now everything is fast enough 
that you'd need a phenomenally large list for it to be useful.  The only 
one I subscribe to that big is Dave Farber's IP list, and the fanout is 
only visible in the Received: headers.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.

---

From: Wei Chuang <[email-masked]>
Date: Mon, 30 Jun 2014 11:22:20 -0700

> much simpler like the message wrapping that's an option in recent versions

With message wrapping, my understanding is it wraps the original message in
a MIME part.  If that's the case, then that's pretty much the storage (or
more) of doing the diff.  And if both parties do a DKIM signing, then its
almost the all the way there to this proposal.  Yes there is some
conformance burden but it provides much greater security guarantees.  The
MUA owners are certainly feeling pressure from Spam and Phishing.  I'd
imagine they'd be willing to change if they saw enough benefit.

> forwarders.  I talk to a lot of other small mail system operators, and most
> of them are only dimly aware of DMARC as that thing that screws up AOL and
> Yahoo mail.

The lack of pick up of smaller providers of particularly DKIM is what drove
this proposal.  We did a survey of DKIM and SPF pick up for personal mail,
and observed that large provider were using DKIM, but there was a dramatic
drop off as the providers got smaller.  SPF had a drop off too, but less
pronounced.   This is disappointing in that DKIM provides a stronger
security guarantee, and has less restrictions on its deployment than SPF
(if one excludes DMARC constraints).  Is it only lack of awareness?  I
doubt that otherwise we'd see both SPF and DKIM drop off in equal measure.
 Its not due to X509 PKI complexity as DKIM doesn't require that.  In any
case, we were wondering if its due in part to the warts that DMARC has
(meaning imposes on DKIM / SPF), hence this proposal.

> On my system, the only use the filters make of DKIM is to reject unsigned
> mail from a fixed list of major phish targets, a spamassassin feature that
> predates DMARC by many years.
>
> your proposal, particularly if it turns out that it needs a lot of tweaking
> to avoid false positives.

Actually this proposal is supposed to resolve the tweaking that is needed
today with DMARC.  What tweaking do see you will be required?  Agreed that
there will be a cost in additional CPU processing time (diff),  greater
message size and eng effort for conformance.  But besides that?  (And
granted the DMARC part of the proposal isn't out yet)

>> sender has know the complete forwarding path message may take.  This could
>> be a problem in particular with mailing-lists where there are multiple such
>> paths in the fanout.
>>
>
No specific example- it was meant hypothetically.  But in the lore here,
the internet is such as vast place with so permutations of messages and
providers, that if something can break, invariably it will.

thanks,
-Wei

Regards,

---

From: Wei Chuang <[email-masked]>
Date: Mon, 30 Jun 2014 11:31:21 -0700

> that's preferred by the WG.
I got in touch with the moderators.  The list discussion is still charter
oriented, so I'm moving any discussion of this proposal to
[email-masked].  Hopefully the charter discussion wraps up soon.

Thanks,
-Wei

---

From: "John R Levine" <[email-masked]>
Date: 30 Jun 2014 14:52:58 -0400

> more) of doing the diff.

There's a major practical difference: the message wrap hack is essentially 
a single message digest. List managers already have code to build digests, 
and MUAs can display them, if not always very beautifully.  Lists do not 
have code to save the original message, then later use some diff'ing 
algorithm to create new message parts that no MUA knows how to display.

> today with DMARC.  What tweaking do see you will be required?

Incoming mail filters will have to look at the diffs and apply some yet to 
be invented heuristics to analyse the them and decide whether the before 
and after versions are "too different".  I have no idea what a 
satisfactory definition of "too different" is, and would be surprised if 
anyone else did.  There isn't even a generally accepted version of diff 
syntax -- programs like the freeware "patch" have extensive heuristics to 
try to decode all of the various diff formats they have to deal with.

Anyway, the two of us have been arguing in a vacuum.  Let's see what other 
people thing.

Regards,