Hello, > Why not installing xmail in a sandbox?
Good call :) I am planning on using a freebsd jail for it eventually, just testing the waters right now. Allthough if the jail/sandbox is broken into, the problems with the current permissions still apply and the cracker can still read the emails and get passwords and other info out of the mail, as well as forge mail. One of the easiest ways to get access to a box is to get the pass from a less secure source than the actual box, such as a personal computer or "public" box where email may be stored. And since most everyone uses 1 or a few passwords to cover the entire expanse of their logins, getting one pass makes getting the others all that much easier. Don't get me wrong, I really like Xmail and think Davide has done an incredible job with it. I can imagine hundreds of reasons why "it should be ok as-is because ___ or if you ____"; what I can not see is a single good reason to *not* have it use sane permissions of 600 or even 660. I'm sure there is a possible reason, but I've yet to hear it. Maybe the chmod or setting the umask would have a performance impact ? Is it not compatible without other non-unixish systems ? Is there some sort of filter that drops privs and still needs to edit these files ? I'm fairly determined to have it set permissions the way I feel it should be, so I'll shut up about it and take a stab at editing the code (<3 OSS). If it works out I'll submit a patch, however I wouldn't be so bold as to expect it to be added to releases. If I can manage it, I'll put up a little site with it and all my perl filters. Thanks for the suggestions, Darren - To unsubscribe from this list: send the line "unsubscribe xmail" in the body of a message to [EMAIL PROTECTED] For general help: send the line "help" in the body of a message to [EMAIL PROTECTED]
