1219820Sjeff 2219820Sjeff 3219820Sjeff K N O W N B U G S I N S E N D M A I L 4219820Sjeff 5219820Sjeff 6219820SjeffThe following are bugs or deficiencies in sendmail that we are aware of 7219820Sjeffbut which have not been fixed in the current release. You probably 8219820Sjeffwant to get the most up to date version of this from ftp.sendmail.org 9219820Sjeffin /pub/sendmail/KNOWNBUGS. For descriptions of bugs that have been 10219820Sjefffixed, see the file RELEASE_NOTES (in the root directory of the sendmail 11219820Sjeffdistribution). 12219820Sjeff 13219820SjeffThis list is not guaranteed to be complete. 14219820Sjeff 15219820Sjeff* Header values which are too long may be truncated. 16219820Sjeff 17219820Sjeff If a value of a structured header is longer than 256 (MAXNAME) 18219820Sjeff characters then it may be truncated during output. For example, 19219820Sjeff if a single address in the To: header is longer than 256 characters 20219820Sjeff then it will be truncated which may result in a syntactically 21219820Sjeff invalid address. 22219820Sjeff 23219820Sjeff* Delivery to programs that generate too much output may cause problems 24219820Sjeff 25219820Sjeff If e-mail is delivered to a program which generates too much 26219820Sjeff output, then sendmail may issue an error: 27219820Sjeff 28219820Sjeff timeout waiting for input from local during Draining Input 29219820Sjeff 30219820Sjeff Make sure that the program does not generate output beyond a 31219820Sjeff status message (corresponding to the exit status). This may 32219820Sjeff require a wrapper around the actual program to redirect output 33219820Sjeff to /dev/null. 34219820Sjeff 35219820Sjeff Such a problem has been reported for bulk_mailer. 36219820Sjeff 37219820Sjeff* Null bytes are not handled properly in headers. 38219820Sjeff 39219820Sjeff Sendmail should handle full binary data. As it stands, it handles 40219820Sjeff all values in the body, but not 0x00 in the header. Changing 41219820Sjeff this would require a major restructuring of the code -- for 42219820Sjeff example, almost no C library support could be used to handle 43219820Sjeff strings. 44219820Sjeff 45219820Sjeff* Header checks are not called if header value is too long or empty. 46219820Sjeff 47219820Sjeff If the value of a header is longer than 1250 (MAXNAME + MAXATOM - 6) 48219820Sjeff characters or it contains a single word longer than 256 (MAXNAME) 49219820Sjeff characters then no header check is done even if one is configured for 50219820Sjeff the header. 51219820Sjeff 52219820Sjeff* Header lines which are too long will be split incorrectly. 53219820Sjeff 54219820Sjeff Header lines which are longer than 2045 characters will be split 55219820Sjeff but some characters might be lost. Fix: obey RFC (2)822 and do not 56219820Sjeff send lines that are longer than 1000 characters. 57219820Sjeff 58219820Sjeff* milter communication fails if a single header is larger than 64K. 59219820Sjeff 60219820Sjeff If a single header is larger than 64KB (which is not possible in the 61219820Sjeff default configuration) then it cannot be transferred in one block to 62219820Sjeff libmilter and hence the communication fails. This can be avoided by 63219820Sjeff increasing the constant MILTER_CHUNK_SIZE in 64219820Sjeff include/libmilter/mfdef.h and recompiling sendmail, libmilter, and 65219820Sjeff all (statically linked) milters (or by using undocumented compile 66219820Sjeff time options: _FFR_MAXDATASIZE/_FFR_MDS_NEGOTIATE; you have to 67219820Sjeff read the source code in order to use these properly). 68219820Sjeff 69219820Sjeff* Sender addresses whose domain part cause a temporary A record lookup 70219820Sjeff failure but have a valid MX record will be temporarily rejected in 71219820Sjeff the default configuration. Solution: fix the DNS at the sender side. 72219820Sjeff If that's not easy to achieve, possible workarounds are: 73219820Sjeff - add an entry to the access map: 74219820Sjeff dom.ain OK 75219820Sjeff - (only for advanced users) replace 76219820Sjeff 77219820Sjeff# Resolve map (to check if a host exists in check_mail) 78219820SjeffKresolve host -a<OKR> -T<TEMP> 79219820Sjeff 80219820Sjeff with 81219820Sjeff 82219820Sjeff# Resolve map (to check if a host exists in check_mail) 83219820SjeffKcanon host -a<OKR> -T<TEMP> 84219820SjeffKdnsmx dns -R MX -a<OKR> -T<TEMP> 85219820SjeffKresolve sequence dnsmx canon 86219820Sjeff 87219820Sjeff 88219820Sjeff* Duplicate error messages. 89219820Sjeff 90219820Sjeff Sometimes identical, duplicate error messages can be generated. As 91219820Sjeff near as I can tell, this is rare and relatively innocuous. 92219820Sjeff 93219820Sjeff* Misleading error messages. 94219820Sjeff 95219820Sjeff If an illegal address is specified on the command line together 96219820Sjeff with at least one valid address and PostmasterCopy is set, the 97219820Sjeff DSN does not contain the illegal address, but only the valid 98219820Sjeff address(es). 99219820Sjeff 100219820Sjeff* \231 considered harmful. 101219820Sjeff 102219820Sjeff Header addresses that have the \231 character (and possibly others 103219820Sjeff in the range \201 - \237) behave in odd and usually unexpected ways. 104219820Sjeff 105219820Sjeff* AuthRealm for Cyrus SASL may not work as expected. The man page 106219820Sjeff and the actual usage for sasl_server_new() seem to differ. 107219820Sjeff Feedback for the "correct" usage is welcome, a patch to match 108219820Sjeff the description of the man page is in contrib/AuthRealm.p0. 109219820Sjeff 110219820Sjeff* accept() problem on SVR4. 111219820Sjeff 112219820Sjeff Apparently, the sendmail daemon loop (doing accept()s on the network) 113219820Sjeff can get into a weird state on SVR4; it starts logging ``SYSERR: 114219820Sjeff getrequests: accept: Protocol Error''. The workaround is to kill 115219820Sjeff and restart the sendmail daemon. We don't have an SVR4 system at 116219820Sjeff Berkeley that carries more than token mail load, so I can't validate 117219820Sjeff this. It is likely to be a glitch in the sockets emulation, since 118219820Sjeff "Protocol Error" is not possible error code with Berkeley TCP/IP. 119219820Sjeff 120219820Sjeff I've also had someone report the message ``sendmail: accept: 121219820Sjeff SIOCGPGRP failed errno 22'' on an SVR4 system. This message is 122219820Sjeff not in the sendmail source code, so I assume it is also a bug 123219820Sjeff in the sockets emulation. (Errno 22 is EINVAL "Invalid Argument" 124219820Sjeff on all the systems I have available, including Solaris 2.x.) 125219820Sjeff Apparently, this problem is due to linking -lc before -lsocket; 126219820Sjeff if you are having this problem, check your Makefile. 127219820Sjeff 128219820Sjeff* accept() problem on Linux. 129219820Sjeff 130219820Sjeff The accept() in sendmail daemon loop can return ETIMEDOUT. An 131219820Sjeff error is reported to syslog: 132219820Sjeff 133219820Sjeff Jun 9 17:14:12 hostname sendmail[207]: NOQUEUE: SYSERR(root): 134219820Sjeff getrequests: accept: Connection timed out 135219820Sjeff 136219820Sjeff "Connection timed out" is not documented as a valid return from 137219820Sjeff accept(2) and this was believed to be a bug in the Linux kernel. 138219820Sjeff Later information from the Linux kernel group states that Linux 139219820Sjeff 2.0 kernels follow RFC1122 while sendmail follows the original BSD 140219820Sjeff (now POSIX 1003.1g draft) specification. The 2.1.X and later kernels 141219820Sjeff will follow the POSIX draft. 142219820Sjeff 143219820Sjeff* Excessive mailing list nesting can run out of file descriptors. 144219820Sjeff 145219820Sjeff If you have a mailing list that includes lots of other mailing 146219820Sjeff lists, each of which has a separate owner, you can run out of 147219820Sjeff file descriptors. Each mailing list with a separate owner uses 148219820Sjeff one open file descriptor (prior to 8.6.6 it was three open 149219820Sjeff file descriptors per list). This is particularly egregious if 150219820Sjeff you have your connection cache set to be large. 151219820Sjeff 152219820Sjeff* Connection caching breaks if you pass the port number as an argument. 153219820Sjeff 154219820Sjeff If you have a definition such as: 155219820Sjeff 156219820Sjeff Mport, P=[IPC], F=kmDFMuX, S=11/31, R=21, 157219820Sjeff M=2100000, T=DNS/RFC822/SMTP, 158219820Sjeff A=IPC [127.0.0.1] $h 159219820Sjeff 160219820Sjeff (i.e., where $h is the port number instead of the host name) the 161219820Sjeff connection caching code will break because it won't notice that 162219820Sjeff two messages addressed to different ports should use different 163219820Sjeff connections. 164219820Sjeff 165219820Sjeff* ESMTP SIZE underestimates the size of a message 166219820Sjeff 167219820Sjeff Sendmail makes no allowance for headers that it adds, nor does it 168219820Sjeff account for the SMTP on-the-wire \r\n expansion. It probably doesn't 169219820Sjeff allow for 8->7 bit MIME conversions either. 170219820Sjeff 171219820Sjeff* Client ignores SIZE parameter. 172219820Sjeff 173219820Sjeff When sendmail acts as client and the server specifies a limit 174219820Sjeff for the mail size, sendmail will ignore this and try to send the 175219820Sjeff mail anyway. The server will usually reject the MAIL command 176219820Sjeff which specifies the size of the message and hence this problem 177219820Sjeff is not significant. 178219820Sjeff 179219820Sjeff* Paths to programs being executed and the mode of program files are 180219820Sjeff not checked. Essentially, the RunProgramInUnsafeDirPath and 181219820Sjeff RunWritableProgram bits in the DontBlameSendmail option are always 182219820Sjeff set. This is not a problem if your system is well managed (that is, 183219820Sjeff if binaries and system directories are mode 755 instead of something 184219820Sjeff foolish like 777). 185219820Sjeff 186219820Sjeff* 8-bit data in GECOS field 187219820Sjeff 188219820Sjeff If the GECOS (personal name) information in the passwd file contains 189219820Sjeff 8-bit characters, those characters can be included in the message 190219820Sjeff header, which can cause problems when sending SMTP to hosts that 191219820Sjeff only accept 7-bit characters. 192219820Sjeff 193219820Sjeff* 8->7 bit MIME conversion 194219820Sjeff 195219820Sjeff When sendmail is doing 8->7 bit MIME conversions, and the message 196219820Sjeff contains certain MIME body types that cannot be converted to 7-bit, 197219820Sjeff sendmail will pass the message as 8-bit. 198219820Sjeff 199219820Sjeff* 7->8 bit MIME conversion 200219820Sjeff 201219820Sjeff If a message that is encoded as 7-bit MIME is converted to 8-bit and 202219820Sjeff that message when decoded is illegal (e.g., because of long lines or 203219820Sjeff illegal characters), sendmail can produce an illegal message. 204219820Sjeff 205219820Sjeff* MIME encoded full name phrases in the From: header 206219820Sjeff 207219820Sjeff If a full name phrase includes characters from MustQuoteChars, sendmail 208219820Sjeff will quote the entire full name phrase. If MustQuoteChars includes 209219820Sjeff characters which are not special characters according to STD 11 (RFC 210219820Sjeff 822), this quotation can interfere with MIME encoded full name phrases. 211219820Sjeff By default, sendmail includes the single quote character (') in 212219820Sjeff MustQuoteChars even though it is not listed as a special character in 213219820Sjeff STD 11. 214219820Sjeff 215219820Sjeff* bestmx map with -z flag truncates the list of MX hosts 216219820Sjeff 217219820Sjeff A bestmx map configured with the -z flag will truncate the list 218219820Sjeff of MX hosts. This prevents creation of strings which are too 219219820Sjeff long for ruleset parsing. This can have an adverse effect on the 220219820Sjeff relay_based_on_MX feature. 221219820Sjeff 222219820Sjeff* Saving to ~sender/dead.letter fails if su'ed to root 223219820Sjeff 224219820Sjeff If ErrorMode is set to print and an error in sending mail occurs, 225219820Sjeff the normal action is to print a message to the screen and append 226219820Sjeff the message to a dead.letter file in the sender's home directory. 227219820Sjeff In the case where the sender is using su to act as root, the file 228219820Sjeff safety checks prevent sendmail from saving the dead.letter file 229219820Sjeff because the sender's uid and the current real uid do not match. 230219820Sjeff 231219820Sjeff* Berkeley DB 2.X race condition with fcntl() locking 232219820Sjeff 233219820Sjeff There is a race condition for Berkeley DB 2.X databases on 234219820Sjeff operating systems which use fcntl() style locking, such as 235219820Sjeff Solaris. Sendmail locks the map before calling db_open() to 236219820Sjeff prevent others from modifying the map while it is being opened. 237219820Sjeff Unfortunately, Berkeley DB opens the map, closes it, and then 238219820Sjeff reopens it. fcntl() locking drops the lock when any file 239219820Sjeff descriptor pointing to the file is closed, even if it is a 240219820Sjeff different file descriptor than the one used to initially lock 241219820Sjeff the file. As a result there is a possibility that entries in a 242219820Sjeff map might not be found during a map rebuild. As a workaround, 243219820Sjeff you can use makemap to build a map with a new name and then 244219820Sjeff "mv" the new db file to replace the old one. 245219820Sjeff 246219820Sjeff Sleepycat Software has added code to avoid this race condition to 247219820Sjeff Berkeley DB versions after 2.7.5. 248219820Sjeff 249219820Sjeff* File open timeouts not available on hard mounted NFS file systems 250219820Sjeff 251219820Sjeff Since SIGALRM does not interrupt an RPC call for hard mounted 252219820Sjeff NFS file systems, it is impossible to implement a timeout on a file 253219820Sjeff open operation. Therefore, while the NFS server is not responding, 254219820Sjeff attempts to open a file on that server will hang. Systems with 255219820Sjeff local mail delivery and NFS hard mounted home directories should be 256219820Sjeff avoided, as attempts to open the forward files could hang. 257219820Sjeff 258219820Sjeff* Race condition for delivery to set-user-ID files 259219820Sjeff 260219820Sjeff Sendmail will deliver to a file if the file is owned by the DefaultUser 261219820Sjeff or has the set-user-ID bit set. Unfortunately, some systems clear that bit 262219820Sjeff when a file is modified. Sendmail compensates by resetting the file mode 263219820Sjeff back to it's original settings. Unfortunately, there's still a 264219820Sjeff permission failure race as sendmail checks the permissions before locking 265219820Sjeff the file. This is unavoidable as sendmail must verify the file is safe 266219820Sjeff to open before opening it. A file can not be locked until it is open. 267219820Sjeff 268219820Sjeff* MAIL_HUB always takes precedence over LOCAL_RELAY 269219820Sjeff 270219820Sjeff Despite the information in the documentation, MAIL_HUB ($H) will always 271219820Sjeff be used if set instead of LOCAL_RELAY ($R). This will be fixed in a 272219820Sjeff future version. 273219820Sjeff 274219820Sjeff$Revision: 8.61 $, Last updated $Date: 2011-04-07 17:48:23 $ 275219820Sjeff