HTML E-Mail bei einigen MailClients nur als PlainText

  • karlchen karlchen
    Jedi-General
    0 x
    1433 Beiträge
    30 Hilfreiche Beiträge
    01. 07. 2013, 14:26

    Hi,

    wir verschicken einen Newsletter der aus PLainText und HTML besteht, bei einige Empfänger wird er allerdings nicht korrekt interpretiert und es seiht aus, als ob der komplette HTML Teil nicht interpretiert wird und nur rein als kodierter PlainText ausgegeben wird.
    Wir haben das ganze mittlerweile mit schon http://litmus.com/ getestet und es liegt scheinbar nicht am HTML Konstrukt.

    Dazu kommt, das wenn ich einen Test-Newsletter versende, die Mails bei den betroffenen Personen korrekt ankommen, wenn ich den kompletten Newsletter rausschicke kommen Sie allerdings fehlerhaft ab.

    Einziger Unterschied beim versenden ist, das die Empfänger der Test-Newsletter aus einer direct_mail "Normale Liste" kommen und die richtigen Empfänger aus tt_address.

    Da ich das Problem nicht wirklich eingrenzen kann wäre ich für jede Idee und jeden Hinweis dankbar.


  • 1
  • florist florist
    Jedi-Ritter
    0 x
    130 Beiträge
    0 Hilfreiche Beiträge
    01. 07. 2013, 15:01

    Was genau meinst du mit direct_mail "Normale Liste"?
    Verwendest du ein tmpl für Plain und ein angepasstes für html oder eins für beide arten?
    Einziger Unterschied der mir spontan einfällt ist vielleicht, dass das "Recieve e-mails as HTML?" häkchen aus tt_address nicht korrekt gesetzt ist.

    Wir importieren grundsätzlich die Empfängerlisten via csv über direct_mail.
    Beim Schritt "Mapping" des imports setzen wir immer nochmal die Eigenschaft:

    1. Additional options<br>
    2. All recipients receive HTML newsletter

  • karlchen karlchen
    Jedi-General
    0 x
    1433 Beiträge
    30 Hilfreiche Beiträge
    01. 07. 2013, 21:27

    hi florist,

    "Normale Liste" ist die deutsche Übersetzung von direct_mail für den Recipient List Type "Plain list ", dort trägt man die E-Mails einfach in ein Textfeld ein. Diejenigen die sich normal auf der Seite über direct_mai_subscription registriert haben, landen als tt_address Datensatz in der DB. Auch die Felder wie "Recieve e-mails as HTML?" sind korrekt gesetzt. Da wir als Newsletter immer Plaintext und HTML versenden müsste diese Empfänger ja direkt die Plaintext Variante angezeigt bekommen.

    Habe mittlerweile auch mal die versendeten Newsletter angesehen. Wenn der Newsletter bei den testern defekt ist sieht das steht das im "TO:" Feld: 'TO: " " email@domain.de' wenn es korrekt ist steht nur 'TO: email@domain.de'. Der Unterschied sieht die Gänsefüsschen vor der E-Mail... Mal schauen, wenn ich rausfinde wo die herkommen und ich die beseitgt bekomme ob es dann klappt. Mein einziger Strohhalm momentan ... :(

  • karlchen karlchen
    Jedi-General
    0 x
    1433 Beiträge
    30 Hilfreiche Beiträge
    09. 07. 2013, 16:18

    mal nen kurzer Zwischenstatus, falls auch mal jemand das Problem haben sollte.

    Das Problem scheint nur mit nur mit Outlook 2003 zu bestehen, wenn in der E-Mail sowas steht

    "Erzeugt" wird der Code an dieser Stelle von /res/scripts/class.dmailer.php

    1. if (!empty($recipRow['name'])) {
    2. // if there's a name
    3. $recipient = array(
    4. $recipRow['email'] => $GLOBALS['LANG']->csConvObj->conv( $recipRow['name'], $GLOBALS['LANG']->charSet, $this->charset),
    5. );
    6. } else {
    7. // if only email is given
    8. $recipient = array(
    9. $recipRow['email'],
    10. );
    11. }

    Wenn der else zweigt genutzt wird, entsteht das Problem nicht, dann steht in der E-mail auch nur

    Um das Problem jetzt nur komplett zu lösen muss ich noch rausfinden ob es an "$GLOBALS['LANG']->csConvObj->conv()" liegt oder einem daraus resultierenden leeren Rückgabe. Oder eventuell an swiftmailer liegt. Doch nun erstmal den nächsten regulären Newsletter abwarten, wenn es dann keine negativen Rückmeldungen gibt. Schau ich noch mal genauer rein.

  • 1