berenger.mo...@neutralite.org: > > I finally decided myself to install a software to manage my mails.
Good luck! My impression is that this is one of the few things that have
not become considerably easier on Linux in the last ten years.
Mutt is still a good choice today if you can live with the limits of a
terminal. I use it myself, but not completely exclusively.
You need to address at least these questions:
- How do I plan to access mails using mutt (IMAP or local storage?)
- Local storage:
- How do I pull mail from a remote server
- How do I deliver mail to different mailboxes (MDA)
- What type of mailboxes to use (mbox vs. maildir)
- How to I send mail to remote servers (MTA)
A basic setup would be something like the link you posted. I would just
replace fetchmail with getmail and procmail with maildrop. You can skip
that part completely if you mail is already on an IMAP-capable server.
Mutt can access that as well. Works fine for me. Some people complain
about speed, but that doesn't apply to me. As long as you have header
caching enabled in mutt and your mailboxes are smaller than, say, 10,000
mails, it should be fast enough.
Running a full-fledged MTA like Postfix or Exim gives you flexibility if
you, for example, want to use different smart hosts depending on the
sender address. This is handy if you use several different mail
providers or if several people use the mail server.
> For the fetcher, I am surprised that debian does not seems to
> recommend or suggest using one, so I will not spend time on that
> -for now at least- and will do as the article says, unless I
> discover something interesting in the process.
Setups like yours have come out of fashion in the last few years. People
either use GUI clients or web interfaces these days. :-/
(BTW, I had assumed fetchmail was dead while getmail is alive. It is
actually the other way round!)
> But for the tool to send mails, things are different: I can count 16
> alternatives. Some are obviously wrong for my use, like
> lsb-invalid-mta, postfix or exim ( those last ones are probably too
> big for my simple usage, they seems designed for big boxes where
> mailing is an important task ), but even after removing some obvious
> ones, I still have a lot of choice.
Do not rule out Postifx and Exim. Simple setups are relatively simple to
achieve nowadays, at least with Debian's debconf templates.
> So, here is my question:
> What would you use as a MTA on a Debian system made for an end-user?
I use Postfix on all of my machines, even simple "satellite" systems
that simply forward all mail to my central mail server.
Exim is a good choice as well, if only for the fact that it is Debian's
default MTA. I chose Postfix a few years ago because I found it easier
to understand. Might be different today, but I have no reason to switch.
> _ supports IMAP, POP3 and SMTP ( this does not sound excessive I
> think, but if there are other important protocols, I do not even
> know their existences or uses )
You have the common misconception that a "mail server" (MTA) has
anything to do with how you access your mails. An MTA's job is purely to
route mails between servers. They can deliver mail that is handed over
from client connections or via the command line, but the rest is routing
of mails.
You do not need a POP3 or IMAP server for the setup that is described in
the link you posted. You only need a client like fetchmail or getmail.
Mutt then accesses local mailboxes in the filesystem.
(That doesn't mean it is necessarily a bad idea to run a POP3/IMAP
server like Dovecot, even on a laptop! IMAP makes switching mail clients
a non-issue, especially with server-side spam-filtering and mail
sorting.)
> _ is not a daemon running constantly: why should I have a daemon
> running to send mail when I am not connected to Internet or not
> taking care of my mails?
Don't be bothered about that. My central Postfix server in my LAN uses
less than 5MB of RAM. It really doesn't matter. Total CPU usage in 100
days of uptime is about 36 seconds.
> Something which is started by the client (
> MUA it seem? ) is good enough for me and does not consume time when
> starting or shutting down my computers.
>
> _ is lightweight, because I always aim to have a system which let
> all possible resources to my compilers, and which respect my
> batteries. I bet that if I can still survive 4H with wifi after 3
> years of intensive use, it is partly because I do not use heavy
> softwares.
Ok, I see where you are coming from. But believe my when I say that a
simple full-fledged MTA does not use any considerable amount of
resources (unless you constantly bombard it with more than ten mails per
second).
Startup time is also negligible.
> _ is configured by raw text in the good old UNIX way because I have
> learn so many from Debian's configuration files and their comments,
> which are very useful when you messed everything and can not even
> access Internet :)
Don't worry about that. Both Postfix and Exim use plain text config
files and come with tons of useful documentation.
> PS: sorry for the long description of my request, but I tried to be
> as complete as possible. Hopefully it makes things I aim for more
> clear...
Yes, thank you.
Just as an example on what is possible:
I run my own mail server on a rented VPS. It uses Postfix and Dovecot
with spam filtering (policyd-weight, dspam) and mail sorting (Sieve). I
access mail with different clients, mostly mutt on a constantly running
server in my LAN at home which is also my central LAN mail server. This
machine even runs Dovecot as well which is synced to the pulic server
using offlineimap (simple 1st level backup). There I also pull mails
from a few other mail accounts using getmail and procmail. These mails
are synced to the pulic server as well using offlineimap.
I see exactly the same mails in my locally running mutt, Thunderbird on
my laptop or my workstation at the office and with K-9 on my smartphone.
I don't want to give the impression that such a setup is easy to build,
but maintenance effort is very low.
J.
--
When I get home from the supermarket I don't know what to do with all the
plastic.
[Agree] [Disagree]
<http://www.slowlydownward.com/NODATA/data_enter2.html>
signature.asc
Description: Digital signature
