1 files changed, 131 insertions, 0 deletions
diff --git a/usr.sbin/sendmail/KNOWNBUGS b/usr.sbin/sendmail/KNOWNBUGS
new file mode 100644
index 0000000..f34c6b7
--- /dev/null
+++ b/usr.sbin/sendmail/KNOWNBUGS
@@ -0,0 +1,131 @@
+
+
+	     K N O W N   B U G S   I N   S E N D M A I L
+			     (for 8.6.7)
+
+
+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.CS.Berkeley.EDU
+in /ucb/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.
+
+  Sendmail should handle full binary data.  As it stands, it handles
+  any value from 0x01-0xFF in the body and 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.
+
+* No "exposed users" in "nullrelay" configuration.
+
+  The "nullrelay" configuration hides all addresses behind the mail
+  hub name.  Some sites might prefer to expose some names such as
+  root.  This information is always available in Received: lines.
+
+* $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 behaviour is in this
+  circumstance.
+
+* REDIRECT aliases don't work with `n' option.
+
+  If you have option `n' set when you use newaliases and have
+  REDIRECT addresses in your aliases file, you'll get the error
+  messages during the newaliases instead of when email is sent to
+  the address in question.  The workaround is to turn off the `n'
+  option.
+
+* MX records that point at non-existent hosts work strangly.
+
+  Consider the DNS records:
+
+	hostH	MX	1 hostA
+		MX	2 hostB
+	hostA	A	128.32.8.9
+
+  (note that there is no A record for hostB).  If hostA is down,
+  an attempt to send to hostH gives "host unknown" -- that is, it
+  reflects out the status on the last host it tries, which in this
+  case is hostB, which is unknown.  It probably ought to eliminate
+  hostB early in processing.
+
+* NAME environment variables with commas break.
+
+  If you define your NAME environment variable to have a comma
+  (e.g., ``Lastname, Firstname''), and you are using the $q definition
+  that uses ``name <address>'' format, sendmail treats the first and
+  last names as two addresses, thus producing a bogus From line.  You
+  can work around this by changing the $q definition to use
+  ``address (name)''.
+
+* \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.
+
+* DEC Alphas (OSF/1 1.3) sometimes time out on sending mail.
+
+  I have one report that DEC Alphas acting as SMTP clients sometimes
+  will apparently not see the "250 OK" message in response to the
+  dot that indicates the end of the message.  This only happens if
+  the message is run from the queue -- if it gets through on first
+  try, everything is fine.  I have been unable to reproduce this
+  problem at Berkeley.
+
+* accept() problem on SVR4.
+
+  Apparently, the sendmail daemon loop (doing accept()s on the network)
+  can get into a wierd 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.)
+
+* Sending user deletion not done properly in :include: lists.
+
+  If you don't have the "m" (me too) option set, then a person
+  sending to a list that contains themselves should not get a copy
+  of the message.  However, if that list points to a :include: file
+  that has one address per line, this will break, and the sender
+  will always get a copy of their own message, just as though the
+  "m" option were set.
+
+  You can eliminate this by adding commas at the end of each line
+  of the :include: file.
+
+* 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.
+
+(Version 8.18, last updated 3/14/94)