Re: [Mozilla Enterprise] Naming the installation files

[Paul Kosinski via Enterprise]

The Linux versions of Firefox have been named differently ("x86_64" vs
"i686") for a long time, so it should be easy enough to name the Windows
versions.

I made a script some years ago to download both the Linux and Windows
versions (plus their checksums and its signature) all at once from their
proper FTP directories. It takes a FF version number (e.g. "60.9.1"),
and renames everything to make the files much more uniform and readable:

  -rw-r--r-- 1 USER users  836 Sep  2 04:56 SHA512SUMS-FF-60.9.0-esr.txt.asc
  -rw-r--r-- 1 USER users   797352 Sep  2 04:56 SHA512SUMS-FF-60.9.0-esr.txt
  -rw-r--r-- 1 USER users 36428296 Sep  2 04:58 Firefox-Setup-60.9.0-esr-32.exe
  -rw-r--r-- 1 USER users 39272200 Sep  2 04:58 Firefox-Setup-60.9.0-esr-64.exe
  -rw-r--r-- 1 USER users 53465985 Sep  2 04:56 firefox-60.9.0-esr-64.tar.bz2
  -rw-r--r-- 1 USER users 5534 Sep  2 04:56 firefox-60.9.0-esr-32.tar.bz2

I have attached my Perl script: it will undoubtedly will need some
changes for your environment (e.g. USER, maybe a proxy and maybe even
translate to Powershell?).


On Mon, 4 Nov 2019 13:02:56 +0100
Sirko Pöhlmann  wrote:

> Hello,
> 
> Would it be possible to name the installation files for the download
> so that you can see what you have in front of you ?
> The x86 and x64 bit files all have the same name. This is misleading
> if you have to maintain both versions in your system.
> 
> 
> Regards, Sirko
> 
> 


esr-get-firefox
Description: Binary data
___
Enterprise mailing list
Enterprise@mozilla.org
https://mail.mozilla.org/listinfo/enterprise

To unsubscribe from this list, please visit 
https://mail.mozilla.org/listinfo/enterprise or send an email to 
enterprise-requ...@mozilla.org with a subject of "unsubscribe"

Re: [Mozilla Enterprise] Mozilla To Stop Supporting Sideloaded Extensions In Firefox

[Luca Olivetti]

El 4/11/19 a les 16:12, James Pearson ha escrit:



P.S. I'm still a bit confused about 'sideloading' - as the Blog post 
says the change will be with Firefox 73/74 - but I can't seem to enable 
'sideloading' with ESR 68 - i.e. want to be able to load named 
extensions from a central location without copying them to each profile 
with the current ESR 68 ...


I always put the extensions in the browser/extensions subdirectory where 
firefox.exe is (some of them xpi, some of them unzipped), and, in my 
limited testing, this still works with 68 esr (though when I create a 
user's profile I set extensions.autoDisableScopes to 11).


Bye
--
Luca Olivetti
Wetron Automation Technology http://www.wetron.es/
Tel. +34 93 5883004 (Ext.3010)  Fax +34 93 5883007
___
Enterprise mailing list
Enterprise@mozilla.org
https://mail.mozilla.org/listinfo/enterprise

To unsubscribe from this list, please visit https://mail.mozilla.org/listinfo/enterprise 
or send an email to enterprise-requ...@mozilla.org with a subject of 
"unsubscribe"

Re: [Mozilla Enterprise] Mozilla To Stop Supporting Sideloaded Extensions In Firefox

[Paul Kosinski via Enterprise]

Maybe "deployment" is easier in some sense, but the massive change
introduced by Quantum, which annihilated a large number of add-ons, has
made it impossible to return to Firefox's previous functionality and
usability (esp. the user interface). Thus the new state of affairs is
that, although it's easier to deploy this version of the browser, it
isn't the same browser.

P.S. I have been using the Firefox family pretty much exclusively since
I switched from Mosaic (DEC's OSF/1 Unix on Alpha) to Netscape about
24 years ago, but Quantum is by far the most disruptive change ever.
It's the first change that actually *removed* significant functionality
compared to the previous versions.


On Fri, 1 Nov 2019 08:26:25 -0500
Mike Kaply  wrote:

> This method was deprecated by Chrome years ago and we provide new and
> better methods via policy.
> 
> As it stands today, any extension installed by these mechanisms gets
> disabled anyway.
> 
> And we've actually made deployment easier with each release.
> 
> Mike
> 
> 
> 
> On Fri, Nov 1, 2019 at 8:18 AM Luca Olivetti  wrote:
> 
> >
> > https://news.slashdot.org/story/19/11/01/0331216/mozilla-to-stop-supporting-sideloaded-extensions-in-firefox
> >
> >
> > Really?
> > If so, thank you (not!) for making deployment more difficult with
> > each release.
> >
> > Bye
> > --
> > Luca Olivetti
> > Wetron Automation Technology http://www.wetron.es/
> > Tel. +34 93 5883004 (Ext.3010)  Fax +34 93 5883007
___
Enterprise mailing list
Enterprise@mozilla.org
https://mail.mozilla.org/listinfo/enterprise

To unsubscribe from this list, please visit 
https://mail.mozilla.org/listinfo/enterprise or send an email to 
enterprise-requ...@mozilla.org with a subject of "unsubscribe"

Re: [Mozilla Enterprise] Mozilla To Stop Supporting Sideloaded Extensions In Firefox

[James M. Pulver]

I'm guessing if you're deploying policies as policies.json you probably 
can template it in your configuration management tool. I find this is 
where erb templates shine in puppet for instance.

--
James Pulver
CLASSE Computer Group
Cornell University

On 11/4/19 6:30 AM, Marco Gaiarin wrote:
> Mandi! Mike Kaply
>In chel di` si favelave...
> 
>> The thing that is going away is the concept of sideloading where you put
>> extensions in a central location and they get loaded into Firefox and the 
>> user
>> can't remove them (they can only disable them).
>> You will still be able to put extensions into distribution/extensions because
>> they simply get installed into Firefox as normal extensions.
> 
> Things get newer, anche change. It is normal.
> 
> 
> But still i'm lost trying to understand *why* of that change. Looking
> at:
>   
> https://blog.mozilla.org/addons/2019/10/31/firefox-to-discontinue-sideloaded-extensions/
> 
> seems to me that the trouble came from the fact that some 'threat' have
> hijacked 'sideloading' to have their extensions loaded and locked.
> 
> This mean to me that the 'threat' had to be executed as 'administrator'
> (to copy extension in 'extensions' and to put some 'js' files in
> 'defaults\preferences', to use Autoconfig to prevent extension
> disabling or uninstallation.
> 
> But if users have administrator right on the local machine, can also hijack
> the new 'policy' settings, probably doing nastier things!
> 
> So, really i don't understand the benefit of new 'policy' method of
> installing extensions versus the 'sideloading+Autoconfig' old one.
> 
> 
> Still i prefere sideloading (why duplicate all extensions for all
> users, when i can install only one time?), but if we have to change,
> what are really the benefit?
> If is only a 'preferences mess cleanup', why not simply add a policy
> 'SideloadExtensions = true'?
> 
> 
> Also, if we have to switch to policy, please have the 
> distribution/policies.json
> to be non-monolithic: have a single file is a bit rigid nowadays, where
> modern configuration files work on split-files.
> 
> Eg, make the parser load not only 'distribution/policies.json' but also
> (for examples) 'distribution/policies/*.json' with 'policy snippets'.
> 
> Thanks.
> 
___
Enterprise mailing list
Enterprise@mozilla.org
https://mail.mozilla.org/listinfo/enterprise

To unsubscribe from this list, please visit 
https://mail.mozilla.org/listinfo/enterprise or send an email to 
enterprise-requ...@mozilla.org with a subject of "unsubscribe"

Re: [Mozilla Enterprise] Issues with multiprocessing

[Samuel Ambaye]

I’ve attached the issue/email I reported earlier but unfortunately did not have 
the bandwidth to pursue it further.
I did create however create a ticket with our IDP but they were able to 
reproduce the issue with another third party IDP and so we dropped the issue 
altogether. Since then, we have tried to use a more “mainstream” FF 
configuration

Best,
Samuel


From: Mike Kaply 
Date: Monday, 4 November 2019 at 18:44
To: Samuel Ambaye 
Cc: Tiago Marques Delboni , "enterprise@mozilla.org" 

Subject: Re: [Mozilla Enterprise] Issues with multiprocessing

What specific problems did you encounter? Did you open or find bugs in bugzilla 
for them?

Mike

On Fri, Nov 1, 2019 at 3:14 AM Samuel Ambaye 
mailto:samuel.amb...@oakfnd.ch>> wrote:
Hi,

Yes. We also had to temporarily set the value to false to avoid a few issues 
(SSO, capability.policy.policynames, start up errors).
We are removing usage of the FF setting capability.policy.policynames so that 
we can restore support for multiprocessing and avoid SSO issues.

Best,
Samuel


From: Enterprise 
mailto:enterprise-boun...@mozilla.org>> on 
behalf of Tiago Marques Delboni 
mailto:tiago.delb...@almg.gov.br>>
Date: Thursday, 31 October 2019 at 17:24
To: "enterprise@mozilla.org" 
mailto:enterprise@mozilla.org>>
Subject: [Mozilla Enterprise] Issues with multiprocessing

Hi!

Since ESR 52.x and now with ESR 60.x, both Windows/64bits, we are having issues 
with multiprocessing enabled - FF hangs or some funcionalities of 
sites/applications doesn't work as expected. We observed this behavior on 
OpenCMS based websites, Alfresco and a few others.

To fix this, we had to set "browser.tabs.remote.autostart=false" in our 
organization.

Anyone else having this kind os issues?
--

Tiago Marques Delboni

___
Enterprise mailing list
Enterprise@mozilla.org
https://mail.mozilla.org/listinfo/enterprise

To unsubscribe from this list, please visit 
https://mail.mozilla.org/listinfo/enterprise or send an email to 
enterprise-requ...@mozilla.org with a 
subject of "unsubscribe"
--- Begin Message ---
We have a tool called mozregression:

https://mozilla.github.io/mozregression/

That would be very helpful to find this out.

If you can recreate on Firefox 52, and you could track down what caused it, 
that would be great.

Mike

On Thu, Jun 7, 2018 at 3:29 PM, Samuel Ambaye  wrote:
Thank you for looking into this. We did not have the issue with ESR FF 52 x32 
like we do now with FF 60 x64 but I have not tested on V52 with a clean/new 
profile like I have on V60. 


On 7 Jun 2018, at 22:02, Mike Kaply  wrote:

I've looked into this and I can't find any reason why setting checkloaduri to 
enabled would cause this behavior.

Is this a new behavior or did it happen on Firefox 52?

Mike

On Thu, Jun 7, 2018 at 10:58 AM, Samuel Ambaye  wrote:
Hi, 

Given Firefox 60 and that the following pref is added using about:config

capability.policy.localfilelinks.sites = http://www.example.com

When using an Identity Provider initiated SAML sign-in (on www.example.com)
The system somehow changes a SAML HTTP method POST to method GET causing the 
signing to fail.

Work-Around: Set browser.tabs.remote.autostart to false.

Notes: Apparently, others have reproduced this issue on other other sites 
(Salesforce) and when using other Identity Providers (GSuite).

My questions are:
Is capability.policy.localfilelinks.sites a supported configuration?
Is this just a bug or is there a trade off between the preference and the 
work-around.
Any other / better work-arounds?
Any advice other than filing a bug report and disabling autostart?

Best,
Samuel

PS - The preference is used with the ones below
capability.policy.localfilelinks.checkloaduri.enabled and
capability.policy.policynames
PSS - No issue in Chrome, which does not offer access to the local file system 
anyway due to security conerns.


___
Enterprise mailing list
Enterprise@mozilla.org
https://mail.mozilla.org/listinfo/enterprise

To unsubscribe from this list, please visit 
https://mail.mozilla.org/listinfo/enterprise or send an email to 
enterprise-requ...@mozilla.org with a subject of "unsubscribe"




--- End Message ---
___
Enterprise mailing list
Enterprise@mozilla.org
https://mail.mozilla.org/listinfo/enterprise

To unsubscribe from this list, please visit 
https://mail.mozilla.org/listinfo/enterprise or send an email to 
enterprise-requ...@mozilla.org with a subject of "unsubscribe"

Re: [Mozilla Enterprise] Issues with multiprocessing

[Mike Kaply]

What specific problems did you encounter? Did you open or find bugs in
bugzilla for them?

Mike

On Fri, Nov 1, 2019 at 3:14 AM Samuel Ambaye 
wrote:

> Hi,
>
>
>
> Yes. We also had to temporarily set the value to false to avoid a few
> issues (SSO, capability.policy.policynames, start up errors).
>
> We are removing usage of the FF setting capability.policy.policynames so
> that we can restore support for multiprocessing and avoid SSO issues.
>
>
>
> Best,
>
> Samuel
>
>
>
>
>
> *From: *Enterprise  on behalf of Tiago
> Marques Delboni 
> *Date: *Thursday, 31 October 2019 at 17:24
> *To: *"enterprise@mozilla.org" 
> *Subject: *[Mozilla Enterprise] Issues with multiprocessing
>
>
>
> Hi!
>
> Since ESR 52.x and now with ESR 60.x, both Windows/64bits, we are having
> issues with multiprocessing enabled - FF hangs or some funcionalities of
> sites/applications doesn't work as expected. We observed this behavior on
> OpenCMS based websites, Alfresco and a few others.
>
> To fix this, we had to set "browser.tabs.remote.autostart=false" in our
> organization.
>
> Anyone else having this kind os issues?
>
> --
>
> *Tiago Marques Delboni*
>
>
> ___
> Enterprise mailing list
> Enterprise@mozilla.org
> https://mail.mozilla.org/listinfo/enterprise
>
> To unsubscribe from this list, please visit
> https://mail.mozilla.org/listinfo/enterprise or send an email to
> enterprise-requ...@mozilla.org with a subject of "unsubscribe"
>
___
Enterprise mailing list
Enterprise@mozilla.org
https://mail.mozilla.org/listinfo/enterprise

To unsubscribe from this list, please visit 
https://mail.mozilla.org/listinfo/enterprise or send an email to 
enterprise-requ...@mozilla.org with a subject of "unsubscribe"

Re: [Mozilla Enterprise] Naming the installation files

[Tanstaafl]

Just created one for Thunderbird too:

https://bugzilla.mozilla.org/show_bug.cgi?id=1593748

On Mon Nov 04 2019 12:09:41 GMT-0500 (Eastern Standard Time), Tanstaafl
 wrote:
> I just did because this has been annoying me for a while too...
> 
> https://bugzilla.mozilla.org/show_bug.cgi?id=1593740
> 
> Is there a way to desigate this one to both Firefox and Thunderbird? Or
> do I need to create one for Thunderbird too?
> 
> On Mon Nov 04 2019 09:39:49 GMT-0500 (Eastern Standard Time), Mike Kaply
>  wrote:
>> Can you open a bug for this in bugzilla? I admit this has been confusing
>> for me at times as well:
>>
>> https://bugzilla.mozilla.org/enter_bug.cgi?product=Firefox=Installer
>>
>> Mike
>>
>> On Mon, Nov 4, 2019 at 6:03 AM Sirko Pöhlmann > > wrote:
>>
>> Hello,
>>
>> Would it be possible to name the installation files for the download so
>> that you can see what you have in front of you ?
>> The x86 and x64 bit files all have the same name. This is misleading if
>> you have to maintain both versions in your system.
>>
>>
>> Regards, Sirko
>>
>>
>> -- 
>> Dipl.-Ing.(FH) Sirko Poehlmann
>>
>> Tel: 03641 3667 43         Fax: 03641 3667 77
>> GMBU e.V. - Fachsektion Photonik und Sensorik
>> Felsbachstraße 7                D- 07745 Jena
>> poehlm...@gmbu.de                
>>  www.gmbu.de 
>>
>> DSGVO - http://www.gmbu.de/cms/de/datenschutz

___
Enterprise mailing list
Enterprise@mozilla.org
https://mail.mozilla.org/listinfo/enterprise

To unsubscribe from this list, please visit 
https://mail.mozilla.org/listinfo/enterprise or send an email to 
enterprise-requ...@mozilla.org with a subject of "unsubscribe"

Re: [Mozilla Enterprise] Naming the installation files

[Tanstaafl]

I just did because this has been annoying me for a while too...

https://bugzilla.mozilla.org/show_bug.cgi?id=1593740

Is there a way to desigate this one to both Firefox and Thunderbird? Or
do I need to create one for Thunderbird too?

On Mon Nov 04 2019 09:39:49 GMT-0500 (Eastern Standard Time), Mike Kaply
 wrote:
> Can you open a bug for this in bugzilla? I admit this has been confusing
> for me at times as well:
> 
> https://bugzilla.mozilla.org/enter_bug.cgi?product=Firefox=Installer
> 
> Mike
> 
> On Mon, Nov 4, 2019 at 6:03 AM Sirko Pöhlmann  > wrote:
> 
> Hello,
> 
> Would it be possible to name the installation files for the download so
> that you can see what you have in front of you ?
> The x86 and x64 bit files all have the same name. This is misleading if
> you have to maintain both versions in your system.
> 
> 
> Regards, Sirko
> 
> 
> -- 
> Dipl.-Ing.(FH) Sirko Poehlmann
> 
> Tel: 03641 3667 43         Fax: 03641 3667 77
> GMBU e.V. - Fachsektion Photonik und Sensorik
> Felsbachstraße 7                D- 07745 Jena
> poehlm...@gmbu.de                
>  www.gmbu.de 
> 
> DSGVO - http://www.gmbu.de/cms/de/datenschutz
___
Enterprise mailing list
Enterprise@mozilla.org
https://mail.mozilla.org/listinfo/enterprise

To unsubscribe from this list, please visit 
https://mail.mozilla.org/listinfo/enterprise or send an email to 
enterprise-requ...@mozilla.org with a subject of "unsubscribe"

Re: [Mozilla Enterprise] Mozilla To Stop Supporting Sideloaded Extensions In Firefox

[James Pearson]

Marco Gaiarin wrote:



The thing that is going away is the concept of sideloading where you put
extensions in a central location and they get loaded into Firefox and the user
can't remove them (they can only disable them).
You will still be able to put extensions into distribution/extensions because
they simply get installed into Firefox as normal extensions.


Things get newer, anche change. It is normal.


But still i'm lost trying to understand *why* of that change. Looking
at:
 
https://blog.mozilla.org/addons/2019/10/31/firefox-to-discontinue-sideloaded-extensions/

seems to me that the trouble came from the fact that some 'threat' have
hijacked 'sideloading' to have their extensions loaded and locked.

This mean to me that the 'threat' had to be executed as 'administrator'
(to copy extension in 'extensions' and to put some 'js' files in
'defaults\preferences', to use Autoconfig to prevent extension
disabling or uninstallation.

But if users have administrator right on the local machine, can also hijack
the new 'policy' settings, probably doing nastier things!

So, really i don't understand the benefit of new 'policy' method of
installing extensions versus the 'sideloading+Autoconfig' old one.


Still i prefere sideloading (why duplicate all extensions for all
users, when i can install only one time?), but if we have to change,
what are really the benefit?
If is only a 'preferences mess cleanup', why not simply add a policy
'SideloadExtensions = true'?


I agree - I don't want thousands of copies of the same extension in each 
user's home directory - I just want a single copy to be loaded from a 
central location along with Firefox itself


If there are already Policies to control what extensions are enabled by 
default, then why not allow those extensions to be sideloaded ???


Thanks

James Pearson

P.S. I'm still a bit confused about 'sideloading' - as the Blog post 
says the change will be with Firefox 73/74 - but I can't seem to enable 
'sideloading' with ESR 68 - i.e. want to be able to load named 
extensions from a central location without copying them to each profile 
with the current ESR 68 ...

___
Enterprise mailing list
Enterprise@mozilla.org
https://mail.mozilla.org/listinfo/enterprise

To unsubscribe from this list, please visit https://mail.mozilla.org/listinfo/enterprise 
or send an email to enterprise-requ...@mozilla.org with a subject of 
"unsubscribe"

Re: [Mozilla Enterprise] Support TLS 1.0 and 1.1

[Mike Kaply]

We have no plans to remove them from the current ESR which will be
supported until mid to late 2020.

The current plan is to remove them completely in March 2020, so it is
unlikely they will be in the next ESR.

https://www.fxsitecompat.dev/en-CA/docs/2019/tls-1-0-and-1-1-are-now-deprecated-disabled-in-nightly/

Mike

On Mon, Nov 4, 2019 at 12:57 AM Schroth, Juergen <
juergen.schr...@bechtle.com> wrote:

> Hi,
>
>
>
> up to which ESR version is the encryption TLS 1.0 and 1.1 still supported?
>
> When will the support be expected to end? ( year/month )
>
> Is the setting TLS min still configurable afterwards ( fallback, GPO, cfg
> file ) or will TLS 1.0 and 1.1 be completely deactivated.
>
>
>
> Kind regards
>
> Juergen
>
>
> ___
> Enterprise mailing list
> Enterprise@mozilla.org
> https://mail.mozilla.org/listinfo/enterprise
>
> To unsubscribe from this list, please visit
> https://mail.mozilla.org/listinfo/enterprise or send an email to
> enterprise-requ...@mozilla.org with a subject of "unsubscribe"
>
___
Enterprise mailing list
Enterprise@mozilla.org
https://mail.mozilla.org/listinfo/enterprise

To unsubscribe from this list, please visit 
https://mail.mozilla.org/listinfo/enterprise or send an email to 
enterprise-requ...@mozilla.org with a subject of "unsubscribe"

[Mozilla Enterprise] security.OCSP.require

[Osdoba, Sascha]

Hi Mike,

could you please add this setting as a preference setting into GPO.

Thanks,

Sascha

___
Enterprise mailing list
Enterprise@mozilla.org
https://mail.mozilla.org/listinfo/enterprise

To unsubscribe from this list, please visit 
https://mail.mozilla.org/listinfo/enterprise or send an email to 
enterprise-requ...@mozilla.org with a subject of "unsubscribe"

[Mozilla Enterprise] Naming the installation files

[Sirko Pöhlmann]

Hello,

Would it be possible to name the installation files for the download so 
that you can see what you have in front of you ?
The x86 and x64 bit files all have the same name. This is misleading if 
you have to maintain both versions in your system.



Regards, Sirko


--
Dipl.-Ing.(FH) Sirko Poehlmann

Tel: 03641 3667 43 Fax: 03641 3667 77
GMBU e.V. - Fachsektion Photonik und Sensorik
Felsbachstraße 7D- 07745 Jena
poehlm...@gmbu.de www.gmbu.de

DSGVO - http://www.gmbu.de/cms/de/datenschutz
___
Enterprise mailing list
Enterprise@mozilla.org
https://mail.mozilla.org/listinfo/enterprise

To unsubscribe from this list, please visit https://mail.mozilla.org/listinfo/enterprise 
or send an email to enterprise-requ...@mozilla.org with a subject of 
"unsubscribe"

Re: [Mozilla Enterprise] Mozilla To Stop Supporting Sideloaded Extensions In Firefox

[Marco Gaiarin]

Mandi! Mike Kaply
  In chel di` si favelave...

> The thing that is going away is the concept of sideloading where you put
> extensions in a central location and they get loaded into Firefox and the user
> can't remove them (they can only disable them).
> You will still be able to put extensions into distribution/extensions because
> they simply get installed into Firefox as normal extensions.

Things get newer, anche change. It is normal.


But still i'm lost trying to understand *why* of that change. Looking
at:

https://blog.mozilla.org/addons/2019/10/31/firefox-to-discontinue-sideloaded-extensions/

seems to me that the trouble came from the fact that some 'threat' have
hijacked 'sideloading' to have their extensions loaded and locked.

This mean to me that the 'threat' had to be executed as 'administrator'
(to copy extension in 'extensions' and to put some 'js' files in
'defaults\preferences', to use Autoconfig to prevent extension
disabling or uninstallation.

But if users have administrator right on the local machine, can also hijack
the new 'policy' settings, probably doing nastier things!

So, really i don't understand the benefit of new 'policy' method of
installing extensions versus the 'sideloading+Autoconfig' old one.


Still i prefere sideloading (why duplicate all extensions for all
users, when i can install only one time?), but if we have to change,
what are really the benefit?
If is only a 'preferences mess cleanup', why not simply add a policy
'SideloadExtensions = true'?


Also, if we have to switch to policy, please have the distribution/policies.json
to be non-monolithic: have a single file is a bit rigid nowadays, where
modern configuration files work on split-files.

Eg, make the parser load not only 'distribution/policies.json' but also
(for examples) 'distribution/policies/*.json' with 'policy snippets'.

Thanks.

-- 
dott. Marco Gaiarin GNUPG Key ID: 240A3D66
  Associazione ``La Nostra Famiglia''  http://www.lanostrafamiglia.it/
  Polo FVG   -   Via della Bontà, 7 - 33078   -   San Vito al Tagliamento (PN)
  marco.gaiarin(at)lanostrafamiglia.it   t +39-0434-842711   f +39-0434-842797

Dona il 5 PER MILLE a LA NOSTRA FAMIGLIA!
  http://www.lanostrafamiglia.it/index.php/it/sostienici/5x1000
(cf 00307430132, categoria ONLUS oppure RICERCA SANITARIA)
___
Enterprise mailing list
Enterprise@mozilla.org
https://mail.mozilla.org/listinfo/enterprise

To unsubscribe from this list, please visit 
https://mail.mozilla.org/listinfo/enterprise or send an email to 
enterprise-requ...@mozilla.org with a subject of "unsubscribe"