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@utoronto.ca\department.chair@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@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.