Email expiration dates, results of the first exchanges

by | Apr 28, 2021 | Non classé | 0 comments

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

The proposal: to add an expiration date to some 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 to enrich the debate.

Note : This article is translated from French, for the original article, see here.

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

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

By the way, this also helps to rephrase the basic principle to make it clearer and closer to what it could be in reality:

“Provide commercial email senders 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 therefore 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. And it is quite relevant.

With the expiration date mechanism, it’s not a question of relieving senders of the other 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 get brands to send less. But let’s find solutions for what will still be sent.

It is the recipient’s role, he is in charge

Second most common comment!

In the same way, some people suggest that webmails and email clients could offer tools to delete certain emails in a smart way.

The purpose of the expiration date is to provide webmails and email clients with 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, or they don’t think about it, or 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 we think about the carbon footprint of storing an email, we have to think about the whole chain, from the manufacturing of the material to its recycling and not only about the energy consumption of the storage devices.

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 mistake to wait to have this information before moving. At the risk of never doing anything.

Email, as a protocol, is impossible to change

Email is old, and as a protocol, it is extremely difficult to make it evolve. This is a point that has been made several times during the discussions 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, …).

To counter this difficulty, in the initial proposal, it was proposed to use two different mechanisms

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

Many people were skeptical about the second option. Concerning the first one, Marcel Becker pointed out on the Emailgeeks Slack that an SMTP header “Expires:” already existed 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 be implemented, it is therefore essential that technical email specialists look into the solution that should be used to transmit the expiry date of the sender of the message to the Mail User Agent (MUA). 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 privacy of electronic communications. Operators are therefore forbidden to intervene in the mailboxes of their customers and users.

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

However, there are several avenues that seem quite feasible to comply with the law while moving forward:

  • Ask the user for consent on the principle of automatic deletion.
  • Not deleting automatically, but regularly proposing to the user to clean his 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 on the importance of digital frugalty.

It’s a lot of work for webmails and ISPs

Yes, clearly, the adoption of email expiration date will require some work from webmails and ISPs.

Some, like Steve Atkins from Wordtothewise, question the need for an expiration date. Don’t ISPs already have enough data to set up 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 take the expiration date into account 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 a sender from automatic deletion on request of the recipient
  • …

The next steps

1. Gather support

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

These stakeholders are:

  • Email senders (advertisers): who must agree to define the expiration date of all the emails they send.
  • ESPs (Email Service Providers): who must modify their solution to collect the expiration date and transmit it to webmails and ISPs.
  • Webmails and ISPs: who have to process the expiration date and propose different tools to the recipients in order to reach our final result, i.e. to reduce the number of stored emails in an unlimited way.

We will therefore write several emails and sample pitches in order to try to collect promises of participation from these different actors. If you are interested in this project, you can obviously participate by reaching out to your contacts.

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

2. Structuring the project on a wiki

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

Don’t hesitate to create an account if you want to participate and comment.

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

  1. Technical specifications
  2. FAQs
  3. Templates for the collection of commitments.
  4. List of brands, ESPs, webmails, ISPs having made a promise of participation
  5. …

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 carrying the expiration date in emails.

4. And other things

TBD

Thanks to the contributors of this debate

Sorry if I missed anyone 😉

Submit a Comment

Your email address will not be published. Required fields are marked *