dt> Yes, but the thought, that we have to queue every single *******
dt> message in the first place just because someone's greylisting,
dt> makes me kind of sick.
Perhaps it is just imprecise language, but it's not every message
that's affected. It's just the first time the receiving site sees a
new combination of (recipient, sender IP, sender). For most normal,
person-to-person sorts of emails, I'm skeptical that this adds up to
much above normal levels. For mailing list and other types of
traffics that use VERP (unique addresses per message), it's a burden.
dt> Yes, but it isn't usefull in any way even now, when spammers abuse
dt> other peoples systems. (Via open relay, open proxies, etc.) And
dt> by the way, spammers wouldn't have to really "queue" mails, just
dt> try to send every temporary failed message a second time after
dt> they finished processing their recipient list.
Of course, these things are all true, but it is also true that most
spammers and most virus email is coming from individual systems and
does not retry. Everyone fully expects those things to morph to
overcome greylisting someday. That time might not even be that far
off. OTOH, it's so cheap and effective to implement greylisting today
that it's almost foolish to avoid it.
dt> But as we're talking about greylisting, and many people here seem
dt> to use it, what about the hints database problem I mentioned here
dt> some time ago? As you're using greylisting, I'm sure you all have
dt> a solution to this situation:
Probably the only solution today is getting the recipient sites to
whitelist your servers, which is certainly labor intensive on both
ends. (I spend a lot of time manually examining my greylist logs
looking for "legit" SMTP senders to add to my whitelist.)
--
bill-exim@??? (WJCarpenter) PGP 0x91865119
38 95 1B 69 C9 C6 3D 25 73 46 32 04 69 D6 ED F3
