Richard Clayton writes:
> >+1 to hashing MIME parts separately.
>
> without providing new forms of recipe I don't see how this helps
> anything -- the recipe is fundamentally the same if you remove 100
> lines or if you remove a 100 line MIME part
If you would want to hash mime parts separately, that would of course
need new recipe formats. (And I am not saying we should do that, I was
just saying it can be done if it is needed).
> BTW: you can also have a LOT of MIME parts, most days I make a half-
> dozen emails with 50 MIME attachments, but that's a bit odd of
> course.
Not that odd, it is actually very common, when people are sending
pictures to each other. I.e., after a party somewhere, people quite
often send tens of pictures they have taken to other people. Not
everybody have an east way to put pictures in some publicly available
web site, or create an album in cloud whose address they can share.
User will simply use their phone, and add images as attachments to the
email. Sometimes they have to split those emails to multiple separete
emails because of size limits...
> Attachments will underestimate MIME parts by 2 or 3 in most
> messages.
>
> However when I look at data from $DAYJOB$ I see that a typical day
> has a handful of messages with 30 or more attachments, hundreds of
> thousands of message with 20+ attachments and we get into the
> millions at around 12 or 13 attachments.
>
> That's a lot of hashes to put into header fields.
One way to do that would be to add those hashes to the actual
MIME-headers, i.e., create Content-hash MIME header, that will have a
hash of the mime content. Then the security gateway decides that it
wants to remove the windows executable attachment that was included in
the message with a attachment that just has text "This windows
executable was removed". The security gateway would calculate new
Content-hash for the MIME header, and provide recipe that will say
that whole mime content was replaced, the content-hash header was
changed from xxx to yyy, the content-type was changed from
"application/x-msdos-prgram" to "text" etc.
If every mime-part would be mandated to hash content-hash header then
the actual total body hash could be calculated by just hashing all
mime headers in all attachments and not include the actual body parts
in the hashing, as the content-hash that is in mime headers would
already cover that part.
If normal changes to mime parts is done, then they would modify the
body as normally, and provide recipe for them, but then they would
also provide recipe to update the content-hash of that mime part, that
would be used to calculate total body hash.
So there are ways to do that, but as I am not sure whether we should
include complicated body modifications at all, I do not think we want
to do this.
I can see things where someone adds header and footer to the email
body, but anything more complicated would most likely need to be
saying "body was modified, no diff available", i.e., null recipe.
> > A filter whose purpose is removal will choose a null body Recipe
> >and under -09 that means the message cannot be fully verified.
>
> Delivering it seems dumb ... why would I want to receive a message
> that was malicious ? especially in a DKIM2 world where the offending
> message can be correctly delivered back to its origin with an
> appropriate note.
Why do you think it was malicious if someone completely removes a
windows executable from the mail it is forwarding?
Or the mailing list removes the html junk version of the email that
has both useful plain text version and bloated html version.
There are lots of mailing list that prefer text/plain, and will
automatically remove html (mailman filter_mime_types), or even
convert html to text if no text version available (mailman
convert_html_to_plaintext), or will always remove all message
attachments that have specific filename extensions regardless of mime
type (mailman filter_filename_extensions defaults to exe, bat, cmd,
com,pif, scr, vbs, cpl).
Lots of mailing lists will remove complete mime attachments, and
wasn't DKIM2 supposed to be working with mailing lists (and without
null recipe)...
>
> >Perpart hashing gives safety removal a path and the original
> >signature can still be checked.
>
> You can check the 11 (or 30 or 49 or whatever) MIME parts that remain.
> Depending on what was removed (a big JPEG saying "this is all a joke, do
> not take this email literally" ??) the semantic meaning of the message
> may or may not be preserved.
As I said mailing list software do quite a lot of processing on the
mime parts before delivering the emails to the mailing list.
For example the mailman 2.1.35 describes its processing as follows:
Content filtering
Policies concerning the content of list traffic.
Content filtering works like this: when a message is received by the
list and you have enabled content filtering, the individual
attachments are first compared to the filter types. If the
attachment type matches an entry in the filter types, it is
discarded.
Then, if there are pass types defined, any attachment type that does
not match a pass type is also discarded. If there are no pass types
defined, this check is skipped.
After this initial filtering, any multipart attachments that are
empty are removed. If the outer message is left empty after this
filtering, then the whole message is discarded.
Then, each multipart/alternative section will be replaced by just
the first alternative that is non-empty after filtering if
collapse_alternatives is enabled.
Finally, any text/html parts that are left in the message may be
converted to text/plain if convert_html_to_plaintext is enabled and
the site is configured to allow these conversions.
and after that it goes to actual settings related to these. This is
old mailman, so I do not know what features modern versions have, but
usually they do not remove features, juts add even more...
--
[email protected]
_______________________________________________
Ietf-dkim mailing list -- [email protected]
To unsubscribe send an email to [email protected]
