Options

It's OK to relay mail for aliases that include foreign domains

Check this box if you wish to allow MDaemon to relay mail for aliases that include non-local domains. This option overrides the Do not allow message relaying option in Relay Control for those aliases.

Fully qualified aliases (no wildcards) are allowed to be list members

Click this checkbox if you want to allow aliases to be members of MDaemon mailing lists. Only actual accounts can be list members if this control is not enabled. Note: aliases containing wildcards are not permitted to be list members even if this option is enabled.

Mail from 'Postmaster,' 'abuse,' 'webmaster' requires authentication

When this option is enabled, MDaemon will require messages claiming to be from any of your "postmaster@...", "abuse@..." or "webmaster@..." aliases or accounts to be authenticated before MDaemon will accept them. Spammers and hackers know that these addresses might exist, and may therefore attempt to use one of them to send mail through your system. This option will prevent them and other unauthorized users from being able to do so. For your convenience this option is also available on the SMTP Authentication screen, located at: Security » Security Settings. Changing the setting here will change it there as well.

IP Shield honors aliases

By default the IP Shield will honor aliases when checking incoming messages for valid domain/IP pairs. The IP Shield will translate an alias to the true account to which it points and thus honor it if it passes the shield. If you clear this checkbox then the IP Shield will treat each alias as if it is an address independent of the account that it represents. Thus, if an alias' IP address violates an IP Shield then the message will be refused. This option is mirrored on the IP Shield screen — changing the setting here will be change it there as well.

Replicate aliases to LDAP address book

Click this check box if you want aliases to be replicated to the LDAP address book. Alias replication is necessary for the LDAP remote verification feature to work reliably, but if you are not using that feature then replicating aliases to the LDAP address book is unnecessary. If you are not using remote verification then you can safely disable this feature to save processing time. For more information on remote LDAP verification see LDAP.

Aliases processing stops when result matches an existing account or list

When this option is enabled, alias processing will stop when the recipient of the incoming message matches an existing account or mailing list. This typically applies to aliases that include a wildcard. For example, if you have an alias set to, "*@example.com=user1@example.com," then this option will cause that alias to be applied only to addresses that do not actually exist on your server. So, if you also have the account, "user2@example.com," then messages addressed to user2 would still be delivered to him because the alias wouldn't be applied to those messages. But messages addressed to some non-existent account or list would be sent to "user1@example.com" because the wildcard alias would be applied to those messages. This option is enabled by default.

This option must be enabled when you are using Subaddressing, to avoid potential problems with handling those messages.

Use recursive aliasing

Click this check box if you want to process aliases recursively. Any alias match causes the resulting value to be reprocessed back through the entire alias list—it is possible to nest aliases up to 10 levels deep. For example, you could set up something like this:

user2@example.com = user1@example.com

user1@example.com = user5@example.net

user5@example.net = user9@example.org

This is logically identical to the single alias:

user2@example.com = user9example.org

It also means that:

user1@example.com = user9example.org

See:

Aliases