: If you think about it this needs a rather clever system to manage. I give you
: the following scenario
: you send 30,000 messages a day to mail servers in domain x. eg
: bittwiddlers.com there is a catastrophic network failure in the network and
: it is impossible to send mail to that domain. Your fast system passes all of
: the mail during that day the network is out to the slow system all 30,000
: messages. The slow server now has to do the task. or worse your servers
: start madly passing the mail around amongst themselves in the vain beleif
: that one of the others will be able to get through.
I can agree that that is possible but in this particular case this mail is
very time dependant such that if it remains in the queue for more than six
hours it is considered useless. So, in as case like you have outlined above
we wouldn't worry about it much as long as the network came back up in time
to send out the mail the next day.
I'm just trying to figure out if I can push the delayed messages off somewhere
else under the assumption that the recipient addresses will come up in the next
few hours. I don't want to delay my fast servers by having all these possible
bad messages in the queue.
: I think what you need is a distributed processing version of qmail.
: Any takers ???
Actually, I would love that. I have a distributed front end that parses the
mail and through socket connections passes it to a series of qmail servers out
there to push it out. It would be nice if I could just have a distributed
qmail or a distributed queue that multiple qmails could operate on.
--
Matthew Harrell Never raise your hand to your
Bit Twiddlers, Inc. children - it leaves your
[EMAIL PROTECTED] midsection unprotected.
