Known Bugs in Current and Recent Versions of DMail

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.


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,
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.

You should either upgrade to version 2.5k or download the sendmail stub for linux_libc6 and replace,
with it. (NB: on some platforms you also have to replace, /usr/lib/sendmail if it is not a link).

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


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


With these settings in dmail.conf,
authent_domain true


(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,
then DSMTP sends the following line to the external authentication,

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 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


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


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.

Check_gid defaulted to 'false' rather than no setting

Consequences:Users get error message about problem with their drop file.

Setup:UNIX platforms only.

Found in:(2.7a - 2.7d)

Details:Fixed default for check_gid to no group. It was 'false' when the setting takes a group name. This means that DPOP would not allow access to drop file once it had something in it because gid of drop file will never match 'false'. Hence users will get a message saying that there was a problem with their drop file.