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.
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.
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.
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.
9 comments
[ 1.7 ms ] story [ 29.5 ms ] threadAlso, 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
I guess this only shows how email is used for entirely orthogonal purposes now.
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.
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.