autodiscover und autoconfig [GELÖST]

[Alexander]

Du hast es mit dem Safari-browser geöffnet?

Normalerweise sollte der Safari erkennen, das es sich bei der unter dieser URL ausgelieferten XML um eine Konfiguration handelt und dir die entsprechende Konfigurationsmöglichkeiten anzeigen.

Ich hab leider zur Zeit kein Apple Gerät zur Hand, kann somit frühstens ab morgen noch einmal schauen.

Da es in lezter Zeit in diesem Modul keine Änderung gab, kann es auch sein, das Apple etwas geändert hat, aus dem Grund bitte einmal die verwendeten Versionsnummern der eingesetzten Software mitteilen. Danke.

[MLan]

Hi Alex,
So sieht das aus.

Gruß Mlan

PS:
KH 21.1 + 21.2
Safari 12.0.3
MacOS Mojave 10.14.3

[mhagge]

Ich hab hier mal getestet, kommt so hier auch

MacOSX Monterey 12.01 mit Safari 15.1, aber auch bei IOS 15.1. mit dem dortigen Safari

MLan und ich sind ja nun MacOS-bzw. Safari-Versionsmäßig relativ weit auseinander. Hat es für Mojave noch irgendwelche Updates gegeben, die da was verändert haben könnten?

[MLan]

MLan und ich sind ja nun MacOS-bzw. Safari-Versionsmäßig relativ weit auseinander. Hat es für Mojave noch irgendwelche Updates gegeben, die da was verändert haben könnten?

Kann ich dir nicht sagen, meine Mojave läuft in einer VM. Kann das Ding nicht updaten.
Habe das nur für Testzwecke am laufen.

Aber egal, nun mit welchem OS/Browser.
Vorher müsste ja erstmal der "Univeral configurator" erscheinen,
da wo ich Name und Mail eingebe und das tut's halt nicht.
Es kommt halt immer sofort die fehlerhafte config.

Gruß MLan

[Alexander]

Hatte heute die Gelegenheit den "Universal Configurator" noch einmal anzuschauen.

Es ist wichtig, das die Konfigurationsdatei ".mobileconfig" als Dateiendung aufweist.
Die URL muss also nun wie folgt lauten. Dann erhält man eine Profil-Datei, die die noch fehlenden Eingaben (Anzeige-Name, Email, Password) abfragt.

Code: Select all

http://autoconfig-apple.domain.de/setup.mobileconfig

(Die URL, die ich 2019 gepostet habe, habe ich soeben korrigiert.)

Jetzt gibt es noch das Problem, dass das zwar für Mobilgeräte funktioniert, hier erkennt der Safari gleich, dass es sich um eine Konfiguration handelt, bei Desktop-Systemen aber lediglich die XML im Browser angezeigt wird (Man müsste den Inhalt manuell als "setup.mobileconfig" speichern und dann die Datei anklicken) -> Ergo, aktuell nicht schön.


=> Mit dem kommenden KeyHelp-Update gibt es nun also 2 Änderungen:

- Es wird keine Rolle mehr spielen, ob "setup.mobileconfig" nun teil der URL ist oder nicht.
- Die Datei wird bei aufrufen der URL sofort zum Download angeboten - Für Mobil-Geräte ändert sich damit nichts, aber für Desktop-Systeme kommt gleich der Dialog zum Importieren des Profils.
(- hab auch noch ein paar Bezeichnungen geändert)

[Tobi]

Hey Alex,

wie ich eben feststellen musste funktioniert deine "setup.mobileconfig" nicht wenn WEB- und MAIL-Server getrennte Maschinen sind.
Als Servername wird dann leider der WEB-Server genommen.
Und das funktioniert dann nicht.

Wäre schön wenn du das bitte fixen könntest.

[Alexander]

Hmm, hast du spontan auch eine Idee, wie du es am liebsten gelöst haben möchtest?

[Tobi]

Hmm, hast du spontan auch eine Idee, wie du es am liebsten gelöst haben möchtest?

Mit getmxrr() sollte sich doch der passende MX Server ermitteln lassen.

Andernfalls könnte man auch einfach den Hostnamen verwenden.
Denn diese E-Mail-Configs lädt man sich ja nur auf dem Mail-Server runter und dann passt der Hostname.

[MLan]

Hmm, hast du spontan auch eine Idee, wie du es am liebsten gelöst haben möchtest?

Hallo,
bin zwar nicht gefragt worden, würde aber gern meinen Senf dazugeben.
Ich würde mir eine Maske im Adminpanel wünschen, wo man sich seine autoconfig selber zusammenstellen kann.
Gerade jetzt mit SNI und der Möglichkeit der Ports 465/587 fände ich das super.

Gruß Mlan

[Alexander]

Dann müsste das Folgende ja hoffentlich für alle eine akzeptable Lösung bieten, es kommt ein neues Einstellungsfeld hinzu:

Code: Select all

E-Mail Autoconfig/Autodiscover & Verbindungsdatenanzeige
	Gibt an, welcher Servername für die Autoconfiguration eines Mail-Clients sowie für das Verbidungsdatenanzeige-Fenster verwendet werden soll.
	
( ) Priorisieren des Server-Hostnamen
	Zeigt immer den Server-Hostnamen dieses Servers an (km123456.keymachine.de).
	
( ) Priorisieren des E-Mail-Domain-Namens
	Zeigt die E-Mail-Domain als Hostnamen an, sofern diese mit SSL/TLS gesichert ist. 
	
( ) Externer Mailserver
	Zeigt für alle E-Mail-Konten den folgenden Hostnamen an.
	[ ...EINGABEFELD... ]

Einziges Problem was ich mit Option 3 sehe. Das würde für alle E-Mailkonten gelten. Wenn auch dem Server sich aber Domains aufhalten, dessen Email-Konten auf dem Server selbst gehostet werden, wird der falsche Server angezeigt. Auf der anderen Seite, wenn man schon eine klare Trennung zwischen Web und Mail-Server hat, dann sollte man da ja auch konsequent bleiben, also ist der Gedanke vielleicht in der Praxis garnicht relevant - aber das müsst ihr mir sagen .

@Mlan
i.d.R. will man die SSL/TLS-Ports (993/995/465), statt die STARTTLS-Ports (143/110/587/25), da diese sicherer sind. Diese werden seitens der Autoconfiguration auch jetzt schon als priorisiert dem Mail-Client angezeigt, sollten also vom Mail-Client auch vorausgewählt werden. Von daher denk ich, ist was die Ports angeht keine weitere Einstellung notwendig.


Wäre das soweit okay, oder hab ich noch einen Denkfehler?

[Tobi]

Denkfehler?
Weiß nicht...

Aber Punkt 3 kann es eigentlich nie geben.
Denn wenn externer Mailserver, dann keine lokalen E-Mail-Konten.
Und wenn keine lokalen E-Mail-Konten, dann auch keine E-Mail-Einrichtungsinfo.

Also das Problem aktuell ist, dass auf dem E-Mail-Server beim Benutzen der autoconfig, der WEB-Server als Host eingetragen ist.
Richtig wäre, dass der (lokale) HOST-Name des MAIL-Servers genommen wird. Weil der stimmt immer, egal wie er heißen mag.

[Alexander]

Na genau dafür wäre dann das Eingabefeld (= Option 3) da.

Email-Clients schauen nicht nach dem MX wenn sie Einrichten (zumindest nicht am Anfang). Sie schauen zuerst, ob sie eine Auto-Configuration finden. Und das tun sie in dem Sie einfach die Domain nehmen und dort per HTTP-Request prüfen. Wie gesagt, die Prüfung nach MX passiert erst später, wenn sie keine Auto-Configuration finden können.

In deinem Fall müsstest du also auf deinem WEB Server den Hostnamen deines MAIL Servers angeben. Auf dem Mail-Server lässt du alles wie es ist.

Dann kommt der Mail-Client -> Fragt die Domain ab (per HTTP) und landet somit auf dem WEB-Server - und hier wird aufgrund der getätigten Einstellung die Auto-Configuration entsprechend mit dem Hostnamen des MAIL-Servers ausgegeben.

[Tobi]

Der von dir gezeigt Weg nützt mir dann letztendlich auch wieder nix, da wir mehr als einen externen E-Mail Server haben.
Zum Teil haben wir noch Kunden mit E-Mail-Postfächern bei Provider XY.
Neuere Kunden mit besonderen Ansprüchen bekommen jetzt KeyHelp-Server A als Mail-Server angeboten.
Und dann gibt es noch den KeyHelp-Server B mit angebundenem E-Mail Archiv (aufpreispflichtig).
Die Webseiten aller dieser Kunden liegen jedoch auf dem KeyHelp-Server C (Webserver).
Wenn dann müsste man es also _pro_ Domain hinterlegen können, zu viel Aufwand für zu wenig Nutzen...

Eigentlich ging es mir nur um die Angaben in der "setup.mobileconfig" welche man sich vom Mailserver runterladen kann.
Woher bekommt die denn ihre Angaben? Und warum steht da der Webserver drin?

[Alexander]

Die Konfiguration setup.mobileconfig auf deinem MAIL Server ist korrekt und zeigt auch den MAIL-Server an, nur wird sie wie gesagt von den Mail-Clienten nicht beachtet, wie hier eben beschrieben:

Email-Clients schauen nicht nach dem MX wenn sie Einrichten (zumindest nicht am Anfang). Sie schauen zuerst, ob sie eine Auto-Configuration finden. Und das tun sie in dem Sie einfach die Domain nehmen und dort per HTTP-Request prüfen. Wie gesagt, die Prüfung nach MX passiert erst später, wenn sie keine Auto-Configuration finden können.

Anfragen der Mail-Clients landen also zuerst auf deinem WEB und nicht bei deinem MAIL-Server. Deswegen wird die angefragte Konfiguration von WEB-Server zurückgegeben. Warum dem so ist, musst du die Mail-Client Entwickler fragen, hat sicher seine Gründe, da hat KeyHelp aber keinen Einfluss darauf .

Auch was das automatische Ermitteln angeht, also das dein WEB-Server, wenn vom Mail-Client angefragt, quasi loszieht und versucht sich die autoconfig von anderen Servern zu holen (weil die Mail-Clients ja scheinbar selbst nicht dazu in der Lage sind ) würde es noch um ein vielfaches komplizierter machen. KeyHelp müsste dann quasi ein eigenes System besitzen, was autoconfig und autodiscover (und was es da noch alles gibt) Daten von fremden Servern ermitteln kann - also genau so, wie es die Mail-Clients machen würden, nur besser. Von KeyHelp zu KeyHelp kein Problem, aber wenn es sich beim Mail-Server um ein KeyHelp-fremdes System handelt müsste man das Autodiscover & Autoconfig (usw.)-"Protokoll" im KeyHelp abbilden und das würde ich nicht unbedingt wollen .


Deswegen auch meine Frage eingangs "Hmm, hast du spontan auch eine Idee, wie du es am liebsten gelöst haben möchtest?" - Es ist leider nicht so trivial wie es vielleicht den Anschein hat und im Idealfall ohne das man noch eine separate "pro Domain"-Liste pflegen muss.

[MLan]

Wenn dann müsste man es also _pro_ Domain hinterlegen können...

Das wäre auch meine favorisierte Lösung.
Wenn so ein Autoconfig Domain Set existiert, dann dieses ausliefern, andernfalls ein Standard Paneldomain Set.

@Mlan
i.d.R. will man die SSL/TLS-Ports (993/995/465), statt die STARTTLS-Ports (143/110/587/25), da diese sicherer sind. Diese werden seitens der Autoconfiguration auch jetzt schon als priorisiert dem Mail-Client angezeigt, sollten also vom Mail-Client auch vorausgewählt werden. Von daher denk ich, ist was die Ports angeht keine weitere Einstellung notwendig.
Wäre das soweit okay, oder hab ich noch einen Denkfehler?

Problem was man seit der Umstellung 465/587 hat ist folgender Punkt.
Bei älteren Kunden wurde der 587 genutzt.
Nun liefert die Autoconfig aber den 465 aus.
Damit hat man bei einigen Firmenkunden ein kleines Durcheinander.
Deswegen hatte ich den Vorschlag, den Port auch anzupassen zu dürfen, gemacht.
Gruß Mlan