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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



>  Date: 2005-08-26 17:44
>  From: Peter Dambier <peter@xxxxxxxxxxxxxxxx>
>  To: IETF General Discussion Mailing List <ietf@xxxxxxxx>
>  Reply to: peter@xxxxxxxxxxxxxxxx

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:ietf@xxxxxxxx>

> 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" <joel@xxxxxxxxxxxxxxxx>

> 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 <nobody@xxxxxxxxxxxxxxxxx>

> 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@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]