order of sending mail and saving to fcc

[Nicolas Rachinsky]

* Derek Martin <invalid at pizzashack.org> [2019-06-11 12:36 -0500]:
> On Tue, Jun 11, 2019 at 10:04:25PM +1000, Erik Christiansen wrote:
> > In the event that send fails, the local copy is essential for a resend
> > attempt. No ifs, no buts, no maybes. I'm at a loss to imagine any
> > scenario in which mutt should risk inability to write that Fcc, through a
> > hang-up or conniption during sending.
> 
> This argument seems like complete nonsense to me...  if the send
> fails, you're left back at the compose screen.  If by some
> unbelievable coincidence the send fails AND you lose power before you
> can do something about it, this is NO DIFFERENT than if the power went
> out just before you finished composing the message.

It is different. In one case nobody has my mail. In the other case
the recipient might have it, but the sender does not.

>  It's not your
> mail client's job to protect you from every conceibable system failure
> which might cause data loss, nor should it be.

Of course it is not its job. If my computer melts to a blob of
something, that is not mutt's problem.

But it is mutt's job to make it easier (or even possible without
arcane workarounds) to avoid more or less simple problems. Diskless
workstations loosing their connectivity at the worst moment. Crashing
systems. ...

>  And for every other
> case, the current behavior is the far superior one because it can not
> mislead you into thinking you sent a message you did not, and does not
> lead to the various encoding issues Kevin mentioned separately. 

It is quite easy to have a setup, where I can verify if the mail was
sent if there is any doubt.

The new behavior does create a situation that makes it much more
likely to create a situation where I have to ask e.g. a client for
a mail I sent to him. That would be quite embarrasing without some
good explanation (like a major event, like a house which burned
down).

> But also, just because the message failed to send, your ideas and the
> impetus for writing them down didn't vanish.  Your brain is the
> back-up.

Ahm. No. Any temporary information copied into the mail is just not in
my brain.

Anything where the exact wording is important cannot be reproduced
(so the recipient gets two mails that are different, and the sender
only knows one of them).

>  In the event that the message in question is the unusual
> combination of lengthy, complex, and important enough that the pain of
> re-composing it from scratch is somehow prohibitive, then you damn
> well better be composing it using a word processor that takes frequent
> snapshots of your document as you compose, and then sending it as an
> attachment (or as a link, or by doing a text conversion, or...
> whatever)--not relying on your mail client to preserve it.

I'm relying on my mail client, that it safely stores a message of
every message sent.  

> And by the
> way even then, you can't guarantee 100% that you won't lose the data.
> Your hard disk could explode, say due to a lightning strike.  No
> software can't protect you from that.  At a certain point such
> considerations become completely ridiculous.

Yeah. But that is no reason to not protect from things it can protect
me easily from by just storing the message before sending it.

I do not want to protect mutt my mail from a supernova in my hard
disk. 

I consider it quite absurd to use such an argument:
"Why should I ever call fsync? The computer may be struck by lightning
and might get lost completely."


> 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.

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.


Nicolas