2

Up to now we get new mails with the tool getmail.

It works well. There is a cron job which runs every minute.

Is there a way to get the mail faster?

I see two ways:

  • Solution 1: run the cron job every 30 seconds
  • Solution 2: maybe use IMAP idle. I means a more daemon like way, not a CLT which gets called every minute.
  • Solution 3: ???

Solution 1 is simple: 

* * * * * getmail; sleep 25; getmail

Better solutions are welcome.

Protocol: IMAP

guettli
  • 3,591
  • 17
  • 72
  • 123
  • 2
    You need to make a good configuration top to bottom. If you set a sleep of 25 and you have the default SimplePOP3Retriever class timing of 180 you're in trouble already. – Overmind Sep 16 '19 at 08:32
  • 1
    @Overmind thank you for this hint. I am aware if this and the actual config is not that simple. We have wrapper which does locking. – guettli Sep 16 '19 at 08:50

4 Answers4

10

getmail seems to support IMAP IDLE. So you can write a simple systemd job:

[Unit]
Description=Starts getmail
After=network.target

[Service]
ExecStart=/usr/bin/getmail --idle=INBOX
Restart=on-failure

[Install]
WantedBy=multi-user.target

Put it in /etc/systemd/system/getmail-idle.service and run systemctl enable --now getmail-idle.

Of course you may need to add stuff like User= and parameters to getmail that you need tailored for you.

Stefan Seidel
  • 722
  • 1
  • 8
  • 20
5

fetchmail in daemon mode with IMAP and --idle option may do the trick. Please have a look at man page as it mentions some limitations.

Tomek
  • 3,390
  • 1
  • 16
  • 10
  • 1
    AFAIK fetchmail is written in C and has a long history of security issues: http://www.fetchmail.info/security.html (that's why I used getmail in the past). But thank you for this answer. I will try to find a different tool which supports a daemon mode with IMAP. – guettli Sep 16 '19 at 07:44
  • Nothing wrong with C, e.g. Linux Kernel. Historic security problems somewhat relevant, but that linked page was last updated in 2012. fetchmail is in Ubuntu 'main' and probably similar in other distros, and so will get prompt security attention. – Jack Wasey Nov 17 '20 at 11:36
3

Better solution (IMHO): Have your mail server at a position where it can be directly delivered to (e.g. not an inhouse server behind a firewall).

  • Use some mail hosting service or some form of VPS to run it yourself
  • If you want to keep it inhouse behind the firewall, have the MX be a machine that can talk to your inhouse mail server via a VPN or similar.
Sven
  • 98,649
  • 14
  • 180
  • 226
1

Have you looked into setting up forwarding on the parent system? This avoids the need for polling and also avoids IDLE solutions and their persistent connections. On the master server, you set up some way for it to reach the remote server. This might use an "alias" database, perhaps with a custom "transports" setting to reach the remote machine.

Do you have alias capability and forwarding on the master server? What mail transport are you running?

Tim Riker
  • 51
  • 5
  • Yes, you are right. Setting up a smtp server could be used. In the past (on a different project) we had set up a SMTP daemon. This is not complicated, it is done in some minutes. But it has a major drawback: Responsibility. If my SMTP server is misconfigured and rejects mails, these mails get lost. If my getmail config is broken, it won't fetch mails. Related: https://github.com/guettli/programming-guidelines/blob/master/README.rst#dont-set-up-a-smtp-daemon – guettli Sep 17 '19 at 08:24
  • I refer to the parent system. In other words, where to the mail messages go now? Where do you pull them from? The box that receives the messages could forward them (or a copy of them) to another nost. Then the second host would not have to poll for messages at all. They would come in as soon as they are delivered. In the simple case, this can be done with a $HOME/.forward file. This would only work if the end server you are trying to get the mail too is internet accessible, which it might not be. – Tim Riker Sep 18 '19 at 20:12
  • Note: setting up an internal SMTP server that is not public facing avoids most of the concerns you raise in the link above. Easy enough to allow connections to it only from the parent host, and not to use it for outgoing email. Use it for what you need, not for everything if you don't need everything. – Tim Riker Sep 18 '19 at 20:17
  • I once had this setup (an internal SMTP server that is not public facing). But we lost mails because the internal SMTP server was misconfigured and returned smtp status 5xx (These errors will result in the SMTP connection being dropped, and the sending mail server will advise the user that their mail could not be delivered. ): https://en.wikipedia.org/wiki/List_of_SMTP_server_return_codes#5xx_Permanent_errors – guettli Sep 19 '19 at 07:27