5 ms·

I was interning in Rackspace this summer. For a while we were working on an email notification sender and we wanted email clients to group messages related the

by songgao 13y ago

I was interning in Rackspace this summer. For a while we were working on an email notification sender and we wanted email clients to group messages related the same event into a single conversation. However, different "event" might have same message subject, and we wanted to suggest how messages should be grouped. So we looked into "In-Reply-To" (RFC-822) and "References"(RFC-2822) fields. We ended up implementing RFC-2822 since it obsoletes RFC-822 and we figured if we want our message grouping work on most email clients, the safest way was to use the up-to-date standard (2822). Interesting fact is that, among three clients we tested, only mutt faithfully implemented the standard. It honestly grouped all messages referenced to the same ID into the same parent, despite subject or sending time. However, neither Gmail or Outlook respects the "References" field. In Gmail, it seems subject of the message plus [one of <time of message sent> and <References>] are used for grouping. But it certainly doesn't exclusively rely on "References" since we got messages referenced to same parent message grouped into different conversations. In Outlook, "References" field is ignored completely. It only relies on subject of messages. We got messages for different "event" from more than 10 days from each other, grouped into same conversation.

MoOmer 13y ago
Not sure if you're still there, but I think rfc 2822 was made obsolete by 5322[1] - which has since had some updates as well [1] http://datatracker.ietf.org/doc/rfc5322/ http://datatracker.ietf.org/doc/rfc5322/
- songgao 13y ago
  Thanks! That's an interesting read. We were actually wondering what was the maximum number of items in References field but couldn't find any. This RFC does give an answer[1]! [1] http://tools.ietf.org/html/rfc5322#page-25 http://tools.ietf.org/html/rfc5322#page-25 EDIT: fixed typo
jvehent 13y ago
People who haven't taken the time to work with mutt sometime fail to understand how convenient and user friendly it is. Pretty colors and nice interfaces do not always increase productivity. Sometimes displaying threads properly is all that's needed. Also, the "mark thread as read" feature in mutt (^R) is a life saver when sorting through dozens of discussions.
- songgao 13y ago
  My personal experience is that, I like how mutt looks and the fact that I'm able to deal with emails in CLI. The reason I'm not using it as my main email client (yet) is that I can't remember all shortcuts and I don't know enough what exactly each keystroke does to my emails and email server. These can all be fixed by reading docs and more practice though. I guess it's the same thing as vim. Once you are used to it, it becomes the favorite.
  - jvehent 13y ago
    And like vim, you will probably never use, nor need, all the shortcuts available. I use about a dozen keys in mutt, some of which are custom binding I use to send messages to separate maildir in one keystroke. All my emails get into my Inbox (except for bugzilla stuff). I go through my Inbox several times a day, and as I read messages, I press 'o', 'n', 'e', or 'a' to send the message in one of the four folders I mostly use. For the rest, I sort it manually using the 's' key. This way, my Inbox is always empty. Or if it's not, I know it's a message I need to get back to later on. There's usually no more than a handful of those. Granted, you can do that with any mail client. But mutt is particularly well suited for the job.
- ubernostrum 13y ago
  I have taken the time to try to work with Mutt, and some other console email tools. I would love to be using something like that full-time, since I practically live in terminal windows. But ultimately I can't; I don't need pretty colors or graphical tricks. I do need something which understands that it's not 1975 anymore. My mail no longer lives in a local spool file, and there is no longer a local sendmail. I have multiple email addresses, which use IMAP, and remote SMTP. And none of the console clients -- including Mutt -- can really do that. Every couple years I try Mutt again, and try whatever the current crop of attempted successors are, and get thrown right back into 1975 again and give up in frustration. (and Mutt, last I checked, actually considers it both a feature and a point of philosophical purity/pride to refuse to acknowledge the fact that anything other than "shell out to local sendmail" exists. Also, IMAP was unbearably slow, usually requiring a full re-fetch/re-index of the entire remote inbox, potentially hundreds of thousands of messages, every time Mutt started up, and multiple IMAP accounts were an unholy mess)

by songgao 13y ago

MoOmer 13y ago

Not sure if you're still there, but I think rfc 2822 was made obsolete by 5322[1] - which has since had some updates as well [1] http://datatracker.ietf.org/doc/rfc5322/ http://datatracker.ietf.org/doc/rfc5322/

songgao 13y ago
Thanks! That's an interesting read. We were actually wondering what was the maximum number of items in References field but couldn't find any. This RFC does give an answer[1]! [1] http://tools.ietf.org/html/rfc5322#page-25 http://tools.ietf.org/html/rfc5322#page-25 EDIT: fixed typo

jvehent 13y ago

People who haven't taken the time to work with mutt sometime fail to understand how convenient and user friendly it is. Pretty colors and nice interfaces do not always increase productivity. Sometimes displaying threads properly is all that's needed. Also, the "mark thread as read" feature in mutt (^R) is a life saver when sorting through dozens of discussions.

songgao 13y ago
My personal experience is that, I like how mutt looks and the fact that I'm able to deal with emails in CLI. The reason I'm not using it as my main email client (yet) is that I can't remember all shortcuts and I don't know enough what exactly each keystroke does to my emails and email server. These can all be fixed by reading docs and more practice though. I guess it's the same thing as vim. Once you are used to it, it becomes the favorite.
- jvehent 13y ago
  And like vim, you will probably never use, nor need, all the shortcuts available. I use about a dozen keys in mutt, some of which are custom binding I use to send messages to separate maildir in one keystroke. All my emails get into my Inbox (except for bugzilla stuff). I go through my Inbox several times a day, and as I read messages, I press 'o', 'n', 'e', or 'a' to send the message in one of the four folders I mostly use. For the rest, I sort it manually using the 's' key. This way, my Inbox is always empty. Or if it's not, I know it's a message I need to get back to later on. There's usually no more than a handful of those. Granted, you can do that with any mail client. But mutt is particularly well suited for the job.
ubernostrum 13y ago
I have taken the time to try to work with Mutt, and some other console email tools. I would love to be using something like that full-time, since I practically live in terminal windows. But ultimately I can't; I don't need pretty colors or graphical tricks. I do need something which understands that it's not 1975 anymore. My mail no longer lives in a local spool file, and there is no longer a local sendmail. I have multiple email addresses, which use IMAP, and remote SMTP. And none of the console clients -- including Mutt -- can really do that. Every couple years I try Mutt again, and try whatever the current crop of attempted successors are, and get thrown right back into 1975 again and give up in frustration. (and Mutt, last I checked, actually considers it both a feature and a point of philosophical purity/pride to refuse to acknowledge the fact that anything other than "shell out to local sendmail" exists. Also, IMAP was unbearably slow, usually requiring a full re-fetch/re-index of the entire remote inbox, potentially hundreds of thousands of messages, every time Mutt started up, and multiple IMAP accounts were an unholy mess)