Linuchs: Mail-Versand: Eingebundenes Logo mehrfach zeigen, per CSS definierbar?

0 54

Mail-Versand: Eingebundenes Logo mehrfach zeigen, per CSS definierbar?

Linuchs
  • css
  1. 0
    Rolf B
    1. 0
      Linuchs
      1. 0
        Rolf B
        1. 0
          Der Martin
          1. 1
            Mitleser 2.0
            1. 1
              Der Martin
            2. 0
              TS
              • css
              • datenschutz
              • e-mail
              1. 0
                Mitleser 2.0
                1. 0
                  TS
                  1. 0
                    Mitleser 2.0
                    1. 0
                      TS
                      • netzwerk
                      • programmiertechnik
                      • rfc
                      1. 0
                        Der Martin
                        • humor
                        • tippfehler
                        1. 0
                          TS
                      2. 0
                        Rolf B
                      3. 0
                        Mitleser 2.0
        2. 0
          Linuchs
          1. 0
            Rolf B
            1. 0
              Mitleser 2.0
              1. 1
                Rolf B
                1. 0
                  Der Martin
                2. 0
                  Mitleser 2.0
            2. 0
              Linuchs
              1. 0
                Rolf B
                1. 0
                  Linuchs
                  1. 0
                    Der Martin
                    1. 0

                      gelöst - danke

                      Linuchs
        3. 0
          Camping_RIDER
  2. 0
    Gunnar Bittersmann
    • html
  3. 1
    Mitleser 2.0
    1. 0
      Linuchs
    2. 0
      Camping_RIDER
      1. 1
        Mitleser 2.0
  4. 1

    Mail-Versand: Eingebundenes Logo mehrfach zeigen, per CSS definierbar? -> MIME-Type

    Ralf
    • css
    • e-mail
    • html
  5. 1
    TS
    • css
    • e-mail
    • mime
    1. 0
      Der Martin
    2. 1
      Mitleser 2.0
      1. 1
        Der Martin
        1. 0
          Mitleser 2.0
          1. 0
            TS
            • meinung
            • zu diesem forum
          2. 0
            Der Martin
            1. 0
              Camping_RIDER
              1. 1
                Der Martin
                1. 2
                  Camping_RIDER
                  1. 0
                    Der Martin
                    1. 1
                      Camping_RIDER
                      1. 2
                        Tabellenkalk
                      2. 0
                        Der Martin
                        1. -1
                          Mitleser 2.0
                          1. 1
                            Der Martin
                  2. 0
                    Mitleser 2.0
                2. 1
                  Rolf B
                  1. 0
                    Der Martin
            2. 0
              Mitleser 2.0

Moin,

ich möchte Mails im HTML-Format versenden *), ein eingebundenes Logo soll mehrmals im Text gezeigt werden. Auf meinen Webseiten habe ich sowas:

.remso {
  background-image: url("/img/logo_remso.png");
  background-repeat: no-repeat;
  background-position: left bottom;
  background-size: 1.5em 1.5em; /* width height */
  font-family: sans-serif;
  letter-spacing: 0.1em;
  padding-left: 1.8em;
  color: #f00;
}

In der Mail ist /img/logo_remso.png natürlich nicht greifbar und bei einmaliger Nutzung würde ich es so lösen:

<img src=
"data:image/png;base64,iVBORw0KGgo ... RU5ErkJ ggg==" />

Wie kann ich das Logo in der Mail mehrfach zeigen?

*) bitte um einen Link, wie ich zusätzlich text/plain in die Mail integriere.

Gruß, Linuchs

  1. Hallo Linuchs,

    zum Sternchen fällt mir höchstens ein, die Ausgabe mit htmlspecialchars($plaintext) zu machen und bedarfsweise ein <div> oder eine <figure> mit CSS-Eigenschaften wie white-space für die Formatierung drumrum zu setzen.

    Das Problem bei img ist, dass Du ein neues, ggf. störendes Element im DOM hast. Das hier müsste doch auch funktionieren:

    .remso {
      background-image: url("data:image/png;base64,iVBORw0KGgo ... RU5ErkJ ggg==");
      background-repeat: no-repeat;
      background-position: left bottom;
      background-size: 1.5em 1.5em; /* width height */
      font-family: sans-serif;
      letter-spacing: 0.1em;
      padding-left: 1.8em;
      color: #f00;
    }
    

    Rolf

    --
    sumpsi - posui - obstruxi
    1. Hallo Rolf,

      Das hier müsste doch auch funktionieren:

      Leider nein, weder mit noch ohne url(). Fehlermeldung des Firefox: Ungültiger Wert für Eigenschaft

      Gruß, Linuchs

      1. Hallo Linuchs,

        Leider nein, weder mit noch ohne url()

        Dann machst Du was falsch oder hat einen merkwürdigen Firefox.

        https://jsfiddle.net/7vswqbnj/1

        Funktioniert unter FF Win 94

        Das ist aber egal - der HTML Renderer der Mailprogramme muss es können. Und da bin ich mir gerade nicht so sicher, wie gut die bei Data-URLs sind. Das hier ist wenig optimistisch.

        Eine absolute URL zu verwenden hat natürlich auch was. Vor allem dann, wenn Du die Kundennummer des Empfängers als Query Parameter ans Bild hängst und dann in deinem Log auswertest, wer die Mail bekommen hat.

        Rolf

        --
        sumpsi - posui - obstruxi
        1. Hallo,

          Eine absolute URL zu verwenden hat natürlich auch was. Vor allem dann, wenn Du die Kundennummer des Empfängers als Query Parameter ans Bild hängst und dann in deinem Log auswertest, wer die Mail bekommen hat.

          ja, und weil genau das auch von Spammern und zwielichtigen Geschäftsleuten missbraucht wird (Ist das eine aktiv benutzte Mailadresse?), ist bei den meisten Mailclients inzwischen die Voreinstellung, Bilder aus dem Web nicht automatisch nachzuladen, sondern erst wenn der Nutzer das ausdrücklich will.

          May the Schwartz be with you
           Martin

          --
          Theorie ist, wenn eigentlich jeder weiß, wie's gehen müsste, und es geht doch nicht.
          Praxis ist, wenn's geht, obwohl es keiner so richtig versteht.
          Bei uns sind Theorie und Praxis vereint: Nichts geht, und keiner weiß, warum.
          1. ja, und weil genau das auch von Spammern und zwielichtigen Geschäftsleuten missbraucht wird (Ist das eine aktiv benutzte Mailadresse?), ist bei den meisten Mailclients inzwischen die Voreinstellung, Bilder aus dem Web nicht automatisch nachzuladen, sondern erst wenn der Nutzer das ausdrücklich will.

            Fun fact: der Gmail Webmailer lädt die per Default! Allerdings zieht Google sich sich die Ressource zunächst vom fremden Host und schreibt den SRC dann um für den View im Webmail. Dadurch ist zumindest verschleiert ob der Account genutzt, bzw. ob die Mail angeschaut wurde.

            Gar nicht mal so dumm. Theoretisch müsste Gmail dass dann aber für alle eingehenden Mails machen, also auch für Accounts, die gar nicht existieren. Ansonsten: Abruf = Account existiert zumindest.

            Den Test hab ich bislang noch nicht gemacht.

            1. Hallo,

              ja, und weil genau das auch von Spammern und zwielichtigen Geschäftsleuten missbraucht wird (Ist das eine aktiv benutzte Mailadresse?), ist bei den meisten Mailclients inzwischen die Voreinstellung, Bilder aus dem Web nicht automatisch nachzuladen, sondern erst wenn der Nutzer das ausdrücklich will.

              Fun fact: der Gmail Webmailer lädt die per Default!

              naja, bekanntlich steht ja das D in Google für Datenschutz.

              May the Schwartz be with you
               Martin

              --
              Theorie ist, wenn eigentlich jeder weiß, wie's gehen müsste, und es geht doch nicht.
              Praxis ist, wenn's geht, obwohl es keiner so richtig versteht.
              Bei uns sind Theorie und Praxis vereint: Nichts geht, und keiner weiß, warum.
            2. Hello,

              ja, und weil genau das auch von Spammern und zwielichtigen Geschäftsleuten missbraucht wird (Ist das eine aktiv benutzte Mailadresse?), ist bei den meisten Mailclients inzwischen die Voreinstellung, Bilder aus dem Web nicht automatisch nachzuladen, sondern erst wenn der Nutzer das ausdrücklich will.

              Fun fact: der Gmail Webmailer lädt die per Default! Allerdings zieht Google sich sich die Ressource zunächst vom fremden Host und schreibt den SRC dann um für den View im Webmail. Dadurch ist zumindest verschleiert ob der Account genutzt, bzw. ob die Mail angeschaut wurde.

              Wann genau tut er das? Schon beim Empfang der Header (und des ersten Body-Teiles?) auf dem Post-Office oder erst on-the-Fly beim Abruf per Webmailer vom Post-Office?

              Gar nicht mal so dumm. Theoretisch müsste Gmail dass dann aber für alle eingehenden Mails machen, also auch für Accounts, die gar nicht existieren. Ansonsten: Abruf = Account existiert zumindest.

              Den Test hab ich bislang noch nicht gemacht.

              Interessanter Recherche-Tipp.

              Bei nachzuladendem CSS gab es bisher immer noch eine Lücke bei den meisten eMail-Clients. Den Request kann/konnte man daher immer noch personalisieren.

              Glück Auf
              Tom vom Berg

              --
              Es gibt nichts Gutes, außer man tut es!
              Das Leben selbst ist der Sinn.
              1. Wann genau tut er das? Schon beim Empfang der Header (und des ersten Body-Teiles?) auf dem Post-Office oder erst on-the-Fly beim Abruf per Webmailer vom Post-Office?

                Keine Ahnung. Auch das könnte man recht einfach testen.

                1. Hello,

                  Wann genau tut er das? Schon beim Empfang der Header (und des ersten Body-Teiles?) auf dem Post-Office oder erst on-the-Fly beim Abruf per Webmailer vom Post-Office?

                  Keine Ahnung. Auch das könnte man recht einfach testen.

                  Das sollte man testen, um für dieses Forum und ggf. andere einen Mehrwert zu generieren :-)

                  Glück Auf
                  Tom vom Berg

                  --
                  Es gibt nichts Gutes, außer man tut es!
                  Das Leben selbst ist der Sinn.
                  1. Wann genau tut er das? Schon beim Empfang der Header (und des ersten Body-Teiles?) auf dem Post-Office oder erst on-the-Fly beim Abruf per Webmailer vom Post-Office?

                    Keine Ahnung. Auch das könnte man recht einfach testen.

                    Das sollte man testen, um für dieses Forum und ggf. andere einen Mehrwert zu generieren :-)

                    Hau rein! 👍

                    1. Hello,

                      Wann genau tut er das? Schon beim Empfang der Header (und des ersten Body-Teiles?) auf dem Post-Office oder erst on-the-Fly beim Abruf per Webmailer vom Post-Office?

                      Keine Ahnung. Auch das könnte man recht einfach testen.

                      Das sollte man testen, um für dieses Forum und ggf. andere einen Mehrwert zu generieren :-)

                      Hau rein! 👍

                      Das war deine Show. Die will ich Dir nicht stehlen.

                      Allerdings würde ich mir schon anschauen, was und wie Du es ermittelst hast.
                      Nun zeig mal, dass Du nicht nur reden kannst ;-P

                      Von mir findest Du hierzu (eventuell noch) diverse tiefer gehende Postings im Forumsarchiv in der Zeit von ca. 2005 bis 2013. Danach hatte ich eher andere (für mich spannende) Themen auf dem Schirm.

                      Z. B.:
                      Kann man aus zwei vorhandenen IPs (V4) das kleinste gemeinsame Supernet bestimmen? Dass sowas geht und üblich ist, war MIR vollkommen klar, aber mein Auftraggeber (Bildungsanbieter) konnte damit nicht wirklich etwas anfangen, obwohl Superpetting in seinem eigenen Curriculum stand.
                      Hierzu jetzt aussagefähige und leicht verständliche Erläuterungen und Normen (z. B. RFCs) zu finden, hat mich doch sehr von sinnvollen Dingen abgehalten.
                      Schließlich hat es mich Aufträge gekostet.

                      Glück Auf
                      Tom vom Berg

                      --
                      Es gibt nichts Gutes, außer man tut es!
                      Das Leben selbst ist der Sinn.
                      1. Hallo Tom,

                        Das war deine Show. Die will ich Dir nicht stehlen.

                        vor allem braucht's zum Testen einen gmail-Account. Hast du einen? - Ich nicht.

                        obwohl Superpetting in seinem eigenen Curriculum stand.

                        Herzliche Grüße vom guten alten Dr. Freud! 😀

                        May the Schwartz be with you
                         Martin

                        --
                        Theorie ist, wenn eigentlich jeder weiß, wie's gehen müsste, und es geht doch nicht.
                        Praxis ist, wenn's geht, obwohl es keiner so richtig versteht.
                        Bei uns sind Theorie und Praxis vereint: Nichts geht, und keiner weiß, warum.
                        1. Hello Martin,

                          Das war deine Show. Die will ich Dir nicht stehlen.

                          vor allem braucht's zum Testen einen gmail-Account. Hast du einen? - Ich nicht.

                          Ich hätte vermutlich sogar einen auf einem der eingeschläferten Lappis.

                          obwohl Superpetting in seinem eigenen Curriculum stand.

                          Herzliche Grüße vom guten alten Dr. Freud! 😀

                          Oh heiliger GPunkt mein lieber Schlomo! Das war jetzt aber wirklich nur ein Tippfehler.

                          Deshalb habe ich den Auftrag aber auch nicht verloren. Aber der Verantwortliche hatte durchaus partiell Fachwissen, mit dem ich nicht mithalten konnte. Das war aber auch nicht Gegenstand meiner Semianarblöcke in dem Zyklus. Dafür war er eben im Bereich Networking nicht so firm, glaubte aber, dies zu sein (-> Dunning Kruger).

                          Genau diese Erfahrungen bringen mich aber immer wieder dazu, dass man tatsächlich immer erst "die Energie des Verstehens" fördern sollte, bevor man jemand mit "best Practice" und Fertiglösungen überfährt.

                          Das soll aber keinesfalls die Verlinkung von Fertiglösungen inklusive Anmerkungen dazu verteufeln. Wenn schnelle Arbeit notwendig ist, kann das schon helfen. Es kumuliert dann eben nur von Schicht zu Schicht auch die Fehler(quellen).

                          Glück Auf
                          Tom vom Berg

                          --
                          Es gibt nichts Gutes, außer man tut es!
                          Das Leben selbst ist der Sinn.
                      2. Hallo TS,

                        obwohl Superpetting in seinem eigenen Curriculum stand.

                        Das wage ich ernsthaft zu bezweifeln…

                        Aber - interessante Auswirkung der Autokorrektur. p und n sind ja nun nicht ganz so nah beieinander 😂

                        Rolf

                        --
                        sumpsi - posui - obstruxi
                      3. Keine Ahnung. Auch das könnte man recht einfach testen.

                        Das sollte man testen, um für dieses Forum und ggf. andere einen Mehrwert zu generieren :-)

                        Hau rein! 👍

                        Das war deine Show. Die will ich Dir nicht stehlen.

                        Ich hab hier nen fun fact zum Thema in die Runde geworfen, der mir vor einiger Zeit durch Zufall aufgefallen ist. Thats it. Also wenn es hier noch ne Show geben soll, muss sich jemand Anderes drum kümmern.

        2. Hallo Rolf,

          Dann machst Du was falsch oder hat einen merkwürdigen Firefox.

          Danke für deine Mühe, das Hintergrund-Bild bei fiddle kann ich sehen. Ich hatte Gänsefüße:

            .remso {
              background-image:
          url("data:image/png;base64,iVBORw0K...AAAAABJ
          RU5ErkJ ggg==");
          

          Doch auch nach Schlachten der Gänse erscheint das Logo nicht, hier die FF-Meldung:

          ...

          Ungültiger Wert für Eigenschaft. Den \ vor ); hat FF dazugedichtet, ist nicht von mir. Bei deinem fiddle ist er mit dem Inspektor nicht zu sehen.

          Gruß, Linuchs

          1. Hallo Linuchs,

            ist Dir ein Zeilenumbruch reingerutscht? Das muss eine Megalange Zeile sein.

            Es ist aber rein akademisch. Wie ich eben verlunken habe, ist der Support für data-URLs in Mailclients nicht gut genug.

            Rolf

            --
            sumpsi - posui - obstruxi
            1. Es ist aber rein akademisch. Wie ich eben verlunken habe, ist der Support für data-URLs in Mailclients nicht gut genug.

              Das stimmt nicht. Der Support ist sehr gut - soweit man die Bilder nicht direkt, sondern via CID/Content-ID einbindet.

              1. Hallo Mitleser,

                vielleicht mangelt es mir ja an Erfahrung mit HTML Mails, aber wenn ich das richtig verstehe, sind CIDs und Data-URIs zwei paar Schuhe.

                CID: Referenz auf Bild als Mail-Attachment
                DATA-URI: Bild ist inline im CSS

                Das wäre also ein ganz anderer Ansatz. Einer, der durchaus positiv klingt.

                Rolf

                --
                sumpsi - posui - obstruxi
                1. Hallo Rolf,

                  vielleicht mangelt es mir ja an Erfahrung mit HTML Mails, aber wenn ich das richtig verstehe, sind CIDs und Data-URIs zwei paar Schuhe.

                  CID: Referenz auf Bild als Mail-Attachment
                  DATA-URI: Bild ist inline im CSS

                  ja, das ist richtig. [EDIT: Nicht nur im CSS, auch im HTML]

                  Das wäre also ein ganz anderer Ansatz. Einer, der durchaus positiv klingt.

                  Genau. Denn so hat man das vor 20 Jahren schon gemacht.

                  May the Schwartz be with you
                   Martin

                  --
                  Theorie ist, wenn eigentlich jeder weiß, wie's gehen müsste, und es geht doch nicht.
                  Praxis ist, wenn's geht, obwohl es keiner so richtig versteht.
                  Bei uns sind Theorie und Praxis vereint: Nichts geht, und keiner weiß, warum.
                2. vielleicht mangelt es mir ja an Erfahrung mit HTML Mails, aber wenn ich das richtig verstehe, sind CIDs und Data-URIs zwei paar Schuhe.

                  Ja, stimmt. Unsauber formuliert meinerseits.

            2. Hallo Rolf,

              ist Dir ein Zeilenumbruch reingerutscht?

              Jede Menge, ich habe den kryptischen base64-Block aus dem Quellcode der Mail genommen. Wenn ich das so im HTML-Teil eingebe, funktioniert es.

              Okay, nun sind die Zeilenumbrüche im css-Teil raus, FF dichtet auch kein \ mehr dazu, aber es funktioniert immer noch nicht, dieselbe Fehlermeldung wie vorher.

              Ich nehme testweise mal dein Bild aus dem fiddle. Funktioniert bei mir auch nicht.

              Gruß, Linuchs

              1. Hallo Linuchs,

                hast Du das irgendwo online?

                Rolf

                --
                sumpsi - posui - obstruxi
                1. Halo Rolf,

                  ich habs mal hochgeladen. Gehst du auf remso.eu

                  Und ergänzt die URL um /mailing_werbung.htm

                  Wenn ich aus deinem fiddle eine eigene htm mache, sehe ich den Hintergrund. Habe aber nicht entdeckt, was bei mir schief läuft.

                  Gruß, Linuchs

                  1. Hallo,

                    ich habs mal hochgeladen. Gehst du auf remso.eu

                    Und ergänzt die URL um /mailing_werbung.htm

                    wenn ich mir da den Quellcode ansehe, entdecke ich im base64-Code ziemlich am Ende ein Leerzeichen, das den Code ungültig macht. Wo kommt das her?

                    May the Schwartz be with you
                     Martin

                    --
                    Theorie ist, wenn eigentlich jeder weiß, wie's gehen müsste, und es geht doch nicht.
                    Praxis ist, wenn's geht, obwohl es keiner so richtig versteht.
                    Bei uns sind Theorie und Praxis vereint: Nichts geht, und keiner weiß, warum.
                    1. Hallo Martin,

                      im base64-Code ziemlich am Ende ein Leerzeichen, das den Code ungültig macht. Wo kommt das her?

                      Das war's. Vermutlich beim Zusammensetzen der vielen Zeilen zu einem String übersehen.

                      Danke dir.

                      Gruß, Linuchs

        3. Aloha ;)

          Eine absolute URL zu verwenden hat natürlich auch was. Vor allem dann, wenn Du die Kundennummer des Empfängers als Query Parameter ans Bild hängst und dann in deinem Log auswertest, wer die Mail bekommen hat.

          Das (also der zweite Teil des Vorschlags) ist datenschutzrechtlich eine heiße Kiste. Wenn man das macht haben die Kunden hoffentlich zuvor eine Datenschutzerklärung unterschrieben und in die Auswertung dieser Daten (Abrufzeitpunkt von E-Mails) eingewilligt...

          Grüße,

          RIDER

          --
          Camping_RIDER a.k.a. Riders Flame a.k.a. Janosch Albers-Zoller
          # Twitter # Steam # YouTube # Self-Wiki # Selfcode: sh:) fo:) ch:| rl:) br:^ n4:? ie:% mo:| va:) js:) de:> zu:} fl:( ss:) ls:[
  2. @@Linuchs

    In der Mail ist /img/logo_remso.png natürlich nicht greifbar

    https://remso.eu/img/logo_remso.png ist es aber.

    und bei einmaliger Nutzung würde ich es so lösen:

    <img src=
    "data:image/png;base64,iVBORw0KGgo ... RU5ErkJ ggg==" />
    

    Es ist erschreckend, wie wenig du hier nach all der Zeit und all deinen gestellten Fragen bereit bist, das Nötige zu lernen.

    Bilder brauchen das alt-Attribut. Bei dekorativen Bildern: alt=""; sonst Alternativtext, der auch vom Kontext abhängt:

    <img src="https://remso.eu/img/logo_remso.png" alt="remso-Logo"/>
    

    aber

    <a href="/">
      <img src="https://remso.eu/img/logo_remso.png" alt="Startseite"/>
    </a>
    

    😷 LLAP

    --
    „Dann ist ja auch schrecklich, dass wir in einem Land leben, in dem nicht nur Bildungswillige leben, sondern auch hinreichende Zahlen von Bekloppten. Das darf ich so locker formulieren, ich bin ja jetzt Rentner und muss nicht mehr auf jedes Wort achten.“
    — Joachim Gauck über Impfgegner
  3. Wie kann ich das Logo in der Mail mehrfach zeigen?

    Dein Stichwort lautet CID/Content-ID. Das ist nicht nur aus diesem Grund wichtig. Direktes Base64 funktioniert in vielen E-Mail-Clients nicht. Dieser Artikel geht darauf ein:

    https://blog.flavia-it.de/bilder-in-e-mails/

    bitte um einen Link, wie ich zusätzlich text/plain in die Mail integriere.

    Kann ich für PHP nicht mit dienen. Aber einen Rat habe ich: versuche das auf keinen Fall selbst zu bauen, außer Du stehst auf Schmerzen.

    Es gibt bestimmt eine gute PHP-Bibliothek dafür.

    Nochmal: solltest Du Deine Mails bislang „from scratch“ selbst aufgebaut haben, ist jetzt der Zeitpunkt auf eine ausgewachsene Bibliothek zu setzen. PHPMailer sieht auf den ersten Blick interessant aus. Aber da sollten lieber PHP-kundige Tipps geben.

    1. Dein Stichwort lautet CID/Content-ID.

      Vielen Dank für den Link. Da es im Thunderbird funktioniert, wäre ich in die Falle getappt.

      Ich sende mir das Bild selbst per Thunderbird, dem Quellcode entnehme ich dann die base64 Angabe.

    2. Aloha ;)

      Es gibt bestimmt eine gute PHP-Bibliothek dafür.

      Wir (@Felix Riesterer und ich) verwenden PHPMailer und sind damit ganz zufrieden.

      Grüße,

      RIDER

      --
      Camping_RIDER a.k.a. Riders Flame a.k.a. Janosch Albers-Zoller
      # Twitter # Steam # YouTube # Self-Wiki # Selfcode: sh:) fo:) ch:| rl:) br:^ n4:? ie:% mo:| va:) js:) de:> zu:} fl:( ss:) ls:[
      1. Wir (@Felix Riesterer und ich) verwenden PHPMailer und sind damit ganz zufrieden.

        Na dann! @Linuchs

        https://github.com/PHPMailer/PHPMailer/wiki/Tutorial#inline-attachments

        dürfte es wohl sein. Oder - wie zu erwarten/befürchten - bau mal selbst nach. Viel Spaß ;-)

  4. Hi,

    ich möchte Mails im HTML-Format versenden *), ein eingebundenes Logo soll mehrmals im Text gezeigt werden. Auf meinen Webseiten habe ich sowas:

    .remso {
      background-image: url("/img/logo_remso.png");
      background-repeat: no-repeat;
      background-position: left bottom;
      background-size: 1.5em 1.5em; /* width height */
      font-family: sans-serif;
      letter-spacing: 0.1em;
      padding-left: 1.8em;
      color: #f00;
    }
    

    In der Mail ist /img/logo_remso.png natürlich nicht greifbar und bei einmaliger Nutzung würde ich es so lösen:

    <img src=
    "data:image/png;base64,iVBORw0KGgo ... RU5ErkJ ggg==" />
    

    Wie kann ich das Logo in der Mail mehrfach zeigen?

    Du musst den MIME-Type multipart/related bauen. Da liegt das Image dann einmal im Anhang und wird im HTML-Part einfach mehrfach referenziert.

    Sowas konnte man früher immer gut mit Outlook-Express üben und dann einfach nachbauen. Nicht alle Programme aus der guten alten Win95-Zeit waren schlecht ;-p

    Greetz
    Ralf

  5. Hello,

    ich möchte Mails im HTML-Format versenden *), ein eingebundenes Logo soll mehrmals im Text gezeigt werden. Auf meinen Webseiten habe ich sowas:

    .remso {
    

    background-image: url("/img/logo_remso.png");

    background-repeat: no-repeat; background-position: left bottom; background-size: 1.5em 1.5em; /* width height */ font-family: sans-serif; letter-spacing: 0.1em; padding-left: 1.8em; color: #f00; }

    Wie soll das funktionieren? Die angegebene URL ist relativ zu einer aktiven Domain. Welche Domain ist denn da aktiv (im verarbeitenden Client), wenn die eMail gelesen wird?

    Auch, wenn Du die URL nun absolut angeben würdest, würden dies die meisten aMail-Clients nicht mehr unterstüzen. Sie würden zumindest eine vorherige Warnung und Frage ausgeben, ob das Nachladen von externen Inhalten erlaubt wird.

    Alle für die Darstellung der eMail erforderichen Daten sollten daher eingebettet werden.

    Die Stichworte hierfür sind "MIME-Format", "multipart/related" und "CID/ContentID". Die hast Du schon bekommen von Ralf und MItleser2.0.

    Übrigens:
    Nicht nur als Hobbyist sollte man sowas durchaus mal selber bauen. Man benötigt dafür nur die passenden Tipps. Das ergibt dann die "Energie des Verstehens".

    Auf "Fertigsuppen" hinzuweisen, sollte dann hier immer nur Beiwerk sein und keinesfalls die Kernaussage!

    Glück Auf
    Tom vom Berg

    --
    Es gibt nichts Gutes, außer man tut es!
    Das Leben selbst ist der Sinn.
    1. Moin,

      Auf meinen Webseiten habe ich sowas:

      .remso {
        background-image: url("/img/logo_remso.png");
        background-repeat: no-repeat;
        background-position: left bottom;
        background-size: 1.5em 1.5em; /* width height */
        font-family: sans-serif;
        letter-spacing: 0.1em;
        padding-left: 1.8em;
        color: #f00;
      }
      

      Wie soll das funktionieren? Die angegebene URL ist relativ zu einer aktiven Domain.

      ja, Linuchs schreibt ja laut und deutlich oben drüber Auf meinen Webseiten, du hast das sogar noch mit zitiert. Dass das in einer e-Mail so nicht gehen kann, hat er ja selbst gleich eingesehen.

      Auch, wenn Du die URL nun absolut angeben würdest, würden dies die meisten aMail-Clients nicht mehr unterstüzen. Sie würden zumindest eine vorherige Warnung und Frage ausgeben, ob das Nachladen von externen Inhalten erlaubt wird.

      Darauf habe ich schon hingewiesen.

      Übrigens:
      Nicht nur als Hobbyist sollte man sowas durchaus mal selber bauen. Man benötigt dafür nur die passenden Tipps. Das ergibt dann die "Energie des Verstehens".

      Auf "Fertigsuppen" hinzuweisen, sollte dann hier immer nur Beiwerk sein und keinesfalls die Kernaussage!

      Dem kann ich mich nur anschließen. Das Beste ist aber meiner Ansicht nach ein guter Mittelweg. Man muss nicht alles selbst machen. Aber es schadet nicht, das Prinzip von Fremdcode, den man einsetzt, in etwa zu verstehen.

      May the Schwartz be with you
       Martin

      --
      Theorie ist, wenn eigentlich jeder weiß, wie's gehen müsste, und es geht doch nicht.
      Praxis ist, wenn's geht, obwohl es keiner so richtig versteht.
      Bei uns sind Theorie und Praxis vereint: Nichts geht, und keiner weiß, warum.
    2. Übrigens:
      Nicht nur als Hobbyist sollte man sowas durchaus mal selber bauen. Man benötigt dafür nur die passenden Tipps. Das ergibt dann die "Energie des Verstehens".

      Jeder, wie er mag. Ich persönlich sehe das (in dem Fall!) komplett anders - obwohl ich beruflich doch das ein oder andere Mal Kontakt mit dem Thema habe. Das Thema Multipart-Mail ist m.E. komplett dröge und gleichzeitig umfangreich. Da bin ich heilfroh, dass es fertige und robuste Bibliotheken gibt, die mir diese Fisselsarbeit abnehmen.

      Im Fall der Fälle schaue ich mir mal den von „Bibliothek X“ generierten Quelltext von Mails an, bzw. auch die Version, die dann letztlich beim Client ankommt. Mehr aber auch nicht.

      Auf "Fertigsuppen" hinzuweisen, sollte dann hier immer nur Beiwerk sein und keinesfalls die Kernaussage!

      Nein, eben nicht immer. Mit der Argumentation könntest Du z.B. auch auf die Frage „wie parse ich JSON?“ mit einem Algorithmus-Ansatz statt dem Hinweis auf die hierfür verfügbaren Module antworten.

      1. Hallo,

        Nicht nur als Hobbyist sollte man sowas durchaus mal selber bauen. Man benötigt dafür nur die passenden Tipps. Das ergibt dann die "Energie des Verstehens".

        Jeder, wie er mag. Ich persönlich sehe das (in dem Fall!) komplett anders - obwohl ich beruflich doch das ein oder andere Mal Kontakt mit dem Thema habe. Das Thema Multipart-Mail ist m.E. komplett dröge und gleichzeitig umfangreich.

        das empfinde ich komplett anders. Für mich ist das einerseits spannend, und andererseits, wenn man es dann mal verstanden hat, gleichzeitig so simpel.

        Da bin ich heilfroh, dass es fertige und robuste Bibliotheken gibt, die mir diese Fisselsarbeit abnehmen.

        Ich bin noch nie in die Verlegenheit gekommen, multipart-Mails erzeugen zu müssen. Aber wenn das mal auf mich zukommen sollte, würde ich es vermutlich "zu Fuß" machen. Das dürfte in diesem Fall schneller gehen, als sich erst in die Dokumentation einer Fremdkomponente einzulesen.

        Auf "Fertigsuppen" hinzuweisen, sollte dann hier immer nur Beiwerk sein und keinesfalls die Kernaussage!

        Nein, eben nicht immer.

        Vielleicht nicht immer, aber im Regelfall schon.

        Mit der Argumentation könntest Du z.B. auch auf die Frage „wie parse ich JSON?“ mit einem Algorithmus-Ansatz statt dem Hinweis auf die hierfür verfügbaren Module antworten.

        Aus der Sicht des Hilfesuchenden würde ich mir beides wünschen. Erst eine Übersicht, wie JSON "funktioniert" (das kann meinetwegen auch ein Verweis auf die Spec sein), und dann optional den Hinweis, dass es dafür schon fertige Lösungen gibt. Mit Link auf zwei oder drei populäre oder empfehlenswerte.

        May the Schwartz be with you
         Martin

        --
        Theorie ist, wenn eigentlich jeder weiß, wie's gehen müsste, und es geht doch nicht.
        Praxis ist, wenn's geht, obwohl es keiner so richtig versteht.
        Bei uns sind Theorie und Praxis vereint: Nichts geht, und keiner weiß, warum.
        1. Ich bin noch nie in die Verlegenheit gekommen, multipart-Mails erzeugen zu müssen.

          OK. Unter diesen Voraussetzungen ist:

          Aber wenn das mal auf mich zukommen sollte, würde ich es vermutlich "zu Fuß" machen. Das dürfte in diesem Fall schneller gehen, als sich erst in die Dokumentation einer Fremdkomponente einzulesen.

          eine äußerst interessante These.

          1. Hello,

            Ich bin noch nie in die Verlegenheit gekommen, multipart-Mails erzeugen zu müssen.

            OK. Unter diesen Voraussetzungen ist:

            Aber wenn das mal auf mich zukommen sollte, würde ich es vermutlich "zu Fuß" machen. Das dürfte in diesem Fall schneller gehen, als sich erst in die Dokumentation einer Fremdkomponente einzulesen.

            eine mehr als interessante These möchte ich meinen.

            Das hängt vom jeweiligen Background-Wissen ab, dass man sich doch hier eigentlich erwerben können sollte - neben den durchaus oft sinnvollen Tipps zu Fertiglösungen :-)

            Die Gestalter der jeweiligen Protokolle und der RFCs dazu kochen ihren Kaffee meistens auch nur mit Wasser.

            Wir sollten es vermeiden, vor dem Verständnis für Zusammenhänge Ängste zu schüren, sondern sollten Wege dazu aufzeigen.

            Glück Auf
            Tom vom Berg

            --
            Es gibt nichts Gutes, außer man tut es!
            Das Leben selbst ist der Sinn.
          2. Hallo,

            Ich bin noch nie in die Verlegenheit gekommen, multipart-Mails erzeugen zu müssen.

            OK. Unter diesen Voraussetzungen ist:

            Aber wenn das mal auf mich zukommen sollte, würde ich es vermutlich "zu Fuß" machen. Das dürfte in diesem Fall schneller gehen, als sich erst in die Dokumentation einer Fremdkomponente einzulesen.

            eine äußerst interessante These.

            nicht wahr? 😀 - Das hängt damit zusammen, dass mir die Theorie dazu bekannt und klar ist, einen Großteil der einschlägigen RFCs (angefangen bei 822) habe ich schon gelesen und weitgehend verstanden, und ich habe schon oft erhaltene Mails auf Quellcodeebene "reverse-engineered".

            Deshalb behaupte ich: Aus den Kopfdaten (Absender, Empfänger, Subject usw.), dem gewünschten Textinhalt und den zusätzlichen Medien, die angehängt oder eingebettet werden sollen, eine RFC-konforme multipart-Mail zu erzeugen, ist reine Fleißarbeit. Das Programm dazu dürfte in wenigen Stunden stehen. Testen und Debuggen käme dann natürlich noch dazu.

            [EDIT: Also sagen wir mal: Ein Schmuddelwetter-Wochenendprojekt.]

            May the Schwartz be with you
             Martin

            --
            Theorie ist, wenn eigentlich jeder weiß, wie's gehen müsste, und es geht doch nicht.
            Praxis ist, wenn's geht, obwohl es keiner so richtig versteht.
            Bei uns sind Theorie und Praxis vereint: Nichts geht, und keiner weiß, warum.
            1. Aloha ;)

              Deshalb behaupte ich: Aus den Kopfdaten (Absender, Empfänger, Subject usw.), dem gewünschten Textinhalt und den zusätzlichen Medien, die angehängt oder eingebettet werden sollen, eine RFC-konforme multipart-Mail zu erzeugen, ist reine Fleißarbeit. Das Programm dazu dürfte in wenigen Stunden stehen. Testen und Debuggen käme dann natürlich noch dazu.

              Wohl dem, der "einige Stunden oder mehr" für ein wenig Fleißarbeit übrig hat. In den meisten Fällen hat man™️ das wohl eher nicht, zumal die notwendige Zeit für Einarbeitung nicht der Rede wert ist - zumindest was PHPMailer angeht spreche ich da aus Erfahrung.

              Grüße,

              RIDER

              --
              Camping_RIDER a.k.a. Riders Flame a.k.a. Janosch Albers-Zoller
              # Twitter # Steam # YouTube # Self-Wiki # Selfcode: sh:) fo:) ch:| rl:) br:^ n4:? ie:% mo:| va:) js:) de:> zu:} fl:( ss:) ls:[
              1. Hallo Janosch,

                Deshalb behaupte ich: Aus den Kopfdaten (Absender, Empfänger, Subject usw.), dem gewünschten Textinhalt und den zusätzlichen Medien, die angehängt oder eingebettet werden sollen, eine RFC-konforme multipart-Mail zu erzeugen, ist reine Fleißarbeit. Das Programm dazu dürfte in wenigen Stunden stehen. Testen und Debuggen käme dann natürlich noch dazu.

                Wohl dem, der "einige Stunden oder mehr" für ein wenig Fleißarbeit übrig hat.

                sollte es eine dienstliche Aufgabe sein, hat man diese Zeit; wenn man es aus persönlichem Ehrgeiz oder als Hobby macht, dann auch.

                In den meisten Fällen hat man™️ das wohl eher nicht, zumal die notwendige Zeit für Einarbeitung nicht der Rede wert ist - zumindest was PHPMailer angeht spreche ich da aus Erfahrung.

                Ich habe noch nicht oft erlebt, dass man mit weniger als 2..3 Tagen RTFM auskommt, meist durch etwas Quellcode-Studium ergänzt, um eine von einer anderen Person geschriebene und (mehr oder weniger gut) dokumentierte Bibliothek zu verstehen.

                Kann natürlich sein, dass PHPMailer da eine rühmliche Ausnahme ist.

                May the Schwartz be with you
                 Martin

                --
                Theorie ist, wenn eigentlich jeder weiß, wie's gehen müsste, und es geht doch nicht.
                Praxis ist, wenn's geht, obwohl es keiner so richtig versteht.
                Bei uns sind Theorie und Praxis vereint: Nichts geht, und keiner weiß, warum.
                1. Aloha ;)

                  Deshalb behaupte ich: Aus den Kopfdaten (Absender, Empfänger, Subject usw.), dem gewünschten Textinhalt und den zusätzlichen Medien, die angehängt oder eingebettet werden sollen, eine RFC-konforme multipart-Mail zu erzeugen, ist reine Fleißarbeit. Das Programm dazu dürfte in wenigen Stunden stehen. Testen und Debuggen käme dann natürlich noch dazu.

                  Wohl dem, der "einige Stunden oder mehr" für ein wenig Fleißarbeit übrig hat.

                  sollte es eine dienstliche Aufgabe sein, hat man diese Zeit;

                  So pauschal stimmt das nicht - und dazu braucht man nicht mal in so seltsamen Strukturen beschäftigt sein wie ich. Auch jeder "normale" Arbeitgeber freut sich nicht sonderlich darüber, wenn die Arbeitnehmer beständig das Rad neu erfinden wenn ihre dienstliche Aufgabe der Bau von Autos ist.

                  Grüße,

                  RIDER

                  --
                  Camping_RIDER a.k.a. Riders Flame a.k.a. Janosch Albers-Zoller
                  # Twitter # Steam # YouTube # Self-Wiki # Selfcode: sh:) fo:) ch:| rl:) br:^ n4:? ie:% mo:| va:) js:) de:> zu:} fl:( ss:) ls:[
                  1. Hallo,

                    Wohl dem, der "einige Stunden oder mehr" für ein wenig Fleißarbeit übrig hat.

                    sollte es eine dienstliche Aufgabe sein, hat man diese Zeit;

                    So pauschal stimmt das nicht - und dazu braucht man nicht mal in so seltsamen Strukturen beschäftigt sein wie ich.

                    also mein Arbeitgeber freut sich in der Regel, wenn ich eine Alternative zum ursprünglichen Plan vorschlage, die schneller zum Ziel führt. Bei uns ist Zeit meistens eher der Flaschenhals als Geld.

                    Auch jeder "normale" Arbeitgeber freut sich nicht sonderlich darüber, wenn die Arbeitnehmer beständig das Rad neu erfinden wenn ihre dienstliche Aufgabe der Bau von Autos ist.

                    Wenn das Erfinden neuer Räder weniger Zeit braucht als das Suchen, Verstehen und Anpassen existierender Räder, dann vielleicht doch. Vielleicht legt der Kunde ja auch Wert auf Räder mit Herzchenprofil. Meine bevorzugte Herangehensweise ist deshalb:

                    • Ist DIY prinzipiell möglich (Kenntnisse, technische Voraussetzungen, Kundenforderungen)? Wenn ja, Aufwand dafür grob abschätzen.
                    • Ist der geschätzte Aufwand klein gegenüber dem Gesamt-Zeitbudget des Projekts? Wenn ja, machen!
                    • Recherche nach verfügbaren Lösungen, Auswählen von zwei, drei Favoriten, Anlesen der Doku, Abschätzen des Aufwands bei der Integration und Anpassung. Hier auch schon an Lizenzfragen denken! Bis hierher sind in der Regel schon mindestens 2..3 Tage vergangen, eher mehr.
                    • Endgültiges Auswählen der zu verwendenden Fertigsuppe im Projektteam, schließlich Implementierung.

                    So gehe ich auch im Job vor, wenn ich ein Wörtchen mitreden darf. Und zumindest bei den Teilaufgaben, die ich erledigen soll, darf ich das meistens.

                    May the Schwartz be with you
                     Martin

                    --
                    Theorie ist, wenn eigentlich jeder weiß, wie's gehen müsste, und es geht doch nicht.
                    Praxis ist, wenn's geht, obwohl es keiner so richtig versteht.
                    Bei uns sind Theorie und Praxis vereint: Nichts geht, und keiner weiß, warum.
                    1. Aloha ;)

                      Wohl dem, der "einige Stunden oder mehr" für ein wenig Fleißarbeit übrig hat.

                      sollte es eine dienstliche Aufgabe sein, hat man diese Zeit;

                      So pauschal stimmt das nicht - und dazu braucht man nicht mal in so seltsamen Strukturen beschäftigt sein wie ich.

                      also mein Arbeitgeber freut sich in der Regel, wenn ich eine Alternative zum ursprünglichen Plan vorschlage, die schneller zum Ziel führt. Bei uns ist Zeit meistens eher der Flaschenhals als Geld.

                      Ja eben - hier auch. Unser beider Argumente sind identisch, nur die Prämissen unterscheiden sich. Meine ist, dass das Verwenden eines fertigen Tools schneller geht als das selbst schreiben. Deine ist, dass das Verwenden eines fertigen Tools wegen notwendiger Einarbeitung zeitaufwändiger ist.

                      Beide Prämissen haben ihre Berechtigung - je nach dem, wie der konkrete Fall gelagert ist.

                      Wenn wir jetzt hier über ein Framework mit weitreichenden Auswirkungen für ein Gesamtprojekt sprechen bin ich unbedingt bei dir.

                      Im Fall von PHPMailer bin ich aber geneigt zu vermuten, dass meine Prämisse korrekt ist.

                      // Initialisierung
                      $mail = new \PHPMailer\PHPMailer\PHPMailer();
                      $mail->CharSet = 'UTF-8';
                      
                      // Versand via SMTP statt mail()
                      $mail->isSMTP();
                      $mail->Host = $host;
                      $mail->Port = $port;
                      $mail->SMTPAuth = true;
                      $mail->Username = $username;
                      $mail->Password = $password;
                      $mail->SMTPSecure = 'tls';
                      
                      // Kopfzeilen
                      $mail->setFrom('maier@example.org', 'Frau Maier');
                      $mail->addAddress('mueller@example.org', 'Herr Müller');
                      $mail->Subject = 'Betrifft irgendwas wichtiges'
                      
                      // Inhalt
                      $mail->isHtml(true);
                      $mail->AddEmbeddedImage('image.jpg', 'img');
                      $mail->Body = $html;
                      $mail->AltBody = $plaintext;
                      
                      // Versand und Weitergabe von Fehlern
                      if (!$mail->send()) {
                          throw new Exception($mail->ErrorInfo);
                      }
                      

                      Ich kann hier keinen RTFM-Moment erkennen. Bibliothek einbetten, Minimalbeispiel anpassen, Mailversand läuft. Ich kann mir nicht vorstellen, wie eine eigene Implementierung an der Stelle zeiteffizienter sein soll, zumal hier nicht nur der Zeit- und Kostenfaktor eine Rolle spielt, sondern auch und insbesondere die Robustheit der Lösung.

                      Wär ja schon dämlich, wenn meine selbstgebaute Bibliothek nicht jeden denkbaren Inhalt verkraftet und dann auf einmal versagt, wenn man damit was versenden will was vorher keiner auf dem Schirm hatte… Dann doch lieber eine Lösung von der Stange, die so weit verbreitet ist, dass Implementierungsfehler bereits irgendjemandem früher aufgefallen sind.

                      Grüße,

                      RIDER

                      --
                      Camping_RIDER a.k.a. Riders Flame a.k.a. Janosch Albers-Zoller
                      # Twitter # Steam # YouTube # Self-Wiki # Selfcode: sh:) fo:) ch:| rl:) br:^ n4:? ie:% mo:| va:) js:) de:> zu:} fl:( ss:) ls:[
                      1. Hallo,

                        Dann doch lieber eine Lösung von der Stange, die

                        ... auch bereits dokumentiert ist, was für ein Arbeiten im Team oder für das 6 Monate älter Ego ja auch wichtig ist.

                        Gruß
                        Kalk

                      2. Hallo,

                        also mein Arbeitgeber freut sich in der Regel, wenn ich eine Alternative zum ursprünglichen Plan vorschlage, die schneller zum Ziel führt. Bei uns ist Zeit meistens eher der Flaschenhals als Geld.

                        Ja eben - hier auch. Unser beider Argumente sind identisch, nur die Prämissen unterscheiden sich. Meine ist, dass das Verwenden eines fertigen Tools schneller geht als das selbst schreiben. Deine ist, dass das Verwenden eines fertigen Tools wegen notwendiger Einarbeitung zeitaufwändiger ist.

                        Beide Prämissen haben ihre Berechtigung - je nach dem, wie der konkrete Fall gelagert ist.

                        richtig, deshalb habe ich ja auch im vorhergehenden Posting den Entscheidungsprozess beschrieben, der beide Optionen betrachtet.

                        Wenn wir jetzt hier über ein Framework mit weitreichenden Auswirkungen für ein Gesamtprojekt sprechen bin ich unbedingt bei dir.

                        Im Fall von PHPMailer bin ich aber geneigt zu vermuten, dass meine Prämisse korrekt ist.

                        Auch die Möglichkeit hatte ich bereits eingeräumt, ohne PHPMailer selbst zu kennen.

                        Ich kann hier keinen RTFM-Moment erkennen. Bibliothek einbetten, Minimalbeispiel anpassen, Mailversand läuft. Ich kann mir nicht vorstellen, wie eine eigene Implementierung an der Stelle zeiteffizienter sein soll, zumal hier nicht nur der Zeit- und Kostenfaktor eine Rolle spielt, sondern auch und insbesondere die Robustheit der Lösung.

                        Was dieses Beispiel betrifft, hast du mich überzeugt. Ich war aber in Gedanken inzwischen viel allgemeiner unterwegs.

                        May the Schwartz be with you
                         Martin

                        --
                        Theorie ist, wenn eigentlich jeder weiß, wie's gehen müsste, und es geht doch nicht.
                        Praxis ist, wenn's geht, obwohl es keiner so richtig versteht.
                        Bei uns sind Theorie und Praxis vereint: Nichts geht, und keiner weiß, warum.
                        1. Was dieses Beispiel betrifft, hast du mich überzeugt. Ich war aber in Gedanken inzwischen viel allgemeiner unterwegs.

                          Toll. Kannst diesen Erkenntnisgewinn jetzt auch irgendwie begründen? Magic?

                          1. Hallo,

                            Was dieses Beispiel betrifft, hast du mich überzeugt. Ich war aber in Gedanken inzwischen viel allgemeiner unterwegs.

                            Toll. Kannst diesen Erkenntnisgewinn jetzt auch irgendwie begründen? Magic?

                            was soll ich noch begründen, wenn mir jemand ein quasi fertiges Codebeispiel zeigt und sagt: "It's that easy"?

                            Nur genügt mir das natürlich mittelfristig nicht. Früher oder später (erfahrungsgemäß eher früher) packt mich die Neugier und ich will wissen, was das Teil sonst noch so alles kann und wie es realisiert ist. Dann ist also ein Blick in die Doku und in den Quellcode doch noch unausweichlich.

                            Ebenso wie ich bei vielen Elektronik-Produkten auch erst Ruhe gebe, wenn ich sie mal von innen gesehen habe - unahbhängig davon, ob ich den inneren Aufbau dann verstehe oder nicht. Eine Fritzbox, die ich nicht mal aufgemacht und genau inspiziert habe, ist noch nicht "meine".

                            Ich war aber in Gedanken inzwischen viel allgemeiner unterwegs.

                            Meine Erfahrung ist, dass Software oft nur punktuell und anhand von ein paar Beispielen dokumentiert wird. Was meist fehlt, ist eine Beschreibung der Zusammenhänge: Wie wirken die Parameter zusammen, was hat wo wieder einen Einfluss, wo können unerwartete Nebenwirkungen auftreten, wenn ich an "Schraube" X drehe?
                            Das ist im FOSS-Bereich so, das ist aber auch bei den ganz Großen wie Microsoft oder SAP so.

                            Und weil dieser Überblick oft fehlt, steht man im Regen, wenn der eigene konkrete Anwendungsfall nicht von einem der Beispiele abgedeckt ist. Dann muss man doch wieder anfangen zu probieren, im Netz zu suchen oder zu reverse-engineeren.

                            Eine DIY-Lösung bedeutet beim ersten Bedarf vielleicht mehr Aufwand. Der reduziert sich aber später, wenn man die Komponente wiederverwendet und von Anfang an genau weiß, was sie kann und was nicht. Und wo man eventuell ansetzen muss, um bestimmte Features zu ergänzen.

                            May the Schwartz be with you
                             Martin

                            --
                            Theorie ist, wenn eigentlich jeder weiß, wie's gehen müsste, und es geht doch nicht.
                            Praxis ist, wenn's geht, obwohl es keiner so richtig versteht.
                            Bei uns sind Theorie und Praxis vereint: Nichts geht, und keiner weiß, warum.
                  2. So pauschal stimmt das nicht - und dazu braucht man nicht mal in so seltsamen Strukturen beschäftigt sein wie ich. Auch jeder "normale" Arbeitgeber freut sich nicht sonderlich darüber, wenn die Arbeitnehmer beständig das Rad neu erfinden wenn ihre dienstliche Aufgabe der Bau von Autos ist.

                    Exakt. Der Bau von Multipart-Mails ist dafür ein Paradebeispiel. Außer es kommt jemand um die Ecke und sagt „Hey, ich hab die RFC dazu überflogen. Fremdlibs sind Zeufelszeug!“.

                2. Hallo Martin,

                  sollte es eine dienstliche Aufgabe sein, hat man diese Zeit;

                  Kommt sehr auf den Dienst an.

                  Für's Selbermachen in vertretbarem Umfang gibt aber dennoch gute Gründe. Die Freigabe der Nutzung einer externen Library, vor allem aus dem FLOSS Bereich, ist darüber hinaus für viele Dienstgeber ein aufwändiger Genehmigungsprozess. Zu Recht. Es gibt genug verwaiste FLOSS Projekte; wenn man da etwas auswählt, das nach 2 Jahren keinen Betreuer mehr hat, so dass man es dann entweder selbst pflegen oder auf eine andere Lib migrieren muss, hat man ins warme Braune gepackt.

                  Und ich erinnere an die left-pad Katastrophe am 22.03.2016, wo der Autor alle seine Module aus NPN entfernt hat und sich herausstellte, dass es haufenweise Abhängigkeiten dazu gab, deren Builds dann zerbröselten.

                  Libs sind eine Chance, Zeit zu Sparen und Fremdknowhow zu nutzen
                  Libs sind das Risiko, sich den Launen eines Fremdentwicklers auszusetzen

                  Eine FLOSS-Lib, die ich im Zweifelsfall nicht selbst weiter pflegen kann, ist ein großes Risiko.

                  Ein Build-Prozess, der bei Depublikation einer Lib zerbröselt, ist unklug. Aber offenbar sind viele Projekte so gebaut, dass ihr Build sich die Abhängigkeiten immer vom Zentralrepository zieht.

                  Rolf

                  --
                  sumpsi - posui - obstruxi
                  1. Hallo Rolf,

                    sollte es eine dienstliche Aufgabe sein, hat man diese Zeit;

                    Kommt sehr auf den Dienst an.

                    das kann natürlich sein. Ich kann das nur aus meiner eigenen Erfahrung beurteilen. Ich war nie primär als Softwareentwickler angestellt (obwohl das mein Schwerpunktthema im Informatik-Studium war). Auch im jetzigen Job gilt stillschweigend: Für Software, die in unseren Produkten an Kunden geht, sind unsere hauptamtlichen Softwareenwickler zuständig. Für Software, die nur zum internen Gebrauch bestimmt ist, bin aber auch ich gut genug, so dass ich ab und zu auch solche Aufgaben bekomme.

                    Das läuft dann normalerweise so, dass ich mich zunächst mit ein paar Kollegen zusammensetze, die die Software später nutzen sollen, und wir definieren gemeinsam die Anforderungen. Dann versuche ich, den Aufwand in etwa abzuschätzen. Ergebnis ist dann eine Aussage wie etwa: "Drei Wochen bis zur ersten lauffähigen Testversion, mindestens weitere drei Wochen bis zur Reife."

                    Und dann sagt der Teamchef oder Abteilungsleiter entweder "Is' okay, machma", oder einer schreit, dass das viel zuviel ist, und man versucht, einen Kompromiss zu finden. Der besteht dann oft darin, dass wir bestimmte Anforderungen zurückstellen und auf eine spätere Erweiterung vertagen.

                    In jedem Fall bin aber ich (also der in diesem Fall amtierende SW-Entwickler) derjenige, der den Aufwand definiert, wobei ich natürlich immer eine gewisse Reserve einplane.

                    Für's Selbermachen in vertretbarem Umfang gibt aber dennoch gute Gründe. Die Freigabe der Nutzung einer externen Library, vor allem aus dem FLOSS Bereich, ist darüber hinaus für viele Dienstgeber ein aufwändiger Genehmigungsprozess. Zu Recht.

                    Ja. Nicht nur die Unwägbarkeit, ob das Projekt auch in einem Jahr noch betreut und gepflegt wird, auch die Frage, ob im konkreten eigenen Anwendungsfall vielleicht Nebenwirkungen oder Unfähigkeiten auftreten, ist wichtig.

                    Es gibt genug verwaiste FLOSS Projekte; wenn man da etwas auswählt, das nach 2 Jahren keinen Betreuer mehr hat, so dass man es dann entweder selbst pflegen oder auf eine andere Lib migrieren muss, hat man ins warme Braune gepackt.

                    Deswegen ist meine Devise in so einem Fall: Zunächst mal nutzen; mich mittelfristig aber so weit reinfuchsen, dass ich die Software verstehe und im Bedarfsfall auch selbst Bugs beheben oder Features nachrüsten kann.

                    Libs sind eine Chance, Zeit zu Sparen und Fremdknowhow zu nutzen
                    Libs sind das Risiko, sich den Launen eines Fremdentwicklers auszusetzen

                    Eine FLOSS-Lib, die ich im Zweifelsfall nicht selbst weiter pflegen kann, ist ein großes Risiko.

                    Ganz genau.

                    May the Schwartz be with you
                     Martin

                    --
                    Theorie ist, wenn eigentlich jeder weiß, wie's gehen müsste, und es geht doch nicht.
                    Praxis ist, wenn's geht, obwohl es keiner so richtig versteht.
                    Bei uns sind Theorie und Praxis vereint: Nichts geht, und keiner weiß, warum.
            2. nicht wahr? 😀 - Das hängt damit zusammen, dass mir die Theorie dazu bekannt und klar ist, einen Großteil der einschlägigen RFCs (angefangen bei 822) habe ich schon gelesen und weitgehend verstanden, und ich habe schon oft erhaltene Mails auf Quellcodeebene "reverse-engineered".

              Deshalb behaupte ich: Aus den Kopfdaten (Absender, Empfänger, Subject usw.), dem gewünschten Textinhalt und den zusätzlichen Medien, die angehängt oder eingebettet werden sollen, eine RFC-konforme multipart-Mail zu erzeugen, ist reine Fleißarbeit. Das Programm dazu dürfte in wenigen Stunden stehen. Testen und Debuggen käme dann natürlich noch dazu.

              [EDIT: Also sagen wir mal: Ein Schmuddelwetter-Wochenendprojekt.]

              Viel Spaß dabei. Berichte mal bitte retrospektiv Deinen Zeitaufwand dazu. Dann schauen wir gerne mal, inwiefern RTFM PHPMailer vs „Eigenbau“ letztendlich abgeschnitten hat.

              Gespannte Grüße.