This list is not exhaustive. It is intended to highlight major bugs in the version you are using, to help you to decide if you should upgrade. Most bugs even if very serious only affect systems with a particular setup, so mostly it is quite safe to keep using a version with known bugs.
Known Unexpected behaviour of DMail
These are things that you might expect to work but don't.
Current Beta Version (2.8z5), (implies not yet fixed in any version on site)
Current Release Version: (2.7q and 2.7r) (implies fixed in current beta)
Previous Release Version: (2.5g) (implies fixed in current beta)
Recent Beta/Release Versions: (most customers wont have seen many of these beta versions)
fatal bug when invalid destination syntax
Consequences: DSMTP dies, and if message makes it into queue files then
DSMTP dies every time the message comes up for delivery - yes very bad!
Setup: independent
Found in: all versions before 2.5h, but 2.5k is the current version to replace with.
Details: If a message arrives addressed with a strange syntax DSMTP dies. You have to delete the
offending q_ file from the work_path directory to stop DSMTP from dieing.
You should upgrade to version 2.4k
RH6 (and above) Linux box hangs on startup after installing DMail
Consequences:your Red Hat 6 or above box freezes at the point where sendmail is
starting.
Setup:independent
Found in:(all versions before 2.5k when installed on Red Hat 6 and above)
Details:The startup script for sendmail changed in Red Hat 6 distributions and
unfortunately our 'sendmail stub' does not handle the new way in which it is called.
To get going again, reboot your machine. At the lilo prompt enter,
You should either upgrade to version 2.5k or download the
sendmail stub
for linux_libc6 and replace,
fromip_max handle leak
Consequences:handle leak results in DSMTP not being able to open .tmp
files in the work area.
Setup:setting fromip_max turned on, and limit reached regularly (possibly
only on windows platforms).
Found in:(all versions before 2.5i)
Details:DSMTP stops responding to any TCPIP connections as it has run out of file
handles. The log is generally full of messages stating that .tmp and other files in the
work area could not be opened for strange reasons.
NWAuth loosing user accounts
Consequences:
Setup:Using external authentication with the option of NWAuth. More than one
user being added at a time by any of NWAuth wadduser or NetAuth.
Found in:(all versions before 2.5i)
Details:newer versions of NWAuth (with DMail versions 2.4f and above) operate
with two user data files, nwauth.txt and nwauth.add, instead of just nwauth.txt. The .add
file is used to change entries in the user database without requiring a re-read of the
entire nwauth.txt file (which is one line per user). Every time a user is added the .add file
is checked to see if it is above the 'rebuild file size' (3kbytes by default). If it is then
NWAuth re-writes nwauth.txt and deletes nwauth.add.
The problem arises when more than one NWAuth (or wadduser) tries to add a user at the same
time and the nwauth.txt file is re-written by both of them. There is the potential to loose a
section or all of the nwauth.txt file. This is a rare occurrence on most systems.
Domain Aliases
Consequences: DSMTP does lookup of username@alias_for_domain instead of username@main_domain
Setup: External Authentication and authent_domain set to true and multiple host_domain
settings (aliases for your main domain).
Found in: All versions up to 2.5g
Details:
With these settings in dmail.conf,
(where the first host_domain setting is defined to be the main
domain and the rest aliases for it)
If a message comes in to DSMTP for local delivery to the user,
The problem with this is that in nwauth.txt (or nwauth.add) the
admin will have only added the user,
How does DPOP handle it?
DPOP has its own dpop_host setting so it ignores all host_domain
settings (so does not know, and does not need to know, about the
domain aliases) and always looks up tam@h_domain.com. Note: this can
cause a problem if the dpop_host setting is set to something
different from the first host_domain setting.
Aliases and Forward rules causing delivery to wrong domain
Consequences: DSMTP writes incoming messages to drop file in wrong domains directory.
Setup: External Authentication AND authent_domain set to false AND aliases or
forward rules to multiple local destinations on different domains (drop_prefix false might
make the consequences worse).
Found in: all versions that handle such aliases up to 2.5g
Details:
If there are two destinations for an alias and each destination requires an external
authentication lookup. Then if the destinations are on separate domains DSMTP will probably
think that both drop files belong in the second domain's drop file path. If drop_prefix is
set to true (the default) then drop files from separate domains will have different prefixes
so the error will be obvious when looking in the drop directories. If drop_prefix is false
then users with the same username on different domains could get the incorrect mail!
NB: this is an bug unreported by any of our customers.
MAC/OSX installs incorrect startup script (2.5k onwards)
Consequences:On reboot DMail does not start itself up
Setup:N/A
Found in:2.5k and above - hope to have this fixed in version 2.7c
Details:The installation utility installs a startup script for DMail in /etc/rc.d/init.d
on UNIX platforms, unfortunately this is not a valid path on MAC/OSX.
See the note on this in this section, Startup Scripts or
contact DMail Support.
linux single
so that it is started in single user mode. Then once it has started rename,
/etc/rc.d/init.d/sendmail /etc/rc.d/init.d/sendmail.not
and reboot your machine as normal.
/usr/sbin/sendmail
with it. (NB: on some platforms you also have to replace, /usr/lib/sendmail if it is not a
link).
host_domain h_domain.com
host_domain alias_domain.com
authent_domain true
dpop_host h_domain.com
bob@alias_domain.com
then DSMTP sends the following line to the external authentication,
lookup bob@alias_domain.com
bob@h_domain.com