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