was kann man damit anfangen

[Rolf]

Hallo,

im Grunde geht es um das leidige Thema, eine Mail-Adresse zu checken,
ohne dass eine Mail beantwortet bzw. ein Link angeclickt werden muss.
Des Kunden Wille ist sein Himmelreich und so bastele ich so vor mich hin.
Dabei bin ich auf diese Daten gestossen.
Über die URL kiann ein weiterer frei wählbarer Host eingegeben werden.
Frage:
Wenn zu einem Host kein MX-Record existiert, kann es dann trotzdem eine
gültige Mailadresse geben? Der umgekehrte Fall ist ja immer möglich, wenn
man keine Mail-Adresse zu einer Domain anmeldet.

Also, was bringt der ganze Hick-Hack nun wirklich?

m.b.G. Rolf

[Mega]

Frage:
Wenn zu einem Host kein MX-Record existiert, kann es dann trotzdem eine
gültige Mailadresse geben?

Natürlich kann es. Mails können ja auch Systemintern versendet werden oder zwischen zwei Hosts, die z.B. zwei Intranets verbinden.
Mailserver können aber so eingestellt werden (und sollten es auch sein), dass sie Mails nur annehmen, wenn für den Absendeserver ein MX-Record existiert inkl. eines Reverserecords.

Das machen m.W.n. auch Freemailer wie Web.de oder GMX so.

[bleicher]

Grüße,
was machst du mit den neuen adressen? die gibts alle paar wochen - sollte der dienst etwas länger laufen...

das kommt natürlich zu den fällen von "sonstigen" anbietern und den adressen der [e-mail] art.
MFG
bleicher

[Sven Rautenberg]

Moin!

Frage:
Wenn zu einem Host kein MX-Record existiert, kann es dann trotzdem eine
gültige Mailadresse geben?

Ja. Wenn kein MX zu der Domain existiert, ist ein vorhandener A-Record zu nutzen.

Sprich: Wenn für "maildomain.example" kein MX existiert, kann aber ein A mit eingetragener IP existieren. Dann ist die Mail eben an diese IP zuzustellen.

Erst wenn das scheitert, weil entweder unter der IP des A-Records oder unter allen IPs der aufgelösten MX-Records kein Mailserver antwortet, oder der Mailserver mit einer finalen Unzustellbarkeit antwortet, kann man davon ausgehen, dass der prüfende Host wohl keine Möglichkeit hat, an die angegebene Mailadresse zu senden.

Das heißt allerdings immer noch nicht, dass die Adresse nicht existiert, denn man kann ja als testender Versuchssender auch auf Blacklisten eingetragen sein, die der empfangende Mailserver auswertet.

Ganz besonders wichtig: Mailserver implementieren mit zunehmender Häufigkeit Greylisting, d.h. der erste Mailserverkontakt mit Sendeversuch wird mit einer temporären Fehlermeldung abgelehnt. Das bedeutet nicht, dass die Mailadresse nicht existiert, sondern dass man es später noch einmal versuchen soll.

Also, was bringt der ganze Hick-Hack nun wirklich?

Ich halte es, je nach Anwendungsfall (zu dem du bisher wenig konkrete Aussage gemacht hast), für unsinnig bis überflüssig, eine aufwendige, aber unzuverlässige Mailvalidation zu implementieren, wenn man stattdessen eine vollständige, unaufwendigere, aber auf der positiven Reaktion des Mailempfängers basierende Validierung bauen kann.

- Sven Rautenberg

[Rolf]

Hallo Sven,

Ich halte es, je nach Anwendungsfall (zu dem du bisher wenig konkrete
Aussage gemacht hast), für unsinnig bis überflüssig, eine aufwendige,
aber unzuverlässige Mailvalidation zu implementieren, wenn man stattdessen
eine vollständige, unaufwendigere, aber auf der positiven Reaktion des
Mailempfängers basierende Validierung bauen kann.

Du hast völlig Recht - ABER:
der Kunde hat es rundweg abgelehnt!

Natürlich könnte ich jetzt sagen, mach Deinen Mist alleine - ABER:
das hat mein Tankwart rundweg abgelehnt ... :-(

Zweck des ganzen Hick-Hack ist es, dass mein Kunde später seinen Kunden
eMails senden kann. Im Grunde ist das alles Unfug. Die Leute, die auf
diese Seite kommen, suchen keine Schnäppchen. Und es ist IMHO nicht
anzunehmen, dass die Mail-Validierung eine Kundenflucht auslöst,
aber: s. o.

m.b.G. Rolf

[Rolf]

Hallo Sven,

gerade ist mir noch etwas eingefallen!
Es laufen ja fast täglich Meldungen durch Presse, Funk und Fersehen, dass
irgendwo Kundendaten in falsche Hände gefallen sind. Vielleicht wird deshalb
jede Art von Userverwaltung auf dem Webserver abgelehnt ... wer weiss ?

m.b.G. Rolf

[Daniel Thoma]

Hallo Rolf,

Zum Thema E-Mail-Validierung ohne Bestätigungsmail:
http://www.coveryourasp.com/ValidateEmail.asp
Interessant ist vor allem noch die SMTP-Variante, die scheint relativ zuverlässig zu sein.

Das Problem beim Verzicht auf eine Bestätigungsmail ist aber noch ein ganz anderes: Mit allen anderen Verfahren überprüfst Du nur, ob es die Adresse geben kann bzw. mit dem SMTP-Verfahren auch noch, ob es sie wirklich gibt.
Das heißt aber nicht, dass sie demjenigen, der sie angibt, auch gehört.
Wenn Du da jetzt irgendwelche Werbung o.ä. hinschickst und Du hast das eben nicht überprüft, ist das Spam und kann juristisch ärger geben.

Du hast völlig Recht - ABER:
der Kunde hat es rundweg abgelehnt!

Evtl. schreckt ihn die Gefahr von Abmahnungen durch Empfänger oder Konkurrenten ab?

So ein Validierungsverfahren ohne Bestätigungsmail kann eigentlich immer nur zustäzlich verwendet werden. Dann ist der Vorteil, dass man sofort eine Rückmeldung bekommt und den Benutzer darauf hinweisen kann. Damit kann man vermeiden, dass die Anmeldung wegen eines Tippfehlers o.ä. fehlschlägt (so lang es die falsche Adresse nicht ebenfalls gibt).

Grüße

Daniel

[ChrisB]

Hi,

Zum Thema E-Mail-Validierung ohne Bestätigungsmail:
http://www.coveryourasp.com/ValidateEmail.asp
Interessant ist vor allem noch die SMTP-Variante, die scheint relativ zuverlässig zu sein.

Glaub' ich nicht.

"This method uses the SMTP protocol to contact the domain mailserver and actually ask if the user is valid!
A few small caveats - some mailservers don't effectively support this feature"

Wenn Mailserver *nicht* so eingestellt waeren, dass sie das nicht unterstuetzen - dann koennte ja *jeder* Spammer pruefen, ob es die Zieladresse gibt. Deshalb wird das heutzutage in der Praxis m.W. so gut wie gar nicht mehr unterstuetzt.

Der Test mit meiner eigene E-Mailadresse bestaetigt mir das - "failed".

MfG ChrisB

[Daniel Thoma]

Hallo ChrisB,

Der Test mit meiner eigene E-Mailadresse bestaetigt mir das - "failed".

Hm, ich habe das gerade mal mit t-online, web.de und gmx.de probiert und es scheint zu funktionieren. So ganz unverbreitet scheint es also nicht zu sein.
Zudem kann man prüfen, ob ein SMTP-Server das einfach nicht unterstützt oder ob es den Benutzer tatsächlich nicht gibt.
Der Benutzer "postmaster" muss überall existieren, man könnte also einfach im Fehlerfall noch prüfen, ob es für diesen klappt.
Ich denke, da sollte dann nicht mehr viel durchfallen.

Grüße

Daniel

[Sven Rautenberg]

Moin!

Hm, ich habe das gerade mal mit t-online, web.de und gmx.de probiert und es scheint zu funktionieren. So ganz unverbreitet scheint es also nicht zu sein.

Bei SELFHTML funktioniert es nicht. Dürfte am Greylisting liegen. Dabei schafft dieser Mechanismus einem ziemlich viel Spam vom Hals, ich würde ihn also als wichtig einstufen.

Zudem kann man prüfen, ob ein SMTP-Server das einfach nicht unterstützt oder ob es den Benutzer tatsächlich nicht gibt.

Die Antwort des Mailservers auf den angefangenen, dann abgebrochenen Versuch des Mailversands kann man nicht beeinflussen.

Der Benutzer "postmaster" muss überall existieren, man könnte also einfach im Fehlerfall noch prüfen, ob es für diesen klappt.

Dieses Standardeinfallstor für Spam wird von genervten Admins vermutlich als allererstes gekappt.

Außerdem: Der Account muss vielleicht existieren, aber nirgendwo ist vorgeschrieben, dass er nicht auch gegen Spam geschützt sein darf.

Ich denke, da sollte dann nicht mehr viel durchfallen.

Ausreichend viel, würde ich meinen.

Es hängt immer davon ab, was man mit dem Ergebnis anfangen möchte. Aber die allermeisten Verwendungszwecke im kommerziellen Bereich verbieten sich, wenn der Inhaber des fraglichen Mailpostfachs nicht tatsächlich aktiv per Link seine Zustimmung gibt.

"verbietet sich" == "potentiell abmahnfähig" == "kosten unnötig Geld"

- Sven Rautenberg

[Daniel Thoma]

Hallo Sven,

Die Antwort des Mailservers auf den angefangenen, dann abgebrochenen Versuch des Mailversands kann man nicht beeinflussen.

Wieso sollte man versuchen, eine Mail zu versenden, wenn es doch das Kommando VRFY gibt? Ein Mailserver sollte darauf entweder korrekt antworten oder irgend einen Fehlercode schicken. Was man im Fehlerfall dann macht, sei dahingestellt.
Bei einem Standardkonformen Mailserver sollte das also funktionieren.
Vermutlich wertet das Script einfach Statuscodes falsch aus.

Es mag natürlich zu viele Mailserver geben, die den Standard verletzen. Ich will diese Technik auch nicht generell empfehlen, aber vielleicht kann sie hier und da doch von Nutzen sein.

Außerdem: Der Account muss vielleicht existieren, aber nirgendwo ist vorgeschrieben, dass er nicht auch gegen Spam geschützt sein darf.

Klar, aber wenn sogar dieser es nicht ist, dann sollten es die anderen auch nicht sein. War aber anscheinen eine schlechte Idee, bei selfhtml.org klappt es für Postmaster aber ansonsten nicht.

"verbietet sich" == "potentiell abmahnfähig" == "kosten unnötig Geld"

Ja, das sagte ich ja bereits.

Grüße

Daniel

[Christian Seiler]

Hallo Daniel,

Die Antwort des Mailservers auf den angefangenen, dann abgebrochenen Versuch des Mailversands kann man nicht beeinflussen.
Wieso sollte man versuchen, eine Mail zu versenden, wenn es doch das Kommando VRFY gibt?

In fast jedem Tutorial zur Mailserverkonfiguration wird empfohlen, VRFY wg. Spam zu deaktiveren. Ich würde mal behaupten, dass VRFY deutlich unzuverlässiger als "probieren und abbrechen" ist.

Wie Sven schon sagte: Die einzige wirklich sinnvolle und auch rechtlich einwandfreie E-Mail-Verifikationsmethode ist es, eine Bestätigungsmail mit kryptografischem Token zu verschicken.

Viele Grüße,
Christian

[Sven Rautenberg (outa house)]

Moin!

Die Antwort des Mailservers auf den angefangenen, dann abgebrochenen Versuch des Mailversands kann man nicht beeinflussen.
Wieso sollte man versuchen, eine Mail zu versenden, wenn es doch das Kommando VRFY gibt? Ein Mailserver sollte darauf entweder korrekt antworten oder irgend einen Fehlercode schicken. Was man im Fehlerfall dann macht, sei dahingestellt.
Bei einem Standardkonformen Mailserver sollte das also funktionieren.

Das VRFY-Kommando ist, wie man dem Textumfeld deines Links entnehmen kann, in der ursprünglichen Fassung optional gewesen. Und darüber hinaus kann ich mir nicht vorstellen, dass es Mailadmins gibt, die dieses Kommando auf ihren Mailservern aktiviert haben. Der RFC ist ja zu entnehmen, dass VRFY nur "SHOULD be supported" sein soll, und "MAY be disabled".

Vermutlich wertet das Script einfach Statuscodes falsch aus.

Auf dem SELF-Mailserver ist VRFY aus guten Gründen deaktiviert. Wir kriegen auch so schon genug Spam, da muss nicht noch ein Mechanismus in Gang gesetzt werden, der die Gültigkeit von Adressen verifizierbar macht. Ansonsten könnte man sich wunderbar alle möglichen local-parts generieren und mit VRFY prüfen, welche Buchstabenkombinationen davon gültige Adressen sind.

Diese Listen ließen sich dann für einiges Geld verkaufen: Gültige Mailadressen sind bei Spammern sehr beliebt.

Es mag natürlich zu viele Mailserver geben, die den Standard verletzen. Ich will diese Technik auch nicht generell empfehlen, aber vielleicht kann sie hier und da doch von Nutzen sein.

Wie die RFC eindeutig einräumt: Es gibt keine Pflicht, VRFY zu unterstützen, nur die Möglichkeit.

- Sven Rautenberg

[Daniel Thoma]

Hallo Sven,

Es ist mir völlig klar, dass das Verfahren nicht immer funktioniert.
Ich sage ja nur, es lässt sich unterscheiden, ob ein Benutzer nicht existiert oder ob das Verfahren mit dem entsprechenden SMTP-Server nicht funktioniert.

Bei VRFY geht das auf jeden Fall, beim Sendeversuch einer Mail sollte man auch unterscheiden können, ob das am Grey-Listing scheitert oder nicht. Bei Grey-Listing sollte ja ein temporärer Fehler signalisiert werden, prüft der Server hingegen wirklich, ob die Adresse existiert, sollte ein endgültiger Fehler signalisiert werden.
Mit diesem Wissen kann ich nun z.B. eine Webanwendung bauen, die dem Benutzer sofort Rückmeldung über eine falsch eingegebene Adresse gibt. Damit das sinnvoll ist, muss natürlich der Anteil der Server, bei denen es klappt, einigermaßen hoch sein. Es stört aber nicht, wenn es bei 20% der Adressen oder so nicht funktioniert.

Auf dem SELF-Mailserver ist VRFY aus guten Gründen deaktiviert.

Ich hab das jetzt mal mit telnet bei diversen Mailanbietern ausprobiert, VRFY scheint tatsächlich überall nicht verfügbar zu sein. Also wird wohl wirklich ein Sendeversuch durchgeführt. Interessant finde ich aber, dass das bei den selben Anbietern dann funktioniert.

Ich habe das gerade mal mit GMX und SELFHTML getestet:
GMX ungültige Adrese:
  RCPT TO:[e-mail]
  550 5.1.1 [e-mail]... User is unknown {mx107}
GMX gültige Adresse:
  RCPT TO:[e-mail]
  250 2.1.5 ok {mx041}

SELFHTML gültig/ungültig:
RCPT TO:[e-mail]
450 4.2.0 [e-mail]: Recipient address rejected: Greylisted, see http://postgrey.schweikert.ch/help/selfhtml.org.html

Man kann die Fälle also problemlos unterscheiden. Bei Grey-Listing könnte man es ja sogar später nochmal versuchen. Allerdings fällt dann der Nutzen für eine sofortige Rückmeldung an den Nutzer weg. Das wäre also nur interessant, wenn man wirklich Mailadressen ohne Nutzerrückmeldung bestätigen will. Da fällt mir spontan auch kein Anwendungszweck ein, außer Spamen natürlich.

Wie die RFC eindeutig einräumt: Es gibt keine Pflicht, VRFY zu unterstützen, nur die Möglichkeit.

Ja, wie gesagt kein Problem. Allerdings ist VRFY wirklich nicht ausreichend verbreitet um irgend wie interessant zu sein.
Es wundert mich auch wirklich etwas, warum einerseits VRFY überall ausgeschaltet ist, bei den großen Anbietern aber offensichtlich nirgendwo Grey-Listing verwendet wird, im Prinzip ist das dann ja sinnlos.

SELFHTML scheint generell etwas strenger konfiguriert zu sein, als üblich. Sonst hat sich niemand dafür interessiert, was ich eigentlich bei HELO als Clientname mitschicke. ;-)

Grüße

Daniel

[Sven Rautenberg]

Moin!

SELFHTML scheint generell etwas strenger konfiguriert zu sein, als üblich. Sonst hat sich niemand dafür interessiert, was ich eigentlich bei HELO als Clientname mitschicke. ;-)

HELO-Filterung ist ein ziemlich effektives Mittel, um Spam abzuhalten. Schließlich gibts dafür einerseits klare Formerfordernisse im RFC, andererseits kann eigentlich kein System auf der Welt außer unseren eigenen Servern behaupten, Grüße von "selfhtml.org" zu übermitteln.

Alle vier oder fünf Hersteller von verbreiteter Mailserversoftware haben diese RFC intensiv gelesen und umgesetzt - die diversen Hersteller von Spamsoftware zum Glück nicht so sehr.

- Sven Rautenberg

[Sven Rautenberg]

Moin!

Ich halte es, je nach Anwendungsfall (zu dem du bisher wenig konkrete
Aussage gemacht hast), für unsinnig bis überflüssig, eine aufwendige,
aber unzuverlässige Mailvalidation zu implementieren, wenn man stattdessen
eine vollständige, unaufwendigere, aber auf der positiven Reaktion des
Mailempfängers basierende Validierung bauen kann.
Du hast völlig Recht - ABER:
der Kunde hat es rundweg abgelehnt!

Du hast bis jetzt noch nicht einmal gesagt, um was exakt es geht.

Erwartest du noch weitergehende Hilfestellung? Sehe mich mit den wenigen Infos außerstande, irgendwas zu formulieren, geschweige den was hilfreiches.

- Sven Rautenberg

[Paul]

Hallo Rolf,

die einzig wahre Validierung ist natürlich eine entsprechende Bestätigungreaktion eines Mailempfägers.

Dennoch nutze ich nach wie vor einfache Plausibilitätsprüfung der Email.
Und das macht auch Sinn, denn bei hohem Besucheraufkommen fällt schon mal einiges an Joke-Einträgen weg, weil überraschend viele doch sowas wie:
[e-mail]
[e-mail]
dukannstmichmal
[e-mail]

sich also nicht mal die Mühe machen eine realitätsnahe Email anzugeben.

Das sollte auch deinem Kunden reichen(meinen reicht sowas) oder noch besser wenn der Kunde Null Ahnung hat, mach es in JS, so das die fehlerhafte Email bereits bei der Eingabe angemeckert wird. Ich mache es extra nicht so, damit der JokeUser nicht solange weiter probiert bis es passt, aber einem Besserwisser-Kunde beeindruckt solch eine Spielerei doch allzu leicht.

Gruss
Paul