Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watnot!watmath!clyde!cbatt!ucbvax!sdcsvax.ucsd.edu!brian From: brian@sdcsvax.ucsd.edu.UUCP Newsgroups: mod.protocols.tcp-ip Subject: Submission for mod-protocols-tcp-ip Message-ID: <8702262320.AA04321@sdcsvax.UCSD.EDU> Date: Thu, 26-Feb-87 18:20:10 EST Article-I.D.: sdcsvax.8702262320.AA04321 Posted: Thu Feb 26 18:20:10 1987 Date-Received: Sat, 28-Feb-87 08:03:51 EST Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 83 Approved: tcp-ip@sri-nic.arpa 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 recipients. What's going on: When mail is sent over an SMTP connection such as is used on the ethernet, a RCPT TO:
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: 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" problems. 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