I’ve heard various opinions on what to do with an MDaemon account belonging to someone who has left a company. In a recent post on our community forums, an MDaemon administrator had set a former employee’s account to Frozen, and then configured an auto-responder for the account. Frozen accounts cannot send outbound email, and the user of a frozen account cannot check for new email.
Account is FROZEN (can receive but cannot send or check email)
Select this option if you wish to allow the account to receive incoming messages but prevent it from being able to check or send messages. This is useful when, for example, you suspect the account has been hijacked. Freezing the account would prevent the malicious user from accessing its messages or using the account to send messages, but it would still be able to receive its incoming email.
The result of this is that auto-response messages from frozen accounts to external (non-local) addresses are sent to the Holding queue (more information on the Holding queue can be found here).
Let’s take a closer look at what happens.
Let’s say an employee has left the company. As the MDaemon administrator, I don’t want that employee’s account to be used, so I place it in Frozen status via the main Account Details screen of the account editor, as shown here.
Now let’s say I’ve enabled an auto-responder for the account, as shown here.
In the following example, I’ve created the account firstname.lastname@example.org, and have configured the auto-responder.
When I send a test to email@example.com from firstname.lastname@example.org, the MDaemon server hosting the @brad.ssllock.com domain places the message in the frozen account’s mailbox, but the user is unable to log into webmail or access the inbox via another email client. When MDaemon then tries to send the auto-responder that we enabled for the frozen account, the message is moved to the Holding queue and the following is written to the MDaemon logs:
Mon 2018-06-18 11:18:33.406: Session 042192; child 0001
Mon 2018-06-18 11:18:33.406: Parsing message <c:\mdaemon\queues\remote\pd50000000056.msg>
Mon 2018-06-18 11:18:33.406: * From: email@example.com
Mon 2018-06-18 11:18:33.406: * To: Training@mdaemon.com
Mon 2018-06-18 11:18:33.406: * Subject: RE: Test to Frozen Account with Auto-Responder
Mon 2018-06-18 11:18:33.406: * Size (bytes): 3822
Mon 2018-06-18 11:18:33.406: * Message-ID: MDAEMON0005201806181118.AA1812640@mail.brad.ssllock.com
Mon 2018-06-18 11:18:33.421: Message moved to holding queue because sending account is disabled
Mon 2018-06-18 11:18:33.421: SMTP session terminated (Bytes in/out: 0/0)
Mon 2018-06-18 11:18:33.421: ———-
The result is that the auto-response never gets sent because the account is frozen.
Rather than freezing the account, you could simply change the account’s password so that it can still accept mail and send auto-response messages. This can be done via the main Account Details screen, as shown here.
If you prefer to freeze the account instead of changing its password, another option would be to create a content filter rule that would send your desired response to the original message sender instead of using the auto-responder. That content filter rule would look something like this:
In this example, I created a rule that sends a reply to the sender of messages addressed to firstname.lastname@example.org using the “Send a NOTE 1” action. I then entered the $SENDER$ macro and the desired response. This message will be sent back to the message sender in response to a message originally sent to the frozen account.
You can get pretty creative with MDaemon’s content filter to perform a variety of tasks, so hopefully you found this helpful!