Re: Just got an interesting project...

Top Page
Attachments:
Message as email
+ (text/plain)
Delete this message
Reply to this message
Author: George Toft
Date:  
To: Main PLUG discussion list
Subject: Re: Just got an interesting project...
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.
>>>
>
>
>

---------------------------------------------------
PLUG-discuss mailing list -
To subscribe, unsubscribe, or to change you mail settings:
http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss