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.