The reason I use POP3 is so that my server does not get filled up with users saving all their messages on the server. With POP3 they get downloaded to the client and then wiped off the server. Those few users that use Webmail exclusively or use the "save messages to server" option have been warned that if their mailbox usage is determined to be excessive we will go in and wipe their mailbox. That is done with periodic scripts, very little intervention on my part.
Maybe, I am misinformed of how the two (POP3 and IMAP) work but that is what I remember from my reading. IMAP does have advantages especially for my current situation, but POP3 looked like the right choice when we first set everything up. Can you all share your experiences and/or opinions of the two (POP3, IMAP)? Thanks again.
Sean
Paul L. Allen wrote:
Sean Smith writes:
Obviously, the users are able to setup filters and rules in their mail program (OE, Netscape) but some of them have asked about filtering in sqwebmail. I read that you can if you use maildrop. But, I would rather not have to reconfigure my server.
Filtering in sqwebmail isn't really filtering in sqwebmail. Sqwebmail
in that case acts as a web front-end to define maildrop filters that act
at delivery time. This is the sensible way to do it because it only
happens once and it doesn't matter whether you use sqwebmail or IMAP
to read your messages. This is sensible because even if you normally
use IMAP you can use sqwebmail to set up filters that work with both.
There are many ways to configure it to work, but the standard method
is based around the techniques found on the qmailadmin mailing list archive.
Qmailadmin is configured to, if you tick the misnamed "enable anti-spam",
create /var/vpopmail/domain/user/.qmail and put in it a command specified
when you configure qmailadmin. That command is typically |preline
/usr/local/bin/maildrop /etc/mailfilter. Typical /etc/mailfilters
can also be found in the qmailadmin archive (not all work, not all work
in all conditions).
Usually /etc/mailfilter checks the message size and feeds it to
spamassassin if it is below a certain size (so spamassassin doesn't choke),
tests to see if the spam flag is set, if the spam flag is set it checks if
a Spam folder exists for the user and creates it if it doesn't then
delivers it to the Spam folder, if the spam folder does not exist it loads
the user's .mailfilter (created using sqwebmail) if it exists then
delivers it either as specified by a condition in the mailfilter or
delivers it to the inbox if no other delivery instruction from the user
disposes of it.
This is good. It means you can selectively control which users get mail
filtering/spam trapping and which don't. You can have /etc/mailfilter
test to see if the domain directory has a file called, for example, .spam
and only pass the message through spamassassin if the file exists (this
is necessary if anti-spam is a chargeable extra to mail services for a
domain).
Trust me, this is the good way of doing it. If you don't need to
spam-trap everything then this lets you control which domains and which
users get it, avoiding the load of spam-trapping everything. It allows
users to create/modify their own filters. It fits in with how sqwebmail
and qmailadmin work. You'd need to find, or write, something to do
per-user spamassassin learning on a daily basis if you want users to be
able to move stuff into or out of the Spam folder if it has been
misclassified, but that's simple script-type stuff.
You don't have to go down this route, but it's there and it works. Any
alternative would have to be coded, and most people would be reluctant
to code something when there is a good alternative. Basically, all the
answers you'll get will say "use maildrop/sqwebmail filters."
