- anti-abuse-wg - mailman.ripe.net

Draft Minutes - AA-WG @ RIPE80
by Brian Nisbet 07 Jul '20

07 Jul '20

Colleagues, Please find attached the draft minutes from our working group session at RIPE 80. Could you let the Co-Chairs know, by Friday 17th July, if there are any errors or omissions? Thanks, Brian Co-Chair, RIPE AA-WG Brian Nisbet Service Operations Manager HEAnet CLG, Ireland's National Education and Research Network 1st Floor, 5 George's Dock, IFSC, Dublin D01 X8N7, Ireland +35316609040 brian.nisbet(a)heanet.ie www.heanet.ie Registered in Ireland, No. 275301. CRA No. 20036270

4 4

Measurement study on understanding global email configuration quality
by Tobias Fiebig 07 Jul '20

07 Jul '20

Dear all, I am a researcher at TU Delft in the Netherlands, looking into Network Security, Protocol Adoption and human factors. My student Olamide is looking into how well _sending_ email setups are maintained around the globe. For this, we need many people, ideally from 'smaller' providers, i.e., with non gmail/hotmail/yahoo addresses, to send us emails. Please consider participating in this study, and sharing it in your networks. To help us, please follow the instructions at: https://www.email-security-scans.org/ Important caveat: If your mailer validates recipient addresses before accepting mails for delivery, you might be unable to send to destination addresses that are (a) only resolvable via IPv6 only, or (b) Have broken DNSSEC, which we use to test DNSSEC validation. If this is the case, please just remove the 1-3 offending addresses from the To: header. Please also note that our test setups will test whether the host delivering mails to us is an open relay. Also note that you may receive bounces from your mailserver for some of the destination addresses, e.g., if mails cannot be delivered via IPv6, or if your mail-setup validates DANE records for our DANE test domain. We do _not_ need a copy of those bounces. In case you want to get results for a domain you operate or use early, please just drop me an email from the same domain and delivering servers after you participated, and I will share the data with you. :-) Met vriendelijke groet, Dr.-Ing. Tobias Fiebig, Assistant Professor / Universitair Docent Department Engineering Systems and Services Informatie- en Communicatie Technologie (ICT) TU Delft / Dept. ESS Faculty of Technology, Policy and Management (TBM) Building 31 Jaffalaan 5 - room B3.170 2628 BX Delft P.O.Box 5015 2600 GA Delft, The Netherlands T +31 (0)15 27 85700 E t.fiebig(a)tudelft.nl Present: Monday t/m Friday

1 0

Re: [anti-abuse-wg] Fwd: Re: botnet controllers
by PP 25 Jun '20

25 Jun '20

Firstly, reporting it to the LEO does not cause the resources to be de-registered. Secondly, your example regarding IPv6 is another reason why this approach is not sufficient: there are 340,282,366,920,938,000,000,000,000,000,000,000,000 possible IPv6 addresses. It should be that the resources are only allocated to legitimate established corporations. Phone numbers aren't wholly allocated to anyone who asks, they remain controlled by a reputable phone company. Why should IP addresses be different? On 25/06/2020 4:50 pm, Shane Kerr wrote: > Dear Phish Phucker, > > The RIPE NCC is a not-for-profit, membership-based organization based > in the Netherlands. They are responsible for allocating Internet > number resources (IP addresses and AS numbers) in their region. Their > policies are set by RIPE, which is just anyone who joins the RIPE > mailing lists and participates in the policy discussions. > > I'm not sure what policy can be introduced. Historically RIPE > participants have been reluctant to make any value judgements about > what IP resources can and cannot be used for. Currently as long as you > are truthful about your organization's registration information you > have fulfilled the requirements. > > In a sense this should be enough. The information is available for > anyone who cares about protecting their users from spam originating > there. Spamhaus lists the organization, and I am pretty sure that most > e-mail providers either block their IP addresses because of that - or > have their own abuse tracking which identifies them. It's not > perfect... I had to change VPS provider because my previous VPS > provider kept having its IPv6 addresses blocked by Spamhaus and > neither my provider nor Spamhaus would explain why (my provider > claimed to have never received any complains, and Spamhaus never > explains anything). But it seems to be good enough for most people. > > If an organization is breaking a law, then the correct action is to > report them to the law-enforcement organization (LEO) that feels like > it is in their jurisdiction. Again, since the member is required by > the RIPE NCC to have correct information about the person or > organization that has been allocated resources, the LEO can follow-up. > > It's hardly an ideal situation, but difficult to see how to improve it > given the general anti-regulation philosophy of most Internet providers. > > Cheers, > > -- > Shane > > On 25/06/2020 08.03, PP wrote: >> So who at RIPE is responsible for allocating this resource, and what >> policy can be introduced to prevent the allocation of IP address >> resources to irresponsible organizations like this one? >> >> SpamHaus have it listed as the worlds number one source of spam: >> >> https://www.spamhaus.org/statistics/networks/ >> >> >> >> On 25/06/2020 2:10 pm, Tõnu Tammer via anti-abuse-wg wrote: >>> >>> We've had similar experience with this VPN provider. >>> >>> He claims not being able to track malicious actor is for the benefit >>> of free speech but when malware is used to attack people who express >>> free speech he did not understand that his service is not >>> contributing towards free speech but hinders it. >>> >>> Tonu >>> CERT-EE >>> >>> On 25.06.2020 04:15, PP wrote: >>>> >>>> Botnet controllers on VPN provider that refuses to act: >>>> >>>> >>>> organisation: ORG-SL751-RIPE >>>> org-name: Freedom Of Speech VPN >>>> org-type: OTHER >>>> address: P.O. Box 9173 >>>> address: Victoria >>>> address: Mahe Island >>>> address: Seychelles >>>> e-mail: info(a)FOS-VPN.org >>>> abuse-c: SL12644-RIPE >>>> mnt-ref: FOS-VPN-MNT >>>> mnt-by: FOS-VPN-MNT >>>> created: 2018-07-13T05:33:45Z >>>> last-modified: 2020-02-28T12:37:39Z >>>> source: RIPE >>>> >>>> >>>> >>>> >>>> -------- Forwarded Message -------- >>>> Subject: Re: botnet controllers >>>> Date: Wed, 24 Jun 2020 21:49:21 +0200 >>>> From: info(a)ghlc.biz >>>> To: PP <phishphucker(a)storey.ovh> >>>> >>>> >>>> >>>> On 2020-06-24 13:03, PP wrote: >>>> Hello! >>>> >>>> >>>> Please note that all mentioned IPs belong to non-logging VPN services. >>>> >>>> No user logs are kept. >>>> >>>> >>>> Sincerely yours >>>> >>>> David Craig >>>> >>>> >>>>> SBL488704 >>>>> 185.140.53.75/32 >>>>> ghlc.biz >>>>> 23-Jun-2020 05:26 GMT >>>>> Malware botnet controller @185.140.53.75 >>>>> https://www.spamhaus.org/sbl/query/SBL488704 >>>>> >>>>> >>>>> SBL488686 >>>>> 91.193.75.58/32 >>>>> ghlc.biz >>>>> 22-Jun-2020 18:39 GMT >>>>> NanoCore botnet controller @91.193.75.58 >>>>> https://www.spamhaus.org/sbl/query/SBL488686 >>>>> >>>>> >>>>> SBL488548 >>>>> 185.244.30.201/32 >>>>> ghlc.biz >>>>> 19-Jun-2020 13:21 GMT >>>>> QuasarRAT botnet controller @185.244.30.201 >>>>> https://www.spamhaus.org/sbl/query/SBL488548 >>>>> >>>>> >>>>> SBL488006 >>>>> 185.140.53.162/32 >>>>> ghlc.biz >>>>> 18-Jun-2020 10:11 GMT >>>>> NanoCore botnet controller @185.140.53.162 >>>>> https://www.spamhaus.org/sbl/query/SBL488006 >>>>> >>>>> >>>>> SBL487900 >>>>> 185.140.53.229/32 >>>>> ghlc.biz >>>>> 16-Jun-2020 13:28 GMT >>>>> NanoCore botnet controller @185.140.53.229 >>>>> https://www.spamhaus.org/sbl/query/SBL487900 >>>>> >>>>> >>>>> SBL487899 >>>>> 185.244.30.113/32 >>>>> ghlc.biz >>>>> 16-Jun-2020 12:59 GMT >>>>> RemcosRAT botnet controller @185.244.30.113 >>>>> https://www.spamhaus.org/sbl/query/SBL487899 >>>>> >>>>> >>>>> SBL487893 >>>>> 185.140.53.236/32 >>>>> ghlc.biz >>>>> 16-Jun-2020 12:07 GMT >>>>> NanoCore botnet controller @185.140.53.236 >>>>> https://www.spamhaus.org/sbl/query/SBL487893 >>>>> >>>>> >>>>> SBL487886 >>>>> 185.165.153.45/32 >>>>> ghlc.biz >>>>> 16-Jun-2020 10:26 GMT >>>>> NanoCore botnet controller @185.165.153.45 >>>>> >>>>> https://www.spamhaus.org/sbl/query/SBL487886 >

3 5

Fwd: Re: botnet controllers
by PP 25 Jun '20

25 Jun '20

Botnet controllers on VPN provider that refuses to act: organisation: ORG-SL751-RIPE org-name: Freedom Of Speech VPN org-type: OTHER address: P.O. Box 9173 address: Victoria address: Mahe Island address: Seychelles e-mail: info(a)FOS-VPN.org abuse-c: SL12644-RIPE mnt-ref: FOS-VPN-MNT mnt-by: FOS-VPN-MNT created: 2018-07-13T05:33:45Z last-modified: 2020-02-28T12:37:39Z source: RIPE -------- Forwarded Message -------- Subject: Re: botnet controllers Date: Wed, 24 Jun 2020 21:49:21 +0200 From: info(a)ghlc.biz To: PP <phishphucker(a)storey.ovh> On 2020-06-24 13:03, PP wrote: Hello! Please note that all mentioned IPs belong to non-logging VPN services. No user logs are kept. Sincerely yours David Craig > SBL488704 > 185.140.53.75/32 > ghlc.biz > 23-Jun-2020 05:26 GMT > Malware botnet controller @185.140.53.75 > https://www.spamhaus.org/sbl/query/SBL488704 > > > SBL488686 > 91.193.75.58/32 > ghlc.biz > 22-Jun-2020 18:39 GMT > NanoCore botnet controller @91.193.75.58 > https://www.spamhaus.org/sbl/query/SBL488686 > > > SBL488548 > 185.244.30.201/32 > ghlc.biz > 19-Jun-2020 13:21 GMT > QuasarRAT botnet controller @185.244.30.201 > https://www.spamhaus.org/sbl/query/SBL488548 > > > SBL488006 > 185.140.53.162/32 > ghlc.biz > 18-Jun-2020 10:11 GMT > NanoCore botnet controller @185.140.53.162 > https://www.spamhaus.org/sbl/query/SBL488006 > > > SBL487900 > 185.140.53.229/32 > ghlc.biz > 16-Jun-2020 13:28 GMT > NanoCore botnet controller @185.140.53.229 > https://www.spamhaus.org/sbl/query/SBL487900 > > > SBL487899 > 185.244.30.113/32 > ghlc.biz > 16-Jun-2020 12:59 GMT > RemcosRAT botnet controller @185.244.30.113 > https://www.spamhaus.org/sbl/query/SBL487899 > > > SBL487893 > 185.140.53.236/32 > ghlc.biz > 16-Jun-2020 12:07 GMT > NanoCore botnet controller @185.140.53.236 > https://www.spamhaus.org/sbl/query/SBL487893 > > > SBL487886 > 185.165.153.45/32 > ghlc.biz > 16-Jun-2020 10:26 GMT > NanoCore botnet controller @185.165.153.45 > > https://www.spamhaus.org/sbl/query/SBL487886

2 2

New on RIPE Labs: What is Network Time Security and Why is it Important?
by Mirjam Kuehne 23 Jun '20

23 Jun '20

Dear colleagues, In his RIPE Labs article, Michael Cardell Widerkrantz from Netnod is explaining the Network Time Security protocol is and why it matters: https://labs.ripe.net/Members/michael_cardell_widerkrantz/what-is-network-t… Kind regards, Mirjam Kühne RIPE NCC

1 0

inter-cloud.tech - 9th worst source of spam in the entire world
by Justin S 11 Jun '20

11 Jun '20

SpamHaus designates dutch based " inter-cloud.tech" as the worlds 9th worst source of spam in the entire world: https://www.spamhaus.org/sbl/listings/inter-cloud.tech

1 0

Post Election Unwanted Email Collection Project
by IP Abuse Research 26 May '20

26 May '20

To Whom It May Concern, Around the time of the election RIPE members posted about receiving unwanted email from candidates. I would like to more formally quantify this event. To start I have two questions: 1) Has anyone followed up with RIPE membership to assess how large of a mailing run was sent? Did all registered RIPE members sent email or only a portion? 2) Has anyone collected samples of the unwanted mail with or without headers to establish a corpus which can be analyzed? If this feedback and corpus has not yet been compiled / established I am happy to help do so. Please send any details and examples you're willing to share. Thank you for your time and willingness to help quantify this event.

1 0

bgprep.info
by mohsen atiq 26 May '20

26 May '20

Dear Sir, Recently I developed a robot that collects reported IP lists from more than 160 resources and then tries to categorize and normalize these lists. Some of these resources are highly reputed, and some of them are personal-lists. I summarize the result in the https://bgprep.info/report web app. this tiny app provides basic search and reporting functionality and a free, unlimited rest API for researching purpose. Besides this, I maintain my database of IP-Location and BGP AS-location. Currently, the information is updated regularly every week, but I will try to decrease the update interval. I am very eager to hear your feedback about this app. Please consider this information, and related data is entirely free and remains free in the future. Best regards. Mohsen

1 0

Spam from provider Timeweb/Russia AS9123 - and they just ignore me
by Martin Wilhelmi 25 May '20

25 May '20

Hey everyone, I have a conflict with a provider from Russia "Timeweb" AS9123. It seems to be hosting a customer who sends spam and uses one of my domains as sender. I got the information via DMARC, RFC 7489 with several mails. This provider has an abuse email address. After I contacted them, they analyzed my domain, complained about the header of the automatic DMARC e-mail from mail.ru, because there an internal host distributes it and uses an internal IP address 10/8 according to RFC 1918 and so on. Apparently one does not want to do anything and requests one of these e-mails classified as spam sent to @mail.ru. But this is not provided for in the DMARC protocol, which the provider does not 'believe’. This means I continue to receive emails from Russia telling me that my domain is being used by their host to send spam. And the provider writes me many e-mails telling me that I have to provide correct facts and that nothing else will be done. Because DMARC emails are not facts and cannot be used as evidence. Do you have any idea how to deal with this? I have received 11 DMARC emails from mail.ru regarding this host. I have attached last one here with header: Return-Path: <dmarc_support(a)corp.mail.ru> Delivered-To: mnin(a)mnin.de Received: from mail.mnin.de ([xxxx]) by mail.mnin.de with LMTP id yedWJNMKx14sDAAAuS6XVA (envelope-from <dmarc_support(a)corp.mail.ru>) for <mnin(a)mnin.de>; Fri, 22 May 2020 01:12:19 +0200 Received: from relay7.m.smailru.net (relay7.m.smailru.net [94.100.178.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.mnin.de (Postcow) with ESMTPS id 6D59868509C for <mnin(a)mnin.de>; Fri, 22 May 2020 01:12:18 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=corp.mail.ru; s=mail; h=Date:Message-ID:To:From:Subject:MIME-Version:Content-Type; bh=DMqnfyeB+D0YjhIdtRipG66iEqaOVRHns+l07FJTLbw=; b=k6PdTMpn2SHfn7HO4jdOto6jxVRnOLsCsFLz0Lp87ytUyQL7ifwnze/LC/xQlDQ1hLpkHdM/sM8RFDgusUQYtL4e7/Zkmln4vsjgPvsW6go/YK7hvaeQBKMKgDSXqTlTXqm7BUyXOU4g9wByuAWUM0UpOM+3lrgHzm7d/Fil5IU=; Received: from [10.161.4.115] (port=48176 helo=60) by relay7.m.smailru.net with esmtp (envelope-from <dmarc_support(a)corp.mail.ru>) id 1jbuMI-0007Kr-2n for mnin(a)mnin.de; Fri, 22 May 2020 02:12:14 +0300 Content-Type: multipart/mixed; boundary="===============1678280035031557895==" MIME-Version: 1.0 Subject: Report Domain: mnin.de; Submitter: Mail.Ru; Report-ID: 25590927945792699841590019200 From: dmarc_support(a)corp.mail.ru To: mnin(a)mnin.de Message-ID: <dmarc-1590102734(a)corp.mail.ru> Date: Fri, 22 May 2020 02:12:14 +0300 Auto-Submitted: auto-generated ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=mnin.de; s=dkim; t=1590102738; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: dkim-signature; bh=DMqnfyeB+D0YjhIdtRipG66iEqaOVRHns+l07FJTLbw=; b=YpE4Z5u3l+mzLxsH+2Qbd39KekLCXa2jbbIrdnDxvgNFS6zvl4zKq33jQ/7fs5KkJEB0Xc VCRT+1keQ9x/+a0tp6IMMUKE1elcOp6LHbBzTXCZYcgylnhbmb/JrCgAUI67KzXJlLn4o4 pxToLIR5HD58dGeler0v2GTby5si8GUfczS2mM4QAvxJHDSZ8GqTE359H8HTmXUXGBQRb+ 0RVhhOzYxwmusEpWvuMcXYm4oZ7V+eKNuv12N5xCAbaWaqen37v1M53j0pu1vYoUSQBgOa dv3UgtOSdPxj8wVI5OzpY6ZVKtfSqyTXW5dV+8yfZUSe1Zpm/UPOO5eaqyUnpw== ARC-Seal: i=1; s=dkim; d=mnin.de; t=1590102738; a=rsa-sha256; cv=none; b=keiIRdDt35e1bk6toEJdITgagC1CXQE81NoMoM8T19TBM9LFU4zudqRg73qPYgGkqvXqqI Te3Z+AC+CZp9bxfqIOrm2xSE8fNfZEKYhl5fB59sen9/m1rwiZznvvbNcBCJMpytYyDAbg l74M2uJVfvrUAoAbMF8dweJV/SANBC2K6eKs1r9nRu5DrCEcicWKNLxWbvZ7Q/TccUGgeZ VCyYvxqc0m5U7wZqK/32Sgf1EpWAjkXpC5eTMxH73FfrIkpPQa8v5ag6qKMP+GRk8B3GO1 eQxsci0l3eATOMFFeEAW/QkSB+ur5f2bPEraluEN5VD4iwWzd2tBGmbcT0ZKaw== ARC-Authentication-Results: i=1; mail.mnin.de; dkim=pass header.d=corp.mail.ru header.s=mail header.b=k6PdTMpn; spf=pass (mail.mnin.de: domain of dmarc_support(a)corp.mail.ru designates 94.100.178.51 as permitted sender) smtp.mailfrom=dmarc_support(a)corp.mail.ru X-Last-TLS-Session-Version: TLSv1.2 Authentication-Results: mail.mnin.de; dkim=pass header.d=corp.mail.ru header.s=mail header.b=k6PdTMpn; dmarc=pass (policy=reject) header.from=corp.mail.ru; spf=pass (mail.mnin.de: domain of dmarc_support(a)corp.mail.ru designates 94.100.178.51 as permitted sender) smtp.mailfrom=dmarc_support(a)corp.mail.ru --===============1678280035031557895== MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhpcyBpcyBhbiBhZ2dyZWdhdGUgcmVwb3J0IGZyb20gTWFpbC5SdS4= --===============1678280035031557895== Content-Type: application/gzip MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="mail.ru!mnin.de!1590019200!1590105600.xml.gz" H4sICM4Kx14C/21haWwucnUhbW5pbi5kZSExNTkwMDE5MjAwITE1OTAxMDU2MDAueG1sAIVTQXKk MAy85xW5zSkYqDADW4qzH9jLfsDlscXgCtgu22Szv48MYUJqKpULlpqW6JYFPL9N4/0rhmicfTpU RXm4R6ucNvbydJhT/9Aenvkd9Ij6LNULh4DehSQmTFLLJDm4cBFWTsj/SDMWf2dgVwRwIozrSQYl 4uxz5W/lgi8yXgTirgzAtxSkUM4mqZIwtnd8SMn/YmzA8Upn+XzICBXeVmzajOZ103RlV5+6x+bU 1ceuax8rQsqqq8sS2CcRyASKIO2F5J7xYizfE1cE0OoFrsrmmOGcA9uXspu5eDca9V/4+TyaOGD+ lCP9lk/W2EIj1a85SP1iJh6ArQHI6PslzSd4bp0ltucQt5gC8CrxKovJAT1vPheQRp1P949K3RwU CuN51bZFXTfF6VRUx5Z6Xd+AcrOlpsDWYLOAr3KcyWu2YKJ30STalg8pewQW/T1dEuGLlexgzRcv 7LYjW+QZjTaZ3tAichhQagyiD276HNYeBPaFL+c0iIBxHlP80LDNmqrTkBcGw7Ju28gjjqiSC1wT g8RtKaxtuJcx5jtdkr2ZHxsr55FPWSa1XZJveq4D+aqdbXfGrj/cO84BW+uiAwAA --===============1678280035031557895==-- Decompressed xml is: <?xml version='1.0' encoding='utf-8'?> <feedback><report_metadata><org_name>Mail.Ru</org_name><email>dmarc_support(a)corp.mail.ru</email><extra_contact_info>http://help.mail.ru/mail-help</extra_contact_info><report_id>25590927945792699841590019200</report_id><date_range><begin>1590019200</begin><end>1590105600</end></date_range></report_metadata><policy_published><domain>mnin.de</domain><adkim>r</adkim><aspf>r</aspf><p>none</p><sp>none</sp><pct>100</pct></policy_published><record><row><source_ip>188.225.77.168</source_ip><count>1</count><policy_evaluated><disposition>none</disposition><dkim>fail</dkim><spf>fail</spf></policy_evaluated></row><identifiers><header_from>mnin.de</header_from></identifiers><auth_results><dkim><domain>ninthhelper.ru</domain><selector>dnin</selector><result>pass</result></dkim><spf><domain>ninthhelper.ru</domain><scope>mfrom</scope><result>pass</result></spf></auth_results></record></feedback> Cheers, Martin

4 4

Re: [anti-abuse-wg] Spamming LIR accounts
by JORDI PALET MARTINEZ 14 May '20

14 May '20

I don't think EU laws are useless towards non-EU countries that break them. In the case of privacy, they will not be able to keep doing business with the EU. In a more understanding way, EU (or EU members) reach agreements with specific countries so the sanctions can be applied as well, including fines. For example, when speaking about GDPR, countries like Mauritius and Uruguay, have signed those agreements. I believe the reason is to allow mutual business, it makes a lot of sense: if you are offering applications that collect our citizen data, you must follow our rules, or we will find someone that want to follows them. We do this every other day, in any economic activity. I know that if you violate speed limit in one country the fine will be collected from your account in many other countries, it is just reciprocity. Regards, Jordi @jordipalet El 10/5/20 20:54, "anti-abuse-wg en nombre de Sabri Berisha" <anti-abuse-wg-bounces(a)ripe.net en nombre de sabri(a)cluecentral.net> escribió: ----- On May 7, 2020, at 2:26 AM, Nick Hilliard nick(a)foobar.org wrote: Hi, (And to you Töma, Peace :)) > Töma Gavrichenkov wrote on 07/05/2020 10:03: >> What does GDPR have to say about this? > > You mean the Privacy and Electronic Communications Regulations / PECR. > Spamming is prohibited under article 13. > > National transcriptions of this legislation have implemented this as a > civil offence in some EU countries and a criminal offence in others. Yes, and as long as the sender is safe in a non-EU country, none of the EU "laws" will apply to them nor will they care. It's the same thing as saying bad things about Thailand's king while shouting from a pedestal on St. Petersburg Square. I don't know about you guys, but I have a very effective system for dealing with this kind of crap. It's called *plonk*. Thanks, Sabri ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.

7 11