rmail reply creates 2 CC: fields, violates RFC 2822

rmail reply creates 2 CC: fields, violates RFC 2822

[Joe Harrington]

I have the following in .emacs:

(setq mail-default-reply-to "jh@physics.ucf.edu")
(setq mail-default-headers (concat "Full-Name: Joe Harrington\n"
				   "CC: jh@physics.ucf.edu\n"))

When I reply to an rmail message that has a CC: in it, it (mail-mode
or rmail-mode, I'm not sure) makes a second CC: field for the
addresses in the original CC: of the message being replied to.  This
violates RFC 2822, which in section 3.6 specifies that there shall be
only one CC: in the header of an email message.  While this crime is
not often prosecuted (2822 is a proposed standard, but is listed by
rfc-editor.org as obsoleting 822), I am getting warnings from my
department's Debian-based exim4 mailer for each reply message I send.
This is, at the very least, very annoying (see below).  A good
solution would be either to search for an existing CC: before
inserting the reply CC:s, or, if those go in first, providing a new
variable mail-always-cc that gets combined with the reply CC:s to make
one field.

Thanks,

--jh--

Content-Type: multipart/report; report-type=delivery-status;
 boundary="----------=_1198091319-18423-3"
MIME-Version: 1.0
Subject: Delivery status notification, invalid header: duplicate header field
From: "Content-filter at locutus.physics.ucf.edu" <postmaster@physics.ucf.edu>
To: <jh@physics.ucf.edu>
Date: Wed, 19 Dec 2007 14:08:33 -0500 (EST)

This is a multi-part message in MIME format...

------------=_1198091319-18423-3
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

Your message WAS SUCCESSFULLY RELAYED to:
  <pschell@mail.ucf.edu>
  <fleniken@physics.ucf.edu>
  <jh@physics.ucf.edu>
  <mucciolo@physics.ucf.edu>
  <rohit@physics.ucf.edu>
  <sstolbov@physics.ucf.edu>

This delivery report was generated by the program amavisd-new at host
locutus.physics.ucf.edu. Our internal reference code for your message is
18423-11/UTvxf0uH4+ha

INVALID HEADER: DUPLICATE HEADER FIELD

  Duplicate header field: "Cc"

Return-Path: <jh@physics.ucf.edu>
Message-ID: <wl8odcm7b9o.fsf@glup.physics.ucf.edu>
Subject: Re: Next meeting

DUPLICATE HEADER FIELD

  The RFC 2822 standard specifies rules for forming internet messages.
  Section '3.6. Field definitions' specifies that certain header fields
  must not occur more than once in a message header.

------------=_1198091319-18423-3
Content-Type: message/delivery-status; name="dsn_status"
Content-Disposition: inline; filename="dsn_status"
Content-Transfer-Encoding: 7bit
Content-Description: Delivery delay report

Reporting-MTA: dns; locutus.physics.ucf.edu
Received-From-MTA: smtp; locutus.physics.ucf.edu ([127.0.0.1])
Arrival-Date: Wed, 19 Dec 2007 14:08:33 -0500 (EST)

Original-Recipient: rfc822;pschell@mail.ucf.edu
Final-Recipient: rfc822;pschell@mail.ucf.edu
Action: delayed
Status: 2.0.0
Diagnostic-Code: smtp; 250 2.6.0 Bad message, but will be delivered anyway
Last-Attempt-Date: Wed, 19 Dec 2007 14:08:33 -0500 (EST)
Final-Log-ID: 18423-11/UTvxf0uH4+ha

Original-Recipient: rfc822;fleniken@physics.ucf.edu
Final-Recipient: rfc822;fleniken@physics.ucf.edu
Action: delayed
Status: 2.0.0
Diagnostic-Code: smtp; 250 2.6.0 Bad message, but will be delivered anyway
Last-Attempt-Date: Wed, 19 Dec 2007 14:08:33 -0500 (EST)
Final-Log-ID: 18423-11/UTvxf0uH4+ha

Original-Recipient: rfc822;jh@physics.ucf.edu
Final-Recipient: rfc822;jh@physics.ucf.edu
Action: delayed
Status: 2.0.0
Diagnostic-Code: smtp; 250 2.6.0 Bad message, but will be delivered anyway
Last-Attempt-Date: Wed, 19 Dec 2007 14:08:33 -0500 (EST)
Final-Log-ID: 18423-11/UTvxf0uH4+ha

Original-Recipient: rfc822;mucciolo@physics.ucf.edu
Final-Recipient: rfc822;mucciolo@physics.ucf.edu
Action: delayed
Status: 2.0.0
Diagnostic-Code: smtp; 250 2.6.0 Bad message, but will be delivered anyway
Last-Attempt-Date: Wed, 19 Dec 2007 14:08:33 -0500 (EST)
Final-Log-ID: 18423-11/UTvxf0uH4+ha

Original-Recipient: rfc822;rohit@physics.ucf.edu
Final-Recipient: rfc822;rohit@physics.ucf.edu
Action: delayed
Status: 2.0.0
Diagnostic-Code: smtp; 250 2.6.0 Bad message, but will be delivered anyway
Last-Attempt-Date: Wed, 19 Dec 2007 14:08:33 -0500 (EST)
Final-Log-ID: 18423-11/UTvxf0uH4+ha

Original-Recipient: rfc822;sstolbov@physics.ucf.edu
Final-Recipient: rfc822;sstolbov@physics.ucf.edu
Action: delayed
Status: 2.0.0
Diagnostic-Code: smtp; 250 2.6.0 Bad message, but will be delivered anyway
Last-Attempt-Date: Wed, 19 Dec 2007 14:08:33 -0500 (EST)
Final-Log-ID: 18423-11/UTvxf0uH4+ha

------------=_1198091319-18423-3
Content-Type: text/rfc822-headers; name="header"
Content-Disposition: inline; filename="header"
Content-Transfer-Encoding: 7bit
Content-Description: Message headers

Return-Path: <jh@physics.ucf.edu>
Received: from glup.physics.ucf.edu (glup.physics.ucf.edu [10.171.140.16])
	(Authenticated sender: jh@physics.ucf.edu)
	by locutus.physics.ucf.edu (Postfix) with ESMTP id 571C54D80DB;
	Wed, 19 Dec 2007 14:08:33 -0500 (EST)
Date: Wed, 19 Dec 2007 14:08:35 -0500
Message-Id: <wl8odcm7b9o.fsf@glup.physics.ucf.edu>
From: Joe Harrington <jh@physics.ucf.edu>
To: sstolbov@physics.ucf.edu
CC: mucciolo@physics.ucf.edu, rohit@physics.ucf.edu,
	pschell@mail.ucf.edu, fleniken@physics.ucf.edu
In-reply-to: <20071219123524.tgefxapylwcw0c00@physics.ucf.edu>
	(sstolbov@physics.ucf.edu)
Subject: Re: Next meeting
Full-Name: Joe Harrington
CC: jh@physics.ucf.edu
Reply-To: jh@physics.ucf.edu
References: <000901c841b2$c517baf0$2c8eab0a@rahman1>
	<wl8zlw77l0v.fsf@glup.physics.ucf.edu>
	<8E542E44-8429-44C6-8E44-97AE89B37F34@physics.ucf.edu>
	<000601c84257$d4a91d60$2c8eab0a@rahman1> <47694EA1.2020408@physics.ucf.edu> <20071219123524.tgefxapylwcw0c00@physics.ucf.edu>

------------=_1198091319-18423-3--

Re: rmail reply creates 2 CC: fields, violates RFC 2822

[Richard Stallman]

It is ridiculous to restrict the user in this way.

I often send messages with multiple CC lines.  I put in multiple CC
lines by hand.  I'd rather program Rmail to automatically delete those
warnings (which should be easy) than go to the trouble of
consolidating CC fields.

Who should we contact to call for a change in RFC 2822?