2
SmarterMail doesn't look at SPF record in DNS when sending email?
Question asked by Montague WebWorks - 7/21/2021 at 9:48 AM
Unanswered
I have a system set up for clients to send opt-in bulk emails from their website through a SM bulk email server, and want to send the emails from: their domain, which is primarily housed on another, transactional email server. If Auth Bypass is set on, it works fine, as long as my email script logs in with the proper credentials. But that is a little dangerous. Hackers can obtain the un/pw and then go to town.

I have control of all my clients' DNS and have both the main and the bulk server IPs listed in their SPF record, but I still get the relaying error when attempting to send emails from their domain and I have Auth Bypass set off.

An expert on SM and email in general told me that mail servers always look locally, and never at the domain's DNS. This has always frustrated me, and made me wonder why the email server can't do a DNS lookup to see if sending the email is ok? The answer I was given was "this is how every email server works."

Me? I think it's just lazy. And don't tell me that it's a security feature. With all the other settings available in SM, an admin could wreak havoc and open the box wide to the world.

So, can someone from ST tell me if this is in fact the case, that email servers never check the DNS records for whether or not they are ok to send the email, and if so, why? I mean, DNS is fairly unhackable, just as much as any setting in SM.

Perhaps this could be added as another switch? "Check DNS for SPF Authority" or something.

Thanks
Mik MullerMontague WebWorks

4 Replies

Reply to Thread
4
Nathan Replied
SPF is a bolt-on technology designed to try to limit the ability to spoof so as such it is not mandatory anywhere. The latter point could be argued, particularly with the large players increasingly using it but that is the position from an RFC perspective.

Mail servers will always (okay in 99% of cases) attempt local delivery if the domain is defined as it determines it is authoritative for that domain by virtue of it being defined. Historically this made sense, why go to the 'expense' of DNS lookups if you know you host the domain by definition. 

To resolve your immediate issue setup the domain the user wants to send from in SM but configure the 'Inbound Message Delivery' as 'External (Use MX)'. This will let the user authenticate, you can lock down so they can only send from the domain or the specific address within the domain. Importantly, if they send an email n to their own domain (or someone else on the same SM box does) then it will be delivered to their real MX. 

Addressing your question as to why a mail server does not check if it is allowed to send by checking SPF that is a good question. As already mentioned it is not part of the standard so is not inherently there. Also, the SM mail server that hosts your mailboxes does not necessarily have to be present in the SPF record - assuming you are routing outbound email via a gateway, in which case that Internet facing gateway would need to be listed. So, with this quick example you can see it could be problematic in certain scenarios.

However, we implement such a feature on our Exim mail gateways in tandem with having to specifically authorise the domain. The reason for doing this is not so much as an ACL but simply to ensure clients have setup and maintained the correct SPF record as a lack of SPF or invalid SPF can damage the reputation of a sending IP with the big players.

So I would +1 it as a feature within SM but it may be something that is configurable, i.e. perhaps have the option of validating the IP(s) of the SM server against the SPF record and/or the presence of a specific 'include' which would infer the same valid nature in your environment.




0
Montague WebWorks Replied
I host about 130 domains on my main MX, and don't want to have to add those to my bulk email server, too.

Yes, a setting that could say 'look at the SPF' or something just as simple.
Mik MullerMontague WebWorks
0
Douglas Foster Replied
You need to add your originating server to the server whitelist on the bulk messaging server.  (System admin... Gear [icon]... Security... [Whitelist] tab... [New] button.   This will allow messages coming from the originating server, and destined for the Internet, to pass through without authentication.

Historically, open relays have been a huge problem.   Server A (domain A) finds Server B (domain B) on the Internet.  Then Server A sends a message to Server B addressed for domain C.   Server B sees that the message is not for domain B, so it sends it on its way to the server for domain C.    Of course, the message is malicious, which is why Server A wants Server B to take the blame.

The solution is closed relays -  by default, systems only accept unauthenticated SMTP messages from remote servers for locally hosted domains.    Authenticated users are allowed to send messages to both locally hosted domains and remote domains.  

Whitelisting an IP address is an alternative form of authentication.   Your second server is functioning as an outgoing gateway for these messages, so whitelisting the source server makes the most sense.   Conceptually, the second server is relying on the first server to have performed authentication before forwarding the message, so the second server does not need to repeat the authentication process.

SPF would apply if the messages were addressed to a domain on your second server.   Since this is not the case, it does not apply.

Hope this clarifies things,

Doug
0
Montague WebWorks Replied
Hi Doug. I think you may misunderstand my situation. The bulk email server is used by my webserver for SMTP duties. The issue is in attempting to send From: a domain that is not present on the bulk server, but *is* present on my main email server (ie; this is a customer sending a bulk email from their website who wants to use their domain as the From). I have an SPF record for every domain I host, indicating the bulk email server is authorized to send emails on that domain's behalf.

My problem comes in because the bulk email server fails to see the domain locally. The domain is present on the main email server, but not on the bulk email server. I'd prefer not to duplicate the domains on the bulk server as that's a pain and a potential licensing issue.

My ask is if a new y/n setting could be added to instruct the bulk email server to do a quick SPF lookup if the domain isn't local before failing it for relaying.
Mik MullerMontague WebWorks

Reply to Thread