smtpcheck, imapcheck, popcheck

Mail fails quietly. A server that stops offering STARTTLS, or renews onto a certificate for the wrong name, keeps accepting connections while every sender that insists on TLS backs off and retries for days. These checks count the TLS upgrade and the certificate as part of “up”, and warn before the certificate expires.

A check never sends mail and never opens a mailbox. It reads the greeting and the capabilities, upgrades to TLS, logs in if asked, and says goodbye.

All three run on your own agents only. Mail-server probes from Pingtower’s shared addresses would put those addresses’ reputation at risk, so a check that names a Pingtower region is refused with a 422 under the rule agent_only. See Hosted checks.

Parameters

The three take the same parameters.

TLS is 1.2 or later. The certificate is always verified, and there is no parameter to skip that.

Logging in

Set username and give the check a PASSWORD in its env, which is the only name a mail check’s env takes. The password is sealed at rest and write-only, and a login is only ever sent over TLS: username or PASSWORD with tls: none is refused. One without the other is refused too. Changing address without sending PASSWORD again is refused with a 422, so a stored password never goes to a new server. So is adding a source to sources without it, so it never reaches an agent it was not sealed for: env: sources now include <names> the env was not sealed for; re-supply env (or send {} to clear it). Removing or reordering sources keeps it. Minting a new agent token for a source stops the check running from that source until you send PASSWORD again: see Secrets.

SMTP logs in with AUTH PLAIN, or AUTH LOGIN when that is all the server offers over TLS. IMAP uses LOGIN, and POP3 USER and PASS. An error never carries the server’s text, so a server that echoes the password can’t put it into an event.

The password reaches the agent only inside a check that Pingtower assigns to it, so a login works only on a check stored in Pingtower, not on a check in a local agent.yaml. A check stored in Pingtower must name a host that resolves to a public address, and the agent refuses to dial a private one for it. A server on a private network can be checked from the agent’s own agent.yaml, without a login.

Status

A completed dialogue is up: STARTTLS ok, logged in, certificate valid for 87d. If the certificate has warn_before or less left, it is degraded: STARTTLS ok; certificate expires in 12d.

It is down when:

• the host does not resolve, the connection is refused, or the server stops answering: timed out;
• the greeting is not a mail greeting, or lacks expect_banner;
• the server does not offer the upgrade (STARTTLS not offered), refuses it, or sends data before the handshake;
• the handshake fails, or the certificate is expired, not trusted, or not valid for server_name;
• the login is rejected, or an SMTP server offers neither AUTH PLAIN nor AUTH LOGIN.

Measurements

The checks need addons agent 0.4.0 or later; an older agent reports them as unknown addons.

Example

- id: mx-submission
  addon: smtpcheck
  interval: 5m
  with:
    address: mail.acme.example:587
    expect_banner: ESMTP
    warn_before: 336h        # 14 days

- id: imap
  addon: imapcheck
  interval: 5m
  with:
    address: mail.acme.example:993
    tls: implicit

A rule for it

{"name":"mail-cert-expiring","match":{"tags":["addon:smtpcheck","addon:imapcheck","addon:popcheck"]},
 "conditions":[{"key":"days_until_expiry","op":"lte","value":14}],
 "identifier_keys":["check"],"renotify_minutes":1440}