locked
Difference between Exchange and Linux-based smtp servers RRS feed

  • Question

  • Hello!

    I'm currently trying to find a solution to the following problem:
    https://social.technet.microsoft.com/Forums/office/en-US/88d1ffc7-f6df-4c7d-aca2-1aba0d7a6387/fsrm-mail-notification?forum=winserverfiles

    In short: FSRM server can't send email notifications via Exchange server because "FSRM server use its computer account to authenticate the SMTP session before submitting message to exchange. To resolve the issue you must assign FSRM count account ( servername$) send as permission on user mailbox you are using in From field from exchange management Shell".

    From this I can surmise that FSRM can't send email without first being authenticated by the smtp server - by ANY smtp server  as it's a "feature" of FSRM.

    But that's not true - FSRM starts sending email perfectly once I redirect it to the Linux smtp server wich has the single Anonymous authentication method enabled.

    I then tried "to turn" my Exchange 2013/2016 into Linux mail server by checking out all authentication methods except Anonumous for the Default Frontend Receive connector:

    That didn't help - even in this configuration FSRM server tries to authenticate itself:

    It makes me think that FSRM server "wants" to authenticate a session in Exchange but does not "want" in Linux...weird...

    So what's the difference between the "anonymous" Exchange "smtp server" and the Linux-based server? Why FSRM server can't send a message without authentication via Exchange but can send it fine via Linux?

    Thank you in advance,

    Michael




    • Edited by MF47 Monday, December 14, 2015 9:04 AM
    Monday, December 14, 2015 9:02 AM

All replies

  • it is probably the way that Exchange answers, showing that authentication is enabled.

    Create a new receive connector and make it an anonymous relay, restricted to just the IP address of this server.

    Simon.


    Simon Butler, Exchange MVP
    Blog | Exchange Resources | In the UK? Hire Me.

    Monday, December 14, 2015 8:24 PM
  • "it is probably the way that Exchange answers, showing that authentication is enabled." - that's why I left only Anonymous users option checked... Exchange should not have answered with any authentication options...

    "Create a new receive connector" - that's what I'm trying not to do. At least until I'm sure why the Default Recieve Connector is not enough fot such email.

    Regards,

    Michael

    Tuesday, December 15, 2015 7:26 AM
  • Why don't you want to setup another receive connector? It is a very common fix for this kind of problem. When you have a specific application that needs to relay through Exchange, but you don't want to allow relaying (whether authenticated or anonymous) to wider people or the internet, then a custom receive connector is the path to go.

    You can see the differences between the way that the servers work by telnet in to them, then issue an ehlo command. That will tell you what the remote server is offering to the client.

    Simon.


    Simon Butler, Exchange MVP
    Blog | Exchange Resources | In the UK? Hire Me.

    Tuesday, December 15, 2015 9:01 AM
  • "When you have a specific application that needs to relay through Exchange," - NO application needs to RELAY through Exchange, the application just needs to be authenticated in order to be allowed to send mail. Both the sender (FSRM@TestCompany.com) and the reciever (Administrator@TestCompany.com) are users of the same Exchange organization so no relaying occurs here.

    "It is a very common fix for this kind of problem." - the main problem is that I'm still not sure what exact kind of the problem I have and I wouldn't like to start trying various solutions until I have a good understanding of the root of the problem. In this case I don't understand why do I need an extra connector? Why won't the default one do?

    For example, I can successfully send the same notification email in Telnet from the non-domain computer (anonymously):


    On the other hand, FSRM can send notifications via Linux server without authentication, too - so what prevents FSRM from sending anonymous email via Exchange through its DEFAULT recieve connector?

    Regards,

    Michael


     
    • Edited by MF47 Tuesday, December 15, 2015 11:22 AM
    Tuesday, December 15, 2015 11:21 AM
  • The answer is in that telnet command.

    The Exchange server is issuing AUTH-NTLM, so telling the client it can authenticate. The Linux server will not be doing that. I guess the application sending the email will attempt to authenticate if possible.

    Simon.


    Simon Butler, Exchange MVP
    Blog | Exchange Resources | In the UK? Hire Me.

    • Proposed as answer by David Wang_ Tuesday, December 15, 2015 12:22 PM
    Tuesday, December 15, 2015 12:07 PM
  • "The Exchange server is issuing AUTH-NTLM, so telling the client it can authenticate. " - yes, and this leads us exactly to the question in the post heading: what is the "Difference between Exchange and Linux-based smtp servers" , because I expect Exchange NOT to advertise ntlm (as well as any other authentication methods) when all authentication checkboxes are cleared (as depicted above). Otherwise what's the purpose of presenting authentication options that are disabled on a connector's properties?

    By the way, "...the client it can authenticate" does not ensue that the client WILL authenticate: my telnet session succeeded although it could not be authenticated as it was initiated from the untrusted domain.



    • Edited by MF47 Friday, December 18, 2015 2:47 PM
    Tuesday, December 15, 2015 1:25 PM