On Mon, 2009-05-01 at 08:29 -0500, Adam Prime wrote:
> set up a basic
> (extendable and documented) configuration.
AFAIK, Makefile.PL (ExtUtils::MakeMaker) is not designed to do this
although it is probably possible.
It should be easy/ier with Build.PL (Module::Build, iirc) but I don't
think th
Robert Spier wrote:
So: Patches to improve Makefile.PL and a standard install are welcome.
Do we want to end up somewhere where Makefile.PL is required?
Personally, I like that the untar and run is the default.
-R
Shouldn't it be possible to have both options work? Perhaps the
Makefile cou
Adam Prime wrote:
> The default config probably isn't going to be (and shouldn't be IMO)
> that useful to almost everyone on this list. To my mind, it should be
> 'a drop in replacement for qmail', which to me reads that at it's base,
> it accepts mail, and delivers it locally.
That could be
Guy Hulbert wrote:
> On Mon, 2009-05-01 at 08:29 -0500, Adam Prime wrote:
>> set up a basic
>> (extendable and documented) configuration.
>
> AFAIK, Makefile.PL (ExtUtils::MakeMaker) is not designed to do this
> although it is probably possible.
>
> It should be easy/ier with Build.PL (Module::
It does certainly seem like QP is not used as a drop-in replacement for
qmail nearly so much as it's used as platform representing one element
of a larger anti-spam toolbox. That's how we use it here. It is a
shame that many of the tasks that people need QP to do, they can't do
with vanilla Q
On Mon Jan 05, 2009 at 10:13:24 -0500, Chris Lewis wrote:
> It's entirely possible, and indeed quite easy to do a "full install"
> with a stock Makefile.PL.
Indeed, I do the same thing. (Although I make a local Debian package
and push that out via CFEngine.)
> The real issue is what, precis
Steve Kemp wrote:
The real issue is what, precisely, should a "generic default qpsmtpd"
installation _do_ precisely?
Yes, that's the key. To be useful it should be configured for the
local environment. That might just be the standard rcpthost plugin
or it might mean local changes too.
Jared Johnson wrote:
> I don't imagine that this idea
> of having everything wait for DATA will be adopted: it limits the
> usefulness of plugins that could have rejected earlier, and in my mind
> it doesn't really simplify the problem much.
I'm not really suggesting that it be "adopted" in tha
Guy Hulbert wrote:
On Mon, 2009-05-01 at 08:29 -0500, Adam Prime wrote:
AFAIK, Makefile.PL (ExtUtils::MakeMaker) is not designed to do this
although it is probably possible.
It should be easy/ier with Build.PL (Module::Build, iirc) but I don't
think there is a standard method.
You can do anyth
On Mon Jan 05, 2009 at 10:56:42 -0500, Chris Lewis wrote:
> Eg: We hold off issuing 550s until the DATA transaction completes. This
> means that all filtering plugins have have a mutually agreed to place to
> stick their results, know what to check before wasting time on redundant
> filtering whe
Chris Lewis wrote:
I'm not really suggesting that it be "adopted" in that sense. But what
would make sense is to have each plugin operating to a common model for
whether filtering is on, deciding when to reject, logging, reason
reporting etc, where "don't reject until after DATA" could be a
conf
On Mon, 5 Jan 2009 15:11:06 -0600
Jared Johnson wrote:
> Chris Lewis wrote:
> > # I synthesize my own sessionid. Whatever happened to this in core?
> > my $session = $transaction->notes('sessionid');
>
> Another opportunity to improve core ;)
It was removed, because it had troubles on -pref
12 matches
Mail list logo
