"Enable Domain's SMTP auth setting for local deliveries" at SERVER LEVEL is too strict. Some customers need this option enabled and some others need it disabled.
Problem reported by Gabriele Maoret - SERSIS - 9/29/2021 at 9:24 AM
"Enable Domain's SMTP auth setting for local deliveries" (see image below) at SERVER LEVEL is too strict.

Some customers need this option enabled and some others need it disabled.

An example of a customer (with @DOMAIN.COM mail domain) that need it disabled is one that use MailGun to send mail from his website and want to use an existing email address as a sender and want a copy of the mail in his inbox.

The SPF is configured to allow MailGun to send mail for @DOAMIN.COM (like the SmarterMail Server is), but the interna user in SmarterMail can't receive his copy beause of this setting.

Is there a way to enable/disable this setting per domain?

An alternate solution is to bind this setting with SPF check to permit local delevery without SMTP auth if the sender IP fulfill SPF request.

6 Replies

Reply to Thread
Gabriele Maoret - SERSIS Replied
Hint: it would also be interesting to add an option to bypass this control for mail servers that are explicitly present in the domain SPF list.
Sabatino Replied
I did some tests because a user needed it

If you have this on a general level
and set this on the domain
the effect is just that.

They can send without authentication to all local users but authentication is required to relay

However, I find the solution partial and in any case at risk

In fact, by doing this, if the sender of an email is from the domain on which the option has been disabled, it can send to any user of the server.

I wish it could only ship to the domain on which this option has been enabled.

Sabatino Replied
I forgot to add that an unauthenticated local submission does not seem to be within the limits and functionality provided by

Priority and Throttling

So if someone discovers a sender / domain on which the local authentication option has been disabled they can spam server users
Gabriele Maoret - SERSIS Replied
@Sabatino: this is not a valid solution because it exposes you to risks of spoofing/phishing
Sabatino Replied
Yes. as I have in fact also highlighted it is not a good solution but the only one possible at this moment. unless you combine it with spf ... but sm is apparently ignoring us. yet many web servers have this problem ... at least that's my experience.
Sabatino Replied
I'm discussing with kyle (luckily there is otherwise we would have to invent it :)) via
ticket about the problem.

I wanted to share my latest observation with everyone

hi kyle
I have been thinking about the problem

The problem stems from the fact that smarteremail considers messages arriving from external emails differently than those present on the server.

I try to explain myself better with an example

Suppose I have a xtest.com domain on my sm server

with an email info@xtest.com configured

Now, an email arrives from test@gmail.com, antispam, spf, dkim etc. is applied. etc.

Instead, an email arrives from an external ip: xx.xx.xx.xx which has as sender info@xtest.com
and recipient info@xtest.com or any other email on the server

sm in the basic configuration asks the user for authentication. If I disable the auth for local users it creates a security problem

In my opinion it should behave the same way as it does if the email is not on the server

That is to apply the rules of antispam and so on normally, in particular the spf

And so if the score is high it ends up in spam

In this way I can safely put the client's web server IP in the SPF, because it does not create a security problem

Reply to Thread