From: Aaron Wolfe (aawolfegmail.com)
Date: Tue May 13 2008 - 18:51:54 CDT

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

On Tue, May 13, 2008 at 4:21 AM, Stefan Förster <citeincertum.net> wrote:

> * Aaron Wolfe <aawolfegmail.com> wrote:
> > On Sat, May 10, 2008 at 8:09 PM, Wietse Venema <wietseporcupine.org>
> wrote:
> > > I don't like dropping the shields down because some service dies.
> > >
> > > It causes people to lose confidence in Postfix, because it results in
> > > unpredictable behavior. There is enough bad software on the Internet.
> > >
> >
> >
> > Would it be possible (and make sense) to have an option to specify
> somehow
> > that a particular policy filter is non essential and it's failure should
> be
> > considered equivalent to "DUNNO" or similar?
> >
> > I have had more than one situation where a daemon failed and the
> resulting
> > mail delays were unfortunate and really unnecessary as the mail system
> > (besides the policy filter) was working fine. In our case, dropping
> this
> > filter from our UCE fighting checks would not have resulted in "shields
> > down" or more spam, just extra work for the more resource intensive
> checks
> > later on in the chain.
>
> This might be a dumb question, but if your policy declares a service
> involved in sending or receiving mail as "Non critical", why add it in
> the first place?
>
> For most sites, there is a strict "path" that incoming or outgoing
> mail has to follow. If it's not completely unacceptable for site
> owners to skip some of the steps on that path, then there is a flaw in
> this sites policy.
>

In regard to spam fighting, I consider lots of the services we run to be
less than critical, and in fact we allow users to decide for themselves
whether or not to use some of them. Many of the filtering techniques we use
are there to reduce the load on more resource hungry checks later on, not
because we can't detect the spam without them. For example, if our
greylisting filter, great... but if it doesn't work I really don't care. We
did fine before we had it, and I would prefer mail to continue coming in.

In the battle between spammers and the rest of the world, new ideas are
common and the tools to implement these ideas are sometimes written in a
rush. There is a benefit to using these tools, both in reducing spam
(hopefully) and in learning more about how an idea works in the real world.
Unfortunately there is also risk: risk of false positives because the idea
isn't yet refined (or is just a bad idea), and risk of failure because the
software to implement the idea isn't mature and well tested.

Compared to all the other services I get involved in managing, my postfix
configuration changes much more often. Apache, bind, etc really don't need
adjustment unless there is a security problem or a new requirement from our
programmers. But mail config and the tools involved in mail processing
change simply because spam changes and spam fighting changes.

My users consider mail broken when they don't get mail, but they also
consider it broken when they get spam. So, I am torn often between
implementing a tool that might help make users happy and the consquences
that might make them sad. To mitigate the complaints, it is nice to keep
mail "working" as best we can while learning more about these tools.

> Besides, you can use a greylisting milter if you want this kind of
> behaviour.
>
>
I know this all started as a greylisting problem, but really the ideas
discussed apply to any type of service that isn't critical. Maybe all of
these should be implemented as milters. I think there are milter to do just
about anything you can imagine. Using milters simply because you want a
"dunno on failure" kind of behavior is certainly an option but it feels kind
of wierd.

>
> Cheers
> Stefan
>

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]