Hi, On 21 Jun 2003 19:21:12 +0100 Yorkshire Dave <[EMAIL PROTECTED]> wrote:
> On Sat, 2003-06-21 at 08:58, Alan Leghart wrote: > > > This method proposes to delay EVERY SINGLE MESSAGE until a database match > > is found for sending IP, FROM, and TO. > > > > So...we punish everyone in the world, and hope that a delay of one or more > > hours is considered "acceptable"? > > I agree, applied globally this is too much of a broad brush, it assumes > every host is a spammer and waits for them to prove otherwise with a > re-send. Guilty until proven innocent Might I politely suggest that people please read the original paper before engaging in any shrill handwringing: "The data collected during testing showed that more than 99% of the mail that was blocked with the tested setting of 1 hour would still have been blocked with a delay setting of only 1 minute. However, it is expected that as spammers become aware of this blocking method, they will change their software to retry failed deliveries. At that point, having a larger initial delay will definitely help, as it gives time for other blocking methods to act. For this reason, it is suggested that at least a one hour delay value be kept as a default, since spammers will start adapting as soon as this method becomes known and starts being used." and "One additional feature which has not yet been mentioned is the provision for some method to allow manual whitelisting of relays, recipients, and possibly even senders. This manual whitelisting capability is not strictly necessary, but for several reasons, a minimum implentation pretty much requires at least manual whitelisting based on IP address for things like localhost, or primary/backup MX hosts for the domains being handled. Since those relays are presumably smart enough to retry, and should never be blocked anyway, there is little point to delaying mail delivery attempts from them. Likewise, whitelisting recipients (or recipient domains) may be useful in an ISP or similar setting, where particular customers wish to exempt their domains from the possible mail delivery delays that Greylisting may cause." So the one hour figure was chosen as a reasonable *one-time* delay for sender-recipient-address triplet. Once a triplet is in the database, there's no further delay. In Alan's pathological example, one has to question a) why there's no communication between sales rep and sysadmin staff to allow rapid whitelisting of clients, b) why any business would be so incompetently managed as to put such critical reliance on such an unreliable medium as email[1] (don't these people have phones?), and c) if despite all good sense the timeliness of email was considered critical to business, why you'd implement greylisting with the default 1 hour delay rather than dropping it to 5 minutes (or why you'd use it at all.) But this is a chosen pathological example and the problems mentioned are less a function of greylisting as they are of bad management. In this case, the damage is less severe than that from refusing mail from blacklisted servers or silently dropping mail falsely flagged by SA and the method gracefully handles mailing list traffic unlike most C/R systems. The worst outcome from greylisting is an increased bandwidth requirement on innocents and an adjustably small delay on initial mailings. This is all described in the original paper. > Greylisting used in conjunction with an open relay/proxy dnsbl could be > good though, greylisting dnsbl listed hosts might be better than > blocking them outright. The one-hour delay is there primarily to allow the DNSBLs time to catch up to spam reports. Drop the latency in DNSBL listings and you can drop the one-hour default delay. Greylisting is not a panacea but it fairly well kills proxy-spamming dead right now and raises the cost and complexity of spamming with little change to existing systems and with trivial inconvenience to most users. YMMV. And yes, that's me listed way at the bottom of the credits section for initial peer review. I'm still concerned about the additional bandwidth consumed by widespread greylisting but the method forces spam sources to act like real MTAs and the only false positives found so far have been due to badly broken MTAs (those that ignore 45x temporary failure response codes.) Please follow up on [greylist-users] - see http://lists.puremagic.com/cgi-bin/mailman/listinfo/greylist-users for subscription info. -- Bob [1] Especially for moving graphics around. I worked in publishing and as of 1995 we routinely trucked image files back and forth via FTP. Anything really big involved mailing disks around (not CD-ROMs, SCSI drives...) ------------------------------------------------------- This SF.Net email is sponsored by: INetU Attention Web Developers & Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php _______________________________________________ Spamassassin-talk mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/spamassassin-talk
