[mailmaint] Re: autoconfig consensus points

[Michel Le Bihan <[e-mail]>]

Hi all,

I have to admit I'm struggling to understand what publishing both autoconfig and PACC as IETF documents would actually achieve. If the outcome is essentially "here is autoconfig, but please don't use it, use PACC instead", I don't see how that helps PACC succeed in practice.

Existing autoconfig implementers will have little reason to migrate if autoconfig still carries the IETF's stamp of approval right alongside PACC. Also, why would a new implementer take on PACC, with the extra complexity that comes with it, when a simpler, already widely deployed alternative sits right next to it with the same official status?

Best,
Michel Le Bihan

Le 30/07/2026 à 04:23, Neil Jenkins a écrit :
> On Thu, 30 Jul 2026, at 07:13, Ben Bucksch wrote:
>> 
>>     or someone man-in-the-middle's the autoconfig on public WiFI (as
>>     it allows non-HTTPS fetch), you could return a malicious autoconfig
>> 
>> AutoConfig has a number of mitigations for that:
>> 
>>  *
>> 
>>     To defend against evil local routers and DNS servers, the spec
>>     recommends the MUA to make 2 independent DNS lookups, e.g. one
>>     via local DNS resolver and one via DNS over HTTPS (e.g. Quad9,
>>     CloudFlare, Google) or from the MUA vendor's datacenter. To
>>     prevent downgrade attacks, if that DoH check fails, the whole
>>     setup should abort with "Insecure network" or similar.
>> 
> 
> Yes, this helps against DNS poisoning, although not against HTTP fetch.
> 
>>  *
>> 
>>     Timing and frequency: How often do you set up your primary email
>>     account? Not a strong defense in itself, but reduces risk
>>     drastically.
>> 
> 
> If the autoconfig is also polled for updates, this would increase the likelihood a lot of course.
> 
>>  *
>> 
>>     The MUA is required to show the server domains to the end user
>>     and have him explicitly review and approve it,
>> 
> 
> Realistically this is unlikely to help much; the percentage of users that will check at all, let alone notice (especially in the case of similar domains) is negligible. It doesn't hurt, but it's not a meaningful protection.
> 
>> I've never heard of a single successful attack in 15+ years, i.e. 0 exploits.
>> 
> 
> I think it's highly unlikely you personally would have ever heard if there had been. This is not a meaningful security argument.
> 
>> If the attacker does manage to place his malicious config /and/ gets the user to approve it, then it's game over anyways - and if I'm not overlooking something, the same would happen with PACC
>> a) the config returns password based auth, user logs in to attacker server, game over. Or
>> b) the config returns the attacker's issuer, OAuth2 server, and MITM the whole OAuth process.
> 
> PACC + the Open OAuth profile differ in several significant ways:
> 
>   * The requirements for fetching it make it much more difficult for
>     an attacker to get a malicious config to the user. Local DNS
>     poisoning would not be sufficient, as they still wouldn't be able
>     to get the SSL cert they would need to serve the autoconfig file.
>     This also rules out HTTP interception, as SSL is mandatory.
>   * In the case of a typo-ed domain, you could of course get served a
>     malicious config. This could just be configured for password based
>     auth, and you're right that the user might well just put in their
>     password into the app then. However, more and more services are
>     moving to a password on its own not being enough, because they are
>     so phishable etc. So this would force the config to try to do
>     OAuth. At this point, there is significant difference:
>       o With autoconfig, you use any of the mix up attacks to present
>         the real service login page, then steal the authorisation
>         code. The user cannot tell they are being phished.
>       o With the Open OAuth Profile:
>           + The issuer identification and resource indicators prevent
>             the access token from being sent to malicious servers, so
>             you can't do that mix up attack.
>           + The issuer identification also prevents the mix up attack
>             where you are given the real authorization endpoint and
>             resource servers, but the attackers own token endpoint.
>           + So the only thing left the attacker can try is a phishing
>             page hosted on their own website. This is much less likely
>             to succeed:
>               # The Safe Browsing list can list it and prevent it from
>                 being accessible in all modern browsers as soon as
>                 it's found.
>               # Password managers will not autofill because the origin
>                 is wrong
>               # Passkeys will flat out not work due to the incorrect
>                 origin, completely preventing any attack.
> 
> 
>>> So if the user typos their email address,
>> That's not really an "attack", because it's initiated by the user. There's not much we can do here: garbage in, garbage out.
> 
> Err… that's probably the most likely general attack. Relying on users to be perfect for security is, like, the number one security fallacy? One of the reasons that more and more services are deprecating password authentication and requiring OAuth is so you /can/ add meaningful protection for this.
> 
>>     with the legitimate "authURL" but a malicious "tokenURL". The
>>     user would then be prompted to complete login at their real
>>     provider's website, after which the client would send the
>>     authorization code to the attacker, giving them access.
>> 
>> That's a good one, thanks for raising that. We could easily require that the hostname for both URLs must be the same.
>> 
> 
> But … this is getting into changing the document again rather than documenting what is specifically implemented right now? And if you're changing it, you'd adopt the standardised solution like we have in our standards-track drafts (OAuth server metadata with issuer identification).
> 
>> Possible solution: The MUA should show both OAuth2 domains to the user, if they don't match, in the same screen where the user approves the IMAP, SMTP and OAuth2 server domain.
> 
> That's back to the user can be trusted to verify technical information fallacy.
> 
>>     Or you could return a legitimate authURL and tokenURL but the
>>     attacker's IMAP server — the client will then also happily send
>>     the authorization token to the attacker, allowing them to
>>     silently man-in-the-middle the connection.
>> 
>> That's why the MUA is required to show the domain of the IMAP server.
>> 
> 
> And again.
> 
>> This protocol is very widespread active use, by about a dozen widely different clients, and over 8% of all domains with mail. It's more popular than Exchange AutoDiscover. It's not going to just go away, no matter what we do here.
>> 
> 
> Not many popular clients actually support it though. It's Thunderbird and some rounding errors. Honestly, once Apple adopt PACC I would expect the number to rapidly pass this, given iOS Mail is by several orders of magnitude the most popular email client in the world.
> 
> It seems we still disagree about the fundamental point of publishing this. As I said in my previous email, no new client should implement this spec, as they are opening their users up to security issues and it is not the future. The protocol does not conform with existing IETF best practice. It is useful for server implementers to understand what some existing clients already do.
> 
> The IETF's mission is /to produce high quality, relevant technical and engineering documents that influence the way people design, use, and manage the Internet in such a way as to make the Internet work better./ It does not rubber stamp a document just because it has some existing usage. Encouraging easier, secure autoconfiguration and interoperable OAuth to move away from password auth makes the internet better: PACC + Open OAuth do that. This document could encourage more clients to implement security issues, and lead to confusion about why there are two different "IETF autoconfig standards".
> 
> Cheers,
> Neil.
>