Qualcomm's Eudora is one of the oldest Personal Computer based mail clients. It's also one of the pioneers of POP3, and one of the first mail clients to support IMAP4, as well as ACAP.
It has a very, very long heritage, and it's good to see that it's making a bit of a comeback, partly due to the ditching of the old lite version, replacing it with an advertising based model. As an IMAP4 client, it's pretty reliable most fo the time, which is, in my experience, very rare indeed.
The ACAP support it offers is pretty basic - it's designed purely to work with Qualcomm's Worldmail server package, which has a stripped-down ACAP server there to provide initial configuration only. So don't expect Eudora to suddenly handle shared addressbooks, full roaming, etc. It does save you from remembering anything more than an ACAP server address, a username, and a couple of passwords, though.
Information regarding Eudora and a "true" ACAP server is hard to find. You've probably been wondering why - it's not as if it's a trade secret, it's simply that there's not been much interest. But I've noticed an increasing number of people finding the Infotrope site based on a Google search looking for information, hence I've put some here.
I should point out that I'd be unable to share this information with you if it weren't for the patience and tolerance of both Randall Gellens and Jeff Beckley, both Qualcomm/Eudora people, who hand-holded me through much of my experimentation with Eudora.
Download whatever the latest Infotrope ACAP Server is from here, unpack it, configure it, install it. Or find another one. I'm pretty sure that Communigate Pro's ACAP module might just about be up to handling this. Cyrus SML ACAPd will do as well.
Now just load in the data. It's fairly straightforward, isn't it?
Ah, okay. More detail might help.
Eudora will try to get the settings by logging in using CRAM-MD5, then issuing the SEARCH command: . search "/vendor.eudora/~/" return ("*") equal "entry" "i;octet" "settings"
This SEARCH expands the dataset to /vendor.eudora/user/<current userid>/, where <current userid> is the current session's authorization identifer, normally the same as the authentication identifier. For your purposes, loading the data, you'll want this to be whichever user you're changing settings for.
It's expecting to see a single ENTRY intermediate response come back, telling it about an ENTRY called "settings", which contains everything it wants to know.
The list of attributes is somewhat documented by Qualcomm/Eudora here, but be warned: This is documenting how Eudora 3 operates, not Eudora 4 and 5, nor the upcoming 6.
Several attributes have been changed, and here I list all the ones I use:
| ACAPServer | Tells Eudora which ACAP server to use. But wait! It's using it already! |
| ACAPUserID | Tells Eudora who to authenticate as for ACAP. Again, I'm not sure of the point. |
| AccessMethod | Either "POP" or "IMAP", this tells Eudora how to pick up mail. If you've gone to the trouble of setting up an ACAP server, I'm assuming you've got an IMAP server handy, so set this - the default is "POP", I think. |
| DomainQualifier | If you send a mail to "bob", this value gets added as the Domain, to make "bob@example.com", or whatever. |
| DSDefault | What Directory Services gateway protocol to use. "LDAP" or "PH", I think. (LDAP is understood, anyway). |
| ExtraNicknamesDir | Some extra directory for Eudora to look for addressbook files. Instant bug, it seems - Eudora doesn't understand backslashes in ACAP literals, and ignores the entire entry as a result. Scary stuff. Infotrope always sends strings containing characters from quoted-specials (Basically \ and ") as literals. Ho hum. |
| LDAPServer | Your LDAP server. |
| MailName | IMAP Authentication Identifier, or POP login. |
| MailServer | IMAP or POP Server. |
| RealName | Gets used in From: header. |
| ReturnAddress | Gets used in From: header, and MAIL FROM SMTP command during submission. |
| SMTPServer | The outgoing SMTP host. |
| UseACAPServer | I set this to "1", just to be on the safe side. |
Note that those attributes don't have the required "vendor.eudora." prefix on them. You'll unfortunately need to put them all in twice, once with, and once without, that prefix.
The reason is that a bug in Eudora 4-5 means that "quoted" values only get read without the prefix, and {7}
literal (*) values only get read with it. Infotrope ACAP Server does allow you to force attributes to be sent as literals, using the "hint" right of 0, but this is non-standard. To do it, just put in an ACL entry granting the "0" right to people. I do this by setting it in "dataset.acl" on every mentioned authzid there. It's an awful hack, but it solves the problem.
Sometimes, the settings won't work at all as a result. Oh, dear. Mostly this isn't the case, though, as the settings will be transmitted by Infotrope as quoted strings whenever it has a choice, since they're smaller than 1024 characters and don't contain naughty letters (The quoted-specials, \ and ", and CR, NUL, and LF).
Most of these settings will be the same for all users, so put them into the /vendor.eudora/site/ dataset (or a group dataset), and get the user's dataset to inherit from it.
As a final note, I've left out large numbers of settings - the full list is available in the WorldMail documentation, which in turn can be found on the Eduora website.
When configuring Eudora for the first time, tell it to use the ACAP server, with a suitable username and password. Eudora should find the settings, and display a précis of them. Don't accept them, there's another bug here. :-|
Instead, let Eudora quiz you about them all - you'll find they're all set correctly, and you can simply hit Next rather a lot.
On a running Eudora, you can simply go to the Autoconfiguration bit of the Settings dialog, fill in the details and let it update them all - it'll just "work".
These bugs will hopefully be fixed in later versions - it's worth noting that they were never spotted since they don't, apparently, affect WorldMail's autoconfiguration ACAP-a-like server, and the absence of any real installed base of ACAP servers has prevented anyone from noticing them to date.
As of 6.0.0.10, which I've just about finished testing, there's no changes to the ACAP code, with the interesting exception that Eudora 6 issues the LOGOUT command, whereas previous versions did not. This makes little difference to me, but it's nice all the same.
System Administrators may not see the benefit to doing any of this - after all, it's another server to install into the infrastructure, there's no new functionality, just a one-off saving of a few seconds for a new user.
Salesmen and Marketing folk may miss the point, too - no new feature, no fancy ability, and the damn protocol doesn't even have an X in the acronym.
However, Technical Support folk, who've had to talk novices and even relatively experienced computer users through setting and/or checking every option in Eudora associated with basic email access, will spot something pretty quick - they can now tell a user to go through one short procedure, and get good, working settings. This reduces their load, which in turn should reduce cost for an ISP or organisation.
Personally, I can see great things in the future for ACAP, hence my personal interest in the protocol - if more applications supported it, technical support loads would drop enormously, and hopefully this can reflect in better health for the internet industry, as well as lower costs for users.
* : Yes, this is ACAP humour. Since I'd quoted the word "quoted", I felt honour-bound to transmit the word literal as a literal. (And since this is coming from a server, I don't need to wait for your continuation request, so there.)