[Info-vax] TCPIP Services IMAP and POP resource consumption

[Rich Jordan]

On Saturday, February 6, 2016 at 10:08:36 AM UTC-6, Stephen Hoffman wrote:
> On 2016-02-06 00:24:14 +0000, Rich Jordan said:
> 
> > But using TELNET to the POP server takes almost 60 seconds for the 
> > banner to come back.  Enter USER USERNAME, and its almost a minute 
> > before you are told Password required.  QUIT responds in about 20 
> > seconds.
> > 
> > So we're going to turn up logging, see if we can monitor things to find 
> > out what the slowdown is.
> 
> I'd normally monitor locking traffic as contention on SYSUAF can cause 
> what you are seeing here, but that everything else that's working here 
> implies that this is isolated to POP.
> 
> Look for spam activity.   Your description fits what malware can do 
> when it discovers an open mail server.    Use tcpdump on the POP 
> traffic, since it's utterly wide open, insecure, and unencrypted.
> 
> Had a VMS box "discovered" by some malware, and that VMS box was then 
> used to blast out spam.   I'd briefly shut off the SMTP sending queues 
> while troubleshooting that box, and the backlog that quickly piled up 
> in the outgoing queues was quite impressive.
> 
> Moving to hosted mail or to a replacement server -- a Mac Mini can do 
> all of what this box is doing, and more easily and more securely -- is 
> likely the best path, and as these folks are apparently doing.   
> Present-day OpenVMS does not do this mail server job at all well, and 
> this OpenVMS box is very old and very much down-revision.
> 
> 
> 
> -- 
> Pure Personal Opinion | HoffmanLabs LLC

Hoff,
     we've been pressing them to move mail service for years.  Even licensing Mailtraq or Communigate Pro, or other mail app to run on their existing PC servers would have been a huge help.  But no budget (until now that we can't get the mail to run with any consistency).  Resource usage is now down to about 25-30% of what it was before, and today (just checked, with last POP restart at midnight last night) POP login and command response is down to 3-4 seconds.

     We did have issues with one PC in house repeatedly spewing out hundreds of copies of a large mail with attachment, but it was a legit email; we assumed it was just outlook on the (XP, Office 2003) box malfunctioning.  THAT tied up all the SMTP queues.  There has been no other sign of that kind of flooding on the SMTP side.  Relay checks show the system is secure from any outside access, and we had also done like you, paused the queues, let mail build up, and review the headers and top info on the many files that built up.  Outbound mail was clean.

     They do receive a lot of spam (because they could or would not pay for any amelioration) which can tie things up now and again.  I have no doubt getting rid of the inbound spam would have helped, especially for the users who stopped removing messages from the server (which they claim they didn't do but that's how the two Outlooks checked so far were set).

     Hopefully we can keep it running at least somewhat through the next few weeks until the migration occurs.  If we get hold of the box after that I'll run the full set of available tests, rebuild it, then test again just to be sure there's no actual hardware issues (no sign of that has been seen).