NeoMail FAQ ====================== Q. Why aren't HTML e-mails supported? A. Because HTML e-mails are the most abhorrent things that exist in the e-mail world. All self-respecting mail clients that can send HTML e-mail provide an option for sending mails in both plaintext and HTML format, and NeoMail can read the plaintext version of those just fine. Anyone sending their e-mails in solely HTML format is probably someone you don't want to be corresponding with. Malicious Javascript in HTML mails is bad news. Worse yet, many spammers will send their mails in HTML only, and reference an image that is loaded from a server's CGI script, which logs your e-mail address as valid. Q. I still want HTML mail. It's a shortcoming of NeoMail that it doesn't filter out all the possible nastiness and display the HTML as best it can. A. Do you have any idea how incredibly difficult it is to ensure the absence of any HTML that could possibly be used maliciously in a processor- and memory-efficient manner? It's not possible in a purely perl CGI without incurring unacceptable performance penalties. Anyone who tells you otherwise is either lying, or not really taking into consideration all possibilities of abuse. Additionally, as NeoMail is viewed through a web browser, any time a new hole opens up in a browser, a new vulnerability exists which the user should be protected from. Guess what? Not displaying HTML messages eliminates EVERY ONE of these possibilities. Q. I STILL want HTML mail. Can't you at least include it as an option? A. In the immortal words of Arnold Schwarzenegger in Kindergarten Cop, "STOP WHINING!" I will not dedicate my time to including a feature that puts users at risk, and only serves a purpose for those who would like to send fancy e-mail advertisements or do something more nefarious. Those who are in the know support me in this decision, thank you for your e-mails. Please, just trust me. HTML was designed for the web, not for e-mail. It's one of the reasons that NeoMail's slogan is "Webmail that doesn't suck... as much." Because, let's be honest. Webmail sucks. ALL webmail sucks. Hotmail sucks. Yahoo mail sucks. And yes, NeoMail sucks. I just think it sucks less. Please understand, I don't mean "sucks" in the sense that the programs themselves don't do something really cool, I simply mean that when you compare them to the feature set and responsiveness of a standalone e-mail client, the fall flat on their face. They don't hold a candle to a custom application. Internet culture as a whole needs to get back to its roots. Protocols were used for what they were designed for. HTTP/HTML are not designed for e-mail. It's a testament to the ingenuity of thousands of people out there that they are now flexible enough to do almost anything, but you cannot expect a webmail client to be on par with a standalone POP/IMAP client. It's like trying to perform heart surgery with a dull survival knife. The tool wasn't created for the job. Standards for remotely accessible e-mail (IMAP, for instance) need to be widely adopted and clients for commonly needed functions need to be as ubiquitous as the web browser is. If so many people require something, this should not be an uphill battle. I have a mac.com e-mail address. Did you know that Apple provides a real IMAP account for access from anywhere in the world, and any new Mac has the software capable of reading it already available? Any IMAP-compatible mailreader will work, of course, but that's not the point. What we see as a need for Web-based mail is really a need for a centrally located, remotely stored, universally accessible e-mail inbox. Standards exist that can provide that now. If the standards aren't scalable enough in real-world situations, then a panel of industry talents needs to convene to create one that is. We need to stop looking at the lowest common denominator and start innovating again. And I don't mean "innovating" like that software company that shall remain nameless considers it. I mean innovation accomplished by the joint efforts of companies, government, and the Internet population at large. Because, despite what IP law, corporations, and the government might lead you to believe, the most earth-shattering innovations don't occur behind closed doors, or in tiny locked rooms. The most earth-shattering innovations occur when someone has an idea, and he or she makes it available to others, who build on it, and go from there. The important thing is that the idea doesn't get locked up in a cage at some point, unable to progress. We don't have that now. The environment on the early Internet is the closest I can honestly say we've ever gotten to it in modern times. Anyway, just some thoughts off the top of my head -- sorry for the rant but those of you know me know it's what I do best. Q. When I try to access NeoMail, I get an error about some charset function not existing. A. You're using an outdated version of CGI.pm. You can grab a current one from CPAN (http://www.cpan.org), a link to a working one is available at the NeoMail homepage (http://www.neomail.org). Incidentally, this function call is removed from 1.20 final, so the problem shouldn't happen anymore. Q. When I try to access NeoMail, I get an error saying it can't locate MD5.pm. A. Your UNIX version's Perl distribution apparently doesn't include the MD5 module. You can grab a current one from CPAN (http://www.cpan.org), a link to a working one is available at the NeoMail homepage (http://www.neomail.org). Q. When I try to send mail, I always get an error message saying there's a problem sending my message! Sometimes the message will even go through just fine. A. NeoMail determines how the message sending attempt went by looking at your sendmail binary's exit status. If it is non-zero, the error page is displayed. Depending on your actual MTA and whether you're using a real sendmail binary or a sendmail compatability binary, lots of things could cause sendmail to exit with non-zero status. If you're sending to a local user that doesn't exist, sendmail will know, and exit with an error code. Another common cause is that someone updated sendmail's /etc/aliases file with a bad entry, or didn't run newaliases, causing sendmail to raise a non- fatal error, and confusing NeoMail. Q. NeoMail seems to be running properly, but I can't see my INBOX! It's always empty even though I know I have mail. A. Most commonly, this results from installing NeoMail sgid mail, but having a mail server that doesn't actually store user mail spools with group read/write bits turned on. See the instructions at the end of the INSTALL file regarding running setuid root instead, or, better yet, set up your mail spools to be read/writable by a common group. The other possibility is that you've not specified the correct location for your spoolfiles altogether. Q. NeoMail is installed, but I get a message about it not being able to find neomail.conf in any of the @INC directories! A. This is usually a permissions thing, make sure that neomail.pl and neomail-prefs.pl have the proper permissions to read the /var/neomail directory, and that suidperl is present and functioning properly. This is often not the case on Slackware Linux. When suidperl issues arise, most users have reported success after recompiling perl from scratch, making sure to say "no" when asked if their kernel is suid-script secure, and "yes" when asked if they want to use suid script emulation during the Configure script. Q. I got NeoMail installed OK, but I can't login! No matter what I type I get the invalid password message. Also, my Apache error_log shows reads on a closed filehandle, and a couple uses of undefined values as well. What gives? A. This means that, for some reason, NeoMail is having trouble opening the file you specified as your encrypted password file during setup.pl, or in the $passwdfile variable if you configured NeoMail manually. The root of this problem could be one of several possibilities. First, and most commonly, is that people simply forget to specify /etc/shadow as the password file when using shadowed passwords. This generally happens on manual installs only, as setup.pl does some checking to make sure that there are encrypted passwords in whatever file it defaults to. The next possibility is that while the program knows where your passwords are stored, it cannot open the file to read them, because it has insufficient permissions. Checklogin.pl should generally run suid root, unless you choose a manual install and used a file that doesn't require root permissions to be read for your encrypted passwords. If this isn't the case, another likely possibility is that while you have the Perl interpreter on your system, you don't have the additional wrapper program included in most Perl distributions, suidperl. This should generally exist in the same directory as perl does, and be setuid root. When perl opens a setuid script, it sees the setuid bit, and since most operating systems don't allow scripts to run setuid, it calls the suidperl executable to run the script with root permissions. Q. Does NeoMail support MD5 passwords? A. The short answer is YES. The (slightly) longer answer is that since NeoMail uses the Perl crypt() function, passing it the entire encrypted password as a salt, crypt() is able to detect the telltale $1$ at the beginning of the password and know that it is encrypted using MD5, then use the proper encryption algorithm to perform the password check.