E-Mail Zustellung an Gmail

[lotex24.systems]

Hallo Forum,

ich habe bewusst den Smalltalk gewählt, da es im weitesten Sinne nichts mit den Produkten von JTL zu tun hat, zum anderen möchte ich das Thema auch nicht zum auskotzen verstanden wissen, eher als Thema zur Hilfe.

Seit ca. 3 Wochen erhalten unsere Kunden, welche ein GMail - Konto nutzen, keine Mail aus unseren Onlineshops, welche den Bestellprozess dokumentieren. Selbstredend sind die Mail an Kunden, welche per Überweisung bestellen und natürlich alle Daten in dieser Mail enthalten sind.

Google bietet eine umfangreiche Dokumentation, ein Hilfeforum oder auch das Tool Postmaster, wo Bulk-Absender registriert werden können, um die Zustellung zu analysieren.

Wir haben heute für unsere Gruppe eine Testmail bei Gmail angelegt um das Zustellungsverhalten nachzeichnen zu können. Doch so richtig schlau sind wir auch nicht geworden. Ich habe mein Team gebeten, mir Testmails auf den Account zu senden. Alle Absender nutzen die gleiche Domain und Mailserver. Zwei Mails sind durchgegangen, 3 wurden Seitens Google als Spam abgelehnt, somit kann es nicht mit der Sender-IP zu tun haben.

SPF, DKIM, abuse, Revers alles im grünen Bereich...

Wer hat zur Zeit ähnliche Probleme?

Jan

PS: aus den Shops wird per SMTP gesendet, nicht per PHP-Mail.

technisches:

NS -> Schlund (primär und sekundär)
DNS wird über Schlund gewartet
Shops haben eigene IP mit SSL
gesendet wird über IP des Host

PSS: da einige Mails durchgehen und alle die selbe Domain und zustellenden Mailserver nutzen, kann hier keine IP-Blockade vorliegen.

 

[Xantiva]

Kannst Dir bei GMail den Mailheader ansehen? Gibt es da evtl. Auffälligkeiten? Wie unterscheiden sich die Testmails? Alles Text und HTML-Mail, oder ggf. nur Text-Mails?

 

[Kaj]

Das Problem haben wir von Anfang an gehabt. Leider konnte niemand helfen ( Servicepartner, JTL)

Bin gespannt ob es hier eine Lösung gibt

 

[christian1701]

Habe das gleiche Problem bei gmx Adressen (beide Shops von JTL gehostet) da wird fast 100% als spam abgelehnt. Auch erhalte ich beim Abrufen der Shop Mails über Outlook immer einen Sicherheitszertifikat hinweis (Zielprinzipname ist falsch). Das ist seit dem letzten Serverumzug beim JTL Hosting vor ein Paar Monaten aufgetaucht.

 

[Xantiva]

Ja und? Hat Outlook denn recht? Wenn Du die Mails per SSL abrufst, dann muss der Server auch ein Zertifikat für die korrekte Domain ausliefern. Gibt es z.B. nur ein einfaches Zertifikat (kein Wildcard) für die www.example.com, dann gilt das zwar noch für die example.com, aber nicht mehr für die mail.example.com. In so einem Fall kommt ein Warnhinweis, dass der Zertifikat nicht passt.

 

[B.N.C]

Web.de, Googlemail, Aol machen uns schon seit Anfang Probleme. Hier landet die hälfte im Spam Ordner.

 

[css-umsetzung]

Wenn diese Mails abgelehnt werden, bekommt Ihr ja einen entsprechenden Hinweis.
Was steht denn da drin, sehr oft ist das Problem ein fehlender SPF Eintrag, auch kann es Probleme geben, wenn der html Anteil zu hoch ist.

Im oberen Beitrag sehe ich das der SPF passt, es kann auch mit Prioritäten in Mails zu tun haben, das das spamlevel höher gesetzt wird.

Web.de bemängelt unter Umständen auch punkte im Betreff.

 

[elevennerds.de]

Hallo,

gesendet wird über IP des Host

sowas würde ich nicht machen, sondern immer über einen Mailprovider versenden. Ich nutze selbst 1und1, habe das schon bei einigen Kunden genauso implementiert und da gab es noch nie Probleme.

Gibt es einen Grund, warum ihr eure Mails direkt zustellt?

MfG

Rene

 

[exe]

Hallo !
Mir ist aufgefallen, dass der Mailserver kein valides Zertifikat besitzt - könnte mich aber auch irren, da ich nur schnell drüber geschaut habe.

Dmark und DKIM gehören ebefalls zum guten Ton und erhöhen das Vertrauen. Ansonsten gibt es noch Seiten, die deine Mails analysieren und entsprechend bewerten.

Gruß

 

[css-umsetzung]

ich glaube kaum einer hat diese beiden Werte gesetzt und dennoch kommen die E-Mails durch, ich hatte mit vom Threadstarter Shop auch mal Mails bei der Kundenerstellung und Löschung schicken lassen um das Spamlevel von Spamassasin zu sehen, da ist alles voll im grünen Bereich.

MX Tools zeigt nur an das er keinen Dmark hat und findet sonst alles OK.

 

[Xantiva]

Wie lautet denn der SPF-Eintrag? Ist der nur für die IP4-Adresse gesetzt und die IP6-Adresse wurde evtl. noch vergessen?
Ohne Details von den individuellen Problemen ist das nur ein rätselraten ...

 

[exe]

Wir suchen gerade die Nadel im Heuhaufen - ohne eindeutige Meldung ist das ein reines raten.

Es sind so viele Merkmale im Umlauf, die zur Filterung von SPAM genutzt werden, dass man sich nur mit einem einwandfreiem Mailserver und behutsames versenden von Mails schützen kann. dmark, DKIM und DANE werden beim Ranking deutlich unterschätzt, bei SPF wurde das jahrelang auch. Inzwischen wird SPF eher überschätzt. Es ist ebenfalls möglich, dass man mit einem Server schlicht in einer IP-Range liegt, die von vielen Betreibern schlicht ignoriert werden, da hilft nur Kontakt suchen und Whitelisten lassen. Je nach Anbietern, wollen die eine mündliche Zusage, dass man weiß was man tut, bis hin zum Pentest/Audit bestehen - die haben alle ihre eigenen Vorlieben

Wie erwähnt, gibt es Seiten die sich darauf spezialisiert haben, einzelne Mails nach "triggern" zu durchsuchen und transparent zu bewerten. Fehlerhaftes Encoding, Text vs. HTML Anteile, Sprachangaben, RFC Konforme Headerangaben, version des Mailers, usw.. SpamAssasin ist ein guter Helfer, doch die Mailservergiganten haben da noch weitere, nicht immer Nachvollziehbare, Bewertungen für ihre SPAM-Erkennung. Wer einen kommerziellen Mailserver betreibt, muss alles nehmen was er in die Hand bekommt, um seinen Mailserver als legitim erscheinen zulassen.

Und da bin ich auch der Meinung, wer das nicht schafft, sollte sich an einen Anbieter wenden der den ganzen Tag nichts anderes macht.

 

[lotex24.systems]

Hallo ...

bin mal nach über einen Monat zurück und möchte mal Bericht erstatten.

Seit zwei Tagen funktioniert die Zustellung an unsere GMail-Kunden ohne Probleme. Da eine Zustellung mal funktionierte und mal nicht (gleiche Absender Domain und Mailserver), haben wir eine IP-Blockade ausgeschlossen. Wir haben dann viel mit den SPF-Einträgen experimentiert und dort einen zusätzlichen Parameter für die IP-Adresse des Mailservers gesetzt, das funktionierte dann auch für eine kurze Zeit. Dann sind wir daher gegangen und haben Mails nur noch als TXT-Format an GMail-Kunden gesendet, was auch funktioniert hat und Tage später wieder nicht.

Man versucht sich ja in die Fehlernachrichten einzulesen und das Augenmerk fällt immer auf den Fehlercode, welchen man dann analysiert. Doch das grundlegende Problem lag ganz wo anders...

Ab und an prüfen wir die DMARC-Reports, wo auch die IP-Adresse des Mailservers verzeichnet ist, dieser Report kam von Google. Hinterlegt war eine IPv6-Adresse und diese gehört unserem Server. Eine nochmalige Prüfung der GMail-Fehlermeldung verzeichnete auch diese IPv6.

Warum auch immer, in der main.cfg von Postfix stand beim Eintrag inet_protocols = all (IPv4 und IPv6). GMail hat sich somit natürlich IPv6 gekrallt (Danke @Xantiva für den Hinweis auf IPv6), doch unser System ist komplett auf IPv4 konfiguriert. Wir haben den Eintrag jetzt auf inet_protocols = ipv4 gesetzt, Postfix natürlich neugestartet und Schwupps... FUNKTIONOBEL...

Jan

PS: Doch erklärt sich für uns daraus nicht, warum die Zustellung mal funktionierte und mal nicht...