Re: [Exim] SMTP Cluster - Shared Spool?

Top Pagina
Delete this message
Reply to this message
Auteur: Suresh Ramasubramanian
Datum:  
Aan: George Schlossnagle
CC: Jawaid.Bazyar, bazyar, exim-users
Onderwerp: Re: [Exim] SMTP Cluster - Shared Spool?
george@??? (George Schlossnagle) [Sunday, August 11, 2002 12:26 PM]:

> That having been said, having small fcal arrays shared by a couple
> relays (not overlapping spools, just co-mounted) seems like a nice and
> relatively cost efficient way to ensure spool high-availabilty through
> first tier mx failure.


Having the MXs handoff to another cluster for local delivery ASAP reduces
this risk. Mail doesn't stay on the first tier MXs for any significant
length of time.

Split spool directories helps speed things up even more.

For bounces etc - have those shunted to a backup queue for delivery, and
then handed off ASAP to a fallback MX server.

That way, actual mail (especially that being delivered to your users) stays
on your MXs for a very very short amount of time (assuming the downstream
MTAs you handoff to for final delivery stay up...).

> For the maildir access, I completely concur, but I want to make sure
> the mail a relay receives to be delivered (less a concern for inbound
> mail, more a concern for outbound).


A system with regular queuerunners handing off to one (or even two or three)
fallback MX hosts might be a better idea.

That, and a few people looking through the tertiary fallback MX host to see
what's causing mail not to be delivered to a remote location (99.99% of it
bounces). Then doing one or more of -

* Running qtool.pl (on sendmail) or exim -Mrm to scrub the queue clean if
necessary

* Finding and blocking hosts which don't accept bounces (lots of them
spammer domains, the others might be legit lists with bounce handling and
bouncing user weeding problems (in which case such hosts would be unblocked
ASAP once we are contacted...)

* Contacting remote hosts blocking or firewalling off our IP space, to make
sure our mail does get through.

The basic goal of this is "don't keep mail too long on the primary MX,
handoff to secondary hosts for local or remote delivery ASAP".

That way - concerns about mail being lost by having a queue crash on you are
not avoided 100% but they are minimized.

That, and using ramdisks for the spool (as you and Theo have suggested more
than once in the past) might help speed things up far more. Costs $$$
though, compared to ordinary hard drives ...

    -srs