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]
