es gibt »spezialexperten« die testen mittlerweile nur auf TLS 1.3.
evtl. liegt es daran.
es liegt am Hostname Mismatch (Netcups MX werden standardmäßig mit Prio 50 gesetzt, dh zuerst wird mail.domain.tld probiert und nachdem hier das Wildcard *.netcup.net zurückliefert, ist die Konfiguration nicht richtig)
Ist jetzt aber nichts Neues (und dem Support bekannt)
Hallo,
weiß jemand warum Mails von kleinanzeigen.de nie ankommen auf den Netcup-Mails?
Extrem, extrem ärgerlich!
Einen Spam-Ordner habe ich gar nicht.
MfG
Wenn Dir nur Posteingang angezeigt wird, würde ich bei den Einstellungen anfangen
Alles anzeigenHallo,
Samfilter ist kompeltt eaktiviert.
Habe nur Posteingang und Papierkor als Ordner.
Adresseingabe ist 100 % korrekt bei Linkedin.
DNS alles auf Standard.
Spam-Filter KOMPLETT deaktiviert heißt auch rspamd bei der Domäne?
Hallo Leute vielen vielen Dank für eure Hilfe.
Ich hab jetzt 'nen tolles Workaround gemacht = heißt Thunderbird für netcup Mails
Ich weiß das ist immer so lala aber es läuft.
Rechtzeitig bevors neue Outlook kommt 
Über Systemsteuerung/Mail kannst Outlook schon auch manuell konfigurieren aber Ja: ich hab auch gewechselt
Stelliungnahme des Supports:
Ohne Worte
rspamd-worker-8404 - kommt der jemandem bekannt vor?
Danke für den Hinweis (anhand rspamd-worker-8404 Beitrag gefunden) und es nach einigen Anläufen über den 1st Level-Support geschafft (2nd/3rd ist direkt leider nicht erreichbar) eMails wurden auf einmal mit *** SPAM *** markiert (siehe hier) und nun stellt sich raus, dass bei externen Domänen die Deaktivierung nicht selbst durchgeführt werden kann:
Bezüglich externer Domains: Bei Bedarf können wir es für diese manuell auf Anfrage deaktivieren, da es über das CCP ja nicht möglich ist.
Mach damit - also mit der nicht passenden Spamkennzeichnung - bitte einen neuen Beitrag auf. Ich würde mich beteiligen und ebenfalls beisteuern, habe mir die Kennzeichnung aber noch nicht genauer angesehen, weil ich mich bisher nicht auf netcup E-Mail-Adresse verlassen wollte.
Ticket is offen (hab auch nochmals die mit EICAR infizierte eMail geschickt und nachgehakt)
Betreffend Spam habe ich gerade existierenden Beitrag gefunden: scheinbar wissens selbst nicht, was einsetzen (die in Plesk getroffenen Einstellungen beziehen sich auf SpamAssassin, nicht rspamd) 
Alles anzeigenDie Kopfzeilen sagen, dass hier gar kein Virenscan seitens netcup gelaufen ist und nur der SpamAssassin 3.4.2 drübergeschaut hat.
Soweit ich mich noch erinnern kann, bestünde auch die Möglichkeit, dem SpamAssassin die Virenprüfung z.B. via ClamAV zu geben, aber das scheint hier nicht der Fallzu sein.
Der einzige Eintrag in den Kopfzeilen dazu kommt anscheinend noch von extern: (ich habe die gesamten Kopfzeilen dem Support mitgegeben)
X-Virus-Scanned: Debian amavisd-new at !change-mydomain-variable!.example.com
Ich habe hier den Screenshot vom MS Edge Browser, dessen Smartscreen Technik auch gleich den Download der EICAR-Testdatei verhindert:
Webmail01_netcup_kein_Virenscan_EICAR-Testdatei.png
Nachdem der Virenschutz nicht zuverlässig ist, schein nunt auch Spamerkennung zu spinnen: heute wurden mehrere eMails mit *** SPAM *** im Betreff ergänzt (im Plesk ist übrigens ***SPAM*** also ohne Leerzeichen eingestellt) und laut Header wurden diese nicht als verdächtig eingestuft (spannenderweise taucht X-Spam: Yes in einem nicht markierten eMail auf). Relevanter Teil wie folgt, fällt euch was ein?
X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on mx2e45.netcup.net
X-Spam-Level:
X-Spam-Status: No, score=0.9 required=7.0 tests=HTML_IMAGE_RATIO_08,
HTML_MESSAGE,MIME_HTML_MOSTLY,RDNS_NONE,SPF_HELO_NONE,SPF_NONE,
T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.2
X-Spamd-Result: default: False [13.05 / 15.00];
BAYES_SPAM(5.10)[100.00%];
HFILTER_HOSTNAME_UNKNOWN(2.50)[];
PHISHING(2.00)[domain.tld->domain.tld];
LONG_SUBJ(1.97)[262];
AUTH_NA(1.00)[];
R_PARTS_DIFFER(0.59)[79.3%];
MIME_GOOD(-0.10)[multipart/related,multipart/alternative,text/plain];
R_DKIM_NA(0.00)[];
FROM_EQ_ENVFROM(0.00)[];
R_SPF_NA(0.00)[no SPF record];
MIME_TRACE(0.00)[0:+,1:+,2:+,3:~,4:~,5:~,6:~,7:~,8:~,9:~,10:~,11:~];
RCVD_COUNT_TWO(0.00)[2];
ASN(0.00)[asn:xxx, ipnet:xxx.xxx.xxx.xxx/19, country:DE];
TO_MATCH_ENVRCPT_ALL(0.00)[];
RCVD_VIA_SMTP_AUTH(0.00)[];
DMARC_NA(0.00)[domain.tld];
ARC_NA(0.00)[];
TO_DN_NONE(0.00)[];
FROM_HAS_DN(0.00)[];
HAS_ATTACHMENT(0.00)[];
HAS_X_PRIO_ONE(0.00)[1];
RCPT_COUNT_ONE(0.00)[1];
RCVD_TLS_ALL(0.00)[]
Alles anzeigenDanke für die Rückmeldung - kann bestätigen, dass es wieder klappt
netcup_WCP_Kontaktformular_Support_OK.png
Lasse aber auch hier noch den Verweis aufs Helpcenter da, den charmin.armin oben ja schon gegeben hat und der in der E-Mail zur Bestätigung des Empfangs jetzt enthalten ist.
Kennen Sie schon unser neues Kontaktformular? Gerne können Sie Ihre Anfrage zukünftig darüber versenden, damit wir Ihnen noch schneller und effizienter weiterhelfen können: https://deref-gmx.net/mail/client/PF…%2Fde%2Fsupport
Anscheinend werden die Tickets, welche übers Helpcenter eingereicht werden, von einer anderen Abteilung bearbeitet 
Hab vor 5 Tagen Header einer (virenverseuchten) eMail übermittelt und wollte meine Ursprungsanfrage sehen (wird leider -aus Datenschutzgründen?- nicht der Bestätigungsmail angefügt)
Ich habe Ihre Anfrage soeben an unsere Kollegen der entsprechenden Abteilung zur weiteren Prüfung weitergeleitet.
Wir bitten Sie daher um Geduld. Wir werden uns schnellstmöglich bei Ihnen zurückmelden.
Natürlich wurde das Thema (zusammen mit dem noch immer vorhandenen DNSSEC-Problem) auch per eMail eskaliert:
Wie bereits erwähnt, wird am Virenschutz gearbeitet, ich kann aktuell aber noch keine genaue zeitliche Prognose für eine Behebung treffen.
Hallo Michael,
Push-Mail ist bedauerlicherweise bei den Webhosting Paketen von Netcup nicht enthalten. Das wäre nur realisierbar, sofern du dir ein Konto bei Google anlegst und dann bei Netcup DNS-Verwaltung für Domains auf Google änderst.
Ein kürzeres Abrufintervall ist meines Wissens nicht möglich. Dieses kann nur über einen JailBreak realisiert werden und das ist natürlich Geschmackssache.
Gruß
Sheldor
Sorry fürs Aufwärmen aber ist P-IMAP (Push) noch immer nicht verfügbar?
Also mein Thunderbird hat keinerlei Problem ein Konto meiner E-Mail Adresse bei netcup per autoconfig einzurichten.
Edit: Du hast nicht zufällig den CNAME-Eintrag für autoconfig.deinedomain.tld irgendwie überbügelt?
Codeautoconfig.meinedomain.tld. 3600 IN CNAME autoconfig.netcup.net. autoconfig.netcup.net. 7200 IN A 46.38.225.195
Danke fürs Testen aber DNS-Einstellungen wurden auf Standard zurückgesetzt
netcups autoconfig ist so schon korrekt.
man kann hier ja nicht TLS angeben, weil autoconfig-»SSL« SSLv3 bzw TLSv1.1 aufwärts beinhaltet
und smp 465 hat, da erster eintrag, oberste priorität.
Richtig, was ausgehend betrifft - eingehend ist aber (derzeit) 143 mit StartTLS an 1. Stelle und Thunderbird dürfte auch in diesem Beispiel nicht an die Autoconfig rankommen (und probiert daher typische Serverbezeichnungen, eventuell hier weiterlesen - ich stelle das Troubleshooting über 1st Level-Support ein;)
K-9 Mail wurde übrigens fündig (beschwert sich nur ein wenig;)
Für mich bedeutet dennoch die Aussage, dass der Virenschutz global für jeden aktiviert sei etwas anderes. Sonst würden keine Viren(test)mails in neuen Mailaccounts durchkommen. Mich stört einfach die, in meinen Augen, falsche Aussage, die einen Schutz suggeriert, der nicht da ist.
Aber ich gehe auch davon aus, dass das Problem nun nach Bekanntwerden auch zeitnah behoben wird und dann ist wieder alles im Lot.
Netcup versucht das Problem zeitnah zu beheben, von mir habens (letzte Woche) einen Mailheader übermittelt bekommen. Mich stört auch, dass ich trotz Urgenz mit einer falschen Aussage abgewimmelt wurde. EDIT: soeben folgende Antwort auf meinen via Support-Formular eingereichten Mailheader (indem auch die bestehende Fallnummer erwähnt wurde) erhalten 
get your sh*** done
Problem mit Autoconfig scheinbar gelöst!
Seit heute Mittag wird das Autoconfig "richtig" aufgelöst.
"http://autoconfig.domain.tld/mail/config-v1.1.xml" liefert "mx1234.netcup.net" und nicht mehr "mail.domain.tld".
Aber "webmail.domain.tld" funktioniert weiterhin nicht. Es muss noch mit "webmail01.netcup.net" gearbeitet werden.
Sollte in Netcups Autoconfig nicht auch Port 465 also implizites TLS (Danke an MacLemon für die detaillierte Auflistung) als bevorzugte Methode (statt 587 mit StartTLS also optionale Verschlüsselung) bzw. 993 statt 143 (IMAP) angeführt sein? Schon klar, dass die Implementierung von Zertifikaten für jeweilige mail.domain.tld auf mx1234.netcup.net eine Herausforderung darstellt (ja, auch ich habe vor Jahren EXIM so konfiguriert, dass auch bei selbst signierten Zertifikaten nicht gemeckert wird;) und ähnlich stellt es sich übrigens mit webmail.domain.tld dar (hierfür müsste der Webserver webmail01.netcup.net auch auf die jeweiligen Kundendomänen entsprechend antworten und das wäre eine aufwendige Administration. Copro hat es hier ganz schön zusammengefasst (ich begnüge mich mit einer Umleitung/PageRule;)
https://helpcenter.netcup.com/de/support hat bei mir funktioniert
Copro hab den Chef in CC: gesetzt (rechne nicht vor nächster Woche mit einer Antwort)
Okay, es funzt bei mir auch nur bei alten Mailkonten erwartungsgemäß.
Lege ich einen neuen Account an, habe ich genau dasselbe Problem wie du.
Die Checkboxen sind nach einem Refresh alle wieder aus und die Mail trudelt im Posteingang ein!
Hier sollte wirklich schnell eine Lösung gefunden werden. Die Aussage, dass der Virenscan per default immer an ist, scheint jedenfalls nicht zu stimmen. Dann wäre nicht zuerst die Virenmail geblockt und beim neuen Account durchgelassen worden.
Was bin ich froh das nicht beim alten Account testweise abgeschaltet zu haben...
Auch mx2e45.netcup.net lässt trotz inaktiver Virensuche EICAR durch - hab den Support gebeten, doch bitte eingehenden Virenschutz zu aktivieren und folgende Antwort erhalten 
Der Virenschutz ist dauerhaft aktiv und kann nicht deaktiviert werden. Die Option kann aktuell nicht ausgeblendet werden, hat jedoch keine Auswirkung auf die Funktion.
Hallo,
hier besteht aktuell das gleiche Problem mit der Meldung. (Ich habe dazu auch schon ein Supportticket erstellt.)
Der Threadersteller schreibt von einem "MXG Portal" ?
Das sagt mir nichts. Ist das ein kostenloses Test-tool ?Ich weiß nicht wie ich testen kann, ob die Mail-Funktionen trotz oben stehender Meldung dennoch mithilfe des Zertifikates verschlüsselt sind.
Vielen Dank
Das MXG Portal ist ein absichtlicher Buchstabendreher da Marktbegleiter hier nicht gerne genannt werden (dürfen)
Die Problematik mit MX Prio 10 mail.domain.tld ist ebenfalls bekannt und "Domain schützen" in Plesk irreführend 
Das fände ich (und viele andere Webhosting-Kunden) auch schön, allerdings ist es unsicher, denn...
...es ist leider nicht möglich, die Subdomain webmail.example.com zu zertifizieren.
Was hat es mit dieser Einstellung auf sich? Hier würde ein Wildcard ja hervorragend reinpassen, für mail.domain.tld übrigens auch
Finde es ziemlich unsicher, auf diese Art (zB im fremden WLAN) die Zugangsdaten unverschlüsselt zu übertragen!
Das frage ich mich auch gerade. Vor allem weil einer sogar schon den Link vom Webformular fürs Austragen gesendet hat.
Vor allem ist Announcements ja moderiert und Archiv gibts auch keins 
Danke für den Link KB19 (da outen sich die wahren Experten) Netcup scheint auch bei der Signatur (Copyright) nicht auf dem letzten Stand zu sein
ignoriert bei folgendem Artikel mal das was der gemacht hat ...
Scherz von Teenager führte zu Kampfjet-Einsatz (futurezone.at)
SSL everywhere ist nett;
und bringt es was, kann jedes Stück Software damit korrekt umgehen?
Futurezone scheint wohl eher History-Repeatin' Archive-Artikel weil auf einer Website das Datum leicht gefälscht werden kann,
LE freundlich war SnapChat schon immer und "Bomb" kommt am Flughafen nie gut (auch wenns in einem Bild war) Diskussion hier
Hat jemand erforscht, inwiefern
SMTP Smuggling
(https://sec-consult.com/blog/detail/sm…ails-worldwide/) der aktuelle Grund, Postfix zu patchen und Cisco secure gateway korrekt zu konfigurieren, für Exim nicht zutrifft? Etwa weil exim sich an die RFCs hält?
Wie kommst drauf, dass Exim nicht betroffen sein sollte? Postfix über SEC Consult (großartiger Talk übrigens am 37C3):
Days before a 10+ day holiday break and associated production change freeze, SEC Consult has published an email spoofing attack that involves a composition of email services with specific differences in the way they handle line endings other than <CR><LF>.
Unfortunately, criticial information provided by the researcher was not passed on to Postfix maintainers before publication of the attack, otherwise we would certainly have convinced SEC Consult to postpone publication until after people had a chance to update their Postfix or other affected systems.
The net result: a presumably unintended zero-day attack was published because some people weren't aware of the scope of the attack.
Technically, the attack explots END-OF-DATA confusion by sending <LF>.<LF> or <LF>.<CR><LF> instead of <CR><LF>.<CR><LF>. The vulnerability was introduced many decades ago in Sendmail, by allowing the non-standard <LF> line ending in addition to the standard <CR><LF>. For compatibility with programs that expect Sendmail behavior, the non-standard <LF> line ending was also allowed by other SMTP servers including Postfix and Exim.
