[Top] [All Lists]

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

2015-02-27 10:04:30

--On Friday, February 27, 2015 10:50 +0100 Alessandro Vesely
<vesely(_at_)tana(_dot_)it> wrote:

On Wed 25/Feb/2015 16:35:33 +0100 Kai Engert 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:


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

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 

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.

A (draft) writeup of this idea can be found as a PDF file at:

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.

ietf-smtp mailing list

<Prev in Thread] Current Thread [Next in Thread>