• Alpine and O365 Gateway

    From Pascal W@21:1/5 to All on Wed Nov 17 10:42:57 2021
    Hi! Does anyone have experience proxying Alpine via this "O365 gateway"?

    https://github.com/mguessan/davmail

    Thanks,
    Pascal

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Eduardo Chappa@21:1/5 to Pascal W on Wed Nov 17 19:31:27 2021
    On Wed, 17 Nov 2021, Pascal W wrote:

    Hi! Does anyone have experience proxying Alpine via this "O365 gateway"?

    https://github.com/mguessan/davmail

    Yes, Davmail is a tool that allows you access an exchange server (using
    the exchange protocol) through an imap gateway. My experience is that it
    is slow, but if that is what you will be allowed to use it is better than nothing. The default concept of "deleted" in davmail is "deleted and
    expunged" so configure it to not to expunge upon deletion.

    Good luck!

    --
    Eduardo
    https://tinyurl.com/yc377wlh (web)
    http://repo.or.cz/alpine.git (Git)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Pascal W@21:1/5 to Eduardo Chappa on Fri Nov 26 00:57:37 2021
    Thanks! From reading the documentation of DavMail my understanding is that Alpine will still be required to be approved by Azure AD administrators. At my company they have flipped the switch from default setting and do not allow developer self-service
    consent for apps. DavMail will not solve that problem for me.

    /Pascal

    On Thursday, November 18, 2021 at 3:31:31 AM UTC+1, Eduardo Chappa wrote:
    On Wed, 17 Nov 2021, Pascal W wrote:

    Hi! Does anyone have experience proxying Alpine via this "O365 gateway"?

    https://github.com/mguessan/davmail
    Yes, Davmail is a tool that allows you access an exchange server (using
    the exchange protocol) through an imap gateway. My experience is that it
    is slow, but if that is what you will be allowed to use it is better than nothing. The default concept of "deleted" in davmail is "deleted and expunged" so configure it to not to expunge upon deletion.

    Good luck!

    --
    Eduardo
    https://tinyurl.com/yc377wlh (web)
    http://repo.or.cz/alpine.git (Git)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Eduardo Chappa@21:1/5 to Pascal W on Fri Nov 26 02:23:30 2021
    On Fri, 26 Nov 2021, Pascal W wrote:

    Thanks! From reading the documentation of DavMail my understanding is
    that Alpine will still be required to be approved by Azure AD
    administrators. At my company they have flipped the switch from default setting and do not allow developer self-service consent for apps.
    DavMail will not solve that problem for me.

    Dear Pascal,

    depending on the type of security that is needed in your workplace, your administrators should consider allowing apps that are known to work and
    are trusted by the community. Both Alpine and Davmail are known and
    trusted by the community, and the proof of that is that a quick search in
    the internet will show you many universities that tell users how to
    configure each of these programs to access their services. In addition
    these products are distributed by Linux distributors (e.g.: Debian,
    Fedora, Suse, Ubuntu, etc.) which adds to that these programs have been reviewed and tried by the community, and security issues found in them
    would be highly publicized.

    The fact is that users can trust these products.

    However, in addition to these observations that you should pass along to your administrators, there is the issue of what Microsoft tells to the administrators. In essence when you read Microsoft documentation and when
    you talk to administratror the sense is that only Microsoft products are trustowrthy (because they were purchased from a legitimate company) and products not offered by Microsoft might not be trustworthy or might not
    offer the same quality of service that their products offer, etc. In
    essence, administrators are afraid to allow a third party product because
    it is unsafe and/or inferior to a Microsoft product, for which a fee to
    use was already paid to Microsoft.

    In this way Microsoft can sustain its dominance over other products. Products such as those coming from Google or Apple do not suffer these
    issues because there is too much pressure to allow them and are considered
    safe by the community. In your case, there is no much pressure to allow
    Alpine because the user base is small, albeit it is considered safe by its users.

    The story of the man with the bag that will kidnap kids was meant to
    scare kids to not to trust strangers based on their looks. This is
    similar, and many admnistrators prefer to forbid Alpine and not accept the evidence that Alpine is safe and trusted by its community of users.

    There are merits to the way your system is being protected. No
    everything is wrong, but allowing access to Microsoft products by default, while leaving all other products out and only authorize them on a case by
    case basis makes one company to take control of its users, and that is not
    good for users at the end of the day. The idea of securing systems is important, and you have to make the case the Alpine will not make their
    systems less secure.

    Are there any programs that you your administrator have granted access
    to acceess their servers?

    --
    Eduardo
    https://tinyurl.com/yc377wlh (web)
    http://repo.or.cz/alpine.git (Git)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Brandon Jewett-Hall@21:1/5 to Pascal W on Mon Oct 2 09:11:39 2023
    Hi Pascal,

    I was able to get DavMail + Alpine working for a similar situation (university Office365 account that disallows most email applications). In my case, the IT department allows use of Mac Mail (Mail.app), so I set up my account with Mail.app on my Mac,
    and then I was able to spoof Mac Mail by copying the Exchange refresh token out of the Keychain and setting .davmail.properties like so (replace the email string in the refresh token property name accordingly):

    davmail.mode=O365Manual davmail.oauth.clientId=f8d98a96-0999-43f5-8af3-69971c7bb423 davmail.oauth.redirectUri=com.apple.Preferences://oauth-redirect/ davmail.oauth.youremail@example.edu.refreshToken=<REFRESH TOKEN>

    On the Alpine side, I use plain auth for IMAP+SMTP and enter a fake password when prompted (any non-empty value will do), which appears to be needed to trigger the correct OAuth flow inside DavMail. After successful auth, in my case, DavMail rewrote the
    refresh token property in my properties file with an AES-encrypted version (presumably for the questionable rationale of avoiding plaintext).

    The obvious downside of this approach is that you have to manually update the refresh token from Keychain whenever O365 forces re-auth, but these events are typically infrequent (on the order of months or years).

    On Friday, November 26, 2021 at 12:57:38 AM UTC-8, Pascal W wrote:
    Thanks! From reading the documentation of DavMail my understanding is that Alpine will still be required to be approved by Azure AD administrators. At my company they have flipped the switch from default setting and do not allow developer self-service
    consent for apps. DavMail will not solve that problem for me.

    /Pascal
    On Thursday, November 18, 2021 at 3:31:31 AM UTC+1, Eduardo Chappa wrote:
    On Wed, 17 Nov 2021, Pascal W wrote:

    Hi! Does anyone have experience proxying Alpine via this "O365 gateway"?

    https://github.com/mguessan/davmail
    Yes, Davmail is a tool that allows you access an exchange server (using the exchange protocol) through an imap gateway. My experience is that it is slow, but if that is what you will be allowed to use it is better than nothing. The default concept of "deleted" in davmail is "deleted and expunged" so configure it to not to expunge upon deletion.

    Good luck!

    --
    Eduardo
    https://tinyurl.com/yc377wlh (web)
    http://repo.or.cz/alpine.git (Git)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)