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 65285229Sgshapiro all (statically linked) milters (or by using undocumented compile 66285229Sgshapiro time options: _FFR_MAXDATASIZE/_FFR_MDS_NEGOTIATE; you have to 67285229Sgshapiro read the source code in order to use these 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 105285229Sgshapiro* AuthRealm for Cyrus SASL may not work as expected. The man page 106285229Sgshapiro and the actual usage for sasl_server_new() seem to differ. 107285229Sgshapiro Feedback for the "correct" usage is welcome, a patch to match 108285229Sgshapiro the description of the man page is in contrib/AuthRealm.p0. 109285229Sgshapiro 11038032Speter* accept() problem on SVR4. 11138032Speter 11238032Speter Apparently, the sendmail daemon loop (doing accept()s on the network) 11338032Speter can get into a weird state on SVR4; it starts logging ``SYSERR: 11438032Speter getrequests: accept: Protocol Error''. The workaround is to kill 11538032Speter and restart the sendmail daemon. We don't have an SVR4 system at 11638032Speter Berkeley that carries more than token mail load, so I can't validate 11738032Speter this. It is likely to be a glitch in the sockets emulation, since 11838032Speter "Protocol Error" is not possible error code with Berkeley TCP/IP. 11938032Speter 12038032Speter I've also had someone report the message ``sendmail: accept: 12138032Speter SIOCGPGRP failed errno 22'' on an SVR4 system. This message is 12238032Speter not in the sendmail source code, so I assume it is also a bug 12338032Speter in the sockets emulation. (Errno 22 is EINVAL "Invalid Argument" 12438032Speter on all the systems I have available, including Solaris 2.x.) 12538032Speter Apparently, this problem is due to linking -lc before -lsocket; 12638032Speter if you are having this problem, check your Makefile. 12738032Speter 12838032Speter* accept() problem on Linux. 12938032Speter 13042575Speter The accept() in sendmail daemon loop can return ETIMEDOUT. An 13142575Speter error is reported to syslog: 13238032Speter 13338032Speter Jun 9 17:14:12 hostname sendmail[207]: NOQUEUE: SYSERR(root): 13438032Speter getrequests: accept: Connection timed out 13538032Speter 13638032Speter "Connection timed out" is not documented as a valid return from 13738032Speter accept(2) and this was believed to be a bug in the Linux kernel. 13838032Speter Later information from the Linux kernel group states that Linux 13938032Speter 2.0 kernels follow RFC1122 while sendmail follows the original BSD 14038032Speter (now POSIX 1003.1g draft) specification. The 2.1.X and later kernels 14138032Speter will follow the POSIX draft. 14238032Speter 14338032Speter* Excessive mailing list nesting can run out of file descriptors. 14438032Speter 14538032Speter If you have a mailing list that includes lots of other mailing 14638032Speter lists, each of which has a separate owner, you can run out of 14738032Speter file descriptors. Each mailing list with a separate owner uses 14838032Speter one open file descriptor (prior to 8.6.6 it was three open 14938032Speter file descriptors per list). This is particularly egregious if 15038032Speter you have your connection cache set to be large. 15138032Speter 15238032Speter* Connection caching breaks if you pass the port number as an argument. 15338032Speter 15438032Speter If you have a definition such as: 15538032Speter 15638032Speter Mport, P=[IPC], F=kmDFMuX, S=11/31, R=21, 15738032Speter M=2100000, T=DNS/RFC822/SMTP, 15838032Speter A=IPC [127.0.0.1] $h 15938032Speter 16038032Speter (i.e., where $h is the port number instead of the host name) the 16138032Speter connection caching code will break because it won't notice that 16238032Speter two messages addressed to different ports should use different 16338032Speter connections. 16438032Speter 16538032Speter* ESMTP SIZE underestimates the size of a message 16638032Speter 16738032Speter Sendmail makes no allowance for headers that it adds, nor does it 16838032Speter account for the SMTP on-the-wire \r\n expansion. It probably doesn't 16938032Speter allow for 8->7 bit MIME conversions either. 17038032Speter 17190792Sgshapiro* Client ignores SIZE parameter. 17290792Sgshapiro 17390792Sgshapiro When sendmail acts as client and the server specifies a limit 17490792Sgshapiro for the mail size, sendmail will ignore this and try to send the 17590792Sgshapiro mail anyway. The server will usually reject the MAIL command 17690792Sgshapiro which specifies the size of the message and hence this problem 17790792Sgshapiro is not significant. 17890792Sgshapiro 17938032Speter* Paths to programs being executed and the mode of program files are 18038032Speter not checked. Essentially, the RunProgramInUnsafeDirPath and 18138032Speter RunWritableProgram bits in the DontBlameSendmail option are always 18238032Speter set. This is not a problem if your system is well managed (that is, 18338032Speter if binaries and system directories are mode 755 instead of something 18438032Speter foolish like 777). 18538032Speter 18638032Speter* 8-bit data in GECOS field 18738032Speter 18838032Speter If the GECOS (personal name) information in the passwd file contains 18938032Speter 8-bit characters, those characters can be included in the message 19038032Speter header, which can cause problems when sending SMTP to hosts that 19138032Speter only accept 7-bit characters. 19238032Speter 19338032Speter* 8->7 bit MIME conversion 19438032Speter 19538032Speter When sendmail is doing 8->7 bit MIME conversions, and the message 19638032Speter contains certain MIME body types that cannot be converted to 7-bit, 197168515Sgshapiro sendmail will pass the message as 8-bit. 19838032Speter 19938032Speter* 7->8 bit MIME conversion 20038032Speter 20138032Speter If a message that is encoded as 7-bit MIME is converted to 8-bit and 20238032Speter that message when decoded is illegal (e.g., because of long lines or 20338032Speter illegal characters), sendmail can produce an illegal message. 20438032Speter 20538032Speter* MIME encoded full name phrases in the From: header 20638032Speter 20764562Sgshapiro If a full name phrase includes characters from MustQuoteChars, sendmail 20890792Sgshapiro will quote the entire full name phrase. If MustQuoteChars includes 20964562Sgshapiro characters which are not special characters according to STD 11 (RFC 21064562Sgshapiro 822), this quotation can interfere with MIME encoded full name phrases. 21138032Speter By default, sendmail includes the single quote character (') in 21238032Speter MustQuoteChars even though it is not listed as a special character in 21338032Speter STD 11. 21438032Speter 21542575Speter* bestmx map with -z flag truncates the list of MX hosts 21638032Speter 21742575Speter A bestmx map configured with the -z flag will truncate the list 21842575Speter of MX hosts. This prevents creation of strings which are too 21942575Speter long for ruleset parsing. This can have an adverse effect on the 22042575Speter relay_based_on_MX feature. 22142575Speter 22243730Speter* Saving to ~sender/dead.letter fails if su'ed to root 22342575Speter 22443730Speter If ErrorMode is set to print and an error in sending mail occurs, 22543730Speter the normal action is to print a message to the screen and append 22643730Speter the message to a dead.letter file in the sender's home directory. 22743730Speter In the case where the sender is using su to act as root, the file 22843730Speter safety checks prevent sendmail from saving the dead.letter file 22943730Speter because the sender's uid and the current real uid do not match. 23064562Sgshapiro 23143730Speter* Berkeley DB 2.X race condition with fcntl() locking 23243730Speter 23343730Speter There is a race condition for Berkeley DB 2.X databases on 23443730Speter operating systems which use fcntl() style locking, such as 23543730Speter Solaris. Sendmail locks the map before calling db_open() to 23643730Speter prevent others from modifying the map while it is being opened. 23743730Speter Unfortunately, Berkeley DB opens the map, closes it, and then 23843730Speter reopens it. fcntl() locking drops the lock when any file 23943730Speter descriptor pointing to the file is closed, even if it is a 24043730Speter different file descriptor than the one used to initially lock 24143730Speter the file. As a result there is a possibility that entries in a 24243730Speter map might not be found during a map rebuild. As a workaround, 24343730Speter you can use makemap to build a map with a new name and then 24443730Speter "mv" the new db file to replace the old one. 24543730Speter 24664562Sgshapiro Sleepycat Software has added code to avoid this race condition to 24764562Sgshapiro Berkeley DB versions after 2.7.5. 24864562Sgshapiro 24943730Speter* File open timeouts not available on hard mounted NFS file systems 25043730Speter 25143730Speter Since SIGALRM does not interrupt an RPC call for hard mounted 25243730Speter NFS file systems, it is impossible to implement a timeout on a file 25343730Speter open operation. Therefore, while the NFS server is not responding, 25443730Speter attempts to open a file on that server will hang. Systems with 25543730Speter local mail delivery and NFS hard mounted home directories should be 25643730Speter avoided, as attempts to open the forward files could hang. 25743730Speter 25890792Sgshapiro* Race condition for delivery to set-user-ID files 25964562Sgshapiro 260285229Sgshapiro Sendmail will deliver to a file if the file is owned by the DefaultUser 26190792Sgshapiro or has the set-user-ID bit set. Unfortunately, some systems clear that bit 262168515Sgshapiro when a file is modified. Sendmail compensates by resetting the file mode 26364562Sgshapiro back to it's original settings. Unfortunately, there's still a 264168515Sgshapiro permission failure race as sendmail checks the permissions before locking 26564562Sgshapiro the file. This is unavoidable as sendmail must verify the file is safe 26664562Sgshapiro to open before opening it. A file can not be locked until it is open. 26764562Sgshapiro 268110560Sgshapiro* MAIL_HUB always takes precedence over LOCAL_RELAY 269110560Sgshapiro 270110560Sgshapiro Despite the information in the documentation, MAIL_HUB ($H) will always 271110560Sgshapiro be used if set instead of LOCAL_RELAY ($R). This will be fixed in a 272110560Sgshapiro future version. 273110560Sgshapiro 274266527Sgshapiro$Revision: 8.61 $, Last updated $Date: 2011-04-07 17:48:23 $ 275