> Don't. Pop-before-smtp is an ugly hack which was only really implemented > as a quick workaround kludge until smtp auth was developed, standardised > and widely available.
I think you guys are too hard on pop-before-smtp. Granted it is a kludge and should be avoided it you can. But we have used it for several years with no problems except that a couple times the daemon stopped for no apparent reason and had to be manually restarted. If you primarily provide Internet connectivity as we do, the best policy is to only relay for clients on your network. If a few customers connect through another ISP, tell them to use their ISP's outgoing mailserver, this is the standard solution. If they have a T1 or a premium DSL with static IP, then we will enter their IP in our relaying database. If they're too cheap to spring for a static IP on their DSL, or they are using another ISP's dialup and are too inept to enter that ISP's outgoing mailserver, tough luck. Or they can use our WebMail server, that's another solution. If you primarily provide webhosting and email accounts but not connectivity, then SMTP AUTH is the standard solution. If you are a private company, and you have remote/mobile/SOHO clients, things are less clear. My preference would still be to use the ISP's outgoing mailserver. But you may have a policy that all sent mail goes through your server, maybe so you can log it or screen it for viruses and/or content. Also you probably have more control over the email clients that your employees use and you probably set it up for them. In this case you may want to use SMTP AUTH or even non-standard mail like Exchange mail. We don't like SMTP AUTH because it is not practical to make all our customers use it just to accomodate the few who need it. And if we enable it on our server, we have problems with our many Mac users with Netscape 4.x clients which seem to choke if the server offers AUTH but the client is not set up for it. Again, WebMail is an alternative. We use EmuMail which is basically a web-based POP3 client, we actually run it on the same server as qpopper but it can just as easily (and probably better) be on a separate server.
