POP3 Proxy Doesn't Inspect Fetchmail Messages

Question

Hello There, 
 I have an internal mail server behind the UTM which has fetchmail configured in multi-drop mode, I made sure that TOP is not being used by setting fetchall and keep while unsetting uidl, I can receive full messages and attachments successfully with the proxy enabled, but it appears that the proxy is not processing the messages for some odd reason. 
 I mainly use fetchmail for my users' gmail accounts and I have "Scan TLS encrypted POP3 traffic" enabled with a valid, publicly trusted certificate, the following is the corresponding POP3 proxy logs while fetching 50 messages, any thoughts? 
 2020:04:15-10:17:48 utm pop3proxy[2587]: Spawning a new SSL client handler for accepted connection from 192.168.0.25 
 2020:04:15-10:17:48 utm pop3proxy[2587]: Accepted client connection from 192.168.0.25 for 172.217.194.108 (Main External server_id 1) 
 2020:04:15-10:17:48 utm pop3proxy[2587]: SSL references REF_CaHosUTMComodServi REF_PopSerPopgmServe 
 2020:04:15-10:17:48 utm pop3proxy[2587]: Load default SSL certificate /etc/pop3proxy.conf.includes/DREF_CaHosUTMComodServi.cert 
 2020:04:15-10:17:48 utm pop3proxy[2587]: Load default SSL key /etc/pop3proxy.conf.includes/DREF_CaHosUTMComodServi.key 
 2020:04:15-10:17:48 utm pop3proxy[2587]: Load SSL certificate /etc/pop3proxy.conf.includes/REF_PopSerPopgmServe.cert 
 2020:04:15-10:17:48 utm pop3proxy[2587]: Load SSL key /etc/pop3proxy.conf.includes/REF_PopSerPopgmServe.key 
 2020:04:15-10:17:48 utm pop3proxy[2587]: Client: Authentication succeeded (user testuser@gmail.com, account_id 1) 
 2020:04:15-10:17:48 utm pop3proxy[2587]: Not connected to remote server because local authentication succeeded and prefetch mode is enabled 
 2020:04:15-10:17:48 utm pop3proxy[2587]: testuser@gmail.com logged in (account 1) 
 2020:04:15-10:17:48 utm pop3proxy[2587]: Client wants message #1 
 2020:04:15-10:17:48 utm pop3proxy[2587]: Client wants message #2 
 2020:04:15-10:17:48 utm pop3proxy[2587]: Client wants message #3 
 2020:04:15-10:17:48 utm pop3proxy[2587]: Client wants message #4 
 2020:04:15-10:17:48 utm pop3proxy[2587]: Client wants message #5 
 2020:04:15-10:17:48 utm pop3proxy[2587]: Client wants message #6 
 2020:04:15-10:17:49 utm pop3proxy[2587]: Client wants message #7 
 2020:04:15-10:17:49 utm pop3proxy[2587]: Client wants message #8 
 2020:04:15-10:17:49 utm pop3proxy[2587]: Client wants message #9 
 2020:04:15-10:17:49 utm pop3proxy[2587]: Client wants message #10 
 2020:04:15-10:17:49 utm pop3proxy[2587]: Client wants message #11 
 2020:04:15-10:17:49 utm pop3proxy[2587]: Client wants message #12 
 2020:04:15-10:17:49 utm pop3proxy[2587]: Client wants message #13 
 2020:04:15-10:17:49 utm pop3proxy[2587]: Client wants message #14 
 2020:04:15-10:17:49 utm pop3proxy[2587]: Client wants message #15 
 2020:04:15-10:17:49 utm pop3proxy[2587]: Client wants message #16 
 2020:04:15-10:17:49 utm pop3proxy[2587]: Client wants message #17 
 2020:04:15-10:17:49 utm pop3proxy[2587]: Client wants message #18 
 2020:04:15-10:17:49 utm pop3proxy[2587]: Client wants message #19 
 2020:04:15-10:17:49 utm pop3proxy[2587]: Client wants message #20 
 2020:04:15-10:17:49 utm pop3proxy[2587]: Client wants message #21 
 2020:04:15-10:17:49 utm pop3proxy[2587]: Client wants message #22 
 2020:04:15-10:17:49 utm pop3proxy[2587]: Client wants message #23 
 2020:04:15-10:17:50 utm pop3proxy[2587]: Client wants message #24 
 2020:04:15-10:17:50 utm pop3proxy[2587]: Client wants message #25 
 2020:04:15-10:17:50 utm pop3proxy[2587]: Client wants message #26 
 2020:04:15-10:17:50 utm pop3proxy[2587]: Client wants message #27 
 2020:04:15-10:17:50 utm pop3proxy[2587]: Client wants message #28 
 2020:04:15-10:17:50 utm pop3proxy[2587]: Client wants message #29 
 2020:04:15-10:17:50 utm pop3proxy[2587]: Client wants message #30 
 2020:04:15-10:17:50 utm pop3proxy[2587]: Client wants message #31 
 2020:04:15-10:17:50 utm pop3proxy[2587]: Client wants message #32 
 2020:04:15-10:17:50 utm pop3proxy[2587]: Client wants message #33 
 2020:04:15-10:17:50 utm pop3proxy[2587]: Client wants message #34 
 2020:04:15-10:17:50 utm pop3proxy[2587]: Client wants message #35 
 2020:04:15-10:17:50 utm pop3proxy[2587]: Client wants message #36 
 2020:04:15-10:17:50 utm pop3proxy[2587]: Client wants message #37 
 2020:04:15-10:17:50 utm pop3proxy[2587]: Client wants message #38 
 2020:04:15-10:17:50 utm pop3proxy[2587]: Client wants message #39 
 2020:04:15-10:17:50 utm pop3proxy[2587]: Client wants message #40 
 2020:04:15-10:17:50 utm pop3proxy[2587]: Client wants message #41 
 2020:04:15-10:17:50 utm pop3proxy[2587]: Client wants message #42 
 2020:04:15-10:17:50 utm pop3proxy[2587]: Client wants message #43 
 2020:04:15-10:17:50 utm pop3proxy[2587]: Client wants message #44 
 2020:04:15-10:17:50 utm pop3proxy[2587]: Client wants message #45 
 2020:04:15-10:17:51 utm pop3proxy[2587]: Client wants message #46 
 2020:04:15-10:17:51 utm pop3proxy[2587]: Client wants message #47 
 2020:04:15-10:17:51 utm pop3proxy[2587]: Client wants message #48 
 2020:04:15-10:17:51 utm pop3proxy[2587]: Client wants message #49 
 2020:04:15-10:17:51 utm pop3proxy[2587]: Client wants message #50 
 I increased the debugging level for the proxy (level 5) and I can't see any errors nor complains beyond what's shared already, I just receive the full messages and the counter for processed POP3 messages stays at 0, I also tried to disable the prefetch mode without any luck. 
 Cheers!

DouglasFoster · Accepted Answer

You have not said how you know that messages are not being checked. I do not see anything in the logs indicating that you have a problem. 
 The log indicates that prefetch mode is on, which changes the behavior of UTM. If you are seeing messages delivered, it means that UTM connected to Gmail for successful download, and that you connected to UTM for successful relay. All of this implies that everything is working perfectly. But the obvious thing to try next is to disable prefetch to see if it changes your perceived symptoms. 
 General trouble-shooting issues: 
 Routing: 
 Your routing appears to be fine, but here are some things that could go wrong: 
 
 POP3 is a transparent proxy. It only works if the traffic has to pass through UTM on its way to the Internet. 
 POP3 proxy only intercepts traffic from source IPs listed in its Allowed Networks list. Other sources will bypass the proxy. 
 Transparent proxies only check specific ports. If you are using a non-standard port, the traffic will bypass the proxy. 
 
 TLS Inspection: 
 
 UTM needs to be able to impersonate the remote mail server to the POP3 client. You said that the remote system is Gmail, so I doubt that you have a valid commercial certificate for google.com. Instead, you need to generate a certificate within UTM for the target host name, and configure that certificate on the pop3 proxy. Additionally, you need to install the UTM VPN CA certificate on the client, so that the UTM server certificate will be trusted when UTM offers it. (You do not install the server certificate on the client.) Given that mail is being received, I am guessing that Fetchmail is configured to ignore certificate errors. If it was enforcing certificate verification, any certificate problems would prevent messages from being downloaded.