Closed Bug 34819 Opened 24 years ago Closed 12 years ago

altmail support

Categories

(MailNews Core :: Backend, enhancement, P3)

Product:
MailNews Core
Component:
Backend
Type:
enhancement

Tracking

(Not tracked)

Status:
VERIFIED WONTFIX

People

(Reporter: sspitzer, Unassigned)

References

(
URL
)

Details

(Keywords: helpwanted, Whiteboard: This is for the altmail API only, compare bug 11459) 

see http://help.netscape.com/kb/consumer/19980630-3.html for more details.

it seems like we implement altmail easier in the new architecture than it was to
implement in the old architecture.

but, of course, no one has the time to spend on it.

starting this bug for amiga@eudoramail.com (Don McCuiston)
adding help wanted key word.
Keywords: helpwanted
when implementing altmail, there should be 4 options.
 1) mozilla's mailnews
 2) start a program with the mailto address as an arg (typical UNIX mailers)
 3) MAPI (some lame win32 API, apperantly)
 4) URL+expando to open a browser window to: foo.bar/compose.cgi?[address]
Would be cool if this was configurable seperatly for mail and news.
In unix atleast it is comon to use separate programs for mail and news.
Yes, definatly keep in mind what larhal@gdpc.se said. It must be configurable
seperatly for mail and news. It's not even uncommon on windows (eudora, forte's
agent, pegasus, more im sure). Im not familiar with Mac software, but I don't
doubt there are mail-only and news-only user agents there as well.
Could we use something like the "personal keywords" mechanism to do the URL part 
of this?

Gerv
Keywords: 4xp
Hardware: PC → All
how is this bug different to bug 11459?

11459 would like to use mail with mozilla and news with an external client if I
understand correctly.. actually bug 11459 should be dependant on this one since
it won't work if you can't even launch an external app...
Making bug 11459 "mailto: can launch external mail app or launch an url"
dependent on this one per Fabian. 

The high number of votes (17) really applies to this one, too.
Blocks: 11459
It would be nice to *try* to target it even if it's not assigned.
can protozilla aid us here?
Dependance: This bug should depend on the mailto: bug 11459 (not the other way
around), assuming that one is implemented via Protozilla (which seems to be the
current best bet). Protozilla can launch external apps already.

It seems to me like this bug asks for the following:
- Support for clients which use the Navigator Third Party Mail and News SDK
- (indirectly) Support for Simple MAPI

I suggest to file a separate bug for MAPI, depending on the other mailto: bug.

This will leave this bug to support the Navigator API (s.o.) only, which isn't
supported anymore since Netscape Comm. 4.5. I suggest WONTFIX, since third-party
apps can easily provide little shell scripts for Protozilla, which can be dumped
into a certain folder (e.g. via XPI), assuming Protozilla will be integrated
into Mozilla.
No longer blocks: 11459
> third-party apps can easily provide little shell scripts for Protozilla

Perhaps, but ordinary users can't. I should not have to fiddle around with a text 
editor, editing (or downloading) a shell script, in order for Navigator to use 
Claris Emailer (or whatever other unsupported e-mail program I happen to use).

Protozilla code should be used as a basis for extending the `Helper Apps' prefs 
to cover protocols as well as mime-types; but just bundling it with Mozilla and 
then considering this bug resolved would be very poor UI-wise.

> but ordinary users can't.

They won't hook up to the Netscape Mail API either. This is what we are talking
about here.

> would be very poor UI-wise

Was there UI for altmail? I don't think so.

I agree that we should supply a nice UI to select an alternative mailer. But
*this* is not the bug for it.

Re: MAPI Support versus mailto:

AFAICT, MAPI is being legacied by Microsoft in favor of a system protocol
registration for mailto:

On my box, this registration is stored in
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\mailto\shell\open\command. Unfortunately,
the only user interface is the Programs tab of the Internet Options control
panel. It's unfortunate that this is system-level setting in an otherwise
IE-specific control panel.

Netscape Communicator 4.7 registers itself as potential mailto: provider, and
works fine from internet protocol-aware applications such as MS Office 2000, and
even IE. Mozilla mail needs to provide equivalent functionality.

MAPI support would only provide two things: 
1) Allow you to send mail from older Windows programs that are only MAPI-aware
(such as Office 95 and 97) 
2) Allow older Mail clients (Eudora 3.x?) to be used with the Mozilla browser.
In short, by the time it was implemented, it would probably irrelevant.

For whatever it's worth, I think the correct fix on Windows is:
1) Mozilla should register itself as a potential mailto: (etc) provider
2) Implement a vendor-independent control panel to allow the user to set their
preferred programs for Internet protocols.
3) Have Mozilla respect these settings
4) Forget about MAPI

As a final note, this issue is a deployment problem in corporate environments
where there might not be SMTP mail access available. Opening a useless message
window when the user has specified Lotus Notes, MS Outlook, or even Netscape
4.7/iPlanet as their default mailer turns into a support issue.
Filed Bugzilla Bug 77846 All your internet properties should belong to us.

After that's fixed you should be able to pick mozilla for mail and news and a 
few other things.
*** Bug 84968 has been marked as a duplicate of this bug. ***
QA Contact: lchiang → esther
Need a way to use Eudora with Mozilla.

For Netscape 4.x I use the following settings in user.js:
user_pref("mail.use_altmail", true);
user_pref("mail.use_altmail_for_news", false);
user_pref("mail.altmail_dll", "EudoraNS.dll");

Did not test NS6.1 PR1 yet.

Would be great if Mozilla could support something similiar:
user_pref("mail.use_altmail", true);
user_pref("mail.use_altmail_for_news", true);
user_pref("mail.altmail_dll", "EudoraNS.dll");
user_pref("mail.altmail_dll_for_news", "FreeAgentNS.dll");

Regards
Maddes (user)

I tried to understand what someone of you meant with "installer problem" and
here is what I found out:

If you want to use another mail client or news client then do not install
Mozilla's mail/news component. This way 'mailto:' and 'news:' URLs are
handled by the OS default program, otherwise Mozilla will ALWAYS use its own
mail/news client.
Unfortunately I don't know a way to deactivate or deinstall the mail/news
component after installation. This also applies when you "install" Mozilla
through the non-installer ZIP archive.
So deinstall/remove Mozilla and reinstall only the wanted components with the
installer version.
Any help or information to deactivate the mail/news component after installation
is greatly appreciated.

Matthias Buecher, don't bother trying this in 6.x / mozilla.

altmail is not supported.

To Seth: I know, and when someone posted that 'mailto:'/'news:' URLs should be
given to the OS if there's no Mozilla mail/news client (this bug or a similar
one), I started playing around and found that "browser only solution" which
works fine (I use Eudora and a friend M$ Outlook).
*** Bug 97566 has been marked as a duplicate of this bug. ***
On Windown you only need to "start" that URL
(mailto:foobar@null.net?subject=test, for example). That should be *very* easy
to fix and it should also work for Mozilla's own mail/news, without any
additional code. Just make it launch the URL by default, Windown will take care
of the rest.

I don't know if Linux/other*NIXes/Mac support that kind of functionality.

There is no reason why not to take that 5-15 minutes of your time and fix it
now. I can't do it myself because I fortunately :) don't know anything about
Windown-programming (nor Mozilla code/structure) or have any compiler for Windown.
tronic2@sci.fi: AltMail is not the bug you are looking for. you are thinking of 
bug 11459.
would be nice to allow mozilla to work together with the OSX mail application as
well.
Whiteboard: [OSX+]
what are the chances someone will pick this up, so we can get it into 094? is 
this really and OSX+ show stopper, or just a nomination?
pinkerton are you saying OSX is using altmail? wow

anyway we haven't found someone to do this feature yet. Certainly not for the
094 branch. adding nsBranch-
Keywords: nsbranch-
oh, is altmail a particular win32 feature, or is it just the general term for
using an external 3rd-party mailer. If the former, we need to open a different
bug to use a 3rdparty mac mailer.
I thought it was a general term, as well. See my 2000-06-11 21:36 comment. If
it's some microsoft API, we need a seperate bug for UNIX too.
altmail was something we did in 4.x, for at least windows, linux and mac.

see http://developer.netscape.com/software/sdks/index.html?content=mailnews.html
I'm not sure how much of the old api (if any) we'd support going forward.
think of altmail as a way to integrate other mailnews clients into mozilla,
other than our mailnew client.  (for mailto: links, send page, etc.)

I think 4.x altmail would also launch the other mailer, if you did Tasks | Mail
& News.
Whiteboard: [OSX+] → [OSX]
Blocks: 107067
Keywords: nsbranch-
I'm only mentioning this because I don't see it listed anywhere in this bug
yet...  on Mac (either Mac OS 7/8/9 or Mac OS X) all you have to do to honor the
control-panel-chosen email client is post a Global URL (GURL) event to the
system that contains the complete url in mailto: format.

FWIW, Mozilla already knows how to send GURL events, since if I put in a
protocol that Mozilla doesn't support (like aim: for example) it correctly
launches the application set in the control panel to handle that protocol.  The
only thing needed to fix this on Mac, then, it to convince Mozilla not to try to
handle mailto: itself, and the rest will fall into place with the existing
mechanisms.
Whiteboard: [OSX]
changing to RFE.
Severity: normal → enhancement
No longer blocks: 107067
Just adding my vote for this -- I need this for my kiosks at DNA Lounge.  I have
a Navigator-only install, no Confusicator, and thus no built-in mail composition
tool.  In 4.78, I could do this:

  user_pref("mail.use_altmail", true);
  user_pref("mail.altmail_dll", "/usr/local/lib/muttzilla.so");

and have Muttzilla invoke my gsendmail program:

  http://www.jwz.org/gsendmail/
  http://www3.telus.net/brian_winters/mutt/

Without support for this, there is no way to use mailto links at all.

from http://www.hmetzger.de/net6e.html#49

user_pref("network.protocol-handler.external.mailto", true);

is supposed to do something, but I haven't looked into it yet.
mkaply has a patch to handle external protocols on non windows - windows 
already supports them :)

but that doesn't relate to altmail, which is a really spiffy intergation thing.
Ok, well, I tried to install this http://protozilla.mozdev.org/ thing, since
someone said that would let me add a binding for the "mailto:" URL that could
run my own program.  But its craptastic "Install" button didn't work, even when
I grabbed my ankles and ran the browser as root.

If someone (hi Dawn!) would like to explain to me how I can get this thing
installed on Linux and/or whether it's even worth trying to convince protozilla
to invoke gsendmail for me, that would go a long way toward making it feasable
for me to install Mozilla on the DNA Lounge kiosks...

just to remind me that there's also a news flag, http://www.ufaq.org/commonly/
outlook.html and it turns out that the MacOS pref is a bit different :-).
*** Bug 149329 has been marked as a duplicate of this bug. ***
taking back from nobody.  this is on the radar again.
Assignee: nobody → sspitzer
brain dump:

given that we can build with DISABLE_MAIL_NEWS, I think we're half way there.
(need to find out if Help UI does the right thing when you disable mailnews)

Then we could:

1)  if the user build with ENABLE_ALT_MAIL, we build mozilla/altmail
2)  add the necessary chrome and overlays to altmail.jar to create the necessary
UI for the browser, so it looks like it did when we built with mailnews.
3)  we might need a little bit of stub js (or C++) to do the right things when
the UI is hit.

the UI we have to add back:

1) mail icon in the task bar
2) addressbook icon in the task bar
3) "file | new | message" (simple mailto url?)
4) "file | send link" (simple mailto url?)
5) "file | send page" (might be harder than send link, not sure)
6) "window | mail and newsgroups", "window | addressbook"

maybe we won't add this back for altmail, or add it back conditionally:

7) "tools | search | messages", "tools | search | addresses" 

maybe altmail will be done to conditionally add back mail and / or addressbook UI.

there are already so prefs you can set to launch the default mailto protocol
handler, that will come in handy.  (we might need mozilla/altmail to produce
altmail.js and dump into the default prefs dir.)
Status: NEW → ASSIGNED
I'm not sure, if I understand you correctly (and I am still unclear about
comment 7 / 12). But I think it is important that a user can enable support to
launch a third-party mailer (esp. for mailto: link) with a pref switch only,
while still having Mozilla Mailnews installed. Maybe users will probably choose
to install "Complete" or want to install Mailnews to try it out and then decide
that they want to use another mailer as their default mailer.
There's already a pref, albeit without any UI, to make this work on Mac &
Windows: <http://www.mozilla.org/start/1.0/faq/mail-news.html#3.3>
oops, replied before seeing Seth's brain dump comment.  The pref I mentioned
only adds support for mailto:, the rest of the features Seth proposed would of
course require more work.
Re comment #40, let me clarify that *all* I want is for mailto: links to work
(launch an external program) on Unix.  I explicitly do not want all the rest of
that clutter: no mail icon in the dock, no "new message" menu item, no search,
none of that noise.

I don't want mozilla to be a mail reader, or pretend to be a mail reader.  I
just want to repair the handicap that mailto: links don't work.
In response to comment #42 : I think the pref does not work in the correct way. Right now you can choose to set it to Mozilla vs Not Mozilla, but I think it should be the option to choose Default System Settings vs Mozilla. (And either ask to use mozilla or respect the system settings by default - that's what system settings are for) 
At this moment, when system default is set to Mozilla but the pref is set to 'External app' it will use a non-mozilla app. 
PLEASE DON'T RESPOND TO THIS BUG. THIS BUG IS FOR DEVELOPMENT OF AN ALTMAIL
IMPLEMENTATION. If you don't know what altmail is then you shouldn't be
commenting in this bug. If you want something which doesn't behave like altmail
then you shouldn't talk about it in this bug. If you feel a need to respond
please try news://news.mozilla.org/netscape.public.mozilla.mail-news

seth: i've looked at this and i think that the mailto: handler should be moved
out of mozilla/mailnews. afaik it isn't vital to mailnews internally and as such
it should probably live in netwerk or it could live in extensions/altmail if we
decide to make altmail a required glue for mail (as it was in days of old).

Personally I'd like to be able to have one mozilla installed with 3 profiles,
one which relies on altmail, one which uses mozmail (yes that's two accounted
for, the third might do something else if we are flexible enough). Remember that
system administrators should be able to have a single global mozilla
installation and still allow their users to use either mailnews or altmail.

jwz's needs are satisfied both by mkaply's work and protozilla so I'd expect not
to hear further from him here unless we need information about how older
netscape navigators actually implemented altmail or how some altmail library was
implemented.
> PLEASE DON'T RESPOND TO THIS BUG. THIS BUG IS FOR DEVELOPMENT OF AN ALTMAIL
> IMPLEMENTATION. 

Blah blah blah.

> jwz's needs are satisfied both by mkaply's work and protozilla so I'd expect not
> to hear further from him here unless we need information about how older
> netscape navigators actually implemented altmail or how some altmail library was
> implemented.

Look, if there's another bug with the theme "mailto: doesn't work", I'd be happy
to comment there instead, but as far as I can tell, this bug is the only
relevant one.

Protozilla doesn't work, and is not, as far as I can tell, a real part of
Mozilla anyway.  

Tell me how to make mailto: work, and I'll leave you alone.

To address jwz's question, I don't know why the adding
ofuser_pref("network.protocol-handler.external.mailto", true); to user.js
doesn't work in a *nix build.  It should just make Necko toss mailto: links to
uriloader for processing by an external helper and it definitely works on the
Mac.  How that code works on *nix though I haven't a clue.

> Look, if there's another bug with the theme "mailto: doesn't work"

Bug 11459.


My question in comment 12 is still unanswered, from what I could see. I still
don't understand why we should support altmail at all.

From what I understood, altmail is an API for a DLL that can invoke third-party
mailers. So, 4.x called a certain DLL using that API (if enabled) to invoke
third-party mailers and that DLL then used other means (proprietary or standard)
to invoke a mailer. That API was created for 4.x, which also shipped a
implementation of it that invoked third-party apps via MAPI.

This is all fine and nice, but it is an API created for 4.x and I don't see a
need to support that particular API in Mozilla. Especially when considering the
following facts:

- mailto:-redirect to external apps (bug 11459) is reported by some people to
work on Win and Mac. Most likely, it would be easy to extend it for Unix,
working with Unix customs (e.g. invoking mailers by commandline+arg and possibly
other ways).
- I see lots of fixed bugs about MAPI [1] and others still open. Judging from
that, Simple MAPI seems to work. And I do see code for it in mozilla/mailews/mapi/.

So, unless there is some application that
- provides an altmail DLL implementation for to invoke itself *and*
- has no other supported (or easier supported) ways to be invoked *and*
- has a user demand to be supported
I think that there is no need to support that particular, old API and we should
WONTFIX this bug and concentrate on the other ways (bug 11459 and Simple MAPI).
Whiteboard: This is for the altmail API only, compare bug 11459
old API link: 
http://developer.netscape.com/software/sdks/index.html?content=mailnews.html

If we do this right, there is nothing stopping someone from implementing code
behind the UI hooks to use the existing, 4.x altmail API.
URL: http://developer.netscape.com/softwar... → http://www.mozilla.org/mailnews/altma...
the reason why I want altmail with all the UI hooks is because if we pair that
with the stand alone mail work (see
http://bugzilla.mozilla.org/show_bug.cgi?id=90293), we'd be right back to
something that looks and acts like mozilla, but with mail and browser in
seperate processes.

for jwz, and those who just install browser part of mozilla:
the reason the pref doesn't work on unix is that these two methods are not
implemented in mozilla/uriloader/exthandler/unix/nsOSHelperAppService.cpp

nsOSHelperAppService::ExternalProtocolHandlerExists()
nsOSHelperAppService::LoadUrl()

Here's an idea of how you could implement those that would be friendly to all
*nixes:

nsOSHelperAppService::ExternalProtocolHandlerExists(const char *
aProtocolScheme, PRBool * aHandlerExists) {
  // check if the environment variable "MOZILLA_" + toUpperCase(aProtocolScheme)
+ "_HANDLER" is set, and not empty.
}

nsOSHelperAppService::LoadUrl(nsIURI * aURL)
{
  // extract the url spec from the aURL
  // get the scheme from the url
  // get the enviroment variable for "MOZILLA_" + toUpperCase(scheme) + "_HANDLER"
  // if the env is non empty, do system() or exec() the value of the env
variable + " " + spec
}

Then all you'd have to do is:

setenv MOZILLA_MAILTO_HANDLER /usr/local/bin/gsendmail

the patch for bug 33282 also implements these methods (with hidden prefs for the
applications to use)
Christian, thanks for the info.

The suggested implementation #33282 of
nsOSHelperAppService::ExternalProtocolHandlerExists() and
nsOSHelperAppService::LoadUrl() uses prefs, instead of environment variables.

for those who want mailto: to work with just browser, see that bug.

now that we got that settled, this bug is back to being about altmail.
mmh kinda old school, but i think this will be more than resolved when we begin
with 1.5 (or whenever the plans of the new roadmap will be realized)
Product: MailNews → Core
sorry for the spam.  making bugzilla reflect reality as I'm not working on these bugs.  filter on FOOBARCHEESE to remove these in bulk.
Assignee: sspitzer → nobody
Status: ASSIGNED → NEW
Filter on "Nobody_NScomTLD_20080620"
QA Contact: esther → backend
Product: Core → MailNews Core
Resolving as WONTFIX with approval by Standard8 and Ratty.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → WONTFIX
v
Just use mailto: handler
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.