3 ms·

I cannot stress enough how difficult it is to build out a complete, working, featureful, not-buggy webmail client. There are tons of edge cases. Roundcube has

I cannot stress enough how difficult it is to build out a complete, working, featureful, not-buggy webmail client. There are tons of edge cases. Roundcube has been around significantly longer than Mailpile. For a lot of people, stability is more attractive than great hair. I'm not pooping on your preference for Mailpile though, which has a much sexier interface than RC's default skin, and I hope the Mailpile guys do well and are around for 10 years. But, saying, "ew, LAMP" is pretty shallow.

alecsmart1 13y ago
Can you enlighten me with some edge cases one might face while building an email app?
- oblio 13y ago
  Anything covering email on a production scale is going to be full of edge cases.
- stevekemp 13y ago
  One obvious one that many people fail at initially is sanitizing any HTML-formatted mail. You don't want viewing the mail to result in an XSS attack against the mail-viewing application, stealing your login cookie for example.
  - mike-cardwell 13y ago
    Both GMail and FastMail have had this vulnerability in the past. GMail had it when script was hidden inside SVGs. FastMail had it when script was embedded in attachment filenames. I'm sure lots of other webmail systems had/have these issues too.
- thaumaturgy 13y ago
  Probably the Roundcube trac would be a good place to start. They've closed 5400+ bugs, feature requests, etc.: http://trac.roundcube.net/query?status=closed&col=id&col=summary&col=status&col=owner&col=type&col=priority&col=milestone&col=resolution&desc=1&order=id http://trac.roundcube.net/query?status=closed&col=id&col=sum... Here are some randomly-selected examples: http://trac.roundcube.net/ticket/1485777 http://trac.roundcube.net/ticket/1485777 http://trac.roundcube.net/ticket/1486166 http://trac.roundcube.net/ticket/1486166 http://trac.roundcube.net/ticket/1489535 http://trac.roundcube.net/ticket/1489535 http://trac.roundcube.net/ticket/1489409 http://trac.roundcube.net/ticket/1489409 I don't have any personal anecdotes, sorry. The couple of very minor things I've worked on haven't been email-specific. edit: Actually, there was one that bit me a couple of years ago. SpamAssassin by default will convert an original message into an attachment and append the attachment to the spam report if it determines the message is junk. This is reasonable, but you want a convenient way to undo this for your users. SpamAssassin is supposed to mark these attachments with a specific MIME type: Content-Type: message/rfc822; x-spam-type=original But on some configurations, for reasons I no longer recall, it doesn't. The attachment gets marked as text/plain instead. So if you're writing code to unpack a SpamAssassin report, you can't rely on the MIME type being there. You have to fall back to doing some guesswork instead -- and if the original message also contained attachments, it can get kinda hairy.

alecsmart1 13y ago

Can you enlighten me with some edge cases one might face while building an email app?

oblio 13y ago
Anything covering email on a production scale is going to be full of edge cases.
stevekemp 13y ago
One obvious one that many people fail at initially is sanitizing any HTML-formatted mail. You don't want viewing the mail to result in an XSS attack against the mail-viewing application, stealing your login cookie for example.
- mike-cardwell 13y ago
  Both GMail and FastMail have had this vulnerability in the past. GMail had it when script was hidden inside SVGs. FastMail had it when script was embedded in attachment filenames. I'm sure lots of other webmail systems had/have these issues too.
thaumaturgy 13y ago
Probably the Roundcube trac would be a good place to start. They've closed 5400+ bugs, feature requests, etc.: http://trac.roundcube.net/query?status=closed&col=id&col=summary&col=status&col=owner&col=type&col=priority&col=milestone&col=resolution&desc=1&order=id http://trac.roundcube.net/query?status=closed&col=id&col=sum... Here are some randomly-selected examples: http://trac.roundcube.net/ticket/1485777 http://trac.roundcube.net/ticket/1485777 http://trac.roundcube.net/ticket/1486166 http://trac.roundcube.net/ticket/1486166 http://trac.roundcube.net/ticket/1489535 http://trac.roundcube.net/ticket/1489535 http://trac.roundcube.net/ticket/1489409 http://trac.roundcube.net/ticket/1489409 I don't have any personal anecdotes, sorry. The couple of very minor things I've worked on haven't been email-specific. edit: Actually, there was one that bit me a couple of years ago. SpamAssassin by default will convert an original message into an attachment and append the attachment to the spam report if it determines the message is junk. This is reasonable, but you want a convenient way to undo this for your users. SpamAssassin is supposed to mark these attachments with a specific MIME type: Content-Type: message/rfc822; x-spam-type=original But on some configurations, for reasons I no longer recall, it doesn't. The attachment gets marked as text/plain instead. So if you're writing code to unpack a SpamAssassin report, you can't rely on the MIME type being there. You have to fall back to doing some guesswork instead -- and if the original message also contained attachments, it can get kinda hairy.