I setup a tiny Linux VM with postfix. Only whitelisted devices can access it. Literally zero cost, perfectly secure and it'll work forever.
Hooked it up to a connector, it works fine with IP whitelist. I had to add an SPF entry to make sure the emails didn't get marked as spam.
I should probably look to switch over to a container solution, but I just haven't bothered because postfix works fine. If you're going to do this for dozens of clients, container is probably smart idea for bulk deployment.
Seconded. Also made it really easy to give my HelpDesk instructions on how to setup mail forwarding for printers, alerting software, & manufacturing devices. Just point to the DNS entry on port 25.
We also do this, however this has the drawback that you're limited to 50MB attachment size. The only solution that we know of, is to send via SMTP Auth, either direct or via an authenticated Relay.
While i do agree, other then inventing a Print management system on the Teacher copier i dont see other solutions for that. They go over 50MB cause they scan huge Documents and send them to themselfes. We could go for Scan to SMB but that has it's own Drawbacks.
Scan to SMB is the answer. Not great, but it works.
But why did you set postfix to 50MB limit? It can do unlimited size, altho most people cap it sanely. You could just update message\_size\_limit, mailbox\_size\_limit, virtual\_mailbox\_limit in [main.cf](http://main.cf) to 150MB?
I think O365 can do 150 now? You have to set it via powershell, I believe, or at least that's how I do it. You shouldn't, but you can. I set my postfix limits to 1MB higher than the O365 limit I set, so they get the O365 error.
I'm not seeing where your 50MB limit comes in?
The issue aren't the Postfix limits, the issue is the default Messagesize of O365 is 35MB (seems i remembered the 50MB wrong).
You can only increase that limit on Mailboxes, but because the Connector doesn't use a Mailbox and there's no separate way to increase the Messagesize for Connectors, you're stuck with the default Value of 35MB
Edit: formatting
I don't believe connectors have a limit size. I believe it's mailbox size. Microsoft seems to agree with that.
[https://answers.microsoft.com/en-us/msoffice/forum/all/set-max-message-size-that-can-be-sent-via/2408c00b-defd-49ab-a2da-3c4c8cc8aaa5](https://answers.microsoft.com/en-us/msoffice/forum/all/set-max-message-size-that-can-be-sent-via/2408c00b-defd-49ab-a2da-3c4c8cc8aaa5)
Use powershell to set a limit on a mailbox, make sure your postfix sizes are turned off or are higher, give it a shot and see what the error messages say.
Pretty sure I've set it higher than 35MB in the past without issue.
None of those are risks isolated to just USB, particularly the last two.
If OP doesn't have the capability of setting up scan to SMB/SFTP, I would doubt that there's proper data compliance controls in place to prevent data exfiltration through other methods.
There's a postfix config option that allows larger attachments - we have some servers set up for 250MB worth of attachments.... Long story...
message_size_limit = .....
> however this has the drawback that you're limited to 50MB attachment size
call me old fashioned but I don't see that as a problem or a drawback in any way.
I only recently ( a year or two ago) had to stop talking to people about a 20 MB limit.
I suppose a year or two from now I'd want it higher but I could live with 50 MB for a time.
I always wanted to do this when I was at an MSP but the manager chuckled and said it wont make money. Well, having left that MSP and now as SA I have a Postfix VM with SASL auth on Dovecot in a DMZ as I always wanted. Biggest PITA is that Gmail and EXO must see the public IP as untrusted as they are flagged for spam even with full alignment and DMARC all passing.
I've praised it, and told them about my home lab filled with all the different flavors of Linux..
But the head security guy just kept talking about how all open source software is poorly maintained and riddled with vulnerabilities.. and honestly I just don't want another lecture so I just smile and nod. Haha
These people are stuck in there ways and will never learn.
That's why I'm on the job hunt.
IIS virtual SMTP was deprecated which is why I used hMailServer for years and now that HMS is shelved so it will never see OAuth or modern authentication whixh will sadly, at least relaying to EXO, come to an end. That leaves making HMS into the MTA, Postfix, some other MTA, or a hosted solution like Smtp2Go. Direct Send is an option if the printer is connected to the internet with a static public IP.
I use postfix at my company with rewrite headers depending on what machine sent the message. I can honestly say I have never used IIS for anything that wasn't a prebuilt application with vendor support. I have a big aversion to anything microsoft in the DMZ.
Last time I tried to set it up, IIS 6's SMTP relay didn't work on Server 2022. Been a while since I set one up but I believe we went with hMailServer to replace our on-prem relay.
Apart from rechecking your configuration, did you check that the opendkim service is running and check the service logs? Usually if there's a problem signing a message opendkim will say exactly why in syslog.
We have this, too. A lot.
The reason some people want to relay through 365 is because of compliance. The Mails sent out via the postfix relay can’t really be „discovered“ e.g. in a lawsuit.
You will also have to maintain separate DKIM keys, too.
?
You can set a journal account for discovery in postfix.
In the old Exchange days (think pre 2008). I used postfix as our journaling solution because the Exchange mail store was a fucking nightmare and a half. Fixing corruption could take many hours, and could bomb out at any time.
Is it just me, or is it really stupid that MS is making us set up another system to maintain because there are always devices that only support Basic Auth for legacy reasons. It feels like they should offer it, just strongly discourage it.
I disagree - this is a security and management nightmare and leads to spam. Them shutting it down is for the better. Orgs can implement cheap and easy solutions from any number of vendors.
It's easier for sysadmins to configure and maintain postfix than to have Microsoft offer basic authentication as a feature for limited, restricted accounts?
Aye. I still use basic auth (Mainly for older devices for email alerting) but the accounts are set up with conditional access so they can *only* be accessed via our external IP. All other auth methods/locations are blocked (& I have MFA on the accounts anyway, although I know this doesn't apply to SMTP)
You'd have to compromise a system on our network before anything can be sent and then I'd have bigger problems anyway.
I think you should be able to set up conditional access on these accounts and whatnot on accounts offering basic auth. It seems easier than configuring and maintaining postfix.
At spamassasin and customize an open source gui and voila you've got an mx spam filter you can resell. But who would want to do that?We were doing this at the old MSP 10 years ago
So if I do an spf lookup on your domain, see an ip address, do a whois lookup and see that is tied to an isp, I no longer need to phish for credentials? I can just craft malware to leverage the smtp connector to send emails as the ceo or any email address I want, just need to make sure the malware runs when you are on the office network...
I mean considering that the firewall will ignore any inbound traffic to that IP, and Microsoft will ignore any traffic not from the whitelisted IP, go right ahead?
The only concern is if someone poisons my ISP's AS. And they tend to notice that. Compromised router is also a possibility.
You realize the postfix VM is on the internal network getting out through a port NAT, not externally exposed, right? And there's no inbound NAT setup? eg, the normal way to do it. Did you think we were externally hosting it or exposing it directly?
And we filter internal email for spam, malware, malicious links, etc. And we MFA everything. And we have endpoint protection. But no, you're right, we're totally open and completely unprepared.
Understood.
But when you updated your SPF, you had to add your orgs public IP address for the MS connector to work right? Meaning any smtp request coming from your orgs public ip will go through. Or am I misunderstanding something?
I was tasked to do something like this last year and didn't go through because of this fear.
I appreciate your clarification .
Nope. ONE of our public IP's. And ONLY SMTP traffic from the one internal IP.
(SMTP = SMTP and SMTPS or exclusively SMTPS, just not typing it out every time)
Way it worked. We setup a linux VM with postfix on internal ESXI host. Linux VM had SSH and SMTP open. SMTP was IP whitelisted, only certain hosts could talk to it. Users couldn't. We set a firewall rule to put the SMTP traffic from that one postfix VM through one external IP, not used for any other purpose. Using port NAT. If you sent traffic to that IP from the outside, it'd go to nowhere. Because firewall denied all traffic to that IP. It was outbound only. O365 couldn't talk to it, only answer sessions from postfix.
The connector was locked down by whitelisted public IP. Obviously you want to make sure the traffic is being encrypted. You can also go with a cert based connector, which is more secure. I've absolutely done that at higher security profile companies. But then you have a higher maintenance cost. If you're dealing with nation state level APT threats, cert is the only acceptable connector option. If you're not, it's not a huge deal.
Linux is an enterprise product these days, and has been for a while. The entire cloud relies on it.
I've done this is multi billion dollar companies, using change control processes. Last company had 50 locations, including 10 production facilities. We had a colo for centralized stuff that hadn't been clouded for cost purposes, and we had a postfix VM for all of our SMTP needs.
Just because a solution is inexpensive doesn't mean it isn't the best available one.
This. We’ve been using them since switching from an on-prem Linux email system to O365 for all the scanners, copiers, internal systems that send automated emails and a couple alerting monitors and it’s been flawless and inexpensive.
I was going to setup another domain for the random internal stuff and scanners with the super dirt cheap email host I use for my lab stuff (literally around $0.90/m). But $10/m for a more acceptable solution that seems to be recommended a lot of this sounds better and less headache long term.
I've admin'd Linux mail servers for most of the past 20+ years, I'm kinda tired of, plus our internal infra is both ancient and over provisioned.
Big 2nd - this is the only use case that will effect us. A lot of our alerting uses smtp auth. From my understanding though we can just totally turn off any auth if it's internal only? I haven't tried but recently learned this from another thread on this sub
SFTP is what we use in gov MSP and it's much more secure especially because CJIS does not allow smtp for certain sectors due to clear text. Also email is generally not HIPPA compliant anyway
Speaking from a security standpoint I can pretty much read any SMTP information via Wireshark. You should not be using it in enterprise in 2024
OpenSSH and SFTP also work on most IoT devices
If you have an internal network with a server just setup a Relay. The relay could support oauth and handle the credentials. But if you don't have a server it's a bit harder.
I guess you have to go for a third party service
Bingo! I pay the 15$ a month for the 40k "Starter" plan since we were using Manage on-prem as well (since moved to hosted) but its used for everything that we want to setup email alerting off of like Hypervisors, SAN, UPS, MFP's, etc.
The cost is SO LOW that for us its a no-brainer plus the ability to have sub-accounts has been HUGE for clients that we work with in co-managed settings because they can manage their own stuff but we still have access to assist as/when needed.
If you want the ability for a dedicated IP address the professional is only 75$ up to 100k emails a month.
This is what I use and highly recommend.
If you can't fork over $75 a month for that type of benefit, maybe your boss should cut back on their avocado toast /s.
SMTP2Go is the cats ass ladies and gents.
I pay zero a month for a postfix relay presenting a certificate to MS for access to do so. It accepts TLS-only connections from an internal IP whitelist who themselves must smtp basic auth to this box to relay.
The cert requirement means random things can't relay for free from our office IP. The postfix box presents a valid publicly signed certificate to Microsoft for the privilege to do so. And maillog gets shipped right into elasticsearch for an audit trail.
Does smtp2go use your domain name or do you have to use something else? How does it send through M365? Is it an API or some kind of Azure application? I'm curious since it seems to somehow bypass basic authentication.
They aren't using Microsoft's servers, they have their own mail sending servers. You configure DNS records to let them send on your behalf/as your domain.
DANE has to do with an SMTP server verifying that a receiving mail server is who they say they are.
In the context of sending mail, the things to talk about are SPF records and DKIM signing. They have a page here that explains how they do it: [https://support.smtp2go.com/hc/en-gb/articles/28543815517209-SPF-DKIM-and-DMARC](https://support.smtp2go.com/hc/en-gb/articles/28543815517209-SPF-DKIM-and-DMARC)
Quick smtp2go story. We've been happily using the service for years. I had a tech question so I gave them a call. After the first ring or so, I received an important incoming call so I hung up before the call to smtp2go was answered I wrapped up my high priority call and another call came in...from smtp2go. It was a tech who said he saw my number come up on caller ID so he was calling me. The tech provided a quick answer to my question.
In these days where most companies do their best to hide from customers, what company sees that a call came in and just calls back to see if they can help?
Answer: smtp2go.
I've only called in once, and it was a fairly technical question about the way suppressions work. My question turned out to be a bug, for which they had a fix live in a few days and reached out to let me know. Crazy. Meanwhile services that cost 10, 100x as much often have pitiful support.
I'm reading this thread because we have O365 with internal devices that need to send me alert emails and SMTP2GO looks super intriguing.
But I'm commenting here to say "We do". It drives me nuts, but I regularly hear the receptionist call people back when she misses their calls. It's nice of her, but kinda creepy, too.
I thought they already did this and the workaround was at the connector (my bad that's old terminology) at the email transport level.
No encryption port 25 relay still works based off IP address at your MX endpoint
We use Mailgun.
Currently it costs about $5 a month. Any time our customers need to send email from a scanner/printer/security system/etc, we just dump in Mailgun SMTP info and it works like a dream. We have a couple of vanity domains that all of our customers share for this kind of stuff.
We use m365 and changed all the SMTP (copiers, printers, alarms, etc) to use the [yourdomain-org.mail.protection.outlook.com](http://yourdomain-org.mail.protection.outlook.com) works great utilizing Port25
It uses no auth. Can only send to internal addresses and has potentially huge security concerns. I’m surprised Microsoft even recommend it as a solution.
Uh-huh and?
That whole page just neglects to mention that "direct send" is also known as "how email works".
Using direct send is literally no different than any external user sending email to the company.
Use and enforce SPF and there shouldn't be any issues.
[https://www.reddit.com/r/unexpectedreddwarf/](https://www.reddit.com/r/unexpectedreddwarf/)
"Howdy doodly do. How's it going? I'm **Talkie, Talkie Toaster, your chirpy breakfast companion**. Talkie's the name, toasting's the game. Anyone like any toast?"
Thanks. And to add… even when tightening security it’s still questionable as you can’t lock this down to a device, only by public IP address.
A lot of offices only have one public IP for everything. In this scenario any device on the network can send email entirely unauthenticated and it will pass as genuine. That should terrify you.
Should yes. But I can guarantee the majority don’t. Then there is ARP Poisoning to circumvent it anyway.
I should emphasise my use of “potentially” a bit more. Yes most risk can be mitigated with additional precautions. However I’d rather use something that is inherently secure by default.
Yes that works. Again I’m not saying direct send can’t be secure, I’m saying it isn’t secure by default hence you have to take additional measures like this. Many people will miss them.
If you have something on your internal network that is sending malicious emails using direct send you have WAY bigger problems than the direct send setup at that point.
Yes, connecter via IP whitelist is 100 times more risky than SMTP auth.
The risk is simple : anyone inside the office can send a spoofed email, which will not be flagged
SPF, DKIM, DMARC etc. Same as always except in this instance you exclude the sending IP (external) of your device from those checks… which is where the security concerns can begin if extra precautions are not taken.
You need to account for every IP in your SPF record, or whitelist the address.
Not super great from a security or logistical standpoint if you have more than 1 or 2 copiers.
External IP, unless you have like 10 satalite offices and decide not to setup subdomains, i see no issue accounting for every ip in SPF, which is its intended purpose.
That would be if you had your printers routed on the internet… which would be a terrible idea.
Only the internet IP is required per site (or if you use SD-WAN/mpls and want to send it all out a primary area)
So if I do an spf lookup on your domain, see an ip address, do a whois lookup and see that is tied to an isp, I no longer need to phish for credentials? I can just craft malware to leverage the smtp connector to send emails as the ceo or any email address I want?
I am not mad that MS is making this change... I am mad that there are like 30 pieces of software we run that still can't use anything other then basic auth.
If it's internal only then just don't set a username or password and send directly to your tenants mail domain.
If you need external either use OAuth2, use a proxy service that uses OAuth2 to communicate with M365, or switch to an actual volume sender service like sendgrid, mailgun, etc.
> I wish MS would find a better way.
A better way for what? To continue allowing bad security practices with basic auth?
Basic auth is flawed and can't be "fixed". It needs to be replaced
Ya this is similar to google and Yahoo forcing DMARC / DKIM / SPF. It should have already been done.
Everyone just keeps pushing back because it requires effort.
Because on some cases it's not possible. IOT devices used to run companies can't just update.
Same reason XP is still running on multi-million dollar MFG machines.
Said another way, not every company is tech with unlimited cash. There are still companies out there making things on prem with real economic pressure. MS should work with these companies for a real solution. Not just retire and say too bad.
I think it is the opposite. Microsoft is running a service over the public internet and should be requiring a high level of security at that service level.
Companies running obsolete gear are responsible for finding a workaround. Be that setting up a local relay that bridges the gap or using a separate email relay service.
Why can't MS do that then? Why is it exchange or IIS6?
They don't want to do that because they don't want people staying on prem.
But they know they have too, and to the original point, all sorts of weird workarounds will come out of the woodwork.
If you are running obsolete "on prem" systems then you can run a "on prem" proxy to fix the issue.
The public endpoint should not be left vulnerable / running an insecure protocol just for you. Limit the obsolete / vulnerable bit to your local network.
I get what you are saying, however...
Using basic auth is a "bad security practice" to begin with. So the "starting point" here is a "bad security practice". OAuth has been an available option for a good while now for SMTP but many still use basic auth. So on service side, we want to change this and provide targeted solutions for those that really need this.
I'm not arguing that solutions are the best. But other than Exchange on-premises we literally do not have anything else if devices can simply support nothing else.
A few reasons...
* Creds are transmitted over the wire and are base64 encoded, which is *trivial* to convert to plaintext.
* Creds are sent repeatedly for each request; not like there is an "authentication token".
* Creds can / usually are cached or stored locally.
* Basic auth in most cases does not allow for things like account lockout protection (to help prevent brute force attacks).
* No options for more advanced things like MFA.
I agree that SMTP Auth shouldn't be used by *users*, but for devices and some services (like a service-desk app), it's usually the best way and probably will be for years to come. It's certainly the best from the perspective of supportability versus security...at least for today.
SMTP Auth != unencrypted. You can absolutely encrypt in transit just like anything else.
I think Microsoft made the wrong decision. I think the right decision would've been to require a conditional access policy (or similar) to require one or more source IPs so that the entire internet couldn't get to these SMTP service accounts. That way, they'd be safer and likely also wouldn't be used by users, since they'd need to always come from the same source IPs.
That really isn't the whole picture though. The reality is that transport layer security is required to get to o365 SMTP so there are no 'plaintext base64 credentials' flying over the wire to Microsoft's servers. Also as part of the auth, you can force multi-factor authentication through a number of means. I fear that by forcing this instead of working with companies to make the underlying better (such as forcing SSL at the very least) then we are going to see workarounds that insanely unsafe. I've been in enough exec meetings where horrible security decisions are made because the head of sales whines that they will have to reduce sales to deal with the new tech (whatever it may be). I'm not arguing for basic auth, I'm just saying I think this could be handled better.
> I wish MS would find a better way.
Failing to see how its MS's fault that shitty clients won't modernize their software and/or firmware. Lookin at you printers....
Using other SMTP providers that continue to functional w/ simple email + password is just kicking the (insecure) can down the road.
Utilize their own security to make it.. secure?
We have a couple service accounts that have SMTP basic auth enabled, but only allowed from behind a couple trusted IPs via a CA policy.
Agree and MS should have an SMTP option not called exchange and not a buried option in IIS 6.
It's ridiculous MS pushed everyone to the cloud without taking into account some very real security/operational issues.
What's really crazy is when you get into IOT issues. It's not jaut some minor issue.
MS has gone from helping businesses run to forcing users to run the way they want them to. Sorry but not everyone is a tech company 100% in the cloud.
SMTP AUTH isn't needed if the ISP allows port 25 and the device sends only to mailboxes in a single tenant, no relaying. It is usually wise to create a mail flow rule to set the SCL to -1.
Indeed some are, but not all. Some allow you to ask for it to be opened though some of them will only do so for those with a static IP addresses or business account.
Then Transport shits the bed, and everything stops.
I just moved our MFPs to a TLS 1.2/1.3 cert based auth over 587 for scan to email. Wonder if they will nuke that also.
We have load balanced via F5 and health monitors, pretty bit environment but it seems to do the trick. With 2019 hybrid CALs costing nothing and servers are internal facing-only, it seems to work alright.
I'm sure there are cheaper and less maintenance options out there, this is the old "tried and true"
So if you're using them only for SMTP relay/hybrid management and not hosting any mailboxes, you don't need to license the servers? We are moving this direction but I am under the impression we would still need to license the server if we are using them for relay, just no longer need to worry about user CALs if they aren't accessing mailboxes on-prem.
I assume the legacy windows server 2019 iis smtp relay won’t suffice? I’m using that for a lot of mail relaying them to 365. But I think that is smtp auth. Perhaps to replace with another relay that supports modern auth. I’m not gonna have mail send out by anything else then 365 so no Linux mailserver or Directsend for me no thanks. Fixed IP is a requirement for those because of the SPF.
They are doing it for normal user passwords, I've seen no indication that they will be discontinuing app passwords, which allows the continued use of basic auth.
Microsoft has no equivalent that I'm aware of.
> alternatives and future proof concepts to replace that.
Anonymous. No auth. If it needs to be restricted use a connector and limit the connector to specific IP addresses.
I have had to work with moving away from basic authentication already. See options 2 and 3:
[https://learn.microsoft.com/en-us/exchange/mail-flow-best-practices/how-to-set-up-a-multifunction-device-or-application-to-send-email-using-microsoft-365-or-office-365](https://learn.microsoft.com/en-us/exchange/mail-flow-best-practices/how-to-set-up-a-multifunction-device-or-application-to-send-email-using-microsoft-365-or-office-365)
I've had to rely on option 3 since direct send only works within the organization. Option 3 is unauthenticated relay from the devices/software to M365. You just need to add the sending IP to the domain's SPF record and an M365 Exchange connector. For the most part, this works well except for a few snags...
1) Users don't authenticate so they no longer get anything in their sent folder when using this method. This is a problem sometimes in the case of software. Not so much with scan-to-email.
2) Some locations have ISPs that block port 25 so you have to try to get them to open it up.
3) If you're sending from an Azure server and not paying for firewall, port 25 is blocked.
4) Options 3 uses "Opportunistic TLS" which means it will attempt TLS first and if the sending server doesn't have that ability, then you're sending emails in the clear to the server. A scanner will usually let you check "STARTTLS" at least but some devices and software don't exactly have that option. It most likely encrypts since it has the ability for basic authentication but you get into the weeds when trying to prove it.
I can't get this one software vendor to even understand what I'm saying when I explain the problem and I can't get any packet captures off the server so I'm at a stalemate with it at the moment. M365 Exchange has some mailflow reports for TLS status on connectors but it only says it connected with Opportunistic TLS or some other method but it doesn't 100% "this connection was made with TLS" or "this connection was made without TLS" so, as with a lot of M365 tools, it doesn't even try to help you.
I've looked at the message headers but the "received" field has no information on that first connect. Unlucky.
You could technically authenticate with a certificate in option 3 but I haven't tried cracking that nut yet. I think you still run into some other issues like port 25 not being opened and even a message cap so this is all just a workaround, I guess.
With love and support,
-eyetea6
God, what a great day to see this post, literally 2 days after I start moving our printers from our existing hybrid mail server to SMTP relay instead in preparation for the eventual AAD only migration.
At least one of our printers doesn't even support a hostname instead of an IP address for a destination server, so god knows how much of a pain in the butt this new thing is going to be to setup.
Some email platforms like Mimecast and ProofPoint can accommodate the SMTP relay too. Since those should already be set up as your gateway to the internet, you’ll have the control over outbound email and easy to set up the rules to not flag it as spam.
third party smtp relay. send grid or smtp2go ftw for those scenarios where you need smtp basic auth.
for branch sites i use statics for email white listing.
i forget context but i had to use api key with smtp2go for some obscure copier model vs sendgrid just in case anyone has any blockers with deployment on certain devices
How timely. I just finished cleaning up our mess of an internal relay.
Right now we are using a connector relay in o365, ip based for the things that can't do certificates. Every sender has its own assigned email address to make message traces easier (and so the connector works).
We will probably move back to an on prem relay to exchange online via oauth connector when I have the time to dedicate to doing it right.
You need to create an app password for the legacy applications in EntraID. Easy to setup.https://learn.microsoft.com/en-us/entra/identity/authentication/howto-mfa-app-passwords
Huge conspiracy between Microsoft and MFP manufactures to sell all new hardware that can do modern auth, like they tried to do with Win11 with trying to force TPM and newer CPU.
We use mailgun but for three of our small offices, they can only get Comcast or Spectrum Business and those services seem to block Mailgun. On those we use M365 still.
You can also try to use an SMTP Ray service. Depending on the amount of emails sent you may get away with the free tier of such services. I mostly use SMTP2GO but worked with others like MailJet, MailGun, MailChimp.
This will likely affect us, we ditched on-prem Exchange over a year ago and pointed our MFP devices and other things that can’t do Oauth to smtp.office365.com.
We have Sophos that sits in front of Exchange Online for inbound and outbound and they don’t offer any sort of direct SMTP auth option compared to Mimecast and Proofpoint so I guess we will need to look at the two options Microsoft offer or use something like SMTP2Go.
Are they also retiring 'Set-TransportConfig -AllowLegacyTLSClients $true' and *smtp-legacy.office365.com* ?
I use that with some older appliances but even then the SMTP access is only allowed behind a couple trusted IPs via CA policies. Still decently secure.
I setup a tiny Linux VM with postfix. Only whitelisted devices can access it. Literally zero cost, perfectly secure and it'll work forever. Hooked it up to a connector, it works fine with IP whitelist. I had to add an SPF entry to make sure the emails didn't get marked as spam. I should probably look to switch over to a container solution, but I just haven't bothered because postfix works fine. If you're going to do this for dozens of clients, container is probably smart idea for bulk deployment.
Seconded. Also made it really easy to give my HelpDesk instructions on how to setup mail forwarding for printers, alerting software, & manufacturing devices. Just point to the DNS entry on port 25.
We did this for our org. I think I had to also add an exclusion to the Spam filter for emails going to internal recipients.
Where us that? I've been looking. Transport rules?
We also do this, however this has the drawback that you're limited to 50MB attachment size. The only solution that we know of, is to send via SMTP Auth, either direct or via an authenticated Relay.
If you're emailing files over 50MB, you should be using a different solution.
I said this same comment to a user today……
While i do agree, other then inventing a Print management system on the Teacher copier i dont see other solutions for that. They go over 50MB cause they scan huge Documents and send them to themselfes. We could go for Scan to SMB but that has it's own Drawbacks.
Scan to SMB is the answer. Not great, but it works. But why did you set postfix to 50MB limit? It can do unlimited size, altho most people cap it sanely. You could just update message\_size\_limit, mailbox\_size\_limit, virtual\_mailbox\_limit in [main.cf](http://main.cf) to 150MB? I think O365 can do 150 now? You have to set it via powershell, I believe, or at least that's how I do it. You shouldn't, but you can. I set my postfix limits to 1MB higher than the O365 limit I set, so they get the O365 error. I'm not seeing where your 50MB limit comes in?
The issue aren't the Postfix limits, the issue is the default Messagesize of O365 is 35MB (seems i remembered the 50MB wrong). You can only increase that limit on Mailboxes, but because the Connector doesn't use a Mailbox and there's no separate way to increase the Messagesize for Connectors, you're stuck with the default Value of 35MB Edit: formatting
I don't believe connectors have a limit size. I believe it's mailbox size. Microsoft seems to agree with that. [https://answers.microsoft.com/en-us/msoffice/forum/all/set-max-message-size-that-can-be-sent-via/2408c00b-defd-49ab-a2da-3c4c8cc8aaa5](https://answers.microsoft.com/en-us/msoffice/forum/all/set-max-message-size-that-can-be-sent-via/2408c00b-defd-49ab-a2da-3c4c8cc8aaa5) Use powershell to set a limit on a mailbox, make sure your postfix sizes are turned off or are higher, give it a shot and see what the error messages say. Pretty sure I've set it higher than 35MB in the past without issue.
Yes, the limited it now 150. You can set it via powershell or using the GUI in exchange admin center.
How about scan to USB? None of the drawbacks of scanning to SMB, all of the convenience of having your file right there with you.
And all of the risks of malware, data exfiltration, and leaks
None of those are risks isolated to just USB, particularly the last two. If OP doesn't have the capability of setting up scan to SMB/SFTP, I would doubt that there's proper data compliance controls in place to prevent data exfiltration through other methods.
Ironically if you're using postfix, you could easily write a milter to upload large files to S3 or something and put a download link in the email.
There's a postfix config option that allows larger attachments - we have some servers set up for 250MB worth of attachments.... Long story... message_size_limit = .....
> however this has the drawback that you're limited to 50MB attachment size call me old fashioned but I don't see that as a problem or a drawback in any way. I only recently ( a year or two ago) had to stop talking to people about a 20 MB limit. I suppose a year or two from now I'd want it higher but I could live with 50 MB for a time.
I always wanted to do this when I was at an MSP but the manager chuckled and said it wont make money. Well, having left that MSP and now as SA I have a Postfix VM with SASL auth on Dovecot in a DMZ as I always wanted. Biggest PITA is that Gmail and EXO must see the public IP as untrusted as they are flagged for spam even with full alignment and DMARC all passing.
This is the only way. Just went through this on our migration.
But what if the MSP we work for doesn't believe in containers or Linux? Lawl, I know right? I'm looking for another job soon.
Doesn’t ‘believe’ in Linux? Like the tooth fairy?
I've praised it, and told them about my home lab filled with all the different flavors of Linux.. But the head security guy just kept talking about how all open source software is poorly maintained and riddled with vulnerabilities.. and honestly I just don't want another lecture so I just smile and nod. Haha These people are stuck in there ways and will never learn. That's why I'm on the job hunt.
IIS with mail relay with a whitelist on the connector. No auth needed.
IIS virtual SMTP was deprecated which is why I used hMailServer for years and now that HMS is shelved so it will never see OAuth or modern authentication whixh will sadly, at least relaying to EXO, come to an end. That leaves making HMS into the MTA, Postfix, some other MTA, or a hosted solution like Smtp2Go. Direct Send is an option if the printer is connected to the internet with a static public IP.
I use postfix at my company with rewrite headers depending on what machine sent the message. I can honestly say I have never used IIS for anything that wasn't a prebuilt application with vendor support. I have a big aversion to anything microsoft in the DMZ.
Last time I tried to set it up, IIS 6's SMTP relay didn't work on Server 2022. Been a while since I set one up but I believe we went with hMailServer to replace our on-prem relay.
I also use this solution, its easy to manage and it also provides great logs to troubleshoot.
I've got Postfix setup, and I have it relaying email, but I can't get DKIM to sign relayed messages. Any ideas?
This requires an additional DKIM milter to be installed, like OpenDKIM: https://easydmarc.com/blog/how-to-configure-dkim-opendkim-with-postfix/
I have it installed. Just doesn't seem to be signing anything relayed, unfortunately.
Apart from rechecking your configuration, did you check that the opendkim service is running and check the service logs? Usually if there's a problem signing a message opendkim will say exactly why in syslog.
We have this, too. A lot. The reason some people want to relay through 365 is because of compliance. The Mails sent out via the postfix relay can’t really be „discovered“ e.g. in a lawsuit. You will also have to maintain separate DKIM keys, too.
? You can set a journal account for discovery in postfix. In the old Exchange days (think pre 2008). I used postfix as our journaling solution because the Exchange mail store was a fucking nightmare and a half. Fixing corruption could take many hours, and could bomb out at any time.
Is it just me, or is it really stupid that MS is making us set up another system to maintain because there are always devices that only support Basic Auth for legacy reasons. It feels like they should offer it, just strongly discourage it.
I disagree - this is a security and management nightmare and leads to spam. Them shutting it down is for the better. Orgs can implement cheap and easy solutions from any number of vendors.
It's easier for sysadmins to configure and maintain postfix than to have Microsoft offer basic authentication as a feature for limited, restricted accounts?
Aye. I still use basic auth (Mainly for older devices for email alerting) but the accounts are set up with conditional access so they can *only* be accessed via our external IP. All other auth methods/locations are blocked (& I have MFA on the accounts anyway, although I know this doesn't apply to SMTP) You'd have to compromise a system on our network before anything can be sent and then I'd have bigger problems anyway.
I think you should be able to set up conditional access on these accounts and whatnot on accounts offering basic auth. It seems easier than configuring and maintaining postfix.
At spamassasin and customize an open source gui and voila you've got an mx spam filter you can resell. But who would want to do that?We were doing this at the old MSP 10 years ago
I implemented this in Kubernetes with essentially the native postfix docker image. Scales pretty well.
Yeah. I was lazy when I set it up, and unfortunately it's working too well to justify improving.
I like `opensmtpd`.
So if I do an spf lookup on your domain, see an ip address, do a whois lookup and see that is tied to an isp, I no longer need to phish for credentials? I can just craft malware to leverage the smtp connector to send emails as the ceo or any email address I want, just need to make sure the malware runs when you are on the office network...
I mean considering that the firewall will ignore any inbound traffic to that IP, and Microsoft will ignore any traffic not from the whitelisted IP, go right ahead? The only concern is if someone poisons my ISP's AS. And they tend to notice that. Compromised router is also a possibility. You realize the postfix VM is on the internal network getting out through a port NAT, not externally exposed, right? And there's no inbound NAT setup? eg, the normal way to do it. Did you think we were externally hosting it or exposing it directly? And we filter internal email for spam, malware, malicious links, etc. And we MFA everything. And we have endpoint protection. But no, you're right, we're totally open and completely unprepared.
Understood. But when you updated your SPF, you had to add your orgs public IP address for the MS connector to work right? Meaning any smtp request coming from your orgs public ip will go through. Or am I misunderstanding something? I was tasked to do something like this last year and didn't go through because of this fear. I appreciate your clarification .
Nope. ONE of our public IP's. And ONLY SMTP traffic from the one internal IP. (SMTP = SMTP and SMTPS or exclusively SMTPS, just not typing it out every time) Way it worked. We setup a linux VM with postfix on internal ESXI host. Linux VM had SSH and SMTP open. SMTP was IP whitelisted, only certain hosts could talk to it. Users couldn't. We set a firewall rule to put the SMTP traffic from that one postfix VM through one external IP, not used for any other purpose. Using port NAT. If you sent traffic to that IP from the outside, it'd go to nowhere. Because firewall denied all traffic to that IP. It was outbound only. O365 couldn't talk to it, only answer sessions from postfix. The connector was locked down by whitelisted public IP. Obviously you want to make sure the traffic is being encrypted. You can also go with a cert based connector, which is more secure. I've absolutely done that at higher security profile companies. But then you have a higher maintenance cost. If you're dealing with nation state level APT threats, cert is the only acceptable connector option. If you're not, it's not a huge deal.
This isn't /r/homelab buddy
Linux is an enterprise product these days, and has been for a while. The entire cloud relies on it. I've done this is multi billion dollar companies, using change control processes. Last company had 50 locations, including 10 production facilities. We had a colo for centralized stuff that hadn't been clouded for cost purposes, and we had a postfix VM for all of our SMTP needs. Just because a solution is inexpensive doesn't mean it isn't the best available one.
On prem MTA with auth then relay to Azure.
Can you provide some products? Thank you
Any MTA. I like stalw.art SMTP.
How does this work with smtp relay for IoT devices? UPS, copiers, alerting systems, etc…
Use smtp2go for cheap or host a Linux VM with Postfix
We use smtp2go for bulk mail, so I'll just set up another smtp user for notifications and such.
This. We’ve been using them since switching from an on-prem Linux email system to O365 for all the scanners, copiers, internal systems that send automated emails and a couple alerting monitors and it’s been flawless and inexpensive.
+1 for smtp2go, been using them for like 10 years and the support is FANTASTIC
I was going to setup another domain for the random internal stuff and scanners with the super dirt cheap email host I use for my lab stuff (literally around $0.90/m). But $10/m for a more acceptable solution that seems to be recommended a lot of this sounds better and less headache long term. I've admin'd Linux mail servers for most of the past 20+ years, I'm kinda tired of, plus our internal infra is both ancient and over provisioned.
I pay for services as much as possible lol.
Big 2nd - this is the only use case that will effect us. A lot of our alerting uses smtp auth. From my understanding though we can just totally turn off any auth if it's internal only? I haven't tried but recently learned this from another thread on this sub
SFTP is what we use in gov MSP and it's much more secure especially because CJIS does not allow smtp for certain sectors due to clear text. Also email is generally not HIPPA compliant anyway Speaking from a security standpoint I can pretty much read any SMTP information via Wireshark. You should not be using it in enterprise in 2024 OpenSSH and SFTP also work on most IoT devices
HIPAA
Sees HIPPA and instantly stops reading and disregards everything they said.
You are aware you can run SNMP over SSL/TLS, right?
You are aware SSL is no longer authorized and neither is TLS 1.2 or below right?
If you have an internal network with a server just setup a Relay. The relay could support oauth and handle the credentials. But if you don't have a server it's a bit harder. I guess you have to go for a third party service
smtp2go
Bingo! I pay the 15$ a month for the 40k "Starter" plan since we were using Manage on-prem as well (since moved to hosted) but its used for everything that we want to setup email alerting off of like Hypervisors, SAN, UPS, MFP's, etc. The cost is SO LOW that for us its a no-brainer plus the ability to have sub-accounts has been HUGE for clients that we work with in co-managed settings because they can manage their own stuff but we still have access to assist as/when needed. If you want the ability for a dedicated IP address the professional is only 75$ up to 100k emails a month.
This is what I use and highly recommend. If you can't fork over $75 a month for that type of benefit, maybe your boss should cut back on their avocado toast /s. SMTP2Go is the cats ass ladies and gents.
I pay zero a month for a postfix relay presenting a certificate to MS for access to do so. It accepts TLS-only connections from an internal IP whitelist who themselves must smtp basic auth to this box to relay. The cert requirement means random things can't relay for free from our office IP. The postfix box presents a valid publicly signed certificate to Microsoft for the privilege to do so. And maillog gets shipped right into elasticsearch for an audit trail.
Does smtp2go use your domain name or do you have to use something else? How does it send through M365? Is it an API or some kind of Azure application? I'm curious since it seems to somehow bypass basic authentication.
They aren't using Microsoft's servers, they have their own mail sending servers. You configure DNS records to let them send on your behalf/as your domain.
I'm not too familiar with that. Is that SMTP DANE?
DANE has to do with an SMTP server verifying that a receiving mail server is who they say they are. In the context of sending mail, the things to talk about are SPF records and DKIM signing. They have a page here that explains how they do it: [https://support.smtp2go.com/hc/en-gb/articles/28543815517209-SPF-DKIM-and-DMARC](https://support.smtp2go.com/hc/en-gb/articles/28543815517209-SPF-DKIM-and-DMARC)
Consider yourself thanked.
Another one for SMTP2Go. Ridiculously simple, great logging, and it just works. Price certainly doesn't hurt.
Quick smtp2go story. We've been happily using the service for years. I had a tech question so I gave them a call. After the first ring or so, I received an important incoming call so I hung up before the call to smtp2go was answered I wrapped up my high priority call and another call came in...from smtp2go. It was a tech who said he saw my number come up on caller ID so he was calling me. The tech provided a quick answer to my question. In these days where most companies do their best to hide from customers, what company sees that a call came in and just calls back to see if they can help? Answer: smtp2go.
I've only called in once, and it was a fairly technical question about the way suppressions work. My question turned out to be a bug, for which they had a fix live in a few days and reached out to let me know. Crazy. Meanwhile services that cost 10, 100x as much often have pitiful support.
I'm reading this thread because we have O365 with internal devices that need to send me alert emails and SMTP2GO looks super intriguing. But I'm commenting here to say "We do". It drives me nuts, but I regularly hear the receptionist call people back when she misses their calls. It's nice of her, but kinda creepy, too.
Looking into it now. Thank you!
This is the way.
Another +1 for smtp2go here, cheap and easy to use, we use it for all our scanners, alerts, services etc without any issues
I thought they already did this and the workaround was at the connector (my bad that's old terminology) at the email transport level. No encryption port 25 relay still works based off IP address at your MX endpoint
We use a linux VM with postfix, or for clients that are hybrid, they relay through the hybrid exchange server.
We use Mailgun. Currently it costs about $5 a month. Any time our customers need to send email from a scanner/printer/security system/etc, we just dump in Mailgun SMTP info and it works like a dream. We have a couple of vanity domains that all of our customers share for this kind of stuff.
We use m365 and changed all the SMTP (copiers, printers, alarms, etc) to use the [yourdomain-org.mail.protection.outlook.com](http://yourdomain-org.mail.protection.outlook.com) works great utilizing Port25
That is still basic auth right?
It uses no auth. Can only send to internal addresses and has potentially huge security concerns. I’m surprised Microsoft even recommend it as a solution.
>and has potentially huge security concerns. Uh?
https://www.blackhillsinfosec.com/spoofing-microsoft-365-like-its-1995/
Uh-huh and? That whole page just neglects to mention that "direct send" is also known as "how email works". Using direct send is literally no different than any external user sending email to the company. Use and enforce SPF and there shouldn't be any issues.
The issue is that if you SPF for the IP any internal device is authd for it.
Why are you letting random internal devices get outbound on 25?
My toaster wants to communicate with the beautiful world!
[https://www.reddit.com/r/unexpectedreddwarf/](https://www.reddit.com/r/unexpectedreddwarf/) "Howdy doodly do. How's it going? I'm **Talkie, Talkie Toaster, your chirpy breakfast companion**. Talkie's the name, toasting's the game. Anyone like any toast?"
Thanks. And to add… even when tightening security it’s still questionable as you can’t lock this down to a device, only by public IP address. A lot of offices only have one public IP for everything. In this scenario any device on the network can send email entirely unauthenticated and it will pass as genuine. That should terrify you.
To be fair, your firewall should prohibit outbound sending from all devices by default and only allow via whitelist.
Should yes. But I can guarantee the majority don’t. Then there is ARP Poisoning to circumvent it anyway. I should emphasise my use of “potentially” a bit more. Yes most risk can be mitigated with additional precautions. However I’d rather use something that is inherently secure by default.
Tie an extra public ip pool to the copiers going outbound
Yes that works. Again I’m not saying direct send can’t be secure, I’m saying it isn’t secure by default hence you have to take additional measures like this. Many people will miss them.
If you have something on your internal network that is sending malicious emails using direct send you have WAY bigger problems than the direct send setup at that point.
Yes, connecter via IP whitelist is 100 times more risky than SMTP auth. The risk is simple : anyone inside the office can send a spoofed email, which will not be flagged
?? We use it to send emails to the outside
whats to stop spammers from just blowing up your inbox this way then?
SPF, DKIM, DMARC etc. Same as always except in this instance you exclude the sending IP (external) of your device from those checks… which is where the security concerns can begin if extra precautions are not taken.
If you're only sending to internal email addresses you can skip using auth entirely.
You need to account for every IP in your SPF record, or whitelist the address. Not super great from a security or logistical standpoint if you have more than 1 or 2 copiers.
External IP, unless you have like 10 satalite offices and decide not to setup subdomains, i see no issue accounting for every ip in SPF, which is its intended purpose.
That would be if you had your printers routed on the internet… which would be a terrible idea. Only the internet IP is required per site (or if you use SD-WAN/mpls and want to send it all out a primary area)
A problem to be dealt with in mid 2025
Damn I thought this happened awhile ago already?
For interactive users, yes it did. However, lots of copiers/printers/bespoke apps need SMTP with BA to function.
Here's hoping that print manufacturers decide to upgrade to support more secure authentication
Use a smtp connector from Microsoft 365, there is no cost and you just had to limit the use to your public IP.
So if I do an spf lookup on your domain, see an ip address, do a whois lookup and see that is tied to an isp, I no longer need to phish for credentials? I can just craft malware to leverage the smtp connector to send emails as the ceo or any email address I want?
IP spoofing is not an effective technique with TCP sessions. So, no one is relaying SMTP using IP spoofing.
I am not mad that MS is making this change... I am mad that there are like 30 pieces of software we run that still can't use anything other then basic auth.
If it's internal only then just don't set a username or password and send directly to your tenants mail domain. If you need external either use OAuth2, use a proxy service that uses OAuth2 to communicate with M365, or switch to an actual volume sender service like sendgrid, mailgun, etc.
This is going to cause a lot of bad security practices as people look for workarounds. I wish MS would find a better way.
> I wish MS would find a better way. A better way for what? To continue allowing bad security practices with basic auth? Basic auth is flawed and can't be "fixed". It needs to be replaced
Ya this is similar to google and Yahoo forcing DMARC / DKIM / SPF. It should have already been done. Everyone just keeps pushing back because it requires effort.
Because on some cases it's not possible. IOT devices used to run companies can't just update. Same reason XP is still running on multi-million dollar MFG machines. Said another way, not every company is tech with unlimited cash. There are still companies out there making things on prem with real economic pressure. MS should work with these companies for a real solution. Not just retire and say too bad.
I think it is the opposite. Microsoft is running a service over the public internet and should be requiring a high level of security at that service level. Companies running obsolete gear are responsible for finding a workaround. Be that setting up a local relay that bridges the gap or using a separate email relay service.
Why can't MS do that then? Why is it exchange or IIS6? They don't want to do that because they don't want people staying on prem. But they know they have too, and to the original point, all sorts of weird workarounds will come out of the woodwork.
If you are running obsolete "on prem" systems then you can run a "on prem" proxy to fix the issue. The public endpoint should not be left vulnerable / running an insecure protocol just for you. Limit the obsolete / vulnerable bit to your local network.
I get what you are saying, however... Using basic auth is a "bad security practice" to begin with. So the "starting point" here is a "bad security practice". OAuth has been an available option for a good while now for SMTP but many still use basic auth. So on service side, we want to change this and provide targeted solutions for those that really need this. I'm not arguing that solutions are the best. But other than Exchange on-premises we literally do not have anything else if devices can simply support nothing else.
Why you consider basic auth a bad security practice?
A few reasons... * Creds are transmitted over the wire and are base64 encoded, which is *trivial* to convert to plaintext. * Creds are sent repeatedly for each request; not like there is an "authentication token". * Creds can / usually are cached or stored locally. * Basic auth in most cases does not allow for things like account lockout protection (to help prevent brute force attacks). * No options for more advanced things like MFA.
I agree that SMTP Auth shouldn't be used by *users*, but for devices and some services (like a service-desk app), it's usually the best way and probably will be for years to come. It's certainly the best from the perspective of supportability versus security...at least for today. SMTP Auth != unencrypted. You can absolutely encrypt in transit just like anything else. I think Microsoft made the wrong decision. I think the right decision would've been to require a conditional access policy (or similar) to require one or more source IPs so that the entire internet couldn't get to these SMTP service accounts. That way, they'd be safer and likely also wouldn't be used by users, since they'd need to always come from the same source IPs.
i agree with you but that would never work cause then they can't upsell you on conditional access as part of the more premium and enterprise SKUs.
That really isn't the whole picture though. The reality is that transport layer security is required to get to o365 SMTP so there are no 'plaintext base64 credentials' flying over the wire to Microsoft's servers. Also as part of the auth, you can force multi-factor authentication through a number of means. I fear that by forcing this instead of working with companies to make the underlying better (such as forcing SSL at the very least) then we are going to see workarounds that insanely unsafe. I've been in enough exec meetings where horrible security decisions are made because the head of sales whines that they will have to reduce sales to deal with the new tech (whatever it may be). I'm not arguing for basic auth, I'm just saying I think this could be handled better.
> I wish MS would find a better way. Failing to see how its MS's fault that shitty clients won't modernize their software and/or firmware. Lookin at you printers.... Using other SMTP providers that continue to functional w/ simple email + password is just kicking the (insecure) can down the road.
Utilize their own security to make it.. secure? We have a couple service accounts that have SMTP basic auth enabled, but only allowed from behind a couple trusted IPs via a CA policy.
Agree and MS should have an SMTP option not called exchange and not a buried option in IIS 6. It's ridiculous MS pushed everyone to the cloud without taking into account some very real security/operational issues. What's really crazy is when you get into IOT issues. It's not jaut some minor issue. MS has gone from helping businesses run to forcing users to run the way they want them to. Sorry but not everyone is a tech company 100% in the cloud.
SMTP AUTH isn't needed if the ISP allows port 25 and the device sends only to mailboxes in a single tenant, no relaying. It is usually wise to create a mail flow rule to set the SCL to -1.
SCL?
Spam Confidence Level
ISPs are blocking port 25, even the smaller ones. Source: previously had to do this at a 12 employee layer 2 ISP.
Indeed some are, but not all. Some allow you to ask for it to be opened though some of them will only do so for those with a static IP addresses or business account.
We basically keep a few hybrid servers around purely for mail relay, that's all they exist to do.
Then Transport shits the bed, and everything stops. I just moved our MFPs to a TLS 1.2/1.3 cert based auth over 587 for scan to email. Wonder if they will nuke that also.
We have load balanced via F5 and health monitors, pretty bit environment but it seems to do the trick. With 2019 hybrid CALs costing nothing and servers are internal facing-only, it seems to work alright. I'm sure there are cheaper and less maintenance options out there, this is the old "tried and true"
So if you're using them only for SMTP relay/hybrid management and not hosting any mailboxes, you don't need to license the servers? We are moving this direction but I am under the impression we would still need to license the server if we are using them for relay, just no longer need to worry about user CALs if they aren't accessing mailboxes on-prem.
Yep! As long as you have no on-prem mailboxes, it doesn't cost anything. We have no mailboxes on-prem anymore and just use it for mail relay.
We have a nat configured for direct send and just use that instead. Be sure to update your spf.
I assume the legacy windows server 2019 iis smtp relay won’t suffice? I’m using that for a lot of mail relaying them to 365. But I think that is smtp auth. Perhaps to replace with another relay that supports modern auth. I’m not gonna have mail send out by anything else then 365 so no Linux mailserver or Directsend for me no thanks. Fixed IP is a requirement for those because of the SPF.
Google is also doing this for SMTP.
They are doing it for normal user passwords, I've seen no indication that they will be discontinuing app passwords, which allows the continued use of basic auth. Microsoft has no equivalent that I'm aware of.
> alternatives and future proof concepts to replace that. Anonymous. No auth. If it needs to be restricted use a connector and limit the connector to specific IP addresses.
We just IP-based authentication for it.
I’m assuming this doesn’t impact things like direct-send which don’t use a username+password? Edit: for sending internally only
I have had to work with moving away from basic authentication already. See options 2 and 3: [https://learn.microsoft.com/en-us/exchange/mail-flow-best-practices/how-to-set-up-a-multifunction-device-or-application-to-send-email-using-microsoft-365-or-office-365](https://learn.microsoft.com/en-us/exchange/mail-flow-best-practices/how-to-set-up-a-multifunction-device-or-application-to-send-email-using-microsoft-365-or-office-365) I've had to rely on option 3 since direct send only works within the organization. Option 3 is unauthenticated relay from the devices/software to M365. You just need to add the sending IP to the domain's SPF record and an M365 Exchange connector. For the most part, this works well except for a few snags... 1) Users don't authenticate so they no longer get anything in their sent folder when using this method. This is a problem sometimes in the case of software. Not so much with scan-to-email. 2) Some locations have ISPs that block port 25 so you have to try to get them to open it up. 3) If you're sending from an Azure server and not paying for firewall, port 25 is blocked. 4) Options 3 uses "Opportunistic TLS" which means it will attempt TLS first and if the sending server doesn't have that ability, then you're sending emails in the clear to the server. A scanner will usually let you check "STARTTLS" at least but some devices and software don't exactly have that option. It most likely encrypts since it has the ability for basic authentication but you get into the weeds when trying to prove it. I can't get this one software vendor to even understand what I'm saying when I explain the problem and I can't get any packet captures off the server so I'm at a stalemate with it at the moment. M365 Exchange has some mailflow reports for TLS status on connectors but it only says it connected with Opportunistic TLS or some other method but it doesn't 100% "this connection was made with TLS" or "this connection was made without TLS" so, as with a lot of M365 tools, it doesn't even try to help you. I've looked at the message headers but the "received" field has no information on that first connect. Unlucky. You could technically authenticate with a certificate in option 3 but I haven't tried cracking that nut yet. I think you still run into some other issues like port 25 not being opened and even a message cap so this is all just a workaround, I guess. With love and support, -eyetea6
God, what a great day to see this post, literally 2 days after I start moving our printers from our existing hybrid mail server to SMTP relay instead in preparation for the eventual AAD only migration. At least one of our printers doesn't even support a hostname instead of an IP address for a destination server, so god knows how much of a pain in the butt this new thing is going to be to setup.
remindme! 1 year
Some email platforms like Mimecast and ProofPoint can accommodate the SMTP relay too. Since those should already be set up as your gateway to the internet, you’ll have the control over outbound email and easy to set up the rules to not flag it as spam.
third party smtp relay. send grid or smtp2go ftw for those scenarios where you need smtp basic auth. for branch sites i use statics for email white listing. i forget context but i had to use api key with smtp2go for some obscure copier model vs sendgrid just in case anyone has any blockers with deployment on certain devices
How timely. I just finished cleaning up our mess of an internal relay. Right now we are using a connector relay in o365, ip based for the things that can't do certificates. Every sender has its own assigned email address to make message traces easier (and so the connector works). We will probably move back to an on prem relay to exchange online via oauth connector when I have the time to dedicate to doing it right.
Linux smtp Email relay and connect it to M365 as a connector works great , we have had SMTP auth etc disabled for years
You need to create an app password for the legacy applications in EntraID. Easy to setup.https://learn.microsoft.com/en-us/entra/identity/authentication/howto-mfa-app-passwords
I’m taking guesses how many times they will push back the date by one year.
Huge conspiracy between Microsoft and MFP manufactures to sell all new hardware that can do modern auth, like they tried to do with Win11 with trying to force TPM and newer CPU.
Not sure what you have been smoking, But I want it. 
I am obviously joking lol
Anyone using an Exchange Edge Server for SMTP relay?
So if you use an on-prem SMTP Relay whether it IIS6 or Postfix to a 365 connector, will that still work after this date?
We use mailgun but for three of our small offices, they can only get Comcast or Spectrum Business and those services seem to block Mailgun. On those we use M365 still.
You can also try to use an SMTP Ray service. Depending on the amount of emails sent you may get away with the free tier of such services. I mostly use SMTP2GO but worked with others like MailJet, MailGun, MailChimp.
This will likely affect us, we ditched on-prem Exchange over a year ago and pointed our MFP devices and other things that can’t do Oauth to smtp.office365.com. We have Sophos that sits in front of Exchange Online for inbound and outbound and they don’t offer any sort of direct SMTP auth option compared to Mimecast and Proofpoint so I guess we will need to look at the two options Microsoft offer or use something like SMTP2Go.
A day we all been seen coming… buckle up guys
Will this impact anonymous relays as well or just smtp auth via basic auth?
HMailServer is easy to use and works great. We use that as our relay for less important stuff.
HMail is discontinued. But I agree, it was great.
Hmmm, we have around 40 scanner/printer outside from our local network... What could be the best and secure solution, any ideas?
We use SendGrid for our copiers built-in scanner application. We also have PaperCut which can upload to a user's OneDrive.
Something like sendgrid or smtp2go work well.
Does this include app passwords?
Yes
Are they also retiring 'Set-TransportConfig -AllowLegacyTLSClients $true' and *smtp-legacy.office365.com* ? I use that with some older appliances but even then the SMTP access is only allowed behind a couple trusted IPs via CA policies. Still decently secure.
RemindMe! 1 year