Re: Replying to the list (was: [1003.1(2016)/Issue7+TC2 0001138]: Add strsignal(), sig2str() and str2sig() to the standard.)
Date:Thu, 10 Sep 2020 09:32:03 +0100 From:"Geoff Clare via austin-group-l at The Open Group" Message-ID: <20200910083203.GA29472@localhost> | You read it again. You are ignoring the last sentence. No, I am not. | Yes. The last sentence. It clearly implies that the address in the | "From:" field is the address that "Reply-To:" overrides. It does not. It says what to do if there is no Reply-To field, and has no bearing at all if there is. I know - I was involved in writing that text when it appeared first in rfc2822 ... correctly handling Reply-To has always been one of my hobby horses (ever since Dave Crocker explained it to me when I asked him long ago ... the text in rfc822 was not very informative at all). We cannot say where the client must send replies, as, as we both agree, that's ultimately up to the person sending the reply. But we can say what the Reply-To field means, and that is what that test says. It is not an override of the From field, it "indicates the address(es) to which the author of the message suggests that replies be sent." The current config of the austin-list mailer is perverting that use. Some lists (absent an author supplied Reply-To field) add a Reply-To directing replies to only the list, as many list members prefer things that way (not all mailers do good duplicate filtration, so if many people get a private reply, and the same reply via the list, they actually see both (and for some reason, that irritates many people). That's not exactly perfect, but it is at least reasonable, and understandable. Adding a Reply-To field with what ought to be in the From field is simply insane. | Of course. Who else to send a reply to is the choice of the person | sending the reply. Which is why almost all email clients provide | separate "reply" and "reply all" functions. I know - a very limited approach. I have lots of options on where I send replies, far more than just those two. The question is where should a normal reply be sent, the one that is used all the time when there is no reason to override. That's what matters here, as that is the one that is used by default (the one I automatically pick when I want to send any normal e-mail reply). I have (recently) here normally been using my "reply to everyone" variant, which is more than a typical Reply-All as it includes every address it can find in any source/recipient field in the header of the message, then I just go and delete the inappropriate ones. I also have "reply to author" "reply to sender" (there are occasionally times when that is appropriate) and "reply to significant addrs" (Reply-To if there is one, otherwise >From + To, but not cc). There are many combinations that might be useful to recipients, users should be able to tailor this to suit their needs, just having "reply" and "reply all" is limiting. If the message includes the mailing list headers (why are those not added for austin-list messages) then I also see "subscribe"/"unsubscribe" and "reply to list" if those addresses are given, which they ought to be. | It is the almost universally adopted convention. You need to accept | that and move on. Sorry, that I refuse to do. | Also, it in no way reduces the functionality of email. It isn't the reply sending that loses functionality, it is the act of sending a message and indicating (in a way that can be automated, rather than text in the message) to which addresses you would like replies to be sent. For example, in this message, I am including a Reply-To header like this Reply-To: Robert Elz , Andrew Josey so that if you choose to continue this debate, we can stop bothering the whole list with this issue that has nothing at all to do with the objectives of the list, but just mailing list management. But I bet it will be deleted by the mailing list software, and replaced by something differentYou should still see it in the copy of this message sent to you directly though. If included in the message you actually see, I assume that your mailer's normal action, when you use it in the normal way you would reply to any other message sent to the list, would be to include the list anyway, ignoring my request. You may choose then to go edit the header, and delete the extra address(es) but why should you be required to take that step, when this can trivially easily be automated. I know, that's how it works for me. | I used the word "offered" above and in an earlier email for a reason. | The way this is usually handled is that the different reply functions | pre-populate the To and Cc fields with the "offered" addresses. | The person composing the reply can then alter them before sending. Of course, but when all I desire to do is reply to wherever the reply should go, and particularly when I'm replying quickly, I usually don't even look at the header of my reply. Why should I have to? When I am
Re: Replying to the list (was: [1003.1(2016)/Issue7+TC2 0001138]: Add strsignal(), sig2str() and str2sig() to the standard.)
Robert Elz wrote, on 10 Sep 2020: > > | The Reply-To header is used to indicate where the author prefers to > | have replies sent *instead of the address in the From header*. > > From where do you obtain that idea? > > What RFC5322 says on this is: > >The originator fields also provide the information required when >replying to a message. When the "Reply-To:" field is present, it >indicates the address(es) to which the author of the message suggests >that replies be sent. In the absence of the "Reply-To:" field, >replies SHOULD by default be sent to the mailbox(es) specified in the >"From:" field unless otherwise specified by the person composing the >reply. > > Read again: "it indicates the address(es) to which the author of the > message suggests that replies be sent." > You read it again. You are ignoring the last sentence. > Do you see anything there which mentions anything about "instead of > the address in the From header"? Yes. The last sentence. It clearly implies that the address in the "From:" field is the address that "Reply-To:" overrides. > Nor does it say anywhere anything about adding more addresses from > other fields to what the author of the message to which we're replying > suggested - though of course, since the message I am sending (the reply) > is my message, I can direct it anywhere I like Of course. Who else to send a reply to is the choice of the person sending the reply. Which is why almost all email clients provide separate "reply" and "reply all" functions. (In the POSIX standard mailx client, these functions are provided by the "reply" and "Reply" commands.) > I'll admit that the "Reply-To is a replacement for From" is a very > widely held misconception - but it is wrong, and severly reduces the > functionality of e-mail. It is the almost universally adopted convention. You need to accept that and move on. Also, it in no way reduces the functionality of email. It provides easy access to the two most frequently desired types of reply. Modifications to the offered address can be made before the email is sent. An email client that only has one reply function only provides easy access to one of the two most frequently desired types of reply. > [...] how is someone to send a message to > you, and visibly (as in explicitly, no bcc type stuff) send a copy > to their boss, so she knows that the sender is dealing with the > issue as directed, but request replies not be sent to (and so bother) > her? On the other hand, your reply should include the sender's > colleague (also cc'd in the message) who is working with the sender > on solving your problem. I used the word "offered" above and in an earlier email for a reason. The way this is usually handled is that the different reply functions pre-populate the To and Cc fields with the "offered" addresses. The person composing the reply can then alter them before sending. > With your (limited) client, [...] My email client (mutt) is just about as unlimited as it is possible for an email client to be. Configured the way I have it, it includes (selected fields from) the header, pre-populated according to which reply function I used, in the file that is loaded into my chosen text editor for me to compose the reply. I have complete control over the contents of those fields (and can add others if I choose to). -- Geoff Clare The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
Re: Replying to the list (was: [1003.1(2016)/Issue7+TC2 0001138]: Add strsignal(), sig2str() and str2sig() to the standard.)
Geoff Clare via austin-group-l at The Open Group wrote in <20200909161256.GA15692@localhost>: |Robert Elz wrote, on 09 Sep 2020: |> |> And thanks for the tutorial on how to use e-mail - but my e-mail client |> doesn't have a "reply all" function, I don't want it to, the notion of |> just "reply" vs "reply all" is absurdly simplistic. What I have \ |> is "reply" |> which by default replies to the Reply-To if there is one, otherwise the |> From+To+Cc list (more or less the equivalent of what you consider to be |> "Reply All" I assume). | |There's your problem right there. You are using an email client that |is not fit for purpose. Hihihi. But at least his mailer is scriptable to the core! And i would throw in and say that DMARC is to blame. And maybe it is because so many mostly graphical and web-based mail clients do not truly support "attachments" (aka MIME parts) nicely. We have two distinct standardized approaches for signed data (S/MIME and multipart/encrypted plus multipart/signed), and DMARC could very well just have created a MIME multipart/signed from the DKIM signed data, or just any other multipart type (/mixed mostly), where the original data resides. But that cannot simply be done on the island that a single RFC is, so that simply injects yet another header into the main header block, and does not care for the very important and decades old part of the email infrastructure that mailing-lists are. But the job is done. For the MUA i maintain i have implemented and use a "set reply-to-swap-in=mlist" approach, where "mlist" states that the action shall be performed when "the thread happens on something configured as a mailing-list" (mlist and mlsubscribe commands here), and it works somewhat, but it is nothing but a gross hack to at least address the real person in From:. It does not (yet) cover the introductional reply reference. |> That's the way it should work - the Reply-To field |> is the one you are supposed to use to suggest to me where you prefer \ |> to have |> replies sent | |The part after the "-" is (partially) correct. However, it in no way |implies that email clients should behave the way yours does. | |The Reply-To header is used to indicate where the author prefers to |have replies sent *instead of the address in the From header*. Yes. _Instead_. I always have to look. It is a misuse by DMARC. |Therefore when replying (using whichever of the reply functions the email |client provides) the only difference that the presence of Reply-To should |have is that the reply address(es) the client offers contain the Reply-To |address(es) in place of the From address. All other addresses (if any) |taken from other headers should be the same. Using the presence of |Reply-To to decide whether or not to include To+CC is just plain broken. That is not how it usually works, or? Isn't Reply-To: used as an exclusive replacement of all the addressees, unless i am mistaken? RFC 5322 explicitly states Note: Some mail applications have automatic reply commands that include the destination addresses of the original message in the destination addresses of the reply. How those reply commands behave is implementation dependent and is beyond the scope of this document. In particular, whether or not to include the original destination addresses when the original message had a "Reply-To:" field is not addressed here. and if i recall correctly presence and usage of Reply-To: caused replacement of all addressees with that address(es)? I have definitely seen Reply-To: used like that, likely because Mail-Followup-To: never became standardized. Having said that, i think the behaviour of the MUA i maintain is no good, and i think i will treat your statement as a suggestion and implement it like that. --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
Re: Replying to the list (was: [1003.1(2016)/Issue7+TC2 0001138]: Add strsignal(), sig2str() and str2sig() to the standard.)
Date:Wed, 9 Sep 2020 17:12:56 +0100 From:"Geoff Clare via austin-group-l at The Open Group" Message-ID: <20200909161256.GA15692@localhost> | There's your problem right there. You are using an email client that | is not fit for purpose. While it might (well, does) have problems, this is not one of them. | The Reply-To header is used to indicate where the author prefers to | have replies sent *instead of the address in the From header*. >From where do you obtain that idea? What RFC5322 says on this is: The originator fields also provide the information required when replying to a message. When the "Reply-To:" field is present, it indicates the address(es) to which the author of the message suggests that replies be sent. In the absence of the "Reply-To:" field, replies SHOULD by default be sent to the mailbox(es) specified in the "From:" field unless otherwise specified by the person composing the reply. Read again: "it indicates the address(es) to which the author of the message suggests that replies be sent." Do you see anything there which mentions anything about "instead of the address in the From header"?(It would say field, not header, an e-mail message has one header (and an optional body), the header is composed of several fields, the From: To: Cc: ... are fields, not "headers" though that incorrect terminology is frequently used - I do it myself, much too often, unfortunately). Nor does it say anywhere anything about adding more addresses from other fields to what the author of the message to which we're replying suggested - though of course, since the message I am sending (the reply) is my message, I can direct it anywhere I like - I don't need to include any addresses that appeared anywhere in the header of the original message - and when all that contains is noreply@whatever in the From field, and my addr in the To field, that's often the necessary thing to do. I'll admit that the "Reply-To is a replacement for From" is a very widely held misconception - but it is wrong, and severly reduces the functionality of e-mail. The rest of your message uses that error as its underlying assumption, so needs no further comment. It is simply wrong. Note: there is nothing wrong with an e-mail client providing various different reply functions, that pick different sets of addresses for you to use, instead of the default - but the "normal" reply in the presence of a Reply-To field, that is when you're not deliberately deciding to ignore the suggestion from the author of the original message when given, should always be to reply to, and only to, the addresses in the Reply-To field. If you don't act that way, then how is someone to send a message to you, and visibly (as in explicitly, no bcc type stuff) send a copy to their boss, so she knows that the sender is dealing with the issue as directed, but request replies not be sent to (and so bother) her? On the other hand, your reply should include the sender's colleague (also cc'd in the message) who is working with the sender on solving your problem. With your (limited) client, your choices are Reply (just to the sender, omitting the colleague) or Reply-All, wich will go to everyone, including the boss. If you simply did what the Reply-to field asked, you'd be sending to the (in this case) 2 addresses that would be listed there, and no others.Much more complicated scenarios are possible - and in all of them, by default, using the properly constructed Reply-To as the target list for the reply makes things work, doing anything else usually fails. kre
Re: Replying to the list (was: [1003.1(2016)/Issue7+TC2 0001138]: Add strsignal(), sig2str() and str2sig() to the standard.)
Robert Elz wrote, on 09 Sep 2020: > > And thanks for the tutorial on how to use e-mail - but my e-mail client > doesn't have a "reply all" function, I don't want it to, the notion of > just "reply" vs "reply all" is absurdly simplistic. What I have is "reply" > which by default replies to the Reply-To if there is one, otherwise the > From+To+Cc list (more or less the equivalent of what you consider to be > "Reply All" I assume). There's your problem right there. You are using an email client that is not fit for purpose. > That's the way it should work - the Reply-To field > is the one you are supposed to use to suggest to me where you prefer to have > replies sent The part after the "-" is (partially) correct. However, it in no way implies that email clients should behave the way yours does. The Reply-To header is used to indicate where the author prefers to have replies sent *instead of the address in the From header*. Therefore when replying (using whichever of the reply functions the email client provides) the only difference that the presence of Reply-To should have is that the reply address(es) the client offers contain the Reply-To address(es) in place of the From address. All other addresses (if any) taken from other headers should be the same. Using the presence of Reply-To to decide whether or not to include To+CC is just plain broken. -- Geoff Clare The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
Re: Replying to the list (was: [1003.1(2016)/Issue7+TC2 0001138]: Add strsignal(), sig2str() and str2sig() to the standard.)
austin-group-l@opengroup.org said: | Replies should work the same way they used to[*]. If you use your email | client's "reply all" function First, see how that citation of your message looks when I don't go and manually fix it, that's because the address used is that from the From: field - which is who sent the message (who authorised it to be sent, usually but not always the same person).Or that is the way it is intended to work. And thanks for the tutorial on how to use e-mail - but my e-mail client doesn't have a "reply all" function, I don't want it to, the notion of just "reply" vs "reply all" is absurdly simplistic. What I have is "reply" which by default replies to the Reply-To if there is one, otherwise the From+To+Cc list (more or less the equivalent of what you consider to be "Reply All" I assume). That's the way it should work - the Reply-To field is the one you are supposed to use to suggest to me where you prefer to have replies sent (as in, just send to the list, I will get a copy that way", or "send to me and the list, as I'm not on this list", or "reply just to me, if anyone else indicates an interest in my bizarre problem, I'll summarise replies once I have a solution" -- or "send replies to me and my supervisor", or various other possibilities) - all managed by placing the list of desired addresses in the Reply-To header, before you send the message. My e-mail client is set up (properly) to respect that request by default. Once the default list of addresses has been established, I then get to modify it as I see fit (after all, the reply is a message I am sending, I get ultimate control over to whom my message is sent) - I can add or delete addresses from what was established by default. When I think it is likely to be necessary to do that (sometimes when the sender of the message isn't e-mail sophisticated, or is stuck behind a crappy interface which doesn't allow the header fields to be set as desired) I do it, but I don't usually when replying to messages on lists - normally those "just work" adequately - if the sender set a Reply-To header, then they're asking for a particular reply strategy, and unless I have a very good reason, I comply with their request.That is, until this nonsense started - now this list (and one or two others which adopted the same strategy - perhaps because they're using the same list software) I have to remember to adjust the destination address fields for every reply I send, as the default is almost never what the sender requested, but instead this noise from the list. austin-group-l@opengroup.org said: | This DKIM/DMARC mail message header mixing approach always makes me nervous That was really stef...@sdaoden.eu who said that, but again, the From field, which indicates that (or should) has been perverted. I suppose I could have it include the entire From field, so the citation would have been "Steffen Nurpmeso via austin-group-l at The Open Group" said: | This DKIM/DMARC mail message header mixing approach always makes me nervous but that gets kind of overbearing, and what's more, misstates what Steffen's e-mail address is. I could just use the "human name" part (which in this case would still be annoying) but I prefer to use the e-mail addr, as that is something others can use to communicate, just the human part can be informative, but is otherwise useless. The way it is done is totally broken - it could have been much simpler, e-mail has all the header fields required for this. The Sender field is exactly on point - it indicates the origin of the message, should that not be the From: field (which is really on whose behalf the message was sent). For a list like this, setting the Sender to be the list address would make sense - as it is the list doing the sending to all of the recipients, as requested (authorised) by the person who authorised (and usually) sent the message to the list (the From field). Then the From and Reply-To fields could be left alone. Of course, to be useful, that would require Google (et al) actually doing what the e-mail standards say they should do, and basing their test for "did this e-mail originate at an authorised sending host" based upon the Sender field if there is one (and From if there is not - Sender is not included if it would be identical to From). I kind of doubt that they do that - and they certainly never will if everyone simply caves in to their broken requirements, severely limiting the functionality of e-mail in the process. kre
Re: Replying to the list (was: [1003.1(2016)/Issue7+TC2 0001138]: Add strsignal(), sig2str() and str2sig() to the standard.)
Geoff Clare via austin-group-l at The Open Group wrote in <20200909093026.GA21859@localhost>: |Robert Elz wrote, on 09 Sep 2020: |> ps: this new e-mail encapsulation is still inserting bogus Reply-To \ |> headers |> that request replies go only to the sender of the message ... one of the |> messages I sent you (Geoff) earlier (I have forgotten what it was about) |> was actually intended for the list, but I forgot that I needed to go |> manually add the list name. | |Replies should work the same way they used to[*]. If you use your |email client's "reply all" function the reply is to the list and to |the sender (and Cc's). If you use "reply", the reply is only to the This DKIM/DMARC mail message header mixing approach always makes me nervous. It is ok for me since Reply-To: is in the list of retained headers and so i see it. But otherwise a different address magically springs into existence, and i always have to look twice to assure myself. |sender. So if you accidentally sent a private email that was meant for |the list, the same would have happened before the change was made to |the mailing list configuration. | |[*] One small difference is that some email clients ask whether to |honour the Reply-To (e.g. mutt). One nit: ..some email clients optionally ask.. (The mailx clone i maintain needs "set reply-to-honour[=ask-yes here]", for example.) --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
