Alexander Zangerl writes:
> On Sun, 03 Feb 2019 14:13:24 +, Harald Geyer writes:
> >I get the following error:
> >| What now? send
> >| sendmail: No recipients specified although -t option used
> >| exit 1
>
> could you please provide (possibly sanitised) copies
> of your ~/.mh_profile and /etc/nmh/mts.conf?
I actually installed nmh from scratch to reproduce the bug before
writing up the report, so there shouldn't be anything special in there,
but sure:
lambda@hdev:~$ cat .mh_profile
MH-Profile-Version: 1.0
Path: Mail
lambda@hdev:~$ cat .mh_profile
MH-Profile-Version: 1.0
Path: Mail
lambda@hdev:~$ cat /etc/nmh/mts.conf
# nmh mail transport interface customization file.
#
# Check the mh-tailor(5) man page for descriptions of available options.
#
# The delivery method to use, which must be one of the following:
# smtp: nmh opens a socket connection to the appropriate port
#on the servers listed below and speaks SMTP to the
#first one that responds. This is the default.
# sendmail/smtp: nmh pipes messages directly to the sendmail program,
#speaking SMTP. Can be abbreviated to "sendmail".
# sendmail/pipe: nmh pipes messages directly to the sendmail program,
#using the -t option so that addresses are retrieved
#from the message.
mts: sendmail/pipe
# Name that nmh considers `local'. If not set, nmh will
# query the system for this value (gethostname, etc...).
#localname: foo.bar.com
# Default location of mail drops. If this option is
# set, but empty, the user's home directory is used.
mmdfldir: /var/mail
# The name of the maildrop file in the directory where maildrops
# are kept. If this is empty, the user's login name is used.
mmdflfil:
#
# The locking algorithm to use on the spool file. Valid settings are:
#
# fcntl Locking using the fcntl() function
# dot "Dot" locking using an external lock file
# flock Locking using the flock() function (if supported by OS)
# lockf Locking using the lockf() function (if supported by OS)
#
# Locking algorithms supported on this installation are:
#
# fcntl dot flock lockf
#
# The default spool locking configured on this system is fcntl;
# change the line below to get a different value
#spoollocking: fcntl
# Hardcoded POP server name (prevents inc'ing from local mail spool).
#pophost: localhost
# A SINGLE SMTP server to use when using SMTP support
servers: localhost
> >Both recipients get messages with different Message-Ids, but the
> >content seems to be exactly the same.
> ...
> >I believe this is in conflict
> >with the man page of send(1), which states that Bcc-recipients will
> >receive a message with a clear indication in the body, warning them
> >not to disclose their status as recipients by replying.
>
> i don't see any indication in the send manpage that supports your reasoning.
It is implied in the description of the dcc header.
> but looking closely at the FAQ, the post manpage and the actual
> code i do see that nmh tries to reformat bcc's under some/many/most
> circumstances (and offers a weird nonstandard dcc header to create the
> 'normal'/classic behaviour of identical copies).
>
> i can confirm that nmh 1.7 has buggy bcc handling, at least
> when sendmail/pipe is used as transport:
> using a shim program instead of actual sendmail/postfix/whatever i could see
> that the sequence of comp-whatnow-post creates TWO messages to transmit,
>
> * one that contains the original body, complete with to: and bcc:,
> ie. leaving sendmail/postfix/whatever to handle that bcc:,
> which causes normal mail transfer agents to produce the
> 'normal'/classic bcc: behaviour,
> * and one that has the warning-encrusted body but no to: at all and only a
> blank
> bcc: header. that one is clearly untransmittable, which is what causes
> the error message you saw.
>
> i'll get in touch with upstream and have a deeper look at the problem myself
> as well.
>
> you might try switching to 'smtp' or 'sendmail/smtp' in /etc/nmh/mts.conf
> as a potential workaround until that bug is sorted;
Thanks for the info. I guess this explains why I vaguely remember bcc
working in the past.
> note that
> according to the mts.conf manpage dcc: is NOT supported if 'sendmail/pipe'
> is the transport.
Thanks again, I'd have totally missed that. Sometimes it is hard to
know which man pages to read ... :)
Thanks for your help,
Harald
