2023-09-11 12:26:40 +03:00
This file lists RFC's by number and title. "make" fetches the RFC's and adds
references back to the source code where they are referenced. Not all RFC's in
this list have been implemented yet.
2023-01-30 16:27:06 +03:00
Also see IANA assignments, https://www.iana.org/protocols
# Mail, message format, MIME
822 Standard for ARPA Internet Text Messages
add webmail
it was far down on the roadmap, but implemented earlier, because it's
interesting, and to help prepare for a jmap implementation. for jmap we need to
implement more client-like functionality than with just imap. internal data
structures need to change. jmap has lots of other requirements, so it's already
a big project. by implementing a webmail now, some of the required data
structure changes become clear and can be made now, so the later jmap
implementation can do things similarly to the webmail code. the webmail
frontend and webmail are written together, making their interface/api much
smaller and simpler than jmap.
one of the internal changes is that we now keep track of per-mailbox
total/unread/unseen/deleted message counts and mailbox sizes. keeping this
data consistent after any change to the stored messages (through the code base)
is tricky, so mox now has a consistency check that verifies the counts are
correct, which runs only during tests, each time an internal account reference
is closed. we have a few more internal "changes" that are propagated for the
webmail frontend (that imap doesn't have a way to propagate on a connection),
like changes to the special-use flags on mailboxes, and used keywords in a
mailbox. more changes that will be required have revealed themselves while
implementing the webmail, and will be implemented next.
the webmail user interface is modeled after the mail clients i use or have
used: thunderbird, macos mail, mutt; and webmails i normally only use for
testing: gmail, proton, yahoo, outlook. a somewhat technical user is assumed,
but still the goal is to make this webmail client easy to use for everyone. the
user interface looks like most other mail clients: a list of mailboxes, a
search bar, a message list view, and message details. there is a top/bottom and
a left/right layout for the list/message view, default is automatic based on
screen size. the panes can be resized by the user. buttons for actions are just
text, not icons. clicking a button briefly shows the shortcut for the action in
the bottom right, helping with learning to operate quickly. any text that is
underdotted has a title attribute that causes more information to be displayed,
e.g. what a button does or a field is about. to highlight potential phishing
attempts, any text (anywhere in the webclient) that switches unicode "blocks"
(a rough approximation to (language) scripts) within a word is underlined
orange. multiple messages can be selected with familiar ui interaction:
clicking while holding control and/or shift keys. keyboard navigation works
with arrows/page up/down and home/end keys, and also with a few basic vi-like
keys for list/message navigation. we prefer showing the text instead of
html (with inlined images only) version of a message. html messages are shown
in an iframe served from an endpoint with CSP headers to prevent dangerous
resources (scripts, external images) from being loaded. the html is also
sanitized, with javascript removed. a user can choose to load external
resources (e.g. images for tracking purposes).
the frontend is just (strict) typescript, no external frameworks. all
incoming/outgoing data is typechecked, both the api request parameters and
response types, and the data coming in over SSE. the types and checking code
are generated with sherpats, which uses the api definitions generated by
sherpadoc based on the Go code. so types from the backend are automatically
propagated to the frontend. since there is no framework to automatically
propagate properties and rerender components, changes coming in over the SSE
connection are propagated explicitly with regular function calls. the ui is
separated into "views", each with a "root" dom element that is added to the
visible document. these views have additional functions for getting changes
propagated, often resulting in the view updating its (internal) ui state (dom).
we keep the frontend compilation simple, it's just a few typescript files that
get compiled (combined and types stripped) into a single js file, no additional
runtime code needed or complicated build processes used. the webmail is served
is served from a compressed, cachable html file that includes style and the
javascript, currently just over 225kb uncompressed, under 60kb compressed (not
minified, including comments). we include the generated js files in the
repository, to keep Go's easily buildable self-contained binaries.
authentication is basic http, as with the account and admin pages. most data
comes in over one long-term SSE connection to the backend. api requests signal
which mailbox/search/messages are requested over the SSE connection. fetching
individual messages, and making changes, are done through api calls. the
operations are similar to imap, so some code has been moved from package
imapserver to package store. the future jmap implementation will benefit from
these changes too. more functionality will probably be moved to the store
package in the future.
the quickstart enables webmail on the internal listener by default (for new
installs). users can enable it on the public listener if they want to. mox
localserve enables it too. to enable webmail on existing installs, add settings
like the following to the listeners in mox.conf, similar to AccountHTTP(S):
WebmailHTTP:
Enabled: true
WebmailHTTPS:
Enabled: true
special thanks to liesbeth, gerben, andrii for early user feedback.
there is plenty still to do, see the list at the top of webmail/webmail.ts.
feedback welcome as always.
2023-08-07 22:57:03 +03:00
1847 Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted
2023-01-30 16:27:06 +03:00
2045 Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies
2046 Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types
2047 MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text
2049 Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples
add webmail
it was far down on the roadmap, but implemented earlier, because it's
interesting, and to help prepare for a jmap implementation. for jmap we need to
implement more client-like functionality than with just imap. internal data
structures need to change. jmap has lots of other requirements, so it's already
a big project. by implementing a webmail now, some of the required data
structure changes become clear and can be made now, so the later jmap
implementation can do things similarly to the webmail code. the webmail
frontend and webmail are written together, making their interface/api much
smaller and simpler than jmap.
one of the internal changes is that we now keep track of per-mailbox
total/unread/unseen/deleted message counts and mailbox sizes. keeping this
data consistent after any change to the stored messages (through the code base)
is tricky, so mox now has a consistency check that verifies the counts are
correct, which runs only during tests, each time an internal account reference
is closed. we have a few more internal "changes" that are propagated for the
webmail frontend (that imap doesn't have a way to propagate on a connection),
like changes to the special-use flags on mailboxes, and used keywords in a
mailbox. more changes that will be required have revealed themselves while
implementing the webmail, and will be implemented next.
the webmail user interface is modeled after the mail clients i use or have
used: thunderbird, macos mail, mutt; and webmails i normally only use for
testing: gmail, proton, yahoo, outlook. a somewhat technical user is assumed,
but still the goal is to make this webmail client easy to use for everyone. the
user interface looks like most other mail clients: a list of mailboxes, a
search bar, a message list view, and message details. there is a top/bottom and
a left/right layout for the list/message view, default is automatic based on
screen size. the panes can be resized by the user. buttons for actions are just
text, not icons. clicking a button briefly shows the shortcut for the action in
the bottom right, helping with learning to operate quickly. any text that is
underdotted has a title attribute that causes more information to be displayed,
e.g. what a button does or a field is about. to highlight potential phishing
attempts, any text (anywhere in the webclient) that switches unicode "blocks"
(a rough approximation to (language) scripts) within a word is underlined
orange. multiple messages can be selected with familiar ui interaction:
clicking while holding control and/or shift keys. keyboard navigation works
with arrows/page up/down and home/end keys, and also with a few basic vi-like
keys for list/message navigation. we prefer showing the text instead of
html (with inlined images only) version of a message. html messages are shown
in an iframe served from an endpoint with CSP headers to prevent dangerous
resources (scripts, external images) from being loaded. the html is also
sanitized, with javascript removed. a user can choose to load external
resources (e.g. images for tracking purposes).
the frontend is just (strict) typescript, no external frameworks. all
incoming/outgoing data is typechecked, both the api request parameters and
response types, and the data coming in over SSE. the types and checking code
are generated with sherpats, which uses the api definitions generated by
sherpadoc based on the Go code. so types from the backend are automatically
propagated to the frontend. since there is no framework to automatically
propagate properties and rerender components, changes coming in over the SSE
connection are propagated explicitly with regular function calls. the ui is
separated into "views", each with a "root" dom element that is added to the
visible document. these views have additional functions for getting changes
propagated, often resulting in the view updating its (internal) ui state (dom).
we keep the frontend compilation simple, it's just a few typescript files that
get compiled (combined and types stripped) into a single js file, no additional
runtime code needed or complicated build processes used. the webmail is served
is served from a compressed, cachable html file that includes style and the
javascript, currently just over 225kb uncompressed, under 60kb compressed (not
minified, including comments). we include the generated js files in the
repository, to keep Go's easily buildable self-contained binaries.
authentication is basic http, as with the account and admin pages. most data
comes in over one long-term SSE connection to the backend. api requests signal
which mailbox/search/messages are requested over the SSE connection. fetching
individual messages, and making changes, are done through api calls. the
operations are similar to imap, so some code has been moved from package
imapserver to package store. the future jmap implementation will benefit from
these changes too. more functionality will probably be moved to the store
package in the future.
the quickstart enables webmail on the internal listener by default (for new
installs). users can enable it on the public listener if they want to. mox
localserve enables it too. to enable webmail on existing installs, add settings
like the following to the listeners in mox.conf, similar to AccountHTTP(S):
WebmailHTTP:
Enabled: true
WebmailHTTPS:
Enabled: true
special thanks to liesbeth, gerben, andrii for early user feedback.
there is plenty still to do, see the list at the top of webmail/webmail.ts.
feedback welcome as always.
2023-08-07 22:57:03 +03:00
2183 Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field
2023-01-30 16:27:06 +03:00
2231 MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations
3629 UTF-8, a transformation format of ISO 10646
2023-09-11 12:26:40 +03:00
3676 The Text/Plain Format and DelSp Parameters
2023-01-30 16:27:06 +03:00
3834 Recommendations for Automatic Responses to Electronic Mail
5234 Augmented BNF for Syntax Specifications: ABNF
5322 Internet Message Format
5598 Internet Mail Architecture
2023-03-20 10:52:45 +03:00
6854 Update to Internet Message Format to Allow Group Syntax in the "From:" and "Sender:" Header Fields
2023-01-30 16:27:06 +03:00
7405 Case-Sensitive String Support in ABNF
2023-07-26 20:23:20 +03:00
9228 Delivered-To Email Header Field
2023-01-30 16:27:06 +03:00
add webmail
it was far down on the roadmap, but implemented earlier, because it's
interesting, and to help prepare for a jmap implementation. for jmap we need to
implement more client-like functionality than with just imap. internal data
structures need to change. jmap has lots of other requirements, so it's already
a big project. by implementing a webmail now, some of the required data
structure changes become clear and can be made now, so the later jmap
implementation can do things similarly to the webmail code. the webmail
frontend and webmail are written together, making their interface/api much
smaller and simpler than jmap.
one of the internal changes is that we now keep track of per-mailbox
total/unread/unseen/deleted message counts and mailbox sizes. keeping this
data consistent after any change to the stored messages (through the code base)
is tricky, so mox now has a consistency check that verifies the counts are
correct, which runs only during tests, each time an internal account reference
is closed. we have a few more internal "changes" that are propagated for the
webmail frontend (that imap doesn't have a way to propagate on a connection),
like changes to the special-use flags on mailboxes, and used keywords in a
mailbox. more changes that will be required have revealed themselves while
implementing the webmail, and will be implemented next.
the webmail user interface is modeled after the mail clients i use or have
used: thunderbird, macos mail, mutt; and webmails i normally only use for
testing: gmail, proton, yahoo, outlook. a somewhat technical user is assumed,
but still the goal is to make this webmail client easy to use for everyone. the
user interface looks like most other mail clients: a list of mailboxes, a
search bar, a message list view, and message details. there is a top/bottom and
a left/right layout for the list/message view, default is automatic based on
screen size. the panes can be resized by the user. buttons for actions are just
text, not icons. clicking a button briefly shows the shortcut for the action in
the bottom right, helping with learning to operate quickly. any text that is
underdotted has a title attribute that causes more information to be displayed,
e.g. what a button does or a field is about. to highlight potential phishing
attempts, any text (anywhere in the webclient) that switches unicode "blocks"
(a rough approximation to (language) scripts) within a word is underlined
orange. multiple messages can be selected with familiar ui interaction:
clicking while holding control and/or shift keys. keyboard navigation works
with arrows/page up/down and home/end keys, and also with a few basic vi-like
keys for list/message navigation. we prefer showing the text instead of
html (with inlined images only) version of a message. html messages are shown
in an iframe served from an endpoint with CSP headers to prevent dangerous
resources (scripts, external images) from being loaded. the html is also
sanitized, with javascript removed. a user can choose to load external
resources (e.g. images for tracking purposes).
the frontend is just (strict) typescript, no external frameworks. all
incoming/outgoing data is typechecked, both the api request parameters and
response types, and the data coming in over SSE. the types and checking code
are generated with sherpats, which uses the api definitions generated by
sherpadoc based on the Go code. so types from the backend are automatically
propagated to the frontend. since there is no framework to automatically
propagate properties and rerender components, changes coming in over the SSE
connection are propagated explicitly with regular function calls. the ui is
separated into "views", each with a "root" dom element that is added to the
visible document. these views have additional functions for getting changes
propagated, often resulting in the view updating its (internal) ui state (dom).
we keep the frontend compilation simple, it's just a few typescript files that
get compiled (combined and types stripped) into a single js file, no additional
runtime code needed or complicated build processes used. the webmail is served
is served from a compressed, cachable html file that includes style and the
javascript, currently just over 225kb uncompressed, under 60kb compressed (not
minified, including comments). we include the generated js files in the
repository, to keep Go's easily buildable self-contained binaries.
authentication is basic http, as with the account and admin pages. most data
comes in over one long-term SSE connection to the backend. api requests signal
which mailbox/search/messages are requested over the SSE connection. fetching
individual messages, and making changes, are done through api calls. the
operations are similar to imap, so some code has been moved from package
imapserver to package store. the future jmap implementation will benefit from
these changes too. more functionality will probably be moved to the store
package in the future.
the quickstart enables webmail on the internal listener by default (for new
installs). users can enable it on the public listener if they want to. mox
localserve enables it too. to enable webmail on existing installs, add settings
like the following to the listeners in mox.conf, similar to AccountHTTP(S):
WebmailHTTP:
Enabled: true
WebmailHTTPS:
Enabled: true
special thanks to liesbeth, gerben, andrii for early user feedback.
there is plenty still to do, see the list at the top of webmail/webmail.ts.
feedback welcome as always.
2023-08-07 22:57:03 +03:00
https://www.iana.org/assignments/message-headers/message-headers.xhtml
2023-01-30 16:27:06 +03:00
# SMTP
821 (obsoleted by RFC 2821) SIMPLE MAIL TRANSFER PROTOCOL
2821 (obsoleted by RFC 5321) Simple Mail Transfer Protocol
5321 Simple Mail Transfer Protocol
1870 SMTP Service Extension for Message Size Declaration
1985 SMTP Service Extension for Remote Message Queue Starting
2034 SMTP Service Extension for Returning Enhanced Error Codes
2852 Deliver By SMTP Service Extension
2920 SMTP Service Extension for Command Pipelining
2505 Anti-Spam Recommendations for SMTP MTAs
2852 Deliver By SMTP Service Extension
3207 SMTP Service Extension for Secure SMTP over Transport Layer Security (STARTTLS)
3030 SMTP Service Extensions for Transmission of Large and Binary MIME Messages
3461 Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs)
3462 (obsoleted by RFC 6522) The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages
3463 Enhanced Mail System Status Codes
3464 An Extensible Message Format for Delivery Status Notifications
3798 (obsoleted by RFC 8098) Message Disposition Notification
3848 ESMTP and LMTP Transmission Types Registration
3865 A No Soliciting Simple Mail Transfer Protocol (SMTP) Service Extension
3885 SMTP Service Extension for Message Tracking
3974 SMTP Operational Experience in Mixed IPv4/v6 Environments
4409 (obsoleted by RFC 6409) Message Submission for Mail
2023-09-11 12:26:40 +03:00
4468 Message Submission BURL Extension
2023-01-30 16:27:06 +03:00
4865 SMTP Submission Service Extension for Future Message Release
4954 SMTP Service Extension for Authentication
5068 Email Submission Operations: Access and Accountability Requirements
5248 A Registry for SMTP Enhanced Mail System Status Codes
5335 (obsoleted by RFC 6532) Internationalized Email Headers
5336 (obsoleted by RFC 6531) SMTP Extension for Internationalized Email Addresses
5337 (obsoleted by RFC 6533) Internationalized Delivery Status and Disposition Notifications
6008 Authentication-Results Registration for Differentiating among Cryptographic Results
6152 SMTP Service Extension for 8-bit MIME Transport
6409 Message Submission for Mail
6522 The Multipart/Report Media Type for the Reporting of Mail System Administrative Messages
6530 Overview and Framework for Internationalized Email
6531 SMTP Extension for Internationalized Email
6532 Internationalized Email Headers
6533 Internationalized Delivery Status and Disposition Notifications
6729 Indicating Email Handling States in Trace Fields
2023-02-28 00:34:56 +03:00
6857 Post-Delivery Message Downgrading for Internationalized Email Messages
2023-01-30 16:27:06 +03:00
7293 The Require-Recipient-Valid-Since Header Field and SMTP Service Extension
7372 Email Authentication Status Codes
7435 Opportunistic Security: Some Protection Most of the Time
7504 SMTP 521 and 556 Reply Codes
7505 A "Null MX" No Service Resource Record for Domains That Accept No Mail
8098 Message Disposition Notification
8601 Message Header Field for Indicating Message Authentication Status
8689 SMTP Require TLS Option
# SPF
4408 (obsoleted by RFC 7208) Sender Policy Framework (SPF) for Authorizing Use of Domains in E-Mail, Version 1
6652 Sender Policy Framework (SPF) Authentication Failure Reporting Using the Abuse Reporting Format
7208 Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1
7208-eid5436 errata: header-field FWS
7208-eid6721 errata: corrected smtp example response
7208-eid4751 errata (not verified): ptr mechanism
7208-eid5227 errata (not verified): ptr lookup order
7208-eid6595 errata (not verified): 2 void lookups vs exists
7208-eid6216 errata (not verified): ptr in multiple requirements example from appendix A.4
# DKIM
6376 DomainKeys Identified Mail (DKIM) Signatures
6376-eid4810 errata: q= qp-hdr-value
6376-eid5070 errata: tag-spec
4686 Analysis of Threats Motivating DomainKeys Identified Mail (DKIM)
4871 (obsoleted by RFC 6376) DomainKeys Identified Mail (DKIM) Signatures
5016 Requirements for a DomainKeys Identified Mail (DKIM) Signing Practices Protocol
5585 DomainKeys Identified Mail (DKIM) Service Overview
5672 (obsoleted by RFC 6376) DomainKeys Identified Mail (DKIM) Signatures -- Update
5863 DomainKeys Identified Mail (DKIM) Development, Deployment, and Operations
6377 DomainKeys Identified Mail (DKIM) and Mailing Lists
8032 Edwards-Curve Digital Signature Algorithm (EdDSA)
8301 Cryptographic Algorithm and Key Usage Update to DomainKeys Identified Mail (DKIM)
8463 A New Cryptographic Signature Method for DomainKeys Identified Mail (DKIM)
# DMARC
7489 Domain-based Message Authentication, Reporting, and Conformance (DMARC)
7489-eid5440 errata: valid dmarc records with(out) semicolon
7489-eid6729 errata (not verified): publicsuffix list only for ICANN DOMAINS
7960 Interoperability Issues between Domain-based Message Authentication, Reporting, and Conformance (DMARC) and Indirect Email Flows
9091 Experimental Domain-Based Message Authentication, Reporting, and Conformance (DMARC) Extension for Public Suffix Domains
# DKIM/SPF/DMARC
8616 Email Authentication for Internationalized Mail
# Greylisting
6647 Email Greylisting: An Applicability Statement for SMTP
# DNSBL/DNSWL
5782 DNS Blacklists and Whitelists
8904 DNS Whitelist (DNSWL) Email Authentication Method Extension
# DANE
implement dnssec-awareness throughout code, and dane for incoming/outgoing mail delivery
the vendored dns resolver code is a copy of the go stdlib dns resolver, with
awareness of the "authentic data" (i.e. dnssec secure) added, as well as support
for enhanced dns errors, and looking up tlsa records (for dane). ideally it
would be upstreamed, but the chances seem slim.
dnssec-awareness is added to all packages, e.g. spf, dkim, dmarc, iprev. their
dnssec status is added to the Received message headers for incoming email.
but the main reason to add dnssec was for implementing dane. with dane, the
verification of tls certificates can be done through certificates/public keys
published in dns (in the tlsa records). this only makes sense (is trustworthy)
if those dns records can be verified to be authentic.
mox now applies dane to delivering messages over smtp. mox already implemented
mta-sts for webpki/pkix-verification of certificates against the (large) pool
of CA's, and still enforces those policies when present. but it now also checks
for dane records, and will verify those if present. if dane and mta-sts are
both absent, the regular opportunistic tls with starttls is still done. and the
fallback to plaintext is also still done.
mox also makes it easy to setup dane for incoming deliveries, so other servers
can deliver with dane tls certificate verification. the quickstart now
generates private keys that are used when requesting certificates with acme.
the private keys are pre-generated because they must be static and known during
setup, because their public keys must be published in tlsa records in dns.
autocert would generate private keys on its own, so had to be forked to add the
option to provide the private key when requesting a new certificate. hopefully
upstream will accept the change and we can drop the fork.
with this change, using the quickstart to setup a new mox instance, the checks
at internet.nl result in a 100% score, provided the domain is dnssec-signed and
the network doesn't have any issues.
2023-10-10 13:09:35 +03:00
6394 Use Cases and Requirements for DNS-Based Authentication of Named Entities (DANE)
2023-01-30 16:27:06 +03:00
6698 The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA
7218 Adding Acronyms to Simplify Conversations about DNS-Based Authentication of Named Entities (DANE)
7671 The DNS-Based Authentication of Named Entities (DANE) Protocol: Updates and Operational Guidance
7672 SMTP Security via Opportunistic DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS)
implement dnssec-awareness throughout code, and dane for incoming/outgoing mail delivery
the vendored dns resolver code is a copy of the go stdlib dns resolver, with
awareness of the "authentic data" (i.e. dnssec secure) added, as well as support
for enhanced dns errors, and looking up tlsa records (for dane). ideally it
would be upstreamed, but the chances seem slim.
dnssec-awareness is added to all packages, e.g. spf, dkim, dmarc, iprev. their
dnssec status is added to the Received message headers for incoming email.
but the main reason to add dnssec was for implementing dane. with dane, the
verification of tls certificates can be done through certificates/public keys
published in dns (in the tlsa records). this only makes sense (is trustworthy)
if those dns records can be verified to be authentic.
mox now applies dane to delivering messages over smtp. mox already implemented
mta-sts for webpki/pkix-verification of certificates against the (large) pool
of CA's, and still enforces those policies when present. but it now also checks
for dane records, and will verify those if present. if dane and mta-sts are
both absent, the regular opportunistic tls with starttls is still done. and the
fallback to plaintext is also still done.
mox also makes it easy to setup dane for incoming deliveries, so other servers
can deliver with dane tls certificate verification. the quickstart now
generates private keys that are used when requesting certificates with acme.
the private keys are pre-generated because they must be static and known during
setup, because their public keys must be published in tlsa records in dns.
autocert would generate private keys on its own, so had to be forked to add the
option to provide the private key when requesting a new certificate. hopefully
upstream will accept the change and we can drop the fork.
with this change, using the quickstart to setup a new mox instance, the checks
at internet.nl result in a 100% score, provided the domain is dnssec-signed and
the network doesn't have any issues.
2023-10-10 13:09:35 +03:00
7673 Using DNS-Based Authentication of Named Entities (DANE) TLSA Records with SRV Records
7929 DNS-Based Authentication of Named Entities (DANE) Bindings for OpenPGP
8162 Using Secure DNS to Associate Certificates with Domain Names for S/MIME
2023-01-30 16:27:06 +03:00
# TLS-RPT
8460 SMTP TLS Reporting
8460-eid6241 Wrong example for JSON field "mx-host".
# MTA-STS
8461 SMTP MTA Strict Transport Security (MTA-STS)
# ARC
8617 The Authenticated Received Chain (ARC) Protocol
# ARF
5965 An Extensible Format for Email Feedback Reports
6650 Creation and Use of Email Feedback Reports: An Applicability Statement for the Abuse Reporting Format (ARF)
6591 Authentication Failure Reporting Using the Abuse Reporting Format
6692 Source Ports in Abuse Reporting Format (ARF) Reports
# IMAP
1730 (obsoleted by RFC 2060) INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4
2060 (obsoleted by RFC 3501) INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1
3501 (obsoleted by RFC 9051) INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1
9051 Internet Message Access Protocol (IMAP) - Version 4rev2
1733 DISTRIBUTED ELECTRONIC MAIL MODELS IN IMAP4
2087 IMAP4 QUOTA extension
2088 (obsoleted by RFC 7888) IMAP4 non-synchronizing literals
2152 UTF-7 A Mail-Safe Transformation Format of Unicode
2177 IMAP4 IDLE command
2180 IMAP4 Multi-Accessed Mailbox Practice
2193 IMAP4 Mailbox Referrals
2342 IMAP4 Namespace
2683 IMAP4 Implementation Recommendations
2971 IMAP4 ID extension
3348 (obsoleted by RFC 5258) The Internet Message Action Protocol (IMAP4) Child Mailbox Extension
3502 Internet Message Access Protocol (IMAP) - MULTIAPPEND Extension
3503 Message Disposition Notification (MDN) profile for Internet Message Access Protocol (IMAP)
3516 IMAP4 Binary Content Extension
3691 Internet Message Access Protocol (IMAP) UNSELECT command
4314 IMAP4 Access Control List (ACL) Extension
4315 Internet Message Access Protocol (IMAP) - UIDPLUS extension
4466 Collected Extensions to IMAP4 ABNF
4467 Internet Message Access Protocol (IMAP) - URLAUTH Extension
4469 Internet Message Access Protocol (IMAP) CATENATE Extension
4549 Synchronization Operations for Disconnected IMAP4 Clients
4551 (obsoleted by RFC 7162) IMAP Extension for Conditional STORE Operation or Quick Flag Changes Resynchronization
4731 IMAP4 Extension to SEARCH Command for Controlling What Kind of Information Is Returned
4959 IMAP Extension for Simple Authentication and Security Layer (SASL) Initial Client Response
2023-06-24 13:07:22 +03:00
4978 The IMAP COMPRESS Extension
2023-01-30 16:27:06 +03:00
5032 WITHIN Search Extension to the IMAP Protocol
5092 IMAP URL Scheme
5161 The IMAP ENABLE Extension
5162 (obsoleted by RFC 7162) IMAP4 Extensions for Quick Mailbox Resynchronization
5182 IMAP Extension for Referencing the Last SEARCH Result
5255 Internet Message Access Protocol Internationalization
5256 Internet Message Access Protocol - SORT and THREAD Extensions
5257 Internet Message Access Protocol - ANNOTATE Extension
5258 Internet Message Access Protocol version 4 - LIST Command Extensions
5259 Internet Message Access Protocol - CONVERT Extension
5267 Contexts for IMAP4
5464 The IMAP METADATA Extension
5465 The IMAP NOTIFY Extension
5466 IMAP4 Extension for Named Searches (Filters)
2023-09-11 12:26:40 +03:00
5524 Extended URLFETCH for Binary and Converted Parts
2023-01-30 16:27:06 +03:00
5530 IMAP Response Codes
5738 (obsoleted by RFC 6855) IMAP Support for UTF-8
5788 IMAP4 Keyword Registry
5819 IMAP4 Extension for Returning STATUS Information in Extended LIST
5957 Display-Based Address Sorting for the IMAP4 SORT Extension
6154 IMAP LIST Extension for Special-Use Mailboxes
6203 IMAP4 Extension for Fuzzy Search
6237 (obsoleted by RFC 7377) IMAP4 Multimailbox SEARCH Extension
6851 Internet Message Access Protocol (IMAP) - MOVE Extension
6855 IMAP Support for UTF-8
6858 Simplified POP and IMAP Downgrading for Internationalized Email
7162 IMAP Extensions: Quick Flag Changes Resynchronization (CONDSTORE) and Quick Mailbox Resynchronization (QRESYNC)
2023-06-27 20:31:47 +03:00
7162-eid5055 errata: space after untagged OK
2023-01-30 16:27:06 +03:00
7377 IMAP4 Multimailbox SEARCH Extension
7888 IMAP4 Non-synchronizing Literals
7889 The IMAP APPENDLIMIT Extension
8437 IMAP UNAUTHENTICATE Extension for Connection Reuse
8438 IMAP Extension for STATUS=SIZE
2023-06-24 13:07:22 +03:00
8440 IMAP4 Extension for Returning MYRIGHTS Information in Extended LIST
2023-01-30 16:27:06 +03:00
8457 IMAP "$Important" Keyword and "\Important" Special-Use Attribute
2023-06-24 13:07:22 +03:00
8474 IMAP Extension for Object Identifiers
2023-01-30 16:27:06 +03:00
8508 IMAP REPLACE Extension
8514 Internet Message Access Protocol (IMAP) - SAVEDATE Extension
8970 IMAP4 Extension: Message Preview Generation
2023-06-24 13:07:22 +03:00
9208 IMAP QUOTA Extension
9394 IMAP PARTIAL Extension for Paged SEARCH and FETCH
2023-01-30 16:27:06 +03:00
2023-11-11 21:40:53 +03:00
5198 Unicode Format for Network Interchange
2023-01-30 16:27:06 +03:00
2023-09-11 12:26:40 +03:00
# Lemonade profile
4550 (obsoleted by RFC 5550) Internet Email to Support Diverse Service Environments (Lemonade) Profile
5383 Deployment Considerations for Lemonade-Compliant Mobile Email
5423 Internet Message Store Events
5442 LEMONADE Architecture - Supporting Open Mobile Alliance (OMA) Mobile Email (MEM) Using Internet Mail
5550 The Internet Email to Support Diverse Service Environments (Lemonade) Profile
5551 Lemonade Notifications Architecture
2023-01-30 16:27:06 +03:00
# Mailing list
2369 The Use of URLs as Meta-Syntax for Core Mail List Commands and their Transport through Message Header Fields
2919 List-Id: A Structured Field and Namespace for the Identification of Mailing Lists
# Sieve
2023-06-24 13:07:22 +03:00
3028 (obsoleted by RFC 5228) Sieve: A Mail Filtering Language
2023-01-30 16:27:06 +03:00
5228 Sieve: An Email Filtering Language
2023-06-24 13:07:22 +03:00
5804 A Protocol for Remotely Managing Sieve Scripts
3894 Sieve Extension: Copying Without Side Effects
5173 Sieve Email Filtering: Body Extension
5183 Sieve Email Filtering: Environment Extension
5229 Sieve Email Filtering: Variables Extension
5230 Sieve Email Filtering: Vacation Extension
5231 Sieve Email Filtering: Relational Extension
5232 Sieve Email Filtering: Imap4flags Extension
5233 Sieve Email Filtering: Subaddress Extension
5235 Sieve Email Filtering: Spamtest and Virustest Extensions
5260 Sieve Email Filtering: Date and Index Extensions
5293 Sieve Email Filtering: Editheader Extension
5429 Sieve Email Filtering: Reject and Extended Reject Extensions
5435 Sieve Email Filtering: Extension for Notifications
5437 Sieve Notification Mechanism: Extensible Messaging and Presence Protocol (XMPP)
5463 Sieve Email Filtering: Ihave Extension
5490 The Sieve Mail-Filtering Language -- Extensions for Checking Mailbox Status and Accessing Mailbox Metadata
5703 Sieve Email Filtering: MIME Part Tests, Iteration, Extraction, Replacement, and Enclosure
5784 Sieve Email Filtering: Sieves and Display Directives in XML
6131 Sieve Vacation Extension: "Seconds" Parameter
6558 Sieve Extension for Converting Messages before Delivery
6609 Sieve Email Filtering: Include Extension
6785 Support for Internet Message Access Protocol (IMAP) Events in Sieve
8579 Sieve Email Filtering: Delivering to Special-Use Mailboxes
8580 Sieve Extension: File Carbon Copy (FCC)
9042 Sieve Email Filtering: Delivery by MAILBOXID
3431 (obsoleted by RFC 5231) Relational Extension
3598 (obsoleted by RFC 5233) Subaddress Extension
3685 (obsoleted by RFC 5235) Spamtest and VirusTest Extensions
2023-01-30 16:27:06 +03:00
2023-06-24 13:07:22 +03:00
Also see http://sieve.info/documents
2023-01-30 16:27:06 +03:00
2023-09-11 12:26:40 +03:00
# JMAP
8620 The JSON Meta Application Protocol (JMAP)
8621 The JSON Meta Application Protocol (JMAP) for Mail
8887 A JSON Meta Application Protocol (JMAP) Subprotocol for WebSocket
9007 Handling Message Disposition Notification with the JSON Meta Application Protocol (JMAP)
9219 S/MIME Signature Verification Extension to the JSON Meta Application Protocol (JMAP)
9425 JSON Meta Application Protocol (JMAP) for Quotas
See implementation guide, https://jmap.io/server.html
2023-01-30 16:27:06 +03:00
# Vouch by reference
5518 Vouch By Reference
# TLS
2023-12-24 01:07:21 +03:00
5056 On the Use of Channel Bindings to Secure Channels
5705 Keying Material Exporters for Transport Layer Security (TLS)
5929 Channel Bindings for TLS
2023-01-30 16:27:06 +03:00
6125 Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)
implement dnssec-awareness throughout code, and dane for incoming/outgoing mail delivery
the vendored dns resolver code is a copy of the go stdlib dns resolver, with
awareness of the "authentic data" (i.e. dnssec secure) added, as well as support
for enhanced dns errors, and looking up tlsa records (for dane). ideally it
would be upstreamed, but the chances seem slim.
dnssec-awareness is added to all packages, e.g. spf, dkim, dmarc, iprev. their
dnssec status is added to the Received message headers for incoming email.
but the main reason to add dnssec was for implementing dane. with dane, the
verification of tls certificates can be done through certificates/public keys
published in dns (in the tlsa records). this only makes sense (is trustworthy)
if those dns records can be verified to be authentic.
mox now applies dane to delivering messages over smtp. mox already implemented
mta-sts for webpki/pkix-verification of certificates against the (large) pool
of CA's, and still enforces those policies when present. but it now also checks
for dane records, and will verify those if present. if dane and mta-sts are
both absent, the regular opportunistic tls with starttls is still done. and the
fallback to plaintext is also still done.
mox also makes it easy to setup dane for incoming deliveries, so other servers
can deliver with dane tls certificate verification. the quickstart now
generates private keys that are used when requesting certificates with acme.
the private keys are pre-generated because they must be static and known during
setup, because their public keys must be published in tlsa records in dns.
autocert would generate private keys on its own, so had to be forked to add the
option to provide the private key when requesting a new certificate. hopefully
upstream will accept the change and we can drop the fork.
with this change, using the quickstart to setup a new mox instance, the checks
at internet.nl result in a 100% score, provided the domain is dnssec-signed and
the network doesn't have any issues.
2023-10-10 13:09:35 +03:00
7250 Using Raw Public Keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)
2023-01-30 16:27:06 +03:00
7525 Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)
2023-12-24 01:07:21 +03:00
7627 Transport Layer Security (TLS) Session Hash and Extended Master Secret Extension
2023-01-30 16:27:06 +03:00
8314 Cleartext Considered Obsolete: Use of Transport Layer Security (TLS) for Email Submission and Access
2023-12-24 01:07:21 +03:00
8446 The Transport Layer Security (TLS) Protocol Version 1.3
2023-01-30 16:27:06 +03:00
8996 Deprecating TLS 1.0 and TLS 1.1
8997 Deprecation of TLS 1.1 for Email Submission and Access
2023-12-24 01:07:21 +03:00
9266 Channel Bindings for TLS 1.3
2023-01-30 16:27:06 +03:00
# SASL
2023-02-05 18:29:03 +03:00
2104 HMAC: Keyed-Hashing for Message Authentication
2195 IMAP/POP AUTHorize Extension for Simple Challenge/Response
2023-01-30 16:27:06 +03:00
4013 (obsoleted by RFC 7613) SASLprep: Stringprep Profile for User Names and Passwords
4422 Simple Authentication and Security Layer (SASL)
4505 Anonymous Simple Authentication and Security Layer (SASL) Mechanism
4616 The PLAIN Simple Authentication and Security Layer (SASL) Mechanism
5802 Salted Challenge Response Authentication Mechanism (SCRAM) SASL and GSS-API Mechanisms
6331 Moving DIGEST-MD5 to Historic
7613 (obsoleted by RFC 8265) Preparation, Enforcement, and Comparison of Internationalized Strings Representing Usernames and Passwords
7677 SCRAM-SHA-256 and SCRAM-SHA-256-PLUS Simple Authentication and Security Layer (SASL) Mechanisms
8265 Preparation, Enforcement, and Comparison of Internationalized Strings Representing Usernames and Passwords
# IDNA
3492 Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA)
5890 Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework
5891 Internationalized Domain Names in Applications (IDNA): Protocol
5892 The Unicode Code Points and Internationalized Domain Names for Applications (IDNA)
5893 Right-to-Left Scripts for Internationalized Domain Names for Applications (IDNA)
5894 Internationalized Domain Names for Applications (IDNA): Background, Explanation, and Rationale
# ACME
8555 Automatic Certificate Management Environment (ACME)
8737 Automated Certificate Management Environment (ACME) TLS Application-Layer Protocol Negotiation (ALPN) Challenge Extension
2023-12-21 17:16:30 +03:00
# CAA
8657 Certification Authority Authorization (CAA) Record Extensions for Account URI and Automatic Certificate Management Environment (ACME) Method Binding
8659 DNS Certification Authority Authorization (CAA) Resource Record
2023-01-30 16:27:06 +03:00
# DNS
1034 DOMAIN NAMES - CONCEPTS AND FACILITIES
1035 DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION
1101 DNS Encoding of Network Names and Other Types
1536 Common DNS Implementation Errors and Suggested Fixes
2181 Clarifications to the DNS Specification
2308 Negative Caching of DNS Queries (DNS NCACHE)
implement dnssec-awareness throughout code, and dane for incoming/outgoing mail delivery
the vendored dns resolver code is a copy of the go stdlib dns resolver, with
awareness of the "authentic data" (i.e. dnssec secure) added, as well as support
for enhanced dns errors, and looking up tlsa records (for dane). ideally it
would be upstreamed, but the chances seem slim.
dnssec-awareness is added to all packages, e.g. spf, dkim, dmarc, iprev. their
dnssec status is added to the Received message headers for incoming email.
but the main reason to add dnssec was for implementing dane. with dane, the
verification of tls certificates can be done through certificates/public keys
published in dns (in the tlsa records). this only makes sense (is trustworthy)
if those dns records can be verified to be authentic.
mox now applies dane to delivering messages over smtp. mox already implemented
mta-sts for webpki/pkix-verification of certificates against the (large) pool
of CA's, and still enforces those policies when present. but it now also checks
for dane records, and will verify those if present. if dane and mta-sts are
both absent, the regular opportunistic tls with starttls is still done. and the
fallback to plaintext is also still done.
mox also makes it easy to setup dane for incoming deliveries, so other servers
can deliver with dane tls certificate verification. the quickstart now
generates private keys that are used when requesting certificates with acme.
the private keys are pre-generated because they must be static and known during
setup, because their public keys must be published in tlsa records in dns.
autocert would generate private keys on its own, so had to be forked to add the
option to provide the private key when requesting a new certificate. hopefully
upstream will accept the change and we can drop the fork.
with this change, using the quickstart to setup a new mox instance, the checks
at internet.nl result in a 100% score, provided the domain is dnssec-signed and
the network doesn't have any issues.
2023-10-10 13:09:35 +03:00
2672 (obsoleted by RFC 6672) Non-Terminal DNS Name Redirection
3226 DNSSEC and IPv6 A6 aware server/resolver message size requirements
2023-01-30 16:27:06 +03:00
3363 Representing Internet Protocol version 6 (IPv6) Addresses in the Domain Name System (DNS)
3596 DNS Extensions to Support IP Version 6
3597 Handling of Unknown DNS Resource Record (RR) Types
implement dnssec-awareness throughout code, and dane for incoming/outgoing mail delivery
the vendored dns resolver code is a copy of the go stdlib dns resolver, with
awareness of the "authentic data" (i.e. dnssec secure) added, as well as support
for enhanced dns errors, and looking up tlsa records (for dane). ideally it
would be upstreamed, but the chances seem slim.
dnssec-awareness is added to all packages, e.g. spf, dkim, dmarc, iprev. their
dnssec status is added to the Received message headers for incoming email.
but the main reason to add dnssec was for implementing dane. with dane, the
verification of tls certificates can be done through certificates/public keys
published in dns (in the tlsa records). this only makes sense (is trustworthy)
if those dns records can be verified to be authentic.
mox now applies dane to delivering messages over smtp. mox already implemented
mta-sts for webpki/pkix-verification of certificates against the (large) pool
of CA's, and still enforces those policies when present. but it now also checks
for dane records, and will verify those if present. if dane and mta-sts are
both absent, the regular opportunistic tls with starttls is still done. and the
fallback to plaintext is also still done.
mox also makes it easy to setup dane for incoming deliveries, so other servers
can deliver with dane tls certificate verification. the quickstart now
generates private keys that are used when requesting certificates with acme.
the private keys are pre-generated because they must be static and known during
setup, because their public keys must be published in tlsa records in dns.
autocert would generate private keys on its own, so had to be forked to add the
option to provide the private key when requesting a new certificate. hopefully
upstream will accept the change and we can drop the fork.
with this change, using the quickstart to setup a new mox instance, the checks
at internet.nl result in a 100% score, provided the domain is dnssec-signed and
the network doesn't have any issues.
2023-10-10 13:09:35 +03:00
3833 Threat Analysis of the Domain Name System (DNS)
2023-01-30 16:27:06 +03:00
4343 Domain Name System (DNS) Case Insensitivity Clarification
4592 The Role of Wildcards in the Domain Name System
implement dnssec-awareness throughout code, and dane for incoming/outgoing mail delivery
the vendored dns resolver code is a copy of the go stdlib dns resolver, with
awareness of the "authentic data" (i.e. dnssec secure) added, as well as support
for enhanced dns errors, and looking up tlsa records (for dane). ideally it
would be upstreamed, but the chances seem slim.
dnssec-awareness is added to all packages, e.g. spf, dkim, dmarc, iprev. their
dnssec status is added to the Received message headers for incoming email.
but the main reason to add dnssec was for implementing dane. with dane, the
verification of tls certificates can be done through certificates/public keys
published in dns (in the tlsa records). this only makes sense (is trustworthy)
if those dns records can be verified to be authentic.
mox now applies dane to delivering messages over smtp. mox already implemented
mta-sts for webpki/pkix-verification of certificates against the (large) pool
of CA's, and still enforces those policies when present. but it now also checks
for dane records, and will verify those if present. if dane and mta-sts are
both absent, the regular opportunistic tls with starttls is still done. and the
fallback to plaintext is also still done.
mox also makes it easy to setup dane for incoming deliveries, so other servers
can deliver with dane tls certificate verification. the quickstart now
generates private keys that are used when requesting certificates with acme.
the private keys are pre-generated because they must be static and known during
setup, because their public keys must be published in tlsa records in dns.
autocert would generate private keys on its own, so had to be forked to add the
option to provide the private key when requesting a new certificate. hopefully
upstream will accept the change and we can drop the fork.
with this change, using the quickstart to setup a new mox instance, the checks
at internet.nl result in a 100% score, provided the domain is dnssec-signed and
the network doesn't have any issues.
2023-10-10 13:09:35 +03:00
5001 DNS Name Server Identifier (NSID) Option
2023-01-30 16:27:06 +03:00
5452 Measures for Making DNS More Resilient against Forged Answers
6604 xNAME RCODE and Status Bits Clarification
6672 DNAME Redirection in the DNS
6891 Extension Mechanisms for DNS (EDNS(0))
6895 Domain Name System (DNS) IANA Considerations
implement dnssec-awareness throughout code, and dane for incoming/outgoing mail delivery
the vendored dns resolver code is a copy of the go stdlib dns resolver, with
awareness of the "authentic data" (i.e. dnssec secure) added, as well as support
for enhanced dns errors, and looking up tlsa records (for dane). ideally it
would be upstreamed, but the chances seem slim.
dnssec-awareness is added to all packages, e.g. spf, dkim, dmarc, iprev. their
dnssec status is added to the Received message headers for incoming email.
but the main reason to add dnssec was for implementing dane. with dane, the
verification of tls certificates can be done through certificates/public keys
published in dns (in the tlsa records). this only makes sense (is trustworthy)
if those dns records can be verified to be authentic.
mox now applies dane to delivering messages over smtp. mox already implemented
mta-sts for webpki/pkix-verification of certificates against the (large) pool
of CA's, and still enforces those policies when present. but it now also checks
for dane records, and will verify those if present. if dane and mta-sts are
both absent, the regular opportunistic tls with starttls is still done. and the
fallback to plaintext is also still done.
mox also makes it easy to setup dane for incoming deliveries, so other servers
can deliver with dane tls certificate verification. the quickstart now
generates private keys that are used when requesting certificates with acme.
the private keys are pre-generated because they must be static and known during
setup, because their public keys must be published in tlsa records in dns.
autocert would generate private keys on its own, so had to be forked to add the
option to provide the private key when requesting a new certificate. hopefully
upstream will accept the change and we can drop the fork.
with this change, using the quickstart to setup a new mox instance, the checks
at internet.nl result in a 100% score, provided the domain is dnssec-signed and
the network doesn't have any issues.
2023-10-10 13:09:35 +03:00
7686 The ".onion" Special-Use Domain Name
2023-01-30 16:27:06 +03:00
7766 DNS Transport over TCP - Implementation Requirements
implement dnssec-awareness throughout code, and dane for incoming/outgoing mail delivery
the vendored dns resolver code is a copy of the go stdlib dns resolver, with
awareness of the "authentic data" (i.e. dnssec secure) added, as well as support
for enhanced dns errors, and looking up tlsa records (for dane). ideally it
would be upstreamed, but the chances seem slim.
dnssec-awareness is added to all packages, e.g. spf, dkim, dmarc, iprev. their
dnssec status is added to the Received message headers for incoming email.
but the main reason to add dnssec was for implementing dane. with dane, the
verification of tls certificates can be done through certificates/public keys
published in dns (in the tlsa records). this only makes sense (is trustworthy)
if those dns records can be verified to be authentic.
mox now applies dane to delivering messages over smtp. mox already implemented
mta-sts for webpki/pkix-verification of certificates against the (large) pool
of CA's, and still enforces those policies when present. but it now also checks
for dane records, and will verify those if present. if dane and mta-sts are
both absent, the regular opportunistic tls with starttls is still done. and the
fallback to plaintext is also still done.
mox also makes it easy to setup dane for incoming deliveries, so other servers
can deliver with dane tls certificate verification. the quickstart now
generates private keys that are used when requesting certificates with acme.
the private keys are pre-generated because they must be static and known during
setup, because their public keys must be published in tlsa records in dns.
autocert would generate private keys on its own, so had to be forked to add the
option to provide the private key when requesting a new certificate. hopefully
upstream will accept the change and we can drop the fork.
with this change, using the quickstart to setup a new mox instance, the checks
at internet.nl result in a 100% score, provided the domain is dnssec-signed and
the network doesn't have any issues.
2023-10-10 13:09:35 +03:00
7828 The edns-tcp-keepalive EDNS0 Option
7873 Domain Name System (DNS) Cookies
2023-01-30 16:27:06 +03:00
8020 NXDOMAIN: There Really Is Nothing Underneath
8482 Providing Minimal-Sized Responses to DNS Queries That Have QTYPE=ANY
8490 DNS Stateful Operations
implement dnssec-awareness throughout code, and dane for incoming/outgoing mail delivery
the vendored dns resolver code is a copy of the go stdlib dns resolver, with
awareness of the "authentic data" (i.e. dnssec secure) added, as well as support
for enhanced dns errors, and looking up tlsa records (for dane). ideally it
would be upstreamed, but the chances seem slim.
dnssec-awareness is added to all packages, e.g. spf, dkim, dmarc, iprev. their
dnssec status is added to the Received message headers for incoming email.
but the main reason to add dnssec was for implementing dane. with dane, the
verification of tls certificates can be done through certificates/public keys
published in dns (in the tlsa records). this only makes sense (is trustworthy)
if those dns records can be verified to be authentic.
mox now applies dane to delivering messages over smtp. mox already implemented
mta-sts for webpki/pkix-verification of certificates against the (large) pool
of CA's, and still enforces those policies when present. but it now also checks
for dane records, and will verify those if present. if dane and mta-sts are
both absent, the regular opportunistic tls with starttls is still done. and the
fallback to plaintext is also still done.
mox also makes it easy to setup dane for incoming deliveries, so other servers
can deliver with dane tls certificate verification. the quickstart now
generates private keys that are used when requesting certificates with acme.
the private keys are pre-generated because they must be static and known during
setup, because their public keys must be published in tlsa records in dns.
autocert would generate private keys on its own, so had to be forked to add the
option to provide the private key when requesting a new certificate. hopefully
upstream will accept the change and we can drop the fork.
with this change, using the quickstart to setup a new mox instance, the checks
at internet.nl result in a 100% score, provided the domain is dnssec-signed and
the network doesn't have any issues.
2023-10-10 13:09:35 +03:00
8499 DNS Terminology
2023-01-30 16:27:06 +03:00
8767 Serving Stale Data to Improve DNS Resiliency
implement dnssec-awareness throughout code, and dane for incoming/outgoing mail delivery
the vendored dns resolver code is a copy of the go stdlib dns resolver, with
awareness of the "authentic data" (i.e. dnssec secure) added, as well as support
for enhanced dns errors, and looking up tlsa records (for dane). ideally it
would be upstreamed, but the chances seem slim.
dnssec-awareness is added to all packages, e.g. spf, dkim, dmarc, iprev. their
dnssec status is added to the Received message headers for incoming email.
but the main reason to add dnssec was for implementing dane. with dane, the
verification of tls certificates can be done through certificates/public keys
published in dns (in the tlsa records). this only makes sense (is trustworthy)
if those dns records can be verified to be authentic.
mox now applies dane to delivering messages over smtp. mox already implemented
mta-sts for webpki/pkix-verification of certificates against the (large) pool
of CA's, and still enforces those policies when present. but it now also checks
for dane records, and will verify those if present. if dane and mta-sts are
both absent, the regular opportunistic tls with starttls is still done. and the
fallback to plaintext is also still done.
mox also makes it easy to setup dane for incoming deliveries, so other servers
can deliver with dane tls certificate verification. the quickstart now
generates private keys that are used when requesting certificates with acme.
the private keys are pre-generated because they must be static and known during
setup, because their public keys must be published in tlsa records in dns.
autocert would generate private keys on its own, so had to be forked to add the
option to provide the private key when requesting a new certificate. hopefully
upstream will accept the change and we can drop the fork.
with this change, using the quickstart to setup a new mox instance, the checks
at internet.nl result in a 100% score, provided the domain is dnssec-signed and
the network doesn't have any issues.
2023-10-10 13:09:35 +03:00
8914 Extended DNS Errors
9018 Interoperable Domain Name System (DNS) Server Cookies
2023-01-30 16:27:06 +03:00
9210 DNS Transport over TCP - Operational Requirements
# DNSSEC
3225 Indicating Resolver Support of DNSSEC
3658 Delegation Signer (DS) Resource Record (RR)
4033 DNS Security Introduction and Requirements
4034 Resource Records for the DNS Security Extensions
4035 Protocol Modifications for the DNS Security Extensions
4470 Minimally Covering NSEC Records and DNSSEC On-line Signing
4956 DNS Security (DNSSEC) Opt-In
5155 DNS Security (DNSSEC) Hashed Authenticated Denial of Existence
5702 Use of SHA-2 Algorithms with RSA in DNSKEY and RRSIG Resource Records for DNSSEC
5933 Use of GOST Signature Algorithms in DNSKEY and RRSIG Resource Records for DNSSEC
6014 Cryptographic Algorithm Identifier Allocation for DNSSEC
6781 DNSSEC Operational Practices, Version 2
6840 Clarifications and Implementation Notes for DNS Security (DNSSEC)
implement dnssec-awareness throughout code, and dane for incoming/outgoing mail delivery
the vendored dns resolver code is a copy of the go stdlib dns resolver, with
awareness of the "authentic data" (i.e. dnssec secure) added, as well as support
for enhanced dns errors, and looking up tlsa records (for dane). ideally it
would be upstreamed, but the chances seem slim.
dnssec-awareness is added to all packages, e.g. spf, dkim, dmarc, iprev. their
dnssec status is added to the Received message headers for incoming email.
but the main reason to add dnssec was for implementing dane. with dane, the
verification of tls certificates can be done through certificates/public keys
published in dns (in the tlsa records). this only makes sense (is trustworthy)
if those dns records can be verified to be authentic.
mox now applies dane to delivering messages over smtp. mox already implemented
mta-sts for webpki/pkix-verification of certificates against the (large) pool
of CA's, and still enforces those policies when present. but it now also checks
for dane records, and will verify those if present. if dane and mta-sts are
both absent, the regular opportunistic tls with starttls is still done. and the
fallback to plaintext is also still done.
mox also makes it easy to setup dane for incoming deliveries, so other servers
can deliver with dane tls certificate verification. the quickstart now
generates private keys that are used when requesting certificates with acme.
the private keys are pre-generated because they must be static and known during
setup, because their public keys must be published in tlsa records in dns.
autocert would generate private keys on its own, so had to be forked to add the
option to provide the private key when requesting a new certificate. hopefully
upstream will accept the change and we can drop the fork.
with this change, using the quickstart to setup a new mox instance, the checks
at internet.nl result in a 100% score, provided the domain is dnssec-signed and
the network doesn't have any issues.
2023-10-10 13:09:35 +03:00
7901 CHAIN Query Requests in DNS
2023-01-30 16:27:06 +03:00
8198 Aggressive Use of DNSSEC-Validated Cache
8624 Algorithm Implementation Requirements and Usage Guidance for DNSSEC
8749 Moving DNSSEC Lookaside Validation (DLV) to Historic Status
9077 NSEC and NSEC3: TTLs and Aggressive Use
9157 Revised IANA Considerations for DNSSEC
9276 Guidance for NSEC3 Parameter Settings
2023-05-30 23:11:31 +03:00
# HTTP
2616 Hypertext Transfer Protocol -- HTTP/1.1
7230 Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing
9110 HTTP Semantics
# Websockets
6455 The WebSocket Protocol
2023-01-30 16:27:06 +03:00
# More
2023-02-05 12:55:34 +03:00
3339 Date and Time on the Internet: Timestamps
2023-01-30 16:27:06 +03:00
3986 Uniform Resource Identifier (URI): Generic Syntax
5617 (Historic) DomainKeys Identified Mail (DKIM) Author Domain Signing Practices (ADSP)
6186 (not used in practice) Use of SRV Records for Locating Email Submission/Access Services
7817 Updated Transport Layer Security (TLS) Server Identity Check Procedure for Email-Related Protocols
2023-09-11 12:26:40 +03:00
# WebDAV
4918 HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)
3253 Versioning Extensions to WebDAV (Web Distributed Authoring and Versioning)
3648 Web Distributed Authoring and Versioning (WebDAV) Ordered Collections Protocol
3744 Web Distributed Authoring and Versioning (WebDAV) Access Control Protocol
4437 Web Distributed Authoring and Versioning (WebDAV) Redirect Reference Resources
5323 Web Distributed Authoring and Versioning (WebDAV) SEARCH
6578 Collection Synchronization for Web Distributed Authoring and Versioning (WebDAV)
# CalDAV
4791 Calendaring Extensions to WebDAV (CalDAV)
5689 Extended MKCOL for Web Distributed Authoring and Versioning (WebDAV)
6638 Scheduling Extensions to CalDAV
6764 Locating Services for Calendaring Extensions to WebDAV (CalDAV) and vCard Extensions to WebDAV (CardDAV)
7809 Calendaring Extensions to WebDAV (CalDAV): Time Zones by Reference
7953 Calendar Availability
# iCal
5545 Internet Calendaring and Scheduling Core Object Specification (iCalendar)
5546 iCalendar Transport-Independent Interoperability Protocol (iTIP)
6047 iCalendar Message-Based Interoperability Protocol (iMIP)
6868 Parameter Value Encoding in iCalendar and vCard
7529 Non-Gregorian Recurrence Rules in the Internet Calendaring and Scheduling Core Object Specification (iCalendar)
7986 New Properties for iCalendar
9073 Event Publishing Extensions to iCalendar
9074 "VALARM" Extensions for iCalendar
9253 Support for iCalendar Relationships
6321 xCal: The XML Format for iCalendar
7265 jCal: The JSON Format for iCalendar
# CardDAV
6352 CardDAV: vCard Extensions to Web Distributed Authoring and Versioning (WebDAV)
# vCard
2425 A MIME Content-Type for Directory Information
2426 vCard MIME Directory Profile
6350 vCard Format Specification
6351 xCard: vCard XML Representation
6473 vCard KIND:application
6474 vCard Format Extensions: Place of Birth, Place and Date of Death
6715 vCard Format Extensions: Representing vCard Extensions Defined by the Open Mobile Alliance (OMA) Converged Address Book (CAB) Group
6869 vCard KIND:device
7095 jCard: The JSON Format for vCard
