Re: Moving to a new machine

[Ray_Net]

rickman wrote on 27-01-18 01:23:
I had to give up on my on my old laptop (Lenovo piece of ...) and got 
a new one.  I want to move all my newsgroup files to the new machine. 
Oddly enough when I search on doing this I find info on moving 
Thunderbird.  They say to use Mozbackup.  Will that work with Seamonkey?


Otherwise they talk about copying the profile folder contents. Should 
that work ok with Seamonkey?



YES

I should copy what's inside this directory:
C:\Users\tit_p\AppData\Roaming\Mozilla\SeaMonkey\Profiles\ey8r9gln.default\

Or you copy
C:\Users\tit_p\AppData\Roaming\Mozilla\SeaMonkey\

note "tit-p" is my user-account-name.
___
support-seamonkey mailing list
support-seamonkey@lists.mozilla.org
https://lists.mozilla.org/listinfo/support-seamonkey

Moving to a new machine

[rickman]

I had to give up on my on my old laptop (Lenovo piece of ...) and got a new 
one.  I want to move all my newsgroup files to the new machine.  Oddly 
enough when I search on doing this I find info on moving Thunderbird.  They 
say to use Mozbackup.  Will that work with Seamonkey?


Otherwise they talk about copying the profile folder contents.  Should that 
work ok with Seamonkey?


--

Rick C
___
support-seamonkey mailing list
support-seamonkey@lists.mozilla.org
https://lists.mozilla.org/listinfo/support-seamonkey

Re: SeaMonkey cannot access a web site Chrome can.

[Paul B. Gallagher]

Rob Steinmetz wrote:

I have a remote site. The people at that site cannot access a internal 
website we use at another location. I have had the users clear their 
cache and try to access the site. Chrome on the same machines can access 
the site. They can ping the ip address.


I'm looking for a way to figure out what is causing SeaMonkey to not 
load the website.



Please define "can't access." Do they get a DNS error, a 404 error, a 
SeaMonkey certificate error, a blank page, or what? I assume DNS is fine 
if Chrome can access it and they can ping it. But you need to give the 
experts here some clues to work with.


--
War doesn't determine who's right, just who's left.
--
Paul B. Gallagher

___
support-seamonkey mailing list
support-seamonkey@lists.mozilla.org
https://lists.mozilla.org/listinfo/support-seamonkey

Re: SeaMonkey cannot access a web site Chrome can.

[NFN Smith]

Rob Steinmetz wrote:
I have a remote site. The people at that site cannot access a internal 
website we use at another location. I have had the users clear their 
cache and try to access the site. Chrome on the same machines can access 
the site. They can ping the ip address.


I'm looking for a way to figure out what is causing SeaMonkey to not 
load the website.



There's a variety of reasons that you could be having problems.  Proxy 
settings, as noted elsewhere, are potential, but I think unlikely.


You haven't mentioned whether you have any extensions installed. If you 
have something like one of the AdBlock variants, NoScript, etc., those 
could be causing problems.


In my own experience, absent problems with extensions, display issues 
tend to be profile-specific. Personally, I make extensive use of both 
AdBlock Plus, and NoScript, plus things like blocking of trackers and 
third-party cookies.  Thus, if I can't get whitelisting to work quickly, 
or have other quirks that cause display issues, I keep a second profile, 
where nearly all the settings are default. If switch to the second 
profile, I can't remember a time when I haven't gotten the display I 
would expect. That pretty clearly identifies my problem as something 
with my specific profile, rather a more general problem with Seamonkey.


The fastest troubleshooting tool is to go to Help -> Restart with 
Add-ons disabled.  That will reset your profile to mostly default 
preference settings, and disable all your extensions. And on occasion, 
I've found that a one-time use of Safe Mode is enough to clear problems. 
If problems persist when you go back to regular mode, then you need to 
start taking a look at your extensions. Try to isolate the extension 
that's having problems. Once you've found that, you want to disable (and 
perhaps try reinstalling the extension).


Smith

___
support-seamonkey mailing list
support-seamonkey@lists.mozilla.org
https://lists.mozilla.org/listinfo/support-seamonkey

Re: SeaMonkey cannot access a web site Chrome can.

[Richmond]

Rob Steinmetz wrote:
> I have a remote site. The people at that site cannot access a internal
> website we use at another location. I have had the users clear their
> cache and try to access the site. Chrome on the same machines can access
> the site. They can ping the ip address.
> 
> I'm looking for a way to figure out what is causing SeaMonkey to not
> load the website.

Maybe it is proxy settings.

___
support-seamonkey mailing list
support-seamonkey@lists.mozilla.org
https://lists.mozilla.org/listinfo/support-seamonkey

SeaMonkey cannot access a web site Chrome can.

[Rob Steinmetz]

I have a remote site. The people at that site cannot access a internal 
website we use at another location. I have had the users clear their 
cache and try to access the site. Chrome on the same machines can access 
the site. They can ping the ip address.


I'm looking for a way to figure out what is causing SeaMonkey to not 
load the website.

___
support-seamonkey mailing list
support-seamonkey@lists.mozilla.org
https://lists.mozilla.org/listinfo/support-seamonkey

Re: Version Numbers 52.0 or 52.6.0 in user agent

[WaltS48]

On 1/25/18 11:18 PM, Daniel wrote:

David E. Ross wrote:

On 1/25/2018 8:32 AM, WaltS48 wrote:

On 1/25/18 10:56 AM, David E. Ross wrote:

On 1/25/2018 3:44 AM, Daniel wrote:

David E. Ross wrote:

On 1/24/2018 7:51 PM, Daniel wrote:

Frank-Rainer Grahl wrote:

2.49.1 is based on ESR 52.4
2.49.2 should (hopefully) arrive in the next 2-3 weeks and will 
be based

on 52.6

Firefox does not show minor version numbers in its UA string.

52.5.3 ESR:
Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:52.0) Gecko/20100101
Firefox/52.0

2.49.2 x 64 local build:
Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:52.0) Gecko/20100101
Firefox/52.0 SeaMonkey/2.49.2

As you can see almost identical but as usual google and others 
will do

incorrect user agent sniffing.

FRG
That's interesting!! Being a long term SM user, it has always 
intrigued
me why the Gecko number has not been updated in yonks 
(20100101)... but
now I see that probably stems from FF, which also doesn't seem 
to update

its Gecko release date!!

Presumably the Gecko engine *HAS* actually been updated!! ;-P

Not updating the version date for Gecko in the user agent string 
is part
of Mozilla's plan to obscure user characteristics.  Web servers 
sniffing
user data supposedly find it harder to track individual users.  
See bug

#1329996 at .

I prefer relying on the Secret Agent extension from
.

Then one would have to wonder what use it is to have the Gecko 
version

with-in the User-Agent string at all!! ;-(


Some Web servers insist on sniffing the user agent string and expect
some kind of date for Gecko.  Mozilla-based browsers fail to work on
such Web sites unless there is a date field.


An example please.


I do not have an example.  I recall reading in a bug report (now
apparently closed) that omitting the Gecko date was causing problems
with Web servers that sniff the UA.

I seem to recall that some/many sites fail to function for SeaMonkey 
unless the SeaMonkey UA had FF in it ... in some cases *Only FF* in 
the SM UA


So why the mention, now, of some sniffing for Gecko?? Is that Gecko 
*only* or Gecko *as well* now??




Some light reading for you Daniel, and anyone else that might be interested.

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/User-Agent

Enjoy!

___
support-seamonkey mailing list
support-seamonkey@lists.mozilla.org
https://lists.mozilla.org/listinfo/support-seamonkey

Re: Version Numbers 52.0 or 52.6.0 in user agent

[Daniel]

David E. Ross wrote:

On 1/25/2018 8:18 PM, Daniel wrote:

David E. Ross wrote:

On 1/25/2018 8:32 AM, WaltS48 wrote:

On 1/25/18 10:56 AM, David E. Ross wrote:

On 1/25/2018 3:44 AM, Daniel wrote:

David E. Ross wrote:

On 1/24/2018 7:51 PM, Daniel wrote:

Frank-Rainer Grahl wrote:

2.49.1 is based on ESR 52.4
2.49.2 should (hopefully) arrive in the next 2-3 weeks and will be based
on 52.6

Firefox does not show minor version numbers in its UA string.

52.5.3 ESR:
Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:52.0) Gecko/20100101
Firefox/52.0

2.49.2 x 64 local build:
Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:52.0) Gecko/20100101
Firefox/52.0 SeaMonkey/2.49.2

As you can see almost identical but as usual google and others will do
incorrect user agent sniffing.

FRG

That's interesting!! Being a long term SM user, it has always intrigued
me why the Gecko number has not been updated in yonks (20100101)... but
now I see that probably stems from FF, which also doesn't seem to update
its Gecko release date!!

Presumably the Gecko engine *HAS* actually been updated!! ;-P


Not updating the version date for Gecko in the user agent string is part
of Mozilla's plan to obscure user characteristics.  Web servers sniffing
user data supposedly find it harder to track individual users.  See bug
#1329996 at .

I prefer relying on the Secret Agent extension from
.


Then one would have to wonder what use it is to have the Gecko version
with-in the User-Agent string at all!! ;-(


Some Web servers insist on sniffing the user agent string and expect
some kind of date for Gecko.  Mozilla-based browsers fail to work on
such Web sites unless there is a date field.


An example please.


I do not have an example.  I recall reading in a bug report (now
apparently closed) that omitting the Gecko date was causing problems
with Web servers that sniff the UA.


I seem to recall that some/many sites fail to function for SeaMonkey
unless the SeaMonkey UA had FF in it ... in some cases *Only FF* in the
SM UA

So why the mention, now, of some sniffing for Gecko?? Is that Gecko
*only* or Gecko *as well* now??



The servers were not sniffing specifically for "Gecko".  When they
sniffed, however, they were programmed to expect certain fields in the
UA string.  One of those fields was the Gecko date, but they did not
parse the date.  Instead, any date in that position of the UA string was
acceptable.

Why bother sniffing for something and then not use it?? Some programmers 
must like to waste time!!


Thanks, David.

--
Daniel

User agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 
SeaMonkey/2.49.1 Build identifier: 20171016030418


User agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 
SeaMonkey/2.49.1 Build identifier: 20171015235623

___
support-seamonkey mailing list
support-seamonkey@lists.mozilla.org
https://lists.mozilla.org/listinfo/support-seamonkey

Re: Expired certificates in the Builtin Object Token

[Mason83]

On 25/01/2018 13:41, Andrey Shcheglov wrote:

> I see a number of expired certificates under Builtin Object Token
> (vanilla SeaMonkey 2.46 and 2.49.1, fresh user profile):
> 
> https://habrastorage.org/webt/5d/ay/ch/5daychmswvrkawglzjk68bp7vfa.png
> 
> If I delete those, they reappear under the "Others" tab:
> 
> https://habrastorage.org/webt/xa/2q/is/xa2qisg6arve5xwmc6tmpcmwrqw.png
> 
> The certificates are expired (expiration year is 2014, below is an
> example for https://addons.mozilla.org):
> 
> https://habrastorage.org/webt/5f/ry/ox/5fryoxyqavfrl6hcibhnsbzjxuw.png
> 
> They, naturally, differ from their effective counterparts of the said
> web sites:
> 
> https://habrastorage.org/webt/rs/rq/we/rsrqwev0r-wnaujxrpacyf-s0s4.png
> 
> What's the need for those?

These are all "fake" certificates, dating back to 2011, wrongly issued
by Comodo.

https://www.wired.com/2011/03/comodo-compromise/
https://en.wikipedia.org/wiki/Comodo_Group#Certificate_hacking

In SM, I think they store the fact that they should NOT be trusted.

However, since they are now expired, I'm not sure they are needed anymore;
or maybe it is to flag the use of the fake certs. Maybe a cert specialist
can explain that better :-)

Regards.
___
support-seamonkey mailing list
support-seamonkey@lists.mozilla.org
https://lists.mozilla.org/listinfo/support-seamonkey

Re: X-No-Archive set to No automatically?

[Yamo']

Hi,

Andreas Bockelmann a écrit le 26/01/2018 à 08:33 :
> Hello,
> 
> maybe I'm false, but I remember that I had a setting in Seamonkey which sets 
> Header 'X-No-Archive' to 'Yes' automatically and per default. Current 
> version seems not to have this feature. Can anybody advise how to set this 
> header automatically?


You can follow this page : 


-- 

Sorry for possible mistakes in English!
http://pasdenom.info/
___
support-seamonkey mailing list
support-seamonkey@lists.mozilla.org
https://lists.mozilla.org/listinfo/support-seamonkey