John N. Alegre [mailto:lists@johnalegre.net] wondered:
Could some kind person point me to a good HOWTO or tutorial on setting up POP Mail on a SuSE 9.1 Pro system.
I'd like to find a neat, concise (yet explanatory, as in, why you are doing each step and what the options are... hmm, probably defeats "concise" right there, doesn't it) HowTo for setting up an IMAP server on SUSE. Meanwhile, there's something at http://www.howtoforge.com/perfect_setup_suse_9.2 and a similar one for 10.1 that might have useful info for you. For me, it leaves me with as many questions as it answers, since, of course, I don't wish to do exactly what the writer has done, but I'm not sure which bits are important and which are not as far as antecedents to the IMAP/POP3 config is concerned. For example, there doesn't seem to be much about getting the mail from elsewhere to the Courier IMAP/POP server. In my case, I don't want outside forces pushing to my PC, I want my PC going to my ISP, fetching the mail and putting it in the right places, in the right condition that the IMAP server can use it. Then I want the IMAP server to keep it forever and not "accidentally" delete it just because it's been read or is old... stuff that you don't care about, because you want POP, but an indication of how sparse or disconnected the HowTos have been from my perspective (ask me how I ended up with 1.5 million files [mostly duplicates] in my /Maildir... better yet, don't ask - it's an agonizing tale that seems to have no end). Kevin (still blundering along) The information contained in this electronic mail transmission may be privileged and confidential, and therefore, protected from disclosure. If you have received this communication in error, please notify us immediately by replying to this message and deleting it from your computer without copying or disclosing it. -- 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
Thank you Kevin for taking the time to reply. All other input welcome. john On Wednesday 19 July 2006 15:33, mlist@safenet-inc.com wrote:
John N. Alegre [mailto:lists@johnalegre.net] wondered:
Could some kind person point me to a good HOWTO or tutorial on setting up POP Mail on a SuSE 9.1 Pro system.
I'd like to find a neat, concise (yet explanatory, as in, why you are doing each step and what the options are... hmm, probably defeats "concise" right there, doesn't it) HowTo for setting up an IMAP server on SUSE.
Meanwhile, there's something at http://www.howtoforge.com/perfect_setup_suse_9.2
and a similar one for 10.1 that might have useful info for you.
For me, it leaves me with as many questions as it answers, since, of course, I don't wish to do exactly what the writer has done, but I'm not sure which bits are important and which are not as far as antecedents to the IMAP/POP3 config is concerned.
For example, there doesn't seem to be much about getting the mail from elsewhere to the Courier IMAP/POP server. In my case, I don't want outside forces pushing to my PC, I want my PC going to my ISP, fetching the mail and putting it in the right places, in the right condition that the IMAP server can use it. Then I want the IMAP server to keep it forever and not "accidentally" delete it just because it's been read or is old... stuff that you don't care about, because you want POP, but an indication of how sparse or disconnected the HowTos have been from my perspective (ask me how I ended up with 1.5 million files [mostly duplicates] in my /Maildir... better yet, don't ask - it's an agonizing tale that seems to have no end).
Kevin (still blundering along)
The information contained in this electronic mail transmission may be privileged and confidential, and therefore, protected from disclosure. If you have received this communication in error, please notify us immediately by replying to this message and deleting it from your computer without copying or disclosing it.
-- 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
On Wednesday 19 July 2006 22:33, mlist@safenet-inc.com wrote:
John N. Alegre [mailto:lists@johnalegre.net] wondered:
Could some kind person point me to a good HOWTO or tutorial on setting up POP Mail on a SuSE 9.1 Pro system.
I'd like to find a neat, concise (yet explanatory, as in, why you are doing each step and what the options are... hmm, probably defeats "concise" right there, doesn't it) HowTo for setting up an IMAP server on SUSE.
You talk about Courier, is that a hard requirement? Setting up the config you want with cyrus IMAP is very simple on SUSE. If that's good enough for you I could put together a step by step howto -- Ut supra post festum sunt obscura -- 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
On Wednesday 19 July 2006 16:37, Anders Johansson wrote:
Setting up the config you want with cyrus IMAP is very simple on SUSE. If that's good enough for you I could put together a step by step howto Please do.
Thanks Anders john -- 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
On Thursday 20 July 2006 00:26, John N. Alegre wrote:
On Wednesday 19 July 2006 16:37, Anders Johansson wrote:
Setting up the config you want with cyrus IMAP is very simple on SUSE. If that's good enough for you I could put together a step by step howto
Please do.
Concept: A mail server that doesn't accept remote connections to deliver mail. Mail are fetched from a remote server that handles incoming connections, and delivered locally to an IMAP server (cyrus) Packages needed: postfix, cyrus-imapd, fetchmail, fetchmailconf (GUI for configuration of fetchmail, not strictly needed) I'm assuming either SUSE Linux 10.1 or SLES 10 here (note that in SLES 10 you can do this through the YaST mail server module as well) Step 1: install the required packages. Step 2: configure postfix edit /etc/sysconfig/postfix and change POSTFIX_LOCALDOMAINS to include your email domain. For example if you have an email address foo@bar.com it should be POSTFIX_LOCALDOMAINS="bar.com" also change POSTFIX_MDA so it reads POSTFIX_MDA=cyrus Then run SuSEconfig --module postfix Step 3: start cyrus and its authentication daemon rccyrus start rcsaslauthd start Step 4: restart postfix rcpostfix restart You now have a working mail/IMAP server. At this point you need to create an account on the cyrus server. If you open an email client and configure as incoming account to point to the cyrus server, it will automagically create the account for you. However, by default the quota will be set to 10MB, which might be a little low for you( I know it is for me), so before you do this, you may want to edit /etc/imapd.conf and set autocreatequota: to something a little higher (it needs to be more than 0, otherwise the account won't be automatically created) Step 5: configure fetchmail either manually, if you know the config file syntax, or through the fetchmailconf GUI Step 6: run fetchmail If in the config you set it up as a daemon, run it as a daemon, otherwise set up a cron job to run it at regular intervals (not sure how specific I need to be about this step) That should be all. I actually set up my desktop machine as a mail server as I went along, to verify each step, so the above should be relatively accurate, but I may still have missed something, so for your forgiveness in advance I beg Hope this helps Anders -- 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
On Thursday 20 July 2006 02:01, Anders Johansson wrote:
On Thursday 20 July 2006 00:26, John N. Alegre wrote:
On Wednesday 19 July 2006 16:37, Anders Johansson wrote:
Setting up the config you want with cyrus IMAP is very simple on SUSE. If that's good enough for you I could put together a step by step howto
Please do.
Concept: A mail server that doesn't accept remote connections to deliver mail. Mail are fetched from a remote server that handles incoming connections, and delivered locally to an IMAP server (cyrus)
Packages needed: postfix, cyrus-imapd, fetchmail, fetchmailconf (GUI for configuration of fetchmail, not strictly needed)
Oops, one more required package (but I think it's installed by default) cyrus-sasl-saslauthd -- 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
A few minor points I forgot to mention
Step 2: configure postfix edit /etc/sysconfig/postfix and change POSTFIX_LOCALDOMAINS to include your email domain. For example if you have an email address foo@bar.com it should be
POSTFIX_LOCALDOMAINS="bar.com"
also change POSTFIX_MDA so it reads
POSTFIX_MDA=cyrus
if you have other users on your local subnet that shouldn't be allowed to use this mail server, you should also change POSTFIX_ADD_MYNETWORKS_STYLE towards the end of /etc/sysconfig/postfix so it reads POSTFIX_ADD_MYNETWORKS_STYLE="host"
You now have a working mail/IMAP server. At this point you need to create an account on the cyrus server. If you open an email client and configure as incoming account to point to the cyrus server, it will automagically create the account for you. However, by default the quota will be set to 10MB, which might be a little low for you( I know it is for me), so before you do this, you may want to edit /etc/imapd.conf and set autocreatequota: to something a little higher (it needs to be more than 0, otherwise the account won't be automatically created)
If you do this, don't forget to restart cyrus afterwards (before you attempt to create the account) rccyrus restart If you miss this, your account will get the old quota, and you'll have to use the cyradm tool later to increase it And the final (hopefully) thing I forgot to mention, make sure port 143 is open on this machine in your firewall configuration, if you want to reach the imap server from another machine. Setting up IMAP with TLS or SSL is for another day -- 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
From: "Anders Johansson"
On Thursday 20 July 2006 00:26, John N. Alegre wrote:
On Wednesday 19 July 2006 16:37, Anders Johansson wrote:
Setting up the config you want with cyrus IMAP is very simple on SUSE. If that's good enough for you I could put together a step by step howto
Please do.
Concept: A mail server that doesn't accept remote connections to deliver mail. Mail are fetched from a remote server that handles incoming connections, and delivered locally to an IMAP server (cyrus)
Packages needed: postfix, cyrus-imapd, fetchmail, fetchmailconf (GUI for configuration of fetchmail, not strictly needed) ....
Hope this helps
I hope I misunderstand the goal because the processes you outline are far in excess of what might be needed for an internal network. At present that machine here happens to be FC4. But that's more or less immaterial. It simply explains some of the packages available easily. The ONLY reason there is a "sendmail" on the system is to handle the cron daemon and logwatch emails to root and my main user account. 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. 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. 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. {^_^} Joanne Dow -- 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
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
From: "Anders Johansson"
On Thursday 20 July 2006 02:42, jdow wrote:
I didn't consider spam filtering, that should be done on the external machine, normally
I've been doing this since SpamAssassin 2.3x days. It works. The brief digression that involved PostFix (on a Mandrake build just before they became Mandrival) was at best a qualified success. The spam filtering is done before it gets to the inboxes due to the emailer I am using. (I make my money with Windows development for broadcast video uses. I telecommute. I'm constantly shipping builds to the customer. It's easier if I don't have to change machines. The Linux machines enter for security and some fun. But it HAS lead to a small inconsequential patch to partition and filesystem handling in the Linux kernel. {^_-} Winks and pats self on back, too.)
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.
The rest is standard fetchmail boilerplate. The line I quoted was the key for bypassing SendMail/QMail/EXIM/PostFix/whathaveyou. (<cough> it also avoids amavisd-new, too. I've watched too many people have problems getting it setup. What I have works. I'm disinclined to fix it. {^_-})
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
It is arcane. However, since I sit right next to the server I played some procmail games. When I receive customer email or email from my partner it plays different sound files to alert me. It also proved useful before the PerMsgStatus.pm bug which caused (partially) scored but unmarked missed spam in my mailbox. I simply ran it twice if the first time failed. There is an absurd kind of logic to the way you can do that with procmail. I can also easily skip spam processing for email from the spamassassin mailing lists. That is QUITE helpful. My partner writes some of the SARE rules and I also do some SA hacking. If I was doing simple mail reception I'd still go global fetchmail, procmail with a REALLY simple boilerplate to deliver the mail, and DoveCot. It'd still take me more than 4 minutes. I have a small case of RTFMitis, I tend to read manuals then do when I can. I realize this detracts from my reputation. But, gee, I can't help it. And I can't find any 12 step programs.... {^_-} Joanne -- 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
On Thursday 20 July 2006 03:58, jdow wrote:
From: "Anders Johansson"
On Thursday 20 July 2006 02:42, jdow wrote:
I didn't consider spam filtering, that should be done on the external machine, normally
I've been doing this since SpamAssassin 2.3x days. It works. The brief digression that involved PostFix (on a Mandrake build just before they became Mandrival) was at best a qualified success. The spam filtering is done before it gets to the inboxes due to the emailer I am using. (I make my money with Windows development for broadcast video uses. I telecommute. I'm constantly shipping builds to the customer. It's easier if I don't have to change machines. The Linux machines enter for security and some fun. But it HAS lead to a small inconsequential patch to partition and filesystem handling in the Linux kernel. {^_-} Winks and pats self on back, too.)
Cool, you're into Amigas :) kernel hacking is something I haven't really gotten into. I tried it once, and managed to hang the whole machine, and I've stayed away from it since. I'll keep to the user space :)
It is arcane. However, since I sit right next to the server I played some procmail games. When I receive customer email or email from my partner it plays different sound files to alert me. It also proved useful before the PerMsgStatus.pm bug which caused (partially) scored but unmarked missed spam in my mailbox. I simply ran it twice if the first time failed. There is an absurd kind of logic to the way you can do that with procmail. I can also easily skip spam processing for email from the spamassassin mailing lists. That is QUITE helpful. My partner writes some of the SARE rules and I also do some SA hacking.
If I was doing simple mail reception I'd still go global fetchmail, procmail with a REALLY simple boilerplate to deliver the mail, and DoveCot. It'd still take me more than 4 minutes. I have a small case of RTFMitis, I tend to read manuals then do when I can. I realize this detracts from my reputation. But, gee, I can't help it. And I can't find any 12 step programs....
:) Well, to each her own. That's what's great about linux, there are so many ways of doing it. Whatever works, and suits your style of working, is good I still object to the "far more excessive" tag though :) Anders -- 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
From: "Anders Johansson"
On Thursday 20 July 2006 03:58, jdow wrote:
From: "Anders Johansson"
On Thursday 20 July 2006 02:42, jdow wrote:
I didn't consider spam filtering, that should be done on the external machine, normally
I've been doing this since SpamAssassin 2.3x days. It works. The brief digression that involved PostFix (on a Mandrake build just before they became Mandrival) was at best a qualified success. The spam filtering is done before it gets to the inboxes due to the emailer I am using. (I make my money with Windows development for broadcast video uses. I telecommute. I'm constantly shipping builds to the customer. It's easier if I don't have to change machines. The Linux machines enter for security and some fun. But it HAS lead to a small inconsequential patch to partition and filesystem handling in the Linux kernel. {^_-} Winks and pats self on back, too.)
Cool, you're into Amigas :)
Into? If you have 3.9 you have some of my code on that machine. I did the partitioning engine for it. {^_-} I also wrote or maintained most of the Microbotics scsi controller code.
kernel hacking is something I haven't really gotten into. I tried it once, and managed to hang the whole machine, and I've stayed away from it since. I'll keep to the user space :)
If I was doing simple mail reception I'd still go global fetchmail, procmail with a REALLY simple boilerplate to deliver the mail, and DoveCot. It'd still take me more than 4 minutes. I have a small case of RTFMitis, I tend to read manuals then do when I can. I realize this detracts from my reputation. But, gee, I can't help it. And I can't find any 12 step programs....
:)
Well, to each her own. That's what's great about linux, there are so many ways of doing it. Whatever works, and suits your style of working, is good
I still object to the "far more excessive" tag though :)
I sat here envisioning the email threading itself through the rather labyrinthine guts of PostFix and any tools PostFix involves in the act as opposed to wee little old procmail and flinched. {^_-} Joanne (At one time jdow@bix.com, but it died, sad to say. that was the ID in the Amiga days.) -- 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
On Thu, 2006-07-20 at 02:01 +0200, Anders Johansson wrote:
On Thursday 20 July 2006 00:26, John N. Alegre wrote:
On Wednesday 19 July 2006 16:37, Anders Johansson wrote:
Setting up the config you want with cyrus IMAP is very simple on SUSE. If that's good enough for you I could put together a step by step howto
Please do.
Concept: A mail server that doesn't accept remote connections to deliver mail. Mail are fetched from a remote server that handles incoming connections, and delivered locally to an IMAP server (cyrus)
{snip}
That should be all. I actually set up my desktop machine as a mail server as I went along, to verify each step, so the above should be relatively accurate, but I may still have missed something, so for your forgiveness in advance I beg
Hope this helps
Thanks Anders -- 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
Anders, Thank you. One last question. Is it possible to run things as you suggest and have the ability to both get mail directly from /var/spool/mail if loged on to the SuSE box or retrive it via fetchmail from a remote machine AT THE SAME TIME, i.e. logged on I run Kmail and Kmail gets mail from /var/spool/mail/user which is put there via SMTP / Postfix or that same user retrieves his mail via fetchmail if not logged on with Kmail up? I still want users that log on to the suse box to get mail via Kmail / local mail box. Thanks john On Wednesday 19 July 2006 19:01, Anders Johansson wrote:
You now have a working mail/IMAP server. At this point you need to create an account on the cyrus server. If you open an email client and configure as incoming account to point to the cyrus server, it will automagically create the account for you. However, by default the quota will be set to 10MB, which might be a little low for you( I know it is for me), so before you do this, you may want to edit /etc/imapd.conf and set autocreatequota: to something a little higher (it needs to be more than 0, otherwise the account won't be automatically created)
Step 5: configure fetchmail either manually, if you know the config file syntax, or through the fetchmailconf GUI
Step 6: run fetchmail If in the config you set it up as a daemon, run it as a daemon, otherwise set up a cron job to run it at regular intervals (not sure how specific I need to be about this step)
-- 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
On Thursday 20 July 2006 14:33, John N. Alegre wrote:
Anders,
Thank you.
One last question.
Is it possible to run things as you suggest and have the ability to both get mail directly from /var/spool/mail if loged on to the SuSE box or retrive it via fetchmail from a remote machine AT THE SAME TIME, i.e. logged on I run Kmail and Kmail gets mail from /var/spool/mail/user which is put there via SMTP / Postfix or that same user retrieves his mail via fetchmail if not logged on with Kmail up?
I still want users that log on to the suse box to get mail via Kmail / local mail box.
I'm confused, I thought you were talking about IMAP. The solution I detailed will store all your email in cyrus IMAP, and you can connect to it to read your email whether you're logged in locally or not (firewall permitting). The /var/spool/mail storage is taken out of the equation, and fetchmail is only used for putting things into cyrus, not for actually reading the email, for that you just connect to IMAP using your mail client. After all, one of the major points of IMAP is to have the email stored in one single location, instead of all over the place But if you really want to keep the /var/spool/mail storage, then the solution suggested by Joanne would do it for you -- 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
From: "Anders Johansson"
On Thursday 20 July 2006 14:33, John N. Alegre wrote:
Anders,
Thank you.
One last question.
Is it possible to run things as you suggest and have the ability to both get mail directly from /var/spool/mail if loged on to the SuSE box or retrive it via fetchmail from a remote machine AT THE SAME TIME, i.e. logged on I run Kmail and Kmail gets mail from /var/spool/mail/user which is put there via SMTP / Postfix or that same user retrieves his mail via fetchmail if not logged on with Kmail up?
I still want users that log on to the suse box to get mail via Kmail / local mail box.
I'm confused, I thought you were talking about IMAP.
The solution I detailed will store all your email in cyrus IMAP, and you can connect to it to read your email whether you're logged in locally or not (firewall permitting). The /var/spool/mail storage is taken out of the equation, and fetchmail is only used for putting things into cyrus, not for actually reading the email, for that you just connect to IMAP using your mail client. After all, one of the major points of IMAP is to have the email stored in one single location, instead of all over the place
But if you really want to keep the /var/spool/mail storage, then the solution suggested by Joanne would do it for you
For either my design or yours I'd highly recommend configuring KMail to draw the mail through the IMAP interface. Otherwise the consistency of the IMAP mail database would suffer. (For POP3 it would not matter much at all barring simultaneous access attempts.) {^_^} -- 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
Anders, On Thursday 20 July 2006 08:32, Anders Johansson wrote:
I'm confused, I thought you were talking about IMAP.
The solution I detailed will store all your email in cyrus IMAP, and you can connect to it to read your email whether you're logged in locally or not (firewall permitting). The /var/spool/mail storage is taken out of the equation, and fetchmail is only used for putting things into cyrus, not for actually reading the email, for that you just connect to IMAP using your mail client. After all, one of the major points of IMAP is to have the email stored in one single location, instead of all over the place
But if you really want to keep the /var/spool/mail storage, then the solution suggested by Joanne would do it for you I am sorry to be jumping back on this thread so late, I was tied up for a day.
What I want, and I realize there are more then one need being expressed on this thread and I am happy for that, but what, I, want is a solution where of the 30 user accounts I have on this SuSE 9.1 Pro box, some 3 or 4 can log on under full KDE and use Kmail connected to their /var/spool/mail files to read, save and delete mail. I want the other 25 odd users to be able to log on from remote machines, either Red Hat Linux or more often OS X and use a local mailer to POP or IMAP (I do not care which) their mail. The same users will be logged in and the others will be remote. This will not change in most cases. If there was an easy soution where they could do both fine but I think I am safe to say that it will be a finite set of all the user accounts that log in directly. I do understand that you are talking about settin up POP or IMAP and using that for both the logged in and remote mail accounts, and if that is the easier fix, fine, but I was hoping to put in the remote system and switch users over to it slowly leaving the rest using the /var/spool/mail file. Thanks for all the help. john -- 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
participants (5)
-
Anders Johansson -
jdow -
John N. Alegre -
Mike McMullin -
mlist＠safenet-inc.com