1

Hello all,

I’m hoping this is the right place to ask this…

Here’s my problem - we migrated to Office 365 back in August. Our Ricoh scanners are working great for everyone that is listed in our old exchange server, but new employees with accounts made after the migration don’t receive any of their scanned files.

After some troubleshooting, we discovered that new employees receive scans when we change their email address from name@domain.com to name@domain.onmicrosoft.com.

I’m looking for a way to automate this email domain modification process behind the scenes, so that someone can type in name@domain.com on the scanner and it will route to name@domain.onmicrosoft.com.

In the meantime, I will edit the address book entries for newer employees… but many current employees just type in their email every time and skip the address book, and I figure it’s just a matter of time until a significant portion of post-migration employees are in the same boat. I’m trying to nip this issue in the bud before it becomes a huge deal.

Has anyone here done, or tried to do, anything like this in the past? Thanks for reading!

1 Spice up
2

Have you checked to make sure their SMTP address in hosted exchange has the name@domain.com listed? Are you also sure it’s not being blocked by filtering, maybe quarantine?

1 Spice up
3

I believe the SMTP info is set up correctly - I just checked one of the affected user’s settings in the Office 365 admin console, and the primary SMTP is name@domain.com with name@domain.onmicrosoft.com listed as a proxy.

Part of yesterday’s troubleshooting was adding a broad filter whitelist to everything that comes in with our domain, which did not seem to affect anything.

My hypothesis is that the scanners look in our old exchange server for email addresses in the name@domain.com format, and give an error when they can’t be found there. Using the name@domain.onmicrosoft.com format, I’m guessing it skips our old server and heads straight over to office 365 to get the routing info. I’m assuming that makes sense… mail routing issues aren’t exactly my forte :slight_smile:

4

The scanner shouldn’t be doing any of that at all. Are you using your internal exchange server as the relay? Are you in a hybrid setup or migrating everyone?

1 Spice up
5

Oops, I should have been more specific - we are slowly trying to replace our old setup with Office 365 components where we can. One result of that is that we have a separate FreeBSD smtp relay for all of our scanners - everything else can hook up to 365 without trouble. Sorry for the confusion!

I was hoping that it would be a simple-ish workaround to do something along the lines of Dustin340’s solution here , using the relay we already had set up for just the scanners.

We have a hybrid setup right now - new employees are added to our Active Directory which syncs up with Office 365. At this point, we aren’t using our exchange server for much as far as I know (I’m a relatively new employee myself).

6

You could use a rewrite rule in some sort of spam filtering but the rule will be tricky, sine it’s only some, not all. It’s possible that your MX record on the internal relay is only looking and seeing the exchange box and the exchange box is dropping the mail because it doesn’t have accounts for them.

1 Spice up
7

Can you trace where it’s going form your internal relay?

1 Spice up
8

Also smtp logs on the relay may provide some good insight

1 Spice up
9

So, some employees are using Office365 and can successfully scan e-mails to name@domain.on.microsoft.com but their name@domain.com is not working because they no longer exist in the on-premise exchange server.

If this is the case you can do one of two things:

  1. Create a contact alias for the user in your on-premise exchange server which points name@domain.com to name@domain.on.microsoft.com

  2. Setup split domain routing so when the e-mail bound to name@domain.com hits your on-premise exchange server it will see the e-mail account doesn’t exist and forward the e-mail to office365.

What is the issue with getting your FreeBSD SMTP relaying through Office365? If you get this setup you shouldn’t need to do either of the above two steps.

2 Spice ups
10

Thank you both so much for the suggestions! I’m already really happy I signed up here :slight_smile:

I will take a closer look at our setup and try some of the things that have been suggested. I will be sure to post an update when I get a chance… to be honest, this is one of the less urgent projects on my plate with the workaround in place, but I am very excited to get it going and better understand our mail routing system in the process.