Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Two sendmail on the same machine.

3 views
Skip to first unread message

Marco Pizzi

unread,
Apr 16, 2004, 10:51:55 AM4/16/04
to
Hello,

I need to run two different sendmail processes on the same machine.
The machine has an ethernet card with two different ip addresses
belonging to different classes.
One sendmail process is listening as a daemon on the first ip, and the
second process is listening as a daemon too on the alias ip address.
The two processes use two different .cf config files, and two
different mailertables.
One of them, has a milter in it's config file.
My goal is to differentiate the e-mails using the first sendmail and
its mailertable.
For example:
if I send a mail to foo.com, the first sendmail process must deliver
it immediately (foo.com not present in its mailertable) and so the
mail is not processed by the milter.
if I send a mail to foobar.com, the first sendmail process must
send it to the second sendmail process, with milter enabled, and then
delivers it (empty mailertable).

But I have a problem: I have configured the mailertable of the first
process like this:
foobar.com smtp:[192.168.0.1]
where the 192.168.0.1 is the alias ip address of the ethernet card,
and where, at the port 25 the second sendmail process is listening.
In the precedent example if I send the mail to foo.com the first
process deliver it regularly, but if I send an e-mail to foobar.com I
have the well known error:
"sm-mta[392]: i3GDB4LS000390: SYSERR(root): [192.168.0.1] config
error: mail loops back to me (MX problem?)".
even if foobar is not defined as local anywhere!
My doubt is that probably the first sendmail process sees that
192.168.0.1 is the secondary address of the same interface, and then
he consider it local.
I'm right?
How I can fix this problem?
Does exist a more intelligent way in order to differentiate the e-mail
flow to the milter (based on the destination address) using only a
sendmail process?

Thanks.

Ville Jorma

unread,
Apr 16, 2004, 11:38:31 AM4/16/04
to

"Marco Pizzi" <ma...@SURNAME.name> wrote in message
news:0erv701r2n4rd131r...@4ax.com...

Hello,

> I have configured the mailertable of the first
> process like this:
> foobar.com smtp:[192.168.0.1]

I have noticed that sometimes it's necessary to use
relay mailer instead of smtp when destination is at the same host.
Don't know why though. With smtp mailer I got odd timeouts
with no error message. When the destination is at another host
smtp mailer works fine. This happens on Solaris.
Can anyone explain this?

> I have the well known error:
> "sm-mta[392]: i3GDB4LS000390: SYSERR(root): [192.168.0.1] config
> error: mail loops back to me (MX problem?)".
> even if foobar is not defined as local anywhere!

Do you have
define(`confDONT_PROBE_INTERFACES', `True')dnl
and do you have CLIENT_OPTIONS defined the same way
as DAEMON_OPTIONS?


Regards,

Ville Jorma

Per Hedeland

unread,
Apr 16, 2004, 3:00:39 PM4/16/04
to
In article <0erv701r2n4rd131r...@4ax.com> Marco Pizzi

<ma...@SURNAME.name> writes:
>
>But I have a problem: I have configured the mailertable of the first
>process like this:
>foobar.com smtp:[192.168.0.1]
>where the 192.168.0.1 is the alias ip address of the ethernet card,
>and where, at the port 25 the second sendmail process is listening.
>In the precedent example if I send the mail to foo.com the first
>process deliver it regularly, but if I send an e-mail to foobar.com I
>have the well known error:
>"sm-mta[392]: i3GDB4LS000390: SYSERR(root): [192.168.0.1] config
>error: mail loops back to me (MX problem?)".
>even if foobar is not defined as local anywhere!
>My doubt is that probably the first sendmail process sees that
>192.168.0.1 is the secondary address of the same interface, and then
>he consider it local.
>I'm right?

No. See FAQ 4.5, the very last paragraph.

>How I can fix this problem?

In your case a more useful advice than "don't do that" is probably to
check out the 'k' mailer flag (see doc/op/op.*).

>Does exist a more intelligent way in order to differentiate the e-mail
>flow to the milter (based on the destination address) using only a
>sendmail process?

Let the milter make the decision - i.e. have it tell sendmail that it
"accepts" the message as soon as it has received enough info to
determine that it shouldn't do any processing.

--Per Hedeland
p...@hedeland.org

0 new messages