KNOWNBUGS revision 141858
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 44141858Sgshapiro* Header lines which are too long will be split incorrectly. 45141858Sgshapiro 46141858Sgshapiro Header lines which are longer than 2045 characters will be split 47141858Sgshapiro but some characters might be lost. Fix: obey RFC (2)822 and do not 48141858Sgshapiro send lines that are longer than 1000 characters. 49141858Sgshapiro 5094334Sgshapiro* Sender addresses whose domain part cause a temporary A record lookup 5194334Sgshapiro failure but have a valid MX record will be temporarily rejected in 5294334Sgshapiro the default configuration. Solution: fix the DNS at the sender side. 5394334Sgshapiro If that's not easy to achieve, possible workarounds are: 5494334Sgshapiro - add an entry to the access map: 5594334Sgshapiro dom.ain OK 5694334Sgshapiro - (only for advanced users) replace 5794334Sgshapiro 5894334Sgshapiro# Resolve map (to check if a host exists in check_mail) 5994334SgshapiroKresolve host -a<OKR> -T<TEMP> 6094334Sgshapiro 6194334Sgshapiro with 6294334Sgshapiro 6394334Sgshapiro# Resolve map (to check if a host exists in check_mail) 6494334SgshapiroKcanon host -a<OKR> -T<TEMP> 6594334SgshapiroKdnsmx dns -R MX -a<OKR> -T<TEMP> 6694334SgshapiroKresolve sequence dnsmx canon 6794334Sgshapiro 6894334Sgshapiro 6938032Speter* Duplicate error messages. 7038032Speter 7138032Speter Sometimes identical, duplicate error messages can be generated. As 7238032Speter near as I can tell, this is rare and relatively innocuous. 7338032Speter 7490792Sgshapiro* Misleading error messages. 7538032Speter 7690792Sgshapiro If an illegal address is specified on the command line together 7790792Sgshapiro with at least one valid address and PostmasterCopy is set, the 7890792Sgshapiro DSN does not contain the illegal address, but only the valid 7990792Sgshapiro address(es). 8038032Speter 8138032Speter* \231 considered harmful. 8238032Speter 8338032Speter Header addresses that have the \231 character (and possibly others 8438032Speter in the range \201 - \237) behave in odd and usually unexpected ways. 8538032Speter 8638032Speter* accept() problem on SVR4. 8738032Speter 8838032Speter Apparently, the sendmail daemon loop (doing accept()s on the network) 8938032Speter can get into a weird state on SVR4; it starts logging ``SYSERR: 9038032Speter getrequests: accept: Protocol Error''. The workaround is to kill 9138032Speter and restart the sendmail daemon. We don't have an SVR4 system at 9238032Speter Berkeley that carries more than token mail load, so I can't validate 9338032Speter this. It is likely to be a glitch in the sockets emulation, since 9438032Speter "Protocol Error" is not possible error code with Berkeley TCP/IP. 9538032Speter 9638032Speter I've also had someone report the message ``sendmail: accept: 9738032Speter SIOCGPGRP failed errno 22'' on an SVR4 system. This message is 9838032Speter not in the sendmail source code, so I assume it is also a bug 9938032Speter in the sockets emulation. (Errno 22 is EINVAL "Invalid Argument" 10038032Speter on all the systems I have available, including Solaris 2.x.) 10138032Speter Apparently, this problem is due to linking -lc before -lsocket; 10238032Speter if you are having this problem, check your Makefile. 10338032Speter 10438032Speter* accept() problem on Linux. 10538032Speter 10642575Speter The accept() in sendmail daemon loop can return ETIMEDOUT. An 10742575Speter error is reported to syslog: 10838032Speter 10938032Speter Jun 9 17:14:12 hostname sendmail[207]: NOQUEUE: SYSERR(root): 11038032Speter getrequests: accept: Connection timed out 11138032Speter 11238032Speter "Connection timed out" is not documented as a valid return from 11338032Speter accept(2) and this was believed to be a bug in the Linux kernel. 11438032Speter Later information from the Linux kernel group states that Linux 11538032Speter 2.0 kernels follow RFC1122 while sendmail follows the original BSD 11638032Speter (now POSIX 1003.1g draft) specification. The 2.1.X and later kernels 11738032Speter will follow the POSIX draft. 11838032Speter 11938032Speter* Excessive mailing list nesting can run out of file descriptors. 12038032Speter 12138032Speter If you have a mailing list that includes lots of other mailing 12238032Speter lists, each of which has a separate owner, you can run out of 12338032Speter file descriptors. Each mailing list with a separate owner uses 12438032Speter one open file descriptor (prior to 8.6.6 it was three open 12538032Speter file descriptors per list). This is particularly egregious if 12638032Speter you have your connection cache set to be large. 12738032Speter 12838032Speter* Connection caching breaks if you pass the port number as an argument. 12938032Speter 13038032Speter If you have a definition such as: 13138032Speter 13238032Speter Mport, P=[IPC], F=kmDFMuX, S=11/31, R=21, 13338032Speter M=2100000, T=DNS/RFC822/SMTP, 13438032Speter A=IPC [127.0.0.1] $h 13538032Speter 13638032Speter (i.e., where $h is the port number instead of the host name) the 13738032Speter connection caching code will break because it won't notice that 13838032Speter two messages addressed to different ports should use different 13938032Speter connections. 14038032Speter 14138032Speter* ESMTP SIZE underestimates the size of a message 14238032Speter 14338032Speter Sendmail makes no allowance for headers that it adds, nor does it 14438032Speter account for the SMTP on-the-wire \r\n expansion. It probably doesn't 14538032Speter allow for 8->7 bit MIME conversions either. 14638032Speter 14790792Sgshapiro* Client ignores SIZE parameter. 14890792Sgshapiro 14990792Sgshapiro When sendmail acts as client and the server specifies a limit 15090792Sgshapiro for the mail size, sendmail will ignore this and try to send the 15190792Sgshapiro mail anyway. The server will usually reject the MAIL command 15290792Sgshapiro which specifies the size of the message and hence this problem 15390792Sgshapiro is not significant. 15490792Sgshapiro 15538032Speter* Paths to programs being executed and the mode of program files are 15638032Speter not checked. Essentially, the RunProgramInUnsafeDirPath and 15738032Speter RunWritableProgram bits in the DontBlameSendmail option are always 15838032Speter set. This is not a problem if your system is well managed (that is, 15938032Speter if binaries and system directories are mode 755 instead of something 16038032Speter foolish like 777). 16138032Speter 16238032Speter* 8-bit data in GECOS field 16338032Speter 16438032Speter If the GECOS (personal name) information in the passwd file contains 16538032Speter 8-bit characters, those characters can be included in the message 16638032Speter header, which can cause problems when sending SMTP to hosts that 16738032Speter only accept 7-bit characters. 16838032Speter 16938032Speter* 8->7 bit MIME conversion 17038032Speter 17138032Speter When sendmail is doing 8->7 bit MIME conversions, and the message 17238032Speter contains certain MIME body types that cannot be converted to 7-bit, 17338032Speter sendmail will strip the message to 7-bit. 17438032Speter 17538032Speter* 7->8 bit MIME conversion 17638032Speter 17738032Speter If a message that is encoded as 7-bit MIME is converted to 8-bit and 17838032Speter that message when decoded is illegal (e.g., because of long lines or 17938032Speter illegal characters), sendmail can produce an illegal message. 18038032Speter 18138032Speter* MIME encoded full name phrases in the From: header 18238032Speter 18364562Sgshapiro If a full name phrase includes characters from MustQuoteChars, sendmail 18490792Sgshapiro will quote the entire full name phrase. If MustQuoteChars includes 18564562Sgshapiro characters which are not special characters according to STD 11 (RFC 18664562Sgshapiro 822), this quotation can interfere with MIME encoded full name phrases. 18738032Speter By default, sendmail includes the single quote character (') in 18838032Speter MustQuoteChars even though it is not listed as a special character in 18938032Speter STD 11. 19038032Speter 19142575Speter* bestmx map with -z flag truncates the list of MX hosts 19238032Speter 19342575Speter A bestmx map configured with the -z flag will truncate the list 19442575Speter of MX hosts. This prevents creation of strings which are too 19542575Speter long for ruleset parsing. This can have an adverse effect on the 19642575Speter relay_based_on_MX feature. 19742575Speter 19843730Speter* Saving to ~sender/dead.letter fails if su'ed to root 19942575Speter 20043730Speter If ErrorMode is set to print and an error in sending mail occurs, 20143730Speter the normal action is to print a message to the screen and append 20243730Speter the message to a dead.letter file in the sender's home directory. 20343730Speter In the case where the sender is using su to act as root, the file 20443730Speter safety checks prevent sendmail from saving the dead.letter file 20543730Speter because the sender's uid and the current real uid do not match. 20664562Sgshapiro 20743730Speter* Berkeley DB 2.X race condition with fcntl() locking 20843730Speter 20943730Speter There is a race condition for Berkeley DB 2.X databases on 21043730Speter operating systems which use fcntl() style locking, such as 21143730Speter Solaris. Sendmail locks the map before calling db_open() to 21243730Speter prevent others from modifying the map while it is being opened. 21343730Speter Unfortunately, Berkeley DB opens the map, closes it, and then 21443730Speter reopens it. fcntl() locking drops the lock when any file 21543730Speter descriptor pointing to the file is closed, even if it is a 21643730Speter different file descriptor than the one used to initially lock 21743730Speter the file. As a result there is a possibility that entries in a 21843730Speter map might not be found during a map rebuild. As a workaround, 21943730Speter you can use makemap to build a map with a new name and then 22043730Speter "mv" the new db file to replace the old one. 22143730Speter 22264562Sgshapiro Sleepycat Software has added code to avoid this race condition to 22364562Sgshapiro Berkeley DB versions after 2.7.5. 22464562Sgshapiro 22543730Speter* File open timeouts not available on hard mounted NFS file systems 22643730Speter 22743730Speter Since SIGALRM does not interrupt an RPC call for hard mounted 22843730Speter NFS file systems, it is impossible to implement a timeout on a file 22943730Speter open operation. Therefore, while the NFS server is not responding, 23043730Speter attempts to open a file on that server will hang. Systems with 23143730Speter local mail delivery and NFS hard mounted home directories should be 23243730Speter avoided, as attempts to open the forward files could hang. 23343730Speter 23490792Sgshapiro* Race condition for delivery to set-user-ID files 23564562Sgshapiro 23664562Sgshapiro Sendmail will deliver to a fail if the file is owned by the DefaultUser 23790792Sgshapiro or has the set-user-ID bit set. Unfortunately, some systems clear that bit 23864562Sgshapiro when a file is modified. Sendmail compensates by resetting the file mode 23964562Sgshapiro back to it's original settings. Unfortunately, there's still a 24064562Sgshapiro permission failure race as sendmail checks the permissions before locking 24164562Sgshapiro the file. This is unavoidable as sendmail must verify the file is safe 24264562Sgshapiro to open before opening it. A file can not be locked until it is open. 24364562Sgshapiro 244110560Sgshapiro* MAIL_HUB always takes precedence over LOCAL_RELAY 245110560Sgshapiro 246110560Sgshapiro Despite the information in the documentation, MAIL_HUB ($H) will always 247110560Sgshapiro be used if set instead of LOCAL_RELAY ($R). This will be fixed in a 248110560Sgshapiro future version. 249110560Sgshapiro 250141858Sgshapiro$Revision: 8.57 $, Last updated $Date: 2004/12/02 23:39:01 $ 251