gmail.com used to do that to lists.debian.org. We deliver ~300,000 emails to gmail a day. It resulted in some deliveries timing out before they were even attempted; I'll let you imagine the rest.
Cheers, Pasc On Fri, 2005-06-17 at 08:35 +0200, Petter Reinholdtsen wrote: > [Santiago Vila] > > For example, we could use greylisting. Or we could reject messages that > > are known to come directly from trojanized windows machines acting as > > open proxies. Or even better, we could do both things. > > Or a completely different option. Here at the university the > postmasters implemented a system to delay delivery based on blacklist > entries. The delaying is done during the first connect, and does not > require the MTA in the other end to reconnect, like greylisting. The > idea is simple: > > - Keep/use a list of good and not soo good blacklists for MTA hosts. > > - If the other side is listed in one of this blacklists, act as a > _very_ slow SMTP server. The initial hello reply is delayed 1-2 > minutes in this case, and if the client try to send anything in > this period, the connection is dropped. The SMTP protocol specifies > that the client should not send anything before receiving the intro > line from the other end, so this is safe to do. > > - This reduced the amount of spam with more than 90 percent, I've > been told. The current spam software do not seem to have time to > wait for a reply, or give up the delivery after a few seconds > without any reply. In either case, all standard-compliant MTAs are > able to get their mails through, even if they are listed in a > blacklist. > > - MTAs not listed in a blacklist is passed throught without any > delays. > > Could this be an idea for Debian as well? > > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]