order of sending mail and saving to fcc

John Long codeblue at inbox.lv
Tue Jun 11 18:40:53 UTC 2019


Hi Mutters,

I haven't been following the thread but just to reply to a few points
with the names of the posters removed in order to focus on content
rather than who said what:

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

If the issue is whether saving a copy or sending a copy happens first,
it seems obvious to me in most cases it doesn't matter.

But, as long as it is not any more difficult to do it correctly, maybe
we can use a journaling file system as a very rough analog. We expect
that any update gets committed to the journal before it gets committed
to the real file. If the lights go out, we replay the journal and the
file (depending on some minor details like what was journaled blah blah
blah) gets restored to a coherent state.

So it seems pretty clear that, if there are no overriding
considerations the first thing that ought to happen is that a local
copy of the email is saved to disk before the email is sent. Then the
email is sent, the the saved copy is marked sent. So in those rare
cases, there is a consistency mechanism that leaves things in a known
state.

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

The flagging operation of a saved message is much faster than saving
the whole message. So while it's true having a saved copy with no
status information attached to it could lead to this case you mention-
which is certainly bad, it seems to me that designing things so that
the saved email is created with an unsent flag and after the email is
sent the flag on the sent copy is set to sent is easy and make sense.

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

Yes, and the above paragraph would seem to be one way.

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

This seems reasonable to me. I understand that means nothing here on
the list and probably not much elsewhere ;) but at the same time, free
speech is good and no electrons were harmed in creating this email.

> > 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^)  

I go with the opposite opinion. I think there is an obvious precedent
here in journaling filesystems, which are vitally concerned with data
and/or metadata consistency. It does not necessarily mean that an email
client has to be coded the same way or that the same level of rigor is
appropriate, but in the absence of compelling reasons to the contrary
the question arises, why not then?

> You might consider it wrong but I do not seem to be the only one
> thinking the old order is the correct one.

Old stuff is usually better in my opinion. The problem is that most
people seem to think you have to keep throwing features out there when
what they had was perfectly fine at some point. And most Linux distros
make it very hard never to update some app or middleware.

When I ran Slackware I got around this by building everything from
source and then never updating apps I was happy with. But there is a
lot of home sysadm work involved with that and of course some risk of
losing out on security updates for various and never-ending screwups.
In the end, package-managed distros make it very easy to get the
latest, but not necessarily the best.

/jl



More information about the Mutt-users mailing list