What are some of the email transmission standards and protocols that a library should implement to ensure privacy and reliable delivery? Can libraries depend on reliable email delivery for important communications such as circulation notices? How does email fit into marketing campaigns?
Although a mainstay for personal and professional communications, email has also become notorious for its many problems and complications. Since email persists as libraries' primary channel of communications with their users, it is important to be aware of the technical issues and trends in the way it is used.
The number of email messages sent via the internet is massive and continues to grow. An estimated 293.6 billion email messages were transmitted in 2019.5 Not all email messages involve intentional or wanted use: spam email represents over 55 percent of email traffic. The frustrations of email and the convenience of interactive messaging apps such as SMS (short message service), iMessage, WhatsApp, Facebook Messenger, and others have come to replace email for many types of personal communication. Slack, Microsoft Teams, and IRC have seen ever increasing use for workplace communications.
These use patterns have implications for the way that libraries communicate with their patrons. While almost all library patrons may have one or more email addresses, they may not necessarily check email regularly. Almost any integrated library system can be configured to also send notices via SMS. Patrons may be reluctant to opt to receive notices this way, possibly out of concern that they will be overloaded with spam via their mobile phones like they experience on their email accounts. Even if a portion of messages can be offloaded to SMS, email will likely continue as the primary way that libraries send messages to their patrons for the foreseeable future.
The main questions with email concern trust and reliability. How do you know that the message is from its stated sender? Is the message sent and received intact, or has it been intercepted and altered in transit? Is the message private, or can others intercept and read it? Does the message contain meaningful content, or has it been generated through bulk advertising? Does it contain malware or link to a malicious site with malware? Is it a message that tempts the receiver to divulge personal information or to fall prey to some type of scam? Many attacks rely on social engineering to take advantage of naive victims. All these scenarios are so common that they diminish trust in email as a communications medium. Fortunately, the email ecosystem has evolved to provide multiple layers of protection for each of these possible types of misuse. To be considered trustworthy, mail services must implement a complex set of protocols and standards that validate the identity of the sender, the integrity of the message, and guard against most patterns of unwanted or dangerous solicitations.
Gmail, Microsoft Outlook and Exchange, Yahoo Mail, and other major providers of email services have implemented sophisticated infrastructure based on the latest security practices and protocols to safely send and receive messages. Major mail services pass each message through sophisticated algorithms to categorize them according to risk level, automatically rejecting those that fall into obvious categories of unwanted mail and flagging those deemed suspicious. These services offer an option to automatically place suspicious messages into something like a “Junk Email” or to automatically delete them.
The Apache SpamAssasin, a widely implemented open source application for mail filtering, evaluates a complex list of factors to assign each message a score representing the likelihood that it is spam (see: https://spamassassin.apache.org). Errors in technical implementation of mail delivery, suspicious patterns of content, or an origination from a source known to be associated with spam generation result in scores that may fall below the mail service's threshold for trustworthiness. There are circumstances where libraries need to generate messages to their users or community members. Notices from the library's integrated library system are the classic example. Other scenarios include messages related to event registration, program announcements, or general marketing and publicity. The applications that generate these messages must be configured to format and transmit email messages in strict conformance to the applicable standards and protocols and to follow practices that will ensure their classification as safe for delivery and not rejected as spam.
A number of standards and protocols are involved in the secure and reliable transmission of email messages. Though a bit technical, it is important to have at least a general understanding of the email ecosystem when implementing or evaluating products that involve the generation of email messages to patrons or community members.
In order to generate an email message, the application needs access to a Message Transfer Agent (MTA) that uses the SMTP protocol to transfer the message to the intended recipient(s). Examples of MTAs include Sendmail in the Unix environment or Exchange on Microsoft Windows servers. SMTP uses a series of conversational directives where the application provides mandatory header fields (to: from: subject: date), optional supplemental fields, and the body of the message. It is essential to control access to the MTA by requiring some type of strong authentication before initiating a SMTP sequence. Failure to do so results in an “open relay,” which enables unauthorized agents to generate mail via the institution's domain.
Sender Policy Framework
SPF, or the Sender Policy Framework, describes a set of configuration practices that confirm that the MTA is authorized to deliver email on behalf of the domain name representing the organization. This framework includes entries in the DNS (Domain Name System) configuration for that domain. Since DNS configuration details are strictly controlled and can only be made by authorized domain administrators, these configuration entries can be considered as trustworthy. Basic configuration details related to email include the creation of an MX record specifying the mail server authorized for the domain and a PTR entry that enables a reverse DNS lookup, which is useful to email validation. SPF goes beyond these basic DNS entries and involves the creation of a TXT entry in the DNS record for the domain that lists the IP addresses or domains of the authorized MTAs. Receiving mail systems will perform a DNS lookup that validates that the MTA that originated the message properly appears in a TXT entry for that domain. (Example: librarytechnology.org. 37 IN TXT “v=spf1 ip4:xx.xx.xx.xx).
SPF provides a basic level of assurance that the email agent that generated the message is authorized to do so, but does not address every possibility for abuse.
DomainKeys Identified Mail
DKIM, or DomainKeys Identified Mail, provides an additional layer of features that ensure the integrity of the message. It addresses the concern that the message received has not been modified in any way from its original form. DKIM accomplishes this validation via encryption technologies involving public and private key. The application generating the email message produces multiple cryptographic signatures that can be used to validate the integrity of the delivery headers and the body of the message. Hashes are generated using the private key, which is never shared publicly. The DKIM routines then insert an additional header into the message, which is used by the receiver to validate the message. Validation of a cryptographic hash requires access to the public key, which is published in the DNS entry in the sender's domain record in a TXT entry.
Example of a dkim TXT entry:
dkim._domainkey.librarytechnology.org: v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AM IIBCgKCAQEAvP/zFa1IAR3HZM6i44ksmvvxOr BMztncbYiqPXWnNljRoOg6x2CMwZPVaODsETp AfSlDff42j0tkP2ZQ0SYNJu6bGlKFKJSvsp+g6FAcnslw3S SN6lDLATQS4zsjLTiZeS/WfsjRMcxL67usCuH80/fy Bnt0piTnbOx5QmQpAittwGzctm6ICkHPB8h6oXiV jaab8XBRStOrhDUe76ILVkDr0ppIlqhkf404mSOsow LfU6c5RDmcrYh5xij1sxS/apR/gzSdd4hSuaoIMeeVX4+ DHllsYLuPO4AsbkHVqn0djYIL6+rh/q70CYvID6 ZI40fIhvLjQ8QRmeUAGc3TwwIDAQAB;
Example of a DKIM signature provided in a message header
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=librarytechnology.org; h=to:from:subject:date:mime -version:content-type:content-transfer-encoding; s=dkim; bh=Xs6hjsnOsLry/yDSCPIoYzsRK+ddfUi+o99n3sD7L gI=; b=S8EHFNpthh+A8phZuuQX1UTGyRK0koYo+gq Dt2gQC329sn2tMURGXiQUxSPbCvB7m3lgsUB4LuOp/ olZbz0IbUeVamQxkk6dKXGJbir8yhA0349jLzmLyNa ATX2DsLsGukpoLtEArRPDYJ0r0kiJXWHiGXv1oAt 22ziFZMy57I724cQQw5RcaOct2HpFyfGNOCiW0AD +i+64UHxMThj25LKrDbQsbocjhPweWlpwkF7nCP D0kA36bNCyPCi8zmE0v9W3k+njA0vPs0j+p0ITxTyI Y7cfSj9G7GU0R6jpsgLN4HjnPtkSt398FTHThXpNg/ J58pEE7gQkOBUKkEhzQ==
This signature includes multiple components, including: the DKIM version, the algorithm for canonicalization for message body and headers prior to generating the hash and signature, the selector referenced in the DNS entry, and the base64 hashes for the message body and for the full message. The body hash applies only to the message body and can be validated without reference to the public key. If the body hash is valid, the receiving mail system will perform a DNS request to access the public key for validation of the digital signature of the message. If all these steps are successful, the DKIM signature is considered valid. Implementation of DKIM is a bit complex, but gives strong confidence to the integrity of the message.
Domain-based Message Authentication, Reporting, and Conformance
DMARC builds on SPF and DKIM, adding an additional layer that enables reporting and accountability in the email ecosystem. Also implemented as a TXT entry in the DNS, DMARC aligns to existing SPF and DKIM entries and provides addresses to send and receive email performance and exception reports. These reports enable a mail administrator to know if unauthorized or invalid messages were sent on behalf of their domain.
Multiple Interrelated Protocols Increase Trust
The implementation of this full suite of email protocols can be a bit complex, even for experienced systems administrators. Fortunately, most libraries will not need to implement them directly. In most cases the vendor of the ILS, event management system, or automated marketing solution will attend to these details. Libraries should, however, require that these vendors demonstrate that these protocols have been implemented and produce fully validated messages. This is especially important if the messages are sent using the library's own domain, which is the preferred approach. Libraries would generally prefer that the messages send on their behalf come from an email address like firstname.lastname@example.org rather than something like email@example.com.
These protocols and procedures provide a basic technical foundation for a library's email messaging environment. With this foundation in place, email can better serve as a component of an overall messaging strategy that includes other channels such as mobile messaging and social media. Many libraries are working toward communications strategies that go beyond support of transactional interactions, such as circulation notices, to also encompass broader campaigns in support of stronger engagement with existing patrons and to reach more broadly into their service community.
- “Number of sent and received e-mails per day worldwide from 2017 to 2023” Statistica, 2019, https://www .statista.com/statistics/456500/daily-number-of-e-mails -worldwide.
- “Global spam volume as percentage of total e-mail traffic from January 2014 to December 2019, by month.” Statistica, 2020, https://www.statista.com/statistics/420391 /spam-email-traffic-share.