Email-Antworten archivieren mit dynamischen Adressen für reply to

du brauchst dazu einen Mailserver auf dieser Machine.
Das dürfte meistens der Fall sein.

Dann wirst du ein eigenes Modul mit dieser Funktionalität schreiben müssen, das über die Mail-API solche Dinge erledigt.

Wie gut bist du selbst bei der Programmierung von PHP?

Schau dir im PHP-Manual die Mailboxfunktionen an.
Damit ist das realisierbar.

Ich bin kein Profi, aber hab schon einiges mit Drupal programmiert. Hier fehlt mir aber etwas die Vorlage. Ich hab das folgende Modul mal etwas angeschaut:

https://www.drupal.org/project/bounce

Das Modul macht soweit ich das seh etwas ähnliches...ich würde allerdings keine Bounces handlen sondern antworten. Das heisst wenn ich eine Mail-Adresse mit responses@meine-domain.com anlege und alle X Minuten eine Verbindung zum Mail-Server aufbauen lasse um dann die Inbox auszulesen, sollte das funktionieren?

Vorab vielen Dank

Da die Ursprungsmail nicht neu geformt werden muss, kann man sie (mehr oder weniger) an eine andere Adresse weiterleiten.

Dies erfordert einen cornjob, der regelmäßig die Eingänge überprüft, und die Mails nach einer Übersetzungstabelle weiterreicht.

Dieser Vorgang selbst muss nicht zwangsläufig in Drupal laufen, aber auf Records von Drupal zugreifen.

Dadurch, dass der eigentliche Prozess keinerlei Oberfläche benötigt, kann er komplett geschützt und außerhalb laufen, und benötigt keinen Drupal-Bootstrap.

In Drupal würde ich ein Modul anlegen, das entweder bei der Neuanlage eines Users mit einer entsprechenden Rolle automatisch eine Mailbox anlegt, oder ein gesondertes Feld für die Pflege durch den Administrator erlaubt.

Da als Absender immer das Drupalsystem steht, gibt es auch keine Probleme mit dem Hostingssystem und seinen Spamschutzsystemen.

Theoretisch kann diese Funktionalität auch komplett an einen anderen Host/Service ausgelagert werden.

Der Bearbeitungsprozess muss nur sauber mit Timestamps arbeiten, um keine Mails zu vergessen, aber auch keine doppelt zu versenden.

Ich hab das zwar selbst noch nicht benutzt, aber der Modul-Beschreibung nach klingt das für mich nach der gewünschten Funktion:
https://www.drupal.org/project/mailcomment

Ergänzung:
Mit "gewünschter Funktion" meine ich die Möglichkeit per Mail auf Beiträge antworten zu können. Auch wenn es evtl. nicht direkt über dynamische Mail-Adressen sondern über den Mail-Content funktioniert.
Dynamische Mail-Adressen würden am einfachsten mit einem Catch-All funktionieren und damit schwer bezüglich SPAM im Zaum zu halten sein. Bezüglich des Contents z.B. über IDs in Betreff-Zeilen oder ähnliches funktionieren anscheinend viele Tracking/Support-Systeme, wie ich es als Kunde bei diversen IT-Firmen bisher mitbekommen habe. Ich selbst verfolge diesen Ansatz nicht mehr aus eigenen Antrieb (d.h. für meine eigenen Tracker), da das Mail-System eben aufgrund SPAM und anderen Problemen mir zu instabil geworden ist. Da bleibe ich dann lieber bei der reinen Benachrichtigungs-Funktion für Mails und wenn es wichtig ist vllt. per SMS und belasse die eigentliche Kommunikation nach Möglichkeit allein in der Webanwendung.

würde ich die Umsetzung der Mails aus Drupal heraus halten.

Wenn dies eine externe Anwendung aufgrund von Übersetzungstabellen durchführt, kann SPAM entsprechend behandelt werden, ohne dass das Drupalsystem einbezogen ist.

Durch entsprechende Umsetzung in einem Schnittstellenmodul werden nur gültige Nachrichten nach Drupal gesendet.

Allerdings steckt ein bisschen mehr Arbeit darin.

Ich würde auch keinen "catch all" anlegen, auch wenn dies bequemer wäre, sondern echte Postfächer.
Existiert ein Postfach nicht, geht die Nachricht ins' Leere, wodurch ein Austesten durch Spamming erschwert wird.

Die genannten Module klingen genau nach dem was ich gesucht habe. Vielen Dank dafür! Aber deinen Bedenken nach zu urteilen scheint dies nicht der empfehlenswerte Weg zu sein

Mit Schnittstellenmodul meinst du dabei aber kein Modul innerhalb einer Drupal-Installation?

Angenommen ich würde mit einem eigenen Modul in Drupal in den Footer-Bereich meiner ausgehenden Mail einen Schlüssel in Form eines random-generierten Strings hinterlegen, der bspw. 2 Wochen gültig ist und an eine Email-Adresse gekoppelt ist. Also "yzasdbdsöasdass234adsbsaks73ns" zu Email "meine-mail@domain.de". Kommt nun eine Antwort in meinen Mailserver mit diesem String im Footer von der angegeben Mail-Adresse, so könnte man diese Mail dahingehend entsprechend identifizieren.

Ein Spamming, indem dieser String mehrfach benutzt wird, könnte man dahingehend vermeiden oder übersehe ich etwas?

Ich persönlich halte das Mail-System als ganzes im Moment für problematisch. Wenn mich aber ein Kunde beauftragen sollte, Drupal mit Mail-Empfang auszustatten würde ich mich zuerst an den genannten Modulen orientieren bzw. etwas ähnliches umsetzen.

In jedem Fall braucht mal ein Mail-Server, der irgendwie mit Drupal kommuniziert in empfangener Richtung. Das ist ja auf jeden Fall eine externe Lösung. Die Drupal-IDs z.B. der Nodes und Kommentare in die Mail-Adresse zu holen wie im Eröffnungspost angedacht wäre dann kompliziert, wenn man kein Catch-All benutzen würde. Meine Bedenken zu Spam diesbezüglich wäre der SPAM, der auf dieser Catch-All-Adresse rein kommen würde und das eigene System belasten würde. Dies Problem können man mit einer kompletten Fernsteuerung des Mail-Servers umgehen, der wirkliche Mail-Adresse anlegt. Das wäre aber wirklich aufwendig. Deshalb würde ich einen Weg bevorzugen, der die IDs irgendwie in Mail hinein bekommt, wie es wie schon erwähnt bei vielen Mail-basierten Tracking-Systemen üblich ist. Die besagten Module lesen in einem Mail-Postfach und weisen automatisiert verarbeiten die IDs innerhalb der Mails.
Auf der anderen Seite steht der Mail-Versand. Drupal muss ja in jedem Fall Mails versenden können auch für den Versand von OneTime-Logins. Ohne Zusatzmodule oder Konfigurationen auf PHP-Ebene übergibt einfach Drupal Mails an PHP und PHP an "sendmail". Das Programm, das dann auf Server-Ebene die Mails entgegen nimmt muss nicht unebdingt das alte Programm "Sendmail" sein. Das Problem ist hier oft die Konfiguration dieses auf dem Server verwendeten Mailservers. Hier reicht es nicht, daß er einfach nur funktioniert. Aufgrund der großen Spammer-Problematik werden die empfangen Mail-Server z.B. bei Internetprovider des Users, der auch nur eine Passwort-Reset-Mail bekommen soll inzwischen zurecht sehr skeptisch darüber, welcher Server mit welchen Einstellungen wie viele Mails sendet. Seitdem Webanwendungen inkl, Drupal leider oft auch erfolgreich gehackt werden (siehe Drupalgeddon), um einfach über die oben beschriebene Standard-Mail-Funktion dann massenhaft SPAM zu versenden hat sich das Problem leider verschärft. Wenn man dann zwar sein eigenes System sauber hat, aber auf einem Webserver z.B. im managed Hosting den selben Mail-Versender nutzt, wie die vllt. gehackte Webanwendung vom "Nachbarn", steht das eigen System dann schnell mal auf einer "Blacklist" der SPAM-Bekämpfer.
Wenn man aber eine Kommunikationslösung aufbaut, die dann essentiell auf Mails basiert wie z.B. auch bei einem Newsletter-Versand über Drupal, macht es Sinn einen externen Mail-Server auch zum Versenden der Mails zu benutzen, entweder per Modul oder bei PHP-Routing. Je nachdem wie viel Mails man versenden muss in kurzer Zeit macht es dann evtl. Sinn auf einen Mail-Dienstleister zurück zu greifen, der darauf spezialisiert ist und sich vor allem darum kümmert, daß die versendeten Mails möglichst vertrauenswürdig wirken für die Empfänger-Systeme und Probleme in diesem Mail-Verkehr aktiv überwacht und darauf reagiert.

All dies lässt sich denke ich wahrscheinlich sogar mit den Standard-Modulen relativ leicht umsetzen ohne eigene Programmierungen. Einfach ein separates Mail-Konto auf einem vollwertigen gut verwalteten Mail-Server einbinden (natürlich über SSL-Verschlüsselung) und darüber dann Task-Mails senden und empfangen.

Bezüglich dem missbräuchlichem Senden an die Drupal-Anwendung per Mail ist es klar, daß es eine Logik geben sollte, wer denn posten darf auf diesem Weg. Ich glaube, daß die genannten Module so etwas schon berücksichtigen. Aber auf jeden Fall macht es neben Tokens und IDs in der Mail Sinn, den Absender zu überprüfen mit berchtigtsen Sender-Adressen z.B. über mit Drupal-User Mail-Adressen evtl. auch mit der Möglichkeit multipler Mail-Adressen (z.B. mit multiple_email).