[Users] January 19, 2021 Zeta Alliance Conference Call Summary

[Frédéric Nass]

Hi Randy,

Thanks for bringing the calendar issue to John's attention during the 
last call and sorry for not reading your report earlier than today. I 
like to keep them unread until I have enough time to read them 
carefully. :-)

I realize I may not have been clear enough regarding this calendar 
issue. The issue appears because of the way Zimbra synchronizes 
calendars. Suppose there's an event in Calendar (A) 
https://timetable.myuniversity.com/calendar/year_1/group_A/calendar.ics 
that's also in Calendar (B) 
https://timetable.myuniversity.com/calendar/year_1/group_B/calendar.ics. 
If Zimbra synchronizes Calendar (A) before Calendar (B), then the event 
will only be downloaded once in Calendar (A) and will not be downloaded 
in Calendar (B) despite it's actually part of Calendar (B). The event 
will just be skipped on Calendar (B) synchronization and will not be 
considered in Calendar (B) at all.

As a result, if Zimbra user chooses to display only Calendar (B) and not 
Calendar (A) in the Zimbra Web Client, then the common event will not 
appear on the Calendar view at all. And that's the issue.
The common event should be synchronized in both/all Calendars that 
contains it so that it can be displayed in the ZWC calendar view 
whatever the calendar is ticked.

I've just been notified today by Zimbra's support that my case has 
resulted in a Bug (ZBUG-2097) so I hope it will be fixed one day.

Kind regards,

Frédéric.


Le 22/01/2021 à 20:52, Randy Leiker a écrit :
> Hello Zeta Alliance Community,
>
> Here is a summary of this week’s conference call.  A few brief reminders:
>
>   * Conference calls are every Tuesday and open to all using either
>     the FreeConferenceCall.com VoIP app or via a dial-in number:
>     https://www.freeconferencecall.com/wall/zetalliance
>   * Each week’s call agenda can be found at:
>     _https://drive.google.com/drive/folders/1xDyBJFjnfZYxuXJHiDzsXjjMuGGtIl7J_
>   * A copy of each week’s summary is also posted to the Zimbra Forums:
>       o All Prior Months: https://forums.zimbra.org/viewforum.php?f=9
>       o December 2020: https://forums.zimbra.org/viewtopic.php?f=9&t=69008
>       o January 2021: https://forums.zimbra.org/viewtopic.php?f=9&t=69121
>   * Constructive feedback on these call summaries is always welcome.
>
>
> January 19, 2021
>
> *Setting A Maximum Message Size Per Domain*
> Noah P. said that he is looking for a means to enforce a maximum email 
> size limit per Zimbra domain.  He explained that he has two customers 
> that want to keep email messages within their organizations smaller 
> than they are now, and Noah does not wish to apply the lower size 
> limit to all other customer domains on his Zimbra servers, but rather 
> just to those two customer’s domains.  Cine suggested that CBPolicyd ( 
> https://wiki.zimbra.com/wiki/How-to_for_cbpolicyd ) might be of help, 
> and said that he knows CBPolicyd can set a maximum outbound message 
> size limit, but was not certain if it was possible to set an inbound 
> message size limit too.  Mark S. suggested that Noah could setup a new 
> Zimbra MTA server specifically for the customers requesting the lower 
> message size limit, then route all of the email for those two 
> customers through the new MTA server.  Matthew F. said that writing a 
> Postfix Milter to filter based on message size might work, but the 
> downside to this approach would be that messages that are too large 
> would bounce to the sender only after Zimbra initially accepts the 
> messages for delivery.  Matthew also pointed out that in doing a quick 
> Telnet connection test to his Zimbra MTA server, he noticed that 
> Postfix advertises the maximum message size accepted immediately after 
> the HELO/EHLO command is sent, suggesting that it may only be 
> practical to have a server-wide message size limit set, as compared to 
> a per domain setting, assuming that all of the users are using the 
> same Zimbra MTA server.
>
> *Resetting Mailbox Passwords When Two-Factor Authentication Is Enabled*
> John E. shared an update on an issue discussed in an earlier Zeta 
> Alliance call related to difficulties encountered when attempting to 
> use the Zimbra password reset feature for a mailbox with two-factor 
> authentication enabled.  He said that this has been acknowledged by 
> Zimbra as a bug (ZCS-10191; status updates are not available via the 
> Zimbra Support Portal) and is anticipated to be fixed in an upcoming 
> patch that should be released soon.  Noah P. asked if the bug fix will 
> only apply to the Modern UI, the Classic UI, or both in Zimbra 9.  
> John E. said that the bug fix is associated with the server back-end, 
> so he thinks it should apply to both the Modern and Classic UIs.
>
> *Using Shared Calendars Containing The Same Calendar Event UIDs*
> From the Zeta Alliance mailing list, Frederic N. said that he has 
> Zimbra users who have multiple shared calendars, and they often add 
> the same calendar events to these multiple shared calendars with the 
> same UID number.  His users report that when their email clients are 
> configured to synchronize each of these shared calendars, they expect 
> the calendar events with the same UID number to appear for each shared 
> calendar, but the actual behavior observed is that the calendar events 
> appear only once on a single shared calendar – usually the shared 
> calendar that synchronizes first.  He wondered if this occurs because 
> of the de-duplication feature in Zimbra that also avoids repeatedly 
> delivering email messages with the same message ID number.  Cine said 
> that Frederic did not mention which email clients are in use by the 
> users, but generally it is up to each email client to decide on which 
> calendar events they will download, rather than the Zimbra server.  He 
> did not think that the de-duplication feature in Zimbra was involved, 
> as that feature only applies to email deliveries.  John H. added that 
> most email clients will consider calendar events with the same UID to 
> be the same calendar event, thereby causing the event to be displayed 
> only once within the email client, even if it appears on multiple 
> shared calendars on the server-side.  He said that for ActiveSync 
> clients, it is up to the client to decide on how to display calendar 
> events with the same UID, as either a single event, or multiple events.
>
> *Non-Responsive Mailboxd Process and AWS Storage Buckets*
> Mark S. shared that he recently experienced an issue with one of his 
> Zimbra mailbox servers where none of the users could access their 
> mailboxes, but the mailboxd processes and its dependencies were 
> running with a load of 120%.  After a restart of the mailboxd and 
> related services, users still could not access their mailboxes.  With 
> Zimbra Support’s assistance, the issue was pinpointed to a problem 
> with mailboxd accessing the AWS storage buckets containing his Zimbra 
> server’s disk volumes.  He said that when using AWS storage buckets as 
> Zimbra volumes, he used to be able to create a primary/secondary 
> volume without also needing to create a logical representation in 
> Zextras of the external AWS S3 storage bucket.  But, he discovered 
> that now this is required.  Cine said that about one year ago, the 
> Zimbra Administration UI changed to add support for some updates to 
> the supported volume types, but the Zextras back-end CLI did not.  He 
> said that it should now no longer be possible to create a Zimbra 
> volume without a corresponding AWS S3 bucket. When using AWS buckets 
> for Zimbra volumes, Cine recommended running these CLI commands:
>
>   * “zxsuite hsm getAllVolumes” to get the bucketConfigurationId
>     value, then run:
>   * “zxsuite hsm listBuckets” to see the actual bucketConfigurationId
>     for your actual buckets.
>   * If your primary or secondary storage volume references a
>     non-existent bucket ID, you may need to run “zxsuite hsm
>     doUpdateVolume …” to fix.
>
> *Using Smart Hosts In Zimbra To Manage Outbound Email Routing*
> Noah P. re-visited a topic from the November 10th Zeta Alliance call ( 
> https://forums.zimbra.org/viewtopic.php?f=9&t=68942#p299710 ) related 
> to controlling SMTP mail flow in Zimbra per domain. He said he had 
> been continuing to experiment with this capability by working with 
> using the Zimbra Smart Hosts feature to attempt to direct mail per 
> domain through specific Zimbra MTAs.  Mark S. suggested that Noah 
> should use the “zimbraSmtpHostname” setting per domain for this 
> purpose, but Noah said this setting only works for users who access 
> their mailboxes with the SOAP clients, such as the Zimbra Connector 
> for Outlook and ActiveSync.  Noah has observed that the Zimbra Web 
> Client, SMTP (IMAP/POP) clients, mailbox forwarders, and distribution 
> lists still continue to use the Zimbra global MTA setting, ignoring 
> the per domain “zimbraSmtpHostname” setting.  Cine suggested using 
> Postfix’s “sender_dependent_relayhost_maps” attribute in addition to 
> the “zimbraSmtpHostname” setting to help ensure consistency for each 
> user’s email client use case.  John H. suggested that Noah should also 
> create a Zimbra request for enhancement to make this capability part 
> of Zimbra’s official features.
>
> *“Host or domain name not found” Errors During Zimbra Server Migration*
> Matthew F. said that he is working on a customer migration from an old 
> to a new Zimbra server version.  He said that after a mailbox is moved 
> from the old to the new server, the LMTP server address for the 
> mailbox, that Zimbra uses for mail delivery, is updated to the new 
> server’s fully qualified domain name (FQDN) as expected, but email 
> deliveries sent from mailboxes on the old server to the mailbox on the 
> new server result in “status=bounced (Host or domain name not found. 
> Name service error for name=xxxx type=A: Host not found)” error 
> messages in mailbox.log.  He found that after moving a mailbox to the 
> new Zimbra server, and changing the LMTP FQDN for a mailbox to an IP 
> address, this then allows for email to be delivered normally.  Noah P. 
> wondered if Zimbra may be checking the server’s local /etc/hosts file 
> before using the DNS resolver configured for the server, and the 
> /etc/hosts file contains an incorrect entry for the FQDN of the new 
> server.  Mark S. said that he worked with a customer that had a 
> multi-homed Zimbra server, with one network interface assigned to a 
> public IP address, and another assigned to a VPN.  He found it very 
> tricky to get mail routed correctly with this setup and suggested 
> using Postfix’s “lmtp=native” setting.  He said that without this 
> setting, Postfix avoided using the /etc/hosts file for look-ups and 
> always used the DNS resolver configured for the server.   Cine 
> suggested that Matthew take a look at using dnsmasq as it makes these 
> types of scenarios much easier.  Mark S. suggested taking a look at 
> his dnsmasq how-to ( 
> https://www.missioncriticalemail.com/2018/04/12/zimbra-dnsmasq-configuration-guide/ 
> ) and said that dnsmasq is beneficial since it only answers DNS 
> queries for records it is specifically configured to answer, and 
> passes all other queries through to the server’s regular DNS 
> resolver.  Noah P. also suggested the Zimbra command: “zmlocalconfig 
> -e postfix_lmtp_host_lookup=native” which Matthew said he currently 
> has enabled.  Cine added that using the /etc/nsswitch.conf file to set 
> the order in which DNS resolvers are used may help, such as this 
> configuration value: “hosts:  files dns”.  Mark S. said that this page 
> ( https://wiki.zimbra.com/wiki/Postconf_keys ) maps Postfix 
> configuration settings to Zimbra-equivalent settings may be of help 
> too.  Noah P. said that Matthew might be looking for this Zimbra 
> setting too: “zimbraMtaLmtpHostLookup”, which can be described from 
> the CLI using: “zmprov desc -a zimbraMtaLmtpHostLookup”.  Matthew F. 
> said he currently has this setting configured: 
> “zimbraMtaLmtpHostLookup: dns”.
>
>
> Randy Leiker (randy at skywaynetworks.com )
> Skyway Networks, LLC
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.zetalliance.org/pipermail/users_lists.zetalliance.org/attachments/20210201/0192339f/attachment.html>