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 <kaie(_at_)kuix(_dot_)de>
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
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp