Seit Version 4.0.0 der Extension MailformPlus (th_mailformplus) verfügt das Mail-Form Plugin über Funktionen zur Spam-Abwehr. Das ist zwar gut, führt aber in manchen Fällen leider zu Problemen...
Eine dieser neuen Funktionen ist das Abgleichen des HTTP Referer ($_SERVER['HTTP_REFERER']) mit einer per TypoScript definierten Liste von zulässigen Referers. Diese Liste wird standardmäßig (und automatisch) um den eigenen Server ($_SERVER['HTTP_HOST']) erweitert. Sinn und Zweck dieser Funktion ist es zu verhindern, dass jemand über einen anderen Server unser Mail-Formular missbraucht, um Spam zu verschicken. Dazu schickt der Spammer GET- oder POST-Requests (also abgesendete Formulare, mit seinem Content = Müll) von seinem Server an unsere Seite mit dem Formular. Würde der Referer nicht geprüft, schickt das Formular nun fleißig Mails über unseren Server und Mailadresse raus. Richtig problematisch wird es, wenn das Formular so konfiguriert ist, dass der Kunde eine Bestätigungsmail erhält! Dann geht der ganze Müll (abhängig von den Formular-Feldern die in der Mail verarbeitet werden) raus an die angegebene Email Adresse. Im anderen Fall, wird nur die Datenbank und das Postfach des Admin zugemüllt.
Das spricht natürlich dafür, die Standardkonfiguration so zu lassen wie es ist. Allerdings, wie ja schon geschrieben gibt's hier ab und an Probleme... Und zwar dann, wenn ein richtiger Kunde das Formular ausfüllt und aus irgendwelchen Gründen keinen Referer hat. Das kann z.B. durch bestimmte Netzwerk-Konfigurationen, Browser Plugins die den Referer löschen oder an den Firewall-Einstellungen liegen. Der nicht vorhandene Referer wird mit der Liste der zulässigen verglichen, was natürlich zu keiner Übereinstimmung führt. In Folge dessen, wird weder eine Mail an den User noch an den Admin gesendet. War es eine "dringende" Kontaktanfrage, hat man den potenziellen Neukunden unter Umständen verloren... blöd!
Dieses Verhalten kann man über TypoScript abstellen. Das geht so:
plugin.tx_thmailformplus_pi1.doNotCheckReferer = 1
Ich würde das Risiko nicht eingehen, einen Neukunden zu verlieren. Auf der anderen Seite ist es etwas Riskant die Prüfung des Referer abzustellen. Daher muss man einfach sehr genau beobachten was da vor sich geht ;).
Ach ja, es gibt noch 2 weitere Einstellungen um die Problematik etwas zu entschärfen. Zum einen kann man die Zahl der Email die an eine Email-Adresse gesendet werden begrenzen.
plugin.tx_thmailformplus_pi1.limitMailsToUser = 1
Und, zum andern könnte man ein Captcha einbauen - z.B. freeCap CAPTCHA (sr_freecap) oder reCAPTCHA (jm_recaptcha). Das hält zumindest die meisten Maschinen davon ab Spam zu verschicken. Auf der anderen Seite sind diese Captchas nicht sonderlich userfreundlich.
Tja... wie man's macht... isses falsch ;)! Was denkt Ihr?
Dienstag, 23. September 2008
Samstag, 13. September 2008
Direct Mail - Wo sind denn die CSS Styles hin?!
Das hab ich mich nach dem ersten Testversand meines Newsletters auch gefragt... Als ich mir die Seite ganz normal im Frontend anzeigen ließ, war noch alles in Ordnung - die Styles waren da und alles perfekt formatiert. Doch nach dem Versenden, sah das anders aus. Wo vorher noch CSS Styles im <head> Bereich des Newsletters zu finden waren... ist jetzt nur noch ein leeres <style></style> Tag vorhanden! Was um Himmels Willen ist da nun passiert?!
Die Antwort ist eigentlich ganz einfach - aber langsam... mich hat‘s auch einige graue Haare gekostet ;). In meinem Fall kam noch hinzu, dass ich über TypoScript sämtlichen Header-Code deaktiviert hatte um es dann selber, wiederrum über TypoScript, zu setzen. Das gibt mir die Möglichkeit genau zu steuern was da in den Header kommt. Das kann ich bei einem Newsletter nur empfehlen. Denn nur so, hat man die vollständige Kontrolle über den Header und es kann nicht mehr vorkommen, dass z.B. durch die Installation eines neuen Plugins irgendwelcher Header-Code - meist CSS oder JavaScript - plötzlich hinzukommt und unser Newsletter-Layout zerschießt. Wie das geht, seht Ihr hier:
# disable all header code
config.disableAllHeaderCode = 1
# define page element
page = PAGE
page.typeNum = 0
# set header code
page.10 = TEXT
page.10.value (
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title>...</title>
<style>
body {...}
p {...}
</style>
</head>
<body bgcolor="ffffff" text="#000000">
)
# set page content - in this case with templavoila
page.20 = USER
page.20.userFunc = tx_templavoila_pi1->main_page
# close body and html tag
# include tracking-pixel
page.30 = TEXT
page.30.value (
<img src="typo3conf/ext/direct_mail/res/gfx/dmailerping.gif" width="1" height="1" dmailerping="1" />
</body>
</html>
)
So, zurück zum eigentlichen Problem. Ist doch echt komisch, dass die Styles aus dem <style> Tag nach dem Versand einfach verschwunden sind obwohl ich es manuell hinzugefügt hatte. Google hat mir dazu einiges ausgespuckt. Doch alles was ich in den Foren lesen konnte war "es liegt an den Mail-Clients (Outlook, gmx, ...) ... die schneiden CSS manchmal einfach weg". Kann das sein? Ich meine NEIN. Habs auch getestet, mit sämtlichen Clients. Die Styles waren einfach weg. Das muss also irgendwie beim versenden passieren. Vielleicht gibt's ja nen TypoScript Parameter für Direct Mail, mit dem man dieses Verhalten steuern kann? ... Leider auch nicht. Dann fiel mir aber auf, dass sämtliche HTML-Kommentare aus dem Code entfernt wurden... na, dämmers scho ;)? Üblicherweise kommentiert man CSS-Styles im HTML-Code aus, damit ältere Browser die kein CSS unterstützen das nicht fälschlicherweise als Text mit ausgeben (im obigen Beispiel hab ich bewusst drauf verzichtet ;)). Also... ausprobieren... und siehe da... meine Styles sind wieder da... und alles ist gut! So einfach kann‘s manchmal sein.
Das Wegschneiden von HTML-Kommentaren ist eigentlich sinnvoll, denn es sind unnötige Bytes die hier in der Gegend rum geschickt werden - das allerdings auskommentierte Styles weggeschnitten werden... halte ich für einen Bug. Allerdings konnte ich die entsprechende Stelle im Code - auch nach langem Suchen - nicht finden... was mich ehrlich gesagt schon ein bisschen wurmt!
Jetzt noch mal kurz was zum Thema Newsletter und CSS im Allgemeinen. Bekanntlich verhalten sich die vielen Mail-Clients (online u. offline) höchst unterschiedlich was die Darstellung von CSS angeht. Daher ist es wichtig Formatierungen auf ein Minimum zu reduzieren. Beim Newsletter-Design (bei Webseiten bin ich ähnlicher Meinung) gilt: Weniger ist Mehr! Ihr erspart Euch jede Menge Ärger, wenn Ihr das das Design schlicht und mit wenigen Formatierungen gestaltet. Es gibt eine ausgezeichnete Übersicht welche Email-Clients was unterstützen - das sollte an dieser Stelle weiterhelfen. Und nachdem wir den CSS-Code damit sehr klein halten, halte ich es für sinnvoll den Code wie im obigen Beispiel direkt in den HTML-Code mit aufzunehmen und nicht über eine extern Datei einzubinden. Es hat den Vorteil, dass die korrekte Darstellung des Newsletters so nicht von der Verfügbarkeit Eures Servers abhängt. Und wie oben beschrieben... bloß nicht auskommentieren! Ich sehe das auch nicht als kritisch an. Die Clients die das <style> Tag nicht unterstützen kann man meiner Ansicht nach vernachlässigen - wenn es überhaupt noch welche gibt ist diese Zahl sehr gering (das sieht man selbst bei SELFHTML so).
Na dann… viel Erfolg beim Newsletterversand!
Die Antwort ist eigentlich ganz einfach - aber langsam... mich hat‘s auch einige graue Haare gekostet ;). In meinem Fall kam noch hinzu, dass ich über TypoScript sämtlichen Header-Code deaktiviert hatte um es dann selber, wiederrum über TypoScript, zu setzen. Das gibt mir die Möglichkeit genau zu steuern was da in den Header kommt. Das kann ich bei einem Newsletter nur empfehlen. Denn nur so, hat man die vollständige Kontrolle über den Header und es kann nicht mehr vorkommen, dass z.B. durch die Installation eines neuen Plugins irgendwelcher Header-Code - meist CSS oder JavaScript - plötzlich hinzukommt und unser Newsletter-Layout zerschießt. Wie das geht, seht Ihr hier:
# disable all header code
config.disableAllHeaderCode = 1
# define page element
page = PAGE
page.typeNum = 0
# set header code
page.10 = TEXT
page.10.value (
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title>...</title>
<style>
body {...}
p {...}
</style>
</head>
<body bgcolor="ffffff" text="#000000">
)
# set page content - in this case with templavoila
page.20 = USER
page.20.userFunc = tx_templavoila_pi1->main_page
# close body and html tag
# include tracking-pixel
page.30 = TEXT
page.30.value (
<img src="typo3conf/ext/direct_mail/res/gfx/dmailerping.gif" width="1" height="1" dmailerping="1" />
</body>
</html>
)
So, zurück zum eigentlichen Problem. Ist doch echt komisch, dass die Styles aus dem <style> Tag nach dem Versand einfach verschwunden sind obwohl ich es manuell hinzugefügt hatte. Google hat mir dazu einiges ausgespuckt. Doch alles was ich in den Foren lesen konnte war "es liegt an den Mail-Clients (Outlook, gmx, ...) ... die schneiden CSS manchmal einfach weg". Kann das sein? Ich meine NEIN. Habs auch getestet, mit sämtlichen Clients. Die Styles waren einfach weg. Das muss also irgendwie beim versenden passieren. Vielleicht gibt's ja nen TypoScript Parameter für Direct Mail, mit dem man dieses Verhalten steuern kann? ... Leider auch nicht. Dann fiel mir aber auf, dass sämtliche HTML-Kommentare aus dem Code entfernt wurden... na, dämmers scho ;)? Üblicherweise kommentiert man CSS-Styles im HTML-Code aus, damit ältere Browser die kein CSS unterstützen das nicht fälschlicherweise als Text mit ausgeben (im obigen Beispiel hab ich bewusst drauf verzichtet ;)). Also... ausprobieren... und siehe da... meine Styles sind wieder da... und alles ist gut! So einfach kann‘s manchmal sein.
Das Wegschneiden von HTML-Kommentaren ist eigentlich sinnvoll, denn es sind unnötige Bytes die hier in der Gegend rum geschickt werden - das allerdings auskommentierte Styles weggeschnitten werden... halte ich für einen Bug. Allerdings konnte ich die entsprechende Stelle im Code - auch nach langem Suchen - nicht finden... was mich ehrlich gesagt schon ein bisschen wurmt!
Jetzt noch mal kurz was zum Thema Newsletter und CSS im Allgemeinen. Bekanntlich verhalten sich die vielen Mail-Clients (online u. offline) höchst unterschiedlich was die Darstellung von CSS angeht. Daher ist es wichtig Formatierungen auf ein Minimum zu reduzieren. Beim Newsletter-Design (bei Webseiten bin ich ähnlicher Meinung) gilt: Weniger ist Mehr! Ihr erspart Euch jede Menge Ärger, wenn Ihr das das Design schlicht und mit wenigen Formatierungen gestaltet. Es gibt eine ausgezeichnete Übersicht welche Email-Clients was unterstützen - das sollte an dieser Stelle weiterhelfen. Und nachdem wir den CSS-Code damit sehr klein halten, halte ich es für sinnvoll den Code wie im obigen Beispiel direkt in den HTML-Code mit aufzunehmen und nicht über eine extern Datei einzubinden. Es hat den Vorteil, dass die korrekte Darstellung des Newsletters so nicht von der Verfügbarkeit Eures Servers abhängt. Und wie oben beschrieben... bloß nicht auskommentieren! Ich sehe das auch nicht als kritisch an. Die Clients die das <style> Tag nicht unterstützen kann man meiner Ansicht nach vernachlässigen - wenn es überhaupt noch welche gibt ist diese Zahl sehr gering (das sieht man selbst bei SELFHTML so).
Na dann… viel Erfolg beim Newsletterversand!
Abonnieren
Posts (Atom)
