231–240 of 251 posts
It is simple: the more fear uncertainty and doubt the "big email providers" can cast on no using one of the big email providers the more they chase everyone into their business (when they can read it). You can go on and on how it is "technically hard to fix email" but that is a second order effect to not even trying.
Earlier quoted context omitted.
Spam is viagra ads and the like (unsolicited commercial email). Promotional emails from companies you have a relationship with are a different thing. Users should be able to easily filter and ignore promotional email, but email hosting companies should never block it as spam. SMTP is not where email organization should happen. That's what email clients are for. Blocking DoS attacks and spam makes sense. Blocking Amaz…
>Users should be able to easily filter and ignore promotional email, but email hosting companies should never block it as spam. See, you still seem to think that it's a negotiation between the senders and the receivers. My point is that you don't have the right to the end-user's attention. If the end-user wants to hire someone to filter out messages they don't want to read, using whatever criteria for "don't want to…
> Users should be able to easily filter and ignore promotional email, but email hosting companies should never block it as spam.
i.e. Yes, it should be the user's control, not the hosting company's, not the sending server's.
Earlier quoted context omitted.
Yes, that's my point. It doesn't really solve any issues that SPF/DKIM don't already solve -- pointing to certs isn't a new solution, it's a rehash of the same solution. And yes, the concept of relays should disappear along with much of the other cruft SMTP brings. (And while we're at it, can we fix/replace IMAP, or at least make the spec say that message ids are eternal and can't be invalidated?)
IMO Message ids should be defined as a sha512 of headers and content to ensure they are unique. A new protocol is required.
As for a new protocol, there are some out there, but all fail in some way or another. I figured I'd throw my ideas out there and see how much they fail https://github.com/jimktrains/email_ng
Earlier quoted context omitted.
> However, what is wrong is when a business can demonstrate that it is not engaged in such practices, yet the third-party provider still refuses to cease penalizing them. They don't have any responsibility to help you do business. Comcast and your recipients are not required to accept your email. It's in their interest to do so, of course, because that's what their customers are paying them to do so... but their cust…
> They don't have any responsibility to help you do business No, but in the course of doing their business, this third party cannot wrongfully interfere with our business. It's a key distinction that you are missing. As to the rest of your comment, you are assuming that the problem was the content (advertising). However, I have stated at least three times on this thread the actual issue; we were erroneously classifie…
Um... they're an email filtering company, and you're an email sending company. Interfering with your business is their business! That's what Comcast is paying them to do --- Comcast want your business interfered with!
> As to the rest of your comment, you are assuming that the problem was the content (advertising).
I'm afraid you've missed my point here. The content is important, because having advertising in the content means that they will have already written you off as a reputable company. I'm pretty sure the conversation at their end went something like:
A. Hey, Bob, I've just got an email from someone claiming we shouldn't be blocking their email, but they're on the honeypot list.
B. Sigh. Again? Do we have one of their messages?
A. Yup. Here.
B. It's got advertising in it. They're a spammer. Screw 'em.
(It may not even have gone that far. I have no idea what format your newsletters are in, but if they score badly they may not even have bothered to look at them.)
My point is: you may not be a bad guy, but to an awful lot of people in the SMTP industry, you're going to look just like one.
Earlier quoted context omitted.
> Spam is viagra ads and the like (unsolicited commercial email). Promotional emails from companies you have a relationship with are a different thing. Users should be able to easily filter and ignore promotional email, but email hosting companies should never block it as spam. If you didn't ask my permission to send me those promotional emails, they absolutely are spam and anyone who sends them should have their ema…
Its also law. Do Not Call for instance doesn't apply to companies you have a relationship with. That's why some major banks 'affiliate' with 100's of companies, essentially selling the right to spam their customers. Its screwed up, sure. But its the state we're in right now.
Earlier quoted context omitted.
> They don't have any responsibility to help you do business No, but in the course of doing their business, this third party cannot wrongfully interfere with our business. It's a key distinction that you are missing. As to the rest of your comment, you are assuming that the problem was the content (advertising). However, I have stated at least three times on this thread the actual issue; we were erroneously classifie…
> No, but in the course of doing their business, this third party cannot wrongfully interfere with our business. Um... they're an email filtering company, and you're an email sending company. Interfering with your business is their business! That's what Comcast is paying them to do --- Comcast want your business interfered with! > As to the rest of your comment, you are assuming that the problem was the content (adve…
It's funny when people start their sentences with "Um...", as if they are about to unleash some potent wisdom of which their target is unaware, then instead immediately go on to prove that they have absolutely no idea what they're talking about.
And, now you're literally inventing imaginary conversations.
It's gotten really silly by now and I've repeated nearly half a dozen times on this thread why "points" such as yours are not applicable here. So, hope you don't mind that I'm going to get off this ride now.
Take care.
Everyone seems to agree that email is broken (and yet incredibly useful and almost universal in reach). So moving on from there, how do we fix it? Who is currently working on fixing it? What would a new protocol look like?
This is the big question I'd like to hear an answer for as well.
Earlier quoted context omitted.
Maybe something like this? https://github.com/ssbc https://github.com/ssbc/secure-scuttlebutt https://github.com/ssbc/scuttlebot
Or djb's IM2000 (later fleshed out by JdeBP): http://homepage.ntlworld.com/jonathan.deboynepollard/Proposa... That might have since fallen out of favor, I'm unsure.
I am surprised and encouraged to see IM2000 mentioned in this discussion.
As to whether such ideas have fallen out of favour, I offer this observation:
You are using a pull-style electronic communications system right now. Your WWW browser is the originator and receipient UA, and Hacker News is the message store. A copy of a message is only made and sent across the network when you request it with your User Agent. A lot of Internet-mediated communications are not SMTP-based any more. The shift to pull-style systems has, in some ways, actually already happened.
As such, many of the things that people ask about IM2000 are questions that they can answer from their own direct experiences, with a little reflection. How do you deal with senders who alter their messages? Well: how do you the receipient deal with the fact that right here and now I can hit an edit button and modify this comment after people have pulled it for reading it, with no edit history and nothing but the honour system for dealing with letting people know? The fleshing out of IM2000 set out the idea of downloading to folders in the recipient MUA the messages that one wanted to take off the senders' mail stores, by the way.
Earlier quoted context omitted.
Exchange is much more discerning of email structure than Google servers. That means that, if you have any configuration mistake, an Exchange server will reject your email. But if you have a good reputation, Gmail will deliver it anyway.
Exchange servers weren't "rejecting" my email. They were giving me SMTP 250 (Queued mail for delivery) then silently failing to deliver it. Hotmail sender support kept saying "I do not see anything offhand that would be preventing your mail from reaching our customers from this IP" Also, my emails were and are text/plain. I'm sure Exchange does reject malformed emails, but that wasn't my problem.
But, of course, YMMV. And I have no experience at all sending email to Hotmail. I just thought it was worth checking your server settings.
Drinking game for this thread. Start at the top of the comments: * every time someone implies spam filtering is a massive conspiracy against "the little guy", drink * every time someone suggests Bitcoin be used for something, drink * every time a solution utterly fails to account for compromised end-user machines sending spam, drink * every time a comment can be summed up as "assuming a PKI exists, this problem is tr…
That reminds me of an old classic: http://craphound.com/spamsolutions.txt
There are a lot of obvious problems with email.
* It's hard to run your own mail server, as described in the original post
* Your address is tied to your provider
* The standards involved in delivering mail (SMTP, POP, IMAP, etc) are complex, layered with hacks (SPF, STARTTLS, etc), hard to implement correctly, hard to secure.
* The standards that govern the actual body of email (multipart MIME, a 90s-vintage subset of "HTML" and "CSS") are even worse
But despite all those flaws, email is built on ubiquitous open standards running on a federated infrastructure.
It's the best thing we have.
Proprietary standards and centralized designs like AIM, ICQ, MSN, FB Messenger, Slack, and Twitter DMs come and go.
Email is forever, and is more useful than all of those combined. The flipside is that it's very hard to "fix".