On Thursday 20 July 2006 17:59, mlist@safenet-inc.com wrote:

For example, if you want a general service for several people, who have the option to log onto the serving machine and read mail from there, OR to read their mail from other PCs in the building (I'll worry about remote webbish access in part 2), then you want fetchmail and <whatever goes in the middle> and IMAP server to all start and run as processes when the machine boots. ... so why does fetchmail have little config files for each local user, in each respective home directory, and are they even seen if the given user is not logged in, and what about mail users who don't have login accounts on the server PC? Why _don't_ they need little fetchmail config files of their own?

fetchmail has one config file per instance you run. There are basically two ways of doing it. Either each user sets up fetchmail for his/her own accounts, and runs a private fetchmail, or the admin of the machine sets up one central config which fetches all email for all user accounts. It's down to taste and what suits your exact setup really. Both ways work

Similar questions about IMAP. And where should the mail be going for the IMAP server to handle it, if _some_ of the users are local login users, but some are remote-only and don't have a login account on the serving PC?

I suspect that rules out Joanne's solution then, since I don't think that can handle virtual users (at least I don't think so). cyrus can though, but in the solution I gave in my other email, it would require that you create accounts for them, but you can disable logins (set login shell to /bin/false) if you want. There are ways of creating purely virtual users without linux accounts too, if you really want them

Does IMAP need/expect that all the incoming mail will be in one place, or can it handle (say) /data/Maildir for the non-local subscribers as well as individual ~/Maildir for those who have local login accounts? What about that question makes it stupid? :-)

It's not a stupid question. IMAP the protocol doesn't care where the mail is physically stored, but I don't think I've ever seen an actual IMAP server that could handle multiple locations (cyrus murder, I guess, in some sense)

I mentioned Courier because that's what was used in the HowTos to which I originally pointed John Alegre. No other attraction to it. My first-ever attempt at a server was with Cyrus, but I tripped over stuff to do with authentication and might also have had a generic IMAP trying to run at the same time, or maybe Cyrus does like Postfix does (when it pretends to be sendmail), and presents an executable just called "imap" or "imapd"... does it? After I finished installing SUSE 10.1 and blundering through the (attempted) mail setup, Xinetd seemed to think there was something called imapd, and nothing called Cyrus-IMAP... though I think there was a Cyrus-sasl daemon (listed in xinetd) that wasn't active... so easily do I confuse.

Neither cyrus imap nor saslauthd are run through xinetd, they are standalone daemons

What I'm aiming for is: <snip requirements>

I didn't say anything about outbound, in your scenario I don't see a reason why the email client should't connect directly to the external mail server. But if you want it to go through the postfix server for some reason (security perhaps), then it's not so hard Have a look at the description I gave in my other email and let me know if it matches your requirements -- 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: <mlist@safenet-inc.com> ... Let's start here...

The object would be two-fold: - to get me and other people up with a working house mail server

That should be easy.

- to have us understand how we got there (when previous attempts got lost in conflicting options and misconceptions)

The easier the setup approach the easier it is to recreate. {^_-}

For example, if you want a general service for several people, who have the option to log onto the serving machine and read mail from there, OR to read their mail from other PCs in the building (I'll worry about remote webbish access in part 2), then you want fetchmail and <whatever goes in the middle> and IMAP server to all start and run as processes when the machine boots. ... so why does fetchmail have little config files for each local user, in each respective home directory, and are they even seen if the given user is not logged in, and what about mail users who don't have login accounts on the server PC? Why _don't_ they need little fetchmail config files of their own?

OK, there are reasons that they do not want to try to snarf email up from under an IMAP server if you are using IMAP with IMAP folders and all that stuff. There is nothing that says your local mail client cannot access via IMAP the same as any other client. I'd recommend doing that for consistency, anyway. (As a talking point I do not much like the folder behavior of IMAP as my MUA presents it. I prefer the mail folder behavior of the MUA itself. This has its downside that I accept. I have to synchronize MUA databases before switching. IMAP would eliminate that issue nicely at the expense of messier foldering.)

Similar questions about IMAP. And where should the mail be going for the IMAP server to handle it, if _some_ of the users are local login users, but some are remote-only and don't have a login account on the serving PC?

THAT depends on the tools you use. If you are using DoveCot then you can include an incantation in your .bash_profile that directs it to get incoming email from /var/spool/mail/... and get all other mail from ~/Mail/.... This is a minimum configuration item. With Cyrus it "seems to be" more complex. I'll let andres address Cyrus since he knows it.

Does IMAP need/expect that all the incoming mail will be in one place, or can it handle (say) /data/Maildir for the non-local subscribers as well as individual ~/Maildir for those who have local login accounts? What about that question makes it stupid? :-)

DoveCot works out of actual user accounts, whether or not the users can or do log into the 'ix machine. I believe Cyrus is well suited for "virtual" accounts. For three or four users the local 'ix account approach is quite easy and does not consume much in the way of resources. (This also allows for such nice things as per user SpamAssassin rules and databases quite easily. You can apply more filtering to the children's accounts than yours if you wish.)

I mentioned Courier because that's what was used in the HowTos to which I originally pointed John Alegre. No other attraction to it. My first-ever attempt at a server was with Cyrus, but I tripped over stuff to do with authentication and might also have had a generic IMAP trying to run at the same time, or maybe Cyrus does like Postfix does (when it pretends to be sendmail), and presents an executable just called "imap" or "imapd"... does it? After I finished installing SUSE 10.1 and blundering through the (attempted) mail setup, Xinetd seemed to think there was something called imapd, and nothing called Cyrus-IMAP... though I think there was a Cyrus-sasl daemon (listed in xinetd) that wasn't active... so easily do I confuse.

DoveCot uses the account's name and password from the passwd file. It's easy maintenance. {^_-}

My second-ever attempt was with Dovecot, which is part of my current pickle. Courier or Dovecot not necessary at all. If simple and reliable can happen with Cyrus chained to a couple of other necessary apps, bring it on. I'm going to be monkeying with LDAP or sasl before this is over, aren't I?

Do remember that SendMail/PostFix/yatta and more yatta are not necessary when you are using Fetchmail. That can remove a major configuration pickle out of the way.

What I'm aiming for is:

Inbound ======= - fetchmail gets mail from my ISP for my personal account and for three others (maybe later I try to figure out how it gets gmail)

OK, It's time for me to cut and paste a little. This is a thinned down example from my .fetchmailrc. I daemonize a fetchmail for each of the users here. For two to 10 users that's probably quite practical. Beyond 10 then learning the global magic becomes necessary. (I like the per user arrangement because if automating new places from which to fetch mail becomes desireable you can have the user log into a web page and run a home grown management tool if you want.) ===8<--- from my (sanitized) .fetchmailrc defaults mda "/usr/bin/procmail -d me" set syslog set postmaster "" set no bouncemail set no spambounce set properties "" #set daemon 60 #I do this in the fetchmail startup line. #set logfile fetchmail.log #use this when debugging. poll smtp.earthlink.net with proto POP3 user 'me' there with password 'buzzbuckets or something' is 'me@here' here options pass8bits smtpaddress ' ' poll smtp.earthlink.net with proto POP3 user 'otherme' there with password 'other buzzbuckets or something' is 'me@here' here options pass8bits smtpaddress ' ' ===8<--- There is probably some excess verbiage present but this works so why fix it? Also note that I have all the external accounts feed one email account here. It seems easier to process it that way. The fetchmail man pages should help if you want separate email setups for each site. Being lazy I'd simply setup some dummy nologin users to hold the per account scripts needed. Of course, this feeds procmail, which needs its own per user script. But that's basically boilerplate. I'll include calling SpamAssassin below, which includes some "extreme prejudice" diversions: ===9<--- from my (sanitized) .fetchmailrc ############################################################################# # Necessary generic definitions ############################################################################# DROPPRIVS=yes #VERBOSE=yes ## rawmbox is no longer needed at this time. #:0c: clone.lock ##* ^List-Id: .*(spamassassin\.apache.\org) #$HOME/mail/rawmbox ############################################################################# # Then we install some deaths and diversions ############################################################################# :0: * ^From: FETCHMAIL-DAEMON@morticia.wizardess.wiz $HOME/mail/fetchmail_messages # bye bye uol.com.br :0: * ^From: AntiSpam UOL <.*@uol.com.br> /dev/null ############################################################################## # Tag SA-user and SA-dev list mail ############################################################################## PROCMAILHEADER="X-Procmail: " :0 fw * ^List-Id: .*(spamassassin\.apache.\org) | formail -A "$PROCMAILHEADER an SA list. Mail not processed." # done this way so I could include some debugging in the scan cases. :0 * < 500000 * !^List-Id: .*(spamassassin\.apache.\org) { :0 fw: spamassassin.lock | /usr/bin/spamc -t 150 -u <username> } # and a final diversion if the ClamAssassin plugin for SpamAssassin fires :0: * ^X-Spam-Status: .*CLAMAV.* $HOME/jdvirus/ClamAV_Quarantine ===9<--- The email gets delivered.... The entire script COULD be as simple as this: ===8<--- DROPPRIVS=yes :0 fw: spamassassin.lock * < 500000 * !^List-Id: .*(spamassassin\.apache.\org) | /usr/bin/spamc -t 150 -u <username> ===8<--- In both cases replace "<username>" with the actual username.

- any other magic that needs to happen (I've read lots of confusing things about Postfix and Procmail and all kinds of other stuff that I need or don't need, depending on who's talking and which way the wind is blowing, how old the FAQ or HowTo is, etc.) Maybe there's nothing between fetchmail and (Cyrus) IMAP and this step is empty?

With fetchmail and procmail you're done as far as getting the mail goes. With this line in your environment added to /etc/profile you get it all: MAIL="/home/$USER/mail:INBOX=/var/spool/mail/$USER" You may need to modify the /etc/dovecot.conf file for the services you want to enable. I use the secure ports for external access while I am travelling. So I had to edit lines related to imaps and pop3s to enable and configure them. It's a short conf file that is well commented.

- an IMAP server finds the mail in a place and format that it can use (I think I prefer Maildir format, but I'm prepared to be corrected on that, too)

There is some magic here. The above line is for mbox format. For MailDir you include a "/" after the names above as a signal that MailDir is to be used. For the needs here mbox seems to work just fine and was the default when I set this all up a longish time ago. (At first I used an old IMAP/POP tool that is not more or less gone. I migrated to DoveCot because it was so simple to get running and I did not need the levels of security that Cyrus gives. Internal hackers I don't have. {^_-})

- I (or other user) can log on locally and read, sort into folders, delete some, but mostly _keep_ all my mail for a long time (years) and see/manipulate it with any mail-client (mostly KMail, but I might use others) The mail should never magically disappear just because it's been read, or just because it's reached a certain age. If that ever happens, I'd want it to be because of an explicit choice on my part, not because I overlooked a default or some-such. I hate surprises. :-)

Please perform ALL accesses through the IMAP interface. As for the mail dissappearance that is under the control of you MUA. Check its options.

- I or another user should be able to connect from other machines on my household LAN and do exactly the same reading/sorting of mail, which should _stay_ nice and safe on the IMAP server, not being deleted unless specifically targeted by the user/client. Someday, same should apply from outside my house, but not a priority. If there's a way to safeguard IMAPped mail against stupid general deletion policies in (say) a Mac mail client, that would be good.

If you always access through IMAP this should be quite possible with minimal to no difficulty. It's what IMAP is designed to do.

So, some of the above stuff will involve me putting the right names and IP addresses, etc. into the right places when configuring fetchmail, Postfix?, Procmail?, Cyrus.

See my cuttings above. {^_-}

OUTBOUND ======== - mail-reader client generates new mail or replies to a mail, and it goes out to my ISP and to the world.

Exactly what I do. That is an MUA configuration item. Configure your KMail or equivalent the way you want.

I'm thinking that the IMAP server oughta be involved somehow on the outbound path, 'cuz otherwise how do I have a "Sent Mail" directory/folder that's central and up-to-date?

I believe you will find that this is a MUA configuration item as well. (It certainly is with the MUA I use for reasons of convenience.)

Inbound or Outbound, I'm not very concerned about virus scanning, because I'm running a Linux box, and most of the clients are Linux or Mac... but if it's easy and cheap on resources, I'm game... but only when the basic mail service works and I can breathe again.

You don't HAVE to use ClamAssassin. For "obvious reasons" I do. {^_-} You probably will want spam filtering. My configuration above includes that as a matter of course. I can't imagine running without it.

Kevin

I think most of what you need is above, I hope. (If you do want to run SpamAssassin I have some "prejudices" about setting it up in an environment with a small number of real users that prove over time to be very very effective. I have about 1 in 1000 spams get through and about 1 in 10,000 hams get mismarked at present.) And of course, I leave the Postfix/Cyrus involvement path to others to explain. I never did get it working satisfactorily. {^_^} 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