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

2005-08-28 Thread Iljitsch van Beijnum 

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

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.


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?)

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.


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?

___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

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

2005-08-28 Thread Bruce Lilly 
>  Date: 2005-08-26 17:44
>  From: Peter Dambier <[EMAIL PROTECTED]>
>  To: IETF General Discussion Mailing List 
>  Reply to: [EMAIL PROTECTED]

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: 

> 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 PROTECTED]>

> 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 PROTECTED]>

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