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

Different queue lifetime(s) - is there a solution for my problem or do we need finer control?

9 views
Skip to first unread message

Dr. Uwe Meyer-Gruhl

unread,
Oct 18, 2009, 10:37:18 AM10/18/09
to
Hi,


is there any possibility to have different queue lifetimes apart from
"maximal_queue_lifetime" and "bounce_queue_lifetime"? Or is there
another elegant solution to my problem?

Background: I have a root server which shall forward mail to dial-up
servers with dynamic IP addresses. The dial-up servers cannot act as
MX themselves, since every 24 hours, their IPs are changed.

Thus, the fixed-IP root server acts as MX. In order to deliver
messages fast, I want to abolish pulling e-mails via fetchmail and
push the messages directly, like it is explained here:
http://www.thalmann.de/postfix-dialup.html

However, sometimes, the dial-up server(s) will be offline for a longer
period than the usual 5 days "maximal_queue_lifetime" specifies. Just
increasing that parameter does not do the job, since every outgoing
message will be retried for the same long time.

What I need would be a means to specify a much longer lifetime for the
"relay_domains" only, something like "relay_queue_lifetime".

I have looked into ETRN/"fast_flush_domains", but first, this is not
what I want, namely push delivery and second, "maximal_queue_lifetime"
also applies to this queue.

I know I could do this trick by either:

1. Using a different component than Postfix for queueing relayed mail,
e.g. UUCP. This has the drawback that it employs another error-prone
component and delivery could potentially be done to the wrong UUCP
destination (i.e. whoever inherits my old IP). Postfix gives me the
means to ensure delivery to the correct final destination (i.e. SSL
certificates) - and it does it fast normally. Ensuring this by UUCP is
quite diffcult.

2. Implementing a second "proxy" Postfix instance on the root server
with a much larger lifetime. This is rather complex, though. An
alternative would be a second MTA instance with a short lifetime that
handles only outgoing mail.


Thanks.

0 new messages