[Users] October 13, 2020 Zeta Alliance Conference Call Summary

[Filippo Cinetto]

Hello everyone!

Just a quick correction: my comment about new zimlets was as usual out of
personal curiosity and not an "official" statement...

Il mer 14 ott 2020, 06:09 Randy Leiker <randy at skywaynetworks.com> ha
scritto:

> 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://docs.google.com/document/d/1uUUDJpwp2CAylU6lxtbEdVcUX_qSbciyes6gLTWw2fY/edit
>    - A copy of each week’s summary is also posted to the Zimbra Forums:
>    - All Prior Months: https://forums.zimbra.org/viewforum.php?f=9
>       - September 2020:
>       https://forums.zimbra.org/viewtopic.php?f=9&t=68705
>       - October 2020: https://forums.zimbra.org/viewtopic.php?f=9&t=68823
>       - Constructive feedback on these call summaries is always welcome.
>
>
> October 13, 2020
>
> *New Time For the Zeta Alliance Weekly Calls*
> Marc G. proposed taking a vote to continue the recurring weekly Zeta
> Alliance calls on Tuesdays, but starting with the call for November 3,
> 2020, to change the time to 9:30 am America/Los Angeles (Pacific).  A vote
> was taken on the call and the newly proposed time was accepted by all in
> attendance.  The new call time will make it easier for everyone in Europe
> to attend, since the calls will start earlier in the evening, while still
> allowing the calls to take place during daytime business hours in the
> United States.  The new call time is equivalent to:
>
>    - America/New York (Eastern) 12:30 pm
>    - Europe/Amsterdam (Central) 6:30 pm
>
> Due to occasional differences for a couple of weeks each year in the start
> and end dates of Daylight Savings Time in the United States and Summer Time
> in Europe, everyone will use the America/Los Angeles (Pacific) time zone,
> in case of conflicts, to determine the start time of each week’s Zeta
> Alliance call.  The next Daylight Savings Time change in the America/Los
> Angeles (Pacific) time zone takes place on November 1, 2020.  This page (
> https://en.wikipedia.org/wiki/Daylight_saving_time_in_the_United_States )
> provides guidance on the start and end dates for Daylight Savings Time in
> the America/Los Angeles (Pacific) time zone.
>
> *Making It Easier For Vendors and Developers To Integrate With Zimbra*
> Marc G. cited an example of one of his customers that is using a calendar
> product that has been integrated with Office 365 and Gmail, but not
> Zimbra.  He asked for ideas from those on the call about how Synacor can
> make it easier for both software vendors and independent developers to
> integrate their apps with Zimbra, as they often do currently with Office
> 365 and Gmail.  He suggested that if Zimbra could provide an application
> programming interface (API) compatible with Microsoft Graph (
> https://docs.microsoft.com/en-us/graph/overview ), that it may be easier
> to get new software vendors and developers onboard to integrate with
> Zimbra, since they could theoretically re-use their existing Office 365
> integration for an easy integration with Zimbra.  John E. said a business
> case would need to be made for this in order to allocate resources to such
> an effort within Synacor, and that it could prove difficult to engineer a
> work alike API to Microsoft Graph in Zimbra, since Graph is a proprietary
> API subject to unexpected changes that also relies heavily on
> Microsoft-only services that would need to be referenced directly.  Randy
> L. suggested that perhaps Zimbra Professional Services could more actively
> promote their ability to assist vendors and developers with product
> integration when a Zimbra customer does not have the in-house development
> resources to do so themselves.
>
> John E. said a common complaint is that Zimbra 8.8’s API is based around
> the SOAP standard, while much of the world has moved on to other
> integration techniques.  He added that Zimbra 9 has a new GraphQL API (
> https://graphql.org/ ) available that makes integrations similar to
> Microsoft Graph possible, and that the Modern UI in Zimbra 9 is built on
> GraphQL.  Barry D. said that a JavaScript library supporting GraphQL is
> available at: https://github.com/Zimbra/zm-api-js-client and he has
> written a how-to at:
> https://blog.zimbra.com/2020/08/zimbra-skillz-using-tags-and-graphql-from-a-zimlet/
> .  He added that with the development of the Modern UI in Zimbra 9, a new
> authentication mechanism utilizing JWT ( https://jwt.io/ ) was added,
> that replaces the Zimbra AUTH_TOKEN. The JWT support provides the
> foundation for rich security configurations, and impersonations, in a
> standard way.  Barry D. also suggested taking a look at
> https://github.com/Zimbra/zimbra-zimlet-tags .  Cine offered that if
> anyone needs someone to turn their ideas in to a Zimlet or integration with
> Zimbra, that the Zextras development team can also take on such work, and
> said to send him a note for further discussion.
>
> *New Zimlet For Creating And Using Email Templates*
> Barry D. shared a Zimlet that can be used for creating and using email
> templates: https://github.com/Zimbra/zimbra-zimlet-email-templates .
> This Zimlet makes it easy for those who send many similar looking emails to
> convert those messages in to templates, where place holder values in the
> template can be replaced with the desired content before sending.
>
> *Updated Zimlet For Integrating Nextcloud With Zimbra 9*
> Barry D. announced that he has updated a Zimlet for integrating Nextcloud
> in to Zimbra 9 that has been published to the Zimbra repos, but has not yet
> been documented in the Zimbra Administrator’s Guide.
>
> *Avoiding Backscatter Spam For External Anti-Spam Appliances*
> David M. said he is working on setting up a new anti-spam appliance,
> external to his Zimbra installation.  His prior anti-spam appliance
> performed LDAP look-ups via Zimbra to determine whether or not the
> appliance should accept a message from a sender for delivery, which avoids
> issues with backscatter email (
> https://en.wikipedia.org/wiki/Backscatter_(email) ).  However, his new
> anti-spam appliance does not provide this LDAP look-up capability, so he
> has alternatively looked at using Postfix’s VRFY feature to check with
> Zimbra if a sender’s message should be accepted.  He explained that the
> VRFY feature works well for regular Zimbra mailboxes, but does not work
> correctly for Zimbra email aliases.  He has observed messages sent to email
> aliases being accepted by the anti-spam appliance, then by Zimbra, which
> are later rejected by Zimbra resulting in backscatter email.  Noah P. said
> he had encountered the same issue in the past and recommended adjusting
> this setting in Zimbra:
> https://zimbra.github.io/zimbra-9/adminguide.html#_protect_alias_domains_from_backscatter_spam
> .  Marc G. commented that the way his organization worked around this issue
> was to stand up an independent LDAP server, external to Zimbra, which both
> Zimbra and his anti-spam system use for verifying recipient email
> addresses.  He said given the preference, he would like to see a direct
> integration with Zimbra.
>
> *Mitigating Zero-Day Malware And Neutralizing Phishing Links Via Email*
> Marc G. said that a common issue his organization encounters is that email
> arrives in customer Inboxes that contain zero-day malware that cannot yet
> be detected by any anti-virus product.  In those instances, his team
> investigates by uploading the suspect email attachments to VirusTotal (
> https://en.wikipedia.org/wiki/VirusTotal ), and often finds that few, if
> any anti-virus (AV) products detect the malware.  But then, over time, AV
> products begin to detect the suspect file as malware, as updated malware
> definitions become available.  He said he would like to see a means in
> Zimbra to either recall or delete messages found to be containing zero-day
> malware from customer Inboxes in an automated manner.  However, this is
> likely to be tricky as it relates to privacy, since it may require some
> level of access to customer mailboxes.
>
> Randy L. commented that all AV products are fundamentally flawed, since
> they operate on the model of trust everything by default, but block only
> select content, based on malware signatures that will always trail the
> release of new malware variants.  This is as compared to the more effective
> deny by default approach (aka application white listing), where only
> approved content is allowed to pass.  He explained that the way his
> organization mitigates the issue Marc described is by quarantining all
> email by default that contains any type of executable content, in addition
> to quarantining all Office files that contain macros.  For emails
> containing either of these types of files, the original recipient of the
> message receives a notification that a file has been removed from the
> original email, but can be released from the quarantine, if the recipient
> trusts the sender and was expecting the message.  All other messages
> containing attachments then continue on through normal AV checks using
> multiple AV products.
>
> Noah P. suggested that for mitigating phishing links in emails, it would
> be interesting to do an integration with Zimbra for Cuckoo (
> https://cuckoosandbox.org/ ) where a suspect link in an email could be
> opened safely by a recipient in a sandbox.  He also referred to this blog
> article discussing a similar integration:
> https://blog.rootshell.be/2012/06/20/cuckoomx-automating-email-attachments-scanning-with-cuckoo/
> .  Randy L. commented that he thinks this is the basis of how the
> Proofpoint service works, where suspect links are rewritten in a received
> message, so clicked links are opened in either an ephemeral VM or container
> on a remote server, rather than the recipient’s local computer, and the
> recipient is instead viewing the suspect link through a VNC-like remote
> session, so their local computer remains safe.
>
> *Avoiding Business Email Compromise Security Incidents*
> Marc G. commented that one of his concerns is Business Email Compromise
> (BEC):
> https://www.fbi.gov/scams-and-safety/common-scams-and-crimes/business-email-compromise
> ).  A BEC is a security incident where an attacker gains control over a
> Zimbra user’s mailbox, most often via a successful phishing attack.  Randy
> L. commented that he has read security bulletins indicating that Office 365
> accounts that lack two-factor authentication, are being particularly hit
> hard as of late with these types of security incidents.  In those cases, an
> attacker quietly maintains persistent access to a victim’s mailbox by
> setting up inbound and outbound filtering rules that automatically forwards
> a copy of any messages sent or received from the victim’s email account to
> the attacker.  This allows the attacker to observe the normal flow of email
> over a period of time.  When the attacker sees a financial transaction
> being discussed, the attacker will then intervene by impersonating either
> the sender or recipient of a message, advising one of the parties to make a
> last minute change to the financial details, usually so a payment can be
> routed to a bank account under an attacker’s control, thereby completing
> the goal of a BEC.  Many security teams are overlooking this type of
> intrusion in to mailboxes, as suspicious filtering rules are normally not
> checked by most organizations during security audits or threat hunting.
> Marc G. commented that his organization has personally experienced at least
> one BEC incident where they were contacted by someone out-of-band (by
> phone) asking to verify the changed banking information for a payment
> transaction, thereby defeating the attack.
>
>
> 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/20201014/cb1c6309/attachment.html>