ietf-smtp
[Top] [All Lists]

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

2015-03-02 09:37:35
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:
http://mailarchive.ietf.org/arch/msg/ietf-announce/rlIsY8yvvKhbkbkuk2mcQ-ylSNw

Nonsense. John Klensin already explained why this action in regards to ASCII is
apropos of exactly nothing.

Moreover, the counterexamples to this thesis are thick on the ground: MIME was
in no way deployed when it was standardized, nor was/is EAI. HTTP/2 is the
obvious recent non-email counterexample. The list goes on and on and on.

The problem with most "new" anti-spam techniques is actually the exact
opposite: They aren't new, they often have been deployed as part of one system
or another, and when that was done they didn't work very well. (John Levine has
already responded to this particular proposal; I have nothing to add to that
response.)

Another problem is the IETF standardizes Internet protocols, not techniques for
doing things. A lot of anti-spam techniques have no protocol component, and
thus are not eligible for standardization. Just as one example, the technique
of whitelisting originators that appear in a user's address book is a local
matter that has no obvious protocol component.

Of course this doesn't mean informational RFCs couldn't be written. But we're
talking about standardization here, not RFC publication.

All that said, the IETF does have a substantial bias that impedes the adoption
of many of the anti-spam techniques I see mentioned on various lists: The IETF
is a lot happier when someone walks up with a reasonably complete specification
for whatever it is they want to do and then stands behind that specification.

Coming in with the equivalent of jottings on a napkin, or suggesting
substantive changes to someone else's work that substantively change the
character of that work, are not going to be welcomed unless the work has clear
and immediate utility.

And why should they be? It takes a lot of effort to get something onto the
standards track. (MIME took many hundreds of hours of Nathaniel's and my time.
I expect EAI took comparable amounts.) Expecting someone else to do all that
work simply isn't reasonable.

If you feel strongly that something needs to be a standard, then you need to
enact the labor necessary to get that to happen.

                                Ned

_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp

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