postfix 2.3 timing out after a relay destination's reboot

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

postfix 2.3 timing out after a relay destination's reboot

milosz@adoc.fr
Hello,

I have 2 postfix mail relays (similar postfix configuration) which
forward my incoming emails to an Exchange Server, and I have problems
after Exchange reboots. One mail relay (Relay2) “hooks” Exchange and
starts over sending mails and one (Relay1) keeps timing out though the
Exchange server is up and the connections can be established on TCP 25
with a telnet connection.

My Postfix version : 2.3.8-2

My OS : Ubuntu Feisty


My network topology is :
- Relay1 has a public IP and forwards incoming mail to a NATed firewall
(pfsense) which forwards TCP 25 to the internal IP of my Exchange server
- Relay2 has a public IP and forwards incoming mail without NAT and only
with its routes to the internal IP of my Exchange server

During the reboot of the Exchange server, the logs on Relay are similar to :


Sep 15 12:13:33 relay postfix/qmgr[10428]: 65E2F3C03F: to=<
[hidden email]>, relay=none, delay=0.28, delays=0.18/0.1/0/0, dsn=4.4.1,
status=defe

rred (delivery temporarily suspended: connect to
192.168.0.250[192.168.0.250]: Connection timed out)

When the Exchange server’s reboot is done and its services started,
Relay2 forwards new incoming emails to my Exchange server, and old ones
will be resent later; without further action.

But Relay1 keeps timing out (meanwhile I can establish a connection to
the NATed IP with telnet), even for new mails, until I restart Postfix.

Postfix is really great, but I need to have them autonomous on this
point, because I’m not in charge of the Exchange server, and the
Exchange reboots can happen outside of my working hours.

I’ve already spent a few hours googling, but for now, I don’t have any
serious clue … I’ll plan during the next week an Ethereal frame capture
to see if I can find the problem

Has someone had this kind of problem in the past ?
- Is that a network problem ? Does it come from my pfsense firewall ?
- Is there a value to set in Postfix ? I’ve seen the value
“default_destination_concurrency_failed_cohort_limit”, which I can
disable, but I don’t have Postfix 2.5 installed and this value doesn’t
explain why I do have an asymmetric behavior between my two relays

- Any other clue ?

Thanks a lot and sorry for my bad english ;-)

Milosz SZOT

ADOC System Engineer

[hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: postfix 2.3 timing out after a relay destination's reboot

Noel Jones-2
[hidden email] wrote:

> Hello,
>
> I have 2 postfix mail relays (similar postfix configuration) which
> forward my incoming emails to an Exchange Server, and I have problems
> after Exchange reboots. One mail relay (Relay2) “hooks” Exchange and
> starts over sending mails and one (Relay1) keeps timing out though the
> Exchange server is up and the connections can be established on TCP 25
> with a telnet connection.
>
> My Postfix version : 2.3.8-2
>
> My OS : Ubuntu Feisty
>
>
> My network topology is :
> - Relay1 has a public IP and forwards incoming mail to a NATed firewall
> (pfsense) which forwards TCP 25 to the internal IP of my Exchange server
> - Relay2 has a public IP and forwards incoming mail without NAT and only
> with its routes to the internal IP of my Exchange server
>
> During the reboot of the Exchange server, the logs on Relay are similar
> to :
>
>
> Sep 15 12:13:33 relay postfix/qmgr[10428]: 65E2F3C03F: to=<
> [hidden email]>, relay=none, delay=0.28, delays=0.18/0.1/0/0, dsn=4.4.1,
> status=defe
>
> rred (delivery temporarily suspended: connect to
> 192.168.0.250[192.168.0.250]: Connection timed out)

This entry was logged by the postfix/qmgr program.  The
message is deferred because postfix has marked the destination
as unreachable due to previous failures.  No connection was
actually attempted at this time.  Once a destination is marked
unreachable, postfix won't attempt a new connection to that
same destination for at least $minimal_backoff_time.

Read the QSHAPE_README to understand how postfix uses the
different queues.
If you've changed minimal_backoff_time, maximal_backoff_time,
and queue_run_delay, you should probably set them back to the
sensible default values.

http://www.postfix.org/QSHAPE_README.html
http://www.postfix.org/TUNING_README.html

If you need more help, please tell us the version of postfix
you are using (the controls available depend on your postfix
version) and show "postconf -n" output.

--
Noel Jones