Beiträge von charmin.armin

    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 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) ||

    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)[]

    Anscheinend werden die Tickets, welche übers Helpcenter eingereicht werden, von einer anderen Abteilung bearbeitet X/ 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)


    Zitat

    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:



    Zitat

    Wie bereits erwähnt, wird am Virenschutz gearbeitet, ich kann aktuell aber noch keine genaue zeitliche Prognose für eine Behebung treffen.

    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?

    Code
    autoconfig.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;)


    temp.jpg


    K-9 Mail wurde übrigens fündig (beschwert sich nur ein wenig;)


    temp.jpg

    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 :cursing: get your sh*** done


    temp.jpg

    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;)

    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 ?(


    Zitat

    Der Virenschutz ist dauerhaft aktiv und kann nicht deaktiviert werden. Die Option kann aktuell nicht ausgeblendet werden, hat jedoch keine Auswirkung auf die Funktion.



    temp.jpg


    temp.jpg

    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 X(

    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 ;)


    temp.jpg

    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 :P 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

    temp.jpg

    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/d…oofing-e-mails-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.