bb25f85ce8
This was intended to be a small followup for https://github.com/go-gitea/gitea/pull/23712, but...here we are. 1. Our docs currently use `slug` as the entire URL, which makes refactoring tricky (see https://github.com/go-gitea/gitea/pull/23712). Instead, this PR attempts to make future refactoring easier by using slugs as an extension of the section. (Hugo terminology) - What the above boils down to is this PR attempts to use directory organization as URL management. e.g. `usage/comparison.en-us.md` -> `en-us/usage/comparison/`, `usage/packages/overview.en-us.md` -> `en-us/usage/packages/overview/` - Technically we could even remove `slug`, as Hugo defaults to using filename, however at least with this PR it means `slug` only needs to be the name for the **current file** rather than an entire URL 2. This PR adds appropriate aliases (redirects) for pages, so anything on the internet that links to our docs should hopefully not break. 3. A minor nit I've had for a while, renaming `seek-help` to `support`. It's a minor thing, but `seek-help` has a strange connotation to it. 4. The commits are split such that you can review the first which is the "actual" change, and the second is added redirects so that the first doesn't break links elsewhere. --------- Signed-off-by: jolheiser <john.olheiser@gmail.com>
51 lines
2 KiB
Markdown
51 lines
2 KiB
Markdown
---
|
|
date: "2022-12-01T00:00:00+00:00"
|
|
title: "Incoming Email"
|
|
slug: "incoming-email"
|
|
weight: 13
|
|
draft: false
|
|
toc: false
|
|
aliases:
|
|
- /en-us/incoming-email
|
|
menu:
|
|
sidebar:
|
|
parent: "usage"
|
|
name: "Incoming Email"
|
|
weight: 13
|
|
identifier: "incoming-email"
|
|
---
|
|
|
|
# Incoming Email
|
|
|
|
Gitea supports the execution of several actions through incoming mails. This page describes how to set this up.
|
|
|
|
**Table of Contents**
|
|
|
|
{{< toc >}}
|
|
|
|
## Requirements
|
|
|
|
Handling incoming email messages requires an IMAP-enabled email account.
|
|
The recommended strategy is to use [email sub-addressing](https://en.wikipedia.org/wiki/Email_address#Sub-addressing) but a catch-all mailbox does work too.
|
|
The receiving email address contains a user/action specific token which tells Gitea which action should be performed.
|
|
This token is expected in the `To` and `Delivered-To` header fields.
|
|
|
|
Gitea tries to detect automatic responses to skip and the email server should be configured to reduce the incoming noise too (spam, newsletter).
|
|
|
|
## Configuration
|
|
|
|
To activate the handling of incoming email messages you have to configure the `email.incoming` section in the configuration file.
|
|
|
|
The `REPLY_TO_ADDRESS` contains the address an email client will respond to.
|
|
This address needs to contain the `%{token}` placeholder which will be replaced with a token describing the user/action.
|
|
This placeholder must only appear once in the address and must be in the user part of the address (before the `@`).
|
|
|
|
An example using email sub-addressing may look like this: `incoming+%{token}@example.com`
|
|
|
|
If a catch-all mailbox is used, the placeholder may be used anywhere in the user part of the address: `incoming+%{token}@example.com`, `incoming_%{token}@example.com`, `%{token}@example.com`
|
|
|
|
## Security
|
|
|
|
Be careful when choosing the domain used for receiving incoming email.
|
|
It's recommended receiving incoming email on a subdomain, such as `incoming.example.com` to prevent potential security problems with other services running on `example.com`.
|