Re: MTA behavior with respect to Bcc headers

2019-11-01 Thread Fabian Groffen
Hi, I think this goes into the area of the dont-reveal-bcc.patch/write_bcc.patch Debian and Gentoo both have this patch, which also contains some of its rationales: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=467432 http://dev.mutt.org/trac/ticket/3337 (dead, is there a way to find its con

Re: MTA behavior with respect to Bcc headers

2019-11-01 Thread Kevin J. McCarthy
On Fri, Nov 01, 2019 at 09:56:24AM +0100, Fabian Groffen wrote: As can be read from the Debian bug, the original rationale was to be able to keep Bcc-header in the Fcc copy, but not reveal the Bcc header to the MTA, so whatever policy/decision it has, it can never spill it to the recipients. Th

Re: MTA behavior with respect to Bcc headers

2019-11-01 Thread Fabian Groffen
Hi Kevin, On 01-11-2019 18:56:06 +0800, Kevin J. McCarthy wrote: > On Fri, Nov 01, 2019 at 09:56:24AM +0100, Fabian Groffen wrote: > >As can be read from the Debian bug, the original rationale was to be > >able to keep Bcc-header in the Fcc copy, but not reveal the Bcc header > >to the MTA, so wha

Re: MTA behavior with respect to Bcc headers

2019-11-01 Thread Cameron Simpson
On 01Nov2019 18:56, Kevin J. McCarthy wrote: It sounds like this needs to be changed. I'm not sure I like the patch as-is, but the basic idea sounds reasonable to me. I see three possibilities: 1) Change the default of $write_bcc to 'no', and also change the behavior so that Bcc is written

Re: MTA behavior with respect to Bcc headers

2019-11-01 Thread Kevin J. McCarthy
On Sat, Nov 02, 2019 at 09:07:59AM +1100, Cameron Simpson wrote: What do we do with removed options? Do the elicit errors from the mutt startup, or maybe just a warning? (Thinking about using the same muttrc on machines with different mutt versions.) That's a good point, which I neglected to m

$send_multipart_alternative

2019-11-01 Thread Aaron Schrab
Just a couple thoughts after playing around a little bit with the $send_multipart_alternative option recently added to master. I think it would be nice to support some "magic" MIME type that the filter could return to indicate that no alternative should be generated. I may want to use this fo

Re: $send_multipart_alternative

2019-11-01 Thread Kevin J. McCarthy
On Fri, Nov 01, 2019 at 08:05:42PM -0400, Aaron Schrab wrote: I think it would be nice to support some "magic" MIME type that the filter could return to indicate that no alternative should be generated. I may want to use this for an occasional message, but not for the vast majority of messages

Re: $send_multipart_alternative

2019-11-01 Thread Kevin J. McCarthy
On Sat, Nov 02, 2019 at 08:49:14AM +0800, Kevin J. McCarthy wrote: Did you try previewing the message, or just sending it straight through? It *might* work, if you don't use preview before sending. Trying to preview will cause mutt to parse out the parts in a receive-mode manner, which won't w

Re: $send_multipart_alternative

2019-11-01 Thread Kevin J. McCarthy
On Sat, Nov 02, 2019 at 08:56:08AM +0800, Kevin J. McCarthy wrote: I'll have to look at the code when I have more time. But I still wonder if you sent the message, and whether the actual sent message was corrupt or just the preview. Okay, taking a quick peek, I see sending wouldn't work. The

Re: $send_multipart_alternative

2019-11-01 Thread Kevin J. McCarthy
On Sat, Nov 02, 2019 at 09:18:14AM +0800, Kevin J. McCarthy wrote: I don't want to over-complicate the code, but if there is a quick fix, I'll see what I can do about this. I won't have a chance to work on it until later this week though. I put together a quick hack and pushed it up to 'kevi