ietf-smtp
[Top] [All Lists]

Re: [ietf-smtp] Possible cont4ibution to moving forward with RFC5321bis SMTP

2019-12-30 13:17:58
On 12/30/19 11:34 AM, Laura Atkins wrote:

On 30 Dec 2019, at 16:06, Keith Moore <moore(_at_)network-heretics(_dot_)com <mailto:moore(_at_)network-heretics(_dot_)com>> wrote:

On 12/30/19 10:58 AM, Laura Atkins wrote:


On 30 Dec 2019, at 15:24, Keith Moore <moore(_at_)network-heretics(_dot_)com <mailto:moore(_at_)network-heretics(_dot_)com>> wrote:

On 12/30/19 8:31 AM, Laura Atkins wrote:

30% of email addresses on a marketing list go bad every year. It doesn’t seem that changing email addresses is that problematic.

Of course it is problematic, because any email address that is changed for that reason cannot be used as stable contact info for use between friends and colleagues.    And this degrades the utility of email.

This has been the case since 1999.
So addressing the issue is clearly long overdue.

Why are you assuming no one has attempted to address the issue in 20 years?

I don't assume that at all, and the myriad efforts to address the issue are quite evident.  But I also observe that email delivery, as experienced by casual email users, is still unreliable - to the point that for many people, email is the messaging system of last resort.   But it's also essential enough to have that system of last resort that casual email users have developed lots of ways of attempting to cope with the unreliability.

And yet, I still find Internet standard email fundamentally more functional than every other messaging system out there.  And I think Internet email is fixable, whereas most of the other interpersonal messaging systems appear to me to have fundamental and largely insurmountable limitations that will likely keep them from ever being as functional.

But it's not necessary to survey the literature to understand that spam is a huge problem and that existing solutions are inadequate.

It is necessary to understand why the existing solutions are what they are. You’ve made a host of assumptions that are, quite honestly, disrespectful of the people who’ve been working on this for their entire careers.

I mean no disrespect, and my very purpose in this conversation is to understand the landscape.   But I suspect the political and/or economic landscape is more of an impediment to solving the problem than the technical challenges are.   And that's why, to me, it makes sense to try to understand the political and/or economic landscape before doing a technical deep dive on any particular proposal.

I also observe that the landscape is different now than it was in the late 1990s and wonder if the changing landscape creates new opportunities that did not exist 20 years ago.

Or to explain this a different way - I  have identified roughly a dozen significantly different technical approaches that appear to have not been tried (at least at scale), because most of them are things that would involve changes to the email protocols and/or widespread practice - if they had been tried, it would be evident.

I also know better than to float concrete proposals without doing a lot of technical research first.   But in my experience the political research is even more important.   If a bad idea gets shot down for technical reasons, that's overall a good thing even if it meant some energy was wasted.    But if a good idea gets shot down for political reasons, that's a very bad result, because the good idea can be discredited for decades after the political issues have been forgotten.

So before trying to pitch or defend or even develop technical proposals in detail, I want to understand which of those proposals might land on potentially-fertile ground, and maybe also where the fertile ground is if it exists.

Keith

p.s. I also understand that if any new ideas were found to be helpful, they would be more likely to be complimentary approaches to what exists, than competing ones.


_______________________________________________
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>