Based on some recent experience of inconsistencies between the MDRA and the Desktop Application what is considered the best option for most administration tasks?
I've been creating public folders with submission addresses for various tasks and I've noticed differences in the defaul ACLs applied depending on where you create the folders. This on top of some other bugs or inconsistencies has me wondering which UI is best and safest to use for general administation?
TIA
Remote Administration is the primary user interface. If you are seeing other bugs or inconsistencies, please provide the details so that we can investigate.
Hi Arron, so whilst adding public folders ACLs get applied differntly depending on where you create the publc folder. If I create a public folder in the nested under ROOT the ACLs are the same created from both UIs. However, if I create a public folder at a domain level the ACLs are different.
At domain level if created in the desktop application the default (anyone) has no ACL permissions, anyone@domain.com has lr amd a custom Group I have created gets full permissions lrswipcda.
If I create a folder using the MDRA the folder only gets the deafult (anyone) lrswi permissions.
I've come accoss this whilst trying to make use of sumission addresses on public folders. We have a scenario where we want a leavers historic email and current email to be stored so that other users can see and interact with it but we can delete the account. We were having problems with some emails ending up in the bad mail queue due to exceding the maximum hop count i.e. they were stuck in a loop.
The reason for adding the public folders at a domain level rather than the root is because we have multiple domains and we want to keep public folders tied to the domain they are intended for and not be visible by users on other domains.
Hope this makes sense?
Thanks for the detail. It’s a bug in Remote Administration. When you create a public folder under a domain, it doesn’t copy the domain folder’s permissions the way the desktop application does. I've submitted a bug for the development team to review
Would you like help with the hop count issue as well? If you do could you send the routing and SMTP logs, plus one affected message from the Bad queue?
https://mdaemon.sharefile.com/r-rc3922c1eed334d4dbf5e34f0bd04ccd6
Hi Arron. I got to the bottom of the Bad Mail issue. It was to do with the ACLs. I'd removed all permissions from the anyone@domain.com and the default (anyone) was stripped to post only which was added by the submission address. It seems that the narrower perission of anyone@domain.com was taking precident over the default (anyone) permission.
What was confusing was that emails from external sources and email clients connecting to MDaemon internally sending email to the sumbission address was working fine. The problem we had is we use postfix for some internal system stuff and emails generated from this which were from system@domain.com to submission_address@domain.com were the ones ending up in the bad mail queue. Simply removing the ACL for anyone@domain.com fixed the issue!
Thanks as always for your help!
English
Chinese (Simplified)
French
German
Italian
Japanese
Russian
Spanish
Vietnamese
