This one time, at band camp, Andreas Metzler said: > Wouter Verhelst <[EMAIL PROTECTED]> wrote: > > On Thu, Jul 13, 2006 at 11:01:09AM -0700, Thomas Bushnell BSG wrote: > [...] > >> Ok, now I understand. As I've already said, graylisting on /27 > >> netblocks amounts to inventing new network standards, which I believe > >> should go through the IETF standardization process before we block > >> email from people who don't comply with our newly invented standards. > > > Really, I don't understand why you wrote this. > > > Greylisting already exists. This would just make it _less_ of a problem. > > > By greylisting from /27 netblocks, you wouldn't block any additional > > mail as opposed to greylisting in general; quite to the contrary. > > > Greylisting in this manner does not require anything specific from a > > remote host, except that it must follow the standards as defined in > > RFC2821 and come back some time after it received the initial 4xx status > > reply. What part of that is a "newly invented standard"? > [...] > > Hello, > The following setup would be in compliance with rfc2821 but would > not be able to deliver mail to a greylisting host: > - retrying every hour for up to five days > - messages are sent out from 120 different IP-addresses all living in > different /27 netblocks. > - retries do not happen on the same IP. Initial try IP-address #1, 2nd > try IP-address #2, ... ,120th try IP-address #120
I suggest that when we find a domain that sends mail from 120 /27's
(roughly a /20), we worry about it then.
zgrep -E 'H=[^[:space:]]*.yahoo.com ' /var/log/exim4/mainlog* | egrep -v
'(-|=)>' | \
awk -F [ '{print $2}' | awk -F] '{print $1}' | sort -u | wc -l
2792
That's just over a /21, and they're the biggest I deal with. This is just
under a year's logs, on a fairly busy site. This site uses greylisting,
and does not use netblocks - it greylists the IP/sender/recipient tuple
as is. I have had no complaints about lost mail, although a few about
slow mail.
But that's not the entire point; there will be false positives. There are
probably false positives right now with the various other spam filters in
place, although I have no idea and can't check on them. Presumably the
sender doesn't get a notification in cases where a procmail rule or
spamassassin rule keeps a mail from hitting a list or my @debian.org
account.
With a greylisting system, there is no blackholing of mail - the sender
will get 'still retrying' DSN's, and finally a "couldn't deliver" DSN
in the above scenario. The sender is notified if there's a problem, so
long as the sending site pretends to follow the RFC.
The point is to make email useable without making it untreliable. This
way seems like a pretty good compromise to me.
--
-----------------------------------------------------------------
| ,''`. Stephen Gran |
| : :' : [EMAIL PROTECTED] |
| `. `' Debian user, admin, and developer |
| `- http://www.debian.org |
-----------------------------------------------------------------
signature.asc
Description: Digital signature
