Mailinglist Archive: opensuse (2831 mails)

< Previous Next >
Re: [SLE] POP Mail HOWTO?
From: <mlist@xxxxxxxxxxxxxxx>

...
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@xxxxxxxxxxxxxxxxxxxxxx
$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@xxxxxxxx
Also check the archives at http://lists.suse.com
Please read the FAQs: suse-linux-e-faq@xxxxxxxx


< Previous Next >
References