Subject: Re: [ietf-smtp] Survival of arbitrary MIME Content-foo header field?

From: Brandon Long <[email-masked]>
Date: Fri, 3 Aug 2018 10:30:06 -0700

I remember code which strips all of the Content-* foo headers for a part
when modifying that part.   I assume that's generally fine if everything is
being messed with.

Our s/mime code also does specially handling of all content-* headers when
signing/encrypting, so a "new" one is safe there as well.

Brandon

On Mon, Jul 30, 2018 at 12:43 PM John Levine <[email-masked]> wrote:

> >> A few hosts add additional MIME content (advertising, footers), but the
> ones I've paid any attention to seem to do so by
> >fairly crude textual insertion, so probably wouldn't corrupt existing
> content too much.
> >
> >To the extent that the unknown MIME header field depends on the
> >associated content to be unmodified, that's an obvious problem.
>
> The ones I've seen look at the MIME type enough to know whether to add
> text or to rewrite HTML, so they probably would not mess with a
> mystery part.
>
> >However my impression is that such additions by mediators, such as
> >mailing lists or anti-abuse enterprise front-ends, are done to the
> >primary body-part -- the cover note -- and not to any attachments.
>
> Or they splice on a new part and wrap it all in multipart/related.
>
> I'd think a mystery type at the top level would be likely to trigger
> spam and malware filters that not altogether unreasonably assume that
> something mysterious is likely to be evil.
>
> R's,
> John
>
> _______________________________________________
> ietf-smtp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-smtp
>

---

From: Dave Crocker <[email-masked]>
Date: Fri, 3 Aug 2018 10:38:14 -0700

On 8/3/2018 10:30 AM, Brandon Long wrote:
> when modifying that part.   I assume that's generally fine if everything 
> is being messed with.

My interest was in preservation of unknown content-* fields when the 
body-part is being tranfered (relayed or whatever).

If the content itself is being messed with, I'd assume all bets are off 
for its associated meta-data in content-* fields, since really the 
body-part will now be a different object...

> 
> Our s/mime code also does specially handling of all content-* headers 
> when signing/encrypting, so a "new" one is safe there as well.

thanks!

d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net