[Mimedefang] Debian squeeze postfix mimedefang

[Michiel Brandenburg]

Hi all,

> FYI for Debian sendmail users, the same thing needed to be done on a
> system running "wheezy", e.g., add the following to
> `/etc/init.d/mimedefang':

I have seen this problem too, I have looked at the code and it seems 
that there is a delay between the creation of the socket (using 
smfi_setconn mimedefang.c line 2442) and exit of the parent process 
after daemonizing. Could it be that the smfi_setconn only indicates the 
intent to create the socket and does not do the actual socket creation 
itself ?  Just theorizing here mind you.

I seem to remember reading somewhere when this function fails, the only 
place you can check it is in the smfi_main function.  Might be that this 
is the actual place that this socket is created. If this is the case 
it's created after the fork this might explain the delay, and thus 
wheezy (my flavor) messes up with parallel booting assuming mimedefang 
is ready while it's still starting.  Sendmail (in my case) is then 
started and can not connect to the socket.

>      # Start mimedefang
>      printf "%-59s" "Starting $prog: "
>      rm -f $SOCKET>  /dev/null 2>&1
>      $PROGDIR/$prog -P $PID -R $LOOPBACK_RESERVED_CONNECTIONS \
>      <snip>
>      RETVAL=$?
>      if [ $RETVAL = 0 ] ; then
> +       #
> +       # To avoid a warning message when sendmail is started,
> +       # give some time to create the Milter socket file.
> +       #
> +       sleep 2

Might be better to add some sleeping loop here checking on the 
appearance of the socket, on some of my systems it appears in 1 sec 
others 2-3 seconds.  As a server might do all of it's init.d within 10 
sec .. adding 2 sec sleeping time seems horrible :)

A better fix might be to let the parent process exit only when the 
socket has been created, don't know if this is a wanted feature but it 
might be the best solution. A non-zero exit status can be returned if 
this socket does not appear in a certain time frame.  If the choice is 
made to change mimedefang.c it might also be best to move the waiting on 
the multiplexor being alive (it's checked 50 times at 3 sec intervals 
after the fork) so we can be sure all is ok before we tell the world all 
is well when in fact something failed. Not sure a connection attempt is 
made after entering smfi_main, but logging 'Multiplexor unresponsive - 
entering main loop anyway' seems to indicated that that case might fall 
into the bad category.

That or we can ask the libmilter ppl to keep trying to connect and not 
assume that the socket will never appear, not sure how that will work 
out though.

> As an additional item for Debian mimedefang/sendmail users, you may
> need to tweak the ownership of a couple of files:
I added smmsp to the defang group that seems to work too, no need to 
change the init.d script in my case.  Adding this user to the defang 
group may introduct security issues as the mail server can then read / 
write most of the internal mimedefang temp files, on the other hand the 
mailserver supplied mimedefang with the data.

Adding the mailserver user to the defang group allows postfix / sendmail 
configurations to use the same init.d script .. add postfix to defang 
group or add smmsp :)  Or run mimedefang as another user/group, my 
thoughts are to keep this out of the init.d scripting as there probably 
is no 100% correct way to do this for all platforms out there.

--
Michiel Brandenburg