1

We've been banging our heads for the last few days trying to figure this one out. Even our Senior Systems Engineer seems to be unable to come up with a decent explanation for this one.

We discovered this issue when our MFPs refused to Scan to Email outside of our company emails. We have the domain (and proper MX record) "@ourdomain.com". Our MFPs can scan and send to those emails through our local Exchange server just fine. Telnet has been tested within the network and we get the same result.

Our OWA can send emails just fine, to any address. Our DNS Gateway is set properly on the MFPs.

We have the proper receive connector's set up to allow the printers and our test desktop to relay emails.

The problem - We cannot send emails to any email but ours outside of using OWA/Outlook. Are we missing something important here?

Ex: Our MFPs can email anemail@ourdomain.com, but not anemail@gmail.com or any other domain.

Thirk
  • 113
  • 1
  • 5
  • 2
    `Are we missing something important here?` - Yes. you're missing a coherent and detailed description of the problem. – joeqwerty Jun 16 '15 at 16:39
  • **The problem** - We cannot send emails to any email but ours outside of using OWA. – Thirk Jun 16 '15 at 16:41
  • You haven't mentioned outlook or another email application, do you only use owa? – Drifter104 Jun 16 '15 at 16:51
  • My coworker uses Outlook, and it works for him. Added to the description, sorry about that. – Thirk Jun 16 '15 at 16:52
  • 2
    I know you said you have the proper connectors set up but this does sound like a relay/connector issue. Exchange 2013 is a little different from 2010 in terms of relay connectors, where to set them up etc. Take a look here http://exchangeserverpro.com/exchange-2013-configure-smtp-relay-connector/ – Drifter104 Jun 16 '15 at 17:03

1 Answers1

1

What you're trying to do is not sending, it's relaying. The MFPs are sending and they are trying to use your Exchange server as an SMTP relay. Exchange used to be an open relay by default, but that is a major security problem so now Exchange servers will not relay any mail by default. Using Outlook or OWA is not relaying because in those cases the Exchange server itself is generating the message.

This page has instructions on how to create an SMTP relay connector for Exchange 2013. Briefly, you create a new receive connector, allow anonymous connections, and (very important) you specify the IP addresses of your MFPs as allowed to send through that connector.

Todd Wilcox
  • 2,831
  • 2
  • 19
  • 31
  • EXCELLENT. Thank you! I needed to run the PowerShell command to get it working. You've solved a week's worth of misery for my team. – Thirk Jun 16 '15 at 18:17
  • You're welcome. Now the challenge is to document and remember this when you upgrade your MFPs or some other device or service needs an SMTP relay. – Todd Wilcox Jun 16 '15 at 18:20
  • Already working on the documentation. What I'm investigating now is how the command works and exactly what it did to AD. – Thirk Jun 16 '15 at 18:23
  • @Drifter104 Sorry I didn't notice your comment actually. I could.. delete my answer so you can post your comment as an answer? If you wanted to have answered the question I'm not sure why you posted a comment instead. – Todd Wilcox Jun 16 '15 at 19:09
  • No sarcasm or criticism intended – Drifter104 Jun 16 '15 at 19:37
  • Oh, ok. Someone downvoted my answer at the same time as your comment so I erroneously put two and two together. – Todd Wilcox Jun 16 '15 at 19:52
  • Just wondering... couldn't you setup a user mailbox for the printers and have the printers use those credentials as a client to send email instead of using the printer's SMTP server? – Jon Jun 22 '15 at 14:20
  • @Jon While I'm 99% sure that could be done, I confess I've never done it before. Primarily because figuring out how to get different brands, models, and software versions of MFPs to authenticate to Active Directory for LDAP queries has always been difficult enough. Going further to configure authentication for SMTP XAUTH (if supported) has never seemed worthwhile enough. Plus I think an additional Exchange CAL would be required for that config (a Windows device CAL is required for the LDAP query account!) – Todd Wilcox Jun 22 '15 at 14:41
  • I agree CALs are another whole issue. If you buy the server version and you have to buy the pro client version to connect to the server then why require yet another license? Greed. Back to my point... I meant like a pop3 mailbox account in exchange. All printers I've dealt with allow you to type in a username, password & email server address. That's all. Then when the printer needs to email something it contacts the server with the given username and done. Also unless each printer needs their own email address you could just use one generic account so it will only cost you 1 license. – Jon Jun 23 '15 at 13:57
  • A mailbox on an Exchange server is a mailbox (with all the licensing requirements thereof) regardless of whether you access it with POP3, IMAP, MAPI, OWA, OutlookAnywhere, etc. Microsoft documentation indicates that the only way to license printers, scanners, etc. is to purchase a device license for each one, but yes, greed is often a factor in their literature. It might very well be legit licensing to purchase one user CAL for all network devices that are sharing one mailbox. Personally I've had trouble with Exchange authentication on MFPs. – Todd Wilcox Jun 23 '15 at 14:22