Oauth2 en fetchmail

[Mijzelf]

Zeer binnenkort stopt Microsoft met gebruikersnaam/wachtwoord toegang voor zijn mailservers, het moet dan oauth zijn. Ik heb een aantal e-mail adressen, waaronder een paar van MS, waarvan ik de mail door fetchmail laat ophalen, en bezorgen bij mijn privé mailserver, waardoor ik via 1 webinterface (roundcube) bij al mijn mail kan.

Een van de MS mailadressen is een zakelijk account, die al langer oauth nodig heeft, en daarbij gebruik ik email-oauth2-proxy. Dat werkt. Om het aan de gang te krijgen moest ik een App registreren op dat account, wat me een client-id en client-secret oplevert, waarmee de proxy kan werken voor dat account. Hij haalt nog (met tussenkomst van een browser) een access token op.

Nu dacht ik dezelfde truuk te gebruiken voor mijn ander MS adressen. Maar dat gaat niet op. Om een App te registreren moet ik een Azure account aanmaken, waarbij ik een telefoonnummer moet opgeven voor verificatie. Een hoop hoepels weer.

Wanneer ik Thunderbird gebruik, kan hij gewoon bij mijn mail komen. Dus ik dacht, dan haal ik de client-id en client-secret uit een Thunderbird installatie. De client-id heb ik gevonden, maar de secret niet. Via de 'show password' methode laat hij wel iets zien, maar dat is te lang om de secret te zijn, en te kort voor de access token.

Het lijkt dat Thunderbird iets anders doet dan mijn mail-proxy. Op de een of andere manier haalt hij zelf (wel met tussenkomst van een browser) de secret op, terwijl ik die bij de proxy van een pagina van MS moest kopiëren.

Mijn vragen: Waarom moet ik een App registreren voor de Proxy? Die zou zich toch 'gewoon' als Thunderbird kunnen voordoen en zelf zijn secret ophalen?
Weet iemand of ik die account secret van Thunderbird kan achterhalen?
Weet iemand een andere manier om een headless server de mail te laten ophalen? (Hij draait Debian, als dat er iets toe doet)

[Polderviking]

Als je echt op fetchmail leunt zou ik je mail verhuizen naar een provider waar je gewoon met een wachtwoord kan werken of je mail helemaal zelf doen.

Het zijn m.i. alleen Microsoft en Google die zo absoluut zijn over het gebruik van oauth.

Maintainer van Fetchmail er wel mee bezig is maar het heeft nagenoeg nul prioriteit, overigens ga je daarvoor m.i. nog steeds door die hoepels moeten met het defineren van een app binnen azure en loop je voor je andere adressen nogsteeds vast.

[Killah_Priest]

Kun je geen appreg maken als je inlogt op de Azure portal (met het betreffende MS account)?
Als ik bv met mijn hotmail adres inlog op de portal dan is er een tenant specifiek voor mijn mailadres waarmee ik dus ook appregs aan kan maken enzo (dus de basis dingen binnen Entra).

[Mijzelf]

@Killah_Priest Nee dus. Blijkbaar zijn niet alle MS accounts gelijk. Het gaat hier om hotmail adressen die nog dateren van voor MS hotmail overnam. En ik ben nooit ingegaan op aanbiedingen om de accounts te 'upgraden'.

@Polderviking Op zich werkt die proxy prima, en kan ook SMTP proxien. Verder draai ik nog een pythonscript die de mail weggooit als ouder dan X, en die werkt ook via de proxy. Wat dat betref is het veelzijdiger dan een implementatie in fetchmail.
Maar die hoepels zijn wel een dingetje. Het ontgaat me waarom Thunderbird die niet nodig heeft.

[TommyCP]

Ik ben toevallig met ongeveer hetzelfde bezig. Niet fetchmail, maar wel op zoek naar een manier om een headless server via OAuth2 bij mijn Hotmail-account te laten komen.

Vraagje: hoe weet je dat code die je middels 'show password' uit Thunderbird hebt weten te krijgen geen token is? Je had het over de lengte, maar bij mijn weten is er geen lengte gespecificeerd voor tokens.

[Mijzelf]

Helemaal zeker weet ik het natuurlijk niet, maar in ieder geval is hij niet compatible met de tokens in de proxy.

Ik heb voor 1 account dus een werkende client-secret aangemaakt via de 'Microsoft Entra admin center'. Dat is een string van ongeveer 40 bytes. Vervolgens heeft de proxy (met tussenkomst van een browser) twee tokens opgehaald. In een file zijn een refresh-token en een access-token opgeslagen, de refresh-token is ongeveer 1200 bytes, en de access token ongeveer 2400.

Het password dat Thunderbird laat zien is 420 bytes lang. Dat komt dus niet in de buurt van een van de 3 tokens van de proxy.

[TommyCP]

Ik zat nog te denken dat base64 encoding een verschil in lengte kon verklaren, maar 40 vs 420 bytes is idd een wel erg groot verschil.

Maar ik begrijp dat je er voor iig 1 account uit bent gekomen m.b.v. Azure?

[Sso]

Hallo, interessante post. Ik probeer dit momenteel werkend te krijgen met MS365 en fetchmail om IMAP te syncen. Loop hierbij telkens tegen issue aan. Zou je de Email Proxy en fetchmail.rc config kunnen delen met me? BVD!

[vanaalten]

Sso schreef op vrijdag 22 november 2024 @ 11:54:
Hallo, interessante post. Ik probeer dit momenteel werkend te krijgen met MS365 en fetchmail om IMAP te syncen. Loop hierbij telkens tegen issue aan. Zou je de Email Proxy en fetchmail.rc config kunnen delen met me? BVD!

@Sso Kan je niet beter je eigen config enzo hier plaatsen en beschrijven waar je tegenaan loopt? Dan kunnen mensen hier helpen debuggen en hebben andere mensen met vergelijkbare problemen ook meer aan.

[akimosan]

Ik kan nog steeds app wachtwoorden aanmaken voor mijn private MS account via

How to get and use app passwords - Microsoft Support
en de link/knop naar https://go.microsoft.com/fwlink/?linkid=2274139

[Mijzelf]

@Sso

De relevante delen van de configs. .fetchmailrc:

poll localhost proto POP3 service 1995 uidl                                                                                       
       user '[e-mail]' there with password 'ZeerGeheim' is '[e-mail]' here sslproto '' keep 

emailproxy.config:

[POP-1995]
server_address = outlook.office365.com
server_port = 995
local_address = 127.0.0.1

[[e-mail]]
permission_url = https://login.microsoftonline.com/common/oauth2/v2.0/authorize
token_url = https://login.microsoftonline.com/common/oauth2/v2.0/token
oauth2_scope = https://outlook.office365.com/IMAP.AccessAsUser.All https://outlook.office365.com/POP.AccessAsUser.All https://outlook.office365.com/SMTP.Send offline_access
redirect_uri = http://localhost:10000
client_id = <GUID>
client_secret = <40 karakter secret>

Toen de proxy voor het eerst ging inloggen had ik een portforward gemaakt naar de server met

ssh -L10000:localhost:10000 [e-mail]

zodat ik een browser kon openen op http://localhost:10000. Op de server van Microsoft heb ik, toen ik de client_id registreerde, op de een of andere manier opgegeven dat http://localhost:10000 iets speciaals was.

[Sso]

Dank - ik ga mijn settings nogmaals controleren

[Sso]

Helaas lukt het (met pop3 ipv imap) ook niet. Debug van de proxy:

2024-11-25 07:24:58: New incoming connection to POP server at 127.0.0.1:1993 (unsecured) proxying outlook.office365.com:995 (SSL/TLS)
2024-11-25 07:24:58: Accepting new connection from 127.0.0.1:51920 to POP server at 127.0.0.1:1993 (unsecured) proxying outlook.office365.com:995 (SSL/TLS)
2024-11-25 07:24:58: POP (127.0.0.1:51920-{127.0.0.1:1993}-outlook.office365.com:995) --> [ Client connected ]
2024-11-25 07:24:58: POP (127.0.0.1:51920-{127.0.0.1:1993}-outlook.office365.com:995) <-> [ Starting TLS handshake ]
2024-11-25 07:24:58: POP (127.0.0.1:51920-{127.0.0.1:1993}-outlook.office365.com:995) <-> [ TLSv1.2 handshake complete ]
2024-11-25 07:24:58: POP (127.0.0.1:51920-{127.0.0.1:1993}-outlook.office365.com:995) <-- b'+OK The Microsoft Exchange POP3 service is ready. [QQBTADQAUAAxADgAOQBDAEEAMAAwADQANgAuAEUAVQBSAFAAMQA4ADkALgBQAFIATwBEAC4ATwBVAFQATABPAE8ASwAuAEMATwBNAA==]\r\n'
2024-11-25 07:24:58: POP (127.0.0.1:51920-{127.0.0.1:1993}-outlook.office365.com:995) <-- b'+OK The Microsoft Exchange POP3 service is ready. [QQBTADQAUAAxADgAOQBDAEEAMAAwADQANgAuAEUAVQBSAFAAMQA4ADkALgBQAFIATwBEAC4ATwBVAFQATABPAE8ASwAuAEMATwBNAA==]\r\n'
2024-11-25 07:24:58: POP (127.0.0.1:51920-{127.0.0.1:1993}-outlook.office365.com:995) --> b'CAPA\r\n'
2024-11-25 07:24:58: POP (127.0.0.1:51920-{127.0.0.1:1993}-outlook.office365.com:995) --> b'CAPA\r\n'
2024-11-25 07:24:58: POP (127.0.0.1:51920-{127.0.0.1:1993}-outlook.office365.com:995) <-- b'+OK\r\n'
2024-11-25 07:24:58: POP (127.0.0.1:51920-{127.0.0.1:1993}-outlook.office365.com:995) <-- b'TOP\r\n'
2024-11-25 07:24:58: POP (127.0.0.1:51920-{127.0.0.1:1993}-outlook.office365.com:995) <-- b'UIDL\r\n'
2024-11-25 07:24:58: POP (127.0.0.1:51920-{127.0.0.1:1993}-outlook.office365.com:995) <-- b'SASL PLAIN XOAUTH2\r\n'
2024-11-25 07:24:58: POP (127.0.0.1:51920-{127.0.0.1:1993}-outlook.office365.com:995) <-- b'USER\r\n'
2024-11-25 07:24:58: POP (127.0.0.1:51920-{127.0.0.1:1993}-outlook.office365.com:995) <-- b'.\r\n'
2024-11-25 07:24:58: POP (127.0.0.1:51920-{127.0.0.1:1993}-outlook.office365.com:995) <-- b'+OK\r\n'
2024-11-25 07:24:58: POP (127.0.0.1:51920-{127.0.0.1:1993}-outlook.office365.com:995) <-- b'TOP\r\n'
2024-11-25 07:24:58: POP (127.0.0.1:51920-{127.0.0.1:1993}-outlook.office365.com:995) <-- b'UIDL\r\n'
2024-11-25 07:24:58: POP (127.0.0.1:51920-{127.0.0.1:1993}-outlook.office365.com:995) <-- b'SASL PLAIN\r\n'
2024-11-25 07:24:58: POP (127.0.0.1:51920-{127.0.0.1:1993}-outlook.office365.com:995) <-- b'USER\r\n'
2024-11-25 07:24:58: POP (127.0.0.1:51920-{127.0.0.1:1993}-outlook.office365.com:995) <-- b'.\r\n'
2024-11-25 07:24:58: POP (127.0.0.1:51920-{127.0.0.1:1993}-outlook.office365.com:995) --> b'STLS\r\n'
2024-11-25 07:24:58: POP (127.0.0.1:51920-{127.0.0.1:1993}-outlook.office365.com:995) --> b'STLS\r\n'
2024-11-25 07:24:58: POP (127.0.0.1:51920-{127.0.0.1:1993}-outlook.office365.com:995) <-- b'-ERR Command is not valid in this state.\r\n'
2024-11-25 07:24:58: POP (127.0.0.1:51920-{127.0.0.1:1993}-outlook.office365.com:995) <-- b'-ERR Command is not valid in this state.\r\n'
2024-11-25 07:24:58: POP (127.0.0.1:51920-{127.0.0.1:1993}-outlook.office365.com:995) --> [ Client disconnected ]
2024-11-25 07:24:58: POP (127.0.0.1:51920-{127.0.0.1:1993}-outlook.office365.com:995) <-- [ Server disconnected ]

[Sso]

Ok werkend gekregen met IMAP. Dank voor de hulp!