* Thomas Roessler <roessler@xxxxxxxxxxxxxxxxxx> [2004:05:22:08:46:55+0200]
scribed:
> On 2004-05-21 15:52:52 -0500, Michael D Schleif wrote:
>
> > What can be done about this?
>
> unset write_bcc
Yes, I finally found this, and several archived posts from this and
other lists, discussing this matter. Thank you.
This is not an acceptable solution for me, because it also removes bcc
headers from that copy filed away in record==sent. All of the other
MUA's I've tested strip the bcc header on outgoing messages, but retain
the original bcc header for the archived sent message -- except mutt.
This is important for two main reasons:
[1] Historical tracking; and
[2] Facility to re-send the same message to the exact same recipients.
Google led me to several old mailing list discussions (here, exim and
elsewhere) that pointed me to write_bcc, on the mutt side, and -t
argument to exim. I have not found a way to get -t to work. In
~/.muttrc, this failed no matter what sequence the arguments:
sendmail="/usr/sbin/sendmail -t -oem -oi"
I could _not_ successfully send out any email at all.
So, from the exim side, I tried to change /etc/inetd.conf:
smtp stream tcp nowait mail /usr/sbin/exim exim -bs -t
This worked for outgoing mail; but, I could no longer _receive_ email.
Finally, I found a hint to modify the remote_smtp transport in exim.conf:
headers_remove = bcc
This appears to do everything as I expect. Anybody know any gotchas
about this?
Yes, I do understand the arguments on both sides. Exim believes that no
MTA has the right to mess with headers, and the RFC's do not contradict
this. Mutt believes that bcc headers are sent out with reason, and if I
don't like that, then *NO* bcc headers will persist at all.
I do not know which side is right, nor do I care. Since the RFC's
appear to be agnostic in this regard, I think that it should be up to
the user/sender to decide how to keep blind carbon copies blind.
Personally, I cannot imagine -- under any circumstances whatsoever --
why I would want anybody else in the universe to know my bcc list?!?!
At anyrate, I also cannot understand why it is so difficult to find a
solution to this problem. Perhaps this lame thread will cut short other
seekers' travails . . .
--
Best Regards,
mds
mds resource
877.596.8237
-
Dare to fix things before they break . . .
-
Our capacity for understanding is inversely proportional to how much
we think we know. The more I know, the more I know I don't know . . .
--
Attachment:
signature.asc
Description: Digital signature