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?<p>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.
Me, I'm the target audience :).<p>From the linked articles, I understand "greytrapping" to be adding clients that attempt delivery to an invalid address <i>and</i> don't retry when greylisted to a deny list.
The article is about SMTP 451 Requested action aborted: local error in processing and not HTTP 451 - request cannot be satisfied for legal reasons.
Greylisting is great until it delays your email login/signup verification codes for 20 minutes. Especially if they expire in 15.<p>I guess this only shows how email is used for entirely orthogonal purposes now.
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.<p>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 <i>so</i> time sensitive. My greylisting is only 5 minutes.
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).<p>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.
Unless you whitelist the notification email, which I've has to do a few times.
Whitelisting doesn't work if one doesn't know the email domain name the service will use.<p>An Amazon verification email will be sent from "account-update@amazon.com". It's intuitive to predict "@amazon.com" so whitelisting works.<p>However, State Farm Insurance login verification codes are actually sent from <i>"noreply@sfauthentication.com"</i> instead of the "@statefarm.com"
For some weird reason I thought this was about Ray Bradbury's Fahrenheit 451.
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.<p>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 <i>most</i> legit mailers will do just that. Not all, though.<p>Recent versions of postfix added protocol checks that don't require a retry from the client: <a href="https://www.postfix.org/POSTSCREEN_README.html" rel="nofollow">https://www.postfix.org/POSTSCREEN_README.html</a><p>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.<p>Pre-greet checks are <i>still</i> a hack: there's nothing stopping a competent spammer from implementing the protocol properly, except that "competent spammer" is an oxymoron.
How is preventing delivery of legitimate email due to the sender's software being misconfigured "good for you"?<p>Also, RFC 5321 [0] says:<p>> 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.<p>> In many situations and configurations, the less- capable clients discussed above SHOULD be using the message submission protocol (RFC 4409) rather than SMTP.<p>[0] <a href="https://www.rfc-editor.org/rfc/rfc5321" rel="nofollow">https://www.rfc-editor.org/rfc/rfc5321</a>
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.
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.<p>Which isn't to say it's not worth it, although nowadays I'd recommend that <a href="https://www.postfix.org/POSTSCREEN_README.html" rel="nofollow">https://www.postfix.org/POSTSCREEN_README.html</a> pre-greet checks are just as good at stopping spam and better at not blocking legit mail.
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.
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.
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.
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.
[dead]