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