132 lines
5.3 KiB
Plaintext
132 lines
5.3 KiB
Plaintext
|
|
|
|
K N O W N B U G S I N S E N D M A I L
|
|
(for 8.6.7)
|
|
|
|
|
|
The following are bugs or deficiencies in sendmail that I am 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.CS.Berkeley.EDU
|
|
in /ucb/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.
|
|
|
|
|
|
* Null bytes are not handled properly.
|
|
|
|
Sendmail should handle full binary data. As it stands, it handles
|
|
any value from 0x01-0xFF in the body and 0x01-0x80 and 0xA0-0xFF in
|
|
the header. Notably missing is 0x00, which would require a major
|
|
restructuring of the code -- for example, almost no C library support
|
|
could be used to handle strings.
|
|
|
|
* Duplicate error messages.
|
|
|
|
Sometimes identical, duplicate error messages can be generated. As
|
|
near as I can tell, this is rare and relatively innocuous.
|
|
|
|
* No "exposed users" in "nullrelay" configuration.
|
|
|
|
The "nullrelay" configuration hides all addresses behind the mail
|
|
hub name. Some sites might prefer to expose some names such as
|
|
root. This information is always available in Received: lines.
|
|
|
|
* $c (hop count) macro improperly set.
|
|
|
|
The $c macro is supposed to contain the current hop count, for use
|
|
when calling a mailer. This macro is initialized too early, and
|
|
is always zero (or the value of the -c command line flag, if any).
|
|
This macro will probably be removed entirely in a future release;
|
|
I don't believe there are any mailers left that require it.
|
|
|
|
* If you EXPN a list or user that has a program mailer, the output of
|
|
EXPN will include ``@local.host.name''. You can't actually mail to
|
|
this address. It's not clear what the right behaviour is in this
|
|
circumstance.
|
|
|
|
* REDIRECT aliases don't work with `n' option.
|
|
|
|
If you have option `n' set when you use newaliases and have
|
|
REDIRECT addresses in your aliases file, you'll get the error
|
|
messages during the newaliases instead of when email is sent to
|
|
the address in question. The workaround is to turn off the `n'
|
|
option.
|
|
|
|
* MX records that point at non-existent hosts work strangly.
|
|
|
|
Consider the DNS records:
|
|
|
|
hostH MX 1 hostA
|
|
MX 2 hostB
|
|
hostA A 128.32.8.9
|
|
|
|
(note that there is no A record for hostB). If hostA is down,
|
|
an attempt to send to hostH gives "host unknown" -- that is, it
|
|
reflects out the status on the last host it tries, which in this
|
|
case is hostB, which is unknown. It probably ought to eliminate
|
|
hostB early in processing.
|
|
|
|
* NAME environment variables with commas break.
|
|
|
|
If you define your NAME environment variable to have a comma
|
|
(e.g., ``Lastname, Firstname''), and you are using the $q definition
|
|
that uses ``name <address>'' format, sendmail treats the first and
|
|
last names as two addresses, thus producing a bogus From line. You
|
|
can work around this by changing the $q definition to use
|
|
``address (name)''.
|
|
|
|
* \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.
|
|
|
|
* DEC Alphas (OSF/1 1.3) sometimes time out on sending mail.
|
|
|
|
I have one report that DEC Alphas acting as SMTP clients sometimes
|
|
will apparently not see the "250 OK" message in response to the
|
|
dot that indicates the end of the message. This only happens if
|
|
the message is run from the queue -- if it gets through on first
|
|
try, everything is fine. I have been unable to reproduce this
|
|
problem at Berkeley.
|
|
|
|
* accept() problem on SVR4.
|
|
|
|
Apparently, the sendmail daemon loop (doing accept()s on the network)
|
|
can get into a wierd 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.)
|
|
|
|
* Sending user deletion not done properly in :include: lists.
|
|
|
|
If you don't have the "m" (me too) option set, then a person
|
|
sending to a list that contains themselves should not get a copy
|
|
of the message. However, if that list points to a :include: file
|
|
that has one address per line, this will break, and the sender
|
|
will always get a copy of their own message, just as though the
|
|
"m" option were set.
|
|
|
|
You can eliminate this by adding commas at the end of each line
|
|
of the :include: file.
|
|
|
|
* 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.
|
|
|
|
(Version 8.18, last updated 3/14/94)
|