Determine user's default email client

[Richard Cornford]

You're being obtuse! You put a mailto link in a web page to
open an e-mail client to facilitate communication and you
know that!

I am not being obtuse, I am looking at the design requirement before
considering the mechanisms by which it might best be achieved. The
design requirement is to facilitate communication; achieving that is the
goal of any implementation, and preferably doing so reliably.

As you have a list of conditions under which a form based
email will fail where a mailto will succeed. What's your point?

Where is such a list?

Observed actually


And you can have the web server fail or run out of space
whereas the mail server is churning out and in emails. There
are many possibilities, none of which you've considered.

There are no types of application server failure that mail servers are
not equally susceptible to.

Obviously. Again, what's your point? I'm assuming that the
person can indeed send email. You're assuming the person
can indeed browse.

You assumption is known not to hold for all client-side systems, while
whenever an individual has accessed a web-page with either a mailto link
or a mail form over the internet the ability to browse has been
demonstrated.

Sure there is! Open up your mind a little bit!

Open my mind to what exactly? You have proposed no limitations imposed
by the use of an e-mail form on a web page, and I don't see how you
could because the existence of a form, and the server-side code to back
it up, does not preclude either the possibility of short-circuiting the
submission of the mail into a background post using XML HTTP Request
objects (where supported) or the provision of a mailto link in addition.
Layering alternatives over a reliable foundation is not restricted by
anything but the capabilities of the client, and certainly not by the
existence of the reliable foundation.

Richard.

 

[Randy Webb]

You're being obtuse! You put a mailto link in a web page to open an
e-mail client to facilitate communication and you know that!

No, its put there in the *hopes* that it opens an email client (if it
even exists on the system). The same is not true of a form as there is
nothing to open.

As you have a list of conditions under which a form based email will
fail where a mailto will succeed. What's your point?

No, he listed things that will cause either or both to fail. The same
list is inclusive of forms, but not to mailto: as there are more things
that can fail with mailto: than with forms. Perhaps you should re-read
what he said and pay attention to the part that says "an equal impact on
normal e-mail traffic".

Observed actually

Not near as many times as I have observed a mailto: link not working
properly.

And you can have the web server fail or run out of space whereas the
mail server is churning out and in emails. There are many possibilities,
none of which you've considered.

Yes, he even listed them. As there is no need to save the emails on the
server, thats a non-issue. If the server is set up properly to handle
it, then the email is not "saved", it is forwarded (emailed) to an
inbox. Whereas it becomes part of the normal email system. The
difference (which you refuse to admit) is the reliablity of the
mechanism used to get the information into the email system.

Obviously. Again, what's your point? I'm assuming that the person can
indeed send email. You're assuming the person can indeed browse.

And one method is more reliable than the other. You just refuse to "open
your mind" (your own words) and realize it.

Sure there is! Open up your mind a little bit!

Ummm, what limitations are imposed by facilitating reliable communication?



--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq
Answer:It destroys the order of the conversation
Question: Why?
Answer: Top-Posting.
Question: Whats the most annoying thing on Usenet?

 

[Andrew DeFaria]

I am not being obtuse, I am looking at the design requirement before
considering the mechanisms by which it might best be achieved. The
design requirement is to facilitate communication; achieving that is
the goal of any implementation, and preferably doing so reliably.

And as I've told you countless times now, mailto links facilitate
communications just fine for me and millions of others. I've also
pointed out that your web based form email also has failure points.

^^ ^^^^^ ^^^^^^ ^^ ^^^^^^ ^^^^^^ ^^^^^^^


Where is such a list?

I'm not sure. I thought you had it!

But seriously you're pointing out failure points for mailto links which
is your list. I'm saying there are failure points for web based email
too, which would be my list.

There are no types of application server failure that mail servers are
not equally susceptible to.

Yes that is unless the web server is on host A and it's trashed while
the email server is on host B which is working just fine. And there are
many other ways that even if the two services are coexisting on the same
system where one is down and the other is still providing service.

You assumption is known not to hold for all client-side systems, while
whenever an individual has accessed a web-page with either a mailto
link or a mail form over the internet the ability to browse has been
demonstrated.

Not necessarily the case. Some browsers don't even support forms
(ancient I agree but true nonetheless). Also many other browsers have
problems navigating through proprietary only web sites, for example.
Finally it is possible that a person has configured his email client but
lacks a browser, yet the email he just received has a link that he
cannot browse to! Again there many forms of failures.

Open my mind to what exactly?

To the fact that you ain't got 100% reliability either.

You have proposed no limitations imposed by the use of an e-mail form
on a web page, and I don't see how you could because the existence of
a form, and the server-side code to back it up, does not preclude
either the possibility of short-circuiting the submission of the mail
into a background post using XML HTTP Request objects (where supported)

Or using an bona fide email client (again, where supported! ;-) )

or the provision of a mailto link in addition.

In addition is cool. We've already established that.

 

[Andrew DeFaria]

No, its put there in the *hopes* that it opens an email client (if it
even exists on the system). The same is not true of a form as there is
nothing to open.

Likewise you are hoping that the browser can indeed navigate your site
and support forms.

No, he listed things that will cause either or both to fail. The same
list is inclusive of forms, but not to mailto: as there are more
things that can fail with mailto: than with forms. Perhaps you should
re-read what he said and pay attention to the part that says "an equal
impact on normal e-mail traffic".

Again, the web server can be on host A and have filled disks whereas the
mail server can be on host B and have tons of space.

Yes, he even listed them. As there is no need to save the emails on
the server, thats a non-issue. If the server is set up properly to
handle it, then the email is not "saved", it is forwarded (emailed) to
an inbox.

And in the meantime it hangs out in mqueue and often has other people's
mbox's on them that tend to grow without bound.

Whereas it becomes part of the normal email system. The difference
(which you refuse to admit) is the reliablity of the mechanism used to
get the information into the email system.

All I'm saying is that failures can happen in both methods and neither
is 100%.

And one method is more reliable than the other. You just refuse to
"open your mind" (your own words) and realize it.

I haven't seen any data to support that point. I've had far more
failures with web sites and their email forms than I've ever had with my
email client. YMMV, however, mine hasn't!

Ummm, what limitations are imposed by facilitating reliable
communication?

His assumption is that it's 100% reliable and that's not true.

 

[Michael Winter]

[snip]

Likewise you are hoping that the browser can indeed navigate your site
and support forms.

WTF? How do you propose that a mailto: link would be of more use here then?

This is why I find this thread so annoying. You aren't arguing on the same
grounds. This debate is based upon communication initiated from a web
page. Anything else is irrelevant, and your point is a prime example of
that.

Personally, I think this thread should end. If it ever had a purpose, it's
certainly lost it now.

[snip]

All I'm saying is that failures can happen in both methods and neither
is 100%.

And who said otherwise? Of course both methods can fail, but the majority
of those failures - server errors, power cuts, etc - are beyond the
control of both the developer and the user. However, what the developer
can control is how communication is initiated.

The problem with mailto:, and the whole basis of the debate in this
thread, is that it makes an unreasonable assumption about the user's
configuration; that they have a default mail client associated with the
browser. A form does not make any assumptions. It is entirely reasonable
to expect a browser to support forms as they have been part of the HTML
Specification for years.

There is no reason why a mailto: link cannot appear on a page, but it
should not be solely relied upon for communication. Why is that so
difficult to accept?

[snip]

Mike

 

[Dr John Stockton]

JRS: In article <[email protected]

, dated Wed, 13 Oct 2004 18:38:03, seen in news:comp.lang.javascript,

One out of every three Americans is suffering from some form of mental
illness. Think of two of your best friends. If they are OK, then it must
be you.

Yet more false logic. 95% of the world population does not directly
have that problem - though it may well question the accuracy of "One out
of every three".

 

[Andrew DeFaria]

WTF? How do you propose that a mailto: link would be of more use here
then?

I never proposed that. I'm simply pointing out that there are situations
where your scenarios fails too. I agree that if you can't navigate the
site then you can't navigate the site. However there are sites that are
not navigatable by one browser, say Mozilla, because the developer chose
a form approach along with some proprietary features of a particular
browser, say IE, and that user is then impeded from being able to email
(i.e. communicate) whereas his browser of choice (Mozilla) has an email
client that works fine and a mailto link instead of the proprietary IE
only web based form (not that Mozilla can't handle forms too rather the
parts used in the form are say Active X controls or some other IE only
dohicky) would have worked just fine. IOW this is a situation that fails
your "forms are 100% reliable" assertion. And I've actually had quite a
few instances where this was the case for me.

This is why I find this thread so annoying. You aren't arguing on the
same grounds. This debate is based upon communication initiated from
a web page. Anything else is irrelevant, and your point is a prime
example of that.

You apparently do not understand my point.

Personally, I think this thread should end. If it ever had a purpose,
it's certainly lost it now.

The power to end this thread for you personally was within your grasp
from the beginning. If you do not wish to discuss this then simply stop.

[snip]

All I'm saying is that failures can happen in both methods and
neither is 100%.

And who said otherwise? Of course both methods can fail, but the
majority of those failures - server errors, power cuts, etc - are
beyond the control of both the developer and the user. However, what
the developer can control is how communication is initiated.

It was you would asserted form email is 100% reliable. I'm just refuting
that statement.

The problem with mailto:, and the whole basis of the debate in this
thread, is that it makes an unreasonable assumption about the user's
configuration; that they have a default mail client associated with
the browser. A form does not make any assumptions. It is entirely
reasonable to expect a browser to support forms as they have been
part of the HTML Specification for years.

The problem with web based email forms is that they too make several
assumptions. They assume that the browser supports forms (probably a
pretty safe assumption) and that the web server, email server, etc are
all functioning. They also assume they have not put up other impedemints
for the user to huddle including browser differences and proprietary
controls.

There is no reason why a mailto: link cannot appear on a page, but it
should not be solely relied upon for communication. Why is that so
difficult to accept?

I agree that there is no reason why a mailto: link cannot appear. In
fact many sites have them for contacting support, sales, web masters,
etc. I do not recall in the problem definition that we are relying
_solely _on a mailto link. Who said that?

 

[Michael Winter]

I never proposed that.

I never said you did. It was a rhetorical question, implying that both
would be equally useless.

I'm simply pointing out that there are situations where your scenarios
fails too.

I know there are. Did you read my post properly? From what you've written
here, and later, I have reason to doubt that.

I agree that if you can't navigate the site then you can't navigate the
site. However there are sites that are not navigatable by one browser,
say Mozilla, because the developer chose a form approach along with some
proprietary features of a particular browser, say IE, [...]

If a developer makes something as simple as a form submission proprietary,
then that developer is a moron. This "argument" would fall under the "what
the developer can control" catagory I mentioned.

[snip]

You apparently do not understand my point.

No. I can't say I've witnessed you make a point, thus far (except things
I've already stated).

[snip]

It was you would asserted form email is 100% reliable. I'm just refuting
that statement.

When did I say that? Read the paragraph you just quoted. I said both
methods can fail, but some things are more reliable than others.

The problem with web based email forms is that they too make several
assumptions. They assume that the browser supports forms (probably a
pretty safe assumption)

I already stated that.

and that the web server, email server, etc are all functioning.

No-one has control over that. A mailto: link would fail if my mail server
was dead, too. I already know this and stated it (I'd count it as a server
error).

They also assume they have not put up other impedemints for the user to
huddle including browser differences and proprietary controls.

As I said: a developer that would do this is an idiot. I know there are
plenty of them around, but that is no reason to decry a method because of
moronic implementation, when the method itself is sound.

[snip]

I do not recall in the problem definition that we are relying _solely
_on a mailto link. Who said that?

It's implicit. It is the reason why the "solid advice" that Randy was
referring to at the start of this thread exists. People do rely solely
upon mailto:, and when it fails, communication doesn't occur. I haven't
seen the subject diverge, so if that hasn't been the basis of your
argument, then what on Earth are you talking about? Perhaps if that is
understood, this thread can, indeed, end.

Mike

 

[Andrew DeFaria]

If a developer makes something as simple as a form submission
proprietary, then that developer is a moron. This "argument" would
fall under the "what the developer can control" catagory I mentioned.

That's all fine and good however you do realize that the world is full
of morons...

No. I can't say I've witnessed you make a point, thus far (except
things I've already stated).

Well if you can't understand it then there is nothing more that I can do.

When did I say that? Read the paragraph you just quoted. I said both
methods can fail, but some things are more reliable than others.

I thought it was you that stated that form based email is 100% reliable.
If so then sorry. In any event each method can and does fail and each
method has it's pluses and minuses.

I already stated that.


No-one has control over that. A mailto: link would fail if my mail
server was dead, too. I already know this and stated it (I'd count it
as a server error).

Yes and that's part of my point. You don't have control over whether or
not the end user has configured his email client so that mailto would
succeed. Similarly you (often - some do) don't have control over whether
or not the mail server is up or the web sever is up. So then we are
arguing whether it is more common that a mailto link will fail or that a
web email form will fail. And with that I think we can simply agree to
disagree.

As I said: a developer that would do this is an idiot. I know there
are plenty of them around, but that is no reason to decry a method
because of moronic implementation, when the method itself is sound.

My decrying of web base email systems was already enumerated.
Reliability was not high on the list for me. But as has been said before
the solution is simple - provide both!

It's implicit.

No it was not at all implicit!

It is the reason why the "solid advice" that Randy was referring to
at the start of this thread exists. People do rely solely upon
mailto:, and when it fails, communication doesn't occur. I haven't
seen the subject diverge, so if that hasn't been the basis of your
argument, then what on Earth are you talking about? Perhaps if that
is understood, this thread can, indeed, end.

The thread can easily end from your perspective at any time by merely
ignoring it.

 

[kaeli]

Yet more false logic. 95% of the world population does not directly
have that problem - though it may well question the accuracy of "One out
of every three".

Who stole your sense of humor?
You really ought to try to get it back.

--
--
~kaeli~
Frisbeetarianism (n.), The belief that, when you die, your
soul goes up on the roof and gets stuck there.
http://www.ipwebdesign.net/wildAtHeart
http://www.ipwebdesign.net/kaelisSpace

 

[Andrew DeFaria]

Who stole your sense of humor? You really ought to try to get it back.

I think he lost it on his way to get a PhD! ;-)

 

[Randy Webb]

Likewise you are hoping that the browser can indeed navigate your site
and support forms.

OK, here's your chance. Name a browser that does not support forms that
is less than 10 years old. Otherwise, you are beating a dead horse. You
are also assuming that I make my forms/navigation browser dependent when
I don't. I probably test in more browsers than most people even know exist.

Again, the web server can be on host A and have filled disks whereas the
mail server can be on host B and have tons of space.

And the vice versa is true. Thats another case of you beating a dead
horse. Anything that can impact a form can also impact the reliability
of a mailto:. The difference is there is one thing that can impact a
mailto: that does *not* impact a form. Thats the configuration of a
email-client on the client. Thats *two* pieces of software needed where
a form only needs one. You keep missing/ignoring that important difference.

And in the meantime it hangs out in mqueue and often has other people's
mbox's on them that tend to grow without bound.

That same limitation applies to mailto:, so its another dead horse you
are beating.

All I'm saying is that failures can happen in both methods and neither
is 100%.

I have never said either is 100%. I said mailto: will fail more often
than a form will.

I haven't seen any data to support that point. I've had far more
failures with web sites and their email forms than I've ever had with my
email client. YMMV, however, mine hasn't!

Now you want data. Geez. OK, here's you some data. AOL membership is
currently approximately 40 million users. The web-user base is estimated
at 200 million. That puts AOL users at about 20% of the market. The
mailto: example given on the MSDN site, that I posted here, does *not*
work in the AOL software. Thats ~20% of users that can not communicate
with you because of the mailto: link used. Your turn. Show some data on
browsers that do not support forms and submission. I genuinely want to
see that data.

His assumption is that it's 100% reliable and that's not true.

I personally disagree with the "100%" reliable. Nothing is 100%
reliable, simply because of the way that the web works. What I *will*
say is that, until proven otherwise, pure common sense says that forms
are more reliable than mailto:. Of course, you are welcome to attempt to
prove me wrong by naming some browsers, less than 10 years old, that do
not support forms.

 

[kaeli]

No I have acknowledged it many times. I just happen to believe that most
people who use a browser also use an email client.

I think *most* overstates it.

Out of all the people in my family who go online (6), I am the ONLY ONE with
a default e-mail client. I am the ONLY ONE who uses Outlook. I've been trying
to get my parents to use it, but they prefer the web-based mail. Gods know
why.

People who use the following as their primary mail will not appreciate mailto
links, either, since even though they may have a default mail client, they
probably don't use it:
yahoo
hotmail
gmail
anyone who has internet based ISP mail (we use comcast and AT&T)

People at internet cafes, libraries, and schools will also hate you.

You are bound to interpret the world from what you see around you. Have you
ever polled people to see if they use a default client? People who aren't
major computer users who frequent Usenet?

--

 

[Andrew DeFaria]

I think *most* overstates it.

Yes we can get into a disagreement about the degree and size of each
population.

Out of all the people in my family who go online (6), I am the ONLY
ONE with a default e-mail client.

Let me guess, you're also probably the only one who really knows how to
use a computer.

I am the ONLY ONE who uses Outlook.

My sincerest condolences! ;-)

I've been trying to get my parents to use it, but they prefer the
web-based mail. Gods know why.

Exactly, god knows why.

People who use the following as their primary mail will not appreciate
mailto links, either, since even though they may have a default mail
client, they probably don't use it:
yahoo
hotmail
gmail
anyone who has internet based ISP mail (we use comcast and AT&T)

IOW web based email. Yes I know this, been saying it all along actually.
Again we just disagree as to the extend of each population.

People at internet cafes, libraries, and schools will also hate you.

That's their perogative.

You are bound to interpret the world from what you see around you.

As has you here.

Have you ever polled people to see if they use a default client?
People who aren't major computer users who frequent Usenet?

Most of the people I know use some sort of email client. Some have
gotten into web based email clients too like you mention above. Still
most of them know how to, have installed and configured some sort of
default email client.

 

[Dr John Stockton]

JRS: In article <[email protected]

, dated Thu, 14 Oct 2004 14:06:51, seen in news:comp.lang.javascript,

A couple of points there doc:
1. It's a tagline! Intended to be funny!
Failure.

2. Explaining or analyzing jokes just proves that you didn't "get
it".
3. It did say Americans did it not?

It did.

4. America is not 95% of the world population!

It is not; it is approximately 5%. Now read what you wrote with
intelligence and thoughtfulness. If the first sentence is assumed to be
true, then the second and third considered jointly follow logically only
if the people that you are addressing, and their best friends, are
Americans. But the majority of the readers of this newsgroup are non-
Americans, and the same will generally be true of their best friends.

You illustrate thereby a typical American attitude; one which needs to
be remedied if your country is not to continue to lose what friends it
still has.

 

[kaeli]

Let me guess, you're also probably the only one who really knows how to
use a computer.

Yup.
They all know just enough to be dangerous.

My sincerest condolences! ;-)

LOL
Hey, _I_ like it. But I also know how to turn off scripting, run in safe
security zone, and all that jazz. I've never had any problems with it.
I also have a good anti-virus program. *heh*

Most of the people I know use some sort of email client. Some have
gotten into web based email clients too like you mention above. Still
most of them know how to, have installed and configured some sort of
default email client.

I meant the people who actually use whatever site this thread originally was
talking about, if any. I didn't read the whole thing. I'm not gonna. *g*

I mean, if 95% of my users had a default mail client, I'd feel fine using
mailto. I use it here at work. Everyone here has, and uses, Outlook.
But if you don't know who uses your stuff, you really can't generalize about
them much at all. You have to guess, based on what kind of site it is and
stuff.

My only point was that you really can't say who uses what out there and that
mailto makes an assumption many of us don't like to make - the existence of a
default mail client (that they actually use) on the user's computer.

We now return you to your regularly scheduled mailto vs. forms debate.

--

 

[Randy Webb]

According to http://cnn.netscape.cnn.com/news/storymain.jsp?number=1:

In April of 1995 Netscape 1.1 was released. The new browser added
table support as well as many of its own new HTML elements and
attributes. By the middle of that year most WWW users on the
Internet were using Netscape's browser.

I don't believe it had form support back then.

I don't believe it had support for mailto: either. But its irrelevant.
When you have to go back 9 1/2 years to find a browser that doesn't
support forms and I only have to go back 1 day to find a browser that
doesn't handle mailto: properly, I will stick with the form.

You do but many others don't.

That doesn't break the form nor navigation aspects. Its the
implementation of a stupid/ignorant web author that breaks it. Not the
basic functionality of it.

That's you - not everybody.

As many IE-only sites as I encounter, I agree 100%.

Not at all. They both have problems ergo neither are 100% reliable.

I have never said either was 100%. I said the form was *more* reliable
than a mailto:

Not true. A form could, for example, want you to fill out a drop down
and get the entries for a drop down from a database. The database can be
experiencing a problem thus the form fails. Whereas a mailto is
unaffected by this.

Thats not the form itself breaking. Thats the moronic/ignorant web
author making it dependent on something that may or may not be
available. It still doesn't change the reliability of the form itself.

No I have acknowledged it many times. I just happen to believe that most
people who use a browser also use an email client. I've heard tales that
email is more frequently used than the web - not sure if I believe that.
While I do know people who *also* use web based email solutions, I don't
know of a single person who relies solely on web based email. IOW,
they've all got an email client and it's configured.

Well, you can stop saying you don't know of a single person who relies
solely on web based email. I am one of them in one scenario, not one in
another. When I am at work, it is 100% web-based. And for my personal
primary email address, it is web-based as well. And it simply can *not*
be set up with an email client.

That's your opinion. My opinion is that I've had far more failures with
web based forms than mailto.

And based on your personal experience, you say that mailto: is reliable.
But based on *my* personal experience, mailto: breaks more often.

That proves nothing except for market share. How's that relevant?

As long as you quote it out of context, nothing. Quoted in its original
context, which was a precursor to my next statement, it shows that ~20%
of the people on the web can not use that mailto: link.

Didn't see your example. Is that just an <a
href="mailto:emailaddress">click here</a> style of mailto link? I'm
shocked that such a thing doesn't work for AOL users!

No, the code that I posted can be viewed here:

<URL:
http://msdn.microsoft.com/library/default.asp?url=/workshop/networking/predefined/mailto.asp
/>

But are you saying you have problems with this form:

<form action="emailIt.php">
<input type="text" name="emailAddress" size="80">
<input type="text" name="subjectLine" size="80">
<textarea rows="80" cols="200"></textarea>
<input type="submit" value="Send Email">
</form>

If so, you need a new browser.

I cannot tell which browsers people are using.

Nor can you tell which email client they have installed nor how it will
react to a mailto: that contains more than an email address. And that
seems to be the predominate use that I have seen of them is when the
page author attempts to fill out the from, to, subject and body of the
email.


The best solution, that has been posted at least twice, is to offer
both. But in the event I only offer one, it will always be a form until
something happens to change my mind.

As I said, YMMV but my "milage" and experience does not vary from what
I've experienced. Sorry if that's a tough nut to swallow.

Not a tough nut to swallow. I have no problems with the fact that you
have never had trouble (maybe minor ones). But when you claim that based
on your experience that a form is less reliable than mailto then it gets
beyond a nut to swallow. Not when the majority of
articles/posts/webpages I have read on them speak directly to the
unreliability of the mailto: based simply on the fact that you have no
way of knowing how, even if it will, react to the mailto: the way you
think it will.

 

[Andrew DeFaria]

LOL
Hey, _I_ like it. But I also know how to turn off scripting, run in
safe security zone, and all that jazz. I've never had any problems
with it.I also have a good anti-virus program. *heh*

Well then my condolences that you actually like it!

But it does speak volumes that you have to go through all of that just
to protect yourself. Me, I use Netscape/Mozilla/Thunderbird. Have for
years. Never use an AV program. Never had to. Never got a virus. And no,
I'm not just lucky.

I meant the people who actually use whatever site this thread
originally was talking about, if any. I didn't read the whole thing.
I'm not gonna. *g*

Well I didn't. I was speaking in the more general sense.

I mean, if 95% of my users had a default mail client, I'd feel fine
using mailto. I use it here at work. Everyone here has, and uses, Outlook.

More condolences are in order... ;-)

But if you don't know who uses your stuff, you really can't generalize
about them much at all. You have to guess, based on what kind of site
it is and stuff.

My only point was that you really can't say who uses what out there
and that mailto makes an assumption many of us don't like to make -
the existence of a default mail client (that they actually use) on the
user's computer.

Again, the solution is simple - provide both. A mailto link is but a few
characters to code.

 

[Michael]

kaeli wrote:
But it does speak volumes that you have to go through all of that just
to protect yourself. Me, I use Netscape/Mozilla/Thunderbird. Have for
years. Never use an AV program. Never had to. Never got a virus. And no,
I'm not just lucky.

Don't forget to get the latest updates to those programs... There was about
4 bugs just released about them...

Mike

 

[Andrew DeFaria]

Don't forget to get the latest updates to those programs... There was
about 4 bugs just released about them...

Thanks for your concern however I do keep up with the latest (which you
would have known if you had checked the headers). And 4 bugs do not
translate to 4 gaping security holes. Many security type advisements are
about what might possibly be possible for an extremely talented hacker
and often are not ever exploited. Just because a buffer overrun is
possible does not mean that it is at all easy to then "take over"
another person's computer - more just that the possibility is there.