Date: Thu,  7 Oct 93 04:30:01 PDT
From: Advanced Amateur Radio Networking Group <tcp-group@ucsd.edu>
Errors-To: TCP-Group-Errors@UCSD.Edu
Reply-To: TCP-Group@UCSD.Edu
Precedence: Bulk
Subject: TCP-Group Digest V93 #260
To: tcp-group-digest


TCP-Group Digest            Thu,  7 Oct 93       Volume 93 : Issue  260

Today's Topics:
                         FTP client && net.rc
                             Lost message
                       Need Info!!!!! (2 msgs)
                        Raising the S/N ratio

Send Replies or notes for publication to: <TCP-Group@UCSD.Edu>.
Subscription requests to <TCP-Group-REQUEST@UCSD.Edu>.
Problems you can't solve otherwise to brian@ucsd.edu.

Archives of past issues of the TCP-Group Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives".

We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party.  Your mileage may vary.  So there.
----------------------------------------------------------------------

Date: Wed, 06 Oct 1993 23:16:43 EDT
From: "Russell Nelson" <nelson@crynwr.com>
Subject: FTP client && net.rc
To: tcp-group@ucsd.edu

I've updated my patch for the FTP client, last updated for 890918 NOS!

If you want to automagically have your username and password supplied
when you FTP into a host, apply this patch.

These patches let you put passwords (in cleartext!) into a file called
"net.rc".  This file should have lines in the form "host user password".
If password is missing, you are prompted for it.

No copyright claimed.

-Russell Nelson, <nelson@crynwr.com>


C:\H\RCSDSRC>rcsdiff -u ftpcli.cc
===================================================================
RCS file: RCS\ftpcli.c
retrieving revision 1.20
diff -c -r1.20 ftpcli.c
*** c:\temp\t1000013 Thu Oct  7 02:16:00 1993
--- ftpcli.c Thu Oct  7 02:15:28 1993
***************
*** 90,98 ****
   struct ftpcli ftp;
   struct sockaddr_in fsocket;
   int resp,vsave;
!  char *bufsav,*cp;
   FILE *control;
   int s;
  
   /* Allocate a session control block */
   if((sp = newsession(Cmdline,FTP,1)) == NULLSESSION){
--- 90,99 ----
   struct ftpcli ftp;
   struct sockaddr_in fsocket;
   int resp,vsave;
!  char *bufsav,*cp,*ftpcli_login();
   FILE *control;
   int s;
+  unsigned int i;
  
   /* Allocate a session control block */
   if((sp = newsession(Cmdline,FTP,1)) == NULLSESSION){
***************
*** 159,184 ****
    switch(resp){
    case 220:
     /* Sign-on banner; prompt for and send USER command */
!    getline(sp,"Enter user name: ",ftp.buf,LINELEN);
     /* Send the command only if the user response
!     * was non-null
!     */
!    if(ftp.buf[0] != '\n'){
!     fprintf(control,"USER %s",ftp.buf);
      resp = getresp(&ftp,200);
     } else
      resp = 200; /* dummy */
     break;
    case 331:
!    /* turn off echo */
!    sp->ttystate.echo = 0;
!    getline(sp,"Password: ",ftp.buf,LINELEN);
!    printf("\n");
!    /* Turn echo back on */
!    sp->ttystate.echo = 1;
!    /* Send the command only if the user response
!     * was non-null
!     */
     if(ftp.buf[0] != '\n'){
      fprintf(control,"PASS %s",ftp.buf);
      resp = getresp(&ftp,200);
--- 160,191 ----
    switch(resp){
    case 220:
     /* Sign-on banner; prompt for and send USER command */
!    if((cp = ftpcli_login(&ftp, sp->name)) == NULLCHAR){
!     getline(sp,"Enter user name: ",ftp.buf,LINELEN);
!     cp = ftp.buf;
!    }
     /* Send the command only if the user response
!    * was non-null
!    */
!    if(cp[0] != '\n'){
!     fprintf(control,"USER %s",cp);
      resp = getresp(&ftp,200);
     } else
      resp = 200; /* dummy */
+    cp[0] = '\n';
     break;
    case 331:
!    if(ftp.buf[0] == '\0') {
!     /* turn off echo */
!     sp->ttystate.echo = 0;
!     getline(sp,"Password: ",ftp.buf,LINELEN);
!     printf("\n");
!     /* Turn echo back on */
!     sp->ttystate.echo = 1;
!     /* Send the command only if the user response
!      * was non-null
!      */
!    }
     if(ftp.buf[0] != '\n'){
      fprintf(control,"PASS %s",ftp.buf);
      resp = getresp(&ftp,200);
***************
*** 824,829 ****
--- 831,882 ----
    return 1;
  failure:;
   return 1;
+ }
+ /* Attempt to log in the user whose name is in ftp->username and password
+  * in pass
+  */
+ static char *
+ ftpcli_login(ftp,host)
+ struct ftpcli *ftp;
+ char *host;
+ {
+  char buf[80],*username,*password;
+  FILE *fp;
+  extern char *Hostfile; /* List of user names and permissions */
+ 
+  if ((host = strchr(host,' ')) == NULLCHAR){
+   return NULLCHAR;
+  }
+  host++;
+  if((fp = fopen(Hostfile,"r")) == NULLFILE){
+   return NULLCHAR;
+  }
+  while(fgets(buf,sizeof(buf),fp),!feof(fp)){
+   rip(buf);
+   if(buf[0] == '#')
+    continue; /* Comment */
+   if((username = strchr(buf,' ')) == NULLCHAR)
+    /* Bogus entry */
+    continue;
+   *username++ = '\0';  /* Now points to user name */
+   if(strcmp(host,buf) == 0)
+    break;  /* Found host name */
+  }
+  if(feof(fp)){
+   /* User name not found in file */
+   fclose(fp);
+   return NULLCHAR;
+  }
+  fclose(fp);
+  /* Look for space after user field in file */
+  if((password = strchr(username,' ')) == NULLCHAR)
+   /* if not there then we'll prompt */
+   password = "";
+  else
+   *password++ = '\0';  /* Now points to password */
+   sprintf(ftp->buf, "%s%c%c%s\n%c", password, *password?'\n':'\0',
+    '\0', username, '\0');
+  return ftp->buf + strlen(password) + 2;
  }
  
  

===================================================================
RCS file: RCS\files.c
retrieving revision 1.9
diff -c -r1.9 files.c
*** c:\temp\t1008960 Thu Oct  7 02:16:34 1993
--- files.c Wed Oct  6 19:11:46 1993
***************
*** 8,13 ****
--- 8,14 ----
  
  #ifdef MSDOS
  char System[] = "MSDOS";
+ char *Hostfile = "/net.rc";  /* host and passwords */
  char *Startup = "/autoexec.net"; /* Initialization file */
  char *Userfile = "/ftpusers"; /* Authorized FTP users and passwords */
  char *Maillog = "/spool/mail.log"; /* mail log */

-- 
-russ <nelson@crynwr.com> What canst *thou* say?
Crynwr Software           Crynwr Software sells packet driver support.
11 Grant St.              315-268-1925 Voice  |  LPF member - ask me about
Potsdam, NY 13676         315-268-9201 FAX    |  the harm software patents do.

------------------------------

Date: Wed, 6 Oct 93 09:58:56 EDT
From: crompton@NADC.NAVY.MIL (D. Crompton)
Subject: Lost message
To: geertj@ica.philips.nl, tcp-group@ucsd.edu

I thought that was Phil Karn that did the Star Trek Decipher?

------------------------------

Date: Wed, 6 Oct 1993 07:22:49 -0400 (EDT)
From: Admin <men2a!aquin!k4ngc!k4ngc!dbennett@uunet.UU.NET>
Subject: Need Info!!!!!
To: tcp-group@ucsd.edu

I have a Unix system operational at home running XOBBS and and UNIX
LLBBS. I am looking for someone who has current copies of all NOS
and NOS related programs that I can get using a 150MB Cart Tape.
I do not have direct link into Internet so I cant FTP any files.
I would like to make these files available to those who do now
have Internet connect.  Can anyone help me.

73's Don Bennett
-- 
+--------------------------------------------------+
| Donald H. Bennett (K4NGC) | (Voice) 703-670-4773 |
| 15016 Carlsbad Road       | (Data)  703-680-5970 |
| Woodbridge, Va 22193      | (UUCP)  703-680-5970 |
| (AX25)  K4NGC @ K4NGC     |         login: nuucp |
| (Domain) k4ngc.ampr.org   | (IP#)   44.96.0.1    |
+--------------------------------------------------+
| Internet: uunet!men2a!aquin!k4ngc!dbennett       |
+--------------------------------------------------+

------------------------------

Date: Wed, 6 Oct 1993 07:22:49 -0400 (EDT)
From: Admin <men2a!aquin!k4ngc!k4ngc!dbennett@uunet.UU.NET>
Subject: Need Info!!!!!
To: tcp-group@ucsd.edu

I have a Unix system operational at home running XOBBS and and UNIX
LLBBS. I am looking for someone who has current copies of all NOS
and NOS related programs that I can get using a 150MB Cart Tape.
I do not have direct link into Internet so I cant FTP any files.
I would like to make these files available to those who do now
have Internet connect.  Can anyone help me.

73's Don Bennett
-- 
+--------------------------------------------------+
| Donald H. Bennett (K4NGC) | (Voice) 703-670-4773 |
| 15016 Carlsbad Road       | (Data)  703-680-5970 |
| Woodbridge, Va 22193      | (UUCP)  703-680-5970 |
| (AX25)  K4NGC @ K4NGC     |         login: nuucp |
| (Domain) k4ngc.ampr.org   | (IP#)   44.96.0.1    |
+--------------------------------------------------+
| Internet: uunet!men2a!aquin!k4ngc!dbennett       |
+--------------------------------------------------+

------------------------------

Date: Wed, 6 Oct 93 23:46:05 EDT
From: "Ross Patterson" <n4yyh@wa2hee.ampr.org>
Subject: Raising the S/N ratio
To: tcp-group@UCSD.EDU

On Sat, 02 Oct 1993 21:38:53 -0400, Ashok Aiyar wrote:

>>Is the bug still in the SMTP server and client that means that the
>>translation of lines with a dot at the beginning are not handled >correctly.
>
>Yes, it appears to be still in there.  I am not aware of any NET/NOS which 
>handles the "." at the beginning of a line correctly, if I am interpreting 
>the RFC correctly.

I haven't been around tcp-group long enough to know if this is "the" bug,
but the SMTP spec is quite explicit about how a receiver-SMTP should handle
lines beginning with a dot.  RFC 821 (August 1982) "SMTP" page 41, section
4.5.2 "TRANSPARENCY" reads:

   "2. When a line of mail text is received by the receiver-SMTP it
    checks the line.  If the line is composed of a single period it is the
    end of mail.  If the first character is a period and there are other
    characters on the line, the first character is deleted."

RFC 1123 (October 1989) "Requirements for Internet Hosts - Application and
Support" page 55, section 5.2.11 "Transparency: RFC-821 Section 4.5.2"
reinforces this:

   "Implementors MUST be sure that their mail systems always add and delete
    periods to ensure mail transparency."

>If I compose a message with a line beginning with ".", my SMTP client 
>converts those lines to begin with "..".  It is my understanding the 
>receiving SMTP should remove the extra "." -- but I could well be mistaken.

It's not just the extra period - it's any leading (but not standalone)
period.  A conforming sender-SMTP will always send doubled leading periods,
but the spec is clear that the leading period gets removed regardless of
what follows it.  The sole exception is the "<CRLF>.<CRLF>" end-of-mail
sequence.

A quick examination of SMTPSERV.C from WG7J's JNOS 1.09 shows the
following.  KA9Q's 930622 release varies a bit, but the key points are
the same.  getmsgtxt() is called by the DATA command to read the mail text
from the sender-SMTP over the network:

static int
getmsgtxt(mp)
struct smtpsv *mp;
{
 ... set up ...
 while(1){
  if(recvline(mp->s,p,sizeof(buf)) == -1){
   return 1;
  }
  rip(p);
  /* check for end of message ie a . or escaped .. */
  if (*p == '.'){
   if (*++p == '\0'){
    ... end of message processing ...
                return 0;
   } else if (!(*p == '.' && *(p+1) == '\0'))
    p--;
  }
  ... process input line ...
 }
}

The "if (!(*p ... p--;" sequence looks like SMTPSERV only removes the 
period on lines consisting entirely of 2 periods (i.e. "<CRLF>..<CRLF>").  

>If anyone is aware of an SMTP patch for this problem, I would appreciate 
>hearing about it.

It would seem the thing to do is to delete:

     else if (!(*p == '.' && *(p+1) == '\0'))
           p--;

thus removing any period that starts a line (i.e. "<CRLF>.").  A more
conservative approach, that honors the spirit of RFC 821 if not it's
letter, would be to replace that code fragment with:

     else if (*p != '.')
           p--;

thus removing the first of a pair of periods that start a line (i.e. 
"<CRLF>.."). 

Note: The above suggestions are untested.  That would be cheating. 
Software is a thing of the mind.

73,
Ross Patterson
N4YYH

------------------------------

End of TCP-Group Digest V93 #260
******************************
******************************