KNOWNBUGS revision 94334
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 4494334Sgshapiro* Sender addresses whose domain part cause a temporary A record lookup 4594334Sgshapiro failure but have a valid MX record will be temporarily rejected in 4694334Sgshapiro the default configuration. Solution: fix the DNS at the sender side. 4794334Sgshapiro If that's not easy to achieve, possible workarounds are: 4894334Sgshapiro - add an entry to the access map: 4994334Sgshapiro dom.ain OK 5094334Sgshapiro - (only for advanced users) replace 5194334Sgshapiro 5294334Sgshapiro# Resolve map (to check if a host exists in check_mail) 5394334SgshapiroKresolve host -a<OKR> -T<TEMP> 5494334Sgshapiro 5594334Sgshapiro with 5694334Sgshapiro 5794334Sgshapiro# Resolve map (to check if a host exists in check_mail) 5894334SgshapiroKcanon host -a<OKR> -T<TEMP> 5994334SgshapiroKdnsmx dns -R MX -a<OKR> -T<TEMP> 6094334SgshapiroKresolve sequence dnsmx canon 6194334Sgshapiro 6294334Sgshapiro 6338032Speter* Duplicate error messages. 6438032Speter 6538032Speter Sometimes identical, duplicate error messages can be generated. As 6638032Speter near as I can tell, this is rare and relatively innocuous. 6738032Speter 6890792Sgshapiro* Misleading error messages. 6938032Speter 7090792Sgshapiro If an illegal address is specified on the command line together 7190792Sgshapiro with at least one valid address and PostmasterCopy is set, the 7290792Sgshapiro DSN does not contain the illegal address, but only the valid 7390792Sgshapiro address(es). 7438032Speter 7538032Speter* \231 considered harmful. 7638032Speter 7738032Speter Header addresses that have the \231 character (and possibly others 7838032Speter in the range \201 - \237) behave in odd and usually unexpected ways. 7938032Speter 8038032Speter* accept() problem on SVR4. 8138032Speter 8238032Speter Apparently, the sendmail daemon loop (doing accept()s on the network) 8338032Speter can get into a weird state on SVR4; it starts logging ``SYSERR: 8438032Speter getrequests: accept: Protocol Error''. The workaround is to kill 8538032Speter and restart the sendmail daemon. We don't have an SVR4 system at 8638032Speter Berkeley that carries more than token mail load, so I can't validate 8738032Speter this. It is likely to be a glitch in the sockets emulation, since 8838032Speter "Protocol Error" is not possible error code with Berkeley TCP/IP. 8938032Speter 9038032Speter I've also had someone report the message ``sendmail: accept: 9138032Speter SIOCGPGRP failed errno 22'' on an SVR4 system. This message is 9238032Speter not in the sendmail source code, so I assume it is also a bug 9338032Speter in the sockets emulation. (Errno 22 is EINVAL "Invalid Argument" 9438032Speter on all the systems I have available, including Solaris 2.x.) 9538032Speter Apparently, this problem is due to linking -lc before -lsocket; 9638032Speter if you are having this problem, check your Makefile. 9738032Speter 9838032Speter* accept() problem on Linux. 9938032Speter 10042575Speter The accept() in sendmail daemon loop can return ETIMEDOUT. An 10142575Speter error is reported to syslog: 10238032Speter 10338032Speter Jun 9 17:14:12 hostname sendmail[207]: NOQUEUE: SYSERR(root): 10438032Speter getrequests: accept: Connection timed out 10538032Speter 10638032Speter "Connection timed out" is not documented as a valid return from 10738032Speter accept(2) and this was believed to be a bug in the Linux kernel. 10838032Speter Later information from the Linux kernel group states that Linux 10938032Speter 2.0 kernels follow RFC1122 while sendmail follows the original BSD 11038032Speter (now POSIX 1003.1g draft) specification. The 2.1.X and later kernels 11138032Speter will follow the POSIX draft. 11238032Speter 11338032Speter* Excessive mailing list nesting can run out of file descriptors. 11438032Speter 11538032Speter If you have a mailing list that includes lots of other mailing 11638032Speter lists, each of which has a separate owner, you can run out of 11738032Speter file descriptors. Each mailing list with a separate owner uses 11838032Speter one open file descriptor (prior to 8.6.6 it was three open 11938032Speter file descriptors per list). This is particularly egregious if 12038032Speter you have your connection cache set to be large. 12138032Speter 12238032Speter* Connection caching breaks if you pass the port number as an argument. 12338032Speter 12438032Speter If you have a definition such as: 12538032Speter 12638032Speter Mport, P=[IPC], F=kmDFMuX, S=11/31, R=21, 12738032Speter M=2100000, T=DNS/RFC822/SMTP, 12838032Speter A=IPC [127.0.0.1] $h 12938032Speter 13038032Speter (i.e., where $h is the port number instead of the host name) the 13138032Speter connection caching code will break because it won't notice that 13238032Speter two messages addressed to different ports should use different 13338032Speter connections. 13438032Speter 13538032Speter* ESMTP SIZE underestimates the size of a message 13638032Speter 13738032Speter Sendmail makes no allowance for headers that it adds, nor does it 13838032Speter account for the SMTP on-the-wire \r\n expansion. It probably doesn't 13938032Speter allow for 8->7 bit MIME conversions either. 14038032Speter 14190792Sgshapiro* Client ignores SIZE parameter. 14290792Sgshapiro 14390792Sgshapiro When sendmail acts as client and the server specifies a limit 14490792Sgshapiro for the mail size, sendmail will ignore this and try to send the 14590792Sgshapiro mail anyway. The server will usually reject the MAIL command 14690792Sgshapiro which specifies the size of the message and hence this problem 14790792Sgshapiro is not significant. 14890792Sgshapiro 14938032Speter* Paths to programs being executed and the mode of program files are 15038032Speter not checked. Essentially, the RunProgramInUnsafeDirPath and 15138032Speter RunWritableProgram bits in the DontBlameSendmail option are always 15238032Speter set. This is not a problem if your system is well managed (that is, 15338032Speter if binaries and system directories are mode 755 instead of something 15438032Speter foolish like 777). 15538032Speter 15638032Speter* 8-bit data in GECOS field 15738032Speter 15838032Speter If the GECOS (personal name) information in the passwd file contains 15938032Speter 8-bit characters, those characters can be included in the message 16038032Speter header, which can cause problems when sending SMTP to hosts that 16138032Speter only accept 7-bit characters. 16238032Speter 16338032Speter* 8->7 bit MIME conversion 16438032Speter 16538032Speter When sendmail is doing 8->7 bit MIME conversions, and the message 16638032Speter contains certain MIME body types that cannot be converted to 7-bit, 16738032Speter sendmail will strip the message to 7-bit. 16838032Speter 16938032Speter* 7->8 bit MIME conversion 17038032Speter 17138032Speter If a message that is encoded as 7-bit MIME is converted to 8-bit and 17238032Speter that message when decoded is illegal (e.g., because of long lines or 17338032Speter illegal characters), sendmail can produce an illegal message. 17438032Speter 17538032Speter* MIME encoded full name phrases in the From: header 17638032Speter 17764562Sgshapiro If a full name phrase includes characters from MustQuoteChars, sendmail 17890792Sgshapiro will quote the entire full name phrase. If MustQuoteChars includes 17964562Sgshapiro characters which are not special characters according to STD 11 (RFC 18064562Sgshapiro 822), this quotation can interfere with MIME encoded full name phrases. 18138032Speter By default, sendmail includes the single quote character (') in 18238032Speter MustQuoteChars even though it is not listed as a special character in 18338032Speter STD 11. 18438032Speter 18542575Speter* bestmx map with -z flag truncates the list of MX hosts 18638032Speter 18742575Speter A bestmx map configured with the -z flag will truncate the list 18842575Speter of MX hosts. This prevents creation of strings which are too 18942575Speter long for ruleset parsing. This can have an adverse effect on the 19042575Speter relay_based_on_MX feature. 19142575Speter 19243730Speter* Saving to ~sender/dead.letter fails if su'ed to root 19342575Speter 19443730Speter If ErrorMode is set to print and an error in sending mail occurs, 19543730Speter the normal action is to print a message to the screen and append 19643730Speter the message to a dead.letter file in the sender's home directory. 19743730Speter In the case where the sender is using su to act as root, the file 19843730Speter safety checks prevent sendmail from saving the dead.letter file 19943730Speter because the sender's uid and the current real uid do not match. 20064562Sgshapiro 20143730Speter* Berkeley DB 2.X race condition with fcntl() locking 20243730Speter 20343730Speter There is a race condition for Berkeley DB 2.X databases on 20443730Speter operating systems which use fcntl() style locking, such as 20543730Speter Solaris. Sendmail locks the map before calling db_open() to 20643730Speter prevent others from modifying the map while it is being opened. 20743730Speter Unfortunately, Berkeley DB opens the map, closes it, and then 20843730Speter reopens it. fcntl() locking drops the lock when any file 20943730Speter descriptor pointing to the file is closed, even if it is a 21043730Speter different file descriptor than the one used to initially lock 21143730Speter the file. As a result there is a possibility that entries in a 21243730Speter map might not be found during a map rebuild. As a workaround, 21343730Speter you can use makemap to build a map with a new name and then 21443730Speter "mv" the new db file to replace the old one. 21543730Speter 21664562Sgshapiro Sleepycat Software has added code to avoid this race condition to 21764562Sgshapiro Berkeley DB versions after 2.7.5. 21864562Sgshapiro 21943730Speter* File open timeouts not available on hard mounted NFS file systems 22043730Speter 22143730Speter Since SIGALRM does not interrupt an RPC call for hard mounted 22243730Speter NFS file systems, it is impossible to implement a timeout on a file 22343730Speter open operation. Therefore, while the NFS server is not responding, 22443730Speter attempts to open a file on that server will hang. Systems with 22543730Speter local mail delivery and NFS hard mounted home directories should be 22643730Speter avoided, as attempts to open the forward files could hang. 22743730Speter 22890792Sgshapiro* Race condition for delivery to set-user-ID files 22964562Sgshapiro 23064562Sgshapiro Sendmail will deliver to a fail if the file is owned by the DefaultUser 23190792Sgshapiro or has the set-user-ID bit set. Unfortunately, some systems clear that bit 23264562Sgshapiro when a file is modified. Sendmail compensates by resetting the file mode 23364562Sgshapiro back to it's original settings. Unfortunately, there's still a 23464562Sgshapiro permission failure race as sendmail checks the permissions before locking 23564562Sgshapiro the file. This is unavoidable as sendmail must verify the file is safe 23664562Sgshapiro to open before opening it. A file can not be locked until it is open. 23764562Sgshapiro 23894334Sgshapiro$Revision: 8.55 $, Last updated $Date: 2002/03/05 00:45:54 $ 239