I did some research. The error=2013 is a MySQL error which basically states that the thread (MySQL) that is servicing the process (Amavis) has been closed. I am wondering if perhaps MySQL is not running enough threads on this server to keep Apache, Amavis, phpList, and everything else that relies on MySQL happy, and as a result, it's killing off older threads to spawn new ones for new requests?

I did notice that after Debian recently released their upgrade for MySQL-server, this began happening. I'm really grasping at straws here, but things appear to be working normally, until the server goes under heavy load from phpList sending out a campaign, and then the Pandora's box opens, and everything begins failing miserably.

---edit---

I was a wee bit off on the whole MySQL killing off threads to spawn new ones for new processes. What I didn't realize is that, with the way that MySQL is configured in my.cnf, there is no limit on how many new threads MySQL can spawn, which keeps it scalable for when new requests are made to MySQL. Looking over the data, I realize that Amavis can just request a new connection to MySQL using a different thread than the one that MySQL closed. I'm still confused about the Amavis eval 95 line 200 part though. Why isn't this just a normal "MySQL has gone away" error? What's different about this?

Yes, I have the correct username and password for Amavisd in the config files. Amavis is able to connect to the database just fine. I'm not getting any errors saying that it can't connect. The only thing that's changed is Debian's version of mysql-server. Here's an excerpt of the mysql error log from my system, after I rebooted this morning:

150827 10:41:23 [Note] /usr/sbin/mysqld (mysqld 5.5.44-0+deb8u1) starting as process 2210 ...
150827 10:41:23 [Warning] Using unique option prefix myisam-recover instead of myisam-recover-options is deprecated and will be removed in a future release. Please use the full name instead.
150827 10:41:23 [Note] Plugin 'FEDERATED' is disabled.
150827 10:41:23 InnoDB: The InnoDB memory heap is disabled
150827 10:41:23 InnoDB: Mutexes and rw_locks use GCC atomic builtins
150827 10:41:23 InnoDB: Compressed tables use zlib 1.2.8
150827 10:41:23 InnoDB: Using Linux native AIO
150827 10:41:23 InnoDB: Initializing buffer pool, size = 128.0M
150827 10:41:23 InnoDB: Completed initialization of buffer pool
150827 10:41:23 InnoDB: highest supported file format is Barracuda.
150827 10:41:23  InnoDB: Waiting for the background threads to start
150827 10:41:24 InnoDB: 5.5.44 started; log sequence number 336435488
150827 10:41:24 [Note] Server hostname (bind-address): '127.0.0.1'; port: 3306
150827 10:41:24 [Note]   - '127.0.0.1' resolves to '127.0.0.1';
150827 10:41:24 [Note] Server socket created on IP: '127.0.0.1'.
150827 10:41:24 [Note] Event Scheduler: Loaded 0 events
150827 10:41:24 [Note] /usr/sbin/mysqld: ready for connections.
Version: '5.5.44-0+deb8u1'  socket: '/var/run/mysqld/mysqld.sock'  port: 3306  (Debian)

Should the buffer pool be higher? I also did some reading up on the errors that I was getting in the threads that I had created about my old server / OS / installation, regarding to postfix dying when I was trying to send an email campaign. There were problems with trivial rewrite, problems with a rw loop, postfix-qmgr dying, and problems with proxymap not working, and basically everything that was tied to MySQL just completely grinding to a halt. Everything that I have been reading has been pointing at problems with MySQL. Hopefully someone can help me with this, as this has been a serious problem.

I increased my MySQL InnoDB buffer pool to 512M to see if perhaps it makes a difference. I have one database on this machine that is 130M+ for phpList, alone. If there were cron jobs that were running against the phpList database yesterday at almost the same time as the Amavis disconnects, that could explain why it wasn't performing properly. It was taking too long for MySQL to respond to Amavis' request for information, because MySQL was too busy performing a cron job which was taking up quite a bit of MySQL's resources... I'm just guessing here, but I'm thinking that my buffer pool was set far too low. I'm going to monitor it and see if this helps. As I said, it seems that everything continues to tie back to MySQL as being the culprit, here.

I also took my MySQL thread cache size from 8 to 20. That may eliminate some of the problems with MySQL closing Amavis' threads. The more I look at it, the more I realize that I don't think that MySQL was optimized correctly for my system's needs. I think that MySQL was choking on everything that I was throwing at it.

Absolutely! So far, so good with the new tuning. I'm going to keep an eye on it for the next couple of days, and if the problem seems to resolve, I'll definitely post my tuning.