John Levine wrote in
<20220107230754(_dot_)85D9634669D5(_at_)ary(_dot_)qy>:
|It appears that Steffen Nurpmeso <steffen(_at_)sdaoden(_dot_)eu> 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)
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp