NAME

naughty - dispose of naughty connections

SYNOPSIS

Rather than immediately terminating naughty connections, plugins can flag the connection and dispose of it later. Examples are dnsbl, karma, greylisting, resolvable_fromhost, SPF, and DKIM.

BACKGROUND

Historically, deferred rejection was based on the belief that malware will retry less if we disconnect after RCPT. Observations in 2012 suggest it makes no measurable difference when we disconnect.

Disconnecting early will block connections from your users who are roaming, or whose IP space is voluntarily listed by their ISP. Deferring rejection until after the remote has had the ability to authenticate allows RBLs to be safely used on port 25 and 587.

Some (much older) RFCs suggest deferring later.

For these and other reasons, a few plugins implemented deferred rejection on their own. By having naughty, other plugins can be much simpler.

DESCRIPTION

Naughty provides the following:

consistency

With one change to the config of naughty, all plugins can reject their messages at the preferred time. I use this feature for spam filter training. When setting up a new server, I use 'naughty reject data_post' until after dspam is trained. Once the bayesian filters are trained, I change to 'naughty reject data', and avoid processing the message bodies.

efficiency

After a connection is marked as naughty, subsequent plugins can detect that and skip processing. Plugins like SpamAssassin and DSPAM can benefit from using naughty connections to train their filters.

Since many connections are from blacklisted IPs, naughty significantly reduces the resources required to dispose 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.

simplicity

Rather than having plugins split processing across hooks, plugins can run to completion when they have the information they need, issue a reject naughty if warranted, and be done.

authentication

When a user authenticates, the naughty flag on their connection is cleared. This allows users to send email from IPs that fail connection tests such as dnsbl. Note that if reject connect is set, connections will not get the chance to authenticate. To allow clients a chance to authenticate, reject mail works well.

HOW TO USE

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() 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 inhibits spammers from detecting address validity.

reject_type [ temp | perm | disconnect ]

If the plugin that set naughty didn't specify, 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, $optional_log_message );
 };

AUTHOR

 2012 - Matt Simerson - msimerson@cpan.org

Qpsmtpd:naughty

Contents