Badsender
Rechercher
Close this search box.

#ZeroCarbonEmail : expiration dates of emails, result of the first exchanges

  • updated on 

At the end of March, I published a proposal to reduce the environmental impact of the almost indefinite storage of most emails.

The proposal: add an expiration date to certain types of emails (mainly commercial), so that they can be deleted almost automatically.

This proposal has triggered many reactions, some very enthusiastic, others less so, which is also interesting in order to enrich the debate.

For those who want to reread the public exchanges, the main ones took place here :

All of these remarks enrich the reflection on the subject, and I will take the time to detail the main ones while answering them.

Moreover, this also allows the basic principle to be reformulated to make it clearer and closer to what it could be in reality:

"Provide senders of commercial emails with the means to specify an expiration date for their messages. This is to make it easier for webmails and ISPs to design tools to (semi)automatically delete these emails."

In this article, we list the most frequently encountered remarks and questions and answer them. Feel free to continue to enrich the discussion here or elsewhere.

It is better to reduce the carbon footprint by reducing the number of emails sent

Probably the most common remark. Which is quite relevant.

The expiration date mechanism is not intended to relieve senders of the responsibility of sending less.

But let's not fool ourselves, even brands that are mindful of their carbon footprint will still send emails. And even if they send less, stop targeting their inactives, segment better, shift their mass emails to automated emails.

So, yes, let's encourage brands to send less. But let's find solutions for what will still be sent.

This is the role of the recipient, he is in charge

Second most common remark!

In the same vein, some suggest that webmails and email clients could offer tools to delete certain emails en masse in an intelligent way.

The purpose of the expiration date is to give webmails and email clients additional information to create these tools and put them in the hands of the recipients.

So yes, in the end, it is the recipient who makes the decision. But we have to make it easy for them, otherwise, like today, they won't do anything. Because it's complicated, because they don't think about it, or because they're afraid to delete important messages.

Does it really reduce the carbon footprint?

We can even go further, doesn't the action of deleting an email consume more energy than indefinite storage?

When thinking about the carbon footprint of email storage, you have to think about the whole chain, from the construction of the hardware to its recycling, and not only about the energy consumption of the storage media.

Currently, if there are figures on the carbon footprint of email, they are not very precise and do not detail the different stages of the life cycle of an email.

It would be very interesting to have this level of detail. But it would be a shame to wait to have this information before moving. At the risk of never doing anything.

Email, as a protocol, is impossible to reform

Email is an old man (or woman), and as a protocol it is extremely difficult to evolve. This is a point that has been made several times and is quite relevant.

The adoption of the latest email evolutions took several years to spread... and for some, it is not yet won (DMARC, BIMI, List-Unsubscribe, ...).

In order to counter this difficulty, in the initial proposal it was proposed to go through two different mechanisms:

  • a dedicated SMTP header: the longest way to be validated and adopted
  • of the code Schema.org directly in the body of the message: easy to set up by advertisers and routers

Many people were skeptical about the second option. Regarding the first one, Marcel Becker pointed out on the Emailgeeks Slack that an SMTP header "Expires:" already exists in the RFCs (https://tools.ietf.org/html/rfc4021#page-31) and that it was unused. However, it seems that this header cannot be recycled. To be confirmed.

If the project is to go ahead, it is therefore essential that technical email specialists look into the solution that must be used to transmit the expiry date of the sender of the message to the Mail User Agent (MUA, i.e. email client). This is a crucial point of the project.

In some countries, webmails and ISPs may not have the right to delete an email

The legislation of some countries is very restrictive regarding the confidentiality of electronic communications. Operators are then forbidden to intervene in the email boxes of their customers and users.

Need help?

Reading content isn't everything. The best way is to talk to us.


This is an objection that has been seen many times and needs to be addressed.

There are, however, several avenues that seem quite feasible for complying with the law while moving forward:

  • Ask the user for consent on the principle of automatic deletion.
  • Do not delete automatically, but regularly offer the user to clean up their emails based on the expiration date.
  • Allow to block automatic deletion on certain senders or messages.

Again, the expiration date is not there to delete emails without warning the recipient. On the contrary, the objective is to help them, to simplify their task... and maybe also to educate them about the importance of digital ecology.

That's a lot of work for webmails and ISPs

Yes, clearly, the adoption of email expiration date is going to require some work on the side of webmails and ISPs.

Some, like Steve Atkins of Wordtothewise, question the need for an expiration date. Don't ISPs already have enough data to implement these mechanisms without the help of an expiration date?

"If an ISP wanted to do this, they could probably do it without really needing any additional data from the sender. Identify bulk mail; offer user option to automatically archive older bulk mail, either after some length of time or to maintain no more than X messages from a sender in their inbox."

To which Marcel Becker (Verizon Media/Yahoo) replies:

"yes, we already do that. We recommend to users what they should delete or not - but having additional sender signals in the expire header helps. That's all 🙂 "

Here is a non-exhaustive list of features that ISPs should work on to accommodate the expiration date and offer (semi)automatic deletion of these emails:

  • read and store the expiration date
  • display the date from which the email expires in the interface
  • collect users' consent before automatically deleting certain emails
  • provide a mechanism to exclude an email or sender from automatic deletion upon request of the recipient
  • …

That's a lot of work for the routers

On the router side too there is potentially work to update their tools to allow advertisers to declare an expiration date and pass it on to MUAs.

Moreover, it is interesting to think about the implementation of this feature. First of all, a priori, only commercial emails would be concerned, we can't imagine that a transactional email, which can have a legal value, would have an expiration date imposed.

For the advertiser, it is at the time of the creation of his message that the expiration date will be defined. At the same time in the interface of the router that the choice of the subject, the shipping address, ...

Here are the options he may have when setting the expiration date:

  • The email expires 30 days after the sending date (default)
  • Customize the expiration date
  • Do not set an expiration date for this email

It would be interesting to propose a well thought-out specification that routers could use (once the technical decisions have been made).

The next steps

1. Collecting promises

In this proposal, there is a chain of 3 different stakeholders who must all be engaged at the same time in the same direction. If one of the links in the chain does not participate, the efforts of the others will be in vain.

These stakeholders are:

  • Email senders (advertisers) The following are examples of companies that must commit to setting an expiration date for all of the emails they send.
  • ESPs (Email Service Providers, routers) For example: who have to modify their solution in order to collect the expiration date and transmit it to webmails and ISPs.
  • Webmails and ISPs which must deal with the expiration date and offer different tools to the recipients in order to achieve our final result, i.e. to reduce the number of emails stored in an unlimited way.

We will therefore write several emails and standard arguments in order to try to collect promises of participation from these different actors. If you agree with this project, you can obviously participate by contacting your contacts.

These arguments will be specific for these different actors, to which we can also add the Professional Associations.

2. Structure the project on a wiki

An Xwiki was quickly deployed here: https://www.zerocarbon.email/

Do not hesitate to create an account if you wish to participate and comment.

This Wiki will allow us to structure the information around the project:

  • Technical specifications
  • FAQs
  • Sample Pledge Forms
  • List of brands, routers, webmails, ISPs having made a promise of participation
  • …

3. Validate the technical aspects

This is a dimension that could take time. It would therefore be interesting to quickly set up a small team whose role would be to validate the technical aspects of transporting the expiration date in emails.

4. And many other things

TBD

Thanks to the contributors of this debate

Sorry if I missed anyone 😉

Photo by Kai Brune on Unsplash

Share
The author
Picture of Jonathan Loriaux
Jonathan Loriaux
Active for more than ten years in emailing, my career path started on the technical side (integration of emailing campaigns) before turning to sales (as an eCRM expert) and finally to marketing consulting. For 9 years I have been the author of the blog Badsender.com. Emailing is not only an expertise, it really became my passion, that's why Badsender is now my main activity with the creation of an emailing consultant activity linked to the website.
All publications

Laisser un commentaire

Your email address will not be published. Les champs obligatoires sont indiqués avec *