[GTALUG] Fetchmail and Office365 and backslashes, oh my!

[Myles Braithwaite 👾]

Peter King via talk wrote on 2018-07-04 2:53 PM:
> Recently we were forcibly "migrated" to Office365 for our email services,
> and with the change numerous things were broken.  One of the last things
> I cannot figure out how to solve is how to pass an alias email address to
> the MS server.  So in .fetchmailrc I have a line like this:
> 
> user "prof.bozo at utoronto.ca\department.chair at utoronto.ca"  there with password "XYZZY" is bozo here
> 
> But this fails, and in the fetchmail logfiles it represents the username as
> not having a backslash:
> 
> Jul  4 14:35:14 fetchmail[13829]: IMAP> A0002 LOGIN "prof.bozo at utoronto.camedieval.philosophy@utoronto.ca" *
> Jul  4 14:35:14 fetchmail[13829]: IMAP< A0002 NO LOGIN failed.
> Jul  4 14:35:14 fetchmail[13829]: IMAP> A0003 LOGOUT
> 
> If I double-backslash it, though, I get a double backslash in the username.
> Ditto for triple, quadruple, and quintuple backslashes.  Nor does it work
> if I single-quote the backslash.
> 
> According to the fetchmail manual, the backslash is used to communicate via
> ASCII sequences and codes with fetchmail, and it's pretty clear that this
> is part of the problem.
> 
> Google turned up a few people with the same problem, but they seemed to
> have their problems (from 7+ years ago) fixed by multiple backslashes,
> which clearly aren't working for me.
> 
> Any ideas?  Our local people maintaining the MS Office365 nonsense dont'
> support fetchmail and are not interested in helping ...

I was having the same issues a year ago and basically gave up. I'm not 
100% sure if this will work for you but it magically started working for me.

I switched my O365 account two-factor auth (they use SMS to transmit the 
code, Ew) and had to create a bunch of app passwords[0] to be able to 
connect with my main email client. Randomly one day decided to see if 
this would work with fetchmail and lo and behold it did.

I don't know why it worked or if something was disabled in that year but 
it works now.

[0]: The location where you generate new passwords is here: 
<https://account.activedirectory.windowsazure.com/AppPasswords.aspx>

Off-Topic:

One of the scary things about finding URLs to generate passwords on 
Super User is the fact the `windowsazure.com` whois lookup responds with 
MarkMonitor Inc., they help corporations protect their domain names. So 
you have to check the SSL certificate first to see if it's a valid 
domain. I had to use this command:

echo | openssl s_client -showcerts -servername 
account.activedirectory.windowsazure.com -connect 
account.activedirectory.windowsazure.com:443 2>/dev/null | openssl x509 
-inform pem -noout -text

to review if it's valid.