order of sending mail and saving to fcc

[Derek Martin]

On Tue, Jun 11, 2019 at 08:11:33PM +0200, Nicolas Rachinsky wrote:
> > I hesitate to go far as to say that if you think saving the message
> > first is the right behavior, you are simply wrong... but I'm
> > definitely thinking it. =8^)
> 
> You might consider it wrong but I do not seem to be the only one
> thinking the old order is the correct one.

The argument is really simple.  The current solution solves your
problem, and mine.  Your solution solves only your problem.

> Considering how often I heard other people swear because they lost
> some sent mail, because their MUA crashed after sending and before
> storing it, this does just seem to be the wrong order.

I've been on this list since ~1995, and I've certainly heard people
express concern about the possibility of this, I can't say that
complaints about it actually happening have been particiluarly common.

To avoid going back and forth responding to quoted comments, I'll
instead summarize the concerns.  As best I can recall, there are 3:

1. If you DON'T save the message first, it is impossible to resend
   the message if sending fails.

2. If you DO save the message first, it can lead to misleading the
   user into thinking messages were sent, when they never were.

3. If you DO save the message first, it has negative repercussions in
   terms of cryptography, certain headers, etc. which will not be
   "correct" in the saved copy.

Ignoring the fact that #1 is hogwash anyway, because you certainly can
recreate a message that captures the sense of what you wrote the first
time, even if it is not word-for-word identical, the current solution
solves ALL of those concerns:

1. If sending fails, you are left at the compose menu, with a copy of
   your original message at the ready.  This is already a rare
   occurence for most people.  The most likely reason for sending to
   fail is you used an invalid address.  Every mail client has means
   to prevent that from happening if you are sending to someone you've
   already interacted with (address book, Mutt aliases, LDAP lookup,
   etc.), excepting the case where a previously valid address suddenly
   is not.

2. In the extraordinarily unlikely event that sending fails, AND you
   have a power outage while you are sitting at the compose menu, you
   still have a copy of at the very least your message text, sitting
   in the temporary file Mutt was going to use to send the message.
   And let's be extremely clear: THIS IS UNBELIEVABLY UNLIKELY. But it
   can happen.

3. In the equally extraordinarily unlikely event you can not remember
   who you were going to send the message to, you can set
   edit_headers=yes and Mutt will copy the headers into the temporary
   file, so you will not lose those either.  The notion is completely
   asinine, but it was raised as a concern, so, there you go.

4. Mutt will update encryption and any heaers added or changed by
   sending before it is copied to Fcc, so the file on disk will be as
   accurate a copy of your message as possible.

5. The Fcc copy will be created only once the message is actually
   sent, so there is no misleading of the user to think the message
   was sent when in fact it was not.

6. In the event creating the Fcc copy fails, Mutt will prompt you what
   to do, giving you the opportunity to deal with it however you like.
   In the mean time, the temporary copy still exists on disk, in the
   event of non-catastrophic system failure at this point.

7. In the event of actual catastrophic system failure, none of these
   things will save you.  Everyone appears to agree Mutt should not
   try to solve for this.

So, all of your concerns are addressed by the current behavior.  None
of the concerns that brougnt this behavior into being are addressed by
the behavior you want.  The only logical conclusion then, which I now
feel completely justified in saying, is that if you still want that
behavior, YOU ARE SIMPLY WRONG.


-- 
Derek D. Martin    http://www.pizzashack.org/   GPG Key ID: 0xDFBEAD02
-=-=-=-=-
This message is posted from an invalid address.  Replying to it will result in
undeliverable mail due to spam prevention.  Sorry for the inconvenience.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.mutt.org/pipermail/mutt-users/attachments/20190611/ac6a1f86/attachment.asc>