On Thu, 2005-12-08 at 17:50 -0800, Mark Sapiro wrote:
> John Dennis wrote:
> >
> >If your MTA can only handle one, or a small number of client connections
> >then each connection will be busy handling SMTP_MAX_RCPTS and other
> >client connections will queue up. If you have 4,000 recipients then you
> >have the potential to tie up 8 SMTP client connections.
>>> I don't think this is correct. Unless there are multiple outgoing
> runners processing slices, I don't see how SMTP delivery is
> multi-threaded, and even if there are multiple runners, a single
> message to even 4000 recipients is going to be processed in its
> entirety by one runner.
Depends on whether the client waits for a success status or not, which
if my memory serves me correctly (its been failing lately :-) is not the
behavior in an SMTP transaction. I believe the MTA accepts the input,
queues the request and control is returned, at that point I believe the
connection is typically closed. At this point the outgoing running will
loop again and attempt initiate a new SMTP transaction. At least that
how I think it works, plus the behavior is specific to each MTA.
If the client waits for the transaction to complete they of course
you're right.
Mailman is not multi-threaded but many MTA's are or more properly many
MTA's pre-fork a pool of processes which are managed like threads.
--
John Dennis <jdennis at redhat.com>