[Postfixbuch-users] Teilweise verzögerterVersand

[Ralf Hildebrandt]

* Jan Theofel <theofel at etes.de>:

> Beim ip-up:
>   [...]
>   fetchmail -a -v -d 300 >>/var/log/fetchmail 2>&1
>   /usr/sbin/postconf -e "defer_transports = "
>   /usr/bin/postfix reload
>   /usr/bin/postfix flush

OK

> und beim ip-down:
>   /usr/sbin/postconf -e "defer_transports = hold"
>   /usr/bin/postfix reload
>   fetchmail -q

OK

> In /etc/postfix/transport habe ich eingetragen:
> 
> .                        hold:
> meinedomain.de           smtp:[192.168.0.111]
> 192.168.0.111            smtp:[192.168.0.111]
> subdomain.meinedomain.de hold:

OK. (Wusste nicht, dass "." alles matched)

> relayhost = [mail.eteshost.de]
> defer_transports = hold
> transport_maps = hash:/etc/postfix/transport

in master.cf ist hold definiert?

> Wenn nun Mail nach extern verschickt werden soll bekomme ich:
> connect to mail.eteshost.de[195.126.91.45]: Connection timeout
> 
> Baue ich aber von Hand eine Verbindung auf dem SMTP Port auf, kann ich
> problemlos meine Mail loswerden.
> 
> Auf mail.eteshost.de habe ich natürlich auch Zugriff und dort einen
> Blick in die mail-log geworfen. Dort finden sich ausser dem haendischem
> (telnet auf Port 25) keine Verbindungen des Servers.
> 
> Er scheint die Maschien also garnicht zu connecten. Aber wieso?

Gute Frage: Mal mit tcpdump sniffen!

-- 
Ralf Hildebrandt (Im Auftrag des Referat V a)   Ralf.Hildebrandt at charite.de
Charite Campus Mitte                            Tel.  +49 (0)30-450 570-155
Referat V a - Kommunikationsnetze -             Fax.  +49 (0)30-450 570-916
Experience is that marvelous thing that enables you to recognize a 
mistake when you make it again.                     -- F. P. Jones