New sonic.net webmail application

[kgc]

If there is an Archive feature that downloads selected messages into a zip file, I'm on my way.

Currently, you can only save individual messages as ".eml" under the ".../more" action button. I've added this as a feature request.

[joekidd]

Love the new interface. It resolves some issues I was having with the old options, e.g. they didn't support Chrome.

Question: Will you be adding a calendar with it? I didn't see a calendar option.

Joe

[Guest]

You guys who are on dialup and are using any type of GUI are a glutton for punishment. When I was using dialup 1200/2400 bps modems, I was using elm/pine. Those programs are the most efficient in reading mail on limited bandwidth pipes.

[lr]

You guys who are on dialup and are using any type of GUI are a glutton for punishment. When I was using dialup 1200/2400 bps modems, I was using elm/pine. Those programs are the most efficient in reading mail on limited bandwidth pipes.

I agree, and still have (al-) pine set up on my shell machines.

But in this day and age, these readers are impractical for most people, for two main reasons. One, a large fraction of mails shows up formatted in RTF or HTML, and rendering those into ASCII often destroys their readability. Second, to a large extent e-mail has become a file transfer protocol, and the text part of the message is unimportant or even non-existent. Instead, the real content of the message is an image, a PDF file (often a single-page PDF), or an attached file that needs to be handled by a real application (Excel most commonly for me, but also various word processing programs). It is just much more convenient to see the PDF file rendered directly in the mail reader, or be able to double-click on the spreadsheet that's attached directly in the e-mail reader, instead of having to do several manual steps to get it opened up.

The problem is: While we all need (or at least strongly want) the convenience of a GUI-based mail reader, some of us (probably a minority) is at least sometimes in areas where "bandwidth" is very hard to come by. Which is why it is very important to have mail reading applications that use minimal bandwidth on the last leg. And that's the difference between the old and the new web mail readers: the new one is much slower. Don't know whether the issue is the total number of bytes transferred, the number of connections that it establishes each of which may have a large setup latency, or the time it takes the local browser to set up the required scripting.

If I had a spare evening or two, I could exactly measure the network traffic caused by the old and new webmail (I have access to the routers that handle our traffic, and can add statistics gathering to the packet filtering in there). But I'd much prefer to not have to spend that effort, and Sonic get off its customer-inimical position.

[teresab]

I like this new webmail very much (on my Mac laptop).

Can the header and icon menu options strips be made narrower so I see more of the preview pane?

Also, would like to see an answer to lwalsh regarding missing check boxes: (Re: New sonic.net webmail application)

- Is there a way to select messages to (delete, mark, move to new folder, view source, etc.) without actually opening them?

-Thanks

[ajhaig]

I have been deleting them by using ctrl select then delete. they don't open that way.

[Guest]

But in this day and age, these readers are impractical for most people, for two main reasons. One, a large fraction of mails shows up formatted in RTF or HTML, and rendering those into ASCII often destroys their readability. Second, to a large extent e-mail has become a file transfer protocol, and the text part of the message is unimportant or even non-existent. Instead, the real content of the message is an image, a PDF file (often a single-page PDF), or an attached file that needs to be handled by a real application (Excel most commonly for me, but also various word processing programs). It is just much more convenient to see the PDF file rendered directly in the mail reader, or be able to double-click on the spreadsheet that's attached directly in the e-mail reader, instead of having to do several manual steps to get it opened up.

You can download the MIME attachments within pine--at least I could do that when I last used it maybe 20 years ago. Convenience has a price and while I can empathize with those on limited bandwidth, the fact of the matter is if they, including you, want to maximize on efficiency, use pine and scp to get your attachments. Otherwise, you will have to accept the overhead of a GUI client. A GUI client can also be Outlook Express, Outlook, Thunderbird, or Mail (OS X) using the IMAP/POP protocols. I would think the IMAP protocol may be most efficient.

And for people who complain about not wanting to download the mails unless they remove them from the server, that's not how it works if you're using IMAP/POP. The client only downloads the headers for actions and not the body.

Here's the first link I found about email protocols and their efficiency: https://kb.wisc.edu/page.php?id=1535

The problem is: While we all need (or at least strongly want) the convenience of a GUI-based mail reader, some of us (probably a minority) is at least sometimes in areas where "bandwidth" is very hard to come by. Which is why it is very important to have mail reading applications that use minimal bandwidth on the last leg. And that's the difference between the old and the new web mail readers: the new one is much slower. Don't know whether the issue is the total number of bytes transferred, the number of connections that it establishes each of which may have a large setup latency, or the time it takes the local browser to set up the required scripting.

The reason why the new webmail client is slower on dialup links is because of its increased use of AJAX. It mimics a real application where you can drag and stop and stuff like that but there are transfers that happen in the background. The webapp not only receiving data but also sending mouse/key events. Once the uplink--in the case of dialup probably the entire pipe--is saturated, nothing will received in a timely manner because a working uplink is required for TCP/IP's transmission handshake. In most cases, the uplink/pipe is used for the AJAX protocol and TCP's protocol have to wait.

[Guest]

You guys who are on dialup and are using any type of GUI are a glutton for punishment. When I was using dialup 1200/2400 bps modems, I was using elm/pine. Those programs are the most efficient in reading mail on limited bandwidth pipes.

I agree, and still have (al-) pine set up on my shell machines.

Do you often use pine at Sonic? Is there anything special we would have to ask Sonic about, or would just general references on pine be enough to begin using it?

Btw, I do agree with your other points. I'm thinking of pine (etc) for use in abnormal situations.

/ [email protected] - current mailbox [email protected] /

[jpro]

I use the original squirrel mail with my Mac desktop and much prefer it to the new webmail. Here's why:
1. With Safari and squirrel mail, I can see all my read and unread posts on one page and TAB each post to load while I read each one. With the new webmail I am forced to split the screen and can only read one at a time after waiting for it to load. With tabs, each post is viewable in full screen. When I am through reading each post, I simply command/W to close the tab and move to the next one. I would be very disappointed if this capability disappears.
2.In addition to full screen reviewing of read/unread mail, I really like the look of original squirrel mail. I have selected the green background colors (very easy on the eyes) and can choose a larger font for my 65 yr old eyes. I can zoom in with the browser, but why should I have to? I think the new webmail app is a huge step backwards.
3. I couldn't care less about drag and drop. With squirrel mail, I select the topics I want to move to a folder, select the folder from the dropdown, and click move. Works for me.
Please don't take away my squirrel mail!!

[lr]

Do you often use pine at Sonic?

Rarely, bordering on hardly ever.

Is there anything special we would have to ask Sonic about, or would just general references on pine be enough to begin using it?

Log in to shell.sonic.net, say "pine" (the first time I think it puts you through some welcome dialog), enter your password, and you're off to the races.

Part of the reason I use pine rarely is that for me with an IMAP based mail reader, things work reasonably well, even in low-bandwidth situation (our bandwidth/latency at home is highly variable, and can be as good as 2Mbit/s, and when I'm in the office, bandwidth is unbelievably good, and is measured in units of Gbits). I agree that in most cases, IMAP should be a pretty efficient way to handle mail. Although a method like running pine on a machine that's located at Sonic, or the old Squirrelmail system might be more efficient in showing you a list of e-mail subjects (because it only needs to transmit the short text strings of the sender name and subject line over the line, rather than the whole header, but that's not a significant difference).

At home, I use pine against my own IMAP server (our internal server at home contains a separate mail spool served by a Dovecot IMAP server). That's only because I'm too lazy to set up my apple mail to go to that server.

My wife's situation is different. For administrative reasons, she can't use an IMAP-based mail reader on her favorite laptop, she's not a professional computer hack, so pine etc. are not her cup of tea, so for her the web-based mail at Sonic is the perfect compromise. Which is why I am upset that Sonic is removing the efficient (but old) one. While admittedly the new one is much nicer, and has many bells and whistles, the old one works much better over slow links.

I don't see this as a big crisis. Sonic is not the only ISP in the world. It may be the best one, but the second best is likely to be good enough for my needs. I'll give it a week or so, and see whether management at Sonic comes to its senses and reverses the decision to unplug all the old web mail.