SMTP server, IP address only

HCHTech

Well-Known Member
Reaction score
4,252
Location
Pittsburgh, PA - USA
I've got a handful of devices at clients that have alert notification capabilities, but only allow for IP addresses to be used as the SMTP server. I'm pretty sure this rules out using O365, and places like Sendgrid and SMTP2GO appear to reserve dedicated IPs for their higher cost plans ($90-$150/mo).

Is there a less expensive (or free) option I could use?
 
Last edited:
Doesn't rule out M365 at all... BUT it does require using an SMTP proxy / relay on the LAN.

I've used IIS for this in a few places: https://docs.microsoft.com/en-us/ii...-iis/configure-smtp-e-mail-in-iis-7-and-above

Just configured a local SMTP relay thanks to IIS services to "smart host" login to whatever I need to send to, or in some cases just push junk to the TCP 25 MX record for the 365 tenant. Depends on what I'm after. The IIS proxy gets an IP white list of stuff that can send to it, and off it goes.

You could configure sendmail on linux running on a raspberry pi to do it if you want really cheap.
 
Last edited:
BUT it does require using an SMTP proxy / relay on the LAN.

Ahh, of course - that makes sense. I've messed with smarthosts and all of that back in the on-prem Exchange days, but my brain didn't put 2 and 2 together to come up with that as a solution without Exchange on prem. Thanks - two of those clients have servers, so this will be my weekend project. I'll save the 3rd client for another time since they don't have a server and I need to think about the ramifications of installing IIS on a workstation a bit before going down that rabbit hole. I'm nowhere near ready to add raspberry pi's to my arsenal - haha.
 
I only use Linux for my data recovery machines, and don't relish working with it when I don't have to. In my (lack of) linux experience, every question that comes up turns into a field of study - haha. I'm old and my brain gets less and less facile every day.

Plus, what about ongoing maintenance of the thing. Can you remote into it to diagnose why it isn't working? Can it notify you if there are problems? For client solutions, inventing hardware doesn't seem like a robust answer, IMO.
 
I only use Linux for my data recovery machines, and don't relish working with it when I don't have to. In my (lack of) linux experience, every question that comes up turns into a field of study - haha. I'm old and my brain gets less and less facile every day.

Plus, what about ongoing maintenance of the thing. Can you remote into it to diagnose why it isn't working? Can it notify you if there are problems? For client solutions, inventing hardware doesn't seem like a robust answer, IMO.
It's $100 if it breaks you replace it. In this setup it's got one job. A backup image is all you need. If it is being weird you nuke it and pave.
 
If the site already has an MS server in play, configuring IIS to do SMTP is near trivial, and it's one less system to maintain.

Besides, the windows server is already being image backed up right? One less thing to worry about.

It takes me just as long to make IIS into a secure relay as it does sendmail. Just depends on what's easier to deploy, because of what's already there.

And yes, I can monitor both platforms, so that bit doesn't matter as much.
 
If it was me I'd use Post-fix. Now whether I self host or use a cloud VM is a different matter. What's really important to insure you have all the anti-spam protocols like DKIM, DMARC, etc setup. Without that mail flow will be unpredictable, as in spotty.
 
If it was me I'd use Post-fix. Now whether I self host or use a cloud VM is a different matter. What's really important to insure you have all the anti-spam protocols like DKIM, DMARC, etc setup. Without that mail flow will be unpredictable, as in spotty.


Too much work, it's not about setting up a mail server that transmits to the world. It's just about either having it handle the authenticated send to the already public mail service, or unauthenticated send and manually authorized for the same.

You shouldn't have to mess with any of the above DNS records to make all this work. Building a fully functional mail exchanger is for a very different task, and while a valuable thing, it's a TON of work, and a bucket of maintenance for a simple relay to make up for crappy SMTP clients on some scanners.
 
You shouldn't have to mess with any of the above DNS records to make all this work. Building a fully functional mail exchanger is for a very different task, and while a valuable thing, it's a TON of work, and a bucket of maintenance for a simple relay to make up for crappy SMTP clients on some scanners.
I disagree. Framing the original situation as I understand it. Site has appliances that can't process DNS so the SMTP must be accessed via IP address to send notifications. So the email will hit the public Internet and any sending domain that doesn't have all it's I's dotted and T's crossed will have problems if it's hitting ecosystems like Google, Outlook.com, etc, etc. I've been running my own email server over 15 years and have watched how all the changes to combat spam, phishing etc have played out. All those rules apply to the SMTP server. When it comes to email you have to play by their rules for a trouble free experience. The only way around it is if the sending and receiving domains are self controlled. In that case you can turn off all that stuff on both ends.
 
@Markverhyden

I've supported a ton of stuff like the OP, PBXs especially old ones love to do this.

You have server, and port fields for SMTP like you'd expect, but only numbers and .s can go into the server field. So you slap a small SMTP relay on something on the LAN, and use that local address. That relay is a smart host that logs into the real exchange to move mail to the world.

This way all I have is a blip of code running on something, even a Raspberry Pi can do it... and I don't have to change anything in my public DNS records because the smart host isn't sending to the world, it's doing an authenticated send to a real exchanger that will be doing that.
 
Back
Top