Re: Best way to relay mail to a server with intermittent connectivity
On 01/27/15 18:57, Seth wrote:
I administer an email system which uses a VPS running OpenSMTPD as the
public facing bit.
The VPS relays email to and from a separate OpenSMTPD mail server
which is located on premises. We'll call this the 'local' server.
The local server gets powered down every night, however this currently
causes messages to back up on the VPS or 'public' server. When the
local server comes back online in the morning, I have to log into the
public relay server and use smtpctl to manually resume the route to
the local server. Then a 'smtpctl schedule all' command must be run
after which the backed up overnight email comes pouring in.
This configuration is suboptimal for two reasons
* It generates bounce and 'sending delayed' postmaster messages when
the local server is down
smtpd.conf(5)
*bounce-warn* /n/{*s*|*m*|*h*|*d*}[, /.../]
Specify the delays for which temporary failure reports must be
generated when messages are stuck in the queue. For example:
bounce-warn 1h, 6h, 2d
will generate a failure report when an envelope is in the queue for
more than one hour, six hours and two days. The default is 4h.
* It requires manual intervention to ensure speedy email delivery to
the local server when it's powered back on.
I've been thinking about adding another OpenSMTPD relay mail server at
the local site, which is low power and can stay running all the time
without issue. But this merely shifts the location of the mail pile-up
from remote to local.
Any mail gurus out there have a solid method for solving this problem?
Re: Best way to relay mail to a server with intermittent connectivity
On Tue, 27 Jan 2015 17:22:43 -0800, Edgar Pettijohn
ed...@pettijohn-web.com wrote:
*bounce-warn* /n/{*s*|*m*|*h*|*d*}[, /.../]
Specify the delays for which temporary failure reports must be
generated when messages are stuck in the queue. For example:
bounce-warn 1h, 6h, 2d
will generate a failure report when an envelope is in the queue for
more than one hour, six hours and two days. The default is 4h.
Thanks, I caught that right after posting, of course. Dialed it back to 1d.
Still need to solve the problem of scheduling that big morning dump.
Of email.
--
You received this mail because you are subscribed to misc@opensmtpd.org
To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
Re: Best way to relay mail to a server with intermittent connectivity
On Tue, 27 Jan 2015 20:18:04 -0800, Edgar Pettijohn ed...@pettijohn-web.com wrote: Still need to solve the problem of scheduling that big morning dump. Of email. cron That's not really going to work because the power-up time could vary between 2-4 hours. The mail needs to flow as soon as possible after powering on the local server. What would be ideal is for the relaying server to probe the local server every five minutes. As soon as an active SMTP port is discovered on the local server, the relay sends all queued emails. -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
RE: Best way to relay mail to a server with intermittent connectivity
You could simply have a startup script on the local server that connects runs smtpctl on the remote machine through SSH keys, so the command is run as soon as the server is started, automatic and no delays. Hope that helps -Original Message- From: Seth [mailto:l...@sysfu.com] Sent: Wednesday, January 28, 2015 8:25 AM To: misc@opensmtpd.org Subject: Re: Best way to relay mail to a server with intermittent connectivity On Tue, 27 Jan 2015 21:11:52 -0800, Sunil Nimmagadda su...@nimmagadda.net wrote: I was wondering what if your local server is the primary MX and then your public server a backup MX. That way, whenever your local server is online the mails end up directly in it and your backup server automatically checks for primary server availability and routes accumulated mails once the primary MX is up. That's a good point. The VPS is configured as the sole MX host in this case because it runs OpenBSD + PF + Spamd + BGP, and serves as the spam choke-point. http://bgp-spamd.net/ To date, it has not been possible to stand up an OpenBSD host on premises to perform the same role, although I am pushing in this direction. Another idea I had was provision a low power embedded *nix device running OpenBSD/OpenSMTPD on premise that runs 24/7, and stores the 'night's catch' of emails locally on a flash device etc. When the main email server comes on line in the morning, startup scripts or whatever grabs or syncs the 'night's catch' in maildir format and transfers the whole bundle to the main 'local' email, server which runs Dovecot IMAP or some groupware like Zarafa. -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
Re: Best way to relay mail to a server with intermittent connectivity
On Tue, 27 Jan 2015 21:11:52 -0800, Sunil Nimmagadda su...@nimmagadda.net wrote: I was wondering what if your local server is the primary MX and then your public server a backup MX. That way, whenever your local server is online the mails end up directly in it and your backup server automatically checks for primary server availability and routes accumulated mails once the primary MX is up. That's a good point. The VPS is configured as the sole MX host in this case because it runs OpenBSD + PF + Spamd + BGP, and serves as the spam choke-point. http://bgp-spamd.net/ To date, it has not been possible to stand up an OpenBSD host on premises to perform the same role, although I am pushing in this direction. Another idea I had was provision a low power embedded *nix device running OpenBSD/OpenSMTPD on premise that runs 24/7, and stores the 'night's catch' of emails locally on a flash device etc. When the main email server comes on line in the morning, startup scripts or whatever grabs or syncs the 'night's catch' in maildir format and transfers the whole bundle to the main 'local' email, server which runs Dovecot IMAP or some groupware like Zarafa. -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
Re: Best way to relay mail to a server with intermittent connectivity
On Tue, Jan 27, 2015 at 08:47:24PM -0800, Seth wrote: On Tue, 27 Jan 2015 20:18:04 -0800, Edgar Pettijohn ed...@pettijohn-web.com wrote: Still need to solve the problem of scheduling that big morning dump. Of email. cron That's not really going to work because the power-up time could vary between 2-4 hours. The mail needs to flow as soon as possible after powering on the local server. What would be ideal is for the relaying server to probe the local server every five minutes. As soon as an active SMTP port is discovered on the local server, the relay sends all queued emails. I was wondering what if your local server is the primary MX and then your public server a backup MX. That way, whenever your local server is online the mails end up directly in it and your backup server automatically checks for primary server availability and routes accumulated mails once the primary MX is up. -- You received this mail because you are subscribed to misc@opensmtpd.org To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
Re: Best way to relay mail to a server with intermittent connectivity
On 01/27/15 20:45, Seth wrote:
On Tue, 27 Jan 2015 17:22:43 -0800, Edgar Pettijohn
ed...@pettijohn-web.com wrote:
*bounce-warn* /n/{*s*|*m*|*h*|*d*}[, /.../]
Specify the delays for which temporary failure reports must be
generated when messages are stuck in the queue. For example:
bounce-warn1h, 6h, 2d
will generate a failure report when an envelope is in the queue for
more than one hour, six hours and two days. The default is 4h.
Thanks, I caught that right after posting, of course. Dialed it back
to 1d.
Still need to solve the problem of scheduling that big morning dump.
Of email.
cron
--
You received this mail because you are subscribed to misc@opensmtpd.org
To unsubscribe, send a mail to: misc+unsubscr...@opensmtpd.org
