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

naughty: POD additions

Browse Source
This commit is contained in:
Matt Simerson 2012-06-27 03:20:49 -04:00
parent eefb4ab823
commit bc793a87c7
1 changed files with 8 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

13
plugins/naughty
View File

@ -16,7 +16,7 @@ but my observations in 2012 suggest it makes no measurable difference whether
I disconnect during connect or rcpt. I disconnect during connect or rcpt.
Disconnecting later is inefficient because other plugins continue to do their Disconnecting later is inefficient because other plugins continue to do their
work, oblivious to the fact that the connection is destined for the bit bucket. work, oblivious to the fact that a connection is destined for the bit bucket.
=head1 DESCRIPTION =head1 DESCRIPTION
@ -31,7 +31,7 @@ Plugins like SpamAssassin and DSPAM can benefit from using naughty connections
to train their filters. to train their filters.
Since so many connections are from blacklisted IPs, naughty significantly Since so many connections are from blacklisted IPs, naughty significantly
reduces the processing time required for disposing of them. Over 80% of my reduces the resources required to disposing of them. Over 80% of my
connections are disposed of after after a few DNS queries (B<dnsbl> or one DB connections are disposed of after after a few DNS queries (B<dnsbl> or one DB
query (B<karma>) and 0.01s of compute time. query (B<karma>) and 0.01s of compute time.
@ -41,6 +41,8 @@ Instead of each plugin handling cleanup, B<naughty> does it. Set I<reject> to
the hook you prefer to reject in and B<naughty> will reject the naughty the hook you prefer to reject in and B<naughty> will reject the naughty
connections, regardless of who identified them, exactly when you choose. connections, regardless of who identified them, exactly when you choose.
For training spam filters, I<reject data_post> is best.
=head2 simplicity =head2 simplicity
Rather than having plugins split processing across hooks, they can run to Rather than having plugins split processing across hooks, they can run to
@ -55,7 +57,8 @@ deployment models.
When a user authenticates, the naughty flag on their connection is cleared. When a user authenticates, the naughty flag on their connection is cleared.
This is to allow users to send email from IPs that fail connection tests such This is to allow users to send email from IPs that fail connection tests such
as B<dnsbl>. Keep in mind that if I<reject connect> is set, connections will as B<dnsbl>. Keep in mind that if I<reject connect> is set, connections will
not get the chance to authenticate. not get the chance to authenticate. To allow clients a chance to authenticate,
I<reject mail> works well.
=head2 naughty =head2 naughty
@ -109,7 +112,7 @@ Here's how to use naughty and get_reject in your plugin:
my ($self, $transaction) = @_; my ($self, $transaction) = @_;
... do a bunch of stuff ... ... do a bunch of stuff ...
return DECLINED if is_okay(); return DECLINED if is_okay();
return $self->get_reject( $message ); return $self->get_reject( $message, $optional_log_message );
}; };
=head1 AUTHOR =head1 AUTHOR
@ -153,7 +156,7 @@ sub register {
sub naughty { sub naughty {
my $self = shift; my $self = shift;
my $naughty = $self->connection->notes('naughty') or do { my $naughty = $self->connection->notes('naughty') or do {
$self->log(LOGINFO, "pass, clean"); $self->log(LOGINFO, 'pass');
return DECLINED; return DECLINED;
}; };
$self->log(LOGINFO, "disconnecting"); $self->log(LOGINFO, "disconnecting");