Mail Autoconfig

Introduction This protocol allows users to set up their existing email account in a new mail client application, by entering only their name, email address, and password. The mail application, by means of mail autoconfig specified here, will determine all the other parameters that are required, including IMAP or POP3 hostname, TLS configuration, form of username, authentication method, and other settings, and likewise for SMTP. Contact sync and calendar, file sharing and other services can also be set up automatically. The protocol works by first determining the domain from the email address, and the querying well-known URLs at the email provider, which return the configuration parameters in computer-readable form. Failing that, various fallback sources can be applied, like a common database of configurations for large email providers who do not directly support this protocol, or other mechanisms to determine the configuration. While this AutoConfig protocol was conceived for configuring mail clients, it can also be used for accounts of other types, like contacts and calendar sync, chat, video conference, or online publishing. The primary concept and limitation here is that these accounts need to be hosted by the same provider as the email address.

Implementations This protocol is in production use since 15 years by major email clients, and the config database (used as fallback) contains configurations for over 50% of all email accounts. Currently, this protocol or parts of it has been implemented by:

Thunderbird
Parula
Evolution
KMail
Kontact
K9 Mail and Thunderbird Mobile
FairEmail
NextCloud email
Delta Chat

and likely other mail clients. The purpose of this paper is to document and specify what is deployed in the wild.

Data format Whether the ISP or a common central database returns the configuration, the resulting document MUST have the following data format and qualities. The MIME type is text/xml.

XML config file The following example shows the syntax of the XML config file. example.com example.net Google Workspace GMail imap.example.com 993 SSL password-cleartext %EMAILADDRESS% pop.example.com 995 SSL password-cleartext %EMAILADDRESS% smtp.googlemail.com 587 STARTTLS password-cleartext %EMAILADDRESS% https://jmap.example.com OAuth2 http-basic %EMAILADDRESS% https://mail.example.com/EWS/Exchange.asmx %EMAILADDRESS% http-basic https://mail.example.com/Microsoft-Server-ActiveSync %EMAILADDRESS% OAuth2 Configure mail app for IMAP Email mit IMAP konfigurieren https://contacts.example.com/remote.php/dav http-basic %EMAILADDRESS% https://calendar.example.com/remote.php/dav http-basic %EMAILADDRESS% https://share.example.com/remote.php/dav http-basic %EMAILADDRESS% wss://example.com:5281/xmpp-websocket http-basic %EMAILADDRESS% xmpp.example.com 5223 TLS password-cleartext %EMAILADDRESS% https://talk.example.com/login OAuth2 %EMAILADDRESS% https://login.example.com/auth https://login.example.com/token login.example.com IMAP POP3 SMTP CalDAV CardDAV WebDAV offline_access open give-me-your-password ]]>

Global elements The file starts with an XML header, e.g. <?xml version="1.0"?>, and is encoded in UTF-8 without BOM.

clientConfig The root element of the XML file is <clientConfig version="1.2">. The version is 1.2 for the version defined in this specification. 1.1 is a compatible previous version. Higher versions are for future specifications. The client MUST NOT reject a config file solely based on the version number.

emailProvider Element <emailProvider id="example.com"> is within the root element. This element has no semantic purpose and exists for legacy reasons only. If all of its child elements were within the root element, their meaning would still be the same. The id is a unique string that typically matches the primary domain of the provider. Within <emailProvider> are <domain>, <displayName> and <displayShortName>, <documentation>, <incomingServer> and <outgoingServer>.

domain E.g. example.com example.net example-hosting.com ]]> The content of the <domain> element defines which email addresses this config is valid for. E.g. a config with <domain>example.com</domain> is valid for email address fred@example.com. Multiple <domain> elements may be included, which means that the config is valid for all of these domains. Their order has no meaning - you may sort them by number of users, importance to the provider, or alphabethically. A <domain purpose="mx"> specifies the domain name of the MX server of the email address, and is used config file lookup using MX server names, as specified in section MX. The purpose property is mainly informational and may be ignored.

displayName and displayShortName E.g. Google Workspace GMail ]]> The <displayName> element contains the name of the provider, e.g. as preferred by the marketing of the provider itself. It SHOULD be no longer than 30 characters, but MUST be no longer than 60 characters. The <displayShortName> element contains the name of the provider, as typically used by end users. It SHOULD be no longer than 12 characters, and it MUST NOT be longer than 20 characters.

documentation E.g. Configure mail app for IMAP Email mit IMAP konfigurieren ]]> This is purely informational and not required for the automatic setup. Records the user help webpage at the provider that describes the mail server settings. The config may be based on that page, but does not necessarily have to match it, e.g. when a better config is available than the one described on the webpage. The url property contains the URL of the webpage. The <descr> content describes the content and purpose of the page and why it's referenced here. Multiple <descr> elements with different lang properties are allowed, whereby the lang property contains the 2-letter ISO language code, like the HTML lang attribute.

Server sections E.g. <incomingServer type="jmap"> or <calendar type="carddav">

The type property specifies the wire protocol that this server uses. See section type below.
<incomingServer> specifies the server that the mail client retrieves email from and submits changes to. In many protocols, this server is also used for sending email.
<outgoingServer> is used for sending, if <incomingServer> does not support that directly. This is currently used only for SMTP in combination with IMAP and POP3.
<incomingServer> and <outgoingServer> are within element <emailProvider>, whereas <calendar>, <addressbook>, <fileShare>, <chatServer> and <videoConference> are within the root element <clientConfig>, i.e. one level higher. Other than that, they work the same.
In some protocols, the <incomingServer> server additionally provides calendars, addressbooks, and other data. For such protocols, the same server is not repeated in other specific server sections like <calendar>. Calendar-only clients supporting such multi-purpose protocols MUST read the <incomingServer> (nonewithstanding that it's within legacy element <emailProvider>) and test and use the parts of the protocol needed for their functionality.

Multiple server sections Server sections of the same type (like <incomingServer> or <calendar>) may appear multiple times in the same config file. In this case, the one listed first is preferred by the config provider. Unless the client has specific other requirements, it SHOULD pick the first config. The client may derivate from this recommendation, because * the client doesn't support a higher-priority protocol, e.g. a JMAP configuraion is listed first and is the most preferred, but the client does not support JMAP yet, or * the client doesn't support a configuration setting, e.g. it doesn't support STARTTLS, or the config specifies only an OAuth2 authentication and the client either doesn't implement OAuth2, or there is a problem in the OAuth2 flow with this provider, or * the client has a specific policy to prefer another configuration, e.g. a STARTTLS config is listed before a direct TLS config, and the client has a policy of preferring direct TLS, or likewise the client prefers IMAP over POP3. Server types, elements and protocols that the client does not support MUST be ignored and the client MUST continue to parse the other server sections, which may contain configs that the client understands and supports. The client ignores the file only if there is no supported and working config found.

type The type property on the server section element specifies the wire protocol that this server uses.

Element	Type	Base	Name	Specification
incomingServer	`jmap`	URL	JMAP	RFC 8620, RFC 8621, RFC 8887, RFC 9610 et al
incomingServer	`imap`	TCP	IMAP	RFC 9051 or RFC 3501, et al
incomingServer	`pop3`	TCP	POP3	RFC 1939, RFC 5034
outgoingServer	`smtp`	TCP	SMTP	RFC 5321, RFC 2822
calendar	`caldav`	URL	CalDAV	RFC 4791
addressbook	`carddav`	URL	CardDav	RFC 6352
fileShare	`webdav`	URL	WebDAV	RFC 4918
chatServer	`xmpp`	URL	XMPP	RFC 6120, RFC 6121, RFC 7395
chatServer	`xmpptcp`	TCP	XMPP	RFC 6120, RFC 6121
chatServer	`matrix`	URL	Matrix	https://spec.matrix.org
setupServer	`managesieve`	TCP	ManageSieve	RFC 5804, RFC 5228
incomingServer	`ews`	URL	Exchange Web Services
incomingServer	`activeSync`	URL	ActiveSync
incomingServer	`graph`	URL	Microsoft Graph

Other protocol names can be added using an IANA registry. See the corresponding section below.

URL-based protocols E.g. https://jmap.example.com/session http-basic %EMAILADDRESS% ]]> For server sections with protocols that are based on HTTPS or other URLs, the following elements are supported:

url E.g. <url>https://jmap.example.com/session</url> The content of the <url> element contains the URL where to contact the server. The URL scheme will normally be HTTPS and the URL start with https://. Some protocols may use other schemes, e.g. WebSockets wss://.

authentication E.g. <authentication>http-basic</authentication> The content of the <authentication> element defines which HTTP authentication method to use.

http-basic: Authenticate to the HTTP server using WWW-Authenticate: Basic. See RFC 7617.
http-digest: Authenticate to the HTTP server using WWW-Authenticate: Digest. See RFC 7616
OAuth: Authenticate to the HTTP server using WWW-Authenticate: Bearer. See RFC 6750 Section 3. The provider MUST adhere to the requirements defined in section OAuth2 in this specification.

The rules as specified in sections "Multiple authentication alternatives" and "Authentication verification and fallback" apply here as well.

username E.g. <username>%EMAILADDRESS%</username> or <username>fred</username> The username to use for the authentication method. Placeholders MUST be replaced before using the actual value. See section "Placeholders".

TCP-based protocols For server sections with protocols that are based on TCP, the following elements are supported: imap.example.com 993 SSL password-cleartext %EMAILADDRESS% ]]>

hostname E.g. <hostname>imap.example.com</hostname> The content of the <hostname> element contains the fully qualified hostname of the server.

port E.g. <port>993</port> The content of the <port> element is an integer and contains the TCP port number at the hostname. The port is typically specific to the combination of the wire protocol and socketType.

socketType E.g. <socketType>SSL</socketType> The content of the <socketType> element specifies whether to use direct TLS, STARTTLS, or none of these.

SSL: Directly contact the TCP port using TLS. TLS version 1.2 or higher SHOULD be used. Higher versions may be required based on security situation, server support, and client policy decisions.
STARTTLS: Contact the TCP port first using an unencrypted plain socket, then upgrade to TLS using the protocol-specific STARTTLS specification. With this configuration, STARTTLS MUST be used and TLS MUST be used after the STARTTLS upgrade. If the upgrade to TLS fails for whatever reason, the client MUST disconnect and MUST NOT try to authenticate. This prevents downgrade attacks that could otherwise steal passwords, user data, and impersonate users.
plain: Unencrypted connection, with neither TLS nor STARTTLS. May be needed for local servers. Deprecated.

TLS validation In all cases where TLS is used, either directly or using STARTTLS, the client MUST validate the TLS certificate and ensure that the certificate is valid for the hostname given in this config. If not, or if the TLS certificate is otherwise invalid, the client MUST either disconnect or MAY warn the user of the dangers and ask for user confirmation. Such fallback with warning and confirmation is allowed only at original configuration and MUST NOT be allowed during normal everyday connection. If the server had a valid TLS certificate during original configuration and the TLS certificate is later invalid during normal connection, the client MUST disconnect. As an exception, if the problem is that the TLS certificate expired recently, the client MAY choose to not consider that a failure during normal connection and MAY use other recovery mechanisms.

authentication E.g. <authentication>password-cleartext</authentication> The content of the <authentication> element defines which authentication method to use. This can be either an authentication defined by the wire protocol, or a SASL scheme, or a successor to SASL.

password-cleartext: Send password in the clear. Uses either the native authentication method defined by the wire protocol (if that is based on plaintext passwords), or a SASL authentication scheme like SASL PLAIN or SASL LOGIN, or a successor.
password-encrypted: An encrypted or hashed password mechanism. Includes SASL CRAM-MD5, DIGEST-MD5 and SCRAM-SHA-256-PLUS. TLS alone by itself does not qualify as "password-encrypted".
NTLM: Legacy Windows login mechanisms NTLM or NTLMv2.
GSSAPI: Kerberos or GSSAPI, a single-signon mechanism based on TCP.
TLS-client-cert: On the SSL/TLS layer, after server request, the client sends a TLS client certificate for the user, possibly after letting the user select confirm it. Uses SASL EXTERNAL scheme.
OAuth: OAuth. SASL OAUTHBEARER (current) or XOAUTH2 (deprecated) or successors. The provider MUST adhere to the requirements defined in section OAuth2 in this specification.
client-IP-address: Server can be used without any explicit authentication, and the client is admitted based on its IP address. This may be the case for some SMTP servers on local networks. Not supported on the Internet. Deprecated, because it breaks mobile devices.

Recommending specific SASL schemes Additionally, a specific SASL scheme may be specified using SASL, a space, and the specific SASL authentication scheme name, e.g. SASL SCRAM-SHA-256-PLUS. In such a case, the server config SHOULD also specify a more generic authentication mechanism as a lower priority alternative. That would make clients use the specific authentication mechanism, if they support it, and other clients will use the more generic authentication mechanism.

Multiple authentication alternatives The <authentication> element may appear multiple times within a server section. In this case, they are ordered from the most to the least preferred method, based on the policy of the provider. If a client does not support a specific authentication scheme, or does not have the conditions to use it, e.g. the client does not have a Client ID for this OAuth2 server, then the client MUST skip this <authentication> element and use the next in the list instead. If none of the authentication methods are supported by the client, the client MUST ignore that server section and use the remaining server sections.

Authentication verification and fallback The client SHOULD test the configuration during setup, with an actual authentication attempt. If the authentication fails, the client decides based on the authentication error code how to proceed. E.g. if the authentiocation method itself failed, or the error code indicates a systemic failure, the client SHOULD use a lower-priority authentication method from the list. If the authentication method is working, but the error code indicated that the username or password was wrong, then the client MAY ask the user to correct the password. For that reason, the server SHOULD be specific in the error codes and allow the client to distinguish between

an unsupported or non-working authentication method or other systemic failures
the client being rejected by the server
the user being blocked from login
the user authentication failing due to wrong password or username
other reasons

If the server were to return the same error code for all these cases, the client might tell the user that the password is wrong, and the user starts attempting other passwords, potentially revealing passwords to other higher-value assets, which is highly dangerous. If the authentification succeeded, the client SHOULD take note of the working configutation and use that for all subsequent connections, until an explicit reconfiguration occurs. During normal everyday operation, the client SHOULD NOT fallback nor attempt multiple different authentication methods.

Placeholders The <username> value may contain placeholders. The following special substrings in the value MUST be replaced by the client, before the value is actually used.

Placeholder	Replace with	Example
`%EMAILADDRESS%`	E-Mail-Address of the user	`fred@example.com`
`%EMAILLOCALPART%`	Part before `@` in the E-Mail-Address	`fred`
`%EMAILDOMAIN%`	Part after `@` in the E-Mail-Address	`example.com`

Some clients MAY also support the same placeholders for the fields <hostname>, <url>, <authURL>, <tokenURL>, <issuer>, <displayName> and <displayShortName>.

XML validation The client SHOULD validate that the config file is valid XML, and if the XML syntax is invalid, the client SHOULD ignore the entire file. In contrast, if there are merely unknown elements or properties, the client MUST NOT ignore the file. The client SHOULD read only the elements and attributes that are supported by the client, and MUST ignore the others that are unknown to the client. The client may optionally want to validate the XML before parsing it. This is not required. If the client choses to validate, the validation MUST ignore unknown elements and properties and MUST NOT drop or ignore a configuration that contains unknown elements and properties. This is required to allow future extensions of the format without breaking existing clients.

Config retrieval by mail clients The mail client application, when it needs the configuration for a given email address, will perform several steps to retrieve the configuration from various sources. The steps are ordered by priority. They may all be requested at the same time, but a higher priorty result that is available SHOULD be preferred over a lower priority one, even if the lower priority one is available earlier. Exceptions apply when a higher priority result is either invalid or outdated, or the fetch method is less secure. Lower priority requests MAY be cancelled, if a valid higher priority result has been successfully received. The priority is expressed below with the number before the URL or location, with lower numbers meaning higher priority, e.g. 1.2 has higher priority than 4.1. In the URLs below, %EMAILADDRESS% shall be replaced with the email address that the user entered and wishes to use, and %EMAILDOMAIN% shall be replaced with the email domain extracted from the email address. For example, for "fred@example.com", the email domain is "example.com", and for "fred@test.cs.example.net", the email domain is "test.cs.example.net". For full support of this specification, all "Required" and "Recommended" mechanisms MUST be implemented and working. For partial support of this specification, all "Required" mechanisms MUST be implemented and working, and in this case, you shall make explicit when advertizing or referring to auto config that there is only partial support of this specification.

Mail provider First step is to directly ask the mail provider and allow it to return the configuration. This step ensures that the protocol is decentralized and the mail provider is in control of the configuration issued to mail clients.

1.1. https://autoconfig.%EMAILDOMAIN%/mail/config-v1.1.xml?emailaddress=%EMAILADDRESS% (Required. emailaddress is Optional)
1.2. https://%EMAILDOMAIN%/.well-known/autoconfig/mail/config-v1.1.xml (Optional)
1.3. http://autoconfig.%EMAILDOMAIN%/mail/config-v1.1.xml (Optional)

For example:

1.1. https://autoconfig.example.com/mail/config-v1.1.xml?emailaddress=fred@example.com
1.2. https://example.com/.well-known/autoconfig/mail/config-v1.1.xml
1.3. http://autoconfig.example.com/mail/config-v1.1.xml

Step 1.3. is mainly for legacy servers. Many current deployments use this HTTP URL.

Customzing the config for a specific user To allow the mail provider to return a configuration adjusted for that mailbox, the client sends the email address as query parameter in URL 1.1. This allows the mail provider to e.g. separate mailboxes on geographically local mail servers, e.g. a mail server located in the same office building where an employee works. However, while the protocol allows for such heterogenous configurations, mail providers are discouraged from doing so, and are instead encouraged to provide one single configuration for all their users. For example, DNS resolution based on location, mail proxy servers, or other techniques as necessary, can be used to route the traffic and host the mail efficiently. This mechanism also allows the autoconfig server to map the email address to a username that cannot be expressed using the Placeholders (see section). However, this method is discouraged. Instead, the email server login should accept email addresses as username, and doing the mapping to internal usernames at login time, which avoids the need for the client to know a different username. To avoid that email addresses can be tested for validity, whenever customized configs are returned, the autoconfig server should respond to non-existing email addresses with a configuation that appears to be real and is similar in structure to real configurations, e.g. a random host out of the pool of actual hosts.

Central database The ISPDB contains the configurations for most mail providers with a market share larger than 0.1%, and contains configurations for half of the email accounts in the world. This is a useful fallback for mail providers which do not host a config server described in the previous step. Using a central database (ISPDB) of mail configurations for the large mail providers will increase the success rate of finding a valid configuration drastically, up to 10-fold. The mail client application may choose the mail config database provider. A public mail config database is available at base URL https://v1.ispdb.net/. %ISPDB% below is the base URL of that database.

2.1. %ISPDB%%EMAILDOMAIN% (Recommended)

For example:

2.1. https://v1.ispdb.net/geologist.com

MX Many companies do not maintain their own mail server, but let their email be hosted by a hosting company, which is then responsible for the email of dozens or thousands of domains. For these hosters, it may be difficult to set up the configuration server (step 1.1.) with valid TLS certificate for each of their customers, and to convince their customers to modify their root DNS specifically for autoconfig. On the other side, the ISPDB can only contain the hosting company and cannot know all their customers. To handle such domains, the protocol first needs to find the server hosting the email. If the previous mechanisms yield no result, the client SHOULD perform a DNS MX lookup on the email domain, and retrieve the MX server (incoming SMTP server) for that domain. Only the highest priority MX hostname is considered. From that MX hostname, 2 values are extracted:

Extract only the second-level domain from the MX hostname, and use that as value for %MXBASEDOMAIN%. To determine the second-level domain, use the Public Suffic List or a similarly suited method, to correctly handle domains like ".co.uk" and ".com.au".
Remove the first component from the MX hostname, i.e. everything up to and including the first ., and use that as value for %MXFULLDOMAIN%. Use it only if it is longer than %MXBASEDOMAIN%.

For example:

For "mx.example.com", the MXFULLDOMAIN and MXBASEDOMAIN are both "example.com".
For "mx.example.co.uk", the MXFULLDOMAIN and MXBASEDOMAIN are both "example.co.uk".
For "mx.premium.europe.example.com", the MXFULLDOMAIN is "premium.europe.example.com" and the MXBASEDOMAIN is "example.com".

Then, attempt to retrieve the config for these MX domains, using the previous methods:

3.1. https://autoconfig.%MXFULLDOMAIN%/.well-known/mail-v1.xml?emailaddress=%EMAILADDRESS% (Required)
3.2. https://autoconfig.%MXBASEDOMAIN%/.well-known/mail-v1.xml?emailaddress=%EMAILADDRESS% (Recommended)
3.3. %ISPDB%%MXFULLDOMAIN% (Recommended)
3.4. %ISPDB%%MXBASEDOMAIN% (Recommended)

For example:

3.1. https://autoconfig.premium.europe.example.com/.well-known/mail-v1.xml?emailaddress=fred@example.com
3.2. https://autoconfig.example.com/.well-known/mail-v1.xml?emailaddress=fred@example.com
3.3. https://v1.ispdb.net/premium.europe.example.com
3.4. https://v1.ispdb.net/example.com

Local disk For testing purposes, you may want to define a location on the disk, relative to the application installation directory, or relative to the user configuration directory, which may contain a configuration file for a specific domain, and which your application will use, if the above methods fail.

4.1. %USER_CONFIGURATION_DIR%/isp/%EMAILDOMAIN%.xml (Optional)
4.2. %APP_INSTALL_DIR%/isp/%EMAILDOMAIN%.xml (Optional)

For example:

4.1. /home/fred/.config/yourapp/isp/example.com.xml
4.2. /opt/yourapp/isp/example.com.xml

Other mechanisms You may want to implement other mechanisms to find a configuration, for example Exchange AutoDiscover, DNS SRV, or heuristic guessing. If you implement such alternative methods, and if they are less secure than some of the mechanisms provided here, the alternative methods SHOULD be considered only with lower priority (as defined above) than the more secure mechanisms defined here. For evaluating other mechanisms, use similar criteria as outlined in section "Security considerations".

Manual configuration If the above mechanisms fail to provide a working configuration, or if the user explicitly chooses so, you SHOULD give the end user the ability to manually enter a configuration, and use that configuration to configure the account.

Config validation

User approval Independent of the mechanisms used to find the configuration, before using that configuration, you SHOULD display that configuration to the end user and let him confirm it. While doing so:

At least the second-level domain name(s) of the hostnames involved MUST be shown clearly and with high prominence.
The client MUST NOT cut off parts of long second-level domains, to avoid spoofing. At least 63 characters MUST be displayed.
Care SHOULD be taken with international characters that look like ASCII characters, but have a different code.

Login test After the user confirmed the configuration, you SHOULD test the configuration, by attempting a login to each server configured. Only if the login succeeded, and the server is working, should the configuration be saved and retrieving and sending mail be started.

OAuth2 windows If the configuration contains OAuth2 authentication, or any other kind of authentication that uses a web browser with URL redirects, you MUST show the full URL or the second-level domain of the current page to the end user, at all times, including after page changes, URL changes, or redirects. The authentication start URL may be the email hoster, but it redirects to a corporate server for login, and then back to the hoster. This allows for setups where the hoster is not allowed to see the plaintext passwords. Showing the URL or hostname allows the end user to verify that he is logging in at the expected page, e.g. the login server of their company, instead of the email hoster's page. It is important that the user verifies that he enters the passwords on the right domain.

Config publishing by mail providers Mail service providers who want to support this specification and publish the mail configuration for their own mail service, so that mail client apps can be automatically configured, SHOULD follow this section as guideline and MUST respect the definitions in this specification.

Configuration fields MUST NOT contain invalid or non-working configuration data.
The provided configuration MUST be working, and SHOULD use state-of-the-art security.
Configurations MUST be public and MUST NOT require authentication (see below).

Config location for single domain The configuration file SHOULD be published at the URL for step 1.1., i.e.

https://autoconfig.%EMAILDOMAIN%/.well-known/mail-v1.xml?emailaddress=%EMAILADDRESS%

e.g. for fred@example.com

https://autoconfig.example.com/.well-known/mail-v1.xml?emailaddress=fred@example.com

For backwards compatibility with older mail clients, step 1.2. should also be implemented.

Config location for domain hosters For mail providers which host entire domains for their business customers, the same URL as listed in the previous section is preferred. Alternatively, the configuration file SHOULD be published at the location for step 3.1., i.e.

https://autoconfig.%MXFULLDOMAIN%/.well-known/mail-v1.xml?emailaddress=%EMAILADDRESS%

E.g. if the MX server for customer domain example.net is "mx.premium.europe.example.com", then the config file should be at

https://autoconfig.premium.europe.example.com/.well-known/mail-v1.xml?emailaddress=fred@example.net

For backwards compatibility with older mail clients, step 3.2. should also be implemented.

Return config for non-existing email addresses Servers SHOULD return a valid config, even if the email address sent as URL parameter does not exist. Otherwise, spammers or attackers would be able to test the validity of email addresses. This is true even if the config server needs the email address to determine which of multiple configurations is correct. In such a configuration, if the client sends a non-existing email address, the config server SHOULD return one of the valid configuations, so that valid and invalid email addresses are indistiguishable.

No authentication for config Any of the above URLs for retrieving the config file MUST NOT require authentication, but MUST be public. This is because the config contains the authentication method. Without knowing the config, the client does not know which authentication method is required and which username form (e.g. username "fred" or "fred@example.com" or "fred\EXAMPLE") to use. Given that the config is required for authentication, the config itself cannot require authentication.

OAuth2 requirements If OAuth2 is used, the provider MUST adhere to the "Open Profile for Public Clients" or mAuth specification. The OAuth2 server MUST either accept the public client ID as given in the config file, without secret, or MUST allow the string open as client ID, or both. The server MUST NOT employ any other methods to block clients that are acting on behalf of users. The specifications also contain requirements for expiry times and the login page, which are needed for mail client applications to work. The OAuth2 scope MUST include all services defined in this config file. The same refresh and access token MUST be valid for all services defined in the same config file, including for all URL-based protocols like CalDAV and all TCP-based protocols like IMAP.

Alternatives considered

DNSSEC Due to their top-level domain, some domains do not have DNSSEC available to them, even if they would like to deploy it. Even where the top-level domain supports it, DNSSEC is currently deployed in only 1% of domains, with adoption rates falling instead of rising, due to the difficulties of administrating it correctly. Therefore, DNSSEC cannot be relied on in this specification, and DNS must be considered insecure for the purposes of this specification.

DNS SRV DNS SRV protocols (RFC 2782, RFC 6186) are not used here, for 2 reasons:

DNS SRV relies on insecure DNS and the config can therefore be trivially spoofed by an attacker. See also DNSSEC above.
DNS SRV does not provide all the necessary configuration parameters. For example, we need all of:

the username form ("fred@example.com", or "fred", or "fred\EXAMPLE", or even a username with no relation to the email address)
authentication method (password, CRAM-MD5, OAuth2, SSL client certificate)
authentication method parameters (e.g. OAuth parameters)

and other parameters. If any of these parameters are not configured right, the configuration won't work. While these parameters could theoretically be added to DNS SRV, that would mean a new specification and render the idea void that this is a protocol that already exists, is standardized and deployed. It is unlikely that all DNS SRV records would be updated with the new values. Therefore, it does not solve the problem. This specification was created as an answer to these deficiencies and provides an alternative to DNS SRV.

CAPABILITIES Deployments in the wild from actual ISPs show that protocol-specific commands to find available authentication methods, e.g. IMAP CAPABILITIES or POP3 CAPA, are not reliable. Many email servers advertize authentication methods that do not work. Some IMAP servers are default configured to list all SASL authentication methods that have corresponding libraries installed on the system, independent on whether they are actually configured to work. The client receives a long list of authentication methods, and many of them do not work. Additionally, the server response may be only "authentication failed" and may not indicate whether the method failed due to lack of configuration, or because the password was wrong. Because some authentication servers lock the account after 3 failed login attempts, and it may also fail due to unrelated reasons (e.g. username form, wrong password, etc.), the client cannot blindly issue countless login attempts. Locking the account must be avoided. So, simply attempting all methods and seeing which one works is not an option for the email client. Additionally, some email servers advertize Kerberos / GSSAPI, but when trying to use it, the method fails, and also runs into a long 2 minute timeout in some cases. End users consider that to be a broken app. Additionally, such commands are protocol specific and have to be implemented in multiple different ways. Finally, some non-mail protocols may not support capabilties commands that include authentication methods.

Security Considerations

Risk If an attacker can provide a forged configuration, the provided mail hostname and authentication server can be controlled by the attacker, and the attacker can get access to the plain text password of the user. The attack can be implemented as man-in-the-middle, so the end user might receive mail as expected and never notice the attack. An attacker gaining the plain text password of a real user is a very significant threat for the organization, not only because mail itself can contain sensitive information and can be used to issue orders within the organization that have wide-ranging impact, but given single-sign-on solutions, the same username and password may give access to other resources at the organization, including other computers or, in the case of admin users, even adminstrative access to the core of the entire organization. Multi-factor authentication might not defend against such attacks, because the user may believe to be logging into his email and therefore comply with any multi-factor authentication steps required.

DNS Any protocol that relies on DNS without further validation, e.g. http, should be considered insecure. This also applies to the DNS MX lookup and the https calls that base on its results, as described in section "MX". One possible mitigation is to use multiple different DNS servers and verify that the results match, e.g. to use the native DNS resolver of the operating system, and additionally also query a hardcoded DoH (DNS over HTTPS) server. Nonetheless, the result should be used with care. If such configs are used, the end user MUST explicitly confirm the config, particularly the resulting second-level domains. See section "User approval".

HTTP HTTP requests may be intercepted, redirected, or altered at the network level. See "Risk" above. Even if an http URL redirects to a https URL, and the domain of the https URL cannot be validated against the email domain, that is still insecure. For that reason, clients MUST prefer HTTPS over HTTP during config retrieval, within the same retrieval method. If such configs from HTTP are used, the end user MUST explicitly confirm the config, particularly the resulting second-level domains. See section "User approval".

Config updates Part of the security properties of this protocol assume that the timeframe of possible attack is limited to the moment when the user manually sets up a new mail client. This moment is triggered by the end user, and a rare action - e.g. maybe once per year or even less, for typical setups -, so an attacker has limited chances to run an attack. While not a complete protection on its own, this reduces the risk significantly. However, if the mail client does regular configuration updates using this protocol, this security property is no longer given. For regular configuration updates, the mail client MUST use only mechanisms that are secure and cannot be tampered with by an active attacker. Furthermore, the user SHOULD still approve config changes. But even with all these protections implemented, the mail client vendor should make a security assessment for the risks of making such regular updates. The mail client vendor should consider that servers can be hacked, and most users simply approve changes proposed by the app, so these give only a limited protection.

Server security Given that mail clients will trust the configuration, the server delivering the configuration file needs to be secure. A static web server offers better security. The server software SHOULD be updated regularly and hosted on a dedicated secure server with all unnecessary services and server features turned off. For the ISPDB, additions and modifications to the configurations are applicable to all respective users and must be made with care. The authenticity of the configuration MUST be verified from authorative sources. Server hostnames MUST be compared with the email domain names they are serving, and if they differ, the ownership of the server hostnames MUST be validated. The risk is mitigated to some degree by section "User approval".

IANA Considerations

Registration IANA will create the following registry in a new registry group called "Mail Autoconfig": Registry Name: "Autoconfig Protocol Type Names" Registration Procedure: Specification Required, per RFC 8126, Section 4 Designated Expert: The author of this document.

Contents Table, with fields Element (alphanumeric), Type (alphanumeric), Base (URL or TCP or URL/TCP), Name, Specification, and Additional Elements The registrations need to define:

Element: The XML element wrapping the server section.
Type: The type property value of the server section.
Base: Whether the protocol is URL-based or TCP-based,
Name: The commonly used name of the protocol
Specification: Which RFCs or document specifies the protocol, and
Additional Elements: (Optional) Protocol-specific XML elements and their meaning.

Initial registration

Element	Type	Base	Name	Specification
incomingServer	`jmap`	URL	JMAP	RFC 8620, RFC 8621, RFC 8887, RFC 9610 et al
incomingServer	`imap`	TCP	IMAP	RFC 9051 or RFC 3501, et al
incomingServer	`pop3`	TCP	POP3	RFC 1939, RFC 5034
outgoingServer	`smtp`	TCP	SMTP	RFC 5321, RFC 2822
calendar	`caldav`	URL	CalDAV	RFC 4791
addressbook	`carddav`	URL	CardDav	RFC 6352
fileShare	`webdav`	URL	WebDAV	RFC 4918
chatServer	`xmpp`	URL	XMPP	RFC 6120, RFC 6121, RFC 7395
chatServer	`xmpptcp`	TCP	XMPP	RFC 6120, RFC 6121
chatServer	`matrix`	URL	Matrix	https://spec.matrix.org
setupServer	`managesieve`	TCP	ManageSieve	RFC 5804, RFC 5228
incomingServer	`ews`	URL	Exchange Web Services
incomingServer	`activeSync`	URL	ActiveSync
incomingServer	`graph`	URL	Microsoft Graph

The Additional Elements field is empty in all of the initial values.

Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.