[gsoc] dma(8) status update

[Max Lindner-4]

Hi!

I was asked to do a status report, so here it is:

-.forward-support works
-smarthost handling was improved, so only one connection is used per
message, not one connection per receipient

todo:

-cram-md5 authentication for smarthosts

The patch can be found here:
http://wwwcip.informatik.uni-erlangen.de/~simxlind/dma-dotforward.patch

If you are interested, I would be glad to hear some opinions regarding
my approach.

Regards,
Max

[Simon 'corecode' Schubert]

Max Lindner wrote:

> Hi!
>
> I was asked to do a status report, so here it is:
>
> -.forward-support works
> -smarthost handling was improved, so only one connection is used per
> message, not one connection per receipient
>
> todo:
>
> -cram-md5 authentication for smarthosts
>
> The patch can be found here:
> http://wwwcip.informatik.uni-erlangen.de/~simxlind/dma-dotforward.patch
>
> If you are interested, I would be glad to hear some opinions regarding
> my approach.

Good work!  Could you describe on a high level how you handle .forward
and smarthost, especially regarding security?

thanks
   simon

[Max Lindner-4]

2008/8/9 Simon 'corecode' Schubert <corecode@...>:

> Good work!  Could you describe on a high level how you handle .forward and
> smarthost, especially regarding security?

Of course!

.forward:

dma runs as root and splits itself up into 3 branches now:

-the old codebase, which drops privileges to user nobody / group mail
-a process for reading an users .forward (the function
dotforwardhandler), which forks for every file to read and drops
privileges to that user before reading.
-a process for writing an users mailbox/executing the pipe for
delivering the mail (the function write_to_local_user), which forks
for every mail to deliver and drops privileges to that user before
open the file/pipe

The communication between the 3 branches is done via two socketpairs,
one socketpair for each new branch. In order to prevent concurring
communication, it is synchronised with one semaphore each.

The new processes terminate themselves as soon as every mail which was
enqeued was sent out or bounced. This is signaled by another semaphore
which is incremented before delivery starts and decremented after the
mail was successfully sent or written or the bounce was generated and
delivered.

smarthost-delivery:

for implementing the new smarthost delivery, I use the new function
deliver_smarthost. While the function deliver takes one qitem a time,
the deliver_smarthost function takes a queue. This queue is generated
during go_background and is the main queue with having removed the
local receipients.
This queue is given to the deliver_remote function, which sends one
"RCPT TO: xy@..." for each qitem. Depending on the returning
status code (accept, temporary error, permanent error) the qitem is
copied to one of 3 other queues. These 3 queues are processed again in
deliver_smarthost after completing the deliver_remote function. Sent
qitems are deleted, temporary failed items are tried again and
permanent failed items are bounced.

I hope this helps. Regarding security I tried to run as little code as
possible as root, use privilege separation and tried not to disregard
anything which can lead to a buffer overflow. Do you have additional
suggestions?

Regards,
Max

[Matthias Schmidt-12]

Hi,

* Max Lindner wrote:

> Hi!
>
> I was asked to do a status report, so here it is:
>
> -.forward-support works
> -smarthost handling was improved, so only one connection is used per
> message, not one connection per receipient
>
> todo:
>
> -cram-md5 authentication for smarthosts
>
> The patch can be found here:
> http://wwwcip.informatik.uni-erlangen.de/~simxlind/dma-dotforward.patch

Good work, Max!  Rock on with the remaining things :)

> If you are interested, I would be glad to hear some opinions regarding
> my approach.

If anybody is using dma(8) or has some spare time, give Max's patches a
try and report bugs/patches/$whatever to bugs@.  I'm sure Max has
currently no time to take care of the reports (some SoC work left), but if
they are registered in the tracker, they won't get lost.

Regards

        Matthias