3 ms·

What does the vast majority of email produced currently look like and how do you know? Also, surprisingly, I, for one, don't have to read the majority of email

What does the vast majority of email produced currently look like and how do you know? Also, surprisingly, I, for one, don't have to read the majority of email produced. It's perfectly sufficient if I can read those emails that I receive, and the vast majority of those fit within those limitations without any problems. Hell, my guess is that the LKML (https://lkml.org/ https://lkml.org/) alone probably is the majority of my incoming mail, and that one essentially runs on "old" email clients. Though I guess that in your eyes that's a sign that the majority of kernel developers just are too stupid to know what a powerful MUA looks like ...

nailer 12y ago
LKML has very strict rules as it's primarily used for patches the Linux kernel. Other mailing lists, as you may be aware, are not primarily used for software patches, since most human beings, as I would hope you realise but perhaps don't, are not software developers. > What does the vast majority of email produced currently look like and how do you know? I don't think anyone has access to the majority of the world's email, so the best we can do is take a sample of general purpose mail servers and mailing lists, of which I've run many. However: you're arguing that the vast majority of email conforms to your rules (after all, we wouldn't consider email software maintained unless it could actually handle most email - I hope you agree but at this point I wouldn't be surprised if you didn't). This is a pretty fantastical claim, and the only proof you've been able to provide is personal experience of a mailing list with single specialist audience. Which seems much weaker. In fact, that that mailing list needs to tell people what mail clients to use seems to prove my point rather than your own. I didn't say kernel developers don't know what a powerful MTA is. I didn't say anyone was stupid. You're new here and you keep breaking the HN guidelines. Perhaps you'd be better suited to a different website?
- zAy0LfpBZLC8mAC 12y ago
  > LKML has very strict rules as it's primarily used for patches the Linux kernel. Other mailing lists, as you may be aware, are not primarily used for software patches, since most human beings, as I would hope you realise but perhaps don't, are not software developers. Your point being? > However: you're arguing that the vast majority of email conforms to your rules Please read more carefully. > In fact, that that mailing list needs to tell people what mail clients to use seems to prove my point rather than your own. Mind to elaborate?
  - nailer 12y ago
    >> LKML has very strict rules as it's primarily used for patches the Linux kernel. Other mailing lists, as you may be aware, are not primarily used for software patches, since most human beings, as I would hope you realise but perhaps don't, are not software developers. > Your point being? LKML is a poor representation of email users. >> However: you're arguing that the vast majority of email conforms to your rules >Please read more carefully. If you're not arguing that, you're arguing that despite most email not being formatted to 78 character displays, email clients which can't display most email are acceptable, which seems even more ridiculous. >> In fact, that that mailing list needs to tell people what mail clients to use seems to prove my point rather than your own. > Mind to elaborate? The presence of specific mailing list client guidelines indicate that most email is not formatted to 78 character displays, a notion which you were challenging earlier.
    - zAy0LfpBZLC8mAC 12y ago
      > LKML is a poor representation of email users. Which is relevant how? > If you're not arguing that, you're arguing that despite most email not being formatted to 78 character displays, email clients which can't parse most email are acceptable and not poor, which seems even more ridiculous. First of all, I didn't make any claims about what most emails look like. Just because I don't believe what you claim, doesn't mean I believe the opposite. I don't know, and as far as I can tell, you don't either. And it's irrelevant anyhow, as people might just not be receiving a representative sample of the emails out there, so it would be idiotic to give up advantages of your own mailer because it would not be able to parse mails that you don't even receive. Other than that, your thinking seems to be pretty one-dimensional. Email clients have more qualities than their ability to parse emails with lines longer than 78 characters (obviously, this is not really about them being unable to parse those lines, as in crashing or not displaying the mail at all, but about suboptimal handling), and some of those qualities might outweigh any disadvantage due to that. Also, it might just be that 78 character plain text mails are actually inherently superior to all the alternatives, in which case, even if the majority of emails today does not fit into that category, the sensible solution still would be to improve MUAs that send other formats rather than to make the older MUA support the inferior formats that are being widely used. > The presence of specific mailing list client guidelines indicate that most email is not formatted to 78 character displays, a notion which you were challenging earlier. Maybe you want to read the LKML's actual FAQ? Those "client guidelines" have very little to do with a 78 character limit, and all with how one can efficiently communicate using email, how some of the more well-known bugs in various MUAs hinder that, and how one can work around those problems. Some of that is specific to software development, but most of it really isn't at all. It just so happens that many newer MUAs tend to not support efficient work flows that have stood the test of time very well, and don't really offer any sensible alternatives either, and also tend to lack in interoperability with those (mostly older) MUAs that do support those well-working workflows.

nailer 12y ago

LKML has very strict rules as it's primarily used for patches the Linux kernel. Other mailing lists, as you may be aware, are not primarily used for software patches, since most human beings, as I would hope you realise but perhaps don't, are not software developers. > What does the vast majority of email produced currently look like and how do you know? I don't think anyone has access to the majority of the world's email, so the best we can do is take a sample of general purpose mail servers and mailing lists, of which I've run many. However: you're arguing that the vast majority of email conforms to your rules (after all, we wouldn't consider email software maintained unless it could actually handle most email - I hope you agree but at this point I wouldn't be surprised if you didn't). This is a pretty fantastical claim, and the only proof you've been able to provide is personal experience of a mailing list with single specialist audience. Which seems much weaker. In fact, that that mailing list needs to tell people what mail clients to use seems to prove my point rather than your own. I didn't say kernel developers don't know what a powerful MTA is. I didn't say anyone was stupid. You're new here and you keep breaking the HN guidelines. Perhaps you'd be better suited to a different website?

zAy0LfpBZLC8mAC 12y ago
> LKML has very strict rules as it's primarily used for patches the Linux kernel. Other mailing lists, as you may be aware, are not primarily used for software patches, since most human beings, as I would hope you realise but perhaps don't, are not software developers. Your point being? > However: you're arguing that the vast majority of email conforms to your rules Please read more carefully. > In fact, that that mailing list needs to tell people what mail clients to use seems to prove my point rather than your own. Mind to elaborate?
- nailer 12y ago
  >> LKML has very strict rules as it's primarily used for patches the Linux kernel. Other mailing lists, as you may be aware, are not primarily used for software patches, since most human beings, as I would hope you realise but perhaps don't, are not software developers. > Your point being? LKML is a poor representation of email users. >> However: you're arguing that the vast majority of email conforms to your rules >Please read more carefully. If you're not arguing that, you're arguing that despite most email not being formatted to 78 character displays, email clients which can't display most email are acceptable, which seems even more ridiculous. >> In fact, that that mailing list needs to tell people what mail clients to use seems to prove my point rather than your own. > Mind to elaborate? The presence of specific mailing list client guidelines indicate that most email is not formatted to 78 character displays, a notion which you were challenging earlier.
  - zAy0LfpBZLC8mAC 12y ago
    > LKML is a poor representation of email users. Which is relevant how? > If you're not arguing that, you're arguing that despite most email not being formatted to 78 character displays, email clients which can't parse most email are acceptable and not poor, which seems even more ridiculous. First of all, I didn't make any claims about what most emails look like. Just because I don't believe what you claim, doesn't mean I believe the opposite. I don't know, and as far as I can tell, you don't either. And it's irrelevant anyhow, as people might just not be receiving a representative sample of the emails out there, so it would be idiotic to give up advantages of your own mailer because it would not be able to parse mails that you don't even receive. Other than that, your thinking seems to be pretty one-dimensional. Email clients have more qualities than their ability to parse emails with lines longer than 78 characters (obviously, this is not really about them being unable to parse those lines, as in crashing or not displaying the mail at all, but about suboptimal handling), and some of those qualities might outweigh any disadvantage due to that. Also, it might just be that 78 character plain text mails are actually inherently superior to all the alternatives, in which case, even if the majority of emails today does not fit into that category, the sensible solution still would be to improve MUAs that send other formats rather than to make the older MUA support the inferior formats that are being widely used. > The presence of specific mailing list client guidelines indicate that most email is not formatted to 78 character displays, a notion which you were challenging earlier. Maybe you want to read the LKML's actual FAQ? Those "client guidelines" have very little to do with a 78 character limit, and all with how one can efficiently communicate using email, how some of the more well-known bugs in various MUAs hinder that, and how one can work around those problems. Some of that is specific to software development, but most of it really isn't at all. It just so happens that many newer MUAs tend to not support efficient work flows that have stood the test of time very well, and don't really offer any sensible alternatives either, and also tend to lack in interoperability with those (mostly older) MUAs that do support those well-working workflows.