Also email attachments can be binary encoded, base64 is just one option.
People are free to say that SMTP is "bad" or "broken" but they have to say exactly why that is the case. And "there are multiple different implementations" is a pretty poor justification, as a SMTP replacement would likely have the same issue (or worse).
(What will it look like? I would guess it will look like a two-part service, with one protocol for servers to talk to each other and another for clients to talk to servers. Servers will send tiny notifications to other servers that mail is available for their subscribers; then the receiving servers will retrieve the mail and cache it or store it for clients. This changes the spam problem fundamentally by requiring some persistence on the part of the sending server.)
I'd like to see the HTML that is supported in e-mails standardised, so there's no more issues about which clients will render what. I'd like to see the failure notices standardised, so that invalid e-mail addresses produce a standard "404-like" response, and so on.
The problem isn't so much that we have multiple implementations (I agree that can potentially be a strength). The problem is that there's very little that's consistent across the platforms.
Count me out. It wasn't even two weeks ago that we had the story here about how The Onion was hacked because somebody clicked on an obfuscated HTML URL in email.
We can't stop social engineering like that - it's completely unavoidable. Which is why banks and payment providers regularly tell people not to follow links asking for bank details (etc). Yeah it sucks that The Onion got hacked that way, but your argument is doesn't fix that. Your argument is nothing more than cutting of your nose to spite your face (ie advocating an inconsistent platform for legitimate e-mails despite anchor tags working on every client already).
At least if e-mail was completely redesigned, then we could have banks provide a unique cert that hangs in the e-mail header and can support the authenticity claim of the sender (I'm sure there's ways around that idea I've just presented - but that was just off the top of my head. Any such design would obviously need to be thoroughly thought out)
So like I said before, it's impossible to prevent social engineering.
What you're proposing is making things harder to work in the hope that human intelligence will prevail. But the problem is that these cases are where human intelligence has failed, so making things harder is just counter productive. And this is why you can't prevent social engineering from happening and why crippling technology and creating a worse user experience just to try catch a few fringe cases is just a backwards approach to handling the issue.
Instead what we need is methods in place to verify the authenticity of senders and better education to users so that don't make silly mistakes like installing random "virus scanners" from web ads or clicking strange URLs in e-mails (and the URLs themselves could be standardised. eg no sub-domains become clickable, to prevent people falling for face.book.com).
Strawman; we're talking about email, where the combination of header forging and HTML mis-labeling are what's really dangerous, not web pages.
Claiming this is a straw man argument only demonstrates how unwilling you are to view this from another's perspective. At least I've listened to your arguments and come up with potential workarounds.
So yes, I do agree with you that anchor tags are misused in phishing mail, but let's make that a reason to fix the specification rather than just ignoring the issues completely (or worse yet, officially removing HTML and then letting 3rd party developers invent their own broken specs and us ending back exactly where were are now).
As for your comment about mouse over events, you can't have Javascript in HTML e-mails so that point is completely irrelevant.
Now, there still are some loose ends about various screen sizes, preferred font family and size, and of course allowing textual searches, but those parameters should be few enough to be less problematic that HTML is right now.
It would disable any form of cross scripting by default, which in my opinion is a better state of affairs than HTML alone is right now (now, you can embed an external image in a web page, and bam, Facebook knows what you read).
I wish to see better support for non-ASCII plain text in email clients and web browsers, but until the HTML is all I have.
Then there's hyperlinks. If not like HTML anchor tags were the hypertext is independent to the destination, but still some method to follow links in e-mails as a lot of online registration requires email activation that way.
So do think there is a benefit for some level of markup in e-mails.
Well, there's the (IIRC) RFC-specified way to write URLs within '<URL:' and '>' pairs, e.g. <URL:https://news.ycombinator.com/>; (interestingly, the HN URL-finder doesn't support that).
So SMTP and POP3/IMAP?
>Servers will send tiny notifications to other servers that mail is available for their subscribers; then the receiving servers will retrieve the mail and cache it or store it for clients. This changes the spam problem fundamentally by requiring some persistence on the part of the sending server.
So NNTP?
| So SMTP and POP3/IMAP?
| So NNTP?
They probably shouldn't be, though, there's an IMAP extension for submission.
> I was under the impression that most Usenet networks used UUCP.
No, NNTP. UUCP hasn't been used seriously for over a decade.
Yours, news.ycombinator.com!ethomson
| No, NNTP. UUCP hasn't been used seriously for
| over a decade.
[1] According to Wikipedia, UUCP was still in use in 2006 for at least one software product.
Well it's not exactly secure, for one thing.
> Also email attachments can be binary encoded, base64 is just one option.
base64 is a method for encoding binary. You cannot send raw binary other ASCII - which is why base64 is used in SMTP.
> People are free to say that SMTP is "bad" or "broken" but they have to say exactly why that is the case.
Actually I have given a long list of reasons every time I've complained about SMTP[1][2]
[1] https://news.ycombinator.com/item?id=5510910 [2] https://news.ycombinator.com/item?id=5297472
No more or less secure than HTTP/HTTPS. In fact exactly as secure as...
>base64 is a method for encoding binary. You cannot send raw binary other ASCII - which is why base64 is used in SMTP.
http://tools.ietf.org/html/rfc3030
http://tools.ietf.org/html/rfc2045
http://en.wikipedia.org/wiki/MIME#Content-Transfer-Encoding
>Actually I have given a long list of reasons every time I've complained about SMTP >https://news.ycombinator.com/item?id=5510910 https://news.ycombinator.com/item?id=5297472
Your list is full of misinformation.
- Base64 thing is nonsense. As already stated SMTP supports binary and has for a long time.
- SMTPS is fairly well supported. In fact I currently connect to nothing which lacks it, and my email client auto-selects it when setting up new connections. Most of the hosts as far as I know support SMTPS out-of-the-box.
- SMTP reply codes are standardised (http://www.ietf.org/rfc/rfc1893.txt)
- HTML is standardised.
- SMTP is not designed to be real-time. That is what IM is designed to provide.
HTTPS is end to end encryption. In the instances that SMTP traffic is encrypted, it's only node to node. So SMTPS is less secure than HTTPS.
> http://tools.ietf.org/html/rfc3030
It's still not /the/ standard though, just /a/ standard; and one that's not particularly well supported in my experience. Most of the SMTP servers I've dealt with have archived and transmitted binary content over base64.
> Your list is full of misinformation.
Please don't be rude. And to address your bullet points:
- already addressed the binary / base64 remark
- already addressed the SMTPS remark
- yes, but those response codes are rarely transmitted back up the stack (and when they are, with a horribly garbled error). I'm talking about rebuilding the entire stack - from client to server - so that users get meaningful responses.
- of course HTTP is standardised. I never said it wasn't. So please don't turn this into a dumb trolling match where you make shit up to win an argument.
- I know SMTP isn't designed to be real time. But there's absolutely no reason why e-mails shouldn't be real time in the modern world. Simply citing IM's as an argument misses the point. IM's are for conversations. Emails are for memos. There's no reason why memo's shouldn't be sent real time. In fact, Android's Gmail notifications are real time. Exchange pushes mail to Outlook clients in real time. There's no reason why real-time shouldn't be the standard for all e-mails. (note: we're not talking about real time character update. Just a standard system for pushing messages instead of the client periodically polling for updates).
Sorry, not following you. HTTPS and SMTPS are both end to end encryption schemes. In fact they both use SSL in a similar way to secure traffic.
> It's still not /the/ standard though, just /a/ standard; and one that's not particularly well supported in my experience.
Really? Strange. I transmit binary data every day over email and I've never had an issue with a recipient not receiving it.
Which mail server and version in particular are you having issues with?
In general almost all of the "big names" in mail servers support more than just base64 as standard.
> yes, but those response codes are rarely transmitted back up the stack
I'm looking in my mail server logs right now, and am seeing a response code from a third party server for every email we forward. Our mail server then determines what to do with each code, and I can manually add additional handlers (e.g. code XXX do THIS, code YYY do THAT).
> I know SMTP isn't designed to be real time. But there's absolutely no reason why e-mails shouldn't be real time in the modern world.
Cost is a reason. Delivery assurance is another (e.g. if it fails to deliver the first time, do you retry for hours or just give up?). The fact that some clients are still on slow/off-line connections is a very good reason (e.g. phones that come in and out of cellular range, people on dial-up, people out in the middle of nowhere who get internet for an hour once a week, etc).
Yeah sorry, I explained my point abysmally there. What I meant was e-mails are only encrypted on a node-to-node basis but obviously a proportion of that transport isn't over SMTP. (My complaints are about the entire e-mail stack where as you're focusing on just SMTP, so there may have been a degree of us talking past each other).
> I'm looking in my mail server logs right now, and am seeing a response code from a third party server for every email we forward. Our mail server then determines what to do with each code, and I can manually add additional handlers (e.g. code XXX do THIS, code YYY do THAT).
We're definitely talking past each here. I'm on about client side not server side. (I should have been more clear from the outset that my complaints are about the entire email stack rather than specifically against SMTP)
> Cost is a reason. Delivery assurance is another (e.g. if it fails to deliver the first time, do you retry for hours or just give up?). The fact that some clients are still on slow/off-line connections is a very good reason (e.g. phones that come in and out of cellular range, people on dial-up, people out in the middle of nowhere who get internet for an hour once a week, etc).
None of that is really an issue though. 1) we already have mail servers that retry for hours 2) we already have instant push mechanisms for e-mails on phones 3) you're actually reducing the network overhead by eliminating the POP3/IMAP handshakes every n minutes in favor of an idle TCP/IP connection with periodic pings.
> Really? Strange. I transmit binary data every day over email and I've never had an issue with a recipient not receiving it. Which mail server and version in particular are you having issues with?
Maybe the base64 conversion is happening at my end then. It's never caused an issue as such (we have the capacity to cope with base64), it was just one of many niggles with the mismatch of the whole ecosystem. But I'll happily concede that I was wrong about the binary point :) (I don't particularly want to announce to the world what software and versions we're running at work for reasons that I hope you appreciate)
You should look at SIP. It's combination of HTTP,SMTP,... and is really great protocol for hackers and creative people. Bad side of SIP is that it's friking huge, but this is because there are lot of extensions (btw even IM is SIP extension).
Plain text means anyone can read your message while it's going over the wire. That person sitting next to you in the coffee shop? He's running a packet sniffer and is reading everything you send, because it's plain text.
-- edit: In information security, plaintext means unencrypted. That's true for SMTP, and that's what I'm referring to. Am I wrong?
You are making the same mistake other posters were making, confusing two different definitions of "plain text". The one we're talking about is ASCII versus some binary obfuscated format (such as MS Word). Both can be encrypted and made equally as secure. Plain text formats are much more amenable to grepping, grokking and manipulation; they make locking out competing implementations harder. See "Keep Knowledge in Plain Text": http://pragmatictips.com/20
In addition, most arguments about "space savings" are rendered moot by compression (which usually works better on plain text), the fact that binary formats in practice almost always take up more space for the same content (even when uncompressed), and most importantly, storage and bandwidth have rendered the size argument totally irrelevant.
Plain text is a style of encoding information (e.g. binary, XML, JSON, plain text, etc). Encryption determines if someone can intercept your message.
Something can be both plain text and secure, like HTTPS for one example.