Unix Mail, keep mails on server

I succesfully installed “mail” on my SUSE-Linux system using “YaST Control Center” and the “mail” command works as expected. But I noticed that with the default YaST configuration collected emails are removed from the mail server. Is it possible to change the configuration such that the mails are kept on the server. to be available for other mail agent. I guess the YaST setup uses “fetchmail” and there is a “/etc/sysconfig/fetchmail” configuration file but there I did not find any information about how this can be achieved

Looking at the “man page” of “fetchmail” one indeed finds the option “-k” which says:

“Keep retrieved messages on the remote mailserver. Normally, messages are deleted from the folder on the mailserver after they hav been retrieved. Specifying the keep option causes retrieved messages to remain in your folder on the mailserver.”

But “fetchmail” is started as a daemon deep into the system, apparently without “-k”. Has somebody already solved the problem to have the option “-k” for “fetchmail” with the SUSE setup?

Maybe add “-k” to the FETCHMAIL_EXPERT_OPTIONS in /etc/sysconfig/fetchmail?
Or try to add “keep” to /etc/fetchmailrc…

I never used this myself, so cannot tell if it really works.
But /etc/init.d/fetchmail starts the daemon with the following line (where FETCHMAIL_RC_PATH is set to /etc/fetchmailrc by default), so both should work:


Sorry, I don’t seem to have fetchmail installed, thus I consulted a fetchmail man page on the internet (which thus may differ because of being of another vesion).

But when you search through it looking after “keep”, it seems that there is also a .fetchmailrc file for each user where you can define such things: ~/.fetchmailrc. Did you check that possibility?

Edit: better go for wolfi323’s soolution, That seems to be more general.

Thanks for the replies

For Henk van Velden:
The only “fetchmailrc” is “/etc/fetchmailrc” and it only says:
poll “pop.t-online.de” protocol AUTO : user “" there with password "” is “*” here

But what wolfi323 proposes works. With




it works as desired! Thanks wolfi323!

But I really think that SUSE should change the default to “keep” ("-k"), that certainly is what most people want! Or at least offer this e option in YaST!

I wouldn’t think so. Most accounts have fixed quota. You’re using POP. If you want a server where all messages stay on the server forever, use IMAP and a lot of disk space on the server.

Normaly such user owned configuration files (in this case ~/.fetchmailrc) that can overrule centraly configured values (that then in fact are default values) (in this case /etc/fetchmailrc) are not already in user’s home directory. Who would create them? You can not want that user creation scripts create dummys for every conf file for all applications that might be available some time.

Such a user config file will either be created when a user uses an application for the first time, or it will only be created by the user him/herself when needed, either by using configuration options of the application (often done in GUI applications), or by using an editor (and use the man page to see what to do).

The man page I saw, definitely mentions ~/.fetchmailrc.

I use fetchmail from the command line, as needed. And that uses “.fetchmailrc”. And yes, “keep” works in “.fetchmailrc”.

I typically use in the form:

fetchmail accountname

where “accountname” is defined in the “.fetchmailrc”. I use “keep” with some accounts, but not with others.

But now that option “-k” works I see that the setup still is not what I want!

When “fetchmail” is restarted, at boot or explicitly by the “root”, all messages on the server are fetched without checking if they already have been put in “/var/spool/mail/username”.

Other mail clients like Outlook Express or Lotus Notes do that correctly, they leave the messages on the server so that other mail systems can collect them but they do not themselves fetch a new copy of the mails they already have collected .

If you’re comparing fetchmail to Outlook Express and Lotus Notes, then why not use one of the many mail clients for the desktop environments? They’ll do what you want. I know Kmail, Evolution, Thunderbird, Opera and so on and so on, all have these options.

I’m not sure, but maybe you should set FETCHMAIL_FETCHALL to “no” in /etc/sysconfig/fetchmail?

If that is “yes” (the default) fetchmail’s “-a” option is set:

       -a | --all | (since v6.3.3) --fetchall
              (Keyword: fetchall, since v3.0)
              Retrieve  both  old (seen) and new messages from the mailserver.
              The default is to fetch only messages the server has not  marked
              seen.   Under  POP3,  this  option  also  forces the use of RETR
              rather than TOP.  Note that POP2  retrieval  behaves  as  though
              --all  is always on (see RETRIEVAL FAILURE MODES below) and this
              option does not work with ETRN or ODMR.  While the -a and  --all
              command-line and fetchall rcfile options have been supported for
              a long time, the --fetchall command-line  option  was  added  in



in /etc/sysconfig/fetchmail

I don’t know what happens when running fetchmail as a daemon.

When I manually run it at the command line (for my own mail), with “keep” in “.fetchmailrc”, it maintains a file “.fetchids” in my home directory which tells it which mail it has already fetched.

I think it is OK now! If in


one puts


instead of


One then gets in


startproc -u fetchmail /usr/bin/fetchmail -d 600 -k -f /etc/fetchmailrc

without “-a”

“startproc” is a binary that seems to be used to start daemons in the SUSE setup!

For Henk:

The reson why there is no ~/.fetchmailrc file with the SUSE setup is:

-f <pathname> | --fetchmailrc <pathname>

Specify a non-default name for the ~/.fetchmailrc run control file. The pathname argument must be either "-" (a single dash, meaning to read the configuration from standard input) or a filename. Unless the --version option is also on, a named file argument must have permissions no more open than 0600 (u=rw,g=,o=) or else be /dev/null. 

The SUSE developers have chosen to have this file in a system directory!

Changing this option in /etc/sysconfig/fetchmail should allow to change that: FETCHMAIL_RC_PATH=“/etc/fetchmailrc”

On 2013-09-16 18:15, hcvv wrote:

> The man page I saw, definitely mentions ~/.fetchmailrc.

Fetchmail if called by an user (or root) will definitely use

But openSUSE creates a configuration on /etc/fetchmailrc which is called
by a service in init.d, and this one explicitly overrides the default
configuration file to use the one under /etc/. The man page does not
talk of this because it is a SuSE creation – lower case ‘u’ intentional
to indicate how old is this config :wink:

Cheers / Saludos,

Carlos E. R.
(from 12.3 x86_64 “Dartmouth” at Telcontar)

On 2013-09-16 18:15, stamcose wrote:
> Thanks for the replies
> For Henk van Velden:
> The only “fetchmailrc” is “/etc/fetchmailrc” and it only says:
> poll “pop.t-online.de” protocol AUTO : user “" there with password "
> is “*” here
> But what wolfi323 proposes works. With

The other way is to edit the “/etc/fetchmailrc” file:

poll "pop.t-online.de" protocol AUTO
user "*" there with password "*" is "*" here, and keep


This one is equivalent to “fetchall” in the config file.

> But I really think that SUSE should change the default to “keep” ("-k"),
> that certainly is what most people want! Or at least offer this e option
> in YaST!

No, most people do not want that. Many email accounts have limited
storage, so the default of ALL clients I have tried (using POP) is to
remove all email from the server. And it is the default operation mode
of fetchmail, too.

Cheers / Saludos,

Carlos E. R.
(from 12.3 x86_64 “Dartmouth” at Telcontar)

With the SUSE daemon configuration it is the file /var/lib/fetchmail/.fetchidstat that is used for this purpose. A typical line indicating an already fetched message:

user@pop.t-online.de 1137172633.13791

Why use Unix Mail at all?

Because you then can send mails from scripts! If one has 100 different messages (generated by software) that should go to 100 different people one can write a script with a “for(do) loop” to send the individual messages!