Technique · Normes
Normes respectées.Lacunes signalées.
Chaque protocole que parle FOLD est défini dans une RFC. Cette page recense celles à l’aune desquelles on juge un client de messagerie et indique, pour chacune, ce que fait le code aujourd’hui : implémenté, partiellement implémenté, pas encore implémenté ou délibérément écarté, et pourquoi.
Vérifié par rapport au code le 2026-09-23
- Implémenté
- 58
- Implémenté et en service.
- Partiel
- 8
- Une partie fonctionne ; la note précise laquelle.
- Pas encore
- 10
- Pas encore implémenté.
- Écarté
- 6
- Délibérément non implémenté ; la note en donne la raison.
Format des messages
Comment un message est construit, lu et affiché.
| RFC | Norme | Statut | Dans FOLD |
|---|---|---|---|
| RFC 5322 | Internet Message Format | Implémenté | Strict à l’écriture ; à la lecture, tolérant envers les sauts de ligne isolés, les en-têtes 8 bits et les variantes de date. |
| RFC 2045-2049 | MIME | Implémenté | FOLD télécharge le message entier et construit l’arbre MIME sur l’appareil. |
| RFC 2047 | MIME Encoded-Words | Implémenté | Texte non ASCII dans les en-têtes, décodé et encodé. |
| RFC 2231 | MIME Parameter Value and Encoded Word Extensions | Partiel | Les noms de fichier longs ou non ASCII sont lus ; à l’envoi, FOLD ne les écrit pas encore sous cette forme. |
| RFC 2183 | Content-Disposition | Implémenté | Intégré ou en pièce jointe, et le nom du fichier. |
| RFC 2387 | multipart/related | Implémenté | Messages avec images intégrées, lus et écrits. |
| RFC 2392 | Content-ID and Message-ID URLs | Implémenté | Les liens cid: vers les images intégrées sont résolus à l’intérieur du message. |
| RFC 6532 | Internationalized Email Headers | Implémenté | Les en-têtes UTF-8 sont toujours lus ; FOLD ne les écrit que pour les adresses internationales, et seulement si le serveur propose SMTPUTF8 ou UTF8=ACCEPT.depuis le 2026-09-21 |
| RFC 3676 | The Text/Plain Format and DelSp Parameters | Pas encore | Le texte format=flowed n’est pas encore recomposé, et FOLD ne l’envoie pas. |
| RFC 2369 | List Commands in Header Fields | Implémenté | List-Unsubscribe comme action : FOLD envoie lui-même la demande par e-mail, les liens web s’ouvrent dans le navigateur. |
| RFC 2919 | List-Id | Implémenté | Reconnaît les listes de diffusion, pour que leurs ruptures de signature typiques ne soient pas présentées comme des falsifications. |
| RFC 8058 | One-Click Unsubscribe | Pas encore | L’en-tête est reconnu, mais FOLD n’envoie pas la requête en un clic ; le désabonnement passe par un e-mail ou par la page web. |
| RFC 8098 | Message Disposition Notification | Partiel | FOLD peut demander un accusé de lecture à l’envoi, mais n’en envoie délibérément jamais. |
Lecture et synchronisation (IMAP)
FOLD demande au serveur ce qu’il prend en charge, puis le redemande après la connexion, et n’active chaque extension que si le serveur l’annonce, avec un repli sur la voie plus simple.
| RFC | Norme | Statut | Dans FOLD |
|---|---|---|---|
| RFC 3501 | IMAP4rev1 | Implémenté | La base que tout serveur prend en charge, y compris STARTTLS sans repli en clair. |
| RFC 9051 | IMAP4rev2 | Écarté | Reconnu, non activé : aucun serveur du périmètre visé ne l’exige ; FOLD utilise à la place les extensions de rev1. |
| RFC 2177 | IDLE | Implémenté | FOLD maintient IDLE sur la boîte de réception de chaque compte et le renouvelle toutes les 25 minutes ; les autres dossiers sont interrogés périodiquement, sur iPhone et iPad uniquement tant que l’app est ouverte. |
| RFC 4315 | UIDPLUS | Implémenté | UID EXPUNGE, pour que FOLD ne supprime jamais que ses propres messages. |
| RFC 6851 | MOVE | Implémenté | Avec COPY et EXPUNGE en repli ; après un MOVE, FOLD vérifie ce qui est resté dans la source. |
| RFC 7162 | CONDSTORE and QRESYNC | Implémenté | Synchronisation incrémentale, y compris VANISHED (EARLIER). |
| RFC 5161 | ENABLE | Implémenté | Une activation ne compte qu’une fois confirmée par le serveur avec ENABLED. |
| RFC 6154 | SPECIAL-USE | Implémenté | Les rôles des dossiers viennent des marqueurs du serveur, les noms courants ne servent que de repli, et les dossiers manquants sont créés avec leur rôle. |
| RFC 9208 | QUOTA | Implémenté | L’espace occupé dans la boîte aux lettres est affiché sur le Mac. |
| RFC 7888 | LITERAL+ and LITERAL- | Implémenté | Moins d’allers-retours lors du chargement sur le serveur. |
| RFC 4959 | SASL-IR | Implémenté | Connexion en un seul aller-retour. |
| RFC 5530 | IMAP Response Codes | Implémenté | FOLD distingue un mot de passe erroné d’un serveur momentanément indisponible. |
| RFC 4731 | ESEARCH | Implémenté | Résultats compacts pour la recherche sur le serveur sur iPhone et iPad ; les serveurs sans ESEARCH reçoivent le SEARCH classique.depuis le 2026-09-21 |
| RFC 5258 | LIST-EXTENDED | Implémenté | Les dossiers et leurs rôles en une seule commande.depuis le 2026-09-21 |
| RFC 5819 | LIST-STATUS | Implémenté | Compteurs des dossiers dans le même LIST, sans sélectionner chaque dossier.depuis le 2026-09-21 |
| RFC 6855 | UTF8=ACCEPT | Implémenté | Noms de dossiers et en-têtes en UTF-8 ; l’encodage des noms de dossiers est basculé en un seul endroit.depuis le 2026-09-21 |
| RFC 2342 | NAMESPACE | Pas encore | La capacité est reconnue, mais la commande n’est jamais envoyée. |
| RFC 2971 | ID | Pas encore | Certains serveurs Yahoo le demandent avant la connexion. |
| RFC 4978 | COMPRESS=DEFLATE | Pas encore | Reporté : il faut un vidage partiel (partial flush), absent du framework Compression d’Apple ; la voie prévue est zlib en direct. |
| RFC 8474 | OBJECTID | Pas encore | Identifiants stables malgré les renommages ; pas encore utilisé. |
| RFC 8970 | PREVIEW | Pas encore | Les aperçus sont générés sur l’appareil à partir du message chargé. |
| RFC 8508 | REPLACE | Pas encore | Les brouillons sont enregistrés sur l’appareil pendant la rédaction et envoyés une seule fois au serveur à la fermeture de l’éditeur ; une copie antérieure sur le serveur n’est pas remplacée. |
| RFC 3516 | BINARY | Écarté | Inutile : FOLD décode lui-même l’arbre MIME. |
| RFC 5256 | SORT and THREAD | Écarté | FOLD construit les conversations localement à partir de References et In-Reply-To, de la même façon sur chaque serveur. |
| RFC 5465 | NOTIFY | Écarté | Presque aucun serveur du périmètre visé ne le propose. |
Envoi (SMTP)
Comment FOLD remet un message à votre serveur.
| RFC | Norme | Statut | Dans FOLD |
|---|---|---|---|
| RFC 5321 | Simple Mail Transfer Protocol | Implémenté | Y compris un dot-stuffing correct. |
| RFC 6409 | Message Submission for Mail | Implémenté | Toujours avec authentification avant l’envoi, sur le port 587 ou 465. |
| RFC 4954 | SMTP Service Extension for Authentication | Implémenté | Authentification avec réponse initiale, et abandon propre quand une méthode échoue. |
| RFC 1870 | SIZE | Implémenté | La taille est annoncée quand le serveur indique une limite, et un message qui la dépasse est refusé avant l’envoi. |
| RFC 2920 | PIPELINING | Implémenté | Expéditeur et destinataires par groupes ; DATA seulement après toutes les réponses sur l’enveloppe, pour qu’un message parte vers tous les destinataires ou vers aucun.depuis le 2026-09-21 |
| RFC 6152 | 8BITMIME | Implémenté | Déclaré quand le message contient des données 8 bits ; sans prise en charge par le serveur, FOLD n’envoie pas de 8 bits.depuis le 2026-09-21 |
| RFC 6531 | SMTPUTF8 | Implémenté | Adresses internationales et en-têtes UTF-8 ; si le serveur ne le prend pas en charge, FOLD s’arrête avec un message clair.depuis le 2026-09-21 |
| RFC 3463 | Enhanced Mail System Status Codes | Implémenté | Les refus sont expliqués en termes clairs plutôt que par un code serveur (avec la RFC 2034).depuis le 2026-09-21 |
| RFC 3461 | Delivery Status Notifications | Pas encore | Les rapports de remise sur demande ne sont pas implémentés. |
| RFC 3030 | CHUNKING (BDAT) | Écarté | Reconnu, non utilisé ; DATA couvre tous les cas. |
| RFC 8689 | REQUIRETLS | Écarté | Presque aucun serveur ne le prend encore en charge. |
Connexion et authentification
Chiffrement de la connexion, méthodes d’authentification et configuration automatique.
| RFC | Norme | Statut | Dans FOLD |
|---|---|---|---|
| RFC 8314 | Cleartext Considered Obsolete | Implémenté | FOLD ne se connecte jamais sans TLS et préfère TLS implicite quand le DNS propose les deux. |
| RFC 3207 | SMTP over TLS (STARTTLS) | Implémenté | Si le serveur ne propose pas STARTTLS, FOLD s’arrête au lieu d’envoyer en clair. |
| RFC 7817 | TLS Server Identity Check for Email | Implémenté | La chaîne de certificats et le nom d’hôte sont vérifiés par le système par rapport au serveur configuré. |
| RFC 4422 | SASL | Implémenté | Cadre de toutes les méthodes de connexion ci-dessous. |
| RFC 7677 | SCRAM-SHA-256 | Partiel | Préféré pour l’envoi (SMTP), avec vérification de la signature du serveur ; la connexion IMAP utilise encore PLAIN. |
| RFC 4616 | PLAIN | Implémenté | Uniquement à l’intérieur de TLS, jamais en clair (délibérément plus strict que la RFC). |
| RFC 6749 | OAuth 2.0 | Implémenté | Connexion avec Google ; XOAUTH2 pour IMAP et SMTP, la méthode qu’utilisent les grands fournisseurs. |
| RFC 7636 | PKCE | Implémenté | Pour chaque connexion OAuth, uniquement S256 ; aucun secret client dans l’app. |
| RFC 8252 | OAuth 2.0 for Native Apps | Implémenté | Connexion dans le navigateur du système, jamais dans une vue web intégrée. |
| RFC 7628 | OAUTHBEARER | Pas encore | Aucun fournisseur du périmètre visé ne l’exige ; XOAUTH2 les couvre. |
| RFC 6186 | SRV Records for Email Submission and Access | Implémenté | L’une des sources de la configuration automatique. |
Chiffrement et signatures
S/MIME et OpenPGP, et les briques sur lesquelles ils reposent.
| RFC | Norme | Statut | Dans FOLD |
|---|---|---|---|
| RFC 5652 | Cryptographic Message Syntax | Implémenté | Le format conteneur de S/MIME : implémentation propre sur iPhone et iPad, celle du système sur le Mac. |
| RFC 8551 | S/MIME 4.0 | Partiel | Signer, vérifier, chiffrer et déchiffrer avec des certificats RSA et AES-CBC ; AES-GCM, qu’exige S/MIME 4.0, n’est pas encore pris en charge. |
| RFC 1847 | Security Multiparts for MIME | Implémenté | L’enveloppe des messages signés et chiffrés. |
| RFC 3565 | AES in CMS | Implémenté | AES pour le chiffrement S/MIME. |
| RFC 5754 | SHA-2 in CMS | Implémenté | SHA-256 et au-delà pour les signatures S/MIME. |
| RFC 5280 | X.509 Certificates | Implémenté | Les chemins de certification sont vérifiés par l’évaluation de confiance du système ; les contrôles de révocation sont facultatifs. |
| RFC 9580 | OpenPGP | Partiel | Clés de version 4 (Ed25519, Curve25519, RSA) avec AES-256 et contrôle d’intégrité, testées face à gpg ; les clés de version 6 et le chiffrement AEAD ne sont pas encore pris en charge. |
| RFC 6637 | Elliptic Curve Cryptography in OpenPGP | Implémenté | Clés de chiffrement Curve25519, le format que FOLD crée et utilise. |
| RFC 3156 | MIME Security with OpenPGP | Implémenté | PGP/MIME pour les messages signés et chiffrés. |
| RFC 3394 | AES Key Wrap | Implémenté | Enveloppe la clé de session pour les destinataires Curve25519. |
| RFC 7253 | OCB Authenticated Encryption | Implémenté | Implémentation propre sur l’AES du système, vérifiée avec les vecteurs de test de la RFC ; sert à lire les messages GnuPG chiffrés en OCB. |
| RFC 9106 | Argon2 | Implémenté | Dérivation de clé du mode Fortress, vérifiée avec le vecteur de test de la RFC. |
| RFC 7693 | BLAKE2 | Implémenté | À l’intérieur d’Argon2, implémentation propre vérifiée face à openssl. |
| RFC 5869 | HKDF | Implémenté | Issu de CryptoKit, pour le mode Fortress. |
Authenticité de l’expéditeur
Comment FOLD vérifie qui a réellement envoyé un message.
| RFC | Norme | Statut | Dans FOLD |
|---|---|---|---|
| RFC 6376 | DKIM Signatures | Implémenté | Vérification sur l’appareil : le hachage du corps et la signature sont recalculés. |
| RFC 8463 | Ed25519 for DKIM | Implémenté | Vérifié avec l’exemple de message de la RFC. |
| RFC 8301 | DKIM Crypto Algorithm Usage | Implémenté | Les clés de moins de 1024 bits et les signatures rsa-sha1 sont rejetées. |
| RFC 8601 | Authentication-Results | Partiel | Seuls les résultats estampillés au nom d’hôte IMAP du compte font foi ; les fournisseurs qui utilisent un autre nom, dont Gmail, ne donnent pas encore de résultat. |
| RFC 7489 | DMARC | Partiel | FOLD utilise le résultat DMARC consigné par votre serveur et vérifie lui-même l’alignement ; la politique publiée n’est consultée qu’avant d’afficher un logo de marque. |
| RFC 7208 | SPF | Partiel | SPF a besoin de l’adresse IP d’envoi ; FOLD lit le résultat consigné par votre serveur. |
| BIMI | Brand Indicators for Message Identification (Internet-Draft) | Implémenté | Logo uniquement si DMARC a réussi avec une politique contraignante et un certificat de marque vérifié ; récupéré une fois par message et conservé avec lui. |
| RFC 9399 | Logotypes in X.509 Certificates | Implémenté | Le logo de la marque provient du certificat de marque vérifié. |
Méthode
Comment cette page est tenue à jour
Le statut provient des règles de conformité de FOLD et d’un audit de la pile de messagerie au regard des RFC. Chaque ligne est vérifiée par rapport au code source avant d’apparaître ici, et la page change quand le code change. Au total, le code cite 95 RFC différentes ; cette page montre celles qui déterminent si un client de messagerie fonctionne bien avec de vrais serveurs.