Subject: [dmarc-ietf] advice to MTAs

From: Vlatko Salaj <[email-masked]>
Date: Sun, 8 Jun 2014 00:25:10 -0700 (PDT)

imo, what all current DMARC deployments lack is notice to
end receiver mailbox about any DMARC validation done on a
particular message, and how it validated.

thus, similarly to Franck's Advice to MUAs, i would propose
adding this kind of txt to DMARC draft:

"DMARC participating MTAs SHOULD include Authentication Results
for all underlying protocols (SPF/DKIM), as well as such results
for DMARC validation itself, among headers of original messages,
during DMARC processing, so they are delivered to end user's
mailbox with the message.

If a participating MTA decides to uphold this advisory, it MUST
at least display:
1. IP address used for SPF validation,
2. domain used for DKIM validation,
3. domain used for DMARC alignment validation,
4. strings used to perform these validations against:
  a. MAIL-FROM and HELO/EHLO in case of SPF,
  b. DKIM signature domain,
  c. Domain-Owner's "asfp", "adkim", "p=" and "sp" DMARC tags,
     in case of DMARC validation,
5. results of each validation and human readable version of it,
if provided by corresponding protocol and if possible, including
any policy overrides.
"

be free to take my txt and fix it, i know it needs refinement.
but i hope the general idea is understood and considered valid
and useful.

this requirement may be more realistic to happen than MUA
design change, imo.

-- 
Vlatko Salaj aka goodone
http://goodone.tk

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 8 Jun 2014 08:30:33 -0700

On Sun, Jun 8, 2014 at 12:25 AM, Vlatko Salaj <[email-masked]>
wrote:

> [...]

That's interesting.  I imagine I assumed they were all (or would all be)
doing that already, so it wasn't made explicit.

I'm not so sure about the SHOULD because the only interoperability A-R
enables is stuff between the verifiers and the MUAs and humans, really.  It
certainly wouldn't be a bad idea for us to highlight how useful it would be
though.

It is mentioned in Section 6, but the mention there doesn't even say that
it's the DMARC result that's supposed to be recorded.  That bit at least
needs to be fixed.

Anyone else have a comment?

-MSK

---

From: Franck Martin <[email-masked]>
Date: Sun, 8 Jun 2014 11:33:13 -0500 (CDT)

----- Original Message -----

> From: "Murray S. Kucherawy" <[email-masked]>
> To: "Vlatko Salaj" <[email-masked]>
> Cc: [email-masked]
> Sent: Sunday, June 8, 2014 5:30:33 PM
> Subject: Re: [dmarc-ietf] advice to MTAs

> On Sun, Jun 8, 2014 at 12:25 AM, Vlatko Salaj < [email-masked] >
> wrote:

> That's interesting. I imagine I assumed they were all (or would all be) doing
> that already, so it wasn't made explicit.

> Anyone else have a comment?

We based DMARC spec on the From header because it is visible to the end user. I understand it is hard to indicate a UI design specification, but we should advice MUA that this header and especially the domain name(s) found there are important, and they should remain visible and easily readable (in a non confusing way) to the end user. 

So I'm happy with advice to MTA, and I still think we should do an advice to the MUA, by telling what is important to us.

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Mon, 09 Jun 2014 02:09:14 +0900

Franck Martin writes:
 > So I'm happy with advice to MTA, and I still think we should do an
 > advice to the MUA, by telling what is important to us.

I think the BCP is the appropriate place for recommendations to the
MUA.  SPF, DKIM, and DMARC are a couple of protocol layers lower than
what MUA developers are interested in; they aren't going to read the
technical spec for DMARC.

The A-R field is another matter: see my reply to Murray.

Steve

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Mon, 09 Jun 2014 02:18:52 +0900

Murray S. Kucherawy writes:

 > I'm not so sure about the SHOULD because the only interoperability
 > A-R enables is stuff between the verifiers and the MUAs and humans,
 > really.  It certainly wouldn't be a bad idea for us to highlight
 > how useful it would be though.

I'm in strong agreement with the "SHOULD" (at least).  If we want to
ask the MUA developers to do something to inform the end user about
authentication results, we sure as shooting should put our protocol
where our mouth is by putting in a requirement that MTAs give them
that information.

I have no opinion about the specifics of Vlatko's list, and I also
suspect that it might want to be "SHOULD provide these A-R data *by
default*," with the nuance that MTAs can provide a configuration
option to reduce the chatter.  (They're presumably logging all this
information, right?  A-R is a convenience for MUAs, sysadmins can use
the logs although they too might find an A-R field very convenient.)

---

From: Dave Crocker <[email-masked]>
Date: Sun, 08 Jun 2014 22:24:12 +0200

On 6/8/2014 7:18 PM, Stephen J. Turnbull wrote:
>  If we want to

Having a requirement that specific information be made available to the
UI is one thing.

Having a requirement that anything be presented to users is quite
another.  For the latter, relevant empirical justification is required.
 Absent that, it's just guesswork about utility -- or worse, runs
counter to what is known -- and that has no place in a formal standard.

d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Hector Santos <[email-masked]>
Date: Sun, 08 Jun 2014 16:45:45 -0400

On 6/8/2014 11:30 AM, Murray S. Kucherawy wrote:
> On Sun, Jun 8, 2014 at 12:25 AM, Vlatko Salaj <[email-masked]
>
> That's interesting.  I imagine I assumed they were all (or would all
> be) doing that already, so it wasn't made explicit.
>
> enables is stuff between the verifiers and the MUAs and humans,
> really.  It certainly wouldn't be a bad idea for us to highlight how
> useful it would be though.
>
> It is mentioned in Section 6, but the mention there doesn't even say
> that it's the DMARC result that's supposed to be recorded.  That bit
> at least needs to be fixed.
>

Only that it goes back to the similar SPF thing regarding dynamic 
rejections. So to be consistent for DMARC:

   DMARC POLICY A-R Trace Guideline

   REJECT     --> N/A see 55x reply codes.
   QUARANTINE --> SHOULD record with A-R.
   NONE       --> SHOULD record with A-R.

-- 
HLS

---

From: Vlatko Salaj <[email-masked]>
Date: Sun, 8 Jun 2014 14:57:39 -0700 (PDT)

On Sunday, June 8, 2014 5:30 PM, Murray S. Kucherawy <[email-masked]> wrote:

> I'm not so sure about the SHOULD

i would stay with SHOULD/MUST combo. i would, actually, even
suggest it to be MUST/MUST combo, but i leave that to general
consensus, as there may be reasons not to go so strong, which
i'm not currently aware of.

however, 1st paragraph should b stronger than RECOMMENDED, imo,
cause i believe such information is quite helpful and very
informative in number of ways to end users in case of issues,
and especially to various levels of support and administration.
also, it is a fact most current MTAs include A-R for
SPF/DKIM, and ASAICS such practice is rather a common standard
now, so i would go with a SHOULD, simply to be in line with
what seems to be usual for MTAs today.

when it comes to 2nd paragraph's MUST, if there r any
operational objections or reasons why would any particular
implementation have to lower these requirements in its use case,
i'm perfectly fine to switch it to SHOULD SHOULD combo.
however, if there aren't any, SHOULD MUST is preferred by me.

anyway, i do suggest we review the list of items in 2nd paragraph,
as i may have left something important out, or listed something
irrelevantly redundant.

i'm not sure how to process "pct" tag exactly, in sense of
DMARC A-R info, to make it obvious, but minimalistic,
but that's something we may want to include also.

ofc, my txt needs RFC tags where appropriate, but i'm sure
Murray will include them as a matter of good document writeup,
which does seem to be one of his talents, as i didn't have any
issues reading any spec he authored before.

> It is mentioned in Section 6

yes, it was my original idea to add advice to MTAa to s6,
with some adequate transformation of the original txt, but
i leave that to u, as the document author, to handle,
since u would do it better than me, or we can cooperate on
wording, if u prefer.

imo, the same section, in addition to advice to MTAs,
would do good to include some wording of advice to MUAs
from Franck's suggestion.

i do think, however, that any design proposals should be
as minimalistic as possible, since that's a whole other area
of expertise, problems and requirements we cannot possibly
hope to evaluate adequately, and, ofc, we need to leave
creative freedom in hands of designers.

so, i do support to RECOMMEND MUAs to make prominence
of a validated FROM domain in their implementations, or,
at least to mention it as MAY. if DMARC succeeds in its
premise to validate authorised email, domain validation
information could become quite useful to design choices
in MUAs, making some distinction between DMARC-validated
and regular email.

-- 
Vlatko Salaj aka goodone
http://goodone.tk

---

From: Terry Zink <[email-masked]>
Date: Sun, 8 Jun 2014 21:31:30 +0000

>  Hector Santos <[email-masked]> wrote:
>

> NONE       --> SHOULD record with A-R.

In our implementation, we also plan to indicate the following scenarios:

1. DMARC fails but the pct value indicated not to take action (i.e., pct=80, this message failed but is in the 20% of cases not to take action) at which point we would stamp "dmarc=fail action=pct.quarantine"

2. DMARC fails and the action is reject but we overrode the requested action (i.e., for a mailing list) at which point we would stamp "dmarc=fail action=o.reject"

Others may feel that this is not necessary (of think this syntax is not clear enough) but we do it for troubleshooting -- "This domain's DMARC action is reject. Why is it in my junk folder?"

--Terry

---

From: "John Levine" <[email-masked]>
Date: 9 Jun 2014 06:49:16 -0000

>Anyone else have a comment?

Recording stuff in A-R is fine.  Advice about how MUAs should display
them is not.  Considering the dismal history of browser warnings about
bad SSL certs, I would expect any user interface advice we give to be
counterproductive.

R's,
John

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Mon, 09 Jun 2014 17:54:41 +0900

> bad SSL certs, I would expect any user interface advice we give to be

Agreed.  However, in case of "p=quarantine", IWBNI MUAs told the
reader that there's a reason Aunt Sally's birthday greeting is in the
spam folder, and it's more than just the that fact that she emailed
you 27 invitations to join her Amway downline last month.

Similarly in case of bypassing DMARC by wrapping the message, or a
length limit on the DKIM signature, IWBNI the unauthenticated parts of
the message were given a "nice UX" treatment semantically equivalent
to displaying it in grey45 on grey50, adding a big warning in red
explaining that From: header can't be trusted and clicking on links is
not advised, and a button to make it readable (and make the annoying
warning go away).

I understand the reservations you and Dave are posting about trying to
make concrete suggestions about UI/UX in RFCs.  Still, unless we get
closer to the end-user wetware than simply adding an invisible
Authentication-Results field, the phishers are just going mimic our
workarounds or create their own.  Best would be direct coordination
with the major MUA teams, but we should also document the semantics
we'd like to convey.

---

From: "John Levine" <[email-masked]>
Date: 9 Jun 2014 14:00:46 -0000

>not advised, and a button to make it readable (and make the annoying

People made this suggestion for l= DKIM signatures, too.  It strikes
me as hugely confusing, since it provides no useful answer to "should
I believe this message or not?"  Someone thinks it's bad, but it looks
OK.  Who do I believe?

A note about why a message was put in the spam folder seems OK, since
it is not demanding that the user make a security decision.

R's,
John

---

From: Barry Leiba <[email-masked]>
Date: Mon, 9 Jun 2014 11:15:18 -0400

> We based DMARC spec on the From header because it is visible to the end
> user.

Yes.
Unfortunately, that's sort of a red herring.  Most email clients show
the "pretty text" of the From (the display-name ABNF construct) if it
exists, and actually *hide* the actual address (the addr-spec ABNF
construct).

Putting as much value on RFC5322 From as DMARC does follows
conventional wisdom, but I believe that wisdom is flawed.

Of course, that speaks to the advice you want to give: tell UIs that
they should show the From addr-spec to users always.  But be clear
about what you're asking for: you're not saying they should do it
because it's objectively "right"; you're saying they should do it
because it helps support the decision that DMARC has made.

Barry

> I understand it is hard to indicate a UI design specification, but we
> should advice MUA that this header and especially the domain name(s) found
> there are important, and they should remain visible and easily readable (in
> a non confusing way) to the end user.

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 09 Jun 2014 12:12:19 -0400

>because it helps support the decision that DMARC has made.

If any authentication technology is going to work, DMARC or whatever, it will have to be tied to some kind of identifier.  5322.From is as good as any and better than most. 

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 9 Jun 2014 09:46:23 -0700

> because it helps support the decision that DMARC has made.

There are some other options that are particularly interesting.  For
example, I'm told that Gmail will only show the display-name if the email
address in the From field is also in the user's address book and the
message authenticated.  Otherwise, it shows the email address.

Naturally, we can't rely on all MUAs doing that any time soon, and we don't
really have much ability to nudge them in that direction either.

-MSK

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Tue, 10 Jun 2014 01:54:39 +0900

John Levine writes:

 > People made this suggestion for l= DKIM signatures, too.

l= DKIM signatures are a bad idea, precisely because in existing MUAs
there will be no indication of what is covered by the signature, and
what not.  "Nobody" does that.

But now mailing lists and other mediators are going to be
systematically sidestepping DMARC, but (as we've seen with Yahoo!
Groups already) still using "p=reject" mailboxes as identification.
We know this is going to happen on a large scale.

 > It strikes me as hugely confusing, since it provides no useful
 > answer to "should I believe this message or not?"  Someone thinks
 > it's bad, but it looks OK.  Who do I believe?

You believe what you believe, of course.

The problem with the usual browser notification about unverifiable
certificates is that it is too technical for most users to grasp, and
they are unable to perform the necessary operations to determine
whether it's secure.  I don't know how to do any of this right, but
surely it's worth trying to do better than we do it now.

 > it is not demanding that the user make a security decision.

ISTM that's just a different UI for the same semantics.

I don't understand what you mean by "not demanding that the user make
a security decision."  If they continue reading the message ("because
it's from Aunt Sally"), and take action on it, they may be defrauded.
If they leave the message alone until they get corroboration through
other channels, the probability is much less.  In that sense they are
making a security decision.

Steve

---

From: "J. Gomez" <[email-masked]>
Date: Mon, 9 Jun 2014 20:53:30 +0200

On Monday, June 09, 2014 10:54 AM [GMT+1=CET], Stephen J. Turnbull wrote:

> John Levine writes:
> 
>  > Recording stuff in A-R is fine.  Advice about how MUAs should
>  display > them is not.  Considering the dismal history of browser
>  warnings about > bad SSL certs, I would expect any user interface
>  advice we give to be > counterproductive.
> 

+1

I couldn't agree more.

DMARC should not stay only in the MTA realm, after all DMARC deals with the Header-From just because that's something the final user SEES, and not because that's something the MTA naturally deals with.

Therefore DMARC should leak to the final user who SEES that Header-From, and that means MUAs have to enter the big picture of DMARC, somehow.

And yes, that "somehow" is the difficult part, but it should not be left aside, I think.

And I think the recommendation to MUA authors should go into the standard itself, not on a side document (BCP or whatever) which may or may not be easy notice/find/know-about.

Regards,
J.Gomez

---

From: "J. Gomez" <[email-masked]>
Date: Mon, 9 Jun 2014 20:58:32 +0200

On Monday, June 09, 2014 5:15 PM [GMT+1=CET], Barry Leiba wrote:

> > We based DMARC spec on the From header because it is visible to the
> > end user.
> 
> Yes.

I think that "asking for that" is both because it is "right", and because "it helps support the decision that DMARC has made".

DMARC is a security framework. If it helps DMARC, it is both things at once.

Regards,
J.Gomez

---

From: Barry Leiba <[email-masked]>
Date: Mon, 9 Jun 2014 22:38:54 -0400

> If any authentication technology is going to work, DMARC or whatever,
> it will have to be tied to some kind of identifier.  5322.From is as good
> as any and better than most.

And yet SPF uses a different one (5321.Mail.From), and there've been
suggestions to use Sender, rather than From, if Sender is present, or
to check both.  There's no one "right" answer, and all have failings.

If a spec is going to suggest UI changes to match the choices that
spec has made, it needs to be clear about where those suggestions come
from.  And the people making the recommendations need to understand
that their recommendations might be wildly in conflict with what UI
experts know to work best for users.

Barry

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 09 Jun 2014 23:17:12 -0400

> experts know to work best for users.

When developed, SPF had a different design goal, bounce reduction.  Any anti-
phising/anti-spam benefit was really a side effect.  No U/I exposure was needed 
for it to be successful.  You've got to hang your hat on one identity.  The 
wild market success of Sender ID is possibly instructive of the implications 
when you don't.

As has been discussed more than one time, if you allow Sender and From, then 
arbitrary Sender's can send mail that will pass with an unverified 5322.From 
(either the address or maybe just the pretty name) being all that's displayed 
to the end user.

Perhaps I'm oversimplifying, but it has seemed self-evident that you need a 
single identifier that is displayed to the end user and 5322.From is the only 
identifier that even comes close to being the right one.

Scott K

---

From: Hector Santos <[email-masked]>
Date: Tue, 10 Jun 2014 07:43:09 -0400

> experts know to work best for users.

+1.

What is an UI expert? I have at least 4-5 MUA products, tools, under 
my belt; text-based, native gui-based, web-based, API-based, etc, a 
tremendous amount of consideration is made in how/what is displayed to 
the user, bells and whistles, and you know what, you can do a great 
job, and its still not perfect. In fact, sometimes the best thing to 
do is to do less, following Pareto's principle works very well.   Take 
a look at some of the current reinvention simple ideas for 
communications fall back to the basic UI simply to make it "fit to 
print/display."

There are two parts to this identity:

   - using it as an strong anchor for domain policy,
   - using it for displaying to the user.

At the end of the day, its about consistency, and what we are talking 
about is basically what will be passed to the mail readers. For the 
IETF, its about 822/2822/5322 and the different mail access portals. 
We have currently within the IETF; POP3, NNTP and IMAP.  Afair, there 
is no IETF RFC for a web-based Mail Access Protocol Inteface ("MAPI").

If we have control of the backend, you can do all sorts of things, but 
ultimately, what is the goal here?

   - Backend filter the message for the user, don't pass it?
   - Pass it with highlights?

If the user has a conference based MUA, like the old MAPI exchange, 
IMAP, or even Newsreaders, then you can move non-rejected bad mail 
into special folders the user still has access to.

If the user only has POP3, then the backend has to decide to filter 
the message unless it knows the MUA will be filtering it.

Anyway, one of the central "battles" if we want to call it a battle, 
is the philosophical differences about what is to be done with 
"rejectable" mail.  5321 finally recognizes the probability of 
discardable mail, that was due to the pending ADSP proposed standard 
that would of provided technical authorization to operating in this mode.

Yet, there are still folks here that believe that rejecting mail at 
SMTP is a "fantasy" not a "reality" and that all mail is always passed 
to users.

I say, we are only dealing with the indeterminate mail, the relaxed, 
the "half-failed",  the mail the backend can't make a decision and 
needs to just forget about it and pass on.  The hard failures are 
really not a problem. They may have some False Positive yield, but it 
is extremely low to non-existence (set it and forget it).

No, instead we are fighting, wasting so much time, about what to do 
with highly detectable rejectable mail based on a policy system.

I go back to RFC5016, where at the last minute, this itemized section 
5.3 provision was added:

    10. SSP MUST NOT provide a mechanism that impugns the existence of
        non-first party signatures in a message.  A corollary of this
        requirement is that the protocol MUST NOT link practices of first
        party signers with the practices of third party signers.

          INFORMATIVE NOTE: the main thrust of this requirement is that
          practices should only be published for that which the publisher
          has control, and should not meddle in what is ultimately the
          local policy of the receiver.

          Refs: Deployment Consideration, Section 4.3.

We still haven't gotten over this hump.  I had warned backed then this 
would be a conflict and it was never was resolved.  That MUST NOT is 
still a strong influence, especially among the LSP (List Service 
Provider) who feel threaten by strong Author Domain policy protocols.

Its a fundamental concept that if a DMARC WG was started, it would 
have to be revisited because if the above concept is still applicable, 
then I have a hard time seeing any resolution to any of this.

-- 
HLS

---

From: Hector Santos <[email-masked]>
Date: Fri, 13 Jun 2014 21:38:28 -0400

> 1. DMARC fails but the pct value indicated not to take action (i.e., pct=80, this message failed but is in the 20% of cases not to take action) at which point we would stamp "dmarc=fail action=pct.…

Sounds reasonable.  Haven't implemented DMARC yet, but I got the fast read understanding "pct" was for reporting triggers. It is not factored in when a reject is triggered? 

> 2. DMARC fails and the action is reject but we overrode the requested action (i.e., for a mailing list) at which point we would stamp "dmarc=fail action=o.reject"

Is "action" is a registered tag?

> Others may feel that this is not necessary (of think this syntax is not clear enough) but we do it for troubleshooting -- "This domain's DMARC action is reject. Why is it in my junk folder?"

For ADSP, the same level of diagnostic consideration was done because we were still in recording mode, not yet enabling honoring the discard policy yet. DMARC changes all this now. FedEx.com and other high value domains use both ADSP discard and now DMARC rejects, so when DMARC is added, both will have a common handling engine.

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

---

From: Hector Santos <[email-masked]>
Date: Fri, 13 Jun 2014 22:35:48 -0400

> On Jun 9, 2014, at 11:17 PM, Scott Kitterman <[email-masked]> wrote:
> 

And that comes from two key concepts, it was historically never expected to be altered (for any communication system past and present) and its the minimum default identity for replying.

---

From: Patrick Rauscher <[email-masked]>
Date: Sat, 14 Jun 2014 11:25:23 +0200

Hey,

> > identifier that even comes close to being the right one.

(I don't have Scotts original mail here, so I reply to this. Sorry!)
Imho 5322.Sender is relevant too. Yes, MUAs usually don't respect this
Header (and it's used not very often :-( ), but most don't show
DKIM-Validation (which could be included together).

Also this allows Mailinglists to interact with DMARC/DKIM correctly
(hint hint)

Greetings,
prauscher

---

From: Hector Santos <[email-masked]>
Date: Sat, 14 Jun 2014 13:12:59 -0400

> On Jun 14, 2014, at 5:25 AM, Patrick Rauscher <[email-masked]> wrote:
> 
> Hey,
> 

Some do have new display logic for the sender.  However, unless you (the backend) have control of the mail reading process, both online and offline/offloaded,  in general you don't, we can only be pretty confident of what would be displayed with the four basic messaging fields common in all communications as a common denominator:
 
  o Date
  o From
  o To
  o Subject

In other words, if you were to start tomorrow to write a mail reader/writer, you must begin with the above for the minimum display rendering.  Remember, not everything is or requires a mail network. It can be an online forum which many systems are heading back to (or just starting with successfully because they are not bogged down like many older established systems are where change is not always a luxury).

You really have two sets of headers: the above messaging headers and networking headers.   Networking control lines, as old FidoNet folks called them, only came into play when you connected a heterogenous network of hosting nodes. For internet mail format networking, the Sender, Reply-to, Return-Path, most of the trace lines, did not apply until you had a network. When you gated a network,  generally, they would be use just to make sure you can respond back and they would be hidden, transparent to the user. Sometimes the user may  only interested in them to go a different route, reply directly or have it travel via some path that was either less costly or more timely, i.e., network routing methods.

Subject is not always filled, but is expected to be part of the message.  Some MUAs enforce it, others don't.  In fact, RFC 822 only required Date, From and To.  RFC 2822/5322 relaxed it to only Date and From.  Date can always be filled as the local or system post time.  So at a minimum, via RFC 821 5321, if a client doesn't enter the headers during, depending on how strict the deployment is set at, it doesn't need them when receiving the DATA payload and can recreate the 822/5322 headers from the SMTP envelope fields:

  5322.From <=== 5321.MAIL FROM
  5322.Date <=== system timestamp
  5322.To <=== 5321.RCPT TO

And you really don't need to fill in the 5322.To because for local direct mail pointers, indexes, this is done using a different control/meta method/file/line from the 5321.RCPT TO lines. You don't rely on the 5322.To or cc to make direct mail references.

> Also this allows Mailinglists to interact with DMARC/DKIM correctly

Operators will have philosophical differences with developers. Always have. In my product development experience, it is good to get practical functional operational guidelines established and bad when sound technical engineering progress is impeded.  The ML needs to fit in with the mail network like everything does with the few known long time acceptable exceptions. DKIM did highlight the body integrity issues, not the 5322 headers. We don't want to add a broken 5322.From to the security exception list.