Re: order of sending mail and saving to fcc

[Derek Martin]

[Sent before I intended to.]

On Sat, Jun 15, 2019 at 01:53:18AM +0200, Nicolas Rachinsky wrote:
> @Derek: I've read your mails in this thread, and I'm in no way
> convinced.

I'd love for you to explain why.  Note that Kevin confirmed that my
arguments are technically correct.  So despite that I techncially,
accurately described how the current solution results in you having a
local copy of the message, which was the only thing you (incorrectly)
said the current behavior was lacking, you find this to be inadequate.
I'd like to understand in what way it does not meet your needs.

-- 
Derek D. Martinhttp://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.



pgps4Oz3PKc8Z.pgp
Description: PGP signature

Re: order of sending mail and saving to fcc

[Derek Martin]

On Sat, Jun 15, 2019 at 01:53:18AM +0200, Nicolas Rachinsky wrote:
> I can only say, Erik wrote the answer I wanted to write.
> 
> @Kevin: The new change sounds very promising. Thank you for that
> and all your work!
> 
> @Derek: I've read your mails in this thread, and I'm in no way
> convinced.

I'd love for you to explain why.

-- 
Derek D. Martinhttp://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.



pgpgFaMb4Ahl8.pgp
Description: PGP signature

Re: Making attachments [Was: Re: order of sending mail and saving to fcc

[Kevin J. McCarthy]

On Sun, Jun 16, 2019 at 03:34:00PM +1000, Erik Christiansen wrote:

That looks quite useful. There's also the CheckAttach vim plugin, by
Christian Brabandt.


Starting in 1.10, there is also $abort_noattach in Mutt.  It's not quite 
as useful, because it waits until you hit send and then scans the text. 
But it's also configurable via $abort_noattach_regexp.  1.11 "fixed" the 
scanner to not scan quoted text too.


--
Kevin J. McCarthy
GPG Fingerprint: 8975 A9B3 3AA3 7910 385C  5308 ADEF 7684 8031 6BDA


signature.asc
Description: PGP signature

Making attachments [Was: Re: order of sending mail and saving to fcc

[Erik Christiansen]

On 16.06.19 09:48, Cameron Simpson wrote:
> I compose with edit_headers=yes, so recipients and subject are part of the
> temporary file.
> 
> Also, I attach using the Attach: pseudo header, so the attachment filename
> is also part of the temp file. Provided I haven't exited the compose mode
> (when the Attach: headers turn into actual mutt attachments) I don't lose
> that state either. (I've also got fcc_attach=yes, might be handy too.)
> 
> And to ease using the Attach: header I have this vi macro:
> 
>  map ^A 1G}-:.r!exec /dev/tty; readline -B 'Attach: '^MIAttach: ^[
> 
> Those are literal ctrl-A, ctrl-M, ctrl-[ (escape) in the macro. This means
> that I just type ctrl-A to commence an attachment and I get a file competion
> capable prompt to fill out the filename.

That looks quite useful. There's also the CheckAttach vim plugin, by
Christian Brabandt. It detects words such as "attached" in the
email body, then prompts on exit to mutt, repeating until no further
attachment paths are provided - thereby doing the remembering too. It
doesn't trigger on quoted text. The set of trigger words is
configurable. It also uses an "Attach:" header.

You'd think that someone who rereads before sending wouldn't forget that
an attachment was intended, but I have found its memory useful on more
than one occasion, especially on longish emails.

Erik

Re: order of sending mail and saving to fcc

[Cameron Simpson]

On 11Jun2019 20:21, Nicolas Rachinsky  
wrote:

* Derek Martin  [2019-06-11 12:47 -0500]:

Not only that, but I neglected the fact that if the send fails, the
file your editor produced in order for it to be passed to Mutt will
still be on disk, so you do IN FACT still have a copy of the message.


I did just (using my old mutt) set sendmail to killall -9 mutt. The
temporay file that stayed on my disk did contain my text. But there
was no other information (recipients, subject, attachments).

So if the tmpdir survives, not everything is lost. But the mail as
such is lost.


Just to this.

I compose with edit_headers=yes, so recipients and subject are part of 
the temporary file.


Also, I attach using the Attach: pseudo header, so the attachment 
filename is also part of the temp file. Provided I haven't exited the 
compose mode (when the Attach: headers turn into actual mutt 
attachments) I don't lose that state either. (I've also got 
fcc_attach=yes, might be handy too.)


And to ease using the Attach: header I have this vi macro:

 map ^A 1G}-:.r!exec /dev/tty; readline -B 'Attach: '^MIAttach: ^[

Those are literal ctrl-A, ctrl-M, ctrl-[ (escape) in the macro. This 
means that I just type ctrl-A to commence an attachment and I get a file 
competion capable prompt to fill out the filename.


Oh yes, readline itself is a little shell script to invoke bash to use 
its GNU readline mode:


 https://bitbucket.org/cameron_simpson/css/src/tip/bin/readline

because it is so useful.

Hoping this improves your compose environment,
Cameron Simpson 

Re: order of sending mail and saving to fcc

[Cameron Simpson]

On 10Jun2019 11:56, Ben Boeckel  wrote:

On Mon, Jun 10, 2019 at 08:40:30 -0700, Felix Finch wrote:

[...slightly extreme failure modes elided...]
For me, the difference is that having extra Fcc copies is nowhere 
near

as bad as not having any.


If you're this paranoid, the only real fix is to have your editor save a
backup somewhere before handing it off to mutt in the first place
anyways. After all, mutt could segfault and lose it before the Fcc!


Hmm, that's already what I do.

As I've mentioned in the past my mutt compose mode actually fires off a 
distinct instance of my muttedit script, which uses mutt to compose and 
send in its own tmux session. With a distinctively named template file.


The innermost mutt invocation goes:

 rmafter "$filename" \
 mutt -e "set editor=$editor" -e 'unset signature' -H "$filename"

The rmafter script removes $filename after the subcommand finishes, but 
only if the subcommand succeeds. So a machine crash (or other lesser 
failure) leaves the filename around.


My boot stuff fires up individual tmux sessions with compose-and-send 
mutts in them for all of these distinctive files if they're lying 
around, providing a seamless resume mode post crash.


All this stuff is readily available in my code repo or for individual 
discussion here.


For interest, here's a section of my ps output for this very email 
message:


 cameron 52210   890 2444652   752   \_ /bin/sh ~/bin/rmafter 
~/tmp/muttedit.52169 mutt -e set editor=vim-flowed -e unset signature -H 
~/tmp/muttedit.52169
 cameron 52214 52210 2491372  4344 \_ mutt -e set editor=vim-flowed -e 
unset signature -H ~/tmp/muttedit.52169
 cameron 52396 52214 2504796 10808   \_ vim -c silent 1,/^$/s/ *$// -c set 
filetype=mail -c set formatoptions=waqj 
~/var/mutt/mutt-fleet-wk-wifi-501-52214-12499587601088287517
 cameron 52235   890 2449288   624   \_ tmux attach-session -t 
mutt-16jun2019-09_27-Re__order_of_sending_mail_and_saving_to_fcc

That's 4 lines commencing with "cameron", in case of folding.

Cheers,
Cameron Simpson 

Re: order of sending mail and saving to fcc

[Nicolas Rachinsky]

I can only say, Erik wrote the answer I wanted to write.

@Kevin: The new change sounds very promising. Thank you for that
and all your work!

@Derek: I've read your mails in this thread, and I'm in no way
convinced.

HAND
Nicolas

Re: order of sending mail and saving to fcc

[Derek Martin]

On Wed, Jun 12, 2019 at 09:31:53AM -0700, Kevin J. McCarthy wrote:
> On Tue, Jun 11, 2019 at 05:28:26PM -0500, Derek Martin wrote:
> >Obviously you don't need to listen to me
> 
> I do listen to you, Derek.  The whole buffer pool migration is a
> result of your recurring prods, and I will continue to work on that,
> likely through the next couple major releases.

:) [If I'm being honest, while that may be true, I don't actually
remember what you're talking about...]

[...]
> It's easy to conclude that objections to the change are overly
> paranoid or irrational,

That's not quite what I'm saying (see below)...

> but Mutt users in general *really* *care* about email.

Of course, I realize that, I'm one of them. :)

[...]
> It's evident, to me, that this change is extremely distressing to at
> least a subset of our users, who really care about having the
> message in their Fcc box before it gets sent out, regardless of the
> issues.

I think that's a mischaracterization.  Based on what people said when
they explained *why* they objected to the change, I think it's
actually the case that they just did not realize we accounted for
their concerns when we designed this change, and that in fact they
already can get exactly the end result they wanted from Fcc-first with
the current behavior (their e-mail is fully recoverable, save the case
of catastrophic system failure).  I think there was not much
opportunity for them to correct that misunderstanding until late in
the thread when I posted my detailed, hopefully succinct explanation
(and I also suspect at least some people who don't like this change
never read the explanation).

I think before you commit this, you should ask that anyone who still
objects go read my explanation if they have not, and then explain how
that does not cover their concerns.  My suspicion is that after doing
so, if there still are any objectors, their explanations will reveal
that they still don't actually understand how this works, and that
their understanding is the problem, not the actual behavior...  Unless
their objection is simply, "but I still want it to be written to Fcc
first for no particluar justifiable reason," because we clearly
decided that is not the right behavior. :)

[I also think if they still don't see that, you, as maintainer, should
know better and stick to the decision we made, but that is clearly a
more controvercial judgement. =8^)]

I think you could make the argument that this disruption is mutt-dev's
fault for not making an effort to communicate this change--one we knew
was contentious at the time we were discussing it--in advance to
mutt-users, so that people could get used to the idea before it hit,
or get involved in the discussion while it was happening, to their
satisfaction.  Perhaps we should do that more in the future...
Regardless, I still maintain we made the right decision here and the
alternative behavior provides nothing good that the current one does
not, but does indeed detract, and should be avoided.

I've said my piece.

-- 
Derek D. Martinhttp://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.



pgpiEY94NQfAo.pgp
Description: PGP signature

Re: order of sending mail and saving to fcc

[Kevin J. McCarthy]

On Tue, Jun 11, 2019 at 05:28:26PM -0500, Derek Martin wrote:

Obviously you don't need to listen to me


I do listen to you, Derek.  The whole buffer pool migration is a result 
of your recurring prods, and I will continue to work on that, likely 
through the next couple major releases.


I also pay attention to other people's viewpoints, especially long time 
users.


Technically, the arguments for post-send fcc are fine.  I believe that, 
barring the most extreme cases, the pieces are there to prevent major 
loss (albeit sometimes with $tmpdir diving if mutt was killed).  It's 
now the default, and I don't have an intention of changing that.


It's easy to conclude that objections to the change are overly paranoid 
or irrational, but Mutt users in general *really* *care* about email. 
My interest is in empowering them, to the best of my ability.  I didn't 
make the change out of a desire to ruin their workflow, but moreso due 
to the technical problems of manipulating the message prior to sending.


It's evident, to me, that this change is extremely distressing to at 
least a subset of our users, who really care about having the message in 
their Fcc box before it gets sent out, regardless of the issues.


I can't give them exactly the old behavior, but I can _easily_ give them 
something approaching it.


Mutt already has tons of config vars, and Mutt is already a beast to 
learn how to configure


I agree.  However, to counter that I've tried to use and extend existing 
prefix namespaces, and more descriptive (if sometimes verbose) names. 
$forward_attachments for a forwarding option; $crypt_ and 
$crypt_protected_headers_ prefixes for the new Protected Headers; 
$imap_qresync; $history_remove_dups, etc.  The list grows longer, but in 
this way is (I hope) still possible to browse and understand what is 
changeable for a certain aspect of Mutt.


Regarding code complexity, the send code has already been simplified 
this release, partly because of the refactorings for the fcc-after 
change and Protected Headers introduction.  I would even say it's 
starting to approach readability ;-).  So, while I'm watchful for the 
proverbial straw on the camel's back, I'm still quite happy with the 
direction of the code and I'm not concerned about the impact of adding 
$fcc_before_send.


--
Kevin J. McCarthy
GPG Fingerprint: 8975 A9B3 3AA3 7910 385C  5308 ADEF 7684 8031 6BDA


signature.asc
Description: PGP signature

Re: order of sending mail and saving to fcc

[Derek Martin]

On Wed, Jun 12, 2019 at 05:20:02PM +1000, Erik Christiansen wrote:
> On 11.06.19 12:36, Derek Martin 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^)
> 
> I like your style, Derek. And respect that your use case works for you.
> What surprises me is the surplus of certitude which refuses to countenance
> a legitimate use case at variance with yours.

It's because it isn't, as I believe I've satisfactorily demonstrated.
The current behavior actually gets you literally everything you want.
It just does it differently than you expected... but it still does it.
There's no need for the Fcc first-behavior, and it is demonstrably
worse for more than one reason.  As such it should be excluded.  I can
not see how you could make any good argument to the contrary.

This is why mutt-dev rather quickly (by our standards regarding
contentious changes) agreed that the current behavior is the right
one.  We discussed it, came to a good conclusion about the solution,
it got implemented, and I think we should stick to that.  I am certain
that those who are objectiing are simply reacting negatively to
change, not realizing that it very clearly is a change for the better
which still gets them exactly what they wanted with Fcc-first
behavior, as the desire to do that went into that decision. That should
be clear to anyone who carefully read the discussion.

More code, more config variables, are inherently bad.  They increase
the burden of management of the code and the probgram, and increase
the learning curve for developers and for users.  A single variable is
obviously only a tiny marginal burden, but when the development
community does not actively resist the urge to add one for every
little triviality, you end up with hundreds of unnecessary such
things increasing complexity, the maintenance burden, the learning
curve, etc..  We have seen over the years that they can cause bugs
where they can interact in unexpected ways, breaking things.

TBH I think (and have long thought) Mutt already has way, way too many
config variables, probably a significant portion of which really don't
provide that much value and should really be removed.

So yes, I will continue to apply some resistance to adding new ones,
as Thomas used to do, for all the same reasons he did.  There should
be a significant positive change in Mutt that is provided by a new
config variable, to counteract that inherent negative, before adding
it is even considered, and in my estimation this one provides only
negative.  But I am (sadly) just rehashing the conversation that went
into the original decision to implement the current behavior in the
first place. :(

-- 
Derek D. Martinhttp://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.



pgpN7n_ZBZN_z.pgp
Description: PGP signature

Re: order of sending mail and saving to fcc

[Erik Christiansen]

On 11.06.19 12:36, Derek Martin 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^)

I like your style, Derek. And respect that your use case works for you.
What surprises me is the surplus of certitude which refuses to countenance
a legitimate use case at variance with yours.

If a new feature had been requested, then a higher bar to adding a
config option would have more merit. But where previously supported
behaviour had been removed, then it is only fair to other users for the
replacement behaviour to be optional only. Making the new behaviour the
default is in fact an (entirely acceptable) indulgence, I submit.

Erik

Re: order of sending mail and saving to fcc

[Erik Christiansen]

On 11.06.19 13:45, Kevin J. McCarthy wrote:
> On Tue, Jun 11, 2019 at 06:43:25AM -0700, Kevin J. McCarthy wrote:
> > Something like $fcc_order or $fcc_before_send is possible,
> 
> I've pushed a branch up to gitlab, kevin/fcc-before-send.  It adds
> $fcc_before_send, default unset.

Many grateful thanks, Kevin. That leaves Derek unimpacted, while
restoration of what we had protects older use cases. Nicolas' case of a
recipient having a copy of an email, but the sender not, can be a
serious problem. For the last half year I have been exchanging
(approval) stamped plans with authorities, consultants, engineers, and
now building contractors. As I've made design changes along the way, it
is very import to know which version of the plans has been received by
which recipient - and that a quote received here applies to a specific
plans version.

> The caveats to enabling are as mentioned: message manipulation is turned
> off, so $fcc_clear and $fcc_attach are ignored.  Another change (from before
> 1.12.0) is if the Fcc fails, you are prompted to retry or save to another
> mailbox, rather than returned to the compose menu.

The caveats are just fine in my use case. I had to look up $fcc_clear,
as I've never figured out any use for message signing. (The framing
carpenters would doubtless look at me oddly if I sent such stuff.)
And, oh goody!, $fcc_attach defaults to yes, so the plans and other attachments
will be saved.

Prompting for an Fcc retry seems ideal to me. To regain that, in place of
being dumped elsewhere, is another improvement. Mission accomplished -
Mutt much improved.

> The branch is off of stable, and is fairly minimal.  I planned on releasing
> 1.12.1 this weekend with some important fixes.  If those opposed to the new
> Fcc behavior think this is an acceptable alternative, I'll be glad to
> include it in that release.

That would be brilliant, Kevin. I'll look for it next week, then.
Many thanks, again, for the effort you're putting in to make mutt the
ideal MUA - despite a variety of use cases in the wild.

Erik

Re: order of sending mail and saving to fcc

[mutt]

Derek Martin wrote:

> On Tue, Jun 11, 2019 at 01:45:18PM -0700, Kevin J. McCarthy wrote:
> > On Tue, Jun 11, 2019 at 06:43:25AM -0700, Kevin J. McCarthy wrote:
> > I've pushed a branch up to gitlab, kevin/fcc-before-send.  It adds
> > $fcc_before_send, default unset.
> 
> Obviously you don't need to listen to me, but I do want to state for
> the record that I'm opposed to this change going in.  I'm sure a lot
> of people will say, "Oh, it's just a config variable."  Those
> who've been paying attention will realize I've consistently argued
> against new config variables by default, over the last 20+ years, and
> I'll restate my unwavering reasoning for that here:
> 
> Mutt already has tons of config vars, and Mutt is already a beast to
> learn how to configure--I think it takes years for people to even
> realize all the features Mutt has that are configurable, nevermind
> getting a config that does all they want.  As such, (I believe) adding
> a new config variable is inherently bad, and should only be done when
> the good of having the alternative behaviors outweighs that bad.  Such
> cases clearly exist, and in those cases I don't argue against them.
> 
> This is not such a case.  I believe I have demonstrated in my last
> post in this thread, using sound logic, that the alternative behavior
> is not only never an improvement for any of the stated concerns, but
> inarguably worse for some of the relevant concerns, and as such clearly
> does not outweigh the bad of making Mutt that much more unweildy to
> understand and configre.  Therefore, the change should not be
> committed.
> 
> -- 
> Derek D. Martinhttp://www.pizzashack.org/   GPG Key ID: 0xDFBEAD02

I could be wrong (and I haven't read the patch so apologies if
I'm being silly) but I think that this patch might be too simple.
If all it does is perform the fcc before sending rather than
after sending, then the message that it saves isn't the message
that is subsequently sent (as explained earlier).

While I personally think that the copy in the /tmp directory
suffices in times of trouble (so far anyway), clearly not
everyone agrees. However, I would expect such people to still
want the actual message that is saved to be a true record of the
message that was sent (taking into account the other fcc-related
config options). At least, once it is successfully sent.

So, if something like this config option were to go ahead, it
should probably save the pre-sending version before sending and,
when the sending succeeds, replace the pre-sending version of the
message with the final version that was actually sent. Otherwise,
the saved message is only appropriate for re-sending but not
appropriate as a permanent record of what was sent. At least,
that's the impression I get from reading this thread.

But that sounds like messy behaviour if the pre-sending copy and
the post-sending copy are in the same file. If the patch is as I
imagine, the documentation should make it clear that turning the
new config option on means that the messages that are saved are
not identical to the messages as they were sent.

Having the pre-sending copy in a separate file would help keep
the code change simple but of course that will bring about yet
another config option to supply the name of the additional file
(like postponed). Another advantage of a separate file for
messages-that-are-in-the-process-of-being-sent is that the
presence of the file on disk is an indication of a failure to
send since the file would be deleted or emptied when the
post-sending copy is saved.

Note that I'm not recommending these changes, just pointing out
that using the new fcc_before_send shouldn't necessarily mean
that the sent box is no longer a true record of what was sent.

Again, apologies for wasting time if I've misunderstood things.
I've used mutt for decades but I'm no expert on its internals.

cheers,
raf

Re: order of sending mail and saving to fcc

[Derek Martin]

On Tue, Jun 11, 2019 at 01:45:18PM -0700, Kevin J. McCarthy wrote:
> On Tue, Jun 11, 2019 at 06:43:25AM -0700, Kevin J. McCarthy wrote:
> I've pushed a branch up to gitlab, kevin/fcc-before-send.  It adds
> $fcc_before_send, default unset.

Obviously you don't need to listen to me, but I do want to state for
the record that I'm opposed to this change going in.  I'm sure a lot
of people will say, "Oh, it's just a config variable."  Those
who've been paying attention will realize I've consistently argued
against new config variables by default, over the last 20+ years, and
I'll restate my unwavering reasoning for that here:

Mutt already has tons of config vars, and Mutt is already a beast to
learn how to configure--I think it takes years for people to even
realize all the features Mutt has that are configurable, nevermind
getting a config that does all they want.  As such, (I believe) adding
a new config variable is inherently bad, and should only be done when
the good of having the alternative behaviors outweighs that bad.  Such
cases clearly exist, and in those cases I don't argue against them.

This is not such a case.  I believe I have demonstrated in my last
post in this thread, using sound logic, that the alternative behavior
is not only never an improvement for any of the stated concerns, but
inarguably worse for some of the relevant concerns, and as such clearly
does not outweigh the bad of making Mutt that much more unweildy to
understand and configre.  Therefore, the change should not be
committed.

-- 
Derek D. Martinhttp://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.



pgpkyRaySVW0q.pgp
Description: PGP signature

Re: order of sending mail and saving to fcc

[Kevin J. McCarthy]

On Tue, Jun 11, 2019 at 06:43:25AM -0700, Kevin J. McCarthy wrote:

Something like $fcc_order or $fcc_before_send is possible,


I've pushed a branch up to gitlab, kevin/fcc-before-send.  It adds 
$fcc_before_send, default unset.


The caveats to enabling are as mentioned: message manipulation is turned 
off, so $fcc_clear and $fcc_attach are ignored.  Another change (from 
before 1.12.0) is if the Fcc fails, you are prompted to retry or save to 
another mailbox, rather than returned to the compose menu.


The branch is off of stable, and is fairly minimal.  I planned on 
releasing 1.12.1 this weekend with some important fixes.  If those 
opposed to the new Fcc behavior think this is an acceptable alternative, 
I'll be glad to include it in that release.


--
Kevin J. McCarthy
GPG Fingerprint: 8975 A9B3 3AA3 7910 385C  5308 ADEF 7684 8031 6BDA


signature.asc
Description: PGP signature

Re: 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. Martinhttp://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.



pgpwITz4RVDLQ.pgp
Description: PGP signature

Re: order of sending mail and saving to fcc

[John Long]

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

Re: order of sending mail and saving to fcc

[Nicolas Rachinsky]

* Derek Martin  [2019-06-11 12:47 -0500]:
> Not only that, but I neglected the fact that if the send fails, the
> file your editor produced in order for it to be passed to Mutt will
> still be on disk, so you do IN FACT still have a copy of the message.

I did just (using my old mutt) set sendmail to killall -9 mutt. The
temporay file that stayed on my disk did contain my text. But there
was no other information (recipients, subject, attachments).

So if the tmpdir survives, not everything is lost. But the mail as
such is lost.

> That is, barring catastrophic system failure, which no mail client
> will ever save you from.

Data loss in case of a catastrophic system failure is not the thing
to argue about. The thing to argue about is, which case of events
is made catastrophic by mutt.

HAND
Nicolas

Re: order of sending mail and saving to fcc

[Nicolas Rachinsky]

* Derek Martin  [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

Re: order of sending mail and saving to fcc

[Nicolas Rachinsky]

* Derek Martin  [2019-06-11 12:16 -0500]:
> On Mon, Jun 10, 2019 at 11:24:11AM +0200, Nicolas Rachinsky wrote:
> > * Jack M  [2019-06-04 10:20 -0500]:
> > > On Tue, June 4, 2019 5:30 am, Nicolas Rachinsky wrote:
> > > > The other one (mail sent, but no local copy)
> > > 
> > > Why would this situation would ever occur?
> > 
> > A power failure at the wrong moment. A crash at the wrong moment. ...
> > 
> > These things tend to happen only at wrong moments.
> 
> But the failure mode of the current behavior is superior:  With the
> old way, you look in Fcc and see the message was sent, so you don't
> send it again (unless you're unusually paranoid, maybe).

But I cannot create the same message again. 

> With the current way, you see there's no message in Fcc, and you send
> it again.

If I do not have the message, how do I send it again?

> And by the way, changes like this one don't happen in a vaccuum.  The
> change was discussed on mutt-dev at some length when it happened, and
> it was eventually agreed that the new behavior is the right one.


Thanks to Kevin J. McCarthy who referred me to it. I habe read it, but
I did not find any convincing argument. 

HAND
Nicolas

Re: order of sending mail and saving to fcc

[Derek Martin]

On Tue, Jun 11, 2019 at 12:36:00PM -0500, Derek Martin wrote:
> 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.

Not only that, but I neglected the fact that if the send fails, the
file your editor produced in order for it to be passed to Mutt will
still be on disk, so you do IN FACT still have a copy of the message.
That is, barring catastrophic system failure, which no mail client
will ever save you from.

-- 
Derek D. Martinhttp://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.



pgpScU1faFRBm.pgp
Description: PGP signature

Re: order of sending mail and saving to fcc

[Derek Martin]

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's not your
mail client's job to protect you from every conceibable system failure
which might cause data loss, nor should it be.  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. 

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

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

-- 
Derek D. Martinhttp://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.



pgpa9q0F0H3H8.pgp
Description: PGP signature

Re: order of sending mail and saving to fcc

[Derek Martin]

On Mon, Jun 10, 2019 at 11:24:11AM +0200, Nicolas Rachinsky wrote:
> * Jack M  [2019-06-04 10:20 -0500]:
> > On Tue, June 4, 2019 5:30 am, Nicolas Rachinsky wrote:
> > > The other one (mail sent, but no local copy)
> > 
> > Why would this situation would ever occur?
> 
> A power failure at the wrong moment. A crash at the wrong moment. ...
> 
> These things tend to happen only at wrong moments.

But the failure mode of the current behavior is superior:  With the
old way, you look in Fcc and see the message was sent, so you don't
send it again (unless you're unusually paranoid, maybe).

With the current way, you see there's no message in Fcc, and you send
it again.

It's better to receive the same e-mail twice, than to never receive it
at all, if it contains important content.

And by the way, changes like this one don't happen in a vaccuum.  The
change was discussed on mutt-dev at some length when it happened, and
it was eventually agreed that the new behavior is the right one.

-- 
Derek D. Martinhttp://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.



pgpJPD9wD7jeR.pgp
Description: PGP signature

Re: order of sending mail and saving to fcc

[Kevin J. McCarthy]

On Tue, Jun 11, 2019 at 10:04:25PM +1000, Erik Christiansen wrote:
If developers insist on the backwards method for themselves, then is an 
fcc_order config option possible for the benefit of users seeking the 
old reliability?


Something like $fcc_order or $fcc_before_send is possible, but with the 
caveat that, pre-send, the message would be saved exactly as sent.  That 
is, $fcc_clear and $fcc_attach would be ignored.


Mutt now defaults $pgp_self_encrypt, so if $pgp_default_key is set an 
encrypted message would still be readable.


Would that be an acceptable alternative?

--
Kevin J. McCarthy
GPG Fingerprint: 8975 A9B3 3AA3 7910 385C  5308 ADEF 7684 8031 6BDA


signature.asc
Description: PGP signature

Re: order of sending mail and saving to fcc

[Erik Christiansen]

On 10.06.19 11:20, Nicolas Rachinsky wrote:
> * "Kevin J. McCarthy"  [2019-06-04 09:44 -0700]:
> > On Tue, Jun 04, 2019 at 12:30:59PM +0200, Nicolas Rachinsky wrote:
> > > Does anybody know the reason of this change?
> > 
> > The most recent discussion on mutt-dev was
> > .  The issue is
> > contentious, and there are arguments on both sides.
> 
> Thank you for the reference.
> 
> > In this case, the comments by active developers seemed to be in consensus
> > that prompting if Fcc fails afterwards is a reasonable compromise.
> 
> Ok, so I will replace $sendmail by something that saves the mail
> first, since not having a local copy of a sent mail (for an easily
> avoidable reason) is just not acceptable here. :(

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.

We have backups for our files for a reason - recovery is impossible
without them. To deliberately create a potentially irrecoverable
situation in mutt is incomprehensible. If developers insist on the
backwards method for themselves, then is an fcc_order config option
possible for the benefit of users seeking the old reliability?

Mind you, I can avoid the problem by remaining on my old mutt, and never
updating.

Erik

Re: order of sending mail and saving to fcc

[Nicolas Rachinsky]

* Ben Boeckel  [2019-06-10 11:56 -0400]:
> If you're this paranoid, the only real fix is to have your editor save a
> backup somewhere before handing it off to mutt in the first place
> anyways. After all, mutt could segfault and lose it before the Fcc!

There is one big difference. If mutt crashes before saving the mail to
fcc, nobody has one. So this avoids the problem with sent mail without
any local copy.


I have a related question: When does mutt unlink attached files (with
unlink set)? Before sending, between sending and fccing or after
fccing?


Nicolas

Re: order of sending mail and saving to fcc

[Felix Finch]

On 20190610, Ben Boeckel wrote:

On Mon, Jun 10, 2019 at 08:40:30 -0700, Felix Finch wrote:

As other(s) have mentioned, power failure, cat jumping on keyboard.  I
have also had sends hang seemingly forever, and the only way forward
is tokill the tmux session.  Then I have no Fcc copy.  I can root
around /tmp to find the message, but I shouldn''t have to.


Doe mutt do the right fsync dance for power failure anyways? How would a
cat jumping on the keyboard possibly a failure mode *anyone* can *plan*
for? (I've had mine swat the power strip switch before which is at least
intersecting with other failure modes.)


Cat could hit 'q' and then you will have neither Fcc nor send copy.


Killing the tmux session seems overkill. You couldn't kill just the
pane holding mutt? Tmux being completely unresponsive sounds like either
a sendmail or tmux bug.


Of course this is what I meant.  And when ^C and ^\ do nothing, I consider it
time to kill the tmux session / pane.  I suppose I could open a new terminal
session, in tmux (because tmux is still responding), and killall mutt, but the
distinction is insignificant.


For me, the difference is that having extra Fcc copies is nowhere near
as bad as not having any.



If you're this paranoid, the only real fix is to have your editor save a
backup somewhere before handing it off to mutt in the first place
anyways. After all, mutt could segfault and lose it before the Fcc!


If it is paranoid to consider the ramifications of a change, then the
implementors of said change were also paranoid.

Please be less snarky and more serious.  You do your arguments no favors.

--
   ... _._. ._ ._. . _._. ._. ___ .__ ._. . .__. ._ .. ._.
Felix Finch: scarecrow repairman & wood chipper / fe...@crowfix.com
 GPG = E987 4493 C860 246C 3B1E  6477 7838 76E9 182E 8151 ITAR license #4933
I've found a solution to Fermat's Last Theorem but I see I've run out of room o

Re: order of sending mail and saving to fcc

[Ben Boeckel]

On Mon, Jun 10, 2019 at 08:40:30 -0700, Felix Finch wrote:
> As other(s) have mentioned, power failure, cat jumping on keyboard.  I
> have also had sends hang seemingly forever, and the only way forward
> is tokill the tmux session.  Then I have no Fcc copy.  I can root
> around /tmp to find the message, but I shouldn''t have to.

Doe mutt do the right fsync dance for power failure anyways? How would a
cat jumping on the keyboard possibly a failure mode *anyone* can *plan*
for? (I've had mine swat the power strip switch before which is at least
intersecting with other failure modes.)

Killing the tmux session seems overkill. You couldn't kill just the
pane holding mutt? Tmux being completely unresponsive sounds like either
a sendmail or tmux bug.

> For me, the difference is that having extra Fcc copies is nowhere near
> as bad as not having any.

If you're this paranoid, the only real fix is to have your editor save a
backup somewhere before handing it off to mutt in the first place
anyways. After all, mutt could segfault and lose it before the Fcc!

--Ben

Re: order of sending mail and saving to fcc

[Felix Finch]

On 20190610, Felix Finch wrote:

Perhaps a compromise is to Fcc as a draft file first, then send, then move the 
draft Fcc file to its permanent location.


Not so clever with IMAP draft files.  It would have to be a special local file, 
and mutt would have to look for it on start.

--
   ... _._. ._ ._. . _._. ._. ___ .__ ._. . .__. ._ .. ._.
Felix Finch: scarecrow repairman & wood chipper / fe...@crowfix.com
 GPG = E987 4493 C860 246C 3B1E  6477 7838 76E9 182E 8151 ITAR license #4933
I've found a solution to Fermat's Last Theorem but I see I've run out of room o

Re: order of sending mail and saving to fcc

[Felix Finch]

On 20190604, Jack M wrote:

The other one (mail sent, but no local copy)


Why would this situation would ever occur?


As other(s) have mentioned, power failure, cat jumping on keyboard.  I have 
also had sends hang seemingly forever, and the only way forward is tokill the 
tmux session.  Then I have no Fcc copy.  I can root around /tmp to find the 
message, but I shouldn''t have to.

For me, the difference is that having extra Fcc copies is nowhere near as bad 
as not having any.

Another factor is that the Fcc is much less likely to fail than the send.

Perhaps a compromise is to Fcc as a draft file first, then send, then move the 
draft Fcc file to its permanent location.

--
   ... _._. ._ ._. . _._. ._. ___ .__ ._. . .__. ._ .. ._.
Felix Finch: scarecrow repairman & wood chipper / fe...@crowfix.com
 GPG = E987 4493 C860 246C 3B1E  6477 7838 76E9 182E 8151 ITAR license #4933
I've found a solution to Fermat's Last Theorem but I see I've run out of room o

Re: order of sending mail and saving to fcc

[Nicolas Rachinsky]

* Francesco Ariis  [2019-06-04 19:52 +0200]:
> Hello Grant,
> 
> On Tue, Jun 04, 2019 at 04:46:50PM -, Grant Edwards wrote:
> > On 2019-06-04, Jack M  wrote:
> > 
> > > The reason (or *a* reason) is that the old way led to the following
> > > situation: Fcc first, then try to send, something weird happens, but
> > > the user has no idea whether the mail was actually sent or not
> > 
> > How could the user not know? If the send fails, mutt prints an error
> > message and stays on the message compose screen.  It's pretty
> > obvious...
> 
> I have the bad habit of pressing 'q' (exit to menu) after sending.
> Also terminal corruption or similar events: you can't be sure whether
> the message was actually sent.

With the new order this behaviour might lead to a sent mail without
a local copy. If you miss the failure to send, you might as well
miss the failure to fcc.

HAND
Nicolas

Re: order of sending mail and saving to fcc

[Nicolas Rachinsky]

* Jack M  [2019-06-04 10:20 -0500]:
> On Tue, June 4, 2019 5:30 am, Nicolas Rachinsky wrote:
> > The other one (mail sent, but no local copy)
> 
> Why would this situation would ever occur?

A power failure at the wrong moment. A crash at the wrong moment. ...

These things tend to happen only at wrong moments.

HAND
Nicolas

Re: order of sending mail and saving to fcc

[Nicolas Rachinsky]

* "Kevin J. McCarthy"  [2019-06-04 09:44 -0700]:
> On Tue, Jun 04, 2019 at 12:30:59PM +0200, Nicolas Rachinsky wrote:
> > Does anybody know the reason of this change?
> 
> The most recent discussion on mutt-dev was
> .  The issue is
> contentious, and there are arguments on both sides.

Thank you for the reference.

> In this case, the comments by active developers seemed to be in consensus
> that prompting if Fcc fails afterwards is a reasonable compromise.

Ok, so I will replace $sendmail by something that saves the mail
first, since not having a local copy of a sent mail (for an easily
avoidable reason) is just not acceptable here. :(

have a nice day
Nicolas

Re: order of sending mail and saving to fcc

[Grant Edwards]

On 2019-06-04, Jack M  wrote:
> On Tue, June 4, 2019 10:46 am, Grant Edwards wrote:
>> On 2019-06-04, Jack M  wrote:
>>
>>
>>> The reason (or *a* reason) is that the old way led to the following
>>> situation: Fcc first, then try to send, something weird happens, but
>>> the user has no idea whether the mail was actually sent or not
>>
>> How could the user not know?
>
> Very easily.
>
>> If the send fails, mutt prints an error message and stays on the message
>> compose screen.
>
> The part starting with "and" is not always true, though.  I've been bitten
> several times by mutt flashing an error message so quickly that I can't
> read it, and then immediately showing an empty inbox with a completely
> different error message about a lost connection to the IMAP server.

Then that's a bug, and it needs to be fixed.  If you try to send a
message and it fails, there's no way you should leave the message
compose screen.  Changing the order of the send/fcc operations to try
to hide problems like that seems odd.

--
Grant

Re: order of sending mail and saving to fcc

[Jack M]

On Tue, June 4, 2019 10:46 am, Grant Edwards wrote:
> On 2019-06-04, Jack M  wrote:
>
>
>> The reason (or *a* reason) is that the old way led to the following
>> situation: Fcc first, then try to send, something weird happens, but
>> the user has no idea whether the mail was actually sent or not
>
> How could the user not know?

Very easily.

> If the send fails, mutt prints an error message and stays on the message
compose screen.

The part starting with "and" is not always true, though.  I've been bitten
several times by mutt flashing an error message so quickly that I can't
read it, and then immediately showing an empty inbox with a completely
different error message about a lost connection to the IMAP server.

-jack

Re: order of sending mail and saving to fcc

[Francesco Ariis]

Hello Grant,

On Tue, Jun 04, 2019 at 04:46:50PM -, Grant Edwards wrote:
> On 2019-06-04, Jack M  wrote:
> 
> > The reason (or *a* reason) is that the old way led to the following
> > situation: Fcc first, then try to send, something weird happens, but
> > the user has no idea whether the mail was actually sent or not
> 
> How could the user not know? If the send fails, mutt prints an error
> message and stays on the message compose screen.  It's pretty
> obvious...

I have the bad habit of pressing 'q' (exit to menu) after sending.
Also terminal corruption or similar events: you can't be sure whether
the message was actually sent.

I see the points made by Nicolas Rachinsky too.

Re: order of sending mail and saving to fcc

[Grant Edwards]

On 2019-06-04, Jack M  wrote:

> The reason (or *a* reason) is that the old way led to the following
> situation: Fcc first, then try to send, something weird happens, but
> the user has no idea whether the mail was actually sent or not

How could the user not know? If the send fails, mutt prints an error
message and stays on the message compose screen.  It's pretty
obvious...

> and so has to contact the recipient.  (The Fcc'd copy contains no
> information to tell the user whether the mail was sent.)  This was
> not a rare occurrence.

-- 
Grant Edwards   grant.b.edwardsYow! I have many CHARTS
  at   and DIAGRAMS..
  gmail.com

Re: order of sending mail and saving to fcc

[Kevin J. McCarthy]

On Tue, Jun 04, 2019 at 12:30:59PM +0200, Nicolas Rachinsky wrote:

Does anybody know the reason of this change?


The most recent discussion on mutt-dev was 
.  The issue is 
contentious, and there are arguments on both sides.


In this case, the comments by active developers seemed to be in 
consensus that prompting if Fcc fails afterwards is a reasonable 
compromise.


Another reason was the implementation of Protected Headers.  The current 
mechanism supporting $fcc_attach and $fcc_clear already went through 
gymnastics to transform the message, save to Fcc, and back out those 
changes for sending.  The introduction of Protected Headers made backing 
out changes substantially more difficult without breaking cryptographic 
signatures.


--
Kevin J. McCarthy
GPG Fingerprint: 8975 A9B3 3AA3 7910 385C  5308 ADEF 7684 8031 6BDA


signature.asc
Description: PGP signature

Re: order of sending mail and saving to fcc

[Jack M]

On Tue, June 4, 2019 5:30 am, Nicolas Rachinsky wrote:
> Hallo,
>
>
> I just noted the entry in UPDATING:
> ! Fcc now occurs after sending a message.  If the fcc fails, mutt will
> prompt to try again, or to try another mailbox.
>
> This seems to be:
> https://gitlab.com/muttmua/mutt/commit/e106487b1f4ebe7128982486accec11ac6f
> 54b5c
>
>
> Does anybody know the reason of this change?

The reason (or *a* reason) is that the old way led to the following
situation: Fcc first, then try to send, something weird happens, but the
user has no idea whether the mail was actually sent or not and so has to
contact the recipient.  (The Fcc'd copy contains no information to tell
the user whether the mail was sent.)  This was not a rare occurrence.

The new way is a million times better.  If something weird happens during
the sending attempt, the user now is aware of this and can decide what to
do.  No misleading Fcc copy is put in a mailbox.  The user can give up,
save a copy of the message to a local folder, etc.

> The other one (mail sent, but no local copy)

Why would this situation would ever occur?

-jack

Re: order of sending mail and saving to fcc

[Ben Boeckel]

On Tue, Jun 04, 2019 at 12:30:59 +0200, Nicolas Rachinsky wrote:
> I considered the previous order (save to fcc, then send the mail)
> always the correct one. If anything bad happens (network connectivity
> failing (in case of imap), computer crashing,...), it seems to
> produce the better outcome.

I'm in favor of the change. If sending does fail, mutt leaves you at the
composition window (attach?) to do a postponement, try sending again,
etc. The problem I'd see is that if sending failed due to some network
error, I'd have 3 or 4 copies of the email by the time it finally gets
fixed in the relevant mailbox that I had to delete manually.

> The situation where I have the mail locally, but it was not sent can
> easily recovered on my side. The other one (mail sent, but no local
> copy) cannot be always recovered without contacting the recipient.

You still have the copy, but it is just saved after sending. Or are you
worried about Fcc failing after being sent?

--Ben

order of sending mail and saving to fcc

[Nicolas Rachinsky]

Hallo,

I just noted the entry in UPDATING:
  ! Fcc now occurs after sending a message.  If the fcc fails, mutt will prompt
to try again, or to try another mailbox.

This seems to be:
https://gitlab.com/muttmua/mutt/commit/e106487b1f4ebe7128982486accec11ac6f54b5c

Does anybody know the reason of this change?

I considered the previous order (save to fcc, then send the mail)
always the correct one. If anything bad happens (network connectivity
failing (in case of imap), computer crashing,...), it seems to
produce the better outcome.

The situation where I have the mail locally, but it was not sent can
easily recovered on my side. The other one (mail sent, but no local
copy) cannot be always recovered without contacting the recipient.

Thank you in advance.

Nicolas