Re: mailx R and r commands (was: Replying to the list)
Geoff Clare wrote, on 14 Sep 2020: > > Mark Harris wrote, on 12 Sep 2020: > > > > > | Solaris uses "Reply-To:" to replace just "From:" > > > | (although it has "R" and "r" the wrong way round!) > > > > This is controlled by the POSIX-standard mailx variable "flipr". It > > can be set system-wide (/etc/mail.rc) or per-user ($HOME/.mailrc). > > My first thought when I saw what Solaris did was that perhaps flipr > had been set somehow. But I did a "set flipr" and then it behaved the > way the standard requires (for flipr unset). So it definitely has them > the wrong way round. For the record, I subsequently found the place in the man page that describes how to obtain conforming behaviour. There is a non-standard "replyall" command that is set internally by mailx on startup and is then (in the default configuration) unset by /etc/mail/mailx.rc - doing it this way means "mailx -n" conforms. To get conforming behaviour when not using -n, either /etc/mail/mailx.rc can be edited to remove the "unset replyall", or individual users can put "set replyall" in their MAILRC file. -- Geoff Clare The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
Re: mailx R and r commands (was: Replying to the list)
Hello. This was vivious, it ends up as Cc: The, POSIX, maintainers:, ;, Robert Elz upon reply time here. That is what happens if you join and split and join and split from strings to (address) objects and way back, loosing all the information along the way. It also came in as an empty "LIST: ;" here, in fact i looked into the archive, luckily, as i thought you addressed only me, but not true, it is in there. Robert Elz wrote in <26171.1600188...@jinx.noi.kre.to>: |Date:Tue, 15 Sep 2020 15:37:31 +0200 |From:Steffen Nurpmeso |Message-ID: <20200915133731.cpghp%stef...@sdaoden.eu> | |Quoting RFC822: || the presence of the "Reply-to" field SUPERSEDES the sending || of a reply to the person named in the "From" field. | |I suspect that this is where the "reply-to is a replacement for From" |idea originated - it kind of reads like that, but that is never what |it meant. All that was saying is that when there is a Reply-To the |>From field is not (by default anyway) used in the reply. It just doesn't |explicitly say that the Reply-To contents are supposed to be the entire \ |list |of addresses to use for the reply, but that is the only thing that really |makes sense (the author can add as many addresses as they want to the |Reply-To, if they want addresses from the To or Cc added, they can be |included - but if the replier includes all those addresses automatically, |there's no way left for the author in the header to say not to do that. All i was saying, and that is plain, is that i have seen use cases where Reply-To: was used as a full replacement. And not only mailing-lists adding their own address to a yet existing Reply-To:. || makes me realize that the BSD Mail codebase and my fork still do not || support the group address list syntax shown here. | |This is one I wouldn't lose any sleep over, while useful sometimes, |its use normally appears when the addresses in the group are elided, |so what the recipient receives is something like | | To: The Committee: ; | |in which case there is simply nothing to use. Using the group syntax |when the addresses are listed adds very little of any value, so in practice |no-one ever does that. (It has always been supported in MH though). And we will support it at some later time. |In any case, this isn't something that we need be concerned with here. Sure. || So this is why DMARC and the way mailman deals with the things || destroy the infrastructure, | |Agreed. | || and this is why i hate them. Why not, let's just hate them, | |I'd also ignore them - that is, simply refuse to pander to that nonsense. |Anyone who wants to participate ought to be able to find a rational e-mail |system to use. So i happily change behaviour of the thing i maintain back to original BSD behaviour. Of course. And all use cases where the never standardized Mail-Followup-To: is realized by placing anything in Reply-To: possibly needs manual adjustment then, if at all. Good night, --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: mailx R and r commands (was: Replying to the list)
Date:Tue, 15 Sep 2020 15:37:31 +0200 From:Steffen Nurpmeso Message-ID: <20200915133731.cpghp%stef...@sdaoden.eu> Quoting RFC822: | the presence of the "Reply-to" field SUPERSEDES the sending | of a reply to the person named in the "From" field. I suspect that this is where the "reply-to is a replacement for From" idea originated - it kind of reads like that, but that is never what it meant. All that was saying is that when there is a Reply-To the >From field is not (by default anyway) used in the reply. It just doesn't explicitly say that the Reply-To contents are supposed to be the entire list of addresses to use for the reply, but that is the only thing that really makes sense (the author can add as many addresses as they want to the Reply-To, if they want addresses from the To or Cc added, they can be included - but if the replier includes all those addresses automatically, there's no way left for the author in the header to say not to do that. | makes me realize that the BSD Mail codebase and my fork still do not | support the group address list syntax shown here. This is one I wouldn't lose any sleep over, while useful sometimes, its use normally appears when the addresses in the group are elided, so what the recipient receives is something like To: The Committee: ; in which case there is simply nothing to use. Using the group syntax when the addresses are listed adds very little of any value, so in practice no-one ever does that. (It has always been supported in MH though). In any case, this isn't something that we need be concerned with here. | So this is why DMARC and the way mailman deals with the things | destroy the infrastructure, Agreed. | and this is why i hate them. Why not, let's just hate them, I'd also ignore them - that is, simply refuse to pander to that nonsense. Anyone who wants to participate ought to be able to find a rational e-mail system to use. kre
Re: mailx R and r commands (was: Replying to the list)
Robert Elz wrote in <21450.1600163...@jinx.noi.kre.to>: |Date:Mon, 14 Sep 2020 23:09:21 +0200 |From:"Steffen Nurpmeso via austin-group-l at The Open Group" \ | |Message-ID: <20200914210921.h1m8r%stef...@sdaoden.eu> | || This is of course very primitive handling and does not take care || for RFC 2822, no Sender: handling, etc. | |That it didn't take 2822 into account, in 199x (for any x) is hardly |surprising, as 2822 didn't appear until 2001 (though it was being worked |on for a few years before that - not as early as '96 though I don't think). Yes, of course, Robert. |RFC822 was not nearly as clear, and while 2822 wasn't really intended to |change anything in this area, just clarify it (unlike other stuff where |lots was made obsolete, and a few new things added, to match what people |were actually doing with mail at the time) it is understandable that e-mail |MUA authors (the very few of them who ever read RFC822, or even knew it |existed ... most seemed to code by guesswork) might have not gotten things |exactly right. RFC 822 is one of the wonderful old style RFCs, for example it says George Jones logs in as Jones on his host. His secre- tary, who logs in as Secy sends mail for him. Replies to the mail should go to George. From:George Jones Sender: Secy@Other-Group as well as George is a member of a committee. He wishes to have any replies to his message go to all committee members. From: George Jones Sender: Jones@Host Reply-To: The Committee: jo...@host.net, sm...@other.org, Doe@Somewhere-Else; Note that if George had not included himself in the enumeration of The Committee, he would not have gotten an implicit reply; the presence of the "Reply-to" field SUPER- SEDES the sending of a reply to the person named in the "From" field. which unfortunately contradicts how BSD Mail and Unix mail work on `reply' time, no, and then makes me realize that the BSD Mail codebase and my fork still do not support the group address list syntax shown here. RFC 5322 which POSIX now mentions says [.] The "Sender:" field specifies the mailbox of the agent responsible for the actual transmission of the message. For example, if a secretary were to send a message for another person, the mailbox of the secretary would appear in the "Sender:" field and the mailbox of the actual author would appear in the "From:" field. If the originator of the message can be indicated by a single mailbox and the author and transmitter are identical, the "Sender:" field SHOULD NOT be used. Otherwise, both fields SHOULD appear. which is the sucked mellow professional way of saying the same thing i'd say. Note: The transmitter information is always present. The absence of the "Sender:" field is sometimes mistakenly taken to mean that the agent responsible for transmission of the message has not been specified. This absence merely means that the transmitter is identical to the author and is therefore not redundantly placed into the "Sender:" field. 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. In all cases, the "From:" field SHOULD NOT contain any mailbox that does not belong to the author(s) of the message. See also section 3.6.3 for more information on forming the destination addresses for a reply. So this is why DMARC and the way mailman deals with the things destroy the infrastructure, and this is why i hate them. Why not, let's just hate them, i do not know what these tanks had in mind, really. |And except in extraordinary circumstances (and Mail having just 2 reply |variants doesn't have enough to ever get there) Sender isn't supposed to |be used (in almost any way at all) - certainly not in your average reply. The BSD Mail clone i maintain (mis)uses Sender: by requiring a *sender* variable to be set when From: (*from*) is set to multiple addresses, aka by using these message members in the same way. I was sure this had historical precedence. |A really good MUA might have a "reply to sender" (though it might be |phrased differently so people don't just assume "sender" means the address |in the From field) as it can occasionally be useful, as in a "Did you \ |really |intend to send that message to me?" reply, which is one kind of reply |where
Re: mailx R and r commands (was: Replying to the list)
Date:Mon, 14 Sep 2020 23:09:21 +0200 From:"Steffen Nurpmeso via austin-group-l at The Open Group" Message-ID: <20200914210921.h1m8r%stef...@sdaoden.eu> | This is of course very primitive handling and does not take care | for RFC 2822, no Sender: handling, etc. That it didn't take 2822 into account, in 199x (for any x) is hardly surprising, as 2822 didn't appear until 2001 (though it was being worked on for a few years before that - not as early as '96 though I don't think). RFC822 was not nearly as clear, and while 2822 wasn't really intended to change anything in this area, just clarify it (unlike other stuff where lots was made obsolete, and a few new things added, to match what people were actually doing with mail at the time) it is understandable that e-mail MUA authors (the very few of them who ever read RFC822, or even knew it existed ... most seemed to code by guesswork) might have not gotten things exactly right. And except in extraordinary circumstances (and Mail having just 2 reply variants doesn't have enough to ever get there) Sender isn't supposed to be used (in almost any way at all) - certainly not in your average reply. A really good MUA might have a "reply to sender" (though it might be phrased differently so people don't just assume "sender" means the address in the From field) as it can occasionally be useful, as in a "Did you really intend to send that message to me?" reply, which is one kind of reply where sending to the addr in the Sender: field (if there isn't one, From: is used) is appropriate, another might be "you typo'd fred's address, you should send another copy to the correct one" (just in case the bounce message didn't get seen). With all of this we're also ignoring anything that we might want to be able to do with the Resent-* fields, which are also not normally used by typical replies, but sometimes can be the right thing to use. But as long as we're confining ourselves to what mailx's 'r' and 'R' commands should do, both Sender and Resent-* are irrelevant. kre ps: Sorry Steffen, I know you're going to see this twice (or perhaps 3 times - but certainly twice) - I forgot this list's obnoxious Reply-To (again!). This time I still had the draft file when I realised though, so this resend includes the list.
Re: mailx R and r commands (was: Replying to the list)
Geoff Clare wrote in
<20200914090031.GB11999@localhost>:
|Robert Elz wrote, on 12 Sep 2020:
|>
|> How you can manage to reconcile this in the standard, more precisely
|> that saying "the r and R commands reply to the current message, using
|> different, but otherwise unspecified, addresses obtained from the header
|> of the current message" (in better prose than that, one would hope), I
|> don't know, and that's not very useful to anyone.
|
|Perhaps one way forward would be to require that mailx can be
|configured so that "R" and "r" behave in a particular way, but that
|it need not be the default configuration.
|
|While reading through the various responses, I also realised that
|there is a fourth problem to add to the list I originally gave.
|(I forget who's response made me think of it, but for convenience
|I'll just put the details here. Apologies for not giving credit
|where due.)
|
|As stated before, the description of "r" says the reply is sent
|to "all recipients included in the header of the message". The
|fourth problem is:
|
|4. "r" is required NOT to send the reply to the author/sender of the
|message, but only to its (known) recipients. (So the author/sender
|will only get the reply if they were included in "To:" or "Cc:".)
An editorial error that reveals deficits in they way human brains
scan text. That is what i thought first. (I never recognized
this "oddity".)
On a second glance this could be thirty and more years old, as
Tenth Edition Research Unix (1991; i think in effect this was UPAS
then, i would presume? It also has a V9 preprocessor block which
uses "UPAS-envelopes", Fromname()) and 3BSD Mail (March 1980; not
newer ones!) did not look out for the From: (let alone Sender:) at
all, like (showing BSD because of further comments below)
if ((replyto = skin(hfield("reply-to", mp))) != NOSTR)
np = extract(replyto, GTO);
else if ((cp = skin(hfield("to", mp))) != NOSTR)
np = extract(cp, GTO);
else
np = NIL;
BSD Mail 8.1 (.. .1, anyhow from 1996-06-14) then prepends
if ((rcv = skin(hfield("from", mp))) == NOSTR)
rcv = skin(nameof(mp, 1));
to the above and then does a dance
... remove all alternates etc. from "np"
if (np != NIL && replyto == NOSTR)
if anything real to address remains and we did not see Reply-To:
np = cat(np, extract(rcv, GTO));
also address From:
else if (np == NIL) {
if (replyto != NOSTR)
printf("Empty reply-to field -- replying to author\n");
np = extract(rcv, GTO);
only address From:
}
head.h_to = np;
This is of course very primitive handling and does not take care
for RFC 2822, no Sender: handling, etc.
--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: mailx R and r commands (was: Replying to the list)
Mark Harris wrote, on 12 Sep 2020: > > > | Solaris uses "Reply-To:" to replace just "From:" > > | (although it has "R" and "r" the wrong way round!) > > This is controlled by the POSIX-standard mailx variable "flipr". It > can be set system-wide (/etc/mail.rc) or per-user ($HOME/.mailrc). My first thought when I saw what Solaris did was that perhaps flipr had been set somehow. But I did a "set flipr" and then it behaved the way the standard requires (for flipr unset). So it definitely has them the wrong way round. -- Geoff Clare The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
Re: mailx R and r commands (was: Replying to the list)
Date:Sat, 12 Sep 2020 19:30:22 +0200 From:Steffen Nurpmeso Message-ID: <20200912173022.shnqc%stef...@sdaoden.eu> | I do not know how you can say this. (If it last your original | address entirely, where is the improvement?) It is at least now directing replies where I requested (not that other than for testing, I'd usually do that here). That the From is being mangled is still a big problem. kre ps: it is so much nicer to be able to reply to a message that arrived directly, sender to me, rather than a copy via the list.
Re: mailx R and r commands (was: Replying to the list)
Robert Elz via austin-group-l at The Open Group wrote in <12525.1599844...@jinx.noi.kre.to>: |Date:Fri, 11 Sep 2020 15:59:26 +0100 |From:"Geoff Clare via austin-group-l at The Open Group" \ | |Message-ID: <20200911145926.GA7856@localhost> ... || rfc2822 itself says much the same thing later on. In 3.6.3 after it || describes how the destination fields should be set when creating a || reply, it says this: || || 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. | |Exactly, what MUAs do with things is not the IETF's bailiwick. | || In particular, whether or not to include the original destination || addresses when the original message had a "Reply-To:" field is not || addressed here. | |As that is a quality of implementation issue. | |Note that my original postscript on the message about issue 1138, where I |mentioned this issue, wasn't about how any MUA handles any mail header \ |fields, |when generating replies, it was about how the mailing list generates |a Reply-To (and mangles the From) field where that Reply-To field is not |indicating the sender's desires as to where replies should be sent. That |is the problem I was pointing out, not what any particular MUA might do |with it. Yeah. ... || S-nail uses "Reply-To:" to replace just "From:" (although, unlike the || others, it puts the recipients from "To:" into "Cc:"). | |That's another issue which isn't easy to decide - the distinction between |To and Cc has been largely ignored by all mail software, as there's no |rational way to automate it, and it makes no difference at all to e-mail |transmission or delivery - just how the recipients interpret the message |which can depend upon which header they see themselves on. Eg: I \ |very rarely |reply to (non-list) messages I'm on the cc list of, my assumption is \ |that I was |included just as a courtesy, whereas if I am on the To list, and a reply is |appropriate, I usually send one. It is configurable, but on with the default system-wide .mailrc (which is not used by all packagers), since you are addressing someone's message, and not the former addressees. You can turn it off. ... || but for "r" it uses "Reply-To:" as replacement for all recipients. | |That's also the right thing to do, interpreting Reply-To correctly for |the common generic reply command. I agree with that. ... |Not sure what the FreeBSD/OpenBSD versions do, but this seems to be just |the same as the MacOS version, and the ideal defaults, to me. | |How you can manage to reconcile this in the standard, more precisely |that saying "the r and R commands reply to the current message, using |different, but otherwise unspecified, addresses obtained from the header |of the current message" (in better prose than that, one would hope), I |don't know, and that's not very useful to anyone. | || P.S. I know I said I would trim all the offtopic stuff, but I just || want to make one small exception: ||> But I bet it will be deleted by the mailing list software, and ||> replaced by something different || It wasn't. | |Yes, I saw... that's a definite improvement over what was there before, |when I first tested that soon after this new way of doing list processing |was enabled, it didn't work like that. I do not know how you can say this. (If it last your original address entirely, where is the improvement?) --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: mailx R and r commands (was: Replying to the list)
Geoff Clare via austin-group-l at The Open Group wrote in <20200911145926.GA7856@localhost>: |Although Andrew asked us to take this to the offtopic list, I would |like instead to bring it back on topic, by making it about mailx. | |The descriptions of the "R" and "r" commands in mailx say that replies |are sent to the "sender" for "R" and to "all recipients included in |the header of the message" for "r". This has the following 3 problems: ... |All that matters for fixing the mailx description is what existing |mailx implementations do. | |Of the ones I tried, with "r": | |Solaris uses "Reply-To:" to replace just "From:" |(although it has "R" and "r" the wrong way round!) There is the flipr variable which can be used to exchange the meaning of these two, as has been said already. |The mailx from GNU mailutils uses "Reply-To:" to replace just "From:". | |S-nail uses "Reply-To:" to replace just "From:" (although, unlike the |others, it puts the recipients from "To:" into "Cc:"). This is all configurable and here most likely inherited from the default resource file (reply-to-honour=ask-yes, followup-to-honour=ask-yes, recipients-in-cc are default; the last is badly named, the original recipients are placed in Cc:, the direct addressee in To:, but things can be "much more complicated", since Reply-To: and Mail-Followup-To: can bring in addresses which were not in the original list of addressees, for example). Once i have looked into this part of the program i have compared the behaviour with the no#1 non-graphical MUA (you use it yourself), and went from there on. Of course configuration matters a lot. In particular we also have a special `Lreply' command which is meant for mailing-lists in particular, because even with lots of configuration options not anything fits in `r' and `R'. The behaviour is carved in stone in a test[1], but due to the many possible outcomes it may not be complete nor correct. Hm. [1] https://git.sdaoden.eu/cgit/s-nail.git/tree/mx-test.sh#n9410 Be warned you have been credited for an improvement of how deeply the variable reply-to-swap-in is honoured for the rest of a compose session. |> For example, in this message, I am including a Reply-To header |> like this |> |> Reply-To: Robert Elz , |> Andrew Josey |> |[...] |> |> But I bet it will be deleted by the mailing list software, and |> replaced by something different | |It wasn't. In my private copy not, but if even on the mailing-list copy then things are even worse. If it would at least keep the original address around somehow where it can easily be seen, for mailing- list archives for example, there Reply-To: is often not included. --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: mailx R and r commands (was: Replying to the list)
> | Solaris uses "Reply-To:" to replace just "From:" > | (although it has "R" and "r" the wrong way round!) > > The original BSD "Mail" did it that way, I have no idea when they > swapped cases, that is 'r' was a "small" reply, and "R" a "big" reply... > > But almost everyone uses "big" replies all the time, replying only to > the author is a less common thing to do, and R is harder to type than r, > so I guess somewhere along the way, someone switched them. > This is controlled by the POSIX-standard mailx variable "flipr". It can be set system-wide (/etc/mail.rc) or per-user ($HOME/.mailrc). Some of the history can be found in the POSIX rationale: "The meanings of r and R are reversed between System V mailx and SunOS Mail. Once again, since this volume of POSIX.1-2017 chose the mailx name, it kept the System V default, but allows the SunOS user to achieve the desired results using flipr, an internal variable in System V mailx, although it has not been documented in the SVID." - Mark
Re: mailx R and r commands (was: Replying to the list)
Date:Fri, 11 Sep 2020 15:59:26 +0100 From:"Geoff Clare via austin-group-l at The Open Group" Message-ID: <20200911145926.GA7856@localhost> | Although Andrew asked us to take this to the offtopic list, I would | like instead to bring it back on topic, by making it about mailx. I will reply (mostly) in kind... | 1. Using "sender" incorrectly implies that if a "Sender:" header field | is present it should be used instead of "From:". I would assume that it was using "sender" more generically, rather than referring to a specific field, but it certainly could be clarified. | 2. If the person replying is one of the "recipients included in the | header of the message", this text requires that the reply message is | sent to them, contradicting text elsewhere which says that this should | only be done if the metoo variable is set. That should be fixed. Probably by something like "Whether the reply sender's address is included, when it would seem to be required, or not to be added, depends upon ..." | 3. It requires that "Reply-To:" is ignored. As should that, though Reply-To is regarded as an originator field, and could be (part of) the "sender" as wrong as that is. The issue here really seems to be that "all recipients included in the header of the message" doesn't include the (generic) sender (who isn't necessarily a recipient, though can be) - and obviously should. | It does not contain an explicit statement either way, so your | interpretation and mine are both possible. You're looking at it backwards, concentrating upon how replies are supposed to be generated (which isn't really specified at all, other than that comment about where a reply SHOULD be sent if there is no Reply-To field present). The IETF don't care about that, that's not an interoperability issue, software can do whatever it likes, what matters is the interpretation of the fields, so one knows what they're for, and what data is appropriate to be included. For that, what's in the RFC is exactly right, Reply-To indicates the address(es) to which the author of the message containing it requests that recipients send replies. What the recipients do with it is up to them, what their MUA offers them as the default "reply" address list, and/or how much it permits modifications are all just quality of implementation issues. Here (the Austin List), however, what the (standard) MUA does with the various command it has - that is, what the users can rely upon happening, is an appropriate topic. | rfc2822 itself says much the same thing later on. In 3.6.3 after it | describes how the destination fields should be set when creating a | reply, it says this: | | 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. Exactly, what MUAs do with things is not the IETF's bailiwick. | In particular, whether or not to include the original destination | addresses when the original message had a "Reply-To:" field is not | addressed here. As that is a quality of implementation issue. Note that my original postscript on the message about issue 1138, where I mentioned this issue, wasn't about how any MUA handles any mail header fields, when generating replies, it was about how the mailing list generates a Reply-To (and mangles the From) field where that Reply-To field is not indicating the sender's desires as to where replies should be sent. That is the problem I was pointing out, not what any particular MUA might do with it. | Let that be an end to the discussion of how "Reply-To:" is (or was | originally) intended to be used and whether various email clients | are right or wrong to handle it the way they do. WRT the latter, yes, please, because there is no answer to that. But if you're going to discuss what the mailx (or Mail, or whatever POSIX calls it) command does by default with its "r" and "R" commands, then the first part of that might not be possible, as what Reply-To means has to be an issue when deciding how and when it should be used. | All that matters for fixing the mailx description is what existing | mailx implementations do. agreed. | Of the ones I tried, with "r": | | Solaris uses "Reply-To:" to replace just "From:" | (although it has "R" and "r" the wrong way round!) The original BSD "Mail" did it that way, I have no idea when they swapped cases, that is 'r' was a "small" reply, and "R" a "big" reply... But almost everyone uses "big" replies all the time, replying only to the author is a less common thing to do, and R is harder to type than r, so I guess somewhere along the way, someone switched them. | S-nail uses "Reply-To:" to replace just "From:" (although, unlike the | others,
