On 2026-09-11 15:19, Al Iverson via mailop wrote:
On Fri, Sep 11, 2026 at 2:10 PM Benoît Panizzon <[email protected]> wrote:
Well, now we can not tell her anymore which of the 8 microsoft
recipients reported her email.
Yes, I understood the problem as you described it.
+1
Coding around this issue also is not tivial
Nope, it is not. But it is not impossible.
and even desirable. In an ideal world, every participant
([email protected], [email protected]) would have a digital
keypair, with the public key hosted somewhere at
https://example.com/.well_known/email/user/key.pub and the private key
either in safe custody of their service provider or, better, in their
own possession, preferably on a hardware token.
in said ideal world, said message *could* be:
- of the highest standard: encrypted using the recipient's public key
and signed using the sender's private key
- of the common standard: like today, plain text
- or in between (signed not encrypted; encrypted not singed)
in said ideal world, the sender would declare in some standardized
header the nature of the email. text field (open ended) with some
standard natures such as "personal" or "invoice", but also room for
creativity and honesty ("account statement with embedded ad"). the
recipient would be presented with a simple interface asking whether what
they see correspond to the declared nature, and so the feedback would
not be just wanted/unwanted; but rather honest/dishonest. because
recipients make mistakes, and sometimes they have also bad days and just
throw into the dustbin what on other days they would not.
in an even more advanced stage, participants could add policy statements
in https://example.com/.well_known/email/user/policy.md.
machine-readable policy statement will further inform service providers.
for example, I as recipient could have a policy to require encrypted
message, and with such a requirement, my mailbox provider will know to
return undeliverable messages that are not.
yes, that means that email messages will become unique for each
recipient, and that will increase network volume and computational
requirements. arguably, it will lead to better quality, lower overall
volume, and the resources will be used to generate more systemic value.
yes, that means non-trivial changes to the software along the chain.
Benoît's server will have to make twenty different copies out of the one
Granny message, verify each individual's recipient's key/policy;
possibly compute encryption twenty times; and then apply Granny's
signature twenty times using her key that is probably in the server's
custody anyway.
I suppose the harder problem is to nudge your users to not send mass
email invites without using a tool better suited for that purpose.
the even harder one is to nudge them not to send emails contrary to the
recipients' wishes.
Granny "mass" mails twenty recipients once a year.
I deal with "professional" organizations mass mailing tens of thousands
of recipients once a day, enabled by Salesforce and its likes. Not
picking specifically on Salesforce, it was just the tool used in the
last obnoxious campaign fired at me by some idiot marketer.
best,
Yuv
_______________________________________________
mailop mailing list
[email protected]
https://list.mailop.org/listinfo/mailop
