Subject: [openpgp] So if we ever did redo the mail system from scratch...

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 14 Apr 2015 09:59:17 -0400

OK so like most folk, I see no point in redoing the mail system. Or
rather I didn't till I sent a message without an attachment. Then it
hit me. There is only one feature that is powerful enough to justify a
whole new mail protocol and it is the ability to change a message
after it is 'sent' but before it is read.

Implementing this would require a complete break with SMTP. We would
have to junk all the idiot crud of forwarding and relays etc. All the
stuff the mail folk love that makes sending mail inefficient and
unreliable.

I don't want to do that right now. But if there is going to be a
change, that is the place I would look for it.

---

From: Ryan Carboni <[email-masked]>
Date: Tue, 14 Apr 2015 08:45:33 -0700

I use gmail with the undo send feature.

On Tue, Apr 14, 2015 at 6:59 AM, Phillip Hallam-Baker <[email-masked]
> wrote:

> _______________________________________________
> openpgp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/openpgp
>

---

From: Tom Ritter <[email-masked]>
Date: Tue, 14 Apr 2015 11:01:27 -0500

> after it is 'sent' but before it is read.

Like the concept of 'Self-Destructing Messages' and Read Receipts -
this requires the cooperation of the receiver.  And, like both of
these, one of the first features built is going to be the option to
disable it, or better yet, view the request to edit and allow the
receiver to accept the request or reject it.

And I think Outlook & Exchange has both this feature and the ability
to view that an edit took place (and maybe what it was)...

> I use gmail with the undo send feature.

Which works by delaying the message in your outbox.  You can write a
client-side rule to do this on outlook clients as well. For many years
I had a rule that would delay any message signed "-tom" for 1-2
minutes for me to edit it.  (And to immediately send any message
signed "-tom.")

-tom

---

From: Ryan Carboni <[email-masked]>
Date: Tue, 14 Apr 2015 09:26:42 -0700

Given that everything is in the cloud, it might be best that an email's
contents is not downloaded until a user opens the email. The attachments
too will be opened when a user clicks on it.

But this would be biased against small email servers.

---

From: David Leon Gil <[email-masked]>
Date: Tue, 14 Apr 2015 16:12:09 -0700

On Tue, Apr 14, 2015 at 9:26 AM, Ryan Carboni <[email-masked]> wrote:
> contents is not downloaded until a user opens the email. The attachments too
> will be opened when a user clicks on it.

W.r.t. attachments, this has already largely happened via webmail
providers' integration with cloud storage services.

Alas -- as Daniel Bernstein has also noted -- sender-stores is in many
respects better; but SMTP does not seem likely to go away soon.

---

From: Ben McGinnes <[email-masked]>
Date: Wed, 15 Apr 2015 11:36:11 +1000

On 14/04/2015 11:59 pm, Phillip Hallam-Baker wrote:
> hit me. There is only one feature that is powerful enough to justify
> a whole new mail protocol and it is the ability to change a message

For all of SMTP's faults, and there are many, not adjusting for user
error in hitting "send" at an inappropriate juncture is *not* amongst
them.  The recall or burn option included in some email servers
(e.g. MS Exchange) is not something worth encouraging.  In part, as
others have said, because it relies upon the complicity of the
receiving server, but also because it lends itself towards abuse.  The
classic case (and I have seen this in action) is a manager of some
company issuing an instruction to a subordinate, subsequently deleting
the message and the subordinate left carrying the can regarding an
action which was apparently "unauthorised".

If a feature of your mail system can get someone fired, or even jailed,
then that's not a feature - it's a law suit in waiting.

> Implementing this would require a complete break with SMTP.

Well, SMTP is certainly living up to its name in application: it is
simple.

Regards,
Ben