Kurzer Hinweis an Leser, die IONOS-Server als SMTP-Relay (SmartHost) verwenden, um Mails von einem eigenen lokalen Mail-Server (Exchange Server) zu versenden. IONOS hat gerade angekündigt, dass man diesen Dienst zum 15. Januar 2024 in der bisherigen Form einstellen werde. Es sind bis zu diesem Datum bestimmte Anpassungen erforderlich, um den Dienst weiter verwenden zu können, da Mails andernfalls von den IONOS SMTP-Servern mit der Fehlermeldung "Sender address is not allowed." abgelehnt und nicht versendet werden. Ergänzung: IONOS hat mir nun eine Stellungnahme geschickt. Und eine Leserergänzung gibt es auch.
Anzeige
Das Thema ist gestern Abend von verschiedenen Lesern an mich herangetragen worden (danke dafür). Mathias fragte beispielsweise, ob ich es mitbekommen habe und meinte: "das dürfte Einige betreffen, die noch On-Premise Mail-Server haben, die nicht direkt an das Internet angebunden sind und via SmartHost versenden."
Worum geht es beim SmartHost?
Manche Firmen oder Privatleute betreiben eigene Mail-Server (Exchange Server) lokal, und verwenden einen "SmartHost" als SMTP-Relay, um Mails zu verwenden. Auch IONOS bietet diesen Dienst für Kunden an. Das hat aber den Nachteil, dass Mails mit Absenderadressen über den SmartHost als SMTP-Relay verschickt werden, die nicht zur Mailadresse passen, die bei IONOS registriert wird. Führt dazu, dass solche Hosts immer öfters auf Sperrlisten landen. Mathias wies mich per Mail auf diesen MSFAQ-Artikel hin, der die Konstruktion des SmartHost samt den Risiken beleuchtet.
IONOS ändert was zum 15. Jan. 2024
IONOS stellt zum 15. Januar 2024 die Möglichkeit zum Versand von Mails mit vom SmartHost abweichenden E-Mail-Adressen ein. Es sind bis zu diesem Datum bestimmte Anpassungen erforderlich, da Mails andernfalls von den IONOS SMTP-Servern mit der Fehlermeldung "Sender address is not allowed." abgelehnt und nicht versendet werden. IONOS hat das Ganze im Support-Beitrag Home E-Mail Meine E-Mails dokumentiert.
Anzeige
Im Text heißt es, dass es ab dem Stichtag 15.01.2024 nicht mehr möglich sei, E-Mails mit alternativen oder leeren Absendern über die IONOS-Server zu versenden. Es ist dann also nicht mehr möglich, so etwas wie guenni[at]born.de als lokale E-Mail-Adresse über einen IONOS-Server zu verschicken. Begründet wird dies mit dem Ansatz, die Sicherheit der Kunden zu erhöhen und daher nur noch E-Mails im SMTP-Relay anzunehmen, wenn im E-Mail-Programm/-App/-Software, oder im E-Mail-Server beim Versand von E-Mails eine Absenderadresse verwendet wird, die zum IONOS-Postfach des E-Mail-Servers gehört.
Stimmen die E-Mail-Adressen für den Absender und die Authentifizierung am Postausgangsserver (SMTP) in den Einstellungen der verwendeten Software nicht überein, werden betroffene E-Mails ab dem 15.01.2024 von den IONOS SMTP-Servern mit der Fehlermeldung Sender address is not allowed. abgelehnt und nicht versendet.
IONOS SmartHost für Exchange ist tot
Weitere Leser wiesen mich heute früh darauf hin, dass Frank Zöchling das Thema im Beitrag IONOS stellt Smarthost Funktion zum 15.01.2024 ein aufgegriffen habe. Frank erreichten viele Leseranfragen zu obigem Thema und kommt zu dem Schluss: Exchange Server können IONOS nicht mehr als Smarthost verwenden. Alle Exchange Server welche einen Sendeconnctor mit IONOS als Smarthost verwenden, sind von der Abschaltung der Smarthost Funktion betroffen.
Es scheinen eine Menge Leute diese Kombination verwendet zu haben. Auch Blog-Leser Yumper schrieb mir beispielsweise in einer Mail:
Ich habe da eine Frage: IONOS erlaubt ab dem 15.1.20215 das Versenden von Emails aus dem Exchange via Smarthost bei nicht mehr.
Können Sie bitte einmal eine Umfrage starten wie andere kleine Firmen das lösen?
Direkt versenden wollen und dürfen wir wegen VS-NFD-Regeln [GB: Für Verschlusssachen, siehe hier] unsere Emails nicht. Wir können deshalb auch kein Office365 benutzen
Zu dieser Frage hat Frank Zöchling in seinem Artikel IONOS stellt Smarthost Funktion zum 15.01.2024 ein einige mögliche Optionen aufgelistet. Vielleicht hilft es dem einen oder anderen aus der Leserschaft. Danke an die Leser für den Hinweis.
Mathias S. schrieb mir gerade in einer Mail, dass er eine Aussage des IONOS-Supports habe, die der obigen Information auf der IONOS-Webseite widerspricht. Der Support schrieb:
Sie haben bei IONOS die E-Mail-Adresse max.mustermann[at]example.com erstellt und verwenden in einem E-Mail-Programm wie z. B. Thunderbird oder Microsoft Outlook die E-Mail-Adresse kontakt@example.org als Absender. In diesem Fall müssen Sie statt der Absenderadresse kontakt[at]example.org die E-Mail-Adresse max.mustermann[at]example.com verwenden.
Mathias meint dazu: "Es ist fraglich ob das stimmt oder nur die Domain @example.org übereinstimmen muss. Bei letzterem wäre die smarthost-Nutzung nämlich noch möglich.
Stellungnahme von IONOS
Auf Grund der Diskussionen und Irritationen zum Blog-Beitrag hatte ich bei der Pressestelle von IONOS nachgefragt und mit Verweis auf diesen Artikel um eine interne Klärung samt Klarstellung gebeten. Diese Stellungnahme ist zum 8. Dezember 2023 eingegangen. Ich stelle den Text einfach hier ein.
Stellungnahme zum Smarthost / Mail Relay
Zum betreffenden Sachverhalt schrieb mit IONOS folgendes:
Vielen Dank für Ihre Anfrage. Kunden, die unser Produkt als Smarthost / Mail Relay nutzen, können dies auch weiterhin tun. Jedoch müssen sie die nachfolgenden Schritte berücksichtigen. Diese wurden bereits auch mit dem Support abgestimmt, falls sich weitere Kunden melden sollten.
Sie können auch ab dem 15.01.2024 über uns via Mail Relay / Smarthost senden. Nachstehend die Voraussetzungen:
1.) Bitte stellen Sie sicher, dass Sie bei uns ein Postfach angelegt haben, das sie als Mail Relay nutzen. Beispiel: „versand@ihredomain.tld"
2.) Bitte stellen Sie Sicher, dass auf der Domain Ihres Mail Relay Postfachs ein IONOS SPF-Eintrag gesetzt ist:
IONOS SPF – Damit Ihre E-Mails gut ankommen3.) Ihre Mail Relay Adressen müssen dieselbe Domain nutzen wie auch Ihr Mail Relay Postfach („versand@ihredomain.tld")
Beispiel: Sie möchten über die Adressen „info@ihredomain.tld", "mail@ihredomain.tld", "rechnung@ihredomain.tld" senden. Hierzu benötigen Sie mindestens ein Mail Relay Postfach bei IONOS, welches den Domain Part "ihredomain.tld" nutzt.
1&1 und GMail-Empfänger
Ich hatte in meiner Mail zudem nach einem weiteren Problem nachgefragt. Kunden, die ein Mail-Postfach unter einer Domain, die beim 1&1 DSL-Vertrag inkludiert ist, betreiben, können seit geraumer Zeit keine Nachrichten mehr zu GMail-Konto versenden. Der Empfang wird von GMail abgelehnt – wohl weil kein DKIM-Eintrag gesetzt ist.
Was mir aber kürzlich aufgefallen ist: Ich konnte mir testweise Mails über ein solche Postfach an eine GMail-E-Mail-Adresse schicken – die Nachrichten kamen an. Andererseits stellte ich fest, dass ich Mails mit einem BlueSky-Invite-Code, versandt an gmail.com-Adressen zurück bekam, weil die Anneldung verweigert wurde. Ich hatte bei 1&1/IONOS nachgefragt, ob es da eine Lösung geben wird? Zum betreffenden Sachverhalt schrieb mit IONOS folgendes:
Was Ihre Frage bezüglich der Gmail-Problem betrifft, möchte ich darauf hinweisen, dass wir bei IONOS seit Juni für alle Domains einen SPF-Record gesetzt haben. Gleichzeitig wurde dies auch bei 1&1 durchgeführt.
Sollten trotzdem noch Probleme bestehen, müssen sich betroffene Kunden beim 1&1 Support melden, damit dies manuell eingerichtet werden kann.
Möglicherweise wurde der SPF nicht gesetzt, weil der MX-Record nicht auf 1&1 zeigt, oder es gab bereits einen SPF-Record als das Update durchgeführt wurde.
Ich werde den Sachverhalt weiter beobachten und entsprechend reagieren, falls Nachrichten von Gmail erneut abgelehnt werden.
Ergänzung eines Blog-Lesers
Carl H. hat mich zum 11. Dezember 2023 noch per E-Mail kontaktiert, weil er seit zwei Wochen in einem (nach seinen Worten extrem zähen) Austausch mit IONOS – und parallel auch mit 1&1 – zu dieser Thematik steht. Das Problem: In seiner Umgebung werden 200 Aliase verwendet. Für jedes dieser Aliase nun ein Postfach hätte angelegt werden müssen, was beim Abholen der Emails Thunderbird wahrscheinlich in die Knie zwingen würde. Carl schrieb dazu: Wir setzen übrigens keinen lokalen SMTP-Server ein, sondern verschicken Emails von Thunderbird-Clients direkt über die SMTP-Server von IONOS und 1&1.
Carl hat mir die letzte Antwort vom IONOS-Kundenservice vom 09.12.2023 (um kurz vor 04:00 nachts) zur Verfügung gestellt:
"Der Grund, warum dies gemacht wurde, liegt nicht daran, dass IONOS dies entschieden hat, sondern daran, dass ab Januar Google Mail und Microsoft keine E-Mails mehr akzeptieren werden, bei denen die Absenderadresse nicht mit der Domain übereinstimmt."
Carl meint dazu: "Dank Ihres Beitrages kann ich diese Antwort nun etwas besser einordnen und würde vermuten, dass tatsächlich die gewohnte Praxis des Versenden von Emails über ein Alias unter der gleichen Domain des Postfach-Accounts weiterhin möglich sein wird. Ob der SPF-Eintrag dabei Pflicht sein wird, mag dahingestellt sein. Das allerdings erstmal nur bei IONOS. Von 1&1 fehlt noch ein entsprechender Hinweis. Ich bin übrigens ziemlich entsetzt über den schlechten Support von IONOSund von 1&1, nicht nur zu dieser Thematik."
Anzeige
Wer heute noch einen Exchange mit POP3 Abruf betreibt hat eh die Kontrolle über seine IT verloren. Dieses gemurkse habe ich letztens noch bei einem Kunden vorgefunden dort habe ich dann auf Hosted-Mailsecurity umgestellt. Dann muss der Exchange auch nicht direkt erreichbar gemacht werden.
Wer es dennoch so betreiben möchte soll sich halt MultiSendCon von Servolutions kaufen… funktioniert genau so schlecht wie Popconv4…
Wer spricht hier von POP3 und POPcon?
Es geht um das Rausschicken. Und da nutzen viele IONOS-Kunden bislang das IONOS-SMPT Relay per TLS1.2 und fügen den "Kundenserver" zum SPF-Record mit hinzu. Klappt ja bislang einwandfrei.
Die müssen sich nun umkucken, was sie tun.
Direkt schicken ohne Relay hat halt hohe Hürden – trotz DNS-PTR, fester IP und korrekt gepflegtem SPF-Record darf man dann bei T-Online betteln für eine gute Reputation. Obwohl man auf keiner Blacklist steht.
Genau das ist der Punkt! Warum hier alle von POP reden ist völlig seltsam. Vermutlich gibt es hunderte oder tausende Server die trotz fester IP und direkten Empfang trotzdem alles über den IONOS Smarthost raus hauen.
Warum sollte man einen Exchange per IONOS-Smarthost (SMTP) anbinden wenn man direkte Zustellung an den Exchange verwendet? Sinn dahinter verschließt sich mir vollkommen. Die Reputation von IONOS Smarthosts ist schon seit Jahren so stark heruntergestuft, dass dieses Konstrukt nur bei POP3 Abruf sinn macht… Klar gibts bei DTAG auch Probleme, aber die halten sich bei meinen Kunden (Teilweise 250+ Postfächer) stark in grenzen. Smarthost und POP3 Abruf sind heute nicht mehr zeitgemäß, verursacht unnötigen Arbeitsaufwand und deshalb mein Ursprünglicher Kommentar…
In den Kommentaren drüben bei FrankysWeb gibt es wohl widersprüchliche Aussagen des Supports dazu. Manche Kommentatoren haben als Antwort per Mail erhalten, dass nur die Domäne passen muss, andere haben die Auskunft erhalten, dass die ganze Adresse passen muss. Scheint so, als wenn nicht mal die IONOS Leute so richtig wissen, was los ist.
Ich finde aber auch, senden über Smarthost ist nicht mehr wirklich zeitgemäß und sollte wo immer möglich vermieden werden.
irgendwas stimmt da in der Interpretation nicht.
Also man benutzt einen Smarthost, weil man eine Dynamische IP Adresse hat auch wenn die sich nicht ändert.
Aber: Es ist zwar nicht RfC konform, aber die Spammer haben Stmp Betreiber dazu gezwungen, keine E-Mails mehr anzunehmen, die von einer dynamischen, "dial up", "DHCP" IP Adresse kommen. Ist praktisch standard, obwohl das das Spam Volumen nicht wirklich gesenkt hat…
Ich werde also meine E-Mails mit eigenem Lokal part nicht mehr los, wenn ich keinen anderen Smart Host habe oder keine feste IP Addresse.
Das ist kein Spaß, wenn dem so sein sollte.
Ich kann angeblich bei Inos nur noch die E-Mails-Absender abliefern, für die ich einen Account bei denen habe.
Wenn ich bei denen eine Domain laufen habe sollte, MUSS deren snarthost aber alle meine local parts akzeptieren und versenden.
Ich habe ihn ja auch im spf meiner Domain genannt.
Ich habe dann ja nicht nur pau1 at pau1es.de, sondern auch mindestens postmaster oder meine komplette Familie, man gönnt sich ja sonst nichts.
Was inos nicht mehr machen möchte ist wohl, das ich E-Mails mit pau1 at t-omlime.de als Absender rein kippe.
Sie stehen natürlich nicht im spf von t-omline.de und der Empfänger, z.B. bei gmail.com wird sie rejeckten.
Und irgendwann landet deren IP in einer Black list "offenes relay"(was nicht stimmt).
Es war im Grunde ein Fehler das inos Email mit fremden Domains angenommen hat. Früher (1985) galt es als "Gute Ton" ein offenes Relay zu betreiben. Dank Spam gilt das heute als unfein.
Der Infos smart host war aber kein offenes Relay.
Aber durch das inzwischen übliche Spf und dkim funktioniert das relaxen nicht mehr.
Und wer mehrere email accounts hat, muss sich halt mehrfach anmelden um diese beim smarthost abliefern zu können.
Das ist ganz korrekt.
Hol Dir ne eigene Domain und gut is.
Die eigene Domain ist nicht das Problem – der Geiz beim Einsatz ordentlicher E-Mail-Lösungen ist es.
Einfach eine ordentliche Lösung nutzen und man hat das Gemurkse nicht. Wenn es nicht M365 oder Google Workplace sein soll, kann man auch bei mailbox.org glücklich werden.
IONOS ist eine absolute Katastrophe, da sie immer noch Dienste anbieten, die maximal als "legacy" betrachtet werden können. Solange dieses Zeug aber existiert, denken Kleinstunternehmen nicht über neue Lösungen nach.
Na ja, grad' die erwähnten "Kleinstunternehmen" werden vermutlich kein so ausuferndes Budget, sofern überhaupt vorhanden, für professionell-spezialisierte Lösungen haben – und da schlägt dann eben auch oft einfach die rechenwirtschaftliche Priorisierung mit anderen benötigten "Arbeitsmaterialien" zu.
Das macht's natürlich nicht besser, ist aber oftmals eine rein betrieblich getriebene Entscheidung. 🤷♂️
Wer professionell auftreten will mit eigener Domain udn eigenen Mailadressen, der kann das auch mit kleinem Geldbeutel tun. Dann muss man halt entsprechend beim Provider buchen, dort auch alles pflegen und sich eine Lösung für die rechtssichere Archivierung beschaffen. Es muss kein lokaler Exchange mit Versand via Smarthost des Providers sein, nur, damit man auf keinen Fall auf einen Gruppenkalender verzichten muss.
Aber das kriege mal in die "K" bei "KMU" rein…. oder in deren "Consultants", die mit der Lösung ja kein Geld verdienen würden.
Bzgl. inkludierter Mailboxen verändern viele Hoster derzeit ihr Produkte, Neuverträge enthalten oft nur noch sehr wenige Mailboxen.
Ja überleg mal warum. Weil E-Mail versenden aufwendig = teuer geworden ist.
Blödsinn. Es ist schlicht egal, ob ich 20 oder 20.000 Mailkonten auf einer Domain liegen habe. Der Konfigurationsaufwand für den MTA ist absolut identisch, was SPF, DKIM und DMARC angeht.
Was Mail so verteuert, sind die Millionen Idioten da draußen, die ihr Outlook als a) Ersatz für jedwedes anderes Protokoll zur Übertraugung von binären Dateien und b) Backup für die lokale Datenhaltung betrachten. Das kostet nämlich Speicherplatz im Falle von IMAP oder gar einem "hosted Exchange". Und Speicherplatz kostet Geld. In der Anschaffung, in der Bereitstellung, der Gewährleistung der Vertfügbarkeit, und so weiter.
Natürlich lässt der Hoster sich das bezahlen, wenn seine Kunden zu blöd sind, sich ihre Dateien auf einem anderen Weg zu beschaffen als per Email. Ganz schlimm wird das, wenn 5 Leute im CC stehen oder Mails mit Anhängen unternehmensintern weitergeleitet werden, die Postfächer aber "hosted" sind.
"Das bedeutet, dass die Versand-Mail-Adresse die gleiche Domain-Endung (Teil nach dem @) haben muss, die auch die Adresse hat, die in unserem Mail-System hinterlegt ist. Alles, was vor dem @-Zeichen steht ist für uns irrelevant."
steht in einer Support Anfrage bei Frank.
Nur so ergibt das Sinn.
Das man nur noch mit dem Account senden Kann mit dem man sich angemeldet hat ist ein Kommunikations Problem.
Man kann nur noch mit der Domain senden die Ionos hostet.
Das ist ganz offensichtlich NICHT so.
Wir (bzw. mein Kunde) wurden angeschrieben, dass wir über "info@meinedomain.de" E-Mails mit ABWEICHENDEN Absender-Adressen (gleiche Domain-Endung!!!) schicken. Das wäre ab dem 14.1.24 nicht mehr möglich.
info[@]meinedomain.de ist beim Smart-Host Eintrag bei uns als Konto hinterlegt.
Genau so ist es. Ein Admin Kollege hatte bei IONOS angerufen.
Der Supporter am anderen Ende der Leitung sagte, dass die Info unglücklich formuliert wurde. Die haben wohl sehr viele Anrufe bekommen.
Wird die Domain bei IONOS gehostet, ändert sich nichts.
ich habe die Mail auch bekommen. Habe aber keinen Mail-Server. Nur eigene Domains bei Puretec damals gebucht. Über 1&1 zu Ionos umbenannt. Da sind Mail-Adressen inklusive. Und die sind mittlerweile auf Office 365 Outlook eingerichtet. Einige auch auf Android zusätzlich. Für 2 der Adressen habe ich jetzt den Hinweis bekommen. Für 20 andere nicht.
Wie muss ich das verstehen?
putertec und co haben emails mit jedem local part angenommen.
Also durfte man mit jedem beliebigen local part vor seiner Domain auch schreiben.
Das können die nicht abgeschaltet haben.
Die Beschreibung ist falsch.
Es ist heute technisch unsinnig, Mails für fremde Domains zu verteilen. Der SPF record wäre nicht gesetzt. Dkim geht auch nicht.
Gut das Ionos das jetzt abschaltet.
Schlecht wie sie das getimed und kommuniziert haben.
(Habe gerade gelesen, das MS das Exchange schon lange so kastriert hat, dass keine absenderspezifischen Smarthosts mehr mehr möglich sind, außer man geht in die Cloud…die haben da echt kriminelle Energie)
Zitat:
Aktion erforderlich: Passen Sie Ihre E-Mail-Einstellungen an
Hallo meinVorname meinNachname,
wir haben festgestellt, dass Sie E-Mails mit alternativen oder leeren Absendern über unsere E-Mail-Server versenden. Dies kann ein Sicherheitsrisiko darstellen und dazu führen, dass andere E-Mail-Anbieter diese E-Mails ablehnen oder als Spam einstufen.
Um die Sicherheit für alle E-Mail-Kunden zu erhöhen, ist es ab dem 15.01.2024 nur noch möglich, E-Mails über unsere Server zu versenden, wenn die Absenderadresse mit dem entsprechenden Postfach übereinstimmt. Weitere Informationen dazu finden Sie in unserem Hilfe-Center.
Was bedeutet das für Sie?
Für diese Postfächer sind bis zum 14.01.2024 Anpassungen in den Einstellungen Ihrer E-Mail-Programme oder der Software notwendig, welche die E-Mails versenden:
ich@meine-eine-Domain.de
auch-ich@meine-andere-Domain.de
Bitte stellen Sie bis zum 14.01.2024 sicher, dass in den Einstellungen Ihrer verwendeten Software identische E-Mail-Adressen für den Absender und die Authentifizierung am Postausgangsserver (SMTP) gesetzt sind. Wenn diese Adressen nicht übereinstimmen, werden betroffene E-Mails ab dem 15.01.2024 von unseren SMTP-Servern mit der Fehlermeldung „Sender address is not allowed." abgelehnt und nicht versendet.
Wie Sie diese Änderungen vornehmen können, haben wir in unserem Hilfe-Center für Sie zusammengefasst.
Leiten Sie diese E-Mail bei Bedarf bitte an die Nutzer der Postfächer oder den Verantwortlichen für Ihre E-Mail-Administration weiter.
Mit freundlichen Grüßen
Kundenservice IONOS
Zitat Ende
und nun?
"Und nun hörst Du auf, aus Deinem Outlook heraus Mails für irgendwas@irgendwer.irgendwo per SMTP mit den Zugangsdaten für eineganzbestimmteadresse@irgendwer.irgendwo einzuliefern. Jedes Mailkonto Deiner Domain muss seine Mails selbst einliefern."
(So interpretiere ich die Mail von IONOS)
und wo kann ich das in einem aktuellen Outlook überhaupt noch manuell so verbiegen? Der Assistent erlaubt das doch gar nicht.
Danke, dass das Thema aufgegriffen wurde. Habe mich im "Diskussions"-Forum (*ttps://www.borncity.com/blog/diskussion-allgemeines/) ja hier auch schon gemeldet.
Mein Kunde ist mit der Domain bei IONOS und nutzt einen Exchange mit vorgeschalteter Sophos XGS mit Mailprotection.
E-Mail Empfang geht mit Nichten per POP3, sondern direkt per MX-Record auf die Sophos XGS ein und dann zum Exchange.
Ausgehend schickt der Exchange an die Sophos XGS und die bisher per TLS1.2 zum IONOS-Relais.
Wir haben dort den info @ meinedomain.de User mit passendem Kennwort angegeben.
IONOS hat uns nun angeschrieben, wir würden über "info@meinedomain.de" mit ABWEICHENDER Absenderadresse schicken. Dies würde ab 14.01.24 nicht mehr funktionieren.
Der IONOS Support ist dort sehr inkompetent und versteht nicht, dass ich weder auf dem Exchange noch auf der Sophos pro Absender einen Smarthost-Eintrag anlegen kann.
Andere Kunden bekommen abweichende Aussagen – alles OK, so lange die Domain passt. Denke ich nicht. Wir wurden explizit, wegen der ABWEICHENDEN Absenderadresse angeschrieben.
Da weiß der eine nicht, was der andere tut. Das Problem mit IONOS ist, dass die so in ihrer "kleine Betriebe" Denke feststecken, dass sie an sowas nicht denken. Obwohl es Kunden nutzen, die einen eigenen Server, z.B. Exchange, haben.
Warum schicken wir nicht einfach "direkt"? Nun, da stellen sich, trotz korrekt gesetztem PTR-Record und SPF-Records vor allem die Privat-Mailer wie T-Online, GMX&Web.de und GMAIL etwas an. E-Mail abgewiesen mit "Bad reputation". Wir stehen auf keiner Blacklist.
Früher habe ich Exchange-Server immer – wenn möglich – zum direkten Senden eingerichtet. Nur wegen der Privat-Mailer und den großen Hürden nutzen wir das Relay. Privatmailer kommen halt bei Bewerbungen regelmäßig vor, ignorieren können wir das Thema nicht.
Was nun? Die GL ist am überlegen, bei IONOS zu kündigen. Wäre besser so.
"Der IONOS Support ist dort sehr inkompetent und versteht nicht, dass ich weder auf dem Exchange noch auf der Sophos pro Absender einen Smarthost-Eintrag anlegen kann."
Es könnte auch einfach sein, dass Du sehr inkompetent bist und nicht verstehst, dass IONOS das einfach nicht mehr will, dass Du Mails von diversen abweichenden Absendern über einen einzigen konfigurierten Mailaccount verschickst.
"Früher habe ich Exchange-Server immer – wenn möglich – zum direkten Senden eingerichtet. Nur wegen der Privat-Mailer und den großen Hürden nutzen wir das Relay. Privatmailer kommen halt bei Bewerbungen regelmäßig vor, ignorieren können wir das Thema nicht."
Was ist ein Privat-Mailer? Und wieso sollte ein Privat-Mailer irgendeinen Einfluss auf den Mailversand aus dem Exchange-Server heraus haben?
Die Hürden, die einem die arroganten Konzerne wie t-online auferlegen, sind da, aber nicht unlösbar. Gerade nicht für Unternehmen, die neben Mail auch noch einen passenden und rechtskonfromen Internetauftritt haben.
Zum Schluß ein Gruß an die GL: bei IONOS zu kündigen ändert nichts an der Ursache des Problems. Es verschiebt nur den Zeitpunkt, an dem es notwendig ist, sich endlich dem Problem zu stellen. Smarthost wird in der Zukunft auch bei anderen Anbietern verschwinden. Aus Sicherheitsgründen.
Also schafft IONOS nicht das SMTP Relay ab, sondern stellt nur sicher das die Absenderdomain mit der gehosteten Domain bei IONOS übereinstimmt.
Klingt doch prinzipiell super.
Wenn das wirklich so ist, ja.
Aber genau das ist – aufgrund der schlechten bzw. widersprüchlichen Kommunikation seitens IONOS – eben nicht klar.
Ein Kunde von uns hat seine Domain seit zig Jahren bei IONOS und erhielt ebenfalls diese Infoemail, obwohl er auschließlich emails der bei IONOS gehosteten Domain über ein Postfach eben jener Domain versendet.
Ein IONOS Vertrag kann durchaus mehrere Domains enthalten – schick wäre also wenn alle Domains EINES Vertrages mit einem Smarthost funktionieren würden. Ist ja auch nicht so, dass IONOS sowas nicht abbilden könnte – alleine das Wollen ist was anderes.
Was ich mich Frage, was macht IONOS eigentlich mit vServer und Dedicated Server Kunden? Bei denen steht nämlich das bisherige Smarthost-Verhalten sogar in der Hilfe von IONOS aufgeführt.
Also, wenn IONOS tatsächlich Smarth. ganz sperrt, wäre dass ein Supergau. Die Vorlaufzeit dies bei den Kunden zu Ändern, ist zu knapp, zumindest bei uns.
Sollte es nur um die Domäne gehen, dann dann sollte es ja eigentlich kein Problem sein, dass zu ändern. z.B. exchange@domaene.de
Sollte tatsächlich jetzt verlangt werden, dass die Absender Adresse 1 zu 1 passt, kann ich MultiSendCon von Serversolutions empfehlen. Dieser benutzt je nach Regelwerk verschiedene Smarth. Geht natürlich nur bei kleinen KMU, weil jeder Benutzer dann seinen eigenen Smarth. bekommt. Wollte ich noch mal anmerken.
Folgendes steht wenn ich in der Mail auf den Link für mehr Infos klicke:
" Was müssen Sie machen, wenn Sie ein E-Mail-Postfach in Verbindung mit einem E-Mail-Programm, einer Software oder eine E-Mail-App nutzen?
Wenn Sie in Ihrem IONOS Konto ein E-Mail-Postfach eingerichtet haben, müssen Sie in den Einstellungen Ihres E-Mail-Programms, Ihrer Software oder Ihrer E-Mail-App sowohl für den Empfang als auch für den Versand von E-Mails die E-Mail-Adresse eintragen, die Sie bei der Einrichtung des E-Mail-Postfachs erstellt haben.
Beispiel:
Sie haben bei IONOS die E-Mail-Adresse max.mustermann@example.com erstellt und verwenden in einem E-Mail-Programm wie z. B. Thunderbird oder Microsoft Outlook die E-Mail-Adresse kontakt@example.org als Absender. In diesem Fall müssen Sie statt der Absenderadresse kontakt@example.org die E-Mail-Adresse max.mustermann@example.com verwenden."
Hier wird also auch von verschiedenen Domains ausgegangen.
Ein Gehampel. Also mal ehrlich, wenn man als Firma so einen Quark macht, anstatt sich für ein paar Euros pro Jahr, eine Domain + Mailsystem zu leisten, dann tuts mir nicht leid drum.
Es muss ja auch gar nicht das ganz große Menü werden mit Rootserver mit eigenen OS + Mailserver und allem pipapo drauf. Beim Hetzner z.B. kostet das preiswerteste Angebot im Bereich Web & Management – Level 1 um die 30 EUs pro Jahr. Mit 100 Mailboxen und allem Standardfunktionen, welche so gängig sich.
Es mag sicherlich nicht für jede Konstellation/Anforderungen passen, aber zum tagtäglichen normalen Mailverkehr dicke ausreichend.
Ganz schön derbe Kommentare hier, teilweise. Möchte mir einer der Kollegen, die Smarthost-Versand als unsinnig/veraltet/blöd ansehen, einmal im Detail verraten, warum das so ist?
Mein gedanklicher Ausgangspunkt sind KMU mit Betonung auf "K". Mini-Netze mit teilweise nur 3-4 Clients. Für die gibt es lokale Mailserver-Systeme (kein Exchange), die zum Einen die damit verbundenen Vorteile einer zentralen Verwaltung & Datenhaltung bieten. Und durch die Kombination POP/Smarthost muss das lokale System (das meist hinter einer dynamischen IP sitzt) sich gar nicht zum Internet hin exponieren, sondern bedient sich standardisierter Schnittstellen. Simpel, sicher, wartungsarm. Was will man mehr? Und warum sollte man sich Klötze wie eigene MX-Einträge, offene Ports und fette Firewalls ans Bein binden? Nochmal: In großen Unternehmen sieht das natürlich anders aus. Aber beim kleinen Handwerksbetrieb?
Irritiert bin ich von der Meldung insofern, als dass eine ganze Reihe unserer Kunden bei IONOS sind, aber bislang keiner diese Info-Mail erhalten hat. Wir senden oft per Smarthost, aber immer nur mit identischer Domäne – sollte es sich also doch in erster Linie um den Versand mit "Fremd-Domain" handeln? Dann wäre dagegen ja im Grunde nichts einzuwenden, es irritiert mich ohnehin, dass das bei einigen Providern in der Form funktioniert.
However – falls es doch um die eigene Domain gehen sollte, hoffe ich inständig, dass die Konzerntochter Strato nicht auch auf diese Idee kommt. Mal schauen, was am Ende dann tatsächlich Sache ist.
Der kleine Handwerksbetrieb braucht keinen lokalen MTA mit zentraler Verwaltung und Datenhaltung, der sich dann gegenüber dem Provider wie ein MUA verhält. Jeder Rechner kriegt seinen MUA mit entsprechender Mailadresse samt Zugangsdaten und gut ist.
Smarthost birgt die Gefahr der missbräuchlichen Nutzung, weil er im Grunde als "open relay", wenngleich (hoffentlich) eingeschränkt auf eine Domäne, fungiert. Wessen Reputation leidet im Fall der missbräuchlicnen Nutzung? Richtig: die des Providers, der den Smarthost anbietet und mit wachsender Nutzerzahl ein exponentiell wachsendes Risiko hat, dass er sich seine IP-Adressen verbrennt.
btw: Das Feld, in dem sich die meisten Kommentatoren bewegen, erfordert Ellenbogen. Da wird das auch schon mal derbe, was nicht gleichzeitig bedeutet, dass man jemandem persönlich vors Knie treten will mit seiner – mitunter ganz bewusst gewählten – Formulierung. :-)
Also in einem Wort viele heiße Luft um fast nichts.
Also Tatsache ist es, dass die Mail keine Interpretation zulässt. Wenn der Inhalt der Mail stimmt wäre kein Relay mehr möglich. Alle unsere Kunden die noch einen lokalen Exchange Server haben, haben diese Mail erhalten. Diese Kunden senden nicht mit anderen Domains. Auch wir haben leider die Erfahrung gemacht, dass am Support quasi niemand bescheid weiß. Jedoch hat einer der Mitarbeiter uns schriftlich mitgeteilt, dass die Mail falsch wäre und es nur um den Domänenteil geht. Jetzt stellt sich natürlich die Frage wieviel so eine Aussage am Ende wert ist. Ich hoffe es gibt noch eine offizielle Klärung, denn falls die Aussagen der Support Mitarbeiter nicht stimmen würden diese Kunden auf ein massives Problem treffen.
Ich habe mal die IONOS-Presseabteilung auf den Artikel hier und die Kommentare hingewiesen und gebeten, das technisch zu klären und ggf. hier eine Klarstellung als Kommentar zu posten. Keine Ahnung, ob die reagieren.
Daumen hoch dafür. Danke, Günter.
Hallo,
ich hatte selbst auch bei ionos nachgefragt und eine Mail der Fachabteilung bekommen. Hier sind klar aufgelistet:
– eigene andere E-Mailadressen (mit selber Domain) gehen auch nach dem 15.01.2024
– fremde oder leere E-Mailadressen gehen nicht mehr.
In unserem Falle gab es 2 Fälle, die jetzt nicht mehr gehen:
– leerer Absender, und
– Absender einer externen Newsletter-Mail
Warum es diese 2 Fälle gab, weiß ich nicht. Eventuell war es auch ein SPF-Testfall an eine private Googlemailadresse. Daher haben wir wohl die E-Mail bekommen. Bewusst war mir das nicht. Da die Mail auch mit "identisch" falsch formuliert war, bin ich durcheinander gekommen, und dachte der Fehler sei Exchange.
Die erste E-Mail mit dem Wort "identisch" ist definitiv falsch. Wer die Mail bekommen hat, hatte wohl falsche Absender.
Also tatsächlich "viel heiße Luft", aber ionos hat leider die Mail nicht korrekt formuliert.
Grüße
IONS scheint ja echt nerven zu haben, Anfang Dez. eine derartige Umstellung bis Mitte Jan 2024 zu erzwingen.
Man kann von Microsoft ja halten was man will, aber so einen kurze Zeitraum hätte die sich nicht erlaubt. Abgesehen von der unklaren Kommunikation.
Gibt es denn alternativen? Vor allem einen SMTP Relay / Smarthost, den man auch so nutzen kann wie aktuell sein Email Konto bei Ionos, ohne z.b. 50 Domains alle zu Verifizieren per CNAME eintrag wie es bei amazon ses oder allem was ich sonst so geestet habe z.b. der fall ist? Ich nutze das bisher um Mails vom server wie kontaktformulare und systemmeldungen zu versenden ohne für jede webseite einen eigene smtp user/passwort zu setzen.
Bei Strato und bei der Telekom geht das noch.
Bei der Telekom ist das in den FAQ sogar ausßdrücklich dokumentiert:
"Eingehende Mails:
Es gibt viele Möglichkeiten, Ihre E-Mails zu externen Services umzulenken:
Weiterleitung: Sie können für jedes eingerichtete Postfach eine Weiterleitung auf eine andere E-Mail-Adresse einrichten.
POP3-Sammeldienst (POP3 Connector): Ihre Homepage-Postfächer sind alle über den Server "securepop.t-online.de" abrufbar (siehe Übersicht der Server).
MX-Record: Wenn der DNS-Eintrag "MX" geändert wird, werden alle Mails, die an Ihre Domain gesandt werden, an das im MX-Record eingetragene Ziel geleitet. Die MX-Records können Sie im Homepage Center unter Domains verwalten.
Ausgehende Mails:
Sie können E-Mails mit verschiedenen Absenderadressen über eine zentrale Authentifizierung des SMTP-Relayserver versenden. Hierfür stellen wir einen speziellen Postausgangsserver zur Verfügung:
SMTP-Server: securesmtprelay.t-online.de Port: 465 (Standard-Port), SSL / alternativ Port 25, TLS
Benutzername: Die vollständige E-Mail-Adresse eines Ihrer Homepage-Postfächer
Kennwort: das dazugehörige E-Mail-Passwort."
Das Problem , was mich da jetzt betrifft, wenn ich zur Telekom wechslen würde, ist das schlichtweg in der Zeit nicht zu schaffen, weil es zuviele Kunden bzw. eMail Adressen wären.
Ich hoffe immer noch, dass sich das ganze Thema in Wohlgefallen auflöst.
Muss man denn bei der Telekom auch jede Domain/Absender Email verifizieren? Wenn nicht, warum muss du das bei jedem Kunden einzeln bearbeiten? Bei mir ist es serverseitig, bedeutet der server sendet bisher alle emails über ein ionos Postfach als relay, mit verschiedenen absender emails.
Ionos hat die Mitteilung für die Umstellung am 15.01.2024 für „Mail Basic und Mail Business" hier veröffentlicht (Home…E-Mail…Meine E-Mails… und dann unter Allgemeine Themen):
https://www.ionos.de/hilfe/e-mail/allgemeine-themen/wichtige-aenderung-fuer-das-versenden-von-e-mails-mit-abweichender-absenderadresse/
Hiervon ist klar eigentlich, dass ein Exchange Connector nicht mehr funktionieren wird. Aber….gleichzeitig veröffentlichen sie die Bedingungen für „Shared Hosting Linux und Managed Server" hier (Home…Hosting… hier klick auf „Kein Versand von E-Mails mit abweichender Absenderadresse" im blauen Balken):
https://www.ionos.de/hilfe/e-mail/allgemeine-themen/kein-versand-von-e-mails-mit-abweichender-absenderadresse/
„Ihr IONOS Vertrag enthält die Domain example.com. Sie haben auf dem dazugehörigen Webspace ein Skript installiert, dass den Inhalt eines Kontaktformulars als E-Mail an Sie verschickt. Als Absenderadresse verwenden Sie eine E-Mail-Adresse von Gmail (Google Mail) mit der Endung @gmail.com.
Ab dem 15.01.2024 können Sie nur noch Absenderadressen in Ihrem Skript verwenden, die auf @example.com enden. E-Mails mit anderen Absendern werden nicht zugestellt. Der IONOS Postausgangsserver (SMTP) Server übermittelt in diesem Fall den folgenden Fehlercode: Sender address is not allowed"
Das würde evtl. die Relay (Smarthost) Funktion, mindesten für die Vertragsdomain, noch erlauben! Die Frage ist, ob die IP-Adressen aus dem Ionos-Bereich (und die Shared Hosting Linux und Managed Server haben eben solche Adressen) unterschiedlich vom Relay-Server smtp.ionos.de behandelt werden, als Adressen von anderen Internet-Provider….
Diese zwei Veröffentlichungen, die irgendwie nicht zusammenpassen, führen bestimmt zu Chaos bei den armen 1-Level Support bei Ionos. Die Einigen zitieren vermutlich aus der ersten Veröffentlichung und Andere aus der Zweiten. Beide haben etwas mit der Umstellung am 15.01.2024 zu tun.
Hallo zusammen,
wir stehen hier auch grad ziemlich im Regen. Sind allerdings eher ein GMU (größeres mittleres Unternehme :-)
Wir setzen hier auch einen lokalen Mailserver ein; allerdings Linux mit Relay-Server.
Unser Server holt die externen Mails per POP ab und werden dann intern in IMAP Postfächern verwaltet. Raus geht es per SMTP und Smart Host/Relay aus genau den Gründen, die hier schon Viele genannt haben.
Was an der Konstruktion schlecht sein soll will sich mir allerdings auch nicht erschließen.
Aber zurück zum eigentlichen Thema:
Ich lese die Nachricht von IONOS ebenso, dass ab Januar kein Relay mehr gehen wird. Auf eine telefonische Anfrage hat man mir gesagt, dass das eine Forderung von MS und Google sei. Wer ist das? Und haben die da zu bestimmen? :-)
Nun meine Frage:
Ich lese aus einigen Posts, dass vermutet wird, dass die IONOS Mail falsch sei und relay doch weiter funktionieren würde. Mag mir da wer eine Referenz nennen, aus der man das schließen kann?
Jemand eine Idee, wie das mit Mailweiterleitungen nach Extern dann aussieht?
Übrigens: Das was hier: https://www.ionos.de/hilfe/e-mail/allgemeine-themen/kein-versand-von-e-mails-mit-abweichender-absenderadresse/ beschrieben steht verstehe ich so, dass das Mails betrifft, die etwa von der Webseite per PHP versendet werden (etwa Kontaktformular). Das bezieht sich für mich in keinster Weise auf Relaying oder zumindest nicht zwingend.
Gruß
Fank
Hallo F(r)ank,
aus den schriftlichen(!) Antworten des Supports, wo mit Fallunterscheidungen es dem Kunden schön erklärt wird, da er die falsche IONOS Mail richtig verstanden hat, und völlig verwirrt war ;-)
Es kommt sicherlich noch eine bessere Stellungnahme in den nächsten Tagen. Wenn du sagst, dass es eine Forderung der großen Unternehmen ist, was auch die starre Frist erklärt und ggf. mit einem Whitelisting zusammen hängt, dann muss man sich eventuell noch abstimmen.
Ja, das ist wahr. Es ist nicht zwingend. Und auch nicht, dass hier auch die identische Absenderadresse nicht zwingend ist. Formulierungen a la IONOS, die nicht eindeutig sind. Ist denen die Auswirkung der Umstellung nicht bewusst? Es wird Tausende Firmen treffen, meiner Meinung nach.
Mindestens klären die Links, die ich gepostet habe die Aussagen aus dem IONOS-Mail, auch für diejenigen die die Mail nicht bekommen haben.
Alternative Relays (wie von Ihnen gelistet, MailJet) würde einen Kunden von mir 32€/Monat (netto) kosten, aber ohne eine Mehrleistung davon zu haben. Es ist schwer ihm zu vermitteln, was ein Relay Server macht und warum plötzlich Mehrkosten entstehen, die sogar über den Preis bei Ionos für seine Webseite/Domain liegen….
Und diejenigen, die einen hosted Server als Relay empfehlen, vergessen gerne den zusätzlichen Zusatzaufwand diesen Server ständig zu überwachen und zu patchen. Deswegen habe ich gerne den Ionos Relay Server verwendet, sobald der Kunde die WEB-Seite auch bei Ionos hatte.
Gruß, Nick
Richtig, vor allem ist bei den meisten Diensten weniger die Smarthost Funktion sondern mehr irgendwelches Tracking der Emails – also eher für Marketing/Newsletter Mails geeignet. Für meinen Zweck nichts und zu teuer. Und ein eigener Email Server, alles schön und gut, aber wenn man nicht die entsprechende Anzahl an Emails hat, wird es auch schwer hier z.B. bei google usw. durchzukommen. Lese ich immer wieder, dass die "großen" es kleinen E-Mail Anbietern und Servern damit extrem schwierig machen. Hatte damit nur probleme, von der Wartung usw. eines eigenen relay ganz zu schweigen. Deshalb habe ich mich nun für SES von Amazon entschieden. Bei 10.000 Mails für 1$ für mich keine Frage da ich diese eh nicht für Newsletter nutzen will. Evtl. mal ansehen
Vielleich hat diese plötzliche Betriebsamkeit bei Ionos (15.01.2024) mit der Verschärfung ab Februar 2024 bei Google und Yahoo zu tun:
https://www.braze.com/resources/articles/yahoo-and-gmails-2024-new-sending-requirements
Und Ionos bietet nicht mal DKIM an. Sie beschreiben nur (ziemlich dreist meine nicht nur ich), wie man den DKIM-Schlüssel beim Provider anfordert):
https://www.ionos.de/digitalguide/e-mail/e-mail-sicherheit/dkim-domainkeys/
Das wird ab Februar 2024 für Google und Yahoo Mailserver für Absender von mehr als 5000 Mails/Tag Pflicht, so lese ich das hier:
„For those senders attempting to send more than 5,000 emails per day to either the Yahoo or Gmail platform, both mail providers will require that all emails be fully authenticated with SPF (Sender Policy Framework), DKIM (Domain Keys Identified Mail), and DMARC (Domain-based Message Authentication, Reporting and Conformance).
Ich habe mir nun SES von Amazon geholt, 10.000 Emails liegen bei 1$ ich muss zwar alle Domains dort per Cname Eintrag validieren, aber ansonsten kann ich dann mit den selben SMTP Daten von allen Emails die auf die jeweilige Domain laufen aus E-Mails versenden. Tests zeigen, dass diese ohne Probleme ankommen, auch z.B. bei gmail, wo ich davor mit eigenem E-Mail Server immer wieder Probleme hatte. Evtl. für euren Anwedungsfall ja auch nutzbar, einfach die SMTP Daten ändern, fertig.
In diesem Artikel beschreibt Ionos, was in Outlook eingestellt werden müsste, um nach 15.01.2024 weiterhin Mails senden zu können:
https://www.ionos.de/hilfe/e-mail/absenderadressen-aendern/absenderadresse-in-outlook-20162019-pruefen-und-aendern/
Und hier ist ganz klar, dass das Feld Benutzername/Emailadresse (= MAIL FROM: ) identisch mit dem Feld Anmeldeinformationen/Benutzername (= AUTH LOGIN …334…) sein muss.
In diesem Beispiel ist eindeutig dieselbe Mail-Domain für Absender und Authentisieren als Beispiel angegeben (kontakt@example.org und max.mustermann@example.com), was nicht mehr funktionieren wird.
Wenn, der IONOS Anleitung nach, Outlook es nicht mehr schafft mit unterschiedlichen Anmelde- und Absenderadresse eine Mail zu senden, dass schafft es auch keinen Connector mehr…
Man sieht also, wieviel Wert die Aussagen der Ionos-Hotline haben („Wird die Domain bei IONOS gehostet, ändert sich nichts" oder ähnliches…). Auch ein Kunde von mir hat eine ähnliche Antwort von der Hotline bekommen und rief mich verwirrt an. Das ist doch nicht Schrödingers Katze, die sowohl tot ist und gleichzeitig lebt!
Ich denke, dass es leider eindeutig ist, dass Smarthost/Mail-Relay bei Ionos Geschichte ist…
Deswegen…"Action": Ersatz muss her! Der SES von Amazon scheint eine interessante Alternative, sowohl preislich als auch sehr wahrscheinlich in Hinsicht auf Reputation => gute Zustellbarkeit. Ich werde diese Lösung auch probieren.
Postfix kann das sasl-Login am Smarthost per Sender E-Mail Adresse in der main.cf steuern:
smtp_sender_dependent_authentication = yes
Danach die Absenderadressen , Loginnamen Passwörter in die sasldb einpflegen.
Ich habe das für mich erweitert und mir einen smtp-proxy-gebaut, der auf Port 587 E-Mails annimmt und nur ein festes user/password login zur Sicherheit nutzt.
Danach leitet postfix z.B. zu IONOS oder, wie in meinem Test zu Hetzer per SMTP weiter.
Je nach "mail from" werden aus der sasldb die entsprechenden Logindaten für den Smarthost genutzt. Und schon geht Exchange -> postfix-smtp-proy -> smarthost.
Alternativ habe ich in einer anderen Windows only Umgebung MutliSendCon als proxy laufen.
Inzwischen scheint sich ionos klar zu sein, welche Verwirrung von ihnen gestiftet worden ist. Neue Anschreiben sehen so aus:
—
Aktion erforderlich: Passen Sie die E-Mail-Einstellungen Ihrer Webspace-Applikationen an
Hallo xxx xxx,
um die Sicherheit für alle Kunden zu erhöhen, ist ab dem 15.01.2024 der E-Mail-Versand aus dem Webspace nur noch mit Absenderadressen möglich, die mit einer Domain aus Ihrem IONOS Vertrag verbunden sind. In folgendem Vertrag werden aktuell vertragsfremde Domains als Absender oder leere Absender verwendet:
Vertragsnummer: xxxxxxx
Als vertragsfremde Domains bezeichnen wir Domain-Namen, die sich nicht im oben genannten IONOS Vertrag befinden. E-Mails, die als Absenderadresse eine vertragsfremde Domain oder keinen Absender verwenden, können von anderen Anbietern abgelehnt oder als Spam eingestuft werden. Wenn viele solcher E-Mails über einen Mailserver versandt werden, wirkt sich das möglicherweise negativ auf die Zustellbarkeit aller E-Mails aus.
Was bedeutet das für Sie?
Egal, ob Sie E-Mails über ein Kontaktformular oder den Webspace versenden, stellen Sie bitte bis zum 15.01.2024 sicher, dass Ihre Anwendungen nur noch E-Mail-Adressen mit einer Domain aus Ihrem IONOS Vertrag als Absender verwenden. Weitere Informationen dazu finden Sie in unserem Hilfe-Center.
Wichtig: Nach dem Stichtag können aus dem Webspace keine E-Mails von einer Adresse mit einer vertragsfremden Domain verschickt werden. Dies gilt auch für leere Absenderadressen.
Leiten Sie diese E-Mail bei Bedarf an die Zuständigen der Administration Ihrer Websites und Webprojekte weiter.
Mit freundlichen Grüßen
IONOS Kundenservice
—
Jetzt ist es eindeutig: Es betrifft nur den local part und der muss im Vertrag enthalten sein.
Guten Morgen,
so eindeutig würde ich das jetzt nicht sehen….
Ich hab heute um 00.37 ne eMail vom Ionos Support auf meine Anfrage bekommen, da steht das Gegenteil drin:
Hallo xxx xxxx,
vielen Dank für Ihre Anfrage.
Die E-Mail, die Sie von uns bekommen haben, ist eine allgemeine Information und eine Aufforderung zur Überprüfung Ihres E-Mail-Accounts. Hintergrund ist folgender:
Um Sie als unseren Kunden zu schützen, werden wir zum Versenden von E-Mails nur noch Adressen unterstützen, die via SMTP authentifiziert sind. Das bedeutet, dass die Versand-Mail-Adresse die gleiche Domain-Endung (Teil nach dem @) haben muss, die auch die Adresse hat, die in unserem Mail-System hinterlegt ist. Auch das Leerlassen der angegebenen Versandadresse (Aliasadresse) ist nicht möglich, wenn diese von einem Programm verlangt wird.
Ab dem 15.01.2024 tritt die Abschaffung von "Mail Spoofing" in Kraft.
Anbei die genaue Erklärung und Anleitung wie Sie es anpassen können auf Ihren E-Mail-Programmen:
https://www.ionos.de/hilfe/index.php?id=5380
Wenn Sie den Link nicht mit einem Klick aufrufen können, kopieren Sie ihn einfach und fügen Sie ihn in die Adresszeile Ihres Browsers ein.
Freundliche Grüße
Granit Fetaj
IONOS Kundenservice
Man weiß langsam nicht mehr was jetzt stimmt. Für mich ist dieser xxx Laden jetzt erledigt, ich werde meine Verträge kündigen und zu einem anderen Hoster wechseln.
Hallo Oliver,
IONOS beseitigt nur den offensichtlichen Fehler und alles ist gut.
Jetzt ist doch nur noch die Frage, ob:
– die Domain (@xyz.com) identisch sein muss, oder
– mehrere Domains im Vertrag erlaubt sind.
Damit ist erstmal ein Großteil der Unsicherheit raus. Ricos Antwort wurde hier auch schon genannt, und ist ja die sinnvollste Lösung.
Wenn du dir unsicher bist, frage den Support doch bitte, wie das jetzt mit 2 Domains im Vertrag ist. Und bitte ggf. den Fall durch die Fachabteilung beantworten zu lassen, da du unterschiedliche Antworten gehört hast. Dann sollte es passen :-)
Ich finde das Vorgehen gut. Bevor es Probleme mit der Zustellung gibt. Die gab es ja auch mal…
Das mit mehreren Vertragsdomains dürfte so zutreffen, wenn man hier schaut:
https://www.ionos.de/hilfe/e-mail/allgemeine-themen/kein-versand-von-e-mails-mit-abweichender-absenderadresse/
Unter "Was muss geändert werden?" schreibt IONOS:
"Tragen Sie für E-Mail-Adressen eine Absender-Adresse ein, die eine Vertrags-Domain verwendet. Wichtig ist, dass der Teil nach dem @-Zeichen der E-Mail-Adresse zu einer Domain aus Ihrem Vertrag gehört. Wenn Sie unter der gleichen Vertragsnummer weitere Domains haben, können Sie auch diese E-Mail-Adressen verwenden."
Das ist für mich eindeutig ein Beleg, vor allem der letzte Satz ist hier bedeutsam.
Warum IONOS an verschiedenen Stellen allerdings verschiedene Aussagen trifft, muss man nicht wirklich verstehen :-(
Hallo zusammen,
für die, die das Glück haben ein postfix basiertes Mailsystem zu betreiben, da habe ich inzwischen eine Lösung gefunden, getestet und ausgerollt:
https://gist.github.com/zmwangx/2c56aa32be68daf48c2f?permalink_comment_id=1913889
Mit ein wenig Ahnung von postfix sollte man das umsetzen können.
Danke an @commodity bei administrator.de
Ein paar Baustellen bleiben möglicherweise noch wenn man etwa mit Mailweiterleitung, Abwesenheitsbenachrichtigung etc arbeitet. Das sollte man sich gezielt anschauen ob es geht.
Viele Grüße
Frank
Bei Frankysweb gibt es eine Konkretisierung. Mail relay / smarthost geht nach wie vor bei Ionos, wenn man sich an die folgenden Voraussetzungen hält:
https://www.frankysweb.de/ionos-stellt-smarthost-funktion-zum-15-01-2024-ein/#comment-125182
Jetzt kommt (endlich) auch von Ionos die Klärung:
https://www.ionos.de/hilfe/e-mail/allgemeine-themen/wichtige-aenderung-fuer-das-versenden-von-e-mails-mit-abweichender-absenderadresse/
SMT-Relay mit dem Ionos-Mailserver scheint jetzt auch nach dem 15.01.2024 zu funktionieren. Es wird sogar als Beispiel (mit Exchange) dargestellt:
"Ich verwende einen SMTP-Relay-Server, Mail-Relay-Server oder Smarthost
Ein SMTP-Relay-Server (alternative Bezeichnung: Mail-Relay-Server oder Smarthost) ist ein Mailserver, der E-Mails von einem Sender annimmt und an Dritte zustellt. Ein Beispiel ist z.B. Microsoft Exchange.
Für die Verwendung muss ein E-Mail-Postfach (relay-Adresse) und ein IONOS SPF-Eintrag in der gleichen Domain angelegt sein.
Beispiel: Die relay-Adresse beispiel@example.com benötigt einen SPF-Eintrag unter example.com.
Wie Sie einen SPF-Eintrag anlegen, erklärt Ihnen der Hilfe-Center-Artikel "IONOS SPF – Damit Ihre E-Mails gut ankommen"
Die E-Mail-Adressen, die den SMTP-Relay-Server nutzen, müssen zur gleichen Domain gehören wie die am Mailserver hinterlegte relay-Adresse."
Nun hoffentlich bleibt es dabei, nachdem (fahrlässig, meiner Meinung nach) man uns bei Ionos zuerst mit der Änderung am 15.01 verrückt gemacht hat, mit einem Artikel, der falsche Behauptungen verbreiterte ("identische Anmeldung und Absender Adresse"). "Danke" Ionos!
Schaut man sich das Hilfedokument welches heute (14.12.23) im Netz liegt an, so ist 1&1 hier wohl zurückgerudert.
Dort heißt es jetzt klipp&klar:
#################################################################################
Beispiel
Sie haben ein E-Mail-Postfach mit der E-Mail-Adresse max.mustermann @ example.com eingerichtet. Diese Adresse wird auch für die Authentifizierung am IONOS Postausgangsservers (SMTP) verwendet. Als Absenderadresse verwenden Sie eine E-Mail-Adresse von Gmail (Google Mail) mit der Endung @ gmail.com.
Ab dem 15.01.2024 können Sie nur noch Absenderadressen verwenden, die auf @ example.com enden. E-Mails mit einem anderen Absender, wie die im Beispiel verwendete @ gmail.com, werden nicht mehr zugestellt. Der IONOS Postausgangsserver (SMTP) übermittelt in diesem Fall den folgenden Fehlercode: Sender address is not allowed.
#################################################################################
Ich hoffe mal sehr, dass dies jetzt den korrekten Sachstand wiedergibt.
Hallo, was aber immer noch nicht klar ist, ich habe Kunden die haben bei Ionos in einem Vertrag mehrere Domains z.B. Domain.com und Domain.de.
Bis jetzt konnte mit beiden Adressen über ein Smarthost bei Ionos gesendet werden.
Jetzt ist die Frage bleibt es weiterhin bei einem Smarthost oder muss ich für jede Domain einen separaten Smarthost anlegen?
Übrigens, hat Ionos den Termin anscheinend auf den 29.1.24 verschoben.
https://www.ionos.de/hilfe/index.php?id=5380&utm_rid=c31efd46-e8d7-44b5-bdd6-f7de6ce61090#c234239
Gruß Christian
Hallo
ja danke das ist genau meine Frage zu der ich nichts verlässliches gefunden habe. Einmal Smarthost bei Ionos für Domain.com aber über den Exchange werden auch Mails von Domain.de verschickt.
Könnte man für jede gewünschte Domain einen separates Ionos Postfach nehmen und wie sähe das dann im Exchange aus?
Gruß Andreas
IMHO betrifft es hauptsächlich "Weiterleitungen". Das ist bei anderen Anbietern schon länger der Fall. Ich habe z.B. mal parallel mit United-Domains getestet.
Beispiel, man betreibt "@meinedomain.de". Dort gibt es auch Konten wie bspw "user@meinedomain.de"
Nun kommt eine eingehende Mail an user@meinedomain.de und wird passend an den Server zugestellt. Soweit kein Problem. Das funktioniert auch, wenn mehrere Domains beim Anbieter registriert sind, Hauptsache, der Relay Anbieter KENNT diese Domains selber.
Nun verschickt user@meinedomain.de eine Mail an irgendwen@gmx.de. Es wird der Relay server dazu verwendet. Auch kein Problem, denn meinedomain.de ist über den Relayserver konfiguriert, bzw beim Provider angemeldet.
ABER und das wird jetzt ein Problem, der Zustellungsweg läuft mit Umleitung/Weiterleitung
Beispiel:
Es kommt eine e-Mail von absender@google.com -> user@meinedomain.de UND soll dort gleich weitergeleitet werden an -> user@gmx.de (entweder über einen Alias oder über Nutzersetting als E-Mail Weiterleitung). DAS geht jetzt nicht mehr. Denn der Absender im Relay ist nun nicht mehr xxx@meinedomain.de sondern "absender@google.com" und wird daher abgelehnt.
Ich denke in diese Richtung geht es morgen. Frage nur: wie gehe ich jetzt in Zukunft genau mit diese Weiterleitung um?
Entweder indem du sie seinlässt, oder auf deinem Server SRS einrichtest.
Problem bei Newslettern (ja, sowas gibt es noch).
Empfänger hat z.B. user@gmx.de oder user@web.de und will explizit auch nur diese E-Mail für den Newsletter offenbaren, leitet dort aber alles weiter zu einer user@gmail.com E-Mail.
Derzeit lehnt Google dann solche E-Mails ab, auch wenn der Newsletter Ansender SPF korrekt ist, da die E-Mail für Google ja nicht vom Newsletter kommt sondern von gmx/web.de und dann bounced alles inklusive der Weiterleitungs Ziel E-Mail Adresse zum Newsletter Absender (und verrät so auch das Weiterleitungsziel).
Hallo, ich hänge mich mal an diesen älteren Beitrag ran. Seit vorgestern haben die ja den Ionos Smarthost umgestellt. Wir haben brav vorab alles getan was nötig war.
Jetzt ist es aber so, dass (alle) Mailserver bestimmte Nachrichten RFC-konform mit leerem Absender versenden müssen. Das betrifft z.B. Unzustellbar-Nachrichten (NDRs) und auch Outlook Abwesenheitsbenachrichtigungen.
Diese können wir seit vorgestern nicht mehr versenden, Ionos lehnt das mit der Begründung Sender nicht erlaubt ab.
Ja, die haben vorher gesagt dass leere Absender verboten sind. Ich habe nicht bedacht, dass bei NDRs usw. der Absender immer leer sein muss.
Hat noch jemand das gleiche Problem?
Kann man Exchange so konfigurieren, dass auch bei diesen Nachrichten ein Absender eingetragen wird? Darf man das überhaupt? Sollte nicht Ionos diese RFC-konformen Nachrichten eigentlich erlauben?
Bin ziemlich ratlos und für jeden Tipp dankbar.
Konfiguriere einfach die externe Postmasteradresse des Exchange Servers:
https://learn.microsoft.com/de-de/exchange/mail-flow-best-practices/configure-external-postmaster-address
Moin,
dies funktioniert nicht. Mail From bleib bei oof leer.
Moin,
funktioniert bei oof hier nicht. Leider.
wir haben es mit multisendcon gelöst. In exchange selber konnten wir keinen Weg finden.
Moin,
wir setzten auch Ionos bei den Kunden als SmartHost über einen MailGateway ein.
Grundsätzlich funktioniert der Versand darüber wenn nach dem @ die gleiche Domain verwendet wird.
Jedoch mussten wir nun feststellen dass der Versand der oof (Out of Office) Mails abgeleht werden da diese keine Mail From enthalten und zwingend Notwendig ist für Ionos, seit der Änderung.
Auf Rückmeldung des Supports warten wir weiterhin.
Dass oof kein Mail From setzt ist "Standard" und konform, Stichwort: RFC 2298.
ich bin betroffen. nach fast 30 Jahren ohne Probleme wurde mir die Möglichkeit genommen die Emails meiner .cx-Domain über Ionos zu versenden. Das Geld nehmen sie aber schon.
Ich bin also auf der Suche nach einem Relay, das ich entsprechend konfigurieren kann, also weitere erlaubte Domains zu der verwendeten. Bei Ionos habe ich bisher keine entsprechende Option gefunden. Ich würde sogar meine .cx-Domain dorthin umziehen, aber diese TLD haben sie nicht im Angebot.
Microsoft M365 scheint das zu können, ist aber unendlich kompliziert…
bei MailJet, einem Massenmail-Versender und über SMTP geht da nichts, obwohl ich alles nach Vorschrift konfiguriert habe. Der Support von dort hat sich immerhin gemeldet, aber ich denke ich habe das falsch verstanden mit dem Relay dort.
Wird sich bei dem Thema oof noch etwas tun?
Der IONOS Support scheint das Problem bislang nicht zu verstehen (zu Beginn wollten sie helfen, ein Konto in Outlook einzurichten) und antwortet sehr zäh.
Hat jemand einen besseren Supporter bei IONOS erwischt?
Oder bleiben nur die Möglichkeiten:
– Umstellen auf Direktversandt
– Wechseln des SmartHost-Providers?
Hat hier einen anderen Lieblings-SmartHost-Provider?
Ich habe am 31.1. eine Mail an den Support geschickt und seither frage ich regelmäßig nach. Eine Antwort bekomme ich aber nie. Nur einen Hinweis, dass das Support-Aufkommen derzeit hoch sei. Das ist wirklich unter aller Kanone was die da abliefern. Die konfigurieren ihren Smarthost entgegen der RFC und wundern sich dann über das Support-Aufkommen. Leider liegt es nicht in meiner Macht den Anbieter zu wechseln, da ich "nur" für die Mailserver zuständig bin. Sonst wäre ich von dem Verein schon längst weg.
so funktioniert es weiterhin:
"Sobald Sie auf den Smarthost (smtp mail relay) unsere Domain nutzten, dann wird das weiterhin funktionieren.
… die Konfiguration von smtp.1und1.de auf smtp.ionos.de zu ändern."
Sie können auch ab dem 15.01.2024 über uns via Mail Relay / Smarthost senden. Gerne nenne ich Ihnen hierzu die Voraussetzungen:
1.) Bitte stellen Sie sicher, dass Sie bei uns ein Postfach angelegt haben, das sie als Mail Relay nutzen. Beispiel: „versand@ihredomain.tld"
2.) Bitte stellen Sie sicher, dass auf der Domain Ihres Mail Relay Postfachs ein IONOS SPF-Eintrag gesetzt ist: https://www.ionos.de/hilfe/domains/mailserver-und-verwandte-records-konfigurieren/spam-versand-vermeiden-mit-spf-record/
3.) Ihre Mail Relay Adressen müssen dieselbe Domain nutzen wie auch Ihr Mail Relay Postfach („versand@ihredomain.tld")
Beispiel: Sie möchten über die Adressen „info@ihredomain.tld", „mail@ihredomain.tld", „rechnung@ihredomain.tld" senden. Hierzu benötigen Sie mindestens ein Mail Relay Postfach bei IONOS, welches den Domain Part „ihredomain.tld" nutzt.
Freundliche Grüße
IONOS Kundenservice
Auf weitere Anfrage erhielt ich die Antwort, dass jedes existierende IONOS-Postfach auch als Mail Relay Postfach genutzt werden kann.
Das SMTP-Relay funktioniert schon. Die OOF Nachrichten werden aber nicht mehr weitergereicht. Diese entsprechen laut IONOS nicht den Anforderungen (Punkt 3). Wie haben Sie das gelöst?
CFX
Wir haben es mit MultiSendcon gelöst. In Exchange selber, haben wir leider keinen Weg gefunden
Hat hier jemand eine Lösung gefunden, wie man es einstellen kann, dass die Abwesenheitsnotiz/OOF mit einer E-Mail-Adresse anstelle von leer versendet wird?
Danke.
Ich schließe mich den letzten beiden Einträgen mal an, Gibt es schon eine Lösung? habe den Postmaster via Set-TransportConfig -ExternalPostmasterAddress angepasst, aber Problem besteht weiterhin.
Vielen Dank
Wir haben es mit MultiSendcon gelöst. In Exchange selber, haben wir leider keinen Weg gefunden
Wir senden die ausgehenden Mails über Postfix. Postfix übernimmt dann die Authentifizierung gegenüber dem SMTP Server von Ionos.
Das ganze lief erst über Sender-based Routing und wurde wegen den MS OOF-Mails, auf statisches Versenden über einen fest definerten Account abgeändert (sender_canonical_maps = static:connector@blablabla.com).
Somit wird das Problem dass die Abwesenheitsnotiz/OOF mit (from ><) versendet wird umgangen. Ich hoffe das hilft ;-)
Gruß Meditux
Tatsächlich kann man sowohl das Problem mit leeren Absenderaddressen für Unzustellbarkeitsnachrichten und Urlaubsbenachrichtigungen als das Problem mit mehreren Domains im gleichen Exchange mittels MultiSendcon lösen.
MultiSendcon Lite ersetzt den leeren Absender automatisch mit dem Absender aus der Email oder mit einem fest konfiguriertem Absender aus dem MultiSendconAdmin. Und falls man mehrere Domains im Exchange hat, dann kann die große MultiSendcon Version für jede Absenderdomain verschiedene SMTP Anmeldedaten für IONOS verwenden.