idnits 2.17.1 draft-vesely-authmethod-dnswl-13.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 5 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 326: '...h the DO bit set MUST NOT be taken to ...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 20, 2019) is 1588 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IETF A. Vesely 3 Internet-Draft December 20, 2019 4 Intended status: Informational 5 Expires: June 22, 2020 7 DNSWL Email Authentication Method Extension 8 draft-vesely-authmethod-dnswl-13 10 Abstract 12 This document describes an additional Email Authentication Method 13 compliant with RFC 8601. The method consists in looking up the 14 sender's IP address in a DNS whitelist. This document is provided 15 for information in case the method is seen in the field, as well as 16 to suggest a useful practice and register the relevant keywords. 18 This document does not consider black lists. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on June 22, 2020. 37 Copyright Notice 39 Copyright (c) 2019 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. Method Details . . . . . . . . . . . . . . . . . . . . . . . 3 53 3. TXT Record Contents . . . . . . . . . . . . . . . . . . . . . 5 54 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 55 4.1. Email Authentication Methods . . . . . . . . . . . . . . 6 56 4.2. Email Authentication Property Type . . . . . . . . . . . 6 57 4.3. Email Authentication Result Names . . . . . . . . . . . . 6 58 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 59 5.1. Over Quota Signaling . . . . . . . . . . . . . . . . . . 7 60 5.2. Security of DNSSEC Validation . . . . . . . . . . . . . . 7 61 5.3. Inherited Security Considerations . . . . . . . . . . . . 8 62 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 63 6.1. Normative References . . . . . . . . . . . . . . . . . . 8 64 6.2. Informative References . . . . . . . . . . . . . . . . . 9 65 Appendix A. Example . . . . . . . . . . . . . . . . . . . . . . 10 66 Appendix B. Known Implementation . . . . . . . . . . . . . . . . 11 67 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13 69 1. Introduction 71 One of the many checks that mail servers carry out is to query domain 72 name system whitelists (DNSWL). That method is fully discussed in 73 [RFC5782]. The DNS [RFC1034] lookup is based on the connecting 74 client's IP address, IPv4 or IPv6, and returns zero or more A 75 records. The latter are IPv4 IP addresses in the range 127/8. 76 Depending on the query, TXT records with varying content can also be 77 retrieved. Query examples are given in Appendix A. 79 Since the IP address is known as soon as the connection is accepted, 80 this check can occur very early in an SMTP transaction. Its result 81 can be used to counterweight policies that typically occur at early 82 stages too, such as the Sender Policy Framework (SPF, the last 83 paragraph of Appendix D.3 of [RFC7208] is also illustrated in 84 Appendix A). In addition, the result of a DNSWL lookup can also be 85 used at later stages; for example, a delivery agent can use it to 86 learn the trustworthiness of a mail relay in order to estimate the 87 spamminess of an email message. The latter possibility needs a place 88 to collect query results for downstream use, which is precisely what 89 the Authentication-Results header field aims at providing. 91 Results often contain additional data, encoded according to DNSWL- 92 specific criteria. The method described in this document considers 93 only whitelists --one of the major branches described by [RFC5782]. 94 There are also black/block lists, DNSBL, and combined lists. Since 95 they all have the same structure, the abbreviation DNSxL is used to 96 mean any. Now, the core procedures of a mail transfer agent (MTA) 97 tend to be quite general, leaving particular cases to be handled by 98 add-on modules. In the case of combined lists, the boundary MTA (see 99 [RFC5598]) which carries out the check and possibly stores the 100 result, has to be able to discern at least the color of each entry, 101 as that is required to make accept/reject decisions. This document 102 provides for storing the result when the DNSxL record to be reported 103 is a whitelisting one. 105 Data conveyed in A and TXT records can be stored as method's 106 properties. In effect, they are tantamount to local policies, albeit 107 outsourced. Downstream agents who know DNSWL-specific encoding can 108 understand the meaning of that data, and use it to make delivery 109 decisions. For example, a mail filter which detected heuristic 110 evidence of scam, can counterweight such data with the 111 trustworthiness score encoded in the A response, so as to protect 112 agains false positives. 114 This document describes a usage of TXT fields consistent with other 115 authentication methods. Namely, to serve the domain name in the TXT 116 record. That way, a downstream filter could also consider whether 117 the sending agent is aligned with the author domain, with semantics 118 similar to [RFC7489]. 120 At the time of this writing, this method is implemented by 121 [Courier-MTA], an outline of the implementation is given in 122 Appendix B. 124 2. Method Details 126 The result of the method states how the query did, up to the 127 interpretation of the returned data. 129 The method has four possible results: 131 pass: The query successfully returned applicable records. This 132 result is usually accompanied by one or both the policy 133 properties described below. Agents unable to interpret 134 those properties can still derive a positive value from 135 the fact that the sender is whitelisted. 136 none: The query worked but yielded no A record, or returned 137 NXDOMAIN, so the sender is not whitelisted. 138 temperror: The DNS evaluation could not be completed due to some 139 error that is likely transient in nature, such as a 140 temporary DNS error, e.g., a DNS RCODE of 2, commonly 141 known as SERVFAIL, or other error condition. A later 142 attempt may produce a final result. 143 permerror: The DNS evaluation cannot work because test entries don't 144 work, that is, DNSWL is broken, or because queries are 145 over quota, e.g., a DNS RCODE of 5, commonly known as 146 REFUSED, or a DNSWL-specific policy.ip with the same 147 meaning. A later attempt is unlikely to produce a final 148 result. Human intervention is required. 150 Note that there is no fail result. 152 The following ptype.property items define how the data provided by 153 the whitelist lookup can be saved. 155 dns.zone: DNSWL query root domain, which defines the meaning of the 156 policy.ip property below. Note that an MTA can use a 157 local mirror with a different name. The name stored here 158 has to be the best available reference for all 159 foreseeable downstream consumers. If the message is 160 handed outside the internal network, dns.zone had better 161 be the global zone. 162 policy.ip: The bit mask value received in type A response, in dotted 163 quad. Multiple entries can be arranged in a comma- 164 separated list. 165 policy.txt: The TXT record, if any. Multiple records are 166 concatenated in the usual way (explained, for example, in 167 Section 3.3 of [RFC7208]). See Section 3 for the 168 resulting content and query options. 169 dns.sec: This is a generic property stating whether the relevant 170 data was validated using DNSSEC ([RFC4033]). For the 171 present method, the relevant data consists of the 172 reported policy properties above, or, if the method 173 result is "none", their non-existence. This property has 174 three possible values: 176 yes: DNSSEC validation confirms the integrity of data. 177 Section 5.2 considers how that is related to the DNS 178 response. 179 no: The data is not signed. See Section 5.2. 180 na: Not applicable. No DNSSEC validation can be 181 performed, possibly because the lookup is run 182 through a different means than a security-aware DNS 183 resolver. This does not necessarily imply less 184 security. In particular, "na" is used if the data 185 was downloaded in bulk and then loaded on a local 186 nameserver --which is the case of an MTA querying a 187 local zone different from the reported dns.zone. 188 DNS errors, including validation errors, can also 189 report "na". This is also the value assumed by 190 default. 192 3. TXT Record Contents 194 According to [RFC5782], TXT records describe the reason why IP 195 addresses are listed in a DNSWL. The TXT record is useful if it 196 contains the domain names. The domain name would correspond to the 197 DNS domain name used by or within the administrative domain (ADMD) 198 operating the relevant MTA, sometimes called the "organizational 199 domain". In that case, the authentication provided by this method is 200 equivalent to a DKIM signature ([RFC6376]) or an SPF check host 201 ([RFC7208]), if the DNSWL is trusted. 203 According to a DNSWL's policy, attributing responsibility of an IP 204 address to an organization may require something more than a mere PTR 205 record consistency. If no domain names can be responsibly associated 206 to a given IP address, for example because the IP address was added 207 without direct involvement of the organization concerned, DNSWLs can 208 use a subdomain of .INVALID ([RFC2606]) where the leftmost label 209 hints at why an address is whitelisted. For example, if the address 210 192.0.2.38 was added by the list managers solely based on their 211 knowledge, the corresponding TXT record might be 212 AUTOPROMOTED.INVALID, so as to avoid to explicitly identify an entity 213 who didn't opt-in. 215 Following the example of Multicast DNS (see the second paragraph of 216 Section 16 of [RFC6762]) names containing non-ASCII characters can be 217 encoded in UTF-8 [RFC3629] using the normalization form canonical 218 composition (NFC) as described in Unicode Format for Network 219 Interchange ([RFC5198]). Inclusion of unaltered UTF-8 TXT values in 220 the header entails an environment compatible with EAI [RFC6530]. 222 DNS queries with a QTYPE of ANY may lead to inconsistent replies, 223 depending on the cache status. In addition, ANY is not "all", and 224 the provisions for queries that have QTYPE=ANY ([RFC8482]) don't 225 cover DNSxLs. A mail server can issue two simultaneous queries, A 226 and TXT. Otherwise, a downstream filter can issue a TXT query on its 227 own, if it knows that an A query was successful and that the DNSWL 228 serves useful TXT records. It is unlikely that TXT records exist if 229 a query for QTYPE A brought a result of none. 231 4. IANA Considerations 233 IANA maintains the "Email Authentication Parameters" registry with 234 several subregistries. IANA is requested to make assignments as set 235 out in the following sections. 237 4.1. Email Authentication Methods 239 IANA is requested to create four new entries in the "Email 240 Authentication Methods" registry as follows. 242 ------+----------+------+--------+-------------------+------+------- 243 Method|Definition|ptype |property| Value |Status|Version 244 ------+----------+------+--------+-------------------+------+------- 245 dnswl |[This.I-D]|dns |zone | DNSWL publicly |active| 1 246 | | | | accessible query | | 247 | | | | root domain | | 248 dnswl |[This.I-D]|policy|ip | type A response |active| 1 249 | | | | received (or | | 250 | | | | comma-separated | | 251 | | | | list thereof) | | 252 dnswl |[This.I-D]|policy|txt | type TXT query |active| 1 253 | | | | response | | 254 dnswl |[This.I-D]|dns |sec | one of "yes" for |active| 1 255 | | | | DNSSEC | | 256 | | | | authenticated | | 257 | | | | data, "no" for | | 258 | | | | not signed, or | | 259 | | | | "na" for not | | 260 | | | | applicable | | 261 ------+----------+------+--------+-------------------+------+------- 263 4.2. Email Authentication Property Type 265 IANA is requested to create a new entry in the "Email Authentication 266 Property Types" registry as follows. 268 +-------+------------+----------------------------------------------+ 269 | ptype | Definition | Description | 270 +-------+------------+----------------------------------------------+ 271 | dns | [This.I-D] | The property being reported belongs to the | 272 | | | Domain Name System | 273 +-------+------------+----------------------------------------------+ 275 4.3. Email Authentication Result Names 277 IANA is requested to create four new entries in the "Email 278 Authentication Result Names" registry as follows. 280 +-------------+-----------+---------------+--------+ 281 | Auth Method | Code | Specification | Status | 282 +-------------+-----------+---------------+--------+ 283 | dnswl | pass | [This.I-D] | active | 284 | | | | | 285 | dnswl | none | [This.I-D] | active | 286 | | | | | 287 | dnswl | temperror | [This.I-D] | active | 288 | | | | | 289 | dnswl | permerror | [This.I-D] | active | 290 +-------------+-----------+---------------+--------+ 292 5. Security Considerations 294 5.1. Over Quota Signaling 296 Some DNSWLs which provide for free access below a given quota, are 297 known to return special codes to signal over quota, for example 298 127.0.0.255. If the MTA cannot interpret that value, that case 299 results in a false positive. It will accept messages having spf=fail 300 if configured to do so. A DNSWL-specific module would realize the 301 fact and call for human intervention. 303 Returning an RCODE 5 (REFUSED) conveys the concept that the query is 304 "unauthorized", and human intervention required. 306 5.2. Security of DNSSEC Validation 308 The dns.sec property is meant to be as secure as DNSSEC results. It 309 makes sense to use it in an environment where the DNSSEC validation 310 can succeed. 312 Section 7 of [RFC4033] examines various ways of setting up a stub 313 resolver which either validates DNSSEC locally or trusts the 314 validation provided through a secure channel. For a different class, 315 it is possible to set up a dedicated, caching, dnssec-enabled 316 resolver reachable by the mail server through interprocess 317 communication on 127.0.0.1. In such cases, the property dns.sec=yes 318 corresponds to the Authenticated Data (AD) bit in the DNS response 319 header. 321 When the response contains no DNSSEC data, a security-aware resolver 322 seeks a signed proof of the non-existence of a DS record, at some 323 delegation point. If no error is returned, the zone is unsigned and 324 dns.sec=no can be set. Quoting the Security Considerations 325 Section of [RFC3225]: The absence of DNSSEC data in response to a 326 query with the DO bit set MUST NOT be taken to mean no security 327 information is available for that zone as the response may be forged 328 or a non-forged response of an altered (DO bit cleared) query. 330 If the application verifies the DNSSEC signatures on its own, it 331 effectively behaves like a validating stub resolver, and hence can 332 set dns.sec correspondingly. 334 When the data is downloaded in bulk and made available on a trusted 335 channel without using DNSSEC, set dns.sec=na or not at all. DNSWL 336 who publish bulk versions of their data can also sign that data, for 337 example using OpenPGP ([RFC4880]). It is the responsibility of 338 system administrators to authenticate the data by downloading and 339 validating the signature. The result of such validation is not 340 reported using dns.sec. 342 5.3. Inherited Security Considerations 344 For DNSSEC, the considerations of Section 12 of [RFC4033] apply. 346 All of the considerations described in Section 7 of [RFC8601] apply. 347 That includes securing against tampering all the channels after the 348 production of this Authentication-Results header field. 350 In addition, the usual caveats apply about importing text from 351 external online sources. Although queried DNSWLs are well known, 352 trusted entities, it is suggested that TXT records be reported only 353 if, upon inspection, their content is deemed actually actionable, and 354 their format compatible with the computing environment. 356 6. References 358 6.1. Normative References 360 [RFC2606] Eastlake 3rd, D. and A. Panitz, "Reserved Top Level DNS 361 Names", BCP 32, RFC 2606, DOI 10.17487/RFC2606, June 1999, 362 . 364 [RFC5782] Levine, J., "DNS Blacklists and Whitelists", RFC 5782, 365 DOI 10.17487/RFC5782, February 2010, . 368 [RFC8601] Kucherawy, M., "Message Header Field for Indicating 369 Message Authentication Status", RFC 8601, 370 DOI 10.17487/RFC8601, May 2019, . 373 6.2. Informative References 375 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 376 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 377 . 379 [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", 380 RFC 3225, DOI 10.17487/RFC3225, December 2001, 381 . 383 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 384 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 385 2003, . 387 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 388 Rose, "DNS Security Introduction and Requirements", 389 RFC 4033, DOI 10.17487/RFC4033, March 2005, 390 . 392 [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. 393 Thayer, "OpenPGP Message Format", RFC 4880, 394 DOI 10.17487/RFC4880, November 2007, . 397 [RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network 398 Interchange", RFC 5198, DOI 10.17487/RFC5198, March 2008, 399 . 401 [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, 402 DOI 10.17487/RFC5598, July 2009, . 405 [RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., 406 "DomainKeys Identified Mail (DKIM) Signatures", STD 76, 407 RFC 6376, DOI 10.17487/RFC6376, September 2011, 408 . 410 [RFC6530] Klensin, J. and Y. Ko, "Overview and Framework for 411 Internationalized Email", RFC 6530, DOI 10.17487/RFC6530, 412 February 2012, . 414 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 415 DOI 10.17487/RFC6762, February 2013, . 418 [RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for 419 Authorizing Use of Domains in Email, Version 1", RFC 7208, 420 DOI 10.17487/RFC7208, April 2014, . 423 [RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based 424 Message Authentication, Reporting, and Conformance 425 (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015, 426 . 428 [RFC8482] Abley, J., Gudmundsson, O., Majkowski, M., and E. Hunt, 429 "Providing Minimal-Sized Responses to DNS Queries That 430 Have QTYPE=ANY", RFC 8482, DOI 10.17487/RFC8482, January 431 2019, . 433 [Courier-MTA] 434 "Courier Mail Server", . 436 [dnswl.org] 437 "DNSWL.ORG", . 439 Appendix A. Example 441 Delivered-To: recipient@example.org 442 Return-Path: 443 Authentication-Results: mta.example.org; 444 dkim=pass (whitelisted) header.i=@example.com 445 Authentication-Results: mta.example.org; 446 dnswl=pass dns.zone=list.dnswl.example dns.sec=na 447 policy.ip=127.0.10.1 448 policy.txt="fwd.example https://dnswl.example/?d=fwd.example" 449 Received-SPF: fail (Address does not pass Sender Policy Framework) 450 client-ip=192.0.2.1; 451 envelope-from="sender@example.com"; 452 helo=mail.fwd.example; 453 receiver=mta.example.org; 454 Received: from mail.fwd.example (mail.fwd.example [2001:db8::2:1]) 455 (TLS: TLSv1/SSLv3,128bits,ECDHE-RSA-AES128-GCM-SHA256) 456 by mta.example.org with ESMTPS; Thu, 03 Oct 2019 19:23:11 +0200 457 id 00000000005DC044.000000005702D87C.000007FC 459 Trace fields at the top of the header 461 The message went through a third party, fwd.example, which forwarded 462 it to the final MTA. Such mail path was not arranged beforehand with 463 the involved MTAs, it emerged spontaneously. This message would not 464 have made it to the target without whitelisting, because: 466 o the author domain published a strict SPF policy (-all), 467 o the forwarder did not alter the bounce address, and 468 o the target usually honors reject-on-fail, according to Section 8.4 469 of [RFC7208]. 471 However, the target also implemented the last paragraph of 472 Appendix D.3 of [RFC7208]. Its behavior hinges on the following DNS 473 entries: 475 1.0.0.0.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.d.b.8.2.0.0.1. 476 list.dnswl.example. 477 IN A 127.0.10.1 478 IN TXT "fwd.example https://dnswl.example/?d=fwd.example" 480 DNS resource records for 2001:db8::2:1 481 (line breaks for editorial reasons) 483 If mail.fwd.example had connected from address 192.0.2.1, then the 484 query name would have been 1.2.0.192.list.dnswl.example. See full 485 description in [RFC5782] 487 At connection time, because the remote IP address is whitelisted, the 488 target MTA did not reject the message before DATA. Instead, it 489 recorded the SPF fail result, and indicated the local policy 490 mechanism which was applied in order to override that result. 491 Subsequent filtering verified DKIM [RFC6376]. 493 At later stages, mail filters can reject or quarantine the message 494 based on its content. A deeper knowledge of the policy values 495 obtained from dnswl.example allows to interpret the values of 496 policy.ip and weight them against other factors so as to make better 497 decisions. 499 Appendix B. Known Implementation 501 Implementation details mentioned in this section have been stable for 502 several years. Yet, this description is necessarily superficial, 503 version dependent, and subject to change. 505 [Courier-MTA] can be configured to lookup DNSBL and DNSWL, with 506 similar command line switches: 508 -block=zone[=displayzone][,var[/n.n.n.n][,msg]] 509 -allow=zone[=displayzone][,var[/n.n.n.n[,]]] 511 zone is the zone to be queried. 513 displayzone is only used for -allow, it is the value to be set in the 514 dns.zone property. 516 var stands for the environment variable whose existence triggers a 517 special action. The default variable names result in a conventional 518 behavior implemented by Courier-MTA. By setting different 519 environment variables, users can customize the behavior. 520 Conventional behavior differs widely between -block and -allow. The 521 former rejects the message, the latter produces Authentication- 522 Results header fields. 524 The n.n.n.n IP address requires a precise A record response. If not 525 given, any response results in setting the corresponding variable. 526 If given, variables are set only if the response matches exactly. 527 Such syntax provides for a very limited interpretation the 528 information encoded in A records. However, it is considered to be 529 too complicated already. Even specifying a range or an enumeration 530 of values would require something beyond what a normal user would be 531 willing to manage. 533 Finally, the trailing message, which overrides the 5xx SMTP reply for 534 -block, is not used for -allow, except that its mere presence 535 requires to query TXT records to be registered in policy.txt. 537 SPF is part of Courier-MTA's core. It is configured separately, and 538 provides for an "allowok" keyword to indicate to override rejection 539 in case of SPF failure and -allow whitelisting. 541 A customary whitelist is [dnswl.org]. It serves A records encoded as 542 follows: 544 1st octect: 127. 545 2nd octect: 0. 546 3rd octect: Category of business, 15 values. 547 4th octect: Trusworthiness/score, 4 values. 549 They also serve TXT records containing the domain name followed by an 550 URL pointing to further info about the relevant organization, such as 551 what other IP addresses of theirs are being whitelisted. They don't 552 use UTF-8. 554 dnswl.org provides for free registration and free access below 555 100,000 queries per day. They use the special return code 556 127.0.0.255 exemplified above to signal over quota. Although 557 Courier-MTA itself does not recognize it, it has a mail filter 558 (zdkimfilter, named after its main usage) where recognition of that 559 code, as well as that of trusworthiness in the 4th octect are hard- 560 coded. 562 Author's Address 564 Alessandro Vesely 565 v. L. Anelli 13 566 Milano, MI 20122 567 IT 569 Email: vesely@tana.it