# Key expiration

## How extending works

Extend sets the expiry to **now + the profile's key validity**. It does not add to the existing expiry, so clicking twice does not stockpile time, and it does not use the duration the key was originally created with — that is never stored.

The consequence is that policy changes apply on the next extend: move a user from a 30-day profile to a 365-day one and their existing key extends by 365, without needing to be regenerated.

## Expiry notifications

Keys expire, so users are warned before they do — otherwise a key dies silently in someone's pipeline.

- The dashboard shows a warning once a key is within the widest email threshold that applies to it (see below), and an error once it has expired.
- With `SMTP_HOST` set, an email goes out at 14, 3 and 1 days before expiry. Each notice is sent at most once per key and threshold; a delivery failure leaves it pending so the next run retries. A recipient the relay reports as gone, such as a mailbox that no longer exists, is logged as a warning and not retried; any other refusal is retried, since it usually means the relay is misconfigured rather than the user.
- A notice is skipped when its threshold is not under 80% of the time the key was valid for when it was created or last extended: the user has just seen the date. A 14-day key gets the 3- and 1-day notices, a 30-day key all three.
- A key gets at most one notice at a time. When several are due together, for instance after Keyosk was down, only the most urgent goes out.
- The notice is bilingual, German first: nothing records a per-user language, so it cannot pick one. Both halves carry the expiry date and the Keyosk link.

The thresholds are a code-level default (`notify.DefaultThresholds`), not an admin setting.

Without `SMTP_HOST` Keyosk logs what it would have sent. It does not silently pretend mail was delivered.