0

At one of the places I do work for, we have a Microsoft Exchange 2010 server for the office email/calendar system. This works great internal, but when sending external we relay off of a CentOS box running a sendmail system which acts as the internal-to-external mail relay system.

This works great for sending directly to someone externally, and helps keep our corporate email behind the firewall, but we have a small problem. Out of office replies which are automatically being sent to external mailboxes by Exchange are getting eaten by the sendmail box, with a "User unknown" error. This is the gist of the errors (sanitized of course):

Dec 27 08:30:11 MAILRELAY sendmail[27225]: uBRDUAlg027225: from=<pvrs=01697e799=foo@bar.baz>, size=3130, class=1, nrcpts=1, msgid=<uuid@bar.baz>, proto=ESMTP, daemon=MTA, relay=[InternalIP]
Dec 27 08:30:13 MAILRELAY sendmail[27230]: uBRDUCRG027228: to=<foo@bar.baz>, delay=00:00:01, xdelay=00:00:00, mailer=smtp, pri=122987, relay=[InternalIP], dsn=5.1.1, stat=User unknown.

When sending outbound mail from the inside corporate systems (NOT automated replies!), everything works:

Dec 27 08:34:02 MAILRELAY sendmail[27250]: uBRDY7jA027250: from=<me@corporate.domain>, size=12716, class=0, nrcpts=1, msgid=<uuid@mailserver.location.corporate.domain>, proto=ESMTP, daemon=MTA, relay=[InternalExchangeIP]
Dec 27 08:34:09 MAILRELAY sendmail[27252]: uBRDY7jA027250: to=<foo@bar.baz>, delay=00:00:02, mailer=smtp, pri=132716, relay=[InternalIP] [InternalIP], dsn=2.0.0, stat=Sent (Requested mail action okay, completed.)

... and the message is delivered as expected. It seems something about the system is eating the automatic "Out of Office" replies, so they aren't getting out to external destinations.

Has anyone seen this and found such a solution? I'm not 100% sure why it's dying on us with these, so if anyone has a solution I'd love to hear it.

Thomas Ward
  • 787
  • 2
  • 7
  • 18
  • I'm not too sure why the from= address in the bounce appears to be set to the destination domain rather than the source domain (your domain). The sendmail server is probably not delivering for that reason. It seems to me that's the thing you want to take a look at. – JBaldridge Jan 03 '17 at 19:00
  • @JBaldridge how that's built I don't have the capacity to check - that's handled behind the scenes with Exchange, and I didn't see any way to change that... – Thomas Ward Jan 03 '17 at 19:27
  • Hi Thomas, I think you're encountering an issue stated in this article http://www.msexchange.org/articles-tutorials/exchange-server-2010/management-administration/automatic-email-server-notifications-in-exchange-server-2010.html Have a look to see if you have this configured, and you might have to consider the workaround since you're using an email relay server – Lex Jan 03 '17 at 22:34
  • @Lex Thanks for your link. I'll have to talk with the rest of the team here to determine whether we want to go this route. We can't change relay servers at this time, so we can't sanely use an Exchange Edge server as our relay, so we may have to use a workaround of autoreplies instead... – Thomas Ward Jan 04 '17 at 14:22

1 Answers1

-1

How this sendmail system works, or rather how it authenticate user is valid or not?

Base on error message "User unknown", I suppose that this system need to verify user before delivering message. For this external OOF message, it send from postmaster, which is configured by Set-TransportConfig with ExternalPostmasterAddress parameter(By default, it's postmaster@ in HUB or postmaster@ in Edge).

To fix your issue, try to manually configure a postmaster and new mailbox with this address in Exchange server.

Refer to: https://technet.microsoft.com/en-us/library/bb430765(v=exchg.141).aspx

Jianfei Wang
  • 387
  • 1
  • 4
  • No effect, it's still going "User Unknown", and having that long pvrs=... address. And I didn't set it up, I sort of inherited this... – Thomas Ward Dec 28 '16 at 14:49
  • Is it "MicrosoftExchange329e71ec88ae4615bbc36ab6ce41109e@"? If so, run below command to change default Microsoft Exchange Recipient to a regular mailbox for testing. Set-OrganizationConfig -MicrosoftExchangeRecipientEmailAddresses -MicrosoftExchangeRecipientEmailAddressPolicyEnabled $false -MicrosoftExchangeRecipientPrimarySmtpAddress – Jianfei Wang Dec 29 '16 at 02:48
  • No it is not. None of these solve the issue. – Thomas Ward Dec 29 '16 at 03:26