On Tue, Jun 19, 2001 at 12:49:53PM +0000, Greg Cope wrote:
> Matthew Byng-Maddick wrote:
> > What's your plan if you get a 4xx error at any stage?
> If its based on a perl client I'll probably queue everything via an MTA
> that is not a 221 OK. I know this is repetition but I want it to be as
221 is what you get after a QUIT. YM 250, I think. This sounds like a
pretty sensible strategy, although you probably want to be able to mark
any 5xx errors as they are as permanent failures.
> simple and fast as possible.
That's a sensible way of doing it.
> Any ideas on how to do this quickly - for want of any guidance I'm
> leaning towards a forking server.
I would still try to avoid the DJB-alike overhead. I'm not so convinced
about it now I think about it, because a lot of servers (I know my exim
does) will do quite a lot of work on connection establishment, and such
things may well block (specifically a rDNS lookup, possibly an ident
lookup), RBL lookups etc. It therefore makes sense to try and use a
queuing strategy that serialises per MX anyway, IMHO.
I'd probably sort your delivery into some kind of strategy order, and then
have 10 or so processes doing the actual delivery. What you have to be
careful of is that if you go to too many processes, then you'll have too
much context-switching, too few, and you're spending time blocking in too
many processes waiting for the other ends. (mail exchanges are often
relatively slow).
The strategy is quite difficult, unfortunately, as you mainly want to
sort into primary MX, but you also want to try secondary-MX's as well.
Of course, if your primary MX is down, then you could just try queueing
with the MTA, and let it sort that out.
The other thing you want to be careful of is that a connection waiting to
timeout is potentially nasty. You could do all of this stuff in a single
threaded sender (with O_NONBLOCK on the sockets), which might work, then
you don't have to worry about how to delegate the addresses to the various
children.
I'm guessing that all these messages are pretty standard template, so
you could actually *generate* the message during the DATA phase rather
than storing it anywhere on disc and spooling it. You also don't need
to store much about the recipient except which ones failed and with what
error. This makes your life easier, as you can do all your MTA queueing
after you've done the main run of messages, and just deliver to the MTA
when your main run has finished, this will help because you'll often get
the failure reponses before you've got to the DATA stage, although there
will be a 4xx or 5xx response to a final dot every so often.
Hope this helps
MBM
--
Matthew Byng-Maddick <[EMAIL PROTECTED]> http://colondot.net/
