Re: Ddclient sending emails on a Postfix server

On 12/12/16 20:03, Sven Vermeulen wrote:
> It's been a while that I did some Postfix work, which might be necessary to
> debug this properly. The socket is owned by ddclient, is it possible that
> "postdrop -r" input and/or output is redirected to a ddclient socket? From a
> quick Google ddclient is shown as a Perl client, so some code scanning might
> help to find out what the socket is about.

Yes, ddclient is one long perl script. I am not a perl diver myself but 
it is not difficult to track down the code. The "sub" routine "sendmail" 
uses the subroutine "pipecmd" to run /usr/bin/sendmail with command line 
parameters and a few lines of input. Pipecmd uses the open function, 
prefixing the command ("sendmail" in this case) with a pipe: open(*FD, 
"| sendmail"). Ddclient doesn't attempt to read stdout from the 
sendmail/postdrop call so presumably this is postdrop trying to read the 
pipe passed to it by sendmail?

Clearly sendmail is running in the ddclient domain (mta_sendmail_exec 
for some curious reason and not the sendmail interface) and presumably 
postdrop transitions to its own domain. This is where I think the 
problem lies and I am hoping it was my fault. At some point in trying to 
get sendmail to work I added 
"postfix_domtrans_user_mail_handler(ddclient_t)" but then found the 
answer was hiding in mta.if. This domtrans interface adds ddclient_t to 
the postfix_user_domtrans type attribute, which sesearch reveals to be 
one of the few ways of transitioning to the postfix_postdrop_t domain. 
That explains why postdrop has transitioned from sendmail (ddclient_t) 
and why it cannot access sendmail's pipe?

I am testing the policy without the domtrans call and with my fingers 
crossed.

Robert