[mod.protocols.tcp-ip] a clarification

jordan@UCBARPA.BERKELEY.EDU.UUCP (02/24/87)

(glad i put a '?' next to it ...) -- the sndmsg balks stuff is from
Wollongong's VMS mailer ...

egged-face,

/jordan

cetron@UTAH-CS.ARPA.UUCP (02/25/87)

In article <8702242033.AA21637@ucbarpa.Berkeley.EDU> jordan@UCBARPA.BERKELEY.EDU (Jordan Hayes) writes:
>(glad i put a '?' next to it ...) -- the sndmsg balks stuff is from
>Wollongong's VMS mailer ...
>
>egged-face,
>
>/jordan

	Don't feel quite so bad, the software tools mailer is somewhat similar:

After it receives the 'terminating' <cr><lf>.<cr><lf> it spawns off a subshell
which attempts to send the receive message header information to a mailer
daemon....if the send works (address is valid, header info complete, etc) then
it returns and the SMTP server responds with the OK message.  If not, it sends
the appropriate error code (syntax error in address - see RFC 822, date missing
etc...).  There IS a window where the remote mailer could time out, but to date
I have never seen this actually happen - remember, it is NOT  trying to deliver
the message, just verify the headers and queue it for delivery.....

-ed cetron
cetron@utah-cs.arpa

ken@HAMLET.CALTECH.EDU.UUCP (02/26/87)

>In article <8702242033.AA21637@ucbarpa.Berkeley.EDU> jordan@UCBARPA.BERKELEY.EDU (Jordan Hayes) writes:
>>(glad i put a '?' next to it ...) -- the sndmsg balks stuff is from
>>Wollongong's VMS mailer ...

    Wollongong's SMTP server spawns a subprocess (called SNDMSG) to
pass the message off to VMSmail. If the subprocess exits fatally, you
get the `sndmsg balks' error.

>	Don't feel quite so bad, the software tools mailer is somewhat similar:
>
>After it receives the 'terminating' <cr><lf>.<cr><lf> it spawns off a subshell
>which attempts to send the receive message header information to a mailer
>daemon....if the send works (address is valid, header info complete, etc) then
>it returns and the SMTP server responds with the OK message.  If not, it sends
>the appropriate error code (syntax error in address - see RFC 822, date missing
>etc...).  There IS a window where the remote mailer could time out, but to date
>I have never seen this actually happen - remember, it is NOT  trying to deliver
>the message, just verify the headers and queue it for delivery.....

    Correction. The Software Tools SMTP receiver does not spawn a
subshell and does all of the verification as the headers come in. It
then queues the message to the mailer daemon which does little more
than expand aliases and copy the file into the delivery queue
directory before returning a success status to the SMTP receiver,
which is then free to return a response to the SMTP partner.

    Any delay seen between <CR><LF>.<CR><LF> and the response code is
due to the time it takes the mailer daemon to copy the file into the
queue. If this is not done syncronously then a machine failure might
cause lost mail. I'd rather get two than none.

					      Kenneth Adelman
					      Caltech