Matthew Byng-Maddick wrote:
>
> 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.
>
Your right 250 - this comes of trying to do too many things at once.
> > 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.
One issue that I've found is that some big domains can sometimes be very
slow .... hence spliting on MX may be good but in a controlled manner.
> 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).
>
have a configuarable start number and tune from there.
> 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.
>
probably - as if the primary is down, the secoundary is likley to be
buzy.
> 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.
select looks like the way to go, but I will need to look at timeouts,
you right (again big domains can be very slow!)
>
> 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.
Go idea.
>
> Hope this helps
Some clever bits there. Thanks.
Just need to write a simple client interface to send the mail, and a
server that starts a load of these objects and manages them via select.
Thanks
Greg
>
> MBM
>
> --
> Matthew Byng-Maddick <[EMAIL PROTECTED]> http://colondot.net/
