The patch below fixes many errors of the form:
*** WARNING: line containing nothing but whitespace in paragraph at line 37 in file writing.pod
*** WARNING: line containing nothing but whitespace in paragraph at line 40 in file writing.pod
There are also a couple of minor typo-fixes.
>> However, I'm back to seeing the connection processes being left behind,
>> despite an explicit quit from the remote host.
> It looks to me as though qpsmtpd should have started a new process
> group with the parent process, but hasn't. Or the developer assumed
> that qpsmtpd would be set up as leader of a process group, but it
> isn't in this circumstance.
Signed-off-by: Robert <rspier@pobox.com>
While writing a plugin for our new spamfilter implementation I noticed
some minor error in the documentation. From the documentation it
sounds like the hook_ok and hook_deny hooks get the previous hook as
parameter.. The truth is: it is the previous plugin.
Allows qpsmtpd-prefork to listen on multiple address/port combinations
simultaneously, based on the corresponding implementation in forkserver.
Signed-off-by: Robert <rspier@pobox.com>
forkserver uses --listen-address to specify the listening socket address, while
prefork uses --interface. Add the former as an alias for the latter, for
consistency & ease of integration. The two still aren't commandline-compatible,
but they're fairly close.
Signed-off-by: Ask Bjørn Hansen <ask@develooper.com>
QP's connection to spamd unnecessarily persists beyond the run of the
spamassassin plugin itself. This closes the socket as soon as we're
finished using it.
Signed-off-by: Ask Bjørn Hansen <ask@develooper.com>
from Tom Callahan <anomaly@abducted.us>
(reformatted by Robert)
Signed-off-by: Robert <rspier@pobox.com>
Signed-off-by: Ask Bjørn Hansen <ask@develooper.com>
Improve Qpsmtpd::Transaction::add_recipient syntax
Update Qpsmtpd::Transaction::add_recipient to use slightly clearer
language, and add 'if $rcpt' to prevent undef recipients from
being added -- in this case, the '@_ and' syntax allowing this set
method to set undef is undesirable, since you shouldn't be adding undef as
a recipient.
Signed-off-by: Ask Bjørn Hansen <ask@develooper.com>
import plugins/connection_time from SVN's contrib. Changes:
* perltidy run
* add one optional parameter: log level of the message, defaults
to LOGNOTICE (same as in SVN)
* updated docs
* use magic hooking with hook_rcpt
* add note about regexes being eval()ed => trusted users only
Signed-off-by: Ask Bjørn Hansen <ask@develooper.com>
Qpsmtpd::Connection::notes() and Qpsmtpd::Transaction::notes() have
identicaly functionality; however, the POD documentation for Connection
notes is fairly brief while the documentation for Transaction notes is
longer and more helpful. This updates the Connection notes documention
to be consistent with its Transaction counterpart.
Qpsmtpd Connection and Transaction objects support notes() methods which
are conventionally used to pass data between plugins. This adds the
same functionality to Address objects. This should make it easier for
plugins to begin supporting message handling based on per-user
configuration directives.
Signed-off-by: Ask Bjørn Hansen <ask@develooper.com>
plugins/virus/kavscanner calls $transaction->add_recipient($_->address)
on a list of Mail::Address objects, but add_recipient() clearly
documents that it takes Qpsmtpd::Address (or compatible) objects, not
strings. This is a bit of a drive-by fix inspired by a grep through the
codebase for calls to add_recipient().
This reverts commit ea86b9fdb2.
Jared said...
I originally considered these functionally identical, but they are
not. The new code, called with, say, $txn->notes('discard',undef),
would result in evaluation as if it were a 'get' method rather than
setting the 'discard' note to undef. That seems quite dangerous. I
suggest either reverting the language back to the '@_ and' model, or
else doing something like:
non-premium customers or something like that such as (3) annoying your
customers, if you are in a position to actually want to do that
Signed-off-by: Robert <rspier@pobox.com>
