SMv16 -> SMv17 - incoming gateway completely broken
Problem reported by Webio - January 20 at 10:59 AM
Submitted
Hello,

so ... I've upgraded main SM instance from v16 to v17. Everything is working well so I've decided to upgrade also my incoming gateways from v16 to v17 .. and guess what .. they are not working AT ALL. After upgrading them to v17 they just stopped working. Local SpamAssassin is not performing ANY incoming mail checks and ALL messages are being bouced with error:

550 <.......> No such user here

Does this is somehow related to licesing issue which I had also with latest v17 when I've upgraded to this version from v16? Even if I had provided license information during installation process I had also to perform multiple times reactivate license after upgrade has been completed to make SMv17 work correctly. Issue with incoming gateways are that they are licensed as free product so I can't reactivate them.

Any suggestions?

Thanks

EDIT: API Log from incoming gateway contains:

[2019.01.20] 18:07:51 Object reference not set to an instance of an object.
[2019.01.20]    at MailService.WCF.Sharing.GetSharesAvailableToUser(CurrentUser currentUser)
[2019.01.20]    at MailService.WCF.MailWCF.MailService.GetFolders(String token) 
EDIT2: Another thing is that in incoming gateway we can't provide IP address in gateway configuration form. Also I can't provide https in URL field because it only accept domain name but when I return go incoming gateway configuration form it is showing http:// in URL field.

EDIT3: So I've uninstalled v17, removed whole dir, installed v16 and used mailConfig and spamConfig bak files made by v17 installer. Not it works as it should.

5 Replies

Reply to Thread
1
Sébastien Riccio Replied
Hi,

Thank you for reporting this. We were about to start the process of upgrading to v17/100. Hopefully I saw your post and stopped everything as we are also using incoming gateways.
It would have been catastrophic that all of our customers incoming mails get rejected with a "No such user here". 

As far as I know it's a 5XX error, so there are no retries from sender MTA's -> mail losts.

It's quite unbelievable that for a product being in beta for a long time and now "production ready" has such problems.

Guess we'll wait another month or two.

Cheers.



0
Scarab Replied
Webio,

Curious if you opened a ticket for this issue, and if there was a fix or special build upcoming to address this specific issue.

So the v16 Incoming Gateways were still working in SmarterMail Gateway Mode to a v17 SmarterMail Server, but when you upgraded the Incoming Gateways to v17 it fell apart?

We have been ready to pull the trigger on upgrading to v17/100, even ran an earlier build install on a copy of our data to evaluate, and were basically keeping a close eye on the forums and patch notes to find a point where there were the least number of major issues that pertain to us before jumping in. As we use multiple Incoming Gateways and experienced a similar problem as you are reporting back with the first release of v16 and were bouncing all inbound emails for 2 days...the only workaround for almost 10 months was to manually specify all of our domains on each Gateway...so we are now more than a little hesitant to upgrade as we really don't want to go through that nightmare again anytime soon.

I guess one could choose not upgrade their SmarterMail Incoming Gateways and just upgrade the primary SmarterMail installation to v17. (Now that I think about it our tertiary backup Incoming Gateway is still running v13 under the premise of "if it's not broke, don't fix it".)
0
Webio Replied
IMHO it all depend on what type of gateway you are using. I'm using Domain forward since my main SM instance is not listed in MX domain configuration so all traffic must go through incoming gateways where spam/av checks are made. I was using domain verification as a part of smartermail gateway mode with user verification over webservice but it is not working too well and for that I opened support ticket. Incoming gateways with user web service verification where passing through spoofed emails (they allowed FROM field to be from domain which is present on main smartermail instance so they should be bounced right?). They suggested me for now to upgrade to SM v17 for this issue because v17 as a gateway mode adds "SMTP User Verification" as an opposite to SmaterMail Gateway Mode (you can enable only one of this two modes) but since this is new setting and I was upgrading from v16 I had gateway mode enabled and after upgrade to v17 all of emails where bounced with no such user here. Probably this is related to exception from API log which I've provided in initial post. If I will have enough time tomorrow I will try to update one of my gateways, narrow possible SMTP connections to one remote mail server and send email to this gateway with enabled mentioned SMTP User verification. This type of verification is not yet described on SM help so it's hard to tell what difference it makes when you compare it to gateway mode and webservice. Probably it will bounce spoofed connections but we will see.

EDIT: here you have topic about spoofed emails:

0
Kyle Kerst Replied
Employee Post
Just a quick follow up on the original issue posted about here. Support was made aware of this and we've worked with the original poster to set up some test scenarios where we routed email through one of the upgraded gateway environments; and found they are delivering mail as expected. This isn't to say they're running at 100%, but from initial review SmarterMail v17 gateway functionality appears to be working as expected. 
Kyle Kerst
Technical Support Specialist
SmarterTools Inc.
(877) 357-6278
www.smartertools.com
1
Webio Replied
Maybe someone could do some testing on your end? I'm almost sure that SmarterMail Gateway Mode is broken when User and Domain Verification is set to Web Service. This is configuration which I used before v17 and it worked and after upgrade to v17 out of box all messages are being bounced with no such user here error. BUT when I disabled SmarterMail Gateway Mode, enable SMTP Verification, select in Section Domains All But Specified Domains (and provide some dummy domain - like somenonexistingdomain.com - as a "specified domain" because I want to all Domains be checked) then messages are being relayed correctly to main SmarterMail instance but no spam checks are being made against relayed messages. So out of the box upgrade from v16 to v17 is making incoming gateway not usable. It needs some tweaks to make it working but still no spam checks make it not usable in at least my environment where all checks are being done on incoming gateway.

Reply to Thread