Tags:
create new tag
, view all tags

Regelung bei der Weiterleitung von Emails

Wegen technischen und organisatorischen Gründen wurde die Weiterleitung von Emails via Exchange neu geregelt.

Problematik der bisherigen technischen Lösung

Die bisherige Lösung bestand darin, das Attribut targetAddress mit der Emailadresse zu versehen, an welche einkommende Emails weitergeleitet werden. Dies funktioniert zwar problemlos, hat aber den Nachteil, dass beim Verschieben von Mailboxen eben dieses Attribut gelöscht wird und von Hand nachgeführt werden muss. Durch die Migration auf Exchange 2007 mussten gleich mehrere Tausend Mailboxen verschoben werden. Der zusätzliche Aufwand, dieses Attribut nachzuführen, war enorm. Deshalb hat man sich für eine neue Lösung entschieden.

Neue Lösung

  • Anstelle des Attributs targetAddress wird neu das Attribut alternateRecipient verwendet
  • alternateRecipient zeigt auf ein (neues) contact-Objekt
  • das contact-Objekt enthält neu die OUTBOUND Emailadresse (im Attribut proxyAddresses)
  • das bisherige Mailbox-Objekt enthält neu nur INBOUND Emailadressen
  • wenn keine INBOUND-Emailadresse definiert ist, wird dem Mailbox-Objekt username@ethz.ch als primäre Emailadresse zugewiesen
  • wenn eine Mail via Exchange abgeschickt wird, wird die primäre Emailadresse als Absenderadresse verwendet
  • generell dürfen die Werte im Attribut proxyAddresses im gesamten AD nur einmal vorkommen, da eine einkommende Mail sonst nicht zustellbar ist

Auswirkungen auf die Funktionalität

  • speichern und weiterleiten (deliver and redirect) von Emails auch nach externen Mailboxen möglich
  • OUTBOUND-Emailadresse (nur die erste) befinden sich neu im contact-Objekt
  • Mailbox-Objekt enthält nur INBOUND-Adressen, standardmässig werden username@ethz.ch und username@intern.ethz.ch gesetzt
  • Absenderadresse ändert sich, falls Mail via Exchange abgesendet wird und primäre Emailadresse im Admin-Tool auf eine OUTBOUND-Emaildomäne zeigt
    • Beispiel: Hauptadresse von User xyz im Admin-Tool ist x.y@ee.ethz.ch (ist OUTBOUND)
    • Mailbox-Objekt von xyz in Exchange hat primäre Emailadresse xyz@ethz.ch (entspricht Absenderadresse)
    • Mailbox-Objekt von xyz leitet eingehende Mails zum contact-Objekt x.y@ee.ethz.ch weiter

Update: Probleme mit der neuen Lösung

  • GUI ist bei OUTBOUND-Adressen nicht im Einklang mit der Realität im AD
  • OUTBOUND-Aliase werden bloss in der nethz-DB gespeichert, nicht im AD-Userobjekt
  • eine OUTBOUND-Hauptadresse erzeugt automatisch einen contact
  • ein contact wird somit logisch an ein Userobjekt gekoppelt, was aber semantisch falsch ist: ein contact ist kein User!
  • im GAL resp. Web Access wird nicht die korrekte (OUTBOUND-)Emailadresse angezeigt sondern bloss username@ethz.ch
  • wenn eine zu migrierende Domäne technisch zeitweise auf INBOUND gesetzt wird (Erstellung von neuen Accounts) darf kein User dieser Domäne seine Emailadresse ändern, da er sonst seinen Forward löscht und einen Teil seiner eingehenden Mails auf Exchange landet
  • wenn ein User Mailadressen in mehreren Domänen hat und diese zu unterschiedlichen Zeitpunkten migriert werden, ist im Prinzip nicht vorhersagbar, ob eine eintreffende Mail in der Mailbox auf Exchange landet, weitergeleitet oder gar nicht zugestellt wird
  • Wenn man in Distribution Lists den Usernamen eingibt, dann wird das AD-Userobjekt eingefügt. Wenn die OUTBOUND-Emailadresse eingegeben wird, dann wird aber der contact eingefügt. Das begreift niemand.
  • Wenn man in Distribution Lists den Usernamen hinzufügt, dann erscheint «username»@ethz.ch als Adresse in der Liste der Members. Das ist unverständlich.
  • Wenn die Hauptadresse INBOUND ist und kein Forward existiert, werden auch bei einer Migration diese Aliase nie automatisch ins Userobjekt geschrieben
  • Wenn Maillisten migriert werden, werden häufig Email-Aliase als Listen-Member eingefügt. Diese Proxyadressen werden im AD aber nicht gefunden, die Liste bleibt daher unvollständig
  • das Entfernen eines Forwards ist ein sehr komplexer Prozess:
    • merken, in welchen Listen der contact drin war
    • Userobjekt zu diesen Listen hinzufügen
    • prüfen, ob contact noch von einem anderen Objekt benutzt wird
    • falls ja, nur das altRecipient-Attribut des Users löschen
    • falls nicht, den contact löschen
    • falls die Emailadresse des contacts mittlerweile INBOUND ist, den contact löschen und alle Userobjekte, welche einen altRecipient auf diesen contact gesetzt hatten, auf das entsprechende Userobjekt umleiten
    • alle Emailadressen aus der nethz-DB holen und in das Userobjekt schreiben

Vorschlag für Verbesserung der neuen Lösung

  • setzen des targetAddress-Attributs (wie früher) bei OUTBOUND-Adressen, welche aber innerhalb der ethz.ch-Domäne sind
  • erstellen eines contact-Objekts, falls Emailadresse ausserhalb der ethz.ch-Domäne ist
  • falls man Emails speichern und auf eine OUTBOUND-Adresse innerhalb ethz.ch weiterleiten möchte, muss zuerst explizit einen contact erstellen und den Forward dorthin umleiten (ergibt einen altRecipient anstatt einer targetAddress)

Vorteile dieser Verbesserung

  • massive Vereinfachung des Forward-Prozesses
  • ein Admin kann nachvollziehen, was passieren wird
  • contact und Userobjekt bleiben zwei separate Dinge und müssen nicht über eine komplexe Logik zusammengehalten werden
  • contact kann separat administriert werden
  • der contact wird nicht durch einen nicht nachvollziehbaren Prozess «einfach so» erstellt
  • Migrationsprozesse werden vereinfacht
  • Fehlerrate und Ticketrate werden reduziert

-- SwenVermeul - 2009-11-24

Topic revision: r7 - 2010-05-31 - vermeul
 
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback