Swift-5.0.3 Sonderzeichen in Mail Adresse

[Carmen]

Hallo,

um meine Mails zu versenden nutze ich Swift-5.0.3 leider hat mich gerade ein User angeschrieben und meinte es kommt keine Mail an. Hab es selber getestet und ja, es stimmt. Sobald in meiner Mail z.B. ein ä enthalten ist, erhalte ich eine Fehlermeldung

Fatal error: Uncaught exception 'Swift_RfcComplianceException' with message 'Address in mailbox given [XXXXXX] does not comply with RFC 2822, 3.6.2.' in /data/www/html/include/lib/Swift-5.0.3/lib/classes/Swift/Mime/Headers/MailboxHeader.php:352 Stack trace: #0 /data/www/html/include/lib/Swift-5.0.3/lib/classes/Swift/Mime/Headers/MailboxHeader.php(264): Swift_Mime_Headers_MailboxHeader->_assertValidAddress('info@getr?...') #1

Kennt Ihr dazu zufällig eine Lösung?

[Tabellenkalk]

Hallo,

Sobald in meiner Mail z.B. ein ä enthalten ist, erhalte ich eine Fehlermeldung

In der Mail oder in der Mailadresse?

Gruß
Kalk

[Carmen]

Hallo,

In der Mail oder in der Mailadresse?

wenn ein User eine Mail Adresse eingibt die ein Sonderzeichen enthält, in diesem Fall ein "ä" erhalte ich wenn ich die Fehlerausgabe aktiviere die zuvor genannte Fehlermeldung.

[Gunnar Bittersmann]

@@Carmen

wenn ein User eine Mail Adresse eingibt die ein Sonderzeichen enthält, in diesem Fall ein "ä" erhalte ich wenn ich die Fehlerausgabe aktiviere die zuvor genannte Fehlermeldung.

Dann behandelt dein Mailclient (Swift) das Sonderzeichen^[1] nicht richtig.

Wo tritt das ä denn auf? Vor oder nach dem @? Wenn zweites: wandle den Hostnamen in Punycode um.

LLAP 🖖

---

1. In diesem Fall stimmt die Bezeichnung „Sonderzeichen“ sogar. Im Kontext E-Mail-Adresse sind Nicht-ASCII-Zeichen Sonderzeichen und müssen entsprechen behandelt werden. In anderen Kontexten (bspw. HTML) sind sie es nicht. ↩︎

[Carmen]

Hallo,

Wo tritt das ä denn auf? Vor oder nach dem @? Wenn zweites: wandle den Hostnamen in Punycode um.

nach dem @ Zeichen. Die E-Mail beginnt mit info@getränke und beim ä tritt der Fehler auf. Muss ich schauen, wie ich dieses erreichen kann

Hostnamen in Punycode

[Auge]

Hallo

Sobald in meiner Mail z.B. ein ä enthalten ist, erhalte ich eine Fehlermeldung

Fatal error: Uncaught exception 'Swift_RfcComplianceException' with message 'Address in mailbox given [XXXXXX] does not comply with RFC 2822, 3.6.2.' in /data/www/html/include/lib/Swift-5.0.3/lib/classes/Swift/Mime/Headers/MailboxHeader.php:352 Stack trace: #0 /data/www/html/include/lib/Swift-5.0.3/lib/classes/Swift/Mime/Headers/MailboxHeader.php(264): Swift_Mime_Headers_MailboxHeader->_assertValidAddress('info@getr?...') #1

Verbirgt sich das „Ä“ hinter dem Fragezeichen in „info@getr?“? Domainnamen mit anderen Zeichen als ASCII, also auch die sogenannten Umlautdomains, müssen mit Punycode maskiert werden. Wie das mit Swift geht, erfragst du am Besten beim Hersteller/Projekt.

Tschö, Auge

[Carmen]

Hallo,

Verbirgt sich das „Ä“ hinter dem Fragezeichen in „info@getr?“? Domainnamen mit anderen Zeichen als ASCII, also auch die sogenannten Umlautdomains, müssen mit Punycode maskiert werden. Wie das mit Swift geht, erfragst du am Besten beim Hersteller/Projekt.

ja, das "ä" sollte anstelle des Fragezeichens stehen. Dann muss ich mal schauen, wie ich dieses beim swiftmailer aktivieren kann. Oder ich muss irgendwie auf meiner Seite prüfen ob in der Mail ein ä vorkommt und dieses dann von Hand umschreiben?

[Carmen]

Hallo,

oder würde es funktionieren wenn ich aus dem "ä" in der Datenbank ein "xn--4caaaa" mache?

[Gunnar Bittersmann]

@@Carmen

oder würde es funktionieren wenn ich aus dem "ä" in der Datenbank ein "xn--4caaaa" mache?

Nein, so funktioniert Punycode nicht.

LLAP 🖖

[Auge]

Hallo

oder würde es funktionieren wenn ich aus dem "ä" in der Datenbank ein "xn--4caaaa" mache?

Wenn das der Punycode für „ä“ sein sollte, ja. Das ist ja, was ich anmerkte. Zumal der auf diese Art korrigierte Eintrag, also die Umschreibung von Nicht-ASCII-Zeichen schon beim Eintrag der Emailadresse, wohl der einzuschlagende Weg ist. Du könntest auch den Originaleintrag in die Datenbank kippen und bei der Benutzung der Emailadresse das „ä“ (oder welches andere Zeichen auch immer) durch den passenden Punycode ersetzen. Das machst du dann aber nicht einmal (beim Eintrag) sondern immer wieder.

Tschö, Auge

[Gunnar Bittersmann]

@@Auge

oder würde es funktionieren wenn ich aus dem "ä" in der Datenbank ein "xn--4caaaa" mache?

Wenn das der Punycode für „ä“ sein sollte, ja.

Nein! Es gibt keinen „Punycode für ‚ä‘“.

LLAP 🖖

[Auge]

Hallo

Verbirgt sich das „Ä“ hinter dem Fragezeichen in „info@getr?“? Domainnamen mit anderen Zeichen als ASCII, also auch die sogenannten Umlautdomains, müssen mit Punycode maskiert werden. Wie das mit Swift geht, erfragst du am Besten beim Hersteller/Projekt.

ja, das "ä" sollte anstelle des Fragezeichens stehen. Dann muss ich mal schauen, wie ich dieses beim swiftmailer aktivieren kann.

Deren Doku. Wenn sie, wie auf dem Github-Repo zu lesen ist, das erst vor kurzem veröffentlichte PHP7 unterstützen, sollte Punycode, das schon ein paar Jahre im Einsatz ist, erst recht unterstützt werden.

Oder ich muss irgendwie auf meiner Seite prüfen ob in der Mail ein ä vorkommt und dieses dann von Hand umschreiben?

Nein. Die veränderte Emailadresse ist nicht mehr die, die angegeben wurde und wohl auch erreichbar sein soll. Was nutzt dir also die Umgehung eines Fehlers (statt dessen Behebung), wenn du mit der veränderten, also anderen Emailadresse nicht deine Mitglieder/Kunden/WasAuchImmer erreichen kannst?

Tschö, Auge

[Gunnar Bittersmann]

@@Carmen

Oder ich muss irgendwie auf meiner Seite prüfen ob in der Mail ein ä vorkommt und dieses dann von Hand umschreiben?

Entweder das für jede auftretende Umlautdomain oder du automatisierst das. Die Suche nach „PHP Punycode“ liefert sowohl Online-Converter als auch PHP-Bibliotheken.

LLAP 🖖

[Carmen]

Hallo,

Entweder das für jede auftretende Umlautdomain oder du automatisierst das. Die Suche nach „PHP Punycode“ liefert sowohl Online-Converter als auch PHP-Bibliotheken.

von Hand wäre auf die schnelle geholfen aber wer weiß was alles so kommt :) Ich habe dieses gefunden: http://php.net/manual/de/function.idn-to-ascii.php

Die Mail Adresse würde dann so in meiner Datenbank stehen?

info@xn--getrnke-8wa

Richtig?

[Der Martin]

Hi,

Die Mail Adresse würde dann so in meiner Datenbank stehen?

info@xn--getrnke-8wa

Richtig?

nein, eher nicht. Ich würde sie in der DB im Klartext stehenlassen und die Umwandlung erst da vornehmen, wo die Mailnachricht erzeugt und verschickt wird.

So long,
 Martin

[Carmen]

Hallo,

nein, eher nicht. Ich würde sie in der DB im Klartext stehenlassen und die Umwandlung erst da vornehmen, wo die Mailnachricht erzeugt und verschickt wird.

das wäre mir auch am liebsten.

Die Mail bereite ich so vor:

$data['to']  = array('name' => $user_titel ." ".$user_name, 'email' => $user_email);

Das heißt, ich müsste diese Mail Adresse vorher umwandeln also so?

$MailUser = idn_to_ascii('$user_email'); 
$data['to']  = array('name' => $user_titel ." ".$user_name, 'email' => $MailUser);

Wenn ich dieses teste, erhalte ich folgende Meldung:

[Mon Jun 13 12:22:10 2016] [error] [client xx.xx.x.xxx] PHP Fatal error: Call to undefined function idn_to_ascii()

Ich habe die PHP Version 5.3.3 am laufen. Und laut http://php.net/manual/de/function.idn-to-ascii.php sollte die Funktion ab (PHP 5 >= 5.3.0 zur Verfügung stehen?

[Auge]

Hallo

Wenn ich dieses teste, erhalte ich folgende Meldung:

[Mon Jun 13 12:22:10 2016] [error] [client xx.xx.x.xxx] PHP Fatal error: Call to undefined function idn_to_ascii()

Ich habe die PHP Version 5.3.3 am laufen. Und laut http://php.net/manual/de/function.idn-to-ascii.php sollte die Funktion ab (PHP 5 >= 5.3.0 zur Verfügung stehen?

Der erste Eintrag in den Benutzerkommentaren sagt, dass die Funktion(en) bis einschließlich PHP 5.3 als Erweiterung installierbar ist. Das heißt im Umkehrschluss, dass sie nicht installiert sein muss. Das scheint bei dir der Fall zu sein. Ab Verion 5.4 gehören die Funktionen zum Standardumfang von PHP. Da PHP 5.3 seine letzte Aktualisierung im August 2014 erhalten hat, ist ein Update, mindestens auf PHP 5.6, besser auf PHP 7, eh zu empfehlen.

Tschö, Auge

[Carmen]

Hallo,

Der erste Eintrag in den Benutzerkommentaren sagt, dass die Funktion(en) bis einschließlich PHP 5.3 als Erweiterung installierbar ist. Das heißt im Umkehrschluss, dass sie nicht installiert sein muss. Das scheint bei dir der Fall zu sein. Ab Verion 5.4 gehören die Funktionen zum Standardumfang von PHP. Da PHP 5.3 seine letzte Aktualisierung im August 2014 erhalten hat, ist ein Update, mindestens auf PHP 5.6, besser auf PHP 7, eh zu empfehlen.

ich kann zwar in meinem Kundenmenü die PHP Version ändern nur ich weiß nicht ob dann noch sämtliche Scripte laufen.

Mein Provider braucht immer Tage bis etwas geklärt ist, dann bleibt mir wohl nichts anderes übrig als die Mail Adressen von Hand zu ändern.

[Carmen]

Hallo,

das umwandeln ging leider nach hinten los :/

ilUser = idn_to_ascii('$user_email'); 
$data['to']  = array('name' => $user_titel ." ".$user_name, 'email' => $MailUser);

raus kommt so etwas:

[e-mail]

[Der Martin]

Hi,

das umwandeln ging leider nach hinten los :/

wie stellst du ds fest?

ilUser = idn_to_ascii('$user_email'); 
$data['to']  = array('name' => $user_titel ." ".$user_name, 'email' => $MailUser);

raus kommt so etwas:

[e-mail]

Sieht doch auf den ersten Blick plausibel aus. Aber hast du auch den wichtigen Hinweis im Manual beachtet, dass der String, der an idn_to_ascii() übergeben wird, in UTF-8 codiert sein muss? Ist vielleicht eine andere Codierung bei dir im Spiel?

So long,
 Martin

[Carmen]

Hallo,

das umwandeln ging leider nach hinten los :/ wie stellst du ds fest?

hab eine Mail mit dem Betreff "Undelivered Mail Returned to Sender" erhalten. Da stand dieses drin.

Sieht doch auf den ersten Blick plausibel aus. Aber hast du auch den wichtigen Hinweis im Manual beachtet, dass der String, der an idn_to_ascii() übergeben wird, in UTF-8 codiert sein muss? Ist vielleicht eine andere Codierung bei dir im Spiel?

eigentlich ja, ich verwende

<meta charset="utf-8">

und im Script

$data['charset']        = 'utf-8';

@Auge hat mir hier: https://forum.selfhtml.org/self/2016/jun/13/swift-5-punkt-0-3-sonderzeichen-in-mail-adresse/1669204#m1669204 schon weitergeholfen :)

[Der Martin]

Hi,

das umwandeln ging leider nach hinten los :/ wie stellst du ds fest? hab eine Mail mit dem Betreff "Undelivered Mail Returned to Sender" erhalten. Da stand dieses drin.

ja, okay. Inzwischen ist mir das auch klar geworden.

Aber hast du auch den wichtigen Hinweis im Manual beachtet, dass der String, der an idn_to_ascii() übergeben wird, in UTF-8 codiert sein muss? Ist vielleicht eine andere Codierung bei dir im Spiel?

eigentlich ja, ich verwende

<meta charset="utf-8">

und im Script

$data['charset']        = 'utf-8';

Auch wenn von der Codierung her vermutlich alles in Ordnung ist: Das ist es nicht, wonach ich gefragt hatte. Wichtig ist nicht, dass auf dem Etikett "Spreewaldgurken" draufsteht; wichtig ist, dass im Glas auch wirklich Spreewaldgurken drin sind.
Was du hier eben gezeigt hast, sind ja quasi nur die Etiketten, auf denen draufsteht, wie der Inhalt angeblich codiert ist. Das muss dann aber auch mit dem Inhalt übereinstimmen. Das scheint bei dir aber zu passen, sonst hättest du noch ganz Effekte wie etwa verstümmelte Umlaute im Text.

So long,
 Martin

[Auge]

Hallo

das umwandeln ging leider nach hinten los :/

[e-mail]

Ja, sieht man. :-)

Die Kodierung mit Punycode ist nur auf den Domainteil anzuwenden. Das heißt, dass du die Emailadresse auseinandernehmen, den Teil nach dem „@“ kodieren und das Ergebnis wieder zusammensetzen musst.

$temp_email = explode('@', $user_email); // Adresse auseinandernehmen
$temp_email[1] = idn_to_ascii($temp_email[1]); // Domainteil der Adresse kodieren
$puny_email = join('@', $temp_email); // Adresse zusammenfrickeln
echo '<pre>' . print_r($puny_email, true) . '</pre>'; // Testausgabe

Das xn-- als Markierung für eine vorhandene Kodierung sollte jetzt hinter dem „@“ stehen.

Tschö, Auge

[Der Martin]

Hi,

das umwandeln ging leider nach hinten los :/

[e-mail]

Ja, sieht man. :-)

Die Kodierung mit Punycode ist nur auf den Domainteil anzuwenden.

guter Punkt, ja. Das ist mir tatsächlich nicht aufgefallen.

Ciao,
 Martin

[Carmen]

Hallo,

Ja, sieht man. :-)

ich finde solche Situationen nicht lustig :)

Die Kodierung mit Punycode ist nur auf den Domainteil anzuwenden. Das heißt, dass du die Emailadresse auseinandernehmen, den Teil nach dem „@“ kodieren und das Ergebnis wieder zusammensetzen musst.

$temp_email = explode('@', $user_email); // Adresse auseinandernehmen
$temp_email[1] = idn_to_ascii($temp_email[1]); // Domainteil der Adresse kodieren
$puny_email = join('@', $temp_email); // Adresse zusammenfrickeln
echo '<pre>' . print_r($puny_email, true) . '</pre>'; // Testausgabe

Das xn-- als Markierung für eine vorhandene Kodierung sollte jetzt hinter dem „@“ stehen.

vielen vielen Dank für deine Hilfe. Jetzt stimmt auch die E-Mail Adresse. Hab es mit Outlook abgeglichen. Microsoft wandelt scheinbar die Mail Adressen intern auch um, sieht man wenn man eine Mail Adresse bearbeiten möchte.

[Der Martin]

Hi,

Ja, sieht man. :-)

ich finde solche Situationen nicht lustig :)

ich schon, solange man andere nicht im Regen stehen lässt. Einmal kurz drüber lachen und dann erklären, was falsch ist und wie's besser geht, finde ich schon okay. Und Humor ist, wenn man auch über sich selbst lachen kann.

Merke: Etwas lustig finden ist nicht dasselbe wie sich über etwas lustig machen.

Good luck,
 Martin

[Carmen]

Hallo,

$temp_email = explode('@', $user_email); // Adresse auseinandernehmen
$temp_email[1] = idn_to_ascii($temp_email[1]); // Domainteil der Adresse kodieren
$puny_email = join('@', $temp_email); // Adresse zusammenfrickeln
echo '<pre>' . print_r($puny_email, true) . '</pre>'; // Testausgabe

ich habe noch eine Frage zu deiner Ausgabe also dieser Zeile:

 echo '<pre>' . print_r($puny_email, true) . '</pre>'; // Testausgabe

Was bedeutet das "true"?

Wenn ich nur dieses ausgebe

echo $puny_email;

erhalte ich in meinem Beispiel genau das gleiche. Oder ist dieses nur Zufall?

[Julius]

Hallo Carmen,

echo '<pre>' . print_r($puny_email, true) . '</pre>'; // Testausgabe

Was bedeutet das "true"?

Dass print_r das Ergebnis zurückgibt statt es direkt auszugeben. Steht auch so in der Doku.

Gruß
Julius

[Auge]

Hallo

Julius hat ja schon die Doku dieser Funktion verlinkt, dennoch möchte ich etwas hinterherschieben.

 echo '<pre>' . print_r($puny_email, true) . '</pre>'; // Testausgabe

Was bedeutet das "true"?

Das true sorgt dafür, dass die Funktion nicht sofort eine Ausgabe erzeugt. In genau dem obigen Beispiel erfolgt die Ausgabe direkt im Anschluss der Ausführung von print_r. Die Ausgabe von print_r wird unmittelbar in die Zeichenkette eingefügt und diese mit echo ausgegeben. Ohne true für print_r bräuchte man nicht einmal echo, da print dann die (dann nackte) Ausgabe instantan sebst erzeugt.

Ich schreibe die Ausgaben von Skripten aber gerne in Variablen, die ich erst später gesammelt ausgebe. Da print_r ohne die explizite Angabe des zweiten Parameters mit true die Ausgabe, wie eben angemerkt, sofort erzeugt, würde mir das um die Ohren fliegen.

$temperatur = getTemerature();
$zwischenergebnisT = print_r($temperatur); // <==
$datum = strftime("%d.%m.%Y");
$uhrzeit = strftime("%H:%M");

Mit dem obigen Code, dessen Variablen in ein HTML-Template wie dieses:

<!DOCTYPE html>
<html lang="de">
 <head>
  <meta charset="utf-8">
  <title>Konstruktion eines Zifferfonts</title>
 </head>
 <body>
  <header>
   <h1>Konstruktion eines Zifferfonts</h1>
  </header>
  <main>
   <section>
    <h2>Ein- und Ausgabe</h2>
    <dl>
     <dt>Temperatur (Testausgabe)</dt>
     <dd><?php echo htmlspecialchars($zwischenergebnisT); ?></dd>
     <dt>Temperatur</dt>
     <dd><?php echo htmlspecialchars($temperatur); ?></dd>
     <dt>Datum</dt>
     <dd><?php echo htmlspecialchars($datum); ?></dd>
     <dt>Uhrzeit</dt>
     <dd><?php echo htmlspecialchars($uhrzeit); ?></dd>
    </dl>
   </section>
  </main>
 </body>
</html>

… eingefügt werden, würde die Ausgabe von print_r im HTML-Quelltext vor dem ersten HTML-Element stehen, da die Ausgabe sofort erfolgt. Der Wert der Variable $zwischenergebnisT lautete true für die erfolgreiche Ausführung der Funktion, was zu einer Ausgabe von 1 als Entsprechung von true per echo $zwischenergebnisT; führen würde.

Dieser Code:

$temperatur = getTemerature();
$zwischenergebnisT = print_r($temperatur, true); // <==
$datum = strftime("%d.%m.%Y");
$uhrzeit = strftime("%H:%M");

… speichert die Ausgabe hingegen in der Variable $zwischenergebnisT, die ihren Wert mit echo $zwischenergebnisT; an der gewünschten Stelle im Template hergibt.

Wenn ich nur dieses ausgebe

echo $puny_email;

erhalte ich in meinem Beispiel genau das gleiche. Oder ist dieses nur Zufall?

Ja und nein. In diesem Beispiel ist die Ausgabe, wenn kein Fehler aufgetreten ist, identisch. In beiden Fällen wird ein String, nämlich der mit der Emailadresse, ausgegeben. Wäre $puny_email ein Array, bekämst du mit echo $puny_email; aber nur das Wort „Array“ zu sehen. Mit echo print_r($puny_email, true); werden dir die Elemente des Arrays in der ganzen Schönheit dessen Struktur angezeigt ^[1].

Manchmal reichen die Infos, die print_r hergibt, nicht. Dann ist var_dump zu bevorzugen. In vielen Fällen reicht die Ausgabe von print_r zur Analyse aber aus.

Tschö, Auge

---

1. Wie im Beispiel #1 auf der von Julius verlinkten Doku-Seite zur Funktion. ↩︎

[dedlfix]

Tach!

Was du da betreibst, ist ein ziemlicher Aufwand nur für eine temporäre Testausgabe. Es kommt dabei nur darauf an, dass man den Wert sieht. Jede Schönheitskur ist unnötiger Aufwand. Kann man machen, bringt aber keinen Gewinn. Irgendwo ein <pre> in den HTML-Teil setzen - selbst ein </pre> kann man sich sparen, weil es beim Testen nur auf den Wert ankommt und der Rest der Seite üblicherweise in dem Augenblick keine Rolle spielt - und ein var_dump($delinquent); einfügen. Fertig. Fliegt doch eh gleich wieder raus, wenn man den Fehler gefunden hat.

dedlfix.

[Auge]

Hallo

Was du da betreibst, ist ein ziemlicher Aufwand nur für eine temporäre Testausgabe. Es kommt dabei nur darauf an, dass man den Wert sieht. Jede Schönheitskur ist unnötiger Aufwand. Kann man machen, bringt aber keinen Gewinn.

Natürlich ist das für eine temporäre Ausgabe ein recht großer Aufwand. Den muss man natürlich nicht treiben. Ich empfinde die Ausgabe mit dicktengleicher Schrift, wie sie mit <pre> über das Standardstylesheet der Browser autoatisch generiert wird, als sehr angenehm und übersichtlich und auf diese Art am einfachsten herzustellen. Zudem geht mir diese aufwendige Notation fast automatisch von der Hand. Von daher ist der zusätzliche Aufwand für mich so gut wie nicht da.

Tschö, Auge

[Gunnar Bittersmann]

@@Carmen

Die Mail Adresse würde dann so in meiner Datenbank stehen?

info@xn--getrnke-8wa

Richtig?

Njein. Ich der Datenbank willst du vielleicht doch lieber die lesbare Adresse mit dem ä haben.

Behandlung von Sonderzeichen sollten immer genau dann erfolgen, wenn sie in den Kontext gebracht werden, wo sie behandelt werden müssen. Nicht vorher.

In dem Fall würde die Umwandlung der Adresse sinnvollerweise dann erfolgen, wenn die Mailadresse in den Kontext To-Feld im Mailheader gebracht wird.

Wenn dein Mailclient an der Stelle kein Eingreifen erlaubt, wäre die vorherige Umwandlung eine Lösung. Aber eben nur die zweitbeste.

LLAP 🖖

[Gunnar Bittersmann]

@@Gunnar Bittersmann

In dem Fall würde die Umwandlung der Adresse sinnvollerweise dann erfolgen, wenn die Mailadresse in den Kontext To-Feld im Mailheader gebracht wird.

Wenn dein Mailclient an der Stelle kein Eingreifen erlaubt,

Moment, wie kommt die Adresse aus der Datenbank in die Mail? Holt sich der Swift die selber oder hast du ein Script, das die Adresse aus der DB holt und an Swift weiterreicht? Im zweiten Fall hast du ja die Stelle, wo du eingreifen und die Umwandlung zum richtigen Zeitpunkt machen kannst.

LLAP 🖖

[Auge]

Hallo

… Ich habe dieses gefunden: http://php.net/manual/de/function.idn-to-ascii.php

Als Ergänzung zu den vorhergehenden Antworten: Ob du die Kodierung beim speichern oder bei der Benutzung des Werts vornimmst, kommt auf deine Eingriffsmöglichkeiten in die benutzten Programme und die Häufigkeit des Einsatzes der Funktion an.

Kannst du, wie Gunnar sagte, die Funktion nicht beim Versand durch Swiftmailer benutzen, ist den Kodierung vor dem speichern der Adresse der bessere Weg. Dann kodierst du die Adresse auch nur ein Mal, statt jedes Mal, wenn du eine Email an den Adessaten versendest.

Andererseits ist Martins Argument, die Kodierung erst dann, wenn sie benötigt wird, anzusetzen, nicht von der Hand zu weisen. Wenn der Anwender mit einer solchen Adresse Korrekturen an seinen Benutzerdaten vornehmen will, wird er im Allgemeinen mit der kodierten Emailadresse nichts anfangen können und dies für einen Fehler halten.

Als Möglichkeit bietet sich an, die Emailadresse einmal im Klartext und einmal kodiert abzuspeichern. Die Klartextversion wird zur Anzeige (z.B. im Profil oder in den Benutzereinstellungen) verwendet, die kodierte Version zum Versand von Emails. Du musst als Anbieter dann natürlich dafür Sorge tragen, dass Änderungen an der Klartextversion der Emailadresse sich auch in der Spalte für die kodierte Version widerspiegeln.

Tschö, Auge