Re: [ietf-smtp] [Emailcore] Status of Greylisting (i'd wish MessageID were part of SMTP prologue)

[John Levine <[e-mail]>]

It appears that Steffen Nurpmeso  <[e-mail]> 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 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.

>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.

>(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.

R's,
John