| Spiros Bousbouras <spibou@gmail.com>: Jan 23 02:21PM I have altered the Subject: to reflect the discussion. This is something which someone (including myself) should have done several exchanges ago. I'm also crossposting to news.admin.net-abuse.usenet since some administrators of usenet servers hang out there and perhaps they can offer more insight. On Mon, 23 Jan 2023 14:29:43 +0100 > On 23/01/2023 10:34, Muttley@dastardlyhq.com wrote: > > On Sun, 22 Jan 2023 13:33:37 +0100 > > David Brown <david.brown@hesbynett.no> wrote: [...] > >> and Bonita) saw the original broken and header-jumbled cross post. > > And my id was in this jumbled header was it? > Yes. [...] > Basically, the header download from one or more newsservers (at least > news.eternal-september.org) differed completely from the headers in the > content of the message. Such an unusual glitch cannot happen independently on several newsservers so it can only have happened on one and then propagated. If it propagated then it should still be visible on other newsservers too since there's no automatic mechanism to fix this nor would news admins have any reason to assume there was an error to fix manually unless they happened to be reading the discussion. > You can't fake that, since it is (obviously) > not supported by the NNTP protocols. Either it is a sophisticated hack > - and that is not realistic - or it was the result of a server glitch. I assume "that" means that the Newsgroups: field in the header shows one set of groups G but some server shows the message when you ask for messages of a group P not contained in G. Yes , this would be hard to fake. The From: line is trivial to fake since severs will only check for correct syntax. -- vlaho.ninja/prog |
| David Ritz <dritz@mindspring.com>: Jan 23 01:03PM -0600 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday, 23 January 2023 14:21 -0000, in article <JaMukkKxSBcM7VPWN@bongo-ra.co>, > which someone (including myself) should have done several exchanges ago. I'm > also crossposting to news.admin.net-abuse.usenet since some administrators > of usenet servers hang out there and perhaps they can offer more insight. I'd like to buy a vowel^W Message-ID of the mystery message. Beyond that, the name appearing in the From header of a Usenet post is an optional descriptor. It can be nearly anything. It cannot be forged. (Email addresses are unique; names, not so much.) Based on the References header of <JaMukkKxSBcM7VPWN@bongo-ra.co> (<http://al.howardknight.net/?ID=167449837100>): <36403165-3cf1-4b73-8ad1-da339b960339n@googlegroups.com> (<http://al.howardknight.net/?ID=167449810000>) posted to rec.arts.books, only: strictly limited to a single newsgroup by G2's http2nntp interface. The article was posted using the GG posting account associated with the valid ibshambat@gmail.com email address. First followup (troll), from "Bonita Montero <Bonita.Montero@gmail.com>": <tqbkrr$1ja1c$1@dont-email.me> (<http://al.howardknight.net/?ID=167449819800>) added comp.lang.c++. The troll includes the full quote of the original post. The information included in the From header, of this message, may or may not accurately reflect its origin. X-post continued in <tqbn12$1jgmh$1@dont-email.me> (<http://al.howardknight.net/?ID=167449840700>, from =?UTF-8?B?w5bDtiBUaWli?= <ootiib@hot.ee>). It is in this post that the erroneous claim, "I can find no server with 'quoted' post," appears. (The quoted original text appeared only in rec.arts.books, not in comp.lang.c++.) <ea2f3bb3-532d-4014-9acd-24fe10a1feecn@googlegroups.com> (<http://al.howardknight.net/?ID=167449849500>) posted only to comp.lang.c++. etc. > [...] >>>> I will say it again - it appears to be the result of a server >>>> glitch. There is nothing here to support this claim. If supporting evidence exists, please refer to it. This matter appears to be more the result of a trolled user glitch. [ snip of conjecture based bickering ] I hope this clears up some of the confusion. - -- David Ritz <dritz@mindspring.com> You will never find an article posted only to rec.arts.books, in comp.lang.c++. -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQSc0FU3XAVGYDjSGUhSvCmZGhLe6wUCY87aGAAKCRBSvCmZGhLe 647lAJ9AZ9OEMM2EwI0mQxldXUQoIRHz9QCeMUZel7Dge9HbiPPNfFEEkk8iOqo= =5UeX -----END PGP SIGNATURE----- |
| Spiros Bousbouras <spibou@gmail.com>: Jan 23 08:06PM On Mon, 23 Jan 2023 13:03:52 -0600 > Beyond that, the name appearing in the From header of a Usenet post is > an optional descriptor. It can be nearly anything. It cannot be > forged. (Email addresses are unique; names, not so much.) Both the name and email address can trivially be forged. The email address doesn't have to be a real email (or even domain) , just syntactically valid. [...] > David Ritz <dritz@mindspring.com> > You will never find an article posted only to rec.arts.books, in > comp.lang.c++. Not under normal circumstances but the claim is that a temporary glitch on eternal-september caused it to happen and that David Brown saw it with his own eyes. |
| David Ritz <dritz@mindspring.com>: Jan 23 02:46PM -0600 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday, 23 January 2023 20:06 -0000, in article <z8dmrhuM9xNk7FY=M@bongo-ra.co>, >> be forged. (Email addresses are unique; names, not so much.) > Both the name and email address can trivially be forged. The email address > doesn't have to be a real email (or even domain) , just syntactically valid. This assume facts not in evidence. While you may be able to put whatever you want in the From header of your articles, posted via AIOE (or using a wide variety of NNTP clients and NNTP servers), Google is another ball of wax. The original article, at the beginning of this thread, was posted via the Google Groups web2news interface. This means that the posting account, with MUST appear in the From header of article originated in this manner. Additionally, we know that Google verified the address and account information, at the time the posting account, was originated. <36403165-3cf1-4b73-8ad1-da339b960339n@googlegroups.com> <http://al.howardknight.net/?ID=167449810000> ] Injection-Info: google-groups.googlegroups.com; posting-host=2001:8004:1160:28ef:d5ae:f4e8:3aac:6009; ] posting-account=90ZYxQoAAAARzFPaCqTWUKRTGA9K_b9_ I will leave it to your propensity for spinning wheels, to verify that each and every article posted via Google Groups and matching From headers containing ibshambat@gmail.com, also include the identical posting account information. > Not under normal circumstances but the claim is that a temporary > glitch on eternal-september caused it to happen and that David Brown > saw it with his own eyes. I'm of the "Show Me" school. I do not care about spurious, unsupported claims. The only glitch was human error. I recommend a visit to an optician. - -- David Ritz <dritz@mindspring.com> "With usenet gone, we just don't teach our kids entertainment-level hyperbole any more." - Paul Vixie -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQSc0FU3XAVGYDjSGUhSvCmZGhLe6wUCY87yNwAKCRBSvCmZGhLe 6yvaAJ46N4g5UyBKfyCF/gguIdoK9Jh/9wCdFmts46yfzazFmd6SdhXufISFgic= =jDYR -----END PGP SIGNATURE----- |
| Spiros Bousbouras <spibou@gmail.com>: Jan 23 10:00PM On Mon, 23 Jan 2023 14:46:47 -0600 > whatever you want in the From header of your articles, posted via AIOE > (or using a wide variety of NNTP clients and NNTP servers), Google is > another ball of wax. So when you said "in the From header of a Usenet post" you meant specifically a post made through googlegroups. Ok , I agree then. > MUST appear in the From header of article originated in this manner. > Additionally, we know that Google verified the address and account > information, at the time the posting account, was originated. [...] |
| "Adam H. Kerman" <ahk@chinet.com>: Jan 23 10:18PM >>forged. (Email addresses are unique; names, not so much.) >Both the name and email address can trivially be forged. The email address >doesn't have to be a real email (or even domain) , just syntactically valid. Of course David Ritz is correct. RFC 5536 Usenet Article Format (USEFOR) 3.1.2. From The From header field is the same as that specified in Section 3.6.2 of RFC5322 (with added restrictions not applicable to this discussion). RFC 5322 Internet Message Format (MESFOR) 3.6.2 Originator Fields from = "From:" mailbox-list CRLF If you read 3.4. Address Specification, you learn that mailbox-list is one or more mailboxes separated by a commas, mailbox itself is defined, and there's a statement "A mailbox receives mail." It's a concept but does not necessarily pertain to file storage. The standard is not a requirement that the user read messages, so let's not get into 247 rounds of "I refuse to use a mailbox on From because I don't want to inundated with spam." Use a mailbox specific to the address you use on From on Usenet articles and not one you use for personal or business communication. And if you don't want to read messages it receives, don't read it. If it's your mailbox, then you can make a legitimate abuse complaint if you are indeed forged. So "just syntactically valid" would be wrong. It receives mail. A News server has no method to validate that the address on From is indeed a mailbox but there are methods outside Usenet to validate a mailbox. In his followup, David Ritz points out that Google Groups validates the mailbox on From. I'm not telling you anything you don't already know. |
| Paavo Helde <eesnimi@osa.pri.ee>: Jan 23 07:49PM +0200 >> years ago on some hardware it had a point. > Putting a \0 at the end of some text you want to pass to a sub function is > standard practice. And ... we are arriving back to where we were before. I clarify now for better addressing your points: When using string_view, you always know how long your to-be-processed piece is, so you don't need to make pointless copies or rely on non-portable hacks (which incidentally also make pointless copies (of VM pages)) just to know where to stop processing. |
| Wuns Haerst <Wuns.Haerst@wurstfabrik.at>: Jan 23 08:07PM +0100 > Oh ok, now you're subdividing threads are you? You're the one who suggested > that using erase() and substr() was somehow just as efficient as returning > a pointer. My suggestion was related to the point that changing the string might result in a new string allocation and I've shown that this change might occur in-place. |
| Malcolm McLean <malcolm.arthur.mclean@gmail.com>: Jan 23 11:14AM -0800 On Monday, 23 January 2023 at 17:02:44 UTC, David Brown wrote: > A sequence of characters inside double quotation marks is a "string > literal". The double quotation marks plus the text inside is the "string literal". You need a different term to describe the text itself. |
| "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu>: Jan 23 11:38AM -0800 On Monday, January 23, 2023 at 2:14:33 PM UTC-5, Malcolm McLean wrote: > > literal". > The double quotation marks plus the text inside is the "string literal". > You need a different term to describe the text itself. "string literal" is a named element of the C grammar. In any context in which "string literal" is the appropriate description the whole thing, the appropriate description for what's between the quote marks is the named grammar element used in the definition of "string literal": s-char-sequence (6.4.5p1). In translation phase 7, the s-char-sequence is used to initialize an array. The details are described in the C standard, 6.4.5p6. That array is guaranteed to be terminated by a null character. As a result, every position within that array is guaranteed to qualify as the start of a C string, which might be empty if that position contains a null character. |
| Cholo Lennon <chololennon@hotmail.com>: Jan 23 04:44PM -0300 > ++p; > } > } OMG! that's why we still have plenty of CVEs in C/C++ applications and also new programming languages like Rust... :-O -- Cholo Lennon Bs.As. ARG |
| Keith Thompson <Keith.S.Thompson+u@gmail.com>: Jan 23 12:34PM -0800 > I do not call it an object, to me its just a variable. Anything beyond that > (an object wich might contain other properties as well as methods) is (way) > outside of my scope. The word "object" is not about object-oriented programming. The C standard defines an "object" as a "region of data storage in the execution environment, the contents of which can represent values"; it doesn't use the term "variable". The C++ standard uses the word "object" in the same way, though it doesn't have quite the same formal definition. An "object" is just a variable, except that a variable typically has a name. > But thats the crux : somethimes I get the distinct feeling that someone is > talking about the address (pointing to a string or otherwise), but than > suddenly seems to talk about the variable holding it. :-\ Yes, people are often informal, or even sloppy, about the distinction. >> *pointer expression*, all of which are clearly distinct concepts. > I think I can translate "pointer value" as to be meaning an address. For > the others ? I do not have the foggiest I'm afraid. For example, `int*` and `char*` are pointer types. A pointer value is the result of evaluating an expression of pointer type, including an expression that simply yields the value stored in an object/variable. That value can be the address of an object (or of a function, but let's set that aside), or it can be a null pointer (there are other possibilities). A pointer expression is a chunk of text in a C or C++ program, interpreted as an expression that, when evaluated, will yield a result of pointer type. >> <OT> > Whoooo.... Is that *on*, of *off* topic ? Not that it matters much which > one though. :-) "<OT>" means off-topic. I marked the last part of my article that way because it discusses C, while the topic of this newsgroup is C++, a distinct language. You raised the issue of the ambiguity between a "pointer" as a value and a "pointer" as an object in the context of a "pointer to a string", which is a C-specific context. I'm trying to steer the discussion in a direction that applies to both languages. (I might suggest posting to comp.lang.c, but I'm not sure it would be useful.) >> to a *value* of pointer type. > AFAIK most people do not use that phrase but use the (shorthand) "string > pointer" (with or without the space) instead. But yes, I would also. Sure, "string pointer" means the same thing as "pointer to a string". It's slightly informal, but not likely to be ambiguous. > But I think I am going to stop asking. It looks like the destinction > between the address and what its stored in isn't of much, if any, importance > to the people here. Suggestion: Any time you read something specific that you find confusing, ask about it. That's likely to be a lot easier than trying to solve the general problem. People with a lot of experience are likely to write in an informal shorthand that assumes a similar level of experience in readers. It can be ambiguous, but the ambiguity can be resolved *if* you have that experience. If something is genuinely confusing, feel free to keep us on our toes by asking about it. -- Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com Working, but not speaking, for XCOM Labs void Void(void) { Void(); } /* The recursive call of the void */ |
| Keith Thompson <Keith.S.Thompson+u@gmail.com>: Jan 23 01:26PM -0800 > The language states that a text literal in double quotes produces a nul-terminated > string. I think that's the only place the C language itself defines a string. Otherwise > it is purely a standard library concept. No, it doesn't say that. The standard's description of string literals (N1570 6.4.5) does not refer to the standard's definition of "string" (N1570 7.1.1). Consider, for example, "abc\0def". Sections 6 and 7 are both equally valid parts of the C standard. (Most of section 7 is optional for freestanding implementations, but 7.1.1 is not, though the concept of a "string" is less useful in an implementation that doesn't provide library functions that manipulate strings). (A side note: As far as I can tell, N1570 6.4.5 describes the syntax and semantics of a string literal, but never actually says what the value of a string literal is. It's obvious that it's the value of the described array object, but I don't think it actually says so. This is not relevant to the current discussion.) -- Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com Working, but not speaking, for XCOM Labs void Void(void) { Void(); } /* The recursive call of the void */ |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment