Live data from Hacker News

What's up with all those equals signs anyway?

lars.ingebrigtsen.no

81–90 of 200 posts

Re: What's up with all those equals signs anyway?

#81

Earlier quoted context omitted.

> 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

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.

I think this answer was tolerated when SO wasn't as bad as it is now, and wouldn't be tolerated now from anyone.

Re: What's up with all those equals signs anyway?

#82
(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

Re: What's up with all those equals signs anyway?

#83
post #33

> 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?

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 te…

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).

Re: What's up with all those equals signs anyway?

#85

Earlier quoted context omitted.

Hey, POP3 still makes sense. Having a local copy of your emails is useful.

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?

I just read it mainly in one place and through the web interface when I have to.

Re: What's up with all those equals signs anyway?

#86

> 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?

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

I like how SMTP was at least honest in calling it the "receipt to" address and not the "sender" address.

Edit: wrong.

Re: What's up with all those equals signs anyway?

#87

> 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?

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

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 .

    Hi
    .
    250 2.0.0 Ok: queued as BADA579CCB

    QUIT
    221 2.0.0 Bye

Re: What's up with all those equals signs anyway?

#88
post #86

Earlier quoted context omitted.

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

I like how SMTP was at least honest in calling it the "receipt to" address and not the "sender" address. Edit: wrong.

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.

Re: What's up with all those equals signs anyway?

#89
post #86

Earlier quoted context omitted.

I like how SMTP was at least honest in calling it the "receipt to" address and not the "sender" address. Edit: wrong.

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.

Ah, sorry. You're right.

Re: What's up with all those equals signs anyway?

#90
post #66

Earlier quoted context omitted.

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.

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?

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)
Post reply on HN