Marc Chamberlin: > On 6/5/2011 9:36 AM, Wietse Venema wrote: > > Marc Chamberlin: > >> Hello - > >> > >> I am a new subscriber to this mail list and am in need of some help > >> configuring Postfix/Sendmail to work with the Apache James email server. > >> Don't get me wrong on this, Postfix is probably a fine MTA, but I have > >> some complex mailets designed which run under Apache James. ;-) Anywise, > >> in the past, I have usually turned off Postfix, on my servers, and just > >> used the older Sendmail to handle the mail interface for some other > >> applications that are also running on my servers. (Bugzilla and Bacula > >> in particular) To accomplish this, the people at Apache James supplied a > >> set of instructions (now found at > >> http://wiki.apache.org/james/JamesAndSendmail ) to configure Sendmail > >> just to relay email it picks up, to James, and not conflict with James > >> in using the ports) > >> > >> My distro (openSuSE 11.4) appears to be dropping the older Sendmail and > >> moving towards Postfix instead. I know that Postfix supplies a somewhat > >> compatible SendMail front end, so as to remain compatible with those > >> applications that use Sendmail. What I need to know is how to configure > >> Postfix/SendMail to work with and be compatible with Apache James. In > >> other words, I would like to be able to accomplish the same effective > >> configuration as was done and explained on the above mentioned webpage. > > If you can describe what Sendmail features Apache James requires, > > then an experienced Postix admin here can tell you if you need to > > change any Apache/Postfix settings at all. > > > > For example, if it connected to Sendmail with SMTP, then all settings > > you need are in http://www.postfix.org/BASIC_CONFIGURATION_README.html. > > > > Wietse > > > Thanks Wietse for replying! From your reply, I think you are > interpreting my question as asking how Apache James can use > Postfix/Sendmail to process email for it.
Indeed. You wrote that "Postfix supplies a somewhat compatible SendMail SendMail front end". This front end RECEIVES non-network email and inserts it into the Postfix queue for processing. > Actually, what I need is the other way around, how to configure > Postfix/Sendmail to relay email to the Apache James email server > without causing a conflict between the two services. You mean, both running on the same machine. What is the purpose of having two SMTP programs on the same machine? > If you follow the link to the webpage that I provided in my > posting, it will explain what is needed to run the old Sendmail app with > Apache James. Basically there are 4 things which need to be done - > > 1. Stop Postfix/Sendmail from running as an SMTP daemon Execute: # postfix stop > 2. Set up Postfix's frontend Sendmail to relay email to the James > server on localhost. Documented in: http://www.postfix.org/STANDARD_CONFIGURATION_README.html#firewall > 3. Stop Postfix's Sendmail complaining about mail apparently looping > back, if necessary. The most robust way is to configure a second IP address, with its own unique hostname. Specify: /etc/postfix/main.cf: inet_interfaces = the second IP address myhostname = the second hostname Execute: # postfix stop # postfix start If you can't have more than one IP address, then the solution is to configure Apache James to listen on a port other than 25, and to configure Postfix to send mail to that port instead of 25. > 4. James requires SMTP AUTH, so mail relayed to it from Sendmail will > need to follow the log in protocols. Documented in: http://www.postfix.org/SASL_README.html#client_sasl > I won't need Postfix to receive and process email for local users > either, just need the Sendmail API for other applications running on the > servers. Please don't use standard terminology in non-standard ways. That results only in massive confusion. An API is an application programming interface: a library call or a kernel call. The only Sendmail API in general use is the mail filter (Milter) API. This Sendmail API is not designed to deliver mail from one system to another. Wietse