Provides a simple, tiny webservice that serves a contact form and sends responses via e-mail.
→
The simplest way to use this is via docker. See the examples directory for some
example docker-compose files. The latest stable version of this project is published
at ghcr.io/csmith/contact-form:latest.
You should place this service behind an TLS-terminating proxy such as Caddy or Traefik, and ensure it is requested over a secure connection.
The application can be configured either using command line arguments or environmental variables (shown in square brackets, below). from, to, smtp-host, smtp-user, and smtp-pass are required; other options have vaguely sensible fallbacks.
-csrf-trusted-origins string
[CONTACT_CSRF_TRUSTED_ORIGINS] Comma-separated list of trusted origins to bypass CSRF checks
-enable-captcha
[CONTACT_ENABLE_CAPTCHA] Whether to require captchas to be completed
-enable-health-check
[CONTACT_ENABLE_HEALTH_CHECK] Whether to expose health checks at /_health
-from string
[CONTACT_FROM] address to send e-mail from
-log.format string
[CONTACT_LOG_FORMAT] Format of log output ('json' or 'text') (default "text")
-log.level string
[CONTACT_LOG_LEVEL] Lowest level of logs that should be output
-oopspam-apikey string
[CONTACT_OOPSPAM_APIKEY] API key to use for OOPSpam (disabled if not set)
-oopspam-block-dc
[CONTACT_OOPSPAM_BLOCK_DC] Whether to block messages routed from data centre IP ranges
-oopspam-block-temp-email
[CONTACT_OOPSPAM_BLOCK_TEMP_EMAIL] Whether to block temporary email addresses
-oopspam-block-vpn
[CONTACT_OOPSPAM_BLOCK_VPN] Whether to block messages routed via VPN providers
-oopspam-check-for-length
[CONTACT_OOPSPAM_CHECK_FOR_LENGTH] Whether to check minimum message length (default true)
-oopspam-error-handler string
[CONTACT_OOPSPAM_ERROR_HANDLER] What to do if OOPSpam check errors (captcha, allow, deny) (default "deny")
-oopspam-spam-handler string
[CONTACT_OOPSPAM_SPAM_HANDLER] What to do if OOPSpam detects spam (captcha, allow, deny) (default "deny")
-oopspam-url-friendly
[CONTACT_OOPSPAM_URL_FRIENDLY] Whether to reduce the impact of links on spam score
-port int
[CONTACT_PORT] port to listen on for connections (default 8080)
-session-path string
[CONTACT_SESSION_PATH] Path to persist session information (default "./sessions.db")
-smtp-host string
[CONTACT_SMTP_HOST] SMTP server to connect to
-smtp-pass string
[CONTACT_SMTP_PASS] password to supply to the SMTP server
-smtp-port int
[CONTACT_SMTP_PORT] port to use when connecting to the SMTP server (default 25)
-smtp-user string
[CONTACT_SMTP_USER] username to supply to the SMTP server
-subject string
[CONTACT_SUBJECT] e-mail subject (default "Contact form submission")
-to string
[CONTACT_TO] address to send e-mail to
All templates are loaded from the templates directory, which is expected to
be in the current working directory. The form itself is loaded from form.html;
success and failure pages from success.html and failure.html respectively.
If captcha support is enabled, the captcha page is loaded from captcha.html.
Each page is loaded as a go html.template and
can use the templating syntax described there.
Any query parameters passed to the form will be accessible through the {{ .params }} template field. The
default template will include all parameters as hidden fields in the form.
If the form contains a field named from, it will be used in the Reply-To header,
and included in log messages to help trace issues. Otherwise, no
special processing is applied to any field; they are all simply written out to the message body.
No server-side validation is performed.
When running from the docker image, templates are stored in /templates; you can
replace this with a volume to supply custom templates.
Any files in the static directory will be served under the path /static/.
By default that is just a single stylesheet (style.css) that is used by the
default templates.
When running from the docker image, static files are stored in /static; you can
replace this with a volume to supply custom files.
Optional OOPSpam integration can be enabled by setting
the oopspam-apikey flag (or CONTACT_OOPSPAM_APIKEY env var). By default if
the request to OOPSpam fails (e.g. because of server issues, or exceeding the
rate limits) the contact attempt will be failed. You can change this with the
oopspam-error-handler flag (or CONTACT_OOPSPAM_ERROR_HANDLER env var):
allow will just send the message, captcha will present a captcha challenge.
Messages with a score greater than or equal to 3 are considered spam, and
the behaviour in the oopspam-spam-handler flag (or
CONTACT_OOPSPAM_SPAM_HANDLER env var) will determine what happens next. The
default behaviour is to deny the request.
The enable-captcha setting is ignored if OOPSpam is enabled. Captchas will
be presented if the error handler or spam handler has the value captcha
otherwise they won’t be.
If present, the X-Forwarded-For header will be used to determine the client’s
IP address. This is not validated in any way. It is assumed that the contact
for is hosted behind a TLS-terminating proxy that will ensure this header is
passed on with valid data.
If the -enable-health-check flag is present, a healthcheck endpoint will be exposed at /_health.
This implements the draft-inadarei-api-health-check-04
specification. Any application error that occurs when sending a mail or generating a captcha will
result in a failing health check until the same operation succeeds again.
Note that the health check exposes error messages, which could potentially contain information about the configuration of the service or parts of messages being sent. If this is a concern you may wish to restrict access to the URL.
Developed by Chris Smith; CSS heavily based on the login form in ig by Greg Holmes.
Captchas are implemented using the dchest/captcha library. Health checks are implemented using nelkinda/health-go.
