The idea

The idea of expiration dates in email has been born in many different brains over the past few years. When talking about it, many people have told us “I thought it already existed” or “We had thought about it, but didn’t know how to do it!”

That’s why we went for it. We made a practical proposal that was published in late March 2021 on the Badsender blog. And given the great response, we set out to make the idea a reality. This page is here to explain the idea. In a summary version (just below), in a long version (a bit lower) and in a presentation to share (below).

Since this idea belongs to no one, feel free to copy and reuse anything you like.

By the way, feel free to pick up our ready-to-use pitches: Pitch for advertisers / Pitch for webmails and ISPs (to be completed) / Pitch for ESPs (to be completed)

In a nutshell: Expiration dates in email

The evidence is clear, a significant portion of emails become obsolete within days of their reception by recipients. Think of those promotions that are only valid for a few days, those newsletters whose news will almost already be outdated by the time they are received, … These emails take up space in data centers, consume energy for storage (storage device production, usage, end-of-life recycling, …).

In order to reduce the carbon footprint of these emails, they should be deleted, and deleted promptly after receipt. And in order not to put this responsibility on the recipient, why shouldn’t the senders indicate when their emails become obsolete. That’s the point of expiration dates.

In practice, at the time of sending, the sender will define when their message will become obsolete. The ESPs will take care of transmitting the information to the recipient’s mailbox. And the messaging solution will offer the recipients mechanics to more or less automatically delete these emails (with their consent of course).

To achieve this, we need the involvement of the entire email delivery chain: senders, ESPs and ISPs/webmails. If the technical solution is not currently defined, it is not the one that will be complicated to design.The real challenge is the adoption, a massive adoption of all the players in order to make this idea a reality.

And technically? How would that work?

The technical part is to be refined via a future working group on the subject. Nevertheless, here is the original proposal, which will probably not be the final solution. There are two main possibilities:

Via the SMTP header. This could, for example, take the form of a header like “Expiration-Date: Tue, 23 Mar 2021 10:00:00 +0000

In the HTML code using Schema.org microdata that might look like this:

<script type="application/ld+json">
{
  "@context": "http://schema.org",
  "@type": "EmailMessage",
  "expires": "2011-03-23T10:00:00+00:00",
}
</script>

Or to this:

<div itemscope itemtype="http://schema.org/EmailMessage">
	<meta itemprop="expires" content="2011-03-23T10:00:00+00:00" />
</div>

Feel free to contact us if you would like to be part of the technical working group.

In detail: expiration dates in emails

Email and digital sobriety

It’s not always easy to identify the projects to put in place to move towards digital sobriety, and thus reducing the carbon footprint of our activities. As far as email marketing and CRM are concerned, here are a few ways regularly mentioned:

  • Data minimization
  • Reducing sending volumes (handling inactives, better targeting, …)
  • Reducing message weight
  • Responsible purchasing policy (low-carbon data centers, carbon offsets, …)

So many topics on which companies are autonomous.

What about the emails (still) sent?

The question of storing emails in recipients’ email boxes is important:

  • Because after a few days emails become obsolete
  • Because recipients don’t take the time to delete them (lack of tools, lack of education on digital sobriety, lack of time, lack…)

What if we reverse the logic, and relieve the recipient of this responsibility? (without hiding the problem) What if we made the sending companies responsible?

The size of the problem?

Billions of emails are sent every day. (About 300 billion according to Radicati)

  • A large portion of these emails are spam, and thus deleted directly or quarantined in the spam box
  • A very small portion are personal or transactional emails
  • All the rest, the commercial emails (the graymail), stagnate forever in recipients’ mailboxes… even though they have become totally obsolete.

The recipients, are very, very, very few to take the time to clean them.

Yes, but… what about the carbon footprint in that?

Complicated topic, as estimates of the carbon footprint of an email range from 19g of CO² (ADEME, 2011) to 0.03g of CO² (TheShiftProject 2018) for a 1MB email

This carbon footprint picture is complicated. Because it doesn’t speak to anyone, because it depends on the type of energy used, so the country we’re talking about, …

Let’s take another image that is much easier to remember.

What if we talked about the tangible device that holds all those emails? Let’s say, a 2TB hard drive. Hard drive that must be :

PRODUCED > POWERED > RECYCLED

Of 300 billion emails sent per day (Radicati), about 11% are Graymail (Vadesecure 2016) = 33 billion marketing emails per day

If we estimate that the weight of an email (without images) is about 80kb, that’s 2640 TB per day > Or, 1320 hard drives per day > Or, 481,000 hard drives per year

That must be manufactured, powered and recycled!

Accountability of the email industry

As we can see, obsolete email is a REAL environmental problem.

So we need to get to the point where we can eliminate them and make the entire email chain accountable:

  • Advertiser
  • Router
  • FAI / Webmails
  • Recipients

It is the email senders who must solve the problems they themselves have created, not the citizens.

In practice, how would this work?

  1. When configuring an email campaign (whether one-shot or automated), the campaign operator sets an expiration date(relative to the send date or fixed)
  2. The ESP embeds this expiration date inside each email sent.
  3. The ISP/webmail, at the time of receiving the email, can read the expiration date contained in it
  4. The ISP/webmail offers various tools (more or less automatic) so that the recipient can then clean his mailbox by providing the least effort possible (and if the latter gives his consent, the emails can be automatically deleted)

In what order do we move forward?

The concept, even on a technical level, is not complicated. But adoption must be massive in order to have an impact.

The players who will have the most work in implementation will clearly be ISPs and Webmails.

Here are the steps that we are currently planning (but will likely evolve):

  1. Structuring the project: organization/content creation
  2. Collecting support: to prove there is real interest in the project
  3. Starting legal and communication workgroups
  4. Constituting a technical workgroup
  5. First implementations tests

It will probably be a year or two before we see the first implementations coming.

How to support the project

Publicly declare your support!

This means:

  • You commit to using and implementing the expiration date mechanism as soon as it is technically validated.
  • You get involved in the project by helping us generate ever more support.
  • You eventually participate in one of the working groups set up.
  • You agree that your company’s logo and name will be associated with the project(list of supporters)

The working groups

Participate in the various working groups (currently being formed):

Legal

  • Creation of a charter that can be signed by all supporters
  • Legal personality of the project (creation of a legal structure or backing up an existing one)
  • Validation of the concept of expiration dates in local legislation(secrecy of correspondence, …)

Communication

  • Sharing content (FAQs, presentations, articles, …)
  • Organizing the gathering of supportersAnimating the community of supporters
  • Internal lobbying in your respective companies

Technical

  • Creation of draft technical proposal
  • Collection of comments
  • Drafting of technical recommendations for implementation by ISPs/Webmails
  • Drafting of technical recommendations for implementation by ESPs

What now?

The presentation to download and distribute