Settings
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
Allow Logon using aliases
By default users are permitted to log in to their accounts using one of their account aliases instead of their actual mailbox name. Clear this checkbox if you do not wish to allow this.
See:
