Linux – Does snmpd support SNMP monitoring of SendMail queues

Since the default value of QueueLA is 8 * numproc and for RefuseLA 12 * numproc a value of 50 may not be that ridiculous. Try however swapping the values of QueueLA and RefuseLA so that QueueLA > RefuseLA. This trick comes from Vixie and Avolio (Sendmail Theory and Practice):

"Setting them as shown here gives Sendmail a range of load average in which it is capable of delivering messages from its queue but incapable of receiving new messages. This is intentional. If you set Ox to be less than OX, Sendemail has instead a range of load average in which it can receive new mail (thus adding to the queue) but cannot deliver any queued mail."

Let us know what happens

I can confirm that I am seeing the same thing, independently; a sendmail installation with no certificates configured in is still taking advantage of TLS when sending to a server which advertises itself as supporting that protocol.

To see what's going on, I ran a packet capture with tcpdump -n -n -w /tmp/pax.dump port 25 and host 178.18.123.145 on the sending server, then fed that packet dump into wireshark, which told me this:

Note how the highlighted packet (no. 17) contains certificate information, as did the packet four prior (no. 13). Packet 13 is the server's certificate, with the chain of trust, and has "Certificates length" of 2327 bytes. This one is the client's certificate, and it has length zero bytes (highlighted line in the packet breakdown window). So I think there's pretty good evidence to suggest that sendmail generates a random keypair for client purposes, and presents it with a zero-length certificate.

If you find this behaviour annoying, as I did, you can turn it off for communications to all hosts by putting

Try_TLS:                NO

in /etc/mail/access and regenerating access.db.