Beiträge von hede

Danke für die Tipps; da steht aber nicht mehr drin, als ich schon hatte.

Ich habe mir eine (bisher) relativ lag-freie Lösung mit proxy_ndp gebastelt. Via proxy_ndp muss man zwar jede IP einzeln eintragen und keine Subnetze, aber das lässt sich ja skripten. Das wird mir wohl so reichen. Und wenn ich mal über ein günstiges Subnetz stolpern sollte, kann ich ja noch immer zuschlagen.

PS: Der verlinkte Beitrag, der mir helfen soll, endet übrigens mit "Es will einfach nicht funktionieren, ich leg das Ganze erstmal auf Eis..."

Naja, ich habe schon 18446744073709551616 IPv6-Adressen, ich benötige keine weiteren.

Gibt es die Möglichkeit, sich sein Prefix generell auf den vServer routen zu lassen? (also eine feste Route, VServer als Gateway für das Prefix)

Hintergrund:

- LXC innerhalb des VServers, mit KVM ja kein Problem.

- bridge interface mit Subnetz für die Container

- eth des VServers nicht in Bridge: Muss ja, denn ich habe nur eine IPv4 und muss daher für IPv4 in die Container Masqueraden/NATen. (Via iptables in KVM auch kein Problem)

- Netzmaske des eth des VServers daher deutlich größer 64 -> netmask:128

- IPv4 funktioniert hierdurch

Problem bei IPv6:

- der VServer reagiert auf Router-Advertisements nur für seine eigene IP (Netmask=128), nicht für die IPs der Container

- die Netzmaske muss so ja sein, denn die Bridge braucht ihr eigens Subnetz, sonst können da ja vom VServer keine Pakete hin geroutet werden

- Folge: die IPs der Container sind dem Router bei Netcup nicht bekannt: somit keine IPv6-erreichbarkeit der Container

Hat jemand eine sinnvolle Idee?

Ich habe zwei mögliche Lösungen, die mich beide irgendwie noch nicht befriedigen:

- ndppd im Userspace

- proxy_ndp via Kernel

Probleme hierbei:

Beides hat bisher nur leidlich funktioniert. Ich nutze den VServer nur rein privat (bzw. teste aktuell sogar nur) und er hat damit kaum Traffic. Auf die regelmäßigen RA des Routers reagiert der VServer offensichtlich dabei nur mit seiner eigenen IP, nicht dem Subnetz der Bridge. Damit verfallen diese nach einer Zeit aus dem Router Cache. Neue Verbindungen gehen somit erst einmal schief. Das bedeutet, verbinde ich mich nach einer Zeit per SSH zu einem Container oder ruft jemand meine Seite auf, nachdem länger niemand drauf war, gibt es erst einmal keine Verbindung. Erst der zweite Versuch ein paar Sekunden später funktioniert. Das ist irgendwie nicht sonderlich befriedigend. Kann das noch wer beobachten oder hab ich mich vielleicht verkonfiguriert?

proxy_ndp bedeutet darüber hinaus noch, jede einzelne IP, die man nutzt, manuell einzutragen (via ip -6 neigh add proxy...).

Auch irgendwie nicht schön.

Ich werde weiter suchen...

PS: Die Problematik wird dort von kasperd sehr schön beschrieben:

https://serverfault.com/questi…ed-prefix-and-link-prefix

Huhu,

netcup: Ihr nutzt im spam-check die SINGLE_HEADER_3K Regel, die anschlägt, sobald ein Header mehr als rund 3K Zeichen enthält (in meinem Fall auf we870.netcup.net).

Man könnte den Autocrypt Header da raus nehmen. Der ist in üblichen, legitimen Mails u.a. von Thunderbird gesetzt und regelmäßig über 3K groß. Und das ganz regulär.

Zur Erklärung des Autocrypt-Headers: Hiermit übertragen Autocrypt-Compatible Mailclienten einen OpenPGP-Schlüssel des Anwenders, um dem Gegenüber die automatische Verschlüsselung der Antwort zu ermöglichen. Schlüsselgrößen bei rsa heute zwischen 2K und 4K, daher die Größe. Das erhöht zwar die Sicherheit nicht so sehr wie ein manueller Schlüsselaustausch mit Kontrolle der Chain of Trust, aber dafür ist es absolut einfach für Jedermann anwendbar und besser eine verschlüsselte Mail mit einmaliger Chance zum MitM statt generell unverschlüsselte Mails (mit nicht nur MitM und das dauerhaft). Stichwort TOFU: Trust On First Use.

Grüße

der hede

Hallo,

mein Postfach auf we870.netcup.net unterstützt ja prinzipiell imap idle. Nun hab ich das bisher nicht genutzt, lade meine Mails per pop3, aber imap idle bietet ja prinzipiell den Vorteil, dass einkommende Mails sofort da sind und man nicht so oft pollen muss. Da hab ich mir gedacht: prima, das teste ich mal.

Klappt auch prinzipiell, aber es dauert dennoch ca. eine Minute bis neue Mails via imap idle gemeldet werden. Das find ich für so ein push-mail-Verfahren schon irgendwo ungewöhnlich lang. Bei internen Mails auf meinem eigenen Server geht das schneller. Da dauert es ca. 1-2 Sekunden bis eine versandte Mail dem Email-Clienten als neue Mail gemeldet wird.

Ich nutz bei mir cyrus, kann courier das vielleicht gar nicht schneller? Oder liegen es an sonstigen bei netcup liegenden Umständen?

Beobachten andere das ebenfalls?

Ich mein, so tragisch ist das ja jetzt nicht. Bisher tuts für mich ja auch polling via pop3, ich glaub alle 10 oder 15 Minuten, da wäre eine Reaktionszeit von einer Minute ja noch ein deutlicher Fortschritt. Ich bin nur neugierig.

Grüße
hede

PS: Habe per openssl s_client (quasi telnet) getestet, so dass ich die nackten Daten bekomme und natürlich nur die Zeit gewertet, von der an die eingetroffene Mail auch wirklich im Posteingang vorhanden ist. Und da IMAP_ENHANCEDIDLE ja nicht gesetzt sein muss, auch das Ganze noch einmal ohne einen zweiten Clienten (der prüft obs im Posteingang ist); es hatte sich eh herausgestellt, dass die Mail ziemlich sofort ankommt so dass man davon ausgehen kann. Bis der courier-imapd auf we870 das per idle meldet, dauert es immer noch eine Zeit (ca. 1 Min.). Kein gamin/fam am Server? Absichtlich so konfiguriert?

Die IP-Adresse aktuell halten könnte auch der Rechner, stimmt, aber nicht so gut wie der Router. Denn dieser hält ja den dhcp-lease für die öffentliche IP und kann beim Wechsel der öffentlichen IP quasi ohne Zeitverzögerung (push) dem dyndns-Provider Bescheid geben. Der Rechner muss die öffentliche IP regelmäßig kontrollieren (poll) und fügt dennoch auch selbst bei sehr häufigen Kontrollen immer eine gewisse zusätzliche Verzögerung zum eh schon etwas trägen DNS-Update-Prozess hinzu.

Nungut, damit kann man natürlich durchaus leben, selbst wenn man die IP nur alle Stunde mal kontrolliert, wenn der IP-Wechsel nachts erfolgt und man dann alle Nutzer schlafen und ich hab eh bei meinem Provider hier eine quasi-statische IP (ändert sich quasi nur wenn ich das Kabelmodem wirklich mal hard resette und selbst dann nicht einmal unbedingt).

Gibts bei netcup wohl wirklich nicht. Nun ja, muss ja auch nicht. Bei einer nicht herabsetzbaren TTL von 24h auch nicht sinnvoll, selbst wenns ein Interface zur automatischen Aktualisierung geben würde.

TTL von 15 Min. wäre mir ok, auf die typischen 1 Min. der Dyn-Provider würde ich nicht einmal bestehen. Da würd ich auch bei dem Anbieter bleiben...

Ist no-ip.com denn noch kostenlos nutzbar? Ich mein da gäbs auch keine Einsteigerangebote mehr?

Egal, ich werd wohl eh afraid.org nehmen. Machen einen guten Eindruck, wenn mich auch die Preisstaffelung nicht überzeugt. Mehrere Subdomains für umsonst, aber kleinstes kostenpflichtiges Angebot gleich 5€ im Monat.

Hm, ach, Mist. Ich seh grad, in dem alten Router hier ist nur dyndns.org möglich, was mittlerweile ja dyn.com bedeutet... hm... lol...
Und für das Modell gibts leider kein OpenWRT o.ä. (Original is VxWorks mit 2MB Flash, Linux-Support schwierig, hatte ich schonmal nach geguckt)

Na, da muss ich mir wohl mal was einfallen lassen.

Ich verwalte meine Domain hier im CCP. Und bisher habe ich manch Subdomain via CNAME auf eine DynDNS-Domain umgebogen, da der entsprechende Service hier bei mir zuhause rumsteht und sich die IP häufig ändert.

Mein bisheriger DynDNS-Prover (dyn.com) hat mich nu aber irgendwie einmal zu viel geärgert und ich bin dabei Alternativen auszuloten. Der hab ich mit freedns.afraid.org auch eine wohl passende gefunden. Kann man für bezahlen, wenn man will, oder auch spenden oder einfach eine kostenlose Subdomain nehmen. Und sie nehmen einem nicht gleich alle bisher genutzten Subdomain weg, wenn man sich mal 30 Tage nicht in deren Webinterface angemeldet hat!

Hat hier schon jemand damit Erfahrungen gemacht? Sind die brauchbar?

Apropos, frag ich gleich noch die wohl beste Lösung nach:

Netcup bietet ja Domains an und betreibt Nameserver. Gibts hier auch die Möglichkeit, DNS-Einträger per dyndns-Client upzudaten? (Alternativ zum dyndns-clienten das heute wohl durchaus übliche Update per Web-URL.) Natürlich wenn dann nur mit der für diesen Zweck nötigen TTL von deutlich unter der dafür unbrauchbaren Zeit von 86400 Sekunden (24 Stunden).

Dann bräuchte ich für den Service gar keinen anderen Anbieter.

Hallo,

ist "unbemerkbar" ein Schreibfehler oder wirklich so gemeint? Also unabhängig von irgendwelchen Vertrauensketten prüfe ich das Zertifikat per known-fingerprint. Wenn also das neue Zertifikat einen anderen Fingerprint hat, was nach allerallerhöchster Wahrscheinlichkeit der Fall sein sollte (ansonsten wäre ssl/tls in sich kaputt), dann krieg ich das mit.
Und das ist auch gut so, sonst könnte ja irgendwer daherkommen, sich als Netcup-Server ausgeben und meine Mails abfangen.

Aber nungut, in Anbetracht dessen, dass die Server untereinander meist eh unverschlüsselt kommunizieren oder irgendwelchen Zertifikatsketten trauen, spielt das eh keine große Rolle.

Grüße
Michael

Hallo,

gibt es eine Möglichkeit, sich im Vorfeld über stattfindende Zertifikatänderungen informieren zu lassen?

Seit heute hat sich - jedenfalls aus meiner Sicht, ich hoffe das ist auch regulär so - das SSL-Zertifikat auf we870.netcup.net geändert:
subject= /serialNumber=Cx6lc1ZzUuAkDI-a4cGkhQtskzSjRNU3/C=DE/ST=/L=Karlsruhe/O=netcup GmbH/CN=*.netcup.net
notBefore=Nov 26 05:59:07 2013 GMT
notAfter=Oct 21 23:37:01 2015 GMT
MD5 Fingerprint=B8:56:BA:5C:13:34:74:1F:7B:53:DD:05:4C:4D:E5:37
SHA1 Fingerprint=B0:5B:03:11:B9:2D:9A:9F:C5:3C:75:B1:4C:A0:EB:90:CA:7E:1B:F7

Ich weiß, dass das eigentlich nicht interessiert, weil sich kaum einer um Man-In-The-Middle-Angriffe kümmert. Aber ich prüfe das Serverzertifikat halt und Postfix hat natürlich prompt das Versenden eingestellt:
Nov 29 10:16:12 servername postfix/smtp[24277]: 28A31741D1: to=<mail@example.com>, relay=we870.netcup.net[46.38.232.112]:25, delay=2345, delays=234
4/0.29/0.45/0, dsn=4.7.5, status=deferred (Server certificate not verified)

In meinem Fall kein Beinbruch, hab selber keine zahlenden Kunden sondern nur Bekannte und Familie da drauf. Ist schnell geändert und gut is. Aber wie machen das denn andere, die z.B. zahlende Kunden haben? Einfach jedes Zertifikat akzeptieren?

Grüße
Michael

Generell für alle stimmt es natürlich nicht. Natürlich gibt es noch viele andere, die spamcop verwenden und keine passende whitelist aktiviert haben. Keine Ahnung, vielleicht gar die Mehrzahl. Hatte das nur kurz gegengetestet und bei anderen überwiegend problemfrei empfangen.

Ich will auch niemandem stark auf die Füße treten, falls das so rüber kam. Ich persönlich kann das Thema notfalls aussitzen, bis es sich erledigt hat. Natürlich habe ich Kontakte, die betroffen sind und sich bisher bei mir beschwert haben, die realen Umstände erklärt und bewusst gmx und nicht meinem eigenen Provider die Schuld zugeschoben.

Mir ist natürlich auch sehr wohl bewusst, wie schwierig das Thema für Provider wie Netcup ist. Und ich sehe selbst das konsequente Blockieren als durchaus nützlich an. Die Nachricht bei Golem gefällt mir, dass hier auch "hohe Tiere" betroffen sind. Da wird United Internet zur Handlung gezwungen und sich vielleicht besser überlegen, wie man sich vor "schlechten" Kunden schützen kann. (Die Telekom ist angeblich ja auch anschließend an ihr spamcop-Dilemma das Thema angegangen und filter nun auch ausgehende Mails. So jedenfalls lautet eine im Internet auffindbare Nachricht an die eigenen Kunden.)

Btw., die smtp-Ausgangs-IPs von GMX lassen sich glaube recht einfach über deren Loadbalancing-Domain finden:
<<
$ dig mout.gmx.net
mout.gmx.net. 63704 IN A 212.227.17.20
mout.gmx.net. 63704 IN A 74.208.4.201
mout.gmx.net. 63704 IN A 212.227.15.18
mout.gmx.net. 63704 IN A 212.227.17.22
mout.gmx.net. 63704 IN A 212.227.17.21
mout.gmx.net. 63704 IN A 212.227.15.15
mout.gmx.net. 63704 IN A 74.208.4.200
mout.gmx.net. 63704 IN A 212.227.15.19
>>
Einige der IPs scheinen schon auf der whitelist zu sein. Ob alle notwendig sind und ob es wirklich das ist, was ich meine (mout = mailout), weiß ich nicht.

Ich wünsche viel Erfolg und dass sich das bezüglich GMX in Kürze "von alleine behoben hat" (GMX also mit spamcop in Verhandlung steht).

Interessant wäre eine DNSWL (also eine whitelist ala dns-blacklist), in der alle bekannten und verifiziert gültigen Mailausgänge von Mailprovidern geführt werden. Hm, ne, wahrscheinlich auch schlecht, weil sich diese dann nicht mehr um ihre Sicherheit sorgen würden.

Da müssen wir wohl einfach mit leben, dass es ab und an knallt und alle nochmal aufgeweckt werden. Dumm nur, dass dies ein weiterer Grund ist, der für so Dinge wie De-Mail spricht, denen das systemimmanente Problem des Spam nicht so sehr innewohnt wie dem aktuell üblichen smtp-System.

Klar sollten sich möglichst viele bei GMX beschweren. Die Schuld liegt schließlich höchst wahrscheinlich bei GMX-Kunden, z.B. mit verseuchtem Rechner.

Aber dies über die Erreichbarkeit der eigenen Kunden zu erpressen ist für einen wesentlich kleineren Dienst vielleicht nicht gerade das Optimum für die Zufriedenheit der eigenen Kunden. Denn auf die fällt es zurück, wenn die Fehlermeldung dem GMX-Nutzer sagt, dass der Empfänger die eigene, gültige Email bewusst ablehnt, weil er sie für Spam hält. Das alleine sagt dem Absender schon, dass klar die Ursache beim Empfänger liegt, denn es ist ja gar kein Spam. Auch wenn die wahre Ursache eher irgendwo bei GMX liegen sollte, das rafft kein _normaler_ Mensch.

Zumal können diese GMX-Kunden weiterhin anderen Providern Emails schicken, weil diese Provider natürlich nicht bewusst "aus Prinzip" jede Menge gültige Emails ablehnen. (Man bedenke: false positives in der Spam-Filterung sind _weit_ ärgerlicher als durchkommender SPAM!)

Eine Blacklist zu benutzen, die keine Scheu davor hat, große nicht-amerikanische Anbieter aufzunehmen (und eben nicht gesondert zu behandeln, die Telekom traf es ja auch schon) während weit größere Spamschleudern wie MSN oder Yahoo genau diese Sonderbehandlung erfahren und dann auch noch darauf zu beruhen, _nicht_ generell eine eigene whitelist mit bekannten deutschen Mailprovidern zu führen, ist schon... nun ja... kann sich jeder selber denken. Um es mal sehr milde auszudrücken: Widersprüchlich!

Was sollte da ferner liegen, als den Quell des Übels im ablehnenden Empfänger zu sehen... ich mein ja nur.

Dass man auch als großer Provider mal schnell auf solch einer Blacklist landen kann und es auch für einen großen deutschen Provider nicht mal eben so einfach ist, das erstens zu verhindern und zweitens im Fall der Fälle schnell runter zu kommen, sollte jedem klar sein, der sich damit ein wenig auskennt. Dass es da im Interesse aller sein könnte, die Auswirkungen möglichst gering zu halten, sehen wohl nicht alle ein. Manche werden das wohl erst glauben, wenn es ihnen selber mal passiert ist.

Und bezüglich "Too many delisting requests were made.": Um so mehr sich beschweren, desto länger wird blockiert? Über den Status sollte man sich vielleicht auch mal den ein oder anderen Gedanken machen, wie sinnvoll solch ein Verhalten ist.

Nichts zu danken!

Der Status von einigen mout.gmx.net-Adressen ist mittlerweile:
<<<
Additional potential problems
(these factors do not directly result in spamcop listing)

Too many delisting requests were made. Next request might be allowed after 3.9 days
>>>
Wobei 3,9 Tage nicht einmal die größte Zahl ist.

GMX wird also noch einige Tage auf der Spamcop-bl bleiben. Sich mit dem Problem an GMX zu wenden dürfte damit ein recht unwahrscheinlich von Erfolg gekrönt werden.

Könnte jemand den smtp von we870.netcup.net um besagte Einträge in einer Whitelist ergänzen? Es scheinen schon einige IPs von mout.gmx.net in der Whitelist zu stehen, denn eine Mail von GMX, ausgeliefert via 212.227.15.15, kam grad durch, obwohl diese IP ebenfalls auf der Blacklist steht. Kurz zuvor allerdings eine von 212.227.17.21 nicht, mindestens diese IP stand somit heute um 9:46 Uhr noch nicht auf der Whitelist.

Ebenso kam vorgestern schon eine von 212.227.15.15 durch, andere wiederum nicht (z.B. von 212.227.17.22).

GMX nutzt mehr als eine IP zum Versand. Falls die Whitelist seit heute 9:46 Uhr (mein letzter Test mit False Positive) um die fehlenden Einträge ergänzt wurde, dann ist meine Nachricht hier gegenstandslos.

Grüße
Michael Heide

Derzeit wird es noch nicht ausführlich im CCP beschrieben. Wer ähnlich wie ich fragend vor den Spalten Host und Destination steht und sich fragt, wie er da einen SRV-Record unter bringen soll, hier die (derzeitige) Lösung: (Bezeichnungen nach "SRV record" in der engl. Wikipedia)

"_service._proto" in das Host-Feld
und
"priority weight port target" in das Destination-Feld.

Wenn ich das richtig sehe, funzt es schon ganz gut. Meine Einträge von gerade eben sind zwar noch nicht bis zu meinem Haus-DNS propagiert, aber root-dns.netcup.net antwortet schon sehr vielversprechend.

vmk: Laut deinem Test steht er ja eben doch auf einigen Listen. Naja, zwei von 234 ist nicht viel, würde aber eine Ablehnung von denen erklären, die besagte zwei Listen nutzen.

Nunugut, gehen wir mal nicht davon aus, dass es das ist.

Es wäre schön, wenn ich passende Spamassassin-Daten hätte. Aber leider sind die einzigen, über die ich an solche Daten kommen könnte (also SA-Nutzer sind) nicht betroffen. Und die, die betroffenen sind, kann bzw. möchte ich nicht nach solchen Daten fragen, da belasse ich es jetzt einfach mal beim Status Quo.

Danke an alle, die sich beteiligt haben.

Aber scheinbar liegt es bei mir, wenn andere mit besagtem Postausgangsserver von netcup keine Probleme haben. Kolab bastelt da vielleicht ein wenig viele Received-Zeilen in den Header, auch wenn das ja eigentlich kein Grund sein kann. Als ob Spammer durch viele Received-Header auffallen würden... ansonsten fällt mir da nichts auf.

Grüße
hede

PS: Habs, nachdem nach diversen "kein spam"-Markierungen sich gmx die letzten Tage nicht mehr beschwer hat, jetzt doch nochmal geschafft:
(hatte zuvor die getaggten Testmails gelöscht und dabei übersehen, dass man sich den Spamstatus im Webinterface übersetzen lassen kann)

################################################
Return-Path: <[zensiert]@der-he.de>
Delivered-To: GMX delivery to [zensiert]@quantentunnel.de
Received: (qmail invoked by alias); 01 Oct 2012 09:42:04 -0000
Received: from we870.netcup.net (EHLO we870.netcup.net) [46.38.232.112]
by mx0.gmx.net (mx058) with SMTP; 01 Oct 2012 11:42:04 +0200
Received: from [zensiert].der-he.de (ip-[zensiert].unitymediagroup.de [[zensiert]])
(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
(No client certificate requested)
by we870.netcup.net (Postfix) with ESMTPSA id A15B5BD217A6
for <[zensiert]@quantentunnel.de>; Mon, 1 Oct 2012 11:42:04 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1])
by [zensiert].der-he.de (Postfix) with ESMTP id 91F35D9D9
for <[zensiert]@quantentunnel.de>; Mon, 1 Oct 2012 11:44:51 +0200 (CEST)
Received: from [zensiert].der-he.de ([127.0.0.1])
by localhost ([zensiert].der-he.de [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id FVWzrOwgZIEG for <[zensiert]@quantentunnel.de>;
Mon, 1 Oct 2012 11:44:51 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1])
by [zensiert].der-he.de (Postfix) with ESMTP id E2DF7D9CA
for <[zensiert]@quantentunnel.de>; Mon, 1 Oct 2012 11:44:50 +0200 (CEST)
Received: from [zensiert] (unknown [192.168.[zensiert]])
by [zensiert].der-he.de (Postfix) with ESMTPSA id 989DBD9C1
for <[zensiert]@quantentunnel.de>; Mon, 1 Oct 2012 11:44:49 +0200 (CEST)
Date: Mon, 1 Oct 2012 11:42:00 +0200
From: hede <[zensiert]@der-he.de>
To: [zensiert]@quantentunnel.de
Subject: *** GMX Spamverdacht *** Treffen
Message-ID: <20121001114200.631831ab@[zensiert]>
Organization: der-he.de
X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.10; x86_64-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-GMX-Antivirus: 0 (no virus found)
X-GMX-Antispam: 6 ((SPAM: 1));
Detail=5D7Q89H36p5cypUi/P63nJr6vphVwkgPDDSvgaytq6rfGjji84OCNjfdcJCcnqMqaHxQJ
uvubuQNdUoHL0iMMQI33X2E0k7Is0lWfvw62fxmJLIIFOD0rmYid36xWDejnqPAJRK/Xwg/EhaNb
KD05ZcrtsCfwgb0BKactzuXPOlhl7Cv3mqrZcBu2FLoczi2k771yQMzT/uQqhxs0V5f3PMTqOkJ4
LikYAOk1e/aENY=V1;

Treffen morgen 11 Uhr.
################################################

Der Spam-Wert übersetzt sich laut Webinterface zu:
"GMX Spamschutz Textmuster-Profiler: Der Inhalt dieser E-Mail entspricht Ihrem Spam-Profil. "

Ein Spam-Wert von 6 durch den Satz "Treffen morgen 11 Uhr."?
Nungut, ich würde jetzt mal sagen, das liegt weder an mir noch an netcup, sondern an GMX. Erklärt aber nicht, weshalb ganz andere Mails an ganz andere Empfänger ebenfalls als Spam erkannt werden.

(PPS: Ja, hab am Ende etwas unnötig zensiert, aber ist ja auch egal, was interessieren hier meine lokalen Rechnernamen oder die IP meines Heimanschlusses mit dynamischer IP...)

Abgelehnt würde ich nicht sagen, denn zu mir kommt nichts zurück. Der entfernte Mailserver nimmt sie an. Das wiederum macht mir die Analyse etwas schwer, denn an die entsprechenden Daten komme ich schlecht ran.

Daher ja auch die Frage an andere hier, ob wer anderes hier ähnliches bei genutzten relayhosts von netcup beobachtet, das Verhalten also normal ist, oder ob es generell eher weniger Probleme damit gibt.

Die Analyse wird noch dadurch erschwert, dass besagte Provider die Informationen, wie sie auf das Ergebnis "Spam" kommen, nicht an die Kunden weitergeben. Oder kann hier wer was mit Cisco X-IronPort-Anti-Spam-Result-Zeilen oder welchen von GMX anfangen? Die von Cisco sollen wohl verschlüsselt sein, nix zu machen, die von GMX auch? Ich denke schon... (also base64 decodiert ohne Beschwerde, aber dann isses halt noch immer verschlüsselt)

X-GMX-Antispam: 6 ((SPAM: 1));
Detail=5D7Q89H36p5cypUi/P63nGItt22unyzdbdefZBXZSm9luYMXPbsXyCCtKkc4fL0EcI9Sn
W7TyL0Xg230bs365ExzebBSqKyYB6z9qFY3k6SZClSsl0P/F4Yhks/s0vx0HJcgu+SiCyBA6yRuK
+yP33zKDO4ovBpkkR90J05T9LptGT8nTRDUxQ4PN3S1xuEIJh/dfIVIBe30rTc0qbbVhlvZbDdAE
P6PVFfhY5MhL50wD9F57jQvxw==V1;

Leider hab ich noch keinen mit Spamassasin gefunden, der false positives hat. Oder dessen Nutzer sind einfach technisch begabter.
Tja, der proprietäre M*st mal wieder...

Ich muss bei Zeiten mal sehen, ob mir mein DSL-Provider den Versand einer fremden Domain zulässt. Vielleicht gehts damit ja besser.

Hallo,

ich verwende we870.netcup.net als Postausgangsserver. Also als smarthost, relayhost, oder wie man immer das auch nennt.
Die Emails meiner Domain werden also von we870.netcup.net versendet.

Leider werden diese bei vielen Empfängern als Spam markiert.

Ist das normal?

Mach ich was falsch oder sind die Postausgangsserver von netcup üblicherweise halt einfach auf diversen Spamlisten?

Ich versende Mails natürlich nicht direkt von meinem privaten Anschluss, da dieser eine dynamische IP hat. Das dürfte bei vielen Posteingängen direkt die Alarmglocken klingeln lassen. Genau dafür ist aber doch eigentlich ein Relay beim Provider da!? Ziemlich sinnlos, wenn dieses ebenfalls Mails versendet, die als Spam erkannt werden.

Grüße
der hede