Just got an interesting project...

[Eric "Shubes"]

I use and am active with the qmail-toaster project
(http://www.qmailtoaster.com).

I took a look at qmail-pop3d.c, and it uses the unlink function to remove
the message files. It'd be simple to change that to a system call to
'shred', but I expect that would slow down the pop3d session considerably.

If IMAP is being used to access messages (as I expect it is), the
corresponding IMAP software would need to be changed. What email client(s)
are they using?

Another question: do you need to shred messages when they're removed from
the various message queues?

Note, as JT mentioned, shred is not effective on journaled filesystems. I
suppose you could put the Maildir's on an ext2 partition.

To make this work smoothly, I would think that a shredding daemon might be
the ticket. That would be a bit more entailed than simply changing an unlink
function though.

George Toft wrote:
> Anyone up to the task of changing the source?  This is a for-pay 
> project, and if you can deliver, I can put it in the proposal.
> 
> George Toft, CISSP, MSIS
> 623-203-1760
> 
> "That which does not kill us makes us stronger."
> 
> 
> 
> Eric "Shubes" wrote:
>> George Toft wrote:
>>
>>> Requirements:
>>> 1. Deleted files (say, qmail messages after pickup) are shredded upon 
>>> deletion.  Immediately upon delete.  Since an application is performing 
>>> the delete, I must assume "rm" is not being issued, so I can't 
>>> substitute "shred" in its place.
>>>
>>> 2. Files owned by vpopmail:vchkpw can only be read by said user:group - 
>>> this includes root.  We need to lock root (and every other user) out of 
>>> the messages.
>>>
>>> 3. Encrypted file system to defend against physical theft.
>>>
>>>
>>> #3 is easy.
>>>
>>> #2 sounds like a job for SELinux.  Alternatives are welcome :)
>>>
>>> What about #1?  Any ideas?
>>>
>> Change the source and rebuild? Should be fairly easy with qmail as it's
>> distributed as source. Other applications might not be as easy.
>>


-- 
-Eric 'shubes'