On 2025-10-19 12:24, Viktor Dukhovni via mailop wrote:
On Sun, Oct 19, 2025 at 11:45:38AM -0400, postfix--- via mailop wrote:
On 2025-10-19 10:39, Alessandro Vesely via mailop wrote:
> While you can self-sign a certificate saying that your name is "example.com",
> most CAs at least verify that the domain name is actually controlled by the
> requestor.
How about adding the fingerprint of the certificate to DNS, or even better
publish the public key in some well-known URL on the server pointed by DNS?
just sayin'
It seems you're inclined to reinvent DANE. It's been done already.
There are today at least ~4.27 million domains with DANE TLSA records
for SMTP. Example:
https://stats.dnssec-tools.org/explore/?ietf.org
those are two DNS entries and four certificates for a domain. Think a
few magnitudes larger.
There may be some overlap, but reinvention is not. Millions of
certificates per domain. Certainly not millions of DNS entries. Not
going to burden DNS directly with certificate lifecycle, storage,
distribution.
One certificate per email address/alias.
cryptography, something between S/MIME and DANE (and DKIM), a
certificate that MAY be used to encrypt and sign individual messages
like S/MIME or PGP but without the usability issues and managed by the
MTA, not the MUA.
policy, augmented SPF: not just a declaration of which SMTP client may
send messages for the domain, but also what messages the sender is
sending, per **individual message**; and what messages the recipient
accepts (with an exception for some messages that recipients must accept).
an extension of the SMTP protocol. sorry for the non-technical
description, I am confident you get the jist:
COMMUNICATION PROTOCOL
======================
Sender-MUA: SHOULD declare nature of the message being sent, as a
header. if nature of the message is not declared, it is assumed to be
individual to individual postcard (the simplest possible email).
SMTP-client: receive messages and initiates SMTP transmission
SMTP-server: responds with user's acceptable policy. Example: this user
only accepts encrypted and signed messages, and no review requests
(further details on policies below)
SMTP-client: fetch recipient's public key from well known location and
sender's private key from its own storage. encrypt/sign, send
SMTP-server: fetch sender's public key from well known location and
recipient's private key from its own storage. verify/decrypt. Adds
header (URL) for recipient's feedback
Policy-Filter: reject if sender-declared nature of message does not
match recipient's policy
Recipient-MUA: MAY display a button for the recipient to signal back if
the nature of the message received correspond to the sender-declared nature.
POLICIES
========
- recipients CAN declare various level of encryption required
- recipients CAN declare various level of certificates required, down to
individual CA acceptance (from self-signed, to commercial, to extended
verification, to government ID)
- recipients CAN declare various natures/purposes of acceptable messages
- sender is advised to comply
- cryptography is three possibilities: encrypted and signed;
signed-only; neither. encrypted only does not make sense.
- nature/purpose of acceptable messages is an ever-expanding list of
possibilities. because the smart wannaspam will try to classify their
message as something different. recipients can define that their policy
is either permissive, allowing everything except what is listed; or
restrictive, allowing only what is listed.
- list of nature/purposes will (inevitably?) be somewhat long, because
semantics and translations into various languages. eventually,
reasonable senders and recipients will negotiate canonical terms, e.g.
invoice and not invoices.
POLICING
========
- SMTP-server enforces usage of encryption per recipient's specified policy
- SMTP-server enforces acceptable purpose of message per recipient's
specified policy, with an exemption for messages whose nature requires
so. can't let a recipient refuse legitimate invoices; government
mandated messages; etc.
- Recipient-MUA gives recipient the opportunity to signal whether the
message nature/purpose was misrepresented. binary YES/NO. in case of
mixed nature messages, e.g. advertisment within an invoice, sender's
risk to be labeled as spammer.
- based on the signal from the recipient MUA, SMTP-server can score/rate
SMTP-client for future anti-abuse throttling or blocking
- signal is fed back to SMTP-client for user policing.
- all those signals, except the recipient's activation of the feedback
header, are automatic and in a form so that both SMTP-server and
SMTP-client can collect aggregate statistics
What SMTP operators do with their statistics, if at all, is their
business. The goal is to create a clean, actionable signal. A
commercial SMTP operators may use those counters to charge "stamps" to
their senders. The less desirable the message, the higher the stamp,
with a threshold where the SMTP-Sender will deem acceptable to them,
beyond which they will block their sender before getting blocked by the
SMTP-Recipient. A purely economical approach to abuse and reputation.
CERTIFICATES
============
- general principle: everything from self-signed to the most publicly
trusted commercial or governmental CA IS acceptable
- MAY be delegated to the MUA, with the SMTP-server providing a
communication protocol to upload/replace certificates
- MAY be fully automated at the SMTP-server, with completely automated
lifecycle
Yuv
_______________________________________________
mailop mailing list
[email protected]
https://list.mailop.org/listinfo/mailop
