Mailzustellung via inode/upc an drei.at extrem verzögert

[jjknw]

Einer meiner Mail-Accounts ([email protected]) wird von inode/UPC gehostet.
Ich lasse Mails, die an diese Mail-Adresse geschickt werden, - seit Jahren erfolgreich - an [email protected] weiterleiten. Seit 01.02.2013 kommen die weitergeleiteten Mails bei drei.at allerdings bis zu 14 Stunden(!) verspätet an.

Sende ich nun über ein "Dritt-System" testweise ein Mail zugleich an [email protected] und [email protected], so kommt das Mail bei drei.at "unverzüglich" an (1).
Auch bei [email protected] (bzw. [email protected]) kommt das Mail "sofort" an (3).
Von dort wird das Mail auch verzögerungsfrei z.B. an [email protected] weitergeleitet (4a).
Nur die Weiterleitung nach [email protected] lässt Stunden(!) auf sich warten (4b).

Eine Zustellverzögerung (im Normalbetrieb) von einigen Minuten finde ich ja noch akzeptabel, nicht jedoch von mehreren Stunden.
Wer kann mir helfen? Kennt jemand von euch eine kompetente UPC-Ansprechperson, an die ich mich direkt wenden könnte?


Im Detail sieht der ganze Ablauf so aus:

Code: Alles auswählen

Sende Mail zugleich an
[email protected] und [email protected]
   |               |
   |               V
   |            (2) [email protected]
   V                   |
(1) OK, ohne           V
Verzögerung         (3) [email protected]
                           |               |
                           V               V
          (4a) [email protected]   (4b) [email protected]
          OK, ohne Verzögerung   mehrere Stunden Verzögerung!

Ich versende testweise um 16:00:11 ein Mail, zugleich adressiert an [email protected] und [email protected]:

Code: Alles auswählen

01   > To: [email protected], [email protected]
02   > Date: Thu, 07 Feb 2013 16:00:11 +0100

(1) Das Mail an [email protected] kommt "sofort" (16:00:13) an:

Code: Alles auswählen

03   > Received: from atmailgate1.generali.at (mx2.generali.at [194.48.84.18])
04   >        by mail.drei.at  with ESMTP id r17F0DID022933-r17F0DIE022933
05   >        for <[email protected]>; Thu, 07 Feb 2013 16:00:13 +0100

(2) Die Mail-Adresse [email protected] ist als "Forwarder" eingerichtet, sodass alle eintreffenden Mails an [email protected] weitergeleitet werden.
(3) Von dort ([email protected]) werden die Mails an [email protected] weitergeleitet.
(4) Die Mail-Adresse [email protected] ist wiederum als "Forwarder" eingerichtet, sodass alle eintreffenden Mails unverzüglich ZUGLEICH an [email protected] und [email protected] weitergeleitet werden:

(4a) Das weitergeleitete Mail an [email protected] kommt "sofort" (16:00:21) an:

Code: Alles auswählen

06   > Received: from fep17.mx.upcmail.net (fep17.mx.upcmail.net [62.179.121.37])
07   >        by atmailgate2.generali.at (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r17F0LIA025175
08   >        for <[email protected]>; Thu, 7 Feb 2013 16:00:21 +0100
09   > Received: from edge11.upcmail.net ([192.168.13.81])
10   >           by viefep17-int.chello.at
11   >           (InterMail vM.8.01.05.05 201-2260-151-110-20120111) with ESMTP
12   >           id <[email protected]>
13   >           for <[email protected]>; Thu, 7 Feb 2013 16:00:20 +0100
14   > Received: from smartmx-04.inode.at ([62.99.145.4])
15   >        by edge11.upcmail.net with edge
16   >        id xT0L1k00505uo3A0BT0LV7; Thu, 07 Feb 2013 16:00:20 +0100
17   > Received: from mx.expurgate.net ([194.145.224.110]:4796)
18   >        by smartmx-04.inode.at with esmtp (Exim 4.69)
19   >        (envelope-from <[email protected]>)
20   >        id 1U3SxY-0006zh-Kt
21   >        for [email protected]; Thu, 07 Feb 2013 16:00:20 +0100
22   > Received: from mx.expurgate.net (helo=localhost)
23   >        by mx.expurgate.net with esmtp
24   >        id 1U3SxT-0006CE-68
25   >        for [email protected]; Thu, 07 Feb 2013 16:00:15 +0100
26   > Received: from [62.99.145.23] (helo=mx.inode.at)
27   >        by mx.expurgate.net with ESMTP (eXpurgate 4.0.0)
28   >        (envelope-from <[email protected]>)
29   >        id 5113c17f-34bb-3e639117eae3-1
30   >        for <[email protected]>; Thu, 07 Feb 2013 16:00:15 +0100
31   > Received: from [194.48.84.18] (port=15794 helo=atmailgate1.generali.at)
32   >        by smartmx-21.inode.at with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32)
33   >        (Exim 4.69)
34   >        (envelope-from <[email protected]>)
35   >        id 1U3SxS-00036p-Ti
36   >        for [email protected]; Thu, 07 Feb 2013 16:00:14 +0100

(4b) Das "gleiche" weitergeleitete Mail an [email protected] kommt erst um 17:58:27 - also fast 2 Stunden verspätet - an!

Code: Alles auswählen

37   > Received: from fep24.mx.upcmail.net (fep24.mx.upcmail.net [62.179.121.44])
38   >        by mail.drei.at  with ESMTP id r17GwO1Y011550-r17GwO1b011550
39   >        for <[email protected]>; Thu, 07 Feb 2013 17:58:27 +0100
40   > Received: from edge11.upcmail.net ([192.168.13.81])
41   >        by viefep17-int.chello.at
42   >        (InterMail vM.8.01.05.05 201-2260-151-110-20120111) with ESMTP
43   >        id <[email protected]>
44   >        for <[email protected]>; Thu, 07 Feb 2013 16:00:20 +0100
45   > Received: from smartmx-04.inode.at ([62.99.145.4])
46   >        by edge11.upcmail.net with edge
47   >        id xT0L1k00505uo3A0BT0LV7; Thu, 07 Feb 2013 16:00:20 +0100
48   > Received: from mx.expurgate.net ([194.145.224.110]:4796)
49   >        by smartmx-04.inode.at with esmtp (Exim 4.69)
50   >        (envelope-from <[email protected]>)
51   >        id 1U3SxY-0006zh-Kt
52   >        for [email protected]; Thu, 07 Feb 2013 16:00:20 +0100
53   > Received: from mx.expurgate.net (helo=localhost)
54   >        by mx.expurgate.net with esmtp
55   >        id 1U3SxT-0006CE-68
56   >        for [email protected]; Thu, 07 Feb 2013 16:00:15 +0100
57   > Received: from [62.99.145.23] (helo=mx.inode.at)
58   >        by mx.expurgate.net with ESMTP (eXpurgate 4.0.0)
59   >         (envelope-from <[email protected]>)
60   >        id 5113c17f-34bb-3e639117eae3-1
61   >        for <[email protected]>; Thu, 07 Feb 2013 16:00:15 +0100
62   > Received: from [194.48.84.18] (port=15794 helo=atmailgate1.generali.at)
63   >        by smartmx-21.inode.at with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32)
64   >        (Exim 4.69)
65   >        (envelope-from <[email protected]>)
66   >        id 1U3SxS-00036p-Ti
67   >        for [email protected]; Thu, 07 Feb 2013 16:00:14 +0100

Fazit:
Das an [email protected] weitergeleitete Mail via fep17.mx.upcmail.net (siehe Zeile 06-08) kommt sofort an,
das an [email protected] weitergeleitete Mail via fep24.mx.upcmail.net (siehe Zeile 37-39) ist fast 2 Stunden(!) verspätet.

Auffällig:
Mails an [email protected] werden via fepXX.mx.upcmail.net (XX<20) bis fep20.mx.upcmail.net versendet -> keine Verzögerung.
Mails an [email protected] werden via fep21.mx.upcmail.net bis fepXX.mx.upcmail.net (XX>21) versendet -> starke Verzögerungen (bis zu 14 Stunden!).

[jjknw]

Nachdem ich am 07.02.2013 auf meine detailierte Problem-Analyse von UPC folgende "freche" Antwort bekam, war ich fast am "Explodieren":

Der Emailversand ist kein Echtzeit Kommunikationsmittel.
Es kann durchaus vorkommen, dass die Zustellung von Emails längere Zeit in Anspruch nehmen kann.
Sobald ein Mailserver mehrere Emails verarbeiten muss, kann es passieren, dass sich die Emails stauen
und hier etwas Zeit benötigt wird bis alle Mails abgearbeitet wurden.

Welcher Mailserver hier etwas mehr Zeit benötigt hat, können wir leider nicht sehen.

Dieser Mitarbeiter war anscheinend nicht in der Lage, auch nur annähernd die Mail-Header-Informationen zu interpretieren.

Nachdem sich Tags darauf (nach juttas "Intervention"?) endlich ein kompetenter und freundlicher Techniker meldete, versprach dieser, dass ein für Do., 14.02.2013 geplantes Update die Verzögerungen bei der Mailzustellung beheben sollte. Tatsächlich meldete er sich sogar am Fr., 15.02.2013 nochmals, um sich zu vergewissern, ob denn nun eh alles wieder funktioniere - großes Lob!

Tatsächlich funktionierte die Mailzustellung ab Fr., 15.02.2013 wieder wie gewohnt - bis gestern, Mi., 27.02.2013, wo es zu einem "Mehrstündigen Mail-Ausfall bei UPC" kam (siehe <http://futurezone.at/produkte/14369-mehrstuendiger-mail-ausfall-bei-upc.php> und <http://xdsl.at/viewtopic.php?f=60&t=54613>).

Seither gibt's - trotz anders lautender UPC-Aussagen - noch immer (oder schon wieder?) Probleme bei der Mailzustellung:
1. Mails benötigen oft Stunden(!), um von einem UPC-Mailserver zum nächsten weitergereicht zu werden.
2. Mails werden manchmal mehrmals zugestellt:

Ein und dasselbe Mail wird von einem UPC-Mailserver (edge12.upcmail.net) zeitversetzt an mehrere andere UPC-Mailsysteme (viefep19-int.chello.at, viefep20-int.chello.at, usw.) weitergereicht, sodass im Endeffekt der Empfänger das Mail mehrmals erhält (bis zu mehreren Stunden verspätet).
Anscheinend gibt's (Routing-/LoadBalancing-)Probleme im UPC-internen Mail-Cluster.

//edit: Gerade eben erfuhr ich von einem (Newsletter-)Mail, das seit gestern Abend bis heute Nachmittag insgesamt 5 mal(!) zugestellt wurde - mit jeweils einem 3-MB-Attachtment. Ressourcenverschwendung pur.

Ich werde mir wohl einen neuen Mail-Provider suchen müssen...

[lordpeng]

wenn ich sowas lese, bin ich immer wieder froh, meine eigenen mailserver zu betreiben und hier auf niemanden angewiesen zu sein ...

btw. das mit dem newsletter, welcher immer wieder zugestellt wurde, könnte auch ein falsch konfigurierter SBS sein, welcher in einer mail schleife steckt (sowas ist mir zwar schon länger nimmer untergekommen, aber früher war das leider ein durchaus gängiges problem)

[jjknw]

wenn ich sowas lese, bin ich immer wieder froh, meine eigenen mailserver zu betreiben und hier auf niemanden angewiesen zu sein ...

Ja, aber dafür hast du auch die gesamte Verantwortung und Arbeit mit Updates, Spam- und Virenbekämpfung,... (siehe auch <http://xdsl.at/viewtopic.php?f=60&t=51479>)

... könnte auch ein falsch konfigurierter SBS sein, welcher in einer mail schleife steckt ...

Nein, das denke ich nicht. Die Mail-Header (Received:) all dieser mehrfach empfangenen Mails gleichen sich nämlich bei allen durchlaufenen Mailsystemen bis aufs Haar - nur beim jeweils letzten empfangenden UPC-Server unterscheiden sich "id" und "timestamp":

1. Mail:

Code: Alles auswählen

Received: from edge12.upcmail.net ([192.168.13.82])
     by viefep12-int.chello.at
     (InterMail vM.8.01.05.05 201-2260-151-110-20120111) with ESMTP
     id <20130227155147.ULIY29668.viefep12-int.chello.at@edge12.upcmail.net>
     for <[email protected]>;
     Wed, 27 Feb 2013 16:51:47 +0100
Received: from smartmx-11.inode.at ([62.99.145.13])
     by edge12.upcmail.net with edge
     id 5Trm1l00A0HZr5a0CTrmZS; Wed, 27 Feb 2013 16:51:47 +0100
...

2. Mail:

Code: Alles auswählen

Received: from edge12.upcmail.net ([192.168.13.82])
     by viefep17-int.chello.at
     (InterMail vM.8.01.05.05 201-2260-151-110-20120111) with ESMTP
     id <20130227155224.WKLB18677.viefep17-int.chello.at@edge12.upcmail.net>
     for <[email protected]>;
     Wed, 27 Feb 2013 16:52:24 +0100
Received: from smartmx-11.inode.at ([62.99.145.13])
     by edge12.upcmail.net with edge
     id 5Trm1l00A0HZr5a0CTrmZS; Wed, 27 Feb 2013 16:51:47 +0100
...

3. Mail:

Code: Alles auswählen

Received: from edge12.upcmail.net ([192.168.13.82])
     by viefep16-int.chello.at
     (InterMail vM.8.01.05.05 201-2260-151-110-20120111) with ESMTP
     id <20130227155258.FWRF23052.viefep16-int.chello.at@edge12.upcmail.net>
     for <[email protected]>;
     Wed, 27 Feb 2013 16:52:58 +0100
Received: from smartmx-11.inode.at ([62.99.145.13])
     by edge12.upcmail.net with edge
     id 5Trm1l00A0HZr5a0CTrmZS; Wed, 27 Feb 2013 16:51:47 +0100
...

Diese UPC-internen Mailsysteme generieren also "aus dem Nichts" immer wieder "Phantom"-Mails.

Ich fürchte, meine Problem-Analysen werden bei UPC wieder auf "taube Ohren" stoßen (Ausnahmen bestätigen die Regel!). Aber anstatt UPC länger bei der Fehleranalyse zu unterstützen, sollte ich lieber meine Energie in die Suche eines "professionellen" Mail-Hosters stecken...

[jutta]

> Anscheinend gibt's (Routing-/LoadBalancing-)Probleme im UPC-internen Mail-Cluster.

die kaempfen derzeit mit einem ganzen haufen probleme. details weiss ich auch nicht, aber es wird daran gearbeitet.

//edit ps: siehe auch viewtopic.php?f=60&t=54613 ein fehler behoben, dafuer ein neues problem geboren. oder so aehnlich jedenfalls.

ich sammle einstweilen lustige fehlermeldungen und spare auf brieftauben

http://tools.ietf.org/html/rfc1149
http://tools.ietf.org/rfc/rfc2549.txt
*SCNR*