MDaemon 26.0.1 — Multiple regressions with IIS integration: stale IMAP.MRK, broken DELETE, autodiscover, theme forcing

• 

  Univac

  5/15/26, 8:08 AM

  EDIT 2026-05-XX: After feedback from MDaemon support, I need to correct
  this post. The issues described below were NOT caused by a regression in
  MDaemon 26.0.1 or 26.0.2. They were caused by an incomplete IIS migration
  that I performed on the same day as the version update. Specifically, I
  followed partial instructions and missed steps like granting IUSR full
  control on the MDaemon directory tree, and configuring the
  MDAutoDiscover.dll / MDDP.dll / MDMgmtws.dll / MDWebDAV.dll handlers.

  The complete and correct procedure is documented at:
  https://knowledge.mdaemon.com/setup-mdaemon-iis

  The only point from the original post that I still believe is worth
  documenting is the WebDAVModule conflict (the IIS built-in one, not
  MDaemon's MDWebDAV.dll), since it can affect anyone using IIS with the
  Pro theme's REST API. MDaemon will update the KB to mention this.

  I'm leaving the original post below for reference and search indexing,
  but please read the corrected version of the story.

   

  Hi everyone,

  After updating to MDaemon 26.0.1 on 2026-05-12, I ran into a
  chain of issues when running Webmail behind IIS instead of using the built-in
  HTTP server. None of them are mentioned in the 26.0.1 changelog, but they
  share a common root cause that I'd like to document here for anyone who hits
  the same wall. A support ticket will be opened.

  Environment
  -----------
  - Windows Server 2019
  - IIS 10 fronting MDaemon Webmail (external webserver mode, not the built-in)
  - MDaemon serving multiple domains
  - Webmail Pro theme as default
  - Many user mailboxes existing before the 26.0.1 update

  Symptoms observed (in chronological order)
  ------------------------------------------
  1. Users reported that Webmail and IMAP clients showed a "frozen" view of
     their inbox — new mail kept arriving (visible as new .msg files on disk
     with current timestamps), but the inbox listing stopped showing anything
     newer than around the time of the update.

  2. The old Webmail themes (WorldClient, LookOut, Lite) became unreachable
     for some users: clicking a folder returned the theme bootstrap HTML which
     force-redirected them back to Pro.

  3. In Pro theme, deleting an email did nothing — the message stayed in the
     folder. In old themes (forced via URL param), delete worked.

  4. Moving an email between folders produced a copy in the destination but
     left the original in place.

  5. The autodiscover endpoint always returned the Webmail login HTML, even
     with proper URL rewrite rules pointing at WorldClient.dll?View=Autodiscover
     or PATHINFO variants.

  Root cause
  ----------
  After a lot of digging, all of these except #5 turned out to be the same
  underlying issue: **after the 26.0.1 update, MDaemon (running through the
  IIS ISAPI extension) writes to mailbox files under the IUSR security
  context**. Files and folders that existed BEFORE the update don't have IUSR
  in their ACL, so MDaemon silently fails to write/delete them. New files
  created after the update inherit IUSR correctly from the parent directory's
  ACL and work fine.

  What this breaks in practice:
  - Messages.MRK and IMAP.MRK can't be updated → index frozen → Webmail/IMAP
    show stale listings.
  - .msg files can't be deleted → "move" leaves the original behind, "delete"
    is a no-op.

  You can verify this by comparing the ACL of an old IMAP.MRK against one
  that MDaemon recreated after the update — the recreated one has IUSR with
  FullControl, the older ones don't.

  How I fixed it
  --------------
  Applied "Modify" permission for IUSR, with full inheritance (Container +
  Object), to the roots of the mailbox storage (in my case C:\MDaemon\Users
  and a secondary location). Did it from Windows Explorer's Security tab and
  let it propagate to all subfolders and files. Then for any subdirectories
  that had explicit ACLs blocking inheritance, ran:

      icacls "C:\MDaemon\Users" /inheritance:e /T /Q

  After this, the index updates resumed automatically, deletes started
  working, and moves no longer left orphans.

  Separate issue: DELETE verb intercepted by WebDAV
  -------------------------------------------------
  On top of the permission fix, the Pro theme's new REST API uses HTTP
  DELETE verbs (e.g. DELETE /WorldClientAPI/messages/13/message/ids?...).
  With WebDAVModule enabled at the IIS server level (inherited by the site),
  those DELETE requests get swallowed by WebDAV before reaching
  WorldClient.dll. Old themes use plain POSTs so they were unaffected.

  Fix: in the site's web.config, add to <system.webServer>:

      <modules>
        <remove name="WebDAVModule" />
      </modules>
      <handlers>
        <remove name="WebDAV" />
      </handlers>

   

  If WebDAV is locked at the server level, run once as administrator:

      appcmd unlock config -section:system.webServer/modules

  Separate issue: theme forcing for users without explicit preference
  -------------------------------------------------------------------
  Inside each user's mailbox folder there's a WC\User.ini with a [user]
  section. If it has Theme=<something>, that value is used. If it doesn't,
  the global Webmail default theme is applied. After the update some users
  ended up locked to Pro because Pro was set as the global default and they
  had no Theme= line in their User.ini.

  Fix: either set the global default to a sensible theme, or add explicit
  Theme= lines per user via the GUI.

  Separate issue: autodiscover endpoint
  -------------------------------------
  Out of the box, hitting
      https://autodiscover.<domain>/autodiscover/autodiscover.xml
  returns the Webmail login HTML. None of the URL Rewrite variants I tried
  (WorldClient.dll?View=Autodiscover, PATHINFO with
  WorldClient.dll/autodiscover/autodiscover.xml, etc.) produced an XML
  response from MDaemon. The "AutoDiscovery Service" shown in the MDaemon
  GUI is enabled, but MDaemon.exe doesn't listen on any HTTP port for it
  (I checked with Get-NetTCPConnection — only the mail ports are bound).

  Workaround that works perfectly: serve a tiny static autodiscover.php
  under C:\MDaemon\WorldClient\HTML\autodiscover\, rewrite the .xml URL to
  .php in IIS, and let PHP handle the POST. The XML response is the same
  for every user (server names, ports, SSL settings), which is fine for
  autodiscover. The optional bit is parsing the EMailAddress out of the
  request body to fill in <LoginName> and <DisplayName>.

  Full web.config that ended up working
  -------------------------------------

  <?xml version="1.0" encoding="UTF-8"?>
  <configuration>
      <system.webServer>
          <defaultDocument>
              <files>
                  <clear />
                  <add value="WorldClient.dll" />
              </files>
          </defaultDocument>
          <modules>
              <remove name="WebDAVModule" />
          </modules>
          <handlers accessPolicy="Read, Execute, Script">
              <remove name="WebDAV" />
              <remove name="WorldClient-ISAPI" />
              <add name="WorldClient-ISAPI" path="WorldClient.dll" verb="*" modules="IsapiModule" scriptProcessor="C:\MDaemon\WorldClient\HTML\WorldClient.dll" resourceType="File" requireAccess="Execute" allowPathInfo="true" />
          </handlers>
          <security>
              <requestFiltering>
                  <verbs allowUnlisted="true">
                      <add verb="DELETE" allowed="true" />
                      <add verb="PUT" allowed="true" />
                      <add verb="PATCH" allowed="true" />
                  </verbs>
              </requestFiltering>
          </security>
          <rewrite>
              <rules>
                  <rule name="Static Assets" stopProcessing="true">
                      <match url="^webmail/.*" />
                      <conditions>
                          <add input="{REQUEST_FILENAME}" matchType="IsFile" />
                      </conditions>
                      <action type="None" />
                  </rule>
                  <rule name="Autodiscover" stopProcessing="true">
                      <match url="^autodiscover/autodiscover\.xml$" ignoreCase="true" />
                      <action type="Rewrite" url="autodiscover/autodiscover.php" />
                  </rule>
                  <rule name="WorldClientAPI" stopProcessing="true">
                      <match url="^WorldClientAPI/(.*)" />
                      <action type="Rewrite" url="WorldClient.dll/WorldClientAPI/{R:1}" appendQueryString="true" />
                  </rule>
                  <rule name="WorldClient Webmail SPA" stopProcessing="true">
                      <match url="^webmail/(.*)" />
                      <conditions logicalGrouping="MatchAll">
                          <add input="{REQUEST_FILENAME}" matchType="IsFile" negate="true" />
                      </conditions>
                      <action type="Rewrite" url="/webmail/index.html" />
                  </rule>
              </rules>
          </rewrite>
          <staticContent>
              <mimeMap fileExtension="." mimeType="text/plain" />
          </staticContent>
      </system.webServer>
  </configuration>

  DNS side: add per-domain SRV records pointing to your shared endpoint:

      _autodiscover._tcp.<domain>.   IN SRV 0 0 443 autodiscover.inforbaix.com.

  (Note the trailing dot — without it the target becomes relative to the
  zone's $ORIGIN and breaks silently.)

  This way clients querying autodiscover for any of the served domains get
  redirected to a single endpoint with a single SSL certificate.

  Why this matters
  ----------------
  None of this is documented in the 26.0.1 changelog. Each symptom in
  isolation looks like a different problem, and admins hitting one of them
  will likely waste hours assuming it's a configuration issue on their side
  rather than a regression introduced by the update.

  If anyone from MDaemon Technologies is reading: I'd love to see either
  a fix that handles the permission migration during the installer, or at
  least a KB article warning admins to apply IUSR to pre-existing mailbox
  directories before updating.

  Happy to share more detail (logs, ACL captures, web.config) if useful.
  Hopefully this saves someone the week I spent on it.

  Cheers,
  Luis

  0 likes 0 likes Liked Like

  ---

  3
  Posts

  41
  Views

  Reply

  ---

• A

  Arron Admin Staff

  5/18/26, 8:07 AM

  Thank you for the detailed issue report, it is greatly appreciated.  

  What version were you running prior to MDaemon 26.0.1?  

  Do you recall what instructions you used for configuring Webmail to run under IIS?

  Here is our current KB articles for configuring IIS.

  https://knowledge.mdaemon.com/setup-mdaemon-iis

  https://knowledge.mdaemon.com/mdaemon-19.5-and-above-how-to-use-the-mobile-theme-when-running-webmail-in-iis

  after the 26.0.1 update, MDaemon (running through the
  IIS ISAPI extension) writes to mailbox files under the IUSR security
  context**. Files and folders that existed BEFORE the update don't have IUSR
  in their ACL, so MDaemon silently fails to write/delete them. New files
  created after the update inherit IUSR correctly from the parent directory's
  ACL and work fine.

  I am not aware of any changes that we made to alter how MSG files are written to mailbox. MDaemon.exe typically runs as a service, which by default runs as local system.  MDaemon does not impersonate a different user when writing out files.  

  Also, our current instructions for setting up IIS include steps for allowing IUSR full control of the MDaemon directory structure.

  the Pro theme's new REST API uses HTTP
  DELETE verbs (e.g. DELETE /WorldClientAPI/messages/13/message/ids?...).
  With WebDAVModule enabled at the IIS server level (inherited by the site),
  those DELETE requests get swallowed by WebDAV before reaching
  WorldClient.dll. 

  Thanks for letting us know.  I'll see about updating our documentation to advise user's to not enable the WebDAVModule in IIS.

  theme forcing for users without explicit preference

  I have not been able to reproduce this yet. In your MDaemon\WorldClient\Domains.ini file, what sections do you have the Theme key set in? The UserOverrides sections can force a user to use a configured setting and may be contributing to the behavior you are seeing. Can you upload a copy of your MDaemon\WorldClient\Domains.ini file so that I can do additional testing?  You can upload it to https://mdaemon.sharefile.com/r-rc3922c1eed334d4dbf5e34f0bd04ccd6

  Out of the box, hitting
      https://autodiscover.<domain>/autodiscover/autodiscover.xml
  returns the Webmail login HTML. None of the URL Rewrite variants I tried
  (WorldClient.dll?View=Autodiscover, PATHINFO with
  WorldClient.dll/autodiscover/autodiscover.xml, etc.) produced an XML
  response from MDaemon. 

  Did you configure a handler mapping in IIS for AutoDiscover?  The handler mapping in IIS should redirect the reqeusts to the MDaemon\WorldClient\HTML\MDAutoDiscover.dll full instructions are available in our knowledgebase article.  You also need to configure the MDDP handler mapping as described in the knowledgebase article.  

  The "AutoDiscovery Service" shown in the MDaemon
  GUI is enabled, but MDaemon.exe doesn't listen on any HTTP port for it
  (I checked with Get-NetTCPConnection — only the mail ports are bound).

  MDaemon.exe does not listen on the HTTP ports.  If you use the built in webserver it listens on the HTTP ports that are configured.  If you are using IIS, it listens on the HTTP ports and needs to be configured to route AutoDiscover requests correctly.  

  None of this is documented in the 26.0.1 changelog. Each symptom in
  isolation looks like a different problem, and admins hitting one of them
  will likely waste hours assuming it's a configuration issue on their side
  rather than a regression introduced by the update.

  If anyone from MDaemon Technologies is reading: I'd love to see either
  a fix that handles the permission migration during the installer, or at
  least a KB article warning admins to apply IUSR to pre-existing mailbox
  directories before updating.

  Happy to share more detail (logs, ACL captures, web.config) if useful.
  Hopefully this saves someone the week I spent on it.

  To summarize, we need to investigate the issue with user's being forced to the PRO theme and figure out what is happening, a copy of your domains.ini file will help us to do that. You can upload it to https://mdaemon.sharefile.com/r-rc3922c1eed334d4dbf5e34f0bd04ccd6.  For the other issues, I don't see any changes in our source code that would have caused them.

  --
  Arron Caruth

  0 likes 0 likes Liked Like

  ---

• 

  Univac

  5/18/26, 11:49 AM

  Hi @Arron,

  Thank you for the very thorough response. After reading your reply and
  re-examining my own timeline, I owe you a correction.

  The story is actually this:

  - I was on MDaemon 26.0.0 with the built-in webserver on port 3000.
  - On 2026-05-12 I did two things on the same day: updated to 26.0.1, and migrated Webmail to run under IIS for the first time.
  - My IIS configuration was based on partial instructions, not the full
    current KB article. In particular I missed:
      * NTFS permissions for IUSR on the MDaemon directory tree
      * Handler mappings for MDAutoDiscover.dll, MDDP.dll, MDMgmtws.dll,
        MDAirSync.dll and MDWebDAV.dll
      * Several of the security headers and HSTS configuration

  So this was NOT a regression introduced by 26.0.1 or 26.0.2. It was a
  migration to IIS done with incomplete documentation. The HTTP-side identity
  changed from LocalSystem (built-in webserver running as a child of the
  MDaemon service) to IUSR (IIS), and the existing .MRK / .msg files didn't
  have IUSR in their ACL because they had been created over the years under
  LocalSystem. The fact that it coincided with the version update was pure
  timing — both things happened on the same day.

  I apologize for framing my original forum post as a regression. It wasn't.
  It was my own incomplete migration. Your guide was correct; I just didn't
  follow all of it.

  That said, a couple of things from the original report still stand and might
  be useful as documentation improvements:

  - The IIS built-in WebDAVModule (not your MDWebDAV.dll, which is a separate
    legitimate handler) intercepts the DELETE/MOVE verbs that the Pro theme's
    REST API uses. As you already noted, mentioning this in the KB would save
    others from hitting the same wall.

  - About the theme-forcing issue: I'm uploading my Domains.ini to the
    ShareFile link now. Before doing so I checked it myself and I want to
    share what I found, in case it helps:

      * There is no [Default:UserOverrides] section forcing any theme — that
        section only contains "_Exists=1".
      * No per-domain :UserOverrides section sets Theme either.
      * The only Theme= lines in the entire file are inside :UserDefaults
        sections (one global, a handful per-domain), all set to either
        WorldClient or LookOut. None of them are set to Pro.

    Here's what I think happened: the global [Default:UserDefaults] used to
    have Theme=Pro at the time the symptoms appeared. I changed it to
    WorldClient as part of my troubleshooting (because some users with no
    per-account Theme key in their WC\User.ini were ending up on Pro and
    hitting the issues described in the original post). After that change,
    the forced-Pro behavior stopped.

    So the file you'll see is the "after" state. The "before" state had
    Theme=Pro in [Default:UserDefaults] and no per-account Theme override
    for the affected users. From what I observed, this is consistent with
    the normal inheritance behavior (no override → fall back to global
    default → Pro at that time), but I can't tell from my side whether
    there was anything else amplifying it, which is why I'm flagging it.
    If you want to test against the exact configuration that produced the
    symptom, just temporarily set [Default:UserDefaults] Theme=Pro on a
    test setup and try logging in as a user whose WC\User.ini has no
    [user] Theme= line.

  - I will now go through the full setup-mdaemon-iis KB article and apply
    the steps I had missed, particularly the MDAutoDiscover.dll and MDDP.dll
    handlers. That will let me remove the autodiscover.php workaround I had
    to set up. I'll report back if anything doesn't work as expected.

  Thanks again for your patience. I'll edit my forum post to reflect this
  corrected story so it doesn't mislead future readers.

  Best regards,
  Luis

  0 likes 0 likes Liked Like

  ---