https://github.com/smtpd/qpsmtpd/pull/24
Instead of zombies, undead, and a reaper, the plugin has been renamed
'naughty'.
NAME
naughty - dispose of naughty connections
BACKGROUND
Rather than immediately terminating naughty connections, plugins often
mark the connections and dispose of them later. Examples are dnsbl,
karma, greylisting, resolvable_fromhost and SPF.
This practice is based on RFC standards and the belief that malware
will retry less if we disconnect after RCPT. This may have been true,
and may still be, but my observations in 2012 suggest it makes no
measurable difference whether I disconnect during connect or rcpt.
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.
DESCRIPTION
Naughty provides the following:
efficiency
Naughty provides plugins with an efficient way to offer late
disconnects. It does this by allowing other plugins to detect that a
connection is naughty. For efficiency, other plugins should skip
processing naughty connections. Plugins like SpamAssassin and DSPAM
can benefit from using naughty connections to train their filters.
Since so many connections are from blacklisted IPs, naughty
significantly reduces the processing time required for disposing of
them. Over 80% of my connections are disposed of after after a few DNS
queries (dnsbl or one DB query (karma) and 0.01s of compute time.
naughty cleanup
Instead of each plugin handling cleanup, naughty does it. Set reject to
the hook you prefer to reject in and naughty will reject the naughty
connections, regardless of who identified them, exactly when you
choose.
simplicity
Rather than having plugins split processing across hooks, they can run
to completion when they have the information they need, issue a reject
naughty if warranted, and be done.
This may help reduce the code divergence between the sync and async
deployment models.
authentication
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 as dnsbl. Keep in mind that if reject connect is
set, connections will not get the chance to authenticate.
naughty
<naughty> provides a a consistent way for plugins to mark connections
as naughty. Set the connection note naughty to the message you wish to
send the naughty sender during rejection.
$self->connection->notes('naughty', $message);
This happens for plugins automatically if they use the
$self->get_reject( $message ) method and have set 'reject naughty' in
the plugin configuration.
CONFIGURATION
reject
naughty reject [ connect | mail | rcpt | data | data_post ]
The phase of the connection in which the naughty connection will be
terminated. Keep in mind that if you choose rcpt and a plugin (like
rcpt_ok) runs first, and rcpt_ok returns OK, then this plugin will not
get called and the message will not get rejected.
Solutions are to make sure naughty is listed before rcpt_ok in
config/plugins or set naughty to run in a phase after the one you wish
to complete. In this case, use data instead of rcpt to disconnect
after rcpt_ok. The latter is particularly useful if your rcpt plugins
skip naughty testing. In that case, any recipient is accepted for
naughty connections, which prevents spammers from detecting address
validity.
reject_type [ temp | perm | disconnect ]
What type of rejection should be sent? See docs/config.pod
loglevel
Adjust the quantity of logging for this plugin. See docs/logging.pod
EXAMPLES
Here's how to use naughty and get_reject in your plugin:
sub register {
my ($self,$qp) = shift, shift;
$self->{_args} = { @_ };
$self->{_args}{reject} ||= 'naughty';
};
sub connect_handler {
my ($self, $transaction) = @_;
... do a bunch of stuff ...
return DECLINED if is_okay();
return $self->get_reject( $message );
};
AUTHOR
2012 - Matt Simerson - msimer...@cpan.org
