From: Karol E. Zielonko Jr. [zielonko@ixnay-amspay.ucx.lkg.dec.com] Sent: Thursday, September 16, 1999 5:30 AM To: Info-VAX@Mvb.Saic.Com Subject: Re: Queueing msgs direct to UCX SMTP Hi Scott, The format of the control file that is submitted is simply disgusting (and this from the SMTP software engineer, me) and you don't want to try to create one. It is actually in my worklist to scrap the binary file altogther or simplify it somehow. But, if I understand what you want to do, you still may be in luck. Around 3 years back I created a standalone program that you can use to submit a mail message directly to the symbiont. In a nutshell you put the fully formatted, RFC 822 compliant message into a text file and run the utility to read it, convert it to a control file and submit the control file to the symbiont. I called the tool SFF - Send From File. I just checked the V4.1 build trees here and it seems that the SFF image (UCX$SMTP_SFF.EXE) started getting included in the V4.1 kit starting in V4.1 ECO 8. Do you have ECO 8? If not then you should get it. If you see SYS$SYSTEM:UCX$SMTP_SFF.EXE you're in luck. Caveats: This software is currently unsupported! That being said we have been using it as part of our Unix-to-VMS Majordomo port for years and it has been bug free. Because of the great potential for spoofing, running this code requires that either bypass, sysprv or oper priv's are enabled. It is the responsibility of you, the file formatter, to create *all* the SMTP headers, not just the MIME ones. The only header that SFF adds is one Received: header and that is only a security/debug measure for tracking where the mail came from. BTW. Because so many people have been asking for this we may begin supporting it officially in an upcoming release. The remainder of this text is a more detailed writeup on the SFF feature including a full description of the format of the ASCII file you submit to it. Hope this helps. Let me know (via email) how you did. Karol Zielonko zielonko at ucx dot lkg dot dec dot com or karol dot zielonko at compaq dot com This is to document a new feature in UCX SMTP. Briefly the new feature allows one to create an RFC 822 formatted mail message in a file and pass it off to the UCX SMTP mailer to be delivered with headers under your control. Format of the file: The file is an RFC 822 message in a text file with a few SMTP protocol commands (RFC 821) preceding the RFC 822 message. The SMTP protocol commands specify the return path of the mail and the recipients. After the recipients comes the DATA command and then the RFC 822 message. Here is an example: UCXAXP> ty TEST_SMTP_SFF.TXT MAIL FROM: RCPT TO: DATA Date: Sun, 4 Aug 1996 14:48:14 -0400 Message-Id: <96080414481486@ucx.lkg.dec.com> From: zielonko@ucx.lkg.dec.com (Karol Zielonko - UCX engineering - (508)-486-5632) To: zielonko@laddie.ucx.lkg.dec.com Subject: TEST X-VMS-To: SMTP%"zielonko@laddie" This is the test text. To those who are familiar with the SMTP protocol the commands that precede the RFC 822 message are self explanatory. To those who aren't here is a brief explanation. The MAIL FROM and RCPT TO commands form what is called the "envelope" in RFC 821. The MAIL FROM gives the address to which the mail is returned if it needs to be bounced. The RCPT To command gives the address of a recipient. As with the SMTP protocol the commands must appear in the file in the order given above, that is MAIL FROM first followed by RCPT TO and then DATA. Also as with the SMTP protocol there must be one and only one MAIL FROM command. There must be at least one RCPT TO command but there can be more, one for each recipient. The DATA command *must* follow the last RCPT TO command. It can't be left out since it flags the end of the RCPT TO's and the begining of the header block. More notes on the file contents: The text file can be a variable length or Stream_LF. If it's a variable length file you don't need to add end of line CRLFs. If it's a Stream_LF the LF at the end of each line is sufficient. No CR need be added. A blank MAIL FROM is allowed. It looks like: MAIL FROM:<> A blank RCPT TO is not allowed. Each RCPT TO command must contain only one address. If the mail is to go to multiple addresses then one RCPT TO command for each address is required. Since MIME by definition complies with RFC822, MIME mail works too. Do *not* include a Return-Path header in the RFC 822 headers. UCX SMTP puts one in (if the mail is to be delivered locally) based on the MAIL FROM command. If the mail is relayed to another SMTP host the Return-Path will be gleaned from the MAIL FROM command on the final destination host. How to invoke the new function: You can invoke the new function from DCL or from a program. You simply write your RFC 822 mail to a file with the SMTP commands as above and pass the name of the file to UCX SMTP. From a program: UCX$SMTP_MAILSHR.EXE contains a routine called UCX$SMTP_SEND_FROM_FILE. This routine is declared as follows: unsigned int UCX$SMTP_SEND_FROM_FILE(infile_name, logfd, log_level) char *infile_name; FILE *logfd; int log_level; Arguments: infile_name The name of the text file where the RFC 822 mail is located. logfd Optional. If non-null is the pointer to the file to which to log diagnostics. Ie. file must be opened by caller before calling. If no file is specified then output goes to SYS$OUTPUT. log_level Optional. Tells code what level of diagnostics to use. At the point it's either 1 or 0 for on or off. The default is 0 - off. To call the routine link with UCX$SMTP_MAILSHR.EXE. From DCL: I wrote up a jacket program that takes Unix style parameters and passes them to UCX$SMTP_SEND_FROM_FILE. I can give you a .EXE file or the source if you want to redo it. Here's the "usage" text from the program. Usage: SMTP_SFF infile_name [-logfile logfile_name] [-loglevel log_level] infile_name : Name of text input file containing SMTP mail to send. logfile_name : Name of text log file to log diagnostics to. (Default SYS$OUTPUT). log_level : Debug log level. 1 or 0 at this time. (Default 0) Miscellaneous Notes: UCX$SMTP_SEND_FROM_FILE adds a Received: header to the headers you provide. The process must have either bypass, sysprv or oper priv's enabled. This limitation is because there is a great spoofing potential when one has control over the headers of a mail.