1 Topic by swejun

  • swejun
  • Member
  • Offline
  • Registered: 2017-07-26
  • Posts: 84

Topic: expand mailing lists for calendar appoitments

==== Required information ====
- iRedMail version (check /etc/iredmail-release): 0.9.7
- Linux/BSD distribution name and version:  Centos 7.4
- Store mail accounts in which backend (LDAP/MySQL/PGSQL): LDAP
- Web server (Apache or Nginx): APACHE
- Manage mail accounts with iRedAdmin-Pro? NO
- [IMPORTANT] Related original log or error message is required if you're experiencing an issue.
====
Hi all,
having a couple of internal mailing lists defined, and set to be visible via the global address book.
If using the SOGo calendar web gui, I can select a mailing list ( like everyone@my.domain ) as attendee.
When the booking is send, it will be vissible for the organizer and other attendees as "everyone@my.domain" and not individual users.
The preferred method whould be to expnad the mailing list before sending (in the creation phase) so that indiviual accept/reject are tracked.
Is this possible at all to achieve at all?

The work arround is that the organiser selects all individual users instead of the mailing list alias "everyone@my.domain"
For a small organisation its just fine, but if you have hundreds or more users and 5-10 possible alias list to select from it gets more complicated.
/Regards

----

Spider Email Archiver: On-Premises, lightweight email archiving software developed by iRedMail team. Supports Amazon S3 compatible storage and custom branding.

2 Reply by ZhangHuangbin

  • ZhangHuangbin
  • ZhangHuangbin
  • iRedMail Developers
  • Offline
  • Registered: 2009-05-06
  • Posts: 30,770

Re: expand mailing lists for calendar appoitments

swejun wrote:

When the booking is send, it will be vissible for the organizer and other attendees as "everyone@my.domain" and not individual users.

Please report this issue to SOGo team, and ask them to implement it:
https://sogo.nu/support/index.html

Or, bug tracker: https://sogo.nu/bugs/

3 Reply by swejun

  • swejun
  • Member
  • Offline
  • Registered: 2017-07-26
  • Posts: 84

Re: expand mailing lists for calendar appoitments

Ok, thanks. Will do.
BTW: A second possible workarround:
- Create a group in Your private address book, add individual recipients.
When using this group, it will be expanded before submision of an e-mail or calendar booking.

I'm not sure why it works differently, other than that this groups is stored in the SQL database instead of the LDAP directory
Could it possibly behave differently if using SQL based installation instead of LDAP?

/Ingvar

4 Reply by swejun

  • swejun
  • Member
  • Offline
  • Registered: 2017-07-26
  • Posts: 84

Re: expand mailing lists for calendar appoitments

Solved!
I managed to find out how to create an expandable list to be used for calendar appointments.
Did not test all possible configuration variants, so maybe there are som obsolete options.
Anyway: The hints for the answer was found at: https://sogo.nu/files/docs/SOGoInstalla … using_ldap

Background: we have created internal mailing lists as described in http://www.iredmail.org/docs/ldap.add.mail.list.html
If using this maillist when creating  a booking, individual recipients accpt/deny will not be visible.

1) Instead, create a new group in LDAP, with structural objectClass=groupOfUniqueNames, and add UniqueMemebers
2) Update /etc/sogo/sogo.conf, add a new section under SOGoUserSources = ( {old section}, { new section} ); describing the new global address book and add a filter criteria to limit the search result
3) restart the sogod service
4) The result will be that all calendar groups can be used when creating appointments (add attende: calendar-all@..) and individual requests will be send and vissible in all calendars, just as if they had been addedd manually

Configs:
# LDAP entry exported
# Entry 1: cn=calendar-all,ou=Groups,domainName=mydomain.tld,o=domains,dc=int,d...
dn: cn=cal-all,ou=Groups,domainName=mydomain.tld,o=domains,dc=int,dc=mydomain,dc=tld
cn: calendar-all
description: Calendar Group All at MyDomain
enabledservice: displayedInGlobalAddressBook
mail: calendar-all@mydomain.tld
objectclass: groupOfUniqueNames
objectclass: top
objectclass: extensibleObject
uniquemember: mail=User1@mydomain.tld,ou=Users,domainName=mydomain.tld,o=domains,dc=int,dc=mydomain,dc=tld
uniquemember: mail=User2@mydomain.tld,ou=Users,domainName=mydomain.tld,o=domains,dc=int,dc=mydomain,dc=tld
uniquemember: mail=User3@mydomain.tld,ou=Users,domainName=mydomain.tld,o=domains,dc=int,dc=mydomain,dc=tld

etc.
     
       
        {
            // see https://sogo.nu/files/docs/SOGoInstalla … using_ldap
            // added new section  into /etc/sogo/sogo.conf
            type = ldap;
            CNFieldName = cn;
            IDFieldName = cn;
            UIDFieldName = cn;
            baseDN = "o=domains,dc=int,dc=mydomain,dc=tld";
            bindDN = "cn=vmail,dc=int,dc=mydomain,dc=tld";
            bindPassword = "SecretPassword";
            canAuthenticate = YES;
            displayName = "Calendar Groups";
            hostname = "ldap://127.0.0.1:389";
            id = calendar_groups;
            isAddressBook = YES;
            filter = "(enabledService=displayedInGlobalAddressBook AND objectClass=groupOfUniqueNames)";
            listRequiresDot = NO;
        }

5 Reply by ZhangHuangbin

  • ZhangHuangbin
  • ZhangHuangbin
  • iRedMail Developers
  • Offline
  • Registered: 2009-05-06
  • Posts: 30,770

Re: expand mailing lists for calendar appoitments

swejun wrote:

uniquemember: mail=User1@mydomain.tld,ou=Users,domainName=mydomain.tld,o=domains,dc=int,dc=mydomain,dc=tld
uniquemember: mail=User2@mydomain.tld,ou=Users,domainName=mydomain.tld,o=domains,dc=int,dc=mydomain,dc=tld
uniquemember: mail=User3@mydomain.tld,ou=Users,domainName=mydomain.tld,o=domains,dc=int,dc=mydomain,dc=tld

iRedMail tried hard to avoid using full DN as value of some LDAP attributes, because it will be a little complicated to maintain the dn if you moved / removed / renamed the account email address. But many applications still prefer full DN.

Just a remind.