Re: need a sane approach to MIME attachment organization

On 2012-10-21, LuKreme <[email protected]> wrote:
>
> Leave the messages intact. If we need the attachment elsewhere, that
> becomes a new file. This specific issue is why I moved from Eudora,
> since it strips attachments from messages (and does a few other Bad
> Things as well).

These are the problems with that:

  * you lose the ability to automatically process a file attachment
    and carry out realtime actions on that file the spot (unless you
    keep your MUA running 24/7 and code it to do the job of procmail).

  * you have a duplication between your mail-embedded file (which
    lasts as long as your archives), and the proper file.  Thus
    wasting space, and degrading the performance of the MUAs
    operations on large mbox files.  The space waste and potential for
    excessive mbox files is in part due to keeping the file as an
    ASCII payload.

  * the file must be extracted and potentially decrypted every single
    time it is opened from the message (if not duplicated).

  * if you opt not to duplicate the file in the filesystem, then
    finding the file later on is non-trivial -- a process that is
    weakened by giving up the option to browse for the file in a
    well-organized file structure, in place of a /search/.  An email
    mbox structure may be optimized for more important browsing than
    what would be conducive to file searching.

>> All files should probably be extracted as messages arrive,
>
> I vehemently disagree. All mail that is accepted for delivery has to
> be delivered intact.

You seem to be talking from the standpoint of procmail filtering an
organization with multiple users.  This use case is quite different
from that of a single user filtering their own mail.

If a particular user who controls their own procmail script is
expecting a message with a known structure and a particular
attachment, and the integrity of the message body is unimportant apart
from the file itself, then there is no value to preserving the
original bits.  If there is a forensic need to preserve the original
bits, then of course that option exists already anyway.

In fact, I have particular uses where there is no need to deliver the
message at all.  I need to act on a file attachment contained in an
auto-generated message, process it, and throw away the email.

Even if we consider your position from the standpoint of an
organization using procmail for many users, there is a security need
to inspect and quarantine malicious files, while simultaneously giving
the user access to the body of the message (which may very well be
legitimate and have no malicious intent).

>> Seems like a job for procmail.
>
> MIME and procmail go together about as well as fish fingers and
> banana custard.

That's a shame, because it means that procmail does not perform its
job well in circumstances where automation on inbound MIME objects is
required, while it's inappropriate to impose this kind of flexible
automation on a MUA.