6
E-Mail an t-online und web.de Adressen kommt immer zurück
Hey Mail-Geeks und Spezialisten!
Ich habe folgendes Problem: Wie oben beschrieben kommen Mails an einige WEB.DE und t-online Adressen wieder zurück oder brauchen 2 Tage, bis sie durchgestellt werden. Oftmals kommt dann eine, wie die folgende, Fehlermeldung:
Von: Microsoft Outlook
Gesendet: Montag, 12. August 2013 08:46
An: xxx xxx
Betreff: Unzustellbar: testmail
mailin52.aul.t-online.de hat Ihre Nachricht an die folgende E-Mail-Adresse zurückgewiesen:
yyyy (yyyyyy@t-online.de) (yyyyy@t-online.de)
mailin52.aul.t-online.de hat diesen Fehler ausgegeben:
user unknown Unknown recipient.
Die eingegebene E-Mail-Adresse konnte nicht gefunden werden. Überprüfen Sie die E-Mail-Adresse des Empfängers, und versuchen Sie, die Nachricht erneut zu senden. Wenden Sie sich an den Helpdesk, falls das Problem weiterhin besteht.
Diagnoseinformationen für Administratoren:
Generierender Server: LEAS.metallbau.local
yyyyy@t-online.de
mailin52.aul.t-online.de #550-5.1.1 user unknown 550 5.1.1 Unknown recipient. ##
Ursprüngliche Nachrichtenkopfzeilen:
Received: from LEAS.metallbau.local ([fe80::23c8:9a82:d40b:251a]) by
LEAS.metallbau.local ([fe80::23c8:9a82:d40b:251a%10]) with mapi id
14.02.0342.003; Mon, 12 Aug 2013 08:45:36 +0200
From: xxxx <xxxx@metallbau-werder.de>
To: "yyyy (yyyyy@t-online.de)" <yyyyyy@t-online.de>
Subject: testmail
Thread-Topic: testmail
Thread-Index: Ac6XJ4fab4YXVdIrRmSx2iuBsVIzDQ==
Date: Mon, 12 Aug 2013 06:45:35 +0000
Message-ID: <972944D5C53FA9459090F858C70033FB09159EE4@LEAS.metallbau.local>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [192.168.2.29]
Content-Type: multipart/related;
boundary="_004_972944D5C53FA9459090F858C70033FB09159EE4LEASmeta_";
type="multipart/alternative"
MIME-Version: 1.0
**
In diesem Fall ging die Testmail (wie zu sehen) an einen t-online Account. Das Verwirrende an der ganzen Geschichte ist, dass andere User aus dem gleichen Netzwerk über den gleichen Mail-Server an die gleiche Adresse Mails schicken können. Nur eben ein Kollege nicht.
Kurz zum Netzwerk:
Hier steht ein Windows 2011 Standard SBS mit DC, DHCP, DNS. . . Rollen. Zudem läuft auf dem Ding ein Exchange 2011 Server über den alle ihre Firmenmails verschicken.
Das Exchange-Profil von dem Kollegen ist genauso wie alle anderen Konfiguriert worden, also nichts anders als bei den anderen eingestellt.
Die Mails rufen wir mit Outlook 2010 ab. Das Betriebssystem des Anwender-Computers ist Win7 64bit.
Kann uns jemand helfen?
Danke im Voraus =).
Besten Gruß
Chris
Ich habe folgendes Problem: Wie oben beschrieben kommen Mails an einige WEB.DE und t-online Adressen wieder zurück oder brauchen 2 Tage, bis sie durchgestellt werden. Oftmals kommt dann eine, wie die folgende, Fehlermeldung:
Von: Microsoft Outlook
Gesendet: Montag, 12. August 2013 08:46
An: xxx xxx
Betreff: Unzustellbar: testmail
mailin52.aul.t-online.de hat Ihre Nachricht an die folgende E-Mail-Adresse zurückgewiesen:
yyyy (yyyyyy@t-online.de) (yyyyy@t-online.de)
mailin52.aul.t-online.de hat diesen Fehler ausgegeben:
user unknown Unknown recipient.
Die eingegebene E-Mail-Adresse konnte nicht gefunden werden. Überprüfen Sie die E-Mail-Adresse des Empfängers, und versuchen Sie, die Nachricht erneut zu senden. Wenden Sie sich an den Helpdesk, falls das Problem weiterhin besteht.
Diagnoseinformationen für Administratoren:
Generierender Server: LEAS.metallbau.local
yyyyy@t-online.de
mailin52.aul.t-online.de #550-5.1.1 user unknown 550 5.1.1 Unknown recipient. ##
Ursprüngliche Nachrichtenkopfzeilen:
Received: from LEAS.metallbau.local ([fe80::23c8:9a82:d40b:251a]) by
LEAS.metallbau.local ([fe80::23c8:9a82:d40b:251a%10]) with mapi id
14.02.0342.003; Mon, 12 Aug 2013 08:45:36 +0200
From: xxxx <xxxx@metallbau-werder.de>
To: "yyyy (yyyyy@t-online.de)" <yyyyyy@t-online.de>
Subject: testmail
Thread-Topic: testmail
Thread-Index: Ac6XJ4fab4YXVdIrRmSx2iuBsVIzDQ==
Date: Mon, 12 Aug 2013 06:45:35 +0000
Message-ID: <972944D5C53FA9459090F858C70033FB09159EE4@LEAS.metallbau.local>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [192.168.2.29]
Content-Type: multipart/related;
boundary="_004_972944D5C53FA9459090F858C70033FB09159EE4LEASmeta_";
type="multipart/alternative"
MIME-Version: 1.0
**
In diesem Fall ging die Testmail (wie zu sehen) an einen t-online Account. Das Verwirrende an der ganzen Geschichte ist, dass andere User aus dem gleichen Netzwerk über den gleichen Mail-Server an die gleiche Adresse Mails schicken können. Nur eben ein Kollege nicht.
Kurz zum Netzwerk:
Hier steht ein Windows 2011 Standard SBS mit DC, DHCP, DNS. . . Rollen. Zudem läuft auf dem Ding ein Exchange 2011 Server über den alle ihre Firmenmails verschicken.
Das Exchange-Profil von dem Kollegen ist genauso wie alle anderen Konfiguriert worden, also nichts anders als bei den anderen eingestellt.
Die Mails rufen wir mit Outlook 2010 ab. Das Betriebssystem des Anwender-Computers ist Win7 64bit.
Kann uns jemand helfen?
Danke im Voraus =).
Besten Gruß
Chris
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 214013
Url: https://administrator.de/contentid/214013
Printed on: April 25, 2024 at 13:04 o'clock
6 Comments
Latest comment
Servus,
Ist doch eindeutig. Der Kollege mit den Problemen wird einen Tippfehler in der Mailaddresse haben und sein Outlook hat diesen Tippfehler im Adresscache. Beachte: Anzeigename einer Mailadresse ist nicht gleich der Mailadresse an die die Mail geht.
Such mal in den Routinglogs nach den Mails, dann siehst Du an welche Adresse die Mail wirklich geschickt wurde.
Lösung: Lösche beim Kollegen den Adresscache bzw. alle Verweise auf die fehlerhafte Adresse.
Gruß
Marcus
mailin52.aul.t-online.de #550-5.1.1 user unknown 550 5.1.1 Unknown recipient. ##
Ist doch eindeutig. Der Kollege mit den Problemen wird einen Tippfehler in der Mailaddresse haben und sein Outlook hat diesen Tippfehler im Adresscache. Beachte: Anzeigename einer Mailadresse ist nicht gleich der Mailadresse an die die Mail geht.
Such mal in den Routinglogs nach den Mails, dann siehst Du an welche Adresse die Mail wirklich geschickt wurde.
Lösung: Lösche beim Kollegen den Adresscache bzw. alle Verweise auf die fehlerhafte Adresse.
Gruß
Marcus
1
Hi
Ich hatte vor kurzem ein ähnliches Problem mit einem Exchange 2010 (übrigens ist in sbs 2011 auch exchange 2010 drin).
Versuch mal eine diagnose deines Mailservers von Extern:
http://mxtoolbox.com/diagnostic.aspx
Wenn du bei TLS Probleme hast kann es vorkommen das manche Mailübertragungen funktionieren und andere wieder nicht.
Zumindest war das verhalten bei mir so. Ich habe auch Verzögerungsnachrichen vom Exchange erhalten.
Nach meiner Diagnose bin ich zu dem schluss gekommen das dass Verwendete TLS Zertifikat für die verschlüsselung nicht richtig funktioniert.
Ich habe das Zertifikat erneut ausgestellt und ersetzt.
Nach dem austausch hat bei mir alles wieder korrekt funktioniert.
PS: Die Erkärung des Kollegen ist allerdings wahrscheinlicher. Da das Problem aber wie beschrieben bei allen auftritt könnte es möglicherweise kein Tippfehler sein.
LG Andreas Ausserwöger
Ich hatte vor kurzem ein ähnliches Problem mit einem Exchange 2010 (übrigens ist in sbs 2011 auch exchange 2010 drin).
Versuch mal eine diagnose deines Mailservers von Extern:
http://mxtoolbox.com/diagnostic.aspx
Wenn du bei TLS Probleme hast kann es vorkommen das manche Mailübertragungen funktionieren und andere wieder nicht.
Zumindest war das verhalten bei mir so. Ich habe auch Verzögerungsnachrichen vom Exchange erhalten.
Nach meiner Diagnose bin ich zu dem schluss gekommen das dass Verwendete TLS Zertifikat für die verschlüsselung nicht richtig funktioniert.
Ich habe das Zertifikat erneut ausgestellt und ersetzt.
Nach dem austausch hat bei mir alles wieder korrekt funktioniert.
Zitat von @Onitnarat:
Servus,
> mailin52.aul.t-online.de #550-5.1.1 user unknown 550 5.1.1 Unknown recipient. ##
Ist doch eindeutig. Der Kollege mit den Problemen wird einen Tippfehler in der Mailaddresse haben und sein Outlook hat diesen
Tippfehler im Adresscache. Beachte: Anzeigename einer Mailadresse ist nicht gleich der Mailadresse an die die Mail geht.
Such mal in den Routinglogs nach den Mails, dann siehst Du an welche Adresse die Mail wirklich geschickt wurde.
Lösung: Lösche beim Kollegen den Adresscache bzw. alle Verweise auf die fehlerhafte Adresse.
Gruß
Marcus
Servus,
> mailin52.aul.t-online.de #550-5.1.1 user unknown 550 5.1.1 Unknown recipient. ##
Ist doch eindeutig. Der Kollege mit den Problemen wird einen Tippfehler in der Mailaddresse haben und sein Outlook hat diesen
Tippfehler im Adresscache. Beachte: Anzeigename einer Mailadresse ist nicht gleich der Mailadresse an die die Mail geht.
Such mal in den Routinglogs nach den Mails, dann siehst Du an welche Adresse die Mail wirklich geschickt wurde.
Lösung: Lösche beim Kollegen den Adresscache bzw. alle Verweise auf die fehlerhafte Adresse.
Gruß
Marcus
PS: Die Erkärung des Kollegen ist allerdings wahrscheinlicher. Da das Problem aber wie beschrieben bei allen auftritt könnte es möglicherweise kein Tippfehler sein.
LG Andreas Ausserwöger
1
Servus Marcus,
ahhh. Okay. Du hattest vollkommen recht! Da hätte ich auch hinter steigen können. Der Kollege hatte echt einen Tippfehler in der Adresse. Tzzz. Wenn man nicht mit dem Adressbuch arbeitet.
Haste auch eine Lösung für die verzögerte Mailzustellung parat?
Gruß
Chris
ahhh. Okay. Du hattest vollkommen recht! Da hätte ich auch hinter steigen können. Der Kollege hatte echt einen Tippfehler in der Adresse. Tzzz. Wenn man nicht mit dem Adressbuch arbeitet.
Haste auch eine Lösung für die verzögerte Mailzustellung parat?
Gruß
Chris
Hey Andreas,
danke für deine Antwort!
Das werde ich gleich mal ausprobieren. Mal sehen, was sich tut!
Lieben Gruß Chris
danke für deine Antwort!
Wenn du bei TLS Probleme hast kann es vorkommen das manche Mailübertragungen funktionieren und andere wieder nicht.
Zumindest war das verhalten bei mir so. Ich habe auch Verzögerungsnachrichen vom Exchange erhalten.
Nach meiner Diagnose bin ich zu dem schluss gekommen das dass Verwendete TLS Zertifikat für die verschlüsselung nicht
richtig funktioniert.
Ich habe das Zertifikat erneut ausgestellt und ersetzt.
Nach dem austausch hat bei mir alles wieder korrekt funktioniert.
Zumindest war das verhalten bei mir so. Ich habe auch Verzögerungsnachrichen vom Exchange erhalten.
Nach meiner Diagnose bin ich zu dem schluss gekommen das dass Verwendete TLS Zertifikat für die verschlüsselung nicht
richtig funktioniert.
Ich habe das Zertifikat erneut ausgestellt und ersetzt.
Nach dem austausch hat bei mir alles wieder korrekt funktioniert.
Das werde ich gleich mal ausprobieren. Mal sehen, was sich tut!
Lieben Gruß Chris
Servus Chris,
ahhh. Okay. Du hattest vollkommen recht! Da hätte ich auch hinter steigen können. Der Kollege hatte echt einen
Tippfehler in der Adresse. Tzzz. Wenn man nicht mit dem Adressbuch arbeitet.
Tippfehler in der Adresse. Tzzz. Wenn man nicht mit dem Adressbuch arbeitet.
Freut mich, dass ich einen Treffer erzielen konnte, aber diese Problematik kenne ich nur zu gut
Haste auch eine Lösung für die verzögerte Mailzustellung parat?
Hast Du hier auch eine entsprechende Fehlermeldung, die von oben ist ja eine wegen Tippfehler? Wie versendet Dein SBS denn Mails nach draußen, also wie ist der Sendekonnektor eingestellt, Smarthost oder direkt per DNS?
Die Verzögerung könnte durch die Spamfilter von web.de zustande kommen. Wenn Dein SBS direkt per DNS versendet tritt er ja als versendender Server bei web.de auf, wenn hier nun etwas mit den DNS-Einträgen (Stichwort Reverse-Lookup) nicht passt. Oder Dein SBS sich mit "LEAS.metallbau.local" auf HELO meldet, dann kann es schon sein, dass web.de und Konsorten die Mails als spamverdächtig einstuft und daraufhin entweder verzögern oder irgendwann als unzustellbar zurückweisen.
Lösung: DNS-Einträge sauber setzen oder über Deinen Mailprovider versenden. Letzteres ist meist die leichtere und bessere Lösung.
Gruß
Marcus
Hey Marcus,
hey Andreas!
Kurze Rückmeldung zu meinem Problem:
das Neuausstellen des Zertifikates war der Weisheit letzter Schluss =). Jetzt funktioniert bei dem Kollegen endlich alles so, wie es soll.
Danke für eure geniale Hilfe!
Lieben Gruß aus Werder.
Chris
hey Andreas!
Kurze Rückmeldung zu meinem Problem:
das Neuausstellen des Zertifikates war der Weisheit letzter Schluss =). Jetzt funktioniert bei dem Kollegen endlich alles so, wie es soll.
Danke für eure geniale Hilfe!
Lieben Gruß aus Werder.
Chris
