crans
/
documentation
mirror of https://gitlab.crans.org/nounous/documentation.git
19
0
Fork 0
Code Issues Projects Releases Wiki Activity

Corrections 1

merge-requests/21/head
glevy 2025-07-23 22:05:15 +02:00
parent 2c126fe34a
commit 08ba68fb3a
1 changed files with 66 additions and 37 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

101
services/mail/normes.md
View File

@ -15,7 +15,6 @@ seront décrites.
bien que mal, en proposant de chiffrer les mails qui transitent d'un MTA à un
autre, signant les mails émis par un serveur,... Toutes ces techniques sont
mises en place autour du protocole mail, lequel ne change pas.
- Aujourd'hui, certains organismes influents ont le bon goût de rejeter les
mails issus de serveurs n'implémentant pas les protocoles les plus
importants. Quoi que l'on pense du poids de l'influence des géants, cela
@ -27,7 +26,7 @@ seront décrites.
## Au Cr@ns
| | *Statut au Cr@ns ?* | Adoption |
|---------+-------------------+------------------------------------|
|---------|-------------------|------------------------------------|
| SPF | Implémenté | Large |
| DKIM | Implémenté | Large |
| SRS | Implémenté | ? |
@ -37,6 +36,7 @@ seront décrites.
| DANE | Non-implémenté | Faible (requiert DNSSEC) |
Tous ce qui est discuté ci-dessous fonctionne de la manière suivante :
- l'infrastructure émettrice (le Cr@ns) publie des informations la concernant,
- les serveurs réceptionnant les mails (les `MX` des destinataires des mails émis par
le Cr@ns) peuvent vérifier les mails à l'aide de ces informations.
@ -45,7 +45,7 @@ Tous ce qui est discuté ci-dessous fonctionne de la manière suivante :
émetteur car plus d'un service est souvent requis (*e.g.* un serveur DNS
autoritaire, un serveur Web,...).
# SPF
## SPF
- [SPF](https://www.rfc-editor.org/rfc/rfc7208),
- [Page Wikipédia](https://en.wikipedia.org/wiki/Sender_Policy_Framework).
@ -53,13 +53,18 @@ autoritaire, un serveur Web,...).
Le SPF (*Sender Policy Framework*) permet d'indiquer quels serveurs ont le droit
d'émettre des mails en `crans.org` (ou tout autre domaine, bien entendu).
## Implémentation (côté infrastructure émettrice)
### Implémentation (côté infrastructure émettrice)
Pour cela, nous publions un champ `TXT` pour `crans.org`. Voici le contenu que l'on
obtient pour quelques associations avec `kdig -t TXT crans.org` (`dig`
peut être utilisé à la place de `kdig`) :
- Cr@ns: `v=spf1 mx ip4:185.230.79.1 ip6:2a0c:700:2:0:ec4:7aff:fe59:a1ad ip4:185.230.79.38 ip6:2a0c:700:2::ff:fe01:3502 ~all`
Au Cr@ns :
```txt
v=spf1 mx ip4:185.230.79.1 ip6:2a0c:700:2:0:ec4:7aff:fe59:a1ad ip4:185.230.79.38
ip6:2a0c:700:2::ff:fe01:3502 ~all
```
Cela signifie que les serveurs mail du Cr@ns (`mx`) et les adresses listées (et
celles-ci uniquement) ont le droit d'envoyer des mails dont la source
@ -68,7 +73,11 @@ prétendue est *...@crans.org*.
Utiliser `~all` permet d'indiquer que si un mail provient d'une autre IP, il ne
faut pas rejeter le mail, mais le mettre en *permerror*.
- April: `v=spf1 include:spf.mailjet.com mx ip4:62.73.5.35 include:spf.protection.outlook.com include:_spf.april.com ip4:37.71.69.68 ip4:37.71.69.69 ip4:37.71.69.70 include:_spf.salesforce.com -all`
À l'April :
```txt
v=spf1 include:spf.mailjet.com mx ip4:62.73.5.35 include:spf.protection.outlook.com include:_spf.april.com ip4:37.71.69.68 ip4:37.71.69.69 ip4:37.71.69.70 include:_spf.salesforce.com -all
```
Idem, avec des champs `include:...` en plus. Ces derniers permettent d'inclure
un autre enregistrement SPF (*e.g.* celui de `spf.mailjet.com`).
@ -79,20 +88,20 @@ ne satisfaisant pas ce test. C'est une politique plus sévère que `~all`, qui a
D'autres mécanismes et formats existent, mais nous ne les présentons pas
ici. Se référer à la RFC ou la page Wikipédia pour leur description.
## Vérification (côté serveur récepteur)
### Vérification (côté serveur récepteur)
Lorsque `redisdead` (le `MX` du Cr@ns) reçoit un mail, nous demandons à un service
externe de vérifier le SPF (via la variable `smtpd_recipient_restrictions`). Le
service externe tourne sur la même VM et est `postfix-policyd-spf-python`.
# TODO SRS
## TODO SRS
- [Le papier d'origine](https://www.libsrs2.org/srs/srs.pdf),
- [La page Wikipédia](https://en.wikipedia.org/wiki/Sender_Rewriting_Scheme).
*Note :* les adresses générées par `postsrsd` sont valides pendant 21 jours.
# DKIM
## DKIM
- [La RFC](https://www.rfc-editor.org/rfc/rfc6376.html),
- [La page Wikipédia](https://en.wikipedia.org/wiki/DomainKeys_Identified_Mail).
@ -101,12 +110,13 @@ Le protocole DKIM (*Domain Key Identified Mail*) permet au serveur émetteur de
mails, et au serveur récepteur de vérifier cette signature, en utilisant des
méthodes de cryptographie asymétrique.
## Implémentation (côté émetteur)
### Implémentation (côté émetteur)
### Serveur mail
#### Serveur mail
Le serveur émetteur possède la clef privée. Il ajoute à tout mail sortant un
champ à l'en-tête de la forme suivante :
```txt
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=crans.org; s=mail;
t=1702660809; bh=NqcDLO2gkZU0IxcV+mE7uZ2NRnN/yfceH73Q1nhaFg4=;
@ -125,30 +135,43 @@ champ à l'en-tête de la forme suivante :
```
Le bloc contient une liste de clefs-valeurs :
- `v` indique la version du protocole,
- `d` le domaine attestant de la validité du mail,
- `s` le nom du sélecteur (/Cf/. plus bas),
- `b` et `bh` contiennent les signatures.
*Notes :*
- Il est possible que le mail ne soit pas signé par le domaine correspondant à
l'adresse d'envoi, puisqu'il est possible d'autoriser autrui à envoyer un
mail à notre place (*cf*. SPF plus haut).
- Se référer à la page Wikipédia, ou à la RFC pour une liste exhaustive des
clefs.
### Serveur DNS
#### Serveur DNS
Il faut placer dans le serveur DNS un champ TXT dont la clef est
`sélecteur._domainkey.domain`, où `domain` (resp. `sélecteur`) est la valeur de la
clef `d` (resp. `s`) définie plus haut.
Par exemple, pour le champ fourni plus haut, nous pouvons lire :
```txt
"v=DKIM1; k=rsa; " "p=MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAtwkNVd9Mmz8S4WcfuPk0X2drG39gS8" "+uxAv8igRILgzWeN8j2hjeZesl8pm/1UTVU87bYcdfUgXiGfQy9nR5p/Vmt2kS7sXk9nsJ/VYENg" "b3IJQ6paWupSTFMyeKycJ4ZHCEZB/bVvifoG6vLKqW5jpsfCiOcfdcgXATn0UPuVx9t93yRrhoEM" "ntMv9TSodjqd3FKCtJUoh5cNQHo0T6dWKtxoIgNi/mvZ92D/IACwu/XOU+Rq9fnoEI8GukBQUR5A" "kP0B/JrvwWXWX/3EjY8X37ljEX0XUdq/ShzTl5iK+CM83stgkFUQh/rpww5mnxYEW3X4uirJ7VJH" "mY4KPoIU+2DPjLQj9Hz63CMWY3Ks2pXWzxD3V+GI1aJTMFOv2LeHnI3ScqFaKj9FR4ZKMb0OW2BE" "FBIY3J3aeo/paRwdbVCMM7twDtZY9uInR/NhVa1v9hlOxwp4/2pGSKQYoN2CkAZ1Alzwf8M3EONL" "KeiC43JLYwKH1uBB1oikSVhMnLjG0219XvfG/tphyoOqJR/bCc2rdv5pLwKUl4wVuygfpvOw12bc" "vnTfYuk/BXzVHg9t4H8k/DJR6GAoeNAapXIS8AfAScF8QdKfplhKLJyQGJ6lQ75YD9IwRAN0oV+8" "NTjl46lI/C+b7mpfXCew+p6YPwfNvV2shiR0Ez8ZGUQIcCAwEAAQ=="
"v=DKIM1; k=rsa; "
"p=MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAtwkNVd9Mmz8S4WcfuPk0X2drG39gS8" "
+uxAv8igRILgzWeN8j2hjeZesl8pm/1UTVU87bYcdfUgXiGfQy9nR5p/Vmt2kS7sXk9nsJ/VYENg"
"b3IJQ6paWupSTFMyeKycJ4ZHCEZB/bVvifoG6vLKqW5jpsfCiOcfdcgXATn0UPuVx9t93yRrhoEM"
"ntMv9TSodjqd3FKCtJUoh5cNQHo0T6dWKtxoIgNi/mvZ92D/IACwu/XOU+Rq9fnoEI8GukBQUR5A" "kP0B/
JrvwWXWX/3EjY8X37ljEX0XUdq/ShzTl5iK+CM83stgkFUQh/rpww5mnxYEW3X4uirJ7VJH" "mY4KPoIU
+2DPjLQj9Hz63CMWY3Ks2pXWzxD3V+GI1aJTMFOv2LeHnI3ScqFaKj9FR4ZKMb0OW2BE" "FBIY3J3aeo/
paRwdbVCMM7twDtZY9uInR/NhVa1v9hlOxwp4/2pGSKQYoN2CkAZ1Alzwf8M3EONL"
"KeiC43JLYwKH1uBB1oikSVhMnLjG0219XvfG/tphyoOqJR/bCc2rdv5pLwKUl4wVuygfpvOw12bc" "vnTfYuk/
BXzVHg9t4H8k/DJR6GAoeNAapXIS8AfAScF8QdKfplhKLJyQGJ6lQ75YD9IwRAN0oV+8" "NTjl46lI/C
+b7mpfXCew+p6YPwfNvV2shiR0Ez8ZGUQIcCAwEAAQ=="
```
## Vérification (côté récepteur)
### Vérification (côté récepteur)
Côté réception (`redisdead` pour nous), nous utilisons le milter (filtre pour
mail) fourni par `opendkim`. Ce milter écoute en local et est appelé par `postfix`.
@ -157,17 +180,17 @@ prendre. Ce dernier va regarder les en-têtes du mail. Si il trouve une signatur
DKIM, il va effectuer la requête DNS décrite plus haut et vérifier la signature
du mail (valeurs des clefs `b` et `bh`).
# TODO DMARC
## TODO DMARC
- [La RFC](https://www.rfc-editor.org/rfc/rfc7489),
- [La page Wikipédia](https://en.wikipedia.org/wiki/DMARC).
# TODO ARC
## TODO ARC
- [La RFC](https://www.rfc-editor.org/rfc/rfc8617.html),
- [La page Wikipédia](https://en.wikipedia.org/wiki/Authenticated_Received_Chain).
* MTA-STS
## MTA-STS
- [La RFC](https://datatracker.ietf.org/doc/html/rfc8461),
- [La page Wikipédia](https://en.wikipedia.org/wiki/Simple_Mail_Transfer_Protocol#SMTP_MTA_Strict_Transport_Security).
@ -179,37 +202,39 @@ Contrairement au `DANE` (décrit plus bas), ce protocole ne demande pas la mise
place de DNSSEC. En revanche, il demande d'avoir un serveur Web accessible en
`https` (pour nous, `https://crans.org` doit être servi par un serveur Web).
## Implémentation (côté infrastructure émettrice)
### Implémentation (côté infrastructure émettrice)
### Dans la zone DNS
#### Dans la zone DNS
Il faut ajouter un champ `TXT` accessible à `_mts-sts.domain.tld`.
Quelques exemples :
- Gmail : `v=STSv1; id=20190429T010101;`,
- Microsoft : `v=STSv1; id=20190225000000Z;`,
- Outlook : `v=STSv1; id=20190225000000Z;`.
### Sur le serveur Web
#### Sur le serveur Web
Il faut que le serveur Web associé serve un fichier texte accessible à l'adresse
`https://mta-sts.domain.tld/.well-known/mta-sts.txt`
Quelques exemples :
+ [Gmail](https://mta-sts.gmail.com/.well-known/mta-sts.txt),
+ [Outlook](https://mta-sts.outlook.com/.well-known/mta-sts.txt),
+ [Microsoft](https://mta-sts.microsoft.com/.well-known/mta-sts.txt).
- [Gmail](https://mta-sts.gmail.com/.well-known/mta-sts.txt),
- [Outlook](https://mta-sts.outlook.com/.well-known/mta-sts.txt),
- [Microsoft](https://mta-sts.microsoft.com/.well-known/mta-sts.txt).
Le fichier texte contient une liste de clefs-valeurs. Ces clefs décrivent quel
protocole sera utilisé.
## Vérification côté récepteur.
### Vérification côté récepteur
Est-il possible d'utiliser `postfix-mta-sts-resolver` ? N'ayant pas implémenté cette
solution pour le moment (ni au Cr@ns, ni personnellement), nous ne pouvons pas
commenter sur le sujet.
# DANE
## DANE
- [La RFC](https://www.rfc-editor.org/rfc/rfc6698),
- [La page Wikipédia](https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Named_Entities).
@ -218,15 +243,16 @@ Actuellement, pour vérifier un certificat `C` proposé par un serveur mail, il
faire confiance à un certificat racine, lequel est utilisé pour signer un autre
certificat (dit *certificat intermédiaire*), lequel est utilisé pour signer le
certificat `C`. Pour vérifier `C`, il faut
+ faire confiance au certificat racine,
+ vérifier les deux signatures sus-mentionnées.
- faire confiance au certificat racine,
- vérifier les deux signatures sus-mentionnées.
`DANE` est une norme permettant aux propriétaires de domaines de déclarer quels
cetificats doivent être acceptés pour quels services.
*Note :* cela n'est pas spécifique aux mails.
## Implémentation (côté infrastructure émettrice)
### Implémentation (côté infrastructure émettrice)
Pour mettre en place `DANE`, il suffit d'ajouter un champ DNS à sa zone :
@ -247,7 +273,7 @@ Pour mettre en place `DANE`, il suffit d'ajouter un champ DNS à sa zone :
L'objectif de ce champ est d'indiquer comment vérifier le certificat.
| *Valeur* | *Signification* |
|--------+----------------------------------------------------------------------------------------------------------------------------------------------------------------|
|--------|----------------------------------------------------------------------------------------------------------------------------------------------------------------|
| 0 | Le certificat doit être valide (root -> intermediate -> "cert"), et /associated data/ décrit l'un des certificats parents de "cert" |
| 1 | `associated data` décrit "cert", et le certificat doit aussi être valide /wrt/. un certificat racine de confiance. |
| 2 | `associated data` décrit un parent de "cert". Ce parent est supposé de confiance, et "cert" doit bien être son descendant. |
@ -258,7 +284,7 @@ L'objectif de ce champ est d'indiquer comment vérifier le certificat.
Ce champ décrit ce qui est décrit par `associated data`.
| *Valeur* | *Signification* |
|--------+-----------------------------|
|--------|-----------------------------|
| 0 | Tout le certificat. |
| 1 | Seulement la clef publique. |
@ -268,7 +294,7 @@ Ce champ indique comment vérifier `associated data` contre la donnée du certif
(ou de la clef publique).
| *Valeur* | *Signification* |
|--------+--------------------------------------------------------|
|--------|--------------------------------------------------------|
| 0 | `associated data` doit être égal à la donnée. |
| 1 | `associated data` doit être égal au sha256 de la donnée. |
| 2 | `associated data` doit être égal au sha512 de la donnée. |
@ -287,11 +313,13 @@ peut faire la même chose (ou du `3 0 2`).
### Mise en place
Hypothèses :
- le serveur DNS accepte des mises à jour DNS dynamiques de la part du serveur
mail,
- le renouvellement du certificat utilise `certbot`.
Mise en place :
- Dans la confguration `certbot`,
+ passer en challenge DNS-01 et :
* `manual_auth_hook` : un script mettant en place le challenge,
@ -304,10 +332,10 @@ Mise en place :
deux TTL avant de (1) mettre en place le nouveau certificat et (2) retirer le
vieux champ TLSA.
Je propose de mettre en place un timer `systemd` qui serait activé "après
l'arrêt de `certbot` pour plus de 2 TTLs". Ce timer lancerait un service, lequel
aurait une condition d'activation "un certificat existe dans le dossier
staging".
Je propose de mettre en place un timer `systemd` qui serait activé "après
l'arrêt de `certbot` pour plus de 2 TTLs". Ce timer lancerait un service, lequel
aurait une condition d'activation "un certificat existe dans le dossier
staging".
### Exemple
@ -316,10 +344,11 @@ Mise en place :
=> 3 0 1 50E9221F066DCD1991ED9D3BA0AD10159F3585780F6FABBAE2942E43 37789FC8
```
## Implémentation (côté serveur mail destinataire)
### Implémentation (côté serveur mail destinataire)
Côté serveur mail destinataire, la configuration est très simple (car nous
utilisons Postfix). Cela se fait principalement via les options suivantes :
- `smtp_dns_supoprt_level` (valeur `dnssec`)
- `smtp_tls_dane_insecure_mx_policy` (valeur `dane`)