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

From: Kai Engert <[email-masked]>
Date: Wed, 25 Feb 2015 16:35:33 +0100

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

---

From: "John Levine" <[email-masked]>
Date: 25 Feb 2015 18:13:44 -0000

In article <[email-masked]> you write:
>avoiding spam. The ASRG list is no longer active,

It's still around but I moved it when the ASRG research group shut down.
Send "subscribe" to [email-masked]

>discussed/rejected already.

These are all well known ideas, some of which are very, very old.  For
example, notify and poll was proposed by Dan Bernstein in the 1990s.
See http://cr.yp.to/im2000.html

Some of the ideas turn out to be bad, others are OK but not worth the
enormous switching costs from the way mail works now.  A few including
notify and poll have patent license issues in the U.S.

R's,
John, former ASRG chair

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 27 Feb 2015 10:50:10 +0100

> enhancement of today's SMTP, so let's start by discussing if this

The reason why it is inappropriate is that the IETF seems to be committed to
standardizing practices which are already in widespread use, rather than
discussing new ideas.  For example, it recently elevated to Internet Standard
the ASCII format for network interchange:
http://mailarchive.ietf.org/arch/msg/ietf-announce/rlIsY8yvvKhbkbkuk2mcQ-ylSNw

SMTP is not yet an Internet Standard, in the sense that the old standard (RFC
821) is obsolete, and elevating the current draft (RFC 5321) is not being
considered, AFAIK.

> https://kuix.de/two-way-mail/

In the motivation, the article considers unsolicited email to be spam, which is
wrong, according to most people's opinion.  "Bulk" is the usually added
adjective, although unsolicited bulk email (UBE) doesn't cover all cases of
thoughtless sending, and has false positives (e.g. emergency alerts).

A difficulty with your approach is that there is no globally deployed method to
ascertain that a sender is who he says he is.  Spammers would still be able to
buy sender addresses and spam the recipients who whitelisted them.  For
example, sender accounts can be bought here: https://buyaccs.com/

> Require email address whitelists, controlled by the user

Users are unable to do that.  If it were possible to have them maintain
whitelists at least for their mailing list subscriptions, there would be no
problems using DMARC.

IMHO whitelist maintenance should be an automated side effect of subscription.

> to discover them and add entries to the whitelist.

That renames the problem without solving it.  To require that email recipients
periodically check a list of recent contact attempts (RCA) doesn't differ from
current practices if you re-rename "message" an RCA, "message content" its
subject, and "inbox" the list.

Ale
--

---

From: John C Klensin <[email-masked]>
Date: Fri, 27 Feb 2015 11:04:03 -0500

--On Friday, February 27, 2015 10:50 +0100 Alessandro Vesely
<[email-masked]> wrote:

>> 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.
> 
> The reason why it is inappropriate is that the IETF seems to
> be committed to standardizing practices which are already in
> widespread use, rather than discussing new ideas.  For
> example, it recently elevated to Internet Standard the ASCII
> format for network interchange:

Alessandro,

Just to clarify a few things on the assumption that you are
serious (but possibly confused) rather than having discovered
that today is International Troll Day and feeling a need to
celebrate...

First, the status change for RFC 20 was done to eliminate a
technical procedural problem and to correct a rather old
classification error.  No one should think that it changes the
status of ASCII at all.

Second, John Levine has already explained some of the reasons
why this particular idea is neither new nor particularly
helpful.   I recommend that anyone who believes they have a
magical solution for spam have a look at t Vern Schryver's
summary at http://www.rhyolite.com/anti-spam/you-might-be.html 

> SMTP is not yet an Internet Standard, in the sense that the
> old standard (RFC 821) is obsolete, and elevating the current
> draft (RFC 5321) is not being considered, AFAIK.

It is actually "considered" regularly and, as many people who
have been following this list know, I've been keeping and
updating a working draft for a possible 5321bis since not long
after that document was published.  I can't speak to all the
reasons why an update has not appeared and been processed for
full standard, but at least three of them (not independent of
each other) are:

(i) Despite the somewhat intermittent preferences of a few of
us, there doesn't appear to be real community demand for such an
update, especially demand sufficient to justify the effort it
would take.

(ii)  There is clear evidence that an attempt to open 5321bis
for discussion and review would require us to revisit many of
the decisions made by the DRUMS WG (leading to RFC 2821) and in
the process of getting what became RFC 5321 reviewed and
approved.  A few of those issues, such as the one raised in a
recent discussion about source paths, almost certainly need
review and discussion.  Most probably don't, but that would not
prevent them from generating a large amount of noise and
workload, especially for the editor, AD(s), and possibly a WG
and associated apparatus.

(iii) There is at least equally clear evidence that such an
attempt would bring a out large number of proposals that claim
that, if only SMTP were changed in such-and-such a way, spam,
and/or phishing and perhaps world hunger and global warming
would be eliminated.  Like this proposal, they would have to be
analyzed and discussed one at a time and, like this proposal,
suggestions that IETF rules don't permit adding new and untried
features or requirements to a document intended to become a full
standard would probably be met with derisive comments about
looking backwards.

The net result is considerably reduced motivation.

> In the motivation, the article considers unsolicited email to
> be spam, which is wrong, according to most people's opinion.
> "Bulk" is the usually added adjective, although unsolicited
> bulk email (UBE) doesn't cover all cases of thoughtless
> sending, and has false positives (e.g. emergency alerts).
>...

Thanks, at least, for your summary.  There are, fwiw, a number
of other issues in addition to the ones that you and John Levine
mentioned.  That said, as I have pointed out on other occasions,
I've got one mailbox that, despite having been around (and moved
from system to system) starting years before many readers of
this list had heard of email or the Internet, has never received
a single spam message.  It works by having a filter in the
delivery process that rejects any message that is not
authenticated in a way that is recognized and accepted by the
recipient system.  That authenticator was a cookie 30 years ago
and is now a PGP signature using a key that the delivery server
already has cached.  It resembles this most recent proposal in
that it requires prior arrangements between sender and proposed
receiver for mail to be received and by having lousy scaling
properties but, for the cases where it is useful and worth the
trouble, it has a really good track record.
 
   john