gelöst: Mailtransport verzögert: status=deferred, Connection timed out

[Mein Papierkorb]

Hallo nochmal,

habe soeben bei dem Hoster Contabo angerufen und die haben tatsächlich 
bestätigt, dass sie zwecks Spam-Schutz bei allen Serverprodukten (egal 
ob VPS oder root-Servern) eine Bremse eingebaut haben.
Also steht für mich mal wieder ein kleiner Providerwechsel an... :-/
Aber immerhin: Ursache gefunden!
Danke an Gerald, der mich mit dem Stichwort "Netzwerkproblem" auf die 
richtige Spur gebracht hat.

Viele Grüße,
Markus


Am 15.10.2020 um 22:15 schrieb Mein Papierkorb:
> Hallo,
>
> 1)
> die Verteilung der Mails in den Queues sieht wie folgt aus:
> incoming: 1
> active: 825
> defer: 11601
> deferred: 11601
> alle anderen Queues sind im 1-2 stelligen Bereich.
>
> 2)
> Kann es was mit dem Versionswechsel von 2.x auf 3.x und dem 
> compatibilty_level zu tun haben?
> Wie gesagt, ich habe den compatibility_level noch nicht auf 2 gesetzt, 
> weil ich dessen Auswirkungen nicht kenne und nicht weiss, ob und wie 
> vorab die main.cd oder master.cf angepasst werden muss.
>
> 3)
> Zu dem Netzwerkproblem:
> würde ich generell auch mal als Möglichkeit in Betracht ziehen, da es 
> sich um einen virtuellen Server handelt.
> Durch die Serverumstellung habe ich auch den Serverhoster gewechselt. 
> Ich bin mit dem neuen VPS - Server bei Contabo.
> Mit Netzwerkeinstellungen a la "nf_conntrack_max" etc kenne ich mich 
> leider so gar nicht aus - diesen Eintrag konnte ich auch nicht finden.
> Habe selbst zumindest nichts an solchen Stellen gefrickelt, wenn dann 
> muss dort ne Standard-Einstellung vom Provider ein Limit setzen.
> Werde dort morgen mal anfragen, ob die irgendwas limitieren.
>
> Viele Grüße,
> Markus
>
>
>
> Am 15.10.2020 um 21:37 schrieb Gerald Galster:
>>> Oct 15 18:47:41 mail postfix/error[28607]: 2974C5C47FE2: 
>>> to=<katharina58 at gmx.net>, relay=none, delay=13016, 
>>> delays=12954/62/0/0, dsn=4.4.1, status=deferred (delivery 
>>> temporarily suspended: connect to 
>>> mx01.emig.gmx.net[212.227.17.5]:25: Connection timed out)
>>> ***
>> "Connection timed out" deutet auf ein Netzwerkproblem hin.
>>
>> Mögliche Ansatzpunkte wären:
>>
>> - Verbindungen gehen aus (/proc/sys/net/nf_conntrack_max oder ähnliches)
>> - Verbindungen sind via iptables limitiert (SYN Pakete werden 
>> geblockt, ...)
>> - Firewall/Router zwischendrin verursacht das Problem
>> - IDS/Deep Inspection greift in SMTP ein
>> - Fehler auf der Netzwerkkarte (ifconfig / errors / duplex mismatch)
>>
>> Versuche mit netcat manuell eine Verbindung herzustellen. Falls Port 
>> 25 nicht erreichbar ist probiere einen anderen Port, z.B. 80 / 443. 
>> Funktioniert letzteres greift irgendwas in SMTP ein.
>>
>> Vielleicht hilft ein tcptraceroute um zu sehen wo die Pakete verloren 
>> gehen: traceroute -n -T -p 25 <server>
>>
>>
>>> Oct 15 18:47:10 mail postfix/error[28477]: 4584B5C457C3: 
>>> to=<bounce at exchangedomain>, relay=none, delay=13493, 
>>> delays=13462/31/0/0, dsn=4.4.1, status=deferred (delivery 
>>> temporarily suspended: connect to exchangeserver[ipv4]:25: 
>>> Connection timed out)
>> delays=13462/31/0/0
>>
>> The format of the "delays=a/b/c/d" logging is as follows:
>>
>> a = time from message arrival to last active queue entry
>> b = time from last active queue entry to connection setup
>> c = time in connection setup, including DNS, EHLO and STARTTLS
>> d = time in message transmission
>>
>> a dauert ziemlich lange, wie ist die Verteilung der Mails in den Queues?
>>
>> Für einen kurzen Überblick:
>>
>> [root at server ~]# cd /var/spool/postfix
>> [root at server ~]# for i in *; do echo $i && find $i | wc -l; done
>>
>> Aktiv zugestellt werden Mails in der active Queue, diese ist limitiert:
>> qmgr_message_active_limit (default: 20000), ggf. erhöhen
>>
>> Alles darüber hinaus liegt z.B. in incoming und wandert erst nach 
>> active wenn dort Platz frei wird.
>>
>> Wie sich die Mails verteilen kann man auch mit qshape nachschauen:
>> http://www.postfix.org/QSHAPE_README.html
>>
>> Viele Grüße
>> Gerald
>
>