[HLUG] Exim 4.50 on Debian 3.1 external greet_pause?

[Mark Broadbent]

On 29/01/07, John Hedges <john at drystone.co.uk> wrote:
> Hi Mark
>
> > On 29/01/07, John Hedges <john at drystone.co.uk> wrote:
> > >On Mon, Jan 29, 2007 at 04:01:44PM +0000, Mark Broadbent wrote:
> > >> [...]
> > >
> > >Thanks Mark. Maybe I am less than bomb-proof. However I'm still not
> > >convinced that the (im)probability of receiving mail from a broken
> > >sender when your primary is down warrants maintenance of a second mail
> > >server. Perhaps it's a bit hard line but it's better not to pander to
> > >broken/misconfigured senders. You never know, it might prompt them to
> > >get their servers fixed :) And as far as the warning messages are
> > >concerned, aren't they useful to the sender?
> >
> > I greatly depends on your circumstances, for me, my primary is located
> > in my house and is off most of the time so I want the backup to
> > collect mail and hold it quietly for upto 2 weeks (like when I go on
> > holiday).  For a business who relies on email then you have no option
> > but to make it as easy and bombproof as possible for your customers to
> > send you email.  But for everyone else, it won't matter.
> >
> > >If your secondary can deliver mail, then fine - it's obviously useful in
> > >that you are improving availability, but just to spool seems pointless
> > >to me.
> >
> > Very rarely would a secondary actually deliver mail (as I said before
> > it would be a redundant primary if it did)
>
> That's exactly my take on the provision of a secondary MX, to be a
> redundant MX for when the primary fails. I'm sure that many ISPs will
> use mirrored SMTP relays as secondaries that will do full mail
> delivery. Your situation is different because you are dealing with a
> mailserver that handles local deliveries.
>
> > it's a good way of
> > reducing the delivery delay for email that was delivered whilst you
> > were off-line. Depending how long the primary is off-line, it could
> > take 1-2 days to actually receive all the stored email when relying on
> > the sending server to retransmit.  Again this highly depends on the
> > sending servers configuration.
> >
> > Basically what I'm getting at is that it a defensive set-up to guard
> > against other peoples mistakes.
>
> Your configuration is interesting in that you are leveraging the
> secondary MX as a mail queue. In many ways, I prefer it to mine which is
> a primary MX on a permanently connected VM with mailboxes and either
> IMAP direct to that host, or fetchmail for distribution into mailboxes
> on a lan server. Either way, I rely on some sort of polling with IMAP or
> POP3. However, you have two sets of ACLs to keep in sync and the
> necessity to route inbound SMTP through your firewall.

I'm not a fan of polling, it can work well for small set-ups but can
quickly become onerous.  I'd rather have direct delivery personally (I
was a Demon user for a good number of years and they preferred direct
SMTP delivery over POP3 and it kind of stuck :).

BTW what ACLs would have to be kept in sync?

> Why don't you make your secondary MX your primary? It would always spool
> when it couldn't forward to your home and you'd only need one set of
> ACLs (plus a very simple one on your home server to allow SMTP only from
> your mail server and lan). This would give you the same functionality,
> would make more sense primary/secondary-wise and would allow you to
> tighten your firewall.

I buy my backup MX as a service and have no control over it (it
doesn't have any spam/AV controls on it) so I have to implement those
anyway on my primary and I might as well allow connections from any
sender as I have to deal with all the email on that machine anyway.
To be honest I am thinking in the future of having a primary sitting
in a permanently connected VM just so I can read new email without
having the machine turned on at home, but conversely I would keep the
backup in case of outages (the backup MX service costs peanuts).

Thanks
Mark

-- 
Mark Broadbent
* http://www.wetlettuce.com/