Robert Brockway grabbed a keyboard and wrote: > On Tue, 22 Jan 2013, David Guntner wrote: > >>> (2) Use a catch-all rule at the end of .procmailrc so that even if mail >>> falls through it goes somewhere other than /dev/null. >> >> Also mentioned in the manpage I quoted: It doesn't say that the errant >> filter error sends to /dev/null, but there's a risk a message will end >> up in an unexpected location. > > Yeah, I didn't mean that literally. When procmail drops mail it goes in > to a black hole from which there is no return, as I'm sure you know. I > have straced procmail before but I don't recall what it did with the > mail in the end, it may well drop it to /dev/null.
Actually, in all the (many) years I've been using Procmail, I've never
once had it fall through and just discard the message outright. Maybe
that happens if you've got a rule that *would* route to /dev/null and
the errant test above falls through to it? Beats me. I'm not doubting
you, I'm just saying that in my personal experience, it's never
happened. Maybe I've just been lucky. :-)
> Mail tends to be pretty tiny compared to modern available storage. I
> have 37GB of personal mail which includes many years of list mail as
> well as personal mail. I suspect most people don't have that much.
Agreed. I just tend to balk when someone throws out "disk is cheap" in
general terms; I see it bandied about too often by people who don't take
into account that not everyone has money to spend. Sorry for the
somewhat knee-jerk reaction if that's not what you were doing. :-)
> If you run large mail installations (as I have) there are all sorts of
> great tricks to dedupe mail these days.
>
> Unless you are talking about very large numbers of users mail storage
> requirements are tiny compared to the storage requirements of so many
> other sorts of data today.
I once ran a RS/6000 server running AIX at a university. Disk space was
always an issue since students figured disk space was free (and this was
back in the 90's when those types of SCSI diskpacks cost a bit more than
what you can get for a home computer these days). We finally stuck a
quota on home directories, and I set up a cron job that would look for
mbox files that were bigger than a given size & gzip them up and put the
.gz into their home directory - and if they were out of space, they lost
their mail.
After that, most of them learned pretty quickly to manage their mail
better. :-)
>>> Note: Anyone implmenting a solution like this should take in to account
>>> privacy laws in relevant jurisdictions (where they are, where the MTA
>>> is, etc).
>>
>> I'm not entirely sure how privacy laws come into play here, given we're
>> talking about a way to pull in mail from several sources for an
>> individual, *by* that individual running a cron job or whatever. It's
>
> This comment directly followed and related to the use of the always_bcc
> parameter in Postfix. It will capture all mail passing through that
> MTA, regardless of sender or recipient. Most MTAs serve a large number
> of users. That's where the potential privacy concerns come in.
Sure, I agree with you here. But I was keeping things within the
context of the OP's message asking about this type of thing, where the
OP stated needing a way to collect mail and filter into folders
independent of what MUA was being used, running their own system on a
VM. Within that context, there's no privacy concerns. At the time, I
didn't realize you were speaking in more general terms about larger
multi-user systems. Sorry for the misunderstanding.
--Dave
signature.asc
Description: OpenPGP digital signature
