Hello Norman Ramsey!
Norman Ramsey wrote in
<176289465083.1076430.14783347885118237087.report...@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 \
|[email protected] [email protected] [email protected] [email protected] \
|nr@phoenix [email protected] mailrus!Princeton.EDU!nr idacrd!prin\
|ceton!nr rutgers!hpsemc.cup.hp.com!princeton!nr surya!att!princeton!nr \
|[email protected] [email protected] [email protected] \
|[email protected] [email protected] attbl!norman@bel\
|lcore.com [email protected]
|```
|
|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.)
--steffen
|
|Der Kragenbaer, The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
