Wietse -
Thank you for explaining your position on this in so much detail! You
definitely have a pretty strong and reasonable opinion here. I was
essentially after mail filtering capabilities analogous to those of a
network packet filter and I felt that those would reasonably fit into
Postfix pr
Solar Designer:
> On Thu, Nov 17, 2011 at 06:39:29AM -0500, Wietse Venema wrote:
> > Solar Designer:
> > > Does this mean you're going to implement it? Sounds great if so. And
> > > the default action feature, please - I'd use them together.
> >
> > ACCEPT in header_checks == turn off header che
On Thu, Nov 17, 2011 at 06:39:29AM -0500, Wietse Venema wrote:
> Solar Designer:
> > Does this mean you're going to implement it? Sounds great if so. And
> > the default action feature, please - I'd use them together.
>
> ACCEPT in header_checks == turn off header checks for this message.
Right
Solar Designer:
> On Wed, Nov 16, 2011 at 08:02:03PM -0500, Wietse Venema wrote:
> > Solar Designer:
> > > OK. I took a look at the code and I see those difficulties now. How
> > > about something like the attached patch? It's totally untested other
> > > than that it compiles, and it's probably
On Wed, Nov 16, 2011 at 08:02:03PM -0500, Wietse Venema wrote:
> Solar Designer:
> > OK. I took a look at the code and I see those difficulties now. How
> > about something like the attached patch? It's totally untested other
> > than that it compiles, and it's probably wrong (especially conside
Solar Designer:
> On Wed, Nov 16, 2011 at 04:11:17PM -0500, Wietse Venema wrote:
> > As I explained in a different response, there is no "this table"
> > concept outside the low-level (pcre, hash, etc.) table itself. At
> > higher levels, there is a lookup result without source attribution.
> >
>
On Wed, Nov 16, 2011 at 04:11:17PM -0500, Wietse Venema wrote:
> As I explained in a different response, there is no "this table"
> concept outside the low-level (pcre, hash, etc.) table itself. At
> higher levels, there is a lookup result without source attribution.
>
> Considering Postfix's dri
Solar Designer:
> Wietse,
>
> Thank you for your comments and explanation!
>
> On Wed, Nov 16, 2011 at 01:04:10PM -0500, Wietse Venema wrote:
> > I must confess that I no longer understand what the purpose is of
> > ACCEPT in header_checks, if the purpose is other than skipping
> > all further lo
Wietse,
Thank you for your comments and explanation!
On Wed, Nov 16, 2011 at 01:04:10PM -0500, Wietse Venema wrote:
> I must confess that I no longer understand what the purpose is of
> ACCEPT in header_checks, if the purpose is other than skipping
> all further lookups of all header_checks table
Solar Designer:
> On Wed, Nov 16, 2011 at 11:48:34AM -0500, Wietse Venema wrote:
> > ACCEPT is simply to explain only if it disables all further checks.
> > Things become messy otherwise.
>
> Maybe we should call it other than ACCEPT, then - to make it clear that
> other restrictions elsewhere may
Solar Designer:
> On Wed, Nov 16, 2011 at 10:39:00AM -0600, /dev/rob0 wrote:
> > On Wednesday 16 November 2011 10:06:36 Solar Designer wrote:
> > > I admit I'm not familiar with the code and I haven't tried to
> > > implement ACCEPT yet, but aren't DISCARD and REJECT also
> > > whole-message action
On Wed, Nov 16, 2011 at 11:48:34AM -0500, Wietse Venema wrote:
> ACCEPT is simply to explain only if it disables all further checks.
> Things become messy otherwise.
Maybe we should call it other than ACCEPT, then - to make it clear that
other restrictions elsewhere may still reject the message?
On Wed, Nov 16, 2011 at 10:39:00AM -0600, /dev/rob0 wrote:
> On Wednesday 16 November 2011 10:06:36 Solar Designer wrote:
> > I admit I'm not familiar with the code and I haven't tried to
> > implement ACCEPT yet, but aren't DISCARD and REJECT also
> > whole-message actions? Is ACCEPT somehow very
On Wednesday 16 November 2011 10:39:00 I wrote:
> A single reject action anywhere before acceptance causes the mail
> to be rejected. Numerous permit (or dunno) actions are required
> for acceptance; one per restriction stage, one per each header
> evaluated in header_checks(5), one for each line i
Solar Designer:
[on whitelisting]
> > State, including what message the line belongs to, is not saved
> > between lines.
> >
> > Adding any kind of whole-message action would require major changes
> > to the way cleanup works, and is unlikely to happen anytime soon.
>
> I admit I'm not familiar w
On Wednesday 16 November 2011 10:06:36 Solar Designer wrote:
> On Wed, Nov 16, 2011 at 09:36:21AM -0600, Noel Jones wrote:
> > If you need more fine-grained control, use eg. SpamAssassin.
>
> I don't feel that whitelisting of PGP-encrypted messages is more
> fine-grained than the kind of blacklist
On Wed, Nov 16, 2011 at 09:36:21AM -0600, Noel Jones wrote:
> On 11/16/2011 8:32 AM, Solar Designer wrote:
> > I'd like to have an ACCEPT action for *header_checks and body_checks.
> > This was requested before:
> >
> > http://archives.neohapsis.com/archives/postfix/2005-02/1116.html
> >
> > I've
On 11/16/2011 8:32 AM, Solar Designer wrote:
> Hi,
>
> I'd like to have an ACCEPT action for *header_checks and body_checks.
> This was requested before:
>
> http://archives.neohapsis.com/archives/postfix/2005-02/1116.html
>
> I've read the replies in that thread, and I continue to think that
>
Hi,
I'd like to have an ACCEPT action for *header_checks and body_checks.
This was requested before:
http://archives.neohapsis.com/archives/postfix/2005-02/1116.html
I've read the replies in that thread, and I continue to think that
adding an ACCEPT action for *header_checks and body_checks is a
19 matches
Mail list logo
