Submission for mod-protocols-tcp-ip

Brian Kantor (
26 Feb 87 23:20:10 GMT

Path: sdcsvax!brian
From: brian@sdcsvax.UCSD.EDU (Brian Kantor)
Newsgroups: mod.protocols.tcp-ip
Subject: Re: duplicate message in SMTP ("sndmsg balks, try again later")
Message-ID: <2766@sdcsvax.UCSD.EDU>
Date: 26 Feb 87 23:20:09 GMT
References: <8702241936.AA19824@ucbarpa.Berkeley.EDU>
Reply-To: brian@sdcsvax.UCSD.EDU (Brian Kantor)
Distribution: world
Organization: UCSD wombat breeding society
Lines: 71

This is a message I sent a few weeks ago to someone locally who was
seeing this problem. Some of the information in here is therefore
UCSD-specific, but you'll get the idea....
More than you ever wanted to know about VMS SMTP mail:

Brief description of problem: mail addressed to many recipients on a
VMS machine has been received as multiple duplicates by some of the

What's going on: When mail is sent over an SMTP connection such as is
used on the ethernet, a RCPT TO:<address> line is sent for each
individual recipient to be delivered to on that connection (i.e., on
that host). The receiving mailer (in this case, the Wollongong VMS
mail package) is responsible for validating and delivering the mail to
those recipients.

It has been previously noticed that one somewhat common VMS practice
can cause difficulties with mail: that of removing the home directory
of a user who is still in the VMS User Authorisation File. (Apparently
this prevents logins whilst still maintaining accounting information in
the UAF. Or something; I'm not a VMS guru by a long shot.) The
Wollongong mail system apparently checks the validity of a mail
delivery address (the RCPT TO:<mailbox> line) during the SMTP
transaction by checking the UAF. If a user is still in that file, it
OK's the destination mailbox and continues. If the user is NOT in the
UAF, a reject message is instead returned, and the mail will be
returned to the sender as having one or more "recipient unknown"

After the list of recipients is negotiated, the mail message itself is
sent. At the end of this DATA portion of the SMTP connection, the
Wollongong VMS software invokes the VMS mailer to deliver the actual
mail. The SMTP connection is still open to the originating mailer (in
this case, sdcsvax's sendmail daemon), and will remain that way until
OK and QUIT transactions take place. Ordinarily, the Wollongong
software delivers the mail to the user's mailbox file, and returns an
OK to the sender, who in turn QUITS the connection, and all is well.

However, if the recipients's home directory on the VMS system is
missing, the delivery fails, and an error code is returned. Sendmail
then assumes that the mail wasn't delivered, since it never got the OK,
and requeues the message for delivery on the next queue run (about 20
minutes later under our circumstances), and the whole process repeats
until either the mail is successfully delivered to all validated
recipients, or until the message times out after 3 days (or someone
goes in and snuffs it).

Where this is a real pain is when you have a long list of recipients
and somewhere in the middle of it (or worse, near the end!) there is
one whose mailbox isn't available for delivery - if, for instance, his
home directory is missing. Then what happens is that all the
recipients PREVIOUS to him have gotten the mail message delivered to
them, but sendmail gets an error back from the Wollongong VMS mailer,
and requeues the message to ALL the recipients again, so they'll get
another copy 20 minutes later.

There isn't any cure for this, except for Wollongong to make their
software smarter. There's no provision in the SMTP specification to
allow the mail transport mechanism to accept a recipient in the earlier
part of the transaction, and later selectively reject it. Obviously
one should not send messages to people who aren't there anymore, but
sometimes it is difficult to tell which are valid addresses when doing
massive bulk mailings. Neither is it particularly intelligent to
return an error message to sendmail that applies to only one recipient
when the message isn't totally lost. I guess sendmail is at fault here
too. Maybe its the SMTP specification that's losing.

        Brian Kantor UCSD Office of Academic Computing
                        Academic Network Operations Group UCSD B-028,
                        La Jolla, CA 92093 USA

This archive was generated by hypermail 2.0b3 on Thu Mar 09 2000 - 14:37:43 GMT