Under unix, no, because SMTP_FORWARD= is set to the local machine by default (I believe it actually defaults to the value of NODE= unless you have the special variable SMTP_HOSTNAME= defined, but I don't have the code in front of me; either way it shouldn't be necessary to define SMTP_FORWARD= under unix). Under Windows, on the other hand, you do have to define SMTP_FORWARD= when defining SMTP_FORWARD_n=, because if you don't there is no fallback host defined for use if asynchronous delivery fails. I need to note this difference in the manuals, although it makes no practical difference under unix if you go ahead and define SMTP_FORWARD= in go.user when adding SMTP_FORWARD_n= asynchronous workers. FWIW (I saw your other message) this -is- similar to what ASYNCH_SMTP=1 does but it allows you to tune asynchronous delivery by adding more than one asynchronous delivery connexion. ASYNCH_SMTP was added primarily for demonstration purposes (to show that sendmail was usually the bottleneck in situations where LISTSERV was slow to process commands), whereas SMTP_FORWARD_n is the supported method for handling asynchronous outbound delivery. You'll note that ASYNCH_SMTP isn't documented :) Nathan On Thu, 9 Nov 2000 08:30:04 -0500 Paul Russell said: >In the discussion of the SMTP_FORWARD_n statement, the Site Manager's >Manual states: > > You MUST define an SMTP_FORWARD= parameter in the site > configuration file which will tell LISTSERV where to deliver > mail synchronously should asynchronous delivery fail for any > reason. > >Is this required, when the SMTP_FORWARD_n statement is being used in the >manner described in the FAQ? > >-- pdr > >On 8 Nov 2000, Nathan Brindle <[log in to unmask]> wrote: >> >> Assuming this is unix, I just added a FAQ with regard to this: >> >> http://www.lsoft.com/manuals/lsv-faq.stm#1.13 >> >> Nathan >> >> On Wed, 8 Nov 2000 11:02:08 -0500 you said: >> >Listserv's web interface is much to be desired! while Listserv is busy, it >will >> >not let >> >you read private archives (AUTH) until it completes it's task. :( >> >I'd like to know if this will be changed anytime soon. >> > >> >Thanks for the response! >> >