On Thu, 02 Apr 2009 16:56:07 CDT, Marty Hoag said:

>     There was even an RFC on this! RFC 1047, "DUPLICATE
> MESSAGES AND SMTP" from 1988. Of course your problem could
> differ but if you are curious see
>     http://tools.ietf.org/rfc/rfc1047.txt
>
>     I'm not sure why this would show up on messages
> with external recipients (or blocks but each one is a
> message with up to 100 RCPT TOs). However, lots has
> changed since 1988 - there were usually no spam/virus
> scanners and such - so maybe something else is creating
> a similar effect.

The RFC is 2 decades old, and the effect still persists.  These days,
the most common cause is the remote end getting bogged down on A/V and spam
scanning and failing to return a '250 OK' in a timely fashion.

There's another possible cause in Sendmail - hostname canonization (though
usually that's seen as a hit on each individual RCPT TO:).  If the system's
spam/etc processing requires a DNS lookup, and there's a number of off-site
destinations, you *could* end up in a situation where multiple DNS timeouts
would accumulate to cause enough delay for the sender to timeout on the '250 OK'.

You might want to check if you have 'SORT_RECIPIENTS={1|2}' coded in your
go.user file - that will cause all the off-site recipients to end up clustered
in one or two blocks.