Jared Johnson wrote:
>> _Every_ filter reject _must_ result in a real reject back to the sender
>> (by inline 5xx error). In this way we can ensure that someone is shown
>> that it didn't get through, and we provide them with instructions on
>> what to do to remediate a FP. By 250'ing the email,
_Every_ filter reject _must_ result in a real reject back to the sender
(by inline 5xx error). In this way we can ensure that someone is shown
that it didn't get through, and we provide them with instructions on
what to do to remediate a FP. By 250'ing the email, and eliding a
recipient, you're
David Nicol wrote:
> You have to treat the whole address as the key to the preference
> looker-upper, as SMTP allows recipients with multiple domains in the
> same transaction. The latest release of tipjar::MTA (outbound) for
> example organizes multiple recipients after an MX lookup instead of b
Jared Johnson wrote:
> When we get all the way to DATA with ex. 2 recips, scan the message, and
> one accepts it while the other wants to reject, we say 250 and then
> quietly discard the second recip, effectively turning his 'reject'
> preference into an 'ignore'.
If we were going to go down
On Tue Jan 06, 2009 at 11:14:32 -0600, David Nicol wrote:
> I'm issuing DENYSOFT on recipients after the first when there is going
> to be data analysis required by either the first or by the new recipient
> to make an accept/reject decision.
How well does that work in practise? I've consid
On Mon, Jan 5, 2009 at 3:11 PM, Jared Johnson wrote:
> 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
>>
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
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
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: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
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
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.
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
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::
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, 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
>
> 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
On Sun, 2009-04-01 at 06:41 -0800, Ask Bjørn Hansen wrote:
> I'd like us to move towards doing a "proper" standard-
> ish install as the default.
You need a post-install configuration tool (script to start) as well.
--
--gh
19 matches
Mail list logo
