On 01Nov2019 18:56, Kevin J. McCarthy <ke...@8t8.us> wrote:
It sounds like this needs to be changed. I'm not sure I like the patch
as-is, but the basic idea sounds reasonable to me.
I see three possibilities:
1) Change the default of $write_bcc to 'no', and also change the
behavior so that Bcc is written to the Fcc mailbox regardless of the
setting. This has the advantage of not changing any *documentated*
behavior, as the option says nothing about Fcc. (Of course, I'd
update the documentation and announce the changes.)
2) Change the behavior of $write_bcc to only control writing to the
Fcc mailbox (as the patch does). My question is whether the option is
useful in this state. Which leads to a third possibility:
3) Remove the option. Never write Bcc when sending, and always when
Fcc'ing.
I likely won't be able to look at this for about a week, as I travel
home, so opinions very welcome!
Subjectively, I have always assumed that Bcc is stripped from the sent
email. And therefore that the default mode should implement that
behaviour. (*)
So I'm very +1 for write_bcc defaulting to no. It is only useful to be
yes if the sendmail executable is reading addresses from the headers.
Conversely, I'd expect an Fcc to preserve all the headers. If I resent
an Fcc copy I'd expected mutt again to strip the bcc for send and keep
it for fcc.
So I'm +1 for option (1) or (2) or (3), with the default behaviour of
strip-bcc-for-send and keep-bcc-for-fcc.
What do we do with removed options? Do the elicit errors from the mutt
startup, or maybe just a warning? (Thinking about using the same muttrc
on machines with different mutt versions.)
(*) and it would appear I've been using the default i.e. write_bcc=yes
for years. I need to fix that.
Cheers,
Cameron Simpson <c...@cskk.id.au>
