Subject: [art] SMTP/IMAP extension to enable email escrow

From: "Suresh S." <[email-masked]>
Date: Thu, 14 Feb 2019 05:22:42 +0000

Hello,

I would like to suggest an extension to SMTP and IMAP.

What:
- To enable a email originator send just the email header to a third party who serves as an escrow.
- The objective of this extension is to introduce a measure of accountability/responsiveness/customer orientation at the email recipient.
- When an email originator sends a message to a recipient requesting a response, some businesses/organizations may not read the email because it got categorized as spam or another reason resulting in loss of email delivery within an organization which does not result in an error response transmitted to the email originator.

Use-case scenario:
- A business/organization which wishes to introduce transparency in its handling of incoming email messages will use the services of an independent email escrow agency (e.g. Better Business Bureau).
- Features of the independent email escrow agency:
+ Receives just the email header from the email originator.
+ When the email recipient responds to the email, the email escrow agency receives a copy of just the header resulting in deleting the email header received from the email originator.
+ If the email recipient does not respond within a finite amount of time, (may be a month or another configurable time-frame which is mutually understood between the escrow agency and business/organization),
++ The email escrow agency sends a reminder to the email recipient.
++ If email recipient does not respond within 7 business days (or another configurable time-frame), the email escrow agency increments a publicly visible record of number of email requests not responded.
++ If email recipient does respond beyond the stipulated time-frame (7 business days or another value), the public record of email responsiveness is decremented.

Proposed extension:
- SMTP and IMAP would include 'ESCROW <string>"

Why:
- In the capacity of an individual (no leverage of an institution), I have pursued a public interest advocacy since 2007 to advance legal protection when common devices emitting potent energy are used for crime*. Attempting to request subject matter expert opinion/collaboration in science (material, molecular biology, forensic), technology (microwave systems), law (theory and practice) at academic, private research agencies and government, getting a response has been a significant challenge.
- A business/organization offering transparency of one's responsiveness which is measured by a third party email escrow agency will help differentiate itself among competitors.
- Empowers an ecosystem of trust-building institutions who serve as wardens of industry, NGO (Charity Navigator etc.) and government.

Best Regards,
Suresh
Open Researcher profile, https://orcid.org/0000-0002-7404-0705.

[*] Please start from https://competitionunlimited.wordpress.com/disclaimer/.

Sent with [ProtonMail](https://protonmail.com) Secure Email.

---

From: JFC Morfin <[email-masked]>
Date: Thu, 14 Feb 2019 22:12:33 +0100

I support this extension and would suggest a 
read-back/blockchain-like option. The header is sent with three 
optional fields : topic, text's url and hash value.
Best
JFCM

At 06:22 14/02/2019, Suresh S. wrote:
>- The objective of this extension is to introduce a measure of 
>accountability/responsiveness/customer orientation at the email recipient.
>- When an email originator sends a message to a recipient requesting 
>a response, some businesses/organizations may not read the email 
>because it got categorized as spam or another reason resulting in 
>loss of email delivery within an organization which does not result 
>in an error response transmitted to the email originator.
>
>Use-case scenario:
>- A business/organization which wishes to introduce transparency in 
>its handling of incoming email messages will use the services of an 
>independent email escrow agency (e.g. Better Business Bureau).
>+ When the email recipient responds to the email, the email escrow 
>agency receives a copy of just the header resulting in deleting the 
>email header received from the email originator.
>+ If the email recipient does not respond within a finite amount of 
>time, (may be a month or another configurable time-frame which is 
>mutually understood between the escrow agency and business/organization),
>++ If email recipient does not respond within 7 business days (or 
>another configurable time-frame), the email escrow agency increments 
>a publicly visible record of number of email requests not responded.
>++ If email recipient does respond beyond the stipulated time-frame 
>(7 business days or another value), the public record of email 
>responsiveness is decremented.
>
>Proposed extension:
>- In the capacity of an individual (no leverage of an institution), 
>I have pursued a public interest advocacy since 2007 to advance 
>legal protection when common devices emitting potent energy are used 
>for crime*. Attempting to request subject matter expert 
>opinion/collaboration in science (material, molecular biology, 
>forensic), technology (microwave systems), law (theory and practice) 
>at academic, private research agencies and government, getting a 
>response has been a significant challenge.
>- A business/organization offering transparency of one's 
>responsiveness which is measured by a third party email escrow 
>agency will help differentiate itself among competitors.
>- Empowers an ecosystem of trust-building institutions who serve as 
>wardens of industry, NGO (Charity Navigator etc.) and government.
>
>Best Regards,
>Suresh
>Open Researcher profile, 
><https://orcid.org/0000-0002-7404-0705>https://orcid.org/0000-0002-7404-0705.
>
>[*] Please start from 
><https://competitionunlimited.wordpress.com/disclaimer/>https://competitionunlimited.wordpress.com/disclaimer/.
>
>
>
>
>
>Sent with <https://protonmail.com>ProtonMail Secure Email.
>
>_______________________________________________
>art mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/art

---

From: [email-masked] (Dale R. Worley)
Date: Thu, 14 Feb 2019 21:02:33 -0500

"Suresh S." <sureshs=[email-masked]> writes:
> - When an email originator sends a message to a recipient requesting a
> response, some businesses/organizations may not read the email because
> it got categorized as spam or another reason resulting in loss of
> email delivery within an organization which does not result in an
> error response transmitted to the email originator.

It would help a lot if you wrote a draft that explained in more detail
how the mechanism is expected to work.

Dale

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 15 Feb 2019 10:20:15 +0100

> how the mechanism is expected to work.

Some prior discussion may help.  I don't know IMAP very much, but my
understanding is that it is mostly about client/ server interactions, and
leaves it to implementations to decide what is the server admins or 3rd parties
ability to track users' actions.  We all know that giant providers base their
anti-spam and feedback loop policies on the results of tracking user actions
using purposely written software.  Most ESPs also forge their messages adding
invisible images and tracking URLs, without caring whether recipients wish to
introduce transparency in their handling of incoming email messages.  Besides,
we have return receipts and positive delivery notifications.

How is ESCROW related with existing tracking practices?  Is the message author
supposed to learn the content of the <string> appearing after the ESCROW
keyword (which I assume is the the 3rd party agency)?  Can the author decide
which message is tracked on a per-message basis?  What if the message is spam?
 What other actions can the recipient take, besides replying?

I think that clarifying some points before a formal spec can be worthwhile.

Best
Ale
--

---

From: "Suresh S." <[email-masked]>
Date: Fri, 15 Feb 2019 10:44:15 +0000

I came across the following post after I started to write a document to provide more clarity (not an IETF draft in the typical sense of what goes into it) on what changes may be needed to existing protocol constructs. Before I go further, I will share what I have.

To address "Besides, we have return receipts and positive delivery notifications.", far too many individuals/organizations who claim to serve the interests of the public are nothing more than an abyss - silent to suffering (please view https://competitionunlimited.wordpress.com). For those who cannot afford to lobby law makers, physically visit subject matter experts, mobilize people/groups concerning matters of significant importance, email is the lifeline.

> "How is ESCROW related with existing tracking practices?"
Please view attached write-up. Concisely, tracking ensures message delivery but whether the recipient responded is indeterminate.

> "What other actions can the recipient take, besides replying?"
To match word with deed (please see attached write-up for elaboration on this front), the recipient ought to reply for taking the role of being a guardian of society.

> "Is the message author supposed to learn the content of the <string> appearing after the ESCROW keyword (which I assume is the the 3rd party agency)?"
Yes. I did not mean to add terminology that may be confusing, but did to convey what exactly may be a change at the periphery. The string is nothing but an email address.

> "Can the author decide which message is tracked on a per-message basis?"
Yes.

> "What if the message is spam?"
>From my visibility of spam handling (the attached write-up clearly disclaims email implementation/deployment experience), apart from the email Escrow quiz the email originator to verify whether or not a message is spam there may be more ingenious ways, but I do not know.

Faithfully,
Suresh

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Friday, 15 February 2019 14:50, Alessandro Vesely <[email-masked]> wrote:

> > "Suresh S." sureshs=[email-masked] writes:
> >
> --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 15 Feb 2019 18:51:59 +0100

Hi Suresh,

> Please view attached write-up. Concisely, tracking ensures message delivery but whether the recipient responded is indeterminate.

I have a couple of comments about that text:

   An email sent by an originator without an error indication (refusal based on
   policy, spam etc.) from the recipient's email server is assumed to be
   delivered to the inbox of the recipient.

That is the original intention.  If the message contains a virus, however, a
bounce would likely result in the virus being delivered to someone who was not
in fact the actual sender, but just another random email address on the real,
hidden sender's list.  That lead many operators to just silently drop infected
messages.

   In the interest of the email system provide a useful purpose in situations
   when an email originator seeks help from organizations that position
   themselves to serve the public in the capacity of a government functionary,
   business/industry regulatory agency, NGO who claims to serve the interests
   of common people and organizations (academia and private) that subsist on
   government funding are answerable to the people who they project to
   enlighten/serve/protect.

That kind of service is usually provided by ticketing systems, a.k.a. issue
tracking systems.  I never saw one where a third party agency is involved, but
issue management is audited internally, possibly surveying users' satisfaction.

> To match word with deed (please see attached write-up for elaboration on this front), the recipient ought to reply for taking the role of being a guardian of society.

Some messages may just say "thank you, farewell".  No need to reply.

Or "You won, click here to get rich".  No need to reply.

> Yes. I did not mean to add terminology that may be confusing, but did to convey what exactly may be a change at the periphery. The string is nothing but an email address.

That requires some pinpointing.  Let me try and be didactic (after your
parenthesized note quoted below.)

As an _SMTP extension_, the availability of an ESCROW and its email address
appear after the user hit <send>.  (Perhaps he or she may be asked if they want
to send the message header to that agency?)  Positive DSNs are an SMTP
extension which the user asks blindly before sending; return receipt are not
SMTP extension, they are asked for, blindly, by setting a header field before
sending.

As an _IMAP extension_, it gets known to recipients when they connect to their
inbox.  It wouldn't be related to any particular message.

>> "Can the author decide which message is tracked on a per-message basis?"

Good.

> From my visibility of spam handling (the attached write-up clearly disclaims email implementation/deployment experience), apart from the email Escrow quiz the email originator to verify whether or…

The determination of a message spamminess is totally subjective.  There are
techniques to catch blatant cases, but there are too many shades of gray to
make sharply defined decisions automatically.

Best
Ale
--

---

From: "Suresh S." <[email-masked]>
Date: Fri, 15 Feb 2019 21:07:59 +0000

Dear Ale,

The reasons for silent drops are many. From my personal experience, I can safely contend that virus was involved in my messages. I say this based on receiving on vacation auto-responders from quiet a few interspersed with those that do not.

In the write-up I sent, I cover the ticketing system some employ but unfortunately the majority do not.

> Or "You won, click here to get rich".  No need to reply.
When you write to someone in the capacity of who most certainly can help regarding a need for law to protect unsuspecting/defenseless victims, medicine to detect when common sources emitting potent energy are used for crime, that is not the intent, you want an answer.

> inbox.  It wouldn't be related to any particular message.
Appears you may be interpreting my intention from a _IETF nuance_ view referred in my write-up. The intention of the proposal is that this feature would be available for each message sent just as one would choose to include or not a BCC field, I do not yet know how that is characterized in an IETF working group.

The transparent forum like the IETF that I have been used to especially as a younger person if only was also available to address concerns at the intersection of rule of law, science and technology, there would not be a condition like what exists today - lawless behavior is uncaring of the cautious.

Faithfully,
Suresh

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Friday, 15 February 2019 23:21, Alessandro Vesely <[email-masked]> wrote:

> As an SMTP extension, the availability of an ESCROW and its email address
> As an IMAP extension, it gets known to recipients when they connect to their
> -----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> art mailing list
> [email-masked]

---

From: "Suresh S." <[email-masked]>
Date: Fri, 15 Feb 2019 22:00:58 +0000

Thought I provide another perspective, the proposed method of transparency is akin to giving visibility as much to those inside as much as those outside an organization, metaphorically speaking it is like holding a mirror to customer/constituent facing departments.

Just as the Army during my service in the National Guard would quiz us after returning from a deployment whether one has engaged in and/or have any information of organized crime infiltrating the ranks, I hope organizations in civil society in general and those especially who take a guardian role are vigilant of organized crime entering their employee base to cause an otherwise respected organization cut a sorry figure in the public eye.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Saturday, 16 February 2019 02:37, Suresh S. <sureshs=[email-masked]> wrote:

> Appears you may be interpreting my intention from a IETF nuance view referred in my write-up. The intention of the proposal is that this feature would be available for each message sent just as one would choose to include or not a BCC field, I do not yet know how that is characterized in an IETF working group.
>
> On Friday, 15 February 2019 23:21, Alessandro Vesely [email-masked] wrote:
>
> > Hi Suresh,