config.xml

Posted on November 14, 2008
Filed Under Outlook Connector | Leave a Comment

The config.xml file stores a number of Outlook Connector related account settings. This file is not formally documented, but since it’s in XML format, most of the items are self-explanatory. Here is a breakdown of the options.

Whether or not you use a custom localcache.db location.

0 - Use default location
1 - Use custom location

If you use a custom localcache.db location, this is the location where it is stored.

Whether or not to send a return-receipt when requested.  You can use any number from 0-2, with the following meanings:

0 - Always send a response
1 - Never send a response
2 - Poompt me before sending a response

Timeout in seconds for socket communication.  I’m not sure if it’s just for IMAP or also for SMTP.  The default is 0, which means use the default OS behavior (which I think is no timeout).  There is no GUI for this setting.

Outlook 2000 does not have a built-in automatic send/receive ability, so OC provides one.  These settings are for whether it’s enabled, and how much time (in minutes) to wait between them.  These settings can be set in the GUI on Outlook 2000.  It is not used in other versions of Outlook.

Whether or not to show a progress indicator dialog when loading messages.

0 - Show no dialog
1 - Show the dialog

If you are showing a progress indicator, this setting controls how many messages need to be queued for Outlook Connector to show a progress indicator as messages are being downloaded.

This controls what name appears in the “root” of the mailbox in Outlook.  This is especially useful if you have multiple accounts and want to easily tell them apart.  This is available in the GUI.

The IMAP server hostname and port number.

Whether or not to use SSL for IMAP sessions.

0 - Don’t use SSL
1 - Require SSL.

The email address Outlook Connector uses in the From field (and possibly other places internally)

Your “organization” is sent along with email you send.

This is the name displayed in the From field (And possibly other places internally)

The IMAP username and password.  Note that the password field is encrypted using reversable encryption, which means that although it’s not visible here, it’s possible a skilled attacker could recover the password.

Outlook Connector can optionally save passwords between sessions.

0 - Ask for the password each session.
1 - Remember the password

The SMTP server hostname and port number.  Typical options are:

25 - The default
366 - One of MDaemon’s alternate SMTP ports (ODMR)
587 - Another of MDaemon’s alternate SMTP ports (MSA, requires AUTH)
995 - Dedicated SSL port.

SMTP server SSL settings.  Set both to zero to not use SSL at all, set “UseOutgoingSSL” to 1 to use a dedicated SSL port (995).  Set “UseSMTP_TLS” to 1 to connect with an unencrypted session and switch over to SSL using the STARTTLS command.

Use the IMAP authentication information for SMTP as well.

0 - SMTP uses it’s own authentication information
1 - SMTP uses the IMAP authentication information.

This switch controls whether or not SMTP authentication is required.

SMTP username and password, if you are using custom SMTP authentication information.   If <UseIMAPAuthForSMTP> is set to 1, these fields are ignored.

Outlook Connector can optionally save passwords between sessions.

0 - Ask for the password each session.
1 - Remember the password Ignored if you are using your IMAP password.

Override custom language and use English names for the built-in folders (Inbox, Contacts, Calendar, Tasks, Journal, Notes, Deleted Items, Sent Items, etc)

Whether to show all folders, or only IMAP subscribed folders.  Note that you cannot hide the built-in folders.

0 - Show only subscribed folders.
1 - Show all folders.

Controls whether you want to send/receive all folders, or only selected folders.

0 - Only selected folders
1 - All Folders

Note: All folders will be synchronized when accessed, this only changes the behaviour of the Send/Receive Mail feature in Outlook (whether by manual mail check, or scheduled check)

This is a binary field and defined, it controls which folders will be checked for new mail.

Although this field is not documented, you can copy it from one machine to another if the folder list is identical.  This is useful for an initial deployment, when you want many folders synchronized regularly.

This setting tells Outlook Connector whether or not to download full message bodies, including attachments, when they are first downloaded from the server.

0 - Download entire messages, including attachments, as soon as they are discovered.
1 - Download headers immediately, only download message bodies as they are needed.

Note that Offline users will probably want to download entire messages.  However, downloading entire messages will result in a significantly larger database if your users have mail they don’t open (for example, mail already stored on the server before Outlook Connector was set up)

This controls whether Outlook Connector will leave the IMAP connection open at all times, or open and close connections repeatedly.

0 - Close the connection when not in use.
1 - Leave the connection open.

Note that you’ll nearly always want to leave this at 1, setting this to 0 will actually create more load on the server, as well as cause user delays.  IMAP was designed to leave connections open for an extended period of time.

Outlook Connector can create a backup copy of LocalCache.db at shutdown.  This functionality was added a long time ago and has never been tested by Alt-N, so I don’t know if it works or not.  There is no GUI for these settings.  Also note that it does not backup the attachments folder, and that restoring will cause data to get out of sync.

LastBackup - Timestamp of when the last backup happened.
BackupEverySession - Backup every time outlook closes?
DaysBetweenBackupProgression - How many days between backups, if not backing up every session.
NumberOfBackups - How many backups to create.  0 (the default) = none.

I don’t know what the filenames of the backups would be or where they are stored. If you use this feature, please don’t file bug reports with Alt-N, this is entirely undocumented, unsupported, and due to the inconsistent state your attachments folder will be left in, it’s probably going to cause more problems then you think it might solve.

Tags: , ,

Related posts

Understanding POP3 mail client duplicates

Posted on October 13, 2008
Filed Under MDaemon | Leave a Comment

Duplicates are an annoying, but altogether not infrequent side-effect of the POP3 protocol — Lets discuss how and why they occur.

Avoiding duplicates is fairly easy, but unfortunately many many clients fail to implement a robust algorithm, resulting in the potential for duplicates nearly any time something unexpected happens, be it a timeout, client crash, internet connection disconnect, server shutdown, or other unexpected incident.

A bit of background, each time a POP3 client connects to the server, the POP3 client knows only the number of messages available, and the total size of those messages.

Mail clients download one message at a time using a number assigned to each message. However, there is no guarantee that the order of messages will be consistent from one session to another, especially if messages have been added or deleted.  As a result, there is a tendency among mail client authors to just download everything, rather then going through the slightly more complex process of determining which messages are actually new, and which are not.

There are three POP3 commands a client can try to keep track of what messages it has downloaded, HEAD, LAST and UIDL.

HEAD downloads the entire headers of a single message at a time, which is usually enough information for a mail client to determine whether or not it has seen a message before. However, this is a very wasteful technique, especially on an even remotely large mailbox.

Next up is the LAST command. This was once popular, but today I am only aware of a couple mail clients that still use it. The LAST command allows a client to track the last message downloaded.

Internally in MDaemon, LAST remembers the filename of the latest message which was downloaded, and will figure out the appropriate message number each time the command is called. This feature is interesting in that it can help one mail client know if another mail client has already downloaded a message, while still leaving mail on the server. Not many clients actually use this functionality though.

The third, and most popular is the UIDL command. Today, most clients use UIDL, which looks something like this:

UIDL
+OK
1 MD50000012441:MSG:6068:29885722:921102544
2 MD50000012442:MSG:3146:29885724:646725136
3 MD50000012453:MSG:2802:29885951:1370435200
4 MD50000012454:MSG:9389:29885960:885815424
.

The UIDL command lists each message by number followed by a string which is guaranteed to not change between sessions. This allows the mail client to build an index of messages and easily determine which are new, and which were seen before.

MDaemon constructs the UIDL results using the message name, date stamp, size, and a few other details about the messages. As a result, if a message is modified on the server, it will appear as “new” to mail clients even if you don’t rename it.

Armed with an index of messages, it is then up to the client to track which messages it has seen before and which it has not.

So, how does a mail client avoid duplicates? Well, it’s actually pretty simple. Before downloading any messages, issue a UIDL command and note each message in a local index. This data should be maintained even after a mail client has attempted to delete a message, at least until the client has established another POP3 session to confirm the messages were actually deleted.

So you may be asking yourself why any of this is an issue at all, why not just delete messages as soon as they’re downloaded?

Well, most clients do, if you look at the logs you’ll often see a DELE command after each message is downloaded. However, if the POP3 session ends in any method other then the client issuing a QUIT command, the POP3 protocol requires the mail server to leave the mailbox in it’s original state. This means that when a session disconnects unexpectedly, half-deleted messages are not actually removed, and instead are still waiting on the server for the next time a POP3 client connects.

As it turns out, in many modern mail clients, you can actually avoid duplicates by setting your mail client to “Leave messages on server” and “Remove mail from server after ‘1′ day” — This combination ensures that your mail client must maintain a list of downloaded messages between sessions, but still removes messages in short order, preventing mailboxes from getting overwhelmed.

Tags: ,

Related posts

How to delete all disabled accounts

Posted on October 7, 2008
Filed Under MDaemon | Leave a Comment

An example situation is this: As new employees start, you create mailboxes. When an employee leaves, you disable the mailbox. Skip ahead several years and you now have hundreds of disabled accounts eating up licenses and would like to delete them all.

  1. Backup.  Please backup, we’re talking about deleting massive numbers of accounts including their mail directories here, and if you don’t have a backup plan, at least have an up to date resume?
  2. In MDaemon, go to Accounts –> Export to CSV file
  3. Open the CSV file in Excel
  4. Sort by the “AccessType” field.  Be sure to use the “My data has headers” option, don’t sort the header in with the file.  Also be certain that you sorted the entire file, not just the column.
  5. Look down the AccessType line and find the section that contains “C” entries.  These accounts are completely disabled.
  6. Copy the email addresses listed in the first field, the “Email” field.
  7. Start notepad
  8. Paste the email addresses into Notepad.
  9. I implore you, please confirm that these are actually disabled mailboxes, if you made a mistake sorting in step #5, you’ll delete the wrong mailboxes.
  10. Save the Notepad file as C:\MDaemon\App\deluser.sem

When MDaemon sees the deluser.sem file, MDaemon will proceed to immediately delete every email address listed there, including their mail folders, all without prompting.

This can be done while MDaemon is running, or when MDaemon is shut down, the deluser.sem file will be processed as soon as MDaemon starts.

Tags: , ,

Related posts

« go back — keep looking »