Koozali.org: home of the SME Server

Obsolete Releases => SME Server 8.x => Topic started by: brianr on July 30, 2015, 06:33:24 PM

Title: Disabling email for a while
Post by: brianr on July 30, 2015, 06:33:24 PM
What is the best way to disable (and then re-enable) mail receipt for a short while, from the console?

I need to test the MX Backup for a server.
Title: Re: Disabling email for a while
Post by: Stefano on July 30, 2015, 06:34:31 PM
IMHO, stopping qpsmtpd service should do the trick :-)
Title: Re: Disabling email for a while
Post by: CharlieBrady on July 30, 2015, 07:03:12 PM
IMHO, stopping qpsmtpd service should do the trick :-)

qpsmtpd and sqpsmtpd

sv d /service/*qpsmtpd

Having a backup MX is unnecessary, and will complicate spam filtering.
Title: Re: Disabling email for a while
Post by: janet on July 31, 2015, 03:24:45 AM
brianr

Quote
[I need to test the MX Backup for a server.

As Charlie says, having the backup MX is not necessary. Mail will be queued & when the first (& only) MX server comes back on line, then mail will be delivered.

Having the second mX backup server may cause mail to be delivered to your sme server from that different mail server & the source is lost, so sme server cannot do as good a job at spam filtering etc.

Instead of testing the backup MX record, you should delete it.
Title: Re: Disabling email for a while
Post by: brianr on July 31, 2015, 10:33:52 AM
I don't want to start up this debate again about MX backup, except to say that over the years I've run servers both with and without MX backups.

My experience is even when the main SMEServer is down for shortish periods (an hour or two), some senders still experience bounces, rather than the expected retrys if there is no MX Backup.  Also with an MX backup the "stored" email is delivered very much quicker to the re-ignited mailserver than if we rely on the originating mailserver to retry.  Consequently I use MX Backup in situations when the customer believes that they cannot wait or risk loosing email. 

Most of my servers are/where on essentially domestic broadband lines, in some cases using a static IP and sometimes using a dyndns hostname to track a dynamic IP (which results in potential gaps in the mail receipt capability as the dynamic IP address is tracked).

Just my two penn'orth.

Title: Re: Disabling email for a while
Post by: CharlieBrady on July 31, 2015, 04:33:18 PM
Most of my servers are/where on essentially domestic broadband lines, in some cases using a static IP and sometimes using a dyndns hostname to track a dynamic IP (which results in potential gaps in the mail receipt capability as the dynamic IP address is tracked).

Worse than just gaps in receipt, that could result in mail being intercepted or bounced by someone else.
Title: Re: Disabling email for a while
Post by: brianr on July 31, 2015, 05:26:23 PM
Worse than just gaps in receipt, that could result in mail being intercepted or bounced by someone else.

true, but unlikely, I think IP addresses which are part of a dynamic pool are generally left unused for a period after being reclaimed for exactly that reason.

However in some cases (including my own server), there is no option for a static IP.
Title: Re: Disabling email for a while
Post by: Fumetto on August 01, 2015, 02:57:39 AM
Also I have raised the issue a while ago ... but I've never tried this, I think that might be a good approach to solving mount two sme; sme1.domai.tld is "master" mx, sme2.domain.tld is "slave" mx.
When SME1 go offline SME2 collect your incoming mail, which could be "captured" by SME1 when back online with a script that uses fetchmail.

I know that for some use fetchmail is considered "the absolute evil", but in theory it should work, or not?