GSoC 2008 dma enhancements

[Matthias Schmidt]

Hi,

* Max Lindner wrote:
> Hi out there!
> 
> I'm Max, a 25 year old graduate computer science student from germany.
> I finished my diploma thesis in April and held my final talk about my
> thesis the friday before. That's why I was nearly invisible since my
> accepted application. Besides computers I'm very keen on running,
> biking, climbing (and many other sports). I live in Erlangen, which is
> in Frankonia (Bavaria) where we have many little breweries and most of
> them produce very good beer :-) My nickname in #dragonflybsd is
> gisanka.

Beer sounds good :) Welcome aboard, Max.

> For the .forward support I planned to support any combination of the
> following 3 ways to redirect a message:
> 
> |/pipe/to/executable
> mailbox at remote.host
> !deliverdirekttomailbox

Yep, we need all these three items.  Especially the | support is
helpful as much people use procmail/spamassassin/$whatever to filter
mails.

> In order to read a users .forward file, the dma-process must be run as
> root, so it must be set setuid root. This would solve the problem
> which I read at the mailinglist the last week, where it was not
> possible to write a mail from non-root to non-root ootb.

If all stuff is careful written, I'm fine with dma setuid root, but IIRC
someone (Simon? Matt?) mentioned that they would prefer another
mechanism ...

> I would not run the dma process as a daemon. It should be sufficient
> if it runs as long as it tries to deliver a message and terminate
> after the last message was sent. I guess when dma is used on a host,
> then the mailsetup is a very tiny one (and mostly with a smarthost)
> and so there should be no need to listen on port 25 or have a
> queue-runner-daemon because there are not many mails to send.

Yeah, dma should not listen on any outgoing port.  If we would go that
way we'll end up with the same problems the big ones[tm] aka sendmail,
postfix etc have to deal with :)

> Things to care about:
> -make sure that dma reads only .forward and could not be used to read
> other files of another user
> -make sure that the input is sanitized when running as root
> -drop privileges asap during execution (if possible at all)
> -if mail is piped to executable, run the executable as user, not as root

Correct.

> Do you think I disregarded something? Is there anything to add to the
> list I should care about?

ATM not, but I'm sure we'll hit some things during the process :)

regards

	Matthias