none
Error sending message from Powershell

    Question

  • so, here's my situation:

    I have a completely isolated lab network that I have complete control over, consisting of a Server 2012 VM running Exchange 2013, a Windows 7 client VM running Outlook 2013, and an Ubuntu server (14.04-3 LTS) running postfix as its mail server. As these VMs are completely isolated from everywhere, and are physically separated from the Internet, security concerns are very low.

    My issue is that I need to be able to send complete email messages by scripting them. I am attempting to use the PowerShell Send-MailMessage cmdlet, and it's not working. I get the following output:

    PS C:\Windows\system32> Send-MailMessage -From <user1>@email.local -To <user2>@linux.local -Subject "powershell 1600
    test" -Body "sent from PS to linux" -SmtpServer email-server
    Send-MailMessage : Mailbox unavailable. The server response was: 5.7.1 Unable to relay
    At line:1 char:1
    + Send-MailMessage -From <user1>@email.local -To <user2>@linux.local -Subject " ...
    + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
        + CategoryInfo          : InvalidOperation: (System.Net.Mail.SmtpClient:SmtpClient) [Send-MailMessage], SmtpFailed
       RecipientException
        + FullyQualifiedErrorId : SmtpException,Microsoft.PowerShell.Commands.SendMailMessage

    I did my homework, and found that there are some changes that need to be made to the default Exchange server to make this possible:
    1. Add a "Relay" Receive Connector (per http://exchangeserverpro.com/how-to-configure-a-relay-connector-for-exchange-server-2010/)
    2. Allow the "Relay" connector to relay for any recipient using" Get-ReceiveConnector "Relay" | Add-ADPermission -User "NT AUTHORITY\ANONYMOUS LOGON" -ExtendedRights "Ms-Exch-SMTP-Accept-Any-Recipient" (per http://serverfault.com/questions/476979/exchange-connector-wont-send-to-external-domains)

    After making those changes, email is flowing back and forth properly from the Outlook thick client through the Exchange Server to the Ubuntu server (also to/from OWA.) All is well there.

    But Send-MailMessage from PowerShell is getting the same error message. At this point, I've tried recreating the connector, checking the message tracking logs (nothing indicative), sniffing the network traffic to see if there really is anything going on the wire (nothing at all, not even DNS lookups), and a few other things.

    All this indicates to me is that there's still some Exchange configuration issue, but I don't know what it is. Any ideas?

    (BTW - I don't *have* to use Send-MailMessage to accomplish the goal of sending emails via a script. It just seemed the mot promising method.)

    Thanks in advance for any and all advice.

    -Bruce D.

    Wednesday, February 10, 2016 4:04 PM

Answers

  • Specify a value for RemoteIpRanges, and there will be a reason that the connector would be selected versus the Default one and there won't be any "competition".  Hosts in the RemoteIpRanges list will be routed through the relay connector because of its more specific IP match, while all others will be routed through Default.

    Ed Crowley MVP "There are seldom good technological solutions to behavioral problems."
    Celebrating 20 years of providing Exchange peer support!

    Saturday, February 20, 2016 12:00 AM
    Moderator

All replies

  • Is it possible that the NDR is coming from the Linux server?  The best way to test this is to use telnet to port 25 and fat-finger in a message, like:

    telnet email-server 25
    helo user1.email.local
    mail from:user1@email.local
    rcpt to:user2@linux.local
    data
    Subject:Test
             <blank line>
    This is a test.
    .     <period on line by itself>
    quit
    

    Repeat by trying a connection from the Exchange server to the Linux server.


    Ed Crowley MVP "There are seldom good technological solutions to behavioral problems."
    Celebrating 20 years of providing Exchange peer support!

    Wednesday, February 10, 2016 5:55 PM
    Moderator
  • That worked. It went through in seconds.

    I've tried sending from OWA, Outlook, and now Telnet, all successfully. The only failure comes from trying to send from PS.

    Wednesday, February 10, 2016 8:54 PM
  • You might try sending to port 587 and adding authentication.  When prompted, enter the credentials for user1, or an account that has Send As right on user1.

    $Cred = Get-Credential
    Send-MailMessage -From <user1>@email.local -To <user2>@linux.local -Subject "powershell 1600 test" -Body "sent from PS to linux" -SmtpServer email-server -Port 587 -Credential $Cred

    If that works, you can automate the credential part if you want.

    http://stackoverflow.com/questions/6239647/using-powershell-credentials-without-being-prompted-for-a-password


    Ed Crowley MVP "There are seldom good technological solutions to behavioral problems."
    Celebrating 20 years of providing Exchange peer support!

    Wednesday, February 10, 2016 10:37 PM
    Moderator
  • No go, I'm afraid.

    There's some new information, though. Just now, I *was* able to send from a Win7 client's Powershell (PS v2). Still unable to send from the *server's* Powershell (PS v3). The v2 cmdlet doesn't seem to support the "port" parameter, and I was able to send from the Win7 client without it.

    Thursday, February 11, 2016 3:34 PM
  • You might want to enable protocol logging on the receive connectors and see which receive connector is being selected for the connections on the server and workstation.

    Ed Crowley MVP "There are seldom good technological solutions to behavioral problems."
    Celebrating 20 years of providing Exchange peer support!

    Friday, February 12, 2016 3:22 AM
    Moderator
  • OK, Ed, I've enabled logging. The problem is, I don't know which of the hundreds of log files to look in, or what they're going to tell me when I find the right one(s). Can you provide any guidance?
    Wednesday, February 17, 2016 3:14 PM
  • add the IP of the workstation you are running the script from to the relay connector.

    in your script:  -SmtpServer 'email-server'

    is 'email-server' the linux server or the exchange server?


    Wednesday, February 17, 2016 3:31 PM
  • "email-server" is the Exchange server. And I'm running the script from the server's own Powershell.
    Wednesday, February 17, 2016 4:00 PM
  • OK, Jon, I took a riff off of your suggestion. I added the *network* address (172.16.1.0/16) to the relay connector, and now it all works. Both from the server and from the client. Bear in mind that the server's own IP (172.16.1.5) was already in the list.

    Also in the list already was 127.0.0.1, fe80::, and ::1.

    ????

    Wednesday, February 17, 2016 5:18 PM
  • Where did you add that address, to RemoteIPRanges?  That would be where to put it.  Does the sending server have more than one IP address?  Maybe you need to enter all the server's addresses.

    There's a potential problem with allowing the complete subnet.  If you add another Exchange server at some point, you'll find that it won't be able to communicate because inter-server communication will choose the wrong connector, relay instead of Default.  I would recommend that you enter only the specific IP addresses of hosts you want to be able to relay instead of a complete range.


    Ed Crowley MVP "There are seldom good technological solutions to behavioral problems."
    Celebrating 20 years of providing Exchange peer support!

    Wednesday, February 17, 2016 6:42 PM
    Moderator
  • It's in the Scoping tab of the connector, under "Remote Network Settings". And I was wrong. It worked for a while, then failed again after restarting the server.

    I hear what you're saying about multiple Exchange servers, Ed, but right now I'm looking for "functioning reliably". Right now, what I've got is sometimes it works and sometimes it doesn't.

    I'm still trying to chase down what you said earlier about logging. Any guidance on where in the logs to look, and what to look for?

    Thanks again for all of your help.

    Thursday, February 18, 2016 3:00 PM
  • I would remove the RemoteIPRanges from the Default receive connector.  Then create a new receive connector with PermissionsGroups set to Anonymous, RemoteIPRanges set to the IP address(es) of the server.  Configure it for relay if this server needs to send mail outside the Exchange organization.

    http://exchangeserverpro.com/exchange-2013-configure-smtp-relay-connector/


    Ed Crowley MVP "There are seldom good technological solutions to behavioral problems."
    Celebrating 20 years of providing Exchange peer support!

    Thursday, February 18, 2016 8:20 PM
    Moderator
  • I *may* have the answer. First, I left the port configuration on the relay connector at its default setting of 25. It seems that a default connector may be competing for port 25, and when the competition heats up, neither connector can access 25. That results in failures.

    But also, send-mailmessage insists on choosing which interface it thinks it's sending email from, without seeking input from me. I had to configure the relay connector to accept email from all the IP's of all NIC's on the box, even if those NICs weren't otherwise being used for email, because send-mailmessage might have chosen them.

    It's been working for the past hour with those changes. Let's see if it continues to work.

    Thanks for all of your help and guidance over the last few days.

    -Bruce D.


    Friday, February 19, 2016 5:47 PM
  • Specify a value for RemoteIpRanges, and there will be a reason that the connector would be selected versus the Default one and there won't be any "competition".  Hosts in the RemoteIpRanges list will be routed through the relay connector because of its more specific IP match, while all others will be routed through Default.

    Ed Crowley MVP "There are seldom good technological solutions to behavioral problems."
    Celebrating 20 years of providing Exchange peer support!

    Saturday, February 20, 2016 12:00 AM
    Moderator
  • dont put the servers own IP on the relay connector and dont put a range on the relay connector. be specific on the relay connector. Just have the application servers Ip in there (or workstation).


    Saturday, February 20, 2016 9:10 AM