KNOWNBUGS revision 90792
138032Speter 238032Speter 338032Speter K N O W N B U G S I N S E N D M A I L 438032Speter 538032Speter 690792SgshapiroThe following are bugs or deficiencies in sendmail that we are aware of 738032Speterbut which have not been fixed in the current release. You probably 864562Sgshapirowant to get the most up to date version of this from ftp.sendmail.org 938032Speterin /pub/sendmail/KNOWNBUGS. For descriptions of bugs that have been 1038032Speterfixed, see the file RELEASE_NOTES (in the root directory of the sendmail 1138032Speterdistribution). 1238032Speter 1338032SpeterThis list is not guaranteed to be complete. 1438032Speter 1566494Sgshapiro* Delivery to programs that generate too much output may cause problems 1638032Speter 1766494Sgshapiro If e-mail is delivered to a program which generates too much 1866494Sgshapiro output, then sendmail may issue an error: 1966494Sgshapiro 2066494Sgshapiro timeout waiting for input from local during Draining Input 2166494Sgshapiro 2266494Sgshapiro Make sure that the program does not generate output beyond a 2366494Sgshapiro status message (corresponding to the exit status). This may 2466494Sgshapiro require a wrapper around the actual program to redirect output 2566494Sgshapiro to /dev/null. 2666494Sgshapiro 2766494Sgshapiro Such a problem has been reported for bulk_mailer. 2866494Sgshapiro 2938032Speter* Null bytes are not handled properly in headers. 3038032Speter 3138032Speter Sendmail should handle full binary data. As it stands, it handles 3238032Speter all values in the body, but only 0x01-0x80 and 0xA0-0xFF in 3338032Speter the header. Notably missing is 0x00, which would require a major 3438032Speter restructuring of the code -- for example, almost no C library support 3538032Speter could be used to handle strings. 3638032Speter 3790792Sgshapiro* Header checks are not called if header value is too long or empty. 3880785Sgshapiro 3980785Sgshapiro If the value of a header is longer than 1250 (MAXNAME + MAXATOM - 6) 4080785Sgshapiro characters or it contains a single word longer than 256 (MAXNAME) 4180785Sgshapiro characters then no header check is done even if one is configured for 4280785Sgshapiro the header. 4380785Sgshapiro 4438032Speter* Duplicate error messages. 4538032Speter 4638032Speter Sometimes identical, duplicate error messages can be generated. As 4738032Speter near as I can tell, this is rare and relatively innocuous. 4838032Speter 4990792Sgshapiro* Misleading error messages. 5038032Speter 5190792Sgshapiro If an illegal address is specified on the command line together 5290792Sgshapiro with at least one valid address and PostmasterCopy is set, the 5390792Sgshapiro DSN does not contain the illegal address, but only the valid 5490792Sgshapiro address(es). 5538032Speter 5638032Speter* \231 considered harmful. 5738032Speter 5838032Speter Header addresses that have the \231 character (and possibly others 5938032Speter in the range \201 - \237) behave in odd and usually unexpected ways. 6038032Speter 6138032Speter* accept() problem on SVR4. 6238032Speter 6338032Speter Apparently, the sendmail daemon loop (doing accept()s on the network) 6438032Speter can get into a weird state on SVR4; it starts logging ``SYSERR: 6538032Speter getrequests: accept: Protocol Error''. The workaround is to kill 6638032Speter and restart the sendmail daemon. We don't have an SVR4 system at 6738032Speter Berkeley that carries more than token mail load, so I can't validate 6838032Speter this. It is likely to be a glitch in the sockets emulation, since 6938032Speter "Protocol Error" is not possible error code with Berkeley TCP/IP. 7038032Speter 7138032Speter I've also had someone report the message ``sendmail: accept: 7238032Speter SIOCGPGRP failed errno 22'' on an SVR4 system. This message is 7338032Speter not in the sendmail source code, so I assume it is also a bug 7438032Speter in the sockets emulation. (Errno 22 is EINVAL "Invalid Argument" 7538032Speter on all the systems I have available, including Solaris 2.x.) 7638032Speter Apparently, this problem is due to linking -lc before -lsocket; 7738032Speter if you are having this problem, check your Makefile. 7838032Speter 7938032Speter* accept() problem on Linux. 8038032Speter 8142575Speter The accept() in sendmail daemon loop can return ETIMEDOUT. An 8242575Speter error is reported to syslog: 8338032Speter 8438032Speter Jun 9 17:14:12 hostname sendmail[207]: NOQUEUE: SYSERR(root): 8538032Speter getrequests: accept: Connection timed out 8638032Speter 8738032Speter "Connection timed out" is not documented as a valid return from 8838032Speter accept(2) and this was believed to be a bug in the Linux kernel. 8938032Speter Later information from the Linux kernel group states that Linux 9038032Speter 2.0 kernels follow RFC1122 while sendmail follows the original BSD 9138032Speter (now POSIX 1003.1g draft) specification. The 2.1.X and later kernels 9238032Speter will follow the POSIX draft. 9338032Speter 9438032Speter* Excessive mailing list nesting can run out of file descriptors. 9538032Speter 9638032Speter If you have a mailing list that includes lots of other mailing 9738032Speter lists, each of which has a separate owner, you can run out of 9838032Speter file descriptors. Each mailing list with a separate owner uses 9938032Speter one open file descriptor (prior to 8.6.6 it was three open 10038032Speter file descriptors per list). This is particularly egregious if 10138032Speter you have your connection cache set to be large. 10238032Speter 10338032Speter* Connection caching breaks if you pass the port number as an argument. 10438032Speter 10538032Speter If you have a definition such as: 10638032Speter 10738032Speter Mport, P=[IPC], F=kmDFMuX, S=11/31, R=21, 10838032Speter M=2100000, T=DNS/RFC822/SMTP, 10938032Speter A=IPC [127.0.0.1] $h 11038032Speter 11138032Speter (i.e., where $h is the port number instead of the host name) the 11238032Speter connection caching code will break because it won't notice that 11338032Speter two messages addressed to different ports should use different 11438032Speter connections. 11538032Speter 11638032Speter* ESMTP SIZE underestimates the size of a message 11738032Speter 11838032Speter Sendmail makes no allowance for headers that it adds, nor does it 11938032Speter account for the SMTP on-the-wire \r\n expansion. It probably doesn't 12038032Speter allow for 8->7 bit MIME conversions either. 12138032Speter 12290792Sgshapiro* Client ignores SIZE parameter. 12390792Sgshapiro 12490792Sgshapiro When sendmail acts as client and the server specifies a limit 12590792Sgshapiro for the mail size, sendmail will ignore this and try to send the 12690792Sgshapiro mail anyway. The server will usually reject the MAIL command 12790792Sgshapiro which specifies the size of the message and hence this problem 12890792Sgshapiro is not significant. 12990792Sgshapiro 13038032Speter* Paths to programs being executed and the mode of program files are 13138032Speter not checked. Essentially, the RunProgramInUnsafeDirPath and 13238032Speter RunWritableProgram bits in the DontBlameSendmail option are always 13338032Speter set. This is not a problem if your system is well managed (that is, 13438032Speter if binaries and system directories are mode 755 instead of something 13538032Speter foolish like 777). 13638032Speter 13738032Speter* 8-bit data in GECOS field 13838032Speter 13938032Speter If the GECOS (personal name) information in the passwd file contains 14038032Speter 8-bit characters, those characters can be included in the message 14138032Speter header, which can cause problems when sending SMTP to hosts that 14238032Speter only accept 7-bit characters. 14338032Speter 14438032Speter* 8->7 bit MIME conversion 14538032Speter 14638032Speter When sendmail is doing 8->7 bit MIME conversions, and the message 14738032Speter contains certain MIME body types that cannot be converted to 7-bit, 14838032Speter sendmail will strip the message to 7-bit. 14938032Speter 15038032Speter* 7->8 bit MIME conversion 15138032Speter 15238032Speter If a message that is encoded as 7-bit MIME is converted to 8-bit and 15338032Speter that message when decoded is illegal (e.g., because of long lines or 15438032Speter illegal characters), sendmail can produce an illegal message. 15538032Speter 15638032Speter* MIME encoded full name phrases in the From: header 15738032Speter 15864562Sgshapiro If a full name phrase includes characters from MustQuoteChars, sendmail 15990792Sgshapiro will quote the entire full name phrase. If MustQuoteChars includes 16064562Sgshapiro characters which are not special characters according to STD 11 (RFC 16164562Sgshapiro 822), this quotation can interfere with MIME encoded full name phrases. 16238032Speter By default, sendmail includes the single quote character (') in 16338032Speter MustQuoteChars even though it is not listed as a special character in 16438032Speter STD 11. 16538032Speter 16642575Speter* bestmx map with -z flag truncates the list of MX hosts 16738032Speter 16842575Speter A bestmx map configured with the -z flag will truncate the list 16942575Speter of MX hosts. This prevents creation of strings which are too 17042575Speter long for ruleset parsing. This can have an adverse effect on the 17142575Speter relay_based_on_MX feature. 17242575Speter 17343730Speter* Saving to ~sender/dead.letter fails if su'ed to root 17442575Speter 17543730Speter If ErrorMode is set to print and an error in sending mail occurs, 17643730Speter the normal action is to print a message to the screen and append 17743730Speter the message to a dead.letter file in the sender's home directory. 17843730Speter In the case where the sender is using su to act as root, the file 17943730Speter safety checks prevent sendmail from saving the dead.letter file 18043730Speter because the sender's uid and the current real uid do not match. 18164562Sgshapiro 18243730Speter* Berkeley DB 2.X race condition with fcntl() locking 18343730Speter 18443730Speter There is a race condition for Berkeley DB 2.X databases on 18543730Speter operating systems which use fcntl() style locking, such as 18643730Speter Solaris. Sendmail locks the map before calling db_open() to 18743730Speter prevent others from modifying the map while it is being opened. 18843730Speter Unfortunately, Berkeley DB opens the map, closes it, and then 18943730Speter reopens it. fcntl() locking drops the lock when any file 19043730Speter descriptor pointing to the file is closed, even if it is a 19143730Speter different file descriptor than the one used to initially lock 19243730Speter the file. As a result there is a possibility that entries in a 19343730Speter map might not be found during a map rebuild. As a workaround, 19443730Speter you can use makemap to build a map with a new name and then 19543730Speter "mv" the new db file to replace the old one. 19643730Speter 19764562Sgshapiro Sleepycat Software has added code to avoid this race condition to 19864562Sgshapiro Berkeley DB versions after 2.7.5. 19964562Sgshapiro 20043730Speter* File open timeouts not available on hard mounted NFS file systems 20143730Speter 20243730Speter Since SIGALRM does not interrupt an RPC call for hard mounted 20343730Speter NFS file systems, it is impossible to implement a timeout on a file 20443730Speter open operation. Therefore, while the NFS server is not responding, 20543730Speter attempts to open a file on that server will hang. Systems with 20643730Speter local mail delivery and NFS hard mounted home directories should be 20743730Speter avoided, as attempts to open the forward files could hang. 20843730Speter 20990792Sgshapiro* Race condition for delivery to set-user-ID files 21064562Sgshapiro 21164562Sgshapiro Sendmail will deliver to a fail if the file is owned by the DefaultUser 21290792Sgshapiro or has the set-user-ID bit set. Unfortunately, some systems clear that bit 21364562Sgshapiro when a file is modified. Sendmail compensates by resetting the file mode 21464562Sgshapiro back to it's original settings. Unfortunately, there's still a 21564562Sgshapiro permission failure race as sendmail checks the permissions before locking 21664562Sgshapiro the file. This is unavoidable as sendmail must verify the file is safe 21764562Sgshapiro to open before opening it. A file can not be locked until it is open. 21864562Sgshapiro 21990792Sgshapiro$Revision: 8.54 $, Last updated $Date: 2001/12/17 16:07:51 $ 220