ietf-822
[Top] [All Lists]

Re: [Fwd: I-D ACTION:draft-moore-mail-nr-fields-00.txt]

2004-09-05 14:39:08

As it's implemented today, Reply-to is little more than a surrogate
From.  Actually, we would probably be better off without it

I strongly disagree. It is often necessary to specify that replies should
go elsewhere than the mailbox(es) in the From field:
1. a message sent from work, responses desired at home or vice versa

users should be able to set the From field on a per-message basis.
(it's not forgery if the address belongs to you)

2. multiple authors, responses should go to one author

potentially useful, but rarely used

3. the case in point, message sent from an individual, responses should
   go to a list mailbox

fair enough. though presumably the list is one of the recipients of the message, and if there were a way to say "don't reply to the author" that would also work.

there are indeed cases where it would be useful if the author could redirect replies (say, to a secretary) but the way Reply tends to be implemented by user agents, this isn't likely to work well anyway.

I think the current typical user interface has the wrong split between what the author of a message specifies and what the recipient specifies when he's composing a reply.

Now you might say "forge From" instead of using Reply-To, but that
won't work with some times of authentication and spam filtering.

most forms of spam filtering are too broken to use anyway. and any authentication mechanism that restricts the setting of From is broken. From is clearly not intended to be used for that purpose.

Now it happens to be the case that most MUAs have two types of reply
functions corresponding to the two cases.

Both of which do the wrong thing.  "plain reply" should probably be
(and be labeled) "reply to author".

Nothing prevents MUA authors from implementing that -- indeed, pine
can be configured so, and Kmail provides a working "Reply to Author"
in addition to other types of responses.

maybe other MUA authors need encouragement?

The other "reply" (call it "group
reply") should probably have some way of excluding recipients that, for
whatever reason, should not receive replies.

Are you suggesting a field that modifies the interpretation of a different
field? I thought you were opposed to that.

everything else being equal, I would prefer something like To-NoReply. but I am trying to keep an open mind about other possibilities.

It might be the case that
"group reply" should be the default, though this would probably be too
big a departure from existing behavior.

We probably ought not to specify such details of UA design as which type
of response is the default.

not clear. lack of uniformity in UA behavior causes problems. I don't think we should specify details like what the interface should look like, where the buttons should be, whether it's a command-line or GUI interface, etc. I do think it might be useful to encourage some degree of uniformity as to which functions are provided, and I do think it might be useful to say "please provide ways of doing these things".

Many MUAs don't even display reply-to fields when viewing
a message.

The MUAs mentioned above, as well as several others, do.  In any
event, when a response is being composed, surely the recipient(s)
is/are displayed in any sensible MUA -- advice to MUA authors
comes into play if there are any MUAs that don't display recipients when
composing a response.

often there's no easy way to tell how the recipients of a reply relate to the sender and recipients of the original message. that is why reply behavior can be surprising.

I haven't use MacOS of any flavor for sending mail, but I've had no
problems with doing so, including cutting and pasting addresses in
(and *between*) common MUAs on several flavors of MS Windows
and under the X Window System.   Taht aside, we should differentiate
architectural issues from implementation issues. Architecturally, there
is nothing preventing a user from viewing or setting message header
fields. Implementation issues may well warrant advice to MUA authors.

I agree that these are implementation issues.

Keith


<Prev in Thread] Current Thread [Next in Thread>