rseichter / automx2

Mail User Agent (email client) configuration made easy
GNU General Public License v3.0
65 stars 20 forks source link

autodiscover <SSL>off</SSL> always returned for mail servers #1

Closed CacheMinimal closed 3 years ago

CacheMinimal commented 3 years ago

Using release 2021.3.1 on Ubuntu Server 20.04 I am finding that all mail server autodiscover requests contain the following value in their XML response:

<SSL>off</SSL>

This is regardless of setting the column socket_type to SSL in table server, as shown in the examples. By way of database verification, autoconfig returns <socketType>SSL</socketType> for the same server.

I believe this to be an error here:

https://github.com/rseichter/automx2/blob/7ad7a3e8773dd00bbda53d154d4e63e318d47fd8/automx2/generators/outlook.py#L79

Which should read:

SubElement(element, 'SSL').text = self.on_off('SSL' == server.socket_type)

This appears to then correctly provision accounts using SSL via the autodiscover protocol.

rseichter commented 3 years ago

I am not too happy about the current implementation of SSL and AuthRequired in the Autodiscover generator code, because there appears to be no direct match for the socketType and authentication elements used in Autoconfig, with the latter service offering a greater variety of values than Autodiscover's simple on/off switches. I have considered dropping the attributes from my Autodiscover implementation in order to fall back to the respective default values (AuthRequired already defaults to "always true" anyway).

Can you please tell me what MUA software you have used for testing? I have not received complaints from Outlook users so far, and I'm not sure if the change you proposed would be helpful or not.

CacheMinimal commented 3 years ago

Apologies for any confusion. I was not questioning your current implementation in any way, just pointing out a logic error in the code. You are currently checking server.authentication for the value SSL, which it will never have. The authentication attribute takes values like plain or login. I believe this to be a simple typo as shown above.

At present I have no particular MUA in mind and am just validating with curl. Below are my test cases and responses received using the current release.

Autoconfig

curl 'https://autoconfig.example.net/mail/config-v1.1.xml?emailaddress=user@example.net'

responds with:

<clientConfig version="1.1">
  <emailProvider id="automx2-1000">
    <identity/>
    <domain>example.net</domain>
    <displayName>Example Organisation</displayName>
    <displayShortName>Example</displayShortName>
    <incomingServer type="imap">
      <hostname>mail.example.net</hostname>
      <port>993</port>
      <socketType>SSL</socketType>
      <username>user</username>
      <authentication>plain</authentication>
    </incomingServer>
    <outgoingServer type="smtp">
      <hostname>mail.example.net</hostname>
      <port>465</port>
      <socketType>SSL</socketType>
      <username>user</username>
      <authentication>plain</authentication>
    </outgoingServer>
  </emailProvider>
</clientConfig>

Autodiscover

Create an autodiscover.xml request file containing:

<Autodiscover xmlns="http://schemas.microsoft.com/exchange/autodiscover/outlook/requestschema/2006">
  <Request>
    <EMailAddress>user@example.net</EMailAddress>
<AcceptableResponseSchema>http://schemas.microsoft.com/exchange/autodiscover/outlook/responseschema/2006a</AcceptableResponseSchema>
  </Request>
</Autodiscover>

Send the request with: curl -XPOST -d @autodiscover.xml --header "Content-Type:text/xml" https://autodiscover.example.net/autodiscover/autodiscover.xml

responds with:

<Autodiscover xmlns="http://schemas.microsoft.com/exchange/autodiscover/responseschema/2006">
  <Response xmlns="http://schemas.microsoft.com/exchange/autodiscover/outlook/responseschema/2006a">
    <User>
    <DisplayName>Example User</DisplayName>
    </User>
    <Account>
      <AccountType>email</AccountType>
      <Action>settings</Action>
      <Protocol>
        <Type>IMAP</Type>
        <Server>mail.example.net</Server>
        <Port>993</Port>
        <LoginName>user</LoginName>
        <SSL>off</SSL>
        <AuthRequired>on</AuthRequired>
      </Protocol>
      <Protocol>
        <Type>SMTP</Type>
        <Server>mail.example.net</Server>
        <Port>465</Port>
        <LoginName>user</LoginName>
        <SSL>off</SSL>
        <AuthRequired>on</AuthRequired>
      </Protocol>
      <Protocol>
        <Type>CalDAV</Type>
        <Server>https://cloud.example.net/remote.php/dav/calendars/</Server>
        <Port>443</Port>
        <SSL>on</SSL>
        <DomainRequired>off</DomainRequired>
        <LoginName>user</LoginName>
      </Protocol>
      <Protocol>
        <Type>CardDAV</Type>
        <Server>https://cloud.example.net/remote.php/dav/addressbooks/</Server>
        <Port>443</Port>
        <SSL>on</SSL>
        <DomainRequired>off</DomainRequired>
        <LoginName>user</LoginName>
     </Protocol>
    </Account>
  </Response>
</Autodiscover>

Mobileconfig

curl https://autodiscover.example.net/mobileconfig/?emailaddress=user@example.net

responds with:

<plist version="1.0">
  <dict>
    <key>PayloadContent</key>
    <array>
      <dict>
        <key>EmailAccountDescription</key>
        <string>user@example.net</string>
        <key>EmailAccountName</key>
        <string>Example User</string>
        <key>EmailAccountType</key>
        <string>EmailTypeIMAP</string>
        <key>EmailAddress</key>
        <string>user@example.net</string>
        <key>IncomingMailServerAuthentication</key>
        <string>EmailAuthPassword</string>
        <key>IncomingMailServerHostName</key>
        <string>mail.example.net</string>
        <key>IncomingMailServerPortNumber</key>
        <integer>993</integer>
        <key>IncomingMailServerUseSSL</key>
        <true/>
        <key>IncomingMailServerUsername</key>
        <string>user</string>
        <key>OutgoingMailServerAuthentication</key>
        <string>EmailAuthPassword</string>
        <key>OutgoingMailServerHostName</key>
        <string>mail.example.net</string>
        <key>OutgoingMailServerPortNumber</key>
        <integer>465</integer>
        <key>OutgoingMailServerUseSSL</key>
        <true/>
        <key>OutgoingMailServerUsername</key>
        <string>user</string>
        <key>OutgoingPasswordSameAsIncomingPassword</key>
        <true/>
        <key>PayloadDescription</key>
        <string>Email account configuration for user@example.net</string>
        <key>PayloadDisplayName</key>
        <string>example.net</string>
        <key>PayloadIdentifier</key>
        <string>com.apple.mail.managed.f04751f8b1be4fb6a50c405926ad0bb4</string>
        <key>PayloadType</key>
        <string>com.apple.mail.managed</string>
        <key>PayloadUUID</key>
        <string>f04751f8b1be4fb6a50c405926ad0bb4</string>
        <key>PayloadVersion</key>
        <integer>1</integer>
        <key>SMIMEEnablePerMessageSwitch</key>
        <false/>
        <key>SMIMEEnabled</key>
        <false/>
        <key>SMIMEEncryptionEnabled</key>
        <false/>
        <key>SMIMESigningEnabled</key>
        <false/>
        <key>allowMailDrop</key>
        <false/>
        <key>disableMailRecentsSyncing</key>
        <false/>
      </dict>
    </array>
    <key>PayloadDisplayName</key>
    <string>Mail account example.net</string>
    <key>PayloadIdentifier</key>
    <string>automx2-49b1a3a41fc9468cb8b359ed37113dfa</string>
    <key>PayloadRemovalDisallowed</key>
    <false/>
    <key>PayloadType</key>
    <string>Configuration</string>
    <key>PayloadUUID</key>
    <string>49b1a3a41fc9468cb8b359ed37113dfa</string>
    <key>PayloadVersion</key>
    <integer>1</integer>
  </dict>
</plist>
rseichter commented 3 years ago

No need to apologise, your observation is correct. What I meant to express is that the mapping from the DB columns, which were initially created for Autoconfig, to the Autodiscover fields, is not something I am content with in its current state. I have thought about either adding boolean columns specifically for Autodiscover, or to not map these attributes at all, as I mentioned above.

I should change the generator implementation, but I am unsure about the best way to do it. Perhaps it would be easiest to pick an implementation and document it in detail, so as not to surprise existing users.