🚀 go-pugleaf

 In article <831160874_OASIS_@wile.demon.co.uk>
  paz@wile.demon.co.uk (Mark Parry) said:-

>
>Hi all,
>        Can anyone help me with my EMail sending problems please ?
> 
>I managed to send one OK with a confirmation of 1 sent, but when I 
>sent the next one, the send and receive data lights flash briefly on 
>my Modem, then my machine justs sits there for AGES, no hard drive 
>accessing, no Modem activity.

You are probably sending  direct.

>after a while, I just pressed F10 and Return, and exited at the NET> 
>prompt. When I got back to OASIS, my Modem hadn't hung up and I don't 
>think the Email had been sent 'cos OASIS still has it in the 'items to 
>upload' window.

If Oasis shows it then it hasn't gone. You need a function key defined 
as follows ...

fkey 93 "ppp sl0 lcp close\n"
     ^^
     change as required (currently means SHIFT-F10).

That will drop the line for you then just type "exit" as per normal.

>I've tried it several times (using smtp kick) and I'm worried that the 
>recipient IS actually receiving the mail and is getting REALLY annoyed 
>at getting this mail several times !

They aren't :-)

What can (and does happen) is that email may go out in groups. It is 
best to leave "smtp trace" and "smtp verbose" as below - so there will 
be an "SMTP QUIT" output for each email successfully dispatched. 
Before you log off, issue "sm l" (short for smtp list) to double check 
they have all gone - if not "smtp kick" again, repeating as necessary.

>What's going on ?!?!!

The problem will lie within STARTUP.NOS, look for the following 
variables and modify where they differ ...

smtp timer 600
smtp wait 1
smtp trace 3
smtp maxclients 10
smtp beep on
smtp gateway post.demon.co.uk
smtp verbose on
smtp delay 1
smtp batch off

>I've tried Demons' helpline, but no joy.....

Busy for 3 days then "sorry we don't know about the atari" eh? :-(

>My gratitude would know no bounds.

Emails get sent in two ways. The first method used is a direct 
connection where SMTP attempts to connect to the destination you 
specify. This can be very slow for *you* because SMTP has to wait for 
the "TCP packets" which make up the email to get delivered and for 
suitable responses to be received from the destination before the 
next bit can be sent.

The second method (gateway) is fast for *you* but slow for the email. 
SMTP just talks to demon which can respond very fast. The demon end 
then queues the email along with everbody else's and sends it when it 
can without any need for you to remain connected.

The "smtp wait" line specifies the amount of time (seconds) SMTP 
spends before giving up on direct posting and passes it to the gateway 
- the smaller the value the better. Unfortunately a zero value does 
not work (iirc means infinite wait) so 1 is used. This can result in 
the occasional unwanted direct connection. There is a way of forcing 
these through the gateway anyway but it's a bit technical.

For all practical purposes, the gateway can be considered as fast as 
direct posting (maybe faster even - depends on bandwidth).

The only time direct posting should be considered is for very 
important emails when there are "advertised" outgoing mail delays.


__

Guy Harrison

guy@swampdog.demon.co.uk