I saw in release notes that was a problem in the 7208, but I'm on 7242

anyone?

Thanks

Hi,

We did the upgrade to the last version and the problem persists.

Regards,

I have a SM / Office 365 split domain working on the near-bulletproof SM 15.7.6970*, SM Enterprise, set up for one domain only. Some of the SM settings for this are not exactly clear, but it works pretty much perfectly. 

Regarding SM delivery to Office 365 servers...

This is what I have set for external delivery in V15 - not sure how your SM config screen(s) look:

Domain Location: External

External Host Address: [domain-com].mail.protection.outlook.com

and of course you've already checked "Deliver locally if user exists"

You might try contacting Linda Pagillo of mailsbestfriend.com, known for Declude. She's on here a lot, with tons of helpful info.

*nobody uses the Outlook desktop app, so that's not a concern

Hi Paul,

Thanks for your response.

Yes we set domain records like o365 recommends.

The problem is in SM (v17-last) receive an email for a local account from office 365 account with the same domain (non local) rejects the email with the error: 550 Authentication is required for relay. And yes, in the domain in the inbound local delevery we set: External (use MX Record), and we already try with External Host Address, same result, SM ignore the External Configuration.

We tested with another domain and it worked well. Now in the real client domain doesn't work.

Regards

I don't have a good answer for you at this point, but I'm curious as to where the 550 message is originating, SM or Office 365. 

Also, have you entered contacts in Office 365 for all users on the SM server?  

Error is on SM, on email reception from office 365 connector. The problem is in intra-domain email  messages, for example an account that only exist in Office 365 send an email for another account hosted in smartermail. The enter in the office 365 connector and because the "from:" came from an account that does no exist in local smartermail domain, he reject.

So, messages from outside the domain are getting through to SM, but not - as you said - intra-domain emails?

Yes, the problem is when the from address its from the same domain and came from an outside server.

I open a support ticket for this issue

So I open a support ticket related to this issue, and after a few post, in resume:

"this was submitted to the product backlog because it is a deviation from the current product behavior" 

We have a product that in every release give features and take out others. I bit tired of the last years path of development.

I have no idea what that message means. SM should certainly work in a split-domain environment. 

And if it worked OK in a test environment with the same software version, why would it not work in a similar environment? 

I repeat the test with test domain and didnt work intradomain accounts. It doesnt work any more. I try upgrade to version 17 to see if any of the upgrade resolve, without success. The only think I get with the upgrade was lost the list of EAS accounts. Another feature that disappear.

They say that this issue goes to backlog. It only one more lots feature. And they propose that I open a forum post to get support from the community to resolve this "deviation".

Hello, 

We've found that this issue occurs because Require SMTP Authentication is enabled for the domain. SmarterMail is expecting authentication, and the delivery fails because it is not provided. At this time, the only solution for bypassing that requirement is to whitelist the IP. However, we've escalated this functionality for review, as we can see how that is not an ideal solution. 

Paul, I understand you are running a similar setup in version 15.x. Can you confirm whether you have SMTP Authentication enabled for that domain?

Hello Andrea,

But if you don't select Requere SMTP Authentication you create an open relay. I show that option to tony, but its not an option.

Regards,

 

This is for SMTP authentication from O365 -> SM? I will check how I have that connector set up. 

If this is sorted out it will help us keep some accounts from moving to 0365. I'd rather get rid of the super large mailboxes to them and keep the smaller ones on prem.@Sergia, if you can update this thread when you got it going that will be great.

We run split-domain configuration across multiple client domains in combination with Microsoft 365 (O365) and encounter no problems under v17 including the latest 30th July 2020 build. Nothing, fancy, the config follows the steps outlined in the first post so nothing unusual.

Outline of the config:

1. Public MX points to M365

2. Domain configured within 365 as internal relay

3. A connector scopes all tenant domains, delivers to the hostname of smartermail, TLS enabled

4. Smartermail configuration:

4a. Inbound message delivery = external MX

4b. Deliver local = yes

4c. SMTP authentication = yes

Any given user is only defined in 365 or Smartermail so that mail flows between environments.

@ Nathan: Per Microsoft, I created an (O365) Exchange contact for each non-O365 account (in this case, each SM user or alias), for O365 delivery to SM. 

It's working fine; my config doesn't work without this contact list. However, do you have a way around this? 

@Paul,

I suspect that is the problem, there is no need to create contacts unless you want it for the purpose of a 'unified' GAL in 365. We do not do that. 

If you need it, the only real option I can see would be to give your Smartermail domain an alias of client-domain.onsome-other-domain.com (you get the idea, an alias in another domain so mail can be routed out of the tenacy) and configure the contacts with the alias domain based email address. This way intra-org emails will flow transparently, albeit using an alias for 365 > Smartermail if using the GAL. Externally everyone's real email address would work.

As mentioned, we do not complicate matters with attempting to created a unified GAL either within 365 or Smartermail. We leave that limitation as it is. However, the workaround suggested would work in both directions with domain aliases.

Hi Nathan,

I did exactly what you describe, but don't work in my setup, that's the reason why I open a ticket, because maybe it was something in other configuration that conflict with, maybe it was some of the N upgrades that I made that leave something to upgrade. But the response for the ticket is that my result its the expected.

On your configuration the user that only exist in O365 can exchange email with user that only exist In SM?

@Paul, the problem is when the email arrive to SM, because the exchange connector does what is supposed, when an account for the domain not exist in O365 it puts the email in the connector that deliver to SM (and SM reject the email)

Hi Sergio,

I thought I would sanity check that 365 and Smartermail users in the same domain can exchange email and I can confirm that we have full two way email comms between them in the split-domain configuration. 

This is with the current build but from our perspective it has worked without issue since we moved from v15 directly to v17 following the beta period. We never deployed any of the beta builds in production.

Do you have a h/w firewall performing SMTP inspection /  have to feed it with a list of 'internal' domains? 

Hi,

No I do not have firewall check, and I have sure that the email is rejected by smartermail. Should be some configuration not related with the domain that block the email.

Maybe SM knows a bit more about this.

Nathan,

Can you compare your configuration with this imagem

In configurations » Protocols

Thanks

@Nathan

I don't need a GAL, but that's what I worked out with Microsoft techs when I set things up. This client even wants all mis-addressed messages delivered to a catch-all, and that's also working fine (Microsoft doesn't officially support this, but does allow it).

At some point I'd like to know more about how you've got your split domain set up, but at this time I have other non-email fish to fry. Cheers. 

Sergio... Spotted the problem,  'Enable domain's SMTP auth setting for local deliveries' is disabled on our setup which makes sense. It appears to be a setting that does not have a use case in my opinion :-)

Reading the help file, enabling this forces authentication if an email is 'from' another user in the domain but originates outside of smartermail. This perhaps makes sense 90% of the time but what about systems the legitimately 'spoof' emails from a sender that lives on your domain as is the case in a split-domain scenario. It could equally apply in many other situations.

Nathan,

Thank you! I will investigate a little more about the impact of disable the option. But its a litle bit sad that the resolution came from the community and not from the SM support team that should understand the all process. ( I had a open ticket )

Any way the option should except only the domains with external local delivery and not all domains.

Thanks