Subject: [Emailcore] Additional fields to categorize email to reduce email storage cost

From: Vijay Patel <[email-masked]>
Date: Sat, 10 Jul 2021 16:29:26 +0530

Hi,

Sincere thanks for maintaining internet standards.

Background:
Whenever I see my gmail account with lots of subscription emails,
newsletters, and promotional mails, I get questions about how to manage and
streamline them.

Unsubscribe is definitely a simple option to get rid of it.
Or spam filter options (by email provider).

I am looking for an additional feature that mandates email sender to
specify when the email can be deleted safely.

Example-1: I get daily promotional emails for my bank account / debit card
/ credit card / spend on internet / offers / Investment services / Mutual
funds / IPO / and a lot more.
If these email messages carry specific fields to indicate it is Pure
Promotional email, I believe it will help Gmail / Outlook Live / Yahoo to
provide additional options to users (like me) to delete past emails which
are not relevant after certain days.

I believe this will lead to electronics resource saving (Storage cost /
Backup management), Electricity savings, and reducing carbon footprint.

Example-2: Newsletter emails
Newsletter subscription might be driving a lot of email traffic on a daily
basis. Can there be further categorization of email based on use cases?
Example, A newsletter email may contain full body (html + latest features),
but it shall also contain a link to persistent copy on the internet (to be
managed by sender). This will allow to truncate the message after certain
days.

The challenge I am describing in this use case is more related to current
roles and responsibilities owned by various stakeholders. Email providers
are happy to provide free storage + huge limits . Email senders are not at
all worried about sending thousands of emails per day and filling
mailboxes. The movement, storage cost is added to email sender, genuine
email senders (All large email publishing companies / newsletter senders -
who are equally sensible about contributing to a better internet future)
can play their good role.

I am not sure if these issues can be discussed by the emailcore group. But
surely, I am attempting to inform those who are actively working to make
the internet a better place.

Regards,
Vijay

<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
Virus-free.
www.avast.com
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

---

From: "John Levine" <[email-masked]>
Date: 10 Jul 2021 17:58:36 -0400

>specify when the email can be deleted safely.

The Expires: message header was defined in RFC 2156 in 1998.  As far as I am
aware, noboy uses it.

I think we can conclude that if there were a demand for this feature, sometime
over the past two decades people would have used it, but there isn't, so they don't.

Also, in 1998 a gigabyte of disk space cost about $50, while now it costs about 3 cents,
so we would expect people in that era to care a lot more about how much space
their mail used.

R's,
John

---

From: John C Klensin <[email-masked]>
Date: Sat, 10 Jul 2021 23:20:04 -0400

--On Saturday, July 10, 2021 17:58 -0400 John Levine
<[email-masked]> wrote:

>> I am looking for an additional feature that mandates email
>> sender to specify when the email can be deleted safely.
> 
> The Expires: message header was defined in RFC 2156 in 1998.
> As far as I am aware, noboy uses it.
> 
> I think we can conclude that if there were a demand for this
> feature, sometime over the past two decades people would have
> used it, but there isn't, so they don't.
> 
> Also, in 1998 a gigabyte of disk space cost about $50, while
> now it costs about 3 cents, so we would expect people in that
> era to care a lot more about how much space their mail used.

John,

Completely agree with everything you write above, but one
additional comment.  "Mandating" that message senders do
anything (including attaching "Expires" header fields) is a
dicey business.  In most cases, senders have little incentive
unless there is agreement that the message will be automagically
deleted from the recipient's mail store when that date passes.
The is unenforceable and not what I think Vijay is asking for.
And, of course, if the goal is to minimize recipient storage
space, the sender may have no incentive to do that either.  

We do see a variation on this theme today, and that is messages
with something like "action required before 2021-07-31" in the
subject line: nothing automated, but a strong hint to the
recipient.

best.
   john

---

From: Dave Crocker <[email-masked]>
Date: Sat, 10 Jul 2021 20:30:31 -0700

> so we would expect people in that era to care a lot more about how much space

1. The reason for adding expiration information is losing timely 
relevance or utility, not saving storage space.

2. RFC 2156 cites the header field but doesn't actually define it.

3. RFC 2156 cites one heck of a lot of fields, making it especially 
unlikely that stray Internet folk will know that any particular field is 
defined and usable.

Still, there's never been a community desire to emulate richer 'office' 
functionality, in spite of various efforts to support it over the years.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: "John R Levine" <[email-masked]>
Date: 10 Jul 2021 23:41:09 -0400

On Sat, 10 Jul 2021, Dave Crocker wrote:
> 1. The reason for adding expiration information is losing timely relevance or 
> utility, not saving storage space.
>

See RFC 4021 which refers to 2156 and defines it as

Related information:
       Time at which a message loses its validity.  Renamed version of
       obsolete Expiry-Date header field.  RFC 2156 (MIXER), not for
       general use.

Dunno why it says not for general use unless the idea is it's only for 
X.400 gateways.

The syntax of usenet messages is nearly the same as mail messages, and 
they also have an Expires header, see RFC 5536. sec 3.2.5.  They used to 
be fairly common in periodically posted FAQ messages, so one would expire 
when the next copy of the FAQ was posted, but I haven't seen many of those 
lately, either.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly