On Thu, 17 Jan 2013, Tracy Wise wrote:
> In my php.ini, sendmail path is "/usr/sbin/sendmail -t -i" HOWEVER I
> noticed that on my system "/usr/sbin/sendmail" isn't actually sendmail.
> It's an alias pointing to "/etc/alternatives/mta", which in turn points
> to "/usr/sbin/sendmail.postfix". So I assume PHP is actually using
> sendmail.postfix. (And actually I could see Postfix in the headers of
> emails sent out when it was working before I installed OpenDKIM.) But
> if it matters, let me also point out the following:
sendmail.postfix is likely a program that accepts mail on stdin in the
same way sendmail itself does. It's a tool for adding something to the
queue outbound. It's provided as part of postfix so that it can be a
drop-in replacement for legacy code that used that sendmail interface.
> Okay so I think my problem relates to one or both of the following:
>
> 1. Something to do with interference from sendmail (but please be sure
> you understand what I explained about my /usr/sbin/sendmail actually being an
> alias for /usr/sbin/sendmail.postfix so maybe that's not the problem,
> *shrug*).
It's possible that they are conflicting, but it seems unlikely to me that
installation of opendkim created the conflict. opendkim is a daemon that
the filters contact in order to get signing and verification services.
It can temp-fail messages, but only in the case of detectable errors, and
they are always logged (when Syslog is set in opendkim.conf).
I'm a sendmail person and not a postfix person, so I can't help with this
myself. Perhaps someone on this list can help you; if not, I suggest
posting this same description on the postfix-users mailing list.
http://www.postfix.org/lists.html#lists
> P.S. I also have a firewall with most ports blocked but outgoing mail was
> working before installing opendkim so I assume it's not a firewall issue,
> unless dkim requires some additional port (and I assume that's not the case).
It needs DNS. It also needs whatever TCP port is selected for postfix to
talk to opendkim, although you could also be using a UNIX domain socket in
which case the firewall won't be involved. It might also need whatever
port is needed to talk to your databases, if it's configured to get keys
or other data from something like SQL or LDAP.
-MSK
Received on Thu Jan 17 2013 - 07:41:32 PST