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
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.
A (draft) writeup of this idea can be found as a PDF file at:
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.
Find a way to signal contact attempts to the recipient, enabling a user
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
--
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp