Dear Maintainer,

When sending mail using heirloom-mailx, I have been accustomed to edit
the message with ~v, at which time I may add a Cc: header line with
one or more addresses.  Since I have `askcc` set, I would see these
addresses for confirmation after editing my message.  This was the
behavior I observed up through Debian 12 (bookworm?).

However, on the current Debian 13 release (trixie), the Cc:
information that I have edited in my ~v session is discarded.
I have confirmed its loss both using `set askcc` and also by actually
sending the message and confirming the absence of a Cc: header.

My ~/.mailrc begins as follows:

```
set append dot save VISUAL=emacs EDITOR=/usr/bin/less
set askcc
set askatend
unset askbcc
unset ignoreeof
set ask
set crt=24
unset hold
set metoo
set record=$HOME/outmail
set replyall # doesn't work on cs
ignore via message-id status received
set editheaders    # s-nail

alternates nr@cs nr@elan nr@hart nr@fs nr@princeton nr@notecnirp nr@k2 nr@Princeton.EDU nr@princeton.edu nr@princeton.EDU nr%cs@Princeton.EDU nr@phoenix nr@phoenix.Princeton.EDU mailrus!Princeton.EDU!nr idacrd!princeton!nr rutgers!hpsemc.cup.hp.com!princeton!nr surya!att!princeton!nr nr@cs.princeton.edu norman@bellcore.com norman@flaubert.bellcore.com norman@payday.bellcore.com norman@decadent.bellcore.com attbl!norman@bellcore.com norman.ramsey.1@purdue.edu
```

The rest of the ~/.mailrc is a long list of alias commands.


TL;DR: Since Debian 13 (trixie), heirloom-mailx no longer honors a Cc:
field added with ~v, even when `editheaders` is set.

Hello Norman Ramsey!

Norman Ramsey wrote in
 <176289465083.1076430.14783347885118237087.reportbug@homedog.cs.tufts.edu>:
 |Package: heirloom-mailx
 |Version: 12.5-4
 |Severity: normal
 |
 |Dear Maintainer,
 |
 |When sending mail using heirloom-mailx, I have been accustomed to edit
 |the message with ~v, at which time I may add a Cc: header line with
 |one or more addresses.  Since I have `askcc` set, I would see these
 |addresses for confirmation after editing my message.  This was the
 |behavior I observed up through Debian 12 (bookworm?).
 |
 |However, on the current Debian 13 release (trixie), the Cc:
 |information that I have edited in my ~v session is discarded.
 |I have confirmed its loss both using `set askcc` and also by actually
 |sending the message and confirming the absence of a Cc: header.
 |
 |My ~/.mailrc begins as follows:
 |
 |```
 |set append dot save VISUAL=emacs EDITOR=/usr/bin/less
 |set askcc
 |set askatend
 |unset askbcc
 |unset ignoreeof
 |set ask
 |set crt=24
 |unset hold
 |set metoo
 |set record=$HOME/outmail
 |set replyall # doesn't work on cs
 |ignore via message-id status received
 |set editheaders    # s-nail

I have some problems parsing your problem.

Please note first that the # comment sign on a line does not
create a shell-style comment, the above are all (somewhat
ignored, however) errors.  Comments are actually commands in
BSD Mail, so they must be placed on lines of their own.  (Newer
S-nail can support shell-style comments, with "set v15-compat=y"
for example; the someday upcoming v14.10 out of the box.)

I do not know what "set replyall" is about to achieve, `replyall'
is a(n obsolete) command, not a variable.  Looking at it now,
there was a Replyall variable (uppercase initial R) in Heirloom
mailx, documented as

       Replyall
              Reverses the sense of reply and Reply commands.

Hm.  Like the "flipr" variable.  Too much hassle, why not simply
use `reply' or `Reply' (or `Lreply' with S-nail; that also has
"commandalias"es).

Having said all that i have learned that Heirloom mailx 12.5 is no
longer supported in Debian (for quite some time)?  Are you sure
you are really using 12.5?
With S-nail v14.9.25 i cannot reproduce your problem as you
describe it; with the above resource placed in /tmp/t.rc i get:

  $ MAILRC=/tmp/t.rc mailx -:u -R
  mailx: Variable is read-only: #
  mailx: Variable names may not contain =, space or control characters: 'doesnt work on cs'
  mailx: Variable is read-only: #
  mailx version v14.9.25.  Type `?' for help

aka

  $ MAILRC=/tmp/t.rc mailx -:u -Sv15-compat=y -R
  mailx version v14.9.25.  Type `?' for help

And i can ~v and add a Cc: header field, and i am asked to confirm
the list due to *askcc*, and the sent (displayed due to
"-Smta=test") email includes that Cc:.

Note: it MAY depend upon what content you have placed in Cc: --
because of the fix for CVE-2014-7844 [1] you may have to set the
*expandaddr* variable, you definitely have to do this for S-nail.

  [1] http://seclists.org/oss-sec/2014/q4/1066

 |alternates nr@cs nr@elan nr@hart nr@fs nr@princeton nr@notecnirp nr@k2 \
 |nr@Princeton.EDU nr@princeton.edu nr@princeton.EDU nr%cs@Princeton.EDU \
 |nr@phoenix nr@phoenix.Princeton.EDU mailrus!Princeton.EDU!nr idacrd!prin\
 |ceton!nr rutgers!hpsemc.cup.hp.com!princeton!nr surya!att!princeton!nr \
 |nr@cs.princeton.edu norman@bellcore.com norman@flaubert.bellcore.com \
 |norman@payday.bellcore.com norman@decadent.bellcore.com attbl!norman@bel\
 |lcore.com norman.ramsey.1@purdue.edu
 |```
 |
 |The rest of the ~/.mailrc is a long list of alias commands.

I .. do not actually know whether these ! UUCP address paths still
work out.  That is to say, whether they are meaningful.  I have
added an internal .TODO note for checking this out.  (I know for
sure your "8-bit in alias names" is still a hacky solution for
S-nail.)

... [.mailrc fragment omitted]

 > I have some problems parsing your problem.
 >
 > Please note first that the # comment sign on a line does not
 > create a shell-style comment, the above are all (somewhat
 > ignored, however) errors.

Interesting.  I have reread the man page for heirloom-mailx,
and I did not have much luck finding documentation of the format.

As you may have guessed, my .mailrc is very hold.  I likely wrote my
first .mailrc over 35 years ago.

 > Having said all that i have learned that Heirloom mailx 12.5 is no
 > longer supported in Debian (for quite some time)?  Are you sure
 > you are really using 12.5?

Yes:

   $ heirloom-mailx -V
   12.5 6/20/10

I do have s-nail v14.9.25 installed on my system, but interestingly it
is not offered as an implementation of `mailx`:

  $ update-alternatives --list mailx
  /usr/bin/bsd-mailx
  /usr/bin/heirloom-mailx
  /usr/bin/mail.mailutils
  /usr/bin/mh/mhmail

I'm not sure whether s-nail is considered incompatible with mailx or
if that's just an omission.

 > Note: it MAY depend upon what content you have placed in Cc: --
 > because of the fix for CVE-2014-7844 [1] you may have to set the
 > *expandaddr* variable, you definitely have to do this for S-nail.

I checked this out and no, it's not the issue.  Confirmed via test.

It appears that my best course of action will be to see about
migrating to s-nail.  (I have the "`-a` for attachment" semantics too
deeply embedded into my fingers to wish to migrate to bsd-mailx.)

 > (I know for sure your "8-bit in alias names" is still a hacky
 > solution for S-nail.)

I'm sorry—I don't know what you mean by 8-bit in alias names.
What does that maean?  And What part of my .mailrc suggested
that I am doing it?


Norman

Hello Norman.

Norman Ramsey wrote in
 <20251113175212.A5AAA2C1693@homedog.cs.tufts.edu>:
 |... [.mailrc fragment omitted]
 |
 |> I have some problems parsing your problem.
 |>
 |> Please note first that the # comment sign on a line does not
 |> create a shell-style comment, the above are all (somewhat
 |> ignored, however) errors.
 |
 |Interesting.  I have reread the man page for heirloom-mailx,
 |and I did not have much luck finding documentation of the format.

That is much, much older, and POSIX standardized as

  Null Command
  Synopsis:      # comment
  This null command (comment) shall be ignored by mailx.

Heirloom mailx documented it as

  If the command begins with a # sign, the line is ignored.

S-nail v14.9.25 is chatty

   #   The comment-command causes the entire line to be ignored.  Note:
       this really is a normal command which’ purpose is to discard its
       arguments, not a “comment-start” indicating special character,
       which means that for example trailing comments on a line are not
       possible (except for commands which use Shell-style argument
       quoting†).

 |As you may have guessed, my .mailrc is very hold.  I likely wrote my
 |first .mailrc over 35 years ago.

Great!  About a decade earlier than myself.

 |> Having said all that i have learned that Heirloom mailx 12.5 is no
 |> longer supported in Debian (for quite some time)?  Are you sure
 |> you are really using 12.5?
 |
 |Yes:
 |
 |   $ heirloom-mailx -V
 |   12.5 6/20/10

Oh, i have no idea of Debian.  I bought and used Debian 3.0,
"Woody" it surely was, to go away to FreeBSD 4.7 later.
I then tried it once when the Heirloom mailx maintainer was
reluctant to continue with s-nail, but the installation was
actually unusable, which caused a bit of a turmoil on some Debian
devel list the name of which i have forgotten.

 |I do have s-nail v14.9.25 installed on my system, but interestingly it
 |is not offered as an implementation of `mailx`:
 |
 |  $ update-alternatives --list mailx
 |  /usr/bin/bsd-mailx
 |  /usr/bin/heirloom-mailx
 |  /usr/bin/mail.mailutils
 |  /usr/bin/mh/mhmail
 |
 |I'm not sure whether s-nail is considered incompatible with mailx or
 |if that's just an omission.

I *think* there are even bug reports open on that.  This is
a Debianism, and so i am "technically unsuitable" (google
translate).

 |> Note: it MAY depend upon what content you have placed in Cc: --
 |> because of the fix for CVE-2014-7844 [1] you may have to set the
 |> *expandaddr* variable, you definitely have to do this for S-nail.
 |
 |I checked this out and no, it's not the issue.  Confirmed via test.
 |
 |It appears that my best course of action will be to see about
 |migrating to s-nail.  (I have the "`-a` for attachment" semantics too
 |deeply embedded into my fingers to wish to migrate to bsd-mailx.)
 |
 |> (I know for sure your "8-bit in alias names" is still a hacky
 |> solution for S-nail.)
 |
 |I'm sorry—I don't know what you mean by 8-bit in alias names.
 |What does that maean?  And What part of my .mailrc suggested
 |that I am doing it?

You complained in 2017 that your aliases do not work in s-nail;
i had implemented syntax rules according to Postfix aliases(5),
but after you came over i had to change it to support high-bit
bytes, semicolon and period in addition.

And now the roof burns!  Because you are not listed in s-nail's
THANKS even though i see

  179b39f392 sendout.c:mightrecord(): FIX: terminate starg list! (Norman Ramsey)
  1bc65e1bdc a_amv_var_lookup(): error log on empty environment variable (Norman Ramsey)
  8a4237d257 `alias': support high-bit bytes and semicolon (Norman Ramsey)
  135cbebe04 makefile: add missing reverse solidus (Norman Ramsey)
  80038311f1 Fix: do not generate charset=binary parameter (Norman Ramsey)..
  5cd0f50dc6 Restore historical behaviour of *askb?cc* (Norman Ramsey)

(not in a row, and some commits happen because i stumble over
things while looking into issues).

So yes, it seems we had several threads in between 2017-07-07 and
2017-09-11 regarding several deficits of s-nail, and it all
started because of the above Debianism, via

  ▸+l 102 Norman Ramsey                     2017-07-07         139/   6420 Bug#867623: heirloom-mailx is not an alternative for /usr/bin/mailx

It seems to me you are subscribed to the mailx mailing-list since
August third, 2017, too.  Yeah, well.  So little time, v14.10 is
in the works for about six years now, and is what i use for as
long.  So many changes, but still lots of TODO.

 |Norman
 --End of <20251113175212.A5AAA2C1693@homedog.cs.tufts.edu>

Greetings dear Norman!