8. Nachrichtenänderungen
Sites KÖNNEN Einreichungen ändern, um die Einhaltung von Standards und Site-Richtlinien sicherzustellen. Dieser Abschnitt beschreibt eine Reihe solcher Änderungen, die oft als nützlich erachtet werden.
HINWEIS: Als Orientierungshilfe für lokale Entscheidungen zur Implementierung von Nachrichtenänderungen besteht eine oberste Regel darin, solche Aktionen auf Abhilfemaßnahmen für spezifische Probleme zu beschränken, die klare Lösungen haben. Dies gilt insbesondere für Adresselemente. Beispielsweise führt das wahllose Anhängen einer Domäne an eine Adresse oder ein Element, dem eine fehlt, normalerweise zu mehr defekten Adressen. Eine unqualifizierte Adresse muss als gültiger lokaler Teil in der Domäne verifiziert werden, bevor die Domäne sicher hinzugefügt werden kann.
Jede vom MSA weitergeleitete oder zugestellte Nachricht MUSS den Anforderungen von [SMTP-MTA] und [MESSAGE-FORMAT] entsprechen.
8.1. 'Sender' hinzufügen
Der MSA KANN das 'Sender'-Feld hinzufügen oder ersetzen, wenn die Identität des Absenders bekannt ist und diese nicht im 'From'-Feld angegeben ist.
Der MSA MUSS sicherstellen, dass jede Adresse, die er in ein 'Sender'-Feld einfügt, tatsächlich eine gültige E-Mail-Adresse ist.
8.2. 'Date' hinzufügen
Der MSA KANN der eingereichten Nachricht ein 'Date'-Feld hinzufügen, wenn es fehlt, oder das 'Date'-Feld korrigieren, wenn es nicht der [MESSAGE-FORMAT]-Syntax entspricht.
8.3. 'Message-ID' hinzufügen
Der MSA SOLLTE das 'Message-ID'-Feld hinzufügen oder ersetzen, wenn es fehlt oder keine gültige Syntax aufweist (wie in [MESSAGE-FORMAT] definiert). Beachten Sie, dass eine Reihe von Clients immer noch keine Message-ID-Felder generieren.
8.4. Transfer-Codierung
Der MSA KANN eine Transfer-Codierung auf die Nachricht gemäß den MIME-Konventionen anwenden, wenn dies erforderlich und für den MIME-Typ nicht schädlich ist.
8.5. Nachricht signieren
Der MSA KANN die Nachricht (digital) signieren oder auf andere Weise Authentifizierungsinformationen hinzufügen.
8.6. Nachricht verschlüsseln
Der MSA KANN die Nachricht für den Transport verschlüsseln, um Organisationsrichtlinien widerzuspiegeln.
HINWEIS: Um nützlich zu sein, impliziert das Hinzufügen einer Signatur und/oder Verschlüsselung durch den MSA im Allgemeinen, dass die Verbindung zwischen dem MUA und dem MSA selbst auf andere Weise gesichert sein muss, beispielsweise durch Betrieb innerhalb einer sicheren Umgebung, durch Sicherung der Einreichungsverbindung auf der Transportschicht oder durch Verwendung eines [SMTP-AUTH]-Mechanismus, der Sitzungsintegrität bietet.
8.7. Aliase auflösen
Der MSA KANN Aliase (CNAME-Einträge) für Domänennamen im SMTP-Umschlag und optional in Adressfeldern des Headers auflösen, vorbehaltlich lokaler Richtlinien.
HINWEIS: Das bedingungslose Auflösen von Aliasen könnte schädlich sein. Wenn beispielsweise www.example.net und ftp.example.net beide Aliase für mail.example.net sind, könnten beim Umschreiben nützliche Informationen verloren gehen.
8.8. Header-Umschreiben
Der MSA KANN lokale Teile und/oder Domänen im SMTP-Umschlag und optional in Adressfeldern des Headers gemäß lokaler Richtlinien umschreiben. Beispielsweise zieht es eine Site möglicherweise vor, 'JRU' als 'J.Random.User' umzuschreiben, um Anmeldenamen zu verbergen, und/oder 'squeaky.sales.example.net' als 'zyx.example.net' umzuschreiben, um Maschinennamen zu verbergen und das Verschieben von Benutzern zu erleichtern.
Es sollten jedoch nur Adressen, lokale Teile oder Domänen geändert werden, die bestimmten lokalen MSA-Konfigurationseinstellungen entsprechen. Es wäre sehr gefährlich für den MSA, datenunabhängige Umschreibungsregeln anzuwenden, wie z. B. das ständige Löschen des ersten Elements eines Domänennamens. So wäre beispielsweise eine Regel akzeptabel, die das ganz linke Element der Domäne entfernt, wenn die vollständige Domäne mit '*.foo.example.net' übereinstimmt.
Der MSA DARF KEINE vorwärts gerichtete (Ziel-) Adresse auf eine Weise umschreiben, die die Einschränkungen von [SMTP-MTA] bezüglich Änderungen von lokalen Teilen verletzt.