IETF Mail AutoConfig draft adds OAuth endpoint security checks
News
The IETF MAILMAINT working group's Mail AutoConfig revision 07 adds proposed OAuth endpoint security checks and changes the preferred configuration discovery location. The important addition is section 5.4: a client must consider both the authorization endpoint and the token endpoint before trusting an automatically discovered setup. This remains an Internet-Draft, not a final standard, not an RFC, and not current production guidance.
The official publication event records November 2, 2026 at 17:47:39 UTC, which is November 3 at 04:47:39 AEDT in Australia/Sydney. This is a material revision of an already adopted working-group draft, not a new adoption. I treat it as a development and security review item for mail-client developers, hosting operators, mailbox providers, and security teams.
Revision 07 establishes no provider rollout, deployment deadline, or current sender requirement. The endpoint scenario is a security rationale for the proposal, not a report of a confirmed breach.
What section 5.4 proposes for OAuth endpoints
Automatic configuration supplies information that a mail client uses to connect an account. With OAuth, that information can include an issuer and endpoint URLs. The authorization endpoint handles the browser-based authorization flow. The token endpoint receives the client's subsequent request to exchange an authorization code for tokens. Those are separate trust decisions, even when the user experiences one login.
The new section 5.4 permits endpoint discovery through RFC 8414 authorization-server metadata or OpenID Connect issuer metadata, direct use of configured authURL and tokenURL values, or a combination. Metadata requires issuer consistency. Combining metadata with configured endpoints requires consistency checks rather than silently accepting conflicting information.
|
|
|
|---|---|---|
Issuer metadata | RFC 8414 or OIDC | Issuer consistency |
Configured URLs | authURL and tokenURL | Both endpoint domains |
Combined sources | Metadata and URLs | Source consistency |
Endpoint sources described by the draft proposal.
The proposed domain check covers both endpoint domains against the email-address domain or server domain. If an OAuth domain does not match, the client must show that domain while the user approves the servers, or abort configuration. Checking only the authorization URL leaves the token destination outside that review.
Issuer consistency and domain review answer different questions. Issuer checking establishes that metadata belongs to the expected issuer. Domain review exposes an OAuth destination outside the expected account or server domains. A client implementing the proposal needs to preserve both checks; one does not substitute for the other.
For an implementation review, record the expected issuer and the source of each endpoint before starting authorization. Test metadata alone, configured URLs alone, and combined inputs. In the combined case, include conflicting values in the test fixtures instead of testing only agreement. A valid TLS certificate authenticates the hostname being contacted; it does not establish that the hostname is an appropriate token destination for the account being configured. Endpoint ownership still needs review.
Why a genuine login page does not validate tokenURL
A forged configuration can point authURL at the genuine authorization service while setting tokenURL to a malicious endpoint. The user sees the real login page and completes a legitimate authorization flow. After the client receives the authorization code, it sends its token-exchange request to the separately configured tokenURL. The malicious endpoint then receives the valid code.
The code is sent by the client during the exchange, rather than becoming safe because the browser displayed a familiar domain. I would review that destination before allowing the exchange. The scenario explains the proposed check without establishing that a particular provider is affected or that a successful account takeover occurred.
Authorization endpoint
The user visits this endpoint during authorization. A genuine page establishes where that interaction happens. It does not establish who controls a separately configured token endpoint.
Token endpoint
The client sends the code exchange here after authorization. Its domain needs its own trust check before the client transmits the code, even after a genuine login.
Different hostnames are not evidence of an attack by themselves. An organization can use a separate identity domain, and authorization and token services can have different hostnames. The security issue is whether their ownership and relationship are established, with unexpected domains exposed for approval or configuration stopped.
A useful test therefore includes a legitimate cross-domain arrangement as well as a hostile token destination. The client should explain the unfamiliar OAuth domain at the server approval stage. A vague login-success message does not provide the information needed for that decision.
The discovery URL also changes
Section 4.1 now proposes a required discovery location under the autoconfig subdomain: /.well-known/client-autoconfig.xml, retrieved over HTTPS with a valid TLS certificate. The emailaddress query parameter remains optional. Clients can retrieve the required location without including an email address.
The former /mail/config-v1.1.xml location and /.well-known/autoconfig/mail/config-v1.1.xml variant remain deprecated-but-deployed fallbacks. They are not abolished immediately. The draft's required and deprecated labels describe implementation of this proposal; they do not impose an immediate migration mandate on every existing provider or client.
Proposed discovery location and deployed fallback templatestext
# Proposed required URL, without the optional query https://autoconfig.%EMAILDOMAIN%/.well-known/client-autoconfig.xml # Optional query string to append to the required URL ?emailaddress=%EMAILADDRESS% # Deprecated, deployed fallbacks https://autoconfig.%EMAILDOMAIN%/mail/config-v1.1.xml https://%EMAILDOMAIN%/.well-known/autoconfig/mail/config-v1.1.xml
For operators evaluating future support, the practical inventory includes the hostname serving configuration, certificate coverage for that hostname, and the paths existing clients request. A working older endpoint does not establish that the proposed new path is available. Test that separately without removing a working service.
Which safeguards were already in revision 06
Section 5.3 already required display of the current authorization-page URL or domain through page changes and redirects in revision 06. The new endpoint checks extend the security discussion beyond what the user sees in the browser. They should not be reported as the first requirement to display an OAuth login destination.
Address-enumeration mitigation also predates revision 07. A configuration service that customizes responses by email address should avoid revealing whether a mailbox exists. Returning an obvious error only for nonexistent addresses exposes that distinction. This is separate from deciding whether a token endpoint is trustworthy.
That distinction matters when reviewing implementation work: retain the earlier display and enumeration safeguards, then assess the new endpoint validation and discovery-path changes. A revision review should identify the added behavior precisely rather than relabeling every security paragraph as new.
What developers and operators should test next
I would start with isolated implementations and test accounts. Compare revisions 06 and 07 against the client's actual setup flow, including the point where servers are approved and the point where the authorization code is transmitted. A configuration parser accepting the new location is only one part of that work.
Keep existing working clients and services in place while evaluating the proposal. The useful outcome now is a documented set of trust decisions and compatibility tests, with ownership questions resolved before any future adoption.
- Compare revisions: Review sections 4.1 and 5.4 against revision 06 in a controlled implementation.
- Verify ownership: Establish who controls each OAuth endpoint and validate metadata issuer matching.
- Exercise decisions: Test approval and abort paths for unexpected domains, including a genuine login with a hostile tokenURL.
- Inventory discovery: Check existing URL use, proposed path availability, and valid TLS certificate coverage.
- Preserve safeguards: Retest authorization URL display and address-enumeration behavior alongside the new checks.
Include cases where only the authorization domain is unfamiliar, only the token domain is unfamiliar, and both are unfamiliar. Confirm that rejecting an unexpected domain stops the setup before any code exchange. For an approved cross-domain setup, confirm that the destination used for the exchange is the destination reviewed by the user. These are practical test cases for evaluating the proposal, rather than an announcement that deployed clients already implement its behavior. Keep test logs free of authorization codes and tokens.
Keep deployed email authentication healthy
This draft concerns account configuration and OAuth endpoint trust. It does not change bulk sender authentication requirements. SPF, DKIM, and DMARC do not protect OAuth authorization codes. Continue checking deployed authentication with a domain health check and send a real message through the email tester when validating message authentication after operational changes. Neither check validates this proposed OAuth flow.
Our DMARC platform, Suped, supports the separate operational work of reviewing sending sources and diagnosing authentication failures through DMARC monitoring. Use that evidence to keep legitimate sending healthy while development teams evaluate the AutoConfig draft. Any future implementation decision should follow review of endpoint trust and discovery compatibility, with existing services kept working during evaluation.
Frequency asked questions
No. It is a revision of an already adopted MAILMAINT working-group Internet-Draft. It is not final and is not current production guidance.
The client sends the authorization code to tokenURL during the exchange. A genuine authorization page does not establish that a separately configured token endpoint is trustworthy.
No. Different hostnames have legitimate uses. The proposal checks both endpoint domains and requires an unmatched OAuth domain to be shown during server approval, or configuration to abort.
No. Older paths remain deprecated-but-deployed fallbacks in the proposal. Revision 07 does not announce an immediate migration requirement for every existing provider or client.
