Just got an interesting project...

[George Toft]

I can make the FS any type that will accomplish the desired results.

Once I meet with the client, I can find out if he is using pop or imap, 
and look into using certificates to preclude username/password attacks.

George Toft, CISSP, MSIS
623-203-1760

"That which does not kill us makes us stronger."



Eric "Shubes" wrote:
> 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.
>>>
> 
> 
>