# Yunohost en tant que serveur mail
:::info
Travail en cours, brouillon, incomplet, en complément de;
- https://doc.neutrinet.be/ipv6
:::
:::danger
En vue de faire un **Wiki post** de https://forum.yunohost.org/t/attaque-s-institutionnalisee-s-contre-les-noms-de-domaine-et-la-liberte-dauto-hebergement/24480 et de remplacer le sujet par « **Yunohost en tant que serveur mail** » ou autre.
Et de faire pareil pour la version anglaise https://forum.yunohost.org/t/institutionalized-attack-s-on-domain-names-and-self-hosting-freedom/24453 et de remplacer le titre par **Yunohost as a mail server** ou autre.
:::
## Todos
- faire en sorte que la doc de Yunohost mentionne que le choix d'un domaine gratuit permettra l'envoit de mail **mais que ceux ci finiront très probablement dans les spams** ET que l'utilisation d'un tel domaine va nuire à la réputation des adresses IP du fournisseur d'adresses IPv4 et IPv6 *(le FAI ou le fournisseur de VPN)*.
https://yunohost.org/fr/dns_nohost_me
- voir comment Yunohost pourrait implémenter le SOA pour les sous-domaines en .nohost.me, .noho.st et .ynh.fr.
- voir comment Yunohost pourrait pousser un meilleur enregisterement DNS pour le DMARC pour le `yunohost dyndns update`.
- voir comment Yunohost pourrait suggérer un meilleur enregistrement DNS pour le DMARC pour le `yunohost domain dns suggest`.
- corriger DMARC sur https://yunohost.org/fr/dns_config
- corriger l'outil de diagnostic qui s'attend seulement au record `"v=DMARC1; p=none"` ou dire qu'il faut désactiver ce diagnostic dans l'admin.
- répondre à la question *« est-ce que Yunohost envoit aussi des rapports dmarc quand on lui en demande ? »* et si ce n'est pas le cas, *« comment implémenter ça ? »*.
-
## Introduction.
Poursuivre un projet d'auto-hébergement basé sur Yunohost **avec l'idée d'utiliser les mails**, cela exige de prendre en compte des paramètres qui sont de plus en plus nombreux et complexes.
L'email au travers du protocole SMTP est un des plus vieux services décentralisé. Faisons en sorte qu'il soit encore possible d'héberger un serveur mail pour des projets personnels, familliaux ou professionnels de petites ou moyenne taille.
:::info
Les commandes utilisées ci-dessous sont disponibles sur un système d'exploitation GNU/Linux et sont peut-être différente sur Mac OS®, Windows® ou autre.
:::
Si vous considérez que cette documentation manque de rigueur, de précision ou que vous identifiez une erreur, libre à vous d'éditer ce sujet converti en « wiki-post ». Dés lors, si vous disposez des droits suffisant, l'icône représentant un crayon à des fins d'édition.
## Le nom de domaine et les sous-domaines.
Un **nom de domaine** c'est, par exemple : `exemple.com`.
Un **sous domaine** *(bien que cela ne veut pas dire grand chose techniquement)*, c'est par exemple : `ailleurs.chez.exemple.com`.
### Domaines et adresses mails
Deux adresses mails telles que `bidule@exemple.com` et `bidule@ailleurs.chez.exemple.com` peuvent se reposer sur un seul serveur mail ou des serveurs mails différents. C'est, à mon sens du moins, pourquoi la notion de *sous domaine* ne veut pas dire grand chose techniquement.
Du point de vue des serveurs qui enverront ou recevront des emails pour le compte de `bidule`, ce sont bien deux adresses différentes qui pourraient être gérées par deux serveurs mails différents, avec des adresses IPv4 et IPv6 différentes, des enregistrements DNS différents voir même des logiciels serveurs différents.
Ceci dit, ces deux adresses mails pourraient aussi être toutes les deux de simples **alias** d'une seule et unique boîte mail dont le « véritable nom » serait `bidule@le.vrais.serveur.mail.de.exemple.com`.
Comprennez par là qu'un serveur mail qui recevrait trois mails différents issus de *(From:)* `bidule@exemple.com` ou de `bidule@ailleurs.chez.exemple.com` ou encore de `bidule@le.vrais.serveur.mail.de.exemple.com` pourrait, pour chacun de ces différent mails hypothétiques, prendre la décision **d'accepter**, de **mettre en quarantaine** sur le serveur de réception ou dans les indésirables de la personne à qui ils seraient destinés ou de **rejeter** l'un ou l'autre de ces mails ou tout les trois.
C'est pourquoi le ou les noms de domaine gérés par votre serveur doivent être administrés avec attention. En quelque sorte, cela *aide* les serveurs mails à prendre des décision concernant ce qui sortirait de votre serveur.
### Éviter les domaines gratuits
Rappelons que Yunohost permet d'envoyer et recevoir des mails, en plus de l'installation de tout un tas d'autres applications.
Utiliser les domaines *gratuits* proposé par Yunohost peut s'avérer suffisant si vous n'avez pas l'ambition d'exploiter les fonctionnalités de courrier au quotidien.
Mais si vous souhaitez utiliser les fonctionnalités de courrier au quotidien, vers tout un tas d'organisations de part le monde, utiliser un nom de domaine *gratuit* n'est pas suffisant.
Dans ce cas, il faut éviter les domaines gratuits du genre `*.noho.st`, `*.nohost.me`, `*.ynh.fr`.
En exemple, Yahoo® à commencé à considérer **automatiquement en tant que spam et à les rejeter**, tout mail issu d'une adresse mail venant d'un sous domaine listé plus haut à cause du SOA. Voir la page [Yahoo Sender Hub - SMTP Error Codes](https://senders.yahooinc.com/smtp-error-codes/), dont vous trouverez ci-dessous la capture d'écran de l'extrait concerné en date du 07 août 2023.
Et voici un exemple en ligne de commande concercant le domaine `tierce.nohost.me` utilisé par la brique Internet de l'auteur à l'origine de cet article.
```
$ host -t soa exemple.com
exemple.com has SOA record ns1.abovedomains.com. hostmaster.trellian.com. 2023080801 10800 3600 604800 3600
$ host -t soa nohost.me
nohost.me has SOA record ns0.yunohost.org. hostmaster.yunohost.org. 1083874 10800 3600 604800 10
$ host -t soa tierce.nohost.me
tierce.nohost.me has no SOA record
```
Selon Yahoo® cela suffit à rejeter les mails issus du domaine `tierce.nohost.me`.
:::info
Petite observation de la part de l'auteur à l'origine de cet article.
La brique Internet qui se repose sur le domaine `tierce.nohost.me` dispose d'une boîte mail utilisée quotidiennement et de trois autres boîtes pour ainsi dire jamais utilisées.
Le volume de mails émis par ce serveur depuis son appartion sur Internet en décembre 2016 est largement inférieur à 2000 mails, toutes sources et tous destinataires confondus.
Soit, **moins d'un mail par jour** en moyenne entre 2016 et 2023.
Mais à cause de Yahoo®, de ses choix concerant le `SOA`, le choix pris par leurs algorithmes est le rejet pur et simple.
:::
Et comme souvent, une action en entraine une autre, lorsqu'un gros acteur du trafic mail commence à rejeter des mails, **peu importe la raison**, cela nuit à la réputation des **adresses IP** potentiellement associables tout ces domaines.
Lors d'un échange avec le support de Spamhaus, le Fournisseur d'Accès Internet Associatif Neutrinet asbl a reçu, entre autres, cet élément de réponse :
> *« You are aware of the dismal reputation of `nohost.me` ?
Because it is free, it gets abused continuously. Too much of that and it gets listed.*
Ce qui va de paire avec *« We do not discuss the specific criteria we use. »* que l'en peut lire sur la page de Spamhaus [Why is a domain listed in DBL?](https://www.spamhaus.org/faq/section/Spamhaus%20DBL#371) dont vous trouverez ci-dessous la capture d’écran de l’extrait concerné en date du 07 août 2023.
Du travail devrait être réalisé par les bénévoles de Yunohost *(elles ? eux ? vous ? moi ? qui d'autre ?)* à propos de la gestion DNS de ces domaines gratuits parce qu'il est, en théorie, possible de mettre en place la création d'enregistrement de type SOA pour les sous-domaines concernés.
Mais c'est probablement inutile parce que, du point de vue des acteurs de grande taille, un domaine c'est `exemple.com` et c'est sensé appartenir à une entité identifiable et `n.importe.quoi.d.autre.exemple.com` sera relégué au rang de « sous » domaine.
Et toujours de leur point de vue, si c'est gratuit et peu identifiable, cela sera considéré sans le moindre respect, peu importe les efforts techniques mis en place, que ce soit à des fins licite ou non.
### Préférez un domaine dont vous êtes propriétaire
Oui, c'est injuste et excluant pour les personnes qui ne souhaitent pas enregistrer un nom de domaine à leur nom ou qui ne peuvent pas se le permettre économiquement.
Mais Internet et les services mails ne sont pas toujours justes.
En terme d'intimité numérique, qui dit paiement dit traçabilité et qui dit traçabilité dit que vous devrez très probablement fournir une adresse email existante *(et probablement associée à votre futur nom de domaine)* et un numéro de téléphone au bureau d'enregistrement que vous choisirez.
Si vous cherchez un bureau d'enregsitrement *(registrar)*, il y a toute une liste, certe non exhaustive, dans [un sondage réalisé par Yunohost en 2021 *(en anglais)*](https://forum.yunohost.org/t/what-dns-registrars-are-you-using/17159).
### Liens en vrac à propos des noms de domaine
- https://freespeech.com/2023/04/19/red-alert-icann-and-verisign-proposal-would-allow-any-government-in-the-world-to-seize-domain-names/
- https://circleid.com/posts/83420_controversial_domain_names/
- https://www.accessnow.org/campaign/keepiton/
- [Politique de rappel des données Whois](https://www.icann.org/resources/pages/wdrp-2012-02-25-fr) - ICANN
- [Accrédité ou non à l'ICANN ?](https://openclassrooms.com/forum/sujet/registrar-non-accredite-par-l-icann-mefiance) - Sur un forum d'OpenClassRooms à propos d'Infomaniak
## Les adresses IPv4 et IPv6
Votre serveur Yunohost **doit** disposer d'adresse IPv4 et IPv6 **qui ne changent pas automatiquement** et qui sont donc des adresses dites **fixes** ou **statiques** routables sur Internet.
### IPv4
Votre serveur **doit** disposer d'une adresse IPv4 en `/32` publique et routable sur Internet.
### IPv6
Votre serveur **doit** disposer d'une adresse IPv6 en `/64` publique et routable sur Internet.
- à lire : https://engineering.linkedin.com/email/sending-and-receiving-emails-over-ipv6
:::info
à noter : IPv6 Blocklist minimum range
Based on how we view the specifications for allocation of IPv6 addresses, all Spamhaus blocklists will list IPv6 ranges no smaller than a /64.
https://www.spamhaus.org/organization/statement/012/spamhaus-ipv6-blocklists-strategy-statement
:::
Pas clair pour moi si un /64 est suffisant ou non.
Par exemple, pour tierce.nohost.me, j'ai pris un /64 chez Neutrinet… mais j'aurais dû prendre un /48 ou un /60.
Mais bon, ça ne m'explique pas encore pourquoi Spamhaus n'aime pas « mon ipv6 ou celle de paragram ».
```
2.4. Assigning Address Blocks
The original recommendation for assigning IPv6 address space to end users was as follows:
• /48 (65 536 subnets) in the general case, except for very large subscribers
• /64 (a single subnet) when it is known that one and only one subnet is needed by design
• /128 (a single address) when it is absolutely known that one and only one device is
connecting
However, RFC 6177 1 (also known as Best Current Practice 157) changes this, and recommends
using an address block / prefix size tailored to the end user's needs. It also recommends against
giving out single addresses. For instance, a /48 is much more than a home user needs, but a /64
only allows for a single subnet, which may be limiting, if not immediately, then in the future. So
a /56 or /60 may be more appropriate for consumers.
Source : https://www.ripe.net/support/training/material/IPv6-for-LIRs-Training-Course/Preparing-an-IPv6-Addressing-Plan.pdf
```
### Comment tester les adresses IP ?
- est-ce que c'est configuré automatiquement ?
- est-ce que l'outil de diagnostique teste et rapporte correctement ?
- quels autres outils ?
## Adresses IPs et reverse DNS (rDNS ou PTR)
Bien que cela concerne le FQDN de votre serveur mail, cet enregistrement DNS **doit** être pris en compte par votre fournisseur d'adresse IP tel que votre Fournisseur d'Accès Internet, de service d'ébergement de machine virtuelle, de service de colocation, de service VPN avec IP fixes, etc.
Dans l'exemple suivant, une birque Internet disposant du domaine `tierce.nohost.me` et d'adresses IPv4 et IPv6 fournies par Neutrinet ASBL cela donne;
```
~ ᐅ host tierce.nohost.me
tierce.nohost.me has address 80.67.181.227
tierce.nohost.me has IPv6 address 2001:913:1fff:ffff::b:d0fe
tierce.nohost.me mail is handled by 10 tierce.nohost.me.
~ ᐅ host 80.67.181.227
227.181.67.80.in-addr.arpa domain name pointer tierce.nohost.me.
~ ᐅ host 2001:913:1fff:ffff::b:d0fefe
e.f.0.d.b.0.0.0.0.0.0.0.0.0.0.0.f.f.f.f.f.f.f.1.3.1.9.0.1.0.0.2.ip6.arpa domain name pointer tierce.nohost.me.
```
Pour comparer avec des adresses qui, au 5 août 2023, ne dispose pas de PTR, les réponses obtenues sont bien différentes en affichent un nom générique associé au domaine du fournisseur.
```
~ ᐅ host 80.67.181.253
253.181.67.80.in-addr.arpa domain name pointer dynamic-80-67-181-253.reverse.neutri.net.
~ ᐅ host 2001:913:1fff:ffff::b:d0ff
f.f.0.d.b.0.0.0.0.0.0.0.0.0.0.0.f.f.f.f.f.f.f.1.3.1.9.0.1.0.0.2.ip6.arpa domain name pointer dynamic-2001-0913-1fff-ffff-0000-0000-000b-d0ff.v6.reverse.neutri.net.
```
### Comment tester le reverse DNS ?
- est-ce que c'est configuré automatiquement ?
- est-ce que l'outil de diagnostique teste et rapporte correctement ?
- quels autres outils ?
## Les ports TCP
Pour que votre serveur mail fonctionne correctement pour envoyer et recevoir du courrier et pour permettre à différents clients mail de s'y connecter pour les consulter ou les télécharger, il faut que les ports suivants soient ouverts et joignables au travers des ipv4 et ipv6 **fixes et publiques** de votre serveur Yunohost.
- `25`, `465` et `587` pour le protocole `SMTP` en `TCP` pour IPv4 **et** IPv6,
- `110` et `995` pour le protocole `POP` en `TCP` IPv4 pour **et** IPv6,
- `143` et `993` pour le protocole `IMAP` en `TCP` pour IPv4 **et** IPv6,
Réalsier cela « derrière » un modem-routeur *(une box Internet)* peut rendre cela plus compliqué, disfonctionnel et peut-être même impossible si le fournisseur des adresses IP de votre connexion ou de votre serveur Yunohost **bloquerait le trafic en amont** pour les ports concernés. C'est souvent le cas pour le **port 25 en tcp** par exemple.
### Comment tester l'ouverture des ports ?
- est-ce que c'est configuré automatiquement ?
- est-ce que l'outil de diagnostique teste et rapporte correctement ?
- quels autres outils ?
## DNS, l'enregistrement DMARC
### Liens en vrac
- https://fr.wikipedia.org/wiki/DMARC
- https://dmarc.org/wiki/FAQ#What_steps_should_I_follow_to_implement_DMARC_on_my_corporate_email_domain.3F
L'enregistrement `DMARC` sert d'outil d'information à l'attention des serveurs qui recevront des mails issus de votre serveur **et aussi** d'outil de diagnostique à l'attention des personnes qui gèrent un serveur ou un service mail.
En effet, il est possible de demander qu'un rapport automatique soit envoyé à une adresse mail du domaine concerné à l'aide des champs `rua=mailto:une.adresse@exemple.com` et `ruf=mailto:une.adresse@exemple.com`.
:::warning
Si les adresses mails définies dans le `rua=` ou le `ruf=` ne sont pas gérée par le même nom de domaine, il faut créer un enregistrement TXT supplémentaire au format `exemple.com._report._dmarc.autredomaine.com. TXT "v=DMARC1"`, comme [expliqué ici](https://dmarc.org/wiki/FAQ#I_published_a_DMARC_record_with_reports_going_to_another_domain.2C_but_none_seem_to_be_received).
:::
Il se repose sur les deux autres enregistrements que sont `DKIM` et `SPF`.
Un serveur qui reçoit un email va tester le SPF et le DKIM et si l'un de ces deux tests ou les deux tests en question échouent, l'enregistrement DMARC indique au serveur de réception quelle politique *(policy)* adopter en cas d'échec à l'un ou l'autre test effectué pour chaque email reçu.
:::danger
Dans Yunohost, la configuration par défaut des enregistrement est insuffisante avec `v=dmarc1; p=none;` il manque au moins le champ `rua=` et une adresse mail *(ou une url?)* pour y recevoir d'éventuels rapports.
:::
### Indispensables
v=
p=
rua=
### Optionnels (mais recommandés)
pct=100 (default)
sp=quarantine;
rua=mailto:rua-reports@example.com
fo=1
adkim=r
aspf=r
rf=afrf (default)
:::warning
Idée en vrac…
Est-ce qu'un serveur fraichement installé devrait avoir un p=quarantine et un pct=20 tant que des rapports ne sont pas reçus et analysés ? Ensuite, lorsque tout semble fonctionner correctement, le champ pct=100 peut-être assigné. En cas de changement de configuration, le champ pct= devrait redescendre pour signifier qu'il y a une « phase de test » en cours.
:::
## DNS, l'enregistrement DKIM
:::warning
Prise en charge automatique par Yunohost : partielle (ou complète, à vérifier). Yunohost génère des clés DKIM de 1024 bits là où les gros acteurs se basent sur des clés de 2048 bit.
:::
## DNS, l'enregistrement SPF
:::info
Mmmm… mais de quelles IP pourraient donc venir les mails de Gogol ?
`$ dig txt gmail.com`
`gmail.com. 43 IN TXT "v=spf1 redirect=_spf.google.com"`
Ha, c'est redirigé vers un autre record spf.
`$ dig txt _spf.google.com`
`_spf.google.com. 227 IN TXT "v=spf1 include:_netblocks.google.com include:_netblocks2.google.com include:_netblocks3.google.com ~all"`
Ha, c'est rediriqé vers trois autres records spf.
`$ dig txt _netblocks.google.com`
`_netblocks.google.com. 207 IN TXT "v=spf1 ip4:35.190.247.0/24 ip4:64.233.160.0/19 ip4:66.102.0.0/20 ip4:66.249.80.0/20 ip4:72.14.192.0/18 ip4:74.125.0.0/16 ip4:108.177.8.0/21 ip4:173.194.0.0/16 ip4:209.85.128.0/17 ip4:216.58.192.0/19 ip4:216.239.32.0/19 ~all"`
Ouille… ça fait un paquet d'ipv4 ça !
`$ dig txt _netblocks2.google.com`
`_netblocks2.google.com. 197 IN TXT "v=spf1 ip6:2001:4860:4000::/36 ip6:2404:6800:4000::/36 ip6:2607:f8b0:4000::/36 ip6:2800:3f0:4000::/36 ip6:2a00:1450:4000::/36 ip6:2c0f:fb50:4000::/36 ~all"`
Et un encore plus gros paquet d'ipv6 !
`$ dig txt _netblocks3.google.com`
`_netblocks3.google.com. 182 IN TXT "v=spf1 ip4:172.217.0.0/19 ip4:172.217.32.0/20 ip4:172.217.128.0/19 ip4:172.217.160.0/20 ip4:172.217.192.0/19 ip4:172.253.56.0/21 ip4:172.253.112.0/20 ip4:108.177.96.0/19 ip4:35.191.0.0/16 ip4:130.211.0.0/22 ~all"`
Des ipv4, il y en a un peu plus, je vous les mets quand même ?
Et en plus c'est avec `~all` C'est là où on voit que le rapport de force ne sera jamais équilibré parce qu'avec un petit serveur d'une petite organisation ce sera du genre `ip4:une.petite.ip ip6:idem -all` pour dire, avec une forme d'assurance, « vour pouvez rejeter tout ce qui ne viendra pas de `une.petite.ip` ou de `idem`.
Mais malgré ça, et malgré le fait que `une.petite.ip` va envoyer trois mails par semaine … ils risquent encore de se retrouver dans les spams comme de vulgaires pollueurs de boîtes mails. SPF, PTR, DKIM et rDNS mis en place ou non.
:::
## DNS, l'enregisterement MX
L'enregistrement `MX` d'un nom de domaine
C'est l'enregistrement qui renseignera Internet sur la ou les adresses IPv4 ou IPv6, souvent au travers de leur `FQDN`
Il en faut au moins un.
Si il y en a plusieurs pour un domaine en particulier la notion de priorité entrera en compte.
## DNS, l'enregistrement AAAA
## DNS, l'enregistrement A
## DNS, l'enregistrement SOA
## En cas de non respect
Les emails envoyés par votre serveur Yunohost finiront probablement dans les dossiers indésirables de vos destinataires ou seront tout simplement rejetés.
Pire encore votre serveur nuira à la réputation des adresses IPv4 et IPv6 qui vous seront fournies par l'opérateur réseau qui vous les aura attribuée.
Il en va donc de votre responsabilité en tant qu'administrateur·ice en herbe ou expérimenté.
## Mais pourquoi ?
Si les spam, les tentatives de fishing, les hoax ou d'autres arnaques par mail n'existaient pas, il n'y aurait probablement pas besoin de se prendre la tête avec ce qui est expliqué ici.
Par contre, de la part de gros fournisseurs tels que Microsoft®, Alphabet®, Yahoo®, AOL®, etc refuser des mails d'une machine qui envoit moins de, disons 100 par semaine, ce n'est pas très fair-play.
C'est pas la puissance de calcul qui leur manque, ni l'espace de stockage, ni les ressources intellectuelles pour mettre en place une politique de lutte contre les contenus non solicités qui serait un peu plus tolèrante envers les initiatives d'auto-hébergement qui se contenteraient de quelques mails privés, professionnels et peut-être l'un ou l'autre envoi en plus grand nombre.
À leur échelle, prendre la peine de compter qu'un serveur avec des adresses IPv4 et IPv6, a envoyé 42 mails ce mois-ci, devrait être à leur portée.
Mais malheureusement ce n'est pas comme ça que ça fonctionne.
À la base, votre fournisseur d'adresses IPv4 et IPv6 devra au moins s'être enregistré dans leur « programme de lutte contre le spam » pour signaler qu'en tant qu'humain·e ou en tant qu'entreprise, ils ou elles se portent, en quelque sort, garant de la bonne réputation des adresses IPv4 ou IPv6 dont ils ou elles ont la charge.
Et comme si cela ne suffisait pas, si les adresses IPv4 et IPv6 de votre tout nouveau serveur mail sont vues pour la première fois par les serveurs de ces organisations, elles sont déjà considérées comme suspectes parce qu'elles n'auraient pas de « réputation ». Là aussi, c'est pas très fair-play.
Mais le nombre de mail envoyés ou la bonne réputation des adresses IP de votre serveur (SPF, PTR) ne suffisent pas. Il faut aussi que ces mails soient authentiques (DKIM) et assoicé à un nom de domaine dont vous seriez le ou la propriétaire (SOA) et que les règles du traitement des échecs soient correctement définies (DMARC).
Mis à part ça, héberger un soit même un serveur mail ne se fera pas magiquement.
### Liens en vrac
- Spamhaus - [Why is a domain listed in DBL?](https://www.spamhaus.org/faq/section/Spamhaus%20DBL#371)
- Mailcow - [Spamhaus DNS Blocklist changes since 2023-07](https://mailcow.email/posts/2023/spamhaus-dnsblocklist/)
- Témoignage succint à propos de [La gestion SNDS/JMRP, ou le spam chez Microsoft](https://www.librement-votre.fr/dotclear/index.php?post/2021/02/11/La-gestion-SNDS/JMRP%2C-ou-le-spam-chez-Microsoft)
- Hezner - [Microsoft Blacklist](https://docs.hetzner.com/robot/dedicated-server/troubleshooting/microsoft-blacklist)
- Google - [Éviter que les messages envoyés aux utilisateurs Gmail soient bloqués ou marqués comme spam](https://support.google.com/mail/answer/81126?sjid=7412680081830483743-EU&visit_id=638271019114023282-1052170354&p=UnsolicitedIPError&rd=1&hl=fr)
## Tester
- https://www.abuseat.org/helocheck.html
- https://mail-tester.com
- https://jetmore.org/john/code/swaks/
## Contenus en relation
* Voici de l'aide à propos de [comment contribuer au code source de Yunohost](https://yunohost.org/fr/dev).
### Problèmes en tant que serveur
* https://github.com/YunoHost/issues/issues/2162
* https://github.com/YunoHost/issues/issues/2035
* https://github.com/YunoHost/issues/issues/1937
* https://github.com/YunoHost/issues/issues/1223
* https://github.com/YunoHost/issues/issues/1501
* https://github.com/YunoHost/issues/issues/1297
* https://github.com/YunoHost/issues/issues/947
* https://github.com/YunoHost/issues/issues/1858
* https://github.com/YunoHost/issues/issues/269
* https://github.com/YunoHost/issues/issues/1621
### Problèmes pour les clients
* https://github.com/YunoHost/issues/issues/1456
* https://github.com/YunoHost/issues/issues/1556
### Sujets sur le forum
* https://forum.yunohost.org/tag/mail
* https://forum.yunohost.org/tag/smtp
* https://forum.yunohost.org/tag/dns
* https://forum.yunohost.org/tag/dyndns