MailNews Core
18 years ago
5 years ago


(Reporter: (not reading, please use instead), Unassigned)




Firefox Tracking Flags

(Not tracked)


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

see 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 (Don McCuiston)
adding help wanted key word.
Keywords: helpwanted

Comment 2

17 years ago
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:[address]
Blocks: 11459
for 4.x details as well.

Comment 4

17 years ago
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.

Comment 5

17 years ago
Yes, definatly keep in mind what 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?



17 years ago
Keywords: 4xp
Hardware: PC → All

Comment 7

17 years ago
how is this bug different to bug 11459?

Comment 8

17 years ago
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...

Comment 9

17 years ago
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

Comment 10

17 years ago
It would be nice to *try* to target it even if it's not assigned.

Comment 11

17 years ago
can protozilla aid us here?

Comment 12

17 years ago
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

Comment 13

17 years ago
> 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.

Comment 14

17 years ago
> 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.

Comment 15

17 years ago
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.

Comment 16

17 years ago
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.

Comment 17

16 years ago
*** Bug 84968 has been marked as a duplicate of this bug. ***


16 years ago
QA Contact: lchiang → esther

Comment 18

16 years ago
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");

Maddes (user)

Comment 19

16 years ago
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.

Comment 21

16 years ago
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).

Comment 22

16 years ago
*** Bug 97566 has been marked as a duplicate of this bug. ***

Comment 23

16 years ago
On Windown you only need to "start" that URL
(, 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.

Comment 24

16 years ago 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
Whiteboard: [OSX+]

Comment 26

16 years ago
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?

Comment 27

16 years ago
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.

Comment 29

16 years ago
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.

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. 


16 years ago
Whiteboard: [OSX+] → [OSX]


16 years ago
Blocks: 107067


16 years ago
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


16 years ago
Whiteboard: [OSX]

Comment 32

16 years ago
changing to RFE.
Severity: normal → enhancement


16 years ago
No longer blocks: 107067

Comment 33

16 years ago
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/");

and have Muttzilla invoke my gsendmail program:

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

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

is supposed to do something, but I haven't looked into it yet.

Comment 35

16 years ago
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.

Comment 36

16 years ago
Ok, well, I tried to install this 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...

Comment 37

16 years ago
just to remind me that there's also a news flag,
outlook.html and it turns out that the MacOS pref is a bit different :-).

Comment 38

15 years ago
*** 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.)

Comment 41

15 years ago
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.

Comment 42

15 years ago
There's already a pref, albeit without any UI, to make this work on Mac &
Windows: <>

Comment 43

15 years ago
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.

Comment 44

15 years ago
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.

Comment 45

15 years ago
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. 

Comment 46

15 years ago
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://

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

Comment 47

15 years ago

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.

Comment 48

15 years ago
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.

Comment 49

15 years ago
> 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

Comment 50

15 years ago

(BTW: I am not saying that altmail is bad design or a bad API. Just that we have
other ways already to achieve the desired result, or almost have them.)
old API link:

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.
the reason why I want altmail with all the UI hooks is because if we pair that
with the stand alone mail work (see, 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


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

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.

Comment 55

15 years ago
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
Filter on "Nobody_NScomTLD_20080620"
QA Contact: esther → backend


9 years ago
Product: Core → MailNews Core
Resolving as WONTFIX with approval by Standard8 and Ratty.
Last Resolved: 5 years ago
Resolution: --- → WONTFIX


5 years ago

Comment 59

5 years ago
Just use mailto: handler
You need to log in before you can comment on or make changes to this bug.