CWP Outbound Packets

Guys, what's going on here?
I first spotted this issue on a NAT VPS but have since seen similar activity on other VPS' with dedicated IPs. On the NAT one the packets were sourced from root, cwpsrv and amavis.
Why are systems attempting to contact cloudmark/proofpoint via a dedicated port?

Apr  5 15:43:18 cwp kernel: Firewall: *TCP_OUT Blocked* IN= OUT=eth0 SRC=10.0.0.130 DST=208.83.139.205 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=26965 DF PROTO=TCP SPT=50278 DPT=2703 WINDOW=29200 RES=0x00 SYN URGP=0 UID=0 GID=0
Apr  5 15:43:19 cwp kernel: Firewall: *TCP_OUT Blocked* IN= OUT=eth0 SRC=10.0.0.130 DST=208.83.139.205 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=26966 DF PROTO=TCP SPT=50278 DPT=2703 WINDOW=29200 RES=0x00 SYN URGP=0 UID=0 GID=0
Apr  5 15:43:42 cwp kernel: Firewall: *TCP_OUT Blocked* IN= OUT=eth0 SRC=10.0.0.130 DST=208.83.137.117 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=6618 DF PROTO=TCP SPT=60906 DPT=2703 WINDOW=29200 RES=0x00 SYN URGP=0 UID=990 GID=986
Apr  5 15:43:43 cwp kernel: Firewall: *TCP_OUT Blocked* IN= OUT=eth0 SRC=10.0.0.130 DST=208.83.137.117 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=6619 DF PROTO=TCP SPT=60906 DPT=2703 WINDOW=29200 RES=0x00 SYN URGP=0 UID=990 GID=986
Apr  5 15:43:43 cwp kernel: Firewall: *TCP_OUT Blocked* IN= OUT=eth0 SRC=10.0.0.130 DST=208.83.139.205 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=31254 DF PROTO=TCP SPT=50282 DPT=2703 WINDOW=29200 RES=0x00 SYN URGP=0 UID=990 GID=986
Apr  5 15:43:44 cwp kernel: Firewall: *TCP_OUT Blocked* IN= OUT=eth0 SRC=10.0.0.130 DST=208.83.139.205 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=31255 DF PROTO=TCP SPT=50282 DPT=2703 WINDOW=29200 RES=0x00 SYN URGP=0 UID=990 GID=986

[root@ny ~]# grep "TCP_OUT Blocked" /var/log/messages
Apr  5 10:43:00 ny kernel: Firewall: *TCP_OUT Blocked* IN= OUT=eth0 SRC=23.94.xxx.xxx DST=208.83.139.205 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=57075 DF PROTO=TCP SPT=35026 DPT=2703 WINDOW=29200 RES=0x00 SYN URGP=0 UID=0 GID=0
Apr  5 10:43:01 ny kernel: Firewall: *TCP_OUT Blocked* IN= OUT=eth0 SRC=23.94.xxx.xxx DST=208.83.139.205 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=57076 DF PROTO=TCP SPT=35026 DPT=2703 WINDOW=29200 RES=0x00 SYN URGP=0 UID=0 GID=0
Apr  5 10:43:01 ny kernel: Firewall: *TCP_OUT Blocked* IN= OUT=eth0 SRC=23.94.xxx.xxx DST=208.83.137.118 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=1495 DF PROTO=TCP SPT=55922 DPT=2703 WINDOW=29200 RES=0x00 SYN URGP=0 UID=0 GID=0
Apr  5 10:43:02 ny kernel: Firewall: *TCP_OUT Blocked* IN= OUT=eth0 SRC=23.94.xxx.xxx DST=208.83.137.118 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=1496 DF PROTO=TCP SPT=55922 DPT=2703 WINDOW=29200 RES=0x00 SYN URGP=0 UID=0 GID=0

Does appear to be amavis related and I'm very concerned that it runs under root privileges, in some cases - on another server..

Apr  9 06:09:45 au kernel: Firewall: *TCP_OUT Blocked* IN= OUT=eth0 SRC=103.108.xxx.xxx DST=208.83.137.118 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=28676 DF PROTO=TCP SPT=50150 DPT=2703 WINDOW=29200 RES=0x00 SYN URGP=0 UID=0 GID=0
Apr  9 17:01:06 au kernel: Firewall: *TCP_OUT Blocked* IN= OUT=eth0 SRC=103.108.xxx.xxx DST=208.83.137.117 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=57123 DF PROTO=TCP SPT=56586 DPT=2703 WINDOW=29200 RES=0x00 SYN URGP=0 UID=990 GID=986

[root@au ~]# grep 986 /etc/group
amavis:x:986:clamscan

Is this a known (stealth) activity?

Google is your friend:
https://lmgtfy.com/?q=clamav+2703


https://www.speedguide.net/port.php?port=2703

Google is your friend:
https://lmgtfy.com/?q=clamav+2703


https://www.speedguide.net/port.php?port=2703

Revenge is sweet - got some of my own medicine.
Wouldn't be so bad but thought I'd removed clamd/clamav/amavis/spamassassin on the ny and cwp instances. Speaking of which, the au instance keeps saying it needs updated, even though I've done it twice! (python3 reinstall required.) Grr, wish the clamav maintainers would get their act together.

AntiSpam/AntiVirus (recommended):    ClamAV, Amavis & Spamassassin, Requires 1Gb+ RAM

Need an option to NOT use/install amavis, nor install Razor.
Don't need more bloat in the system!

This stealth method of connecting to cloudmark is unacceptable (what's wrong with port 443?) and people really should boycott its' use.