smtp auth; who ,how, why and when?


Using exchange 2010

2x Rx connectors

  • internal network
  • gateway, anonymous permissions only.

All users use Outlook, some users work from home, most users have email on their phones. Occasionally I use OWA from the outside world.

UTM SGxxx, configured for smtp proxy, no ISP smart host

There is one website with a user enquiry form.

I have no test environment so I am loath to poke around too much. 


Does exchange need the UTM nominated as a smart host and Why?

Does the UTM need to accept smtp auth from the internet for the outlook services described above?

  • if No? how do I turn it off (this question arises due to around 7 regular "Too many failed logins from xxx for facility smtp, blocked for 24hrs") but still allow the website enquiry form to pass.



  • Hi Simon and welcome to the UTM Community!

    Rather than respond directly to your questions now, please work through Basic Exchange setup with SMTP Proxy and then come back here for help.

    For the WAF configuration, start with Sophos UTM Web Application Firewall with Exchange 2013 and Web Application Firewall for Exchange 2016.  The 2016 version is better written, so I would try that one before the 2013 version.

    Cheers - Bob

  • Authentication it is not needed for users. The purpose of it is: A user configured in UTM can Relay directly emails (send) skipping Exchange. But that it is not allowed by most company policy.

    You can put UTM as "send connector" in Exchange (smart host) and UTM will handle the email

  • In reply to oldeda:

    The UTM is currently the smart host for exchange, super!

    The UTM is mostly configured as per Bob's setup post.

    My preference is to make the UTM do most of the work and leave exchange relatively normal.

    However, I do not understand why an external party/server would even be permitted to begin an smtp authentication, this seems wasteful and inelegant.

    • is this normal because the authentication will always fail. (and how do I have confidence this is true)
      • Is this handshake processing overhead better placed into another function of the UTM?
    • should the dubious IP address be entered somewhere to drop it at the firewall (or send it to a blackhole)?

    To prevent authentication attempts (presuming this is best practice to mitigate the smtp password guessing attacks) should "allow upstream/relay hosts only" be checked but have no listed entries, or does the check box imply a blanket function for the UTM?


  • In reply to Simon Denham:

    Please show a picture of the section of the 'Relaying' tab that includes 'Authenticated Relay' and 'Host-based Relay'.

    Cheers - Bob

  • In reply to Simon Denham:

    What is the purpose of allowing "qcds-office" to relay off the Proxy?  That's the source of your error messages.

    Cheers - Bob

  • In reply to Simon Denham:

    Authentication is not a handshake with other external hosts like hotmail or gmail, but like i said users only can send emails directly from UTM (no need to logon to exchange). In this case you should disable the Authentication

    In Relaying Tab:

    1) Disable

    "Allow authenticated relaying"

    2) In "Allowed Hosts/Networks"  should be only Exchange Ip

    In exchange configure a "send connector" with UTM Internal IP x.x.x.x.  (not host-name or dns name)

    In this way you eliminate DNS Problems or some other failures in exchange. The Email will be handled by UTM where you can see more detailed logs in case of failure. You can leave Exchange Server without Gateway or DNS configured, and the email will still go out

  • In reply to oldeda:

    qcds-office is the AD profile for the MFC to permit sending emails and saving to folders. In my view it only needs to send emails to internal users. this was configured by the installer of the SG115. I am loath to poke too hard at this during the business week.

    Exchange has only one send connector pointing to the UTM/gateway configured thus:

    Does the network need 2x Send Connectors? (one to specify Smart Host and one pointing at the UTM/Gateway?)

    However, yes I will make these changes this weekend and hopefully then resolve the MFC email/saving configuration.

  • In reply to Simon Denham:

    No, the connector is good

    If qcds-office is a scanner or something else. They have to go through exchange. Not UTM. Only Exchange Server must be there

  • We have a disagreement with Bob about using Standart mode or Transparent mode. But consider my recomandation below  if  Exchange Server is the only one who will send emails to the outside world. And if you said that you want the best from UTM and make it a real Smarthost

    1 Check Transparent Mode

    2 In relaying tab, put only exchange IP

    3 Delete or Disable any firewall rule about SMTP

    4 Delete any DNAT rules about SMTP

    Don't confuse smtp rules with OWA access (https 443 with SMTP 25

    You can still leave the rules active, but they are useless while "Transparent Mode" is enabled, and they will confuse you, not UTM.

    To regulate traffic for one specific host-ip (like scanner or printer) with firewall rules, you have to exclude it from Transparent Mode.

    There you have the option to blacklist a specific host, no need to make firewall rule to drop traffic on smtp traffic for that specific host

    Thats it :)

  • In reply to Simon Denham:

    I will try to clarify some of your confusion about protocols and features:

    Every TCP conversation has a source and destination IP address which is used to route the packet.  It also has source and destination port which identify the sending and receiving programs, so the operating systems know how to deliver the packet when it arrives, and the receiving program knows how to reply.   To permit conversations to be started, processes that accept incoming connections (sometimes called daemons) listen on "Well known" port numbers, so that my machine can connect to yours without me calling first to ask you about your configuration.   Source port number values for the initiating program do not matter.   The program asks the operating system for a unique port number before it starts a conversation, and the other end reads the source port of the incoming packet to construct its reply.

    Each communication type uses different port numbers.

    Inbound Messages

    Mail is transferred when a sending system connects to port 25 on a target server and starts an SMTP session.   This connection is unauthenticated (no login), and the server will accept mail from nearly anybody, as long as it is targeted to a mail domain that it controls.    Of course, in practice, the receiving system performs spam checks on the incoming traffic, but the point is that hotmail does not require a login for a gmail server to send a message to gmail.

    Outbound Messages

    Authenticated SMTP (optionally on port 25, but more often on port 465 or 587) is used for a client program to use a mail system to send a message to a mail domain that it does not control.   This is mostly used for email clients and for automated systems that need to send alarms.   For email clients, authenticated SMTP (which only sends mail) is paired with either IMAP or POP3 (protocols which only retrieve mail).  IMAP and POP have their own port numbers for both clear text and encrypted sessions.

    If a system accepts traffic for mail domains that it does not control, this is an "open relay".   Spammers use open relays to hide their source address and let someone else suffer the consequences of their dirty work, so  you never want to create an open relay.

    OWA and Outlook Anywhere are email clients written entirely in web protocols.   They should only be used with encryption, so you need to allow port 443 in your firewall.

    My configuration recommendations:

    • Alarming devices, email clients, and anything else that generates mail should send it to your mail server.   Some alarming systems cannot do authentication, so they need an exception for the receiving system to trust them based on the source IP.   But all of this traffic should be submitted to your mail server, not to UTM.
    • UTM should not accept any authenticated SMTP traffic.   This opens the device to password guessing attacks from the internet, attacks which you do not need or want.

    Smart Hosts

    A Smart Host is any device which adds a hop to the email delivery sequence, presumably because it does some evaluation of the traffic related to either deliver routing or spam filtering.   In this sense, an Exchange Connector is a Smart Host.

    UTMs add value in spam filtering, so it is desirable as a Smart Host.   Assuming that you agree, your message flow will be

    Internet -- UTM --- Exchange Connector -- Exchange

    In small environments, the Exchange Connector function runs on the Exchange server, so it does not add a hop.

    So you want to configure your perimeter devices to force this traffic flow.

    UTM should accept relay (outbound) from your Exchange server only.

    UTM SMTP proxy should be on.

  • In reply to Simon Denham:

    "qcds-office is the AD profile for the MFC to permit sending emails and saving to folders. In my view it only needs to send emails to internal users. this was configured by the installer of the SG115."

    Agreed with the others, Simon, that you don't want 'Authenticated Relay' and that, normally, the only thing that should be allowed to relay is your Exchange box.  Look in the Mail Manager on the 'SMTP Log' tab.  Put the IP of the HP Printer in the 'IP/Net/Address/Subj. substring:' box and you will see if emails are coming from it.  Likewise, put the sender email address of the qcds-office user in that box to see if any emails were sent from an IP other than the Exchange server.  You may not need to come in on the weekend unless the printer needs to be configured to relay off Exchange.  I'm not sure that it's that important to change the settings on the HP printer - I'd probably just leave it relaying off the UTM.

    Cheers - Bob

  • In reply to oldeda:

    Olsi, when you have the Proxy in Transparent mode, is it possible for an internal workstation to send email to an external server if 25/465/587 are blocked by the firewall?

    Cheers - Bob

  • In reply to BAlfson:

    If the internal Host is In "Allowed Relayed List", Yes

    You have to exclude it from "Transparent" to make it subject of Firewall Rules.

    It is like Country Blocking or Web Proxy Bob. Firewall

    Rules are the last in hierarchy

  • In reply to BAlfson:

    Normaly the workstation traffic on this ports will be intercepted by "Trasnparent Mode" first, but he can't send nothing if it is not in "Allowed to Relay". Even if you have a firewall rule "workstation-any-to any-allow. You have to exclude it from transparent, so the Firewall/dnat rule will handle that traffic