Fehlendes Reverse Mapping (PTR Record)

Die IP Adresse eines jeden Mailservers muß sich rückwärts zu einem Hostnamen auflösen lassen können.

Beispiel:
nslookup 194.231.55.234
234.55.231.194.in-addr.arpa name = relay.vianetworks.de.

Diese IP Adresse löst also erfolgreich zum Namen relay.vianetworks.de auf. Weiterhin löst relay.vianetworks.de widerum selbst zu einer existierenden Adresse (Forward Mapping) auf.

Das Reverse Mapping enspricht hier dem Forward Mapping, was den Idealfall darstellt.

Beispiel:
nslookup relay.vianetworks.de
Address: 194.231.55.234

Der Absender erhält beim Fehlen des Reverse Mappings (oder wenn das Ziel des Reverse Mappings nicht exakt zurück auflöst) die Fehlermeldung:

Your IP address does not resolve to a hostname - no proper reverse mapping exists

Siehe auch: RFC 1912

Disqualifizierendes Reverse Mapping / dynamische Adressen

Der ausliefernde Host besitzt ein Reverse Mapping, welches allerdings nicht plausibel zu einem Emailserver passen kann.

Beispiel:
nslookup 217.255.247.59
59.247.255.217.in-addr.arpa. 86400 IN PTR pD9FFF73B.dip.t-dialin.net.

Das Ergebnis der Abfrage zeigt einen Host aus einem typischen ADSL/ISDN Pool mit üblicherweise dynamischer IP Adresse. Emails von diesem Host werden nicht angenommen, da es sich einerseits um eine dynamische IP Adresse handelt und andererseits kein adäquates Reverse Mapping vorhanden ist. Der Betreiber dieses "Servers" ist dringend angehalten für die IP Adresse des Systems ein sinnvolles und gleichzeitig möglichst zum Forward Mapping passendes Reverse Mapping z.B. bei seinem Provider konfigurieren zu lassen. Die Nutzung eines solchen Hosts zum Versenden von Emails ist aufgrund der Eigenschaften des nicht adäquaten Reverse Mappings und der Angehörigkeit zu einem Einwahl Pool daher zum Scheitern verurteilt.
Alternativ zur Schaffung eines sinnvollen Reverse Mappings ist es zu empfehlen den Relayserver des Providers als Ausgangsserver bzw. Smarthost zu nutzen.

Der Absender erhält folgende Fehlermeldung:

You are a dynamic host - please use your providers mailserver to send emails

Siehe auch: RFC 1912

Beispiel zu einem einwandfreiem Reversemapping

Die IP des Server 1.2.3.4 löst auf zu servername.domainname.tld und servername.domainname.tld löst auf zu 1.2.3.4. Der Kreis ist somit geschlossen.

Also: 1.2.3.4 ----> servername.domainname.tld ----> 1.2.3.4

Ist dieses bei Ihrem System genau in dieser Reihenfolge wirklich ebenso der Fall? RDNS Check

Greylisting

Wir verwenden zur Abwehr von unerwünschten Werbenachrichten neben einer Vielzahl weiterer Mechanismen das Verfahren namens Greylisting. Initial eingehende Emails werden bei dieser Technik kurzzeitig nicht akzeptiert (temporärer Fehler) und nach wenigen Minuten beim zweiten, serverseitigen Zustellversuch umgehend angenommen, sofern keinerlei Probleme identifiziert werden. Dieser zweite Zustellversuch geschieht automatisch und führt nicht zur Kontaktierung des Absenders. Jede weitere Email des gleichen Absenders mit dem gleichen Ziel wird darauf hin für zehn Tage ebenso sofort angenommen. Das Verfahren bietet derzeit einen großen Nutzen zur Bekämpfung von SPAM bei nur sehr geringen, damit initial einhergehenden, Verzögerungen bei der Zustellung. Diese Verzögerung beträgt in der Regel bei standardkonformen und somit einsatztauglichen Servern lediglich 5 bis 20 Minuten.

Der Relayserver erhält folgende temporäre Fehlermeldung:

Greylisting in action, please come back in a few minutes

Siehe auch: RFC 2821

Host in Blackliste

Diverse öffentlich bekannte sowie hausintern gepflegte Blacklisten mit Einträgen SPAM sendender IP Adressen verringern vor allem während Zeiten hohen Emailaufkommens die Anzahl unerwünschter Werbeemails. Dabei sind nicht gerechtfertigte Einträg in Blacklisten äußerst selten. Sollten Sie dennoch einen Fehleintrag vermuten bitten wir Sie den in der Fehlermeldung genannten Anbieter der Blackliste zu kontaktieren oder aber uns zu informieren, sofern es sich um genau diese Mitteilung handelt:

We don't accept mail from your IP

Sollte der Absender einer Email im Falle eines Problems keine der obigen oder anderen herkömmlichen Fehlermeldungen erhalten, so liegt hier ein weiteres Fehlverhalten bzw. ein Defekt des sendenden Servers vor, da das Antivirus/AntiSPAM System immer eine Fehlermeldung an den Absender generiert. Der Administrator des Servers sollte sich daher die Funktion seiner Verarbeitung der Fehlermeldungen genauer ansehen.