> Qualcomms POP servers have this problem as well, on linux, solaris, etc. > Except the lock file gets stored where ever your users mail is stored. > /var/mail(on a sun) or where ever. I guess a nice solution would be to have a > subdirectory with mode 700 permissions under /var/mail/locks or something like > that where only the popper can write to. Or just ignore the lock if the owner > of the lock file is diffrent thant the userid of the person popping their > mail. The terminology and extensions used here are getting a little muddled, so I'm going to edify for others who may be confused: username : mailbox .username.pop : temporary mailspool location, effectively locks POP .username.lock: lockfile for "real" mailspool, locks LDA qpopper has a compilation option to specify an alternate directory for the .pop files. From the INSTALL file, section 7f for Qualcomm's popper version 2.53: POP_DROP - When qpopper runs, it moves your mailspool to a temporary location (.user.pop). The default location is in the mail spool directory. /tmp is an alternative but is considered to be a security risk. A system reboot usually clears the temporary .user.pop files. For performance reasons, a sysadmin who has 1000+ users can create a separate spool directory for qpopper files; /usr/spool/poptemp is preferable. Permissions should be the same as your mailspool with the same owner and group. Edit the value of POP_DROP in config.h. For Eg: #define POP_DROP "/usr/spool/poptemp/.%s.pop" Of course, if /usr/spool/poptemp is set 1777 you still have problems with other people creating .pop files if they have local access to the mail server. As you suggested, a better solution would probably be similar to what procmail does -- if a lockfile is detected and is not owned by the user for whom the temporary mailspool is being created (excepting root, as of version 3.14), it is overwritten with a new one using proper permissions and ownership. qpopper 3.0 is out, and although it boasts "improved mailbox locking code," a cursory glance at the code *appears* to reveal the same issues. I'll set up a testbed to make sure. Just to be clear, the worst thing that someone can do with this is a DOS against POP requests for targeted users. Chris
