Pegasus Mail & Mercury

Welcome to the Community for Pegasus Mail and
The Mercury Mail Transport System, the Internet's longest-serving PC e-mail system!
Welcome to Pegasus Mail & Mercury Sign in | Join | Help
in
Home Blogs Forums Downloads Pegasus Mail Overview Mercury Overview Wiki

issue with mail delivery to public mail folder

Last post 02-23-2018, 16:16 by Joerg. 5 replies.
Sort Posts: Previous Next
  •  02-07-2018, 11:40

    • Joerg is not online. Last active: 05-22-2018, 20:12 Joerg
    • Top 25 Contributor
    • Joined on 03-25-2008
    • German Baltic Sea Coast
    • Contributor
    • Points 5,840

    issue with mail delivery to public mail folder

    Hi Guys,

    Since a few days we experience an oddity with our public mail folder.

    Following settings:

    Users have their own Pmail mailboxes which reside at the server where Mercury is forwarding their mails to. Mercury D is polling the single user mailboxes at the ISP and retrieving available mails to local user mailboxes. Additionally Mercury D is polling one ISP mailbox which have no local user assigned. By using an Alias (publicmail@domain.com > PUBLIC:path_to_folder) Mercury is putting all mails of this special mailbox into the folder defined in the Alias definition. In Pmail we have assigned this folder as a Public Folder where all users could simultaneously access to. Works fine so far.

    Since we changed our server from MS Server 2003 to MS Server 2016 Mercury is being started as a service without GUI. Only for configuration tasks I stop the Mercury service and start the Mercury GUI. Now we experience the following, when Mercury is running without GUI as a service: Mails, which are addressed to a local user and additionally in <cc:> addressed to the public mail address (or vice versa) do not reliably arrive in both inboxes. Sometimes they come and sometimes they arrive only at the user's mailbox but not in the Public Mailbox. I'm not able to recognize a pattern. Also the analyzing of the logs do not discover anything. The mails to Public keep disappeared.

    In comparison: when Mercury is manually started and is running with GUI, all mails appear as intended: Mercury D is polling the user mailbox at the ISP and retrieves and forwards the mail to user's inbox. Then Mercury D is polling the "Public Mailbox" at the ISP and retrieves the same mail (which was sent to Public Mailbox in CC:) again and forwards it to public folder as defined in the Alias definition.

    I have also made some test with and without msgid.mer which are situated in all user mailboxes, but without success.

    Has anybody a clue in this regard?

    Cheers

    Joerg

     

    Update:

    In the meantime I'm not sure whether it depends on how Mercury is running (service or GUI). Rather it seems in case the mail contains both an address wich is assigned to an existing local user as well as an additional address (cc) which is assigned to an Alias (PUBLIC:), Mercury is prefering the local user and is forwarding the mail twice to the local user account but not to the public folder.

  •  02-09-2018, 22:44

    • Brian Fluet is not online. Last active: 05-22-2018, 19:04 Brian Fluet
    • Top 10 Contributor
    • Joined on 12-24-2014
    • North Carolina, USA
    • SuperStar
    • Points 19,790

    Re: issue with mail delivery to public mail folder

    Hi Joerg,

    I'm just posting to say that I'm clueless.  Two areas where our usage of Mercury is different is yours being on a server and running as a service, mine is on a PC running the GUI.

    Your "update" seems to indicate that something is broken in the alias routing to the public folder.  A permissions issue to the public folder perhaps?  Article here on services and security contexts just in case it might be enlightening:  https://docs.microsoft.com/en-us/dotnet/framework/windows-services/how-to-specify-the-security-context-for-services 

    I also don't know why MSGIDS.MER isn't supressing the duplicates.  I wondered if messages aren't considered duplicate if TO: and/or CC: are different but, if it worked before, why not now???

    This will continue to roll around in my head and I'll certainly share any thoughts that may result. 

    Good luck my friend!

  •  02-21-2018, 17:38

    • Joerg is not online. Last active: 05-22-2018, 20:12 Joerg
    • Top 25 Contributor
    • Joined on 03-25-2008
    • German Baltic Sea Coast
    • Contributor
    • Points 5,840

    Re: issue with mail delivery to public mail folder

    Following has been turned out: When an email is retrieved by Mercury D from an ISP email account which is not assigned to a local Pmail user but connected by aliasing to a Public Mail Folder, this email will be safely delivered into this public folder. Fine so far.

    But in case this e-mail additionally contains a local e-mail address in cc (assigned to an ordinary Pmail user account), and this cc address has been retrieved by Mercury D firstly (before polling the address connected to Public Folder), the mail will be delivered to the local ordinary user. After that, when polling the address connected to the Public Folder, the Mercury D state window is showing the retrieving of the same mail again (OK so far), which will be delivered to the local user account again (seems the alias function is processing also all cc values again) and into the Public Folder. But the mail often do not arrive in the public folder and the mail log is also not showing any delivery into public folder.

    Now I will try to change the polling sequence of Mercury D in that manner that the e-mail address connected to the public folder is being polled firstly before all other ordinary accounts are being checked. Hopefully then Mercury D is more reliable delivering mails into the public folder.

    Regards

    Joerg

  •  02-23-2018, 14:44

    • Joerg is not online. Last active: 05-22-2018, 20:12 Joerg
    • Top 25 Contributor
    • Joined on 03-25-2008
    • German Baltic Sea Coast
    • Contributor
    • Points 5,840

    Re: issue with mail delivery to public mail folder

    Now I have changed the polling sequence of Mercury D. Now, Mercury D is firstly checking the ISP mailboxes which are connected to public folders, followed by the ISP mailboxes connected to local Pmail users. It seems this order is more reliable.

    Mails which are addressed to local users AND to public folders (in cc) or vice versa will be processed as follows:

    1. Mercury D is calling the ISP for the account connected to the local public mailbox. It find a mail, addressed to a local user account and to an aliased public folder and will retrieve and put the mail into both, the user's account and the public folder although this aliased account is not assigned to a local Pmail account within Mercury D!

    2. Then Mercury D is calling the other user's accounts with the ISP according to its calling sequence. When calling the account of the affected user, Mercury D is retrieving the mail and put it into user's account again. In case the MSGIDS.MER is in place, this duplicated mail will be suppressed. (In past the suppression didn't work for some user accounts because of a spelling mistake. I created a file MSGID.MER and was wondering why it didn't work. Embarrassed

    So far my new experience with public folders. For the moment it seems to be work without loosing mails.

  •  02-23-2018, 15:00

    • Brian Fluet is not online. Last active: 05-22-2018, 19:04 Brian Fluet
    • Top 10 Contributor
    • Joined on 12-24-2014
    • North Carolina, USA
    • SuperStar
    • Points 19,790

    Re: issue with mail delivery to public mail folder

    Glad you got it figured out.  Thanks for the troubleshooting effort and for keeping us up to date. 

    Are the messages pulled from user's accounts resulting in duplicates to the public folder?


  •  02-23-2018, 16:16

    • Joerg is not online. Last active: 05-22-2018, 20:12 Joerg
    • Top 25 Contributor
    • Joined on 03-25-2008
    • German Baltic Sea Coast
    • Contributor
    • Points 5,840

    Re: issue with mail delivery to public mail folder

    Hi Brian,

    No, the messages pulled from user's accounts don't result in duplicates to the public folder. They will only be dropped into the inbox of the (Mercury D) assigned local user.

     

    Finally it seems Mercury (D or Core) is checking all opportunities (defined aliases and local accounts) for local mail delivery in case no local user is assigned.

View as RSS news feed in XML

Contact | Advertise | Host provider: PraktIT | Terms of Use | Privacy Statement
Copyright © 2007-2011 David Harris / Peter Strömblad. | Pegasus Mail Home Page