Netcup Mail-Server in wiederholt in Spam-Blacklist bei Microsoft/Hotmail

Zitat von komischer_Vogel

Was willst Du uns/mir damit sagen?

Bitte entschuldige meinen, doch sehr trockenen Humor zu diesem Thema.

Die Frage ist doch: was erwartest du von einem shared Hosting / shared Mail Exchange mit offensichtlichem Clientel als Zielgruppe? Du kriegst genau das, wofuer du bezahlst, nicht mehr und nicht weniger -- und das ist noch nicht einmal wertend gemeint.

Als jemand, der regelmaessig seine Mitmenschen mit IT-Sicherheit nervt, biete ich immer folgende Metapher an: IT-Sicherheit ist wie eine Kette, sie ist nur so stark, wie ihr schwaechstes Glied + IT-Sicherheit ist ein Prozess, kein Produkt. Wenn also ein Kunde auf dem shared MX ein schwaches Passwort nutzt, kompromittiert wird oder anderweilig die Integritaet (https://de.wikipedia.org/wiki/Integrit%…nssicherheit%29) ueber seine Mails verliert und daraufhin zur Spamschleuder wird, muessen alle anderen Benutzer auf dem MX mit den Folgen leben und die Folgen mittragen.

Wenn du mehr haben willst, musst du entweder dafuer bezahlen bzw. einen Dienstleister auswaehlen, der sich darauf spezialisiert hat oder einen eigenen dedizierten Mailserver zu betreiben, was mittlerweile so einfach, wie nie geworden ist. Man muss noch nicht mal viele Kenntnisse mitbringen. Es genuegt schon, wenn man rudimentaer mit der Shell umgehen kann und ein grundliegendes Verstaendnis fuer Linux und E-Mail mitbringt. Eine super Anleitung fuer den Betrieb eines eigenen Mailservers gibt es seit zig Jahren vom Kollegen Christoph Haas (https://workaround.org/).

Zitat von komischer_Vogel

Wenn ich als Laie über die netcup-Server Mails unter völlig fremden Domains versenden kann

Was genau meinst du eigentlich damit?

Zitat von ckd

Eine super Anleitung fuer den Betrieb eines eigenen Mailservers gibt es seit zig Jahren vom Kollegen Christoph Haas

Die hatte ich angefangen zu lesen aber ich wollte kein webmail, kein redis und kein php und als datenbank sqlite3 - das hab ich mir dann selbst gebaut mithilfe der halluzinierenden KI und ich bin soweit zufrieden mit meiner Fata Morgana.

Vielleicht habe ich mich ja missverständlich ausgedrückt. Ich bin echt kein Profi.

Ich habe aber nun auch schon 6, 7 verschiedene Hoster samt deren Mailservern durch, von Standards wie s trato, df, manitu, dogado über irgendwelche kleineren wie greensta. Bei keinem konnte ich Mails für fremde Domains versenden und habe konsequenterweise solch eine Fehlermeldung (oder eine ähnliche) bekommen:

Screenshot zu Ablehnung meiner Mail durch strato.png


Ist dieses Mailserververhalten, also die Ablehnung, wirklich eher die Ausnahme oder doch die Norm? Ich frage aus echtem Interesse.

Zitat von komischer_Vogel

Ist dieses Mailserververhalten, also die Ablehnung, wirklich eher die Ausnahme oder doch die Norm? Ich frage aus echtem Interesse.

Du darfst nur ueber den Alias versenden, der deinem Konto zugewiesen ist.

Zitat von komischer_Vogel

Ist dieses Mailserververhalten, also die Ablehnung, wirklich eher die Ausnahme oder doch die Norm?

Das war vor nicht langer Zeit bei dem von dir genannten anderen Anbieter möglich, aber jetzt bekommst du da die gezeigte Fehlermeldung. Die Konventionen ändern sich. Das Missbrauchspotential von "ich weiß wer der Absender ist, also darf der von beliebigen Adressen verschicken" war wohl zu offensichtlich.

Das Kernproblem, das du beschreibst, ist, dass man den Emails unter Nutzung aller technischen Antispam-Maßnahmen nicht ansehen kann, dass der Absender nicht der Domaininhaber ist, wenn eine fremde Domain genutzt wird, deren Mail beim selben Anbieter gehostet wird. Die wird dann über den korrekten Server verschickt und besteht auch sonst alle Antispam-Tests, aber der Eigentümer der Domain hat damit nichts zu tun. Wenn man also Mails im Namen eines anderen Netcup-Kunden verschicken will (und herauszufinden, dass jemand Netcup-Kunde ist, ist trivial), dann mietet man sich ein Webhosting hier und legt einfach los. Kein Automatismus hält einen davon ab oder warnt die Empfänger.

Andererseits ist die Möglichkeit, im Namen anderer Domains, die man nicht bei Netcup hostet, verschicken zu können, ungemein praktisch, und Netcup kann im Bedarfsfall natürlich schon herausfinden, wer die Mails wirklich verschickt hat. Netcup hat die Abwägung noch zugunsten der Funktionalität getroffen, aber ich würde nicht wetten, dass das noch lange so bleibt.

Zitat von ckd

Du darfst nur ueber den Alias versenden, der deinem Konto zugewiesen ist.

schon. hier ist aber gemeint, daß man mit beliebigem FROM senden kann.

Zitat von Olivetti

schon. hier ist aber gemeint, daß man mit beliebigem FROM senden kann.

Das war wohl missverstaendlich von mir formuliert. Ein korrekt, konfigurierter Mailserver ueberprueft, von welcher E-Mail Adresse der User senden darf und wuerde die Mail ansonsten verwerfen.

Zitat von ckd

Ein korrekt, konfigurierter Mailserver ueberprueft

Die Überprüfung der Absenderdomain anhand des angemeldeten Accounts ist wie schon geschrieben auch bei anderen Anbietern erst neuerdings* obligatorisch. Der Mailserver war auch vorher korrekt konfiguriert, aber man beugt sich mittlerweile der Situation, dass die gängigen Methoden zur Erkennung von gefälschten Absendern an dieser Konfiguration scheitern, weil die Erkennung am absendenden Server und nicht am Account des Absenders festmacht.

*) seit 2024 beim genannten Anbieter

Zitat von ckd

Das war wohl missverstaendlich von mir formuliert. Ein korrekt, konfigurierter Mailserver ueberprueft, von welcher E-Mail Adresse der User senden darf und wuerde die Mail ansonsten verwerfen.

Wie gesagt, ich habe das heute vom meinem netcup-Account ausprobiert und konnte beliebige Email-Adressen nutzen, auch Email-Adressen, bei denen die Domain nicht hier gehostet ist und auch nicht (mehr) in meinem Besitz. Ich habe, dass nur getestet, weil ich eine Formulierung eines Users so verstanden hatte, dass dies möglich sei und ich konnte das eigentlich nicht glauben.

Zitat von komischer_Vogel

meinem netcup-Account ausprobier

über welchen sendeserver hast du denn gesendet? was steht im header?

Zitat von NaN

Die Überprüfung der Absenderdomain anhand des angemeldeten Accounts ist wie schon geschrieben auch bei anderen Anbietern erst neuerdings* obligatorisch. Der Mailserver war auch vorher korrekt konfiguriert, aber man beugt sich mittlerweile der Situation, dass die gängigen Methoden zur Erkennung von gefälschten Absendern an dieser Konfiguration scheitern, weil die Erkennung am absendenden Server und nicht am Account des Absenders festmacht.

*) seit 2024 beim genannten Anbieter

Danke für diese tolle und verständliche Antwort. Tatsächlich habe ich es dann wohl erst nach 2024 bei s t rato probiert, aber ich weiß, dass das bei greensta zumindest damals (um 2015) nicht funktionierte. Da war es tatsächlich eine Verwechselung von mir, es zu versuchen. Deshalb bin ich immer davon ausgegangen, dass das normal ist, so "etwas" abzufangen.

Ich lerne wirklich gerne. Worin liegt denn ein praktischer Use Case für solch ein Verhalten?

Zitat von ASS

über welchen sendeserver hast du denn gesendet? was steht im header?

s********r.de ist die fremde Domain über die ich nicht mehr verfüge.

Den Rest kannst Du aus dem Header entnehmen.

Return-Path: <webmaster@s********r.de>
Authentication-Results: web.de; dkim=none; spf=fail
smtp.mailfrom=webmaster@s************r.de; dmarc=none
header.from=s**********r.de; iprev=pass policy.iprev=188.68.63.170
Received: from relay.yourmailgateway.de ([188.68.63.170]) by mx-ha.web.de
(mxweb006 [212.227.15.154]) with ESMTPS (Nemesis) id 1M75XX-1wYDLb3I7z-005V09
for <th***.***@web.de>; Thu, 18 Jun 2026 10:26:40 +0200
Received: from mors-relay8203.netcup.net (localhost [127.0.0.1])
by mors-relay8203.netcup.net (Postfix) with ESMTPS id 4ggv2m2F5xz8f2Z
for <th***.***@web.de>; Thu, 18 Jun 2026 08:26:40 +0000 (UTC)
Received: from policy02-mors.netcup.net (unknown [46.38.225.35])
by mors-relay8203.netcup.net (Postfix) with ESMTPS id 4ggv2P6BcYz8fNl
for <th***.***@web.de>; Thu, 18 Jun 2026 08:26:21 +0000 (UTC)
Received: from mx2fe4.netcup.net (unknown [10.243.12.53])
(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256)
(No client certificate requested)
by policy02-mors.netcup.net (Postfix) with ESMTPS id 4ggv2P0yTtz8sch
for <th***.***@web.de>; Thu, 18 Jun 2026 10:26:21 +0200 (CEST)
Received: from [IPV6:::1] (p200300cd7f4422ce104f426028e8c627.dip0.t-ipconnect.de [IPv6:2003:cd:7f44:22ce:104f:4260:28e8:c627])
by mx2fe4.netcup.net (Postfix) with ESMTPSA id 7A15380883
for <th***.***@web.de>; Thu, 18 Jun 2026 10:26:20 +0200 (CEST)
Received-SPF: pass (mx2fe4: connection is authenticated)
Message-ID: <3558e029-6f81-4dbc-ac4c-b2d7f1f1e4c1@st********r.de>
Date: Thu, 18 Jun 2026 10:26:20 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Content-Language: de-DE
To: th***.***@web.de
From: Th <webmaster@st********r.de>
Subject: vollkommen fremde Domain
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Antivirus: Avast (VPS 260618-0, 18.6.2026), Outbound message
X-Antivirus-Status: Clean
X-PPP-Message-ID: <178177118070.4055602.4629345598374179241@mx2fe4.netcup.net>
X-NC-CID: jilzgk1n7eJ3QMQjFrilCn3mStEJvxgG416VvRofaCy8LtEIpbvqq7svr44/5hQqE6ULhT8wN8lZ
Envelope-To: <th***.***@web.de>

Und das ist der gesamte Header?

Zitat von rdiez

Sowohl E-Mail-Clients als Spam-Filter sollten eine Abweichung zwischen Envelope- und From-Adresse als spam-verdächtig markieren,

Im Internet gefunden:

Automated processing is a big reason. You want to be able to send any bounces/autoreplies/errors to be processed separately, otherwise those messages disappear, or get ignored, or some poor sap has to dig through them. Yes, adding an X- header for processing is possible, but a lot of the time bounces/etc. won't include the original email or only a mangled portion of it and you won't be able to get the source.

For example, say someone signs up on your website, and you send them an email saying thanks for signing up. Your MAILFROM and From might look like this:

MAIL FROM: <user-signup-123123123@bounces.example.com>
From: Website X <noreply@example.com>

This way, the user sees the "friendly from" in the mail client. But if the user doesn't exist, their MTA will send the bounce message to:

user-signup-123123123@bounces.example.com

and an automated process can easily pull the userid (the 123123123 part) and the part of the system that created the bounce(the -signup- part) from the header and easily delete/mark that user as disabled.

Zitat von rdiez

Wir reden hier über die Fälschung der Domäne (üblich bei Spam).

Genau. Unter anderem. Aber oft ist es eben keine Fälschung sondern sinnvoll.
im Internet gefunden :
Here you can see that the "MAIL FROM" (MAIL FROM:<ben.charles@xyzinc.com>) is part of the SMTP transaction, whereas the "message from"tony.rock@zxinc.com is part of the actual email message.

IMG_5241.jpg

Known cases where "envelope from" and "message from" are different

1. Mailing Lists: When emails are sent through a mailing list, the "envelope from" address often corresponds to the mailing list server , while the "message from" address is that of the original sender.
2. Forwarding Services: When an email is forwarded by a service, the "envelope from" might be the forwarding service, while the "message from" remains the original sender's address
3. Automated Emails: In automated or transactional emails, the "envelope from" is typically a no-reply or system address, while the "message from" might be a user-facing address for replies.
4. Third-Party Email Services: When using third-party services (e.g., CRM systems, marketing platforms) to send emails on behalf of a user, the "envelope from" could be the service's domain, while the "message from" is the user's address.
5. Email Aliases: Users can send emails using aliases, where the "envelope from" is the underlying actual email address, while the "message from" is the alias address.
6. Spoofing and Phishing: In malicious scenarios, attackers may deliberately set different "envelope from" and "message from" addresses to deceive recipients.

Drum prüfe wer sich ewig bindet Trennung Hosting/Server und E-Mail Provider. Hier würde ich spezialisierte Provider nutzen, z.b. etwas mit E-Mail (auf Englisch) in einer box.org