| 1 |
|
| 2 |
|
| 3 |
K N O W N B U G S I N S E N D M A I L |
| 4 |
|
| 5 |
|
| 6 |
The following are bugs or deficiencies in sendmail that we are aware of |
| 7 |
but which have not been fixed in the current release. You probably |
| 8 |
want to get the most up to date version of this from ftp.sendmail.org |
| 9 |
in /pub/sendmail/KNOWNBUGS. For descriptions of bugs that have been |
| 10 |
fixed, see the file RELEASE_NOTES (in the root directory of the sendmail |
| 11 |
distribution). |
| 12 |
|
| 13 |
This list is not guaranteed to be complete. |
| 14 |
|
| 15 |
* Header values which are too long may be truncated. |
| 16 |
|
| 17 |
If a value of a structured header is longer than 256 (MAXNAME) |
| 18 |
characters then it may be truncated during output. For example, |
| 19 |
if a single address in the To: header is longer than 256 characters |
| 20 |
then it will be truncated which may result in a syntactically |
| 21 |
invalid address. |
| 22 |
|
| 23 |
* Delivery to programs that generate too much output may cause problems |
| 24 |
|
| 25 |
If e-mail is delivered to a program which generates too much |
| 26 |
output, then sendmail may issue an error: |
| 27 |
|
| 28 |
timeout waiting for input from local during Draining Input |
| 29 |
|
| 30 |
Make sure that the program does not generate output beyond a |
| 31 |
status message (corresponding to the exit status). This may |
| 32 |
require a wrapper around the actual program to redirect output |
| 33 |
to /dev/null. |
| 34 |
|
| 35 |
Such a problem has been reported for bulk_mailer. |
| 36 |
|
| 37 |
* Null bytes are not handled properly in headers. |
| 38 |
|
| 39 |
Sendmail should handle full binary data. As it stands, it handles |
| 40 |
all values in the body, but not 0x00 in the header. Changing |
| 41 |
this would require a major restructuring of the code -- for |
| 42 |
example, almost no C library support could be used to handle |
| 43 |
strings. |
| 44 |
|
| 45 |
* Header checks are not called if header value is too long or empty. |
| 46 |
|
| 47 |
If the value of a header is longer than 1250 (MAXNAME + MAXATOM - 6) |
| 48 |
characters or it contains a single word longer than 256 (MAXNAME) |
| 49 |
characters then no header check is done even if one is configured for |
| 50 |
the header. |
| 51 |
|
| 52 |
* Header lines which are too long will be split incorrectly. |
| 53 |
|
| 54 |
Header lines which are longer than 2045 characters will be split |
| 55 |
but some characters might be lost. Fix: obey RFC (2)822 and do not |
| 56 |
send lines that are longer than 1000 characters. |
| 57 |
|
| 58 |
* milter communication fails if a single header is larger than 64K. |
| 59 |
|
| 60 |
If a single header is larger than 64KB (which is not possible in the |
| 61 |
default configuration) then it cannot be transferred in one block to |
| 62 |
libmilter and hence the communication fails. This can be avoided by |
| 63 |
increasing the constant MILTER_CHUNK_SIZE in |
| 64 |
include/libmilter/mfdef.h and recompiling sendmail, libmilter, and |
| 65 |
all (statically linked) milters (or by using undocumented compile |
| 66 |
time options: _FFR_MAXDATASIZE/_FFR_MDS_NEGOTIATE; you have to |
| 67 |
read the source code in order to use these properly). |
| 68 |
|
| 69 |
* Sender addresses whose domain part cause a temporary A record lookup |
| 70 |
failure but have a valid MX record will be temporarily rejected in |
| 71 |
the default configuration. Solution: fix the DNS at the sender side. |
| 72 |
If that's not easy to achieve, possible workarounds are: |
| 73 |
- add an entry to the access map: |
| 74 |
dom.ain OK |
| 75 |
- (only for advanced users) replace |
| 76 |
|
| 77 |
# Resolve map (to check if a host exists in check_mail) |
| 78 |
Kresolve host -a<OKR> -T<TEMP> |
| 79 |
|
| 80 |
with |
| 81 |
|
| 82 |
# Resolve map (to check if a host exists in check_mail) |
| 83 |
Kcanon host -a<OKR> -T<TEMP> |
| 84 |
Kdnsmx dns -R MX -a<OKR> -T<TEMP> |
| 85 |
Kresolve sequence dnsmx canon |
| 86 |
|
| 87 |
|
| 88 |
* Duplicate error messages. |
| 89 |
|
| 90 |
Sometimes identical, duplicate error messages can be generated. As |
| 91 |
near as I can tell, this is rare and relatively innocuous. |
| 92 |
|
| 93 |
* Misleading error messages. |
| 94 |
|
| 95 |
If an illegal address is specified on the command line together |
| 96 |
with at least one valid address and PostmasterCopy is set, the |
| 97 |
DSN does not contain the illegal address, but only the valid |
| 98 |
address(es). |
| 99 |
|
| 100 |
* \231 considered harmful. |
| 101 |
|
| 102 |
Header addresses that have the \231 character (and possibly others |
| 103 |
in the range \201 - \237) behave in odd and usually unexpected ways. |
| 104 |
|
| 105 |
* AuthRealm for Cyrus SASL may not work as expected. The man page |
| 106 |
and the actual usage for sasl_server_new() seem to differ. |
| 107 |
Feedback for the "correct" usage is welcome, a patch to match |
| 108 |
the description of the man page is in contrib/AuthRealm.p0. |
| 109 |
|
| 110 |
* accept() problem on SVR4. |
| 111 |
|
| 112 |
Apparently, the sendmail daemon loop (doing accept()s on the network) |
| 113 |
can get into a weird state on SVR4; it starts logging ``SYSERR: |
| 114 |
getrequests: accept: Protocol Error''. The workaround is to kill |
| 115 |
and restart the sendmail daemon. We don't have an SVR4 system at |
| 116 |
Berkeley that carries more than token mail load, so I can't validate |
| 117 |
this. It is likely to be a glitch in the sockets emulation, since |
| 118 |
"Protocol Error" is not possible error code with Berkeley TCP/IP. |
| 119 |
|
| 120 |
I've also had someone report the message ``sendmail: accept: |
| 121 |
SIOCGPGRP failed errno 22'' on an SVR4 system. This message is |
| 122 |
not in the sendmail source code, so I assume it is also a bug |
| 123 |
in the sockets emulation. (Errno 22 is EINVAL "Invalid Argument" |
| 124 |
on all the systems I have available, including Solaris 2.x.) |
| 125 |
Apparently, this problem is due to linking -lc before -lsocket; |
| 126 |
if you are having this problem, check your Makefile. |
| 127 |
|
| 128 |
* accept() problem on Linux. |
| 129 |
|
| 130 |
The accept() in sendmail daemon loop can return ETIMEDOUT. An |
| 131 |
error is reported to syslog: |
| 132 |
|
| 133 |
Jun 9 17:14:12 hostname sendmail[207]: NOQUEUE: SYSERR(root): |
| 134 |
getrequests: accept: Connection timed out |
| 135 |
|
| 136 |
"Connection timed out" is not documented as a valid return from |
| 137 |
accept(2) and this was believed to be a bug in the Linux kernel. |
| 138 |
Later information from the Linux kernel group states that Linux |
| 139 |
2.0 kernels follow RFC1122 while sendmail follows the original BSD |
| 140 |
(now POSIX 1003.1g draft) specification. The 2.1.X and later kernels |
| 141 |
will follow the POSIX draft. |
| 142 |
|
| 143 |
* Excessive mailing list nesting can run out of file descriptors. |
| 144 |
|
| 145 |
If you have a mailing list that includes lots of other mailing |
| 146 |
lists, each of which has a separate owner, you can run out of |
| 147 |
file descriptors. Each mailing list with a separate owner uses |
| 148 |
one open file descriptor (prior to 8.6.6 it was three open |
| 149 |
file descriptors per list). This is particularly egregious if |
| 150 |
you have your connection cache set to be large. |
| 151 |
|
| 152 |
* Connection caching breaks if you pass the port number as an argument. |
| 153 |
|
| 154 |
If you have a definition such as: |
| 155 |
|
| 156 |
Mport, P=[IPC], F=kmDFMuX, S=11/31, R=21, |
| 157 |
M=2100000, T=DNS/RFC822/SMTP, |
| 158 |
A=IPC [127.0.0.1] $h |
| 159 |
|
| 160 |
(i.e., where $h is the port number instead of the host name) the |
| 161 |
connection caching code will break because it won't notice that |
| 162 |
two messages addressed to different ports should use different |
| 163 |
connections. |
| 164 |
|
| 165 |
* ESMTP SIZE underestimates the size of a message |
| 166 |
|
| 167 |
Sendmail makes no allowance for headers that it adds, nor does it |
| 168 |
account for the SMTP on-the-wire \r\n expansion. It probably doesn't |
| 169 |
allow for 8->7 bit MIME conversions either. |
| 170 |
|
| 171 |
* Client ignores SIZE parameter. |
| 172 |
|
| 173 |
When sendmail acts as client and the server specifies a limit |
| 174 |
for the mail size, sendmail will ignore this and try to send the |
| 175 |
mail anyway. The server will usually reject the MAIL command |
| 176 |
which specifies the size of the message and hence this problem |
| 177 |
is not significant. |
| 178 |
|
| 179 |
* Paths to programs being executed and the mode of program files are |
| 180 |
not checked. Essentially, the RunProgramInUnsafeDirPath and |
| 181 |
RunWritableProgram bits in the DontBlameSendmail option are always |
| 182 |
set. This is not a problem if your system is well managed (that is, |
| 183 |
if binaries and system directories are mode 755 instead of something |
| 184 |
foolish like 777). |
| 185 |
|
| 186 |
* 8-bit data in GECOS field |
| 187 |
|
| 188 |
If the GECOS (personal name) information in the passwd file contains |
| 189 |
8-bit characters, those characters can be included in the message |
| 190 |
header, which can cause problems when sending SMTP to hosts that |
| 191 |
only accept 7-bit characters. |
| 192 |
|
| 193 |
* 8->7 bit MIME conversion |
| 194 |
|
| 195 |
When sendmail is doing 8->7 bit MIME conversions, and the message |
| 196 |
contains certain MIME body types that cannot be converted to 7-bit, |
| 197 |
sendmail will pass the message as 8-bit. |
| 198 |
|
| 199 |
* 7->8 bit MIME conversion |
| 200 |
|
| 201 |
If a message that is encoded as 7-bit MIME is converted to 8-bit and |
| 202 |
that message when decoded is illegal (e.g., because of long lines or |
| 203 |
illegal characters), sendmail can produce an illegal message. |
| 204 |
|
| 205 |
* MIME encoded full name phrases in the From: header |
| 206 |
|
| 207 |
If a full name phrase includes characters from MustQuoteChars, sendmail |
| 208 |
will quote the entire full name phrase. If MustQuoteChars includes |
| 209 |
characters which are not special characters according to STD 11 (RFC |
| 210 |
822), this quotation can interfere with MIME encoded full name phrases. |
| 211 |
By default, sendmail includes the single quote character (') in |
| 212 |
MustQuoteChars even though it is not listed as a special character in |
| 213 |
STD 11. |
| 214 |
|
| 215 |
* bestmx map with -z flag truncates the list of MX hosts |
| 216 |
|
| 217 |
A bestmx map configured with the -z flag will truncate the list |
| 218 |
of MX hosts. This prevents creation of strings which are too |
| 219 |
long for ruleset parsing. This can have an adverse effect on the |
| 220 |
relay_based_on_MX feature. |
| 221 |
|
| 222 |
* Saving to ~sender/dead.letter fails if su'ed to root |
| 223 |
|
| 224 |
If ErrorMode is set to print and an error in sending mail occurs, |
| 225 |
the normal action is to print a message to the screen and append |
| 226 |
the message to a dead.letter file in the sender's home directory. |
| 227 |
In the case where the sender is using su to act as root, the file |
| 228 |
safety checks prevent sendmail from saving the dead.letter file |
| 229 |
because the sender's uid and the current real uid do not match. |
| 230 |
|
| 231 |
* Berkeley DB 2.X race condition with fcntl() locking |
| 232 |
|
| 233 |
There is a race condition for Berkeley DB 2.X databases on |
| 234 |
operating systems which use fcntl() style locking, such as |
| 235 |
Solaris. Sendmail locks the map before calling db_open() to |
| 236 |
prevent others from modifying the map while it is being opened. |
| 237 |
Unfortunately, Berkeley DB opens the map, closes it, and then |
| 238 |
reopens it. fcntl() locking drops the lock when any file |
| 239 |
descriptor pointing to the file is closed, even if it is a |
| 240 |
different file descriptor than the one used to initially lock |
| 241 |
the file. As a result there is a possibility that entries in a |
| 242 |
map might not be found during a map rebuild. As a workaround, |
| 243 |
you can use makemap to build a map with a new name and then |
| 244 |
"mv" the new db file to replace the old one. |
| 245 |
|
| 246 |
Sleepycat Software has added code to avoid this race condition to |
| 247 |
Berkeley DB versions after 2.7.5. |
| 248 |
|
| 249 |
* File open timeouts not available on hard mounted NFS file systems |
| 250 |
|
| 251 |
Since SIGALRM does not interrupt an RPC call for hard mounted |
| 252 |
NFS file systems, it is impossible to implement a timeout on a file |
| 253 |
open operation. Therefore, while the NFS server is not responding, |
| 254 |
attempts to open a file on that server will hang. Systems with |
| 255 |
local mail delivery and NFS hard mounted home directories should be |
| 256 |
avoided, as attempts to open the forward files could hang. |
| 257 |
|
| 258 |
* Race condition for delivery to set-user-ID files |
| 259 |
|
| 260 |
Sendmail will deliver to a file if the file is owned by the DefaultUser |
| 261 |
or has the set-user-ID bit set. Unfortunately, some systems clear that bit |
| 262 |
when a file is modified. Sendmail compensates by resetting the file mode |
| 263 |
back to it's original settings. Unfortunately, there's still a |
| 264 |
permission failure race as sendmail checks the permissions before locking |
| 265 |
the file. This is unavoidable as sendmail must verify the file is safe |
| 266 |
to open before opening it. A file can not be locked until it is open. |
| 267 |
|
| 268 |
* MAIL_HUB always takes precedence over LOCAL_RELAY |
| 269 |
|
| 270 |
Despite the information in the documentation, MAIL_HUB ($H) will always |
| 271 |
be used if set instead of LOCAL_RELAY ($R). This will be fixed in a |
| 272 |
future version. |
| 273 |
|
| 274 |
$Revision: 8.61 $, Last updated $Date: 2011-04-07 17:48:23 $ |
