+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. Fixed (for the message body only)
+ in 8.7.
+
+* 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 and unbalanced quotes 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)''.
+
+ If you have an unbalanced double quote (e.g., ``Firstname"Lastname'')
+ the auto-quoting algorithm breaks.
+
+* \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.
projects / unix-history / blobdiff