Subject: Re: [ietf-smtp] Idea: Two-Way Mail

From: Chris Newman <[email-masked]>
Date: Tue, 03 Mar 2015 18:37:17 -0800

One of the key problems with white-listing email is that many security systems
(including web authentication systems) are layered on top of an email
introduction from a previously unknown sender. If I'm signing up for an account
on a web page and it sends me email to confirm I own the address I'm using,
that doesn't work with a white-listing mechanism.

Like it or not, email-without-introduction is mission critical to the Internet.
We just can't break that in general. So incompatible changes to the core
protocols don't make sense now.

But could we make incremental improvements or reduce the need for that? I think
so. If someone defined practices for a web browser to create a CardDAV/vCard
entry with appropriate attributes when creating an account, and perhaps a media
type or header to indicate a message is this sort of ownership confirmation
message then those messages could be processed automatically if correlated with
an approved CardDAV/vCard entry.

That's just an example. I think there is room for improvement, but it's going
to go a lot faster if done as extensions that can win if they're useful enough
to deploy. Perhaps we could allow some users (not sales people, however) to
migrate towards a whitelist-only model if we are successful enough at providing
better ways to solve introduction problems like the one I mention above. But
such a mechanism needs to be off-by-default to avoid inadvertently breaking all
the usually unnoticed critical functions layered on email.

Another big problem is that there are few people in the email industry with
spare cycles to work on significant standards. So someone with a lot of cycles
needs to lead the effort with deployable extensions that improve the situation
without breaking things.

		- Chris

--On February 25, 2015 16:35:33 +0100 Kai Engert <[email-masked]> wrote:
> Hello,
> 
> I'm not sure what's the best place to send this idea to enhance SMTP for
> avoiding spam. The ASRG list is no longer active, so I'm trying it on
> this list. Please suggest better places if you think it's inappropriate.
> I think it might be appropriate, if there's willinglist to adopt. I
> understand that many people/groups would have to agree to such an
> enhancement of today's SMTP, so let's start by discussing if this
> approach could work.
> 
> A (draft) writeup of this idea can be found as a PDF file at:
> https://kuix.de/two-way-mail/
> 
> Very short summary below:
> =================================
> Email should adopt the both-way opt-in requirement used by many instant
> messaging systems, before messages are accepted for delivery.
> 
> Require email address whitelists, controlled by the user, managed on the
> user's mailbox server.
> 
> Find a way to signal contact attempts to the recipient, enabling a user
> to discover them and add entries to the whitelist.
> 
> Change email delivery from today's store-and-forward approach and switch
> to store-notify-and-poll.
> 
> Have the destination server retrieve email only if the sender address is
> in the recipient's whitelist.
> 
> Have the destination server contact a mail server based on official
> records (e.g. DNS), instead of accepting mail from anywhere.
> =================================
> 
> Please let me know in case this is actually an old idea and has been
> discussed/rejected already.
> I'd appreciate your feedback.
> 
> Best Regards
> Kai
> 
> 
> _______________________________________________
> ietf-smtp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-smtp
>

---

From: "John Levine" <[email-masked]>
Date: 4 Mar 2015 17:10:04 -0000

>protocols don't make sense now.

Quite right.  There have been endless anti-spam proposals that amount
to dividing the world between the good guys inside the perimeter, and
the bad guys outside.  But this just replaces the spam problem with
the introduction problem, which is at least as hard.

I've set up a taxonomy of anti-spam techniques in the ASRG wiki:

http://wiki.asrg.sp.am/wiki/Taxonomy_of_anti-spam_techniques

It's reasonably complete, but if anyone can think of ones that are missing,
drop me a note and I'll give you a password so you can add them.

R's,
John