byterazor/qpsmtpd
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Get rid of grey_timeout and 'white' clients

Browse Source 
These are noops:  clients that retry before grey_timeout is exceeded and
clients that retry after grey_timeout is exceeded all pass greylisting until
expired by white_timeout.
This commit is contained in:
Jared Johnson 2014-12-28 21:16:34 -06:00
parent c01cdffb08
commit eb0ff1fe98
2 changed files with 5 additions and 32 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

25
plugins/greylisting
View File

@ -33,9 +33,9 @@ How that works is best explained by example:
A new connection arrives from the host shvj1.jpmchase.com. The sender is
chase@alerts.chase.com and the recipient is londonwhale@example.com. This is
the first connection for that triplet so the connection is deferred for
I<black_timeout> minutes. After the timeout, but before the I<grey_timeout>
elapses, shvj1.jpmchase.com retries and successfully delivers the mail. For
the next I<white_timeout> days, emails for that triplet are not delayed.
I<black_timeout> minutes. After the timeout elapses, shvj1.jpmchase.com retries
and successfully delivers the mail. For the next I<white_timeout> days, emails
for that triplet are not delayed.
The next day, shvj1.jpmchase.com tries to deliver a new email from
alerts@alerts.chase.com to jdimon@example.com. Since this triplet is new, it
@ -73,14 +73,6 @@ e.g. to allow per-recipient logging. Default: 0.
The initial period during which we issue DENYSOFTs for connections from an
unknown (or timed out) 'connection triplet'. Default: 50 minutes.
=head2 grey_timeout <timeout_seconds>
The subsequent 'grey' period, after the initial black blocking period,
when we will accept a delivery from a formerly-unknown connection
triplet. If a new connection is received during this time, we will
record a successful delivery against this IP address, which whitelists
it for future deliveries (see following). Default: 3 hours 20 minutes.
=head2 white_timeout <timeout_seconds>
The period after which a known connection triplet will be considered
@ -180,8 +172,9 @@ my $VERSION = '0.12';
my $DENYMSG = "This mail is temporarily denied";
my %PERMITTED_ARGS = map { $_ => 1 } qw(per_recipient remote_ip sender
recipient black_timeout grey_timeout white_timeout deny_late db_dir
recipient black_timeout white_timeout deny_late db_dir
nfslock p0f reject loglevel geoip upgrade );
$PERMITTED_ARGS{grey_timeout} = 1; # Legacy argument now ignored
my %DEFAULTS = (
remote_ip => 1,
@ -189,7 +182,6 @@ my %DEFAULTS = (
recipient => 0,
reject => 1,
black_timeout => 50 * 60, # 50m
grey_timeout => 3 * 3600 + 20 * 60, # 3h:20m
white_timeout => 36 * 3600 * 24, # 36 days
nfslock => 0,
p0f => undef,
@ -389,13 +381,6 @@ sub greylist {
return $self->cleanup_and_return();
}
# Grey IP - accept unless timed out
elsif ( $self->now - $ts < $config->{grey_timeout} ) {
$self->db->set( $key, sprintf $fmt, $self->now, $new, $black, 1 );
$self->log(LOGWARN, "pass: updated grey->white");
return $self->cleanup_and_return(DECLINED);
}
$self->log(LOGWARN, "pass: timed out (grey)");
return $self->cleanup_and_return(DECLINED);
}

12
t/plugin_tests/greylisting
View File

@ -256,18 +256,6 @@ sub test_greylist {
is( $self->rc( $self->greylist( $self->transaction, $sender, $rcpt ) ),
'DENYSOFT: This mail is temporarily denied',
're-greylisted 36 days later' );
$self->connection->remote_ip('4.3.2.1');
$mocktime = $start;
is( $self->rc( $self->greylist( $self->transaction, $sender, $rcpt ) ),
'DENYSOFT: This mail is temporarily denied',
'Initial connection attempt greylisted for new IP' );
$mocktime = $start + 36 * 3600 * 24 - 60;
is( $self->rc( $self->greylist( $self->transaction, $sender, $rcpt ) ),
# 'DENYSOFT: This mail is temporarily denied',
# 'New IP still greylisted when greylist_timeout window is missed' );
'DECLINED',
"New IP allowed for 36 days, just like 'white' clients (huh?)" );
}
{