Aethera Beta 1 Released 146
StupiDiot writes: "Aethra is a open source mail client which follows in the steps of LookOut, and is being developed by the Kompany. In case you haven't been
following, Aethera is theKompany's fork of the greatly hyped/anticipated Magellan project. Beta 1 of Aethera sports POP3, SMTP, HTML, DnD, a contacts interface, sticky notes, and more. IMAP, Calendar support, etc., are promised for the next beta. There is no mention of the license although source is available from the Web site -- most of the source files seem to be under the BSD license.
" So, I downloaded it and tried playing with is last night - it's a very cool, very slick program - the competition between this and the Gnome-equivalent Evolution will be interesting, as always. Regardless of which wins, the race to produce an Outlook-killer is on.
Outlook Killer? (Score:1)
Good luck! Without something like Exchange or an "Outlook Killer" that is compatible with Exchange, there's no way this will get ANYWHERE.
I'd love for it to happen though...
wasting of time (Score:1)
Re:I'm writing an Outlook killer myself (Score:1)
Re:HTML Email is NOT a feature (Score:1)
Re:I'm writing an Outlook killer myself (Score:1)
Both formats have problems. While I love the direct response system of the unix style, it doesn't fit so well in this age of variable size windows for reading e-mail. It doesn't word-wrap. HTML is (justifiably) panned for all the crap people have put it in, but a separation between the data and the display would be a good thing.
Heck, I used it in this post, by italicizing the comment I'm replying to. I can't do that so easily in e-mail.
Re:Why do people do this? (Score:1)
At least MS actually go to the trouble of usability testing and feeding the results back into the design process. With most open source apps the design criteria tends to go to "the developer should be happy with it" and not much further.
Re:There are already standards for this (Score:1)
Not really. MS developers contribute to quite a few RFCs and other open standards these days.
Re:Please... (Score:1)
Not really - all of those examples don't require anyone else to put up with your choices. The nearest anyone else would have to come to them is the paper produced by LaTeX.
EMail is *entirely* about interoperablity, on the net-at-large, at least - your choice of mail client and format does affect what I see.
That said, if someone could make a "liblinks" so that I could read the HTML mail in links without having it as an external viewer in mutt, that'd be cool - as it stands, HTML mail is passed over in favour of mail I can read without effort, unless it's someone I know.
Exchange (Score:1)
Re:Just Want A Good, SOLID Mail Client (Score:1)
Oh and can you remove the "three pane" layout rubbish. Messages should be displayed in a window that can be stacked as the user sees fit. And I don't use folders so why bother with all that wasted screen space. But I do use the keyboard so it should be aimed at not needing a mouse.
And multiple UIs, say console and X (or web and X) for when I dial in from home.
And a scripting language (so I can do pick -t rpm-list | save +rpm-list interactively)
Zmail is still my killer application. I'd sell one of my two sisters for an industrial strength mailer than runs on Linux (mutt comes close but thye took out the best bit from mush---the shell-like interface)
richard.
integration with dialer? (Score:1)
Szo
Re:HTML Email is NOT a feature (Score:1)
Personally, I despise any kind of marked up e-mail format. On the other hand, I don't mind some limited forms of client-side markup. For example, the quote highlighting that kmail now does is handy, although the charset support can just go.
As long as the original text version is what I actually got so that I can still dial in and read it with elm (AKA the devil I know).
c.
Re:Why do people do this? (Score:1)
And thus ensuring Microsoft's lock in of corporate "standards" such as Outlook.
The key here is the server, not the client. I don't want a clone for Outlook to read my messages in, but I do want to be able to access my company's calendar and contacts database. Tools that extract Exchange information and make it usable to the rest of us are desperately needed.
There's a broader point here: one of the reasons Linux is weak on the desktiop is that there are few people with the ability to see beyond the Windows (capital W, note) paradigm for tools and UI.
KDE is the worst offender (although Gnome is guilty too). It's a stupendous technical achievement, but all the imagination has gone into the code. For a UI, someone just screenshotted Windows 95 and then set about making everything the same, down to one click app and document launching.
Re:HTML Email is NOT a feature (Score:1)
[excessive flamage]
If you stupid OS zealots would stop using a mail client that's older than your mothers *cough* mutt *cough* and drag yourselves kicking and screaming into the 21st century (or at least past 1991), there would be no problem with using HTML in email. Believe it or not, there are reasons for using X other than getting 12 terminal windows on the same screen.
[/flamage]
Re:Please... (Score:1)
How about one that `upgrades' plain text for viewing, stripping the asterisks from "*foo*" and making it bold, like what Mozilla does with ":)"?
MAPI (Score:1)
Re:not again! (Score:1)
What we really need is neither of these projects, but instead something that uses open standards-based peer to peer protocols to do calendaring.
What's so difficult about HTML? (Score:1)
Re:Not an Outlook killer (Score:1)
Re:Outlook killer? How about Exchange killer? (Score:1)
But I agree with the point, that in order for this kind of app to take off you have to match the features of Exchange and Groupwise, and add more stability.
Groupwise is great for stability, the client is what needs the most work. (ie; not wrapping lines).
Perhaps its time for a new groupware server, with hooks that these apps can plug into to have a shared calendar todo lists etc.
Just my 2c
Once again... (Score:1)
Btw, I've tried Aethera, and... it's a killer.
--
Re:OL killer? (Score:1)
Mulberry (Score:1)
Re:Why do people do this? (Score:1)
We all know that Windows sucks. So why, oh why, do countless Open Source projects spring up that try to slavishly duplicate the look and feel of yet another crap Windows product while leaving out the only good parts of the functionality? And then they call it a "Windows:foo killer". Do they really think Microsoft are the sole arbiters of what constitutes good GUI design?
Considering they actually hire people who specialize in user interfaces and the psychologies behind them? Yeah. Just because you don't like the look and feel, doesn't mean that everyone else---
ICAP server (Score:1)
It has most of the functionality of the Netscape Calendar server -- it just needs the SASL wrapper written for it, and it provides a client.
---
Re:Amen! (Score:1)
I understand the unix philosophy of 'doing one thing & doing it well'. But PIM is really one thing that has contacts/mails/calendar.
And also a synchronisation with PALM / those cell phones would be nice too.
LinuxLover
Please... (Score:1)
why don't every one use CLI instead of all the cool looking KDE/gnome/E/whatever?
why get DSL when a 56k modem can download webpages aswell.
why people have to use Koffice/MsOffice instead of Latex to write a letter. INfact it is the one used to write thesis & books
I *like & send* text mails most of the time as most of my friends are unix users and they hiss on HTML mail. But if I need to 'mark' my mail using bold/italic/colors or whatever, I would rather use HTML for that. It is *still* text unlike some other proprietary format. And trust me a color coded mail is more readable / presentable than one filled with underscores and stars.
What I would like is a mail client that would 'dowongrade' HTML to plain text for viewing. (and it might even be smarter to do bold / italics using 'curses' or just plain using underscores stars). Now that would be real nice.
LInuxLover
Re:IMAP support (Score:1)
I also like IMAP where msgs live in server and deleted msgs are removed from server. This way I don't have to backup my mail dir often. One think that pisses me off about POP is when I select
- leave mail on server
- delete mail on server upon local delete
nothing happens (Netscape mail / kmail). The mails keep accumulating in Inbox and oneday all the mails started to bounce back with error message 'insufficient resources for recipient' !!!
Any one has a workaround for this?
LinuxLover
Hurry up to patent Office (Score:1)
Sure this an absolute wínner and I hope you are lucky to get your well deserved financial reward.
//Pingo
Outlook replacement? (Score:1)
Reason: Context (Score:1)
It's ironic, then, that you choose to post to Slashdot differently (instead of like I'm posting now). Context is everything, and replying to points in turn has no substitute.
Every email client I've used, I've always changed it so my new text appears on top. Even my Linux ones.
Re:HTML Email is NOT a feature (Score:1)
Why in the world would you do such a ignorant thing such as to despise a semantic markup language such as HTML. It would be utterly idiotic to put down a semantic markup language, which has the purpose of providing a better description of the message's meaning to the reader. I've written about this at length on my website [neverending.org], so I'm not going to try to re-iterate this old, tired argument. In the end, HTML email providea meaning and structure, and gives the power of presentation to the reader, not the author.
Re:HTML Email is NOT a feature (Score:1)
Could you possibly be more ignorant of what HTML is? You fail to realize that HTML is a semantic markup language, not some presentational language, which you obviously think it is, judging from your webpage [wtower.com], which uses a plethora of deprecated presentational HTML elements. I've written about the topic of HTML email at length [neverending.org]; it comes down to the fact that HTML provides a greater means of communication since it is a semantic markup language, and since it is such, gives the ability of presentation to the reader, not the author, as which is done with flat text. Having the author decide presentation is one of the worst evils we are plagued with concerning email.
Re:HTML Email is NOT a feature (Score:1)
On the other hand, your entire argument is nullified since the client in no way shape or form needs to support the deprecated presentational aspects of HTML.
Urethra (Score:1)
Re:outlook killer (Score:1)
Re:HTML Email is NOT a feature (Score:1)
Sorry - to be more precise, the end user doesn't see <EM> as denoting "Emphasis", they perceive it as "a way to get Italics". And since 99% of the userbase is used to seeing three items in a toolbar marked "B I[underline]" to get the presentational elements, it wonn't matter whether they're Bold or Italic, or Strong and Emphasis.
The end user uses markup elements as presentational elements because they don't appreciate the difference. The level of clue you're asking for isn't realistic; as a tech writer, I've seen the most "OO"-clued developers and technically-clued testers produce Word and FrameMaker documents that are marked entirely with "hardcoded font changes", even when given a template/style-sheet chock full of everything they want.
They still "<Font=Courier Size=10>" when they mean "<functioncall>" because they don't grok that a desktop publishing system is not a typewriter. Now imagine trying to get Joe AOLer to do the right thing for a random email. He won't, for the same reason - because he can't comprehend the difference. "Yo, what's the difference as long as it looks bold when I click the bold button?"
Re:HTML Email is NOT a feature (Score:1)
Bah! A mouse is just a device you use to figure out which of those terminal windows you wanna type in ;-) :-) :-)
Re:Yes, but (Score:1)
"Well, if it supports HTML mail, it's a web browser, so I guess it's gonna have to if it wants to beat Mozilla! You can wait three years for v1.0 of your mail client as long as it's got skinz, can't you?" *rimshot* ;-)
Re:HTML Email is NOT a feature (Score:1)
Agreed -- but email is not the new medium, the web was.
(To clarify: Would you chastise Leonardo DaVinci because the Mona Lisa isn't a 3D CGI rendering? Even if HTML:Plaintext as CGI:Paint, it does not follow that all email should parse HTML, just as it does not parse that all oil paintings should be "updated" to look like ray-tracings. Email, WWW, paint, and ray-tracing are media. Plain text, HTML, the Mona Lisa, and Quake models are instances of media.)
Re:HTML Email is NOT a feature (Score:1)
Umm... ask 100 users who prefer HTML mail to text why they use HTML mail.
Betcha 99 of 'em say "Well, it'z cuz u can bold things and italicize things".
The fact that HTML is a semantic markup language has nothing to do with the fact that it's used as a presentational language, thereby effectively nullifying your argument.
Lud·dite (lŭd'ît) (Score:1)
1) Any of a group of British workers who between 1811 and 1816 rioted and destroyed laborsaving textile machinery in the belief that such machinery would diminish employment.
2) One who opposes technical or technological change.
Re: (Score:1)
Outlook Today (Score:1)
Aren't you all addicted to your Outlook Today?
Re:There are already standards for this (Score:1)
i think most of parts are already there (ldap, ical, etc.), but someone has to glue them together.
Re:Amen! (Score:1)
The "UNIX philosophy" does not nessicarilly apply to end user applications IMO. You can have a seamless end user PIM app that is made up of a number of individual components that all interact, doing their own thing well but the user just sees a seamless, intergrated frontend.
Amen! (Score:2)
Elm, Pine, mutt, kmail, or one of several other mailers all work fine for my mail. I don't need anouther mail client. I do however need a way to do calendaring, and it needs to be compatable with everyone else's calendar. I don't care what your mail tool is, I'm used to pine and we can communicate.
This week we are in the process of switchig from Synchronize (with unix or windows clients) to exchange (and citrix for those with unix on their desk top - most of us) because the main office is exchange and those who regularly go to headquarts have a secratary just to keep the two systems in sync. It will work, but from playing with citrix I've already realized it is slow.
Problem is anyone can write a mail client. ASCII is an old standard. All the protocols are well described in rfcs. There are plenty of resources on network programing for just about any OS. Exchange is not well documented however. Good luck creating your own client - it is unlikely to work.
Re:HTML Email is NOT a feature (Score:2)
As soon as you talk HTML, you must think portability across platforms and applications, because HTML is supposed to be a platform-independant solution. (on the other hand, plain text *is* a solution, hands down). But 90% of the problem with HTML messages that are sent are the same 90% of the problem with the rest of the web -- these people have no idea how to write HTML code properly. From using malformed HTML markup to using IE-only tricks, these messages are barely readable on most browsers -- strip away the HTML to leave text, and you usually have something unreadable due to poor formating or hiding the content in the HTML (even though, theorhetically, removing HTML tags from a proper HTML document should leave a easily readible plain text file). This is a big concern to anyone using wireless internet devices, such as cel phones -- if that HTML message parsed down to text only is unreadible at 80x24, imaging trying to read it at 25x4, or worse.
You then have to conside the other problem, and that is compatibility with HTML browsers. Most of these email clients link to an existing browser engine, and embed it into a window. Lookout, obvious, and IIRC, Evolution will grab the Gecko engine from mozilla to do any HTML display. So you first run into the standard problems with HTML rendering in the various engines. But particularly on the windows side, these instances of the browser are NOT sandboxes -- all the standard hacks and the like will work in terms of, say, malicious buffer overruns from URLs. In addition, the 1x1 web bugs and other tricks can easily be inserted into the HTML email, and since you usually can't set different privacy and security for that browser instance, you're as vunerable as you would be with normal browsing. Plus I can send code in HTML that would normally be picked up by a cookie-blocker or such if the user had viewed the page via a normal HTTP connection, but would not be blocked in this case, and do the usual tricks of reporting back to a server.
Add to all of this that there is no clear cut standard for sending HTML email to begin with. Sometimes I'll get it in the plaintext client as HTML right after the headers, sometimes as two parts of a mime-encoded message, sometimes as an attachment -- it's a mess!
I believe that two things need to be done to make HTML email a practical thing that sits on top of the current email system that we have. Obviously, we need a standard for how to send and recieve email. Modifying the RFC for email servers to be able to recognize when an email client is sending in HTML, so that it can tag the message appropriately, and then when mail is being retrieved, a numeric can be sent prior to retrival to indicate that HTML or plaintext is desired (ala BINARY and ASCII of ftp servers). The server then would strip any HTML out of messages that contain it before sending the message out, if the plain text feature was enabled.
The other thing, more serious, is to develop a subset of HTML that can be used for email, similar to how /. does a trim of html -encoded messages. Restrict the set to only layout messages, such as B, H1, as well as links etc, and avoid anything that moves outside of just display, such as IMG, SCRIPT, EMBED, etc, such that what really can be sent is a what RTF can provide, in HTML terms. Mail clients can parse this before sending, but the job again would be up to the mail servers.
Putting such a new email server in place, as long as the way HTML was sent uses one of the current methods in use today, would not disrupt how older servers would continue to function, since only the input and output servers have any extra processing of messages to do. But there's a long way to go before this could be commonplace everywhere... it would require much help from MS and other vendors, and they're probably not going to cave in from this.
Re:Please... (Score:2)
This may be one division between anyone introduced to the Internet pre-Netscape, and those after that point (give or take a year). I have no problem with the defacto standards of viewing plaintext "markup" like *emphasized words* or SHOUTING, since I've been reading email and usenet for at least 10 years now. And on the other hand, I find that outside of bold and italics, any color coding done in passages is distracting. The above poster obviously feels different. And while I would love my way to be the right way, I do realize that 90% of the people using the net today are going to be of the latter state of mind. C'est la vie, but here's the important point:
We're moving 'backwards' in terms of display technologies as we get more wireless internet devices where you only have a 24x4 character display to show a message. If only text email existed, there would not be a single problem with handling mail on these devices, but with HTML email abuses, they have to figure out how to parse everything to fit on that. Sure, maybe in 2 years we'll have holograph, 3d displays on all these things capable of effectively large graphic displays, but the NOW is that we don't. If you design for the most effective lowest common demonator, no one will complain. ("Most effective" to avoid any slippery slopes -- I *expect* that to play Q3A, I'm going to need a powerful system, but to read email, I should be able to do that on a Vic20.).
Re:Aren't they afraid of being sued? (Score:2)
While there products are meant to mimic some of the functionality of some MS products, the look and behaviour vary a lot.
Apple may have successfully sued people for copying it's UI, but you can't sue someone simply for making an IDE (which, I seem to recall, wasn't even started by them..) or for making a flowchart program.
What you can do is sue someone for blatently copying a UI (like, oh say Evolution-Outlook or Gnumeric-Excel...)
It would be funny to see MS trying to sue someone for making a copeting product..
Cheers
Re:HTML Email is NOT a feature (Score:2)
I mean, I read all these books about people who scream and holler and stamp their feet with respect to change, but I never believed I would actually see the like.
Psst. While you weren't looking, your terminal changed to use ISO-latin. That's eight bits. It might even use unicode of all things, not only 8 bits but with funky escapes to encode 16 bit chars. Neither of which will show up on your IBM Codepage console on the 386sx running Linux 0.9 for which you read mail using cat
And despite your protestations, most mail readers got MIME support. Perhaps you've heard of it: it's what that "web" thing uses too.
And despite your ranting and raving, even a great many technically clueful people really don't give a damn about what you consider acceptable documents to transfer over e-mail.
Cope.
--
Re:HTML Email is NOT a feature (Score:2)
Would you rather it were RTF? I like being able to mark up my email, thanks very much.
--
Re:HTML Email is NOT a feature (Score:2)
Outlook most certainly can, including Outlook Express. Simply open the contact in the address book and check "Send E-Mail using plain text only". Besides, I don't share your feelings about HTML email. Each new medium developed should be able to repesent information to the richest extent possible. Using plain text only is an artificial limitation that makes only some people happy. Those people should strive to develop email clients that let them strip the plain text out of rich email, but they shouldn't be allowed to dictate what everyone else uses.
All said, there is no denying that a rich medium invites poor taste. Crass use of fonts, colors and sizes can indeed make email very unreadable, but that reflects more on the poor taste and inexperience of the author than on the flaws of the medium. A good email client would offer a sensible set of filters that can let you normalize rich email to whatever you want: full formatting, colors only, fonts only, or plain text only.
Re:Internationalize! (Score:2)
You mean something like Pango [pango.org]?
Re:Outlook Killer, C'est Que C'est (Score:2)
The important bit is the server platform. It is very hard to make cretinous Minesweeper Consulatants and Solitaire Experts that dwell around the coridors of large corps and claim to be from the "Incompetent in Technology" department to use anything but MS Exchange. So anything that can deal with their abominative productions is more than welcome.
Supports HTML email? (Score:2)
(this would have been funnier with the multiple o's, but filter stopped me. Damn.
Pope
Freedom is Slavery! Ignorance is Strength! Monopolies offer Choice!
Re:Outlook Killer, C'est Que C'est (Score:2)
Well, according to a note that I *would* quote (but for the fact that the kde news server just got slashdotted), the president of theKompany says that there is no reason that Aethra can't easily be ported to windows.
--
Evan
Re:HTML Email is NOT a feature (Score:2)
Email is a method for communicating. C-o-m-m-u-n-i-c-a-t-i-o-n is the keyword, the issue isnt HTML vs ASCII - it's which method that allows me to communicate more efficently.
<rant>
And beliving that email should stay 7-bited is so narrowminded that it's scary - makes me wonder if you've ever seen the outside the US? (Assuming you're an american, because most others nations have a realistic worldview) . Repeat, Lather, Rinse: The US isn't the entire world. English isnt the only language. 99% OF ALL LANGUAGES CAN'T BE EXPRESSED IN 7-bit ASCII.
So why the fuck are you ranting about the superiority of 7bit ascii? There isnt a single advantage to using 7-bit ascii over MIME or (preferbly) Unicode.
</rant>
-henrik
OL killer? (Score:2)
This may well be explainable: it is not cheap to conduct various usability studies, yet it is still sad nonetheless.
Re:Why do people do this? (Score:2)
To make the open source movement something the PHBs can understand you have to give them MS-like solutions. An Outlook Killer is a step in this direction. "Sir, why buy 2000 Outlooks (or whatevers) if there's this one for free that we can tailor to due as you, the almight Lord Boss, please?".
Face it, they need a comparison - you can't expect a non-techie to understand that Linux is superior to Windows ?? due to it's stability, you need to make them understand through ca$h ($$$$$$) or something else.
I say, GREAT job guys - keep it up!
--
All browsers' default homepage should read: Don't Panic...
Re:Not an Outlook killer (Score:2)
Re:Not an Outlook killer (Score:2)
Re:Interface biting (Score:2)
ROFL!
Ahum. Sorry, couldn't help myself...
Thimo
--
Re:Outlook Killer, C'est Que C'est (Score:2)
Re:OL killer? (Score:2)
Look on the bright side of having these opensource Outlook lookalikes being exact. If you have a company with x employees that were raised on Outlook and switch them to this, it'll be easy for them to figure it out without asking on newsgroups, reading through FAQs, and dinking around. Time is money, and not everyone has the time to goof off with an app when there's work to be done.
Re:I'm writing an Outlook killer myself (Score:2)
So that at least one of the 13 previous people who were also "top-replying" would be encouraged to get some clue and trim out the irrelevant crud ;-)
Why the heck did you, a proponent of "top-posting" - when you posted your reply to Slashdot, which does not (last time I looked) automatically quote text to which you're replying - put your reply at the bottom of your reply to the original poster?
Answer: The same reason peoples' replies belong below the quoted text in email, namely "Here's what Foo said. Here's what Bar said in response. And here's why I agree with Foo and not Bar.", or more bluntly, because people in western cultures read left-to-right and top-to-bottom.
Re:HTML Email is NOT a feature (Score:2)
I'm one of those who believes HTML in email is an abomination.
The answer to why I use HTML markup on Slashdot is because Slashdot is accessed through the web. HTML is what web pages are made of; it's therefore appropriate to use HTML.
Email is not the Web. Email is a method for sending text (7-bit text, none of this 8-bit M$ASCII crap even!) between users on two systems.
Since even web browser authors can't render the same pice of HTML identically, and there are only two mainstream browsers, how on earth do you propose to make every email client (from mutt to Elm to Pine to Eudora to Outbreak to Nutscrape to...) render HTML correctly?
Email is not the web. If you want to mark up your email, *emphasize* things or _underline_ them or SCREAM, but do it in 7-bit ASCII, and do it in text.
- Paul Tomblin in alt.sysadmin.recovery, regarding HTML in USENET.I happen to agree with the sentiment when it comes to HTML in email too.
Re:HTML Email is NOT a feature (Score:2)
Umm... because 7-bit ASCII is what's in the RFC that specifies what SMTP is?
Because MIME-encoded binaries are 7-bit ASCII, just encoded in base64?
In English, I'd still rather see a "'" or """ instead of the =[hexdigit] that MIME uses -- but I'd rather see =[hexdigit] than the 8-bit "thing" that M$ includes.
Just like I'd much rather see a 7-bit ASCII representation of a base64-encoded JPG than have a mailer just "cat natalieportman.jpg | /bin/mail poorbastard@127.0.0.1"
Non-US character sets will likely wind up in some sort of representation that comes down to 7-bit ASCII too. SMTP is an 8-bit-unclean protocol - and if you use SMTP, you have to figure out how to decode quoted-printable or base64 data.
If you're going UTF-8 (or UTF-16), and the transport is not 8-bit-clean (i.e. if you use SMTP), then you need to do it in 7 bits and do MIME support. RFC2376, IIRC.
Email is about communication across platforms. To the extent possible, it should be independent of the mail client of the sender and the reader.
That's what the RFCs are for.
(Disclaimer: If you're doing groupware - strictly for stuff in the LAN and you control all the clients and all the recipients - you can design an 8-bit-clean transport protocol, and you can blithely send all the 8-bit data you want. Just don't assume that anyone outside your LAN will be able to read it. That is where Lotus Bloats and MSexchange both went wrong, and that's the thing I'd like to see an open-source Outlook-killer not do.)
(Of course, I do agree that that the issue of 8-bit-unclean transport is a wholly separate issue from my stance on HTML mail, since you can do HTML mail in 7-bit, but I'll still bounce it in procmail. It's just that I'll bounce it for a different reason ;-)
Re:I'm writing an Outlook killer myself (Score:2)
Why in the heck would I want my text below the part I'm replying to? So the person can read through 14 consecutive replies before they get to the good stuff?
Because as good Netiquette [phish.net] you should be trimming the text of the message you're quoting to the bare essentials - obviously.
Steve
---
IMAP (Score:2)
But I DO have to admit, Aethra DOES look pretty...
-Brandon
this is no outlook killer. (Score:2)
our server is run by microserfs...meaning forwarding is disabled, IMAP and POP are closed.
NO non-microsoft mail client will ever work with our exchange server.
IMHO, exchange and outlook are a better example of Microsoft's antitrust behavior than the browser wars.
Re:Amen! (Score:2)
Re:Not an Outlook killer (Score:2)
--
Re:I'm writing an Outlook killer myself (Score:2)
Why in the heck would I want my text below the part I'm replying to? So the person can read through 14 consecutive replies before they get to the good stuff?
Every email client I've used, I've always changed it so my new text appears on top. Even my Linux ones.
-
-Be a man. Insult me without using an AC.
Not an Outlook killer (Score:2)
What *really* needs to happen is for someone to take the initiative on providing an extensible messaging environment that enables you to offer directory services, calendaring, addressing, forms, event handling, messaging, and VOIP across a corporate environment. SMTP and POP3 just aren't going to meet this need. Those types of features are what separate a mail program from a groupware environment.
Instead, what I really think people are looking for is not so much an Outlook killer (after all, it is in fact only a client) but an Exchange killer. And that needs to be cross platform or else you'll only have minor adoption rates - supporting Linux just won't do (even for the server). I find it hard to get impressed with another "me-too" mail program wanting to be groupware.
Re:Interface biting (Score:2)
Pine uses a suspiciously similar interface too (It has To:, CC:, Subject: and the message body!) It must be copying Outlook as well!!
---
DOT.KDE.ORG (Score:2)
a lot of talk about licensing issues and a apparent feud between the kompany and magellan developers
Must sys that it still looks nice tho
theKOMPANY is working... (Score:2)
again dot.kde.org http://dot.kde.org/979768484/979777064/979778240/
IMAP support (Score:2)
not again! (Score:2)
there was the camel mail backend that they could have used, and implemented a kde interface - so why ignore it and the chance of *easier* interoperability between this and evolution??
i know this is still an important project, but people can't ignore existing technologies because of the fact that it was a competitors design.
sad...
funny (Score:2)
--
Kiro
Nice support. (Score:2)
DnD? As in "Dungeons and Dragons"? Gee, I hope that the Wizards know.
Re:Just Want A Good, SOLID Mail Client (Score:2)
Re:I'm writing an Outlook killer myself (Score:2)
Actually, it does. More advanced email clients work out what the indent characters are for each particular segment of text. Bingo! They now know each paragraph for individual word-wrapping, _and_ they know what to indent that paragraph with. Doesn't work very well on single-line replies, though.
Yes (Score:2)
Re:Outlook Killer, C'est Que C'est (Score:2)
>Regardless of which wins, the race to produce an Outlook-killer is on.
Making Outlook killers is easy! Oh, wait, you mean competing applications, not a virus...
Yes, but (Score:3)
No? What! I thought all OpenSource projects these days had to be able to do these two before you can even consider a first release! What were these guys thinking!
Why do people do this? (Score:3)
I don't like the look and feel of Outhouse. And as an email client it sucks big hairy ones. I do like the calendaring, or at least I would if I needed to schedule things with more than one person. So why is this "Outhouse killer" duplicating the look and feel of Outhouse, but not offering any way to do calendaring through a SexChange server?
No thanks. I'll stick to mutt, and occasionally when somebody sends me a Microsoft attachment that I can't read by piping it to strings, I'll fire up Mozilla's email client on my NT machine. It's not great, but at least it knows enough to open up my IMAP inbox by default, unlike Outhouse.
Outlook killer? How about Exchange killer? (Score:3)
My company uses Exchange and we all hate it. But everybody loves Outlook. Hell, I like Outlook, but use it in Internet mode, not Exchange native mode, because I can't use IMAP when Outlook is set to use Exchange, though I can set up additional POP3 accounts.
But the server side, Exchange, is a giant piece of bloatware that couldn't stay up for a week if Bill Gate's life depended on it.
You want to hurt Microsoft bad? Come up with a free-as-in-speech, open source, server-side replacement for Exchange, supporting all the features the client, Outlook, wants to use. I haven't got the programming skills to attack this, but I do believe that the route to the desktop is through the server, at least for open source systems.
I think there's a lot to be said for the embrace and extend strategy, and open source should embrace and extend the server side of Microsoft protocols, to get to the client side. As far as I know, reverse engineering to achieve compatibility is still legal in some parts of the world... Is anybody working on this already, and I just never heard about it?
For those asking for an Exchange killer (Score:3)
I've been using IMP, the webmail portion of HORDE, for quite some time now (no, not me personally; I use mutt. My _users_ have been using it). It's a very nice webmail client, especially with a few patches (for things like importing Outlook address books), and looks similar to Yahoo! mail (apparently; I've not used Yahoo! mail).
Though IMP is the most mature component, they also have Kronolith, which does calendaring. You have to get the code from CVS at the moment, but it is apparently in use in the Real World. Yes, it's a bit simple at the moment, but it's under development, so it _is_ happening.
Note that HORDE is entirely done with PHP, so it _does_ work on MS platforms (the server part, obviously; the client part is a web browser
The best part about providing users with webmail is that there is NO configuration. This is especially good when you are in Baltimore, and a good chunk of your users are in Chicago. You tell them on the phone, "Here is your username/password and the URL, go log in."
Sotto la panca, la capra crepa
I am afraid to agree (Score:3)
The Law of Software Envelopment: ``Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can.''
(Jamie Zawinski)
They clearly got it backward...
Cheers,
--fred
Outlook Killer, C'est Que C'est (Score:3)
HTML Email is NOT a feature (Score:4)
Now, I completely understand that in intraoffice communications, because of the braindead-ness of PHBes, HTML or formatted email proliforates badly, just because they can bold the words "and I want it done NOW!". So it's completely understandable that an email client that is to be used on the rogue linux back in a WinNT environment is going to need to not only understand Lookout's protocols but also the ability to view HTML email directly. In addition, it would help to make conversions from WinNT to Linux systems if such were to occur more easier for the PHBs since they still have their pretty email system.
But please oh please limit it to just that. It should not be too hard to set up, by default, limiting HTML email to certain address sets, specifically ones with the same domain as yours, as well as making sure that HTML email is disabled on a normal install. The address sets that can accept HTML should be able to be customized, of course, in case you have contacts that you normally use HTML email with. I don't care if your office mates all email each other in HTML, but if you have to mail me or anyone else on the outside world that you don't know yet, make sure it's in plain text. The current batch of clients that support HTML email (include Lookout) do NOT have any such feature, and this would be highly recommended for any further email clients.
There are already standards for this (Score:4)
Unfortunately, I personally know of no open server-side implementation of these standards, though there probably are some. If you know of any, please post here.
Re:Interface biting (Score:4)
Whatever -- e-mail GUI programs tend to look alike, and that's not really a bad thing. At least people recognize what's going on immediately and don't have to familiarize themselves with it too much -- especially when you're trying to replace/compete with Outlook (*including* the database and back office functions), it doesn't hurt to be a little familiar.
Lastly, nobody's stopping you from contributing to Aethera's further development. If you wanna help out, please do so. :-)
cya
Ethelred [macnews.de]
Re:Outlook killer? How about Exchange killer? (Score:4)
But the server side, Exchange, is a giant piece of bloatware that couldn't stay up for a week if Bill Gate's life depended on it.
As someone who has worked professionally with Exchange for some time, I'd have to contradict part of this at least. Sure Exchange is bloated (I've just been dowloading SP4, which is obscenely large ~ 134 MB). I'd have to disagree with the stability accusation, though. I've been doing second line support for about 40 Exchange servers on a corporate network (all running on ridiculously overspecced Compaq servers) and it's proved to be rock solid. The only faults I've had in the last year related to the Lotus Notes connector - a bit of software that makes Charlie Manson look stable - and the occassional hardware glitch.
Using up-to-date service packs, neither NT nor Exchange are anywhere near as flaky as they used to be. As a passionate Linux user, I'm irritated every time I see anti-Linux FUD. However, as a regular NT admin, I'm also irritated by anti-MS FUD There are plenty of real points upon which NT & Exchange can be attacked (price, security, being closed-source) but echoing outdated rhetoric serves no one.
Sorry for the rant. I think I'll go and have another cup of tea now.
--
Re:Why do people do this? (Score:5)
Interface biting (Score:5)
Evolution Inbox screenshot [ximian.com]
Evolution Compose message screenshot [ximian.com]
Considering the bashing Microsoft takes around these parts, isn't it surprising that the interface here has been pretty blatantly jacked from Outlook? Now it might be the case that this really *is* the best interface style to use for an E-mail client, and that's fine. But give credit where credit is due for the design, or bash and don't bite.
I'm writing an Outlook killer myself (Score:5)
- Sends emails to your friends in a totally proprietary format, also encoded with CSS to protect it from the evil hackers who broke TNEF [std.com].
- In an email reply, it takes all your new text from where it should be (directly under the part replied to) and automatically moves it above the original message. This is to deliberately make you look like a newbie and thus make you more attractive to your preferred soulmate gender.
- Posts to newsgroups in Microsoft's extended RTF format. That'll teach them to complain about HTML.
- Automatically opens any executable attachments and runs them. You obviously wanted to do that, so this saves your valuable time.
- Includes a built in copy of Solitaire and Minesweeper for you to play while it sends and retrieves your mail.
- Sends me, err, 'performance data' of any *.jpg or *.mpg attachments you recieve.
What do you think? Am I on to a winner?Outlook killer? How about Exchange Server killer? (Score:5)
I want to see an Exchange killer in the back hooked up to one of these Outlook killer clients. Plus, I'd like to see it a little more sane/easier to administer. I'm not asking for more clickable items, I'm asking for sane permission structures (so I can keep Dave from resetting Betty's calendar without her permission), realistically tied together scheduling and a nicely followable format for the whole configuration.
I realize there are some albeit very, very small efforts under way to complete some projects along these lines. But there seems to be so much focus on the front end that no one really says squat about the server side requirements/code.
Until I hear that one of these packages is fully ready to tackle the Exchange/Outlook combo punch, I'll just keep plugging away with what I've got. Seperate server based calendaring, seperate e-mail, seperate collaboration, all a pain in the ass to accomplish, but usable. And constantly listening to my users bitch and moan because at that other company, "We used Outlook."
We get by with what we've got (and the boss liked the price tag, probably the only reason we are using Linux), but it sure would be nice to give the users something focused on their needs.