Mobile email/teleflip.com blocked (updated)

Update 11-Oct-2007: teleflip.com have contacted us and changed over to using SSL IMAP connections rather than screen scraping web pages, a much better approach to retrieving emails. Thanks teleflip.

I just noticed that one of our web servers was getting noticeably more loaded than the others. After some investigation, I tracked the problem down to a site called teleflip.com. Basically it appears they provide a way to get and send email on your cellphone in the US. A nice idea, but it seems the way they implement at least the “get” part is horrible and unacceptable.

Rather than using standard email protocols like POP or IMAP which are designed to download emails, especially IMAP which lets you download just the important meta-data for emails such as From address, Subject, Date, etc, and then get the parts of an email you actually want, they seem to be logging into our web interface and paging one page at a time through users mailboxes, some of which are 1000’s of pages long.

In fact from our logs, I see that they appear to be logging in for only 8 different users, but appear to be generating over 1,000,000 web requests a day! This is absolutely insane behavior. And to top it off, rather than using a User-Agent field that identifies them as a bot type site, they’re trying to hide themselves as a standard version of Firefox using “Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050518 Firefox/1.0.4″.

Unfortunately because of this activity, I’ve had to block all the teleflip.com IPs (64.74.168.128/25). I don’t intend to unblock them, because using the web interface to scrape email data is completely the wrong approach. They should be using POP or IMAP, and if they had some real sense, they’d use IMAP IDLE to actually get notification of when new emails arrived so they could push just those new emails to your phone.

Until teleflip.com improve their systems, we recommend that you do NOT use them.

For users looking for the best possible mobile email experience, we recommend using ChatterEmail with a Palm Treo. ChatterEmail is a full IMAP client on a phone, including IDLE support to handle push email events. For Windows Mobile users, we recommend looking at FlexMail. It’s not quite as powerful as ChatterEmail, but seems to be the best email client for Windows Mobile phones at the moment.

Posted in Technical. Comments Off

HTML editors and some help testing FCKeditor 2.5

For quite some time now, we’ve wanted to change the HTML editor that the FastMail web interface uses for the compose screen when you’re in HTML editing mode. By default, we’re still using the very old htmlArea, although you can choose to use either Xinha or FCKeditor from the Action menu (you have to switch to text editing mode first to make the change, but then any change you made is sticky for the session, and across logins).

The reason we’ve stayed with htmlArea is that we’ve been waiting for a compelling reason to upgrade. htmlArea continues to work, and while the other HTML editors have been developed and have had features added, they’ve also had additional problems and bugs grafted onto them as well that have in many cases negated the additions.

I’ve been keeping an eye on Xinha and FCKeditor (and also other editors like Tiny MCE), and have been waiting for the right release to upgrade. FCKeditor 2.4 was looking very promising. One of the features I really wanted to use was the new EnterMode option which allows you to control if the Enter key generates either a <br>, a <p> or a <div> tag. This turns out to be surprisingly important because of the way HTML works versus the way people expect WYSIWYG style editors to work.

The problem resolves around two conflicting observations

  1. When people hit Enter, they want the cursor to drop directly to the next line and not leave any vertical gap
  2. When people hit Enter, they expect a paragraph of text to created and treated as a “block” of text for block level formatting items (eg indent, right-to-left display, etc)

The problem is that in HTML, to create a new “block” of text, you use <p> markers around the text. Unfortunately by default browsers includes some vertical spacing between blocks of paragraph text. So if you set EnterMode=p, then when you hit Enter, it does create a new <p> block, but also the cursor moves down what appears to be around 1.5 lines, rather than directly to the next line. Now you can explicitly set the spacing on paragraphs so that it bunches paragraphs directly underneath each other with no gap, but you need to apply that to the whole document, which means that if you reply to existing text that contains <p> tags, those will all be bunched next to each other as well, even if that’s not how the original author intended it and can make it hard to separate out paragraphs. Basically there’s a disconnect between the semantic nature of the HTML and the way it’s displayed.

Going the other way, if you use <br> markers, these don’t create new “blocks” of text, they merely designate points in the big block of text where to insert a line-break. While this might sound fine, it creates problems when you then try and perform actions on blocks of text (eg center, or turn into a list, or change to right-to-left text display, etc). Despite these issues, the fact that inserting a <br> moves the cursor immediately to the next line which is what most people expect, is the reason most online HTML editors use this approach.

The final approach is to use <div> markers. In fact, div markers are an excellent compromise. They do create new HTML blocks making formatting easier, but by default don’t include any extra vertical spacing, so they create the “cursor drops down only one line” effect. Interestingly, the HTML editor in Outlook Express has always used <div> markers when using the Enter key, and in most cases it creates exactly the effect people want.

So when FCKeditor 2.4 added the ability to set EnterMode=div, I thought this was going to be a great solution. Unfortunately it turned out that EnterMode=div was very buggy, making it basically useless in 2.4.

It appears that FCKeditor 2.5 (which is currently in beta testing) has had a lot of work into fixing the text entry and tag generation bugs. I’m hoping that this release will be stable enough to finally replace htmlArea. Additionally FCKeditor 2.5 includes Opera and Safari support, so users of those browsers should be able to do HTML editing in the web interface as well.

I’m hoping people can give the 2.5 beta release a try, and I’ve started a forum thread (http://www.emaildiscussions.com/showthread.php?t=50374) where people can provide feedback so I can get a general sense of good this release is looking.

Posted in Technical. Comments Off
Follow

Get every new post delivered to your Inbox.

Join 5,002 other followers