smtp auth; who ,how, why and when?

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

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?

Cheers

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

Cheers - Bob

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

Cheers - Bob

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

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.

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.

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

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.