Notification Email Messages - Source?

1. If there's no configuration on the 'Advanced' tab in 'Notifications' or in 'Email Protection >> SMTP', then there are no stored credentials.

2. No idea.

3. Without seeing an example header of a notification you've received, it's hard to say.  My guess would be that your email service accepts the email from your UTM to the recipient there and then relays the message to your personal account.

Cheers - Bob

Hi Bob - Thank you for the reply. I am still trying to figure out what happened.

I think the UTM was caching the email authentication credentials somewhere, but I can't prove it with absolute certainty. I logged into my hosting service and changed the password for the email account I had set up at the hosting service for the UTM (even though nothing was enabled or displayed in the Advanced tab). Immediately after that, the UTM stopped sending email messages.

It is possible that the hosting service was running an open mail relay and then closed it around the same time. This morning they denied making any changes to their mail server, and the timing would had to have been very coincidental.

The problem with their denial is that:
* I brought the issue to their attention yesterday morning. They may be too embarrassed to admit the mail server configuration issue (or their lower tier support people aren't aware of the change). 
* The start of the email messages from the UTM four days ago coincides with a major server change at the hosting provider - they were forced to move the physical server on very short notice four days ago.

Next tests:
I am going to enter the new email credentials in the Management->Notifications->Advanced tab to see if I can get the notifications started again. Assuming they work, I will delete the entries and disable the Advanced tab, and see if the email messages continue anyway. I will let you know what I learn. 

Cheers, utmadm

Final results:

* I configured the Notifications->Advanced tab for the SMTP server, correct port, email authentication account info (including the newly changed password), and it all worked as it should. Email notifications were sent by the UTM and received by my account.

* I loaded the UTM's auto-backup from when the email notifications suddenly started working a few days ago. I confirmed that the Notifications->Advanced tab was disabled and the fields (other than SMTP port) were empty. I rebooted the UTM to force a notification but none was received. It is not surprising, because I had changed the email password at the hosting service. It is also possible that the hosting service fixed their open email relay, which they deny existed.

* I also rebooted the UTM while concurrently sending and receiving email messages from a desktop email client behind the same NAT - to show that the UTM did not "piggyback" on unrelated mail server authentications coming from a desktop computer at the same public IP address.

* I restored the new configuration, and notifications started working again.

I cannot fully explain what happened, and there is no way to be certain which of the following is true:

A) The UTM was running its own SMTP service, relying on an open relay at my hosting service to send email messages. The hosting service denies that they had an open relay or made any change to their email configuration. I find it very suspect that the UTM's notifications started when they moved their hosting server to another facility. 

B) The UTM had somehow stored email authentication credentials for its email account and was using them, even though they were not displayed in Notifications->Advanced.

C) The UTM was "piggybacking" on an email authentication coming from my email client software on my desktop computer that happened around the same time. I tried various email sends and checks from the desktop computer just before and during the UTM reboot process, and it could not send mail when the Notifications->Advanced email settings were empty (not configured). 

I vote for A, but the hosting provider denies it and we will never know for sure.

With the older configuration, did you also check 'Email Protection >> SMTP' 'Advanced' to be sure a smart host wasn't configured there?

Cheers - Bob

Hi Bob,

Thank you for your continued interest and advice.

Good question. The answer is that Email Protection->SMTP->Advanced tab, Smarthost settings (at the very bottom of the page) are unchecked and the fields are empty. 

Just above it, the "Advanced settings" has values for the SMTP hostname, Postmaster address, BATV Secret (UNSET), and the various numeric entries. I do not remember completing them, so I guess that they were autofilled during initialization. 

The other fields on the entire SMTP->Advanced tab are blank. 

Bottom line: I believe that I never touched any settings on this page.

Cheers, utmadm

If you'd like to send me a copy of the header of one of the emails that came through when it shouldn't, I can probably see quickly how it got to you.

Cheers - Bob

Here is an example header and message, from when the UTM email messages suddenly started to appear. Names, IP addresses, etc. were changed to protect the innocent. The IP address represents the dynamic (DHCP) public IP address of the home DSL account: 


From: "Firewall Notification System" 
Subject: [virtualUTM][INFO-000] System was restarted
Date: 30 March 2014 6:51:04 AM PDT
To: sophosadmin@example.com
Return-Path: 
Envelope-To: sophosadmin@example.com
Delivery-Date: Sun, 30 Mar 2014 06:51:14 -0700
Received: from adsl-172-20-34-46.dsl.invalid.arpa ([172.20.34.46]:47611 helo=virtualUTM) by server.provider.com with esmtps (UNKNOWN[:D]HE-RSA-AES256-SHA:256) (Exim 4.82) (envelope-from ) id 1WUG8m-0007zq-JO for sophosadmin@example.com; Sun, 30 Mar 2014 06:51:12 -0700
Received: from localhost ([127.0.0.1]:32900) by virtualUTM with esmtp (Exim 4.76) (envelope-from ) id 1WUG8f-0001ch-06 for sophosadmin@example.com; Sun, 30 Mar 2014 06:51:05 -0700
Received: by localhost (Postfix, from userid 0) id DD2A142802; Sun, 30 Mar 2014 06:51:04 -0700 (PDT)
Mime-Version: 1.0
Content-Disposition: inline
Content-Type: text/plain
Message-Id: 
Auto-Submitted: yes
Precedence: bulk
X-Mailer: Firewall Notification System
Content-Transfer-Encoding: quoted-printable


System was restarted
Reason: Shut down via WebAdmin

Home UTM Alert

-- 
System Uptime *****: 0 days 0 hours 0 minutes
System Load *******: 0.73
System Version ****: Sophos UTM 9.109-1

Please refer to the manual for detailed instructions.

Here is an example header and message, from this morning, after I had properly configured the UTM to connect to the mail server with a valid username and password (username: utmhome@example.com). Names, IP addresses, etc. were changed to protect the innocent. The IP address represents the dynamic (DHCP) public IP address of the home DSL account: 

From: "Firewall Notification System" 
Subject: [virtualUTM][INFO-000] System was restarted
Date: 4 April 2014 10:40:25 AM PDT
To: sophosadmin@example.com
Return-Path: 
Envelope-To: sophosadmin@example.com
Delivery-Date: Fri, 04 Apr 2014 10:40:30 -0700
Received: from [172.20.35.159] (port=43681 helo=virtualUTM) by server.provider.com with esmtpsa (UNKNOWN[:D]HE-RSA-AES256-GCM-SHA384:256) (Exim 4.82) (envelope-from ) id 1WW86P-0001yf-Fl for sophosadmin@example.com; Fri, 04 Apr 2014 10:40:29 -0700
Received: by virtualUTM (Postfix, from userid 0) id ADC1E42868; Fri,  4 Apr 2014 10:40:27 -0700 (PDT)
Mime-Version: 1.0
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
Message-Id: 
Auto-Submitted: yes
Precedence: bulk
X-Mailer: Firewall Notification System


System was restarted
Reason: Rebooted via WebAdmin

Home UTM Alert

-- 
System Uptime *****: 0 days 0 hours 0 minutes
System Load *******: 0.39
System Version ****: Sophos UTM 9.109-1

Please refer to the manual for detailed instructions.

Mystery solved!  It was the ISP's mistake, but they're not running an open relay.

For commercial connections, it's not necessary to configure a smart host because SMTP traffic is allowed.

Normally, ISPs block port 25 for residential connections, but it appears from Post #8 above that your ISP's network suddenly allowed that traffic, so your UTM could send email directly to the sophosadmin account at example.com.  In fact, if that's not the ISP's mail server, the ISP is still allowing port 25 traffic, and that could stop anytime, blocking the UTM's connection to the configured smart host.

Cheers - Bob

Hi Bob,

Thanks for the review. My home ISP is AT&T DSL. We pay a separate company for shared hosting of our domain "example.com".

Based on your explanation, the home ISP (AT&T) must have allowed the UTM to connect to the provider's "server.provider.com" on port 25 without authentication to send the email. 

Perhaps it is not an "open relay" per se, but it appeared that the hosting provider's server was open for destination email addresses that were hosted by it. Once I talked with them, it appears that they closed that loophole.