Guest User!

You are not Sophos Staff.

Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 2 replies
  • Subscribers 27 subscribers
  • Views 262 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Notifications Using Built-In Mail Server Not Sent and Filling Up /var - Fix + Cleanup Steps

ChrisKnight

Bug in SFOS 19.0.1, 19.0.2; possibly others. Fixed this on several 19.0.1 systems yesterday when /var filled up. Posting in case others run into the same problem.

When Administration > Notification Settings has notifications sent via the built-in mail server, the notifications aren't sent.

This will eventually result in the logs located in /var/spool/output/msglog filling up /var and preventing the XG from sending/receiving e-mail

The problem sounds remarkably similar to the following Sophos Community post from 12 years ago:

https://community.sophos.com/utm-firewall/f/mail-protection-smtp-pop3-antispam-and-antivirus/49116/send-email-over-ipv6-and-exim-logs-failed-to-expand-return-path

 I was seeing the following in the logs located at /var/spool/output/msglog/*

2023-03-20 05:29:34.063Z <my recipient email address> R=default_mx_router T=remote_smtp defer (-1) DT=0.000s: Failed to expand return path "${if eq{${if and{{!eq{$sender_address}{}}{eq{${if eq{1}{1} {1}{0}}}{1}}{match_domain{${lc:$sender_address_domain}}{+local_domains}}{eq{${lookup{${lc:$sender_address_domain}_BATV}nwildlsearch{/cfs/proxy/smtp/conf/exim_profile}}}{1}}{eq{${if or{{match_address{${if eq{${prvscheck {$sender_address}{}{}}}{}{$sender_address}{${prvscheck {$sender_address}{}{}}}}}{+except_batv_senders}}{match_address{${if eq{${prvscheck {$local_part@$domain}{}{}}}{}{$local_part@$domain}{${prvscheck {$local_part@$domain}{}{}}}}}{+except_batv_rcpt}}{match_ip{$sender_host_address}{+except_batv_network}}{match_ip{$sender_host_address}{+except_batv_fqdn}}}{1}{0}}}{0}}}{1}{0}}}{1}{${prvs {$return_path}{${decrypt{tblavasconf:batv_secret}{\$sfos\$7\$0\$EG5jf284wWq2w2aF4p_dysZSHkR3seXGTOGghLLYKiAwaUoHjVar8vy8LyBWbot-1_Vupzyv_zeds6w76vcZ9g~~MaTISYOqfg5-A1zu7vIfKC-QiyHfKS90BBok5eeNZ4k~}}}}}fail}": "(null).999.0.0" is not an IP address inside "or{...}" condition inside "and{...}" condition

 Problem appears to be fixed by swapping to an external mail server, or swapping to an external mail server then swapping back to the built-in mail server. At least this is what prevented the notification e-mails getting stuck after I reclaimed the disk space.

 The logs and stuck messages that are filling up the disk space can be removed using the following process:

Use ssh to log in to the XG; log in as admin
5 for Device Management
3 for Advanced Shell
cd /var/spool/output/input
grep -r -l '<sender or recipient e-mail address>' . | awk '{fname=substr($1,1,length($1)-2); print "rm " fname "-D " fname "-H ../msglog/" fname }' | sh
 
Please note the above command will remove all queued messages and associated logs for the sender or recipient address - you may want to examine the -H files in the current directory and look for a better match that will restrict the search to only the problematic messages; '(null)' may be more appropriate, but I don't have a copy of an affected -H file to see what the line starting with "-host_address" contained to restrict the search.
 
 


This thread was automatically locked due to age.
Parents Reply Children
No Data
Unfiltered HTML