ietf-smtp
[Top] [All Lists]

Re: [ietf-smtp] [Shutup] Proposed Charter for the "SMTP Headers Unhealthy To User Privacy" WG (fwd)

2015-12-11 12:03:45
My wife, who is a good web designer but not particularly conversant in mail
headers, gets her mail service from a web hosting provider.   They have been
doing a perfectly adequate job.   She has her own domain.   If they start
sucking, she can switch to Google, or have me operate her mail service, or 
take
some other option.   She is not locked in.

So the solution is for everyone to get their own domain, so their address
is portable? 

I'm sorry, but this is nothing short of delusional.

I've lost track of the number of times I've patiently explained to someone 
that
their problem was the result of crap service from their provider. I can 
count
on the fingers of no hands the number of times this has resulted in them
changing providers.

Right, you've been providing them with free support.

And once again you have demonstrated that attempting to have a sensible
discussion with you is a total waste of time. 

Rather than acknowledge the demonstrable reality of provider lock-in,
you start strawmanning and moving the goalposts around.

I never said I provided anyone with anything resembling a substitute
for the support their ISP/MSP should have provided. I never even implied it.

Since you seem to be big on anecdotes, here are a few of my own:

Q. "Hey Ned, I'm having problems again sending to the X list you maintain.
   Why didn't it get through?"

A. (After checking logs.) "Because your provider botched their DNS setup and
   attempts to validate your message failed, resulting in a temporary error
   your provider apparently interpreted as permanent. I can't fix this and it's
   the fifth time it's happened; you need to switch to a better provider."

--

Q. "Hey Ned, you never sent me the stuff I asked for. Why?"

A. "I sent it; it bounced because your mailbox is full and I couldn't tell you
   what happened because, well, your mailbox is full.

Q. "What does "mailbox full" mean and how do I fix it?"

A. (30 seconds of googling.) "Your mailbox is full because your quota looks to
   be about 1/100 what modern email systems typically provide. You need to
   switch to a provider with reasonable quotas."

--

Q. "Hey Ned, I'm no longer getting mail from the Y list you maintain. What's
   going on?"

A. "I had to remove your address from the list because everything I sent to
   it bounces with a completely nonspecific error. You'll need to talk to
   your provider and find out what's going on. It's possible it's a problem
   on my end, but I can't fix it unless I know what it is."

Q. "OK, I called them and after an hour on the phone they say they don't know
   why it is happening and they can't do anything to fix it. What now?"

A. "Well, absent some kind of explanation of why they are rejecting the
   message, there's nothing I can do. You might want to consider switching
   to a provider that actually provides assistance when you call."

None of those people have switched providers. All of them continue to 
have problems with their current providers.

Why would they switch?

Oh, I don't know, maybe because their ability to send and/or receive mail
reliably has been severely compromised by their provider and there's nothing
anyone else can do about it?

This is precisely my point.   You are their service provider, and you are
protecting them from the hassles they would otherwise endure at the hands
of their nominal service provider.

Except that I'm not. I can't possibly perform the function, and the cases
where I've actually been able to solve a problem for somebody, as opposed to
telling them what the problem is, are so rare as not to matter.

If you could no longer provide the help you have been providing because we
closed down this privacy loophole, they would suddenly have some clarity about
their situation, and maybe take action to do something about it.

Seriously? You actually think eliminating my currently nonexistent use of this
privacy loophole to provide an alternative support channel for people I know
would actually convince someone to switch providers? When the actual issues
they are demonstrably willing to live with are vastly more serious?

And you could provide them with really good advice on how to do that in a way
that avoids them being locked in again to their next mail service provider, if
that provider should turn out to suck.

Right, so that instead of dealing with mail providers they'll instead be
dealing with a domain provider - a space I personally have considerable trouble
navigating?

In an ideal world, maybe. But here in the real world we have to take factors
like provider lock-in into account in assessing these tradeoffs.

I don't think that we should design protocols to account for provider
lock-in.

If we were designing protocols here I would say that it would make sense to
at least try to design things to make it harder for lock-in to happen.

But we're not designing protocols here. We're talking about advising
and/or tweeaking existing protocols, once which are deployed at vast
scale and which are highly constrained in a bunch of different ways.

A very different thing.

                                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>