| 1 | |
| 2 | |
| 3 | K N O W N B U G S I N S E N D M A I L |
| 4 | (for 8.6.9) |
| 5 | |
| 6 | |
| 7 | The following are bugs or deficiencies in sendmail that I am aware of |
| 8 | but which have not been fixed in the current release. You probably |
| 9 | want to get the most up to date version of this from FTP.CS.Berkeley.EDU |
| 10 | in /ucb/sendmail/KNOWNBUGS. For descriptions of bugs that have been |
| 11 | fixed, see the file RELEASE_NOTES (in the root directory of the sendmail |
| 12 | distribution). |
| 13 | |
| 14 | This list is not guaranteed to be complete. |
| 15 | |
| 16 | |
| 17 | * Null bytes are not handled properly. |
| 18 | |
| 19 | Sendmail should handle full binary data. As it stands, it handles |
| 20 | any value from 0x01-0xFF in the body and 0x01-0x80 and 0xA0-0xFF in |
| 21 | the header. Notably missing is 0x00, which would require a major |
| 22 | restructuring of the code -- for example, almost no C library support |
| 23 | could be used to handle strings. Fixed (for the message body only) |
| 24 | in 8.7. |
| 25 | |
| 26 | * Duplicate error messages. |
| 27 | |
| 28 | Sometimes identical, duplicate error messages can be generated. As |
| 29 | near as I can tell, this is rare and relatively innocuous. |
| 30 | |
| 31 | * No "exposed users" in "nullrelay" configuration. |
| 32 | |
| 33 | The "nullrelay" configuration hides all addresses behind the mail |
| 34 | hub name. Some sites might prefer to expose some names such as |
| 35 | root. This information is always available in Received: lines. |
| 36 | |
| 37 | * $c (hop count) macro improperly set. |
| 38 | |
| 39 | The $c macro is supposed to contain the current hop count, for use |
| 40 | when calling a mailer. This macro is initialized too early, and |
| 41 | is always zero (or the value of the -c command line flag, if any). |
| 42 | This macro will probably be removed entirely in a future release; |
| 43 | I don't believe there are any mailers left that require it. |
| 44 | |
| 45 | * If you EXPN a list or user that has a program mailer, the output of |
| 46 | EXPN will include ``@local.host.name''. You can't actually mail to |
| 47 | this address. It's not clear what the right behaviour is in this |
| 48 | circumstance. |
| 49 | |
| 50 | * REDIRECT aliases don't work with `n' option. |
| 51 | |
| 52 | If you have option `n' set when you use newaliases and have |
| 53 | REDIRECT addresses in your aliases file, you'll get the error |
| 54 | messages during the newaliases instead of when email is sent to |
| 55 | the address in question. The workaround is to turn off the `n' |
| 56 | option. |
| 57 | |
| 58 | * MX records that point at non-existent hosts work strangly. |
| 59 | |
| 60 | Consider the DNS records: |
| 61 | |
| 62 | hostH MX 1 hostA |
| 63 | MX 2 hostB |
| 64 | hostA A 128.32.8.9 |
| 65 | |
| 66 | (note that there is no A record for hostB). If hostA is down, |
| 67 | an attempt to send to hostH gives "host unknown" -- that is, it |
| 68 | reflects out the status on the last host it tries, which in this |
| 69 | case is hostB, which is unknown. It probably ought to eliminate |
| 70 | hostB early in processing. |
| 71 | |
| 72 | * NAME environment variables with commas and unbalanced quotes break. |
| 73 | |
| 74 | If you define your NAME environment variable to have a comma |
| 75 | (e.g., ``Lastname, Firstname''), and you are using the $q definition |
| 76 | that uses ``name <address>'' format, sendmail treats the first and |
| 77 | last names as two addresses, thus producing a bogus From line. You |
| 78 | can work around this by changing the $q definition to use |
| 79 | ``address (name)''. |
| 80 | |
| 81 | If you have an unbalanced double quote (e.g., ``Firstname"Lastname'') |
| 82 | the auto-quoting algorithm breaks. |
| 83 | |
| 84 | * \231 considered harmful. |
| 85 | |
| 86 | Header addresses that have the \231 character (and possibly others |
| 87 | in the range \201 - \237) behave in odd and usually unexpected ways. |
| 88 | |
| 89 | * DEC Alphas (OSF/1 1.3) sometimes time out on sending mail. |
| 90 | |
| 91 | I have one report that DEC Alphas acting as SMTP clients sometimes |
| 92 | will apparently not see the "250 OK" message in response to the |
| 93 | dot that indicates the end of the message. This only happens if |
| 94 | the message is run from the queue -- if it gets through on first |
| 95 | try, everything is fine. I have been unable to reproduce this |
| 96 | problem at Berkeley. |
| 97 | |
| 98 | * accept() problem on SVR4. |
| 99 | |
| 100 | Apparently, the sendmail daemon loop (doing accept()s on the network) |
| 101 | can get into a wierd state on SVR4; it starts logging ``SYSERR: |
| 102 | getrequests: accept: Protocol Error''. The workaround is to kill |
| 103 | and restart the sendmail daemon. We don't have an SVR4 system at |
| 104 | Berkeley that carries more than token mail load, so I can't validate |
| 105 | this. It is likely to be a glitch in the sockets emulation, since |
| 106 | "Protocol Error" is not possible error code with Berkeley TCP/IP. |
| 107 | |
| 108 | I've also had someone report the message ``sendmail: accept: |
| 109 | SIOCGPGRP failed errno 22'' on an SVR4 system. This message is |
| 110 | not in the sendmail source code, so I assume it is also a bug |
| 111 | in the sockets emulation. (Errno 22 is EINVAL "Invalid Argument" |
| 112 | on all the systems I have available, including Solaris 2.x.) |
| 113 | |
| 114 | * Sending user deletion not done properly in :include: lists. |
| 115 | |
| 116 | If you don't have the "m" (me too) option set, then a person |
| 117 | sending to a list that contains themselves should not get a copy |
| 118 | of the message. However, if that list points to a :include: file |
| 119 | that has one address per line, this will break, and the sender |
| 120 | will always get a copy of their own message, just as though the |
| 121 | "m" option were set. |
| 122 | |
| 123 | You can eliminate this by adding commas at the end of each line |
| 124 | of the :include: file. |
| 125 | |
| 126 | * Excessive mailing list nesting can run out of file descriptors. |
| 127 | |
| 128 | If you have a mailing list that includes lots of other mailing |
| 129 | lists, each of which has a separate owner, you can run out of |
| 130 | file descriptors. Each mailing list with a separate owner uses |
| 131 | one open file descriptor (prior to 8.6.6 it was three open |
| 132 | file descriptors per list). This is particularly egregious if |
| 133 | you have your connection cache set to be large. |
| 134 | |
| 135 | (Version 8.19, last updated %G%) |