[Search] [pdf|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03                                                   
Network Working Group                                         A. Brotman
Internet-Draft                                                   Comcast
Intended status: Best Current Practice                           T. Zink
Expires: January 31, 2021                      Zink Magical Contraptions
                                                             M. Bradshaw
                                                           July 30, 2020

   Receivers Guidance for Implementing Branded Indicators for Message
                         Identification (BIMI)


   This document is meant to assist receivers or other mailbox providers
   by providing guidance to implementing Brand Indicators for Message
   Identification (BIMI).  This document is a companion to the main BIMI
   drafts which should first be consulted and reviewed.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on January 31, 2021.

Copyright Notice

   Copyright (c) 2020 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must

Brotman, et al.         Expires January 31, 2021                [Page 1]

Internet-Draft                   BIMI-RG                       July 2020

   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Goals for BIMI  . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Should your site implement BIMI?  . . . . . . . . . . . . . .   3
   4.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   5.  Site implementations  . . . . . . . . . . . . . . . . . . . .   4
   6.  Validation of a BIMI message  . . . . . . . . . . . . . . . .   5
     6.1.  BIMI Site Requirements  . . . . . . . . . . . . . . . . .   5
     6.2.  Verified Mark Certificate (VMC) Validation  . . . . . . .   6
   7.  Communicating BIMI results between the MTA and the MUA  . . .   6
     7.1.  Image Retrieval . . . . . . . . . . . . . . . . . . . . .   6
     7.2.  TTL of cached images  . . . . . . . . . . . . . . . . . .   7
     7.3.  Image Display . . . . . . . . . . . . . . . . . . . . . .   7
     7.4.  Privacy Concerns  . . . . . . . . . . . . . . . . . . . .   7
     7.5.  Basic flow example  . . . . . . . . . . . . . . . . . . .   8
     7.6.  Message Classification  . . . . . . . . . . . . . . . . .   9
   8.  Domain Reputation . . . . . . . . . . . . . . . . . . . . . .   9
     8.1.  Rolling up based upon domain vs organizational domain . .   9
     8.2.  VMC Root of Trust . . . . . . . . . . . . . . . . . . . .  10
   9.  BIMI Playbook Checklist . . . . . . . . . . . . . . . . . . .  10
   10. Public documentation  . . . . . . . . . . . . . . . . . . . .  11
     10.1.  Documentation For Brands:  . . . . . . . . . . . . . . .  11
     10.2.  Documentation For Users: . . . . . . . . . . . . . . . .  11
   11. Appendix  . . . . . . . . . . . . . . . . . . . . . . . . . .  12
     11.1.  Glossary . . . . . . . . . . . . . . . . . . . . . . . .  12
   12. Contributors  . . . . . . . . . . . . . . . . . . . . . . . .  13
   13. References  . . . . . . . . . . . . . . . . . . . . . . . . .  13
   14. References  . . . . . . . . . . . . . . . . . . . . . . . . .  13
     14.1.  Normative References . . . . . . . . . . . . . . . . . .  13
     14.2.  URIs . . . . . . . . . . . . . . . . . . . . . . . . . .  14
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  14

1.  Introduction

   The Brand Indicators for Message Identification (BIMI) specification
   introduces a method by which Mail User Agent (MUA, e.g., an email
   client) providers combine DMARC-based message authentication with
   cryptographic methods to ensure the identity of a sender.  If the
   identity is ensured, the MUA can then retrieve sender-selected
   iconography to display within the MUA.  This displayed iconography
   grants the sender brand impressions via the BIMI-capable MUA, and
   should be a driving factor for the adoption of authenticated email.

Brotman, et al.         Expires January 31, 2021                [Page 2]

Internet-Draft                   BIMI-RG                       July 2020

1.1.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "OPTIONAL" in this document are to be interpreted as described in
   [BCP 14] [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

2.  Goals for BIMI

   As stated in other BIMI drafts, BIMI intends to advance email
   authentication by granting a sending party brand impressions as long
   as the message passes authentication mechanisms and meets other
   receiver qualifications (reputation, encryption, allow listing, et
   cetera).  DMARC currently has wide adoption by some of the Internet's
   larger brands, but there is still a long tail of small-to-medium size
   brands (and many large ones) that do not have it.  Because BIMI
   provides a visual presence in the inbox, and because visual
   impressions are desirable for brands, BIMI provides an incentive for
   marketers to spur DMARC adoption, whereas a concern purely from
   security may not.

3.  Should your site implement BIMI?

   If your site satisfies the Section 6.1, this is likely a "yes".

   As email has evolved over the past three decades, it is no longer a
   medium of merely exchanging text, but of enabling people to build
   rich experiences on top of it.  BIMI provides an incentive for brands
   to send email more securely because the desired behavior - a visual
   imprint in the inbox - first requires DMARC adoption.

4.  Terminology

   The following terms are used throughout this document.

   o  MTA

   o  MUA

   o  DKIM

   o  SPF

   o  DMARC

   o  Alignment

Brotman, et al.         Expires January 31, 2021                [Page 3]

Internet-Draft                   BIMI-RG                       July 2020

   o  Verified Mark Certificate (VMC)

   o  Recipient Domain

   o  Sending Domain

   o  MVA

   For definitions of these terms, see the Appendix.

5.  Site implementations

   In order for a site to correctly implement BIMI, the receiver must be
   able to perform the following:

   o  Validate SPF

   o  Validate DKIM signatures

   o  Validate DMARC

   o  Discover and fetch a BIMI assertion record using DNS

   o  Fetch a SVG using HTTPS

   o  Validate a SVG using a profile

   o  Add Authentication-Results and BIMI-* Headers to a message

   Optionally, for a site to correctly implement BIMI Verified Mark
   Certificate (VMC) verification, the receiver must be able to perform
   the following:

   o  Fetch a VMC using HTTPS

   o  Validate a VMC (a new kind of Extended Validation (EV)

   o  Extract a SVG from a VMC

   A site may wish to implement URI alteration and image caching for
   hosted recipients.  By implementing BIMI, a site agrees that through
   some combination of trust mechanisms, it will instruct a BIMI-capable
   MUA to display the image fetched from a URI within the message
   headers.  This URI is created after the MTA authenticates a message,
   and is also able to authenticate the VMC associated with the sending
   domain.  Discussion of these trust mechanisms is beyond the scope of
   this document.

Brotman, et al.         Expires January 31, 2021                [Page 4]

Internet-Draft                   BIMI-RG                       July 2020

6.  Validation of a BIMI message

6.1.  BIMI Site Requirements

   In the BIMI specification, a message MUST be authenticated via DMARC.
   As stated in the DMARC draft, this requires that only one of DKIM or
   SPF must successfully pass validation with alignment with the
   organizational domain in the From: address.  However, for additional
   local security measures, a receiving site may choose to create
   additional requirements for senders in order to verify BIMI (that is,
   indicate to a downstream MUA that it is safe to load a BIMI logo in
   the email client)

   This may include, but is not limited to:

   o  Requiring both DKIM and SPF to validate and align with the
      organizational domain in the From: address (whereas DMARC only
      requires one of SPF or DKIM to align with the From: domain)

   o  SPF "strength" requirements (e.g., requiring "-all", disallowing
      usage of "?all" or not allowing inclusion of overly large address

   o  SMTP delivery via TLS

   o  Feedback Loop registration or other method of registration with
      the receiving site

   o  Domain reputation via a DNS allow list or other reputation system

   These localized requirements are at the discretion of the receiving
   site.  In general, the stricter the criteria, the less chance there
   is of an MUA erroneously showing a logo and giving the wrong signal
   to a user.

   Upon receipt of an email, a receiver that implements BIMI should
   remove or rename any previously existing BIMI-* headers other than
   BIMI-Selector, as they may have come from an attacker (as long as the
   BIMI-Selector is covered by the DKIM signature; if not, it should be
   removed, renamed, or ignored).


   o  It may be useful to have messages exiting a site to have those
      BIMI-* headers removed as well.

   o  It is useful for a site that has not implemented BIMI to remove
      those headers so that an MUA that does make use of those headers

Brotman, et al.         Expires January 31, 2021                [Page 5]

Internet-Draft                   BIMI-RG                       July 2020

      would not accidentally display a BIMI image when the message has
      not been properly authenticated by the email receiver (even though
      an MUA should not make use of BIMI headers and instead rely upon
      settings from the mailstore, it is possible that some MUAs will
      nevertheless use headers without taking appropriate precautions).

6.2.  Verified Mark Certificate (VMC) Validation

   (Currently, see document in Reference below)

7.  Communicating BIMI results between the MTA and the MUA

   In order for a receiver that has implemented BIMI to notify an MUA
   that it should display the images:

   o  An MTA must verify BIMI, and if it passes, add additional headers
      containing the logo to be displayed.

   The MUA must check to see if a message passed BIMI before loading the
   BIMI image.

   While the MTA MAY stamp BIMI-related information in the message
   headers, they should not be relied upon by an MUA without additional
   checks to make sure they were added by a trusted source, for example,
   making sure the MTA strips existing headers on ingress, or by
   checking for a bimi pass in a trusted Authentication-Results header.

7.1.  Image Retrieval

   A core part of the BIMI specification is that the MUA will retrieve
   an image file to display for each BIMI-validated message.  There are
   multiple ways to accomplish this, for example:

   o  In its most basic setup, a BIMI-capable MUA could retrieve the
      image file directly from the site specified in the BIMI-Location

   o  A BIMI capable MTA will add a header containing the Base64 encoded
      SVG of the image file.  The MUA can use this header to retrieve
      the already validated image file for display.  This is the
      recommended method of image retrieval as the work of retrieval and
      validation has already been done by the MTA.

   o  Other providers may choose to cache the associated images in a
      local store which could be used as the BIMI resource address in
      the headers of a BIMI-approved message in a sort of proxy

Brotman, et al.         Expires January 31, 2021                [Page 6]

Internet-Draft                   BIMI-RG                       July 2020

7.2.  TTL of cached images

   In some circumstances it is necessary to cache the images that an MUA
   would want to load.  For example, if a domain owner has a short TTL
   time, it would force the MUA to look it up in an unreasonably short
   period of time.  In this case, a receiver may want to set its own

   One option is to set it to several hours, or a day; another option is
   to set the TTL to the same as the expiration period in the VMC that
   contains the BIMI image.  The downside is that the caching mechanism
   might need to check for certificate revocation, and then re-fetch

7.3.  Image Display

   Although BIMI does not define an aspect ratio for Brand Indicators it
   is expected that the majority of receivers will display them in a
   square or circular space.  Is it recommended to brands that their
   Indicators should be constructed to display in a 1:1 aspect ratio,
   receivers should design the user interface display for BIMI
   Indicators with this in mind.

7.4.  Privacy Concerns

   There is some concern that the retrieval of the iconography could
   result in a privacy leak.
   As the images are retrieved, it's possible that the image provider
   could track the retrieving system in some way.  This has implications
   whether it be the sender or provider that is hosting the image.  For
   example, a sender could include a singular selector for a single
   recipient, or a provider could append a tracking string to the image
   URI in the header.

   A receiver may choose to track the number of selectors an
   organizational domain is permitted to use and deny processing if this
   exceeds a defined limit.  Similarly, a receiver may choose to track
   and limit distinct Indicator URLs.

   MTAs are encouraged to cache BIMI Records, VMCs, and Indicators to
   limit tracking.

   MUAs are encouraged to extract Indicators from the BIMI-Indicator
   header rather than retrieving them directly from the source, as doing
   so will limit any data exposure to the MTA processing the message.
   The BIMI approved SVG profile prohibits an SVG from loading external
   elements, this removes the risk of tracking when an Indicator is
   shown in the client.

Brotman, et al.         Expires January 31, 2021                [Page 7]

Internet-Draft                   BIMI-RG                       July 2020

   An in-depth discussion of all the potential privacy leaks with
   respect to loading or embedding images is outside the scope of this

7.5.  Basic flow example

   One sample implementation of BIMI by a receiver, who does everything
   on-the-fly, is as following:

   o  Upon receipt of a message, the receiver checks to see if the
      message passes aligned-SPF or DKIM, and DMARC, and ensures that
      the sending domain has a DMARC policy of "quarantine" or "reject"
      per local receiver policy, while properly applying the appropriate
      DMARC policy to the message.

   o  If the message passes prior checks, the receiver will then check
      to see if the domain in the From: address has a BIMI record (or,
      if the message has a BIMI-Selector header that is covered by the
      DKIM-Signature, uses that to do the BIMI query in DNS).

   o  If a BIMI record is found, the receiver then retrieves the VMC
      from the location that the BIMI record points to, and attempts to
      verify the VMC using a trusted root certificate. .

   o  Upon successful verification of the VMC, the receiver extracts the
      verified image from the VMC.  If the SVG also passes the SVG
      validation steps then this is a successful BIMI verification.

   o  If the BIMI verification fails then the MTA must not indicate to
      the MUA to show a BIMI image.  The MUA MAY show a default image
      such as a set of initials, or unidentified sender.

   o  The email receiver then does the rest of its anti-spam, anti-
      malware, and anti-phishing checks as discussed in Section 7.6

   o  The email receiver then adds the relevant Authentication-Results
      and BIMI-* headers to the message to signal to the downstream
      email client that the message passed BIMI and that is safe to load
      the logo.

   o  Eventually, the MUA checks the BIMI-* headers, decodes the image
      in the BIMI-Indicator header, and displays it as the sender photo
      (or however else it chooses to render the BIMI logo in conjunction
      with the message).

Brotman, et al.         Expires January 31, 2021                [Page 8]

Internet-Draft                   BIMI-RG                       July 2020

7.6.  Message Classification

   The successful validation of BIMI does NOT indicate that a message is
   not spam, malware, or phishing.

   It is expected that receivers undertake their usual message filtering
   and classification steps, and take the results of these checks into
   consideration when deciding if a BIMI Indicator should be shown to
   the user.

   If classification is preformed before BIMI is evaluated then a
   receiver MAY CHOOSE to skip BIMI processing for that message, in this
   case they SHOULD add a bimi=skipped entry to the Authentication-
   Results header for that message, and SHOULD add a comment stating the
   reasons for skipping BIMI processing.

   If a message is classified as phishing or malware then the MUA SHOULD
   NOT display the logo.

   If a message is classified as spam (meaning that the message comes
   from a known brand, but contains spammy content), then the email
   receiver MAY choose not to display the logo.

8.  Domain Reputation

   Receivers are advised to consider incorporating local sources of
   domain trust intelligence into the processes which ultimately
   determine whether or not BIMI logos are displayed.  Simply because a
   sending domain passes BIMI requirements does not mean the images
   should automatically be displayed in the MUA; a site may impose
   further restrictions based on domain reputation.

   One source of additional reputation intelligence could be a platform
   that the email provider has created to calculate domain trust based
   on historical traffic; another is an explicit list of trusted domains
   that has been curated by an individual provider; a third is a list
   that is purchased from a vendor that might be a pass/fail or a scored
   list; another option is some mix of any of the previous three.

8.1.  Rolling up based upon domain vs organizational domain

   BIMI is designed to be able to work on selectors, and so in theory a
   brand/domain could specify multiple BIMI logos and differentiate them
   on a per-domain (per-selector) basis.  The advantage for the brand is
   that they can choose the image they want the user to see depending
   upon various conditions (e.g., seasonal images, regional images,

Brotman, et al.         Expires January 31, 2021                [Page 9]

Internet-Draft                   BIMI-RG                       July 2020

   However, for an email receiver, it may be easier to roll up BIMI
   logos on an organizational domain basis.  One reason may be for the
   purposes of reputation, another may be for simplifying management of
   images.  In this case, it would need to be made clear to brands that
   this is how the loading of BIMI images works.  This documentation
   could live on a postmaster site, under technical documentation, or
   other official page maintained by the receiver.  It could then be
   referred to when sending organizations ask about how to on-board to
   BIMI at the receiver, and provide official guidance about the way it
   works at the site.

   If rolling up by organizational domain, then it may make sense to use
   a "lowest common denominator" approach.  That is, an organizational
   domain must meet all the requirements for BIMI, rather than only a
   subdomain.  The reason for this is that if sub.brand.com gets an
   image due to having strong authentication policies, but brand.com
   does not, then this may cause confusion because a user may learn to
   associate sub.brand.com and its image with brand.com; and if
   brand.com can be spoofed even though sub.brand.com cannot, that can
   lead to users becoming more susceptible to phishing from brand.com.

   To alleviate this, receivers may wish to show logos only for domains
   that have organizational domains with strong DMARC policies.  Or, if
   an organizational domain does not have a strong DMARC policy but a
   subdomain does, then it may treat the organizational domain as if it
   does have a strong DMARC policy so as to prevent a phisher or spammer
   from impersonating the brand or any of its subdomains.

   A strong DMARC policy may be defined as one which has some level of
   enforcement. ie, a p=quarantine policy with an effective pct=100, or
   a p=reject policy.

8.2.  VMC Root of Trust

   VMCs are verified back to their issuing Certificate Authority (CA).
   Receivers may wish to maintain their own list of trusted CAs for BIMI
   rather than relying on a generally available bundle of trusted Root
   Certificates such as those distributed with browsers or operating
   systems.  The Authindicators Working Group will maintain a list of
   known VMC Root CA Certificates to help bootstrap such a list.

9.  BIMI Playbook Checklist

   There are several factors to consider for email receivers on things
   that can go wrong; below are a handful of considerations:

   o  Failing to verify a VMC

Brotman, et al.         Expires January 31, 2021               [Page 10]

Internet-Draft                   BIMI-RG                       July 2020

   o  Failing to extract an Indicator from a validated VMC

   o  Failing to validate a SVG against the recommended profile

   o  Failing to parse a gzipped SVG Indicator

   o  Failing to load a logo in the email client

   o  Failing to access the logo (e.g., permissions errors)

   o  Connectivity problems to the logo

   o  Failing to display a correct logo in the email client

   o  Having the wrong logo stored for a brand (i.e., uploading it to a
      local store but associating it with the wrong brand)

   o  Caching a logo for too long after it has updated

   There are many reasons why a logo may fail to load; having tools to
   investigate (logs, headers in messages, internal documentation that
   is clearly written, having the knowledge pushed out to multiple
   escalation channels) is important for investigation.

10.  Public documentation

10.1.  Documentation For Brands:

   It is ideal to publish the criteria that is used by your site to
   determine when BIMI will be displayed.  It is fine to say that you
   use some internal domain reputation metrics as additional criteria to
   determine whether or not a logo should be displayed, and it isn't
   necessary to give away the exact nature of the algorithm other than
   to say "You must maintain good sending practices."

   If you use an explicit allow list, a site may want to list the
   minimum requirements, and the method of applying to be listed.
   Similarly, a provider may wish to state what type of activity will
   revoke the decision to display logos previously approved.

10.2.  Documentation For Users:

   BIMI is not meant to instill additional trust in messages, and it is
   important to make this known to your users.  All messages, even those
   with logos, should still be treated with (mild) skepticism, and any
   action regarding the message should still be individually evaluated.
   It's possible for a site that has a high trust value to become
   compromised and send fraudulent messages that could compromise a

Brotman, et al.         Expires January 31, 2021               [Page 11]

Internet-Draft                   BIMI-RG                       July 2020

   user's system.  Ensure your customers have a place that documents
   BIMI and demonstrates how to check messages for fraud.

11.  Appendix

11.1.  Glossary

   o  MUA - Mail User Agent - The application used to read messages by
      the end user.  This could be a thick client or a web-based

   o  MTA - Mail Transfer Agent - Software used to transfer messages
      between two systems, typically between two sites, using SMTP as
      the protocol.

   o  SPF - Sender Policy Framework [1] - SPF is a framework that
      designates which systems should be sending for a given domain.
      This can be a list of IPs, CIDRs, or references to DNS records.
      As the sender should be controlling their DNS, they should
      understand which IPs should be sending as their domain.

   o  DKIM - DomainKeys Identified Mail [2] - DKIM is a system by which
      a chosen set of headers, combined with the message contents, are
      cryptographically signed, and then validated by the receiving
      system.  Using DNS, the receiving system can retrieve a public
      key, and then validate the signature within the headers of a
      message.  When implemented properly, the systems responsible for
      sending the messages for a given domain name should be the only
      ones capable of creating messages that correctly validates.

   o  DMARC - Domain-based Message Authentication, Reporting, and
      Conformance [3] - DMARC is a message authentication mechanism that
      works with SPF and DKIM.  The BIMI specification requires that a
      message passes DMARC.  In order for a message to pass DMARC, one
      of SPF or DKIM must successfully validate, and the domain in the
      From: address must align with the domain that passed SPF or DKIM.

   o  Alignment - Alignment refers to the organizational domain, as
      defined by DMARC, of the domain in the From: address being the
      same as the organizational domain that passed SPF or DKIM.  For
      example, baz.example.com has an organizational domain of
      example.com; bar.foo.example.com also has an organizational domain
      of example.com.  It aligns with org.example.com, because both have
      the same organizational domain.  A definition of organizational
      domain and methods of discovery may be found in the DMARC [4] RFC.

Brotman, et al.         Expires January 31, 2021               [Page 12]

Internet-Draft                   BIMI-RG                       July 2020

   o  MVA - Mark Verifying Authority - An entity that a receiver uses to
      certify that the iconography that they intend to use with BIMI is
      properly/legally licensed for their use.

   o  DRA - Dispute Resolution Authority - This organization will
      moderate between two entities that believe they are both entitled
      to use a logo.  Receivers should then abide by the decision of the
      DRA as it pertains to logo usage in the MUA.

   o  VMC - Verified Mark Certificate - An Extended Validation
      Certificate is used in conjunction with BIMI to create a place
      where information pertaining to iconography for a sending domain
      can be securely verified.  In the case of BIMI, hashes for an MVA-
      approved set of iconography will be stored in a field within the
      certificate.  This should allow a receiver site to validate the
      retrieved imagery before putting the BIMI image URI into the
      message headers.

12.  Contributors


13.  References

   The full BIMI verification spec can be found at:

   Verified Mark Certificates Usage: <https://docs.google.com/document/

14.  References

14.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

Brotman, et al.         Expires January 31, 2021               [Page 13]

Internet-Draft                   BIMI-RG                       July 2020

14.2.  URIs

   [1] https://tools.ietf.org/html/rfc7208

   [2] https://tools.ietf.org/html/rfc6376

   [3] https://tools.ietf.org/html/rfc7489

   [4] https://tools.ietf.org/html/rfc7489

Authors' Addresses

   Alex Brotman

   Email: alex_brotman@comcast.com

   Terry Zink
   Zink Magical Contraptions

   Email: tzink@terryzink.com

   Marc Bradshaw

   Email: marc@fastmailteam.com

Brotman, et al.         Expires January 31, 2021               [Page 14]