Alexander Zangerl writes: > On Sun, 03 Feb 2019 14:13:24 +0000, 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
