Subject: Change the mailing list protocol, not DMARC.

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 7 Jun 2014 08:40:50 -0400

On Sat, May 3, 2014 at 2:08 PM, Hector Santos <[email-masked]> wrote:

> Let me ask, what if a fedex.com employee use this email domain for
> subscribing to the IETF list?

Any subsequent problems are irrelevant unless FedEx, the owner of
fedex.com considers them to be relevant.

That is what folk complaining don't get: you don't have the right to
use your employers email or a public email provider's email any way
you want. The domain name owner makes the rules.

As Craster insists: My domain, my rules.

If you want to make the rules then get your own domain. I think that
is something most IETF participants know how to do.

In the medium term, lets kill the stupidity of mailing lists with a
protocol that works. NNTP was originally designed to replace mailing
lists. It actually works quite well at that. The only problem was the
IT-Dictator mindset that underlies it: newsgroups have to be approved
by the Commune!

The idea that newsgroups work by the mail client PULLING a list of
unread messages and then PULLING those that are to be read is the best
architecture for newsgroups.

I am currently using 8Gb of my primary Gmail account space, 80% of
that is my mailing list mail. Google and Yahoo could both save tens of
millions of dollars worth of hard drives a year with a better
protocol, thats incentive to invest.

The only points that need to change are the mailing list programs need
to offer a very simple network API and the clients need to accept it.
The second is not so difficult to deploy for the 90% of webmail users.

---

From: [email-masked] (Martin Rex)
Date: Wed, 11 Jun 2014 19:00:04 +0200 (CEST)

Phillip Hallam-Baker wrote:
> Hector Santos <[email-masked]> wrote:
>> 

Strange concept!

Does your jurisdiction allow your landlord to interfere with
postal/snail mail that is delivered from or to your rented appartment?

And unless your jurisdiction is hopelessly outdated, the same
rules ought to apply to interference with telecommunications.

> IT-Dictator mindset that underlies it: newsgroups have to be approved

Set up your own mail2news gateway.

/usr/lib/aliases  http://www.tldp.org/LDP/nag/node213.html
main2news script  http://www.sirlab.de/linux/descr_m2n.html

-Martin

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 12 Jun 2014 08:47:27 -0400

> postal/snail mail that is delivered from or to your rented appartment?

Absent specific government action to protect the tenant, the landlord can
abuse them in almost any way they choose. Which is why we have voluminous
legislative protections for tenants. There is an entire field of law
concerning that.

The reason that is necessary is that the alternative to renting is very
expensive and requires a large amount of capital. But if houses were $6
then it would be perfectly reasonable for society to tell tenants that they
are on their own because they should become freeholders.

> main2news script  http://www.sirlab.de/linux/descr_m2n.html

My point is that mail is an old protocol and people who expect that it can
be kept going unaltered in its original form serving all the purposes that
it was never designed for but have emerged over time are going to be upset
no matter what.

Spam is an attack. The people who send spam are hardened criminals who have
murdered at least two people in the past five years. It is futile to expect
that the mail system can continue to operate without changes.

The major ISPs can and will and SHOULD consider the interests of the
majority of their customers as they move forward. If they don't, open email
systems based on SMTP will go the same way as USENET and die because people
don't want to put up with them any more.

The possibility that SAP might force you to subscribe to IETF lists through
a different address does not worry me in the slightest. That is not one of
the uses of email that I consider any sort of priority. I am quite happy
making you change your mail config.

But looking further ahead, it is becoming clear that maintaining mailing
list capabilities is going to become increasingly difficult in the face of
escalating anti-spam controls. Which is why I suggest that rather than the
IETF community reacting to DMARC by refusing to consider any change that
inconveniences members of its club, IETF instead designs a protocol that
addresses the actual needs.

In the SMTP/IMAP model the message is pushed to the sender outbound MTA,
pushed to the receiver outbound MTA and pulled by the client from the
outbound MTA.

The SMTP/IMAP model is thus PUSH/PUSH/PULL

The model of NNTP and Dropbox and many of the blogging comments apps is
PUSH/PULL/PULL. That is a message pattern that we can and should support in
IETF protocols. Because when someone is sending 10Gb of data, the PUSH/PUSH
model is not viable. Better to leave that data siting on the outbound
server rather than have it clog up hundreds of inbound servers and sit
unread.

US6192407 has a priority date of Oct 24, 1996, now would be a good time to
work on such a protocol.

---

From: Dave Crocker <[email-masked]>
Date: Thu, 12 Jun 2014 16:19:48 +0200

> My point is that mail is an old protocol and people who expect that it
> can be kept going unaltered in its original form serving all the
> purposes that it was never designed for but have emerged over time are
> going to be upset no matter what.

This is a variant of the usual refrain, over the last 20 years, about
dealing with some limitation or other to email.  It goes along the lines
of "We need to throw out SMTP and start over."

To this and the above I have my own usual refrain:

     There will come a point at which SMTP (or IMAP, or the email object
or...) do need to be replaced.  An appropriate procedure for deciding
when that point has been reached needs to be:

     1.  Get community (rough) consensus about the non-technical
characteristics for the functional change; that is, agreement about what
the community wants to do with/for email that it cannot currently do.

     2.  The email technical community has been successfully making
enhancements to the same continuously running end-to-end service for
30-40 years (depending upon how one counts); so give it a chance to find
a way to incrementally improve the existing service to support whatever
is needed.

     3.  When the technical community fails, it will be time to develop
the relevant protocol/format/whatever.

On the average, those calling for replacing SMTP (or whatever) have been
stopped at the first step.

Someday, they won't be.

But until then, meta-declarations about needing to replace Internet Mail
(or any other existing Internet service) don't have much practical purpose.

d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: John C Klensin <[email-masked]>
Date: Thu, 12 Jun 2014 10:50:19 -0400

--On Thursday, June 12, 2014 16:19 +0200 Dave Crocker
<[email-masked]> wrote:

>> My point is that mail is an old protocol and people who
>> expect that it can be kept going unaltered in its original
>> form serving all the purposes that it was never designed for
>> but have emerged over time are going to be upset no matter
>> what.
> 
> This is a variant of the usual refrain, over the last 20
> years, about dealing with some limitation or other to email.
> It goes along the lines of "We need to throw out SMTP and
> start over."
> 
>      There will come a point at which SMTP (or IMAP, or the
> email object or...) do need to be replaced.  An appropriate
> procedure for deciding when that point has been reached needs
> to be:
>...

FWIW, +1 to Dave's "usual refrain".
The other three things that occurred to me when reading the "old
protocol..." statement were:

(1) "kept going unaltered in its original form..." has rarely
been the expectation and, indeed, many changes have been
successfully introduced to deal with evolving needs.

(2) One of those changes --support for remote body parts-- was
incorporated into MIME in its very first version and contains
most of the mechanism needed to support what I understand PHB is
recommending for PUSH-PULL-PULL.  It has been implemented in
several places but has gotten very little traction in the mail
sending and receiving community.  IMO, it ought to be incumbent
on anyone proposing a different "get notification, then retrieve
mail from server" model explain why their ideas will be more
successful than that 20-odd-year-old MIME mechanism.

(3) Even though adjustments have been made to deal with changing
knowledge and needs, we have been using the old, Newtonian, view
of mechanics for circa 300 years, not merely 30 or 40.  Perhaps
the argument for dumping old things because not every issue and
bit of future knowledge was originally designed into those
laws/theories should be used to dump them too.  Perhaps they
should even have been dumped in the middle of the 19th century
before relativity and quantum theory came along.

Final Ultimate Solution to the [Alleged] Email Problem (FUSAEP)
anyone?

    john

---

From: Ted Lemon <[email-masked]>
Date: Thu, 12 Jun 2014 11:04:56 -0400

> (or any other existing Internet service) don't have much practical purpose.

On the contrary, they keep us thinking about it and trying to envision different ways of solving the problem.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 12 Jun 2014 11:18:24 -0400

On Jun 12, 2014, at 10:50 AM, John C Klensin <[email-masked]> wrote:
> IMO, it ought to be incumbent

Implementing this 20-year-old MIME mechanism would be very difficult, would have limited potential payoff, and would be pretty obviously privacy-violating.   And in order for it to do any good, recipients would have to refuse large attachments.   So there really isn't a viable transition path from what we have now to this, and if we had this, it would make things a lot worse in some respects, and make things better in almost no respect.

This functionality is very similar to the behavior of modern MUAs that will fetch images in email messages given the URL, which is in ubiquitous use as a way of bugging mail recipients to see if they actually read the message.    I disable it in my MUA.

Point being, the fact that this technology hasn't taken off is no indication of a lack of demand for the technology PHB was describing.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 12 Jun 2014 12:16:45 -0400

> of "We need to throw out SMTP and start over."

No, not quite. Think of it as we have a dying patient on the operating
table and we are going to amputate parts to keep them alive, replacing them
with prosthetics as we go.

Eventually the prosthetics will take over and we can replace the head. But
thats not where we are starting.

> (or any other existing Internet service) don't have much practical purpose.

In the AI community they like to talk about problems being AI-complete,
that is if you can solve that problem you can solve all AI problems.

Pointing out that an approach is less likely to succeed than replacing some
of the email infrastructure seems a useful approach to me.

We do in fact have emergent quasi-mail systems including Dropbox like
things and blogs with subscriptions to comments that don't really fit well
in the email infrastructure either. My proposal was not to replace the
email core, it was to design a purpose built protocol for things email has
always done rather badly.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 12 Jun 2014 12:33:29 -0400

> successful than that 20-odd-year-old MIME mechanism.

In a word - WebMail.

Updating mail clients is a long and tedious process so it is not surprising
that updates take a lot of time to percolate through. It was 5 years after
the initial deployment of MIME before mail clients to support it became
common. And the first of those that did were actually combined mail/NNTP
readers.

WebMail is a much more fluid environment. A change in the specs can be
pushed out to half the mail userbase very quickly. With DKIM we saw changes
pushed out to around a tenth of the mail user base in a few hours.

All it would take to make a change stick is to up update mailman and a few
other mailing list managers and get buy in from the companies that are
pushing DMARC. And the proposal would save them a lot of money because they
would only need to pull and store data once per list rather than for every
subscriber they support.

I don't read all my mail in Webmail, but I read all my mailing list mail in
WebMail.

> before relativity and quantum theory came along.

Actually Newton made the exact same arguments as Einstein concerning
relativity. The only difference was that Newton concluded that the speed of
light must be infinite which was consistent with the empirical observations
possible in his day.

The starting point for this discussion was that people claimed that DMARC
would cause a loss of email functionality that really matters. There are
thus three possible outcomes:

1) Google and Yahoo abandon use of an important anti-spam tool because the
ability for anyone to send mail from a domain from anywhere they choose
really matters.

2) Google and Yahoo continue use of an important anti-spam tool they have
developed and deployed because said ability does not matter enough.

3) The IETF community develops a new protocol that meets the needs that
will be negatively impacted by DMARC.

Now I think it abundantly clear that arguments in favor of 1 have lost
already and should lose. So we are really arguing between choice 2 or 3.

---

From: Miles Fidelman <[email-masked]>
Date: Thu, 12 Jun 2014 15:03:13 -0400

Phillip Hallam-Baker wrote:
>
>
>
> On Wed, Jun 11, 2014 at 1:00 PM, Martin Rex <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     > Hector Santos <[email-masked] <mailto:[email-masked]>> wrote:
>     >>
>     >> Let me ask, what if a fedex.com <http://fedex.com> employee use
>     this email domain for
>     > fedex.com <http://fedex.com> considers them to be relevant.
>     >
> Absent specific government action to protect the tenant, the landlord 
> can abuse them in almost any way they choose. Which is why we have 
> voluminous legislative protections for tenants. There is an entire 
> field of law concerning that.
>
>
Though, in the case of mail, it's Federal law that prevents "mail 
tampering" and other unauthorized interference with US mail.  I'm not 
100% sure, but I expect that an employer might not be legally allowed to 
interfere with a letter addressed to you, at your workplace.

When it comes to email - there are (or at least used to be) the Email 
Privacy Act - which forbid employers from reading your mail, in the 
absence of a clearly stated policy that reserved the right to do so.

Miles Fidelman

-- 
In theory, there is no difference between theory and practice.
In practice, there is.   .... Yogi Berra

---

From: Miles Fidelman <[email-masked]>
Date: Fri, 13 Jun 2014 07:55:25 -0400

Stephen J. Turnbull wrote:
> Phillip Hallam-Baker writes:
>
>   > My point is that mail is an old protocol and people who expect that
>   > it can be kept going unaltered in its original form serving all the
>   > purposes that it was never designed for but have emerged over time
>   > are going to be upset no matter what.
>
> True, as far as it goes.  However, there is need for a push protocol
> that allows you to receive contacts from authors you don't know yet,
> in other words, a medium that is designed to be flexible enough to
> accomodate new modes of communication.
>
> It's not obvious to me that this need can be satisfied while at the
> same time denying spam.  If it is indeed impossible, I don't see why
> that purpose can't continue to be served by email, while most mail
> (which is correspondence among acquaintances) gets redirected into
> authenticated channels.
>
Just a quick reminder here:  Postal mail is still going strong, after 
100s of years.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 13 Jun 2014 08:18:03 -0400

>>  Just a quick reminder here:  Postal mail is still going strong, after
Only because we haven't got email security properly sorted.

I can't remember the last time I received a real letter. All I get is junk
mail and bills. And the bills arrive because we haven't got the standards
for doing it electronically established yet.

Within a decade postal mail and the telephone will have become as
functionally obsolete as fax. It will take a lot longer for them to
disappear, the telegram only stopped last year, about a hundred years after
it was utterly obsolete.

The postal service will continue of course until Bezos works out how to get
his drones to work.

Technology does change over time. There is a very clear demand for an open
Dropbox like solution. There is a clear need for a protocol that allows
email like subscriptions to blog comments without the mailbox clog that
results.

---

From: Tony Finch <[email-masked]>
Date: Fri, 13 Jun 2014 14:41:59 +0100

Ted Lemon <[email-masked]> wrote:

On external body parts:

> Implementing this 20-year-old MIME mechanism would be very difficult,
> would have limited potential payoff, and would be pretty obviously
> privacy-violating. And in order for it to do any good, recipients would
> have to refuse large attachments.

In practice message size limits are typically a few dozen MB, and people
hit this frequently enough for it to be annoying. They also have problems
with security restrictions on attachment file types.

So a number of sites have implemented systems which strip large
attachments, put them on a web server, and modify the message to include a
link to the detached file.

https://fileexchange.imperial.ac.uk/

http://fluff.bris.ac.uk/fluff/

https://webdropoff.auckland.ac.nz/

http://turin.nss.udel.edu/wiki/dropbox/doku.php

etc.

BUT! These systems do not use the MIME external body mechanism, because it
is common for mail servers to reject these messages on the grounds that
they are too difficult to properly scan for viruses.

The end result is something pretty simiilar to MIME external bodies, but
a complete mess from the protocol architecture point of view.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Lundy, Fastnet: Variable, becoming north, 3 or 4. Slight or moderate. Fair.
Good, occasionally moderate.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 13 Jun 2014 09:51:03 -0400

> a complete mess from the protocol architecture point of view.

Ouch.   Yet another reason why a flag day may be necessary to improve the situation.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 13 Jun 2014 10:59:32 -0400

> Ouch.   Yet another reason why a flag day may be necessary to improve the
Now I will note that this is the sort of use of mail that people think we
can fix and that the only difference between this use and the ones people
think we can't change is where they got invented and by who[1].

What really needs to happen is that the external body mechanism needs to be
integrated into the virus scanning mechanism and both have to support use
of digital signatures so that senders can be appropriately whitelisted.

At the moment the mail systems make no distinction between someone outside
my company sending me a ZIP file and me sending a ZIP file to my engineers.
That is due to the mail protocols being defective.

Maybe the value of DMARC lies in that it will impose some pain on the
community that has the ability to make changes to the mail system for a
change.

[1] Strictly speaking it 'should' be whom but I think that particular word
has been de facto deprecated.

---

From: Tony Finch <[email-masked]>
Date: Fri, 13 Jun 2014 16:03:42 +0100

> That is due to the mail protocols being defective.

No, that's poor configuration by your postmasters. It's straightforward
and quite common to configure distinct security policies for internal and
external mail, based on whether the message arrived via your submission
service or your MX service.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Humber: Northwest, veering northeast, 3 or 4. Smooth, becoming slight or
moderate. Fog patches for a time. Moderate or good, occasionally very poor.

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Fri, 13 Jun 2014 09:11:48 +0900

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 13 Jun 2014 12:57:56 -0400

> service or your MX service.
Actually it is quite a bit more complicated than that and has to do with
being a security company and the difference between what we think is
correct and what we can prove to our auditors at reasonable cost.

---

From: Miles Fidelman <[email-masked]>
Date: Fri, 13 Jun 2014 14:06:18 -0400

Phillip Hallam-Baker wrote:
>
>
>
> On Fri, Jun 13, 2014 at 7:55 AM, Miles Fidelman 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>         expect that
>     Just a quick reminder here:  Postal mail is still going strong,
>     after 100s of years.
>
>
> I can't remember the last time I received a real letter. All I get is 
> junk mail and bills. And the bills arrive because we haven't got the 
> standards for doing it electronically established yet.

Bills are "real" - they're transactional.  So are checks.  Some of us 
actually do things like send proposals, signed contracts, and so forth.  
And, of course, packages.  And the higher the value, the more likely 
that they'll be sent via physical mail.  It ain't going away anytime soon.

Miles Fidelman

---

From: Joe Abley <[email-masked]>
Date: Fri, 13 Jun 2014 20:02:14 -0400

On 13 Jun 2014, at 7:55, Miles Fidelman <[email-masked]> wrote:

> Just a quick reminder here:  Postal mail is still going strong, after 100s of years.

I don't know what it's like where you live, but here the only thing that is keeping the post office afloat is being paid by advertisers to deliver unsolicited junk.

"Canada Post has hiked postal rates for regular mail and plans to cut up to 8,000 jobs as it phases out urban mail delivery over the next five years -- all in a bid to reverse the tide of red ink at the money-losing Crown corporation."

"The Crown Corporation predicted this year that Canada Post and its subsidiaries would lose $274 million before tax in 2014."

"Still going strong" is not a phrase that resonates with me.

Joe

---

From: John C Klensin <[email-masked]>
Date: Sat, 14 Jun 2014 02:48:38 -0400

--On Friday, June 13, 2014 10:59 -0400 Phillip Hallam-Baker
<[email-masked]> wrote:

>...
> What really needs to happen is that the external body
> mechanism needs to be integrated into the virus scanning
> mechanism and both have to support use of digital signatures
> so that senders can be appropriately whitelisted.

And what property of external bodies do you believe would
prohibit implementing external bodies so that incoming material
is buffered and scanned for viruses (and whatever else one wants
to scan things for) the same way any local body part/ attachment
scanned?  Or extending the external body mechanism to support
signatures -- either in the form of verifying that a signature
or hash in the message matches one taken over the external body
or an option and check on a signature attached to the external
body.

Seems to me that, at worst, all either would take would be
defining of a new access type (see Section 5.2.3 of RFC 2046)
that would make some material in the phantom body mandatory to
pay attention to if present.

Not exactly the sort of radical, earthshaking, change that
justifies a claim that the mail system needs to be replaced.

    john

---

From: Dave Crocker <[email-masked]>
Date: Sat, 14 Jun 2014 09:14:51 +0200

On 6/12/2014 6:33 PM, Phillip Hallam-Baker wrote:
> On Thu, Jun 12, 2014 at 10:50 AM, John C Klensin <[email-masked]
...
>     successful than that 20-odd-year-old MIME mechanism.

This is a classic confusion between software implementation and
operation, vesus networking architecture.

Webmail is nothing more than a particular style of user interface,
integrated into the operations of a particular service.  25-30 years
ago, Einar Stefferud labeled this a "split UI" mode, since part of the
mail user interface runs on the user's platform and part runs on the
server's.  It uses whatever homegrown UI-to-UI protocol the local
operator chooses, but otherwise is nothing but classic Internet Mail
architecture.

It's a useful operating mode, within its limits, which typically
includes requiring full-time connectivity.  As good as user access to
the Internet often is, requiring it all the time, for doing email, is a
pretty serious limitation.

More importantly, it isn't interoperable, in the sense we use the term
in the IETF, since it locks the user into the service provider for
literally everything.

There's no user ability to have a different MUA, different email
storage, different address book, different anything.   By having things
locked into the recipient's own email service provider, there is no way
to distribute out enhancements.

So, for example, there is no way for the /author/ to declare an
attachment as being located somewhere else.

> Updating mail clients is a long and tedious process so it is not
> surprising that updates take a lot of time to percolate through. It was
> 5 years after the initial deployment of MIME before mail clients to
> support it became common. And the first of those that did were actually
> combined mail/NNTP readers.

Truly distributed networking architecture certainly does carry costs,
including costs and delays of making changes.

But we've had a highly siloed world before the Internet and we didn't
much like sticking to it.  That we've moved back to it for many services
is convenient for providers to control their market (and, yes, quickly
provide new features) but it has made the user's world notably more
complex and often less interoperable.

Consider the issue, the next time you want to send someone an instant
message.  Do you send it via SMS, google, facebook, yahoo, skype or --
oh yeah -- aol?  That's a really prime example of the derivative effects
of excessive integration witha provider: combinatorial explosion rather
than seamless Internet integration.

And the view that it is sufficient to have a client which integrates all
the heterogeneous services into a single user interface misses the
operational complexities and lack of interoperability they are living with.

> I don't read all my mail in Webmail, 

Why not.  If it's so wonderful, then why isn't it being used for all
your email?

d/

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 14 Jun 2014 10:01:32 -0400

On Sat, Jun 14, 2014 at 3:14 AM, Dave Crocker <[email-masked]> wrote:

> integrated into the operations of a particular service.

It is the mode used by the majority of mail users today. Which makes it
rather more than just technology from a deployment point of view.

Of course WebMail is simple, I implemented a version of Webmail in 1993. It
took me less than a week to get it running. Would have taken me a day if
not for the fact that I found the POST method was broken. So it was the
first version of WebMail to be able to send mail.

And yes I am aware of the patent lawsuit. That is why we got into the whole
history bit.

> pretty serious limitation.

Yes, I invented it and I didn't use it until Gmail launched. WebMail is
only useful with high bandwidth links.

But if you are looking to change the mail system those limits are
irrelevant as they don't stop people using it.

> in the IETF, since it locks the user into the service provider for

Umm, how do you work this one out? I am using gmail right now with my
[email-masked] address.

> storage, different address book, different anything.

Perhaps you should look at something before you speak about it. You are
completely wrong about all of those. In fact most MUA these days have
specific handling to integrate with gmail, yahoo, etc.

> By having things

Software authors have been declaring IETF approved features junk and
refusing to implement them for years.

The fact that the mail providers don't snap to attention and implement a
feature because it is agreed by an IETF committee does not mean that they
will never implement it. Who proposes the feature and what they do to get
it deployed makes the difference.

Another thing that makes the difference is time and situation. I invented
WebMail in 1993 but Gmail didn't launch till 2004. And it was the
combination of high bandwidth, generous storage allowances and the fact
Javascript no longer crashed after three seconds that made modern WebMail
possible.

> than seamless Internet integration.

Well maybe the reason that problem hasn't been addressed is that too many
people take notice of the people whose only function is to tell them that
something can't be done, won't work, etc.

It was thirty years from the start of project Xanadu to the birth of the
web. Plenty of people thought it impossible

> Why not.  If it's so wonderful, then why isn't it being used for all

Same reason that I use Linux, Windows and Mac every single day. Same reason
I have three different home automation systems in my house. Same reason I
just bought a 3D mill kit despite the fact that there is a CNC Mill and
Lathe in the basement already.

I don't want to become a technological fossil who is clinging to some
obsolete tool that the market passed by long ago. This is a technology
business, if you want to contribute you have see what is happening in every
part of it.

---

From: Miles Fidelman <[email-masked]>
Date: Sat, 14 Jun 2014 10:40:22 -0400

Phillip Hallam-Baker wrote:
>
> On Sat, Jun 14, 2014 at 3:14 AM, Dave Crocker <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     > On Thu, Jun 12, 2014 at 10:50 AM, John C Klensin
>     <[email-masked] <mailto:[email-masked]>
>     ...
> It is the mode used by the majority of mail users today. Which makes 
> it rather more than just technology from a deployment point of view.

That's almost certainly not true, or it's certainly highly questionable.

Two words:
1. Outlook
2. Smartphones

---

From: [email-masked]
Date: Sat, 14 Jun 2014 07:42:09 -0700 (PDT)

> 2. Smartphones

Some data to support this conclusion:

   http://emailclientmarketshare.com/

				Ned

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 14 Jun 2014 11:26:36 -0400

On Sat, Jun 14, 2014 at 10:40 AM, Miles Fidelman <[email-masked]

> That's almost certainly not true, or it's certainly highly questionable.

Well it all depends on whether you measure users or uses. People who use
mail a lot are more likely to use a dedicated client.

But from a deployment point of view smartphones are and always will be
limited lifetime devices because of their mode of use. If Apple adds a new
feature today, 90% of the Apple smartphones in regular use will support it
in three years. Because even if development of phones stops, any device you
carry with you every day is going to see a lot of wear and tear.

But even taking this as a given, it seems that every time that I go to a
blog with a comments form on using my iPhone the provider is trying to push
a 'stream reader' app at me. It might be that these people will only push a
proprietary app but I think it likely that they would be interested in an
open standard if one was on offer.

You may be right of course that change is impossible, it is certainly
difficult. But it does have a better chance of achieving the desired goal
of a decent discussion mechanism that supports the desired capabilities,
access modes, etc. than sitting in the sea and bidding the DMARC tide turn.

---

From: Alessandro Vesely <[email-masked]>
Date: Sat, 14 Jun 2014 17:30:36 +0200

> to distribute out enhancements.

I agree with Dave on this point.  His note is especially meaningful
in this thread, because Phillip started it noting that:

On Sat 07/Jun/2014 14:40:50 +0200 Phillip Hallam-baker wrote:
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf/kvU9-WN7AASUAUpfUCpc__LpLGE
>>>> As Craster insists: My domain, my rules.

That is the sort of reasoning which is often heard about social
networks, sometimes culminating with someone observing that we should
devise a protocol for generic social sites, so as to avoid being at
the mercy of the provider of the day...

Specifying a protocol is only useful inasmuch as it allows to swap
the underlying implementation.  Webmail, for example, can be
implemented locally using an IMAP backend (e.g. Mailpile).

The issue at hand originates from the fact that protocols, by
definition[1], cover the mechanics rather than the semantics.  DMARC
attempts to ensure the authenticity of an identifier, whose semantics
should provide for accountability.  So, while its enforcement depends
on the ability of receivers to reject (with "considerable care"[2])
its impact and semantics are still left to the community.  Some sort
of training is appropriate, but IETF's voice doesn't seem to be much
heard outside of a restricted circle, which is one of the reasons why
I proposed an online demonstration.

Ale

[1] thread starting in:
 http://www.ietf.org/mail-archive/web/ietf/current/msg71257.html
my observation on semantics was in:
 http://www.ietf.org/mail-archive/web/ietf/current/msg73752.html

[2] http://tools.ietf.org/html/rfc5321#section-7.9

---

From: Dave Crocker <[email-masked]>
Date: Sat, 14 Jun 2014 20:06:28 +0200

> rather more than just technology from a deployment point of view.

This appears to be claiming that popularity alters whether something is
'technology' or 'architecture' or the like.  For the point I was making,
market penetration statistics are irrelevant.

(There seems to be some confusion in the meaning of the term webmail.  I
have a guess about it's basis later in this note.)

What makes a difference to architecture is architecture.

Webmail is merely a classic centralized time-sharing server approach to
email service, the same as we had from the 1960s (for standalone email
service) and early 1970s (for networked email).  It's prettier and
faster, and perhaps a bit more functional, but architecturally it is
identical.

At base, the term is for marketing siloed email operations that are
accessed through a browser.  Marketing terms can be useful, as can the
services they reference, of course, but they don't have much to do with
technical architecture.

> Of course WebMail is simple, I implemented a version of Webmail in 1993.

I made no comment about technical complexity or its absence.

Siloed operation certainly permits simpler decision-making for the
operator and often permits simpler development for the software folk,
and especially faster cycling of enhancements -- though one would be
hard-pressed to call any of the current, major providers' internal
systems simple...

Change requiring multi-administration coordination is inherently slow
and expensive, but it's the only choice when a service truly is global
and, therefore, subject to the consensus (or lack of it) by many
independent organizations.

>     includes requiring full-time connectivity.  
...
> irrelevant as they don't stop people using it.

The changes are limited to that operator.  Sometimes operators do
wonderful things within their siloed environments.

However if you are creating an interoperable change, it no longer has
anything to do with the term 'webmail', since it has to do with open
protocol standards, whereas 'webmail' has to do with accessing a
centralized service, and either with a raw browser or with a proprietary
active agent downloaded as session start.

See RFC 5598, Figure 5.  If there are architectural/technical
characteristics about 'webmail' that are different from an
implementation approach to the MUA then please provide a technical
description.

> [email-masked] <mailto:[email-masked]> address. 

The protocol between the user-side and server-side of the MUA is
proprietary.  The mechanisms for access the message store are (or can
be) proprietary. Same for local access to the MTA.  And best of all: The
user is locked into the operators MUA (as I said before and you missed
responding to.)

My point was not that a proprietary webmail service is unable to
exchange mail with other Internet Mail users, but that the environment
/within/ the webmail service is entirely siloed.  The world of email
evolved to permit quite a bit of choice of operational components, and
webmail services essentially eliminate those choices.

That a user's world is made simpler by having a fully-integrated
operator that downloads the MUA to the browser in real-time is an
obvious and significant benefit for some/many users.  But again, that's
irrelevant to a discussion about email architecture.

> specific handling to integrate with gmail, yahoo, etc.

After 40 years of doing email software, servers and standards, its
richness as a playground for technical innovation and human use remain
impressive to me.  I still find some wonder at what there is to learn
about it.

Or perhaps...

What your note confuses is the difference between being an email
operator that might offer web-based access, versus accessing such a
service through other means.

That is, from what I can tell the confusion here is between "webmail" as
a term referring to an access method for service -- where that term does
have some technical merit, given the split UA -- versus use of the term
to cover all aspects of an operator that offers such web-based access,
which moves the use into purely marketing purposes.  Hence it would
imply that all gmail users are webmail users, which of course they aren't.

Restated:  It's possible that you are using the term to refer to any
tightly-integrated operation of MUA, MS, MSA/MDA, and at least one MTA,
where some users gain access through a web browser.  That's certainly
popular way to use the term amongst non-technical folk.

I'm assuming rather more knowledge and care for technical discussion on
an IETF list.  Here, the term webmail only makes sense when referring to
the web-related portion of some users' access, namely through a browser.

Yes, gmail offers web-based access.  And yes, I access my gmail account
through IMAP and Thunderbird.

But the first fact is irrelevant to the second.  There is nothing about
my access that is "webmail" anymore than it is webmail when I use a
different setting in Thunderbird to access my bbiw.net account -- which
I've been lazy about and haven't added web-based access to -- and get
exactly the same type of service as I get from gmail.  IMAP defines the
service semantics and the nature of the window into the remote email store.

> refusing to implement them for years.

'author' was used in juxtaposition with 'recipient'.  I was/am referring
to message authors, not programmers.

> Well maybe the reason that problem hasn't been addressed is that too
> many people take notice of the people whose only function is to tell
> them that something can't be done, won't work, etc.

Fascinating.  It would be educational to see the documentation
supporting that claim, especially since I thought the driving forces
were customer capture by the operator and a lack of user demand for
integration.

d/

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 15 Jun 2014 08:14:38 +1200

Ned,

On 15/06/2014 02:42, [email-masked] wrote:
...
> Some data to support this conclusion:
[that webmail is not dominant]
>   http://emailclientmarketshare.com/

Hmm. I was curious about what those numbers really measure.
Judging by http://litmus.com/email-analytics, it seems that
they refer to a sample of emails that (a) contained a specific
HTML snippet and were (b) opened as HTML by the clients and
(c) by implication, had been sent via a mailing list. It seems
very likely to me that the sample consisted of spam. I'm
not sure that the numbers reflect unbiased statistics, unless
you're a spammer. In any case they don't indicate how many
people open email in plain text mode (which I alway do if
possible, precisely to avoid embedded code).

That said, they certainly show that one size doesn't fit all.

Does anyone have statistics of POP3 vs IMAP vs split-UI?

    Brian

---

From: [email-masked]
Date: Sat, 14 Jun 2014 13:21:24 -0700 (PDT)

> (c) by implication, had been sent via a mailing list.

Litmus is a service for people who send out bulk mail and want to track
whether or not it's seen, and when it's seen what client is used to see it.

> It seems
> very likely to me that the sample consisted of spam.

Actually, it's unlikely in the extreme. Spammers are into volume, they don't
care about tracking analytics and aren't going to pay a company like Litmus to
perform such a service. But there are a hell of a lot of legitimate bulk email
senders out there who do care about the effectiveness of their mail, and have
the money to pay for such things.

> I'm

Well, I think it's up to you to show that a significant fraction of the
email-reading public prefers to read HTML mail without resolving any of the
links, and that missing out on that fraction significantly biases such data.

> That said, they certainly show that one size doesn't fit all.

Which was the main point.

				Ned

---

From: Brandon Long <[email-masked]>
Date: Fri, 13 Jun 2014 12:13:14 -0700

On Fri, Jun 13, 2014 at 11:06 AM, Miles Fidelman <[email-masked]

>> On Fri, Jun 13, 2014 at 7:55 AM, Miles Fidelman <
>> [email-masked] <mailto:[email-masked]>> wrote:
>>
>  And, of course, packages.  And the higher the value, the more likely that
> they'll be sent via physical mail.  It ain't going away anytime soon.

If I had spam filtering on postal mail that was as good as I've got on
email, regular postal mail would already be gone.

That isn't to say that high value postal mail at FedEx/UPS/etc prices would
be gone, just that current first class mail and daily deliveries would be.

In the US, the USPS is already on rough ground (which isn't entirely due to
failing rates of mail, granted), so "going strong" would not be what I'd
use.  Holding out for another 100 years in some form... maybe.

Brandon

---

From: Eric Burger <[email-masked]>
Date: Mon, 16 Jun 2014 14:13:24 -0400

I also wonder about the accuracy of the numbers. They say Apple’s MUAs command 44% of the email MUA market (iPhone+iPad+MacOS). That seems just a tiny bit high, considering Apple commands 40% of all smartphones, 33% of all tablets, and under 8% of desktops.

---

From: [email-masked]
Date: Mon, 16 Jun 2014 11:22:19 -0700 (PDT)

> I also wonder about the accuracy of the numbers. They say Apple’s MUAs
> command 44% of the email MUA market (iPhone+iPad+MacOS).

> That seems just a tiny bit high, considering Apple commands 40% of all
> smartphones, 33% of all tablets, and under 8% of desktops.

All they are saying that those are the email clients they see accessing the
messages sent by the folks who use their service. This has very little to do
with the phone/laptop  market overall. A lot of people never access their email
from their smart phone or tablet; indeed, there are a fair number who never do
anything "smart" with their phone at all.

Assuming the numbers are actually representative of mobile email use on a
broader scale, at most what they are telling you is that the percentage of
people who actually make use of their phone's capabilities for email may be
higher for iPhones/iPads.

				Ned

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 17 Jun 2014 08:48:40 +1200

Ned,

> the money to pay for such things.

I think I'll avoid stating an opinion about the boundary between
legitimate bulk email and spam, because that would lead to far
too much dissent, pretty much regardless of what I said ;-)

> links, and that missing out on that fraction significantly biases such data.

I believe I am in a tiny, tiny minority by running my email
client in 'plain text' mode unless I receive a message that is
incomprehensible without setting 'original html' mode.

> Which was the main point.

Indeed.

    Brian

---

From: Stephen Casner <[email-masked]>
Date: Mon, 16 Jun 2014 14:33:09 -0700 (PDT)

> incomprehensible without setting 'original html' mode.

I'm with you there.

                                                        -- Steve

---

From: Theodore Ts'o <[email-masked]>
Date: Mon, 16 Jun 2014 19:55:40 -0400

> > incomprehensible without setting 'original html' mode.

Ditto.  But whenver these sorts of discussions come up, it's always
pointed out that engineers don't count when product managers are
making their decisions.  :-(

			- Ted (who is using "mutt" and "offlineimap")

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 16 Jun 2014 21:39:14 -0400

>                         - Ted (who is using "mutt" and "offlineimap")
That behavior might be unusual but the default for Gmail is to not open
embedded images unless a particular sender has been whitelisted for that.

So not at all surprising that Webmail would rank lower on that mode of
measurement.

---

From: John C Klensin <[email-masked]>
Date: Tue, 17 Jun 2014 09:26:53 -0400

--On Monday, June 16, 2014 19:55 -0400 Theodore Ts'o
<[email-masked]> wrote:

>> > client in 'plain text' mode unless I receive a message that
>> > is incomprehensible without setting 'original html' mode.
>> 
>> I'm with you there.
> 
> Ditto.  But whenver these sorts of discussions come up, it's
> always pointed out that engineers don't count when product
> managers are making their decisions.  :-(

To state that differently and perhaps more relevantly, many,
perhaps most, of the decisions about what to offer and support
are not made by product managers but by marketing product
designers who are more interested in whether something
demonstrates well and looks sexy than by, e.g., long-term
usability.   When criteria of those types are used, plain-text
email preferences will always lose, no matter how many of us (or
even non-engineers) prefer them for performance, security,
efficiency, or other reasons.

    john

---

From: Ted Lemon <[email-masked]>
Date: Tue, 17 Jun 2014 09:31:17 -0400

On Jun 17, 2014, at 9:26 AM, John C Klensin <[email-masked]> wrote:
> When criteria of those types are used, plain-text

FWIW, non-flowing, non-indentable plain text is a royal PITA for me when I'm doing document reviews, so I have a lot of sympathy for those product managers.   The idea that indentation and flowable text can have security impacts is kind of sad.

---

From: Tony Finch <[email-masked]>
Date: Tue, 17 Jun 2014 15:12:33 +0100

Ted Lemon <[email-masked]> wrote:

> FWIW, non-flowing, non-indentable plain text is a royal PITA for me when
> I'm doing document reviews, so I have a lot of sympathy for those
> product managers.

It is a pity that Microsoft's refusal to implement RFC 2646 means that the
spec is pretty much unusable. Apple Mail used to support it but has
backed off to formatting each paragraph on one extremely long line.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Hebrides, Bailey: Westerly or southwesterly 4 or 5, occasionally 6 in Bailey.
Slight or moderate. Fog patches at first. Moderate or good, occasionally very
poor at first.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 17 Jun 2014 11:24:17 -0400

> backed off to formatting each paragraph on one extremely long line.

Yup.

---

From: John C Klensin <[email-masked]>
Date: Tue, 17 Jun 2014 11:51:41 -0400

--On Tuesday, June 17, 2014 09:31 -0400 Ted Lemon
<[email-masked]> wrote:

>> email preferences will always lose, no matter how many of us
>> (or even non-engineers) prefer them for performance, security,
> FWIW, non-flowing, non-indentable plain text is a royal PITA
> for me when I'm doing document reviews, so I have a lot of
> sympathy for those product managers.   The idea that
> indentation and flowable text can have security impacts is
> kind of sad.

Red herring, I think.  As Tony pointed out, RFC 2646 is out
there, does work, and few if any of us who prefer plain text
mail to HTML have any problems with it.  When it is necessary,
I'm also willing to give up some convenience for enhanced
security and privacy.

The things that I think have security (or significant
operational) impacts include tracking beacons embedded in
messages to tell the sender (at least) when or if they were read
(privacy problem), embedded large images or text that is
automagically downloaded when the message is opened or earlier
(potential DoS attack), embedded malware and scripts of multiple
flavors even if not intentionally hostile, and so on.

It is probably too bad that Rich Text didn't get and keep
traction for those who want the ability to, e.g., color for
format text without exposing themselves to the risks above (and
others).  It is equally unfortunate that there are not more MUAs
around that can provide a reasonable interpretation of HTML
without following external links (either pull or push) or doing
anything else questionable without significant control by the
user.  But those things didn't happen.  I'd like to believe that
is because there isn't sufficient marketplace demand, but the
"sexy demo" and "designed for people who don't want to have to
either learn or think about their tools" issues at best distort
whatever demand might otherwise exist.

    john

---

From: Scott Brim <[email-masked]>
Date: Tue, 17 Jun 2014 12:38:45 -0400

> flavors even if not intentionally hostile, and so on.

Yes, there are many traps for the average user on a MUA that tries
very hard to look spiffy. I like mutt ... but an alternative is to use
a GUI MUA that where you can keep its behavior conservative.
Thunderbird is not bad at that.

---

From: Hector Santos <[email-masked]>
Date: Tue, 17 Jun 2014 16:55:33 -0400

John, 

We have a multi-portal framework where we all started as text only systems and it's been a moving target as a function of the evolution of the client devices, and it continues to be a moving target.  There is no IETF "webmail" protocol, like we have for SMTP,  POP3, IMAP and NNTP.  If you want more control, you offer online or native frontend/apps, otherwise you only have 822/2822/5322 has a common ground for independent 3rd party hosting client tools.

When internet mail came, a Preserve MIME option was added. It was default off and the sysop had control. Not the user.  All mail was transformed into the native mail storage format, attachment separated. The web ui portal was given view HTML/text only click if the mail was save in preserve mime mode.

When users began to roam using pop3, the pop3 server recreated the RFC x822 mail for the pop3 download.  No WYSIWYG complaints for many years. Operators set the Preserve Mime option on a case by case basis. Some operators with a higher movement of roaming users, wrote scripts to set the option to true. 

As HTML, storage issues declined, more online viewing stripping of harmful HTML or images stuff was added, the Preserve Mime option was eventually provided as a user option. But today, it is still off by default.  That can change in a future ever evolving update. 

We also have Preserve Mime options at the conference, mail, network type storage level. So for some NNTP gated emails or list storage areas,  it's preserved and in others it's clean up as plain text. 

Now today, if you had to do this over all again, what will be done?  Well, it depends. There is good strategy that simple is better, just do it, no user options, or save it for the future, forget about the stuff that was just candy and never used, etc.  Some of the native Mail apps for these smart devices are pretty primitive compared to their PC counterparts. Just look at twitter and these other small footprint, 5% of what you already had reinventions, that are successful.

Nothing hasn't really change but the vendor need to single source these multiple portals. It also depends on how performance is needed. Offloading speeds things up. Web based is stil a lot of overhead. HTML5 and web sockets will give us more feel of a native client.

From an IETF standpoint, probably an I-D for an web-based Mail I/O API, then we can properly call it WebMail.

--
Hector Santos
http://www.santronics.com

> On Jun 17, 2014, at 11:51 AM, John C Klensin <[email-masked]> wrote:
> 
> work,

---

From: John C Klensin <[email-masked]>
Date: Wed, 18 Jun 2014 09:12:01 -0400

--On Tuesday, June 17, 2014 12:38 -0400 Scott Brim
<[email-masked]> wrote:

>> messages to tell the sender (at least) when or if they were
>> read (privacy problem), embedded large images or text that is
>> (potential DoS attack), embedded malware and scripts of
>> multiple flavors even if not intentionally hostile, and so on.
> 
> Yes, there are many traps for the average user on a MUA that
> tries very hard to look spiffy. I like mutt ... but an
> alternative is to use a GUI MUA that where you can keep its
> behavior conservative. Thunderbird is not bad at that.

But not so good at some other things.

<mini-rant>

I use email heavily enough that I'd happily pay a hundred or two
USD a year for something that was optimized for IMAP desktop and
laptop use, that has good MIME support (not just patches on an
earlier approach), that was well-supported and whose design
enhanced or preserved my productivity. Wrt the latter, note that
I'm heavily dependent on IMAP disconnected mode and, like many
others here, have strong opinions about the importance of
controlled handling of HTML messages, controlled handling of
certs, S/MIME and PGP (both OpenPGP and legacy), and support for
other email and IMAP functionality that seems critical.   Now
that it is the middle of 2014, an MUA that didn't have full i18n
(aka "EAI") support wouldn't be worth the cost of conversion.
Perhaps unlike others, I'm a lot less concerned about close
calendar integration or inline support of a wide variety of
media types as long as I can quickly and easily extract body
parts to the local file system, get to them, and open them with
external programs.   Probably some other IETF users are in
similar situations.   But the evidence is that those who are
making product decisions don't believe we constitute a market on
which they can get adequate ROIs, so we periodically end up in
these almost-pointless "where is the action" discussions that
lead nowhere... except back to the conclusions that some people
are more or less happy with whatever they are using and that a
lot of people (who presumably don't deal with the combination of
very high mail volume and the periodic need to work offline) use
some flavor of "webmail".

Sad situation, IMO.
</rant>

     john

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 18 Jun 2014 10:13:21 -0400

On Wed, Jun 18, 2014 at 9:12 AM, John C Klensin <[email-masked]> wrote:

> earlier approach),

..

> . except back to the conclusions that some people

I am still looking for a calendar program written by someone who
understands that there are multiple time zones and that when I travel from
one time zone to another I probably want to get up at different times etc
without having the change affect appointments when I return.

Seriously, is it so difficult for someone to understand that when setting a
recurring appointment it is necessary to be able to specify the time zone
so that the correct daylight savings adjustments are made?

I gave up waiting for those features in Outlook after waiting ten years.
But they do indicate just how 'STUCK' software gets.

I don't know why such obviously necessary features don't get into product
but I am pretty sure the 'security' and 'usability' are the reasons we are
stuck with insecure and hard to use products. Whenever a product group has
a requirement that they aren't up to hacking they will squawk 'security' or
'usability' as the reason.

It is the same here, someone will suggest ending some feature and someone
will pop up saying that it is absolutely essential to keep it going because
it is necessary to support the mail system in Timbuktu which still runs on
DEC10s talking UUCP. And of course the guy who actually lives in Timbuktu
is protesting that they are pretty sure they never had any DEC 10s to start
with and they mostly run Ubuntu.

As for being a low volume mail user, I am currently using 10Gb of my 15Gb
free Gmail allowance. The reason I use Gmail to do my IETF mail is that I
can't wait half an hour for IMAP or POP to sync each time I want to read
mail.

I don't give my work email out nearly as often as my gmail account which
means that I get my corporate email in an acceptable length of time.

---

From: Hector Santos <[email-masked]>
Date: Wed, 18 Jun 2014 11:29:33 -0400

> On Jun 18, 2014, at 9:12 AM, John C Klensin <[email-masked]> wrote:
> 
> ........ But the evidence is that those who are

+1,  it is a very expensive integrated, moving target design issue, especially for smaller operations.  It pays to picky and choose, be conservative with incremental changes, when you already have an established base of differ multi-portal needs.  Honestly, we haven't really had another good top notch integrated IETF technologies RFC that puts it all together ala what RFC1123 (STD3) did for integrated internet protocols application hosting systems.  At that point, the applications developers will have a better handle of what needs to be done.  The mail related RFCs these days written mostly by same usual folks, tend to be overly verbally complex, confusing, ambiguous, too open ended, and if I may say, not always "protocol complete" from an integration standpoint. 

Personally, I use a mix of MUAs, and it's changes depending on what's going on. Right now, relaxing at a pool, with my new iPad mail app. It has absolutely no display rending options that it can see and the other day I wanted to see a message in fix font mode, so I switched over to the web interface with safari, a 1996 web ui design that still works but needs to be streamlined for the new smaller, keyboard less device environments, with lesser real estate to display, less needs to over do it with display options. 

With the INTL stuff,  I'm still catching up to this, but overall, adding functional UTF wrappers around the field displays, etc and this is only being done at the web ui. With the other legacy views, you see the UTF prefixes, etc.

---

From: Miles Fidelman <[email-masked]>
Date: Wed, 18 Jun 2014 11:45:24 -0400

Phillip Hallam-Baker wrote:
> understands that there are multiple time zones and that when I travel 
> from one time zone to another I probably want to get up at different 
> times etc without having the change affect appointments when I return.
>
> Seriously, is it so difficult for someone to understand that when 
> setting a recurring appointment it is necessary to be able to specify 
> the time zone so that the correct daylight savings adjustments are made?
>
> I gave up waiting for those features in Outlook after waiting ten 
> years. But they do indicate just how 'STUCK' software gets.

That's odd - time zones and daylight savings time just seem to work in 
all the calendars that I use -  (including Outlook and my out-of-the-box 
Android smartphone)

>
> As for being a low volume mail user, I am currently using 10Gb of my 
> 15Gb free Gmail allowance. The reason I use Gmail to do my IETF mail 
> is that I can't wait half an hour for IMAP or POP to sync each time I 
> want to read mail.
>
> I don't give my work email out nearly as often as my gmail account 
> which means that I get my corporate email in an acceptable length of time.

Hmmm.... my mailbox alone gets maybe 5000 emails a day - a lot of it 
spam of course, but a lot of list traffic and admin messages (I'm 
postmaster for our system as well as admin for a bunch of email 
lists).   The mail on my laptop client (SeaMonkey) and my smartphone are 
pretty much always up to date, and if I boot my laptop cold, a few 
thousand messages will update within a minute or so.  If it takes you 
half an hour to sync IMAP then you're doing something very wrong.

Miles Fidelman

---

From: Hector Santos <[email-masked]>
Date: Wed, 18 Jun 2014 13:24:34 -0400

> On Jun 18, 2014, at 10:13 AM, Phillip Hallam-Baker <[email-masked]> wrote:
> 
> As for being a low volume mail user, I am currently using 10Gb of my 15Gb free Gmail allowance. The reason I use Gmail to do my IETF mail is that I can't wait half an hour for IMAP or POP to sync each time I want to read mail.
> 

That should only be an issue the first time.  And the only thing that I can see off-hand with pop3 is if the client is not issuing the server update command with is QUIT.  In other words, your device mail app and/or connectivity is dropping rather than gracefully closing then session.  The explicitly issued  QUIT command is the only way the server to know you successful got your mail and can begin some backend marking of reception.

---

From: Mark Rousell <[email-masked]>
Date: Wed, 18 Jun 2014 21:25:17 +0100

On 14/06/2014 16:26, Phillip Hallam-Baker wrote:
> blog with a comments form on using my iPhone the provider is trying to
> push a 'stream reader' app at me. It might be that these people will
> only push a proprietary app but I think it likely that they would be
> interested in an open standard if one was on offer.

I suspect that for the most part they'd only be interested in an open
standard if it could reliably push adverts as part of the content and
generate reliably trackable page views from the adverts.

It seems to me that the re-siloisation of data has been driven by
commercial interests predicated on the hope of profit from
reader/customer lock-in and advertising revenue.

Open standards seem to me to tend in general to be incompatible with
advertising-based commercialisation in this context.

-- 
Mark Rousell

PGP public key: http://www.signal100.com/markr/pgp
Key ID: C9C5C162