Valdis Kletnieks wrote:
> 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.

Well, my problem occurs at the LISTSERV --> sendmail level.  Both reside on
the same machine.  I only use A/V and spam scanning at the point of
delivery, so outgoing mail is not scanned.  I see no reason why the
sendmail would not return a '250 OK'.  The machine was not unreasonably
loaded.  It is a fast quad Opteron machine with 250MB/sec disk throughput.


>
> 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'.

As mentioned above, there is no spam processing on the outgoing mail.  The
block that was re-sent only contained 4 outside domains: utoronto.ca,
yahoo.com, yahoo.uk.com and gmail.com.  So there should not be excessive
DNS lookups.

Does anyone known how long would LISTSERV wait for '250 OK' before giving
up and resending the block?

>
> 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.
>

I do not, unless it is a default.

Thanks a lot to all of you.
Frank

--

Frank Bures, Dept. of Chemistry, University of Toronto, M5S 3H6
[log in to unmask]
http://www.chem.utoronto.ca
PGP Public Key:
http://subkeys.pgp.net:11371/pks/lookup?op=index&search=Frank+Bures

Please, reply to the above address only.  <lisfrank> does not accept replies.