On 8/25/23 15:35, John R. Levine wrote:
On Thu, 24 Aug 2023, Keith Moore wrote:
* We have, IMO, largely failed to make email interoperable in the
presence of spam filters. Making email delivery reliable is
currently, as far as I can tell, a dark art.
If you know how to do that, I know a lot of people who really really
would like to talk to you. The same message might be legit to someone
who asked for it and spam to someone who didn't, so there's no
technical way to distinguish. Most of the spam that gets into my
inbox is from throwaway accounts at the same places that send much of
my real mail, and not for lack of effort on the part of mail systems
to stop it. (At this point, whatever clever anti-spam scheme someone
might suggest, I'm confident I can tell you whre it's failed before.)
It's simple to take a stab at describing the problem, much more
difficult to identify a specific set of mechanisms that are usable by
ordinary people to let them control what kind of spam filters make sense
for them.
I absolutely agree that there's no purely technical way to distinguish
spam from ham, but it is possible to fairly reliably place messages into
specific categories that are useful for some particular user. e.g.
based on message content (what language?), length, types of attachments,
whether signed by a party known to the recipient, whether the sender is
known to the recipient, etc. All of these mechanisms exist already but
quite often aren't effectively controllable by the user. I suspect
users would benefit from some standard indications and maybe some
nonbinding user interface recommendations.
Also a set of recommendations for how to make email easily classified on
the recipient's end. e.g. which magic DNS records should be set up,
what kind of signatures should be used, how should those signers' public
keys be verified? These mechanisms have been in use for long enough
that we must surely by now have some ideas of which ones are useful and
for which purposes.
Once I lost a contract worth hundreds of thousands of dollars because
the would-be client's mail got caught by a spam filter, I realized that
spam filtering really needed to be something that could be specified on
a per-recipient basis.
* The widespread use of email from mobile handheld devices has had a
tremendous effect on the usability of email for technical
collaboration, such as IETF does.
This is conflating cause and effect. People are going to use their
phones for mail whether we like it or not, so it would be a good idea
for us to figure out how to make it work. Telling them to go away
until they can find a real computer isn't it.
I expect it would continue to be a matter of recipient preference how
they handle their incoming email. But maybe we can give them better tools.
On the other hand, I don't know of any way to make long emails readable
on a small screen. But if the email were formatted carefully, maybe a
message with multiple levels of replies (quoting a portion of the
subject message at each level), could have those quoted portions
collapsed by default and expanded by clicking on the recipient email.
(Would it help? I suspect not much, but I'm open to suggestions and
experimentation with suggestions.)
* We've completely failed to make email end-to-end secure, not because
the problems aren't solvable, but because we've let a very small
number of people talk us out of trying.
At this point I don't even know what "end" means. Where's the end in
a webmail session?
Each end of a conversation between humans is always the human, if the
user is a human. (might also need bot-to-human and vice versa) In a
webmail session, I'd say that the ideal is for the {en,de}cryption to be
done on the human's web browser. That's hard to do well without
explicit support in the browser for key storage and management, but it's
not out of the question to define how such support should work.
More generally I think there will be a need both for human-to-human
encryption (with no cleartext in between) and enterprise-to-enterprise
encryption (where each party's enterprise's network can see the
cleartext for various purposes - malware filtering, logging, to prevent
exfiltration of sensitive information, etc., etc.) Those are
legitimate business and/or legal reasons. The trick is, I think, to
distinguish the two cases and make the differences sufficiently clear to
users. If I get an email from president@xxxxxxxxxxxxxx, I really want
to know whether it came directly from Joe Biden or from someone in the
White House speaking on his behalf. (which is probably a flawed example
but I hope that at least illustrates why the difference between
human-to-human and enterprise-to-enterprise is important.) Or if I get
an email from someone in an oppressive country, I'd like to be able to
know whether that country's government is reading that sender's mail.
(Then the problem is to figure out which CAs are honest and which ones
are compromised...)
* We've failed to adapt SMTP/IMAP/POP authentication standards (and
for authentication in other application protocols) to a world where
multi-factor authentication is increasingly required, and where
hardware authentication tokens are widely available.
For once I agree with you, although there seems to be some progress
there. Perhaps we need to talk more to the FIDO people.
Yes. I think SASL can be extended to these use cases, but the details
need to be worked out.
Keith
