1 files changed, 147 insertions, 0 deletions
diff --git a/contrib/sendmail/KNOWNBUGS b/contrib/sendmail/KNOWNBUGS
new file mode 100644
index 0000000..cd62b20
--- /dev/null
+++ b/contrib/sendmail/KNOWNBUGS
@@ -0,0 +1,147 @@
+
+
+	     K N O W N   B U G S   I N   S E N D M A I L
+			     (for 8.9.0)
+
+
+The following are bugs or deficiencies in sendmail that I am aware of
+but which have not been fixed in the current release.  You probably
+want to get the most up to date version of this from ftp.sendmail.org	
+in /pub/sendmail/KNOWNBUGS.  For descriptions of bugs that have been
+fixed, see the file RELEASE_NOTES (in the root directory of the sendmail
+distribution).
+
+This list is not guaranteed to be complete.
+
+
+* Null bytes are not handled properly in headers.
+
+  Sendmail should handle full binary data.  As it stands, it handles
+  all values in the body, but only 0x01-0x80 and 0xA0-0xFF in
+  the header.  Notably missing is 0x00, which would require a major
+  restructuring of the code -- for example, almost no C library support
+  could be used to handle strings.
+
+* Duplicate error messages.
+
+  Sometimes identical, duplicate error messages can be generated.  As
+  near as I can tell, this is rare and relatively innocuous.
+
+* $c (hop count) macro improperly set.
+
+  The $c macro is supposed to contain the current hop count, for use
+  when calling a mailer.  This macro is initialized too early, and
+  is always zero (or the value of the -c command line flag, if any).
+  This macro will probably be removed entirely in a future release;
+  I don't believe there are any mailers left that require it.
+
+* If you EXPN a list or user that has a program mailer, the output of
+  EXPN will include ``@local.host.name''.  You can't actually mail to
+  this address.  It's not clear what the right behavior is in this
+  circumstance.
+
+* \231 considered harmful.
+
+  Header addresses that have the \231 character (and possibly others
+  in the range \201 - \237) behave in odd and usually unexpected ways.
+
+* accept() problem on SVR4.
+
+  Apparently, the sendmail daemon loop (doing accept()s on the network)
+  can get into a weird state on SVR4; it starts logging ``SYSERR:
+  getrequests: accept: Protocol Error''.  The workaround is to kill
+  and restart the sendmail daemon.  We don't have an SVR4 system at
+  Berkeley that carries more than token mail load, so I can't validate
+  this.  It is likely to be a glitch in the sockets emulation, since
+  "Protocol Error" is not possible error code with Berkeley TCP/IP.
+
+  I've also had someone report the message ``sendmail: accept:
+  SIOCGPGRP failed errno 22'' on an SVR4 system.  This message is
+  not in the sendmail source code, so I assume it is also a bug
+  in the sockets emulation.  (Errno 22 is EINVAL "Invalid Argument"
+  on all the systems I have available, including Solaris 2.x.)
+  Apparently, this problem is due to linking -lc before -lsocket;
+  if you are having this problem, check your Makefile.
+
+* accept() problem on Linux.
+
+  Apparently, the accept() in sendmail daemon loop can return ETIMEDOUT
+  and cause sendmail to sleep for 5 seconds during which time no new
+  connections will be accepted.  An error is reported to syslog:
+
+  Jun  9 17:14:12 hostname sendmail[207]: NOQUEUE: SYSERR(root):
+			getrequests: accept: Connection timed out
+
+  "Connection timed out" is not documented as a valid return from
+  accept(2) and this was believed to be a bug in the Linux kernel.
+  Later information from the Linux kernel group states that Linux
+  2.0 kernels follow RFC1122 while sendmail follows the original BSD
+  (now POSIX 1003.1g draft) specification.  The 2.1.X and later kernels
+  will follow the POSIX draft.
+
+* Excessive mailing list nesting can run out of file descriptors.
+
+  If you have a mailing list that includes lots of other mailing
+  lists, each of which has a separate owner, you can run out of
+  file descriptors.  Each mailing list with a separate owner uses
+  one open file descriptor (prior to 8.6.6 it was three open
+  file descriptors per list).  This is particularly egregious if
+  you have your connection cache set to be large.
+
+* Connection caching breaks if you pass the port number as an argument.
+
+  If you have a definition such as:
+
+	  Mport,          P=[IPC], F=kmDFMuX, S=11/31, R=21,
+			  M=2100000, T=DNS/RFC822/SMTP,
+			  A=IPC [127.0.0.1] $h
+
+  (i.e., where $h is the port number instead of the host name) the
+  connection caching code will break because it won't notice that
+  two messages addressed to different ports should use different
+  connections.
+
+* ESMTP SIZE underestimates the size of a message
+
+  Sendmail makes no allowance for headers that it adds, nor does it
+  account for the SMTP on-the-wire \r\n expansion.  It probably doesn't
+  allow for 8->7 bit MIME conversions either.
+
+* Paths to programs being executed and the mode of program files are
+  not checked.  Essentially, the RunProgramInUnsafeDirPath and
+  RunWritableProgram bits in the DontBlameSendmail option are always
+  set.  This is not a problem if your system is well managed (that is,
+  if binaries and system directories are mode 755 instead of something
+  foolish like 777).
+
+* 8-bit data in GECOS field
+
+  If the GECOS (personal name) information in the passwd file contains
+  8-bit characters, those characters can be included in the message
+  header, which can cause problems when sending SMTP to hosts that
+  only accept 7-bit characters.
+
+* 8->7 bit MIME conversion
+
+  When sendmail is doing 8->7 bit MIME conversions, and the message
+  contains certain MIME body types that cannot be converted to 7-bit,
+  sendmail will strip the message to 7-bit.
+
+* 7->8 bit MIME conversion
+
+  If a message that is encoded as 7-bit MIME is converted to 8-bit and
+  that message when decoded is illegal (e.g., because of long lines or
+  illegal characters), sendmail can produce an illegal message.
+
+* MIME encoded full name phrases in the From: header
+
+  If a full name phrase includes characters from MustQuoteChars, sendmail  
+  will quote the entire full name phrase. If MustQuoteChars includes  
+  characters which are not special characters according to STD 11 (RFC  
+  822), this quotation can interfere with MIME encoded full name phrases. 
+  By default, sendmail includes the single quote character (') in
+  MustQuoteChars even though it is not listed as a special character in
+  STD 11.
+
+
+(Version 8.32, last updated 6/30/98)