Технологии · Стандарты
Стандарты соблюдены.Пробелы названы.
Каждый протокол, на котором работает FOLD, определён в RFC. На этой странице перечислены те, по которым оценивают почтовый клиент, и для каждого сказано, что код делает сегодня: реализовано, реализовано частично, пока нет или сознательно не реализовано, и почему.
Сверено с кодом 2026-09-23
- Реализовано
- 58
- Реализовано и используется.
- Частично
- 8
- Часть работает; в примечании сказано, какая.
- Пока нет
- 10
- Пока не реализовано.
- Сознательно нет
- 6
- Сознательно не реализовано; причина указана в примечании.
Формат письма
Как письмо составляется, читается и отображается.
| RFC | Стандарт | Статус | В FOLD |
|---|---|---|---|
| RFC 5322 | Internet Message Format | Реализовано | Строго при записи; при чтении допускаются одиночные переводы строки (LF), 8-битные заголовки и варианты формата даты. |
| RFC 2045-2049 | MIME | Реализовано | FOLD загружает письмо целиком и строит дерево MIME на устройстве. |
| RFC 2047 | MIME Encoded-Words | Реализовано | Текст вне ASCII в заголовках, декодирование и кодирование. |
| RFC 2231 | MIME Parameter Value and Encoded Word Extensions | Частично | Длинные имена файлов и имена вне ASCII читаются; при отправке FOLD пока не записывает их в этой форме. |
| RFC 2183 | Content-Disposition | Реализовано | Встроенное содержимое или вложение, а также имя файла. |
| RFC 2387 | multipart/related | Реализовано | Письма со встроенными изображениями, чтение и запись. |
| RFC 2392 | Content-ID and Message-ID URLs | Реализовано | Ссылки cid: на встроенные изображения разрешаются внутри письма. |
| RFC 6532 | Internationalized Email Headers | Реализовано | Заголовки в UTF-8 читаются всегда; FOLD записывает их только для международных адресов и только если сервер предлагает SMTPUTF8 или UTF8=ACCEPT.с 2026-09-21 |
| RFC 3676 | The Text/Plain Format and DelSp Parameters | Пока нет | Текст format=flowed пока не переформатируется, и FOLD его не отправляет. |
| RFC 2369 | List Commands in Header Fields | Реализовано | List-Unsubscribe как действие: FOLD сам отправляет письмо с запросом, веб-ссылки открываются в браузере. |
| RFC 2919 | List-Id | Реализовано | Распознаёт списки рассылки, чтобы типичные для них нарушения подписи не показывались как подделка. |
| RFC 8058 | One-Click Unsubscribe | Пока нет | Заголовок распознаётся, но FOLD не отправляет запрос отписки в один клик; отписка идёт по почте или через веб-страницу. |
| RFC 8098 | Message Disposition Notification | Частично | При отправке FOLD может запросить уведомление о прочтении, но сам намеренно никогда его не отправляет. |
Чтение и синхронизация (IMAP)
FOLD спрашивает сервер, что тот поддерживает, и ещё раз после входа, а каждое расширение включает, только если сервер его объявляет; иначе используется более простой способ.
| RFC | Стандарт | Статус | В FOLD |
|---|---|---|---|
| RFC 3501 | IMAP4rev1 | Реализовано | Базовый уровень, который поддерживает любой сервер, включая STARTTLS без отката на открытый текст. |
| RFC 9051 | IMAP4rev2 | Сознательно нет | Распознаётся, но не включается: ни один сервер из целевой группы его не требует; вместо него FOLD использует расширения rev1. |
| RFC 2177 | IDLE | Реализовано | FOLD держит IDLE на папке «Входящие» каждой учётной записи и обновляет его каждые 25 минут; остальные папки опрашиваются, на iPhone и iPad только пока приложение открыто. |
| RFC 4315 | UIDPLUS | Реализовано | UID EXPUNGE, чтобы FOLD удалял только собственные письма. |
| RFC 6851 | MOVE | Реализовано | С COPY и EXPUNGE как запасным путём; после MOVE FOLD проверяет, что осталось в исходной папке. |
| RFC 7162 | CONDSTORE and QRESYNC | Реализовано | Инкрементальная синхронизация, включая VANISHED (EARLIER). |
| RFC 5161 | ENABLE | Реализовано | Расширение считается включённым, только когда сервер подтвердит это ответом ENABLED. |
| RFC 6154 | SPECIAL-USE | Реализовано | Роли папок берутся из меток сервера, привычные имена служат лишь запасным вариантом, недостающие папки создаются с нужной ролью. |
| RFC 9208 | QUOTA | Реализовано | Заполненность почтового ящика показывается на Mac. |
| RFC 7888 | LITERAL+ and LITERAL- | Реализовано | Меньше обменов запрос-ответ при загрузке на сервер. |
| RFC 4959 | SASL-IR | Реализовано | Вход за один обмен запрос-ответ. |
| RFC 5530 | IMAP Response Codes | Реализовано | Неверный пароль и временно недоступный сервер различаются. |
| RFC 4731 | ESEARCH | Реализовано | Компактные результаты серверного поиска на iPhone и iPad; серверы без ESEARCH получают классический SEARCH.с 2026-09-21 |
| RFC 5258 | LIST-EXTENDED | Реализовано | Папки и их роли одной командой.с 2026-09-21 |
| RFC 5819 | LIST-STATUS | Реализовано | Счётчики папок в том же LIST, без выбора каждой папки.с 2026-09-21 |
| RFC 6855 | UTF8=ACCEPT | Реализовано | Имена папок и заголовки в UTF-8; кодировка имён папок переключается в одном месте.с 2026-09-21 |
| RFC 2342 | NAMESPACE | Пока нет | Поддержка на сервере распознаётся, но сама команда никогда не отправляется. |
| RFC 2971 | ID | Пока нет | Некоторые серверы Yahoo требуют ID до входа. |
| RFC 4978 | COMPRESS=DEFLATE | Пока нет | Отложено: нужен частичный сброс (partial flush), которого нет во фреймворке Compression от Apple; планируется использовать zlib напрямую. |
| RFC 8474 | OBJECTID | Пока нет | Стабильные идентификаторы, не меняющиеся при переименовании; пока не используются. |
| RFC 8970 | PREVIEW | Пока нет | Предпросмотр формируется на устройстве из загруженного письма. |
| RFC 8508 | REPLACE | Пока нет | Черновики сохраняются на устройстве во время написания и выгружаются один раз при закрытии окна письма; более ранняя копия на сервере не заменяется. |
| RFC 3516 | BINARY | Сознательно нет | Не нужно: FOLD сам декодирует дерево MIME. |
| RFC 5256 | SORT and THREAD | Сознательно нет | FOLD строит разговоры локально по References и In-Reply-To, одинаково на любом сервере. |
| RFC 5465 | NOTIFY | Сознательно нет | Почти ни один сервер из целевой группы его не предлагает. |
Отправка (SMTP)
Как FOLD передаёт письмо вашему серверу.
| RFC | Стандарт | Статус | В FOLD |
|---|---|---|---|
| RFC 5321 | Simple Mail Transfer Protocol | Реализовано | Включая корректное удвоение точек (dot-stuffing). |
| RFC 6409 | Message Submission for Mail | Реализовано | Всегда со входом перед отправкой, на порту 587 или 465. |
| RFC 4954 | SMTP Service Extension for Authentication | Реализовано | Вход с начальным ответом (initial response) и корректное прерывание, если способ входа не сработал. |
| RFC 1870 | SIZE | Реализовано | Размер объявляется, если сервер называет лимит, а письмо сверх лимита отклоняется до загрузки. |
| RFC 2920 | PIPELINING | Реализовано | Отправитель и получатели группами; DATA только после всех ответов на конверт, так что письмо уходит либо всем получателям, либо никому.с 2026-09-21 |
| RFC 6152 | 8BITMIME | Реализовано | Объявляется, если письмо содержит 8-битные данные; без поддержки на сервере FOLD 8-битные данные не отправляет.с 2026-09-21 |
| RFC 6531 | SMTPUTF8 | Реализовано | Международные адреса и заголовки в UTF-8; если сервер этого не поддерживает, FOLD останавливается с понятным сообщением.с 2026-09-21 |
| RFC 3463 | Enhanced Mail System Status Codes | Реализовано | Отказы объясняются простыми словами, а не кодом сервера (вместе с RFC 2034).с 2026-09-21 |
| RFC 3461 | Delivery Status Notifications | Пока нет | Отчёты о доставке по запросу не реализованы. |
| RFC 3030 | CHUNKING (BDAT) | Сознательно нет | Распознаётся, но не используется; DATA покрывает все случаи. |
| RFC 8689 | REQUIRETLS | Сознательно нет | Почти ни один сервер его пока не поддерживает. |
Соединение и вход
Шифрование соединения, способы входа и автоматическая настройка.
| RFC | Стандарт | Статус | В FOLD |
|---|---|---|---|
| RFC 8314 | Cleartext Considered Obsolete | Реализовано | FOLD никогда не подключается без TLS и предпочитает неявный TLS, если DNS предлагает оба варианта. |
| RFC 3207 | SMTP over TLS (STARTTLS) | Реализовано | Если сервер не предлагает STARTTLS, FOLD останавливается, а не отправляет открытым текстом. |
| RFC 7817 | TLS Server Identity Check for Email | Реализовано | Цепочку сертификатов и имя хоста система проверяет по настроенному серверу. |
| RFC 4422 | SASL | Реализовано | Основа для всех перечисленных ниже способов входа. |
| RFC 7677 | SCRAM-SHA-256 | Частично | Предпочитается при отправке (SMTP), с проверкой подписи сервера; для входа по IMAP пока используется PLAIN. |
| RFC 4616 | PLAIN | Реализовано | Только внутри TLS, никогда открытым текстом (намеренно строже, чем RFC). |
| RFC 6749 | OAuth 2.0 | Реализовано | Вход через Google; XOAUTH2 для IMAP и SMTP, способ, который используют крупные провайдеры. |
| RFC 7636 | PKCE | Реализовано | При каждом входе через OAuth, только S256; в приложении нет клиентского секрета. |
| RFC 8252 | OAuth 2.0 for Native Apps | Реализовано | Вход в системном браузере, никогда во встроенном веб-представлении. |
| RFC 7628 | OAUTHBEARER | Пока нет | Ни один провайдер из целевой группы его не требует; их покрывает XOAUTH2. |
| RFC 6186 | SRV Records for Email Submission and Access | Реализовано | Один из источников для автоматической настройки. |
Шифрование и подписи
S/MIME и OpenPGP, а также компоненты, на которых они построены.
| RFC | Стандарт | Статус | В FOLD |
|---|---|---|---|
| RFC 5652 | Cryptographic Message Syntax | Реализовано | Формат контейнера S/MIME: на iPhone и iPad собственная реализация, на Mac системная. |
| RFC 8551 | S/MIME 4.0 | Частично | Подпись, проверка, шифрование и расшифровка с сертификатами RSA и AES-CBC; AES-GCM, которого требует S/MIME 4.0, пока не поддерживается. |
| RFC 1847 | Security Multiparts for MIME | Реализовано | Оболочка подписанных и зашифрованных писем. |
| RFC 3565 | AES in CMS | Реализовано | AES для шифрования S/MIME. |
| RFC 5754 | SHA-2 in CMS | Реализовано | SHA-256 и более стойкие хеши для подписей S/MIME. |
| RFC 5280 | X.509 Certificates | Реализовано | Пути сертификации проверяет системная оценка доверия; проверки отзыва необязательны. |
| RFC 9580 | OpenPGP | Частично | Ключи версии 4 (Ed25519, Curve25519, RSA) с AES-256 и проверкой целостности, протестировано на gpg; ключи версии 6 и шифрование AEAD пока не поддерживаются. |
| RFC 6637 | Elliptic Curve Cryptography in OpenPGP | Реализовано | Ключи шифрования Curve25519, формат, который FOLD создаёт и использует. |
| RFC 3156 | MIME Security with OpenPGP | Реализовано | PGP/MIME для подписанных и зашифрованных писем. |
| RFC 3394 | AES Key Wrap | Реализовано | Упаковывает сеансовый ключ для получателей с Curve25519. |
| RFC 7253 | OCB Authenticated Encryption | Реализовано | Собственная реализация поверх системного AES, проверена по тестовым векторам RFC; используется для чтения писем из GnuPG, зашифрованных в режиме OCB. |
| RFC 9106 | Argon2 | Реализовано | Вывод ключа в режиме Fortress, проверен по тестовому вектору RFC. |
| RFC 7693 | BLAKE2 | Реализовано | Внутри Argon2, собственная реализация, проверена на openssl. |
| RFC 5869 | HKDF | Реализовано | Из CryptoKit, для режима Fortress. |
Подлинность отправителя
Как FOLD проверяет, кто на самом деле отправил письмо.
| RFC | Стандарт | Статус | В FOLD |
|---|---|---|---|
| RFC 6376 | DKIM Signatures | Реализовано | Проверяется на устройстве: хеш тела и подпись вычисляются заново. |
| RFC 8463 | Ed25519 for DKIM | Реализовано | Проверено на примере письма из RFC. |
| RFC 8301 | DKIM Crypto Algorithm Usage | Реализовано | Ключи короче 1024 бит и подписи rsa-sha1 отклоняются. |
| RFC 8601 | Authentication-Results | Частично | Доверие получают только результаты, проставленные под IMAP-именем хоста учётной записи; провайдеры, которые используют другое имя, в том числе Gmail, пока не дают результата. |
| RFC 7489 | DMARC | Частично | FOLD использует результат DMARC, записанный вашим сервером, и сам проверяет выравнивание доменов; опубликованная политика запрашивается только перед показом логотипа бренда. |
| RFC 7208 | SPF | Частично | Для SPF нужен IP-адрес отправителя; FOLD читает результат, записанный вашим сервером. |
| BIMI | Brand Indicators for Message Identification (Internet-Draft) | Реализовано | Логотип только после пройденной проверки DMARC при политике с применением мер и с проверенным сертификатом товарного знака; загружается один раз на письмо и хранится вместе с ним. |
| RFC 9399 | Logotypes in X.509 Certificates | Реализовано | Логотип бренда берётся из проверенного сертификата товарного знака. |
Методика
Как ведётся эта страница
Статус берётся из правил соответствия FOLD и аудита почтового стека на соответствие RFC. Каждая строка сверяется с исходным кодом, прежде чем появиться здесь, и страница меняется вместе с кодом. Всего код ссылается на 95 различных RFC; на этой странице показаны те, от которых зависит, насколько хорошо почтовый клиент работает с реальными серверами.