Hallo,
mir sind nun nach 3 Tagen Fehler-Suche allmählich die Ideen ausgegangen.
Schicke ich eine einfache Plain-Text-Mail mit dem Text-Content
Zeile 1
Zeile 2
steht dann in der Mail
Zeile 1Zeile 2
Dies betrifft sämtliche Versandformen im Plain-Text außer QuickMail, das ist OK.
An type=99 (bzw. plaintextLib.inc) liegt es m.E. nicht. Ich habe bereits eine .txt-Datei auf den Server gestellt und die per Direct Mails / Plain Text URL versandt. Diese hat auch ganz sicher chr(13)+chr(10) an den Zeilen-Enden gehabt. Mehr Text "pur" geht sicher nicht. Ich frage mich, wo werden die Zeilenumbrüche entfernt ???? Habe die 'class.mod_web_dmail.php' natürlich auch abgegrast.
Vielleicht liegt´s Problem auch irgendwo "draußen" an base64 oder iso-8859-1? Wenn ich per base64 verschicke, wandelt mein Empfangs-Mailserver die Mail autom. ins 8bit Format. Könnten dabei die CR´s hopps gehen?
Puh, ich hoffe, jemand kann mir den entscheidenen Tip geben.
Viele Grüße
D.
(PS. ... und wieso bin ich offensichtl. der einzige, der damit hadert?)
1. Hast du die Mails im Mailclient angeschaut, oder im Webbrowser? Das ist ein Unterschied. Im Browser zeigt der keine CR/LF an (weil es ja erst in <br> gewandelt werden muß). Es gibt einen Trick: Laß dir den Quelltext anzeigen, wenn da die CR/LF drin sind, kommt es auch im Mailclient richtig an.
2.
wandelt mein Empfangs-Mailserver die Mail autom. ins 8bit Format.
das ist ungewöhnlich. bitte mal abschalten. eventl ist dass das problem
3.
(PS. ... und wieso bin ich offensichtl. der einzige, der damit hadert?)
Bitte nimm es nicht persönlich, aber wir hatten ja schon das Vergnügen. Vielleicht hast du einfach nicht genug Erfahrung... Zumindest fande ich Deine Antwort etwas arrogant. Aber das kann ja mal passieren, wenn man zu tun hat.
Hallo
und danke für die Antwort!
Hast du die Mails im Mailclient angeschaut, oder im Webbrowser?
Im Mailclient.
Ich verwende neben html-fähigen Clienten auch reine Text-Clienten (Popcorn falls bekannt).
Chr(10) und (13) sind dann beim Empfang bereits draußen, dessen bin ich mir sicher. Hab´ die Mails auch mit ´nem Hex-Editor untersucht.
Laß dir den Quelltext anzeigen, wenn da die CR/LF drin sind, kommt es auch im Mailclient richtig an.
Jo, bereits gemacht.
bitte mal abschalten. eventl ist dass das problem
Die T3-Mails versende ich über einen eigenen Server, empfangen tue ich allerdings über einen Provider-Account. Dort habe ich natürlich nur bedingt bis garkeinen Einfluß auf irgendwelche Einstellungen.
Allerdings haben inzwischen weitere Tests ergeben, daß es daran auch nicht liegen dürfte, da er in anderen Fällen nicht konvertierte und das Problem trotzdem bestand.
Vielleicht hast du einfach nicht genug Erfahrung... Zumindest fande ich Deine Antwort etwas arrogant
??? Hätte ich die Erfahrung würde ich sicher nicht hier posten. Allerdings bitte ich auch mir zuzugestehen, daß ich als erfahrener Programmierer mit Fehleranalysen umzugehen weiß.
Das Geschriebenes leider oft anders ankommt als Gesagtes, das wissen wir sicher von allg. Korrespondenzen aus der Geschäftswelt etc. (passiert halt immer wieder). Ich hoffe, da sehen wir drüber hinweg.
Gruß
D.
Ok, letzter Versuch, um nochmal Klarheit zu haben. Ruf den newsletter mit type=99 oder type=199 in der url auf im browser auf. und laß dir das ergebnis als quelltext anzeigen. wenn da die cr/lf drin sind, weiß ich auch nicht weiter. ich habe schon zig mal newsletter installiert und auch fett umgebastelt. hatte noch nie das problem. auch mit html-checkbox im be habe ich überall eingebaut. verwende postfix als mailer, der macht am geringsten fehler. alles andere kannst du natürlich schwer beeinflußen.
c.
p.s. hmm, aber das hast du schon ausprobiert... (s. thread-start).
Ach so, mein jetztiger Stand ist der...
Möglicherweise ist das kein T3-Problem, denn T3 übergibt seine Plain-Texte zur base64-Konvertierung an den Anwendungsserver (so wie ich das aus den Quell-Codes rausgelesen habe). Nur kann ich mir wiederrum nicht vorstellen, daß dort das Problem sitzt, da ich mit Suse 8.2 up-to-date bin. Aber auf jeden Fall ein Ansatz für die weitere Suche.
Gruß
D.
Ruf den newsletter mit type=99 oder type=199 in der url auf im browser auf. und laß dir das ergebnis als quelltext anzeigen. wenn da die cr/lf drin sind, weiß ich auch nicht weiter
Das war mit das Erste, was ich untersucht hatte. Sie waren dort nicht drin. Dann habe ich die plaintextLib.inc so umgebaut, daß sie drin sind.
Leider hat das aber nix genützt.
Aber dennoch vielen Dank !
Wenn ich dahinter gekommen bin, werde ich es hier posten.
Gruß
D.
type=99: Aber(!) Ergebnis nicht im Browser betrachten, sondern als Quelltext. Nur dann siehst du die CR/LF.
c.
Ps. Ich habe sogar plaintext so umgebaut das es auf Mac läuft, weil im original wird nur CR als Zeilenumbruch verwendet. Macs kapieren das nicht, sonder nur CR/LF (Entourage Client hatte plötzlich auch keine Umbrüche mehr). Ich will damit sagen, dass die Ext 100% läuft.
type=99: Aber(!) Ergebnis nicht im Browser betrachten, sondern als Quelltext. Nur dann siehst du die CR/LF.
Jo, auch das, indem ich die Quell-Text-Ansicht des Browsers beansprucht sowie die Datei auf HD gespeicht habe.
Gruß
D.
merkwürdig. ich würde dir ja gerne weiter helfen (typo3 login wäre jetzt nicht schlecht). aber das kostet dann geld. wie dem auch sei. guten rutsch.
c.