687
edits
Changes
From SME Server
Jump to navigationJump to searchperldoc output for naughty
<span id="_top">[[Qpsmtpd#Plugins]]</span>
= [[#___top|NAME]] =
naughty - dispose of naughty connections
= [[#___top|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'''.
= [[#___top|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.
= [[#___top|DESCRIPTION]] =
Naughty provides the following:
== [[#___top|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.
== [[#___top|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.
== [[#___top|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.
== [[#___top|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.
= [[#___top|HOW TO USE]] =
Set the connection note ''naughty'' to the message you wish to send the naughty sender during rejection.
<pre> $self->connection->notes('naughty', $message);</pre>
This happens for plugins automatically if they use the $self->get_reject() method and have set ''reject naughty'' in the plugin configuration.
= [[#___top|CONFIGURATION]] =
== [[#___top|reject]] ==
<pre> naughty reject [ connect | mail | rcpt | data | data_post ]</pre>
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.
== [[#___top|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
== [[#___top|loglevel]] ==
Adjust the quantity of logging for this plugin. See docs/logging.pod
= [[#___top|EXAMPLES]] =
Here's how to use naughty and get_reject in your plugin:
<pre> 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 );
};</pre>
= [[#___top|AUTHOR]] =
<pre> 2012 - Matt Simerson - msimerson@cpan.org</pre>
<!-- Generated Sun Jul 16 09:19:14 EDT 2017 using
perldoc -T -ohtml /usr/share/qpsmtpd/plugins/naughty |pandoc -f html -t mediawiki |sed 1 i\\n\n\n<span id="_top">[[Qpsmtpd#Plugins]]</span> |sed -e s#</d.>##
-->
= [[#___top|NAME]] =
naughty - dispose of naughty connections
= [[#___top|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'''.
= [[#___top|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.
= [[#___top|DESCRIPTION]] =
Naughty provides the following:
== [[#___top|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.
== [[#___top|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.
== [[#___top|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.
== [[#___top|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.
= [[#___top|HOW TO USE]] =
Set the connection note ''naughty'' to the message you wish to send the naughty sender during rejection.
<pre> $self->connection->notes('naughty', $message);</pre>
This happens for plugins automatically if they use the $self->get_reject() method and have set ''reject naughty'' in the plugin configuration.
= [[#___top|CONFIGURATION]] =
== [[#___top|reject]] ==
<pre> naughty reject [ connect | mail | rcpt | data | data_post ]</pre>
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.
== [[#___top|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
== [[#___top|loglevel]] ==
Adjust the quantity of logging for this plugin. See docs/logging.pod
= [[#___top|EXAMPLES]] =
Here's how to use naughty and get_reject in your plugin:
<pre> 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 );
};</pre>
= [[#___top|AUTHOR]] =
<pre> 2012 - Matt Simerson - msimerson@cpan.org</pre>
<!-- Generated Sun Jul 16 09:19:14 EDT 2017 using
perldoc -T -ohtml /usr/share/qpsmtpd/plugins/naughty |pandoc -f html -t mediawiki |sed 1 i\\n\n\n<span id="_top">[[Qpsmtpd#Plugins]]</span> |sed -e s#</d.>##
-->
