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 15223067Sgshapiro* Header values which are too long may be truncated. 16223067Sgshapiro 17223067Sgshapiro If a value of a structured header is longer than 256 (MAXNAME) 18223067Sgshapiro characters then it may be truncated during output. For example, 19223067Sgshapiro if a single address in the To: header is longer than 256 characters 20223067Sgshapiro then it will be truncated which may result in a syntactically 21223067Sgshapiro invalid address. 22223067Sgshapiro 2366494Sgshapiro* Delivery to programs that generate too much output may cause problems 2438032Speter 2566494Sgshapiro If e-mail is delivered to a program which generates too much 2666494Sgshapiro output, then sendmail may issue an error: 2766494Sgshapiro 2866494Sgshapiro timeout waiting for input from local during Draining Input 2966494Sgshapiro 3066494Sgshapiro Make sure that the program does not generate output beyond a 3166494Sgshapiro status message (corresponding to the exit status). This may 3266494Sgshapiro require a wrapper around the actual program to redirect output 3366494Sgshapiro to /dev/null. 3466494Sgshapiro 3566494Sgshapiro Such a problem has been reported for bulk_mailer. 3666494Sgshapiro 3738032Speter* Null bytes are not handled properly in headers. 3838032Speter 3938032Speter Sendmail should handle full binary data. As it stands, it handles 40168515Sgshapiro all values in the body, but not 0x00 in the header. Changing 41168515Sgshapiro this would require a major restructuring of the code -- for 42168515Sgshapiro example, almost no C library support could be used to handle 43168515Sgshapiro strings. 4438032Speter 4590792Sgshapiro* Header checks are not called if header value is too long or empty. 4680785Sgshapiro 4780785Sgshapiro If the value of a header is longer than 1250 (MAXNAME + MAXATOM - 6) 4880785Sgshapiro characters or it contains a single word longer than 256 (MAXNAME) 4980785Sgshapiro characters then no header check is done even if one is configured for 5080785Sgshapiro the header. 5180785Sgshapiro 52141858Sgshapiro* Header lines which are too long will be split incorrectly. 53141858Sgshapiro 54141858Sgshapiro Header lines which are longer than 2045 characters will be split 55141858Sgshapiro but some characters might be lost. Fix: obey RFC (2)822 and do not 56141858Sgshapiro send lines that are longer than 1000 characters. 57141858Sgshapiro 58182352Sgshapiro* milter communication fails if a single header is larger than 64K. 59182352Sgshapiro 60182352Sgshapiro If a single header is larger than 64KB (which is not possible in the 61182352Sgshapiro default configuration) then it cannot be transferred in one block to 62182352Sgshapiro libmilter and hence the communication fails. This can be avoided by 63182352Sgshapiro increasing the constant MILTER_CHUNK_SIZE in 64182352Sgshapiro include/libmilter/mfdef.h and recompiling sendmail, libmilter, and 65182352Sgshapiro all (statically linked) milters (or by using an undocumented compile 66182352Sgshapiro time option: _FFR_MAXDATASIZE; you have to read the source code in 67182352Sgshapiro order to use this properly). 68182352Sgshapiro 6994334Sgshapiro* Sender addresses whose domain part cause a temporary A record lookup 7094334Sgshapiro failure but have a valid MX record will be temporarily rejected in 7194334Sgshapiro the default configuration. Solution: fix the DNS at the sender side. 7294334Sgshapiro If that's not easy to achieve, possible workarounds are: 7394334Sgshapiro - add an entry to the access map: 7494334Sgshapiro dom.ain OK 7594334Sgshapiro - (only for advanced users) replace 7694334Sgshapiro 7794334Sgshapiro# Resolve map (to check if a host exists in check_mail) 7894334SgshapiroKresolve host -a<OKR> -T<TEMP> 7994334Sgshapiro 8094334Sgshapiro with 8194334Sgshapiro 8294334Sgshapiro# Resolve map (to check if a host exists in check_mail) 8394334SgshapiroKcanon host -a<OKR> -T<TEMP> 8494334SgshapiroKdnsmx dns -R MX -a<OKR> -T<TEMP> 8594334SgshapiroKresolve sequence dnsmx canon 8694334Sgshapiro 8794334Sgshapiro 8838032Speter* Duplicate error messages. 8938032Speter 9038032Speter Sometimes identical, duplicate error messages can be generated. As 9138032Speter near as I can tell, this is rare and relatively innocuous. 9238032Speter 9390792Sgshapiro* Misleading error messages. 9438032Speter 9590792Sgshapiro If an illegal address is specified on the command line together 9690792Sgshapiro with at least one valid address and PostmasterCopy is set, the 9790792Sgshapiro DSN does not contain the illegal address, but only the valid 9890792Sgshapiro address(es). 9938032Speter 10038032Speter* \231 considered harmful. 10138032Speter 10238032Speter Header addresses that have the \231 character (and possibly others 10338032Speter in the range \201 - \237) behave in odd and usually unexpected ways. 10438032Speter 10538032Speter* accept() problem on SVR4. 10638032Speter 10738032Speter Apparently, the sendmail daemon loop (doing accept()s on the network) 10838032Speter can get into a weird state on SVR4; it starts logging ``SYSERR: 10938032Speter getrequests: accept: Protocol Error''. The workaround is to kill 11038032Speter and restart the sendmail daemon. We don't have an SVR4 system at 11138032Speter Berkeley that carries more than token mail load, so I can't validate 11238032Speter this. It is likely to be a glitch in the sockets emulation, since 11338032Speter "Protocol Error" is not possible error code with Berkeley TCP/IP. 11438032Speter 11538032Speter I've also had someone report the message ``sendmail: accept: 11638032Speter SIOCGPGRP failed errno 22'' on an SVR4 system. This message is 11738032Speter not in the sendmail source code, so I assume it is also a bug 11838032Speter in the sockets emulation. (Errno 22 is EINVAL "Invalid Argument" 11938032Speter on all the systems I have available, including Solaris 2.x.) 12038032Speter Apparently, this problem is due to linking -lc before -lsocket; 12138032Speter if you are having this problem, check your Makefile. 12238032Speter 12338032Speter* accept() problem on Linux. 12438032Speter 12542575Speter The accept() in sendmail daemon loop can return ETIMEDOUT. An 12642575Speter error is reported to syslog: 12738032Speter 12838032Speter Jun 9 17:14:12 hostname sendmail[207]: NOQUEUE: SYSERR(root): 12938032Speter getrequests: accept: Connection timed out 13038032Speter 13138032Speter "Connection timed out" is not documented as a valid return from 13238032Speter accept(2) and this was believed to be a bug in the Linux kernel. 13338032Speter Later information from the Linux kernel group states that Linux 13438032Speter 2.0 kernels follow RFC1122 while sendmail follows the original BSD 13538032Speter (now POSIX 1003.1g draft) specification. The 2.1.X and later kernels 13638032Speter will follow the POSIX draft. 13738032Speter 13838032Speter* Excessive mailing list nesting can run out of file descriptors. 13938032Speter 14038032Speter If you have a mailing list that includes lots of other mailing 14138032Speter lists, each of which has a separate owner, you can run out of 14238032Speter file descriptors. Each mailing list with a separate owner uses 14338032Speter one open file descriptor (prior to 8.6.6 it was three open 14438032Speter file descriptors per list). This is particularly egregious if 14538032Speter you have your connection cache set to be large. 14638032Speter 14738032Speter* Connection caching breaks if you pass the port number as an argument. 14838032Speter 14938032Speter If you have a definition such as: 15038032Speter 15138032Speter Mport, P=[IPC], F=kmDFMuX, S=11/31, R=21, 15238032Speter M=2100000, T=DNS/RFC822/SMTP, 15338032Speter A=IPC [127.0.0.1] $h 15438032Speter 15538032Speter (i.e., where $h is the port number instead of the host name) the 15638032Speter connection caching code will break because it won't notice that 15738032Speter two messages addressed to different ports should use different 15838032Speter connections. 15938032Speter 16038032Speter* ESMTP SIZE underestimates the size of a message 16138032Speter 16238032Speter Sendmail makes no allowance for headers that it adds, nor does it 16338032Speter account for the SMTP on-the-wire \r\n expansion. It probably doesn't 16438032Speter allow for 8->7 bit MIME conversions either. 16538032Speter 16690792Sgshapiro* Client ignores SIZE parameter. 16790792Sgshapiro 16890792Sgshapiro When sendmail acts as client and the server specifies a limit 16990792Sgshapiro for the mail size, sendmail will ignore this and try to send the 17090792Sgshapiro mail anyway. The server will usually reject the MAIL command 17190792Sgshapiro which specifies the size of the message and hence this problem 17290792Sgshapiro is not significant. 17390792Sgshapiro 17438032Speter* Paths to programs being executed and the mode of program files are 17538032Speter not checked. Essentially, the RunProgramInUnsafeDirPath and 17638032Speter RunWritableProgram bits in the DontBlameSendmail option are always 17738032Speter set. This is not a problem if your system is well managed (that is, 17838032Speter if binaries and system directories are mode 755 instead of something 17938032Speter foolish like 777). 18038032Speter 18138032Speter* 8-bit data in GECOS field 18238032Speter 18338032Speter If the GECOS (personal name) information in the passwd file contains 18438032Speter 8-bit characters, those characters can be included in the message 18538032Speter header, which can cause problems when sending SMTP to hosts that 18638032Speter only accept 7-bit characters. 18738032Speter 18838032Speter* 8->7 bit MIME conversion 18938032Speter 19038032Speter When sendmail is doing 8->7 bit MIME conversions, and the message 19138032Speter contains certain MIME body types that cannot be converted to 7-bit, 192168515Sgshapiro sendmail will pass the message as 8-bit. 19338032Speter 19438032Speter* 7->8 bit MIME conversion 19538032Speter 19638032Speter If a message that is encoded as 7-bit MIME is converted to 8-bit and 19738032Speter that message when decoded is illegal (e.g., because of long lines or 19838032Speter illegal characters), sendmail can produce an illegal message. 19938032Speter 20038032Speter* MIME encoded full name phrases in the From: header 20138032Speter 20264562Sgshapiro If a full name phrase includes characters from MustQuoteChars, sendmail 20390792Sgshapiro will quote the entire full name phrase. If MustQuoteChars includes 20464562Sgshapiro characters which are not special characters according to STD 11 (RFC 20564562Sgshapiro 822), this quotation can interfere with MIME encoded full name phrases. 20638032Speter By default, sendmail includes the single quote character (') in 20738032Speter MustQuoteChars even though it is not listed as a special character in 20838032Speter STD 11. 20938032Speter 21042575Speter* bestmx map with -z flag truncates the list of MX hosts 21138032Speter 21242575Speter A bestmx map configured with the -z flag will truncate the list 21342575Speter of MX hosts. This prevents creation of strings which are too 21442575Speter long for ruleset parsing. This can have an adverse effect on the 21542575Speter relay_based_on_MX feature. 21642575Speter 21743730Speter* Saving to ~sender/dead.letter fails if su'ed to root 21842575Speter 21943730Speter If ErrorMode is set to print and an error in sending mail occurs, 22043730Speter the normal action is to print a message to the screen and append 22143730Speter the message to a dead.letter file in the sender's home directory. 22243730Speter In the case where the sender is using su to act as root, the file 22343730Speter safety checks prevent sendmail from saving the dead.letter file 22443730Speter because the sender's uid and the current real uid do not match. 22564562Sgshapiro 22643730Speter* Berkeley DB 2.X race condition with fcntl() locking 22743730Speter 22843730Speter There is a race condition for Berkeley DB 2.X databases on 22943730Speter operating systems which use fcntl() style locking, such as 23043730Speter Solaris. Sendmail locks the map before calling db_open() to 23143730Speter prevent others from modifying the map while it is being opened. 23243730Speter Unfortunately, Berkeley DB opens the map, closes it, and then 23343730Speter reopens it. fcntl() locking drops the lock when any file 23443730Speter descriptor pointing to the file is closed, even if it is a 23543730Speter different file descriptor than the one used to initially lock 23643730Speter the file. As a result there is a possibility that entries in a 23743730Speter map might not be found during a map rebuild. As a workaround, 23843730Speter you can use makemap to build a map with a new name and then 23943730Speter "mv" the new db file to replace the old one. 24043730Speter 24164562Sgshapiro Sleepycat Software has added code to avoid this race condition to 24264562Sgshapiro Berkeley DB versions after 2.7.5. 24364562Sgshapiro 24443730Speter* File open timeouts not available on hard mounted NFS file systems 24543730Speter 24643730Speter Since SIGALRM does not interrupt an RPC call for hard mounted 24743730Speter NFS file systems, it is impossible to implement a timeout on a file 24843730Speter open operation. Therefore, while the NFS server is not responding, 24943730Speter attempts to open a file on that server will hang. Systems with 25043730Speter local mail delivery and NFS hard mounted home directories should be 25143730Speter avoided, as attempts to open the forward files could hang. 25243730Speter 25390792Sgshapiro* Race condition for delivery to set-user-ID files 25464562Sgshapiro 25564562Sgshapiro Sendmail will deliver to a fail if the file is owned by the DefaultUser 25690792Sgshapiro or has the set-user-ID bit set. Unfortunately, some systems clear that bit 257168515Sgshapiro when a file is modified. Sendmail compensates by resetting the file mode 25864562Sgshapiro back to it's original settings. Unfortunately, there's still a 259168515Sgshapiro permission failure race as sendmail checks the permissions before locking 26064562Sgshapiro the file. This is unavoidable as sendmail must verify the file is safe 26164562Sgshapiro to open before opening it. A file can not be locked until it is open. 26264562Sgshapiro 263110560Sgshapiro* MAIL_HUB always takes precedence over LOCAL_RELAY 264110560Sgshapiro 265110560Sgshapiro Despite the information in the documentation, MAIL_HUB ($H) will always 266110560Sgshapiro be used if set instead of LOCAL_RELAY ($R). This will be fixed in a 267110560Sgshapiro future version. 268110560Sgshapiro 269266711Sgshapiro$Revision: 8.61 $, Last updated $Date: 2011-04-07 17:48:23 $ 270