Subject: Reply-To (Was Re: [Re: regarding IETF lists using mailman: nodupes considered harmful])

From: Bruce Lilly <[email-masked]>
Date: Sun, 28 Aug 2005 13:55:47 -0400

>  Date: 2005-08-26 17:44
>  From: Peter Dambier <[email-masked]>
>  To: IETF General Discussion Mailing List <[email-masked]>
>  Reply to: [email-masked]

N.B.^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
> Iljitsch van Beijnum wrote:

> > No, what needs to happen if we collectively decide we don't want the  
> > current behavior is that the mailinglist software sets a "reply-to"  
> > header, so when you hit "reply" or "group reply" your reply is sent  
> > with the list in the "To:" field and nothing else. This used to work  
> > well, not sure if modern clients handle this correctly, though. Try  to 
> > reply to this message to see what happens.

One important nit: Reply-To is an originator field (RFC 2822) and should
never be forged by somebody or something (e.g. list expander) other than the
originator.  Mailing lists have the List-Post field (RFC 2369) available
for mailing list use, e.g.:
List-Post: <mailto:[email-masked]>

> Great, it works!

Except of course when some people (ahem!) set Reply-To to an individual
mailbox, forcing respondents to use a reply-all function to reach the
discussion list (with a copy to the specified mailbox) if the optional
List-Post field is missing...

It is unsurprising that Reply-To functions in that manner; it is an explicit
purpose of the field dating back at least to RFC 724 (May 1977):

        3) Reply-to:

           This field provides a general mechanism for indicating  any
           mailbox(es)  to  which  responses  are  to  be sent.  Three
           different uses for this feature can be  distinguished.   In
           the  first  case,  the  author(s)  may  not  have   regular
           machine-based  mailboxes  and therefore wish to indicate an
           alternate machine address.  In the second case,  an  author
           may  wish  additional  persons  to  be  made  aware  of, or
           responsible for, responses; responders  should  send  their
           replies  to  the "Reply-to:" mailbox(es).  More interesting
           is a case such as text-message teleconferencing in which an
           automatic distribution facility  is  provided  and  a  user
           submitting  an  "entry" for distribution only needs to send
           their message to the mailbox(es) indicated in  the  "Reply-
           to:" field.

"text-message teleconferencing" is a quaint reference to mailing lists.
 
>  Date: 2005-08-26 23:46
>  From: "Joel M. Halpern" <[email-masked]>

> I really hate lists with "reply-to" pointing to the list.
> I know when I want to reply to the list, and when I want to reply 
> individually to the sender.  When reply-to points to the list, it is 
> extremely difficult with most mailers to send a reply to the originator.

Kmail, Evolution, and Sylpheed each have options for sending a response to
the message author directly, and Pine prompts for a user decision.  For
others, selection from a list or copy-and-paste often suffice.  I won't
try to characterize "most" UAs, as I haven't examined all of them, but if a
particular one lacks a feature, the most effective ways to remedy the problem
are to contact the supplier or, failing a suitable enhancement, to switch to
a UA that does provide the desired functionality.  Certainly there are plenty
of products available.

As noted in RFC 724 and its successors, there are several reasons for use of
the Reply-To field; clearly neither the field nor its uses are new.  The lack
of a facility for dealing with messages using the Reply-To field for its
intended purpose is a serious defect in an MUA.

>  Date: 2005-08-27 02:16
>  From: Frank Ellermann <[email-masked]>

> My "astonishment factor" was worse than the small difficulty
> to copy and paste From when I know that I have to be careful.

Reply-To is a standard field and ought to be visible when viewing the
original message [1].  In any event, the To field of the response ought to
be clearly visible.  In either case, if not, see above re. effective ways to
remedy UA problems.

----
1. Part of the problem is UAs which suppress message header fields, caused
   by the proliferation of "noise" fields in the message header (initially
   SMTP "Mail-From", subsequently renamed "Received", and now including a
   large number of others).  There is a series of drafts describing a
   backwards-compatible extension to the Internet Message Format to rectify
   that problem.  See draft-lilly-extensible-internet-message-format-p01-00
   and related parts p02-p04.

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Frank Ellermann <[email-masked]>
Date: Sun, 28 Aug 2005 21:28:28 +0200

Bruce Lilly wrote:

> Part of the problem is UAs which suppress message header
> fields, caused by the proliferation of "noise" fields in the
> message header (initially SMTP "Mail-From", subsequently
> renamed "Received", and now including a large number of
> others).

s/Received/Return-Path/ (or is this some pre-821 history ?)

Ordinary users are most probably not often interested in the
timespamp lines, and MUAs not showing them in their default
configuration are fine.

> See draft-lilly-extensible-internet-message-format-p01-00

Sorry, so far I didn't have the time to read your drafts (but
I have them in my public "collection" ;-)  Priority one on my
"todo"-list after USEFOR is now 2821bis - first thing I plan
is some kind of ABNF-diff.
                            Bye, Frank

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sun, 28 Aug 2005 21:42:29 +0200

On 28-aug-2005, at 19:55, Bruce Lilly wrote:

> originator.

Well, to me, the mailing list "re-originates" the message, so I don't  
see the problem.

(Why did you set a reply-to header, then?)

> others, selection from a list or copy-and-paste often suffice.

The trouble is that the mail clients I'm familiar with (and that's  
not too many, somehow learning a new one always freaks me out) give  
the user the option to either reply to the sender (as in: address in  
the From: header) or do a group reply, where everyone else is put  
into the CC: header. What I would really like is "reply to the list"  
but that's not an option. Removing the sender in To: and moving the  
list from CC: to To: is too much work: there is considerable mousing  
or complex keyboard stuff involved. I know it sounds silly that a two- 
second task would be too much work, but then, apparently the much  
simpler task of simply removing any unnecessary text left at the  
bottom of the finished message (shift-apple-cursor down backspace in  
my case) is deemed too hard for more and more people, with the result  
that each reply contains all messages before it, if these lazy  
bandwidth-wasters are left to their own devices.

> the most effective ways to remedy the problem are to contact the  
> supplier or

Not effective at all. My mail client is broken in several ways since  
the last OS update several months ago, but so far, the bugs aren't  
even acknowledged, let alone fixed. So feature requests: forget it.

> failing a suitable enhancement, to switch to a UA that does provide  
> the desired functionality.

Is there a list of what functionality can be found where?