Re: nmh query
Hi David, > I don't know what msmtp does with Bcc: lines. It removes them by default. https://marlam.de/msmtp/msmtp.html#remove_005fbcc_005fheaders > Perhaps the msmtp documention offers information on the keepbcc that > you mentioned. keepbcc was renamed to remove_bcc_headers in msmtp 1.6.0. https://marlam.de/msmtp/news-archive.html -- Cheers, Ralph.
Re: nmh query
Date:Mon, 04 Nov 2019 21:30:26 -0500 From:David Levine Message-ID: <14902-1572921026.632...@bdjh.xawd.osnl> | I'd be interested to see how much of that makes it through to each of you. This (the list message) was just as would be expected. The bcc with Received, X-Received, X-Google-DKIM-Signature, X-Gm-Message-State, and X-Google-Smtp-Source fields omitted here; they were all between the Return-Path (added when the message arrived, of course) and the From fields: Return-Path: From: David Levine Date: Mon, 04 Nov 2019 21:30:26 -0500 Message-ID: <14902-1572921026.632...@abfc.a5ot.rhvn> Subject: Re: nmh query BCC: --- Blind-Carbon-Copy To: nmh-workers@nongnu.org From: David Levine Subject: Re: nmh query In-Reply-To: Your message of Mon, 04 Nov 2019 12:41:21 +0700 References: <103064.1572832605@turing-police> <1566906103416.58394b5e41b92...@rfob.org> <15752.1572806...@olgas.newt.com> <15334-1572811692.926...@bf5j.dink.lmvm> <20164.1572846...@jinx.noi.kre.to> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Date: Mon, 04 Nov 2019 21:30:26 -0500 Message-ID: <14902-1572921026.632...@bdjh.xawd.osnl> [message body just the same as the list message] --- End of Blind-Carbon-Copy Looks fine to me, I see no reason to change anything. kre
Re: nmh query
Robert writes: > At least one recipient field used to be required, when Bcc is the only one, > it had to be be retained (it didn't need to, and shouldn't, contain any > addresses, but the field had to remain). This requirement seems to have > been deleted, and now a message with no recipient fields is OK, but for > compat with older MUAs (potentially even MTAs) it is still a good idea to > include an empty Bcc: field when there are no To or Cc fields. Thanks for that explanation. nmh does retain the (always blank) BCC: in the blind copies. Valdis, the non-blind message does not retain any Bcc fields, so no leak there. I included the following in this message draft: Bcc: b...@rfob.org, Robert Elz , "Valdis Kl=?utf-8?Q?ē?=tnieks" I'd be interested to see how much of that makes it through to each of you. David
Re: nmh query
Date:Sun, 03 Nov 2019 20:56:45 -0500 From:"Valdis Kl=?utf-8?Q?=c4=93?=tnieks" Message-ID: <103064.1572832605@turing-police> | I'll go further and assert that if there is still a Bcc: header in the | RFC822 headers once the MSA has accepted the mail for further processing, | that somebody has dropped the ball Not always, sometimes there is only the Bcc header containing recipients. At least one recipient field used to be required, when Bcc is the only one, it had to be be retained (it didn't need to, and shouldn't, contain any addresses, but the field had to remain). This requirement seems to have been deleted, and now a message with no recipient fields is OK, but for compat with older MUAs (potentially even MTAs) it is still a good idea to include an empty Bcc: field when there are no To or Cc fields. | because sometimes, even a Bcc: that shows that there *were* | other recipients may be an unacceptable information leak When there is another recipient field, and this copy of the message is to an address that is in that other field, that's reasonable. But when the message is being delivered to someone on the Bcc list (which is all the time when that was the only recipient field) there needs to be something to explain to the recipient why the message was delivered to them - a Bcc field ("one or more others received this message - you were one of them") achieves that purpose, whether it contains the recipient's address, or not. kre
Re: nmh query
>That's proper behavior. BCC is *blind* carbon copy, specifically >intended to *not* show who else got copies. I'd argue that the only >time it's acceptable to list recipients there is if you are feeding >to an MSA that's like 'sendmail -t' that needs it to get additional >recipients because you can't speak SMTP and hand off RCPT TO:<...> for >the Bcc people. To get back to the larger point ... with sendmail/pipe, you are accepting reduced functionality. MH-style BCC will continue to work. But Dcc (which behaves like everyone other MUA's Bcc) will not. --Ken
Re: nmh query
On Sun, 03 Nov 2019 15:08:12 -0500, David Levine said: > And it looks like BCC: has never listed the bcc recipients. This > is from the MH 6.8.5 post.c: > > fprintf (out, "BCC:\n"); That's proper behavior. BCC is *blind* carbon copy, specifically intended to *not* show who else got copies. I'd argue that the only time it's acceptable to list recipients there is if you are feeding to an MSA that's like 'sendmail -t' that needs it to get additional recipients because you can't speak SMTP and hand off RCPT TO:<...> for the Bcc people. And of course, you trust your MTA to then promptly eat that header and not promulgate it any further. I'll go further and assert that if there is still a Bcc: header in the RFC822 headers once the MSA has accepted the mail for further processing, that somebody has dropped the ball because sometimes, even a Bcc: that shows that there *were* other recipients may be an unacceptable information leak pgpw8DkFlpVvb.pgp Description: PGP signature
Re: nmh query
Bala writes: > hi david > > thanks for any help! here is my mh_profile entry > > send: -mts sendmail/pipe -sendmail /home/bala/bin/msmtp -noverbose -alias > /home/bala/.mhrc OK, with sendmail/pipe, all addresses are provided in the message itself to the sendmail program. BSD sendmail deletes Bcc: lines: -t Read message for recipients. To:, Cc:, and Bcc: lines will be scanned for recipient addresses. The Bcc: line will be deleted before transmission. I don't know what msmtp does with Bcc: lines. Perhaps the msmtp documention offers information on the keepbcc that you mentioned. While it doesn't have anything to do with this, note that nmh's Dcc: is not supported with sendmail/pipe. I would use sendmail/smtp if you want support for Dcc:. David
Re: nmh query
Hi Bala, > b...@rfob.org wrote: > > > if there is a small nit in nmh-1.7.1 (even with keepbcc on in .msmtprc > > BCC: line does not show up to bcc recipients) who do i ask? .msmtprc looks like something used by msmtp. nmh does not use it, not does it have any kind of keepbcc setting. And it looks like BCC: has never listed the bcc recipients. This is from the MH 6.8.5 post.c: fprintf (out, "BCC:\n"); If you want us to look into this further, which mail transport are you using (smtp, sendmail/smtp, or sendmail/pipe)? That would be set either in nmh's mts.conf, your ~/.mh_profile, or in your invocation of send with the -mts switch. David
Re: nmh query
[Trying to get through some backlog before upcoming travel builds it back up again.] Hey, you started using MH a couple of years before me. Awesome. I'm still using 1.6, so I'm unfamiliar with the keepbcc and .msmtprc file. Please use nmh-workers@nongnu.org for your question. b...@rfob.org wrote: > i read the faq - honest injun! > > i started using mh in 1982 and it still works - thanks in part to folks like > you! > > if there is a small nit in nmh-1.7.1 (even with keepbcc on in .msmtprc > BCC: line does not show up to bcc recipients) who do i ask? > > thanks much! > cheers > bala > -- Bill Wohler aka http://www.newt.com/wohler/, GnuPG ID:610BD9AD