Mike's unattended mail squawked out on Sunday 21-Oct-2012@05:04:33
On 2012-10-21, LuKreme <kremels(_at_)kreme(_dot_)com> 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.
____________________________________________________________
procmail mailing list Procmail homepage: http://www.procmail.org/
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)de
http://mailman.rwth-aachen.de/mailman/listinfo/procmail