Re: [Emailcore] Status of Greylisting (i'd wish MessageID were part of SMTP prologue)
Steffen Nurpmeso <[email protected]> Sat, 08 Jan 2022 22:11:48 +0100
| Newsgroups | gmane.ietf.smtp |
|---|---|
| Message-ID | <20220108211148.poNIn%[email protected]> |
John Levine wrote in <[email protected]>: |It appears that Steffen Nurpmeso <[email protected]> said: |>doable, but i do see very much different behaviour, for example by |>NetBSD.org, with multiple deferrals and short-time whitelisting. | |I have seen strange implementations of greylisting like this. When |I've asked people what the point of all of the extra delay is, the |most coherent answer I've gotten is that if they delay the mail and |it's spam, the IP might have gotten added to a DNSBL by the time they |retry. Of course, if that is what they really want, they should put |the incoming mail into a queue, wait a half hour, and then recheck the |DNSBLs before delivering it. It seems like they believe that making |greylisting stricter will make mail more secure, for ill defined |definitions of "more" and "secure." I have to say i am not really satisfied with this statement of yours, for one the software side says "what queue", and "how to drive this in practice with out-of-the-box software" (not to mention "easily"), and then NetBSD people never appeared half-assed to me, especially regarding network technology. For example they patch postfix to connect it with their blocklist daemon (that is now also in FreeBSD) in order to cheaply announce failed login attempts to the firewall. That spirit does not seem to be so brutely simple and asocial ("simply lay down responsibility to the network") as you imply here. So i am not convinced, but of course, the mechanisms you mention may also reduce spam load, and it may well be that this plays a role. |I also think some of the thinking is stuck in the distant past |when consumer ISPs didn't block outgoing port 25 and it was |more common for mail to come from behind NATs. So you are in favourite to obsolete Greylisting as such? I am just wondering, given how rigorously you limit access to your own mail account, in a world where more and more organizations and public bodies like Universities etc. outsource their entire mail infrastructure to the giant providers like GMail, to drop their administrative effort, most likely that will be the reason. |>You know and that is what is so hard to believe. Given that the |>concept is twenty years old and the standard becomes ten this |>year, wouldn't it make sense for a bot to simply try an address |>a second time after X minutes, if it has the time and space? | |That's not how bot spamware works. It's just about volume, |blasting mail out and not caring what happened to it. To |retry you have to remember what you've sent and have some |sort of retry queue. Naah, they have plenty of addresses, |they'll just send more spam. You know, i am not selling something here. You are surely right for most of the bots around. But there are more intelligent things around. And there are experienced, considerable players around which configure accordingly, in practice. I am only implementing a greylisting daemon, a standardized anti-spam aka anti-abuse policy, then further hopefully next week, and i was struggling with the impossibility to exactly identify emails, and that a bot that simply sends almost whatever email anew after x+1 minutes can only be whitelisted when looking for the triple client_address (mutilated!) / sender / recipient. And if players stop being nice or for whatever reason the IPv4/24 aka IPv6/64 mutilation may even render Greylisting impossible. And so my thinking was that the possibility to announce the one UUID that the Internet Message Format SHOULDs via a SMTP extension could be an idea how to improve this situation. Like i said, then your "single retry" could be sufficient if senders play nice, and the multi-hour delays that exist as of today would be left to the rest. |>(falsely read the manual) that turned it into an open relay, and, |>i really should have kept the logs because it was so fascinating, |>one IP connected, and did nothing for several minutes, then |>another IP connected, and then they started sending mails |>simultaneously (how did they know??) | |I see lots of botnets doing open relay scanning, with results |acted on quite fast. Yaaah, but note they did not log in, the first one only connected and staid. Well maybe they acted according to the greeting string, it is likely that more than one read the manual as it was by then falsely. You know it had that robotic-AI i-see! appearance, as it appeared in the logs, followed by the aggregation of troops that came thereafter in intervals. My gut feeling at least. Whereas that SSH attack i have seen, it was like a spider walking, very cautious, it must have taken months to get there, it was only one, and she/he did it. Whatever. A nice Sunday i wish everybody. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)