On Sun, 8 Mar 1998 17:18:00 -0400, BRIAN MC NAMARA <[log in to unmask]> wrote: >here is an issues that I recently ran into. We at the Seminary use 1.8c. >I have run into a security issue regading POP3 mail programs that let you >specify username and domain. To me, it seems that anyone can get to >anylist if they use moderator/owner/system admin username and if they >know the list name. To me this seems like a pretty big security issue even if >there is no way around it. Any ideas out there? Yes, userID and addresses can be 'spoofed' and rather easily faked. This poses 2 security problems. First is merely posting a message to the list, especially a moderated list. The only defense against this is Send= (whatever),Confirm. This requires everyone posting to use the OK-confirmation to OK their own message (yes, even Editors and Owners are not exempt from this). No password is required or possible. By sending the OK confirm back to the address of the sender, and getting a response LISTSERV is 100% sure that sender sent (and now approves) the message. In the case of address spoofing, the OK-confirm goes back to the person whose address was spoofed, not to the spoofer. Thus they are alerted to something funny going on and the msg will not be sent, if not confirmed. The only way around this is if the spoofer has physical use of the users computer, which is possible, but uncommon. While very secure, this method does impose severe user inconvenience, so you have to decide if it's worth it. The second is list commands, changes of SETings, etc. For this, the Validate= Yes header keyword exists. You can read about all the combinations, etc, in the Owners Manual, Appendix B, but basically, this requires confirmation to all commands (except innocuous ones like HELP or INFO or THANKS). The confirmation can be in the form of a Personal Password (known only to that user and to LISTSERV) or by the use of the same OK-Confirmation mechanism. As before, the OK- request goes back to the 'spoofed' address, not to the spoofer. There is even a very secure NOPWD setting, which prohibits the use of a password, and allows only the OK-confirmation method for all commands by Owners or users. PUT commands always require a personal password. Again there is a convenience vs. security issue you need to evaluate for your situation.