autoconfig.conf SSL & autodiscover Frage

[Ralph]

Sorry Alex, aber bis heute habe ich mit dem „neuen“ 465er Port „undefinierbare“ Probleme in Verbindung mit Outlook und Microsoft Mail.
Es endet immer damit, dass Ich schlussendlich Port 587 verwende…

Das kann ich bestätigen, auch bei meinen alten (imscp) Systemen verwende ich in der autoconfig nur noch 587 für smtp, seit dem gab es keine Probleme mehr bei den Kunden.
Wer andere Ports verwenden möchte, kann dies ja tun indem diese manuell umgestellt werden im Client.

Es geht aber bei autoconfig/autodiscover darum direkt auf Anhieb eine funktionierende Client Verbindung bereit zu stellen ohne manuell eingreifen zu müssen.

Beim autodiscover funktioniert nur der download für IOS, der Microsoft Teil liefert derzeit gar keinen Output:

Code: Select all

This XML file does not appear to have any style information associated with it.
<Autodiscover xmlns="http://schemas.microsoft.com/exchange/autodiscover/responseschema/2006">
<Response>
<Error Time="10:06:33.7441250" Id="0000000000">
<ErrorCode>600</ErrorCode>
<Message>Invalid Request</Message>
<DebugData/>
</Error>
</Response>
</Autodiscover>

[Ralph]

Hm, was mir vorhin noch aufgefallen ist ... dieser xmlns Link im Header für das xml Schema zeigt beim direkten Aufruf

The resource you are looking for has been removed, had its name changed, or is temporarily unavailable.

https://schemas.microsoft.com/exchange/ ... chema/2006

möglich wäre aber auch dass dort nochmals für die Clients weitergeleitet wird, aber erscheint mir seltsam ...

Der Header des autodiscover xml files, sollte diese 3 Infos enthalten, xml version, Autodiscover xmln, Response xmlns letztere via "https"

Code: Select all

<?xml version="1.0" encoding="utf-8" ?>
<Autodiscover xmlns="https://schemas.microsoft.com/exchange/autodiscover/responseschema/2006">
<Response xmlns="https://schemas.microsoft.com/exchange/autodiscover/outlook/responseschema/2006a">
...

Aber wundern würde es mich nicht wenn dieser Inhalt der Schema URL bei Microsoft gar nicht mehr existiert

[Alexander]

Hm, was mir vorhin noch aufgefallen ist ... dieser xmlns Link im Header für das xml Schema zeigt beim direkten Aufruf
The resource you are looking for has been removed, had its name changed, or is temporarily unavailable.
https://schemas.microsoft.com/exchange/ ... chema/2006

möglich wäre aber auch dass dort nochmals für die Clients weitergeleitet wird, aber erscheint mir seltsam ...

Der Header des autodiscover xml files, sollte diese 3 Infos enthalten, xml version, Autodiscover xmln, Response xmlns letztere via "https"
CODE: ALLES AUSWÄHLEN

<?xml version="1.0" encoding="utf-8" ?>
<Autodiscover xmlns="https://schemas.microsoft.com/exchange/ ... chema/2006">
<Response xmlns="https://schemas.microsoft.com/exchange/ ... hema/2006a">
...
Aber wundern würde es mich nicht wenn dieser Inhalt der Schema URL bei Microsoft gar nicht mehr existiert

Gerade nochmal hier nachgeschaut:

https://learn.microsoft.com/en-us/opens ... dfrom=MSDN

Stand August 2021 / Protocol-Revision 21.0
https://msopenspecs.azureedge.net/files ... CLI%5d.pdf

Auch dort wird noch auf die http://... statt https:// Adresse verwiesen. Und im Error-Fall heißt es auch nur <Repsonse> statt <Response xmlns="...">
KeyHelp antwortet also weiterhin gemäß dieser Dokumentation/Spezifikation korrekt.

Da schieb ich den Ball gerne weiter .

[Ralph]

Auch dort wird noch auf die http://... statt https:// Adresse verwiesen. Und im Error-Fall heißt es auch nur <Repsonse> statt <Response xmlns="...">
KeyHelp antwortet also weiterhin gemäß dieser Dokumentation/Spezifikation korrekt.
Da schieb ich den Ball gerne weiter .

Gut, akzeptiert
könnte denn der Output nur ein wenig optimiert werden?
Also die Standard Ports an erster Stelle (die ssl Ports darunter) eventl. Port 25 ganz rausnehmen ... (wird von vielen ISP blockiert).

Es geht nur darum direkt eine für alle funktionierende Verbindung herzustellen, der User kann danach weiter individuell anpassen und experimentieren.

L.G.

[Alexander]

Tja, das ist jetzt die Frage, was ich an die Spitze der Autokonfiguration/des Verbindungsdaten-Popup setzen sollte. (Von mir aus macht gern ein Vote dazu)

Port: 587
- vermeintlich unsicherer als 465
- scheinbar bei einigen Nutzern weniger Problem-behaftet

Port 465
- sicherer
- sollte laut rfc bevorzugt werden
- führt bei manchen scheinbar zu Problemen

[Ralph]

Tja, das ist jetzt die Frage, was ich an die Spitze der Autokonfiguration/des Verbindungsdaten-Popup setzen sollte. (Von mir aus macht gern ein Vote dazu)

Port: 587
- vermeintlich unsicherer als 465
- scheinbar bei einigen Nutzern weniger Problem-behaftet

Port 465
- sicherer
- sollte laut rfc bevorzugt werden
- führt bei manchen scheinbar zu Problemen

Na ja, sicherer wäre 465, aber es nützt ja nichts wenn bei vielen Usern damit keine Verbindung zustande kommt und Fail2ban dann auch noch anschliessend zuschlägt
Das autoconfig/autodiscover soll ja dabei helfen überhaupt einmal eine Verbindung herstellen, möglichst kompatibel, in den Zugangsdaten könnte man aber darauf hinweisen.
587 ist eigentlich zum Standard geworden ...

[Tobi]

Wäre vielleicht ein erster Schritt herauszufinden WARUM Port 465 nicht erwartungsgemäß funktioniert?

[Ralph]

Wäre vielleicht ein erster Schritt herauszufinden WARUM Port 465 nicht erwartungsgemäß funktioniert?

verdammt gute Frage
Nun, ich würde mich selbst als paranoiden Sicherheits Papst bezeichnen, unter anderem ....
Aber bei den meisten Kunden ist es leider etwas anders, für die steht an erster Stelle usability und bei autoconfig geht es ja um usability.

Port 587 ist Standard, nichts aussergewöhnliches ... via TLS "sicherheitskritisch" eher weniger

25.08.2023 — Port 587 ist der Standardport für die SMTP-Übermittlung im modernen Web. Man kann zwar auch andere Ports für die Einreichung verwenden

https://www.google.de/search?q=port+587

[Alexander]

Wäre vielleicht ein erster Schritt herauszufinden WARUM Port 465 nicht erwartungsgemäß funktioniert?

Sagst du es Microsoft oder ich ?

Na dann nehme ich den Port für Microsoft eben komplett raus, für Apple und Mozilla lasse ich alles unverändert. Damit sollte es doch dann passen?

[Tobi]

Ne also den Port 465 hätte ich schon gern.
Am liebsten automatisch in Outlook.

Ich habe nur bisher noch nie die Zeit gefunden dementsprechend die Logfiles zu analysieren. Zu den Zeiten von anno dunnemal gab es zum Beispiel den Microsoft Outlook Express Schalter „fix_broken_blablabla“. Lang ist her… War das „fix_broken_smtpagent = 1“ oder so?

Gerne nehme ich mich mal der Sache im Detail an falls niemand anders auf Logfile-Analyse scharf ist

[Ralph]

Also von mir aus können die Ports auch alle drin bleiben, es kommt aber auf die Priorität an - also die kompatibelsten Ports an erste Stelle setzen.
autoconfig/autosiscover macht nur Sinn wenn dadurch eine funktionierende Verbindung ohne manuelles Eingreifen hergestellt werden kann.