Mutt Email Client - mutt, exim, write_bcc, Bcc: field/header, debian. Resolved.

Author

mutt, exim, write_bcc, Bcc: field/header, debian. Resolved.

Dan Bray

2006-09-25, 1:34 am

Hello all,

This is a post to document the resolution (strictly speaking, work-around)
for a problem we've had for several years.
It relates to the well-known problem in using mutt and exim together.

Description:
When the MUA mutt is used along with the MTA exim, the Bcc field is not
written in the record of the outgoing mail.

Work-around:
Unfortunately, I know of only a system-level solution to this, not
per-user!

- Create /etc/exim4/exim.filter, which contains the line
headers remove "Bcc"
- Edit /etc/exim4/exim4.conf.template to add, early on, the line
system_filter=/etc/exim4/exim.filter
- Edit your ~/.muttrc, or /etc/Muttrc, to explicitly set
set write_bcc=yes
- run, as root,
update-exim4.conf
- as root, restart exim
/etc/init.d/exim4 restart

Cause:
(I'll keep things brief by focusing on the debian installation used here.)
I used to have no such problem. It may have arisen when debian started
using exim as its default MTA.
Debian has known about this problem, and so the system-level /etc/Muttrc
has been edited to unset write_bcc:

# Exim does not remove Bcc headers
unset write_bcc

So the user ends up with no record of the Bcc field in his/her outgoing
folder! (Exim does receive, and work on, the Bcc list. So all recipients
will receive the mail and will not see the Bcc list.)
Unfortunately, this is more than an annoyance. Both my old ~/.muttrc
and the Mutt manual say that the default for write_bcc is True! So the
behaviour appeared to have no explanation.

Root Cause:
It is suggested to have to do with exim's expectations of whether an
MUA is allowed to touch headers or not. IOW, the interface between
the MUA and the MTA is contentious. My uninformed, impatient,
suspicion is that this may involve different interpretations of an
RFC.

<rant on>
If so, then this is nothing new. These are two glorious pieces of
software, but the end result is that the user is left with years of
unrecorded Bcc lists. If I may vent, the effect is &^%(&^%(& annoying.
<rant off>

Proposed Solution:
As an end user, I fully expect that the Bcc field is *always* removed
from outgoing mail. Ergo, exim always strips Bcc regardless of mutt's
decision to include it in the header or not.
In trying to provide the option of blinding the _sender_ to the Bcc,
the functionality is broken.

exim:
Vague interface specifications are nothing new. I'd argue that no
interpretation should result in Bcc lists being sent out. So exim
should not argue that it is bound by the spec's. It always strips Bcc.

mutt:
Certainly, the choice of writing to the 'record' folder is not bound by
RFCs. Mutt is perfectly free to decide for itself. So why not provide a
new option distinct from write_bcc? Jim Gottlieb echoed this on
Dec 20 2001 in this NG as well.

debian:
Instead of unsetting write_bcc in /etc/Muttrc, use the above system filter
to force exim to always strip Bcc.

Thanks go to the posts of Michael D Schleif to mailing.unix.mutt-users
back on 21-22 May 2004. However, he was suggesting a transport filter.
As this'd have to be applied to each transport, the above system filter
is a slight improvement IMHO on his idea.

And thanks much to all the time, effort and talent which the mutt,
exim and debian folks have put into these.

Reply to this NG only.
Thanks all,
Dan
PS Yes I know that there likely are mistakes in the above. But it is also
bound to save lots of folks lots of time.

Alain Bench

2006-09-25, 1:20 pm

Hello Dan,

On Monday, September 25, 2006 at 0:56:06 +0000, Dan Bray wrote:

> the well-known problem in using mutt and exim together.

First of all, thank you very much for sharing your solution. :-)

> These are two glorious pieces of software, but the end result is that
> the user is left with years of unrecorded Bcc lists.

Each party claims to be innocent, and points the finger to the other
party. When IMHO both are at fault. And the 2 faults collaborate to
produce the problem.

> why not provide a new [Mutt] option distinct from write_bcc?

Useless: Mutt should $record BCC unconditionally, regardless of
$write_bcc, which should only act on what's passed to $sendmail. There
may even already be a patch doing this, IINM: I failed to locate it...

Bye! Alain.
--
Give your computer's unused idle processor cycles to a scientific goal:
The Folding@home project at <URL:http://folding.stanford.edu/>.

Dan Bray

2006-09-26, 1:31 am

Alain Bench <albench.NOSP@M.oreka.invalid> writes:

> On Monday, September 25, 2006 at 0:56:06 +0000, Dan Bray wrote:

>
> Useless: Mutt should $record BCC unconditionally, regardless of
> $write_bcc, which should only act on what's passed to $sendmail. There

Hallelujah!

Paul Walker

2006-09-27, 1:25 am

On Tue, 26 Sep 2006 05:03:11 GMT, Dan Bray wrote:

> Hallelujah!

I think you may have misunderstood Alain - I believe that's not should as in
"that's what it currently does", but as in "that's what I want it to do".

--
Paul

Dan Bray

2006-09-28, 7:23 am

Paul Walker <usenet@blacksun.org.uk> writes:

> On Tue, 26 Sep 2006 05:03:11 GMT, Dan Bray wrote:
>
>
> I think you may have misunderstood Alain - I believe that's not should as in
> "that's what it currently does", but as in "that's what I want it to do".

I understood the latter.
But thanks anyway.