2022.10.30

Sendmail::PMilter - README.1.23
===============================

Any problems, at any stage, please let me know.

The tests should all pass.  They do here.

Sendmail::PMilter is in routine use on a live Sendmail server at my
place of business.  At present it uses only the prefork dispatcher.

In the last few months several Postfix users have admitted to using
Sendmail::PMilter.  I hope this trend continues.  It should just work
but please let me know if you have any problems.

The volumes of mail which Sendmail::PMilter V1.2x has processed for me
are, so far, tiny.  Typically, including all the rejected messages, a
few hundred messages per day.  It's probably time now, cautiously, to
increase the volume of messages which Sendmail::PMilter processes.

Those of you who run servers which are busier than mine are especially
welcome to try Sendmail::PMilter.  Again, if you wish, it can be in a
logging-only configuration.

If you're inexperienced with Perl milters, and want to have a go but
are not sure how to proceed, please let me know.  I'll try to help as
much as I can.  Once you get the hang of them, I think you'll wonder
how you ever managed without them.

Dispatchers
===========

There are several different ways to handle concurrent mail processes.
These mechanisms are implemented by dispatchers, one for each of four
mechanisms: Prefork, Postfork, Sequential and Threaded.  In the three
years that I've been using this module (I spent the first six months
finding issues, the next two and a half years fixing them) I have only
seriously used the 'prefork' mechanism.  At first I dabbled, briefly,
with the threaded dispatcher.  It blew up horribly, so instead I used
the prefork dispatcher.  After a little cleanup it's been fine.  Later
I found some patches for the threaded dispatcher published, which I've
included in the V1.2x code, but since then I haven't back-tracked to
try the threaded (nor any other) dispatcher.  Like testing on higher
throughput servers, testing the dispatchers is another area where I'd
be very grateful for some input from other users.

Other areas:
============

Documentation: if you think anything is wrong, is missing, could be
made clearer, needs more examples, you name it - please let me know.

----

examples: The existing examples are as I found them.  I plan to create
sample milters which I hope will be useful as templates for those who
want to hit the ground running.

----

Is anyone using the FLAGS argument to register()?  If not I'll drop it
but I can easily keep it around for posterity.  For fine-grained flags
control I propose to add a hashref, so that if you don't need all the
per-connection negotiation features you could just say something like

$milter->register(
	NAME,
	{ CALLBACKS },
	{ protocol_flags => $pflags, action_flags => $aflags }
);

----

Does anyone want the setdbg() and settimeout() methods back?  These
undocumented methods were in the Sendmail::Milter which was provided
by Sendmail::PMilter V1.00, but as Sendmail::Milter is no longer part
of this package they are not now provided.  They did nothing anyway.


Future development:
===================

All suggestions for improvements will gratefully be received.

Code some of it in XS and compare benchmarks?  As yet I have little
idea of the CPU cycle consumption of this pure Perl implementation of
the Sendmail <-> milter interface.  I haven't spent a lot of time on
it because I'm using it with milters which are vastly more hungry for
resources than the interface.  If you make any measurements please do
let me know what you find.

To contact me:
==============

Less than 2% of the attempts to send mail to my domains are genuine.
For this reason my PAUSE and other list addresses won't accept mail
from anything but the respective list servers.  Other mail is very
unforgivingly filtered by a Perl milter.

If you want to contact me it's probably best to use the CPAN issue
tracking system:

https://rt.cpan.org/Public/Dist/Display.html?Name=Sendmail-PMilter.

If you and I need to exchange more than a couple of messages I'll be
very happy to tweak the filter rules if necessary.
