David -

You were on the right track, the issue IS with the NOS.  It could have been in the initial installation of Mercury and it's alias file or a migration from Bindery>NDS.  Either way, ConsoleOne revealed under a user object's Other attributes tab, a setting for EMail Address unilike the E-mail address attribute under the General tab, which is blank for all users in this eDir context.  The Other EMail attribute is not present for user objects created after the migration to NDS.  The Other attribute EMail setting had a 0SMTP:aliasname set, which was changed, the NLMs unloaded/loaded, and now the user's e-mail has the desired specification wrt Sender and Message-ID.  Best to tidy up by removing that Other EMail attribute from all user objects.

Thanks again.  Cheers!     -Robert

If the synonym.mer file is not present in the system/mercury folder, users still have their synonym@domain as the sender's address rather than username@domain
.  Only a copying the old synonym.mer file to the new

system/mercury folder allowed those users to post messages as

bouncebacks to the postmaster indicated the synonym@domain did not

exist.  Once the old file was there, their mail went through, albeit

with the synonym as the sender, not their proper username.  A scan of their pmail.ini files yield no indication of the synonym@domain but I may be looking in the wrong file.  Mind you, we've been running pmail/mercury since '93...yes, starting with pmail for DOS.

btw, this behavior is with the latest greatest winPMail running with the latest greatest Mercury transport on a Netware 6.5 server.

[quote user="rhs"]

If the synonym.mer file is not present in the system/mercury folder, users still have their synonym@domain as the sender's address rather than username@domain

btw, this behavior is with the latest greatest winPMail running with the latest greatest Mercury transport on a Netware 6.5 server.

[quote user="David Harris"][quote user="rhs"]

If the synonym.mer file is not present in the system/mercury folder, users still have their synonym@domain as the sender's address rather than username@domain

btw, this behavior is with the latest greatest winPMail running with the latest greatest Mercury transport on a Netware 6.5 server.

[/quote]

Since you're running on a NetWare 6.5 server, are you running in Bindery or NDS mode? If so, the synonym is almost certainly being sourced from the NOS. Assuming you're running in NDS mode (Bindery mode on an NDS server is a REALLY bad idea), using the Pegasus Mail NCONFIG utility to remove the synonym from the user's NDS object.

[/quote]

Thanks for the note of encouragement, David.
Indeed, we are in NDS/eDir mode. I ran the NCONFIG program, drilled down to the appropriate context, then user object, and when viewing their properties, there was no synonym set, none to delete.

Further investigation yielded this curiousity: With both alias and synonym files commented out of mercury.ini and the NLMs unloaded/loaded, the user runs Pegaus Mail for Windows
v4.1.1.  A post to local users has the Message-ID: <numberID@username.ou.ou.ou.o> while a post to a non-local user has the Message-ID <numberID@alias.subdomain.subdomain.tld>  The point being that the username, which is properly viewed in the bottom status bar of win-pmail, is carried for local mail, while this alias is injected for non-local (internet) mail.  *Nowhere* in the Pegasus Mail for Windows settings can we find the alias.  Is there a nifty 'delete this file, it will be reconstructed' tip/trick which we can try?  fwiw, the pmail.ini file has no reference of the alias.  It's out there, somewhere, but even a regedit can't find the bugger.  arrgh.