-
Notifications
You must be signed in to change notification settings - Fork 0
When Should I use PostGraph?
you might expect the author of a tool to tell you "yes, you absolutely should use this thing i build!". however, the reality is that a native implementation of the Graph Mail API will generally be preferrable to using a third-party tool. below are some scenarios you might be using or planning to use, any my opinion on if you should instead consider PostGraph.
enabling the SMTP endpoint generally is a kind of horrible idea, as it opens up a massive attack vector to your tenant. legacy authentication (with SMTP auth is a part of) has basically no effective controls to prevent abuse. attackers can use this for password spray attacks, quickly compromising accounts. even microsoft acknowleges this and recommends blocking conditional access.
without conditional access (relying on e.g. security defaults), blocking legacy auth is a all-or-nothing deal. thus, you're probably better of routing any remaining on-premise services using SMTP through PostGraph.
when utilizing conditional access, this view shifts. now, you're able to enable legacy auth / SMTP only for specific users, and - more importantly - specific IP ranges. thus, you can limit your exposure a lot, making attacks only feasible from e.g. your internal network.
of course, there's still the possibility of an attack agains M365 beign carried out from inside your network (or a guest network with the same external IP), but for many this might be an acceptable risk. however, it is currently unclear for how long Microsoft will continue support for SMTP, so keep that in mind. for now tho, there's no clear benefit using PostGraph instead of the native SMTP endpoints with proper conditional access policies applied.
kinda horrible idea. with this, not only do you have to take care of an additional Server, but it's an Exchange Server. even if you've closed off OWA from the internet, you still have a massive attack surface, with tons of vulnerabilitys beign found all the time.
stay away, use PostGraph.
some software vendors have started adding support for sending Mail via M365 Exchange online, often replacing the "normal" SMTP auth with XOAUTH2 or utilizing application permissions of the graph api.
these application will request you to create an m365 app registration with SMTP.SendAsApp or Application-Scoped Mail.Send permissions.
if the application has some built-in authentication mechanism, and keeps the client credentials inaccessible for users, you may use this. imo, PostGraph should be preferred over XOAuth2 authentication, but that's just because i kinda dislike the way it works...
however, many software vendors take the lazy route adding support for M365, and treat the client credentials as an alternative to individual user's SMTP credentials (accessible to the user). this for one means that any user has access to the client credentials and can send mail as whoever they like (or a malware can come along and grab them...). additionally, if the day comes around where the client secret expires, you now have to deal with everyone needing to update their settings at once. so, unless your're some kind of masochist, you should absolutely consider using PostGraph.
some software vendors actually add decent support for sending mail via Graph, using delegated user permissions. that means that they request a token scoped to a single user only, meaning they can only send mail with the permissions that user has.
you'll recognize these applications by a "Sign-in with Microsoft" button, followed by an interactive authentication flow each users has to go through. if you're required to create a new app registration in M365, you will only be adding delegated Mail.Send permissions.
if this is the case, there's no need to use PostGraph. unless there's some other issue with the implementation, use the native implemenation directly.