Re: need a sane approach to MIME attachment organization

Mike's unattended mail squawked out on Sunday 21-Oct-2012@05:04:33
> 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).

Actually, you don’t. Processing the file does not necessitate stripping the file.

>  * you have a duplication between your mail-embedded file (which
>    lasts as long as your archives), and the proper file.

For certain definitions of ‘the proper file’ I suppose. To my mind, the original message stays intact, period. Anything you do after that should never change the messages that was received.

>    Thus wasting space,

As I said, if space is an issue, limit the size of attachments. Encourage users to delete unneeded email.

My email archives, including attachments, for my personal mail are under 5GB and go back to 1999, and I never delete anything but spam. That’s a trivial amount of space.

>    and degrading the performance of the MUAs
>    operations on large mbox files.

unless you are still using mbox files, large attachments have basically no impact on MUAs, only the count of messages in the folder are an issue.

>    The space waste and potential for
>    excessive mbox files is in part due to keeping the file as an
>    ASCII payload.

No one who is serious about email should be using mbox files. They are great when a really large mailspool was 1 megabyte. They are quite terrible with mailboxes that are hundreds of megabytes or more.

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

This is a good thing.

>  * if you opt not to duplicate the file in the filesystem, then
>    finding the file later on is non-trivial

Depends entirely on your MUA. finding attachments in my MUA is trivial.

>> 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.

Well, yes. That’s what I do.

>  This use case is quite different from that of a single user filtering their own mail.

Yes, that is entirely different/ what you do with YOUR mail after it’s delivered is entirely up to you.

> 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.

Yes, I have recipes like that as well. Your original message didn’t lead me to believe you were talking about your personal mailspool.

> 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,

Which should be done prior to accepting the email for delivery.

> while simultaneously giving the user access to the body of the message (which may very well be legitimate and have no malicious intent).

That seems an odd stance to take. If a mail contains harmful content, it is de facto a harmful message and should be rejected at the transaction phase. This lets the sender know the message was not delivered and they can take steps to deal with the issue.

>> 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,

procmail was written long before MIME email became common.

> while it's inappropriate to impose this kind of flexible
> automation on a MUA.


-- 
I told you...<BLAM BLAM BLAM BLAM> Don't call me Junior.