Browse

Tag: security

Adding BIMI to your mailbox service to improve security and user experience

Image by Valimail

BIMI (Brand Indicators for Message Identification) is an emerging industry standard which attempts to drive adoption of strong email authentication, to help fight phishing, spoofing, and fraudulent emails by displaying verified brand images in the inbox. Several mailbox providers, including Gmail, AOL and Fastmail, are now live with BIMI. Are you looking to increase the security and experience for the users of your mailbox service by implementing this new standard as well? With Halon MTA, you’re ready to get started. Our BIMI module does the heavy lifting; verifying the indicators for inbound email and attaching the images to the email for display in the users’ inbox. Currently there are very few MUAs with BIMI support, but if you develop your own webmail or app the BIMI group has guidance for how to display the verified logo in your user interface.

What BIMI is, and how it works

In short, BIMI displays verified brand images in users’ inboxes, visible even before messages are opened. It builds upon the existing email authentication standards (SPF, DKIM and DMARC), and incentives email senders to embrace those technologies by increasing their brand impression. According to Agari, only 24% of Fortune 500 sending domains are authenticated. BIMI improves visibility and engagement for the brands, while at the same time increasing security for users. It roughly consists of the following steps;

  1. The brand sending the email first needs to implement email authentication (enforcing DMARC) for their domain name.
  2. The brand then creates an appropriate image of their trademarked logo, optionally applies for a Verified Mark Certificate (VMC), stores it on a HTTPS location, and points at it with a BIMI DNS record.
  3. When a BIMI-enabled mailbox service (like Gmail) receives an email from the brand to a specific recipient, the mailbox service’s MTA first verifies that the email is in fact from the sending brand using email authentication like DMARC.
  4. If the email is successfully authenticated, the mailbox service’s MTA checks if the sending brand’s domain has BIMI, and if so, verifies that logo against the VMC certificate authorities or using some other reputation system.
  5. If the brand’s BIMI logo was successfully verified, it is attached to the email (for example as a header), before the email is shipped off the recipient’s inbox.
  6. Finally, the recipient looks at her inbox using the mailbox service’s webmail or app, which displays the brand’s logo next to the address and subject in the email listing.
Getting started with BIMI validation on Halon MTA

Halon was the first commercial MTA to add support for many great new security standards such as DMARC, EdDSA DKIM (elliptic curve), DANE and MTA-STS. To our knowledge, we’re the first to add BIMI validation as well. Our BIMI validation module is only 182 lines of Halon script, which I think is pretty impressive (especially considering that it includes a basic ASN.1 parser). To get started with BIMI on Halon MTA, just check out the BIMI module to your configuration repository, add the following to your end-of-DATA script hook. The module uses some X.509 functions from the unreleased Halon MTA 5.8, please let us know if you want to try it out. As for showing the images in your webmail or app, we’re happy to provide guidance and examples.

import $calist from "bimi/ca.crt";
import { bimi, bimi_vmc } from "bimi/bimi.hsl";
import { dmarc } from "dmarc/dmarc.hsl";

$dmarc = dmarc($mail, $senderip, $senderhelo, $senderdomain);
$bimi = bimi($mail, $dmarc);

// Verified Mark Certificate (VMC)
if ($bimi["record"]["a"]) {
	$bimi_vmc = bimi_vmc($bimi, $calist);
	if ($bimi_vmc["indicator"]) {
		$mail->addHeader("BIMI-Indicator",
			str_strip(array_join(pcre_match_all(#/(^(.{0,49})|(.{0,64}))/, 
					$bimi_vmc["indicator"])[1], "\r\n ")),
			["encode" => false]);
	} else
		echo "BIMI VMC error: $bimi_vmc; $bimi";
} else {
	if ($bimi["error"] and $bimi["class"] != "dmarc" and $bimi["class"] != "dns")
		echo "BIMI error: $bimi";
}

Thank you for reading, and don’t hesitate to reach out if you want to learn more!

Not all successful DSN deploys are successful

Our latest release 5.5 adds support for the RFC 3461 DSN extension, and published a guide on how to get started. At first glance it may seem like a very nifty feature, and one may wonder why it’s not just enabled by default. Fact it, the DNS extension comes with a few peculiarities which need to be considered.

In many email environments, the receiver has multiple store-and-forward MTAs before the message reaches the recipient’s inbox. Each MTA in the path has a different purpose, and may reject the message (if it is spam, for example) rather than deliver it forward. This is what requires MTAs to send “failed” DSN notifications; when an MTA which isn’t your first (edge) rejects a message. The sender always has to be notified as per the transaction safety requirement of email.

One of the features provided by the DSN extension is that you may also request “delivered” notifications by the last MTA before the recipient’s inbox (or “relayed” notifications by the last MTA supporting the DSN extension). This lets the sender know when and if the message was delivered.

Thinking about it, this feature may be nice to have enabled in your MTA for outbound email. It would let you or your users know if and when a message is delivered; rather than only notifying you when and if delivery fails.

If you implement this feature for inbound traffic however, it would be one of your own MTA that would have to send those notifications out to anyone on the Internet that requested them. The notifications would go out from the last MTA in your inbound path. When messages are processed and routed internally, additional information that should not be visible to the sender are sometimes added. Allowing the sender to request a notification possibly containing some of this possibly sensitive information might not be ideal. This concern has be raised many times before, for example in the Exim documentation

Note: Supplying success-DSN messages has been criticised on privacy grounds; it can leak details of internal forwarding.

During our implementation and testing we enabled success notifications for some of our outbound traffic, to see which mailbox providers send such notifications. We were quite surprised to learn that Microsoft includes quite a lot of information regarding the recipients in their success notifications. We instantly reported this to the MSRC team but it was rejected as not being an issue 🙈

Amongst those hundred of lines of X-MS- headers you receive in their success notifications, I’m not sure if the last login time of the recipient is necessary. This is in fact the actual time when the recipient (eg. [email protected]) last checked their email:

X-MS-UserLastLogonTime: 10/1/2020 12:06:31 AM

Bottom line is; should you choose to implement this feature, make sure you do not add sensitive or unnecessary information to your success notifications that may expose your network internals or your customers’ personal information.

Using ARC to work around DMARC’s forwarder issues

Authenticated Received Chain (ARC) is a proposed standard that have been developed to help address issues with DMARC and certain forwarders, such as mailing lists. It defines a standard for how to pass authentication results from one intermediary to another, making this information available to the recipient system. It works even in the case of multiple intermediaries, a.k.a. a chain

DMARC verifies the sender authenticity, as specified by the RFC5322.From header domain name, using SPF and DKIM. Certain indirect email flows such as mailing lists break this by altering the message, while maintaining the original From header. It causes issues for both senders that publish a DMARC policy, and receivers that verify DMARC. The two large mailbox providers AOL and Yahoo published a p=reject DMARC policy for their domains in 2014, causing some disruption for senders on those domains. It occurred when emailing recipients on mailbox services that verifies DMARC via for example mailing lists. This was, and still is, remedied by ad-hoc solutions.

ARC in itself isn’t a reputation system. The specification doesn’t define how the reputation of intermediates should be tracked, nor how public lists should be operated. In other words, as a recipient mailbox provider you still have to operate such systems in order to make use of the information that ARC provides. DMARC.org announced ARC at a M3AAWG meeting in Atlanta, 2015, where it’s been a frequent topic ever since.

include "authentication.header";
include "authentication.arc";

$chain = ARC::chainValidate();
if ($chain["status"] == "pass" or $chain["status"] == "none")
{
	ARC::seal(
			"201805", "example.com", "pki:arc",
			$chain,
			AuthenticationResults()
				->SPF(["smtp.client-ip" => $senderip])
				->DKIM()
				->DMARC()
				->addMethod("arc", $chain["status"], ["header.oldest-pass" => $chain["oldestpass"] ?? "0"])
				->toString()
		);
}

 

We have just released an implementation for ARC (draft 14) on Github, which supports both verification and (re)sealing. It’s written in Halon script, and we’re using it on our own domain to start with. If you’re interested in taking it for a spin, just let us know.

We attend TES security roundtable in London

The very successful TES security roundtable meetings are continuing. This time it brings us to London, UK on May 24th.

The meeting will revolve around DMARC, DANE, email encryption techniques, password protection and SMTP transport protection. Vittorio Bertola, Head of Policy and Innovation at Open-Xchange has assemblied a great line-up. The meeting is an exclusive invite-only event for people working with email infrastructure issues.

Halon 4.6 “curry” with outbound anti-spam

You probably know from before that Halon’s scriptable SMTP server enable email providers to avoid blacklisting and increase deliverability. The 4.6 release, “curry”, contains Cyren’s outbound anti-spam (OAS). In combination with our cluster-synchronised rate limit function, it provides incredibly effective and accurate abuse prevention. Just like their Cyren’s inbound anti-spam, OAS uses a hash-sharing technology called recurrent pattern detection (RPD) that identifies outbreak patterns. It’s designed to detect spam from internal sources rather than external, and doesn’t report/contribute any signatures since it could blacklist your own infrastructure.

With the flexibility of scripting you can determine customer/sender identities accurately even in mixed traffic. This is used as identifier for rate limits based on classifiers such as Cyren’s OAS, delivery failure rate, queue size, etc. By using IP source hashing and alternative IPs for suspicious traffic, deferring obvious abuse and controlling connection concurrency, you can achieve high deliverability with minimal administration.

The 4.6 release comes with many additional features and improvements. It adds SNI support to the TLS functions. The Monaco-based code editor now have additional code completion, built-in documentation, tabs, and a mini-map.

For more information on the release, see the full changelog on GitHub. If you want to try Cyren’s outbound anti-spam, contact our sales team.

Anders Berggren speaker at Driving IT in Copenhagen

Driving IT, on November 3rd in Copenhagen, is a conference that gives a unique insight into the world’s constant changes in IT and development. The host IDA is The Danish Society of Engineers.

IDA Universe wants to strengthen knowledge exchange and personal and development for professionals who engage in technical and science subjects at a high academic level.

One way of doing this is the Driving IT conference, where Halon CTO Anders Berggren will be speaking. His topic is ”The state of email encryption”, addressing the fact that standards such as DANE and MTA-STS are becoming competitive differentiators. Are you in the Copenhagen area? Get your ticket!

Better spam protection in Mölndal municipality

Mölndals Stad (Mölndal municipality) has approximately 5000 employees and 10 000 students. In 2010 the IT department decided that 15 000 inboxes needed a new spam protection.

Anders Westerberg, now Head of IT Security in Mölndal, had built an open-source based solution that worked well. But for Annika Samuelsson, Head of IT development and maintenance, it was clear that they could not go on using a solution that only one person knew how to operate. Together with Anders she investigated possible replacements that could fulfill their wishes, and Halon caught their eye. The Halon software was then newly introduced to the market, and they saw an advantage in the company being open to a dialogue around how the product could be tailored to fit their needs.

The focus was of course on abiding by laws and regulations. Email sent to Mölndal municipality becomes public record and must be archived, even if it’s just spam. Stopping the email before it enters their system saves them that burden, and it’s also the procedure recommended by the organisation SKL (Municipalities and Country Councils of Sweden). Before implementing Halon, Annika and her team handled all spam quarantine, something that is now in the past. With the ”bulk” feature, an email manager will get a report on all blocked unsolicited email.

The result is very satisfying, says Annika Samuelsson

Introducing Halon was a quick process, and even though most of the work was done in-house they received some help from Halon support staff to do the fine tuning. Since becoming a customer, they have reached out a few times to address spam issues.

There have been incidents where we get spam that passes through the filter. But it’s always been very easy to get in touch with Halon and resolving the issues. Once it was actually as easy as a misunderstanding on which users that could report spam.

Mölndal municipality are subject to public procurement, and regularly has to compare their system to market competitors. But they have yet to find a product that solves their problems as effectively and smooth as Halon.

We feel very comfortable with what Halon provides us, and we would definitively 
recommend it to other governmental businesses.

Download case study (PDF).

Time-of-click protection against ransomware, malware and phishing

Time-of-click protection adds an extra layer of security to protect email users from accessing malicious content. Attacks including malware, ransomware and phishing are becoming more common and more sophisticated with every day, along with users keeping more sensitive information.

With an additional time-of-click protection, Halon will classify links in email every time it’s clicked, before allowing or denying the user to visit it. This means that if the scammer waits two minutes or two months with infecting the site, the user will still be protected when he or she chooses to click the link. It’s the extra layer of security that won’t allow you to visit infected websites by way of a link in an email protected by Halon.

Read more.

Dude, where’s my email?

Ensuring high deliverability in email is no walk in the park. As a high-volume sender of email, there are many things to take in consideration, especially with cybercriminals keeping a fast pace in innovation.

Read more.

Email Security Roundtable in Zürich, Switzerland

To email hosting and service providers in or around Switzerland, we kindly invite you to join an intimate group of Cloud and Telco VIPs for an exclusive Email Security Roundtable to introduce you to the Trusted Email Services (TES) initiative on Thursday, September 21, 2017, hosted by Open-Xchange.

TES was launched as an industry e ort to raise awareness around email security threats and promote the deployment of innovative technologies to address them, including encryption and DNS-based mechanisms such as DNSSEC, DANE and DNS filtering. The discussion will deliver an insight into how internet service providers and software companies adopting TES guidelines and best practices can secure and qualify their services, comply with recent legal requirements (GDPR) and establish enduring customer relationships.