Inline Images

[uli64]

Hallo,

kennt jemand eine Email App die[FONT=&quot] Inline Images unterstüzt?

Gruß Uli
[/FONT]

 

[mizch]

Inline Images gibt es nur bei HTML-E-Mails. Die sind weit weit weg von jedem gültigen E-Mail-Standard (und meiner Meinung nach grober Unfug, der Ungeziefer wie Webbugs mitbringt und mehr). Um HTML-E-Mails zu erstellen, brauchst Du einen HTML-Composer. Ich glaube nicht, dass in absehbarer Zeit ein E-Mail-App-Entwickler sich so ein Ungetüm antut.

 

[Rak]

Naja, wegen HTML: MailDroid kann wohl bei Text einiges mitgeben (Fett, kursiv, Farbe usw.)

 

[uli64]

Mir geht es darum das ich mein Angebotsformular das ich Word kopiere inkl Logo und dann in die Mail einfüge. Aber das Logo lässt sich nicht einfügen. Zur Info, ich will das in mein Tab in die Mails einfügen

 

[Rak]

Ich hatte mich auf mizch bezogen und ergänzt.

(..) ich Word kopiere inkl Logo und dann in die Mail einfüge. (..)

Sorry, das ist ja schon am PC übel . Das kann bei Empfängern gruselig aussehen. Seriös ist sowas eigentlich nicht.

Was du willst geht so wohl nicht.

Ich würde dir sowieso auch am PC für sowas eine normale Textsignatur empfehlen. Wenn es nicht anders geht, hänge ein PDF an die Mail.

 

[jna]

So falsch auch

Die sind weit weit weg von jedem gültigen E-Mail-Standard

ist -- deine Idee

mein Angebotsformular das ich Word kopiere inkl Logo und dann in die Mail einfüge.

ist wirklich absurd. Da hängt man ein PDF an.

 

[mizch]

(HTML-Mail ist kein Standard)
-- deine Idee

Nein. E-Mail ist in RFC 2822 und den MIME-RFCs standardisiert. Nenne mir mal den RFC, der HTML-Mail definiert. Ersatzweise gerne auch ein Dokument irgendeiner anderen Standard-Organisation.

Nachtrag: Man kann über die einzelnen Punkte in Why HTML in EMail is a bad Idea unterschiedlicher Ansicht sein, aber der Punkt

Because it violates the e-mail standards and protocols unnecessarily.

ist nicht neu, ist bekannt und findet sich häufig, wenn man nach den drei Stichworten „HTML eMail evil” sucht. Also danke für die Zuschreibung, diese Idee sei von mir, aber die Ehre gebührt nicht nicht mir, sie ist eher als Tatsache allgemein bekannt und wird auf Seiten wie der genannten und vielen anderen diskutiert.

 

[jna]

Versteh' mich nicht falsch - zu dem Zeitpunkt, als das von dir zitierte Panphlet erschien, mögen viele Argumente gestimmt haben, und wurden durchaus von mir geteilt - aber die sind heute, 15 Jahre später, obsolet.

HTML-Mails sind durchaus RFC-Konform (RFC 2557, RFC 2854). Problematisch kann höchstens sein, dass ein Client kein HTML darstellen kann, während der sender keinen Plaintext mitschickt. Das dürfte in der Realität des Jahres 2013 aber auch nicht mehr vorkommen.

Um aber nicht völlig abzuschweifen - das hat mit der ursprünglichen Frage nämlich nichts zu tun, und hier waren wir uns einig, dass die Lösung des Problems des Fragestellers mit "PDF-Anhang" wohl am besten zu beantworten ist

 

[mizch]

Die genannten MIME-RFCs findet man zwar, wenn man nach „HTML” und „email” sucht, definieren aber den Transport eines kompletten HTML-Dokuments innerhalb eines E-Mail-Bodys, äquivalent zum Transport einer Audio-Datei oder eines PDF-Dokuments als MIME Part. Sie haben nichts mit dem etwas kruden Subset von HTML zu tun, der in HTML-Emails verwendet wird und der nirgends standardisiert ist. Um die von Dir zitierten RFCs zu erfüllen, müsste ein E-Mail-Client einen vollständigen Browser integriert haben (was nirgends der Fall ist) oder aber das ganze HTML-Dokument an einen Browser weitergeben (was viele, wenn nicht die meisten Clients tun). Diese RFCs haben nichts mit heutigen HTML-Emails zu tun, denn die transportieren ihr HTML eben nicht mit den dort beschrieben Eigenschaften in der dort beschriebenen Form, sondern verletzen genau diese RFCs und andere.

Versteh' mich nicht falsch - zu dem Zeitpunkt, als das von dir zitierte Panphlet erschien, mögen viele Argumente gestimmt haben, und wurden durchaus von mir geteilt - aber die sind heute, 15 Jahre später, obsolet.

Du hast nicht mal die Einführung gelesen. Letztes Update war 2006. Und seither hat sich in Sachen HTML-Email nichts getan. Das kannst Du mir ruhig glauben. HTML-E-Mail ist nach wie vor ein Gebiet, in dem jeder ohne jeden Standard eigene Brötchen backt. Der eine Client kann dies mehr, der andere jenes. Noch schlimmer sieht es aus, wenn es nicht ums Lesen, sondern ums Verfassen geht. Da bleiben meistens nur ein paar (nicht einheitliche) Schriftarten und -größen, ein paar (bis auf die Grundfarben nicht einheitliche) Schriftfarben und die Unterbringung von bunten Bildchen mit etwas Positionierung.

hier waren wir uns einig, dass die Lösung des Problems des Fragestellers mit "PDF-Anhang" wohl am besten zu beantworten ist

Ja. Da sind wir uns einig. Denn hier handelt es sich um ein standardisiertes Format, das auch eine längere Archivierung überdauert.

 

[jna]

Doch habe ich. Insbesondere "The author's feelings on HTML in email have largely changed since then".

Und ja, mir reicht es in Mails aus, fett oder kursiv zu schreiben - und nicht *fett* oder /kursiv/.

 

[mizch]

"The author's feelings on HTML in email have largely changed since then".

Meine auch. Ich habe schon vor ein paar Jahren meinen gnus seufzend durch Thunderbird ersetzt.

Der Punkt war halt, dass Du gemeint hast, es sei nur meine Idee, dass HTML in E-Mail nicht standardisiert sei. Es gab um die Jahrtausendwende einige Bemühungen in der IETF, so etwas zu erreichen. Microsoft hat sich nicht darum gekümmert und sein eigenes Ding gemacht (wohl um Alleinstellungsmerkmale für sein Windows zu erreichen, wie so oft bei Standards). In dieser Zeit wurde auch das oben verlinkte Dokument ursprünglich verfasst, weil viele sich auf den Standpunkt stellten, das alles sei angesichts dieser Umstände ohnehin Quatsch und man solle es ganz bleiben lassen. Die Standardisierung verlief im Sande und das ist bis heute so geblieben.

 

[jna]

Ich weiß wohl und kann mich gut erinnern...

 

[Rak]

Hey Vorsicht, wer heutzutage noch weiß, was ein RFC ist, wird in den "Club der alten Säcke" verbannt ...