"Domain und MX-Record" - Falle

[eknori]

Momentan haben wir ein lustiges kleines Problem mit der Trennung eines MX-Records von der dazugehörenden Domain.
Bisher war die domain incl. aller Postfächer  "AndereCompany.de" bei der Telekom gehostet. Die Mails wurden über pop3 abgeholt.
Nachdem wir das Unternehmen gekauft haben, sind natürlich alle User auf unserem Domino angelegt worden. Als Mailadresse haben die eine FirstName.Lastname@AndereCompany.de erhalten. Den MX-Record haben wir auf unser MailGateway umgebogen. Soweit, so gut.
Mails an diese Personen kommen rein und Mails nach extern von diesen Personen gehen raus.

Gestern rief ein Mitarbeiter eines Unternehmens mit der Domain "FremdesUnternehmen.com" an und sagte, daß er mails an die besagten Mitarbeiter nicht zustellen kann. Nach der Fehlermeldung befragt, murmelte er was von Imap.t-com.blubb.
Ich habe ihm dann von meinem Firmenaccount eine Mail geschickt; die kam auch an. Ebenso kam seine Antwort auf meine Mail an.

Dann habe ich ihm eine Mail unter dem Namen eines Users der AndereCompany.de geschickt und prompt bekam ich eine Fehlermeldung: Cannot send mail as user ... Authentication needed.  häää

Der Anrufer beteuerte, daß das Senden bis vor einer Woche noch funktioniert hat. Danach sind die zur Telekom umgezogen und seitdem geht das nicht mehr.

"AndereCompany.de" und "FremdesUnternehmen.com" sind also domainseitig bei dem gleichen Hoster.

Anruf bei der Telekom brachte dann ( vorerst ) Licht in das Dunkel.

Wenn "FremdesUnternehmen.com" an "AndereCompany.de" mailt, bekommen die eine Fehlermeldung, daß der Account des Empfängers nicht aktiv ist. Die Mail wird aber zugestellt und landet im Postfach des Empfängers ... bei der Telekom.
Wir hatten dort alle Postfächer und Useraccounts noch belassen; aber deaktiviert, weil wir der Meinung waren, daß das Umbiegen des MX reicht.

der User aus "AndereCompany.de" bekommt die fehlermeldung bezgl. der Anmeldung, weil lt. Telekom noch ein Account dort existiert und bei der Zustellung von Mails Tkom intern keine Unterscheidung stattfindet zwischen interner mail und Mail an eine andere Domain.

Lösungsvorschlag der telekom: Löschen Sie alle Accounts und alle mailboxen. Die Domain und die Webseite kann verbleiben.

Habt ihr schon einmal > 100 User und Mailboxen über das Webinterface dort gelöscht? Da muss man schon ein bisschen Zeit mitbringen ...

Dumm nur, daß es nach wie vor nicht funktioniert. Auch mit einem user, der nie dort einen Account hatte, bekomme ich keine Mail an "FremdesUnternehmen.com" raus.

"FremdesUnternehmen.com" kann aber an diesen User problemlos mailen, weil er ja dort kein Postfach hat ...

Ist schon eine bekloppte Welt.

Mal sehen, was dem techniker bei der Telekom sonst noch einfällt. Ich bin mit meinem Latein am Ende.

[m3]

Kann es nicht sein, dass das "interne" DNS der t-com noch immer der Meinung ist, dass der MX für "AndereCompany.de" noch immer bei Ihnen ist?

Nur weil bei t-com ein Account "mumpfi" existiert, heißt das ja nicht, dass alle E-Mails mit dem Empfänger mumpfi@..... (irrelevant von der Domain dahinter) in dessen Posteingang landen.

IMHO cached deren DNS sehr lange oder wird nicht sauber gepflegt. Die Erklärung mit dem Accounts empfinde ich als sehr fadenscheinig.

[eknori]

Kann es nicht sein, dass das "interne" DNS der t-com noch immer der Meinung ist, dass der MX für "AndereCompany.de" noch immer bei Ihnen ist?

Kann sein, aber ich sitze nicht bei den Telekomikern.

Die Erklärung mit dem Accounts empfinde ich als sehr fadenscheinig.

Anfangs hatte ich das noch irgendwie verstanden; mitlerweile kann ich es nicht mehr nachvollziehen.
Nachdem ich gestern alle Accounts gelöscht habe, funktioniert es heute immer noch nicht. Support ist erst ab 8:00 zu erreichen ... Und mir hängen die User im Nacken, weil es sich um geschäftliche Kontakte handelt. Soll ich jetzt dem Mailpartner sagen: "Tut uns leid, aber da sie ihre Domain beim gleichen Provider hosten können wir mit Ihnen nicht mailtechnisch kommunizieren. Gehen Sie zu einem anderen Provider, dann funktioniert es!".
Vor allen DIngen möchte ich nicht wissen, wie viele Unternehmen uns noch mails schicken wollen, es aber nicht können, und die sich bisher noch nicht gemeldet haben.

[m3]

Ich bin schon gespannt, wie sich die t-com wieder herausreden will.

[eknori]

Schlussendlich war es dann der DNS Cache bei den Komikern.

[m3]

 

[eknori]

ich auch besser  . Vor allen Dingen musste ICH etliche Male nachfragem ob es denn schon Fortschritte gibt. Krönung dann heute morgen. Ticketnummer 192 ... ?? Nö, haben wir nicht. Aber erzählen Sie doch mal, worum es geht 

[blizzard]

na gabs denn schon eine Antwort von den netten Telekomikern?

Ich hatte vor einem halben Jahr ein ähnliches Problem, dass der public DNS Server einige Telekom Hostnames nicht mehr richtig auflösen konnte und komischerweise wir mal wieder die Ersten waren, die dies bemerkt haben und somit die Fehler beim Provider ausbügeln mussten - unglaublich.

[eknori]

Hatte ich doch schon geschrieben:

Schlussendlich war es dann der DNS Cache bei den Komikern.

[hallo.dirk]

...ich habe so einen ähnlichen Fall in Singapur....
Mails von diesem Provider kommen bei uns nicht an...

Ein Jahr hat es gedauert, bis die Kollegen folgende Aussage vom dortigen Provider bekommen haben.

Dear Sir/Mdm,

We understand that the domain name fremdeDomain.com.sg is having a mailhosting
service with Provider. When fremdeDomain.com.sg sends out email, it will check thru
Provider servers first to see if the receiver is on Provider server before
sending it to the internet. In this case, Provider server detected that
MeineDomain.com.sg is having mailhosting service with Provider. As such,
it will send to the mailbox and if it does not exist, it will bounce.

The mailhosting service for MeinDomain.com.sg is still active. If
MeinDomain.com.sg do not require the mailhosting service from Provider
anymore, you to fax in your request with your company letterhead,
including details such as the business registration

Aha, na endlich 

Irgendjemand muss damals vergessen haben, den Service nach der Umstellung zu kündigen.