Order of looking for valid mailaddress

FJR

posted Jul 28 '16 at 9:16 am

Hi Rolf,

wow ... thank you very much! Seems in future I should look for some more reasons for those errors.

[quote]It checks to see whether the user part refers to a Group that has been defined in the “Groups” page of the Mercury Core Module configuration dialog.[/quote]

Did know that and have some groups defined in Mercury pointing at groups in NDS/eDirectory (Novell User Management Database).

But I didn't realize what happens if the userpart of the mailaddress is the same than a groupname in NDS. The problem was: no errormessage by Mercury than a mail with "Recovery from abnormal termination" to Postmaster and similar entries in Loader.log. A hint like "New mailbox directory missing" would have been nice ... because a existing user in NDS, who deleted his new mailbox directory located in his home directory on the server, results in same behaviour of Mercury.

I think even without NDS and simply defined usernames/mailboxes with Mercury and Pegasus, the result would be the same if that directory is deleted or renamed: termination of Mercury. Can't test it due to NDS ... perhaps somebody else?

thanks Olaf

Hi Rolf,wow ... thank you very much! Seems in future I should look for some more reasons for those errors.[quote]It checks to see whether the user part refers to a Group that has been defined in the “Groups” page of the Mercury Core Module configuration dialog.[/quote] Did know that and have some groups defined in Mercury pointing at groups in NDS/eDirectory (Novell User Management Database).But I didn't realize what happens if the userpart of the mailaddress is the same than a groupname in NDS. The problem was: no errormessage by Mercury than a mail with "Recovery from abnormal termination" to Postmaster and similar entries in Loader.log. A hint like "New mailbox directory missing" would have been nice ... because a existing user in NDS, who deleted his new mailbox directory located in his home directory on the server, results in same behaviour of Mercury.I think even without NDS and simply defined usernames/mailboxes with Mercury and Pegasus, the result would be the same if that directory is deleted or renamed: termination of Mercury. Can't test it due to NDS ... perhaps somebody else?thanks &nbsp;&nbsp; Olaf&nbsp;

FJR

posted Jul 27 '16 at 9:42 pm

Had an issue with mercury/32 with NDS/eDirectory-Modul and meanwhile deleted alias for mailaddress. Mercury crashed when an email arrived for that address and after several restarts copied the mailfiles to a BAD-Diretory in the queuedirectory. Sometimes the recovery wasn't sucessfully and Mercury terminated. :-( Solution was: had deleted the alias, but there has been a usergroup in eDiretory of servers with the same name. Groups don't have a maildirectory ... so Mercury crashed.

With this I have a simple question (didn't find the information): what's the order Mercury checks for valid mailaddresses?

usernames
synonyms
aliases
mailinglists
other directoryobjects

Is this correct? Did I forget something? Is there an additional order for directoryobjects?

bye Olaf

Had an issue with mercury/32 with NDS/eDirectory-Modul and meanwhile deleted alias for mailaddress. Mercury crashed when an email arrived for that address and after several restarts copied the mailfiles to a BAD-Diretory in the queuedirectory. Sometimes the recovery wasn't sucessfully and Mercury terminated. :-( Solution was: had deleted the alias, but there has been a usergroup in eDiretory of servers with the same name. Groups don't have a maildirectory ... so Mercury crashed.With this I have a simple question (didn't find the information): what's the order Mercury checks for valid mailaddresses? <ol><li>usernames</li><li>synonyms</li><li>aliases</li><li>mailinglists</li><li>other directoryobjects</li></ol>Is this correct? Did I forget something? Is there an additional order for directoryobjects? bye &nbsp;&nbsp; Olaf&nbsp;

Rolf Lindby

posted Jul 28 '16 at 5:20 am

There is some information in the Mercury Daemon Developer Guide about address resolution, specifically the is_local_address and

is_valid_local_user functions. Here is what it says about is_local_address:

It’s worth taking a moment to examine the steps that is_local_address performs when
evaluating an address:
• The address is reduced to its simplest form and split into user and domain parts.
• The address is checked against the special reserved string “<>” (meaning “do not
reply”). If it matches, the function returns 2, indicating a non-local address serviced by
an alias, to ensure that it is allowed to relay.
• If the domain part does not match any domain defined in the “Local Domains” page of
the Mercury Core Module configuration dialog, the routine returns 0.
• It checks whether the user part contains any of the special alias prefixes file:,
tfile:, public:, daemon: and filter: if it does, it immediately returns -1 (these
prefixes are only valid when they are resolved as part of an alias, which happens later).
• It attempts to resolve the user part as an alias, up to five times (that is, it is possible to
have aliases that are themselves aliases, up to five levels deep). During this process, the
alias prefixes described above are permitted as prefixes to the aliased address and will
result in a return value of 1 (valid local address).
• It checks whether the entire address is a synonym for another address (a synonym is a
kind of special bidirectional alias that can be used as a complete replacement for another
address on the system).
• It checks to see if the user part contains a VERP prefix: VERP prefixes are used to automate error handling for mailing lists and usually start with the string “verp.”.
• It checks to see if the user part is a mailing list hosted on the local system.
• It checks to see if the user part is the reserved address “postmaster”.
• It checks to see if the user part is the reserved name of the Mercury mail server component (usually “maiser”).
• It checks whether the user part alone is a synonym for another address on the system.
• It checks to see whether the user part refers to a Group that has been defined in the
“Groups” page of the Mercury Core Module configuration dialog.
• It checks to see if the user part is a so-called “percent hack” form, which Mercury uses to
allow direct delivery of mail to noticeboards.
• It checks to see if the user part is a valid local username
• It checks again to see if the user part is the reserved address “postmaster” (this can
happen as the result of both alias and synonym resolution).
• If it gets to this point without finding a match, it returns -1 (“local domain but no such
user defined”).
The uic and server parameters to this function are historical: they are used internally by the
code to handle certain network-specific address transformations, and cannot be NULL. They
are passed unaltered to is_valid_local_user (see below) as part of the process of determining whether the address is local.

There is some information in the Mercury Daemon Developer Guide about address resolution, specifically the&nbsp;is_local_address and&nbsp; is_valid_local_user functions. Here is what it says about is_local_address:<blockquote>It’s worth taking a moment to examine the steps that is_local_address performs when evaluating an address: • The address is reduced to its simplest form and split into user and domain parts. • The address is checked against the special reserved string “&lt;&gt;” (meaning “do not reply”). If it matches, the function returns 2, indicating a non-local address serviced by an alias, to ensure that it is allowed to relay. • If the domain part does not match any domain defined in the “Local Domains” page of the Mercury Core Module configuration dialog, the routine returns 0. • It checks whether the user part contains any of the special alias prefixes file:, tfile:, public:, daemon: and filter: if it does, it immediately returns -1 (these prefixes are only valid when they are resolved as part of an alias, which happens later). • It attempts to resolve the user part as an alias, up to five times (that is, it is possible to have aliases that are themselves aliases, up to five levels deep). During this process, the alias prefixes described above are permitted as prefixes to the aliased address and will result in a return value of 1 (valid local address). • It checks whether the entire address is a synonym for another address (a synonym is a kind of special bidirectional alias that can be used as a complete replacement for another address on the system). • It checks to see if the user part contains a VERP prefix: VERP prefixes are used to automate error handling for mailing lists and usually start with the string “verp.”. • It checks to see if the user part is a mailing list hosted on the local system. • It checks to see if the user part is the reserved address “postmaster”. • It checks to see if the user part is the reserved name of the Mercury mail server component (usually “maiser”). • It checks whether the user part alone is a synonym for another address on the system. • It checks to see whether the user part refers to a Group that has been defined in the “Groups” page of the Mercury Core Module configuration dialog. • It checks to see if the user part is a so-called “percent hack” form, which Mercury uses to allow direct delivery of mail to noticeboards. • It checks to see if the user part is a valid local username • It checks again to see if the user part is the reserved address “postmaster” (this can happen as the result of both alias and synonym resolution). • If it gets to this point without finding a match, it returns -1 (“local domain but no such user defined”). The uic and server parameters to this function are historical: they are used internally by the code to handle certain network-specific address transformations, and cannot be NULL. They are passed unaltered to is_valid_local_user (see below) as part of the process of determining whether the address is local. </blockquote>&nbsp;

Related Topics

Pending draft

Confirm move posts

Insufficient permissions

Select a different topic

Edit history