| ▲ | What's up with all those equals signs anyway?(lars.ingebrigtsen.no) |
| 344 points by todsacerdoti 6 hours ago | 101 comments |
| |
|
| ▲ | TazeTSchnitzel 16 minutes ago | parent | next [-] |
| The most interesting thing to me wasn't the equals signs, which I knew are from quoted-printable, but the fact that when an equals sign appears, a letter that should have been preceding or following it is missing. It's as if an off-by-one error has occurred, where instead of getting rid of the equals sign, it's gotten rid of part of the actual text. Perhaps the CRLF/LF thing is part of it. |
| |
|
| ▲ | ruhith 4 hours ago | parent | prev | next [-] |
| The real punchline is that this is a perfect example of "just enough knowledge to be dangerous." Whoever processed these emails knew enough to know emails aren't plain text, but not enough to know that quoted-printable decoding isn't something you hand-roll with find-and-replace. It's the same class of bug as manually parsing HTML with regex, it works right up until it doesn't, and then you get congressional evidence full of mystery equals signs. |
| |
| ▲ | lvncelot 3 hours ago | parent | next [-] | | > It's the same class of bug as manually parsing HTML with regex, it works right up until it doesn't I'm sure you already know this one, but for anyone else reading this I can share my favourite StackOverflow answer of all time: https://stackoverflow.com/a/1732454 | | |
| ▲ | josefx 3 hours ago | parent | next [-] | | I prefer the question about CPU pipelines that gets explained using a railroad switch as example. That one does a decent job of answering the question instead of going of on a, how to best put it, mentally deranged one page rant about regexes with the lazy throw away line at the end being the only thing that makes it qualify as an answer at all. | | |
| ▲ | kapep 2 hours ago | parent | next [-] | | The regex answer is from the very old days of Stackoverflow, before fun was banned. I agree it barely qualifies as answer, but considering that the question has over 4 million page views (which almost puts it in the top 100 most viewed questions all-time), it has reached a lot people. The answer probably had much more influence than any serious answer on that topic. So I'd say the author did a good job. | | |
| ▲ | bobince an hour ago | parent | next [-] | | Of all the things I wrote on SO, including many actually-useful detailed explanations, it was this drunken rant that stuck, for some reason. | | |
| ▲ | falcor84 an hour ago | parent [-] | | And for that I applaud you. I know it's a hassle for a platform to moderate good rants from bad ones, and I decry SO from pushing too hard against these. I truly believe that our industry would benefit from more drunken technical rants. |
| |
| ▲ | DangitBobby an hour ago | parent | prev [-] | | People have shared it here and on reddit a bunch of times because it's funny. I always found the pragmatic counter-answer about using regex and the comments about how brittle it is to parse XML properly assuming a specific structure to be much more useful. |
| |
| ▲ | MrGilbert 2 hours ago | parent | prev [-] | | For anyone wondering about the railroad switch post:
https://stackoverflow.com/questions/11227809/why-is-processi... |
| |
| ▲ | bayesnet 2 hours ago | parent | prev | next [-] | | I know this is grumpy but this I’ve never liked this answer. It is a perfect encapsulation of the elitism in the SO community—if you’re new, your questions are closed and your answers are edited and downvoted. Meanwhile this is tolerated only because it’s posted by a member with high rep and username recognition. | | |
| ▲ | 1718627440 2 hours ago | parent | next [-] | | I think this answer was tolerated when SO wasn't as bad as it is now, and wouldn't be tolerated now from anyone. | |
| ▲ | throwaway_61235 2 hours ago | parent | prev [-] | | As someone who used to write custom crawlers 20 years ago, I can confirm that regular expressions worked great. All my crawlers were custom designed for a page and the sites were mostly generated by some CMS and had consistent HTML. I don't remember having to do much bug fixes that were related to regular expression issues. I don't suggest writing generic HTML parsers that works with any site, but for custom crawlers they work great. Not to say that the tools available are the same now as 20 years ago. Today I would probably use puppeteer or some similar tool and query the DOM instead. |
| |
| ▲ | Cthulhu_ 2 hours ago | parent | prev [-] | | HE COMES |
| |
| ▲ | V__ 3 hours ago | parent | prev [-] | | They have top men working on it right now. |
|
|
| ▲ | heikkilevanto 4 hours ago | parent | prev | next [-] |
| I thought the article would be about the various meanings of operators like = == === .=. <== ==> <<== ==>> (==) => =~= |
| |
|
| ▲ | tiborsaas 5 hours ago | parent | prev | next [-] |
| > We see that that’s a quite a long line. Mail servers don’t like that Why do mail server care about how long a line is? Why don't they just let the client reading the mail worry about wrapping the lines? |
| |
| ▲ | direwolf20 4 hours ago | parent | next [-] | | SMTP is a line–based protocol, including the part that transfers the message body The server needs to parse the message headers, so it can't be an opaque blob. If the client uses IMAP, the server needs to fully parse the message. The only alternative is POP3, where the client downloads all messages as blobs and you can only read your email from one location, which made sense in the year 2000 but not now when everyone has several devices. | | |
| ▲ | fluoridation 2 hours ago | parent [-] | | Hey, POP3 still makes sense. Having a local copy of your emails is useful. | | |
| ▲ | direwolf20 2 hours ago | parent [-] | | If you want it to be the only copy and not sync with anything POP3 is line–based too, anyway. Maybe you can rsync your maildir? | | |
| ▲ | fluoridation 2 hours ago | parent [-] | | I just read it mainly in one place and through the web interface when I have to. | | |
| ▲ | dylan604 11 minutes ago | parent [-] | | If your "in one place" reader is still open and downloading messages then there will be no messages to view in the web interface when you have to. |
|
|
|
| |
| ▲ | layer8 4 hours ago | parent | prev | next [-] | | Mails are (or used to be) processed line-by-line, typically using fixed-length buffers. This avoids dynamic memory allocation and having to write a streaming parser. RFC 821 finally limited the line length to at most 1000 bytes. Given a mechanism for soft line breaks, breaking already at below 80 characters would increase compatibility with older mail software and be more convenient when listing the raw email in a terminal. This is also why MIME Base64 typically inserts line breaks after 76 characters. | | |
| ▲ | SoftTalker 2 hours ago | parent [-] | | In early days, many/most people also read their email on terminals (or printers) with 80-column lines, so breaking lines at 72-ish was considered good email etiquette (to allow for later quoting prefix ">" without exceeding 80 characters). |
| |
| ▲ | jcynix an hour ago | parent | prev | next [-] | | "BITNET was a co-operative university computer network in the United States founded in 1981 by Ira Fuchs at the City University of New York (CUNY) and Greydon Freeman at Yale University." https://en.wikipedia.org/wiki/BITNET BITNET connected mainframes, had gateways to the Unix world and was still active in the 90s. And limited line lengths … some may remember SYSIN DD DATA … oh my goodness … https://www.ibm.com/docs/en/zos/2.1.0?topic=execution-systsi... | |
| ▲ | citrin_ru 4 hours ago | parent | prev | next [-] | | Back in 80s-90s it was common to use static buffers to simplify implementation - you allocate a fixed size buffer and reject a message if it has a line longer than the buffer size. SMTP RFC specifies 1000 symbols limit (including \r\n) but it's common to wrap around 87 symbols so it is easy to examine source (on a small screen). | |
| ▲ | liveoneggs 3 hours ago | parent | prev | next [-] | | This is how email work(ed) over smtp. When each command was sent it would get a '200'-class message (success) or 400/500-class message (failure). Sound familiar? telnet smtp.mailserver.com 25 HELO MAIL FROM: me@foo.com RCPT TO: you@bar.com DATA blah blah blah how's it going? talk to you later! . QUIT | | |
| ▲ | Telemakhos 3 hours ago | parent | next [-] | | This brings back some fun memories from the 1990s when this was exactly how we would send prank emails. | | |
| ▲ | fix4fun an hour ago | parent [-] | | That was nice part of 1990s - many systems allow for funny things ;) |
| |
| ▲ | 1718627440 2 hours ago | parent | prev | next [-] | | For anyone who wants to try this against a modern server: openssl s_client -connect smtp.mailserver.com:smtps -crlf
220 smtp.mailserver.com ESMTP Postfix (Debian/GNU)
EHLO example.com
250-smtp.mailserver.com
250-PIPELINING
250-SIZE 10240000
250-VRFY
250-ETRN
250-AUTH PLAIN LOGIN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250-DSN
250-SMTPUTF8
250 CHUNKING
MAIL FROM:me@example.com
250 2.1.0 Ok
RCPT TO:postmaster
250 2.1.5 Ok
DATA
354 End data with <CR><LF>.<CR><LF>
Hi
.
250 2.0.0 Ok: queued as BADA579CCB
QUIT
221 2.0.0 Bye
| |
| ▲ | xg15 2 hours ago | parent | prev [-] | | I like how SMTP was at least honest in calling it the "receipt to" address and not the "sender" address. Edit: wrong. | | |
| ▲ | 1718627440 2 hours ago | parent [-] | | RCPT TO specifies the destination (recipient) address, the "sender" is what is written in MAIL FROM. However what most mail programs show as sender and recipient is neither, they rather show the headers contained in the message. | | |
|
| |
| ▲ | thephyber 4 hours ago | parent | prev | next [-] | | The simplest reason: Mail servers have long had features which will send the mail client a substring of the text content without transferring the entire thing. Like the GMail inbox view, before you open any one message. I suspect this is relevant because Quoted Printable was only a useful encoding for MIME types like text and HTML (the human readable email body), not binary (eg. Attachments, images, videos). Mail servers (if they want) can effectively treat the binary types as an opaque blob, while the text types can be read for more efficient transfer of message listings to the client. | |
| ▲ | josefx 4 hours ago | parent | prev | next [-] | | RFC822 explicitly says it is for readability on systems with simple display software. Given that the protocol is from 1982 and systems back then had between 4 and 16kb RAM in total it might have made sense to give the lower end thin client systems of the day something preprocessed. | | |
| ▲ | sumtechguy 3 hours ago | parent [-] | | Also it is an easy way to stop a denial of service attack. If you let an infinite amount in that field. I can remotely overflow your system memory. The mail system can just error out and hang up on the person trying the attack instead of crashing out. | | |
| ▲ | fluoridation 2 hours ago | parent [-] | | Surely you don't need the message to be broken up into lines just for that. Just read until a threshold is reached and then close the connection. |
|
| |
| ▲ | Pinus 4 hours ago | parent | prev | next [-] | | As far as I can remember, most mail servers were fairly sane about that sort of thing, even back in the 90’s when this stuff was introduced. However, there were always these more or less motivated fears about some server somewhere running on some ancient IBM hardware using EBCDIC encoding and truncating everything to 72 characters because its model of the world was based on punched cards. So standards were written to handle all those bizarre systems. And I am sure that there is someone on HN who actually used one of those servers... | | | |
| ▲ | codingdave 4 hours ago | parent | prev [-] | | Keep in mind that in ye olden days, email was not a worldwide communication method. It was more typical for it to be an internal-only mail system, running on whatever legacy mainframe your org had, and working within whatever constraints that forced. So in the 90s when the internet began to expand, and email to external organizations became a bigger thing, you were just as concerned with compatibility with all those legacy terminal-based mail programs, which led to different choices when engineering the systems. | | |
|
|
| ▲ | xg15 3 hours ago | parent | prev | next [-] |
| I'm just wondering why this problem shows up now. Why do lots of people suddenly post their old emails with a defective QP decoder? > For some reason or other, people have been posting a lot of excerpts from old emails on Twitter over the last few days. On the risk of having missed the latest meme or social media drama, but does anyone know what this "some reason or other" is? Edit: Question answered. |
| |
| ▲ | SCdF 3 hours ago | parent | next [-] | | Presumably the Epstein files, but I'm not on twitter so not sure | | | |
| ▲ | ropp 3 hours ago | parent | prev [-] | | the DOJ published another bunch of Epstein emails |
|
|
| ▲ | thedanbob 3 hours ago | parent | prev | next [-] |
| I wrote my own email archiving software. The hardest part was dealing with all the weird edge cases in my 20+ year collection of .eml files. For being so simple conceptually, email is surprisingly complicated. |
| |
| ▲ | stevekemp an hour ago | parent [-] | | I wrote a console-based mail client, which was 25% C++ and 75% Lua for defining the UI and the processing. It never got too popular, but I had users for a few years and I can honestly say MIME was the bane of my life for most of those years. |
|
|
| ▲ | beejiu 5 hours ago | parent | prev | next [-] |
| > So what’s happened here? Well, whoever collected these emails first converted from CRLF (i.e., “Windows” line ending coding) to “NL” (i.e., “Unix” line ending coding). This is pretty normal if you want to deal with email. But you then have one byte fewer: I think there is a second possible conclusion, which is that the transformation happened historically. Everyone assumes these emails are an exact dump from Gmail, but isn't it possible that Epstein was syncing emails from Gmail to a third party mail server? Since the Stackoverflow post details the exact situation in 2011, I think we should be open to the idea that we're seeing data collected from a secondary mail server, not Gmail directly. Do we have anything to discount this? (If I'm not mistaken, I think you can also see the "=" issue simply by applying the Quoted-Printable encoding twice, not just by mishandling the line-endings, which also makes me think two mail servers. It also explains why the "=" symbol is retained.) |
| |
| ▲ | TazeTSchnitzel 18 minutes ago | parent | next [-] | | In one of the email PDFs I saw an XML plist with some metadata that looked like it was from Apple's Mail.app, so these might be extracted from whatever internal format that uses. | |
| ▲ | MoltenMan 4 hours ago | parent | prev [-] | | This seems like the most likely reason to me! |
|
|
| ▲ | JKCalhoun 2 hours ago | parent | prev | next [-] |
| (The title of the blog reminded me the late Bob Pease [1] who had the signature, "What's all this XXX stuff, anyhow?" [2] where XXX might be "noise gain", "capacitor leakage"…) [1] https://en.wikipedia.org/wiki/Bob_Pease [2] https://www.qsl.net/n9zia/pease/index.html |
|
| ▲ | quibono 5 hours ago | parent | prev | next [-] |
| CLRF vs LF strikes again. Partly at least. I wonder why even have a max line length limit in the first place? I.e. is this for a technical reason or just display related? |
| |
| ▲ | brk 2 hours ago | parent | next [-] | | Wait, now we have to deal with Carriage Line Return Feeds too? I wonder if the person who had the idea of virtualizing the typewriter carriage knew how much trouble they would cause over time. | | |
| ▲ | keybored 2 hours ago | parent [-] | | Yeah, and using two bytes for a single line termination (or separation or whatever)? Why make things more complicated and take more space at the same time? | | |
| ▲ | floren 2 hours ago | parent [-] | | Remember that back in the mists of time, computers used typewriter-esque machines for user interaction and text output. You had to send a CR followed by an LF to go to the next line on the physical device. Storing both characters in the file meant the OS didn't need to insert any additional characters when printing. Having two separate characters let you do tricks like overstriking (just send CR, no LF) |
|
| |
| ▲ | OJFord 5 hours ago | parent | prev | next [-] | | I haven't seen them other than in the submission - but if the length matches up it may be that they were processed from raw email, the RFC defines a length to wrap at. Edit: yes I think that's most likely what it is (and it's SHOULD 78ch; MUST 998ch) - I was forgetting that it also specifies the CRLF usage, it's not (necessarily) related to Windows at all here as described in TFA. Here it is in my 'notmuch-more' email lib: https://github.com/OJFord/amail/blob/8904c91de6dfb5cba2b279f... | | |
| ▲ | FabHK 5 hours ago | parent [-] | | > it's not (necessarily) related to Windows at all here as described in TFA. The article doesn't claim that it's Windows related. The article is very clear in explaining that the spec requires =CRLF (3 characters), then mentions (in passing) that CRLF is the typical line ending on Windows, then speculates that someone replaced the two characters CRLF with a one character new line, as on Unix or other OSs. | | |
| ▲ | OJFord 4 hours ago | parent [-] | | Ok yeah I may have misinterpreted that bit in the article. It would be a totally reasonable assumption if you didn't happen to know that about email though, it wasn't a judgement regardless. |
|
| |
| ▲ | dgan 5 hours ago | parent | prev [-] | | I am just wondering how it is good idea for a sever to insert some characters into user's input. If a collegue were to propose this, i d laugh in his face It's just sp hacky i cant belive it's a real life's solution | | |
| ▲ | jagged-chisel 5 hours ago | parent | next [-] | | “Insert characters”? Consider converting the original text (maintaining the author’s original line wrapping and indentation) to base64. Has anything been “inserted” into the text? I would suggest not. It has been encoded. Now consider an encoding that leaves most of the text readable, translates some things based on a line length limit, and some other things based on transport limitations (e.g. passing through 7-bit systems.) As long as one follows the correct decoding rules, the original will remain intact - nothing “inserted.” The problem is someone just knowledgeable enough to be aware that email is human readable but not aware of the proper decoding has attempted to “clean up” the email for sharing. | | |
| ▲ | dgan 5 hours ago | parent [-] | | Okey it does sound better from this POV. Still wierd as its a Client/UI concern, not something a server is supposed to do; whats next,adding "bold" tags on the title? Lol | | |
| ▲ | brookst 3 hours ago | parent [-] | | SMTP is a line-oriented protocol. The server processes one line at a time, and needs to understand headers. Infinite line length = infinite buffer. Even worse, QP is 7-bit (because SMTP started out ASCII only), so characters >127 get encoded as three bytes (equal, then two hex digits), so a 500-character non-ASCII UTF8 line is 1500 bytes. It all made sense at the time. Not so much these days when 7-bit pipes only exist because they always have. |
|
| |
| ▲ | direwolf20 3 hours ago | parent | prev | next [-] | | It's called escaping, and almost every protocol has it. HN must convert the & symbol to & for displaying in HTML. Many wire protocols like SATA or Ethernet must insert a 1 after a certain number of consecutive 0s to maintain electrical balance. Don't remember which ones — don't quote me that it's SATA and Ethernet. | |
| ▲ | flexagoon 5 hours ago | parent | prev | next [-] | | When you post a comment on HN, the server inserts HTML tags into your input. Isn't that essentially the same thing? | | |
| ▲ | dgan 5 hours ago | parent [-] | | No, because there is a clear separation between the content and the envelop. You wouldnt expect the post office to open your physical letters and write routing instructions to the postmen for delivery But I agree with sibling comment: it makes more sense when its called "encoding" instead of "inserting chars into original stream" | | |
| ▲ | 1718627440 an hour ago | parent [-] | | > You wouldnt expect the post office to open your physical letters and write routing instructions to the postmen for delivery Digital communication is based on the postmen reading, transcribing and copying your letters. There is a reason why digital communication is treated differently then letters by the law and why the legally mandated secrecy for letters doesn't apply to emails. |
|
| |
| ▲ | layer8 4 hours ago | parent | prev [-] | | Just wait until you learn what mess UTF-8 will turn your characters into. ;) |
|
|
|
| ▲ | jojomodding 6 hours ago | parent | prev | next [-] |
| https://web.archive.org/web/20260203094902/https://lars.inge... Did the site get the HN kiss of death? |
|
| ▲ | maartin0 3 hours ago | parent | prev | next [-] |
| Fun how the archive.today article near the top has this exact issue https://pastes.io/correspond https://news.ycombinator.com/item?id=46843805 |
|
| ▲ | lordnacho 6 hours ago | parent | prev | next [-] |
| I love how HN always floats up the answers to questions that were in my mind, without occupying my mind. I, too, was reading about the new Epstein files, wondering what text artifact was causing things to look like that. |
| |
| ▲ | AlphaAndOmega0 6 hours ago | parent | next [-] | | Same here. I did notice what I think was an actual error on someone's part, there was a chart in the files comparing black to white IQ distributions, and well, just look at it: https://nitter.net/AFpost/status/2017415163763429779?s=201 Something clearly went wrong in the process. | |
| ▲ | fredley 5 hours ago | parent | prev [-] | | Me too. I first assumced it was an OCR error, then remembered they were emails and wouldn't need to go through OCR. Then I thought that the US Government is exactly the kind of place to print out millions of emails only to scan them back in again. I'm glad to know the real reason! |
|
|
| ▲ | voxelghost 4 hours ago | parent | prev | next [-] |
| My main takeaway from this article, is that I want to know what happened to the modified pigs with non-cloven hoofs |
|
| ▲ | lucb1e 4 hours ago | parent | prev | next [-] |
| cat title | sed 's/anyway/in email/'
would save a click for those already familiar with =20 etc. |
|
| ▲ | noduerme 4 hours ago | parent | prev | next [-] |
| Great. Can't wait for equal signs to be the next (((whatever this is))). Maybe it's a secret code. j/k On a side note: There are actually products marketed as kosher bacon (it's usually beef or turkey). And secular Jews frequently make jokes like this about our kosher bros who aren't allowed to eat the real stuff for some dumb reason like it has too many toes. |
| |
|
| ▲ | MarginalGainz 2 hours ago | parent | prev | next [-] |
| "It’s a fascinating case of 'Abstraction Leak'. We’ve become so accustomed to modern libraries handling encoding transparently that when raw data surfaces (like in these dumps), we often lack the 'Digital Archeology' skills to recognize basic Quoted-Printable. These artifacts (=20, =3D) are effectively fossils of the transport layer. It’s a stark reminder that underneath our modern AI/React/JSON world, the internet is still largely held together by 7-bit ASCII constraints and protocols from the 1980s. |
|
| ▲ | seydor 5 hours ago | parent | prev | next [-] |
| TLDR "=\r\n" was converted to "=\n" |
| |
| ▲ | netsharc 5 hours ago | parent | next [-] | | Author seems to think Unix uses a character called "NL" instead of "LF"... | | |
| ▲ | debugnik 5 hours ago | parent | next [-] | | Unicode labels U+000A as all of "LINE FEED (LF)", "new line (NL)" and "end of line (EOL)". I'm guessing different names were imported from slightly different character sets, although I understand the all-uppercase name to be the main/official one. https://www.unicode.org/charts/PDF/U0000.pdf | |
| ▲ | matsemann 5 hours ago | parent | prev | next [-] | | NL, or New Line, is a character in some character sets, like old mainframe computers. No need to be snarky just because he mistyped or uses a different name for something. | |
| ▲ | db_admin 5 hours ago | parent | prev [-] | | I am more surprised by the description of “rock döts”. A Norwegian certainly knows that ASCII is not enough for all our alphabetical needs. | | |
| ▲ | topaz0 2 hours ago | parent [-] | | https://en.wikipedia.org/wiki/Metal_umlaut The writer presumably knows that umlauts and other non-ascii characters are functional in many languages. "rock döts" is poking fun at the trend in a certain tranche of anglophone rock/metal to use them in a purely aesthetic way in band names etc. |
|
| |
| ▲ | thaumasiotes 4 hours ago | parent | prev [-] | | No, the article is quite explicit that that isn't what happened. |
|
|
| ▲ | brador 4 hours ago | parent | prev | next [-] |
| Could be worsened by inaccurate optical character recognition in some cases. Back in those days optical scanners were still used. |
|
| ▲ | zabzonk 4 hours ago | parent | prev | next [-] |
| People posting Excel formulae? |
|
| ▲ | ccppurcell 4 hours ago | parent | prev | next [-] |
| Rock dots? You mean diacritics? Yeah someone invented them: the ancient Greeks, idiöt. |
| |
|
| ▲ | ValveFan6969 an hour ago | parent | prev [-] |
| You don't need no equals signs when your IQ is through the roof and you got a superior attention span. What are these people even saying? Do they even know how to think for themselves or have they been completely brainwashed by their parents and the educational system into being exactly like everyone else, so much so that they're incapable of formulating an original idea? |
