[Postfixbuch-users] Suche was in der Art "fallback nexthop"

[Stefan Förster]

* Ralf Ebeling <r.ebeling at hagrid.posteule.com> wrote:
> ich habe mich die Tage damit beschäftigt wie ich Mails von
> meinem Root-Server via SMTP an meine lokale Maschine an einer
> DSL-Leitung (ohne feste IP) versenden kann.
> 
> Mit einem von der lokalen Maschine initierten Port-Forwarding
> (via autossh und ssh) scheint das soweit auch zu funktionieren,
> aber ich stelle mir die Frage wie ich Mails alternativ via uucp
> zustellen kann, wenn das Port-Forwarding mal für ein paar Tage
> nicht funktioniert.
> 
> Wäre soweit kein Problem, wenn Mails nicht nach bounce_queue_lifetime
> zurückgehen würden...
> 
> Mir sind da 2 mögliche Lösungen in den Kopf gekommen:
> 
> 1) ein neuer Transport "smtp-tunnel" mit abweichenden Settings für
>    delay_warning_time=99d und bounce_queue_lifetime=99d
> 
> 2) ein neuer transport "smtp-tunnel" mit einem smtp_fallback_relay
>    auf smtpd at locahost:20000, welcher wiederum transport_maps für
>    Domain xyz via uucp gesetzt hat
> 
> Ich habe beides noch nicht probiert, aber gibt es vielleicht noch
> einen anderen Weg (ausser mir eine Leitung mit fester IP zu gönnen)?

Das ist eigentlich kein SMTP-Problem. Du willst einen virtuellen Link
(irgendein VPN), über welchen der Rechner hinter der DSL-Strecke vom
annehmenden MX aus erreichbar ist, damit Du Dich nicht mit
Fallback-Lösungen herumschlagen musst - zumidnest glaube ich, daß Du
das willst.

Das Lebenszeitproblem in der Postwarteschlange (Halleluja!) erledigst
Du dann mit KISS:

1. Die Definition eines dedizierten Transports, welcher als "defer
only" deklariert ist. Der Rechner hinter der ADSL-Strecke kann dann
von cron aus ein "ETRN mydomain" absetzen, wann immer er lustig ist -
z.B. beim Booten.

2. Ein Skript, welches beim Verbindungsaufbau des VPN-Tunnels den
Transport-Eintrag in der main.cf tauscht:
   - Tunnel oben:  Direkte SMTP-Einlieferung über VPN-Strecke
   - Tunnel unten: Queueing wie unter (1) beschrieben.

Es erscheint mir sinnvoll, wenn das Skript auch bei einem Abbau des
Tunnels aktiv wird. Da anzunehmen ist, daß zu diesem Zeitpunkt schon
ein paar Mails deferred wurden, sollte das Skript nach dem Austauschen
der Transport-Tabelle ein re-queuing der Nachrichten anstoßen, damit
sie den richtigen Transportweg erreichen.

Jetzt muß ich dann aus Neugier fragen: Warum denn kein IMAP auf dem
Server, der fest angebunden ist?


Ciao
Stefan
-- 
Stefan Förster     http://www.incertum.net/     Public Key: 0xBBE2A9E9
"The universe is not required to be in perfect harmony with human ambition." - Carl Sagan