The article is about SMTP 451 Requested action aborted: local error in processing and not HTTP 451 - request cannot be satisfied for legal reasons.
gwd 29 days ago [-]
It's not clear to me what the target audience of this article is. It seems to assume everyone knows what greylisting and greytrapping are; but surely the people who know what those terms mean without explanation are already convinced?
I picked up from context the general idea behind "greylisting", although I'm sure there's a lot of details that aren't covered. (How do you chose what domain gets greylisted? How often, how long?). But what "greytrapping" is, I can't guess, even after reading the entirety of two of his articles.
andrewaylett 29 days ago [-]
Me, I'm the target audience :).
From the linked articles, I understand "greytrapping" to be adding clients that attempt delivery to an invalid address and don't retry when greylisted to a deny list.
purkka 29 days ago [-]
Greylisting is great until it delays your email login/signup verification codes for 20 minutes. Especially if they expire in 15.
I guess this only shows how email is used for entirely orthogonal purposes now.
dijit 29 days ago [-]
I have an auto-whitelist if my greylisting has been handled properly, which means that, the first signup email is indeed invalid, but the second works.
On rare occasions I get frustrated by this, and I'm forced to login via ssh and manually permit a greylisted address through - though normally I am not so time sensitive. My greylisting is only 5 minutes.
nulbyte 29 days ago [-]
I tend to despise senders that believe email is always an effective real-time channel. Delays happen for all sorts of reasons, ranging from massive outages to scanning incoming emails for spam or malware (my corporate email is sloooow).
Greylisting has been so effective for my personal email, I don't mind waiting a bit on the rare occasion (by now, most senders are already recognized). And on the rare occasion I get spam, it's been cathartic, adding a rule to reject the sender with a quippy SMTP eerror. It's also been easy enough just to forward it to abuse@google.com, because it's almost always from Gmail.
spc476 29 days ago [-]
Unless you whitelist the notification email, which I've has to do a few times.
jasode 29 days ago [-]
Whitelisting doesn't work if one doesn't know the email domain name the service will use.
An Amazon verification email will be sent from "account-update@amazon.com". It's intuitive to predict "@amazon.com" so whitelisting works.
However, State Farm Insurance login verification codes are actually sent from "noreply@sfauthentication.com" instead of the "@statefarm.com"
rednafi 29 days ago [-]
For some weird reason I thought this was about Ray Bradbury's Fahrenheit 451.
Smar 29 days ago [-]
Fitting to the times.
andrewaylett 29 days ago [-]
Honestly, greylisting is a hack. There are better options available nowadays, for all that I was almost certainly using greylisting when the author wrote the text in the article.
The key insight behind the idea is that common junk mailing software doesn't support standard SMTP very well. Greylisting tells the client to try again in a few minutes, and most legit mailers will do just that. Not all, though.
A key observation here is that there's more than one way to ask a client to wait: the opening stanza in an SMTP transaction involves the server sending a message, and the client isn't supposed to respond until it receives that message. And it turns out that pre-greet checks (at least in my experience) have better anti-spam specificity. So I turned greylisting off $mumble years ago.
Pre-greet checks are still a hack: there's nothing stopping a competent spammer from implementing the protocol properly, except that "competent spammer" is an oxymoron.
Kwpolska 29 days ago [-]
How is preventing delivery of legitimate email due to the sender's software being misconfigured "good for you"?
Also, RFC 5321 [0] says:
> SMTP clients that [...] do not maintain queues for retrying message transmissions that initially cannot be completed, may otherwise conform to this specification but are not considered fully-capable.
> In many situations and configurations, the less- capable clients discussed above SHOULD be using the message submission protocol (RFC 4409) rather than SMTP.
In my 19 years of greylisting, I have yet to have legitimate email fail due to it. And it was one of the easiest ways to significantly decrease the amount of spam. It's been worth it in my opinion.
andrewaylett 29 days ago [-]
You may have not realised that legitimate email has failed (and it might even be true) but my experience suggests it's unlikely that it hasn't happened. I only have a handful of users, but when I was greylisting I'd get reports of missing mail at least annually.
Which isn't to say it's not worth it, although nowadays I'd recommend that https://www.postfix.org/POSTSCREEN_README.html pre-greet checks are just as good at stopping spam and better at not blocking legit mail.
wiredfool 29 days ago [-]
Greylistibg is very effective in my experience, but there are definitely some confirm your email loops that won’t work without whitelisting. It’s a combination of multiple ip addresses and retry times greater than the life of the code.
29 days ago [-]
selcuka 29 days ago [-]
In greylisting the 451 is sent from the recipient's SMTP sender to the sender's SMTP server. The client software is irrelevant. They have bigger problems if their server doesn't implement a retry queue.
flomo 29 days ago [-]
AFAICT, back in 2010 they had a partner who used a scummy email vendor. And he's still trying to re-litigate that? Email is so untrusted at this point, it seems not worth dredging up. The original site is gone and is now an AI startup.
flomo 29 days ago [-]
Also to add, before Mailchimp and Sendgrid etc, there weren't many obviously reputable vendors in the email space. The business people were dealing with a salesman who was sure you wouldn't getting spam holed.
PunchyHamster 29 days ago [-]
[dead]
Rendered at 11:33:26 GMT+0000 (Coordinated Universal Time) with Vercel.
I picked up from context the general idea behind "greylisting", although I'm sure there's a lot of details that aren't covered. (How do you chose what domain gets greylisted? How often, how long?). But what "greytrapping" is, I can't guess, even after reading the entirety of two of his articles.
From the linked articles, I understand "greytrapping" to be adding clients that attempt delivery to an invalid address and don't retry when greylisted to a deny list.
I guess this only shows how email is used for entirely orthogonal purposes now.
On rare occasions I get frustrated by this, and I'm forced to login via ssh and manually permit a greylisted address through - though normally I am not so time sensitive. My greylisting is only 5 minutes.
Greylisting has been so effective for my personal email, I don't mind waiting a bit on the rare occasion (by now, most senders are already recognized). And on the rare occasion I get spam, it's been cathartic, adding a rule to reject the sender with a quippy SMTP eerror. It's also been easy enough just to forward it to abuse@google.com, because it's almost always from Gmail.
An Amazon verification email will be sent from "account-update@amazon.com". It's intuitive to predict "@amazon.com" so whitelisting works.
However, State Farm Insurance login verification codes are actually sent from "noreply@sfauthentication.com" instead of the "@statefarm.com"
The key insight behind the idea is that common junk mailing software doesn't support standard SMTP very well. Greylisting tells the client to try again in a few minutes, and most legit mailers will do just that. Not all, though.
Recent versions of postfix added protocol checks that don't require a retry from the client: https://www.postfix.org/POSTSCREEN_README.html
A key observation here is that there's more than one way to ask a client to wait: the opening stanza in an SMTP transaction involves the server sending a message, and the client isn't supposed to respond until it receives that message. And it turns out that pre-greet checks (at least in my experience) have better anti-spam specificity. So I turned greylisting off $mumble years ago.
Pre-greet checks are still a hack: there's nothing stopping a competent spammer from implementing the protocol properly, except that "competent spammer" is an oxymoron.
Also, RFC 5321 [0] says:
> SMTP clients that [...] do not maintain queues for retrying message transmissions that initially cannot be completed, may otherwise conform to this specification but are not considered fully-capable.
> In many situations and configurations, the less- capable clients discussed above SHOULD be using the message submission protocol (RFC 4409) rather than SMTP.
[0] https://www.rfc-editor.org/rfc/rfc5321
Which isn't to say it's not worth it, although nowadays I'd recommend that https://www.postfix.org/POSTSCREEN_README.html pre-greet checks are just as good at stopping spam and better at not blocking legit mail.