zookeeper-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Szalay-Bekő Máté <szalay.beko.m...@gmail.com>
Subject Re: Zookeeper and curator SASL authentication
Date Thu, 16 Jan 2020 15:05:12 GMT
great! :)

On Wed, Jan 15, 2020 at 6:38 PM Arpit Jain <jain.arpit6@gmail.com> wrote:

> I managed to create ACL with authenticated client principal using below
> lines of code in client:
>
>             curator
> .create().creatingParentContainersIfNeeded().withACL(ZooDefs.Ids.
> CREATOR_ALL_ACL).forPath("/mynode");
>
>
> ZooDefs.Ids.CREATOR_ALL_ACL gives permissions to the client which is
> authenticated.
>
> To test this, I logged in using zkCli.sh on ZK server and ran getAcl
> /mynode and able to browse the znodes and can see that node has all (CDRWA)
> permission for authenticated uses. If I log in with a unauthenticated
> principal, I am not able to see the znodes tree even though I manage to
> connect to ZK server.
>
> On Wed, Jan 15, 2020 at 12:19 PM Enrico Olivelli - Diennea <
> enrico.olivelli@diennea.com> wrote:
>
>> Yes, they are system properties
>>
>> You can take this guide (about Kafka) as example
>>
>> https://docs.confluent.io/current/kafka/authentication_sasl/authentication_sasl_gssapi.html
>>
>>
>>
>> Il giorno 15/01/20, 13:17 "Arpit Jain" <jain.arpit6@gmail.com> ha
>> scritto:
>>
>>     I have not passed those parameters. Is this something I need to set in
>>     Zookeeper (zoo.cfg) ?
>>
>>     On Wed, Jan 15, 2020 at 12:12 PM Enrico Olivelli - Diennea <
>>     enrico.olivelli@diennea.com> wrote:
>>
>>     > Usually with SASL auth you are using:
>>     > kerberos.removeHostFromPrincipal=true
>>     > kerberos.removeRealmFromPrincipal=true
>>     >
>>     > is this the case for you ?
>>     >
>>     > Enrico
>>     >
>>     > Il giorno 15/01/20, 13:01 "Arpit Jain" <jain.arpit6@gmail.com> ha
>>     > scritto:
>>     >
>>     >     I have asked in Curator mailing list as well but not much help.
>> I am
>>     > able
>>     >     to set ACL with sasl scheme by using zkCli.sh client in
>> Zookeeper
>>     > server.
>>     >     The idea is to use Curator to set the ACLs so that only my
>> client
>>     >     application can access its Znodes.
>>     >
>>     >
>>     >     On Wed, Jan 15, 2020 at 9:21 AM Szalay-Bekő Máté <
>>     > szalay.beko.mate@gmail.com>
>>     >     wrote:
>>     >
>>     >     > I am not sure what is wrong with the code... I am not
>> familiar with
>>     >     > Curator. I can try to google / reproduce this and see what is
>> wrong,
>>     > but it
>>     >     > will take a while for me. So first I would ask the others,
>> maybe
>>     > there is
>>     >     > someone who knows both ZooKeeper SASL and Curator and can
>> help you
>>     > more in
>>     >     > this mailing list. If noone replies, then I will try to setup
>> a dummy
>>     >     > project with Curator to test this.
>>     >     >
>>     >     > Did you also ask around the Curator mailing list maybe? Would
>> it
>>     > help if I
>>     >     > send you code about setting the ACLs using plain ZooKeeper
>> (and no
>>     > Curator)?
>>     >     >
>>     >     > On Tue, Jan 14, 2020 at 2:48 PM Arpit Jain <
>> jain.arpit6@gmail.com>
>>     > wrote:
>>     >     >
>>     >     >> Thanks for the clarification.
>>     >     >> I am able to authenticate client with Zookeeper. However,
>> when I
>>     > started
>>     >     >> to set ACLs with the same client, I get error messages. This
>> is how
>>     > I am
>>     >     >> creating curator client for setting ACLs
>>     >     >>
>>     >     >>         CuratorFrameworkFactory.Builder builder =
>>     >     >>
>>     >     >>             CuratorFrameworkFactory.builder().connectString(
>>     >     >> coordinatorHosts).retryPolicy(retryPolicy)
>>     >     >>
>>     >     >>             .connectionTimeoutMs(coordinatorConnectionTimeout
>>     >     >> ).sessionTimeoutMs(coordinatorSessionTimeout);
>>     >     >>
>>     >     >>         final CuratorFramework curatorFramework =
>>     >     >>
>>     >     >>             builder.authorization("sasl", "zkclient/
>>     > zoo1@EXAMPLE.COM"
>>     >     >> .getBytes()).aclProvider(new ACLProvider() {
>>     >     >>
>>     >     >>             @Override
>>     >     >>
>>     >     >>             public List<ACL> getDefaultAcl() {
>>     >     >>
>>     >     >>                 return ZooDefs.Ids.CREATOR_ALL_ACL;
>>     >     >>
>>     >     >>             }
>>     >     >>
>>     >     >>
>>     >     >>             @Override
>>     >     >>
>>     >     >>             public List<ACL> getAclForPath(String path)
{
>>     >     >>
>>     >     >>                 return ZooDefs.Ids.CREATOR_ALL_ACL;
>>     >     >>
>>     >     >>             }
>>     >     >>
>>     >     >>         }).build();
>>     >     >>
>>     >     >>
>>     >     >>  I see below logs in Zookeeper node:
>>     >     >>
>>     >     >>
>>     >     >>
>>     >     >>
>>     >     >>
>>     >     >> *2020-01-14 13:27:53,174 [myid:1] - INFO
>>     >     >>  [NIOWorkerThread-3:SaslServerCallbackHandler@120] -
>> Successfully
>>     >     >> authenticated client: authenticationID=zkclient/
>> zoo1@EXAMPLE.COM
>>     >     >> <zoo1@EXAMPLE.COM>;  authorizationID=zkclient/
>> zoo1@EXAMPLE.COM
>>     >     >> <zoo1@EXAMPLE.COM>.2020-01-14 13:27:53,175 [myid:1] -
INFO
>>     >     >>  [NIOWorkerThread-3:SaslServerCallbackHandler@136] - Setting
>>     > authorizedID:
>>     >     >> zkclient/zoo1@EXAMPLE.COM <zoo1@EXAMPLE.COM>2020-01-14
>> 13:27:53,175
>>     >     >> [myid:1] - INFO  [NIOWorkerThread-3:ZooKeeperServer@1170] -
>> adding
>>     > SASL
>>     >     >> authorization for authorizationID: zkclient/zoo1@EXAMPLE.COM
>>     >     >> <zoo1@EXAMPLE.COM>2020-01-14 13:27:53,182 [myid:1] -
INFO
>>     >     >>  [NIOWorkerThread-7:ZooKeeperServer@1095] - got auth packet
>>     >     >> /172.30.0.6:36658 <http://172.30.0.6:36658>2020-01-14
>> 13:27:53,183
>>     > [myid:1]
>>     >     >> - WARN  [NIOWorkerThread-7:ZooKeeperServer@1123] -
>> Authentication
>>     > failed
>>     >     >> for scheme: sasl*
>>     >     >>
>>     >     >> Is this not the correct way to do it ?
>>     >     >>
>>     >     >>
>>     >     >>
>>     >     >> On Tue, Jan 14, 2020 at 11:52 AM Szalay-Bekő Máté <
>>     >     >> szalay.beko.mate@gmail.com> wrote:
>>     >     >>
>>     >     >>> The system property name is a bit misleading... this
>> parameter is
>>     >     >>> actually specifies the username used in the ZooKeeper server
>>     > principal.
>>     >     >>> (in your case the server principal is: zookeeper/
>> zoo1@EXAMPLE.COM)
>>     >     >>> AFAIK the ZooKeeper client (after authenticated as zkclient/
>>     >     >>> zoo1@EXAMPLE.COM in Kerberos based on the jaas.conf file)
>> needs
>>     > to know
>>     >     >>> the ZooKeeper server principal in order to ask for a
>> specific
>>     > token from
>>     >     >>> kerberos which can be read by the ZooKeeper server.
>>     >     >>>
>>     >     >>> In 3.5.5 (or 3.5.6) you can use the
>> zookeeper.sasl.client.username
>>     >     >>> parameter (plus some other parameters) to configure how
the
>> server
>>     >     >>> principal will be determined by the client.
>>     >     >>> See:
>>     >     >>>
>>     >
>> https://github.com/apache/zookeeper/blob/c11b7e26bc554b8523dc929761dd28808913f091/zookeeper-server/src/main/java/org/apache/zookeeper/SaslServerPrincipal.java#L48
>>     >     >>>
>>     >     >>> In future releases (3.5.7, 3.6, ...) you can also use
>>     >     >>> the zookeeper.server.principal parameter (a much better
>> name I
>>     > think) to
>>     >     >>> use a fix server principal name in the client.
>>     >     >>> See:
>>     >     >>>
>>     >
>> https://github.com/apache/zookeeper/blob/1c5d135d74f16275876c024401dc2de92909b20a/zookeeper-server/src/main/java/org/apache/zookeeper/SaslServerPrincipal.java#L50
>>     >     >>>
>>     >     >>> On Mon, Jan 13, 2020 at 6:03 PM Arpit Jain <
>> jain.arpit6@gmail.com>
>>     >     >>> wrote:
>>     >     >>>
>>     >     >>>> Does this user name have to be "Zookeeper"
>>     >     >>>> (-Dzookeeper.sasl.client.username=zookeeper) always
?
>>     >     >>>> And the client principal name is different than this
>>     > username..Correct
>>     >     >>>> me if I am wrong ?
>>     >     >>>>
>>     >     >>>> On Mon, Jan 13, 2020 at 4:58 PM Arpit Jain <
>> jain.arpit6@gmail.com
>>     > >
>>     >     >>>> wrote:
>>     >     >>>>
>>     >     >>>>> Thanks you so much !
>>     >     >>>>> It worked finally. I had to change
>>     >     >>>>> -Dzookeeper.sasl.client.username=zookeeper parameter.
>>     >     >>>>>
>>     >     >>>>> On Mon, Jan 13, 2020 at 4:40 PM Szalay-Bekő Máté
<
>>     >     >>>>> szalay.beko.mate@gmail.com> wrote:
>>     >     >>>>>
>>     >     >>>>>> You are using 3.5.5 or 3.5.6, right?
>>     >     >>>>>> I think you need to specify:
>>     >     >>>>>> -Dzookeeper.sasl.client.username=zookeeper
>>     >     >>>>>> can you give it a try? If it doesn't work then
I can
>> take a
>>     > deeper
>>     >     >>>>>> look (also we can enable some debug logging)
>>     >     >>>>>>
>>     >     >>>>>> On Mon, Jan 13, 2020 at 5:31 PM Arpit Jain
<
>>     > jain.arpit6@gmail.com>
>>     >     >>>>>> wrote:
>>     >     >>>>>>
>>     >     >>>>>>> Hi
>>     >     >>>>>>>
>>     >     >>>>>>> I have Kerberos, Zookeeper and my application
(using
>> curator)
>>     >     >>>>>>> running in 3 docker containers with ZK
SASL
>> authentication
>>     > enabled. The ZK
>>     >     >>>>>>> can login to Kerberos and starts successfully.
>>     >     >>>>>>>
>>     >     >>>>>>> The ZK server principal is zookeeper/zoo1@EXAMPLE.COM
>>     >     >>>>>>> The client principal is : zkclient/zoo1@EXAMPLE.COM
>>     >     >>>>>>>
>>     >     >>>>>>> While starting my application, I am seeing
failure while
>>     > obtaining
>>     >     >>>>>>> TGS.
>>     >     >>>>>>> See the log at Kerberos side:
>>     >     >>>>>>>
>>     >     >>>>>>>
>>     >     >>>>>>>
>>     >     >>>>>>> *Jan 13 15:22:19 kdc krb5kdc[20](info):
AS_REQ (2
>> etypes {18
>>     > 17})
>>     >     >>>>>>> 172.30.0.6 <http://172.30.0.6>: NEEDED_PREAUTH:
>> zkclient/
>>     > zoo1@EXAMPLE.COM
>>     >     >>>>>>> <zoo1@EXAMPLE.COM> for krbtgt/EXAMPLE.COM@EXAMPLE.COM
>>     >     >>>>>>> <EXAMPLE.COM@EXAMPLE.COM>, Additional
>> pre-authentication
>>     > requiredJan 13
>>     >     >>>>>>> 15:22:19 kdc krb5kdc[20](info): AS_REQ
(2 etypes {18
>> 17})
>>     > 172.30.0.6
>>     >     >>>>>>> <http://172.30.0.6>: ISSUE: authtime
1578928939, etypes
>>     > {rep=18 tkt=18
>>     >     >>>>>>> ses=18}, zkclient/zoo1@EXAMPLE.COM <zoo1@EXAMPLE.COM>
>> for
>>     >     >>>>>>> krbtgt/EXAMPLE.COM@EXAMPLE.COM <EXAMPLE.COM@EXAMPLE.COM
>> >Jan
>>     > 13 15:22:19 kdc
>>     >     >>>>>>> krb5kdc[20](info): TGS_REQ (4 etypes {18
17 16 23})
>> 172.30.0.6
>>     >     >>>>>>> <http://172.30.0.6>: ISSUE: authtime
1578928939, etypes
>>     > {rep=18 tkt=18
>>     >     >>>>>>> ses=18}, zkclient/zoo1@EXAMPLE.COM <zoo1@EXAMPLE.COM>
>> for
>>     >     >>>>>>> zkclient/zoo1@EXAMPLE.COM <zoo1@EXAMPLE.COM>*
>>     >     >>>>>>>
>>     >     >>>>>>> However, if I use the zkCli.sh to login
to Zookeeper, it
>>     >     >>>>>>> successfully logs in. See the log on Kerberos
side. See
>> the
>>     > difference in
>>     >     >>>>>>> the last line while requesting TGS.
>>     >     >>>>>>>
>>     >     >>>>>>>
>>     >     >>>>>>>
>>     >     >>>>>>> *Jan 13 15:26:14 kdc krb5kdc[20](info):
AS_REQ (2
>> etypes {18
>>     > 17})
>>     >     >>>>>>> 172.30.0.3 <http://172.30.0.3>: NEEDED_PREAUTH:
>> zkclient/
>>     > zoo1@EXAMPLE.COM
>>     >     >>>>>>> <zoo1@EXAMPLE.COM> for krbtgt/EXAMPLE.COM@EXAMPLE.COM
>>     >     >>>>>>> <EXAMPLE.COM@EXAMPLE.COM>, Additional
>> pre-authentication
>>     > requiredJan 13
>>     >     >>>>>>> 15:26:14 kdc krb5kdc[20](info): AS_REQ
(2 etypes {18
>> 17})
>>     > 172.30.0.3
>>     >     >>>>>>> <http://172.30.0.3>: ISSUE: authtime
1578929174, etypes
>>     > {rep=18 tkt=18
>>     >     >>>>>>> ses=18}, zkclient/zoo1@EXAMPLE.COM <zoo1@EXAMPLE.COM>
>> for
>>     >     >>>>>>> krbtgt/EXAMPLE.COM@EXAMPLE.COM <EXAMPLE.COM@EXAMPLE.COM
>> >Jan
>>     > 13 15:26:14 kdc
>>     >     >>>>>>> krb5kdc[20](info): TGS_REQ (4 etypes {18
17 16 23})
>> 172.30.0.3
>>     >     >>>>>>> <http://172.30.0.3>: ISSUE: authtime
1578929174, etypes
>>     > {rep=18 tkt=18
>>     >     >>>>>>> ses=18}, zkclient/zoo1@EXAMPLE.COM <zoo1@EXAMPLE.COM>
>> for
>>     >     >>>>>>> zookeeper/zoo1@EXAMPLE.COM <zoo1@EXAMPLE.COM>*
>>     >     >>>>>>>
>>     >     >>>>>>> The client section in JAAS config file
is same in both
>> the
>>     > cases but
>>     >     >>>>>>> the server it is looking for is different
in both the
>> cases.
>>     >     >>>>>>> Could someone suggest why there is a difference
?
>>     >     >>>>>>>
>>     >     >>>>>>> Thanks
>>     >     >>>>>>>
>>     >     >>>>>>>
>>     >     >>>>>>>
>>     >     >>>>>>> On Mon, Jan 13, 2020 at 4:17 PM Szalay-Bekő
Máté <
>>     >     >>>>>>> szalay.beko.mate@gmail.com> wrote:
>>     >     >>>>>>>
>>     >     >>>>>>>> Also please note, that the
>>     >     >>>>>>>> 'Configuration.getConfiguration().refresh()'
will
>> reload only
>>     > the
>>     >     >>>>>>>> jaas.config.
>>     >     >>>>>>>> If you also need to reload the kerberos
client config,
>> then
>>     > you can
>>     >     >>>>>>>> add the "refreshKrb5Config=true" line
to your
>> jaas.conf file.
>>     > This will
>>     >     >>>>>>>> trigger to reload the krb.cfg file
as well if needed.
>>     >     >>>>>>>>
>>     >     >>>>>>>> I am just working on a PR where I had
to use both of
>> these:
>>     >     >>>>>>>>
>>     >
>> https://github.com/apache/zookeeper/pull/1204/files#diff-0c01d3c68a71c68701d778cc556c8e0a
>>     >     >>>>>>>>
>>     >     >>>>>>>> Cheers,
>>     >     >>>>>>>> Mate
>>     >     >>>>>>>>
>>     >     >>>>>>>> On Thu, Jan 9, 2020 at 10:02 PM Damien
Diederen <
>>     >     >>>>>>>> ddiederen@sinenomine.net> wrote:
>>     >     >>>>>>>>
>>     >     >>>>>>>>>
>>     >     >>>>>>>>> Hi Enrico,
>>     >     >>>>>>>>>
>>     >     >>>>>>>>> > There is a method to force
JAAS to reload the system
>>     > property.
>>     >     >>>>>>>>> >
>>     >     >>>>>>>>> > Something like
>> Configuration.getConfiguration().refresh()
>>     >     >>>>>>>>>
>>     >     >>>>>>>>> Great to know!  Thanks!
>>     >     >>>>>>>>>
>>     >     >>>>>>>>> > You have to call that method
after changing the
>> system
>>     > property
>>     >     >>>>>>>>>
>>     >     >>>>>>>>> Cheers, -D
>>     >     >>>>>>>>>
>>     >     >>>>>>>>>
>>     >     >>>>>>>>>
>>     >     >>>>>>>>> > Il gio 9 gen 2020, 20:05 Damien
Diederen <
>>     >     >>>>>>>>> ddiederen@sinenomine.net> ha
>>     >     >>>>>>>>> > scritto:
>>     >     >>>>>>>>> >
>>     >     >>>>>>>>> >>
>>     >     >>>>>>>>> >> Hi Arpit, Máté,
>>     >     >>>>>>>>> >>
>>     >     >>>>>>>>> >> Arpit wrote:
>>     >     >>>>>>>>> >>
>>     >     >>>>>>>>> >> > The solution is to
pass JAAS file
>>     >     >>>>>>>>> >> > with
>>     > -Djava.security.auth.login.config=/path/to/jaas.conf.
>>     >     >>>>>>>>> >>
>>     >     >>>>>>>>> >> Okay—good.
>>     >     >>>>>>>>> >>
>>     >     >>>>>>>>> >> > Using System.setProperty
does not work for me.
>>     >     >>>>>>>>> >>
>>     >     >>>>>>>>> >> Ah, I see.  And I'm not
surprised; I think Máté is
>> on the
>>     > right
>>     >     >>>>>>>>> track:
>>     >     >>>>>>>>> >>
>>     >     >>>>>>>>> >> >> I also faced
this exception not long ago. I
>> think it
>>     > is an
>>     >     >>>>>>>>> edge case,
>>     >     >>>>>>>>> >> most
>>     >     >>>>>>>>> >> >> probably you
have something else, but still...
>> maybe it
>>     >     >>>>>>>>> helps:
>>     >     >>>>>>>>> >> >>
>>     >     >>>>>>>>> >> >> I tried to write
a unit test which dynamically
>>     > generated
>>     >     >>>>>>>>> multiple
>>     >     >>>>>>>>> >> >> jaas.conf files.
Then I was setting the
>>     >     >>>>>>>>> >> >> java.security.auth.login.config
system property
>> to the
>>     >     >>>>>>>>> config file I
>>     >     >>>>>>>>> >> needed
>>     >     >>>>>>>>> >> >> in the given
testcase, and when I tried to
>> establish a
>>     >     >>>>>>>>> ZooKeeper
>>     >     >>>>>>>>> >> connection
>>     >     >>>>>>>>> >> >> in the unit test,
I also got the same exception
>> that
>>     > you got.
>>     >     >>>>>>>>> >> >>
>>     >     >>>>>>>>> >> >> The problem was,
that the security
>> configuration file I
>>     >     >>>>>>>>> referred in the
>>     >     >>>>>>>>> >> >> java.security.auth.login.config
system property
>> file
>>     > was
>>     >     >>>>>>>>> read only once,
>>     >     >>>>>>>>> >> >> then stored in
memory. And it haven't got
>> reloaded,
>>     > even if
>>     >     >>>>>>>>> the file (or
>>     >     >>>>>>>>> >> >> its path in the
system property) changed.
>>     >     >>>>>>>>> >>
>>     >     >>>>>>>>> >> My understanding is that
the property is read very
>> early
>>     > after
>>     >     >>>>>>>>> "VM boot"
>>     >     >>>>>>>>> >> (the first time any class
tries to access the
>>     >     >>>>>>>>> java.security.Provider):
>>     >     >>>>>>>>> >> the resource it points
to is parsed at that point,
>> and the
>>     >     >>>>>>>>> property
>>     >     >>>>>>>>> >> "never" checked again.
>>     >     >>>>>>>>> >>
>>     >     >>>>>>>>> >> (It *may* be possible
to flush the "Spi" or
>> something,
>>     > but it's
>>     >     >>>>>>>>> clearly
>>     >     >>>>>>>>> >> not the kind of usage
it was designed for.)
>>     >     >>>>>>>>> >>
>>     >     >>>>>>>>> >> >> Maybe the best
in this case is to
>>     >     >>>>>>>>> >> >> specify separate
JAAS config sections for each
>> tests
>>     > and use
>>     >     >>>>>>>>> a single
>>     >     >>>>>>>>> >> >> JAAS.conf file
per JVM.
>>     >     >>>>>>>>> >>
>>     >     >>>>>>>>> >> That's probably the easiest
if the set is
>> enumerable.
>>     >     >>>>>>>>> >>
>>     >     >>>>>>>>> >> "Real dynamism" might
require overriding the "Spi"
>> or
>>     >     >>>>>>>>> "Provider," but
>>     >     >>>>>>>>> >> that's probably overkill
for a few tests.
>>     >     >>>>>>>>> >>
>>     >     >>>>>>>>> >> (Now that I think of it…
our tests are already run
>> under
>>     > the
>>     >     >>>>>>>>> JMockit
>>     >     >>>>>>>>> >> agent, so live-patching
JAAS methods using
>> mockit.MockUp
>>     > might
>>     >     >>>>>>>>> be
>>     >     >>>>>>>>> >> another option :)
>>     >     >>>>>>>>> >>
>>     >     >>>>>>>>> >> Anyway.  It looks like
setting the property
>> externally
>>     > worked
>>     >     >>>>>>>>> for Arpit.
>>     >     >>>>>>>>> >>
>>     >     >>>>>>>>> >> Cheers, -D
>>     >     >>>>>>>>> >>
>>     >     >>>>>>>>>
>>     >     >>>>>>>>
>>     >
>>     >
>>     >
>>     > ________________________________
>>     >
>>     > CONFIDENTIALITY & PRIVACY NOTICE
>>     > This e-mail (including any attachments) is strictly confidential
>> and may
>>     > also contain privileged information. If you are not the intended
>> recipient
>>     > you are not authorised to read, print, save, process or disclose
>> this
>>     > message. If you have received this message by mistake, please
>> inform the
>>     > sender immediately and destroy this e-mail, its attachments and any
>> copies.
>>     > Any use, distribution, reproduction or disclosure by any person
>> other than
>>     > the intended recipient is strictly prohibited and the person
>> responsible
>>     > may incur in penalties.
>>     > The use of this e-mail is only for professional purposes; there is
>> no
>>     > guarantee that the correspondence towards this e-mail will be read
>> only by
>>     > the recipient, because, under certain circumstances, there may be a
>> need to
>>     > access this email by third subjects belonging to the Company.
>>     >
>>
>>
>>
>> ________________________________
>>
>> CONFIDENTIALITY & PRIVACY NOTICE
>> This e-mail (including any attachments) is strictly confidential and may
>> also contain privileged information. If you are not the intended recipient
>> you are not authorised to read, print, save, process or disclose this
>> message. If you have received this message by mistake, please inform the
>> sender immediately and destroy this e-mail, its attachments and any copies.
>> Any use, distribution, reproduction or disclosure by any person other than
>> the intended recipient is strictly prohibited and the person responsible
>> may incur in penalties.
>> The use of this e-mail is only for professional purposes; there is no
>> guarantee that the correspondence towards this e-mail will be read only by
>> the recipient, because, under certain circumstances, there may be a need to
>> access this email by third subjects belonging to the Company.
>>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message