KNOWNBUGS revision 132943
1254721Semaste 2254721Semaste 3254721Semaste K N O W N B U G S I N S E N D M A I L 4254721Semaste 5254721Semaste 6254721SemasteThe following are bugs or deficiencies in sendmail that we are aware of 7254721Semastebut which have not been fixed in the current release. You probably 8254721Semastewant to get the most up to date version of this from ftp.sendmail.org 9254721Semastein /pub/sendmail/KNOWNBUGS. For descriptions of bugs that have been 10254721Semastefixed, see the file RELEASE_NOTES (in the root directory of the sendmail 11254721Semastedistribution). 12254721Semaste 13254721SemasteThis list is not guaranteed to be complete. 14296417Sdim 15254721Semaste* Delivery to programs that generate too much output may cause problems 16254721Semaste 17254721Semaste If e-mail is delivered to a program which generates too much 18254721Semaste output, then sendmail may issue an error: 19254721Semaste 20254721Semaste timeout waiting for input from local during Draining Input 21254721Semaste 22254721Semaste Make sure that the program does not generate output beyond a 23254721Semaste status message (corresponding to the exit status). This may 24254721Semaste require a wrapper around the actual program to redirect output 25254721Semaste to /dev/null. 26254721Semaste 27254721Semaste Such a problem has been reported for bulk_mailer. 28262528Semaste 29262528Semaste* Null bytes are not handled properly in headers. 30254721Semaste 31254721Semaste Sendmail should handle full binary data. As it stands, it handles 32254721Semaste all values in the body, but only 0x01-0x80 and 0xA0-0xFF in 33296417Sdim the header. Notably missing is 0x00, which would require a major 34296417Sdim restructuring of the code -- for example, almost no C library support 35296417Sdim could be used to handle strings. 36296417Sdim 37296417Sdim* Header checks are not called if header value is too long or empty. 38280031Sdim 39254721Semaste If the value of a header is longer than 1250 (MAXNAME + MAXATOM - 6) 40254721Semaste characters or it contains a single word longer than 256 (MAXNAME) 41254721Semaste characters then no header check is done even if one is configured for 42254721Semaste the header. 43254721Semaste 44254721Semaste* Sender addresses whose domain part cause a temporary A record lookup 45288943Sdim failure but have a valid MX record will be temporarily rejected in 46254721Semaste the default configuration. Solution: fix the DNS at the sender side. 47296417Sdim If that's not easy to achieve, possible workarounds are: 48296417Sdim - add an entry to the access map: 49296417Sdim dom.ain OK 50288943Sdim - (only for advanced users) replace 51288943Sdim 52254721Semaste# Resolve map (to check if a host exists in check_mail) 53262528SemasteKresolve host -a<OKR> -T<TEMP> 54254721Semaste 55258054Semaste with 56254721Semaste 57254721Semaste# Resolve map (to check if a host exists in check_mail) 58296417SdimKcanon host -a<OKR> -T<TEMP> 59254721SemasteKdnsmx dns -R MX -a<OKR> -T<TEMP> 60254721SemasteKresolve sequence dnsmx canon 61254721Semaste 62254721Semaste 63254721Semaste* Duplicate error messages. 64254721Semaste 65254721Semaste Sometimes identical, duplicate error messages can be generated. As 66254721Semaste near as I can tell, this is rare and relatively innocuous. 67254721Semaste 68254721Semaste* Misleading error messages. 69254721Semaste 70280031Sdim If an illegal address is specified on the command line together 71254721Semaste with at least one valid address and PostmasterCopy is set, the 72254721Semaste DSN does not contain the illegal address, but only the valid 73254721Semaste address(es). 74254721Semaste 75254721Semaste* \231 considered harmful. 76254721Semaste 77254721Semaste Header addresses that have the \231 character (and possibly others 78254721Semaste in the range \201 - \237) behave in odd and usually unexpected ways. 79262528Semaste 80254721Semaste* accept() problem on SVR4. 81254721Semaste 82254721Semaste Apparently, the sendmail daemon loop (doing accept()s on the network) 83254721Semaste can get into a weird state on SVR4; it starts logging ``SYSERR: 84254721Semaste getrequests: accept: Protocol Error''. The workaround is to kill 85254721Semaste and restart the sendmail daemon. We don't have an SVR4 system at 86296417Sdim Berkeley that carries more than token mail load, so I can't validate 87254721Semaste this. It is likely to be a glitch in the sockets emulation, since 88254721Semaste "Protocol Error" is not possible error code with Berkeley TCP/IP. 89254721Semaste 90262528Semaste I've also had someone report the message ``sendmail: accept: 91280031Sdim SIOCGPGRP failed errno 22'' on an SVR4 system. This message is 92280031Sdim not in the sendmail source code, so I assume it is also a bug 93280031Sdim in the sockets emulation. (Errno 22 is EINVAL "Invalid Argument" 94254721Semaste on all the systems I have available, including Solaris 2.x.) 95254721Semaste Apparently, this problem is due to linking -lc before -lsocket; 96254721Semaste if you are having this problem, check your Makefile. 97254721Semaste 98254721Semaste* accept() problem on Linux. 99254721Semaste 100276479Sdim The accept() in sendmail daemon loop can return ETIMEDOUT. An 101254721Semaste error is reported to syslog: 102254721Semaste 103254721Semaste Jun 9 17:14:12 hostname sendmail[207]: NOQUEUE: SYSERR(root): 104254721Semaste getrequests: accept: Connection timed out 105276479Sdim 106254721Semaste "Connection timed out" is not documented as a valid return from 107254721Semaste accept(2) and this was believed to be a bug in the Linux kernel. 108254721Semaste Later information from the Linux kernel group states that Linux 109254721Semaste 2.0 kernels follow RFC1122 while sendmail follows the original BSD 110254721Semaste (now POSIX 1003.1g draft) specification. The 2.1.X and later kernels 111254721Semaste will follow the POSIX draft. 112296417Sdim 113296417Sdim* Excessive mailing list nesting can run out of file descriptors. 114296417Sdim 115296417Sdim If you have a mailing list that includes lots of other mailing 116296417Sdim lists, each of which has a separate owner, you can run out of 117296417Sdim file descriptors. Each mailing list with a separate owner uses 118296417Sdim one open file descriptor (prior to 8.6.6 it was three open 119296417Sdim file descriptors per list). This is particularly egregious if 120280031Sdim you have your connection cache set to be large. 121280031Sdim 122280031Sdim* Connection caching breaks if you pass the port number as an argument. 123280031Sdim 124280031Sdim If you have a definition such as: 125280031Sdim 126280031Sdim Mport, P=[IPC], F=kmDFMuX, S=11/31, R=21, 127280031Sdim M=2100000, T=DNS/RFC822/SMTP, 128280031Sdim A=IPC [127.0.0.1] $h 129280031Sdim 130280031Sdim (i.e., where $h is the port number instead of the host name) the 131280031Sdim connection caching code will break because it won't notice that 132280031Sdim two messages addressed to different ports should use different 133280031Sdim connections. 134280031Sdim 135280031Sdim* ESMTP SIZE underestimates the size of a message 136280031Sdim 137280031Sdim Sendmail makes no allowance for headers that it adds, nor does it 138254721Semaste account for the SMTP on-the-wire \r\n expansion. It probably doesn't 139254721Semaste allow for 8->7 bit MIME conversions either. 140254721Semaste 141254721Semaste* Client ignores SIZE parameter. 142254721Semaste 143254721Semaste When sendmail acts as client and the server specifies a limit 144254721Semaste for the mail size, sendmail will ignore this and try to send the 145254721Semaste mail anyway. The server will usually reject the MAIL command 146254721Semaste which specifies the size of the message and hence this problem 147254721Semaste is not significant. 148254721Semaste 149254721Semaste* Paths to programs being executed and the mode of program files are 150254721Semaste not checked. Essentially, the RunProgramInUnsafeDirPath and 151254721Semaste RunWritableProgram bits in the DontBlameSendmail option are always 152254721Semaste set. This is not a problem if your system is well managed (that is, 153254721Semaste if binaries and system directories are mode 755 instead of something 154254721Semaste foolish like 777). 155254721Semaste 156254721Semaste* 8-bit data in GECOS field 157254721Semaste 158254721Semaste If the GECOS (personal name) information in the passwd file contains 159254721Semaste 8-bit characters, those characters can be included in the message 160254721Semaste header, which can cause problems when sending SMTP to hosts that 161254721Semaste only accept 7-bit characters. 162254721Semaste 163254721Semaste* 8->7 bit MIME conversion 164254721Semaste 165254721Semaste When sendmail is doing 8->7 bit MIME conversions, and the message 166254721Semaste contains certain MIME body types that cannot be converted to 7-bit, 167254721Semaste sendmail will strip the message to 7-bit. 168254721Semaste 169254721Semaste* 7->8 bit MIME conversion 170254721Semaste 171254721Semaste If a message that is encoded as 7-bit MIME is converted to 8-bit and 172254721Semaste that message when decoded is illegal (e.g., because of long lines or 173254721Semaste illegal characters), sendmail can produce an illegal message. 174254721Semaste 175288943Sdim* MIME encoded full name phrases in the From: header 176254721Semaste 177254721Semaste If a full name phrase includes characters from MustQuoteChars, sendmail 178254721Semaste will quote the entire full name phrase. If MustQuoteChars includes 179254721Semaste characters which are not special characters according to STD 11 (RFC 180254721Semaste 822), this quotation can interfere with MIME encoded full name phrases. 181296417Sdim By default, sendmail includes the single quote character (') in 182254721Semaste MustQuoteChars even though it is not listed as a special character in 183262528Semaste STD 11. 184254721Semaste 185288943Sdim* bestmx map with -z flag truncates the list of MX hosts 186254721Semaste 187254721Semaste A bestmx map configured with the -z flag will truncate the list 188254721Semaste of MX hosts. This prevents creation of strings which are too 189254721Semaste long for ruleset parsing. This can have an adverse effect on the 190254721Semaste relay_based_on_MX feature. 191254721Semaste 192254721Semaste* Saving to ~sender/dead.letter fails if su'ed to root 193254721Semaste 194254721Semaste If ErrorMode is set to print and an error in sending mail occurs, 195254721Semaste the normal action is to print a message to the screen and append 196254721Semaste the message to a dead.letter file in the sender's home directory. 197254721Semaste In the case where the sender is using su to act as root, the file 198254721Semaste safety checks prevent sendmail from saving the dead.letter file 199296417Sdim because the sender's uid and the current real uid do not match. 200254721Semaste 201254721Semaste* Berkeley DB 2.X race condition with fcntl() locking 202254721Semaste 203254721Semaste There is a race condition for Berkeley DB 2.X databases on 204254721Semaste operating systems which use fcntl() style locking, such as 205254721Semaste Solaris. Sendmail locks the map before calling db_open() to 206254721Semaste prevent others from modifying the map while it is being opened. 207254721Semaste Unfortunately, Berkeley DB opens the map, closes it, and then 208254721Semaste reopens it. fcntl() locking drops the lock when any file 209296417Sdim descriptor pointing to the file is closed, even if it is a 210296417Sdim different file descriptor than the one used to initially lock 211296417Sdim the file. As a result there is a possibility that entries in a 212296417Sdim map might not be found during a map rebuild. As a workaround, 213296417Sdim you can use makemap to build a map with a new name and then 214296417Sdim "mv" the new db file to replace the old one. 215296417Sdim 216296417Sdim Sleepycat Software has added code to avoid this race condition to 217296417Sdim Berkeley DB versions after 2.7.5. 218296417Sdim 219296417Sdim* File open timeouts not available on hard mounted NFS file systems 220296417Sdim 221296417Sdim Since SIGALRM does not interrupt an RPC call for hard mounted 222296417Sdim NFS file systems, it is impossible to implement a timeout on a file 223296417Sdim open operation. Therefore, while the NFS server is not responding, 224296417Sdim attempts to open a file on that server will hang. Systems with 225296417Sdim local mail delivery and NFS hard mounted home directories should be 226296417Sdim avoided, as attempts to open the forward files could hang. 227296417Sdim 228296417Sdim* Race condition for delivery to set-user-ID files 229296417Sdim 230296417Sdim Sendmail will deliver to a fail if the file is owned by the DefaultUser 231296417Sdim or has the set-user-ID bit set. Unfortunately, some systems clear that bit 232296417Sdim when a file is modified. Sendmail compensates by resetting the file mode 233296417Sdim back to it's original settings. Unfortunately, there's still a 234296417Sdim permission failure race as sendmail checks the permissions before locking 235296417Sdim the file. This is unavoidable as sendmail must verify the file is safe 236296417Sdim to open before opening it. A file can not be locked until it is open. 237296417Sdim 238296417Sdim* MAIL_HUB always takes precedence over LOCAL_RELAY 239296417Sdim 240296417Sdim Despite the information in the documentation, MAIL_HUB ($H) will always 241296417Sdim be used if set instead of LOCAL_RELAY ($R). This will be fixed in a 242296417Sdim future version. 243296417Sdim 244296417Sdim$Revision: 8.56 $, Last updated $Date: 2002/12/18 22:39:06 $ 245296417Sdim