KNOWNBUGS revision 38032
138032Speter 238032Speter 338032Speter K N O W N B U G S I N S E N D M A I L 438032Speter (for 8.9.0) 538032Speter 638032Speter 738032SpeterThe following are bugs or deficiencies in sendmail that I am aware of 838032Speterbut which have not been fixed in the current release. You probably 938032Speterwant to get the most up to date version of this from ftp.sendmail.org 1038032Speterin /pub/sendmail/KNOWNBUGS. For descriptions of bugs that have been 1138032Speterfixed, see the file RELEASE_NOTES (in the root directory of the sendmail 1238032Speterdistribution). 1338032Speter 1438032SpeterThis list is not guaranteed to be complete. 1538032Speter 1638032Speter 1738032Speter* Null bytes are not handled properly in headers. 1838032Speter 1938032Speter Sendmail should handle full binary data. As it stands, it handles 2038032Speter all values in the body, but only 0x01-0x80 and 0xA0-0xFF in 2138032Speter the header. Notably missing is 0x00, which would require a major 2238032Speter restructuring of the code -- for example, almost no C library support 2338032Speter could be used to handle strings. 2438032Speter 2538032Speter* Duplicate error messages. 2638032Speter 2738032Speter Sometimes identical, duplicate error messages can be generated. As 2838032Speter near as I can tell, this is rare and relatively innocuous. 2938032Speter 3038032Speter* $c (hop count) macro improperly set. 3138032Speter 3238032Speter The $c macro is supposed to contain the current hop count, for use 3338032Speter when calling a mailer. This macro is initialized too early, and 3438032Speter is always zero (or the value of the -c command line flag, if any). 3538032Speter This macro will probably be removed entirely in a future release; 3638032Speter I don't believe there are any mailers left that require it. 3738032Speter 3838032Speter* If you EXPN a list or user that has a program mailer, the output of 3938032Speter EXPN will include ``@local.host.name''. You can't actually mail to 4038032Speter this address. It's not clear what the right behavior is in this 4138032Speter circumstance. 4238032Speter 4338032Speter* \231 considered harmful. 4438032Speter 4538032Speter Header addresses that have the \231 character (and possibly others 4638032Speter in the range \201 - \237) behave in odd and usually unexpected ways. 4738032Speter 4838032Speter* accept() problem on SVR4. 4938032Speter 5038032Speter Apparently, the sendmail daemon loop (doing accept()s on the network) 5138032Speter can get into a weird state on SVR4; it starts logging ``SYSERR: 5238032Speter getrequests: accept: Protocol Error''. The workaround is to kill 5338032Speter and restart the sendmail daemon. We don't have an SVR4 system at 5438032Speter Berkeley that carries more than token mail load, so I can't validate 5538032Speter this. It is likely to be a glitch in the sockets emulation, since 5638032Speter "Protocol Error" is not possible error code with Berkeley TCP/IP. 5738032Speter 5838032Speter I've also had someone report the message ``sendmail: accept: 5938032Speter SIOCGPGRP failed errno 22'' on an SVR4 system. This message is 6038032Speter not in the sendmail source code, so I assume it is also a bug 6138032Speter in the sockets emulation. (Errno 22 is EINVAL "Invalid Argument" 6238032Speter on all the systems I have available, including Solaris 2.x.) 6338032Speter Apparently, this problem is due to linking -lc before -lsocket; 6438032Speter if you are having this problem, check your Makefile. 6538032Speter 6638032Speter* accept() problem on Linux. 6738032Speter 6838032Speter Apparently, the accept() in sendmail daemon loop can return ETIMEDOUT 6938032Speter and cause sendmail to sleep for 5 seconds during which time no new 7038032Speter connections will be accepted. An error is reported to syslog: 7138032Speter 7238032Speter Jun 9 17:14:12 hostname sendmail[207]: NOQUEUE: SYSERR(root): 7338032Speter getrequests: accept: Connection timed out 7438032Speter 7538032Speter "Connection timed out" is not documented as a valid return from 7638032Speter accept(2) and this was believed to be a bug in the Linux kernel. 7738032Speter Later information from the Linux kernel group states that Linux 7838032Speter 2.0 kernels follow RFC1122 while sendmail follows the original BSD 7938032Speter (now POSIX 1003.1g draft) specification. The 2.1.X and later kernels 8038032Speter will follow the POSIX draft. 8138032Speter 8238032Speter* Excessive mailing list nesting can run out of file descriptors. 8338032Speter 8438032Speter If you have a mailing list that includes lots of other mailing 8538032Speter lists, each of which has a separate owner, you can run out of 8638032Speter file descriptors. Each mailing list with a separate owner uses 8738032Speter one open file descriptor (prior to 8.6.6 it was three open 8838032Speter file descriptors per list). This is particularly egregious if 8938032Speter you have your connection cache set to be large. 9038032Speter 9138032Speter* Connection caching breaks if you pass the port number as an argument. 9238032Speter 9338032Speter If you have a definition such as: 9438032Speter 9538032Speter Mport, P=[IPC], F=kmDFMuX, S=11/31, R=21, 9638032Speter M=2100000, T=DNS/RFC822/SMTP, 9738032Speter A=IPC [127.0.0.1] $h 9838032Speter 9938032Speter (i.e., where $h is the port number instead of the host name) the 10038032Speter connection caching code will break because it won't notice that 10138032Speter two messages addressed to different ports should use different 10238032Speter connections. 10338032Speter 10438032Speter* ESMTP SIZE underestimates the size of a message 10538032Speter 10638032Speter Sendmail makes no allowance for headers that it adds, nor does it 10738032Speter account for the SMTP on-the-wire \r\n expansion. It probably doesn't 10838032Speter allow for 8->7 bit MIME conversions either. 10938032Speter 11038032Speter* Paths to programs being executed and the mode of program files are 11138032Speter not checked. Essentially, the RunProgramInUnsafeDirPath and 11238032Speter RunWritableProgram bits in the DontBlameSendmail option are always 11338032Speter set. This is not a problem if your system is well managed (that is, 11438032Speter if binaries and system directories are mode 755 instead of something 11538032Speter foolish like 777). 11638032Speter 11738032Speter* 8-bit data in GECOS field 11838032Speter 11938032Speter If the GECOS (personal name) information in the passwd file contains 12038032Speter 8-bit characters, those characters can be included in the message 12138032Speter header, which can cause problems when sending SMTP to hosts that 12238032Speter only accept 7-bit characters. 12338032Speter 12438032Speter* 8->7 bit MIME conversion 12538032Speter 12638032Speter When sendmail is doing 8->7 bit MIME conversions, and the message 12738032Speter contains certain MIME body types that cannot be converted to 7-bit, 12838032Speter sendmail will strip the message to 7-bit. 12938032Speter 13038032Speter* 7->8 bit MIME conversion 13138032Speter 13238032Speter If a message that is encoded as 7-bit MIME is converted to 8-bit and 13338032Speter that message when decoded is illegal (e.g., because of long lines or 13438032Speter illegal characters), sendmail can produce an illegal message. 13538032Speter 13638032Speter* MIME encoded full name phrases in the From: header 13738032Speter 13838032Speter If a full name phrase includes characters from MustQuoteChars, sendmail 13938032Speter will quote the entire full name phrase. If MustQuoteChars includes 14038032Speter characters which are not special characters according to STD 11 (RFC 14138032Speter 822), this quotation can interfere with MIME encoded full name phrases. 14238032Speter By default, sendmail includes the single quote character (') in 14338032Speter MustQuoteChars even though it is not listed as a special character in 14438032Speter STD 11. 14538032Speter 14638032Speter 14738032Speter(Version 8.32, last updated 6/30/98) 148