On Thursday 20 July 2006 02:42, jdow wrote:
I hope I misunderstand the goal because the processes you outline are far in excess of what might be needed for an internal network.
Oh, I don't know. It took me about 5 minutes to set up, including installing the packages, since I didn't already have them on my desktop. I don't think that's excessive
The packages involved in receiving the email into the mbox email in-boxes are simply fetchmail, procmail, SpamAssassin, and Clam-AV via the ClamAssassin plugin for SpamAssassin. If you do not want any spam filtering the latter two items are not needed.
So you have fetchmail, procmail, and an imap program. I have fetchmail, postfix (which is there by default anyway) and an imap program. I didn't consider spam filtering, that should be done on the external machine, normally
Fetchmail grabs the email from the each user's accounts on the ISP. As it happens I have it setup for two savvy people with several email accounts each. We run fetchmail via a little script in each user's directory with individual .fetchmailrc files. This took place way back in time when this seemed to function better than the global fetchmailrc file approach. YMMV. I simply have not fixed what is not broken. The important .fetchmailrc for this is simply:
defaults mda "/usr/bin/procmail -d <user>"
Replace <user> with the user ID, of course.
and no config at all for server address, username on the remote server, password??? There will be at least one more line, I'm sure.
Procmail can deliver the email to the /var/spool/mail/<user> file directly. I place necessary lines for running SpamAssassin (and black holing certain email pests.)
Once the email is in the spool file reception is done. Now I have to send it to the user. For that I simply use DoveCot. Normally you'd simply fire it up and tell it where the spool files live and go. I have a somewhat more complex configuration for automating user interactive Bayes training for SpamAssassin. Normal mail is fetched via POP3S directly from the spool file. Then there are per user mail storage directories for IMAPS access to the spam training mail folders.
Note that there is no need to involve more than simply fetchmail, procmail, and dovecot for the simplest configuration. I use this simply because it allows far simpler access to per user Bayes and rules for SpamAssassin. The postfix/cyrus route proved very difficult to build into this required configuration.
If the original query was from a fellow who needed to pull email from an ISP and then distribute it accessibly on the Internet note that this is what I am doing via useage of the POP3S and IMAPS ports. I let them be open on the firewall. I do not allow raw POP3 or raw IMAP access outside the internal network.
This is of course a valid and usable setup, but I don't think it's that much less work than my suggestion And the less I have to do with procmail, the better -- Check the headers for your unsubscription address For additional commands send e-mail to suse-linux-e-help@suse.com Also check the archives at http://lists.suse.com Please read the FAQs: suse-linux-e-faq@suse.com