[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: greylisting on debian.org?

This one time, at band camp, Andreas Metzler said:
> Wouter Verhelst <wouter@debian.org> 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

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

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 |
|  : :' :                                        sgran@debian.org |
|  `. `'                        Debian user, admin, and developer |
|    `-                                     http://www.debian.org |

Attachment: signature.asc
Description: Digital signature

Reply to: