E-Mail: wirkt sich reply-to auch auf bounces aus?

[DeWitt]

Hallo SELFHTML-Gemeinde,

Ich möchte über den Header einer E-Mail bewirken, dass Bounce-Nachrichten an Adresse A , Antworten jedoch an Adresse B geschickt werden.

Mein erster Ansatz wären folgende zwei Header-Zeilen:
____

From: Adresse A
Reply-To: Adresse B
____

Allerdings frage ich mich, ob dies den gewünschten Effekt hätte, oder ob dann auch Bounces an die "reply-to"-Adresse geschickt werden würden.
Gibt es dafür überhaupt eine Regelung, an die sich (quasi) alle Webserver halten?
Leider kenne ich keine fundierten Quellen zum Thema Mail-Header...

Ciao,
David //aka DeWitt

[Cheatah]

Hi,

Allerdings frage ich mich, ob dies den gewünschten Effekt hätte, oder ob dann auch Bounces an die "reply-to"-Adresse geschickt werden würden.

nein. Sie werden an die im Return-Path-Header angegebene Adresse geschickt. Dieser Header wird entfernt, bevor der "Endkunde" die Mail zu Gesicht bekommt.

Leider kenne ich keine fundierten Quellen zum Thema Mail-Header...

RFC 2822 definiert das Mailformat.

Cheatah

[DeWitt]

Allerdings frage ich mich, ob dies den gewünschten Effekt hätte, oder ob dann auch Bounces an die "reply-to"-Adresse geschickt werden würden.

nein. Sie werden an die im Return-Path-Header angegebene Adresse geschickt. Dieser Header wird entfernt, bevor der "Endkunde" die Mail zu Gesicht bekommt.

Ok, das hilft mir schon weiter, allerdings kommen da bei mir gleich jede Menge neue Fragen auf:

Verstehe ich das also richtig: Es ist prinzipiell egal, welche Adresse bei "From" usw. steht, bounces werden immer an den Return-Path geschickt?
Was muss ich mir unter dieser Angabe vorstellen? Im RFC2821 steht:

The primary purpose of the Return-path is to designate the address to
  which messages indicating non-delivery or other mail system failures
  are to be sent.

Wird dieser Eintrag also vom versendenden Programm erstellt (in meinem Fall also /usr/bin/mail) und ist quasi die Adresse des Mail-Programms auf meinem Server?
Daraus ergäbe sich gleich die nächste Frage: Wer erhält standardmäßig Emails, die an den Return-Path gehen? Der Server-Admin?

RFC 2822 definiert das Mailformat.

Immer diese RFCs :/. Gibt es sowas wie einen "RFC-Parser", der sie visuell aufbereitet? Ich finde es recht mühsam, die RFCs in ihrer plaintext-Struktur zu lesen und meide sie deswegen, auch wenn sie wahrscheinlich eine richtige Goldgrube für den sind, der sie zu nutzen weiß.

Ciao,
David //aka DeWitt

[Der Martin]

Hallo,

Sie werden an die im Return-Path-Header angegebene Adresse geschickt. Dieser Header wird entfernt, bevor der "Endkunde" die Mail zu Gesicht bekommt.

Im RFC2821 steht:

The primary purpose of the Return-path is to designate the address to
  which messages indicating non-delivery or other mail system failures
  are to be sent.

That's what Cheatah said.

Wird dieser Eintrag also vom versendenden Programm erstellt (in meinem Fall also /usr/bin/mail) und ist quasi die Adresse des Mail-Programms auf meinem Server?

Nein, normalerweise vom ersten SMTP-Server, der die Nachricht entgegennimmt.

Daraus ergäbe sich gleich die nächste Frage: Wer erhält standardmäßig Emails, die an den Return-Path gehen? Der Server-Admin?

Vermutlich. Die Server der großen Volksprovider sind allerdings meist so eingerichtet, dass sie auch als Return-Path deine eigene Mailadresse (bzw. eine deiner eigenen Adressen) eintragen, die zu diesem Account gehört (gehören).

RFC 2822 definiert das Mailformat.
Immer diese RFCs :/. Gibt es sowas wie einen "RFC-Parser", der sie visuell aufbereitet? Ich finde es recht mühsam, die RFCs in ihrer plaintext-Struktur zu lesen

Etliche RFCs gibt es auch in einer als HTML "aufgehübschten" Fasung, aber das beste an denen ist IMHO der Link zur Plaintext-Version. Wenn man dann noch ein Script drüberlaufen lässt, das die lästigen Seitenumbrüche und Fußzeilen rausschneidet, ist alles in Butter. Dann hat man ein gut nutzbares, fortlaufendes Textdokument.

auch wenn sie wahrscheinlich eine richtige Goldgrube für den sind, der sie zu nutzen weiß.

Ja, allerdings. :-)

So long,
 Martin