• This forum has a zero tolerance policy regarding spam. If you register here to publish advertising, your user account will be deleted without further questions.

Plattform zum Testen des E-Mail Providers bzw. der Mailserverkonfiguration

meinmail

New Member
Hallo Gemeinde!

Ich hoffe, ich bin hier richtig und möchte mit diesem Beitrag zur Verbesserung im Mailverkehr beitragen. Dem einen oder anderen kann es auch beim Einrichten (s)eines Mailservers helfen:

Leider sind korrekt konfigurierte bzw. gut gewartete Mailserver die Seltenheit.
Ist das schlimm? JA - denn würden nur 100% korrekte Systeme miteinander kommunizieren, würde ein großer Teil der ungewollten Mails (SPAM) ausgesperrt bleiben.
Da jedoch leider viele unsaubere Systeme im Netz existieren, müssen alle Mailserver ihre Sicherheit dementsprechend anpassen - somit 'Lücken öffnen' - da man andernfalls sehr viele legale Mails ablehnen würde; und das möchte natürlich niemand.

Der Witz an der Geschichte ist, daß der Enduser normaler weise auch gar keine Möglichkeit hat, seinen Provider zu überprüfen, zumal er ja wahrscheinlich nicht einmal auf die Idee kommen würde, daß da u.U. etwas nicht stimmt.

Wir haben, als Versuch die User darauf aufmerksam zu machen, eine Plattform online gestellt, mit der einzelne Tests zusammengeführt werden und Aufschluß darüber gegeben wird, ob der getestete Server in Ordnung ist oder nicht.

https://test.meinmail.info

LG
meinmail
 
Last edited by a moderator:
Hallo Leute!

Ehrlich gesagt haben wir hier schon mit ein bißchen mehr Feedback gerechnet, als seit der Erstellung eingegangen ist :rolleyes:...

Ist das Thema uninteressant oder ist die Beschreibung vielleicht nicht ganz treffend bzw. unklar?

Naja, wie auch immer - mittlerweile gibt es auch die Möglichkeit einen Schnelltest durchzuführen.

Einfach ein (leeres) Mail an schnelltest@meinmail.info senden - das Mail wird zwar abgelehnt, jedoch im darauf folgenden Postmaster steht das Ergebnis der Bewertung (allerdings nur, ob der Test positiv, neutral oder negativ verlaufen ist).

Für die Detailauswertung muß der detaillierte Test ausgeführt werden.

Siehe: https://test.meinmail.info


Falls etwas unklar sein sollte - bitte fragen! Dafür sind wir da :)

LG
 
Leider sind korrekt konfigurierte bzw. gut gewartete Mailserver die Seltenheit.
Ist das schlimm? JA - denn würden nur 100% korrekte Systeme miteinander
kommunizieren, würde ein großer Teil der ungewollten Mails (SPAM)
ausgesperrt bleiben.
Sorry aber das ist Blödsinn!!!!
98 % des Spams kommen aus Botnetzen.
Botnetze bestehen aus Clienten die durch Trojaner oder Schad Programme
übernommen worden sind!!

Da jedoch leider viele unsaubere Systeme im Netz existieren,
müssen alle Mailserver ihre Sicherheit dementsprechend anpassen -
somit 'Lücken öffnen' - da man andernfalls sehr viele legale Mails
ablehnen würde; und das möchte natürlich niemand.
Das ist auch Blödsinn!!!
Greylisting, DNS Blacklisting und dieverse gut etablierte möglichkeiten für
jeden SMTP Server wehren gut 99% des Spam aufkommens ab!!
Man muss sie nur nutzen!!

Gefährlich sind eher die Leute die einen Mailserver ins Netz stellen und
anschliessend als Relay Missbraucht werden!!

Ausserdem WIE willst du Spam verhindern der so geschickt aufgebaut ist das selbst
Spamfilter, wie Amavis, Spamassassin o.ä., das nicht erkennen??

Kannst du ernsthaft sicherstellen das in deinem Briefkasten nicht unerwünschter
Werbemüll ist, das glaub ich kaum??

Sven
 
Ich hab das mal getestet. Die Idee an sich ist ja nicht ganz so dumm, das Ergebnis aber dennoch falsch.

Code:
FEHLER: Der Mailserver, ueber den Ihre Mails versendet werden, meldet sich NICHT korrekt!
Die Anmeldung des Mailservers stimmt NICHT mit dem Hostnamen der sendenden IP-Adresse ueberein!
Das kann zu groben Problemen bei der Mailzustellung fuehren!
Meldung des Servers: mail.kerneloops.de
Hostname: kerneloops.de
IP-Adresse: 62.75.129.118

Das System ist so durchaus RFC-konform konfiguriert ;)
 
Bei meinem Test kam das gleiche Ergebnis wie bei wstuermer - HELO des Mail-Servers und PTR sind auch bei mir nicht identisch, aber der HELO ist natürlich auf die IP meines Servers auflösbar.
 
Hmm, interessant finde ich, dass die Antwortmails von dem System bei Google Mail im Spam-Ordner landen ;) weil für meinmail.info scheinbar ein SPF-Record mit "hardfail" konfiguriert ist. Das ist u.U. problematisch bei Weiterleitungen. Ich würde ja gern, dass dafür notwendige SRS umsetzen, nur habe ich bisher keine wirklich brauchbare Anleitung oder Beispiel für Postfix gefunden, ohne das ich manuell am Postfix herumpatchen muss (Debian Squeeze im Einsatz).

RFC 1912 sagt nur - für jedes IP-Adresse sollte es einen PTR in der in-addr.arpa-Domäne geben und jeder PTR sollte auf einen gültigen A-Record verweisen. PTR und A-Record müssen natürlich zur selben Maschine führen.
 
Freut mich, daß sich Interessierte gefunden haben :)

Die Plattform ist grundsätzlich für Enduser gedacht, die mit der Tiefe der Thematik nicht vertraut sind und hier dennoch die Möglichkeit haben über die Vorgehensweisen Ihrer Provider informiert zu werden.
Hier scheinen ja alle eigene Mailserver zu betreiben ;) - paßt auch zum Board...
Es gibt viele User, die Probleme mit dem Zustellen ihrer Mails haben und natürlich nicht wissen warum - hier kann man das prüfen UND der User, der von IT keine Ahnung haben muß, schickt das Testergebnis (sofern schlecht) zu seinem Provider und braucht ihn nur zu fragen: Warum ist das so? Bis wann ist das korrigiert? Bitte - Danke.


Diejenigen, die bereits getestet haben, sollten wissen was zu tun ist - kleiner Tipp: Wenn alles korrekt ist, checkt mal Eure LogFiles - Ihr werdet merken, daß viele empfangende Mailserver Eure Mails gleich, also ohne Greylisting, akzeptieren werden (Erstkontakt vorausgesetzt).
Auch nicht schlecht, oder? Übrigens: die Testergebnisse sind so korrekt ;)

Auf eine AW möchte ich hier dennoch eingehen - zu Sven:

Du bist der Meinung, daß das Blödsinn ist - ist's jedoch nicht! Genau das ist nämlich der JumpingPoint!

Was Du geschrieben hast, bezüglich wie oder was man einsetzen kann, um seine Server zu schützen - darum geht es hier gar nicht!
Das Thema setzt an der Wurzel an. Und wenn mit aller Strenge, also nur 100% korrekte Systeme miteinander kommunizieren würden, dann würde das das Spamaufkommen SEHR WOHL drastisch reduzieren, da viele Spammer gar nicht die Möglichkeit hätten, Eingriffe in dieser Tiefe vorzunehmen.
Mit reduzieren meine ich jetzt nicht unbedingt die Mails, die letztendlich dem Empfänger tatsächlich zugestellt werden, sondern schon vorher im Datenverkehr - nicht korrekte Mailserver werden sofort abgewiesen; ohne, daß da noch irgendwas weiter geprüft wird. Das ist das Ziel :)

In einer Sache hast Du natürlich recht: Ganz verhindern kann man SPAM nicht - denn, wenn's von Top-Maschinen verschickt wird und inhaltlich auch gut aufgebaut ist, dann gehen die ersten paar hunderttausend raus (wenn überhaupt), bevor Blacklisten usw. reagieren. Aber dann ist's vorbei und der zuständige Admin hat viel Arbeit...
Und spätestens dann wird sich dieser überlegen, wie er seine Systeme noch besser schützen kann BEVOR Spam rausgeschleudert wird.

Übrigens: Deine Seite ist seit mehreren Tagen off. (nicht der Blog) - check mal ;)


Vielleicht noch aus der eigenen Erfahrung, um die Thematik zu untermauern:

Große Freemailer, wie Hotmail, Google usw. haben grundsätzlich sehr gute Konfigurationen, während manche Provider, dessen Hauptgeschäft die Internetzugänge selbst sind, hingegen oftmals fürchterliche Konf. aufweisen.
Warum ist das so?
Weil für die Freemailer das das Hauptgeschäft ist, bei dem die Sache unbedingt funktionieren muß, während die Anderen das Mailen nur als (lästiges) Nebenprodukt betreiben. Sie verdienen daran ja nichts, müssen aber den Dienst anbieten.
Bei einem der größten Provider Österreichs ist das z.B. ganz schlimm - aber die interessiert das auch gar nicht, weil sie sind ja die Größten...

Gibt es Nachweise für diese Aussage: JA - Eure LogFiles ;)


Wünsche Euch weiterhin viel Erfolg damit,
LG
Martin
 
Wenn man schon solche hochtrabenden Tests anbietet, dann sollte man sich auch an die zuständigen RFCs halten und keine offensichtlichen Falschmeldungen raushauen:
Code:
FEHLER: Der Mailserver, ueber den Ihre Mails versendet werden, meldet sich NICHT korrekt!
Die Anmeldung des Mailservers stimmt NICHT mit dem Hostnamen der sendenden IP-Adresse ueberein!
Das kann zu groben Problemen bei der Mailzustellung fuehren!
Meldung des Servers: mail.rootservice.org
Hostname: devzero.rootservice.org
IP-Adresse: 78.47.20.28
Fixe den Test und schicke mir das korrigierte richtige Testergebnis zu.

Und noch etwas: Bitte konfiguriere Dein Mailsystem korrekt, denn es gibt meine Mailheader als seine eigenen aus und hätte ohne meinen vorausschauenden Eingriff zu einem Mailbombing auf mein Mailkonto geführt. Das ist auch bei Euch in AT strafbar...
 
Wenn alles korrekt ist, checkt mal Eure LogFiles - Ihr werdet merken, daß viele empfangende Mailserver Eure Mails gleich, also ohne Greylisting, akzeptieren werden (Erstkontakt vorausgesetzt).

Ja, und das ist auch der Grund, warum Greylisting derzeit noch so effektiv ist. Würde der überwiegende Teil der Mailserver Greylisting nutzen, hätten die Spammer mit ihren Bots lange nachgerüstet, so daß diese das Greylisting umschiffen (ich habe sogar schon die eine oder andere Spammail bei mir entdeckt, wo das der Fall zu sein scheint (von einem DSL-Anschluß direkt zugestellt und durchs Greylisting gekommen).

Das Thema setzt an der Wurzel an. Und wenn mit aller Strenge, also nur 100% korrekte Systeme miteinander kommunizieren würden, dann würde das das Spamaufkommen SEHR WOHL drastisch reduzieren, da viele Spammer gar nicht die Möglichkeit hätten, Eingriffe in dieser Tiefe vorzunehmen.

Die Spammer versuchen mit möglichst wenig Aufwand möglichst viel Müll zu versenden. Wenn allerdings mehr Aufwand notwendig ist, wird dieser auch rein gesteckt - das Spam-Geschäft dürfte noch ordentlich Spielraum nach oben haben, wenn es trotz Gesetzen so aktiv betrieben wird.
 
SRS - Test verfügbar!

Ab sofort kann der sendende Mailserver geprüft werden, ob SRS im Einsatz ist (beta).

Das wird bei den meisten von Euch sicher nicht der Fall sein, aber wer z.B. ein BlackBerry-Handy benützt und Mails von seiner eigenen Adresse darüber verschickt, wird über die RIM-Server via SRS geleitet.

Aus unserer Erfahrung benützen hauptsächlich sinnlose Newsletter-Mailer oder andere automatischen Massenmailer SRS, damit SPF gekillt wird und deren Mails auch sicher weitergeleitet werden.

Ob das wirklich das gelbe vom Ei ist, sei dahingestellt...

https://test.meinmail.info


LG
Martin
 
Last edited by a moderator:
Wann wird Euer Mailsystem gefixt? Muss ich erst Anzeige erstatten, oder geht es auch ohne?

Falls Ihr nicht wisst, wovon ich schreibe, dann studiert mal fleissig folgende Mailheader Eurer E-Mail an mich und da Ihr ja nach eigener Aussage Ahnung von der Thematik habt, reicht Euch ja ein kurzer Blick, um festzustellen, welche Headerzeilen rechtswidrig von Euch aus meiner E-Mail übernommen wurden:
Code:
Return-Path: <test@meinmail.info>
X-Original-To: joeuser@rootservice.org
Delivered-To: joeuser@rootservice.org
Received: from mail.intellihost.at (mail.intellihost.at [212.108.37.159])
	by mail.rootservice.org (Postfix) with ESMTP id 120BD35E83F
	for <joeuser@rootservice.org>; Sun, 29 Jan 2012 13:48:16 +0100 (CET)
Received: from  [127.0.0.1] by mail.intellihost.at
  (ArGoSoft Mail Server Pro for WinNT/2000/XP, Version 1.8 (1.8.6.8)); Sun, 29 Jan 2012 13:48:10 +0100
X-EW-Sign: F1584843F8BC438DB884CE86571215F2
Subject: Analyse 1/2
From: Test@MeinMail.Info
Message-Id: 78.47.20.28.devzero.rootservice.org.3460.joeuser@rootservice.org.2012-01-29
Received: from [192.168.178.21] (port-14659.pppoe.wtnet.de [84.46.57.124])
	(using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: joeuser@rootservice.org)
	by mail.rootservice.org (Postfix) with ESMTPSA id EFB7B35E834
	for <test@meinmail.info>; Sun, 29 Jan 2012 13:48:01 +0100 (CET)
Disposition-Notification-To: Joe User <joeuser@rootservice.org>
Date: Sun, 29 Jan 2012 13:49:11 +0100
Reply-To: Joe User <joeuser@rootservice.org>
Organization: RootService
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1
MIME-Version: 1.0
To: "Test@MeinMail.Info" <test@meinmail.info>
References: <1521e50ded4c45b3b887e4b76ef82d60@test.meinmail.info> 78.47.20.28.devzero.rootservice.org.4796.joeuser@rootservice.org.2012-01-22 78.47.20.28.devzero.rootservice.org.4804.joeuser@rootservice.org.2012-01-22 78.47.20.28.devzero.rootservice.org.4811.joeuser@rootservice.org.2012-01-22
In-Reply-To: <1521e50ded4c45b3b887e4b76ef82d60@test.meinmail.info> 78.47.20.28.devzero.rootservice.org.4796.joeuser@rootservice.org.2012-01-22 78.47.20.28.devzero.rootservice.org.4804.joeuser@rootservice.org.2012-01-22 78.47.20.28.devzero.rootservice.org.4811.joeuser@rootservice.org.2012-01-22
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-ArGoMail-Authenticated: ewall@intellihost.at
 
@Jue User: Na, na, na - anzeigen wird hier sicher niemand jemanden wegen irgendetwas - wollen wir doch bei der Sache bleiben, gell?
Dennoch danke für den Hinweis - dieser wurde bei den gesendeten Antwortmails (Analysemails) bereits berücksichtigt.
Jetzt bist jedoch Du an der Reihe - da gibt es ja noch einiges zu tun ;)


Zu den Testergebnissen (speziell Servermeldung): Die Tests sind so korrekt!

Die HELO/EHLO Meldung soll/muß zum PTR der sendenden IP passen - jetzt gibt es theoretisch die Möglichkeit von mehreren PTRs zu einer IP, allerdings ist das:

1. völlig sinnlos (zumindest zu dieser Thematik)
2. werten die meisten rDNS-Abfragen nur den ersten eingetragenen PTR aus

Somit: Das Setzen einer korrekten Servermeldung ist relativ einfach und es gibt keine Erklärung, warum bei einem PTR [dasist.meinptr.tld] die Servermeldung [mail.meinptr.tld] lauten sollte.
Zur Info: Viele Mailserver bewerten gerade diese Meldung in der Einstufung des SPAM-Verdachts!

Bestätigungen für diese Aussage:

Schaut Euch z.B. das Testbeispiel von GMail an - warum ist das wohl so?

Zu diesem Thema gibt es 3 gute Freunde:

- Eure LogFiles
- Google
- testet selber über seriöse Mailbetreiber, wie GMail, Hotmail, oder wer Euch sonst noch einfällt

Wer halbwegs Traffic auf seinem Mailserver produziert, kann das sehr, sehr gut nachvollziehen.


Wir wünschen weiterhin viel Erfolg mit https://test.meinmail.info
LG
Martin
 
RFC 2821 definiert den EHLO Hostnamen als:
The domain name given in the EHLO command MUST BE either a primary host name (a domain name that resolves to an A RR) or, if the host has no name, an address literal as described in section 4.1.1.1.

Ich sehe hier nicht direkt einen Verstoss zu Joe's Setup, oder irre ich mich?

PS:
"Die IP-Adresse, ueber die die Mails versendet werden, ist in KEINEN geprueften WhiteListen aufgelistet!"
DAS ist Snake-oil. Die Telekom dachte auch immer "ich bin gross, ich darf das" mit ihrem Spamproblem bis Spamcop die Schnauze voll hatte. Whitelisting ist genauso; ich bin VIP, ich darf das. *hust*
 
Last edited by a moderator:
@Jue User: Na, na, na - anzeigen wird hier sicher niemand jemanden wegen irgendetwas - wollen wir doch bei der Sache bleiben, gell?
Ihr begeht gleich mehrere Straftaten und die Betroffenen sollen ruhig bleiben? Realitätsverlust oder was ist los bei Euch?

Dennoch danke für den Hinweis - dieser wurde bei den gesendeten Antwortmails (Analysemails) bereits berücksichtigt.
Abgesehen vom Aufbau der Message-ID hat sich bei Euch absolut nichts geändert:
Code:
Return-Path: <test@meinmail.info>
X-Original-To: joeuser@rootservice.org
Delivered-To: joeuser@rootservice.org
Received: from mail.intellihost.at (mail.intellihost.at [212.108.37.159])
	by mail.rootservice.org (Postfix) with ESMTP id 1D29835E83F
	for <joeuser@rootservice.org>; Sun,  5 Feb 2012 17:54:54 +0100 (CET)
Received: from  [127.0.0.1] by mail.intellihost.at
  (ArGoSoft Mail Server Pro for WinNT/2000/XP, Version 1.8 (1.8.6.8)); Sun, 5 Feb 2012 17:54:52 +0100
X-EW-Sign: FA5F190E925F13B5BAD5F47F85415573
Subject: Analyse 1/2
From: Test@MeinMail.Info
Message-Id: 12869.4712.561392062.2012-02-05@mail.intellihost.at
Received: from [192.168.178.21] (port-2696.pppoe.wtnet.de [84.46.10.146])
	(using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits))
	(No client certificate requested)
	(Authenticated sender: joeuser@rootservice.org)
	by mail.rootservice.org (Postfix) with ESMTPSA id 5BA2635E834
	for <test@meinmail.info>; Sun,  5 Feb 2012 17:54:35 +0100 (CET)
Disposition-Notification-To: Joe User <joeuser@rootservice.org>
Date: Sun, 05 Feb 2012 17:54:57 +0100
Reply-To: joeuser@rootservice.org
Organization: RootService
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0) Gecko/20120129 Thunderbird/10.0
MIME-Version: 1.0
To: "Test@MeinMail.Info" <test@meinmail.info>
References: <1521e50ded4c45b3b887e4b76ef82d60@test.meinmail.info> 78.47.20.28.devzero.rootservice.org.4796.joeuser@rootservice.org.2012-01-22 78.47.20.28.devzero.rootservice.org.4804.joeuser@rootservice.org.2012-01-22 78.47.20.28.devzero.rootservice.org.4811.joeuser@rootservice.org.2012-01-22 78.47.20.28.devzero.rootservice.org.3462.joeuser@rootservice.org.2012-01-29
In-Reply-To: <1521e50ded4c45b3b887e4b76ef82d60@test.meinmail.info> 78.47.20.28.devzero.rootservice.org.4796.joeuser@rootservice.org.2012-01-22 78.47.20.28.devzero.rootservice.org.4804.joeuser@rootservice.org.2012-01-22 78.47.20.28.devzero.rootservice.org.4811.joeuser@rootservice.org.2012-01-22 78.47.20.28.devzero.rootservice.org.3462.joeuser@rootservice.org.2012-01-29
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-ArGoMail-Authenticated: ewall@intellihost.at

Jetzt bist jedoch Du an der Reihe - da gibt es ja noch einiges zu tun ;)
Für mich gibt es nichts weiter zu tun, als die beiden Anzeigen (einmal AT, einmal DE) einzutüten und abzuschicken.
Vielleichht fangt Ihr ja endlich mal damit an, Euer völlig kaputtes Mailsystem zu fixen, statt hier Euer Angebot zu promoten.

Zu den Testergebnissen (speziell Servermeldung): Die Tests sind so korrekt!
Die Tests mögen korrekt sein, die gegebenen Interpretationen der Testergebnisse zumindest in einem Punkt hingegen nicht.

Die HELO/EHLO Meldung soll/muß zum PTR der sendenden IP passen - jetzt gibt es theoretisch die Möglichkeit von mehreren PTRs zu einer IP, allerdings ist das:

1. völlig sinnlos (zumindest zu dieser Thematik)
2. werten die meisten rDNS-Abfragen nur den ersten eingetragenen PTR aus

Somit: Das Setzen einer korrekten Servermeldung ist relativ einfach und es gibt keine Erklärung, warum bei einem PTR [dasist.meinptr.tld] die Servermeldung [mail.meinptr.tld] lauten sollte.
Zur Info: Viele Mailserver bewerten gerade diese Meldung in der Einstufung des SPAM-Verdachts!
OK, dann erläutere mir mal bitte, was an folgendem standardkonformen Realworld-Setup falsch ist und warum es damit mailtechnisch seit Jahren keinerlei Probleme gibt, obwohl Du ja gegenteiliges behauptest.
Code:
System:
IP-Adresse: 78.47.20.28
Domain: rootservice.org
Host: devzero
PTR: devzero.rootservice.org

Dienste:
Mailserver: mail.rootservice.org
Webserver: www.rootservice.org

Vielleicht solltet Ihr Euch mal Nachhilfe von einem echten Postmaster geben lassen und vor Allem die zuständigen Standards verstehen...
 
Ich find die Projektidee sehr gut! Ob es aber auch tatsächlich so umgesetzt wurde, kann ich leider nicht beurteilen. Interessieren würde mich aber, wo hier eine Strafbarkeit begründet sein könnte?
 
Es werden blind alle Mailheader aus der Mail meiner Testanforderung als Mailheader in das Testergebnis übernommen. Dadurch werden folgende Straftaten begangen (betreffende Mailheader in Klammern):
1. Straftat: Computersabotage (Disposition-Notification)
2. Straftat: Idenditätsdiebstahl (Received, Disposition-Notification, Reply-To, Organization)
3. Straftat: Fälschung (References, In-Reply-To)

Die restllichen übernommenen Mailheader sind derzeit keinem Straftatbestand zuzuordnen. In Ordnung ist es dennoch nicht...
 
Um etwaige Mißverständnisse zu vermeiden, haben wir folgende Anpassungen vorgenommen:

- Header: ein X-Tag mit entsprechender Information wurde eingefügt *)
- HELO/EHLO-Test: eine Nichtübereinstimmung zwischen HELO und PTR wirft nun keinen Fehler mehr aus, sofern das HELO vorhanden, ein A-Record ist und zur IP des sendenden Servers zeigt (siehe Auszug Wikipedia: "Some e-mail mail transfer agents will perform FCrDNS verification on the domain name given on the SMTP HELO and EHLO commands. This can violate RFC 2821 and so e-mail is usually not rejected by default." [http://en.wikipedia.org/wiki/Forward-confirmed_reverse_DNS])

Allerdings bleibt ein 'Hinweis' bei Nichtübereinstimmung und Erfüllung der oben genannten Definition bestehen, da es, auch wenn nicht RFC-konform, Mailserver gibt, die eine Übereinstimmung bewerten.

Mit 'O.K.' wird der Test deshalb auch weiterhin nur bei Übereinstimmung gewertet.

Das ist Fakt und Google wirft dazu genug Ergebnisse aus.

Hier ein Beispiel von GMail (siehe auch Testbeispiel online):
Meldung des Servers: mail-bk0-f52.google.com
Hostname: mail-bk0-f52.google.com
IP-Adresse: 209.85.214.52

Warum, denkt Ihr, machen die (und viele andere) das so? Checkt dazu Eure besten Freunde: LogFiles!

An dieser Stelle möchte ich gerne ein Zitat von Claus von Wolfhausen (UCEPROTECT-Network) aus den cart00neys anführen (wobei das an eine bestimmte Person gerichtet war):

-----
Leute wie Sie müssen lernen, daß es ein Privileg und nicht etwa ein einklagbarer Rechtsanspruch ist, daß andere Leute Mail von Ihnen annehmen.
Damit Sie in den Genuss dieses Privilegs kommen, müssen Sie die auf dem Empfängersystem gültigen Regeln beachten, genauso wie jemand der Ihnen Mail senden will, die Regeln auf Ihrem System beachten muß.
-----

Das ist nämlich in gewisser Weise auch der Grundgedanke unserer Plattform.
Einfach einen Mailserver online zu stellen sollte nicht genug sein, sondern der zuständige Admin soll/muß sich AKTIV bemühen und darum kümmern, um seinen Server als 'maximal gut darzustellen'!

Und dazu gehört ein absolut astreiner Mailserver und natürlich die Helferlein wie Blacklists, Whitelists, Backscattering, SPF, usw.

Denn dann hätte das angpeilte, sicherlich visionäre, Ziel eine Chance auch Realität zu werden.


Wir möchten hier niemanden belehren oder schlecht machen, sonder lediglich Usern helfen, um auf etwaige Mißstände hinzuweisen (es gibt eine Menge grauslich konfigurierte Mailserver im Netz) und eine Idee umsetzen, die letztendlich allen dienen kann.

Wenn sich genug User bei ihren Providern melden und nachfragen, warum sie z.B. ein negatives Testergebnis haben oder ein bestimmter Punkt nicht erfüllt ist, dann wird dieser einmal beginnen müssen nachzudenken und hoffentlich entsprechend einlenken.


*) Nachsatz zu Joe User: Wenn Dich das mit den Headern wirklich so stört, dann lasse es bitte nicht hier aus; das zerstört nämlich den gesamten Thread, da das mit dem eigentlichen Thema nichts zu tun hat.
Trete entweder direkt mit uns in Kontakt oder öffne einen neuen Thread.
Aus unserer Sicht gibt es hier kein Problem, zumal, BEVOR die 2 Nachrichten versendet werden, der User via Double Opt-in seine Adresse aktivieren muß und erst NACH Senden an die Testadresse zwei Bounces erhält.
Das System versendet somit nichts in derartiger Form ohne eindeutiger Aufforderung des letztendlichen Adressaten, dem die Herkunft dadurch eindeutig bekannt ist.
Danke für Dein Verständnis.


Viel Erfolg & LG
Martin
 
Sorry, aber ein Opt-In berechtigt Euch definitiv nicht dazu, gegen RFCs zu verstossen und Straftaten zu begehen.

Und Nein, ich werde zu dem Thema weder einen neuen Thread aufmachen, noch Euch Off-Forum kontaktieren und erst recht nicht Eure Fehler hier totschweigen.
Ihr habt hier mit der Werbung für Euren (vorsätzlich fehlerhaften) Dienst angefangen, auf die korrekte Konfiguration von Mailservern hinzuweisen. Also werdet Ihr jetzt auch die bittere Pille schlucken müssen, dass Ihr zunächst Euren eigenen Mailserver korrekt konfigurieren müsst, bevor Ihr andere dazu auffordert.

Behebt einfach die Fehler in Eurem Setup (dauert keine fünf Minuten) und schon bin ich wieder ruhig...
 
Hallo!

Seit einigen Monaten zusätzlich verfügbar: ausführlicher GREYLISTING-TEST

Grund: Man glaubt es kaum, aber es gibt tatsächlich noch Mailsysteme, die Greylisting als Sender! nicht unterstützen.

D.h., ist beim Empfänger Greylisting aktiv, senden die fehlerhaft konfigurierten Mailserver nicht erneut oder nur 1 Mal (oder zu wenige Male), während die Grylisting-Zeitsperre beim Empfänger noch nicht aufgehoben ist.
Weiters gibt es den häufigen Fehler, daß der Mailserver die Zustellungsversuche von unterschiedlichen IP-Adressen vornimmt. Das führt im schlimmsten Fall ebenfalls zu einer negativen Zustellung, zumindest jedoch zu einer unnötigen zusätzlichen Verzögerung und Mehrbelastung der Ressourcen seitens des Senders.


Mit diesem Test sieht der Sender das, was ihm normaler Weise verborgen bleibt - über welche IPs und Intervalle versucht sein Mailserver die Mails zuzustellen.

https://test.meinmail.info/index.php/greylisting-test.html


Viel Erfolg & LG ;)
Martin
 
Back
Top