Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Hostile Email Landscape

liminality.xyz

Post reply on HN
Print view View original

221–230 of 251 posts

Re: The Hostile Email Landscape

#221

Post by ricardobeat »

lsc wrote: post #131
staunch wrote: post #119

Earlier quoted context omitted.

> ... because it would mean that spammers would need to control the servers they use to send for longer than they do now. This is the reason IM2000 is exciting. Spammers only survive using hit and run tactics. We might see a 99% reduction in total generated spam.

Really? More than 99% of the junk email in my box is from "legitimate" senders who use their own mailservers. The truth of the matter is that it's already pretty easy to block the hit and run spammers. Most of the junk that gets through is sent by people with the resources to bully the spamfilters into accepting it.

Your inbox != the internet. The majority of email traffic has been spam for a decade now.

Re: The Hostile Email Landscape

#222

Post by grey-area »

jimktrains2 wrote: post #79
grey-area wrote: post #71

Earlier quoted context omitted.

At present SMTP is so broken that arbitrary servers are allowed to send mail for any domain, with fake headers, there is no proper verification of sending server or sending identity, the mail is accepted (along with legitimate mail), and put in spam folders (sometimes, as is real mail sometimes). SPF/DKIM are an attempt to solve that of course, but they are not enforced rigorously or universally, and tactics like IP…

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.

Re: The Hostile Email Landscape

#223

Post by antichrist »

weihaw wrote: post #203

Gmail has Postmaster tools that let domains with moderately large mail flow be able to monitor their spam reputation scores, email authentication e.g DKIM / SPF, DMARC rejection rates, etc. This tool can help address a number issues folks here have mentioned wrt Gmail. In particular please look at the "Delivery Errors Dashboard" description in the help center article. help center post: https://goo.gl/7QHoqc Postmaste…

We are using Gmail Postmaster tools (I work at a small ESP), and while this tool is certainly useful for diagnosing rejections, delivery to Gmail inbox / promotions is still a black box.

In our case, a number of IP addresses we are using started showing up as "bad" in Postmaster tools, despite having no increase in complaint rates (actually, in Spam rate dashboard it shows 0.0% for the past 90 days). We have implemented Gmail feedback loop headers into outgoing emails to diagnose the issue, but the Feedback Loop dashboard also does not show any data.

All of these IPs have a Senderscore reputation in the high 90s and deliver perfectly fine to all ISPs, except Gmail. Contacting Gmail team through their form also yields no response.

My takeaway from this situation is that once Gmail starts not liking your emails for some obscure reason, you have practically no way to fix that, apart from getting a new IP / sending domain and starting to build sending reputation from scratch.

Re: The Hostile Email Landscape

#224

Post by crdoconnor »

lsc wrote: post #131
staunch wrote: post #119

Earlier quoted context omitted.

> ... because it would mean that spammers would need to control the servers they use to send for longer than they do now. This is the reason IM2000 is exciting. Spammers only survive using hit and run tactics. We might see a 99% reduction in total generated spam.

Really? More than 99% of the junk email in my box is from "legitimate" senders who use their own mailservers. The truth of the matter is that it's already pretty easy to block the hit and run spammers. Most of the junk that gets through is sent by people with the resources to bully the spamfilters into accepting it.

99% of them have unsubscribe buttons, too.

Re: The Hostile Email Landscape

#225

Post by rojor »

cm2187 wrote: post #7

The problem is not so much the attitude of the big guys. It is that smtp is fundamentally broken. we need a better mail protocol that ensures: 1. Traffic always encrypted and content always signed 2. Guarantee that the sender is who it claims he is 3. Decorrelating the email from the domain, a lot of users are prisoners of their current provider just because the address they gave everyone ends with the provider's dom…

You know, I've been wondering about this. I wrote about an email token system here [0], let me know what you think.

[0] https://roj.is/blog/a-different-approach-to-online-account-m...

Re: The Hostile Email Landscape

#226

Post by al2o3cr »

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 trivially solved", CHUG THE REST OF THE BOTTLE

Re: The Hostile Email Landscape

#227

Post by unclebucknasty »

david-given wrote: post #218
unclebucknasty wrote: post #146

Earlier quoted context omitted.

>* pinning the entirety of the blame on the third party provider is wrong.* We disagree. It's certainly understandable that the third-party might raise false-positives. 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. So, who else's fault would it be? Mine? The customer? The customer's e-mail provid…

> 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 classified as sending to honeypots and/or defunct addresses.

Re: The Hostile Email Landscape

#228

Post by wl »

staunch wrote: post #138
lsc wrote: post #131

Earlier quoted context omitted.

Really? More than 99% of the junk email in my box is from "legitimate" senders who use their own mailservers. The truth of the matter is that it's already pretty easy to block the hit and run spammers. Most of the junk that gets through is sent by people with the resources to bully the spamfilters into accepting it.

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…

> 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 emails blocked. This rationalization that spamming is ok because the recipient is a customer and there is an unsubscribe mechanism is delusional self-interest.

Re: The Hostile Email Landscape

#229

Post by JoeAltmaier »

wl wrote: post #228
staunch wrote: post #138

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…

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

Re: The Hostile Email Landscape

#230

Post by zrm »

chmike wrote: post #210
tromp wrote: post #169

Earlier quoted context omitted.

Sounds like a plan! With a memory-bound proof-of-work system like my Cuckoo Cycle, computing the hash could require the use of more than 4GB of memory for over 5 minutes on a 20-thread server, thus preventing the use of botnets for avoiding the expense.

Not sure Internet providers or google will be enthusiast about this proposal. This is equivalent as asking to pay to register a new destination address. In this case the mail relay owner has to pay. It would be more fair to ask users who send mail to pay to register a new destination address. Google and mail relay provider would be more happy with this variant.

It's very friendly to large providers. The amount of computation needed to send to a domain is the same regardless of how many emails you send so large providers can amortize it over more emails. And large providers generally operate their own infrastructure, which implies they already have a lot of idle computing capacity during off peak hours, and "off peak" is staggered across regions.

But even if some large providers refuse to hash outgoing mail, they can still verify incoming mail. The interesting benefit is that a small email provider can burn some dollars in computation once to avoid having their mail discarded by a large provider's spam filter indefinitely.

Post reply on HN