Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

This is fairly normal in today’s world of email providers, and one of the reasons it can be painful to manage your own SMTP server, right?

Mail delivery is an anarchy and I’m impressed the problem of spam has been solved to the degree we currently see. Yes it’s much more centralized than before, and no that isn’t a good thing, but from a customer’s experience point of view, I couldn’t go back to the old days of manually training your email client’s spam filter and whatnot.



> This is fairly normal in today’s world of email providers, and one of the reasons it can be painful to manage your own SMTP server, right?

Yes. Silently discarded e-mail is the worst thing that can happen because you can't detected it as a sender. Your message reaching the spam folder is bad, but not as bad as getting silently discarded.

The best among the bad options is probably getting rejected with the SMTP return code 550 along with instructions how to delist in the return message.


If you are running a business and have customers having emails that are silently being dropped, adding a "verify your email address" page in your process is probably a good step to have anyway.


Why exactly? Would Microsoft's internal spam filter likely consider that spammers often don't provide that page so you would stand out?


If they're consistently dropping mail, the user stays unverified. But a verification page is practically mandatory anyway for all sorts of reasons, not least checking the user hasn't mistyped their email.


If you’re being silently discarded you likely have terrible reputation, and requiring verification will help to fix that.


It's increasing becoming the case that "terrible reputation" now includes the low reputation self hosters who don't have enough volume to even use the tools Google and Microsoft offer.

Google's Postmaster tools all show "No data to display at this time. Please come back later. Postmaster Tools requires that your domain satisfies certain conditions before data is visible for this chart."

Microsoft's Safe Network Data Service shows *"No data for specified IPs on this date" for every day.


Don't worry they do that as well. First VPS I got had been completely blacklisted at the provider level and they were refusing everything with 550. Support didn't reply either.


> This is fairly normal in today’s world of email providers

Certainly not normal, but done sometimes, yes.

> and one of the reasons it can be painful to manage your own SMTP server, right?

It's part of the job, but it's more likely that the big providers are the least of your problems. They can be reached and you're usually not alone with your problems.

It's the small providers who have terrible filtering, who use low-quality shit-lists like UCEProtect/Backscatter or their own "heuristics", that are the most painful.


Well I've gotten blocked from being delivered Outlook-hosted mail because my primary MX is on a Linode block that at times get listed with UCEProtect (level 3 even!!!)

Why can't the big ones just check SPF and DKIM etc and let us responsible self-hosters do our thing


> Well I've gotten blocked from being delivered Outlook-hosted mail because my primary MX is on a Linode block that at times get listed with UCEProtect (level 3 even!!!)

I really don't think Microsoft would ever touch that pile of shit, most likely your spammy neighbour got your neighbourhood blacklisted at both places simultaneously.

> Why can't the big ones just check SPF and DKIM etc and let us responsible self-hosters do our thing

Most of the spammers have valid SPF and DKIM. Quite a few have entire subnets of IP addresses to spew spam from. That's why a random IP and just those two aren't sufficient to just start blasting.


«Most of the spammers have valid SPF and DKIM»

What porbelm means is that when SPF and DKIM are valid, reputation check should be based on the sending domain, not on the sending IP.

This way spammers still get thwarted (because of their domains with zero or low reputation) and legit senders can send from any IP (since their domain CAN build good reputation)

Besides, it's also easier to track reputation of ~360M domains than billion of IPv6 and IPv4 ranges.


That's great in theory.

Unfortunately many legitimate sending domains are newly registered, so have no reputation. It's not possible to rely on age either: if requiring domains to be aged becomes commonplace, they're cheap enough that spammers would just register them and wait for a bit, maintaining a pipeline of them.

So it becomes necessary to consider the reputation of whoever is enabling the sending of the email. The only way to do that is by IP.

If a domain uses DKIM, has a good reputation but comes from a bad IP, then sure, you might trust it. I don't think that'll help much in practice though.


Everything you said applies to IP-reputation as well. There is nothing that makes domain-reputation inherently harder than IP-reputation.

Consider this: every legit IP address once started with the problem of having zero reputation.

How you build reputation from zero is simple: you start by being allowed to send only small amount of daily emails (rest goes to spam or is outright rejected by the recipient SMTP server). Then adjust reputation based on the usual factors (observe human recipients flagging emails as spam/not spam, watch for keywords like Viagra, etc, all the exact same stuff email providers already do). You gain or loose reputation over time, which affects how much you can send: a lot, or nothing.


Some hosting providers have a very negative IP reputation. They seem to be unable to stop their users from sending out spam. They don't seem to react to abuse reports, let alone take action to stop abuse from their ASN generally. So I block their entire netblocks, IP-wise. I'm not aware of any legitimate emails being caught up in this. If somebody is unfortunately caught up, my response is that they should use a more reputable provider.

According to your previous post, I shouldn't do that for DKIM/SPF -valid emails by IP, but I do. I hope this explains I do, and why purely domain-based reputation doesn't work.


Big spammers own multiple ranges of IPs just as easily as they own multiple domains. When you block only 1 of their range, they can re-use their same domains to spam you from other ranges. If you blocked by domain, this would be effective across all their ranges of IPs.

So, in your example, blocking by IP isn't necessarily superior to blocking by domain (and vice versa.)

Once again: it's possible to have the tools and infrastructure manage domain reputation and do a job as good as (and arguably better than) IP reputation. Also to consider: IPs can be acquired by spammers for nearly $0 (eg: destroy+recreate VPS to get a new IP for free), whereas domain names have a fixed cost of ~$10 USD per year per domain. So if you have a system that manages domain reputation and has 1 million domain in the blacklist, you know for a fact that you are burning ~$10M/year of spammers' money.


I'm fairly sure all what you're desribing is and has been done. It's just not a simple problem and spammers do all that you've described as well, plus more.

Recent trend I'm seeing is creating malicious Google and Microsoft account or hacking websites and using those to spew spam.


> Why can't the big ones just check SPF and DKIM etc and let us responsible self-hosters do our thing

I self-host and frequently block entire ISPs. It's very common to get the same mail for days on end from a different IP, and often a different domain each time. Some months DO accounts for over 50% of my spam, for example.

I'm sure there's more graceful ways to handle it if I was willing to put far too much of my own time into fighting a losing battle. but adding a REJECT line for a whole netblock takes seconds.

I don't begrudge the big hosts for treating whole ISPs as cesspits as I do the very same thing.


It's solved?

From what I see, it's just a few players exchanging mail between themselves and discarding a high percentage of traffic.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: