headers
Paul Jakma | 1 Jun 09:59
Picon

Re: mail-followup-to / mail-copies-to


On Sun, 29 May 2005, Paul Jakma wrote:

> A major part of /my/ problem with using Reply-To for directing 
> list-replies is that many MUAs will then direct replies (be it 
> 'reply' or 'reply-all') to the mailbox(es) in the Reply-To field 
> automatically *without* involving their user in this decision, with 
> great risk that user doesn't even notice the redirection (and hence 
> commits an indiscretion by sending a private reply to multiple 
> addresses, not just the original author).
>
> If that annoying behaviour were discouraged via an official 
> document I could then whine at the implementors of such MUAs,

So is there any interest in this as a possible way forward?

regards,
--

-- 
Paul Jakma	paul <at> clubi.ie	paul <at> jakma.org	Key ID: 64A2FF6A
Fortune:
"Ow, my face is on fire!"

 	--Ralph Wiggum
 	  Bart of Darkness (Episode 1F22)
Permalink | Reply | 0 comments |
headers
Paul Jakma | 1 Jun 10:03
Picon

Re: mail-followup-to / mail-copies-to


On Tue, 31 May 2005, Charles Lindsey wrote:

> Which is why there needs to be a standard to declare exactly what 
> it is supposed to do and not to do.

Yes, but just conceptually it's quite a broad concept.

Given the current state of things wrt Reply-To and MUA behaviour i 
think "Do no harm" should be a major factor. Adding scope for further 
ambiguity and/or diverging MUA behaviour is worse than present 
situation.

> Sure. But a proper MFT standard would state clearly who the reply 
> was to go to (subject to user override) in all the possible 
> combinations of List-Post fields, MFT fields, Reply-To fields, etc 
> that could arise.

Given previous discussion, it seems unlikely it could ever become a 
standard header though.

regards,
--

-- 
Paul Jakma	paul <at> clubi.ie	paul <at> jakma.org	Key ID: 64A2FF6A
Fortune:
The poetry of heroism appeals irresitably to those who don't go to a war,
and even more so to those whom the war is making enormously wealthy."
 		-- Celine
(Continue reading)

Permalink | Reply | 0 comments |
headers
Paul Jakma | 1 Jun 10:08
Picon

Re: Understanding response protocols


On Mon, 30 May 2005, Charles Lindsey wrote:

> Does it really allow you to set the Reply-To field according to the 
> "role"?

Yes it does.

With the caveat that at present it doesn't allow multi-mailbox 
Reply-To's to be set. I intend to nag on the Pine list to try get 
that fixed.

> Certainly, the intention wrt Mail-Followup-To was that 
> users could set something like those "roles", but in a manner that 
> generated a MFT field depedong on the "role".

Sure, I could do that.

But that's very configuration intensive. (Just as for the Reply-To 
solution). "I like to be copied on wide-replies" tends to be a global 
preference, it shouldn't need per-list configuration - just something 
you set once in your MUA and leave be (maybe on very rare occassions 
editing the header when composing an email, when it doesnt suit).

I'd still love a Foo-Copy-Me type header, much easier and clearer. 
But seems I wont get it. :(

regards,
--

-- 
Paul Jakma	paul <at> clubi.ie	paul <at> jakma.org	Key ID: 64A2FF6A
(Continue reading)

Permalink | Reply | 22 comments |
headers
Charles Lindsey | 2 Jun 11:46
Picon
Picon

Re: Understanding response protocols


In <Pine.LNX.4.63.0506010904260.7726 <at> sheen.jakma.org> Paul Jakma <paul <at> clubi.ie> writes:

>But that's very configuration intensive. (Just as for the Reply-To 
>solution). "I like to be copied on wide-replies" tends to be a global 
>preference, it shouldn't need per-list configuration - just something 
>you set once in your MUA and leave be (maybe on very rare occassions 
>editing the header when composing an email, when it doesnt suit).

>I'd still love a Foo-Copy-Me type header, much easier and clearer. 
>But seems I wont get it. :(

Well, as MFT is currently implemented, either it gets filled in by the
mailing list administrator (according to whatever the "list policy" is),
or by the original poster - something like

    Mail-Followup-To: me <at> mydomain.example,list-address <at> list.example

For a man who wants personal as well as list replies. But to provide that
funtionality conveniently requires the poster's MUA to be configured with
a list of known mailing lists, and how the MFT is to be formed for each.

It would be better if there were a couple of keywords so you could say

    Mail-Followup-To: poster,list

and configure that for all lists you subscribe to.

That presumes the MUA generating replies can figure out what 'poster'
means (easy - use the Reply-To/From address) and what 'list' means (not so
(Continue reading)

Permalink | Reply | 21 comments |
headers
Paul Jakma | 3 Jun 15:36
Picon

Re: Understanding response protocols


On Thu, 2 Jun 2005, Charles Lindsey wrote:

> Well, as MFT is currently implemented, either it gets filled in by 
> the mailing list administrator (according to whatever the "list 
> policy" is), or by the original poster - something like
>
>    Mail-Followup-To: me <at> mydomain.example,list-address <at> list.example
>
> For a man who wants personal as well as list replies. But to 
> provide that funtionality conveniently requires the poster's MUA to 
> be configured with a list of known mailing lists, and how the MFT 
> is to be formed for each.
>
> It would be better if there were a couple of keywords so you could say
>
>    Mail-Followup-To: poster,list
>
> and configure that for all lists you subscribe to.

To be honest, I'd rather see some kind of 'best-practice for 
Reply-To' document than MFT. Reply-To, in an ideal world, should work 
just as well. The only reason for MFT, it seems, is just to avoid 
bogus behaviour in MTAs wrt Reply-To.

I dont seem to having much success in my last mail asking whether 
it'd be an idea to draft such a BCP document though. :(

Which is a shame, cause until that is done we'll either continue 
having this discussion every now and then, or we'll see more and more
(Continue reading)

Permalink | Reply | 20 comments |
headers
Charles Lindsey | 6 Jun 15:43
Picon
Picon

Re: Understanding response protocols


In <Pine.LNX.4.63.0506031429140.947 <at> sheen.jakma.org> Paul Jakma <paul <at> clubi.ie> writes:

>On Thu, 2 Jun 2005, Charles Lindsey wrote:

>> It would be better if there were a couple of keywords so you could say
>>
>>    Mail-Followup-To: poster,list
>>
>> and configure that for all lists you subscribe to.

>To be honest, I'd rather see some kind of 'best-practice for 
>Reply-To' document than MFT. Reply-To, in an ideal world, should work 
>just as well. The only reason for MFT, it seems, is just to avoid 
>bogus behaviour in MTAs wrt Reply-To.

No! Reply-To is what you should use if you want to send a personal reply
to the author of, the original message (which indeed you sometimes need to
do if, for example, your reply is too complex/personal/whatever for
sending to thje complete list).

Therefore, it is evident that some further Reply-to-like header (MFT, MCT
or something new) is needed for use with the "Reply-to-List" command (or
Reply-to-All if Reply-to-list is not provided).

Such a header should be flexible enough to include/not-include the
original poster (or his nominee) in the reply, and to include/not-include
various sub-lists/super-lists/parallel-lists/no-list-at-all in the reply.

>> Actually, that is all beginning to look quite like the
(Continue reading)

Permalink | Reply | 19 comments |
headers
Bruce Lilly | 6 Jun 20:40
Picon

Re: Understanding response protocols


On Mon June 6 2005 09:43, Charles Lindsey wrote:
> 
> In <Pine.LNX.4.63.0506031429140.947 <at> sheen.jakma.org> Paul Jakma <paul <at> clubi.ie> writes:

> >To be honest, I'd rather see some kind of 'best-practice for 
> >Reply-To' document than MFT. Reply-To, in an ideal world, should work 
> >just as well. The only reason for MFT, it seems, is just to avoid 
> >bogus behaviour in MTAs wrt Reply-To.
> 
> No! Reply-To is what you should use if you want to send a personal reply
> to the author of, the original message (which indeed you sometimes need to
> do if, for example, your reply is too complex/personal/whatever for
> sending to thje complete list).

No, the semantics of the Reply-To field is NOT "personal reply", it is
"where the author(s) suggested".  Nor is the semantics "the author"; that
would be the From field.  A response to the author(s) intentionally
disregarding the authors' suggestion would go to the mailboxes in the
original message From field, and that is precisely what several UAs
which provide separate "Reply to Author" functions do. 

> Therefore, it is evident that some further Reply-to-like header (MFT, MCT
> or something new) is needed for use with the "Reply-to-List" command

Several UAs implement a "Reply to List" function without such a header
field; evidently there is no such "need".
Permalink | Reply | 11 comments |
headers
Keith Moore | 6 Jun 20:58
Picon

*Reply-to* considered harmful (was Re: Understanding response protocols)


> No! Reply-To is what you should use if you want to send a personal reply
> to the author of, the original message (which indeed you sometimes need to
> do if, for example, your reply is too complex/personal/whatever for
> sending to thje complete list).

That is completely incorrect.

"From" contains the author (or authors) of the original message.  If you 
want your reply to go to the author(s) of the original message, you need 
to send your message to the addresses in the From field.  As at least
one example in RFC 822 makes clear, it is not reasonable to assume that
sending to addresses in the Reply-To field will reach the author(s) of 
the original message.

> Therefore, it is evident that some further Reply-to-like header (MFT, MCT
> or something new) is needed for use with the "Reply-to-List" command (or
> Reply-to-All if Reply-to-list is not provided).

No, it doesn't follow - both because your premise is incorrect, and because
the absence of a field specifically intended for group replies is not an indicator
that some additional field is needed.  

Rather, the whole assumption that the author of a message should be able to
change the behavior of a recipient's user agent is very much in doubt.  Even
in the case of a single recipient message the behavior of Reply in the presence
of a Reply-To field is too often surprising for the responder.   It only becomes 
more surprising in the presence of additional recipients, reply to author /
reply to all choices, mailing lists, and/or multiple fields indicating how to reply -
_no matter how those new fields are defined_.
(Continue reading)

Permalink | Reply | 6 comments |
headers
Bruce Lilly | 6 Jun 21:21
Picon

Re: Folding of long lines in message bodies


On Mon May 30 2005 14:30, Charles Lindsey wrote:
> And if implemented correctly, it should not result
> in extremely long lines

And yet it does.  See
http://www.imc.org/ietf-smime/mail-archive/msg01961.html
for example.

The distinguishing characteristic of such messages (absent
from Jacob's original in this thread) is that an entire
paragraph of text is contained in a single message line as
described in section 3.1 of RFC 3676.
Permalink | Reply | 14 comments |
headers
Bruce Lilly | 6 Jun 21:48
Picon

Confusing UAs considered harmful (was *Reply-to* considered harmful)


On Mon June 6 2005 14:58, Keith Moore wrote:

> Rather, the whole assumption that the author of a message should be able to
> change the behavior of a recipient's user agent is very much in doubt.

That's emphatically NOT the assumption behind the Reply-To field semantics.
"suggestion" != "change the behavior"

It appears to be the assumption behind "Mail-Followup-To", but then that's
not an official message header field and is implemented differently by
the few UAs that pay any attention to it.

Some UAs may in fact change behavior; blame the UAs and/or their authors
if you wish, don't blame the field.  Maybe blame RFC 724/822 authors for
the "If there is" sentences (absent from RFCs 733/2822).

[more complaints about particular types of UAs elided]

> The only way to make Reply work better is to improve the user interfaces
> of mail user agents so that recipients of messages are more easily able to 
> explicitly choose where their replies go.

Agreed.  Maybe UAs, when instructed to respond, should start with "Where
do you want your message to go today?" :-)

> To the [extent?] new fields can help 
> this process, they can only do so by providing more information to a recipient
> to inform that choice.
(Continue reading)

Permalink | Reply | 2 comments |

Gmane