Ask HN: Is Graylisting Still Feasble? | Hacker News Reader

Ask HN: Is Graylisting Still Feasble?

12 pointsvoakbasda7 comments

I use graylisting on my mail server. For those unaware, this involves soft bouncing all incoming mail from new senders, requiring them to retry later. The idea is that most spammers will not retry, and this has seemed to work well for me over the years.

Recently, I have run into problems receiving 2FA messages, because the sender's mail server retry interval is longer than the expiration of the 2FA token. Unless I get really lucky with my timing, this basically locks me out of that account. In this case, it's my 401k, so this is not a situation where I can simply smile and ignore the absurdity of our modern age.

I tried contacting the company's support, but unsurprisingly they have been completely useless in resolving this issue. They will not extend the 2FA tokens' lifetime, and they will not decrease their mail server retry period.

While I can directly whitelist their addresses on my server, this situation seems to signal that graylisting no longer can be used without risking untimely delivery of 2FA or other time-critical mail, since the other users of my system do not have the ability to whitelist other addresses that cause problems. If you have run email servers that use graylisting, does this track with your experience?

More speculatively, have some servers stopped retrying delivering (contrary to RFC requirements) in the event of soft failures? That would be hard to believe, but I keep reading that various FAANG mail services are increasingly hostile when interacting with independent mail servers. It would not surprise me to learn that these services have found a way to detect and ban servers that use graylisting, though I cannot fathom a good reason beyond their insatiable desire to consolidate more users onto their platforms.

I also use greylisting along with XBL as sole spam control. But nowadays it's important to push it down the pipeline a little bit.

For example if my MTA receives an email that has a valid hostname, spf is good, isn't on xbl, then it will accept it even if the sender is unknown. Soft bounce happens only when something is blatantly incorrect.

I used to also check DKIM before accepting a mail but that forced my MTA to accept the SMTP DATA and I worry that some clients would not retry if the mail was rejected after DATA (even though they should, because "storage full" isn't uncommon for example).

It ends up working well for me because most legitimate mail have all those things right, and most illegitimate mail have at least one thing wrong.

> They will not extend the 2FA tokens' lifetime,

As they shouldn't. This will compromise the system's security.

> and they will not decrease their mail server retry period.

Is their retry period not following the RFC?

Graylisting has always required constant manual intervention when I managed mail servers. I'd say just whitelist their domain and move on.

Another solution is to outsource spam filtering to some 3rd-party service that will forward emails to you. It might be well worth your time.

It's been a while since I've messed with the details of mail servers, but it would seem that if a server passes the graylist test once, that's a good indication that it will continue to pass it, so you may want to see if you can have the graylist process allow the 2fa mails after the first one makes it through with retries.

Won't help much if they have a large outbound cluster though.

Doesn’t graylisting usually get applied to the first message from a `user@domain via server` set, and then when it resends and succeeds the test it’s added to a whitelist to prevent future delays?

That’s certainly how my mail service does it.

I would assume that sender+recipient for the 2FA is stable, so your graylist software should learn that as a good sender. Don't graylist every single email from a good sender!

This sounds annoying as hell for senders and incredibly non-standard. Why not just deal with spam? It’s not a big deal.

All my spam goes into a folder I basically never look at.

Now you’re breaking your own stuff just to stop spammers.

Actually, graylisting [1] works by exploiting the standard, which says mail servers may temporarily reject incoming messages for a variety of reasons (e.g. disk full). In these situations, the sending server is required to hold the message and try again, and those servers that don't are the ones that are violating the standard. Moreover, the sending user should never see the temporary failure. This is all outlined in Section 6.1 of RFC5321 [2].

[1] https://en.wikipedia.org/wiki/Greylisting_(email)

[2] https://datatracker.ietf.org/doc/html/rfc5321#section-6.1

Reply on news.ycombinator.com