home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / mail / sendmail / 2816 < prev    next >
Encoding:
Text File  |  1992-11-17  |  2.9 KB  |  59 lines
  1. Newsgroups: comp.mail.sendmail
  2. Path: sparky!uunet!ukma!darwin.sura.net!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!mp.cs.niu.edu!rickert
  3. From: rickert@mp.cs.niu.edu (Neil Rickert)
  4. Subject: Re: UIUC/IDA sendmail 565c bug + FIX
  5. Message-ID: <1992Nov18.014417.8200@mp.cs.niu.edu>
  6. Organization: Northern Illinois University
  7. References: <1992Nov17.234000.14505@usl.edu>
  8. Date: Wed, 18 Nov 1992 01:44:17 GMT
  9. Lines: 48
  10.  
  11. In article <1992Nov17.234000.14505@usl.edu> jpd@ucs.usl.edu (Dugal James P.) writes:
  12. >Here is a smtp trace from the KA9Q program, sending mail to a SunOS system
  13. >running sendmail 5.65c.  Note that the second MAIL FROM is lost (or more
  14. >properly, received out-of-order) by sendmail, resulting in a 503 error.
  15. >The KA9Q option SMTP BATCH was set on, which causes the HELO, MAIL FROM,
  16. >RCPT TO, and DATA commands to be sent in one transmission.
  17.  
  18. This is very definitely not a sendmail bug.  You can argue that it was
  19. a bad design decision if you wish, but you cannot call it a bug.  It is
  20. also not unique to IDA versions of sendmail.  This happens in the vanilla
  21. BSD version also.
  22.  
  23. If you read RFC821 you will see that it describes a dialogue.  The client
  24. sends a verb to the server then the server replies.  With your batch
  25. mode you are breaking this dialogue assumption.  If there is a bug it
  26. is in running KA9Q in BATCH mode.
  27.  
  28. >*** srvrsmtp.c.orig    Mon Jun 24 15:27:31 1991
  29. >--- srvrsmtp.c    Tue Nov 17 13:31:18 1992
  30. >***************
  31. >... [patch deleted for brevity]
  32.  
  33. >Is there a more elegant fix, or at least a diagnosis of what's
  34. >happening and why this fixes the problem?
  35.  
  36. Your fix will work, but may cause other problems.
  37.  
  38. Sendmail, after processing the MAIL command, does a fork().  The rest
  39. of the transaction is handled by the child.  At the end of the message
  40. the child exits, and the parent reads the next transaction (or the QUIT).
  41.  
  42. When you batch data, the input buffer is not empty at the time of the
  43. fork().  The child gets its own copy of the buffer, and processes that.
  44. When the child exits, the parent resumes where it left off, and since
  45. there was unprocessed data in the buffer at the time of fork(), that is
  46. now processed.  The parent sendmail is thus seeing the RCPT verbs which
  47. the child had already processed.  Moreover, with batching, when the
  48. child sees the line beginning with '.' at the end of the message, its
  49. buffer may not be empty, but could contain the next MAIL command.  It
  50. is likely that this second MAIL was not in the parent's original buffer,
  51. and since it has already been read() once, cannot be read again.  Thus
  52. the second MAIL might be lost completely when the child terminates.
  53.  
  54. The best fix is to follow RFC821, and not assume such batching will
  55. work.  Note that sendmail depends on the fork()/exit() to reset state
  56. at the end of a message.  With the fork() removed other problems may
  57. occur, such as running out of memory or running out of file descriptors.
  58.  
  59.