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 s
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.
Minutes of the 14th September 2020 Teleconference
All Enclosed are the minutes from the teleconference held yesterday regards Andrew - Minutes of the 14th September 2020 Teleconference Austin-1063 Page 1 of 1 Submitted by Andrew Josey, The Open Group. 15th September 2020 Attendees: Nick Stoughton, USENIX, ISO/IEC JTC 1/SC 22 OR Don Cragun, IEEE PASC OR Joerg Schilling, FOKUS Fraunhofer Geoff Clare, The Open Group Eric Ackermann, HPI, University of Potsdam Eric Blake, Red Hat, The Open Group OR Richard Hansen Apologies: Andrew Josey, The Open Group Tom Thompson, IEEE * General news A reminder that we plan to switch the Etherpad authentication to use The Open Group Single Sign on. To test the authentication visit https://etherpad.rhansen.org/p/testing We plan to switch to this updated method most likely on 17 Sep 2020. Please note that you need to have a working login for www.opengroup.org. If you are having issues please contact Andrew. * Outstanding actions (Please note that this section has been flushed to shorten the minutes - to locate the previous set of outstanding actions, look to the minutes from 13th June 2019 and earlier) Bug 1254: "asynchronous list" description uses "command" instead of "AND-OR list" OPEN https://austingroupbugs.net/view.php?id=1254 Action: Joerg to investigate how his shell behaves. Bug 700 - Nick to raise this issue with the C committee Bug 713 - Nick to raise with the C committee. Bug 739 - Nick to raise with the C committee. * Current Business Bug 697: Adding of a getdirentries() function https://www.austingroupbugs.net/view.php?id=697 This has a separate etherpad page. https://posix.rhansen.org/p/bug697 We will continue after the Issue 8 draft 1 bug resolution Bug #1364: use of noclobber with files in /tmp Accept as Marked https://www.austingroupbugs.net/view.php?id=1364 On page 2287 line 73900 section 2.7.2, and page 3587 line 124071 section C.2.7.2, add to the "Notes to Reviewers": If option 2 is adopted in a future draft, note that the change from https://www.austingroupbugs.net/view.php?id=1364 [^] will need to be reapplied to the option 2 text. On page 2287 line 73909 section 2.7.2, change: Performing these operations atomically ensures that the creation of lock files and unique (often temporary) files is reliable. to: Performing these operations atomically ensures that the creation of lock files and unique (often temporary) files is reliable, with important caveats detailed in [xref to XRAT C.2.7.2]. On page 3588 line 124127 section C.2.7.2, change: The standard developers consider this to be of less importance than ensuring that the creation of lock files is reliable. to: The standard developers consider reliable lock creation to be more important than the creation of symbolic link targets. Creation of lock files and unique (often temporary) files with noclobber set is only reliable provided neither non-regular files nor symbolic links to non-regular files exist or are created in the same directory with the same names, and no other processes delete the files while still in use. If a directory such as /tmp is used for lock files, then another process could accidentally or maliciously create a FIFO (or a special file, given sufficient privilege) with the same name, causing multiple processes to simultaneously open the same lock file instead of one succeeding and the others failing. Bug #1365: rm -v description implies only operands are reported Accept https://www.austingroupbugs.net/view.php?id=1365 Bug #1366: Out of date rationale for XSI definition Accept https://www.austingroupbugs.net/view.php?id=1366 Bug #1369: COLUMNS and LINES rationale Accept https://www.austingroupbugs.net/view.php?id=1369 Bug #1370: Where change history starts OPEN https://www.austingroupbugs.net/view.php?id=1370 This was left open to get Andrew's view (He is happy with retaining Issue 5 in the CH) Proposed change: On page 3433 line 117421 (XRAT B.1.1) change: The CHANGE HISTORY section for each entry details the technical changes that have been made to that entry from Issue 5. Changes between earlier versions of the base document and Issue 5 are not included. to: The CHANGE HISTORY section for each entry details the technical changes that have been made in Issue 5 and later. Changes made before Issue 5 are not included. On page 3555 line 122714 (XRAT C.1.1) change: The CHANGE HISTORY section for each utility describes technical changes made to that utility from Issue 5. Changes between earlier versions of the base document and Issue 5 are not included. to: The CHANGE HISTORY section for each utility describes technical changes made to that utility in Issue 5 and later. Changes made before Issue 5 are not included. Bug #1383: Make "Application Usage" less confusing. OPEN https://www.austing
Austin Group teleconference +1 888 974 9888 PIN 618 156 403
BEGIN:VCALENDAR VERSION:2.0 PRODID:-//opengroup.org//NONSGML kigkonsult.se iCalcreator 2.22.1// CALSCALE:GREGORIAN METHOD:REQUEST BEGIN:VTIMEZONE TZID:America/New_York X-LIC-LOCATION:America/New_York BEGIN:DAYLIGHT TZOFFSETFROM:-0500 TZOFFSETTO:-0400 TZNAME:EDT DTSTART:20120311T02 RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=2SU END:DAYLIGHT BEGIN:STANDARD TZOFFSETFROM:-0400 TZOFFSETTO:-0500 TZNAME:EST DTSTART:20121104T02 RRULE:FREQ=YEARLY;BYMONTH=11;BYDAY=1SU END:STANDARD END:VTIMEZONE BEGIN:VEVENT UID:5f607ae01e...@opengroup.org DTSTAMP:20200915T082712Z ATTENDEE;ROLE=CHAIR:MAILTO:a.jo...@opengroup.org CREATED:20200915T00Z DESCRIPTION:Web/Project: Single UNIX Specification\nTitle: Austin Group tel econference +1 888 974 9888 PIN 618 156 403\nDate/Time: 21-Sep-2020 at 11: 00 America/New_York\nDuration: 1.00 hours\nURL: https://collaboration.open group.org/platform/single_unix_specification/events.php\n\n* All calls are anchored on US time **\n\nTopic: Austin Group teleconference\n--- \nAudio conference information \n---\n\nYou are invit ed to a Zoom meeting.\n\nMeeting ID: 618 156 403\n\nJoin from PC\, Mac\, i OS or Android: https://logitech.zoom.us/j/618156403\n \nor join by phone: \nUS: 888 974 9888\nUK: 800 031 5717\nDE: 800 724 3138\nFR: 805 082 588\n \nOther international numbers available here:\nhttps://zoom.us/u/adlvrb8IL j\n \nMeeting ID: 618 156 403\n\nor join from a H.323/SIP Device:\n Dial: 162.255.37.11 (US West) or 162.255.36.11 (US East)\nMeeting ID: 618 156 403\n\nShare from a PC or MAC: https://zoom.us/share/618156403\n \nOr iPhone one-tap (US Toll): +16699006833\,618156403# or +16465588656\, 618156403#\n\nPassword for zoom call ends with x\n\nAll Austin Group part icipants are most welcome to join the call.\nThe call will last for 60 min utes.\n\n\nAn etherpad is usually up for a meeting\, with a URL using the date format as below:\n\nhttps://posix.rhansen.org/p/202x-mm-dd\nusername= posix password=2115756#\n\n(Note that this will switch to use The Open Gro up single sign on\,\nfor those individuals with gitlab.opengroup.org accou nts.\nPlease contact Andrew if you need to be setup)\n\nBug reports are av ailable at:\nhttps://www.austingroupbugs.net\n DTSTART;TZID=America/New_York:20200921T11 DURATION:PT1H0M0S LAST-MODIFIED:20200915T042712Z ORGANIZER;CN=Single UNIX Specification:MAILTO:do-not-re...@opengroup.org SEQUENCE:0 STATUS:CONFIRMED SUMMARY:Austin Group teleconference +1 888 974 9888 PIN 618 156 403 TRANSP:OPAQUE URL:https://collaboration.opengroup.org/platform/single_unix_specification/ events.php X-MICROSOFT-CDO-ALLDAYEVENT:FALSE X-VISIBILITY:40 X-JOINBEFORE:5 X-CATEGORY:Teleconference X-PLATO-SITE:Single UNIX Specification X-PLATO-SITEID:136 END:VEVENT END:VCALENDAR meeting.ics Description: application/ics
