I appreciate your response.  I'll try the FULL822 option while 
researching options with Microsoft.  They've sent me a patch in the 
past, but the error has always returned - even in 2003's SMTP server.  
The error is documented here:

http://support.microsoft.com/default.aspx?scid=kb;en-us;321150

-Peter


Nathan Brindle wrote:

> At 12:58 AM 3/20/2005 -0600, you wrote:
>
>> This is because Listserv sends its posts as a single message with 
>> multiple recipients.  Is there any way to have the engine instead 
>> send the single message 150 times to each of my list members?  Seems 
>> like the manual is silent on this configuration change.
>
>
> Not really silent, just not fond of the idea.  You can set everyone on 
> the list to the deprecated (but still documented) FULL822 personal 
> option and a separate SMTP envelope is generated for each address.  
> This is deprecated, however, because it significantly slows things 
> down, particularly if the outbound SMTP server is optimised for BSMTP.
>
> The problem is really not with LISTSERV, though.  The IIS SMTP engine 
> shouldn't be trying to throw errors back in the middle of a BSMTP 
> transaction.  From LISTSERV's perspective, a well-behaved SMTP server 
> should accept the BSMTP transaction as a unit and send delivery errors 
> back only after the entire transaction is finished.  LISTSERV is not a 
> full-featured SMTP server; its function is to hand off mail in bulk to 
> a full-featured SMTP server for delivery, and it is not designed to 
> handle errors generated "on the fly" in the middle of a BSMTP 
> transaction.
>
> Some SMTP servers can be configured not to do this sort of thing (for 
> instance, sendmail often is configured by default to do 
> canonicalization of addresses on the fly, which doesn't play well with 
> LISTSERV, but you can turn that off by adding FEATURE(`nocanonify') in 
> sendmail.mc).  However, I don't know if the IIS server can be 
> reconfigured not to throw delivery errors during an SMTP conversation 
> or not.
>
> I'm sure you'll find quite a bit of art on this subject in the 
> archives of this list, though.
>
> Nathan
>
> .
>