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://neomail.sourceforge.net).  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://neomail.sourceforge.net).

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, <PASSWD> 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.
