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.
(3) Keep a backup of all email. I have my personal MTAs (running
Postfix) keep a copy of all email that passes through them. If
something somewhere (procmail/maildrop/imapfilter/whatever) drops the
ball I can always go to my mail backup account and recover the mail
item. Yes this doubles mail storage requirements, but you know what -
disk is cheap[1].
If you're telling fetchmail to invoke Procmail or Maildrop directly,
aren't you *bypassing* Postfix processing?
The comment I replied to specifically mentioned passing to an MTA.
In any case you can potentially do it upstream, which is what I do. I run
my own MXs which bcc backup all email before passing it on.
Also, disk is only cheap if you have the money to spend. Not everyone
does. But that's just an aside.
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.
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.
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.
Rob
--
Email: rob...@timetraveller.org Linux counter ID #16440
IRC: Solver (OFTC & Freenode)
Web: http://www.practicalsysadmin.com
Director, Software in the Public Interest (http://spi-inc.org/)
"Information is a gas"
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/alpine.deb.2.00.1301231049490.30...@pollux.opentrend.net
