F20 System Wide Change: No Default Sendmail

[Lennart Poettering]

On Mon, 22.07.13 19:19, Miloslav Trmač (mitr at volny.cz) wrote:

> On Mon, Jul 22, 2013 at 7:00 PM, Lennart Poettering
> <mzerqung at 0pointer.de> wrote:
> > On Mon, 22.07.13 18:43, Miloslav Trmač (mitr at volny.cz) wrote:
> >
> >> On Mon, Jul 22, 2013 at 6:36 PM, Lennart Poettering
> >> <mzerqung at 0pointer.de> wrote:
> >> > On Fri, 19.07.13 20:22, Miloslav Trmač (mitr at volny.cz) wrote:
> >> >
> >> >> On Fri, Jul 19, 2013 at 8:16 PM, Matthew Miller
> >> >> <mattdm at fedoraproject.org> wrote:
> >> > Where "expected to do" means effectively route it to /dev/null?
> >>
> >> It's actually less similar to /dev/null than log files are - log files
> >> are rotated and deleted, mail stays in the mail boxes until explicitly
> >> deleted (or space runs out).
> >
> > Well, so it's even a DoS... Just find some trigger to generate a lot of
> > mails to root and /var will eventually fill up, even beyond those 10%
> > reserved for root, since well, mail to root is accounted to root...
> 
> My concern about this proposal doesn't actually depend on local
> delivery, it _could_ go to /dev/null by default for all I care.

What a crappy API is that?

> I'll note, however, that "this is a DoS" is rarely a convincing
> argument - the only practical way to combat a DoS is to impose some
> kind of limit, which is just a DoS of a different kind.  You get to
> choose _what_ kinds of DoS your computer will be subject to, but with
> finite CPU power and storage you can't avoid DoS situations.

The point I am trying to make is that if you have something that is
vulnerable to a DoS attack you need to have a strategy to handle
that. You need to keep the attack local, isolated as much as you can
from the rest of the system and other clients. A strategy of "hey, yeah,
let's queue this all up and allow unprivileged clients to bring down the
entire system by easily flooding /var" is a bad strategy, an
embarrassingly bad one. It's a DoS that is the opposite of local.

> And, philosophically, silently losing data is generally much worse
> than requiring manual intervention for the system to run when space
> runs out.  (Not that the mails we sent by default are _that_ valuable,
> though.)
>     Mirek

If we drop data we definitely always need to keep track of that and
account it, no doubt. (journald does keep track of messages dropped via
per-service/per-priority ratelimit, and it will tell you how far back
history in the logs reach)

Lennart

-- 
Lennart Poettering - Red Hat, Inc.