Domino 7 $MIMETrack

1. Configuration Document für den ausgehenden MX Server öffnen
2. MIME
3. Advanced
4. Advanced Outbound Message Options

Unter dem Punkt "Notes items to be removed from headers:"

dann "$MIMETrack" eintragen...

Bei mir steht da auch:

INetFrom
$MIMETrack
$Mailer
Principal

Nein, da gibt es keinen "magischen" notes.ini Parameter.

Kontrolliere, ob die MIME-Settings überhaupt von dir aktiviert wurden im Konfigurationsdokument:

Allgemein > Internationale MIME-Einstellungen für dieses Dokument > Aktiviert

Sofern es mehrere Konfigurationsdokumente gibt kontrolliere, ob nicht zufällig noch ein weiteres für den gleichen Server gültig ist und sich die Einstellungen nicht widersprechen.

Las but not Least muss man nach einer Änderung am Konfigurationsdokument i.d.R. die Änderungen dem Router bekannt machen, am sinnvollsten ist es, diesen einmal neu zu starten.

was meinst du denn mit "Sender"? Gibt mal ein Beispiel...

Warum sie das müssen isr mir rätselhaft. Denn es sind reine Informationsfelder, die du da benennst.

Wichtig sind nur Reply To und From, da diese für Anzeige bzw Antwort verwendet werden.

Ein anderer Punkt ist, daß gerade diese Felder eben nicht verändert werden sollen, da sonst ja jeder eine Mail abschicken könnte mit einem ganz anderen Absender und das niemals mehr zurückverfolgbar ist

Ich vermute, mit "Gruppen Account" meinst du eine Mailin-DB? Wenn dort der Owner korrekt eingetragen ist und diese Mailin-DB auch eine SMTP-Adresse hat, tut das von sich aus, ohne dass man wild was verbiegen müsste...

Dann ist bei deren Mailsystem was verbogen. Ich habs grad auch mit meinem GMX-Account nachvollzogen, das tut einwandfrei. Wie du ja schon richtig angemerkt hast.

Wichtig ist, dass das FROM-Feld korrekt befüllt ist, denn das ist ausschlaggebend. X-ReturnPath, Sender und wie sie alle heißen, das ist nur Spaß. Ich hab ne Auflistung aller relevanten SMTP-Felder, die Mailer verwenden, wenn sie RFC-konform arbeiten. Sinnigerweise zu Hause :roll: *grmpf*
Aber ich bin mir ziemlich sicher, dass dein Problem nicht am X-ReturnPath-Feld hängt, sonderm am -scheinbar- verbastelten Mailer des Empfängers...

Jetzt mal ne ganz blöde Frage: warum willst du dir Arbeit machen, wenn andere es nicht hinbekommen, ihr System sauber zu halten? Da du nicht wissen kannst, mit wem du noch alles jemals kommunizieren willst, willst du jedes Mal an deinen Templates was verbiegen? Sollen die halt ihr System grade biegen und gut ist.

Also mal ehrlich, davon abgesehen, dass ich nicht einmal die Zeit, geschweige denn die Lust dazu hätte, da müsste mir auch noch was fehlen, an meinen (standardkomformen) Sachen rumzubasteln, um die Fehler Anderer auszubügeln...

Das Teambox-Template kenne ich, hab ich mich aber noch nicht soweit mit auseinander gesetzt, um auf Anhieb sagen zu können, was die gemacht haben. Problem dabei ist auch: ich gehe mal davon aus, deine Mailin-DB basiert auf der Mailschablone? Indem Fall wirst du viel Freude bei neuen Versionen haben, wenn du sämtliche Anpassungen jedes Mal wieder reinbasteln darfst. Kann man machen, klar. Allerdings stehen für mich Aufwand und Nutzen in keinem Verhältnis.

Und wenn irgendwer Probleme mit RFC-konformen Notesmails in seinem Exchange hat, gilt -für mich jedenfalls- die goldene Regel: "Wer's nicht kann, soll's lassen". So einfach ist die Welt...

Aha ok...

Also bei uns war es mal so, das man in das location document eine beliebige eMail Adresse als Sender eintragen konnte. Leider sind dann einige "Poweruser" hergegangen und haben aus Spaß die eMail Adresse der Kollegen da eingetragen.

Daraufhin wurde es so umgestellt, das egal was für einen Bullshit die da eintragen die eMail Adresse aus dem pers. document genommen wird. Für Firmen eMails z.B. info@firma.de verwende ich ebenfalls die Teammailbox (Und eine selbst Programmierte DB).

Was spricht denn gegen die Teammailbox?

So, ich hab mir grad nochmal das RFC 822 reingetan und wie ich das verstehe und bisher auch beobachtet habe, liegt der Fehler ganz eindeutig auf Seiten des anderen Mailers. Ich zitiere:

Zitat

4.4. ORIGINATOR FIELDS

The standard allows only a subset of the combinations possi-
ble with the From, Sender, Reply-To, Resent-From, Resent-Sender,
and Resent-Reply-To fields. The limitation is intentional.

4.4.1. FROM / RESENT-FROM

This field contains the identity of the person(s) who wished
this message to be sent. The message-creation process should
default this field to be a single, authenticated machine
address, indicating the AGENT (person, system or process)
entering the message. If this is not done, the "Sender" field
MUST be present. If the "From" field IS defaulted this way,
the "Sender" field is optional and is redundant with the
"From" field. In all cases, addresses in the "From" field
must be machine-usable (addr-specs) and may not contain named
lists (groups).

4.4.2. SENDER / RESENT-SENDER

This field contains the authenticated identity of the AGENT
(person, system or process) that sends the message. It is
intended for use when the sender is not the author of the mes-
sage, or to indicate who among a group of authors actually
sent the message. If the contents of the "Sender" field would
be completely redundant with the "From" field, then the
"Sender" field need not be present and its use is discouraged
(though still legal). In particular, the "Sender" field MUST
be present if it is NOT the same as the "From" Field.

The Sender mailbox specification includes a word sequence
which must correspond to a specific agent (i.e., a human user
or a computer program) rather than a standard address. This
indicates the expectation that the field will identify the
single AGENT (person, system, or process) responsible for
sending the mail and not simply include the name of a mailbox
from which the mail was sent. For example in the case of a
shared login name, the name, by itself, would not be adequate.
The local-part address unit, which refers to this agent, is
expected to be a computer system term, and not (for example) a
generalized person reference which can be used outside the
network text message context.

Alles anzeigen

Damit ist zunächst einmal definiert, dass FROM und SENDER standardkonforme Felder sind, die nicht einfach rausgenommen werden können, will man dem RFC entsprechen. Punkt!

Nun kommen wir zu deinem Fall. Du schickst aus deiner Mailin-DB etwas raus, sagen wir in eine andere Notes-DB. Dort kommt an "Mailin-Name, Sent by: Dein Name/Firma". Soweit, so bekannt. Und genau das ist auch der Unterschied zwischen FROM und SENDER. Wie wir oben sehen, gibt FROM den eindeutigen Namen des Senders an. Das ist -so dein Mailin-Dokument eine gültige SMTP-Adresse enthält- eben diese Adresse. Das Feld SENDER wird mit deiner, in der Arbeitsumgebung eingetragenen SMTP-Adresse gefüllt.

Da das FROM Feld existent sein *muss*, das SENDER Feld existent sein *kann*, ist daraus zu schließen, dass im Zweifelsfalle das FROM Feld verwendet werden muss, will man eine Antwort schicken, da eben nur dieses Feld eindeutig definiert, an wen die Mail zurück geht. Deinem Header lässt sich entnehmen, dass dort die Felder "korrekt" gefüllt sind, also die SMTP-Adressen bei dir und der Mailin-DB stimmen. Wir sehen auch, dass der Domino die Felder RFC-konform füllt.

Geht nun der remote Mailer auf das falsche Feld, ist das -ich wiederhole mich gerne- _nicht_ _dein_ Problem. Punkt! Abermals. Es bringt also überhaupt nichts, würdest du diese Felder entweder entfernen (was dazu führen kann, dass Mails abgewiesen werden, weil nicht RFC-konform) oder umbiegen. Und ich wiederhole mich auch jetzt, wenn ich sage, du kannst nicht -und glaube mir: du willst nicht- um jeden Fehler eines jeden Mailers, mit dem du irgendwann einmal in Berührung kommen wirst, drumherum programmieren.

Und das Thema -jedenfalls für mich- endlich einmal abzuschließen: du bist Admin! Du hast ein gewisses Maß an Wissen zu haben, das eine solche -mit Verlaub- saublöde Anforderung deiner Teams schlicht und ergreifend abblockt, das mit technischen Gegebenheiten und/oder programmiertechnischen Aufwand begründest und auf mögliche Nebenwirkungen hinweist, bzw. im Zweifelsfalle (sollte die Umsetzung durch Dritte erfolgen) ebenso schlicht und ergreifend die Verantwortung für diese Lösung ablehnst. Punkt! Zum Dritten.

Fassen wir zusammen:
* dein Domino arbeitet, wie erwartet,
* der remote Mailer tut das nicht,
* die gestellte Anforderung ist in irgendeiner Weise bestimmt zu erfüllen,
* die möglicherweise daraus resultierenden Nebenwirkungen sind nicht abzusehen,
* im Fehlerfalle ist völlig unklar und sehr schwer -wenn überhaupt- nachvollziehbar, was nun den Fehler verursacht. Von einem Fehlerfix gar nicht erst zu reden.

Ergo:
Du bist aus dem Schneider!

Ich hoffe, ich habe mich klar, deutlich und unmissverständlich ausgedrückt? :roll:

Dann werdet ihr entweder was an der Schablone oder an eurer Konfiguration verändert haben