KNOWNBUGS revision 110560
11590Srgrimes 21590Srgrimes 31590Srgrimes K N O W N B U G S I N S E N D M A I L 41590Srgrimes 51590Srgrimes 61590SrgrimesThe following are bugs or deficiencies in sendmail that we are aware of 71590Srgrimesbut which have not been fixed in the current release. You probably 81590Srgrimeswant to get the most up to date version of this from ftp.sendmail.org 91590Srgrimesin /pub/sendmail/KNOWNBUGS. For descriptions of bugs that have been 101590Srgrimesfixed, see the file RELEASE_NOTES (in the root directory of the sendmail 111590Srgrimesdistribution). 121590Srgrimes 131590SrgrimesThis list is not guaranteed to be complete. 141590Srgrimes 151590Srgrimes* Delivery to programs that generate too much output may cause problems 161590Srgrimes 171590Srgrimes If e-mail is delivered to a program which generates too much 181590Srgrimes output, then sendmail may issue an error: 191590Srgrimes 201590Srgrimes timeout waiting for input from local during Draining Input 211590Srgrimes 221590Srgrimes Make sure that the program does not generate output beyond a 231590Srgrimes status message (corresponding to the exit status). This may 241590Srgrimes require a wrapper around the actual program to redirect output 251590Srgrimes to /dev/null. 261590Srgrimes 271590Srgrimes Such a problem has been reported for bulk_mailer. 281590Srgrimes 291590Srgrimes* Null bytes are not handled properly in headers. 301590Srgrimes 311590Srgrimes Sendmail should handle full binary data. As it stands, it handles 321590Srgrimes all values in the body, but only 0x01-0x80 and 0xA0-0xFF in 331590Srgrimes the header. Notably missing is 0x00, which would require a major 341590Srgrimes restructuring of the code -- for example, almost no C library support 3574769Smikeh could be used to handle strings. 3688150Smikeh 3774769Smikeh* Header checks are not called if header value is too long or empty. 3874769Smikeh 3974769Smikeh If the value of a header is longer than 1250 (MAXNAME + MAXATOM - 6) 401590Srgrimes characters or it contains a single word longer than 256 (MAXNAME) 411590Srgrimes characters then no header check is done even if one is configured for 421590Srgrimes the header. 431590Srgrimes 441590Srgrimes* Sender addresses whose domain part cause a temporary A record lookup 451590Srgrimes failure but have a valid MX record will be temporarily rejected in 461590Srgrimes the default configuration. Solution: fix the DNS at the sender side. 471590Srgrimes If that's not easy to achieve, possible workarounds are: 481590Srgrimes - add an entry to the access map: 491590Srgrimes dom.ain OK 501590Srgrimes - (only for advanced users) replace 511590Srgrimes 521590Srgrimes# Resolve map (to check if a host exists in check_mail) 531590SrgrimesKresolve host -a<OKR> -T<TEMP> 541590Srgrimes 551590Srgrimes with 561590Srgrimes 5777274Smikeh# Resolve map (to check if a host exists in check_mail) 5877274SmikehKcanon host -a<OKR> -T<TEMP> 591590SrgrimesKdnsmx dns -R MX -a<OKR> -T<TEMP> 601590SrgrimesKresolve sequence dnsmx canon 611590Srgrimes 621590Srgrimes 6388150Smikeh* Duplicate error messages. 6477274Smikeh 6588150Smikeh Sometimes identical, duplicate error messages can be generated. As 661590Srgrimes near as I can tell, this is rare and relatively innocuous. 6777274Smikeh 6877274Smikeh* Misleading error messages. 691590Srgrimes 701590Srgrimes If an illegal address is specified on the command line together 711590Srgrimes with at least one valid address and PostmasterCopy is set, the 7274769Smikeh DSN does not contain the illegal address, but only the valid 7388150Smikeh address(es). 741590Srgrimes 751590Srgrimes* \231 considered harmful. 7674769Smikeh 7774769Smikeh Header addresses that have the \231 character (and possibly others 7874769Smikeh in the range \201 - \237) behave in odd and usually unexpected ways. 7977274Smikeh 801590Srgrimes* accept() problem on SVR4. 8188150Smikeh 8288150Smikeh Apparently, the sendmail daemon loop (doing accept()s on the network) 8388150Smikeh can get into a weird state on SVR4; it starts logging ``SYSERR: 8488150Smikeh getrequests: accept: Protocol Error''. The workaround is to kill 8588150Smikeh and restart the sendmail daemon. We don't have an SVR4 system at 8688150Smikeh Berkeley that carries more than token mail load, so I can't validate 8788150Smikeh this. It is likely to be a glitch in the sockets emulation, since 8888150Smikeh "Protocol Error" is not possible error code with Berkeley TCP/IP. 8988150Smikeh 9088150Smikeh I've also had someone report the message ``sendmail: accept: 9188150Smikeh SIOCGPGRP failed errno 22'' on an SVR4 system. This message is 9288150Smikeh not in the sendmail source code, so I assume it is also a bug 9388150Smikeh in the sockets emulation. (Errno 22 is EINVAL "Invalid Argument" 9488150Smikeh on all the systems I have available, including Solaris 2.x.) 9588150Smikeh Apparently, this problem is due to linking -lc before -lsocket; 961590Srgrimes if you are having this problem, check your Makefile. 971590Srgrimes 981590Srgrimes* accept() problem on Linux. 991590Srgrimes 1001590Srgrimes The accept() in sendmail daemon loop can return ETIMEDOUT. An 1011590Srgrimes error is reported to syslog: 1021590Srgrimes 1031590Srgrimes Jun 9 17:14:12 hostname sendmail[207]: NOQUEUE: SYSERR(root): 10474769Smikeh getrequests: accept: Connection timed out 10574769Smikeh 10674769Smikeh "Connection timed out" is not documented as a valid return from 10788150Smikeh accept(2) and this was believed to be a bug in the Linux kernel. 1081590Srgrimes Later information from the Linux kernel group states that Linux 1091590Srgrimes 2.0 kernels follow RFC1122 while sendmail follows the original BSD 1101590Srgrimes (now POSIX 1003.1g draft) specification. The 2.1.X and later kernels 11176455Smikeh will follow the POSIX draft. 11276455Smikeh 11376455Smikeh* Excessive mailing list nesting can run out of file descriptors. 11476455Smikeh 11576455Smikeh If you have a mailing list that includes lots of other mailing 11676455Smikeh lists, each of which has a separate owner, you can run out of 11776455Smikeh file descriptors. Each mailing list with a separate owner uses 11876455Smikeh one open file descriptor (prior to 8.6.6 it was three open 11976455Smikeh file descriptors per list). This is particularly egregious if 12076455Smikeh you have your connection cache set to be large. 12177274Smikeh 12274769Smikeh* Connection caching breaks if you pass the port number as an argument. 12374769Smikeh 12474769Smikeh If you have a definition such as: 12574769Smikeh 1261590Srgrimes Mport, P=[IPC], F=kmDFMuX, S=11/31, R=21, 1271590Srgrimes M=2100000, T=DNS/RFC822/SMTP, 12874769Smikeh A=IPC [127.0.0.1] $h 12974769Smikeh 1301590Srgrimes (i.e., where $h is the port number instead of the host name) the 1311590Srgrimes connection caching code will break because it won't notice that 1321590Srgrimes two messages addressed to different ports should use different 1331590Srgrimes connections. 13467496Sphk 1351590Srgrimes* ESMTP SIZE underestimates the size of a message 1361590Srgrimes 1371590Srgrimes Sendmail makes no allowance for headers that it adds, nor does it 1381590Srgrimes account for the SMTP on-the-wire \r\n expansion. It probably doesn't 1391590Srgrimes allow for 8->7 bit MIME conversions either. 14077274Smikeh 1411590Srgrimes* Client ignores SIZE parameter. 1421590Srgrimes 1431590Srgrimes When sendmail acts as client and the server specifies a limit 1441590Srgrimes for the mail size, sendmail will ignore this and try to send the 14577274Smikeh mail anyway. The server will usually reject the MAIL command 1461590Srgrimes which specifies the size of the message and hence this problem 1471590Srgrimes is not significant. 1481590Srgrimes 1491590Srgrimes* Paths to programs being executed and the mode of program files are 1501590Srgrimes not checked. Essentially, the RunProgramInUnsafeDirPath and 1511590Srgrimes RunWritableProgram bits in the DontBlameSendmail option are always 1521590Srgrimes set. This is not a problem if your system is well managed (that is, 1531590Srgrimes if binaries and system directories are mode 755 instead of something 1541590Srgrimes foolish like 777). 1551590Srgrimes 1561590Srgrimes* 8-bit data in GECOS field 1571590Srgrimes 1581590Srgrimes If the GECOS (personal name) information in the passwd file contains 1591590Srgrimes 8-bit characters, those characters can be included in the message 1601590Srgrimes header, which can cause problems when sending SMTP to hosts that 1611590Srgrimes only accept 7-bit characters. 1621590Srgrimes 1631590Srgrimes* 8->7 bit MIME conversion 1641590Srgrimes 1651590Srgrimes When sendmail is doing 8->7 bit MIME conversions, and the message 1661590Srgrimes contains certain MIME body types that cannot be converted to 7-bit, 16788150Smikeh sendmail will strip the message to 7-bit. 1681590Srgrimes 1691590Srgrimes* 7->8 bit MIME conversion 17088150Smikeh 1711590Srgrimes If a message that is encoded as 7-bit MIME is converted to 8-bit and 1721590Srgrimes that message when decoded is illegal (e.g., because of long lines or 17388150Smikeh illegal characters), sendmail can produce an illegal message. 1741590Srgrimes 17577274Smikeh* MIME encoded full name phrases in the From: header 1761590Srgrimes 1771590Srgrimes If a full name phrase includes characters from MustQuoteChars, sendmail 17877274Smikeh will quote the entire full name phrase. If MustQuoteChars includes 17988150Smikeh characters which are not special characters according to STD 11 (RFC 18088150Smikeh 822), this quotation can interfere with MIME encoded full name phrases. 18188150Smikeh By default, sendmail includes the single quote character (') in 18288150Smikeh MustQuoteChars even though it is not listed as a special character in 1831590Srgrimes STD 11. 1841590Srgrimes 18588150Smikeh* bestmx map with -z flag truncates the list of MX hosts 1861590Srgrimes 1871590Srgrimes A bestmx map configured with the -z flag will truncate the list 1881590Srgrimes of MX hosts. This prevents creation of strings which are too 1891590Srgrimes long for ruleset parsing. This can have an adverse effect on the 1901590Srgrimes relay_based_on_MX feature. 19176455Smikeh 1921590Srgrimes* Saving to ~sender/dead.letter fails if su'ed to root 1931590Srgrimes 1941590Srgrimes If ErrorMode is set to print and an error in sending mail occurs, 1951590Srgrimes the normal action is to print a message to the screen and append 1961590Srgrimes the message to a dead.letter file in the sender's home directory. 1971590Srgrimes In the case where the sender is using su to act as root, the file 1981590Srgrimes safety checks prevent sendmail from saving the dead.letter file 19977274Smikeh because the sender's uid and the current real uid do not match. 2001590Srgrimes 2011590Srgrimes* Berkeley DB 2.X race condition with fcntl() locking 2021590Srgrimes 20377274Smikeh There is a race condition for Berkeley DB 2.X databases on 2041590Srgrimes operating systems which use fcntl() style locking, such as 2051590Srgrimes Solaris. Sendmail locks the map before calling db_open() to 2061590Srgrimes prevent others from modifying the map while it is being opened. 20776455Smikeh Unfortunately, Berkeley DB opens the map, closes it, and then 20876455Smikeh reopens it. fcntl() locking drops the lock when any file 20977274Smikeh descriptor pointing to the file is closed, even if it is a 2101590Srgrimes different file descriptor than the one used to initially lock 2111590Srgrimes the file. As a result there is a possibility that entries in a 2121590Srgrimes map might not be found during a map rebuild. As a workaround, 2131590Srgrimes you can use makemap to build a map with a new name and then 2141590Srgrimes "mv" the new db file to replace the old one. 2151590Srgrimes 2161590Srgrimes Sleepycat Software has added code to avoid this race condition to 2171590Srgrimes Berkeley DB versions after 2.7.5. 21877274Smikeh 2191590Srgrimes* File open timeouts not available on hard mounted NFS file systems 2201590Srgrimes 22177274Smikeh Since SIGALRM does not interrupt an RPC call for hard mounted 22282793Sache NFS file systems, it is impossible to implement a timeout on a file 22382793Sache open operation. Therefore, while the NFS server is not responding, 22474769Smikeh attempts to open a file on that server will hang. Systems with 2251590Srgrimes local mail delivery and NFS hard mounted home directories should be 2261590Srgrimes avoided, as attempts to open the forward files could hang. 2271590Srgrimes 2281590Srgrimes* Race condition for delivery to set-user-ID files 2291590Srgrimes 2301590Srgrimes Sendmail will deliver to a fail if the file is owned by the DefaultUser 2311590Srgrimes or has the set-user-ID bit set. Unfortunately, some systems clear that bit 2321590Srgrimes when a file is modified. Sendmail compensates by resetting the file mode 23388150Smikeh back to it's original settings. Unfortunately, there's still a 2341590Srgrimes permission failure race as sendmail checks the permissions before locking 23588150Smikeh the file. This is unavoidable as sendmail must verify the file is safe 2361590Srgrimes to open before opening it. A file can not be locked until it is open. 23788150Smikeh 23888150Smikeh* MAIL_HUB always takes precedence over LOCAL_RELAY 2391590Srgrimes 24088150Smikeh Despite the information in the documentation, MAIL_HUB ($H) will always 24188150Smikeh be used if set instead of LOCAL_RELAY ($R). This will be fixed in a 24288150Smikeh future version. 24388150Smikeh 24488150Smikeh$Revision: 8.55.2.1 $, Last updated $Date: 2002/12/18 22:38:48 $ 24588150Smikeh