diff options
Diffstat (limited to 'sendmail/KNOWNBUGS')
-rw-r--r-- | sendmail/KNOWNBUGS | 250 |
1 files changed, 250 insertions, 0 deletions
diff --git a/sendmail/KNOWNBUGS b/sendmail/KNOWNBUGS new file mode 100644 index 000000000000..6c7adb11fdf2 --- /dev/null +++ b/sendmail/KNOWNBUGS @@ -0,0 +1,250 @@ + + + K N O W N B U G S I N S E N D M A I L + + +The following are bugs or deficiencies in sendmail that we are aware of +but which have not been fixed in the current release. You probably +want to get the most up to date version of this from ftp.sendmail.org +in /pub/sendmail/KNOWNBUGS. For descriptions of bugs that have been +fixed, see the file RELEASE_NOTES (in the root directory of the sendmail +distribution). + +This list is not guaranteed to be complete. + +* Delivery to programs that generate too much output may cause problems + + If e-mail is delivered to a program which generates too much + output, then sendmail may issue an error: + + timeout waiting for input from local during Draining Input + + Make sure that the program does not generate output beyond a + status message (corresponding to the exit status). This may + require a wrapper around the actual program to redirect output + to /dev/null. + + Such a problem has been reported for bulk_mailer. + +* Null bytes are not handled properly in headers. + + Sendmail should handle full binary data. As it stands, it handles + all values in the body, but not 0x00 in the header. Changing + this would require a major restructuring of the code -- for + example, almost no C library support could be used to handle + strings. + +* Header checks are not called if header value is too long or empty. + + If the value of a header is longer than 1250 (MAXNAME + MAXATOM - 6) + characters or it contains a single word longer than 256 (MAXNAME) + characters then no header check is done even if one is configured for + the header. + +* Header lines which are too long will be split incorrectly. + + Header lines which are longer than 2045 characters will be split + but some characters might be lost. Fix: obey RFC (2)822 and do not + send lines that are longer than 1000 characters. + +* Sender addresses whose domain part cause a temporary A record lookup + failure but have a valid MX record will be temporarily rejected in + the default configuration. Solution: fix the DNS at the sender side. + If that's not easy to achieve, possible workarounds are: + - add an entry to the access map: + dom.ain OK + - (only for advanced users) replace + +# Resolve map (to check if a host exists in check_mail) +Kresolve host -a<OKR> -T<TEMP> + + with + +# Resolve map (to check if a host exists in check_mail) +Kcanon host -a<OKR> -T<TEMP> +Kdnsmx dns -R MX -a<OKR> -T<TEMP> +Kresolve sequence dnsmx canon + + +* Duplicate error messages. + + Sometimes identical, duplicate error messages can be generated. As + near as I can tell, this is rare and relatively innocuous. + +* Misleading error messages. + + If an illegal address is specified on the command line together + with at least one valid address and PostmasterCopy is set, the + DSN does not contain the illegal address, but only the valid + address(es). + +* \231 considered harmful. + + Header addresses that have the \231 character (and possibly others + in the range \201 - \237) behave in odd and usually unexpected ways. + +* accept() problem on SVR4. + + Apparently, the sendmail daemon loop (doing accept()s on the network) + can get into a weird state on SVR4; it starts logging ``SYSERR: + getrequests: accept: Protocol Error''. The workaround is to kill + and restart the sendmail daemon. We don't have an SVR4 system at + Berkeley that carries more than token mail load, so I can't validate + this. It is likely to be a glitch in the sockets emulation, since + "Protocol Error" is not possible error code with Berkeley TCP/IP. + + I've also had someone report the message ``sendmail: accept: + SIOCGPGRP failed errno 22'' on an SVR4 system. This message is + not in the sendmail source code, so I assume it is also a bug + in the sockets emulation. (Errno 22 is EINVAL "Invalid Argument" + on all the systems I have available, including Solaris 2.x.) + Apparently, this problem is due to linking -lc before -lsocket; + if you are having this problem, check your Makefile. + +* accept() problem on Linux. + + The accept() in sendmail daemon loop can return ETIMEDOUT. An + error is reported to syslog: + + Jun 9 17:14:12 hostname sendmail[207]: NOQUEUE: SYSERR(root): + getrequests: accept: Connection timed out + + "Connection timed out" is not documented as a valid return from + accept(2) and this was believed to be a bug in the Linux kernel. + Later information from the Linux kernel group states that Linux + 2.0 kernels follow RFC1122 while sendmail follows the original BSD + (now POSIX 1003.1g draft) specification. The 2.1.X and later kernels + will follow the POSIX draft. + +* Excessive mailing list nesting can run out of file descriptors. + + If you have a mailing list that includes lots of other mailing + lists, each of which has a separate owner, you can run out of + file descriptors. Each mailing list with a separate owner uses + one open file descriptor (prior to 8.6.6 it was three open + file descriptors per list). This is particularly egregious if + you have your connection cache set to be large. + +* Connection caching breaks if you pass the port number as an argument. + + If you have a definition such as: + + Mport, P=[IPC], F=kmDFMuX, S=11/31, R=21, + M=2100000, T=DNS/RFC822/SMTP, + A=IPC [127.0.0.1] $h + + (i.e., where $h is the port number instead of the host name) the + connection caching code will break because it won't notice that + two messages addressed to different ports should use different + connections. + +* ESMTP SIZE underestimates the size of a message + + Sendmail makes no allowance for headers that it adds, nor does it + account for the SMTP on-the-wire \r\n expansion. It probably doesn't + allow for 8->7 bit MIME conversions either. + +* Client ignores SIZE parameter. + + When sendmail acts as client and the server specifies a limit + for the mail size, sendmail will ignore this and try to send the + mail anyway. The server will usually reject the MAIL command + which specifies the size of the message and hence this problem + is not significant. + +* Paths to programs being executed and the mode of program files are + not checked. Essentially, the RunProgramInUnsafeDirPath and + RunWritableProgram bits in the DontBlameSendmail option are always + set. This is not a problem if your system is well managed (that is, + if binaries and system directories are mode 755 instead of something + foolish like 777). + +* 8-bit data in GECOS field + + If the GECOS (personal name) information in the passwd file contains + 8-bit characters, those characters can be included in the message + header, which can cause problems when sending SMTP to hosts that + only accept 7-bit characters. + +* 8->7 bit MIME conversion + + When sendmail is doing 8->7 bit MIME conversions, and the message + contains certain MIME body types that cannot be converted to 7-bit, + sendmail will pass the message as 8-bit. + +* 7->8 bit MIME conversion + + If a message that is encoded as 7-bit MIME is converted to 8-bit and + that message when decoded is illegal (e.g., because of long lines or + illegal characters), sendmail can produce an illegal message. + +* MIME encoded full name phrases in the From: header + + If a full name phrase includes characters from MustQuoteChars, sendmail + will quote the entire full name phrase. If MustQuoteChars includes + characters which are not special characters according to STD 11 (RFC + 822), this quotation can interfere with MIME encoded full name phrases. + By default, sendmail includes the single quote character (') in + MustQuoteChars even though it is not listed as a special character in + STD 11. + +* bestmx map with -z flag truncates the list of MX hosts + + A bestmx map configured with the -z flag will truncate the list + of MX hosts. This prevents creation of strings which are too + long for ruleset parsing. This can have an adverse effect on the + relay_based_on_MX feature. + +* Saving to ~sender/dead.letter fails if su'ed to root + + If ErrorMode is set to print and an error in sending mail occurs, + the normal action is to print a message to the screen and append + the message to a dead.letter file in the sender's home directory. + In the case where the sender is using su to act as root, the file + safety checks prevent sendmail from saving the dead.letter file + because the sender's uid and the current real uid do not match. + +* Berkeley DB 2.X race condition with fcntl() locking + + There is a race condition for Berkeley DB 2.X databases on + operating systems which use fcntl() style locking, such as + Solaris. Sendmail locks the map before calling db_open() to + prevent others from modifying the map while it is being opened. + Unfortunately, Berkeley DB opens the map, closes it, and then + reopens it. fcntl() locking drops the lock when any file + descriptor pointing to the file is closed, even if it is a + different file descriptor than the one used to initially lock + the file. As a result there is a possibility that entries in a + map might not be found during a map rebuild. As a workaround, + you can use makemap to build a map with a new name and then + "mv" the new db file to replace the old one. + + Sleepycat Software has added code to avoid this race condition to + Berkeley DB versions after 2.7.5. + +* File open timeouts not available on hard mounted NFS file systems + + Since SIGALRM does not interrupt an RPC call for hard mounted + NFS file systems, it is impossible to implement a timeout on a file + open operation. Therefore, while the NFS server is not responding, + attempts to open a file on that server will hang. Systems with + local mail delivery and NFS hard mounted home directories should be + avoided, as attempts to open the forward files could hang. + +* Race condition for delivery to set-user-ID files + + Sendmail will deliver to a fail if the file is owned by the DefaultUser + or has the set-user-ID bit set. Unfortunately, some systems clear that bit + when a file is modified. Sendmail compensates by resetting the file mode + back to it's original settings. Unfortunately, there's still a + permission failure race as sendmail checks the permissions before locking + the file. This is unavoidable as sendmail must verify the file is safe + to open before opening it. A file can not be locked until it is open. + +* MAIL_HUB always takes precedence over LOCAL_RELAY + + Despite the information in the documentation, MAIL_HUB ($H) will always + be used if set instead of LOCAL_RELAY ($R). This will be fixed in a + future version. + +$Revision: 8.59 $, Last updated $Date: 2007/02/21 23:13:58 $ |