Hello,

If I recall correctly, in previous versions this check wasn't always working, especially when the customer IP address was whitelisted somewhere in SmarterMail.

They maybe fixed this in this release althought I see no changelog entry about it.

Have you checked the SMTP log to see if their MAIL FROM domain name matches the authenticated user domain name ?

Maybe your customer has already a mismatch here and that it now raises as the check seems to work now.

Kind regards.

EDIT: checking our server SMTP log, it seems that the check now works and it wasn't before, because we have a few of these 550 entries for users trying to send mail with an invalid from not matching their auth domain name. Before this build it was letting this through.

Hello,

It seems to be related to non-authenticated inbound connections, and the sending IP is in the authentication bypass. Since it is not an authenticated user, the FROM address may not be a valid domain/email account on the server, however, the destination is.   It looks like a bug was introduced in this mechanism.

Hello, 

That would be a problem indeed. Do you have any of these in your smtp log (set to detailed) ?

[2020.12.24] 01:26:44.968 [x.x.x.x][35234893] rsp: 550 From domain must match authenticated domain | Info: domain(domain.tld):domain.tld, authenticated username: user@domain.tld, sendersEmail: sender@domain.tld

It would be interresting to see what's in authenticated username, if they are triggered even for non-auth sessions.

OK, then we`ll need to hold off the upgrade until this is fixed or cleared up. Thanks for reporting it!

Good morning, and thanks for your patience as we have been out of office for the holiday. I'm reviewing your issue report, but we'll need to investigate these further before providing guidance. Can I have you submit a ticket on this with the sender details (from address) so we can check out your logs in more detail? Thanks Jason!

Running into the same issue here. Rather simple to reproduce: add an IP to the authentication bypass list, send an email from that IP with the from address set to a legitimate domain on the server but a non-existent user in that domain.

I was using a generic email address (alert@existing-domain.tld) with an existing domain (but non-existent user) for sending alert type messages from various pieces of software, with the sending IPs in the authentication bypass list. In the meantime, I've created the user in that domain and have the sending IPs authenticate - which is probably a better long term solution (for me) anyway.

Thanks,

 Elazar

Hello all, just wanted to provide an update on this issue.  The devs were aware of the issue and have already submitted a fix.  This should be available in the next public release.

Hi Larry,
good news - do you already know the date of next public release?
If an updated public release will be available during next days it would be ok to wait a few more days until then - otherwise I would probably open a support-ticket for a custom-build with the fix.

Indeed, a build with this fix would be useful to have this week - is that possible?

+1 for a build

Hey all, I believe we'll have a build with this fix in this week.

We just published a release that addresses this issue.

Hello everyone, 

I wanted to make you aware that today's public build should resolve this issue:

SmarterMail Downloads: https://www.smartertools.com/smartermail/downloads

Build 7669 (Dec 30)

If you continue to have any trouble on this build, feel free to let us know here. However, I'd also encourage you to start a support ticket for a one-on-one review. 

Thank you,

The fix appears to fix the issue if you have 'SMTP Auth Bypass' enabled in 7669 but not if you are only whitelisting an IP for SMTP.



This always worked before as we were able to whitelist shared web servers IP addresses so that if you have a "contact us" form on a website you could have the "from" address the visitors address they entered on the "Contact us" form.

Since upgrading to Build 7669 we are getting 100's of "550 From address must match authenticated address" from our shared hosting web server IP addresses.

In 2021 (and, well, since a long time) this should never be the case. 

Using visitor's e-mail address as the From of your form result e-mail will lead to trouble with SPF and other identification mechanisms and could cause your mail to go into spam folders, because that is considered as e-mail spoofing.

You should instead use a from address from a domain that exists on your server and that has a SPF record matching your mailserver. Then use visitor e-mail as the Reply-To header, so when replying to the form, the reply will go to the visitor e-mail address.

Regretfully as we have used this method for nearly 20 years, we host thousands of websites where they set then 'from' address on the 'contact us' form as the from the address of the vistor and this has worked in SmarterMail since we started using it in 2007 up until 7661.

The changes in SmarterMail since 7661 mean our log files are full of thousands of rejected emails from websites IP addresses.

It would be a big change to notifying customers and asking them to change the way they send emails from their websites. It is doable but would need time to notify and work with thousands of customers to ensure they have made the changes to their websites before the changes can be rolled out.

As this is a change in SmarterMail that changes decade-old behaviour then have an option that allows it to work in the old way would be better rather than making the change mandatory and not even mentioned in the Release Notes.

For now, we have had to roll back to 7642.

To be clear, the "fix" resolved part of the issue but not the entire issue.

Previously, if an IP was Whitelisted, then Settings -> Protocols -> SMTP In -> Require Auth Match did not apply.  There is not a way to replicate this capability in the current build.  With the "fix" you can Bypass SMTP Auth, but some of us want to Require SMTP Auth so we have an account in the header to track and bypass Require Auth Match.

It would seem that several Bypass functions were enabled through the single Whitelist feature and now those functions are being broken out into individual parts.

At Settings -> Security -> Whitelist, there are SMTP, SMTP Auth Bypass, and SMTP Spam Bypass options.  My suggestion would be to add an SMTP Auth Match Bypass.  This would allow us to still require authentication so we can properly track who is sending messages and allow the From address to be anything, which is quite helpful for Contact Us forms so that we can easily reply to the person who completed the form.

Thanks,

Dave

Yeah, Whitelisting an IP address shouldn't disable Auth match as you might want to whitelist an IP against the IDS but still check if the from address/domain matches to avoid the users using bogus "from" addresses.

On another hand there are some cases where you would like to also skip the Auth match for some IP

That said I'm still convinced that the "From" should be an e-mail from an existing domain on the server and that "Reply-To" header is used instead for directing the replies to the right address. Using the visitor address as From was ok until mid 2000 before SPF started to be used.

Check "What’s wrong with From header being the visitor’s email?" chapter)

Still, on SM Auth match is a global server toggle if I'm not wrong. So yes your solution to add a specific Bypass entry for this would be a good compromise.

I agree you need could do with two options.

The SMTP whitelisting is useful for the IDS as you don't want a customer using the wrong username and password while sending emails from their websites and blocking the IP of a shared hosting server affecting all customers on that server.

It is often the case that a user changes their mailbox password but forgets they also need to update the password when their website sends emails.

While I would prefer customers use 'Reply-To' on their websites, with close on 10,000 domains hosted and this not being a requirement for the last 20 years I foresee lots of unhappy customers if this change is forced on them. It would be good to have this for new servers that go online.

Therefore it would be nice to see another option on the whitelist to disable the SMTP Auth Match for certain IP ranges.