KNOWNBUGS revision 43730
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 6842575Speter The accept() in sendmail daemon loop can return ETIMEDOUT. An 6942575Speter error is reported to syslog: 7038032Speter 7138032Speter Jun 9 17:14:12 hostname sendmail[207]: NOQUEUE: SYSERR(root): 7238032Speter getrequests: accept: Connection timed out 7338032Speter 7438032Speter "Connection timed out" is not documented as a valid return from 7538032Speter accept(2) and this was believed to be a bug in the Linux kernel. 7638032Speter Later information from the Linux kernel group states that Linux 7738032Speter 2.0 kernels follow RFC1122 while sendmail follows the original BSD 7838032Speter (now POSIX 1003.1g draft) specification. The 2.1.X and later kernels 7938032Speter will follow the POSIX draft. 8038032Speter 8138032Speter* Excessive mailing list nesting can run out of file descriptors. 8238032Speter 8338032Speter If you have a mailing list that includes lots of other mailing 8438032Speter lists, each of which has a separate owner, you can run out of 8538032Speter file descriptors. Each mailing list with a separate owner uses 8638032Speter one open file descriptor (prior to 8.6.6 it was three open 8738032Speter file descriptors per list). This is particularly egregious if 8838032Speter you have your connection cache set to be large. 8938032Speter 9038032Speter* Connection caching breaks if you pass the port number as an argument. 9138032Speter 9238032Speter If you have a definition such as: 9338032Speter 9438032Speter Mport, P=[IPC], F=kmDFMuX, S=11/31, R=21, 9538032Speter M=2100000, T=DNS/RFC822/SMTP, 9638032Speter A=IPC [127.0.0.1] $h 9738032Speter 9838032Speter (i.e., where $h is the port number instead of the host name) the 9938032Speter connection caching code will break because it won't notice that 10038032Speter two messages addressed to different ports should use different 10138032Speter connections. 10238032Speter 10338032Speter* ESMTP SIZE underestimates the size of a message 10438032Speter 10538032Speter Sendmail makes no allowance for headers that it adds, nor does it 10638032Speter account for the SMTP on-the-wire \r\n expansion. It probably doesn't 10738032Speter allow for 8->7 bit MIME conversions either. 10838032Speter 10938032Speter* Paths to programs being executed and the mode of program files are 11038032Speter not checked. Essentially, the RunProgramInUnsafeDirPath and 11138032Speter RunWritableProgram bits in the DontBlameSendmail option are always 11238032Speter set. This is not a problem if your system is well managed (that is, 11338032Speter if binaries and system directories are mode 755 instead of something 11438032Speter foolish like 777). 11538032Speter 11638032Speter* 8-bit data in GECOS field 11738032Speter 11838032Speter If the GECOS (personal name) information in the passwd file contains 11938032Speter 8-bit characters, those characters can be included in the message 12038032Speter header, which can cause problems when sending SMTP to hosts that 12138032Speter only accept 7-bit characters. 12238032Speter 12338032Speter* 8->7 bit MIME conversion 12438032Speter 12538032Speter When sendmail is doing 8->7 bit MIME conversions, and the message 12638032Speter contains certain MIME body types that cannot be converted to 7-bit, 12738032Speter sendmail will strip the message to 7-bit. 12838032Speter 12938032Speter* 7->8 bit MIME conversion 13038032Speter 13138032Speter If a message that is encoded as 7-bit MIME is converted to 8-bit and 13238032Speter that message when decoded is illegal (e.g., because of long lines or 13338032Speter illegal characters), sendmail can produce an illegal message. 13438032Speter 13538032Speter* MIME encoded full name phrases in the From: header 13638032Speter 13738032Speter If a full name phrase includes characters from MustQuoteChars, sendmail 13838032Speter will quote the entire full name phrase. If MustQuoteChars includes 13938032Speter characters which are not special characters according to STD 11 (RFC 14038032Speter 822), this quotation can interfere with MIME encoded full name phrases. 14138032Speter By default, sendmail includes the single quote character (') in 14238032Speter MustQuoteChars even though it is not listed as a special character in 14338032Speter STD 11. 14438032Speter 14542575Speter* bestmx map with -z flag truncates the list of MX hosts 14638032Speter 14742575Speter A bestmx map configured with the -z flag will truncate the list 14842575Speter of MX hosts. This prevents creation of strings which are too 14942575Speter long for ruleset parsing. This can have an adverse effect on the 15042575Speter relay_based_on_MX feature. 15142575Speter 15243730Speter* Saving to ~sender/dead.letter fails if su'ed to root 15342575Speter 15443730Speter If ErrorMode is set to print and an error in sending mail occurs, 15543730Speter the normal action is to print a message to the screen and append 15643730Speter the message to a dead.letter file in the sender's home directory. 15743730Speter In the case where the sender is using su to act as root, the file 15843730Speter safety checks prevent sendmail from saving the dead.letter file 15943730Speter because the sender's uid and the current real uid do not match. 16043730Speter 16143730Speter* Berkeley DB 2.X race condition with fcntl() locking 16243730Speter 16343730Speter There is a race condition for Berkeley DB 2.X databases on 16443730Speter operating systems which use fcntl() style locking, such as 16543730Speter Solaris. Sendmail locks the map before calling db_open() to 16643730Speter prevent others from modifying the map while it is being opened. 16743730Speter Unfortunately, Berkeley DB opens the map, closes it, and then 16843730Speter reopens it. fcntl() locking drops the lock when any file 16943730Speter descriptor pointing to the file is closed, even if it is a 17043730Speter different file descriptor than the one used to initially lock 17143730Speter the file. As a result there is a possibility that entries in a 17243730Speter map might not be found during a map rebuild. As a workaround, 17343730Speter you can use makemap to build a map with a new name and then 17443730Speter "mv" the new db file to replace the old one. 17543730Speter 17643730Speter* File open timeouts not available on hard mounted NFS file systems 17743730Speter 17843730Speter Since SIGALRM does not interrupt an RPC call for hard mounted 17943730Speter NFS file systems, it is impossible to implement a timeout on a file 18043730Speter open operation. Therefore, while the NFS server is not responding, 18143730Speter attempts to open a file on that server will hang. Systems with 18243730Speter local mail delivery and NFS hard mounted home directories should be 18343730Speter avoided, as attempts to open the forward files could hang. 18443730Speter 18543730Speter(Version 8.36, last updated 2/4/1999) 186