Are Fetchmaildaemon and Postfix necessary?
 

Hello,

I've just upgraded security on my Debian-based Libranet.
After downloading with apt-get upgrade, a few config questions popped up concerning Ssh, Postfix, and Fetchmaildaemon.

I take Ssh to be a program for mail encryption.

From what I've read on this forum, you don't seem to need Postfix or fetchmail unless you use your computer as a mailserver.

Is this correct?

Or do you need some kind of program to be able to get your mail anyway even if you use Mozilla or Thunderbird?

:Pengy:

Thanks in advance for your help,

ssh is a secure verion of telnet nothing to do with email encryption.
You are correct in saying you only need postfix if you are running a mail server.
Fetchmail is used to fetch mail from a POP3 server so you may have a need for this if you download email from your ISP.
Hope this helps
Dave

ssh is an acronym for secure shell. It is used to connect to your box from outside. It has nothing to do with mail.

Postfix is an MTA (Mail Transport Agent); it recieves from the internet and sends mail there. You can think it as a centralized place having all the mail-configuration in one place so every MUA (Mail User Agent, eg. mutt, pine, mozilla-mailnews, kmail, etc..) doesn't have to be configured separatedly; some MUAs can partially work as MTA:s (this is the way it is done in the windows world; One program tries to do everything, and does everything poorly).

fetchmail is a tool that fetches mail. Especially it fetches mail from other imap or pop accounts and passes them to local MTA, as if they were send here in the first place.

One part missing from the puzzle is a MDA (Mail delivery agent). This is an optional part. MDA (like procmail or mailfilter) can be used to postprocess your mail to be filtered to certain folders with arbitrary criteria; this processing can be done in co-operation with some spam analyzing tools like spamassassin and/or bogofilter.

You do need a MTA to recieve mail eg. from your system, cron scripts, other users and that sending mail from arbitrary program (eg. cvs sends mail on new commits if configured so, and mdadm sends mail if one of your HDs in your raid-array begings to malfunction.)

Mail is quite fundamental part of the messaging system, even if mail is send only locally. (thus postfix is quite heavyduty tool for only local delivery; a program like nullmailer might be more approriate).

Well.. it seems that nullmailer won't deliver mail locally; esmtp does it with procmail.

Phaah.. atleast exim4 is trivial to configure to do only local delivery and send outgoing mail to smarthost, possibly with address rewriting. Maybe postfix is not much worse.

Thanks you dave and TonyT for your replies!

I didn't reconfigure fetchmail after upgrading -- should I -- or would the default config be still valid (that would be the config shipped with my distro version)?

The default config in fetchmail probably does nothing. The usage of fetchmail is to fetch mail from one or more of your pop/imap accounts (provided by your isp or similar); if not explicitly configured, it uses no accounts.

Well, my email (Mozilla) works very well, so I suppose the config file first produced when I configured Libranet ppp is still valid.

Cheers

Put you described where your pop/imap account is for your mozilla, didn't you? In that case, mozilla is doing the work of fetchmail for one user without passing the mail to any MDA:s.

I'm not sure I understand your question, ToniT.

I configured Libranet PPP while installing Libranet (Libranet being my Linux distro). It was very easy. It must have been after package installation but definitly before I launched Mozilla for the first time (and i've installed a new version).

Cheers

Just saying that is your mail delivered to /var/mail/username, or is it read locally by mozilla.

Well, my /var/mail dir's got one 10KB file in it, called "nobody".

I wouldn't think the mail's delivered to that dir then, what do you reckon?

Cheers,

So, what I'm saying, that you *have* configured mozilla, and it reads maail by it's own.