I'm having 'fun' trying to get my CRM server to send email externally via the exchange 2007 server. I'm receiving this message: ExternalAuthoritative cannot be set with BasicAuth, BasicAuthRequireTLS, ExchangeServer, or Integrated authentication mechanisms. when I try and configure what i want. We only have one exchange server, and the CRM server used a third party program (Orbis TaskCenter) that does not support TLS, only basic auth. I need this app to send out emails, which it will do internally, but when using an external address, I receive a 5.7.1 Relay Error. So I tried to set it up with externally secured, but the client app required authentication, and then fails. Is there no way to make it work like exchange 2003 used to? At least I can restrict by IP now, so I'm wondering why this funtionality is not allowed, or am I going about this all wrong. Greg

You may need to open up relaying for this particular IP.. or e-mail address. What is happening is when the application is sending the mail from the internet it is blocked as the application is using SMTP and does not have a way to prove what is it. For e,g Anyone can pretend he is having so and so e-mail and smtp the mail; to your server ( sppofing) which by default is stopped . You need to assign the permission or allow it to relay through your receive connector.

I think this shoudl work. with permissions http://msexchangeteam.com/archive/2006/12/28/432013.aspx

Yes, I saw that one, however the application doesn't support TLS and is part of a new domain that we are merging towards ( the application doesn't utilize AD accounts either, so I suppose that point is mute). So it is only capable of using basic authentication only. That is the reason I cant seem to get it accepted by the exchange 2007 server. When I enable basic auth, instead of TLS, I receive this message above. Greg

So by the lack of response, can at least promote to the powers that be that the Microsoft Exchange is not capable of basic authentication with a legacy application? Greg

On Sun, 5 Dec 2010 21:50:32 +0000, DebuggerAu wrote: >So by the lack of response, can at least promote to the powers that be that the Microsoft Exchange is not capable of basic authentication with a legacy application? Just create another receive connector and restrict the IP addresses to the CRM server. You can enable Externally Secured if that's not too much permission to give away for you. No need to use any authentication at all. --- Rich Matheisen MCSE+I, Exchange MVP --- Rich Matheisen MCSE+I, Exchange MVP

Thanks Rich, Not really, I can live with that traffic internally, and I have tried that, but the application fails to work without authentication, it appears to need a client auth. Even though it had a checkbox to turn it off and I can send an email successfully with telnet, Orbis TaskManager returns this error: Login Authentication Required but not supported by the server (0x80040d50) Pity it wasn't written by MS. So looks like I'm stuck with getting basic auth going on as a client. I'm awaiting the manufacturer for an update, but I'd be surprised if I'm the first to come across this issue. Any other suggestions? Greg

On Mon, 6 Dec 2010 00:58:19 +0000, DebuggerAu wrote: > > >Thanks Rich, > >Not really, I can live with that traffic internally, and I have tried that, but the application fails to work without authentication, it appears to need a client auth. > >Even though it had a checkbox to turn it off and I can send an email successfully with telnet, Orbis TaskManager returns this error: > >Login Authentication Required but not supported by the server (0x80040d50) > >Pity it wasn't written by MS. > >So looks like I'm stuck with getting basic auth going on as a client. > >I'm awaiting the manufacturer for an update, but I'd be surprised if I'm the first to come across this issue. > >Any other suggestions? If all you need is the AUTH LOGIN to be present in the EHLO keywords then create the new receive connector and on the "Authenication" tab just check the "Basic Authentication" box -- nothing else. On the "Permission Groups" tab, uncheck "Anonymous" and check "Exchange Users". 220 srvr005.XXXXXXXX.com Microsoft ESMTP MAIL Service ready at Sun, 5 Dec 2010 21:25:54 -0500 ehlo 250-srvr005.XXXXXXXXXX.com Hello [192.168.1.102] 250-SIZE 10485760 250-PIPELINING 250-DSN 250-ENHANCEDSTATUSCODES 250-AUTH LOGIN <===== This is what you're looking for, right? 250-8BITMIME 250-BINARYMIME 250 CHUNKING --- Rich Matheisen MCSE+I, Exchange MVP --- Rich Matheisen MCSE+I, Exchange MVP

Thanks for that, I did try that but I'm doing it again to be sure: Orbis Task Manager gives this error: The Sending Failed due to an error from the MAIL FROM command (0x80040d44) So I did a trace and got this: [6/12/2010 4:53:43 PM:642] EHLO SLX AUTH LOGIN c2FtY29tLmNvbS5hdVxTTFXXXXXXXXX U0xYIzEwMHXXXXXXXXX= MAIL FROM:<XXXXXXXXX@XXXXXXXX.com.au> SIZE=381 RET=HDRS then nothing, strange.. Any ideas? Greg

Hi Greg, It sounds odd, I want to verify below: 1. Does the exchange server work well, and all the service work well. 2. Did you restart the transport service after you change the configuration 3. The Above link and information seems proper. Some related issue you could refer to: http://social.technet.microsoft.com/Forums/en/exchangesvradmin/thread/158bf99e-1db6-4840-87b7-cce7553d291e http://blogs.technet.com/b/jribeiro/archive/2010/01/12/how-to-anonymously-relay-in-exchange-server-2007-2010.aspx http://social.technet.microsoft.com/Forums/en-US/exchangesvrtransport/thread/e6b9d8ff-4402-4947-b2f7-5f028ea60da4 Regards! GavinPlease remember to click Mark as Answer on the post that helps you, and to click Unmark as Answer if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

On Mon, 6 Dec 2010 06:05:59 +0000, DebuggerAu wrote: > > >Thanks for that, I did try that but I'm doing it again to be sure: > >Orbis Task Manager gives this error: > >The Sending Failed due to an error from the MAIL FROM command (0x80040d44) > >So I did a trace and got this: > >[6/12/2010 4:53:43 PM:642] EHLO SLX AUTH LOGIN c2FtY29tLmNvbS5hdVxTTFXXXXXXXXX U0xYIzEwMHXXXXXXXXX= MAIL FROM:<XXXXXXXXX@XXXXXXXX.com.au> SIZE=381 RET=HDRS > >then nothing, strange.. Any ideas? What did you use to get that information? Was it a network monitor (e.g. Wireshark)? Is the address in the MAIL FROM command assigned to the user account used to authenticate the session? If not, then the account used to authenticate should have the SEND AS permission on the user assigned the address in the MAIL FROM command. --- Rich Matheisen MCSE+I, Exchange MVP --- Rich Matheisen MCSE+I, Exchange MVP

Thanks Rich, I was using smsniff, and correct, it is the same account as the authorized user. Thanks Gavin too, I've been re re retrying those variations with help from those links, but no joy as yet. Greg

On Tue, 7 Dec 2010 04:26:46 +0000, DebuggerAu wrote: > > >Thanks Rich, I was using smsniff, and correct, it is the same account as the authorized user. Does the account have a mailbox? As strange as it may sound, try adding the account to the user's "Security" tab in ADUC and assigning it the "Send As" permission (the "SELF" account is probably already there and, if it is, it should have "Receive As" and "Send As"). --- Rich Matheisen MCSE+I, Exchange MVP --- Rich Matheisen MCSE+I, Exchange MVP

Wow, you were right on, somehow (I'm frowning) it had them removed.. But at least now I can send internally, not externally any more, but I'll need to look into that later. Thanks, and I'll update you with my findings after the weekend. Cheers,Greg

On Fri, 10 Dec 2010 01:44:53 +0000, DebuggerAu wrote: >Wow, you were right on, somehow (I'm frowning) it had them removed.. The account isn't present in the ACL by default. The "SELF" account represents the user and *that's* there when the mailbox is first assigned. >But at least now I can send internally, not externally any more, but I'll need to look into that later. What's the failure when you try to send e-mail to an address not in your set of accepted domains? --- Rich Matheisen MCSE+I, Exchange MVP --- Rich Matheisen MCSE+I, Exchange MVP

Thanks Rich, I setup a trace on the exchange server and now I get more info, thank goodness. I also have a base 64 decrypter to help with the auth info and I believe it is that its authenticating using an masqueraded domain name, UPN actually, not the actual AD domain, which causes auth to fail. It is also in the format xxxxxx.com.au/username or xxxxxx.com.au/username@domainname.com.au if I enter an actual domain name within this client, then it is appending to the end it as in the last example, but no matter what I change in the client the initial UPN domain name is suffixed, and breaks the auth. I tried a few telnet tests, with username@domain.com.au and all is well, as is using the username by itself. So I've contacted the vendor who may have a clue, but unless someone knows how to allow sending from a UPN suffix domain within exchange? It looks like I may have to wait with baited breath:) I really appreciate the help too, just wanted to give you blokes a round of applause.. Greg