From c05745a3dea02e588793850d44c98d1d480b5729 Mon Sep 17 00:00:00 2001 From: Julian Ospald Date: Wed, 15 Jun 2016 14:40:15 +0200 Subject: [PATCH] First commit --- .gitignore | 29 + Bachelorthesis/Appendix.tex | 44 + Bachelorthesis/Bachelorthesis.tex | 161 + Bachelorthesis/BachelorthesisLiterature.bib | 719 + Bachelorthesis/Content/Abstract.tex | 21 + .../Content/AlternativeLoesungen.tex | 5 + .../AlternativeLoesungen/Bewertung.tex | 1 + .../Content/AlternativeLoesungen/DarkMail.tex | 3 + Bachelorthesis/Content/Entwicklung.tex | 0 .../Content/Entwicklung/IdeaConcept.tex | 8 + .../Entwicklung/IdeaConcept/Algorithmus.dia | 2329 + .../Entwicklung/IdeaConcept/Algorithmus.png | Bin 0 -> 32501 bytes .../Entwicklung/IdeaConcept/Algorithmus.tex | 124 + .../Content/Entwicklung/Methoden.tex | 15 + .../Content/Entwicklung/Realisierung.tex | 5 + .../Realisierung/Implementierung.tex | 1 + .../Implementierung/Einsprungpunkt.tex | 15 + .../Realisierung/Implementierung/Haraka.tex | 33 + .../Implementierung/Konfiguration.tex | 30 + .../Implementierung/MTA-Entscheider.tex | 50 + .../Implementierung/SMTP-gateway.tex | 38 + .../Realisierung/Implementierung/Wahl.tex | 24 + .../Entwicklung/Realisierung/Testsystem.tex | 13 + .../Content/EvaluationValidation.tex | 19 + Bachelorthesis/Content/Intro.tex | 25 + Bachelorthesis/Content/Intro/Format.tex | 96 + Bachelorthesis/Content/Intro/Gesamtsystem.tex | 43 + Bachelorthesis/Content/Intro/Protokolle.tex | 5 + .../Content/Intro/Protokolle/IMAP4.dia | 3063 ++ .../Content/Intro/Protokolle/IMAP4.png | Bin 0 -> 53101 bytes .../Content/Intro/Protokolle/IMAP4.tex | 59 + .../Content/Intro/Protokolle/POP3.tex | 73 + .../Content/Intro/Protokolle/SMTP-Model.dia | 670 + .../Content/Intro/Protokolle/SMTP-Model.png | Bin 0 -> 16734 bytes .../Content/Intro/Protokolle/SMTP.tex | 76 + .../Content/Intro/Protokolle/emailg.dia | 2307 + .../Content/Intro/Protokolle/emailg.png | Bin 0 -> 38992 bytes .../ListOfAbbreviations.tex | 32 + Bachelorthesis/Content/LookOut.tex | 4 + .../Content/LookOut/PraktischeProbleme.tex | 1 + .../PraktischeProbleme/DirectoryServer.tex | 4 + .../PraktischeProbleme/Fehlerbehandlung.tex | 5 + .../PraktischeProbleme/Gesamtsystem.tex | 7 + .../PraktischeProbleme/Implementierung.tex | 6 + .../LookOut/PraktischeProbleme/Spam.tex | 7 + .../LookOut/PraktischeProbleme/Verify.tex | 5 + .../PraktischeProbleme/Zuverlaessigkeit.tex | 3 + .../Content/LookOut/TheoretischeProbleme.tex | 1 + .../KryptografieSystem.tex | 1 + .../TheoretischeProbleme/PublicKey.tex | 4 + .../TheoretischeProbleme/RoutingAlgo.tex | 5 + .../TheoretischeProbleme/Spezifikation.tex | 5 + .../TheoretischeProbleme/Verschluesselung.tex | 3 + Bachelorthesis/Content/Problematik.tex | 19 + .../Content/Problematik/Anforderungen.tex | 75 + .../Problematik/BetrachtungDatenschutz.tex | 1 + .../BetrachtungDatenschutz/Anonymitaet.tex | 5 + .../Anonymitaet/TorBirdy.tex | 28 + .../BetrachtungDatenschutz/Bewertung.dia | 2374 ++ .../BetrachtungDatenschutz/Bewertung.png | Bin 0 -> 32473 bytes .../BetrachtungDatenschutz/Bewertung.tex | 18 + .../Verschluesselung.tex | 5 + .../Verschluesselung/GPG.tex | 30 + .../Verschluesselung/STARTTLS.tex | 33 + .../Verschluesselung/TLS.tex | 14 + .../Verschluesselung/asymcrypto.dia | 1964 + .../Verschluesselung/asymcrypto.png | Bin 0 -> 47014 bytes Bachelorthesis/Content/Settings.tex | 418 + .../StatutoryDeclaration.tex | 20 + Bachelorthesis/Content/TitlePage.tex | 34 + .../TitlePage/fhbi_logo_kompakt_orange.jpg | Bin 0 -> 52602 bytes Bachelorthesis/LICENSE | 437 + Bachelorthesis/Makefile | 79 + COPYRIGHT | 7 + Implementierung/Handbuch.md | 100 + Implementierung/LICENSE | 340 + Implementierung/Makefile | 13 + .../alpine-haraka-gateway/Dockerfile | 50 + .../alpine-haraka-gateway/README.md | 4 + .../alpine-haraka-gateway/config/plugins | 9 + .../docker-entrypoint.sh | 131 + .../plugins/.tern-project | 12 + .../plugins/create_myst_mail.js | 162 + .../plugins/enable_parse_body.js | 25 + .../alpine-haraka-gateway/plugins/my_mx.js | 34 + .../plugins/open_relay.js | 46 + Implementierung/alpine-haraka/Dockerfile | 50 + Implementierung/alpine-haraka/README.md | 4 + Implementierung/alpine-haraka/config/plugins | 12 + .../alpine-haraka/docker-entrypoint.sh | 131 + .../alpine-haraka/plugins/.tern-project | 12 + .../alpine-haraka/plugins/add_myst_header.js | 25 + .../plugins/data_post_write_mail.js | 42 + .../plugins/enable_parse_body.js | 25 + .../alpine-haraka/plugins/my_mx.js | 34 + .../alpine-haraka/plugins/my_transaction.js | 168 + .../alpine-haraka/plugins/myst_send.js | 29 + .../alpine-haraka/plugins/open_relay.js | 46 + .../alpine-haraka/plugins/test_queue.js | 42 + Implementierung/alpine-swaks/Dockerfile | 10 + Implementierung/alpine-swaks/README.md | 1 + Makefile | 21 + README.md | 9 + RFCs/rfc1521.txt | 4539 ++ RFCs/rfc1522.txt | 563 + RFCs/rfc1730.txt | 4318 ++ RFCs/rfc1939.txt | 1291 + RFCs/rfc196.txt | 218 + RFCs/rfc2045.txt | 1739 + RFCs/rfc2046.txt | 2467 ++ RFCs/rfc2047.txt | 843 + RFCs/rfc2049.txt | 1347 + RFCs/rfc2183.txt | 675 + RFCs/rfc2487.txt | 451 + RFCs/rfc2595.txt | 843 + RFCs/rfc2821.txt | 4427 ++ RFCs/rfc2822.txt | 2859 ++ RFCs/rfc3207.txt | 507 + RFCs/rfc3501.txt | 6051 +++ RFCs/rfc4035.txt | 2971 ++ RFCs/rfc4288.txt | 1347 + RFCs/rfc4289.txt | 619 + RFCs/rfc4880.txt | 5043 +++ RFCs/rfc5246.txt | 5827 +++ RFCs/rfc5321.txt | 5323 +++ RFCs/rfc5322.txt | 3195 ++ RFCs/rfc6376.txt | 4259 ++ RFCs/rfc6409.txt | 1123 + RFCs/rfc7457.txt | 731 + RFCs/rfc821.txt | 4050 ++ RFCs/rfc822.txt | 2901 ++ RFCs/rfc974.txt | 399 + ...uild, Ship, and Run Any App, Anywhere.html | 716 + .../Logo-Docker.svg | 108 + .../Swarmnado-357x627-15.gif | Bin 0 -> 938202 bytes .../XDFrame.html | 50 + .../affix.js | 162 + .../agility_0.png | Bin 0 -> 1199 bytes .../animate.min.css | 6 + .../app.css | 1 + .../app.js | 610 + .../app1.css | 5114 +++ .../big_data_blue_icon.svg | 27 + .../bootstrap.min.css | 14 + .../build.png | Bin 0 -> 16172 bytes .../control_0.png | Bin 0 -> 484 bytes .../cubeportfolio.min.css | 12 + .../devops_blue_icon.svg | 33 + .../docker.js | 944 + .../docker_datacenter_banner_image_1.png | Bin 0 -> 13618 bytes .../docker_diagram51.svg | 1105 + .../fa-reddit-alien.png | Bin 0 -> 5943 bytes .../flexslider.css | 96 + .../font-awesome.min.css | 4 + .../forms2-theme-simple.css | 32 + .../forms2.css | 562 + .../forms2.min.js | 7 + .../foundation.js | 6392 +++ .../infrastructure_blue_icon.svg | 45 + .../integration_blue_icon.svg | 120 + .../isotope.pkgd.min.js | 12 + .../jquery-migrate-1.2.1.min.js | 2 + .../jquery-ui-slider-pips.css | 407 + .../jquery-ui-slider-pips.min.js | 3 + .../jquery-ui.min.css | 7 + .../jquery-ui.min.js | 13 + .../jquery.ba-bbq.js | 1137 + .../jquery.cubeportfolio.min.js | 12 + .../jquery.flexslider.js | 1191 + .../jquery.magnific-popup.min.js | 4 + .../jquery.matchHeight.min.js | 10 + .../jquery.smooth-scroll.min.js | 7 + .../jquery.ui.touch-punch.min.js | 11 + .../magnific-popup.css | 374 + .../modernizr.min.js | 1 + .../portability_0.png | Bin 0 -> 1404 bytes .../run.png | Bin 0 -> 2230 bytes .../scrollspy.min.js | 1 + .../ship.png | Bin 0 -> 15110 bytes .../track.js | 40 + .../vendor.js | 35126 ++++++++++++++++ .../wow.js | 2 + Webseiten/Haraka SMTP Email Server.html | 96 + .../application.js | 83 + .../bootstrap.css | 7 + .../bootstrap.js | 6 + .../btn_donate_LG.gif | Bin 0 -> 1714 bytes .../Haraka SMTP Email Server_files/docs.css | 995 + .../Haraka SMTP Email Server_files/holder.js | 419 + .../Haraka SMTP Email Server_files/jquery.js | 6 + .../pygments-manni.css | 66 + ...ls@w3.org from January to March 1997).html | 271 + .../public-message | 20 + Webseiten/Open Source - Sendmail.com.html | 782 + .../Open Source - Sendmail.com_files/brand | 109 + .../btn_search_trans.png | Bin 0 -> 758 bytes .../Open Source - Sendmail.com_files/head.css | 247 + .../letter-bt.jpg | Bin 0 -> 17732 bytes .../Open Source - Sendmail.com_files/main.css | 1109 + .../munchkin.js | 8 + .../open_source.css | 137 + .../proofpoint-sendmail-logo_240.png | Bin 0 -> 6651 bytes .../slide_layer.js | 102 + .../swfobject.js | 11 + Webseiten/OpenBSD 5.3.html | 850 + Webseiten/OpenBSD 5.3_files/RoyPuffy.jpg | Bin 0 -> 82327 bytes Webseiten/OpenBSD 5.3_files/smalltitle.gif | Bin 0 -> 2220 bytes Webseiten/OpenSMTPD.html | 85 + Webseiten/OpenSMTPD_files/opensmtpd.png | Bin 0 -> 82940 bytes Webseiten/The GNU Privacy Guard.html | 268 + .../cc-by-sa-3.0_80x15.png | Bin 0 -> 672 bytes .../logo-gnupg-light-purple-bg.png | Bin 0 -> 9024 bytes .../The GNU Privacy Guard_files/site.css | 734 + .../traueranzeige-g10_v2015.png | Bin 0 -> 3821 bytes ...re made to make email easier. — Mozilla.html | 440 + .../common-bundle.f0a21783cc6e.js | 4 + .../logo.e19c8e6706dd.png | Bin 0 -> 7630 bytes .../responsive-bundle.2b0724257ae0.css | 1 + .../screenshot-linux.7af76cb37bda.png | Bin 0 -> 32289 bytes .../site-bundle.6009f70fa7b1.js | 1 + .../thunderbird-landing-bundle.b9555ff2948e.css | 1 + .../wordmark.3b0e03fa56f1.png | Bin 0 -> 6462 bytes Webseiten/Tor Browser.html | 789 + .../InternetDefenseLeague-footer-badge.png | Bin 0 -> 7253 bytes Webseiten/Tor Browser_files/master.css | 4 + Webseiten/Tor Browser_files/onion.jpg | Bin 0 -> 3911 bytes .../screenshot-osx-torbrowser-icon.png | Bin 0 -> 25569 bytes .../Tor Browser_files/tbb-close-button.png | Bin 0 -> 985 bytes .../Tor Browser_files/tbb-screenshot1.jpg | Bin 0 -> 118817 bytes .../Tor Browser_files/tbb-screenshot2.jpg | Bin 0 -> 158895 bytes .../Tor Browser_files/tbb-screenshot3.jpg | Bin 0 -> 259865 bytes Webseiten/Tor Browser_files/tbbproject.css | 274 + ...r library and command line utilities..html | 1389 + .../1241845 | Bin 0 -> 928 bytes .../77851 | Bin 0 -> 5190 bytes ...d692eff9a2e78dcd63daa5b580c38b36df3fdb.css | 2 + ...cb01f83f1cdb613eda0449f533197693bcc6bda.js | 7 + ...109bed474faec913166035b2ff3a0f62206618.css | 2 + ...afbdd11f6506fc3f5a9113a4d5b875fe8d4eadd.js | 13 + .../octocat-spinner-128.gif | Bin 0 -> 11721 bytes .../octocat-spinner-32.gif | Bin 0 -> 2310 bytes .../torbirdy – Tor Bug Tracker & Wiki.html | 432 + .../babel.js | 229 + .../en_US.js | 2 + .../folding.js | 82 + .../jquery.js | 9404 +++++ .../search.js | 88 + .../tor-logo.png | Bin 0 -> 11604 bytes .../tor.css | 576 + .../trac.css | 850 + .../trac.js | 133 + .../trac_logo_mini.png | Bin 0 -> 1687 bytes .../tractags.css | 45 + .../wiki.css | 133 + .../wysiwyg-load.js | 3 + .../wysiwyg.css | 140 + .../wysiwyg.js | 4012 ++ common.mk | 9 + 258 files changed, 168267 insertions(+) create mode 100644 .gitignore create mode 100644 Bachelorthesis/Appendix.tex create mode 100755 Bachelorthesis/Bachelorthesis.tex create mode 100755 Bachelorthesis/BachelorthesisLiterature.bib create mode 100755 Bachelorthesis/Content/Abstract.tex create mode 100644 Bachelorthesis/Content/AlternativeLoesungen.tex create mode 100644 Bachelorthesis/Content/AlternativeLoesungen/Bewertung.tex create mode 100644 Bachelorthesis/Content/AlternativeLoesungen/DarkMail.tex create mode 100644 Bachelorthesis/Content/Entwicklung.tex create mode 100644 Bachelorthesis/Content/Entwicklung/IdeaConcept.tex create mode 100644 Bachelorthesis/Content/Entwicklung/IdeaConcept/Algorithmus.dia create mode 100644 Bachelorthesis/Content/Entwicklung/IdeaConcept/Algorithmus.png create mode 100644 Bachelorthesis/Content/Entwicklung/IdeaConcept/Algorithmus.tex create mode 100644 Bachelorthesis/Content/Entwicklung/Methoden.tex create mode 100644 Bachelorthesis/Content/Entwicklung/Realisierung.tex create mode 100644 Bachelorthesis/Content/Entwicklung/Realisierung/Implementierung.tex create mode 100644 Bachelorthesis/Content/Entwicklung/Realisierung/Implementierung/Einsprungpunkt.tex create mode 100644 Bachelorthesis/Content/Entwicklung/Realisierung/Implementierung/Haraka.tex create mode 100644 Bachelorthesis/Content/Entwicklung/Realisierung/Implementierung/Konfiguration.tex create mode 100644 Bachelorthesis/Content/Entwicklung/Realisierung/Implementierung/MTA-Entscheider.tex create mode 100644 Bachelorthesis/Content/Entwicklung/Realisierung/Implementierung/SMTP-gateway.tex create mode 100644 Bachelorthesis/Content/Entwicklung/Realisierung/Implementierung/Wahl.tex create mode 100644 Bachelorthesis/Content/Entwicklung/Realisierung/Testsystem.tex create mode 100644 Bachelorthesis/Content/EvaluationValidation.tex create mode 100644 Bachelorthesis/Content/Intro.tex create mode 100644 Bachelorthesis/Content/Intro/Format.tex create mode 100644 Bachelorthesis/Content/Intro/Gesamtsystem.tex create mode 100644 Bachelorthesis/Content/Intro/Protokolle.tex create mode 100644 Bachelorthesis/Content/Intro/Protokolle/IMAP4.dia create mode 100644 Bachelorthesis/Content/Intro/Protokolle/IMAP4.png create mode 100644 Bachelorthesis/Content/Intro/Protokolle/IMAP4.tex create mode 100644 Bachelorthesis/Content/Intro/Protokolle/POP3.tex create mode 100644 Bachelorthesis/Content/Intro/Protokolle/SMTP-Model.dia create mode 100644 Bachelorthesis/Content/Intro/Protokolle/SMTP-Model.png create mode 100644 Bachelorthesis/Content/Intro/Protokolle/SMTP.tex create mode 100644 Bachelorthesis/Content/Intro/Protokolle/emailg.dia create mode 100644 Bachelorthesis/Content/Intro/Protokolle/emailg.png create mode 100644 Bachelorthesis/Content/ListOfAbbreviations/ListOfAbbreviations.tex create mode 100644 Bachelorthesis/Content/LookOut.tex create mode 100644 Bachelorthesis/Content/LookOut/PraktischeProbleme.tex create mode 100644 Bachelorthesis/Content/LookOut/PraktischeProbleme/DirectoryServer.tex create mode 100644 Bachelorthesis/Content/LookOut/PraktischeProbleme/Fehlerbehandlung.tex create mode 100644 Bachelorthesis/Content/LookOut/PraktischeProbleme/Gesamtsystem.tex create mode 100644 Bachelorthesis/Content/LookOut/PraktischeProbleme/Implementierung.tex create mode 100644 Bachelorthesis/Content/LookOut/PraktischeProbleme/Spam.tex create mode 100644 Bachelorthesis/Content/LookOut/PraktischeProbleme/Verify.tex create mode 100644 Bachelorthesis/Content/LookOut/PraktischeProbleme/Zuverlaessigkeit.tex create mode 100644 Bachelorthesis/Content/LookOut/TheoretischeProbleme.tex create mode 100644 Bachelorthesis/Content/LookOut/TheoretischeProbleme/KryptografieSystem.tex create mode 100644 Bachelorthesis/Content/LookOut/TheoretischeProbleme/PublicKey.tex create mode 100644 Bachelorthesis/Content/LookOut/TheoretischeProbleme/RoutingAlgo.tex create mode 100644 Bachelorthesis/Content/LookOut/TheoretischeProbleme/Spezifikation.tex create mode 100644 Bachelorthesis/Content/LookOut/TheoretischeProbleme/Verschluesselung.tex create mode 100644 Bachelorthesis/Content/Problematik.tex create mode 100644 Bachelorthesis/Content/Problematik/Anforderungen.tex create mode 100644 Bachelorthesis/Content/Problematik/BetrachtungDatenschutz.tex create mode 100644 Bachelorthesis/Content/Problematik/BetrachtungDatenschutz/Anonymitaet.tex create mode 100644 Bachelorthesis/Content/Problematik/BetrachtungDatenschutz/Anonymitaet/TorBirdy.tex create mode 100644 Bachelorthesis/Content/Problematik/BetrachtungDatenschutz/Bewertung.dia create mode 100644 Bachelorthesis/Content/Problematik/BetrachtungDatenschutz/Bewertung.png create mode 100644 Bachelorthesis/Content/Problematik/BetrachtungDatenschutz/Bewertung.tex create mode 100644 Bachelorthesis/Content/Problematik/BetrachtungDatenschutz/Verschluesselung.tex create mode 100644 Bachelorthesis/Content/Problematik/BetrachtungDatenschutz/Verschluesselung/GPG.tex create mode 100644 Bachelorthesis/Content/Problematik/BetrachtungDatenschutz/Verschluesselung/STARTTLS.tex create mode 100644 Bachelorthesis/Content/Problematik/BetrachtungDatenschutz/Verschluesselung/TLS.tex create mode 100644 Bachelorthesis/Content/Problematik/BetrachtungDatenschutz/Verschluesselung/asymcrypto.dia create mode 100644 Bachelorthesis/Content/Problematik/BetrachtungDatenschutz/Verschluesselung/asymcrypto.png create mode 100644 Bachelorthesis/Content/Settings.tex create mode 100755 Bachelorthesis/Content/StatutoryDeclaration/StatutoryDeclaration.tex create mode 100755 Bachelorthesis/Content/TitlePage.tex create mode 100644 Bachelorthesis/Content/TitlePage/fhbi_logo_kompakt_orange.jpg create mode 100644 Bachelorthesis/LICENSE create mode 100644 Bachelorthesis/Makefile create mode 100644 COPYRIGHT create mode 100644 Implementierung/Handbuch.md create mode 100644 Implementierung/LICENSE create mode 100644 Implementierung/Makefile create mode 100644 Implementierung/alpine-haraka-gateway/Dockerfile create mode 100644 Implementierung/alpine-haraka-gateway/README.md create mode 100644 Implementierung/alpine-haraka-gateway/config/plugins create mode 100644 Implementierung/alpine-haraka-gateway/docker-entrypoint.sh create mode 100644 Implementierung/alpine-haraka-gateway/plugins/.tern-project create mode 100644 Implementierung/alpine-haraka-gateway/plugins/create_myst_mail.js create mode 100644 Implementierung/alpine-haraka-gateway/plugins/enable_parse_body.js create mode 100644 Implementierung/alpine-haraka-gateway/plugins/my_mx.js create mode 100644 Implementierung/alpine-haraka-gateway/plugins/open_relay.js create mode 100644 Implementierung/alpine-haraka/Dockerfile create mode 100644 Implementierung/alpine-haraka/README.md create mode 100644 Implementierung/alpine-haraka/config/plugins create mode 100644 Implementierung/alpine-haraka/docker-entrypoint.sh create mode 100644 Implementierung/alpine-haraka/plugins/.tern-project create mode 100644 Implementierung/alpine-haraka/plugins/add_myst_header.js create mode 100644 Implementierung/alpine-haraka/plugins/data_post_write_mail.js create mode 100644 Implementierung/alpine-haraka/plugins/enable_parse_body.js create mode 100644 Implementierung/alpine-haraka/plugins/my_mx.js create mode 100644 Implementierung/alpine-haraka/plugins/my_transaction.js create mode 100644 Implementierung/alpine-haraka/plugins/myst_send.js create mode 100644 Implementierung/alpine-haraka/plugins/open_relay.js create mode 100644 Implementierung/alpine-haraka/plugins/test_queue.js create mode 100644 Implementierung/alpine-swaks/Dockerfile create mode 100644 Implementierung/alpine-swaks/README.md create mode 100644 Makefile create mode 100644 README.md create mode 100644 RFCs/rfc1521.txt create mode 100644 RFCs/rfc1522.txt create mode 100644 RFCs/rfc1730.txt create mode 100644 RFCs/rfc1939.txt create mode 100644 RFCs/rfc196.txt create mode 100644 RFCs/rfc2045.txt create mode 100644 RFCs/rfc2046.txt create mode 100644 RFCs/rfc2047.txt create mode 100644 RFCs/rfc2049.txt create mode 100644 RFCs/rfc2183.txt create mode 100644 RFCs/rfc2487.txt create mode 100644 RFCs/rfc2595.txt create mode 100644 RFCs/rfc2821.txt create mode 100644 RFCs/rfc2822.txt create mode 100644 RFCs/rfc3207.txt create mode 100644 RFCs/rfc3501.txt create mode 100644 RFCs/rfc4035.txt create mode 100644 RFCs/rfc4288.txt create mode 100644 RFCs/rfc4289.txt create mode 100644 RFCs/rfc4880.txt create mode 100644 RFCs/rfc5246.txt create mode 100644 RFCs/rfc5321.txt create mode 100644 RFCs/rfc5322.txt create mode 100644 RFCs/rfc6376.txt create mode 100644 RFCs/rfc6409.txt create mode 100644 RFCs/rfc7457.txt create mode 100644 RFCs/rfc821.txt create mode 100644 RFCs/rfc822.txt create mode 100644 RFCs/rfc974.txt create mode 100644 Webseiten/Docker - Build, Ship, and Run Any App, Anywhere.html create mode 100644 Webseiten/Docker - Build, Ship, and Run Any App, Anywhere_files/Logo-Docker.svg create mode 100644 Webseiten/Docker - Build, Ship, and Run Any App, Anywhere_files/Swarmnado-357x627-15.gif create mode 100644 Webseiten/Docker - Build, Ship, and Run Any App, Anywhere_files/XDFrame.html create mode 100644 Webseiten/Docker - Build, Ship, and Run Any App, Anywhere_files/affix.js create mode 100644 Webseiten/Docker - Build, Ship, and Run Any App, Anywhere_files/agility_0.png create mode 100644 Webseiten/Docker - Build, Ship, and Run Any App, Anywhere_files/animate.min.css create mode 100644 Webseiten/Docker - Build, Ship, and Run Any App, Anywhere_files/app.css create mode 100644 Webseiten/Docker - Build, Ship, and Run Any App, Anywhere_files/app.js create mode 100644 Webseiten/Docker - Build, Ship, and Run Any App, Anywhere_files/app1.css create mode 100644 Webseiten/Docker - Build, Ship, and Run Any App, Anywhere_files/big_data_blue_icon.svg create mode 100644 Webseiten/Docker - Build, Ship, and Run Any App, Anywhere_files/bootstrap.min.css create mode 100644 Webseiten/Docker - Build, Ship, and Run Any App, Anywhere_files/build.png create mode 100644 Webseiten/Docker - Build, Ship, and Run Any App, Anywhere_files/control_0.png create mode 100644 Webseiten/Docker - Build, Ship, and Run Any App, Anywhere_files/cubeportfolio.min.css create mode 100644 Webseiten/Docker - Build, Ship, and Run Any App, Anywhere_files/devops_blue_icon.svg create mode 100644 Webseiten/Docker - Build, Ship, and Run Any App, Anywhere_files/docker.js create mode 100644 Webseiten/Docker - Build, Ship, and Run Any App, Anywhere_files/docker_datacenter_banner_image_1.png create mode 100644 Webseiten/Docker - Build, Ship, and Run Any App, Anywhere_files/docker_diagram51.svg create mode 100644 Webseiten/Docker - Build, Ship, and Run Any App, Anywhere_files/fa-reddit-alien.png create mode 100644 Webseiten/Docker - Build, Ship, and Run Any App, Anywhere_files/flexslider.css create mode 100644 Webseiten/Docker - Build, Ship, and Run Any App, Anywhere_files/font-awesome.min.css create mode 100644 Webseiten/Docker - Build, Ship, and Run Any App, Anywhere_files/forms2-theme-simple.css create mode 100644 Webseiten/Docker - Build, Ship, and Run Any App, Anywhere_files/forms2.css create mode 100644 Webseiten/Docker - Build, Ship, and Run Any App, Anywhere_files/forms2.min.js create mode 100644 Webseiten/Docker - Build, Ship, and Run Any App, Anywhere_files/foundation.js create mode 100644 Webseiten/Docker - Build, Ship, and Run Any App, Anywhere_files/infrastructure_blue_icon.svg create mode 100644 Webseiten/Docker - Build, Ship, and Run Any App, Anywhere_files/integration_blue_icon.svg create mode 100644 Webseiten/Docker - Build, Ship, and Run Any App, Anywhere_files/isotope.pkgd.min.js create mode 100644 Webseiten/Docker - Build, Ship, and Run Any App, Anywhere_files/jquery-migrate-1.2.1.min.js create mode 100644 Webseiten/Docker - Build, Ship, and Run Any App, Anywhere_files/jquery-ui-slider-pips.css create mode 100644 Webseiten/Docker - Build, Ship, and Run Any App, Anywhere_files/jquery-ui-slider-pips.min.js create mode 100644 Webseiten/Docker - Build, Ship, and Run Any App, Anywhere_files/jquery-ui.min.css create mode 100644 Webseiten/Docker - Build, Ship, and Run Any App, Anywhere_files/jquery-ui.min.js create mode 100644 Webseiten/Docker - Build, Ship, and Run Any App, Anywhere_files/jquery.ba-bbq.js create mode 100644 Webseiten/Docker - Build, Ship, and Run Any App, Anywhere_files/jquery.cubeportfolio.min.js create mode 100644 Webseiten/Docker - Build, Ship, and Run Any App, Anywhere_files/jquery.flexslider.js create mode 100644 Webseiten/Docker - Build, Ship, and Run Any App, Anywhere_files/jquery.magnific-popup.min.js create mode 100644 Webseiten/Docker - Build, Ship, and Run Any App, Anywhere_files/jquery.matchHeight.min.js create mode 100644 Webseiten/Docker - Build, Ship, and Run Any App, Anywhere_files/jquery.smooth-scroll.min.js create mode 100644 Webseiten/Docker - Build, Ship, and Run Any App, Anywhere_files/jquery.ui.touch-punch.min.js create mode 100644 Webseiten/Docker - Build, Ship, and Run Any App, Anywhere_files/magnific-popup.css create mode 100644 Webseiten/Docker - Build, Ship, and Run Any App, Anywhere_files/modernizr.min.js create mode 100644 Webseiten/Docker - Build, Ship, and Run Any App, Anywhere_files/portability_0.png create mode 100644 Webseiten/Docker - Build, Ship, and Run Any App, Anywhere_files/run.png create mode 100644 Webseiten/Docker - Build, Ship, and Run Any App, Anywhere_files/scrollspy.min.js create mode 100644 Webseiten/Docker - Build, Ship, and Run Any App, Anywhere_files/ship.png create mode 100644 Webseiten/Docker - Build, Ship, and Run Any App, Anywhere_files/track.js create mode 100644 Webseiten/Docker - Build, Ship, and Run Any App, Anywhere_files/vendor.js create mode 100644 Webseiten/Docker - Build, Ship, and Run Any App, Anywhere_files/wow.js create mode 100644 Webseiten/Haraka SMTP Email Server.html create mode 100644 Webseiten/Haraka SMTP Email Server_files/application.js create mode 100644 Webseiten/Haraka SMTP Email Server_files/bootstrap.css create mode 100644 Webseiten/Haraka SMTP Email Server_files/bootstrap.js create mode 100644 Webseiten/Haraka SMTP Email Server_files/btn_donate_LG.gif create mode 100644 Webseiten/Haraka SMTP Email Server_files/docs.css create mode 100644 Webseiten/Haraka SMTP Email Server_files/holder.js create mode 100644 Webseiten/Haraka SMTP Email Server_files/jquery.js create mode 100644 Webseiten/Haraka SMTP Email Server_files/pygments-manni.css create mode 100644 Webseiten/NEW DRAFT_ Regularizing Port Numbers for SSL. from Christopher Allen on 1997-02-07 (ietf-tls@w3.org from January to March 1997).html create mode 100644 Webseiten/NEW DRAFT_ Regularizing Port Numbers for SSL. from Christopher Allen on 1997-02-07 (ietf-tls@w3.org from January to March 1997)_files/public-message create mode 100644 Webseiten/Open Source - Sendmail.com.html create mode 100644 Webseiten/Open Source - Sendmail.com_files/brand create mode 100644 Webseiten/Open Source - Sendmail.com_files/btn_search_trans.png create mode 100644 Webseiten/Open Source - Sendmail.com_files/head.css create mode 100644 Webseiten/Open Source - Sendmail.com_files/letter-bt.jpg create mode 100644 Webseiten/Open Source - Sendmail.com_files/main.css create mode 100644 Webseiten/Open Source - Sendmail.com_files/munchkin.js create mode 100644 Webseiten/Open Source - Sendmail.com_files/open_source.css create mode 100644 Webseiten/Open Source - Sendmail.com_files/proofpoint-sendmail-logo_240.png create mode 100644 Webseiten/Open Source - Sendmail.com_files/slide_layer.js create mode 100644 Webseiten/Open Source - Sendmail.com_files/swfobject.js create mode 100644 Webseiten/OpenBSD 5.3.html create mode 100644 Webseiten/OpenBSD 5.3_files/RoyPuffy.jpg create mode 100644 Webseiten/OpenBSD 5.3_files/smalltitle.gif create mode 100644 Webseiten/OpenSMTPD.html create mode 100644 Webseiten/OpenSMTPD_files/opensmtpd.png create mode 100644 Webseiten/The GNU Privacy Guard.html create mode 100644 Webseiten/The GNU Privacy Guard_files/cc-by-sa-3.0_80x15.png create mode 100644 Webseiten/The GNU Privacy Guard_files/logo-gnupg-light-purple-bg.png create mode 100644 Webseiten/The GNU Privacy Guard_files/site.css create mode 100644 Webseiten/The GNU Privacy Guard_files/traueranzeige-g10_v2015.png create mode 100644 Webseiten/Thunderbird — Software made to make email easier. — Mozilla.html create mode 100644 Webseiten/Thunderbird — Software made to make email easier. — Mozilla_files/common-bundle.f0a21783cc6e.js create mode 100644 Webseiten/Thunderbird — Software made to make email easier. — Mozilla_files/logo.e19c8e6706dd.png create mode 100644 Webseiten/Thunderbird — Software made to make email easier. — Mozilla_files/responsive-bundle.2b0724257ae0.css create mode 100644 Webseiten/Thunderbird — Software made to make email easier. — Mozilla_files/screenshot-linux.7af76cb37bda.png create mode 100644 Webseiten/Thunderbird — Software made to make email easier. — Mozilla_files/site-bundle.6009f70fa7b1.js create mode 100644 Webseiten/Thunderbird — Software made to make email easier. — Mozilla_files/thunderbird-landing-bundle.b9555ff2948e.css create mode 100644 Webseiten/Thunderbird — Software made to make email easier. — Mozilla_files/wordmark.3b0e03fa56f1.png create mode 100644 Webseiten/Tor Browser.html create mode 100644 Webseiten/Tor Browser_files/InternetDefenseLeague-footer-badge.png create mode 100644 Webseiten/Tor Browser_files/master.css create mode 100644 Webseiten/Tor Browser_files/onion.jpg create mode 100644 Webseiten/Tor Browser_files/screenshot-osx-torbrowser-icon.png create mode 100644 Webseiten/Tor Browser_files/tbb-close-button.png create mode 100644 Webseiten/Tor Browser_files/tbb-screenshot1.jpg create mode 100644 Webseiten/Tor Browser_files/tbb-screenshot2.jpg create mode 100644 Webseiten/Tor Browser_files/tbb-screenshot3.jpg create mode 100644 Webseiten/Tor Browser_files/tbbproject.css create mode 100644 Webseiten/lavabit_libdime_ The DIME resolver library and command line utilities..html create mode 100644 Webseiten/lavabit_libdime_ The DIME resolver library and command line utilities._files/1241845 create mode 100644 Webseiten/lavabit_libdime_ The DIME resolver library and command line utilities._files/77851 create mode 100644 Webseiten/lavabit_libdime_ The DIME resolver library and command line utilities._files/frameworks-2d635ad8ba43f32e07aa1fd713d692eff9a2e78dcd63daa5b580c38b36df3fdb.css create mode 100644 Webseiten/lavabit_libdime_ The DIME resolver library and command line utilities._files/frameworks-e677f2022a5d36e8f5ad35d0fcb01f83f1cdb613eda0449f533197693bcc6bda.js create mode 100644 Webseiten/lavabit_libdime_ The DIME resolver library and command line utilities._files/github-ac57e85eb92ed03f8984683a81109bed474faec913166035b2ff3a0f62206618.css create mode 100644 Webseiten/lavabit_libdime_ The DIME resolver library and command line utilities._files/github-b18da7a1736acf63af955a0d6afbdd11f6506fc3f5a9113a4d5b875fe8d4eadd.js create mode 100644 Webseiten/lavabit_libdime_ The DIME resolver library and command line utilities._files/octocat-spinner-128.gif create mode 100644 Webseiten/lavabit_libdime_ The DIME resolver library and command line utilities._files/octocat-spinner-32.gif create mode 100644 Webseiten/torbirdy – Tor Bug Tracker & Wiki.html create mode 100644 Webseiten/torbirdy – Tor Bug Tracker & Wiki_files/babel.js create mode 100644 Webseiten/torbirdy – Tor Bug Tracker & Wiki_files/en_US.js create mode 100644 Webseiten/torbirdy – Tor Bug Tracker & Wiki_files/folding.js create mode 100644 Webseiten/torbirdy – Tor Bug Tracker & Wiki_files/jquery.js create mode 100644 Webseiten/torbirdy – Tor Bug Tracker & Wiki_files/search.js create mode 100644 Webseiten/torbirdy – Tor Bug Tracker & Wiki_files/tor-logo.png create mode 100644 Webseiten/torbirdy – Tor Bug Tracker & Wiki_files/tor.css create mode 100644 Webseiten/torbirdy – Tor Bug Tracker & Wiki_files/trac.css create mode 100644 Webseiten/torbirdy – Tor Bug Tracker & Wiki_files/trac.js create mode 100644 Webseiten/torbirdy – Tor Bug Tracker & Wiki_files/trac_logo_mini.png create mode 100644 Webseiten/torbirdy – Tor Bug Tracker & Wiki_files/tractags.css create mode 100644 Webseiten/torbirdy – Tor Bug Tracker & Wiki_files/wiki.css create mode 100644 Webseiten/torbirdy – Tor Bug Tracker & Wiki_files/wysiwyg-load.js create mode 100644 Webseiten/torbirdy – Tor Bug Tracker & Wiki_files/wysiwyg.css create mode 100644 Webseiten/torbirdy – Tor Bug Tracker & Wiki_files/wysiwyg.js create mode 100644 common.mk diff --git a/.gitignore b/.gitignore new file mode 100644 index 0000000..f11ade4 --- /dev/null +++ b/.gitignore @@ -0,0 +1,29 @@ +_minted-* +*.aux +*.log +*.out +*.pdf +*.gz +*.toc +*.nav +*.snm +*.vrb +*.mintedcmd +*.mintedmd5 +*.dvi +*.cdb +*.cdm +*.pdb +*.pdm +*.bak +*.directory +*.bbl +*.blg +*.lof +*.lot +*.swp +*.lol +*.idx +*.ilg +*.ind +*~ diff --git a/Bachelorthesis/Appendix.tex b/Bachelorthesis/Appendix.tex new file mode 100644 index 0000000..c043112 --- /dev/null +++ b/Bachelorthesis/Appendix.tex @@ -0,0 +1,44 @@ +\begin{appendix} + +\chapter{Beiliegende Datenträger} +Dieser Arbeit liegt eine CD bei. Nachfolgend wird der Inhalt aufgelistet und beschrieben. + +\section{Inhaltsliste} + +\begin{itemize} + \setlength\itemsep{\Itemizespace} + \item CD 1 + \begin{itemize} + \setlength\itemsep{\Itemizespace} + \item Thesis + \begin{itemize} + \setlength\itemsep{\Itemizespace} + \item Binary + \item Source + \end{itemize} + \item Webseiten + \item RFCs in Textform + \item Implementierung + \begin{itemize} + \setlength\itemsep{\Itemizespace} + \item Dockerfiles + \item Source + \item Konfigurationsdateien + \end{itemize} + \item Dokumentation + \begin{itemize} + \item Handbuch + \end{itemize} + \end{itemize} +\end{itemize} + +\clearpage +\section{Inhaltsbeschreibung} +Die Implementierung befindet sich im Unterordner \verb#Implementierung# und beinhaltet dort auch den Quellcode für die Docker Images \verb#alpine-haraka#, \verb#alpine-haraka-gateway# und \verb#alpine-swaks#. Die Haraka Plugins sind also jeweils in den Ordnern \\ \verb#Implementierung/alpine-haraka/plugins# und \\ \verb#Implementierung/alpine-haraka-gateway/plugins#. + +Der Latex Quellcode befindet sich im Unterordner \verb#LaTeX# und ein Symlink zur PDF existiert im Root-Ordner als \verb#Bachelorthesis.pdf#. + +Alle RFCs sind in Textform im Unterordner \verb#RFCs# aufzufinden. Ebenso sind alle referenzierten Webseiten statisch im Unterordner \verb#Webseiten# verfügbar. + +\end{appendix} + diff --git a/Bachelorthesis/Bachelorthesis.tex b/Bachelorthesis/Bachelorthesis.tex new file mode 100755 index 0000000..49854fd --- /dev/null +++ b/Bachelorthesis/Bachelorthesis.tex @@ -0,0 +1,161 @@ +\documentclass[ %draft, % To display over/unterfull hboxes + a4paper, % use DIN A4 Paper + onecolumn, % Only one Column of text + oneside, % Pint only right sides + titlepage, % Print a titlepage + openany, % Open new chapter on any page + 12pt] % Text size + {report} + +\include{Content/Settings} + +\begin{document} + + + +\thispagestyle{empty} +\input{Content/TitlePage} +\input{Content/Abstract} + + +\setcounter{page}{3} +\tableofcontents + +\chapter{Einleitung} + \input{Content/Intro} + \section{E-Mail Format (IMF)} + \input{Content/Intro/Format} + \section{E-Mail Protokolle} + \input{Content/Intro/Protokolle} + \subsection{SMTP} + \input{Content/Intro/Protokolle/SMTP} + \subsection{POP3} + \input{Content/Intro/Protokolle/POP3} + \subsection{IMAP4} + \input{Content/Intro/Protokolle/IMAP4} + \section{E-Mail als Gesamtsystem} + \input{Content/Intro/Gesamtsystem} + +\chapter{Motivation und Problematik} + \input{Content/Problematik} + \section{Betrachtung von Datenschutz in aktuellen E-Mail Systemen} + \input{Content/Problematik/BetrachtungDatenschutz} + \subsection{Verschlüsselung von E-Mail-Verkehr} + \input{Content/Problematik/BetrachtungDatenschutz/Verschluesselung} + \subsubsection{GPG} + \input{Content/Problematik/BetrachtungDatenschutz/Verschluesselung/GPG} + \subsubsection{TLS} + \input{Content/Problematik/BetrachtungDatenschutz/Verschluesselung/TLS} + \subsubsection{STARTTLS} + \input{Content/Problematik/BetrachtungDatenschutz/Verschluesselung/STARTTLS} + \subsection{Anonymität von E-Mail-Verkehr} + \input{Content/Problematik/BetrachtungDatenschutz/Anonymitaet} + \subsubsection{TorBirdy} + \input{Content/Problematik/BetrachtungDatenschutz/Anonymitaet/TorBirdy} + \subsection{Bewertung} + \input{Content/Problematik/BetrachtungDatenschutz/Bewertung} + \section{Anforderungen an eine adäquate Lösung} + \input{Content/Problematik/Anforderungen} + +\chapter{Alternative Lösungen bzw. E-Mail Systeme} + \input{Content/AlternativeLoesungen} + \section{Dark Mail} + \input{Content/AlternativeLoesungen/DarkMail} + \section{Bewertung} + \input{Content/AlternativeLoesungen/Bewertung} + +\chapter{Entwicklung eines SMTP-basierten Anonymisierungs-Algorithmus} + \input{Content/Entwicklung} + \section{Idee \& Konzept} + \input{Content/Entwicklung/IdeaConcept} + \subsection{Algorithmus} + \input{Content/Entwicklung/IdeaConcept/Algorithmus} + \section{Methoden} + \input{Content/Entwicklung/Methoden} + \section{Realisierung} + \input{Content/Entwicklung/Realisierung} + \subsection{Testsystem} + \input{Content/Entwicklung/Realisierung/Testsystem} + \subsection{Implementierung} + \input{Content/Entwicklung/Realisierung/Implementierung} + \subsubsection{Wahl der SMTP-Software} + \input{Content/Entwicklung/Realisierung/Implementierung/Wahl} + \subsubsection{Übersicht über Haraka} + \input{Content/Entwicklung/Realisierung/Implementierung/Haraka} + \subsubsection{Wahl des Einsprungpunktes} + \input{Content/Entwicklung/Realisierung/Implementierung/Einsprungpunkt} + + \subsubsection{Implementierung MTA-Entscheider} + \input{Content/Entwicklung/Realisierung/Implementierung/MTA-Entscheider} + \subsubsection{SMTP-Gateway und MystMail Erstellung} + \input{Content/Entwicklung/Realisierung/Implementierung/SMTP-gateway} + \subsubsection{Haraka Konfiguration} + \input{Content/Entwicklung/Realisierung/Implementierung/Konfiguration} + +\chapter{Evaluation \& Validation} + \input{Content/EvaluationValidation} + +\chapter{Ausblick} + \input{Content/LookOut} + \section{Theoretische Probleme} + \input{Content/LookOut/TheoretischeProbleme} + \subsubsection{Verschlüsselungsalgorithmus} + \input{Content/LookOut/TheoretischeProbleme/Verschluesselung} + \subsubsection{Public-Key System} + \input{Content/LookOut/TheoretischeProbleme/PublicKey} + \subsubsection{Routing-Algorithmus} + \input{Content/LookOut/TheoretischeProbleme/RoutingAlgo} \subsubsection{Kryptografie-System insgesamt} + \input{Content/LookOut/TheoretischeProbleme/KryptografieSystem} + \subsubsection{Fehlen einer Spezifikation} + \input{Content/LookOut/TheoretischeProbleme/Spezifikation} + + \section{Praktische Probleme} + \input{Content/LookOut/PraktischeProbleme} + \subsubsection{Professionelle Implementierung} + \input{Content/LookOut/PraktischeProbleme/Implementierung} + \subsubsection{Fehlerbehandlung} + \input{Content/LookOut/PraktischeProbleme/Fehlerbehandlung} + \subsubsection{Verifizierung und Authentizität} + \input{Content/LookOut/PraktischeProbleme/Verify} + \subsubsection{Spam-Abwehr und Traffic} + \input{Content/LookOut/PraktischeProbleme/Spam} + \subsubsection{Directory Server} + \input{Content/LookOut/PraktischeProbleme/DirectoryServer} + \subsubsection{Zuverlässigkeit} + \input{Content/LookOut/PraktischeProbleme/Zuverlaessigkeit} + \subsubsection{Gesamtsystem} + \input{Content/LookOut/PraktischeProbleme/Gesamtsystem} + + +% appendix +\input{Appendix} + +\cleardoublepage +\phantomsection +\addcontentsline{toc}{chapter}{\listfigurename} +\listoffigures + +\cleardoublepage +\phantomsection +\addcontentsline{toc}{chapter}{\listtablename} +\listoftables + +\cleardoublepage +\phantomsection +\addcontentsline{toc}{chapter}{\lstlistlistingname} +\lstlistoflistings + +\cleardoublepage +\phantomsection +\markboth{\uppercase{\ListOfAbbreviations}}{} +\chapter*{\ListOfAbbreviations} +\addcontentsline{toc}{chapter}{\ListOfAbbreviations} +\input{Content/ListOfAbbreviations/ListOfAbbreviations} + +\cleardoublepage +\phantomsection +\addcontentsline{toc}{chapter}{\bibname} +\bibliography{BachelorthesisLiterature} + + +\end{document} diff --git a/Bachelorthesis/BachelorthesisLiterature.bib b/Bachelorthesis/BachelorthesisLiterature.bib new file mode 100755 index 0000000..92c4bbe --- /dev/null +++ b/Bachelorthesis/BachelorthesisLiterature.bib @@ -0,0 +1,719 @@ + +@misc{rfc196, + author="R.W. Watson", + title="{Mail Box Protocol}", + series="Request for Comments", + number="196", + howpublished="RFC 196", + publisher="IETF", + organization="Internet Engineering Task Force", + year=1971, + month=jul, + note="Obsoleted by RFC 221", + url="http://www.ietf.org/rfc/rfc196.txt", +} + +@misc{rfc2045, + author="N. Freed and N. Borenstein", + title="{Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies}", + series="Request for Comments", + number="2045", + howpublished="RFC 2045 (Draft Standard)", + publisher="IETF", + organization="Internet Engineering Task Force", + year=1996, + month=nov, + note="Updated by RFCs 2184, 2231, 5335, 6532", + url="http://www.ietf.org/rfc/rfc2045.txt", +} + +@misc{rfc2046, + author="N. Freed and N. Borenstein", + title="{Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types}", + series="Request for Comments", + number="2046", + howpublished="RFC 2046 (Draft Standard)", + publisher="IETF", + organization="Internet Engineering Task Force", + year=1996, + month=nov, + note="Updated by RFCs 2646, 3798, 5147, 6657", + url="http://www.ietf.org/rfc/rfc2046.txt", +} + +@misc{rfc2047, + author="K. Moore", + title="{MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text}", + series="Request for Comments", + number="2047", + howpublished="RFC 2047 (Draft Standard)", + publisher="IETF", + organization="Internet Engineering Task Force", + year=1996, + month=nov, + note="Updated by RFCs 2184, 2231", + url="http://www.ietf.org/rfc/rfc2047.txt", +} + +@misc{rfc2049, + author="N. Freed and N. Borenstein", + title="{Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples}", + series="Request for Comments", + number="2049", + howpublished="RFC 2049 (Draft Standard)", + publisher="IETF", + organization="Internet Engineering Task Force", + year=1996, + month=nov, + url="http://www.ietf.org/rfc/rfc2049.txt", +} + +@misc{rfc4288, + author="N. Freed and J. Klensin", + title="{Media Type Specifications and Registration Procedures}", + series="Request for Comments", + number="4288", + howpublished="RFC 4288 (Best Current Practice)", + publisher="IETF", + organization="Internet Engineering Task Force", + year=2005, + month=dec, + note="Obsoleted by RFC 6838", + url="http://www.ietf.org/rfc/rfc4288.txt", +} + +@misc{rfc4289, + author="N. Freed and J. Klensin", + title="{Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures}", + series="Request for Comments", + number="4289", + howpublished="RFC 4289 (Best Current Practice)", + publisher="IETF", + organization="Internet Engineering Task Force", + year=2005, + month=dec, + url="http://www.ietf.org/rfc/rfc4289.txt", +} + +@misc{rfc1521, + author="N. Borenstein and N. Freed", + title="{MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies}", + series="Request for Comments", + number="1521", + howpublished="RFC 1521 (Draft Standard)", + publisher="IETF", + organization="Internet Engineering Task Force", + year=1993, + month=sep, + note="Obsoleted by RFCs 2045, 2046, 2047, 2048, 2049, updated by RFC 1590", + url="http://www.ietf.org/rfc/rfc1521.txt", +} + +@misc{rfc1522, + author="K. Moore", + title="{MIME (Multipurpose Internet Mail Extensions) Part Two: Message Header Extensions for Non-ASCII Text}", + series="Request for Comments", + number="1522", + howpublished="RFC 1522 (Draft Standard)", + publisher="IETF", + organization="Internet Engineering Task Force", + year=1993, + month=sep, + note="Obsoleted by RFCs 2045, 2046, 2047, 2048, 2049", + url="http://www.ietf.org/rfc/rfc1522.txt", +} + +@misc{rfc2183, + author="R. Troost and S. Dorner and K. Moore", + title="{Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field}", + series="Request for Comments", + number="2183", + howpublished="RFC 2183 (Proposed Standard)", + publisher="IETF", + organization="Internet Engineering Task Force", + year=1997, + month=aug, + note="Updated by RFCs 2184, 2231", + url="http://www.ietf.org/rfc/rfc2183.txt", +} + +@misc{rfc5322, + author="P. Resnick", + title="{Internet Message Format}", + series="Request for Comments", + number="5322", + howpublished="RFC 5322 (Draft Standard)", + publisher="IETF", + organization="Internet Engineering Task Force", + year=2008, + month=oct, + note="Updated by RFC 6854", + url="http://www.ietf.org/rfc/rfc5322.txt", +} + +@misc{rfc2822, + author="P. Resnick", + title="{Internet Message Format}", + series="Request for Comments", + number="2822", + howpublished="RFC 2822 (Proposed Standard)", + publisher="IETF", + organization="Internet Engineering Task Force", + year=2001, + month=apr, + note="Obsoleted by RFC 5322, updated by RFCs 5335, 5336", + url="http://www.ietf.org/rfc/rfc2822.txt", +} + +@misc{rfc5321, + author="J. Klensin", + title="{Simple Mail Transfer Protocol}", + series="Request for Comments", + number="5321", + howpublished="RFC 5321 (Draft Standard)", + publisher="IETF", + organization="Internet Engineering Task Force", + year=2008, + month=oct, + note="Updated by RFC 7504", + url="http://www.ietf.org/rfc/rfc5321.txt", +} + +@misc{rfc6376, + author="D. Crocker and T. Hansen and M. Kucherawy", + title="{DomainKeys Identified Mail (DKIM) Signatures}", + series="Request for Comments", + number="6376", + howpublished="RFC 6376 (INTERNET STANDARD)", + publisher="IETF", + organization="Internet Engineering Task Force", + year=2011, + month=sep, + url="http://www.ietf.org/rfc/rfc6376.txt", +} + +@misc{rfc4035, + author="R. Arends and R. Austein and M. Larson and D. Massey and S. Rose", + title="{Protocol Modifications for the DNS Security Extensions}", + series="Request for Comments", + number="4035", + howpublished="RFC 4035 (Proposed Standard)", + publisher="IETF", + organization="Internet Engineering Task Force", + year=2005, + month=mar, + note="Updated by RFCs 4470, 6014, 6840", + url="http://www.ietf.org/rfc/rfc4035.txt", +} + +@misc{rfc1939, + author="J. Myers and M. Rose", + title="{Post Office Protocol - Version 3}", + series="Request for Comments", + number="1939", + howpublished="RFC 1939 (INTERNET STANDARD)", + publisher="IETF", + organization="Internet Engineering Task Force", + year=1996, + month=may, + note="Updated by RFCs 1957, 2449, 6186", + url="http://www.ietf.org/rfc/rfc1939.txt", +} + +@misc{rfc3501, + author="M. Crispin", + title="{INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1}", + series="Request for Comments", + number="3501", + howpublished="RFC 3501 (Proposed Standard)", + publisher="IETF", + organization="Internet Engineering Task Force", + year=2003, + month=mar, + note="Updated by RFCs 4466, 4469, 4551, 5032, 5182, 5738, 6186, 6858", + url="http://www.ietf.org/rfc/rfc3501.txt", +} + +@misc{rfc822, + author="D. Crocker", + title="{STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT MESSAGES}", + series="Request for Comments", + number="822", + howpublished="RFC 822 (INTERNET STANDARD)", + publisher="IETF", + organization="Internet Engineering Task Force", + year=1982, + month=aug, + note="Obsoleted by RFC 2822, updated by RFCs 1123, 2156, 1327, 1138, 1148", + url="http://www.ietf.org/rfc/rfc822.txt", +} + +@misc{rfc821, + author="J. Postel", + title="{Simple Mail Transfer Protocol}", + series="Request for Comments", + number="821", + howpublished="RFC 821 (INTERNET STANDARD)", + publisher="IETF", + organization="Internet Engineering Task Force", + year=1982, + month=aug, + note="Obsoleted by RFC 2821", + url="http://www.ietf.org/rfc/rfc821.txt", +} + +@misc{rfc2821, + author="J. Klensin", + title="{Simple Mail Transfer Protocol}", + series="Request for Comments", + number="2821", + howpublished="RFC 2821 (Proposed Standard)", + publisher="IETF", + organization="Internet Engineering Task Force", + year=2001, + month=apr, + note="Obsoleted by RFC 5321, updated by RFC 5336", + url="http://www.ietf.org/rfc/rfc2821.txt", +} + +@misc{rfc6409, + author="R. Gellens and J. Klensin", + title="{Message Submission for Mail}", + series="Request for Comments", + number="6409", + howpublished="RFC 6409 (INTERNET STANDARD)", + publisher="IETF", + organization="Internet Engineering Task Force", + year=2011, + month=nov, + url="http://www.ietf.org/rfc/rfc6409.txt", +} + +@misc{rfc2487, + author="P. Hoffman", + title="{SMTP Service Extension for Secure SMTP over TLS}", + series="Request for Comments", + number="2487", + howpublished="RFC 2487 (Proposed Standard)", + publisher="IETF", + organization="Internet Engineering Task Force", + year=1999, + month=jan, + note="Obsoleted by RFC 3207", + url="http://www.ietf.org/rfc/rfc2487.txt", +} + +@misc{rfc1730, + author="M. Crispin", + title="{Internet Message Access Protocol - Version 4}", + series="Request for Comments", + number="1730", + howpublished="RFC 1730 (Proposed Standard)", + publisher="IETF", + organization="Internet Engineering Task Force", + year=1994, + month=dec, + note="Obsoleted by RFCs 2060, 2061", + url="http://www.ietf.org/rfc/rfc1730.txt", +} + +@misc{rfc2595, + author="C. Newman", + title="{Using TLS with IMAP, POP3 and ACAP}", + series="Request for Comments", + number="2595", + howpublished="RFC 2595 (Proposed Standard)", + publisher="IETF", + organization="Internet Engineering Task Force", + year=1999, + month=jun, + note="Updated by RFC 4616", + url="http://www.ietf.org/rfc/rfc2595.txt", +} + +@misc{rfc974, + author="C. Partridge", + title="{Mail routing and the domain system}", + series="Request for Comments", + number="974", + howpublished="RFC 974 (Historic)", + publisher="IETF", + organization="Internet Engineering Task Force", + year=1986, + month=jan, + note="Obsoleted by RFC 2821", + url="http://www.ietf.org/rfc/rfc974.txt", +} + +@misc{rfc4880, + author="J. Callas and L. Donnerhacke and H. Finney and D. Shaw and R. Thayer", + title="{OpenPGP Message Format}", + series="Request for Comments", + number="4880", + howpublished="RFC 4880 (Proposed Standard)", + publisher="IETF", + organization="Internet Engineering Task Force", + year=2007, + month=nov, + note="Updated by RFC 5581", + url="http://www.ietf.org/rfc/rfc4880.txt", +} + +@misc{rfc5246, + author="T. Dierks and E. Rescorla", + title="{The Transport Layer Security (TLS) Protocol Version 1.2}", + series="Request for Comments", + number="5246", + howpublished="RFC 5246 (Proposed Standard)", + publisher="IETF", + organization="Internet Engineering Task Force", + year=2008, + month=aug, + note="Updated by RFCs 5746, 5878, 6176, 7465, 7507, 7568, 7627, 7685", + url="http://www.ietf.org/rfc/rfc5246.txt", +} + +@misc{rfc7457, + author="Y. Sheffer and R. Holz and P. Saint-Andre", + title="{Summarizing Known Attacks on Transport Layer Security (TLS) and Datagram TLS (DTLS)}", + series="Request for Comments", + number="7457", + howpublished="RFC 7457 (Informational)", + publisher="IETF", + organization="Internet Engineering Task Force", + year=2015, + month=feb, + url="http://www.ietf.org/rfc/rfc7457.txt", +} + +@misc{rfc3207, + author="P. Hoffman", + title="{SMTP Service Extension for Secure SMTP over Transport Layer Security}", + series="Request for Comments", + number="3207", + howpublished="RFC 3207 (Proposed Standard)", + publisher="IETF", + organization="Internet Engineering Task Force", + year=2002, + month=feb, + url="http://www.ietf.org/rfc/rfc3207.txt", +} + + + +% ssmtps +@misc{ssmtps, + Title = {Regularizing Port Numbers for SSL}, + Author = {Christopher Allen}, + HowPublished = {\url{https://lists.w3.org/Archives/Public/ietf-tls/1997JanMar/0079.html}}, + Month = {1}, + Year = {1999}, + Note = {[Online; geprüft 10.03.16]}, + Owner = {Christopher Allen}, + Timestamp = {2016.02.12}, + Urldate = {2016.02.12}, +} + +% email statistics report +@misc{erep, + Title = {Email Statistics Report, 2013-2017}, + Author = {Sara Radicati, PhD and + Justin Levenstein}, + HowPublished = {\url{http://www.radicati.com/wp/wp-content/uploads/2013/04/Email-Statistics-Report-2013-2017-Executive-Summary.pdf}}, + Month = {4}, + Year = {2013}, + Note = {[Online; geprüft 14.03.16]}, + Owner = {The Radicati Group, Inc.}, + Timestamp = {2016.02.12}, + Urldate = {2016.02.12}, +} + +@misc{torbirdyhp, + author = {{The Tor project}}, + title = {TorBirdy Homepage}, + month = 7, + year = 2015, + HowPublished = {\url{https://trac.torproject.org/projects/tor/wiki/torbirdy}}, + Note = {[Online; geprüft 14.03.16]}, + urldate = {2015-12-26} +} + +@misc{torbrowserhp, + author = {{The Tor project}}, + title = {Tor Browser Homepage}, + month = 7, + year = 2015, + HowPublished = {\url{https://www.torproject.org/projects/torbrowser.html.en}}, + Note = {[Online; geprüft 14.03.16]}, + urldate = {2015-12-26} +} + +@misc{thunderbirdhp, + author = {{Mozilla}}, + title = {Thunderbird Homepage}, + month = 2, + year = 2016, + HowPublished = {\url{https://www.mozilla.org/en-US/thunderbird/}}, + Note = {[Online; geprüft 14.03.16]}, + urldate = {2015-12-26} +} + +@misc{gnupghp, + author = {{The GNU Privacy Guard Team}}, + title = {The GNU Privacy Guard Homepage}, + month = 12, + year = 2015, + HowPublished = {\url{https://www.gnupg.org}}, + Note = {[Online; geprüft 14.03.16]}, + urldate = {2015-12-26} +} + +@misc{dockerhp, + author = {{Docker}}, + title = {Docker Homepage}, + month = 02, + year = 2016, + HowPublished = {\url{https://www.docker.com/}}, + Note = {[Online; geprüft 14.03.16]}, + urldate = {2016-02-12} +} + +@misc{sendmailhp, + author = {{Sendmail, Inc.}}, + title = {Sendmail Homepage}, + month = 02, + year = 2016, + HowPublished = {\url{http://www.sendmail.com/sm/open_source/}}, + Note = {[Online; geprüft 14.03.16]}, + urldate = {2016-02-12} +} + +@misc{opensmtpdhp, + author = {{OpenBSD}}, + title = {OpenSMTPD Homepage}, + month = 02, + year = 2016, + HowPublished = {\url{https://www.opensmtpd.org/}}, + Note = {[Online; geprüft 14.03.16]}, + urldate = {2016-02-12} +} + +@misc{opensmtpdrel, + author = {{OpenBSD}}, + title = {OpenSMTPD first release Website}, + month = 02, + year = 2016, + HowPublished = {\url{http://www.openbsd.org/53.html}}, + Note = {[Online; geprüft 14.03.16]}, + urldate = {2016-02-12} +} + +@misc{harakahp, + author = {{Unbekannt}}, + title = {Haraka Homepage}, + month = 02, + year = 2016, + HowPublished = {\url{https://haraka.github.io/}}, + Note = {[Online; geprüft 14.03.16]}, + urldate = {2016-02-12} +} + +@incollection{apopinsec, + year={2008}, + isbn={978-3-540-79262-8}, + booktitle={Topics in Cryptology – CT-RSA 2008}, + volume={4964}, + series={Lecture Notes in Computer Science}, + editor={Malkin, Tal}, + doi={10.1007/978-3-540-79263-5_1}, + title={Security of MD5 Challenge and Response: Extension of APOP Password Recovery Attack}, + url={http://dx.doi.org/10.1007/978-3-540-79263-5_1}, + publisher={Springer Berlin Heidelberg}, + keywords={APOP; Challenge and Response; Password Recovery; Hash Function; MD5; Collision Attack; Message Difference}, + author={Sasaki, Yu and Wang, Lei and Ohta, Kazuo and Kunihiro, Noboru}, + pages={1-18}, +} + +@INPROCEEDINGS{Syverson97anonymousconnections, + author = {Paul F. Syverson and David M. Goldschlag and Michael G. Reed}, + title = {Anonymous connections and onion routing}, + booktitle = {In IEEE Symposium on Security and Privacy}, + year = {1997}, + pages = {44--54} +} + +@techreport{mitm, + title = {{Active Man in the Middle Attacks}}, + author = {Roi Saltzmann and Adi Sharabani}, + group = {IBM Rational Application Security + Group}, + year = {2009}, + month = {02}, + institution = {IBM Rational Application Security Group} +} + +@misc{torbirdy, + Title = {Towards a Tor-safe Mozilla Thunderbird}, + Author = {{The Tor project}}, + HowPublished = {\url{https://trac.torproject.org/projects/tor/raw-attachment/wiki/doc/TorifyHOWTO/EMail/Thunderbird/Thunderbird%2BTor.pdf}}, + Month = {7}, + Year = {2011}, + Note = {[Online; geprüft 14.03.16]}, + Owner = {The Tor project}, + Timestamp = {2016.02.12}, + Urldate = {2016.02.12}, +} + +@inproceedings{torpaper, + author = {Dingledine, Roger and Mathewson, Nick and Syverson, Paul}, + title = {Tor: The Second-generation Onion Router}, + booktitle = {Proceedings of the 13th Conference on USENIX Security Symposium - Volume 13}, + series = {SSYM'04}, + year = {2004}, + location = {San Diego, CA}, + pages = {21--21}, + numpages = {1}, + url = {http://dl.acm.org/citation.cfm?id=1251375.1251396}, + acmid = {1251396}, + publisher = {USENIX Association}, + address = {Berkeley, CA, USA}, +} + +@ARTICLE{onionrouting1, + author = {David Goldschlag and Michael Reed and Paul Syverson}, + title = {Onion Routing for Anonymous and Private Internet Connections}, + journal = {Communications of the ACM}, + year = {1999}, + volume = {42}, + pages = {39--41} +} + +@INPROCEEDINGS{onionrouting2, + author = {Roger Dingledine and Nick Mathewson and Paul Syverson}, + title = {Tor: The Second-Generation Onion Router}, + booktitle = {IN PROCEEDINGS OF THE 13 TH USENIX SECURITY SYMPOSIUM}, + year = {2004}, + publisher = {} +} + + +@book{popper1998karl, + title={Karl Popper: Logik Der Forschung}, + author={Popper, K.R. and Keuth, H.}, + isbn={9783050030210}, + lccn={99516156}, + series={Klassiker Auslegen}, + url={https://books.google.de/books?id=cAbXAAAAMAAJ}, + year={1998}, + publisher={Akademie Verlag GmbH} +} + +@ARTICLE{swprototyping, +author={Luqi}, +journal={Computer}, +title={Software evolution through rapid prototyping}, +year={1989}, +volume={22}, +number={5}, +pages={13-25}, +keywords={medical computing;software engineering;deliverable version;evolution activities;hyperthermia system;incremental implementation effort;rapid prototyping;requirements analysis;requirements errors;software evolution;software systems;Buildings;Computer bugs;Concrete;Costs;Production systems;Prototypes;Software prototyping;Software systems;Software tools;Virtual prototyping}, +doi={10.1109/2.27953}, +ISSN={0018-9162}, +month={May},} + +@article{Chaum:1981:UEM:358549.358563, + author = {Chaum, David L.}, + title = {Untraceable Electronic Mail, Return Addresses, and Digital Pseudonyms}, + journal = {Commun. ACM}, + issue_date = {Feb. 1981}, + volume = {24}, + number = {2}, + month = feb, + year = {1981}, + issn = {0001-0782}, + pages = {84--90}, + numpages = {7}, + url = {http://doi.acm.org/10.1145/358549.358563}, + doi = {10.1145/358549.358563}, + acmid = {358563}, + publisher = {ACM}, + address = {New York, NY, USA}, + keywords = {digital signatures, electronic mail, privacy, public key cryptosystems, security, traffic analysis}, +} + +@misc{darkmail, + Title = {Dark Internet Mail Environment: Architecture and Specifications}, + Author = {Ladar Levison}, + HowPublished = {\url{https://darkmail.info/downloads/dark-internet-mail-environment-march-2015.pdf}}, + Month = {03}, + Year = {2015}, + Note = {[Online; geprüft 14.03.16]}, + Owner = {}, + Timestamp = {2016.02.12}, + Urldate = {2016.02.12}, +} + +@misc{libdime, + Title = {The DIME resolver library and command line utilities}, + Author = {Dark Mail Alliance}, + HowPublished = {\url{https://github.com/lavabit/libdime}}, + Month = {02}, + Year = {2016}, + Note = {[Online; geprüft 14.03.16]}, + Owner = {}, + Timestamp = {2016.02.12}, + Urldate = {2016.02.12}, +} + +@techreport{bitmessage, + address = {New York, NY, USA}, + author = {Warren, Jonathan}, + day = {27}, + institution = {Bitmessage}, + keywords = {authentication, bitmessage, cryptography, email, p2p, privacy, security}, + month = nov, + posted-at = {2013-06-26 07:42:26}, + title = {Bitmessage: A {Peer-to-Peer} Message Authentication and Delivery System}, + url = {http://bitmessage.org/bitmessage.pdf}, + year = {2012} +} + + +@techreport{bitcoin, + abstract = {A purely peer-to-peer version of electronic cash would allow online +payments to be sent directly from one party to another without going through a +financial institution. Digital signatures provide part of the solution, but the main benefits are lost if a trusted third party is still required to prevent double-spending. +We propose a solution to the double-spending problem using a peer-to-peer network. The network timestamps transactions by hashing them into an ongoing chain of hash-based proof-of-work, forming a record that cannot be changed without redoing the proof-of-work. The longest chain not only serves as proof of the sequence of events witnessed, but proof that it came from the largest pool of {CPU} power. As long as a majority of {CPU} power is controlled by nodes that are not cooperating to attack the network, they'll generate the longest chain and outpace attackers. The network itself requires minimal structure. Messages are broadcast on a best effort +basis, and nodes can leave and rejoin the network at will, accepting the longest proof-of-work chain as proof of what happened while they were gone.}, + author = {Nakamoto, Satoshi}, + citeulike-article-id = {8496220}, + citeulike-linkout-0 = {http://fastbull.dl.sourceforge.net/project/bitcoin/Design\%20Paper/bitcoin.pdf/bitcoin.pdf}, + keywords = {bitcoin, cryptographic\_protocols, cryptography, electronic\_cash\_system, electronic\_commerce, hashcash, peer\_to\_peer\_network, proof\_of\_work}, + posted-at = {2011-01-01 14:24:54}, + priority = {0}, + title = {Bitcoin: A {Peer-to-Peer} Electronic Cash System}, + url = {https://bitcoin.org/bitcoin.pdf}, + institution = {Bitcoin}, + year = {2009} +} + +@TechReport{Berjon:14:H, + author = "Robin Berjon and Steve Faulkner and Travis Leithead and Silvia Pfeiffer and Edward O'Connor and Erika Doyle Navara", + title = "{HTML5}", + month = jul, + note = "http://www.w3.org/TR/2014/CR-html5-20140731/", + year = "2014", + bibsource = "http://w2.syronex.com/jmr/w3c-biblio", + type = "Candidate Recommendation", + institution = "W3C", +} + +@book{Ferguson:2003:PC:862106, + author = {Ferguson, Niels and Schneier, Bruce}, + title = {Practical Cryptography}, + year = {2003}, + isbn = {0471223573}, + edition = {1}, + publisher = {John Wiley \& Sons, Inc.}, + address = {New York, NY, USA}, +} \ No newline at end of file diff --git a/Bachelorthesis/Content/Abstract.tex b/Bachelorthesis/Content/Abstract.tex new file mode 100755 index 0000000..498241d --- /dev/null +++ b/Bachelorthesis/Content/Abstract.tex @@ -0,0 +1,21 @@ +\begin{abstract} +\thispagestyle{empty} + +Im Angesicht globaler Überwachung durch Regierungen, %toref +schwer kontrollierbarer Sammlung und Speicherung von Benutzer-Daten durch Anbieter von Internetdiensten %toref +und fehlender Aufklärung über Konsequenzen internetbasierter Kommunikation soll diese Arbeit sowohl einen Überblick über aktuelle Probleme von E-Mail-Kommunikation, die die Privatsphäre des Benutzers betreffen, als auch eine Untersuchung möglicher Lösungen leisten. + +Die Vielzahl möglicher Kommunikationsmittel im Internet erlaubt uns nicht, dieses Thema abstrakt zu behandeln. Oft unterscheiden sich diese fundamental: in der Art der Benutzung, dem verwendeten Protokoll, den zugrunde liegenden kryptografischen Algorithmen, den aktuellen Implementierungen und inhärenten Problemen. + +Deshalb konzentriert sich diese Arbeit auf eines der ältesten digitalen Nachrichten- Übertragungsverfahren, welches schon im Arpanet %toref +erste Anwendung fand: die E-Mail. Dabei wird die E-Mail sowohl als Technologie aber auch als Kommunikationsform betrachtet und ihre Bedeutung aufgezeigt. + +Der Überblick über aktuelle Probleme wird alle Aspekte behandeln, die relevant für die Privatsphäre des Benutzers sind. Dies beinhaltet konkrete Daten der Kommunikation wie Inhalt, aber auch Metadaten. %toexp: Meta-Daten + +Bei der Betrachtung möglicher Lösungen werden zunächst bereits existierende aufgeführt, seien sie experimentell, schon implementiert oder nur konzeptionell. Nachfolgend wird ein alternativer Vorschlag inklusive Konzeption, rudimentärer Protokollbeschreibung, beinhaltender Algorithmen und Proof of Concept Implementierung der wissenschaftlichen Gemeinschaft zur Falsifikation unterbreitet. + +Dieses Konzept soll als Idee, weniger als vollständige Lösung angesehen werden. Viele daraus folgende Probleme werden nicht ausreichend gelöst werden können. Diese werden jedoch nachfolgend untersucht und Vorschläge zur Weiterentwicklung unterbreitet. + +Abschließend wird diskutiert, ob das vorgeschlagene Konzept ausreichend Potenzial hat, um bei entsprechender Weiterentwicklung eine angemessene Lösung sein zu können. + +\end{abstract} \ No newline at end of file diff --git a/Bachelorthesis/Content/AlternativeLoesungen.tex b/Bachelorthesis/Content/AlternativeLoesungen.tex new file mode 100644 index 0000000..91720bc --- /dev/null +++ b/Bachelorthesis/Content/AlternativeLoesungen.tex @@ -0,0 +1,5 @@ +Zur Lösung der Datenschutzprobleme auf SMTP-Ebene existieren wenig wissenschaftliche Arbeiten. Eine etwas theoretische Arbeit ist \QuoteM{Untraceable Electronic Mail, Return Addresses, and Digital Pseudonyms} \RefIt{Chaum:1981:UEM:358549.358563}, welche allerdings nicht auf konkrete E-Mail Protokolle eingeht, da sie auch ca. 1 Jahr vor dem ersten SMTP Standard \RefIt{rfc821} veröffentlicht wurde. + +Allerdings existieren alternative E-Mail Systeme, die das Problem des Datenschutzes auf ihre eigene Weise lösen ohne an SMTP gebunden zu sein. Dazu gehören beispielsweise Dark Mail \RefIt{Chaum:1981:UEM:358549.358563}, aber auch Bitmessage \RefIt{bitmessage}, welches auf der Bitcoin \RefIt{bitcoin} Technologie basiert. + +Nachfolgend wird Dark Mail kurz besprochen. \ No newline at end of file diff --git a/Bachelorthesis/Content/AlternativeLoesungen/Bewertung.tex b/Bachelorthesis/Content/AlternativeLoesungen/Bewertung.tex new file mode 100644 index 0000000..ea20ec8 --- /dev/null +++ b/Bachelorthesis/Content/AlternativeLoesungen/Bewertung.tex @@ -0,0 +1 @@ +Alternative Lösungen wie Dark Mail \RefIt{Chaum:1981:UEM:358549.358563} oder Bitmessage \RefIt{bitmessage} sind zum Teil sehr elegant und durchdacht, entfernen sich aber deutlich von den weitverbreiteten Protokollen wie SMTP oder IMAP. Dies mag zwar notwendig sein, um diverse Spezifikationsfehler in den genannten Protokollen zu überwinden, ist aber gleichzeitig auch ein Problem. Denn die neuen vorgeschlagenen Protokolle müssen mit den bestehenden Protokollen konkurrieren, da sie mit diesen inkompatibel sind. Ob diese Ideen genügend Penetrationspotenzial haben, um von der Internetgemeinde angenommen zu werden, bleibt fraglich. diff --git a/Bachelorthesis/Content/AlternativeLoesungen/DarkMail.tex b/Bachelorthesis/Content/AlternativeLoesungen/DarkMail.tex new file mode 100644 index 0000000..8320b4e --- /dev/null +++ b/Bachelorthesis/Content/AlternativeLoesungen/DarkMail.tex @@ -0,0 +1,3 @@ +Als sehr genau spezifizierte Alternative zur E-Mail muss Dark Mail, bzw. \QuoteM{Dark Internet Mail Environment} \RefIt{darkmail} genannt werden. Dark Mail verwirft jegliche bekannten Protokolle wie SMTP und entwickelt ein gänzlich neues E-Mail Konzept mit den Protokollen \QuoteDirect{Dark Mail Transfer Protocol}{darkmail}{S. 82-87} und \QuoteDirect{Dark Mail Access Protocol}{darkmail}{S. 108}. Ebenso kommt ein eigenes Datenformat namens \QuoteDirect{D/MIME}{darkmail}{S. 68-81} zum Einsatz. + +Auf die genauen Einzelheiten kann hier nicht eingegangen werden, da Dark Mail sehr komplex ist. Wichtig zu bemerken ist allerdings, dass es eine dem Onion Routing \RefIt{onionrouting1} \RefIt{onionrouting2} ähnliche Methodik benutzt. Ebenso kommt verschachtelte Verschlüsselung und ein durchdachtes Schlüsselsystem zum Einsatz. Allerdings ist Dark Mail auf Implementierungsebene noch nicht fertig und es existiert zum derzeitigen Zeitpunkt kein Release \RefIt{libdime}. diff --git a/Bachelorthesis/Content/Entwicklung.tex b/Bachelorthesis/Content/Entwicklung.tex new file mode 100644 index 0000000..e69de29 diff --git a/Bachelorthesis/Content/Entwicklung/IdeaConcept.tex b/Bachelorthesis/Content/Entwicklung/IdeaConcept.tex new file mode 100644 index 0000000..8562508 --- /dev/null +++ b/Bachelorthesis/Content/Entwicklung/IdeaConcept.tex @@ -0,0 +1,8 @@ +Zur Lösung der Anforderungen in \autoref{tab:FunctionalRequirements} wird nachfolgend ein Algorithmus diskutiert und vorgestellt, der die Verbindung zwischen MTAs auf SMTP-Ebene anonymisieren soll, sodass Sender und Empfänger einer E-Mail nicht durch Verfolgung von IP-Adressdaten nachvollzogen werden können. + +Bei der Überlegung eines solchen Algorithmus spielt vor allem \autoref{text:NFA1} eine Rolle. Alternative E-Mail Systeme mit einem Schwerpunkt auf Datensicherheit wurden bereits in Kapitel 3 vorgestellt. Im Zuge dieser Arbeit wird allerdings versucht, der Akzeptanz halber eine SMTP-basierte Lösung zu entwickeln. Dies soll, mit minimalem Aufwand für E-Mail Server Betreiber und Nutzer, eine Verbesserung der Datensicherheit ermöglichen. + +Bei der Wahl und Entwicklung des Algorithmus wurde vor allem Wert darauf gelegt, dass keine spezifischen SMTP Erweiterungen notwendig sind. Somit soll dieser auf dem Minimum des IMF und SMTP Protokolls fußen. + +Die Anonymisierung soll über zufälliges Routing realisiert werden, welches kryptografisch gestützt wird. Alle Informationen zum Routing sollen in der E-Mail kodiert sein. Jeder Knoten soll zu jedem Zeitpunkt nur den Nachfolger und Vorgänger kennen. Die originale E-Mail darf nicht modifiziert werden, was bedeutet, dass ein Verschachtelungsverfahren angewendet werden muss. + diff --git a/Bachelorthesis/Content/Entwicklung/IdeaConcept/Algorithmus.dia b/Bachelorthesis/Content/Entwicklung/IdeaConcept/Algorithmus.dia new file mode 100644 index 0000000..c27a82e --- /dev/null +++ b/Bachelorthesis/Content/Entwicklung/IdeaConcept/Algorithmus.dia @@ -0,0 +1,2329 @@ + + + + + + + + + + + + + #A4# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + ## + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + ## + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + ## + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #MUA (Sender)# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #MTA (1. hop)# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #MTA (3. hop)# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + ## + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #directory server# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + ## + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #MUA (Empfänger)# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + ## + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + ## + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #MTA# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #MSA# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #E-Mail server Sender# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + ## + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + ## + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #MDA# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #MTA# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #E-Mail server Empfänger# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + ## + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + ## + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #IMAP4# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + ## + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #From: myst@sender.de +To: myst@hop1.de +Date: Tue, 8 Mar 2016 +Subject: +X-Myst-Mail:1# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #From: myst@hop1.de +To: myst@hop2.de +Date: Tue, 8 Mar 2016 +Subject: +X-Myst-Mail:1# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #From: myst@hop2.de +To: myst@hop3.de +Date: Tue, 8 Mar 2016 +Subject: +X-Myst-Mail:1# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #From: myst@hop3.de +To: myst@empfaenger.de +Date: Tue, 8 Mar 2016 +Subject: +X-Myst-Mail:1# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #From: hans@sender.de +To: kunz@emfpaenger.de +Date: Tue, 8 Mar 2016 +Subject: + +Hallo.# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #verschlüsselt +für empfaenger.de# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #verschlüsselt +für hop3.de# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #verschlüsselt +für hop2.de# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #verschlüsselt +für hop1.de# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #Myst Mail# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #empfängt Liste von +möglichen hops# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #erstellt +Myst Mail# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + ## + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #MTA (2. hop)# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/Bachelorthesis/Content/Entwicklung/IdeaConcept/Algorithmus.png b/Bachelorthesis/Content/Entwicklung/IdeaConcept/Algorithmus.png new file mode 100644 index 0000000000000000000000000000000000000000..a829f7dea4297ce33deaf6726e546feed95e2f1b GIT binary patch literal 32501 zcmaI81yq#p*EKwp2!e=!G)PK!H-geB-O}CN$WNq^ZV8d@7`jwI7*e_s7`mnNyXGIy zde{4{=XJ?qF*Dq8-RJCc&ffbXLRDD?81br0oh149inFE2mgvd!tYItYuE&8P4PqvHSdyRY_ ztmbCPFaIDL{E|9K7XKMdxZi4+Gurmml2eE7!O--&S375f+S-}l&?>KrW1HGv_t0`C z$0k%Wjc481Aq)eh5;~}}kBCgdX0I<~_EWxU#Q$XxVUO$oKl398cfOZ-=gCp!Wo{X<=s*JayClHxm*Zllb4ou z>B8E7Wu}frrPR`4&6c_*B1xS;!xSMD{5^kNnU~!*XrfSa5qD9yvZ}0NA=MTfLcm_? zrZ>&{T}hJp{kz0(uTzE5Vhq!xm}Dm8XKs|FlO7L_O2(^X=l*ymzI|M2~IKp zwiFs%lPKts(MhOeBT$+i9!?Ej=jJsQvTY{0`F7V*T=}q|)*vm7Pc@7m^<)v1jhdRt z8JtUHL2uGi{w6JXR+^rAfZJZG?}Jc~{+*iN0?a{ejwC#sL2_Y)pPt>DoeLK?q9#=s zS#d;K+B}Ll1H2VG15*Nrl(Cn>!^Q2v{qK_ezkg7}=pgWTERE)fdDQteHY9wt2$fx$ z99bDcBLyGdD!Z8g{PqgiH_ipQkUu zqx>h!!kXsW$5KlHhj|Sp?-ni&ShyCeVRyvbJNLLrNK#)5%%<#j@Cb(!7F-gW=F|4+bc!H^CK!eRK|2SXk{nqbNP74wh!U+>S^`kG3JK|-h zB&4OUhIGUD$UBndh~~Ho;T24{S;h2k$_n6|i4iI|^{&*^`TnGz`1bwJy<7SOC$lEN z60=>7!pQjxL&uGj~*v)V>Ho{n${|^!x=Ep6X_JqMLb$3fnTFsbv5>|Um~8`I!EQl z2HlZ#tK&*>TL){;$?$X7j1f22ZXPGq+Hn>x7zg5?jcsjIT3Wgwc@Jx-kORD1W^QGT zxa1zJe}w{Ce4bRtr?f^EJluG%FXx}$y3=&`>Ml^(Ukw^EgH!T29(;<`&&PZZv*L>a z@os*bzGNNVt?~tbNA|QyK8S z8`M+Kah^4&;(6z7?+Dux>hvKNE^a(^SGwscU3o=hiIUEE(uPoff6gxvL=t`u))W_Y zydtBDH3C;x&O0Va7h;nZvJ+q;dvio;e6zrpF}(6 z$&E8MjuyC$TV#3=WPD-%GH5pmXKTu89f&C+H5NwX*GI|JTXRn#jxVMQvq-Fj|AbNL z?hH4yxA?DDGV{j_d9xut)Dtx>vSZ;|<6o-fR$b$9(C)g{d{ir5zc0M%+x=`jbsZ-0 z@$!+y_%QZ#A{N{Us+GglUf)`VhYOF9cokGqX4pT-lzRB+bIHQFyOqP1GoKx%b<79{ ze%eSWN1!{HV; zdFnN8+N*3M*|3UypzdvLEF2#G`s*FTc%kMvvX;zxTxLp*5W{`%OX9TD&|aDj3+s6& zsioFj(W$-mhW%5z8BaTqFl0afuFd6OIVcA9a{X}^yV1S?%?P)bZ6%3RFVT#jT+3>FY$*!P|5uL?X{7 z_81TE53Jj z`5YdODMN7})=yzcO+A3(la`nM1;i!J`ui|?#0!InEOhz#@1zSc-^z88LA>sFaQG=~ z-Y}6oyC-5+T3REG%-nkZBZmdY;&WWw{-b)fMwdI=#n?n!&V5{uWi|)VmUp?jjS5~b z+(dA32|na{=I|_%>1Ddd_$;Ocz#D^U!7;gqweFHAKRsor;L-=tul4TTcwFEqO_9}5 zmf+tHPuLz)Q&0-pNs;#D85*bkZI1~5)mm6sxcqQ`p*+&El^=D&Ds>ZH@t&Ic1eV13 z?*1z0LAP-IRgV8jl<_U~mbd>O8@9%p;MSMx=$V2nAQ#^D^z_7up6ggxd~2GCr;&Mt zMf6NrcIk@asY8oht+$`q_+4BNdU{$!xNL51t?OL9%_^7Obmd~Bld-_D_ofZmoVRM5 zUG3LW)H6_t;G&iPE>eGn@Xf4vadFW$7rmAZI|JLB29MYJ`eH~4l|`05rskz*BJ!Tl z&|U3Ij8t7}CZfKjyb&BLX6`ww26m)N10 zjS%_ZHW_D`{Z77X|Ifi&P^jHe9$}^N*d#O!_QsHAW@LPi=o9W^P9gFtkK~?z+$Hqs!-Csf4nsuvt>qlu_CYA@l;tWEszTTEMbs~a-I$H7F5t#< zzM*yPhf5gWxrbfO@8q$&M1At<>`GUS=C7$Mt1Q&{!Per-{w1S3Yn+|pcd?Y>9ex*% zF6mOAo_g%faAtY8xn<>f%#N*fHbSTM=&j~^H|U6{sX5m+ldt28DW-W@6;(Jzwf$cV zlCZXv+J{bOe``&t32q{AoYNckeDrt+<9k;K%3u4Qgk0Zd_Tu2U^b`IwoLSoAJvko2pok zv$>ST(jzUFJKf9U#wW|_;dj*S`zt$=7S_}pkI7K-Qm`{4{-Jz^!IiTFIK7WnMy1^P zXYWSYV#DL~Md4ed>Dw0qiyY09sRo7S)CsirO&p#(n2y-V;tCu1l1SZ8YDj*hTxlfv z2+oB<39eVcEq{F*^P7AS?kenc&~~+viNxaV*zQfLkd#{ea*-y!Zia!#v>YsPJz8Wso&hl zZ@;0ikRB3nbDqs>H?`lmywvJ-Sp4+~0r;RAs{N-o0c8A21JCw~aso4kEH{TTy;i!A zAaFRGf6@INIPP98EP?k2j2!{o9r3z@KX;NoXuf;*cjBFj1y}mTlAnqom;Fq2X=&;9 zc+o3s_RW_ZpsT)m>px#J;5i@h+FD}MwOO-F%c5=;oZ|Xt1Rg}lbI*IXqESmzGlqzh zdS}Zt1a#%HkuD=;iiL+s|wn0zluiZKh2p48% zn%uX4+wO<$b%|D?O{g%+p^&zUu2`us za6Va#&d%*l59+vxSfAnSn;t@A2m>qY-Be?TrlzJx4}rFT9_}Dh>B-5-#)jq9J0Xvq z)8jr$m29EOwQr%l;E+i~fB5eW?1}S*d`{N6M??~bEVavZ^0I`jM|0hUM9q4!JP0@r zzXY7mat{kg`S`<=wUM{Ri{cWhlPM?Be|*AWXJi!gJ+(`DO20i^M#B`>qdY zf23c3+-lk7@O7V%d?xqU^liO=HkcZ`7d+w`H93@x&+?=`ZH(mP^qWsr8CQ`J3wzpw z=m963gE}x9$F=oD5nk-idx7%vBMduHyevOI->}v5&6_tt_kVLHJw35z&9_+fj~?!g z1>#kyb`~>{<|RlIRZ6ddXN0L(K`j+}!@|R&{>qH&0>Fb={d@ge?!%R)5EzFXaLgU)UITiq;mY&4qBMEWQ(i! z7W%Q2&}gBsuqL;ii4sC1Z>q%pw&PyXfvocTyPKl%?R0Ld^Q|$OdJYiGzGpk%7MkG7 zy1KK?n_uQ)qjg^b_&ulP4nFF-!xh~KITa+&@N z2REhf)ZSp$7n_Hw6Apq(Pt~oovp=~cBY`0m)_yjnKWl#ukiDd$0!>v{7Xf9ZrA#tz zMg8QK*66P(=k8NcabK^bIITL;Du@PO)h3&75SZ(K*(d{mY45^kvhs2jf0zi<|hDsN;zVSJtQyJ ztGfE~DpK+r=5(+v8MO*s)A1bmwd&@Ul`@CXcpo#x_m>wkZ(%MqBAd^n=Ye19P-(GM zs``G9E1%-E9KfI0FLHM}&dbXS5pv(+@YtCEc#^Su+Y^>UJm-EnwJlT=`=SAty~->@ z(qT6VXR<1RR%Js8o55nIr6J~S{T97QdZshzq0Q$nS308OLn=@&aarpH;k4+z7E__$ z7%L=Xn^)bN*KYsyMcxPU_7`3*nPTuY=c;o|-naO9pljAP4&cok>Nx$aFhFf! z^~DFI9Dvr-U?i0M*w{gWg+(o8zb|Vq8C@PJSwd!J9`>vUb-Y?8%^VtRQS|(&7XNX} zAN9Y#+N`r0`NC~A4B9|QQc8-E*P;iwl6QrQ5u56%1@gV(ajo`DM6@qb`Ljtj0$vd_ zb9wnkJlW)2wBsG}k5#U@9=nt{(&2jUf?aTQY=qIdgCkVn3~){CX0LA6-t+1NK43>I z;A|q4{RMyqXo$bY#uogOnpd&m`l){gR*{JvJI**d=3O^Q=Fu%#)@~T{ZfNbOLoJV! z9EYRhFzM8Kf}D8c;60SV3yRWM{u`NCGNjQ$rOZsnmXgxa9n$5? zx7|5@ROkM&wj>(m6aF4 zFcw`#&LFPGYGz{4^LR>1q1X4dk5b@Vv)g8tpqu5$mv*zhrw}mKfF~eVG(K(Q=TN3q z0iLM;=MiF|@9dq&4@*ks3Jx;gud3>!&Wq1ocW~2RlB2zF7o`#au^7ePk=Ad1e?8sF z$Ip+lHC?q_u3P8Wd3O$;?^|;6E5;md9ypTMlYc(?3v(R?LRahGmy-VTG(RTuC$!e~ z?)nTov-{gCbQ}s)RU@N&M6U%F_O}AN(&;WW^WZ4HaiPA!Kj}}?ebLHJq;Y15L0~=ba~CreT}+aev|~B=?;O8!)zkkOVb3PDlt-D)>f< zrlqQ^SG-N)ux|ZsKvLG`T;nb5XZhk^`D)cvZ?`87Q42ci0a|2VR!o*|sdW~qw@e3T z&R-V>6)9JJBNdxo?9C4EoB~KDcKj0$g#S{l#gkxA93${v0h9>1nO|mOXGfeX?%_hJ zZ{MzDTZE8u8cSYK7aF||=ZSLFw~+7GY*q5A;o0X)-J9amvhd|-?tHA(`6J;8jx5_F z6MG$)!Sqfp7!`{BZ^J)N&&*tc9>|<4{hLB6A0Hp`)@0cIblp{u|3eIQJAZH$s9rZJHPrLGP-8+ zI}Kabxor-Ek(M%8t3nR}A=~c0zYF9*45`V;#AEPDwb~i)s8@0F>l;#k)78}XN^wyy zw&Aq?U2U^oXpEcHfl;|k94Q!UBup^!QS!B&M2>)q>G5h0NU_OM%>j5A7IA`dkyGnF z6r{zY0FTJdUzU+_p7F%OwTj%u4%wBVE*e~plsx!c_iL@seu$?(d+qyhcL6ftor)-8 zFof*SHDn5T*n&*pwp1KVEku>OHE=X*bfY!!-`=>3I*`7EraxtEC88<%;IYyba`ku9 ziYpzA3-}UD$t{FhkJ6Qbn>(3)`sV9!=?!F7Dnd~u*dJ%Rn zmNOW|MTgEmaxmk;b3AsZzz_fiH7#vz6zj#7vl#v*9ncf^)1^A^URI7xe!4XVA_H_olW73`Dwr4uCNqVm^s&o_=CTL z18XpwVT)ppSbJ%yE$AG=vU8{`7c5D6cjD<%HLB;_LZ*1cMAc(5Y32j47gzI{ z>h}N?#*0*{%FCkx!{H~nkK-V0zUvzkyTX_MVmWv3kS*neU%yNx-DqxcGU7E9;4%M_ z_m6Ge@j@j#5ZTX;X9nP|09^+x>p-xbg7k*~1UsJ6cd95YCE+xcrlnFtI;q1ZAGTCN zsyHUzuzXiI{d}*`LLWtK5HW^k^4g`0*Hw1jUmtOwg8SPT&dwaN1pN)x%Vc?_G>$v~ zouI`jE-rp7NW|nUdFDzwy)hyBF$G(-jPIK{#q)J-%G3icLuZW&K&#;rvW{Ju)vz8f2f}X115T(_33>>&I^4USQA#D1WffZ0vuG z7X177Z>NA=eQ-u?1D7{0E-u#ZpAq-?7V4xm%edy*A3vHbg!iDevB&q)^U}RBG+YFP z1(=GM*`UsUUR$6POJs}qoPbWX-<%6TH}r&%=f5LXwBuq6T7U;NF%{rY(QHEXYqV-D z4=Wss*t`4g8p36l{+DT~eqS3s|MSQAyqNwG9r~>jU39agb%zC5Ug;)h0Vi=eLEv?I342~c5 z4-5}c6p5u9A^-jgijO6VMNZTWPAOGlPSd)t}NCngJD4q?lfdXhJ}iPK(|E z&I`;f0Fo)i{D~yqyy?N_Ur+_n8F+iSvXTEBt!RadXPjG2gM^fHy2?1{WL?gsrt{(M zuyB8EZf?%5s$DC4^PA-sjZ7?yUOhwRP~hdCPXqCQs|9iUp9$#xqY6Is18h_pKiPoI z3-l0xP>hJ0oSGuR0mV`|TgU@Gkh~KQXc%_m4iV6PgVu6@F*!LIk^QBmwdDEq@~D>9 z)R=NMHrxCi$Jm6-DeJDyhyI(w>>Zc+=PTr13pGIxfe!wBC*)d(kb7>59ef?Izfq=3f83kb1 zdN7T1U=8ibi`&aSaX!`*7#wg&m3KE6;-{lhS*1!o{f$@-t{z!CQc71Ev$_C}WB0d)rEU|>A%K5w~*d+a&ZG7w|M*@p*@@!X#i zy}w+$QJ!!0sybN#1K=;S_%$8oYaZ?%MgC7y^oGZQzayV%&CusR zj-e2pI}O`tX=wpbw8eE1aItu?5{mPJfZ!wLD>aE*gR^&mWJ0<11NKVzRu&c(fLq;I9vt;&b?Tl3_f>Y;PPO@y2Zg;`5%3cBN$$vot=TMos(i2 zjE_E>*%w1jfo>=3{fGPBRn1?A%$@R)amR1+W=ZG=#G4I<-Fp(i$Xs1n$(AhNem-Y6 z9o=ernLDQNV9&jrS^NxDAa!2nWp0LH5^cV0xl#M|N_S{WD4&0m@qI;$`vwN0(ssMy4#XRZDQ56F}Wn^J*f@5 z-)qu~tn*j$`Okv*cXFsm>M(WWzhgx^ik9{U>6p?DG)+Hb44lQ%@NFL*2@r73cwZ# zQQnN&eM`iV5mSs);NMKye7Z=CocYlKnc!>5mE$#uc{|p`ItR1A&#~0V!h>RZg1DeX z=zwdXd8P8jezJ5D9Q=04@323s7IaO3=UW4rfao4F>LM_ec-j|E7OkP8t_jJceFfP+ z74Qk6L1--n(U696GAj}Z;!Va*bAPK~J zrIPSLQE(WaU8HO_861>ZJsqU7l}9xUA|Sip2|M=-1Q$gv>}lZIPp5UG9BJs>jn;V! zXQ%XDLF!zimWPNRe&Qq7fKtx}Ysq9xp6p1Gg2WSN!7y5=vfyq0;A*`?y80Zn5%}AvQ;9VPG_&i(@-1#c}uH@$l95Sp5Ee zj)sf3tmv__yJ9*$;E2s*h%*>U$}_69$~^t5X8DDKDNcuYJQ;vh(i$j;~!tNpAya?Lr)J%qW z`^5ZRttxY5&t<$NtTv3`&{1i=nJ{{Jigav!rPij&&=dXcxr4KV8KISzqc~fKRu$4$ zpTNZsf0#E~99!B+7>TTo%9MTT*Bo&oZ3@-i%pR3?-J2V&xZcVi!{`Q5q3qt*uh?8tu{O%`O~8&NLW~RgIc1O)a;M=)NM|@u{LmBQt%C z{fFUvy*F<}j1-4UD)FD$y5pTPHFQbNUa)F5uEZ_xUM={$b;YY1=`<%0XDF@*S9INU zkwLQP-_m|`YmQ(b`V@i_e4+B-b$NR1YGR+{f=h=6p6gWs(xq%-LL>5A{4rbCY?rMG zmg)=LXlab^;OSG`-nokf;^?4H*nY9aj)t&_+!?c*yr?E=qOUcHNcafEh^%5HEjyBd z8y*z`q);A4pW;6#VdFo;vrNE{kVkLwV_WOwrt594++TZblhf@a5t1!y!;!Zp{G;TT zzAIFCaCA#+KPvXgq_pHbhPeI7`UG)QTOO5UBpP09i>ro)$sVx)!}UytIG>@>Ub-{9 zc*FAZmGS$nwI^d!S>YF-FqK)W&)u1?0!*x6RyWzheP+Rb7l;3vf~b`es|O4xJni6| zW(oP18vMh)UqpU93e=ipfD#2e!%7(WD-Slj@(cSkgauu_4KL$Yh=gx*GHrpS!1#-T zN~}Sye3M3>GQ0|C#@!fxXk;Vw6M~662J-F3ez={+?h3#UZ7< zD#?&d6f@NCjESY;iE)4u7X4_GMk7)>x?8Jn>M2p9Y=GaP4SB0{}qtaj_*kAVPfv|CpfH_(;?~a6oMjijBKz+@o zpg-HayHaaM#A$3po8*q-8?>mCSX2kqH(C zRjE7i2mZxL-oX#@Z-2dXQ|fw^k<^B3JtZ=)l$aocM6Ss6_&^)hwqYSb!$Dz9I%+|l zn059Vze2~#dOBig>}93ilDlo%LGBYR?bPNq81y+4zOnU-X#*6pX%WpwSkvb4ztN89qnC0f)WLIChHC&VOkqb|Y#{Rf@t0sg|KE{*eW%ETIY13N$m%9- z$wGU%9q;zRRmx#h8vj<5@gH6 z*J9{N$dlkH+&;8AU2>+`TiYf)J+DaP3tfSBwbvs2Jqom1XB_Vn-vNgSjXh=^fwJQ% z+C96oPjsQs&9}#IyitM!GtwL$pf5w`&fB9@yyQEWT#zk&=?PDOK1rvjzoMUKG&*)! zrdU|dMfStxnE{d!Vo+1e|)U&~fk zXM&s)L5x8U{g{6Vb2(nz&|-!^{EIt`?8T)yj`_93PN+JBPj{A+@K8uGiCh*;y;56D zLnTkYeDLYq#Wsvx@l`^&RjNRRu~*~Ua-%@8(Q}-#xCZ0q37X~w?LH5Sa%IjG&h}!? zN8`3JXo_W;55@wWubfakx)^e~c4Wg77`qlvnXnri(n^)J(VCpfwlMhERZqlYGsELLUiDac8MxaNL)7as931O>wH)*nQoQif zj2qyb2N+80N;7WFblMmk!&y8-xloUmr*CTujH6gTv&>&<&7E$qiAPrIjhFp2W1B(D z7=SN$OODo(H-FH(*igLBS2E9-6)BWuu2XH&J;c9E=7En-BiBAZFtbmlNi=}cnZo;$ zl*`Fgg7MvSg~Q&fxW2}EFh%$FzP)ip$_&O}EYLFPiRi^s>q{US8Uj>S@n>3IDVpBI ziJ#B$ZBKt1E)=R<2`rQ;9j(5%?4Nmk`jzr-OS|)0^B*MqyDDmt5V_9uiK8G=YAhPY z`|X_jZNLOY3SmZOS98~=IFDAE9|BPzk@N%v$@mBPPflhU-WDQXk@6W%vNtIdpOIRH0w6GK zu%1<%Ca({O>7|2M3{#6P>YHa=k!72neLW6YsWGQrB{`X)M-(6;5>R>NHo&lM@Kkl9 z$r~1!HwgCs;QRZgbM(-z9ar1Aa{#txsbyCKoIZ>%z8(pP0bKalk z(C>xb$lZi9hwWf2po{-!p8FveIeWB0WT8a7{V~Jzka8W$VMnvn3FuW59J)|zgEgy7V z#+RS-DtcXdNNJgc`Ter4&3!Rs1MBh}dWk8-UmHF0H% z*Xk;lK*+{Sb$BOL?XxI;G8MQ&lgoP)vqJOqQKCzlJFCK?GP>y;yXI=9UyPeKIo!rY z-}vVB=!wD?7q+@oOLy(JFHFtnV*eN&WtDUmo>Pa@db6bZ}XeJbP#v zMyGa_xyziSqw;vHbfH}`q#vptTKz--g@{CMFG*wdEc@rHQo{is_K9@Uxz3=))OSQ; zNGT^t=NI+7K>DCHaXK&Y&X$h6Qz#*NE6F@s5$gQ!`~jCkcrPh9c6ph^(Yh+3kvk;XK z%N18man(PDKfBvO0g+6xx#yE54)6H*ECjh%T`JWMXhL>$oTj!Zb-20iZCQt zeuc?oa{G9Dsw-1s`WG_ofH>~5gT+9aBd}#wh%)0U`R5Cel=v*5LUhUm)saOo42W!j z(R&2=i|u=C5l+l+axQoa^)<}K|8`>Lzve`iMbZkQi-S!6L-JIO>d1<%vC?dI?PTr$sj^j$uCz2;>A&<`-nXmXNGeY6xr8aQeSIxUsPoz(i z<1NvxkS;!wKUNDlqLM1}8B=>b`P@C>M%I8;e@2?`Em5o@5(WBYkrX~w)!L|5=m0Qx zkdC%AFU*C;GEHm3PnE45_askoXt2e_$Vd7MrG38d=A;fTuywQQoJ3$O1ThTJ4&kPL`ibGNhZ+P6S2U^~ z3VXJZQgrwS{3uCUKr|%$dA(BTuaj;LwCcoHDxSVmfT&#rbmPlas%b#EEi5eTZ6!?s z8-?SdP_FkaK@^xj)dUef%{(c(C#kswxG@mmBJv0JBy?i!YCtbHcpWYQrb$yvYaj{1 zkpfv@XLmRBX>=9|&@uocOrGru1kH!rO>rCsiXcGA5!3_16XEZ3=_LjjTNm52r=qXyiD}<3Ml*Hjn-!AeXEIW{S*RL=5mH)CRy2 z2E_h&Vke+;j{{Db=(Q|WaakEqMqjREs6BcCaDq}ObF9zZ9CilHTBJt6$bb_A zsC|Eat`UM%LPm&ka~q|Rk&zi08P2Oz3ED02MDE&GHMc{dZ`$uz51&~d2FOcE<^7bZIj8H07DA=An?|_{K@X-xc|f9L=}B}EARbbN%&5-x;^IeG$z@!QY5L>RxxcU`vl zx>SONgM&~4(Qcnz66S_lxLA<+4kR(I>g5F8U*%ITojUWglr#qa_Z{%^?{oI09jr|{2r2q?2mG3mxTK< z4nZq*7K9k1%=5~`qI9BBAe9CSBMlA20Vdy|&N8N{1E>+Fd$V{FYKFMV$c(vlDs(|n>)hq)%F){2ZF;@YwR6zI+m;CR4{Vl`M zK-uy$Gq$e_^oq98-;l&)_)aq!cT3V)d7CP~K*vO{tACHbi-M0d#JarM7!uKix*}!* zCd6|fg8+^6*y#}L9su&bqD%U}gAL)x1X&%^hmJ+$Jf&-eB;a}~J45$F&YkV8-nPTO^Ev?#_VJ5@YPhBBbf=2yceC!UgM*GD65c zbBkE>HD?saYiQ*^M-K_5Fw&FMeHx8kDS;smIR)xjW#zDr{N2UkUC)8|-IdC8Y|A+? z&Eg2Ev!~_le^W0pU`wq^rBP2xN>a=g()6k>EVKl$rXqG_4s3uMcbWVLGcy;Y0Z3VU zF3%ZrXI49(YpXPija^RQgzyg;t(&i;c3DpZ>XeZItFFUhOGBjwQ1ipENjomu4@IxH zzDfyuGBMe@?chV~gDh_VLa{7Mj@LU}cR3&3EZ^KKC>UM;2zvN4XIGib$gboIhj6;p9$=0<0|5dz%vE(MQC0}_sKF_Wt*k-nyGihFSbHm z)eAj;f2z3*yyJUSBql~i&W+Nru&``lFT~;j^}DQ0c(l~+o2&o$1>f113E@*BxIY#P zHyIhu0*=A&RUJ9G{ty)O==QH*Ru#YO#<>S--4`IuD5NgI;mPxjhYg*Tb5gqtepj44^n*IbhsBFK4Yfyl6 zoQIu_&M4EL+d^pSJ8B4@lb?|;^tQFP=h-MVV7vI6^WYEMZAwZ?Anw^&m0mNiBT3v4 zdQv%yJ2%U91H~Ru^Xg-Ps2UB*%$>{4Ibi^HJnbIJ{mh9ho%5$F(SuC@2OC3~F&+lq ze?GSRo(Tc-JW!g7lq+i6>)0HTF|_4g+lFyFNbU@DvC!x>xTC$YRT&f2LQ$pIWh<(X z*Z!>&dJulF(~`h-HREm=2yJ6j1fm*;D1hs8gh~^KjwAK}_QzmzGHmi8jbsJ-i#dy% z)UiM6nGEgfACGH=h$9C=>bcqdfXOh5`DW{D99zp)Z74b(-!SFGVvKyH`fp8Tsnov{ zp>ut)OsRruq@fwmWXe3b^*Pglh&lI4KMbuZn2!2A+?t)$dpZ2q?;zx%E)x^Z>M1c% z;BW`pE^-$@(cRr$q`lcXbP2FC=ESD*R`&f3vNslF6#J5(n!E|dCA!H;$>m;32hUZ^ zRMGFPZ_}jvfagK1(V={$x|po7ObHERgeKX$1C0iNV3|0Hn~uK&iWp=Ai4uihe(@{t zu@~>*w1aj6u8Dw12twHFf0a`#u0C^*xAj;A)gI-b-q@79ONKH4bp?oDpd2Ctl?KGz zqcd+0k2Bz#`Vb=s0pp5+!V>do_S{@-HQi1=ul? zhOK-D3V~mc#nA3C7-A8X<|z@@9wZR8K3;Sigg%<8vGD^?6Om?WEus?glGi3DCkLE7 zYH96f78h(Pus7K)zV7G_%SeXatAa?u*(F}XS5Q2FISY-_;un;Hs>+T!%YpgPRNw^0lPf1x}Kh`@h>SK>O;T; z%FN(fGG`_HdQ&NXU3Cpy^~_96kOFl^3*HmZbmZq#Lk8l2cMa%jJ8=*uX696OV+zeK z+S~AJ;5}0GtL4yZ=6_^TQN%<=Qvi%Il1!n=hORAx#F32^@pKVgYQ;>j^pcr$uohC$hPJ;@e~>e9VE50PKqE&)~HK_H|$l z_)2D6XQ`y7HgbP zx!f@q^SVVk;%HO~Cx%SW6?nAShWE#d5Do10;vv2LaZwB@|AwpJbnCOH6e8ZhhPu`p zvpd>djY9o#H(rK<82D(xW(?p>-8)5WIXF6KJ^Ugb6gb#vdhIFhzEGRwDEYiwGXJ|f zut)%O`0l}-4_bTRNnPzqRQfE9NM_%qY^rRxL1X@Nsmh8)eO z!FnuzXJ;pwSzC{wxXLNu)H?3>@3~lVFa6{zPzgkUc@}8bG-*Tu&t${+*rHey3EWGj z(=sdA^4Mn5ZJWpIYKVBsJoV8SpGx@~rUj7Kw13VmSQ+98up*n3Ksx|Yd1}Gm5BS*C z)t~nC-v&d!769iOh?+W7wEGi60~fT)CSGCB{oMjOJKcarWyf^#(k3fWZC64FU82Mi=Ew|;r& z6m0l$PuNbwer3Y!o$=Hp`{VfBXY3-I9S65tngW(jW-qh~`?9~ZA2JP96h;)AFcP=a zaPA1SVHALE=-&i$6|Ajnh>N^*4HpeRha8;l9lIObz69>ctFf?iRw>d=&whMvQMNB- zbb<2xMS5+f5#H2k+h)ga;3Kt>KcRug+p*u-6d4O#Id-LM1b}uBj_@Amx$@5p4oWMR z2u?1q4`?Xi(+}g*Jk$sax!O`#yrz?9gXT#Qd~zpvjpgE<&Y9=nZad##i{zl7Em+BH z<`G#Fz5OPJGfm5m#YC^-`oZ~m5P4SYK&X1-l{IJZgikXpV)8yx|K|Ap&DBW|0QqP>;_+%)g-jR+(#zlN;C5i01uDz zN>}mMm;7_U&g=2`DirLXf6qPCqz4#!vx5muJ70qNneXw+z;Wq5q4w-ew1aim)uX}6 z=?6?l8r$P_mLRX1q=hSa{iW022bEvY%@Z8|hmzMf%P9WrLUzskXD@R-AV%fg`-2;E zU)Js^O(^fWs0(4^_B*ks7q)n9-f6mAeAJlO^P}{rc5bE2`ovzwT2G3t`m2sCl8pn} z9QrTw>&x8xotE|(u-0zgS#QtE{x3TWs4+Faj=p`NPN6@qZ2VzY*HT)VmK}#a3N0Mv2&ovhja*XBRuKch{N%7R_Itd$CN%RoJ|{4ysQB#KB~bz8Jy= z(Kj1SQC{@y&H67{*5~7WF1XdOT*!ntXMSW!Yt8F_{QPvS?Sv1v--O-Eltc8DVcI;O zFd*c^O~ZjDfMHHFd5nwG?xO8E%LHBB$2#cqv)uK-B;Z%tksezW;89bp2Zr?h5UT%+ zO3%MEA1Tn(-K&uo~wT(W5qf9 zPNb$m37>Lsl)nG>n``qHIv=X~cNHWI~?@l+RkKWbJbeu02re0#x({4Uy z*|@y5Y|yORm4BJF!rD1ocV07iJ}He)5-TNa)*@Ix*&Ew?S3ppR&d46oXq%ElPv4O` zw+Q^yg9FmX-A0ayJ;gmyCVp)OX_L=!)m%BHP{L5REuNI*Hs$~`6>_(WbxsYhB9&Pu zk6On-C|~{bU0(J<ll&TJuH2BN?uAYoSf`i9%?RM&M$z!IKqT8H+ml@ zMT!&oUzZj&wI+qRbyYifSDF)~sZmWG_@g8rKBGHqg>&<`af7YiR5+HAHHfX;C#oPa z5L-|gaNykn?vhs4OR``;Vbx3+pPXx<3@wPa&$|P3RWQWXZ3D7TQ&kKJ;f6)_H15~? z;P1YyhJl>)y^$T~!W<|6+7S1y$R+Xn0)jLMbFOP<)~q%2 z$K3zK_wKv*%X9YGdw;kv$|8UC)8H-K`L4I`e`ixtG1c0p;KG?0&G=A<&BVc#LQ4?F&{elRQD zK&PH9cw%&TJnr>*&3_jAB~1#A7K~Fi&Sff{*s&yhGZX=(%97PxA@N%Jx!aF=!^!b& zTVqN_2Om}{Zq)g`$+gB}Va~kLEv(|qmB3ooaW(9jIQcDGWi)yQ^G=;xyhL^~@UfA* zv?5f^NTYoPIwm4dKG95YiUoQ8iN`O~C}XvswE~}zj~~R3;**UE)V)5O<|%bqJ&^H%r&GVg4rh)y zZT+|sG3WjL;;u{p$>a>{Qr;d$;!bzP8i+CL(p32t_Yb&FzhEO!wYIn8V$P)eY(qg6 zzD`u8t6+dU6d3Z1H zz%CEM-Z;DY3N{KU*<_A{)#;lsQojh?PR7_u+*1mgxKq4wHT{mx-M+NM9RvClp^jj7 zwN2Xm2~Fd)Iw`^M0&g~=N#IQdR&)H?MeCcsB@IE)5}@p|#qFaDa_?Fzs>AmtiW5&3 zsZawiDZV)oU8fE0bUT=z@(B^WBLD8?L~Ex<;k2$WRY%Gbij4c_k0v7@31dm{1|7Gz z;yfa?_!J>}QJ$dSlBrIr+%merudda!J8UBGx_%UA#ywsVJo6k4xy!cqDPFQt1neCc z{@MCS^d|U=Pdan4jToP3_}E0j3Y+X{27h)HHwhTojjInf~2uacgB4m*L_#H zbtg09dOpp+cZ+OG-eTB=2Pw)@rZff|FY`2Rx7!FB2_5%7=7DB70Fl8vRzw`NQ%jh)s~{cW|cIw29w+Vd|dBvgO6f+;cMk zCVqAy&j&V6N3bbqEYrIT*FsK^`x|$H|shbBMSD{+n^fnDOH^)6fwK&w4jhs z=pP(h$p7fvFGa^$Q~l&)HG$SLXL5>jRK)m%hRRFy0fknM+k)!+bIbdKw>VqrOpe`c zxUMrZqcHSNN_0cXMi~12Uk|^%o4dT6(wl6QpAhFKh}%9EdX<8Nsj_HRK`h41tuI=! z42|~2tn>DzPck#DPYht_Dfv3TM6+{+UAs@EV+!f!StskaL!MSy-Jd@O!_5~o1%K>N zTi%T)AzjK|8xpXh>=&at|0AAPfTh(>peo<-K85pZMnGQg-iNs zE>(pOu@;H-E+mraHw}GW40{^GU3o}VgYYtf*tWpg2!9V z>o2=+)b7X^>V~No{a#>_VaTf-Gco_cqjr?*z++aKucWf{+Fmbd{aR6|i0Eb|nS=D# z{4=)aIhL91Q!ca5HD; zzP(VQwy9vE4NY=a^=*ZB=6i9)G@RbJJFkpbuLkHVN{D2&#azi3pWrBZ9}T=5h=S9fCDmwqyGx3WJ%*r>&K0Bfh^TYVAP&G+Pb zjHUn2P*7t>61`aSPHekzYp(fB!RLN_o34u#>06vKx}cnk+124Tj;SLRkE42VmW^%D z6b<#8lJ&2S{hsTE7`A5ycly1teWW@y-e05gN7VCc`afkV#sF3nlYGmJSqQ&e-FHy64i2(Y zA}@{7)YOhI)|xCR6;q-R0!D69b$TtSxzr1r)l1WSaSr8$7K>!Nof8B5JnflZEr0n` zi%Go%MJe^N!(?Yp>dVLIjFVR4-}SR|VSM}!tZYi5qO{LX$C+r$y7lJi@}{0q$0n+i zSm&CIGe(~d{_kM#LjuUPXc=rLwbj)}L2BVUpK+@C^mYAKr%Q9{F!rtcGsFx9zv2ad zNtigl4Q6(M#GF^ZX=;#T%?Sj)m&l2hazAl4?BEqQKltzN)Q%e>q_f@QwU1QP{56>r zJGP_gF;z<>*KgEoM%`p)?udD%^kh1!x;3fuLw)E5KIwZ~Pa&H`{3REP&@-9;-PzuGQKv)1g7^vkq1b4?CCQL1lWYx$f>$9SN_(dUg4V zch$T{OMTUz)t}T8b8mbT)KwgI4c*om3Xm--Hs6yL`Q*?300Mh)+o@Vmp^YT~Xte@q zEQzFS+>;<82CXW~XHc|a6|x1q0l)@TRn>vlZWNu00uOE9>SSsCE-beBFVc1I$&tZg z3E9~iTAEvKAZrOEP7ow|>Bo?5*CdF>+JM}NRV?Hcw^Y)x%Gz$Mp8~rH| z-TQofTe9gh%|O_Vou_hga*(5cHc3fM{ZXh%{`h{J`N{r<2M9F4>Vku}8j3GqpW#m) zBlFZ0{836+c>4)6X)GtY0poXIo}7BfO_K1LI=ps3IND!<7lR1Q<^}Poc%i`c0_=4t zqys6lR0>#aCeMb_vqz0ZZ!4M}j#8-$RlflHm6#hr@28)U@gWg#a&pp@cEA%30MZKS zg)J`-`%m%%a6hXdC{l>nIcm9u=^^0JR&u5Ep?gW1ahTazy2SV5I3~SwP2omayG<&7 zd#fJ~=xn4Wjjmq3di~NP3gLHxm79+GZ)rPlM!Guv)D!tfEgF>N1SJbBjOJ0FZ)*hH z{3H3|aSh?*r{%-%oB81hA)57b9}U9f;_Y)~D|KiUpQmnW+RzM%I^!r6yfNf>vK?cV zQ_}k?V`$OGYYlo1igo{*j*3r@9%;IpkJEtZzlOjzykLC9B9g)Fa8&Im-S(X<9|_TU z9BoD}^NbZ~KF{SPr>p52V5~e&FlcyN#%U}!bT=Bym*?D1rmxBI%kbM%R;9&6P&-b& znzVr$*DPy2pXdwT^5~BN_jUhhj9_N}a1b%~fEt(RQuM>*_`jr|H&q_~%2^WYKb?@V zfIoq}fmYHz+1ws?0JFzG;ICdS9I zjNn|*fH4<5ejvK;q@#1@G)5?XLMCzHQ<0RLNUgc@>p93Zeiv3-CU6k1spl+Wf1Bvq zp^CY$I}o@}EzvsBNY{LPHIlxy!R={~u+0G0wXt{rQ&Geh}BdiC< zUxI!HXD*k660b?FQ#Z?#bh%0S4bSZelLl@%={PhX(tC#V?vr;;SA6C}ZhqhvyW`B+ zbmn|+l=T@ZsUC9yRMrQYQHw%+H#+jqb$-{JEv)A&%9(VVB))}Jj8Ws0C zsj_vm6}-<)WelljnQ~Sx8M`=LskZIFA~tBfcN^PyChz|$A<3JP7}G=H4y zx6FKwdi4?0rt_|h4yDeY6D5Y#;YC_44|Sr26>*sT8~4;% zv)s^4T)e!S-?PIuY%M@j@KaI1tgTNh#!B6aYCHj#@5A=tK+`LdfGx0ZQ5M^as}1*# zKU03t>T`-i$tUet(PVBfkfYqS{8cvliJE^Vb0TrvIkb^a;H%07sV|A@VQz{ZkO=c> ztB@@Lh#9I;CabIKkRgC(ebG%f)7o#)Gjliw*38H!Scv6 zwV%H#2B*T8O&1*=+#hhxP}PZ`7s5t_pnwf0@@SiKzw8%T0aX#!q37%hz~eJeQfea_ zyvih4X@F&X7URO=NB;y}zn6 z9Jjr1Ux0FQ?C^4{51zM%`T}6KA=`&=&mTZo0H{|f<(5TzATg9Vr{>qnjJJO@8+G7K zIT9!E*=-N=`K*}*F8ex3dLB+W_Si{+B}#F(f`EXReO-d?C3BV~rQ$RDGlGoF9G!mrvviT~+Sxi=5gVgbqgisU2fDDKOGkdzwlnMqC1Jjar}Y55BSXb?13`d%0P4YE zCOTSL;5%een5$6{RX8lgAO6JR)_jwwhsSFWT5)`QoRUI|f?ZW5lAZYRyZf5j+67|o zz!DW5C!@ll8+9zD80{Y1q@*cgGk0S*=MQvys{ zZ@N`?Z`wv&;JQ3Gs)D%=xKzY%jYA1fg@}__6oyKU65U?c{QNwWbg|gExIpA*r>m>` z;-PB8RWQ+_>R)n*?2)-~e3IeZ{oucs!R#+V@Je&XTEp0Q0m3VQ=If!Bwbu$W5R79! zp49>?1xkuA952)^r&w*mu*x&ey*tt1<_KF!e3!hjvQkSARuyR;;(c}kg$b765nP{T z2Ri)PFlq17I-|5bjzS_1JDK~ky54Ljor%CeJ2mu3!(bWLzpHc!dO?}_&&4uR|{MTb-0m+Dnn*Unu?}jfc(>FudZ2=9g z20N9SS?@`O8+3Q9lb}!vYvJF}&=^E<4k0z%e6#KuZ^Q34FiA6m636zh^~h_FDk@U) z44_`~wA7C;TJ>Po=NxvbI3D?F3rovmP?{qG?qlkBedaF%AR9z4f*;~M)eKjDUfyp# zIg)?gx^nTe5el7=wzii3BSF9|Wiebv z(t${Qq@sZBD~;TtQF)sK@h$=$Q|2lM&GGu7`|xX$jw}B@WMj_Eg4|(DfPOM0{c7H7 zkoVIrNeUL^i)DmkZy#-19cl@LevAxYmxi0L8`1l-2_oLGqzl(>MROourM3e>*}p#- z)1`c&KyJInPvrBOZz9u1e>XyuGSd~|=I>11DpQ+__UdXCTBPo>DjcI?yxb-!8=`i zfUrnQ{}#Ou-oeGm2)T4It#{*=m{2=mf>-I-dD=ryu+w+)4dwVmP26I6z-~;uulBJH zzb@^y5Pdo|efL4DZq;cpOYUj&WN0uMXDx-1mZNojt>5G9`D(oAQ0PVp1G85)^4m-mrQ6xm94b6KAlz=c$`(`p8Y1JNH17`bN~Gc zA@spcGVfJQrHdm~8A=s}o59awD)8ES*Q71=hP@w_X}tjk(JsFKHO}cZb-S>&0>{7K z+228Du5t+$37e-3mYQeF-I-Rjt5Q*o8&OlueQs}Gw;t`>t$NAC(_*iDEloH}(8-b0 zg*wQOD1iBiPLR69w%pj?lhF*`v|!La%6)iio7PRyd%flYoxvRdykYjA8m2j{O7qk_2E&*m0gs(6ZVHd7;G&BhN#8W#l#S}5;ZMWUONVmo7oHl?+;r&OwbSCf}8K)sAn<2{!N*$Vh#mAkz{JINmfD6Q}5f- z%x-n-Ts>)AM`uY1!o0ZI_4Kh$@5;Idp7Wk#P4=VRlm&@#%ga4&dMbnj$O9jmPriOB zV|Z6gx7@U#Yv;L>R_DTc_9Ev6;7i|}zZ;AFY?&LrPbHtlq zJUO8hVIyO_{8nmuXKs75s!hDV=Nr>*I^-^A;=d1A{VzR4|3+PH#V1u$Cz2v9)GDOX zYA)C`-q5nCk1CqCv#?q>5_`UJxk@WPiZM(}r(nHUJF0rpra(6eZk(sze$ z9=R`z2VIpzw{Wjt|M9lrozHHx;sc>Skv3jSLR}tdukp)iTKd^0>rts(+28M2{<(Sn zV7P0hN+UeNBj=6K%M7f2-V3NS0wQ}X>h{oYLD;APh0&DEOL_VRNi5$DcG;(rH;l+|R7)GJE|7>KZ_=++m(RK+OUuEMws2|nA{i~p z8mCbn6&?iNoNSddM=e~>xX|*7KM0$jaT8j>Sb*S>XcX5nl>=YpZ$FyArv)Qz%_BWo zTX{8Bf(J@Pnk;wm;l3Jy>eTB*uIMQFd^O3KYk1{0771BLBP5*$&+hgRqSyvfWN2xi z2&qTfsFsD7c@0+%_yd^m^T@giOWV?!c3e~r^29~{WVk0J!oDA_!9(0Sr60_~1-9w= z?PT{aCPq2lGDPCkL*}JdkQcdPTXm5ix0nJ86>IN^j%71o~WnvWyHdrllc1%g<^C<&Ilkxsdq8V6J?N) zp7megr#-W~fWp7`xQi=a#Sxd69BUODY11UWqsWi;H&-t;U%Hubq3#0w6eXq7AX&^Q z)8AQIt)a&o!`<}9*TuNABv0b543Hy@)`n(Hk@*w6>gDc3ro@@ae5THoFvi{E92OBt#yplJ$a;D&GB+O;b{diBY}y8$(-9(?~*#aDYje*Z&-hqPPvRR}L8 zw!V?;G6^s8FnaepdSyEq=9kaLrEPRf9bbL#=f|ti_CkqWfQIy4!o;2^ri_p0Du0g+ zi8JqYN4Ya2U+cK2^}z)rezcYQmtan$2c;_k-TbUC_oz;Qn{C@r^q11iD-PTbW-u3g zpAlp}jHbx1dWmlnlC4ocj5V-;ypmQWk(0P|lucH|J}35vF65I{tWPeU*D>v#_&*?x z9gEyU?Q+YSqe>I_@$f&On2mx(Byg~Y3_PA+8i+;i5L$~hEf<$1@*c+Xzkidl8(vhB z&7kn0x;XIXLoPMSX^2YS^Qnr8kt;!OspE0q(T6##&5dAE7BVva;5)!lZwZ+f65nZ(?8A!%eQBBP`PqZfkSgbX!K<+Qu@V3q`2LvW#W5oyZFk>1*A zX=yn;JOtt)8!KyYN3BLl7qp?oft#x<;^-+&bT;(7{tBz&8jn@dW-Xv9kluKV{7tH4PGOrYU{1Pm^q zM>#k;IyyLP&NQaJLoVLf?wFVuz=wt*@>ht*8->yCyGb5`2K3M!OaT&Eyu7?TMt|7= zzXzyjf~HwoMUNFLU!-mWzorQoY}~zq1QlRQQd?UKMp6jfwfE}D-g<8RTa)pIh6Z@$ z7iMPffy;jTwlhT8CkI>lO`e#`R@hd^h|vUYPO0^HId2eyh{I>>4vn{H=I(Fb?0~&^ zU$ICX;TXR;nTGzMvun6c76Om~7`ciH3kwSgvy+9iwIf%^DiD=`qW^bA{2T*0FB8*y zXjHAt7p0WYL%!ZXx6(a31dnB4F=Dd!^HlQpH>VZQ2*y?_asE-JkCcqe0i0rhs|uMU zI7g7+^1OsR4JE-2&1Yq06=DwDtI^4@urPembP>l+_j*)V3q38WPvzOODwEy>-XIIT zflKLNcLb{_`j+EzAMp6a52hRw#N713YZp)w$04T#6P{X=Qe**0>iG5zEMfC|4H54n zZtlv5Vw7q+I$+{x+HS0oaC@1SH@3E}uDYs945(Y+!_4%&NNaD*IO=P%kPKU_vxgsW zNx`V6&UJepnnsQDYCAuAadXoa6VuB1b^v8S8EB}Zs~bUM>Sx4l1vxV$IRf{kc@u%L z`XgbwBsEpr&~Of94N;6@DGA8MMj7Vk=hxoW))~prJ8iSHva$lRVPWCp5zgey%na~` zfw$-e<=akb;= zkwF-0&kti1=vVUqP3Ng`;^QHgyu5sE@%yT(DwwMPt>6W`Vd9JJhCg|Gd!L=1>HPRs zT3Y(^=g)V}LZUDKwMUu8ueG)DrPAYLcRC7VP2ldqhT8w6nhLRp!tKOe) zR?4!@^M1z;dhL@A?MO@kB{=zCUO`X!!cJ-?(EQ^ zcX6C?1dN!;c{Tp*?{DsO1qm=HSXx=_?Jr#7CxF%6^l83Y=Y8x?6=6x%LG~GaCW};Ewm5x7Ti()Qztz*zk)eJkYO?R{KX$2sdDcv zhX4Nk8yt$xfQWcA6Oe$N zf6kD-npf+D#|*ewp_%7q&wwllIWHW`qXDuH0pc<2oBkp&b4*|vLV&NCD0C*%3JNd4 z=#M_O20E6T|sIB)1xE|@ETviT@% zFwmor9&*^45o=sg-I~JunVdbVh7pmia-%smjq<%T+MAI_t#WAj_L;x^5l4|!)~H+g z&|kaNGYi^s-%h&~N>>jLm!pM8yoo`9fnv&PAPmbH0JUFts~ zl>%?Q%qpD&RaJc}8zqy&9KPGr=YjX7gQ;(m!n*Wra#Gu60J@xvjBMD_SwXvZzj9;h z2T(;v4PJO=2QqWLU4Q zt`1D{6~d+8?0s}}gm%h3^w_i@JkXxvI5g2t{IcM1+;3QSn)Xilh8Mdz;pJx8?`MVX zc%*v(H&rk(X=-X#n0|Gzw+}fP`3$65(!so^9|3{sTPd3flH%2>loigvx_I#n#8Tka zrNd1L4ob=AJgtVvX3q^idrpbQl8=b(1x(F!KE|xuS@IfpJFjunVnvO6-flI zr+zcobve%TiDUOSyXjMQSDpwhDPG1pV?-OnTT|m`7C5t3UOYUkmhg9b5xAj^z$b;J zPRp24^x|WDxWQw;_@VPxr-u_>>=8%g5w4M+rI)PCz#zI~rT7A@uOKdBW6oDY&>up& zI|S7HEopz>2(|o$6}(tA_pwD&t@AnH+W$!xr_CxZ26i)>xVShA3kyI0 zKtsu#4s~GJeuZ?>d-KhH?33H3d`K41|8V-D(Bss)n9(Q#m_%YX{XBZh3k43uJlx#u zgK8PDm^f3KYi?0FlpHBn&Ct$7ZlX3-r&%k$lr;8RRuFD}3pGsY$3vdj@$J|~3U`@? zb&2jhYAYFzW-kxMUxU7|?4X9smCkCZ*cd36Z_-)gBl0T3?Pekv?btczw+_dO5a)~_W817SJmi22s7;pypg zpY_d6MpDv;uq%EU8L7(3dI15%@-HoJ%JVs5A6X@(bkLE2Y~U}L&|bQHIl1B?4^%Cu zV4VbEQpoC3BG2!)0*yjaUsZ>(1D*XuCVx5TPL~r7iISH%%hXCWJ%Hv^WJ~Pj)2+J& z;zbCbrw*~&VCRO7er|3Klu5!5e%Ne5X(l8pN_edcr?(ses&VkGgtJ?i$&#I|cfd5F zu%ra>(Q^NHd3v70wr6By1g6VFjrr8Qyj~g^+nF6+7@>GR7t*Zcz(}s$@atvBm{YZz`U}u!HR6DVjk7`>pd^Z5$#x= z6Njki1Z`FF8i42!$>QVVBc7exR)n;-WZ7atqiG42u6&KVF(Q|P(V4ruyMTfN{_R0S zLjx-(H2f`6x$N&?;0aqKw3Ua4$HCxFh_Rlq)82+74M0-2vbeYi)as?BZ3a1zbCtrv z0B({eP=8Qm9pKx_tRCgP^j+jK%Gw$f2VfHm7kEDkSx8}YnqX&u6C7MTeppr=gQDl^ za@i)R37{dIPcq&nCntlu@0~vy!X=H3UhtUDi*>rYyD@O&%E6sB{ysQOfdxpCnVCT3 zHa_j}g5CsbLJ9B_tYW!i9JETRa%cKkbBb*Zc>17~Zh>@ie|sC_{kKkpj)vbr z;^D)GYHD%WpUSV;UK9iMo~@lBI0sXTjDC&oegQu=wLUsJ3R?w;YGKqvB<5YG14DUu zm^EJhE^YE3U3^lW65q%4=btKkcz)n%ZJ|N1|axOnLkEEtG2}>hTI{Ay9@K z=j-YA+`@vYj?R5JTS4JjhrNqS)W2&baSG}XBhU54fIJ{6*#_cJ)A8xoB(Q6syeSwM zc={?9v;e$;Y~mH1ma%!M!ldK?dkz*L)GjqFfG}>L+-GZLwLld~d%Gv{#_K)gtL~@( z$?aAgrUvj1gy2()$&hFx55h~-o6hoIU=RpitvXs-pIlI66Hj3rq5Rjui5F>Q3?`ir z`kWe$IN(vZmI!(_c0n-%wxy1mYa>XIE>`#PHZ`);kuXzHB|^vz`3Q(sd1VFN|&qG{@ zgWSe^tLbDD$`|*5hrYY(ci6#6b-z6>J|CTOJ#j{(lA z#zoXMH0)s0RaS{;W{?rTg+;Tmw=5b~tl{Bj%q%PrP!v85pGJDlGNfW~vt`X)Qsq1-?`n|6ds&@-#nxZ?xaB9y8d|vgQ#KbeL-k=nUuP;u>mb zn%+j9#$T$!D=92&=r7L(j7k-i%qQ#w#H#sfFheVp@Hu!Q;sD7q z>v6$$W5{Sgcw?;^)%a7(7KO?%(0m2Yq_xrBV)1VnN!p$8ztloD+G|&^CxS#$p{t>) zGy6LUw3`D1PbPIDpE@&ZU|bGu5*M)A!n z4Cz_b=xF7RHs6Xh6SgjZdZ^Pk>ZXn*xBU|Iznc`V7Z>zeOa{?B(be@@>bcr(3gH%cgVW0Lm#`CVc~-pwG%E3HUsWPoW}YZ zj!I&opWu)h5D*a9Rasr#`T6r$4xuw&?*AMSj#F=;R6-#GnYA*kJj2HMRUz$D3k&xH}|lY1M@`Cww9I_EC97?XTav- zf+H!TBqb$bSqWZ+TKqEzKGz?o+>*<9LNW-;$nsZhz^BYA$~P_|Z7K&fR}cmEg45;E z4RfY_B!H&kbI4CiO`RMZY~_Jy1wu#VK4-2Sl5ev)E~1+qhk!V)ZNbdIUxuQ;h5bpR-dC@*XZRGBSc|!kmg5 zECDL{!&zTPhlfd`b$IP8Eaql+_@D`4)8gJ|@JCQ#0|5}#O@%?g>~p-93yQ*54f}?c zRdsoJ!SA`AtE=xY?QKj7v#|v#ECmN&(J8lOJKes3(&&Q%@8J&!4*)cZH?Blh23Wdu zSbYwrT~5Ojf|29q=;(U0cR*N+QD|&oMuz$Xawt(>vhjaf5YD9Feid`GfE^l8N_YgQ z@~>?Jgd;!2jK|!InuMb3@KgDT5+BT*9#?OzT$uaof?5l)v1ZEU1v$L~ZU0q4r z&;?))EuXC-lp&%Ihp~W7v=rK?%oU;vSWCgC6cD$1G;^8fwCRxbb%*_5n#_oZ=wJ|l z(?c~NtJmuGI#D9C_b(-n)-5=#$5>jg!POqpsNLR=Q(9`ABamsncbyLb4_rLXcZ8KB z*E7MDU2Jby6;LurzN()G{7aEO%z`s32=wwMuPOGzv;Y(;L^fXy4!Kg^q7F0!V#O@7 z-9in$)H5STC@0_xa5f-*NsWuUWi`ruqP|{q1f>u7bSC8#`;%x?(g zP8|Slf+78f2Mwn?MBuN3)Kv>m9iUc9OJkElC~M)})4Ze)!gT=x@_)cCB1)a8*3d>m zmsM~N2Cr-%;7PUqF0HE*wN2>zn&IW?37Zy#0ko?1=FX|FDVbsQh2(NcMdbc{ohQ%p zEC6mzlw}3AvYnOH&?#PEKw#kU(Gi@!v<9GEMn;Bu(ZD{^#>aB3G2k}stl#n`?aJUpVE?%8F|}8{*Yt^yjoCDg_|;pMyPYx8F1EG7*a4??~Rq&{%Zr^ z>h!iO834$R%%ZjI#JWbWY?b8L*!JvlzbcYBwt?yX=h3nhw6y=ZcGW@jhf0_O{BB$Z zAPRg+?!#Fi^d0^-jIGWemt?(nufD1({`^a{R`3f`(@!J+ot}C+-uXT-a4oUd=9NP$ z_P>Xxabv7&YI^6vZ)64tIGof12O-fgFxd2wCyQELZ{tTcocBGE!;-850)sO*u8_iD zkPu(^_K5E84-fE^&VA?psi-I-I7c!0`*BmWI!~T_7?*qjA+Zi8oGn&WvEJV@hwSg%%K2)=dW|Vo zqhG^9LIkEH{S}rtRCBIm1zhic3m<+!MTheGVk&VwIFJup3-Ix18NoW9l!QbA4Q?oh$cbQmeSHWlR9HAMp*7tKxd#y*o>qfv*|VO@ zU2mX)29&ue!_b*69^@+`g6(pEm%~i?ACZf*+C@L$9RaEpC$j}a$hSebEe0kBr z1O6fbg7$D=9|KVl0#^c3SpH1R%p6~P?fo|bJF8xk=Qym4(zBP`+5R;RU|_cIA15om zf)32e%7UyTa_<*Q{Qk&lLecxEsBfp>VE^sCG8$}2Zr;4f#|KzgAkve&j`sHX#l;UG zt{!zrFd-)=p9NxFWMt%PEG&;bTCfGNJvHqx+6ERTj~2&WaHe7o5@-3Q-*5Lu*A*O71y^>0l7&)cFTkzop{20R1Gm*n5mzm;WG zXCNN9fjm|<&c@v5SRK>ZRVZb-Or7K2Acn3IGE$q zuCt29i5<4Gky@eKxW`P$woN{QBifOPOuy6-ZZ6-qo=GfDwl` zm@iGwNS5d|LfK1DP>}mM#a#|~j7u0A)h<`Bp&{Pf=WQK_W=xv^D%>yKi>OtoyuVa|yu{kVq6|Lc1Z!ZG3vPcH z)QI+rFF>zU&dCe>|8@?_{|fXpq&EL&e-57GV6yMrExlsJ3->|ENj*jvOB%fSA06@* A;{X5v literal 0 HcmV?d00001 diff --git a/Bachelorthesis/Content/Entwicklung/IdeaConcept/Algorithmus.tex b/Bachelorthesis/Content/Entwicklung/IdeaConcept/Algorithmus.tex new file mode 100644 index 0000000..0938080 --- /dev/null +++ b/Bachelorthesis/Content/Entwicklung/IdeaConcept/Algorithmus.tex @@ -0,0 +1,124 @@ +Der Algorithmus wird nachfolgend \QuoteM{MystMail Algorithmus} genannt und ist vom Grundprinzip dem Onion Routing \RefIt{onionrouting2} nicht unähnlich. + +Der Algorithmus bezieht sich allerdings nicht nur auf MTAs, sondern muss auch auf der Ebene der Kommunikation zwischen MUA und MSA eingreifen. + +In ihrer Funktionsweise ist die MystMail eine gewöhnliche E-Mail, die eine Art Liste von Relay Servern beinhaltet. Die E-Mail wird also nicht direkt an den schlussendlichen Empfänger gesendet, sondern über mehrere Relay Server (auch \QuoteM{Hops} genannt) geleitet, basierend auf den kodierten Informationen in der E-Mail. Dies ist der Anonymisierungspfad. Damit dieser Pfad selbst weder für die Hops noch für irgendjemand sonst sichtbar ist, muss er kryptografisch in die E-Mail eingebettet werden. + +Die sogenannte Liste von Hops ist also keine Liste, die in Form von Klartext als Header festgesetzt wird. Stattdessen wird die originale E-Mail inklusive Header über ein asymmetrisches Verschlüsselungsverfahren mit dem öffentlichen Schlüssel des ersten Hops verschlüsselt und fungiert jetzt als Body einer neuen E-Mail, die an denselben Hop gerichtet ist, gewissermaßen die erste MystMail. Für den nächsten Hop wird das Verfahren mit der soeben neu erstellten MystMail wiederholt. Dies kann theoretisch beliebig oft wiederholt werden und hat zur Folge, dass eine verschachtelte Verschlüsselung vorliegt, jede Schicht mit einem anderen öffentlichen Schlüssel verschlüsselt. Dies bedeutet wiederum, dass kein Hop in der Mitte des Pfades an die übernächste MystMail gelangen kann, da er nicht den privaten Schlüssel dafür besitzt. Somit kennt jeder Hop nur Vor -und Nachfolgehop. + +Ist nun die schlussendliche MystMail mit der impliziten Liste von Hops vollständig durch den MUA erstellt, wird sie an den ersten Hop gesendet. Dieser entschlüsselt den Body mit seinem privaten Schlüssel und erhält die nächste MystMail mit Informationen zum nächsten Hop im \verb#To:# Headerfeld. Diese MystMail versendet er über SMTP nun an den nächsten Hop, welcher die nächste MystMail entschlüsselt, usw. Die MystMail hat jedoch ein dediziertes Headerfeld \verb#X-Myst-Mail: 1#, der SMTP-kompatibel markiert, dass diese E-Mail eine spezielle E-Mail ist. Durch den ganzen Pfad ist dieses Headerfeld aktiv. Gelangt die E-Mail an den schlussendlichen Empfänger, so entschlüsselt dieser den Body der E-Mail ohne bereits zu wissen, dass er der Empfänger ist. Erst nachdem der MTA keinen \verb#X-Myst-Mail: 1# findet, weiß er, dass er der schlussendliche Empfänger ist und kann die entschlüsselte E-Mail lokal über den MDA zustellen. + +Dieser Algorithmus wird auf MTA-Ebene durch das \verb#X-Myst-Mail: 1# Headerfeld ausgelöst. Ist dieses nicht Bestandteil des Headers, so wird die E-Mail nach den gewöhnlichen Regeln des MTAs zugestellt oder weitergeleitet. Die Art und Weise, wie dieser Algorithmus auf MUA Ebene ausgelöst wird, ist nicht spezifiziert. + +Sowohl der Verschlüsselungsalgorithmus für die verschachtelten E-Mails als auch der Zufallsalgorithmus zur Auswahl der Hops wird hier nicht spezifiziert. + +In chronologischen Schritten kann der Algorithmus folgendermaßen dargestellt werden:\\ + +\begin{minipage}{\linewidth} +\begin{mail}{MystMail-Algorithmus Simulation}{MystMail-Algorithmus} +MUA (Sender): empfängt Liste von Hops von einem zentralen + Server +MUA (Sender): wählt aus der Liste einen zufälligen Pfad aus +MUA (Sender): erstellt die initiale verschachtelte MystMail + für den ersten Hop +MUA (Sender): reicht die MystMail an seinen MSA ein +MSA (Sender): nimmt MystMail entgegen +MTA (Sender): sendet die MystMail an den ersten Hop +MTA (1. hop): nimmt die MystMail entgegen +MTA (1. hop): erkennt den "X-Myst-Mail: 1" Header +MTA (1. hop): entschlüsselt den Body der E-Mail mit seinem + öffentlichen Schlüssel +MTA (1. hop): erkennt, dass auch dort ein "X-Myst-Mail: 1" + Header vorliegt +MTA (1. hop): benutzt den entschlüsselten Text als neue E-Mail + und sendet die MystMail an die Adresse aus dem + "To:" Headerfeld, den 2. Hop +MTA (2. hop): nimmt die MystMail entgegen +[...] (wie 1. hop) +MTA (3. hop): nimmt die MystMail entgegen +[...] (wie 1. hop) +MTA (Empfänger): nimmt die MystMail entgegen +MTA (Empfänger): erkennt das "X-Myst-Mail: 1" Headerfeld +MTA (Empfänger): entschlüsselt den Body der E-Mail mit seinem + öffentlichen Schlüssel +MTA (Empfänger): erkennt, dass im entschlüsselten Text kein + "X-Myst-Mail: 1" Headerfeld vorliegt +MTA (Empfänger): leitet die E-Mail an den MDA weiter +MDA (Empfänger): stellt lokal zu +MUA (Empfänger): ruft E-Mail vom POP3/IMAP Server ab + und sieht die original E-Mail + mit dem korrekten "From:" Feld vom Empfänger +\end{mail} +\end{minipage} + +Auf Basis des MTA ist also eine Entscheidung notwendig, abhängig vom \verb#X-Myst-Mail# Headerfeld. Diese Entscheidung kann folgendermaßen dargestellt werden:\\ +\\ +\begin{minipage}{\linewidth} +\begin{mail}{MystMail MTA Entscheider}{mtadecider} +// either relays a MystMail or delivers the inputmail in case +// it is not a MystMail +function processMail (inputmail) { + header = inputmail.header; + body = inputmail.body; + if header.getField("X-Myst-Mail").notNull() + newMystMail = decrypt(body); + envelope = createEnvelope(newMystMail); + send(newEnvelope); + else + deliverToMDA(inputmail); +} + +// creates the Envelope that carries Meta-Data for the +// SMTP transaction, such as "RCPT TO" and "MAIL FROM" +function createEnvelope(inputmail) -> Envelope { + from = inputmail.header.getField("From"); + to = inputmail.header.getField("To"); + + return new Envelope(mail = inputmail + , RCTP = [to] + , MAILFROM = from); +} +\end{mail} +\end{minipage} + +Für den MUA liegt folgendes Verhalten vor:\\ + +\begin{minipage}{\linewidth} +\begin{mail}{MystMail-Erstellung (MUA)}{mysterstellung} +// creates the initial MystMail +function createMystMail(inputmail) -> EMail { + hops = getHopList(); + path = chooseHopPath(hops) ++ inputmail.recipient; + newmail = inputmail; + + for hop in path {Alle Informationen zum routing sollen in der E-Mail kodiert sein. + if (hop == path[0]) + from = "myst@" ++ inputmail.sender.address.domain; + else + from = hop.prev.address; + to = "myst@" ++ hop.domain; + body = encrypt(hop, newmail); + newmail = EMail(From = from + , To = to + ).addHeader("X-Myst-Mail: 1"); + } + + return newmail; +} +\end{mail} +\end{minipage} + + +\autoref{fig:algorithmus} zeigt schematisch den Ablauf des Algorithmus. Die initiale E-Mail ist 4-fach verschachtelt verschlüsselt und geht über 3 Hops. Jeder Hop entschlüsselt den Body der eingegangenen E-Mail, benutzt diesen entschlüsselten Text als vollständige IMF-kompatible E-Mail inklusive Header und Body und leitet diese dann an den nächsten Hop weiter. Der Empfänger MTA erkennt, dass kein \verb#X-Myst-Mail# Headerfeld vorliegt und reicht die unveränderte originale E-Mail an den MDA weiter. Die farbig markierten Pfeile zeigen an, welcher Teil der MystMail gerade weitergesendet wird. + +Anzumerken ist hierbei, dass abgesehen von der originalen E-Mail alle Header das \verb#From# und \verb#To# Feld verschleiern, indem der Benutzername \verb#myst# verwendet wird. Technisch gesehen ist es unerheblich, wie der Benutzername definiert ist, da dies das Verhalten des MystMail MTAs nicht verändert. + +\begin{figure}[htb] + %\Centerfloat + \centering + \includegraphics[scale=0.5]{Content/Entwicklung/IdeaConcept/Algorithmus.png} + \caption{Übersicht MystMail Algorithmus} + \label{fig:algorithmus} +\end{figure} +\vfill +\clearpage \ No newline at end of file diff --git a/Bachelorthesis/Content/Entwicklung/Methoden.tex b/Bachelorthesis/Content/Entwicklung/Methoden.tex new file mode 100644 index 0000000..dbdb4e7 --- /dev/null +++ b/Bachelorthesis/Content/Entwicklung/Methoden.tex @@ -0,0 +1,15 @@ +Die hier beschriebenen Methoden beziehen sich auf die wissenschaftliche Arbeitsweise, sowohl auf theoretischer als auch auf praktischer Ebene, welche in dieser Arbeit Anwendung findet. + +Dem Geiste nach wird versucht dem wissenschaftstheoretischen Ideal aus der \QuoteM{Logik der Forschung} \RefIt{popper1998karl} von Karl R. Popper zu entsprechen. Demnach ist die Arbeit als Ganzes vor allem ein Diskussionsvorschlag an den wissenschaftlichen Apparat. Sie stellt aber ebenso eine Behauptung auf mit der Erwartung, dass an derselben Falsifikationsversuche durchgeführt werden können. + +Das Wesen der Falsifikation ist hier allerdings etwas anders als in klassischen empirischen Wissenschaften wie der Physik. Neben der logischen Falsifikation, die sich vor allem auf Argumentationsfehler und Logikfehler im Allgemeinen bezieht, ist die sogenannte empirische Falsifikation im Kontext der hier aufgestellten Behauptungen weniger exakt und die Trennung beider Formen weniger eindeutig. Konzeptionelle Fehler und Schwächen können sowohl a priori, als auch a posteriori erkannt werden, da die Tauglichkeit des vorgeschlagenen Systems nicht rein formal bestimmt werden kann. Viele in der Praxis relevante Details und Faktoren wirken auf das System als ganzes ein und machen Falsifikationsversuche schwieriger. Mögliche Angriffsvektoren werden häufig erst entwickelt oder entdeckt, wenn ein System bereits eine Weile in Benutzung ist. Gerade deshalb sind weite Teile des vorgeschlagenen Systems nur sehr abstrakt beschrieben. Somit konzentriert sich diese Arbeit mehr auf eine Idee, weniger auf ein vollständig durchdachtes Konzept und kann letzteres auch nicht leisten. + +Die genannte Idee wird im Zuge dessen argumentativ unterstützt, sowohl im Rückblick auf das existierende E-Mail System und seine Schwächen, als auch im Hinblick auf Systeme im allgemeinen, die ähnliche algorithmische Methoden erfolgreich verwenden. + +Auf dieser Basis wird weiterhin versucht nachzuweisen, dass der Algorithmus im Kern implementierbar ist und die Proof of Concept Implementierung zumindest die wichtigsten Anforderungen aus \autoref{tab:FunctionalRequirements} und \autoref{tab:NonFunctionalRequirements} tatsächlich erfüllen kann. + +Die Implementierung wird sich auf den Kern-Algorithmus beschränken und ein minimales Testsystem zur Simulation von MTA-Kommunikation beinhalten. + +Bei der Entwicklung der Implementierung wird eine abgewandelte Form des Prototyping Modells \RefIt{swprototyping} angewendet. Dabei ist der erste Schritt die Entwicklung eines Testsystems, das ein verteiltes System simulieren kann. Andernfalls ist es schwierig, in kurzen Abständen Codeänderungen durchzuführen und deren Auswirkungen zu überprüfen. Sobald dieses Testsystem steht, wird eine existierende SMTP Implementierung ausgewählt und diese ins Testsystem integriert. Das Testsystem beschränkt sich hierbei auf sichtbare Laufzeittests. Ist diese grundlegende Funktionalität gegeben, so wird der eigentliche Algorithmus injiziert und ohne weitere Iterationen vervollständigt. Erst nach dieser Phase findet eine Reflexion statt, die Refactoring oder sogar eine vollständige Neuentwicklung zur Folge haben kann. Der Dokumentationsprozess ist ein fortlaufender Prozess, der in jeder Phase der Entwicklung stattfindet. + + diff --git a/Bachelorthesis/Content/Entwicklung/Realisierung.tex b/Bachelorthesis/Content/Entwicklung/Realisierung.tex new file mode 100644 index 0000000..454a720 --- /dev/null +++ b/Bachelorthesis/Content/Entwicklung/Realisierung.tex @@ -0,0 +1,5 @@ +Die Realisierung auf Basis des Prototyping Modells durchläuft mehrere Phasen. Zunächst wird ein Testsystem entwickelt, das auf Docker \RefIt{dockerhp} basiert. Dieses Testsystem wird es erlauben, mehrere MTAs miteinander isoliert kommunizieren zu lassen. Dafür muss ebenso eine SMTP Implementierung gewählt werden. Nach der Entwicklung des Testsystems wird der Einsprungpunkt gesucht, an dem der Algorithmus in das bestehende SMTP Protokoll injiziert werden kann. Ist dieser gefunden, wird zunächst der MystMail MTA Entscheider (Code \ref{mtadecider}) implementiert. Dieser wird noch nicht die Logik für das Erstellen der weiterzuleitenden MystMail beinhalten oder das Weiterleiten selbst, sondern lediglich die Entscheidungslogik testen. Danach kann überprüft werden, ob das SMTP Protokoll immer noch einwandfrei funktioniert und beim Erkennen einer MystMail der entsprechende Entscheidungszweig erreicht wird. Ist die Korrektheit hier verifiziert, wird der Teil des MystMail MTA Entscheiders implementiert, der die Nachricht, zunächst noch unverändert, an einen vordefinierten MTA weiterleitet. Somit wird das Weiterleiten zwischen den MTAs getestet. Ist das Weiterleiten möglich, so wird die eigentliche Logik zum Entpacken einer MystMail implementiert, inklusive dem Interpretieren des Bodies und dem Erstellen eines Envelope. Nach diesem Schritt wird eine statische initiale MystMail per Hand erstellt und das Entpacken sowie die Weiterleitung zwischen den MTAs getestet. Als letzter Schritt wird die MystMail-Erstellung (Code \ref{mysterstellung}) als SMTP-Gateway implementiert, nicht als MUA Erweiterung. Dies geschieht aus Gründen der Einfachheit. + +Nachfolgend werden die einzelnen Phasen der Entwicklung beschrieben, Entscheidungen erklärt und Probleme erläutert. + +\label{section:realisierung} diff --git a/Bachelorthesis/Content/Entwicklung/Realisierung/Implementierung.tex b/Bachelorthesis/Content/Entwicklung/Realisierung/Implementierung.tex new file mode 100644 index 0000000..e57abbb --- /dev/null +++ b/Bachelorthesis/Content/Entwicklung/Realisierung/Implementierung.tex @@ -0,0 +1 @@ +Für die Implementierung wurden zunächst verschiedene SMTP-Softwarelösungen betrachtet und eine adäquate ausgewählt. Nachfolgend werden systematisch, wie in Kapitel~\ref{section:realisierung} erklärt, die einzelnen Implementierungsschritte durchlaufen. \ No newline at end of file diff --git a/Bachelorthesis/Content/Entwicklung/Realisierung/Implementierung/Einsprungpunkt.tex b/Bachelorthesis/Content/Entwicklung/Realisierung/Implementierung/Einsprungpunkt.tex new file mode 100644 index 0000000..50bf9de --- /dev/null +++ b/Bachelorthesis/Content/Entwicklung/Realisierung/Implementierung/Einsprungpunkt.tex @@ -0,0 +1,15 @@ +Für die Wahl des Einsprungpunktes kamen mehrere Ansätze in die nähere Auswahl. + +Der erste Ansatz war die E-Mails kurz bevor sie die Queue erreichen, im Hook \verb#queue# abzufangen und die E-Mail manuell weiterzuleiten, beispielsweise indem über \verb#outbound.send_email(...)# eine neue E-Mail erstellt und versendet wird. Das Problem hierbei ist allerdings, dass der \verb#queue# Hook speziell ist und man diesen nur vollständig überschreiben kann, nicht aber nur zusätzliche Logik einführen kann. Dies erhöht den Implementierungsaufwand. + +Eine weitere Möglichkeit wäre gewesen, an mehreren Stellen anzusetzen, beispielsweise bei den Hooks \verb#mail# und \verb#rcpt#, und für jede Station Informationen zu sammeln, diese dann im \verb#connection.results# Objekt zu speichern und dann zu einem späteren Zeitpunkt eine neue E-Mail zu versenden oder die bestehende zu manipulieren. Da dies allerdings erhöhter Aufwand ist und einen globalen Zustand beinhaltet, wurde diese Idee verworfen. + +Der letzte Ansatz war, im Hook \verb#data_post# anzusetzen, direkt nachdem die E-Mail Daten eingegangen sind, also das SMTP Kommando \verb#DATA# abgeschlossen ist. Dies hat mehrere Vorteile. Zum einen kann dieser Hook durch andere Plugins normal weiterverarbeitet werden und zum anderen erlaubt er an dieser Stelle das Transaktionsobjekt, welches gerade erstellt wurde, ohne viel Seiteneffekte direkt zu manipulieren. Ebenso ist dies eine zentrale Stelle, an der noch relativ wenig Plugin-Logik ausgeführt worden ist, sodass kein kompliziertes Speichern von Zwischendaten erforderlich ist. + +Somit fiel die Wahl auf den letzten Ansatz und hatte folgende Implikationen: +\begin{itemize} +\item Einsprungpunkt nachdem das SMTP Kommando \verb#DATA# vollständig ausgeführt wurde (nach dem E-Mail Text) +\item keine Zwischenzustände nötig +\item erlaubt das Weiterverarbeiten durch andere Plugins +\item direktes Modifizieren des Transaktionsobjektes: E-Mail und andere Meta-Daten werden direkt manipuliert +\end{itemize} diff --git a/Bachelorthesis/Content/Entwicklung/Realisierung/Implementierung/Haraka.tex b/Bachelorthesis/Content/Entwicklung/Realisierung/Implementierung/Haraka.tex new file mode 100644 index 0000000..3057a45 --- /dev/null +++ b/Bachelorthesis/Content/Entwicklung/Realisierung/Implementierung/Haraka.tex @@ -0,0 +1,33 @@ +Wie bereits erwähnt, basiert Haraka auf einem explizit entwickelten Plugin-System. Weite Teile der Kernfunktionalität von Haraka sind über das Plugin-System selbst implementiert und werden als Standard-Plugins mitgeliefert. Diese können dann über diverse Konfigurationsdateien im Ordner \verb#config# direkt gesteuert werden. Ebenso kann definiert werden, welche Plugins überhaupt ausgeführt werden und in welcher Reihenfolge. Dies ist der Kern der Haraka-Konfiguration und befindet sich in der Datei \verb#config/plugins# im Basisordner. + +Interessante hooks, die für die Implementierung von Bedeutung sind oder sein können, sind die folgenden: +\begin{itemize} +\item \verb#connect_init#: wird beim Start einer Verbindung aufgerufen +\item \verb|lookup_rdns|: liefert den reverse DNS +\item \verb#connect#: wird nach \verb|lookup_rdns| aufgerufen +\item \verb#mail#: hier können die Absender examiniert werden +\item \verb#rcpt#: hier können die Rezipienten examiniert werden +\item \verb#data#: wird beim \verb#DATA# SMTP Kommando aufgerufen +\item \verb#data_post#: wird am Ende des \verb#DATA# Kommandos aufgerufen, wenn der Client mit einem Punkt in einer Zeile signalisiert, dass die E-Mail Daten vollständig sind und der Server antworten kann +\item \verb#queue#: bevor die Mail in die Queue gelangt +\item \verb#get_mx#: wird beim Versenden aufgerufen, um den MX Record des empfangenden MTAs festzustellen +\end{itemize} + +Das Plugin-Konzept sieht vor, dass mehrere Plugins denselben Hook verwenden können. Dafür muss am Ende der Funktion ein entsprechender Return Code zurückgegeben werden. + +Um ein Open Relay zu definieren, kann man beispielsweise beim \verb#rcpt# Hook ansetzen, und ,abhängig von diversen Regeln, eine Weiterleitung erlauben oder nicht: +\begin{JavaScript}{Haraka Relay}{hrelay} +/** + * This relays the mssage if is_valid_rcpt(recipient) returns true + */ +exports.hook_rcpt = function(next, connection, params) { + // check if the recipient is valid (e.g. in a list) + if (is_valid_rcpt(params[0]) == true) { + connection.relaying = true; + } + return next(OK); // no further plugins on this hook will run +} +\end{JavaScript} + +Wie hier zu sehen ist, existieren in Haraka einige grundsätzliche Objekte, die etwaige Informationen tragen. Auf der äußersten API Schicht befindet sich das \QuoteM{Connection Object} (\verb#connection# auf Code-Ebene). Dies wird für jede Verbindung, die Haraka mit einem anderen MTA eingeht erstellt und hat eine eindeutige UUID. Es trägt allgemeine Informationen über den Remote Server. Ebenso stellt es allerdings die Verbindung zur nächsten API-Schicht her, der Transaktion. \verb#connection.transaction# ist ein Objekt, das die gerade ablaufende Transaktion beschreibt. Es ist erst valide, nachdem \verb#MAIL FROM# gesendet wurde und wird beim Erreichen der Mail-Queue vernichtet wenn \verb#RSET# gesendet wird oder wenn \verb#MAIL FROM# nicht akzeptiert wurde. Innerhalb des Transaktions-Objekts sind weitere Objekte gekapselt, die die Informationen über den eigentlichen Vorgang enthalten. Das Transaktions-Objekt ist im Grunde der Umschlag der E-Mail. Es enthält die SMTP Informationen über Empfänger in \verb#transaction.rcpt_to# und Sender in \verb#transaction.mail_from#, ebenso wie die E-Mail selbst über die Objekte \verb#transaction.header# (alle Headerfelder) und \verb#transaction.body# (Text der E-Mail). Hierüber ist es möglich, an alle Informationen während einer SMTP-Sitzung zu gelangen, diese zu manipulieren oder abhängig von den Daten (z.B. Existenz von Headerfeldern) weitere Logik ausführen zu lassen. Weiterhin existiert ein ein \QuoteM{Outbound Modul}, welches über das Objekt \verb#outobund# ansprechbar ist. Über dieses Objekt ist es möglich, explizit E-Mails zu verschicken, beispielsweise wenn ein Plugin während der Verarbeitung selbst eine neue E-Mail schicken möchte. +Als letztes interessantes Objekt existiert im Connection Objekt das Objekt \verb#connection.results#, welches dazu benutzt werden kann Zustände und Informationen zu speichern, die dann über mehrere Plugins hinaus abrufbar sind (z.B. logs). diff --git a/Bachelorthesis/Content/Entwicklung/Realisierung/Implementierung/Konfiguration.tex b/Bachelorthesis/Content/Entwicklung/Realisierung/Implementierung/Konfiguration.tex new file mode 100644 index 0000000..3ccd494 --- /dev/null +++ b/Bachelorthesis/Content/Entwicklung/Realisierung/Implementierung/Konfiguration.tex @@ -0,0 +1,30 @@ +Nun müssen die Implementierungen noch adäquat in das Plugin-System integriert werden. Haraka Plugins werden erst ausgeführt, wenn sie in der Konfigurationsdatei \verb#config/plugins# in der korrekten Reihenfolge aufgelistet sind. Ebenso müssen einige weitere Anpassungen gemacht werden, damit ein Testlauf möglich wird. Beispielsweise muss der \verb#get_mx# Hook überschrieben werden, da hier nur lokale Systeme ohne MX-Record vorliegen. Die Implementierung ist ebenso im Anhang einsehbar. % toref + +Die Konfigurationsdatei für die Hops ist folgendermaßen definiert: +\begin{mail}{Hop-Konfiguration}{hopconfig} +my_mx +access +dnsbl +helo.checks +open_relay +data.headers +enable_parse_body +my_transaction +max_unrecognized_commands +\end{mail} + +Die Konfigurationsdatei für das SMTP-Gateway ist folgendermaßen definiert: +\begin{mail}{MSA-Konfiguration}{msaconfig} +my_mx +access +dnsbl +helo.checks +mail_from.is_resolvable +open_relay +data.headers +enable_parse_body +create_myst_mail +max_unrecognized_commands +\end{mail} + +Der Hauptunterschied liegt lediglich in Zeile 8 und Zeile 9, welche die Plugins beschreiben, die über \verb#data_post# das Transaktions-Objekt verändern. diff --git a/Bachelorthesis/Content/Entwicklung/Realisierung/Implementierung/MTA-Entscheider.tex b/Bachelorthesis/Content/Entwicklung/Realisierung/Implementierung/MTA-Entscheider.tex new file mode 100644 index 0000000..a9827a7 --- /dev/null +++ b/Bachelorthesis/Content/Entwicklung/Realisierung/Implementierung/MTA-Entscheider.tex @@ -0,0 +1,50 @@ +Nachfolgend wird der Hauptteil des Implementierungscodes aufgezeigt, allerdings ohne die Hilfsfunktionen. Dies soll eine Übersicht über den Haraka-spezifischen Algorithmus für den MTA-Entscheider geben. + +\begin{minipage}{\linewidth} +\begin{JavaScript}{Haraka MTA-Entscheider}{hentscheider} +exports.hook_data_post = function(next, connection) { + // if we have a myst mail, we need to inject our Protocol + if (is_myst_mail(connection.transaction.header)) { + // we decrypt the mail body and treat it as raw + // mail data + var decrypted_email = myst_decrypt(connection. + transaction.body.bodytext); + + // replace the current transaction object + var t = transform_transaction(decrypted_email, + connection); + connection.transaction = t; + + // the unpacked mail is a myst mail too, + // relay it + if (is_myst_mail(connection.transaction.header)) { + connection.relaying = true; + } + } + + // let the other handlers do what they want, we are + // finished injecting our logic, the rest is still + // SMTP compliant + next(); +} +\end{JavaScript} +\end{minipage} + +Die Funktionen \verb#myst_decrypt()# und \verb#transform_transaction()# können zunächst leere Funktionen sein. Wichtig ist hier lediglich die Funktion \verb#is_myst_mail()#, welche folgendermaßen definiert ist: + +\begin{JavaScript}{Haraka Myst header checker}{hismystmail} +function is_myst_mail(header) { + if (header.get("X-Myst")) { + return true; + } + + return false; +} +\end{JavaScript} + +Damit ist der erste Teil des MTA-Entscheider bereits implementiert und die Logik für das Entpacken und Erstellen der neuen E-Mail kann implementiert werden. + +Die Verschlüsselung und Entschlüsselung ist hier lediglich Base64. Die Funktion \verb#transform_transaction()# wird aufgrund ihrer Komplexität nur im Anhang gezeigt, % toref +da sie ebenso auf interner Haraka-API aufbaut. + +Ebenso wichtig ist, anzumerken, dass \verb#connection.relaying = true;# im MTA-Entscheider bedeutet, dass der MTA für alle MystMails ein Open Relay ist. Deshalb kann und sollte ab Zeile 16 weitere Logik darüber entscheiden (z.B. eine Whitelist), ob die E-Mail weitergeleitet werden darf. diff --git a/Bachelorthesis/Content/Entwicklung/Realisierung/Implementierung/SMTP-gateway.tex b/Bachelorthesis/Content/Entwicklung/Realisierung/Implementierung/SMTP-gateway.tex new file mode 100644 index 0000000..ac9076c --- /dev/null +++ b/Bachelorthesis/Content/Entwicklung/Realisierung/Implementierung/SMTP-gateway.tex @@ -0,0 +1,38 @@ +Um die initiale MystMail zu erstellen, die die Informationen über die Hops verschlüsselt in sich trägt, wird diese der Einfachheit halber im MSA, also gewissermaßen einem SMTP-Gateway, generiert. + +Die Liste der Hops ist statisch und vordefiniert für Testzwecke. Es liegt somit kein Zufallsalgorithmus vor. Die Verschlüsselung ist ebenso lediglich Pseudoverschlüsselung und kodiert gemäß Base64. + +\begin{minipage}{\linewidth} +\begin{JavaScript}{Haraka Myst Erstellung}{hcreatemystmail} +function create_myst_mail(transaction) { + // recipient is always the last hop + var recipient = transaction.rcpt_to[0].host; + var hops = get_hops(); + hops.push(recipient); + + // innermost mail, untouched + var old_mail = get_raw_mail(transaction.body); + + var i; + var new_mail = old_mail; + for (i = hops.length - 1; i >= 0; i--) { + if (i == 0) { + // first hop, "from" must be the actual sender + var sender = transaction.mail_from.host; + new_mail = create_mail_for_hop(sender, hops[i], + date, new_mail); + } else { + new_mail = create_mail_for_hop(hops[i-1], + hops[i], date, new_mail); + } + } + + return new_mail; +} +\end{JavaScript} +\end{minipage} + +Die Hilfsfunktionen lassen sich im Anhang einsehen. % toref + +Nachdem die Mail erstellt ist, wird ähnlich wie beim MTA-Entscheider im Hook \verb#data_post# angesetzt und das Transaktions-Objekt manipuliert, um die dort enthaltene E-Mail mit der MystMail auszutauschen. Der entsprechende Code ist etwas kompliziert und ebenfalls im Anhang einsehbar. + \ No newline at end of file diff --git a/Bachelorthesis/Content/Entwicklung/Realisierung/Implementierung/Wahl.tex b/Bachelorthesis/Content/Entwicklung/Realisierung/Implementierung/Wahl.tex new file mode 100644 index 0000000..340204f --- /dev/null +++ b/Bachelorthesis/Content/Entwicklung/Realisierung/Implementierung/Wahl.tex @@ -0,0 +1,24 @@ +Bei der Wahl der SMTP-Software waren mehrere Gesichtspunkte von besonderer Bedeutung: +\begin{itemize} +\item wird die Software tatsächlich eingesetzt? +\item wird die Software aktiv entwickelt und gepflegt? +\item in welcher Sprache ist die Software geschrieben? +\item ist die Software (ausreichend) dokumentiert? +\item wie kompliziert ist die Konfiguration? +\item wie einfach lässt sich die innere Logik verändern? +\end{itemize} + +Diese Punkte sind wichtig, um eine mögliche Weiterentwicklung der Idee auf Basis derselben Implementierung einfacher zu machen, obwohl diese nur eine Proof-of-Concept Implementierung ist. Ebenso vereinfachen sie die Implementierung an sich und machen diese einfacher zu verstehen. Einige der Punkte sind auch relevant für Sicherheitsbedenken. Dies betrifft vor allem die Programmiersprache und die Komplexität der inneren Logik. + +Zur näheren Auswahl kamen aufgrund der genannten Gesichtspunkte folgende SMTP-Softwarelösungen: +\begin{enumerate} +\item Sendmail \RefIt{sendmailhp} +\item OpenSMTPD \RefIt{opensmtpdhp} +\item Haraka \RefIt{harakahp} +\end{enumerate} + +Sendmail kam in die nähere Auswahl, da es eine sehr alte Lösung ist, die extrem hohe Verbreitung hat. Ebenso ist der Code in weiten Teilen sehr gut dokumentiert. Allerdings ist die Konfigurationskomplexität äußerst hoch und der Code beinhaltet viel Indirektion, da der Code über die Zeit gewachsen ist. Sendmail ist in C geschrieben. + +Als Alternative zu Sendmail fiel der Blick auf OpenSMTPD, dessen erstes stabiles Release aus dem ersten Quartal 2013 stammt \RefIt{opensmtpdrel}. Dies versprach eine bessere Strukturierung des Codes als Sendmail. Allerdings musste festgestellt werden, dass so gut wie keine Dokumentation auf Code-Ebene vorhanden ist. OpenSMTPD ist ebenfalls in C geschrieben. Aufgrund der mangelhaften Dokumentation schied dies also Option aus. + +Als weitere Alternative wurde Haraka betrachtet. Haraka ist ein SMTP Server, welcher in Node.js geschrieben ist, also praktisch in Javascript. Dies öffnete einige Bedenken, da Javascript schwach und dynamisch typisiert ist und diverse Details des SMTP-Protokolls auf sehr exaktem Verhalten bezüglich der Bit-Länge gesendeter Nachrichten beruhen. Allerdings besitzt Haraka ein Plugin-System, welches auf Callbacks bzw. Hooks basiert, die es dem Programmierer erlauben, an unterschiedlichen Stellen in der Verarbeitung einer Transaktion anzusetzen und diese zu überschreiben oder lediglich zusätzliche Logik zu definieren. So ist es beispielsweise möglich, zu definieren was der Haraka Server nach einem empfangenen \verb#DATA# SMTP-Kommando tut, ohne bereits bestehenden Code verändern zu müssen. Ebenso ist die Dokumentation in weiten Teilen ausreichend, weshalb diese SMTP-Softwarelösung trotz der Bedenken über die Schwächen des Javascript-Typsystems als Basis der Implementierung ausgewählt wurde. diff --git a/Bachelorthesis/Content/Entwicklung/Realisierung/Testsystem.tex b/Bachelorthesis/Content/Entwicklung/Realisierung/Testsystem.tex new file mode 100644 index 0000000..0d820b6 --- /dev/null +++ b/Bachelorthesis/Content/Entwicklung/Realisierung/Testsystem.tex @@ -0,0 +1,13 @@ +Für das Testsystem wird eine isolierte Umgebung benötigt, die ausreichend Kontrolle über Netzwerkdetails erlaubt und trotzdem möglichst frei von etwaigen Netzwerkproblemen ist. Würde hier echte Hardware eingesetzt werden, so käme das Problem hinzu, dass auf Hardware-Ebene Probleme und Fehler das System beeinträchtigen könnten. Eine manuelle lokale Konfiguration innerhalb eines Host-Systems, die das simulieren mehrerer MTAs erlaubt, ist aufgrund der Konfigurationskomplexität ebenso unerwünscht. Ebenso würde dies eine Abhängigkeit vom Host-System und dessen Konfiguration bedeuten. Aus diesem Grund wird eine Container-Software eingesetzt, die die entsprechenden Abstraktionsschichten bereits bereitstellt. Sie erlaubt mehrere gleichartige Prozesse isoliert laufen zu lassen und dieselben über eine definierte softwareseitige Netzwerkschnittstelle kommunizieren zu lassen. Für diese Art von Software existieren mehrere Lösungen. Für die Realisierung wird hier allerdings die Software \QuoteM{Docker} \RefIt{dockerhp} eingesetzt. + +Docker ist keine Hardwarevirtualisierung. Es ist eine Abstraktionsschicht, die es erlaubt Prozesse in isolierten User-Spaces auf demselben Betriebssystemkernel laufen zu lassen. Dazu benutzt es Kernel Features wie Cgroups und Kernel Namespaces. Auf Dateisystem-Ebene wird UnionFS benutzt. + +Die praktische Funktionsweise reduziert sich auf folgenden Ablauf: Der Benutzer erstellt eine Definitionsdatei mit dem Namen \QuoteM{Dockerfile}. Diese definiert gewissermaßen den Installationsprozess eines vollständigen Betriebssystems, der darin benötigten Applikationen, sowie die Art und Weise wie diese ausgeführt und konfiguriert werden. Auf Basis dieses Dockerfiles kann ein \QuoteM{Docker Image} erstellt werden. Ein Docker Image kann als Vorlage betrachtet werden, mit der eine Chroot-ähnliche Umgebung erstellt und ausgeführt werden kann. Diese ausgeführte Umgebung wird \QuoteM{Docker Container} genannt. Wichtig ist dabei, zu wissen, dass das Image aus mehreren UnionFS-Layern besteht (pro Dockerfile-Anweisung ein Layer). Wenn ein Container gestartet wird, so wird auf die Daten aus dem Image zugegriffen. Allerdings sind diese immer read-only. Sobald Änderungen an Dateien innerhalb eines Containers gemacht werden, wird die read-only Schicht des Images mit einer read-write Schicht des laufenden Containers zusammengeführt, ohne dass die Daten des Images sich dabei verändern. Somit können auf Basis eines beispielsweise gemeinsamen MySQL-Images mehrere MySQL-Instanzen gestartet werden, die alle dieselbe Version, dasselbe Betriebssystem und dieselbe Umgebung besitzen, aber dennoch voneinander isoliert sind, sowohl auf Prozess-, Netzwerk- und Dateisystem-Ebene. Beim Starten von Containern ist es allerdings möglich, diese miteinander zu verbinden, so dass sie auf Netzwerkebene miteinander kommunizieren können. + +Mithilfe dieses Systems wird es möglich, mehrere gleiche MTAs zu starten und zu verbinden. Dabei können diese sich dennoch in der Konfiguration unterscheiden, da im laufenden Container Änderungen vorgenommen werden können. Ebenso ist es möglich, über Umgebungsvariablen oder Mountpoints, die vom Host in den Container zeigen, den Zustand und die Konfiguration eines Containers zu steuern. Ebenso sind die Container nahezu vollständig unabhängig vom laufenden Host-System, da ein Container bereits ein vollständiges Betriebssystem darstellt und lediglich mit dem Kernel des Host-Systems über den Docker Daemon kommuniziert wird. + +Es werden gemäß \autoref{fig:algorithmus} also 5 E-Mail Container gestartet. Alle 3 Hops und der E-Mail Server des Empfängers haben dieselbe Konfiguration. Nur der E-Mail Server des Senders hat eine abweichende Konfiguration, da dieser als SMTP Gateway fungiert und anstelle des MUAs die initiale MystMail generiert. Alle Container werden in einem Netzwerk zusammengefasst und können untereinander kommunizieren. + +Dieses System erlaubt es nun, fortlaufend Laufzeittests durchzuführen. Diese finden nicht automatisiert statt, sondern werden über die laufenden Prozesse in den Containern und deren Logdateien manuell durchgeführt. + +Die Implementierung des Testsysems ist im Anhang einsehbar. diff --git a/Bachelorthesis/Content/EvaluationValidation.tex b/Bachelorthesis/Content/EvaluationValidation.tex new file mode 100644 index 0000000..b4ffd74 --- /dev/null +++ b/Bachelorthesis/Content/EvaluationValidation.tex @@ -0,0 +1,19 @@ +Das Testsystem wird gemäß des im Anhang befindlichen Handbuchs gestartet. Bei jedem Hop wird über die Konsole überwacht, welche Informationen eingehen. Ebenso werden temporär eingehende E-Mails in eine Datei geschrieben, um diese debuggen zu können. +Der Testlauf zeigt auf: +\begin{itemize} +\item die E-Mail erreicht den Empfänger Container +\item die eingegangene E-Mail am Empfänger Container stimmt mit der abgesendeten E-Mail überein +\item in jedem Hop ist nur die MystMail sichtbar, welche im Body in Base64 Kodierung die nächste MystMail beinhaltet +\end{itemize} + +Da die Implementierung allerdings nur diverse Teile des Algorithmus implementiert, erfüllt sie auch nicht exakt die Anforderungen aus \autoref{tab:FunctionalRequirements}. Dinge, die erfolgreich implementiert wurden, sind: +\begin{itemize} +\item MystMail MTA Entscheider als Open Relay (basierend auf dem \verb#X-Myst-Mail# Headerfeld) +\item MystMail Erstellung auf SMTP-Gateway Ebene mit statischer Hopliste und Base64 Kodierung anstatt kryptografischer Verschlüsselung +\end{itemize} + +Damit kann allerdings bereits nachgewiesen werden, dass der Algorithmus im Kern funktioniert und nur die Informationen an die Hops gelangen, die für diese sichtbar sein sollen. Auf IMF Ebene sind die Informationen durch die Kodierung im Body geschützt und auf IP-Ebene durch das zufällige Routing. + +Es kann allerdings nicht nachgewiesen werden, dass eine in der Praxis nutzbare Implementierung möglich oder sinnvoll ist, da u.a. wesentliche Teile der funktionalen Anforderungen aus \autoref{tab:FunctionalRequirements} fehlen wie z.B. tatsächliche kryptografische Verschlüsselung oder ein Algorithmus der eine zufällige Route auswählt. Für einen Nachweis der praktischen Tauglichkeit müssten weitaus mehr Kriterien betrachtet werden und die Implementierung einen anderen Umfang haben. Auf Seite der nichtfunktionalen Anforderungen aus \autoref{tab:NonFunctionalRequirements} wurde zumindest NFA 1 eingehalten, obschon hier der Umstand ausgelassen wird, dass dennoch ein Ökosystem offener E-Mail Relay Server existieren muss, welche den hier beschriebenen Algorithmus beispielsweise als Plugin bereitstellen müssen. Eine MystMail kann nicht über gewöhnliche SMTP Server weitergeleitet werden, da für die Weiterleitung spezielles Wissen erforderlich ist. + +Dennoch ist das Kernziel erreicht, indem das Weiterleiten und das Ver -und Entpacken von MystMails erfolgreich implementiert wurde. diff --git a/Bachelorthesis/Content/Intro.tex b/Bachelorthesis/Content/Intro.tex new file mode 100644 index 0000000..666c1e0 --- /dev/null +++ b/Bachelorthesis/Content/Intro.tex @@ -0,0 +1,25 @@ +Dieses Kapitel soll eine Übersicht über die Bedeutung, Beschaffenheit und Funktionsweise der E-Mail geben, was sowohl Protokolle und Format als auch in der Praxis relevante Technologien betrifft. Ebenso beschreibt es das Zusammenwirken dieser Protokolle und das daraus entstehende Gesamtsystem, welches auch grob die in der Praxis aufzufindende Server-Struktur umreißt. Dies ist notwendig, um die Problematik praktischer Anonymisierung und Verschlüsselung nachfolgend darzulegen, welche sowohl technologischer als auch ökosystematischer Natur sind. + +Die E-Mail ist eines der ältesten digitalen Nachrichten-Übertragungsverfahren und wurde bereits im Arpanet über Erweiterungen des FTP Protokolls \QuoteIndirectNoPage{rfc196} \QuoteIndirectNoPage{rfc822} +angewendet. So gesehen entstand sie über einen längeren Zeitraum und entwickelte sich über mehrere RFCs über die Jahrzehnte. +Streng genommen bezeichnet die E-Mail jede Form briefähnlicher Nachrichten, die auf elektronischem Wege übertragen werden. + +Das am häufigsten benutzte E-Mail System +setzt sich aus mehreren Komponenten zusammen, welche sehr stark miteinander korrelieren. +Die Basis hierbei bildet das IMF vom RFC 5322 \RefIt{rfc5322}, +welches nur die Form einer Nachricht spezifiziert. Darauf aufbauend wurde das SMTP Protokoll im RFC 5321 \RefIt{rfc5321} +entwickelt, welches den Transport von Nachrichten spezifiziert. Weiterhin existieren Protokolle, die die Verwaltung und den Zugriff auf E-Mails durch den Benutzer, nicht deren Transport zwischen Servern, beschreiben. Dazu zählen POP3 nach RFC 1939 \RefIt{rfc1939} +und IMAP nach RFC 3501 \RefIt{rfc3501}, +die sich allerdings in ihrer Funktionalität teilweise stark unterscheiden. + +Konzeptionell besteht die gängige E-Mail in erster Linie aus einem äußeren Envelope, welcher Meta-Daten für den Transport beinhaltet. In diesem befinden sich Header und Body. Der Header beinhaltet ebenfalls Metadaten und die eigentliche Nachricht wird als Body bezeichnet. + +Dieses System bildet allerdings nur die minimale Basis heutiger internetbasierter E-Mail Kommunikation und wird in der Praxis durch eine Vielzahl von Technologien erweitert. Manche davon wurden speziell als Erweiterungen für E-Mail Protokolle entwickelt, andere werden lediglich systemkompatibel eingesetzt. + +Um die Relevanz heutiger E-Mail Kommunikation zu verstehen, ist es hilfreich Statistiken über Anzahl von E-Mail Konten und E-Mail Datenverkehr zu betrachten. Eine Studie der Radicati Group \RefIt{erep} +im Jahr 2013 ergab, dass sich die Anzahl weltweiter E-Mail Konten auf ca. 3.9 Mrd. beläuft. Die Prognose für das Jahresende 2017 sah einen Anstieg auf ca. 4.9 Mrd. Konten vor, welches einer jährlichen Wachstumsrate von 6\% entspricht. Ca. 24\% aller E-Mail Konten sind dieser Studie zufolge geschäftliche E-Mail Konten. +Der Datenverkehr insgesamt belief sich im Jahr 2013 auf ca. 182 Mrd. gesendeter E-Mails pro Tag. Es wird erwartet, dass dieses Volumen für geschäftliche E-Mails ansteigt. Zu bemerken ist allerdings, dass eine Abnahme des Volumens von Privatanwendern erwartet wird. Dies könnte laut der Radicati Group +an dem Aufkommen neuer Kommunikationstechnologien wie Instant Messaging und sozialen Netzwerken liegen. +Dennoch zeigen diese Zahlen, dass E-Mail Kommunikation äußerst relevant ist und sich als Kommunikationsform etabliert hat. \QuoteIndirect{erep}{S. 3, 4} + +Aufgrund der hohen Verbreitung von E-Mail Kommunikation müssen auch Lösungen zur Anonymisierung diskutiert werden, die möglicherweise nicht optimal, aber mittelfristig praktikabel und kompatibel mit dem bestehenden System sind. diff --git a/Bachelorthesis/Content/Intro/Format.tex b/Bachelorthesis/Content/Intro/Format.tex new file mode 100644 index 0000000..b54a9e0 --- /dev/null +++ b/Bachelorthesis/Content/Intro/Format.tex @@ -0,0 +1,96 @@ +Das im Kontext aktueller E-Mail Systeme benutzte E-Mail Format ist das \QuoteM{Internet Message Format}, kurz IMF. + +Das IMF hat mehrere Versionen, angefangen beim RFC 822 \RefIt{rfc822}, +welches noch den Titel \QuoteM{STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT MESSAGES} trägt und vom 13. August 1982 ist, bis hin zu RFC 2822 \RefIt{rfc2822}, +welches bereits den Titel \QuoteM{Internet Message Format} trägt und vom April 2001 ist. Auf Basis dieser beiden RFCs wurde im Oktober 2008 der RFC 5322 \RefIt{rfc5322} veröffentlicht und ist damit die aktuellste Version zum Zeitpunkt dieser Arbeit. Das Ziel des RFC 5322 ist es eine Spezifikation für das Format von Text-Nachrichten, die zwischen Computer-Benutzern verschickt werden, bereitzustellen. Es ist im Kontext der E-Mail eingebettet und korreliert somit sehr eng mit dem SMTP Protokoll. Es beschreibt allerdings lediglich das Format der Nachrichten, nicht wie diese Nachrichten verschickt oder empfangen werden. + +Das Format selbst setzt sich aus den Konzepten Header und Body zusammen. Der Header besteht aus mehreren Headerfeldern, welche jeweils einen Namen und einen Wert haben, die durch das Zeichen \verb-":"- getrennt werden. Die Headerfelder selbst werden durch einen Zeilenumbruch voneinander getrennt. Es gibt eine Reihe durch den RFC 5322 vordefinierter Headerfelder, die eine vorgegebene Bedeutung haben und von E-Mail Servern in bestimmter Weise verwertet werden. Dazu zählen vor allem folgende: +\begin{itemize} +\item \verb-From:- der Absender, beschrieben durch E-Mail Adresse, Name optional +\item \verb-To:- eine Liste von Empfängern, beschrieben durch E-Mail Adresse, Name optional +\item \verb-Date:- Zeitpunkt zu dem die Nachricht verfasst wurde, nicht Zeitpunkt des Transports +\item \verb-Subject:- Betreff der Nachricht +\item \verb#Message-ID:# eine von E-Mail Servern automatisch generierte ID wird intern benutzt, um mehrfache Zustellung zu verhindern +\item \verb#Received:# wird von E-Mail Servern, die nur weiterleiten, der Nachricht hinzugefügt, somit kann der Weg, den eine E-Mail nimmt, nachvollzogen werden +\end{itemize} +Die einzigen obligatorischen Headerfelder sind sind \verb-From:- und \verb-Date:-. Jeder Header, der diese Felder nicht besitzt, muss als nicht wohlgeformt zurückgewiesen werden. Weiterhin sind Headerfelder möglich, die nicht im RFC 5322 beschrieben sind. Diese können von E-Mail Servern ignoriert werden. Manche Headerfelder sind für E-Mail Clients gedacht oder werden zum Beispiel von Nachrichtenfiltern ausgewertet. +Dem Header folgt nach einer leeren Zeile der Body. Dieser besteht aus der eigentlichen Nachricht. Sowohl Header als auch Body sind auf 7-bit ASCII beschränkt. + +Eine vollständige E-Mail gemäß IMF könnte z.B. so aussehen: +\\ + +\begin{minipage}{\linewidth} +\begin{mail}{E-Mail}{E-Mail} +From: Hans Bauer +To: Mina Meier +Date: Tue, 8 Mar 2016 06:46:18 -0800 +Subject: Beispiel-Mail +Message-ID: <18283.122131@bauer.de> +X-Mein-Header: True + +Dies ist ein Beispieltext +über mehrere Zeilen. +\end{mail} +\end{minipage} +\\ + +Zeile 1 bis 6 stellen den vollständigen Header dar, getrennt durch die Leere Zeile 7. Der Body erstreckt sich über die Zeilen 8 bis 9. + +Aufgrund der Beschränkungen dieses Systems auf 7-bit ASCII Zeichen und dem Fehlen von Inhalten, die nicht Text sind, wurde \QuoteM{Multipurpose Internet Mail Extensions}, kurz MIME, entwickelt. Es ist beschrieben in RFC 2045 \RefIt{rfc2045}, +RFC 2046 \RefIt{rfc2046}, +RFC 2047 \RefIt{rfc2047}, +RFC 2049 \RefIt{rfc2049}, +RFC 4288 \RefIt{rfc4288} und +RFC 4289 \RefIt{rfc4289}. +Die Integration dieses Systems in SMTP ist in RFC 1521 \RefIt{rfc1521} +und RFC 1522 \RefIt{rfc1522} beschrieben. + +MIME erweitert den IMF Standard, indem es Zeichen erlaubt, die außerhalb des 7-bit ASCII Bereichs liegen, sowohl für den Body als auch für die Header. Weiterhin ermöglicht es Inhalte, die nicht Text sind, wie Programme, Audio-Dateien, Video-Dateien oder Bilder. +Anzumerken ist, dass MIME für unterschiedliche Protokolle verwendet wird, nicht nur für SMTP, sondern auch für beispielsweise HTTP \QuoteIndirect{Berjon:14:H}{Kapitel 4.7.10.3}. + +Die Integration in den bestehenden IMF Standard erfolgt über neue dedizierte Headerfelder, die die nötigen Informationen beinhalten, um etwaige spezielle Headerfelder oder nicht-Text Teile des Bodies interpretieren zu können. Die relevanten Headerfelder lauten wie folgt: +\begin{itemize} +\item \verb#MIME-Version:# die Version des MIME Standards +\item \verb#Content-Type:# der Typ des Inhalts, z.b. \verb#text/plain# +\item \verb#Content-Disposition:# wurde in RFC 2183 \RefIt{rfc2183} +hinzugefügt und erlaubt das Angeben von sogenannten \QuoteM{Presentation Information} +\end{itemize} + +Der MIME Standard erlaubt es aber vor allem sogenannte \QuoteM{MIME multipart messages} zu erstellen und zu interpretieren. Diese haben mehrere Bodies, die einzeln interpretiert werden. Getrennt werden diese durch das sogenannte \QuoteM{boundary}. + +Eine E-Mail mit einem gewöhnlichen Datei-Anhang würde beispielsweise so aussehen: + +\begin{minipage}{\linewidth} +\begin{mail}{MIME-Mail}{MIME-Mail} +From: Hans Bauer +To: Mina Meier +Date: Tue, 8 Mar 2016 06:47:18 -0800 +Subject: Beispiel-MIME-Mail +Message-ID: <18283.122131@bauer.de> +MIME-Version: 1.0 +Content-Type: multipart/mixed; + boundary="------------080209010109060601000409" + +This is a multi-part message in MIME format. +--------------080209010109060601000409 +Content-Type: text/plain; charset=utf-8 +Content-Transfer-Encoding: 7bit + +Mit Anhang. + +--------------080209010109060601000409 +Content-Type: text/plain; charset=UTF-8; + name="Datei" +Content-Transfer-Encoding: base64 +Content-Disposition: attachment; + filename="Beispieldatei" + +RGF0ZWlpbmhhbHQK +--------------080209010109060601000409-- +\end{mail} +\end{minipage} +\\ + +Die ersten 8 Zeilen sind der E-mail Header, die 9. leere Zeile trennt Header und Body, welcher sich von Zeile 10 bis 25 erstreckt. Wichtig hierbei ist das Headerfeld \verb#Content-Type:# in Zeile 7, welches ankündigt, dass dies eine multipart MIME E-Mail ist. Ebenso gibt dieses Feld in Zeile 8 über \verb#boundary=# an, wo sich die einzelnen Teile im gesamten Body befinden. Dazu beinhalten die einzelnen Teile des Bodies erneut MIME Headerfelder, die eine korrekte Interpretation durch z.B. das E-Mail Programm vom Benutzer erlauben. So besitzt diese E-Mail einen gewöhnlichen Text-Anteil und einen Dateianhang, welcher Base64 verschlüsselt ist. + +Dem Benutzer würde in diesem Fall im E-Mail Programm der Text \verb#Mit Anhang.# angezeigt werden und die Möglichkeit angeboten werden, die Datei mit dem Namen \verb#Beispieldatei# herunterzuladen. diff --git a/Bachelorthesis/Content/Intro/Gesamtsystem.tex b/Bachelorthesis/Content/Intro/Gesamtsystem.tex new file mode 100644 index 0000000..2d8aeff --- /dev/null +++ b/Bachelorthesis/Content/Intro/Gesamtsystem.tex @@ -0,0 +1,43 @@ +Nachdem nun die Spezifikationen und Protokolle im einzelnen vorgestellt wurden, muss die E-Mail als Gesamtsystem betrachtet werden. Dazu wird nachfolgend untersucht, wie die Komponenten zusammengeführt werden, miteinander kommunizieren und wie eine Server-Konfiguration grob in der Praxis aussieht. + +Auf der untersten Ebene befindet sich der \QuoteM{Mail User Agent}, kurz MUA. Er bezeichnet ein gewöhnliches E-Mail Programm, mit dem E-Mails gelesen, verfasst, empfangen und gesendet werden können. Beispiele hierfür sind Programme wie etwa \QuoteM{Mozilla Thunderbird} +oder \QuoteM{Outlook Express}. +Dies ist die Stelle, an der der Benutzer dem System Input gibt. Ein solches Programm muss in der Lage sein, mit allen Protokollen und Spezifikationen umzugehen. Für den Versand ist das beispielsweise IMF und SMTP, für das Empfangen und Manipulieren von E-Mails beispielsweise POP3 oder IMAP4. +Dies findet alles beim Benutzer statt, ist also clientseitig. + +Auf der nächsten Ebene befindet sich der sogenannte E-Mail Server. Allerdings besteht dieser aus mehreren Komponenten. Mehrere E-Mail Server können sehr unterschiedliche Funktionalitäten bereitstellen, obwohl sie alle das SMTP Protokoll implementiert haben. Wenn der Benutzer über einen MUA eine E-Mail verschicken will, so sendet er diese an einen sogenannten \QuoteM{Mail Submission Agent} häufig an Port 587 \QuoteIndirect{rfc6409}{S. 6}, kurz MSA. Über diesen wird die initial erstellte E-Mail empfangen und gelangt so in den Zustellungsmechanismus. + +Nachfolgend kann die E-Mail nun, abhängig vom Zustellungsmechanismus, über mehrere sogenannte \QuoteM{Mail Transfer Agents}, kurz MTA, weitergeleitet werden. Für jede Weiterleitung wird der E-Mail ein Headerfeld \verb#Received:# hinzugefügt, über welches der Weg, den die E-Mail über mehrere MTAs genommen hat, nachvollzogen werden kann. Der MTA ist die zentrale Einheit der E-Mail Zustellung, da er E-Mails versendet und empfängt. + +Gelangt die E-Mail zum E-Mail Server des Empfängers, so wird der sogenannte \QuoteM{Mail Delivery Agent}, kurz MDA, aktiv. Dieser hat die Aufgabe, die E-Mail dem korrekten Benutzerkonto zuzuordnen, da ein E-Mail Server für gewöhnlich mehrere Benutzerkonten bereitstellt. + +Auf der letzten Ebene befindet sich erneut ein MUA, und zwar in diesem Fall der des Empfängers, der nun über einen in seinem E-Mail Server integrierten POP3 oder IMAP4 Dienst die E-Mail abrufen kann. + +Das bedeutet, dass ein E-Mail Server verschiedene Formen haben kann, z.B.: +\begin{itemize} +\item ein MTA, ein MSA, ein MDA und ein IMAP4 und POP3 Server, gewissermaßen als vollständige Lösung +\item nur ein MSA und MTA, der empfangene E-Mails an einen vordefinierten E-Mail Server weiterleitet, gewissermaßen als SMTP Gateway +\item nur ein MTA, z.B. als offenes oder internes Relay +\end{itemize} + +\begin{figure}[htb] + %\Centerfloat + \centering + \includegraphics[scale=0.5]{Content/Intro/Protokolle/emailg.png} + \caption{E-Mail als Gesamtsystem} + \label{fig:emailg} +\end{figure} + +\vfill +\clearpage + +Die \autoref{fig:emailg} zeigt schematisch das Zusammenspiel der Komponenten: +Der ursprüngliche Absender erstellt über seinen MUA die E-Mail. Der MUA kontaktiert den MSA des \QuoteM{E-Mail Server 1} des Absenders, welcher im MUA hinterlegt ist. Der MTA des \QuoteM{E-Mail Server 1} muss jetzt entscheiden, was mit der E-Mail im nachfolgenden passiert. Eine Möglichkeit ist, dass die E-Mail direkt an den E-Mail Server des Empfängers gesendet wird (in \autoref{fig:emailg} als \QuoteM{Route 1} gekennzeichnet). Ebenso möglich ist aber auch, dass der Empfänger E-Mail Server ein MTA ist, der lediglich weiterleitet (in \autoref{fig:emailg} als \QuoteM{Route 2} gekennzeichnet). Die Regeln dazu werden in Routingtabelle und Zugriffsrichtlinien in den jeweiligen MTAs hinterlegt und können abhängig von einer Reihe von Informationen sein wie z.B. Empfängerdomain der E-Mail. Es kann notwendig sein, dass der weiterleitende MTA das Envelope der E-Mail manipuliert und z.B. den Empfänger anpasst. Wenn keine Regeln vorhanden sind, spricht man von einem \QuoteM{open relay}. +Erreicht die E-Mail den \QuoteM{E-Mail Server 3} des schlussendlichen Empfängers, so wird dieser feststellen, dass er der Empfänger ist und leitet die E-Mail an den MDA weiter, der sie dem korrekten Benutzerkonto zustellt. Dieses Benutzerkonto ist über einen IMAP4 Server vom MUA des Empfängers erreichbar. + +Es ist nicht notwendig, dass E-Mail Server 1, 2 und 3 echte physische Instanzen sind. Es sind auch komplexere Konfigurationen möglich, bei denen die einzelnen Funktionalitäten über mehrere physische Instanzen verteilt sind. + +Das Konzept eines E-Mail Servers, der nur die Funktionalität eines MTA bereitstellt, wird nachfolgend noch von hoher Relevanz sein. + +Ein weiteres wichtiges Detail für die Zustellung und Weiterleitung von E-Mails ist der sogenannte MX Resource Record, erstmals beschrieben in RFC 947 \RefIt{rfc974}. Beim Versenden oder Weiterleiten von E-Mails fragt der sendende MTA zunächst den MX-Record der Empfängerdomain ab, welcher die tatsächliche FQDN des E-Mail Servers des Empfängers liefert. Erst zu diesem verbindet er sich dann. + diff --git a/Bachelorthesis/Content/Intro/Protokolle.tex b/Bachelorthesis/Content/Intro/Protokolle.tex new file mode 100644 index 0000000..a432a21 --- /dev/null +++ b/Bachelorthesis/Content/Intro/Protokolle.tex @@ -0,0 +1,5 @@ +Dieses Unterkapitel behandelt die weitverbreiteten E-Mail Protokolle SMTP, POP3 und IMAP4, welche die Basis heutiger internetbasierter E-Mail Kommunikation bilden. Für diese Protokolle gibt es eine Vielzahl von Erweiterungen, die allerdings immer auf den bestehenden Protokollen aufbauen und diese selbst nicht verändern, damit die gemeinsame Schnittstelle nicht verloren geht. + +Während das SMTP Protokoll die Kommunikation zwischen E-Mail Servern definiert, behandeln die Protokolle POP3 und IMAP4 die Verwaltung und den Zugriff auf E-Mails durch den Benutzer, nicht deren Transport zwischen Servern. Obwohl IMAP4 das modernere System ist, +verwenden viele Server noch POP3, +weshalb es hier der Vollständigkeit halber mit aufgeführt wird. \ No newline at end of file diff --git a/Bachelorthesis/Content/Intro/Protokolle/IMAP4.dia b/Bachelorthesis/Content/Intro/Protokolle/IMAP4.dia new file mode 100644 index 0000000..c1b9bad --- /dev/null +++ b/Bachelorthesis/Content/Intro/Protokolle/IMAP4.dia @@ -0,0 +1,3063 @@ + + + + + + + + + + + + + #A4# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #Verbindung hergestellt# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #Authentifizierung# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #"Not Authenticated"# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #"Authenticated"# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #"Selected"# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #"Logout"# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #korrekte normale Authentifizierung# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #korrekte pre-authentication# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #"OK"# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #"PREAUTH"# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #keine korrekte Authentifizierung# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #"BYE"# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #"LOGOUT"# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + ## + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #"LOGIN"# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #"AUTHENTICATE"# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + ## + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #"LOGOUT"# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #"SELECT"# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #"EXAMINE"# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + ## + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #"LOGOUT"# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #failed "EXAMINE"# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #"CLOSE"# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #failed "SELECT"# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #Verbindung getrennt# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #Zustand# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #client Nachricht# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #server Nachricht# + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/Bachelorthesis/Content/Intro/Protokolle/IMAP4.png b/Bachelorthesis/Content/Intro/Protokolle/IMAP4.png new file mode 100644 index 0000000000000000000000000000000000000000..91fde038288916f080a9634051e26a812db13b43 GIT binary patch literal 53101 zcmb@uc|6qp+c!KYk}M@D*(o8EeV6Q8vaf@ZWZ$>3o>8_CLI~OSLH4m`$r&-(_dVMT z#y<9WK2zuUyYBmbuIF`Me>}Zj=b6m+`&p0WeY}t3nDD1hl*ljBU4}p)L zp@8f_Z?vYs@M+GKU}dF8kBDXEBdQ9I&aPr5A3DS(vwOMrt(=jRsrQLt>s?u&4YiAk&{xoEV^NA1coZI*S=77c zt3=VQjhF~Md;R5$deTMaiY*uPeVR?*ed*Y?77yBWZwZ{j^?UP1Zr|4TSstHY(et7E ztJ%j(wDqQlRo325g>a}w(whhO4L{!!sCp63E@YQyGw437*Zo5fdLu|)w#_ZkVzhmC zhUNBizS4ly6~7y#)=qp?tE zOB*mF9;3I!5VVi7<`-``r(Yypw@=$Kpk4?q; zQ)UYenkE5GDd-uyWUGoNW+X=ic4VbuJFLprTrj990;SG+F(aw*sURazABJ#j)Edk$ zHWnHbB6#pNghce)3C8Z1^2TJo?XaNb+q)XtFvMC4l^zKtDq3O>+frPjzA=d&Hn3SH zh*oGLqW@f?KA4X_KhZOTpP%gys1=!vx@&|bZ%poo%DmdQUHY}U-6aI8T6+z-`TjWq z0(q!!TC&?W*o5V}qkx^x$DM|HTf6a?*sf_qeR882hd(|_i+s zZ^EY22@jDl75I7$USx@$@i&lryL#v{?N`a@-Rdp`S%|AN5ZKJ`5meN|w*wAj>m&cu*BTER$tfTg$)~#fYxzMPU3e9(9@yNN$ z*Xs%M+Jn$VTi=U5q)a99#OILlD*s6RDS`HiWu_C>Ei*Gl=oaf2n#&9hL&C&%Nu7d) zPnB@t{d1hEDtblu&3!+ALAf8+@40Ib&Tg>wl*YMmE0k4Ad0=xoZYWEkWRyB96g6A7 zuQEe$8!l}LLt=I<%RA4ME{!N%shA1sT?}d`UZ)~iXC8%Ev$)A}CB zTMI(Md;QuP6i2TNwccD}8RX;TR6sxY9K^!+kn*oDEXaKCY(=eG_s1N)aC0T@hoc(tjKKmo24eE_M>3BR3K&g9%bw14~|9()K6Ikb%Vcf)D4V= z@=P-YaXYRmst=vH5|Fc+t1|gq=M{Re?Yim^>f-G6BVXl$I7r94qmWQ}{Z8K3xM&_s zEVtBsu93Qm>%ERqSTn7LZ+qQMH*mSHHzeQ-5m~LfSgPDU-k=LgZEo+KDIk}3nOQQD z+tvS)&hV4&(t0EF?&`@?1JCTci6#<)Uue?Y{Is^H|qkP!UM9@MV`nQaxA4 z&@-JgU+twow<|1vfIj-^_O`Mg*t^|3x^tzqy4qQ8eOhVa{kNzdJqLc!^Fv&g8gFb) z115T*fWR%LGmseTbo7q8WS-9X5spI+Yv(_5b3yO0j8#5#EO5+%@4?t7mK&r8j|rP2 z{=QDL_Lbz0&Fas4?}(Xiz2AbQBKGx%OA1A1eoi{2@?OlF4r~#&e;P_bCpO^DiPu+> zG2Pu|;KbtK&Bn9-)`*n42=~$Q@n@Ef{j9(*nez4~XTQ6G7f`*fHTN233+oI;rgNJ8H4KQD1L9Dr_vrJu(&E_BUpo5wvw<f{j$Kd5Nbi|zA`NQO&Yya zkf$S4?VeGgFQx}sHt&xje^%PG9!Cy z#*Kz?2(Qsu99-I8ee^Lcol%fyUb8}9QTTf;mWSG`HH8Ofu z+Ly0JYoA|)WR)gG2A(@#GkYT!yR}eSpe$gG$_xb(4j={-{FcCnBx}Td`By-)eDbAF z)Z>cu1{u6o6HVGsD5CNPFwt#sV3%~Im)IBMiDyIF*OQNsx3Y+6pDUcpDO{g!`xF&o za7*U&^9g1&UK4fblACASaY-WsPOS+*MO*oc@I1}YP$pIFCg7d#LIazM3`Fo?bG!fksb^p_At>bJh`8@^(91#cN^L|`@;hA;Dh8%LOKxr} z(kDLzEEQvfp=yHcfd({>{Bi)wew6h^;p06{o`etSvCm?Xh#=1vcqoI?5<;#Z;ABKi>2dg2EOu?$h zZZy0i5WNAG?ttIJ|Lq4CIWhDw47O|7^_ zz-$Jt(SBhek`HdybbPqIDB-y->NL~1v*XG=&j9{W(Zy&tS+nu+q2=-3+8`V%G1y7? z$i9Bcv389P!YrQdyIIc-uWQ?_vm1pQ85#8?^4u19`QrrB(qfHdQ~|$96?U-g&wA6( zPrwXf7sz@xSdPPF&19_;rEq(WO8ogwQcFiAJLJLZrYgufo0Qa9UaI3|;cCSwy4q<^ z6G=1yL|)Z1_*^NJ#h&ieU=R_E^D6H6%`TjS|6);i6#gV#gCNFsgw8O z#S3Kw8r~pD327CpTX+bWqyr~sVD7))D>9ptmzM&+2oOEc8U2IJ>4qUSEiEm~Ow-9J zEtZ>TjtUI_y|kcU6u=2&K=U`*fx;Hr`Wuj1r!>%tH zM4LIzulOOU;8>IiNhs*IC~SSPo7H!7b8_6*$NDeZripu8_8dx^+?Z+fsiYw{C^gnI zHMQ3$HLA?xpi6h{=4|rCI!@KO{4l41bX*~&e8kGd!vh5?i@T#HX=A_mEo#O|KkBx~ z!OXZZFodcl3qY8-4d7M!6%Lcan8H%y>M#2JV376ob*^SsNEk;vDJCrXL-Ewm1VN># zs~#=MUuWO2vw==RWBMhAE_~#$y26_@fX5jbZJ&Eq?k|TVpTne33mxiE068EWy&!5_r5aZg8U7t|?vz97|)o z&NRYL0W~&*cR3FNHmB;{)&_FZ zi4Oe^?pj+}?XUK?!xX?t^BdfSC;{oLs5U=Qvi;Qn6VWTgqGnP(D%Dh|o);~QRaoM$ zMjP5Ha8ojL&;v6g#m(LGG`W9XjI9G!aa+XkJ|C{7J@U4Y?Tg%|cunbgSL+bSqdV`n zf^Hg@4hIW)R|=0BoF(lI)QgY0D?FU{Y-l+y{S#JQb7G*Dj?FOd|gEz z1S%*f6zi9M5uO8j)g)pOd4s1>#Nx@5=&#xYV-T>uFHHN3&g3}VjFIA=whc09`_@in*`8$3A=Ed$3-CSIb{ZOGXvhYDv5{ zHa5g+)zr0JfScYPUrlw5M zJH8xg?%FS3<`s$)u=8JIq`IiUl~NFn`zgb&G1L*d?~GXRB6_R5F;U$kPG{d4K@&>J zRCCwr18opPKu3 zex4rv1Nz=ug|T|{TXSE7`5L#{fIVYM*kNaof(@M{UYQNVH3@xRa`k~dPH$gBc%T(E z@5Lr0B$PrMMjBR7{yOiE_t7RcWnP$>JyQY>AnbZOh0+Z0c^OpKi0#?i8BrAuJ(pI! zVtw*k{J&D{;K`CcuDK+fe0*3jcyU$LP>ON>69&v80ySD@-kFm9_fo`gYTWP?|6v}j zN6YC>B-SM!sD2I5SYFKH-3FkmF7ZLxKm)o@BF|kT9Xa*ZFnbL?DFz05O))5-iDmW6 zDVAN)rDjbC;9sxufVa&sZUU6_q81teiebe>1RPIx+SKhw?DaIgXV@;>79KNxp2W9k zd2+BZvm(tT;rS!wLwx*VeOgMs(PWkaS+ECT7|}Jxr?-^cf7wE%%y*%#(|MCGZS;$Z z+yh@{Wo6-xGH`fJy8~?2I`Fw=4?<{YX#CIiM`uP2cGF>Pq#TB^aHSZ=Jb2kl;duq) zw`o8@z0F&;CY@ULX9zV?g{#jc@#bxxjNk;oyQ`B~Ji$VTxBYc=gfa%*XweH?6m>uq zS>)dST3PW8Xk3WkPWM?(ZY`eq(s{y2+6m~B9Mo_z7B$>sJ0NH?kQ1S&m&Rdm(Z1;D z$6V6~tiTKz3^~_QvY&$#m0mnSF3Y?;EZ+6e`ntRw_}5=G`u1n1yT} zRT-RcQ5=3HVKNOkTAInI+g(An>m`O2S)YIZ0dDs1ShkT*Ga@AD zp+cRkCXcttTfb;a{gx?X$>cEa$=&!$1Let@5LA(&Mt;90`BQ+q1tz1k>@u*w-_%~q z*^ia8@WrG*`Q$w3pm(S3#6ve^_i@(AbM8}iiVAVI)F#uVN+I98mx;xG<-{`iE4BrS z3B>pLGQbT@d(Ce6lOn(k$c0i&`|b7uw_sTBnv0!xkMldo+Ze0J&P@6iMZJ32Zv^wV z%u>jWNHMufEj7+B)grutgGnd@Ryy;SjjL^4$jIfVGvz`Xktd4u@3-Dl5eD$SJuH8R zTUnK5pf8NYjkM?_z{)n8^lA~hxl%?zz8X$<0XzUc zW7i2dEPc4CjfZ*j$!5bFGFo2Kx}O4W0L+!z&3gjxAR*DfMRWJV%?*(&F5L?E^{rKH zY}Q0({VdPM?WgMcPxM3_r^ZeYBSN;iYrbSufTLg#wjZ-VT(++8X(QV$pvzeFc+GRo z-Vh`EnrER>@r{3wR@lVjcXO39R672)WEIriE1kzz%<30&37fwKX%f>926_;PKwFb; z^?%j2tM)7>b{fco6^Ur>_KhA9h*%y1^AdXH))yd~K{{Z6lP!UPnnk-#J!vphVSYNS zXk{C04uGj;v6O(Loh1M_XPf;`xXT(@Ii;kUOlloRIJ^J=Sj;fas{1C&1dF|1TKBUV zckYW8jC}q2b+%HBar~FcN~x7$7(gBaz`Z>0=wm_;>cjCmM)9^kg=yuYo%A|T;!Dy1w9h5l?!Qe zEd*>kK=Na5i@*yC?u}gm$cgvfy|6vqaNs9^u{QAsE^5RZLtO}#3cw<`hY1VVtp+JWPN_K1-v06ZF+ znp3{;){b-j>&_q$9@vEhd-$LCLKlF-?n_)TG=~)h+?7~iQK{2lkwbedrS4w zp+BW-Ksm~`_~0tTc-fiEYG@HhqiirSFscq;Utc7s8b`&XUjC5V6ndDTB)ATTSE^QuYmuLl%hK62-s z=Vc7FYvq?OlGv<$L2safG^Gh`<}@vL@Yw8xehetIQ9M5$oAuNJY!+d2t$-Egy={#Q zp?#jD+Is7CFEz|CLyX&RF^GH>JRPXEqiX#HjI4IJ zs^ds+%<5GYgSDcrJ;S^#AKVDQFP)LJz5_Ge3EV(|p}eC&lKEf!{r(=jGrOwFy*EW@ zMAjJKwms?OS^&Ccx~4}v?>pRixHEmCIk zZetK-qjlK5c|Gp}jW=xax{A5f>49mn`bz@JVWVdINz^af$YSZ_PE!aSdG*|n70O-i zMOP;G-t@?$!oO07+0{@~^V^`udJqV&ltkZbk%Tb%iy2Ed>o z80;*1#ayHe&U7Ute|DMJ?(G&)GL|*7J*rLAlSBR|X-mz|vc85ss>RR(RkLu8F*|JF z7cM>y!}0Tk3-kgVW#4^iW^}kqB;7G?3HszCbEOj#Psz;()U46#L6r(U;G$DSoEQi7 z4#yB4#aIV{M&zYJvnCiaU8=MdoMol=jhA>wz1uwBft117Q{7lt`BW%U{l?k!G&gR*%wPRH$$FcdoSaTZ4g;hJ zT?zGr$Pn5<0G}^UxypPdaU9*S;yP&xz`ZsrD4ocQRJ{(O>U0x6@94)SEdfo~Qd)o) zG5$wQz`otQFGLSE0aR(6Nj<6^7EQyKt;sJlS^T`n4UozMz)YQ~U3q4Rn z+s%)lXUF^GiI>^$|2cqH6L}6vt8s)hx;oYQ`+LshB2cZYNtT;GTmP*EX!dWQNxyvg zGC1Lv8r|Q&uk~k#(i}b!%`Eb|KruVhl%|BQc6 zBF}PkHKjfU9cTCD?rhn~V24fIGfqxUpwmtzud0EO!-y2z)krZ+ngv!F1Tn+ebtnKy z6SxhGi)ZjEG(`PG^lOB>6l`yqkdlW<2!X)I1FesCMgYo9T-(fs?vnyNxiDG2%#t-wOvAus2o2M5+e73^dF{$8M-#9$eqIsM{p; zFL38)Gog_4y+O_26CxSBrK}G<*T-Tdwg|Q4fnfv@kQ^8>lkPaT`G@w%>|SlLd%{|T zJ)Yc{k7*_6N(f;CqSm;p^~K1OjP?eSJPpv!Kmt^#Y*C}cYnc7ld{di_TXYE*Sy zvmO1^V^rwMwqsUf)yH>XEyQPsi!n1Ciu97+59aL0$H!;#9r0{Op9djeG9zUGJy3B& z0%fM@oR_q}!>+-lGtMc#B-Avb-m7l#!US*+Ku5Mr12D6|<~c;p3s8V8mM4sE#G zwqyVyVV&>HI0~`0-H6s_XNVi!T5N!MjaCHn z#?!hK49qY+e8X~Gh{0KVi*e`n7dq$&-&BAGBx6`X-N>19d^m! zt}I9pC%YsE_!-mCLR2G9Nf~4bGJIi-jP$PoZC0V|{p44@p$sWy&5CQid>awCb4iY@ zP?FHkfUU-VD&H0?2NGt0??r|ydplpkPsBPec9oQp;_I;XpWoLRU#5S}_|FGYlA;#? z+xL5x5R%Y2TTTdlWXOuVDJ3O^?0+-;|2Y9Xk?{A#9mCplRDYOeWccd*R~FHv8~+*g z-_`wo2+(}sHr)U$_}`aTU-f5ZcCaF;f1bJazwBFV@HKk=>j7B(?=8jlECJ8s)-W9+ zId)r0lKC72C|yi}^nIUX&JP!XvOkB$fL+l?kma?K0+(?L7$<<#0C&66gq@q1bQ}jCJ!S2DN)5#~{+Yjb9rW?F~zi=tN;`}ky5n%&}EWqIG zA$`*AM=LD5XwAHz0SuRp%L%(!Qv#Aj7BT>Bim&CwoB8kSaSt4s@>q36Gc0z+U;s-2 z_}_PWq@s_4iOJzj2gWKOsM!702ym(zVkyx?avWY#QUb!}_P68$&_a-=pa(?hN&QYY zHzk9(Ac(ejp@<);B4s5dKTz|)gqsDP?F0J37eu{fz?;$u*?#1`QC<(0SqS3T^e!;` zWW8H{4q$I5#m`UrBrrLD(dzKRFQU`|#-6FPMgkOq=d}e&Su-0rL2xOyGHLk{KN? zj{eQz`qTB?H$1>?Yh*}EjST_kHv>56?Gh4ae)KCzCi=fCDA$$ zbc9ob_?3DE2I1J1rbD(}_1^w^*Yh4cl%zpbLxX(mTQOksqeNzI;_y#6E%vuY-oBPD z*WVr-1%<8U0%Cv9XJ^8$tkj?^Jr@6n&F@EQzTj`u5}0}Ee4SsveyJz(cRm#h%J!+< zel^!g4FpBmyS!G7w>}4)*GLRFBd4+Q%&%a8$_a15tp!d{UGbnjeyfCAlTbK5E{@-A z`9~yQvmqdI4*(Tzk6>jlVA_)lS5-H7=0)y)RGk!f+SiqTMZzl7^CSG*)q#X3ZEp8q z-sMe^yodteTQ6R`2xP-yASZmy_5J6*;d*rSj5`g*13ht#QXS(|c>7gU@wpu=DrDs; zdt=Viyf2SwQsAsM_3mds&>UBiA1owZts*ZfNJr`E2o36WJk=4>u*}z2A5P%qhX$9P zwlMVUo|xVDkBbGM(-W-%DGLacVezsDizJ zPK@?h83%&ytwC{9-Oy3;tnuiZazCQlMH z&dwOnS#Q2@ZIFfGIR1POKGXa3+am0g3%VqgfUBhdc`mA-k+AK{P_3eY@RY+aMwjna z2v!JzUp|J|<|kcgVcBsRdOrZQB0!Xs>v9j6#lRT!c0V1oXh6baB^&m^n}j`2!FWi? zf8>=0hlg=d?)ml;cFC>O-nlK zyU9gw1DRL_X^^_5^rFH+K_0zAP1JYJ1qvsSAJ7@Uu2HXQKvV4f>LafgdH zMJF)G-XDrjjiC}sZu}p%Uz^>$>v;PzJ1b_F>m1%S=FOO=MQtlCKQz)xvpm(KFmHKuP#k<-(x z86mYm=s>my0saE2BB*~SNK`yW4qUX?-V-7r!-6-@0$xJGD)aZ<1NU(%GUP+8eEU{* zZ+xB1ucfnHVU!f*<_0)J3jlCU>7y4~TCoXR2kYZ*?c^d=cB7kspFjZnb{oKGgdyZ% zt>#JJpic&BaM|`eSsII^&EveiZ= z6_X0+0bt6J(kJVUyL~69;<9LZF;-52->eM?9t4c<23RI}3h7kl*%}u-9;|Ma_Ouy2 z5)UjLsnJTM+<(Sh%@2)LVHkF48YvqT-&BhXaa9iG9kjx%HC?fi%;bRoq=}7gO}_Eu zp+#%Zpr*`O4`0g%T|@kzdu!P-(qCTQ6nJ@Mo1(l4L{jEwwYGM&9!8%pMh%YvA@_3_ z9+6q4L|5^i?sA=0B#p?vM5Z&?Ya1I+0NQQQ=t|I`NpZFRuvc--fmVj*KIb;?h$-BA z>N>lkUAX49i&-_g<+)&hu3sMVxBw|$8oAnd8Gv*WF?31gF&4w*Jdkm|mp@Y4F6B-A zh~F5#WR3a(o$!G7ohdU7>p=%;=5g%a%Uk;4+U=(75x2kk-a}XPEV<$g!aS1Cppv=y zfJKs7%b!JKBdbO6O9W`c3S7~7U;{9IwKK5dSeV88vu3OTRGXG*BL8^LG_67Ngm*vz zvzmq~azwD65_ffUJ!y5g{X97J82X`bU2)pG8qTY~t$|qMY0{GuD&l7*MH<1dn^LcS zGG}lA37g6!3cblzb4^UL6X8Y`Y9;5ZgfT533+(4hLhp?387F?p5*2OxHLbEUYq08L ze}frH|1ov6yR4=escexUFAS?AzdnrV*&Fzy>=sK$PP4 zK_E7b{(;3K5bltV1j|z`d+FnthOs6G z)4_VYA(1E1hB<>jB9U)sLyH);B`Z~6=<5jm{jp3BK3U0?h=1nT|0RUTGhM>2ru({U zmXA~EocDi~sSXuTUR5ai*#5dStL+*0ws8@wVlmkP|Kb6vM5;0lgp_PTJ9W_p{)X4m zsjKZq9f4_x>jR2A_(Y=DUF-qp!xk)wsjzg0;CvFalX9r&lG`xDa7B%++Of7d<6y;2 z+BdDII&~+tZS?GWteKSoxdvME<@1e+_ul5H+9NK%@ve;ML_IF=gCFLf`_%N!luql> zzbE348}phiY;26{iDr~K>!ii`bkfv1jbHn!ZDV6Q{w2;%p0MZ`8*sF7cEx(EsAcpd zX0GMiy?~AAW0Au{LCL~MT+kp?pSXoA{ zab^(veFRmC`o}WV3tg(Tw?btfBX4O*2zTfrX|#b4y2i6sIs@p>&7#w1y6lbYBbE6F zn6kYAp4=9ILLKFMURbTo$y&Y8h2<*W*E&+ZbePTv1Iytv5Phvl;9|G_h7D2uW&}Dd zGrDp%jC1o3i0(Uj#581ZHdadUwXP|eck4VVbT^;ooHfBrZS~0iT&banf+uXR`tbge z%;PW|#nsZjv&luK$Crd(z9}Z#e#|A6&yLiK=Ig%`SyfPWEM2xjV&}Y?M0JIfZ>`#~ zbZDrXM_f3oo{Y?6{iA-FJ~BPQgyEXj^%iUoy6Fqo>BhviVSj-ZZ2scXO8nOP zUBvVo3l_dC%-MXP2ZiwCR@Haz6sNS5`YNJ5Zw);z@eI4h-Z*>GVv?(8z4{KU=5}@A z)Kka;v)nD@YVs45pq>uqCj+`_(?*J6E#bb{AmKb}SS@a6S7Y?Ad!z?eqYE;rxR~?E zkaJJR-o?tqpO(b8xjHV*>>5Ur6c1W!(}+akxCnU}?IYh*+L!Bv{#1^V?&ruy4LMAV zXrAfYd5EeJgk8qyd~G|G;kJp$Ys{^+En1fBl~A)j`^>~@%t=Z)FMjkw#khIOodLp? z8;$ZSphOP(fC#(NeMFl_2zqty`n(?}`K!;w0fl@f#rxVk8`;vpQ=M9=cwZV-;o#)a zup33)G=M_lbcFQq_Om21a0I!s*7(Nw6#zaoTc3RU4g6b1vHrtYk0!?D*X)uZ+!7{f z;)PYZ+-!%J3FPk&VCuq@^Z3pCxw8dPBpO4AKx3JbKHYJ~Bv&p1+0{XuO}ejao7@F}o;+P^ zHv^O@>zA6Jj85mDs3#G9eoiFhTybNC%PTo?UmrtAb0IZ8B=nN|T2{$@hlw1yP<)R9 zUEZtico@GPz+DbSd2ijEDIt~Og@fSC@&hEQE6a|X^F|5#6u}$=gTtk%-96RM->hjv zh^v_X_{@H>w&i4EH~y^Q_%Gz`?+)FX}cQTFA5u zu4^UY`I~_Y9LVtNYhs>f;Wx$JEYBsN+xknoAlG%IvX?F&@hPo+Q=6SKlqAI+nZ<$7=qEiKPmpGB` zG%EJkche*p;$w$QQFc+KR)|D)VMWXH+`#bwFP`T`jg6+-s+U*1zEP4Q&rh>cahs!I z2P>{$6s81q+sP*^5E1Occ`tsL_BP3!o%ho@Aa1nw0}ijNriMe)luV%N;yW)EMbT|} zP@oKLsIp7K$us{2Qk(x&9nQG}R?gBy0(z(K+dWQzfVH)CvlZV(5M~93kg#9UY}=J) zrLO?UL>$RD8Fu4n`8Ewrp}+4n#%rKtO&KsM3o#B+VRGp!Z*Qb$ZwJXMwh>*s07&q$ zk%JYcxz}mFSC@m*-R?_T4-tlgN=5cdfVOnuEoD2rP!~ip^Cs}k3(dCd(9jM*IsSeR za70({59^7>#AGW~JEjc`dJL#&6_bZuy~g;SSu%r zkP*o1l5#Ol$;PH|a^s1n<_c?Zkdf);7&zkriH)jm9&BZmS`mj(_^XF7Z{-{7Sr@^^ zBta>jN{Ji^gShT@D=a3ksodFg8nKunoJM`FEhc6=jfk_mu<+-q(ysy_aIln=V15wJ z(G9OxY!A(sKKI_cOn8kHzX^6pwy`M+J$?PV=Ph4H@H=Lnzx8$5^PXm#nudlD^b!>} z{@k7GE%DDOv;}W~Ji`T9O5`QsT0DUPD)#WV^3K9d;yU0A|H#1q_Mvm9C0H-T(h*Lv zEja3bc^fb!e+Fw4c-_14lwER+@xNB|pPBxAI5kN4XKVvWVf@2;TNVOpiT640-P;Pd zYtaTcI!xp46H{&?`WVLatM-m~3g;!l3nTsN=jYk8O)tPUrCa-5GXtq~K$47s1Q|%j z-z>i7%zo`ZkMj!%aA>ACf`l4i>?v>YzW`|f{Wgh!(?e=a$$kK7Jx#2FwcJt02H?urU|<_S&IRsHG#XmBAQbBx+?g3%xT0vV8Ntzf20U;^F(2# znBjE`6<06V;#U|@WKbsUvLKIK1f{rq&4-V*0|J_9F!*)5uRgWhCwQXp=b%9~>=>Si z0+H@jd(`@P6R=fbA=Z~tC-E#&G03rk zlC>k5K(NMdEjJ;o^S9c-6~n!+G}sR0dLO>Yea`-AdJXRaI33 zrg_pGFk7+zO3A?p$XkKjwhCYrbGETKuftyX2Cx_}&(%ITgEZAgQPxbt}89nI9T*tc;@<-3mD@S#KlT z-)z`6qIv&9*<0~F;5Zo>7nu1phl`SV=Hm`aUTzpS;hI5j$H~FA5zBk^e;x`674<$a zN`n=xu`Vp6*zI*tAEV9pJE(ysOo_E`E#(a z*nczWVshV8u6d```d}0XFijQx|zA-Ds@}{1`Cn>R}YyL?`p*L zmNb&YMo0to(D0NB1~ z09L|d^)rJ6sQtx{2Kn~@fHR<#)qtyI>Kj&i>|64t5{7Xz-UcBo;LfhSN7p`FS6(!!mi4W; z3|m>-wOt4oW_;8p5c0>oeC%1;`Tknb)VGwMf3GaiW>UEF4dm@VVu`JK^t$}mI*%;; z(MKT>8_-&$Wt5!m&B|*<5FQa?EuXSRXhAF`$$mE@t(+zO!)%31x=K26`ic_Tg@(JZ z$^*?_sFPn5bAkOK+}r-bZ~9hQoq#A=(;XB_yyGgApEId@3R>7ysL7cao4y3G%Y&l> zJTd6Vac{$Xza>M6Yk78mP+=r+Hg;?WfTb*Z7@v*KB0%bF14?c-yFT^V8n!&ZQbz1^T3@);Z|JR}( zu~4+_2Hwp|mV3wKti9^OwYQ6eo%?`x)cLntw1oDNzYQn{>kPre{a^9ouJW{|pD7ps z2xf=;wv`;9wV*;rJFDePBhIn0A2{#le_RGD$lytU=AX959-E*^QviDT{Y{`<<@IS{ zw~ZkcyQ3|tAdR?C?%Em*?ipAZke_+UI-!S2wUOm8a2%> zxewZVNrS;IQzyggrXEs}nbe{-Y7>$R?cfi=6w3ch!N^EO79*MUh5u|#({|`@uq@Vj zU{l_M)D|dJo&FjOJ20v@HD$lJ^~a`C15Z@oi{d=niR_ayfFkfp`{1`X1Q{-(tl}zN z+)2wd12JMkmfuo_-yPJcF>_;bxVee=$^$U9H<%jV7eWloKt~s9*tJ1}_9`u<%zYJ+ zsaCz{zaV%^|2umYdU#W2X8pKU**Awe*Zb3iaap=zR75*0=$G7YDFBP1vV%6HU|u?m z@64r3xjm6|d6KQTxKNH@k^2x&9l8(s9{T&DLCP(xnj`%I^e;h2(<7Pl%t9Tgfw=?X zdh7T<2jOenN-DZXqD*DFJ$7m41fSXa6hukGEc>$^?=R#*@{0hdS&k#$-%Xk-E%4j?<-uf*gqnAaOZN(~ZgT~U!; z3U`7ILF$hEQnTYNkUgY-w)!&@^a_juhbnWjUKs#fFbJCmK*Hao+O`^0c_Jmfrd*Uj z)oefiU#}MAF5>Yk-q1d_wM9A9PQN_+n32I}v%B1@-`LaJ+XQMTe_SW&0E+uBO6d%{ z%4S^a$Y76pcS~SkaB$IxlFIHsi{H2o5=y{z*|n-{Ox7|zd@c`KAD%}s0_1v#d<7Iu zRxyTgy3xlCw}JuPx9}*Elgv;Oh3BnI|JDMqU-~V=4D12|yNM=_+df}F{sz=6329SO z=~R*9AuawI?&EVU_`J1%fOX%mKnDA8{2YI-5Z`10dMid^K<*u}niUB=YX`-D?Vt}F zAE*Oe@sYF}xi5{g0PV>^7rq860#6i;FNX(B8!F;wdxIobZdxGdne{=`OZplp_0%9M z-ISyM_M0ikL5~o-=g4$QgR%hZ&&=afx4~-pg}uQ}v6f4>9f*D(74y8_c$Nb2cNZ__ zp~D{W*rdB34#ThT)RriK>Utrx)U! zFzYcgwr8*?y4)_NQMQ-@FDKB0-4C44wF~C8z=`X1_h-ZA2&4`_M>Fa@iOzd6+$+K@ zG3jnpv+RlPr1e0T8h??`|CFVb?LO;oJJ8{71Umf-Aiwuxzj>*C8nmVZ=aMV{2qfMH z_1nU)j@=iaKk7~C#I$dV*iHyqy|mo~EzoPA#a#CVf}b6rnt$XvT3+_AK1rPw!h8Y=!td{VzXY!Zq#r7tf}`7dOi=j0j~HUPaK zJjOYSQF}u=#x?5s8K8A7zq@xBU4~wa8P1KYvG4DsMSpSwMGtvBkDmic0l^c%o0|{r zo5LNa!CR`DqZ%Thzys=$aHuA<`N^%yH5WjIebidK<`6v14EEh!Lz(&a1&{K83udXG zKJGDhM->7u07bkyas?;%yW#GfTS#xztk?rB`0D)uX4EQaZ8=pBxZ?Zl7o>In0qkDR zUC}mU4>Z#6*P7_$ftNitY!P=a43uZiz|??4FESXFqbxMw+nBOJ-2JFTN%>#_v?NJ5 z&jn!x2&iXj947V4%os+y>EDLXcEre_z{V!*ip-#7w4izMLo#?NM9{OO`P`Vt_|-61 znrnnUTo6ii1+=-{)M^Ph12ro1An%PkTFC&;jJ@&n^i<}2J7(pR+Y_F>|m~%$8vHW*<mY5vezo04uI_~1;a$6&#o_~ zNkl{h3vbvI2jy@387|-B?tmQn`g8-<#Hq;xP|wycUVP*o=`-E@RiA46=|iIJ+#?>t z&ri~-?2}zx)oDX6B_!BvSu~y1fKKaPs90H}WpG-9c|gi`S5o1`FP-TbEmVQc1C_O(oOiV ziYl(J@E<7FlEY51sSM_=9l8t-w?bgvL9%R$?_Pm2gH{#LJf^In5#=UDA>X#EZCFq{ zqx~d$vjOSO8TM8yd#Jgo#%Z(xlfrwE_-8xO6;M~-vQaa6nt>TA90ZLvi{>#z+cPUm zXV@iA^y#i%ts{-nP8IpJ9G~~hRw37O2263;d)1edNa1yi!yv<9t4qg?C#q%FBl|0b1^`KBF6mrCM2juh;!fho`+U`rQ+$6#tZ$B47d{a z^^a@XR8Bxx7U2j~5hyz_l9>S|0)A@|w}q>cntbmR$_5uuu6s5F`~RqGG(_Hex`IqW z2^hB$XX2Qp?FyZTzoNF89_$H7_q^3n{NNLinQqSe2{d0@n7(|u%u_qH;4=m496$>F zZ+ofeHs6e-jDWZt*nW|8+)8$Cn`aUS+(`0jmvIf(G=GL{qrrz-1O^LL4k5t zG^d0F%F^U&K3A|Io4mO3{bhAJr5M$SPRw=EXhz1T3ZNAZE%6GJDsIP!_#dwo8yOMF zoY(R9VAryN*D!m#_e`dKA5jRPj!bZQFJIcI$Y73}_-K z&hDps{K-{|1$S=VYMmwItrw!Bcs-JGsh#r9TGgODTbB<|7_En1aNt-fQ3{bmWf?bk z_$v=ybk&;hrQ7A7oy@wJWO8g7HEJ4N!cA#oWc{A#UwWtvnDcb8v4!~$SDmB2CPt)q z&BUIcq`qkf0v$K~or9ZOt=ItFN-&tq&N6e-_$dI9BG{j&0oxzG7mcDeJ=LV!mx&(= z6vnwUW^6OE%*|yc?F8H%qdV)Otn&`zf88`@p{DRPktapQoHwbiHIEH=wm7JM;uC43 zrKRH?HT<~O(vv=1@BPH7A~IXD@O*Iib2soP;G0PnE~j~Ct!Z08q$FF3kN4wqkTN1r zrE3dKm|A$FcAB`&iDwj(6XLoq5CPb}-qNpEBLE7w0)!kyzPG_0F1O7U9D+3|EQD<< z=oRO!q=RooNr4k5R9pN7Z!wEo{t-J$?lyN1$o_574Z+-8o6d*=(`2NPH)hvuKqW;) zv#=1cNHOgevt~pABg;vUncnLKQP(m4vhQwY zip=U(+XDE#zflZr0OmFVd>w!q-!QpIL8EDeX^tGv6hu&uJ2hRefX$$))B#s_fX}b0)6j$a_^{(W#70pbMn}B z)@;@U=qh%4`g6HQrF7&JKZhPQ*&xA%+v6|PK$f~a5s8C<=AwX<@*0H_t#NXb>AB}dO%Dh zED)p&M37QS8c|R{K|s1h>FzESL22nmLh2CG9g2WR#{ucCLme8)-`x0qzW1*?#{J{o zF|L2S<2{_S_g;I&TysA2na{H3axPY99d@gz-j$^0gNpP|z;k5w*&*kr9{-31#MlK3aQOj@w9FoSCr;L-j9r_6w`ZAz}Q04qQV*0$8*slALjH9E|GB2n* z6b}|!0=aV{R)qkD>my^kd(NFha>9FKXBpBJ?gGlsWt>#Ry(h(?A#zdjIi}Q-lKUCx z1(~~d$MWvZ3U78iGQ#|}(Ji(c^SCW@xS7x8zMo9vrd$TNxu_^C`k(&x%`ey?4L+CKWs4?Ci~c}o4HRw83L6hScpjg%J=*7aHkHt)R@yMTM;)tE z9{dqP$eKfi*?8k};#+uNjs#Q~Tlp~{hqXd07%s08hL8;c3k`dXLdjy@i<+21 z^W5!`?ur%AzEDuqE04A~Nc(277|o@`WxVwgfMMfLKVf2>y%ZX41UEem>nP4)*<^LK zvHs|9J42pYGcY-$!osdptWJLNBqus?8r+0#vBwkhXAx2h zw0YW$1{D636AHf4j5oq`$q4JJTYPsgbk;@Z)IxFXD7Yq9iD>kJjJSn#avJGq>i%S0 zd&~G@p`gPHZ<4!QMH{i!<*6x!xsn-pu3P>3z#0$S{dNke#J>doe!OVHs|&AZ*j@jA z{r%gffx?iGtWqOtm#HgB%r}nTzTvfw{Ei)AZ9KHdZlY``Z}x}7nbRw-s6~h+UNPLN ze3}OYNkLdx6O4c8SD9jYWB&$Hcdt#uh=NTn7imO91{k1ohdiytO?No<)XHDh*JC>$ zfq;*C%$wDve^;Bl*C-6Db*4pKv#J=5C*+J|B@nqBgku6Yz1GWM46hiJsB)`=n}I)j z-rOB!^6@wx6{ z-KnDv%{g-T@0X{F%@ni~DLDb`gJy^trV^q&=8#RPnIXYoQk(<5#fbwo8W$Bb0r0i1 z0nPPsbE%~l;TYZjHBAH)=UTkB_Kf^`oO|{BxnM-tfe89E)2xlE`^uMdJMRb)APUdo z!G8}0j1(jh9)aC`K=t3NqP&6okGv;}D&W6&^Qc2c8Qum(+&Bnb3y-cHM=I8F|QD( z-(mVp85ADWa`47NW@z|UOzU!6_~^E^(2$Ou-Uvh4)%eN+4mQ%6oz>HH1oym8)3tQs zP@Z%%@E=~ceY`UdTgLIuSaS-Xu7BheKxqfix}!u%tsPK5sE9~J&b%fj5s92^)SBA^ zXCL^mp-X1-^YaURx!aFuYDpsNPLR$RI3(sO=e;f&vT6oMJ|rYWW7z^IynokcBkn4( z($m+s_oHaF|979eD)~C#oHqJjQ_6hF=pCE;5kj~;ciCX1vg`vd9^3I#lgB@N zfD}W+&!4eEt^q06!tztaoqg<9YR7V`&ooSgTJfu-DyxY zbJGxN?DR@PV6RoUjU$!(udU-hVjG$lk-xk?{>#oPIqQAtN#0lZB#GX~9pFVSem|z+ z&HsI-b=Uqm%}H~~;f%z;uByaM2>3S=(1>0cO7x{gt~9gf;Bt-mAP;Q&71Ae81)z_cQ< z4d&}g0ecOK*gD|<&;=-=?^HA%?Bu$K33f*Mro=U6UkDcpLAP+TfX|m}#Qo?1iiaq? z?m;d5>v|uc9=Bm1du$&My@siSRN>D7Dz}jIpSG$>YDMOKON#n=wE!qVZ#l!T0qc+z zhG>6hRm|tIBWQ4BwViaJKweZm6oa>K8m`Bv&VZ{v*cycBL8H_n5vrhpYMY^ys|m5+ zDPk(+Qj2k@W><@2Z43_8`Sp$OL*LK4LW+5cX=kX9-+vr~tL`ALD605&PB`gFR@;O* z)I3Xxiv9q=Shd)M*Lvoe1Yl!NB_)x3$ZT6&ZpCsrz;dc__w>y$*-etgaLdKsWq#W< z45R4jJ%LJ_(?T3JvAd{T)ii zqUy50+GsyQ;X;(0?jugH{>YtmPBcHbIfH7mt>SoI{74^<>z)6qN}2dk2>ZsCtcK71 z&;?l5HAjbgObVG$m314mN+`5kq0%sbR=64>W0;Xp=~)HLWyR@@mWR~LU+@*vaO&=x z2^mqQJq=j8L@#85vHH1v*GT_BZj<)ZJlmRxc;VC?{3R-9{c%Z z{q}eWz3<4S`~sGy4>{YiRY_!I&i(lc`0~GH{?K&^0425>MjMcssdj2tRb2VXiU2#}dB@DXi-M_Ay zXdD%2m6DZ|=VD2`sHnesdaqnZKJ}SlAFKXCr$XjSLtyac<>dhi8OyHyF7TqLdeY`S zWF41vm^;i%%DhYxsA{~y#f2ICblLMl7EYd$p{wDOu^@I zTP2$hQiVeG$BT7W_>kMMTV^-I?>Fa*_f*t7pt(X!$vFp%+%;KttzV_A{lFVuSaqav z+Zl(^88j(|EIz!T zxCW*5rUm`PGy-$YHX~D&tSV*%d(nD$%NkX8Z{u7(A+xV-7{(;`$J>3vyk^fDY~S{# z8_o25&hm1s4v-@Oe#utOn}Cs)my?5@Rm#_qNcg!~+|o<`8mX)#nwL5=($81-eD zNZ_pXAT@6!CsY=Ea z(>9Oe=IHF~JaOv00jwD4As4~$55)$}XXDb-eM%PW&;_2%$5uD@V5gwpMEq16SKBmN zg?2jFRo^=>?km$KQB@-I3M`X1fTeE_+iO9&Ft^!Iu@0*U^BcLzP`N;ANmB1l3;SI3pJq7pT|>1hV(q zR1;t)ngFsvsqM(Q88NdQsqkxVn%#>~8jn^$_dl(!|w7xaSEsv{Iz*3ETzB{ zVNjI=^^qh3I1zX!`{f}+Gt0=j!6IWNSeDB`(FXh3oF9rBd$K%YsGY#Et{bUtDP5}U zOK;u^hxvv1g>)I7VKH1S1EYVN}_iyd&?10u# z8%@&z3{IVTH&T{46Rii<=2r+qU|>Tq=j)#zVPB9a2XhFkJv1`%0W_5X&_IyEXqwMx z8NCtf9)Tl?NIrUU#G4UPvascoId}9lF%vF;8kKmcZ3N8&xZwlH)9z7?fC$UsVnKV3 zR?P^z-}m>YN1;4L5lX#|*l$g`NAM3{=UrZ@q@NUz$klTV<$t7Or&^)pucUkD`%{a* zSg3LA|MD=kUFK6@ARBCI0A3=6JNPHh{cLCu7d!dWwGrZmV)wJaHAqSU8wo|6>a;qe>T6!{~TMNvC)oA z=ohkEuEeg%&pzb1R+82!?{)j?rTkqox>?wbqF2cS@9X}4`g_M%MqPaf?1r}OGZY@S z;hK5q2G|2t>Yv6Y_ir`5Al7>jtN&QN?eiZVJr|7Ih2CE}dh`VnOHx&NF^V_pdHl(MgLqEVjuqHZtX)*jz5;?q>OZ+>W zh2L`GCyck)eF->|KP_zXu@6aZile!N-ZZLrKn>T3$70soLneXBWc)t4`Tx6zY=~I!XU${S~v$1 z0rLwNkXk#?IDnch!R;YyiiDdX;o){5GXYhQv%(r?Hu~Q1^MTR(E6hSdBduB&{mw^7 z9<)1dOsleH6shtrI(9$jaWw8YMMUX>`+ji1cjDbduLBB4 zMsiKF!Ci~P?!LD_g|O{k87s0Ux-LzV?ujeC!wL$vxm!6MKE&9d`uGbME`aqi0ecJ~ zemn&3qi%aFyu6Mu`BJNyzEw|~O^k|vmQxlU#@Uq;%D{Z84Hi1qN z@{e$a9SOuO9E^;NAohVmW$WAoVOY=L=RmMv-0|f*(2?f7#qh-gs0@!DfZqcb08^?1 zw(q+yzb*C>tk;AOC8T*7h00}&ZVXE6IuTKpae|VapM7;>VYCGB z;(D5b?x_`6+q`;?A1V8ynZ+4>gNS63H}Q1gvcP1q5t8yuk+BHv|@jy;=RAE-_rZc(JnR zPaiBYB=HT+ffWtTs1UrgCa)=3S63IJ4FrO4)msC`NKH2^s{2ACyxXyT_qq9_;>NKD z$;94~v<@!9rDdV@=dzzFmCtIO%}09U*RQ7%&=jbF{)Vwc)#7V+;+W8DRpr}$ZOok) z!2yux4!8buzP6V9V~RS=gqwQolE`sEgiw2Bc0++>vr|pwT0Dwh`CBl z`tw0>&<-kDAq@B3ey#TvTns1+Uu#z;GfL(T;rgplwP000MQ1k`bl<(fKS9vCk(zd@ z{pj)d57p8REVH|DpLDhQG70LCv1jEgmj)-RroKAEBP|LomALv6*t?v->6S7AMK2?x zOnrtZ@QqVovjGJ=C!Ton=?%?++PvmJ^pEQOCq}B0dncR?$(h;Lra5vB)qBwY;{qH$ zKKt>=Ro52Pcr@&goTux{bu@|>6xUG^!L2@nTVpckvE3^<6qG8s7-nEgMav|c^b=w# zFdS9z>Y&3{x!Q1z*R}Bv5dHu^0E1oz+wefqBjaF3b`T@TXL5e(U2LcZ1uT5hIrIz* zd5s%w{J}k6-ujT2@O3C)vWamdqpoSW)p7^BfX`1hFtYcSog(e}@rJma-S0#LUW|4{ zL+Om4WdoL3XdCjfF+AeuX@vxyoX%0syK(=1mtFz=?c2L|VoC^BsN%J+-t_-`pR@Mr zSiQ9>hxhh;n)rN|m(EnXdF9_!EpKAhjEsg-OL3i)>lE7~#`_x~n763?M{}*?AL`@C zQrDP{zR(EduA9%ZzzmBmOI5M4*_dhyX?=2|q7LE;kf(&A;^}Tr?KT&^-!Nb0qcJK1 zpd3xE*>SMF&`7J0>}9tk*O#NHf9{p6ETyofT5-CL#L`ekrot6m`v3uH4}`GuD~+jB z8{Zus{#Ng1zH#IAub}JZH3xRZd-{2-6qU=;!z$9#0rP*jO#wN0;|b-ely#If^8&2; z;lYY~T3Q+)01pRXnVfgTsTTb|~`WRki%H4?3N zs17M{^Sch=j5XWJ7-A$<%X&@ixjD6}?@%5~Tk6fkQ{ z?k`S5jiCmnh%dnTaGh3g|65yvk~gtxY0x!MYp5hIeB({Y)is*{!u>^#97^SQ4xJd< zj^UoxuB(T3DiP!c-(L_F@qHAIG>(pYVEG!7&1cV^1sCOxY?9~S;G;hJN8+YEGrWS^ zIU_^?UL|f-swKVkz5qO1&)m7+g%$ap`|6=9?rk(Trr0!79ymuSK39-Ic>Guev&2eO zg&S-boiOve`}xI>U=+D+XRsxUc8*~$=!U|+eCyUN69}__#v7g`<>fb!xn%8R_EoVu zr|;&KKOYQRDT_?ep_eyTa{II*(wf(P$iBsg(O^-XOAgEluVhllf(PAF-i!t&g+rF9$` zY`vhXDI*O6apLg;UOML~UZNbe_~mL+|{Gr7Z=hQ>Vk>`k!A zp!)d+3>id9vf!}+y|%HT0hq_dR@1)~pR5mEpl(W|t1eYnvL%_Tt#I0YC^)x}C;cy; zff$P6_U&-%BNnZU4D5hH1lvCm@9Ohc8`fqp(OkgVfl2=MM3KQ~SeXQZl$s8CxrTP& z0CXrvWaYmrjUR|2H%fNdAAJLC4aC=kirOgvJgNW!8eVb)YM-F<%Tzy2_u;hF9~zH6 zM_l9;GUt{`Fa>GYQ*~+_cm(W}nt#fGB!FOYu$rqtCl^BJZ+ro>ptCe<(}umQS)f*7 zoS7=){n6i_8h}7~$f{iRst{aR(~W9>63Z(;^l{Qy_qV~&1EOoG`U$N`grzIXm)Xk-Aa!XmtVDzatkAP8DoJk|UlwIja^mcJ zaXlrux1V=~v+V8~D`ZaLUdzeJLFx+%P%rh=#Ngpb;!UrK101*wb+=JR<)@vi-s{7y z{L~f&SKgkc*;#QvT5zcS9Tv>_%A*F~s|x>Q4(m$ABCT)SEqZ!TIsy3LHRwow`uI_~ z+NF$Z6-7WYgZuFdbYY#~84%wB*I700&dlRUY7uf08t4{4J`_u^7wX+ z^GidF5}OOoL5+F^6kghg^WVoQWF}U}4|M{g2iYp!T&oVt?H1XE3)%Jyv2bpcru#xe5 z%TLd>^lmh(7U>iiHU^};X{6*bi_II9c#Tiu5o6#W^6{gOPjD#s{3a3c{4m#@oSgJ> zLEVk}`t?Kvei}b5alJTHk+kKErn{@$TYUfEknPKC%lkJjIiQ9f*PRgc{5$d+lpX>o zxtM&1L3XdR+}1dPEsRCYZsO-B7)IZZAA?dj^lxRndT35>Q|&Tu^{!Q~Ac|Ih$jmKh zRb&rM+$T=WJ#f@g8naHJ9?w3R*T(-K_UGLk&5-BPZ6@9@%BS}(1&~UD1P&RqvIT6^ zYSaX*&>8HnuQmWAA6LR}#~;$qaqcqCf!UE$KRoZ`fC=}kcx3+vrCC7^XW`g&@!3m! zKP~znQ*+O(5srf62a7I$M89!#rTql{&%=W~Lx;DYyiR+51_)w#v_^Q6tZ%r@rj;w$ zX8fI!SMhdY?8t{PU%?ZQb06V%-Q589NAuUdGYu{6O8Zk0J>V6##}URc1bf}0q#k7bepe%gck_j90U>k z8i3ec74RsuJl$OZ5|T6I5XbEw?yb-xT?wH*U|`^uK1$t`mK*;OyfJ7#a_-fh+Oo{_ zw_3a9_qxv9D*=&VQW3krViLOXdbiNf($bQctr|+&g{UY+&LocGjZdT{xM7DYO4Nqi zUM9Yqn6SZpk&gW}-9dci_jtp}Jt3L|frwQrCvG+`d+k~2uW4wf&BH)px5NFvkaN&q zbc8?0hX=m~nqH*(UT?2$2?Fe@pLdK#3X&h~CX-D6ShzUH=#fl^!F zqqxA|rSt_CG?r&9yt3YuQr+`S7Og zxBphRG{e2pJ#46kuoFqk9!j00djLr!9m5|4SMH{=sBxM`V`N2#;oJnP$49#nP8;9& z&Ut)!0(bkmklPo_8_a2w9?nw0_k1pz{o(rTU2a9765NS@d5*3GnwQ_56(#O3XOzij z*P~{x5_kJDu<%zWuTW&rOW7=BE2iO*o`ata;fAc?a;2PfH6Hrgs&ThHuX>##>Y8fu z`P3Oq@3fdtlJSf9c8TrnCRz>1(mVR$?S zz0Q|8)zp7^NGYf)q)~Zy>T626tug&=CRS<1^FCaz~->tu24~oiGutaC5=ZcT1m!v8y*%XkP*&;si|SrEaa1Ce<}%{snf0@ z98xeQ0)-7sFTe3!^5_6lGWPk$ha$V|)Mv6ImC?NNT*knC02dA1H@PsTfznlMNn7Q2 ze3Z-kStER0Xlp7%{EIj~I8p^DAV!#tA#0z&5D;YJen%5hWfNy%K6NnS+q1mrTP9V9WBQ(te`Mn!*X z?mbCXfE9*+u%za2siYeKmw-X@629h9ala0h5@l+9kso;@M&)W58)^x zHo)Dnbf{NEl$yVo0JVou5~8dPh>9wP#v$rutJ${#wj{m0B9OO4a-H{(U#k`x z0LGCj9fuuSZ!uFUx0weU6%H9qh^EPA2wdJG;CO%+`EP(L$jHfIi={7^Wznou?t%g) zQ@aX?DdoGs60u01-9bSIL_&HpAK<~Qg}(Ov9f%G=J1=|#wzJ4#=`N64ZAJ2f_NpjI ztyYriOHb-( zn1e{O$YRr0;pYaE(uDs$Q>7xGfBo+>lEZ|{gBlf7kH2SK>~?rIcAcsN$z0q)pCG_{ z)Udrf0uD#VYh_=G0=5?v@yY+a zxPZMFBleo>8(SX>`^Qh1(D^Cz(VEI1vIE}N9w$W_og+y(&r?)k_OjYQ83YPSZK()2 zVP!yvJnDG*a>9G}+qZKveKzO^ZY)cxZH}b!b`OHQ8*tL+PQ)4|U?WRry)#aw>XXr7|Hxb1*Vz^f@b0VR^60{)#72 zRgK;$SmzJ@WwK{bJZmFdQz}H5JCWFk`awa|p1ZiNf9SGZ(s+}PcG`-y!&l4K(Y5%a zkB+nJ7NCrvWff73^S6M)#ntTy^kg-Su2~`ZUL7?LOXE{E)+m< z;QmyIj7v1>_W*ttlqUye{L!DZ3M<~tu>Qees$zZ1C9Z9&jUt^3%*momkWbt;XiwWM zOy<+0{sM~>a%oN4*l#aVo?bxTRIX+B15CZ@@u!OvJbdlr6kd6NUO;}AjI~8g0MGLQ zr6$g@dieXa-E8u{i|vESj^#zN?75Sw77@$Qi4@tG@&K$(-ugB3%JDFhGeq1mOMq$v zn79q<%8>MJ@h2uShcpNyAQ_|7~R|-Lo(-=Io7*4}{NUB1nN+s?xYX7a*EW^yc ziul%Sqzy>b96S)cS!pZn`TmBO59snJ!^v9} zAgBwHjrHIKOJYG57*bEg=A*3h07x2je0f_B4P`TM=;gQ;%*eCZwk1Q8@c5{5EoL<~ zzP?$OeO=Ym@3o#mL*wqB_v56+Ugs&~(qCL(p9F3<6|dD}q$p&G-w*iM(K@Ixdrkpi z%Vlw5d(p^zLH2_6tJ3%R1r{#xF*I$(s(80BE0Y1lW#BKZrOGlyPD?8cnVJ?& z#D9l!k%OqyDCWm?kLV~9FQ}tGoJJD+l@68>Z2nj8-MH~C0Zhe7;T4$viiGVy>+1y} z1JO1p6~=@Cebu8`JQTVENBRZ%asyubWriH_HPB@?5<*d+eh?6myfyX|e<{zEgSqkK z_3PJw@kCfkfd>a_t7Zx`sBg$G?y7dKb0ruT{mOv%QUb5}5J~`qqIk?T3D;2`N1Zs* z4!AwZV{vha_d54WUnGjcs26aPpmu2C@&Mx^oCriC5U^gKUu~pq2Lu`c_eQ~7*lZaW zb#uiT7g>a~>cy~Yi#~hS0wt~5wq&SpVA>znRw^3*n#+iHpJzi)(w%{+z@}cxPEU`h z^eF1%p$Kt1C<5;blzFOXd*kgh{tgjZjCvhAbZ#H)bfCP0$%tn(u6Wm_iPlh& zfKJ?y?yo;zHGrjIPlUnQR+)_`H5aKq0JIhJCQ$IUA%OXiX$s|pP#jKC0ckk|n@@0A zlbHVf-9FF!Ga1O7!CStHp8poE?p1} zK^-j69g1ZVgtnG|0Dx2#Lx>2Nav{9Anps(Wx!_i}$S41rp1To-VMOU*!Sjc?B5P%31%iU$Sxi(uiWhJM6cvd4 z!yrlsD&r2oTl%}UD%9q|tsqaoDPME7UODdM8OauR)EP5~W%U7mJ%Vfj7*ESTizzh2B1KY_*$VKK@PBtLHE2!R9 z1I7^cM70@ z4G)1dodV>zK+LjHhcme*nR2VXhoQSoj_!1cLV@Z zjDy9is;Ua61u~j5^`5xMzd@lOTwR!y{of_8CJ+{cA2olm`_UniHiRyO5Oc-fqaXHb ze&?+$+EeGmy=`|~t7y@Ggs>q8BdC0EwMjYes{sc92sDV)8Mva5D42s}^ww|Q0#XW! zen2sx7!MGepM7sm#`SGFm3Q%{*KL-Mz@+a0Z~6?eN){yVAvsPWv@-^%{RqrOh}4}I zTB0amvjHfiIf6~5y?HLSt+mg^GVtUWJ-B)g=?4GHtV5ST_6HR1SGC*^ria)0OK0Pq zDY;D|gM%mP@Pu zK{!f{iZ8ZoxFBTkXoK#PR7~Og7vhm5wP7aieH1mw&i*q`Ab6up%IgK&Yp1PU#yk!4(lt9MrWqGd5-^bJFg zQ;(UtCPPraKEh(K*aW@>NWJ||5IzEp(Zxe(oGjQPSnz%6vTy!Lz~kyZ61T*|3JDYho6wd*ad=&O5BfTv$E-M@ZF#J`1rGy!-aLgW$lGrQUV8LeAzz61aZ+}zx~PfmPIOIsPP;DPAl@7IqXKLSI6 zJ`P_VYQ5H3BFz z@IW7$z#anBk9@ul5l}{F3q+-vMo0rk@!OjL{pK_g<;#?(pJ6iZI&Iv0)6f#f&%?^P z4E<0Jqwm7g5y~iEz2B8r3wEy12xA1NL4`3X{BCXHxT~|w!`*($R;YmgL_K3piIYt4 z6k~M$Q{PIO^Jio@1?c969VY#O(}3{tF5gvTo=ih5iJV*)_=1o~1y>>w7T=!P9ISmL zu?!>|Fn8;QRTYq9fxHBV*{Wj6y5GvktJ%~;?2-9_b5wX$N`w!(G}rsY4?I9ToM8WT zo{7@Wk{*8qmQYGk(h0b6FprCLo5P{hX76<=CxORg_HT5uQzVOD_)e<|Nfq2Sc-M%B`m)yv02V!!U_ zu)8PWP{6g9&st%vhf+ZnD?WFODNI~A@*`jP;EylE5hO5a9H%~ms0`$i&r{t0>8o#N z2rUI~SqN)qwE3BoH(Fz+$}5OlT+_9bWIHXlL2e{h)9!L?Oa zkF|gFgClT0&p<4<=XWxn5j?)M6X)?I4-$AlSkkQ+gj_C&M2~q3kd?y@(W=S~!2!(l zsSO;s1i-|AA8x`aYy*(L1-9a>ZxF7Qs64SqRjV_MA{u#}uKLsYI^Pq%@^!_8>NOi7!vt7ukpIf%SO?{?jE23P-pcxi71R6L>wr zy*U~nI^G|}p|4r(!pq0USJ+o#frCx>aP;Uv3y|grRt+Ig1UA{;9xT`SMMM*WKScve z?RE(qPX~TVOCZoNO;|OK0CxbdEbn52f-2J63arO(Iu%L-DXgdrQnT7M@sVfT}v03A61;6Y6f{AcOT zGvJ=}=NQh++BO9_yJC0(*Rn7J37ZAbYhPf$d>7bkSotlkmP0o$H7cQx{=L#=g-$!8 zh}6RQXfwpy5>uf@i3CJ-JNS|xO-k3nPYXEuIH3TlxGc3FW){rtg(KUhO0$Hm53|;f zK)g+q#pRK?U*C?gjX%cHgYFSLqzjx|z-)}P3huTr;1*k+41t5v45>}vloIsPgMewc z|G|43x$@`v%TXO^w!17NO6Rn-^*5d@1M&06Ha+6Jz`g^G)jWz1lg4a+bmg?j+rqRu~CREU-ng?M#}Lr3fH~59Yh1y0@=LVK6$+ zJVY^F!>})~as7Q+^tEq9BuKDNf(yWBdZ7}=a<%l+$v5#GpJ+Ggipq zgYqK;3Hsk3Iiw11QSGQFtaQfzU>Z7h&``fFgPkCbyyP&95e!@d#~2mF zNC_DBe=O=V%Xui7oi5k^aREF~fDe!5z}XLC8YW*(eXYM?h$8JkaNgIyBD4D^Xb4ef zPC-k|{yt9F{{oz4e~>o=aK*y}e4Nty%EqJ!C$T&-VibV@G-i>W(J)L=j4?C9Nd!e#OtZJ#v0=s)OzSY=k-&Z_Qq_<#l zp)BWg%-o_k%~*9i@u~Ndw0ezQfmWMp#=9elLWNK8Skb+B5W!N%z8GT4s@1xcJ|y+> zb#xa^=gkiaf7E6PP&7^Pl_dC6RG0ZPU;5+ae4K z9xzQx(a7v=%H`e>%kIU#;hX8FK%v~gMrLX6hcqu~@-q1rG*w-5Ht!$;A;Onm+qwlx zs<}}f7^KPiIZr`kxhquf|N34@YqL3X5zg~T_ea8Loj~yOoVoj38dEK5PNE1-!fYwA zkuRzIUGeZ*z}!cS3JTQ^K9fcBW_fjyY8oSp?5E@F0DG&|m^mObpYwnD6>^EFpex8k z!^mYzX4*V!R5UI^E>%GgdA#Kkl*bnl$V8mb=%G(oGwlpN!S@PjQ7W|2>WjxYn-`}a zHBhzY@e!ivGX2d*Cgpd{44^XHa*gL15aVelPqSI`Q5CrrjYD^UhAv{PwXH5le ze8w>Dr+68;B(mulDk|9)!Ch+MJ;ta<=VDG7jjhO%NC`{mrpO)AsC1?6+9Yf#$X+3A zIEB)IWZG0OEK$&qzP~Yk(%U_HLq1AES5okeSba!!PXx5&j0m#s&H9#Tv5%y@Xp--R zaAs7L3n%L{pGBe0JR35^L!n5G;5AUFL@%$?|KIu``kf!N!ywers~7~}0CxCAZvoUR z7Fba)UO+At*><=7yg|;XYo>-nMWH&S83=V~*l66^PN5EAvXPzxA+N)ZMnAY&%;MZG~;J8UbOc>t3biVFmV4yn) z?Pmv^MIFNUk=}q?juaZouTO$g2Ai&Q7hrxwb?iKd5AbXZ@609Wvcx)MFS`ht*B|G= z8qNKJoy+4aAm|@ps-=|1B2_&irAWZb$co_UCrHhp|3v+d%Xd&eNa31vOJtiM5xELm z1TPiNDvlYV=eqx{?I@ zu!iU~Dhi&13z3K}R7D@~XxbVU4O}sqt-0`38jHl2XW+s6ndO<}^7n*^wmcFVK5tZy zMD!?V9Pr#i=>)(O&uuVxX3bRsk-}0(!1m^$e|cU!7MXyzmJ3lHLu%k0FrEMMHXZSL7~OxBlkux>oi@Wi0IGxP&bHq&8S8FPov zV`ah{ji-0%0@n(aoB@caJpwyWYwcTj=egl?OkvPD|jc$GQqR znVHBkegfl#^K|?a4&#I5mQlQRq6}a*LzDP2Lg2p0I`XJ}eH`fGM>vjj@-s>rrhADg z^dzaHg2EuDff7-q$_&%K+BV%jWN=lyw=vq8uSUnrrk^pc-Eab$i)=BZrLoR2{dM>6 zYJ%RyyoKs|x8F3|!n!-!+}=>>;T0EUk_w6wsC@+KfA?u`n3bdLBx~9%Cj)LELxX0z zN%txWcj34pTiHWAyyli|>p3G~P<+GEOn~Y~W|I2MwZ;4QODcxug7=)ubE7jQ29gCe zd9R^%@L@WMa2z%r3RU_I2@l=<6G*rPap6Ox>fXmTTRW6MmrDx598 zM+xHRbI$T~QAn#Vhxf;~vGE2*nr31%-Mp7~w5S0)1XN;kavn8QUFtrg3 zJ?-W^y84ic9EFbui7ph%lM=cSb({nK|LuopWY&9-5P`H`6GK8FpV&7^35m}e5D`NZ z(FNX-6>J1_p>Sv|{8Np)Q3}9?8Z{mQ@1i_Y0m6f0g3ti*nt|ZsA%Lb?(s;GUc9Rie z4?eyD?B(x3JyD@X#=09HT(uq;NEAwx2-ffan-4NlcphIirz4{I`@Cm`t;K^u2xGpx zn(~GWP1Sz>>(?%}ZglGKc)AC!dvJDrS5t@(t-*@s((ppv`q56ZV)jK6HiAlIlpoHe zC2Vv&;&YVqr_2x|)bhU%U{^?35FKr{R7`x1cHPF|p3{ab2n?MWc|hQRwCPY~aP|9QHROKmempYhi1!$gOH^ zwuCQ;XUM%KoK4B5@Nng5W5O5M38Ij$K)riXVYj=;5yqNLBGh5q=eRuth^ppjw+8T6 z$3?{+8|+xXlcqyXXd|ZX;p-8BY^~fs%C0+!W~JX3(qx`Ko$F3(hhfS8qYnW!R76Gc zn8)`$QQF%ANhb;Hu$ue+_`&)KZDgnaK8DjKqG6W!^odDhfcz#xQN4FBPvk8=t8;w+ z5%w0E(EapfcIG+^8Z*MaQgSSh)6nME+Vh^?WIE) zn)N`TAoJD31Y%vtk>|Z9fv`@s_+=nXxs3#r!>#9ebcofR@TlEduHbXmw8aA3^MF0t zm9jmm9e&vmpzzpJG3TXKzOdH`(F-sR_=E3G1_Ob`UA*}j>gc(|28(QEJ^K^LPTL zm$bIUO}^4WIuQ8p4Z_of;r-CQ17ZRGb#&@D9?d5Nb)~yBKfk*!BlbAmpmQjpMg7Z- zH|-p;il?j{ieMZ84wsacE;cXW5nGq>o-hzjw7>n==Sm20+bS)X==RyYPov&qcPur^ zk`{90Z3_7-Voo-fmGtvITjbqfpH+e?3%_d|0k4-QT|~Y8mm95rQqcqvLWWr63m+`- zoT}dUkKzc`i8C>y*r;tj<@)^}t>*Y1RESmn!lbSo96-ChXy7e5+m@ZBSw_-l+`=}r ze;f7dIx=fA-<=HO$!&}6toQZt-~7#35Z|=^D!%>wqoL_}joYZ7doVs0{U%B)+`s-h zcMe6VuGhI}=IHG}kOh=B7&}L&lDB_hM_uH3q%#y;e|_uP%~;w@{n5y!>t)g7Ftf_Q zTzjDOwqg?8*2Z3V&yMq&x0LGl=IRyS8+;TR(_A{E^t|qb0Fa$LP>Sadm;9jH2b9eM77#&yAa#y9>dbIv7}-a{=g57(ac#0^uCMWL=@V!b# z72luwKZ`1~8x{#2$WINp9yIdHK0Q=fo< zV!ksTRM7n>^*6*MXEb4mJd9y&efI^!ZsE@>a6ErdIZ&=ozy|$V%VkXrfil6(|NTF@ zP=p;;+W!Za=OW$$3SSm*L`af7e*9QRCxsrbx|1gXD=+0md{^NmP|Q^0@JGN+MwPz$ zOE98mN|W_n(Vyn_>&xp!)x~@#UEU$Bx-K%}Y45#U`ea)<=K3u_yt=}Kl;1a_D={i# zi2L9{7~Vb}h0Pc-c4{3spQxWmcAIJS)G)hhGWe5P<3L&RAjG@xeL9yv&H5&%XqV3O zw%mQi#<#hMcfm^Vi;AXlSw(Qq`><4L+fI%FT~O-{or@xmtRs{-ZS%?}_3@q8(W(79 z1$@LVkQ_o;d^d4u8UGOZoia8lR1>QJAx<0q=y9j8=XTxqCYS6rS`s&9PJh=v&kJ`$ zAe7^~-HWjO%P2^1`0loP?m~9JiG<^Ecty>%Bl-{Ie$+O0E->KyisHL)((kN z=>c#`2mSNT&^t6AuF?GOM)Z%kHY(dn6b8#P!AspiCKvMa>u=D-teCC`^^h5XCL#VU zN*!*`nZmeqR#5xb)x-<*3SHO-I9g;hPtM>(>r7fl(pK5x0Ho12=7{bmqf-VQvq!U<>`WJziuMbo3eUs;uXkuA*CQ7`4C7eY^L&i z@sA1jqB6Km1D}YRR|F@Z@gktsF*jOs z1b4Zskl6$Do10Gp{>XTTq<^DK%aurc5ZOQ1sqZ*K1|tx!)@pqEbo4t#_em z+Kf2O_D*hpf?~rZryI`=PjG#MY}w{raf`7$Zxl)b&Ux*CQ?Q(X{{U40P{Pa)XHJC{ zg1my3!NRUcY6$*;wACRH;Ip zm}20m8-+S`k9rP+t+lPnhDRXTTuLQX9d%*D&pKXzGb@E*<8kE#2R{>(xj>TH z?c-@F`bcSM!aBjpSqlCL>$hgrTpeoJd1+3>ok1lVy)TIT!xye4 z0cp{y8wY1q#f68@td8TjpqIxo0d29v_83CGvyBZHB2!QazV3XZeR|ETpUTp4y00~7 zCizn>!^Thb)`N$_&oDh{n}yA;kc@{TIG0yR%_~<=5wQiGoEu~W81gElkJtH^Zrr#5 zr>E*j(6m1oN`?AOvk{UDHc3|wqBTP}WiJKJM`A1y3L78`{OBh{nlkYaYuAFyCSQ}=1FqD;V4PfM>? z61~ywG~mLmS>81)a4r#vN-dxy9kbvBk`8Yg^>#(L2&z9*I)<3R@kVWZE?^sSktO{E zNz&IGZn8;$umDn(gRvYdGq!1!a+2t}VWBARF^r<=LV8=m zu61Pt#K4D;pFll;6A%%y1o-g)`wIeXvBV@FaO8t7hNP$R?mqDhIS+(#EH+M0RXQ65zR^9=wjs!IBHPP1Bm2MkN z$gvD(wcah9xFGo2mI|Tqf)4VFw=uQ_fMQOCN*|<-`eZ0e6&3RN&T6`>)+=c`(nEp- zYEL0PhzF_^hrV=yUTd-0uoH-gs>Kn<-%Sw(P%>ecs57X+hzhNYzVsbobi1VIU~_tn z(DFMHO17?2=9@19TgaS9TmbmH3c8$+AOD2%TR6Ix0bvz^$QLAI6hQw4vVTy*ZD=d* zkQ3q5+Pf$?u%4tzm1YU=Yz`R}l*4z4IQ3NB&pwOELZIBy0YayJ753(J?7-?BC|<&# zTYzu^Ny!{IJF_$S36KG$;{^;&pH7LV+(2?PQ{a#oNHXq>)SxVpLuf(CcMOakQzp_9M?!$;np zCC_@NTz;2`-sLuiEZW#3Fx0=YTL<>F4z~4%ho1UpwFM(6>;IH-4&9yYY4qg}b}aW@ z^~LP;#BVi8r@tu9r&rTW%ewM4_=TOMPw-{aYR~-3J`G)eBwJqkEivRPB#GAf<%vb! z3$*Twj5&>005eoOP+&X@N1gOv@xGlFX%J@kFys> z6b?vk0)mB$E5~mw(3Sw>&1u{VIu1gF#Kdm1arVqlOP@Fkb(|)Py(4q><(FKSZR46r zBFEIpS{9f;K{sW6RKF@5uC1iGr55P4LW*|~N_e2U84{+5ND-8~SBxuR;TTd%$^rNW zPD(8Sk|ETGwSxe>rzhanhajzc{rKPa@87TY5u85FaFU@(X8at9l7n>HyYrQqO0?Z? zzMtc!CddK*$Ac;gT?PO?x;$Ktv0Ej73c#SPgg?&)ilKmdm$S58-?V zD7vPgq8chOA2rd(t*<-7Tg5|HeIO)HJ?POZm}dJd?Edr+|NF^vo|o^C%8kv4^C)3e z83)te%U2ZbJrp$HJE;zi9jZSf{bzqPi@9^d4M&aqv9U48FOIrc_x36;0BHs=8(_GH zu5-2GFREo@8f~)j znRw(m;9Y9-SXB~5KfqojpCM<**A2Cf!e&FI&`*$ThXdj18MObO#=bis$Nm5NO32JX zWwe~5qBLo%2%)X5p`xX|_cRirQdF9>hn99)Mw3e2(jHWDm$r-&&+Br|_xV1*^ZVyH ze>vUveO;gVp0D@oZ6n$T5?PdRS{3$m^o=6{zhUFXmxh{q>`ABYi$p@f&IdH2seLL^ z%JUVbKrZFs%O#-;sQD(V$dRV@`Wsl4_*_$<>T?IE4B})a-p$O^z#k>+SZ5iICXgPN z&C+rIM_o%lntzqCwN1FAQ7b)*`0%weVqtFQ9>*cQdlIGXZE+G593)`J%xCsss=)Wp zAUc9^CxV$`LL;_C6xIdOx8s65VOwu4nzT z_NgrGoF(*ChduHD2)yY{(Rynq!^cjDz7+<*WeGP01Jy?K?cMXBUsw&WOYH(w5dTNF zrFwe6hAiP1x^Oi+X_e=OwvJVTuaIz@a%(VBws35QuGrah@O$a5nGc$4 z`2_D>k=*(4I*2|rq$zz3mZcG6v>v*8QM~)&axL9ZVh?m(Ypj?6508Snv9U2u7g-ht zmihFlmiAea(dPB**R{1r#pKq^11Cd-MwZy5#tFJEQ8(Azb4J5hes9%9-jrjON0jsW zB#LbNzJRqFh#)ul@LT7Q!a~7sV+VO8oRkYce*6f&3|xoyxf)N9>o4Q_!FGb(W$thl zr;X$p&@D_urJo&E&i&zWPZl64K``$CMAqk!5n2f+3HNWb@UBHo!>J$+rQpg~| zqq!)5&wE43(x3{ER9JBfB}-iHTG?6 zjlO&LGY~I|Jlc=C!NVgA-W61baxWMq;)VroVC;{iZ#)i3>vUsOf0=J5z0b)uscZ`i zD|2^O)kU@TBss|NBVgeM_NdLW?SMhq?5~xfUuOBoqO7Y>gioTAdkV+@Zm~TvP1y{4 z9mp2Bn@qQ_U(WzziFS=j6|F&F!(C!@8#+Ke&NOUb_1GHxO|C|K;AuMPttyBrvtq*g3h@$9MKetxhVs*zY!_amuz49lJBl*iW$1Jn>;QII;^{r;nAQ=AM( z?8Jdx{s+cR_1Ni!h`rc?Sb8VaJ@=52kpa}vzUT26_~&3Q-}})ju>%43Jb>pf z7WSC8#`RSDE^8(Nh**L1#47265?N31KWT4C2n!odiayE)5jiaTsmr-yfODvM_+oQ^ zypQ`t>r$4#wnfdGsQce7Grh<+(a_L5eE1Nmb_Gp&LEN_t2cv9u_}#mAka-G9N^z(% zN6oUj@5Hwu2_Ydzs7!zjQ8D#u_~{k*sos0vM=(rIVc|D{mo8NTP(bvI?yP_5ktBL= zG=YSRU%$StRL(gGR~{sSnFi(aP_mM4pLXupF&_SWda&vVIyituhuk2Ta1m~Fu`MO2 z;01dSsfuAr!QO`1b3LhaCuEN#9Uzl_Z3a; zTe+JmAnBE`Mzthu8v{cT0Jf;BvPV}4FbV*9Cm}Tq3Np0Pa7Mu;Nt1$q?)tQA+qQ$? zJOM;|2Imp1BC@iwkmjtSHfMVto3Vr42=GI**Wxela&O)w>*S*j%4Ct5ixYdAQq3a!n;rXT;;Y;4HvtZufq> zFXOG!c0VLS7X)fUkgWhT0*m-9EG&$McC9IO5|y=Z()+u86YemH4kInu9DSXli|w$IzJFht8PW!W zq$PF%4h%r(8f*_Et&}@8qpk}5B`>d7bV6Os^-%npavD`V0Nq^91gY~B>v)S<7gBk3 zDJW?M@R5s)i(G3dDXEAd1;Z%NGPnZB7i+y2?bra)n?{@KTfxD=`-M*9$Uq1Bf)5D3 zmr8jb1P6R@@45GKT?qq^_hn zaIR05st%=3?%2ry!S)hkd^WunDs6d&y!QBVyOzU69rT(Y}h7mX&?L;oL#@XfUrK zrtrzl8$qR)2F?JAru;a5=1kbg&&o5NU$csDD3}H_@xvDwJ~{4U7vvVLa{i9Fm8j~1 zxmB8&sMI-q$|Hm%LPT03d36zBiTLi?WUyaGhK$G!qGTJ`&y|&x9EnU>^puT|)Rn(C z-El6haL-o~!j!yDu0Q$B%`;q=6vMIQr9n5 zwvf$zR#-$-B3@A?1~Y-o{n3YeBh=;xLnB-zQAQenMX7zX%3W(Axs76oY0lc!0K1F2 z1V$DXgD0ZL_vC^gz76JI5!4#gs2}i-s1-MpRO7$;T^Vn?P`mbQkS!76%B(sp!52`yx941M_F0mlYb z0Bv)C1%inU%c=~tOOzXro95VwwZ9J4S`v7h4Blo4NN9Vz#Qd9=BD^H2>g?<+MiejY zU4m#DUYs0PU+5wJEwz zg)rEl5nMnJ0*{{L0)fz~^5s5@#GmS)S9l@^6EaKo`QNoNS-T6RtdA~OXPn&J=`fW? z`=U>s@DNG6$Tu=F0*Llqg?l_?3Lju>ad27!YK-e)A*tgg-mKfqN7WKa_f8v#o=<+& z;2JO1~dvG@C8K+!Q6Tqr5E35kXT?is5KzCz;z{=ip0gc zT{4s$T@GG39%@PJlRm>yeCFoeCvtLfw^1JW-lp*$&R1n8h;dQdG%-GoI0yX1`7kW9 z-C*VShe2$pXhqr5PdLHgoivxcOJjNJ6U$T!^4Ex8`z6k4eU@(99&U%%uLej)Z#FE=8q zigPF^swvN1qcl*jOjGfcwaa`xR6l}GJ%N7??1MT*R0{>8X;*3`;NTADL??;t=io2} zh8i0pfo+04_n|f3TJp|U%gjhQtbTuuimS;+DOu{4~+5~}-pR;dZKBs+|JguoRC zq55TJ$RCAvuq)Dzn<@0JfBQKh%%LKk($j6TPSe=CxU2XSKhXvEcUA#W%x>Ip1Ywzl zFB(fK4vt|T0Re_~`L?`_QI^Bt0E%Cfl}Cf6lTUa4ja9EsPim<}))aTF5!X;qy0!f? z{jAjKrTE6@*CCDLsDGbi%weHPg1g?;19tHM6k7C{H-j1ja3!R^%c9HyPIP3^-=fjo3;?MMzwz>SZWo+LOE~|G= zr2M$XttX%kGoZ1tk*tq^GlgZ+tMRL%o?r{Up;tymPovID=*^IpD#^$P?FhHd^W(!H z82XlyclKFjrO9rP%(#N1gvHrLF3u=83Lsb3ty_1oBjpB_xA75-W?xuAsLW7QQt|=0 zM$l&FdfJlAZ%ug-k~i=kdb~$${gy32h-4Vm_~8sfWHWW!l%Q7B7colMd}OOvc!a-J zz8X;;N^RU;>_7%3?VmB^=u9GPA~xg$Ji#1lG=yz?KZ6e@ZM$a}m({kUFr&puwkc8x zUrMABMA#ZB^LJA*!j{`m--bO#IU=bP&YwSzWpHY`70nbddA3Yv#H&`09 zhMM%N^DTbK+Mr6}t3+66JpdP7SQzOY8$cMi9BT>(fLxqVsrg0>gse|7TfV5JY4)hT zLNLK`+!a+W(JC}E^;+8kx{QNG#nx}yWKiaC9-7z)WK^J)WP{CsC}DMVb&t5_=FaGh z8~m#4JVZzl!urW=8NSLsw!%g^M8A-1s(`msTU!ez7x#%b+*jyqP{e6$CR*D^O0*#8 z(-$vZ^n(T)6gW6Txg=-?2{ckH!5ystCscA$Qrxtt&o_sgS7;1x-loMC)cm#-%a)v(SS_6ZvofZP7D7EbeXB50}#6FkF z63lrDP9gv`V3vHXDOEd3UWiL&Wo2-1o;Eb3LzJc!)}B+iyMGQ;*eJSQMu;62uxiiv zv**t_Nm6H!SJcnb7y=4gyU_+>9s(8vqTjILVEh_8hMhabp=Q=^=K_rr>CVHELJpzg z?JR<6aBa-Q{~9JO#Y#e>$TO(L+#97`GU!N%1w+uG2JRq&hrI6%)N-lqMsA}GhUT+YsV$l9r4|3ihxrR#jgY-}@ zuKM+3{78t-7>z^l0WKo6p261e!{j8UH-J0gi(7^e(jY=)h}e?uEu`&Fh$on1#nga+ z@%cln1krIXIvN#JC+DIA>H4yACW{Ay4}Di~O_9u6Kr5v$lKcE5=d?cSco#JUYk1!{ z>}ug%EEc~i0ondqXE=)}Qayy4v;Cl-rSdxPtKZ3+(8_MJikL20ieuwHO7o=XrOO77 zKd=>TbqqPB8F@=NZ<<|#EBDK;xBs~L$tM$$l51AcA+%e_RV_ao@>XB?3@z=lix_NP5jNB@?~)mC3xjj-hh3*spn=svKoDFZI2_?;3;k7Qy!8u z#W?REh(`J1D;K8P5rfW7zlo>^SD)_o37r;VrDFq5x%PO$*4qk&E#% zPPw`iom5;p&CaN$hFr9hKRtQZc`W8U>QFIB_t;x|3ck@usRWT?1f#*}n7t?DL z9o4%cBCcHkuARK4nATMSq+r#>1%?QyGhsTq!Dw=lQ&0WO8hFT5-dTF6qy#f~+3>gX z^ol3YzU_kK#{NdPmd)-jN81l}Pcu?hcAb#UTWFimm5&gniVm1N3VLuKq0kV+l1l9# z)`-To*p-f(27QVb?qotUoG&N1OH-EKI9@GU-p9`KJzvG$jitr%)~$%p*Vk(n-H(g- z7`9nd?hCtx)hx_s;k$dIVFA1AB(o8MR6>|3rGXzVJU4J zB><02e!KnJNRwL=V;By>t}WNja@5D-Q~htZhPW&aokDP zytyFoRaxDB)3~XcnVp>s>pu}Q+Kn1Bro^qfjaAx^2e}G04=n!*B-uMJx7k@o)cO>WgYJPuwK@;`;O zq|$?2ckeZ^pJ>r{opiJHSDhJfu&6~Azjp5@w33JE0_Q1H`*xHcO&52{v5>KgMsHsR zxpup-c#w$H&{_t*uuGy=6vZljYWT>SMx+xrlA2|8Wb&GWqUR`A7%SD7$E|X4_EA$u ze5h+^I7Ql%CAe78t*bmTw(-nW4@L8(69!VudVak z0DJph#0Va&#U`l21UF{G-Q#L`ed{lt$HxvtT4mx57s)piu<(V+n`xQ{r=8xNB5UDN zkD>BosLw%aQi=c%ynfgL&|tM2rBc&lvMh^|jNaUYCU=I>v9ko51)~Gb!k`O983MmU#5&x>Uu@JCG6d3Qs%eA#M>(FswYPafoI$SUEvB{iG)_?Z)>eK_FI#E$cJw)e;xNNlhapfxYU5-n%@dsjJmC( zQoE@2+gDv(T_^skz1gWfb!Ru~n}1HQr;9`M=>AZmBf^59=}JMwfxD$J_>94JdN$dQ zC8s@2V^r>jLQ#|38M=K|?@3|I@>^?6LUoNJV{`;;B4l!JaxxYP3s_1w+*!SASbGbO zA680lqzrcGgLF00>OTD{RaEO4$0IQ%AA<}A_?V&f&~^a~$liUnrCQ*JaS=AvFcI<7 zu#Zupk(bO$7M9|G+{{-&f&2z0Uc^D`U;!hV_x>pz`~KCW_jcR7W`Q4Ln! z_d)>+ImS%*B$B%mQlR}$>lIv(n@>j)8mTh021&W^K!oX&QRm3!;VO5r0T+$4XS?xU zJ2N)ow@=P{&+z%e!h(K<3-^rlS|SR8hWExp6;y^s{;B-Wv4D0 zn}e`MrYJhl{6s~7a5x>|#EJ8jof;E71$Y*0KIK4~00V%|YpuAM4Pl)8TuA)2a}zC5 zj&yNAXE-xL$BQ7x+<4@OVc%+kzdn#Lpc8Z2fzS>(0brhxw4yF7L}MV7%t4pMEJ;^& zmm=%XUM_A+n@g*nZjl~szM`Fz^?kvtuzWt67>*~u_xV%dhKt&laZ9 zvuP&EC@36cT}Rx)@jpG%sZ;En&ZGJIeck+`NIchp4NPx>89^UYlKR4E!!%kMsPGF|1q3N2v{5tL$FioTAni&<+ootf&zmvo}| ztvVGfT0yr=Q6p+$)dnyy2>=|jf&MMpN+*xLqGR7Lcm^}((^oo0L(pPTbIU!{1S0&uGn9~xgj3;Dc z)eQ=5?sIJ38KxNNws{?D0y>I^))1aRF9vW>pRMs-xb5TfrXZQRKbMkvlOyn2vz-|0 z8iE%xW{m`Mgt_B)3*M|QR+_ZIBEQssvfFz6|!!D$kS+F5s8oG^|Y z18({F!?CUJa7HCv!*f?EgvsxL#T$M&F3z*M%9VH9h|^EoTnHlJUFZ=GYJ#_284h`2 z-&9CVg|t@dA#uMuBVDPphz2MlqlK&_JQBbGeZb-0AHhJp!u1H_sC#i*{mhxjYE!ee zmmkV6UrDvDQR!G5Xe}@UxrVInk9WlIJ1iatwPvG_#L^kN_ZfESDowhj5iba~-xuR3 zN)2`h@EFN3^4wjx(xYB!!-;-EZY#`Z5O~Ucd>%zmsnS6eFX594}=C7lNn^-Kooj41l ze7Lv8s-Pgvxhy&~wCx4Ffa)lB4SVFR-YO}$uV@Q= z_$Jp9o4&$f))p({EBPFm?Cn@edG+zu@FJ^w??(n4zZGeeYKuD_(=XZY?^kRaJIEiB zK>Cd!U(>t0f#?VJ=4iNPW;j|^mOC#^A9iOMq`t}N3%tg|EuW*8Y5eq-`zyrsZfxUx zw0;f2gtJzbrnp1CS=l{B!tdsYJIzr;n1T*1$)U~W6pKVEy5_1GoL})mQHHUs>x8M~ z2I4G&0K+i~_ddTm1eruj*W6sL>3;nt<$-LtuwUi;xLEvJ;t?WXVb4r7nir$S>?A|wvGTh$WsOS8vCY%WS}CZb_zgoWJL-kEk=C0@NDq{64i zC5HLN4YhQY3Lo7zspRy8gP8uN1-Pq*hCbH_g1%Aygsf&j`ut*Nl3c|&+f;9=Ri|cI zKK1CX;M?GBw(37SQ)Ph_iH5}$R-GhQd?9e63t_PG*$jJyo2l&`Cj3$vDf)KpkIgo$ zbC^=2sbz-DGtKaFMF&^saRZOW46&hpq(tuvnV^+8ztp44R~WawZ>C*^kR>j1BVv^m z?lX1=^xpvF()8c280@Q}k)n&*G~&q4 zhR5Pa{4$ja7!O-GFJ*2?Q#*i}d`r}%^&nYPMz$d8Rr&oxEUSO(_kUiCxBTcrjuvs5 z)Ao!L5Dwrm+fBpH!! z^{LrzlThR&5bOGc{)ZB~>PD}*F~?-2c(L0qx^i7OHeFqV<;b}mtU0h-d^ zll_6+=?`y`Mq7@1Q-y-$T9eDxS+)gFA;WK0uR2x*JaG(MV=VHYspZ3=#D@oXiR}N( z|35z<|Mq{^zVkn0&)@xfZ6E2a^{7G!j}6ds)>DHOuGxp_U;ZA*HReI&X4h`oX)H=R zTm^gf-8Zb;;AJ5x!a?l$W(0OjKr2u)$|+9r`q|E$};9!FZqf3Fcv##tV2?k2lZjTxdg zr>t>RJ_D@>*iiW&6TFDN{N_a^6z8%SK(n|*mx#Q8XY$s{F$JWOt4(@pXM-`EzdwAB zIsNlBoQl7{M(!*x#Gx@axu2^HOli&r>+1dUHQZp336n4VO8yHg#9N0c{quUNzy9^y-;?>DQ~2-Get-C{f&ZTA|9tN6Isa=4|Njdj z)(ieRU?kM-9KF~L0oF#+gim=bQBFo^n6-dVITpA9Or&I3n^j-ErNgko#S#f*WC1pA z+9Vvgjc{VcWW_4bE(1)Bupw?CbAz^5!l*m;j3fbi;B)3Ss{VnXE8^)$=x9*R)9m@0 z54a>{7cpv15-j3rFdlg_QR<3>5{UE50N6sd$^iu(4KiS0w(HJ+*d9%UW#cfFokJE3 zS=xxtGUzk7h`W{Z3T_XOECGEh@aTc$P&|G5^zxk+b3mv_Zi+{$Yl!llI6e+fFgTKU zN#zKMYt3{ghMlk_`OnaSZU%iX8cdj)kTgJ&1Ts%WBa_%udSTO+07m51-U9ot$qcVj zsfw0xH^yJ(K$1a{HH}(>khTp-EraBfn+x$99r8DFi23yZaWz^qHCT0ck)G(kiaYSO z2iO_FL#EuGzyk%bRkmj41<9?%s0ulZR=A`jGFcvDP8y^MScdTP$XOV7wJp#QcAR}=lf$jly_n_K$0S2-@@kcHBzrjWW0le9yo8as(4_YW(J51{_d@VL(Zv=9GSJJ2JmO37|nWqpU1`RqJ}uBftXn z!uFL9zYggb#LbU)-4w7IJ5_qmUqM6Eii7pDB8U zC&ObzC~q<=mhC9_!$M}NK_%K-r5~Q)acrhKJ4sI2VpUid`?=>TRn>G7o6eB}Qs$wUsFC}7L*pRx~BmC;>&1{ca<6YlfX7fC;{8eM7 z@=9pvHTur!0TiUCt7LjQSFM!%{(Ai^5$ZS{SK;0zHqJzGTvSI z!qrc1=pnCL=yCo}VlTNoWe&2NnXQIo0R3ZTS0m@%bxu z)w+{!)n=S-^cFL2eRz3|hoyL^XX~KeVI(Oc?oAT#zIIG=)6X*Efq}}%V@@DMiZlPx`40xA`M}XSatyaC7 zsS4D_t>j_d+`mUsZ|vn{Gb5{XmcE@3-e&j|Z+inwtNP4f+C)5GgDNrlV_mty>Fd44 z5d*ne*>ID?f^hGXSrlVremKx?i6}82%lGh9w0AaA(P8VEYZK#rWk$C;fcbnRli)rf zwM&;C_c88>daje!W0U!-CeBTft0sCuL%+$_!hP(H|F3iRc&K0cT)*X8)2}1Mo_UMY zIJd^BT}V=hbeUv!)CiG-XgcNSXrp8&*tDF|A8uulzML+l*er8*u8YF^@?3+Z0{}|nxu^*?KR_fWJ>V@#^imdlYNxuK0Z` zFbQYacHtmxfE0KLc6Mgm;Q$Cf{K~-Wv{2L*YYFKG)~9+q`kuztFR=XbVHOs=Pji$F ze%mdlO70fhnP;vp)ut*hhc>%64o5dFA0CKK-D^r^XzGg)Gam`EIB2R}^YQ9PqJ7Aa z*E-^U1E!Vyb4jsuh@YK(swa7(Q#oB|{q;s?NC(Busu0|KqzLE5rXmL zy#whM32MhK8~U`nFqFw2yL@faos=k}v_YEuaIs%eLSctr)Mq)F#Y<;5MTj`1P=%S~ zmnGjnnjU6N@H|;)o~h0`)klVNIdSk6O= zzNs-%4;1mQ+_PH*<{Q}2ifgJb9o~=W4ZUK-s*bYN?ZkJNzI1+QLGUQ_NR~Qh%l*AS znP2I1a9r%*(8|dI==kAfx9OBY8o}#AQnd>&UR)eL%BRl-KbLw_078?h)c9KUNak@m z$oE*~Hks_wLG`DX(+<%zQg9xmR2}jo`8(g&@#v~gb{!BuD^N{pkA};K8bY(}jZkr& ze9E=Y7G0y*eNSLT0F9W{43)uaKaWNzoPJ$oiGp%U8n?`#3$KCmyUPghX=Pn}y6XGV zM2nc~$FLYNG1iR)2W&cle2dU)Te?bz6x8d2W2AKBC7U=WQ~&bbwq3+Mw?4G1DdKSt z$Q>ZkA!|a=1r}$k@XYa|2eWLPNXJjMxWjkA})u8bJFV3(nzrkzN zoA(Nzt1y*RNYJb-tG`XDz2ss|Bp`p~k^b@G=3Pn0gOtV_P0(gcBR$LEJVk;SUi*{% ZKy}48M;`arpiUv= +S: * OK IMAP4rev1 Service Ready +C: a001 login mrc secret +S: a001 OK LOGIN completed +C: a002 select inbox +S: * 322 EXISTS +S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) +S: * 12 RECENT +S: * OK [UNSEEN 88] Message 88 is the first unseen message +S: a002 OK [READ-WRITE] SELECT completed +C: a003 fetch 8 body[header] +S: * 8 FETCH (BODY[HEADER] {342} +S: From: Hans Bauer +S: To: Mina Meier , +S: Kaiser Wilhelm +S: Date: Tue, 8 Mar 2016 06:46:18 -0800 +S: Subject: Beispiel-Mail +S: Message-ID: <18283.122131@bauer.de> +S: X-Mein-Header: True +S: +S: ) +S: a003 OK FETCH completed +C: a004 store 8 +flags \deleted +S: * 8 FETCH (FLAGS (\Seen \Deleted)) +S: a004 OK +FLAGS completed +C: a005 logout +S: * BYE IMAP4rev1 server terminating connection +S: a005 OK LOGOUT completed +\end{mail} +\end{minipage} + +Wie hier zu sehen ist, sind die Transaktionen durchnummeriert und haben für Client und Server denselben Bezeichner. Der IMAP4 Zustand ist implizit und muss aus dem Kontext erschlossen werden. + +% TODO: figure gets misplaced +% TODO: nicht alle server Nachrichten dargestellt +\begin{figure}[htb] + %\Centerfloat + \centering + \includegraphics[scale=0.4]{Content/Intro/Protokolle/IMAP4.png} + \caption{IMAP4 SDL Diagramm} + \label{fig:imap4} +\end{figure} + +\vfill +\clearpage diff --git a/Bachelorthesis/Content/Intro/Protokolle/POP3.tex b/Bachelorthesis/Content/Intro/Protokolle/POP3.tex new file mode 100644 index 0000000..b3311f2 --- /dev/null +++ b/Bachelorthesis/Content/Intro/Protokolle/POP3.tex @@ -0,0 +1,73 @@ +POP3 ist die Version 3 des \QuoteM{Post Office Protocol}, spezifiziert in RFC 1939 \RefIt{rfc1939}. Während SMTP das Versenden, Erstellen und Weiterleiten von E-Mails beschreibt, beschreibt POP3 das Abholen, Auflisten und Löschen von E-Mails an einem E-Mail Server \QuoteIndirect{rfc1939}{S. 2}. Es ist keine Erweiterung des SMTP Protokolls, da es eine eigenständige Funktionalität hat, die SMTP nicht bereitstellt. Ebenso denkbar ist, dass POP3 mit einem E-Mail Server verwendet wird, der nicht SMTP zum Versenden benutzt, was allerdings in der Praxis kaum vorkommt. POP3 ist sehr simpel und eingeschränkt in der Funktionalität, was bereits in RFC 1939 angesprochen wird, mit einem Vermerk zu dem etwas mächtigeren IMAP4 Protokoll \QuoteIndirect{rfc1939}{S. 2}. + +Ähnlich wie SMTP ist auch POP3 ein Client-Server basiertes System. In gängigen E-Mail Servern befindet sich also häufig nicht nur ein SMTP, sondern auch ein POP3 Server. + +Ebenso wie SMTP ist auch POP3 TCP basiert. Die Kommunikation findet entweder über Port 110 \QuoteIndirect{rfc1939}{S. 3} statt oder im Falle von SSL/TSL Verschlüsselung über das POP3S Protokoll auf Port 995, welcher allerdings nach RFC 2595 \QuoteIndirect{rfc2595}{S. 9} als veraltet gilt und stattdessen STARTTLS auf dem Standardport 110 benutzt werden soll. + +POP3 ist ein sehr zustandsbehaftetes Protokoll, d.h. die Verbindung kann sich in verschiedenen Zuständen befinden. Der erste Zustand ist der \QuoteDirect{AUTHORIZATION state}{rfc1939}{S. 3}, in dem sich die Verbindung befindet nachdem der POP3 server das sogenannte \QuoteDirect{greeting}{rfc1939}{S. 3} gesendet hat. Nachfolgend muss sich der Client authentifizieren. Ist die Authentifizierung erfolgreich, so gelangt die Verbindung in den \QuoteDirect{TRANSACTION state}{rfc1939}{S. 3}. In diesem Zustand kann der Client diverse Anfragen senden, um mit den auf dem POP3 Server liegenden E-Mails zu interagieren. Der letzte Zustand, der sogenannte \QuoteDirect{UPDATE state}{rfc1939}{S. 3 f}, wird erreicht nachdem der Client das \verb#QUIT# Kommando gesendet hat. In diesem Zustand werden alle Ressourcen freigegeben, die während des \QuoteM{TRANSACTION state} belegt wurden. Erst danach wird die TCP Verbindung geschlossen. \QuoteIndirect{rfc1939}{S. 3 f} + +Dem POP3 Client stehen folgende Kommandos zur Kommunikation mit dem Server zur Verfügung: +\begin{itemize} + +\item AUTHORIZATION state +\begin{itemize} + \item \verb#USER #: wird in Verbindung mit \verb#PASS# zur Authentifizierung verwendet, alternativ kann \verb#APOP# verwendet werden + \item \verb#PASS #: wird in Verbindung mit \verb#USER# zur Authentifizierung verwendet, alternativ kann \verb#APOP# verwendet werden + \item \verb#APOP#: alternatives Authentifizierungsverfahren, welches das Passwort nicht als Klartext sendet + \item \verb#QUIT#: beendet die Verbindung +\end{itemize} + +\item TRANSACTION state +\begin{itemize} + \item \verb#STAT#: Abfrage des Status der Mailbox + \item \verb#LIST (i)#: zeigt Informationen zu der i-ten E-Mail oder zu allen E-Mails, gewöhnlicherweise Anzahl und Größe + \item \verb#RETR i#: lädt die i-te E-Mail vom Server herunter + \item \verb#DELE i#: löscht die i-te E-Mail + \item \verb#NOOP#: tut nichts, der Server antwortet immer positiv + \item \verb#RSET#: macht das löschen von E-Mails rückgängig + \item \verb#TOP i l#: lädt den Header und die ersten l Zeilen der i-ten E-Mail herunter + \item \verb#UIDL i#: zeigt die \QuoteM{unique-id} der E-Mail an +\end{itemize} + +\item UPDATE state +\begin{itemize} + \item \verb#QUIT#: beendet die Verbindung und führt mögliche \verb#DELE# Kommandos aus +\end{itemize} + +\end{itemize} + +Eine mögliche POP3-Sitzung könnte so aussehen: +\\ +\\ +\begin{minipage}{\linewidth} +\begin{mail}{POP3-Sitzung}{POP3-Sitzung} +S: +C: +S: +OK pop3.bauer.de POP3-Server +C: USER hans@pop3.bauer.de +S: +OK Valid user, now enter password +C: PASS +S: +OK Password valid, maildrop locked and ready +C: STAT +S: +OK 500 4670 +C: LIST 670 +S: -ERR no such message +C: LIST 67 +S: +OK 67 300 +C: RETR 67 +S: +OK 300 octets +S: +S: . +C: DELE 67 +S: +OK message 67 deleted +C: QUIT +S: +OK POP3 server signing off (maildrop empty) +C: +S: +\end{mail} +\end{minipage} + +Wie hier zu sehen ist, liegt ein impliziter Zustand vor, welcher aus dem Kontext erschlossen werden muss. + +Wichtig anzumerken ist auch, dass das normale POP3 Authentifizierungsverfahren über die Kommandos \verb#USER# und \verb#PASS# unsicher ist, da die Daten als Klartext gesendet werden \QuoteIndirect{rfc1939}{S. 14}. Ebenso gilt das alternative APOP Authentifizierungsverfahren als unsicher \QuoteIndirect{apopinsec}{S. 1-18}. +Stattdessen kann STARTTLS mit POP3 verwendet werden, gemäß RFC 2595 \RefIt{rfc2595}. diff --git a/Bachelorthesis/Content/Intro/Protokolle/SMTP-Model.dia b/Bachelorthesis/Content/Intro/Protokolle/SMTP-Model.dia new file mode 100644 index 0000000..d333c52 --- /dev/null +++ b/Bachelorthesis/Content/Intro/Protokolle/SMTP-Model.dia @@ -0,0 +1,670 @@ + + + + + + + + + + + + + #A4# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + ## + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + ## + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + ## + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + ## + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #SMTP Server# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #SMTP client# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #Dateisystem# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #Dateisystem# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #SMTP Kommandos# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #SMTP Antworten# + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/Bachelorthesis/Content/Intro/Protokolle/SMTP-Model.png b/Bachelorthesis/Content/Intro/Protokolle/SMTP-Model.png new file mode 100644 index 0000000000000000000000000000000000000000..1eb8bebcd3e6d047341c8ac4fef34cf1390b9709 GIT binary patch literal 16734 zcmeIac|6r`|37#t=~%N&g6(SK)BqEivB>R@7A{D7f z_MPlPcJn;l-}%jN=KFih%pddToX6)D&T-E5zOL8uTwd=xRA2819raFX0)aqxRO`@5 z0$~d;zRxCZ#@Dc2V%hj-%O%oLLn4vb-g~?UKT^4BnO-6gwl$Iex2ZUMIGI4;B^*7Z zZs?sj(dngTFuW{3Eyu?Vb}2Lu{@y8b3= z@DVp}!XgNSwv>;G|Gv4}Mad-k@4Fq>DQL*wsJ-W{BCnqiC8?F8#zRWc7h(x3dxBpy zt*8fW{dM!5wNrOR=f{s>RaPToV|RAST$um;qcz)7@Z8&@w;w$^qpeLd6-1#PpO7%~ zRQ{glNh2d!2?^KBmz4uny&WALhyQM!6>E~)w|+uYl0;zP+3Ng_kY;@5%=*%B@;N&@ zDm{KxtpT~I;!DGEVrGZGxUMWXv9q&xB`C&p$SWwk|L`F*GqccfUzuiwzMVU<&h-?* zW8XW~u=G#{!n(Ti$`+j7&kv| zA`;S`W@d&neEjr@MQZ!H`9yam58vFvgjt7)nOWwG7rs4jH%TTdq{IZvs`$tecojOI8^l{J~>-rGEnep`L)AV#1yN~z2WgMqTigBTBDZlb}=u^VC zY)e%;J3D4(W*3*KurTV11Q8LD)|aMFaCsRS!((F&gYJyS#i^!Dm=nhL5e{VFitaIn z9kiN}tm}29-z9J5?40%TrIK|mkvb$gDoSntqxg8O6#a`AFQ%EMG+p+zo>K4Toub`7 zC%`PIcZlfY<0B&@6Z+uhs`=++)xft`H(iu{$a`z1|3hhMDYLbRGD(oismy(lnpD@) zVl?8bq@;An|I1R#`xRMvc@qhd*Eu=QUcBf_YU}7o^txg5A(D|_VTb0LKOsu|-#O~9 zZVK;KP*jYG@tpV-!f?7WK)Lt^9j7dB@a8RB(#b0d3!@{@s_;MNI(hOW2Q4M(R=sUW zX(^A2-{R7rVe|d>y|`yHw^`0!8vGc0`!;Q`zPb6Xuf^Fz*g&tTu8`nh2L}h(~OMc z2?w_F4PZwV^CBWX_kXzKc;Q09#kL@Zor<0><9jygtAz!!Xy4ZF+Z0~t;N--`%KFYa zml#y{<;!8>4i1ht`T2|#RfFykw{J6$rn<^w>_bScR9C&HV+g;7v2y*7y`H}uIG`~tNXEw!tikIBN_r|ex|9M&U z3X2@8O{5XLOPLfq8(Uv_e^PNu%BD&&VPO*SyrW|{6*u8sTF;T(TH+q=9B;-7X@~F6 zP7qVl(gcEdv5yQSoAcul=8)&v9{aL_X>e_tEA(N}+!_ zJy#Yc424e_8+(0-bn29hl+>T;>9>}5Nuy(9yMx``-P77AmW)0*Y-eR< zO=*yok(nt_3)?QWyUAEnMyEqu@!w48u|J^KK47?#Q69l6@TB!j)U8`-=SjOtK_%HQ0O(zNg&Mh z$kILLLe3hPnKiWDI&vrMMQ(S6|HIWYlaz=sVhRoW{x^>Mu3Whi+>{)+-qt&D^0{F! z!@ApMwY&ccW;H!ePB^>xVdC0K_r_tOnCa`_i&LxEFp@{$SK2vqVoJc;@m!iVL)ZN8zyStMUk9-bKj0jP_hZhBVGS$5c(I$;=60r}z zNzX;vDAklmUI^Gi;N_-u-}av#$uU4r{)X2k%IaTht>X|dA^(DKfRc)h{O{G<=$hnj z{{NSdcj159m#+g{1U2*hg^wTeDk_#D{>#eBii(O5w<-S~>FMdOUPYjL6`P|KQeIC% zsG|A5diB}%07@t=9o@>`DOHaVeV-``f2Qe%aI0)7O`ZJjrypwky}(SE`EUOX7qvgMnsN8= zxP9l2v9U3GqCmV=XUXNUaPbO<^XHe=SEl|>b$9nh2p@Qc_!J1D$aG|+aO-~`acTHV zl4{@?orJK%PfX3sI5{{tcJBN=Hs*N#ykvq7t_Ay@Mt&Sh(SPvZ!B6z~&soo&J$v=a zF4tu1)~!GR_-ef#`r^fla5k~!g?5(@cX+yGN`(?GUOKjA%a#L|M>>tN&-l*{9OdME zsBx3Nt-W1j-@d`&;qKx~g8ck_@50%=xmUGafL*MtT!+7KxwoO-WTdC}4(N=0&~ONQ z+y3*{ujSEi8Ju#?SktVcfUFRt+(c;-L$d3R+JT$ zX25{$yP6t}8;)BZmoh$XFs}>%Ry{WDqW9$MUY+=!;bE`7+R&TZd5nyVJl!==ugWfu z896wNVAE7KRxhRGQ=dCGeD5Ah!npC3wqL(KPBY`wh3}V-1eBDN5K}&V(vkerQ%SX- zrQCmoO|GS-1slLE@2d7ma=%A()B7WLxcPz+ntQT_e`FfV56zFYYIl@!>we-X5N}7< zroH1K94kD<6}^Qm{FJ%*>iXJBP*6}uM+d$hPgX&o%gD(!C`vauPjh|Uvy+pvv$J!l zLfpf{!_UuevZMIhuV25?&0L(E$^+I)3JVKUQuw;rjnvc#_ZudfU(w)zZCtyv7FRhp zbdPCkk9w43XNx;4d5&`=>4}So)EK-I71Fh_u;3!ys3kja(9oz6uUwrSZ_6WXJW}2%VAAa1=!lP$ zzp^lneUo$UkOweAx4d-e5;krokO5!uM`vqp6ql4_ndDY~_#k-Tz-(LIxn1-}x>hKH zukRV`K0JE#2*`GPNQ)R$guFoK^+D9m@|626&E}nJ^gPG$ z-8iZvvWzRRKZQIU`Z3+nqdH(DfG3n-b=4ot5 z&CTuMVPPX4CD*TC&&{1duiEoeP}`cFZ=bO6M;vWS%K{) zPPaVdp!;{^>l5UQK*ocI4~GW_?;70UQe5~f*WJ^qeSd$sYj04`&N|h5i(F-{z16Sn z8Ynhs%BMuDiQC$@I9nc?asuGs6pJW)ELl$7C-rF9Vq<`OFFc`S0HS zBtQRD!5ELULsSy^(V2EMW_*0ShhK2(roUCu<*4TeN|*b>#lynGck}a?sFsq5Cxq@j zH^^9@`M{HXru=n5!TX4frN+ShXUcxARS5x4oj-rx^B#caGnzKv%%~^^%Il0fcAU4e zn*L#IxrW*@Iy#yf5Nn)$#^Us8--%!OpFVv;l*u@@c({*!{`~pi!GqZTxw*MRME}2? zUe@-WmoAA23B@0<`-pv8dYuUrf8_At3l0vuknpH#sQCQ+Bn^%JPYF`@_gnCvlaiGU zSYP#Va(ab?AqmOL|Lo{c5)+HKNJT@_-~MbaJWBB1F8blMmA~@YeVqK@5(|qn{iuv$ zW(B;#{QUf`E3qQR`^}54ZUHXI%FYg4nzbwS1bv;LP^X}vz-n{a#;dEVr>9+kH}`EY zD$~avn;5ve|F=i#2cMONSINoAPo6w^`gG`5zT+JpRRraJ$bBMK_xI;)Y-~S%{NO5jk(-tErMY?bOOhh0(1aqZXt2Jo z?{a}tyK`rWW`Hs15#`pc{_{VK7sX63U2t@il9b$W&^-+_2z8u>ni|3KLD(dyz`65S z*h3u$K|)RKZ3qp!j*gB(4ij5=I*tY# z_sFb@pV&7$*r4b+?)_&dqG`vy*jOOwZJwS5&tAQ>D3uiw(lRqMvtOb7wPo`99vcLvJYs)s zvH#92-HrRv(anY30h~NM*$BYr&-Z0Z3^gWqUwaj}IL#*~S18hV!WAG0yY%wK3tU8r z*VLJd7stVm*u+kI%=Ep(Ma+JAo|g8;eek35m4&pYPkpak`4f9rLG9G3A8+5j{rc5y zZF!z)EF0xH&IEiLV|#1R!N2od-h`cgy$(3rE2&q3#Nd2K+1l^g3TmFx4__=Il` z)0etC9|!HR5oHTk+G_g7;VUjqal=568F~*rJv}6!!$cHfX&ITz?N5C~Ouz)V^m3N1 zwrV#a#=RzfX-3}a6H6Z$95gjC(HFW`R;FaG6jje5I#Z|l^Wp+Z+DQWg6zGlRF>!aw zoe^mCE#JS_woiTQ=)n1eIcf!Q#{O*1(mWs~m2o`zjJdfehf>w0n-V7+Yi0`HyqS)4 zWK2~5L~n0z|K*XgqN*y-anK`Fb|oOlx7W73+i<$FtBcwQ9q=ZzsEkZL_vtDH|K+*g zKQilc_OYOJlB>V{=Lhd>50vr|{&Dnmz&SLOJQLB^onO98w!AWPSIVD!$kJC>Sy4No!s0L%kSLm z!bKgZqKmF$DS;?&-GLix{dZLL9?C{kS*@=9?anmLp8PpU2)PV31yDHA0$6QnX$jdW zARr)WQS#=B%5Sou(AU$$z`+4(eg$F6r*Wfa0d=frEW1>Y_Nsc&kNiixBlA^5qr*T zZ*=^bbC#GgFkpK^N-OWW^iHRim!`lW+9c9u?%m1v?tPzB-b8)7rq}z*m44dy)zy8U zAIc%;7-b&6;6x~iS1gi$1Ef?VhD&!ZE_*J1og$Ow?ivvbGkXj-M?p1-A9ksj2+I4EukKcN9x0DV2dNm6fgDQC(j|0y2^^jb8n}5jE}o z(jY?*6(3a$i5vL-_Ks%pNS+l4xep&a_yt8SF7CZoxMHZH!?|-_tBW)ENZE%Lrlvmq z@9Bc|D+AVS3&Yjco4RVO*T2Ux4meM z&YbB&l+F~3^4Qq)?=yHB|L`Grct>+{^ZWOQj~;z)V}@m-X=ZY;d73jSmjyLm>rJ4lQ|5*p4IIfH33AnsN_Jw-L(h`sxx8(eK|Ez_0+- zvn$tqLHxq}v?UU}BLKh`J9JiyTHj=O>auE!ggVoeOQiCg(elSGwfvNQ)@bF(hPdTSZg+qyz65$AQz_9 z{T@*V@`DCoK)oiO^c@Fog{J-y{@D`d!e% ziC$4#2n00O6olCA)B%5MMz)i7t@479Fw{aVoBWX+ zC_jp>{<;XQo7t}^2p&@OH)9??Y`8LYW%Ta$kn!SYhA%S6k6}nR#~&%}U}moI`r&!v z1Y<>LC@=N_AMAHFCOVoaAWY51X7`lL$v&`6W8>BYsdHIog;_Qmn|Vc|tgcO>*RSH> z=y&~r>1VV+;S`=*%RGklPLI=b*a)v|&CzK2%pc1O<&n{-D!meJncM{s^<)nhnhV`Jm*?++2+e#5)_awu3R5R})|Grnmm z^U?^3!uIQKZfc5(kC(^7e70@AYV9-Kb1gPDwxXhpEG(A0yTqQl&sy4i4$<>hZo+K)Ys&;O2auN!jwJ2(JCv1IX&%eYRlwN9B2b6&rm#d3!~CHzU=Slz~FYh$C4qK{Hs ze-N=$Z`k0|obFiVQY4L?0!eU~tuho+KI~VLI)Ln}^Zrr$mYX3;y&3gQ2E_fi05G4I~ ziI}jSY|9RQX3=1V5K`Nl^UNe61%;h_EUc`t2?;QL+h8~v8~+6{gNlNPl5~`J?Rk4| zpFx&IDUkM8$cb1OS~uJULu2DVpM83(L-4(MxoRV?ty5F#P*%>T@_v6kI5 zps91=-xadBGKOa}HosJf9Pd1xf8o@H3oq{6*?zx)OwJoVejMO>Kw`end9kPzCc(d1 z04u)W@remW5){^vz@vNA8UCX@K-W1$uO^?L z^kSHafL0zMsO#0jobw4{5W_c~di%T`v^OBS_h@WKU60q<8*v!A+u)jF^q8BM*PXC1 z-}TkvSFgm1zoWJ5>gb4yiRI=k?!mQP$%RL{`R(D=9? zl;Rm}s>%EJ_}q%kS5wo{Q2F$MCG+!R3qz``q~+vjoEiCQ|CxK!j+!Fw_UF#^e|>WJ z@L|8k_rFj6mz1Y)`30yblJDjRt4EciuPW-_Fumgawv<7E|0aKhBJ`Bg^@tB^us(~ z5)bx|j)pQkPz?+~-JYWftEbC4Q?B6BrF7)T2k?v(<1rp(Ul!xD!FnLC3-j}XW_ckY znuwFgNct&Har2^_i){z0IEX=ugZC|0*VbU~Gcz(?<1~JCnsvvHVwdg;=qpG<2OQrn zh|$(s=vMxJC%F#JuS`|miH!VGU(aWT4%Ig?p<5B_`s751+l^$}A3uM3BLft@Cd;n; z&3f~OrIqsC?Zb$l!^8+~<zB%s%o$y_`bKayl-vJJ$G?aa1($bOxE^Ne2MMZmw)d$Yk}v)Y44x( zgp5*b? zL3>PU(UPhL>SGW)LD#Q?IKmowc=v8D>L4y>9Qp-(z%ow$mFGYw8JU?YIAG)tdNc*! z8{2v&fH=TKaMvWjrv>MOii+gzI}tkG$;1;4r8ZsrK6ptW5E!m~+qP|`#l;pS9_Q<# z_=@(3ir$v1iq@}M#@+(xLN(g8b0^5VM~dBcclC<-rcn>cQTA?6DJdyDos^t>C*$Pv z?*JE2xBYtFUL&SJ-=p6ttpyYf*mr%~_AI2rzI|U?TG%S@^#tUL2&5?Pc@x5Jm_u=w zRa9I&dv?}6^pC-F!>*Xy%gergUj2|r&8tehXHw^$vl1R_-~I6ty@bv4hxN(Qsl$=Gpte5F z$Piptx?XP!fC0TDn(8LUe@MO)%m-Nd@XXxZXR&EybXZg*AKZklfW7wvMgv}ri;WdC z$x#Dh={uQ3OI2r%xdIUL>s1U=jip{wV9^>z{HCHtb!!as3iJNmYa5q{LA-EfriVU1 z+`pZjz`ND_a|zxWmYJJ2Br6@A+laCFbof#c5fK&^7WHf!5*tkRM{}MRWgUIY``C-- z=-1Lc2O#BHV;I5B%?+Ick%*2$ObHIAkSt_>a`HJW#@t*+!81rmyaHHc7<%fv@t+$Z zq$luz9kDKA3LqJP1g1Xj8lctq;)1qpqvs8dLuvhd(r?CtSAh2tkO8YIrHG_tZfa^D z^d?_lUjS}0oO#P(rBHj%%hnp;7~(nFO`4KH+E)ii^apNnUsZXMm8JJF7nF}}eSIAZ z#EgMEJ{70Gl4^4e&EiL z_id635b}MlTq!IlfOy>Rfra_a@CN^4Ws15F#rGW42Cu)!Pg{F?J*iwSC2y8)C5UB- z2QNLncb@HL4OIA=ZQKMkavAnJSm14Y;YV(-5s?qB5&{oEnR45<lCia--9W{-I1 zs9jH@#9?9tVPUmNDHPs+5~#GV(H~lPcGI!9h0bf&{E`OWj#T2Q-^%ODoYQ0 zZEnJ-pPfaS_lfU@G&JD=s`$~z*Ej5A)*PtT{QNtfQG8AIUq}cK*FJpsJv1_iFa;OXIez>mKO3PB zO8YoO_@D`Rqa8h^UuH~u!r`${3&a!?*~G+BX?VOgRXnVQ;Y5U-s6 za=kPU0<#TRku8+CPBUCRyZmVS(!oTd0EtT#L~(fpVMcMva}<22e(FXlco-%ocw zBcB<_(Dl^7ICWi8`~^0aTtbwV!_u(_FIY!9AA4nP@qM2H0WQeJy|KN9`l?Xsd;2Oa zQ9^A$r~i+ov*VA4qn|S0Af;UFC}Qk3F#I0mq2Ldk+g|80?35@$7VVh@oV`$W(AL?Q z-$K=Z9irep-GhNj?c#e)-f7#9F2_BZ(FUtGICW|sYQWJ;XK4uWRx&hUCWKp6W)(qL z2_s9fSLQhZ6DWun|AL1!OHWa!Mk0}JT6z&IAAr^HuFnb)mPO4gqEB7;(e*@8Qu4&t z_pdf@&FCpNQ{G**xtwb1oBOYolA1bc%z4n^y@^oPd>6(OXfur_luJZ}g%yf5n_7ju zr`T8m)OmtF*!O1e6A0dLn(XcDs)(9R*F_;DK@6OYBng1^ChuOyl-!&yIqb?b2#<}g z#Xyk3<9|6D`|lZB+W*z~?Bn6HxhB}L!q=~@B{)F3Fg$e{JrkN!{SF}(>JZY`Z{Of~ z_F6>o5`hwwV!iZ6_lbyL3Im=pP(m4qll3!ztM@c#D*Q|f0x1XtecLFj`gmY!vT(6B zJE*-xS##5`B?^7RZ}+C86KBpK(H2p)D}Dal_-t=%WK;qF8b#SMU};ZxBGeM&Ec0F` zU|l^_gmVR5V7sSJKZuWCggq>;s0gv>R&p}!<1KPc!@3lu5$3Yggb{zyq%< zSINpV&N|vfDGgbK9za#ewz_BXB4@A$}_wS(| z;IRQ)!EaEyX$7_MqpdP1#Xy2EL77Fs7U|wv>dGW@wZXi1~6HL)dz>498^%~qkYm?UG7f45_w2nf=PNCFkz9a)SDg$k zkBYgm@qN(?pj#NaL^XFOmmgqYSZi1e+!vS%*G22@Iu5zYV`5rDP7cAwR&pY^2^$6_ z_}l+9k?b;CU)%RL_4qy^Aqgp|-Q5L$N7m7kd=$?azck5(&Y2a)dNpfXBmX$lSj#IZ z2?>*2YfXSg(zCR*fgZ4$?c88=UaqbjE2uNT+)C3kGe8#1 zmJ%b~l^b|FIFDQ`EQd0_L9KF&;Q&C*ohMrK-?^p%B+5apkIUB>{X zyZo-56FioR0G1esTD^I@TgBMSpe9J8#@sEy) zf#3u^5E`wbPa2%S;3$wgKsU(ne_`}^{i*P{vDv7TMIx;th+y$FH`fhNHg%Rj9dh8} z&zwElaTMFO!8KRCvLGrbm{C@i*f4m^{1PDh`SYWwSjkF0Oc+n#;E=}$lR4$GIOmQX zYna=>)DP#v17jzr2^ce=8Gu1{vu+qx+P;0eDl!5IUg~4Xa^%=C>g!c%L=2Gu(Sbd{ zhe({V(ctb}Y_1kD&H`584esmfBQkDzwaCWujTINJc3&SFsS??l9iSAOWgX}RA7H0JWNdA<00G@M8i$qQsU;n z7XOz?kIf(aX8JU{=5d`zG&OTgL{m6*j~%N%mHR(WclY~6%8fDQvHRDCv5Jr#Ir~o> z3A;vh_DW%3UrEUiOc@tF+jX!WsqMNHK}u2bUpDOOUFD&_sqx4VqfxqDy>ntLK^a!` zC8SH2{-E4r0*alJv%x+u-Sm)!MN++nfkECvAb1o|aQd$ApwI`Al-NSt<4}B?gN{hl zhfdYfqNlBm*|w=wYD|BCn}ssK9(x41huJ`d$}f+El$HGfWec4<@jf+T7@R>#xAdQ9 z4G6CsqYA>9)PJAP5I%Uy^)pE@wB&^|G7Wjlz&Zfx5`fx@-A}v(YHW*4)6_ly}W8eZzhjhJ4SsyM@N#KSG$pQG@yXyAs+Z`R|!A-z8HrCeemo7o>?(FCQ zcBbc6D#9S+fiwtWmmA{55a1v=1IwnOY%XF6E>EE80mZ_nD$LK{GwidmUXHU)Pq)J` zMQ!;A4I&*RRRXtdU@8>x@+CX!SUO}&3=*N50`g)6>q~ZCCeWWU=BxSAQd4K!T`EC5 zjJg>4*un=VC-oxzb+olPm3`m%Y5X?et@^D3J<@gq6GW#m&;4m*5waMFF8t*k7y^k$ zkBi_G%nbKccnmg#_nIh~T?g*L09DI5MQTP8Iw&MJq*HiAg#Vu*x)4$^zyoT^SJgZU z=n1Gu*m#ViP5sKJ39U<&2&IZcTms=gdD4&c5Y$T)5|$0(h3jH+@+2-$3f@OB`Mgo* zP+L{~7S$e&{c+ALF5VGnUe8u#1r`54!{*T70EcU;tA$uTg0aG#L34#p{-xKot1|Eo zLvw3uHjLE9#$m4L*yLmv+|iMdar20NXq)NluW#Qz#+dtv%8P&F5Jx-0E8c>+ef^pn z?(A~+(Ic=E>vvN^AceWW+VDdHpwyv|PXZ}?9L(ZDZ?A+>iG--jTZVQ$yAXffnLriS zkz*p7=t3Tf86Gx9dxZ9CWOQtaC*|aGARe8)kjcB7o1=AJ*j{EmK74mDbN}f;4CkT9 zU|`@cerP01?I4PnvQ!CN-?b*CjWNW$oSet{LMW%uHJ?49GAgYQ!A@zWTVk37112Qn zhE{(08cZypR3{}QERm^vI6HY}fs}$lB1#I1i@)B4*4z4ednYPiVdH}}h-o2&jQ1U4 z;#!k~v|qU4dCxe#jPPP9qB;Z9-_+LK4aOFQp-{dd{x-~boH#}{JY^h>04m#3k%XA} zfwqIGQ0I}ub@lZqMKb`|WZ!dzY8BcEJ&y{locEZ0l-0gO*xDW2Z)s|3a$%71pJSnp z8M<*f!^A_!o@MQ~JnLWfB#J%!9RN7E;yb}6zseb~pY(5|7!9a(DdnretsP@1ydiqO zUfXGFY29l2aZHEI8=wtFqT+*>((uhINo4*2#7fa z%c|XS1ffak4Go_(I+9a+LGRq%Pooff9!5n?w^{}+ zEiOih+>VSqOq{tP;P&KyXgq={Oq-H{4q*3@CuK9`?qQ(r-aU+0r)72N3)1bB7CLai z9VQ821R%g}m#l_f*E1M!Se|$EV-yJ?2*X(wi^_2(|I1C7e;qnM!jlOubB$%L39bW2S1r>2x|K z%4+XB%{jABr^D(8aeRdTii>^V#Z@?Jpep?v6X%UKJT&^7+UWG@U*On4K;|YUb#i3w z5qaUA^Q!jO9sEr|z&c!Y+>N9isUasL^9sw$%EJ0(D%e}Gy*POsDj+SSiL2*IQK_Q$ zXn+6lLxV&DlRloJ4+XjeYAJFRX$YRG^F3h3X%5$h(@Og`im`~T4zwBt zpIKW-UOd@WumbNEQp8~Vy$Q^)-E6KIa__lE%9=1EG4YNf!L95o5R<#X1O;3-S)~)x zUQia`x^?Dg@fyeKJ88mpV0y+Q zmoQWVJ7*1Wf3lK&JHr-Xld$kYzmWNt{6?jig~pAIP!JG|rr&>ZT?I=?{5NXx2ig~U zBq%7lG1&ydPSz_9H53NfIXRKXWaHyU`ueKnMq$kWgo64&(PMH{#a((pda9R(bk3el z0kA*|1cc(gF%Q7Gf&kycKKJJj&a)d}+1q8Re$XA_aR4S5F^L|;3$L*Pf~iZz(v5LR z#u7`C+%g7$;cy{pzvXI<0w&a9pY8E_HWrp?Srnyt zgu8p#Gsm^*n(gQqnncL8xL1qh#(DM3K1s>1KYp-QMuvq|H|lTpBL;Cu+3O&H#8sY8 z(pZf@41#1XZ3*S71U?lSqEhwfX{0NX_FXnGD7~~q^&9b(L9DlJw)XHIr zjK>cRk#ZHYtdyFf1m7M1`9=jVefc-Z@GlqMXO|>?kmGU*`mgsn@SktW7C#!Bh$}vy zRK!w6nHr2uvJZ9z$7M?hS#N4`gr#^^zm}g0#ktGlWM_t2P`Zf#`3JYMP+{^@n;*9_ zoT{jPd@F;6RLi?JQX+^bf)y&?fej)0NG*{24=`2xS=VxQGz^^|Xy==LK zDsJ=L*9h6UeqFzRPZ7$mF8*6Rd712qhJR(SX6l(ik(BKkBVRu}to^S`lMco6ci3}l z?`P*c3OL!hO+6@Gh@!z5V~nug7xPidz`UT*`J5Xm{_s%xzpmDy`CfKTg?VkX305$7 z^fC_xRUD~D#1bKnn+V7^w7@PZ3L&K|E-e8r{7E-ep7V~u3dzgoKK2p&doJ9B{3egC zoa~gthce&*5>CG|&AXwO@#pi?l$5Ib_Vcym%Q==K#X>$Q{bsDO!n8J;e4$M-zg5Br zvnVRo7cPVuh~RD&#pgvu92*b8>zCrJb4}zwKTx=QL5@;n3&eLnp6atTH||D|b(uov zB;4vaMGH($RyVwQ2vz4_gN#p zrrG;ZlR~;nii*I%L~-As_~#&gqdUNHq%k`xw*8hf=|=HQ6g0cPiIPLpKqpcD1g?mJ zS@gC}-m)GeD&V`7cUlFdMMXUamzwdSd7?xemq)T=YZjy%JA3XZBJtgV^2 zxz}-P^#1#1VC(6On+Xb2005u>xOQM|s{;uq_iLW1%>(ot%~l>SzO`YYbjv_w#`5-m z7~?8tNL?TNU>0}zeO>5Kcd6}@ZA;U=xPwBHqy+{AH>IoBBgL%H8GZyEpRJ2aa&$ER zlq-rwNZH9EJPp;NqN?tMhsPU?)mK(-fU_>nzJNQjm4=Ns7;;bDZ%@^5FS4komW(NUcv*YoZ&>h~e}+~9sSbAyS}<}(QEBDi6;~%^F~;>p6xch^ zRC99)@%I05%l!Y1EJ%Ked{_Pd<4a@{-izTyqvZczfd3aS|Nr(SxA#sFt{P%ogUnZ^ zgi7>rPXyFZf`er<2rR532Y-gJUqsWr8BJF_M;*Np8xIGeLg7#y44he+J`k&h2w# +S: 250 OK +C: RCPT TO: +S: 250 OK +C: RCPT TO: +S: 250 OK +C: DATA +S: 354 start mail input +C: From: Hans Bauer + To: Mina Meier , + Kaiser Wilhelm + Date: Tue, 8 Mar 2016 06:46:18 -0800 + Subject: Beispiel-Mail + Message-ID: <18283.122131@bauer.de> + X-Mein-Header: True + + Dies ist ein Beispieltext + über mehrere Zeilen. + . +S: 250 OK +C: QUIT +S: 221 closing channel +\end{mail} +\end{minipage} + +Was hier besonders auffällt und äußerst wichtig für die weitere Betrachtung der Problematik und Implementierung sein wird, ist die Tatsache, dass die Headerfelder \verb#From# und \verb#To# auf Ebene des IMF praktisch losgelöst sind von den tatsächlich angegebenen Informationen \verb#MAIL FROM# und \verb#RCPT TO# auf Ebene des SMTP Protokolls. Sie können divergieren oder übereinstimmen. Obwohl es hier eine Reihe von Regeln gibt wie sich ein E-Mail Server verhalten soll, gibt es keine Garantie, dass hier Konsistenz herrscht. Dies wird unter anderem für das Headerfeld \verb#BCC# genutzt, welches angibt, dass die E-Mail an einen weiteren Empfänger gesendet werden soll, aber diese Information aus dem Header gelöscht wird, sobald der Server zustellt oder weiterleitet \QuoteIndirect{rfc5321}{S. 85}. + +Ebenso ersichtlich in Zeile 1 ist hier, dass eine SMTP Sitzung generell über Port 25 abgewickelt wird \QuoteIndirect{rfc5321}{S. 68}. Reicht ein SMTP Client eine E-Mail bei einem Server ein, wird allerdings Port 587 gemäß dem RFC \QuoteDirect{Message Submission for Mail}{rfc6409}{S. 6} benutzt. Im Falle von SSL/TLS Verschlüsselung wird allerdings häufig Port 465 benutzt \QuoteIndirectNoPage{ssmtps}, obwohl nach RFC \QuoteDirect{SMTP Service Extension for Secure SMTP over TLS}{rfc2487}{S. 2} dafür kein designierter Port mehr vorhergesehen ist, da stattdessen STARTTLS benutzt werden soll. + +\begin{figure}[htb] + %\Centerfloat + \centering + \includegraphics[scale=0.4]{Content/Intro/Protokolle/SMTP-Model.png} + \caption{SMTP Modell} + \label{fig:smtpmodel} +\end{figure} diff --git a/Bachelorthesis/Content/Intro/Protokolle/emailg.dia b/Bachelorthesis/Content/Intro/Protokolle/emailg.dia new file mode 100644 index 0000000..40898e6 --- /dev/null +++ b/Bachelorthesis/Content/Intro/Protokolle/emailg.dia @@ -0,0 +1,2307 @@ + + + + + + + + + + + + + #A4# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + ## + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + ## + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + ## + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + ## + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #MDA# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #MTA# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #MSA# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + ## + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + ## + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + ## + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + ## + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #MDA# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #MTA# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #MSA# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #MTA# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #E-Mail server 1# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #E-Mail server 2, +relay only# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #E-Mail server 3# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + ## + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + ## + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + ## + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #IMAP4# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + ## + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #POP3# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #MUA# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + ## + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #MUA# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + ## + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + ## + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #Absender# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #Empfänger# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #Route 1# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #Route 2# + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/Bachelorthesis/Content/Intro/Protokolle/emailg.png b/Bachelorthesis/Content/Intro/Protokolle/emailg.png new file mode 100644 index 0000000000000000000000000000000000000000..46e2fda5067796bedbf31dc7ab0effa11371cfc0 GIT binary patch literal 38992 zcmcHhbySpX8$JpTVgOQtfRfT7CEeYK(&bPhQi8N72#BPBNJ)1{2uMn!bcld}Lw9$l zz&_`F_xoGxTi;*bx7VJvo=3fB=Dx2u<2a7}i0Ir=`$6IrY}$7WvB=3@MVhyM-4hE`4~;z~j;hZn=}AMRv1rAf z{&25L zjG_BJJL_0i6ua3gosj^ZBQ9rWkr1g`jiOsr+5(GN?;nf2Vd(9eQZFssms#lvCe8F> z>3;JcpE@GhE z1c;JsR>q9RgKrZjzYg7>NMYxr5sgNlwreXFZKWT2>;)i z_y6vy{lV-`fEn8pmOWNsNun^Ym;Wy9ZcyuNX%AH%NU%f_@NE&|KUFVZ$AGq`Ttpmm9erWe~JFT#h%2_(9oo$ zBwybvZnVwZfB*i~{m<)Qb!e_qMy3mfOM>m+bYHJX%zb;hKU0yFmDSPFaci0N?h+^KtidtG) zK6&!Q*4Eb9*|~G~>({UF?D6q&RIv#&Bl>03=#~7oYjDtIyvi|CG5m0EkC!{GnMy7b zmdVMv5hME*>5gCFP(tfrf9K)%W9L zcLa=DXW$|#GBPPS8RHH)IX<=6@qA}gc6K)Zl%1#NzZ7u~Boa9sKC;}O=`Ul}^Qu6( zK(|oyaBO~h`iJY#>OnVGBO;E^nh52u{chCu^mlLX*1;NzO2p;3@$yVkP*6~3u>&tJul!%!n>UHEuC5jZviLfw6@x>H zdmR26AOCl_F{Yr9f62{_%j>#2*woZi?Yy+Ov{c}EN!|ww#}=rD(0}rzy|uO8^F$Mq zF@jB_Xr&@Dk_d6_+Oj$QE~EX>u>F>g25 zz{)E3`6}&)G~|FS6BE<=dvJJ|g4ND!>-+0?nnT+b#>SIiK!Wz;`uh4dQO<{$4cVJFrX7KZ9xI|rCWkH$#dt8&{g zeD>^_l2QlUY~(Plw$?*N=E~c>;5P6En1tk;{pEHV?|-nRQBhF@G!mW=ZV=b6UpF>3 z#-k8$adjd~4EOg}2KxH? zwzs#>j<&!~#bE$5&4C}b+WY#xfw9<)mfsa}NJ~vk&CX`@fzK2aI#k?eW2^BvvL7jn zuy}KMQUBkSq+f7xoD8-gzW4Ee~YsP8YQyiWI5U^jAC7&9_6 zpH#lcJ3g(ftPCOJ%9*pR@jp$MyAMup+T@45xw-k|yM3~xcSB4}OoB0sq-3LNEGM|T z_P|B3KpK)BNfgo=%W1R z#qQs?-COKwYirZl)Sa*(ZiNi2*8ThUWTW@xM=DX{`Zqc=dEpYLR{P8StDL6W(?2<$ zREB>1NQ!k8HUw=#P5w8@I1F1-MLp%71%y`1bq&#ryo1dX}|9IpqR*KVgY} z9lVq3eNo-iL)>Lp?UbD)e&_C89n#lMUePDf#l^)@QCfzE3D1^RR#wU^dnX&-o{d)6 zDu$7_mK8AVL&okW3^4OLo(c5v@%i!N$KFz}YO(3FXM8V)xzpA4^%bP0-_1KJD=ULL z+1nSLeh3W-IqUVl7|2$Q1^ZL(l5k!O_4oJxhd0&mwxA(Ds1z`b0=VJoc(pU^iAm`* zW&gFAYgeRe-8MdRJkcGgyz(xsw4-1nCdovnJZBBJomJ#(KoQe^Nz+QY2(IBI}E`?B$zl#=q_Z0pU= z-L1w;ul@}AoSYnsy_rRC+(uU$+Gf`fxO49h>AXcrsTgH!QAKH<0hi|FX+xWjGg zvtRWyn3$Q4jt&i53BR+jT${>R^h7hu*FMnOhQTxK^`DdM{N?dHJ1z)0TI zAcv3;fQqVhB3apH$V^kUueMGP)?@>4Sv@>C#Kq4mq9M8b`SS;xm4B+r8f*jQLfN=jI`xX)gm?N7X#>b$G39vl=DWa53Uvuh4*;eDL z_2H7HuAT(`?yjy6v9p_-5)iV%s?JVNKhj7x50oVv+A^u6gHfkcR2LavgSYny{T>vgHkzmQcMRImn2@x-(L;N);BipKdF9{EJ969&6C>I*;!Ir+ST2C zww!6anjfQmvjP=V>EP&iaEMVCJq0#XD|_ND*Lb^UmmAk2?`E2 zBluI&eeDXy1et*Grv1Gl|D3q#J*vB%GPhN`m zcb=Y~9<1l(vmHSqgAjnRJYHQUa#$>G#jOn>XocV0d=8Q~4{n*u${*PNmm{VA;_1?i z)Z%aWAm3fbBNuzU+tT0f_|x}V{%G0r+ax5cu3`03_qh4^v`xh299^hl8Ym>a>hkhd z$V@yVqNB^L`ZJ0fPHiAEB#XH29v*HE=0$~th0WFy1nOh**VX;f1VVdT@NPo*^2f`Z?{BS%L@ z3}VeJE%mguqanr`O#&3?N^y8;VZjg6h1@OxS@vyAK{IUs*}0t*G@MhHEcR zUrqmb2l0=DjEqM7O>~dwh46pzH30Lhcx%1iQR?nAw!0UaHp{70m$&MQ2=9Z`RKEM3=30x^yqg-$0xq7($Z20C2DGF zj6H%B6cmS-^=}Slf2utecri>!L1AlWCvMf3w#r|-Ia#k-uVJrI6ru6}cW!1zV}xD2 z?luigqy2;kB8o{Z-_4{HLbdJRuQQG>wa@yul0SK$oSl)8kO&J2J+ri&s&OqCJ?s4S zYaDVL_??bEg$9IY+DjqGnpRd;uH_H^#NCiWe6#C zb#+M25T7K@)_IF;Y5C=WKy89$dS7}G6Gs8`>Z7z1LtA~a)V(-i=Nu&l!#a0I3qcab z8h@v-y^bG?8!~F5i99ZjQwKFqZ z0jQQD=`8`DJb``98TsR%0Wb&&33==3 zNkoi(RdXupp@SBU@j=Q|;V zjg5}BwX_I{h&UPH_w(5l-)eyLYgUXf`fg9>!wgZFEOSb`uP zxHHnxWq|GAHp|J$xxao5+dFd|BnNNEd-1%MIQ~r#xwUdvc;S{8!w^k?IY9*523!j; z#2G$~3$qA@i2vQHpN^RsQXemD^g<0~6C-F0DRGkCUTANQpl2P#g8R}S!Rq_cq)ACh z`}_Ngii*G}g%mdUGxlJzi@)MAO^5PzZrfZ1r@Ha?tHIuEYe=Qt*zaV~SXdj~G>}N_ z9;Zs!O*KHku7XGif=vr7&V97r!Cj&+1}+{M83`lT%)NyTW2QRX>y><*DA3c{$;!k8 z7%*VXDX0>xvSt;48|2Tscki}`)6fXoQ=%3KIb_b&GYUw#jFTcF9+>_>;P7i=Kr(#< zuySqSOE_eNx%O}%U)7v}R%CGZ2`x>{rpZr?EG$7XVM^dcHI@*`9z1veH&*@3K2t-Q z5eAFw@(W-Yn30jTwhPeX$$Af1xPArLK9T2#>mvZaQoT-D{mJui;bEL7V4^UjmoHz^ z5EIX#d7-eJss_w26p+=mo1}>0Z)TYO^Yu4IXbBJ8-pb9@X@2qzV!EvjgsKbM(9<~MmtNo z?2QN|7lH0k%+L^iluj=?Ut zC2QLHoX%z=mKD6e%PYCnG7ic6IrWN=D^rb)@$m-Q+S-{4VKxo2@(oKv9sJpc#djmG zq9Wf2p(if?AtdDd{Jiz)4rDYPBAXAyA>E9(&-5d2TTr}R7ulVADDsqT?ENqP`(yd* zOn-_wM>rt*89oCL1JD6h_a+(Ve9dR4t^lPNJiho77H0wrnvSXPXH*;3)Hb}}Lw2{w z$d(osbTl=cz_>OiY71<>^Mn_7zPKUH7Vr$dwx(Sz_h?wz@~OXIhV1!MeAsBKYmj=k zwoH&nF}qPdl7P`mH{%1MljzlPoxinTudizB5`d}c3jH_TgF*)Z2T-L>mF2Z|JT}of z9gF7tE=;>W9-j>KV>T*m>d5NlQ51xm7SEq^8kS@I09c|;VZ-)C2{XUT^;wa+!9Ui6 zKYsG(>P_`PLiYFf!N$E$SH7$cd;80Mno5covE~>n{>o#Lb(a1|asM{$o=_SkiNec+ z>LCUAQVDF@tF6h2;o)OQLf||Q6^?yQ)BRLIIa$Xu0FQi_uAmKx(!qMH(k`4v((TnN z0(|_%8qy}3K?24kH&1=xAJWzFdGr=tWrU zjAAx3GfP{W>;^UjoQxTzvpoWNQ&mMJ0FT1$bl)1#hFCf11p+85v1qFf@L9lUD2UDj zGz1y;fEb7&d;zYNfXD+T{i1E%wH)kXvgS$cW`afy4 zIN}!7A4VI+YK1{ncGBJi{(`KmXKkT(jcQzGYA7?vfIPebVTXmC{TBf0i5gc}qWxDQke_bfP5}CHk^$KKffPfv~68}P+!n6k-OP;%c-M%?keS5a?9R{r=9BrE=0^WTz zq-TOL47jI5bZm=|^{2p2vp45sIKxNZPa&M*ZvafW|r6{pW~BoHCMi9qQfuYuRPHc~co zBS1y}<-h(Ohv7aiu9lf>VfNry^hu7(a*xgRg@nzBOa4z{pIK_3<252KE-pa+)XI6d z0+_MlRR&wl9kZd#CU0qR>2vi4Gsz>1&KD@{=AF5ASs59~qh*eB3Nh>Iw@6m?wx9GA z<>U(%VSH#*TRF;heyNMef^vz}oI1qWNLYP~0StwdT_0fzkr~)lUK=%5{~g%BPmq_( z%gaITeUu_*(9Ffr`81o{HuvA1Bsa}NyHc0^o_q?>k#yFV^mi|Dy6=C*&g1gYY_|d; zQ~PpC;{Rq0v4K|LlGKsZnz@}3&;L*A2098h`M0WORb3#&mCv(ahxvxc+4G?fPHKVH zi(?JIbU>#C+UGt}YB4m7Y|iqg6{C=1KXY@xd|nXd6!!9&S82idHTRR<1;E*e_0fv% zU%wvuyRxZ1ZYYXLPGR!CrirnTU>|i6-7VIjyHV5ysBd?77d(G%X-Th#$X4oiHGa%F z%N|+AZj-j^#hCW9tlBQ46(|@@Xf1p%WwwD^?lHa#@Uk?uoH6 zwMVxvAYLI+QNTg8DuBjH3z5}4jEvbZbny9EFxO~E=Fi*#*Z}+k9CNfep(^-{RwNLt zl7T4r`R^oFLM*_G0}XFI04c~>gIQ((qMNFA{sR6Bh#qo-Og>f5)knu5gx zhyY7da#b&iaDr|76dx}PT2i>=MI6B4JSHeT6oXm|gNRQ|^u9blLYwdbuu5+b34kwR z9-poiQwY33`-e8o0{KZh#EIFtxhEAit-ooMgEk>BAb^hRHT0CJ&N2BjFo5yZq)|dbqM^Lp1&}sf#BxD#gUw`}Fe>|2 z1`nS}5%n#ss}QVjsB3HUc^t08s)|GK0Vy8@+=Uvx{|q9$&g1A215rshI1VWF7^bKq zBT(;>{>le^fU?1@N@6w*B=Uv1Ik;3C@B$FYg+>1J5*FrvIavp~0+NJP5h^c`4x>j~ zhKH*F(b?n&T5)voCr2kFoG$m%TYQg9IS~M4xo%B^+x!q@67V+u!pGtlXH%D@U$R(! zcXhFeiat?0$W?#wVjV(f%xFtfQwHQbn|wtSj3Wymr|02_WtY9{_O!HcFHrT(k+Ls< zUx&C<>HnRdlZf?hLY=1Aq*3>kIGf{gUpio7)(T}nX(sh=vUA?#Gcz*>*7x3R=7u5{ zr7kRCGt=Xg_1W2sjsytHL7|~v`v_vV1qDqSJWoLPb)D@}zi}gQczBqtSEZx^{Thlv znsXql)PE*EzTEBR0wrwXpd%VU$KAUpkkHAvjDZpZFXy4Bp9A3!XdcPma!}PPE8SfG z^Ky0uC$t&J2@4DijEERD4+MXQ^=xf#r?{i-So#s5Dwq%kKm}XvYmu|I zww|bcRlJKeU1HwOrxlJfGCVA&sHj(+keQj8oehvK=ekNH%%Bc5LMWEpx_j4Pq{kAf zB8=f>mr%6GUKfEq#k`ISYU_`3>w!T*Q+b$wX<1o46zb~g=8Kt50`#nkt7~fPK}DYL zh*-@JXJHi<9_j5Z?lP_npg#jm<-YD$@HLFH%)C5nP)^``h9EPiNn`5i=_x8ILTwM` zhePq)(sF5jo`I1Os!u%p{0D#tKwJZ*34#fv@`qAVKP*$a6F8-#Kap{uO1&C?{7{#`S~#`i^kB+ z%-((zDoenMK`zV&A^xNHiuXhIB@0e*59q(haW^0M;sB)~NgI5jmja~`Ks6A|%1DFKQm<@OUb zi=we<-tJVoKnUTfK|xq21pr{0IyeUe&0X`t6`T2RP zH0r~_#*Pjp*LiXu*f7W{AP9h2LD@vt-y;V(VD_RryUX!CeA{jPE5Ky(ybx`zLc@x> z`uYN~k126+xt+WyAd64U&6(8_K#jE2*?^UCxx6?B7-D|8obM@=0zCH4JE>36(c1d@ zEZ+P*icew*|ZyVr1I1 zfyakT7?VsoHzQ*!jOoILT%uoj;=_jzP0h^(>tEq+j~1p#UGH;ns3|GsIw>(oN}BK< zAWZKt@$xzY&Vkqt;x@d@xXNsSX2T^|OopY``UVC=MMjAeD(s}7Y%jptEH0KVy#`nF z4+!`y9$N(qI*_AA94t5R<+0xDk!V|yuT@n-Y;3E5f_L>i&QD$aOWcy5o0&Z@Yq~1` zyIV~~<&Tm)o0hsdAt|YDfiA~Mf%WkRJuNMCVFn76=$V5_q067nOOL>W_`T{uI)DH` z&hxATDz6m$Hdm*=qS91!MI`K$6)&$aD@l z{zJOfAwIp@95<+Z5r1gnRQwf0tHELuZvc6t&QC$DebiH|WO=8pxmh;xk{rrwA35~D zr9s38*>fG#H3tU=*zkqo)R>qG&}`U5ZLhrh0sR857P{@A3;|vL3*w&BLf0*N1*>K% z1}NkJ7lH&0@di<3t3ltzPxU!A_6V4p3jSYRCfK#amnNomcJ%;-0BL>u&kM{C#`OYJ z`j~8}z^X|}`8=XDvHg?P3HtI!N?{(G!CZVQk*~(}qrJV4f1iT#1N&RB%M+YXegX13 z1c2GKwK1p#0oHT_w;Zkg^BmUpS5wndD0kL)dE)&50`}c*tj&1Q6$}s@48VzikdQkp z{pi5^f)v<0YEid`3`FPWM^n&k09@n@BvydWjLsGw9%t}={@L*;`YtaFSQ&=RV8ea|(%#Yne;|Lb(&C#Z~=?@H(RS3u`4zYV6z=~y4*;^BpX`-9-`4_4(jG>k2hszq08mN-V5U&{ zUmYrdSOj`C3kSzJl(~9-{Ti*byHAJ(ehzAVBA+$gZ5&ACMj&DWMEW3?F+Pq2P-~M! zOa`^SsmqJ+>q!>0&PjVMD@9OvtYPZ5nO{9OcSAqF{(IXqLvRmE#F~37Q~K zp5kl}4Xp8`n@MUuywk&g2@?+wVR`6HQ&VPf6fD51j?)3CFu&b|M*`ZVoW6yyO zmFLfaxD568KL9`l`33au^*Qhk(8VDA*1z6k5*MEs8L5V60Du6TU8xoNk>O8Ej$49>4-XFkx1F4vfDM+Flvo4if_4B;&pJrv%>j6-s;X0s-Y=mn zV`s-f8Uj_i+C4OZ1N;Na7PbDl{@Y5diPz525%A~11Jz9+G%{F|MF1KlD6OB<8C7Go9% zq+R*CCal}ANv1w~Wl4z{it9|24C`uSu&j!Til&y<$TU3aBSdEkInYc=WYlE9(?H}$ z>mBGj*LNm;5D*rA4JyM6dOlP0A4xmT(9&@A%Fnn5=8#Vg0OCPfprN5TbcE%Kjn#ty zKqKizNle`Q8{-6S!TdM{01mq7hHe%CX&oTboq)V;CwLyjmXn!48VE~2E=c+{ATm6> zN9eLOX>^)~?$IG8B0>jkh?IwFW3L7Go;%w?(2HEw;I@r^lh3sDKn&V%1_sKSWCF}U z1gNwbVmlNst-gK_s$xy+e-KdHn1pbGF1_XCNC?yX?dyu4Xa;W5Q3R0=?PX=*5T3b= z>pCPVzkeqnAh4uC6+Y2(Qkn#9TUa>$Eu=yAyB?0Nt|TF?FKPgdfsdAk8zGVCrOQG~ zr4JwCp54sTDfkSgyT5;lfHeKy*B4!{d@;gnk zR1N}yGTJ@X*KvOUlLsxO=Z(3!IfzFv;%_gfMn>Ypo>!JI1;Yj+p}rCSAR#KM3}D(u z9V){YOl%CK^X%gM;IOa*K(XUhJ77AOHIDhZGm`a{pmNzZvug98+i_&J{(yi0$qwBB z^6fd`1dGE#a)B3C&z~QHItcNy+-3+86eFFCF+qL6a3U!WE`7D;P+#9CwYvx)U6BL2 z5Tu!?(1hwHK0b7U6>M`kfvUWsY65~igfSGjJ2)_-g!}flgQ@jyv=Oc2s3q`KJ1yXx z4MQGtB4~r0^d%>!G#s=^6HQIJ*J2i3(dZ7cMlMCgb^snAhjl}HO;uHu7d}Xlld9$N$V5 z5)U!V1M4w9B&P(uil?m~N-aThWv6oCvpF9w^;|8Dl!UdSw|NqWT%O%fzX$R=@+=$}}T5ZsUyH z)DC{=k`nj`2M^Dp*9j;cFF$|lWkYA=4XDkn>v*k)<2Iu^WngEZQk6tv#0zyrNIs~v|9p5MPWyJGG`DqJYFw*y+~0Z1M!3Q|N7vbss&iGJkEs`+>G?a;CU zQ4>nVmK~pHMMN%tL6EL_wUq*rPC^1(e5Q;95JzZI08xnx+zvwTYSFh*X!@An+)VlO zX&dUa-@LQ+BfZ;!ZMpGx?j|KsnwU(Xb1(qgywA0>(6h^IrB&&i79ARji_n?OS1NvZ=a3D!EN4OLvb-MJOlQ8dE|Ym zw{Y#G3$$;bT*lQ-jEI=;BCIHvU+_=h0_XzlPCJdB`5r6@2pR2DQzi@kc|))y;NZ+B z54yz)(sZR$tc{Bd?9-La(v{QYBjjVNR9@bN&R6HcjWCHf`yDMUEzpGcCMp?xwV+tA z209QV-kyTgIy^cGL6+~{J*mZgl`d#35(VN8$OV)x3|w?)()J8=v%=ztpo24xu{1|i zV&WJ88X&h{&+GfYyC;Uu%Q3WJ&vN25xJ;gSrWhH&(~*9sgOQbxSV%p%>9OBhNXo%B zmI#OddJ}T|-=Q^2c&4@oR3o?!4iq5QzJ~Az+<^vKQU>$T-3?BTjw{0@=73@9>+3~b zmZztu(>lETWM%*!(b3b>LkAfApPqhiZw~_s;b1xf2aZ7=J~tSTr#wj%e*AE{U;CpKN7q&T3-zkOkETVP zqNU$c%sjtZ>OJ^PUaLXN2+%-f{3M-lxEr9Jws4x_{QNFp82!DHmvw*v(ad$EZ0Wzf z1*gDVhApY6sO+Ex6NHt*!jT)G>wqXdGBUFM#GD4SJiWLFRY2S@FfhTjIW69t3z$k0;+JEYVr%|#6T*AxQ#hlkH8-as(d8#pg= z10@ndJNUU4ln<4NBAW;g1uq&xY6-T}WIk2M+}EqBlnQaPLJ{I6X5`URl1%WQeK$Z| zmv#9F^%+p40t4HbQ$3qFUqhl*P*8vpD}bV2NLS#Bpo8PnNQ~ErfsPSFAliX0D6x>1 zpd8Q1i;{oF%iLD^OwrUwoHDt+8DQVjUw5-6F6}zm^>2Dw>P6N_UEROnXHH;t(5F$N z+5p)axSrz^5~%xhWz&marKQEH4((n!KJrS-;imGzFy7vM_gK%R(BF{FL%FiPtybBj zLKk!%XcNSz6e6UiHa?X4{Qmv>{qtrah|1bhxI2u<)0^H#Ev-s&A9i{zC-B`cxzhyS ze3vP(U(P9t{c@O~0I?j36Hwrr1{AsO^Zc5ZmzN<=wh+`kBxwB<9ru~+FFsB=e`@CB z^LfYR`F3WE=3HE3N4MQZdV`-|_0c1=<3KmLNu4{bWd%r1U9WYcUs>nPT9sg2qC_bIX3bpdr9oK>6#Sbl%=+1i3prE;;2*E1-)g2bGE>eMyw>$YBmiZEut>xZ4kmYXzaRGwv`UW8ghGgve z4kx=7on@l~*w=a*73Nu_JB`;jfP^#|qR%@PNe05?C~&{;hwuHzX( z&jd7g2i>BF4jy2(GrE z?HrR?)kEAT-p97Cx$jQX6Ce#qobL}nV1wSXOQ;)v{P+<8;G+3AeTGi5IusGyTf&>G zPIDWt+fL5a3)T_Ls0)-fHowAGw<0Cq)R5FZrr3M3;XQbR*SuYWu3fKj1T zvGh&Adi4BNT<*ZlI(>hgKnEkC?|$q)HhoHqcl1By?tp+X$5 zRR{Rb7MNv1v5Ewg7KnU5z1;3GIlk$`$WCVZ6Zxwm@Ndt@Ldw;^d^M;7LQx2e)d3ti zK3OfmEMJhZ-VoqMNNtrU&ED2DKEgSU>u03Y)qE#SJbaj@I4Eon)zrW`pf{(`PO)!3 zQ_}HYY(RPM&TC7ThWDbb>Xw)Sbpw-(ApWNeP+pt06_z~8`*E}#s9B-5lCBv|-D zIqwSD0= z=SQS!Ypkz1KHQJRFfP(BV~mc0*0|4)s}cLC^#8K=WJ)!GZ80hS;T&`))}GV zDR{dC6=Y}|-k?^HOruCza+}Jzao1!6Bba=6j(IA8aWpqR4%g!5;;O z(MNVqoLL}PhLdTB5kYhY()0O zeb6|HNj!(O5nDG5qYp9}v>4j_{StG0qA^{d-y$GeR=iVz@a5XE;LGsH6hz5eV^C9> zLFd6djX8gjP3q7_wIK^R7{>?1ZG*0!u#b=8!I zY3m2Rsy=L^z>KS;wwfGW1jt%|QFJF_rF5X9aKaUt8WfzTRPla7V*QNZqS;k`G>~h9 zzX!Bt>%O#isi{+tgn{BUy9(P#d(W1~VrBU2FJq=^XB|p~E4s_2Gf`BaZhwaJPH-Hyp~PF^qxsI*_kUPfwwVfE=1|$2KyxKT6;jW?f}Wo!iTcGxUu- ziSwpH*_k%GYSj3Q+Uh(I5ZL@%n3$Pq4m7p8NS+whr1eSNM(A(J=^N&EQhx*&4tFiZ z-_wE4E`$$2J!P)jA+1ntx$+G(WS~)eR((=)u8vYuk~oI552(HU!l|dW%6m zC6v14?J8&)(bW6{5bZuYjgW&W$OT}P-O4)1^d0q&8%;%st5~#2LBW!PjThE!MYY0G9>!@OyT68}vl*yI>_kq*9zD-fG&?s`W=J+Uw>h1y9RoG_E6&E9255mwxn8%9BiM3m`FpV(}K#im+ap_&VVyohmLTj&CN}~ z2N?O3*VzUD;FqxIpb*}`r_?X_EOCfnK?!{d8OONeaO0It=Ai`=5EoJ}YYrx70XPFX zRM@ucEkW6_x99BSuO#jot@rp|ShxY=n5?Yq0q-EBo!47CUiYqFgf*_EPs$@-U``rm zei5!)4lD(z!3*bppq6)1fL3qT!=b7fE#?I&5RiLva&oQfz*J+b=P~gYS>riZJr@hv z4FP+t+`Q}IqqakzU;-p0I&Rpa*$L1$1#&55lxnt6**B*e({gk~wV57bv-Q&?!5!E8 zLUCx_*P#jqX!pT`yxF;k)Ksq5NT^gpRRr45UoH2&YcC^GhDws3e#@bBs-XJ- zv3TzcrGLVQom?6lDB-v)_pueL65!!M6$zn^M0zfCk;Jb7P4@M{gTN!9y3*x{*;#!LTDvU9>=BSWf!Rrbzy!?UF8S(8 z(%XG1tzrg-1BES@tRuzC0U@>Y98y38tOYNa%Rw>+8~}wz&zO=9k9~fvOfvWWoArMp zCMoKB=frw?(>dXzBqSvMfq}5~PcCerj&DhWX6&Fv5kqy8$3g|9`9YI3`!u9hEbg=8 zA4??02QpkZ{0FmuIHm3>J$_ug8~HvXgAM^_{Gi?rhhzH3E}mPkK=P)VJdo>s#_&oi zFr>=rx_?n9?NAG3KY#yL=&HOe%q0k_h*=zHb+$R&6HS5PzLl)f!CaoHGX_t}@uac* z6GmYnRkVSZwSLf8ztMQZeH#Bra)()Mz7QJ*ek&%;EB6E70NW~EngiKetB4y#-Tee$ z?1vZUXQ1AZ-__Y^onKHJ)d_M^i@8GRK*Vfk=7Al%%){C;Mw?2TBtyHzJjK z8MRk2C-_qvKk$j;kU#u&({8=OgJWc@;SxCcj@YrJ<|P=o_;U`HE{ipk;?0?d&|EYDJF)I5GyMd&>sF>o)(Za;jl$4jj`L21Ip7*1X^49HG`TimV1Ab zR+D)^Z@LLA3fpZQXa->ww|4-|0BVXA&a&c|e~Siw1E)1A_NAs%4<`I}hS zz~Q$gm}Xn%pVqoY@t`AkxZ(vSr?YgG+bRqt>s zI{5uwoxTHJ3JC?oja`(+wu0wrC;`p29*>ak=G+R1pPKAc0cJ4yBbdAtdULI_S%&X9P}@VJh?N6N z`ny9nNm1jh-gU7P&J_Xb16hpug#|cob_J*)CISFbR21etUS2JBQq|8}Lu-Wp>jemr zqdQcj3uC6a7A73N_vBmaowg;1BK%bcBYcb>-w(<2puL7Mi_VpYDTMZdbn4B|kTs`{ z%k6@C1slj@z^V8!h$rXHrErmc^3cK4mF9@4NxhJeAz-F;r)k~H`%d7>w*)shwZ$6l zq(&RQ&2r}_Zd|62O5jjA{(-FW>wS$}!&@IDelp8oEt#coc|up8Qh)cMAxNWPfw}=s zg*HF2J}S7VmLmhv9h1*yT6ZcyntNhkz}nED#E>zzrUM_snZcS0uxsO%2yJ$;WaVfL z@v=f9lY)b>eLzDi*?aA>I*9FqmT#NQp(1#wM_ zTmEW45Bpw#AZp>0%CeUvpP1PAzyPm=#08X*Es8w|u(2bmy?|yx2=aXU7Mg1(p?!*N zD=-ay3Sb@x(oWEkuO7EAG#qL_IvTTu<7-tz}rCRDau4f(PAqXe8c%6O_}vTohq&S zTpdblAcQ*^U7K2-PZe_A3-rdofnA&ELw9*zajC9X7imEO))xME#M;{fL`J8z3uHZB&Lt#&KE9EJF`TetK`>* z#Opoi*>TOxmPex2G~t|uBW4h-@rP`LFQHs|PL$QSPqbonK$OtkU?sAuUu`eoHbXK? zuRrbXpJ(3lWx?WG6085sk8!o2 zg#3pS`IN#kaiZc z!edh$vAchix$S-2c&7z;&*N=u_-sNtxMj-4;^>>NH?~O{GE~Q1Aw(#@ev@EJixn)F zMVutjYzdFI2}M6%{G8=Q6B7ahi`$1l>%3)9U{dnTzZ@+ynj+Z2`e4Y}A<+G{h$Kx8qMS2>iU`zF?Q zMd|WdP7Tfs9OtX>8r<)woe?iI}A8NjSl*2y_N}%rLktXacv(GEA0lnX~S!o zb<$v^B96RdP@T{HR+=QBch!;7}Ti7|Tj z7HMFfzm9owCLOOnu!I$*+~~By_vj1V5GM6otG`x^4;C6NhY~+Vn?=X9m#^Q~Es5Ek zyH4`Au#YdQE`h;EJC5o@9Z9yaVMNnD$JzdU)NtGAi(fef;|1w2s#s#wht$n3b?TCK z&(&9wSJ8uuGGZZ)k)dX5?w)2+da~Ns`J!i`==c>pUdu;MbkYZ>+fY{0cQ%P!s)mQ2gl}#-*#50R_&7)KS`6Y8_U2`TO&vMwZFOu*1(5WP1IHMT+{#B63V|Q2xtx zr4yaxn~E1WDs?zUM@8Ikm;GcO|L*RQTQo@G_oM9zDIg;Gc-sBNz4mJp5o1PFk%wNK zgdh2SR=wL5<_{WT2+X9JU#=WtwAK}!lq2l5>Wg!1?Xu~Ecb!4^T3C@UqH2DCAbt?B zCgT#9r1jt#)1wi89-8i#A6ZeoL!~ETSWCy3%$y{7f{p{Y&*`~+!9L%pLo8{(M4nMK zhTJ0${rUMDy8oTpW;xJ?iGlUQkl$ss8xb=`XsdqFO^=`MwR5eBk&R+mKvC-3>Y zVo!*`6f3~N2uq`kJe)%NuS$NK7##K4uB2h}+vefKOnby~nYaJueU}@(xb!ESvrx9F z^prU}j}7Wgi+h=@2?Fw3=n3kUdF3YM^+hLJs$EP5wQUQaE?QDS_Govdl{=4K4`k!- zF|aVtkkD= zdraHl5LM4ZH4S9w?9;e7tHo=qsB%ilFgDDTSL{Neq?QQ}BZBK0hil zLdIrLj89Cwefze$NT#QyZtnh}{~hL5X7uMlFsZu8vSO8$!o{lMlno4}68*duUN*W@ zSkL6U%(;1GIrKM_7v2a62oN*>F{mDO<{6_~DUt&n8YUzjM5lsb14_{_P-E=GL>U&5~N;5h|;;mYUlWX#=wK;Bm?v={S+Y`Pkuv97gpn8k7|wzYa4Nmds&`on+1loKF*NV#Mf@bI zKl?Et(0Z**(DVM+)p9uAZFriWuKd8WM=w{wt{2PLuBNAhPl9#b&s3yGa4bwlHebkF zP2|F=T>Hz;7n-icg!{;9PCu*9D&r5V&E# zP|aqt(t~{NN~8K_oS{2nnj7u|9(6Ys;5;d8!Bf9ogPeCWcCJZ`EsNwvJ4NBk$K(-o z#RtEmX$>^Z{7Wyn&eGO(Nxlgt=qVo%#dlmaz4>Hl^Rrd**RLN`=l5l;A8MKCB-p-a zR+D)|uj-_eJil)*U#VHh{tO(2Ci?T!X(=S2BBB+qT=gJ&#p$ibVM6s5KD!+3RN{7l zJ^W~K5KDvi#*K2DYcw>+$J2{yX`UWx_kN_yTJ>LvVlw;Z&bh{r#3L2|F9$#7ZOos};LLgM!;13UjtB)j#B=5quxsOEck z*iz|iZN7GX4)=r~BnW3zHMKFc4^}_kGB+`C*~p*y5Tu*uA|P=n?LTL4L8e<(_o(z+ zSEeh8!Xuqs0UQmiAGdRKijJNBacPcuL8A)cZm3#Br;)%|1W0z>Y zJj)gE8-voT6*isv67Jk0u7BM5~BDK;zP+%E=igQZXwN@KbQgK^?cB zN30WI7$Vf2PmL+h(DdHJhg}?ZMQ&4xIB4Vb)4`jxeqd&T_V#gNCsQW~R}zX%M){LY+rW`tl4tbE5nS4@yf);73E$=Z_6F zH6#D8+TJ^y>ppxRHYzKT>_ilaP>HN4Nm7XHk&#UzBNQ4$BqcIJQOVw9WrobMmF}#} zLRQ&+=R4ou^ZfCA|9w8kecVTf5AX3B*XtVRb)Jd>JYNG2tX&lEM%N)F>9y;@@2kI4 z-0Cl;m#6&e-bR;yZ_oOT8|GD4P^lvDXnARawO3HZi=XSBXUn`UM9zk}=x9W%1lp~D z-VQJSiYn{%>tio{*9XsKNLG+mNS6)~j|T1~G?;2V+Wnyhq&MTDaU8~}LB%BB2ZiuZ z@`ZIz|FA!Y<2p+GE>NOR3Usx#pKZQ)(a3fylFXTCOqC}RNf=TsNr%UAahHdSN_^`u zZUtFl{vP5vbC1v7@EScrLlXp~TpO&IEN)W05pAEWG)%lu9gLxaBl+XIjF<#p$A@_D zRgvz{CrvQh!2qnu%gcjDW%b0f3*u2PUS#&i6#Hi4PiQ}rgxTHtJ5Wu5Y&5V*)Quph zK!b7;QiRTP8`q}Gs-vZP8ca$Z zcGXM`FW7OY)V4LHL+YZ_K7qpHfl2%UcYm=ddHcka9poitP`V!abj5jLB0MI>`MUp) zTV5^haqa!jRr(&fu+}SkD4cdY&>hpiWiQn^dlq@k#=5$*%cXZN@?TI>Lm#8Dre?>e z*YcwGubUzRoPxtURnXg(_u%ASqET<&l@m}@WYt#y7em8lhVlC!Cet7OT~nx=;ncgm zgGY6Ax{>qKl2Zd@W?^ALE$*R~+BpSsr_ozULiWw3al!TzyeUK0`{}A;4aq;Vr<2N5 z?kd1gW<9u9^oKH}2hP}M;8UV@b0URJa?-#nn)eg2$zP;YORhVRINVXSiqvu1VVM%Z=UYOE! z*W2sq2cz|?j_!&&X0nsJ_~E6ZZ7<2CZo^d>6L%Q-D)h~)1T$?{_{=Wu_ZIpPcRb!9 zbX}NbM@|Y*N~6T>=8n+?XU6JWP>mTm+&hUqabF5v4?u#am^WnIa@=YHECok>lvv0VoNmVS8p3-Ktpc>Fu2ETth>vZKq>J{y2EYwB~i@_%a*BguYgYAZ1auo6;WGMt|P zhJr4s zJ8Q>)$<1cg+C8l^>=`xO86wL$Mmv(9wzX+UOP8S2UPtWoD-cheaOUf*2VA9SNrjqwHjVxB7dNFPdeu;k@=wuY7= znchu05Dok$36dcs2|JtJxHo^VWh9zw75RS};*VNJ^bfe?+|^_{Tjo$2~Xu#`K|U8qs`!tM^`k9$5Gb--ufxwaB7 zFf|%2WbZX#@Nn?7#E1X)hwQhXuu_?b{K>&SA#D)jIdkCpr06Yex`mcOduojy%<1l@ zcDG^|d3Q;Uf5@!dZuw&H(oTh)0VXBP3HFHWG+cPPNgh^9kVt2p-hKq5`G$BV7v63R zCd!(UamKY4cx7ec*~gR-;YQx3B5^aJC<&+M1)_uaO_B>$`$;Gq_tNOucgu&N3_o6U7_CNZ`nC>e$$jFjo6l4fc$Cvdt)=5;i zS$mq@*!0bj*R|h>(NbmUwZrP|WsA)mS{D9g*7Dd^0!6XMkLe3iKPw1RQ3X5%#lUu| z?dB!Slb;h+b{Cw#C>f`l_G-w0qjn&k^(&*wi-9QF`7gr$9cXf=q^^2>uBYhfqy}P+ znz?NcD_MV$Md-LM?DoD=!mL5z^8L0_>wktr_ddlO)4gwD!GEQML&Ja=xTz8L+b6dG z_oVq+^H zs)U1w3roW9`lRuQ>1Dw@WraaLd$SVe|L3QR{i5$u^dE%VC}CuHD8#P^YiL%hXK0O3 zl*hA1hpc{yY{vfCk#jw`E_L6+i9-!yY~B@g$YS3nuXBo-)K^kT zvCe!@v$3r9;MyBW_fj7(#XxZ?{MIki4WY8Fhj)qE#L%he_^*9d)~ooSQ1doCTE4UV zflEnpirB}P+>|#0!aPQDPtX8c@FjARx|_v4n>7fQR`a|?T{ojGwU)iqxlpAM_WkX4 zh9UDQ0WtjD=0o?m?jJrecD3@EU16=8;gF*E{#2w*`*;iQ;8~CQ`W%G<-b{ahadaAT8~$t z9*#Er`f5!oZP#fTs;5bPNtT;S@rM|N^J@QJ&T0QEg{&Q8-K^Lj_}x0R5BDawtD=#tNzuVsz3BQ zsP^{UrbRw|^193O$f=+U0+>ZaQ*%{M&(AA=pRG?EYZ_T??;*$p}FWDSR9ding_@ z4Y{zmNZNXLw10DEW3(39#hX>I?K7O3`#ELo36lV~Y6QI*E4{-YQ7y^vgpBgp6^|`E zJ;G<}K6{X3C#y&72DEJgM@AF$Mjm7=U$HG53;okAmp z`)9hf*~fKmXTE8TuJG)d!gGb+w{~Z?+8y7@WXN`#)MZ*-i%9a|dh#lt_cLez$tw3f zPkwkW*AlKra7y5Mwvtsd94&ekgJi<(r&u)~niT}K$-5Yv^Z0qw9-@)|EM_Qr z?~CzbBZcg>-}fg2^JxE_2x5PVs!!~268g+TN)`9J)X%_P=QZ$1#JmQ7X1;oDF!6Y4 z-(WgRX{12~eG%bZh1o?{ZQ&brbYQj&f4QIXRQus{Uk5G`5Wf;5dvEO2HBoW@eTHsg8Km9aa<9JkkDKyo*~ivGA~if$%LZrO@Ql!WwW zmg<(By=QC$HZOV_NWAjjI+XJBFaL^_t+R5;)j8wslr|@MWbn>A5*p#593lJ60eyqK z|9n;KS>AYTzJy9QTP)X*(_S*HXSz8>69wj+9%1FDn=hgdG->(JUrGhm>ctzYQ)Cgk zA99SsY6));@S|Gmhu*$tV_PMel4XBK1txQp(QFT?8#;F;+?*%#?mdbfB#Xc1J_)uY zwrKp6Uk}mi^lwX`OH~Dm>O-8BkI}RzrTli&ML}=ZJB?H^NsF&CEzkG2ZQHxfMe>4n z4|RV(nhlJ?lmi6&+m0vM;;#}pXtMfwFS{v@>bQ4ut<8{w%-&rlZm}=V^L&z~+}yZ% zOI@jQjc|rdx+AZ!IObU z^bCyz6(<(;#jNPWw41puF$=9_*}`~-zdlY*qibJX@UswyVcTPI&LQdeT~e!S0uje= zZw#~7sXkXqT?}?!ukPA8%zopyd+DRG$bb)yzQ^TX?Jm4y(7&hu#4fq^3EG$UwYTg1 zIc?$H6sR-F|24YZ0z;>~tkYu7{GyJlarbk}nET;}@9va6Ymm3bV4S!wHeAZ?ZM5AU z0l78fjQZ7kNr_T#lGm>=nK1JGUo3#O?Gvr?mm@y9t_g0Jv)`iwT?)dn)e8jndCh?- z!?vP7>nE5+YTw_S$OyK^(LhGhm4z~JvJ&m-$m69n>V;bkVg`QEPWR1}Z2NEcTF>E! ztfa?}bI2^-NYHA^pLYQh&e^lyithcH{F3%GD-gT`_vqH$AHsOsC_N7P&>=;fGHD> zmUwP zTR@dO$ygtkQE`?Yx9M)6^h3F~A21s<cAeXU?`F*QDm*QsNMHhwxbtVsG=eY(4*we;?zmFV# z5tv*)aNNRZ-*s01po{xg@>OF$XTC^dNX}Ly!R=_sC|CPg9{uKFtl4YHp2$|oPa#=8 z*geB)Ot;_}-+g?MkCe()@`>%1eFr4`xG(%sHW&Z0jaI(yQNH)tDmL)o{MkZ})90e^ z$i5A6hs=sVhp}z_94+aU(W+zSv_H97XUV-x9>8#?TGulM?)@`sIQ_`mvl;Uw6qZ_fRb@=;TbAxmM$*)=o?+*q92qWV$v zA_HA1qRW1%44;P~b*6>_8XIC~-|+Q5<{tY@>WfRg5xreW`H=F=*d-Y+KOIxb=f3AA zKWDJkymj)VdNzM{V>zjhbPw6i#XV&~r!Ht+34B=RekqcS{xrv<-(A-4ne8^}KOl+x zLe@uaWG?$wk(4ZF>o!k&mXn1|oPUOnc+1q1e>}Tx6H|8I&M6@1^tU}&fzlL?x1-ug zww3*My?ew>8^7gt5B8Ns3kmK8Nognkn2JNzsGD9y}H}H&+t>3W&r8|C_-`8IYT{hx$8Fzd8-1U)ImyY)WvZQkBi?5_o(sIEz zf~yG>cYu^DJkk#2FJH1uPlM|5$7KrukHK9JRuD(r_}#mA0Ly|WSWGM(d`6=8bPuin z9ypEecW4X%g^Pw?aMFU806acKUq0ZWv?B2J1FDZpDOuj*ao3I3g{*0ul&x?E_4u zrlJxHZUQu*g3jsZuU~0t(Zgu`41X9Lj6X8c7kI^eNnKAbYGgV<3s5fmCgvd@@*mHt z|3s(H>5WS68ToDR!Kyuc7u3b7Dk|x-7QyB=HXgtwpR-F6K;j+=O|8L|<)tNpg&(+)KWd2lC!A)&#u z4qb(q3jo~yLt{cqi>h9##qXt6pu1_&7FJhx0DJ~~e3p=UXz&V}_-=G{S|MQd`jZv0 zGB^Jf;a{G9I(BF5W&$UpB}M_UCh?Vz2h(-n_o~mIFCJo^b1wxTHhE0QoZ#(LKvUV? z9Y^1*kcPdA@c<9TZ#=|A1o&S89=mweE2e_u)yL*$2vra~s{pGde_J3(#X*Jvj$x9H zTQjI{77+Ri!3ORi&yNo27C6r}|3vaV=rPCzb_g771Wb}T>W*{1GNe3$jjhq_h9wiW z@Tkc~85|er;lmF2+SAhnaxSb1tVGub@n9uJmYxfhC9FDR#y^b$q(~Fg(5;ioi2H%l zLQ5{{%44nHSfP2xgvw)A%F(s*QvH=;=O+-DWsEI&MOSoox&lLrA3T2ia{j&=Kyhd( z1onLuBuSta0i?16YrVRh8lK5X@O5Q zrUwih$bxGWiFE@_Yd|zC)(Vxre*FW_JCW?)0d{lsU}J!L{TM#&KD>Bq9Ua!-3){uX z=?w#bo)I5p?Lbw72HApQ2iTs#&fak; z#1k~|JckcwEqmn66dRJDup;Ii|0|B}2)gW!9yQA*SyIoi5d`NK(Ez&aacs5t8(J46 zBqiB)@6I&}n5FWQ2Rg%#nV^@zc*=AWbWYLeU7qjycDj3*p{u927xUr?4E^l!OvusL zs5I>V%V6;donK_+Wz1m^((OS>VD3Ww(~V z*?7#R?KLzj#KDHVds+R_qUTR(^ggNCROB|Ni=d1;$BFp9P`=ynujyxi$d#+Gr~HakBgd`pEHm1QYG; zi~QfvYDZ`UONO#KBYFj(Qn7$#71farPH#$%mM= zZ$R)NfB#t&eZe!(1;H1PC?f@)H17pIoM(shG@Kgnl*EyP1GCR(1AYI7Z>BS-P!wU@ z%Nztr2-LSu?ggg_Fxx4h=Ku{1uszT>5;}C~!i5Xq=mTF3IH{~{Y(Ul6h{wf@Hg$FV z0bK?REU^5pAh*ZHB3_1Q*|zKYg<=<;GyNEIfzp1EW_`vKgZ2L%XvSb34!6T!_&b#@ z(`L?#SHaF9b%c>elg8NiIJ!RqH!|ln4{mg~w?B2DCf=1p;x`&ULJy)-83*SE1SMeJ z)}stL*Q7 zqru3MrrdKO1zk^J2QPsxKNqAQn3EeYD)>8?jWvR=-lXy_MvZ7%MISiY%%4j*4IT$w z5jt8j0W=2JCJq$v_W#6cvI3zwmO8FO3<(?#;wx~e;6Lc~WaHhzuMGl3?`52O+Q^+@ zgkWM&VO&G^Jq<1KiG>yq`scmZ@s2+09=JaKdlxsOWv$OkFE+_EU*mVxYqi;&ldf0SHq*D z^_~8zKzk`{obJWEfX&MKB)X7E(Cv3)eRT<@mJFPp7KVo3kSHW6#arT=CKV}=l!6KF zNo*`FsIm_4+jp;sIu8!k>(>hWjAWlN*@n+7uyAc`>J9(e+1Px^v$-^q&Noi?O zp`G9=z}mSr-+GqhEB4h}HLj5{4e+p_Irh?sgeT4&Fdcn5{Ejrd4b2%aCOH38qmNOY zgrPC#^!&(n+kY)hMlZgp>aGGvCZv%QA zUd#%lWF*gb0zneXt|SKT8?*l`TBAybUf12ufp^4 z30_Q&i0H#fhV6i!h)j?VC*}3+7PSY=lD2`f?7_9UOjdd+-kI3Iy;NT z$voICYANe1bsg(jAVrTa{-W-|>9WN^nyAwP=mite%`yQc5nv$*2ypO@&MmbWTVK8$ z=jV3@bB;^J8pXVLBa?MB#{kYQc*HOoygMy1K-Si}PK?uN3PbC_xjyX_G(%!tS*+*7 zcijMy44O{#u1IGK6D$BYJJ5Tk%>ExWR=zRz1ffy|PirY6;ZJmdC$>|9`fp;KNKCQXrJg>EVHn%fE|1+laCmq!2S!w z3K=KAzIhKHI$Xw}5Y7(YFA1F?9138xAOnR3JqL#jS{kByOT{5*m1s`a0Td@3D>&uJ zmd0hZ&(#O|CdX`{F%cr^2L8ZoFpq4klyBIfan$gP^H!sB#hyHn#{xP4`v-o%{rvn& zaTl*liO=F3MR;*OPMH(7IZ)bmAkb_&%#2{58AP&N83eD96UG+ z7qJC`0t5G}@zQ~DTr6J49u6{Q5d8}fF#&z(-cfF$k)WINV>?B|#OGjwV%Q=kQTot| z?MvgAlEM;SLEsBcu1j-9TaQtk{kmHGU@1HzJp9P3NM*%ovqaGdvHGIXsz8_~0KP&d z1vC?2O~F_mC|q;P35V2$9m*OH$ECy3(x+Db7l#K}dj*%fH~@u~4^tc8L-nIB`-y@b zVsrW`u`sB4W+27x>-bOj(hkWzH~8FlNAizTh}k0tPQxUiIpznK(Y-UX^T(1vwDJR| zjjNBbCI1tI(~=YtDWK#EG3CPN?U(jT#2GU18ZV4Np#>@#847+gRzaEOuJF+m4sgZ{rz@E`Gx+oUHB8p(gh`9GzB4QQ>|LoKdzIJpXw z4U;G%BLnv)=I>`wad9_CN9@WX1fLiPP`A9C;IR`zUt47*&^+9Ng6HFw5O~)O%}BZZ zDn!){tDt*0ed*RZ7@6QSbIEzjAfkpdMNp@sEgz0${uH+e!vpv}yP>p2Sk_==c!l5? zgD+Mf{6+x9wCDTz_^AEl!3zXRGRb$2U?s!xEh?G|-d2dE9KP3JOC0Ytjg3KdL-o$@ zij|=eMzFJjA*h+7VGxcyUdaZw3V5Quqb#;K8ZpGMh(G{g;UB3U?b64$aLsRkwg)Q` zzLo5&;@U^~YzgDEBqzL~4ZBv$( zmaYeLn5_-Z6@0RcJ?WBQrg`}UpYXS5yp zJ_Zwr9i?7k0e=!{4$$C)iN)z7O9LA-G&tz+y;QIHAUooG+v4P-QRwlb0~0l{P~GoS z<$?w4oi1ES7oL2CmPwoczVkab&P#olc#n(LtVqx#X$aHaZi*T7cjkc zt=wbIk_3hh{DUR+S07|VtfWrDk?){QD<7UwVU>Qdgs=?_e%7HzejG(p$=?}Kp) zeSq1!3=I$56+LTrx6*_yx}~5BAqE<|BW52c3sUzg&%r~@Ho9vF`i(;K`cS!z)u$d4 zBO|pACuU#%guHDINEUQA^P#(-7r`A4Zr592{zlMcIhD_^o_YDi z$W#D3fE)C)A!vPv4`~CoPDHqEnNpIH$yUeaq>wE1CAqD%AF@f;Ky@ni_k2bTuWuSk zO}^+(bVkSyW0CGH4mI6?E~KgeHN#wa&i*(DGXd&rcvPT5&>UAy(|2kE?$MW?3V2Ga zH1sqxorG#A4nmJoAJ=nj&;CR+bCB)#P0}+p9Y9C5pZow!JLu$iqcVhwAfqF%WC7pT z2bab%4SR4CPAQU7fZbtE(3V|r{wdVqD7iPTBi6>54*feUc0lsf)IL>IoV5N_DTaKl zya043y)IsSta}InXRtYIIPz1htgP0Js{Gb+Ve}fUU}Qpg`19vaf|0jg;lP2n$kyo_ z806|k$|Jm?Tp}cU(4=7I;82E$L3xcDd`l-}WO@WHfH={YoG5n_ilz22;S8KJ9RP)sf!Ut z2=p$EqjS|&Rp4<&6`TrJX|)N>*b1wW+>?JY6@|!zb^$jbfVAGg;w#+Hn$WLslT-%o zEZ|Y-m;BqPcT={iA1z^a1mcOiI4L?~D@R5Cr_+?l>I+6R61SJ%?@ExB;SBMp*e>5F zlPo@`#Y>Qr(2=4~aEZV+#VA!J4#EoxpNb^_PM@O=eM zGTKNl?`P18NwPDdF~<&3Fu*%F=;H}anL&9cYZ zC%RCrcOn~uxZ9}hGP&b;8!uRky`AXLL%8|m-gJNjfD zUJXFK@NL1@6WG3~>H~w*GCD`N!6^uC()GctsTy_kjF_LDFb4lv70y`XQ!WnK-;&*c z#7aH9UR70QYQLkSJ0B`LCK7@+mNs(Pl6oh_E|9LHpu6a(yqW>OTj%%UlL)FYXJON==P~XD~Gi zg6Br{;fR)Ptlz{br#;ci?-EPFt)Fa`fj~YMvH*O1_vM4ZMTI9OTvbqq4lSU_d)uSp zM>OZCplHnkx7+7qMVbs)j>qJGcb}9qX&hBwbhR3Z@z$))eY!~M~R?`KF-5&bUfDK z@_#98>Y;~;y-tZh5N-r=aN&u-mJ{iGFdHJ$`NEi8-yW{Wlfp&}e-&t|0ry5@HROQ7 ziv&fW*7xbJ@{6_#=G#D~M*i4ckYgZI@w&tZ%MAlo*O*XOO}~WB6@?bPxv~GGQbjUqXI}xBUzcq9e0> z4HfXE1tbr>QAxwASKT-Gp#kZy8HiWgK zYy`Qp{Ebh7_zPjHeE^*8^R>7!_09DDO#jUK)Jpvaj*z-5iAc@|VpY1lx@U`vRwd#{ z20WRs2-HGgh23s~lrISgPEiyhB{(lokqI5g|A4Zl+Ofkj*P&T)?K_oeJF+bBO`PD- zgCnn@NC{Pps3<+eZE)~#YQ1Tj&11wUr(xP2g@jDwr*IVI{hJWE9H6I!_Faj~xS6^6 z>tgEsf4}zyY9BZiNszsK$sBZJqT`^11VK*Gka7MeY+ltPJSSpVaG-R!XFjt`0hah z0z)187O};q`i?oIQQ>8hQf|46yrZ~Ho9}z}d{n5p?Qx*jBQXaGB@|!$kWUO0fqSE# z)Cp-E?ulnFUid)RhOY&=lGNy{C^t-?3koYyJr$5|ERJwCmUrx2Ui0eUE%#I&`6hBKyv%Vn=yK zkdnJDzvz$lN(eq*}mXcKLEkse)XA^8CUAlflUglkXk@43Q;dy56e6y%OtVS7IqC4 zyV`G8`6dOy+d#$;Ie8QrKqn;-T+{{6?9R#G&;Y5gD0=ONj4Zb;n8m?ajJhV$^7uan zL$JAjdKwf6YVq1Ph(S3GHxcF$aVnC_NQ-tLV>Rvp6#_#eqfX=9e+kp#l;0e&<;p&1L4LMOUJ9=2N-?_0&Q4O5P3ra zI!a#U1Tl-@$QUgzE`sk1Jd zK1_s%#|(t^Fn@Sv&z*2q%{wi^c~?OLm$QfG%`G?L-~ zL(9G>M==4LCfDf6BjSjaY-ngmyb#5}%#555p~s8zQMS<&LY78>3LI_s>9|0}qYi;w zTZFW3{vX0J_ZH79%M1R~*wOtTlFL6By_U*?c@JJiecL;xLGua#|htnO;M?pHnf zW^ik9r^53lNkO3m(|BzN_d%NvwhW}}XA~9xO!vK*3{-L*Ti>Q2n__p;=5l*lDB7ns z`6OE#8YU11!cf`kDA~#zPysMX1$Nz7j!Ml~s=JT5N8~2JbHWM$ z^(*3KapYdUe~+6C3@{wK#Scy1_OrR4ZXSj9#K7bvLfCJ}+TlIblWYKokv9iz+04R% z7p@JP15&{&78W&bXB5x?;;YHb#wH064N|*DuGE747fndnMmyEF$I@x#AQHv_nq{;# z`8{+C5W}51#Edc$rrUYCp%=_Eki?EdPABNPN?pc*kcP7lm z3xIOuRJ!;i4|5P5xIB07hTji;_|`Y)SqcO-%CKnQM`s)PNnOlH_I>c69&*_|8FxPt z!ga`DAen*8E8@F8axyX?6nVWj)^6aPT;xFyiUNTrgo+V+A#3Xfl_m_B5e|&lXK``g z;rrm)Vh-OHLH~)04MsW)@@r!muU|t&q#XMm9u;(Kq$MP>@WMNay@SV+&=`ofLrx7+ zCF7{zFxnadBIeQxpaUG#B^-}{2K+!ludAzzxFDg~8-rpto>An$0V^aGn)ZDCk`cfU zU!+wCVXQMOu#?jaUTRbC9Gi|GLR78X@Jpj*y^5hKjHEltQ%kp&*PM63Vo9Ca&wzl{ z4xtv=oxR775qhz>m1Y366pc~UM-+*O{by$?5)x%79fn~Q*y5!hAt${X1tc8YP0h`( z5)weR+=5vi#tMqS$(MoBHq=S1!FY>oG0NL`lqAGX18F~gm}5Y&zL5Srij~#c3fOEw z^yj6$RVwgdC%e*n5%D4z6gDoq5TAGn7o;GP!=R2v%#TaU-k6F(CcT$wXFhhDA-KGU zr>9@U#_nNdb%&*f_g)~#GXXOxVS$qj2^c{EfoLo@>}h}+FkD%f7)L^z3&s#-%`zy9 zAStANgDm#U=xHjJ0EGm2dsmSd*-LMaOfjS_Fd{t&Wb!U!M34bPV#Chbda-X~{RUKE z@TD&9mS^DYy$zI|6JZj&N*c$c4l!fDXAq(mAo z5KMFfb~Z+ctgWuXFBtssgK^Iu=p%fl>qeYxv!reE!)x8 zSy_(AUNuQPA^r*ubSpb@ZKxNbhV+EL%8iaa#cvgffF6FhD~2J)m*mWQZ6Wu^YinANvNV?FEV}5F2)=uVk82SJA|)r zimDV$oEy|VMu0U1 z-v02p-1FPA&i6Q#oTtID--9IxMk`YRkFbN9Y7n`2JIcJS0{uTv}LE>|)TV zr@nHj62i&z%v`)HvdOGtP$M7Yc=(zHVscxz?m>$o@|g`uVPhP4;M*w)DT6NOUZq99 zG0z}Gfbk!CARz)wz)TkA$6hlh^Dd9m|9Mb@jzktT4Z_7nX{8yOwir1#j2sHpg3m$B zrmGuy=T0S3YyUDIXA}s}RvbOJfXb}G$|GL}M`3<$?n((y)mGSCF?1kMdSbC2T6#jCb8woBi-#};O9u5wW4t^n;r387tAuQAV{iA*tHY!G~xUeur#sdJY zTC4{Nzl^!P6K?PWuU(tQmoS8rcw|VTjw3;?54t9_Bz}io2N$c1>qMBJ-&Wjh2X^X2 zE=&l-x4=qIwTq7fxi_G}aK%EHwWNA@bl}dtq_1D>I8cS$7Pe!86qf7o2eTP8eIrW* zu@dYb!ZTsNfr=y?VB!rB5@{wC7P`YmqId-mM&QGT zzxvAM@GP;|beg=<(l_B*!Gp-l$&rGxdPD>Zz9U%pHBr!O?(5sY5CcSlodnl zqtpVKcX*x<96SO5Dzuj+dCO9;0=7c;PLH2aSq<_yQjYy3By@BkAj!u-D_xF0Y%TtEh3JQ(*z*R#kl=w_cDF5x#U?x^CR0;s0 zi!zdiT1-eC><%Gi5_!-pTbG}a0P}IQh(R+NB|}^vjO_al960N_jWfi`#zyZ5GMYKy zmqyTvl7v4T9Hm5}z&X}h{pr&*G@1{Ki))`<_=W@?V>_tYAuQ4Wd2Wq1=-g-;(HZ#4 zn}SFmW)9SEQ3t__j+S+7W{8MEjIanas(^YSR&T1w&B;OR1Uw%QGR}zGFd5L{-HQkf z&@mLsQ4#Gcbh?7#Y{%jq33OZV{{rcM+Khsgs_LVsPoH{DsF%ZIB@SdhJ~HCq0x>os zSO}#2Fun(`0cBKdA5u&c`ANit?(U0N3v`eh!BGd&Mqp1a#7L;0;kwg{d98vsV_UlW zJ7U47p`pMBMPp}UMd8{7)~#m9y`r+BtalaJew;!;pM>GwK2Q-R17(-TUcpUY@7q}83aLXF{iLlslZFU22sLq1)a#)Y zsBz|+y1u?AIG!;*09Z1;-};4V9>;!d%8z5UiA;0FEddwL=0u2^IA6avwMo zcJB(XN{k8}2QcfzJ0XWbf+_>}ON;NmbHj5c2P0Po-xYh}-|?}Dm>6w-j?f-dHG-E% zD-9>Oi@a4fHPx^nhlh`J6PjuOEdoP%uIn4Br@ZH%q3_=sij0T6B+{|#m4rM{4uJeO z<{M0wgxIdUd=)Gl);&IqM&T#-{)S8%2wh<~a5j-}NM2Xi%KMWV3q1=!L|7WM+oO)` z?8H2(r?3AAAst*ppb7_~ubcP$Cx=J@b-Pmuuy20BZqVjwk?{QkWc4p4YS{bOSv zzaQw|OB_{zi2*{XDfbCpjo_5QIHi}@8Y%fU__-L#KmZ*wQ*J)?1&l7?w5Mk0oaPDS zDnfQjdc^4obFzOSd z$s@(zfFOX7AW)UiC9n*H_JNME*P9;#Ojc%QM}5{;ak7!S!@-18se=s+;0+Ohy7z~4 zkl_)QVbm~+FsXf&48N3@YJMA}OkY%z*d`@Kk^6es;Og}$JjPDXt#~FM|LBV%^9*bUd zjSZP#|1`RcNh4AyNucgJ1K`kk6_xNJ@oe31$VxeFZBl?@q}=lyNLM19hn{U{@o^jU zq$Olw<2Q1o4q=aBl~OoPtR{=TYjOEIzGLr!1K5bt;a{zpjx_T!g*U8ld2pU@aXn0X zJW3EVd=r2^#S6k`%;NZewyD1O%W@vJxvR%5GWo=ut>(r_@fE zH`dpG0qO8uAv{6k(d2IaIph~Dj+e==G_2)jco3OdykE!lFo8a@E7d56vxoucMSMpn zcD#N24qK+QRE9~%=pNq7+`?jMaWMuu7{JrPD44wC)UbmKD2}uZWj{6zQS_GymnlSQ z1)F_XPYuo}icT;fL`D*cy41Aq(ZF@q*44cLG7{UCqwLiCM=yu$e7%~2B><+VFr!74 z0F`C)Y?1^8^rl8vwY7!T-01erWmeFG)!fX|{!fQ zX)~>_UiE^L*4bIjqeb^Yv0Aqaxuz#Nnwpw80VC_~ZKEYKv9hY${;LvC?C9o(La^j* zEM}00JO5HlzyUfmw}fp0XG62qfRTmeT2B_~Z5+aZ-|zO06&vzoVvb?K!7bweG~8^{ zr*Cu}pFUkfJ_>tCAVbyb*W@HdeGez+)Wn1o-XEDL!R)$D1igqQ*8$YSt)53l5{`?W zT^E`Q6@;+|p-zNaE_ME1_;Wx@LB|r}^@KD>N`{OW2+pxNk zdzqY`{uGrS_G$DQPBGNyLC=oQKd|6W<~hhG8sXfBh_eOE1!58;oY#c}1sgF>zxq)4#90S{$MN;o4QG5*G;$F( z0uuFfQXuahyq~8}clBzGNfExr|Au_|-`Cy$AHO;kl*Rx$YOZ6}^u1d2vm)^A>?2 + + + + + + + + + + + + #A4# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + ## + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + ## + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + ## + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + ## + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #MDA# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #MTA# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #MSA# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + ## + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + ## + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + ## + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + ## + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #MDA# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #MTA# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #MSA# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #MTA# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #E-Mail server 1# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #E-Mail server 2, +relay only# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #E-Mail server 3# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + ## + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #IMAP4# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + ## + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #POP3# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #MUA# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + ## + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #MUA# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #Absender# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #Empfänger# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #über TorBirdy anonymisiert und +TLS verschlüsselt# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #GPG verschlüsselte E-Mail# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #entschlüsselte E-Mail# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #eventuell TLS/STARTSSL verschlüsselt, +nicht anonymisiert# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + ## + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/Bachelorthesis/Content/Problematik/BetrachtungDatenschutz/Bewertung.png b/Bachelorthesis/Content/Problematik/BetrachtungDatenschutz/Bewertung.png new file mode 100644 index 0000000000000000000000000000000000000000..2a7b61bfbe2b0441d0b945c7a379c5e6ee5460ca GIT binary patch literal 32473 zcmb@u1yogS*EYJ55JePFKvY0cP+9@$FbJgu=~C(1bf*eRBT^zI0@5J4flVmgDP2lP zclSRRzTbb&H^z6y8RMMa@xIS9T+iBT-7)7iuX)XRFJF0C3F5O?&Z1B#;-^nU6;P;C z&L|Y_Z^Bb>h3S!a6Z{L;=F!vVgoK1cf8>6{U(Z-RQL{mzPIn;x$0_ljjz^)cqn?UB zeC`;tFyi3)TYNJJGSR+DlO`hHK8kTe-ne(KhXe(rj%4 z)58WF(XBAL=YAbn7)=$e6%oqQx`q{H)T(#3r!C5=8{ zwjX0O&@Z*nm>PR&Gp$#%O+9|H`wpf2DzTT5-<<9LmZM7}!0>f5Wl5zVd%n2C%I@-+ z&_)yq%Cu}CNV2y3cUP+%?m4Nv-qgz@ryj`jwvnB7d_z8M=zVFN0(EM_ZJ{JedJ7kK z;6s%j2WqF8Bh+kPgr{>}IJ~^YOr`bm>=l|s4V3(kRo?9VM!jtb8*`O{pn!6b=jU+m zuKFM|(&eB+p{9H^P^hq*XdIM$P%%F00Utd4|MbO@JLN<+XWS$?+R|v)}V%?3_Q0 z$*^-ZvlNT`q`DXOGn2_aJTSU}Ca&4i7`4KiuoX2LYAGEqiW+$otd%xlYR|8Kn53>W zZ!5TH^1)o?U3Z^-tSUBd-y5r5i%!@Vk-xT`m_akVU^L`$Ta@?9c`MUPH1#i+qWK6s z%~|+}FR)`$ODtncZ4cc1hF;ino>}fD8FRw~@tO3cgc!EHwtO^v_7u&fRqpi<-F}xV9-88-?dOUsV>XF@MmSZDptOWb@I$U0pMMR&61dtW!f1{L6Wu zE;`Gx@@qG%iQPi)phAQWAxufb{4DD@+L+v4LKV6G#Fw{C}(m7}m>Irpcgb=F<>7~3&_hwSJ!y7d(e zTlL$EQt1Ns{DqG_)1@{;tvOcQV`O7WjsGgPtJ_VvGYeDOZX`Yy$sS#G%>3m-!!y0( z(tE(OkggHzy?dyLa?ht7skps7tMLA>^eev)gw4mNcdAm9n4Z!fpDhxo`}_A({I&$M zxtxDttd_0jOfGZqLaBn)LhsFB(iszf+0darouG;3ZevUl^j0N}HnEDdYx;v{ysa>VtM8%4=$X@B&og)0_Fxc~)^3^!d~AqV%8ZQksWu@aHzkC30vs8mlWjC z_=oKY>JgEZ>GkYWEvs1>Tj*>&%faaGPaAp3JhU~&9eW#351CP@fOn00xU2UcoeI9T z>|$w?sI`qT*eE{3ZhBn@$BRoGL+_m+%WmzV|0Y2aA03wK$5(;5yOu zgS%0h<3^tf-Ny!EOx;moTmk6EZwKa2Cw`6M=i6EhB{Pj5c@5zmam)E}wkK6Bl{hxnrw`=TVNn|3SwiU6{Kz-Twrb6Qvrc z1ikKWG8rm4z3G_7(Az3m>Pi`-C?3G7gvlSTafv9|ex+lAMUEWjd$R(s^7N)Z{y{!Y z@nB~5&YI&3p@Tbl%9CqT%?=}WeRY9XAM;qX#|li(Gx_@Z=H})y`Mthc!|K`5t*ZCp zg^(tt8nc4pt<8ho4w>Pqsz)LW)$q2>$xylU)YE7Z3`#Pajjmpl+sk^~?@77yrh1Xt ztW2{%CHv7z^@a5L*NX6{kIa&joFPj$;)*xt`*L(D-QC?Q>LWJidTydO9}SREh{Q6PLM*w3(FfO>fr18+idp&o#|UGe*)Qf;lpk@krIp0xVX^*$E?!fOpTISpDG zT3dUt6h`lg@8iw)WfYC&GZ?yRbsERMtZu!%c2xatEC;{TWoy9jw)7|YO83KLsYnWP z@>#9(TtD>kZhUGrz)}v{n{q_CE)L9=4n`Q_p@pCAxT$)5$kxL4=I9)EBs@Oc-;U=r zY-@?)q;>p_!?TDnANt#xJ9M6!-$conj2Y%@!sNV>(z%m#k3l@w5-f}4 z?KdqdbkDxGJGMH-@`Y2S?Yyz1Nqaie?-aeXVH+{JfSe(=SP6mmRIBMf>^<2>VgI}Wz8+@N|ZE1Fg< zHDhsabAA~XAy2;ZLy_MROf@o_*@lIWMj33w1gIl3|c=g4q+%m$~_i@*5{+H+&9@-P59z_hg7Zf`7%@0qs_T1HCb{$ z6JK>uUB~A8m8Hp7XKvap4HgkBw{xuLc!&kQ8n7Chy-8r?vV>hZsw-$#) zb|)`ly%P}3%iYvkBcUKUunl{ZEdv^obNZ|rX(jHah}g|a&n61v1kx*mR840 zu;itrr#sx6)e`facH|Gv(6n;)`yhAd((SvSh1D4eRt$`>H+7qLC`6yNSr~3rF58X8 z`n?P;=hH$LJSCbLPma{iJB;iAp8=zASRA}hSJk-a`B8_h{PzVeszEwIcpPQ0@ZOB? z#oH8Ynlo;_O9S~5qFvqH?J<11Zl-P_pFe+&ic0&Y?dT0LM0a+yd_Rm)kx40ivRfT| zkR+s~rKO;NYhGjCKi{yuwDcR{&xgaOJaa7{DXP+;|3qaR?~uDOu4q9tvP=&<(oFX6 zz8PX4NNiouRXKglaf}t^#Xqj>A!|W9!}XSWqW=2p$-iVuC{GehLYvH<^KP*+mOES7 z%51_mG3Y+;V(+XDxh(C|Nk2nIuKh zn@sA|fc4;mvL~X;7G$&TC6SJG=f6BLGs~1aepp*uJN5T(ddBH&63mUdgUT{K-#!^Z zjeXm(AIl2nSi4g4;6fZr{blXhj)W&kQS@lj-b_Zi)z#IfPoMT;dMT%xBiXe|3w)ku zs;=g@3wLMDkOeeOu1t4xp5v0!G{r)LH}klEqy^Hs{n~Jqm%)72C{uMmQj?5qGwVZFkCqQW?B24jO-f4o+Zye$(J4VK zU@t8#{apQ)87Zc2YSjrdUOUsV&^)1DyBO6tYF5>1YQ@Vrplfbm*dBr}I{BgDM!9K6 z=k7WOI>zTodz{8lfw9eUc^vI&y%d1eiwx4AL_8|CYJcL7_dY0d8c&nstj<= zL)$r*ZY{!OHHK?B9qW*-n)_%|84w}K`Qq!#_a!+vlhq5$%?D#vbKXPN6ULOp7en|1!U}z3;ZSAsfpNJ7uhNb@)0O=epkHbo1|@ zbaXl86hi20ia!&)h+aeP)$-}a`}0q`zj2s^jVAw)fb`bu-Q)L@fjl*OAMuH9@vASJ z{Jsf%@sZ~M%iGgZ?iCyJw=rYc4)<56A%Ncaoftg%o;K-~SQMY)vchjlxHEu_bG`j- zp+!0URP($R@d3~Y&(6TBw<*~gbdKocM6w(hS194P?~3d)ShQL0-OGFNdW9vpLk#Y- zBEQt|<)MNmi*DVM>UYj6Z&5&JUT7|t-E`TO94X~^`DQfv`dt|0<>w~p(ouAD92Rjk zb#q$8ryj$v9}-hDspK?G1UHv&&uN`KB@Wj}-L|4!cav{1G%XA`N1kFup2y3_$6@x# zr(t7OA=z)V=K&G&z&7TbhS~0}(n7)GveD!RH<4@2Ih9SrC1m9EM3j2%SL@ z!02#KOTJ7vca?!>EYsnB$9b3xL7rv8LjR4PjAN%WBvs;JqxeRD=Xx@53C?w-V*o8L zP;rO?9sF_C*w|yVZM=N@maz7+$(OVh-yz^%5W~bXMtd{WLPJA2-47hI`0-G|;sGC; zBd7knPuAcmmwMe>bsNn(E=Gah`#7TEIw@(?-Is5CJ`|(gOhj8uE_+0B=<6+M!hNUy zP+*cpo$-6C`9dDjO^IeB_e>4mclv`*8ls{Tj^x$^X8}!Ytmv9W>BPV)@9Nf_D{saj z`TI>KG*Kei$%aZ;b6MewcyS>5{zjOOk6`s>O3UxY-QQrO^IBp%ye`THZI?oymfBrh zlzn){LnTMM2a88bf?4`d?5Vg6ykdX3GRJ}ZrH{Wy)n%)B9ABdTIiNRb3ds;`GOr0S zi5#=!=B}+&SLO6x0E6zt;^lm5F~}diZ*-HBlar5+Pi<1+#bM0FG$u0UwePJ}7wH7V zTIhf@Qne+JqppiIf0Lw^bW!g@L$p+Vr;j>}*&WidGzqcKkEHxG9 zGKpQ@V8i#j7iGr&Y;w6R!qD&BIeS)A)xbBIJhP~px~79&FpEte4VPTHU_K4^h+_ON zvGaZU9oO$g>mN9#smQ_eY5GP^d7dA2*VtN)Bp}vXP%W2wC=ZrIVpbp2_$%!dN8`aR z*~LVM`-Eq~0p6H5kTkZ2kCsnmW8vLD9}QRGhBi*t2R}EHWhY=cb7PVA_(M)*#H3!- zeW_&y644l@b*X*f9*DJJ^2Eu6&3lbA~!i1Jd$x362u=(dR-`xe8#tO;e;E5)X& z;rj!|Un!Z&cE0KvHs1_xczXe0!nW$Cvs-_wy-CmL1Xo(L%@?khi>=uj!5W>GNmmK; zD3}iBb=KNFBpd6QA40rZdq z^hkbca=7sr%ck*4cBOz&{qX%66u0CZ=0L ztfv432p#}DZixp+1e}{4R&(C^g}rnc7oK-ze^o-QL}7e<@^E{T4gVd&NFvtO^;cei zM|9mvQq@|lKam>)gGC~iD?-nbPqy;FYw8dHC&;bq_n-1hmIB8`gCx(47i~S^63w`cn`Lb(x)ZX z*1tWIl4i7s0|GfiaemOMWH)?&Nk^xc^09Cw0M_55Y%e`VkP$P&@Rnd!%kQ>kv>u)` z1FmPg`@RgiT&cxiAosC)0bv18J+JM-tD=HjjV0TJMLAZHyo$Soi9Hvu{jo9NK;cPP z<-+8=z1PP5ujplY`|aF&krX~@#SNP8N^6xj*ut>o+iSen&z!kpJJV{^-c?tWJVG{f zEC1>*{>8Du(W1vGLcHd)CagnBg6FYPh^Fjnc~r(_c1KNZt?_nO;(Km46EY0?ia^n7 zf3U6zfA)BPzV6-qL#OHskWK%78*-DLS*p~wlf{&E!9dNtKI~Pfc2TuN7Fn~Kh`U)S zo_HD$=+>T?ieqhlyN_MT`p52RN>cgga@rBU`H+n6A6xDm1GBU0+3(6^4L_QzY^>#n z-3fq&WOj1maQyDmz?@?gRajxoUtxPcZN7pQYj^1XAmz4HH7NqaDh4eds^2H8aZ=rT zw5%|^#;_t-WOd)nPUJ4V>BtKZwgvYmE*Ot$X6r=CL?^kq1PW}gm1?An^#+AD2Ax*J z733Unqmpfxwy(9S!%m+3;BGV+cVl~`VSJCUX)X4bRZrd4a|W!ptjFZH$1)L?6yeOs z@ZN?qPtB$zE70>f%6|;q%qB?i)y1HG%Zk4XpkbxsFr`oWZI2TwoXfJB zsLMBK?MmlC-7p#EEwOyKRHo>>-HW~CmG}L#bX!Bi9i57@cho`D0$YJRqaEKLqZ0I+ zDP}t!N``+Na}OmT1{X+R$rQ&>oH=vG<9L4zclHJ+=X&Gq_)8&CoQ8gczC>Zt`1r8n z00H(aYW@$rUk-~)NQ`+LAHLqOTpH#heJU+o=Df)SH>%qFZK!Zl$cYP}&2eBPbcE;e+xgzW8hpub36JS{ zRN@>TEtN<>Orh}6xbQ^t3*O$e$W%tot$WW5+L5^tjrVerQQmoGZLPOsNg6`MnPjaG z@Lx<=t(aW!F)C^RB&GQwNW&mmGW^>T6%rBx!dZ9jU6f?`L0*h7tNCDqO*?>A)sxHG z4$(0&uCraq5BB&RmNa|Pm9!4I=;^0GB6+=W;m3FTo=}^P&n0 zUGIpmUW?QzwQaN(%3h6-wy;KA|>}i2jqSG5vr?vLgET&mY75ht|EFjbg>#U@l^>My0 zS&9+>XxW5B{AdePIW;|f5yPKPJw0%qC#yM&sMf&Da9c6uu%FHL+RZ_>TKYuFc^fs=c`_RRBCo5jy%D{p+jMik0R!9Ju(G5qT{t7Bvt zPPgT1sMrjSuJm^qe|6ExlB-26$;2`NMQY_~{{GTA^396a@LWq}*@kfh?+5gVG=s}P zID-YhC)4VPx-Dc)fd>*~H(QGw%29J(6-R z4WPP72LbmM17sLg)Bt{xsrPhm326bW)zkK2FNL8HWpifiIAW@qo?H2EJ96zDTqB#_ zv!mjA(qa&G_u*V`5BAExtA@QSe3lQca38Gqvy$K;znz+S7R9e5%@8G`^Xe72J3WCF z(HA{P7P7TMQ{p}fEJIWdgAnRThLC*XtGD>n08!u?Btf1Z$Jg`$1x5A#N~ftlTQ-re zg1{>2=X;T!RR&$DwYQB7M-ch(%V}A)V)?I$`ae(o`4&$o48rpcGt49h!2bze8=y>_~NN$-4HS@O$pNdCT zbTZZ<$xN+014r~$%XpF5K;A>bL4{<=v{5|I2Y}#IRMy9bYcq*W7=4Z?(Hb*u0WBkI zdj|tk-Oxro%-5H@8~0+}Q%Ux|`*|r1i;IcbE%ZNwr#tT07gZGHnN$7VUaJetGYJo4 zV_mLXcA))yrdDq=_?^pLO{?@vo-guUsfVoj&u%<+uQ*4;VvsNW`BtH+X;-qL{iX{Q zcZ7ku+sgHoBVB&?><|0jnP4NsRv5h zC6u(!uBdK}!4`P`8D?8pw43JEpg#rGGQ z1E?VJc!N(ismPM)LAS$IK;BpH5ZKrkY)txAQq@0N+m!Pnp`PB|j+FOt zS2c${x^z~SP~V`bA%u?ZB)Q-3d??R%^r&j#x%N=-#Vy)i7cjLKHhbPz8@AVWR;`c9 zhOORj%qFUZxZkqmuTAd6>?Vv?i%Uuu@y z?GbgB-8C;c{xlk6vy_|h9jdn-arGo?e>M7}m#3;8fnVXCR)I41zg_@8|Ec82q-QtB zi16QdgQVg0-C;BYq9?zd-neMF6wWYW!s(&6r+QQ%MQ9Bz=8g5o8Ac2?J>l`xoYL%o z;u2PFSpg*n26w}FgnxIOh*3or3KZB&KR_Aq?68^ggIu2uVB>jKy2E`>O1Lp$I$UM) z7o%~HB*A%b(H{bEBT2qtaM^a8s8}P=^PdivAK@K82aRU@6&0`iSt9)z`I0FLu)Z>o zB?#$hU9S&enu&P;M}bG~yeY;f;b@BuJ#$f1bks$Tj0~_~1s^;}FW?#@@Uo7_UFF!( zWRx&6n|BtK;lQ5%lk(%Z!V2Au$YkNOYjS_79e0Ax%sEe5KmTMuOL)nO=!a@sT)6w; z0;Oy`n?z893{T_AALn0qc)&?tuuQi#ZjUw3^&D%h#UD3BTS$s}v8Z0}?A%i#z=Na# zZfN)S3AjS9rbb710=&Ds94|ZzOj9h3J&$1_>R$N{*-Rg~dM!4EuXW2QqDSiWLkRy>%3)M?-Rsbp8~o$K-^-4e&u9HrzTgGJ<_Pb-l0ds z1SM(&t zDLfz9&G#<$WJL0?=I7;&dK|mu57_>Bvra%Q(DVkst2j4eicul=RV|cSG)t^&-8l0H zG*e`$x6K29V{vZ}+XVBl2Ga=bt=7|KWY>3k6H#)T^{?zs$1e|ImRJ5%yKlVUhyohu zu-?iuX45X@Fy`j)MqI8MM8i8_@FzUnZnlelyS2r@rurSR*exEO?C%{%DdbEI8WvCE zh3jG;*xODuh2M^Ita6J6Vim({MR#Y)=$lDT`fa&5mOFPW$1;nHd3Pidp=1yW+ONmq zW?!%FG$|=5D6E;!(-feHF#jtp^uq^vScS<+z3$`V$gs%B$k{^77RpM%8M7fLA3o-{T}L9tvC_j2lDe>$x<|Lr-2}19hNCVm{pqk*?6Lo zbVNX)Y>HG-z2T}LFaO)>J$kG{2>$SH`aDrrSBKgSX#ebV45712*k$*fKktVy7Gqz< zh(eb=63Hnkm-}-kK-4-0qvN(1J%HK)h_tV&yv`_ollBb=*uXx?#^S%YUSu_t83jzz zpE9)2@-{Pbh8EU-e|tID-`@oU>TK=uy~FLX3s<=_VFvDcSw5noqEHYs=t_DT&28S) z(gI8O3MzDP?UW#4D+IRJlapbjAsqUX;VODND}H}`9_+y!IY{kIt^benxT763rUrGOx*5WDUL z{{*#BclT?Vb+U9{_S&e6LZbLx6UEz%jA;+w5-bftrGkNpX`{jmvI&P^fel#Fz_)hF zLtrXmN#cQ5J{x8!9qw)F>gw89Tf6U0f%fb9Fq~PXO?L%~!j0D6Xn%@*ZI8pHFTawN zlO@9ki_GUMWbVW<(bF|HHqtnxHtH!@u?8xVGb>*TL8j%fJZdxDCeyWtjt2)Rci9&9 zI4bkmamKx<0ghPM6v@7P&oMJaGMvqg^^Vw24@O2t8V4g-!w%W-ymKZp4BZm6ZW~Yt zOEhecyCAsoL+5y}4`q0MZEX!!DBpfjz1h6#)vH%)>+6ZQyk&^4vBjoSaS(reQ12EE zHn!`0%vij(H=naST(a)ZUZGk7ju_4y?>O#TWIi-%-OLJJDfRSe8f+vaY%>Nwv{Y3c zq43n~{lH~=X{6HQ7^GfS5kDWFneG(1moNXofG$1pMn-RKZ7oR94&^^0>KqKQK6u6f z7}GGOv8n0oAdW0Cl)@c{6Ce*eqj!DgJt&#r^!f${73*yRWA6KlkRukMM*tpro!0-V zUHK&aZD+?(rEi2^`{^|(fAncNj5tllvRCZ9($v(1>hr104*-U}kYNcC$f42b*3b9f zD#}@Mnf9`MuYr;yt~}oz1HoMU2_)I)bEa+ zQ4ciWmBd%MU7@Ca`T|X654A1v_+(?KMfqlLvDE~+_zyw3>28i`Up7+Z7)oi>lYD~w zNmb7JTqNXzbZuN+ve6bHbaG`DOyoS zscQKK;^N}aFF|nr8n64oj$}B~tVVEcnbSH4C#R0{Y;sMFXt`-8wD3L10vLBZ7YBMc zkHx4U@8*u-uheJje_NXy8XPx!RKWZWp^O}G`CgTEZHgk4zR!m1VxRz|3UYwJa#_CP z>UhHA_Z1smQcK65`pca1>#3c=(qNPKv=m_XprNhg#m_hQK$ySE%|ggo{t)3!^I$ON zH+3;|AH%}9On#+C>bR?k=H=%@C46<%WmyQI9t!2MPoH*TOFg-usHuTL$GdF}fKM8< ze9DCfhTN1mPb)m!Q?R=THJrVEb8G9h^>&ftts#qGT9Km>hp|{L<1Q%4X{0}AtQ6on zMe_`W(sqKvnz_YAM}TRt05Ax{mES+XL-{EviqBkRP}MQi*O!SCEU{l4g!wf=n?yzu zys56H#;2jgX8PSZsxD~b12^~D&~E}EC5#0&48pA#Tk-KTh)lvezj22~!AmJvRKLU0 z0BFHzD!{-Zrl1x8`)9B7R8}@9`4FB8$lqJxwvW{82Md|+-!B9x1v^B5wY#h9Gnetl zj~}g}S_=`rCrvR0zz}?@v8@f3g;6DY7`igxMIS>$C&tHN@BRJ!pl%JZ8K^{gW#D)g zW^@pS3}&Jl2@Q*tutQLojpMcY%679EVj;X)-D9Xen0C24r5ylK2V&XM2-eiaSJo0J z`>#^>!_xZSuo9oA26&;uJJXjFFGo7l9eim-I`PYw7Xx|vv=Ch&${HU2lGTV{)7ndT zPeT^MT4}DfzWEuuR4OG3e$Ef2j>^MD3n)1s1GS(4KmA8kpiMzQDuP9=%+cy!3q-Ch z#Ad08jrl%{waG@9v=;Q^aJCDscS*6IkcvEgXnb+|<4qaCu2bQ$!gP;le%yRyw* z4W#AcX0YHZwNG(zOIGg<3=GtdKJq%Qd>Jr94;7h%P~)+`h=DpUkNF@MAK&iI>O^0* zR>reLanM>}6a4)AV57b!CPMEKI&dpe+u6ABBYhEe0a~SmoHvRWix7p#z$HZP3Gk3q z{e65BW)6-#iC`MKyzP}yd=DMVdefHI!|wD@}Jg-XX@bebG=!nCCeVbET94f zn8HdY^O{F99l9ZOtRL)X&buIIOUW;3|ZmIr#!OGK( zIcEt3&UtrDzggPM*?A9a5DZRq65IxuKzm~&X~@EYnM!5uuV23)%&O%m*_Gjh>f3;O zl*dQAY z##ni@$=*BGiJ^1&z$^3)O91pvIA+UaM_H&o-{#YYrVbd-vc3L;6 zrvXwJ&ZGoEb!%~?++kbJqhwZ=)Oe_9(Gv%kg&09n%ij;0=SgphBWSqh3^WCLy$Z_W z{)HCS9PlmxQ?urI;H7Mu#T{$T(8I#4ocUdE5||upmPN@&yQ70$=!=q;l`YB?Fz&h~ z6@x9E{3ad60c`WyeUs;4Qh-^^bV?b@cEbs~ySv~bjm^zi;7R@wtm?mx*CQ05sW|;v z;=3t@KIpvBH#F3coz4bpgtHSQct)0Y3N*{{@)se?p-G5fgzjcU%?zg0*nz}ml{%-x__wL5OGID)Dr_BN) z62T2)%rC->HmQn&iR!x@f~~0Ov`2AHM`)m}Vvc#Dq%Q#Kf>S;=GGYdL(sQ)eSE(MS zZ<+#Y0uFRBq^zuLbz+R`h?OiwE*|YRoHkYZg;K}0lf!?$VKzbDANrXzw1+LLi6w%r zb(YDBNJn$G=CQLdJx{&sy0Zc(p(-A44{kNJk(4>MFVI!JXmj!WK^tEa^c~5Sa3xD3^o-tVZS_D9-&h#2E826 zrc@U|1xzpYL21uPHNg-#v^dDU&|?-1GCXiUm(W6y!;MfM&0@0}LD3t$CFZXopJm3Mo)MEn_n>=7tOmPHmjM0dL~ zU#}j79z%;F04I&GD|C1LghJJ5rv88xgkgwAlmSO;nl6%%vN z#GC^u#W)1}^P3tD$Qgq-KgjMv=#99#A1mT9%3+zy(hj|FuDf|5(*_yO)7F3qK!-gU zB*%bO+nd>>5!8{8CGf2eEU`nPbB@O$bgK@@grHqe2wwDOS%#x$2 z(KZcVc8V7IB?!wU=HhR zYh`5vZ*W@Ugs{LTz?2|y%kn{bQ@2tO3z(gqh13uhCmvo7Y3N(cEI9}w`feY->enk} zYYx~StLqFqP6UE|8XFq}fE_?P?%wutj$&gS=yme1z<7a$UnAuh;IEj;#zfMcX&-)#>3%malT_=#Bb9X7V218m{wrNIl} z@{3wv;Lx=R%OWQuvnlKdoIVtaEr8HK0*XxgWR1O{ple1oPY?Kj6wtgB2i6KI zP6KIh@k4BP`GDCGWZ%k}s-)_QP2iYud^QFd%2@|XH&|I&A%pm&*aU>fy!%_Ahl4ZI zojd(N*&v{BFPAm|U5wjdxmLR`&M96RCzvM(oc$mO)A*Sw1dD76O~0J?OR zL8MetQnIP3>6IF;4+-J@^akLbiIL$-f+Q+R+r9KM)fVVzs+AwXv}QVF|G!&^ShObtUZWi;^Eg zn(+?Q5s3dNi+LFkP5Uup?#y)PH}zK`jJCJ5NJ~m~rQVr>o8~GWx)>j49PGJIZx227 zX$|$*9&rGl$64wSfo9z(!#LRS-gG8``zF6W0p~}y3H0)u$|C^CN`yiJ<*3{lC&ETV z49h%u($LfdEFy0z2}c4P4GAq1!6Kts8ay)S-_kG=Re)fKOIZ%&?{q2heMG%}PesBE zeqr$}YHMoFAp!HpYlHk<08^MzQGhZ+c+aRX&oeQELYCjiv62NsJ!~_yvJZeN(|UpX zB6Q!Jt5sm3V_02$=CBgnsFx1w3PjF%Yr$B}8b%0C$O73tl<-`(78={z<)o!qRI)W) z%bH8v5ILLVT!KI;u`#r##(Ny?!tz%@Lv(YwD3Gqd+rId(k*2xJELP1k+(zK)u;+Q; zXS|%8-S!A%`&VHM0qF2SkeXntur|}OJZj8)t+$Av3*+a{8RawzR`r%>o@Gch z0F4pofixdlHxxkJc(7uc|DqoE!ClMr=ayXPVMoY7MGjUT%gVNW74w(=c6?NI@#00h zGD;rgVL$Y&@3KNfgR~c#%snPUBr=Hv?B?{G))L{^4vLU~A@nW7?c0X^-(N06wGwFL z{??+YR`!H+o+Z+Aa5{15_uc4L@b%+uk7MXdF9HHXK|ujKa-Ws8Rgc4NX;`hkYDa(w z_2zY_ISHae0fYh+!mZTzUU~V5iirtr{!*mtg3&<(?2PJF0UEehG5O7JkP5~?Ul}g3 zF{f1j8@d_$lmh9ZdfTX%%(DG>6v)Dd8;?OqvKyiWdrSpU6P7oOP?{mb28f{sx?~D+ zSawM6;0ZTx-dwyA0BUE^5V|{=o7r9v_9#)qP8mY5#aIOh0a2|6Da6hjGk-q)d{`F+ zrvuJi!z$en5fNcvFo0HbkYxc}^UBk_JMWg_d%k$Vp=JXC6FRK>A+1tWRowv!03l9x z*>CtIvi^6YGD~hs1i3=G1MEvmN~#-6(f&!A0Dfwlkp*N2M2Dpz4ExQSk8=#?cD<-C zpnj6T0ln^H>&=_Ni&}Q$$>2;Flb$(T{?i4;od;1fzE$_bbDK(i@Ux{D{ZJf1E zSsdZo5`Xrr6BuF;r0eyx9!5JQ&!LoY{c@Ef#{gM;k<{?})Qo1kGAme^hK2?tJq?u; z?p#${btkNbHxpc<32od%@D0#@9e@;)blc@otz~Q1>NEvdiW{rVJ42Lkj2NESZFQrQZCK_g#?!74EZGtsu$XG6CN(5VfEqlw>(#24ceDOt;_wAkx7KD@D5zKK85r!T z#ovRYH?T?$5obYu9w^0!qL!5TmD}Qp?d6DsS#2I5FVPtZkUN za{BW$VD7V8J`pGGB#s%~najvIOGJdUoC9|sb6GBTj!dLKvBwlir;Qws!wk@8;0ype z8{2tbiT*vW;uCWlNc?=?6wGxOgaJPv!fLZ|I9r4`sMsVhhQ*GAw-eq%kh4oZeQG>d zFbloV>B?E@Qs(L5GqAxAt7nu&forVKro<1j3R;cVKqEsR$SI0Szz@V{92{T@J%m5)U6fL=Io3vl5=nBLCB4HzN&s`R~q~COUnkpgpkil>&}~ zN(_ za$`_HnA!w-4s5Cr(q8E7FNLT9X@Y`k_Dk6AFPfi5Cg_-$=HQTs<(L70ATYmP43rmS zo;?fM1j{pp*8Y6ZV97ofR(U@_k>LH|idvwZm(J?};{X%5Z`APxNz|eFxAZx=G`+(Z z?t>1mZoNEOkUT1O|6Z-10+)bX*AdcmRNQrtnV#MTap2qLHM1YeDUw z%#U5&fEuD96Y_qxLbTI{Y@|^tW#BH9J`=xASu&6H{^n8s<~f% z4uB^7E2RMPErU)(w&f6Pjhumi`)ysOn#hAwBth{GW7p9Zh5S1*E-o%C>{3`)fd7B) z8A^S2bJ@ZMbQ_{P<>Dnkp6e~L;csZcF6G%;7()M?W(fT^KsXW>x~N|$J2g2uY*kPF zGwt@Re;XNy7ONQjO0bZUF#Q49AO|$0n$|j6&4_HQusXqXM6bYXS;}npzTbgdN6TkBL7>c z&76!7tUYzW%wCg*np#U<{yH7xDWG8rLu+`46erui9dDfU^1@RQ$rE0Il8tY1A^FKP zSz5#~D@Yq>llK5X0hIc#)4{etg6XrFwOI>rQJfq`{crIElq5wtI5H>k)r>o|UgVqEUjxx1m$S9FRZ^S&q z-y!A#K!a(^*@cKBM+U54-i;~)x(9FzWdFYT;IBSA81x}z)0ygpOmuW!$G-{X8xJQ@ zBwPu?r6a{wxLJg%mZAuk<{T$`$fZvM5E>9vy4!Uwc)<_gsW zO)rSE2F;_9LYuXw0}(Qz`WXrc+Q`37My;5PG$C6{GeGeOHFb_R%8YLBt-lL2#ag=u zps6Q1R=tMKsxe=HL)3YHEXDsVU`kVt2p&;M+x_?L*Zeuhs88Qpi)L z$7XujTFjua^Xohz zDMl?&@E?XmpTDm*{x{#tw3z=DG{1&T#5D?^X-+ITS>=nbUCG?lkd?uEy_6#P(BXeD z6|s8sTN^8r9j#LtC#D4kb@E$1juRK0uAk{$rOHL4S0;~2ie%Y!H;*0`1;u(z+2y96 z3~21aZ<}ySdkZ(`?5ya~hUa#l2H-Oi2Leh=9}4n=6x}3cwjDGkAFjTBVGCw#Y@Hq! z&FRJG)W3slqHL&QvSuLTp<_1d8%W{c!aC7wP5tzV&}FWeou0C4GVe~<5XzmI-qu7z zH@EDp{n0Okh(GLFrH9D{huhgjSYJQHdT_A0A|3K~Qku1rx#D;98Td#}W}%h*1Hmm@ zsu2@mGJT_~ATgad5n_ueGdQkBG@u^r*_(qs_K^i2%tb7s zF)neVg%M_+a1{KuX2D_H8uW%SX39Xaocy zr*)4R7-r}jW%pWbhJOZejpP#>({Rld!P=Vl#U*Pr5 zDlb_Q^*3_XOrf+aVMm+nz$(5CGRu4YVe4Ulf{EvhC%(>xcM4e$t7xJV1PE<>F$V7Q zAD05aMvxlNwFdwEBk`#)oAJAdEr|p`zn{H@$o*( zJ;0+TJ{oM{)mrDM%m@S7_my`~aA%_B1aM-y0r7czQWCO?g)4~QNIig$IOg|r1|4po2?_{2Fgn0h}ypt`{FWHX@IxKHhuA&>Jym(G-oZaGfq?%GP3bMD(Hm)>yb^-R zXHErCT-~`eGYAXwo|7D@pR#J6f8ra%61tgn+8J5!EMJaJ>k)Ig*#Xrn^IGRO5ZqQL zPI@Re+t^X$HIc0Vr#s--|0Qxhrv|wJKmF*@(T&7*Ve5luP%!{nnpVLzgPe0{m5${v zgiLFgOpiyYM z6&hvKLCg6ahIjL1$E>WZlP(;imjvee!!S*puLm>KKJ`7d0jHm8#_w zwl+2zLlS4{|0WJuoPKEIh~_dLFFpXh7K$mMKGy{8SH^~p+@S9Rznp6ZVLE}yNlC*{ z!wYH#wa)`8fS*2nD(#sU?o9&${H(iq2cjxn0ewOP8aF1^Qd3hQyBCvyKRRQ%Zi*A{ z7T@Yz-9Qd&)&YN-%9WXJ6OxS+r1E<8f+PkEod1qede|ua^;8(qiHiTg<#?xFf?Ruz=I*@6h4yotl)-JT|^8{KZK;uH{By)W^v{Y1(F%3Wx z2@02?pB;dUU65fx4;Y2q1q6$7V-HB=AUT4Z+yUfnNN1I_Xf}}ZrvxmI zhrk#>Uhdp49G{rDNJd6SM~8f#;Ro)8ROSn%2*BV%ncaM>q8ubgI6s;*&u!c_S$#pI z>~L!+O5waN!hT-wLH^BBZ`67ODPa%PJU5T7$@@Sk!<&O`zIX2)nr3a?ZF`wrsl;~M z&_RV)<);$zMWe~->H3U}i9V)7x)!1_X};m}j;7bX11FOg8s z>8~a#{i+K~apX9H~+D&8dd}Y;PXxh`jeg{K=7F-1V1H)Pni7w^rML4 zz~9UmJY6J=1pNPa&VPG3xl}HEu?2d<|93F@pNAtltA+Bk%!g%z?>)^ywA75VRBLJq znB^SLpV-Wd9gYDrNC>7Q9X2C&+Gj;1A*&Ge29t3bU1T`6J)@0QiJUxiE4k_J* z*^p!GUm6H}yA*w=kXqP;+<0k!RkxcabTr!FB?9MDWx!)iuk70HYN{bj;AyI{IY&x@eUQg!+b`#JTejIU-BGW+9p~B&s ztchF=heO_Ir=r+vTbIq?SXOorh09oQz05wwcSV;YvOoAd>fy6nV$aCP8AH4kQej(& z5y+haM)cqDLG5?BNfQU8Y@s^?xJveH0~Cw!qu)bM!%r@B#uzmlGYo){jvW!l{m`6JdS zswf!&ZsgN27Elw0`Xo&>Dds_g05r}V9qw;tpUPIEAZ28^qsQZ&{PioH#b@}hpFVM$ zt3%X;|0$k19q)epbXomNGNg+_%*@Trbv3Lc42Z6p^z>qRhUZ1&j|_C3 z&pH>r+`ULeHS4Ae1PN8ht915c8UCNA<$2sU>Q*oDZ1I@(cmaJD@5yVt4_7_}JvWvN z|6jFzc{tT=+wQ6-8b}c<5uu4PRYb-VWr`>=ry?Trlp#b#L_$f)>`|sB^DL>5NGPmW zkz|$-5#M?Dyx)G0{k_Mr_p$%j{(7D)YyH+eT=#XI*Lj}z(X^G%8CW9(Or{RAD^D_V zMBAw7u(vR+@S4q#Ix(Jc*^xCsfdfrG1 zt7>aE7iafMdgVNQCWL+D?9i~tCVg2D)C%uZnF~&Gm^^sr`0T(Z+VQmMXvK%s9eX_r zzPG;CSv8)PkZ6lVK~v}XHuGk^YtpZgHNDJ(C$E%vzFY1wc&1}W$ZY16Bxc1?zQ5vr zTIJ`%3BS!m*$T!FVsX-_osU-3Ea*GA&^n4eKa5eg`e}NXPFCAo0st?OUq)gsKV}_%utH`*ZrSEjX^u34}UxOH&6V_?D-ES4<%1rp| zLl**PDjm2PIOe4l7EftllhXCwD;zJ$tTMP zBMSJ&eh0Wa?$WFZGA^*YrFgi&eNid*;akg%esAC}w$C@I-_KwKyO(}?>(z)o-OtM> z%iaituSHpt_^(aa_Rntm&lw;~)Ar$KqueWnQ?P-e6gDr}H=ZizssFaaDCA|fKwZJa z$i~=|gBJqh-@;b2V$(SpzxS>N-mLMwND37Yy?X{$;FTTekDc+~W*(N}<8>fhG+v zyNK0>k$Fd{jH>>@=WmK!i+tcN9{hQ$r&=T1XLq9SoH|>l+36nt<(g`~MW+#CJ^gmG zZqQSxwy6}8M=7qu{PM#Jmh8R4v3*~?5@qqP5;~6l#!YKCG@INlDdPM_TojME-hTVD z_Tm+;4IRHk@RD3zSASW}tDm-d4CpdX*1SOyqb@bjrc&%9)}6T~?6mOciai@&1KRVN ze2_U!<>BF>Qom-D?IYOg>V`c21Dnay}f4)Q^Qm@+(h>?XEgdmeDC_gKkpQC=Z-Y`%erM-goWR9_UcRe zEzBb^l78<3^q(54GUR1)8hKy+Z4TbMvM8#p8m}9(J`{Kg7a$FEn(II+ikqhzgL#GY zJvZl-Jn%k{vaKX;Kh97xFfafFS-RC;<%P9G`S+LHTJFA}&`FAXoi6(GosD$ZE&Jcz zU$SJYPvf%X%VWe&cFAuoQu6Zh0^PE@x|+v>WY6A%PDxNDfVIF@g049O14B_#yzv=P z@xDQxn`#2+)sBHn(RN}vg2W%iD>@*kN@PdBhE??@000DU!G3q_Mvouko4%cT;*#(g z-I;KZ96&JWC=%3pJY&_ww8KclTWDpb2#bK5bXsOo6yZQM8< z?`0w=C+CBgZPhB)($tg#KgwHuLV)}|$m!@k%8nLRJ4tPSqNr#nFKK&HR{dz`FVizU%!5p8U3ol zWb*M&!&hYSw=axNgMBvo@Kp&;_uOPg?Q7}3)HSz_f#5j{d|T$(n=2nyJ7((-fu>}3 zn)bD?uPB{&43Vgb5X4a=-Z%UzASu}@!g1?vvLN94i{vC0RbEF8O?$y~d({rG24Gi$ zS3UpE9|p1oTjRI6csAdmWfZ@&;+#1AKY+dMP(J%|cF1@lj=u6led$b3D5?Ut#dlYR zhlfFZf!^SyO6yG>X{k8fSx3` zL#a-W`n!1ZH+Ob{QsX_6N4Scl<;@n99g_S7iy1)K*GBgpuryd=vgbcO1`X;(O-&f*uH?e~ zVb`w{O6mQ59wnf}uO1Y+g5NUp%FQS)&NiYaebTe<7WibI-!Es^#B{f=EFeS@ zR5pZF?>FDO3GLPI)2G_8cgyD|G*ooZuh9xafs`HtM+ha-PoT&!0y_&wjS|!tS@Q&t3Vvx;nx0YixiB4{FKgSA39g?PcKQ>VaC5t=!KPrEDUIRWhfSkTiS&)j$z zrlX@nTA#iA=CEok*350SxxdFsYyW=#S_|juZud3pg!gyFUhXHTH`C}og2Rjf8EJX= zeq=!|AgpO_AS`imuQ+w#B(j2*xSZAf>q=<)s4wY42+ zg-&2Kq4QIKcK}7CEyq+=QgR9b3F?#^;o%_l@5A{3hyeOA7ZBjlSB0NZQsMh2=-Yw? z{|11`E282CF}|+8ekWG}fK|v(GGto6)$Y?)kosPPfCF1$bamgWEOu$FWM&rTs;;W4 zg7Dyqmwo%wGz=onBk;__J9I%Wf?9(1eF4+ox@!p3xv}CQ@J?t5Tr|apLdK_W78MoY zAp8zQ7u#|ceQ{dz@+oN&7EMarMbKrmrtvEJ&X4&mmb|l;h}G1tn3$Xidbxf3_R!a0 zyS4ss*UxkVo-$aF-)i%zz#*YHTTmV1q2tG+gE^V6;tM{ImEa0H`^-@O0o){8Rd~8}7+yms2xa zy}mW^m&^%c^B(>4V{T5zVj0moaw9nS0>W8>&qOWTiPmufQ)C-t6SW8R{tg_|Cx4@@ zEMk;91HzEE`*26TPUpx_0XOqiU_M}2g{T@Be8eJY5o$ol0Zl=#06g+LsQ15mSXg|) zXS712y7OMcS;^C&lGzxyKERgCXJ7#D^|b6}0|X890W-<5xd8O$d?z${x&qNW zce=^$-t7!92IrCJq|$){2jU?L>yP)&q3=^ACL6*sn+UXo)mjW99A+-h?bsZZM;Unr zRpxGn(>+F$pNuNOj{_6)Ujj7hM;1NjXjrVv}SB>prBhTB>0{6c@Rqj z)sdwk+8_UR5o~56Ibn0?_!dS2(K$Tdr%)Nf>f0TQzzb1FJ2E>&|B;Tg9~=+DkwyTF zGyTNE%)AjRl}W7hD7bhf_y1bDRK1iZqMtTAjbq9TeBO~$j*jC{j>SV0g+r8mM9$*% z+LGnT-cy5?;+%-$2=n)(7Sp{Z%ayT53huLrb25WT+YOVFV_@+a|JrBcg>|2wvYc04CJ#qBmyQO=mi2mpa70U?Sk40n;Stoe-$F$FNa&U4Q^l;T{nFYti z#QcPeE29%Ui+DvpUr@&G=XC6J`XoY;eu_{7jWG0~L3zRi_5gGk?s8aO3Glc zC9{Nsbeb4{Lcg=-u-Cgh$0mf+2yj+F$zmes?eaPPmh6 zB}<|38jw2z8cja;lFDfQW_YH2%;2^Xg}^|x0IdIb-IG$3a+iR)o2a2RXSN4d5jXr_ z_4V~XF45IAG>$oB_HV%&@5$~ci*}gbZyE}wpvf3clcc1iw?7-mf;>yu;qu`pW`4QLRKHYz$!;j zx<9m;Q`Dl+}H!*~G z9no52FB2NGUE9$Dd(%#y*iu+gR^Ea{$6B0o>C&Z)%$$x)V(?@9TZ&g#KPbOoegfyH z=P-XC)cL64mM>cdN#-!sEdK7@!H$D_haUKq18#^k-z`Qn|Q_!9Fj`Y*Gd{9n9-Xe=WDS+K$8#g7q=<3NkZxyhRas z64e8;J6U9ADDsRdOwXYfH9m@n zu~5ha&f&80=S%(JASd0^t;j*biva zCc$xmx<%!gzMPvY>TycxAsd@Pqx>1`3^lUBwU_e^AGG9_6#H zT}!5;K(9{@JC@GC%vcRuqg`MxMs3&ToqLZs230c74ZBYu&LHu2&3Z<1s!H2sjEtZ- z;h4E9kSwTz9sgy*<@6)cDsH%%Ib;yBkWKL3K~jb9qK5|GY1dP zZ>;kNA~^K9Kyh{iON|oq5vwkMfk|`Qdt|Z)4j!}{K~!J8W(`?V;d%Q&GoX~dM1&)G zXiSV0QcDEj^*$LeYehx*x0h=BU!K;66bic}IA1^*P;C;~pGpFcqHpP(hBHihDB~>H zIHp+Z5DgF;=0=nH=S%(!9NtR`0=Ykri;iKk$G$W$nkaJjlLa9^F1+ylG?@69(=3mD z1*HFTL8f!5E>UT6GJD0i?8MshKfJTh|2PP+lcN1ptQkt9p6e1JF*L_0awpy~q?W=^ zgff1#Mue}AoX`H-oge#06Hty4|N8qf*#=LZYpjoW8j8T~&-O7~e7#iet$Q~P ztiP^i9J&Q(^7qkwF0VgSeG%eLF#P9D9YcqC zjmz^)XPfbKyYyC3#@9=Vjr{%9&Wz`a{|ym57~1!hCs$e8II-H^#610HPCtqp*K}d1d5m&ggR#u^Y!g$7|rhXGC1gZz!y7(+Pu-aW&UW^*_T;$$oIqxD_Sl(!c(yS@W-_kFGqw7ahpxX+0*Y zuhCRPwPx3ZFF(EeA(9tzh z2HOT3PZ`SCRMZqu27wt{1r9xWsy)AoFA zUEq@c$!xP4t+L6s>nE8E`1|2=aj4%QjT+1kEVM&5h~0+5slV=*94C28eH3YkmtPAT zA=kKb^CrJQNHRol$<{%rGv6Y6MHas;N-b)KJlRT3FQB19_OU7-B|IPzXwq=C!J$VP zq!Uh&Z~_On(;b-MHtqP0>(`%na$1E)qnY@FJGK#5-;L7r!ba?70Hr(pUS_|u2Gok% zY@XS+X7q)#$rEm*qdsPaKs1FnMrb3*ihxQjFfdV(`O`#NJteT76R$0YTMWtoFpjjV zL~uva-SN)%xqlXxv@MD^fF61u!VV~rkY|YU)p>y?vZ}`%3<#3LP?|Q9J@dAs%-h4u ztGHJIg*fKRNn75Gbh@N7p$A5saiaBO#f=KRB(NF93W+-e@~@l{P*RHPWe5T*p(KL4 zgI}2zId9#!uiYsDp^IVJTG1=t#g^iGpg;s~SU0x}$v4ml0Z^=6juh!jCFgW%{BZsA zY>=xVIoR1^{lox*SdikA1?%3q9QKo$ITodK#8s#bcGAfAz)`iDO3O( z^k=iqs@0mNHa{Hyycd)hq}pnEAgE4KsBB}aCkAyfYgksSXi3|<1_T32oFtT6Y;(B| z-EL4++6%rcapYh7uQ5TUcOH1Ly;gKkof0Lqz3ZL|IQl|EwFsvFDMX*KAI1GI(Med1N&^e zAJ}s;Gftg4e!KF${9Qy?2X5pWWL_gR`G`1>R{%t2eR?z9JcHt{vho2=I|lhB5*+X_H*s9O^*&MnUTQFzEkQ1T=8l` z(=<11kePfmEjt!%|H(D8j+>kd=G}R=yDfsx(*#eQnrJ=2wwCYvcRx8v`?z_}OnGV2 z7ysz=J(=cLG2A8MLE~S!vN`$6mp(P+%O>T*+oI$qg1e?XxmmXTMOmeB+R|ArwqJ1sGREI@KEPq_tG*#951Y0_}%;@Wuxr2Y~%Xr5h+uqmh>AdqEhWi z{G6$8%ZA@$oczvDCG}q$bc-gAG)|9-+}c_1zeI+kzXAErOfcZ7tSn*lk3HtTawFE( z)J~@YRmQj|wA+ZX7lGV>4LtJ@>?myaTOY&T ziO{D40s;ViOy(@@YB)W6hCj4&zbun#)sjG$6UyWetT>xjmwOHxV))Ya)J%Ll%N!q4*dz3LvoWpvYNx9BE z@Il-6ms-a0o0pftWNj?KhuF>g_O}QPd@>H-c(d4T>n@$a*7qfRij}+9Q|KpIcp}4j z`d+ibRWRRSyX_|u`4pd?3343}uzIUnU>_O1MK5#EG@=`fvdWV_Kf)%5g<@kdk6X5= z8r z=7qgZ`kB5Aiz=1F8iO72uGmS@*NftNHuxWIwyu)xwEulpNnYjV!27-isT%8O*wWQT zO~C{otGP5tMoVw`-!^8{4pC`ek&jhv+4RJ=s?5~a;|27t5bvUXmBJc<8wxuz_0^6> zWEpL(4jM9z*o0tzfkU$Eg;^7o7P0hI1k+xsrt@Il`RZf@r>scY~wl=xyVGHt&{Sbn$do;_)Pe(goal9Mey$w1G6SMriq zo{K(Jpg2^=9k*|DnRor83U$}qE!)%s8NJqned)jHiFa_}aXDu`)~Kx)H~FD}qnn>vft2jBN2)7Ye%=k|_AF{wLY$r{>PsihWG~=Kd~*edL^X zKE0d8UC-o{ibqZ+ye5?bzr0+%LD8(IHx0&)OwSt-xyQX=PI%^JaE*YI6S3{4ymyvc zqqvUpIQ?4)l~+w?i>Q{_MZN2X;D`CQ=DQL;_Ugn7<9?ed{(r%J_*`U`0so~-6W?F$ zc231(KuH8!VoOUn=1oj}(9MaP?^kRtDd=LTBGIa}v9JEm{S@17-kfNVYA!FspAf>? zh1gsPxK*=kj4;ZBFD{p4a|xgHB|r%DBjLQ*^Is~Loa;DF)@d0LSeTvpAc{fKJ=WLd z-8VOuc4&1OQ^0%jU0AsHs{R~x{+^6m7Z&Fdj%PjaP!e2CKDyE>q1Jzi^Y3B=lq}Po z{QO?)FY7`oRyhXvbUReEZ6&LspO;^p`290k5Vsn*4u6Z4I_#K+3=v{AwXq#0;P%YF zMQOGGe-9`Gj%K0S04M{_Rj3pHT6#J}RW3k=acSR19d?)^!kt=ko98$FbDjEQ0l88T z)uON(Fuk%Z*tk-gShxX!z=yK$lr`q{Qgt7Wh*&%Ov!ZWd4r^Wn)jaxs6xx?M4){0b zpT8Nx(T9r*;=LzDR}_R{uQo=;i(Z_ogF|u3RV;$2ZCG$8=m+>H<9x4fXryaBbx4q~ z7w#;G$}1;lpY{{08?J*}wri^gu{?FlY{^LTP;%tKz{oxK=vFJRcm5nOIk1^qDx}fW zV{i;Z+0G#^!(2X%q3`irp3!^ zVC$^kqBgsVnWqX>bn-U?*Kg|jrAz!3;D$b7fs1;UE(P(=628ey0YvxLq@)!NtHkf$ zb@Q`)7K)fT6Y)+YDIIm6%8(oPKi?(H$~w`#sGhEcZ#RNCK-ceY)aWjUk_~3Mh(yoM z;unObS9wt@J{mU&z$W$M(Y8l1->mT&C5SB)ng#Av`KY567m;sgIi&xztpe#BokdNp zIs0Cm>~?qn|9ymwgA9ilhC||KUrcksBaZFLFj2LtYGsD zhkG{mR6Oh-|M$Cl4lgWtJTbByHSz4{*)@?i^ym%O(mG=S zi97KTCSp=2US7Z1s7UUhn6iOYD}EtGelgr32`AgV_R){UX9srRkkck0&Us7S@4X!X_Ff^PLItI{&53jlZhJ8>%nGtUk~!-*H` z0D`b>%<@ngC!X`&7Tl?~-K}@3Fur1eL*}~e>ag0Jj4b`h8+s_o;0*-7#;5Y?-fPz< ztNi=;Th@s3d)#o4ueCNQyRKF#yGG#5tGdBfwvECGzHr9vvbi?SjW=J^6%4fNR0%99 zd{F-HGcnJ$uY8VnRI-#r=9u<|`hfJa8j{l-H~+`+SjV999M^A9e2zG+GwYB0@ips1;}aN1v$D<{4&OjSR|-A)U=XbI_c<#Y$IdUKCe zs#U(FJw0DiZfxgk+RNw7l z+PI#BW9Js}qY4WKhr(M*_zLcziEU$(q2UgtSUzNgm6iKrh8wgot@9fCx0yGIBH`|< z*YGKwgpY#K=u_fp=l!$T#sPg@=<+QKl_JTJ;rj)i(9%cq?V?_*&Q2Sj`=B)zKpTax zNN{*~`F(jgXz-!R$3;xwzXOS1eQgLJxqpSKMwG(EFLWgs^<%y0Y%XJJJ_y4cV3ZD4 zYl!y}DirARP!p(`^kV_|)WNO<@?WkJZ9CeGtC7)<@$ua0k#3*9Tbjn+Xt#mP@HuDc z#TTH>Z_|oX?U6ybL_Y@lK?(eB{QW6`RY$+n9y!!oB4w{>QZnsfe9X+u?D%nZCu1WI zSXBW>F7_DH>XAX3P7lQN=!4O7I^M)=yb9C`G>&_(M*3*Oy-D?-$7#YFYbPj}=BG*~ z<0ctUS@gE#{J?l92yWk=?zgz0mvP*QW`|=6ypf+|6aeH8x&u@81)z-z9-s$0Q9`I< zx;y07VNVF=fnGtiqrqMSNbBasxF4o$STsjh0qiY?m*l(Yj~_pxYW?}4SLDyp+sRf&mwQZ2n2Aa9>4AcjNsIWI`f?L#U$xG9akDe45_r#OAf%s%_d<^Nr9zN)gI zD11Ys50}wtUHjk?3^9R_N?u8yAfO5BJd%80vleXh8LxK7?Fmh7YwMRu1mel^%5`0^^q6 z9pq9@6v`uoU_A!#?z z;^H<=1zK2Ig3A4@-3N4rKk9M0Qo5}OwVsey00U{=5x=ByPi`Fml9@zwf6?;lxCq+5 z`rx6LY1dzdacxrcl@k+tgyOg^L0MTSkzU=CZ`wREjgP=%KLSbtV-3Oq0m^Ig)VOdN zLh*8A*2gz}$4X4TunEyD}XJo`itF^Vx-vgmrYVDnNK(iu?jlbzu7P@|G`OPHdEa zK!zh}dpka@L<6_x9V*x*4fj-P$rMpnc7qz(jSvU_IyrRe4yE8u9XNhLukMKc)Jfmj zH1xNOPCO{VRFKO^@%S?Z^8IhiO}hiP+0vklF| zt`6Sohk8L=|NSLmH;n{sCN!SmjQ=xckkeU*NLQq3s}_;Wk27G-;EQsnOOH}ROe+2l znAv~hl!&YUH+b#;!%LUoZub3~fOF1+F#*bbVJ(_85RvSBAwo|Fe;vFd-m*-}{1qh~ yc8Egg`slc5z-5nou|d#YR8@n!^a?*NE_bwPw+Og+{Ufe}r>LoDDd!w85BM+VG?khF literal 0 HcmV?d00001 diff --git a/Bachelorthesis/Content/Problematik/BetrachtungDatenschutz/Bewertung.tex b/Bachelorthesis/Content/Problematik/BetrachtungDatenschutz/Bewertung.tex new file mode 100644 index 0000000..fb56843 --- /dev/null +++ b/Bachelorthesis/Content/Problematik/BetrachtungDatenschutz/Bewertung.tex @@ -0,0 +1,18 @@ +Nahezu alle Datenschutzmechanismen für E-Mails sind erst wesentlich später als die ursprünglichen Protokolle wie SMTP entstanden und haben sich mit der Zeit entwickelt. Viele der vorgestellten Technologien sind unabhängige Lösungen, die lediglich in Verbindung mit E-Mail Systemen verwendet werden können, andere sind wiederum Protokollerweiterungen, die sich mehr oder weniger sinnvoll in das Gesamtkonzept einfügen. Sichtbar anhand der untersuchten Technologien ist allerdings, dass hier keine konsistente Lösung vorliegt. Jede Lösung zielt auf einen anderen Bereich ab und versucht ein atomares Problem zu lösen, ohne dabei auf die Kohärenz eines in der Praxis eingesetzten E-Mail Systems achten zu können. Dies öffnet unabhängig vom Kohärenzproblem auch das Problem der Konfiguration eines konkreten Systems. Die immense Komplexität der zusammenspielenden Komponenten wurde in Kapitel 1 erhellt und ist ein praktisches Problem solcher Systeme. + +Dennoch ist es möglich die genannten Systeme zu nutzen, um eine Reihe von Problemen bezüglich Datensicherheit zu lösen. Um die Inhaltsdaten des Bodies einer E-Mail für jeden außer der Empfängerperson unzugänglich zu machen, kann das asymmetrische Verschlüsselungsverfahren GPG benutzt werden. Selbst der Server-Betreiber oder ein Man-in-the-Middle ist dann nicht in der Lage, die E-Mail ohne weiteres zu entschlüsseln, unabhängig davon, in welcher Weise diese transportiert wurde. Allerdings bezieht sich GPG nur auf den Body einer E-Mail und nicht auf die Header. Ebenso ist es möglich, die Protokoll-Transaktionen von SMTP, POP3 und IMAP über direktes TLS oder STARTTLS zu verschlüsseln. Problematisch hierbei ist aber, dass eine verschlüsselte Verbindung nicht durchgängig garantiert werden kann, z.b. wenn die Verbindung über mehrere MTAs geht oder wenn der E-Mail Server erlaubt zu unverschlüsselten Verbindungen herunterzustufen, insbesondere über SMTP STARTTLS. Und letzten Endes ist eine gewisse Anonymisierung der IP-Verbindungsdaten über TorBirdy möglich. Diese gilt allerdings nur für die Kommunikation des MUA mit dem MSA bzw. POP3/IMAP server. + +\autoref{fig:bewertung} zeigt sehr deutlich, dass selbst beim Einsatz all dieser Technologien und unter der Voraussetzung korrekter Konfiguration immer noch eine wesentliche Stelle nicht ausreichend anonymisiert oder verschlüsselt werden kann. Dies ist nämlich die Kommunikation zwischen mehreren MTAs. Hier kann durchgängig nicht angenommen werden, dass Transaktionen verschlüsselt sind. Ebenso sind die Verbindungen direkt und weiterleitende E-Mail Server werden über den \verb#Received# Header gekennzeichnet. Somit ist es ohne viel Aufwand möglich, den Weg, den eine E-Mail nimmt, nachzuverfolgen und zumindest die kommunizierenden E-Mail Server eindeutig zu bestimmen. Die Menge an offenen Metadaten an dieser Stelle ist so hoch, dass hier keine Gesamtlösung zu erkennen ist und u.U. Sender und Empfänger direkt identifiziert werden können. + +Allerdings ist festzuhalten, dass abgesehen von der mangelnden Verschleierung der Kommunikation zwischen MTAs, die existierenden Technologien die Basis einer Gesamtlösung bilden können. + +\begin{figure}[htb] + %\Centerfloat + \centering + \includegraphics[scale=0.4]{Content/Problematik/BetrachtungDatenschutz/Bewertung.png} + \caption{Übersicht Datenschutz in E-Mail Systemen} + \label{fig:bewertung} +\end{figure} +\vfill +\clearpage + diff --git a/Bachelorthesis/Content/Problematik/BetrachtungDatenschutz/Verschluesselung.tex b/Bachelorthesis/Content/Problematik/BetrachtungDatenschutz/Verschluesselung.tex new file mode 100644 index 0000000..9b491b6 --- /dev/null +++ b/Bachelorthesis/Content/Problematik/BetrachtungDatenschutz/Verschluesselung.tex @@ -0,0 +1,5 @@ +Mit Verschlüsselung sind kryptografisch-mathematische Methoden gemeint, um Nachrichten (z.B. Text) in eine neue Form zu bringen, die nicht ohne weiteres (z.B. ohne Schlüssel) in die ursprüngliche Form gebracht werden kann. + +Bei der Betrachtung der Verschlüsselung von E-Mail Verkehr muss erst definiert werden welche Teile des Verkehrs verschlüsselt werden. Hier gibt es mehrere Schichten. Die erste Schicht sind die Inhaltsdaten der E-Mail, gewissermaßen der Body und eventuell auch die Header. Die zweite Schicht ist die Sitzung zwischen E-Mail Server und Client. Dies gilt für alle involvierten Protokolle SMTP, POP3 und IMAP4, die diese Verschlüsselung unterstützen müssen, um die einzelnen Kommandos vom Client zum Server und die Antworten vom Server zum Client über einen kryptografischen Kanal zu transferieren. + +Zunächst werden Technologien bezüglich der Verschlüsselung des E-Mail Bodies betrachtet und nachfolgend Technologien auf Protokoll-Ebene untersucht. Dabei werden auch Probleme dieser Verfahren und Methoden aufgezeigt. diff --git a/Bachelorthesis/Content/Problematik/BetrachtungDatenschutz/Verschluesselung/GPG.tex b/Bachelorthesis/Content/Problematik/BetrachtungDatenschutz/Verschluesselung/GPG.tex new file mode 100644 index 0000000..fc062ef --- /dev/null +++ b/Bachelorthesis/Content/Problematik/BetrachtungDatenschutz/Verschluesselung/GPG.tex @@ -0,0 +1,30 @@ +\QuoteDirectNoPage{GNU Privacy Guard}{gnupghp} ist eine vollständige und freie Implementierung des OpenPGP Standards, der in RFC 4880 \RefIt{rfc4880} definiert ist. + +Es handelt hier sich um ein Verschlüsselungsverfahren, das asymmetrische Public-Key Verfahren mit symmetrischen Verfahren kombiniert \QuoteIndirect{rfc4880}{S. 1}. + +Ein symmetrisches Verschlüsselungsverfahren benutzt nur einen einzigen Schlüssel für das Verschlüsseln und Entschlüsseln. Dieser muss also beiden Kommunikationspartnern zur Verfügung stehen, darf aber niemand anderem zugänglich sein. Die Übertragung eines solchen Schlüssels wird deshalb häufig über ein asymmetrisches Verschlüsselungsverfahren bewerkstelligt. +% toref + +Ein asymmetrisches Public-Key Verfahren besteht auf Sender -und Empfänger-Seite jeweils aus einem Schlüsselpaar. Dieses setzt sich aus einem öffentlichen und einem privaten Schlüssel zusammen, die gemeinsam generiert werden. Nur die öffentlichen Schlüssel werden ausgetauscht und erlauben der jeweils anderen Partei für den Besitzer des Schlüsselpaars zu verschlüsseln. Der private Schlüssel wird vom Besitzer zum Entschlüsseln benutzt und kann mit einem Passwort geschützt sein. +% toref + +\begin{figure}[htb] + %\Centerfloat + \centering + \includegraphics[scale=0.4]{Content/Problematik/BetrachtungDatenschutz/Verschluesselung/asymcrypto.png} + \caption{Asymmetrisches Verschlüsselungsverfahren in der Praxis} + \label{fig:asymcrypto} +\end{figure} + +\autoref{fig:asymcrypto} stellt schematisch einen vereinfachten Ablauf einer verschlüsselten einseitigen Kommunikation von Bob zu Alice dar, basierend auf dem asymmetrischen Verschlüsselungsverfahren. Beide Parteien benötigen zunächst ein Schlüsselpaar, welches lokal generiert wird. Danach müssen die Parteien die benötigten öffentlichen Schlüssel austauschen. Dies kann manuell oder über einen öffentlichen Server geschehen. Als nächsten Schritt benutzt Bob den öffentlichen Schlüssel von Alice, um die Nachricht für Alice zu verschlüsseln. Dann verschlüsselt und sendet er diese. Anschließend benutzt Alice ihren privaten Schlüssel um die Nachricht zu entschlüsseln. \QuoteIndirect{Ferguson:2003:PC:862106}{Kapitel 3.3} + +Hierbei kommt die Frage auf, woher Bob weiß, dass er den korrekten öffentlichen Schlüssel von Alice besitzt, wenn er diesen über einen öffentlichen Server geladen hat. Um dies festzustellen, wird ein \QuoteM{Secure Hash Algorithm} benutzt, der gewissermaßen den Fingerabdruck des öffentlichen Schlüssels darstellt. Bob kann nun Alice über einen sicheren Kanal kontaktieren (z.B. persönlich) und fragen, ob ihr Fingerabdruck des öffentlichen Schlüssels dem entspricht, den er lokal sieht. Aufgrund der Kollisionsunwahrscheinlichkeit von z.B. SHA-1 erlaubt dies eine sinnvolle Aussage über die Echtheit des öffentlichen Schlüssels, den Bob heruntergeladen hat. \QuoteIndirect{Ferguson:2003:PC:862106}{Kapitel 6.2.2} + +GPG ist im Ablauf also ähnlich wie \autoref{fig:asymcrypto}, benutzt allerdings auch das symmetrische Verschlüsselungsverfahren in dem Verschlüsselungsprozess. Beim Sender wird dabei die Nachricht selbst lediglich über das symmetrische Verfahren mit einem einmaligen \QuoteM{session key} verschlüsselt. Dieser \QuoteM{session key} wird dann mit dem öffentlichen Schlüssel des Empfängers über das asymmetrische Verschlüsselungsverfahren verschlüsselt. Der symmetrische Schlüssel wird dann am Anfang der Nachricht mitgeschickt. Der Empfänger muss dann erst mit seinem privaten Schlüssel den \QuoteM{session key} entschlüsseln und dann mit diesem die eigentliche Nachricht. Dies geschieht natürlich auf Programmebene und wird nicht manuell vom Benutzer durchgeführt. \QuoteIndirect{rfc4880}{S. 6} + +Anzumerken ist, dass GPG nicht nur für Verschlüsselung, sondern auch für Signierung benutzt werden kann. Damit kann der Absender einer Nachricht kryptografisch verifiziert werden. \QuoteIndirect{rfc4880}{S. 7} + +GPG wird in der Praxis vielfältig benutzt. Dazu gehört das manuelle Verschlüsseln von Dateien für Andere, das Signieren von \QuoteM{git commits} +und das Verschlüsseln des Nachrichteninhaltes einer E-Mail. + +Angenommen, die E-Mail selber ist über das SMTP Protokoll in sicherer Weise weitergeleitet worden, ohne dass ein Dritter diese verändern oder sehen konnte. Wenn die E-Mail auf dem Zielserver eintrifft, liegt sie dort dennoch als Klartext vor und wird durch die verschiedenen Komponenten innerhalb des Servers durchgereicht. Ist der E-Mail Server kompromittiert, so ist auch die Nachricht kompromittiert. Ist die Nachricht allerdings GPG-verschlüsselt, so ist dies nicht der Fall. Zumindest nicht für den Body. diff --git a/Bachelorthesis/Content/Problematik/BetrachtungDatenschutz/Verschluesselung/STARTTLS.tex b/Bachelorthesis/Content/Problematik/BetrachtungDatenschutz/Verschluesselung/STARTTLS.tex new file mode 100644 index 0000000..53e228e --- /dev/null +++ b/Bachelorthesis/Content/Problematik/BetrachtungDatenschutz/Verschluesselung/STARTTLS.tex @@ -0,0 +1,33 @@ +STARTTLS ist eine Erweiterung für eine Reihe von Text-basierten Protokollen wie IMAP, POP3 und SMTP, aber auch FTP oder LDAP. Für IMAP und POP3 wurde diese in RFC 2595 \RefIt{rfc2595} definiert und für SMTP in RFC 3207 \RefIt{rfc3207}. Die Erweiterung benutzt das TLS Protokoll, hat aber im Vergleich zu einer gewöhnlichen TLS Kommunikation ein paar entscheidende Unterschiede: +\begin{itemize} +\item die Verbindung wird zunächst unverschlüsselt initiiert +\item nach der Begrüßung antwortet der Server, dass er über STARTTLS verfügt und der Client kann eine TLS verschlüsselte Verbindung initiieren und anschließend z.B. Logindaten senden +\item es wird kein dedizierter SSL Port benötigt +\item STARTTLS ist allerdings protokollspezifisch +\end{itemize} + +Nachfolgend eine SMTP-basierte STARTTLS Verbindung: +\begin{mail}{SMTP-STARTTLS}{SMTP-STARTTLS} +S: +C: <öffnet Verbindung> +S: 220 service ready +C: EHLO bauer.de +S: 250-bauer.de welcome +S: 250-STARTTLS +C: STARTTLS +S: 220 Go ahead +C: +C & S: +C & S: <Überprüfen des Ergebnisses> +... +\end{mail} + +Ab Zeile 12 ist die Verbindung verschlüsselt und der Server kann beispielsweise über \verb#AUTH PLAIN# eine Klartext-basierte Authentifizierung anfordern, da diese nun innerhalb der verschlüsselten Verbindung sicher ist. + +Die Vorteile von STARTTLS sind einmal, dass keine zusätzlichen Ports benötigt werden, aber auch, dass optional eine unverschlüsselte Verbindung weitergeführt werden kann. Da dies aber häufig unerwünscht ist, ist es bedingt möglich den Server so zu konfigurieren, dass eine nachfolgende TLS Verbindung erforderlich ist \QuoteIndirect{rfc2595}{S. 3} \QuoteIndirect{rfc3207}{S. 3}. Für POP3/IMAP in Verbindung mit STARTTLS müssen Server so konfigurierbar sein, dass eine erfolgreiche TLS Verbindung etabliert sein muss, bevor jede Art von Benutzerauthentifizierung stattfindet \QuoteIndirect{rfc2595}{S. 3}. Auf SMTP Ebene ist es nur für Server erlaubt, die nicht \QuoteDirect{publicly-referenced}{rfc3207}{S. 3} sind, TLS Verschlüsselung zu erzwingen. + +Zu den Nachteilen gehört allerdings, dass bei STARTTLS mehr Metadaten verbreitet werden als bei direkter TLS Verbindung auf einem alternativen Port. Da die Verbindung initial unverschlüsselt ist, erlaubt dies auch weitere Angriffsvektoren wie z.b. \QuoteDirect{STARTTLS Command Injection Attack (CVE-2011-0411)}{rfc7457}{S. 4}, bei denen u.a. versucht werden kann, die Verbindung während der kurzen Periode von Klartextkommunikation herunterzustufen, indem das \verb#STARTTLS# Kommando vom Client gar nicht erst den Server erreicht. Dies hängt aber auch wie schon eingangs erwähnt von der Serverkonfiguration ab. Ebenso sagt die Spezifikation nicht aus wie ein Client sich exakt zu verhalten hat, wenn eine STARTTLS Verbindung fehlschlägt: \QuoteDirect{If the TLS negotiation fails or if the client receives a 454 response, the client has to decide what to do next. There are three main choices: go ahead with the rest of the SMTP session, retry TLS at a later time, or give up and return the mail to the sender.}{rfc3207}{S. 6}. +Dies bedeutet, dass der Client theoretisch versuchen kann, mit einer Klartext-Verbindung fortzufahren. +Dies muss auf Clientebene gelöst werden und entsprechende Konfigurationsoptionen angeboten werden, ist aber nicht garantiert. + +Trotz der genannten Probleme ist STARTTLS das einzige Protokoll, das einen TLS-basierten Verbindungsaufbau von SMTP, POP3 und IMAP Servern überhaupt spezifiziert, im Gegensatz zu den Pseudoprotokollen SMTPS, POP3S und IMAPS, die keine konkrete Spezifikation haben und das Verhalten zwischen Client und Server demnach von Implementierungsdetails abhängt. diff --git a/Bachelorthesis/Content/Problematik/BetrachtungDatenschutz/Verschluesselung/TLS.tex b/Bachelorthesis/Content/Problematik/BetrachtungDatenschutz/Verschluesselung/TLS.tex new file mode 100644 index 0000000..bf39fdd --- /dev/null +++ b/Bachelorthesis/Content/Problematik/BetrachtungDatenschutz/Verschluesselung/TLS.tex @@ -0,0 +1,14 @@ +TLS bezeichnet das Protokoll \QuoteM{Transport Layer Security}, welches im RFC 5246 \RefIt{rfc5246} definiert ist. Es ist ein Protokoll auf Applikationsebene, welches den Datenschutz und die Datenintegrität zweier kommunizierender Applikationen sicherstellen soll. Dabei besteht es aus zwei Schichten, einerseits aus dem \QuoteM{TLS Record Protocol} und dem \QuoteM{TLS Handshake Protocol}. \QuoteIndirect{rfc5246}{S. 4} + +Das \QuoteM{TLS Record Protocol} stellt dabei die unterste Schicht dar, direkt über dem TCP Protokoll und stellt sicher, dass die Verbindung selbst verschlüsselt ist. Dies findet über ein symmetrisches Verschlüsselungsverfahren statt. Dabei ist der gemeinsame Schlüssel auf die Laufzeit einer Sitzung begrenzt. Ferner definiert dieses Protokoll wie die Integrität von Nachrichten über Hashfunktionen wie SHA-1 sichergestellt wird. \QuoteIndirect{rfc5246}{S. 4} + +Das \QuoteM{TLS Handshake Protocol} hingegen ist im \QuoteM{TLS Record Protocol} eingebettet und übernimmt die Funktion der Authentifizierung. Auf dieser Ebene fällt ebenso die Entscheidung, welcher Verschlüsselungsalgorithmus benutzt wird und der Austausch der kryptografischen Schlüssel. Erst nach diesem Prozess wird die eigentliche Sitzung aktiv und Sitzungsdaten können gesendet werden. Dieser Prozess findet über asymmetrische Verschlüsselung basierend auf dem Public-Key Verfahren statt. Darauf basierend ist dann der Austausch des symmetrischen Sitzungsschlüssels sicher. \QuoteIndirect{rfc5246}{S. 4} + +Der öffentliche Schlüssel des Servers wird in der Praxis häufig von einem weiteren öffentlichen Schlüssel einer sogenannten \QuoteM{Certificate Authority} signiert. Die verbindende Gegenstelle muss also nur dem Schlüssel der Certificate Authority vertrauen. Applikationen wie Webbrowser liefern häufig ein Paket von vertrauten Schlüsseln solcher Certificate Authorities mit. Öffentliche Schlüssel können allerdings auch \QuoteM{self-signed} sein ohne Verbindung zu einer Certificate Authority. Diese müssen dann allerdings beim Empfänger manuell verifiziert und zugelassen werden. +\QuoteIndirect{Ferguson:2003:PC:862106}{Kapitel 19 bis 21} + +Die Schwächen und Probleme des TLS Protokolls und des darüber liegenden Zertifikats-Systems im einzelnen zu analysieren würde den Rahmen dieser Arbeit sprengen. Einige der bekannten Angriffe auf das Protokoll wurden in RFC 7457 \RefIt{rfc7457} veröffentlicht. Für einige davon existieren Lösungen, entweder durch Konfigurationsänderungen am Server-System oder durch Erweiterungen der TLS Spezifikation. +Festzuhalten ist aber lediglich, dass TLS das wohl am weitesten verbreitete Verfahren ist, um die Kommunikation im WWW, aber auch die Kommunikation von und zu E-Mail Servern zu verschlüsseln und das Problem eines \QuoteM{Man-in-the-Middle-Angriff}, kurz MITMA \RefIt{mitm}, zu lösen. + +Die Protokolle SMTPS, POP3S und IMAPS sind also nur Bezeichner für die Protokolle SMTP, POP3 und IMAP, die auf den dedizierten Ports 465, 995 und 993 ansprechbar sind und nur über das TLS Protokoll ansprechbar sind. Für diese existiert keine konkrete Spezifikation. + diff --git a/Bachelorthesis/Content/Problematik/BetrachtungDatenschutz/Verschluesselung/asymcrypto.dia b/Bachelorthesis/Content/Problematik/BetrachtungDatenschutz/Verschluesselung/asymcrypto.dia new file mode 100644 index 0000000..7232fec --- /dev/null +++ b/Bachelorthesis/Content/Problematik/BetrachtungDatenschutz/Verschluesselung/asymcrypto.dia @@ -0,0 +1,1964 @@ + + + + + + + + + + + + + #A4# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + ## + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + ## + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + ## + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + ## + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + ## + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + ## + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #Alice# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #Bob# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #Bobs pubkey# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #Bobs privkey# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #Alices privkey# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #Alices pubkey# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #Alices pubkey# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #pulls Alices pubkey# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #Alices pubkey# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #encrypted for Alice# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #pushes Alices pubkey# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #decrypted# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #public key server# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #Bob sends encrypted +file# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #Alice decrypts file# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #Bob encrypts file# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/Bachelorthesis/Content/Problematik/BetrachtungDatenschutz/Verschluesselung/asymcrypto.png b/Bachelorthesis/Content/Problematik/BetrachtungDatenschutz/Verschluesselung/asymcrypto.png new file mode 100644 index 0000000000000000000000000000000000000000..6df4b9c3e49df33c913f08368f0f9b0af377ded0 GIT binary patch literal 47014 zcmZ_$2RxR4{5B4sl8{}L8PbqMMiN3wkwQihk&(<~?~z19p^^p}k-ajqC5c2KB+8ai zvSsFfoWA${d+z6c{?GM#ed`<7bzYzI^LdZseY}tNc}r9M1j9zojRZk3sHz;(A_z+S zx6XrR9e%P`?-2|BqI6PH)uExG>Fm|$!9QuQs^~ir1a%|%A4Sofp%{YTBUFza(Q%LZ z{lmksexaXw;_s=%CFZ&u<#(?fm0!_>o8^?$J`|x1Un;LFj?XvYDXM-MZ)Wb6VSd9l zGv4w7TZDjHk&H{dx36FQzr~kkPpvJwoJyZFg^rso)-O%}D}C=f`SkD5^b->?`lDC^ zq1cpTMNR$>VWl`miN7>ACi{^8JV}wyM6godsW#2gWAG{vlb|GOsaoU-&Ev@qL~Nku z68WZw0YYQ=i?t^=jZmaD!6(e`_0ZcoI=;%t$awkk<*i#E{`@G}tDx(1b#R}Rl~q+R z)7R!^@dF2bl(=Pu9i`cJ*}|f@xR{fJV`Oyn(_^t02?@vCOI?1o<>;j+szq+}t^f4N z)yc`GDgH)rvFG1EKLoaKU*B2cI#y?z^C?C_gJxlAyh302?CUE(tfR8?@|-_D+V`W_ z~Opn0nVpzV^$=6vxK$@$*-9cUKgs&{uKGx`r_K_4U0Sn&t@dnCw$d zJDbswZxea{{?ycQf>8}tsFu66~2f0&D+xT>8t9W9=OB&%IeEYPUEb!w7vWT z6TMYbR8*oyr4y5rR&D7|!k$o>$jQlxi;J(9n4h0#R(iD0;Qjvkx`@5B{0b{G4|-BO z8z_m}3~R>`dymGGt!n>PQKKD!^t|#>EE#jU4C5@Qd^3h1&m&jHuG|Iu-@+Zr-$shF?lbioPo0<;zV<=ku+r`zJf{td7!r zsIO0VaAaU$P*U;q^c=jaWU(c%cha5hy8Vx0Wtx%iMG{r}4|~q=1tugUNM77VXxhTQ z_?%LmOWel0Xcx6-lOCV1GaTeGcztD`xjA-+hX3>P!<%>B4-aqpYU~#s6Jwlnp>fF3 z$%#tg=infVQeJ*Om4fSdS2Xi0ry+HvoB8=Jb`SoJw%%cmkBc+0u_A%K7Ux3Grqt4rfK=-=H|BVT2CYfbWjto zL=GN|^!`@Q-t?!6O-DvRK!D$jo`FI2LTh$FMTMWf{*$sYAFO=v$KJMPA)4ndSFiE~ z4h#+DezUFY=X4qCm|dLx1%sIXl~wURlvji1+p9}=CZ42i)+v*9`x7Q=W9&0TK~M#e zU!{K4uKOm701bb`(*pv5rGBeM6D@GR8^7HL>)4cPVO%#ta`N+c21XtBI{R=3Jjlt- z%@4lzx7%-Z&byt=ubv)23)U*}%` zjXLB+!%w$GIJq>30>L5vEw4Kfb|^qb{8Ak&j*NlfF8|RWo$rxPV`9b!2V3Kn>3Dc} zyu6mMB%w>{YHBvUZ*T0{wTqLJ^ZEvcVwYcMBdpRC%Dw*n303&lo@b?f;6T28`GUn* zM}EHYCOO}K%O2Q#T7IXW^(@QM__M&SGc`4Jbaa$)o18nGA|O0Q-lw^_*}6I51McKT zY1ii6>LJ{Rw2Y07PoHl1{@uIg9uIC=$s#i&llGBve}8|PZPvIP5u2<>pE*Gg90K!v zm#F4D_w3)__~pwqVyA-3DC?LoK@=7+5sIcblADcQ?i54_-nBqSs#7#qEgC~w3TR8C3wuR|&cW0Q6Ljer$L z{z6knCm|(8RhG)%J$8}am>J= zBsuw}>qf%iEp;Kjix4DJ4_=A>FlmB_WhL`ZtgoQ&bJe@S?}yTen>6I20$H?D8($Lx zbk@8CA;~P?wO+Bjhtd#lJuAG$$@?U?IH8p$8U%E9=8^{ci^l@lkAhQ@V7DRh^PT7!vCqRWReh_`&}Kg#LYfq z83o}kB0ajL8--`DHNPc4cvFA&p56*~W_ze!|Hkcv4(WwNzO|myrt;^zZ&ep?iYmUl zzfF-%`U4$79AM5%uB+fYOR@J;nw0pd=)m2qaytj+Scyyit+->$hoi6moUM59`qP6_ zmp@vQh3`89_cEnTdLGj`OpuX;IFQ=)K&XJmL$k9y-;UKM^0xTyy8UPF(ZmK`y}uP1 zn(EU;!2P5DM`~Am(sH&ZyM_8Bub>uA({#ySp=m0kGe}6dkq%7WD zd-u1k*4bUpQ=DB??`-LNvXM9zNUk-W^U(c-m$xqq@$fkQq|eD=`D{z@Z6r@NnO9po z{$*P-$8$M;Dk}3C%c;NJ34VTJ)$9C=$@M9&L>*QucD8Dvx3E|}P%&OEASPz%OK1fc z$Y62zCi_*5wk`aTbsXay6C~e&8Cv#AOG5A{3by^gm^gZ{6DT;)GRFSnQpxq8(=|@^S0y zVC#yEh_dI6jbmIlig_*0Se-e;GR8{89$Wj>^78cO2fH<1Ml00^F>tv8WRO?9)$<7M z`G2|0|8<}oo7mWNwY0Q`vXP80RQO)l=m9iGi~Xu)hL3LEyxGrh6;XkcTFz_E7U;y- zZ^b1^Jvt#OBRt^x^^YGv{^FjS8vKZ8q{h!g2=Ze?!}wnuziZuHzH*ywZ^vtUu+S`<>{O|=l0?L&WGA^`nvCp{N@WO>?Q*}b~A_+JQj^E|HWM{X}J?h!BXHik7Xl~uPlQyjCH1sK= zBvD>T<-xAgrDbIwRz(e-K6_T-J{iFL%Ax=Gk>3941%zFSrP7O=6BG-Ax+Hm5*uSEH49b1;oy;DMK`jw9zYwzfo zT2Ri*B^0Y*cm5%%uX>UQHJ^0{MCL#I)-u-D|7KsYGS_gh`_xm(k>*6T7X2r30Cz0u9d$16Z$~ZsDyEa9QvcAgS@)*5it3+NmURNuRP$!!1p4jgIB(@AH2eSr#e2Gk$6W*-kcI@ z0Uc{`i~7d_0qc;eMl}}Z=Nr|3FfS}D03W%}3^zU8qkX=>_8TAxpvd>{hCwFD10GWY zAAWz!?R;%tfnwwB+qZB!<08kMA|hAjCwg_J2>*e#HZFGd$B!R7kG6bx_b%Z?=(b0X z9$_~k4NLR#@_;CL6?{w6(?c38oTQ^*E4W=X#}n&`V$$Z%l5pyKp#yHf!lE7k4* zD7Y^sPD#tT-`}jQt@}>8FU{F0C{!R=z)lYwIN;{?H)8KO*FWF&4W}vnZIy6}9EiMr ze@DKYn8%g|VC|~AHGC42l0*#)C$MD!yx(kHSO2Xn&5W4Y+5LEVnrrjs2LLLszU3QT zn8we4|Nf1Ao|&1!&Lkuybp!Vde83kzH!OA@0iyC<7>qn_MB_d?s*9C8e#{X<*RV(xTIJ`6Bzz&kCzE)6*p$)4TW+P_a$JMHKve&E%PfDk-&gJQ20pyDy?P zkKiL=i+Es7KO4#iUTqzn9oG*!{q8Dz#@shHR)#>MTHjsf^%wT|+VQHI zT&%FVJdIz`@b5DyFwC=TO4rZD$#Zd7^u0T-P7uz>H~#b<^Am9u6%`X=Fwvhse>Q&* zD5hrG#;jCmnECqk>%vEisVeH~|K=wJs`eucZ#7yvsiqdX?eOA9(F$`5i%m+WPM?n4 zXCP(QAqgCL+#)-h@4knFv1LHkI*Ks*wU~aP*xA9=b&LFQsjM*@xHM^J^4{$)Pd|eL z-TM0;OYgn{mq4HoxTMZMmXVx13~Y_6&gb9qA^rqJ(7op}v2wO^k84$OPEoF{oVa-{ z_BICxN14x(E5NeaBVmq1jsx?P{TZkly5sp}wuMH9gBvE~&wKUB@~Qy<6vse2R*S5X#{|0PkMQ^A6Q{GBPsTwr!)^DiS5<;W*n7 ziByD?aoB6ldwD*bd1~x+x2Km^D2K!b;i?n) z`uOS7y|vdrcvx<3E<8%J+oRof&YyxZJtJf6_wNl%+tTCW&iK^hZVM0wh8y`SefC!c zF-*_RZIf|MW;fbE2yS0Hk0~!ZV>V=_045{;z=x5MxVeRe>7fA8%kWHXBctaRFR3d6 zUTA1!c})L|sEEqIx|JUN5|@xbFvr=S*V1}xn&Ug)OKop&Z)0O)RVqb<8Iau1{lwH% zYa5%r?`cuT`Sre~+7_A=A1`jzoB&@@ok{beP&6S?PVJMB5PCMYh&|db)Ae%VkrVRz z3IFeF?mGoH@u(=!*myQwuXlJjIV(#;mWHV1SX+Cy_w-#;!_M7jwrtrl>`gQhwjCq_ zB@{Uk0P%XbPJL>fKmEe|q?xmG-h`O4vhwMP#0-L%4JO^_T}#Uhf@te&E)I@w?d{A; zQ&ZE7F^A;b-hO}cMlmIck_fXWQ|ZyEsVT&j^FCgdmcw9^P+3ZuzPtICWqiTAd?pt+ zAiK64Z~2PkL^9F)%oDAMU-b-Vz-%^{Kn_rdIMmd@IfSOPYU#md=7xJooG&AF@ zL=#%$H8ae@Pe#TV1;5O8BTdbTzG}K+T8jT7QSGCF0dw+gB~C+({5$sT%P1@?G+hF0 z!~u?gMhMd;kLrKXbpH#8`}b33Tcd`GT!qODE^--_^D(6{k_S<@kmTd zLufN#4Awq>{-i7&;m^JH|V z-rd@aiWV23V`O|}C`Ay}WN@3ATv$eFIyL2}bTcPMj6bl!;-Gz36mv7`TwUGP+hZtW z7Z(=;nQ<#z2e0UzKmX@jZZLD-;9$i4`%05L@n!P(vRF|`$-Hw}Mu3M13&0KywYBb3 z1FFxY>_B(n1m_T8Z;v6xwY0T;s;k=`*#7O?7;@`qOUm=-&jD^gvmh|VE-4{T?vSbI zp;IFW&f^iTU^ZR7U*4zUc+<`Q*uy3q_8X>K}_yP*CjIvj@v|c5;$M zVf^fLFGEIR;-yok>XF6ZoVFJ)^4&U$93i!Hr}ELGFL0&%k9i5!ZO9#(TR1s8;*L^l zYkvWW*5+nxWAm#u?ObqRV3f2&Jif50sj0lYoZ)fOB$5duw{+P3`=+qBOLY(7pf11L z&j?FIMnptQJD37i+`4ruFbt`Aqq-9%(Xti(K%5Rpl*h$`#xh^N1T|FPHg1G}W@qn* z3o>v?y?giW=D`HP^2O1#U?$$;l9HjJA?o$(y;o+xZr*ijVs`d07zG6FU$R`GHEOD= zhhQ0bR$pdjX92tc^nnI^e0%`01aB=9vGmzEQ^^~_!3uu=mVqemKG`88Gz#?gIyZNE zc6N4d&eg@`^vRR3#?9Kt&m2JJ5EQfo_9XF;>+kmQiq(I3H{EmVFE1Mq-=0d@rLOM8 z*#pgaFZ$v9mM40TotQ*e4WgWl;$HvBjZ0aia@d8i+lIF_TfdJzMcEZtd)AHl+ za0dX?Iy$d_{4!9vLTdi_?LjfIg}F}q)|M8_8`OmI4KgzA-n~0X`OX%G&U41b3PM7u z#udItjvQ%gYcn!3>T77*kJOA;o;KnCs%jq(!MAtbTR!sR7?2BSEwi6F+1b+0!_55V zaKC^OW7LtP4-5B9x|^7ofYx@pdbJS14%8gip|}SRz64Ow!N{e#)z#JS=_#%IFP_Dw zl$Od#OOr(Pr%#^%?fC+ohZ~O|4@^qf0|)iIxrQ8vk3@{$rXn=YBaA4XKm`#lZ~_3W z@6R8jh4d@Ps@38ZPoJJgBm*TYVp!PI-!Jg!5TX+&Y+c2`%4($YI&}qjJfNOS=H@yc zXASd1nVVB}({A3Rfi0nK1n9eMbDkg$k$clTjqHTefNeM+3nRy7I)t#>@bbTV|K0+$ z7k!nxySwC+I@%;2WR!1yv;UN$q9Wiu-aU<~gI}Q9U}=qxdn{?Cg#-ui=c6FSf%r=9 zl4Q1?u&8KOdwY9NPY)P%u>CEKjoFL)Q4|2z+*}#HcI_IB4DbgeT5`)iO5p285%X-rH^1rL832v~kv9fX* zZBdO6K6~a2EghZ2fdgf5q5C`4c6fpS)W42R*J9(~D1wEdvZ$?9p`@g&e2)qTmv@H! z_t|C*NZNNTBmN_nBUU1qM9%c0VM0xs#Ano!hYug7guck z!UMxNBrLv{d7YD?rXpg=(ljBVu<&tJ@4(>Tp+kpsSBJNtvb^;1k?Ows5Dp14bL;6@ z+S{*A_Mb@M*-H4Y0iXLtPD9ASNl3;(xaki52;Y*hkK7t0A2?Eg*X=|POM(z0(=jK? zfqUGCP)k$~I)b#ftlle5ku7dPPb=lh`!2ZGo^hqdq6tDq25)yvApcKVrA!;c@)u2HF=81k?D0A?Nf z{d*ZGZ0*e?FS!HNgv8;)WvHgGZ+W>b^))q@L79)E0+4p-8~Pk$RYO69v69&~7U1&O zv17v{BMwD|r%#{maIk)Fk$Y50Nyd3N?BPS4fZW=3smSZ@+_Oh@;xsz~{-5?7fidZ~ z?Ck8vl$DXys5X$V=6jR`9}8(qEQq^TuU-}0v*!syI?m9lCdB|S5Q#{U=E*^OBQ32> zW6}iCM>=0$&Hj3n&D#`wZSCyJ(8=gAj&7; z0bi0dzNk0pq0p0a8GV?U`3F#Y@YnS-s0R@~!X7;$u@~9d`{r(+Ug|ElZH$I6egF3I z7s^_i{{lQns~$S|g}B$jO^QBfCMuqF{@p%_G?Ek@pMyx(*WZt|+g`cSm8iD0!+}!} zfuEoMnhE>fy=iEH;btXMl9Lc&)-8ft?zo^V1U78GC$Iq(J3@U*N($mG%Agl`cWe%sM@>m+ckbLd`Irir zNA<9GAoGO_KM)?_N7!RSiwb>4LeUv(_J1!VD*8G7RqB-H=x|a#6(v4qL942@50m|5I=Z!c?RzRUB; z$=DlZ*>LlnJ9f}-lPd(ImXrJ5)D#Y@@%OAkz>sY0tG@H#{(YGB)qz@;8{^)AVZJMi zcHQOC%;G+aGoTc|z3fYPy4N|xcT|{kmqvu%&JC4+k&h1h=|P1%p4mM2+aQWyRlIdbSWSq72TFb@^%lB%(DtiqR{XP zn%9{ZN?yjr9g)44Ug)z#)}QE@p;i7GhfThnkDffyD~MHwA|#X%7vB_}^~$Ks6G%If zSsW+{L7qIF|K7+5)R>)TQd8iq=_e)5q0VPUGlD-pbLAs?0 zvgUYCkLLOF#TP5rIhS{Ur}@&+v51y?W@e_hd<=PxPmy93GuVS1(27KrU*Wql(ezF! zIW5hp==+v^=W%E0#ud;1Kkr;#S<#4*{{eF3Klst%VEzLg?t`@YcH0Jm%rdSA-_EJQ4|b?Et=XO#8KXm@1I{sZo~#~eGZO} za82WUYc`pfVPtoC7&)+PduQj?ty{^hn4rQIE9%N^vmdAp-zs95ou7aA?p@t8XX2t& zo+HK0j&&Y9eAoxXBeFmucB99Sj19UO#ufkIcVKtqe3zwVjD5gGz${0Ghu2e6)5$lZ zFL(SR+_!uJtN{Y{(`wUbP)xO9{CWMg09!YqX*gijJOEm2grMk9A zo%HZn$Tq1$&_yTUbF^$yYU)W@7D7;VIiHbO)kmiSbq({S0EpTe+>K@p>Jstrb z6lqsi7irt%GHCb%mjPaY*)_GbtMV=TNX!lb4TYjeq>a732I7<8fzmi?;(kQLU~g~b z{*a0a1(_Ik2KN0IfymZyVM1bJ6Snvy1AL|K&-Bn|$_?~|F25d?l^u@!cqvCOZ}T3$ zty?3(Nx6+Q?-Ua|bM73Oo;0;!ZiyX<^4ePvvzWKDE=QqowRP zyKE_meFz38#}MogbiOt=_Ba-yRL$!b6h@_wNQSydBytI@b~19D+=y84@ElMhWCC;> zH=;L-T&*g5uMZ_-OQAzQqKB!O*<{X5g3pKieytlfZg4Xu#m2sAXkduekok{t8Ass7 z$(5ngK(16~?VU&ojI^{P03D{L@dX7^W72g2HT@tO7QudZ`!0=TgVv%`Bes1>HS4ciik-NK1b$%fg3C=UalEx61;+y7frNRDk>^^<=%(xRLeLHsQl-P5O*NB+#+$CypJd1Gc3%% zuS(U3NSyfdLsm`g&FVUj;;G0hc7-z8#6jzYi@PY_#v( zZ++xIz+`Naw+X}oh`&SA3nC&SfG~07QaH$Wcb0lggEV}4(0&^WOWezs$7LCH2FJ!$ zK$d`I|J2p>5B5l2{Owz;g^Dylv;v}zK6F5loA>HfU2W}Slm#$7GN4okB4R7gEza6p zzI+)#vA_TNr`;bx;;TQGOUcOa!9pQxAnoin*@EAAr>38QS6&W%39zZ)1+>X{LNj{x zce@x43^@H`q^N35$Ak3?U)2+#TR~Cp45-%9cH} zMi%WCI0}hlsIHOwk?XxMh24K`*C{0}%^t0x4lq*N-5q1{7zs(vdp?YG5oXdw1hEE^ zPeIiM?G`LUO_ouzEzxNnbv#BW@Eg_aol_mY-Dh{%7>{&kh1fFjMmIM8ov~+JSe_D_a$~QN3XCqgzSPB{RL|(Dk`d^g31@69vd{-362JiWL)Msh@5%$ zEX?nXpWbRH>N!ix$4{Q@Gc4RMDjMo4lFSBc_1-HiJaAPS5eKyLs?S&W zmRjdc^kk&5?}xg&(Z)D3TzqHMLk?3|OKfPq%#C~*g3b+yAmOC8wuF#S zU1Q?}DG)04kU-#E&ESO;EioZsKfRfimB(ny9;KVH_4@kyv_Z7nXrwmMbd_vULV7z+ zQ<+GoSs;uG3GGQ&S&BMCg7yGw~4KZe_LS?$@|u2nKwYGmR_C(Tdx0 zXSUP6B5rz5#(4SC73j<4wtfEaVFY`HfVf=q?p+}B6zX6lm0XJk8h*q>R=L@KD_%-B zA=H~K1Gz@SfBg7yt&b^rsMZHmuUyG|@xlyT6i5l*<;fFR_sbaHMJvE&bY{@k5#F;0 zf!Uu~2}RdY8hp=geskDCVA#8N$11f0r~~fm8WuU;U>5hDznU_ra~=vCzJtKdkHySz zrm|Oi-k_q}`01JdZ?l|#OV0}Wj+pIA`3>R%^#+drshHXOYn0TSTzSt=*w=rgsMd7I zd}KnlK@psQfc_$>qE;X8d_4{`UYr}VxpIYMIX5dogBJrLA}p*C3}od!&_`sIjnu}& z&5hf<@}pSSA)i-;25531C?=*GJ7kb&$+B(Ry-!IK)=Tf3>pH=3bAo9~N%6oPp>$B$ z%lT&OdgD)R&{Tog0^639kT5gW8OdyFV#319Yj11&9eqy7Yq_|%YHDie{&evLT3T75 z>x6!?%^QCTyN3*4bT`m_J18yP{^Q4m zqeuG@9dK7yynAG-S~zG4^UdU9-=JPGG&FRV>(WqI3H-F1ZoS$Sw(g_G9%d0@`C~>N zHJsG@>9za)>w-65b#se3VAF;TB0Eq%7W_4-<7vrGsdZ-7QJS@C8;Ct`ybcih=ZuW5 zT)zAljZ-l9(U2UHLV)ebi$!c~`!e3o76~y4F{Rm6o~o_o4AnhyUXhlEE~y5#@E(tB(5Kz9@3f2qo#iWYw~K@V8wWC* znw!r6K4%%cR-ZAu^-su}OaJnNG0{z9FdQ|5l>qF$a-APcGmWvdJ2`hw6bgS|eP?TfxHa zj)#lU^105ufB*gkGE-7sM;u@YZDnsw%9x^xHC5P7NN(uzy0$5N#`L=Tkm$aBJd&20 zrlx&Z=IT(4U)zGc>)jJIi?;)BIuCFhWPX^lI^!P?*=PTT)c>khITFIqZ6g!vEm%7cR^a^7ZiN@{F!WNBb-`u?P@sJ zRBHxqY!Mw1(|XESTW%hns;a6>i}oV^qe8}N>Z#Gk(&U14N*9Sdk!MZ(B=RXcWRP=LGlNc%( zBh^6qErX+bHFtm+K;8qK1P2TG1@cAS=3A9eSV8@)3@KyOEmU8(Zn4O{k1pl&po@MbHTfU768PS}Ny*be5W(Bzb;DPUC z-wnh)4-b!73N0@-$H`8rSbEJRMHAZ85W$#$%G8ANrMAckGb(Co>J1yLt*k%{Ubt|< zfhT7%{zae>Pc18087u`fH-umcC}PQCdl;0a^800l-j$$*`+`eSg;KPK+Q7^H`0<05 z9}1v9XqNa~-s1R9=#Wi4vGGHDyR^9YE0iQ4_4h`8Br8-w@)A|4Bh$M^OG?6g^jBAp zux)oe$r7rosrjb&Dh)qc<9N+JjZ;@rI;-z|j7~=miMG4Ij;m@v&<83k@-mi?l`Lp4 za9Qm_C#FMjuPXh`Gn zetvMRfJzH|O=%acpBXkscE!$JTTYo=e`#=Et47P&WxY$=Sazp7WN{9qIQ`@d%|~xc z>1Jl8NaV*>$YlraWQ^^k`%K&(dvlEvUj=Y6Ju&gd&rQ=pxNX&U52;$KgUW2{zVpXu zXzA&Hx1?;&VAosFwncOI%$YMFQt>CG47eNrT|o=uk(;Cx@R_F|0fvFfw6w$_UB>AE z35Gv;_6$A0>~FUA_T!*)P%4?L-=({DK!l;Kz(}xNYw+9XQrjVoi160yx=)TdC;RYS zX0=kjZNkpP6q=qc3@Vdz>&1ixQ?`+VTdYZZj_dqaD<1ay7lmEmcx$?1&z5bUNpIgwmb)6#&EPMScUj-=wfG`9~_5my6@Veg z>4mVc?5n*>xHmz|fxagfML+yt)hhdNYf_4&us0&(0X^uPJqy{@D|7T_ z(I~(GM><%IyncTzl&je&=<4bq|3VQ7jH7ZrZ1YRqf;-|`^UDYBZI$=98(QrW6p4nE z$`@2-7uGT-y4E1UfqE|`WoG)KhD8he#EBD2i;HAYG256OK^oJZJ))w3)}Dw7XxN|4 zG9sB<{=mmip9bBy0b1L(J)3{mt{@md7^#`tqhIFf;_bbB&e(^IY*6%vZmZph!V^uQ z%IM>0uR*A-cu#fOY@Ewgc)633j{!CO+~2?Fw6*D&nCzS4sQ@mG^@qRK?GuK zXh`w}DjQKqygQ7E7IZaC*dfxQpxl66*No^fs{+U2jH-)7!&v)$D3JN||L-o9k}RWQ z1NzD@;^R?_T@MJD8}BA*9+maDu=zgyR|D7ppnRr{8%b2G z;{LXy-}wBxHx<& z^qWbRBMQKDhbiEu+n?{4Wtj#Hv${-?9CJ3~Jan1KDJcs}OEGdD_i-%DTsW3VFhbxg zZa#Xn1+k~832-&G%huKwp73^mNN_M3y)xt?wx#A#5`s^0bDy3_1T()vz@nq0!#8qT zRt8Yf($ek|8b|JJh@l)SzzEzyMi1u)xUpCpJkL|Rqyuv-wh~k|KkW=rEnMI z-Ip3M2+iu)b{>uA%wk4A7pFfDOkHZuO={njz7;EVn3|b6rJ*qn%1=>|zzo3M#I;^$ zD}-F&P@!HxC%Z{~z2e=JJq}JbE%f^OJA^}6S(#;J9skKi|0K^x3Vw+sh*^Su$0AH} z;4E$)fjk(9dDp4O*{JHV6zC6cx^5?AI`Rd$4oX=EISr}kv5Sdsx9`@n@hwcGRFu1a z|Ni>!GFK=s0pD==d{Ssr7(kQZ;ZgMBML!&g3>Nl>J;NOOYfIeTeY%&Bpt3ZKb2J4; zLEH_-6_9Mvm?HZNVh||g=jM8?EaqRoepFwd0~_ub(y)t#rR6EuB}FrgnxI}pDQjS0 zfR^|Td}b2F%KtP)Q!nar5uE9&o2?s|@|j|DNGTQyucJq+kYy3s$PmN=34j9P8OG8S z72klnURz?`+84Y)5mMdR`K;O$DI25)Nww0Vq#~P%{O0dNIB-M=z=|T5EbcRK)dn$` zPg^vX$&NJNDD^sFYn#xre08^|VihThYfexFphrsQmaw45eQY`i2{qVn#Bxy2Xna(? zdE<}WJ@g>_NLyw`aZarN^33LiU!u2od9d_r^WNoYX}?hQK)v$&*DtUo{twYC-HoCf z`5&0oZ+Q|ke(}*Xit>5(8g1z*CQC0);Gp-1NQxtjNj3uSfX)P!UG?^@j_%|M+J`rS zf{uga1b40;Ei(w2iNO0TQ9{%5=TGyMMb3hlLr34fO?XHF&Aa3=Tif)ktSoTw*dcfp z>1R5ijYT9SA2wKIT_~9Yu}OMxGAw#@41N2x7JwhmB2gbDd(v=;h$dSJD|*bve4 zc{g!89DV;UtyR!DG3?MZcwbC;Yf$R$fDZ;U@}QX=u=<_QUB>(r$p-@#ujLpruxU!P zlzXaZXl#`%ML)PrY6F`lKLkAJ#h*KRQ~)iU?&DON7oc+oX3oi(1iorJyZUnv;qiWG z+Uf+NSGniSkdX8#;^C41qkV>p>FTHT9xL!GJc<}> zWZb?X*=H7{E@%Y2ZnVe;nXr#|XKhna#-u`U)rZfY-M~X0a@vK3irb-ifnBv=w?H=p z=pJ;EB0caI6R*+HT4QD9zgCx7C|l&uAhG-?^ZMG>=86x%XHG-J;-EM9pcJJx>;&ir z2oV$`asi9&=l|bH(S#Y!*nep2IYBXlq0isl6)~<`h(p=#lctQp(->_7Uj){OjJk>0 z*^SlJiKV3>VK){Rk6PBOEr9my{O>XHb&F=m1NM$_hHelkkPCs_B+Jb;Sp#Ua^9BZx zj}Kzb@4s=g=a8rv8b+}it!w!TVGZITG9kiK9EJ|z0^H#I$ew+3;zz(ys&glZ+N_;w zk06(J8*YqdR_M@w7f8{hr>BQj9=-|Pucr+b26}ora=Hs{uljO=gQ@w=(SFeVIXN@4 zBk*dGVPz=HI*=JuKuRf1axi+ANc0bw!G|iz()mY0lL~%qXW;LSd^O?C1=g*%naT0f zocaxXw;?coK#op2%nV;pdVJ*i4wu+r%OGZpdUn+YUZfBj2WMwkpyNXupc|azc*^4z(F6Ru&^C% z*w$9GHHkxCV1=;byVa&7EC4$Pvuf!C+XAqnPV=qQBlpP@02R~g9lJMG?)ib4-O5BS z?DsC0=%EHu^UKb~b?)20pAB3}DgaJY+Gw7!C|#urNq>UQ9smJG33f^!U?OHO+1poO zFckBNNEg^sc&R4S8V85bPt4Fc{#yp1ySdpqMy1eDWKEbEFxw2aIjq<^CN7SDVRh=9 zkJpteS0WDR(e4c1fGO_(+C+dTkV9hKwNQj8ptD7?sxmUr^N@ic73Ujs*sA~%zW`;M z4u^NN`B_)M9vAwp`jQ4!V7Iru8Hxm~_Irh&0ww|r%GM`2P$hZp=34q$Bvh0r-bD~YjbPI+%>{&!!$er<1e#}=@#kV28#&z}{Xex9mM z^i}+dmKaDZ=*71R>+Q!hEBVdO!^2r3KiXjo5me)(i7wv~n*XT4*Kc(V-NXGu{JT6_M?Qc|*n@U}GjYiN8N@X%Wj1cBW|Wu3WWZ z3&l9PW9<8iBpGPJbruUB-5!hJh2xMd$kxAhUtTiEFP+;!Vm4^N^m8q6yWl%lXi%j3Yg0 zDgr;D%ET_Lto-eEV4lGiT&NSChoog;S8xk z$yv>#)I13P1w%9KE(amw@87n#Bxc+N1k6wk1%~0?biB2mkzbxT2b#*hBTp5*1!3WI zh_=W*EJtSd{rkfWs2q--kPwKv&lPtGuYooOsu=XvAhF=K<`v8WO$bYXXc$!%#(VHq zBJmA$PDhVo&}h@<&9F8_Sw=zBGu?rKfv^=)F6_F6d`Q7g-Lq$Z4i7(m@IV4-7TP&L z#@J&RpGLtUdEfvOw=^>=>oI&d3mQm#F^VU&(lL^QJ7<{xF0ZMDZ7+5mdzzABb@l50 zXLtW95L&qHEWl<@clY||hfBbep$7(3^iUm2LrjeINN{gp;M5tKPZ!=Em&IORcfU68 z0C@^CsIIJsp&VskJFBI5vjL{RbUr-N_?R@vYU;>z!n1W28Yk&vret(hB6h+(Ol&Y%gsZ*Gu zIE?;6+m9pGC|J;chh<{pel4HhB_UzOT0S?n)0c)Q8u$5GJ;=z%C|3CzJTy1)5FFPR_vL?c4 z#{@YvBJD_@px7JL*KfS{c?csset`VgzbG-Ypul^M3saXW8@9W;x^9v=R+YR-38ES_ z0xWk^BpaX~Y-ZgJ$OQRjR$N@=pd&QM)$H^HC(2?IB;xZ$j)~8n82}}DMg3Z*+EMIc z1Lr`u3p&spMK9W+FIiZ?uz<=RW`^qqGK%_mjKQatso@`I>1lG%}#SA?pO>I#}6CwMiVU1at~cUir77YBo2Pbt4_!A#U{}N3OwC zl9G1A1SY7q++ky7oq?JHo&f3sRK{&sVl7Yxo>PHI8KBnt!#P+nc9_dU_x=uWT3V06 zpo2m~ld{;pTfRdd;uA=N5f>0VD=RA@Oav%qZA4j%iOGG!!kDJos>=HdWhv6Q6Q(5+ zm~@Qc-Sg;lA`oCc9%ye(NkC}kLiGa>yGaQGnulRwqU)Bw9}f8VG1Nn@jKL2ud2eohOqNA3 zfNZBn%S5cv1_*v?y*DxJ0TkdZa03@RyQCP7R?GiL3qJIeh!Dx2y1V@vV~?PZ90SjK^y1IBm2nK}q&A%}K8}|p*fhZoyflv=2w${?F$4LE9^KiU&hGG@_fwm=@@7N>O z%mIRMumWLVZk~YdGRzy{1o89Gqo+@W<~MbKs4cMia@@KGpzj9=jKqRML75hL%~SAm zRH&D8^iJI4u1u;}R~rq!#J02G?i!^BaD;V;L_B&_Tv$k|MWH%<8%WzM=M3XKw>BIj z*l_)JfW_F0`3AiM+c>*h68EEO9vU9Tj6^Yf3RX{YEev8%eqO#jw7k5GoVlMKII=bd zQ427z6O;eY258AU8yR(>jpMgCvU?BjYxU+dAElFQi(788#C!%xF@@IOBA!eEEgu4V zY%i26?I^8~+&~vKe_H3b3o--H-FW6eTwELsPD|bsvH{VGWi(rlkQWr6q!4l6N^P14 zID>`(sYTtsUFr1cyNKSF(*KENKwy$R*iY-G27td%VS3AxA3x!>?MW81Ee15mC=|)(bfz0~W z?7nleylEjRcrF4jU!6*&c7EczCwPd)|Hv>TAT+_QD9VxYoJv*FV*bUEh?P(S@FuZUQ4yQTkFkCSLfeN|Gr?|nd3-J#ZlQm z85JFk-u(ec@R1zXh^>UQG&LIZ6F^^~zyYuL8;s&6ZwYNhMTnU>s&_!N2y`hZBJ%Qa zoXnHLf-I?4S<}Hj!CQ5@W)G@1#u)0AxY{AQA&cF^sM_Qh525l2D9{BQFDhst@@KAF z!j%6@ya3&pIfLHiCD;3}U(cc0(Iz4m*_H2;e?fWovBBIlHoH^tLk2cc1@GDUv`tM- zeg7?7UQ>BqMc5~IWIK>#LR?%9vIb;@9r}t}kWZ}!yq!O$0Il}ZtWT- zs!}?qTO^fP>5{QH#>(*gm~<~Km4>dNC(SE9Sy?X>eBSciU%$G+;Yp88fJ8@tkI$c3 z9MdVNS|HmB+Xs)rq>QZ;gy)4AFUac;LkqwliCAR@T-WCdr;mM`P^E0|7V zU}UuD6+cDnWM*c@JkR}y50P}|(7t>1O+3$+B2QQ^n@>XG3kIXUevNc}v?{FsY6qIR zB%gfUo5Jrr=em!+;(eF`LvFVP*Mr!DS_2l&$AF?@wWce&=4kXP6XExn9;Bj5{3AvT zqGcEgoTHA%cugm@VW8X7ux2Ci^vi>+zr@Q^{6UJgD{txE|AKBE`kB5G?AF_$A z;*NPT=_&8&UE%#xV*Ibo`6pjXL%+(xb=B2HcJ2BJ2E;v>a>5NFe@r^wymJS&EZEKU z<5&O1+`01+w+dUDWE@c78>3tvh02a>F?|^UfripXstY3kg_qHzZ+{N3@)xb>ejdg* zUr+|&c>&j%Awwz*3fj=syG#O7Dcg2Z3|&gOz;x~8QlZp3>Z3k|m`upY%}q;715evo z=pe9mMLf=A897#xv*FvfqJ#u2hLE?Ee43VK5Q90oWnB{e1IXl zSST{_5R`djd)oC%q!c?~U01KOg_YGUH<};*P4aL2&@*6BLRtGWU*ilxh&%`nFY;L` z2n;-?qEZX)a*~nys)myjcEHKTCM`I)2Aa@G#w0HA&ibhT5la8}0VJTZ=5Oih`ZGFO zY~3nUT17$h*aL4O101DUfr=F_kK-&f#}A;%Yi?=5Ko)yfjz4Rpp7mVd7|#M=omkj_j&r{ z3B;}LtN(m9-3oL&=C57uyK-B1d=VpEAg$%YcFDXv%bnH`heviLC4DuZcYjFL>)PS= zYm1|UiGfXKrr?hC;uS}FaT^%;Yscfnn&&rA5$``(a;cg#l4VFV4T4hDL909!9Q|B{JsANKAF(v#a+ltSCu z7T>73V|&2AMLKZ>is05E7%B+F-uyxA)wZ~V1ZU{LF*=719ahuX-tJu7i@Hd`eS%LU zhr;y`nu2&N5!7&&mVzff4gPZF3v~^eCJEHG+7pwGQMGOmiYl=g(G%!bfB!l zX%jscf`WobW$~Ahy=T+O-K_~mdqX`+x~Z${-Z@);7o1|}t4nlB!{`rcojq&eN3Hko z-Td`S=XpfM9kZ^8{(H?+6)8%&Zrvm5_0GO0D*{G#W>fTzpLw+~9Ui#e+;`oluU`*} zi#q~vW1m?!1)O|9_;=ZMm41WFDKqm^TiYDCf{kv= zkSof{%AS2D!2EAjBWCebOL3QCl0YEn^gP$G^FO*eM;;ow(r5kk_3|_|o|hfd)>3L} z3R|Fk1tbcI(k7Zf#3m?``rw29Oc2(i;u=Ak2kw<{9mE;JOqFTSwp#zS@y#0u)&FAR z3dKEK&f=((FynKR&!Yz%fba*Qmhz@%HhBGn`-N;v+6fzP zyu!npFcVGs)due13%^?%t~KSQieZ$ic0hhKYtvM zAl`^ID$&e7IRFxflvDquZgc!9CHpf)*p`|laF2xWbnYvqYu9M_+k3B7paBI)=X+TB z?Af-iuJV31&bvSR`lc49FZ=kcTsb(12f*MNGp!K4WrM#W#c_M~Ap0_uFk0~{q-JES zj3mWaN_N2D!E|1ClcwQ+`SL6V@KzUpiRS0qELo<0`4?g&;yPOP*UR%ww^jGw@#J)R z{=oO4C;0hm8yKiI#1}{@v=f?g;e90c;}u z+`fG~)8KVxMZ>432k4sR|CHeH0m63d+$m~YUSDv*r!3+0g%dwEbf_pRSK}5g0YsLS zd3DT*y~)yllVueXxL)hb$WPCsl&KlYF$zwH`5H0wTScPi^fX*$r;t!bOUt`L@_`vJ zZS9m6lv1Fk9i&eY{{HT$sG;wN!M2 z-W$qmlq{YVW1ypWD(vj--JG4%lau%38H>4>nRZjICuknR6R^O@M~~+2PxA*pm-7fn z^ue%`nu^M>liwTE)bQC4pA;#al66w=+)=}D5vhE9jZ?cGd>8;->h9$QQ24Cvf&=yYOh(STQb@5NMY}q| z1dJRGUC)gNUPOn7$EBxxHnwla4(G9s z14c`M>xrJNNI>*VOn#8I0o4^>q45G+U|_%{a*g6Ao-Q~Hq;PEeBqoYLueb+GFtcu~ z{_(>HPx2sB-Tn@0>BQpVj+&aJ&!-DRcwE8$Il8zYRHCIKzJGs@w?9D~!9a`ycrHpX z9}2#5($bG}{0m{vUyAJfze-9;;qejNdpoR6O#|Gd@m=9~{AB2*O!t~8g|ImX4a`b_ z(8q)8NM#N>AjZa@=MNm?W5(nHGz<6>B2I|QP@gW$Ofx_W76JzL;X|GA*UBeOR6q%= zo&>auUxOtiN1$X`))DKwFjlvM*nq(tj50$jSCE;>$REhlbo@mVz$O6k7caX1Qrh>M z5vviAk$%hblc-E^0%>TFWMy5B3O#{Eti3SG3+*e`a2zcc%;H_?1iwCwRpS{Ru6WXf zNYLlNzvC=lmLzV{tR$xG71?pjxaieVz^9Lo_??{QsA^bMmZX!*%jIEo0s{RoX4u5a z;dO>*&NyKD9xKGmWaHPbLnZx|w~ob!gq(^okjd_S0}=%}n%8$8sOjOGjt>%e7T2wS zfVT*%7zSoxX72g*YYEMWK<0221iA}_S53x0pFVXe(B=JMD_h%;yQH9u1n?+g7MG+z z(!K;#OiVlgN&-*e`#r{oCj$ryLaqE8wJ*?o@2MV2-80uj3@`q3b^E>A++6H8-@KER z=kCwXmk*2loYdb{xfKt2BKs=1D#{v{QhAsVm?^NMf`WqdTvFsib_@-<)f|SMJu&?P zi8F#RG6{LW*g;f*XU$|Suyw3By;GmBm-#}GLWy}wd zoR5zW;q-L(=qMg17u9yP_zx)2zpkD`ChzQ0hV1C{h%sYa?d_Sr_Q{a=uoV9WvSDXq zbzc(~=66mLcHqId@ZubN5P;pQmoCJshSQELZ}yxyaPNg=PGBAb-0b9(0-*ie|3#le zhYmap8uYs^Hf&_!@$p}aMvhzKbEG+`h;&2Zq#uZgcmo)NdCjAzq9*Anf9la?=;`UH z_;X5`mf{)246B3gFF!y3OoVBDAA=}@ar>WRb2>eG8dU8Pi8h`qss<7|7##fLZz@-? z&c(%T|bBoEc%|_$`6}lPUcCWv&O4X*-GyViRr@44rvI?leNK zfu{$|J$>Nnwa{o~Zu_1&?dnn=-262HOd9Iz&lb8suP;mArr|Xp9`D362HVyFUs1im zk2c!;(R8jFd%YH~z%x2YN2);lrM53PnAuE zUFo&eSfI!)UHTTM1zxNz=e*D4H04{V6lH~6yEchf$B&fi{P~3x%HRL{`Sy*W($@H; zSO0nQW(iIf_4RHH4pKdYU;+}a=FgojuFxwhbV;FRH{Ly|(c=q-hN2Z(J!T<%C{NqE zzwi1W<{#Dn{1ebpwIO)&?NhDYol0+gii}SiE!Du-EYi0)cZZ9!~%%$xca7_$$`G1$t!`i$i!{$ z9*Zl-iiteeZrJc}bZZlu@(Xtre|AwkX!`WYlY!(QlFx3i6Z(NS??0E8l~Hed@um_r z9G0U0TNZrm%jDg`D^_-Pt~XFx>vHzirqJ;IhYnA7b{_m~p-PeQFx8kE;MlKU56E1; zbO|~-$|1)2g!Ik4eLg-NjDuuMsA#P_;^0(JaYvk3h7c6-1+5tnJXRp~_8*XlQS=Kp z5d;C*o!!MqURmxX)eZdt7pjh(hRq6rBafRaI*o=Is|_LDQj&ef|mBnKG# zM5rfuc{vrIiGR>e`S7O$Hf_Dy_Ook1z_zU7ir_zgRB9D(+vn`VvyUGYf1VRf%S+Vq za8YmEAms4F=uH-npPy}=0+8c7rHq$@ethYYB}0VarRoQYe+Kd2J^jv|bI48i4*YIi zp2hnF)a$X_VUAiTeq=Neh`!sPYVd`7kHNJ@)XP*2uMu9{)Zb;G2zCq34OI(OkeC1b z=~G|OoHJ)S2=I^!-7|oWV;swkA8j)$&q~;|mA}Ws;Y=15CShRk`}dd|>%P6(C}-?H zZ2T7Y+&_Xu@e8Gze|X;N?c3 z8=_vmr%%7b0dSwpI+QkWUpOt(rrqP@Apl=VjOFRJ7acVHh)#+DS<-kDK-zoT`W-qd zw`Ftn=k%*%&U>FW876o0U!xQt8ebWr=l!2|ad9II+HcE|614GsBlHj3Pdb8HK?M=C^$PvRvh99XI)I(pYs_Z285Rve` zrLG^lWcq@cGY=+>@&sz}G=H|0%HWobK>{Ywk&$cc?2bf6>TU`SedMXWTUwMY7G?)u{m=OEkECu+kIjF?fG*(Rg`~Bmo48dXZ<_2&9#<$%Twrh4C(|(ikL2ii1wcA?TDN^0LgIyEZm+{*#7FF{-a~EV& zjWPjfPTRXJ5qP88AP4*Lq$E|jgW7}UVj+glCgQ_)A-zQ+8526bx}AD9v6n=0*u-6W?pyI|sVMTCnQJ+02A(Oc`9LoA&O!TKt(Xv$herSHc*|KFl zMJ>lv`t=Yq($Li%aH<`I+e`{`Vuw@Pp*!slpYkvPo9dL*)Q^Kk@qVbZ*riCj&D*+l zVnhXIfhzv-i$*WGjAC8(N|pc0xT0$9LA4Y!mEA)tB9 zl!3MI=$IDq0M=~W80-<~CmUdbF8sdXq37BU9yEVck~j=PnxSTBSeBQ!o_ogV4w917 zgk^LpmQ%Zl-1;?tNPh7m-Z#%hdwE>!+#P%Fy}AStmpuf^%UxbvAa`6-cI`4UIS?w2 zEB>?7`h6En6^Xv{Kq*P<)z{=M`QKcCVDZLj=-ay$8Mji+*`!t~b)7AI{C&I$SFZdE z@gz_qYQa=0S4^$^=e^xasK^fF7XjDfUME{Ob*l0K(~pc2>x0i7PSMU7YS-VjT9mPO zstQ&-jg7R@pTKjIJ{AiOtwBL6di55mNO3pNd~e;d1&|zNJYj6i@g5* z2d|ZP+YjLoh^chptdWG7*x0@U2CQ*%>e97SB>KBx*|N1r-UL7Nz9YJH>0-A=Q%tM4 zGOT&VjF@=!6+0y}4w%H)9ll6>fY&B2E^bh+MO{sR#~jDZ)D)kJ53)l=z9IBFr%s;C z+VRT_%^d2Mix(y94v4b5-6}F(yY~F0lDly!x0cSk1SlAL(6sxA=m}e#?n+3w!b#sZ z_P(QBkeTBmGqBsg3>IFm{r(Qm0?Ns=E~7VLn>WTw`#3~pFF==L&ItH z>$`FJQQwc#eqmcSB22$;KfC0QA01q)1Hrf=I$>E1^{1UpN}j{)HSy!F;%($)S__8f zWhEs7OJL3j2Eul8=bqL};youO@nu1I?^SojZvel5P)6oNn$*sbEGjkbA8^!RZh;k1!M6-Y>oVXYjy@eEYsjDt{j4H6bPt`cd6nkMs*M;4v-7ERyja{nI~H zRRr~Hi+0>2DCaiX+lPjSPr}TFNZ_XBF7mb8(bAux>8nlRx|aIkZYMC?3u zk{@Z38$tM8eeu$vLp`W3p-1rwCRiu!^_wP*;K3 zx{{W*gBc8n^`{tEesFi-77}VFmYh6)zKV8Sn0XvIqDAXT=6G(}Ta?={t@IZ8;lKKe zCLzO7%sYEuo8%u@8rxhidw^I#P-@4HL_ryf;X`CksHN!qsBdVxwsIT9_hetp78C6q zs;NmMvV$&;+ztU;$-{5H`Y{3-^=I&)Nfa5E{%%-iZoYZT)%MxLIF4KCvPqjTvFP~y4F9f$%hWj(hR~S^S_=8?~!fkeKksl3>W}B&_RA7 z{_pem&u(6Y85j^2Mp;}vwH-2$+LUodwAU+FdS?eo51in{z(nhH&z1pvFz^ZXEix7J zeX~ZXtMfk7{KVeA?Mdmoa`#yNdNB19g(7B6waGVyGL6Y!`;nxi%_Mbti^SSYnwB+_ zJw?7E3`&I&jiY01SlB`r7nipyS91y6i_Cs*Fr1KDI=gm!eZ!fmb~nh^aVw<-WSsY* z?nGvbO6?U6e0=~gq ze3Y(_fYcdqhha{+U7fVdL(u@y1H8vBH@{u*&030&F!XI z_2I*Kr^iPurBTTZ(cjWV^%#%)^y&OL>sKn;AIE1Dzfz1$5EtQhlBeDxE>bv+6A+mZ zb_tJOv0p#!MAH~Dy^2aDs2_A2J1>9nsU{|b?p?6n6B2^AW&$1nyAZ(G%RmD^xwn|F zSfyWz;7$UN5)l@bV|c`vnv7;4DJ!eu!2_i1QMI+VQd2u1%L%Bu3FLzruA8E_@d1L) zt#4l&2G4KJlVXf(zH`2kE21d4XU%#_=K~`1<=LqLykR>}i9|mAWM$dJQC3=t`lh}!?^^5bxdAA^+XsO*{66+B?KrJ;;LQgH`n z1R)heoOAb%zi?s3vSn$XtX3{q@KThXy~U8X^-=%P;miY;)Z_{a7PJR#sMI7&UP-jQ z#>jJ}a{8{;390*DAJ>8JPWOYIQ^XemoAO1jri_RuC({P)|2q~24YfL*_?af> zDUb${MUQ{vA&(0CQKbnPRiY67tsbQtw`)yKSV z%FODRo{VKKKWPa??wQUR57IzT7rT*Vwp%flOA`s{b62 zQh$r9SO_jE=!9{vc@)^gL|sM24$=kVxUw=Y#;sRVY?m#&bnznR+~ZMy%3Gc&k@ZZt zb60B)HDwjX4pfA3xAgsGnsxSP7SZMtCf~e%J-(uvHr=4yN-Y#b-=n5D=E{|_o7V+I z0a`9UXuW;vE5*)uwY+>Ob0Tn`wE37t@wIbjbbb2VEFwbP;AGIXirbqVAuu6VweHCM z9_tM?nb$+#tx{C6$Gwh*f>LUl6g9}D@7+R)Iluv3yL4fX%}$`p@`xMX{imt~l4r<4 zu&fRpIG|1!_|LYc*_5x%n`dARJCCz(DH_wMua+218~N^`5H`0YvwiKLX_>?~QlSa3-)H=nq5*Wf5i(2!i? z-*oZ`a2a9s0cP=H7O!DP#Q1Th&sTAbwxd3nuzD7qeB7YflY2MWw;5Kx&2v%y3=&G( zDFnzR)KF{89T9e7(_m3{vO!R@lKvJaqyzN(47w4+J$!VhPm{e}_NHuwO=w|WF`lI~4j5 zyB77h(5R})%7#*TbY#kjL{{JQN^cPw{ACWBrn`L*w;5EoJziQu!e`9W{Cra>5;Rkc z8x>@~Q_0B_O)M5IYQ#X}s;-_zeMv+xZ`V-&&pc3Q6tZ%1duvs#VZdfLzkcbWP3u#m zd-&*4xw4^EgRVMPpifNyap7yq9uM$9sTiQ3ZARlR+1l(pF|+-vyFvJ@a^}p<$!G;u z6<72W-E}jk8}`p;_ND zrZ(@{Gq`e>(K=M@`SSwAJLytBce~f^(6622iebXqJNmzK+OQ!==G*p$;g0d(ed@I9 zMn;2GoiG>xy{6!Be0{uqQf01F>Hdb_zjGIC#dSxxB-@;qS;CSAiB@`3hoyN+``f7V zlcX0PU zmI)NklS3`w_SL4ZRaX3#BWGOGV`yzo*6Lxq^QBvwG-_jusyRl?FHNL?FVNryJy`>i z*xOO!dVIXgoH@PjoLt?jDQK`hETLPME_H9`P0`WPnzwjyf5|`A_Y}T4*7+(wdhtT~ zN}ho3=;&x1;c`fV$Z9mz)w2y{cEV{{GMUkYwwl`B@Qdf})I57+nPI;)enm1sx_<%P z?YpKJKrk?&?HMme)#eCFao&bG+uy!V39*bD(61i|jS5p?&Ba4VKy-ierX;YQMG zv79w)-}6e#nh@4n_5lsAVU{DqRxkU_CJ|<_LT9_}LrqP7f=gO#dio%ZLiqF=&OhpO zYQIN{o%eP(U}7@3y(f8d8jWQ zR?VL^{HDdl7+dygDXey{F`YLi4!CyprcdIrj-|PjXM_dIQ#!rNdizGwQBZa;?;v&2 zG0W%e#fcV<>G|(XAkk#2S$QkA6MBJ2UYydkqS30e-U&3 zVuR{*Ve`gw^VI3+rb%sp-CAeeHbPZ(Gqn&wU#RFBi>!(z`(^lviyG;zS2HLjH*hV1 zMa#u(vr|{NGj|*)Ba>Z`1-^k2iv@6k#fY=>l9el;RWx_)MX|qV^dtl>;4P6A?9f8r z3!jc27qB)-Lf;xgO!lAsIx}Q47PxnNwE)o4_02tFlvWnHYl!JEIl$l@0D5uvUUbBV?Gl{o3 zRnvlspW~0lCmrp@?>oUEAviz-Jg;DQ=-{CCJvZZJbz?>DBZ4eM=w&qlhJY$ECJ=_A zg8!-9Oi@TTNe9odWfRKv%a`vPs)?qq0jfh<%p?&#kP}M`K@uxu_xOC(d-a>K5*yg6 zsubd^H#=lY|C{r`%|Iqm-mrkHlMLcoXQCzbp=iV6{-eh^|6DbH&<6BrjRi4Z8$SK0 zJ8sZ_n|f#7I6iU}n??dmmL)mNu(MNHA{IP@AT)Z+mW=;t{F4bw& z+S4(96RV09-`?HbNoVnO zNFT!;nkyZ?#5{C%cHdt2ULRjEodcA|4-+O1VFGvVoSKOR<4{+wC*RBgO%K^M*9>NTX8y0^*orBBMPG3T>e!`$Qv*hf-@ipX~xAZt!@Ic*%POvWd8 z7@ZD^P5)8V^{<1ovkrD)z?BaD7bniY#dOgjL`Pd&ctT89T;IRUD=02ze#M@k(9oGy zR$u06{<-kUa@A?GcC9U2EanDXkk9g&F?_hXs#r-$OububU~6GDK03FeNw5~f+FDvL zZ8_MaGoDaKZHx6Q3E4XI34?Jpe-;T*ae&OfdnfGm`%R}q8r;6^X?L7aI6^?OkS22s zBlav@us|4RZP`NCNlS@0{^#7#*%Z^OS6?`BqJ*|}t*Jamvlw05e3{q;> zHoV}*5$j+r`YRoOesGcr0fHic(1HRa8tXPRUXTGxDtdO_pHypeTP7eN>DB$#UysX` z4jwueub%4U1KR;U78ZD|>zwohTiq2jMll*_^56~qng6)KG4V$CvY z%0d@y5+ZO(hNFG=)JzY^-_*OPbQndxgFUi)?BXs{?GW1jAFQpf&FlRhrf1*tCXh|q zGC<1msf@PT3+zC;L&#xNg}0KD(r_CJ3+wwO{gdV{X55=1B3xSPJ74@MEtPyXhbA8e zC(0d&2_PZGr(mU|f9_js{3|%Gg?o->npKYvD-ufLFJAo2m#3E0{Fd5y&{VCprG;a= z&tlk*vRg0U@CF4atBSI-X`zoksRA*_0SUsz)aTu-;b;hJ2B|gYtK(!i;E`CvRF#*; z`ufL?KX&-MblEcadG83G6uB4ApJ$|zI5|HdG3EMqXIUE4agD}WsCblz?5eF92mzAZE!l50EsWcz9eC{(rpI)LCX zqU~L8ON!iH@#Z{n+5#vDI)^hPpdf_PJ&@GiR94#2W`Im!_H@uJ_Jfk_^De_{r%Sx} z10n1pbbHbV5g|W+&Lnw{6OG+c5r)0Y;$eZ~qn_?wHgdQfafNV!^s509l>XMw5Jf6U zYT`eLJ5CdzapqH585^%+>Qr~YR|Jt22Z;gw`#1giMHT!{XeWpD3Hur*Ute==@vY^_MK_6p%T(N0XaT`7@Sg}=<6 zsS3r9;%RvHm&+!VfFcSz!A=Xv2csdhEOx3|qQOU_qc>r?)%1NS*_Zh!;U;5fn=-mr zflS(O@7c7pfps!6CXXLILe20T*$+4Z-Jrl&?AtfTQ2kHkl3O87-`0P5-n8UJ-CJ9) z-OZGVNz-q$1;M6dWoyVlf`DgdZmw9!tJ?1~Pza-c*egSqDdgFuAIwCe99pqNM@8B+ z@R;_D=)7(1BCqk^nm=f0YD(Maud}n8XJd2NL+@SA#BJ@?ac6zq-P6-n&Bq{l-rTvG zR@}BSyxoG#1U6=@-o(h)Z{H5}hhCK5mb7Vw8}45`UtUX&?2^)f;~l!(G5IJXcaUXL zml&&h?c7OML5!vYp64$y@}5Xb4~jBY>2POCN=s?x!s9wN3)Asg7d|Qloc$0QGl>%b zqRSm)_XtG~$LUu`yR3PAgNv=zpTE^og_Diay^om1+V@{T+xDeLz;DhHlP4LeE-NGl zwO_%k&s6Q;p+id+Evi(I^e}5zU|_nhkJ2F-Y8Q~VkCt&FsZ^e9O>{UfeSnGm&t)qV zYbC_%m>H6TrDC{pz7NE3UH8GYeb0_n%3q7&2%;_46D20PSzCiLl+_YEF`ue>uzc8a#DsHYgcB~%+E4?yBkvt~8(7x$u($mt2#!3HN-70EZ zjh=w~$&>@o3NjLevHlgZn_pMXYNrlO+*^*Vz{5V9?u|drMz06b6VFJ+l$I{PYMP8{ zt0Kuwa9iYEfQQ_HrzjSXyf_&{#eHq*HG#4LiHRpV>grO>b3_@B^YW%JM2G3j@*UN% zCuxBzWBjsJX0;15k~wp5O&}jq^;5^~-(+N6nmgdjDQwwEUYNSTx#?PG?WVQv6^^{x zxR;VJPn|aVtE!6C9k}h3 z_$LRuwXm!#AC^FnR-BzbgB{ifAK3IVizOXbO@ATqWKg5a7taKT1+IeegDR!7<&(7V z)uIKn3XHi;Vi2hjU9+FO^&N2F(4l?%_ao4pq@%NZ*)qfcLAfa0N`@te z%ogI|Zsg3cY%6y|aYleaA;hCg$2JJ$HDl;Uy?a*e)HfhiR9ToTy`%W9(Eo7C)~x-1 z7j*SvN~(>BiZGH`!^n*va_#l%n-(%674T8C7#9~@0?45l&M_P;G8if&MHR(^(+V7Xp7O1U%7Ve=B-xfu613{4lp)0rqwZ*YHe%dH1tKP@U;+-gZUK$HvXT~P4CGE4Z#N%cG0hG z|NdHoumb)9f-O96!y|qkc3~MtXPTpocF3s;bm$?YQlAXv6rMrjN@OQvV-v$Tt*3A{ z^kHiP^Yq*^6`4?R%G$oL>kGPhcz9g(&U*12ts-ObJ#O7&{AV1d9;*+&V9q_m*C4>(zt?lQXZehe>2I5xnug0AWQz;Y zS&_%%H!#ZbJ?}OAILZVJuIH8Xhl1f&EmUvMmWx~FPywOV@6l6_}dEM;YrtqN=T$mdN_<{ z=Q%h;x`~6>-rB0_ud}Hl&|}P>drzN^o;2z8)2BVkD#&^Y_$;it7Q48_ z-@e^KM-0it@f0J@ud<1G#CrvtkHGjdUfPnan!Ckuz?cTlWdtPR~^h@Ji^`52OhM(*v zSypj}x1PZpQ)libzOI)`fWP0#58kl==N-7od*yKWyo+_NI7UK!Rk zmH~Od$kOLodqxHYU0>#B zIs<;+&qmXCqhx!pRW|nAks_`5%}?%`1nf9aNVYFeA124C&qSruBVaF&D$y2G4p;?D zSoiKV;naciP|0P>qFteGw@yp&_rEEXbnR&J#Sw=BtJZz)Cj4HVT8(kzf&&8wvvGd= zc{v3wE2|d>V>|!Z$NoPR(M;26iyT)^q3pI5$_`Ue;zC&J^nj@7i4-SJpT2tGLID4} z8$1hqX;UI2-~Rk(hg4{B@y|c4E1to@%IWsvO#Z%bm+kKE{<*3f82tEnyU!n>UXa zu5Snx6pM>Utnh-UOi862W|1yUnCXI}H?IvY|KR-Jwf=I_xoSGmL~53Havna(^g~#% zwV|ow{G2{LSU4mMA{LY8f$GSU{4${$ru%Mr-Tqr$f8g+uv8vMx_DEQmc4=*md3{Cy zcs2#$Wx z33*nHHn>k=K1}B+aHbY}3*Y$eNiDH~iXL14*4ivu6|CpcPwTw59*j$y-&Bqdtm z@e_adS#zo^D6Y1gU#9cnQp$Ds>kMb7mCG9eM>G8hq}8P~V8TlcNugzQv#?vQ<^RtJ zyuYmMJ&veIvGQc|@DW=^*M8biTxvYzMAgGt+5}>h#=YyTB`@K$3O5a(Dp*ZD)U;}qf>Zoj~;zV5Nf^BMY67+oBocU z!%SQ-j;POz8W1>SvH>J+rbw9bzMwAKRGv=!v2&xNU@HcYC3|ZdfB)WZ+fyVpq@!ag zRR$Y1f@RV@8`LV28YM#dxd9D5dH$R!H67+dUAb(P;lum)?aRuSig)kua@>vDidf?J z5DbBNk?@`Ru`WegH3dqqe*qO1O#g=9fKl|2qzc*=&QOclUSgex z$NuzQMl%@Z0;S>?qhR8~2oG*t%sh3^Ze6>qK*ovMlv0hhI0WM@4><0YAKFtkks=vk zJJMB=ZR`2vMmG|LPKOtNpWHJe)-P-z;{$B)Osti9bD`oI|3fJ%>ek?0y1zrIzGv^= z4-I85)>|}12*2glEuD^B;0HWaQW%R9WP>#mx;n@vVG&7(Va@5E$(l@b3tUdPe5e zhI>}Iulz0Je!G{^JII(2LD}sy96*Rc@w)>dxiV7zt2!dGegB_x0tl_nxZ4;>d(6S59%&@bWkJay$~- zdF4gnB@B{jQ3+wtT`IDky;s&2s}n3kC@5zRTfjt`aHir<3B&gwj?ySXJ+J50qHO-j z=$pO*kpVy=XUFO1_>3Hc$iT-#mb7xQD{^ph4#DO1`jXZs2 zU{zxuz?RjDEN?HX7x&M+yeaFNeYI#q{Qgme3AdVts7?%W)NORP(X6$5@6cH`YW9!6 zi+xvNo&O6`5FboLhif7TF*kC7R6mLH1`0N(X^d7!@IPIJ*>&w4+7QvU!V4558?HLn{&~M%4#Adcz3_E)G z@L^n*X#85$YI8QHNM9)vAAWLk?yl|kAFrje$wKb|<&>@qvdcRtxZkTYGxG;Y+wBtdIQtjJ_o?nQa4Tvl=TrtiHU zs_t68NNC4t1SR)*U(q^<;uvQ(K9U=Xqld~D3BQQr$BW^n`mh?4PDa4!8ynwa`T_@~ za;vfbn$p}Kwk5z85U7~)GAYTBv9hWkTX|o-5dF-a*}&C^0G~6T)Ltu>nu%OSdRvK# zN$2&B?S)>(PaQsuxqr)}<2B>~_}&~l3QY=IjQEA}$B)xOpyjxErGMZFV!*hcaEkIs zS0YF0*2}C_M@KjRV`D9L*SOER94~)SZebQJF!ycRL1!^7UTiQ4IKuzUuPSmgj}Pwu zU2nnTUBj;SN^45#2nnySmrAtxKLaU*AdE*whCLC|>KcI?0*WzeRQI~6o_(a}{Jc^3 zD;)%S=~!NV(# zZo$>H1_l!F@BveYT*dSa=WUegYIOD`yil_Kl)uI?v-75VnOB{dAAJ-D$lT0~A{>1E z-#+4i$WCH(ID3d+7RBPe#8uWUZxp!=uN^8Q6IJm^OYsx5;=5B;-mP`F@~EW&E7sO6 za!E-njO{G)%#G7ZaPNKg#gVpM4z@I_W)~KK)LRT&usb^M9OQrSgD%@_Jf~|;43A3q zy(Nyp? z`Q{BMfk^TPH4<+N2Fq8#We{;`etC-D&1>2upv_Ys8oHh-d2;x|zRcZa4GwXN9hqNu zc6Qus{WU!|W)fWMQ7 za#DZK5*!EmEwpnBF5)zTH)13KU*g2^NRT|FI51E zDqK3l{sT^Ql7j{`I3dqIdJ^L4oO1n2!oql^HHW+`(ugLJkxNObPF64WG!|c4wp~*? zSEKe0Q*9Xh{8s9>w0Dy#gE7?_KXRn7(~)Dtd&uWzOo@8CEnZr(vslmI1%<+;D5bHil` zi}v*34@vEFrLKpSoHhMrC&w^y|*UK7`#i|yJ$-mMZUnc2Q z9iWu_`u5dY6xDf;A1km3XGx``loo9*u>tSzvu9P%$-;xVm(pQ}t^ziQ&^Mv(f!vGM z45&rq&1e#Pxsjn3NY0$j?_3$8@^RGlRZypcQ~p%IeTZ?&GD)Ec3??EOC~W5x_tP|yPwfiO;?CTKXpiZ<`m zlyN0H@~%=BBRJvI3+)Xt#6${37Gb}svEmk+>(TXhTt2<)gLt}|Se=Tbf6gY!mG83^ zmhNml7x$&vJ@mwn^vsuE-qx@K&8JjgWneDMd=T3=w`&Wt1A_++Df^uQYPOJX`ug=G z6_vA~7@(9|v(@UU1^B`Y?Qzefora+U)+q9q!Mv>$T%Q4p8>slkO`n!9?ukZu``%vxc?+-h*+4x5WT{t z`Hu#!S6DJ(3PwF-1G>k%ogJs4m;)+x~5BDX-k#=WPIxFCp3=Mk%6AMGRjIid-8}<#DrTuG?rR&f7pFf#E*(5mx z@LW~p1eBW+DhPF}xZ1G7-Uy4_w+IWd%}L-;JAfN>Nbuwb&-(8{&S zRv$`TATTb&Kc95TJE&hiKp`>s$>2}l6Kvh~5_Oj>iNHVyWZ}dd)>n-lBl>3moem$! z1iGl`7e+=#O;6_R@B$EwV7MLSTfJZI56u1R10lHYUmRg9#2+!Dr^KE*Gn^kKeOGMFRrkeH?N*<9)R}6@$nKQ zGZU%*p@r*+U$oB0$2j8Kg}Ath3nu#)poU3Qx{bh5&rHg*#BOH0U^420!CPqxGrkq# zEM-Q1DlaGZ(Ph$BV4?U=UE3gO^)9P8b^3JRhPsCOb&27BEE0x)YD_)3+fU|`oG`<;iD2WB7o*sthma& z>#qotpjoknEZ5ds>hvAf4Ok>+2Ha!tH*u*{n#}UMyWwd5rC$cgFy8#J%bZakg@zuI zYkxU8;sm~6G|AZ;vN$x*sh z5+5{?kajUQdm$)DyaB%u2u9#|z#%vmlZg|Q_?W}}tf%FGK0RGAXe8O%F3F!2ZL zz=REa@$p~jhJfmTm>PmzWMT?k5Y;d~?%TgV-tanAyZj<}IXJ((CAhN-YCLOeg?{}~ z@B)6^THHtR#rI2nM*RP(XscTH^q8Wkzw0i?#iwTm*~?t;X2JrTG@W#}Zr$kLUSHgs zBB(9qsUJf}d|&p8?^uFtGle6w!Qx_T==$WajG=@2#V`8Cr!rj795-$VE?M^Wd+>7d z!^(y)VjeRu-5dTBoa`<|-e_2=3+ zM}l6PvK@I`hU35tg=PJQo^U+8vCKZJK}=KIDdW(YAAdS;dZWj&*OBkwQuZ%xp0{#k z&_BBeGcLNH_UN99Hhnmw4#Bwl{CR~zgTN)9p}43!+hrk@9J)HpSvhAY5_L)5!E3HJ zIEp{mRq>|5@?KsuB^9Q;cf6%Ea`o1}9QMPkOL6S?g5|jlI+lO>{Z7fbW$Q1w`2K#G zEt@y*z|@0IjFoQr&wQ9CC=DFA1HX>c>#sNwm?9Ba!lI+uKQ_=y@ylGU&U3%k0Zc5$ zkWeW1Nb=+vMwE#@$7=alR(gN>_z@~071coV8Y#C4ulkC4o?wDU)-3MBi1ig7C~(!? zz2dH1(TH@EC?8Z@{U$Ty%VvkpO}899|JKg1m_FSvXncb)bt?$mqukuO(wm1*{bgdU z<`12uxMKikq6vp}8U$EO#hbh9O*1vE;+6x%lrczxRPhsP3R^Z>>>VQ+7(=Q2SGg5H z#DK%o)Ou`VH}N~q!&c!;G+aE z2oaJ}p4NNwHQVR?|AR2UvIlU_E&J^Gj1S9%Sf8+B2Xj4QJ#XH$ODb=WkHSCaufo=y zK&NoxW?GcoP_xok?FA}fFC0FnW$yR)F5j@Xc*FY1+e)jQA(v8`*>Ijc_DNK`w=qpn zxHP1B_7I?m`|7FppXm*o z!-tRmqVv5jYT%aR`nxL}mA9I1#f~m2O6l%U3Adk3O{*&^FnnL^>{WMmnxFr;%ggB9 z6mdMjSp?Qdh?3!>)@GHoR(&OjFyAW|PG5PlZoB?&XEU z)?=K{ox!5mx4(GeqU)1RIn;z%3`16wFXnS&&DrlS$o+`Y7{^dJ>=@ikM$$VsuvbWV z1s0bxcLOHf@%ZGaKld*TH2k+SeEz1h{Dm=veQ;U7<`eqYZpA$w_mdJ~k>v>*BULU9yl}rk_(IBF~dr7H18iZ zYTym&m!nd*HXnPqV{usdt3PuuB`n-%JvXlH_!UTNW>SUkUEhs_54e;MUt@5KJ==FtX4bqkt9zn!^!{b>85sEywO$Gjc)cK@#}&nGx( zE{Y1-_M5tm86xGxx2AETy%P(I&7~kgsqI_-<)6vTd{uf_nK?~+WChJ0j}}$MFXQns zXR;>vP}TQ6{18K^#)bwgFnCJ+($&UJDoT!}^4yK<;_7I2r!)ccV&Xc%X{Ko3n)D=1 z9xIK~f9qunerI}y2m;G=m?(@PfWK`W#a*7E?`4y8PL8myk)ahjz2t)a1EYWk4?g^8 z>(e?zEfiD~2OO!Dp)(OD-kZ|d`T`v*R$4a!q(O1!y-B9Hx!C+uTx;&d+hLIi^%Ujh zBch_HoqBplCp~CS_Rdcm%W)3ef9H-Drq(sh6~4Zrn8Op~1@$4k7eEW(K-}0iVYlW! z!(e`@f$Oj#MxNP2V#rmFspX{b_l72-!02k>1g%){?rukuro_7g?@O{k`p)QWzJKqY zJ)71udP!yXboSarmoH2v=Ly?poLS@SKL7q5qBPjLQ1=H8Oh!tAjyOhR-5!YIB}0#` zj$OsQ;ZHvroXU1;Wk)@6nW@$zl-k*-u>QDWgJQdz=|qLGJ$oLeVuj^H6a2!sy@uw3 zKtAao{b~SQys)V%4e;{hYr)SjS^8?rpZ52i&ancVRoo08DEZ4b)o)^t$5$7x(K5<9 zQOlHp((j(^GrJV^Lv6g51LjLl9r#CKLKo-MkjORd$A_Lo9)~TnZn?QcL70_sE9`^e z!-fq*r8-7_jkEK~Qpd&2agh{|TH&FTXL;WlW%c3urY4bSKyQHyu;XU}^$6+Z$&-UY zJCUbNetwX5}p#V`X7jjx!5 z|G1}9nKUy=pSN_WE>kf|ImMdt_hZfI(`jpoD|%C+C>1%bfTAJs-Oi5sqxJF*J>SWT z3Tn%H;8t==B6`n;;o$Q^QV|SGITK}OP!>czcK>5_TNZ|dh`d71= z{Tn)SvL(_%nE?a#yPOl2TQ6I_yvNVW4!-izhcoV8x_wsmUqqZId%^&3L}Yo3-aS3VTAd1@gunFJN4*1)gruNd#LFuJChB zC7b4KY}Qv^7R@p3`RB=%06-rWK>dd3Jv#jIj)QHx4=x?qd}-pzJs~bjb`3E6Ja+2( zelvg>LBBwDC*Z!#+r#ZO8SpTf{_oL)2gIrEc%DDrwFULWQS^cMpb;YxU0NY$gD|4Kd=yw`!cZ_La^Nb4$)V zYy5l4&YuNGI4ubKYePd-UE|pLV%$B>3kfbeDc9YgyLijs%QDc%-@J*S0eo;6vFkv2zpLTp6pA`O0lr|Z*pomEd&%vGhpq)^DG->NsHmMA>JnqDBVz6c#R+MnpvD`26vVdD=H( z|Ni~(p`xReCtmqY#2iw0Rzl0U<<}+6x#NCb-r7I*>eV^J!g4DXaBSdHH0f3UJLB$5DGPH?qC5lssvKunGim_0n?}7GP-VbMnX$yVa|20y8tn z5z}~e1T`7X} zxXtC?$}JA}%3Y@FyZz#v6Gu;-!fwfvGCIln4|Y2-8avIQwa+c$+uGSM{1tdge6*uu z7^0266O~oZv)~PtBWjH6SFU`j@qKOM`?+h9RsXav#VJz4ZZ>d3?YURB>C zNMB(a_r67X3 z@r8gZjHrUiAjF(e?t9u8X!XOq?)6ez+779eJw^4Rq!8sf^$tnzp_0g&7)_qMxG~aO z#cHF>=XZc5ax4Z4avuE8qfo`@Uq6<2T24wI?Atdv^DUv4-T-)l%we+BR7#ZxdYi$j zY8CY##4!Z4s9`?RYeRt|5wq!{pzF6Pjxco}^;|V@8Bj>LV1m0m(QXeluj+aU(d210 zVMMnp^o;-k(QcD}U%b7>q`7CwHmlEv1r6|U>E*P1PH$bcssj9wuugMqcc{4NeVl^OXa~VGGi~sdN zLdEC7-jBV<&PS0NNxtL1e8UON@9#2uSc{)N<gg1@?25&?Kf%E#^B<@kA5MFl^ws(ky_=U&SN66Iya*mQO0lW8`i#D$uYC8UkmI@-a?WM2*5{Dr)1gY;Y*9k#1z7r!$9FIC@5g;F?-liSflU%{_v=Yvpu5ua;AZ% z?hUmi?N2&7&fooLenTT8kdYodnVtVU4OjMVEaXYyVhE)CZ1%tmh^7WR8{-{bC8wr3 z$DWCd96(qcHNEB&`^VUJH;*4{>-gJ>(}$Km%sP2;(8Hl8#pWC`RTB)d(fku_kyyh{ zWz$XWu0@tlqmPW-RsMK?OI6sPdrpb2j?ft?`1RZQ7AV*Fp_&sG$v%8I-tbnJrNA*8 zTTwa6A2fA+m5e80s*XrY?tu4T_HK@_Jbjy5pPm?hv?Y--$7igX>u9@W%TK~4hIlY& z+|vxFCV#H3#%iGzCLM8}O)-C&2eO~VVM@7$&c37bRz8ZhytpQ;X4V4zqk%@Vf}f7K zONGcxd-R<|WW;Kr>J;28Qn#2uz#wOdiHY$5ZjVg8Em!`ZV8`^f33TI z$gvZ(MPEydPhLFnZ1C}K5_YM->DW0J2n04(WSsDBJg2nw?LqgKtKHT+%$1UrEu_U5 z*ZO4RXFI&|dJ!=BJazSW5>)!T<%SfsK_MadmcZGH{TSD8hCunQUp(-oS6$|QiF0Dw ziy29k>1w-$&bom3(fDLLCSYC8jds9k^F!*cyqHVZu0fZqf1DPiFHMIXMY95Z)djv)7vRmK&Aj4lXoW^L%hd z;b7ls^ItL8gK*AFJc-4uop)Mx4~xEa@7aN6gJzyG9dRMd-TC=-_2hV7Kwf*ke(&zx z5y|+6hxgy~d*LP8XdWw1{B$($ybE!HsJCy_qxco*V#?2pi{X`KjI|CQ?w|}rF!=KuJpFu^+Ac# z(ZQDYw+$Q{=zk%s(fz3LnZQjdz32Q~Z(i!1);{~aWfq@&Iiwfn?|NR%S2^JqBuxaT zX)xX6O1D9lmfdig$$rdWM{$wceH(*g-%4+O->>XrjXe$X@LID1hs&EN-^ngpO(*(x zZ>#i^CZO#!ZLIWm+Ujt|?4`*}7yVJTzj7yS*mrY&RI9+34^&`M9#dY+aEUz9*?j9R z^Dm-4$0}i2@@Fa=?YT&0*XfQBO$|#7jGslUpw`7PALdue?G;7EzoD#?nLZqF7WLQj znE2IU&NJ}db1v?@7+xxGCnH$MFT{DuI z9RbDku|e7_Tjjb=q$PX6`!XB2V6_3Cf1v4Qkn*N+%Us9z6#LMnFnIK8tlT|8LZp|e zcDd-m+wlPTrY+pe#0@t$yQh)Aj@Nf^+OG=K%9>Znm` zsgqBxN+>*4LUZ7|r&h&KC+yjw+J#SEbH}f)ca70T-JBk%MhtvH?5|B+)#uOVvB(4|>*&z7V+~)<>^csB+3g zZ0ht4-G46`JNtfvWzUlr(f1BfRLtAx*B56{vy19LP!x7H(5E@CtIwUmJgX5YtxjUY)NXc>idW}$v zdIxQh){x>SWhp!b6ANPf#Q~Q)ol_|)X})l`LPfcDg|g_Yu!b6|#o>{y$Jb_{o>{#V z3MzHypcB%fz#a~^MN~y-Y$Hybz-uv~FyPzW6C0?`x|nNAC`6NW+tFJZ?O2cybx!@{ z#Yulpz&J;!d~w^4cPI3-HHQwJ9^3QvimFVA03aYyQ5cm4HZK+zy=N&09^Na7`z`a) z{^2T)q27lp;-Z2<4$;f;;$)-lC20LY2@57Rk2lw5io5uZ#~zWdu~B*}Qqd2Zt1{-j z!8FH-aZ6psCoDN`t2SR^t!^2;z&Z6aL2OTFy?K>dIKtc6qYfSQ&b;{XXaR_n^5DW= zcK$2c(%=OS)6iH?6oB0HR%q9lH< z^Bfzi^z`MaWjr{70V}L24;pR8iCi9+lXN%%P^E6- zL+-!nE;>8nf$>-hw>hWv8nDO4%i?2AcG`V3YYIwA&(5?j<~_%G=-(BwjVm-oUmrjQ zq`aV~1`f#}1OT%zxsMpL?B|F5%7E-t!z;gvi-}I|^NuY&GV200j4)sGcjsXwOMj^z z%YcsYt`!X%f5}9OHocYg19W8GDEI#^?Jdf{uCNEHAt@;p{{n5oG_hbmrEWx*VbIC;oe^)nw#Sqy+9y0yzlJz4U8q6 zh1T#^2a1!w`8`CzN2zk8Z&0PVgDm&PXw5bD9;Zd9RGyijm+y(V&_hqSW1xWh8?1-NSUrof4UNj)`ojjLZ?`Tf zdlP=GUM~D_##0jNAISQ2*M*lC@aIH}W!g`o#>X5>)$7}Y*$-W#FD7lGj3bmXax+-e zL%4>1oMiSY@8TpQ@_KqxH|_D2niAt>yz9h1>d|%OgVz5L{-ovs?{5^!Z;AaB?W+|} zt*Bbu;HsPhC!d;<#SMQJ3%`-J#7cr`87d~wG_A68uBq4IqTILvJ97Dtn5k*S9QwPA zd@P2^P3|XHzt;D8VEha=P6yLehos}JOPZEF+oF+CRX(Ev{0VVY)7Qf3Q^JK?mO)AC z2=9RA0<=W!>3|*jR-05iPu0e%uj9z_t}jiUrobQc^(dZxwm065&>}IMRhKk0!yV$o zNi5uMqWP*of=~I^v}(BUXM5pV&@c3ys*_Z1w`<*7&zui)|B)wtAoEp+Q}xVlA63eX zu6|0)TdMiHx#rsbS@;Tz7EP;JzxSAhhDCtR(gpsHt(rsq61vqMD7U zbyxgDKhHm=J}+1Mf3HecZkRaKdF`+unY~rr_yv;ts$wFRoDWwjT-zSdJ4x05cHiG$ zs`QU4^Y0XfZ2viEk>bk{`>XV1_G=%NpQbiwW^6%!KG^rt)S8LfnjZuH{U!VM7mpMT zo5EkwGBUCm(Q8C&(1_TE)5^Zv9W3(4Oqi`a^zG5*-o1K?RP;=H`=y&DlpKA(DopiC(3AztFXVAdlh#j+}2b&gm&A%h}KYV2{iRVaRV7TS@#&|;564Bz4`7+u` zsXvl{jyk}Ss17`djG@8P;SDfI7z{W&YJn7k8skQOAay`R;TtF{XRsUr9?i|bFuCCd zC}a|Z1b&0KK1@lVz#v8QvJRywo64Ta@4d&$;2;3B?1Iyac^fsHF1Dood$^tLi9Le> z8^{S&%S-!M7#;*>FXU!unC4kl*Uf2rCPwP^IW@(d^R#xYlxY7s?Put>;8gRVunk>; zDeq59KEA=%HUE^@dW$tlD}mRDfSmega<^Skr|-7FzY~_^)Rd)8`>b~=Z;3_GWMz$Q z*qV{|{{FzZcHgq`rRxzf_hv z-~Luch7*T?hJ5h985b2>b?VU`m$KPwlh}8j-M@-?T3M*6XJLfxT@Ho@VPIgsXiaLG zm_4yKdzF4jdcoCXEwikPj-?e(a{|}6FHQs=+}Y|H$6%0UahZjo0hrlAk)X!dz30^= zp-f{bu?0sDtkPg$h!^;MrD*ycQ{^OBAMt3H2lIFg>Rh9p1>Qe7KtmyJ0XBoP`^10C{OI4P-fhl57pG z_sUmP*!j;rJ=OOAa&N{N+#uh_C2Z?I@pen-#)Dxu*F|5o&=36YRwN6QVA$e((Iiab v=aHSp;RmWf0um8Vo(en3fmpiG9P#1*#i*0F@1Nf93sT_e>gTe~DWM4f*eD!L literal 0 HcmV?d00001 diff --git a/Bachelorthesis/Content/Settings.tex b/Bachelorthesis/Content/Settings.tex new file mode 100644 index 0000000..6197749 --- /dev/null +++ b/Bachelorthesis/Content/Settings.tex @@ -0,0 +1,418 @@ +% set font to sans-serif +\renewcommand{\familydefault}{\sfdefault} + +\usepackage[left=3.5cm,right=3.0cm,top=2cm,bottom=3cm]{geometry} % Page margins +\usepackage[ngerman]{babel} % Better line breaking +\usepackage[utf8]{inputenc} % Utf8 recognition +\usepackage[T1]{fontenc} % Translate from latex code to draw font +\usepackage{lmodern} % Bolder font +\usepackage{graphicx} % Display images +\usepackage{fancyhdr} % Header/footer +\usepackage[pdfborder={0 0 0}]{hyperref} % Links without visible lines +\usepackage[table]{xcolor} % Get the color in the table +\usepackage{pdflscape} % Get the table into landscape mode +\usepackage[lastpage]{zref} % Set a lable on the last page +\usepackage{listings} % Display formatted code +\usepackage{makeidx} % Generates the index +\usepackage{acronym} % Generates the list of abbreviations +\usepackage{multicol} % List of abbreviations with two columns +\usepackage{bibgerm} % BibTex German Style DIN 1505 +\usepackage{longtable} % Multi page tables +\usepackage[onehalfspacing]{setspace} + +% Tell LaTeX to generate an index +\makeindex + +% No indent @ line start +\parindent 10pt +%\parskip2ex + +% The bibstyle +% gerplain is for only numbers in alphabetic order +% geralpha is for name+year in alphabetic order +\bibliographystyle{gerplain} + +% Header +\pagestyle{fancy} + +\fancypagestyle{plain}{} +\fancyhead[RO,RE]{Seite \thepage\ von\reallastpage} +\fancyhead[LO,LE]{\leftmark} + +% Set the lastpage counter -1 +% So the statutory declaration is not part of the page counter +\makeatletter +\newcommand{\reallastpage}{ + \the \numexpr \zref@extractdefault{LastPage}{page}{0}-1\relax +} +\makeatother + +% Header for starting section +\fancypagestyle{rightmark}{ + \fancyhead[LO,LE]{\rightmark} +} + +% Empty footer +\cfoot{} + +% Brake long url in cite +\def\UrlBreaks{\do\/\do-} + +% Suppress clubs (Schusterjungen) +\clubpenalty = 10000 + +% Suppress widows (Hurenkinder) +\widowpenalty = 10000 + +% Suppress widows in front of a formular +\displaywidowpenalty = 10000 + +% Macro for centering extreme wide tables/figures +\makeatletter +\newcommand*{\centerfloat}{% + \parindent \z@ + \leftskip \z@ \@plus 1fil \@minus \textwidth + \rightskip\leftskip + \parfillskip \z@skip} +\makeatother + +%------------------------------------------------------------------------------ +% Macro for reusing sume text: +%------------------------------------------------------------------------------ + +% Use to define some text and then re use the very same text +% \ref{sth:bla} +% \textlabel{Something AAA}{sth:bla} +\makeatletter +\newcommand*{\Textlabel}[2]{% + \edef\@currentlabel{#1}% Set target label + \phantomsection% Correct hyper reference link + #1\label{#2}% Print and store label +} +\makeatother + +%------------------------------------------------------------------------------ +% Macro for the title: +%------------------------------------------------------------------------------ + +% The full title +\newcommand*{\Title}{\TitleFirstLine~\TitleSecondLine} + +% Only the first line of the title +\newcommand*{\TitleFirstLine}{Betrachtung von Datensicherheit in E-Mail Systemen und Entwicklung eines SMTP-basierten Anonymisierungs-Algorithmus} + +% Only the second line of the title +\newcommand*{\TitleSecondLine}{} + +%------------------------------------------------------------------------------ +% Macros for the list of abbreviations: +%------------------------------------------------------------------------------ + +% To wirte the text only once +\newcommand*{\ListOfAbbreviations}{Abkürzungsverzeichnis} + +% use reversed form +\makeatletter +\renewcommand*{\@acf}[1]{% +\ifAC@footnote +\acsfont{\AC@acs{#1}}% +\footnote{\AC@placelabel{#1}\hskip\z@\AC@acl{#1}{} }% +\else +\acsfont{% Orig:\acffont +\AC@placelabel{#1}\hskip\z@\AC@acs{#1}%Orig: \AC@acl{#1} +\nolinebreak[3] % +\acfsfont{(\acffont{\AC@acl{#1}})}%Orig: (\acsfont{\AC@acs{#1}}) +}% +\fi +\ifAC@starred\else\AC@logged{#1}\fi +} +\makeatother + +%------------------------------------------------------------------------------ +% Macros for the the Index: +%------------------------------------------------------------------------------ + +% The thickness of the line between the columns of the index and the list of +% Abbreviations; 0.4 pt is the LaTeX standart +\newcommand*{\LineThickness}{0.4 pt} + +% Display twoculums with vertical seperator line +\makeatletter +\renewenvironment{theindex} + {\if@twocolumn + \@restonecolfalse + \else + \@restonecoltrue + \fi + \setlength{\columnseprule}{\LineThickness} % Thikness of the columnseprule + \setlength{\columnsep}{35 pt} + \begin{multicols}{2}[\chapter*{\indexname}] % Amount of Columns + \markboth{\MakeUppercase\indexname}% + {\MakeUppercase\indexname}% + \thispagestyle{plain} + \setlength{\parindent}{0pt} + \setlength{\parskip}{0pt plus 0.3pt} + \relax + \let\item\@idxitem}% + {\end{multicols}\if@restonecol\onecolumn\else\clearpage\fi} +\makeatother + +%------------------------------------------------------------------------------ +% Macros for table colors and longtables: +%------------------------------------------------------------------------------ + +% Table gray row +\newcommand*{\Grayrow}{\rowcolor{gray!35}} + +% Table red cell +\newcommand*{\Redcell}{\cellcolor{red!30}} + +% Table green cell +\newcommand*{\Greencell}{\cellcolor{green!30}} + +% Generates a small empty row in a longtable +\newcommand*{\EmptyRow}{\multicolumn{0}{l}{} \\[-9pt]} + +% Needs to be @ the end of the longtable, +% generates a caption with correct spacing +% @par1: the text of the caption +\newcommand*{\CaptionLongtable}[1] + {\multicolumn{0}{l}{} \\[-3pt]\caption{#1}} + +%------------------------------------------------------------------------------ +% Macros for quotes: +%------------------------------------------------------------------------------ + +% A direct quote +% @par1: The quoted text +% @par2: The source where the text is from +% @par3: The page where the text is from +\newcommand*{\QuoteDirect}[3]{\QuoteM{\emph{#1}} \cite[#3]{#2}} + +% A direct quote without page +% @par1: The quoted text +% @par2: The source where the text is from +\newcommand*{\QuoteDirectNoPage}[2]{\QuoteM{\emph{#1}} \cite{#2}} + +% A indirect quote +% @par1: The source where the text is from +% @par2: The page where the text is from +\newcommand*{\QuoteIndirect}[2]{(vgl. \cite[#2]{#1})} + +% A indirect quote without page +% @par1: The source where the text is from +\newcommand*{\QuoteIndirectNoPage}[1]{(vgl. \cite{#1})} + +% A reference +% @par1: The source where the text is from +\newcommand*{\RefIt}[1]{\cite{#1}} + +% A text with quotation marks +% @par1: The text you want to quote +% »text« +\newcommand*{\QuoteM}[1]{\frqq #1\flqq} + +% A text with single quotation marks +% @par1: The text you want to quote +% ›text‹ +\newcommand*{\QuoteMs}[1]{\frq #1\flq} + +% To adjust some words to the flow +% @par1: the adjusted words +% [text] +\newcommand*{\AdjustWords}[1]{{\normalfont[#1]}} + +% Displays a reference to the given object +% @par1: the lable of the thing you want to see +% (Siehe auch Abbildung 1.1 »Ein Bild« auf Seite 4) +\newcommand*{\See}[1] +{(Siehe auch \autoref{#1} \QuoteM{\nameref{#1}} auf \autopageref{#1})} + +% Displays a reference to an equation +% @par1: the lable of the equation you want to see +% (Siehe auch Gleichung 1.1 in »Dummy Section« auf Seite 5) +\newcommand*{\SeeEq}[1] +{(Siehe auch \autoref{#1} in \QuoteM{\nameref{#1}} auf \autopageref{#1})} + +% The symbol for a elision +% Is used for more than missings one word or a sentence +% [...] +\newcommand*{\Elision}{{\normalfont[\dots]}} + +% The symbol for a small elision +% Is used for only one missing word +% [..] +\newcommand*{\ElisionSmall}{{\normalfont[..]}} + +% This is used if a book is cited at whole +% passim means something like continuous +% text (vgl. [Aut99, passim]). +\newcommand*{\passim}{passim} + +% To show the audience that there is something +% To display a wrong/importen part but not corrected in the quote +% text error [sic!] text +\newcommand*{\SIC}{{\normalfont[sic!]}} + +% The text for a note from the author +% text, Anm. d. Autors +\newcommand*{\NoteFromAuthor}{{\normalfont\unskip , Anm. d. Autors}} + +% Space btween \item in itemize +\newcommand*{\Itemizespace}{0 pt} + +%------------------------------------------------------------------------------ +% Listings: +%------------------------------------------------------------------------------ + +% Change the text from a listings caption +\renewcommand*{\lstlistingname}{Code} + +% Change the text from the \autoref +\def\lstlistingautorefname{\lstlistingname} + +% Change the text from the list of listings +\renewcommand*{\lstlistlistingname}{Codeverzeichnis} + +\lstset{literate=% + {Ö}{{\"O}}1 + {Ä}{{\"A}}1 + {Ü}{{\"U}}1 + {ß}{{\ss}}1 + {ü}{{\"u}}1 + {ä}{{\"a}}1 + {ö}{{\"o}}1 + {~}{{\textasciitilde}}1 +} + +\definecolor{lightgray}{rgb}{.9,.9,.9} +\definecolor{darkgray}{rgb}{.4,.4,.4} +\definecolor{purple}{rgb}{0.65, 0.12, 0.82} + +\lstdefinelanguage{JavaScript}{ + keywords={typeof, new, true, false, catch, function, return, null, catch, switch, var, if, in, while, do, else, case, break}, + keywordstyle=\color{blue}\bfseries, + ndkeywords={class, export, boolean, throw, implements, import, this}, + ndkeywordstyle=\color{darkgray}\bfseries, + identifierstyle=\color{black}, + sensitive=false, + comment=[l]{//}, + morecomment=[s]{/*}{*/}, + commentstyle=\color{purple}\ttfamily, + stringstyle=\color{red}\ttfamily, + morestring=[b]', + morestring=[b]" +} + +% C++ code environment +% @par1: The caption +% @par2: The label +% Used as: +% \begin{c++}{caption}{label} +% c++ code +% \end{c++} +% Use empty brackets for code without caption and/or lable like: +% \begin{c++}{}{} +% c++ code +% \end{c++} +\lstnewenvironment{JavaScript}[2]{ + \lstset{ % General command to set parameter(s) + language=JavaScript, + % The language of the code + basicstyle=\small \ttfamily, + % The size of the fonts that are used for the code + breaklines=true, + % Sets automatic line breaking + captionpos=b, + % Sets the caption-position to bottom + showstringspaces=false, + % Underline spaces within strings only + showspaces=false, + % Show spaces everywhere adding particular underscores; + % it overrides 'showstringspaces' + keepspaces=true, + % Keeps spaces in text, useful for keeping indentation + % of code (possibly needs columns=flexible) + numbers=left, + % Where to put the line-numbers; + % possible values are (none, left, right) + showtabs=false, + % Show tabs within strings adding particular underscores + keywordstyle=\bfseries \color{blue}, + % Keyword style + rulesepcolor=\color{gray}, + % The color of the shadow of the box + identifierstyle=\ttfamily, + % The style for non-keywords + commentstyle=\bfseries \color{gray}, + % Comment style + stringstyle=\ttfamily \color{red!50!brown}, + % String literal style + numberstyle=\tiny, + % The style that is used for the line-numbers + tabsize=2, + % Sets default tabsize to 2 spaces + frame=shadowbox, + % Adds a frame around the code use single for no shadow + rulecolor=\color{black}, + % If not set, the frame-color may be changed + % on line-breaks within not-black text + moredelim=[is][\underbar]{__}{__}, + % To create a underlind text to highlight something: __text__ + caption={#1}, + % The caption of the code example will be + % shown in the lstlistoflistings + label={#2} + % The lable used to make a ref to the code + } +}{} + +\lstnewenvironment{mail}[2]{ + \lstset{ % General command to set parameter(s) + basicstyle=\small \ttfamily, + % The size of the fonts that are used for the code + breaklines=true, + % Sets automatic line breaking + captionpos=b, + % Sets the caption-position to bottom + showstringspaces=false, + % Underline spaces within strings only + showspaces=false, + % Show spaces everywhere adding particular underscores; + % it overrides 'showstringspaces' + keepspaces=true, + % Keeps spaces in text, useful for keeping indentation + % of code (possibly needs columns=flexible) + numbers=left, + % Where to put the line-numbers; + % possible values are (none, left, right) + showtabs=false, + % Show tabs within strings adding particular underscores + keywordstyle=\bfseries \color{blue}, + % Keyword style + rulesepcolor=\color{gray}, + % The color of the shadow of the box + identifierstyle=\ttfamily, + % The style for non-keywords + commentstyle=\bfseries \color{gray}, + % Comment style + stringstyle=\ttfamily \color{red!50!brown}, + % String literal style + numberstyle=\tiny, + % The style that is used for the line-numbers + tabsize=2, + % Sets default tabsize to 2 spaces + frame=shadowbox, + % Adds a frame around the code use single for no shadow + rulecolor=\color{black}, + % If not set, the frame-color may be changed + % on line-breaks within not-black text + moredelim=[is][\underbar]{__}{__}, + % To create a underlind text to highlight something: __text__ + caption={#1}, + % The caption of the code example will be + % shown in the lstlistoflistings + label={#2} + % The lable used to make a ref to the code + } +}{} \ No newline at end of file diff --git a/Bachelorthesis/Content/StatutoryDeclaration/StatutoryDeclaration.tex b/Bachelorthesis/Content/StatutoryDeclaration/StatutoryDeclaration.tex new file mode 100755 index 0000000..540b3c7 --- /dev/null +++ b/Bachelorthesis/Content/StatutoryDeclaration/StatutoryDeclaration.tex @@ -0,0 +1,20 @@ +{\ } +\vfill + +\begin{flushleft} + Ich erkläre hiermit an Eides statt, dass ich die vorliegende Arbeit + selbstständig und ohne unerlaubte fremde Hilfe angefertigt, andere als die + angegebenen Quellen und Hilfsmittel nicht benutzt und die den benutzten + Quellen wörtlich oder inhaltlich entnommenen Stellen als solche kenntlich + gemacht habe. + + Dieser Datenträger dient der Vorlage bei dem/r Prüfer/in und der + Prüfungskommission. Der Inhalt der Arbeit darf Dritten ohne ausdrückliche + Genehmigung des Verfassers nicht zugänglich gemacht werden. Dies gilt + insbesondere für die kommerzielle Nutzung, Server von Dritten oder die + Überprüfung mit Hilfe von Plagiatssoftware. +\end{flushleft} + +\vspace*{2cm} +\noindent{Minden, den \today ~ \dotfill} +\vspace*{4cm} diff --git a/Bachelorthesis/Content/TitlePage.tex b/Bachelorthesis/Content/TitlePage.tex new file mode 100755 index 0000000..e9166de --- /dev/null +++ b/Bachelorthesis/Content/TitlePage.tex @@ -0,0 +1,34 @@ +\begin{titlepage} + \hrule + \vspace*{3cm} + \begin{center} + {\Huge \sc \TitleFirstLine} + + \begin{Large} + \vspace*{18pt} + {\Large von Julian Ospald,\\ + geboren am 07.08.1986 in Bielefeld\\ + Betreut durch Frau Birgit Christina George} + + \vspace*{40pt} + {\bf Bachelor-Abschlussarbeit},\\ + eingereicht am Fachbereich Campus Minden\\ + der FH Bielefeld, University of Applied Sciences\\ + + \vspace*{20pt} + \noindent{\today} + \end{Large} + + \vspace*{40pt} + \includegraphics[scale=1.0]{Content/TitlePage/fhbi_logo_kompakt_orange}\\ + + + \vfill + \hrule + \vfill + + + Copyright \copyright \ 2016 Julian Ospald \\ +Licensed under the \href{https://creativecommons.org/licenses/by-nc-sa/4.0/legalcode}{Attribution-NonCommercial-ShareAlike 4.0 International}. + \end{center} +\end{titlepage} \ No newline at end of file diff --git a/Bachelorthesis/Content/TitlePage/fhbi_logo_kompakt_orange.jpg b/Bachelorthesis/Content/TitlePage/fhbi_logo_kompakt_orange.jpg new file mode 100644 index 0000000000000000000000000000000000000000..2a825b87d074647c6f3bdbb06b3d4e602648aaf2 GIT binary patch literal 52602 zcmeFZcUTm`wlCU4G!R6Rl9eQ&ARr)FBxlJgw)QRcrlLsMQk23BQ3W8Y=240E7qv zxed7u0E7+T_9JJQ56s&c_LM_Z@Gfxwp}IEl25{c4oR0t?066xq{}SdXOw|^2gS-zQ0xkk%fG_~q*m*zIHc&Ay?j76AAzGq?H#=BK>7_xyZie*J@4NJ zX*yfCbDD_coc0141nFz%w9{Yd^ZC)){*``kPTNC0?7=bTJU_LE+Mm-uLHfO)uLDRE zYk_pApNoS(NDqTFm%A_21*DHbnhxq<;|%~L6zBau4tCBUeHWxDybSdfL0Sd?E>JlA z18w^cw2#9xkWTKV*!*R=wk3(2e@;--}gTK3jkI$V)Hg;|{UiKV{Fz8bo zkLLjJ*Eyfx1zbH}TMlrM#f2rs#qWp+g3JH6_8(sS+o=DTIN#g9j@Z-t%br0Pdj8(` z_j~`|2g?G0`v>6KeENHzZ88AVyaj-3lYj5y`V0WnZvX(%{}1zFIF}b^AD^dELPGxj z{(>$Jc7o>%`nUGq9q_l2|32{#?-M+K-{01bL&?F>#@F44<9t!=VD2zqFAndgHg*mi zcmAJ3{GYz@AK3Z_K5pwfI68Pacz~}m2Bpl!!wKAO4|^9M7nlc!i^spW!~eQ`_70BQAP3xjDaISeK?8|?ZdyodN|K;~z z{SZZge-e4SIB}eJE9x6^*!g<-oztLBod1vlmjG&j4!91m0i3`s;0_=HNC48n13($j z0CWLEzznbg>;Pu~3U~qjKoIZ}2n9X>pMZEE1;_+)fI^@Qs03<&M&Jj~4s-**fDr%< z{00_*HDDV!1Wq9k2swljLJPSLVTW)-1Rx@i`w%&ZGDHia4>5y0fjB`tAij_w$ZN<4 zNDL$e@&!@|sesf$en2`Q1CR;GEMx_;3ppVoCZZssBVr}uArd0GPozMkNn}W5N#sQ2 zNfbczhA5IKi71Pxga|?OgQ%Nmgy=WX8qonUKzx~)f%pdT9pd}Mip09a=ERP~Uc@29 z;lv5VS;S?;^~5ORA>!Y}>%>?RG7?%64w5@0(j;mmMkID5o+Ke8A4yV33P=znKS_p2 zW=Xb5@T8QaETjUYQl#pnrld}!{-mL#38ZAg2)Ax z3+5L*F1)&saG~fz^M%0+%NI^BUb)D9QR<@ZMf;1-FGgL=xmbU(|Kj4s(@Qj$crVFb zGQ8w^>E)%QOJ$eZE=^t9yL|cb&C8OP^)97(o(fKtN`;^rq}rsuNX<>H zKy5`GK%GEcMcq%me&ym7o-2x1Y_5b{Nxf2cW$elU4K0l@jV=w8<|9oJO()HttK?UC zt}0)(zxw8C_SM#_^R&dYoV1FxcC@c)b7+gF1sdLli?L!zjZEBP*imB^Ny#6=MV2SUUl98-eTUVTa>rtZ+YIzx;4y4#&@63jW3<=7e5id7{4=r zDu2HKk$|{>i$J=-z-`jolD9o>XWbsVLvcspj^CZ)JF|ief?9&F1ZxC0g}8*wg`$N} zLioF4cir#i+(ipt71j`bC0sAOE5a{gCz2{MEJ`V=A_^C+72UZfaL?gh#=UVdS}|?0 zcVaDKXW|m#UgBlqD-v81PbAVL#_rSIe{}!j{SHY|$%m3~$wo=6l(>|SRHf9G^c`t8 z=_2VrGQ2VlGC4ByvNvUIWWUJ%mgA6nBKKMDxBLxx8~H5xxd)sN>>uPkSXSUua8)Q# z*nD{Rq1VIehewK1iouHCm57y8mBN+!l&>lqDW@n;tK3v^QYlv1RuxkXRQ;|-s-~$H ztv064s&1!VsJ^Wsp%JX{QJ#s zUG;?YiOG|qCpa5jn=G3HTXows+ig2VyF|M+`v>-M_A3su4lxePjWACKjWxgkQ@AAGcOf)Px3?FVE-u2<`hlCHfk9HrsB7`H7 zA_$R=k$q9(Q5m1eK6!i^jh2rth@puIh?$Sojzz?A#D&N0$6LpDCfrNNOuUrnoA^6P zE2%b_EBRA0F2y-zB=uoxc^XSvSlUs#efnU=gN(9F*31u?C!bwDkAG49g2>{@O2{V5 z_RC(%G0s8d-p?(}W6JxGcb4yw|GPlH;Af#kVPO$VQB*Nev2XE8$>Wk=rAno>Wp~QH zlrxln_zHaW{kmH5q++yEv$Cb?epT5w?r&+;wAJAV2;w#CocG#d@pz#QPBa68*KmB!ATp$P6?O$`Ae+QW|O> zRv+#j(HR*SH5wfsdp!1g+&FGy`&iV8$;tAmKaL!ibjEj9 zkJrRc5ugMDVH2QLu!q??0HAvf`VXW4(exVv8h8T+AOFLR=kYZ8W#ymx^tkdtR5W{}>SCoiz}DwG)%2WazD|BB5$`%gES- zsj_8oZrA>`PwX3q?5ftGdA|FOd%paVQflfNps(iS?BeR@|Ll3d+t7FK!@}d@6B3h> zQ*v_i@(T)!zEvY?YU}EMwzZ==I=hBPM#sh{CKnc$mjA4*?jIZ;9b-?xi9?8qNJxlD z!4)DSBZY!2(~#V_N-9hS+@w{|BNwru^StozC1*6f{uf&Y(Tf#aKL!-Nwi#z%-Q$ii zxMruclU2zhcHK~1*`D{3_v=^{pL2eV9DI!>-n{(_!+U&8aXH_94lnG-=T^6kEFRoa zHF3P}7n+cVXdhiVbn<_fm|ue$TRu`Vb$<3fsi3xF{LitZx|z%Ku;jwJ&WRN)zm$f# zYe0BPQGM6s>Iq>Ipa8drh=!O3kOyYwXX=lvjy9Xdnoi4ow?fu1f&c9I=X(589R8^d z{{(}7V&Ok+!#_>q{|`Nb5>$`%v627o-m&_wTWtv6VU0GfcZ&7hphf;^c72s>;8^;N z_=#kS#O8J&jp+2KuXU!U7BL~UZ%Ov%tG_Af z7`a3l-yC@PGLFZ&>eqYr<9Er))`n_C3E)$zLU`aU>2jn&C~Rh>9EER`eo*5NztOYl zK(w9B5d&`AQuO0mkvpR0`(|ldQbDH!f&heUMs!n2<$Z8AEER2gpJEa}N6q5e*SXm= z+B(rwElzwnv2T=XSKr3-IYqUhPdD>$r*>pcLZwf>x_u~b`rMm06n}C{y~yRx#_Gq0 zu+IoUOJegy0w6LI$80bMQ}&hbw#*+#w?Z2I*+j+A7PR?KE%-07M%S!K@EG&2NA_(+ zVAI2kvO?burrWi5Me#u<#Tux6HxcarqH2XG2k@co@B|a1L-{AZp|gMb)2oy5wbSTw z8z+Ig7>6BvHnmaG1a|VQDYmf9&?G1WW!xW;QNyx9+^b7cN~6D%eKi{sn3rBo04~eo z4JC1lRJ?aa2!O<)GU?+isfgZssi^#-?PqOVAqT#4-Pnr_M_kdD&-f}1sPRKvn84CF zIf0L_vPh9+0u7chxCJ(3AF#1QhTh!R4P3naegq*yMRCn$n0eI@S+#%I_^r@}0*$eyF zxMc#ZT53OeWto5X+c;xhpHo%xYVWcxDajSX!B!##nY|95RucRghE;x{8`rY}PbF`$ zMDB)qG_aa93ZE|f`s&)Rcgf^TG$ECn#e)T@`3$V9MGg%2<3|Gh#a>K}pLE1z3Cpq! zb!+s?zcB3GY#J#&J+fMx26yiW>AU&uE8Y~oowpSyFG&DWqD*n5Gf1|2S|@kborY5a z09}x1{#Cdxj@gepQyf048ow5va^G7zoAWKLgO_ZeE~(lxRwdfbY)uy%P<~eM|MjU& z;2LI0<4_@f2j#oy+{fV*d_pT+Hk{-lW_s>XGNCj zGuYs^7w7{k8*SaR^#HcHchFzP!%SvDzE#lUCvax-w3Ty7J-Oo}zB|+OVNh0aoHhSz zVSRaJ4a(d-0)v$5i>)c@2DcRSzACBxK{Nq#SB9r;#?W@}2bx9X3U%fz_ zFU7aa|9iv5T>uXYl!lBWx3jFHS%Vw+xXLHdYfDID_l<4^dLwO$>RQTvAqyMPd(oo< z-J}jI@%L9(u4vNcL?;ZFTq8cmh&}l~bWsZ*2*5K`6MR4G6jT=kFQ`(b=vkp3un2f} zckaymQJZ#R%y_T`&vxGy;)jF3-|F;;^|WQD_J^GA(T}6s-Hugk{O_L*|5jYuQ8A3y zE11CqmM4<$auR^rFuXW??q^Umxbv2nbJaQ-IyAv`m!1)TP-D=5VCdoC>zehD+p*NA z!6qu8V%)}(5`gCHr{^lZrVDae4%(Wv`7lsv<_Ulvt^glm3Xclj`-VgYD@?*ArMo>~ zz1g@xZ)ntfEo@8GenGDP7~k6q-RK7=cKb^hF3$Jc?g_M5odXPrYMl1c2*8^m0w55X zinm1a$SDSytjZjrGNz6Rz$n&gyv4!!G!}6*J%ynQe5fX3wozF3H2nusVwjrEABexJ zryiB?s_1rDKGc9CCIjZXSzLpsp_xqWie2FC?Tda~ZJ!>Txl;OWGWJPcVS-jL+wP?F z6qG3lAs6}Z*MPD8cIvdL8}|oA!(48W?h*y+C`@4S54@+m2y#}O0C4+9z<%m3xnbg; z`i-^AZdlV9o(2}-EeEy)E2kz(9B)Ef!`on+rK>W{n4UQawi~yaPvTuG@2{j>;~wO9 z`4YnpZXN-^Y8wy$p(HsfUu&HB)nC0k7sg;r!O6+_-w)+3bJqC_@_H|Pwb+uaBlocR zY8e(kWn_^}ug7wb%;dRfs^?Ow7Ps2GhEc?B;ii#^%ezDOWnkTcCv8y5o%&mee29}O zw^{F|mlN2>ioJRy&nFNezfg;Ah{LIZl*p|6B4&0`sNr7S+jo1pI_yA;IB@xRj{sbX z!|Tl4@L!@XyRoG`GZgsF+ri*+&6+g2bT5_J#l+qznlmS|A=qwVDp11Bz?eab-`i+> z(m^11LDhK#l$`MZKD(6rOQA{$*Y&u=P1Efo)fOIga(UzwXBU!OQR6t5mxUSvaB&fo zyJ$ICP?QX?;NRbecAY@ju{LvWx1*`?yl(lUR-|@{ft)m=tjBThdHAZkBPaFyb^}d| zn65=HqskwuQSI}8em~F8a8k<(yPo{&RWK+wWtm>^mQwjxlSf;w8&T?*rkCiwxk_Y< zNJDDgNw()EG*(lOWk|uqK(XE%TD^nLq*wX%`Y6dRI=4{OIPdxBLSVVCBLN@=EtK^S z_>x}Do>|oU;EmVoGR-4-`Nh-0!LcYuKPSia6W9F6YsKEFw0@6ly?fsV6dIFu>7h)* z60#4oi~LDd>yOMqFQBCr{}gALIVW*?gT^nUJi#!yVKBJYV1#|Dtks&`LY)08-%@@|k8t?WL@sE*A%{QRdZ!PPlYBABf-3#(PT4kK> zzQe)tQ<5j?r|}yOYjTLyN%uV5WRqLk+KEHY;^)Uf(AXY>HpOcr`cK{@f)>Rie;2lB zf`W&pYo>0=$FWv_t9L6F$9>zcZpil?9)`y+6w8EuxLC8D)a4#IhY5_Vvx)xPKDQzu zu&jp3ej9%cC<1qnH^?T>*ac2)LEmw8yaWv7ySK);TJr&@u zCd$aaTqkkQ%NAiI_`AIp-qenYO}+7O;G6H2Ha;~ph`XRqJ*z_idbVcS_jvGT)-3)e zKjpT69E$0TVL#M3OgFG0-U)m=<+b}5rRlFkC$gCyR#&i-d?MouRpzP~TDTb=1T~Dl z|0?TY-t-#A8inKL#7}+Li6Q{h*3obf#T#frk+-;ht`pPXbk5zRbBE?HQ2KvIN94P` zCJb}F9RZMoB}tFj>7N}QPO|fXZtBFab?ahx@X`wUxHK#QJ&bJme1^-Mawxo^Tci7U z?3bh*IOA&g$pti?E&?=dpw+09oH*}1(eNdM%h#Wz79Xjsz1uiaSy*d|&76uO0FK97 zWN=|bMKa4z`PK!-gt)lt;+-h~ziQ@#u}&%PG3EEp4oB zR%f@bzg-Vl*}bm2)jZR4o0)G1Yt&b{kyh=q5>ry7R zFCtXV9vdrOw^odGJm%EZDvm17O}I4b8nyqlnUro&YGVCBf0F^%4Yt z#;HT-?11^*IhL8j|Et?#O{;{ZMQ75=rySYhBL28DaC-X@0E3{$tvkJ6w ztVBVNutR?PV|vxL=H=mZZ2Icv^pte>vfvhK<9Xm(=~2S?2S=p&K`60sLf+)|LENK7 z@3_=cX9s^W?YwR$yJC$ug+alxR?^o(rp5xxeGHMab~6w>|9&WAL9?T;zqw|0vtm%f zR?iY|gG5?jchI79O^#_sjp%?O0r06xjphA@*sx90zVF|r_o$>m*C~2_)pX$eNWvGsUBJF@iffSL4pLv0k7Fl8Fbu6mjJ@A%q&D=^8Jb9s zO`STvGf?RtIWV2f{YIH#bUo@!i#Bw=(66#4CmmAbfm8&fc-+ zud(ieEnXhBo@x4FQt$r`m41Mf6I&FmyFQuEYY;Zxda)is$?(uW#f&GFcr@_na%995 zXOk?K`)pD&JNOU|`B@p{(N$g)5~l$NU5{g?5Uq2(aMwLHMRh|r2IRYo%T8!*9E-N; z;eyie(=SK?XYKD4ZAC^XcOr&>@H?@ujf}2r&_q4mxpK1iP&ek+uXIGW=n)%ISL%(}Z z!)wX9it9{;mGn~i=5|_fbM#kb@L&`=V~_^lbp?Z{TO0VgKddV;9s7qJSkFqS5RK5D zJhLi!))1x6Z%;Zmg3f|(#U%QSKxNa%_2}b&J+C}|#{VMR-hds%L)vr0iA*E_D1LY( zHLjhrWfOkrxYi(=b0QwJ=1~$hiTraW%zW}$k7wX(yP#sX%Dc_F*j2f6oqHgG<8Hu8 z;5e|dJN`w;Bu00rCH52c#sC2jcJoG)OT1sdy~OA~un?dqFnW6Qq*>KfA6`3^W*GQ> zt-$Pl;fG)68ogQzBERj7U=17!7txYvQ}aIP9EH=K6x-jJ6gC!at8w$&ycApM&$eEi z6R|I+pZ{d}aFN2w=nl!fGP^;3t}#%_tFD z{Q|478#~+PVZyC9mL5CAH#2_wUS+2oFXec!Q-gS9XSa#nicSt{Y_m5PIcGi*cdJl~ z{-&CG_!Zf)dcK+M%KpEO~k&1 z-Kp3u%l6-r%Uf$MoNn5gj8<;&zSi_(qM;1ww-HhL_J>o=TUMXIW=YXH%$i&RTL5+i2B2MbK|f z2n0PMMgov6f8;+Ba&9u$&M{#cq_8vu;HLcP`^Stz- z9X!g<229R}FEWDydKYx7MtorSoBf}xPgf=Wva#Rr;DgSck!EG~u08ym*(wZYjR%7R z%#16j9c!!Jdj@3z*423Kponn-aAW(_No)|Sld>+A@gvG#@!_$S@yt)Cd!ALXx2D0T za8qIW2E#`mBLo$EdZP++HQrBfMVNv+v-qT zr>i!`{n9Y6M=Omqt!uX9_mXWpWIk~V2*3R$%?o0fEBqG){P>>kSqzx_u!sWv0QWOo zynH+_PIS2~;%q1TOcq{6b9Rh{)CUfouHio*2Y9!UTN0MO#^3R4aDVwhA;+_=33#?p z!|4|CUFT7=P>nTpj5W9?0W;ef)~8{#^D}sE`BXTLQl95L^a&;a+qLQ038kyB#aZNy z;&Lqp^tx^|vnr<|vjwAG!Zg~gu~1FO+RKS(np~Al-DqjbV#l7jKQ5II z#oG+-(Twtk%)Jx2i^X%3vdU7+_(4=z`g^8JRiG3GUh6+rEG2Vdjq095ro5p)ZY-te(PXyN z+%C}6wotGn@ip}I*)8vm5K%DD<*&c{yZAgOQ~VgOYrUOpp1CNwM7=iw{KoM-uOaGF-n8hGqL}7l?|k^-&2BQmDq^~p=$*34u7YW`NwITj8`;A%m=OS& z>qO>pUXwHdKr+^!fs5D--_y=1D#dGL-nYqlWu9z+4f3b7KwV<=%|-2J7&jxlioI^; zX6410$SW&xZJ#?rx$?N1c6TCPFPC@WxJJJ1I8?%EGC89@`(HLNQGB;4hsf_7{{HR& zr7Z3kZ(qaF(+s}87Jh6Ybk;C4*N+!82G=+!@hPa?e+U4$_WJT09ms2-NF887oI##e zoWGTKJ>3>>ahRuWD z)m?<(x&w8wJAS&Iea*)&CoS^7c+H3g#D1;7Bu6mAj!7MRzB|ngf!uT4o| znvwt;r&3bY$PfbMf3P3)asE;?(#wf`0Otkss+PZI`qr}KRFBAiQVotrPG)o~A4j8iP)&l|&Q?iqh&=&9DB*w|sCp`uu^SA$msk2)RAfqX!2@ zBc}$QdU``jkeIBZVj4428JbrQgl-R#vYhFjTLbTz?bNNs>$pxiPPkY|*5*u%JWYdq zp;SKkSkq8gHw@Y%KKt{Ly+8G1#~o91P_jdvD(N+OR5_&-uhYbje!qGyMEf8A<@9CO zY{t5a7`uD`>x&%0O72w6k%vH`6JcPe6#RCCH5sAOPXFzxQ%%`QCQYrdKwN+CHTv<# zh@8C#I$_Trg=DN@D4XVYYVh=RyGWa{{qko}>y*>AGKt60gC3O0vD32N-^802@@)Z> z$8yW2c9mk{55}q{aSgLuzC{grxyEcDC>wz$un9CnJAVDU3+t?%d%R1&j)Sik*t~5= z*V)Qf@8qWBVSLV%-%k0`Rl)AGHXQj0s{1Wjhd8?2;%px>nBy%)J(|xgvNJKbW1h=c zfAkQJ6JQ4subVmz&LqdbJ`>i&-YAXoUN769LZ|xL96oCc?xQ6(`6}RPIKkhV&}nz$ ziuR{?+ealmre}A&L1@W70(ts%JTom%3y)h?@PT#o)$|`oxNktmFb55!GH&UA$ z$e$P=hFCNOtOW2!vJOq96E{`)`bw6zRq?ELy6j3uoL1R)F1XpWqoPntD@EH?aH`Is zvk;J}&-0ZbaCl3FTmZCFPTV#`9+$nA0_~+ph5Ic^q2`QNj<=$_^^JzK6%7;{8WR1U zJdI0-D?Db<6CGOI7S_;IS+{Ep0WoK059_>Pos4FjrGBtpz642}2zw`ojn>^N)hRBAbxPjKy5q_IOJ}ZDrWGl;`)h9 zh)PKP%#hyLuZ5z*HD`gKcNWhQ{K01i=`OM2nyWJVEU=H<1wU`B@=2*KsY^vIluB5)8Kr=M5TzoIMm}@oa|snQ&<852p z!mHcq0!BmMBaBp+UR-M$tFK{Sq_hBYv(8v)T-Qm}5_?yggqyo{lxc~vwf$i`8hZng zdwe=7CM#WAQ9&1&}Ru8lZ8r0OfBmDC5m&_2|g%LYat-g-Uv%Z<;@1kG0k7^KPK z^suyh0$68*{jGMYf+b~cyoGI>0Nk{goL)A3zl)Rp~U@cRCxZD-zJQ*;zpZ8+`K>~U8$yp zpp@@Ju90U+S3nH#(Lm1Xuy?=^$fU+p;>DxZ9%D|=py)NqWM0cda>LPuia@`rnv7dpz4K;W7;Vt4D;?o#?-%V>s)9>%U2HrahxUGoV zntpk-+gEf4jNAH=+o>5Pcpuh4gq+GId@0PNcE#3{dl-F<9C_?dR)6WExCd{V0rcc?Qtp{&4i+(doW=;HdOC+!;xT^kc;3`DdOjlKp zR8~i-z)1ZnM=Z~7fW%g@K0NPQ#GzZ z_g6#K*QZpbi>FNGDz~Q7R!VA~xeNBJTK3-4O7*WoAc$ce0l_tK9eO`>*>vgSUd5OP zmGVy6IYr;hDFaVgKJs>#zd>&2u`gd7hz*LynvACIAdsdWEQYcQJBr*0Pga2jk%NY; zZ?=04NcVlMuTQ*uvfb^R&T#FUKHW_$rSz9|A(>$I+yYGUw)n_N97X+{S(N-`$-FCC zx_73HmbUOc3ikLteww-t|7g47&+D}XZGD}QeeCNHd_yaNk(*R0zyYT8>QI6hl=8NJ zF*W~7E6lW$8~a2(Y${LRiJ39TQ@(09S@Ig$i~0I!Uf8E{bZk`X`_-Fyxi2wM`_|6> zvRx=gv_Iv%Po1eBT8*o&Ho2GKe%8ZXX?AWyeccY9D%jTs3~b%6shKPRzhwXFLgI%` zP7-Byaa&+be|m8<9W@z@t`Cfqnp{^gxlw1=1xrwnHeMGdo=Sjcw*-4SLm*r8&>G&skcg-)#R-U7RnE)-B3(7xb!Ps zJ#GhV|tG)Ua2ZuFjLbGB)uBIerFxcs<^NTgD2d_6)#}5;j^VxGP`wnk%G1r@jpc)=48giVJf($k*NfHyBlFEi z-K+wyf9K^N7;pFSOO2J!&`Yf{YL->62cw5m(U5UwcCPUzRE--$QH=iem7*^W!p3%9 z_f~h#rbW3mwkVa9Lu=Ds7*4!s{ZzM=99+HBo0*2yI7V;z>AO92)f=9ji&tQpi&r-> z4}blN@&c7NjNd(Ns~eqp+nfG#s%w3eBKUDzct?a{p4vE>@h-=c@JK}3@$xRYGcIB+ zE#w%j6=!y>(TBOpz4KA*81&G_S`A8cB!iv6FIg8zi@&EBqPWr@|ksZ61^+kLyN0>$E4=oF)B zOHV_0Rh;!F&a@E z7SS*;8zOif3j8lc<-e8Ix2SW5N^&PCh2M(KNie&ve}7*2_O9Cc!>pUH)Oo%K7T2pp zaDAkwyV|1-5Oc*mgN($RP3X}j^1Psk(FMqpWnJIycGu@@mF-PiEM1(2Hc+aeQ}0}7 zl4ltB(JgbWP6>7zEoW@TQyzUSCf2C-1R(E2O>1IQj$UJ?ot7G&e^~cK{(>6O<>uDe zFdMwzNoxGbM)pvqaLnZ__V6sY`f%B1af0)5ePyuKZ-r71N1%iMuF{j+Pa^qW>|31u zVAVJ~|4u@Md0xIFVr-|O@|J(Xg-*-YrQ7p0dE+kk1~+9OpT2!Md2cFGd+04j|DYn= zCbwFVtD+IJ&f7HgW8GS2a!-8J9GU>V>w%!(sH-V^P{!a~WX0RYOjgiW${1L;;nBT` z;(zQe{hnr1c+|3a`_eaB1M+3&A*~Nfb#%VQmbvwNU&ZrX)_cg#Cd}^dqG6uDay{e< zRl*DsBD2B~M4E&4xA^sDGZ+q3`9(7Gk)NBjmf5V9@um}4WPJJPvTgGlZIW#Af#~5y zu85Z=2Juf6X2+PZ*$EP5+A~LT=1Z4F$u?YWL>fwx_gYeusp?-heNsrCn_nTX#QOi@ zBazYaOh_PDq#}`s+S1_Fu%-xbB>G0T&C-s+Hagm*C zQyGrME>Mk=6>qVKd&6{})CG)sOk)LBLEv_l2gTMEyUmC^oqrB*iIGp8QQpL_Z}g4~ zTDlCLnZ>U~rcb3uH&&&ajbUX%FMrM}?^w@h>RfU~Bn+3AC5oC3X)CCc#8f|S3lnKB z2g?v&|D$*E$Z7A!s_wEy6Fe#Zd(-^35CU=7cPx((k(LSig06m!N&KiM%j+<@a4OA- zL`=`+Gk^Gc*uJ_7t7x;i^)*7wfl7zJ(D%{3ficjnGg&@Q`Tlp!O&;qA)qLUPX-uZm zs9gmb5kzLoTKcI+kz3{FJJ0UO0xfPw{S3Mom!07W@vvnjW5+O4KpkXygbmCwcee8YaXe+2x_b)UES-5d6DO9$#2Qw0 zm)U|A=>?t(G1Ak=dQfE8mIc3-QP-us`LIyN!>QIDjO5Lb|6y**i2B%=-R>|T$n^N- zj-3sxXT}m5mBKC}E~M$V>EM%CAc$40Vk?tzP zE3<64?VV!m@N!S`$113<}k(IojN6^;q$Dq&`K) zO`(yH`rU~j_qzSh33fzw2G>7^KJV#PT?kMA0v zf4^_>(h_tPU3P^z-<#xP{TBy}ViZ|SJB{Cqd>ZKg6o$Q|+9-Frc3Oo;H22MHNc*-& zIxI0j%f{5Rb114C(;gM;*~nev7_m>Lyg*)(a9R@h{LKG|f6S-poiVENEixmkXoxKL zo9g?*PuFifHRfTnD|MCKeqC1muP}dL>sWSowPC(&N7~zGc*N*{VY~FLKPmTO+J<}f zoBVhFwkvUJC?y-a4#jJf23kemWj-n8-^H(3Kes4%kW4*k>hY)MMKq*+xBSB09BHR) zQJZ)_m%-t>59F=6m~s17qiV${er280Z{my6@`r2vgUyVqob+~3PP?$eut=KDYbLhh z#;CDhi_W(ylj^%3M@n$3YgX%+!a9G6gE*Ixk}x< zI%zpMGl{k~okEGl4U~NCr6p5Ug+vd;ed_8`AYr=VDz(tmTiq7l+m^mSO+TeGph@=v ztbXF}>T))Ue@Vjf`t>la#Wp+&X-R#FrYsH^Xu+W;U69L)a3Jtwk-lONXq2wB%{4Y%^F@tEgG-LY(oT{Cy3{P8MGqD(4DX20+ezipxOPbo;S9aw2=lC(*EY(M~dwV<#- zup%$>y><6m_Nq~ptnOeYe{PRch|VF~(5ZjX&#|o&u5t8{$9mA=;>Xe*v7HT#G`p{% zPSKA>!P4M?-*}MkUI{P_k-XeK-BXH%j3o(Hf`_)Lh)UTT)6ZComtMOsR^2lc9+{Ug z7N9nZ?jD2I73YQ{ULjr<5RsXOlTzW5B{Y>=ztLJ`Mi8e92&&dVb4uQH})0 z{*k?hcBxFXK&sgaF^=gK@`5%eMb)1eIC5Z42c`F)E{s#^j*EH&opg#U|iBV(V~|@MK0*diBRO zl4HJYm#1eokr>mn>eSfEBkJH`d*M?zJ_U=$9E?y6|2AF22Rm5k_K>Zy(yNRY*LCuq z2anYgg}A`)ZDp{|;(i=S>=xm5nQ8OZPGR|obgEUX!EQG4OYcH`agL5oN@$jB)qB+J z=iX59;{=j~9j(oC-gGV4x&*cr3SuVcZnLW;r|!Mjfzw!7r2|9BJDqRwTN_%McAop=>u&=e5dg|gaRYWmq1QLG zjkBV`XlNXUeG~L@n*AD{4EGHyI`W}L#9}@-MEcO*ZC$Unkhf>Ue0_6p@;VEi_PB{n zn)5?pr%e&Ri$T|?kq3iHI>`*PO`w36E`zmRQr1hexZZ%&f}NQz={a7jg{oSr;x+T~ zgqhn7yRT}TeFO!NBGQbIg!Rb0KkniyQ^!mtyBo5zW_s!dhRd?IJxPaj_)<~@3_u$f zO#sB@m)`ACW1sslwz3tiQB_Y`cH`RcFpuEu0gQIF_xdfVO|~Ho)`<7(cV^<-W~&T^ zKK=X!vpo8kmGk8_x29UmB4>&@vL@dr6;z!}aWt5sf*p_w3RQBi>n^75mR$T?G9}OM z`D`8E)meJ4dRJYJ6Slc}7BN(db$HES#FUpW|IBHYv&3i&%q5wickACRO&iQ(4B0R3 zSu-CZyA;JIG9rr?WQCqA1t{34M%0ALJr}=oVLG$KTdRww=i-7jhj19`tRoA1c9@9N^j1`^-m{YdGGsBnx;Q za{uL7?vq+q}K9?+Q8%qoY2j^Vn+Nce|Zf(FqJzVMkL4_dQ_D*$-uN;CMOr zE_&_he#U%@dvJ|ny?Fb0Y3rs;-}KZ-L%z450Pll`qeCt6^mKj98nvJl^1);J_kdow zDEs2fAd;`9RB){AFwe0#z`bndhx?>!J!`|;b;=J7B1z_N+wInNpQlXu@&rQjB!ua% zj_7Q+#wZIyL9onf!~Fsg$iJgJ3f@DEwSf!uzaQ^I^!lmx==|)kZ$RXSY&0TPipSGQ z!}@>!sg$mQ{<4*j!<+`CK-Z18Ixem%D_s)bF<>Txf=pQ_f-XpSO)oMLW3(+ghw=`p z+6-H5Z&~RreNfl)GwBRWJJN$LJ^yGcDqZ%b2Rl5yJ4AQ@BaeU%dL`Z-4A=yHv zJ1m`Gp>=SjU4PVNHf9^lj2T#7wGTB!o&N$$3 zSuO5X_IdUT$|wczh~xu{73r=m})Qj+VVJ={Y+?@B@jt z2+p;y@_tB|d;!}8)OM4Sd1+a@eK)%l_IPp+$s##Xs`ncJ#Nb;FQ1{#26Z{2Y?_khrcLfwMMqt5@IK+fQB7X_)tyZqvX5^KIROt3C1TgX zv-O{R<$l#sXKeS_Hy;Y6RTP{(kh{n9Vl>}!BXBM8@$7%Y-~V98@N4W-Fb8D-?*sAU ziYjOiwq$o&L4#)j12=f>-*s+;kh7YZdm=~>mhob+Z1CeYIO1Fws?RG{syV7|H>Kjz1*D!|p zyFqwoQz`hd4pgG+Y$fKkXdRy1$H~Q4ZXXqVCTr;svUq$@lOdReHc&T`aqzb2ezG9` zQLXxRs7Bg*?(n;ojy7P%Q}Z>lMp* zn1~&>rVu8NjnZ$;u0a6?uVr zDO!nS{;$SMWFlWGH^@fwQ!eJD>0_`JgAd{`<#y~-S)`fXq zx(1oRs{y6Z8lkJ5{((*YT2LcXArr#CEdd-z@A}hohuhEuGP-rsg$~g_0a^#x41Ei35>C5BQ>hlvnyNaz0@v5-pkb zyMUdtvBw!1Dj{{3Nq8hDupj?*`9HBOrJT)*N0!vPdgo$(=+q-0>rz(%za*b5uV~}v z9$c+ZQ)xEEXa!?!dbg^jqPCRPVlZs)3wXuqhvPIyO(Xv8nr^Nq0PsRcPGn9=h9Y z-TluWcU>9+I{Xsxy6!LL$J17J8F@GeG>9|G`$ ze)~LdwFo)4<4e+eLZyKQ;9b2@OSHI9srp2Ts0sOAcF;7p%8jg=7x*aDApG?X+2*I3 zlE)|b>GBQt<`9UbB6Mxo%>>~9*>vf~s982RSay_<4zKV-nz-NjFXX*vSQF~HHi*lD z4Ot3^bft)N1?f#hKtMox6HtnDBE1C2QUnwPq&ETSy_e9VAiehzLZp`fkx)a5-^;#c z=KA*RbI$Cu=ggUz>-*uK2;r?yxu5%f-snjv2mLh~n}f+=q$$1Kt3sg7u@q|^Y1eip zUJzuZ+#0rY-F<@i83cx5V&kuebq*zl{-#K?*kf8BO2#{ovyaP(-QruYyJTVSoy9Kw z^unA$xfQfD{6VcSG~tZ=FCSNZmVAA9@mk>xQ94a}HUW!})H_r!S}`ayi*EU2Z53R| zG5-BG>x`AbUMzp->YR~tQ|OF5gBf(lNByoLw|Z0tx3N-nenH2gYrT(y#?-5 zS#|}lii_+DmjU4EOLn8%Z_rwyBK{Ee5Pn!=%oYp;gerVW52*wMEKFWI@GRT$a)f2w z^vOAw^Pvo0O>wGp@Q5ZWW*n|TR=|pep#awvMn=sv!miTd8G@;t#?0};Eh zf(j_yWsN-{L$sFf>#Py}_RNf*aj5{SuIE|fkkdY&zQm<{fA3Sx zl)?GS()GFaviBhaZ+=07l;4x?4o)odlX`GU9jF1K%PlACUovYvK-w*CXvDOLi6Q4D z%@O?&xiZwPfu&meqYxUl&_0{{Z+5Qo9~h;agaKcX^`%8-v~5JMvv*niH2xGOLz{5b zcte=@&^z?N5@l46-d6gzb)nB}%+UPnQSXEnfRJ*l6^=R}St+H)J&u)A_cVlju^Quv zE2c_jX)BUQ1at)k5XCkV?fdt=amCZJm93Mlfiw90Y3aR{#8)fA^UVorvV`cUOBKZ_ zX4ivM(lMyYh=Hu4_cW__U!C-v-qsFQ5ZHc29P7Zpmy-6n@CJt=fV4|=K{|JKFR5VbL zf_h%_+%4>!w4AI`OYvP))!`iycnG#rf9l5oT8X%VSWpI4gZqPVS#!x5K^c8PnT}Gr zWzz0EpL$=_B?991Qm2>l9YmuCgNdKyrioe^ddRxDD8y&Cp83T@Rt9$cs~iS(8S$$K zLCB#eKMXGe=l1$(98uQ-Jo|r7S$)Z`DmT+UVq^EpbS)94x0rkG>z~q36`gG@8-k&TXS5!X! z`9kt4?kOvSsB~u$y~M@wMaKk$SJWG}*izs0AxGpklTZ57l?2mZFRx$)J*6>rih`AJ zE3V1r^L*{3IJr7t=jK5uHk3g5o1(JZ#}KGkh3>#ckbnaJ1^nk>&!jG_90u6gBM2Ap zkvnXX+(PbUGldOe{b6f;XMa;nPa$C6`noOlz2@cD1Q4VuPwWA96>%cIjoyodoS>%= zGm01p9)*n};$OlDj7QjG2Hz{>NMsjr1r8+Xnl0oO;uIizlbXn`1Az8^azwZn;0yxh zmfhbJ8T{10DXh#%|1hp8#1sO^Uf0oZ*q|f=12g|kVMAStSo3a`-&=Y6n_|lmjreJ^ zEOa6bVcSbUlV_xkPLB30NKA)Ve3v*0f9q^M_pw93VBil^oV%1IT%PtoR`RM z0CPifgKsn^I|8{xAPPjetG_8qNzi{>vcTUIZxcTw*0-BsgQhToH3p4A55V>zNW>a5 z`T&vtf~|v;T30R6(*74JE%@WW0^f#P(wDTG7U!wVE<6siF32s)|Lk1;?DN1aj!mi( z1=jvLNE4P9N5;S*soW2+UdWc59#>~q+R25b=!-Ts@~S_sAF`giJ}S_K+CK8GXr4Wi zO?1p~ssEUn&cL2joc*q(L?-YYYZ8n7q~vDCqCy8Beek_lh*k`TQ0diya3V@6&NjYRSzEEU!D_q%9xy^1I@6 zjowI{b`?}!49Y)Aq??)9+3Gm(HnW1JdTf93>YF1qC{%e(u-UrErhO=gtfr~iLmp-@ zux|Ekf3bPNBOrTT=|x;ccV;x*-vEKPGih|AvSYfH7-&?!RC%4FRF~&4cCfB^Yp`Wj zdMCf!dr}8;`%6&!8&U;_<5rq$&5IAnu@@V`FTU+?ijTMX-w-KHAS) z#hWllt~rV_ zg$ihJu^OIj5Sw?4X`=qpZoR=}SH$CxnQ$rFvMg8i)I&y99A0SOY)OOrVN1j`M=+6y z*;~_ZkXn{ovha{uCTYiojXp+y0~C_UFP!Cl+tN!x4+V{L+5!V{7GMUd>5J>F@p!6g z-V;pgNmQwH{wu?$u@g@7kWMeez(WG>BBjhKd(=2>C$z;EGdm9tA8BuE5AXcX%_Bx8YMtCNSIl_FT`v*(B zZD%ci(WmG4byPsCQNjntpunx~LHWc(>!_VXxu37&fj)UW7thoOgJqS$XHdSRW7I(k z8S9Cq-ic(QCauiHn=9iC4e*;8+T*Khr*p7~{!Kw6C*qHosbLAgg=RIjw~Bdj^NLKr z;C}7Quely{_6u$GF!Ln3pgcbYekQ@;a^Xvd6v>y#U!#}!wLgIKsdap`8?;pZ1NFhL zZ%JO&Gf~M&Qds!4qu7v<6H##FYwzl6US3wJY??%hnqS2CjP$Uui`HeOeqr#CTO&EV zA1FbLUIa*uk;mb-Q_7) z7v}V(FyqBprcIfa_vt9=gBS>v2B{G1(mj}O+Z>2hBnrLu zEbE&^p0!)@0Nd4W;c{+UFP78=cz`3XVrG0!-om25II$(Sz-FleleHtCzX$*<20BZ;lTH ze+Y#OC^I_nH7wllzQ8~&7O4!EYm+(XQyuWHY}jU0nV{Vj=)olmC*!U{RmnGHFEz*q zx|ptBp&CRiE;LJal|VuXYDC3VN_`7XH$~3Ry%Efn(kh%Tx#p7B!y2Vh>1!y18~polbdv$EA`fq`A|KD~ z!V5p&NuFbao-4eX_ul&Yzx-%zp;QD8xG{KM# z9nt9a!y(avHX-REIZvJwvYtM+lHb2MIx#w>t6;38d)|giPgPb_|6%2jmiE=Zgw?N( zh=6J5{d}juiVK@xyi(8JP@BeC7p=${4LAlqbg!N(9I#l84{JC-OgOs!&^?>ZdxZ z3o%h2@CN|5|G4!Mj2HG6)(4@F%R7!5miB(>qS5gvX<%Z;*I};pa9d+2ibi+5C!z;S zLYXDa(bn@|c-Ra4^{>|WWYmA;GI_pv3uLaZ$iS%oyAagBfcgB3zp~jB_++cHPP{qU z@9BG=mgy?%#f!OC;oMB@D+`qCCaO6mL1dBHN!DM8`A9=j$ADIYX_q?HH-^ceKeQEu zNx2_jhrcNVtBPmKUP^Zf3Vgzv_Oah__>wg6Oa(_#PB8zA4U|rFy#EhooMJx)E?bWNt*=T>I1P0lJa#qGYQJe7H;0@YH6dmB?&E27AqGmVQpKa%8*74~&Z5p!`uPPxvM1$DjUw7sF+ z^{cyC@5Gn&c653rByeSWDgmnzx#6OX)9%#n+U4+#T9x@G%P0H6kMrNZ#D5o^7QTqu zD?XMCBU|sId&}T&u=QlE@fBAB6boyN%UI777>M7TZgOX-vq5vqa7i|{wCGZ?|A^Df zejq#|a!D~56c%Uy!^BY!|4SO5^Sbr5KZb0Lz9!5f8a_?ScE+2GoG}_8skCe!(b?Ln zWDH^Fc)AUpXAV1ASqkwS!6c`g90cFYX67f4CCA1B@@-}$0d9D9icdwHV zH1Un?8>TC4f6X#QL0?xD*YfPrNjFJM2h=KBSlmREBs)JrWTVU{eGg@ky}iXrfhKC8*!_miI(-?H-07yBrqJ!_X#9)bmJ>iGax&BHLhnh^qei^S-G#g~U$E)@B77^3@ zLzqDv<-@Em>gDa>;{Rh)Cy`A-OIu$s;mtdVWlw;?m;v-K*oFA0B&!FaQ4A^(2@tu& zj-eM^I~s^#LX5y^`@zn@k`Nv8 zt7c>I0jOQ+0BiBUiMF-nS<@!^45V>deq)`%R#;f-T_n`)6>fi|vo_*W*}E*sg0+&Y z6dt`U=|8^*Of|}+|8GX*EhIYQ_DS|)qVl14_aJUA+s;$|`L@aSLQC~x2%KB?uHc7` zt9tu@IW9_ve^#f{n#HIlWu%>3P?Rn)Zg%Q}gV^3@NSrp{yx$ts<_`!mO&IS`qt)uv zP$$Mubyv9S+@}M2YB7O*4}u1Ny8Tixizt6<9g=zGYOKz9yRZmn*r{!FCjGZT8UM2# z8CFM`@?*_HV{-FC`x1WqrfB%`$YP31gBh}xYwEUI_i;JG@GqNtT4QtGJ5fM1Y~rhS zGJo;FMGW+PGZ3J(8uvG6^CP#;UIxO-kyvqhHX;Ju49| zkyV*?)t-2J0P*|@y)02VVaYGJVf35Aot`se8UIJPFZT~Eu1|fh3chs>+(KaVg|H8N zDN!u>U!wWT{+Px7^fs;Bj`?D8Qzk%-b!F(sg|bTMmzL%^yz%@Fl_3+4MAEh8@-z3C zWks)z;kdOFZ5z}J_Won{63c}2*=}u|No}g|PS8oEtPvBO9>TIrq?C9@#!}ZEcJh{s zf9chK`h(wNnrL&is_6!W9yf^TE%;s>4sR2&?JZ+~qamM*9P2;N@fjQvpz50)9GW>Vi@gSD?=~P zgX}2QYi%!*Y=F8xOS9kQfqFSmx(&P=5uJbmZ=(mDjo1HU~Nt4oF za+l!WVb80kPwcSfu`zyGke~3>CL)OMPX%DpM$ZI3@_>5fVb-zx)l+?QOf;{?4iok< z#^MI70xPwC^JTgBHsJHH^8z}CmUUkybV@8+t<{{BXTf##P`Qs7tj24)uucT!Rv`M% zE(yS1>Mu`SQdFn6vZ8mgcE6$Da$Zh|VLImc1jGHgq*RMe<{{pgvmkoJ>YDYVc|c=6 zscJ0F=F2XyvAGi;A3PBs+|GCQjmi|*Uz2DUhXnz^-o$(DAbCTW!LXk5r$(zIUjf%R4R_y`iMO~G;x3sg<4)M1zIimJ{en39J5XlS3W7(cZ!X6T7E4AL2zPper z%_546e;7WT{xU$L3*yh+5(BV^>+5!Qm2rALbIvS+(kzj=`I%iy>-LK|S(#ZmA9*(H z);H`&C3p($zeeatjObsd1e-L9aZQ^yN) zvfe0^yP2V!lmL3NsrY*1uVEW|j&~+=g3A8-8j6-$*?{dBg>z`a4ntX2QT7#7-WULwe zYR{r)mUI?)G^TZ-)m>s0S=&oSRuOQ+L{Hc%q=oAWo-fqt-`##8=rZ2x!jyN6_1eSC8l#*UI3l7y}GU8XEXJ~+b2U#)g zEHdWaapEjmIL{o@xy)ykg=Co4t!Wi=YHm(VDa{~t37#z#C;LhHCjH3D;4}J$h-fwk z4gBPT+g{bpv(dxrcDNb-`u1{nKk17g^%Vv6u=a&rqhpTTubq~=aSs%fqPm7he^j<# zeHz`t82p^#EI2w($@QCZ#T%Pc9bua;@aYzta1;_DKFyTPP~lZZW48pqb~2as*+pO> zDf8RNbDd>zLGP_sqVZMPdU`bu)?VzV@pTlkWnet*Ooe+(;k;~erC(HOT|b`~)c;Uy zz1@ja{^GS`AvBYhuqXC>{6c`-QAc!&MPo3YRCg@aHo80WYO16v$o3SnrH(<8p$Ob>0d zeO;7?9Q6{zcKoc8PRR>-n9`W)`15sgH8LeDjE62y?XpA2M>F-mZdm{b?P#%l@9r_n z9`sIZo4+nzcbsLc;m!0|a_`o5WrI$t|L}rNrak9?o|Ds-M8sT@9dFLl#q!>C!WRdlAeM?IZThESxan}50j>L_Ok6Bie-@=Hx=?*+Hh;);AuL_=Dua7}YJg28StyR!}>^O7J!fx4nsDqV^(L6x< zs1=#8eAlixqLWkMs&jNK95AE0xrrRR?A%d{;j@oVzgI;YH~O?-R$+7!*!&J#_j=j# z;64|#f#eQnRMTJJtr_kRjC{SHMf5idFxx#5E1^orqjI(f?pC2Dg`o5Gtq z$&Yg{zVWzk1+HuU$fS-n50B$IZy~0@vG8X}R%v!RZ;D#4T2g|8Ly<|6@j^jMnH`393 zUs^3yK6)nI!N54k#wuI;YIOHg)$4!>ob5Q0al27`8Ew8KZLu`ue1P>hXf-zpbD-Lo zY$~U2s-QMgUXFa2r(G1v^%u;y6ZQEs{CDP zc*%)~Rg0ySy*T}Amo2%8oL(DFGy9LY_9cvGFlkx-y@R$ge=$AOyzmL7RY*6xFUTxV;C}{xkBtfJ0%{gm%Ba89~5&w z{QOhl+;!KT-5yRI&PqvRy$}Q4#}~VAe|krKcEaq&6QAWrBNe>8ZC``lU6i;T87ZXa zAC8#a-f2rmXI+*ZMQgQnu{u8@lH@jEQ*nWXvdeII>jA8uATFuC9&M2^eQt?dMSZvw z?)k?ayjC9R@}-omSoO7hawz$)-xR($^GHse4jJu%tI-2jM{+9FX-cBiX~S40IifEa zMvT9^$oXf$a*i8kLClYZ?3WD28UPD=cVB^-`Z-^ACzknxffARo(R1(#V5X8W4-7(g_L_-f?(8D&a9r31sW7!$)ws2l*ChhAo9fxF!<$`_ z*Xe}c5EnOnGHgK2K5BJ>@Lt#*sk#~36BSLbuDlEQXe0MPDk*pn2x~$l3E|Ff1i)ug z(K%JJO>+qTleX-dlgaX9Q01FBrXr$g>hd{RKPS-SW@IP+j8ecd3z%Pian}k&xYm~98NRPy7yZ@sdG5whh)Ig(VB3z` z#!Nopi>5j=Pc8(f_x6u05KQZ^{YolbYi^{j2dOq3mkb)EiZ*%Keuu&RQ!at>r{F*V)~sPtI`&RYmF&c%vF@2 z5tpuqypGJH25J=g6$FtRRLrfsx!VVa*5%5Njd!sH@b4J2?@HrlrBeZp@VX&KXP36l zMTeq8K?wKEbnlsI>CP0EuJhu%phx!O7B`QOr?0QEE&)eoLB8=FH|9$$Cu^ge(t^{w zPqz$SB@XXoZ26wx_pwTUnkD?hEK}D@9ew@r7n8p!yc?G)AKWTfIbTk7ney(VQ`}q0 z5DyLw5)0ZcDzhD@onU@bK+E<|ozx}J`uFiMs9N9BdPh>liCh^)X@}y^Hjy1YHM>x# zr7#RCKXMy2Rn2~k#j*UHP0grW-@U&>`VQwwwOwr1)Ax+k{qbP@`}HReHb4YmJ+#_` z8xr~Dh<7D6;ni!`zUIycSd2HEnVRr@66WN|W&`oh<11^Nud7M`iqzK2vIk9-xLUDX z(L4T+P+h?C6=Lw9R(>xk)D>WLJ85_!oZ(lg(B&6(xW$SPG1dFp!r+n=TP4S!e-U=O@_kwP4;DOJY}PAS>86x_ zE@y=dU7R#`ws-&?Z3QAB%n7My)cyH7aE)C@l(-vYoq(2c`Sp*1H#|c11gKaZLal0~ z#BE-lWHcS7TQC<)JNHFx59BK7B=*bP+^O6-WIo z=eNWWG5x^hehBY&#$KOnZLxUZV!B%C_r{__^37rz?FNxr5e;2YWh+V1J4Hp_G0MIx zfXCYa_UlbK@Hhrtdm3aTS!&``ps=C8&rV87`b5uS^?j^h;kI*ws=8^TR8!!nj^40h zYG!6hLVBX~`<|s@uI%2$yo7tjg`E59TDo+idaM|fqh8B4Fi2wLC(}mjatfYX zY~v0U+lHh4vWO_DrSkBC1bdr%YDxx+?yR)){iGCKS!eV0Z##3c7u_$vZoZxk^tGmP zFhS~7!`&!+w#QXj!fu9qd`u`)yjkV6EUc+uqmm_fg3xWX;ils}fclVI+C5T{9$9LW z-L0*sZ{@f+@iQ%*XDJ-eRonuNwm-4$0ghVmT}z;c$nY_=5f^V~Tj|@y37(*3xi6T& znQEl9YTc3|;pMR$4Tfw9`LR5Q@uYC{hzP*eH`WCXO`BR(IG$kK z78`?HKY6XrFleA6`mO6)S98cLXI@0mR!nXN-|AI61qOYyQdt%<_Mm)I-jVS!Kz>G|#Or9YrM9|mQp^2= z@C;RSVr01^V90qziZd8Q>y1r3AGd+u)U3@G`M_o2xf756m0cc6k|wrzQFcbHPW@6T zIN4i*bR#|??ulJxnk>!}o8%}4@td9J>T&*HM{EbS`C5N=$E)gE$*Ux)yMjf&JSJIi z>g2NgLf@=ic4)b$6ME>#eMuaSBqchS z)Nlr#DiJ;!;w;I}VAM_03u_(N6xhSMHG;eaJG5^J^2`PVXuX@4HHT-+v?l-Da^hrx zjs>_*GG*>Tc{9#b*3Hq555#oq8rtv`D{1KTJd4*-O9$4$B8-J1~K zbc@&B<6+mFZjFxsC(ClKdtV_&1l7FT(;tt*~82U6FQF(V(qw>NI(##4D zme+kmflBgSst_gAsvvV4f5cC1ulYDzRQ4H;8f~vvl>rb^>U3naBa92O95i=jH_LzU zX6zF6qXns`EH~3cUSz8KFhukF+_YfvOcR2`SfBa+sz_2P8bKo|V}DLhZCI*Hi;n%G zE)Z}95kJCWGuk4mi4Cpt-k~sm*A38>?oOcDffx5OxAS3CH&swAAzwZ*3;WF9bd3^j zXS?NOu=qlmT{bcG>$CUI&pV|*8rPe6ST2+gzAke&{N+~piUP0^9=-mY$Gb{`-;W!J zU1YBG?auv3!K}P&tF6J|nTN8~UqZQScUSTxE=xUGA3zJLzAq!{){zc6!gUN8U z(rCTvx`Ec=o`%X_k=SFJkJQ59%LF zB(2NXfOz%{dHigl$n4-NY4HbLHX@_FC!g=*ZW!*TlGfwFn==z0gtoz|>i-xh{f8VR zWWHplA8X!oQ>;QgdA3|&rBfzo$8}M;xq4ys^Tx+A&s(=XSc?N)XTQZ2lP!V0k3p&UuWhd)2ksqtoj4zTeQ=+pT=S3T5+@EU?I(}U zZ+@#A-1rW;swbJ&@;Rh6%tD=3$~G_Qo^4)9zN5N^?yXmzFE5?D?s@ymk7+n5KUwS; zE}OFZy4H#DRebZr_==GqTaDhIejTJGo4GossS1>U3E$gj^Q$t+ra?RhY_A4X)Yxog z=??y9T>fv>n_SzyeoQZHwE?KR6Ct?pSXam=N*&Mq7ZB`c!0HiyvHUBJDaa`g)4t*s zhtnBEx_$MrHlHuQ{8Y^6C_bxIvM7m?MJ{be%<{B$DIuwP8nM zr;&IXjC~-K5|>N%$>=x4s|c>mOU~zQl{L)-EDZaSfAm;ZNymCaU8`69@7 z_CvReQ+oS0bB(VpH~89MV-9Kl#P9kUy4F~h3S<4_VpWjA2@=8oox+Q z%=n+O(|qmDwg9#^{WrzVE*r5EM2(DK+!#mHNd2y~w9}3NDx=VZ|K`MZn$t&S{JbQNU#b1H32ZJU4)7`AXpruFlHZj+m?9sU zojyd6$98N2CpGqc{Y|k8I|1{5JGEj623%53rmd}lUjP!er))A6rVeoi)^=hU+E|k$ z)z5ZFk|U10K$^)*KXA^icHOINqV&rf`a_bE!Itb)V?IC~5`mzqoU8@vN{B>sJ359? zZgp7Z2=&4$c&@H&$)wL?Wl>6@1zX(}9>Z$kr_8@2w0}*j~g7UQmWT8b$b5- z*0;24(U!=47XQ+p2TwJLxF^MC=~c&3=aUjNvNgu##GmfOelZM_B|_SRG`H(K}O zH}2BE(aS0(C%#;YX9YH?1ePk13AmoWDqt&G(+zmWa7QodA8FV+S7V2Acz$-GkGvTX zIX$vHYtQ=i;e>LN`zx(G>T;S7A8mgJtL}OVBsi#p`RIY(zOA5k^t6fQH$}`T(1>&d z34yjj<4255XQ>UJ^~>D+vh=qO?4lJT`hB`u>c#^1++{p!MMj=Qck6L93!dRJna7}> z+87$B=zDnb_I?wts;K7UskeFQq;PV&#p;OV%$mbBWmsFJd|JK&5!Pk3%f^Igd=9yq zM-P!2aW1W$*-s^u<2+JLnSytvMs=L~(RPrq%TMj+8DIE6EY+fY%yFXwBqOQ6QaSV| z(7(#4S2HTSooJ^gv1}hrY5Wh!kNrMck#|*skn(iJfG++{&6+R+3vIP8V$%6w^L?Bb zPk&0BD{Tz`Ah#ab8ziCB{=J|VyDpv@bf^jU2IJgJmtWvvJ6yK-1UvR4h64#BY5El2 zpOQY!jkvV_Lig*+6T9DJ2z!N)`;Oq9<;etumEp+tHPG%7=$ys}CU+R01&DgFv1$FG zE;%nPBv-7>y;J`oo870g9OQjVa%uz}PlNWznTCNSVzk^# z!9QZuHX|wxM@)NLV`zQ3omkH}K`P@^$V=eNJ z9380DRCj^2gvJ-rE@pF89<3rvI(E|P5Aq_ZoAX2Rx7<|ExlVr9zVYGIgXbUh4}EL_ zJ9x>tZyz?G6@=g;6xRe^anZyhNoHu+)uwzQmHOS{aMU<7-($cGu6f@%En8dP_|tdm zg|EGepE_QCo&@PExR`L}<9{z){etk+55XO!pZ6@C6Z>`%9gG779O4{Tm58!F%VUchkN~?=5kkLj)LE3>W7J%Tdj&TR2#4`tqK| zogF5Z)v22_rHr>0tbeVBNq?{#dh^Miwunmab&E$R(&h20AZ$6%Y!#!9;R@TK(dJNN zdZ8mDtjEt!xv4y!DX|WEh`!zf%yU)1JV%}~&lBgIe^Z>B0yO%3AHbP605tlk;U$u_ zWH~vK$(y*GO0Mz59zvv$WRFyk=E&Bwk$VCNt~f4Ohq!(p|(wI3V7)wvelsfiYI0Y9hO7fSSD25kWi+3|&eC zj3Ipvm>BC;K)nAy&14EOsh9$Y_X~h{uZqB^nE%7{0r5Ts5bqyi+4jQFlWunl z60;Z<-y=@41H}7zPdITyyo(HdBTtGU91&?=0OGxJ+7j8-6u>za;2VvvIfAta0mOUB zyMTDl0wtvm)&Z@;U4ZEfxqz&u$|CSL#XCnpydML^dp;P!5fJb10OI`{K)mNfA7q!q zs(mNXdpT$}{Ps7n1L|1xFAX<(5~Ft%z5@b+#Q^C44|c@B3G9TamE{TzAG`pLdicI* zLZ?;yJlD0ybmG4Zbz!~}ccWsh+B3zKb%!eH1pK4S@ph${EvwJ14=yGeHBB#-6@1ue)oJsE*fdh z8+IY;j%o1VOH9hy=r)^mW25hSJS*u!EY4SlCm#21T@@+dHmPTkKGdCOH9JB?Z#N7j zMla-ynxJN%8Fsw08){oH4rUdu;<~iu`r_S%vxLI!yuEEh(Sbhc_L3q?^>D`|OqS6X zSChXSA{iLJdh>9cyCF?Tl#2K}QRrrneBu$V9J>=q2Jgf4hvSopxu^gE(Al_GDn%oD z7fCnCfZA)QPNmPacaN)7`iMS|9(v^z#&56^YIQK!lexQ?!L5nYF*u)c?};N2W&f?k zS!sZrKj7;ArudvTLImQ(MA+Wrb}iEQIl~ zLkN`kWwypFV`3)iCrkJgo|g#!0aRV>HmmQXm&C83ySwQ0ANJ%uiMg*mQi1`o!bG!F zF_|v0qHYl2gUDqz+~H0@^F9Z}8Isi0;(h_bWdO16pY=Hy4(_qWV?OhDt#j(01{c>U63_5{(R9* zPygWgUCa+vPLa{)i(<&}A2?lAU5#^PrXVH?4?OEH0A6!g!R&J9wX%C&oxrnXkEaIa zg$48^g{3pE?xTFS>J;4}W*aGyNj1->T%0G8ii>DBu`IOIEd0+bLx2?9^C^oW=xve= z)TQ!k9JtUGiw+{9gX-Yd)EeC7ApICmO-|TjT4S3trLnPuTfO$4=PrK$h078mZs(F4DN2!3TUC)xL{~}r;U`sK1;XPWxh$|P zQhVGjUg-y$J1cm}=&kg>GHBA~j8VHEHyQm+7Y@t#>Q?)=whJRQ+jF}3d0rfMm1h;k zGulLp9-qoGM?h#a*$V5=z&|Dy?3Bk%N3F5}Nu(D<{v%qr0(zEVia`L5*sMZ!Ee%<2 zQ#CvARzPh9{z?e-)ZHR-Ht_W08O6SV1}rw(gq6;Y&m#IjZR??3O@NZ=ep9sEr(?0Y zfF&EV*ve^Mx*y{`d6v*NLo|6P+(w8=kKzDTLa|G$t+@}JFL6fn#^tLsfx~WX(UXCf zcP?Ksog@{i3%)s|tFxp5df0;Z+u9SUNfwt`lx z=i568JFKARis&!JqCqVxAxm#aN5=lgm>uFF2i@mqL4tGdnuO|~`AUWLJ~c7A=VmH) zIZ0GeK=tiv9;lL+ev(ej_lCXnSKfB{D{CIo2;Vt6UTSUhimf0}Jh#l5OGUVOCg|EI zG#^!MrNPz1J6o+pO!%r4uYZV4r{TLYMV6-7#rCzwOeE zMqW9#SMa>OEh++Owg+&Y>c-=k(4vj$2zc0ZA4*}j(bUF@v6~X5RKCMO$YDuUem}_gt(Hr zz|Ctmx*Czi5I*+!%cr;Iu{VxzOloeuM`Srp-Oa8PhFXcVo^X8iYcGNan%YdRxJj#X z)O#6>cmAxZO?5#?1|yTh`bCw@m_%jb^=RFjt?5I=8l%9=a%eJ>cndJ0C*a>GtR+pA z+y}Y`@K~%f5i*ES5KiX_VPQcXM0Em!)J9%`c^!bVZL_>51g`?_+i(N%CnEm!B-uU< zJWwA``O;cSeOc=XHY{-ZxDS2H?r!RxskFDsab!RK4_PU(f?j1y4wof)BdC;QZ3F_P z-qqcWF6fW}xPU$=6N2)J=ML4oKzRc%d0hYOsNRU+Oc_2PBsKu?I!|UqNm0LH{hsL= z?Yiv#p&QMWeXQSe3rz9_-(BIz2Z2WFE_NZ((aHbZH-8R%5X!W8wMAL0K%7n6Tgc8! zpVNZ@;8w`SaK5l!E8g69dF7H^azba~Zf!n`RJ>!6mdq1VR8(hDXAksFdS}3EeFQQs z6EW}2j721@uc0zvwl_bG z<`ZA*8Cn_JW6LCn7fN4YsJrJVN8?{TJM--IH_V3E;LY$q<7MsZ4{K!&)cn2-n8_R* z;69bj#$@?z-26KEf#)1626dgahioW6=!mcPno@iYlc3uBwUjT%;300i*kr-Ii(dT1 z)FmFfjhYDV8h<`|SJQc0w>hvk1abXyS%;Rfe*KG)k>yP?ni0!8zy``~KBq9w=`sHo znI?aS6i>P13!HU>@$?_(9(1B1&5hXeW}H7LB4XN?g^ziY^!~bXt8)LL6J%%yx|nek zg4^3pKX7JR%sdGgvVPm=*LSY^@e(e=QhvK}({OIgmnpQ?8);gx>m+WR4X*T+c=lvf zg4r@#qJA#+kCQ%^zx&(&-1wukzG+2Utn)SSxJsTZX-%cY?VCc}lXEYre(b@gdCjlI zJ|F!UQCeun%Uo5YJ)zFw@ZjrFBHCRG8dcM}29)9*^O0)kWPV63Bd3U7xM_A6MP#SA zD1{1#wBh5(%0BFaZQGM2H|8m%b6uI;tRiY=gU;US>+W_}VKlAq`ah>SIIzIgp&|qM2EkTET8>Xp%*P6O8W=c{lE7EJv0&J zRgijSjA{N}yr%qv#=}ylZ(@bYmf?V~{A0Dl<2&(MMfq*=QUHv(lZ*>AyRjuVwPz{7 zIFG})M7Q|+ET!CsjglV5{ib;4gSSnbgZhm$>>UY7$8f!yJrv#lmHsq`V|zCS@sbFH z*66!Z>;HtJ=->&M!(O=O(Y_ z<~x`qid*Swj*2!H2mT@r$ZoT45v(qZG@D`8WZ!ee?^KBnQ1Ljs|A;N6&5n&_e<1%S zCMLrd>nJ~Yl)i%U>I;ymY^HCl8JP(|NQ&5X&NqLr9v|c{|*wz1jTmN(RIQz;jv_;s0wJFpYvgs}}Eh6;G zY~@pM6d`Wbm*>@sFOIhs)r!tC>W^JJQ;`2iGiH7j+k|eKYV9SYRqlB>ZC8r~+{OG6 zdy)|Ine!{f#NutWpn>7be`#sMn&swZp_$#OZ~-+sZ^i(n_XFfm_giudj|A}yGH%1jCC1YANq&2S04CYHoT#0XocBWD#|X-{~TEFz_Vhgi>E}7h@tC^ zT_$gu<{{l;ou?jf{?cG5YIeJ4?J4KbtH35$UmalMT{n-~o;uv7+rLpG@?`N-g{0$k&4t+>`t*FhDbrHdT{lsi!UuHv z$FO`(L4$-FDy#ELY<>+MdypFQ6}K(>qD72#^HUX~#3L*gBTe6J6kZmfE7 z#tR4TDB2H5NXk5faL_y?c;9)>`H`}Co0q>hEA7J;+uYgtAq=&EIYAyVf415Ao{Lz_ zTBGS*$oTsk(3DB#0yb6SvP2mqzTg zsO)t-pGpDDGk^ti@qaN}wZQ2*z#Og42)YlB^wEZuGeD~zEhOtE7rNq3EM&~I$sZzTt?sk45 z5HzL;k08<$9u80|w7yv}D^6>$^<6RB6fpJNqPp_)Mrhd6TB57Owfvqq&pL$Rp&)9z z3^AJ)QEMymO8hnZ)ihzr3w}I3cEYzB2jrs7K6JMW@c%S>QYrfJCilkK&-f|pBl_3| zXj+4pGgNuW34VQQ@v$qXmgWtm+jeul!s+$VgUrQ^ZdxMP7sbt8`L0!8+LqtAc5qtA z-pDkxkmct~Pi*Z#UHD(@>`pYTrB9GI{L8l+jTY@T+$CR_Z|1t`eFP0QkD1LaTlL|0 zlr4*L`5%cZ9^B+!!(t=)2Ko>_2v^JNbnvDWmNt&a1$PK-%>8`oDdDSYta03x8D0Zx zN9d~NXb}k!g{ujgvU2J6?0{?}5l_8__joS5#HO47&z-=3+nqRD^d2o69+`SAOVPMb z*?q(MeXM3;bx3{`&eD7*&jQh&t=3zq(BL}$J?pviQBCiM+)X0_Ky+bHBq2OWC?FNR zvr+33Ic2IS`NP`*QA|u^GuNp>1~sU?95&N z*DxX)nkXy?S7>eZ>n;BYcm2yEy?@+0UCd(FRQ4wXhZRCMj4!Ix`|ffAKI(O0MxNx8 z$GlDwo0q#yVtE58O*d?mltJMwE2OExbouQbl2r(zWn62o{W=PDC|S|C+2X=VW7O@$ zbNVhy>#O!H0vNy0v+fGgdp2u4O1D`UuT^`hMny9ktY9$V)5t~r=RgiERFoD(j?QfY z78r_JG;JE$JEBhuCGQvX(n2pPyED%kE(i4?s|8UceH{ZE%n z1a!*%SMBr-%)%-j9txy^YLG2x${u;+s`UQyCXzzTKLAyz(x^>9j_}1PGX0Z{fS zzAPG3fGWvIW)&AJ5lV83c#{*DXJMCf+E_+85m?y}gm3Qd?gcS3Q{#&3!gn{jVz^UZ z3|p9k)EUHCyHpe;hkG_}GLdDjO1%{nd}eBRUXAH1P=?Yb2yV@x9O5w|_J*ui(QaXESlTnuw(5}M7Q1xv z=cNh$@I0rgrd*YZU>JYke38z$)7x6>>L64?Z_03BMXJ{CZY^`LI|)DIRR6Kj|F0OS z$uvIOf%XNNqv8Ak^SdJ|*csHJYsop# zisUW;G*;$I4q7gGuqrlPnxDg0V)=ByCn5lX`7T5i0YKPqh1R znDGosBq~Q~T|aFObm)uVtT4yR%HX=8Cq8|aIbIgaDikjinW$w!YZ?swtA$iQYmXl%!G5ZY66sny>1J8^rNOAf+%Bor1&QE_P}U0;Uc&!3apJ#tg^5}( zTo38AHP(tNzdY}sH82(Oz;kd`H=fV3Sx5VNo;B+JVe_~4`fr~hy>rnyi|f|uGUk)3 z_45lJOBW`&Z`<;1s5*&rC%jf}jHlpm)T0lcl@s2#wGoa9k~~8 zN>=yV1Wdx)m>+{x>_-;s;BMp^cWPXXM!@O33&^va424~>;2f27-^iae!(Z6tpYn@C zR9u-R1$dX}sJg>EvCHa+iak4JoulHXV-&L!ftCE6oaIAB8z9b{g_2#9SmXgdr&)g2 z6=P9+f9bMBkR*>{t}H!OQ|`o2DgmtswwhFpA>DE#>+;;%h}+=NPuxPFkgS4cN<7~; zw3r~B&El&Ueo26IY;U_dfW>+~jLa=P;jjXR&D1}bd;-1>mB;YK$vNKFk9Yd*#fG}% zP;A5H9EF@)n7!;)J%10aAuFY|M9$sS@Quo@Z6@PmXgTlr(O!SJ{=*E9L}|np9!_mDVfN)JR~HmBsrY29obtW&@$u_bru}E9lo+z1-@-HY zi+gbjitgR@?h4#?YO<1QP+cT@#oYb&+M@fO4`Kv5yR8Z(;Bu(>BPWMC#P^S%-!`Ii zeGG~hlvH`P$N85C`yX#L{oB6$#^pIPbD*wqtMK7;aaX&uxOTVt@vtd{%VJW_)#0;m zzwlRzKFPXRKk}T&MO&WJpP+^>#8pGc7XASE%$CQc>r*Ol+!iKURN)<84Ij_(qAfcr z1$(B^zFCPbT~bOu6B9D73Xyxg<%N&hFbZ#mYQvROyMf;gDWX?+ytjmf8*GQ*QqDIq6!R`Y%j^KLztBUEGa zBR#cAC0|HHkH(0--{+^BpVewX9ixo4gh>#C$oP~=OB~#)_dyUtxBJ;;U#~k_J>UfF zoq%`DJC>oC21^c)6*l1r*D_h9842#<@PYSZJeZQ)r8$>`6$jlG5`HrC_WfgP)LE!N zo8I|vTocH*TNa!do>$Fw%}xgqaltuonf1(T59%z3(?q5ZKzjQI2{T*Y@gH@~8VZXF z|K%6lCG>t#TmGb46FL zUnF{DBMn2n)lERl_{f!y{kYQC`#@@z$;J2mv*WxOl4=6|vxe8$f>XUdRd?20NzuSs zooiPihu3+eagE)Yb79+(f0;j6tYNANn)9z(i3S+zZUEE+O0p|}&lz;e;RDcbF#4%n zQZP`UknNj710;_P05YsWPy+#Oc^*i7)*paI+W|Ho83ypjxd$K)eX0sj%>#5XuLSbT ze#kL2tr?)Zfo8D83FInpR~IkVkE2w~~j0OntJ~)k;27%=*e!07Q*Ux1G01omGuqh%s-oxl*BrRlUz zdMkwP3h>t_fsxxI$B48>pm#f9iS|-@FNQD+Ak;vLJ`6zA;lO|8XjD2Ia{m%+jZB{e znyCXum>ve$Z#)U$hX34-v_CUr@c&!!f76Pe!|qkfH2Mt+=P{ew%$TIUn6xl=_cVF& zJVG^xgn1Zc%F!IF&Ui;-T@9e>Z@&+X;$TC|4&P>#$B;IMzwVzQsx0GMY+e8a6M{p9 zN7zfJZbM0|y4rDdyTAX=z_8iS@D&HIl4W&CH&5uwsh*YT`1-NTVu+u#e?#6B41owr zdFikJwiey$%CD5+Ad$w-C#=1uYrw#jC3N@bn^WL<=y#SW2(BDX8q9Jdxu^MTu8Y?4 z23(S`mwnt+{ibMBAYz)GTXujgDGDTj4}uM`{7Wz3Lsy^tcFr`S=`@^e=+4~zmHQVS z;CJ+ITCfie0SY5Qru~c&on<_@$z1xKhg*3br>m^{$)|xb_2M7)pF(|U?|Mi9@?_M& z$%bbm+7n);hNrbD5f?_XX$dtYd)t)?bsx*OGTvna46@73b2glc?M~uF!X-Q=rt#(H zd5oR-Yy@QXw8`6|*sKZ|)CVoU721X5b(<)ca20xO$MKF217b}wz9@7jg0)RBz%^B2 zDX0*o6r3)(v#UV5Gx?~2u_Mm9BF8wHRf*}C&w%td{XF`wi1Vu3IfgH5=V zY-76gzD7^B?D+XN&ls;JcdaoLF(tdHG;mzD*5htz)`M0kLc;S4>}D^c?6nyh)bBom~{-Qh>fav3dbu?wxGq3@u$8i>os`0pM!h% zB(qb_rd+Wxn1yC)*hzga2X#P|AC{?;?F# z^&Gc1ZWu;Zk@{HtZS_olXNgBtC)ai2jt{Oys>y@^5Hr4)E`TmNF%e{|k;+MES3!2WCyou{C z=Q~SgVo;ffP2g}<>%6TK<>)&szEA~hm0$I z%e|BSUHLUKBycsK_A6vkIC-mhC8e%0)0b3!{bgt3S}b{EO}6~-aBbc5p?-<4D8^25 zW_&>dlwtY_^xnR?zXP?orRfSwT@$%pp>7X>Ud6JF#UUqjWcrJ_r_1LHn6s{*sYqOa z&GQ->ewzL7dhG3Mr*!*91JUy5PCflC`BujM4KM3Z^~6BYiOb}uxppl5 z3pJse>v!MmJjmcCc7$%=VtZ>-9n?BH>)7U#qq#;tcl(`K^={ zZV}O~AFD=iq+*Ld=4S)1?8;MDQ44+3{!@He!wU*Wt@tB542!FZKRcD4dG)%GW#e8+ zkqNM?(Hhoqj7W(N8kav(E`7qMwK1k|Owk49Y(8tbKly0+=wki2JHN+t6TJJ)r;)=_ z=aAF!a#93}c*@9k6{o68*>aP{6pX736_Ko1vL*9M(j_+aZt@#j zy}6_WOo5c<{FS3O=BCW&Cd-gd38;%>d4?JLvTOrjm4S;=c$tUO(F#6-iwfJCz_jEY z-YcaxNLk!0Ph7k83f9iouhn%lO|>JGMfv~4Lsy<|GMqGQar#zuB}ZAA#FsA~Y>7eO zoojbZo)~|R9BBi#fp~qI$*;&P#Ep4nYGG|M{JZQ9&N=Abl9yNVO+~Q_&@$Y%_f3dT zWN~5g$7H!seM|->NJ*9&x?Ta>@_ej?aA?#QtWKb4Im=i<`X;~bmyUXe)-BleSx0`k z+T%DZH~H957dhQ_y$?3tQwEcYfO{3H|2;tXpJv_4M;HoeoDHO@`Evb72GT1-O`hiZ z^a?-!5O5@{`S#e`V1^s362sh8q0A+W*slT;)F)K`p!TUJ3$8`%?$%8%qa6wDKV(Mu zO<-3)i|^0u$4k=ImA-moYX{a)+YcrJibr~{&3+dVskhsDWsd!#-{Tfetk3pN_}Pi{ zrwjNMEBpWaG2T6dWu(F58t~?l+j{!5d26AW8j?1e$*PN<1SMFw*%A2LSVhRR`rh*` z)wCHrIokW~n9AgsQY$M14v}dYSk7#_(6f8|c*wGcd*@!XjXE`b8%Bh?2S{0?EU~rl zdJXz1DXrLCr+b@?Wr#qQ5!;_p$*dqqiS;6W#@QbJ*2XN2Y(hwj=0bYT#Z)fBgpW=% z?qvLj%H+dmqu#U%{}@cHsv=Kd>!Z=|A*>^zA!hx^70e~;x|zA~BCEG{wYTEM4J@6u zX%6kt*7?*4pW+3Cuj4nu{4m + +LaTex source code and thesis are licensed under +Attribution-NonCommercial-ShareAlike 4.0 International. + +Implementation is licensed under GPL-2. + diff --git a/Implementierung/Handbuch.md b/Implementierung/Handbuch.md new file mode 100644 index 0000000..82b8a9b --- /dev/null +++ b/Implementierung/Handbuch.md @@ -0,0 +1,100 @@ +# Handbuch zur Ausführung der Implementierung + +## Vorraussetzungen/Abhängigkeiten + +* ein unix-artiges Betriebssystem +* Docker Version 1.10.x (getestet mit 1.10.1) + +Der Docker Daemon muss gestartet sein. Siehe [Installations Guide](https://docs.docker.com/engine/installation/). + +### Bauen der container + +```sh +docker build -t hasufell/haraka alpine-haraka +docker build -t hasufell/haraka-gateway alpine-haraka-gateway +docker build -t hasufell/swaks alpine-swaks +``` + +## Ausführung des Programms + +### Starten des Netzwerkes + +Die Container werden in einem Docker Netzwerk zusammengefasst und +können innerhalb dessen kommunizieren. + +```sh +docker network create haraka +``` + +Der Name des Netzwerkes _muss_ hier `haraka` lauten. + +### Starten der hops + +Diese sollten jeweils in einem Terminal gestartet werden, um den Debug +Output der Container beobachten zu können. + +```sh +docker run -ti \ + --name=hop1 \ + --net=haraka \ + hasufell/haraka + +docker run -ti \ + --name=hop2 \ + --net=haraka \ + hasufell/haraka + +docker run -ti \ + --name=hop3 \ + --net=haraka \ + hasufell/haraka + +docker run -ti \ + --name=rcpt \ + --net=haraka \ + hasufell/haraka +``` + +### Starten des SMTP gateways + +Dieser Server erstellt die initiale MystMail, wenn eine gewöhnliche E-Mail +ankommt und sendet sie an `hop1`. + +```sh +docker run -ti \ + --name=smtp-gateway \ + --net=haraka \ + hasufell/haraka-gateway +``` + +### Absenden einer E-Mail + +```sh +docker run -ti \ + --net=haraka \ + hasufell/swaks \ + swaks -t wurst@rcpt.haraka -f hasufell@smtp-gateway.com -s smtp-gateway.haraka -p 25 +``` + +## Beobachtung der Ergebnisse + +Dies zeigt die MystMail an jedem Hop. + +```sh +for i in hop1 hop2 hop3 rcpt ; do + docker exec -ti ${i} cat /tmp/mail.eml +done +``` + + +## Cleanup + +Falls die Container neu gestartet werden sollen. + +```sh +for i in hop1 hop2 hop3 rcpt smtp-gateway ; do + docker stop ${i} + docker rm ${i} +done +``` + diff --git a/Implementierung/LICENSE b/Implementierung/LICENSE new file mode 100644 index 0000000..3912109 --- /dev/null +++ b/Implementierung/LICENSE @@ -0,0 +1,340 @@ + GNU GENERAL PUBLIC LICENSE + Version 2, June 1991 + + Copyright (C) 1989, 1991 Free Software Foundation, Inc. + 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA + Everyone is permitted to copy and distribute verbatim copies + of this license document, but changing it is not allowed. + + Preamble + + The licenses for most software are designed to take away your +freedom to share and change it. By contrast, the GNU General Public +License is intended to guarantee your freedom to share and change free +software--to make sure the software is free for all its users. This +General Public License applies to most of the Free Software +Foundation's software and to any other program whose authors commit to +using it. (Some other Free Software Foundation software is covered by +the GNU Library General Public License instead.) You can apply it to +your programs, too. + + When we speak of free software, we are referring to freedom, not +price. Our General Public Licenses are designed to make sure that you +have the freedom to distribute copies of free software (and charge for +this service if you wish), that you receive source code or can get it +if you want it, that you can change the software or use pieces of it +in new free programs; and that you know you can do these things. + + To protect your rights, we need to make restrictions that forbid +anyone to deny you these rights or to ask you to surrender the rights. +These restrictions translate to certain responsibilities for you if you +distribute copies of the software, or if you modify it. + + For example, if you distribute copies of such a program, whether +gratis or for a fee, you must give the recipients all the rights that +you have. You must make sure that they, too, receive or can get the +source code. And you must show them these terms so they know their +rights. + + We protect your rights with two steps: (1) copyright the software, and +(2) offer you this license which gives you legal permission to copy, +distribute and/or modify the software. + + Also, for each author's protection and ours, we want to make certain +that everyone understands that there is no warranty for this free +software. If the software is modified by someone else and passed on, we +want its recipients to know that what they have is not the original, so +that any problems introduced by others will not reflect on the original +authors' reputations. + + Finally, any free program is threatened constantly by software +patents. We wish to avoid the danger that redistributors of a free +program will individually obtain patent licenses, in effect making the +program proprietary. To prevent this, we have made it clear that any +patent must be licensed for everyone's free use or not licensed at all. + + The precise terms and conditions for copying, distribution and +modification follow. + + GNU GENERAL PUBLIC LICENSE + TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION + + 0. This License applies to any program or other work which contains +a notice placed by the copyright holder saying it may be distributed +under the terms of this General Public License. The "Program", below, +refers to any such program or work, and a "work based on the Program" +means either the Program or any derivative work under copyright law: +that is to say, a work containing the Program or a portion of it, +either verbatim or with modifications and/or translated into another +language. (Hereinafter, translation is included without limitation in +the term "modification".) Each licensee is addressed as "you". + +Activities other than copying, distribution and modification are not +covered by this License; they are outside its scope. The act of +running the Program is not restricted, and the output from the Program +is covered only if its contents constitute a work based on the +Program (independent of having been made by running the Program). +Whether that is true depends on what the Program does. + + 1. You may copy and distribute verbatim copies of the Program's +source code as you receive it, in any medium, provided that you +conspicuously and appropriately publish on each copy an appropriate +copyright notice and disclaimer of warranty; keep intact all the +notices that refer to this License and to the absence of any warranty; +and give any other recipients of the Program a copy of this License +along with the Program. + +You may charge a fee for the physical act of transferring a copy, and +you may at your option offer warranty protection in exchange for a fee. + + 2. You may modify your copy or copies of the Program or any portion +of it, thus forming a work based on the Program, and copy and +distribute such modifications or work under the terms of Section 1 +above, provided that you also meet all of these conditions: + + a) You must cause the modified files to carry prominent notices + stating that you changed the files and the date of any change. + + b) You must cause any work that you distribute or publish, that in + whole or in part contains or is derived from the Program or any + part thereof, to be licensed as a whole at no charge to all third + parties under the terms of this License. + + c) If the modified program normally reads commands interactively + when run, you must cause it, when started running for such + interactive use in the most ordinary way, to print or display an + announcement including an appropriate copyright notice and a + notice that there is no warranty (or else, saying that you provide + a warranty) and that users may redistribute the program under + these conditions, and telling the user how to view a copy of this + License. (Exception: if the Program itself is interactive but + does not normally print such an announcement, your work based on + the Program is not required to print an announcement.) + +These requirements apply to the modified work as a whole. If +identifiable sections of that work are not derived from the Program, +and can be reasonably considered independent and separate works in +themselves, then this License, and its terms, do not apply to those +sections when you distribute them as separate works. But when you +distribute the same sections as part of a whole which is a work based +on the Program, the distribution of the whole must be on the terms of +this License, whose permissions for other licensees extend to the +entire whole, and thus to each and every part regardless of who wrote it. + +Thus, it is not the intent of this section to claim rights or contest +your rights to work written entirely by you; rather, the intent is to +exercise the right to control the distribution of derivative or +collective works based on the Program. + +In addition, mere aggregation of another work not based on the Program +with the Program (or with a work based on the Program) on a volume of +a storage or distribution medium does not bring the other work under +the scope of this License. + + 3. You may copy and distribute the Program (or a work based on it, +under Section 2) in object code or executable form under the terms of +Sections 1 and 2 above provided that you also do one of the following: + + a) Accompany it with the complete corresponding machine-readable + source code, which must be distributed under the terms of Sections + 1 and 2 above on a medium customarily used for software interchange; or, + + b) Accompany it with a written offer, valid for at least three + years, to give any third party, for a charge no more than your + cost of physically performing source distribution, a complete + machine-readable copy of the corresponding source code, to be + distributed under the terms of Sections 1 and 2 above on a medium + customarily used for software interchange; or, + + c) Accompany it with the information you received as to the offer + to distribute corresponding source code. (This alternative is + allowed only for noncommercial distribution and only if you + received the program in object code or executable form with such + an offer, in accord with Subsection b above.) + +The source code for a work means the preferred form of the work for +making modifications to it. For an executable work, complete source +code means all the source code for all modules it contains, plus any +associated interface definition files, plus the scripts used to +control compilation and installation of the executable. However, as a +special exception, the source code distributed need not include +anything that is normally distributed (in either source or binary +form) with the major components (compiler, kernel, and so on) of the +operating system on which the executable runs, unless that component +itself accompanies the executable. + +If distribution of executable or object code is made by offering +access to copy from a designated place, then offering equivalent +access to copy the source code from the same place counts as +distribution of the source code, even though third parties are not +compelled to copy the source along with the object code. + + 4. You may not copy, modify, sublicense, or distribute the Program +except as expressly provided under this License. Any attempt +otherwise to copy, modify, sublicense or distribute the Program is +void, and will automatically terminate your rights under this License. +However, parties who have received copies, or rights, from you under +this License will not have their licenses terminated so long as such +parties remain in full compliance. + + 5. You are not required to accept this License, since you have not +signed it. However, nothing else grants you permission to modify or +distribute the Program or its derivative works. These actions are +prohibited by law if you do not accept this License. Therefore, by +modifying or distributing the Program (or any work based on the +Program), you indicate your acceptance of this License to do so, and +all its terms and conditions for copying, distributing or modifying +the Program or works based on it. + + 6. Each time you redistribute the Program (or any work based on the +Program), the recipient automatically receives a license from the +original licensor to copy, distribute or modify the Program subject to +these terms and conditions. You may not impose any further +restrictions on the recipients' exercise of the rights granted herein. +You are not responsible for enforcing compliance by third parties to +this License. + + 7. If, as a consequence of a court judgment or allegation of patent +infringement or for any other reason (not limited to patent issues), +conditions are imposed on you (whether by court order, agreement or +otherwise) that contradict the conditions of this License, they do not +excuse you from the conditions of this License. If you cannot +distribute so as to satisfy simultaneously your obligations under this +License and any other pertinent obligations, then as a consequence you +may not distribute the Program at all. For example, if a patent +license would not permit royalty-free redistribution of the Program by +all those who receive copies directly or indirectly through you, then +the only way you could satisfy both it and this License would be to +refrain entirely from distribution of the Program. + +If any portion of this section is held invalid or unenforceable under +any particular circumstance, the balance of the section is intended to +apply and the section as a whole is intended to apply in other +circumstances. + +It is not the purpose of this section to induce you to infringe any +patents or other property right claims or to contest validity of any +such claims; this section has the sole purpose of protecting the +integrity of the free software distribution system, which is +implemented by public license practices. Many people have made +generous contributions to the wide range of software distributed +through that system in reliance on consistent application of that +system; it is up to the author/donor to decide if he or she is willing +to distribute software through any other system and a licensee cannot +impose that choice. + +This section is intended to make thoroughly clear what is believed to +be a consequence of the rest of this License. + + 8. If the distribution and/or use of the Program is restricted in +certain countries either by patents or by copyrighted interfaces, the +original copyright holder who places the Program under this License +may add an explicit geographical distribution limitation excluding +those countries, so that distribution is permitted only in or among +countries not thus excluded. In such case, this License incorporates +the limitation as if written in the body of this License. + + 9. The Free Software Foundation may publish revised and/or new versions +of the General Public License from time to time. Such new versions will +be similar in spirit to the present version, but may differ in detail to +address new problems or concerns. + +Each version is given a distinguishing version number. If the Program +specifies a version number of this License which applies to it and "any +later version", you have the option of following the terms and conditions +either of that version or of any later version published by the Free +Software Foundation. If the Program does not specify a version number of +this License, you may choose any version ever published by the Free Software +Foundation. + + 10. If you wish to incorporate parts of the Program into other free +programs whose distribution conditions are different, write to the author +to ask for permission. For software which is copyrighted by the Free +Software Foundation, write to the Free Software Foundation; we sometimes +make exceptions for this. Our decision will be guided by the two goals +of preserving the free status of all derivatives of our free software and +of promoting the sharing and reuse of software generally. + + NO WARRANTY + + 11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY +FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN +OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES +PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED +OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF +MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS +TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE +PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, +REPAIR OR CORRECTION. + + 12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING +WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR +REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, +INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING +OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED +TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY +YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER +PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE +POSSIBILITY OF SUCH DAMAGES. + + END OF TERMS AND CONDITIONS + + How to Apply These Terms to Your New Programs + + If you develop a new program, and you want it to be of the greatest +possible use to the public, the best way to achieve this is to make it +free software which everyone can redistribute and change under these terms. + + To do so, attach the following notices to the program. It is safest +to attach them to the start of each source file to most effectively +convey the exclusion of warranty; and each file should have at least +the "copyright" line and a pointer to where the full notice is found. + + + Copyright (C) + + This program is free software; you can redistribute it and/or modify + it under the terms of the GNU General Public License as published by + the Free Software Foundation; either version 2 of the License, or + (at your option) any later version. + + This program is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + GNU General Public License for more details. + + You should have received a copy of the GNU General Public License + along with this program; if not, write to the Free Software + Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA + + +Also add information on how to contact you by electronic and paper mail. + +If the program is interactive, make it output a short notice like this +when it starts in an interactive mode: + + Gnomovision version 69, Copyright (C) year name of author + Gnomovision comes with ABSOLUTELY NO WARRANTY; for details type `show w'. + This is free software, and you are welcome to redistribute it + under certain conditions; type `show c' for details. + +The hypothetical commands `show w' and `show c' should show the appropriate +parts of the General Public License. Of course, the commands you use may +be called something other than `show w' and `show c'; they could even be +mouse-clicks or menu items--whatever suits your program. + +You should also get your employer (if you work as a programmer) or your +school, if any, to sign a "copyright disclaimer" for the program, if +necessary. Here is a sample; alter the names: + + Yoyodyne, Inc., hereby disclaims all copyright interest in the program + `Gnomovision' (which makes passes at compilers) written by James Hacker. + + , 1 April 1989 + Ty Coon, President of Vice + +This General Public License does not permit incorporating your program into +proprietary programs. If your program is a subroutine library, you may +consider it more useful to permit linking proprietary applications with the +library. If this is what you want to do, use the GNU Library General +Public License instead of this License. diff --git a/Implementierung/Makefile b/Implementierung/Makefile new file mode 100644 index 0000000..3af5f20 --- /dev/null +++ b/Implementierung/Makefile @@ -0,0 +1,13 @@ +include ../common.mk + + +all: Handbuch.pdf + +Handbuch.pdf: Handbuch.md + $(PANDOC) $^ --latex-engine=xelatex -o $@ + +clean: + $(RM) Handbuch.pdf + +.PHONY: all clean + diff --git a/Implementierung/alpine-haraka-gateway/Dockerfile b/Implementierung/alpine-haraka-gateway/Dockerfile new file mode 100644 index 0000000..157a120 --- /dev/null +++ b/Implementierung/alpine-haraka-gateway/Dockerfile @@ -0,0 +1,50 @@ +FROM mhart/alpine-node:4 +MAINTAINER Julian Ospald + +ENV HARAKA_HOME /app +ENV HARAKA_LOGS /logs +ENV HARAKA_DATA /data +ENV PATH /usr/local/bin:$HARAKA_HOME/node_modules/.bin:$PATH +# node-gyp emits lots of warnings if HOME is set to / +ENV HOME /tmp +ENV HARAKA_VERSION 2.7.0 + +# the application is not started as this user, +# but Haraka can be configured to drop its privileges +# via smtp.ini +RUN echo "@testing http://nl.alpinelinux.org/alpine/edge/testing" \ + >> /etc/apk/repositories && \ + apk --no-cache add make gcc g++ python shadow@testing && \ + groupadd -r haraka && \ + useradd --comment "Haraka Server User" \ + --home "$HARAKA_HOME" \ + --shell /bin/false \ + --gid haraka \ + -r \ + -M \ + haraka && \ + npm install -g "Haraka@$HARAKA_VERSION" && \ + haraka --install "$HARAKA_HOME" && \ + apk --no-cache del make gcc g++ python shadow && \ + rm -rf /var/cache/apk/* + +COPY docker-entrypoint.sh /usr/local/bin/docker-entrypoint +COPY config /app/config +COPY plugins /app/plugins +RUN chmod 0755 /usr/local/bin/docker-entrypoint +RUN mkdir -p "$HARAKA_HOME" && \ + mkdir -p "$HARAKA_LOGS" && \ + mkdir -p "$HARAKA_DATA" && \ + chmod -R 0777 "$HARAKA_LOGS" && \ + chmod -R 0777 "$HARAKA_DATA" && \ + chown -R haraka:haraka "$HARAKA_HOME" "$HARAKA_LOGS" "$HARAKA_DATA" + +ENV HOME "$HARAKA_HOME" + +WORKDIR /app + +EXPOSE 25 + +ENTRYPOINT ["/usr/local/bin/docker-entrypoint"] +CMD [""] + diff --git a/Implementierung/alpine-haraka-gateway/README.md b/Implementierung/alpine-haraka-gateway/README.md new file mode 100644 index 0000000..da9cf7e --- /dev/null +++ b/Implementierung/alpine-haraka-gateway/README.md @@ -0,0 +1,4 @@ +`Dockerfile` and `docker-entrypoint.sh` based on +https://github.com/mhart/alpine-node and https://github.com/gbleux/docker-haraka + +`config/` and `plugins/`: Copyright Julian Ospald, 2016 diff --git a/Implementierung/alpine-haraka-gateway/config/plugins b/Implementierung/alpine-haraka-gateway/config/plugins new file mode 100644 index 0000000..484f517 --- /dev/null +++ b/Implementierung/alpine-haraka-gateway/config/plugins @@ -0,0 +1,9 @@ +my_mx +access +dnsbl +helo.checks +open_relay +data.headers +enable_parse_body +create_myst_mail +max_unrecognized_commands diff --git a/Implementierung/alpine-haraka-gateway/docker-entrypoint.sh b/Implementierung/alpine-haraka-gateway/docker-entrypoint.sh new file mode 100644 index 0000000..cb5b326 --- /dev/null +++ b/Implementierung/alpine-haraka-gateway/docker-entrypoint.sh @@ -0,0 +1,131 @@ +#!/bin/sh +# +# a wrapper script for the Haraka server process. when invoked with +# 'haraka' as first argument, it performs two additional steps: +# * ensure proper ownership and permissions of the persistence directories +# * capture the log statements from stdout and writes it to /logs +# +# all other arguments are passed through to the sub-command. +# +# the ownership and permissions flags is required, as docker maintains +# the settings from the host once a volume is mounted. the userid will +# most likely not match and the default bits of 0755 will prevent Haraka +# to write any data. the permission flags can be defined via the +# environment variable DOCKER_VOLUMES_CHMOD and the ownership via +# DOCKER_VOLUMES_CHOWN. if a variable is not defined, its respective +# action is not performed and the volume directories remain unchanged. +# +# logging to file is supported by Haraka, but only in daemon mode. this +# would cause the container to exit immediately. the SMTP server is +# therefor run in the forground, which causes log messages to end up +# in stdout. the wrapper script redirects it to files in /logs. in order +# to preserve log files from previous runs, a new logfile is created, +# together with a symlink pointing to the current file. the name of the +# log file can be configured via the environment variable +# HARAKA_LOG_DATE_FORMAT. its content is expected to be a valid +# date (1) format pattern. +# + +set -e + +HARAKA_LOG="haraka-latest.log" +HARAKA_BIN="haraka" + +# create a new log file and a symbolic link named 'haraka.log' +# to that file in the same directory. the symbolic link is +# overwritten if it exists. +# @param $1 {String} log filename (without directory path) +haraka_log_rotate() { + # remove symlink in case of persistent mount + test -e "$HARAKA_LOGS/haraka.log" && rm -f "$HARAKA_LOGS/haraka.log" + touch "$HARAKA_LOGS/$1" && ln -s "$HARAKA_LOGS/$1" "$HARAKA_LOGS/haraka.log" +} + +# change the ownership of the haraka persistence volumes. +# @param $1 {String} chown ownership rule +haraka_chown() { + chown -R "$1" "$HARAKA_LOGS" && \ + chown -R "$1" "$HARAKA_DATA" +} + +# change the permission flags of the haraka persistence volumes. +# @param $1 {String} chmod permission flags +haraka_chmod() { + chmod "$1" "$HARAKA_LOGS" && \ + chmod "$1" "$HARAKA_DATA" +} + +# set the filename of the log output. if the environment variable +# 'HARAKA_LOG_DATE_FORMAT' is set, it is used to generate the filename +# postfix using the 'date' command. the default is to use 'date +%s' as +# the filename postfix. +configure_log_filename() { + HARAKA_LOG_IDENT=$(date +"${HARAKA_LOG_DATE_FORMAT:-s}") + HARAKA_LOG="haraka-${HARAKA_LOG_IDENT}.log" +} + +# perform pre-boot actions before the SMTP server starts. +haraka_bootstrap() { + configure_log_filename + haraka_log_rotate "$HARAKA_LOG" + + if test "x$DOCKER_VOLUMES_CHOWN" != "x";then + haraka_chown "$DOCKER_VOLUMES_CHOWN" || return 1 + fi + + if test "x$DOCKER_VOLUMES_CHMOD" != "x";then + haraka_chmod "$DOCKER_VOLUMES_CHMOD" || return 1 + fi + + return 0 +} + +# ensure the environment has been set up correctly. +# @return {Number} a value greater than zero if anything is not OK +validate_haraka_env() { + if test "x$HARAKA_LOGS" = "x";then + echo "Haraka logs directory has not been set." 1>&2 + + return 1 + fi + + if test "x$HARAKA_DATA" = "x";then + echo "Haraka data directory has not been set." 1>&2 + + return 1 + fi + + return 0 +} + +exec_haraka() { + validate_haraka_env || exit 1 + haraka_bootstrap || exit 2 + + # tee outout so 'docker logs' and 'tail -f $LOG_VOLUME/haraka.log' works + exec "$HARAKA_BIN" -c /app "$@" 2>&1 | tee "$HARAKA_LOGS/$HARAKA_LOG" +} + +exec_help() { + echo "Either run this command without any parameters to execute" + echo "Haraka or specify the command which should be invoked." + + exit 0 +} + +# script entry point +main() { + case "${1:-haraka}" in + [hH]araka) + exec_haraka + ;; + --help|-h|-?) + exec_help + ;; + *) + exec "$@" + ;; + esac +} + +main "$@" diff --git a/Implementierung/alpine-haraka-gateway/plugins/.tern-project b/Implementierung/alpine-haraka-gateway/plugins/.tern-project new file mode 100644 index 0000000..4d9c084 --- /dev/null +++ b/Implementierung/alpine-haraka-gateway/plugins/.tern-project @@ -0,0 +1,12 @@ +{ + "libs": [ + "browser", + "underscore", + "jquery", + "Haraka" + ], + "plugins": { + "node": {}, + "complete_strings": {} + } +} diff --git a/Implementierung/alpine-haraka-gateway/plugins/create_myst_mail.js b/Implementierung/alpine-haraka-gateway/plugins/create_myst_mail.js new file mode 100644 index 0000000..249ca9f --- /dev/null +++ b/Implementierung/alpine-haraka-gateway/plugins/create_myst_mail.js @@ -0,0 +1,162 @@ +/* +Haraka Plugins for SMTP-based anonymization +Copyright (C) 2016 Julian Ospald + +This program is free software; you can redistribute it and/or +modify it under the terms of the GNU General Public License +as published by the Free Software Foundation; either version 2 +of the License, or (at your option) any later version. + +This program is distributed in the hope that it will be useful, +but WITHOUT ANY WARRANTY; without even the implied warranty of +MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +GNU General Public License for more details. + +You should have received a copy of the GNU General Public License +along with this program; if not, write to the Free Software +Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. +*/ + +var console = require('console'); +var fs = require('fs'); +var os = require('os'); + +var Address = require('./address').Address; +var MessageStream = require('./messagestream'); +var Transaction = require('./transaction').Transaction; +var config = require('./config'); +var uuid = require('./utils').uuid; + + + + +exports.hook_data_post = function(next, connection) { + + var mail = create_myst_mail(connection.transaction); + var t = transform_transaction(mail, connection); + connection.transaction = t; + + next(); +} + + +/** + * Transforms the current transaction based on a given + * raw email string. This always parses the body. + * + * 'mail_from' and 'rcpt_to' are filled in from the email headers. + * The uuid and results are taken from the old transaction. + * + * @param {string} email the raw full email, including headers + * @param {Connection} connection the current connection object + * @return {Transaction} the new transaction + */ +function transform_transaction(email, connection) { + var email_lines = email.split("\n"); + + // create new empty transaction + var t = new Transaction(); + t.uuid = connection.transaction.uuid; + t.parse_body = true; + t.message_stream = new MessageStream( + config.get('smtp.ini'), t.uuid, + t.header.header_list); + + // parse the email and fill the object + var i; + for (i = 0; i < email_lines.length; i++) { + t.add_data(email_lines[i] + "\n"); + } + t.end_data(function() { return ; }) + + // use old result object + t.results = connection.transaction.results; + + // overwrite mail_from and rcpt_to + var from_addr = t.header.get("From").match(/[^@<\s]+@[^@\s>]+/g)[0]; + var to_addr = t.header.get("To").match(/[^@<\s]+@[^@\s>]+/g)[0]; + t.mail_from = new Address(from_addr); + t.rcpt_to = [new Address(to_addr)]; + t.results.store.mail_from = new Address(from_addr); + t.results.store.rcpt_to = [new Address(to_addr)]; + + return t; +} + + +/** + * Check whether the given header object identifies as a myst mail header + * + * @param {Header} header + * @return {Boolean} true/false + */ +function is_myst_mail(header) { + if (header.get("X-Myst")) { + return true; + } + + return false; +} + + + +function myst_encrypt(string) { + var enc = new Buffer(string).toString('base64'); + + return enc; +} + + +function get_hops() { + // excludes the last hop + return ["hop1.haraka", "hop2.haraka", "hop3.haraka"]; +} + + +// TODO: randomize date? +function create_mail_for_hop(fromd, tod, date, bodytext) { + var from_addr = "myst@" + fromd; + var to_addr = "myst@" + tod; + + return ["Date: " + date, + "To: " + to_addr, + "From: " + from_addr, + "X-Myst: 1", + "Subject: ", + "", + myst_encrypt(bodytext), + ""].join("\n"); +} + + +function create_myst_mail(transaction) { + // recipient is always the last hop + var recipient = transaction.rcpt_to[0].host; + var hops = get_hops(); + hops.push(recipient); + + var date = transaction.header.get("Date").replace(/\n$/, ""); + + // innermost mail, untouched + var old_mail = get_raw_mail(transaction.body); + + var i; + var new_mail = old_mail; + for (i = hops.length - 1; i >= 0; i--) { + if (i == 0) { + // first hop, "from" must be the actual sender + var sender = transaction.mail_from.host; + new_mail = create_mail_for_hop(sender, hops[i], date, new_mail); + } else { + new_mail = create_mail_for_hop(hops[i-1], hops[i], date, new_mail); + } + } + + return new_mail; +} + + +function get_raw_mail(body) { + // TODO: doesn't handle multipart mime + return body.header.header_list.join("") + "\n" + body.bodytext; +} diff --git a/Implementierung/alpine-haraka-gateway/plugins/enable_parse_body.js b/Implementierung/alpine-haraka-gateway/plugins/enable_parse_body.js new file mode 100644 index 0000000..b7dc73e --- /dev/null +++ b/Implementierung/alpine-haraka-gateway/plugins/enable_parse_body.js @@ -0,0 +1,25 @@ +/* +Haraka Plugins for SMTP-based anonymization +Copyright (C) 2016 Julian Ospald + +This program is free software; you can redistribute it and/or +modify it under the terms of the GNU General Public License +as published by the Free Software Foundation; either version 2 +of the License, or (at your option) any later version. + +This program is distributed in the hope that it will be useful, +but WITHOUT ANY WARRANTY; without even the implied warranty of +MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +GNU General Public License for more details. + +You should have received a copy of the GNU General Public License +along with this program; if not, write to the Free Software +Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. +*/ + +// enable parsing of the mail body +exports.hook_data = function(next, connection, params) { + connection.transaction.parse_body = true; + return next(); +}; + diff --git a/Implementierung/alpine-haraka-gateway/plugins/my_mx.js b/Implementierung/alpine-haraka-gateway/plugins/my_mx.js new file mode 100644 index 0000000..3371843 --- /dev/null +++ b/Implementierung/alpine-haraka-gateway/plugins/my_mx.js @@ -0,0 +1,34 @@ +/* +Haraka Plugins for SMTP-based anonymization +Copyright (C) 2016 Julian Ospald + +This program is free software; you can redistribute it and/or +modify it under the terms of the GNU General Public License +as published by the Free Software Foundation; either version 2 +of the License, or (at your option) any later version. + +This program is distributed in the hope that it will be useful, +but WITHOUT ANY WARRANTY; without even the implied warranty of +MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +GNU General Public License for more details. + +You should have received a copy of the GNU General Public License +along with this program; if not, write to the Free Software +Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. +*/ + +'use strict'; + +var dns = require('dns'); + + +/** + * Fake get_mx hook, which just resolves the domain to its ip address. + * This causes outbound.js to avoid dns.resolve, which would otherwise + * mess up with our test system. + */ +exports.hook_get_mx = function(next, hmail, domain) { + dns.lookup(domain, function (err, address, family) { + return next(OK, address); + }) +} diff --git a/Implementierung/alpine-haraka-gateway/plugins/open_relay.js b/Implementierung/alpine-haraka-gateway/plugins/open_relay.js new file mode 100644 index 0000000..f62796b --- /dev/null +++ b/Implementierung/alpine-haraka-gateway/plugins/open_relay.js @@ -0,0 +1,46 @@ +/* +Haraka Plugins for SMTP-based anonymization +Copyright (C) 2016 Julian Ospald + +This program is free software; you can redistribute it and/or +modify it under the terms of the GNU General Public License +as published by the Free Software Foundation; either version 2 +of the License, or (at your option) any later version. + +This program is distributed in the hope that it will be useful, +but WITHOUT ANY WARRANTY; without even the implied warranty of +MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +GNU General Public License for more details. + +You should have received a copy of the GNU General Public License +along with this program; if not, write to the Free Software +Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. +*/ + +'use strict'; + + +var console = require('console'); +var Body = require('./mailbody').Body; + + +/** + * This acts as an open relay for non-local recipients + */ +exports.hook_rcpt = function(next, connection, params) { + if (is_local_rcpt(connection) == false) { + connection.relaying = true; + } + return next(OK); +} + + +function is_local_rcpt(connection) { + // TODO: get "ich.com" from the config files + // TODO: we currently only handle one recipient + if (connection.transaction.rcpt_to[0].host == "ich.com") { + return true; + } + return false; +} + diff --git a/Implementierung/alpine-haraka/Dockerfile b/Implementierung/alpine-haraka/Dockerfile new file mode 100644 index 0000000..157a120 --- /dev/null +++ b/Implementierung/alpine-haraka/Dockerfile @@ -0,0 +1,50 @@ +FROM mhart/alpine-node:4 +MAINTAINER Julian Ospald + +ENV HARAKA_HOME /app +ENV HARAKA_LOGS /logs +ENV HARAKA_DATA /data +ENV PATH /usr/local/bin:$HARAKA_HOME/node_modules/.bin:$PATH +# node-gyp emits lots of warnings if HOME is set to / +ENV HOME /tmp +ENV HARAKA_VERSION 2.7.0 + +# the application is not started as this user, +# but Haraka can be configured to drop its privileges +# via smtp.ini +RUN echo "@testing http://nl.alpinelinux.org/alpine/edge/testing" \ + >> /etc/apk/repositories && \ + apk --no-cache add make gcc g++ python shadow@testing && \ + groupadd -r haraka && \ + useradd --comment "Haraka Server User" \ + --home "$HARAKA_HOME" \ + --shell /bin/false \ + --gid haraka \ + -r \ + -M \ + haraka && \ + npm install -g "Haraka@$HARAKA_VERSION" && \ + haraka --install "$HARAKA_HOME" && \ + apk --no-cache del make gcc g++ python shadow && \ + rm -rf /var/cache/apk/* + +COPY docker-entrypoint.sh /usr/local/bin/docker-entrypoint +COPY config /app/config +COPY plugins /app/plugins +RUN chmod 0755 /usr/local/bin/docker-entrypoint +RUN mkdir -p "$HARAKA_HOME" && \ + mkdir -p "$HARAKA_LOGS" && \ + mkdir -p "$HARAKA_DATA" && \ + chmod -R 0777 "$HARAKA_LOGS" && \ + chmod -R 0777 "$HARAKA_DATA" && \ + chown -R haraka:haraka "$HARAKA_HOME" "$HARAKA_LOGS" "$HARAKA_DATA" + +ENV HOME "$HARAKA_HOME" + +WORKDIR /app + +EXPOSE 25 + +ENTRYPOINT ["/usr/local/bin/docker-entrypoint"] +CMD [""] + diff --git a/Implementierung/alpine-haraka/README.md b/Implementierung/alpine-haraka/README.md new file mode 100644 index 0000000..da9cf7e --- /dev/null +++ b/Implementierung/alpine-haraka/README.md @@ -0,0 +1,4 @@ +`Dockerfile` and `docker-entrypoint.sh` based on +https://github.com/mhart/alpine-node and https://github.com/gbleux/docker-haraka + +`config/` and `plugins/`: Copyright Julian Ospald, 2016 diff --git a/Implementierung/alpine-haraka/config/plugins b/Implementierung/alpine-haraka/config/plugins new file mode 100644 index 0000000..84684dc --- /dev/null +++ b/Implementierung/alpine-haraka/config/plugins @@ -0,0 +1,12 @@ +my_mx +access +dnsbl +helo.checks +open_relay +data.headers +enable_parse_body +my_transaction +data_post_write_mail +test_queue +max_unrecognized_commands + diff --git a/Implementierung/alpine-haraka/docker-entrypoint.sh b/Implementierung/alpine-haraka/docker-entrypoint.sh new file mode 100644 index 0000000..cb5b326 --- /dev/null +++ b/Implementierung/alpine-haraka/docker-entrypoint.sh @@ -0,0 +1,131 @@ +#!/bin/sh +# +# a wrapper script for the Haraka server process. when invoked with +# 'haraka' as first argument, it performs two additional steps: +# * ensure proper ownership and permissions of the persistence directories +# * capture the log statements from stdout and writes it to /logs +# +# all other arguments are passed through to the sub-command. +# +# the ownership and permissions flags is required, as docker maintains +# the settings from the host once a volume is mounted. the userid will +# most likely not match and the default bits of 0755 will prevent Haraka +# to write any data. the permission flags can be defined via the +# environment variable DOCKER_VOLUMES_CHMOD and the ownership via +# DOCKER_VOLUMES_CHOWN. if a variable is not defined, its respective +# action is not performed and the volume directories remain unchanged. +# +# logging to file is supported by Haraka, but only in daemon mode. this +# would cause the container to exit immediately. the SMTP server is +# therefor run in the forground, which causes log messages to end up +# in stdout. the wrapper script redirects it to files in /logs. in order +# to preserve log files from previous runs, a new logfile is created, +# together with a symlink pointing to the current file. the name of the +# log file can be configured via the environment variable +# HARAKA_LOG_DATE_FORMAT. its content is expected to be a valid +# date (1) format pattern. +# + +set -e + +HARAKA_LOG="haraka-latest.log" +HARAKA_BIN="haraka" + +# create a new log file and a symbolic link named 'haraka.log' +# to that file in the same directory. the symbolic link is +# overwritten if it exists. +# @param $1 {String} log filename (without directory path) +haraka_log_rotate() { + # remove symlink in case of persistent mount + test -e "$HARAKA_LOGS/haraka.log" && rm -f "$HARAKA_LOGS/haraka.log" + touch "$HARAKA_LOGS/$1" && ln -s "$HARAKA_LOGS/$1" "$HARAKA_LOGS/haraka.log" +} + +# change the ownership of the haraka persistence volumes. +# @param $1 {String} chown ownership rule +haraka_chown() { + chown -R "$1" "$HARAKA_LOGS" && \ + chown -R "$1" "$HARAKA_DATA" +} + +# change the permission flags of the haraka persistence volumes. +# @param $1 {String} chmod permission flags +haraka_chmod() { + chmod "$1" "$HARAKA_LOGS" && \ + chmod "$1" "$HARAKA_DATA" +} + +# set the filename of the log output. if the environment variable +# 'HARAKA_LOG_DATE_FORMAT' is set, it is used to generate the filename +# postfix using the 'date' command. the default is to use 'date +%s' as +# the filename postfix. +configure_log_filename() { + HARAKA_LOG_IDENT=$(date +"${HARAKA_LOG_DATE_FORMAT:-s}") + HARAKA_LOG="haraka-${HARAKA_LOG_IDENT}.log" +} + +# perform pre-boot actions before the SMTP server starts. +haraka_bootstrap() { + configure_log_filename + haraka_log_rotate "$HARAKA_LOG" + + if test "x$DOCKER_VOLUMES_CHOWN" != "x";then + haraka_chown "$DOCKER_VOLUMES_CHOWN" || return 1 + fi + + if test "x$DOCKER_VOLUMES_CHMOD" != "x";then + haraka_chmod "$DOCKER_VOLUMES_CHMOD" || return 1 + fi + + return 0 +} + +# ensure the environment has been set up correctly. +# @return {Number} a value greater than zero if anything is not OK +validate_haraka_env() { + if test "x$HARAKA_LOGS" = "x";then + echo "Haraka logs directory has not been set." 1>&2 + + return 1 + fi + + if test "x$HARAKA_DATA" = "x";then + echo "Haraka data directory has not been set." 1>&2 + + return 1 + fi + + return 0 +} + +exec_haraka() { + validate_haraka_env || exit 1 + haraka_bootstrap || exit 2 + + # tee outout so 'docker logs' and 'tail -f $LOG_VOLUME/haraka.log' works + exec "$HARAKA_BIN" -c /app "$@" 2>&1 | tee "$HARAKA_LOGS/$HARAKA_LOG" +} + +exec_help() { + echo "Either run this command without any parameters to execute" + echo "Haraka or specify the command which should be invoked." + + exit 0 +} + +# script entry point +main() { + case "${1:-haraka}" in + [hH]araka) + exec_haraka + ;; + --help|-h|-?) + exec_help + ;; + *) + exec "$@" + ;; + esac +} + +main "$@" diff --git a/Implementierung/alpine-haraka/plugins/.tern-project b/Implementierung/alpine-haraka/plugins/.tern-project new file mode 100644 index 0000000..4d9c084 --- /dev/null +++ b/Implementierung/alpine-haraka/plugins/.tern-project @@ -0,0 +1,12 @@ +{ + "libs": [ + "browser", + "underscore", + "jquery", + "Haraka" + ], + "plugins": { + "node": {}, + "complete_strings": {} + } +} diff --git a/Implementierung/alpine-haraka/plugins/add_myst_header.js b/Implementierung/alpine-haraka/plugins/add_myst_header.js new file mode 100644 index 0000000..7f0a6be --- /dev/null +++ b/Implementierung/alpine-haraka/plugins/add_myst_header.js @@ -0,0 +1,25 @@ +/* +Haraka Plugins for SMTP-based anonymization +Copyright (C) 2016 Julian Ospald + +This program is free software; you can redistribute it and/or +modify it under the terms of the GNU General Public License +as published by the Free Software Foundation; either version 2 +of the License, or (at your option) any later version. + +This program is distributed in the hope that it will be useful, +but WITHOUT ANY WARRANTY; without even the implied warranty of +MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +GNU General Public License for more details. + +You should have received a copy of the GNU General Public License +along with this program; if not, write to the Free Software +Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. +*/ + +// adds the myst header item to the current header list +exports.hook_mail = function(next, connection, params) { + connection.transaction.header.add("X-MYST", "1"); + return next(); +}; + diff --git a/Implementierung/alpine-haraka/plugins/data_post_write_mail.js b/Implementierung/alpine-haraka/plugins/data_post_write_mail.js new file mode 100644 index 0000000..3a6d4a6 --- /dev/null +++ b/Implementierung/alpine-haraka/plugins/data_post_write_mail.js @@ -0,0 +1,42 @@ +/* +Haraka Plugins for SMTP-based anonymization +Copyright (C) 2016 Julian Ospald + +This program is free software; you can redistribute it and/or +modify it under the terms of the GNU General Public License +as published by the Free Software Foundation; either version 2 +of the License, or (at your option) any later version. + +This program is distributed in the hope that it will be useful, +but WITHOUT ANY WARRANTY; without even the implied warranty of +MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +GNU General Public License for more details. + +You should have received a copy of the GNU General Public License +along with this program; if not, write to the Free Software +Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. +*/ + +var console = require('console'); +var fs = require('fs'); +var os = require('os'); + +var Address = require('./address').Address; +var Transaction = require('./transaction').Transaction; +var MessageStream = require('./messagestream'); +var config = require('./config'); +var uuid = require('./utils').uuid; + + +var tempDir = os.tmpdir(); + +// write mail to /tmp/mail.eml +exports.hook_data_post = function(next, connection) { + var ws = fs.createWriteStream(tempDir + '/mail.eml'); + ws.once('close', function () { + return next(OK); + }); + connection.transaction.message_stream.pipe(ws); +}; + + diff --git a/Implementierung/alpine-haraka/plugins/enable_parse_body.js b/Implementierung/alpine-haraka/plugins/enable_parse_body.js new file mode 100644 index 0000000..b7dc73e --- /dev/null +++ b/Implementierung/alpine-haraka/plugins/enable_parse_body.js @@ -0,0 +1,25 @@ +/* +Haraka Plugins for SMTP-based anonymization +Copyright (C) 2016 Julian Ospald + +This program is free software; you can redistribute it and/or +modify it under the terms of the GNU General Public License +as published by the Free Software Foundation; either version 2 +of the License, or (at your option) any later version. + +This program is distributed in the hope that it will be useful, +but WITHOUT ANY WARRANTY; without even the implied warranty of +MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +GNU General Public License for more details. + +You should have received a copy of the GNU General Public License +along with this program; if not, write to the Free Software +Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. +*/ + +// enable parsing of the mail body +exports.hook_data = function(next, connection, params) { + connection.transaction.parse_body = true; + return next(); +}; + diff --git a/Implementierung/alpine-haraka/plugins/my_mx.js b/Implementierung/alpine-haraka/plugins/my_mx.js new file mode 100644 index 0000000..3371843 --- /dev/null +++ b/Implementierung/alpine-haraka/plugins/my_mx.js @@ -0,0 +1,34 @@ +/* +Haraka Plugins for SMTP-based anonymization +Copyright (C) 2016 Julian Ospald + +This program is free software; you can redistribute it and/or +modify it under the terms of the GNU General Public License +as published by the Free Software Foundation; either version 2 +of the License, or (at your option) any later version. + +This program is distributed in the hope that it will be useful, +but WITHOUT ANY WARRANTY; without even the implied warranty of +MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +GNU General Public License for more details. + +You should have received a copy of the GNU General Public License +along with this program; if not, write to the Free Software +Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. +*/ + +'use strict'; + +var dns = require('dns'); + + +/** + * Fake get_mx hook, which just resolves the domain to its ip address. + * This causes outbound.js to avoid dns.resolve, which would otherwise + * mess up with our test system. + */ +exports.hook_get_mx = function(next, hmail, domain) { + dns.lookup(domain, function (err, address, family) { + return next(OK, address); + }) +} diff --git a/Implementierung/alpine-haraka/plugins/my_transaction.js b/Implementierung/alpine-haraka/plugins/my_transaction.js new file mode 100644 index 0000000..7fff5fb --- /dev/null +++ b/Implementierung/alpine-haraka/plugins/my_transaction.js @@ -0,0 +1,168 @@ +/* +Haraka Plugins for SMTP-based anonymization +Copyright (C) 2016 Julian Ospald + +This program is free software; you can redistribute it and/or +modify it under the terms of the GNU General Public License +as published by the Free Software Foundation; either version 2 +of the License, or (at your option) any later version. + +This program is distributed in the hope that it will be useful, +but WITHOUT ANY WARRANTY; without even the implied warranty of +MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +GNU General Public License for more details. + +You should have received a copy of the GNU General Public License +along with this program; if not, write to the Free Software +Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. +*/ + +var console = require('console'); +var fs = require('fs'); +var os = require('os'); + +var Address = require('./address').Address; +var MessageStream = require('./messagestream'); +var Transaction = require('./transaction').Transaction; +var config = require('./config'); +var uuid = require('./utils').uuid; +var outbound = require('./outbound'); + + + +exports.hook_data_post = function(next, connection) { + + // if we have a myst mail, we need to inject our Protocol + if (is_myst_mail(connection.transaction.header)) { + // we decrypt the mail body and treat it as raw mail data + var decrypted_email = myst_decrypt(connection.transaction.body.bodytext); + + // replace the current transaction object with the new one based + // on the decrypted_mail + var t = transform_transaction(decrypted_email, connection); + connection.transaction = t; + + // the unpacked mail is a myst mail too, this means we have to relay it, + // otherwise it's handled by the normal haraka delivery methods + if (is_myst_mail(connection.transaction.header)) { + connection.relaying = true; + } + } + + // let the other handlers do what they want, we are finished injecting + // our logic, the rest is still SMTP compliant + next(); +} + + +/** + * Transforms the current transaction based on a given + * raw email string. This always parses the body. + * + * 'mail_from' and 'rcpt_to' are filled in from the email headers. + * The uuid and results are taken from the old transaction. + * + * @param {string} email the raw full email, including headers + * @param {Connection} connection the current connection object + * @return {Transaction} the new transaction + */ +function transform_transaction(email, connection) { + var email_lines = email.split("\n"); + + // create new empty transaction + var t = new Transaction(); + t.uuid = connection.transaction.uuid; + t.parse_body = true; + t.message_stream = new MessageStream( + config.get('smtp.ini'), t.uuid, + t.header.header_list); + + // parse the email and fill the object + var i; + for (i = 0; i < email_lines.length; i++) { + t.add_data(email_lines[i] + "\n"); + } + t.end_data(function() { return ; }) + + // use old result object + t.results = connection.transaction.results; + + // overwrite mail_from and rcpt_to + var from_addr = t.header.get("From").match(/[^@<\s]+@[^@\s>]+/g)[0]; + var to_addr = t.header.get("To").match(/[^@<\s]+@[^@\s>]+/g); + var addresses = []; + for (i = 0; i < to_addr.length; i++) { + addresses.push(new Address(to_addr[i])); + } + + t.mail_from = new Address(from_addr); + t.rcpt_to = addresses; + t.results.store.mail_from = new Address(from_addr); + t.results.store.rcpt_to = addresses; + + return t; +} + + +/** + * Check whether the given header object identifies as a myst mail header + * + * @param {Header} header + * @return {Boolean} true/false + */ +function is_myst_mail(header) { + if (header.get("X-Myst")) { + return true; + } + + return false; +} + + +/** + * Decrypts the whole mail and return + * + * @param {string} string encrypted string + * @return {string} the decrypted string + */ +function myst_decrypt(string) { + var b = new Buffer(string, 'base64').toString('utf8'); + return b; +} + + +function send_myst_mail(email, connection) { + var email_lines = email.split("\n"); + + // create transaction for our mail, to make use of the internal parser + var t = new Transaction(); + t.uuid = connection.transaction.uuid; + t.parse_body = true; + t.message_stream = new MessageStream( + config.get('smtp.ini'), t.uuid, + t.header.header_list); + + // parse the email and fill the object + var i; + for (i = 0; i < email_lines.length; i++) { + t.add_data(email_lines[i] + "\n"); + } + t.end_data(function() { return ; }) + + // use old result object, otherwise we get errors + t.results = connection.transaction.results; + + // finally get mail_from and rcpt_to + // TODO: support multiple recipients for last hop + var from_addr = t.header.get("From").match(/[^@<\s]+@[^@\s>]+/g)[0]; + var to_addr = t.header.get("To").match(/[^@<\s]+@[^@\s>]+/g); + + var outnext = function(code, msg) { + next(OK); + } + + // send mail + for (i = 0; i < to_addr.length; i++) { + outbound.send_email(from_addr, to_addr[i], email, outnext); + } +} diff --git a/Implementierung/alpine-haraka/plugins/myst_send.js b/Implementierung/alpine-haraka/plugins/myst_send.js new file mode 100644 index 0000000..2ad048b --- /dev/null +++ b/Implementierung/alpine-haraka/plugins/myst_send.js @@ -0,0 +1,29 @@ +/* +Haraka Plugins for SMTP-based anonymization +Copyright (C) 2016 Julian Ospald + +This program is free software; you can redistribute it and/or +modify it under the terms of the GNU General Public License +as published by the Free Software Foundation; either version 2 +of the License, or (at your option) any later version. + +This program is distributed in the hope that it will be useful, +but WITHOUT ANY WARRANTY; without even the implied warranty of +MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +GNU General Public License for more details. + +You should have received a copy of the GNU General Public License +along with this program; if not, write to the Free Software +Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. +*/ + +'use strict'; + + +var console = require('console'); + + +exports.hook_send_email = function(next, hmail) { + return next(OK); +} + diff --git a/Implementierung/alpine-haraka/plugins/open_relay.js b/Implementierung/alpine-haraka/plugins/open_relay.js new file mode 100644 index 0000000..f2f6662 --- /dev/null +++ b/Implementierung/alpine-haraka/plugins/open_relay.js @@ -0,0 +1,46 @@ +/* +Haraka Plugins for SMTP-based anonymization +Copyright (C) 2016 Julian Ospald + +This program is free software; you can redistribute it and/or +modify it under the terms of the GNU General Public License +as published by the Free Software Foundation; either version 2 +of the License, or (at your option) any later version. + +This program is distributed in the hope that it will be useful, +but WITHOUT ANY WARRANTY; without even the implied warranty of +MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +GNU General Public License for more details. + +You should have received a copy of the GNU General Public License +along with this program; if not, write to the Free Software +Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. +*/ + +'use strict'; + + +var console = require('console'); +var Body = require('./mailbody').Body; + + +/** + * This acts as an open relay for non-local recipients + */ +exports.hook_rcpt = function(next, connection, params) { + if (is_local_rcpt(connection) == false) { + connection.relaying = true; + } + return next(OK); +} + + +function is_local_rcpt(connection) { + // TODO: get "rcpt.haraka" from the config files + // TODO: we currently only handle one recipient + if (connection.transaction.rcpt_to[0].host == "rcpt.haraka") { + return true; + } + return false; +} + diff --git a/Implementierung/alpine-haraka/plugins/test_queue.js b/Implementierung/alpine-haraka/plugins/test_queue.js new file mode 100644 index 0000000..aae0047 --- /dev/null +++ b/Implementierung/alpine-haraka/plugins/test_queue.js @@ -0,0 +1,42 @@ +/* +Haraka Plugins for SMTP-based anonymization +Copyright (C) 2016 Julian Ospald + +This program is free software; you can redistribute it and/or +modify it under the terms of the GNU General Public License +as published by the Free Software Foundation; either version 2 +of the License, or (at your option) any later version. + +This program is distributed in the hope that it will be useful, +but WITHOUT ANY WARRANTY; without even the implied warranty of +MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +GNU General Public License for more details. + +You should have received a copy of the GNU General Public License +along with this program; if not, write to the Free Software +Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. +*/ + +var console = require('console'); +var fs = require('fs'); +var os = require('os'); + +var Address = require('./address').Address; +var Transaction = require('./transaction').Transaction; +var MessageStream = require('./messagestream'); +var config = require('./config'); +var uuid = require('./utils').uuid; + + +var tempDir = os.tmpdir(); + +// write mail to /tmp/mail.eml +exports.hook_queue = function(next, connection) { + var ws = fs.createWriteStream(tempDir + '/mail.eml'); + ws.once('close', function () { + return next(OK); + }); + connection.transaction.message_stream.pipe(ws); +}; + + diff --git a/Implementierung/alpine-swaks/Dockerfile b/Implementierung/alpine-swaks/Dockerfile new file mode 100644 index 0000000..0cb6340 --- /dev/null +++ b/Implementierung/alpine-swaks/Dockerfile @@ -0,0 +1,10 @@ +FROM alpine:3.3 +MAINTAINER Julian Ospald + +RUN echo "@testing http://nl.alpinelinux.org/alpine/edge/testing" \ + >> /etc/apk/repositories && \ + apk --no-cache add swaks@testing && \ + rm -rf /var/cache/apk/* + +EXPOSE 25 + diff --git a/Implementierung/alpine-swaks/README.md b/Implementierung/alpine-swaks/README.md new file mode 100644 index 0000000..aa37147 --- /dev/null +++ b/Implementierung/alpine-swaks/README.md @@ -0,0 +1 @@ +Copyright Julian Ospald, 2016 diff --git a/Makefile b/Makefile new file mode 100644 index 0000000..0c9274a --- /dev/null +++ b/Makefile @@ -0,0 +1,21 @@ +include common.mk + + +all: Bachelorthesis Handbuch + +Bachelorthesis: + $(MAKE) -C Bachelorthesis + $(LN_S) Bachelorthesis/Bachelorthesis.pdf . + +Handbuch: + $(MAKE) -C Implementierung + $(LN_S) Implementierung/Handbuch.pdf . + +clean: + $(MAKE) -C Bachelorthesis clean + $(MAKE) -C Implementierung clean + $(RM) Bachelorthesis.pdf Handbuch.pdf + + +.PHONY: all clean Bachelorthesis Handbuch + diff --git a/README.md b/README.md new file mode 100644 index 0000000..43ac3ae --- /dev/null +++ b/README.md @@ -0,0 +1,9 @@ +## Julian Ospald's Bachelorthesis + +FH Bielefeld, Computer Science + +Topic: Betrachtung von Datensicherheit in E-Mail Systemen und Entwicklung eines SMTP-basierten Anonymisierungs-Algorithmus + +LICENSE of the LaTeX source and thesis is: [Attribution-NonCommercial-ShareAlike 4.0 International](https://creativecommons.org/licenses/by-nc-sa/4.0/legalcode) + +LICENSE of the Implementation is: [GPL-2](https://www.gnu.org/licenses/old-licenses/gpl-2.0.html) diff --git a/RFCs/rfc1521.txt b/RFCs/rfc1521.txt new file mode 100644 index 0000000..074ba41 --- /dev/null +++ b/RFCs/rfc1521.txt @@ -0,0 +1,4539 @@ + + + + + + +Network Working Group N. Borenstein +Request for Comments: 1521 Bellcore +Obsoletes: 1341 N. Freed +Category: Standards Track Innosoft + September 1993 + + + MIME (Multipurpose Internet Mail Extensions) Part One: + Mechanisms for Specifying and Describing + the Format of Internet Message Bodies + +Status of this Memo + + This RFC specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" for the standardization state and status + of this protocol. Distribution of this memo is unlimited. + +Abstract + + STD 11, RFC 822 defines a message representation protocol which + specifies considerable detail about message headers, but which leaves + the message content, or message body, as flat ASCII text. This + document redefines the format of message bodies to allow multi-part + textual and non-textual message bodies to be represented and + exchanged without loss of information. This is based on earlier work + documented in RFC 934 and STD 11, RFC 1049, but extends and revises + that work. Because RFC 822 said so little about message bodies, this + document is largely orthogonal to (rather than a revision of) RFC + 822. + + In particular, this document is designed to provide facilities to + include multiple objects in a single message, to represent body text + in character sets other than US-ASCII, to represent formatted multi- + font text messages, to represent non-textual material such as images + and audio fragments, and generally to facilitate later extensions + defining new types of Internet mail for use by cooperating mail + agents. + + This document does NOT extend Internet mail header fields to permit + anything other than US-ASCII text data. Such extensions are the + subject of a companion document [RFC-1522]. + + This document is a revision of RFC 1341. Significant differences + from RFC 1341 are summarized in Appendix H. + + + + + +Borenstein & Freed [Page 1] + +RFC 1521 MIME September 1993 + + +Table of Contents + + 1. Introduction....................................... 3 + 2. Notations, Conventions, and Generic BNF Grammar.... 6 + 3. The MIME-Version Header Field...................... 7 + 4. The Content-Type Header Field...................... 9 + 5. The Content-Transfer-Encoding Header Field......... 13 + 5.1. Quoted-Printable Content-Transfer-Encoding......... 18 + 5.2. Base64 Content-Transfer-Encoding................... 21 + 6. Additional Content-Header Fields................... 23 + 6.1. Optional Content-ID Header Field................... 23 + 6.2. Optional Content-Description Header Field.......... 24 + 7. The Predefined Content-Type Values................. 24 + 7.1. The Text Content-Type.............................. 24 + 7.1.1. The charset parameter.............................. 25 + 7.1.2. The Text/plain subtype............................. 28 + 7.2. The Multipart Content-Type......................... 28 + 7.2.1. Multipart: The common syntax...................... 29 + 7.2.2. The Multipart/mixed (primary) subtype.............. 34 + 7.2.3. The Multipart/alternative subtype.................. 34 + 7.2.4. The Multipart/digest subtype....................... 36 + 7.2.5. The Multipart/parallel subtype..................... 37 + 7.2.6. Other Multipart subtypes........................... 37 + 7.3. The Message Content-Type........................... 38 + 7.3.1. The Message/rfc822 (primary) subtype............... 38 + 7.3.2. The Message/Partial subtype........................ 39 + 7.3.3. The Message/External-Body subtype.................. 42 + 7.3.3.1. The "ftp" and "tftp" access-types............... 44 + 7.3.3.2. The "anon-ftp" access-type...................... 45 + 7.3.3.3. The "local-file" and "afs" access-types......... 45 + 7.3.3.4. The "mail-server" access-type................... 45 + 7.3.3.5. Examples and Further Explanations............... 46 + 7.4. The Application Content-Type....................... 49 + 7.4.1. The Application/Octet-Stream (primary) subtype..... 50 + 7.4.2. The Application/PostScript subtype................. 50 + 7.4.3. Other Application subtypes......................... 53 + 7.5. The Image Content-Type............................. 53 + 7.6. The Audio Content-Type............................. 54 + 7.7. The Video Content-Type............................. 54 + 7.8. Experimental Content-Type Values................... 54 + 8. Summary............................................ 56 + 9. Security Considerations............................ 56 + 10. Authors' Addresses................................. 57 + 11. Acknowledgements................................... 58 + Appendix A -- Minimal MIME-Conformance.................... 60 + Appendix B -- General Guidelines For Sending Email Data... 63 + Appendix C -- A Complex Multipart Example................. 66 + Appendix D -- Collected Grammar........................... 68 + + + +Borenstein & Freed [Page 2] + +RFC 1521 MIME September 1993 + + + Appendix E -- IANA Registration Procedures................ 72 + E.1 Registration of New Content-type/subtype Values...... 72 + E.2 Registration of New Access-type Values + for Message/external-body............................ 73 + Appendix F -- Summary of the Seven Content-types.......... 74 + Appendix G -- Canonical Encoding Model.................... 76 + Appendix H -- Changes from RFC 1341....................... 78 + References................................................ 80 + +1. Introduction + + Since its publication in 1982, STD 11, RFC 822 [RFC-822] has defined + the standard format of textual mail messages on the Internet. Its + success has been such that the RFC 822 format has been adopted, + wholly or partially, well beyond the confines of the Internet and the + Internet SMTP transport defined by STD 10, RFC 821 [RFC-821]. As the + format has seen wider use, a number of limitations have proven + increasingly restrictive for the user community. + + RFC 822 was intended to specify a format for text messages. As such, + non-text messages, such as multimedia messages that might include + audio or images, are simply not mentioned. Even in the case of text, + however, RFC 822 is inadequate for the needs of mail users whose + languages require the use of character sets richer than US ASCII + [US-ASCII]. Since RFC 822 does not specify mechanisms for mail + containing audio, video, Asian language text, or even text in most + European languages, additional specifications are needed. + + One of the notable limitations of RFC 821/822 based mail systems is + the fact that they limit the contents of electronic mail messages to + relatively short lines of seven-bit ASCII. This forces users to + convert any non-textual data that they may wish to send into seven- + bit bytes representable as printable ASCII characters before invoking + a local mail UA (User Agent, a program with which human users send + and receive mail). Examples of such encodings currently used in the + Internet include pure hexadecimal, uuencode, the 3-in-4 base 64 + scheme specified in RFC 1421, the Andrew Toolkit Representation + [ATK], and many others. + + The limitations of RFC 822 mail become even more apparent as gateways + are designed to allow for the exchange of mail messages between RFC + 822 hosts and X.400 hosts. X.400 [X400] specifies mechanisms for the + inclusion of non-textual body parts within electronic mail messages. + The current standards for the mapping of X.400 messages to RFC 822 + messages specify either that X.400 non-textual body parts must be + converted to (not encoded in) an ASCII format, or that they must be + discarded, notifying the RFC 822 user that discarding has occurred. + This is clearly undesirable, as information that a user may wish to + + + +Borenstein & Freed [Page 3] + +RFC 1521 MIME September 1993 + + + receive is lost. Even though a user's UA may not have the capability + of dealing with the non-textual body part, the user might have some + mechanism external to the UA that can extract useful information from + the body part. Moreover, it does not allow for the fact that the + message may eventually be gatewayed back into an X.400 message + handling system (i.e., the X.400 message is "tunneled" through + Internet mail), where the non-textual information would definitely + become useful again. + + This document describes several mechanisms that combine to solve most + of these problems without introducing any serious incompatibilities + with the existing world of RFC 822 mail. In particular, it + describes: + + 1. A MIME-Version header field, which uses a version number to + declare a message to be conformant with this specification and + allows mail processing agents to distinguish between such + messages and those generated by older or non-conformant software, + which is presumed to lack such a field. + + 2. A Content-Type header field, generalized from RFC 1049 [RFC-1049], + which can be used to specify the type and subtype of data in the + body of a message and to fully specify the native representation + (encoding) of such data. + + 2.a. A "text" Content-Type value, which can be used to represent + textual information in a number of character sets and + formatted text description languages in a standardized + manner. + + 2.b. A "multipart" Content-Type value, which can be used to + combine several body parts, possibly of differing types of + data, into a single message. + + 2.c. An "application" Content-Type value, which can be used to + transmit application data or binary data, and hence, among + other uses, to implement an electronic mail file transfer + service. + + 2.d. A "message" Content-Type value, for encapsulating another + mail message. + + 2.e An "image" Content-Type value, for transmitting still image + (picture) data. + + 2.f. An "audio" Content-Type value, for transmitting audio or + voice data. + + + + +Borenstein & Freed [Page 4] + +RFC 1521 MIME September 1993 + + + 2.g. A "video" Content-Type value, for transmitting video or + moving image data, possibly with audio as part of the + composite video data format. + + 3. A Content-Transfer-Encoding header field, which can be used to + specify an auxiliary encoding that was applied to the data in + order to allow it to pass through mail transport mechanisms which + may have data or character set limitations. + + 4. Two additional header fields that can be used to further describe + the data in a message body, the Content-ID and Content- + Description header fields. + + MIME has been carefully designed as an extensible mechanism, and it + is expected that the set of content-type/subtype pairs and their + associated parameters will grow significantly with time. Several + other MIME fields, notably including character set names, are likely + to have new values defined over time. In order to ensure that the + set of such values is developed in an orderly, well-specified, and + public manner, MIME defines a registration process which uses the + Internet Assigned Numbers Authority (IANA) as a central registry for + such values. Appendix E provides details about how IANA registration + is accomplished. + + Finally, to specify and promote interoperability, Appendix A of this + document provides a basic applicability statement for a subset of the + above mechanisms that defines a minimal level of "conformance" with + this document. + + HISTORICAL NOTE: Several of the mechanisms described in this + document may seem somewhat strange or even baroque at first + reading. It is important to note that compatibility with existing + standards AND robustness across existing practice were two of the + highest priorities of the working group that developed this + document. In particular, compatibility was always favored over + elegance. + + MIME was first defined and published as RFCs 1341 and 1342 [RFC-1341] + [RFC-1342]. This document is a relatively minor updating of RFC + 1341, and is intended to supersede it. The differences between this + document and RFC 1341 are summarized in Appendix H. Please refer to + the current edition of the "IAB Official Protocol Standards" for the + standardization state and status of this protocol. Several other RFC + documents will be of interest to the MIME implementor, in particular + [RFC 1343], [RFC-1344], and [RFC-1345]. + + + + + + +Borenstein & Freed [Page 5] + +RFC 1521 MIME September 1993 + + +2. Notations, Conventions, and Generic BNF Grammar + + This document is being published in two versions, one as plain ASCII + text and one as PostScript (PostScript is a trademark of Adobe + Systems Incorporated.). While the text version is the official + specification, some will find the PostScript version easier to read. + The textual contents are identical. An Andrew-format copy of this + document is also available from the first author (Borenstein). + + Although the mechanisms specified in this document are all described + in prose, most are also described formally in the modified BNF + notation of RFC 822. Implementors will need to be familiar with this + notation in order to understand this specification, and are referred + to RFC 822 for a complete explanation of the modified BNF notation. + + Some of the modified BNF in this document makes reference to + syntactic entities that are defined in RFC 822 and not in this + document. A complete formal grammar, then, is obtained by combining + the collected grammar appendix of this document with that of RFC 822 + plus the modifications to RFC 822 defined in RFC 1123, which + specifically changes the syntax for `return', `date' and `mailbox'. + + The term CRLF, in this document, refers to the sequence of the two + ASCII characters CR (13) and LF (10) which, taken together, in this + order, denote a line break in RFC 822 mail. + + The term "character set" is used in this document to refer to a + method used with one or more tables to convert encoded text to a + series of octets. This definition is intended to allow various kinds + of text encodings, from simple single-table mappings such as ASCII to + complex table switching methods such as those that use ISO 2022's + techniques. However, a MIME character set name must fully specify + the mapping to be performed. + + The term "message", when not further qualified, means either the + (complete or "top-level") message being transferred on a network, or + a message encapsulated in a body of type "message". + + The term "body part", in this document, means one of the parts of the + body of a multipart entity. A body part has a header and a body, so + it makes sense to speak about the body of a body part. + + The term "entity", in this document, means either a message or a body + part. All kinds of entities share the property that they have a + header and a body. + + The term "body", when not further qualified, means the body of an + entity, that is the body of either a message or of a body part. + + + +Borenstein & Freed [Page 6] + +RFC 1521 MIME September 1993 + + + NOTE: The previous four definitions are clearly circular. This is + unavoidable, since the overall structure of a MIME message is + indeed recursive. + + In this document, all numeric and octet values are given in decimal + notation. + + It must be noted that Content-Type values, subtypes, and parameter + names as defined in this document are case-insensitive. However, + parameter values are case-sensitive unless otherwise specified for + the specific parameter. + + FORMATTING NOTE: This document has been carefully formatted for + ease of reading. The PostScript version of this document, in + particular, places notes like this one, which may be skipped by + the reader, in a smaller, italicized, font, and indents it as + well. In the text version, only the indentation is preserved, so + if you are reading the text version of this you might consider + using the PostScript version instead. However, all such notes will + be indented and preceded by "NOTE:" or some similar introduction, + even in the text version. + + The primary purpose of these non-essential notes is to convey + information about the rationale of this document, or to place this + document in the proper historical or evolutionary context. Such + information may be skipped by those who are focused entirely on + building a conformant implementation, but may be of use to those + who wish to understand why this document is written as it is. + + For ease of recognition, all BNF definitions have been placed in a + fixed-width font in the PostScript version of this document. + +3. The MIME-Version Header Field + + Since RFC 822 was published in 1982, there has really been only one + format standard for Internet messages, and there has been little + perceived need to declare the format standard in use. This document + is an independent document that complements RFC 822. Although the + extensions in this document have been defined in such a way as to be + compatible with RFC 822, there are still circumstances in which it + might be desirable for a mail-processing agent to know whether a + message was composed with the new standard in mind. + + Therefore, this document defines a new header field, "MIME-Version", + which is to be used to declare the version of the Internet message + body format standard in use. + + Messages composed in accordance with this document MUST include such + + + +Borenstein & Freed [Page 7] + +RFC 1521 MIME September 1993 + + + a header field, with the following verbatim text: + + MIME-Version: 1.0 + + The presence of this header field is an assertion that the message + has been composed in compliance with this document. + + Since it is possible that a future document might extend the message + format standard again, a formal BNF is given for the content of the + MIME-Version field: + + version := "MIME-Version" ":" 1*DIGIT "." 1*DIGIT + + Thus, future format specifiers, which might replace or extend "1.0", + are constrained to be two integer fields, separated by a period. If + a message is received with a MIME-version value other than "1.0", it + cannot be assumed to conform with this specification. + + Note that the MIME-Version header field is required at the top level + of a message. It is not required for each body part of a multipart + entity. It is required for the embedded headers of a body of type + "message" if and only if the embedded message is itself claimed to be + MIME-conformant. + + It is not possible to fully specify how a mail reader that conforms + with MIME as defined in this document should treat a message that + might arrive in the future with some value of MIME-Version other than + "1.0". However, conformant software is encouraged to check the + version number and at least warn the user if an unrecognized MIME- + version is encountered. + + It is also worth noting that version control for specific content- + types is not accomplished using the MIME-Version mechanism. In + particular, some formats (such as application/postscript) have + version numbering conventions that are internal to the document + format. Where such conventions exist, MIME does nothing to supersede + them. Where no such conventions exist, a MIME type might use a + "version" parameter in the content-type field if necessary. + + NOTE TO IMPLEMENTORS: All header fields defined in this document, + including MIME-Version, Content-type, etc., are subject to the + general syntactic rules for header fields specified in RFC 822. In + particular, all can include comments, which means that the following + two MIME-Version fields are equivalent: + + MIME-Version: 1.0 + MIME-Version: 1.0 (Generated by GBD-killer 3.7) + + + + +Borenstein & Freed [Page 8] + +RFC 1521 MIME September 1993 + + +4. The Content-Type Header Field + + The purpose of the Content-Type field is to describe the data + contained in the body fully enough that the receiving user agent can + pick an appropriate agent or mechanism to present the data to the + user, or otherwise deal with the data in an appropriate manner. + + HISTORICAL NOTE: The Content-Type header field was first defined in + RFC 1049. RFC 1049 Content-types used a simpler and less powerful + syntax, but one that is largely compatible with the mechanism given + here. + + The Content-Type header field is used to specify the nature of the + data in the body of an entity, by giving type and subtype + identifiers, and by providing auxiliary information that may be + required for certain types. After the type and subtype names, the + remainder of the header field is simply a set of parameters, + specified in an attribute/value notation. The set of meaningful + parameters differs for the different types. In particular, there are + NO globally-meaningful parameters that apply to all content-types. + Global mechanisms are best addressed, in the MIME model, by the + definition of additional Content-* header fields. The ordering of + parameters is not significant. Among the defined parameters is a + "charset" parameter by which the character set used in the body may + be declared. Comments are allowed in accordance with RFC 822 rules + for structured header fields. + + In general, the top-level Content-Type is used to declare the general + type of data, while the subtype specifies a specific format for that + type of data. Thus, a Content-Type of "image/xyz" is enough to tell + a user agent that the data is an image, even if the user agent has no + knowledge of the specific image format "xyz". Such information can + be used, for example, to decide whether or not to show a user the raw + data from an unrecognized subtype -- such an action might be + reasonable for unrecognized subtypes of text, but not for + unrecognized subtypes of image or audio. For this reason, registered + subtypes of audio, image, text, and video, should not contain + embedded information that is really of a different type. Such + compound types should be represented using the "multipart" or + "application" types. + + Parameters are modifiers of the content-subtype, and do not + fundamentally affect the requirements of the host system. Although + most parameters make sense only with certain content-types, others + are "global" in the sense that they might apply to any subtype. For + example, the "boundary" parameter makes sense only for the + "multipart" content-type, but the "charset" parameter might make + sense with several content-types. + + + +Borenstein & Freed [Page 9] + +RFC 1521 MIME September 1993 + + + An initial set of seven Content-Types is defined by this document. + This set of top-level names is intended to be substantially complete. + It is expected that additions to the larger set of supported types + can generally be accomplished by the creation of new subtypes of + these initial types. In the future, more top-level types may be + defined only by an extension to this standard. If another primary + type is to be used for any reason, it must be given a name starting + with "X-" to indicate its non-standard status and to avoid a + potential conflict with a future official name. + + In the Augmented BNF notation of RFC 822, a Content-Type header field + value is defined as follows: + + content := "Content-Type" ":" type "/" subtype *(";" + parameter) + ; case-insensitive matching of type and subtype + + type := "application" / "audio" + / "image" / "message" + / "multipart" / "text" + / "video" / extension-token + ; All values case-insensitive + + extension-token := x-token / iana-token + + iana-token := + + x-token := + + subtype := token ; case-insensitive + + parameter := attribute "=" value + + attribute := token ; case-insensitive + + value := token / quoted-string + + token := 1* + + tspecials := "(" / ")" / "<" / ">" / "@" + / "," / ";" / ":" / "\" / <"> + / "/" / "[" / "]" / "?" / "=" + ; Must be in quoted-string, + ; to use within parameter values + + + +Borenstein & Freed [Page 10] + +RFC 1521 MIME September 1993 + + + Note that the definition of "tspecials" is the same as the RFC 822 + definition of "specials" with the addition of the three characters + "/", "?", and "=", and the removal of ".". + + Note also that a subtype specification is MANDATORY. There are no + default subtypes. + + The type, subtype, and parameter names are not case sensitive. For + example, TEXT, Text, and TeXt are all equivalent. Parameter values + are normally case sensitive, but certain parameters are interpreted + to be case-insensitive, depending on the intended use. (For example, + multipart boundaries are case-sensitive, but the "access-type" for + message/External-body is not case-sensitive.) + + Beyond this syntax, the only constraint on the definition of subtype + names is the desire that their uses must not conflict. That is, it + would be undesirable to have two different communities using + "Content-Type: application/foobar" to mean two different things. The + process of defining new content-subtypes, then, is not intended to be + a mechanism for imposing restrictions, but simply a mechanism for + publicizing the usages. There are, therefore, two acceptable + mechanisms for defining new Content-Type subtypes: + + 1. Private values (starting with "X-") may be + defined bilaterally between two cooperating + agents without outside registration or + standardization. + + 2. New standard values must be documented, + registered with, and approved by IANA, as + described in Appendix E. Where intended for + public use, the formats they refer to must + also be defined by a published specification, + and possibly offered for standardization. + + The seven standard initial predefined Content-Types are detailed in + the bulk of this document. They are: + + text -- textual information. The primary subtype, + "plain", indicates plain (unformatted) text. No + special software is required to get the full + meaning of the text, aside from support for the + indicated character set. Subtypes are to be used + for enriched text in forms where application + software may enhance the appearance of the text, + but such software must not be required in order to + get the general idea of the content. Possible + subtypes thus include any readable word processor + + + +Borenstein & Freed [Page 11] + +RFC 1521 MIME September 1993 + + + format. A very simple and portable subtype, + richtext, was defined in RFC 1341, with a future + revision expected. + + multipart -- data consisting of multiple parts of + independent data types. Four initial subtypes + are defined, including the primary "mixed" + subtype, "alternative" for representing the same + data in multiple formats, "parallel" for parts + intended to be viewed simultaneously, and "digest" + for multipart entities in which each part is of + type "message". + + message -- an encapsulated message. A body of + Content-Type "message" is itself all or part of a + fully formatted RFC 822 conformant message which + may contain its own different Content-Type header + field. The primary subtype is "rfc822". The + "partial" subtype is defined for partial messages, + to permit the fragmented transmission of bodies + that are thought to be too large to be passed + through mail transport facilities. Another + subtype, "External-body", is defined for + specifying large bodies by reference to an + external data source. + + image -- image data. Image requires a display device + (such as a graphical display, a printer, or a FAX + machine) to view the information. Initial + subtypes are defined for two widely-used image + formats, jpeg and gif. + + audio -- audio data, with initial subtype "basic". + Audio requires an audio output device (such as a + speaker or a telephone) to "display" the contents. + + video -- video data. Video requires the capability to + display moving images, typically including + specialized hardware and software. The initial + subtype is "mpeg". + + application -- some other kind of data, typically + either uninterpreted binary data or information to + be processed by a mail-based application. The + primary subtype, "octet-stream", is to be used in + the case of uninterpreted binary data, in which + case the simplest recommended action is to offer + to write the information into a file for the user. + + + +Borenstein & Freed [Page 12] + +RFC 1521 MIME September 1993 + + + An additional subtype, "PostScript", is defined + for transporting PostScript documents in bodies. + Other expected uses for "application" include + spreadsheets, data for mail-based scheduling + systems, and languages for "active" + (computational) email. (Note that active email + and other application data may entail several + security considerations, which are discussed later + in this memo, particularly in the context of + application/PostScript.) + + Default RFC 822 messages are typed by this protocol as plain text in + the US-ASCII character set, which can be explicitly specified as + "Content-type: text/plain; charset=us-ascii". If no Content-Type is + specified, this default is assumed. In the presence of a MIME- + Version header field, a receiving User Agent can also assume that + plain US-ASCII text was the sender's intent. In the absence of a + MIME-Version specification, plain US-ASCII text must still be + assumed, but the sender's intent might have been otherwise. + + RATIONALE: In the absence of any Content-Type header field or + MIME-Version header field, it is impossible to be certain that a + message is actually text in the US-ASCII character set, since it + might well be a message that, using the conventions that predate + this document, includes text in another character set or non- + textual data in a manner that cannot be automatically recognized + (e.g., a uuencoded compressed UNIX tar file). Although there is + no fully acceptable alternative to treating such untyped messages + as "text/plain; charset=us-ascii", implementors should remain + aware that if a message lacks both the MIME-Version and the + Content-Type header fields, it may in practice contain almost + anything. + + It should be noted that the list of Content-Type values given here + may be augmented in time, via the mechanisms described above, and + that the set of subtypes is expected to grow substantially. + + When a mail reader encounters mail with an unknown Content-type + value, it should generally treat it as equivalent to + "application/octet-stream", as described later in this document. + +5. The Content-Transfer-Encoding Header Field + + Many Content-Types which could usefully be transported via email are + represented, in their "natural" format, as 8-bit character or binary + data. Such data cannot be transmitted over some transport protocols. + For example, RFC 821 restricts mail messages to 7-bit US-ASCII data + with lines no longer than 1000 characters. + + + +Borenstein & Freed [Page 13] + +RFC 1521 MIME September 1993 + + + It is necessary, therefore, to define a standard mechanism for re- + encoding such data into a 7-bit short-line format. This document + specifies that such encodings will be indicated by a new "Content- + Transfer-Encoding" header field. The Content-Transfer-Encoding field + is used to indicate the type of transformation that has been used in + order to represent the body in an acceptable manner for transport. + + Unlike Content-Types, a proliferation of Content-Transfer-Encoding + values is undesirable and unnecessary. However, establishing only a + single Content-Transfer-Encoding mechanism does not seem possible. + There is a tradeoff between the desire for a compact and efficient + encoding of largely-binary data and the desire for a readable + encoding of data that is mostly, but not entirely, 7-bit data. For + this reason, at least two encoding mechanisms are necessary: a + "readable" encoding and a "dense" encoding. + + The Content-Transfer-Encoding field is designed to specify an + invertible mapping between the "native" representation of a type of + data and a representation that can be readily exchanged using 7 bit + mail transport protocols, such as those defined by RFC 821 (SMTP). + This field has not been defined by any previous standard. The field's + value is a single token specifying the type of encoding, as + enumerated below. Formally: + + encoding := "Content-Transfer-Encoding" ":" mechanism + + mechanism := "7bit" ; case-insensitive + / "quoted-printable" + / "base64" + / "8bit" + / "binary" + / x-token + + These values are not case sensitive. That is, Base64 and BASE64 and + bAsE64 are all equivalent. An encoding type of 7BIT requires that + the body is already in a seven-bit mail-ready representation. This + is the default value -- that is, "Content-Transfer-Encoding: 7BIT" is + assumed if the Content-Transfer-Encoding header field is not present. + + The values "8bit", "7bit", and "binary" all mean that NO encoding has + been performed. However, they are potentially useful as indications + of the kind of data contained in the object, and therefore of the + kind of encoding that might need to be performed for transmission in + a given transport system. In particular: + + "7bit" means that the data is all represented as short + lines of US-ASCII data. + + + + +Borenstein & Freed [Page 14] + +RFC 1521 MIME September 1993 + + + "8bit" means that the lines are short, but there may be + non-ASCII characters (octets with the high-order + bit set). + + "Binary" means that not only may non-ASCII characters + be present, but also that the lines are not + necessarily short enough for SMTP transport. + + The difference between "8bit" (or any other conceivable bit-width + token) and the "binary" token is that "binary" does not require + adherence to any limits on line length or to the SMTP CRLF semantics, + while the bit-width tokens do require such adherence. If the body + contains data in any bit-width other than 7-bit, the appropriate + bit-width Content-Transfer-Encoding token must be used (e.g., "8bit" + for unencoded 8 bit wide data). If the body contains binary data, + the "binary" Content-Transfer-Encoding token must be used. + + NOTE: The distinction between the Content-Transfer-Encoding values + of "binary", "8bit", etc. may seem unimportant, in that all of + them really mean "none" -- that is, there has been no encoding of + the data for transport. However, clear labeling will be of + enormous value to gateways between future mail transport systems + with differing capabilities in transporting data that do not meet + the restrictions of RFC 821 transport. + + Mail transport for unencoded 8-bit data is defined in RFC-1426 + [RFC-1426]. As of the publication of this document, there are no + standardized Internet mail transports for which it is legitimate + to include unencoded binary data in mail bodies. Thus there are + no circumstances in which the "binary" Content-Transfer-Encoding + is actually legal on the Internet. However, in the event that + binary mail transport becomes a reality in Internet mail, or when + this document is used in conjunction with any other binary-capable + transport mechanism, binary bodies should be labeled as such using + this mechanism. + + NOTE: The five values defined for the Content-Transfer-Encoding + field imply nothing about the Content-Type other than the + algorithm by which it was encoded or the transport system + requirements if unencoded. + + Implementors may, if necessary, define new Content-Transfer-Encoding + values, but must use an x-token, which is a name prefixed by "X-" to + indicate its non-standard status, e.g., "Content-Transfer-Encoding: + x-my-new-encoding". However, unlike Content-Types and subtypes, the + creation of new Content-Transfer-Encoding values is explicitly and + strongly discouraged, as it seems likely to hinder interoperability + with little potential benefit. Their use is allowed only as the + + + +Borenstein & Freed [Page 15] + +RFC 1521 MIME September 1993 + + + result of an agreement between cooperating user agents. + + If a Content-Transfer-Encoding header field appears as part of a + message header, it applies to the entire body of that message. If a + Content-Transfer-Encoding header field appears as part of a body + part's headers, it applies only to the body of that body part. If an + entity is of type "multipart" or "message", the Content-Transfer- + Encoding is not permitted to have any value other than a bit width + (e.g., "7bit", "8bit", etc.) or "binary". + + It should be noted that email is character-oriented, so that the + mechanisms described here are mechanisms for encoding arbitrary octet + streams, not bit streams. If a bit stream is to be encoded via one + of these mechanisms, it must first be converted to an 8-bit byte + stream using the network standard bit order ("big-endian"), in which + the earlier bits in a stream become the higher-order bits in a byte. + A bit stream not ending at an 8-bit boundary must be padded with + zeroes. This document provides a mechanism for noting the addition + of such padding in the case of the application Content-Type, which + has a "padding" parameter. + + The encoding mechanisms defined here explicitly encode all data in + ASCII. Thus, for example, suppose an entity has header fields such + as: + + Content-Type: text/plain; charset=ISO-8859-1 + Content-transfer-encoding: base64 + + This must be interpreted to mean that the body is a base64 ASCII + encoding of data that was originally in ISO-8859-1, and will be in + that character set again after decoding. + + The following sections will define the two standard encoding + mechanisms. The definition of new content-transfer-encodings is + explicitly discouraged and should only occur when absolutely + necessary. All content-transfer-encoding namespace except that + beginning with "X-" is explicitly reserved to the IANA for future + use. Private agreements about content-transfer-encodings are also + explicitly discouraged. + + Certain Content-Transfer-Encoding values may only be used on certain + Content-Types. In particular, it is expressly forbidden to use any + encodings other than "7bit", "8bit", or "binary" with any Content- + Type that recursively includes other Content-Type fields, notably the + "multipart" and "message" Content-Types. All encodings that are + desired for bodies of type multipart or message must be done at the + innermost level, by encoding the actual body that needs to be + encoded. + + + +Borenstein & Freed [Page 16] + +RFC 1521 MIME September 1993 + + + NOTE ON ENCODING RESTRICTIONS: Though the prohibition against + using content-transfer-encodings on data of type multipart or + message may seem overly restrictive, it is necessary to prevent + nested encodings, in which data are passed through an encoding + algorithm multiple times, and must be decoded multiple times in + order to be properly viewed. Nested encodings add considerable + complexity to user agents: aside from the obvious efficiency + problems with such multiple encodings, they can obscure the basic + structure of a message. In particular, they can imply that + several decoding operations are necessary simply to find out what + types of objects a message contains. Banning nested encodings may + complicate the job of certain mail gateways, but this seems less + of a problem than the effect of nested encodings on user agents. + + NOTE ON THE RELATIONSHIP BETWEEN CONTENT-TYPE AND CONTENT- + TRANSFER-ENCODING: It may seem that the Content-Transfer-Encoding + could be inferred from the characteristics of the Content-Type + that is to be encoded, or, at the very least, that certain + Content-Transfer-Encodings could be mandated for use with specific + Content-Types. There are several reasons why this is not the case. + First, given the varying types of transports used for mail, some + encodings may be appropriate for some Content-Type/transport + combinations and not for others. (For example, in an 8-bit + transport, no encoding would be required for text in certain + character sets, while such encodings are clearly required for 7- + bit SMTP.) Second, certain Content-Types may require different + types of transfer encoding under different circumstances. For + example, many PostScript bodies might consist entirely of short + lines of 7-bit data and hence require little or no encoding. + Other PostScript bodies (especially those using Level 2 + PostScript's binary encoding mechanism) may only be reasonably + represented using a binary transport encoding. Finally, since + Content-Type is intended to be an open-ended specification + mechanism, strict specification of an association between + Content-Types and encodings effectively couples the specification + of an application protocol with a specific lower-level transport. + This is not desirable since the developers of a Content-Type + should not have to be aware of all the transports in use and what + their limitations are. + + NOTE ON TRANSLATING ENCODINGS: The quoted-printable and base64 + encodings are designed so that conversion between them is + possible. The only issue that arises in such a conversion is the + handling of line breaks. When converting from quoted-printable to + base64 a line break must be converted into a CRLF sequence. + Similarly, a CRLF sequence in base64 data must be converted to a + quoted-printable line break, but ONLY when converting text data. + + + + +Borenstein & Freed [Page 17] + +RFC 1521 MIME September 1993 + + + NOTE ON CANONICAL ENCODING MODEL: There was some confusion, in + earlier drafts of this memo, regarding the model for when email + data was to be converted to canonical form and encoded, and in + particular how this process would affect the treatment of CRLFs, + given that the representation of newlines varies greatly from + system to system, and the relationship between content-transfer- + encodings and character sets. For this reason, a canonical model + for encoding is presented as Appendix G. + +5.1. Quoted-Printable Content-Transfer-Encoding + + The Quoted-Printable encoding is intended to represent data that + largely consists of octets that correspond to printable characters in + the ASCII character set. It encodes the data in such a way that the + resulting octets are unlikely to be modified by mail transport. If + the data being encoded are mostly ASCII text, the encoded form of the + data remains largely recognizable by humans. A body which is + entirely ASCII may also be encoded in Quoted-Printable to ensure the + integrity of the data should the message pass through a character- + translating, and/or line-wrapping gateway. + + In this encoding, octets are to be represented as determined by the + following rules: + + Rule #1: (General 8-bit representation) Any octet, except those + indicating a line break according to the newline convention of the + canonical (standard) form of the data being encoded, may be + represented by an "=" followed by a two digit hexadecimal + representation of the octet's value. The digits of the + hexadecimal alphabet, for this purpose, are "0123456789ABCDEF". + Uppercase letters must be used when sending hexadecimal data, + though a robust implementation may choose to recognize lowercase + letters on receipt. Thus, for example, the value 12 (ASCII form + feed) can be represented by "=0C", and the value 61 (ASCII EQUAL + SIGN) can be represented by "=3D". Except when the following + rules allow an alternative encoding, this rule is mandatory. + + Rule #2: (Literal representation) Octets with decimal values of 33 + through 60 inclusive, and 62 through 126, inclusive, MAY be + represented as the ASCII characters which correspond to those + octets (EXCLAMATION POINT through LESS THAN, and GREATER THAN + through TILDE, respectively). + + Rule #3: (White Space): Octets with values of 9 and 32 MAY be + represented as ASCII TAB (HT) and SPACE characters, respectively, + but MUST NOT be so represented at the end of an encoded line. Any + TAB (HT) or SPACE characters on an encoded line MUST thus be + followed on that line by a printable character. In particular, an + + + +Borenstein & Freed [Page 18] + +RFC 1521 MIME September 1993 + + + "=" at the end of an encoded line, indicating a soft line break + (see rule #5) may follow one or more TAB (HT) or SPACE characters. + It follows that an octet with value 9 or 32 appearing at the end + of an encoded line must be represented according to Rule #1. This + rule is necessary because some MTAs (Message Transport Agents, + programs which transport messages from one user to another, or + perform a part of such transfers) are known to pad lines of text + with SPACEs, and others are known to remove "white space" + characters from the end of a line. Therefore, when decoding a + Quoted-Printable body, any trailing white space on a line must be + deleted, as it will necessarily have been added by intermediate + transport agents. + + Rule #4 (Line Breaks): A line break in a text body, independent of + what its representation is following the canonical representation + of the data being encoded, must be represented by a (RFC 822) line + break, which is a CRLF sequence, in the Quoted-Printable encoding. + Since the canonical representation of types other than text do not + generally include the representation of line breaks, no hard line + breaks (i.e. line breaks that are intended to be meaningful and + to be displayed to the user) should occur in the quoted-printable + encoding of such types. Of course, occurrences of "=0D", "=0A", + "0A=0D" and "=0D=0A" will eventually be encountered. In general, + however, base64 is preferred over quoted-printable for binary + data. + + Note that many implementations may elect to encode the local + representation of various content types directly, as described in + Appendix G. In particular, this may apply to plain text material + on systems that use newline conventions other than CRLF + delimiters. Such an implementation is permissible, but the + generation of line breaks must be generalized to account for the + case where alternate representations of newline sequences are + used. + + Rule #5 (Soft Line Breaks): The Quoted-Printable encoding REQUIRES + that encoded lines be no more than 76 characters long. If longer + lines are to be encoded with the Quoted-Printable encoding, 'soft' + line breaks must be used. An equal sign as the last character on a + encoded line indicates such a non-significant ('soft') line break + in the encoded text. Thus if the "raw" form of the line is a + single unencoded line that says: + + Now's the time for all folk to come to the aid of + their country. + + This can be represented, in the Quoted-Printable encoding, as + + + + +Borenstein & Freed [Page 19] + +RFC 1521 MIME September 1993 + + + Now's the time = + for all folk to come= + to the aid of their country. + + This provides a mechanism with which long lines are encoded in + such a way as to be restored by the user agent. The 76 character + limit does not count the trailing CRLF, but counts all other + characters, including any equal signs. + + Since the hyphen character ("-") is represented as itself in the + Quoted-Printable encoding, care must be taken, when encapsulating a + quoted-printable encoded body in a multipart entity, to ensure that + the encapsulation boundary does not appear anywhere in the encoded + body. (A good strategy is to choose a boundary that includes a + character sequence such as "=_" which can never appear in a quoted- + printable body. See the definition of multipart messages later in + this document.) + + NOTE: The quoted-printable encoding represents something of a + compromise between readability and reliability in transport. + Bodies encoded with the quoted-printable encoding will work + reliably over most mail gateways, but may not work perfectly over + a few gateways, notably those involving translation into EBCDIC. + (In theory, an EBCDIC gateway could decode a quoted-printable body + and re-encode it using base64, but such gateways do not yet + exist.) A higher level of confidence is offered by the base64 + Content-Transfer-Encoding. A way to get reasonably reliable + transport through EBCDIC gateways is to also quote the ASCII + characters + + !"#$@[\]^`{|}~ + + according to rule #1. See Appendix B for more information. + + Because quoted-printable data is generally assumed to be line- + oriented, it is to be expected that the representation of the breaks + between the lines of quoted printable data may be altered in + transport, in the same manner that plain text mail has always been + altered in Internet mail when passing between systems with differing + newline conventions. If such alterations are likely to constitute a + corruption of the data, it is probably more sensible to use the + base64 encoding rather than the quoted-printable encoding. + + WARNING TO IMPLEMENTORS: If binary data are encoded in quoted- + printable, care must be taken to encode CR and LF characters as "=0D" + and "=0A", respectively. In particular, a CRLF sequence in binary + data should be encoded as "=0D=0A". Otherwise, if CRLF were + represented as a hard line break, it might be incorrectly decoded on + + + +Borenstein & Freed [Page 20] + +RFC 1521 MIME September 1993 + + + platforms with different line break conventions. + + For formalists, the syntax of quoted-printable data is described by + the following grammar: + + quoted-printable := ([*(ptext / SPACE / TAB) ptext] ["="] CRLF) + ; Maximum line length of 76 characters excluding CRLF + + ptext := octet / 127, =, SPACE, or TAB, + ; and is recommended for any characters not listed in + ; Appendix B as "mail-safe". + +5.2. Base64 Content-Transfer-Encoding + + The Base64 Content-Transfer-Encoding is designed to represent + arbitrary sequences of octets in a form that need not be humanly + readable. The encoding and decoding algorithms are simple, but the + encoded data are consistently only about 33 percent larger than the + unencoded data. This encoding is virtually identical to the one used + in Privacy Enhanced Mail (PEM) applications, as defined in RFC 1421. + The base64 encoding is adapted from RFC 1421, with one change: base64 + eliminates the "*" mechanism for embedded clear text. + + A 65-character subset of US-ASCII is used, enabling 6 bits to be + represented per printable character. (The extra 65th character, "=", + is used to signify a special processing function.) + + NOTE: This subset has the important property that it is + represented identically in all versions of ISO 646, including US + ASCII, and all characters in the subset are also represented + identically in all versions of EBCDIC. Other popular encodings, + such as the encoding used by the uuencode utility and the base85 + encoding specified as part of Level 2 PostScript, do not share + these properties, and thus do not fulfill the portability + requirements a binary transport encoding for mail must meet. + + The encoding process represents 24-bit groups of input bits as output + strings of 4 encoded characters. Proceeding from left to right, a + 24-bit input group is formed by concatenating 3 8-bit input groups. + These 24 bits are then treated as 4 concatenated 6-bit groups, each + of which is translated into a single digit in the base64 alphabet. + When encoding a bit stream via the base64 encoding, the bit stream + must be presumed to be ordered with the most-significant-bit first. + + + +Borenstein & Freed [Page 21] + +RFC 1521 MIME September 1993 + + + That is, the first bit in the stream will be the high-order bit in + the first byte, and the eighth bit will be the low-order bit in the + first byte, and so on. + + Each 6-bit group is used as an index into an array of 64 printable + characters. The character referenced by the index is placed in the + output string. These characters, identified in Table 1, below, are + selected so as to be universally representable, and the set excludes + characters with particular significance to SMTP (e.g., ".", CR, LF) + and to the encapsulation boundaries defined in this document (e.g., + "-"). + + Table 1: The Base64 Alphabet + + Value Encoding Value Encoding Value Encoding Value Encoding + 0 A 17 R 34 i 51 z + 1 B 18 S 35 j 52 0 + 2 C 19 T 36 k 53 1 + 3 D 20 U 37 l 54 2 + 4 E 21 V 38 m 55 3 + 5 F 22 W 39 n 56 4 + 6 G 23 X 40 o 57 5 + 7 H 24 Y 41 p 58 6 + 8 I 25 Z 42 q 59 7 + 9 J 26 a 43 r 60 8 + 10 K 27 b 44 s 61 9 + 11 L 28 c 45 t 62 + + 12 M 29 d 46 u 63 / + 13 N 30 e 47 v + 14 O 31 f 48 w (pad) = + 15 P 32 g 49 x + 16 Q 33 h 50 y + + The output stream (encoded bytes) must be represented in lines of no + more than 76 characters each. All line breaks or other characters + not found in Table 1 must be ignored by decoding software. In base64 + data, characters other than those in Table 1, line breaks, and other + white space probably indicate a transmission error, about which a + warning message or even a message rejection might be appropriate + under some circumstances. + + Special processing is performed if fewer than 24 bits are available + at the end of the data being encoded. A full encoding quantum is + always completed at the end of a body. When fewer than 24 input bits + are available in an input group, zero bits are added (on the right) + to form an integral number of 6-bit groups. Padding at the end of + the data is performed using the '=' character. Since all base64 + input is an integral number of octets, only the following cases can + + + +Borenstein & Freed [Page 22] + +RFC 1521 MIME September 1993 + + + arise: (1) the final quantum of encoding input is an integral + multiple of 24 bits; here, the final unit of encoded output will be + an integral multiple of 4 characters with no "=" padding, (2) the + final quantum of encoding input is exactly 8 bits; here, the final + unit of encoded output will be two characters followed by two "=" + padding characters, or (3) the final quantum of encoding input is + exactly 16 bits; here, the final unit of encoded output will be three + characters followed by one "=" padding character. + + Because it is used only for padding at the end of the data, the + occurrence of any '=' characters may be taken as evidence that the + end of the data has been reached (without truncation in transit). No + such assurance is possible, however, when the number of octets + transmitted was a multiple of three. + + Any characters outside of the base64 alphabet are to be ignored in + base64-encoded data. The same applies to any illegal sequence of + characters in the base64 encoding, such as "=====" + + Care must be taken to use the proper octets for line breaks if base64 + encoding is applied directly to text material that has not been + converted to canonical form. In particular, text line breaks must be + converted into CRLF sequences prior to base64 encoding. The important + thing to note is that this may be done directly by the encoder rather + than in a prior canonicalization step in some implementations. + + NOTE: There is no need to worry about quoting apparent + encapsulation boundaries within base64-encoded parts of multipart + entities because no hyphen characters are used in the base64 + encoding. + +6. Additional Content-Header Fields + +6.1. Optional Content-ID Header Field + + In constructing a high-level user agent, it may be desirable to allow + one body to make reference to another. Accordingly, bodies may be + labeled using the "Content-ID" header field, which is syntactically + identical to the "Message-ID" header field: + + id := "Content-ID" ":" msg-id + Like the Message-ID values, Content-ID values must be generated to be + world-unique. + + The Content-ID value may be used for uniquely identifying MIME + entities in several contexts, particularly for cacheing data + referenced by the message/external-body mechanism. Although the + Content-ID header is generally optional, its use is mandatory in + + + +Borenstein & Freed [Page 23] + +RFC 1521 MIME September 1993 + + + implementations which generate data of the optional MIME Content-type + "message/external-body". That is, each message/external-body entity + must have a Content-ID field to permit cacheing of such data. + + It is also worth noting that the Content-ID value has special + semantics in the case of the multipart/alternative content-type. + This is explained in the section of this document dealing with + multipart/alternative. + +6.2. Optional Content-Description Header Field + + The ability to associate some descriptive information with a given + body is often desirable. For example, it may be useful to mark an + "image" body as "a picture of the Space Shuttle Endeavor." Such text + may be placed in the Content-Description header field. + + description := "Content-Description" ":" *text + + The description is presumed to be given in the US-ASCII character + set, although the mechanism specified in [RFC-1522] may be used for + non-US-ASCII Content-Description values. + +7. The Predefined Content-Type Values + + This document defines seven initial Content-Type values and an + extension mechanism for private or experimental types. Further + standard types must be defined by new published specifications. It + is expected that most innovation in new types of mail will take place + as subtypes of the seven types defined here. The most essential + characteristics of the seven content-types are summarized in Appendix + F. + +7.1 The Text Content-Type + + The text Content-Type is intended for sending material which is + principally textual in form. It is the default Content-Type. A + "charset" parameter may be used to indicate the character set of the + body text for some text subtypes, notably including the primary + subtype, "text/plain", which indicates plain (unformatted) text. The + default Content-Type for Internet mail is "text/plain; charset=us- + ascii". + + Beyond plain text, there are many formats for representing what might + be known as "extended text" -- text with embedded formatting and + presentation information. An interesting characteristic of many such + representations is that they are to some extent readable even without + the software that interprets them. It is useful, then, to + distinguish them, at the highest level, from such unreadable data as + + + +Borenstein & Freed [Page 24] + +RFC 1521 MIME September 1993 + + + images, audio, or text represented in an unreadable form. In the + absence of appropriate interpretation software, it is reasonable to + show subtypes of text to the user, while it is not reasonable to do + so with most nontextual data. + + Such formatted textual data should be represented using subtypes of + text. Plausible subtypes of text are typically given by the common + name of the representation format, e.g., "text/richtext" [RFC-1341]. + +7.1.1. The charset parameter + + A critical parameter that may be specified in the Content-Type field + for text/plain data is the character set. This is specified with a + "charset" parameter, as in: + + Content-type: text/plain; charset=us-ascii + + Unlike some other parameter values, the values of the charset + parameter are NOT case sensitive. The default character set, which + must be assumed in the absence of a charset parameter, is US-ASCII. + + The specification for any future subtypes of "text" must specify + whether or not they will also utilize a "charset" parameter, and may + possibly restrict its values as well. When used with a particular + body, the semantics of the "charset" parameter should be identical to + those specified here for "text/plain", i.e., the body consists + entirely of characters in the given charset. In particular, definers + of future text subtypes should pay close attention the the + implications of multibyte character sets for their subtype + definitions. + + This RFC specifies the definition of the charset parameter for the + purposes of MIME to be a unique mapping of a byte stream to glyphs, a + mapping which does not require external profiling information. + + An initial list of predefined character set names can be found at the + end of this section. Additional character sets may be registered + with IANA, although the standardization of their use requires the + usual IESG [RFC-1340] review and approval. Note that if the + specified character set includes 8-bit data, a Content-Transfer- + Encoding header field and a corresponding encoding on the data are + required in order to transmit the body via some mail transfer + protocols, such as SMTP. + + The default character set, US-ASCII, has been the subject of some + confusion and ambiguity in the past. Not only were there some + ambiguities in the definition, there have been wide variations in + practice. In order to eliminate such ambiguity and variations in the + + + +Borenstein & Freed [Page 25] + +RFC 1521 MIME September 1993 + + + future, it is strongly recommended that new user agents explicitly + specify a character set via the Content-Type header field. "US- + ASCII" does not indicate an arbitrary seven-bit character code, but + specifies that the body uses character coding that uses the exact + correspondence of codes to characters specified in ASCII. National + use variations of ISO 646 [ISO-646] are NOT ASCII and their use in + Internet mail is explicitly discouraged. The omission of the ISO 646 + character set is deliberate in this regard. The character set name + of "US-ASCII" explicitly refers to ANSI X3.4-1986 [US-ASCII] only. + The character set name "ASCII" is reserved and must not be used for + any purpose. + + NOTE: RFC 821 explicitly specifies "ASCII", and references an + earlier version of the American Standard. Insofar as one of the + purposes of specifying a Content-Type and character set is to + permit the receiver to unambiguously determine how the sender + intended the coded message to be interpreted, assuming anything + other than "strict ASCII" as the default would risk unintentional + and incompatible changes to the semantics of messages now being + transmitted. This also implies that messages containing + characters coded according to national variations on ISO 646, or + using code-switching procedures (e.g., those of ISO 2022), as well + as 8-bit or multiple octet character encodings MUST use an + appropriate character set specification to be consistent with this + specification. + + The complete US-ASCII character set is listed in [US-ASCII]. Note + that the control characters including DEL (0-31, 127) have no defined + meaning apart from the combination CRLF (ASCII values 13 and 10) + indicating a new line. Two of the characters have de facto meanings + in wide use: FF (12) often means "start subsequent text on the + beginning of a new page"; and TAB or HT (9) often (though not always) + means "move the cursor to the next available column after the current + position where the column number is a multiple of 8 (counting the + first column as column 0)." Apart from this, any use of the control + characters or DEL in a body must be part of a private agreement + between the sender and recipient. Such private agreements are + discouraged and should be replaced by the other capabilities of this + document. + + NOTE: Beyond US-ASCII, an enormous proliferation of character sets + is possible. It is the opinion of the IETF working group that a + large number of character sets is NOT a good thing. We would + prefer to specify a single character set that can be used + universally for representing all of the world's languages in + electronic mail. Unfortunately, existing practice in several + communities seems to point to the continued use of multiple + character sets in the near future. For this reason, we define + + + +Borenstein & Freed [Page 26] + +RFC 1521 MIME September 1993 + + + names for a small number of character sets for which a strong + constituent base exists. + + The defined charset values are: + + US-ASCII -- as defined in [US-ASCII]. + + ISO-8859-X -- where "X" is to be replaced, as necessary, for the + parts of ISO-8859 [ISO-8859]. Note that the ISO 646 + character sets have deliberately been omitted in favor of + their 8859 replacements, which are the designated character + sets for Internet mail. As of the publication of this + document, the legitimate values for "X" are the digits 1 + through 9. + + The character sets specified above are the ones that were relatively + uncontroversial during the drafting of MIME. This document does not + endorse the use of any particular character set other than US-ASCII, + and recognizes that the future evolution of world character sets + remains unclear. It is expected that in the future, additional + character sets will be registered for use in MIME. + + Note that the character set used, if anything other than US-ASCII, + must always be explicitly specified in the Content-Type field. + + No other character set name may be used in Internet mail without the + publication of a formal specification and its registration with IANA, + or by private agreement, in which case the character set name must + begin with "X-". + + Implementors are discouraged from defining new character sets for + mail use unless absolutely necessary. + + The "charset" parameter has been defined primarily for the purpose of + textual data, and is described in this section for that reason. + However, it is conceivable that non-textual data might also wish to + specify a charset value for some purpose, in which case the same + syntax and values should be used. + + In general, mail-sending software must always use the "lowest common + denominator" character set possible. For example, if a body contains + only US-ASCII characters, it must be marked as being in the US-ASCII + character set, not ISO-8859-1, which, like all the ISO-8859 family of + character sets, is a superset of US-ASCII. More generally, if a + widely-used character set is a subset of another character set, and a + body contains only characters in the widely-used subset, it must be + labeled as being in that subset. This will increase the chances that + the recipient will be able to view the mail correctly. + + + +Borenstein & Freed [Page 27] + +RFC 1521 MIME September 1993 + + +7.1.2. The Text/plain subtype + + The primary subtype of text is "plain". This indicates plain + (unformatted) text. The default Content-Type for Internet mail, + "text/plain; charset=us-ascii", describes existing Internet practice. + That is, it is the type of body defined by RFC 822. + + No other text subtype is defined by this document. + + The formal grammar for the content-type header field for text is as + follows: + + text-type := "text" "/" text-subtype [";" "charset" "=" charset] + + text-subtype := "plain" / extension-token + + charset := "us-ascii"/ "iso-8859-1"/ "iso-8859-2"/ "iso-8859-3" + / "iso-8859-4"/ "iso-8859-5"/ "iso-8859-6"/ "iso-8859-7" + / "iso-8859-8" / "iso-8859-9" / extension-token + ; case insensitive + +7.2. The Multipart Content-Type + + In the case of multiple part entities, in which one or more different + sets of data are combined in a single body, a "multipart" Content- + Type field must appear in the entity's header. The body must then + contain one or more "body parts," each preceded by an encapsulation + boundary, and the last one followed by a closing boundary. Each part + starts with an encapsulation boundary, and then contains a body part + consisting of header area, a blank line, and a body area. Thus a + body part is similar to an RFC 822 message in syntax, but different + in meaning. + + A body part is NOT to be interpreted as actually being an RFC 822 + message. To begin with, NO header fields are actually required in + body parts. A body part that starts with a blank line, therefore, is + allowed and is a body part for which all default values are to be + assumed. In such a case, the absence of a Content-Type header field + implies that the corresponding body is plain US-ASCII text. The only + header fields that have defined meaning for body parts are those the + names of which begin with "Content-". All other header fields are + generally to be ignored in body parts. Although they should + generally be retained in mail processing, they may be discarded by + gateways if necessary. Such other fields are permitted to appear in + body parts but must not be depended on. "X-" fields may be created + for experimental or private purposes, with the recognition that the + information they contain may be lost at some gateways. + + + + +Borenstein & Freed [Page 28] + +RFC 1521 MIME September 1993 + + + NOTE: The distinction between an RFC 822 message and a body part + is subtle, but important. A gateway between Internet and X.400 + mail, for example, must be able to tell the difference between a + body part that contains an image and a body part that contains an + encapsulated message, the body of which is an image. In order to + represent the latter, the body part must have "Content-Type: + message", and its body (after the blank line) must be the + encapsulated message, with its own "Content-Type: image" header + field. The use of similar syntax facilitates the conversion of + messages to body parts, and vice versa, but the distinction + between the two must be understood by implementors. (For the + special case in which all parts actually are messages, a "digest" + subtype is also defined.) + + As stated previously, each body part is preceded by an encapsulation + boundary. The encapsulation boundary MUST NOT appear inside any of + the encapsulated parts. Thus, it is crucial that the composing agent + be able to choose and specify the unique boundary that will separate + the parts. + + All present and future subtypes of the "multipart" type must use an + identical syntax. Subtypes may differ in their semantics, and may + impose additional restrictions on syntax, but must conform to the + required syntax for the multipart type. This requirement ensures + that all conformant user agents will at least be able to recognize + and separate the parts of any multipart entity, even of an + unrecognized subtype. + + As stated in the definition of the Content-Transfer-Encoding field, + no encoding other than "7bit", "8bit", or "binary" is permitted for + entities of type "multipart". The multipart delimiters and header + fields are always represented as 7-bit ASCII in any case (though the + header fields may encode non-ASCII header text as per [RFC-1522]), + and data within the body parts can be encoded on a part-by-part + basis, with Content-Transfer-Encoding fields for each appropriate + body part. + + Mail gateways, relays, and other mail handling agents are commonly + known to alter the top-level header of an RFC 822 message. In + particular, they frequently add, remove, or reorder header fields. + Such alterations are explicitly forbidden for the body part headers + embedded in the bodies of messages of type "multipart." + +7.2.1. Multipart: The common syntax + + All subtypes of "multipart" share a common syntax, defined in this + section. A simple example of a multipart message also appears in + this section. An example of a more complex multipart message is + + + +Borenstein & Freed [Page 29] + +RFC 1521 MIME September 1993 + + + given in Appendix C. + + The Content-Type field for multipart entities requires one parameter, + "boundary", which is used to specify the encapsulation boundary. The + encapsulation boundary is defined as a line consisting entirely of + two hyphen characters ("-", decimal code 45) followed by the boundary + parameter value from the Content-Type header field. + + NOTE: The hyphens are for rough compatibility with the earlier RFC + 934 method of message encapsulation, and for ease of searching for + the boundaries in some implementations. However, it should be + noted that multipart messages are NOT completely compatible with + RFC 934 encapsulations; in particular, they do not obey RFC 934 + quoting conventions for embedded lines that begin with hyphens. + This mechanism was chosen over the RFC 934 mechanism because the + latter causes lines to grow with each level of quoting. The + combination of this growth with the fact that SMTP implementations + sometimes wrap long lines made the RFC 934 mechanism unsuitable + for use in the event that deeply-nested multipart structuring is + ever desired. + + WARNING TO IMPLEMENTORS: The grammar for parameters on the Content- + type field is such that it is often necessary to enclose the + boundaries in quotes on the Content-type line. This is not always + necessary, but never hurts. Implementors should be sure to study the + grammar carefully in order to avoid producing illegal Content-type + fields. Thus, a typical multipart Content-Type header field might + look like this: + + Content-Type: multipart/mixed; + boundary=gc0p4Jq0M2Yt08jU534c0p + + But the following is illegal: + + Content-Type: multipart/mixed; + boundary=gc0p4Jq0M:2Yt08jU534c0p + + (because of the colon) and must instead be represented as + + Content-Type: multipart/mixed; + boundary="gc0p4Jq0M:2Yt08jU534c0p" + + This indicates that the entity consists of several parts, each itself + with a structure that is syntactically identical to an RFC 822 + message, except that the header area might be completely empty, and + that the parts are each preceded by the line + + --gc0p4Jq0M:2Yt08jU534c0p + + + +Borenstein & Freed [Page 30] + +RFC 1521 MIME September 1993 + + + Note that the encapsulation boundary must occur at the beginning of a + line, i.e., following a CRLF, and that the initial CRLF is considered + to be attached to the encapsulation boundary rather than part of the + preceding part. The boundary must be followed immediately either by + another CRLF and the header fields for the next part, or by two + CRLFs, in which case there are no header fields for the next part + (and it is therefore assumed to be of Content-Type text/plain). + + NOTE: The CRLF preceding the encapsulation line is conceptually + attached to the boundary so that it is possible to have a part + that does not end with a CRLF (line break). Body parts that must + be considered to end with line breaks, therefore, must have two + CRLFs preceding the encapsulation line, the first of which is part + of the preceding body part, and the second of which is part of the + encapsulation boundary. + + Encapsulation boundaries must not appear within the encapsulations, + and must be no longer than 70 characters, not counting the two + leading hyphens. + + The encapsulation boundary following the last body part is a + distinguished delimiter that indicates that no further body parts + will follow. Such a delimiter is identical to the previous + delimiters, with the addition of two more hyphens at the end of the + line: + + --gc0p4Jq0M2Yt08jU534c0p-- + + There appears to be room for additional information prior to the + first encapsulation boundary and following the final boundary. These + areas should generally be left blank, and implementations must ignore + anything that appears before the first boundary or after the last + one. + + NOTE: These "preamble" and "epilogue" areas are generally not used + because of the lack of proper typing of these parts and the lack + of clear semantics for handling these areas at gateways, + particularly X.400 gateways. However, rather than leaving the + preamble area blank, many MIME implementations have found this to + be a convenient place to insert an explanatory note for recipients + who read the message with pre-MIME software, since such notes will + be ignored by MIME-compliant software. + + NOTE: Because encapsulation boundaries must not appear in the body + parts being encapsulated, a user agent must exercise care to + choose a unique boundary. The boundary in the example above could + have been the result of an algorithm designed to produce + boundaries with a very low probability of already existing in the + + + +Borenstein & Freed [Page 31] + +RFC 1521 MIME September 1993 + + + data to be encapsulated without having to prescan the data. + Alternate algorithms might result in more 'readable' boundaries + for a recipient with an old user agent, but would require more + attention to the possibility that the boundary might appear in the + encapsulated part. The simplest boundary possible is something + like "---", with a closing boundary of "-----". + + As a very simple example, the following multipart message has two + parts, both of them plain text, one of them explicitly typed and one + of them implicitly typed: + + From: Nathaniel Borenstein + To: Ned Freed + Subject: Sample message + MIME-Version: 1.0 + Content-type: multipart/mixed; boundary="simple + boundary" + + This is the preamble. It is to be ignored, though it + is a handy place for mail composers to include an + explanatory note to non-MIME conformant readers. + --simple boundary + + This is implicitly typed plain ASCII text. + It does NOT end with a linebreak. + --simple boundary + Content-type: text/plain; charset=us-ascii + + This is explicitly typed plain ASCII text. + It DOES end with a linebreak. + + --simple boundary-- + This is the epilogue. It is also to be ignored. + + The use of a Content-Type of multipart in a body part within another + multipart entity is explicitly allowed. In such cases, for obvious + reasons, care must be taken to ensure that each nested multipart + entity must use a different boundary delimiter. See Appendix C for an + example of nested multipart entities. + + The use of the multipart Content-Type with only a single body part + may be useful in certain contexts, and is explicitly permitted. + + The only mandatory parameter for the multipart Content-Type is the + boundary parameter, which consists of 1 to 70 characters from a set + of characters known to be very robust through email gateways, and NOT + ending with white space. (If a boundary appears to end with white + space, the white space must be presumed to have been added by a + + + +Borenstein & Freed [Page 32] + +RFC 1521 MIME September 1993 + + + gateway, and must be deleted.) It is formally specified by the + following BNF: + + boundary := 0*69 bcharsnospace + + bchars := bcharsnospace / " " + + bcharsnospace := DIGIT / ALPHA / "'" / "(" / ")" / "+" /"_" + / "," / "-" / "." / "/" / ":" / "=" / "?" + + Overall, the body of a multipart entity may be specified as + follows: + + multipart-body := preamble 1*encapsulation + close-delimiter epilogue + + encapsulation := delimiter body-part CRLF + + delimiter := "--" boundary CRLF ; taken from Content-Type field. + ; There must be no space + ; between "--" and boundary. + + close-delimiter := "--" boundary "--" CRLF ; Again, no space + by "--", + + preamble := discard-text ; to be ignored upon receipt. + + epilogue := discard-text ; to be ignored upon receipt. + + discard-text := *(*text CRLF) + + body-part := <"message" as defined in RFC 822, + with all header fields optional, and with the + specified delimiter not occurring anywhere in + the message body, either on a line by itself + or as a substring anywhere. Note that the + semantics of a part differ from the semantics + of a message, as described in the text.> + + NOTE: In certain transport enclaves, RFC 822 restrictions such as + the one that limits bodies to printable ASCII characters may not + be in force. (That is, the transport domains may resemble + standard Internet mail transport as specified in RFC821 and + assumed by RFC822, but without certain restrictions.) The + relaxation of these restrictions should be construed as locally + extending the definition of bodies, for example to include octets + outside of the ASCII range, as long as these extensions are + supported by the transport and adequately documented in the + + + +Borenstein & Freed [Page 33] + +RFC 1521 MIME September 1993 + + + Content-Transfer-Encoding header field. However, in no event are + headers (either message headers or body-part headers) allowed to + contain anything other than ASCII characters. + + NOTE: Conspicuously missing from the multipart type is a notion of + structured, related body parts. In general, it seems premature to + try to standardize interpart structure yet. It is recommended + that those wishing to provide a more structured or integrated + multipart messaging facility should define a subtype of multipart + that is syntactically identical, but that always expects the + inclusion of a distinguished part that can be used to specify the + structure and integration of the other parts, probably referring + to them by their Content-ID field. If this approach is used, + other implementations will not recognize the new subtype, but will + treat it as the primary subtype (multipart/mixed) and will thus be + able to show the user the parts that are recognized. + +7.2.2. The Multipart/mixed (primary) subtype + + The primary subtype for multipart, "mixed", is intended for use when + the body parts are independent and need to be bundled in a particular + order. Any multipart subtypes that an implementation does not + recognize must be treated as being of subtype "mixed". + +7.2.3. The Multipart/alternative subtype + + The multipart/alternative type is syntactically identical to + multipart/mixed, but the semantics are different. In particular, + each of the parts is an "alternative" version of the same + information. + + Systems should recognize that the content of the various parts are + interchangeable. Systems should choose the "best" type based on the + local environment and preferences, in some cases even through user + interaction. As with multipart/mixed, the order of body parts is + significant. In this case, the alternatives appear in an order of + increasing faithfulness to the original content. In general, the best + choice is the LAST part of a type supported by the recipient system's + local environment. + + Multipart/alternative may be used, for example, to send mail in a + fancy text format in such a way that it can easily be displayed + anywhere: + + + + + + + + +Borenstein & Freed [Page 34] + +RFC 1521 MIME September 1993 + + + From: Nathaniel Borenstein + To: Ned Freed + Subject: Formatted text mail + MIME-Version: 1.0 + Content-Type: multipart/alternative; boundary=boundary42 + + --boundary42 + + Content-Type: text/plain; charset=us-ascii + + ...plain text version of message goes here.... + --boundary42 + Content-Type: text/richtext + + .... RFC 1341 richtext version of same message goes here ... + --boundary42 + Content-Type: text/x-whatever + + .... fanciest formatted version of same message goes here + ... + --boundary42-- + + In this example, users whose mail system understood the "text/x- + whatever" format would see only the fancy version, while other users + would see only the richtext or plain text version, depending on the + capabilities of their system. + + In general, user agents that compose multipart/alternative entities + must place the body parts in increasing order of preference, that is, + with the preferred format last. For fancy text, the sending user + agent should put the plainest format first and the richest format + last. Receiving user agents should pick and display the last format + they are capable of displaying. In the case where one of the + alternatives is itself of type "multipart" and contains unrecognized + sub-parts, the user agent may choose either to show that alternative, + an earlier alternative, or both. + + NOTE: From an implementor's perspective, it might seem more + sensible to reverse this ordering, and have the plainest + alternative last. However, placing the plainest alternative first + is the friendliest possible option when multipart/alternative + entities are viewed using a non-MIME-conformant mail reader. + While this approach does impose some burden on conformant mail + readers, interoperability with older mail readers was deemed to be + more important in this case. + + It may be the case that some user agents, if they can recognize more + than one of the formats, will prefer to offer the user the choice of + + + +Borenstein & Freed [Page 35] + +RFC 1521 MIME September 1993 + + + which format to view. This makes sense, for example, if mail + includes both a nicely-formatted image version and an easily-edited + text version. What is most critical, however, is that the user not + automatically be shown multiple versions of the same data. Either + the user should be shown the last recognized version or should be + given the choice. + + NOTE ON THE SEMANTICS OF CONTENT-ID IN MULTIPART/ALTERNATIVE: Each + part of a multipart/alternative entity represents the same data, but + the mappings between the two are not necessarily without information + loss. For example, information is lost when translating ODA to + PostScript or plain text. It is recommended that each part should + have a different Content-ID value in the case where the information + content of the two parts is not identical. However, where the + information content is identical -- for example, where several parts + of type "application/external- body" specify alternate ways to access + the identical data -- the same Content-ID field value should be used, + to optimize any cacheing mechanisms that might be present on the + recipient's end. However, it is recommended that the Content-ID + values used by the parts should not be the same Content-ID value that + describes the multipart/alternative as a whole, if there is any such + Content-ID field. That is, one Content-ID value will refer to the + multipart/alternative entity, while one or more other Content-ID + values will refer to the parts inside it. + +7.2.4. The Multipart/digest subtype + + This document defines a "digest" subtype of the multipart Content- + Type. This type is syntactically identical to multipart/mixed, but + the semantics are different. In particular, in a digest, the default + Content-Type value for a body part is changed from "text/plain" to + "message/rfc822". This is done to allow a more readable digest + format that is largely compatible (except for the quoting convention) + with RFC 934. + + + + + + + + + + + + + + + + + +Borenstein & Freed [Page 36] + +RFC 1521 MIME September 1993 + + + A digest in this format might, then, look something like this: + + From: Moderator-Address + To: Recipient-List + MIME-Version: 1.0 + Subject: Internet Digest, volume 42 + Content-Type: multipart/digest; + boundary="---- next message ----" + + ------ next message ---- + + From: someone-else + Subject: my opinion + + ...body goes here ... + + ------ next message ---- + + From: someone-else-again + Subject: my different opinion + + ... another body goes here... + + ------ next message ------ + +7.2.5. The Multipart/parallel subtype + + This document defines a "parallel" subtype of the multipart Content- + Type. This type is syntactically identical to multipart/mixed, but + the semantics are different. In particular, in a parallel entity, + the order of body parts is not significant. + + A common presentation of this type is to display all of the parts + simultaneously on hardware and software that are capable of doing so. + However, composing agents should be aware that many mail readers will + lack this capability and will show the parts serially in any event. + +7.2.6. Other Multipart subtypes + + Other multipart subtypes are expected in the future. MIME + implementations must in general treat unrecognized subtypes of + multipart as being equivalent to "multipart/mixed". + + The formal grammar for content-type header fields for multipart data + is given by: + + multipart-type := "multipart" "/" multipart-subtype + ";" "boundary" "=" boundary + + + +Borenstein & Freed [Page 37] + +RFC 1521 MIME September 1993 + + + multipart-subtype := "mixed" / "parallel" / "digest" + / "alternative" / extension-token + +7.3. The Message Content-Type + + It is frequently desirable, in sending mail, to encapsulate another + mail message. For this common operation, a special Content-Type, + "message", is defined. The primary subtype, message/rfc822, has no + required parameters in the Content-Type field. Additional subtypes, + "partial" and "External-body", do have required parameters. These + subtypes are explained below. + + NOTE: It has been suggested that subtypes of message might be + defined for forwarded or rejected messages. However, forwarded + and rejected messages can be handled as multipart messages in + which the first part contains any control or descriptive + information, and a second part, of type message/rfc822, is the + forwarded or rejected message. Composing rejection and forwarding + messages in this manner will preserve the type information on the + original message and allow it to be correctly presented to the + recipient, and hence is strongly encouraged. + + As stated in the definition of the Content-Transfer-Encoding field, + no encoding other than "7bit", "8bit", or "binary" is permitted for + messages or parts of type "message". Even stronger restrictions + apply to the subtypes "message/partial" and "message/external-body", + as specified below. The message header fields are always US-ASCII in + any case, and data within the body can still be encoded, in which + case the Content-Transfer-Encoding header field in the encapsulated + message will reflect this. Non-ASCII text in the headers of an + encapsulated message can be specified using the mechanisms described + in [RFC-1522]. + + Mail gateways, relays, and other mail handling agents are commonly + known to alter the top-level header of an RFC 822 message. In + particular, they frequently add, remove, or reorder header fields. + Such alterations are explicitly forbidden for the encapsulated + headers embedded in the bodies of messages of type "message." + +7.3.1. The Message/rfc822 (primary) subtype + + A Content-Type of "message/rfc822" indicates that the body contains + an encapsulated message, with the syntax of an RFC 822 message. + However, unlike top-level RFC 822 messages, it is not required that + each message/rfc822 body must include a "From", "Subject", and at + least one destination header. + + It should be noted that, despite the use of the numbers "822", a + + + +Borenstein & Freed [Page 38] + +RFC 1521 MIME September 1993 + + + message/rfc822 entity can include enhanced information as defined in + this document. In other words, a message/rfc822 message may be a + MIME message. + +7.3.2. The Message/Partial subtype + + A subtype of message, "partial", is defined in order to allow large + objects to be delivered as several separate pieces of mail and + automatically reassembled by the receiving user agent. (The concept + is similar to IP fragmentation/reassembly in the basic Internet + Protocols.) This mechanism can be used when intermediate transport + agents limit the size of individual messages that can be sent. + Content-Type "message/partial" thus indicates that the body contains + a fragment of a larger message. + + Three parameters must be specified in the Content-Type field of type + message/partial: The first, "id", is a unique identifier, as close to + a world-unique identifier as possible, to be used to match the parts + together. (In general, the identifier is essentially a message-id; + if placed in double quotes, it can be any message-id, in accordance + with the BNF for "parameter" given earlier in this specification.) + The second, "number", an integer, is the part number, which indicates + where this part fits into the sequence of fragments. The third, + "total", another integer, is the total number of parts. This third + subfield is required on the final part, and is optional (though + encouraged) on the earlier parts. Note also that these parameters + may be given in any order. + + Thus, part 2 of a 3-part message may have either of the following + header fields: + + Content-Type: Message/Partial; + number=2; total=3; + id="oc=jpbe0M2Yt4s@thumper.bellcore.com" + + Content-Type: Message/Partial; + id="oc=jpbe0M2Yt4s@thumper.bellcore.com"; + number=2 + + But part 3 MUST specify the total number of parts: + + Content-Type: Message/Partial; + number=3; total=3; + id="oc=jpbe0M2Yt4s@thumper.bellcore.com" + + Note that part numbering begins with 1, not 0. + + When the parts of a message broken up in this manner are put + + + +Borenstein & Freed [Page 39] + +RFC 1521 MIME September 1993 + + + together, the result is a complete MIME entity, which may have its + own Content-Type header field, and thus may contain any other data + type. + + Message fragmentation and reassembly: The semantics of a reassembled + partial message must be those of the "inner" message, rather than of + a message containing the inner message. This makes it possible, for + example, to send a large audio message as several partial messages, + and still have it appear to the recipient as a simple audio message + rather than as an encapsulated message containing an audio message. + That is, the encapsulation of the message is considered to be + "transparent". + + When generating and reassembling the parts of a message/partial + message, the headers of the encapsulated message must be merged with + the headers of the enclosing entities. In this process the following + rules must be observed: + + (1) All of the header fields from the initial enclosing entity + (part one), except those that start with "Content-" and the + specific header fields "Message-ID", "Encrypted", and "MIME- + Version", must be copied, in order, to the new message. + + (2) Only those header fields in the enclosed message which start + with "Content-" and "Message-ID", "Encrypted", and "MIME-Version" + must be appended, in order, to the header fields of the new + message. Any header fields in the enclosed message which do not + start with "Content-" (except for "Message-ID", "Encrypted", and + "MIME-Version") will be ignored. + + (3) All of the header fields from the second and any subsequent + messages will be ignored. + + For example, if an audio message is broken into two parts, the first + part might look something like this: + + X-Weird-Header-1: Foo + From: Bill@host.com + To: joe@otherhost.com + Subject: Audio mail + Message-ID: + MIME-Version: 1.0 + Content-type: message/partial; + id="ABC@host.com"; + number=1; total=2 + + X-Weird-Header-1: Bar + X-Weird-Header-2: Hello + + + +Borenstein & Freed [Page 40] + +RFC 1521 MIME September 1993 + + + Message-ID: + MIME-Version: 1.0 + Content-type: audio/basic + Content-transfer-encoding: base64 + + ... first half of encoded audio data goes here... + + and the second half might look something like this: + + From: Bill@host.com + To: joe@otherhost.com + Subject: Audio mail + MIME-Version: 1.0 + Message-ID: + Content-type: message/partial; + id="ABC@host.com"; number=2; total=2 + + ... second half of encoded audio data goes here... + + Then, when the fragmented message is reassembled, the resulting + message to be displayed to the user should look something like this: + + X-Weird-Header-1: Foo + From: Bill@host.com + To: joe@otherhost.com + Subject: Audio mail + Message-ID: + MIME-Version: 1.0 + Content-type: audio/basic + Content-transfer-encoding: base64 + + ... first half of encoded audio data goes here... + ... second half of encoded audio data goes here... + + Note on encoding of MIME entities encapsulated inside message/partial + entities: Because data of type "message" may never be encoded in + base64 or quoted-printable, a problem might arise if message/partial + entities are constructed in an environment that supports binary or + 8-bit transport. The problem is that the binary data would be split + into multiple message/partial objects, each of them requiring binary + transport. If such objects were encountered at a gateway into a 7- + bit transport environment, there would be no way to properly encode + them for the 7-bit world, aside from waiting for all of the parts, + reassembling the message, and then encoding the reassembled data in + base64 or quoted-printable. Since it is possible that different + parts might go through different gateways, even this is not an + acceptable solution. For this reason, it is specified that MIME + entities of type message/partial must always have a content- + + + +Borenstein & Freed [Page 41] + +RFC 1521 MIME September 1993 + + + transfer-encoding of 7-bit (the default). In particular, even in + environments that support binary or 8-bit transport, the use of a + content-transfer-encoding of "8bit" or "binary" is explicitly + prohibited for entities of type message/partial. + + It should be noted that, because some message transfer agents may + choose to automatically fragment large messages, and because such + agents may use different fragmentation thresholds, it is possible + that the pieces of a partial message, upon reassembly, may prove + themselves to comprise a partial message. This is explicitly + permitted. + + It should also be noted that the inclusion of a "References" field in + the headers of the second and subsequent pieces of a fragmented + message that references the Message-Id on the previous piece may be + of benefit to mail readers that understand and track references. + However, the generation of such "References" fields is entirely + optional. + + Finally, it should be noted that the "Encrypted" header field has + been made obsolete by Privacy Enhanced Messaging (PEM), but the rules + above are believed to describe the correct way to treat it if it is + encountered in the context of conversion to and from message/partial + fragments. + +7.3.3. The Message/External-Body subtype + + The external-body subtype indicates that the actual body data are not + included, but merely referenced. In this case, the parameters + describe a mechanism for accessing the external data. + + When an entity is of type "message/external-body", it consists of a + header, two consecutive CRLFs, and the message header for the + encapsulated message. If another pair of consecutive CRLFs appears, + this of course ends the message header for the encapsulated message. + However, since the encapsulated message's body is itself external, it + does NOT appear in the area that follows. For example, consider the + following message: + + Content-type: message/external-body; access- + type=local-file; + + name="/u/nsb/Me.gif" + + Content-type: image/gif + Content-ID: + Content-Transfer-Encoding: binary + + + + +Borenstein & Freed [Page 42] + +RFC 1521 MIME September 1993 + + + THIS IS NOT REALLY THE BODY! + + The area at the end, which might be called the "phantom body", is + ignored for most external-body messages. However, it may be used to + contain auxiliary information for some such messages, as indeed it is + when the access-type is "mail-server". Of the access-types defined + by this document, the phantom body is used only when the access-type + is "mail-server". In all other cases, the phantom body is ignored. + + The only always-mandatory parameter for message/external-body is + "access-type"; all of the other parameters may be mandatory or + optional depending on the value of access-type. + + ACCESS-TYPE -- A case-insensitive word, indicating the supported + access mechanism by which the file or data may be obtained. + Values include, but are not limited to, "FTP", "ANON-FTP", "TFTP", + "AFS", "LOCAL-FILE", and "MAIL-SERVER". Future values, except for + experimental values beginning with "X-" must be registered with + IANA, as described in Appendix E . + + In addition, the following three parameters are optional for ALL + access-types: + + EXPIRATION -- The date (in the RFC 822 "date-time" syntax, as + extended by RFC 1123 to permit 4 digits in the year field) after + which the existence of the external data is not guaranteed. + + SIZE -- The size (in octets) of the data. The intent of this + parameter is to help the recipient decide whether or not to expend + the necessary resources to retrieve the external data. Note that + this describes the size of the data in its canonical form, that + is, before any Content- Transfer-Encoding has been applied or + after the data have been decoded. + + PERMISSION -- A case-insensitive field that indicates whether or + not it is expected that clients might also attempt to overwrite + the data. By default, or if permission is "read", the assumption + is that they are not, and that if the data is retrieved once, it + is never needed again. If PERMISSION is "read-write", this + assumption is invalid, and any local copy must be considered no + more than a cache. "Read" and "Read-write" are the only defined + values of permission. + + The precise semantics of the access-types defined here are described + in the sections that follow. + + The encapsulated headers in ALL message/external-body entities MUST + include a Content-ID header field to give a unique identifier by + + + +Borenstein & Freed [Page 43] + +RFC 1521 MIME September 1993 + + + which to reference the data. This identifier may be used for + cacheing mechanisms, and for recognizing the receipt of the data when + the access-type is "mail-server". + + Note that, as specified here, the tokens that describe external-body + data, such as file names and mail server commands, are required to be + in the US-ASCII character set. If this proves problematic in + practice, a new mechanism may be required as a future extension to + MIME, either as newly defined access-types for message/external-body + or by some other mechanism. + + As with message/partial, it is specified that MIME entities of type + message/external-body must always have a content-transfer-encoding of + 7-bit (the default). In particular, even in environments that + support binary or 8-bit transport, the use of a content-transfer- + encoding of "8bit" or "binary" is explicitly prohibited for entities + of type message/external-body. + +7.3.3.1. The "ftp" and "tftp" access-types + + An access-type of FTP or TFTP indicates that the message body is + accessible as a file using the FTP [RFC-959] or TFTP [RFC-783] + protocols, respectively. For these access-types, the following + additional parameters are mandatory: + + NAME -- The name of the file that contains the actual body data. + + SITE -- A machine from which the file may be obtained, using the + given protocol. This must be a fully qualified domain name, not a + nickname. + + Before any data are retrieved, using FTP, the user will generally + need to be asked to provide a login id and a password for the machine + named by the site parameter. For security reasons, such an id and + password are not specified as content-type parameters, but must be + obtained from the user. + + In addition, the following parameters are optional: + + DIRECTORY -- A directory from which the data named by NAME should + be retrieved. + + MODE -- A case-insensitive string indicating the mode to be used + when retrieving the information. The legal values for access-type + "TFTP" are "NETASCII", "OCTET", and "MAIL", as specified by the + TFTP protocol [RFC-783]. The legal values for access-type "FTP" + are "ASCII", "EBCDIC", "IMAGE", and "LOCALn" where "n" is a + decimal integer, typically 8. These correspond to the + + + +Borenstein & Freed [Page 44] + +RFC 1521 MIME September 1993 + + + representation types "A" "E" "I" and "L n" as specified by the FTP + protocol [RFC-959]. Note that "BINARY" and "TENEX" are not valid + values for MODE, but that "OCTET" or "IMAGE" or "LOCAL8" should be + used instead. IF MODE is not specified, the default value is + "NETASCII" for TFTP and "ASCII" otherwise. + +7.3.3.2. The "anon-ftp" access-type + + The "anon-ftp" access-type is identical to the "ftp" access type, + except that the user need not be asked to provide a name and password + for the specified site. Instead, the ftp protocol will be used with + login "anonymous" and a password that corresponds to the user's email + address. + +7.3.3.3. The "local-file" and "afs" access-types + + An access-type of "local-file" indicates that the actual body is + accessible as a file on the local machine. An access-type of "afs" + indicates that the file is accessible via the global AFS file system. + In both cases, only a single parameter is required: + + NAME -- The name of the file that contains the actual body data. + + The following optional parameter may be used to describe the locality + of reference for the data, that is, the site or sites at which the + file is expected to be visible: + + SITE -- A domain specifier for a machine or set of machines that + are known to have access to the data file. Asterisks may be used + for wildcard matching to a part of a domain name, such as + "*.bellcore.com", to indicate a set of machines on which the data + should be directly visible, while a single asterisk may be used to + indicate a file that is expected to be universally available, + e.g., via a global file system. + +7.3.3.4. The "mail-server" access-type + + The "mail-server" access-type indicates that the actual body is + available from a mail server. The mandatory parameter for this + access-type is: + + SERVER -- The email address of the mail server from which the + actual body data can be obtained. + + Because mail servers accept a variety of syntaxes, some of which is + multiline, the full command to be sent to a mail server is not + included as a parameter on the content-type line. Instead, it is + provided as the "phantom body" when the content-type is + + + +Borenstein & Freed [Page 45] + +RFC 1521 MIME September 1993 + + + message/external-body and the access- type is mail-server. + + An optional parameter for this access-type is: + + SUBJECT -- The subject that is to be used in the mail that is sent + to obtain the data. Note that keying mail servers on Subject lines + is NOT recommended, but such mail servers are known to exist. + + Note that MIME does not define a mail server syntax. Rather, it + allows the inclusion of arbitrary mail server commands in the phantom + body. Implementations must include the phantom body in the body of + the message it sends to the mail server address to retrieve the + relevant data. + + It is worth noting that, unlike other access-types, mail-server + access is asynchronous and will happen at an unpredictable time in + the future. For this reason, it is important that there be a + mechanism by which the returned data can be matched up with the + original message/external-body entity. MIME mailservers must use the + same Content-ID field on the returned message that was used in the + original message/external-body entity, to facilitate such matching. + +7.3.3.5. Examples and Further Explanations + + With the emerging possibility of very wide-area file systems, it + becomes very hard to know in advance the set of machines where a file + will and will not be accessible directly from the file system. + Therefore it may make sense to provide both a file name, to be tried + directly, and the name of one or more sites from which the file is + known to be accessible. An implementation can try to retrieve remote + files using FTP or any other protocol, using anonymous file retrieval + or prompting the user for the necessary name and password. If an + external body is accessible via multiple mechanisms, the sender may + include multiple parts of type message/external-body within an entity + of type multipart/alternative. + + However, the external-body mechanism is not intended to be limited to + file retrieval, as shown by the mail-server access-type. Beyond + this, one can imagine, for example, using a video server for external + references to video clips. + + If an entity is of type "message/external-body", then the body of the + entity will contain the header fields of the encapsulated message. + The body itself is to be found in the external location. This means + that if the body of the "message/external-body" message contains two + consecutive CRLFs, everything after those pairs is NOT part of the + message itself. For most message/external-body messages, this + trailing area must simply be ignored. However, it is a convenient + + + +Borenstein & Freed [Page 46] + +RFC 1521 MIME September 1993 + + + place for additional data that cannot be included in the content-type + header field. In particular, if the "access-type" value is "mail- + server", then the trailing area must contain commands to be sent to + the mail server at the address given by the value of the SERVER + parameter. + + The embedded message header fields which appear in the body of the + message/external-body data must be used to declare the Content-type + of the external body if it is anything other than plain ASCII text, + since the external body does not have a header section to declare its + type. Similarly, any Content-transfer-encoding other than "7bit" + must also be declared here. Thus a complete message/external-body + message, referring to a document in PostScript format, might look + like this: + + From: Whomever + To: Someone + Subject: whatever + MIME-Version: 1.0 + Message-ID: + Content-Type: multipart/alternative; boundary=42 + Content-ID: + + --42 + Content-Type: message/external-body; + name="BodyFormats.ps"; + site="thumper.bellcore.com"; + access-type=ANON-FTP; + directory="pub"; + mode="image"; + expiration="Fri, 14 Jun 1991 19:13:14 -0400 (EDT)" + + Content-type: application/postscript + Content-ID: + + --42 + Content-Type: message/external-body; + name="/u/nsb/writing/rfcs/RFC-MIME.ps"; + site="thumper.bellcore.com"; + access-type=AFS + expiration="Fri, 14 Jun 1991 19:13:14 -0400 (EDT)" + + Content-type: application/postscript + Content-ID: + + --42 + Content-Type: message/external-body; + access-type=mail-server + + + +Borenstein & Freed [Page 47] + +RFC 1521 MIME September 1993 + + + server="listserv@bogus.bitnet"; + expiration="Fri, 14 Jun 1991 19:13:14 -0400 (EDT)" + + Content-type: application/postscript + Content-ID: + + get RFC-MIME.DOC + + --42-- + + Note that in the above examples, the default Content-transfer- + encoding of "7bit" is assumed for the external postscript data. + + Like the message/partial type, the message/external-body type is + intended to be transparent, that is, to convey the data type in the + external body rather than to convey a message with a body of that + type. Thus the headers on the outer and inner parts must be merged + using the same rules as for message/partial. In particular, this + means that the Content-type header is overridden, but the From and + Subject headers are preserved. + + Note that since the external bodies are not transported as mail, they + need not conform to the 7-bit and line length requirements, but might + in fact be binary files. Thus a Content-Transfer-Encoding is not + generally necessary, though it is permitted. + + Note that the body of a message of type "message/external-body" is + governed by the basic syntax for an RFC 822 message. In particular, + anything before the first consecutive pair of CRLFs is header + information, while anything after it is body information, which is + ignored for most access-types. + + The formal grammar for content-type header fields for data of type + message is given by: + + message-type := "message" "/" message-subtype + + message-subtype := "rfc822" + / "partial" 2#3partial-param + / "external-body" 1*external-param + / extension-token + + partial-param := (";" "id" "=" value) + / (";" "number" "=" 1*DIGIT) + / (";" "total" "=" 1*DIGIT) + ; id & number required; total required for last part + + external-param := (";" "access-type" "=" atype) + + + +Borenstein & Freed [Page 48] + +RFC 1521 MIME September 1993 + + + / (";" "expiration" "=" date-time) + ; Note that date-time is quoted + / (";" "size" "=" 1*DIGIT) + / (";" "permission" "=" ("read" / "read-write")) + ; Permission is case-insensitive + / (";" "name" "=" value) + / (";" "site" "=" value) + / (";" "dir" "=" value) + / (";" "mode" "=" value) + / (";" "server" "=" value) + / (";" "subject" "=" value) + ; access-type required;others required based on access-type + + atype := "ftp" / "anon-ftp" / "tftp" / "local-file" + / "afs" / "mail-server" / extension-token + ; Case-insensitive + +7.4. The Application Content-Type + + The "application" Content-Type is to be used for data which do not + fit in any of the other categories, and particularly for data to be + processed by mail-based uses of application programs. This is + information which must be processed by an application before it is + viewable or usable to a user. Expected uses for Content-Type + application include mail-based file transfer, spreadsheets, data for + mail-based scheduling systems, and languages for "active" + (computational) email. (The latter, in particular, can pose security + problems which must be understood by implementors, and are considered + in detail in the discussion of the application/PostScript content- + type.) + + For example, a meeting scheduler might define a standard + representation for information about proposed meeting dates. An + intelligent user agent would use this information to conduct a dialog + with the user, and might then send further mail based on that dialog. + More generally, there have been several "active" messaging languages + developed in which programs in a suitably specialized language are + sent through the mail and automatically run in the recipient's + environment. + + Such applications may be defined as subtypes of the "application" + Content-Type. This document defines two subtypes: octet-stream, and + PostScript. + + In general, the subtype of application will often be the name of the + application for which the data are intended. This does not mean, + however, that any application program name may be used freely as a + subtype of application. Such usages (other than subtypes beginning + + + +Borenstein & Freed [Page 49] + +RFC 1521 MIME September 1993 + + + with "x-") must be registered with IANA, as described in Appendix E. + +7.4.1. The Application/Octet-Stream (primary) subtype + + The primary subtype of application, "octet-stream", may be used to + indicate that a body contains binary data. The set of possible + parameters includes, but is not limited to: + + TYPE -- the general type or category of binary data. This is + intended as information for the human recipient rather than for + any automatic processing. + + PADDING -- the number of bits of padding that were appended to the + bit-stream comprising the actual contents to produce the enclosed + byte-oriented data. This is useful for enclosing a bit-stream in + a body when the total number of bits is not a multiple of the byte + size. + + An additional parameter, "conversions", was defined in [RFC-1341] but + has been removed. + + RFC 1341 also defined the use of a "NAME" parameter which gave a + suggested file name to be used if the data were to be written to a + file. This has been deprecated in anticipation of a separate + Content-Disposition header field, to be defined in a subsequent RFC. + + The recommended action for an implementation that receives + application/octet-stream mail is to simply offer to put the data in a + file, with any Content-Transfer-Encoding undone, or perhaps to use it + as input to a user-specified process. + + To reduce the danger of transmitting rogue programs through the mail, + it is strongly recommended that implementations NOT implement a + path-search mechanism whereby an arbitrary program named in the + Content-Type parameter (e.g., an "interpreter=" parameter) is found + and executed using the mail body as input. + +7.4.2. The Application/PostScript subtype + + A Content-Type of "application/postscript" indicates a PostScript + program. Currently two variants of the PostScript language are + allowed; the original level 1 variant is described in [POSTSCRIPT] + and the more recent level 2 variant is described in [POSTSCRIPT2]. + + PostScript is a registered trademark of Adobe Systems, Inc. Use of + the MIME content-type "application/postscript" implies recognition of + that trademark and all the rights it entails. + + + + +Borenstein & Freed [Page 50] + +RFC 1521 MIME September 1993 + + + The PostScript language definition provides facilities for internal + labeling of the specific language features a given program uses. This + labeling, called the PostScript document structuring conventions, is + very general and provides substantially more information than just + the language level. + + The use of document structuring conventions, while not required, is + strongly recommended as an aid to interoperability. Documents which + lack proper structuring conventions cannot be tested to see whether + or not they will work in a given environment. As such, some systems + may assume the worst and refuse to process unstructured documents. + + The execution of general-purpose PostScript interpreters entails + serious security risks, and implementors are discouraged from simply + sending PostScript email bodies to "off-the-shelf" interpreters. + While it is usually safe to send PostScript to a printer, where the + potential for harm is greatly constrained, implementors should + consider all of the following before they add interactive display of + PostScript bodies to their mail readers. + + The remainder of this section outlines some, though probably not all, + of the possible problems with sending PostScript through the mail. + + Dangerous operations in the PostScript language include, but may not + be limited to, the PostScript operators deletefile, renamefile, + filenameforall, and file. File is only dangerous when applied to + something other than standard input or output. Implementations may + also define additional nonstandard file operators; these may also + pose a threat to security. Filenameforall, the wildcard file search + operator, may appear at first glance to be harmless. Note, however, + that this operator has the potential to reveal information about what + files the recipient has access to, and this information may itself be + sensitive. Message senders should avoid the use of potentially + dangerous file operators, since these operators are quite likely to + be unavailable in secure PostScript implementations. Message- + receiving and -displaying software should either completely disable + all potentially dangerous file operators or take special care not to + delegate any special authority to their operation. These operators + should be viewed as being done by an outside agency when interpreting + PostScript documents. Such disabling and/or checking should be done + completely outside of the reach of the PostScript language itself; + care should be taken to insure that no method exists for re-enabling + full-function versions of these operators. + + The PostScript language provides facilities for exiting the normal + interpreter, or server, loop. Changes made in this "outer" + environment are customarily retained across documents, and may in + some cases be retained semipermanently in nonvolatile memory. The + + + +Borenstein & Freed [Page 51] + +RFC 1521 MIME September 1993 + + + operators associated with exiting the interpreter loop have the + potential to interfere with subsequent document processing. As such, + their unrestrained use constitutes a threat of service denial. + PostScript operators that exit the interpreter loop include, but may + not be limited to, the exitserver and startjob operators. Message- + sending software should not generate PostScript that depends on + exiting the interpreter loop to operate. The ability to exit will + probably be unavailable in secure PostScript implementations. + Message-receiving and -displaying software should, if possible, + disable the ability to make retained changes to the PostScript + environment, and eliminate the startjob and exitserver commands. If + these commands cannot be eliminated, the password associated with + them should at least be set to a hard-to-guess value. + + PostScript provides operators for setting system-wide and device- + specific parameters. These parameter settings may be retained across + jobs and may potentially pose a threat to the correct operation of + the interpreter. The PostScript operators that set system and device + parameters include, but may not be limited to, the setsystemparams + and setdevparams operators. Message-sending software should not + generate PostScript that depends on the setting of system or device + parameters to operate correctly. The ability to set these parameters + will probably be unavailable in secure PostScript implementations. + Message-receiving and -displaying software should, if possible, + disable the ability to change system and device parameters. If these + operators cannot be disabled, the password associated with them + should at least be set to a hard-to-guess value. + + Some PostScript implementations provide nonstandard facilities for + the direct loading and execution of machine code. Such facilities + are quite obviously open to substantial abuse. Message-sending + software should not make use of such features. Besides being totally + hardware- specific, they are also likely to be unavailable in secure + implementations of PostScript. Message-receiving and -displaying + software should not allow such operators to be used if they exist. + + PostScript is an extensible language, and many, if not most, + implementations of it provide a number of their own extensions. This + document does not deal with such extensions explicitly since they + constitute an unknown factor. Message-sending software should not + make use of nonstandard extensions; they are likely to be missing + from some implementations. Message-receiving and -displaying software + should make sure that any nonstandard PostScript operators are secure + and don't present any kind of threat. + + It is possible to write PostScript that consumes huge amounts of + various system resources. It is also possible to write PostScript + programs that loop infinitely. Both types of programs have the + + + +Borenstein & Freed [Page 52] + +RFC 1521 MIME September 1993 + + + potential to cause damage if sent to unsuspecting recipients. + Message-sending software should avoid the construction and + dissemination of such programs, which is antisocial. Message- + receiving and -displaying software should provide appropriate + mechanisms to abort processing of a document after a reasonable + amount of time has elapsed. In addition, PostScript interpreters + should be limited to the consumption of only a reasonable amount of + any given system resource. + + Finally, bugs may exist in some PostScript interpreters which could + possibly be exploited to gain unauthorized access to a recipient's + system. Apart from noting this possibility, there is no specific + action to take to prevent this, apart from the timely correction of + such bugs if any are found. + +7.4.3. Other Application subtypes + + It is expected that many other subtypes of application will be + defined in the future. MIME implementations must generally treat any + unrecognized subtypes as being equivalent to application/octet- + stream. + + The formal grammar for content-type header fields for application + data is given by: + + application-type := "application" "/" application-subtype + + application-subtype := ("octet-stream" *stream-param) + / "postscript" / extension-token + + stream-param := (";" "type" "=" value) + / (";" "padding" "=" padding) + + padding := "0" / "1" / "2" / "3" / "4" / "5" / "6" / "7" + +7.5. The Image Content-Type + + A Content-Type of "image" indicates that the body contains an image. + The subtype names the specific image format. These names are case + insensitive. Two initial subtypes are "jpeg" for the JPEG format, + JFIF encoding, and "gif" for GIF format [GIF]. + + The list of image subtypes given here is neither exclusive nor + exhaustive, and is expected to grow as more types are registered with + IANA, as described in Appendix E. + + The formal grammar for the content-type header field for data of type + image is given by: + + + +Borenstein & Freed [Page 53] + +RFC 1521 MIME September 1993 + + + image-type := "image" "/" ("gif" / "jpeg" / extension-token) + +7.6. The Audio Content-Type + + A Content-Type of "audio" indicates that the body contains audio + data. Although there is not yet a consensus on an "ideal" audio + format for use with computers, there is a pressing need for a format + capable of providing interoperable behavior. + + The initial subtype of "basic" is specified to meet this requirement + by providing an absolutely minimal lowest common denominator audio + format. It is expected that richer formats for higher quality and/or + lower bandwidth audio will be defined by a later document. + + The content of the "audio/basic" subtype is audio encoded using 8-bit + ISDN mu-law [PCM]. When this subtype is present, a sample rate of + 8000 Hz and a single channel is assumed. + + The formal grammar for the content-type header field for data of type + audio is given by: + + audio-type := "audio" "/" ("basic" / extension-token) + +7.7. The Video Content-Type + + A Content-Type of "video" indicates that the body contains a time- + varying-picture image, possibly with color and coordinated sound. + The term "video" is used extremely generically, rather than with + reference to any particular technology or format, and is not meant to + preclude subtypes such as animated drawings encoded compactly. The + subtype "mpeg" refers to video coded according to the MPEG standard + [MPEG]. + + Note that although in general this document strongly discourages the + mixing of multiple media in a single body, it is recognized that many + so-called "video" formats include a representation for synchronized + audio, and this is explicitly permitted for subtypes of "video". + + The formal grammar for the content-type header field for data of type + video is given by: + + video-type := "video" "/" ("mpeg" / extension-token) + +7.8. Experimental Content-Type Values + + A Content-Type value beginning with the characters "X-" is a private + value, to be used by consenting mail systems by mutual agreement. + Any format without a rigorous and public definition must be named + + + +Borenstein & Freed [Page 54] + +RFC 1521 MIME September 1993 + + + with an "X-" prefix, and publicly specified values shall never begin + with "X-". (Older versions of the widely-used Andrew system use the + "X-BE2" name, so new systems should probably choose a different + name.) + + In general, the use of "X-" top-level types is strongly discouraged. + Implementors should invent subtypes of the existing types whenever + possible. The invention of new types is intended to be restricted + primarily to the development of new media types for email, such as + digital odors or holography, and not for new data formats in general. + In many cases, a subtype of application will be more appropriate than + a new top-level type. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Borenstein & Freed [Page 55] + +RFC 1521 MIME September 1993 + + +8. Summary + + Using the MIME-Version, Content-Type, and Content-Transfer-Encoding + header fields, it is possible to include, in a standardized way, + arbitrary types of data objects with RFC 822 conformant mail + messages. No restrictions imposed by either RFC 821 or RFC 822 are + violated, and care has been taken to avoid problems caused by + additional restrictions imposed by the characteristics of some + Internet mail transport mechanisms (see Appendix B). The "multipart" + and "message" Content-Types allow mixing and hierarchical structuring + of objects of different types in a single message. Further Content- + Types provide a standardized mechanism for tagging messages or body + parts as audio, image, or several other kinds of data. A + distinguished parameter syntax allows further specification of data + format details, particularly the specification of alternate character + sets. Additional optional header fields provide mechanisms for + certain extensions deemed desirable by many implementors. Finally, a + number of useful Content-Types are defined for general use by + consenting user agents, notably message/partial, and + message/external-body. + +9. Security Considerations + + Security issues are discussed in Section 7.4.2 and in Appendix F. + Implementors should pay special attention to the security + implications of any mail content-types that can cause the remote + execution of any actions in the recipient's environment. In such + cases, the discussion of the application/postscript content-type in + Section 7.4.2 may serve as a model for considering other content- + types with remote execution capabilities. + + + + + + + + + + + + + + + + + + + + + +Borenstein & Freed [Page 56] + +RFC 1521 MIME September 1993 + + +10. Authors' Addresses + + For more information, the authors of this document may be contacted + via Internet mail: + + Nathaniel S. Borenstein + MRE 2D-296, Bellcore + 445 South St. + Morristown, NJ 07962-1910 + + Phone: +1 201 829 4270 + Fax: +1 201 829 7019 + Email: nsb@bellcore.com + + + Ned Freed + Innosoft International, Inc. + 250 West First Street + Suite 240 + Claremont, CA 91711 + + Phone: +1 909 624 7907 + Fax: +1 909 621 5319 + Email: ned@innosoft.com + + MIME is a result of the work of the Internet Engineering Task Force + Working Group on Email Extensions. The chairman of that group, Greg + Vaudreuil, may be reached at: + + Gregory M. Vaudreuil + Tigon Corporation + 17060 Dallas Parkway + Dallas Texas, 75248 + + Phone: +1 214-733-2722 + EMail: gvaudre@cnri.reston.va.us + + + + + + + + + + + + + + + +Borenstein & Freed [Page 57] + +RFC 1521 MIME September 1993 + + +11. Acknowledgements + + This document is the result of the collective effort of a large + number of people, at several IETF meetings, on the IETF-SMTP and + IETF-822 mailing lists, and elsewhere. Although any enumeration + seems doomed to suffer from egregious omissions, the following are + among the many contributors to this effort: + + Harald Tveit Alvestrand Timo Lehtinen + Randall Atkinson John R. MacMillan + Philippe Brandon Rick McGowan + Kevin Carosso Leo Mclaughlin + Uhhyung Choi Goli Montaser-Kohsari + Cristian Constantinof Keith Moore + Mark Crispin Tom Moore + Dave Crocker Erik Naggum + Terry Crowley Mark Needleman + Walt Daniels John Noerenberg + Frank Dawson Mats Ohrman + Hitoshi Doi Julian Onions + Kevin Donnelly Michael Patton + Keith Edwards David J. Pepper + Chris Eich Blake C. Ramsdell + Johnny Eriksson Luc Rooijakkers + Craig Everhart Marshall T. Rose + Patrik Faeltstroem Jonathan Rosenberg + Erik E. Fair Jan Rynning + Roger Fajman Harri Salminen + Alain Fontaine Michael Sanderson + James M. Galvin Masahiro Sekiguchi + Philip Gladstone Mark Sherman + Thomas Gordon Keld Simonsen + Phill Gross Bob Smart + James Hamilton Peter Speck + Steve Hardcastle-Kille Henry Spencer + David Herron Einar Stefferud + Bruce Howard Michael Stein + Bill Janssen Klaus Steinberger + Olle Jaernefors Peter Svanberg + Risto Kankkunen James Thompson + Phil Karn Steve Uhler + Alan Katz Stuart Vance + Tim Kehres Erik van der Poel + Neil Katin Guido van Rossum + Kyuho Kim Peter Vanderbilt + Anders Klemets Greg Vaudreuil + John Klensin Ed Vielmetti + Valdis Kletniek Ryan Waldron + + + +Borenstein & Freed [Page 58] + +RFC 1521 MIME September 1993 + + + Jim Knowles Wally Wedel + Stev Knowles Sven-Ove Westberg + Bob Kummerfeld Brian Wideen + Pekka Kytolaakso John Wobus + Stellan Lagerstrom Glenn Wright + Vincent Lau Rayan Zachariassen + Donald Lindsay David Zimmerman + Marc Andreessen Bob Braden + Brian Capouch Peter Clitherow + Dave Collier-Brown John Coonrod + Stephen Crocker Jim Davis + Axel Deininger Dana S Emery + Martin Forssen Stephen Gildea + Terry Gray Mark Horton + Warner Losh Carlyn Lowery + Laurence Lundblade Charles Lynn + Larry Masinter Michael J. McInerny + Jon Postel Christer Romson + Yutaka Sato Markku Savela + Richard Alan Schafer Larry W. Virden + Rhys Weatherly Jay Weber + Dave Wecker + +The authors apologize for any omissions from this list, which are +certainly unintentional. + + + + + + + + + + + + + + + + + + + + + + + + + + +Borenstein & Freed [Page 59] + +RFC 1521 MIME September 1993 + + +Appendix A -- Minimal MIME-Conformance + + The mechanisms described in this document are open-ended. It is + definitely not expected that all implementations will support all of + the Content-Types described, nor that they will all share the same + extensions. In order to promote interoperability, however, it is + useful to define the concept of "MIME-conformance" to define a + certain level of implementation that allows the useful interworking + of messages with content that differs from US ASCII text. In this + section, we specify the requirements for such conformance. + + A mail user agent that is MIME-conformant MUST: + + 1. Always generate a "MIME-Version: 1.0" header field. + + 2. Recognize the Content-Transfer-Encoding header field, and + decode all received data encoded with either the quoted-printable + or base64 implementations. Encode any data sent that is not in + seven-bit mail-ready representation using one of these + transformations and include the appropriate Content-Transfer- + Encoding header field, unless the underlying transport mechanism + supports non-seven-bit data, as SMTP does not. + + 3. Recognize and interpret the Content-Type header field, and + avoid showing users raw data with a Content-Type field other than + text. Be able to send at least text/plain messages, with the + character set specified as a parameter if it is not US-ASCII. + + 4. Explicitly handle the following Content-Type values, to at + least the following extents: + + Text: + + -- Recognize and display "text" mail + with the character set "US-ASCII." + + -- Recognize other character sets at + least to the extent of being able + to inform the user about what + character set the message uses. + + -- Recognize the "ISO-8859-*" character + sets to the extent of being able to + display those characters that are + common to ISO-8859-* and US-ASCII, + namely all characters represented + by octet values 0-127. + + + + +Borenstein & Freed [Page 60] + +RFC 1521 MIME September 1993 + + + -- For unrecognized subtypes, show or + offer to show the user the "raw" + version of the data after + conversion of the content from + canonical form to local form. + + Message: + + -- Recognize and display at least the + primary (822) encapsulation. + + Multipart: + + -- Recognize the primary (mixed) + subtype. Display all relevant + information on the message level + and the body part header level and + then display or offer to display + each of the body parts individually. + + -- Recognize the "alternative" subtype, + and avoid showing the user + redundant parts of + multipart/alternative mail. + + -- Treat any unrecognized subtypes as if + they were "mixed". + + Application: + + -- Offer the ability to remove either of + the two types of Content-Transfer- + Encoding defined in this document + and put the resulting information + in a user file. + + 5. Upon encountering any unrecognized Content- Type, an + implementation must treat it as if it had a Content-Type of + "application/octet-stream" with no parameter sub-arguments. How + such data are handled is up to an implementation, but likely + options for handling such unrecognized data include offering the + user to write it into a file (decoded from its mail transport + format) or offering the user to name a program to which the + decoded data should be passed as input. Unrecognized predefined + types, which in a MIME-conformant mailer might still include + audio, image, or video, should also be treated in this way. + + A user agent that meets the above conditions is said to be MIME- + + + +Borenstein & Freed [Page 61] + +RFC 1521 MIME September 1993 + + + conformant. The meaning of this phrase is that it is assumed to be + "safe" to send virtually any kind of properly-marked data to users of + such mail systems, because such systems will at least be able to + treat the data as undifferentiated binary, and will not simply splash + it onto the screen of unsuspecting users. There is another sense in + which it is always "safe" to send data in a format that is MIME- + conformant, which is that such data will not break or be broken by + any known systems that are conformant with RFC 821 and RFC 822. User + agents that are MIME-conformant have the additional guarantee that + the user will not be shown data that were never intended to be viewed + as text. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Borenstein & Freed [Page 62] + +RFC 1521 MIME September 1993 + + +Appendix B -- General Guidelines For Sending Email Data + + Internet email is not a perfect, homogeneous system. Mail may become + corrupted at several stages in its travel to a final destination. + Specifically, email sent throughout the Internet may travel across + many networking technologies. Many networking and mail technologies + do not support the full functionality possible in the SMTP transport + environment. Mail traversing these systems is likely to be modified + in such a way that it can be transported. + + There exist many widely-deployed non-conformant MTAs in the Internet. + These MTAs, speaking the SMTP protocol, alter messages on the fly to + take advantage of the internal data structure of the hosts they are + implemented on, or are just plain broken. + + The following guidelines may be useful to anyone devising a data + format (Content-Type) that will survive the widest range of + networking technologies and known broken MTAs unscathed. Note that + anything encoded in the base64 encoding will satisfy these rules, but + that some well-known mechanisms, notably the UNIX uuencode facility, + will not. Note also that anything encoded in the Quoted-Printable + encoding will survive most gateways intact, but possibly not some + gateways to systems that use the EBCDIC character set. + + (1) Under some circumstances the encoding used for data may change + as part of normal gateway or user agent operation. In particular, + conversion from base64 to quoted-printable and vice versa may be + necessary. This may result in the confusion of CRLF sequences with + line breaks in text bodies. As such, the persistence of CRLF as + something other than a line break must not be relied on. + + (2) Many systems may elect to represent and store text data using + local newline conventions. Local newline conventions may not match + the RFC822 CRLF convention -- systems are known that use plain CR, + plain LF, CRLF, or counted records. The result is that isolated + CR and LF characters are not well tolerated in general; they may + be lost or converted to delimiters on some systems, and hence must + not be relied on. + + (3) TAB (HT) characters may be misinterpreted or may be + automatically converted to variable numbers of spaces. This is + unavoidable in some environments, notably those not based on the + ASCII character set. Such conversion is STRONGLY DISCOURAGED, but + it may occur, and mail formats must not rely on the persistence of + TAB (HT) characters. + + (4) Lines longer than 76 characters may be wrapped or truncated in + some environments. Line wrapping and line truncation are STRONGLY + + + +Borenstein & Freed [Page 63] + +RFC 1521 MIME September 1993 + + + DISCOURAGED, but unavoidable in some cases. Applications which + require long lines must somehow differentiate between soft and + hard line breaks. (A simple way to do this is to use the quoted- + printable encoding.) + + (5) Trailing "white space" characters (SPACE, TAB (HT)) on a line + may be discarded by some transport agents, while other transport + agents may pad lines with these characters so that all lines in a + mail file are of equal length. The persistence of trailing white + space, therefore, must not be relied on. + + (6) Many mail domains use variations on the ASCII character set, + or use character sets such as EBCDIC which contain most but not + all of the US-ASCII characters. The correct translation of + characters not in the "invariant" set cannot be depended on across + character converting gateways. For example, this situation is a + problem when sending uuencoded information across BITNET, an + EBCDIC system. Similar problems can occur without crossing a + gateway, since many Internet hosts use character sets other than + ASCII internally. The definition of Printable Strings in X.400 + adds further restrictions in certain special cases. In + particular, the only characters that are known to be consistent + across all gateways are the 73 characters that correspond to the + upper and lower case letters A-Z and a-z, the 10 digits 0-9, and + the following eleven special characters: + + "'" (ASCII code 39) + "(" (ASCII code 40) + ")" (ASCII code 41) + "+" (ASCII code 43) + "," (ASCII code 44) + "-" (ASCII code 45) + "." (ASCII code 46) + "/" (ASCII code 47) + ":" (ASCII code 58) + "=" (ASCII code 61) + "?" (ASCII code 63) + + A maximally portable mail representation, such as the base64 + encoding, will confine itself to relatively short lines of text in + which the only meaningful characters are taken from this set of 73 + characters. + + (7) Some mail transport agents will corrupt data that includes + certain literal strings. In particular, a period (".") alone on a + line is known to be corrupted by some (incorrect) SMTP + implementations, and a line that starts with the five characters + "From " (the fifth character is a SPACE) are commonly corrupted as + + + +Borenstein & Freed [Page 64] + +RFC 1521 MIME September 1993 + + + well. A careful composition agent can prevent these corruptions + by encoding the data (e.g., in the quoted-printable encoding, + "=46rom " in place of "From " at the start of a line, and "=2E" in + place of "." alone on a line. + + Please note that the above list is NOT a list of recommended + practices for MTAs. RFC 821 MTAs are prohibited from altering the + character of white space or wrapping long lines. These BAD and + illegal practices are known to occur on established networks, and + implementations should be robust in dealing with the bad effects they + can cause. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Borenstein & Freed [Page 65] + +RFC 1521 MIME September 1993 + + +Appendix C -- A Complex Multipart Example + + What follows is the outline of a complex multipart message. This + message has five parts to be displayed serially: two introductory + plain text parts, an embedded multipart message, a richtext part, and + a closing encapsulated text message in a non-ASCII character set. + The embedded multipart message has two parts to be displayed in + parallel, a picture and an audio fragment. + + MIME-Version: 1.0 + From: Nathaniel Borenstein + To: Ned Freed + Subject: A multipart example + Content-Type: multipart/mixed; + boundary=unique-boundary-1 + + This is the preamble area of a multipart message. + Mail readers that understand multipart format + should ignore this preamble. + If you are reading this text, you might want to + consider changing to a mail reader that understands + how to properly display multipart messages. + --unique-boundary-1 + + ...Some text appears here... + [Note that the preceding blank line means + no header fields were given and this is text, + with charset US ASCII. It could have been + done with explicit typing as in the next part.] + + --unique-boundary-1 + Content-type: text/plain; charset=US-ASCII + + This could have been part of the previous part, + but illustrates explicit versus implicit + typing of body parts. + + --unique-boundary-1 + Content-Type: multipart/parallel; + boundary=unique-boundary-2 + + + --unique-boundary-2 + Content-Type: audio/basic + Content-Transfer-Encoding: base64 + + ... base64-encoded 8000 Hz single-channel + mu-law-format audio data goes here.... + + + +Borenstein & Freed [Page 66] + +RFC 1521 MIME September 1993 + + + --unique-boundary-2 + Content-Type: image/gif + Content-Transfer-Encoding: base64 + + ... base64-encoded image data goes here.... + + --unique-boundary-2-- + + --unique-boundary-1 + Content-type: text/richtext + + This is richtext. + as defined in RFC 1341 + Isn't it + cool? + + --unique-boundary-1 + Content-Type: message/rfc822 + + From: (mailbox in US-ASCII) + To: (address in US-ASCII) + Subject: (subject in US-ASCII) + Content-Type: Text/plain; charset=ISO-8859-1 + Content-Transfer-Encoding: Quoted-printable + + ... Additional text in ISO-8859-1 goes here ... + + --unique-boundary-1-- + + + + + + + + + + + + + + + + + + + + + + + +Borenstein & Freed [Page 67] + +RFC 1521 MIME September 1993 + + +Appendix D -- Collected Grammar + + This appendix contains the complete BNF grammar for all the syntax + specified by this document. + + By itself, however, this grammar is incomplete. It refers to several + entities that are defined by RFC 822. Rather than reproduce those + definitions here, and risk unintentional differences between the two, + this document simply refers the reader to RFC 822 for the remaining + definitions. Wherever a term is undefined, it refers to the RFC 822 + definition. + + application-subtype := ("octet-stream" *stream-param) + / "postscript" / extension-token + + application-type := "application" "/" application-subtype + + attribute := token ; case-insensitive + + atype := "ftp" / "anon-ftp" / "tftp" / "local-file" + / "afs" / "mail-server" / extension-token + ; Case-insensitive + + audio-type := "audio" "/" ("basic" / extension-token) + + body-part := <"message" as defined in RFC 822, + with all header fields optional, and with the + specified delimiter not occurring anywhere in + the message body, either on a line by itself + or as a substring anywhere.> + + NOTE: In certain transport enclaves, RFC 822 restrictions such as + the one that limits bodies to printable ASCII characters may not + be in force. (That is, the transport domains may resemble + standard Internet mail transport as specified in RFC821 and + assumed by RFC822, but without certain restrictions.) The + relaxation of these restrictions should be construed as locally + extending the definition of bodies, for example to include octets + outside of the ASCII range, as long as these extensions are + supported by the transport and adequately documented in the + Content-Transfer-Encoding header field. However, in no event are + headers (either message headers or body-part headers) allowed to + contain anything other than ASCII characters. + + + + + + + + +Borenstein & Freed [Page 68] + +RFC 1521 MIME September 1993 + + + boundary := 0*69 bcharsnospace + + bchars := bcharsnospace / " " + + bcharsnospace := DIGIT / ALPHA / "'" / "(" / ")" / "+" / "_" + / "," / "-" / "." / "/" / ":" / "=" / "?" + + charset := "us-ascii" / "iso-8859-1" / "iso-8859-2"/ "iso-8859-3" + / "iso-8859-4" / "iso-8859-5" / "iso-8859-6" / "iso-8859-7" + / "iso-8859-8" / "iso-8859-9" / extension-token + ; case insensitive + + close-delimiter := "--" boundary "--" CRLF;Again,no space by "--", + + content := "Content-Type" ":" type "/" subtype *(";" parameter) + ; case-insensitive matching of type and subtype + + delimiter := "--" boundary CRLF ;taken from Content-Type field. + ; There must be no space + ; between "--" and boundary. + + description := "Content-Description" ":" *text + + discard-text := *(*text CRLF) + + encapsulation := delimiter body-part CRLF + + encoding := "Content-Transfer-Encoding" ":" mechanism + + epilogue := discard-text ; to be ignored upon receipt. + + extension-token := x-token / iana-token + + external-param := (";" "access-type" "=" atype) + / (";" "expiration" "=" date-time) + + ; Note that date-time is quoted + / (";" "size" "=" 1*DIGIT) + / (";" "permission" "=" ("read" / "read-write")) + ; Permission is case-insensitive + / (";" "name" "=" value) + / (";" "site" "=" value) + / (";" "dir" "=" value) + / (";" "mode" "=" value) + / (";" "server" "=" value) + / (";" "subject" "=" value) + ;access-type required; others required based on access-type + + + + +Borenstein & Freed [Page 69] + +RFC 1521 MIME September 1993 + + + iana-token := + + id := "Content-ID" ":" msg-id + + image-type := "image" "/" ("gif" / "jpeg" / extension-token) + + mechanism := "7bit" ; case-insensitive + / "quoted-printable" + / "base64" + / "8bit" + / "binary" + / x-token + + message-subtype := "rfc822" + / "partial" 2#3partial-param + / "external-body" 1*external-param + / extension-token + + message-type := "message" "/" message-subtype + + multipart-body :=preamble 1*encapsulation close-delimiter epilogue + + multipart-subtype := "mixed" / "parallel" / "digest" + / "alternative" / extension-token + + multipart-type := "multipart" "/" multipart-subtype + ";" "boundary" "=" boundary + + octet := "=" 2(DIGIT / "A" / "B" / "C" / "D" / "E" / "F") + ; octet must be used for characters > 127, =, SPACE, or + TAB, + ; and is recommended for any characters not listed in + ; Appendix B as "mail-safe". + + padding := "0" / "1" / "2" / "3" / "4" / "5" / "6" / "7" + + parameter := attribute "=" value + + partial-param := (";" "id" "=" value) + / (";" "number" "=" 1*DIGIT) + / (";" "total" "=" 1*DIGIT) + ; id & number required;total required for last part + + preamble := discard-text ; to be ignored upon receipt. + + ptext := octet / " / "@" + / "," / ";" / ":" / "\" / <"> + / "/" / "[" / "]" / "?" / "=" + ; Must be in quoted-string, + ; to use within parameter values + + + type := "application" / "audio" ; case-insensitive + / "image" / "message" + / "multipart" / "text" + / "video" / extension-token + ; All values case-insensitive + + value := token / quoted-string + + version := "MIME-Version" ":" 1*DIGIT "." 1*DIGIT + + video-type := "video" "/" ("mpeg" / extension-token) + + x-token := + + + + + + + + + + + + + +Borenstein & Freed [Page 71] + +RFC 1521 MIME September 1993 + + +Appendix E -- IANA Registration Procedures + + MIME has been carefully designed to have extensible mechanisms, and + it is expected that the set of content-type/subtype pairs and their + associated parameters will grow significantly with time. Several + other MIME fields, notably character set names, access-type + parameters for the message/external-body type, and possibly even + Content-Transfer-Encoding values, are likely to have new values + defined over time. In order to ensure that the set of such values is + developed in an orderly, well-specified, and public manner, MIME + defines a registration process which uses the Internet Assigned + Numbers Authority (IANA) as a central registry for such values. + + In general, parameters in the content-type header field are used to + convey supplemental information for various content types, and their + use is defined when the content-type and subtype are defined. New + parameters should not be defined as a way to introduce new + functionality. + + In order to simplify and standardize the registration process, this + appendix gives templates for the registration of new values with + IANA. Each of these is given in the form of an email message + template, to be filled in by the registering party. + + E.1 Registration of New Content-type/subtype Values + + Note that MIME is generally expected to be extended by subtypes. If + a new fundamental top-level type is needed, its specification must be + published as an RFC or submitted in a form suitable to become an RFC, + and be subject to the Internet standards process. + + To: IANA@isi.edu + Subject: Registration of new MIME + content-type/subtype + + MIME type name: + + (If the above is not an existing top-level MIME type, + please explain why an existing type cannot be used.) + + MIME subtype name: + + Required parameters: + + Optional parameters: + + Encoding considerations: + + + + +Borenstein & Freed [Page 72] + +RFC 1521 MIME September 1993 + + + Security considerations: + + Published specification: + + (The published specification must be an Internet RFC or + RFC-to-be if a new top-level type is being defined, and + must be a publicly available specification in any + case.) + + Person & email address to contact for further information: + + E.2 Registration of New Access-type Values + for Message/external-body + + To: IANA@isi.edu + Subject: Registration of new MIME Access-type for + Message/external-body content-type + + MIME access-type name: + + Required parameters: + + Optional parameters: + + Published specification: + + (The published specification must be an Internet RFC or + RFC-to-be.) + + Person & email address to contact for further information: + + + + + + + + + + + + + + + + + + + + + +Borenstein & Freed [Page 73] + +RFC 1521 MIME September 1993 + + +Appendix F -- Summary of the Seven Content-types + + Content-type: text + + Subtypes defined by this document: plain + + Important Parameters: charset + + Encoding notes: quoted-printable generally preferred if an encoding + is needed and the character set is mostly an ASCII superset. + + Security considerations: Rich text formats such as TeX and Troff + often contain mechanisms for executing arbitrary commands or file + system operations, and should not be used automatically unless + these security problems have been addressed. Even plain text may + contain control characters that can be used to exploit the + capabilities of "intelligent" terminals and cause security + violations. User interfaces designed to run on such terminals + should be aware of and try to prevent such problems. + + ________________________________________________________ + Content-type: multipart + + Subtypes defined by this document: mixed, alternative, + digest, parallel. + + Important Parameters: boundary + + Encoding notes: No content-transfer-encoding is permitted. + + ________________________________________________________ + Content-type: message + + Subtypes defined by this document: rfc822, partial, external-body + + Important Parameters: id, number, total, access-type, expiration, + size, permission, name, site, directory, mode, server, subject + + Encoding notes: No content-transfer-encoding is permitted. + Specifically, only "7bit" is permitted for "message/partial" or + "message/external-body", and only "7bit", "8bit", or "binary" are + permitted for other subtypes of "message". + ______________________________________________________________ + Content-type: application + + Subtypes defined by this document: octet-stream, postscript + + Important Parameters: type, padding + + + +Borenstein & Freed [Page 74] + +RFC 1521 MIME September 1993 + + + Deprecated Parameters: name and conversions were + defined in RFC 1341. + + Encoding notes: base64 preferred for unreadable subtypes. + + Security considerations: This type is intended for the + transmission of data to be interpreted by locally-installed + programs. If used, for example, to transmit executable + binary programs or programs in general-purpose interpreted + languages, such as LISP programs or shell scripts, severe + security problems could result. Authors of mail-reading + agents are cautioned against giving their systems the power + to execute mail-based application data without carefully + considering the security implications. While it is + certainly possible to define safe application formats and + even safe interpreters for unsafe formats, each interpreter + should be evaluated separately for possible security + problems. + ________________________________________________________________ + Content-type: image + + Subtypes defined by this document: jpeg, gif + + Important Parameters: none + + Encoding notes: base64 generally preferred + ________________________________________________________________ + Content-type: audio + + Subtypes defined by this document: basic + + Important Parameters: none + + Encoding notes: base64 generally preferred + ________________________________________________________________ + Content-type: video + + Subtypes defined by this document: mpeg + + Important Parameters: none + + Encoding notes: base64 generally preferred + + + + + + + + + +Borenstein & Freed [Page 75] + +RFC 1521 MIME September 1993 + + +Appendix G -- Canonical Encoding Model + + There was some confusion, in earlier drafts of this memo, regarding + the model for when email data was to be converted to canonical form + and encoded, and in particular how this process would affect the + treatment of CRLFs, given that the representation of newlines varies + greatly from system to system. For this reason, a canonical model + for encoding is presented below. + + The process of composing a MIME entity can be modeled as being done + in a number of steps. Note that these steps are roughly similar to + those steps used in RFC 1421 and are performed for each 'innermost + level' body: + + Step 1. Creation of local form. + + The body to be transmitted is created in the system's native format. + The native character set is used, and where appropriate local end of + line conventions are used as well. The body may be a UNIX-style text + file, or a Sun raster image, or a VMS indexed file, or audio data in + a system-dependent format stored only in memory, or anything else + that corresponds to the local model for the representation of some + form of information. Fundamentally, the data is created in the + "native" form specified by the type/subtype information. + + Step 2. Conversion to canonical form. + + The entire body, including "out-of-band" information such as record + lengths and possibly file attribute information, is converted to a + universal canonical form. The specific content type of the body as + well as its associated attributes dictate the nature of the canonical + form that is used. Conversion to the proper canonical form may + involve character set conversion, transformation of audio data, + compression, or various other operations specific to the various + content types. If character set conversion is involved, however, + care must be taken to understand the semantics of the content-type, + which may have strong implications for any character set conversion, + e.g. with regard to syntactically meaningful characters in a text + subtype other than "plain". + + For example, in the case of text/plain data, the text must be + converted to a supported character set and lines must be delimited + with CRLF delimiters in accordance with RFC822. Note that the + restriction on line lengths implied by RFC822 is eliminated if the + next step employs either quoted-printable or base64 encoding. + + + + + + +Borenstein & Freed [Page 76] + +RFC 1521 MIME September 1993 + + + Step 3. Apply transfer encoding. + + A Content-Transfer-Encoding appropriate for this body is applied. + Note that there is no fixed relationship between the content type and + the transfer encoding. In particular, it may be appropriate to base + the choice of base64 or quoted-printable on character frequency + counts which are specific to a given instance of a body. + + Step 4. Insertion into entity. + + The encoded object is inserted into a MIME entity with appropriate + headers. The entity is then inserted into the body of a higher-level + entity (message or multipart) if needed. + + It is vital to note that these steps are only a model; they are + specifically NOT a blueprint for how an actual system would be built. + In particular, the model fails to account for two common designs: + + 1. In many cases the conversion to a canonical form prior to + encoding will be subsumed into the encoder itself, which + understands local formats directly. For example, the local + newline convention for text bodies might be carried through to the + encoder itself along with knowledge of what that format is. + + 2. The output of the encoders may have to pass through one or + more additional steps prior to being transmitted as a message. As + such, the output of the encoder may not be conformant with the + formats specified by RFC822. In particular, once again it may be + appropriate for the converter's output to be expressed using local + newline conventions rather than using the standard RFC822 CRLF + delimiters. + + Other implementation variations are conceivable as well. The vital + aspect of this discussion is that, in spite of any optimizations, + collapsings of required steps, or insertion of additional processing, + the resulting messages must be consistent with those produced by the + model described here. For example, a message with the following + header fields: + + Content-type: text/foo; charset=bar + Content-Transfer-Encoding: base64 + + must be first represented in the text/foo form, then (if necessary) + represented in the "bar" character set, and finally transformed via + the base64 algorithm into a mail-safe form. + + + + + + +Borenstein & Freed [Page 77] + +RFC 1521 MIME September 1993 + + +Appendix H -- Changes from RFC 1341 + + This document is a relatively minor revision of RFC 1341. For + the convenience of those familiar with RFC 1341, the technical + changes from that document are summarized in this appendix. + + 1. The definition of "tspecials" has been changed to no longer + include ".". + + 2. The Content-ID field is now mandatory for message/external-body + parts. + + 3. The text/richtext type (including the old Section 7.1.3 and + Appendix D) has been moved to a separate document. + + 4. The rules on header merging for message/partial data have been + changed to treat the Encrypted and MIME-Version headers as special + cases. + + 5. The definition of the external-body access-type parameter has + been changed so that it can only indicate a single access method + (which was all that made sense). + + 6. There is a new "Subject" parameter for message/external-body, + access-type mail-server, to permit MIME-based use of mail servers + that rely on Subject field information. + + 7. The "conversions" parameter for application/octet-stream has been + removed. + + 8. Section 7.4.1 now deprecates the use of the "name" parameter for + application/octet-stream, as this will be superseded in the future by + a Content-Disposition header. + + 9. The formal grammar for multipart bodies has been changed so that + a CRLF is no longer required before the first boundary line. + + 10. MIME entities of type "message/partial" and "message/external- + body" are now required to use only the "7bit" transfer-encoding. + (Specifically, "binary" and "8bit" are not permitted.) + + 11. The "application/oda" content-type has been removed. + + 12. A note has been added to the end of section 7.2.3, explaining + the semantics of Content-ID in a multipart/alternative MIME entity. + + 13. The formal syntax for the "MIME-Version" field has been + tightened, but in a way that is completely compatible with the only + + + +Borenstein & Freed [Page 78] + +RFC 1521 MIME September 1993 + + + version number defined in RFC 1341. + + 14. In Section 7.3.1, the definition of message/rfc822 has been + relaxed regarding mandatory fields. + + All other changes from RFC 1341 were editorial changes and do not + affect the technical content of MIME. Considerable formal grammar + has been added, but this reflects the prose specification that was + already in place. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Borenstein & Freed [Page 79] + +RFC 1521 MIME September 1993 + + +References + + [US-ASCII] Coded Character Set--7-Bit American Standard Code for + Information Interchange, ANSI X3.4-1986. + + [ATK] Borenstein, Nathaniel S., Multimedia Applications Development + with the Andrew Toolkit, Prentice-Hall, 1990. + + [GIF] Graphics Interchange Format (Version 89a), Compuserve, Inc., + Columbus, Ohio, 1990. + + [ISO-2022] International Standard--Information Processing--ISO 7-bit + and 8-bit coded character sets--Code extension techniques, ISO + 2022:1986. + + [ISO-8859] Information Processing -- 8-bit Single-Byte Coded Graphic + Character Sets -- Part 1: Latin Alphabet No. 1, ISO 8859-1:1987. Part + 2: Latin alphabet No. 2, ISO 8859-2, 1987. Part 3: Latin alphabet + No. 3, ISO 8859-3, 1988. Part 4: Latin alphabet No. 4, ISO 8859-4, + 1988. Part 5: Latin/Cyrillic alphabet, ISO 8859-5, 1988. Part 6: + Latin/Arabic alphabet, ISO 8859-6, 1987. Part 7: Latin/Greek + alphabet, ISO 8859-7, 1987. Part 8: Latin/Hebrew alphabet, ISO + 8859-8, 1988. Part 9: Latin alphabet No. 5, ISO 8859-9, 1990. + + [ISO-646] International Standard--Information Processing--ISO 7-bit + coded character set for information interchange, ISO 646:1983. + + [MPEG] Video Coding Draft Standard ISO 11172 CD, ISO IEC/TJC1/SC2/WG11 + (Motion Picture Experts Group), May, 1991. + + [PCM] CCITT, Fascicle III.4 - Recommendation G.711, Geneva, 1972, + "Pulse Code Modulation (PCM) of Voice Frequencies". + + [POSTSCRIPT] Adobe Systems, Inc., PostScript Language Reference + Manual, Addison-Wesley, 1985. + + [POSTSCRIPT2] Adobe Systems, Inc., PostScript Language Reference + Manual, Addison-Wesley, Second Edition, 1990. + + [X400] Schicker, Pietro, "Message Handling Systems, X.400", Message + Handling Systems and Distributed Applications, E. Stefferud, O-j. + Jacobsen, and P. Schicker, eds., North-Holland, 1989, pp. 3-41. + + [RFC-783] Sollins, K., "TFTP Protocol (revision 2)", RFC 783, MIT, + June 1981. + + [RFC-821] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC + 821, USC/Information Sciences Institute, August 1982. + + + +Borenstein & Freed [Page 80] + +RFC 1521 MIME September 1993 + + + [RFC-822] Crocker, D., "Standard for the Format of ARPA Internet Text + Messages", STD 11, RFC 822, UDEL, August 1982. + + [RFC-934] Rose, M., and E. Stefferud, "Proposed Standard for Message + Encapsulation", RFC 934, Delaware and NMA, January 1985. + + [RFC-959] Postel, J. and J. Reynolds, "File Transfer Protocol", + STD 9, RFC 959, USC/Information Sciences Institute, October 1985. + + [RFC-1049] Sirbu, M., "Content-Type Header Field for Internet + Messages", STD 11, RFC 1049, CMU, March 1988. + + [RFC-1421] Linn, J., "Privacy Enhancement for Internet Electronic Mail: + Part I - Message Encryption and Authentication Procedures", RFC + 1421, IAB IRTF PSRG, IETF PEM WG, February 1993. + + [RFC-1154] Robinson, D. and R. Ullmann, "Encoding Header Field for + Internet Messages", RFC 1154, Prime Computer, Inc., April 1990. + + [RFC-1341] Borenstein, N., and N. Freed, "MIME (Multipurpose Internet + Mail Extensions): Mechanisms for Specifying and Describing the Format + of Internet Message Bodies", RFC 1341, Bellcore, Innosoft, June 1992. + + [RFC-1342] Moore, K., "Representation of Non-Ascii Text in Internet + Message Headers", RFC 1342, University of Tennessee, June 1992. + + [RFC-1343] Borenstein, N., "A User Agent Configuration Mechanism + for Multimedia Mail Format Information", RFC 1343, Bellcore, June + 1992. + + [RFC-1344] Borenstein, N., "Implications of MIME for Internet + Mail Gateways", RFC 1344, Bellcore, June 1992. + + [RFC-1345] Simonsen, K., "Character Mnemonics & Character Sets", + RFC 1345, Rationel Almen Planlaegning, June 1992. + + [RFC-1426] Klensin, J., (WG Chair), Freed, N., (Editor), Rose, M., + Stefferud, E., and D. Crocker, "SMTP Service Extension for 8bit-MIME + transport", RFC 1426, United Nations Universit, Innosoft, Dover Beach + Consulting, Inc., Network Management Associates, Inc., The Branch + Office, February 1993. + + [RFC-1522] Moore, K., "Representation of Non-Ascii Text in Internet + Message Headers" RFC 1522, University of Tennessee, September 1993. + + [RFC-1340] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC + 1340, USC/Information Sciences Institute, July 1992. + + + + +Borenstein & Freed [Page 81] + \ No newline at end of file diff --git a/RFCs/rfc1522.txt b/RFCs/rfc1522.txt new file mode 100644 index 0000000..25bfd6b --- /dev/null +++ b/RFCs/rfc1522.txt @@ -0,0 +1,563 @@ + + + + + + +Network Working Group K. Moore +Request for Comments: 1522 University of Tennessee +Obsoletes: 1342 September 1993 +Category: Standards Track + + + MIME (Multipurpose Internet Mail Extensions) Part Two: + Message Header Extensions for Non-ASCII Text + +Status of this Memo + + This RFC specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" for the standardization state and status + of this protocol. Distribution of this memo is unlimited. + +Abstract + + This memo describes an extension to the message format defined in RFC + 1521 [1], to allow the representation of character sets other than + ASCII in RFC 822 (STD 11) message headers. The extensions described + were designed to be highly compatible with existing Internet mail + handling software, and to be easily implemented in mail readers that + support RFC 1521. + +1. Introduction + + RFC 1521 describes a mechanism for denoting textual body parts which + are coded in various character sets, as well as methods for encoding + such body parts as sequences of printable ASCII characters. This + memo describes similar techniques to allow the encoding of non-ASCII + text in various portions of a RFC 822 [2] message header, in a manner + which is unlikely to confuse existing message handling software. + + Like the encoding techniques described in RFC 1521, the techniques + outlined here were designed to allow the use of non-ASCII characters + in message headers in a way which is unlikely to be disturbed by the + quirks of existing Internet mail handling programs. In particular, + some mail relaying programs are known to (a) delete some message + header fields while retaining others, (b) rearrange the order of + addresses in To or Cc fields, (c) rearrange the (vertical) order of + header fields, and/or (d) "wrap" message headers at different places + than those in the original message. In addition, some mail reading + programs are known to have difficulty correctly parsing message + headers which, while legal according to RFC 822, make use of + backslash-quoting to "hide" special characters such as "<", ",", or + ":", or which exploit other infrequently-used features of that + + + +Moore [Page 1] + +RFC 1522 MIME Part Two September 1993 + + + specification. + + While it is unfortunate that these programs do not correctly + interpret RFC 822 headers, to "break" these programs would cause + severe operational problems for the Internet mail system. The + extensions described in this memo therefore do not rely on little- + used features of RFC 822. + + Instead, certain sequences of "ordinary" printable ASCII characters + (known as "encoded-words") are reserved for use as encoded data. The + syntax of encoded-words is such that they are unlikely to + "accidentally" appear as normal text in message headers. + Furthermore, the characters used in encoded-words are restricted to + those which do not have special meanings in the context in which the + encoded-word appears. + + Generally, an "encoded-word" is a sequence of printable ASCII + characters that begins with "=?", ends with "?=", and has two "?"s in + between. It specifies a character set and an encoding method, and + also includes the original text encoded as graphic ASCII characters, + according to the rules for that encoding method. + + A mail composer that implements this specification will provide a + means of inputting non-ASCII text in header fields, but will + translate these fields (or appropriate portions of these fields) into + encoded-words before inserting them into the message header. + + A mail reader that implements this specification will recognize + encoded-words when they appear in certain portions of the message + header. Instead of displaying the encoded-word "as is", it will + reverse the encoding and display the original text in the designated + character set. + + NOTES + + This memo relies heavily on notation and terms defined STD 11, RFC + 822 and RFC 1521. In particular, the syntax for the ABNF used in + this memo is defined in STD 11, RFC 822, as well as many of the + terms used in the grammar for the header extensions defined here. + Successful implementation of this protocol extension requires + careful attention to the details of both STD 11, RFC 822 and RFC + 1521. + + When the term "ASCII" appears in this memo, it refers to the "7- + Bit American Standard Code for Information Interchange", ANSI + X3.4-1986. The MIME charset name for this character set is "US- + ASCII". When not specifically referring to the MIME charset name, + this document uses the term "ASCII", both for brevity and for + + + +Moore [Page 2] + +RFC 1522 MIME Part Two September 1993 + + + consistency with STD 11, RFC 822. However, implementors are + warned that the character set name must be spelled "US-ASCII" in + MIME message and body part headers. + +2. Syntax of encoded-words + + An "encoded-word" is defined by the following ABNF grammar. The + notation of RFC 822 is used, with the exception that white space + characters MAY NOT appear between components of an encoded-word. + + encoded-word = "=?" charset "?" encoding "?" encoded-text "?=" + + charset = token ; see section 3 + + encoding = token ; see section 4 + + token = 1* + + especials = "(" / ")" / "<" / ">" / "@" / "," / ";" / ":" / " + <"> / "/" / "[" / "]" / "?" / "." / "=" + + encoded-text = 1* + ; (but see "Use of encoded-words in message + ; headers", section 5) + + Both "encoding" and "charset" names are case-independent. Thus the + charset name "ISO-8859-1" is equivalent to "iso-8859-1", and the + encoding named "Q" may be spelled either "Q" or "q". + + An encoded-word may not be more than 75 characters long, including + charset, encoding, encoded-text, and delimiters. If it is desirable + to encode more text than will fit in an encoded-word of 75 + characters, multiple encoded-words (separated by CRLF SPACE) may be + used. + + While there is no limit to the length of a multiple-line header + field, each line of a header field that contains one or more + encoded-words is limited to 76 characters. + + The length restrictions are included not only to ease + interoperability through internetwork mail gateways, but also to + impose a limit on the amount of lookahead a header parser must employ + (while looking for a final ?= delimiter) before it can decide whether + a token is an encoded-word or something else. + + The characters which may appear in encoded-text are further + restricted by the rules in section 5. + + + +Moore [Page 3] + +RFC 1522 MIME Part Two September 1993 + + +3. Character sets + + The "charset" portion of an encoded-word specifies the character set + associated with the unencoded text. A charset can be any of the + character set names allowed in an RFC 1521 "charset" parameter of a + "text/plain" body part, or any character set name registered with + IANA for use with the MIME text/plain content-type [3]. (See section + 7.1.1 of RFC 1521 for a list of charsets defined in that document). + + Some character sets use code-switching techniques to switch between + "ASCII mode" and other modes. If unencoded text in an encoded-word + contains control codes to switch out of ASCII mode, it must also + contain additional control codes such that ASCII mode is again + selected at the end of the encoded-word. (This rule applies + separately to each encoded-word, including adjacent encoded-words + within a single header field.) + + When there is a possibility of using more than one character set to + represent the text in an encoded-word, and in the absence of private + agreements between sender and recipients of a message, it is + recommended that members of the ISO-8859-* series be used in + preference to other character sets. + +4. Encodings + + Initially, the legal values for "encoding" are "Q" and "B". These + encodings are described below. The "Q" encoding is recommended for + use when most of the characters to be encoded are in the ASCII + character set; otherwise, the "B" encoding should be used. + Nevertheless, a mail reader which claims to recognize encoded-words + MUST be able to accept either encoding for any character set which it + supports. + + Only a subset of the printable ASCII characters may be used in + encoded-text. Space and tab characters are not allowed, so that the + beginning and end of an encoded-word are obvious. The "?" character + is used within an encoded-word to separate the various portions of + the encoded-word from one another, and thus cannot appear in the + encoded-text portion. Other characters are also illegal in certain + contexts. For example, an encoded-word in a "phrase" preceding an + address in a From header field may not contain any of the "specials" + defined in RFC 822. Finally, certain other characters are disallowed + in some contexts, to ensure reliability for messages that pass + through internetwork mail gateways. + + The "B" encoding automatically meets these requirements. The "Q" + encoding allows a wide range of printable characters to be used in + non-critical locations in the message header (e.g., Subject), with + + + +Moore [Page 4] + +RFC 1522 MIME Part Two September 1993 + + + fewer characters available for use in other locations. + +4.1. The "B" encoding + + The "B" encoding is identical to the "BASE64" encoding defined by RFC + 1521. + +4.2. The "Q" encoding + + The "Q" encoding is similar to the "Quoted-Printable" content- + transfer-encoding defined in RFC 1521. It is designed to allow text + containing mostly ASCII characters to be decipherable on an ASCII + terminal without decoding. + + (1) Any 8-bit value may be represented by a "=" followed by two + hexadecimal digits. For example, if the character set in use + were ISO-8859-1, the "=" character would thus be encoded as + "=3D", and a SPACE by "=20". (Upper case should be used for + hexadecimal digits "A" through "F".) + + (2) The 8-bit hexadecimal value 20 (e.g., ISO-8859-1 SPACE) may be + represented as "_" (underscore, ASCII 95.). (This character may + not pass through some internetwork mail gateways, but its use + will greatly enhance readability of "Q" encoded data with mail + readers that do not support this encoding.) Note that the "_" + always represents hexadecimal 20, even if the SPACE character + occupies a different code position in the character set in use. + + (3) 8-bit values which correspond to printable ASCII characters other + than "=", "?", "_" (underscore), and SPACE may be represented as + those characters. (But see section 5 for restrictions.) + +5. Use of encoded-words in message headers + + An encoded-word may appear in a message header or body part header + according to the following rules: + + (1) An encoded-word may replace a "text" token (as defined by RFC + 822) in any Subject or Comments header field, any extension + message header field, or any RFC 1521 body part field for which + the field body is defined as "*text". An encoded-word may also + appear in any user-defined ("X-") message or body part header + field. + + Ordinary ASCII text and encoded-words may appear together in the + same header field. However, an encoded-word that appears in a + header field defined as "*text" MUST be separated from any + adjacent encoded-word or "text" by linear-white-space. + + + +Moore [Page 5] + +RFC 1522 MIME Part Two September 1993 + + + (2) An encoded-word may appear within a comment delimited by "(" and + ")", i.e., wherever a "ctext" is allowed. More precisely, the + RFC 822 ABNF definition for "comment" is amended as follows: + + comment = "(" *(ctext / quoted-pair / comment / encoded-word) ")" + + A "Q"-encoded encoded-word which appears in a comment MUST NOT + contain the characters "(", ")" or " encoded-word that appears in + a "comment" MUST be separated from any adjacent encoded-word or + "ctext" by linear-white-space. + + (3) As a replacement for a "word" entity within a "phrase", for + example, one that precedes an address in a From, To, or Cc + header. The ABNF definition for phrase from RFC 822 thus + becomes: + + phrase = 1*(encoded-word / word) + + In this case the set of characters that may be used in a "Q"- + encoded encoded-word is restricted to: . An encoded-word that appears + within a "phrase" MUST be separated from any adjacent "word", + "text" or "special" by linear-white-space. + + These are the ONLY locations where an encoded-word may appear. In + particular, an encoded-word MUST NOT appear in any portion of an + "addr-spec". In addition, an encoded-word MUST NOT be used in a + Received header field. + + Each encoded-word MUST encode an integral number of octets. The + encoded-text in each encoded-word must be well-formed according to + the encoding specified; the encoded-text may not be continued in the + next encoded-word. (For example, "=?charset?Q?=?= =?charset?Q?AB?=" + would be illegal, because the two hex digits "AB" must follow the "=" + in the same encoded-word.) + + Each encoded-word MUST represent an integral number of characters. A + multi-octet character may not be split across adjacent encoded-words. + + Only printable and white space character data should be encoded using + this scheme. However, since these encoding schemes allow the + encoding of arbitrary octet values, mail readers that implement this + decoding should also ensure that display of the decoded data on the + recipient's terminal will not cause unwanted side-effects. + + Use of these methods to encode non-textual data (e.g., pictures or + sounds) is not defined by this memo. Use of encoded-words to + + + +Moore [Page 6] + +RFC 1522 MIME Part Two September 1993 + + + represent strings of purely ASCII characters is allowed, but + discouraged. In rare cases it may be necessary to encode ordinary + text that looks like an encoded-word. + +6. Support of encoded-words by mail readers + +6.1. Recognition of encoded-words in message headers + + A mail reader must parse the message and body part headers according + to the rules in RFC 822 to correctly recognize encoded-words. + + Encoded-words are to be recognized as follows: + + (1) Any message or body part header field defined as "*text", or any + user-defined header field, should be parsed as follows: Beginning + at the start of the field-body and immediately following each + occurrence of linear-white-space, each sequence of up to 75 + printable characters (not containing any linear-white-space) + should be examined to see if it is an encoded-word according to + the syntax rules in section 2. Any other sequence of printable + characters should be treated as ordinary ASCII text. + + (2) Any header field not defined as "*text" should be parsed + according to the syntax rules for that header field. However, + any "word" that appears within a "phrase" should be treated as an + encoded-word if it meets the syntax rules in section 2. + Otherwise it should be treated as an ordinary "word". + + (3) Within a "comment", any sequence of up to 75 printable characters + (not containing linear-white-space), that meets the syntax rules + in section 2, should be treated as an encoded-word. Otherwise it + should be treated as normal comment text. + +6.2. Display of encoded-words + + Any encoded-words so recognized are decoded, and if possible, the + resulting unencoded text is displayed in the original character set. + + When displaying a particular header field that contains multiple + encoded-words, any linear-white-space that separates a pair of + adjacent encoded-words is ignored. (This is to allow the use of + multiple encoded-words to represent long strings of unencoded text, + without having to separate encoded-words where spaces occur in the + unencoded text.) + + In the event other encodings are defined in the future, and the mail + reader does not support the encoding used, it may either (a) display + the encoded-word as ordinary text, or (b) substitute an appropriate + + + +Moore [Page 7] + +RFC 1522 MIME Part Two September 1993 + + + message indicating that the text could not be decoded. + + If the mail reader does not support the character set used, it may + (a) display the encoded-word as ordinary text (i.e., as it appears in + the header), (b) make a "best effort" to display using such + characters as are available, or (c) substitute an appropriate message + indicating that the decoded text could not be displayed. + + If the character set being used employs code-switching techniques, + display of the encoded text implicitly begins in "ASCII mode". In + addition, the mail reader must ensure that the output device is once + again in "ASCII mode" after the encoded-word is displayed. + +6.3. Mail reader handling of incorrectly formed encoded-words + + It is possible that an encoded-word that is legal according to the + syntax defined in section 2, is incorrectly formed according to the + rules for the encoding being used. For example: + + (1) An encoded-word which contains characters which are not legal for + a particular encoding (for example, a '-' in the "B" encoding), + is incorrectly formed. + + (2) Any encoded-word which encodes a non-integral number of + characters or octets is incorrectly formed. + + A mail reader need not attempt to display the text associated with an + encoded-word that is incorrectly formed. However, a mail reader MUST + NOT prevent the display or handling of a message because an encoded- + word is incorrectly formed. + +7. Conformance + + A mail composing program claiming compliance with this specification + MUST ensure that any string of non-white-space printable ASCII + characters within a "*text" or "*ctext" that begins with "=?" and + ends with "?=" be a valid encoded-word. ("begins" means: at the + start of the field-body or immediately following linear-white-space; + "ends" means: at the end of the field-body or immediately preceding + linear-white-space.) In addition, any "word" within a "phrase" that + begins with "=?" and ends with "?=" must be a valid encoded-word. + + A mail reading program claiming compliance with this specification + must be able to distinguish encoded-words from "text", "ctext", or + "word"s, according to the rules in section 6, anytime they appear in + appropriate places in message headers. It must support both the "B" + and "Q" encodings for any character set which it supports. The + program must be able to display the unencoded text if the character + + + +Moore [Page 8] + +RFC 1522 MIME Part Two September 1993 + + + set is "US-ASCII". For the ISO-8859-* character sets, the mail + reading program must at least be able to display the characters which + are also in the ASCII set. + +8. Examples + + From: =?US-ASCII?Q?Keith_Moore?= + To: =?ISO-8859-1?Q?Keld_J=F8rn_Simonsen?= + CC: =?ISO-8859-1?Q?Andr=E9_?= Pirard + Subject: =?ISO-8859-1?B?SWYgeW91IGNhbiByZWFkIHRoaXMgeW8=?= + =?ISO-8859-2?B?dSB1bmRlcnN0YW5kIHRoZSBleGFtcGxlLg==?= + + From: =?ISO-8859-1?Q?Olle_J=E4rnefors?= + To: ietf-822@dimacs.rutgers.edu, ojarnef@admin.kth.se + Subject: Time for ISO 10646? + + To: Dave Crocker + Cc: ietf-822@dimacs.rutgers.edu, paf@comsol.se + From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= + Subject: Re: RFC-HDR care and feeding + + From: Nathaniel Borenstein + (=?iso-8859-8?b?7eXs+SDv4SDp7Oj08A==?=) + To: Greg Vaudreuil , Ned Freed + , Keith Moore + Subject: Test of new header generator + MIME-Version: 1.0 + Content-type: text/plain; charset=ISO-8859-1 + +9. References + + [1] Borenstein N., and N. Freed, "MIME (Multipurpose Internet Mail + Extensions) Part One: Mechanisms for Specifying and Describing + the Format of Internet Message Bodies", RFC 1521, Bellcore, + Innosoft, September 1993. + + [2] Crocker, D., "Standard for the Format of ARPA Internet Text + Messages", STD 11, RFC 822, UDEL, August 1982. + + [3] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, + RFC 1340, USC/Information Sciences Institute, July 1992. + + + + + + + + + + +Moore [Page 9] + +RFC 1522 MIME Part Two September 1993 + + +10. Security Considerations + + Security issues are not discussed in this memo. + +11. Author's Address + + Keith Moore + University of Tennessee + 107 Ayres Hall + Knoxville TN 37996-1301 + + EMail: moore@cs.utk.edu + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Moore [Page 10] + \ No newline at end of file diff --git a/RFCs/rfc1730.txt b/RFCs/rfc1730.txt new file mode 100644 index 0000000..bf45da5 --- /dev/null +++ b/RFCs/rfc1730.txt @@ -0,0 +1,4318 @@ + + + + + + +Network Working Group M. Crispin +Request for Comments: 1730 University of Washington +Category: Standards Track December 1994 + + + INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4 + + + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + + +Abstract + + The Internet Message Access Protocol, Version 4 (IMAP4) allows a + client to access and manipulate electronic mail messages on a server. + IMAP4 permits manipulation of remote message folders, called + "mailboxes", in a way that is functionally equivalent to local + mailboxes. IMAP4 also provides the capability for an offline client + to resynchronize with the server (see also [IMAP-DISC]). + + IMAP4 includes operations for creating, deleting, and renaming + mailboxes; checking for new messages; permanently removing messages; + setting and clearing flags; RFC 822 and MIME parsing; searching; and + selective fetching of message attributes, texts, and portions + thereof. Messages in IMAP4 are accessed by the use of numbers. + These numbers are either message sequence numbers (relative position + from 1 to the number of messages in the mailbox) or unique + identifiers (immutable, strictly ascending values assigned to each + message, but which are not necessarily contiguous). + + IMAP4 supports a single server. A mechanism for supporting multiple + IMAP4 servers is discussed in [IMSP]. + + IMAP4 does not specify a means of posting mail; this function is + handled by a mail transfer protocol such as [SMTP]. + + IMAP4 is designed to be upwards compatible from the [IMAP2] protocol. + Compatibility issues are discussed in [IMAP-COMPAT]. + + + + + + +Crispin [Page i] + +RFC 1730 IMAP4 December 1994 + + + + + +Table of Contents + + + +IMAP4 Protocol Specification ...................................... 1 +1. Organization of this Document ............................. 1 +1.1. How to Read This Document ................................. 1 +1.2. Conventions Used in this Document ......................... 1 +2. Protocol Overview ......................................... 1 +2.1. Link Level ................................................ 1 +2.2. Commands and Responses .................................... 1 +2.2.1. Client Protocol Sender and Server Protocol Receiver ....... 2 +2.2.2. Server Protocol Sender and Client Protocol Receiver ....... 2 +3. State and Flow Diagram .................................... 4 +3.1. Non-Authenticated State ................................... 4 +3.2. Authenticated State ....................................... 4 +3.3. Selected State ............................................ 4 +3.4. Logout State .............................................. 4 +4. Data Formats .............................................. 6 +4.1. Atom ...................................................... 6 +4.2. Number .................................................... 6 +4.3. String .................................................... 6 +4.3.1. 8-bit and Binary Strings .................................. 7 +4.4. Parenthesized List ........................................ 7 +4.5. NIL ....................................................... 7 +5. Operational Considerations ................................ 8 +5.1. Mailbox Naming ............................................ 8 +5.2. Mailbox Size and Message Status Updates ................... 8 +5.3. Response when no Command in Progress ...................... 8 +5.4. Autologout Timer .......................................... 9 +5.5. Multiple Commands in Progress ............................. 9 +6. Client Commands ........................................... 10 +6.1. Client Commands - Any State ............................... 10 +6.1.1. CAPABILITY Command ........................................ 10 +6.1.2. NOOP Command .............................................. 11 +6.1.3. LOGOUT Command ............................................ 11 +6.2. Client Commands - Non-Authenticated State ................. 12 +6.2.1. AUTHENTICATE Command ...................................... 12 +6.2.2. LOGIN Command ............................................. 14 +6.3. Client Commands - Authenticated State ..................... 14 +6.3.1. SELECT Command ............................................ 15 +6.3.2. EXAMINE Command ........................................... 16 +6.3.3. CREATE Command ............................................ 17 +6.3.4. DELETE Command ............................................ 18 +6.3.5. RENAME Command ............................................ 18 + + + +Crispin [Page ii] + +RFC 1730 IMAP4 December 1994 + + +6.3.6. SUBSCRIBE Command ......................................... 19 +6.3.7. UNSUBSCRIBE Command ....................................... 19 +6.3.8. LIST Command .............................................. 20 +6.3.9. LSUB Command .............................................. 22 +6.3.10. APPEND Command ............................................ 22 +6.4. Client Commands - Selected State .......................... 23 +6.4.1. CHECK Command ............................................. 23 +6.4.2. CLOSE Command ............................................. 24 +6.4.3. EXPUNGE Command ........................................... 25 +6.4.4. SEARCH Command ............................................ 25 +6.4.5. FETCH Command ............................................. 29 +6.4.6. PARTIAL Command ........................................... 32 +6.4.7. STORE Command ............................................. 33 +6.4.8. COPY Command .............................................. 34 +6.4.9. UID Command ............................................... 35 +6.5. Client Commands - Experimental/Expansion .................. 37 +6.5.1. X Command ........................................... 37 +7. Server Responses .......................................... 38 +7.1. Server Responses - Status Responses ....................... 39 +7.1.1. OK Response ............................................... 40 +7.1.2. NO Response ............................................... 40 +7.1.3. BAD Response .............................................. 41 +7.1.4. PREAUTH Response .......................................... 41 +7.1.5. BYE Response .............................................. 41 +7.2. Server Responses - Server and Mailbox Status .............. 42 +7.2.1. CAPABILITY Response ....................................... 42 +7.2.2. LIST Response ............................................. 43 +7.2.3. LSUB Response ............................................. 44 +7.2.4. SEARCH Response ........................................... 44 +7.2.5. FLAGS Response ............................................ 44 +7.3. Server Responses - Message Status ......................... 45 +7.3.1. EXISTS Response ........................................... 45 +7.3.2. RECENT Response ........................................... 45 +7.3.3. EXPUNGE Response .......................................... 45 +7.3.4. FETCH Response ............................................ 46 +7.3.5. Obsolete Responses ........................................ 51 +7.4. Server Responses - Command Continuation Request ........... 51 +8. Sample IMAP4 session ...................................... 52 +9. Formal Syntax ............................................. 53 +10. Author's Note ............................................. 64 +11. Security Considerations ................................... 64 +12. Author's Address .......................................... 64 +Appendices ........................................................ 65 +A. Obsolete Commands ......................................... 65 +A.6.3.OBS.1. FIND ALL.MAILBOXES Command ........................ 65 +A.6.3.OBS.2. FIND MAILBOXES Command ............................ 65 +A.6.3.OBS.3. SUBSCRIBE MAILBOX Command ......................... 66 +A.6.3.OBS.4. UNSUBSCRIBE MAILBOX Command ....................... 66 + + + +Crispin [Page iii] + +RFC 1730 IMAP4 December 1994 + + +B. Obsolete Responses ........................................ 68 +B.7.2.OBS.1. MAILBOX Response .................................. 68 +B.7.3.OBS.1. COPY Response ..................................... 68 +B.7.3.OBS.2. STORE Response .................................... 69 +C. References ................................................ 70 +E. IMAP4 Keyword Index ....................................... 71 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Crispin [Page iv] + +RFC 1730 IMAP4 December 1994 + + +IMAP4 Protocol Specification + +1. Organization of this Document + +1.1. How to Read This Document + + This document is written from the point of view of the implementor of + an IMAP4 client or server. Beyond the protocol overview in section + 2, it is not optimized for someone trying to understand the operation + of the protocol. The material in sections 3 through 5 provides the + general context and definitions with which IMAP4 operates. + + Sections 6, 7, and 9 describe the IMAP commands, responses, and + syntax, respectively. The relationships among these are such that it + is almost impossible to understand any of them separately. In + particular, one should not attempt to deduce command syntax from the + command section alone; one should instead refer to the formal syntax + section. + + +1.2. Conventions Used in this Document + + In examples, "C:" and "S:" indicate lines sent by the client and + server respectively. + + +2. Protocol Overview + +2.1. Link Level + + The IMAP4 protocol assumes a reliable data stream such as provided by + TCP. When TCP is used, an IMAP4 server listens on port 143. + + +2.2. Commands and Responses + + An IMAP4 session consists of the establishment of a client/server + connection, an initial greeting from the server, and client/server + interactions. These client/server interactions consist of a client + command, server data, and a server completion result response. + + All interactions transmitted by client and server are in the form of + lines; that is, strings that end with a CRLF. The protocol receiver + of an IMAP4 client or server is either reading a line, or is reading + a sequence of octets with a known count followed by a line. + + + + + + +Crispin [Page 1] + +RFC 1730 IMAP4 December 1994 + + +2.2.1. Client Protocol Sender and Server Protocol Receiver + + The client command begins an operation. Each client command is + prefixed with a identifier (typically a short alphanumeric string, + e.g. A0001, A0002, etc.) called a "tag". A different tag is + generated by the client for each command. + + There are two cases in which a line from the client does not + represent a complete command. In one case, a command argument is + quoted with an octet count (see the description of literal in String + under Data Formats); in the other case, the command arguments require + server feedback (see the AUTHENTICATE command). In either case, the + server sends a command continuation request response if it is ready + for the octets (if appropriate) and the remainder of the command. + This response is prefixed with the token "+". + + Note: If, instead, the server detected an error in the + command, it sends a BAD completion response with tag + matching the command (as described below) to reject the + command and prevent the client from sending any more of the + command. + + It is also possible for the server to send a completion + response for some other command (if multiple commands are + in progress), or untagged data. In either case, the + command continuation request is still pending; the client + takes the appropriate action for the response, and reads + another response from the server. + + The protocol receiver of an IMAP4 server reads a command line from + the client, parses the command and its arguments, and transmits + server data and a server command completion result response. + + +2.2.2. Server Protocol Sender and Client Protocol Receiver + + Data transmitted by the server to the client and status responses + that do not indicate command completion are prefixed with the token + "*", and are called untagged responses. + + Server data may be sent as a result of a client command, or may be + sent unilaterally by the server. There is no syntactic difference + between server data that resulted from a specific command and server + data that were sent unilaterally. + + The server completion result response indicates the success or + failure of the operation. It is tagged with the same tag as the + client command which began the operation. Thus, if more than one + + + +Crispin [Page 2] + +RFC 1730 IMAP4 December 1994 + + + command is in progress, the tag in a server completion response + identifies the command to which the response applies. There are + three possible server completion responses: OK (indicating success), + NO (indicating failure), or BAD (indicating protocol error such as + unrecognized command or command syntax error). + + The protocol receiver of an IMAP4 client reads a response line from + the server. It then takes action on the response based upon the + first token of the response, which may be a tag, a "*", or a "+". As + described above. + + A client MUST be prepared to accept any server response at all times. + This includes server data that it may not have requested. Server + data SHOULD be recorded, so that the client can reference its + recorded copy rather than sending a command to the server to request + the data. In the case of certain server data, recording the data is + mandatory. + + This topic is discussed in greater detail in the Server Responses + section. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Crispin [Page 3] + +RFC 1730 IMAP4 December 1994 + + +3. State and Flow Diagram + + An IMAP4 server is in one of four states. Most commands are valid in + only certain states. It is a protocol error for the client to + attempt a command while the command is in an inappropriate state. In + this case, a server will respond with a BAD or NO (depending upon + server implementation) command completion result. + + +3.1. Non-Authenticated State + + In non-authenticated state, the user must supply authentication + credentials before most commands will be permitted. This state is + entered when a connection starts unless the connection has been + pre-authenticated. + + +3.2. Authenticated State + + In authenticated state, the user is authenticated and must select a + mailbox to access before commands that affect messages will be + permitted. This state is entered when a pre-authenticated connection + starts, when acceptable authentication credentials have been + provided, or after an error in selecting a mailbox. + + +3.3. Selected State + + In selected state, a mailbox has been selected to access. This state + is entered when a mailbox has been successfully selected. + + +3.4. Logout State + + In logout state, the session is being terminated, and the server will + close the connection. This state can be entered as a result of a + client request or by unilateral server decision. + + + + + + + + + + + + + + +Crispin [Page 4] + +RFC 1730 IMAP4 December 1994 + + + +--------------------------------------+ + |initial connection and server greeting| + +--------------------------------------+ + || (1) || (2) || (3) + VV || || + +-----------------+ || || + |non-authenticated| || || + +-----------------+ || || + || (7) || (4) || || + || VV VV || + || +----------------+ || + || | authenticated |<=++ || + || +----------------+ || || + || || (7) || (5) || (6) || + || || VV || || + || || +--------+ || || + || || |selected|==++ || + || || +--------+ || + || || || (7) || + VV VV VV VV + +--------------------------------------+ + | logout and close connection | + +--------------------------------------+ + + (1) connection without pre-authentication (OK greeting) + (2) pre-authenticated connection (PREAUTH greeting) + (3) rejected connection (BYE greeting) + (4) successful LOGIN or AUTHENTICATE command + (5) successful SELECT or EXAMINE command + (6) CLOSE command, or failed SELECT or EXAMINE command + (7) LOGOUT command, server shutdown, or connection closed + + + + + + + + + + + + + + + + + + + + +Crispin [Page 5] + +RFC 1730 IMAP4 December 1994 + + +4. Data Formats + + IMAP4 uses textual commands and responses. Data in IMAP4 can be in + one of several forms: atom, number, string, parenthesized list, or + NIL. + + +4.1. Atom + + An atom consists of one or more non-special characters. + + +4.2. Number + + A number consists of one or more digit characters, and represents a + numeric value. + + +4.3. String + + A string is in one of two forms: literal and quoted string. The + literal form is the general form of string. The quoted string form + is an alternative that avoids the overhead of processing a literal at + the cost of restrictions of what may be in a quoted string. + + A literal is a sequence of zero or more octets (including CR and LF), + prefix-quoted with an octet count in the form of an open brace ("{"), + the number of octets, close brace ("}"), and CRLF. In the case of + literals transmitted from server to client, the CRLF is immediately + followed by the octet data. In the case of literals transmitted from + client to server, the client must wait to receive a command + continuation request (described later in this document) before + sending the octet data (and the remainder of the command). + + A quoted string is a sequence of zero or more 7-bit characters, + excluding CR and LF, with double quote (<">) characters at each end. + + The empty string is respresented as either "" (a quoted string with + zero characters between double quotes) or as {0} followed by CRLF (a + literal with an octet count of 0). + + Note: Even if the octet count is 0, a client transmitting a + literal must wait to receive a command continuation + request. + + + + + + + +Crispin [Page 6] + +RFC 1730 IMAP4 December 1994 + + +4.3.1. 8-bit and Binary Strings + + 8-bit textual and binary mail is supported through the use of + [MIME-1] encoding. IMAP4 implementations MAY transmit 8-bit or + multi-octet characters in literals, but should do so only when the + character set is identified. + + Although a BINARY body encoding is defined, unencoded binary strings + are not permitted. A "binary string" is any string with NUL + characters. Implementations MUST encode binary data into a textual + form such as BASE64 before transmitting the data. A string with an + excessive amount of CTL characters may also be considered to be + binary, although this is not required. + + +4.4. Parenthesized List + + Data structures are represented as a "parenthesized list"; a sequence + of data items, delimited by space, and bounded at each end by + parentheses. A parenthesized list may itself contain other + parenthesized lists, using multiple levels of parentheses to indicate + nesting. + + The empty list is represented as () -- a parenthesized list with no + members. + + +4.5. NIL + + The special atom "NIL" represents the non-existence of a particular + data item that is represented as a string or parenthesized list, as + distinct from the empty string "" or the empty parenthesized list (). + + + + + + + + + + + + + + + + + + + +Crispin [Page 7] + +RFC 1730 IMAP4 December 1994 + + +5. Operational Considerations + +5.1. Mailbox Naming + + The interpretation of mailbox names is implementation-dependent. + However, the mailbox name INBOX is a special name reserved to mean + "the primary mailbox for this user on this server". If it is desired + to export hierarchical mailbox names, mailbox names must be + left-to-right hierarchical using a single character to separate + levels of hierarchy. The same hierarchy separator character is used + for all levels of hierarchy within a single name. + +5.2. Mailbox Size and Message Status Updates + + At any time, a server can send data that the client did not request. + Sometimes, such behavior is required. For example, agents other than + the server may add messages to the mailbox (e.g. new mail delivery), + change the flags of message in the mailbox (e.g. simultaneous access + to the same mailbox by multiple agents), or even remove messages from + the mailbox. A server MUST send mailbox size updates automatically + if a mailbox size change is observed during the processing of a + command. A server SHOULD send message flag updates automatically, + without requiring the client to request such updates explicitly. + Special rules exist for server notification of a client about the + removal of messages to prevent synchronization errors; see the + description of the EXPUNGE response for more details. + + Regardless of what implementation decisions a client may take on + remembering data from the server, a client implementation MUST record + mailbox size updates. It MUST NOT assume that any command after + initial mailbox selection will return the size of the mailbox. + + +5.3. Response when no Command in Progress + + Server implementations are permitted to send an untagged response + (except for EXPUNGE) while there is no command in progress. Server + implementations that send such responses MUST deal with flow control + considerations. Specifically, they must either (1) verify that the + size of the data does not exceed the underlying transport's available + window size, or (2) use non-blocking writes. + + + + + + + + + + +Crispin [Page 8] + +RFC 1730 IMAP4 December 1994 + + +5.4. Autologout Timer + + If a server has an inactivity autologout timer, that timer MUST be of + at least 30 minutes' duration. The receipt of ANY command from the + client during that interval should suffice to reset the autologout + timer. + + +5.5. Multiple Commands in Progress + + The client is not required to wait for the completion result response + of a command before sending another command, subject to flow control + constraints on the underlying data stream. Similarly, a server is + not required to process a command to completion before beginning + processing of the next command, unless an ambiguity would result + because of a command that would affect the results of other commands. + If there is such an ambiguity, the server executes commands to + completion in the order given by the client. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Crispin [Page 9] + +RFC 1730 IMAP4 December 1994 + + +6. Client Commands + + IMAP4 commands are described in this section. Commands are organized + by the state in which the command is permitted. Commands which are + permitted in multiple states are listed in the minimum permitted + state (for example, commands valid in authenticated and selected + state are listed in the authenticated state commands). + + Command arguments, identified by "Arguments:" in the command + descriptions below, are described by function, not by syntax. The + precise syntax of command arguments is described in the Formal Syntax + section. + + Some commands cause specific server data to be returned; these are + identified by "Data:" in the command descriptions below. See the + response descriptions in the Responses section for information on + these responses, and the Formal Syntax section for the precise syntax + of these responses. It is possible for server data to be transmitted + as a result of any command; thus, commands that do not specifically + require server data specify "no specific data for this command" + instead of "none". + + The "Result:" in the command description refers to the possible + tagged status responses to a command, and any special interpretation + of these status responses. + + +6.1. Client Commands - Any State + + The following commands are valid in any state: CAPABILITY, NOOP, and + LOGOUT. + +6.1.1. CAPABILITY Command + + Arguments: none + + Data: mandatory untagged response: CAPABILITY + + Result: OK - capability completed + BAD - command unknown or arguments invalid + + The CAPABILITY command requests a listing of capabilities that the + server supports. The server MUST send a single untagged + CAPABILITY response with "IMAP4" as the first listed capability + before the (tagged) OK response. This listing of capabilities is + not dependent upon connection state or user. It is therefore not + necessary to issue a CAPABILITY command more than once in a + session. + + + +Crispin [Page 10] + +RFC 1730 IMAP4 December 1994 + + + Capability names other than "IMAP4" refer to extensions, + revisions, or amendments to this specification. See the + documentation of the CAPABILITY response for additional + information. No capabilities are enabled without explicit client + action to invoke the capability. See the section entitled "Client + Commands - Experimental/Expansion" for information about the form + of site or implementation-specific capabilities. + + Example: C: abcd CAPABILITY + S: * CAPABILITY IMAP4 + S: abcd OK CAPABILITY completed + + +6.1.2. NOOP Command + + Arguments: none + + Data: no specific data for this command (but see below) + + Result: OK - noop completed + BAD - command unknown or arguments invalid + + The NOOP command always succeeds. It does nothing. + + Since any command can return a status update as untagged data, the + NOOP command can be used as a periodic poll for new messages or + message status updates during a period of inactivity. The NOOP + command can also be used to reset any inactivity autologout timer + on the server. + + Example: C: a002 NOOP + S: a002 OK NOOP completed + . . . + C: a047 NOOP + S: * 22 EXPUNGE + S: * 23 EXISTS + S: * 3 RECENT + S: * 14 FETCH (FLAGS (\Seen \Deleted)) + S: a047 OK NOOP completed + + + + + + + + + + + + +Crispin [Page 11] + +RFC 1730 IMAP4 December 1994 + + +6.1.3. LOGOUT Command + + Arguments: none + + Data: mandatory untagged response: BYE + + Result: OK - logout completed + BAD - command unknown or arguments invalid + + The LOGOUT command informs the server that the client is done with + the session. The server must send a BYE untagged response before + the (tagged) OK response, and then close the network connection. + + Example: C: A023 LOGOUT + S: * BYE IMAP4 Server logging out + S: A023 OK LOGOUT completed + (Server and client then close the connection) + + + +6.2. Client Commands - Non-Authenticated State + + In non-authenticated state, the AUTHENTICATE or LOGIN command + establishes authentication and enter authenticated state. The + AUTHENTICATE command provides a general mechanism for a variety of + authentication techniques, whereas the LOGIN command uses the + traditional user name and plaintext password pair. + + Server implementations may allow non-authenticated access to certain + mailboxes. The convention is to use a LOGIN command with the userid + "anonymous". A password is required. It is implementation-dependent + what requirements, if any, are placed on the password and what access + restrictions are placed on anonymous users. + + Once authenticated (including as anonymous), it is not possible to + re-enter non-authenticated state. + + In addition to the universal commands (CAPABILITY, NOOP, and LOGOUT), + the following commands are valid in non-authenticated state: + AUTHENTICATE and LOGIN. + + + + + + + + + + + +Crispin [Page 12] + +RFC 1730 IMAP4 December 1994 + + +6.2.1. AUTHENTICATE Command + + Arguments: authentication mechanism name + + Data: continuation data may be requested + + Result: OK - authenticate completed, now in authenticated state + NO - authenticate failure: unsupported authentication + mechanism, credentials rejected + BAD - command unknown or arguments invalid, + authentication exchange cancelled + + The AUTHENTICATE command indicates an authentication mechanism, + such as described in [IMAP-AUTH], to the server. If the server + supports the requested authentication mechanism, it performs an + authentication protocol exchange to authenticate and identify the + user. Optionally, it also negotiates a protection mechanism for + subsequent protocol interactions. If the requested authentication + mechanism is not supported, the server should reject the + AUTHENTICATE command by sending a tagged NO response. + + The authentication protocol exchange consists of a series of + server challenges and client answers that are specific to the + authentication mechanism. A server challenge consists of a + command continuation request response with the "+" token followed + by a BASE64 encoded string. The client answer consists of a line + consisting of a BASE64 encoded string. If the client wishes to + cancel an authentication exchange, it should issue a line with a + single "*". If the server receives such an answer, it must reject + the AUTHENTICATE command by sending a tagged BAD response. + + A protection mechanism provides integrity and privacy protection + to the protocol session. If a protection mechanism is negotiated, + it is applied to all subsequent data sent over the connection. + The protection mechanism takes effect immediately following the + CRLF that concludes the authentication exchange for the client, + and the CRLF of the tagged OK response for the server. Once the + protection mechanism is in effect, the stream of command and + response octets is processed into buffers of ciphertext. Each + buffer is transferred over the connection as a stream of octets + prepended with a four octet field in network byte order that + represents the length of the following data. The maximum + ciphertext buffer length is defined by the protection mechanism. + + The server is not required to support any particular + authentication mechanism, nor are authentication mechanisms + required to support any protection mechanisms. If an AUTHENTICATE + command fails with a NO response, the client may try another + + + +Crispin [Page 13] + +RFC 1730 IMAP4 December 1994 + + + authentication mechanism by issuing another AUTHENTICATE command, + or may attempt to authenticate by using the LOGIN command. In + other words, the client may request authentication types in + decreasing order of preference, with the LOGIN command as a last + resort. + + Example: S: * OK KerberosV4 IMAP4 Server + C: A001 AUTHENTICATE KERBEROS_V4 + S: + AmFYig== + C: BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/IJmrMG+25a4DT + +nZImJjnTNHJUtxAA+o0KPKfHEcAFs9a3CL5Oebe/ydHJUwYFd + WwuQ1MWiy6IesKvjL5rL9WjXUb9MwT9bpObYLGOKi1Qh + S: + or//EoAADZI= + C: DiAF5A4gA+oOIALuBkAAmw== + S: A001 OK Kerberos V4 authentication successful + + Note: the line breaks in the first client answer are for + editorial clarity and are not in real authenticators. + + +6.2.2. LOGIN Command + + Arguments: user name + password + + Data: no specific data for this command + + Result: OK - login completed, now in authenticated state + NO - login failure: user name or password rejected + BAD - command unknown or arguments invalid + + The LOGIN command identifies the user to the server and carries + the plaintext password authenticating this user. + + Example: C: a001 LOGIN SMITH SESAME + S: a001 OK LOGIN completed + + + +6.3. Client Commands - Authenticated State + + In authenticated state, commands that manipulate mailboxes as atomic + entities are permitted. Of these commands, the SELECT and EXAMINE + commands will select a mailbox for access and enter selected state. + + + + + + + +Crispin [Page 14] + +RFC 1730 IMAP4 December 1994 + + + In addition to the universal commands (CAPABILITY, NOOP, and LOGOUT), + the following commands are valid in authenticated state: SELECT, + EXAMINE, CREATE, DELETE, RENAME, SUBSCRIBE, UNSUBSCRIBE, LIST, LSUB, + and APPEND. + +6.3.1. SELECT Command + + Arguments: mailbox name + + Data: mandatory untagged responses: FLAGS, EXISTS, RECENT + optional OK untagged responses: UNSEEN, PERMANENTFLAGS + + Result: OK - select completed, now in selected state + NO - select failure, now in authenticated state: no + such mailbox, can't access mailbox + BAD - command unknown or arguments invalid + + The SELECT command selects a mailbox so that messages in the + mailbox can be accessed. Before returning an OK to the client, + the server MUST send the following untagged data to the client: + + FLAGS Defined flags in the mailbox + + EXISTS The number of messages in the mailbox + + RECENT The number of messages added to the mailbox since + the previous time this mailbox was read + + OK [UIDVALIDITY ] + The unique identifier validity value. See the + description of the UID command for more detail. + + to define the initial state of the mailbox at the client. If it + is not possible to determine the messages that were added since + the previous time a mailbox was read, then all messages SHOULD be + considered recent. + + The server SHOULD also send an UNSEEN response code in an OK + untagged response, indicating the message sequence number of the + first unseen message in the mailbox. + + If the client can not change the permanent state of one or more of + the flags listed in the FLAGS untagged response, the server SHOULD + send a PERMANENTFLAGS response code in an OK untagged response, + listing the flags that the client may change permanently. + + Only one mailbox may be selected at a time in a session; + simultaneous access to multiple mailboxes requires multiple + + + +Crispin [Page 15] + +RFC 1730 IMAP4 December 1994 + + + sessions. The SELECT command automatically deselects any + currently selected mailbox before attempting the new selection. + Consequently, if a mailbox is selected and a SELECT command that + fails is attempted, no mailbox is selected. + + If the user is permitted to modify the mailbox, the server SHOULD + prefix the text of the tagged OK response with the "[READ-WRITE]" + response code. + + If the user is not permitted to modify the mailbox but is + permitted read access, the mailbox is selected as read-only, and + the server MUST prefix the text of the tagged OK response to + SELECT with the "[READ-ONLY]" response code. Read-only access + through SELECT differs from the EXAMINE command in that certain + read-only mailboxes may permit the change of permanent state on a + per-user (as opposed to global) basis. Netnews messages marked in + a user's .newsrc file are an example of such per-user permanent + state that can be modified with read-only mailboxes. + + Example: C: A142 SELECT INBOX + S: * 172 EXISTS + S: * 1 RECENT + S: * OK [UNSEEN 12] Message 12 is first unseen + S: * OK [UIDVALIDITY 3857529045] UIDs valid + S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) + S: * OK [PERMANENTFLAGS (\Deleted \Seen \*)] Limited + S: A142 OK [READ-WRITE] SELECT completed + + +6.3.2. EXAMINE Command + + Arguments: mailbox name + + Data: mandatory untagged responses: FLAGS, EXISTS, RECENT + optional OK untagged responses: UNSEEN, PERMANENTFLAGS + + Result: OK - examine completed, now in selected state + NO - examine failure, now in authenticated state: no + such mailbox, can't access mailbox + BAD - command unknown or arguments invalid + + The EXAMINE command is identical to SELECT and returns the same + output; however, the selected mailbox is identified as read-only. + No changes to the permanent state of the mailbox, including + per-user state, are permitted. + + + + + + +Crispin [Page 16] + +RFC 1730 IMAP4 December 1994 + + + The text of the tagged OK response to the EXAMINE command MUST + begin with the "[READ-ONLY]" response code. + + Example: C: A932 EXAMINE blurdybloop + S: * 17 EXISTS + S: * 2 RECENT + S: * OK [UNSEEN 8] Message 8 is first unseen + S: * OK [UIDVALIDITY 3857529045] UIDs valid + S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) + S: * OK [PERMANENTFLAGS ()] No permanent flags permitted + S: A932 OK [READ-ONLY] EXAMINE completed + + +6.3.3. CREATE Command + + Arguments: mailbox name + + Data: no specific data for this command + + Result: OK - create completed + NO - create failure: can't create mailbox with that name + BAD - command unknown or arguments invalid + + The CREATE command creates a mailbox with the given name. An OK + response is returned only if a new mailbox with that name has been + created. It is an error to attempt to create INBOX or a mailbox + with a name that refers to an extant mailbox. Any error in + creation will return a tagged NO response. + + If the mailbox name is suffixed with the server's hierarchy + separator character (as returned from the server by a LIST + command), this is a declaration that the client may, in the + future, create mailbox names under this name in the hierarchy. + Server implementations that do not require this declaration MUST + ignore it. + + If a new mailbox is created with the same name as a mailbox which + was deleted, its unique identifiers MUST be greater than any + unique identifiers used in the previous incarnation of the mailbox + UNLESS the new incarnation has a different unique identifier + validity value. See the description of the UID command for more + detail. + + Example: C: A003 CREATE owatagusiam/ + S: A003 OK CREATE completed + C: A004 CREATE owatagusiam/blurdybloop + S: A004 OK CREATE completed + + + + +Crispin [Page 17] + +RFC 1730 IMAP4 December 1994 + + + Note: the interpretation of this example depends on whether + "/" was returned as the hierarchy separator from LIST. If + "/" is the hierarchy separator, a new level of hierarchy + named "owatagusiam" with a member called "blurdybloop" is + created. Otherwise, two mailboxes at the same hierarchy + level are created. + + +6.3.4. DELETE Command + + Arguments: mailbox name + + Data: no specific data for this command + + Result: OK - delete completed + NO - delete failure: can't delete mailbox with that name + BAD - command unknown or arguments invalid + + The DELETE command permanently removes the mailbox with the given + name. A tagged OK response is returned only if the mailbox has + been deleted. It is an error to attempt to delete INBOX or a + mailbox name that does not exist. Any error in deletion will + return a tagged NO response. + + The value of the highest-used unique indentifier of the deleted + mailbox MUST be preserved so that a new mailbox created with the + same name will not reuse the identifiers of the former + incarnation, UNLESS the new incarnation has a different unique + identifier validity value. See the description of the UID command + for more detail. + + Example: C: A683 DELETE blurdybloop + S: A683 OK DELETE completed + + +6.3.5. RENAME Command + + Arguments: existing mailbox name + new mailbox name + + Data: no specific data for this command + + Result: OK - rename completed + NO - rename failure: can't rename mailbox with that name, + can't rename to mailbox with that name + BAD - command unknown or arguments invalid + + + + + +Crispin [Page 18] + +RFC 1730 IMAP4 December 1994 + + + The RENAME command changes the name of a mailbox. A tagged OK + response is returned only if the mailbox has been renamed. It is + an error to attempt to rename from a mailbox name that does not + exist or to a mailbox name that already exists. Any error in + renaming will return a tagged NO response. + + Renaming INBOX is permitted; a new, empty INBOX is created in its + place. + + Example: C: Z4S9 RENAME blurdybloop owatagusiam + S: Z4S9 OK RENAME completed + + +6.3.6. SUBSCRIBE Command + + Arguments: mailbox + + Data: no specific data for this command + + Result: OK - subscribe completed + NO - subscribe failure: can't subscribe to that name + BAD - command unknown or arguments invalid + + The SUBSCRIBE command adds the specified mailbox name to the + server's set of "active" or "subscribed" mailboxes as returned by + the LSUB command. This command returns a tagged OK response only + if the subscription is successful. + + Example: C: A002 SUBSCRIBE #news.comp.mail.mime + S: A002 OK SUBSCRIBE completed + + +6.3.7. UNSUBSCRIBE Command + + Arguments: mailbox name + + Data: no specific data for this command + + Result: OK - unsubscribe completed + NO - unsubscribe failure: can't unsubscribe that name + BAD - command unknown or arguments invalid + + The UNSUBSCRIBE command removes the specified mailbox name from + the server's set of "active" or "subscribed" mailboxes as returned + by the LSUB command. This command returns a tagged OK response + only if the unsubscription is successful. + + + + + +Crispin [Page 19] + +RFC 1730 IMAP4 December 1994 + + + Example: C: A002 UNSUBSCRIBE #news.comp.mail.mime + S: A002 OK UNSUBSCRIBE completed + + +6.3.8. LIST Command + + Arguments: reference name + mailbox name with possible wildcards + + Data: untagged responses: LIST + + Result: OK - list completed + NO - list failure: can't list that reference or name + BAD - command unknown or arguments invalid + + The LIST command returns a subset of names from the complete set + of all names available to the user. Zero or more untagged LIST + replies are returned, containing the name attributes, hierarchy + delimiter, and name; see the description of the LIST reply for + more detail. + + An empty ("" string) reference name argument indicates that the + mailbox name is interpreted as by SELECT. The returned mailbox + names MUST match the supplied mailbox name pattern. A non-empty + reference name argument is the name of a mailbox or a level of + mailbox hierarchy, and indicates a context in which the mailbox + name is interpreted in an implementation-defined manner. + + The reference and mailbox name arguments are interpreted, in an + implementation-dependent fashion, into a canonical form that + represents an unambiguous left-to-right hierarchy. The returned + mailbox names will be in the interpreted form. + + Any part of the reference argument that is included in the + interpreted form SHOULD prefix the interpreted form. It should + also be in the same form as the reference name argument. This + rule permits the client to determine if the returned mailbox name + is in the context of the reference argument, or if something about + the mailbox argument overrode the reference argument. Without + this rule, the client would have to have knowledge of the server's + naming semantics including what characters are "breakouts" that + override a naming context. + + + + + + + + + +Crispin [Page 20] + +RFC 1730 IMAP4 December 1994 + + + For example, here are some examples of how references + and mailbox names might be interpreted on a UNIX-based + server: + + Reference Mailbox Name Interpretation + ------------ ------------ -------------- + ~smith/Mail/ foo.* ~smith/Mail/foo.* + archive/ % archive/% + #news. comp.mail.* #news.comp.mail.* + ~smith/Mail/ /usr/doc/foo /usr/doc/foo + archive/ ~fred/Mail/* ~fred/Mail/* + + The first three examples demonstrate interpretations in + the context of the reference argument. Note that + "~smith/Mail" should not be transformed into something + like "/u2/users/smith/Mail", or it would be impossible + for the client to determine that the interpretation was + in the context of the reference. + + The character "*" is a wildcard, and matches zero or more + characters at this position. The character "%" is similar to "*", + but it does not match a hierarchy delimiter. If the "%" wildcard + is the last character of a mailbox name argument, matching levels + of hierarchy are also returned. If these levels of hierarchy are + not also selectable mailboxes, they are returned with the + \Noselect mailbox name attribute (see the description of the LIST + response for more detail). + + Server implementations are permitted to "hide" otherwise + accessible mailboxes from the wildcard characters, by preventing + certain characters or names from matching a wildcard in certain + situations. For example, a UNIX-based server might restrict the + interpretation of "*" so that an initial "/" character does not + match. + + The special name INBOX is included in the output from LIST if it + matches the input arguments and INBOX is supported by this server + for this user. The criteria for omitting INBOX is whether SELECT + INBOX will return failure; it is not relevant whether the user's + real INBOX resides on this or some other server. + + Example: C: A002 LIST "~/Mail/" "%" + S: * LIST (\Noselect) "/" ~/Mail/foo + S: * LIST () "/" ~/Mail/meetings + S: A002 OK LIST completed + + + + + + +Crispin [Page 21] + +RFC 1730 IMAP4 December 1994 + + +6.3.9. LSUB Command + + Arguments: reference name + mailbox name with possible wildcards + + Data: untagged responses: LSUB + + Result: OK - lsub completed + NO - lsub failure: can't list that reference or name + BAD - command unknown or arguments invalid + + The LSUB command returns a subset of names from the set of names + that the user has declared as being "active" or "subscribed". + Zero or more untagged LSUB replies are returned. The arguments to + LSUB are in the same form as those for LIST. + + Example: C: A002 LSUB "#news." "comp.mail.*" + S: * LSUB () "." #news.comp.mail.mime + S: * LSUB () "." #news.comp.mail.misc + S: A002 OK LSUB completed + + +6.3.10. APPEND Command + + Arguments: mailbox name + optional flag parenthesized list + optional date/time string + message literal + + Data: no specific data for this command + + Result: OK - append completed + NO - append error: can't append to that mailbox, error + in flags or date/time or message text + BAD - command unknown or arguments invalid + + The APPEND command appends the literal argument as a new message + in the specified destination mailbox. This argument is in the + format of an [RFC-822] message. 8-bit characters are permitted in + the message. A server implementation that is unable to preserve + 8-bit data properly MUST be able to reversibly convert 8-bit + APPEND data to 7-bit using [MIME-1] encoding. + + If a flag parenthesized list or date_time are specified, that data + SHOULD be set in the resulting message; otherwise, the defaults of + empty flags and the current date/time are used. + + + + + +Crispin [Page 22] + +RFC 1730 IMAP4 December 1994 + + + If the append is unsuccessful for any reason, the mailbox MUST be + restored to its state before the APPEND attempt; no partial + appending is permitted. If the mailbox is currently selected, the + normal new mail actions should occur. + + If the destination mailbox does not exist, a server MUST return an + error, and MUST NOT automatically create the mailbox. Unless it + is certain that the destination mailbox can not be created, the + server MUST send the response code "[TRYCREATE]" as the prefix of + the text of the tagged NO response. This gives a hint to the + client that it can attempt a CREATE command and retry the APPEND + if the CREATE is successful. + + Example: C: A003 APPEND saved-messages (\Seen) {310} + C: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST) + C: From: Fred Foobar + C: Subject: afternoon meeting + C: To: mooch@owatagu.siam.edu + C: Message-Id: + C: MIME-Version: 1.0 + C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII + C: + C: Hello Joe, do you think we can meet at 3:30 tomorrow? + C: + S: A003 OK APPEND completed + + Note: the APPEND command is not used for message delivery, + because it does not provide a mechanism to transfer [SMTP] + envelope information. + + + +6.4. Client Commands - Selected State + + In selected state, commands that manipulate messages in a mailbox are + permitted. + + In addition to the universal commands (CAPABILITY, NOOP, and LOGOUT), + and the authenticated state commands (SELECT, EXAMINE, CREATE, + DELETE, RENAME, SUBSCRIBE, UNSUBSCRIBE, LIST, LSUB, FIND + ALL.MAILBOXES, FIND MAILBOXES, and APPEND), the following commands + are valid in the selected state: CHECK, CLOSE, EXPUNGE, SEARCH, + FETCH, PARTIAL, STORE, COPY, and UID. + + + + + + + + +Crispin [Page 23] + +RFC 1730 IMAP4 December 1994 + + +6.4.1. CHECK Command + + Arguments: none + + Data: no specific data for this command + + Result: OK - check completed + BAD - command unknown or arguments invalid + + The CHECK command requests a checkpoint of the currently selected + mailbox. A checkpoint refers to any implementation-dependent + housekeeping associated with the mailbox (e.g. resolving the + server's in-memory state of the mailbox with the state on its + disk) that is not normally executed as part of each command. A + checkpoint may take a non-instantaneous amount of real time to + complete. If a server implementation has no such housekeeping + considerations, CHECK is equivalent to NOOP. + + There is no guarantee that an EXISTS untagged response will happen + as a result of CHECK. NOOP, not CHECK, should be used for new + mail polling. + + Example: C: FXXZ CHECK + S: FXXZ OK CHECK Completed + + +6.4.2. CLOSE Command + + Arguments: none + + Data: no specific data for this command + + Result: OK - close completed, now in authenticated state + NO - close failure: no mailbox selected + BAD - command unknown or arguments invalid + + The CLOSE command permanently removes from the currently selected + mailbox all messages that have the \Deleted flag set, and returns + to authenticated state from selected state. No untagged EXPUNGE + responses are sent. + + No messages are removed, and no error is given, if the mailbox is + selected by an EXAMINE command or is otherwise selected read-only. + + Even when a mailbox is selected, it is not required to send a + CLOSE command before a SELECT, EXAMINE, or LOGOUT command. The + SELECT, EXAMINE, and LOGOUT commands implicitly close the + currently selected mailbox without doing an expunge. However, + + + +Crispin [Page 24] + +RFC 1730 IMAP4 December 1994 + + + when many messages are deleted, a CLOSE-LOGOUT or CLOSE-SELECT + sequence is considerably faster than an EXPUNGE-LOGOUT or + EXPUNGE-SELECT because no untagged EXPUNGE responses (which the + client would probably ignore) are sent. + + Example: C: A341 CLOSE + S: A341 OK CLOSE completed + + +6.4.3. EXPUNGE Command + + Arguments: none + + Data: untagged responses: EXPUNGE + + Result: OK - expunge completed + NO - expunge failure: can't expunge (e.g. permission + denied) + BAD - command unknown or arguments invalid + + The EXPUNGE command permanently removes from the currently + selected mailbox all messages that have the \Deleted flag set. + Before returning an OK to the client, an untagged EXPUNGE response + is sent for each message that is removed. + + Example: C: A202 EXPUNGE + S: * 3 EXPUNGE + S: * 3 EXPUNGE + S: * 5 EXPUNGE + S: * 8 EXPUNGE + S: A202 OK EXPUNGE completed + + Note: in this example, messages 3, 4, 7, and 11 had the + \Deleted flag set. See the description of the EXPUNGE + response for further explanation. + + + + + + + + + + + + + + + + +Crispin [Page 25] + +RFC 1730 IMAP4 December 1994 + + +6.4.4. SEARCH Command + + Arguments: optional character set specification + searching criteria (one or more) + + Data: mandatory untagged response: SEARCH + + Result: OK - search completed + NO - search error: can't search that character set or + criteria + BAD - command unknown or arguments invalid + + The SEARCH command searches the mailbox for messages that match + the given searching criteria. Searching criteria consist of one + or more search keys. The untagged SEARCH response from the server + contains a listing of message sequence numbers corresponding to + those messages that match the searching criteria. + + When multiple keys are specified, the result is the intersection + (AND function) of all the messages that match those keys. For + example, the criteria DELETED FROM "SMITH" SINCE 1-Feb-1994 refers + to all deleted messages from Smith that were placed in the mailbox + since February 1, 1994. A search key may also be a parenthesized + list of one or more search keys (e.g. for use with the OR and NOT + keys). + + Server implementations MAY exclude [MIME-1] body parts with + terminal content types other than TEXT and MESSAGE from + consideration in SEARCH matching. + + The optional character set specification consists of the word + "CHARSET" followed by a registered MIME character set. It + indicates the character set of the strings that appear in the + search criteria. [MIME-2] strings that appear in RFC 822/MIME + message headers, and [MIME-1] content transfer encodings, MUST be + decoded before matching. Except for US-ASCII, it is not required + that any particular character set be supported. If the server + does not support the specified character set, it MUST return a + tagged NO response (not a BAD). + + In all search keys that use strings, a message matches the key if + the string is a substring of the field. The matching is + case-insensitive. + + + + + + + + +Crispin [Page 26] + +RFC 1730 IMAP4 December 1994 + + + The defined search keys are as follows. Refer to the Formal + Syntax section for the precise syntactic definitions of the + arguments. + + Messages with message sequence numbers + corresponding to the specified message sequence + number set + + ALL All messages in the mailbox; the default initial + key for ANDing. + + ANSWERED Messages with the \Answered flag set. + + BCC Messages that contain the specified string in the + envelope structure's BCC field. + + BEFORE Messages whose internal date is earlier than the + specified date. + + BODY Messages that contain the specified string in the + body of the message. + + CC Messages that contain the specified string in the + envelope structure's CC field. + + DELETED Messages with the \Deleted flag set. + + DRAFT Messages with the \Draft flag set. + + FLAGGED Messages with the \Flagged flag set. + + FROM Messages that contain the specified string in the + envelope structure's FROM field. + + HEADER + Messages that have a header with the specified + field-name (as defined in [RFC-822]) and that + contains the specified string in the [RFC-822] + field-body. + + KEYWORD Messages with the specified keyword set. + + LARGER Messages with an RFC822.SIZE larger than the + specified number of octets. + + NEW Messages that have the \Recent flag set but not the + \Seen flag. This is functionally equivalent to + "(RECENT UNSEEN)". + + + +Crispin [Page 27] + +RFC 1730 IMAP4 December 1994 + + + NOT + Messages that do not match the specified search + key. + + OLD Messages that do not have the \Recent flag set. + This is functionally equivalent to "NOT RECENT" (as + opposed to "NOT NEW"). + + ON Messages whose internal date is within the + specified date. + + OR + Messages that match either search key. + + RECENT Messages that have the \Recent flag set. + + SEEN Messages that have the \Seen flag set. + + SENTBEFORE + Messages whose [RFC-822] Date: header is earlier + than the specified date. + + SENTON Messages whose [RFC-822] Date: header is within the + specified date. + + SENTSINCE + Messages whose [RFC-822] Date: header is within or + later than the specified date. + + SINCE Messages whose internal date is within or later + than the specified date. + + SMALLER Messages with an RFC822.SIZE smaller than the + specified number of octets. + + SUBJECT + Messages that contain the specified string in the + envelope structure's SUBJECT field. + + TEXT Messages that contain the specified string in the + header or body of the message. + + TO Messages that contain the specified string in the + envelope structure's TO field. + + UID + Messages with unique identifiers corresponding to + the specified unique identifier set. + + + +Crispin [Page 28] + +RFC 1730 IMAP4 December 1994 + + + UNANSWERED Messages that do not have the \Answered flag set. + + UNDELETED Messages that do not have the \Deleted flag set. + + UNDRAFT Messages that do not have the \Draft flag set. + + UNFLAGGED Messages that do not have the \Flagged flag set. + + UNKEYWORD + Messages that do not have the specified keyword + set. + + UNSEEN Messages that do not have the \Seen flag set. + + + Example: C: A282 SEARCH FLAGGED SINCE 1-Feb-1994 NOT FROM "Smith" + S: * SEARCH 2 84 882 + S: A282 OK SEARCH completed + + +6.4.5. FETCH Command + + Arguments: message set + message data item names + + Data: untagged responses: FETCH + + Result: OK - fetch completed + NO - fetch error: can't fetch that data + BAD - command unknown or arguments invalid + + The FETCH command retrieves data associated with a message in the + mailbox. The data items to be fetched may be either a single atom + or a parenthesized list. The currently defined data items that + can be fetched are: + + ALL Macro equivalent to: (FLAGS INTERNALDATE + RFC822.SIZE ENVELOPE) + + BODY Non-extensible form of BODYSTRUCTURE. + + BODY[
] + The text of a particular body section. The section + specification is a set of one or more part numbers + delimited by periods. + + Single-part messages only have a part 1. + + + + +Crispin [Page 29] + +RFC 1730 IMAP4 December 1994 + + + Multipart messages are assigned consecutive part + numbers, as they occur in the message. If a + particular part is of type message or multipart, + its parts must be indicated by a period followed by + the part number within that nested multipart part. + It is not permitted to fetch a multipart part + itself, only its individual members. + + A part of type MESSAGE and subtype RFC822 also has + nested parts. These are the parts of the MESSAGE + part's body. Nested part 0 of a part of type + MESSAGE and subtype RFC822 is the [RFC-822] header + of the message. + + Every message has at least one part. + + Here is an example of a complex message + with its associated section + specifications: + + 0 ([RFC-822] header of the message) + MULTIPART/MIXED + 1 TEXT/PLAIN + 2 APPLICATION/OCTET-STREAM + 3 MESSAGE/RFC822 + 3.0 ([RFC-822] header of the message) + 3.1 TEXT/PLAIN + 3.2 APPLICATION/OCTET-STREAM + MULTIPART/MIXED + 4.1 IMAGE/GIF + 4.2 MESSAGE/RFC822 + 4.2.0 ([RFC-822] header of the message) + 4.2.1 TEXT/PLAIN + MULTIPART/ALTERNATIVE + 4.2.2.1 TEXT/PLAIN + 4.2.2.2 TEXT/RICHTEXT + + Note that there is no section + specification for the Multi-part parts + (no section 4 or 4.2.2). + + The \Seen flag is implicitly set; if this causes + the flags to change they should be included as part + of the fetch responses. + + BODY.PEEK[
] + An alternate form of BODY[section] that does not + implicitly set the \Seen flag. + + + +Crispin [Page 30] + +RFC 1730 IMAP4 December 1994 + + + BODYSTRUCTURE The [MIME-1] body structure of the message. This + is computed by the server by parsing the [MIME-1] + header lines. + + ENVELOPE The envelope structure of the message. This is + computed by the server by parsing the [RFC-822] + header into the component parts, defaulting various + fields as necessary. + + FAST Macro equivalent to: (FLAGS INTERNALDATE + RFC822.SIZE) + + FLAGS The flags that are set for this message. + + FULL Macro equivalent to: (FLAGS INTERNALDATE + RFC822.SIZE ENVELOPE BODY) + + INTERNALDATE The date and time of final delivery of the message + as defined by RFC 821. + + RFC822 The message in [RFC-822] format. The \Seen flag is + implicitly set; if this causes the flags to change + they should be included as part of the fetch + responses. This is the concatenation of + RFC822.HEADER and RFC822.TEXT. + + RFC822.PEEK An alternate form of RFC822 that does not + implicitly set the \Seen flag. + + RFC822.HEADER The [RFC-822] format header of the message as + stored on the server including the delimiting blank + line between the header and the body. + + RFC822.HEADER.LINES + All header lines (including continuation lines) of + the [RFC-822] format header of the message with a + field-name (as defined in [RFC-822]) that matches + any of the strings in header_list. The matching is + case-insensitive but otherwise exact. The + delimiting blank line between the header and the + body is always included. + + + + + + + + + + +Crispin [Page 31] + +RFC 1730 IMAP4 December 1994 + + + RFC822.HEADER.LINES.NOT + All header lines (including continuation lines) of + the [RFC-822] format header of the message with a + field-name (as defined in [RFC-822]) that does not + match any of the strings in header_list. The + matching is case-insensitive but otherwise exact. + The delimiting blank line between the header and + the body is always included. + + RFC822.SIZE The number of octets in the message, as expressed + in [RFC-822] format. + + RFC822.TEXT The text body of the message, omitting the + [RFC-822] header. The \Seen flag is implicitly + set; if this causes the flags to change they should + be included as part of the fetch responses. + + RFC822.TEXT.PEEK + An alternate form of RFC822.TEXT that does not + implicitly set the \Seen flag. + + UID The unique identifier for the message. + + + Example: C: A654 FETCH 2:4 (FLAGS RFC822.HEADER.LINES (DATE FROM)) + S: * 2 FETCH .... + S: * 3 FETCH .... + S: * 4 FETCH .... + S: A003 OK FETCH completed + + +6.4.6. PARTIAL Command + + Arguments: message sequence number + message data item name + position of first octet + number of octets + + Data: untagged responses: FETCH + + Result: OK - partial completed + NO - partial error: can't fetch that data + BAD - command unknown or arguments invalid + + The PARTIAL command is equivalent to the associated FETCH command, + with the added functionality that only the specified number of + octets, beginning at the specified starting octet, are returned. + Only a single message can be fetched at a time. The first octet + + + +Crispin [Page 32] + +RFC 1730 IMAP4 December 1994 + + + of a message, and hence the minimum for the starting octet, is + octet 1. + + The following FETCH items are valid data for PARTIAL: RFC822, + RFC822.HEADER, RFC822.TEXT, BODY[section], as well as any .PEEK + forms of these. + + Any partial fetch that attempts to read beyond the end of the text + is truncated as appropriate. If the starting octet is beyond the + end of the text, an empty string is returned. + + The data are returned with the FETCH response. There is no + indication of the range of the partial data in this response. It + is not possible to stream multiple PARTIAL commands of the same + data item without processing and synchronizing at each step, since + streamed commands may be executed out of order. + + There is no requirement that partial fetches follow any sequence. + For example, if a partial fetch of octets 1 through 10000 breaks + in an awkward place for BASE64 decoding, it is permitted to + continue with a partial fetch of 9987 through 19987, etc. + + The handling of the \Seen flag is the same as in the associated + FETCH command. + + Example: C: A005 PARTIAL 4 RFC822 1 1024 + S: * 1 FETCH (RFC822 {1024} + S: Return-Path: + S: ... + S: ......... FLAGS (\Seen)) + S: A005 OK PARTIAL completed + + +6.4.7. STORE Command + + Arguments: message set + message data item name + value for message data item + + Data: untagged responses: FETCH + + Result: OK - store completed + NO - store error: can't store that data + BAD - command unknown or arguments invalid + + The STORE command alters data associated with a message in the + mailbox. Normally, STORE will return the updated value of the + data with an untagged FETCH response. A suffix of ".SILENT" in + + + +Crispin [Page 33] + +RFC 1730 IMAP4 December 1994 + + + the data item name prevents the untagged FETCH, and the server + should assume that the client has determined the updated value + itself or does not care about the updated value. + + The currently defined data items that can be stored are: + + FLAGS + Replace the flags for the message with the + argument. The new value of the flags are returned + as if a FETCH of those flags was done. + + FLAGS.SILENT + Equivalent to FLAGS, but without returning a new + value. + + +FLAGS + Add the argument to the flags for the message. The + new value of the flags are returned as if a FETCH + of those flags was done. + + +FLAGS.SILENT + Equivalent to +FLAGS, but without returning a new + value. + + -FLAGS + Remove the argument from the flags for the message. + The new value of the flags are returned as if a + FETCH of those flags was done. + + -FLAGS.SILENT + Equivalent to -FLAGS, but without returning a new + value. + + + Example: C: A003 STORE 2:4 +FLAGS (\Deleted) + S: * 2 FETCH FLAGS (\Deleted \Seen) + S: * 3 FETCH FLAGS (\Deleted) + S: * 4 FETCH FLAGS (\Deleted \Flagged \Seen) + S: A003 OK STORE completed + + + + + + + + + + + + +Crispin [Page 34] + +RFC 1730 IMAP4 December 1994 + + +6.4.8. COPY Command + + Arguments: message set + mailbox name + + Data: no specific data for this command + + Result: OK - copy completed + NO - copy error: can't copy those messages or to that + name + BAD - command unknown or arguments invalid + + The COPY command copies the specified message(s) to the specified + destination mailbox. The flags and internal date of the + message(s) SHOULD be preserved in the copy. + + If the destination mailbox does not exist, a server SHOULD return + an error. It SHOULD NOT automatically create the mailbox. Unless + it is certain that the destination mailbox can not be created, the + server MUST send the response code "[TRYCREATE]" as the prefix of + the text of the tagged NO response. This gives a hint to the + client that it can attempt a CREATE command and retry the COPY if + the CREATE is successful. + + If the COPY command is unsuccessful for any reason, server + implementations MUST restore the destination mailbox to its state + before the COPY attempt. + + Example: C: A003 COPY 2:4 MEETING + S: A003 OK COPY completed + + +6.4.9. UID Command + + Arguments: command name + command arguments + + Data: untagged responses: FETCH, SEARCH + + Result: OK - UID command completed + NO - UID command error + BAD - command unknown or arguments invalid + + The UID command has two forms. In the first form, it takes as its + arguments a COPY, FETCH, or STORE command with arguments + appropriate for the associated command. However, the numbers in + the message set argument are unique identifiers instead of message + sequence numbers. + + + +Crispin [Page 35] + +RFC 1730 IMAP4 December 1994 + + + In the second form, the UID command takes a SEARCH command with + SEARCH command arguments. The interpretation of the arguments is + the same as with SEARCH; however, the numbers returned in a SEARCH + response for a UID SEARCH command are unique identifiers instead + of message sequence numbers. For example, the command UID SEARCH + 1:100 UID 443:557 returns the unique identifiers corresponding to + the intersection of the message sequence number set 1:100 and the + UID set 443:557. + + A unique identifier of a message is a number, and is guaranteed + not to refer to any other message in the mailbox. Unique + identifiers are assigned in a strictly ascending fashion for each + message added to the mailbox. Unlike message sequence numbers, + unique identifiers persist across sessions. This permits a client + to resynchronize its state from a previous session with the server + (e.g. disconnected or offline access clients); this is discussed + further in [IMAP-DISC]. + + Associated with every mailbox is a unique identifier validity + value, which is sent in an UIDVALIDITY response code in an OK + untagged response at message selection time. If unique + identifiers from an earlier session fail to persist to this + session, the unique identifier validity value MUST be greater than + in the earlier session. + + Note: An example of a good value to use for the unique + identifier validity value would be a 32-bit + representation of the creation date/time of the mailbox. + It is alright to use a constant such as 1, but only if + it guaranteed that unique identifers will never be + reused, even in the case of a mailbox being deleted and + a new mailbox by the same name created at some future + time. + + + Message set ranges are permitted; however, there is no guarantee + that unique identifiers be contiguous. A non-existent unique + identifier within a message set range is ignored without any error + message generated. + + The number after the "*" in an untagged FETCH response is always a + message sequence number, not a unique identifier, even for a UID + command response. However, server implementations MUST implicitly + include the UID message data item as part of any FETCH response + caused by a UID command, regardless of whether UID was specified + as a message data item to the FETCH. + + + + + +Crispin [Page 36] + +RFC 1730 IMAP4 December 1994 + + + Example: C: A003 UID FETCH 4827313:4828442 FLAGS + S: * 23 FETCH (FLAGS (\Seen) UID 4827313) + S: * 24 FETCH (FLAGS (\Seen) UID 4827943) + S: * 25 FETCH (FLAGS (\Seen) UID 4828442) + S: A999 UID FETCH completed + + + +6.5. Client Commands - Experimental/Expansion + + +6.5.1. X Command + + Arguments: implementation defined + + Data: implementation defined + + Result: OK - command completed + NO - failure + BAD - command unknown or arguments invalid + + Any command prefixed with an X is an experimental command. + Commands which are not part of this specification, or a standard + or standards-track revision of this specification, MUST use the X + prefix. + + Any added untagged responses issued by an experimental command + MUST also be prefixed with an X. Server implementations MUST NOT + send any such untagged responses, unless the client requested it + by issuing the associated experimental command. + + Example: C: a441 CAPABILITY + S: * CAPABILITY IMAP4 XPIG-LATIN + S: a441 OK CAPABILITY completed + C: A442 XPIG-LATIN + S: * XPIG-LATIN ow-nay eaking-spay ig-pay atin-lay + S: A442 OK XPIG-LATIN ompleted-cay + + + + + + + + + + + + + + +Crispin [Page 37] + +RFC 1730 IMAP4 December 1994 + + +7. Server Responses + + Server responses are in three forms: status responses, server data, + and command continuation request. + + Server response data, identified by "Data:" in the response + descriptions below, are described by function, not by syntax. The + precise syntax of server response data is described in the Formal + Syntax section. + + The client MUST be prepared to accept any response at all times. + + Status responses that are tagged indicate the completion result of a + client command, and have a tag matching the command. + + Some status responses, and all server data, are untagged. An + untagged response is indicated by the token "*" instead of a tag. + Untagged status responses indicate server greeting, or server status + that does not indicate the completion of a command. For historical + reasons, untagged server data responses are also called "unsolicited + data", although strictly speaking only unilateral server data is + truly "unsolicited". + + Certain server data MUST be recorded by the client when it is + received; this is noted in the description of that data. Such data + conveys critical information which affects the interpretation of all + subsequent commands and responses (e.g. updates reflecting the + creation or destruction of messags). + + Other server data SHOULD be recorded for later reference; if the + client does not need to record the data, or if recording the data has + no obvious purpose (e.g. a SEARCH response when no SEARCH command is + in progress), the data SHOULD be ignored. + + An example of unilateral untagged responses occurs when the IMAP + connection is in selected state. In selected state, the server + checks the mailbox for new messages as part of the execution of each + command. If new messages are found, the server sends untagged EXISTS + and RECENT responses reflecting the new size of the mailbox. Server + implementations that offer multiple simultaneous access to the same + mailbox should also send appropriate unilateral untagged FETCH and + EXPUNGE responses if another agent changes the state of any message + flags or expunges any messages. + + Command continuation request responses use the token "+" instead of a + tag. These responses are sent by the server to indicate acceptance + of an incomplete client command and readiness for the remainder of + the command. + + + +Crispin [Page 38] + +RFC 1730 IMAP4 December 1994 + + +7.1. Server Responses - Status Responses + + Status responses may include an optional response code. A response + code consists of data inside square brackets in the form of an atom, + possibly followed by a space and arguments. The response code + contains additional information or status codes for client software + beyond the OK/NO/BAD condition, and are defined when there is a + specific action that a client can take based upon the additional + information. + + The currently defined response codes are: + + ALERT The human-readable text contains a special alert + that MUST be presented to the user in a fashion + that calls the user's attention to the message. + + PARSE The human-readable text represents an error in + parsing the [RFC-822] or [MIME-1] headers of a + message in the mailbox. + + PERMANENTFLAGS Followed by a parenthesized list of flags, + indicates which of the known flags that the client + may change permanently. Any flags that are in the + FLAGS untagged response, but not the PERMANENTFLAGS + list, can not be set permanently. If the client + attempts to STORE a flag that is not in the + PERMANENTFLAGS list, the server will either reject + it with a NO reply or store the state for the + remainder of the current session only. The + PERMANENTFLAGS list may also include the special + flag \*, which indicates that it is possible to + create new keywords by attempting to store those + flags in the mailbox. + + READ-ONLY The mailbox is selected read-only, or its access + while selected has changed from read-write to + read-only. + + READ-WRITE The mailbox is selected read-write, or its access + while selected has changed from read-only to + read-write. + + TRYCREATE An APPEND or COPY attempt is failing because the + target mailbox does not exist (as opposed to some + other reason). This is a hint to the client that + the operation may succeed if the mailbox is first + created by the CREATE command. + + + + +Crispin [Page 39] + +RFC 1730 IMAP4 December 1994 + + + UIDVALIDITY Followed by a decimal number, indicates the unique + identifier validity value. See the description of + the UID command for more detail. + + UNSEEN Followed by a decimal number, indicates the number + of the first message without the \Seen flag set. + + Additional response codes defined by particular client or server + implementations should be prefixed with an "X" until they are + added to a revision of this protocol. Client implementations + should ignore response codes that they do not recognize. + + +7.1.1. OK Response + + Data: optional response code + human-readable text + + The OK response indicates an information message from the server. + When tagged, it indicates successful completion of the associated + command. The human-readable text may be presented to the user as + an information message. The untagged form indicates an + information-only message; the nature of the information may be + indicated by a response code. + + The untagged form is also used as one of three possible greetings + at session startup. It indicates that the session is not yet + authenticated and that a LOGIN command is needed. + + Example: S: * OK IMAP4 server ready + C: A001 LOGIN fred blurdybloop + S: * OK [ALERT] System shutdown in 10 minutes + S: A001 OK LOGIN Completed + + +7.1.2. NO Response + + Data: optional response code + human-readable text + + The NO response indicates an operational error message from the + server. When tagged, it indicates unsuccessful completion of the + associated command. The untagged form indicates a warning; the + command may still complete successfully. The human-readable text + describes the condition. + + + + + + +Crispin [Page 40] + +RFC 1730 IMAP4 December 1994 + + + Example: C: A222 COPY 1:2 owatagusiam + S: * NO Disk is 98% full, please delete unnecessary data + S: A222 OK COPY completed + C: A222 COPY 3:200 blurdybloop + S: * NO Disk is 98% full, please delete unnecessary data + S: * NO Disk is 99% full, please delete unnecessary data + S: A222 NO COPY failed: disk is full + + +7.1.3. BAD Response + + Data: optional response code + human-readable text + + The BAD response indicates an error message from the server. When + tagged, it reports a protocol-level error in the client's command; + the tag indicates the command that caused the error. The untagged + form indicates a protocol-level error for which the associated + command can not be determined; it may also indicate an internal + server failure. The human-readable text describes the condition. + + Example: C: ...very long command line... + S: * BAD Command line too long + C: ...empty line... + S: * BAD Empty command line + C: A443 EXPUNGE + S: * BAD Disk crash, attempting salvage to a new disk! + S: * OK Salvage successful, no data lost + S: A443 OK Expunge completed + + +7.1.4. PREAUTH Response + + Data: optional response code + human-readable text + + The PREAUTH response is always untagged, and is one of three + possible greetings at session startup. It indicates that the + session has already been authenticated by external means and thus + no LOGIN command is needed. + + Example: S: * PREAUTH IMAP4 server ready and logged in as Smith + + + + + + + + + +Crispin [Page 41] + +RFC 1730 IMAP4 December 1994 + + +7.1.5. BYE Response + + Data: optional response code + human-readable text + + The BYE response is always untagged, and indicates that the server + is about to close the connection. The human-readable text may be + displayed to the user in a status report by the client. The BYE + response may be sent as part of a normal logout sequence, or as a + panic shutdown announcement by the server. It is also used by + some server implementations as an announcement of an inactivity + autologout. + + This response is also used as one of three possible greetings at + session startup. It indicates that the server is not willing to + accept a session from this client. + + Example: S: * BYE Autologout; idle for too long + + + +7.2. Server Responses - Server and Mailbox Status + + These responses are always untagged. This is how server data are + transmitted from the server to the client, often as a result of a + command with the same name. + +7.2.1. CAPABILITY Response + + Data: capability listing + + The CAPABILITY response occurs as a result of a CAPABILITY + command. The capability listing contains a space-separated + listing of capability names that the server supports. The first + name in the capability listing MUST be the atom "IMAP4". + + A capability name other than IMAP4 indicates that the server + supports an extension, revision, or amendment to the IMAP4 + protocol. Server responses MUST conform to this document until + the client issues a command that uses the associated capability. + + Capability names MUST either begin with "X" or be standard or + standards-track IMAP4 extensions, revisions, or amendments + registered with IANA. A server MUST NOT offer unregistered or + non-standard capability names, unless such names are prefixed with + an "X". + + + + + +Crispin [Page 42] + +RFC 1730 IMAP4 December 1994 + + + Client implementations SHOULD NOT require any capability name + other than "IMAP4", and MUST ignore any unknown capability names. + + Example: S: * CAPABILITY IMAP4 XPIG-LATIN + + +7.2.2. LIST Response + + Data: name attributes + hierarchy delimiter + name + + The LIST response occurs as a result of a LIST command. It + returns a single name that matches the LIST specification. There + may be multiple LIST responses for a single LIST command. + + Four name attributes are defined: + + \Noinferiors It is not possible for any child levels of + hierarchy to exist under this name; no child levels + exist now and none can be created in the future. + + \Noselect It is not possible to use this name as a selectable + mailbox. + + \Marked The mailbox has been marked "interesting" by the + server; the mailbox probably contains messages that + have been added since the last time the mailbox was + selected. + + \Unmarked The mailbox does not contain any additional + messages since the last time the mailbox was + selected. + + If it is not feasible for the server to determine whether the + mailbox is "interesting" or not, or if the name is a \Noselect + name, the server should not send either \Marked or \Unmarked. + + The hierarchy delimiter is a character used to delimit levels of + hierarchy in a mailbox name. A client may use it to create child + mailboxes, and to search higher or lower levels of naming + hierarchy. All children of a top-level hierarchy node must use + the same separator character. A NIL hierarchy delimiter means + that no hierarchy exists; the name is a "flat" name. + + + + + + + +Crispin [Page 43] + +RFC 1730 IMAP4 December 1994 + + + The name represents an unambiguous left-to-right hierarchy, and + MUST be valid for use as a reference in LIST and LSUB commands. + Unless \Noselect is indicated, the name must also be valid as an + argument for commands, such as SELECT, that accept mailbox names. + + Example: S: * LIST (\Noselect) "/" ~/Mail/foo + + +7.2.3. LSUB Response + + Data: name attributes + hierarchy delimiter + name + + The LSUB response occurs as a result of an LSUB command. It + returns a single name that matches the LSUB specification. There + may be multiple LSUB responses for a single LSUB command. The + data is identical in format to the LIST response. + + Example: S: * LSUB () "." #news.comp.mail.misc + + +7.2.4. SEARCH Response + + Data: zero or more numbers + + The SEARCH response occurs as a result of a SEARCH or UID SEARCH + command. The number(s) refer to those messages that match the + search criteria. For SEARCH, these are message sequence numbers; + for UID SEARCH, these are unique identifiers. Each number is + delimited by a space. + + Example: S: * SEARCH 2 3 6 + + +7.2.5. FLAGS Response + + Data: flag parenthesized list + + The FLAGS response occurs as a result of a SELECT or EXAMINE + command. The flag parenthesized list identifies the flags (at a + minimum, the system-defined flags) that are applicable for this + mailbox. Flags other than the system flags may also exist, + depending on server implementation. + + The update from the FLAGS response MUST be recorded by the client. + + Example: S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) + + + +Crispin [Page 44] + +RFC 1730 IMAP4 December 1994 + + +7.3. Server Responses - Message Status + + These responses are always untagged. This is how message data are + transmitted from the server to the client, often as a result of a + command with the same name. Immediately following the "*" token is a + number that represents either a message sequence number or a message + count. + +7.3.1. EXISTS Response + + Data: none + + The EXISTS response reports the number of messages in the mailbox. + This response occurs as a result of a SELECT or EXAMINE command, + and if the size of the mailbox changes (e.g. new mail). + + The update from the EXISTS response MUST be recorded by the + client. + + Example: S: * 23 EXISTS + + +7.3.2. RECENT Response + + Data: none + + The RECENT response reports the number of messages that have + arrived since the previous time a SELECT command was done on this + mailbox. This response occurs as a result of a SELECT or EXAMINE + command, and if the size of the mailbox changes (e.g. new mail). + + The update from the RECENT response MUST be recorded by the + client. + + Example: S: * 5 RECENT + + +7.3.3. EXPUNGE Response + + Data: none + + The EXPUNGE response reports that the specified message sequence + number has been permanently removed from the mailbox. The message + sequence number for each successive message in the mailbox is + immediately decremented by 1, and this decrement is reflected in + message sequence numbers in subsequent responses (including other + untagged EXPUNGE responses). + + + + +Crispin [Page 45] + +RFC 1730 IMAP4 December 1994 + + + As a result of the immediate decrement rule, message sequence + numbers that appear in a set of successive EXPUNGE responses + depend upon whether the messages are removed starting from lower + numbers to higher numbers, or from higher numbers to lower + numbers. For example, if the last 5 messages in a 9-message + mailbox are expunged; a "lower to higher" server will send five + untagged EXPUNGE responses for message sequence number 5, whereas + a "higher to lower server" will send successive untagged EXPUNGE + responses for message sequence numbers 9, 8, 7, 6, and 5. + + An EXPUNGE response MUST NOT be sent when no command is in + progress; nor while responding to a FETCH, STORE, or SEARCH + command. This rule is necessary to prevent a loss of + synchronization of message sequence numbers between client and + server. + + The update from the EXPUNGE response MUST be recorded by the + client. + + Example: S: * 44 EXPUNGE + + +7.3.4. FETCH Response + + Data: message data + + The FETCH response returns data about a message to the client. + The data are pairs of data item names and their values in + parentheses. This response occurs as the result of a FETCH or + STORE command, as well as by unilateral server decision (e.g. flag + updates). + + The current data items are: + + BODY A form of BODYSTRUCTURE without extension data. + + BODY[section] A string expressing the body contents of the + specified section. The string should be + interpreted by the client according to the content + transfer encoding, body type, and subtype. + + 8-bit textual data is permitted if a character set + identifier is part of the body parameter + parenthesized list for this section. + + Non-textual data such as binary data must be + transfer encoded into a textual form such as BASE64 + prior to being sent to the client. To derive the + + + +Crispin [Page 46] + +RFC 1730 IMAP4 December 1994 + + + original binary data, the client must decode the + transfer encoded string. + + BODYSTRUCTURE A parenthesized list that describes the body + structure of a message. This is computed by the + server by parsing the [RFC-822] header and body + into the component parts, defaulting various fields + as necessary. + + Multiple parts are indicated by parenthesis + nesting. Instead of a body type as the first + element of the parenthesized list there is a nested + body. The second element of the parenthesized list + is the multipart subtype (mixed, digest, parallel, + alternative, etc.). + + Extension data follows the multipart subtype. + Extension data is never returned with the BODY + fetch, but may be returned with a BODYSTRUCTURE + fetch. Extension data, if present, must be in the + defined order. + + The extension data of a multipart body part are in + the following order: + + body parameter parenthesized list + A parenthesized list of attribute/value pairs + [e.g. (foo bar baz rag) where "bar" is the value + of "foo" and "rag" is the value of "baz"] as + defined in [MIME-1]. + + Any following extension data are not yet defined in + this version of the protocol. Such extension data + may consist of zero or more NILs, strings, numbers, + or potentially nested parenthesized lists of such + data. Client implementations that do a + BODYSTRUCTURE fetch MUST be prepared to accept such + extension data. Server implementations MUST NOT + send such extension data until it has been defined + by a revision of this protocol. + + The basic fields of a non-multipart body part are + in the following order: + + body type + A string giving the content type name as defined + in [MIME-1]. + + + + +Crispin [Page 47] + +RFC 1730 IMAP4 December 1994 + + + body subtype + A string giving the content subtype name as + defined in [MIME-1]. + + body parameter parenthesized list + A parenthesized list of attribute/value pairs + [e.g. (foo bar baz rag) where "bar" is the value + of "foo" and "rag" is the value of "baz"] as + defined in [MIME-1]. + + body id + A string giving the content id as defined in + [MIME-1]. + + body description + A string giving the content description as + defined in [MIME-1]. + + body encoding + A string giving the content transfer encoding as + defined in [MIME-1]. + + body size + A number giving the size of the body in octets. + Note that this size is the size in its transfer + encoding and not the resulting size after any + decoding. + + A body type of type MESSAGE and subtype RFC822 + contains, immediately after the basic fields, the + envelope structure, body structure, and size in + text lines of the encapsulated message. + + A body type of type TEXT contains, immediately + after the basic fields, the size of the body in + text lines. Note that this size is the size in its + transfer encoding and not the resulting size after + any decoding. + + Extension data follows the basic fields and the + type-specific fields listed above. Extension data + is never returned with the BODY fetch, but may be + returned with a BODYSTRUCTURE fetch. Extension + data, if present, must be in the defined order. + + The extension data of a non-multipart body part are + in the following order: + + + + +Crispin [Page 48] + +RFC 1730 IMAP4 December 1994 + + + body MD5 + A string giving the content MD5 value as defined + in [MIME-1]. + + Any following extension data are not yet defined in + this version of the protocol, and would be as + described above under multipart extension data. + + ENVELOPE A parenthesized list that describes the envelope + structure of a message. This is computed by the + server by parsing the [RFC-822] header into the + component parts, defaulting various fields as + necessary. + + The fields of the envelope structure are in the + following order: date, subject, from, sender, + reply-to, to, cc, bcc, in-reply-to, and message-id. + The date, subject, in-reply-to, and message-id + fields are strings. The from, sender, reply-to, + to, cc, and bcc fields are parenthesized lists of + address structures. + + An address structure is a parenthesized list that + describes an electronic mail address. The fields + of an address structure are in the following order: + personal name, [SMTP] at-domain-list (source + route), mailbox name, and host name. + + [RFC-822] group syntax is indicated by a special + form of address structure in which the host name + field is NIL. If the mailbox name field is also + NIL, this is an end of group marker (semi-colon in + RFC 822 syntax). If the mailbox name field is + non-NIL, this is a start of group marker, and the + mailbox name field holds the group name phrase. + + Any field of an envelope or address structure that + is not applicable is presented as NIL. Note that + the server must default the reply-to and sender + fields from the from field; a client is not + expected to know to do this. + + + + + + + + + + +Crispin [Page 49] + +RFC 1730 IMAP4 December 1994 + + + FLAGS A parenthesized list of flags that are set for this + message. This may include keywords as well as the + following system flags: + + \Seen Message has been read + + \Answered Message has been answered + + \Flagged Message is "flagged" for urgent/special + attention + + \Deleted Message is "deleted" for removal by + later EXPUNGE + + \Draft Message has not completed composition + (marked as a draft). + + as well as the following special flag, which may be + fetched but not stored: + + \Recent Message has arrived since the previous + time this mailbox was selected. + + INTERNALDATE A string containing the date and time of final + delivery of the message as defined by [SMTP]. + + RFC822 A string expressing the message in [RFC-822] + format. The header portion of the message must be + 7-bit. 8-bit characters are permitted only in the + non-header portion of the message only if there are + [MIME-1] data in the message that identify the + character set of the message. + + RFC822.HEADER A string expressing the [RFC-822] format header of + the message, including the delimiting blank line + between the header and the body. The entire string + must be 7-bit; 8-bit characters are not permitted + in headers. RFC822.HEADER is used to return data + for the RFC822.HEADER, RFC822.HEADER.LINES, and + RFC822.HEADER.LINES.NOT FETCH data items. Note + that a blank line is always included regardless of + header line restrictions. + + RFC822.SIZE A number expressing the number of octets in the + message in [RFC-822] format. + + + + + + +Crispin [Page 50] + +RFC 1730 IMAP4 December 1994 + + + RFC822.TEXT A string expressing the text body of the message, + omitting the [RFC-822] header. 8-bit characters + are permitted only if there are [MIME-1] data in + the message that identify the character set of the + message. + + UID A number expressing the unique identifier of the + message. + + + Example: S: * 23 FETCH (FLAGS (\Seen) RFC822.SIZE 44827) + + +7.3.5. Obsolete Responses + + In addition to the responses listed in here, client implementations + MUST accept and implement the obsolete responses described in + Appendix B. + + + +7.4. Server Responses - Command Continuation Request + + The command completion request response is indicated by a "+" token + instead of a tag. This form of response indicates that the server is + ready to accept the continuation of a command from the client. The + remainder of this response is a line of text. + + This response is used in the AUTHORIZATION command to transmit server + data to the client, and request additional client data. This + response is also used if an argument to any command is a literal. + + The client is not permitted to send the octets of the literal unless + the server indicates that it expects it. This permits the server to + process commands and reject errors on a line-by-line basis. The + remainder of the command, including the CRLF that terminates a + command, follows the octets of the literal. If there are any + additional command arguments the literal octets are followed by a + space and those arguments. + + Example: C: A001 LOGIN {11} + S: + Ready for additional command text + C: FRED FOOBAR {7} + S: + Ready for additional command text + C: fat man + S: A001 OK LOGIN completed + C: A044 BLURDYBLOOP {102856} + S: A044 BAD No such command as "BLURDYBLOOP" + + + +Crispin [Page 51] + +RFC 1730 IMAP4 December 1994 + + +8. Sample IMAP4 session + + The following is a transcript of an IMAP4 session. A long line in + this sample is broken for editorial clarity. + + S: * OK IMAP4 Service Ready + C: a001 login mrc secret + S: a001 OK LOGIN completed + C: a002 select inbox + S: * 18 EXISTS + S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) + S: * 2 RECENT + S: * OK [UNSEEN 17] Message 17 is the first unseen message + S: * OK [UIDVALIDITY 3857529045] UIDs valid + S: a002 OK [READ-WRITE] SELECT completed + C: a003 fetch 12 full + S: * 12 FETCH (FLAGS (\Seen) INTERNALDATE "14-Jul-1993 02:44:25 -0700" + RFC822.SIZE 4282 ENVELOPE ("Wed, 14 Jul 1993 02:23:25 -0700 (PDT)" + "IMAP4 WG mtg summary and minutes" + (("Terry Gray" NIL "gray" "cac.washington.edu")) + (("Terry Gray" NIL "gray" "cac.washington.edu")) + (("Terry Gray" NIL "gray" "cac.washington.edu")) + ((NIL NIL "imap" "cac.washington.edu")) + ((NIL NIL "minutes" "CNRI.Reston.VA.US") + ("John Klensin" NIL "KLENSIN" "INFOODS.MIT.EDU")) NIL NIL + "") + BODY ("TEXT" "PLAIN" ("CHARSET" "US-ASCII") NIL NIL "7BIT" 3028 92)) + S: a003 OK FETCH completed + C: a004 fetch 12 rfc822.header + S: * 12 FETCH (RFC822.HEADER {346} + S: Date: Wed, 14 Jul 1993 02:23:25 -0700 (PDT) + S: From: Terry Gray + S: Subject: IMAP4 WG mtg summary and minutes + S: To: imap@cac.washington.edu + S: cc: minutes@CNRI.Reston.VA.US, John Klensin + S: Message-Id: + S: MIME-Version: 1.0 + S: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII + S: + S: ) + S: a004 OK FETCH completed + C: a005 store 12 +flags \deleted + S: * 12 FETCH (FLAGS (\Seen \Deleted)) + S: a005 OK +FLAGS completed + C: a006 logout + S: * BYE IMAP4 server terminating connection + S: a006 OK LOGOUT completed + + + + +Crispin [Page 52] + +RFC 1730 IMAP4 December 1994 + + +9. Formal Syntax + + The following syntax specification uses the augmented Backus-Naur + Form (BNF) notation as specified in [RFC-822] with one exception; the + delimiter used with the "#" construct is a single space (SPACE) and + not a comma. + + Except as noted otherwise, all alphabetic characters are + case-insensitive. The use of upper or lower case characters to + define token strings is for editorial clarity only. Implementations + MUST accept these strings in a case-insensitive fashion. + + Syntax marked as obsolete may be encountered with implementations + written for an earlier version of this protocol (e.g. IMAP2). New + implementations SHOULD accept obsolete syntax as input, but MUST NOT + otherwise use such syntax. + + address ::= "(" addr_name SPACE addr_adl SPACE addr_mailbox + SPACE addr_host ")" + + addr_adl ::= nstring + + addr_host ::= nstring + ;; NIL indicates [RFC-822] group syntax + + addr_mailbox ::= nstring + ;; NIL indicates end of [RFC-822] group; if + ;; non-NIL and addr_host is NIL, holds + ;; [RFC-822] group name + + addr_name ::= nstring + + alpha ::= "A" / "B" / "C" / "D" / "E" / "F" / "G" / "H" / + "I" / "J" / "K" / "L" / "M" / "N" / "O" / "P" / + "Q" / "R" / "S" / "T" / "U" / "V" / "W" / "X" / + "Y" / "Z" / + "a" / "b" / "c" / "d" / "e" / "f" / "g" / "h" / + "i" / "j" / "k" / "l" / "m" / "n" / "o" / "p" / + "q" / "r" / "s" / "t" / "u" / "v" / "w" / "x" / + "y" / "z" / + ;; Case-sensitive + + append ::= "APPEND" SPACE mailbox [SPACE flag_list] + [SPACE date_time] SPACE literal + + astring ::= atom / string + + + + + +Crispin [Page 53] + +RFC 1730 IMAP4 December 1994 + + + atom ::= 1*ATOM_CHAR + + ATOM_CHAR ::= + + atom_specials ::= "(" / ")" / "{" / SPACE / CTLs / list_wildcards / + quoted_specials + + authenticate ::= "AUTHENTICATE" SPACE auth_type *(CRLF base64) + + auth_type ::= atom + + base64 ::= *(4base64_char) [base64_terminal] + + base64_char ::= alpha / digit / "+" / "/" + + base64_terminal ::= (2base64_char "==") / (3base64_char "=") + + body ::= "(" body_type_1part / body_type_mpart ")" + + body_extension ::= nstring / number / "(" 1#body_extension ")" + ;; Future expansion. Client implementations + ;; MUST accept body_extension fields. Server + ;; implementations MUST NOT generate + ;; body_extension fields except as defined by + ;; future standard or standards-track + ;; revisions of this specification. + + body_ext_1part ::= body_fld_md5 [SPACE 1#body_extension] + ;; MUST NOT be returned on non-extensible + ;; "BODY" fetch + + body_ext_mpart ::= body_fld_param [SPACE 1#body_extension]] + ;; MUST NOT be returned on non-extensible + ;; "BODY" fetch + + body_fields ::= body_fld_param SPACE body_fld_id SPACE + body_fld_desc SPACE body_fld_enc SPACE + body_fld_octets + + body_fld_desc ::= nstring + + body_fld_enc ::= (<"> ("7BIT" / "8BIT" / "BINARY" / "BASE64"/ + "QUOTED-PRINTABLE") <">) / string + + body_fld_id ::= nstring + + body_fld_lines ::= number + + + + +Crispin [Page 54] + +RFC 1730 IMAP4 December 1994 + + + body_fld_md5 ::= nstring + + body_fld_octets ::= number + + body_fld_param ::= "(" 1#(string string) ")" / nil + + body_fld_subtyp ::= string + + body_type_1part ::= (body_type_basic / body_type_msg / body_type_text) + [SPACE body_ext_1part] + + body_type_basic ::= (<"> ("APPLICATION" / "AUDIO" / "IMAGE" / + "MESSAGE" / "VIDEO") <">) / string) SPACE + body_fld_subtyp SPACE body_fields + ;; MESSAGE subtype MUST NOT be "RFC822" + + body_type_mpart ::= 1*body SPACE body_fld_subtyp + [SPACE body_ext_mpart] + + body_type_msg ::= <"> "MESSAGE" <"> SPACE <"> "RFC822" <"> SPACE + body_fields SPACE envelope SPACE body SPACE + body_fld_lines + + body_type_text ::= <"> "TEXT" <"> SPACE body_fld_subtyp SPACE + body_fields SPACE body_fld_lines + + capability ::= atom + ;; Must begin with "X" or be registered with + ;; IANA as standard or standards-track + + capability_data ::= "CAPABILITY" SPACE "IMAP4" [SPACE 1#capability] + + CHAR ::= + + CHAR8 ::= + + command ::= tag SPACE (command_any / command_auth / + command_nonauth / command_select) CRLF + ;; Modal based on state + + command_any ::= "CAPABILITY" / "LOGOUT" / "NOOP" / x_command + ;; Valid in all states + + command_auth ::= append / create / delete / examine / find / list / + lsub / rename / select / subscribe / unsubscribe / + ;; Valid only in Authenticated or Selected state + + + + +Crispin [Page 55] + +RFC 1730 IMAP4 December 1994 + + + command_nonauth ::= login / authenticate + ;; Valid only when in Non-Authenticated state + + command_select ::= "CHECK" / "CLOSE" / "EXPUNGE" / + copy / fetch / partial / store / uid / search + ;; Valid only when in Selected state + + continue_req ::= "+" SPACE (resp_text / base64) + + copy ::= "COPY" SPACE set SPACE mailbox + + CR ::= + + create ::= "CREATE" SPACE mailbox + ;; Use of INBOX gives a NO error + + CRLF ::= CR LF + + CTL ::= + + date ::= date_text / <"> date_text <"> + + date_day ::= 1*2digit + ;; Day of month + + date_day_fixed ::= (SPACE digit) / 2digit + ;; Fixed-format version of date_day + + date_month ::= "Jan" / "Feb" / "Mar" / "Apr" / "May" / "Jun" / + "Jul" / "Aug" / "Sep" / "Oct" / "Nov" / "Dec" + + date_text ::= date_day "-" date_month "-" (date_year / + date_year_old) + + date_year ::= 4digit + + date_year_old ::= 2digit + ;; OBSOLETE, (year - 1900) + + date_time ::= <"> (date_time_new / date_time_old) <"> + + date_time_new ::= date_day_fixed "-" date_month "-" date_year + SPACE time SPACE zone + + date_time_old ::= date_day_fixed "-" date_month "-" date_year_old + SPACE time "-" zone_old + ;; OBSOLETE + + + +Crispin [Page 56] + +RFC 1730 IMAP4 December 1994 + + + delete ::= "DELETE" SPACE mailbox + ;; Use of INBOX gives a NO error + + digit ::= "0" / digit_nz + + digit_nz ::= "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / + "9" + + envelope ::= "(" env_date SPACE env_subject SPACE env_from + SPACE env_sender SPACE env_reply-to SPACE env_to + SPACE env_cc SPACE env_bcc SPACE env_in-reply-to + SPACE env_message-id ")" + + env_bcc ::= "(" 1*address ")" / nil + + env_cc ::= "(" 1*address ")" / nil + + env_date ::= nstring + + env_from ::= "(" 1*address ")" / nil + + env_in-reply-to ::= nstring + + env_message-id ::= nstring + + env_reply-to ::= "(" 1*address ")" / nil + + env_sender ::= "(" 1*address ")" / nil + + env_subject ::= nstring + + env_to ::= "(" 1*address ")" / nil + + examine ::= "EXAMINE" SPACE mailbox + + fetch ::= "FETCH" SPACE set SPACE ("ALL" / "FULL" / + "FAST" / fetch_att / "(" 1#fetch_att ")") + + fetch_att ::= "BODY" / "BODYSTRUCTURE" / + "BODY" [".PEEK"] "[" section "]" / "ENVELOPE" / + "FLAGS" / "INTERNALDATE" / "UID" / + "RFC822" (([".TEXT"] [".PEEK"]) / ".SIZE" / + (".HEADER" [".LINES" [".NOT"] SPACE header_list]) + + find ::= "FIND" SPACE ["ALL."] "MAILBOXES" SPACE + list_mailbox + ;; OBSOLETE + + + + +Crispin [Page 57] + +RFC 1730 IMAP4 December 1994 + + + flag ::= "\Answered" / "\Flagged" / "\Deleted" / + "\Seen" / "\Draft" / flag_keyword / + flag_extension + + flag_extension ::= "\" atom + ;; Future expansion. Client implementations + ;; MUST accept flag_extension flags. Server + ;; implementations MUST NOT generate + ;; flag_extension flags except as defined by + ;; future standard or standards-track + ;; revisions of this specification. + + flag_keyword ::= atom + + flag_list ::= "(" #flag ")" + + greeting ::= "*" SPACE (resp_cond_auth / resp_cond_bye) CRLF + + header_line ::= astring + + header_list ::= "(" 1#header_line ")" + + LF ::= + + list ::= "LIST" SPACE mailbox SPACE list_mailbox + + list_mailbox ::= 1*(ATOM_CHAR / list_wildcards) / string + + list_wildcards ::= "%" / "*" + + literal ::= "{" number "}" CRLF *CHAR8 + ;; Number represents the number of CHAR8 octets + + login ::= "LOGIN" SPACE userid SPACE password + + lsub ::= "LSUB" SPACE mailbox SPACE list_mailbox + + mailbox ::= "INBOX" / astring + ;; INBOX is case-insensitive; other names may be + ;; case-sensitive depending on implementation. + + mailbox_data ::= "FLAGS" SPACE flag_list / + "LIST" SPACE mailbox_list / + "LSUB" SPACE mailbox_list / + "MAILBOX" SPACE text / + "SEARCH" [SPACE 1#nz_number] / + number SPACE "EXISTS" / number SPACE "RECENT" + + + + +Crispin [Page 58] + +RFC 1730 IMAP4 December 1994 + + + mailbox_list ::= "(" #("\Marked" / "\Noinferiors" / + "\Noselect" / "\Unmarked" / flag_extension) ")" + SPACE (<"> QUOTED_CHAR <"> / nil) SPACE mailbox + + message_data ::= nz_number SPACE ("EXPUNGE" / + ("FETCH" SPACE msg_fetch) / msg_obsolete) + + msg_fetch ::= "(" 1#("BODY" SPACE body / + "BODYSTRUCTURE" SPACE body / + "BODY[" section "]" SPACE nstring / + "ENVELOPE" SPACE envelope / + "FLAGS" SPACE "(" #(flag / "\Recent") ")" / + "INTERNALDATE" SPACE date_time / + "RFC822" [".HEADER" / ".TEXT"] SPACE nstring / + "RFC822.SIZE" SPACE number / + "UID" SPACE uniqueid) ")" + + msg_obsolete ::= "COPY" / ("STORE" SPACE msg_fetch) + ;; OBSOLETE untagged data responses + + nil ::= "NIL" + + nstring ::= string / nil + + number ::= 1*digit + ;; Unsigned 32-bit integer + ;; (0 <= n < 4,294,967,296) + + nz_number ::= digit_nz *digit + ;; Non-zero unsigned 32-bit integer + ;; (0 < n < 4,294,967,296) + + partial ::= "PARTIAL" SPACE nz_number SPACE + ("BODY" [".PEEK"] "[" section "]" / + "RFC822" (([".TEXT"] [".PEEK"]) / ".HEADER") + SPACE number SPACE number + + password ::= astring + + quoted ::= <"> *QUOTED_CHAR <"> + + QUOTED_CHAR ::= / + "\" quoted_specials + + quoted_specials ::= <"> / "\" + + rename ::= "RENAME" SPACE mailbox SPACE mailbox + ;; Use of INBOX as a destination gives a NO error + + + +Crispin [Page 59] + +RFC 1730 IMAP4 December 1994 + + + response ::= *response_data response_done + + response_data ::= "*" SPACE (resp_cond_state / resp_cond_bye / + mailbox_data / message_data / capability_data) + CRLF + + response_done ::= response_tagged / response_fatal + + response_fatal ::= "*" SPACE resp_cond_bye CRLF + + response_tagged ::= tag SPACE resp_cond_state CRLF + + resp_cond_auth ::= ("OK" / "PREAUTH") SPACE resp_text + ;; Authentication condition + + resp_cond_bye ::= "BYE" SPACE resp_text + ;; Server will disconnect condition + + resp_cond_state ::= ("OK" / "NO" / "BAD") SPACE resp_text + ;; Status condition + + resp_text ::= ["[" resp_text_code "]" SPACE] (text_mime2 / text) + + resp_text_code ::= "ALERT" / "PARSE" / + "PERMANENTFLAGS" SPACE "(" #(flag / "\*") ")" / + "READ-ONLY" / "READ-WRITE" / "TRYCREATE" / + "UIDVALIDITY" SPACE nz_number / + "UNSEEN" SPACE nz_number / + atom [SPACE 1*] + + search ::= "SEARCH" SPACE ["CHARSET" SPACE astring SPACE] + search_criteria + ;; Character set must be registered with IANA + ;; as a MIME character set + + search_criteria ::= 1#search_key + + search_key ::= search_new / search_old + + search_new ::= "DRAFT" / + "HEADER" SPACE header_line SPACE astring / + "LARGER" SPACE number / "NOT" SPACE search_key / + "OR" SPACE search_key SPACE search_key / + "SENTBEFORE" SPACE date / "SENTON" SPACE date / + "SENTSINCE" SPACE date / "SMALLER" SPACE number / + "UID" SPACE set / "UNDRAFT" / set / + "(" search_criteria ")" + ;; New in IMAP4 + + + +Crispin [Page 60] + +RFC 1730 IMAP4 December 1994 + + + search_old ::= "ALL" / "ANSWERED" / "BCC" SPACE astring / + "BEFORE" SPACE date / "BODY" SPACE astring / + "CC" SPACE astring / "DELETED" / "FLAGGED" / + "FROM" SPACE astring / + "KEYWORD" SPACE flag_keyword / "NEW" / "OLD" / + "ON" SPACE date / "RECENT" / "SEEN" / + "SINCE" SPACE date / "SUBJECT" SPACE astring / + "TEXT" SPACE astring / "TO" SPACE astring / + "UNANSWERED" / "UNDELETED" / "UNFLAGGED" / + "UNKEYWORD" SPACE flag_keyword / "UNSEEN" + ;; Defined in [IMAP2] + + section ::= "0" / nz_number ["." section] + + select ::= "SELECT" SPACE mailbox + + sequence_num ::= nz_number / "*" + ;; * is the largest number in use. For message + ;; sequence numbers, it is the number of messages + ;; in the mailbox. For unique identifiers, it is + ;; the unique identifier of the last message in + ;; the mailbox. + + set ::= sequence_num / (sequence_num ":" sequence_num) / + (set "," set) + ;; Identifies a set of messages. For message + ;; sequence numbers, these are consecutive + ;; numbers from 1 to the number of messages in + ;; the mailbox + ;; Comma delimits individual numbers, colon + ;; delimits between two numbers inclusive. + ;; Example: 2,4:7,9,12:* is 2,4,5,6,7,9,12,13, + ;; 14,15 for a mailbox with 15 messages. + + SPACE ::= + + store ::= "STORE" SPACE set SPACE store_att_flags + + store_att_flags ::= (["+" / "-"] "FLAGS" [".SILENT"]) SPACE + (flag_list / #flag) + + string ::= quoted / literal + + subscribe ::= ("SUBSCRIBE" SPACE mailbox) / subscribe_obs + + subscribe_obs ::= "SUBSCRIBE" SPACE "MAILBOX" SPACE mailbox + ;;OBSOLETE + + + + +Crispin [Page 61] + +RFC 1730 IMAP4 December 1994 + + + tag ::= 1* + + text ::= 1*TEXT_CHAR + + text_mime2 ::= "=?" "?" "?" + "?=" + ;; Syntax defined in [MIME-2] + + TEXT_CHAR ::= + + time ::= 2digit ":" 2digit ":" 2digit + ;; Hours minutes seconds + + uid ::= "UID" SPACE (copy / fetch / search / store) + ;; Unique identifiers used instead of message + ;; sequence numbers + + uniqueid ::= nz_number + ;; Strictly ascending + + unsubscribe ::= ("UNSUBSCRIBE" SPACE mailbox) / unsubscribe_obs + + unsubscribe_obs ::= "UNSUBSCRIBE" SPACE "MAILBOX" SPACE mailbox + ;;OBSOLETE + + userid ::= astring + + x_command ::= "X" atom + + zone ::= ("+" / "-") 4digit + ;; Signed four-digit value of hhmm representing + ;; hours and minutes west of Greenwich (that is, + ;; (the amount that the given time differs from + ;; Universal Time). Subtracting the timezone + ;; from the given time will give the UT form. + ;; The Universal Time zone is "+0000". + + + + + + + + + + + + + + + +Crispin [Page 62] + +RFC 1730 IMAP4 December 1994 + + + zone_old ::= "UT" / "GMT" / "Z" / ;; +0000 + "AST" / "EDT" / ;; -0400 + "EST" / "CDT" / ;; -0500 + "CST" / "MDT" / ;; -0600 + "MST" / "PDT" / ;; -0700 + "PST" / "YDT" / ;; -0800 + "YST" / "HDT" / ;; -0900 + "HST" / "BDT" / ;; -1000 + "BST" / ;; -1100 + "A" / "B" / "C" / "D" / "E" / "F" / ;; +1 to +6 + "G" / "H" / "I" / "K" / "L" / "M" / ;; +7 to +12 + "N" / "O" / "P" / "Q" / "R" / "S" / ;; -1 to -6 + "T" / "U" / "V" / "W" / "X" / "Y" ;; -7 to -12 + ;; OBSOLETE + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Crispin [Page 63] + +RFC 1730 IMAP4 December 1994 + + +10. Author's Note + + This document is a revision or rewrite of earlier documents, and + supercedes the protocol specification in those documents: IMAP4 + Internet drafts, the IMAP2bis Internet drafts, unpublished + IMAP2bis.TXT document, RFC 1176, and RFC 1064. + + +11. Security Considerations + + IMAP4 protocol transactions, including electronic mail data, are sent + in the clear over the network unless the optional privacy protection + is negotiated in the AUTHENTICATE command. + + A server error message for an AUTHENTICATE command which fails due to + invalid credentials should not detail why the credentials are + invalid. + + Use of the LOGIN command sends passwords in the clear. This can be + avoided by using the AUTHENTICATE command instead. + + A server error message for a failing LOGIN command should not specify + that the user name, as opposed to the password, is invalid. + + Additional security considerations are discussed in the section + discussing the AUTHENTICATE and LOGIN commands. + + +12. Author's Address + + Mark R. Crispin + Networks and Distributed Computing, JE-30 + University of Washington + Seattle, WA 98195 + + Phone: (206) 543-5762 + + EMail: MRC@CAC.Washington.EDU + + + + + + + + + + + + + +Crispin [Page 64] + +RFC 1730 IMAP4 December 1994 + + +Appendices + +A. Obsolete Commands + + The following commands are OBSOLETE. It is NOT required to support + any of these commands in new server implementations. These commands + are documented here for the benefit of implementors who may wish to + support them for compatibility with old client implementations. + + The section headings of these commands are intended to correspond + with where they would be located in the main document if they were + not obsoleted. + + +A.6.3.OBS.1. FIND ALL.MAILBOXES Command + + Arguments: mailbox name with possible wildcards + + Data: untagged responses: MAILBOX + + Result: OK - find completed + NO - find failure: can't list that name + BAD - command unknown or arguments invalid + + The FIND ALL.MAILBOXES command returns a subset of names from the + complete set of all names available to the user. It returns zero + or more untagged MAILBOX replies. The mailbox argument to FIND + ALL.MAILBOXES is similar to that for LIST with an empty reference, + except that the characters "%" and "?" match a single character. + + Example: C: A002 FIND ALL.MAILBOXES * + S: * MAILBOX blurdybloop + S: * MAILBOX INBOX + S: A002 OK FIND ALL.MAILBOXES completed + + +A.6.3.OBS.2. FIND MAILBOXES Command + + Arguments: mailbox name with possible wildcards + + Data: untagged responses: MAILBOX + + Result: OK - find completed + NO - find failure: can't list that name + BAD - command unknown or arguments invalid + + The FIND MAILBOXES command returns a subset of names from the set + of names that the user has declared as being "active" or + + + +Crispin [Page 65] + +RFC 1730 IMAP4 December 1994 + + + "subscribed". It returns zero or more untagged MAILBOX replies. + The mailbox argument to FIND MAILBOXES is similar to that for LSUB + with an empty reference, except that the characters "%" and "?" + match a single character. + + Example: C: A002 FIND MAILBOXES * + S: * MAILBOX blurdybloop + S: * MAILBOX INBOX + S: A002 OK FIND MAILBOXES completed + + +A.6.3.OBS.3. SUBSCRIBE MAILBOX Command + + Arguments: mailbox name + + Data: no specific data for this command + + Result: OK - subscribe completed + NO - subscribe failure: can't subscribe to that name + BAD - command unknown or arguments invalid + + The SUBSCRIBE MAILBOX command is identical in effect to the + SUBSCRIBE command. A server which implements this command must be + able to distinguish between a SUBSCRIBE MAILBOX command and a + SUBSCRIBE command with a mailbox name argument of "MAILBOX". + + Example: C: A002 SUBSCRIBE MAILBOX #news.comp.mail.mime + S: A002 OK SUBSCRIBE MAILBOX to #news.comp.mail.mime + completed + C: A003 SUBSCRIBE MAILBOX + S: A003 OK SUBSCRIBE to MAILBOX completed + + +A.6.3.OBS.4. UNSUBSCRIBE MAILBOX Command + + Arguments: mailbox name + + Data: no specific data for this command + + Result: OK - unsubscribe completed + NO - unsubscribe failure: can't unsubscribe that name + BAD - command unknown or arguments invalid + + The UNSUBSCRIBE MAILBOX command is identical in effect to the + UNSUBSCRIBE command. A server which implements this command must + be able to distinguish between a UNSUBSCRIBE MAILBOX command and + an UNSUBSCRIBE command with a mailbox name argument of "MAILBOX". + + + + +Crispin [Page 66] + +RFC 1730 IMAP4 December 1994 + + + Example: C: A002 UNSUBSCRIBE MAILBOX #news.comp.mail.mime + S: A002 OK UNSUBSCRIBE MAILBOX from #news.comp.mail.mime + completed + C: A003 UNSUBSCRIBE MAILBOX + S: A003 OK UNSUBSCRIBE from MAILBOX completed + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Crispin [Page 67] + +RFC 1730 IMAP4 December 1994 + + +B. Obsolete Responses + + The following responses are OBSOLETE. Except as noted below, these + responses MUST NOT be transmitted by new server implementations. + + The section headings of these responses are intended to correspond + with where they would be located in the main document if they were + not obsoleted. + + +B.7.2.OBS.1. MAILBOX Response + + Data: name + + The MAILBOX response MUST NOT be transmitted by server + implementations except in response to the obsolete FIND MAILBOXES + and FIND ALL.MAILBOXES commands. Client implementations that do + not use these commands MAY ignore this response. It is documented + here for the benefit of implementors who may wish to support it + for compatibility with old client implementations. + + This response occurs as a result of the FIND MAILBOXES and FIND + ALL.MAILBOXES commands. It returns a single name that matches the + FIND specification. There are no attributes or hierarchy + delimiter. + + Example: S: * MAILBOX blurdybloop + + +B.7.3.OBS.1. COPY Response + + Data: none + + The COPY response MUST NOT be transmitted by new server + implementations. Client implementations MUST ignore the COPY + response. It is documented here for the benefit of client + implementors who may encounter this response from old server + implementations. + + In some experimental versions of this protocol, this response was + returned in response to a COPY command to indicate on a + per-message basis that the message was copied successfully. + + Example: S: * 44 COPY + + + + + + + +Crispin [Page 68] + +RFC 1730 IMAP4 December 1994 + + +B.7.3.OBS.2. STORE Response + + Data: message data + + The STORE response MUST NOT be transmitted by new server + implementations. Client implementations MUST treat the STORE + response as equivalent to the FETCH response. It is documented + here for the benefit of client implementors who may encounter this + response from old server implementations. + + In some experimental versions of this protocol, this response was + returned instead of FETCH in response to a STORE command to report + the new value of the flags. + + Example: S: * 69 STORE (FLAGS (\Deleted)) + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Crispin [Page 69] + +RFC 1730 IMAP4 December 1994 + + +C. References + + + [IMAP-AUTH] Myers, J., "IMAP4 Authentication Mechanism", RFC 1731. + Carnegie-Mellon University, December 1994. + + [IMAP-COMPAT] Crispin, M. "IMAP4 Compatibility with IMAP2 and + IMAP2bis", RFC 1732, University of Washington, December 1994. + + [IMAP-DISC] Austein, R. "Synchronization Operations for Disconnected + IMAP4 Clients", Work in Progress. + + [IMAP-MODEL] Crispin, M. "Distributed Electronic Mail Models in + IMAP4", RFC 1733, University of Washington, December 1994. + + [IMAP-NAMING] Crispin, M. "Mailbox Naming Convention in IMAP4", Work + in Progress. + + [IMAP2] Crispin, M., "Interactive Mail Access Protocol - Version 2", + RFC 1176, University of Washington, August 1990. + + [IMSP] Myers, J. "IMSP -- Internet Message Support Protocol", Work in + Progress. + + [MIME-1] Borenstein, N., and Freed, N., "MIME (Multipurpose Internet + Mail Extensions) Part One: Mechanisms for Specifying and Describing + the Format of Internet Message Bodies", RFC 1521, Bellcore, Innosoft, + September 1993. + + [MIME-2] Moore, K., "MIME (Multipurpose Internet Mail Extensions) + Part Two: Message Header Extensions for Non-ASCII Text", RFC 1522, + University of Tennessee, September 1993. + + [RFC-822] Crocker, D., "Standard for the Format of ARPA Internet Text + Messages", STD 11, RFC 822, University of Delaware, August 1982. + + [SMTP] Postel, Jonathan B. "Simple Mail Transfer Protocol", STD 10, + RFC 821, USC/Information Sciences Institute, August 1982. + + + + + + + + + + + + + +Crispin [Page 70] + +RFC 1730 IMAP4 December 1994 + + +E. IMAP4 Keyword Index + + + +FLAGS (store command data item) ............... 34 + +FLAGS.SILENT (store command data item) ........ 34 + -FLAGS (store command data item) ............... 34 + -FLAGS.SILENT (store command data item) ........ 34 + ALERT (response code) ...................................... 39 + ALL (fetch item) ........................................... 29 + ALL (search key) ........................................... 27 + ANSWERED (search key) ...................................... 27 + APPEND (command) ........................................... 22 + AUTHENTICATE (command) ..................................... 12 + BAD (response) ............................................. 41 + BCC (search key) .................................. 27 + BEFORE (search key) ................................. 27 + BODY (fetch item) .......................................... 29 + BODY (fetch result) ........................................ 46 + BODY (search key) ................................. 27 + BODY.PEEK[
] (fetch item) .......................... 30 + BODYSTRUCTURE (fetch item) ................................. 31 + BODYSTRUCTURE (fetch result) ............................... 47 + BODY[
] (fetch item) ............................... 29 + BODY[section] (fetch result) ............................... 46 + BYE (response) ............................................. 41 + CAPABILITY (command) ....................................... 10 + CAPABILITY (response) ...................................... 42 + CC (search key) ................................... 27 + CHECK (command) ............................................ 23 + CLOSE (command) ............................................ 24 + COPY (command) ............................................. 34 + COPY (response) ............................................ 68 + CREATE (command) ........................................... 17 + DELETE (command) ........................................... 18 + DELETED (search key) ....................................... 27 + DRAFT (search key) ......................................... 27 + ENVELOPE (fetch item) ...................................... 31 + ENVELOPE (fetch result) .................................... 49 + EXAMINE (command) .......................................... 16 + EXISTS (response) .......................................... 45 + EXPUNGE (command) .......................................... 25 + EXPUNGE (response) ......................................... 45 + FAST (fetch item) .......................................... 31 + FETCH (command) ............................................ 29 + FETCH (response) ........................................... 46 + FIND ALL.MAILBOXES (command) ............................... 65 + FIND MAILBOXES (command) ................................... 65 + FLAGGED (search key) ....................................... 27 + FLAGS (fetch item) ......................................... 31 + + + +Crispin [Page 71] + +RFC 1730 IMAP4 December 1994 + + + + FLAGS (fetch result) ....................................... 50 + FLAGS (response) ........................................... 44 + FLAGS (store command data item) ................ 34 + FLAGS.SILENT (store command data item) ......... 34 + FROM (search key) ................................. 27 + FULL (fetch item) .......................................... 31 + HEADER (search key) .................. 27 + INTERNALDATE (fetch item) .................................. 31 + INTERNALDATE (fetch result) ................................ 50 + KEYWORD (search key) ................................ 27 + LARGER (search key) .................................... 27 + LIST (command) ............................................. 20 + LIST (response) ............................................ 43 + LOGIN (command) ............................................ 14 + LOGOUT (command) ........................................... 11 + LSUB (command) ............................................. 22 + LSUB (response) ............................................ 44 + MAILBOX (response) ......................................... 68 + NEW (search key) ........................................... 27 + NO (response) .............................................. 40 + NOOP (command) ............................................. 11 + NOT (search key) .............................. 28 + OK (response) .............................................. 40 + OLD (search key) ........................................... 28 + ON (search key) ..................................... 28 + OR (search key) ................ 28 + PARSE (response code) ...................................... 39 + PARTIAL (command) .......................................... 32 + PERMANENTFLAGS (response code) ............................. 39 + PREAUTH (response) ......................................... 41 + READ-ONLY (response code) .................................. 39 + READ-WRITE (response code) ................................. 39 + RECENT (response) .......................................... 45 + RECENT (search key) ........................................ 28 + RENAME (command) ........................................... 18 + RFC822 (fetch item) ........................................ 31 + RFC822 (fetch result) ...................................... 50 + RFC822.HEADER (fetch item) ................................. 31 + RFC822.HEADER (fetch result) ............................... 50 + RFC822.HEADER.LINES (fetch item) ............. 31 + RFC822.HEADER.LINES.NOT (fetch item) ......... 32 + RFC822.PEEK (fetch item) ................................... 31 + RFC822.SIZE (fetch item) ................................... 32 + RFC822.SIZE (fetch result) ................................. 50 + RFC822.TEXT (fetch item) ................................... 32 + RFC822.TEXT (fetch result) ................................. 51 + RFC822.TEXT.PEEK (fetch item) .............................. 32 + SEARCH (command) ........................................... 25 + + + +Crispin [Page 72] + +RFC 1730 IMAP4 December 1994 + + + + SEARCH (response) .......................................... 44 + SEEN (search key) .......................................... 28 + SELECT (command) ........................................... 15 + SENTBEFORE (search key) ............................. 28 + SENTON (search key) ................................. 28 + SENTSINCE (search key) .............................. 28 + SINCE (search key) .................................. 28 + SMALLER (search key) ................................... 28 + STORE (command) ............................................ 33 + STORE (response) ........................................... 69 + SUBJECT (search key) .............................. 28 + SUBSCRIBE (command) ........................................ 19 + SUBSCRIBE MAILBOX (command) ................................ 66 + TEXT (search key) ................................. 28 + TO (search key) ................................... 28 + TRYCREATE (response code) .................................. 39 + UID (command) .............................................. 35 + UID (fetch item) ........................................... 32 + UID (fetch result) ......................................... 51 + UID (search key) ............................. 28 + UIDVALIDITY (response code) ................................ 40 + UNANSWERED (search key) .................................... 29 + UNDELETED (search key) ..................................... 29 + UNDRAFT (search key) ....................................... 29 + UNFLAGGED (search key) ..................................... 29 + UNKEYWORD (search key) .............................. 29 + UNSEEN (response code) ..................................... 40 + UNSEEN (search key) ........................................ 29 + UNSUBSCRIBE (command) ...................................... 19 + UNSUBSCRIBE MAILBOX (command) .............................. 66 + X (command) .......................................... 37 + \Answered (system flag) .................................... 50 + \Deleted (system flag) ..................................... 50 + \Draft (system flag) ....................................... 50 + \Flagged (system flag) ..................................... 50 + \Marked (mailbox name attribute) ........................... 43 + \Noinferiors (mailbox name attribute) ...................... 43 + \Noselect (mailbox name attribute) ......................... 43 + \Recent (system flag) ...................................... 50 + \Seen (system flag) ........................................ 50 + \Unmarked (mailbox name attribute) ......................... 43 + + + + + + + + + + +Crispin [Page 73] + diff --git a/RFCs/rfc1939.txt b/RFCs/rfc1939.txt new file mode 100644 index 0000000..b11350e --- /dev/null +++ b/RFCs/rfc1939.txt @@ -0,0 +1,1291 @@ + + + + + + +Network Working Group J. Myers +Request for Comments: 1939 Carnegie Mellon +STD: 53 M. Rose +Obsoletes: 1725 Dover Beach Consulting, Inc. +Category: Standards Track May 1996 + + + Post Office Protocol - Version 3 + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Table of Contents + + 1. Introduction ................................................ 2 + 2. A Short Digression .......................................... 2 + 3. Basic Operation ............................................. 3 + 4. The AUTHORIZATION State ..................................... 4 + QUIT Command ................................................ 5 + 5. The TRANSACTION State ....................................... 5 + STAT Command ................................................ 6 + LIST Command ................................................ 6 + RETR Command ................................................ 8 + DELE Command ................................................ 8 + NOOP Command ................................................ 9 + RSET Command ................................................ 9 + 6. The UPDATE State ............................................ 10 + QUIT Command ................................................ 10 + 7. Optional POP3 Commands ...................................... 11 + TOP Command ................................................. 11 + UIDL Command ................................................ 12 + USER Command ................................................ 13 + PASS Command ................................................ 14 + APOP Command ................................................ 15 + 8. Scaling and Operational Considerations ...................... 16 + 9. POP3 Command Summary ........................................ 18 + 10. Example POP3 Session ....................................... 19 + 11. Message Format ............................................. 19 + 12. References ................................................. 20 + 13. Security Considerations .................................... 20 + 14. Acknowledgements ........................................... 20 + 15. Authors' Addresses ......................................... 21 + Appendix A. Differences from RFC 1725 .......................... 22 + + + +Myers & Rose Standards Track [Page 1] + +RFC 1939 POP3 May 1996 + + + Appendix B. Command Index ...................................... 23 + +1. Introduction + + On certain types of smaller nodes in the Internet it is often + impractical to maintain a message transport system (MTS). For + example, a workstation may not have sufficient resources (cycles, + disk space) in order to permit a SMTP server [RFC821] and associated + local mail delivery system to be kept resident and continuously + running. Similarly, it may be expensive (or impossible) to keep a + personal computer interconnected to an IP-style network for long + amounts of time (the node is lacking the resource known as + "connectivity"). + + Despite this, it is often very useful to be able to manage mail on + these smaller nodes, and they often support a user agent (UA) to aid + the tasks of mail handling. To solve this problem, a node which can + support an MTS entity offers a maildrop service to these less endowed + nodes. The Post Office Protocol - Version 3 (POP3) is intended to + permit a workstation to dynamically access a maildrop on a server + host in a useful fashion. Usually, this means that the POP3 protocol + is used to allow a workstation to retrieve mail that the server is + holding for it. + + POP3 is not intended to provide extensive manipulation operations of + mail on the server; normally, mail is downloaded and then deleted. A + more advanced (and complex) protocol, IMAP4, is discussed in + [RFC1730]. + + For the remainder of this memo, the term "client host" refers to a + host making use of the POP3 service, while the term "server host" + refers to a host which offers the POP3 service. + +2. A Short Digression + + This memo does not specify how a client host enters mail into the + transport system, although a method consistent with the philosophy of + this memo is presented here: + + When the user agent on a client host wishes to enter a message + into the transport system, it establishes an SMTP connection to + its relay host and sends all mail to it. This relay host could + be, but need not be, the POP3 server host for the client host. Of + course, the relay host must accept mail for delivery to arbitrary + recipient addresses, that functionality is not required of all + SMTP servers. + + + + + +Myers & Rose Standards Track [Page 2] + +RFC 1939 POP3 May 1996 + + +3. Basic Operation + + Initially, the server host starts the POP3 service by listening on + TCP port 110. When a client host wishes to make use of the service, + it establishes a TCP connection with the server host. When the + connection is established, the POP3 server sends a greeting. The + client and POP3 server then exchange commands and responses + (respectively) until the connection is closed or aborted. + + Commands in the POP3 consist of a case-insensitive keyword, possibly + followed by one or more arguments. All commands are terminated by a + CRLF pair. Keywords and arguments consist of printable ASCII + characters. Keywords and arguments are each separated by a single + SPACE character. Keywords are three or four characters long. Each + argument may be up to 40 characters long. + + Responses in the POP3 consist of a status indicator and a keyword + possibly followed by additional information. All responses are + terminated by a CRLF pair. Responses may be up to 512 characters + long, including the terminating CRLF. There are currently two status + indicators: positive ("+OK") and negative ("-ERR"). Servers MUST + send the "+OK" and "-ERR" in upper case. + + Responses to certain commands are multi-line. In these cases, which + are clearly indicated below, after sending the first line of the + response and a CRLF, any additional lines are sent, each terminated + by a CRLF pair. When all lines of the response have been sent, a + final line is sent, consisting of a termination octet (decimal code + 046, ".") and a CRLF pair. If any line of the multi-line response + begins with the termination octet, the line is "byte-stuffed" by + pre-pending the termination octet to that line of the response. + Hence a multi-line response is terminated with the five octets + "CRLF.CRLF". When examining a multi-line response, the client checks + to see if the line begins with the termination octet. If so and if + octets other than CRLF follow, the first octet of the line (the + termination octet) is stripped away. If so and if CRLF immediately + follows the termination character, then the response from the POP + server is ended and the line containing ".CRLF" is not considered + part of the multi-line response. + + A POP3 session progresses through a number of states during its + lifetime. Once the TCP connection has been opened and the POP3 + server has sent the greeting, the session enters the AUTHORIZATION + state. In this state, the client must identify itself to the POP3 + server. Once the client has successfully done this, the server + acquires resources associated with the client's maildrop, and the + session enters the TRANSACTION state. In this state, the client + requests actions on the part of the POP3 server. When the client has + + + +Myers & Rose Standards Track [Page 3] + +RFC 1939 POP3 May 1996 + + + issued the QUIT command, the session enters the UPDATE state. In + this state, the POP3 server releases any resources acquired during + the TRANSACTION state and says goodbye. The TCP connection is then + closed. + + A server MUST respond to an unrecognized, unimplemented, or + syntactically invalid command by responding with a negative status + indicator. A server MUST respond to a command issued when the + session is in an incorrect state by responding with a negative status + indicator. There is no general method for a client to distinguish + between a server which does not implement an optional command and a + server which is unwilling or unable to process the command. + + A POP3 server MAY have an inactivity autologout timer. Such a timer + MUST be of at least 10 minutes' duration. The receipt of any command + from the client during that interval should suffice to reset the + autologout timer. When the timer expires, the session does NOT enter + the UPDATE state--the server should close the TCP connection without + removing any messages or sending any response to the client. + +4. The AUTHORIZATION State + + Once the TCP connection has been opened by a POP3 client, the POP3 + server issues a one line greeting. This can be any positive + response. An example might be: + + S: +OK POP3 server ready + + The POP3 session is now in the AUTHORIZATION state. The client must + now identify and authenticate itself to the POP3 server. Two + possible mechanisms for doing this are described in this document, + the USER and PASS command combination and the APOP command. Both + mechanisms are described later in this document. Additional + authentication mechanisms are described in [RFC1734]. While there is + no single authentication mechanism that is required of all POP3 + servers, a POP3 server must of course support at least one + authentication mechanism. + + Once the POP3 server has determined through the use of any + authentication command that the client should be given access to the + appropriate maildrop, the POP3 server then acquires an exclusive- + access lock on the maildrop, as necessary to prevent messages from + being modified or removed before the session enters the UPDATE state. + If the lock is successfully acquired, the POP3 server responds with a + positive status indicator. The POP3 session now enters the + TRANSACTION state, with no messages marked as deleted. If the + maildrop cannot be opened for some reason (for example, a lock can + not be acquired, the client is denied access to the appropriate + + + +Myers & Rose Standards Track [Page 4] + +RFC 1939 POP3 May 1996 + + + maildrop, or the maildrop cannot be parsed), the POP3 server responds + with a negative status indicator. (If a lock was acquired but the + POP3 server intends to respond with a negative status indicator, the + POP3 server must release the lock prior to rejecting the command.) + After returning a negative status indicator, the server may close the + connection. If the server does not close the connection, the client + may either issue a new authentication command and start again, or the + client may issue the QUIT command. + + After the POP3 server has opened the maildrop, it assigns a message- + number to each message, and notes the size of each message in octets. + The first message in the maildrop is assigned a message-number of + "1", the second is assigned "2", and so on, so that the nth message + in a maildrop is assigned a message-number of "n". In POP3 commands + and responses, all message-numbers and message sizes are expressed in + base-10 (i.e., decimal). + + Here is the summary for the QUIT command when used in the + AUTHORIZATION state: + + QUIT + + Arguments: none + + Restrictions: none + + Possible Responses: + +OK + + Examples: + C: QUIT + S: +OK dewey POP3 server signing off + +5. The TRANSACTION State + + Once the client has successfully identified itself to the POP3 server + and the POP3 server has locked and opened the appropriate maildrop, + the POP3 session is now in the TRANSACTION state. The client may now + issue any of the following POP3 commands repeatedly. After each + command, the POP3 server issues a response. Eventually, the client + issues the QUIT command and the POP3 session enters the UPDATE state. + + + + + + + + + + +Myers & Rose Standards Track [Page 5] + +RFC 1939 POP3 May 1996 + + + Here are the POP3 commands valid in the TRANSACTION state: + + STAT + + Arguments: none + + Restrictions: + may only be given in the TRANSACTION state + + Discussion: + The POP3 server issues a positive response with a line + containing information for the maildrop. This line is + called a "drop listing" for that maildrop. + + In order to simplify parsing, all POP3 servers are + required to use a certain format for drop listings. The + positive response consists of "+OK" followed by a single + space, the number of messages in the maildrop, a single + space, and the size of the maildrop in octets. This memo + makes no requirement on what follows the maildrop size. + Minimal implementations should just end that line of the + response with a CRLF pair. More advanced implementations + may include other information. + + NOTE: This memo STRONGLY discourages implementations + from supplying additional information in the drop + listing. Other, optional, facilities are discussed + later on which permit the client to parse the messages + in the maildrop. + + Note that messages marked as deleted are not counted in + either total. + + Possible Responses: + +OK nn mm + + Examples: + C: STAT + S: +OK 2 320 + + + LIST [msg] + + Arguments: + a message-number (optional), which, if present, may NOT + refer to a message marked as deleted + + + + + +Myers & Rose Standards Track [Page 6] + +RFC 1939 POP3 May 1996 + + + Restrictions: + may only be given in the TRANSACTION state + + Discussion: + If an argument was given and the POP3 server issues a + positive response with a line containing information for + that message. This line is called a "scan listing" for + that message. + + If no argument was given and the POP3 server issues a + positive response, then the response given is multi-line. + After the initial +OK, for each message in the maildrop, + the POP3 server responds with a line containing + information for that message. This line is also called a + "scan listing" for that message. If there are no + messages in the maildrop, then the POP3 server responds + with no scan listings--it issues a positive response + followed by a line containing a termination octet and a + CRLF pair. + + In order to simplify parsing, all POP3 servers are + required to use a certain format for scan listings. A + scan listing consists of the message-number of the + message, followed by a single space and the exact size of + the message in octets. Methods for calculating the exact + size of the message are described in the "Message Format" + section below. This memo makes no requirement on what + follows the message size in the scan listing. Minimal + implementations should just end that line of the response + with a CRLF pair. More advanced implementations may + include other information, as parsed from the message. + + NOTE: This memo STRONGLY discourages implementations + from supplying additional information in the scan + listing. Other, optional, facilities are discussed + later on which permit the client to parse the messages + in the maildrop. + + Note that messages marked as deleted are not listed. + + Possible Responses: + +OK scan listing follows + -ERR no such message + + Examples: + C: LIST + S: +OK 2 messages (320 octets) + S: 1 120 + + + +Myers & Rose Standards Track [Page 7] + +RFC 1939 POP3 May 1996 + + + S: 2 200 + S: . + ... + C: LIST 2 + S: +OK 2 200 + ... + C: LIST 3 + S: -ERR no such message, only 2 messages in maildrop + + + RETR msg + + Arguments: + a message-number (required) which may NOT refer to a + message marked as deleted + + Restrictions: + may only be given in the TRANSACTION state + + Discussion: + If the POP3 server issues a positive response, then the + response given is multi-line. After the initial +OK, the + POP3 server sends the message corresponding to the given + message-number, being careful to byte-stuff the termination + character (as with all multi-line responses). + + Possible Responses: + +OK message follows + -ERR no such message + + Examples: + C: RETR 1 + S: +OK 120 octets + S: + S: . + + + DELE msg + + Arguments: + a message-number (required) which may NOT refer to a + message marked as deleted + + Restrictions: + may only be given in the TRANSACTION state + + + + + + +Myers & Rose Standards Track [Page 8] + +RFC 1939 POP3 May 1996 + + + Discussion: + The POP3 server marks the message as deleted. Any future + reference to the message-number associated with the message + in a POP3 command generates an error. The POP3 server does + not actually delete the message until the POP3 session + enters the UPDATE state. + + Possible Responses: + +OK message deleted + -ERR no such message + + Examples: + C: DELE 1 + S: +OK message 1 deleted + ... + C: DELE 2 + S: -ERR message 2 already deleted + + + NOOP + + Arguments: none + + Restrictions: + may only be given in the TRANSACTION state + + Discussion: + The POP3 server does nothing, it merely replies with a + positive response. + + Possible Responses: + +OK + + Examples: + C: NOOP + S: +OK + + + RSET + + Arguments: none + + Restrictions: + may only be given in the TRANSACTION state + + Discussion: + If any messages have been marked as deleted by the POP3 + server, they are unmarked. The POP3 server then replies + + + +Myers & Rose Standards Track [Page 9] + +RFC 1939 POP3 May 1996 + + + with a positive response. + + Possible Responses: + +OK + + Examples: + C: RSET + S: +OK maildrop has 2 messages (320 octets) + +6. The UPDATE State + + When the client issues the QUIT command from the TRANSACTION state, + the POP3 session enters the UPDATE state. (Note that if the client + issues the QUIT command from the AUTHORIZATION state, the POP3 + session terminates but does NOT enter the UPDATE state.) + + If a session terminates for some reason other than a client-issued + QUIT command, the POP3 session does NOT enter the UPDATE state and + MUST not remove any messages from the maildrop. + + QUIT + + Arguments: none + + Restrictions: none + + Discussion: + The POP3 server removes all messages marked as deleted + from the maildrop and replies as to the status of this + operation. If there is an error, such as a resource + shortage, encountered while removing messages, the + maildrop may result in having some or none of the messages + marked as deleted be removed. In no case may the server + remove any messages not marked as deleted. + + Whether the removal was successful or not, the server + then releases any exclusive-access lock on the maildrop + and closes the TCP connection. + + Possible Responses: + +OK + -ERR some deleted messages not removed + + Examples: + C: QUIT + S: +OK dewey POP3 server signing off (maildrop empty) + ... + C: QUIT + + + +Myers & Rose Standards Track [Page 10] + +RFC 1939 POP3 May 1996 + + + S: +OK dewey POP3 server signing off (2 messages left) + ... + +7. Optional POP3 Commands + + The POP3 commands discussed above must be supported by all minimal + implementations of POP3 servers. + + The optional POP3 commands described below permit a POP3 client + greater freedom in message handling, while preserving a simple POP3 + server implementation. + + NOTE: This memo STRONGLY encourages implementations to support + these commands in lieu of developing augmented drop and scan + listings. In short, the philosophy of this memo is to put + intelligence in the part of the POP3 client and not the POP3 + server. + + TOP msg n + + Arguments: + a message-number (required) which may NOT refer to to a + message marked as deleted, and a non-negative number + of lines (required) + + Restrictions: + may only be given in the TRANSACTION state + + Discussion: + If the POP3 server issues a positive response, then the + response given is multi-line. After the initial +OK, the + POP3 server sends the headers of the message, the blank + line separating the headers from the body, and then the + number of lines of the indicated message's body, being + careful to byte-stuff the termination character (as with + all multi-line responses). + + Note that if the number of lines requested by the POP3 + client is greater than than the number of lines in the + body, then the POP3 server sends the entire message. + + Possible Responses: + +OK top of message follows + -ERR no such message + + Examples: + C: TOP 1 10 + S: +OK + + + +Myers & Rose Standards Track [Page 11] + +RFC 1939 POP3 May 1996 + + + S: + S: . + ... + C: TOP 100 3 + S: -ERR no such message + + + UIDL [msg] + + Arguments: + a message-number (optional), which, if present, may NOT + refer to a message marked as deleted + + Restrictions: + may only be given in the TRANSACTION state. + + Discussion: + If an argument was given and the POP3 server issues a positive + response with a line containing information for that message. + This line is called a "unique-id listing" for that message. + + If no argument was given and the POP3 server issues a positive + response, then the response given is multi-line. After the + initial +OK, for each message in the maildrop, the POP3 server + responds with a line containing information for that message. + This line is called a "unique-id listing" for that message. + + In order to simplify parsing, all POP3 servers are required to + use a certain format for unique-id listings. A unique-id + listing consists of the message-number of the message, + followed by a single space and the unique-id of the message. + No information follows the unique-id in the unique-id listing. + + The unique-id of a message is an arbitrary server-determined + string, consisting of one to 70 characters in the range 0x21 + to 0x7E, which uniquely identifies a message within a + maildrop and which persists across sessions. This + persistence is required even if a session ends without + entering the UPDATE state. The server should never reuse an + unique-id in a given maildrop, for as long as the entity + using the unique-id exists. + + Note that messages marked as deleted are not listed. + + While it is generally preferable for server implementations + to store arbitrarily assigned unique-ids in the maildrop, + + + +Myers & Rose Standards Track [Page 12] + +RFC 1939 POP3 May 1996 + + + this specification is intended to permit unique-ids to be + calculated as a hash of the message. Clients should be able + to handle a situation where two identical copies of a + message in a maildrop have the same unique-id. + + Possible Responses: + +OK unique-id listing follows + -ERR no such message + + Examples: + C: UIDL + S: +OK + S: 1 whqtswO00WBw418f9t5JxYwZ + S: 2 QhdPYR:00WBw1Ph7x7 + S: . + ... + C: UIDL 2 + S: +OK 2 QhdPYR:00WBw1Ph7x7 + ... + C: UIDL 3 + S: -ERR no such message, only 2 messages in maildrop + + + USER name + + Arguments: + a string identifying a mailbox (required), which is of + significance ONLY to the server + + Restrictions: + may only be given in the AUTHORIZATION state after the POP3 + greeting or after an unsuccessful USER or PASS command + + Discussion: + To authenticate using the USER and PASS command + combination, the client must first issue the USER + command. If the POP3 server responds with a positive + status indicator ("+OK"), then the client may issue + either the PASS command to complete the authentication, + or the QUIT command to terminate the POP3 session. If + the POP3 server responds with a negative status indicator + ("-ERR") to the USER command, then the client may either + issue a new authentication command or may issue the QUIT + command. + + The server may return a positive response even though no + such mailbox exists. The server may return a negative + response if mailbox exists, but does not permit plaintext + + + +Myers & Rose Standards Track [Page 13] + +RFC 1939 POP3 May 1996 + + + password authentication. + + Possible Responses: + +OK name is a valid mailbox + -ERR never heard of mailbox name + + Examples: + C: USER frated + S: -ERR sorry, no mailbox for frated here + ... + C: USER mrose + S: +OK mrose is a real hoopy frood + + + PASS string + + Arguments: + a server/mailbox-specific password (required) + + Restrictions: + may only be given in the AUTHORIZATION state immediately + after a successful USER command + + Discussion: + When the client issues the PASS command, the POP3 server + uses the argument pair from the USER and PASS commands to + determine if the client should be given access to the + appropriate maildrop. + + Since the PASS command has exactly one argument, a POP3 + server may treat spaces in the argument as part of the + password, instead of as argument separators. + + Possible Responses: + +OK maildrop locked and ready + -ERR invalid password + -ERR unable to lock maildrop + + Examples: + C: USER mrose + S: +OK mrose is a real hoopy frood + C: PASS secret + S: -ERR maildrop already locked + ... + C: USER mrose + S: +OK mrose is a real hoopy frood + C: PASS secret + S: +OK mrose's maildrop has 2 messages (320 octets) + + + +Myers & Rose Standards Track [Page 14] + +RFC 1939 POP3 May 1996 + + + APOP name digest + + Arguments: + a string identifying a mailbox and a MD5 digest string + (both required) + + Restrictions: + may only be given in the AUTHORIZATION state after the POP3 + greeting or after an unsuccessful USER or PASS command + + Discussion: + Normally, each POP3 session starts with a USER/PASS + exchange. This results in a server/user-id specific + password being sent in the clear on the network. For + intermittent use of POP3, this may not introduce a sizable + risk. However, many POP3 client implementations connect to + the POP3 server on a regular basis -- to check for new + mail. Further the interval of session initiation may be on + the order of five minutes. Hence, the risk of password + capture is greatly enhanced. + + An alternate method of authentication is required which + provides for both origin authentication and replay + protection, but which does not involve sending a password + in the clear over the network. The APOP command provides + this functionality. + + A POP3 server which implements the APOP command will + include a timestamp in its banner greeting. The syntax of + the timestamp corresponds to the `msg-id' in [RFC822], and + MUST be different each time the POP3 server issues a banner + greeting. For example, on a UNIX implementation in which a + separate UNIX process is used for each instance of a POP3 + server, the syntax of the timestamp might be: + + + + where `process-ID' is the decimal value of the process's + PID, clock is the decimal value of the system clock, and + hostname is the fully-qualified domain-name corresponding + to the host where the POP3 server is running. + + The POP3 client makes note of this timestamp, and then + issues the APOP command. The `name' parameter has + identical semantics to the `name' parameter of the USER + command. The `digest' parameter is calculated by applying + the MD5 algorithm [RFC1321] to a string consisting of the + timestamp (including angle-brackets) followed by a shared + + + +Myers & Rose Standards Track [Page 15] + +RFC 1939 POP3 May 1996 + + + secret. This shared secret is a string known only to the + POP3 client and server. Great care should be taken to + prevent unauthorized disclosure of the secret, as knowledge + of the secret will allow any entity to successfully + masquerade as the named user. The `digest' parameter + itself is a 16-octet value which is sent in hexadecimal + format, using lower-case ASCII characters. + + When the POP3 server receives the APOP command, it verifies + the digest provided. If the digest is correct, the POP3 + server issues a positive response, and the POP3 session + enters the TRANSACTION state. Otherwise, a negative + response is issued and the POP3 session remains in the + AUTHORIZATION state. + + Note that as the length of the shared secret increases, so + does the difficulty of deriving it. As such, shared + secrets should be long strings (considerably longer than + the 8-character example shown below). + + Possible Responses: + +OK maildrop locked and ready + -ERR permission denied + + Examples: + S: +OK POP3 server ready <1896.697170952@dbc.mtview.ca.us> + C: APOP mrose c4c9334bac560ecc979e58001b3e22fb + S: +OK maildrop has 1 message (369 octets) + + In this example, the shared secret is the string `tan- + staaf'. Hence, the MD5 algorithm is applied to the string + + <1896.697170952@dbc.mtview.ca.us>tanstaaf + + which produces a digest value of + + c4c9334bac560ecc979e58001b3e22fb + +8. Scaling and Operational Considerations + + Since some of the optional features described above were added to the + POP3 protocol, experience has accumulated in using them in large- + scale commercial post office operations where most of the users are + unrelated to each other. In these situations and others, users and + vendors of POP3 clients have discovered that the combination of using + the UIDL command and not issuing the DELE command can provide a weak + version of the "maildrop as semi-permanent repository" functionality + normally associated with IMAP. Of course the other capabilities of + + + +Myers & Rose Standards Track [Page 16] + +RFC 1939 POP3 May 1996 + + + IMAP, such as polling an existing connection for newly arrived + messages and supporting multiple folders on the server, are not + present in POP3. + + When these facilities are used in this way by casual users, there has + been a tendency for already-read messages to accumulate on the server + without bound. This is clearly an undesirable behavior pattern from + the standpoint of the server operator. This situation is aggravated + by the fact that the limited capabilities of the POP3 do not permit + efficient handling of maildrops which have hundreds or thousands of + messages. + + Consequently, it is recommended that operators of large-scale multi- + user servers, especially ones in which the user's only access to the + maildrop is via POP3, consider such options as: + + * Imposing a per-user maildrop storage quota or the like. + + A disadvantage to this option is that accumulation of messages may + result in the user's inability to receive new ones into the + maildrop. Sites which choose this option should be sure to inform + users of impending or current exhaustion of quota, perhaps by + inserting an appropriate message into the user's maildrop. + + * Enforce a site policy regarding mail retention on the server. + + Sites are free to establish local policy regarding the storage and + retention of messages on the server, both read and unread. For + example, a site might delete unread messages from the server after + 60 days and delete read messages after 7 days. Such message + deletions are outside the scope of the POP3 protocol and are not + considered a protocol violation. + + Server operators enforcing message deletion policies should take + care to make all users aware of the policies in force. + + Clients must not assume that a site policy will automate message + deletions, and should continue to explicitly delete messages using + the DELE command when appropriate. + + It should be noted that enforcing site message deletion policies + may be confusing to the user community, since their POP3 client + may contain configuration options to leave mail on the server + which will not in fact be supported by the server. + + One special case of a site policy is that messages may only be + downloaded once from the server, and are deleted after this has + been accomplished. This could be implemented in POP3 server + + + +Myers & Rose Standards Track [Page 17] + +RFC 1939 POP3 May 1996 + + + software by the following mechanism: "following a POP3 login by a + client which was ended by a QUIT, delete all messages downloaded + during the session with the RETR command". It is important not to + delete messages in the event of abnormal connection termination + (ie, if no QUIT was received from the client) because the client + may not have successfully received or stored the messages. + Servers implementing a download-and-delete policy may also wish to + disable or limit the optional TOP command, since it could be used + as an alternate mechanism to download entire messages. + +9. POP3 Command Summary + + Minimal POP3 Commands: + + USER name valid in the AUTHORIZATION state + PASS string + QUIT + + STAT valid in the TRANSACTION state + LIST [msg] + RETR msg + DELE msg + NOOP + RSET + QUIT + + Optional POP3 Commands: + + APOP name digest valid in the AUTHORIZATION state + + TOP msg n valid in the TRANSACTION state + UIDL [msg] + + POP3 Replies: + + +OK + -ERR + + Note that with the exception of the STAT, LIST, and UIDL commands, + the reply given by the POP3 server to any command is significant + only to "+OK" and "-ERR". Any text occurring after this reply + may be ignored by the client. + + + + + + + + + +Myers & Rose Standards Track [Page 18] + +RFC 1939 POP3 May 1996 + + +10. Example POP3 Session + + S: + C: + S: +OK POP3 server ready <1896.697170952@dbc.mtview.ca.us> + C: APOP mrose c4c9334bac560ecc979e58001b3e22fb + S: +OK mrose's maildrop has 2 messages (320 octets) + C: STAT + S: +OK 2 320 + C: LIST + S: +OK 2 messages (320 octets) + S: 1 120 + S: 2 200 + S: . + C: RETR 1 + S: +OK 120 octets + S: + S: . + C: DELE 1 + S: +OK message 1 deleted + C: RETR 2 + S: +OK 200 octets + S: + S: . + C: DELE 2 + S: +OK message 2 deleted + C: QUIT + S: +OK dewey POP3 server signing off (maildrop empty) + C: + S: + +11. Message Format + + All messages transmitted during a POP3 session are assumed to conform + to the standard for the format of Internet text messages [RFC822]. + + It is important to note that the octet count for a message on the + server host may differ from the octet count assigned to that message + due to local conventions for designating end-of-line. Usually, + during the AUTHORIZATION state of the POP3 session, the POP3 server + can calculate the size of each message in octets when it opens the + maildrop. For example, if the POP3 server host internally represents + end-of-line as a single character, then the POP3 server simply counts + each occurrence of this character in a message as two octets. Note + that lines in the message which start with the termination octet need + not (and must not) be counted twice, since the POP3 client will + remove all byte-stuffed termination characters when it receives a + multi-line response. + + + +Myers & Rose Standards Track [Page 19] + +RFC 1939 POP3 May 1996 + + +12. References + + [RFC821] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC + 821, USC/Information Sciences Institute, August 1982. + + [RFC822] Crocker, D., "Standard for the Format of ARPA-Internet Text + Messages", STD 11, RFC 822, University of Delaware, August 1982. + + [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, + MIT Laboratory for Computer Science, April 1992. + + [RFC1730] Crispin, M., "Internet Message Access Protocol - Version + 4", RFC 1730, University of Washington, December 1994. + + [RFC1734] Myers, J., "POP3 AUTHentication command", RFC 1734, + Carnegie Mellon, December 1994. + +13. Security Considerations + + It is conjectured that use of the APOP command provides origin + identification and replay protection for a POP3 session. + Accordingly, a POP3 server which implements both the PASS and APOP + commands should not allow both methods of access for a given user; + that is, for a given mailbox name, either the USER/PASS command + sequence or the APOP command is allowed, but not both. + + Further, note that as the length of the shared secret increases, so + does the difficulty of deriving it. + + Servers that answer -ERR to the USER command are giving potential + attackers clues about which names are valid. + + Use of the PASS command sends passwords in the clear over the + network. + + Use of the RETR and TOP commands sends mail in the clear over the + network. + + Otherwise, security issues are not discussed in this memo. + +14. Acknowledgements + + The POP family has a long and checkered history. Although primarily + a minor revision to RFC 1460, POP3 is based on the ideas presented in + RFCs 918, 937, and 1081. + + In addition, Alfred Grimstad, Keith McCloghrie, and Neil Ostroff + provided significant comments on the APOP command. + + + +Myers & Rose Standards Track [Page 20] + +RFC 1939 POP3 May 1996 + + +15. Authors' Addresses + + John G. Myers + Carnegie-Mellon University + 5000 Forbes Ave + Pittsburgh, PA 15213 + + EMail: jgm+@cmu.edu + + + Marshall T. Rose + Dover Beach Consulting, Inc. + 420 Whisman Court + Mountain View, CA 94043-2186 + + EMail: mrose@dbc.mtview.ca.us + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Myers & Rose Standards Track [Page 21] + +RFC 1939 POP3 May 1996 + + +Appendix A. Differences from RFC 1725 + + This memo is a revision to RFC 1725, a Draft Standard. It makes the + following changes from that document: + + - clarifies that command keywords are case insensitive. + + - specifies that servers must send "+OK" and "-ERR" in + upper case. + + - specifies that the initial greeting is a positive response, + instead of any string which should be a positive response. + + - clarifies behavior for unimplemented commands. + + - makes the USER and PASS commands optional. + + - clarified the set of possible responses to the USER command. + + - reverses the order of the examples in the USER and PASS + commands, to reduce confusion. + + - clarifies that the PASS command may only be given immediately + after a successful USER command. + + - clarified the persistence requirements of UIDs and added some + implementation notes. + + - specifies a UID length limitation of one to 70 octets. + + - specifies a status indicator length limitation + of 512 octets, including the CRLF. + + - clarifies that LIST with no arguments on an empty mailbox + returns success. + + - adds a reference from the LIST command to the Message Format + section + + - clarifies the behavior of QUIT upon failure + + - clarifies the security section to not imply the use of the + USER command with the APOP command. + + - adds references to RFCs 1730 and 1734 + + - clarifies the method by which a UA may enter mail into the + transport system. + + + +Myers & Rose Standards Track [Page 22] + +RFC 1939 POP3 May 1996 + + + - clarifies that the second argument to the TOP command is a + number of lines. + + - changes the suggestion in the Security Considerations section + for a server to not accept both PASS and APOP for a given user + from a "must" to a "should". + + - adds a section on scaling and operational considerations + +Appendix B. Command Index + + APOP ....................................................... 15 + DELE ....................................................... 8 + LIST ....................................................... 6 + NOOP ....................................................... 9 + PASS ....................................................... 14 + QUIT ....................................................... 5 + QUIT ....................................................... 10 + RETR ....................................................... 8 + RSET ....................................................... 9 + STAT ....................................................... 6 + TOP ........................................................ 11 + UIDL ....................................................... 12 + USER ....................................................... 13 + + + + + + + + + + + + + + + + + + + + + + + + + + + +Myers & Rose Standards Track [Page 23] + diff --git a/RFCs/rfc196.txt b/RFCs/rfc196.txt new file mode 100644 index 0000000..205db2b --- /dev/null +++ b/RFCs/rfc196.txt @@ -0,0 +1,218 @@ + + + + + + +NETWORK WORKING GROUP Richard W. Watson +Request for Comments #196 SRI-ARC +NIC 7141 July 20, 1971 +Categories: A.5, D.7 +Obsoletes: none +Updates: none + + A MAIL BOX PROTOCOL + +The purpose of this protocol is to provide at each site a +standard mechanism to receive sequential files for immediate or +deferred printing or other uses. The files for deferred printing +would probably be stored on intermediate disk files, although +details of how a file is handled, stored, manipulated, or printed +at a site are not the concern of this protocol. + +It is also assumed that there would be a program at the sending +site which sends the file in the format given below with the +optional control codes when appropriate. This program could +probably be accessed as a subcommand of the Telnet program. + +The motivation for developing this protocol is the Network +Information Center's (NIC) need to be able to deliver messages +and documents to remote sites, and to be able to receive +documents for cataloging, redistribution, and other purposes from +remote site without having to know the details of path name +conventions and file system commands at each site. Multiple mail +boxes (128) are allowed at each site and are identified as +described below. The default is mail box number 0 for use with +the standard mail printer defined below. + +A mail box, as we see it, is simply a sequential file to which +messages and documents are appended, separated by an appropriate +site dependent code. + +Although this protocol will enable people to transmit messages +directly without going through the NIC, we want to encourage +people to use the NIC as much as possible, so that dialogue will +be recorded, cataloged and available for viewing online at NIC, +using the powerful facilities of the ARC on Line System (NLS). + +The Mail Box Protocol will use established network conventions, +specifically the Network Control Program, Initial Connection +Protocol, and Data Transfer Protocol, NIC 7104. + +The normal transmission is to be full 7-bit ASCII in 8-bit bytes, +the high order bit set to zero. + + + + + [Page 1] + +A MAIL BOX PROTOCOL RFC 196 NIC 7141 + +The standard receiving mail printer for mail box number 0 is +assumed to have a print line 72 characters wide, and a page of 66 +lines. The new line convention will be carriage return (X'OD') +followed by line feed (X'OA') as per the Telnet Protocol RFC 158, +NIC 6768. The standard printer will accept form feed (X'OC') as +meaning move paper to the top of a new page. + +It is the senders responsibility to control the length of the +print line and page. If more than 72 characters per line are sent +or if more than 66 lines are sent without a form feed, than the +receiving site can handle these situations as appropriate for +them. These conventions can be changed by control codes as +described below. + +A message or document being sent to any mail box is a string of 8 +bit bytes. + +At the head of the message or document sent to mail box number 0 +there is to be an initial address string terminated by a form +feed. This address string is to contain the sender's name and +address, and the receiver's name and address formatted in some +reasonable, easy-to-read form for a clerk to read and distribute. +Comments could also be included in the address string. + +The format of information in mail boxes other than mail box +number 0 is not explicitly defined by this protocol. + +Initial Connection + + Initial Connection will be as per the Official Initial + Connection Protocol, Documents #2, NIC 7101, to a standard + socket not yet assigned. A candidate socket number would be + socket #5. + +Data Transmission + + Data Transmission will be as per the Data Transfer Protocol, + RFC 171, NIC 6793. That is, there will be a Modes Available + handshake, and then transmission of special control + information and data. A message or document is defined to be a + block of data. Control information is to be global. That is, + once a control mode is set it is assumed to apply during the + + + + + + + + [Page 2] + +A MAIL BOX PROTOCOL RFC 196 NIC 7141 + + life of the connection unless explicitly changed. More than + one document may be sent during the life of the connection + unless the infinite bit stream mode is used. In the latter + case there will be one message or document per connection. A + reasonable convention for control information sent using the + infinite bit stream mode seems to be to assume that is applies + only to the next data stream connection from the host which + sent the control stream. + +Control Information + + The sending process should be capable of allowing the user to + indicate the control codes associated with the transmission of + a mail item. The control codes can be used with any mail box + number. + + Mail Box Number + + A site may find, as is the case at NIC, that it is useful + to have more than one receiving mail box, each to be + associated with a different process. + + The mail box number for material to be printed by the + standard mail printer is mail box number 0 and is used by + default. + + Code X'DO' + + Meaning: A seven bit binary number in an eight bit field + with the high order bit set to zero is to follow + indicating the receiving mail box number. + + Transmission Code Type + + The default code type is 7-bit ASCII in an 8 bit field, + high order bit to zero. + + 'Code X'AO' + + Meaning: A Data Type signal indicating that the + transmission code is 7-bit ASCII in an 8-bit field, high + order set to zero. + + + + + + + + [Page 3] + +A MAIL BOX PROTOCOL RFC 196 NIC 7141 + + Code X'A1' + + Meaning: Transparency, i.e. a stream of 8 bit bytes. + + Code X'A2' + + Meaning: EBCDIC + + Other character codes could be added in the future. + + Printer Control Codes + + The default settings are a print line of 72 characters and + a print page of 66 lines. + + Code X'D1 + + Meaning: Set line width to 72 characters. + + Code X'D2' + + Meaning: Use the full width of your printer. + + Code X'D3' + + Meaning: Set page size to 66 lines. + + Code X'D4' + + Meaning: Set page size to infinite. + + Other virtual printer control codes can be added in the + future. + + Other classes of control codes can be added as the need + arises. + + + + [ This RFC was put into machine readable form for entry ] + [ into the online RFC archives by BBN Corp. under the ] + [ direction of Alex McKenzie. 12/96 ] + + + + + + + + [Page 4] + diff --git a/RFCs/rfc2045.txt b/RFCs/rfc2045.txt new file mode 100644 index 0000000..9f286b1 --- /dev/null +++ b/RFCs/rfc2045.txt @@ -0,0 +1,1739 @@ + + + + + + +Network Working Group N. Freed +Request for Comments: 2045 Innosoft +Obsoletes: 1521, 1522, 1590 N. Borenstein +Category: Standards Track First Virtual + November 1996 + + + Multipurpose Internet Mail Extensions + (MIME) Part One: + Format of Internet Message Bodies + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Abstract + + STD 11, RFC 822, defines a message representation protocol specifying + considerable detail about US-ASCII message headers, and leaves the + message content, or message body, as flat US-ASCII text. This set of + documents, collectively called the Multipurpose Internet Mail + Extensions, or MIME, redefines the format of messages to allow for + + (1) textual message bodies in character sets other than + US-ASCII, + + (2) an extensible set of different formats for non-textual + message bodies, + + (3) multi-part message bodies, and + + (4) textual header information in character sets other than + US-ASCII. + + These documents are based on earlier work documented in RFC 934, STD + 11, and RFC 1049, but extends and revises them. Because RFC 822 said + so little about message bodies, these documents are largely + orthogonal to (rather than a revision of) RFC 822. + + This initial document specifies the various headers used to describe + the structure of MIME messages. The second document, RFC 2046, + defines the general structure of the MIME media typing system and + defines an initial set of media types. The third document, RFC 2047, + describes extensions to RFC 822 to allow non-US-ASCII text data in + + + +Freed & Borenstein Standards Track [Page 1] + +RFC 2045 Internet Message Bodies November 1996 + + + Internet mail header fields. The fourth document, RFC 2048, specifies + various IANA registration procedures for MIME-related facilities. The + fifth and final document, RFC 2049, describes MIME conformance + criteria as well as providing some illustrative examples of MIME + message formats, acknowledgements, and the bibliography. + + These documents are revisions of RFCs 1521, 1522, and 1590, which + themselves were revisions of RFCs 1341 and 1342. An appendix in RFC + 2049 describes differences and changes from previous versions. + +Table of Contents + + 1. Introduction ......................................... 3 + 2. Definitions, Conventions, and Generic BNF Grammar .... 5 + 2.1 CRLF ................................................ 5 + 2.2 Character Set ....................................... 6 + 2.3 Message ............................................. 6 + 2.4 Entity .............................................. 6 + 2.5 Body Part ........................................... 7 + 2.6 Body ................................................ 7 + 2.7 7bit Data ........................................... 7 + 2.8 8bit Data ........................................... 7 + 2.9 Binary Data ......................................... 7 + 2.10 Lines .............................................. 7 + 3. MIME Header Fields ................................... 8 + 4. MIME-Version Header Field ............................ 8 + 5. Content-Type Header Field ............................ 10 + 5.1 Syntax of the Content-Type Header Field ............. 12 + 5.2 Content-Type Defaults ............................... 14 + 6. Content-Transfer-Encoding Header Field ............... 14 + 6.1 Content-Transfer-Encoding Syntax .................... 14 + 6.2 Content-Transfer-Encodings Semantics ................ 15 + 6.3 New Content-Transfer-Encodings ...................... 16 + 6.4 Interpretation and Use .............................. 16 + 6.5 Translating Encodings ............................... 18 + 6.6 Canonical Encoding Model ............................ 19 + 6.7 Quoted-Printable Content-Transfer-Encoding .......... 19 + 6.8 Base64 Content-Transfer-Encoding .................... 24 + 7. Content-ID Header Field .............................. 26 + 8. Content-Description Header Field ..................... 27 + 9. Additional MIME Header Fields ........................ 27 + 10. Summary ............................................. 27 + 11. Security Considerations ............................. 27 + 12. Authors' Addresses .................................. 28 + A. Collected Grammar .................................... 29 + + + + + + +Freed & Borenstein Standards Track [Page 2] + +RFC 2045 Internet Message Bodies November 1996 + + +1. Introduction + + Since its publication in 1982, RFC 822 has defined the standard + format of textual mail messages on the Internet. Its success has + been such that the RFC 822 format has been adopted, wholly or + partially, well beyond the confines of the Internet and the Internet + SMTP transport defined by RFC 821. As the format has seen wider use, + a number of limitations have proven increasingly restrictive for the + user community. + + RFC 822 was intended to specify a format for text messages. As such, + non-text messages, such as multimedia messages that might include + audio or images, are simply not mentioned. Even in the case of text, + however, RFC 822 is inadequate for the needs of mail users whose + languages require the use of character sets richer than US-ASCII. + Since RFC 822 does not specify mechanisms for mail containing audio, + video, Asian language text, or even text in most European languages, + additional specifications are needed. + + One of the notable limitations of RFC 821/822 based mail systems is + the fact that they limit the contents of electronic mail messages to + relatively short lines (e.g. 1000 characters or less [RFC-821]) of + 7bit US-ASCII. This forces users to convert any non-textual data + that they may wish to send into seven-bit bytes representable as + printable US-ASCII characters before invoking a local mail UA (User + Agent, a program with which human users send and receive mail). + Examples of such encodings currently used in the Internet include + pure hexadecimal, uuencode, the 3-in-4 base 64 scheme specified in + RFC 1421, the Andrew Toolkit Representation [ATK], and many others. + + The limitations of RFC 822 mail become even more apparent as gateways + are designed to allow for the exchange of mail messages between RFC + 822 hosts and X.400 hosts. X.400 [X400] specifies mechanisms for the + inclusion of non-textual material within electronic mail messages. + The current standards for the mapping of X.400 messages to RFC 822 + messages specify either that X.400 non-textual material must be + converted to (not encoded in) IA5Text format, or that they must be + discarded, notifying the RFC 822 user that discarding has occurred. + This is clearly undesirable, as information that a user may wish to + receive is lost. Even though a user agent may not have the + capability of dealing with the non-textual material, the user might + have some mechanism external to the UA that can extract useful + information from the material. Moreover, it does not allow for the + fact that the message may eventually be gatewayed back into an X.400 + message handling system (i.e., the X.400 message is "tunneled" + through Internet mail), where the non-textual information would + definitely become useful again. + + + + +Freed & Borenstein Standards Track [Page 3] + +RFC 2045 Internet Message Bodies November 1996 + + + This document describes several mechanisms that combine to solve most + of these problems without introducing any serious incompatibilities + with the existing world of RFC 822 mail. In particular, it + describes: + + (1) A MIME-Version header field, which uses a version + number to declare a message to be conformant with MIME + and allows mail processing agents to distinguish + between such messages and those generated by older or + non-conformant software, which are presumed to lack + such a field. + + (2) A Content-Type header field, generalized from RFC 1049, + which can be used to specify the media type and subtype + of data in the body of a message and to fully specify + the native representation (canonical form) of such + data. + + (3) A Content-Transfer-Encoding header field, which can be + used to specify both the encoding transformation that + was applied to the body and the domain of the result. + Encoding transformations other than the identity + transformation are usually applied to data in order to + allow it to pass through mail transport mechanisms + which may have data or character set limitations. + + (4) Two additional header fields that can be used to + further describe the data in a body, the Content-ID and + Content-Description header fields. + + All of the header fields defined in this document are subject to the + general syntactic rules for header fields specified in RFC 822. In + particular, all of these header fields except for Content-Disposition + can include RFC 822 comments, which have no semantic content and + should be ignored during MIME processing. + + Finally, to specify and promote interoperability, RFC 2049 provides a + basic applicability statement for a subset of the above mechanisms + that defines a minimal level of "conformance" with this document. + + HISTORICAL NOTE: Several of the mechanisms described in this set of + documents may seem somewhat strange or even baroque at first reading. + It is important to note that compatibility with existing standards + AND robustness across existing practice were two of the highest + priorities of the working group that developed this set of documents. + In particular, compatibility was always favored over elegance. + + + + + +Freed & Borenstein Standards Track [Page 4] + +RFC 2045 Internet Message Bodies November 1996 + + + Please refer to the current edition of the "Internet Official + Protocol Standards" for the standardization state and status of this + protocol. RFC 822 and STD 3, RFC 1123 also provide essential + background for MIME since no conforming implementation of MIME can + violate them. In addition, several other informational RFC documents + will be of interest to the MIME implementor, in particular RFC 1344, + RFC 1345, and RFC 1524. + +2. Definitions, Conventions, and Generic BNF Grammar + + Although the mechanisms specified in this set of documents are all + described in prose, most are also described formally in the augmented + BNF notation of RFC 822. Implementors will need to be familiar with + this notation in order to understand this set of documents, and are + referred to RFC 822 for a complete explanation of the augmented BNF + notation. + + Some of the augmented BNF in this set of documents makes named + references to syntax rules defined in RFC 822. A complete formal + grammar, then, is obtained by combining the collected grammar + appendices in each document in this set with the BNF of RFC 822 plus + the modifications to RFC 822 defined in RFC 1123 (which specifically + changes the syntax for `return', `date' and `mailbox'). + + All numeric and octet values are given in decimal notation in this + set of documents. All media type values, subtype values, and + parameter names as defined are case-insensitive. However, parameter + values are case-sensitive unless otherwise specified for the specific + parameter. + + FORMATTING NOTE: Notes, such at this one, provide additional + nonessential information which may be skipped by the reader without + missing anything essential. The primary purpose of these non- + essential notes is to convey information about the rationale of this + set of documents, or to place these documents in the proper + historical or evolutionary context. Such information may in + particular be skipped by those who are focused entirely on building a + conformant implementation, but may be of use to those who wish to + understand why certain design choices were made. + +2.1. CRLF + + The term CRLF, in this set of documents, refers to the sequence of + octets corresponding to the two US-ASCII characters CR (decimal value + 13) and LF (decimal value 10) which, taken together, in this order, + denote a line break in RFC 822 mail. + + + + + +Freed & Borenstein Standards Track [Page 5] + +RFC 2045 Internet Message Bodies November 1996 + + +2.2. Character Set + + The term "character set" is used in MIME to refer to a method of + converting a sequence of octets into a sequence of characters. Note + that unconditional and unambiguous conversion in the other direction + is not required, in that not all characters may be representable by a + given character set and a character set may provide more than one + sequence of octets to represent a particular sequence of characters. + + This definition is intended to allow various kinds of character + encodings, from simple single-table mappings such as US-ASCII to + complex table switching methods such as those that use ISO 2022's + techniques, to be used as character sets. However, the definition + associated with a MIME character set name must fully specify the + mapping to be performed. In particular, use of external profiling + information to determine the exact mapping is not permitted. + + NOTE: The term "character set" was originally to describe such + straightforward schemes as US-ASCII and ISO-8859-1 which have a + simple one-to-one mapping from single octets to single characters. + Multi-octet coded character sets and switching techniques make the + situation more complex. For example, some communities use the term + "character encoding" for what MIME calls a "character set", while + using the phrase "coded character set" to denote an abstract mapping + from integers (not octets) to characters. + +2.3. Message + + The term "message", when not further qualified, means either a + (complete or "top-level") RFC 822 message being transferred on a + network, or a message encapsulated in a body of type "message/rfc822" + or "message/partial". + +2.4. Entity + + The term "entity", refers specifically to the MIME-defined header + fields and contents of either a message or one of the parts in the + body of a multipart entity. The specification of such entities is + the essence of MIME. Since the contents of an entity are often + called the "body", it makes sense to speak about the body of an + entity. Any sort of field may be present in the header of an entity, + but only those fields whose names begin with "content-" actually have + any MIME-related meaning. Note that this does NOT imply thay they + have no meaning at all -- an entity that is also a message has non- + MIME header fields whose meanings are defined by RFC 822. + + + + + + +Freed & Borenstein Standards Track [Page 6] + +RFC 2045 Internet Message Bodies November 1996 + + +2.5. Body Part + + The term "body part" refers to an entity inside of a multipart + entity. + +2.6. Body + + The term "body", when not further qualified, means the body of an + entity, that is, the body of either a message or of a body part. + + NOTE: The previous four definitions are clearly circular. This is + unavoidable, since the overall structure of a MIME message is indeed + recursive. + +2.7. 7bit Data + + "7bit data" refers to data that is all represented as relatively + short lines with 998 octets or less between CRLF line separation + sequences [RFC-821]. No octets with decimal values greater than 127 + are allowed and neither are NULs (octets with decimal value 0). CR + (decimal value 13) and LF (decimal value 10) octets only occur as + part of CRLF line separation sequences. + +2.8. 8bit Data + + "8bit data" refers to data that is all represented as relatively + short lines with 998 octets or less between CRLF line separation + sequences [RFC-821]), but octets with decimal values greater than 127 + may be used. As with "7bit data" CR and LF octets only occur as part + of CRLF line separation sequences and no NULs are allowed. + +2.9. Binary Data + + "Binary data" refers to data where any sequence of octets whatsoever + is allowed. + +2.10. Lines + + "Lines" are defined as sequences of octets separated by a CRLF + sequences. This is consistent with both RFC 821 and RFC 822. + "Lines" only refers to a unit of data in a message, which may or may + not correspond to something that is actually displayed by a user + agent. + + + + + + + + +Freed & Borenstein Standards Track [Page 7] + +RFC 2045 Internet Message Bodies November 1996 + + +3. MIME Header Fields + + MIME defines a number of new RFC 822 header fields that are used to + describe the content of a MIME entity. These header fields occur in + at least two contexts: + + (1) As part of a regular RFC 822 message header. + + (2) In a MIME body part header within a multipart + construct. + + The formal definition of these header fields is as follows: + + entity-headers := [ content CRLF ] + [ encoding CRLF ] + [ id CRLF ] + [ description CRLF ] + *( MIME-extension-field CRLF ) + + MIME-message-headers := entity-headers + fields + version CRLF + ; The ordering of the header + ; fields implied by this BNF + ; definition should be ignored. + + MIME-part-headers := entity-headers + [ fields ] + ; Any field not beginning with + ; "content-" can have no defined + ; meaning and may be ignored. + ; The ordering of the header + ; fields implied by this BNF + ; definition should be ignored. + + The syntax of the various specific MIME header fields will be + described in the following sections. + +4. MIME-Version Header Field + + Since RFC 822 was published in 1982, there has really been only one + format standard for Internet messages, and there has been little + perceived need to declare the format standard in use. This document + is an independent specification that complements RFC 822. Although + the extensions in this document have been defined in such a way as to + be compatible with RFC 822, there are still circumstances in which it + might be desirable for a mail-processing agent to know whether a + message was composed with the new standard in mind. + + + +Freed & Borenstein Standards Track [Page 8] + +RFC 2045 Internet Message Bodies November 1996 + + + Therefore, this document defines a new header field, "MIME-Version", + which is to be used to declare the version of the Internet message + body format standard in use. + + Messages composed in accordance with this document MUST include such + a header field, with the following verbatim text: + + MIME-Version: 1.0 + + The presence of this header field is an assertion that the message + has been composed in compliance with this document. + + Since it is possible that a future document might extend the message + format standard again, a formal BNF is given for the content of the + MIME-Version field: + + version := "MIME-Version" ":" 1*DIGIT "." 1*DIGIT + + Thus, future format specifiers, which might replace or extend "1.0", + are constrained to be two integer fields, separated by a period. If + a message is received with a MIME-version value other than "1.0", it + cannot be assumed to conform with this document. + + Note that the MIME-Version header field is required at the top level + of a message. It is not required for each body part of a multipart + entity. It is required for the embedded headers of a body of type + "message/rfc822" or "message/partial" if and only if the embedded + message is itself claimed to be MIME-conformant. + + It is not possible to fully specify how a mail reader that conforms + with MIME as defined in this document should treat a message that + might arrive in the future with some value of MIME-Version other than + "1.0". + + It is also worth noting that version control for specific media types + is not accomplished using the MIME-Version mechanism. In particular, + some formats (such as application/postscript) have version numbering + conventions that are internal to the media format. Where such + conventions exist, MIME does nothing to supersede them. Where no + such conventions exist, a MIME media type might use a "version" + parameter in the content-type field if necessary. + + + + + + + + + + +Freed & Borenstein Standards Track [Page 9] + +RFC 2045 Internet Message Bodies November 1996 + + + NOTE TO IMPLEMENTORS: When checking MIME-Version values any RFC 822 + comment strings that are present must be ignored. In particular, the + following four MIME-Version fields are equivalent: + + MIME-Version: 1.0 + + MIME-Version: 1.0 (produced by MetaSend Vx.x) + + MIME-Version: (produced by MetaSend Vx.x) 1.0 + + MIME-Version: 1.(produced by MetaSend Vx.x)0 + + In the absence of a MIME-Version field, a receiving mail user agent + (whether conforming to MIME requirements or not) may optionally + choose to interpret the body of the message according to local + conventions. Many such conventions are currently in use and it + should be noted that in practice non-MIME messages can contain just + about anything. + + It is impossible to be certain that a non-MIME mail message is + actually plain text in the US-ASCII character set since it might well + be a message that, using some set of nonstandard local conventions + that predate MIME, includes text in another character set or non- + textual data presented in a manner that cannot be automatically + recognized (e.g., a uuencoded compressed UNIX tar file). + +5. Content-Type Header Field + + The purpose of the Content-Type field is to describe the data + contained in the body fully enough that the receiving user agent can + pick an appropriate agent or mechanism to present the data to the + user, or otherwise deal with the data in an appropriate manner. The + value in this field is called a media type. + + HISTORICAL NOTE: The Content-Type header field was first defined in + RFC 1049. RFC 1049 used a simpler and less powerful syntax, but one + that is largely compatible with the mechanism given here. + + The Content-Type header field specifies the nature of the data in the + body of an entity by giving media type and subtype identifiers, and + by providing auxiliary information that may be required for certain + media types. After the media type and subtype names, the remainder + of the header field is simply a set of parameters, specified in an + attribute=value notation. The ordering of parameters is not + significant. + + + + + + +Freed & Borenstein Standards Track [Page 10] + +RFC 2045 Internet Message Bodies November 1996 + + + In general, the top-level media type is used to declare the general + type of data, while the subtype specifies a specific format for that + type of data. Thus, a media type of "image/xyz" is enough to tell a + user agent that the data is an image, even if the user agent has no + knowledge of the specific image format "xyz". Such information can + be used, for example, to decide whether or not to show a user the raw + data from an unrecognized subtype -- such an action might be + reasonable for unrecognized subtypes of text, but not for + unrecognized subtypes of image or audio. For this reason, registered + subtypes of text, image, audio, and video should not contain embedded + information that is really of a different type. Such compound + formats should be represented using the "multipart" or "application" + types. + + Parameters are modifiers of the media subtype, and as such do not + fundamentally affect the nature of the content. The set of + meaningful parameters depends on the media type and subtype. Most + parameters are associated with a single specific subtype. However, a + given top-level media type may define parameters which are applicable + to any subtype of that type. Parameters may be required by their + defining content type or subtype or they may be optional. MIME + implementations must ignore any parameters whose names they do not + recognize. + + For example, the "charset" parameter is applicable to any subtype of + "text", while the "boundary" parameter is required for any subtype of + the "multipart" media type. + + There are NO globally-meaningful parameters that apply to all media + types. Truly global mechanisms are best addressed, in the MIME + model, by the definition of additional Content-* header fields. + + An initial set of seven top-level media types is defined in RFC 2046. + Five of these are discrete types whose content is essentially opaque + as far as MIME processing is concerned. The remaining two are + composite types whose contents require additional handling by MIME + processors. + + This set of top-level media types is intended to be substantially + complete. It is expected that additions to the larger set of + supported types can generally be accomplished by the creation of new + subtypes of these initial types. In the future, more top-level types + may be defined only by a standards-track extension to this standard. + If another top-level type is to be used for any reason, it must be + given a name starting with "X-" to indicate its non-standard status + and to avoid a potential conflict with a future official name. + + + + + +Freed & Borenstein Standards Track [Page 11] + +RFC 2045 Internet Message Bodies November 1996 + + +5.1. Syntax of the Content-Type Header Field + + In the Augmented BNF notation of RFC 822, a Content-Type header field + value is defined as follows: + + content := "Content-Type" ":" type "/" subtype + *(";" parameter) + ; Matching of media type and subtype + ; is ALWAYS case-insensitive. + + type := discrete-type / composite-type + + discrete-type := "text" / "image" / "audio" / "video" / + "application" / extension-token + + composite-type := "message" / "multipart" / extension-token + + extension-token := ietf-token / x-token + + ietf-token := + + x-token := + + subtype := extension-token / iana-token + + iana-token := + + parameter := attribute "=" value + + attribute := token + ; Matching of attributes + ; is ALWAYS case-insensitive. + + value := token / quoted-string + + token := 1* + + tspecials := "(" / ")" / "<" / ">" / "@" / + "," / ";" / ":" / "\" / <"> + "/" / "[" / "]" / "?" / "=" + ; Must be in quoted-string, + ; to use within parameter values + + + +Freed & Borenstein Standards Track [Page 12] + +RFC 2045 Internet Message Bodies November 1996 + + + Note that the definition of "tspecials" is the same as the RFC 822 + definition of "specials" with the addition of the three characters + "/", "?", and "=", and the removal of ".". + + Note also that a subtype specification is MANDATORY -- it may not be + omitted from a Content-Type header field. As such, there are no + default subtypes. + + The type, subtype, and parameter names are not case sensitive. For + example, TEXT, Text, and TeXt are all equivalent top-level media + types. Parameter values are normally case sensitive, but sometimes + are interpreted in a case-insensitive fashion, depending on the + intended use. (For example, multipart boundaries are case-sensitive, + but the "access-type" parameter for message/External-body is not + case-sensitive.) + + Note that the value of a quoted string parameter does not include the + quotes. That is, the quotation marks in a quoted-string are not a + part of the value of the parameter, but are merely used to delimit + that parameter value. In addition, comments are allowed in + accordance with RFC 822 rules for structured header fields. Thus the + following two forms + + Content-type: text/plain; charset=us-ascii (Plain text) + + Content-type: text/plain; charset="us-ascii" + + are completely equivalent. + + Beyond this syntax, the only syntactic constraint on the definition + of subtype names is the desire that their uses must not conflict. + That is, it would be undesirable to have two different communities + using "Content-Type: application/foobar" to mean two different + things. The process of defining new media subtypes, then, is not + intended to be a mechanism for imposing restrictions, but simply a + mechanism for publicizing their definition and usage. There are, + therefore, two acceptable mechanisms for defining new media subtypes: + + (1) Private values (starting with "X-") may be defined + bilaterally between two cooperating agents without + outside registration or standardization. Such values + cannot be registered or standardized. + + (2) New standard values should be registered with IANA as + described in RFC 2048. + + The second document in this set, RFC 2046, defines the initial set of + media types for MIME. + + + +Freed & Borenstein Standards Track [Page 13] + +RFC 2045 Internet Message Bodies November 1996 + + +5.2. Content-Type Defaults + + Default RFC 822 messages without a MIME Content-Type header are taken + by this protocol to be plain text in the US-ASCII character set, + which can be explicitly specified as: + + Content-type: text/plain; charset=us-ascii + + This default is assumed if no Content-Type header field is specified. + It is also recommend that this default be assumed when a + syntactically invalid Content-Type header field is encountered. In + the presence of a MIME-Version header field and the absence of any + Content-Type header field, a receiving User Agent can also assume + that plain US-ASCII text was the sender's intent. Plain US-ASCII + text may still be assumed in the absence of a MIME-Version or the + presence of an syntactically invalid Content-Type header field, but + the sender's intent might have been otherwise. + +6. Content-Transfer-Encoding Header Field + + Many media types which could be usefully transported via email are + represented, in their "natural" format, as 8bit character or binary + data. Such data cannot be transmitted over some transfer protocols. + For example, RFC 821 (SMTP) restricts mail messages to 7bit US-ASCII + data with lines no longer than 1000 characters including any trailing + CRLF line separator. + + It is necessary, therefore, to define a standard mechanism for + encoding such data into a 7bit short line format. Proper labelling + of unencoded material in less restrictive formats for direct use over + less restrictive transports is also desireable. This document + specifies that such encodings will be indicated by a new "Content- + Transfer-Encoding" header field. This field has not been defined by + any previous standard. + +6.1. Content-Transfer-Encoding Syntax + + The Content-Transfer-Encoding field's value is a single token + specifying the type of encoding, as enumerated below. Formally: + + encoding := "Content-Transfer-Encoding" ":" mechanism + + mechanism := "7bit" / "8bit" / "binary" / + "quoted-printable" / "base64" / + ietf-token / x-token + + These values are not case sensitive -- Base64 and BASE64 and bAsE64 + are all equivalent. An encoding type of 7BIT requires that the body + + + +Freed & Borenstein Standards Track [Page 14] + +RFC 2045 Internet Message Bodies November 1996 + + + is already in a 7bit mail-ready representation. This is the default + value -- that is, "Content-Transfer-Encoding: 7BIT" is assumed if the + Content-Transfer-Encoding header field is not present. + +6.2. Content-Transfer-Encodings Semantics + + This single Content-Transfer-Encoding token actually provides two + pieces of information. It specifies what sort of encoding + transformation the body was subjected to and hence what decoding + operation must be used to restore it to its original form, and it + specifies what the domain of the result is. + + The transformation part of any Content-Transfer-Encodings specifies, + either explicitly or implicitly, a single, well-defined decoding + algorithm, which for any sequence of encoded octets either transforms + it to the original sequence of octets which was encoded, or shows + that it is illegal as an encoded sequence. Content-Transfer- + Encodings transformations never depend on any additional external + profile information for proper operation. Note that while decoders + must produce a single, well-defined output for a valid encoding no + such restrictions exist for encoders: Encoding a given sequence of + octets to different, equivalent encoded sequences is perfectly legal. + + Three transformations are currently defined: identity, the "quoted- + printable" encoding, and the "base64" encoding. The domains are + "binary", "8bit" and "7bit". + + The Content-Transfer-Encoding values "7bit", "8bit", and "binary" all + mean that the identity (i.e. NO) encoding transformation has been + performed. As such, they serve simply as indicators of the domain of + the body data, and provide useful information about the sort of + encoding that might be needed for transmission in a given transport + system. The terms "7bit data", "8bit data", and "binary data" are + all defined in Section 2. + + The quoted-printable and base64 encodings transform their input from + an arbitrary domain into material in the "7bit" range, thus making it + safe to carry over restricted transports. The specific definition of + the transformations are given below. + + The proper Content-Transfer-Encoding label must always be used. + Labelling unencoded data containing 8bit characters as "7bit" is not + allowed, nor is labelling unencoded non-line-oriented data as + anything other than "binary" allowed. + + Unlike media subtypes, a proliferation of Content-Transfer-Encoding + values is both undesirable and unnecessary. However, establishing + only a single transformation into the "7bit" domain does not seem + + + +Freed & Borenstein Standards Track [Page 15] + +RFC 2045 Internet Message Bodies November 1996 + + + possible. There is a tradeoff between the desire for a compact and + efficient encoding of largely- binary data and the desire for a + somewhat readable encoding of data that is mostly, but not entirely, + 7bit. For this reason, at least two encoding mechanisms are + necessary: a more or less readable encoding (quoted-printable) and a + "dense" or "uniform" encoding (base64). + + Mail transport for unencoded 8bit data is defined in RFC 1652. As of + the initial publication of this document, there are no standardized + Internet mail transports for which it is legitimate to include + unencoded binary data in mail bodies. Thus there are no + circumstances in which the "binary" Content-Transfer-Encoding is + actually valid in Internet mail. However, in the event that binary + mail transport becomes a reality in Internet mail, or when MIME is + used in conjunction with any other binary-capable mail transport + mechanism, binary bodies must be labelled as such using this + mechanism. + + NOTE: The five values defined for the Content-Transfer-Encoding field + imply nothing about the media type other than the algorithm by which + it was encoded or the transport system requirements if unencoded. + +6.3. New Content-Transfer-Encodings + + Implementors may, if necessary, define private Content-Transfer- + Encoding values, but must use an x-token, which is a name prefixed by + "X-", to indicate its non-standard status, e.g., "Content-Transfer- + Encoding: x-my-new-encoding". Additional standardized Content- + Transfer-Encoding values must be specified by a standards-track RFC. + The requirements such specifications must meet are given in RFC 2048. + As such, all content-transfer-encoding namespace except that + beginning with "X-" is explicitly reserved to the IETF for future + use. + + Unlike media types and subtypes, the creation of new Content- + Transfer-Encoding values is STRONGLY discouraged, as it seems likely + to hinder interoperability with little potential benefit + +6.4. Interpretation and Use + + If a Content-Transfer-Encoding header field appears as part of a + message header, it applies to the entire body of that message. If a + Content-Transfer-Encoding header field appears as part of an entity's + headers, it applies only to the body of that entity. If an entity is + of type "multipart" the Content-Transfer-Encoding is not permitted to + have any value other than "7bit", "8bit" or "binary". Even more + severe restrictions apply to some subtypes of the "message" type. + + + + +Freed & Borenstein Standards Track [Page 16] + +RFC 2045 Internet Message Bodies November 1996 + + + It should be noted that most media types are defined in terms of + octets rather than bits, so that the mechanisms described here are + mechanisms for encoding arbitrary octet streams, not bit streams. If + a bit stream is to be encoded via one of these mechanisms, it must + first be converted to an 8bit byte stream using the network standard + bit order ("big-endian"), in which the earlier bits in a stream + become the higher-order bits in a 8bit byte. A bit stream not ending + at an 8bit boundary must be padded with zeroes. RFC 2046 provides a + mechanism for noting the addition of such padding in the case of the + application/octet-stream media type, which has a "padding" parameter. + + The encoding mechanisms defined here explicitly encode all data in + US-ASCII. Thus, for example, suppose an entity has header fields + such as: + + Content-Type: text/plain; charset=ISO-8859-1 + Content-transfer-encoding: base64 + + This must be interpreted to mean that the body is a base64 US-ASCII + encoding of data that was originally in ISO-8859-1, and will be in + that character set again after decoding. + + Certain Content-Transfer-Encoding values may only be used on certain + media types. In particular, it is EXPRESSLY FORBIDDEN to use any + encodings other than "7bit", "8bit", or "binary" with any composite + media type, i.e. one that recursively includes other Content-Type + fields. Currently the only composite media types are "multipart" and + "message". All encodings that are desired for bodies of type + multipart or message must be done at the innermost level, by encoding + the actual body that needs to be encoded. + + It should also be noted that, by definition, if a composite entity + has a transfer-encoding value such as "7bit", but one of the enclosed + entities has a less restrictive value such as "8bit", then either the + outer "7bit" labelling is in error, because 8bit data are included, + or the inner "8bit" labelling placed an unnecessarily high demand on + the transport system because the actual included data were actually + 7bit-safe. + + NOTE ON ENCODING RESTRICTIONS: Though the prohibition against using + content-transfer-encodings on composite body data may seem overly + restrictive, it is necessary to prevent nested encodings, in which + data are passed through an encoding algorithm multiple times, and + must be decoded multiple times in order to be properly viewed. + Nested encodings add considerable complexity to user agents: Aside + from the obvious efficiency problems with such multiple encodings, + they can obscure the basic structure of a message. In particular, + they can imply that several decoding operations are necessary simply + + + +Freed & Borenstein Standards Track [Page 17] + +RFC 2045 Internet Message Bodies November 1996 + + + to find out what types of bodies a message contains. Banning nested + encodings may complicate the job of certain mail gateways, but this + seems less of a problem than the effect of nested encodings on user + agents. + + Any entity with an unrecognized Content-Transfer-Encoding must be + treated as if it has a Content-Type of "application/octet-stream", + regardless of what the Content-Type header field actually says. + + NOTE ON THE RELATIONSHIP BETWEEN CONTENT-TYPE AND CONTENT-TRANSFER- + ENCODING: It may seem that the Content-Transfer-Encoding could be + inferred from the characteristics of the media that is to be encoded, + or, at the very least, that certain Content-Transfer-Encodings could + be mandated for use with specific media types. There are several + reasons why this is not the case. First, given the varying types of + transports used for mail, some encodings may be appropriate for some + combinations of media types and transports but not for others. (For + example, in an 8bit transport, no encoding would be required for text + in certain character sets, while such encodings are clearly required + for 7bit SMTP.) + + Second, certain media types may require different types of transfer + encoding under different circumstances. For example, many PostScript + bodies might consist entirely of short lines of 7bit data and hence + require no encoding at all. Other PostScript bodies (especially + those using Level 2 PostScript's binary encoding mechanism) may only + be reasonably represented using a binary transport encoding. + Finally, since the Content-Type field is intended to be an open-ended + specification mechanism, strict specification of an association + between media types and encodings effectively couples the + specification of an application protocol with a specific lower-level + transport. This is not desirable since the developers of a media + type should not have to be aware of all the transports in use and + what their limitations are. + +6.5. Translating Encodings + + The quoted-printable and base64 encodings are designed so that + conversion between them is possible. The only issue that arises in + such a conversion is the handling of hard line breaks in quoted- + printable encoding output. When converting from quoted-printable to + base64 a hard line break in the quoted-printable form represents a + CRLF sequence in the canonical form of the data. It must therefore be + converted to a corresponding encoded CRLF in the base64 form of the + data. Similarly, a CRLF sequence in the canonical form of the data + obtained after base64 decoding must be converted to a quoted- + printable hard line break, but ONLY when converting text data. + + + + +Freed & Borenstein Standards Track [Page 18] + +RFC 2045 Internet Message Bodies November 1996 + + +6.6. Canonical Encoding Model + + There was some confusion, in the previous versions of this RFC, + regarding the model for when email data was to be converted to + canonical form and encoded, and in particular how this process would + affect the treatment of CRLFs, given that the representation of + newlines varies greatly from system to system, and the relationship + between content-transfer-encodings and character sets. A canonical + model for encoding is presented in RFC 2049 for this reason. + +6.7. Quoted-Printable Content-Transfer-Encoding + + The Quoted-Printable encoding is intended to represent data that + largely consists of octets that correspond to printable characters in + the US-ASCII character set. It encodes the data in such a way that + the resulting octets are unlikely to be modified by mail transport. + If the data being encoded are mostly US-ASCII text, the encoded form + of the data remains largely recognizable by humans. A body which is + entirely US-ASCII may also be encoded in Quoted-Printable to ensure + the integrity of the data should the message pass through a + character-translating, and/or line-wrapping gateway. + + In this encoding, octets are to be represented as determined by the + following rules: + + (1) (General 8bit representation) Any octet, except a CR or + LF that is part of a CRLF line break of the canonical + (standard) form of the data being encoded, may be + represented by an "=" followed by a two digit + hexadecimal representation of the octet's value. The + digits of the hexadecimal alphabet, for this purpose, + are "0123456789ABCDEF". Uppercase letters must be + used; lowercase letters are not allowed. Thus, for + example, the decimal value 12 (US-ASCII form feed) can + be represented by "=0C", and the decimal value 61 (US- + ASCII EQUAL SIGN) can be represented by "=3D". This + rule must be followed except when the following rules + allow an alternative encoding. + + (2) (Literal representation) Octets with decimal values of + 33 through 60 inclusive, and 62 through 126, inclusive, + MAY be represented as the US-ASCII characters which + correspond to those octets (EXCLAMATION POINT through + LESS THAN, and GREATER THAN through TILDE, + respectively). + + (3) (White Space) Octets with values of 9 and 32 MAY be + represented as US-ASCII TAB (HT) and SPACE characters, + + + +Freed & Borenstein Standards Track [Page 19] + +RFC 2045 Internet Message Bodies November 1996 + + + respectively, but MUST NOT be so represented at the end + of an encoded line. Any TAB (HT) or SPACE characters + on an encoded line MUST thus be followed on that line + by a printable character. In particular, an "=" at the + end of an encoded line, indicating a soft line break + (see rule #5) may follow one or more TAB (HT) or SPACE + characters. It follows that an octet with decimal + value 9 or 32 appearing at the end of an encoded line + must be represented according to Rule #1. This rule is + necessary because some MTAs (Message Transport Agents, + programs which transport messages from one user to + another, or perform a portion of such transfers) are + known to pad lines of text with SPACEs, and others are + known to remove "white space" characters from the end + of a line. Therefore, when decoding a Quoted-Printable + body, any trailing white space on a line must be + deleted, as it will necessarily have been added by + intermediate transport agents. + + (4) (Line Breaks) A line break in a text body, represented + as a CRLF sequence in the text canonical form, must be + represented by a (RFC 822) line break, which is also a + CRLF sequence, in the Quoted-Printable encoding. Since + the canonical representation of media types other than + text do not generally include the representation of + line breaks as CRLF sequences, no hard line breaks + (i.e. line breaks that are intended to be meaningful + and to be displayed to the user) can occur in the + quoted-printable encoding of such types. Sequences + like "=0D", "=0A", "=0A=0D" and "=0D=0A" will routinely + appear in non-text data represented in quoted- + printable, of course. + + Note that many implementations may elect to encode the + local representation of various content types directly + rather than converting to canonical form first, + encoding, and then converting back to local + representation. In particular, this may apply to plain + text material on systems that use newline conventions + other than a CRLF terminator sequence. Such an + implementation optimization is permissible, but only + when the combined canonicalization-encoding step is + equivalent to performing the three steps separately. + + (5) (Soft Line Breaks) The Quoted-Printable encoding + REQUIRES that encoded lines be no more than 76 + characters long. If longer lines are to be encoded + with the Quoted-Printable encoding, "soft" line breaks + + + +Freed & Borenstein Standards Track [Page 20] + +RFC 2045 Internet Message Bodies November 1996 + + + must be used. An equal sign as the last character on a + encoded line indicates such a non-significant ("soft") + line break in the encoded text. + + Thus if the "raw" form of the line is a single unencoded line that + says: + + Now's the time for all folk to come to the aid of their country. + + This can be represented, in the Quoted-Printable encoding, as: + + Now's the time = + for all folk to come= + to the aid of their country. + + This provides a mechanism with which long lines are encoded in such a + way as to be restored by the user agent. The 76 character limit does + not count the trailing CRLF, but counts all other characters, + including any equal signs. + + Since the hyphen character ("-") may be represented as itself in the + Quoted-Printable encoding, care must be taken, when encapsulating a + quoted-printable encoded body inside one or more multipart entities, + to ensure that the boundary delimiter does not appear anywhere in the + encoded body. (A good strategy is to choose a boundary that includes + a character sequence such as "=_" which can never appear in a + quoted-printable body. See the definition of multipart messages in + RFC 2046.) + + NOTE: The quoted-printable encoding represents something of a + compromise between readability and reliability in transport. Bodies + encoded with the quoted-printable encoding will work reliably over + most mail gateways, but may not work perfectly over a few gateways, + notably those involving translation into EBCDIC. A higher level of + confidence is offered by the base64 Content-Transfer-Encoding. A way + to get reasonably reliable transport through EBCDIC gateways is to + also quote the US-ASCII characters + + !"#$@[\]^`{|}~ + + according to rule #1. + + Because quoted-printable data is generally assumed to be line- + oriented, it is to be expected that the representation of the breaks + between the lines of quoted-printable data may be altered in + transport, in the same manner that plain text mail has always been + altered in Internet mail when passing between systems with differing + newline conventions. If such alterations are likely to constitute a + + + +Freed & Borenstein Standards Track [Page 21] + +RFC 2045 Internet Message Bodies November 1996 + + + corruption of the data, it is probably more sensible to use the + base64 encoding rather than the quoted-printable encoding. + + NOTE: Several kinds of substrings cannot be generated according to + the encoding rules for the quoted-printable content-transfer- + encoding, and hence are formally illegal if they appear in the output + of a quoted-printable encoder. This note enumerates these cases and + suggests ways to handle such illegal substrings if any are + encountered in quoted-printable data that is to be decoded. + + (1) An "=" followed by two hexadecimal digits, one or both + of which are lowercase letters in "abcdef", is formally + illegal. A robust implementation might choose to + recognize them as the corresponding uppercase letters. + + (2) An "=" followed by a character that is neither a + hexadecimal digit (including "abcdef") nor the CR + character of a CRLF pair is illegal. This case can be + the result of US-ASCII text having been included in a + quoted-printable part of a message without itself + having been subjected to quoted-printable encoding. A + reasonable approach by a robust implementation might be + to include the "=" character and the following + character in the decoded data without any + transformation and, if possible, indicate to the user + that proper decoding was not possible at this point in + the data. + + (3) An "=" cannot be the ultimate or penultimate character + in an encoded object. This could be handled as in case + (2) above. + + (4) Control characters other than TAB, or CR and LF as + parts of CRLF pairs, must not appear. The same is true + for octets with decimal values greater than 126. If + found in incoming quoted-printable data by a decoder, a + robust implementation might exclude them from the + decoded data and warn the user that illegal characters + were discovered. + + (5) Encoded lines must not be longer than 76 characters, + not counting the trailing CRLF. If longer lines are + found in incoming, encoded data, a robust + implementation might nevertheless decode the lines, and + might report the erroneous encoding to the user. + + + + + + +Freed & Borenstein Standards Track [Page 22] + +RFC 2045 Internet Message Bodies November 1996 + + + WARNING TO IMPLEMENTORS: If binary data is encoded in quoted- + printable, care must be taken to encode CR and LF characters as "=0D" + and "=0A", respectively. In particular, a CRLF sequence in binary + data should be encoded as "=0D=0A". Otherwise, if CRLF were + represented as a hard line break, it might be incorrectly decoded on + platforms with different line break conventions. + + For formalists, the syntax of quoted-printable data is described by + the following grammar: + + quoted-printable := qp-line *(CRLF qp-line) + + qp-line := *(qp-segment transport-padding CRLF) + qp-part transport-padding + + qp-part := qp-section + ; Maximum length of 76 characters + + qp-segment := qp-section *(SPACE / TAB) "=" + ; Maximum length of 76 characters + + qp-section := [*(ptext / SPACE / TAB) ptext] + + ptext := hex-octet / safe-char + + safe-char := + ; Characters not listed as "mail-safe" in + ; RFC 2049 are also not recommended. + + hex-octet := "=" 2(DIGIT / "A" / "B" / "C" / "D" / "E" / "F") + ; Octet must be used for characters > 127, =, + ; SPACEs or TABs at the ends of lines, and is + ; recommended for any character not listed in + ; RFC 2049 as "mail-safe". + + transport-padding := *LWSP-char + ; Composers MUST NOT generate + ; non-zero length transport + ; padding, but receivers MUST + ; be able to handle padding + ; added by message transports. + + IMPORTANT: The addition of LWSP between the elements shown in this + BNF is NOT allowed since this BNF does not specify a structured + header field. + + + + + +Freed & Borenstein Standards Track [Page 23] + +RFC 2045 Internet Message Bodies November 1996 + + +6.8. Base64 Content-Transfer-Encoding + + The Base64 Content-Transfer-Encoding is designed to represent + arbitrary sequences of octets in a form that need not be humanly + readable. The encoding and decoding algorithms are simple, but the + encoded data are consistently only about 33 percent larger than the + unencoded data. This encoding is virtually identical to the one used + in Privacy Enhanced Mail (PEM) applications, as defined in RFC 1421. + + A 65-character subset of US-ASCII is used, enabling 6 bits to be + represented per printable character. (The extra 65th character, "=", + is used to signify a special processing function.) + + NOTE: This subset has the important property that it is represented + identically in all versions of ISO 646, including US-ASCII, and all + characters in the subset are also represented identically in all + versions of EBCDIC. Other popular encodings, such as the encoding + used by the uuencode utility, Macintosh binhex 4.0 [RFC-1741], and + the base85 encoding specified as part of Level 2 PostScript, do not + share these properties, and thus do not fulfill the portability + requirements a binary transport encoding for mail must meet. + + The encoding process represents 24-bit groups of input bits as output + strings of 4 encoded characters. Proceeding from left to right, a + 24-bit input group is formed by concatenating 3 8bit input groups. + These 24 bits are then treated as 4 concatenated 6-bit groups, each + of which is translated into a single digit in the base64 alphabet. + When encoding a bit stream via the base64 encoding, the bit stream + must be presumed to be ordered with the most-significant-bit first. + That is, the first bit in the stream will be the high-order bit in + the first 8bit byte, and the eighth bit will be the low-order bit in + the first 8bit byte, and so on. + + Each 6-bit group is used as an index into an array of 64 printable + characters. The character referenced by the index is placed in the + output string. These characters, identified in Table 1, below, are + selected so as to be universally representable, and the set excludes + characters with particular significance to SMTP (e.g., ".", CR, LF) + and to the multipart boundary delimiters defined in RFC 2046 (e.g., + "-"). + + + + + + + + + + + +Freed & Borenstein Standards Track [Page 24] + +RFC 2045 Internet Message Bodies November 1996 + + + Table 1: The Base64 Alphabet + + Value Encoding Value Encoding Value Encoding Value Encoding + 0 A 17 R 34 i 51 z + 1 B 18 S 35 j 52 0 + 2 C 19 T 36 k 53 1 + 3 D 20 U 37 l 54 2 + 4 E 21 V 38 m 55 3 + 5 F 22 W 39 n 56 4 + 6 G 23 X 40 o 57 5 + 7 H 24 Y 41 p 58 6 + 8 I 25 Z 42 q 59 7 + 9 J 26 a 43 r 60 8 + 10 K 27 b 44 s 61 9 + 11 L 28 c 45 t 62 + + 12 M 29 d 46 u 63 / + 13 N 30 e 47 v + 14 O 31 f 48 w (pad) = + 15 P 32 g 49 x + 16 Q 33 h 50 y + + The encoded output stream must be represented in lines of no more + than 76 characters each. All line breaks or other characters not + found in Table 1 must be ignored by decoding software. In base64 + data, characters other than those in Table 1, line breaks, and other + white space probably indicate a transmission error, about which a + warning message or even a message rejection might be appropriate + under some circumstances. + + Special processing is performed if fewer than 24 bits are available + at the end of the data being encoded. A full encoding quantum is + always completed at the end of a body. When fewer than 24 input bits + are available in an input group, zero bits are added (on the right) + to form an integral number of 6-bit groups. Padding at the end of + the data is performed using the "=" character. Since all base64 + input is an integral number of octets, only the following cases can + arise: (1) the final quantum of encoding input is an integral + multiple of 24 bits; here, the final unit of encoded output will be + an integral multiple of 4 characters with no "=" padding, (2) the + final quantum of encoding input is exactly 8 bits; here, the final + unit of encoded output will be two characters followed by two "=" + padding characters, or (3) the final quantum of encoding input is + exactly 16 bits; here, the final unit of encoded output will be three + characters followed by one "=" padding character. + + Because it is used only for padding at the end of the data, the + occurrence of any "=" characters may be taken as evidence that the + end of the data has been reached (without truncation in transit). No + + + +Freed & Borenstein Standards Track [Page 25] + +RFC 2045 Internet Message Bodies November 1996 + + + such assurance is possible, however, when the number of octets + transmitted was a multiple of three and no "=" characters are + present. + + Any characters outside of the base64 alphabet are to be ignored in + base64-encoded data. + + Care must be taken to use the proper octets for line breaks if base64 + encoding is applied directly to text material that has not been + converted to canonical form. In particular, text line breaks must be + converted into CRLF sequences prior to base64 encoding. The + important thing to note is that this may be done directly by the + encoder rather than in a prior canonicalization step in some + implementations. + + NOTE: There is no need to worry about quoting potential boundary + delimiters within base64-encoded bodies within multipart entities + because no hyphen characters are used in the base64 encoding. + +7. Content-ID Header Field + + In constructing a high-level user agent, it may be desirable to allow + one body to make reference to another. Accordingly, bodies may be + labelled using the "Content-ID" header field, which is syntactically + identical to the "Message-ID" header field: + + id := "Content-ID" ":" msg-id + + Like the Message-ID values, Content-ID values must be generated to be + world-unique. + + The Content-ID value may be used for uniquely identifying MIME + entities in several contexts, particularly for caching data + referenced by the message/external-body mechanism. Although the + Content-ID header is generally optional, its use is MANDATORY in + implementations which generate data of the optional MIME media type + "message/external-body". That is, each message/external-body entity + must have a Content-ID field to permit caching of such data. + + It is also worth noting that the Content-ID value has special + semantics in the case of the multipart/alternative media type. This + is explained in the section of RFC 2046 dealing with + multipart/alternative. + + + + + + + + +Freed & Borenstein Standards Track [Page 26] + +RFC 2045 Internet Message Bodies November 1996 + + +8. Content-Description Header Field + + The ability to associate some descriptive information with a given + body is often desirable. For example, it may be useful to mark an + "image" body as "a picture of the Space Shuttle Endeavor." Such text + may be placed in the Content-Description header field. This header + field is always optional. + + description := "Content-Description" ":" *text + + The description is presumed to be given in the US-ASCII character + set, although the mechanism specified in RFC 2047 may be used for + non-US-ASCII Content-Description values. + +9. Additional MIME Header Fields + + Future documents may elect to define additional MIME header fields + for various purposes. Any new header field that further describes + the content of a message should begin with the string "Content-" to + allow such fields which appear in a message header to be + distinguished from ordinary RFC 822 message header fields. + + MIME-extension-field := + +10. Summary + + Using the MIME-Version, Content-Type, and Content-Transfer-Encoding + header fields, it is possible to include, in a standardized way, + arbitrary types of data with RFC 822 conformant mail messages. No + restrictions imposed by either RFC 821 or RFC 822 are violated, and + care has been taken to avoid problems caused by additional + restrictions imposed by the characteristics of some Internet mail + transport mechanisms (see RFC 2049). + + The next document in this set, RFC 2046, specifies the initial set of + media types that can be labelled and transported using these headers. + +11. Security Considerations + + Security issues are discussed in the second document in this set, RFC + 2046. + + + + + + + + +Freed & Borenstein Standards Track [Page 27] + +RFC 2045 Internet Message Bodies November 1996 + + +12. Authors' Addresses + + For more information, the authors of this document are best contacted + via Internet mail: + + Ned Freed + Innosoft International, Inc. + 1050 East Garvey Avenue South + West Covina, CA 91790 + USA + + Phone: +1 818 919 3600 + Fax: +1 818 919 3614 + EMail: ned@innosoft.com + + + Nathaniel S. Borenstein + First Virtual Holdings + 25 Washington Avenue + Morristown, NJ 07960 + USA + + Phone: +1 201 540 8967 + Fax: +1 201 993 3032 + EMail: nsb@nsb.fv.com + + + MIME is a result of the work of the Internet Engineering Task Force + Working Group on RFC 822 Extensions. The chairman of that group, + Greg Vaudreuil, may be reached at: + + Gregory M. Vaudreuil + Octel Network Services + 17080 Dallas Parkway + Dallas, TX 75248-1905 + USA + + EMail: Greg.Vaudreuil@Octel.Com + + + + + + + + + + + + + +Freed & Borenstein Standards Track [Page 28] + +RFC 2045 Internet Message Bodies November 1996 + + +Appendix A -- Collected Grammar + + This appendix contains the complete BNF grammar for all the syntax + specified by this document. + + By itself, however, this grammar is incomplete. It refers by name to + several syntax rules that are defined by RFC 822. Rather than + reproduce those definitions here, and risk unintentional differences + between the two, this document simply refers the reader to RFC 822 + for the remaining definitions. Wherever a term is undefined, it + refers to the RFC 822 definition. + + attribute := token + ; Matching of attributes + ; is ALWAYS case-insensitive. + + composite-type := "message" / "multipart" / extension-token + + content := "Content-Type" ":" type "/" subtype + *(";" parameter) + ; Matching of media type and subtype + ; is ALWAYS case-insensitive. + + description := "Content-Description" ":" *text + + discrete-type := "text" / "image" / "audio" / "video" / + "application" / extension-token + + encoding := "Content-Transfer-Encoding" ":" mechanism + + entity-headers := [ content CRLF ] + [ encoding CRLF ] + [ id CRLF ] + [ description CRLF ] + *( MIME-extension-field CRLF ) + + extension-token := ietf-token / x-token + + hex-octet := "=" 2(DIGIT / "A" / "B" / "C" / "D" / "E" / "F") + ; Octet must be used for characters > 127, =, + ; SPACEs or TABs at the ends of lines, and is + ; recommended for any character not listed in + ; RFC 2049 as "mail-safe". + + iana-token := + + + + +Freed & Borenstein Standards Track [Page 29] + +RFC 2045 Internet Message Bodies November 1996 + + + ietf-token := + + id := "Content-ID" ":" msg-id + + mechanism := "7bit" / "8bit" / "binary" / + "quoted-printable" / "base64" / + ietf-token / x-token + + MIME-extension-field := + + MIME-message-headers := entity-headers + fields + version CRLF + ; The ordering of the header + ; fields implied by this BNF + ; definition should be ignored. + + MIME-part-headers := entity-headers + [fields] + ; Any field not beginning with + ; "content-" can have no defined + ; meaning and may be ignored. + ; The ordering of the header + ; fields implied by this BNF + ; definition should be ignored. + + parameter := attribute "=" value + + ptext := hex-octet / safe-char + + qp-line := *(qp-segment transport-padding CRLF) + qp-part transport-padding + + qp-part := qp-section + ; Maximum length of 76 characters + + qp-section := [*(ptext / SPACE / TAB) ptext] + + qp-segment := qp-section *(SPACE / TAB) "=" + ; Maximum length of 76 characters + + quoted-printable := qp-line *(CRLF qp-line) + + + + + +Freed & Borenstein Standards Track [Page 30] + +RFC 2045 Internet Message Bodies November 1996 + + + safe-char := + ; Characters not listed as "mail-safe" in + ; RFC 2049 are also not recommended. + + subtype := extension-token / iana-token + + token := 1* + + transport-padding := *LWSP-char + ; Composers MUST NOT generate + ; non-zero length transport + ; padding, but receivers MUST + ; be able to handle padding + ; added by message transports. + + tspecials := "(" / ")" / "<" / ">" / "@" / + "," / ";" / ":" / "\" / <"> + "/" / "[" / "]" / "?" / "=" + ; Must be in quoted-string, + ; to use within parameter values + + type := discrete-type / composite-type + + value := token / quoted-string + + version := "MIME-Version" ":" 1*DIGIT "." 1*DIGIT + + x-token := + + + + + + + + + + + + + + + + + + + + +Freed & Borenstein Standards Track [Page 31] + diff --git a/RFCs/rfc2046.txt b/RFCs/rfc2046.txt new file mode 100644 index 0000000..84d90c1 --- /dev/null +++ b/RFCs/rfc2046.txt @@ -0,0 +1,2467 @@ + + + + + + +Network Working Group N. Freed +Request for Comments: 2046 Innosoft +Obsoletes: 1521, 1522, 1590 N. Borenstein +Category: Standards Track First Virtual + November 1996 + + + Multipurpose Internet Mail Extensions + (MIME) Part Two: + Media Types + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Abstract + + STD 11, RFC 822 defines a message representation protocol specifying + considerable detail about US-ASCII message headers, but which leaves + the message content, or message body, as flat US-ASCII text. This + set of documents, collectively called the Multipurpose Internet Mail + Extensions, or MIME, redefines the format of messages to allow for + + (1) textual message bodies in character sets other than + US-ASCII, + + (2) an extensible set of different formats for non-textual + message bodies, + + (3) multi-part message bodies, and + + (4) textual header information in character sets other than + US-ASCII. + + These documents are based on earlier work documented in RFC 934, STD + 11, and RFC 1049, but extends and revises them. Because RFC 822 said + so little about message bodies, these documents are largely + orthogonal to (rather than a revision of) RFC 822. + + The initial document in this set, RFC 2045, specifies the various + headers used to describe the structure of MIME messages. This second + document defines the general structure of the MIME media typing + system and defines an initial set of media types. The third document, + RFC 2047, describes extensions to RFC 822 to allow non-US-ASCII text + + + +Freed & Borenstein Standards Track [Page 1] + +RFC 2046 Media Types November 1996 + + + data in Internet mail header fields. The fourth document, RFC 2048, + specifies various IANA registration procedures for MIME-related + facilities. The fifth and final document, RFC 2049, describes MIME + conformance criteria as well as providing some illustrative examples + of MIME message formats, acknowledgements, and the bibliography. + + These documents are revisions of RFCs 1521 and 1522, which themselves + were revisions of RFCs 1341 and 1342. An appendix in RFC 2049 + describes differences and changes from previous versions. + +Table of Contents + + 1. Introduction ......................................... 3 + 2. Definition of a Top-Level Media Type ................. 4 + 3. Overview Of The Initial Top-Level Media Types ........ 4 + 4. Discrete Media Type Values ........................... 6 + 4.1 Text Media Type ..................................... 6 + 4.1.1 Representation of Line Breaks ..................... 7 + 4.1.2 Charset Parameter ................................. 7 + 4.1.3 Plain Subtype ..................................... 11 + 4.1.4 Unrecognized Subtypes ............................. 11 + 4.2 Image Media Type .................................... 11 + 4.3 Audio Media Type .................................... 11 + 4.4 Video Media Type .................................... 12 + 4.5 Application Media Type .............................. 12 + 4.5.1 Octet-Stream Subtype .............................. 13 + 4.5.2 PostScript Subtype ................................ 14 + 4.5.3 Other Application Subtypes ........................ 17 + 5. Composite Media Type Values .......................... 17 + 5.1 Multipart Media Type ................................ 17 + 5.1.1 Common Syntax ..................................... 19 + 5.1.2 Handling Nested Messages and Multiparts ........... 24 + 5.1.3 Mixed Subtype ..................................... 24 + 5.1.4 Alternative Subtype ............................... 24 + 5.1.5 Digest Subtype .................................... 26 + 5.1.6 Parallel Subtype .................................. 27 + 5.1.7 Other Multipart Subtypes .......................... 28 + 5.2 Message Media Type .................................. 28 + 5.2.1 RFC822 Subtype .................................... 28 + 5.2.2 Partial Subtype ................................... 29 + 5.2.2.1 Message Fragmentation and Reassembly ............ 30 + 5.2.2.2 Fragmentation and Reassembly Example ............ 31 + 5.2.3 External-Body Subtype ............................. 33 + 5.2.4 Other Message Subtypes ............................ 40 + 6. Experimental Media Type Values ....................... 40 + 7. Summary .............................................. 41 + 8. Security Considerations .............................. 41 + 9. Authors' Addresses ................................... 42 + + + +Freed & Borenstein Standards Track [Page 2] + +RFC 2046 Media Types November 1996 + + + A. Collected Grammar .................................... 43 + +1. Introduction + + The first document in this set, RFC 2045, defines a number of header + fields, including Content-Type. The Content-Type field is used to + specify the nature of the data in the body of a MIME entity, by + giving media type and subtype identifiers, and by providing auxiliary + information that may be required for certain media types. After the + type and subtype names, the remainder of the header field is simply a + set of parameters, specified in an attribute/value notation. The + ordering of parameters is not significant. + + In general, the top-level media type is used to declare the general + type of data, while the subtype specifies a specific format for that + type of data. Thus, a media type of "image/xyz" is enough to tell a + user agent that the data is an image, even if the user agent has no + knowledge of the specific image format "xyz". Such information can + be used, for example, to decide whether or not to show a user the raw + data from an unrecognized subtype -- such an action might be + reasonable for unrecognized subtypes of "text", but not for + unrecognized subtypes of "image" or "audio". For this reason, + registered subtypes of "text", "image", "audio", and "video" should + not contain embedded information that is really of a different type. + Such compound formats should be represented using the "multipart" or + "application" types. + + Parameters are modifiers of the media subtype, and as such do not + fundamentally affect the nature of the content. The set of + meaningful parameters depends on the media type and subtype. Most + parameters are associated with a single specific subtype. However, a + given top-level media type may define parameters which are applicable + to any subtype of that type. Parameters may be required by their + defining media type or subtype or they may be optional. MIME + implementations must also ignore any parameters whose names they do + not recognize. + + MIME's Content-Type header field and media type mechanism has been + carefully designed to be extensible, and it is expected that the set + of media type/subtype pairs and their associated parameters will grow + significantly over time. Several other MIME facilities, such as + transfer encodings and "message/external-body" access types, are + likely to have new values defined over time. In order to ensure that + the set of such values is developed in an orderly, well-specified, + and public manner, MIME sets up a registration process which uses the + Internet Assigned Numbers Authority (IANA) as a central registry for + MIME's various areas of extensibility. The registration process for + these areas is described in a companion document, RFC 2048. + + + +Freed & Borenstein Standards Track [Page 3] + +RFC 2046 Media Types November 1996 + + + The initial seven standard top-level media type are defined and + described in the remainder of this document. + +2. Definition of a Top-Level Media Type + + The definition of a top-level media type consists of: + + (1) a name and a description of the type, including + criteria for whether a particular type would qualify + under that type, + + (2) the names and definitions of parameters, if any, which + are defined for all subtypes of that type (including + whether such parameters are required or optional), + + (3) how a user agent and/or gateway should handle unknown + subtypes of this type, + + (4) general considerations on gatewaying entities of this + top-level type, if any, and + + (5) any restrictions on content-transfer-encodings for + entities of this top-level type. + +3. Overview Of The Initial Top-Level Media Types + + The five discrete top-level media types are: + + (1) text -- textual information. The subtype "plain" in + particular indicates plain text containing no + formatting commands or directives of any sort. Plain + text is intended to be displayed "as-is". No special + software is required to get the full meaning of the + text, aside from support for the indicated character + set. Other subtypes are to be used for enriched text in + forms where application software may enhance the + appearance of the text, but such software must not be + required in order to get the general idea of the + content. Possible subtypes of "text" thus include any + word processor format that can be read without + resorting to software that understands the format. In + particular, formats that employ embeddded binary + formatting information are not considered directly + readable. A very simple and portable subtype, + "richtext", was defined in RFC 1341, with a further + revision in RFC 1896 under the name "enriched". + + + + + +Freed & Borenstein Standards Track [Page 4] + +RFC 2046 Media Types November 1996 + + + (2) image -- image data. "Image" requires a display device + (such as a graphical display, a graphics printer, or a + FAX machine) to view the information. An initial + subtype is defined for the widely-used image format + JPEG. . subtypes are defined for two widely-used image + formats, jpeg and gif. + + (3) audio -- audio data. "Audio" requires an audio output + device (such as a speaker or a telephone) to "display" + the contents. An initial subtype "basic" is defined in + this document. + + (4) video -- video data. "Video" requires the capability + to display moving images, typically including + specialized hardware and software. An initial subtype + "mpeg" is defined in this document. + + (5) application -- some other kind of data, typically + either uninterpreted binary data or information to be + processed by an application. The subtype "octet- + stream" is to be used in the case of uninterpreted + binary data, in which case the simplest recommended + action is to offer to write the information into a file + for the user. The "PostScript" subtype is also defined + for the transport of PostScript material. Other + expected uses for "application" include spreadsheets, + data for mail-based scheduling systems, and languages + for "active" (computational) messaging, and word + processing formats that are not directly readable. + Note that security considerations may exist for some + types of application data, most notably + "application/PostScript" and any form of active + messaging. These issues are discussed later in this + document. + + The two composite top-level media types are: + + (1) multipart -- data consisting of multiple entities of + independent data types. Four subtypes are initially + defined, including the basic "mixed" subtype specifying + a generic mixed set of parts, "alternative" for + representing the same data in multiple formats, + "parallel" for parts intended to be viewed + simultaneously, and "digest" for multipart entities in + which each part has a default type of "message/rfc822". + + + + + + +Freed & Borenstein Standards Track [Page 5] + +RFC 2046 Media Types November 1996 + + + (2) message -- an encapsulated message. A body of media + type "message" is itself all or a portion of some kind + of message object. Such objects may or may not in turn + contain other entities. The "rfc822" subtype is used + when the encapsulated content is itself an RFC 822 + message. The "partial" subtype is defined for partial + RFC 822 messages, to permit the fragmented transmission + of bodies that are thought to be too large to be passed + through transport facilities in one piece. Another + subtype, "external-body", is defined for specifying + large bodies by reference to an external data source. + + It should be noted that the list of media type values given here may + be augmented in time, via the mechanisms described above, and that + the set of subtypes is expected to grow substantially. + +4. Discrete Media Type Values + + Five of the seven initial media type values refer to discrete bodies. + The content of these types must be handled by non-MIME mechanisms; + they are opaque to MIME processors. + +4.1. Text Media Type + + The "text" media type is intended for sending material which is + principally textual in form. A "charset" parameter may be used to + indicate the character set of the body text for "text" subtypes, + notably including the subtype "text/plain", which is a generic + subtype for plain text. Plain text does not provide for or allow + formatting commands, font attribute specifications, processing + instructions, interpretation directives, or content markup. Plain + text is seen simply as a linear sequence of characters, possibly + interrupted by line breaks or page breaks. Plain text may allow the + stacking of several characters in the same position in the text. + Plain text in scripts like Arabic and Hebrew may also include + facilitites that allow the arbitrary mixing of text segments with + opposite writing directions. + + Beyond plain text, there are many formats for representing what might + be known as "rich text". An interesting characteristic of many such + representations is that they are to some extent readable even without + the software that interprets them. It is useful, then, to + distinguish them, at the highest level, from such unreadable data as + images, audio, or text represented in an unreadable form. In the + absence of appropriate interpretation software, it is reasonable to + show subtypes of "text" to the user, while it is not reasonable to do + so with most nontextual data. Such formatted textual data should be + represented using subtypes of "text". + + + +Freed & Borenstein Standards Track [Page 6] + +RFC 2046 Media Types November 1996 + + +4.1.1. Representation of Line Breaks + + The canonical form of any MIME "text" subtype MUST always represent a + line break as a CRLF sequence. Similarly, any occurrence of CRLF in + MIME "text" MUST represent a line break. Use of CR and LF outside of + line break sequences is also forbidden. + + This rule applies regardless of format or character set or sets + involved. + + NOTE: The proper interpretation of line breaks when a body is + displayed depends on the media type. In particular, while it is + appropriate to treat a line break as a transition to a new line when + displaying a "text/plain" body, this treatment is actually incorrect + for other subtypes of "text" like "text/enriched" [RFC-1896]. + Similarly, whether or not line breaks should be added during display + operations is also a function of the media type. It should not be + necessary to add any line breaks to display "text/plain" correctly, + whereas proper display of "text/enriched" requires the appropriate + addition of line breaks. + + NOTE: Some protocols defines a maximum line length. E.g. SMTP [RFC- + 821] allows a maximum of 998 octets before the next CRLF sequence. + To be transported by such protocols, data which includes too long + segments without CRLF sequences must be encoded with a suitable + content-transfer-encoding. + +4.1.2. Charset Parameter + + A critical parameter that may be specified in the Content-Type field + for "text/plain" data is the character set. This is specified with a + "charset" parameter, as in: + + Content-type: text/plain; charset=iso-8859-1 + + Unlike some other parameter values, the values of the charset + parameter are NOT case sensitive. The default character set, which + must be assumed in the absence of a charset parameter, is US-ASCII. + + The specification for any future subtypes of "text" must specify + whether or not they will also utilize a "charset" parameter, and may + possibly restrict its values as well. For other subtypes of "text" + than "text/plain", the semantics of the "charset" parameter should be + defined to be identical to those specified here for "text/plain", + i.e., the body consists entirely of characters in the given charset. + In particular, definers of future "text" subtypes should pay close + attention to the implications of multioctet character sets for their + subtype definitions. + + + +Freed & Borenstein Standards Track [Page 7] + +RFC 2046 Media Types November 1996 + + + The charset parameter for subtypes of "text" gives a name of a + character set, as "character set" is defined in RFC 2045. The rules + regarding line breaks detailed in the previous section must also be + observed -- a character set whose definition does not conform to + these rules cannot be used in a MIME "text" subtype. + + An initial list of predefined character set names can be found at the + end of this section. Additional character sets may be registered + with IANA. + + Other media types than subtypes of "text" might choose to employ the + charset parameter as defined here, but with the CRLF/line break + restriction removed. Therefore, all character sets that conform to + the general definition of "character set" in RFC 2045 can be + registered for MIME use. + + Note that if the specified character set includes 8-bit characters + and such characters are used in the body, a Content-Transfer-Encoding + header field and a corresponding encoding on the data are required in + order to transmit the body via some mail transfer protocols, such as + SMTP [RFC-821]. + + The default character set, US-ASCII, has been the subject of some + confusion and ambiguity in the past. Not only were there some + ambiguities in the definition, there have been wide variations in + practice. In order to eliminate such ambiguity and variations in the + future, it is strongly recommended that new user agents explicitly + specify a character set as a media type parameter in the Content-Type + header field. "US-ASCII" does not indicate an arbitrary 7-bit + character set, but specifies that all octets in the body must be + interpreted as characters according to the US-ASCII character set. + National and application-oriented versions of ISO 646 [ISO-646] are + usually NOT identical to US-ASCII, and in that case their use in + Internet mail is explicitly discouraged. The omission of the ISO 646 + character set from this document is deliberate in this regard. The + character set name of "US-ASCII" explicitly refers to the character + set defined in ANSI X3.4-1986 [US- ASCII]. The new international + reference version (IRV) of the 1991 edition of ISO 646 is identical + to US-ASCII. The character set name "ASCII" is reserved and must not + be used for any purpose. + + NOTE: RFC 821 explicitly specifies "ASCII", and references an earlier + version of the American Standard. Insofar as one of the purposes of + specifying a media type and character set is to permit the receiver + to unambiguously determine how the sender intended the coded message + to be interpreted, assuming anything other than "strict ASCII" as the + default would risk unintentional and incompatible changes to the + semantics of messages now being transmitted. This also implies that + + + +Freed & Borenstein Standards Track [Page 8] + +RFC 2046 Media Types November 1996 + + + messages containing characters coded according to other versions of + ISO 646 than US-ASCII and the 1991 IRV, or using code-switching + procedures (e.g., those of ISO 2022), as well as 8bit or multiple + octet character encodings MUST use an appropriate character set + specification to be consistent with MIME. + + The complete US-ASCII character set is listed in ANSI X3.4- 1986. + Note that the control characters including DEL (0-31, 127) have no + defined meaning in apart from the combination CRLF (US-ASCII values + 13 and 10) indicating a new line. Two of the characters have de + facto meanings in wide use: FF (12) often means "start subsequent + text on the beginning of a new page"; and TAB or HT (9) often (though + not always) means "move the cursor to the next available column after + the current position where the column number is a multiple of 8 + (counting the first column as column 0)." Aside from these + conventions, any use of the control characters or DEL in a body must + either occur + + (1) because a subtype of text other than "plain" + specifically assigns some additional meaning, or + + (2) within the context of a private agreement between the + sender and recipient. Such private agreements are + discouraged and should be replaced by the other + capabilities of this document. + + NOTE: An enormous proliferation of character sets exist beyond US- + ASCII. A large number of partially or totally overlapping character + sets is NOT a good thing. A SINGLE character set that can be used + universally for representing all of the world's languages in Internet + mail would be preferrable. Unfortunately, existing practice in + several communities seems to point to the continued use of multiple + character sets in the near future. A small number of standard + character sets are, therefore, defined for Internet use in this + document. + + The defined charset values are: + + (1) US-ASCII -- as defined in ANSI X3.4-1986 [US-ASCII]. + + (2) ISO-8859-X -- where "X" is to be replaced, as + necessary, for the parts of ISO-8859 [ISO-8859]. Note + that the ISO 646 character sets have deliberately been + omitted in favor of their 8859 replacements, which are + the designated character sets for Internet mail. As of + the publication of this document, the legitimate values + for "X" are the digits 1 through 10. + + + + +Freed & Borenstein Standards Track [Page 9] + +RFC 2046 Media Types November 1996 + + + Characters in the range 128-159 has no assigned meaning in ISO-8859- + X. Characters with values below 128 in ISO-8859-X have the same + assigned meaning as they do in US-ASCII. + + Part 6 of ISO 8859 (Latin/Arabic alphabet) and part 8 (Latin/Hebrew + alphabet) includes both characters for which the normal writing + direction is right to left and characters for which it is left to + right, but do not define a canonical ordering method for representing + bi-directional text. The charset values "ISO-8859-6" and "ISO-8859- + 8", however, specify that the visual method is used [RFC-1556]. + + All of these character sets are used as pure 7bit or 8bit sets + without any shift or escape functions. The meaning of shift and + escape sequences in these character sets is not defined. + + The character sets specified above are the ones that were relatively + uncontroversial during the drafting of MIME. This document does not + endorse the use of any particular character set other than US-ASCII, + and recognizes that the future evolution of world character sets + remains unclear. + + Note that the character set used, if anything other than US- ASCII, + must always be explicitly specified in the Content-Type field. + + No character set name other than those defined above may be used in + Internet mail without the publication of a formal specification and + its registration with IANA, or by private agreement, in which case + the character set name must begin with "X-". + + Implementors are discouraged from defining new character sets unless + absolutely necessary. + + The "charset" parameter has been defined primarily for the purpose of + textual data, and is described in this section for that reason. + However, it is conceivable that non-textual data might also wish to + specify a charset value for some purpose, in which case the same + syntax and values should be used. + + In general, composition software should always use the "lowest common + denominator" character set possible. For example, if a body contains + only US-ASCII characters, it SHOULD be marked as being in the US- + ASCII character set, not ISO-8859-1, which, like all the ISO-8859 + family of character sets, is a superset of US-ASCII. More generally, + if a widely-used character set is a subset of another character set, + and a body contains only characters in the widely-used subset, it + should be labelled as being in that subset. This will increase the + chances that the recipient will be able to view the resulting entity + correctly. + + + +Freed & Borenstein Standards Track [Page 10] + +RFC 2046 Media Types November 1996 + + +4.1.3. Plain Subtype + + The simplest and most important subtype of "text" is "plain". This + indicates plain text that does not contain any formatting commands or + directives. Plain text is intended to be displayed "as-is", that is, + no interpretation of embedded formatting commands, font attribute + specifications, processing instructions, interpretation directives, + or content markup should be necessary for proper display. The + default media type of "text/plain; charset=us-ascii" for Internet + mail describes existing Internet practice. That is, it is the type + of body defined by RFC 822. + + No other "text" subtype is defined by this document. + +4.1.4. Unrecognized Subtypes + + Unrecognized subtypes of "text" should be treated as subtype "plain" + as long as the MIME implementation knows how to handle the charset. + Unrecognized subtypes which also specify an unrecognized charset + should be treated as "application/octet- stream". + +4.2. Image Media Type + + A media type of "image" indicates that the body contains an image. + The subtype names the specific image format. These names are not + case sensitive. An initial subtype is "jpeg" for the JPEG format + using JFIF encoding [JPEG]. + + The list of "image" subtypes given here is neither exclusive nor + exhaustive, and is expected to grow as more types are registered with + IANA, as described in RFC 2048. + + Unrecognized subtypes of "image" should at a miniumum be treated as + "application/octet-stream". Implementations may optionally elect to + pass subtypes of "image" that they do not specifically recognize to a + secure and robust general-purpose image viewing application, if such + an application is available. + + NOTE: Using of a generic-purpose image viewing application this way + inherits the security problems of the most dangerous type supported + by the application. + +4.3. Audio Media Type + + A media type of "audio" indicates that the body contains audio data. + Although there is not yet a consensus on an "ideal" audio format for + use with computers, there is a pressing need for a format capable of + providing interoperable behavior. + + + +Freed & Borenstein Standards Track [Page 11] + +RFC 2046 Media Types November 1996 + + + The initial subtype of "basic" is specified to meet this requirement + by providing an absolutely minimal lowest common denominator audio + format. It is expected that richer formats for higher quality and/or + lower bandwidth audio will be defined by a later document. + + The content of the "audio/basic" subtype is single channel audio + encoded using 8bit ISDN mu-law [PCM] at a sample rate of 8000 Hz. + + Unrecognized subtypes of "audio" should at a miniumum be treated as + "application/octet-stream". Implementations may optionally elect to + pass subtypes of "audio" that they do not specifically recognize to a + robust general-purpose audio playing application, if such an + application is available. + +4.4. Video Media Type + + A media type of "video" indicates that the body contains a time- + varying-picture image, possibly with color and coordinated sound. + The term 'video' is used in its most generic sense, rather than with + reference to any particular technology or format, and is not meant to + preclude subtypes such as animated drawings encoded compactly. The + subtype "mpeg" refers to video coded according to the MPEG standard + [MPEG]. + + Note that although in general this document strongly discourages the + mixing of multiple media in a single body, it is recognized that many + so-called video formats include a representation for synchronized + audio, and this is explicitly permitted for subtypes of "video". + + Unrecognized subtypes of "video" should at a minumum be treated as + "application/octet-stream". Implementations may optionally elect to + pass subtypes of "video" that they do not specifically recognize to a + robust general-purpose video display application, if such an + application is available. + +4.5. Application Media Type + + The "application" media type is to be used for discrete data which do + not fit in any of the other categories, and particularly for data to + be processed by some type of application program. This is + information which must be processed by an application before it is + viewable or usable by a user. Expected uses for the "application" + media type include file transfer, spreadsheets, data for mail-based + scheduling systems, and languages for "active" (computational) + material. (The latter, in particular, can pose security problems + which must be understood by implementors, and are considered in + detail in the discussion of the "application/PostScript" media type.) + + + + +Freed & Borenstein Standards Track [Page 12] + +RFC 2046 Media Types November 1996 + + + For example, a meeting scheduler might define a standard + representation for information about proposed meeting dates. An + intelligent user agent would use this information to conduct a dialog + with the user, and might then send additional material based on that + dialog. More generally, there have been several "active" messaging + languages developed in which programs in a suitably specialized + language are transported to a remote location and automatically run + in the recipient's environment. + + Such applications may be defined as subtypes of the "application" + media type. This document defines two subtypes: + + octet-stream, and PostScript. + + The subtype of "application" will often be either the name or include + part of the name of the application for which the data are intended. + This does not mean, however, that any application program name may be + used freely as a subtype of "application". + +4.5.1. Octet-Stream Subtype + + The "octet-stream" subtype is used to indicate that a body contains + arbitrary binary data. The set of currently defined parameters is: + + (1) TYPE -- the general type or category of binary data. + This is intended as information for the human recipient + rather than for any automatic processing. + + (2) PADDING -- the number of bits of padding that were + appended to the bit-stream comprising the actual + contents to produce the enclosed 8bit byte-oriented + data. This is useful for enclosing a bit-stream in a + body when the total number of bits is not a multiple of + 8. + + Both of these parameters are optional. + + An additional parameter, "CONVERSIONS", was defined in RFC 1341 but + has since been removed. RFC 1341 also defined the use of a "NAME" + parameter which gave a suggested file name to be used if the data + were to be written to a file. This has been deprecated in + anticipation of a separate Content-Disposition header field, to be + defined in a subsequent RFC. + + The recommended action for an implementation that receives an + "application/octet-stream" entity is to simply offer to put the data + in a file, with any Content-Transfer-Encoding undone, or perhaps to + use it as input to a user-specified process. + + + +Freed & Borenstein Standards Track [Page 13] + +RFC 2046 Media Types November 1996 + + + To reduce the danger of transmitting rogue programs, it is strongly + recommended that implementations NOT implement a path-search + mechanism whereby an arbitrary program named in the Content-Type + parameter (e.g., an "interpreter=" parameter) is found and executed + using the message body as input. + +4.5.2. PostScript Subtype + + A media type of "application/postscript" indicates a PostScript + program. Currently two variants of the PostScript language are + allowed; the original level 1 variant is described in [POSTSCRIPT] + and the more recent level 2 variant is described in [POSTSCRIPT2]. + + PostScript is a registered trademark of Adobe Systems, Inc. Use of + the MIME media type "application/postscript" implies recognition of + that trademark and all the rights it entails. + + The PostScript language definition provides facilities for internal + labelling of the specific language features a given program uses. + This labelling, called the PostScript document structuring + conventions, or DSC, is very general and provides substantially more + information than just the language level. The use of document + structuring conventions, while not required, is strongly recommended + as an aid to interoperability. Documents which lack proper + structuring conventions cannot be tested to see whether or not they + will work in a given environment. As such, some systems may assume + the worst and refuse to process unstructured documents. + + The execution of general-purpose PostScript interpreters entails + serious security risks, and implementors are discouraged from simply + sending PostScript bodies to "off- the-shelf" interpreters. While it + is usually safe to send PostScript to a printer, where the potential + for harm is greatly constrained by typical printer environments, + implementors should consider all of the following before they add + interactive display of PostScript bodies to their MIME readers. + + The remainder of this section outlines some, though probably not all, + of the possible problems with the transport of PostScript entities. + + (1) Dangerous operations in the PostScript language + include, but may not be limited to, the PostScript + operators "deletefile", "renamefile", "filenameforall", + and "file". "File" is only dangerous when applied to + something other than standard input or output. + Implementations may also define additional nonstandard + file operators; these may also pose a threat to + security. "Filenameforall", the wildcard file search + operator, may appear at first glance to be harmless. + + + +Freed & Borenstein Standards Track [Page 14] + +RFC 2046 Media Types November 1996 + + + Note, however, that this operator has the potential to + reveal information about what files the recipient has + access to, and this information may itself be + sensitive. Message senders should avoid the use of + potentially dangerous file operators, since these + operators are quite likely to be unavailable in secure + PostScript implementations. Message receiving and + displaying software should either completely disable + all potentially dangerous file operators or take + special care not to delegate any special authority to + their operation. These operators should be viewed as + being done by an outside agency when interpreting + PostScript documents. Such disabling and/or checking + should be done completely outside of the reach of the + PostScript language itself; care should be taken to + insure that no method exists for re-enabling full- + function versions of these operators. + + (2) The PostScript language provides facilities for exiting + the normal interpreter, or server, loop. Changes made + in this "outer" environment are customarily retained + across documents, and may in some cases be retained + semipermanently in nonvolatile memory. The operators + associated with exiting the interpreter loop have the + potential to interfere with subsequent document + processing. As such, their unrestrained use + constitutes a threat of service denial. PostScript + operators that exit the interpreter loop include, but + may not be limited to, the exitserver and startjob + operators. Message sending software should not + generate PostScript that depends on exiting the + interpreter loop to operate, since the ability to exit + will probably be unavailable in secure PostScript + implementations. Message receiving and displaying + software should completely disable the ability to make + retained changes to the PostScript environment by + eliminating or disabling the "startjob" and + "exitserver" operations. If these operations cannot be + eliminated or completely disabled the password + associated with them should at least be set to a hard- + to-guess value. + + (3) PostScript provides operators for setting system-wide + and device-specific parameters. These parameter + settings may be retained across jobs and may + potentially pose a threat to the correct operation of + the interpreter. The PostScript operators that set + system and device parameters include, but may not be + + + +Freed & Borenstein Standards Track [Page 15] + +RFC 2046 Media Types November 1996 + + + limited to, the "setsystemparams" and "setdevparams" + operators. Message sending software should not + generate PostScript that depends on the setting of + system or device parameters to operate correctly. The + ability to set these parameters will probably be + unavailable in secure PostScript implementations. + Message receiving and displaying software should + disable the ability to change system and device + parameters. If these operators cannot be completely + disabled the password associated with them should at + least be set to a hard-to-guess value. + + (4) Some PostScript implementations provide nonstandard + facilities for the direct loading and execution of + machine code. Such facilities are quite obviously open + to substantial abuse. Message sending software should + not make use of such features. Besides being totally + hardware-specific, they are also likely to be + unavailable in secure implementations of PostScript. + Message receiving and displaying software should not + allow such operators to be used if they exist. + + (5) PostScript is an extensible language, and many, if not + most, implementations of it provide a number of their + own extensions. This document does not deal with such + extensions explicitly since they constitute an unknown + factor. Message sending software should not make use + of nonstandard extensions; they are likely to be + missing from some implementations. Message receiving + and displaying software should make sure that any + nonstandard PostScript operators are secure and don't + present any kind of threat. + + (6) It is possible to write PostScript that consumes huge + amounts of various system resources. It is also + possible to write PostScript programs that loop + indefinitely. Both types of programs have the + potential to cause damage if sent to unsuspecting + recipients. Message-sending software should avoid the + construction and dissemination of such programs, which + is antisocial. Message receiving and displaying + software should provide appropriate mechanisms to abort + processing after a reasonable amount of time has + elapsed. In addition, PostScript interpreters should be + limited to the consumption of only a reasonable amount + of any given system resource. + + + + + +Freed & Borenstein Standards Track [Page 16] + +RFC 2046 Media Types November 1996 + + + (7) It is possible to include raw binary information inside + PostScript in various forms. This is not recommended + for use in Internet mail, both because it is not + supported by all PostScript interpreters and because it + significantly complicates the use of a MIME Content- + Transfer-Encoding. (Without such binary, PostScript + may typically be viewed as line-oriented data. The + treatment of CRLF sequences becomes extremely + problematic if binary and line-oriented data are mixed + in a single Postscript data stream.) + + (8) Finally, bugs may exist in some PostScript interpreters + which could possibly be exploited to gain unauthorized + access to a recipient's system. Apart from noting this + possibility, there is no specific action to take to + prevent this, apart from the timely correction of such + bugs if any are found. + +4.5.3. Other Application Subtypes + + It is expected that many other subtypes of "application" will be + defined in the future. MIME implementations must at a minimum treat + any unrecognized subtypes as being equivalent to "application/octet- + stream". + +5. Composite Media Type Values + + The remaining two of the seven initial Content-Type values refer to + composite entities. Composite entities are handled using MIME + mechanisms -- a MIME processor typically handles the body directly. + +5.1. Multipart Media Type + + In the case of multipart entities, in which one or more different + sets of data are combined in a single body, a "multipart" media type + field must appear in the entity's header. The body must then contain + one or more body parts, each preceded by a boundary delimiter line, + and the last one followed by a closing boundary delimiter line. + After its boundary delimiter line, each body part then consists of a + header area, a blank line, and a body area. Thus a body part is + similar to an RFC 822 message in syntax, but different in meaning. + + A body part is an entity and hence is NOT to be interpreted as + actually being an RFC 822 message. To begin with, NO header fields + are actually required in body parts. A body part that starts with a + blank line, therefore, is allowed and is a body part for which all + default values are to be assumed. In such a case, the absence of a + Content-Type header usually indicates that the corresponding body has + + + +Freed & Borenstein Standards Track [Page 17] + +RFC 2046 Media Types November 1996 + + + a content-type of "text/plain; charset=US-ASCII". + + The only header fields that have defined meaning for body parts are + those the names of which begin with "Content-". All other header + fields may be ignored in body parts. Although they should generally + be retained if at all possible, they may be discarded by gateways if + necessary. Such other fields are permitted to appear in body parts + but must not be depended on. "X-" fields may be created for + experimental or private purposes, with the recognition that the + information they contain may be lost at some gateways. + + NOTE: The distinction between an RFC 822 message and a body part is + subtle, but important. A gateway between Internet and X.400 mail, + for example, must be able to tell the difference between a body part + that contains an image and a body part that contains an encapsulated + message, the body of which is a JPEG image. In order to represent + the latter, the body part must have "Content-Type: message/rfc822", + and its body (after the blank line) must be the encapsulated message, + with its own "Content-Type: image/jpeg" header field. The use of + similar syntax facilitates the conversion of messages to body parts, + and vice versa, but the distinction between the two must be + understood by implementors. (For the special case in which parts + actually are messages, a "digest" subtype is also defined.) + + As stated previously, each body part is preceded by a boundary + delimiter line that contains the boundary delimiter. The boundary + delimiter MUST NOT appear inside any of the encapsulated parts, on a + line by itself or as the prefix of any line. This implies that it is + crucial that the composing agent be able to choose and specify a + unique boundary parameter value that does not contain the boundary + parameter value of an enclosing multipart as a prefix. + + All present and future subtypes of the "multipart" type must use an + identical syntax. Subtypes may differ in their semantics, and may + impose additional restrictions on syntax, but must conform to the + required syntax for the "multipart" type. This requirement ensures + that all conformant user agents will at least be able to recognize + and separate the parts of any multipart entity, even those of an + unrecognized subtype. + + As stated in the definition of the Content-Transfer-Encoding field + [RFC 2045], no encoding other than "7bit", "8bit", or "binary" is + permitted for entities of type "multipart". The "multipart" boundary + delimiters and header fields are always represented as 7bit US-ASCII + in any case (though the header fields may encode non-US-ASCII header + text as per RFC 2047) and data within the body parts can be encoded + on a part-by-part basis, with Content-Transfer-Encoding fields for + each appropriate body part. + + + +Freed & Borenstein Standards Track [Page 18] + +RFC 2046 Media Types November 1996 + + +5.1.1. Common Syntax + + This section defines a common syntax for subtypes of "multipart". + All subtypes of "multipart" must use this syntax. A simple example + of a multipart message also appears in this section. An example of a + more complex multipart message is given in RFC 2049. + + The Content-Type field for multipart entities requires one parameter, + "boundary". The boundary delimiter line is then defined as a line + consisting entirely of two hyphen characters ("-", decimal value 45) + followed by the boundary parameter value from the Content-Type header + field, optional linear whitespace, and a terminating CRLF. + + NOTE: The hyphens are for rough compatibility with the earlier RFC + 934 method of message encapsulation, and for ease of searching for + the boundaries in some implementations. However, it should be noted + that multipart messages are NOT completely compatible with RFC 934 + encapsulations; in particular, they do not obey RFC 934 quoting + conventions for embedded lines that begin with hyphens. This + mechanism was chosen over the RFC 934 mechanism because the latter + causes lines to grow with each level of quoting. The combination of + this growth with the fact that SMTP implementations sometimes wrap + long lines made the RFC 934 mechanism unsuitable for use in the event + that deeply-nested multipart structuring is ever desired. + + WARNING TO IMPLEMENTORS: The grammar for parameters on the Content- + type field is such that it is often necessary to enclose the boundary + parameter values in quotes on the Content-type line. This is not + always necessary, but never hurts. Implementors should be sure to + study the grammar carefully in order to avoid producing invalid + Content-type fields. Thus, a typical "multipart" Content-Type header + field might look like this: + + Content-Type: multipart/mixed; boundary=gc0p4Jq0M2Yt08j34c0p + + But the following is not valid: + + Content-Type: multipart/mixed; boundary=gc0pJq0M:08jU534c0p + + (because of the colon) and must instead be represented as + + Content-Type: multipart/mixed; boundary="gc0pJq0M:08jU534c0p" + + This Content-Type value indicates that the content consists of one or + more parts, each with a structure that is syntactically identical to + an RFC 822 message, except that the header area is allowed to be + completely empty, and that the parts are each preceded by the line + + + + +Freed & Borenstein Standards Track [Page 19] + +RFC 2046 Media Types November 1996 + + + --gc0pJq0M:08jU534c0p + + The boundary delimiter MUST occur at the beginning of a line, i.e., + following a CRLF, and the initial CRLF is considered to be attached + to the boundary delimiter line rather than part of the preceding + part. The boundary may be followed by zero or more characters of + linear whitespace. It is then terminated by either another CRLF and + the header fields for the next part, or by two CRLFs, in which case + there are no header fields for the next part. If no Content-Type + field is present it is assumed to be "message/rfc822" in a + "multipart/digest" and "text/plain" otherwise. + + NOTE: The CRLF preceding the boundary delimiter line is conceptually + attached to the boundary so that it is possible to have a part that + does not end with a CRLF (line break). Body parts that must be + considered to end with line breaks, therefore, must have two CRLFs + preceding the boundary delimiter line, the first of which is part of + the preceding body part, and the second of which is part of the + encapsulation boundary. + + Boundary delimiters must not appear within the encapsulated material, + and must be no longer than 70 characters, not counting the two + leading hyphens. + + The boundary delimiter line following the last body part is a + distinguished delimiter that indicates that no further body parts + will follow. Such a delimiter line is identical to the previous + delimiter lines, with the addition of two more hyphens after the + boundary parameter value. + + --gc0pJq0M:08jU534c0p-- + + NOTE TO IMPLEMENTORS: Boundary string comparisons must compare the + boundary value with the beginning of each candidate line. An exact + match of the entire candidate line is not required; it is sufficient + that the boundary appear in its entirety following the CRLF. + + There appears to be room for additional information prior to the + first boundary delimiter line and following the final boundary + delimiter line. These areas should generally be left blank, and + implementations must ignore anything that appears before the first + boundary delimiter line or after the last one. + + NOTE: These "preamble" and "epilogue" areas are generally not used + because of the lack of proper typing of these parts and the lack of + clear semantics for handling these areas at gateways, particularly + X.400 gateways. However, rather than leaving the preamble area + blank, many MIME implementations have found this to be a convenient + + + +Freed & Borenstein Standards Track [Page 20] + +RFC 2046 Media Types November 1996 + + + place to insert an explanatory note for recipients who read the + message with pre-MIME software, since such notes will be ignored by + MIME-compliant software. + + NOTE: Because boundary delimiters must not appear in the body parts + being encapsulated, a user agent must exercise care to choose a + unique boundary parameter value. The boundary parameter value in the + example above could have been the result of an algorithm designed to + produce boundary delimiters with a very low probability of already + existing in the data to be encapsulated without having to prescan the + data. Alternate algorithms might result in more "readable" boundary + delimiters for a recipient with an old user agent, but would require + more attention to the possibility that the boundary delimiter might + appear at the beginning of some line in the encapsulated part. The + simplest boundary delimiter line possible is something like "---", + with a closing boundary delimiter line of "-----". + + As a very simple example, the following multipart message has two + parts, both of them plain text, one of them explicitly typed and one + of them implicitly typed: + + From: Nathaniel Borenstein + To: Ned Freed + Date: Sun, 21 Mar 1993 23:56:48 -0800 (PST) + Subject: Sample message + MIME-Version: 1.0 + Content-type: multipart/mixed; boundary="simple boundary" + + This is the preamble. It is to be ignored, though it + is a handy place for composition agents to include an + explanatory note to non-MIME conformant readers. + + --simple boundary + + This is implicitly typed plain US-ASCII text. + It does NOT end with a linebreak. + --simple boundary + Content-type: text/plain; charset=us-ascii + + This is explicitly typed plain US-ASCII text. + It DOES end with a linebreak. + + --simple boundary-- + + This is the epilogue. It is also to be ignored. + + + + + + +Freed & Borenstein Standards Track [Page 21] + +RFC 2046 Media Types November 1996 + + + The use of a media type of "multipart" in a body part within another + "multipart" entity is explicitly allowed. In such cases, for obvious + reasons, care must be taken to ensure that each nested "multipart" + entity uses a different boundary delimiter. See RFC 2049 for an + example of nested "multipart" entities. + + The use of the "multipart" media type with only a single body part + may be useful in certain contexts, and is explicitly permitted. + + NOTE: Experience has shown that a "multipart" media type with a + single body part is useful for sending non-text media types. It has + the advantage of providing the preamble as a place to include + decoding instructions. In addition, a number of SMTP gateways move + or remove the MIME headers, and a clever MIME decoder can take a good + guess at multipart boundaries even in the absence of the Content-Type + header and thereby successfully decode the message. + + The only mandatory global parameter for the "multipart" media type is + the boundary parameter, which consists of 1 to 70 characters from a + set of characters known to be very robust through mail gateways, and + NOT ending with white space. (If a boundary delimiter line appears to + end with white space, the white space must be presumed to have been + added by a gateway, and must be deleted.) It is formally specified + by the following BNF: + + boundary := 0*69 bcharsnospace + + bchars := bcharsnospace / " " + + bcharsnospace := DIGIT / ALPHA / "'" / "(" / ")" / + "+" / "_" / "," / "-" / "." / + "/" / ":" / "=" / "?" + + Overall, the body of a "multipart" entity may be specified as + follows: + + dash-boundary := "--" boundary + ; boundary taken from the value of + ; boundary parameter of the + ; Content-Type field. + + multipart-body := [preamble CRLF] + dash-boundary transport-padding CRLF + body-part *encapsulation + close-delimiter transport-padding + [CRLF epilogue] + + + + + +Freed & Borenstein Standards Track [Page 22] + +RFC 2046 Media Types November 1996 + + + transport-padding := *LWSP-char + ; Composers MUST NOT generate + ; non-zero length transport + ; padding, but receivers MUST + ; be able to handle padding + ; added by message transports. + + encapsulation := delimiter transport-padding + CRLF body-part + + delimiter := CRLF dash-boundary + + close-delimiter := delimiter "--" + + preamble := discard-text + + epilogue := discard-text + + discard-text := *(*text CRLF) *text + ; May be ignored or discarded. + + body-part := MIME-part-headers [CRLF *OCTET] + ; Lines in a body-part must not start + ; with the specified dash-boundary and + ; the delimiter must not appear anywhere + ; in the body part. Note that the + ; semantics of a body-part differ from + ; the semantics of a message, as + ; described in the text. + + OCTET := + + IMPORTANT: The free insertion of linear-white-space and RFC 822 + comments between the elements shown in this BNF is NOT allowed since + this BNF does not specify a structured header field. + + NOTE: In certain transport enclaves, RFC 822 restrictions such as + the one that limits bodies to printable US-ASCII characters may not + be in force. (That is, the transport domains may exist that resemble + standard Internet mail transport as specified in RFC 821 and assumed + by RFC 822, but without certain restrictions.) The relaxation of + these restrictions should be construed as locally extending the + definition of bodies, for example to include octets outside of the + US-ASCII range, as long as these extensions are supported by the + transport and adequately documented in the Content- Transfer-Encoding + header field. However, in no event are headers (either message + headers or body part headers) allowed to contain anything other than + US-ASCII characters. + + + +Freed & Borenstein Standards Track [Page 23] + +RFC 2046 Media Types November 1996 + + + NOTE: Conspicuously missing from the "multipart" type is a notion of + structured, related body parts. It is recommended that those wishing + to provide more structured or integrated multipart messaging + facilities should define subtypes of multipart that are syntactically + identical but define relationships between the various parts. For + example, subtypes of multipart could be defined that include a + distinguished part which in turn is used to specify the relationships + between the other parts, probably referring to them by their + Content-ID field. Old implementations will not recognize the new + subtype if this approach is used, but will treat it as + multipart/mixed and will thus be able to show the user the parts that + are recognized. + +5.1.2. Handling Nested Messages and Multiparts + + The "message/rfc822" subtype defined in a subsequent section of this + document has no terminating condition other than running out of data. + Similarly, an improperly truncated "multipart" entity may not have + any terminating boundary marker, and can turn up operationally due to + mail system malfunctions. + + It is essential that such entities be handled correctly when they are + themselves imbedded inside of another "multipart" structure. MIME + implementations are therefore required to recognize outer level + boundary markers at ANY level of inner nesting. It is not sufficient + to only check for the next expected marker or other terminating + condition. + +5.1.3. Mixed Subtype + + The "mixed" subtype of "multipart" is intended for use when the body + parts are independent and need to be bundled in a particular order. + Any "multipart" subtypes that an implementation does not recognize + must be treated as being of subtype "mixed". + +5.1.4. Alternative Subtype + + The "multipart/alternative" type is syntactically identical to + "multipart/mixed", but the semantics are different. In particular, + each of the body parts is an "alternative" version of the same + information. + + Systems should recognize that the content of the various parts are + interchangeable. Systems should choose the "best" type based on the + local environment and references, in some cases even through user + interaction. As with "multipart/mixed", the order of body parts is + significant. In this case, the alternatives appear in an order of + increasing faithfulness to the original content. In general, the + + + +Freed & Borenstein Standards Track [Page 24] + +RFC 2046 Media Types November 1996 + + + best choice is the LAST part of a type supported by the recipient + system's local environment. + + "Multipart/alternative" may be used, for example, to send a message + in a fancy text format in such a way that it can easily be displayed + anywhere: + + From: Nathaniel Borenstein + To: Ned Freed + Date: Mon, 22 Mar 1993 09:41:09 -0800 (PST) + Subject: Formatted text mail + MIME-Version: 1.0 + Content-Type: multipart/alternative; boundary=boundary42 + + --boundary42 + Content-Type: text/plain; charset=us-ascii + + ... plain text version of message goes here ... + + --boundary42 + Content-Type: text/enriched + + ... RFC 1896 text/enriched version of same message + goes here ... + + --boundary42 + Content-Type: application/x-whatever + + ... fanciest version of same message goes here ... + + --boundary42-- + + In this example, users whose mail systems understood the + "application/x-whatever" format would see only the fancy version, + while other users would see only the enriched or plain text version, + depending on the capabilities of their system. + + In general, user agents that compose "multipart/alternative" entities + must place the body parts in increasing order of preference, that is, + with the preferred format last. For fancy text, the sending user + agent should put the plainest format first and the richest format + last. Receiving user agents should pick and display the last format + they are capable of displaying. In the case where one of the + alternatives is itself of type "multipart" and contains unrecognized + sub-parts, the user agent may choose either to show that alternative, + an earlier alternative, or both. + + + + + +Freed & Borenstein Standards Track [Page 25] + +RFC 2046 Media Types November 1996 + + + NOTE: From an implementor's perspective, it might seem more sensible + to reverse this ordering, and have the plainest alternative last. + However, placing the plainest alternative first is the friendliest + possible option when "multipart/alternative" entities are viewed + using a non-MIME-conformant viewer. While this approach does impose + some burden on conformant MIME viewers, interoperability with older + mail readers was deemed to be more important in this case. + + It may be the case that some user agents, if they can recognize more + than one of the formats, will prefer to offer the user the choice of + which format to view. This makes sense, for example, if a message + includes both a nicely- formatted image version and an easily-edited + text version. What is most critical, however, is that the user not + automatically be shown multiple versions of the same data. Either + the user should be shown the last recognized version or should be + given the choice. + + THE SEMANTICS OF CONTENT-ID IN MULTIPART/ALTERNATIVE: Each part of a + "multipart/alternative" entity represents the same data, but the + mappings between the two are not necessarily without information + loss. For example, information is lost when translating ODA to + PostScript or plain text. It is recommended that each part should + have a different Content-ID value in the case where the information + content of the two parts is not identical. And when the information + content is identical -- for example, where several parts of type + "message/external-body" specify alternate ways to access the + identical data -- the same Content-ID field value should be used, to + optimize any caching mechanisms that might be present on the + recipient's end. However, the Content-ID values used by the parts + should NOT be the same Content-ID value that describes the + "multipart/alternative" as a whole, if there is any such Content-ID + field. That is, one Content-ID value will refer to the + "multipart/alternative" entity, while one or more other Content-ID + values will refer to the parts inside it. + +5.1.5. Digest Subtype + + This document defines a "digest" subtype of the "multipart" Content- + Type. This type is syntactically identical to "multipart/mixed", but + the semantics are different. In particular, in a digest, the default + Content-Type value for a body part is changed from "text/plain" to + "message/rfc822". This is done to allow a more readable digest + format that is largely compatible (except for the quoting convention) + with RFC 934. + + Note: Though it is possible to specify a Content-Type value for a + body part in a digest which is other than "message/rfc822", such as a + "text/plain" part containing a description of the material in the + + + +Freed & Borenstein Standards Track [Page 26] + +RFC 2046 Media Types November 1996 + + + digest, actually doing so is undesireble. The "multipart/digest" + Content-Type is intended to be used to send collections of messages. + If a "text/plain" part is needed, it should be included as a seperate + part of a "multipart/mixed" message. + + A digest in this format might, then, look something like this: + + From: Moderator-Address + To: Recipient-List + Date: Mon, 22 Mar 1994 13:34:51 +0000 + Subject: Internet Digest, volume 42 + MIME-Version: 1.0 + Content-Type: multipart/mixed; + boundary="---- main boundary ----" + + ------ main boundary ---- + + ...Introductory text or table of contents... + + ------ main boundary ---- + Content-Type: multipart/digest; + boundary="---- next message ----" + + ------ next message ---- + + From: someone-else + Date: Fri, 26 Mar 1993 11:13:32 +0200 + Subject: my opinion + + ...body goes here ... + + ------ next message ---- + + From: someone-else-again + Date: Fri, 26 Mar 1993 10:07:13 -0500 + Subject: my different opinion + + ... another body goes here ... + + ------ next message ------ + + ------ main boundary ------ + +5.1.6. Parallel Subtype + + This document defines a "parallel" subtype of the "multipart" + Content-Type. This type is syntactically identical to + "multipart/mixed", but the semantics are different. In particular, + + + +Freed & Borenstein Standards Track [Page 27] + +RFC 2046 Media Types November 1996 + + + in a parallel entity, the order of body parts is not significant. + + A common presentation of this type is to display all of the parts + simultaneously on hardware and software that are capable of doing so. + However, composing agents should be aware that many mail readers will + lack this capability and will show the parts serially in any event. + +5.1.7. Other Multipart Subtypes + + Other "multipart" subtypes are expected in the future. MIME + implementations must in general treat unrecognized subtypes of + "multipart" as being equivalent to "multipart/mixed". + +5.2. Message Media Type + + It is frequently desirable, in sending mail, to encapsulate another + mail message. A special media type, "message", is defined to + facilitate this. In particular, the "rfc822" subtype of "message" is + used to encapsulate RFC 822 messages. + + NOTE: It has been suggested that subtypes of "message" might be + defined for forwarded or rejected messages. However, forwarded and + rejected messages can be handled as multipart messages in which the + first part contains any control or descriptive information, and a + second part, of type "message/rfc822", is the forwarded or rejected + message. Composing rejection and forwarding messages in this manner + will preserve the type information on the original message and allow + it to be correctly presented to the recipient, and hence is strongly + encouraged. + + Subtypes of "message" often impose restrictions on what encodings are + allowed. These restrictions are described in conjunction with each + specific subtype. + + Mail gateways, relays, and other mail handling agents are commonly + known to alter the top-level header of an RFC 822 message. In + particular, they frequently add, remove, or reorder header fields. + These operations are explicitly forbidden for the encapsulated + headers embedded in the bodies of messages of type "message." + +5.2.1. RFC822 Subtype + + A media type of "message/rfc822" indicates that the body contains an + encapsulated message, with the syntax of an RFC 822 message. + However, unlike top-level RFC 822 messages, the restriction that each + "message/rfc822" body must include a "From", "Date", and at least one + destination header is removed and replaced with the requirement that + at least one of "From", "Subject", or "Date" must be present. + + + +Freed & Borenstein Standards Track [Page 28] + +RFC 2046 Media Types November 1996 + + + It should be noted that, despite the use of the numbers "822", a + "message/rfc822" entity isn't restricted to material in strict + conformance to RFC822, nor are the semantics of "message/rfc822" + objects restricted to the semantics defined in RFC822. More + specifically, a "message/rfc822" message could well be a News article + or a MIME message. + + No encoding other than "7bit", "8bit", or "binary" is permitted for + the body of a "message/rfc822" entity. The message header fields are + always US-ASCII in any case, and data within the body can still be + encoded, in which case the Content-Transfer-Encoding header field in + the encapsulated message will reflect this. Non-US-ASCII text in the + headers of an encapsulated message can be specified using the + mechanisms described in RFC 2047. + +5.2.2. Partial Subtype + + The "partial" subtype is defined to allow large entities to be + delivered as several separate pieces of mail and automatically + reassembled by a receiving user agent. (The concept is similar to IP + fragmentation and reassembly in the basic Internet Protocols.) This + mechanism can be used when intermediate transport agents limit the + size of individual messages that can be sent. The media type + "message/partial" thus indicates that the body contains a fragment of + a larger entity. + + Because data of type "message" may never be encoded in base64 or + quoted-printable, a problem might arise if "message/partial" entities + are constructed in an environment that supports binary or 8bit + transport. The problem is that the binary data would be split into + multiple "message/partial" messages, each of them requiring binary + transport. If such messages were encountered at a gateway into a + 7bit transport environment, there would be no way to properly encode + them for the 7bit world, aside from waiting for all of the fragments, + reassembling the inner message, and then encoding the reassembled + data in base64 or quoted-printable. Since it is possible that + different fragments might go through different gateways, even this is + not an acceptable solution. For this reason, it is specified that + entities of type "message/partial" must always have a content- + transfer-encoding of 7bit (the default). In particular, even in + environments that support binary or 8bit transport, the use of a + content- transfer-encoding of "8bit" or "binary" is explicitly + prohibited for MIME entities of type "message/partial". This in turn + implies that the inner message must not use "8bit" or "binary" + encoding. + + + + + + +Freed & Borenstein Standards Track [Page 29] + +RFC 2046 Media Types November 1996 + + + Because some message transfer agents may choose to automatically + fragment large messages, and because such agents may use very + different fragmentation thresholds, it is possible that the pieces of + a partial message, upon reassembly, may prove themselves to comprise + a partial message. This is explicitly permitted. + + Three parameters must be specified in the Content-Type field of type + "message/partial": The first, "id", is a unique identifier, as close + to a world-unique identifier as possible, to be used to match the + fragments together. (In general, the identifier is essentially a + message-id; if placed in double quotes, it can be ANY message-id, in + accordance with the BNF for "parameter" given in RFC 2045.) The + second, "number", an integer, is the fragment number, which indicates + where this fragment fits into the sequence of fragments. The third, + "total", another integer, is the total number of fragments. This + third subfield is required on the final fragment, and is optional + (though encouraged) on the earlier fragments. Note also that these + parameters may be given in any order. + + Thus, the second piece of a 3-piece message may have either of the + following header fields: + + Content-Type: Message/Partial; number=2; total=3; + id="oc=jpbe0M2Yt4s@thumper.bellcore.com" + + Content-Type: Message/Partial; + id="oc=jpbe0M2Yt4s@thumper.bellcore.com"; + number=2 + + But the third piece MUST specify the total number of fragments: + + Content-Type: Message/Partial; number=3; total=3; + id="oc=jpbe0M2Yt4s@thumper.bellcore.com" + + Note that fragment numbering begins with 1, not 0. + + When the fragments of an entity broken up in this manner are put + together, the result is always a complete MIME entity, which may have + its own Content-Type header field, and thus may contain any other + data type. + +5.2.2.1. Message Fragmentation and Reassembly + + The semantics of a reassembled partial message must be those of the + "inner" message, rather than of a message containing the inner + message. This makes it possible, for example, to send a large audio + message as several partial messages, and still have it appear to the + recipient as a simple audio message rather than as an encapsulated + + + +Freed & Borenstein Standards Track [Page 30] + +RFC 2046 Media Types November 1996 + + + message containing an audio message. That is, the encapsulation of + the message is considered to be "transparent". + + When generating and reassembling the pieces of a "message/partial" + message, the headers of the encapsulated message must be merged with + the headers of the enclosing entities. In this process the following + rules must be observed: + + (1) Fragmentation agents must split messages at line + boundaries only. This restriction is imposed because + splits at points other than the ends of lines in turn + depends on message transports being able to preserve + the semantics of messages that don't end with a CRLF + sequence. Many transports are incapable of preserving + such semantics. + + (2) All of the header fields from the initial enclosing + message, except those that start with "Content-" and + the specific header fields "Subject", "Message-ID", + "Encrypted", and "MIME-Version", must be copied, in + order, to the new message. + + (3) The header fields in the enclosed message which start + with "Content-", plus the "Subject", "Message-ID", + "Encrypted", and "MIME-Version" fields, must be + appended, in order, to the header fields of the new + message. Any header fields in the enclosed message + which do not start with "Content-" (except for the + "Subject", "Message-ID", "Encrypted", and "MIME- + Version" fields) will be ignored and dropped. + + (4) All of the header fields from the second and any + subsequent enclosing messages are discarded by the + reassembly process. + +5.2.2.2. Fragmentation and Reassembly Example + + If an audio message is broken into two pieces, the first piece might + look something like this: + + X-Weird-Header-1: Foo + From: Bill@host.com + To: joe@otherhost.com + Date: Fri, 26 Mar 1993 12:59:38 -0500 (EST) + Subject: Audio mail (part 1 of 2) + Message-ID: + MIME-Version: 1.0 + Content-type: message/partial; id="ABC@host.com"; + + + +Freed & Borenstein Standards Track [Page 31] + +RFC 2046 Media Types November 1996 + + + number=1; total=2 + + X-Weird-Header-1: Bar + X-Weird-Header-2: Hello + Message-ID: + Subject: Audio mail + MIME-Version: 1.0 + Content-type: audio/basic + Content-transfer-encoding: base64 + + ... first half of encoded audio data goes here ... + + and the second half might look something like this: + + From: Bill@host.com + To: joe@otherhost.com + Date: Fri, 26 Mar 1993 12:59:38 -0500 (EST) + Subject: Audio mail (part 2 of 2) + MIME-Version: 1.0 + Message-ID: + Content-type: message/partial; + id="ABC@host.com"; number=2; total=2 + + ... second half of encoded audio data goes here ... + + Then, when the fragmented message is reassembled, the resulting + message to be displayed to the user should look something like this: + + X-Weird-Header-1: Foo + From: Bill@host.com + To: joe@otherhost.com + Date: Fri, 26 Mar 1993 12:59:38 -0500 (EST) + Subject: Audio mail + Message-ID: + MIME-Version: 1.0 + Content-type: audio/basic + Content-transfer-encoding: base64 + + ... first half of encoded audio data goes here ... + ... second half of encoded audio data goes here ... + + The inclusion of a "References" field in the headers of the second + and subsequent pieces of a fragmented message that references the + Message-Id on the previous piece may be of benefit to mail readers + that understand and track references. However, the generation of + such "References" fields is entirely optional. + + + + + +Freed & Borenstein Standards Track [Page 32] + +RFC 2046 Media Types November 1996 + + + Finally, it should be noted that the "Encrypted" header field has + been made obsolete by Privacy Enhanced Messaging (PEM) [RFC-1421, + RFC-1422, RFC-1423, RFC-1424], but the rules above are nevertheless + believed to describe the correct way to treat it if it is encountered + in the context of conversion to and from "message/partial" fragments. + +5.2.3. External-Body Subtype + + The external-body subtype indicates that the actual body data are not + included, but merely referenced. In this case, the parameters + describe a mechanism for accessing the external data. + + When a MIME entity is of type "message/external-body", it consists of + a header, two consecutive CRLFs, and the message header for the + encapsulated message. If another pair of consecutive CRLFs appears, + this of course ends the message header for the encapsulated message. + However, since the encapsulated message's body is itself external, it + does NOT appear in the area that follows. For example, consider the + following message: + + Content-type: message/external-body; + access-type=local-file; + name="/u/nsb/Me.jpeg" + + Content-type: image/jpeg + Content-ID: + Content-Transfer-Encoding: binary + + THIS IS NOT REALLY THE BODY! + + The area at the end, which might be called the "phantom body", is + ignored for most external-body messages. However, it may be used to + contain auxiliary information for some such messages, as indeed it is + when the access-type is "mail- server". The only access-type defined + in this document that uses the phantom body is "mail-server", but + other access-types may be defined in the future in other + specifications that use this area. + + The encapsulated headers in ALL "message/external-body" entities MUST + include a Content-ID header field to give a unique identifier by + which to reference the data. This identifier may be used for caching + mechanisms, and for recognizing the receipt of the data when the + access-type is "mail-server". + + Note that, as specified here, the tokens that describe external-body + data, such as file names and mail server commands, are required to be + in the US-ASCII character set. + + + + +Freed & Borenstein Standards Track [Page 33] + +RFC 2046 Media Types November 1996 + + + If this proves problematic in practice, a new mechanism may be + required as a future extension to MIME, either as newly defined + access-types for "message/external-body" or by some other mechanism. + + As with "message/partial", MIME entities of type "message/external- + body" MUST have a content-transfer-encoding of 7bit (the default). + In particular, even in environments that support binary or 8bit + transport, the use of a content- transfer-encoding of "8bit" or + "binary" is explicitly prohibited for entities of type + "message/external-body". + +5.2.3.1. General External-Body Parameters + + The parameters that may be used with any "message/external- body" + are: + + (1) ACCESS-TYPE -- A word indicating the supported access + mechanism by which the file or data may be obtained. + This word is not case sensitive. Values include, but + are not limited to, "FTP", "ANON-FTP", "TFTP", "LOCAL- + FILE", and "MAIL-SERVER". Future values, except for + experimental values beginning with "X-", must be + registered with IANA, as described in RFC 2048. + This parameter is unconditionally mandatory and MUST be + present on EVERY "message/external-body". + + (2) EXPIRATION -- The date (in the RFC 822 "date-time" + syntax, as extended by RFC 1123 to permit 4 digits in + the year field) after which the existence of the + external data is not guaranteed. This parameter may be + used with ANY access-type and is ALWAYS optional. + + (3) SIZE -- The size (in octets) of the data. The intent + of this parameter is to help the recipient decide + whether or not to expend the necessary resources to + retrieve the external data. Note that this describes + the size of the data in its canonical form, that is, + before any Content-Transfer-Encoding has been applied + or after the data have been decoded. This parameter + may be used with ANY access-type and is ALWAYS + optional. + + (4) PERMISSION -- A case-insensitive field that indicates + whether or not it is expected that clients might also + attempt to overwrite the data. By default, or if + permission is "read", the assumption is that they are + not, and that if the data is retrieved once, it is + never needed again. If PERMISSION is "read-write", + + + +Freed & Borenstein Standards Track [Page 34] + +RFC 2046 Media Types November 1996 + + + this assumption is invalid, and any local copy must be + considered no more than a cache. "Read" and "Read- + write" are the only defined values of permission. This + parameter may be used with ANY access-type and is + ALWAYS optional. + + The precise semantics of the access-types defined here are described + in the sections that follow. + +5.2.3.2. The 'ftp' and 'tftp' Access-Types + + An access-type of FTP or TFTP indicates that the message body is + accessible as a file using the FTP [RFC-959] or TFTP [RFC- 783] + protocols, respectively. For these access-types, the following + additional parameters are mandatory: + + (1) NAME -- The name of the file that contains the actual + body data. + + (2) SITE -- A machine from which the file may be obtained, + using the given protocol. This must be a fully + qualified domain name, not a nickname. + + (3) Before any data are retrieved, using FTP, the user will + generally need to be asked to provide a login id and a + password for the machine named by the site parameter. + For security reasons, such an id and password are not + specified as content-type parameters, but must be + obtained from the user. + + In addition, the following parameters are optional: + + (1) DIRECTORY -- A directory from which the data named by + NAME should be retrieved. + + (2) MODE -- A case-insensitive string indicating the mode + to be used when retrieving the information. The valid + values for access-type "TFTP" are "NETASCII", "OCTET", + and "MAIL", as specified by the TFTP protocol [RFC- + 783]. The valid values for access-type "FTP" are + "ASCII", "EBCDIC", "IMAGE", and "LOCALn" where "n" is a + decimal integer, typically 8. These correspond to the + representation types "A" "E" "I" and "L n" as specified + by the FTP protocol [RFC-959]. Note that "BINARY" and + "TENEX" are not valid values for MODE and that "OCTET" + or "IMAGE" or "LOCAL8" should be used instead. IF MODE + is not specified, the default value is "NETASCII" for + TFTP and "ASCII" otherwise. + + + +Freed & Borenstein Standards Track [Page 35] + +RFC 2046 Media Types November 1996 + + +5.2.3.3. The 'anon-ftp' Access-Type + + The "anon-ftp" access-type is identical to the "ftp" access type, + except that the user need not be asked to provide a name and password + for the specified site. Instead, the ftp protocol will be used with + login "anonymous" and a password that corresponds to the user's mail + address. + +5.2.3.4. The 'local-file' Access-Type + + An access-type of "local-file" indicates that the actual body is + accessible as a file on the local machine. Two additional parameters + are defined for this access type: + + (1) NAME -- The name of the file that contains the actual + body data. This parameter is mandatory for the + "local-file" access-type. + + (2) SITE -- A domain specifier for a machine or set of + machines that are known to have access to the data + file. This optional parameter is used to describe the + locality of reference for the data, that is, the site + or sites at which the file is expected to be visible. + Asterisks may be used for wildcard matching to a part + of a domain name, such as "*.bellcore.com", to indicate + a set of machines on which the data should be directly + visible, while a single asterisk may be used to + indicate a file that is expected to be universally + available, e.g., via a global file system. + +5.2.3.5. The 'mail-server' Access-Type + + The "mail-server" access-type indicates that the actual body is + available from a mail server. Two additional parameters are defined + for this access-type: + + (1) SERVER -- The addr-spec of the mail server from which + the actual body data can be obtained. This parameter + is mandatory for the "mail-server" access-type. + + (2) SUBJECT -- The subject that is to be used in the mail + that is sent to obtain the data. Note that keying mail + servers on Subject lines is NOT recommended, but such + mail servers are known to exist. This is an optional + parameter. + + + + + + +Freed & Borenstein Standards Track [Page 36] + +RFC 2046 Media Types November 1996 + + + Because mail servers accept a variety of syntaxes, some of which is + multiline, the full command to be sent to a mail server is not + included as a parameter in the content-type header field. Instead, + it is provided as the "phantom body" when the media type is + "message/external-body" and the access-type is mail-server. + + Note that MIME does not define a mail server syntax. Rather, it + allows the inclusion of arbitrary mail server commands in the phantom + body. Implementations must include the phantom body in the body of + the message it sends to the mail server address to retrieve the + relevant data. + + Unlike other access-types, mail-server access is asynchronous and + will happen at an unpredictable time in the future. For this reason, + it is important that there be a mechanism by which the returned data + can be matched up with the original "message/external-body" entity. + MIME mail servers must use the same Content-ID field on the returned + message that was used in the original "message/external-body" + entities, to facilitate such matching. + +5.2.3.6. External-Body Security Issues + + "Message/external-body" entities give rise to two important security + issues: + + (1) Accessing data via a "message/external-body" reference + effectively results in the message recipient performing + an operation that was specified by the message + originator. It is therefore possible for the message + originator to trick a recipient into doing something + they would not have done otherwise. For example, an + originator could specify a action that attempts + retrieval of material that the recipient is not + authorized to obtain, causing the recipient to + unwittingly violate some security policy. For this + reason, user agents capable of resolving external + references must always take steps to describe the + action they are to take to the recipient and ask for + explicit permisssion prior to performing it. + + The 'mail-server' access-type is particularly + vulnerable, in that it causes the recipient to send a + new message whose contents are specified by the + original message's originator. Given the potential for + abuse, any such request messages that are constructed + should contain a clear indication that they were + generated automatically (e.g. in a Comments: header + field) in an attempt to resolve a MIME + + + +Freed & Borenstein Standards Track [Page 37] + +RFC 2046 Media Types November 1996 + + + "message/external-body" reference. + + (2) MIME will sometimes be used in environments that + provide some guarantee of message integrity and + authenticity. If present, such guarantees may apply + only to the actual direct content of messages -- they + may or may not apply to data accessed through MIME's + "message/external-body" mechanism. In particular, it + may be possible to subvert certain access mechanisms + even when the messaging system itself is secure. + + It should be noted that this problem exists either with + or without the availabilty of MIME mechanisms. A + casual reference to an FTP site containing a document + in the text of a secure message brings up similar + issues -- the only difference is that MIME provides for + automatic retrieval of such material, and users may + place unwarranted trust is such automatic retrieval + mechanisms. + +5.2.3.7. Examples and Further Explanations + + When the external-body mechanism is used in conjunction with the + "multipart/alternative" media type it extends the functionality of + "multipart/alternative" to include the case where the same entity is + provided in the same format but via different accces mechanisms. + When this is done the originator of the message must order the parts + first in terms of preferred formats and then by preferred access + mechanisms. The recipient's viewer should then evaluate the list + both in terms of format and access mechanisms. + + With the emerging possibility of very wide-area file systems, it + becomes very hard to know in advance the set of machines where a file + will and will not be accessible directly from the file system. + Therefore it may make sense to provide both a file name, to be tried + directly, and the name of one or more sites from which the file is + known to be accessible. An implementation can try to retrieve remote + files using FTP or any other protocol, using anonymous file retrieval + or prompting the user for the necessary name and password. If an + external body is accessible via multiple mechanisms, the sender may + include multiple entities of type "message/external-body" within the + body parts of an enclosing "multipart/alternative" entity. + + However, the external-body mechanism is not intended to be limited to + file retrieval, as shown by the mail-server access-type. Beyond + this, one can imagine, for example, using a video server for external + references to video clips. + + + + +Freed & Borenstein Standards Track [Page 38] + +RFC 2046 Media Types November 1996 + + + The embedded message header fields which appear in the body of the + "message/external-body" data must be used to declare the media type + of the external body if it is anything other than plain US-ASCII + text, since the external body does not have a header section to + declare its type. Similarly, any Content-transfer-encoding other + than "7bit" must also be declared here. Thus a complete + "message/external-body" message, referring to an object in PostScript + format, might look like this: + + From: Whomever + To: Someone + Date: Whenever + Subject: whatever + MIME-Version: 1.0 + Message-ID: + Content-Type: multipart/alternative; boundary=42 + Content-ID: + + --42 + Content-Type: message/external-body; name="BodyFormats.ps"; + site="thumper.bellcore.com"; mode="image"; + access-type=ANON-FTP; directory="pub"; + expiration="Fri, 14 Jun 1991 19:13:14 -0400 (EDT)" + + Content-type: application/postscript + Content-ID: + + --42 + Content-Type: message/external-body; access-type=local-file; + name="/u/nsb/writing/rfcs/RFC-MIME.ps"; + site="thumper.bellcore.com"; + expiration="Fri, 14 Jun 1991 19:13:14 -0400 (EDT)" + + Content-type: application/postscript + Content-ID: + + --42 + Content-Type: message/external-body; + access-type=mail-server + server="listserv@bogus.bitnet"; + expiration="Fri, 14 Jun 1991 19:13:14 -0400 (EDT)" + + Content-type: application/postscript + Content-ID: + + get RFC-MIME.DOC + + --42-- + + + +Freed & Borenstein Standards Track [Page 39] + +RFC 2046 Media Types November 1996 + + + Note that in the above examples, the default Content-transfer- + encoding of "7bit" is assumed for the external postscript data. + + Like the "message/partial" type, the "message/external-body" media + type is intended to be transparent, that is, to convey the data type + in the external body rather than to convey a message with a body of + that type. Thus the headers on the outer and inner parts must be + merged using the same rules as for "message/partial". In particular, + this means that the Content-type and Subject fields are overridden, + but the From field is preserved. + + Note that since the external bodies are not transported along with + the external body reference, they need not conform to transport + limitations that apply to the reference itself. In particular, + Internet mail transports may impose 7bit and line length limits, but + these do not automatically apply to binary external body references. + Thus a Content-Transfer-Encoding is not generally necessary, though + it is permitted. + + Note that the body of a message of type "message/external-body" is + governed by the basic syntax for an RFC 822 message. In particular, + anything before the first consecutive pair of CRLFs is header + information, while anything after it is body information, which is + ignored for most access-types. + +5.2.4. Other Message Subtypes + + MIME implementations must in general treat unrecognized subtypes of + "message" as being equivalent to "application/octet-stream". + + Future subtypes of "message" intended for use with email should be + restricted to "7bit" encoding. A type other than "message" should be + used if restriction to "7bit" is not possible. + +6. Experimental Media Type Values + + A media type value beginning with the characters "X-" is a private + value, to be used by consenting systems by mutual agreement. Any + format without a rigorous and public definition must be named with an + "X-" prefix, and publicly specified values shall never begin with + "X-". (Older versions of the widely used Andrew system use the "X- + BE2" name, so new systems should probably choose a different name.) + + In general, the use of "X-" top-level types is strongly discouraged. + Implementors should invent subtypes of the existing types whenever + possible. In many cases, a subtype of "application" will be more + appropriate than a new top-level type. + + + + +Freed & Borenstein Standards Track [Page 40] + +RFC 2046 Media Types November 1996 + + +7. Summary + + The five discrete media types provide provide a standardized + mechanism for tagging entities as "audio", "image", or several other + kinds of data. The composite "multipart" and "message" media types + allow mixing and hierarchical structuring of entities of different + types in a single message. A distinguished parameter syntax allows + further specification of data format details, particularly the + specification of alternate character sets. Additional optional + header fields provide mechanisms for certain extensions deemed + desirable by many implementors. Finally, a number of useful media + types are defined for general use by consenting user agents, notably + "message/partial" and "message/external-body". + +9. Security Considerations + + Security issues are discussed in the context of the + "application/postscript" type, the "message/external-body" type, and + in RFC 2048. Implementors should pay special attention to the + security implications of any media types that can cause the remote + execution of any actions in the recipient's environment. In such + cases, the discussion of the "application/postscript" type may serve + as a model for considering other media types with remote execution + capabilities. + + + + + + + + + + + + + + + + + + + + + + + + + + + +Freed & Borenstein Standards Track [Page 41] + +RFC 2046 Media Types November 1996 + + +9. Authors' Addresses + + For more information, the authors of this document are best contacted + via Internet mail: + + Ned Freed + Innosoft International, Inc. + 1050 East Garvey Avenue South + West Covina, CA 91790 + USA + + Phone: +1 818 919 3600 + Fax: +1 818 919 3614 + EMail: ned@innosoft.com + + + Nathaniel S. Borenstein + First Virtual Holdings + 25 Washington Avenue + Morristown, NJ 07960 + USA + + Phone: +1 201 540 8967 + Fax: +1 201 993 3032 + EMail: nsb@nsb.fv.com + + + MIME is a result of the work of the Internet Engineering Task Force + Working Group on RFC 822 Extensions. The chairman of that group, + Greg Vaudreuil, may be reached at: + + Gregory M. Vaudreuil + Octel Network Services + 17080 Dallas Parkway + Dallas, TX 75248-1905 + USA + + EMail: Greg.Vaudreuil@Octel.Com + + + + + + + + + + + + + +Freed & Borenstein Standards Track [Page 42] + +RFC 2046 Media Types November 1996 + + +Appendix A -- Collected Grammar + + This appendix contains the complete BNF grammar for all the syntax + specified by this document. + + By itself, however, this grammar is incomplete. It refers by name to + several syntax rules that are defined by RFC 822. Rather than + reproduce those definitions here, and risk unintentional differences + between the two, this document simply refers the reader to RFC 822 + for the remaining definitions. Wherever a term is undefined, it + refers to the RFC 822 definition. + + boundary := 0*69 bcharsnospace + + bchars := bcharsnospace / " " + + bcharsnospace := DIGIT / ALPHA / "'" / "(" / ")" / + "+" / "_" / "," / "-" / "." / + "/" / ":" / "=" / "?" + + body-part := <"message" as defined in RFC 822, with all + header fields optional, not starting with the + specified dash-boundary, and with the + delimiter not occurring anywhere in the + body part. Note that the semantics of a + part differ from the semantics of a message, + as described in the text.> + + close-delimiter := delimiter "--" + + dash-boundary := "--" boundary + ; boundary taken from the value of + ; boundary parameter of the + ; Content-Type field. + + delimiter := CRLF dash-boundary + + discard-text := *(*text CRLF) + ; May be ignored or discarded. + + encapsulation := delimiter transport-padding + CRLF body-part + + epilogue := discard-text + + multipart-body := [preamble CRLF] + dash-boundary transport-padding CRLF + body-part *encapsulation + + + +Freed & Borenstein Standards Track [Page 43] + +RFC 2046 Media Types November 1996 + + + close-delimiter transport-padding + [CRLF epilogue] + + preamble := discard-text + + transport-padding := *LWSP-char + ; Composers MUST NOT generate + ; non-zero length transport + ; padding, but receivers MUST + ; be able to handle padding + ; added by message transports. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Freed & Borenstein Standards Track [Page 44] + diff --git a/RFCs/rfc2047.txt b/RFCs/rfc2047.txt new file mode 100644 index 0000000..ff9a744 --- /dev/null +++ b/RFCs/rfc2047.txt @@ -0,0 +1,843 @@ + + + + + + +Network Working Group K. Moore +Request for Comments: 2047 University of Tennessee +Obsoletes: 1521, 1522, 1590 November 1996 +Category: Standards Track + + + MIME (Multipurpose Internet Mail Extensions) Part Three: + Message Header Extensions for Non-ASCII Text + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Abstract + + STD 11, RFC 822, defines a message representation protocol specifying + considerable detail about US-ASCII message headers, and leaves the + message content, or message body, as flat US-ASCII text. This set of + documents, collectively called the Multipurpose Internet Mail + Extensions, or MIME, redefines the format of messages to allow for + + (1) textual message bodies in character sets other than US-ASCII, + + (2) an extensible set of different formats for non-textual message + bodies, + + (3) multi-part message bodies, and + + (4) textual header information in character sets other than US-ASCII. + + These documents are based on earlier work documented in RFC 934, STD + 11, and RFC 1049, but extends and revises them. Because RFC 822 said + so little about message bodies, these documents are largely + orthogonal to (rather than a revision of) RFC 822. + + This particular document is the third document in the series. It + describes extensions to RFC 822 to allow non-US-ASCII text data in + Internet mail header fields. + + + + + + + + + +Moore Standards Track [Page 1] + +RFC 2047 Message Header Extensions November 1996 + + + Other documents in this series include: + + + RFC 2045, which specifies the various headers used to describe + the structure of MIME messages. + + + RFC 2046, which defines the general structure of the MIME media + typing system and defines an initial set of media types, + + + RFC 2048, which specifies various IANA registration procedures + for MIME-related facilities, and + + + RFC 2049, which describes MIME conformance criteria and + provides some illustrative examples of MIME message formats, + acknowledgements, and the bibliography. + + These documents are revisions of RFCs 1521, 1522, and 1590, which + themselves were revisions of RFCs 1341 and 1342. An appendix in RFC + 2049 describes differences and changes from previous versions. + +1. Introduction + + RFC 2045 describes a mechanism for denoting textual body parts which + are coded in various character sets, as well as methods for encoding + such body parts as sequences of printable US-ASCII characters. This + memo describes similar techniques to allow the encoding of non-ASCII + text in various portions of a RFC 822 [2] message header, in a manner + which is unlikely to confuse existing message handling software. + + Like the encoding techniques described in RFC 2045, the techniques + outlined here were designed to allow the use of non-ASCII characters + in message headers in a way which is unlikely to be disturbed by the + quirks of existing Internet mail handling programs. In particular, + some mail relaying programs are known to (a) delete some message + header fields while retaining others, (b) rearrange the order of + addresses in To or Cc fields, (c) rearrange the (vertical) order of + header fields, and/or (d) "wrap" message headers at different places + than those in the original message. In addition, some mail reading + programs are known to have difficulty correctly parsing message + headers which, while legal according to RFC 822, make use of + backslash-quoting to "hide" special characters such as "<", ",", or + ":", or which exploit other infrequently-used features of that + specification. + + While it is unfortunate that these programs do not correctly + interpret RFC 822 headers, to "break" these programs would cause + severe operational problems for the Internet mail system. The + extensions described in this memo therefore do not rely on little- + used features of RFC 822. + + + +Moore Standards Track [Page 2] + +RFC 2047 Message Header Extensions November 1996 + + + Instead, certain sequences of "ordinary" printable ASCII characters + (known as "encoded-words") are reserved for use as encoded data. The + syntax of encoded-words is such that they are unlikely to + "accidentally" appear as normal text in message headers. + Furthermore, the characters used in encoded-words are restricted to + those which do not have special meanings in the context in which the + encoded-word appears. + + Generally, an "encoded-word" is a sequence of printable ASCII + characters that begins with "=?", ends with "?=", and has two "?"s in + between. It specifies a character set and an encoding method, and + also includes the original text encoded as graphic ASCII characters, + according to the rules for that encoding method. + + A mail composer that implements this specification will provide a + means of inputting non-ASCII text in header fields, but will + translate these fields (or appropriate portions of these fields) into + encoded-words before inserting them into the message header. + + A mail reader that implements this specification will recognize + encoded-words when they appear in certain portions of the message + header. Instead of displaying the encoded-word "as is", it will + reverse the encoding and display the original text in the designated + character set. + +NOTES + + This memo relies heavily on notation and terms defined RFC 822 and + RFC 2045. In particular, the syntax for the ABNF used in this memo + is defined in RFC 822, as well as many of the terminal or nonterminal + symbols from RFC 822 are used in the grammar for the header + extensions defined here. Among the symbols defined in RFC 822 and + referenced in this memo are: 'addr-spec', 'atom', 'CHAR', 'comment', + 'CTLs', 'ctext', 'linear-white-space', 'phrase', 'quoted-pair'. + 'quoted-string', 'SPACE', and 'word'. Successful implementation of + this protocol extension requires careful attention to the RFC 822 + definitions of these terms. + + When the term "ASCII" appears in this memo, it refers to the "7-Bit + American Standard Code for Information Interchange", ANSI X3.4-1986. + The MIME charset name for this character set is "US-ASCII". When not + specifically referring to the MIME charset name, this document uses + the term "ASCII", both for brevity and for consistency with RFC 822. + However, implementors are warned that the character set name must be + spelled "US-ASCII" in MIME message and body part headers. + + + + + + +Moore Standards Track [Page 3] + +RFC 2047 Message Header Extensions November 1996 + + + This memo specifies a protocol for the representation of non-ASCII + text in message headers. It specifically DOES NOT define any + translation between "8-bit headers" and pure ASCII headers, nor is + any such translation assumed to be possible. + +2. Syntax of encoded-words + + An 'encoded-word' is defined by the following ABNF grammar. The + notation of RFC 822 is used, with the exception that white space + characters MUST NOT appear between components of an 'encoded-word'. + + encoded-word = "=?" charset "?" encoding "?" encoded-text "?=" + + charset = token ; see section 3 + + encoding = token ; see section 4 + + token = 1* + + especials = "(" / ")" / "<" / ">" / "@" / "," / ";" / ":" / " + <"> / "/" / "[" / "]" / "?" / "." / "=" + + encoded-text = 1* + ; (but see "Use of encoded-words in message + ; headers", section 5) + + Both 'encoding' and 'charset' names are case-independent. Thus the + charset name "ISO-8859-1" is equivalent to "iso-8859-1", and the + encoding named "Q" may be spelled either "Q" or "q". + + An 'encoded-word' may not be more than 75 characters long, including + 'charset', 'encoding', 'encoded-text', and delimiters. If it is + desirable to encode more text than will fit in an 'encoded-word' of + 75 characters, multiple 'encoded-word's (separated by CRLF SPACE) may + be used. + + While there is no limit to the length of a multiple-line header + field, each line of a header field that contains one or more + 'encoded-word's is limited to 76 characters. + + The length restrictions are included both to ease interoperability + through internetwork mail gateways, and to impose a limit on the + amount of lookahead a header parser must employ (while looking for a + final ?= delimiter) before it can decide whether a token is an + "encoded-word" or something else. + + + + + +Moore Standards Track [Page 4] + +RFC 2047 Message Header Extensions November 1996 + + + IMPORTANT: 'encoded-word's are designed to be recognized as 'atom's + by an RFC 822 parser. As a consequence, unencoded white space + characters (such as SPACE and HTAB) are FORBIDDEN within an + 'encoded-word'. For example, the character sequence + + =?iso-8859-1?q?this is some text?= + + would be parsed as four 'atom's, rather than as a single 'atom' (by + an RFC 822 parser) or 'encoded-word' (by a parser which understands + 'encoded-words'). The correct way to encode the string "this is some + text" is to encode the SPACE characters as well, e.g. + + =?iso-8859-1?q?this=20is=20some=20text?= + + The characters which may appear in 'encoded-text' are further + restricted by the rules in section 5. + +3. Character sets + + The 'charset' portion of an 'encoded-word' specifies the character + set associated with the unencoded text. A 'charset' can be any of + the character set names allowed in an MIME "charset" parameter of a + "text/plain" body part, or any character set name registered with + IANA for use with the MIME text/plain content-type. + + Some character sets use code-switching techniques to switch between + "ASCII mode" and other modes. If unencoded text in an 'encoded-word' + contains a sequence which causes the charset interpreter to switch + out of ASCII mode, it MUST contain additional control codes such that + ASCII mode is again selected at the end of the 'encoded-word'. (This + rule applies separately to each 'encoded-word', including adjacent + 'encoded-word's within a single header field.) + + When there is a possibility of using more than one character set to + represent the text in an 'encoded-word', and in the absence of + private agreements between sender and recipients of a message, it is + recommended that members of the ISO-8859-* series be used in + preference to other character sets. + +4. Encodings + + Initially, the legal values for "encoding" are "Q" and "B". These + encodings are described below. The "Q" encoding is recommended for + use when most of the characters to be encoded are in the ASCII + character set; otherwise, the "B" encoding should be used. + Nevertheless, a mail reader which claims to recognize 'encoded-word's + MUST be able to accept either encoding for any character set which it + supports. + + + +Moore Standards Track [Page 5] + +RFC 2047 Message Header Extensions November 1996 + + + Only a subset of the printable ASCII characters may be used in + 'encoded-text'. Space and tab characters are not allowed, so that + the beginning and end of an 'encoded-word' are obvious. The "?" + character is used within an 'encoded-word' to separate the various + portions of the 'encoded-word' from one another, and thus cannot + appear in the 'encoded-text' portion. Other characters are also + illegal in certain contexts. For example, an 'encoded-word' in a + 'phrase' preceding an address in a From header field may not contain + any of the "specials" defined in RFC 822. Finally, certain other + characters are disallowed in some contexts, to ensure reliability for + messages that pass through internetwork mail gateways. + + The "B" encoding automatically meets these requirements. The "Q" + encoding allows a wide range of printable characters to be used in + non-critical locations in the message header (e.g., Subject), with + fewer characters available for use in other locations. + +4.1. The "B" encoding + + The "B" encoding is identical to the "BASE64" encoding defined by RFC + 2045. + +4.2. The "Q" encoding + + The "Q" encoding is similar to the "Quoted-Printable" content- + transfer-encoding defined in RFC 2045. It is designed to allow text + containing mostly ASCII characters to be decipherable on an ASCII + terminal without decoding. + + (1) Any 8-bit value may be represented by a "=" followed by two + hexadecimal digits. For example, if the character set in use + were ISO-8859-1, the "=" character would thus be encoded as + "=3D", and a SPACE by "=20". (Upper case should be used for + hexadecimal digits "A" through "F".) + + (2) The 8-bit hexadecimal value 20 (e.g., ISO-8859-1 SPACE) may be + represented as "_" (underscore, ASCII 95.). (This character may + not pass through some internetwork mail gateways, but its use + will greatly enhance readability of "Q" encoded data with mail + readers that do not support this encoding.) Note that the "_" + always represents hexadecimal 20, even if the SPACE character + occupies a different code position in the character set in use. + + (3) 8-bit values which correspond to printable ASCII characters other + than "=", "?", and "_" (underscore), MAY be represented as those + characters. (But see section 5 for restrictions.) In + particular, SPACE and TAB MUST NOT be represented as themselves + within encoded words. + + + +Moore Standards Track [Page 6] + +RFC 2047 Message Header Extensions November 1996 + + +5. Use of encoded-words in message headers + + An 'encoded-word' may appear in a message header or body part header + according to the following rules: + +(1) An 'encoded-word' may replace a 'text' token (as defined by RFC 822) + in any Subject or Comments header field, any extension message + header field, or any MIME body part field for which the field body + is defined as '*text'. An 'encoded-word' may also appear in any + user-defined ("X-") message or body part header field. + + Ordinary ASCII text and 'encoded-word's may appear together in the + same header field. However, an 'encoded-word' that appears in a + header field defined as '*text' MUST be separated from any adjacent + 'encoded-word' or 'text' by 'linear-white-space'. + +(2) An 'encoded-word' may appear within a 'comment' delimited by "(" and + ")", i.e., wherever a 'ctext' is allowed. More precisely, the RFC + 822 ABNF definition for 'comment' is amended as follows: + + comment = "(" *(ctext / quoted-pair / comment / encoded-word) ")" + + A "Q"-encoded 'encoded-word' which appears in a 'comment' MUST NOT + contain the characters "(", ")" or " + 'encoded-word' that appears in a 'comment' MUST be separated from + any adjacent 'encoded-word' or 'ctext' by 'linear-white-space'. + + It is important to note that 'comment's are only recognized inside + "structured" field bodies. In fields whose bodies are defined as + '*text', "(" and ")" are treated as ordinary characters rather than + comment delimiters, and rule (1) of this section applies. (See RFC + 822, sections 3.1.2 and 3.1.3) + +(3) As a replacement for a 'word' entity within a 'phrase', for example, + one that precedes an address in a From, To, or Cc header. The ABNF + definition for 'phrase' from RFC 822 thus becomes: + + phrase = 1*( encoded-word / word ) + + In this case the set of characters that may be used in a "Q"-encoded + 'encoded-word' is restricted to: . An 'encoded-word' that appears within a + 'phrase' MUST be separated from any adjacent 'word', 'text' or + 'special' by 'linear-white-space'. + + + + + + +Moore Standards Track [Page 7] + +RFC 2047 Message Header Extensions November 1996 + + + These are the ONLY locations where an 'encoded-word' may appear. In + particular: + + + An 'encoded-word' MUST NOT appear in any portion of an 'addr-spec'. + + + An 'encoded-word' MUST NOT appear within a 'quoted-string'. + + + An 'encoded-word' MUST NOT be used in a Received header field. + + + An 'encoded-word' MUST NOT be used in parameter of a MIME + Content-Type or Content-Disposition field, or in any structured + field body except within a 'comment' or 'phrase'. + + The 'encoded-text' in an 'encoded-word' must be self-contained; + 'encoded-text' MUST NOT be continued from one 'encoded-word' to + another. This implies that the 'encoded-text' portion of a "B" + 'encoded-word' will be a multiple of 4 characters long; for a "Q" + 'encoded-word', any "=" character that appears in the 'encoded-text' + portion will be followed by two hexadecimal characters. + + Each 'encoded-word' MUST encode an integral number of octets. The + 'encoded-text' in each 'encoded-word' must be well-formed according + to the encoding specified; the 'encoded-text' may not be continued in + the next 'encoded-word'. (For example, "=?charset?Q?=?= + =?charset?Q?AB?=" would be illegal, because the two hex digits "AB" + must follow the "=" in the same 'encoded-word'.) + + Each 'encoded-word' MUST represent an integral number of characters. + A multi-octet character may not be split across adjacent 'encoded- + word's. + + Only printable and white space character data should be encoded using + this scheme. However, since these encoding schemes allow the + encoding of arbitrary octet values, mail readers that implement this + decoding should also ensure that display of the decoded data on the + recipient's terminal will not cause unwanted side-effects. + + Use of these methods to encode non-textual data (e.g., pictures or + sounds) is not defined by this memo. Use of 'encoded-word's to + represent strings of purely ASCII characters is allowed, but + discouraged. In rare cases it may be necessary to encode ordinary + text that looks like an 'encoded-word'. + + + + + + + + + +Moore Standards Track [Page 8] + +RFC 2047 Message Header Extensions November 1996 + + +6. Support of 'encoded-word's by mail readers + +6.1. Recognition of 'encoded-word's in message headers + + A mail reader must parse the message and body part headers according + to the rules in RFC 822 to correctly recognize 'encoded-word's. + + 'encoded-word's are to be recognized as follows: + + (1) Any message or body part header field defined as '*text', or any + user-defined header field, should be parsed as follows: Beginning + at the start of the field-body and immediately following each + occurrence of 'linear-white-space', each sequence of up to 75 + printable characters (not containing any 'linear-white-space') + should be examined to see if it is an 'encoded-word' according to + the syntax rules in section 2. Any other sequence of printable + characters should be treated as ordinary ASCII text. + + (2) Any header field not defined as '*text' should be parsed + according to the syntax rules for that header field. However, + any 'word' that appears within a 'phrase' should be treated as an + 'encoded-word' if it meets the syntax rules in section 2. + Otherwise it should be treated as an ordinary 'word'. + + (3) Within a 'comment', any sequence of up to 75 printable characters + (not containing 'linear-white-space'), that meets the syntax + rules in section 2, should be treated as an 'encoded-word'. + Otherwise it should be treated as normal comment text. + + (4) A MIME-Version header field is NOT required to be present for + 'encoded-word's to be interpreted according to this + specification. One reason for this is that the mail reader is + not expected to parse the entire message header before displaying + lines that may contain 'encoded-word's. + +6.2. Display of 'encoded-word's + + Any 'encoded-word's so recognized are decoded, and if possible, the + resulting unencoded text is displayed in the original character set. + + NOTE: Decoding and display of encoded-words occurs *after* a + structured field body is parsed into tokens. It is therefore + possible to hide 'special' characters in encoded-words which, when + displayed, will be indistinguishable from 'special' characters in the + surrounding text. For this and other reasons, it is NOT generally + possible to translate a message header containing 'encoded-word's to + an unencoded form which can be parsed by an RFC 822 mail reader. + + + + +Moore Standards Track [Page 9] + +RFC 2047 Message Header Extensions November 1996 + + + When displaying a particular header field that contains multiple + 'encoded-word's, any 'linear-white-space' that separates a pair of + adjacent 'encoded-word's is ignored. (This is to allow the use of + multiple 'encoded-word's to represent long strings of unencoded text, + without having to separate 'encoded-word's where spaces occur in the + unencoded text.) + + In the event other encodings are defined in the future, and the mail + reader does not support the encoding used, it may either (a) display + the 'encoded-word' as ordinary text, or (b) substitute an appropriate + message indicating that the text could not be decoded. + + If the mail reader does not support the character set used, it may + (a) display the 'encoded-word' as ordinary text (i.e., as it appears + in the header), (b) make a "best effort" to display using such + characters as are available, or (c) substitute an appropriate message + indicating that the decoded text could not be displayed. + + If the character set being used employs code-switching techniques, + display of the encoded text implicitly begins in "ASCII mode". In + addition, the mail reader must ensure that the output device is once + again in "ASCII mode" after the 'encoded-word' is displayed. + +6.3. Mail reader handling of incorrectly formed 'encoded-word's + + It is possible that an 'encoded-word' that is legal according to the + syntax defined in section 2, is incorrectly formed according to the + rules for the encoding being used. For example: + + (1) An 'encoded-word' which contains characters which are not legal + for a particular encoding (for example, a "-" in the "B" + encoding, or a SPACE or HTAB in either the "B" or "Q" encoding), + is incorrectly formed. + + (2) Any 'encoded-word' which encodes a non-integral number of + characters or octets is incorrectly formed. + + A mail reader need not attempt to display the text associated with an + 'encoded-word' that is incorrectly formed. However, a mail reader + MUST NOT prevent the display or handling of a message because an + 'encoded-word' is incorrectly formed. + +7. Conformance + + A mail composing program claiming compliance with this specification + MUST ensure that any string of non-white-space printable ASCII + characters within a '*text' or '*ctext' that begins with "=?" and + ends with "?=" be a valid 'encoded-word'. ("begins" means: at the + + + +Moore Standards Track [Page 10] + +RFC 2047 Message Header Extensions November 1996 + + + start of the field-body, immediately following 'linear-white-space', + or immediately following a "(" for an 'encoded-word' within '*ctext'; + "ends" means: at the end of the field-body, immediately preceding + 'linear-white-space', or immediately preceding a ")" for an + 'encoded-word' within '*ctext'.) In addition, any 'word' within a + 'phrase' that begins with "=?" and ends with "?=" must be a valid + 'encoded-word'. + + A mail reading program claiming compliance with this specification + must be able to distinguish 'encoded-word's from 'text', 'ctext', or + 'word's, according to the rules in section 6, anytime they appear in + appropriate places in message headers. It must support both the "B" + and "Q" encodings for any character set which it supports. The + program must be able to display the unencoded text if the character + set is "US-ASCII". For the ISO-8859-* character sets, the mail + reading program must at least be able to display the characters which + are also in the ASCII set. + +8. Examples + + The following are examples of message headers containing 'encoded- + word's: + + From: =?US-ASCII?Q?Keith_Moore?= + To: =?ISO-8859-1?Q?Keld_J=F8rn_Simonsen?= + CC: =?ISO-8859-1?Q?Andr=E9?= Pirard + Subject: =?ISO-8859-1?B?SWYgeW91IGNhbiByZWFkIHRoaXMgeW8=?= + =?ISO-8859-2?B?dSB1bmRlcnN0YW5kIHRoZSBleGFtcGxlLg==?= + + Note: In the first 'encoded-word' of the Subject field above, the + last "=" at the end of the 'encoded-text' is necessary because each + 'encoded-word' must be self-contained (the "=" character completes a + group of 4 base64 characters representing 2 octets). An additional + octet could have been encoded in the first 'encoded-word' (so that + the encoded-word would contain an exact multiple of 3 encoded + octets), except that the second 'encoded-word' uses a different + 'charset' than the first one. + + From: =?ISO-8859-1?Q?Olle_J=E4rnefors?= + To: ietf-822@dimacs.rutgers.edu, ojarnef@admin.kth.se + Subject: Time for ISO 10646? + + To: Dave Crocker + Cc: ietf-822@dimacs.rutgers.edu, paf@comsol.se + From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= + Subject: Re: RFC-HDR care and feeding + + + + + +Moore Standards Track [Page 11] + +RFC 2047 Message Header Extensions November 1996 + + + From: Nathaniel Borenstein + (=?iso-8859-8?b?7eXs+SDv4SDp7Oj08A==?=) + To: Greg Vaudreuil , Ned Freed + , Keith Moore + Subject: Test of new header generator + MIME-Version: 1.0 + Content-type: text/plain; charset=ISO-8859-1 + + The following examples illustrate how text containing 'encoded-word's + which appear in a structured field body. The rules are slightly + different for fields defined as '*text' because "(" and ")" are not + recognized as 'comment' delimiters. [Section 5, paragraph (1)]. + + In each of the following examples, if the same sequence were to occur + in a '*text' field, the "displayed as" form would NOT be treated as + encoded words, but be identical to the "encoded form". This is + because each of the encoded-words in the following examples is + adjacent to a "(" or ")" character. + + encoded form displayed as + --------------------------------------------------------------------- + (=?ISO-8859-1?Q?a?=) (a) + + (=?ISO-8859-1?Q?a?= b) (a b) + + Within a 'comment', white space MUST appear between an + 'encoded-word' and surrounding text. [Section 5, + paragraph (2)]. However, white space is not needed between + the initial "(" that begins the 'comment', and the + 'encoded-word'. + + + (=?ISO-8859-1?Q?a?= =?ISO-8859-1?Q?b?=) (ab) + + White space between adjacent 'encoded-word's is not + displayed. + + (=?ISO-8859-1?Q?a?= =?ISO-8859-1?Q?b?=) (ab) + + Even multiple SPACEs between 'encoded-word's are ignored + for the purpose of display. + + (=?ISO-8859-1?Q?a?= (ab) + =?ISO-8859-1?Q?b?=) + + Any amount of linear-space-white between 'encoded-word's, + even if it includes a CRLF followed by one or more SPACEs, + is ignored for the purposes of display. + + + +Moore Standards Track [Page 12] + +RFC 2047 Message Header Extensions November 1996 + + + (=?ISO-8859-1?Q?a_b?=) (a b) + + In order to cause a SPACE to be displayed within a portion + of encoded text, the SPACE MUST be encoded as part of the + 'encoded-word'. + + (=?ISO-8859-1?Q?a?= =?ISO-8859-2?Q?_b?=) (a b) + + In order to cause a SPACE to be displayed between two strings + of encoded text, the SPACE MAY be encoded as part of one of + the 'encoded-word's. + +9. References + + [RFC 822] Crocker, D., "Standard for the Format of ARPA Internet Text + Messages", STD 11, RFC 822, UDEL, August 1982. + + [RFC 2049] Borenstein, N., and N. Freed, "Multipurpose Internet Mail + Extensions (MIME) Part Five: Conformance Criteria and Examples", + RFC 2049, November 1996. + + [RFC 2045] Borenstein, N., and N. Freed, "Multipurpose Internet Mail + Extensions (MIME) Part One: Format of Internet Message Bodies", + RFC 2045, November 1996. + + [RFC 2046] Borenstein N., and N. Freed, "Multipurpose Internet Mail + Extensions (MIME) Part Two: Media Types", RFC 2046, + November 1996. + + [RFC 2048] Freed, N., Klensin, J., and J. Postel, "Multipurpose + Internet Mail Extensions (MIME) Part Four: Registration + Procedures", RFC 2048, November 1996. + + + + + + + + + + + + + + + + + + + +Moore Standards Track [Page 13] + +RFC 2047 Message Header Extensions November 1996 + + +10. Security Considerations + + Security issues are not discussed in this memo. + +11. Acknowledgements + + The author wishes to thank Nathaniel Borenstein, Issac Chan, Lutz + Donnerhacke, Paul Eggert, Ned Freed, Andreas M. Kirchwitz, Olle + Jarnefors, Mike Rosin, Yutaka Sato, Bart Schaefer, and Kazuhiko + Yamamoto, for their helpful advice, insightful comments, and + illuminating questions in response to earlier versions of this + specification. + +12. Author's Address + + Keith Moore + University of Tennessee + 107 Ayres Hall + Knoxville TN 37996-1301 + + EMail: moore@cs.utk.edu + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Moore Standards Track [Page 14] + +RFC 2047 Message Header Extensions November 1996 + + +Appendix - changes since RFC 1522 (in no particular order) + + + explicitly state that the MIME-Version is not requried to use + 'encoded-word's. + + + add explicit note that SPACEs and TABs are not allowed within + 'encoded-word's, explaining that an 'encoded-word' must look like an + 'atom' to an RFC822 parser.values, to be precise). + + + add examples from Olle Jarnefors (thanks!) which illustrate how + encoded-words with adjacent linear-white-space are displayed. + + + explicitly list terms defined in RFC822 and referenced in this memo + + + fix transcription typos that caused one or two lines and a couple of + characters to disappear in the resulting text, due to nroff quirks. + + + clarify that encoded-words are allowed in '*text' fields in both + RFC822 headers and MIME body part headers, but NOT as parameter + values. + + + clarify the requirement to switch back to ASCII within the encoded + portion of an 'encoded-word', for any charset that uses code switching + sequences. + + + add a note about 'encoded-word's being delimited by "(" and ")" + within a comment, but not in a *text (how bizarre!). + + + fix the Andre Pirard example to get rid of the trailing "_" after + the =E9. (no longer needed post-1342). + + + clarification: an 'encoded-word' may appear immediately following + the initial "(" or immediately before the final ")" that delimits a + comment, not just adjacent to "(" and ")" *within* *ctext. + + + add a note to explain that a "B" 'encoded-word' will always have a + multiple of 4 characters in the 'encoded-text' portion. + + + add note about the "=" in the examples + + + note that processing of 'encoded-word's occurs *after* parsing, and + some of the implications thereof. + + + explicitly state that you can't expect to translate between + 1522 and either vanilla 822 or so-called "8-bit headers". + + + explicitly state that 'encoded-word's are not valid within a + 'quoted-string'. + + + +Moore Standards Track [Page 15] + diff --git a/RFCs/rfc2049.txt b/RFCs/rfc2049.txt new file mode 100644 index 0000000..99f174b --- /dev/null +++ b/RFCs/rfc2049.txt @@ -0,0 +1,1347 @@ + + + + + + +Network Working Group N. Freed +Request for Comments: 2049 Innosoft +Obsoletes: 1521, 1522, 1590 N. Borenstein +Category: Standards Track First Virtual + November 1996 + + + Multipurpose Internet Mail Extensions + (MIME) Part Five: + Conformance Criteria and Examples + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Abstract + + STD 11, RFC 822, defines a message representation protocol specifying + considerable detail about US-ASCII message headers, and leaves the + message content, or message body, as flat US-ASCII text. This set of + documents, collectively called the Multipurpose Internet Mail + Extensions, or MIME, redefines the format of messages to allow for + + (1) textual message bodies in character sets other than + US-ASCII, + + (2) an extensible set of different formats for non-textual + message bodies, + + (3) multi-part message bodies, and + + (4) textual header information in character sets other than + US-ASCII. + + These documents are based on earlier work documented in RFC 934, STD + 11, and RFC 1049, but extends and revises them. Because RFC 822 said + so little about message bodies, these documents are largely + orthogonal to (rather than a revision of) RFC 822. + + The initial document in this set, RFC 2045, specifies the various + headers used to describe the structure of MIME messages. The second + document defines the general structure of the MIME media typing + system and defines an initial set of media types. The third + document, RFC 2047, describes extensions to RFC 822 to allow non-US- + + + +Freed & Borenstein Standards Track [Page 1] + +RFC 2049 MIME Conformance November 1996 + + + ASCII text data in Internet mail header fields. The fourth document, + RFC 2048, specifies various IANA registration procedures for MIME- + related facilities. This fifth and final document describes MIME + conformance criteria as well as providing some illustrative examples + of MIME message formats, acknowledgements, and the bibliography. + + These documents are revisions of RFCs 1521, 1522, and 1590, which + themselves were revisions of RFCs 1341 and 1342. Appendix B of this + document describes differences and changes from previous versions. + +Table of Contents + + 1. Introduction .......................................... 2 + 2. MIME Conformance ...................................... 2 + 3. Guidelines for Sending Email Data ..................... 6 + 4. Canonical Encoding Model .............................. 9 + 5. Summary ............................................... 12 + 6. Security Considerations ............................... 12 + 7. Authors' Addresses .................................... 12 + 8. Acknowledgements ...................................... 13 + A. A Complex Multipart Example ........................... 15 + B. Changes from RFC 1521, 1522, and 1590 ................. 16 + C. References ............................................ 20 + +1. Introduction + + The first and second documents in this set define MIME header fields + and the initial set of MIME media types. The third document + describes extensions to RFC822 formats to allow for character sets + other than US-ASCII. This document describes what portions of MIME + must be supported by a conformant MIME implementation. It also + describes various pitfalls of contemporary messaging systems as well + as the canonical encoding model MIME is based on. + +2. MIME Conformance + + The mechanisms described in these documents are open-ended. It is + definitely not expected that all implementations will support all + available media types, nor that they will all share the same + extensions. In order to promote interoperability, however, it is + useful to define the concept of "MIME-conformance" to define a + certain level of implementation that allows the useful interworking + of messages with content that differs from US-ASCII text. In this + section, we specify the requirements for such conformance. + + + + + + + +Freed & Borenstein Standards Track [Page 2] + +RFC 2049 MIME Conformance November 1996 + + + A mail user agent that is MIME-conformant MUST: + + (1) Always generate a "MIME-Version: 1.0" header field in + any message it creates. + + (2) Recognize the Content-Transfer-Encoding header field + and decode all received data encoded by either quoted- + printable or base64 implementations. The identity + transformations 7bit, 8bit, and binary must also be + recognized. + + Any non-7bit data that is sent without encoding must be + properly labelled with a content-transfer-encoding of + 8bit or binary, as appropriate. If the underlying + transport does not support 8bit or binary (as SMTP + [RFC-821] does not), the sender is required to both + encode and label data using an appropriate Content- + Transfer-Encoding such as quoted-printable or base64. + + (3) Must treat any unrecognized Content-Transfer-Encoding + as if it had a Content-Type of "application/octet- + stream", regardless of whether or not the actual + Content-Type is recognized. + + (4) Recognize and interpret the Content-Type header field, + and avoid showing users raw data with a Content-Type + field other than text. Implementations must be able + to send at least text/plain messages, with the + character set specified with the charset parameter if + it is not US-ASCII. + + (5) Ignore any content type parameters whose names they do + not recognize. + + (6) Explicitly handle the following media type values, to + at least the following extents: + + Text: + + -- Recognize and display "text" mail with the + character set "US-ASCII." + + -- Recognize other character sets at least to the + extent of being able to inform the user about what + character set the message uses. + + + + + + +Freed & Borenstein Standards Track [Page 3] + +RFC 2049 MIME Conformance November 1996 + + + -- Recognize the "ISO-8859-*" character sets to the + extent of being able to display those characters that + are common to ISO-8859-* and US-ASCII, namely all + characters represented by octet values 1-127. + + -- For unrecognized subtypes in a known character + set, show or offer to show the user the "raw" version + of the data after conversion of the content from + canonical form to local form. + + -- Treat material in an unknown character set as if + it were "application/octet-stream". + + Image, audio, and video: + + -- At a minumum provide facilities to treat any + unrecognized subtypes as if they were + "application/octet-stream". + + Application: + + -- Offer the ability to remove either of the quoted- + printable or base64 encodings defined in this + document if they were used and put the resulting + information in a user file. + + Multipart: + + -- Recognize the mixed subtype. Display all relevant + information on the message level and the body part + header level and then display or offer to display + each of the body parts individually. + + -- Recognize the "alternative" subtype, and avoid + showing the user redundant parts of + multipart/alternative mail. + + -- Recognize the "multipart/digest" subtype, + specifically using "message/rfc822" rather than + "text/plain" as the default media type for body parts + inside "multipart/digest" entities. + + -- Treat any unrecognized subtypes as if they were + "mixed". + + + + + + + +Freed & Borenstein Standards Track [Page 4] + +RFC 2049 MIME Conformance November 1996 + + + Message: + + -- Recognize and display at least the RFC822 message + encapsulation (message/rfc822) in such a way as to + preserve any recursive structure, that is, displaying + or offering to display the encapsulated data in + accordance with its media type. + + -- Treat any unrecognized subtypes as if they were + "application/octet-stream". + + (7) Upon encountering any unrecognized Content-Type field, + an implementation must treat it as if it had a media + type of "application/octet-stream" with no parameter + sub-arguments. How such data are handled is up to an + implementation, but likely options for handling such + unrecognized data include offering the user to write it + into a file (decoded from its mail transport format) or + offering the user to name a program to which the + decoded data should be passed as input. + + (8) Conformant user agents are required, if they provide + non-standard support for non-MIME messages employing + character sets other than US-ASCII, to do so on + received messages only. Conforming user agents must not + send non-MIME messages containing anything other than + US-ASCII text. + + In particular, the use of non-US-ASCII text in mail + messages without a MIME-Version field is strongly + discouraged as it impedes interoperability when sending + messages between regions with different localization + conventions. Conforming user agents MUST include proper + MIME labelling when sending anything other than plain + text in the US-ASCII character set. + + In addition, non-MIME user agents should be upgraded if + at all possible to include appropriate MIME header + information in the messages they send even if nothing + else in MIME is supported. This upgrade will have + little, if any, effect on non-MIME recipients and will + aid MIME in correctly displaying such messages. It + also provides a smooth transition path to eventual + adoption of other MIME capabilities. + + (9) Conforming user agents must ensure that any string of + non-white-space printable US-ASCII characters within a + "*text" or "*ctext" that begins with "=?" and ends with + + + +Freed & Borenstein Standards Track [Page 5] + +RFC 2049 MIME Conformance November 1996 + + + "?=" be a valid encoded-word. ("begins" means: At the + start of the field-body or immediately following + linear-white-space; "ends" means: At the end of the + field-body or immediately preceding linear-white- + space.) In addition, any "word" within a "phrase" that + begins with "=?" and ends with "?=" must be a valid + encoded-word. + + (10) Conforming user agents must be able to distinguish + encoded-words from "text", "ctext", or "word"s, + according to the rules in section 4, anytime they + appear in appropriate places in message headers. It + must support both the "B" and "Q" encodings for any + character set which it supports. The program must be + able to display the unencoded text if the character set + is "US-ASCII". For the ISO-8859-* character sets, the + mail reading program must at least be able to display + the characters which are also in the US-ASCII set. + + A user agent that meets the above conditions is said to be MIME- + conformant. The meaning of this phrase is that it is assumed to be + "safe" to send virtually any kind of properly-marked data to users of + such mail systems, because such systems will at least be able to + treat the data as undifferentiated binary, and will not simply splash + it onto the screen of unsuspecting users. + + There is another sense in which it is always "safe" to send data in a + format that is MIME-conformant, which is that such data will not + break or be broken by any known systems that are conformant with RFC + 821 and RFC 822. User agents that are MIME-conformant have the + additional guarantee that the user will not be shown data that were + never intended to be viewed as text. + +3. Guidelines for Sending Email Data + + Internet email is not a perfect, homogeneous system. Mail may become + corrupted at several stages in its travel to a final destination. + Specifically, email sent throughout the Internet may travel across + many networking technologies. Many networking and mail technologies + do not support the full functionality possible in the SMTP transport + environment. Mail traversing these systems is likely to be modified + in order that it can be transported. + + There exist many widely-deployed non-conformant MTAs in the Internet. + These MTAs, speaking the SMTP protocol, alter messages on the fly to + take advantage of the internal data structure of the hosts they are + implemented on, or are just plain broken. + + + + +Freed & Borenstein Standards Track [Page 6] + +RFC 2049 MIME Conformance November 1996 + + + The following guidelines may be useful to anyone devising a data + format (media type) that is supposed to survive the widest range of + networking technologies and known broken MTAs unscathed. Note that + anything encoded in the base64 encoding will satisfy these rules, but + that some well-known mechanisms, notably the UNIX uuencode facility, + will not. Note also that anything encoded in the Quoted-Printable + encoding will survive most gateways intact, but possibly not some + gateways to systems that use the EBCDIC character set. + + (1) Under some circumstances the encoding used for data may + change as part of normal gateway or user agent + operation. In particular, conversion from base64 to + quoted-printable and vice versa may be necessary. This + may result in the confusion of CRLF sequences with line + breaks in text bodies. As such, the persistence of + CRLF as something other than a line break must not be + relied on. + + (2) Many systems may elect to represent and store text data + using local newline conventions. Local newline + conventions may not match the RFC822 CRLF convention -- + systems are known that use plain CR, plain LF, CRLF, or + counted records. The result is that isolated CR and LF + characters are not well tolerated in general; they may + be lost or converted to delimiters on some systems, and + hence must not be relied on. + + (3) The transmission of NULs (US-ASCII value 0) is + problematic in Internet mail. (This is largely the + result of NULs being used as a termination character by + many of the standard runtime library routines in the C + programming language.) The practice of using NULs as + termination characters is so entrenched now that + messages should not rely on them being preserved. + + (4) TAB (HT) characters may be misinterpreted or may be + automatically converted to variable numbers of spaces. + This is unavoidable in some environments, notably those + not based on the US-ASCII character set. Such + conversion is STRONGLY DISCOURAGED, but it may occur, + and mail formats must not rely on the persistence of + TAB (HT) characters. + + (5) Lines longer than 76 characters may be wrapped or + truncated in some environments. Line wrapping or line + truncation imposed by mail transports is STRONGLY + DISCOURAGED, but unavoidable in some cases. + Applications which require long lines must somehow + + + +Freed & Borenstein Standards Track [Page 7] + +RFC 2049 MIME Conformance November 1996 + + + differentiate between soft and hard line breaks. (A + simple way to do this is to use the quoted-printable + encoding.) + + (6) Trailing "white space" characters (SPACE, TAB (HT)) on + a line may be discarded by some transport agents, while + other transport agents may pad lines with these + characters so that all lines in a mail file are of + equal length. The persistence of trailing white space, + therefore, must not be relied on. + + (7) Many mail domains use variations on the US-ASCII + character set, or use character sets such as EBCDIC + which contain most but not all of the US-ASCII + characters. The correct translation of characters not + in the "invariant" set cannot be depended on across + character converting gateways. For example, this + situation is a problem when sending uuencoded + information across BITNET, an EBCDIC system. Similar + problems can occur without crossing a gateway, since + many Internet hosts use character sets other than US- + ASCII internally. The definition of Printable Strings + in X.400 adds further restrictions in certain special + cases. In particular, the only characters that are + known to be consistent across all gateways are the 73 + characters that correspond to the upper and lower case + letters A-Z and a-z, the 10 digits 0-9, and the + following eleven special characters: + + "'" (US-ASCII decimal value 39) + "(" (US-ASCII decimal value 40) + ")" (US-ASCII decimal value 41) + "+" (US-ASCII decimal value 43) + "," (US-ASCII decimal value 44) + "-" (US-ASCII decimal value 45) + "." (US-ASCII decimal value 46) + "/" (US-ASCII decimal value 47) + ":" (US-ASCII decimal value 58) + "=" (US-ASCII decimal value 61) + "?" (US-ASCII decimal value 63) + + A maximally portable mail representation will confine + itself to relatively short lines of text in which the + only meaningful characters are taken from this set of + 73 characters. The base64 encoding follows this rule. + + (8) Some mail transport agents will corrupt data that + includes certain literal strings. In particular, a + + + +Freed & Borenstein Standards Track [Page 8] + +RFC 2049 MIME Conformance November 1996 + + + period (".") alone on a line is known to be corrupted + by some (incorrect) SMTP implementations, and a line + that starts with the five characters "From " (the fifth + character is a SPACE) are commonly corrupted as well. + A careful composition agent can prevent these + corruptions by encoding the data (e.g., in the quoted- + printable encoding using "=46rom " in place of "From " + at the start of a line, and "=2E" in place of "." alone + on a line). + + Please note that the above list is NOT a list of recommended + practices for MTAs. RFC 821 MTAs are prohibited from altering the + character of white space or wrapping long lines. These BAD and + invalid practices are known to occur on established networks, and + implementations should be robust in dealing with the bad effects they + can cause. + +4. Canonical Encoding Model + + There was some confusion, in earlier versions of these documents, + regarding the model for when email data was to be converted to + canonical form and encoded, and in particular how this process would + affect the treatment of CRLFs, given that the representation of + newlines varies greatly from system to system. For this reason, a + canonical model for encoding is presented below. + + The process of composing a MIME entity can be modeled as being done + in a number of steps. Note that these steps are roughly similar to + those steps used in PEM [RFC-1421] and are performed for each + "innermost level" body: + + (1) Creation of local form. + + The body to be transmitted is created in the system's + native format. The native character set is used and, + where appropriate, local end of line conventions are + used as well. The body may be a UNIX-style text file, + or a Sun raster image, or a VMS indexed file, or audio + data in a system-dependent format stored only in + memory, or anything else that corresponds to the local + model for the representation of some form of + information. Fundamentally, the data is created in the + "native" form that corresponds to the type specified by + the media type. + + + + + + + +Freed & Borenstein Standards Track [Page 9] + +RFC 2049 MIME Conformance November 1996 + + + (2) Conversion to canonical form. + + The entire body, including "out-of-band" information + such as record lengths and possibly file attribute + information, is converted to a universal canonical + form. The specific media type of the body as well as + its associated attributes dictate the nature of the + canonical form that is used. Conversion to the proper + canonical form may involve character set conversion, + transformation of audio data, compression, or various + other operations specific to the various media types. + If character set conversion is involved, however, care + must be taken to understand the semantics of the media + type, which may have strong implications for any + character set conversion, e.g. with regard to + syntactically meaningful characters in a text subtype + other than "plain". + + For example, in the case of text/plain data, the text + must be converted to a supported character set and + lines must be delimited with CRLF delimiters in + accordance with RFC 822. Note that the restriction on + line lengths implied by RFC 822 is eliminated if the + next step employs either quoted-printable or base64 + encoding. + + (3) Apply transfer encoding. + + A Content-Transfer-Encoding appropriate for this body + is applied. Note that there is no fixed relationship + between the media type and the transfer encoding. In + particular, it may be appropriate to base the choice of + base64 or quoted-printable on character frequency + counts which are specific to a given instance of a + body. + + (4) Insertion into entity. + + The encoded body is inserted into a MIME entity with + appropriate headers. The entity is then inserted into + the body of a higher-level entity (message or + multipart) as needed. + + Conversion from entity form to local form is accomplished by + reversing these steps. Note that reversal of these steps may produce + differing results since there is no guarantee that the original and + final local forms are the same. + + + + +Freed & Borenstein Standards Track [Page 10] + +RFC 2049 MIME Conformance November 1996 + + + It is vital to note that these steps are only a model; they are + specifically NOT a blueprint for how an actual system would be built. + In particular, the model fails to account for two common designs: + + (1) In many cases the conversion to a canonical form prior + to encoding will be subsumed into the encoder itself, + which understands local formats directly. For example, + the local newline convention for text bodies might be + carried through to the encoder itself along with + knowledge of what that format is. + + (2) The output of the encoders may have to pass through one + or more additional steps prior to being transmitted as + a message. As such, the output of the encoder may not + be conformant with the formats specified by RFC 822. + In particular, once again it may be appropriate for the + converter's output to be expressed using local newline + conventions rather than using the standard RFC 822 CRLF + delimiters. + + Other implementation variations are conceivable as well. The vital + aspect of this discussion is that, in spite of any optimizations, + collapsings of required steps, or insertion of additional processing, + the resulting messages must be consistent with those produced by the + model described here. For example, a message with the following + header fields: + + Content-type: text/foo; charset=bar + Content-Transfer-Encoding: base64 + + must be first represented in the text/foo form, then (if necessary) + represented in the "bar" character set, and finally transformed via + the base64 algorithm into a mail-safe form. + + NOTE: Some confusion has been caused by systems that represent + messages in a format which uses local newline conventions which + differ from the RFC822 CRLF convention. It is important to note that + these formats are not canonical RFC822/MIME. These formats are + instead *encodings* of RFC822, where CRLF sequences in the canonical + representation of the message are encoded as the local newline + convention. Note that formats which encode CRLF sequences as, for + example, LF are not capable of representing MIME messages containing + binary data which contains LF octets not part of CRLF line separation + sequences. + + + + + + + +Freed & Borenstein Standards Track [Page 11] + +RFC 2049 MIME Conformance November 1996 + + +5. Summary + + This document defines what is meant by MIME Conformance. It also + details various problems known to exist in the Internet email system + and how to use MIME to overcome them. Finally, it describes MIME's + canonical encoding model. + +6. Security Considerations + + Security issues are discussed in the second document in this set, RFC + 2046. + +7. Authors' Addresses + + For more information, the authors of this document are best contacted + via Internet mail: + + Ned Freed + Innosoft International, Inc. + 1050 East Garvey Avenue South + West Covina, CA 91790 + USA + + Phone: +1 818 919 3600 + Fax: +1 818 919 3614 + EMail: ned@innosoft.com + + Nathaniel S. Borenstein + First Virtual Holdings + 25 Washington Avenue + Morristown, NJ 07960 + USA + + Phone: +1 201 540 8967 + Fax: +1 201 993 3032 + EMail: nsb@nsb.fv.com + + MIME is a result of the work of the Internet Engineering Task Force + Working Group on RFC 822 Extensions. The chairman of that group, + Greg Vaudreuil, may be reached at: + + Gregory M. Vaudreuil + Octel Network Services + 17080 Dallas Parkway + Dallas, TX 75248-1905 + USA + + EMail: Greg.Vaudreuil@Octel.Com + + + +Freed & Borenstein Standards Track [Page 12] + +RFC 2049 MIME Conformance November 1996 + + +8. Acknowledgements + + This document is the result of the collective effort of a large + number of people, at several IETF meetings, on the IETF-SMTP and + IETF-822 mailing lists, and elsewhere. Although any enumeration + seems doomed to suffer from egregious omissions, the following are + among the many contributors to this effort: + + Harald Tveit Alvestrand Marc Andreessen + Randall Atkinson Bob Braden + Philippe Brandon Brian Capouch + Kevin Carosso Uhhyung Choi + Peter Clitherow Dave Collier-Brown + Cristian Constantinof John Coonrod + Mark Crispin Dave Crocker + Stephen Crocker Terry Crowley + Walt Daniels Jim Davis + Frank Dawson Axel Deininger + Hitoshi Doi Kevin Donnelly + Steve Dorner Keith Edwards + Chris Eich Dana S. Emery + Johnny Eriksson Craig Everhart + Patrik Faltstrom Erik E. Fair + Roger Fajman Alain Fontaine + Martin Forssen James M. Galvin + Stephen Gildea Philip Gladstone + Thomas Gordon Keld Simonsen + Terry Gray Phill Gross + James Hamilton David Herron + Mark Horton Bruce Howard + Bill Janssen Olle Jarnefors + Risto Kankkunen Phil Karn + Alan Katz Tim Kehres + Neil Katin Steve Kille + Kyuho Kim Anders Klemets + John Klensin Valdis Kletniek + Jim Knowles Stev Knowles + Bob Kummerfeld Pekka Kytolaakso + Stellan Lagerstrom Vincent Lau + Timo Lehtinen Donald Lindsay + Warner Losh Carlyn Lowery + Laurence Lundblade Charles Lynn + John R. MacMillan Larry Masinter + Rick McGowan Michael J. McInerny + Leo Mclaughlin Goli Montaser-Kohsari + Tom Moore John Gardiner Myers + Erik Naggum Mark Needleman + Chris Newman John Noerenberg + + + +Freed & Borenstein Standards Track [Page 13] + +RFC 2049 MIME Conformance November 1996 + + + Mats Ohrman Julian Onions + Michael Patton David J. Pepper + Erik van der Poel Blake C. Ramsdell + Christer Romson Luc Rooijakkers + Marshall T. Rose Jonathan Rosenberg + Guido van Rossum Jan Rynning + Harri Salminen Michael Sanderson + Yutaka Sato Markku Savela + Richard Alan Schafer Masahiro Sekiguchi + Mark Sherman Bob Smart + Peter Speck Henry Spencer + Einar Stefferud Michael Stein + Klaus Steinberger Peter Svanberg + James Thompson Steve Uhler + Stuart Vance Peter Vanderbilt + Greg Vaudreuil Ed Vielmetti + Larry W. Virden Ryan Waldron + Rhys Weatherly Jay Weber + Dave Wecker Wally Wedel + Sven-Ove Westberg Brian Wideen + John Wobus Glenn Wright + Rayan Zachariassen David Zimmerman + + The authors apologize for any omissions from this list, which are + certainly unintentional. + + + + + + + + + + + + + + + + + + + + + + + + + + +Freed & Borenstein Standards Track [Page 14] + +RFC 2049 MIME Conformance November 1996 + + +Appendix A -- A Complex Multipart Example + + What follows is the outline of a complex multipart message. This + message contains five parts that are to be displayed serially: two + introductory plain text objects, an embedded multipart message, a + text/enriched object, and a closing encapsulated text message in a + non-ASCII character set. The embedded multipart message itself + contains two objects to be displayed in parallel, a picture and an + audio fragment. + + MIME-Version: 1.0 + From: Nathaniel Borenstein + To: Ned Freed + Date: Fri, 07 Oct 1994 16:15:05 -0700 (PDT) + Subject: A multipart example + Content-Type: multipart/mixed; + boundary=unique-boundary-1 + + This is the preamble area of a multipart message. + Mail readers that understand multipart format + should ignore this preamble. + + If you are reading this text, you might want to + consider changing to a mail reader that understands + how to properly display multipart messages. + + --unique-boundary-1 + + ... Some text appears here ... + + [Note that the blank between the boundary and the start + of the text in this part means no header fields were + given and this is text in the US-ASCII character set. + It could have been done with explicit typing as in the + next part.] + + --unique-boundary-1 + Content-type: text/plain; charset=US-ASCII + + This could have been part of the previous part, but + illustrates explicit versus implicit typing of body + parts. + + --unique-boundary-1 + Content-Type: multipart/parallel; boundary=unique-boundary-2 + + --unique-boundary-2 + Content-Type: audio/basic + + + +Freed & Borenstein Standards Track [Page 15] + +RFC 2049 MIME Conformance November 1996 + + + Content-Transfer-Encoding: base64 + + ... base64-encoded 8000 Hz single-channel + mu-law-format audio data goes here ... + + --unique-boundary-2 + Content-Type: image/jpeg + Content-Transfer-Encoding: base64 + + ... base64-encoded image data goes here ... + + --unique-boundary-2-- + + --unique-boundary-1 + Content-type: text/enriched + + This is enriched. + as defined in RFC 1896 + + Isn't it + cool? + + --unique-boundary-1 + Content-Type: message/rfc822 + + From: (mailbox in US-ASCII) + To: (address in US-ASCII) + Subject: (subject in US-ASCII) + Content-Type: Text/plain; charset=ISO-8859-1 + Content-Transfer-Encoding: Quoted-printable + + ... Additional text in ISO-8859-1 goes here ... + + --unique-boundary-1-- + +Appendix B -- Changes from RFC 1521, 1522, and 1590 + + These documents are a revision of RFC 1521, 1522, and 1590. For the + convenience of those familiar with the earlier documents, the changes + from those documents are summarized in this appendix. For further + history, note that Appendix H in RFC 1521 specified how that document + differed from its predecessor, RFC 1341. + + (1) This document has been completely reformatted and split + into multiple documents. This was done to improve the + quality of the plain text version of this document, + which is required to be the reference copy. + + + + +Freed & Borenstein Standards Track [Page 16] + +RFC 2049 MIME Conformance November 1996 + + + (2) BNF describing the overall structure of MIME object + headers has been added. This is a documentation change + only -- the underlying syntax has not changed in any + way. + + (3) The specific BNF for the seven media types in MIME has + been removed. This BNF was incorrect, incomplete, amd + inconsistent with the type-indendependent BNF. And + since the type-independent BNF already fully specifies + the syntax of the various MIME headers, the type- + specific BNF was, in the final analysis, completely + unnecessary and caused more problems than it solved. + + (4) The more specific "US-ASCII" character set name has + replaced the use of the informal term ASCII in many + parts of these documents. + + (5) The informal concept of a primary subtype has been + removed. + + (6) The term "object" was being used inconsistently. The + definition of this term has been clarified, along with + the related terms "body", "body part", and "entity", + and usage has been corrected where appropriate. + + (7) The BNF for the multipart media type has been + rearranged to make it clear that the CRLF preceeding + the boundary marker is actually part of the marker + itself rather than the preceeding body part. + + (8) The prose and BNF describing the multipart media type + have been changed to make it clear that the body parts + within a multipart object MUST NOT contain any lines + beginning with the boundary parameter string. + + (9) In the rules on reassembling "message/partial" MIME + entities, "Subject" is added to the list of headers to + take from the inner message, and the example is + modified to clarify this point. + + (10) "Message/partial" fragmenters are restricted to + splitting MIME objects only at line boundaries. + + (11) In the discussion of the application/postscript type, + an additional paragraph has been added warning about + possible interoperability problems caused by embedding + of binary data inside a PostScript MIME entity. + + + + +Freed & Borenstein Standards Track [Page 17] + +RFC 2049 MIME Conformance November 1996 + + + (12) Added a clarifying note to the basic syntax rules for + the Content-Type header field to make it clear that the + following two forms: + + Content-type: text/plain; charset=us-ascii (comment) + + Content-type: text/plain; charset="us-ascii" + + are completely equivalent. + + (13) The following sentence has been removed from the + discussion of the MIME-Version header: "However, + conformant software is encouraged to check the version + number and at least warn the user if an unrecognized + MIME-version is encountered." + + (14) A typo was fixed that said "application/external-body" + instead of "message/external-body". + + (15) The definition of a character set has been reorganized + to make the requirements clearer. + + (16) The definition of the "image/gif" media type has been + moved to a separate document. This change was made + because of potential conflicts with IETF rules + governing the standardization of patented technology. + + (17) The definitions of "7bit" and "8bit" have been + tightened so that use of bare CR, LF can only be used + as end-of-line sequences. The document also no longer + requires that NUL characters be preserved, which brings + MIME into alignment with real-world implementations. + + (18) The definition of canonical text in MIME has been + tightened so that line breaks must be represented by a + CRLF sequence. CR and LF characters are not allowed + outside of this usage. The definition of quoted- + printable encoding has been altered accordingly. + + (19) The definition of the quoted-printable encoding now + includes a number of suggestions for how quoted- + printable encoders might best handle improperly encoded + material. + + (20) Prose was added to clarify the use of the "7bit", + "8bit", and "binary" transfer-encodings on multipart or + message entities encapsulating "8bit" or "binary" data. + + + + +Freed & Borenstein Standards Track [Page 18] + +RFC 2049 MIME Conformance November 1996 + + + (21) In the section on MIME Conformance, "multipart/digest" + support was added to the list of requirements for + minimal MIME conformance. Also, the requirement for + "message/rfc822" support were strengthened to clarify + the importance of recognizing recursive structure. + + (22) The various restrictions on subtypes of "message" are + now specified entirely on a subtype by subtype basis. + + (23) The definition of "message/rfc822" was changed to + indicate that at least one of the "From", "Subject", or + "Date" headers must be present. + + (24) The required handling of unrecognized subtypes as + "application/octet-stream" has been made more explicit + in both the type definitions sections and the + conformance guidelines. + + (25) Examples using text/richtext were changed to + text/enriched. + + (26) The BNF definition of subtype has been changed to make + it clear that either an IANA registered subtype or a + nonstandard "X-" subtype must be used in a Content-Type + header field. + + (27) MIME media types that are simply registered for use and + those that are standardized by the IETF are now + distinguished in the MIME BNF. + + (28) All of the various MIME registration procedures have + been extensively revised. IANA registration procedures + for character sets have been moved to a separate + document that is no included in this set of documents. + + (29) The use of escape and shift mechanisms in the US-ASCII + and ISO-8859-X character sets these documents define + have been clarified: Such mechanisms should never be + used in conjunction with these character sets and their + effect if they are used is undefined. + + (30) The definition of the AFS access-type for + message/external-body has been removed. + + (31) The handling of the combination of + multipart/alternative and message/external-body is now + specifically addressed. + + + + +Freed & Borenstein Standards Track [Page 19] + +RFC 2049 MIME Conformance November 1996 + + + (32) Security issues specific to message/external-body are + now discussed in some detail. + +Appendix C -- References + + [ATK] + Borenstein, Nathaniel S., Multimedia Applications + Development with the Andrew Toolkit, Prentice-Hall, 1990. + + [ISO-2022] + International Standard -- Information Processing -- + Character Code Structure and Extension Techniques, + ISO/IEC 2022:1994, 4th ed. + + [ISO-8859] + International Standard -- Information Processing -- 8-bit + Single-Byte Coded Graphic Character Sets + - Part 1: Latin Alphabet No. 1, ISO 8859-1:1987, 1st ed. + - Part 2: Latin Alphabet No. 2, ISO 8859-2:1987, 1st ed. + - Part 3: Latin Alphabet No. 3, ISO 8859-3:1988, 1st ed. + - Part 4: Latin Alphabet No. 4, ISO 8859-4:1988, 1st ed. + - Part 5: Latin/Cyrillic Alphabet, ISO 8859-5:1988, 1st + ed. + - Part 6: Latin/Arabic Alphabet, ISO 8859-6:1987, 1st ed. + - Part 7: Latin/Greek Alphabet, ISO 8859-7:1987, 1st ed. + - Part 8: Latin/Hebrew Alphabet, ISO 8859-8:1988, 1st ed. + - Part 9: Latin Alphabet No. 5, ISO/IEC 8859-9:1989, 1st + ed. + International Standard -- Information Technology -- 8-bit + Single-Byte Coded Graphic Character Sets + - Part 10: Latin Alphabet No. 6, ISO/IEC 8859-10:1992, + 1st ed. + + [ISO-646] + International Standard -- Information Technology -- ISO + 7-bit Coded Character Set for Information Interchange, + ISO 646:1991, 3rd ed.. + + [JPEG] + JPEG Draft Standard ISO 10918-1 CD. + + [MPEG] + Video Coding Draft Standard ISO 11172 CD, ISO + IEC/JTC1/SC2/WG11 (Motion Picture Experts Group), May, + 1991. + + + + + + +Freed & Borenstein Standards Track [Page 20] + +RFC 2049 MIME Conformance November 1996 + + + [PCM] + CCITT, Fascicle III.4 - Recommendation G.711, "Pulse Code + Modulation (PCM) of Voice Frequencies", Geneva, 1972. + + [POSTSCRIPT] + Adobe Systems, Inc., PostScript Language Reference + Manual, Addison-Wesley, 1985. + + [POSTSCRIPT2] + Adobe Systems, Inc., PostScript Language Reference + Manual, Addison-Wesley, Second Ed., 1990. + + [RFC-783] + Sollins, K.R., "TFTP Protocol (revision 2)", RFC-783, + MIT, June 1981. + + [RFC-821] + Postel, J.B., "Simple Mail Transfer Protocol", STD 10, + RFC 821, USC/Information Sciences Institute, August 1982. + + [RFC-822] + Crocker, D., "Standard for the Format of ARPA Internet + Text Messages", STD 11, RFC 822, UDEL, August 1982. + + [RFC-934] + Rose, M. and E. Stefferud, "Proposed Standard for Message + Encapsulation", RFC 934, Delaware and NMA, January 1985. + + [RFC-959] + Postel, J. and J. Reynolds, "File Transfer Protocol", STD + 9, RFC 959, USC/Information Sciences Institute, October + 1985. + + [RFC-1049] + Sirbu, M., "Content-Type Header Field for Internet + Messages", RFC 1049, CMU, March 1988. + + [RFC-1154] + Robinson, D., and R. Ullmann, "Encoding Header Field for + Internet Messages", RFC 1154, Prime Computer, Inc., April + 1990. + + [RFC-1341] + Borenstein, N., and N. Freed, "MIME (Multipurpose + Internet Mail Extensions): Mechanisms for Specifying and + Describing the Format of Internet Message Bodies", RFC + 1341, Bellcore, Innosoft, June 1992. + + + + +Freed & Borenstein Standards Track [Page 21] + +RFC 2049 MIME Conformance November 1996 + + + [RFC-1342] + Moore, K., "Representation of Non-Ascii Text in Internet + Message Headers", RFC 1342, University of Tennessee, June + 1992. + + [RFC-1344] + Borenstein, N., "Implications of MIME for Internet Mail + Gateways", RFC 1344, Bellcore, June 1992. + + [RFC-1345] + Simonsen, K., "Character Mnemonics & Character Sets", RFC + 1345, Rationel Almen Planlaegning, June 1992. + + [RFC-1421] + Linn, J., "Privacy Enhancement for Internet Electronic + Mail: Part I -- Message Encryption and Authentication + Procedures", RFC 1421, IAB IRTF PSRG, IETF PEM WG, + February 1993. + + [RFC-1422] + Kent, S., "Privacy Enhancement for Internet Electronic + Mail: Part II -- Certificate-Based Key Management", RFC + 1422, IAB IRTF PSRG, IETF PEM WG, February 1993. + + [RFC-1423] + Balenson, D., "Privacy Enhancement for Internet + Electronic Mail: Part III -- Algorithms, Modes, and + Identifiers", IAB IRTF PSRG, IETF PEM WG, February 1993. + + [RFC-1424] + Kaliski, B., "Privacy Enhancement for Internet Electronic + Mail: Part IV -- Key Certification and Related + Services", IAB IRTF PSRG, IETF PEM WG, February 1993. + + [RFC-1521] + Borenstein, N., and Freed, N., "MIME (Multipurpose + Internet Mail Extensions): Mechanisms for Specifying and + Describing the Format of Internet Message Bodies", RFC + 1521, Bellcore, Innosoft, September, 1993. + + [RFC-1522] + Moore, K., "Representation of Non-ASCII Text in Internet + Message Headers", RFC 1522, University of Tennessee, + September 1993. + + + + + + + +Freed & Borenstein Standards Track [Page 22] + +RFC 2049 MIME Conformance November 1996 + + + [RFC-1524] + Borenstein, N., "A User Agent Configuration Mechanism for + Multimedia Mail Format Information", RFC 1524, Bellcore, + September 1993. + + [RFC-1543] + Postel, J., "Instructions to RFC Authors", RFC 1543, + USC/Information Sciences Institute, October 1993. + + [RFC-1556] + Nussbacher, H., "Handling of Bi-directional Texts in + MIME", RFC 1556, Israeli Inter-University Computer + Center, December 1993. + + [RFC-1590] + Postel, J., "Media Type Registration Procedure", RFC + 1590, USC/Information Sciences Institute, March 1994. + + [RFC-1602] + Internet Architecture Board, Internet Engineering + Steering Group, Huitema, C., Gross, P., "The Internet + Standards Process -- Revision 2", March 1994. + + [RFC-1652] + Klensin, J., (WG Chair), Freed, N., (Editor), Rose, M., + Stefferud, E., and Crocker, D., "SMTP Service Extension + for 8bit-MIME transport", RFC 1652, United Nations + University, Innosoft, Dover Beach Consulting, Inc., + Network Management Associates, Inc., The Branch Office, + March 1994. + + [RFC-1700] + Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, + RFC 1700, USC/Information Sciences Institute, October + 1994. + + [RFC-1741] + Faltstrom, P., Crocker, D., and Fair, E., "MIME Content + Type for BinHex Encoded Files", December 1994. + + [RFC-1896] + Resnick, P., and A. Walker, "The text/enriched MIME + Content-type", RFC 1896, February, 1996. + + + + + + + + +Freed & Borenstein Standards Track [Page 23] + +RFC 2049 MIME Conformance November 1996 + + + [RFC-2045] + Freed, N., and and N. Borenstein, "Multipurpose Internet Mail + Extensions (MIME) Part One: Format of Internet Message + Bodies", RFC 2045, Innosoft, First Virtual Holdings, + November 1996. + + [RFC-2046] + Freed, N., and N. Borenstein, "Multipurpose Internet Mail + Extensions (MIME) Part Two: Media Types", RFC 2046, + Innosoft, First Virtual Holdings, November 1996. + + [RFC-2047] + Moore, K., "Multipurpose Internet Mail Extensions (MIME) + Part Three: Representation of Non-ASCII Text in Internet + Message Headers", RFC 2047, University of + Tennessee, November 1996. + + [RFC-2048] + Freed, N., Klensin, J., and J. Postel, "Multipurpose + Internet Mail Extensions (MIME) Part Four: MIME + Registration Procedures", RFC 2048, Innosoft, MCI, + ISI, November 1996. + + [RFC-2049] + Freed, N. and N. Borenstein, "Multipurpose Internet Mail + Extensions (MIME) Part Five: Conformance Criteria and + Examples", RFC 2049 (this document), Innosoft, First + Virtual Holdings, November 1996. + + [US-ASCII] + Coded Character Set -- 7-Bit American Standard Code for + Information Interchange, ANSI X3.4-1986. + + [X400] + Schicker, Pietro, "Message Handling Systems, X.400", + Message Handling Systems and Distributed Applications, E. + Stefferud, O-j. Jacobsen, and P. Schicker, eds., North- + Holland, 1989, pp. 3-41. + + + + + + + + + + + + + +Freed & Borenstein Standards Track [Page 24] + diff --git a/RFCs/rfc2183.txt b/RFCs/rfc2183.txt new file mode 100644 index 0000000..f16f127 --- /dev/null +++ b/RFCs/rfc2183.txt @@ -0,0 +1,675 @@ + + + + + + +Network Working Group R. Troost +Request for Comments: 2183 New Century Systems +Updates: 1806 S. Dorner +Category: Standards Track QUALCOMM Incorporated + K. Moore, Editor + University of Tennessee + August 1997 + + + Communicating Presentation Information in + Internet Messages: + The Content-Disposition Header Field + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Abstract + + This memo provides a mechanism whereby messages conforming to the + MIME specifications [RFC 2045, RFC 2046, RFC 2047, RFC 2048, RFC + 2049] can convey presentational information. It specifies the + "Content-Disposition" header field, which is optional and valid for + any MIME entity ("message" or "body part"). Two values for this + header field are described in this memo; one for the ordinary linear + presentation of the body part, and another to facilitate the use of + mail to transfer files. It is expected that more values will be + defined in the future, and procedures are defined for extending this + set of values. + + This document is intended as an extension to MIME. As such, the + reader is assumed to be familiar with the MIME specifications, and + [RFC 822]. The information presented herein supplements but does not + replace that found in those documents. + + This document is a revision to the Experimental protocol defined in + RFC 1806. As compared to RFC 1806, this document contains minor + editorial updates, adds new parameters needed to support the File + Transfer Body Part, and references a separate specification for the + handling of non-ASCII and/or very long parameter values. + + + + + + + +Troost, et. al. Standards Track [Page 1] + +RFC 2183 Content-Disposition August 1997 + + +1. Introduction + + MIME specifies a standard format for encapsulating multiple pieces of + data into a single Internet message. That document does not address + the issue of presentation styles; it provides a framework for the + interchange of message content, but leaves presentation issues solely + in the hands of mail user agent (MUA) implementors. + + Two common ways of presenting multipart electronic messages are as a + main document with a list of separate attachments, and as a single + document with the various parts expanded (displayed) inline. The + display of an attachment is generally construed to require positive + action on the part of the recipient, while inline message components + are displayed automatically when the message is viewed. A mechanism + is needed to allow the sender to transmit this sort of presentational + information to the recipient; the Content-Disposition header provides + this mechanism, allowing each component of a message to be tagged + with an indication of its desired presentation semantics. + + Tagging messages in this manner will often be sufficient for basic + message formatting. However, in many cases a more powerful and + flexible approach will be necessary. The definition of such + approaches is beyond the scope of this memo; however, such approaches + can benefit from additional Content-Disposition values and + parameters, to be defined at a later date. + + In addition to allowing the sender to specify the presentational + disposition of a message component, it is desirable to allow her to + indicate a default archival disposition; a filename. The optional + "filename" parameter provides for this. Further, the creation-date, + modification-date, and read-date parameters allow preservation of + those file attributes when the file is transmitted over MIME email. + + NB: The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, + SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this + document, are to be interpreted as described in [RFC 2119]. + +2. The Content-Disposition Header Field + + Content-Disposition is an optional header field. In its absence, the + MUA may use whatever presentation method it deems suitable. + + It is desirable to keep the set of possible disposition types small + and well defined, to avoid needless complexity. Even so, evolving + usage will likely require the definition of additional disposition + types or parameters, so the set of disposition values is extensible; + see below. + + + + +Troost, et. al. Standards Track [Page 2] + +RFC 2183 Content-Disposition August 1997 + + + In the extended BNF notation of [RFC 822], the Content-Disposition + header field is defined as follows: + + disposition := "Content-Disposition" ":" + disposition-type + *(";" disposition-parm) + + disposition-type := "inline" + / "attachment" + / extension-token + ; values are not case-sensitive + + disposition-parm := filename-parm + / creation-date-parm + / modification-date-parm + / read-date-parm + / size-parm + / parameter + + filename-parm := "filename" "=" value + + creation-date-parm := "creation-date" "=" quoted-date-time + + modification-date-parm := "modification-date" "=" quoted-date-time + + read-date-parm := "read-date" "=" quoted-date-time + + size-parm := "size" "=" 1*DIGIT + + quoted-date-time := quoted-string + ; contents MUST be an RFC 822 `date-time' + ; numeric timezones (+HHMM or -HHMM) MUST be used + + + + NOTE ON PARAMETER VALUE LENGHTS: A short (length <= 78 characters) + parameter value containing only non-`tspecials' characters SHOULD be + represented as a single `token'. A short parameter value containing + only ASCII characters, but including `tspecials' characters, SHOULD + be represented as `quoted-string'. Parameter values longer than 78 + characters, or which contain non-ASCII characters, MUST be encoded as + specified in [RFC 2184]. + + `Extension-token', `parameter', `tspecials' and `value' are defined + according to [RFC 2045] (which references [RFC 822] in the definition + of some of these tokens). `quoted-string' and `DIGIT' are defined in + [RFC 822]. + + + + +Troost, et. al. Standards Track [Page 3] + +RFC 2183 Content-Disposition August 1997 + + +2.1 The Inline Disposition Type + + A bodypart should be marked `inline' if it is intended to be + displayed automatically upon display of the message. Inline + bodyparts should be presented in the order in which they occur, + subject to the normal semantics of multipart messages. + +2.2 The Attachment Disposition Type + + Bodyparts can be designated `attachment' to indicate that they are + separate from the main body of the mail message, and that their + display should not be automatic, but contingent upon some further + action of the user. The MUA might instead present the user of a + bitmap terminal with an iconic representation of the attachments, or, + on character terminals, with a list of attachments from which the + user could select for viewing or storage. + +2.3 The Filename Parameter + + The sender may want to suggest a filename to be used if the entity is + detached and stored in a separate file. If the receiving MUA writes + the entity to a file, the suggested filename should be used as a + basis for the actual filename, where possible. + + It is important that the receiving MUA not blindly use the suggested + filename. The suggested filename SHOULD be checked (and possibly + changed) to see that it conforms to local filesystem conventions, + does not overwrite an existing file, and does not present a security + problem (see Security Considerations below). + + The receiving MUA SHOULD NOT respect any directory path information + that may seem to be present in the filename parameter. The filename + should be treated as a terminal component only. Portable + specification of directory paths might possibly be done in the future + via a separate Content-Disposition parameter, but no provision is + made for it in this draft. + + Current [RFC 2045] grammar restricts parameter values (and hence + Content-Disposition filenames) to US-ASCII. We recognize the great + desirability of allowing arbitrary character sets in filenames, but + it is beyond the scope of this document to define the necessary + mechanisms. We expect that the basic [RFC 1521] `value' + specification will someday be amended to allow use of non-US-ASCII + characters, at which time the same mechanism should be used in the + Content-Disposition filename parameter. + + + + + + +Troost, et. al. Standards Track [Page 4] + +RFC 2183 Content-Disposition August 1997 + + + Beyond the limitation to US-ASCII, the sending MUA may wish to bear + in mind the limitations of common filesystems. Many have severe + length and character set restrictions. Short alphanumeric filenames + are least likely to require modification by the receiving system. + + The presence of the filename parameter does not force an + implementation to write the entity to a separate file. It is + perfectly acceptable for implementations to leave the entity as part + of the normal mail stream unless the user requests otherwise. As a + consequence, the parameter may be used on any MIME entity, even + `inline' ones. These will not normally be written to files, but the + parameter could be used to provide a filename if the receiving user + should choose to write the part to a file. + +2.4 The Creation-Date parameter + + The creation-date parameter MAY be used to indicate the date at which + the file was created. If this parameter is included, the paramter + value MUST be a quoted-string which contains a representation of the + creation date of the file in [RFC 822] `date-time' format. + + UNIX and POSIX implementors are cautioned that the `st_ctime' file + attribute of the `stat' structure is not the creation time of the + file; it is thus not appropriate as a source for the creation-date + parameter value. + +2.5 The Modification-Date parameter + + The modification-date parameter MAY be used to indicate the date at + which the file was last modified. If the modification-date parameter + is included, the paramter value MUST be a quoted-string which + contains a representation of the last modification date of the file + in [RFC 822] `date-time' format. + +2.6 The Read-Date parameter + + The read-date parameter MAY be used to indicate the date at which the + file was last read. If the read-date parameter is included, the + parameter value MUST be a quoted-string which contains a + representation of the last-read date of the file in [RFC 822] `date- + time' format. + +2.7 The Size parameter + + The size parameter indicates an approximate size of the file in + octets. It can be used, for example, to pre-allocate space before + attempting to store the file, or to determine whether enough space + exists. + + + +Troost, et. al. Standards Track [Page 5] + +RFC 2183 Content-Disposition August 1997 + + +2.8 Future Extensions and Unrecognized Disposition Types + + In the likely event that new parameters or disposition types are + needed, they should be registered with the Internet Assigned Numbers + Authority (IANA), in the manner specified in Section 9 of this memo. + + Once new disposition types and parameters are defined, there is of + course the likelihood that implementations will see disposition types + and parameters they do not understand. Furthermore, since x-tokens + are allowed, implementations may also see entirely unregistered + disposition types and parameters. + + Unrecognized parameters should be ignored. Unrecognized disposition + types should be treated as `attachment'. The choice of `attachment' + for unrecognized types is made because a sender who goes to the + trouble of producing a Content-Disposition header with a new + disposition type is more likely aiming for something more elaborate + than inline presentation. + + Unless noted otherwise in the definition of a parameter, Content- + Disposition parameters are valid for all dispositions. (In contrast + to MIME content-type parameters, which are defined on a per-content- + type basis.) Thus, for example, the `filename' parameter still means + the name of the file to which the part should be written, even if the + disposition itself is unrecognized. + +2.9 Content-Disposition and Multipart + + If a Content-Disposition header is used on a multipart body part, it + applies to the multipart as a whole, not the individual subparts. + The disposition types of the subparts do not need to be consulted + until the multipart itself is presented. When the multipart is + displayed, then the dispositions of the subparts should be respected. + + If the `inline' disposition is used, the multipart should be + displayed as normal; however, an `attachment' subpart should require + action from the user to display. + + If the `attachment' disposition is used, presentation of the + multipart should not proceed without explicit user action. Once the + user has chosen to display the multipart, the individual subpart + dispositions should be consulted to determine how to present the + subparts. + + + + + + + + +Troost, et. al. Standards Track [Page 6] + +RFC 2183 Content-Disposition August 1997 + + +2.10 Content-Disposition and the Main Message + + It is permissible to use Content-Disposition on the main body of an + [RFC 822] message. + +3. Examples + + Here is a an example of a body part containing a JPEG image that is + intended to be viewed by the user immediately: + + Content-Type: image/jpeg + Content-Disposition: inline + Content-Description: just a small picture of me + + + + The following body part contains a JPEG image that should be + displayed to the user only if the user requests it. If the JPEG is + written to a file, the file should be named "genome.jpg". The + recipient's user might also choose to set the last-modified date of + the stored file to date in the modification-date parameter: + + Content-Type: image/jpeg + Content-Disposition: attachment; filename=genome.jpeg; + modification-date="Wed, 12 Feb 1997 16:29:51 -0500"; + Content-Description: a complete map of the human genome + + + + The following is an example of the use of the `attachment' + disposition with a multipart body part. The user should see text- + part-1 immediately, then take some action to view multipart-2. After + taking action to view multipart-2, the user will see text-part-2 + right away, and be required to take action to view jpeg-1. Subparts + are indented for clarity; they would not be so indented in a real + message. + + + + + + + + + + + + + + + +Troost, et. al. Standards Track [Page 7] + +RFC 2183 Content-Disposition August 1997 + + + Content-Type: multipart/mixed; boundary=outer + Content-Description: multipart-1 + + --outer + Content-Type: text/plain + Content-Disposition: inline + Content-Description: text-part-1 + + Some text goes here + + --outer + Content-Type: multipart/mixed; boundary=inner + Content-Disposition: attachment + Content-Description: multipart-2 + + --inner + Content-Type: text/plain + Content-Disposition: inline + Content-Description: text-part-2 + + Some more text here. + + --inner + Content-Type: image/jpeg + Content-Disposition: attachment + Content-Description: jpeg-1 + + + --inner-- + --outer-- + +4. Summary + + Content-Disposition takes one of two values, `inline' and + `attachment'. `Inline' indicates that the entity should be + immediately displayed to the user, whereas `attachment' means that + the user should take additional action to view the entity. + + The `filename' parameter can be used to suggest a filename for + storing the bodypart, if the user wishes to store it in an external + file. + + + + + + + + + + +Troost, et. al. Standards Track [Page 8] + +RFC 2183 Content-Disposition August 1997 + + +5. Security Considerations + + There are security issues involved any time users exchange data. + While these are not to be minimized, neither does this memo change + the status quo in that regard, except in one instance. + + Since this memo provides a way for the sender to suggest a filename, + a receiving MUA must take care that the sender's suggested filename + does not represent a hazard. Using UNIX as an example, some hazards + would be: + + + Creating startup files (e.g., ".login"). + + + Creating or overwriting system files (e.g., "/etc/passwd"). + + + Overwriting any existing file. + + + Placing executable files into any command search path + (e.g., "~/bin/more"). + + + Sending the file to a pipe (e.g., "| sh"). + + In general, the receiving MUA should not name or place the file such + that it will get interpreted or executed without the user explicitly + initiating the action. + + It is very important to note that this is not an exhaustive list; it + is intended as a small set of examples only. Implementors must be + alert to the potential hazards on their target systems. + +6. References + + [RFC 2119] + Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", RFC 2119, March 1997. + + [RFC 2184] + Freed, N. and K. Moore, "MIME Parameter value and Encoded Words: + Character Sets, Lanaguage, and Continuations", RFC 2184, August + 1997. + + [RFC 2045] + Freed, N. and N. Borenstein, "MIME (Multipurpose Internet Mail + Extensions) Part One: Format of Internet Message Bodies", RFC + 2045, December 1996. + + + + + + +Troost, et. al. Standards Track [Page 9] + +RFC 2183 Content-Disposition August 1997 + + + [RFC 2046] + Freed, N. and N. Borenstein, "MIME (Multipurpose Internet Mail + Extensions) Part Two: Media Types", RFC 2046, December 1996. + + [RFC 2047] + Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part + Three: Message Header Extensions for non-ASCII Text", RFC 2047, + December 1996. + + [RFC 2048] + Freed, N., Klensin, J. and J. Postel, "MIME (Multipurpose + Internet Mail Extensions) Part Four: Registration Procedures", + RFC 2048, December 1996. + + [RFC 2049] + Freed, N. and N. Borenstein, "MIME (Multipurpose Internet Mail + Extensions) Part Five: Conformance Criteria and Examples", RFC + 2049, December 1996. + + [RFC 822] + Crocker, D., "Standard for the Format of ARPA Internet Text + Messages", STD 11, RFC 822, UDEL, August 1982. + +7. Acknowledgements + + We gratefully acknowledge the help these people provided during the + preparation of this draft: + + Nathaniel Borenstein + Ned Freed + Keith Moore + Dave Crocker + Dan Pritchett + + + + + + + + + + + + + + + + + + +Troost, et. al. Standards Track [Page 10] + +RFC 2183 Content-Disposition August 1997 + + +8. Authors' Addresses + + You should blame the editor of this version of the document for any + changes since RFC 1806: + + Keith Moore + Department of Computer Science + University of Tennessee, Knoxville + 107 Ayres Hall + Knoxville TN 37996-1301 + USA + + Phone: +1 (423) 974-5067 + Fax: +1 (423) 974-8296 + Email: moore@cs.utk.edu + + + The authors of RFC 1806 are: + + Rens Troost + New Century Systems + 324 East 41st Street #804 + New York, NY, 10017 USA + + Phone: +1 (212) 557-2050 + Fax: +1 (212) 557-2049 + EMail: rens@century.com + + + Steve Dorner + QUALCOMM Incorporated + 6455 Lusk Boulevard + San Diego, CA 92121 + USA + + EMail: sdorner@qualcomm.com + + +9. Registration of New Content-Disposition Values and Parameters + + New Content-Disposition values (besides "inline" and "attachment") + may be defined only by Internet standards-track documents, or in + Experimental documents approved by the Internet Engineering Steering + Group. + + + + + + + +Troost, et. al. Standards Track [Page 11] + +RFC 2183 Content-Disposition August 1997 + + + New content-disposition parameters may be registered by supplying the + information in the following template and sending it via electronic + mail to IANA@IANA.ORG: + + To: IANA@IANA.ORG + Subject: Registration of new Content-Disposition parameter + + Content-Disposition parameter name: + + Allowable values for this parameter: + (If the parameter can only assume a small number of values, + list each of those values. Otherwise, describe the values + that the parameter can assume.) + Description: + (What is the purpose of this parameter and how is it used?) + +10. Changes since RFC 1806 + + The following changes have been made since the earlier version of + this document, published in RFC 1806 as an Experimental protocol: + + + Updated references to MIME documents. In some cases this + involved substituting a reference to one of the current MIME + RFCs for a reference to RFC 1521; in other cases, a reference to + RFC 1521 was simply replaced with the word "MIME". + + + Added a section on registration procedures, since none of the + procedures in RFC 2048 seemed to be appropriate. + + + Added new parameter types: creation-date, modification-date, + read-date, and size. + + + + Incorporated a reference to draft-freed-pvcsc-* for encoding + long or non-ASCII parameter values. + + + Added reference to RFC 2119 to define MUST, SHOULD, etc. + keywords. + + + + + + + + + + + + + +Troost, et. al. Standards Track [Page 12] + diff --git a/RFCs/rfc2487.txt b/RFCs/rfc2487.txt new file mode 100644 index 0000000..fb1305f --- /dev/null +++ b/RFCs/rfc2487.txt @@ -0,0 +1,451 @@ + + + + + + +Network Working Group P. Hoffman +Request for Comments: 2487 Internet Mail Consortium +Category: Standards Track January 1999 + + + SMTP Service Extension for Secure SMTP over TLS + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (1999). All Rights Reserved. + +1. Abstract + + This document describes an extension to the SMTP service that allows + an SMTP server and client to use transport-layer security to provide + private, authenticated communication over the Internet. This gives + SMTP agents the ability to protect some or all of their + communications from eavesdroppers and attackers. + +2. Introduction + + SMTP [RFC-821] servers and clients normally communicate in the clear + over the Internet. In many cases, this communication goes through one + or more router that is not controlled or trusted by either entity. + Such an untrusted router might allow a third party to monitor or + alter the communications between the server and client. + + Further, there is often a desire for two SMTP agents to be able to + authenticate each others' identities. For example, a secure SMTP + server might only allow communications from other SMTP agents it + knows, or it might act differently for messages received from an + agent it knows than from one it doesn't know. + + TLS [TLS], more commonly known as SSL, is a popular mechanism for + enhancing TCP communications with privacy and authentication. TLS is + in wide use with the HTTP protocol, and is also being used for adding + security to many other common protocols that run over TCP. + + + + + + +Hoffman Standards Track [Page 1] + +RFC 2487 SMTP Service Extension January 1999 + + +2.1 Terminology + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [RFC-2119]. + +3. STARTTLS Extension + + The STARTTLS extension to SMTP is laid out as follows: + + (1) the name of the SMTP service defined here is STARTTLS; + + (2) the EHLO keyword value associated with the extension is STARTTLS; + + (3) the STARTTLS keyword has no parameters; + + (4) a new SMTP verb, "STARTTLS", is defined; + + (5) no additional parameters are added to any SMTP command. + +4. The STARTTLS Keyword + + The STARTTLS keyword is used to tell the SMTP client that the SMTP + server allows use of TLS. It takes no parameters. + +5. The STARTTLS Command + + The format for the STARTTLS command is: + + STARTTLS + + with no parameters. + + After the client gives the STARTTLS command, the server responds with + one of the following reply codes: + + 220 Ready to start TLS + 501 Syntax error (no parameters allowed) + 454 TLS not available due to temporary reason + + A publicly-referenced SMTP server MUST NOT require use of the + STARTTLS extension in order to deliver mail locally. This rule + prevents the STARTTLS extension from damaging the interoperability of + the Internet's SMTP infrastructure. A publicly-referenced SMTP server + is an SMTP server which runs on port 25 of an Internet host listed in + the MX record (or A record if an MX record is not present) for the + domain name on the right hand side of an Internet mail address. + + + + +Hoffman Standards Track [Page 2] + +RFC 2487 SMTP Service Extension January 1999 + + + Any SMTP server may refuse to accept messages for relay based on + authentication supplied during the TLS negotiation. An SMTP server + that is not publicly referenced may refuse to accept any messages for + relay or local delivery based on authentication supplied during the + TLS negotiation. + + A SMTP server that is not publicly referenced may choose to require + that the client perform a TLS negotiation before accepting any + commands. In this case, the server SHOULD return the reply code: + + 530 Must issue a STARTTLS command first + + to every command other than NOOP, EHLO, STARTTLS, or QUIT. If the + client and server are using the ENHANCEDSTATUSCODES ESMTP extension + [RFC-2034], the status code to be returned SHOULD be 5.7.0. + + After receiving a 220 response to a STARTTLS command, the client + SHOULD start the TLS negotiation before giving any other SMTP + commands. + + If the SMTP client is using pipelining as defined in RFC 1854, the + STARTTLS command must be the last command in a group. + +5.1 Processing After the STARTTLS Command + + After the TLS handshake has been completed, both parties MUST + immediately decide whether or not to continue based on the + authentication and privacy achieved. The SMTP client and server may + decide to move ahead even if the TLS negotiation ended with no + authentication and/or no privacy because most SMTP services are + performed with no authentication and no privacy, but some SMTP + clients or servers may want to continue only if a particular level of + authentication and/or privacy was achieved. + + If the SMTP client decides that the level of authentication or + privacy is not high enough for it to continue, it SHOULD issue an + SMTP QUIT command immediately after the TLS negotiation is complete. + If the SMTP server decides that the level of authentication or + privacy is not high enough for it to continue, it SHOULD reply to + every SMTP command from the client (other than a QUIT command) with + the 554 reply code (with a possible text string such as "Command + refused due to lack of security"). + + The decision of whether or not to believe the authenticity of the + other party in a TLS negotiation is a local matter. However, some + general rules for the decisions are: + + + + + +Hoffman Standards Track [Page 3] + +RFC 2487 SMTP Service Extension January 1999 + + + - A SMTP client would probably only want to authenticate an SMTP + server whose server certificate has a domain name that is the + domain name that the client thought it was connecting to. + - A publicly-referenced SMTP server would probably want to accept + any certificate from an SMTP client, and would possibly want to + put distinguishing information about the certificate in the + Received header of messages that were relayed or submitted from + the client. + +5.2 Result of the STARTTLS Command + + Upon completion of the TLS handshake, the SMTP protocol is reset to + the initial state (the state in SMTP after a server issues a 220 + service ready greeting). The server MUST discard any knowledge + obtained from the client, such as the argument to the EHLO command, + which was not obtained from the TLS negotiation itself. The client + MUST discard any knowledge obtained from the server, such as the list + of SMTP service extensions, which was not obtained from the TLS + negotiation itself. The client SHOULD send an EHLO command as the + first command after a successful TLS negotiation. + + The list of SMTP service extensions returned in response to an EHLO + command received after the TLS handshake MAY be different than the + list returned before the TLS handshake. For example, an SMTP server + might not want to advertise support for a particular SASL mechanism + [SASL] unless a client has sent an appropriate client certificate + during a TLS handshake. + + Both the client and the server MUST know if there is a TLS session + active. A client MUST NOT attempt to start a TLS session if a TLS + session is already active. A server MUST NOT return the TLS extension + in response to an EHLO command received after a TLS handshake has + completed. + +6. Usage Example + + The following dialog illustrates how a client and server can start a + TLS session: + + S: + C: + S: 220 mail.imc.org SMTP service ready + C: EHLO mail.ietf.org + S: 250-mail.imc.org offers a warm hug of welcome + S: 250 STARTTLS + C: STARTTLS + S: 220 Go ahead + C: + + + +Hoffman Standards Track [Page 4] + +RFC 2487 SMTP Service Extension January 1999 + + + C & S: + C & S: + C: + . . . + +7. Security Considerations + + It should be noted that SMTP is not an end-to-end mechanism. Thus, if + an SMTP client/server pair decide to add TLS privacy, they are not + securing the transport from the originating mail user agent to the + recipient. Further, because delivery of a single piece of mail may + go between more than two SMTP servers, adding TLS privacy to one pair + of servers does not mean that the entire SMTP chain has been made + private. Further, just because an SMTP server can authenticate an + SMTP client, it does not mean that the mail from the SMTP client was + authenticated by the SMTP client when the client received it. + + Both the STMP client and server must check the result of the TLS + negotiation to see whether acceptable authentication or privacy was + achieved. Ignoring this step completely invalidates using TLS for + security. The decision about whether acceptable authentication or + privacy was achieved is made locally, is implementation-dependant, + and is beyond the scope of this document. + + The SMTP client and server should note carefully the result of the + TLS negotiation. If the negotiation results in no privacy, or if it + results in privacy using algorithms or key lengths that are deemed + not strong enough, or if the authentication is not good enough for + either party, the client may choose to end the SMTP session with an + immediate QUIT command, or the server may choose to not accept any + more SMTP commands. + + A server announcing in an EHLO response that it uses a particular TLS + protocol should not pose any security issues, since any use of TLS + will be at least as secure as no use of TLS. + + A man-in-the-middle attack can be launched by deleting the "250 + STARTTLS" response from the server. This would cause the client not + to try to start a TLS session. An SMTP client can protect against + this attack by recording the fact that a particular SMTP server + offers TLS during one session and generating an alarm if it does not + appear in the EHLO response for a later session. The lack of TLS + during a session SHOULD NOT result in the bouncing of email, although + it could result in delayed processing. + + + + + + + +Hoffman Standards Track [Page 5] + +RFC 2487 SMTP Service Extension January 1999 + + + Before the TLS handshake has begun, any protocol interactions are + performed in the clear and may be modified by an active attacker. For + this reason, clients and servers MUST discard any knowledge obtained + prior to the start of the TLS handshake upon completion of the TLS + handshake. + + The STARTTLS extension is not suitable for authenticating the author + of an email message unless every hop in the delivery chain, including + the submission to the first SMTP server, is authenticated. Another + proposal [SMTP-AUTH] can be used to authenticate delivery and MIME + security multiparts [MIME-SEC] can be used to authenticate the author + of an email message. In addition, the [SMTP-AUTH] proposal offers + simpler and more flexible options to authenticate an SMTP client and + the SASL EXTERNAL mechanism [SASL] MAY be used in conjunction with + the STARTTLS command to provide an authorization identity. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Hoffman Standards Track [Page 6] + +RFC 2487 SMTP Service Extension January 1999 + + +A. References + + [RFC-821] Postel, J., "Simple Mail Transfer Protocol", RFC 821, + August 1982. + + [RFC-1869] Klensin, J., Freed, N, Rose, M, Stefferud, E. and D. + Crocker, "SMTP Service Extensions", STD 10, RFC 1869, + November 1995. + + [RFC-2034] Freed, N., "SMTP Service Extension for Returning Enhanced + Error Codes", RFC 2034, October 1996. + + [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [SASL] Myers, J., "Simple Authentication and Security Layer + (SASL)", RFC 2222, October 1997. + + [SMTP-AUTH] "SMTP Service Extension for Authentication", Work in + Progress. + + [TLS] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", + RFC 2246, January 1999. + +B. Author's Address + + Paul Hoffman + Internet Mail Consortium + 127 Segre Place + Santa Cruz, CA 95060 + + Phone: (831) 426-9827 + EMail: phoffman@imc.org + + + + + + + + + + + + + + + + + + +Hoffman Standards Track [Page 7] + +RFC 2487 SMTP Service Extension January 1999 + + +C. Full Copyright Statement + + Copyright (C) The Internet Society (1999). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + + + + + + + + + + + + + + + + + + + + + + + +Hoffman Standards Track [Page 8] + diff --git a/RFCs/rfc2595.txt b/RFCs/rfc2595.txt new file mode 100644 index 0000000..66897cd --- /dev/null +++ b/RFCs/rfc2595.txt @@ -0,0 +1,843 @@ + + + + + + +Network Working Group C. Newman +Request for Comments: 2595 Innosoft +Category: Standards Track June 1999 + + + Using TLS with IMAP, POP3 and ACAP + + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (1999). All Rights Reserved. + +1. Motivation + + The TLS protocol (formerly known as SSL) provides a way to secure an + application protocol from tampering and eavesdropping. The option of + using such security is desirable for IMAP, POP and ACAP due to common + connection eavesdropping and hijacking attacks [AUTH]. Although + advanced SASL authentication mechanisms can provide a lightweight + version of this service, TLS is complimentary to simple + authentication-only SASL mechanisms or deployed clear-text password + login commands. + + Many sites have a high investment in authentication infrastructure + (e.g., a large database of a one-way-function applied to user + passwords), so a privacy layer which is not tightly bound to user + authentication can protect against network eavesdropping attacks + without requiring a new authentication infrastructure and/or forcing + all users to change their password. Recognizing that such sites will + desire simple password authentication in combination with TLS + encryption, this specification defines the PLAIN SASL mechanism for + use with protocols which lack a simple password authentication + command such as ACAP and SMTP. (Note there is a separate RFC for the + STARTTLS command in SMTP [SMTPTLS].) + + There is a strong desire in the IETF to eliminate the transmission of + clear-text passwords over unencrypted channels. While SASL can be + used for this purpose, TLS provides an additional tool with different + deployability characteristics. A server supporting both TLS with + + + + +Newman Standards Track [Page 1] + +RFC 2595 Using TLS with IMAP, POP3 and ACAP June 1999 + + + simple passwords and a challenge/response SASL mechanism is likely to + interoperate with a wide variety of clients without resorting to + unencrypted clear-text passwords. + + The STARTTLS command rectifies a number of the problems with using a + separate port for a "secure" protocol variant. Some of these are + mentioned in section 7. + +1.1. Conventions Used in this Document + + The key words "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", + "MAY", and "OPTIONAL" in this document are to be interpreted as + described in "Key words for use in RFCs to Indicate Requirement + Levels" [KEYWORDS]. + + Terms related to authentication are defined in "On Internet + Authentication" [AUTH]. + + Formal syntax is defined using ABNF [ABNF]. + + In examples, "C:" and "S:" indicate lines sent by the client and + server respectively. + +2. Basic Interoperability and Security Requirements + + The following requirements apply to all implementations of the + STARTTLS extension for IMAP, POP3 and ACAP. + +2.1. Cipher Suite Requirements + + Implementation of the TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA [TLS] cipher + suite is REQUIRED. This is important as it assures that any two + compliant implementations can be configured to interoperate. + + All other cipher suites are OPTIONAL. + +2.2. Privacy Operational Mode Security Requirements + + Both clients and servers SHOULD have a privacy operational mode which + refuses authentication unless successful activation of an encryption + layer (such as that provided by TLS) occurs prior to or at the time + of authentication and which will terminate the connection if that + encryption layer is deactivated. Implementations are encouraged to + have flexability with respect to the minimal encryption strength or + cipher suites permitted. A minimalist approach to this + recommendation would be an operational mode where the + TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA cipher suite is mandatory prior to + permitting authentication. + + + +Newman Standards Track [Page 2] + +RFC 2595 Using TLS with IMAP, POP3 and ACAP June 1999 + + + Clients MAY have an operational mode which uses encryption only when + it is advertised by the server, but authentication continues + regardless. For backwards compatibility, servers SHOULD have an + operational mode where only the authentication mechanisms required by + the relevant base protocol specification are needed to successfully + authenticate. + +2.3. Clear-Text Password Requirements + + Clients and servers which implement STARTTLS MUST be configurable to + refuse all clear-text login commands or mechanisms (including both + standards-track and nonstandard mechanisms) unless an encryption + layer of adequate strength is active. Servers which allow + unencrypted clear-text logins SHOULD be configurable to refuse + clear-text logins both for the entire server, and on a per-user + basis. + +2.4. Server Identity Check + + During the TLS negotiation, the client MUST check its understanding + of the server hostname against the server's identity as presented in + the server Certificate message, in order to prevent man-in-the-middle + attacks. Matching is performed according to these rules: + + - The client MUST use the server hostname it used to open the + connection as the value to compare against the server name as + expressed in the server certificate. The client MUST NOT use any + form of the server hostname derived from an insecure remote source + (e.g., insecure DNS lookup). CNAME canonicalization is not done. + + - If a subjectAltName extension of type dNSName is present in the + certificate, it SHOULD be used as the source of the server's + identity. + + - Matching is case-insensitive. + + - A "*" wildcard character MAY be used as the left-most name + component in the certificate. For example, *.example.com would + match a.example.com, foo.example.com, etc. but would not match + example.com. + + - If the certificate contains multiple names (e.g. more than one + dNSName field), then a match with any one of the fields is + considered acceptable. + + If the match fails, the client SHOULD either ask for explicit user + confirmation, or terminate the connection and indicate the server's + identity is suspect. + + + +Newman Standards Track [Page 3] + +RFC 2595 Using TLS with IMAP, POP3 and ACAP June 1999 + + +2.5. TLS Security Policy Check + + Both the client and server MUST check the result of the STARTTLS + command and subsequent TLS negotiation to see whether acceptable + authentication or privacy was achieved. Ignoring this step + completely invalidates using TLS for security. The decision about + whether acceptable authentication or privacy was achieved is made + locally, is implementation-dependent, and is beyond the scope of this + document. + +3. IMAP STARTTLS extension + + When the TLS extension is present in IMAP, "STARTTLS" is listed as a + capability in response to the CAPABILITY command. This extension + adds a single command, "STARTTLS" to the IMAP protocol which is used + to begin a TLS negotiation. + +3.1. STARTTLS Command + + Arguments: none + + Responses: no specific responses for this command + + Result: OK - begin TLS negotiation + BAD - command unknown or arguments invalid + + A TLS negotiation begins immediately after the CRLF at the end of + the tagged OK response from the server. Once a client issues a + STARTTLS command, it MUST NOT issue further commands until a + server response is seen and the TLS negotiation is complete. + + The STARTTLS command is only valid in non-authenticated state. + The server remains in non-authenticated state, even if client + credentials are supplied during the TLS negotiation. The SASL + [SASL] EXTERNAL mechanism MAY be used to authenticate once TLS + client credentials are successfully exchanged, but servers + supporting the STARTTLS command are not required to support the + EXTERNAL mechanism. + + Once TLS has been started, the client MUST discard cached + information about server capabilities and SHOULD re-issue the + CAPABILITY command. This is necessary to protect against + man-in-the-middle attacks which alter the capabilities list prior + to STARTTLS. The server MAY advertise different capabilities + after STARTTLS. + + The formal syntax for IMAP is amended as follows: + + + + +Newman Standards Track [Page 4] + +RFC 2595 Using TLS with IMAP, POP3 and ACAP June 1999 + + + command_any =/ "STARTTLS" + + Example: C: a001 CAPABILITY + S: * CAPABILITY IMAP4rev1 STARTTLS LOGINDISABLED + S: a001 OK CAPABILITY completed + C: a002 STARTTLS + S: a002 OK Begin TLS negotiation now + + C: a003 CAPABILITY + S: * CAPABILITY IMAP4rev1 AUTH=EXTERNAL + S: a003 OK CAPABILITY completed + C: a004 LOGIN joe password + S: a004 OK LOGIN completed + +3.2. IMAP LOGINDISABLED capability + + The current IMAP protocol specification (RFC 2060) requires the + implementation of the LOGIN command which uses clear-text passwords. + Many sites may choose to disable this command unless encryption is + active for security reasons. An IMAP server MAY advertise that the + LOGIN command is disabled by including the LOGINDISABLED capability + in the capability response. Such a server will respond with a tagged + "NO" response to any attempt to use the LOGIN command. + + An IMAP server which implements STARTTLS MUST implement support for + the LOGINDISABLED capability on unencrypted connections. + + An IMAP client which complies with this specification MUST NOT issue + the LOGIN command if this capability is present. + + This capability is useful to prevent clients compliant with this + specification from sending an unencrypted password in an environment + subject to passive attacks. It has no impact on an environment + subject to active attacks as a man-in-the-middle attacker can remove + this capability. Therefore this does not relieve clients of the need + to follow the privacy mode recommendation in section 2.2. + + Servers advertising this capability will fail to interoperate with + many existing compliant IMAP clients and will be unable to prevent + those clients from disclosing the user's password. + +4. POP3 STARTTLS extension + + The POP3 STARTTLS extension adds the STLS command to POP3 servers. + If this is implemented, the POP3 extension mechanism [POP3EXT] MUST + also be implemented to avoid the need for client probing of multiple + commands. The capability name "STLS" indicates this command is + present and permitted in the current state. + + + +Newman Standards Track [Page 5] + +RFC 2595 Using TLS with IMAP, POP3 and ACAP June 1999 + + + STLS + + Arguments: none + + Restrictions: + Only permitted in AUTHORIZATION state. + + Discussion: + A TLS negotiation begins immediately after the CRLF at the + end of the +OK response from the server. A -ERR response + MAY result if a security layer is already active. Once a + client issues a STLS command, it MUST NOT issue further + commands until a server response is seen and the TLS + negotiation is complete. + + The STLS command is only permitted in AUTHORIZATION state + and the server remains in AUTHORIZATION state, even if + client credentials are supplied during the TLS negotiation. + The AUTH command [POP-AUTH] with the EXTERNAL mechanism + [SASL] MAY be used to authenticate once TLS client + credentials are successfully exchanged, but servers + supporting the STLS command are not required to support the + EXTERNAL mechanism. + + Once TLS has been started, the client MUST discard cached + information about server capabilities and SHOULD re-issue + the CAPA command. This is necessary to protect against + man-in-the-middle attacks which alter the capabilities list + prior to STLS. The server MAY advertise different + capabilities after STLS. + + Possible Responses: + +OK -ERR + + Examples: + C: STLS + S: +OK Begin TLS negotiation + + ... + C: STLS + S: -ERR Command not permitted when TLS active + + + + + + + + + + +Newman Standards Track [Page 6] + +RFC 2595 Using TLS with IMAP, POP3 and ACAP June 1999 + + +5. ACAP STARTTLS extension + + When the TLS extension is present in ACAP, "STARTTLS" is listed as a + capability in the ACAP greeting. No arguments to this capability are + defined at this time. This extension adds a single command, + "STARTTLS" to the ACAP protocol which is used to begin a TLS + negotiation. + +5.1. STARTTLS Command + + Arguments: none + + Responses: no specific responses for this command + + Result: OK - begin TLS negotiation + BAD - command unknown or arguments invalid + + A TLS negotiation begins immediately after the CRLF at the end of + the tagged OK response from the server. Once a client issues a + STARTTLS command, it MUST NOT issue further commands until a + server response is seen and the TLS negotiation is complete. + + The STARTTLS command is only valid in non-authenticated state. + The server remains in non-authenticated state, even if client + credentials are supplied during the TLS negotiation. The SASL + [SASL] EXTERNAL mechanism MAY be used to authenticate once TLS + client credentials are successfully exchanged, but servers + supporting the STARTTLS command are not required to support the + EXTERNAL mechanism. + + After the TLS layer is established, the server MUST re-issue an + untagged ACAP greeting. This is necessary to protect against + man-in-the-middle attacks which alter the capabilities list prior + to STARTTLS. The client MUST discard cached capability + information and replace it with the information from the new ACAP + greeting. The server MAY advertise different capabilities after + STARTTLS. + + The formal syntax for ACAP is amended as follows: + + command_any =/ "STARTTLS" + + Example: S: * ACAP (SASL "CRAM-MD5") (STARTTLS) + C: a002 STARTTLS + S: a002 OK "Begin TLS negotiation now" + + S: * ACAP (SASL "CRAM-MD5" "PLAIN" "EXTERNAL") + + + + +Newman Standards Track [Page 7] + +RFC 2595 Using TLS with IMAP, POP3 and ACAP June 1999 + + +6. PLAIN SASL mechanism + + Clear-text passwords are simple, interoperate with almost all + existing operating system authentication databases, and are useful + for a smooth transition to a more secure password-based + authentication mechanism. The drawback is that they are unacceptable + for use over an unencrypted network connection. + + This defines the "PLAIN" SASL mechanism for use with ACAP and other + protocols with no clear-text login command. The PLAIN SASL mechanism + MUST NOT be advertised or used unless a strong encryption layer (such + as the provided by TLS) is active or backwards compatibility dictates + otherwise. + + The mechanism consists of a single message from the client to the + server. The client sends the authorization identity (identity to + login as), followed by a US-ASCII NUL character, followed by the + authentication identity (identity whose password will be used), + followed by a US-ASCII NUL character, followed by the clear-text + password. The client may leave the authorization identity empty to + indicate that it is the same as the authentication identity. + + The server will verify the authentication identity and password with + the system authentication database and verify that the authentication + credentials permit the client to login as the authorization identity. + If both steps succeed, the user is logged in. + + The server MAY also use the password to initialize any new + authentication database, such as one suitable for CRAM-MD5 + [CRAM-MD5]. + + Non-US-ASCII characters are permitted as long as they are represented + in UTF-8 [UTF-8]. Use of non-visible characters or characters which + a user may be unable to enter on some keyboards is discouraged. + + The formal grammar for the client message using Augmented BNF [ABNF] + follows. + + message = [authorize-id] NUL authenticate-id NUL password + authenticate-id = 1*UTF8-SAFE ; MUST accept up to 255 octets + authorize-id = 1*UTF8-SAFE ; MUST accept up to 255 octets + password = 1*UTF8-SAFE ; MUST accept up to 255 octets + NUL = %x00 + UTF8-SAFE = %x01-09 / %x0B-0C / %x0E-7F / UTF8-2 / + UTF8-3 / UTF8-4 / UTF8-5 / UTF8-6 + UTF8-1 = %x80-BF + UTF8-2 = %xC0-DF UTF8-1 + UTF8-3 = %xE0-EF 2UTF8-1 + + + +Newman Standards Track [Page 8] + +RFC 2595 Using TLS with IMAP, POP3 and ACAP June 1999 + + + UTF8-4 = %xF0-F7 3UTF8-1 + UTF8-5 = %xF8-FB 4UTF8-1 + UTF8-6 = %xFC-FD 5UTF8-1 + + Here is an example of how this might be used to initialize a CRAM-MD5 + authentication database for ACAP: + + Example: S: * ACAP (SASL "CRAM-MD5") (STARTTLS) + C: a001 AUTHENTICATE "CRAM-MD5" + S: + "<1896.697170952@postoffice.reston.mci.net>" + C: "tim b913a602c7eda7a495b4e6e7334d3890" + S: a001 NO (TRANSITION-NEEDED) + "Please change your password, or use TLS to login" + C: a002 STARTTLS + S: a002 OK "Begin TLS negotiation now" + + S: * ACAP (SASL "CRAM-MD5" "PLAIN" "EXTERNAL") + C: a003 AUTHENTICATE "PLAIN" {21+} + C: timtanstaaftanstaaf + S: a003 OK CRAM-MD5 password initialized + + Note: In this example, represents a single ASCII NUL octet. + +7. imaps and pop3s ports + + Separate "imaps" and "pop3s" ports were registered for use with SSL. + Use of these ports is discouraged in favor of the STARTTLS or STLS + commands. + + A number of problems have been observed with separate ports for + "secure" variants of protocols. This is an attempt to enumerate some + of those problems. + + - Separate ports lead to a separate URL scheme which intrudes into + the user interface in inappropriate ways. For example, many web + pages use language like "click here if your browser supports SSL." + This is a decision the browser is often more capable of making than + the user. + + - Separate ports imply a model of either "secure" or "not secure." + This can be misleading in a number of ways. First, the "secure" + port may not in fact be acceptably secure as an export-crippled + cipher suite might be in use. This can mislead users into a false + sense of security. Second, the normal port might in fact be + secured by using a SASL mechanism which includes a security layer. + Thus the separate port distinction makes the complex topic of + security policy even more confusing. One common result of this + confusion is that firewall administrators are often misled into + + + +Newman Standards Track [Page 9] + +RFC 2595 Using TLS with IMAP, POP3 and ACAP June 1999 + + + permitting the "secure" port and blocking the standard port. This + could be a poor choice given the common use of SSL with a 40-bit + key encryption layer and plain-text password authentication is less + secure than strong SASL mechanisms such as GSSAPI with Kerberos 5. + + - Use of separate ports for SSL has caused clients to implement only + two security policies: use SSL or don't use SSL. The desirable + security policy "use TLS when available" would be cumbersome with + the separate port model, but is simple with STARTTLS. + + - Port numbers are a limited resource. While they are not yet in + short supply, it is unwise to set a precedent that could double (or + worse) the speed of their consumption. + + +8. IANA Considerations + + This constitutes registration of the "STARTTLS" and "LOGINDISABLED" + IMAP capabilities as required by section 7.2.1 of RFC 2060 [IMAP]. + + The registration for the POP3 "STLS" capability follows: + + CAPA tag: STLS + Arguments: none + Added commands: STLS + Standard commands affected: May enable USER/PASS as a side-effect. + CAPA command SHOULD be re-issued after successful completion. + Announced states/Valid states: AUTHORIZATION state only. + Specification reference: this memo + + The registration for the ACAP "STARTTLS" capability follows: + + Capability name: STARTTLS + Capability keyword: STARTTLS + Capability arguments: none + Published Specification(s): this memo + Person and email address for further information: + see author's address section below + + The registration for the PLAIN SASL mechanism follows: + + SASL mechanism name: PLAIN + Security Considerations: See section 9 of this memo + Published specification: this memo + Person & email address to contact for further information: + see author's address section below + Intended usage: COMMON + Author/Change controller: see author's address section below + + + +Newman Standards Track [Page 10] + +RFC 2595 Using TLS with IMAP, POP3 and ACAP June 1999 + + +9. Security Considerations + + TLS only provides protection for data sent over a network connection. + Messages transferred over IMAP or POP3 are still available to server + administrators and usually subject to eavesdropping, tampering and + forgery when transmitted through SMTP or NNTP. TLS is no substitute + for an end-to-end message security mechanism using MIME security + multiparts [MIME-SEC]. + + A man-in-the-middle attacker can remove STARTTLS from the capability + list or generate a failure response to the STARTTLS command. In + order to detect such an attack, clients SHOULD warn the user when + session privacy is not active and/or be configurable to refuse to + proceed without an acceptable level of security. + + A man-in-the-middle attacker can always cause a down-negotiation to + the weakest authentication mechanism or cipher suite available. For + this reason, implementations SHOULD be configurable to refuse weak + mechanisms or cipher suites. + + Any protocol interactions prior to the TLS handshake are performed in + the clear and can be modified by a man-in-the-middle attacker. For + this reason, clients MUST discard cached information about server + capabilities advertised prior to the start of the TLS handshake. + + Clients are encouraged to clearly indicate when the level of + encryption active is known to be vulnerable to attack using modern + hardware (such as encryption keys with 56 bits of entropy or less). + + The LOGINDISABLED IMAP capability (discussed in section 3.2) only + reduces the potential for passive attacks, it provides no protection + against active attacks. The responsibility remains with the client + to avoid sending a password over a vulnerable channel. + + The PLAIN mechanism relies on the TLS encryption layer for security. + When used without TLS, it is vulnerable to a common network + eavesdropping attack. Therefore PLAIN MUST NOT be advertised or used + unless a suitable TLS encryption layer is active or backwards + compatibility dictates otherwise. + + When the PLAIN mechanism is used, the server gains the ability to + impersonate the user to all services with the same password + regardless of any encryption provided by TLS or other network privacy + mechanisms. While many other authentication mechanisms have similar + weaknesses, stronger SASL mechanisms such as Kerberos address this + issue. Clients are encouraged to have an operational mode where all + mechanisms which are likely to reveal the user's password to the + server are disabled. + + + +Newman Standards Track [Page 11] + +RFC 2595 Using TLS with IMAP, POP3 and ACAP June 1999 + + + The security considerations for TLS apply to STARTTLS and the + security considerations for SASL apply to the PLAIN mechanism. + Additional security requirements are discussed in section 2. + +10. References + + [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax + Specifications: ABNF", RFC 2234, November 1997. + + [ACAP] Newman, C. and J. Myers, "ACAP -- Application + Configuration Access Protocol", RFC 2244, November 1997. + + [AUTH] Haller, N. and R. Atkinson, "On Internet Authentication", + RFC 1704, October 1994. + + [CRAM-MD5] Klensin, J., Catoe, R. and P. Krumviede, "IMAP/POP + AUTHorize Extension for Simple Challenge/Response", RFC + 2195, September 1997. + + [IMAP] Crispin, M., "Internet Message Access Protocol - Version + 4rev1", RFC 2060, December 1996. + + [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [MIME-SEC] Galvin, J., Murphy, S., Crocker, S. and N. Freed, + "Security Multiparts for MIME: Multipart/Signed and + Multipart/Encrypted", RFC 1847, October 1995. + + [POP3] Myers, J. and M. Rose, "Post Office Protocol - Version 3", + STD 53, RFC 1939, May 1996. + + [POP3EXT] Gellens, R., Newman, C. and L. Lundblade, "POP3 Extension + Mechanism", RFC 2449, November 1998. + + [POP-AUTH] Myers, J., "POP3 AUTHentication command", RFC 1734, + December 1994. + + [SASL] Myers, J., "Simple Authentication and Security Layer + (SASL)", RFC 2222, October 1997. + + [SMTPTLS] Hoffman, P., "SMTP Service Extension for Secure SMTP over + TLS", RFC 2487, January 1999. + + [TLS] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", + RFC 2246, January 1999. + + + + + +Newman Standards Track [Page 12] + +RFC 2595 Using TLS with IMAP, POP3 and ACAP June 1999 + + + [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO + 10646", RFC 2279, January 1998. + + +11. Author's Address + + Chris Newman + Innosoft International, Inc. + 1050 Lakes Drive + West Covina, CA 91790 USA + + EMail: chris.newman@innosoft.com + + +A. Appendix -- Compliance Checklist + + An implementation is not compliant if it fails to satisfy one or more + of the MUST requirements for the protocols it implements. An + implementation that satisfies all the MUST and all the SHOULD + requirements for its protocols is said to be "unconditionally + compliant"; one that satisfies all the MUST requirements but not all + the SHOULD requirements for its protocols is said to be + "conditionally compliant". + + Rules Section + ----- ------- + Mandatory-to-implement Cipher Suite 2.1 + SHOULD have mode where encryption required 2.2 + server SHOULD have mode where TLS not required 2.2 + MUST be configurable to refuse all clear-text login + commands or mechanisms 2.3 + server SHOULD be configurable to refuse clear-text + login commands on entire server and on per-user basis 2.3 + client MUST check server identity 2.4 + client MUST use hostname used to open connection 2.4 + client MUST NOT use hostname from insecure remote lookup 2.4 + client SHOULD support subjectAltName of dNSName type 2.4 + client SHOULD ask for confirmation or terminate on fail 2.4 + MUST check result of STARTTLS for acceptable privacy 2.5 + client MUST NOT issue commands after STARTTLS + until server response and negotiation done 3.1,4,5.1 + client MUST discard cached information 3.1,4,5.1,9 + client SHOULD re-issue CAPABILITY/CAPA command 3.1,4 + IMAP server with STARTTLS MUST implement LOGINDISABLED 3.2 + IMAP client MUST NOT issue LOGIN if LOGINDISABLED 3.2 + POP server MUST implement POP3 extensions 4 + ACAP server MUST re-issue ACAP greeting 5.1 + + + + +Newman Standards Track [Page 13] + +RFC 2595 Using TLS with IMAP, POP3 and ACAP June 1999 + + + client SHOULD warn when session privacy not active and/or + refuse to proceed without acceptable security level 9 + SHOULD be configurable to refuse weak mechanisms or + cipher suites 9 + + The PLAIN mechanism is an optional part of this specification. + However if it is implemented the following rules apply: + + Rules Section + ----- ------- + MUST NOT use PLAIN unless strong encryption active + or backwards compatibility dictates otherwise 6,9 + MUST use UTF-8 encoding for characters in PLAIN 6 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Newman Standards Track [Page 14] + +RFC 2595 Using TLS with IMAP, POP3 and ACAP June 1999 + + +Full Copyright Statement + + Copyright (C) The Internet Society (1999). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Newman Standards Track [Page 15] + diff --git a/RFCs/rfc2821.txt b/RFCs/rfc2821.txt new file mode 100644 index 0000000..0eac911 --- /dev/null +++ b/RFCs/rfc2821.txt @@ -0,0 +1,4427 @@ + + + + + + +Network Working Group J. Klensin, Editor +Request for Comments: 2821 AT&T Laboratories +Obsoletes: 821, 974, 1869 April 2001 +Updates: 1123 +Category: Standards Track + + + Simple Mail Transfer Protocol + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2001). All Rights Reserved. + +Abstract + + This document is a self-contained specification of the basic protocol + for the Internet electronic mail transport. It consolidates, updates + and clarifies, but doesn't add new or change existing functionality + of the following: + + - the original SMTP (Simple Mail Transfer Protocol) specification of + RFC 821 [30], + + - domain name system requirements and implications for mail + transport from RFC 1035 [22] and RFC 974 [27], + + - the clarifications and applicability statements in RFC 1123 [2], + and + + - material drawn from the SMTP Extension mechanisms [19]. + + It obsoletes RFC 821, RFC 974, and updates RFC 1123 (replaces the + mail transport materials of RFC 1123). However, RFC 821 specifies + some features that were not in significant use in the Internet by the + mid-1990s and (in appendices) some additional transport models. + Those sections are omitted here in the interest of clarity and + brevity; readers needing them should refer to RFC 821. + + + + + + +Klensin Standards Track [Page 1] + +RFC 2821 Simple Mail Transfer Protocol April 2001 + + + It also includes some additional material from RFC 1123 that required + amplification. This material has been identified in multiple ways, + mostly by tracking flaming on various lists and newsgroups and + problems of unusual readings or interpretations that have appeared as + the SMTP extensions have been deployed. Where this specification + moves beyond consolidation and actually differs from earlier + documents, it supersedes them technically as well as textually. + + Although SMTP was designed as a mail transport and delivery protocol, + this specification also contains information that is important to its + use as a 'mail submission' protocol, as recommended for POP [3, 26] + and IMAP [6]. Additional submission issues are discussed in RFC 2476 + [15]. + + Section 2.3 provides definitions of terms specific to this document. + Except when the historical terminology is necessary for clarity, this + document uses the current 'client' and 'server' terminology to + identify the sending and receiving SMTP processes, respectively. + + A companion document [32] discusses message headers, message bodies + and formats and structures for them, and their relationship. + +Table of Contents + + 1. Introduction .................................................. 4 + 2. The SMTP Model ................................................ 5 + 2.1 Basic Structure .............................................. 5 + 2.2 The Extension Model .......................................... 7 + 2.2.1 Background ................................................. 7 + 2.2.2 Definition and Registration of Extensions .................. 8 + 2.3 Terminology .................................................. 9 + 2.3.1 Mail Objects ............................................... 10 + 2.3.2 Senders and Receivers ...................................... 10 + 2.3.3 Mail Agents and Message Stores ............................. 10 + 2.3.4 Host ....................................................... 11 + 2.3.5 Domain ..................................................... 11 + 2.3.6 Buffer and State Table ..................................... 11 + 2.3.7 Lines ...................................................... 12 + 2.3.8 Originator, Delivery, Relay, and Gateway Systems ........... 12 + 2.3.9 Message Content and Mail Data .............................. 13 + 2.3.10 Mailbox and Address ....................................... 13 + 2.3.11 Reply ..................................................... 13 + 2.4 General Syntax Principles and Transaction Model .............. 13 + 3. The SMTP Procedures: An Overview .............................. 15 + 3.1 Session Initiation ........................................... 15 + 3.2 Client Initiation ............................................ 16 + 3.3 Mail Transactions ............................................ 16 + 3.4 Forwarding for Address Correction or Updating ................ 19 + + + +Klensin Standards Track [Page 2] + +RFC 2821 Simple Mail Transfer Protocol April 2001 + + + 3.5 Commands for Debugging Addresses ............................. 20 + 3.5.1 Overview ................................................... 20 + 3.5.2 VRFY Normal Response ....................................... 22 + 3.5.3 Meaning of VRFY or EXPN Success Response ................... 22 + 3.5.4 Semantics and Applications of EXPN ......................... 23 + 3.6 Domains ...................................................... 23 + 3.7 Relaying ..................................................... 24 + 3.8 Mail Gatewaying .............................................. 25 + 3.8.1 Header Fields in Gatewaying ................................ 26 + 3.8.2 Received Lines in Gatewaying ............................... 26 + 3.8.3 Addresses in Gatewaying .................................... 26 + 3.8.4 Other Header Fields in Gatewaying .......................... 27 + 3.8.5 Envelopes in Gatewaying .................................... 27 + 3.9 Terminating Sessions and Connections ......................... 27 + 3.10 Mailing Lists and Aliases ................................... 28 + 3.10.1 Alias ..................................................... 28 + 3.10.2 List ...................................................... 28 + 4. The SMTP Specifications ....................................... 29 + 4.1 SMTP Commands ................................................ 29 + 4.1.1 Command Semantics and Syntax ............................... 29 + 4.1.1.1 Extended HELLO (EHLO) or HELLO (HELO) ................... 29 + 4.1.1.2 MAIL (MAIL) .............................................. 31 + 4.1.1.3 RECIPIENT (RCPT) ......................................... 31 + 4.1.1.4 DATA (DATA) .............................................. 33 + 4.1.1.5 RESET (RSET) ............................................. 34 + 4.1.1.6 VERIFY (VRFY) ............................................ 35 + 4.1.1.7 EXPAND (EXPN) ............................................ 35 + 4.1.1.8 HELP (HELP) .............................................. 35 + 4.1.1.9 NOOP (NOOP) .............................................. 35 + 4.1.1.10 QUIT (QUIT) ............................................. 36 + 4.1.2 Command Argument Syntax .................................... 36 + 4.1.3 Address Literals ........................................... 38 + 4.1.4 Order of Commands .......................................... 39 + 4.1.5 Private-use Commands ....................................... 40 + 4.2 SMTP Replies ................................................ 40 + 4.2.1 Reply Code Severities and Theory ........................... 42 + 4.2.2 Reply Codes by Function Groups ............................. 44 + 4.2.3 Reply Codes in Numeric Order .............................. 45 + 4.2.4 Reply Code 502 ............................................. 46 + 4.2.5 Reply Codes After DATA and the Subsequent . .... 46 + 4.3 Sequencing of Commands and Replies ........................... 47 + 4.3.1 Sequencing Overview ........................................ 47 + 4.3.2 Command-Reply Sequences .................................... 48 + 4.4 Trace Information ............................................ 49 + 4.5 Additional Implementation Issues ............................. 53 + 4.5.1 Minimum Implementation ..................................... 53 + 4.5.2 Transparency ............................................... 53 + 4.5.3 Sizes and Timeouts ......................................... 54 + + + +Klensin Standards Track [Page 3] + +RFC 2821 Simple Mail Transfer Protocol April 2001 + + + 4.5.3.1 Size limits and minimums ................................. 54 + 4.5.3.2 Timeouts ................................................. 56 + 4.5.4 Retry Strategies ........................................... 57 + 4.5.4.1 Sending Strategy ......................................... 58 + 4.5.4.2 Receiving Strategy ....................................... 59 + 4.5.5 Messages with a null reverse-path .......................... 59 + 5. Address Resolution and Mail Handling .......................... 60 + 6. Problem Detection and Handling ................................ 62 + 6.1 Reliable Delivery and Replies by Email ....................... 62 + 6.2 Loop Detection ............................................... 63 + 6.3 Compensating for Irregularities .............................. 63 + 7. Security Considerations ....................................... 64 + 7.1 Mail Security and Spoofing ................................... 64 + 7.2 "Blind" Copies ............................................... 65 + 7.3 VRFY, EXPN, and Security ..................................... 65 + 7.4 Information Disclosure in Announcements ...................... 66 + 7.5 Information Disclosure in Trace Fields ....................... 66 + 7.6 Information Disclosure in Message Forwarding ................. 67 + 7.7 Scope of Operation of SMTP Servers ........................... 67 + 8. IANA Considerations ........................................... 67 + 9. References .................................................... 68 + 10. Editor's Address ............................................. 70 + 11. Acknowledgments .............................................. 70 + Appendices ....................................................... 71 + A. TCP Transport Service ......................................... 71 + B. Generating SMTP Commands from RFC 822 Headers ................. 71 + C. Source Routes ................................................. 72 + D. Scenarios ..................................................... 73 + E. Other Gateway Issues .......................................... 76 + F. Deprecated Features of RFC 821 ................................ 76 + Full Copyright Statement ......................................... 79 + +1. Introduction + + The objective of the Simple Mail Transfer Protocol (SMTP) is to + transfer mail reliably and efficiently. + + SMTP is independent of the particular transmission subsystem and + requires only a reliable ordered data stream channel. While this + document specifically discusses transport over TCP, other transports + are possible. Appendices to RFC 821 describe some of them. + + An important feature of SMTP is its capability to transport mail + across networks, usually referred to as "SMTP mail relaying" (see + section 3.8). A network consists of the mutually-TCP-accessible + hosts on the public Internet, the mutually-TCP-accessible hosts on a + firewall-isolated TCP/IP Intranet, or hosts in some other LAN or WAN + environment utilizing a non-TCP transport-level protocol. Using + + + +Klensin Standards Track [Page 4] + +RFC 2821 Simple Mail Transfer Protocol April 2001 + + + SMTP, a process can transfer mail to another process on the same + network or to some other network via a relay or gateway process + accessible to both networks. + + In this way, a mail message may pass through a number of intermediate + relay or gateway hosts on its path from sender to ultimate recipient. + The Mail eXchanger mechanisms of the domain name system [22, 27] (and + section 5 of this document) are used to identify the appropriate + next-hop destination for a message being transported. + +2. The SMTP Model + +2.1 Basic Structure + + The SMTP design can be pictured as: + + +----------+ +----------+ + +------+ | | | | + | User |<-->| | SMTP | | + +------+ | Client- |Commands/Replies| Server- | + +------+ | SMTP |<-------------->| SMTP | +------+ + | File |<-->| | and Mail | |<-->| File | + |System| | | | | |System| + +------+ +----------+ +----------+ +------+ + SMTP client SMTP server + + When an SMTP client has a message to transmit, it establishes a two- + way transmission channel to an SMTP server. The responsibility of an + SMTP client is to transfer mail messages to one or more SMTP servers, + or report its failure to do so. + + The means by which a mail message is presented to an SMTP client, and + how that client determines the domain name(s) to which mail messages + are to be transferred is a local matter, and is not addressed by this + document. In some cases, the domain name(s) transferred to, or + determined by, an SMTP client will identify the final destination(s) + of the mail message. In other cases, common with SMTP clients + associated with implementations of the POP [3, 26] or IMAP [6] + protocols, or when the SMTP client is inside an isolated transport + service environment, the domain name determined will identify an + intermediate destination through which all mail messages are to be + relayed. SMTP clients that transfer all traffic, regardless of the + target domain names associated with the individual messages, or that + do not maintain queues for retrying message transmissions that + initially cannot be completed, may otherwise conform to this + specification but are not considered fully-capable. Fully-capable + SMTP implementations, including the relays used by these less capable + + + + +Klensin Standards Track [Page 5] + +RFC 2821 Simple Mail Transfer Protocol April 2001 + + + ones, and their destinations, are expected to support all of the + queuing, retrying, and alternate address functions discussed in this + specification. + + The means by which an SMTP client, once it has determined a target + domain name, determines the identity of an SMTP server to which a + copy of a message is to be transferred, and then performs that + transfer, is covered by this document. To effect a mail transfer to + an SMTP server, an SMTP client establishes a two-way transmission + channel to that SMTP server. An SMTP client determines the address + of an appropriate host running an SMTP server by resolving a + destination domain name to either an intermediate Mail eXchanger host + or a final target host. + + An SMTP server may be either the ultimate destination or an + intermediate "relay" (that is, it may assume the role of an SMTP + client after receiving the message) or "gateway" (that is, it may + transport the message further using some protocol other than SMTP). + SMTP commands are generated by the SMTP client and sent to the SMTP + server. SMTP replies are sent from the SMTP server to the SMTP + client in response to the commands. + + In other words, message transfer can occur in a single connection + between the original SMTP-sender and the final SMTP-recipient, or can + occur in a series of hops through intermediary systems. In either + case, a formal handoff of responsibility for the message occurs: the + protocol requires that a server accept responsibility for either + delivering a message or properly reporting the failure to do so. + + Once the transmission channel is established and initial handshaking + completed, the SMTP client normally initiates a mail transaction. + Such a transaction consists of a series of commands to specify the + originator and destination of the mail and transmission of the + message content (including any headers or other structure) itself. + When the same message is sent to multiple recipients, this protocol + encourages the transmission of only one copy of the data for all + recipients at the same destination (or intermediate relay) host. + + The server responds to each command with a reply; replies may + indicate that the command was accepted, that additional commands are + expected, or that a temporary or permanent error condition exists. + Commands specifying the sender or recipients may include server- + permitted SMTP service extension requests as discussed in section + 2.2. The dialog is purposely lock-step, one-at-a-time, although this + can be modified by mutually-agreed extension requests such as command + pipelining [13]. + + + + + +Klensin Standards Track [Page 6] + +RFC 2821 Simple Mail Transfer Protocol April 2001 + + + Once a given mail message has been transmitted, the client may either + request that the connection be shut down or may initiate other mail + transactions. In addition, an SMTP client may use a connection to an + SMTP server for ancillary services such as verification of email + addresses or retrieval of mailing list subscriber addresses. + + As suggested above, this protocol provides mechanisms for the + transmission of mail. This transmission normally occurs directly + from the sending user's host to the receiving user's host when the + two hosts are connected to the same transport service. When they are + not connected to the same transport service, transmission occurs via + one or more relay SMTP servers. An intermediate host that acts as + either an SMTP relay or as a gateway into some other transmission + environment is usually selected through the use of the domain name + service (DNS) Mail eXchanger mechanism. + + Usually, intermediate hosts are determined via the DNS MX record, not + by explicit "source" routing (see section 5 and appendices C and + F.2). + +2.2 The Extension Model + +2.2.1 Background + + In an effort that started in 1990, approximately a decade after RFC + 821 was completed, the protocol was modified with a "service + extensions" model that permits the client and server to agree to + utilize shared functionality beyond the original SMTP requirements. + The SMTP extension mechanism defines a means whereby an extended SMTP + client and server may recognize each other, and the server can inform + the client as to the service extensions that it supports. + + Contemporary SMTP implementations MUST support the basic extension + mechanisms. For instance, servers MUST support the EHLO command even + if they do not implement any specific extensions and clients SHOULD + preferentially utilize EHLO rather than HELO. (However, for + compatibility with older conforming implementations, SMTP clients and + servers MUST support the original HELO mechanisms as a fallback.) + Unless the different characteristics of HELO must be identified for + interoperability purposes, this document discusses only EHLO. + + SMTP is widely deployed and high-quality implementations have proven + to be very robust. However, the Internet community now considers + some services to be important that were not anticipated when the + protocol was first designed. If support for those services is to be + added, it must be done in a way that permits older implementations to + continue working acceptably. The extension framework consists of: + + + + +Klensin Standards Track [Page 7] + +RFC 2821 Simple Mail Transfer Protocol April 2001 + + + - The SMTP command EHLO, superseding the earlier HELO, + + - a registry of SMTP service extensions, + + - additional parameters to the SMTP MAIL and RCPT commands, and + + - optional replacements for commands defined in this protocol, such + as for DATA in non-ASCII transmissions [33]. + + SMTP's strength comes primarily from its simplicity. Experience with + many protocols has shown that protocols with few options tend towards + ubiquity, whereas protocols with many options tend towards obscurity. + + Each and every extension, regardless of its benefits, must be + carefully scrutinized with respect to its implementation, deployment, + and interoperability costs. In many cases, the cost of extending the + SMTP service will likely outweigh the benefit. + +2.2.2 Definition and Registration of Extensions + + The IANA maintains a registry of SMTP service extensions. A + corresponding EHLO keyword value is associated with each extension. + Each service extension registered with the IANA must be defined in a + formal standards-track or IESG-approved experimental protocol + document. The definition must include: + + - the textual name of the SMTP service extension; + + - the EHLO keyword value associated with the extension; + + - the syntax and possible values of parameters associated with the + EHLO keyword value; + + - any additional SMTP verbs associated with the extension + (additional verbs will usually be, but are not required to be, the + same as the EHLO keyword value); + + - any new parameters the extension associates with the MAIL or RCPT + verbs; + + - a description of how support for the extension affects the + behavior of a server and client SMTP; and, + + - the increment by which the extension is increasing the maximum + length of the commands MAIL and/or RCPT, over that specified in + this standard. + + + + + +Klensin Standards Track [Page 8] + +RFC 2821 Simple Mail Transfer Protocol April 2001 + + + In addition, any EHLO keyword value starting with an upper or lower + case "X" refers to a local SMTP service extension used exclusively + through bilateral agreement. Keywords beginning with "X" MUST NOT be + used in a registered service extension. Conversely, keyword values + presented in the EHLO response that do not begin with "X" MUST + correspond to a standard, standards-track, or IESG-approved + experimental SMTP service extension registered with IANA. A + conforming server MUST NOT offer non-"X"-prefixed keyword values that + are not described in a registered extension. + + Additional verbs and parameter names are bound by the same rules as + EHLO keywords; specifically, verbs beginning with "X" are local + extensions that may not be registered or standardized. Conversely, + verbs not beginning with "X" must always be registered. + +2.3 Terminology + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described below. + + 1. MUST This word, or the terms "REQUIRED" or "SHALL", mean that + the definition is an absolute requirement of the specification. + + 2. MUST NOT This phrase, or the phrase "SHALL NOT", mean that the + definition is an absolute prohibition of the specification. + + 3. SHOULD This word, or the adjective "RECOMMENDED", mean that + there may exist valid reasons in particular circumstances to + ignore a particular item, but the full implications must be + understood and carefully weighed before choosing a different + course. + + 4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean + that there may exist valid reasons in particular circumstances + when the particular behavior is acceptable or even useful, but the + full implications should be understood and the case carefully + weighed before implementing any behavior described with this + label. + + 5. MAY This word, or the adjective "OPTIONAL", mean that an item is + truly optional. One vendor may choose to include the item because + a particular marketplace requires it or because the vendor feels + that it enhances the product while another vendor may omit the + same item. An implementation which does not include a particular + option MUST be prepared to interoperate with another + implementation which does include the option, though perhaps with + reduced functionality. In the same vein an implementation which + + + +Klensin Standards Track [Page 9] + +RFC 2821 Simple Mail Transfer Protocol April 2001 + + + does include a particular option MUST be prepared to interoperate + with another implementation which does not include the option + (except, of course, for the feature the option provides.) + +2.3.1 Mail Objects + + SMTP transports a mail object. A mail object contains an envelope + and content. + + The SMTP envelope is sent as a series of SMTP protocol units + (described in section 3). It consists of an originator address (to + which error reports should be directed); one or more recipient + addresses; and optional protocol extension material. Historically, + variations on the recipient address specification command (RCPT TO) + could be used to specify alternate delivery modes, such as immediate + display; those variations have now been deprecated (see appendix F, + section F.6). + + The SMTP content is sent in the SMTP DATA protocol unit and has two + parts: the headers and the body. If the content conforms to other + contemporary standards, the headers form a collection of field/value + pairs structured as in the message format specification [32]; the + body, if structured, is defined according to MIME [12]. The content + is textual in nature, expressed using the US-ASCII repertoire [1]. + Although SMTP extensions (such as "8BITMIME" [20]) may relax this + restriction for the content body, the content headers are always + encoded using the US-ASCII repertoire. A MIME extension [23] defines + an algorithm for representing header values outside the US-ASCII + repertoire, while still encoding them using the US-ASCII repertoire. + +2.3.2 Senders and Receivers + + In RFC 821, the two hosts participating in an SMTP transaction were + described as the "SMTP-sender" and "SMTP-receiver". This document + has been changed to reflect current industry terminology and hence + refers to them as the "SMTP client" (or sometimes just "the client") + and "SMTP server" (or just "the server"), respectively. Since a + given host may act both as server and client in a relay situation, + "receiver" and "sender" terminology is still used where needed for + clarity. + +2.3.3 Mail Agents and Message Stores + + Additional mail system terminology became common after RFC 821 was + published and, where convenient, is used in this specification. In + particular, SMTP servers and clients provide a mail transport service + and therefore act as "Mail Transfer Agents" (MTAs). "Mail User + Agents" (MUAs or UAs) are normally thought of as the sources and + + + +Klensin Standards Track [Page 10] + +RFC 2821 Simple Mail Transfer Protocol April 2001 + + + targets of mail. At the source, an MUA might collect mail to be + transmitted from a user and hand it off to an MTA; the final + ("delivery") MTA would be thought of as handing the mail off to an + MUA (or at least transferring responsibility to it, e.g., by + depositing the message in a "message store"). However, while these + terms are used with at least the appearance of great precision in + other environments, the implied boundaries between MUAs and MTAs + often do not accurately match common, and conforming, practices with + Internet mail. Hence, the reader should be cautious about inferring + the strong relationships and responsibilities that might be implied + if these terms were used elsewhere. + +2.3.4 Host + + For the purposes of this specification, a host is a computer system + attached to the Internet (or, in some cases, to a private TCP/IP + network) and supporting the SMTP protocol. Hosts are known by names + (see "domain"); identifying them by numerical address is discouraged. + +2.3.5 Domain + + A domain (or domain name) consists of one or more dot-separated + components. These components ("labels" in DNS terminology [22]) are + restricted for SMTP purposes to consist of a sequence of letters, + digits, and hyphens drawn from the ASCII character set [1]. Domain + names are used as names of hosts and of other entities in the domain + name hierarchy. For example, a domain may refer to an alias (label + of a CNAME RR) or the label of Mail eXchanger records to be used to + deliver mail instead of representing a host name. See [22] and + section 5 of this specification. + + The domain name, as described in this document and in [22], is the + entire, fully-qualified name (often referred to as an "FQDN"). A + domain name that is not in FQDN form is no more than a local alias. + Local aliases MUST NOT appear in any SMTP transaction. + +2.3.6 Buffer and State Table + + SMTP sessions are stateful, with both parties carefully maintaining a + common view of the current state. In this document we model this + state by a virtual "buffer" and a "state table" on the server which + may be used by the client to, for example, "clear the buffer" or + "reset the state table," causing the information in the buffer to be + discarded and the state to be returned to some previous state. + + + + + + + +Klensin Standards Track [Page 11] + +RFC 2821 Simple Mail Transfer Protocol April 2001 + + +2.3.7 Lines + + SMTP commands and, unless altered by a service extension, message + data, are transmitted in "lines". Lines consist of zero or more data + characters terminated by the sequence ASCII character "CR" (hex value + 0D) followed immediately by ASCII character "LF" (hex value 0A). + This termination sequence is denoted as in this document. + Conforming implementations MUST NOT recognize or generate any other + character or character sequence as a line terminator. Limits MAY be + imposed on line lengths by servers (see section 4.5.3). + + In addition, the appearance of "bare" "CR" or "LF" characters in text + (i.e., either without the other) has a long history of causing + problems in mail implementations and applications that use the mail + system as a tool. SMTP client implementations MUST NOT transmit + these characters except when they are intended as line terminators + and then MUST, as indicated above, transmit them only as a + sequence. + +2.3.8 Originator, Delivery, Relay, and Gateway Systems + + This specification makes a distinction among four types of SMTP + systems, based on the role those systems play in transmitting + electronic mail. An "originating" system (sometimes called an SMTP + originator) introduces mail into the Internet or, more generally, + into a transport service environment. A "delivery" SMTP system is + one that receives mail from a transport service environment and + passes it to a mail user agent or deposits it in a message store + which a mail user agent is expected to subsequently access. A + "relay" SMTP system (usually referred to just as a "relay") receives + mail from an SMTP client and transmits it, without modification to + the message data other than adding trace information, to another SMTP + server for further relaying or for delivery. + + A "gateway" SMTP system (usually referred to just as a "gateway") + receives mail from a client system in one transport environment and + transmits it to a server system in another transport environment. + Differences in protocols or message semantics between the transport + environments on either side of a gateway may require that the gateway + system perform transformations to the message that are not permitted + to SMTP relay systems. For the purposes of this specification, + firewalls that rewrite addresses should be considered as gateways, + even if SMTP is used on both sides of them (see [11]). + + + + + + + + +Klensin Standards Track [Page 12] + +RFC 2821 Simple Mail Transfer Protocol April 2001 + + +2.3.9 Message Content and Mail Data + + The terms "message content" and "mail data" are used interchangeably + in this document to describe the material transmitted after the DATA + command is accepted and before the end of data indication is + transmitted. Message content includes message headers and the + possibly-structured message body. The MIME specification [12] + provides the standard mechanisms for structured message bodies. + +2.3.10 Mailbox and Address + + As used in this specification, an "address" is a character string + that identifies a user to whom mail will be sent or a location into + which mail will be deposited. The term "mailbox" refers to that + depository. The two terms are typically used interchangeably unless + the distinction between the location in which mail is placed (the + mailbox) and a reference to it (the address) is important. An + address normally consists of user and domain specifications. The + standard mailbox naming convention is defined to be "local- + part@domain": contemporary usage permits a much broader set of + applications than simple "user names". Consequently, and due to a + long history of problems when intermediate hosts have attempted to + optimize transport by modifying them, the local-part MUST be + interpreted and assigned semantics only by the host specified in the + domain part of the address. + +2.3.11 Reply + + An SMTP reply is an acknowledgment (positive or negative) sent from + receiver to sender via the transmission channel in response to a + command. The general form of a reply is a numeric completion code + (indicating failure or success) usually followed by a text string. + The codes are for use by programs and the text is usually intended + for human users. Recent work [34] has specified further structuring + of the reply strings, including the use of supplemental and more + specific completion codes. + +2.4 General Syntax Principles and Transaction Model + + SMTP commands and replies have a rigid syntax. All commands begin + with a command verb. All Replies begin with a three digit numeric + code. In some commands and replies, arguments MUST follow the verb + or reply code. Some commands do not accept arguments (after the + verb), and some reply codes are followed, sometimes optionally, by + free form text. In both cases, where text appears, it is separated + from the verb or reply code by a space character. Complete + definitions of commands and replies appear in section 4. + + + + +Klensin Standards Track [Page 13] + +RFC 2821 Simple Mail Transfer Protocol April 2001 + + + Verbs and argument values (e.g., "TO:" or "to:" in the RCPT command + and extension name keywords) are not case sensitive, with the sole + exception in this specification of a mailbox local-part (SMTP + Extensions may explicitly specify case-sensitive elements). That is, + a command verb, an argument value other than a mailbox local-part, + and free form text MAY be encoded in upper case, lower case, or any + mixture of upper and lower case with no impact on its meaning. This + is NOT true of a mailbox local-part. The local-part of a mailbox + MUST BE treated as case sensitive. Therefore, SMTP implementations + MUST take care to preserve the case of mailbox local-parts. Mailbox + domains are not case sensitive. In particular, for some hosts the + user "smith" is different from the user "Smith". However, exploiting + the case sensitivity of mailbox local-parts impedes interoperability + and is discouraged. + + A few SMTP servers, in violation of this specification (and RFC 821) + require that command verbs be encoded by clients in upper case. + Implementations MAY wish to employ this encoding to accommodate those + servers. + + The argument field consists of a variable length character string + ending with the end of the line, i.e., with the character sequence + . The receiver will take no action until this sequence is + received. + + The syntax for each command is shown with the discussion of that + command. Common elements and parameters are shown in section 4.1.2. + + Commands and replies are composed of characters from the ASCII + character set [1]. When the transport service provides an 8-bit byte + (octet) transmission channel, each 7-bit character is transmitted + right justified in an octet with the high order bit cleared to zero. + More specifically, the unextended SMTP service provides seven bit + transport only. An originating SMTP client which has not + successfully negotiated an appropriate extension with a particular + server MUST NOT transmit messages with information in the high-order + bit of octets. If such messages are transmitted in violation of this + rule, receiving SMTP servers MAY clear the high-order bit or reject + the message as invalid. In general, a relay SMTP SHOULD assume that + the message content it has received is valid and, assuming that the + envelope permits doing so, relay it without inspecting that content. + Of course, if the content is mislabeled and the data path cannot + accept the actual content, this may result in ultimate delivery of a + severely garbled message to the recipient. Delivery SMTP systems MAY + reject ("bounce") such messages rather than deliver them. No sending + SMTP system is permitted to send envelope commands in any character + + + + + +Klensin Standards Track [Page 14] + +RFC 2821 Simple Mail Transfer Protocol April 2001 + + + set other than US-ASCII; receiving systems SHOULD reject such + commands, normally using "500 syntax error - invalid character" + replies. + + Eight-bit message content transmission MAY be requested of the server + by a client using extended SMTP facilities, notably the "8BITMIME" + extension [20]. 8BITMIME SHOULD be supported by SMTP servers. + However, it MUST not be construed as authorization to transmit + unrestricted eight bit material. 8BITMIME MUST NOT be requested by + senders for material with the high bit on that is not in MIME format + with an appropriate content-transfer encoding; servers MAY reject + such messages. + + The metalinguistic notation used in this document corresponds to the + "Augmented BNF" used in other Internet mail system documents. The + reader who is not familiar with that syntax should consult the ABNF + specification [8]. Metalanguage terms used in running text are + surrounded by pointed brackets (e.g., ) for clarity. + +3. The SMTP Procedures: An Overview + + This section contains descriptions of the procedures used in SMTP: + session initiation, the mail transaction, forwarding mail, verifying + mailbox names and expanding mailing lists, and the opening and + closing exchanges. Comments on relaying, a note on mail domains, and + a discussion of changing roles are included at the end of this + section. Several complete scenarios are presented in appendix D. + +3.1 Session Initiation + + An SMTP session is initiated when a client opens a connection to a + server and the server responds with an opening message. + + SMTP server implementations MAY include identification of their + software and version information in the connection greeting reply + after the 220 code, a practice that permits more efficient isolation + and repair of any problems. Implementations MAY make provision for + SMTP servers to disable the software and version announcement where + it causes security concerns. While some systems also identify their + contact point for mail problems, this is not a substitute for + maintaining the required "postmaster" address (see section 4.5.1). + + The SMTP protocol allows a server to formally reject a transaction + while still allowing the initial connection as follows: a 554 + response MAY be given in the initial connection opening message + instead of the 220. A server taking this approach MUST still wait + for the client to send a QUIT (see section 4.1.1.10) before closing + the connection and SHOULD respond to any intervening commands with + + + +Klensin Standards Track [Page 15] + +RFC 2821 Simple Mail Transfer Protocol April 2001 + + + "503 bad sequence of commands". Since an attempt to make an SMTP + connection to such a system is probably in error, a server returning + a 554 response on connection opening SHOULD provide enough + information in the reply text to facilitate debugging of the sending + system. + +3.2 Client Initiation + + Once the server has sent the welcoming message and the client has + received it, the client normally sends the EHLO command to the + server, indicating the client's identity. In addition to opening the + session, use of EHLO indicates that the client is able to process + service extensions and requests that the server provide a list of the + extensions it supports. Older SMTP systems which are unable to + support service extensions and contemporary clients which do not + require service extensions in the mail session being initiated, MAY + use HELO instead of EHLO. Servers MUST NOT return the extended + EHLO-style response to a HELO command. For a particular connection + attempt, if the server returns a "command not recognized" response to + EHLO, the client SHOULD be able to fall back and send HELO. + + In the EHLO command the host sending the command identifies itself; + the command may be interpreted as saying "Hello, I am " (and, + in the case of EHLO, "and I support service extension requests"). + +3.3 Mail Transactions + + There are three steps to SMTP mail transactions. The transaction + starts with a MAIL command which gives the sender identification. + (In general, the MAIL command may be sent only when no mail + transaction is in progress; see section 4.1.4.) A series of one or + more RCPT commands follows giving the receiver information. Then a + DATA command initiates transfer of the mail data and is terminated by + the "end of mail" data indicator, which also confirms the + transaction. + + The first step in the procedure is the MAIL command. + + MAIL FROM: [SP ] + + This command tells the SMTP-receiver that a new mail transaction is + starting and to reset all its state tables and buffers, including any + recipients or mail data. The portion of the first or + only argument contains the source mailbox (between "<" and ">" + brackets), which can be used to report errors (see section 4.2 for a + discussion of error reporting). If accepted, the SMTP server returns + a 250 OK reply. If the mailbox specification is not acceptable for + some reason, the server MUST return a reply indicating whether the + + + +Klensin Standards Track [Page 16] + +RFC 2821 Simple Mail Transfer Protocol April 2001 + + + failure is permanent (i.e., will occur again if the client tries to + send the same address again) or temporary (i.e., the address might be + accepted if the client tries again later). Despite the apparent + scope of this requirement, there are circumstances in which the + acceptability of the reverse-path may not be determined until one or + more forward-paths (in RCPT commands) can be examined. In those + cases, the server MAY reasonably accept the reverse-path (with a 250 + reply) and then report problems after the forward-paths are received + and examined. Normally, failures produce 550 or 553 replies. + + Historically, the can contain more than just a + mailbox, however, contemporary systems SHOULD NOT use source routing + (see appendix C). + + The optional are associated with negotiated SMTP + service extensions (see section 2.2). + + The second step in the procedure is the RCPT command. + + RCPT TO: [ SP ] + + The first or only argument to this command includes a forward-path + (normally a mailbox and domain, always surrounded by "<" and ">" + brackets) identifying one recipient. If accepted, the SMTP server + returns a 250 OK reply and stores the forward-path. If the recipient + is known not to be a deliverable address, the SMTP server returns a + 550 reply, typically with a string such as "no such user - " and the + mailbox name (other circumstances and reply codes are possible). + This step of the procedure can be repeated any number of times. + + The can contain more than just a mailbox. + Historically, the can be a source routing list of + hosts and the destination mailbox, however, contemporary SMTP clients + SHOULD NOT utilize source routes (see appendix C). Servers MUST be + prepared to encounter a list of source routes in the forward path, + but SHOULD ignore the routes or MAY decline to support the relaying + they imply. Similarly, servers MAY decline to accept mail that is + destined for other hosts or systems. These restrictions make a + server useless as a relay for clients that do not support full SMTP + functionality. Consequently, restricted-capability clients MUST NOT + assume that any SMTP server on the Internet can be used as their mail + processing (relaying) site. If a RCPT command appears without a + previous MAIL command, the server MUST return a 503 "Bad sequence of + commands" response. The optional are associated + with negotiated SMTP service extensions (see section 2.2). + + The third step in the procedure is the DATA command (or some + alternative specified in a service extension). + + + +Klensin Standards Track [Page 17] + +RFC 2821 Simple Mail Transfer Protocol April 2001 + + + DATA + + If accepted, the SMTP server returns a 354 Intermediate reply and + considers all succeeding lines up to but not including the end of + mail data indicator to be the message text. When the end of text is + successfully received and stored the SMTP-receiver sends a 250 OK + reply. + + Since the mail data is sent on the transmission channel, the end of + mail data must be indicated so that the command and reply dialog can + be resumed. SMTP indicates the end of the mail data by sending a + line containing only a "." (period or full stop). A transparency + procedure is used to prevent this from interfering with the user's + text (see section 4.5.2). + + The end of mail data indicator also confirms the mail transaction and + tells the SMTP server to now process the stored recipients and mail + data. If accepted, the SMTP server returns a 250 OK reply. The DATA + command can fail at only two points in the protocol exchange: + + - If there was no MAIL, or no RCPT, command, or all such commands + were rejected, the server MAY return a "command out of sequence" + (503) or "no valid recipients" (554) reply in response to the DATA + command. If one of those replies (or any other 5yz reply) is + received, the client MUST NOT send the message data; more + generally, message data MUST NOT be sent unless a 354 reply is + received. + + - If the verb is initially accepted and the 354 reply issued, the + DATA command should fail only if the mail transaction was + incomplete (for example, no recipients), or if resources were + unavailable (including, of course, the server unexpectedly + becoming unavailable), or if the server determines that the + message should be rejected for policy or other reasons. + + However, in practice, some servers do not perform recipient + verification until after the message text is received. These servers + SHOULD treat a failure for one or more recipients as a "subsequent + failure" and return a mail message as discussed in section 6. Using + a "550 mailbox not found" (or equivalent) reply code after the data + are accepted makes it difficult or impossible for the client to + determine which recipients failed. + + When RFC 822 format [7, 32] is being used, the mail data include the + memo header items such as Date, Subject, To, Cc, From. Server SMTP + systems SHOULD NOT reject messages based on perceived defects in the + RFC 822 or MIME [12] message header or message body. In particular, + + + + +Klensin Standards Track [Page 18] + +RFC 2821 Simple Mail Transfer Protocol April 2001 + + + they MUST NOT reject messages in which the numbers of Resent-fields + do not match or Resent-to appears without Resent-from and/or Resent- + date. + + Mail transaction commands MUST be used in the order discussed above. + +3.4 Forwarding for Address Correction or Updating + + Forwarding support is most often required to consolidate and simplify + addresses within, or relative to, some enterprise and less frequently + to establish addresses to link a person's prior address with current + one. Silent forwarding of messages (without server notification to + the sender), for security or non-disclosure purposes, is common in + the contemporary Internet. + + In both the enterprise and the "new address" cases, information + hiding (and sometimes security) considerations argue against exposure + of the "final" address through the SMTP protocol as a side-effect of + the forwarding activity. This may be especially important when the + final address may not even be reachable by the sender. Consequently, + the "forwarding" mechanisms described in section 3.2 of RFC 821, and + especially the 251 (corrected destination) and 551 reply codes from + RCPT must be evaluated carefully by implementers and, when they are + available, by those configuring systems. + + In particular: + + * Servers MAY forward messages when they are aware of an address + change. When they do so, they MAY either provide address-updating + information with a 251 code, or may forward "silently" and return + a 250 code. But, if a 251 code is used, they MUST NOT assume that + the client will actually update address information or even return + that information to the user. + + Alternately, + + * Servers MAY reject or bounce messages when they are not + deliverable when addressed. When they do so, they MAY either + provide address-updating information with a 551 code, or may + reject the message as undeliverable with a 550 code and no + address-specific information. But, if a 551 code is used, they + MUST NOT assume that the client will actually update address + information or even return that information to the user. + + SMTP server implementations that support the 251 and/or 551 reply + codes are strongly encouraged to provide configuration mechanisms so + that sites which conclude that they would undesirably disclose + information can disable or restrict their use. + + + +Klensin Standards Track [Page 19] + +RFC 2821 Simple Mail Transfer Protocol April 2001 + + +3.5 Commands for Debugging Addresses + +3.5.1 Overview + + SMTP provides commands to verify a user name or obtain the content of + a mailing list. This is done with the VRFY and EXPN commands, which + have character string arguments. Implementations SHOULD support VRFY + and EXPN (however, see section 3.5.2 and 7.3). + + For the VRFY command, the string is a user name or a user name and + domain (see below). If a normal (i.e., 250) response is returned, + the response MAY include the full name of the user and MUST include + the mailbox of the user. It MUST be in either of the following + forms: + + User Name + local-part@domain + + When a name that is the argument to VRFY could identify more than one + mailbox, the server MAY either note the ambiguity or identify the + alternatives. In other words, any of the following are legitimate + response to VRFY: + + 553 User ambiguous + + or + + 553- Ambiguous; Possibilities are + 553-Joe Smith + 553-Harry Smith + 553 Melvin Smith + + or + + 553-Ambiguous; Possibilities + 553- + 553- + 553 + + Under normal circumstances, a client receiving a 553 reply would be + expected to expose the result to the user. Use of exactly the forms + given, and the "user ambiguous" or "ambiguous" keywords, possibly + supplemented by extended reply codes such as those described in [34], + will facilitate automated translation into other languages as needed. + Of course, a client that was highly automated or that was operating + in another language than English, might choose to try to translate + the response, to return some other indication to the user than the + + + + +Klensin Standards Track [Page 20] + +RFC 2821 Simple Mail Transfer Protocol April 2001 + + + literal text of the reply, or to take some automated action such as + consulting a directory service for additional information before + reporting to the user. + + For the EXPN command, the string identifies a mailing list, and the + successful (i.e., 250) multiline response MAY include the full name + of the users and MUST give the mailboxes on the mailing list. + + In some hosts the distinction between a mailing list and an alias for + a single mailbox is a bit fuzzy, since a common data structure may + hold both types of entries, and it is possible to have mailing lists + containing only one mailbox. If a request is made to apply VRFY to a + mailing list, a positive response MAY be given if a message so + addressed would be delivered to everyone on the list, otherwise an + error SHOULD be reported (e.g., "550 That is a mailing list, not a + user" or "252 Unable to verify members of mailing list"). If a + request is made to expand a user name, the server MAY return a + positive response consisting of a list containing one name, or an + error MAY be reported (e.g., "550 That is a user name, not a mailing + list"). + + In the case of a successful multiline reply (normal for EXPN) exactly + one mailbox is to be specified on each line of the reply. The case + of an ambiguous request is discussed above. + + "User name" is a fuzzy term and has been used deliberately. An + implementation of the VRFY or EXPN commands MUST include at least + recognition of local mailboxes as "user names". However, since + current Internet practice often results in a single host handling + mail for multiple domains, hosts, especially hosts that provide this + functionality, SHOULD accept the "local-part@domain" form as a "user + name"; hosts MAY also choose to recognize other strings as "user + names". + + The case of expanding a mailbox list requires a multiline reply, such + as: + + C: EXPN Example-People + S: 250-Jon Postel + S: 250-Fred Fonebone + S: 250 Sam Q. Smith + + or + + C: EXPN Executive-Washroom-List + S: 550 Access Denied to You. + + + + + +Klensin Standards Track [Page 21] + +RFC 2821 Simple Mail Transfer Protocol April 2001 + + + The character string arguments of the VRFY and EXPN commands cannot + be further restricted due to the variety of implementations of the + user name and mailbox list concepts. On some systems it may be + appropriate for the argument of the EXPN command to be a file name + for a file containing a mailing list, but again there are a variety + of file naming conventions in the Internet. Similarly, historical + variations in what is returned by these commands are such that the + response SHOULD be interpreted very carefully, if at all, and SHOULD + generally only be used for diagnostic purposes. + +3.5.2 VRFY Normal Response + + When normal (2yz or 551) responses are returned from a VRFY or EXPN + request, the reply normally includes the mailbox name, i.e., + "", where "domain" is a fully qualified domain + name, MUST appear in the syntax. In circumstances exceptional enough + to justify violating the intent of this specification, free-form text + MAY be returned. In order to facilitate parsing by both computers + and people, addresses SHOULD appear in pointed brackets. When + addresses, rather than free-form debugging information, are returned, + EXPN and VRFY MUST return only valid domain addresses that are usable + in SMTP RCPT commands. Consequently, if an address implies delivery + to a program or other system, the mailbox name used to reach that + target MUST be given. Paths (explicit source routes) MUST NOT be + returned by VRFY or EXPN. + + Server implementations SHOULD support both VRFY and EXPN. For + security reasons, implementations MAY provide local installations a + way to disable either or both of these commands through configuration + options or the equivalent. When these commands are supported, they + are not required to work across relays when relaying is supported. + Since they were both optional in RFC 821, they MUST be listed as + service extensions in an EHLO response, if they are supported. + +3.5.3 Meaning of VRFY or EXPN Success Response + + A server MUST NOT return a 250 code in response to a VRFY or EXPN + command unless it has actually verified the address. In particular, + a server MUST NOT return 250 if all it has done is to verify that the + syntax given is valid. In that case, 502 (Command not implemented) + or 500 (Syntax error, command unrecognized) SHOULD be returned. As + stated elsewhere, implementation (in the sense of actually validating + addresses and returning information) of VRFY and EXPN are strongly + recommended. Hence, implementations that return 500 or 502 for VRFY + are not in full compliance with this specification. + + + + + + +Klensin Standards Track [Page 22] + +RFC 2821 Simple Mail Transfer Protocol April 2001 + + + There may be circumstances where an address appears to be valid but + cannot reasonably be verified in real time, particularly when a + server is acting as a mail exchanger for another server or domain. + "Apparent validity" in this case would normally involve at least + syntax checking and might involve verification that any domains + specified were ones to which the host expected to be able to relay + mail. In these situations, reply code 252 SHOULD be returned. These + cases parallel the discussion of RCPT verification discussed in + section 2.1. Similarly, the discussion in section 3.4 applies to the + use of reply codes 251 and 551 with VRFY (and EXPN) to indicate + addresses that are recognized but that would be forwarded or bounced + were mail received for them. Implementations generally SHOULD be + more aggressive about address verification in the case of VRFY than + in the case of RCPT, even if it takes a little longer to do so. + +3.5.4 Semantics and Applications of EXPN + + EXPN is often very useful in debugging and understanding problems + with mailing lists and multiple-target-address aliases. Some systems + have attempted to use source expansion of mailing lists as a means of + eliminating duplicates. The propagation of aliasing systems with + mail on the Internet, for hosts (typically with MX and CNAME DNS + records), for mailboxes (various types of local host aliases), and in + various proxying arrangements, has made it nearly impossible for + these strategies to work consistently, and mail systems SHOULD NOT + attempt them. + +3.6 Domains + + Only resolvable, fully-qualified, domain names (FQDNs) are permitted + when domain names are used in SMTP. In other words, names that can + be resolved to MX RRs or A RRs (as discussed in section 5) are + permitted, as are CNAME RRs whose targets can be resolved, in turn, + to MX or A RRs. Local nicknames or unqualified names MUST NOT be + used. There are two exceptions to the rule requiring FQDNs: + + - The domain name given in the EHLO command MUST BE either a primary + host name (a domain name that resolves to an A RR) or, if the host + has no name, an address literal as described in section 4.1.1.1. + + - The reserved mailbox name "postmaster" may be used in a RCPT + command without domain qualification (see section 4.1.1.3) and + MUST be accepted if so used. + + + + + + + + +Klensin Standards Track [Page 23] + +RFC 2821 Simple Mail Transfer Protocol April 2001 + + +3.7 Relaying + + In general, the availability of Mail eXchanger records in the domain + name system [22, 27] makes the use of explicit source routes in the + Internet mail system unnecessary. Many historical problems with + their interpretation have made their use undesirable. SMTP clients + SHOULD NOT generate explicit source routes except under unusual + circumstances. SMTP servers MAY decline to act as mail relays or to + accept addresses that specify source routes. When route information + is encountered, SMTP servers are also permitted to ignore the route + information and simply send to the final destination specified as the + last element in the route and SHOULD do so. There has been an + invalid practice of using names that do not appear in the DNS as + destination names, with the senders counting on the intermediate + hosts specified in source routing to resolve any problems. If source + routes are stripped, this practice will cause failures. This is one + of several reasons why SMTP clients MUST NOT generate invalid source + routes or depend on serial resolution of names. + + When source routes are not used, the process described in RFC 821 for + constructing a reverse-path from the forward-path is not applicable + and the reverse-path at the time of delivery will simply be the + address that appeared in the MAIL command. + + A relay SMTP server is usually the target of a DNS MX record that + designates it, rather than the final delivery system. The relay + server may accept or reject the task of relaying the mail in the same + way it accepts or rejects mail for a local user. If it accepts the + task, it then becomes an SMTP client, establishes a transmission + channel to the next SMTP server specified in the DNS (according to + the rules in section 5), and sends it the mail. If it declines to + relay mail to a particular address for policy reasons, a 550 response + SHOULD be returned. + + Many mail-sending clients exist, especially in conjunction with + facilities that receive mail via POP3 or IMAP, that have limited + capability to support some of the requirements of this specification, + such as the ability to queue messages for subsequent delivery + attempts. For these clients, it is common practice to make private + arrangements to send all messages to a single server for processing + and subsequent distribution. SMTP, as specified here, is not ideally + suited for this role, and work is underway on standardized mail + submission protocols that might eventually supercede the current + practices. In any event, because these arrangements are private and + fall outside the scope of this specification, they are not described + here. + + + + + +Klensin Standards Track [Page 24] + +RFC 2821 Simple Mail Transfer Protocol April 2001 + + + It is important to note that MX records can point to SMTP servers + which act as gateways into other environments, not just SMTP relays + and final delivery systems; see sections 3.8 and 5. + + If an SMTP server has accepted the task of relaying the mail and + later finds that the destination is incorrect or that the mail cannot + be delivered for some other reason, then it MUST construct an + "undeliverable mail" notification message and send it to the + originator of the undeliverable mail (as indicated by the reverse- + path). Formats specified for non-delivery reports by other standards + (see, for example, [24, 25]) SHOULD be used if possible. + + This notification message must be from the SMTP server at the relay + host or the host that first determines that delivery cannot be + accomplished. Of course, SMTP servers MUST NOT send notification + messages about problems transporting notification messages. One way + to prevent loops in error reporting is to specify a null reverse-path + in the MAIL command of a notification message. When such a message + is transmitted the reverse-path MUST be set to null (see section + 4.5.5 for additional discussion). A MAIL command with a null + reverse-path appears as follows: + + MAIL FROM:<> + + As discussed in section 2.4.1, a relay SMTP has no need to inspect or + act upon the headers or body of the message data and MUST NOT do so + except to add its own "Received:" header (section 4.4) and, + optionally, to attempt to detect looping in the mail system (see + section 6.2). + +3.8 Mail Gatewaying + + While the relay function discussed above operates within the Internet + SMTP transport service environment, MX records or various forms of + explicit routing may require that an intermediate SMTP server perform + a translation function between one transport service and another. As + discussed in section 2.3.8, when such a system is at the boundary + between two transport service environments, we refer to it as a + "gateway" or "gateway SMTP". + + Gatewaying mail between different mail environments, such as + different mail formats and protocols, is complex and does not easily + yield to standardization. However, some general requirements may be + given for a gateway between the Internet and another mail + environment. + + + + + + +Klensin Standards Track [Page 25] + +RFC 2821 Simple Mail Transfer Protocol April 2001 + + +3.8.1 Header Fields in Gatewaying + + Header fields MAY be rewritten when necessary as messages are + gatewayed across mail environment boundaries. This may involve + inspecting the message body or interpreting the local-part of the + destination address in spite of the prohibitions in section 2.4.1. + + Other mail systems gatewayed to the Internet often use a subset of + RFC 822 headers or provide similar functionality with a different + syntax, but some of these mail systems do not have an equivalent to + the SMTP envelope. Therefore, when a message leaves the Internet + environment, it may be necessary to fold the SMTP envelope + information into the message header. A possible solution would be to + create new header fields to carry the envelope information (e.g., + "X-SMTP-MAIL:" and "X-SMTP-RCPT:"); however, this would require + changes in mail programs in foreign environments and might risk + disclosure of private information (see section 7.2). + +3.8.2 Received Lines in Gatewaying + + When forwarding a message into or out of the Internet environment, a + gateway MUST prepend a Received: line, but it MUST NOT alter in any + way a Received: line that is already in the header. + + "Received:" fields of messages originating from other environments + may not conform exactly to this specification. However, the most + important use of Received: lines is for debugging mail faults, and + this debugging can be severely hampered by well-meaning gateways that + try to "fix" a Received: line. As another consequence of trace + fields arising in non-SMTP environments, receiving systems MUST NOT + reject mail based on the format of a trace field and SHOULD be + extremely robust in the light of unexpected information or formats in + those fields. + + The gateway SHOULD indicate the environment and protocol in the "via" + clauses of Received field(s) that it supplies. + +3.8.3 Addresses in Gatewaying + + From the Internet side, the gateway SHOULD accept all valid address + formats in SMTP commands and in RFC 822 headers, and all valid RFC + 822 messages. Addresses and headers generated by gateways MUST + conform to applicable Internet standards (including this one and RFC + 822). Gateways are, of course, subject to the same rules for + handling source routes as those described for other SMTP systems in + section 3.3. + + + + + +Klensin Standards Track [Page 26] + +RFC 2821 Simple Mail Transfer Protocol April 2001 + + +3.8.4 Other Header Fields in Gatewaying + + The gateway MUST ensure that all header fields of a message that it + forwards into the Internet mail environment meet the requirements for + Internet mail. In particular, all addresses in "From:", "To:", + "Cc:", etc., fields MUST be transformed (if necessary) to satisfy RFC + 822 syntax, MUST reference only fully-qualified domain names, and + MUST be effective and useful for sending replies. The translation + algorithm used to convert mail from the Internet protocols to another + environment's protocol SHOULD ensure that error messages from the + foreign mail environment are delivered to the return path from the + SMTP envelope, not to the sender listed in the "From:" field (or + other fields) of the RFC 822 message. + +3.8.5 Envelopes in Gatewaying + + Similarly, when forwarding a message from another environment into + the Internet, the gateway SHOULD set the envelope return path in + accordance with an error message return address, if supplied by the + foreign environment. If the foreign environment has no equivalent + concept, the gateway must select and use a best approximation, with + the message originator's address as the default of last resort. + +3.9 Terminating Sessions and Connections + + An SMTP connection is terminated when the client sends a QUIT + command. The server responds with a positive reply code, after which + it closes the connection. + + An SMTP server MUST NOT intentionally close the connection except: + + - After receiving a QUIT command and responding with a 221 reply. + + - After detecting the need to shut down the SMTP service and + returning a 421 response code. This response code can be issued + after the server receives any command or, if necessary, + asynchronously from command receipt (on the assumption that the + client will receive it after the next command is issued). + + In particular, a server that closes connections in response to + commands that are not understood is in violation of this + specification. Servers are expected to be tolerant of unknown + commands, issuing a 500 reply and awaiting further instructions from + the client. + + + + + + + +Klensin Standards Track [Page 27] + +RFC 2821 Simple Mail Transfer Protocol April 2001 + + + An SMTP server which is forcibly shut down via external means SHOULD + attempt to send a line containing a 421 response code to the SMTP + client before exiting. The SMTP client will normally read the 421 + response code after sending its next command. + + SMTP clients that experience a connection close, reset, or other + communications failure due to circumstances not under their control + (in violation of the intent of this specification but sometimes + unavoidable) SHOULD, to maintain the robustness of the mail system, + treat the mail transaction as if a 451 response had been received and + act accordingly. + +3.10 Mailing Lists and Aliases + + An SMTP-capable host SHOULD support both the alias and the list + models of address expansion for multiple delivery. When a message is + delivered or forwarded to each address of an expanded list form, the + return address in the envelope ("MAIL FROM:") MUST be changed to be + the address of a person or other entity who administers the list. + However, in this case, the message header [32] MUST be left + unchanged; in particular, the "From" field of the message header is + unaffected. + + An important mail facility is a mechanism for multi-destination + delivery of a single message, by transforming (or "expanding" or + "exploding") a pseudo-mailbox address into a list of destination + mailbox addresses. When a message is sent to such a pseudo-mailbox + (sometimes called an "exploder"), copies are forwarded or + redistributed to each mailbox in the expanded list. Servers SHOULD + simply utilize the addresses on the list; application of heuristics + or other matching rules to eliminate some addresses, such as that of + the originator, is strongly discouraged. We classify such a pseudo- + mailbox as an "alias" or a "list", depending upon the expansion + rules. + +3.10.1 Alias + + To expand an alias, the recipient mailer simply replaces the pseudo- + mailbox address in the envelope with each of the expanded addresses + in turn; the rest of the envelope and the message body are left + unchanged. The message is then delivered or forwarded to each + expanded address. + +3.10.2 List + + A mailing list may be said to operate by "redistribution" rather than + by "forwarding". To expand a list, the recipient mailer replaces the + pseudo-mailbox address in the envelope with all of the expanded + + + +Klensin Standards Track [Page 28] + +RFC 2821 Simple Mail Transfer Protocol April 2001 + + + addresses. The return address in the envelope is changed so that all + error messages generated by the final deliveries will be returned to + a list administrator, not to the message originator, who generally + has no control over the contents of the list and will typically find + error messages annoying. + +4. The SMTP Specifications + +4.1 SMTP Commands + +4.1.1 Command Semantics and Syntax + + The SMTP commands define the mail transfer or the mail system + function requested by the user. SMTP commands are character strings + terminated by . The commands themselves are alphabetic + characters terminated by if parameters follow and + otherwise. (In the interest of improved interoperability, SMTP + receivers are encouraged to tolerate trailing white space before the + terminating .) The syntax of the local part of a mailbox must + conform to receiver site conventions and the syntax specified in + section 4.1.2. The SMTP commands are discussed below. The SMTP + replies are discussed in section 4.2. + + A mail transaction involves several data objects which are + communicated as arguments to different commands. The reverse-path is + the argument of the MAIL command, the forward-path is the argument of + the RCPT command, and the mail data is the argument of the DATA + command. These arguments or data objects must be transmitted and + held pending the confirmation communicated by the end of mail data + indication which finalizes the transaction. The model for this is + that distinct buffers are provided to hold the types of data objects, + that is, there is a reverse-path buffer, a forward-path buffer, and a + mail data buffer. Specific commands cause information to be appended + to a specific buffer, or cause one or more buffers to be cleared. + + Several commands (RSET, DATA, QUIT) are specified as not permitting + parameters. In the absence of specific extensions offered by the + server and accepted by the client, clients MUST NOT send such + parameters and servers SHOULD reject commands containing them as + having invalid syntax. + +4.1.1.1 Extended HELLO (EHLO) or HELLO (HELO) + + These commands are used to identify the SMTP client to the SMTP + server. The argument field contains the fully-qualified domain name + of the SMTP client if one is available. In situations in which the + SMTP client system does not have a meaningful domain name (e.g., when + its address is dynamically allocated and no reverse mapping record is + + + +Klensin Standards Track [Page 29] + +RFC 2821 Simple Mail Transfer Protocol April 2001 + + + available), the client SHOULD send an address literal (see section + 4.1.3), optionally followed by information that will help to identify + the client system. y The SMTP server identifies itself to the SMTP + client in the connection greeting reply and in the response to this + command. + + A client SMTP SHOULD start an SMTP session by issuing the EHLO + command. If the SMTP server supports the SMTP service extensions it + will give a successful response, a failure response, or an error + response. If the SMTP server, in violation of this specification, + does not support any SMTP service extensions it will generate an + error response. Older client SMTP systems MAY, as discussed above, + use HELO (as specified in RFC 821) instead of EHLO, and servers MUST + support the HELO command and reply properly to it. In any event, a + client MUST issue HELO or EHLO before starting a mail transaction. + + These commands, and a "250 OK" reply to one of them, confirm that + both the SMTP client and the SMTP server are in the initial state, + that is, there is no transaction in progress and all state tables and + buffers are cleared. + + Syntax: + + ehlo = "EHLO" SP Domain CRLF + helo = "HELO" SP Domain CRLF + + Normally, the response to EHLO will be a multiline reply. Each line + of the response contains a keyword and, optionally, one or more + parameters. Following the normal syntax for multiline replies, these + keyworks follow the code (250) and a hyphen for all but the last + line, and the code and a space for the last line. The syntax for a + positive response, using the ABNF notation and terminal symbols of + [8], is: + + ehlo-ok-rsp = ( "250" domain [ SP ehlo-greet ] CRLF ) + / ( "250-" domain [ SP ehlo-greet ] CRLF + *( "250-" ehlo-line CRLF ) + "250" SP ehlo-line CRLF ) + + ehlo-greet = 1*(%d0-9 / %d11-12 / %d14-127) + ; string of any characters other than CR or LF + + ehlo-line = ehlo-keyword *( SP ehlo-param ) + + ehlo-keyword = (ALPHA / DIGIT) *(ALPHA / DIGIT / "-") + ; additional syntax of ehlo-params depends on + ; ehlo-keyword + + + + +Klensin Standards Track [Page 30] + +RFC 2821 Simple Mail Transfer Protocol April 2001 + + + ehlo-param = 1*(%d33-127) + ; any CHAR excluding and all + ; control characters (US-ASCII 0-31 inclusive) + + Although EHLO keywords may be specified in upper, lower, or mixed + case, they MUST always be recognized and processed in a case- + insensitive manner. This is simply an extension of practices + specified in RFC 821 and section 2.4.1. + +4.1.1.2 MAIL (MAIL) + + This command is used to initiate a mail transaction in which the mail + data is delivered to an SMTP server which may, in turn, deliver it to + one or more mailboxes or pass it on to another system (possibly using + SMTP). The argument field contains a reverse-path and may contain + optional parameters. In general, the MAIL command may be sent only + when no mail transaction is in progress, see section 4.1.4. + + The reverse-path consists of the sender mailbox. Historically, that + mailbox might optionally have been preceded by a list of hosts, but + that behavior is now deprecated (see appendix C). In some types of + reporting messages for which a reply is likely to cause a mail loop + (for example, mail delivery and nondelivery notifications), the + reverse-path may be null (see section 3.7). + + This command clears the reverse-path buffer, the forward-path buffer, + and the mail data buffer; and inserts the reverse-path information + from this command into the reverse-path buffer. + + If service extensions were negotiated, the MAIL command may also + carry parameters associated with a particular service extension. + + Syntax: + + "MAIL FROM:" ("<>" / Reverse-Path) + [SP Mail-parameters] CRLF + +4.1.1.3 RECIPIENT (RCPT) + + This command is used to identify an individual recipient of the mail + data; multiple recipients are specified by multiple use of this + command. The argument field contains a forward-path and may contain + optional parameters. + + The forward-path normally consists of the required destination + mailbox. Sending systems SHOULD not generate the optional list of + hosts known as a source route. Receiving systems MUST recognize + + + + +Klensin Standards Track [Page 31] + +RFC 2821 Simple Mail Transfer Protocol April 2001 + + + source route syntax but SHOULD strip off the source route + specification and utilize the domain name associated with the mailbox + as if the source route had not been provided. + + Similarly, relay hosts SHOULD strip or ignore source routes, and + names MUST NOT be copied into the reverse-path. When mail reaches + its ultimate destination (the forward-path contains only a + destination mailbox), the SMTP server inserts it into the destination + mailbox in accordance with its host mail conventions. + + For example, mail received at relay host xyz.com with envelope + commands + + MAIL FROM: + RCPT TO:<@hosta.int,@jkl.org:userc@d.bar.org> + + will normally be sent directly on to host d.bar.org with envelope + commands + + MAIL FROM: + RCPT TO: + + As provided in appendix C, xyz.com MAY also choose to relay the + message to hosta.int, using the envelope commands + + MAIL FROM: + RCPT TO:<@hosta.int,@jkl.org:userc@d.bar.org> + + or to jkl.org, using the envelope commands + + MAIL FROM: + RCPT TO:<@jkl.org:userc@d.bar.org> + + Of course, since hosts are not required to relay mail at all, xyz.com + may also reject the message entirely when the RCPT command is + received, using a 550 code (since this is a "policy reason"). + + If service extensions were negotiated, the RCPT command may also + carry parameters associated with a particular service extension + offered by the server. The client MUST NOT transmit parameters other + than those associated with a service extension offered by the server + in its EHLO response. + +Syntax: + "RCPT TO:" ("" / "" / Forward-Path) + [SP Rcpt-parameters] CRLF + + + + + +Klensin Standards Track [Page 32] + +RFC 2821 Simple Mail Transfer Protocol April 2001 + + +4.1.1.4 DATA (DATA) + + The receiver normally sends a 354 response to DATA, and then treats + the lines (strings ending in sequences, as described in + section 2.3.7) following the command as mail data from the sender. + This command causes the mail data to be appended to the mail data + buffer. The mail data may contain any of the 128 ASCII character + codes, although experience has indicated that use of control + characters other than SP, HT, CR, and LF may cause problems and + SHOULD be avoided when possible. + + The mail data is terminated by a line containing only a period, that + is, the character sequence "." (see section 4.5.2). This + is the end of mail data indication. Note that the first of + this terminating sequence is also the that ends the final line + of the data (message text) or, if there was no data, ends the DATA + command itself. An extra MUST NOT be added, as that would + cause an empty line to be added to the message. The only exception + to this rule would arise if the message body were passed to the + originating SMTP-sender with a final "line" that did not end in + ; in that case, the originating SMTP system MUST either reject + the message as invalid or add in order to have the receiving + SMTP server recognize the "end of data" condition. + + The custom of accepting lines ending only in , as a concession to + non-conforming behavior on the part of some UNIX systems, has proven + to cause more interoperability problems than it solves, and SMTP + server systems MUST NOT do this, even in the name of improved + robustness. In particular, the sequence "." (bare line + feeds, without carriage returns) MUST NOT be treated as equivalent to + . as the end of mail data indication. + + Receipt of the end of mail data indication requires the server to + process the stored mail transaction information. This processing + consumes the information in the reverse-path buffer, the forward-path + buffer, and the mail data buffer, and on the completion of this + command these buffers are cleared. If the processing is successful, + the receiver MUST send an OK reply. If the processing fails the + receiver MUST send a failure reply. The SMTP model does not allow + for partial failures at this point: either the message is accepted by + the server for delivery and a positive response is returned or it is + not accepted and a failure reply is returned. In sending a positive + completion reply to the end of data indication, the receiver takes + full responsibility for the message (see section 6.1). Errors that + are diagnosed subsequently MUST be reported in a mail message, as + discussed in section 4.4. + + + + + +Klensin Standards Track [Page 33] + +RFC 2821 Simple Mail Transfer Protocol April 2001 + + + When the SMTP server accepts a message either for relaying or for + final delivery, it inserts a trace record (also referred to + interchangeably as a "time stamp line" or "Received" line) at the top + of the mail data. This trace record indicates the identity of the + host that sent the message, the identity of the host that received + the message (and is inserting this time stamp), and the date and time + the message was received. Relayed messages will have multiple time + stamp lines. Details for formation of these lines, including their + syntax, is specified in section 4.4. + + Additional discussion about the operation of the DATA command appears + in section 3.3. + + Syntax: + "DATA" CRLF + +4.1.1.5 RESET (RSET) + + This command specifies that the current mail transaction will be + aborted. Any stored sender, recipients, and mail data MUST be + discarded, and all buffers and state tables cleared. The receiver + MUST send a "250 OK" reply to a RSET command with no arguments. A + reset command may be issued by the client at any time. It is + effectively equivalent to a NOOP (i.e., if has no effect) if issued + immediately after EHLO, before EHLO is issued in the session, after + an end-of-data indicator has been sent and acknowledged, or + immediately before a QUIT. An SMTP server MUST NOT close the + connection as the result of receiving a RSET; that action is reserved + for QUIT (see section 4.1.1.10). + + Since EHLO implies some additional processing and response by the + server, RSET will normally be more efficient than reissuing that + command, even though the formal semantics are the same. + + There are circumstances, contrary to the intent of this + specification, in which an SMTP server may receive an indication that + the underlying TCP connection has been closed or reset. To preserve + the robustness of the mail system, SMTP servers SHOULD be prepared + for this condition and SHOULD treat it as if a QUIT had been received + before the connection disappeared. + + Syntax: + "RSET" CRLF + + + + + + + + +Klensin Standards Track [Page 34] + +RFC 2821 Simple Mail Transfer Protocol April 2001 + + +4.1.1.6 VERIFY (VRFY) + + This command asks the receiver to confirm that the argument + identifies a user or mailbox. If it is a user name, information is + returned as specified in section 3.5. + + This command has no effect on the reverse-path buffer, the forward- + path buffer, or the mail data buffer. + + Syntax: + "VRFY" SP String CRLF + +4.1.1.7 EXPAND (EXPN) + + This command asks the receiver to confirm that the argument + identifies a mailing list, and if so, to return the membership of + that list. If the command is successful, a reply is returned + containing information as described in section 3.5. This reply will + have multiple lines except in the trivial case of a one-member list. + + This command has no effect on the reverse-path buffer, the forward- + path buffer, or the mail data buffer and may be issued at any time. + + Syntax: + "EXPN" SP String CRLF + +4.1.1.8 HELP (HELP) + + This command causes the server to send helpful information to the + client. The command MAY take an argument (e.g., any command name) + and return more specific information as a response. + + This command has no effect on the reverse-path buffer, the forward- + path buffer, or the mail data buffer and may be issued at any time. + + SMTP servers SHOULD support HELP without arguments and MAY support it + with arguments. + + Syntax: + "HELP" [ SP String ] CRLF + +4.1.1.9 NOOP (NOOP) + + This command does not affect any parameters or previously entered + commands. It specifies no action other than that the receiver send + an OK reply. + + + + + +Klensin Standards Track [Page 35] + +RFC 2821 Simple Mail Transfer Protocol April 2001 + + + This command has no effect on the reverse-path buffer, the forward- + path buffer, or the mail data buffer and may be issued at any time. + If a parameter string is specified, servers SHOULD ignore it. + + Syntax: + "NOOP" [ SP String ] CRLF + +4.1.1.10 QUIT (QUIT) + + This command specifies that the receiver MUST send an OK reply, and + then close the transmission channel. + + The receiver MUST NOT intentionally close the transmission channel + until it receives and replies to a QUIT command (even if there was an + error). The sender MUST NOT intentionally close the transmission + channel until it sends a QUIT command and SHOULD wait until it + receives the reply (even if there was an error response to a previous + command). If the connection is closed prematurely due to violations + of the above or system or network failure, the server MUST cancel any + pending transaction, but not undo any previously completed + transaction, and generally MUST act as if the command or transaction + in progress had received a temporary error (i.e., a 4yz response). + + The QUIT command may be issued at any time. + + Syntax: + "QUIT" CRLF + +4.1.2 Command Argument Syntax + + The syntax of the argument fields of the above commands (using the + syntax specified in [8] where applicable) is given below. Some of + the productions given below are used only in conjunction with source + routes as described in appendix C. Terminals not defined in this + document, such as ALPHA, DIGIT, SP, CR, LF, CRLF, are as defined in + the "core" syntax [8 (section 6)] or in the message format syntax + [32]. + + Reverse-path = Path + Forward-path = Path + Path = "<" [ A-d-l ":" ] Mailbox ">" + A-d-l = At-domain *( "," A-d-l ) + ; Note that this form, the so-called "source route", + ; MUST BE accepted, SHOULD NOT be generated, and SHOULD be + ; ignored. + At-domain = "@" domain + Mail-parameters = esmtp-param *(SP esmtp-param) + Rcpt-parameters = esmtp-param *(SP esmtp-param) + + + +Klensin Standards Track [Page 36] + +RFC 2821 Simple Mail Transfer Protocol April 2001 + + + esmtp-param = esmtp-keyword ["=" esmtp-value] + esmtp-keyword = (ALPHA / DIGIT) *(ALPHA / DIGIT / "-") + esmtp-value = 1*(%d33-60 / %d62-127) + ; any CHAR excluding "=", SP, and control characters + Keyword = Ldh-str + Argument = Atom + Domain = (sub-domain 1*("." sub-domain)) / address-literal + sub-domain = Let-dig [Ldh-str] + + address-literal = "[" IPv4-address-literal / + IPv6-address-literal / + General-address-literal "]" + ; See section 4.1.3 + + Mailbox = Local-part "@" Domain + + Local-part = Dot-string / Quoted-string + ; MAY be case-sensitive + + Dot-string = Atom *("." Atom) + + Atom = 1*atext + + Quoted-string = DQUOTE *qcontent DQUOTE + + String = Atom / Quoted-string + + While the above definition for Local-part is relatively permissive, + for maximum interoperability, a host that expects to receive mail + SHOULD avoid defining mailboxes where the Local-part requires (or + uses) the Quoted-string form or where the Local-part is case- + sensitive. For any purposes that require generating or comparing + Local-parts (e.g., to specific mailbox names), all quoted forms MUST + be treated as equivalent and the sending system SHOULD transmit the + form that uses the minimum quoting possible. + + Systems MUST NOT define mailboxes in such a way as to require the use + in SMTP of non-ASCII characters (octets with the high order bit set + to one) or ASCII "control characters" (decimal value 0-31 and 127). + These characters MUST NOT be used in MAIL or RCPT commands or other + commands that require mailbox names. + + Note that the backslash, "\", is a quote character, which is used to + indicate that the next character is to be used literally (instead of + its normal interpretation). For example, "Joe\,Smith" indicates a + single nine character user field with the comma being the fourth + character of the field. + + + + +Klensin Standards Track [Page 37] + +RFC 2821 Simple Mail Transfer Protocol April 2001 + + + To promote interoperability and consistent with long-standing + guidance about conservative use of the DNS in naming and applications + (e.g., see section 2.3.1 of the base DNS document, RFC1035 [22]), + characters outside the set of alphas, digits, and hyphen MUST NOT + appear in domain name labels for SMTP clients or servers. In + particular, the underscore character is not permitted. SMTP servers + that receive a command in which invalid character codes have been + employed, and for which there are no other reasons for rejection, + MUST reject that command with a 501 response. + +4.1.3 Address Literals + + Sometimes a host is not known to the domain name system and + communication (and, in particular, communication to report and repair + the error) is blocked. To bypass this barrier a special literal form + of the address is allowed as an alternative to a domain name. For + IPv4 addresses, this form uses four small decimal integers separated + by dots and enclosed by brackets such as [123.255.37.2], which + indicates an (IPv4) Internet Address in sequence-of-octets form. For + IPv6 and other forms of addressing that might eventually be + standardized, the form consists of a standardized "tag" that + identifies the address syntax, a colon, and the address itself, in a + format specified as part of the IPv6 standards [17]. + + Specifically: + + IPv4-address-literal = Snum 3("." Snum) + IPv6-address-literal = "IPv6:" IPv6-addr + General-address-literal = Standardized-tag ":" 1*dcontent + Standardized-tag = Ldh-str + ; MUST be specified in a standards-track RFC + ; and registered with IANA + + Snum = 1*3DIGIT ; representing a decimal integer + ; value in the range 0 through 255 + Let-dig = ALPHA / DIGIT + Ldh-str = *( ALPHA / DIGIT / "-" ) Let-dig + + IPv6-addr = IPv6-full / IPv6-comp / IPv6v4-full / IPv6v4-comp + IPv6-hex = 1*4HEXDIG + IPv6-full = IPv6-hex 7(":" IPv6-hex) + IPv6-comp = [IPv6-hex *5(":" IPv6-hex)] "::" [IPv6-hex *5(":" + IPv6-hex)] + ; The "::" represents at least 2 16-bit groups of zeros + ; No more than 6 groups in addition to the "::" may be + ; present + IPv6v4-full = IPv6-hex 5(":" IPv6-hex) ":" IPv4-address-literal + IPv6v4-comp = [IPv6-hex *3(":" IPv6-hex)] "::" + + + +Klensin Standards Track [Page 38] + +RFC 2821 Simple Mail Transfer Protocol April 2001 + + + [IPv6-hex *3(":" IPv6-hex) ":"] IPv4-address-literal + ; The "::" represents at least 2 16-bit groups of zeros + ; No more than 4 groups in addition to the "::" and + ; IPv4-address-literal may be present + +4.1.4 Order of Commands + + There are restrictions on the order in which these commands may be + used. + + A session that will contain mail transactions MUST first be + initialized by the use of the EHLO command. An SMTP server SHOULD + accept commands for non-mail transactions (e.g., VRFY or EXPN) + without this initialization. + + An EHLO command MAY be issued by a client later in the session. If + it is issued after the session begins, the SMTP server MUST clear all + buffers and reset the state exactly as if a RSET command had been + issued. In other words, the sequence of RSET followed immediately by + EHLO is redundant, but not harmful other than in the performance cost + of executing unnecessary commands. + + If the EHLO command is not acceptable to the SMTP server, 501, 500, + or 502 failure replies MUST be returned as appropriate. The SMTP + server MUST stay in the same state after transmitting these replies + that it was in before the EHLO was received. + + The SMTP client MUST, if possible, ensure that the domain parameter + to the EHLO command is a valid principal host name (not a CNAME or MX + name) for its host. If this is not possible (e.g., when the client's + address is dynamically assigned and the client does not have an + obvious name), an address literal SHOULD be substituted for the + domain name and supplemental information provided that will assist in + identifying the client. + + An SMTP server MAY verify that the domain name parameter in the EHLO + command actually corresponds to the IP address of the client. + However, the server MUST NOT refuse to accept a message for this + reason if the verification fails: the information about verification + failure is for logging and tracing only. + + The NOOP, HELP, EXPN, VRFY, and RSET commands can be used at any time + during a session, or without previously initializing a session. SMTP + servers SHOULD process these normally (that is, not return a 503 + code) even if no EHLO command has yet been received; clients SHOULD + open a session with EHLO before sending these commands. + + + + + +Klensin Standards Track [Page 39] + +RFC 2821 Simple Mail Transfer Protocol April 2001 + + + If these rules are followed, the example in RFC 821 that shows "550 + access denied to you" in response to an EXPN command is incorrect + unless an EHLO command precedes the EXPN or the denial of access is + based on the client's IP address or other authentication or + authorization-determining mechanisms. + + The MAIL command (or the obsolete SEND, SOML, or SAML commands) + begins a mail transaction. Once started, a mail transaction consists + of a transaction beginning command, one or more RCPT commands, and a + DATA command, in that order. A mail transaction may be aborted by + the RSET (or a new EHLO) command. There may be zero or more + transactions in a session. MAIL (or SEND, SOML, or SAML) MUST NOT be + sent if a mail transaction is already open, i.e., it should be sent + only if no mail transaction had been started in the session, or it + the previous one successfully concluded with a successful DATA + command, or if the previous one was aborted with a RSET. + + If the transaction beginning command argument is not acceptable, a + 501 failure reply MUST be returned and the SMTP server MUST stay in + the same state. If the commands in a transaction are out of order to + the degree that they cannot be processed by the server, a 503 failure + reply MUST be returned and the SMTP server MUST stay in the same + state. + + The last command in a session MUST be the QUIT command. The QUIT + command cannot be used at any other time in a session, but SHOULD be + used by the client SMTP to request connection closure, even when no + session opening command was sent and accepted. + +4.1.5 Private-use Commands + + As specified in section 2.2.2, commands starting in "X" may be used + by bilateral agreement between the client (sending) and server + (receiving) SMTP agents. An SMTP server that does not recognize such + a command is expected to reply with "500 Command not recognized". An + extended SMTP server MAY list the feature names associated with these + private commands in the response to the EHLO command. + + Commands sent or accepted by SMTP systems that do not start with "X" + MUST conform to the requirements of section 2.2.2. + +4.2 SMTP Replies + + Replies to SMTP commands serve to ensure the synchronization of + requests and actions in the process of mail transfer and to guarantee + that the SMTP client always knows the state of the SMTP server. + Every command MUST generate exactly one reply. + + + + +Klensin Standards Track [Page 40] + +RFC 2821 Simple Mail Transfer Protocol April 2001 + + + The details of the command-reply sequence are described in section + 4.3. + + An SMTP reply consists of a three digit number (transmitted as three + numeric characters) followed by some text unless specified otherwise + in this document. The number is for use by automata to determine + what state to enter next; the text is for the human user. The three + digits contain enough encoded information that the SMTP client need + not examine the text and may either discard it or pass it on to the + user, as appropriate. Exceptions are as noted elsewhere in this + document. In particular, the 220, 221, 251, 421, and 551 reply codes + are associated with message text that must be parsed and interpreted + by machines. In the general case, the text may be receiver dependent + and context dependent, so there are likely to be varying texts for + each reply code. A discussion of the theory of reply codes is given + in section 4.2.1. Formally, a reply is defined to be the sequence: a + three-digit code, , one line of text, and , or a multiline + reply (as defined in section 4.2.1). Since, in violation of this + specification, the text is sometimes not sent, clients which do not + receive it SHOULD be prepared to process the code alone (with or + without a trailing space character). Only the EHLO, EXPN, and HELP + commands are expected to result in multiline replies in normal + circumstances, however, multiline replies are allowed for any + command. + + In ABNF, server responses are: + + Greeting = "220 " Domain [ SP text ] CRLF + Reply-line = Reply-code [ SP text ] CRLF + + where "Greeting" appears only in the 220 response that announces that + the server is opening its part of the connection. + + An SMTP server SHOULD send only the reply codes listed in this + document. An SMTP server SHOULD use the text shown in the examples + whenever appropriate. + + An SMTP client MUST determine its actions only by the reply code, not + by the text (except for the "change of address" 251 and 551 and, if + necessary, 220, 221, and 421 replies); in the general case, any text, + including no text at all (although senders SHOULD NOT send bare + codes), MUST be acceptable. The space (blank) following the reply + code is considered part of the text. Whenever possible, a receiver- + SMTP SHOULD test the first digit (severity indication) of the reply + code. + + + + + + +Klensin Standards Track [Page 41] + +RFC 2821 Simple Mail Transfer Protocol April 2001 + + + The list of codes that appears below MUST NOT be construed as + permanent. While the addition of new codes should be a rare and + significant activity, with supplemental information in the textual + part of the response being preferred, new codes may be added as the + result of new Standards or Standards-track specifications. + Consequently, a sender-SMTP MUST be prepared to handle codes not + specified in this document and MUST do so by interpreting the first + digit only. + +4.2.1 Reply Code Severities and Theory + + The three digits of the reply each have a special significance. The + first digit denotes whether the response is good, bad or incomplete. + An unsophisticated SMTP client, or one that receives an unexpected + code, will be able to determine its next action (proceed as planned, + redo, retrench, etc.) by examining this first digit. An SMTP client + that wants to know approximately what kind of error occurred (e.g., + mail system error, command syntax error) may examine the second + digit. The third digit and any supplemental information that may be + present is reserved for the finest gradation of information. + + There are five values for the first digit of the reply code: + + 1yz Positive Preliminary reply + The command has been accepted, but the requested action is being + held in abeyance, pending confirmation of the information in this + reply. The SMTP client should send another command specifying + whether to continue or abort the action. Note: unextended SMTP + does not have any commands that allow this type of reply, and so + does not have continue or abort commands. + + 2yz Positive Completion reply + The requested action has been successfully completed. A new + request may be initiated. + + 3yz Positive Intermediate reply + The command has been accepted, but the requested action is being + held in abeyance, pending receipt of further information. The + SMTP client should send another command specifying this + information. This reply is used in command sequence groups (i.e., + in DATA). + + 4yz Transient Negative Completion reply + The command was not accepted, and the requested action did not + occur. However, the error condition is temporary and the action + may be requested again. The sender should return to the beginning + of the command sequence (if any). It is difficult to assign a + meaning to "transient" when two different sites (receiver- and + + + +Klensin Standards Track [Page 42] + +RFC 2821 Simple Mail Transfer Protocol April 2001 + + + sender-SMTP agents) must agree on the interpretation. Each reply + in this category might have a different time value, but the SMTP + client is encouraged to try again. A rule of thumb to determine + whether a reply fits into the 4yz or the 5yz category (see below) + is that replies are 4yz if they can be successful if repeated + without any change in command form or in properties of the sender + or receiver (that is, the command is repeated identically and the + receiver does not put up a new implementation.) + + 5yz Permanent Negative Completion reply + The command was not accepted and the requested action did not + occur. The SMTP client is discouraged from repeating the exact + request (in the same sequence). Even some "permanent" error + conditions can be corrected, so the human user may want to direct + the SMTP client to reinitiate the command sequence by direct + action at some point in the future (e.g., after the spelling has + been changed, or the user has altered the account status). + + The second digit encodes responses in specific categories: + + x0z Syntax: These replies refer to syntax errors, syntactically + correct commands that do not fit any functional category, and + unimplemented or superfluous commands. + + x1z Information: These are replies to requests for information, + such as status or help. + + x2z Connections: These are replies referring to the transmission + channel. + + x3z Unspecified. + + x4z Unspecified. + + x5z Mail system: These replies indicate the status of the receiver + mail system vis-a-vis the requested transfer or other mail system + action. + + The third digit gives a finer gradation of meaning in each category + specified by the second digit. The list of replies illustrates this. + Each reply text is recommended rather than mandatory, and may even + change according to the command with which it is associated. On the + other hand, the reply codes must strictly follow the specifications + in this section. Receiver implementations should not invent new + codes for slightly different situations from the ones described here, + but rather adapt codes already defined. + + + + + +Klensin Standards Track [Page 43] + +RFC 2821 Simple Mail Transfer Protocol April 2001 + + + For example, a command such as NOOP, whose successful execution does + not offer the SMTP client any new information, will return a 250 + reply. The reply is 502 when the command requests an unimplemented + non-site-specific action. A refinement of that is the 504 reply for + a command that is implemented, but that requests an unimplemented + parameter. + + The reply text may be longer than a single line; in these cases the + complete text must be marked so the SMTP client knows when it can + stop reading the reply. This requires a special format to indicate a + multiple line reply. + + The format for multiline replies requires that every line, except the + last, begin with the reply code, followed immediately by a hyphen, + "-" (also known as minus), followed by text. The last line will + begin with the reply code, followed immediately by , optionally + some text, and . As noted above, servers SHOULD send the + if subsequent text is not sent, but clients MUST be prepared for it + to be omitted. + + For example: + + 123-First line + 123-Second line + 123-234 text beginning with numbers + 123 The last line + + In many cases the SMTP client then simply needs to search for a line + beginning with the reply code followed by or and ignore + all preceding lines. In a few cases, there is important data for the + client in the reply "text". The client will be able to identify + these cases from the current context. + +4.2.2 Reply Codes by Function Groups + + 500 Syntax error, command unrecognized + (This may include errors such as command line too long) + 501 Syntax error in parameters or arguments + 502 Command not implemented (see section 4.2.4) + 503 Bad sequence of commands + 504 Command parameter not implemented + + 211 System status, or system help reply + 214 Help message + (Information on how to use the receiver or the meaning of a + particular non-standard command; this reply is useful only + to the human user) + + + + +Klensin Standards Track [Page 44] + +RFC 2821 Simple Mail Transfer Protocol April 2001 + + + 220 Service ready + 221 Service closing transmission channel + 421 Service not available, closing transmission channel + (This may be a reply to any command if the service knows it + must shut down) + + 250 Requested mail action okay, completed + 251 User not local; will forward to + (See section 3.4) + 252 Cannot VRFY user, but will accept message and attempt + delivery + (See section 3.5.3) + 450 Requested mail action not taken: mailbox unavailable + (e.g., mailbox busy) + 550 Requested action not taken: mailbox unavailable + (e.g., mailbox not found, no access, or command rejected + for policy reasons) + 451 Requested action aborted: error in processing + 551 User not local; please try + (See section 3.4) + 452 Requested action not taken: insufficient system storage + 552 Requested mail action aborted: exceeded storage allocation + 553 Requested action not taken: mailbox name not allowed + (e.g., mailbox syntax incorrect) + 354 Start mail input; end with . + 554 Transaction failed (Or, in the case of a connection-opening + response, "No SMTP service here") + +4.2.3 Reply Codes in Numeric Order + + 211 System status, or system help reply + 214 Help message + (Information on how to use the receiver or the meaning of a + particular non-standard command; this reply is useful only + to the human user) + 220 Service ready + 221 Service closing transmission channel + 250 Requested mail action okay, completed + 251 User not local; will forward to + (See section 3.4) + 252 Cannot VRFY user, but will accept message and attempt + delivery + (See section 3.5.3) + + 354 Start mail input; end with . + + + + + + +Klensin Standards Track [Page 45] + +RFC 2821 Simple Mail Transfer Protocol April 2001 + + + 421 Service not available, closing transmission channel + (This may be a reply to any command if the service knows it + must shut down) + 450 Requested mail action not taken: mailbox unavailable + (e.g., mailbox busy) + 451 Requested action aborted: local error in processing + 452 Requested action not taken: insufficient system storage + 500 Syntax error, command unrecognized + (This may include errors such as command line too long) + 501 Syntax error in parameters or arguments + 502 Command not implemented (see section 4.2.4) + 503 Bad sequence of commands + 504 Command parameter not implemented + 550 Requested action not taken: mailbox unavailable + (e.g., mailbox not found, no access, or command rejected + for policy reasons) + 551 User not local; please try + (See section 3.4) + 552 Requested mail action aborted: exceeded storage allocation + 553 Requested action not taken: mailbox name not allowed + (e.g., mailbox syntax incorrect) + 554 Transaction failed (Or, in the case of a connection-opening + response, "No SMTP service here") + +4.2.4 Reply Code 502 + + Questions have been raised as to when reply code 502 (Command not + implemented) SHOULD be returned in preference to other codes. 502 + SHOULD be used when the command is actually recognized by the SMTP + server, but not implemented. If the command is not recognized, code + 500 SHOULD be returned. Extended SMTP systems MUST NOT list + capabilities in response to EHLO for which they will return 502 (or + 500) replies. + +4.2.5 Reply Codes After DATA and the Subsequent . + + When an SMTP server returns a positive completion status (2yz code) + after the DATA command is completed with ., it accepts + responsibility for: + + - delivering the message (if the recipient mailbox exists), or + + - if attempts to deliver the message fail due to transient + conditions, retrying delivery some reasonable number of times at + intervals as specified in section 4.5.4. + + + + + + +Klensin Standards Track [Page 46] + +RFC 2821 Simple Mail Transfer Protocol April 2001 + + + - if attempts to deliver the message fail due to permanent + conditions, or if repeated attempts to deliver the message fail + due to transient conditions, returning appropriate notification to + the sender of the original message (using the address in the SMTP + MAIL command). + + When an SMTP server returns a permanent error status (5yz) code after + the DATA command is completed with ., it MUST NOT make + any subsequent attempt to deliver that message. The SMTP client + retains responsibility for delivery of that message and may either + return it to the user or requeue it for a subsequent attempt (see + section 4.5.4.1). + + The user who originated the message SHOULD be able to interpret the + return of a transient failure status (by mail message or otherwise) + as a non-delivery indication, just as a permanent failure would be + interpreted. I.e., if the client SMTP successfully handles these + conditions, the user will not receive such a reply. + + When an SMTP server returns a permanent error status (5yz) code after + the DATA command is completely with ., it MUST NOT make + any subsequent attempt to deliver the message. As with temporary + error status codes, the SMTP client retains responsibility for the + message, but SHOULD not again attempt delivery to the same server + without user review and intervention of the message. + +4.3 Sequencing of Commands and Replies + +4.3.1 Sequencing Overview + + The communication between the sender and receiver is an alternating + dialogue, controlled by the sender. As such, the sender issues a + command and the receiver responds with a reply. Unless other + arrangements are negotiated through service extensions, the sender + MUST wait for this response before sending further commands. + + One important reply is the connection greeting. Normally, a receiver + will send a 220 "Service ready" reply when the connection is + completed. The sender SHOULD wait for this greeting message before + sending any commands. + + Note: all the greeting-type replies have the official name (the + fully-qualified primary domain name) of the server host as the first + word following the reply code. Sometimes the host will have no + meaningful name. See 4.1.3 for a discussion of alternatives in these + situations. + + + + + +Klensin Standards Track [Page 47] + +RFC 2821 Simple Mail Transfer Protocol April 2001 + + + For example, + + 220 ISIF.USC.EDU Service ready + or + 220 mail.foo.com SuperSMTP v 6.1.2 Service ready + or + 220 [10.0.0.1] Clueless host service ready + + The table below lists alternative success and failure replies for + each command. These SHOULD be strictly adhered to: a receiver may + substitute text in the replies, but the meaning and action implied by + the code numbers and by the specific command reply sequence cannot be + altered. + +4.3.2 Command-Reply Sequences + + Each command is listed with its usual possible replies. The prefixes + used before the possible replies are "I" for intermediate, "S" for + success, and "E" for error. Since some servers may generate other + replies under special circumstances, and to allow for future + extension, SMTP clients SHOULD, when possible, interpret only the + first digit of the reply and MUST be prepared to deal with + unrecognized reply codes by interpreting the first digit only. + Unless extended using the mechanisms described in section 2.2, SMTP + servers MUST NOT transmit reply codes to an SMTP client that are + other than three digits or that do not start in a digit between 2 and + 5 inclusive. + + These sequencing rules and, in principle, the codes themselves, can + be extended or modified by SMTP extensions offered by the server and + accepted (requested) by the client. + + In addition to the codes listed below, any SMTP command can return + any of the following codes if the corresponding unusual circumstances + are encountered: + + 500 For the "command line too long" case or if the command name was + not recognized. Note that producing a "command not recognized" + error in response to the required subset of these commands is a + violation of this specification. + + 501 Syntax error in command or arguments. In order to provide for + future extensions, commands that are specified in this document as + not accepting arguments (DATA, RSET, QUIT) SHOULD return a 501 + message if arguments are supplied in the absence of EHLO- + advertised extensions. + + 421 Service shutting down and closing transmission channel + + + +Klensin Standards Track [Page 48] + +RFC 2821 Simple Mail Transfer Protocol April 2001 + + + Specific sequences are: + + CONNECTION ESTABLISHMENT + S: 220 + E: 554 + EHLO or HELO + S: 250 + E: 504, 550 + MAIL + S: 250 + E: 552, 451, 452, 550, 553, 503 + RCPT + S: 250, 251 (but see section 3.4 for discussion of 251 and 551) + E: 550, 551, 552, 553, 450, 451, 452, 503, 550 + DATA + I: 354 -> data -> S: 250 + E: 552, 554, 451, 452 + E: 451, 554, 503 + RSET + S: 250 + VRFY + S: 250, 251, 252 + E: 550, 551, 553, 502, 504 + EXPN + S: 250, 252 + E: 550, 500, 502, 504 + HELP + S: 211, 214 + E: 502, 504 + NOOP + S: 250 + QUIT + S: 221 + +4.4 Trace Information + + When an SMTP server receives a message for delivery or further + processing, it MUST insert trace ("time stamp" or "Received") + information at the beginning of the message content, as discussed in + section 4.1.1.4. + + This line MUST be structured as follows: + + - The FROM field, which MUST be supplied in an SMTP environment, + SHOULD contain both (1) the name of the source host as presented + in the EHLO command and (2) an address literal containing the IP + address of the source, determined from the TCP connection. + + + + +Klensin Standards Track [Page 49] + +RFC 2821 Simple Mail Transfer Protocol April 2001 + + + - The ID field MAY contain an "@" as suggested in RFC 822, but this + is not required. + + - The FOR field MAY contain a list of entries when multiple + RCPT commands have been given. This may raise some security + issues and is usually not desirable; see section 7.2. + + An Internet mail program MUST NOT change a Received: line that was + previously added to the message header. SMTP servers MUST prepend + Received lines to messages; they MUST NOT change the order of + existing lines or insert Received lines in any other location. + + As the Internet grows, comparability of Received fields is important + for detecting problems, especially slow relays. SMTP servers that + create Received fields SHOULD use explicit offsets in the dates + (e.g., -0800), rather than time zone names of any type. Local time + (with an offset) is preferred to UT when feasible. This formulation + allows slightly more information about local circumstances to be + specified. If UT is needed, the receiver need merely do some simple + arithmetic to convert the values. Use of UT loses information about + the time zone-location of the server. If it is desired to supply a + time zone name, it SHOULD be included in a comment. + + When the delivery SMTP server makes the "final delivery" of a + message, it inserts a return-path line at the beginning of the mail + data. This use of return-path is required; mail systems MUST support + it. The return-path line preserves the information in the from the MAIL command. Here, final delivery means the message + has left the SMTP environment. Normally, this would mean it had been + delivered to the destination user or an associated mail drop, but in + some cases it may be further processed and transmitted by another + mail system. + + It is possible for the mailbox in the return path to be different + from the actual sender's mailbox, for example, if error responses are + to be delivered to a special error handling mailbox rather than to + the message sender. When mailing lists are involved, this + arrangement is common and useful as a means of directing errors to + the list maintainer rather than the message originator. + + The text above implies that the final mail data will begin with a + return path line, followed by one or more time stamp lines. These + lines will be followed by the mail data headers and body [32]. + + It is sometimes difficult for an SMTP server to determine whether or + not it is making final delivery since forwarding or other operations + may occur after the message is accepted for delivery. Consequently, + + + + +Klensin Standards Track [Page 50] + +RFC 2821 Simple Mail Transfer Protocol April 2001 + + + any further (forwarding, gateway, or relay) systems MAY remove the + return path and rebuild the MAIL command as needed to ensure that + exactly one such line appears in a delivered message. + + A message-originating SMTP system SHOULD NOT send a message that + already contains a Return-path header. SMTP servers performing a + relay function MUST NOT inspect the message data, and especially not + to the extent needed to determine if Return-path headers are present. + SMTP servers making final delivery MAY remove Return-path headers + before adding their own. + + The primary purpose of the Return-path is to designate the address to + which messages indicating non-delivery or other mail system failures + are to be sent. For this to be unambiguous, exactly one return path + SHOULD be present when the message is delivered. Systems using RFC + 822 syntax with non-SMTP transports SHOULD designate an unambiguous + address, associated with the transport envelope, to which error + reports (e.g., non-delivery messages) should be sent. + + Historical note: Text in RFC 822 that appears to contradict the use + of the Return-path header (or the envelope reverse path address from + the MAIL command) as the destination for error messages is not + applicable on the Internet. The reverse path address (as copied into + the Return-path) MUST be used as the target of any mail containing + delivery error messages. + + In particular: + + - a gateway from SMTP->elsewhere SHOULD insert a return-path header, + unless it is known that the "elsewhere" transport also uses + Internet domain addresses and maintains the envelope sender + address separately. + + - a gateway from elsewhere->SMTP SHOULD delete any return-path + header present in the message, and either copy that information to + the SMTP envelope or combine it with information present in the + envelope of the other transport system to construct the reverse + path argument to the MAIL command in the SMTP envelope. + + The server must give special treatment to cases in which the + processing following the end of mail data indication is only + partially successful. This could happen if, after accepting several + recipients and the mail data, the SMTP server finds that the mail + data could be successfully delivered to some, but not all, of the + recipients. In such cases, the response to the DATA command MUST be + an OK reply. However, the SMTP server MUST compose and send an + "undeliverable mail" notification message to the originator of the + message. + + + +Klensin Standards Track [Page 51] + +RFC 2821 Simple Mail Transfer Protocol April 2001 + + + A single notification listing all of the failed recipients or + separate notification messages MUST be sent for each failed + recipient. For economy of processing by the sender, the former is + preferred when possible. All undeliverable mail notification + messages are sent using the MAIL command (even if they result from + processing the obsolete SEND, SOML, or SAML commands) and use a null + return path as discussed in section 3.7. + + The time stamp line and the return path line are formally defined as + follows: + +Return-path-line = "Return-Path:" FWS Reverse-path + +Time-stamp-line = "Received:" FWS Stamp + +Stamp = From-domain By-domain Opt-info ";" FWS date-time + + ; where "date-time" is as defined in [32] + ; but the "obs-" forms, especially two-digit + ; years, are prohibited in SMTP and MUST NOT be used. + +From-domain = "FROM" FWS Extended-Domain CFWS + +By-domain = "BY" FWS Extended-Domain CFWS + +Extended-Domain = Domain / + ( Domain FWS "(" TCP-info ")" ) / + ( Address-literal FWS "(" TCP-info ")" ) + +TCP-info = Address-literal / ( Domain FWS Address-literal ) + ; Information derived by server from TCP connection + ; not client EHLO. + +Opt-info = [Via] [With] [ID] [For] + +Via = "VIA" FWS Link CFWS + +With = "WITH" FWS Protocol CFWS + +ID = "ID" FWS String / msg-id CFWS + +For = "FOR" FWS 1*( Path / Mailbox ) CFWS + +Link = "TCP" / Addtl-Link +Addtl-Link = Atom + ; Additional standard names for links are registered with the + ; Internet Assigned Numbers Authority (IANA). "Via" is + ; primarily of value with non-Internet transports. SMTP + + + +Klensin Standards Track [Page 52] + +RFC 2821 Simple Mail Transfer Protocol April 2001 + + + ; servers SHOULD NOT use unregistered names. +Protocol = "ESMTP" / "SMTP" / Attdl-Protocol +Attdl-Protocol = Atom + ; Additional standard names for protocols are registered with the + ; Internet Assigned Numbers Authority (IANA). SMTP servers + ; SHOULD NOT use unregistered names. + +4.5 Additional Implementation Issues + +4.5.1 Minimum Implementation + + In order to make SMTP workable, the following minimum implementation + is required for all receivers. The following commands MUST be + supported to conform to this specification: + + EHLO + HELO + MAIL + RCPT + DATA + RSET + NOOP + QUIT + VRFY + + Any system that includes an SMTP server supporting mail relaying or + delivery MUST support the reserved mailbox "postmaster" as a case- + insensitive local name. This postmaster address is not strictly + necessary if the server always returns 554 on connection opening (as + described in section 3.1). The requirement to accept mail for + postmaster implies that RCPT commands which specify a mailbox for + postmaster at any of the domains for which the SMTP server provides + mail service, as well as the special case of "RCPT TO:" + (with no domain specification), MUST be supported. + + SMTP systems are expected to make every reasonable effort to accept + mail directed to Postmaster from any other system on the Internet. + In extreme cases --such as to contain a denial of service attack or + other breach of security-- an SMTP server may block mail directed to + Postmaster. However, such arrangements SHOULD be narrowly tailored + so as to avoid blocking messages which are not part of such attacks. + +4.5.2 Transparency + + Without some provision for data transparency, the character sequence + "." ends the mail text and cannot be sent by the user. + In general, users are not aware of such "forbidden" sequences. To + + + + +Klensin Standards Track [Page 53] + +RFC 2821 Simple Mail Transfer Protocol April 2001 + + + allow all user composed text to be transmitted transparently, the + following procedures are used: + + - Before sending a line of mail text, the SMTP client checks the + first character of the line. If it is a period, one additional + period is inserted at the beginning of the line. + + - When a line of mail text is received by the SMTP server, it checks + the line. If the line is composed of a single period, it is + treated as the end of mail indicator. If the first character is a + period and there are other characters on the line, the first + character is deleted. + + The mail data may contain any of the 128 ASCII characters. All + characters are to be delivered to the recipient's mailbox, including + spaces, vertical and horizontal tabs, and other control characters. + If the transmission channel provides an 8-bit byte (octet) data + stream, the 7-bit ASCII codes are transmitted right justified in the + octets, with the high order bits cleared to zero. See 3.7 for + special treatment of these conditions in SMTP systems serving a relay + function. + + In some systems it may be necessary to transform the data as it is + received and stored. This may be necessary for hosts that use a + different character set than ASCII as their local character set, that + store data in records rather than strings, or which use special + character sequences as delimiters inside mailboxes. If such + transformations are necessary, they MUST be reversible, especially if + they are applied to mail being relayed. + +4.5.3 Sizes and Timeouts + +4.5.3.1 Size limits and minimums + + There are several objects that have required minimum/maximum sizes. + Every implementation MUST be able to receive objects of at least + these sizes. Objects larger than these sizes SHOULD be avoided when + possible. However, some Internet mail constructs such as encoded + X.400 addresses [16] will often require larger objects: clients MAY + attempt to transmit these, but MUST be prepared for a server to + reject them if they cannot be handled by it. To the maximum extent + possible, implementation techniques which impose no limits on the + length of these objects should be used. + + local-part + The maximum total length of a user name or other local-part is 64 + characters. + + + + +Klensin Standards Track [Page 54] + +RFC 2821 Simple Mail Transfer Protocol April 2001 + + + domain + The maximum total length of a domain name or number is 255 + characters. + + path + The maximum total length of a reverse-path or forward-path is 256 + characters (including the punctuation and element separators). + + command line + The maximum total length of a command line including the command + word and the is 512 characters. SMTP extensions may be + used to increase this limit. + + reply line + The maximum total length of a reply line including the reply code + and the is 512 characters. More information may be + conveyed through multiple-line replies. + + text line + The maximum total length of a text line including the is + 1000 characters (not counting the leading dot duplicated for + transparency). This number may be increased by the use of SMTP + Service Extensions. + + message content + The maximum total length of a message content (including any + message headers as well as the message body) MUST BE at least 64K + octets. Since the introduction of Internet standards for + multimedia mail [12], message lengths on the Internet have grown + dramatically, and message size restrictions should be avoided if + at all possible. SMTP server systems that must impose + restrictions SHOULD implement the "SIZE" service extension [18], + and SMTP client systems that will send large messages SHOULD + utilize it when possible. + + recipients buffer + The minimum total number of recipients that must be buffered is + 100 recipients. Rejection of messages (for excessive recipients) + with fewer than 100 RCPT commands is a violation of this + specification. The general principle that relaying SMTP servers + MUST NOT, and delivery SMTP servers SHOULD NOT, perform validation + tests on message headers suggests that rejecting a message based + on the total number of recipients shown in header fields is to be + discouraged. A server which imposes a limit on the number of + recipients MUST behave in an orderly fashion, such as to reject + additional addresses over its limit rather than silently + discarding addresses previously accepted. A client that needs to + + + + +Klensin Standards Track [Page 55] + +RFC 2821 Simple Mail Transfer Protocol April 2001 + + + deliver a message containing over 100 RCPT commands SHOULD be + prepared to transmit in 100-recipient "chunks" if the server + declines to accept more than 100 recipients in a single message. + + Errors due to exceeding these limits may be reported by using the + reply codes. Some examples of reply codes are: + + 500 Line too long. + or + 501 Path too long + or + 452 Too many recipients (see below) + or + 552 Too much mail data. + + RFC 821 [30] incorrectly listed the error where an SMTP server + exhausts its implementation limit on the number of RCPT commands + ("too many recipients") as having reply code 552. The correct reply + code for this condition is 452. Clients SHOULD treat a 552 code in + this case as a temporary, rather than permanent, failure so the logic + below works. + + When a conforming SMTP server encounters this condition, it has at + least 100 successful RCPT commands in its recipients buffer. If the + server is able to accept the message, then at least these 100 + addresses will be removed from the SMTP client's queue. When the + client attempts retransmission of those addresses which received 452 + responses, at least 100 of these will be able to fit in the SMTP + server's recipients buffer. Each retransmission attempt which is + able to deliver anything will be able to dispose of at least 100 of + these recipients. + + If an SMTP server has an implementation limit on the number of RCPT + commands and this limit is exhausted, it MUST use a response code of + 452 (but the client SHOULD also be prepared for a 552, as noted + above). If the server has a configured site-policy limitation on the + number of RCPT commands, it MAY instead use a 5XX response code. + This would be most appropriate if the policy limitation was intended + to apply if the total recipient count for a particular message body + were enforced even if that message body was sent in multiple mail + transactions. + +4.5.3.2 Timeouts + + An SMTP client MUST provide a timeout mechanism. It MUST use per- + command timeouts rather than somehow trying to time the entire mail + transaction. Timeouts SHOULD be easily reconfigurable, preferably + without recompiling the SMTP code. To implement this, a timer is set + + + +Klensin Standards Track [Page 56] + +RFC 2821 Simple Mail Transfer Protocol April 2001 + + + for each SMTP command and for each buffer of the data transfer. The + latter means that the overall timeout is inherently proportional to + the size of the message. + + Based on extensive experience with busy mail-relay hosts, the minimum + per-command timeout values SHOULD be as follows: + + Initial 220 Message: 5 minutes + An SMTP client process needs to distinguish between a failed TCP + connection and a delay in receiving the initial 220 greeting + message. Many SMTP servers accept a TCP connection but delay + delivery of the 220 message until their system load permits more + mail to be processed. + + MAIL Command: 5 minutes + + RCPT Command: 5 minutes + A longer timeout is required if processing of mailing lists and + aliases is not deferred until after the message was accepted. + + DATA Initiation: 2 minutes + This is while awaiting the "354 Start Input" reply to a DATA + command. + + Data Block: 3 minutes + This is while awaiting the completion of each TCP SEND call + transmitting a chunk of data. + + DATA Termination: 10 minutes. + This is while awaiting the "250 OK" reply. When the receiver gets + the final period terminating the message data, it typically + performs processing to deliver the message to a user mailbox. A + spurious timeout at this point would be very wasteful and would + typically result in delivery of multiple copies of the message, + since it has been successfully sent and the server has accepted + responsibility for delivery. See section 6.1 for additional + discussion. + + An SMTP server SHOULD have a timeout of at least 5 minutes while it + is awaiting the next command from the sender. + +4.5.4 Retry Strategies + + The common structure of a host SMTP implementation includes user + mailboxes, one or more areas for queuing messages in transit, and one + or more daemon processes for sending and receiving mail. The exact + structure will vary depending on the needs of the users on the host + + + + +Klensin Standards Track [Page 57] + +RFC 2821 Simple Mail Transfer Protocol April 2001 + + + and the number and size of mailing lists supported by the host. We + describe several optimizations that have proved helpful, particularly + for mailers supporting high traffic levels. + + Any queuing strategy MUST include timeouts on all activities on a + per-command basis. A queuing strategy MUST NOT send error messages + in response to error messages under any circumstances. + +4.5.4.1 Sending Strategy + + The general model for an SMTP client is one or more processes that + periodically attempt to transmit outgoing mail. In a typical system, + the program that composes a message has some method for requesting + immediate attention for a new piece of outgoing mail, while mail that + cannot be transmitted immediately MUST be queued and periodically + retried by the sender. A mail queue entry will include not only the + message itself but also the envelope information. + + The sender MUST delay retrying a particular destination after one + attempt has failed. In general, the retry interval SHOULD be at + least 30 minutes; however, more sophisticated and variable strategies + will be beneficial when the SMTP client can determine the reason for + non-delivery. + + Retries continue until the message is transmitted or the sender gives + up; the give-up time generally needs to be at least 4-5 days. The + parameters to the retry algorithm MUST be configurable. + + A client SHOULD keep a list of hosts it cannot reach and + corresponding connection timeouts, rather than just retrying queued + mail items. + + Experience suggests that failures are typically transient (the target + system or its connection has crashed), favoring a policy of two + connection attempts in the first hour the message is in the queue, + and then backing off to one every two or three hours. + + The SMTP client can shorten the queuing delay in cooperation with the + SMTP server. For example, if mail is received from a particular + address, it is likely that mail queued for that host can now be sent. + Application of this principle may, in many cases, eliminate the + requirement for an explicit "send queues now" function such as ETRN + [9]. + + The strategy may be further modified as a result of multiple + addresses per host (see below) to optimize delivery time vs. resource + usage. + + + + +Klensin Standards Track [Page 58] + +RFC 2821 Simple Mail Transfer Protocol April 2001 + + + An SMTP client may have a large queue of messages for each + unavailable destination host. If all of these messages were retried + in every retry cycle, there would be excessive Internet overhead and + the sending system would be blocked for a long period. Note that an + SMTP client can generally determine that a delivery attempt has + failed only after a timeout of several minutes and even a one-minute + timeout per connection will result in a very large delay if retries + are repeated for dozens, or even hundreds, of queued messages to the + same host. + + At the same time, SMTP clients SHOULD use great care in caching + negative responses from servers. In an extreme case, if EHLO is + issued multiple times during the same SMTP connection, different + answers may be returned by the server. More significantly, 5yz + responses to the MAIL command MUST NOT be cached. + + When a mail message is to be delivered to multiple recipients, and + the SMTP server to which a copy of the message is to be sent is the + same for multiple recipients, then only one copy of the message + SHOULD be transmitted. That is, the SMTP client SHOULD use the + command sequence: MAIL, RCPT, RCPT,... RCPT, DATA instead of the + sequence: MAIL, RCPT, DATA, ..., MAIL, RCPT, DATA. However, if there + are very many addresses, a limit on the number of RCPT commands per + MAIL command MAY be imposed. Implementation of this efficiency + feature is strongly encouraged. + + Similarly, to achieve timely delivery, the SMTP client MAY support + multiple concurrent outgoing mail transactions. However, some limit + may be appropriate to protect the host from devoting all its + resources to mail. + +4.5.4.2 Receiving Strategy + + The SMTP server SHOULD attempt to keep a pending listen on the SMTP + port at all times. This requires the support of multiple incoming + TCP connections for SMTP. Some limit MAY be imposed but servers that + cannot handle more than one SMTP transaction at a time are not in + conformance with the intent of this specification. + + As discussed above, when the SMTP server receives mail from a + particular host address, it could activate its own SMTP queuing + mechanisms to retry any mail pending for that host address. + +4.5.5 Messages with a null reverse-path + + There are several types of notification messages which are required + by existing and proposed standards to be sent with a null reverse + path, namely non-delivery notifications as discussed in section 3.7, + + + +Klensin Standards Track [Page 59] + +RFC 2821 Simple Mail Transfer Protocol April 2001 + + + other kinds of Delivery Status Notifications (DSNs) [24], and also + Message Disposition Notifications (MDNs) [10]. All of these kinds of + messages are notifications about a previous message, and they are + sent to the reverse-path of the previous mail message. (If the + delivery of such a notification message fails, that usually indicates + a problem with the mail system of the host to which the notification + message is addressed. For this reason, at some hosts the MTA is set + up to forward such failed notification messages to someone who is + able to fix problems with the mail system, e.g., via the postmaster + alias.) + + All other types of messages (i.e., any message which is not required + by a standards-track RFC to have a null reverse-path) SHOULD be sent + with with a valid, non-null reverse-path. + + Implementors of automated email processors should be careful to make + sure that the various kinds of messages with null reverse-path are + handled correctly, in particular such systems SHOULD NOT reply to + messages with null reverse-path. + +5. Address Resolution and Mail Handling + + Once an SMTP client lexically identifies a domain to which mail will + be delivered for processing (as described in sections 3.6 and 3.7), a + DNS lookup MUST be performed to resolve the domain name [22]. The + names are expected to be fully-qualified domain names (FQDNs): + mechanisms for inferring FQDNs from partial names or local aliases + are outside of this specification and, due to a history of problems, + are generally discouraged. The lookup first attempts to locate an MX + record associated with the name. If a CNAME record is found instead, + the resulting name is processed as if it were the initial name. If + no MX records are found, but an A RR is found, the A RR is treated as + if it was associated with an implicit MX RR, with a preference of 0, + pointing to that host. If one or more MX RRs are found for a given + name, SMTP systems MUST NOT utilize any A RRs associated with that + name unless they are located using the MX RRs; the "implicit MX" rule + above applies only if there are no MX records present. If MX records + are present, but none of them are usable, this situation MUST be + reported as an error. + + When the lookup succeeds, the mapping can result in a list of + alternative delivery addresses rather than a single address, because + of multiple MX records, multihoming, or both. To provide reliable + mail transmission, the SMTP client MUST be able to try (and retry) + each of the relevant addresses in this list in order, until a + delivery attempt succeeds. However, there MAY also be a configurable + limit on the number of alternate addresses that can be tried. In any + case, the SMTP client SHOULD try at least two addresses. + + + +Klensin Standards Track [Page 60] + +RFC 2821 Simple Mail Transfer Protocol April 2001 + + + Two types of information is used to rank the host addresses: multiple + MX records, and multihomed hosts. + + Multiple MX records contain a preference indication that MUST be used + in sorting (see below). Lower numbers are more preferred than higher + ones. If there are multiple destinations with the same preference + and there is no clear reason to favor one (e.g., by recognition of an + easily-reached address), then the sender-SMTP MUST randomize them to + spread the load across multiple mail exchangers for a specific + organization. + + The destination host (perhaps taken from the preferred MX record) may + be multihomed, in which case the domain name resolver will return a + list of alternative IP addresses. It is the responsibility of the + domain name resolver interface to have ordered this list by + decreasing preference if necessary, and SMTP MUST try them in the + order presented. + + Although the capability to try multiple alternative addresses is + required, specific installations may want to limit or disable the use + of alternative addresses. The question of whether a sender should + attempt retries using the different addresses of a multihomed host + has been controversial. The main argument for using the multiple + addresses is that it maximizes the probability of timely delivery, + and indeed sometimes the probability of any delivery; the counter- + argument is that it may result in unnecessary resource use. Note + that resource use is also strongly determined by the sending strategy + discussed in section 4.5.4.1. + + If an SMTP server receives a message with a destination for which it + is a designated Mail eXchanger, it MAY relay the message (potentially + after having rewritten the MAIL FROM and/or RCPT TO addresses), make + final delivery of the message, or hand it off using some mechanism + outside the SMTP-provided transport environment. Of course, neither + of the latter require that the list of MX records be examined + further. + + If it determines that it should relay the message without rewriting + the address, it MUST sort the MX records to determine candidates for + delivery. The records are first ordered by preference, with the + lowest-numbered records being most preferred. The relay host MUST + then inspect the list for any of the names or addresses by which it + might be known in mail transactions. If a matching record is found, + all records at that preference level and higher-numbered ones MUST be + discarded from consideration. If there are no records left at that + point, it is an error condition, and the message MUST be returned as + undeliverable. If records do remain, they SHOULD be tried, best + preference first, as described above. + + + +Klensin Standards Track [Page 61] + +RFC 2821 Simple Mail Transfer Protocol April 2001 + + +6. Problem Detection and Handling + +6.1 Reliable Delivery and Replies by Email + + When the receiver-SMTP accepts a piece of mail (by sending a "250 OK" + message in response to DATA), it is accepting responsibility for + delivering or relaying the message. It must take this responsibility + seriously. It MUST NOT lose the message for frivolous reasons, such + as because the host later crashes or because of a predictable + resource shortage. + + If there is a delivery failure after acceptance of a message, the + receiver-SMTP MUST formulate and mail a notification message. This + notification MUST be sent using a null ("<>") reverse path in the + envelope. The recipient of this notification MUST be the address + from the envelope return path (or the Return-Path: line). However, + if this address is null ("<>"), the receiver-SMTP MUST NOT send a + notification. Obviously, nothing in this section can or should + prohibit local decisions (i.e., as part of the same system + environment as the receiver-SMTP) to log or otherwise transmit + information about null address events locally if that is desired. If + the address is an explicit source route, it MUST be stripped down to + its final hop. + + For example, suppose that an error notification must be sent for a + message that arrived with: + + MAIL FROM:<@a,@b:user@d> + + The notification message MUST be sent using: + + RCPT TO: + + Some delivery failures after the message is accepted by SMTP will be + unavoidable. For example, it may be impossible for the receiving + SMTP server to validate all the delivery addresses in RCPT command(s) + due to a "soft" domain system error, because the target is a mailing + list (see earlier discussion of RCPT), or because the server is + acting as a relay and has no immediate access to the delivering + system. + + To avoid receiving duplicate messages as the result of timeouts, a + receiver-SMTP MUST seek to minimize the time required to respond to + the final . end of data indicator. See RFC 1047 [28] for + a discussion of this problem. + + + + + + +Klensin Standards Track [Page 62] + +RFC 2821 Simple Mail Transfer Protocol April 2001 + + +6.2 Loop Detection + + Simple counting of the number of "Received:" headers in a message has + proven to be an effective, although rarely optimal, method of + detecting loops in mail systems. SMTP servers using this technique + SHOULD use a large rejection threshold, normally at least 100 + Received entries. Whatever mechanisms are used, servers MUST contain + provisions for detecting and stopping trivial loops. + +6.3 Compensating for Irregularities + + Unfortunately, variations, creative interpretations, and outright + violations of Internet mail protocols do occur; some would suggest + that they occur quite frequently. The debate as to whether a well- + behaved SMTP receiver or relay should reject a malformed message, + attempt to pass it on unchanged, or attempt to repair it to increase + the odds of successful delivery (or subsequent reply) began almost + with the dawn of structured network mail and shows no signs of + abating. Advocates of rejection claim that attempted repairs are + rarely completely adequate and that rejection of bad messages is the + only way to get the offending software repaired. Advocates of + "repair" or "deliver no matter what" argue that users prefer that + mail go through it if at all possible and that there are significant + market pressures in that direction. In practice, these market + pressures may be more important to particular vendors than strict + conformance to the standards, regardless of the preference of the + actual developers. + + The problems associated with ill-formed messages were exacerbated by + the introduction of the split-UA mail reading protocols [3, 26, 5, + 21]. These protocols have encouraged the use of SMTP as a posting + protocol, and SMTP servers as relay systems for these client hosts + (which are often only intermittently connected to the Internet). + Historically, many of those client machines lacked some of the + mechanisms and information assumed by SMTP (and indeed, by the mail + format protocol [7]). Some could not keep adequate track of time; + others had no concept of time zones; still others could not identify + their own names or addresses; and, of course, none could satisfy the + assumptions that underlay RFC 822's conception of authenticated + addresses. + + In response to these weak SMTP clients, many SMTP systems now + complete messages that are delivered to them in incomplete or + incorrect form. This strategy is generally considered appropriate + when the server can identify or authenticate the client, and there + are prior agreements between them. By contrast, there is at best + great concern about fixes applied by a relay or delivery SMTP server + that has little or no knowledge of the user or client machine. + + + +Klensin Standards Track [Page 63] + +RFC 2821 Simple Mail Transfer Protocol April 2001 + + + The following changes to a message being processed MAY be applied + when necessary by an originating SMTP server, or one used as the + target of SMTP as an initial posting protocol: + + - Addition of a message-id field when none appears + + - Addition of a date, time or time zone when none appears + + - Correction of addresses to proper FQDN format + + The less information the server has about the client, the less likely + these changes are to be correct and the more caution and conservatism + should be applied when considering whether or not to perform fixes + and how. These changes MUST NOT be applied by an SMTP server that + provides an intermediate relay function. + + In all cases, properly-operating clients supplying correct + information are preferred to corrections by the SMTP server. In all + cases, documentation of actions performed by the servers (in trace + fields and/or header comments) is strongly encouraged. + +7. Security Considerations + +7.1 Mail Security and Spoofing + + SMTP mail is inherently insecure in that it is feasible for even + fairly casual users to negotiate directly with receiving and relaying + SMTP servers and create messages that will trick a naive recipient + into believing that they came from somewhere else. Constructing such + a message so that the "spoofed" behavior cannot be detected by an + expert is somewhat more difficult, but not sufficiently so as to be a + deterrent to someone who is determined and knowledgeable. + Consequently, as knowledge of Internet mail increases, so does the + knowledge that SMTP mail inherently cannot be authenticated, or + integrity checks provided, at the transport level. Real mail + security lies only in end-to-end methods involving the message + bodies, such as those which use digital signatures (see [14] and, + e.g., PGP [4] or S/MIME [31]). + + Various protocol extensions and configuration options that provide + authentication at the transport level (e.g., from an SMTP client to + an SMTP server) improve somewhat on the traditional situation + described above. However, unless they are accompanied by careful + handoffs of responsibility in a carefully-designed trust environment, + they remain inherently weaker than end-to-end mechanisms which use + digitally signed messages rather than depending on the integrity of + the transport system. + + + + +Klensin Standards Track [Page 64] + +RFC 2821 Simple Mail Transfer Protocol April 2001 + + + Efforts to make it more difficult for users to set envelope return + path and header "From" fields to point to valid addresses other than + their own are largely misguided: they frustrate legitimate + applications in which mail is sent by one user on behalf of another + or in which error (or normal) replies should be directed to a special + address. (Systems that provide convenient ways for users to alter + these fields on a per-message basis should attempt to establish a + primary and permanent mailbox address for the user so that Sender + fields within the message data can be generated sensibly.) + + This specification does not further address the authentication issues + associated with SMTP other than to advocate that useful functionality + not be disabled in the hope of providing some small margin of + protection against an ignorant user who is trying to fake mail. + +7.2 "Blind" Copies + + Addresses that do not appear in the message headers may appear in the + RCPT commands to an SMTP server for a number of reasons. The two + most common involve the use of a mailing address as a "list exploder" + (a single address that resolves into multiple addresses) and the + appearance of "blind copies". Especially when more than one RCPT + command is present, and in order to avoid defeating some of the + purpose of these mechanisms, SMTP clients and servers SHOULD NOT copy + the full set of RCPT command arguments into the headers, either as + part of trace headers or as informational or private-extension + headers. Since this rule is often violated in practice, and cannot + be enforced, sending SMTP systems that are aware of "bcc" use MAY + find it helpful to send each blind copy as a separate message + transaction containing only a single RCPT command. + + There is no inherent relationship between either "reverse" (from + MAIL, SAML, etc., commands) or "forward" (RCPT) addresses in the SMTP + transaction ("envelope") and the addresses in the headers. Receiving + systems SHOULD NOT attempt to deduce such relationships and use them + to alter the headers of the message for delivery. The popular + "Apparently-to" header is a violation of this principle as well as a + common source of unintended information disclosure and SHOULD NOT be + used. + +7.3 VRFY, EXPN, and Security + + As discussed in section 3.5, individual sites may want to disable + either or both of VRFY or EXPN for security reasons. As a corollary + to the above, implementations that permit this MUST NOT appear to + have verified addresses that are not, in fact, verified. If a site + + + + + +Klensin Standards Track [Page 65] + +RFC 2821 Simple Mail Transfer Protocol April 2001 + + + disables these commands for security reasons, the SMTP server MUST + return a 252 response, rather than a code that could be confused with + successful or unsuccessful verification. + + Returning a 250 reply code with the address listed in the VRFY + command after having checked it only for syntax violates this rule. + Of course, an implementation that "supports" VRFY by always returning + 550 whether or not the address is valid is equally not in + conformance. + + Within the last few years, the contents of mailing lists have become + popular as an address information source for so-called "spammers." + The use of EXPN to "harvest" addresses has increased as list + administrators have installed protections against inappropriate uses + of the lists themselves. Implementations SHOULD still provide + support for EXPN, but sites SHOULD carefully evaluate the tradeoffs. + As authentication mechanisms are introduced into SMTP, some sites may + choose to make EXPN available only to authenticated requestors. + +7.4 Information Disclosure in Announcements + + There has been an ongoing debate about the tradeoffs between the + debugging advantages of announcing server type and version (and, + sometimes, even server domain name) in the greeting response or in + response to the HELP command and the disadvantages of exposing + information that might be useful in a potential hostile attack. The + utility of the debugging information is beyond doubt. Those who + argue for making it available point out that it is far better to + actually secure an SMTP server rather than hope that trying to + conceal known vulnerabilities by hiding the server's precise identity + will provide more protection. Sites are encouraged to evaluate the + tradeoff with that issue in mind; implementations are strongly + encouraged to minimally provide for making type and version + information available in some way to other network hosts. + +7.5 Information Disclosure in Trace Fields + + In some circumstances, such as when mail originates from within a LAN + whose hosts are not directly on the public Internet, trace + ("Received") fields produced in conformance with this specification + may disclose host names and similar information that would not + normally be available. This ordinarily does not pose a problem, but + sites with special concerns about name disclosure should be aware of + it. Also, the optional FOR clause should be supplied with caution or + not at all when multiple recipients are involved lest it + inadvertently disclose the identities of "blind copy" recipients to + others. + + + + +Klensin Standards Track [Page 66] + +RFC 2821 Simple Mail Transfer Protocol April 2001 + + +7.6 Information Disclosure in Message Forwarding + + As discussed in section 3.4, use of the 251 or 551 reply codes to + identify the replacement address associated with a mailbox may + inadvertently disclose sensitive information. Sites that are + concerned about those issues should ensure that they select and + configure servers appropriately. + +7.7 Scope of Operation of SMTP Servers + + It is a well-established principle that an SMTP server may refuse to + accept mail for any operational or technical reason that makes sense + to the site providing the server. However, cooperation among sites + and installations makes the Internet possible. If sites take + excessive advantage of the right to reject traffic, the ubiquity of + email availability (one of the strengths of the Internet) will be + threatened; considerable care should be taken and balance maintained + if a site decides to be selective about the traffic it will accept + and process. + + In recent years, use of the relay function through arbitrary sites + has been used as part of hostile efforts to hide the actual origins + of mail. Some sites have decided to limit the use of the relay + function to known or identifiable sources, and implementations SHOULD + provide the capability to perform this type of filtering. When mail + is rejected for these or other policy reasons, a 550 code SHOULD be + used in response to EHLO, MAIL, or RCPT as appropriate. + +8. IANA Considerations + + IANA will maintain three registries in support of this specification. + The first consists of SMTP service extensions with the associated + keywords, and, as needed, parameters and verbs. As specified in + section 2.2.2, no entry may be made in this registry that starts in + an "X". Entries may be made only for service extensions (and + associated keywords, parameters, or verbs) that are defined in + standards-track or experimental RFCs specifically approved by the + IESG for this purpose. + + The second registry consists of "tags" that identify forms of domain + literals other than those for IPv4 addresses (specified in RFC 821 + and in this document) and IPv6 addresses (specified in this + document). Additional literal types require standardization before + being used; none are anticipated at this time. + + The third, established by RFC 821 and renewed by this specification, + is a registry of link and protocol identifiers to be used with the + "via" and "with" subclauses of the time stamp ("Received: header") + + + +Klensin Standards Track [Page 67] + +RFC 2821 Simple Mail Transfer Protocol April 2001 + + + described in section 4.4. Link and protocol identifiers in addition + to those specified in this document may be registered only by + standardization or by way of an RFC-documented, IESG-approved, + Experimental protocol extension. + +9. References + + [1] American National Standards Institute (formerly United States of + America Standards Institute), X3.4, 1968, "USA Code for + Information Interchange". ANSI X3.4-1968 has been replaced by + newer versions with slight modifications, but the 1968 version + remains definitive for the Internet. + + [2] Braden, R., "Requirements for Internet hosts - application and + support", STD 3, RFC 1123, October 1989. + + [3] Butler, M., Chase, D., Goldberger, J., Postel, J. and J. + Reynolds, "Post Office Protocol - version 2", RFC 937, February + 1985. + + [4] Callas, J., Donnerhacke, L., Finney, H. and R. Thayer, "OpenPGP + Message Format", RFC 2440, November 1998. + + [5] Crispin, M., "Interactive Mail Access Protocol - Version 2", RFC + 1176, August 1990. + + [6] Crispin, M., "Internet Message Access Protocol - Version 4", RFC + 2060, December 1996. + + [7] Crocker, D., "Standard for the Format of ARPA Internet Text + Messages", RFC 822, August 1982. + + [8] Crocker, D. and P. Overell, Eds., "Augmented BNF for Syntax + Specifications: ABNF", RFC 2234, November 1997. + + [9] De Winter, J., "SMTP Service Extension for Remote Message Queue + Starting", RFC 1985, August 1996. + + [10] Fajman, R., "An Extensible Message Format for Message + Disposition Notifications", RFC 2298, March 1998. + + [11] Freed, N, "Behavior of and Requirements for Internet Firewalls", + RFC 2979, October 2000. + + [12] Freed, N. and N. Borenstein, "Multipurpose Internet Mail + Extensions (MIME) Part One: Format of Internet Message Bodies", + RFC 2045, December 1996. + + + + +Klensin Standards Track [Page 68] + +RFC 2821 Simple Mail Transfer Protocol April 2001 + + + [13] Freed, N., "SMTP Service Extension for Command Pipelining", RFC + 2920, September 2000. + + [14] Galvin, J., Murphy, S., Crocker, S. and N. Freed, "Security + Multiparts for MIME: Multipart/Signed and Multipart/Encrypted", + RFC 1847, October 1995. + + [15] Gellens, R. and J. Klensin, "Message Submission", RFC 2476, + December 1998. + + [16] Kille, S., "Mapping between X.400 and RFC822/MIME", RFC 2156, + January 1998. + + [17] Hinden, R and S. Deering, Eds. "IP Version 6 Addressing + Architecture", RFC 2373, July 1998. + + [18] Klensin, J., Freed, N. and K. Moore, "SMTP Service Extension for + Message Size Declaration", STD 10, RFC 1870, November 1995. + + [19] Klensin, J., Freed, N., Rose, M., Stefferud, E. and D. Crocker, + "SMTP Service Extensions", STD 10, RFC 1869, November 1995. + + [20] Klensin, J., Freed, N., Rose, M., Stefferud, E. and D. Crocker, + "SMTP Service Extension for 8bit-MIMEtransport", RFC 1652, July + 1994. + + [21] Lambert, M., "PCMAIL: A distributed mail system for personal + computers", RFC 1056, July 1988. + + [22] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, November 1987. + + Mockapetris, P., "Domain names - concepts and facilities", STD + 13, RFC 1034, November 1987. + + [23] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part + Three: Message Header Extensions for Non-ASCII Text", RFC 2047, + December 1996. + + [24] Moore, K., "SMTP Service Extension for Delivery Status + Notifications", RFC 1891, January 1996. + + [25] Moore, K., and G. Vaudreuil, "An Extensible Message Format for + Delivery Status Notifications", RFC 1894, January 1996. + + [26] Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD + 53, RFC 1939, May 1996. + + + + +Klensin Standards Track [Page 69] + +RFC 2821 Simple Mail Transfer Protocol April 2001 + + + [27] Partridge, C., "Mail routing and the domain system", RFC 974, + January 1986. + + [28] Partridge, C., "Duplicate messages and SMTP", RFC 1047, February + 1988. + + [29] Postel, J., ed., "Transmission Control Protocol - DARPA Internet + Program Protocol Specification", STD 7, RFC 793, September 1981. + + [30] Postel, J., "Simple Mail Transfer Protocol", RFC 821, August + 1982. + + [31] Ramsdell, B., Ed., "S/MIME Version 3 Message Specification", RFC + 2633, June 1999. + + [32] Resnick, P., Ed., "Internet Message Format", RFC 2822, April + 2001. + + [33] Vaudreuil, G., "SMTP Service Extensions for Transmission of + Large and Binary MIME Messages", RFC 1830, August 1995. + + [34] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 1893, + January 1996. + +10. Editor's Address + + John C. Klensin + AT&T Laboratories + 99 Bedford St + Boston, MA 02111 USA + + Phone: 617-574-3076 + EMail: klensin@research.att.com + +11. Acknowledgments + + Many people worked long and hard on the many iterations of this + document. There was wide-ranging debate in the IETF DRUMS Working + Group, both on its mailing list and in face to face discussions, + about many technical issues and the role of a revised standard for + Internet mail transport, and many contributors helped form the + wording in this specification. The hundreds of participants in the + many discussions since RFC 821 was produced are too numerous to + mention, but they all helped this document become what it is. + + + + + + + +Klensin Standards Track [Page 70] + +RFC 2821 Simple Mail Transfer Protocol April 2001 + + +APPENDICES + +A. TCP Transport Service + + The TCP connection supports the transmission of 8-bit bytes. The + SMTP data is 7-bit ASCII characters. Each character is transmitted + as an 8-bit byte with the high-order bit cleared to zero. Service + extensions may modify this rule to permit transmission of full 8-bit + data bytes as part of the message body, but not in SMTP commands or + responses. + +B. Generating SMTP Commands from RFC 822 Headers + + Some systems use RFC 822 headers (only) in a mail submission + protocol, or otherwise generate SMTP commands from RFC 822 headers + when such a message is handed to an MTA from a UA. While the MTA-UA + protocol is a private matter, not covered by any Internet Standard, + there are problems with this approach. For example, there have been + repeated problems with proper handling of "bcc" copies and + redistribution lists when information that conceptually belongs to a + mail envelopes is not separated early in processing from header + information (and kept separate). + + It is recommended that the UA provide its initial ("submission + client") MTA with an envelope separate from the message itself. + However, if the envelope is not supplied, SMTP commands SHOULD be + generated as follows: + + 1. Each recipient address from a TO, CC, or BCC header field SHOULD + be copied to a RCPT command (generating multiple message copies if + that is required for queuing or delivery). This includes any + addresses listed in a RFC 822 "group". Any BCC fields SHOULD then + be removed from the headers. Once this process is completed, the + remaining headers SHOULD be checked to verify that at least one + To:, Cc:, or Bcc: header remains. If none do, then a bcc: header + with no additional information SHOULD be inserted as specified in + [32]. + + 2. The return address in the MAIL command SHOULD, if possible, be + derived from the system's identity for the submitting (local) + user, and the "From:" header field otherwise. If there is a + system identity available, it SHOULD also be copied to the Sender + header field if it is different from the address in the From + header field. (Any Sender field that was already there SHOULD be + removed.) Systems may provide a way for submitters to override + the envelope return address, but may want to restrict its use to + privileged users. This will not prevent mail forgery, but may + lessen its incidence; see section 7.1. + + + +Klensin Standards Track [Page 71] + +RFC 2821 Simple Mail Transfer Protocol April 2001 + + + When an MTA is being used in this way, it bears responsibility for + ensuring that the message being transmitted is valid. The mechanisms + for checking that validity, and for handling (or returning) messages + that are not valid at the time of arrival, are part of the MUA-MTA + interface and not covered by this specification. + + A submission protocol based on Standard RFC 822 information alone + MUST NOT be used to gateway a message from a foreign (non-SMTP) mail + system into an SMTP environment. Additional information to construct + an envelope must come from some source in the other environment, + whether supplemental headers or the foreign system's envelope. + + Attempts to gateway messages using only their header "to" and "cc" + fields have repeatedly caused mail loops and other behavior adverse + to the proper functioning of the Internet mail environment. These + problems have been especially common when the message originates from + an Internet mailing list and is distributed into the foreign + environment using envelope information. When these messages are then + processed by a header-only remailer, loops back to the Internet + environment (and the mailing list) are almost inevitable. + +C. Source Routes + + Historically, the was a reverse source routing list of + hosts and a source mailbox. The first host in the + SHOULD be the host sending the MAIL command. Similarly, the + may be a source routing lists of hosts and a + destination mailbox. However, in general, the SHOULD + contain only a mailbox and domain name, relying on the domain name + system to supply routing information if required. The use of source + routes is deprecated; while servers MUST be prepared to receive and + handle them as discussed in section 3.3 and F.2, clients SHOULD NOT + transmit them and this section was included only to provide context. + + For relay purposes, the forward-path may be a source route of the + form "@ONE,@TWO:JOE@THREE", where ONE, TWO, and THREE MUST BE fully- + qualified domain names. This form is used to emphasize the + distinction between an address and a route. The mailbox is an + absolute address, and the route is information about how to get + there. The two concepts should not be confused. + + If source routes are used, RFC 821 and the text below should be + consulted for the mechanisms for constructing and updating the + forward- and reverse-paths. + + + + + + + +Klensin Standards Track [Page 72] + +RFC 2821 Simple Mail Transfer Protocol April 2001 + + + The SMTP server transforms the command arguments by moving its own + identifier (its domain name or that of any domain for which it is + acting as a mail exchanger), if it appears, from the forward-path to + the beginning of the reverse-path. + + Notice that the forward-path and reverse-path appear in the SMTP + commands and replies, but not necessarily in the message. That is, + there is no need for these paths and especially this syntax to appear + in the "To:" , "From:", "CC:", etc. fields of the message header. + Conversely, SMTP servers MUST NOT derive final message delivery + information from message header fields. + + When the list of hosts is present, it is a "reverse" source route and + indicates that the mail was relayed through each host on the list + (the first host in the list was the most recent relay). This list is + used as a source route to return non-delivery notices to the sender. + As each relay host adds itself to the beginning of the list, it MUST + use its name as known in the transport environment to which it is + relaying the mail rather than that of the transport environment from + which the mail came (if they are different). + +D. Scenarios + + This section presents complete scenarios of several types of SMTP + sessions. In the examples, "C:" indicates what is said by the SMTP + client, and "S:" indicates what is said by the SMTP server. + +D.1 A Typical SMTP Transaction Scenario + + This SMTP example shows mail sent by Smith at host bar.com, to Jones, + Green, and Brown at host foo.com. Here we assume that host bar.com + contacts host foo.com directly. The mail is accepted for Jones and + Brown. Green does not have a mailbox at host foo.com. + + S: 220 foo.com Simple Mail Transfer Service Ready + C: EHLO bar.com + S: 250-foo.com greets bar.com + S: 250-8BITMIME + S: 250-SIZE + S: 250-DSN + S: 250 HELP + C: MAIL FROM: + S: 250 OK + C: RCPT TO: + S: 250 OK + C: RCPT TO: + S: 550 No such user here + C: RCPT TO: + + + +Klensin Standards Track [Page 73] + +RFC 2821 Simple Mail Transfer Protocol April 2001 + + + S: 250 OK + C: DATA + S: 354 Start mail input; end with . + C: Blah blah blah... + C: ...etc. etc. etc. + C: . + S: 250 OK + C: QUIT + S: 221 foo.com Service closing transmission channel + +D.2 Aborted SMTP Transaction Scenario + + S: 220 foo.com Simple Mail Transfer Service Ready + C: EHLO bar.com + S: 250-foo.com greets bar.com + S: 250-8BITMIME + S: 250-SIZE + S: 250-DSN + S: 250 HELP + C: MAIL FROM: + S: 250 OK + C: RCPT TO: + S: 250 OK + C: RCPT TO: + S: 550 No such user here + C: RSET + S: 250 OK + C: QUIT + S: 221 foo.com Service closing transmission channel + +D.3 Relayed Mail Scenario + + Step 1 -- Source Host to Relay Host + + S: 220 foo.com Simple Mail Transfer Service Ready + C: EHLO bar.com + S: 250-foo.com greets bar.com + S: 250-8BITMIME + S: 250-SIZE + S: 250-DSN + S: 250 HELP + C: MAIL FROM: + S: 250 OK + C: RCPT TO:<@foo.com:Jones@XYZ.COM> + S: 250 OK + C: DATA + S: 354 Start mail input; end with . + C: Date: Thu, 21 May 1998 05:33:29 -0700 + + + +Klensin Standards Track [Page 74] + +RFC 2821 Simple Mail Transfer Protocol April 2001 + + + C: From: John Q. Public + C: Subject: The Next Meeting of the Board + C: To: Jones@xyz.com + C: + C: Bill: + C: The next meeting of the board of directors will be + C: on Tuesday. + C: John. + C: . + S: 250 OK + C: QUIT + S: 221 foo.com Service closing transmission channel + + Step 2 -- Relay Host to Destination Host + + S: 220 xyz.com Simple Mail Transfer Service Ready + C: EHLO foo.com + S: 250 xyz.com is on the air + C: MAIL FROM:<@foo.com:JQP@bar.com> + S: 250 OK + C: RCPT TO: + S: 250 OK + C: DATA + S: 354 Start mail input; end with . + C: Received: from bar.com by foo.com ; Thu, 21 May 1998 + C: 05:33:29 -0700 + C: Date: Thu, 21 May 1998 05:33:22 -0700 + C: From: John Q. Public + C: Subject: The Next Meeting of the Board + C: To: Jones@xyz.com + C: + C: Bill: + C: The next meeting of the board of directors will be + C: on Tuesday. + C: John. + C: . + S: 250 OK + C: QUIT + S: 221 foo.com Service closing transmission channel + +D.4 Verifying and Sending Scenario + + S: 220 foo.com Simple Mail Transfer Service Ready + C: EHLO bar.com + S: 250-foo.com greets bar.com + S: 250-8BITMIME + S: 250-SIZE + S: 250-DSN + + + +Klensin Standards Track [Page 75] + +RFC 2821 Simple Mail Transfer Protocol April 2001 + + + S: 250-VRFY + S: 250 HELP + C: VRFY Crispin + S: 250 Mark Crispin + C: SEND FROM: + S: 250 OK + C: RCPT TO: + S: 250 OK + C: DATA + S: 354 Start mail input; end with . + C: Blah blah blah... + C: ...etc. etc. etc. + C: . + S: 250 OK + C: QUIT + S: 221 foo.com Service closing transmission channel + +E. Other Gateway Issues + + In general, gateways between the Internet and other mail systems + SHOULD attempt to preserve any layering semantics across the + boundaries between the two mail systems involved. Gateway- + translation approaches that attempt to take shortcuts by mapping, + (such as envelope information from one system to the message headers + or body of another) have generally proven to be inadequate in + important ways. Systems translating between environments that do not + support both envelopes and headers and Internet mail must be written + with the understanding that some information loss is almost + inevitable. + +F. Deprecated Features of RFC 821 + + A few features of RFC 821 have proven to be problematic and SHOULD + NOT be used in Internet mail. + +F.1 TURN + + This command, described in RFC 821, raises important security issues + since, in the absence of strong authentication of the host requesting + that the client and server switch roles, it can easily be used to + divert mail from its correct destination. Its use is deprecated; + SMTP systems SHOULD NOT use it unless the server can authenticate the + client. + + + + + + + + +Klensin Standards Track [Page 76] + +RFC 2821 Simple Mail Transfer Protocol April 2001 + + +F.2 Source Routing + + RFC 821 utilized the concept of explicit source routing to get mail + from one host to another via a series of relays. The requirement to + utilize source routes in regular mail traffic was eliminated by the + introduction of the domain name system "MX" record and the last + significant justification for them was eliminated by the + introduction, in RFC 1123, of a clear requirement that addresses + following an "@" must all be fully-qualified domain names. + Consequently, the only remaining justifications for the use of source + routes are support for very old SMTP clients or MUAs and in mail + system debugging. They can, however, still be useful in the latter + circumstance and for routing mail around serious, but temporary, + problems such as problems with the relevant DNS records. + + SMTP servers MUST continue to accept source route syntax as specified + in the main body of this document and in RFC 1123. They MAY, if + necessary, ignore the routes and utilize only the target domain in + the address. If they do utilize the source route, the message MUST + be sent to the first domain shown in the address. In particular, a + server MUST NOT guess at shortcuts within the source route. + + Clients SHOULD NOT utilize explicit source routing except under + unusual circumstances, such as debugging or potentially relaying + around firewall or mail system configuration errors. + +F.3 HELO + + As discussed in sections 3.1 and 4.1.1, EHLO is strongly preferred to + HELO when the server will accept the former. Servers must continue + to accept and process HELO in order to support older clients. + +F.4 #-literals + + RFC 821 provided for specifying an Internet address as a decimal + integer host number prefixed by a pound sign, "#". In practice, that + form has been obsolete since the introduction of TCP/IP. It is + deprecated and MUST NOT be used. + +F.5 Dates and Years + + When dates are inserted into messages by SMTP clients or servers + (e.g., in trace fields), four-digit years MUST BE used. Two-digit + years are deprecated; three-digit years were never permitted in the + Internet mail system. + + + + + + +Klensin Standards Track [Page 77] + +RFC 2821 Simple Mail Transfer Protocol April 2001 + + +F.6 Sending versus Mailing + + In addition to specifying a mechanism for delivering messages to + user's mailboxes, RFC 821 provided additional, optional, commands to + deliver messages directly to the user's terminal screen. These + commands (SEND, SAML, SOML) were rarely implemented, and changes in + workstation technology and the introduction of other protocols may + have rendered them obsolete even where they are implemented. + + Clients SHOULD NOT provide SEND, SAML, or SOML as services. Servers + MAY implement them. If they are implemented by servers, the + implementation model specified in RFC 821 MUST be used and the + command names MUST be published in the response to the EHLO command. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Klensin Standards Track [Page 78] + +RFC 2821 Simple Mail Transfer Protocol April 2001 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2001). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Klensin Standards Track [Page 79] + diff --git a/RFCs/rfc2822.txt b/RFCs/rfc2822.txt new file mode 100644 index 0000000..9f698f7 --- /dev/null +++ b/RFCs/rfc2822.txt @@ -0,0 +1,2859 @@ + + + + + + +Network Working Group P. Resnick, Editor +Request for Comments: 2822 QUALCOMM Incorporated +Obsoletes: 822 April 2001 +Category: Standards Track + + + Internet Message Format + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2001). All Rights Reserved. + +Abstract + + This standard specifies a syntax for text messages that are sent + between computer users, within the framework of "electronic mail" + messages. This standard supersedes the one specified in Request For + Comments (RFC) 822, "Standard for the Format of ARPA Internet Text + Messages", updating it to reflect current practice and incorporating + incremental changes that were specified in other RFCs. + +Table of Contents + + 1. Introduction ............................................... 3 + 1.1. Scope .................................................... 3 + 1.2. Notational conventions ................................... 4 + 1.2.1. Requirements notation .................................. 4 + 1.2.2. Syntactic notation ..................................... 4 + 1.3. Structure of this document ............................... 4 + 2. Lexical Analysis of Messages ............................... 5 + 2.1. General Description ...................................... 5 + 2.1.1. Line Length Limits ..................................... 6 + 2.2. Header Fields ............................................ 7 + 2.2.1. Unstructured Header Field Bodies ....................... 7 + 2.2.2. Structured Header Field Bodies ......................... 7 + 2.2.3. Long Header Fields ..................................... 7 + 2.3. Body ..................................................... 8 + 3. Syntax ..................................................... 9 + 3.1. Introduction ............................................. 9 + 3.2. Lexical Tokens ........................................... 9 + + + +Resnick Standards Track [Page 1] + +RFC 2822 Internet Message Format April 2001 + + + 3.2.1. Primitive Tokens ....................................... 9 + 3.2.2. Quoted characters ......................................10 + 3.2.3. Folding white space and comments .......................11 + 3.2.4. Atom ...................................................12 + 3.2.5. Quoted strings .........................................13 + 3.2.6. Miscellaneous tokens ...................................13 + 3.3. Date and Time Specification ..............................14 + 3.4. Address Specification ....................................15 + 3.4.1. Addr-spec specification ................................16 + 3.5 Overall message syntax ....................................17 + 3.6. Field definitions ........................................18 + 3.6.1. The origination date field .............................20 + 3.6.2. Originator fields ......................................21 + 3.6.3. Destination address fields .............................22 + 3.6.4. Identification fields ..................................23 + 3.6.5. Informational fields ...................................26 + 3.6.6. Resent fields ..........................................26 + 3.6.7. Trace fields ...........................................28 + 3.6.8. Optional fields ........................................29 + 4. Obsolete Syntax ............................................29 + 4.1. Miscellaneous obsolete tokens ............................30 + 4.2. Obsolete folding white space .............................31 + 4.3. Obsolete Date and Time ...................................31 + 4.4. Obsolete Addressing ......................................33 + 4.5. Obsolete header fields ...................................33 + 4.5.1. Obsolete origination date field ........................34 + 4.5.2. Obsolete originator fields .............................34 + 4.5.3. Obsolete destination address fields ....................34 + 4.5.4. Obsolete identification fields .........................35 + 4.5.5. Obsolete informational fields ..........................35 + 4.5.6. Obsolete resent fields .................................35 + 4.5.7. Obsolete trace fields ..................................36 + 4.5.8. Obsolete optional fields ...............................36 + 5. Security Considerations ....................................36 + 6. Bibliography ...............................................37 + 7. Editor's Address ...........................................38 + 8. Acknowledgements ...........................................39 + Appendix A. Example messages ..................................41 + A.1. Addressing examples ......................................41 + A.1.1. A message from one person to another with simple + addressing .............................................41 + A.1.2. Different types of mailboxes ...........................42 + A.1.3. Group addresses ........................................43 + A.2. Reply messages ...........................................43 + A.3. Resent messages ..........................................44 + A.4. Messages with trace fields ...............................46 + A.5. White space, comments, and other oddities ................47 + A.6. Obsoleted forms ..........................................47 + + + +Resnick Standards Track [Page 2] + +RFC 2822 Internet Message Format April 2001 + + + A.6.1. Obsolete addressing ....................................48 + A.6.2. Obsolete dates .........................................48 + A.6.3. Obsolete white space and comments ......................48 + Appendix B. Differences from earlier standards ................49 + Appendix C. Notices ...........................................50 + Full Copyright Statement ......................................51 + +1. Introduction + +1.1. Scope + + This standard specifies a syntax for text messages that are sent + between computer users, within the framework of "electronic mail" + messages. This standard supersedes the one specified in Request For + Comments (RFC) 822, "Standard for the Format of ARPA Internet Text + Messages" [RFC822], updating it to reflect current practice and + incorporating incremental changes that were specified in other RFCs + [STD3]. + + This standard specifies a syntax only for text messages. In + particular, it makes no provision for the transmission of images, + audio, or other sorts of structured data in electronic mail messages. + There are several extensions published, such as the MIME document + series [RFC2045, RFC2046, RFC2049], which describe mechanisms for the + transmission of such data through electronic mail, either by + extending the syntax provided here or by structuring such messages to + conform to this syntax. Those mechanisms are outside of the scope of + this standard. + + In the context of electronic mail, messages are viewed as having an + envelope and contents. The envelope contains whatever information is + needed to accomplish transmission and delivery. (See [RFC2821] for a + discussion of the envelope.) The contents comprise the object to be + delivered to the recipient. This standard applies only to the format + and some of the semantics of message contents. It contains no + specification of the information in the envelope. + + However, some message systems may use information from the contents + to create the envelope. It is intended that this standard facilitate + the acquisition of such information by programs. + + This specification is intended as a definition of what message + content format is to be passed between systems. Though some message + systems locally store messages in this format (which eliminates the + need for translation between formats) and others use formats that + differ from the one specified in this standard, local storage is + outside of the scope of this standard. + + + + +Resnick Standards Track [Page 3] + +RFC 2822 Internet Message Format April 2001 + + + Note: This standard is not intended to dictate the internal formats + used by sites, the specific message system features that they are + expected to support, or any of the characteristics of user interface + programs that create or read messages. In addition, this standard + does not specify an encoding of the characters for either transport + or storage; that is, it does not specify the number of bits used or + how those bits are specifically transferred over the wire or stored + on disk. + +1.2. Notational conventions + +1.2.1. Requirements notation + + This document occasionally uses terms that appear in capital letters. + When the terms "MUST", "SHOULD", "RECOMMENDED", "MUST NOT", "SHOULD + NOT", and "MAY" appear capitalized, they are being used to indicate + particular requirements of this specification. A discussion of the + meanings of these terms appears in [RFC2119]. + +1.2.2. Syntactic notation + + This standard uses the Augmented Backus-Naur Form (ABNF) notation + specified in [RFC2234] for the formal definitions of the syntax of + messages. Characters will be specified either by a decimal value + (e.g., the value %d65 for uppercase A and %d97 for lowercase A) or by + a case-insensitive literal value enclosed in quotation marks (e.g., + "A" for either uppercase or lowercase A). See [RFC2234] for the full + description of the notation. + +1.3. Structure of this document + + This document is divided into several sections. + + This section, section 1, is a short introduction to the document. + + Section 2 lays out the general description of a message and its + constituent parts. This is an overview to help the reader understand + some of the general principles used in the later portions of this + document. Any examples in this section MUST NOT be taken as + specification of the formal syntax of any part of a message. + + Section 3 specifies formal ABNF rules for the structure of each part + of a message (the syntax) and describes the relationship between + those parts and their meaning in the context of a message (the + semantics). That is, it describes the actual rules for the structure + of each part of a message (the syntax) as well as a description of + the parts and instructions on how they ought to be interpreted (the + semantics). This includes analysis of the syntax and semantics of + + + +Resnick Standards Track [Page 4] + +RFC 2822 Internet Message Format April 2001 + + + subparts of messages that have specific structure. The syntax + included in section 3 represents messages as they MUST be created. + There are also notes in section 3 to indicate if any of the options + specified in the syntax SHOULD be used over any of the others. + + Both sections 2 and 3 describe messages that are legal to generate + for purposes of this standard. + + Section 4 of this document specifies an "obsolete" syntax. There are + references in section 3 to these obsolete syntactic elements. The + rules of the obsolete syntax are elements that have appeared in + earlier revisions of this standard or have previously been widely + used in Internet messages. As such, these elements MUST be + interpreted by parsers of messages in order to be conformant to this + standard. However, since items in this syntax have been determined + to be non-interoperable or to cause significant problems for + recipients of messages, they MUST NOT be generated by creators of + conformant messages. + + Section 5 details security considerations to take into account when + implementing this standard. + + Section 6 is a bibliography of references in this document. + + Section 7 contains the editor's address. + + Section 8 contains acknowledgements. + + Appendix A lists examples of different sorts of messages. These + examples are not exhaustive of the types of messages that appear on + the Internet, but give a broad overview of certain syntactic forms. + + Appendix B lists the differences between this standard and earlier + standards for Internet messages. + + Appendix C has copyright and intellectual property notices. + +2. Lexical Analysis of Messages + +2.1. General Description + + At the most basic level, a message is a series of characters. A + message that is conformant with this standard is comprised of + characters with values in the range 1 through 127 and interpreted as + US-ASCII characters [ASCII]. For brevity, this document sometimes + refers to this range of characters as simply "US-ASCII characters". + + + + + +Resnick Standards Track [Page 5] + +RFC 2822 Internet Message Format April 2001 + + + Note: This standard specifies that messages are made up of characters + in the US-ASCII range of 1 through 127. There are other documents, + specifically the MIME document series [RFC2045, RFC2046, RFC2047, + RFC2048, RFC2049], that extend this standard to allow for values + outside of that range. Discussion of those mechanisms is not within + the scope of this standard. + + Messages are divided into lines of characters. A line is a series of + characters that is delimited with the two characters carriage-return + and line-feed; that is, the carriage return (CR) character (ASCII + value 13) followed immediately by the line feed (LF) character (ASCII + value 10). (The carriage-return/line-feed pair is usually written in + this document as "CRLF".) + + A message consists of header fields (collectively called "the header + of the message") followed, optionally, by a body. The header is a + sequence of lines of characters with special syntax as defined in + this standard. The body is simply a sequence of characters that + follows the header and is separated from the header by an empty line + (i.e., a line with nothing preceding the CRLF). + +2.1.1. Line Length Limits + + There are two limits that this standard places on the number of + characters in a line. Each line of characters MUST be no more than + 998 characters, and SHOULD be no more than 78 characters, excluding + the CRLF. + + The 998 character limit is due to limitations in many implementations + which send, receive, or store Internet Message Format messages that + simply cannot handle more than 998 characters on a line. Receiving + implementations would do well to handle an arbitrarily large number + of characters in a line for robustness sake. However, there are so + many implementations which (in compliance with the transport + requirements of [RFC2821]) do not accept messages containing more + than 1000 character including the CR and LF per line, it is important + for implementations not to create such messages. + + The more conservative 78 character recommendation is to accommodate + the many implementations of user interfaces that display these + messages which may truncate, or disastrously wrap, the display of + more than 78 characters per line, in spite of the fact that such + implementations are non-conformant to the intent of this + specification (and that of [RFC2821] if they actually cause + information to be lost). Again, even though this limitation is put on + messages, it is encumbant upon implementations which display messages + + + + + +Resnick Standards Track [Page 6] + +RFC 2822 Internet Message Format April 2001 + + + to handle an arbitrarily large number of characters in a line + (certainly at least up to the 998 character limit) for the sake of + robustness. + +2.2. Header Fields + + Header fields are lines composed of a field name, followed by a colon + (":"), followed by a field body, and terminated by CRLF. A field + name MUST be composed of printable US-ASCII characters (i.e., + characters that have values between 33 and 126, inclusive), except + colon. A field body may be composed of any US-ASCII characters, + except for CR and LF. However, a field body may contain CRLF when + used in header "folding" and "unfolding" as described in section + 2.2.3. All field bodies MUST conform to the syntax described in + sections 3 and 4 of this standard. + +2.2.1. Unstructured Header Field Bodies + + Some field bodies in this standard are defined simply as + "unstructured" (which is specified below as any US-ASCII characters, + except for CR and LF) with no further restrictions. These are + referred to as unstructured field bodies. Semantically, unstructured + field bodies are simply to be treated as a single line of characters + with no further processing (except for header "folding" and + "unfolding" as described in section 2.2.3). + +2.2.2. Structured Header Field Bodies + + Some field bodies in this standard have specific syntactical + structure more restrictive than the unstructured field bodies + described above. These are referred to as "structured" field bodies. + Structured field bodies are sequences of specific lexical tokens as + described in sections 3 and 4 of this standard. Many of these tokens + are allowed (according to their syntax) to be introduced or end with + comments (as described in section 3.2.3) as well as the space (SP, + ASCII value 32) and horizontal tab (HTAB, ASCII value 9) characters + (together known as the white space characters, WSP), and those WSP + characters are subject to header "folding" and "unfolding" as + described in section 2.2.3. Semantic analysis of structured field + bodies is given along with their syntax. + +2.2.3. Long Header Fields + + Each header field is logically a single line of characters comprising + the field name, the colon, and the field body. For convenience + however, and to deal with the 998/78 character limitations per line, + the field body portion of a header field can be split into a multiple + line representation; this is called "folding". The general rule is + + + +Resnick Standards Track [Page 7] + +RFC 2822 Internet Message Format April 2001 + + + that wherever this standard allows for folding white space (not + simply WSP characters), a CRLF may be inserted before any WSP. For + example, the header field: + + Subject: This is a test + + can be represented as: + + Subject: This + is a test + + Note: Though structured field bodies are defined in such a way that + folding can take place between many of the lexical tokens (and even + within some of the lexical tokens), folding SHOULD be limited to + placing the CRLF at higher-level syntactic breaks. For instance, if + a field body is defined as comma-separated values, it is recommended + that folding occur after the comma separating the structured items in + preference to other places where the field could be folded, even if + it is allowed elsewhere. + + The process of moving from this folded multiple-line representation + of a header field to its single line representation is called + "unfolding". Unfolding is accomplished by simply removing any CRLF + that is immediately followed by WSP. Each header field should be + treated in its unfolded form for further syntactic and semantic + evaluation. + +2.3. Body + + The body of a message is simply lines of US-ASCII characters. The + only two limitations on the body are as follows: + + - CR and LF MUST only occur together as CRLF; they MUST NOT appear + independently in the body. + + - Lines of characters in the body MUST be limited to 998 characters, + and SHOULD be limited to 78 characters, excluding the CRLF. + + Note: As was stated earlier, there are other standards documents, + specifically the MIME documents [RFC2045, RFC2046, RFC2048, RFC2049] + that extend this standard to allow for different sorts of message + bodies. Again, these mechanisms are beyond the scope of this + document. + + + + + + + + +Resnick Standards Track [Page 8] + +RFC 2822 Internet Message Format April 2001 + + +3. Syntax + +3.1. Introduction + + The syntax as given in this section defines the legal syntax of + Internet messages. Messages that are conformant to this standard + MUST conform to the syntax in this section. If there are options in + this section where one option SHOULD be generated, that is indicated + either in the prose or in a comment next to the syntax. + + For the defined expressions, a short description of the syntax and + use is given, followed by the syntax in ABNF, followed by a semantic + analysis. Primitive tokens that are used but otherwise unspecified + come from [RFC2234]. + + In some of the definitions, there will be nonterminals whose names + start with "obs-". These "obs-" elements refer to tokens defined in + the obsolete syntax in section 4. In all cases, these productions + are to be ignored for the purposes of generating legal Internet + messages and MUST NOT be used as part of such a message. However, + when interpreting messages, these tokens MUST be honored as part of + the legal syntax. In this sense, section 3 defines a grammar for + generation of messages, with "obs-" elements that are to be ignored, + while section 4 adds grammar for interpretation of messages. + +3.2. Lexical Tokens + + The following rules are used to define an underlying lexical + analyzer, which feeds tokens to the higher-level parsers. This + section defines the tokens used in structured header field bodies. + + Note: Readers of this standard need to pay special attention to how + these lexical tokens are used in both the lower-level and + higher-level syntax later in the document. Particularly, the white + space tokens and the comment tokens defined in section 3.2.3 get used + in the lower-level tokens defined here, and those lower-level tokens + are in turn used as parts of the higher-level tokens defined later. + Therefore, the white space and comments may be allowed in the + higher-level tokens even though they may not explicitly appear in a + particular definition. + +3.2.1. Primitive Tokens + + The following are primitive tokens referred to elsewhere in this + standard, but not otherwise defined in [RFC2234]. Some of them will + not appear anywhere else in the syntax, but they are convenient to + refer to in other parts of this document. + + + + +Resnick Standards Track [Page 9] + +RFC 2822 Internet Message Format April 2001 + + + Note: The "specials" below are just such an example. Though the + specials token does not appear anywhere else in this standard, it is + useful for implementers who use tools that lexically analyze + messages. Each of the characters in specials can be used to indicate + a tokenization point in lexical analysis. + +NO-WS-CTL = %d1-8 / ; US-ASCII control characters + %d11 / ; that do not include the + %d12 / ; carriage return, line feed, + %d14-31 / ; and white space characters + %d127 + +text = %d1-9 / ; Characters excluding CR and LF + %d11 / + %d12 / + %d14-127 / + obs-text + +specials = "(" / ")" / ; Special characters used in + "<" / ">" / ; other parts of the syntax + "[" / "]" / + ":" / ";" / + "@" / "\" / + "," / "." / + DQUOTE + + No special semantics are attached to these tokens. They are simply + single characters. + +3.2.2. Quoted characters + + Some characters are reserved for special interpretation, such as + delimiting lexical tokens. To permit use of these characters as + uninterpreted data, a quoting mechanism is provided. + +quoted-pair = ("\" text) / obs-qp + + Where any quoted-pair appears, it is to be interpreted as the text + character alone. That is to say, the "\" character that appears as + part of a quoted-pair is semantically "invisible". + + Note: The "\" character may appear in a message where it is not part + of a quoted-pair. A "\" character that does not appear in a + quoted-pair is not semantically invisible. The only places in this + standard where quoted-pair currently appears are ccontent, qcontent, + dcontent, no-fold-quote, and no-fold-literal. + + + + + +Resnick Standards Track [Page 10] + +RFC 2822 Internet Message Format April 2001 + + +3.2.3. Folding white space and comments + + White space characters, including white space used in folding + (described in section 2.2.3), may appear between many elements in + header field bodies. Also, strings of characters that are treated as + comments may be included in structured field bodies as characters + enclosed in parentheses. The following defines the folding white + space (FWS) and comment constructs. + + Strings of characters enclosed in parentheses are considered comments + so long as they do not appear within a "quoted-string", as defined in + section 3.2.5. Comments may nest. + + There are several places in this standard where comments and FWS may + be freely inserted. To accommodate that syntax, an additional token + for "CFWS" is defined for places where comments and/or FWS can occur. + However, where CFWS occurs in this standard, it MUST NOT be inserted + in such a way that any line of a folded header field is made up + entirely of WSP characters and nothing else. + +FWS = ([*WSP CRLF] 1*WSP) / ; Folding white space + obs-FWS + +ctext = NO-WS-CTL / ; Non white space controls + + %d33-39 / ; The rest of the US-ASCII + %d42-91 / ; characters not including "(", + %d93-126 ; ")", or "\" + +ccontent = ctext / quoted-pair / comment + +comment = "(" *([FWS] ccontent) [FWS] ")" + +CFWS = *([FWS] comment) (([FWS] comment) / FWS) + + Throughout this standard, where FWS (the folding white space token) + appears, it indicates a place where header folding, as discussed in + section 2.2.3, may take place. Wherever header folding appears in a + message (that is, a header field body containing a CRLF followed by + any WSP), header unfolding (removal of the CRLF) is performed before + any further lexical analysis is performed on that header field + according to this standard. That is to say, any CRLF that appears in + FWS is semantically "invisible." + + A comment is normally used in a structured field body to provide some + human readable informational text. Since a comment is allowed to + contain FWS, folding is permitted within the comment. Also note that + since quoted-pair is allowed in a comment, the parentheses and + + + +Resnick Standards Track [Page 11] + +RFC 2822 Internet Message Format April 2001 + + + backslash characters may appear in a comment so long as they appear + as a quoted-pair. Semantically, the enclosing parentheses are not + part of the comment; the comment is what is contained between the two + parentheses. As stated earlier, the "\" in any quoted-pair and the + CRLF in any FWS that appears within the comment are semantically + "invisible" and therefore not part of the comment either. + + Runs of FWS, comment or CFWS that occur between lexical tokens in a + structured field header are semantically interpreted as a single + space character. + +3.2.4. Atom + + Several productions in structured header field bodies are simply + strings of certain basic characters. Such productions are called + atoms. + + Some of the structured header field bodies also allow the period + character (".", ASCII value 46) within runs of atext. An additional + "dot-atom" token is defined for those purposes. + +atext = ALPHA / DIGIT / ; Any character except controls, + "!" / "#" / ; SP, and specials. + "$" / "%" / ; Used for atoms + "&" / "'" / + "*" / "+" / + "-" / "/" / + "=" / "?" / + "^" / "_" / + "`" / "{" / + "|" / "}" / + "~" + +atom = [CFWS] 1*atext [CFWS] + +dot-atom = [CFWS] dot-atom-text [CFWS] + +dot-atom-text = 1*atext *("." 1*atext) + + Both atom and dot-atom are interpreted as a single unit, comprised of + the string of characters that make it up. Semantically, the optional + comments and FWS surrounding the rest of the characters are not part + of the atom; the atom is only the run of atext characters in an atom, + or the atext and "." characters in a dot-atom. + + + + + + + +Resnick Standards Track [Page 12] + +RFC 2822 Internet Message Format April 2001 + + +3.2.5. Quoted strings + + Strings of characters that include characters other than those + allowed in atoms may be represented in a quoted string format, where + the characters are surrounded by quote (DQUOTE, ASCII value 34) + characters. + +qtext = NO-WS-CTL / ; Non white space controls + + %d33 / ; The rest of the US-ASCII + %d35-91 / ; characters not including "\" + %d93-126 ; or the quote character + +qcontent = qtext / quoted-pair + +quoted-string = [CFWS] + DQUOTE *([FWS] qcontent) [FWS] DQUOTE + [CFWS] + + A quoted-string is treated as a unit. That is, quoted-string is + identical to atom, semantically. Since a quoted-string is allowed to + contain FWS, folding is permitted. Also note that since quoted-pair + is allowed in a quoted-string, the quote and backslash characters may + appear in a quoted-string so long as they appear as a quoted-pair. + + Semantically, neither the optional CFWS outside of the quote + characters nor the quote characters themselves are part of the + quoted-string; the quoted-string is what is contained between the two + quote characters. As stated earlier, the "\" in any quoted-pair and + the CRLF in any FWS/CFWS that appears within the quoted-string are + semantically "invisible" and therefore not part of the quoted-string + either. + +3.2.6. Miscellaneous tokens + + Three additional tokens are defined, word and phrase for combinations + of atoms and/or quoted-strings, and unstructured for use in + unstructured header fields and in some places within structured + header fields. + +word = atom / quoted-string + +phrase = 1*word / obs-phrase + + + + + + + + +Resnick Standards Track [Page 13] + +RFC 2822 Internet Message Format April 2001 + + +utext = NO-WS-CTL / ; Non white space controls + %d33-126 / ; The rest of US-ASCII + obs-utext + +unstructured = *([FWS] utext) [FWS] + +3.3. Date and Time Specification + + Date and time occur in several header fields. This section specifies + the syntax for a full date and time specification. Though folding + white space is permitted throughout the date-time specification, it + is RECOMMENDED that a single space be used in each place that FWS + appears (whether it is required or optional); some older + implementations may not interpret other occurrences of folding white + space correctly. + +date-time = [ day-of-week "," ] date FWS time [CFWS] + +day-of-week = ([FWS] day-name) / obs-day-of-week + +day-name = "Mon" / "Tue" / "Wed" / "Thu" / + "Fri" / "Sat" / "Sun" + +date = day month year + +year = 4*DIGIT / obs-year + +month = (FWS month-name FWS) / obs-month + +month-name = "Jan" / "Feb" / "Mar" / "Apr" / + "May" / "Jun" / "Jul" / "Aug" / + "Sep" / "Oct" / "Nov" / "Dec" + +day = ([FWS] 1*2DIGIT) / obs-day + +time = time-of-day FWS zone + +time-of-day = hour ":" minute [ ":" second ] + +hour = 2DIGIT / obs-hour + +minute = 2DIGIT / obs-minute + +second = 2DIGIT / obs-second + +zone = (( "+" / "-" ) 4DIGIT) / obs-zone + + + + + +Resnick Standards Track [Page 14] + +RFC 2822 Internet Message Format April 2001 + + + The day is the numeric day of the month. The year is any numeric + year 1900 or later. + + The time-of-day specifies the number of hours, minutes, and + optionally seconds since midnight of the date indicated. + + The date and time-of-day SHOULD express local time. + + The zone specifies the offset from Coordinated Universal Time (UTC, + formerly referred to as "Greenwich Mean Time") that the date and + time-of-day represent. The "+" or "-" indicates whether the + time-of-day is ahead of (i.e., east of) or behind (i.e., west of) + Universal Time. The first two digits indicate the number of hours + difference from Universal Time, and the last two digits indicate the + number of minutes difference from Universal Time. (Hence, +hhmm + means +(hh * 60 + mm) minutes, and -hhmm means -(hh * 60 + mm) + minutes). The form "+0000" SHOULD be used to indicate a time zone at + Universal Time. Though "-0000" also indicates Universal Time, it is + used to indicate that the time was generated on a system that may be + in a local time zone other than Universal Time and therefore + indicates that the date-time contains no information about the local + time zone. + + A date-time specification MUST be semantically valid. That is, the + day-of-the-week (if included) MUST be the day implied by the date, + the numeric day-of-month MUST be between 1 and the number of days + allowed for the specified month (in the specified year), the + time-of-day MUST be in the range 00:00:00 through 23:59:60 (the + number of seconds allowing for a leap second; see [STD12]), and the + zone MUST be within the range -9959 through +9959. + +3.4. Address Specification + + Addresses occur in several message header fields to indicate senders + and recipients of messages. An address may either be an individual + mailbox, or a group of mailboxes. + +address = mailbox / group + +mailbox = name-addr / addr-spec + +name-addr = [display-name] angle-addr + +angle-addr = [CFWS] "<" addr-spec ">" [CFWS] / obs-angle-addr + +group = display-name ":" [mailbox-list / CFWS] ";" + [CFWS] + + + + +Resnick Standards Track [Page 15] + +RFC 2822 Internet Message Format April 2001 + + +display-name = phrase + +mailbox-list = (mailbox *("," mailbox)) / obs-mbox-list + +address-list = (address *("," address)) / obs-addr-list + + A mailbox receives mail. It is a conceptual entity which does not + necessarily pertain to file storage. For example, some sites may + choose to print mail on a printer and deliver the output to the + addressee's desk. Normally, a mailbox is comprised of two parts: (1) + an optional display name that indicates the name of the recipient + (which could be a person or a system) that could be displayed to the + user of a mail application, and (2) an addr-spec address enclosed in + angle brackets ("<" and ">"). There is also an alternate simple form + of a mailbox where the addr-spec address appears alone, without the + recipient's name or the angle brackets. The Internet addr-spec + address is described in section 3.4.1. + + Note: Some legacy implementations used the simple form where the + addr-spec appears without the angle brackets, but included the name + of the recipient in parentheses as a comment following the addr-spec. + Since the meaning of the information in a comment is unspecified, + implementations SHOULD use the full name-addr form of the mailbox, + instead of the legacy form, to specify the display name associated + with a mailbox. Also, because some legacy implementations interpret + the comment, comments generally SHOULD NOT be used in address fields + to avoid confusing such implementations. + + When it is desirable to treat several mailboxes as a single unit + (i.e., in a distribution list), the group construct can be used. The + group construct allows the sender to indicate a named group of + recipients. This is done by giving a display name for the group, + followed by a colon, followed by a comma separated list of any number + of mailboxes (including zero and one), and ending with a semicolon. + Because the list of mailboxes can be empty, using the group construct + is also a simple way to communicate to recipients that the message + was sent to one or more named sets of recipients, without actually + providing the individual mailbox address for each of those + recipients. + +3.4.1. Addr-spec specification + + An addr-spec is a specific Internet identifier that contains a + locally interpreted string followed by the at-sign character ("@", + ASCII value 64) followed by an Internet domain. The locally + interpreted string is either a quoted-string or a dot-atom. If the + string can be represented as a dot-atom (that is, it contains no + characters other than atext characters or "." surrounded by atext + + + +Resnick Standards Track [Page 16] + +RFC 2822 Internet Message Format April 2001 + + + characters), then the dot-atom form SHOULD be used and the + quoted-string form SHOULD NOT be used. Comments and folding white + space SHOULD NOT be used around the "@" in the addr-spec. + +addr-spec = local-part "@" domain + +local-part = dot-atom / quoted-string / obs-local-part + +domain = dot-atom / domain-literal / obs-domain + +domain-literal = [CFWS] "[" *([FWS] dcontent) [FWS] "]" [CFWS] + +dcontent = dtext / quoted-pair + +dtext = NO-WS-CTL / ; Non white space controls + + %d33-90 / ; The rest of the US-ASCII + %d94-126 ; characters not including "[", + ; "]", or "\" + + The domain portion identifies the point to which the mail is + delivered. In the dot-atom form, this is interpreted as an Internet + domain name (either a host name or a mail exchanger name) as + described in [STD3, STD13, STD14]. In the domain-literal form, the + domain is interpreted as the literal Internet address of the + particular host. In both cases, how addressing is used and how + messages are transported to a particular host is covered in the mail + transport document [RFC2821]. These mechanisms are outside of the + scope of this document. + + The local-part portion is a domain dependent string. In addresses, + it is simply interpreted on the particular host as a name of a + particular mailbox. + +3.5 Overall message syntax + + A message consists of header fields, optionally followed by a message + body. Lines in a message MUST be a maximum of 998 characters + excluding the CRLF, but it is RECOMMENDED that lines be limited to 78 + characters excluding the CRLF. (See section 2.1.1 for explanation.) + In a message body, though all of the characters listed in the text + rule MAY be used, the use of US-ASCII control characters (values 1 + through 8, 11, 12, and 14 through 31) is discouraged since their + interpretation by receivers for display is not guaranteed. + + + + + + + +Resnick Standards Track [Page 17] + +RFC 2822 Internet Message Format April 2001 + + +message = (fields / obs-fields) + [CRLF body] + +body = *(*998text CRLF) *998text + + The header fields carry most of the semantic information and are + defined in section 3.6. The body is simply a series of lines of text + which are uninterpreted for the purposes of this standard. + +3.6. Field definitions + + The header fields of a message are defined here. All header fields + have the same general syntactic structure: A field name, followed by + a colon, followed by the field body. The specific syntax for each + header field is defined in the subsequent sections. + + Note: In the ABNF syntax for each field in subsequent sections, each + field name is followed by the required colon. However, for brevity + sometimes the colon is not referred to in the textual description of + the syntax. It is, nonetheless, required. + + It is important to note that the header fields are not guaranteed to + be in a particular order. They may appear in any order, and they + have been known to be reordered occasionally when transported over + the Internet. However, for the purposes of this standard, header + fields SHOULD NOT be reordered when a message is transported or + transformed. More importantly, the trace header fields and resent + header fields MUST NOT be reordered, and SHOULD be kept in blocks + prepended to the message. See sections 3.6.6 and 3.6.7 for more + information. + + The only required header fields are the origination date field and + the originator address field(s). All other header fields are + syntactically optional. More information is contained in the table + following this definition. + +fields = *(trace + *(resent-date / + resent-from / + resent-sender / + resent-to / + resent-cc / + resent-bcc / + resent-msg-id)) + *(orig-date / + from / + sender / + reply-to / + + + +Resnick Standards Track [Page 18] + +RFC 2822 Internet Message Format April 2001 + + + to / + cc / + bcc / + message-id / + in-reply-to / + references / + subject / + comments / + keywords / + optional-field) + + The following table indicates limits on the number of times each + field may occur in a message header as well as any special + limitations on the use of those fields. An asterisk next to a value + in the minimum or maximum column indicates that a special restriction + appears in the Notes column. + +Field Min number Max number Notes + +trace 0 unlimited Block prepended - see + 3.6.7 + +resent-date 0* unlimited* One per block, required + if other resent fields + present - see 3.6.6 + +resent-from 0 unlimited* One per block - see + 3.6.6 + +resent-sender 0* unlimited* One per block, MUST + occur with multi-address + resent-from - see 3.6.6 + +resent-to 0 unlimited* One per block - see + 3.6.6 + +resent-cc 0 unlimited* One per block - see + 3.6.6 + +resent-bcc 0 unlimited* One per block - see + 3.6.6 + +resent-msg-id 0 unlimited* One per block - see + 3.6.6 + +orig-date 1 1 + +from 1 1 See sender and 3.6.2 + + + +Resnick Standards Track [Page 19] + +RFC 2822 Internet Message Format April 2001 + + +sender 0* 1 MUST occur with multi- + address from - see 3.6.2 + +reply-to 0 1 + +to 0 1 + +cc 0 1 + +bcc 0 1 + +message-id 0* 1 SHOULD be present - see + 3.6.4 + +in-reply-to 0* 1 SHOULD occur in some + replies - see 3.6.4 + +references 0* 1 SHOULD occur in some + replies - see 3.6.4 + +subject 0 1 + +comments 0 unlimited + +keywords 0 unlimited + +optional-field 0 unlimited + + The exact interpretation of each field is described in subsequent + sections. + +3.6.1. The origination date field + + The origination date field consists of the field name "Date" followed + by a date-time specification. + +orig-date = "Date:" date-time CRLF + + The origination date specifies the date and time at which the creator + of the message indicated that the message was complete and ready to + enter the mail delivery system. For instance, this might be the time + that a user pushes the "send" or "submit" button in an application + program. In any case, it is specifically not intended to convey the + time that the message is actually transported, but rather the time at + which the human or other creator of the message has put the message + into its final form, ready for transport. (For example, a portable + computer user who is not connected to a network might queue a message + + + + +Resnick Standards Track [Page 20] + +RFC 2822 Internet Message Format April 2001 + + + for delivery. The origination date is intended to contain the date + and time that the user queued the message, not the time when the user + connected to the network to send the message.) + +3.6.2. Originator fields + + The originator fields of a message consist of the from field, the + sender field (when applicable), and optionally the reply-to field. + The from field consists of the field name "From" and a + comma-separated list of one or more mailbox specifications. If the + from field contains more than one mailbox specification in the + mailbox-list, then the sender field, containing the field name + "Sender" and a single mailbox specification, MUST appear in the + message. In either case, an optional reply-to field MAY also be + included, which contains the field name "Reply-To" and a + comma-separated list of one or more addresses. + +from = "From:" mailbox-list CRLF + +sender = "Sender:" mailbox CRLF + +reply-to = "Reply-To:" address-list CRLF + + The originator fields indicate the mailbox(es) of the source of the + message. The "From:" field specifies the author(s) of the message, + that is, the mailbox(es) of the person(s) or system(s) responsible + for the writing of the message. The "Sender:" field specifies the + mailbox of the agent responsible for the actual transmission of the + message. For example, if a secretary were to send a message for + another person, the mailbox of the secretary would appear in the + "Sender:" field and the mailbox of the actual author would appear in + the "From:" field. If the originator of the message can be indicated + by a single mailbox and the author and transmitter are identical, the + "Sender:" field SHOULD NOT be used. Otherwise, both fields SHOULD + appear. + + The originator fields also provide the information required when + replying to a message. When the "Reply-To:" field is present, it + indicates the mailbox(es) to which the author of the message suggests + that replies be sent. In the absence of the "Reply-To:" field, + replies SHOULD by default be sent to the mailbox(es) specified in the + "From:" field unless otherwise specified by the person composing the + reply. + + In all cases, the "From:" field SHOULD NOT contain any mailbox that + does not belong to the author(s) of the message. See also section + 3.6.3 for more information on forming the destination addresses for a + reply. + + + +Resnick Standards Track [Page 21] + +RFC 2822 Internet Message Format April 2001 + + +3.6.3. Destination address fields + + The destination fields of a message consist of three possible fields, + each of the same form: The field name, which is either "To", "Cc", or + "Bcc", followed by a comma-separated list of one or more addresses + (either mailbox or group syntax). + +to = "To:" address-list CRLF + +cc = "Cc:" address-list CRLF + +bcc = "Bcc:" (address-list / [CFWS]) CRLF + + The destination fields specify the recipients of the message. Each + destination field may have one or more addresses, and each of the + addresses indicate the intended recipients of the message. The only + difference between the three fields is how each is used. + + The "To:" field contains the address(es) of the primary recipient(s) + of the message. + + The "Cc:" field (where the "Cc" means "Carbon Copy" in the sense of + making a copy on a typewriter using carbon paper) contains the + addresses of others who are to receive the message, though the + content of the message may not be directed at them. + + The "Bcc:" field (where the "Bcc" means "Blind Carbon Copy") contains + addresses of recipients of the message whose addresses are not to be + revealed to other recipients of the message. There are three ways in + which the "Bcc:" field is used. In the first case, when a message + containing a "Bcc:" field is prepared to be sent, the "Bcc:" line is + removed even though all of the recipients (including those specified + in the "Bcc:" field) are sent a copy of the message. In the second + case, recipients specified in the "To:" and "Cc:" lines each are sent + a copy of the message with the "Bcc:" line removed as above, but the + recipients on the "Bcc:" line get a separate copy of the message + containing a "Bcc:" line. (When there are multiple recipient + addresses in the "Bcc:" field, some implementations actually send a + separate copy of the message to each recipient with a "Bcc:" + containing only the address of that particular recipient.) Finally, + since a "Bcc:" field may contain no addresses, a "Bcc:" field can be + sent without any addresses indicating to the recipients that blind + copies were sent to someone. Which method to use with "Bcc:" fields + is implementation dependent, but refer to the "Security + Considerations" section of this document for a discussion of each. + + + + + + +Resnick Standards Track [Page 22] + +RFC 2822 Internet Message Format April 2001 + + + When a message is a reply to another message, the mailboxes of the + authors of the original message (the mailboxes in the "From:" field) + or mailboxes specified in the "Reply-To:" field (if it exists) MAY + appear in the "To:" field of the reply since these would normally be + the primary recipients of the reply. If a reply is sent to a message + that has destination fields, it is often desirable to send a copy of + the reply to all of the recipients of the message, in addition to the + author. When such a reply is formed, addresses in the "To:" and + "Cc:" fields of the original message MAY appear in the "Cc:" field of + the reply, since these are normally secondary recipients of the + reply. If a "Bcc:" field is present in the original message, + addresses in that field MAY appear in the "Bcc:" field of the reply, + but SHOULD NOT appear in the "To:" or "Cc:" fields. + + Note: Some mail applications have automatic reply commands that + include the destination addresses of the original message in the + destination addresses of the reply. How those reply commands behave + is implementation dependent and is beyond the scope of this document. + In particular, whether or not to include the original destination + addresses when the original message had a "Reply-To:" field is not + addressed here. + +3.6.4. Identification fields + + Though optional, every message SHOULD have a "Message-ID:" field. + Furthermore, reply messages SHOULD have "In-Reply-To:" and + "References:" fields as appropriate, as described below. + + The "Message-ID:" field contains a single unique message identifier. + The "References:" and "In-Reply-To:" field each contain one or more + unique message identifiers, optionally separated by CFWS. + + The message identifier (msg-id) is similar in syntax to an angle-addr + construct without the internal CFWS. + +message-id = "Message-ID:" msg-id CRLF + +in-reply-to = "In-Reply-To:" 1*msg-id CRLF + +references = "References:" 1*msg-id CRLF + +msg-id = [CFWS] "<" id-left "@" id-right ">" [CFWS] + +id-left = dot-atom-text / no-fold-quote / obs-id-left + +id-right = dot-atom-text / no-fold-literal / obs-id-right + +no-fold-quote = DQUOTE *(qtext / quoted-pair) DQUOTE + + + +Resnick Standards Track [Page 23] + +RFC 2822 Internet Message Format April 2001 + + +no-fold-literal = "[" *(dtext / quoted-pair) "]" + + The "Message-ID:" field provides a unique message identifier that + refers to a particular version of a particular message. The + uniqueness of the message identifier is guaranteed by the host that + generates it (see below). This message identifier is intended to be + machine readable and not necessarily meaningful to humans. A message + identifier pertains to exactly one instantiation of a particular + message; subsequent revisions to the message each receive new message + identifiers. + + Note: There are many instances when messages are "changed", but those + changes do not constitute a new instantiation of that message, and + therefore the message would not get a new message identifier. For + example, when messages are introduced into the transport system, they + are often prepended with additional header fields such as trace + fields (described in section 3.6.7) and resent fields (described in + section 3.6.6). The addition of such header fields does not change + the identity of the message and therefore the original "Message-ID:" + field is retained. In all cases, it is the meaning that the sender + of the message wishes to convey (i.e., whether this is the same + message or a different message) that determines whether or not the + "Message-ID:" field changes, not any particular syntactic difference + that appears (or does not appear) in the message. + + The "In-Reply-To:" and "References:" fields are used when creating a + reply to a message. They hold the message identifier of the original + message and the message identifiers of other messages (for example, + in the case of a reply to a message which was itself a reply). The + "In-Reply-To:" field may be used to identify the message (or + messages) to which the new message is a reply, while the + "References:" field may be used to identify a "thread" of + conversation. + + When creating a reply to a message, the "In-Reply-To:" and + "References:" fields of the resultant message are constructed as + follows: + + The "In-Reply-To:" field will contain the contents of the "Message- + ID:" field of the message to which this one is a reply (the "parent + message"). If there is more than one parent message, then the "In- + Reply-To:" field will contain the contents of all of the parents' + "Message-ID:" fields. If there is no "Message-ID:" field in any of + the parent messages, then the new message will have no "In-Reply-To:" + field. + + + + + + +Resnick Standards Track [Page 24] + +RFC 2822 Internet Message Format April 2001 + + + The "References:" field will contain the contents of the parent's + "References:" field (if any) followed by the contents of the parent's + "Message-ID:" field (if any). If the parent message does not contain + a "References:" field but does have an "In-Reply-To:" field + containing a single message identifier, then the "References:" field + will contain the contents of the parent's "In-Reply-To:" field + followed by the contents of the parent's "Message-ID:" field (if + any). If the parent has none of the "References:", "In-Reply-To:", + or "Message-ID:" fields, then the new message will have no + "References:" field. + + Note: Some implementations parse the "References:" field to display + the "thread of the discussion". These implementations assume that + each new message is a reply to a single parent and hence that they + can walk backwards through the "References:" field to find the parent + of each message listed there. Therefore, trying to form a + "References:" field for a reply that has multiple parents is + discouraged and how to do so is not defined in this document. + + The message identifier (msg-id) itself MUST be a globally unique + identifier for a message. The generator of the message identifier + MUST guarantee that the msg-id is unique. There are several + algorithms that can be used to accomplish this. Since the msg-id has + a similar syntax to angle-addr (identical except that comments and + folding white space are not allowed), a good method is to put the + domain name (or a domain literal IP address) of the host on which the + message identifier was created on the right hand side of the "@", and + put a combination of the current absolute date and time along with + some other currently unique (perhaps sequential) identifier available + on the system (for example, a process id number) on the left hand + side. Using a date on the left hand side and a domain name or domain + literal on the right hand side makes it possible to guarantee + uniqueness since no two hosts use the same domain name or IP address + at the same time. Though other algorithms will work, it is + RECOMMENDED that the right hand side contain some domain identifier + (either of the host itself or otherwise) such that the generator of + the message identifier can guarantee the uniqueness of the left hand + side within the scope of that domain. + + Semantically, the angle bracket characters are not part of the + msg-id; the msg-id is what is contained between the two angle bracket + characters. + + + + + + + + + +Resnick Standards Track [Page 25] + +RFC 2822 Internet Message Format April 2001 + + +3.6.5. Informational fields + + The informational fields are all optional. The "Keywords:" field + contains a comma-separated list of one or more words or + quoted-strings. The "Subject:" and "Comments:" fields are + unstructured fields as defined in section 2.2.1, and therefore may + contain text or folding white space. + +subject = "Subject:" unstructured CRLF + +comments = "Comments:" unstructured CRLF + +keywords = "Keywords:" phrase *("," phrase) CRLF + + These three fields are intended to have only human-readable content + with information about the message. The "Subject:" field is the most + common and contains a short string identifying the topic of the + message. When used in a reply, the field body MAY start with the + string "Re: " (from the Latin "res", in the matter of) followed by + the contents of the "Subject:" field body of the original message. + If this is done, only one instance of the literal string "Re: " ought + to be used since use of other strings or more than one instance can + lead to undesirable consequences. The "Comments:" field contains any + additional comments on the text of the body of the message. The + "Keywords:" field contains a comma-separated list of important words + and phrases that might be useful for the recipient. + +3.6.6. Resent fields + + Resent fields SHOULD be added to any message that is reintroduced by + a user into the transport system. A separate set of resent fields + SHOULD be added each time this is done. All of the resent fields + corresponding to a particular resending of the message SHOULD be + together. Each new set of resent fields is prepended to the message; + that is, the most recent set of resent fields appear earlier in the + message. No other fields in the message are changed when resent + fields are added. + + Each of the resent fields corresponds to a particular field elsewhere + in the syntax. For instance, the "Resent-Date:" field corresponds to + the "Date:" field and the "Resent-To:" field corresponds to the "To:" + field. In each case, the syntax for the field body is identical to + the syntax given previously for the corresponding field. + + When resent fields are used, the "Resent-From:" and "Resent-Date:" + fields MUST be sent. The "Resent-Message-ID:" field SHOULD be sent. + "Resent-Sender:" SHOULD NOT be used if "Resent-Sender:" would be + identical to "Resent-From:". + + + +Resnick Standards Track [Page 26] + +RFC 2822 Internet Message Format April 2001 + + +resent-date = "Resent-Date:" date-time CRLF + +resent-from = "Resent-From:" mailbox-list CRLF + +resent-sender = "Resent-Sender:" mailbox CRLF + +resent-to = "Resent-To:" address-list CRLF + +resent-cc = "Resent-Cc:" address-list CRLF + +resent-bcc = "Resent-Bcc:" (address-list / [CFWS]) CRLF + +resent-msg-id = "Resent-Message-ID:" msg-id CRLF + + Resent fields are used to identify a message as having been + reintroduced into the transport system by a user. The purpose of + using resent fields is to have the message appear to the final + recipient as if it were sent directly by the original sender, with + all of the original fields remaining the same. Each set of resent + fields correspond to a particular resending event. That is, if a + message is resent multiple times, each set of resent fields gives + identifying information for each individual time. Resent fields are + strictly informational. They MUST NOT be used in the normal + processing of replies or other such automatic actions on messages. + + Note: Reintroducing a message into the transport system and using + resent fields is a different operation from "forwarding". + "Forwarding" has two meanings: One sense of forwarding is that a mail + reading program can be told by a user to forward a copy of a message + to another person, making the forwarded message the body of the new + message. A forwarded message in this sense does not appear to have + come from the original sender, but is an entirely new message from + the forwarder of the message. On the other hand, forwarding is also + used to mean when a mail transport program gets a message and + forwards it on to a different destination for final delivery. Resent + header fields are not intended for use with either type of + forwarding. + + The resent originator fields indicate the mailbox of the person(s) or + system(s) that resent the message. As with the regular originator + fields, there are two forms: a simple "Resent-From:" form which + contains the mailbox of the individual doing the resending, and the + more complex form, when one individual (identified in the + "Resent-Sender:" field) resends a message on behalf of one or more + others (identified in the "Resent-From:" field). + + Note: When replying to a resent message, replies behave just as they + would with any other message, using the original "From:", + + + +Resnick Standards Track [Page 27] + +RFC 2822 Internet Message Format April 2001 + + + "Reply-To:", "Message-ID:", and other fields. The resent fields are + only informational and MUST NOT be used in the normal processing of + replies. + + The "Resent-Date:" indicates the date and time at which the resent + message is dispatched by the resender of the message. Like the + "Date:" field, it is not the date and time that the message was + actually transported. + + The "Resent-To:", "Resent-Cc:", and "Resent-Bcc:" fields function + identically to the "To:", "Cc:", and "Bcc:" fields respectively, + except that they indicate the recipients of the resent message, not + the recipients of the original message. + + The "Resent-Message-ID:" field provides a unique identifier for the + resent message. + +3.6.7. Trace fields + + The trace fields are a group of header fields consisting of an + optional "Return-Path:" field, and one or more "Received:" fields. + The "Return-Path:" header field contains a pair of angle brackets + that enclose an optional addr-spec. The "Received:" field contains a + (possibly empty) list of name/value pairs followed by a semicolon and + a date-time specification. The first item of the name/value pair is + defined by item-name, and the second item is either an addr-spec, an + atom, a domain, or a msg-id. Further restrictions may be applied to + the syntax of the trace fields by standards that provide for their + use, such as [RFC2821]. + +trace = [return] + 1*received + +return = "Return-Path:" path CRLF + +path = ([CFWS] "<" ([CFWS] / addr-spec) ">" [CFWS]) / + obs-path + +received = "Received:" name-val-list ";" date-time CRLF + +name-val-list = [CFWS] [name-val-pair *(CFWS name-val-pair)] + +name-val-pair = item-name CFWS item-value + +item-name = ALPHA *(["-"] (ALPHA / DIGIT)) + +item-value = 1*angle-addr / addr-spec / + atom / domain / msg-id + + + +Resnick Standards Track [Page 28] + +RFC 2822 Internet Message Format April 2001 + + + A full discussion of the Internet mail use of trace fields is + contained in [RFC2821]. For the purposes of this standard, the trace + fields are strictly informational, and any formal interpretation of + them is outside of the scope of this document. + +3.6.8. Optional fields + + Fields may appear in messages that are otherwise unspecified in this + standard. They MUST conform to the syntax of an optional-field. + This is a field name, made up of the printable US-ASCII characters + except SP and colon, followed by a colon, followed by any text which + conforms to unstructured. + + The field names of any optional-field MUST NOT be identical to any + field name specified elsewhere in this standard. + +optional-field = field-name ":" unstructured CRLF + +field-name = 1*ftext + +ftext = %d33-57 / ; Any character except + %d59-126 ; controls, SP, and + ; ":". + + For the purposes of this standard, any optional field is + uninterpreted. + +4. Obsolete Syntax + + Earlier versions of this standard allowed for different (usually more + liberal) syntax than is allowed in this version. Also, there have + been syntactic elements used in messages on the Internet whose + interpretation have never been documented. Though some of these + syntactic forms MUST NOT be generated according to the grammar in + section 3, they MUST be accepted and parsed by a conformant receiver. + This section documents many of these syntactic elements. Taking the + grammar in section 3 and adding the definitions presented in this + section will result in the grammar to use for interpretation of + messages. + + Note: This section identifies syntactic forms that any implementation + MUST reasonably interpret. However, there are certainly Internet + messages which do not conform to even the additional syntax given in + this section. The fact that a particular form does not appear in any + section of this document is not justification for computer programs + to crash or for malformed data to be irretrievably lost by any + implementation. To repeat an example, though this document requires + lines in messages to be no longer than 998 characters, silently + + + +Resnick Standards Track [Page 29] + +RFC 2822 Internet Message Format April 2001 + + + discarding the 999th and subsequent characters in a line without + warning would still be bad behavior for an implementation. It is up + to the implementation to deal with messages robustly. + + One important difference between the obsolete (interpreting) and the + current (generating) syntax is that in structured header field bodies + (i.e., between the colon and the CRLF of any structured header + field), white space characters, including folding white space, and + comments can be freely inserted between any syntactic tokens. This + allows many complex forms that have proven difficult for some + implementations to parse. + + Another key difference between the obsolete and the current syntax is + that the rule in section 3.2.3 regarding lines composed entirely of + white space in comments and folding white space does not apply. See + the discussion of folding white space in section 4.2 below. + + Finally, certain characters that were formerly allowed in messages + appear in this section. The NUL character (ASCII value 0) was once + allowed, but is no longer for compatibility reasons. CR and LF were + allowed to appear in messages other than as CRLF; this use is also + shown here. + + Other differences in syntax and semantics are noted in the following + sections. + +4.1. Miscellaneous obsolete tokens + + These syntactic elements are used elsewhere in the obsolete syntax or + in the main syntax. The obs-char and obs-qp elements each add ASCII + value 0. Bare CR and bare LF are added to obs-text and obs-utext. + The period character is added to obs-phrase. The obs-phrase-list + provides for "empty" elements in a comma-separated list of phrases. + + Note: The "period" (or "full stop") character (".") in obs-phrase is + not a form that was allowed in earlier versions of this or any other + standard. Period (nor any other character from specials) was not + allowed in phrase because it introduced a parsing difficulty + distinguishing between phrases and portions of an addr-spec (see + section 4.4). It appears here because the period character is + currently used in many messages in the display-name portion of + addresses, especially for initials in names, and therefore must be + interpreted properly. In the future, period may appear in the + regular syntax of phrase. + +obs-qp = "\" (%d0-127) + +obs-text = *LF *CR *(obs-char *LF *CR) + + + +Resnick Standards Track [Page 30] + +RFC 2822 Internet Message Format April 2001 + + +obs-char = %d0-9 / %d11 / ; %d0-127 except CR and + %d12 / %d14-127 ; LF + +obs-utext = obs-text + +obs-phrase = word *(word / "." / CFWS) + +obs-phrase-list = phrase / 1*([phrase] [CFWS] "," [CFWS]) [phrase] + + Bare CR and bare LF appear in messages with two different meanings. + In many cases, bare CR or bare LF are used improperly instead of CRLF + to indicate line separators. In other cases, bare CR and bare LF are + used simply as ASCII control characters with their traditional ASCII + meanings. + +4.2. Obsolete folding white space + + In the obsolete syntax, any amount of folding white space MAY be + inserted where the obs-FWS rule is allowed. This creates the + possibility of having two consecutive "folds" in a line, and + therefore the possibility that a line which makes up a folded header + field could be composed entirely of white space. + + obs-FWS = 1*WSP *(CRLF 1*WSP) + +4.3. Obsolete Date and Time + + The syntax for the obsolete date format allows a 2 digit year in the + date field and allows for a list of alphabetic time zone + specifications that were used in earlier versions of this standard. + It also permits comments and folding white space between many of the + tokens. + +obs-day-of-week = [CFWS] day-name [CFWS] + +obs-year = [CFWS] 2*DIGIT [CFWS] + +obs-month = CFWS month-name CFWS + +obs-day = [CFWS] 1*2DIGIT [CFWS] + +obs-hour = [CFWS] 2DIGIT [CFWS] + +obs-minute = [CFWS] 2DIGIT [CFWS] + +obs-second = [CFWS] 2DIGIT [CFWS] + +obs-zone = "UT" / "GMT" / ; Universal Time + + + +Resnick Standards Track [Page 31] + +RFC 2822 Internet Message Format April 2001 + + + ; North American UT + ; offsets + "EST" / "EDT" / ; Eastern: - 5/ - 4 + "CST" / "CDT" / ; Central: - 6/ - 5 + "MST" / "MDT" / ; Mountain: - 7/ - 6 + "PST" / "PDT" / ; Pacific: - 8/ - 7 + + %d65-73 / ; Military zones - "A" + %d75-90 / ; through "I" and "K" + %d97-105 / ; through "Z", both + %d107-122 ; upper and lower case + + Where a two or three digit year occurs in a date, the year is to be + interpreted as follows: If a two digit year is encountered whose + value is between 00 and 49, the year is interpreted by adding 2000, + ending up with a value between 2000 and 2049. If a two digit year is + encountered with a value between 50 and 99, or any three digit year + is encountered, the year is interpreted by adding 1900. + + In the obsolete time zone, "UT" and "GMT" are indications of + "Universal Time" and "Greenwich Mean Time" respectively and are both + semantically identical to "+0000". + + The remaining three character zones are the US time zones. The first + letter, "E", "C", "M", or "P" stands for "Eastern", "Central", + "Mountain" and "Pacific". The second letter is either "S" for + "Standard" time, or "D" for "Daylight" (or summer) time. Their + interpretations are as follows: + + EDT is semantically equivalent to -0400 + EST is semantically equivalent to -0500 + CDT is semantically equivalent to -0500 + CST is semantically equivalent to -0600 + MDT is semantically equivalent to -0600 + MST is semantically equivalent to -0700 + PDT is semantically equivalent to -0700 + PST is semantically equivalent to -0800 + + The 1 character military time zones were defined in a non-standard + way in [RFC822] and are therefore unpredictable in their meaning. + The original definitions of the military zones "A" through "I" are + equivalent to "+0100" through "+0900" respectively; "K", "L", and "M" + are equivalent to "+1000", "+1100", and "+1200" respectively; "N" + through "Y" are equivalent to "-0100" through "-1200" respectively; + and "Z" is equivalent to "+0000". However, because of the error in + [RFC822], they SHOULD all be considered equivalent to "-0000" unless + there is out-of-band information confirming their meaning. + + + + +Resnick Standards Track [Page 32] + +RFC 2822 Internet Message Format April 2001 + + + Other multi-character (usually between 3 and 5) alphabetic time zones + have been used in Internet messages. Any such time zone whose + meaning is not known SHOULD be considered equivalent to "-0000" + unless there is out-of-band information confirming their meaning. + +4.4. Obsolete Addressing + + There are three primary differences in addressing. First, mailbox + addresses were allowed to have a route portion before the addr-spec + when enclosed in "<" and ">". The route is simply a comma-separated + list of domain names, each preceded by "@", and the list terminated + by a colon. Second, CFWS were allowed between the period-separated + elements of local-part and domain (i.e., dot-atom was not used). In + addition, local-part is allowed to contain quoted-string in addition + to just atom. Finally, mailbox-list and address-list were allowed to + have "null" members. That is, there could be two or more commas in + such a list with nothing in between them. + +obs-angle-addr = [CFWS] "<" [obs-route] addr-spec ">" [CFWS] + +obs-route = [CFWS] obs-domain-list ":" [CFWS] + +obs-domain-list = "@" domain *(*(CFWS / "," ) [CFWS] "@" domain) + +obs-local-part = word *("." word) + +obs-domain = atom *("." atom) + +obs-mbox-list = 1*([mailbox] [CFWS] "," [CFWS]) [mailbox] + +obs-addr-list = 1*([address] [CFWS] "," [CFWS]) [address] + + When interpreting addresses, the route portion SHOULD be ignored. + +4.5. Obsolete header fields + + Syntactically, the primary difference in the obsolete field syntax is + that it allows multiple occurrences of any of the fields and they may + occur in any order. Also, any amount of white space is allowed + before the ":" at the end of the field name. + +obs-fields = *(obs-return / + obs-received / + obs-orig-date / + obs-from / + obs-sender / + obs-reply-to / + obs-to / + + + +Resnick Standards Track [Page 33] + +RFC 2822 Internet Message Format April 2001 + + + obs-cc / + obs-bcc / + obs-message-id / + obs-in-reply-to / + obs-references / + obs-subject / + obs-comments / + obs-keywords / + obs-resent-date / + obs-resent-from / + obs-resent-send / + obs-resent-rply / + obs-resent-to / + obs-resent-cc / + obs-resent-bcc / + obs-resent-mid / + obs-optional) + + Except for destination address fields (described in section 4.5.3), + the interpretation of multiple occurrences of fields is unspecified. + Also, the interpretation of trace fields and resent fields which do + not occur in blocks prepended to the message is unspecified as well. + Unless otherwise noted in the following sections, interpretation of + other fields is identical to the interpretation of their non-obsolete + counterparts in section 3. + +4.5.1. Obsolete origination date field + +obs-orig-date = "Date" *WSP ":" date-time CRLF + +4.5.2. Obsolete originator fields + +obs-from = "From" *WSP ":" mailbox-list CRLF + +obs-sender = "Sender" *WSP ":" mailbox CRLF + +obs-reply-to = "Reply-To" *WSP ":" mailbox-list CRLF + +4.5.3. Obsolete destination address fields + +obs-to = "To" *WSP ":" address-list CRLF + +obs-cc = "Cc" *WSP ":" address-list CRLF + +obs-bcc = "Bcc" *WSP ":" (address-list / [CFWS]) CRLF + + + + + + +Resnick Standards Track [Page 34] + +RFC 2822 Internet Message Format April 2001 + + + When multiple occurrences of destination address fields occur in a + message, they SHOULD be treated as if the address-list in the first + occurrence of the field is combined with the address lists of the + subsequent occurrences by adding a comma and concatenating. + +4.5.4. Obsolete identification fields + + The obsolete "In-Reply-To:" and "References:" fields differ from the + current syntax in that they allow phrase (words or quoted strings) to + appear. The obsolete forms of the left and right sides of msg-id + allow interspersed CFWS, making them syntactically identical to + local-part and domain respectively. + +obs-message-id = "Message-ID" *WSP ":" msg-id CRLF + +obs-in-reply-to = "In-Reply-To" *WSP ":" *(phrase / msg-id) CRLF + +obs-references = "References" *WSP ":" *(phrase / msg-id) CRLF + +obs-id-left = local-part + +obs-id-right = domain + + For purposes of interpretation, the phrases in the "In-Reply-To:" and + "References:" fields are ignored. + + Semantically, none of the optional CFWS surrounding the local-part + and the domain are part of the obs-id-left and obs-id-right + respectively. + +4.5.5. Obsolete informational fields + +obs-subject = "Subject" *WSP ":" unstructured CRLF + +obs-comments = "Comments" *WSP ":" unstructured CRLF + +obs-keywords = "Keywords" *WSP ":" obs-phrase-list CRLF + +4.5.6. Obsolete resent fields + + The obsolete syntax adds a "Resent-Reply-To:" field, which consists + of the field name, the optional comments and folding white space, the + colon, and a comma separated list of addresses. + +obs-resent-from = "Resent-From" *WSP ":" mailbox-list CRLF + +obs-resent-send = "Resent-Sender" *WSP ":" mailbox CRLF + + + + +Resnick Standards Track [Page 35] + +RFC 2822 Internet Message Format April 2001 + + +obs-resent-date = "Resent-Date" *WSP ":" date-time CRLF + +obs-resent-to = "Resent-To" *WSP ":" address-list CRLF + +obs-resent-cc = "Resent-Cc" *WSP ":" address-list CRLF + +obs-resent-bcc = "Resent-Bcc" *WSP ":" + (address-list / [CFWS]) CRLF + +obs-resent-mid = "Resent-Message-ID" *WSP ":" msg-id CRLF + +obs-resent-rply = "Resent-Reply-To" *WSP ":" address-list CRLF + + As with other resent fields, the "Resent-Reply-To:" field is to be + treated as trace information only. + +4.5.7. Obsolete trace fields + + The obs-return and obs-received are again given here as template + definitions, just as return and received are in section 3. Their + full syntax is given in [RFC2821]. + +obs-return = "Return-Path" *WSP ":" path CRLF + +obs-received = "Received" *WSP ":" name-val-list CRLF + +obs-path = obs-angle-addr + +4.5.8. Obsolete optional fields + +obs-optional = field-name *WSP ":" unstructured CRLF + +5. Security Considerations + + Care needs to be taken when displaying messages on a terminal or + terminal emulator. Powerful terminals may act on escape sequences + and other combinations of ASCII control characters with a variety of + consequences. They can remap the keyboard or permit other + modifications to the terminal which could lead to denial of service + or even damaged data. They can trigger (sometimes programmable) + answerback messages which can allow a message to cause commands to be + issued on the recipient's behalf. They can also effect the operation + of terminal attached devices such as printers. Message viewers may + wish to strip potentially dangerous terminal escape sequences from + the message prior to display. However, other escape sequences appear + in messages for useful purposes (cf. [RFC2045, RFC2046, RFC2047, + RFC2048, RFC2049, ISO2022]) and therefore should not be stripped + indiscriminately. + + + +Resnick Standards Track [Page 36] + +RFC 2822 Internet Message Format April 2001 + + + Transmission of non-text objects in messages raises additional + security issues. These issues are discussed in [RFC2045, RFC2046, + RFC2047, RFC2048, RFC2049]. + + Many implementations use the "Bcc:" (blind carbon copy) field + described in section 3.6.3 to facilitate sending messages to + recipients without revealing the addresses of one or more of the + addressees to the other recipients. Mishandling this use of "Bcc:" + has implications for confidential information that might be revealed, + which could eventually lead to security problems through knowledge of + even the existence of a particular mail address. For example, if + using the first method described in section 3.6.3, where the "Bcc:" + line is removed from the message, blind recipients have no explicit + indication that they have been sent a blind copy, except insofar as + their address does not appear in the message header. Because of + this, one of the blind addressees could potentially send a reply to + all of the shown recipients and accidentally reveal that the message + went to the blind recipient. When the second method from section + 3.6.3 is used, the blind recipient's address appears in the "Bcc:" + field of a separate copy of the message. If the "Bcc:" field sent + contains all of the blind addressees, all of the "Bcc:" recipients + will be seen by each "Bcc:" recipient. Even if a separate message is + sent to each "Bcc:" recipient with only the individual's address, + implementations still need to be careful to process replies to the + message as per section 3.6.3 so as not to accidentally reveal the + blind recipient to other recipients. + +6. Bibliography + + [ASCII] American National Standards Institute (ANSI), Coded + Character Set - 7-Bit American National Standard Code for + Information Interchange, ANSI X3.4, 1986. + + [ISO2022] International Organization for Standardization (ISO), + Information processing - ISO 7-bit and 8-bit coded + character sets - Code extension techniques, Third edition + - 1986-05-01, ISO 2022, 1986. + + [RFC822] Crocker, D., "Standard for the Format of ARPA Internet + Text Messages", RFC 822, August 1982. + + [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail + Extensions (MIME) Part One: Format of Internet Message + Bodies", RFC 2045, November 1996. + + [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail + Extensions (MIME) Part Two: Media Types", RFC 2046, + November 1996. + + + +Resnick Standards Track [Page 37] + +RFC 2822 Internet Message Format April 2001 + + + [RFC2047] Moore, K., "Multipurpose Internet Mail Extensions (MIME) + Part Three: Message Header Extensions for Non-ASCII Text", + RFC 2047, November 1996. + + [RFC2048] Freed, N., Klensin, J. and J. Postel, "Multipurpose + Internet Mail Extensions (MIME) Part Four: Format of + Internet Message Bodies", RFC 2048, November 1996. + + [RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet Mail + Extensions (MIME) Part Five: Conformance Criteria and + Examples", RFC 2049, November 1996. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2234] Crocker, D., Editor, and P. Overell, "Augmented BNF for + Syntax Specifications: ABNF", RFC 2234, November 1997. + + [RFC2821] Klensin, J., Editor, "Simple Mail Transfer Protocol", RFC + 2821, March 2001. + + [STD3] Braden, R., "Host Requirements", STD 3, RFC 1122 and RFC + 1123, October 1989. + + [STD12] Mills, D., "Network Time Protocol", STD 12, RFC 1119, + September 1989. + + [STD13] Mockapetris, P., "Domain Name System", STD 13, RFC 1034 + and RFC 1035, November 1987. + + [STD14] Partridge, C., "Mail Routing and the Domain System", STD + 14, RFC 974, January 1986. + +7. Editor's Address + + Peter W. Resnick + QUALCOMM Incorporated + 5775 Morehouse Drive + San Diego, CA 92121-1714 + USA + + Phone: +1 858 651 4478 + Fax: +1 858 651 1102 + EMail: presnick@qualcomm.com + + + + + + + +Resnick Standards Track [Page 38] + +RFC 2822 Internet Message Format April 2001 + + +8. Acknowledgements + + Many people contributed to this document. They included folks who + participated in the Detailed Revision and Update of Messaging + Standards (DRUMS) Working Group of the Internet Engineering Task + Force (IETF), the chair of DRUMS, the Area Directors of the IETF, and + people who simply sent their comments in via e-mail. The editor is + deeply indebted to them all and thanks them sincerely. The below + list includes everyone who sent e-mail concerning this document. + Hopefully, everyone who contributed is named here: + + Matti Aarnio Barry Finkel Larry Masinter + Tanaka Akira Erik Forsberg Denis McKeon + Russ Allbery Chuck Foster William P McQuillan + Eric Allman Paul Fox Alexey Melnikov + Harald Tveit Alvestrand Klaus M. Frank Perry E. Metzger + Ran Atkinson Ned Freed Steven Miller + Jos Backus Jochen Friedrich Keith Moore + Bruce Balden Randall C. Gellens John Gardiner Myers + Dave Barr Sukvinder Singh Gill Chris Newman + Alan Barrett Tim Goodwin John W. Noerenberg + John Beck Philip Guenther Eric Norman + J. Robert von Behren Tony Hansen Mike O'Dell + Jos den Bekker John Hawkinson Larry Osterman + D. J. Bernstein Philip Hazel Paul Overell + James Berriman Kai Henningsen Jacob Palme + Norbert Bollow Robert Herriot Michael A. Patton + Raj Bose Paul Hethmon Uzi Paz + Antony Bowesman Jim Hill Michael A. Quinlan + Scott Bradner Paul E. Hoffman Eric S. Raymond + Randy Bush Steve Hole Sam Roberts + Tom Byrer Kari Hurtta Hugh Sasse + Bruce Campbell Marco S. Hyman Bart Schaefer + Larry Campbell Ofer Inbar Tom Scola + W. J. Carpenter Olle Jarnefors Wolfgang Segmuller + Michael Chapman Kevin Johnson Nick Shelness + Richard Clayton Sudish Joseph John Stanley + Maurizio Codogno Maynard Kang Einar Stefferud + Jim Conklin Prabhat Keni Jeff Stephenson + R. Kelley Cook John C. Klensin Bernard Stern + Steve Coya Graham Klyne Peter Sylvester + Mark Crispin Brad Knowles Mark Symons + Dave Crocker Shuhei Kobayashi Eric Thomas + Matt Curtin Peter Koch Lee Thompson + Michael D'Errico Dan Kohn Karel De Vriendt + Cyrus Daboo Christian Kuhtz Matthew Wall + Jutta Degener Anand Kumria Rolf Weber + Mark Delany Steen Larsen Brent B. Welch + + + +Resnick Standards Track [Page 39] + +RFC 2822 Internet Message Format April 2001 + + + Steve Dorner Eliot Lear Dan Wing + Harold A. Driscoll Barry Leiba Jack De Winter + Michael Elkins Jay Levitt Gregory J. Woodhouse + Robert Elz Lars-Johan Liman Greg A. Woods + Johnny Eriksson Charles Lindsey Kazu Yamamoto + Erik E. Fair Pete Loshin Alain Zahm + Roger Fajman Simon Lyall Jamie Zawinski + Patrik Faltstrom Bill Manning Timothy S. Zurcher + Claus Andre Farber John Martin + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Resnick Standards Track [Page 40] + +RFC 2822 Internet Message Format April 2001 + + +Appendix A. Example messages + + This section presents a selection of messages. These are intended to + assist in the implementation of this standard, but should not be + taken as normative; that is to say, although the examples in this + section were carefully reviewed, if there happens to be a conflict + between these examples and the syntax described in sections 3 and 4 + of this document, the syntax in those sections is to be taken as + correct. + + Messages are delimited in this section between lines of "----". The + "----" lines are not part of the message itself. + +A.1. Addressing examples + + The following are examples of messages that might be sent between two + individuals. + +A.1.1. A message from one person to another with simple addressing + + This could be called a canonical message. It has a single author, + John Doe, a single recipient, Mary Smith, a subject, the date, a + message identifier, and a textual message in the body. + +---- +From: John Doe +To: Mary Smith +Subject: Saying Hello +Date: Fri, 21 Nov 1997 09:55:06 -0600 +Message-ID: <1234@local.machine.example> + +This is a message just to say hello. +So, "Hello". +---- + + + + + + + + + + + + + + + + + +Resnick Standards Track [Page 41] + +RFC 2822 Internet Message Format April 2001 + + + If John's secretary Michael actually sent the message, though John + was the author and replies to this message should go back to him, the + sender field would be used: + +---- +From: John Doe +Sender: Michael Jones +To: Mary Smith +Subject: Saying Hello +Date: Fri, 21 Nov 1997 09:55:06 -0600 +Message-ID: <1234@local.machine.example> + +This is a message just to say hello. +So, "Hello". +---- + +A.1.2. Different types of mailboxes + + This message includes multiple addresses in the destination fields + and also uses several different forms of addresses. + +---- +From: "Joe Q. Public" +To: Mary Smith , jdoe@example.org, Who? +Cc: , "Giant; \"Big\" Box" +Date: Tue, 1 Jul 2003 10:52:37 +0200 +Message-ID: <5678.21-Nov-1997@example.com> + +Hi everyone. +---- + + Note that the display names for Joe Q. Public and Giant; "Big" Box + needed to be enclosed in double-quotes because the former contains + the period and the latter contains both semicolon and double-quote + characters (the double-quote characters appearing as quoted-pair + construct). Conversely, the display name for Who? could appear + without them because the question mark is legal in an atom. Notice + also that jdoe@example.org and boss@nil.test have no display names + associated with them at all, and jdoe@example.org uses the simpler + address form without the angle brackets. + + + + + + + + + + + +Resnick Standards Track [Page 42] + +RFC 2822 Internet Message Format April 2001 + + +A.1.3. Group addresses + +---- +From: Pete +To: A Group:Chris Jones ,joe@where.test,John ; +Cc: Undisclosed recipients:; +Date: Thu, 13 Feb 1969 23:32:54 -0330 +Message-ID: + +Testing. +---- + + In this message, the "To:" field has a single group recipient named A + Group which contains 3 addresses, and a "Cc:" field with an empty + group recipient named Undisclosed recipients. + +A.2. Reply messages + + The following is a series of three messages that make up a + conversation thread between John and Mary. John firsts sends a + message to Mary, Mary then replies to John's message, and then John + replies to Mary's reply message. + + Note especially the "Message-ID:", "References:", and "In-Reply-To:" + fields in each message. + +---- +From: John Doe +To: Mary Smith +Subject: Saying Hello +Date: Fri, 21 Nov 1997 09:55:06 -0600 +Message-ID: <1234@local.machine.example> + +This is a message just to say hello. +So, "Hello". +---- + + + + + + + + + + + + + + + +Resnick Standards Track [Page 43] + +RFC 2822 Internet Message Format April 2001 + + + When sending replies, the Subject field is often retained, though + prepended with "Re: " as described in section 3.6.5. + +---- +From: Mary Smith +To: John Doe +Reply-To: "Mary Smith: Personal Account" +Subject: Re: Saying Hello +Date: Fri, 21 Nov 1997 10:01:10 -0600 +Message-ID: <3456@example.net> +In-Reply-To: <1234@local.machine.example> +References: <1234@local.machine.example> + +This is a reply to your hello. +---- + + Note the "Reply-To:" field in the above message. When John replies + to Mary's message above, the reply should go to the address in the + "Reply-To:" field instead of the address in the "From:" field. + +---- +To: "Mary Smith: Personal Account" +From: John Doe +Subject: Re: Saying Hello +Date: Fri, 21 Nov 1997 11:00:00 -0600 +Message-ID: +In-Reply-To: <3456@example.net> +References: <1234@local.machine.example> <3456@example.net> + +This is a reply to your reply. +---- + +A.3. Resent messages + + Start with the message that has been used as an example several + times: + +---- +From: John Doe +To: Mary Smith +Subject: Saying Hello +Date: Fri, 21 Nov 1997 09:55:06 -0600 +Message-ID: <1234@local.machine.example> + +This is a message just to say hello. +So, "Hello". +---- + + + + +Resnick Standards Track [Page 44] + +RFC 2822 Internet Message Format April 2001 + + + Say that Mary, upon receiving this message, wishes to send a copy of + the message to Jane such that (a) the message would appear to have + come straight from John; (b) if Jane replies to the message, the + reply should go back to John; and (c) all of the original + information, like the date the message was originally sent to Mary, + the message identifier, and the original addressee, is preserved. In + this case, resent fields are prepended to the message: + +---- +Resent-From: Mary Smith +Resent-To: Jane Brown +Resent-Date: Mon, 24 Nov 1997 14:22:01 -0800 +Resent-Message-ID: <78910@example.net> +From: John Doe +To: Mary Smith +Subject: Saying Hello +Date: Fri, 21 Nov 1997 09:55:06 -0600 +Message-ID: <1234@local.machine.example> + +This is a message just to say hello. +So, "Hello". +---- + + If Jane, in turn, wished to resend this message to another person, + she would prepend her own set of resent header fields to the above + and send that. + + + + + + + + + + + + + + + + + + + + + + + + + +Resnick Standards Track [Page 45] + +RFC 2822 Internet Message Format April 2001 + + +A.4. Messages with trace fields + + As messages are sent through the transport system as described in + [RFC2821], trace fields are prepended to the message. The following + is an example of what those trace fields might look like. Note that + there is some folding white space in the first one since these lines + can be long. + +---- +Received: from x.y.test + by example.net + via TCP + with ESMTP + id ABC12345 + for ; 21 Nov 1997 10:05:43 -0600 +Received: from machine.example by x.y.test; 21 Nov 1997 10:01:22 -0600 +From: John Doe +To: Mary Smith +Subject: Saying Hello +Date: Fri, 21 Nov 1997 09:55:06 -0600 +Message-ID: <1234@local.machine.example> + +This is a message just to say hello. +So, "Hello". +---- + + + + + + + + + + + + + + + + + + + + + + + + + + +Resnick Standards Track [Page 46] + +RFC 2822 Internet Message Format April 2001 + + +A.5. White space, comments, and other oddities + + White space, including folding white space, and comments can be + inserted between many of the tokens of fields. Taking the example + from A.1.3, white space and comments can be inserted into all of the + fields. + +---- +From: Pete(A wonderful \) chap) +To:A Group(Some people) + :Chris Jones , + joe@example.org, + John (my dear friend); (the end of the group) +Cc:(Empty list)(start)Undisclosed recipients :(nobody(that I know)) ; +Date: Thu, + 13 + Feb + 1969 + 23:32 + -0330 (Newfoundland Time) +Message-ID: + +Testing. +---- + + The above example is aesthetically displeasing, but perfectly legal. + Note particularly (1) the comments in the "From:" field (including + one that has a ")" character appearing as part of a quoted-pair); (2) + the white space absent after the ":" in the "To:" field as well as + the comment and folding white space after the group name, the special + character (".") in the comment in Chris Jones's address, and the + folding white space before and after "joe@example.org,"; (3) the + multiple and nested comments in the "Cc:" field as well as the + comment immediately following the ":" after "Cc"; (4) the folding + white space (but no comments except at the end) and the missing + seconds in the time of the date field; and (5) the white space before + (but not within) the identifier in the "Message-ID:" field. + +A.6. Obsoleted forms + + The following are examples of obsolete (that is, the "MUST NOT + generate") syntactic elements described in section 4 of this + document. + + + + + + + + +Resnick Standards Track [Page 47] + +RFC 2822 Internet Message Format April 2001 + + +A.6.1. Obsolete addressing + + Note in the below example the lack of quotes around Joe Q. Public, + the route that appears in the address for Mary Smith, the two commas + that appear in the "To:" field, and the spaces that appear around the + "." in the jdoe address. + +---- +From: Joe Q. Public +To: Mary Smith <@machine.tld:mary@example.net>, , jdoe@test . example +Date: Tue, 1 Jul 2003 10:52:37 +0200 +Message-ID: <5678.21-Nov-1997@example.com> + +Hi everyone. +---- + +A.6.2. Obsolete dates + + The following message uses an obsolete date format, including a non- + numeric time zone and a two digit year. Note that although the + day-of-week is missing, that is not specific to the obsolete syntax; + it is optional in the current syntax as well. + +---- +From: John Doe +To: Mary Smith +Subject: Saying Hello +Date: 21 Nov 97 09:55:06 GMT +Message-ID: <1234@local.machine.example> + +This is a message just to say hello. +So, "Hello". +---- + +A.6.3. Obsolete white space and comments + + White space and comments can appear between many more elements than + in the current syntax. Also, folding lines that are made up entirely + of white space are legal. + + + + + + + + + + + + +Resnick Standards Track [Page 48] + +RFC 2822 Internet Message Format April 2001 + + +---- +From : John Doe +To : Mary Smith +__ + +Subject : Saying Hello +Date : Fri, 21 Nov 1997 09(comment): 55 : 06 -0600 +Message-ID : <1234 @ local(blah) .machine .example> + +This is a message just to say hello. +So, "Hello". +---- + + Note especially the second line of the "To:" field. It starts with + two space characters. (Note that "__" represent blank spaces.) + Therefore, it is considered part of the folding as described in + section 4.2. Also, the comments and white space throughout + addresses, dates, and message identifiers are all part of the + obsolete syntax. + +Appendix B. Differences from earlier standards + + This appendix contains a list of changes that have been made in the + Internet Message Format from earlier standards, specifically [RFC822] + and [STD3]. Items marked with an asterisk (*) below are items which + appear in section 4 of this document and therefore can no longer be + generated. + + 1. Period allowed in obsolete form of phrase. + 2. ABNF moved out of document to [RFC2234]. + 3. Four or more digits allowed for year. + 4. Header field ordering (and lack thereof) made explicit. + 5. Encrypted header field removed. + 6. Received syntax loosened to allow any token/value pair. + 7. Specifically allow and give meaning to "-0000" time zone. + 8. Folding white space is not allowed between every token. + 9. Requirement for destinations removed. + 10. Forwarding and resending redefined. + 11. Extension header fields no longer specifically called out. + 12. ASCII 0 (null) removed.* + 13. Folding continuation lines cannot contain only white space.* + 14. Free insertion of comments not allowed in date.* + 15. Non-numeric time zones not allowed.* + 16. Two digit years not allowed.* + 17. Three digit years interpreted, but not allowed for generation. + 18. Routes in addresses not allowed.* + 19. CFWS within local-parts and domains not allowed.* + 20. Empty members of address lists not allowed.* + + + +Resnick Standards Track [Page 49] + +RFC 2822 Internet Message Format April 2001 + + + 21. Folding white space between field name and colon not allowed.* + 22. Comments between field name and colon not allowed. + 23. Tightened syntax of in-reply-to and references.* + 24. CFWS within msg-id not allowed.* + 25. Tightened semantics of resent fields as informational only. + 26. Resent-Reply-To not allowed.* + 27. No multiple occurrences of fields (except resent and received).* + 28. Free CR and LF not allowed.* + 29. Routes in return path not allowed.* + 30. Line length limits specified. + 31. Bcc more clearly specified. + +Appendix C. Notices + + Intellectual Property + + The IETF takes no position regarding the validity or scope of any + intellectual property or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; neither does it represent that it + has made any effort to identify any such rights. Information on the + IETF's procedures with respect to rights in standards-track and + standards-related documentation can be found in BCP-11. Copies of + claims of rights made available for publication and any assurances of + licenses to be made available, or the result of an attempt made to + obtain a general license or permission for the use of such + proprietary rights by implementors or users of this specification can + be obtained from the IETF Secretariat. + + + + + + + + + + + + + + + + + + + + + + +Resnick Standards Track [Page 50] + +RFC 2822 Internet Message Format April 2001 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2001). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Resnick Standards Track [Page 51] + diff --git a/RFCs/rfc3207.txt b/RFCs/rfc3207.txt new file mode 100644 index 0000000..dfcd36b --- /dev/null +++ b/RFCs/rfc3207.txt @@ -0,0 +1,507 @@ + + + + + + +Network Working Group P. Hoffman +Request for Comments: 3207 Internet Mail Consortium +Obsoletes: 2487 February 2002 +Category: Standards Track + + + SMTP Service Extension for + Secure SMTP over Transport Layer Security + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2002). All Rights Reserved. + +Abstract + + This document describes an extension to the SMTP (Simple Mail + Transfer Protocol) service that allows an SMTP server and client to + use TLS (Transport Layer Security) to provide private, authenticated + communication over the Internet. This gives SMTP agents the ability + to protect some or all of their communications from eavesdroppers and + attackers. + +1. Introduction + + SMTP [RFC2821] servers and clients normally communicate in the clear + over the Internet. In many cases, this communication goes through + one or more router that is not controlled or trusted by either + entity. Such an untrusted router might allow a third party to + monitor or alter the communications between the server and client. + + Further, there is often a desire for two SMTP agents to be able to + authenticate each others' identities. For example, a secure SMTP + server might only allow communications from other SMTP agents it + knows, or it might act differently for messages received from an + agent it knows than from one it doesn't know. + + + + + + + + +Hoffman Standards Track [Page 1] + +RFC 3207 SMTP Service Extension - Secure SMTP over TLS February 2002 + + + TLS [TLS], more commonly known as SSL, is a popular mechanism for + enhancing TCP communications with privacy and authentication. TLS is + in wide use with the HTTP protocol, and is also being used for adding + security to many other common protocols that run over TCP. + + This document obsoletes RFC 2487. + +1.1 Terminology + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [RFC2119]. + +2. STARTTLS Extension + + The STARTTLS extension to SMTP is laid out as follows: + + (1) the name of the SMTP service defined here is STARTTLS; + + (2) the EHLO keyword value associated with the extension is STARTTLS; + + (3) the STARTTLS keyword has no parameters; + + (4) a new SMTP verb, "STARTTLS", is defined; + + (5) no additional parameters are added to any SMTP command. + +3. The STARTTLS Keyword + + The STARTTLS keyword is used to tell the SMTP client that the SMTP + server is currently able to negotiate the use of TLS. It takes no + parameters. + +4. The STARTTLS Command + + The format for the STARTTLS command is: + + STARTTLS + + with no parameters. + + After the client gives the STARTTLS command, the server responds with + one of the following reply codes: + + 220 Ready to start TLS + 501 Syntax error (no parameters allowed) + 454 TLS not available due to temporary reason + + + + +Hoffman Standards Track [Page 2] + +RFC 3207 SMTP Service Extension - Secure SMTP over TLS February 2002 + + + If the client receives the 454 response, the client must decide + whether or not to continue the SMTP session. Such a decision is + based on local policy. For instance, if TLS was being used for + client authentication, the client might try to continue the session, + in case the server allows it even with no authentication. However, + if TLS was being negotiated for encryption, a client that gets a 454 + response needs to decide whether to send the message anyway with no + TLS encryption, whether to wait and try again later, or whether to + give up and notify the sender of the error. + + A publicly-referenced SMTP server MUST NOT require use of the + STARTTLS extension in order to deliver mail locally. This rule + prevents the STARTTLS extension from damaging the interoperability of + the Internet's SMTP infrastructure. A publicly-referenced SMTP + server is an SMTP server which runs on port 25 of an Internet host + listed in the MX record (or A record if an MX record is not present) + for the domain name on the right hand side of an Internet mail + address. + + Any SMTP server may refuse to accept messages for relay based on + authentication supplied during the TLS negotiation. An SMTP server + that is not publicly referenced may refuse to accept any messages for + relay or local delivery based on authentication supplied during the + TLS negotiation. + + A SMTP server that is not publicly referenced may choose to require + that the client perform a TLS negotiation before accepting any + commands. In this case, the server SHOULD return the reply code: + + 530 Must issue a STARTTLS command first + + to every command other than NOOP, EHLO, STARTTLS, or QUIT. If the + client and server are using the ENHANCEDSTATUSCODES ESMTP extension + [RFC2034], the status code to be returned SHOULD be 5.7.0. + + After receiving a 220 response to a STARTTLS command, the client MUST + start the TLS negotiation before giving any other SMTP commands. If, + after having issued the STARTTLS command, the client finds out that + some failure prevents it from actually starting a TLS handshake, then + it SHOULD abort the connection. + + If the SMTP client is using pipelining as defined in RFC 2920, the + STARTTLS command must be the last command in a group. + + + + + + + + +Hoffman Standards Track [Page 3] + +RFC 3207 SMTP Service Extension - Secure SMTP over TLS February 2002 + + +4.1 Processing After the STARTTLS Command + + After the TLS handshake has been completed, both parties MUST + immediately decide whether or not to continue based on the + authentication and privacy achieved. The SMTP client and server may + decide to move ahead even if the TLS negotiation ended with no + authentication and/or no privacy because most SMTP services are + performed with no authentication and no privacy, but some SMTP + clients or servers may want to continue only if a particular level of + authentication and/or privacy was achieved. + + If the SMTP client decides that the level of authentication or + privacy is not high enough for it to continue, it SHOULD issue an + SMTP QUIT command immediately after the TLS negotiation is complete. + If the SMTP server decides that the level of authentication or + privacy is not high enough for it to continue, it SHOULD reply to + every SMTP command from the client (other than a QUIT command) with + the 554 reply code (with a possible text string such as "Command + refused due to lack of security"). + + The decision of whether or not to believe the authenticity of the + other party in a TLS negotiation is a local matter. However, some + general rules for the decisions are: + + - A SMTP client would probably only want to authenticate an SMTP + server whose server certificate has a domain name that is the + domain name that the client thought it was connecting to. + - A publicly-referenced SMTP server would probably want to accept + any verifiable certificate from an SMTP client, and would possibly + want to put distinguishing information about the certificate in + the Received header of messages that were relayed or submitted + from the client. + +4.2 Result of the STARTTLS Command + + Upon completion of the TLS handshake, the SMTP protocol is reset to + the initial state (the state in SMTP after a server issues a 220 + service ready greeting). The server MUST discard any knowledge + obtained from the client, such as the argument to the EHLO command, + which was not obtained from the TLS negotiation itself. The client + MUST discard any knowledge obtained from the server, such as the list + of SMTP service extensions, which was not obtained from the TLS + negotiation itself. The client SHOULD send an EHLO command as the + first command after a successful TLS negotiation. + + The list of SMTP service extensions returned in response to an EHLO + command received after the TLS handshake MAY be different than the + list returned before the TLS handshake. For example, an SMTP server + + + +Hoffman Standards Track [Page 4] + +RFC 3207 SMTP Service Extension - Secure SMTP over TLS February 2002 + + + might not want to advertise support for a particular SASL mechanism + [SASL] unless a client has sent an appropriate client certificate + during a TLS handshake. + + Both the client and the server MUST know if there is a TLS session + active. A client MUST NOT attempt to start a TLS session if a TLS + session is already active. A server MUST NOT return the STARTTLS + extension in response to an EHLO command received after a TLS + handshake has completed. + +4.3 STARTTLS on the Submission Port + + STARTTLS is a valid ESMTP extension when used on the Submission port, + as defined in [RFC2476]. In fact, since the submission port is by + definition not a publicly referenced SMTP server, the STARTTLS + extension can be particularly useful by providing security and + authentication for this service. + +5. Usage Example + + The following dialog illustrates how a client and server can start a + TLS session: + + S: + C: + S: 220 mail.imc.org SMTP service ready + C: EHLO mail.example.com + S: 250-mail.imc.org offers a warm hug of welcome + S: 250-8BITMIME + S: 250-STARTTLS + S: 250 DSN + C: STARTTLS + S: 220 Go ahead + C: + C & S: + C & S: + C: EHLO mail.example.com + S: 250-mail.imc.org touches your hand gently for a moment + S: 250-8BITMIME + S: 250 DSN + +6. Security Considerations + + It should be noted that SMTP is not an end-to-end mechanism. Thus, + if an SMTP client/server pair decide to add TLS privacy, they are not + securing the transport from the originating mail user agent to the + recipient. Further, because delivery of a single piece of mail may + go between more than two SMTP servers, adding TLS privacy to one pair + + + +Hoffman Standards Track [Page 5] + +RFC 3207 SMTP Service Extension - Secure SMTP over TLS February 2002 + + + of servers does not mean that the entire SMTP chain has been made + private. Further, just because an SMTP server can authenticate an + SMTP client, it does not mean that the mail from the SMTP client was + authenticated by the SMTP client when the client received it. + + Both the SMTP client and server must check the result of the TLS + negotiation to see whether an acceptable degree of authentication and + privacy was achieved. Ignoring this step completely invalidates + using TLS for security. The decision about whether acceptable + authentication or privacy was achieved is made locally, is + implementation-dependent, and is beyond the scope of this document. + + The SMTP client and server should note carefully the result of the + TLS negotiation. If the negotiation results in no privacy, or if it + results in privacy using algorithms or key lengths that are deemed + not strong enough, or if the authentication is not good enough for + either party, the client may choose to end the SMTP session with an + immediate QUIT command, or the server may choose to not accept any + more SMTP commands. + + A man-in-the-middle attack can be launched by deleting the "250 + STARTTLS" response from the server. This would cause the client not + to try to start a TLS session. Another man-in-the-middle attack is + to allow the server to announce its STARTTLS capability, but to alter + the client's request to start TLS and the server's response. In + order to defend against such attacks both clients and servers MUST be + able to be configured to require successful TLS negotiation of an + appropriate cipher suite for selected hosts before messages can be + successfully transferred. The additional option of using TLS when + possible SHOULD also be provided. An implementation MAY provide the + ability to record that TLS was used in communicating with a given + peer and generating a warning if it is not used in a later session. + + If the TLS negotiation fails or if the client receives a 454 + response, the client has to decide what to do next. There are three + main choices: go ahead with the rest of the SMTP session, retry TLS + at a later time, or give up and return the mail to the sender. If a + failure or error occurs, the client can assume that the server may be + able to negotiate TLS in the future, and should try negotiate TLS in + a later session, until some locally-chosen timeout occurs, at which + point, the client should return the mail to the sender. However, if + the client and server were only using TLS for authentication, the + client may want to proceed with the SMTP session, in case some of the + operations the client wanted to perform are accepted by the server + even if the client is unauthenticated. + + Before the TLS handshake has begun, any protocol interactions are + performed in the clear and may be modified by an active attacker. + + + +Hoffman Standards Track [Page 6] + +RFC 3207 SMTP Service Extension - Secure SMTP over TLS February 2002 + + + For this reason, clients and servers MUST discard any knowledge + obtained prior to the start of the TLS handshake upon completion of + the TLS handshake. + + The STARTTLS extension is not suitable for authenticating the author + of an email message unless every hop in the delivery chain, including + the submission to the first SMTP server, is authenticated. Another + proposal [SMTP-AUTH] can be used to authenticate delivery and MIME + security multiparts [MIME-SEC] can be used to authenticate the author + of an email message. In addition, the [SMTP-AUTH] proposal offers + simpler and more flexible options to authenticate an SMTP client and + the SASL EXTERNAL mechanism [SASL] MAY be used in conjunction with + the STARTTLS command to provide an authorization identity. + +7. References + + [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, + April 2001. + + [RFC2034] Freed, N., "SMTP Service Extension for Returning Enhanced + Error Codes", RFC 2034, October 1996. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2476] Gellens, R. and J. Klensin, "Message Submission", RFC + 2476, December 1998. + + [SASL] Myers, J., "Simple Authentication and Security Layer + (SASL)", RFC 2222, October 1997. + + [SMTP-AUTH] Myers, J., "SMTP Service Extension for Authentication", + RFC 2554, March 1999. + + [TLS] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", + RFC 2246, January 1999. + + + + + + + + + + + + + + + +Hoffman Standards Track [Page 7] + +RFC 3207 SMTP Service Extension - Secure SMTP over TLS February 2002 + + +Appendix + + This document is a revision of RFC 2487, which is a Proposed + Standard. The changes from that document are: + + - Section 5 and 7: More discussion of the man-in-the-middle attacks + - Section 5: Additional discussion of when a server should and + should not advertise the STARTTLS extension + - Section 5: Changed the requirements on SMTP clients after + receiving a 220 response. + - Section 5.1: Clarified description of verifying certificates. + - Section 5.3: Added the section on "STARTTLS on the Submission + Port" + - Section 6: Bug fix in the example to indicate that the client + needs to issue a new EHLO command, as already is described in + section 5.2. + - Section 7: Clarification of the paragraph on acceptable degree of + privacy. Significant change to the discussion of how to avoid a + man-in-the-middle attack. + - Section A: Update reference from RFC 821 to RFC 2821. + +Author's Address + + Paul Hoffman + Internet Mail Consortium + 127 Segre Place + Santa Cruz, CA 95060 + + Phone: (831) 426-9827 + EMail: phoffman@imc.org + + + + + + + + + + + + + + + + + + + + + +Hoffman Standards Track [Page 8] + +RFC 3207 SMTP Service Extension - Secure SMTP over TLS February 2002 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2002). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Hoffman Standards Track [Page 9] + diff --git a/RFCs/rfc3501.txt b/RFCs/rfc3501.txt new file mode 100644 index 0000000..5ab48e1 --- /dev/null +++ b/RFCs/rfc3501.txt @@ -0,0 +1,6051 @@ + + + + + + +Network Working Group M. Crispin +Request for Comments: 3501 University of Washington +Obsoletes: 2060 March 2003 +Category: Standards Track + + + INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1 + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2003). All Rights Reserved. + +Abstract + + The Internet Message Access Protocol, Version 4rev1 (IMAP4rev1) + allows a client to access and manipulate electronic mail messages on + a server. IMAP4rev1 permits manipulation of mailboxes (remote + message folders) in a way that is functionally equivalent to local + folders. IMAP4rev1 also provides the capability for an offline + client to resynchronize with the server. + + IMAP4rev1 includes operations for creating, deleting, and renaming + mailboxes, checking for new messages, permanently removing messages, + setting and clearing flags, RFC 2822 and RFC 2045 parsing, searching, + and selective fetching of message attributes, texts, and portions + thereof. Messages in IMAP4rev1 are accessed by the use of numbers. + These numbers are either message sequence numbers or unique + identifiers. + + IMAP4rev1 supports a single server. A mechanism for accessing + configuration information to support multiple IMAP4rev1 servers is + discussed in RFC 2244. + + IMAP4rev1 does not specify a means of posting mail; this function is + handled by a mail transfer protocol such as RFC 2821. + + + + + + + + +Crispin Standards Track [Page 1] + +RFC 3501 IMAPv4 March 2003 + + +Table of Contents + + IMAP4rev1 Protocol Specification ................................ 4 + 1. How to Read This Document ............................... 4 + 1.1. Organization of This Document ........................... 4 + 1.2. Conventions Used in This Document ....................... 4 + 1.3. Special Notes to Implementors ........................... 5 + 2. Protocol Overview ....................................... 6 + 2.1. Link Level .............................................. 6 + 2.2. Commands and Responses .................................. 6 + 2.2.1. Client Protocol Sender and Server Protocol Receiver ..... 6 + 2.2.2. Server Protocol Sender and Client Protocol Receiver ..... 7 + 2.3. Message Attributes ...................................... 8 + 2.3.1. Message Numbers ......................................... 8 + 2.3.1.1. Unique Identifier (UID) Message Attribute ....... 8 + 2.3.1.2. Message Sequence Number Message Attribute ....... 10 + 2.3.2. Flags Message Attribute ................................. 11 + 2.3.3. Internal Date Message Attribute ......................... 12 + 2.3.4. [RFC-2822] Size Message Attribute ....................... 12 + 2.3.5. Envelope Structure Message Attribute .................... 12 + 2.3.6. Body Structure Message Attribute ........................ 12 + 2.4. Message Texts ........................................... 13 + 3. State and Flow Diagram .................................. 13 + 3.1. Not Authenticated State ................................. 13 + 3.2. Authenticated State ..................................... 13 + 3.3. Selected State .......................................... 13 + 3.4. Logout State ............................................ 14 + 4. Data Formats ............................................ 16 + 4.1. Atom .................................................... 16 + 4.2. Number .................................................. 16 + 4.3. String .................................................. 16 + 4.3.1. 8-bit and Binary Strings ................................ 17 + 4.4. Parenthesized List ...................................... 17 + 4.5. NIL ..................................................... 17 + 5. Operational Considerations .............................. 18 + 5.1. Mailbox Naming .......................................... 18 + 5.1.1. Mailbox Hierarchy Naming ................................ 19 + 5.1.2. Mailbox Namespace Naming Convention ..................... 19 + 5.1.3. Mailbox International Naming Convention ................. 19 + 5.2. Mailbox Size and Message Status Updates ................. 21 + 5.3. Response when no Command in Progress .................... 21 + 5.4. Autologout Timer ........................................ 22 + 5.5. Multiple Commands in Progress ........................... 22 + 6. Client Commands ........................................ 23 + 6.1. Client Commands - Any State ............................ 24 + 6.1.1. CAPABILITY Command ..................................... 24 + 6.1.2. NOOP Command ........................................... 25 + 6.1.3. LOGOUT Command ......................................... 26 + + + +Crispin Standards Track [Page 2] + +RFC 3501 IMAPv4 March 2003 + + + 6.2. Client Commands - Not Authenticated State .............. 26 + 6.2.1. STARTTLS Command ....................................... 27 + 6.2.2. AUTHENTICATE Command ................................... 28 + 6.2.3. LOGIN Command .......................................... 30 + 6.3. Client Commands - Authenticated State .................. 31 + 6.3.1. SELECT Command ......................................... 32 + 6.3.2. EXAMINE Command ........................................ 34 + 6.3.3. CREATE Command ......................................... 34 + 6.3.4. DELETE Command ......................................... 35 + 6.3.5. RENAME Command ......................................... 37 + 6.3.6. SUBSCRIBE Command ...................................... 39 + 6.3.7. UNSUBSCRIBE Command .................................... 39 + 6.3.8. LIST Command ........................................... 40 + 6.3.9. LSUB Command ........................................... 43 + 6.3.10. STATUS Command ......................................... 44 + 6.3.11. APPEND Command ......................................... 46 + 6.4. Client Commands - Selected State ....................... 47 + 6.4.1. CHECK Command .......................................... 47 + 6.4.2. CLOSE Command .......................................... 48 + 6.4.3. EXPUNGE Command ........................................ 49 + 6.4.4. SEARCH Command ......................................... 49 + 6.4.5. FETCH Command .......................................... 54 + 6.4.6. STORE Command .......................................... 58 + 6.4.7. COPY Command ........................................... 59 + 6.4.8. UID Command ............................................ 60 + 6.5. Client Commands - Experimental/Expansion ............... 62 + 6.5.1. X Command ........................................ 62 + 7. Server Responses ....................................... 62 + 7.1. Server Responses - Status Responses .................... 63 + 7.1.1. OK Response ............................................ 65 + 7.1.2. NO Response ............................................ 66 + 7.1.3. BAD Response ........................................... 66 + 7.1.4. PREAUTH Response ....................................... 67 + 7.1.5. BYE Response ........................................... 67 + 7.2. Server Responses - Server and Mailbox Status ........... 68 + 7.2.1. CAPABILITY Response .................................... 68 + 7.2.2. LIST Response .......................................... 69 + 7.2.3. LSUB Response .......................................... 70 + 7.2.4 STATUS Response ........................................ 70 + 7.2.5. SEARCH Response ........................................ 71 + 7.2.6. FLAGS Response ......................................... 71 + 7.3. Server Responses - Mailbox Size ........................ 71 + 7.3.1. EXISTS Response ........................................ 71 + 7.3.2. RECENT Response ........................................ 72 + 7.4. Server Responses - Message Status ...................... 72 + 7.4.1. EXPUNGE Response ....................................... 72 + 7.4.2. FETCH Response ......................................... 73 + 7.5. Server Responses - Command Continuation Request ........ 79 + + + +Crispin Standards Track [Page 3] + +RFC 3501 IMAPv4 March 2003 + + + 8. Sample IMAP4rev1 connection ............................ 80 + 9. Formal Syntax .......................................... 81 + 10. Author's Note .......................................... 92 + 11. Security Considerations ................................ 92 + 11.1. STARTTLS Security Considerations ....................... 92 + 11.2. Other Security Considerations .......................... 93 + 12. IANA Considerations .................................... 94 + Appendices ..................................................... 95 + A. References ............................................. 95 + B. Changes from RFC 2060 .................................. 97 + C. Key Word Index ......................................... 103 + Author's Address ............................................... 107 + Full Copyright Statement ....................................... 108 + +IMAP4rev1 Protocol Specification + +1. How to Read This Document + +1.1. Organization of This Document + + This document is written from the point of view of the implementor of + an IMAP4rev1 client or server. Beyond the protocol overview in + section 2, it is not optimized for someone trying to understand the + operation of the protocol. The material in sections 3 through 5 + provides the general context and definitions with which IMAP4rev1 + operates. + + Sections 6, 7, and 9 describe the IMAP commands, responses, and + syntax, respectively. The relationships among these are such that it + is almost impossible to understand any of them separately. In + particular, do not attempt to deduce command syntax from the command + section alone; instead refer to the Formal Syntax section. + +1.2. Conventions Used in This Document + + "Conventions" are basic principles or procedures. Document + conventions are noted in this section. + + In examples, "C:" and "S:" indicate lines sent by the client and + server respectively. + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "MAY", and "OPTIONAL" in this document are to + be interpreted as described in [KEYWORDS]. + + The word "can" (not "may") is used to refer to a possible + circumstance or situation, as opposed to an optional facility of the + protocol. + + + +Crispin Standards Track [Page 4] + +RFC 3501 IMAPv4 March 2003 + + + "User" is used to refer to a human user, whereas "client" refers to + the software being run by the user. + + "Connection" refers to the entire sequence of client/server + interaction from the initial establishment of the network connection + until its termination. + + "Session" refers to the sequence of client/server interaction from + the time that a mailbox is selected (SELECT or EXAMINE command) until + the time that selection ends (SELECT or EXAMINE of another mailbox, + CLOSE command, or connection termination). + + Characters are 7-bit US-ASCII unless otherwise specified. Other + character sets are indicated using a "CHARSET", as described in + [MIME-IMT] and defined in [CHARSET]. CHARSETs have important + additional semantics in addition to defining character set; refer to + these documents for more detail. + + There are several protocol conventions in IMAP. These refer to + aspects of the specification which are not strictly part of the IMAP + protocol, but reflect generally-accepted practice. Implementations + need to be aware of these conventions, and avoid conflicts whether or + not they implement the convention. For example, "&" may not be used + as a hierarchy delimiter since it conflicts with the Mailbox + International Naming Convention, and other uses of "&" in mailbox + names are impacted as well. + +1.3. Special Notes to Implementors + + Implementors of the IMAP protocol are strongly encouraged to read the + IMAP implementation recommendations document [IMAP-IMPLEMENTATION] in + conjunction with this document, to help understand the intricacies of + this protocol and how best to build an interoperable product. + + IMAP4rev1 is designed to be upwards compatible from the [IMAP2] and + unpublished IMAP2bis protocols. IMAP4rev1 is largely compatible with + the IMAP4 protocol described in RFC 1730; the exception being in + certain facilities added in RFC 1730 that proved problematic and were + subsequently removed. In the course of the evolution of IMAP4rev1, + some aspects in the earlier protocols have become obsolete. Obsolete + commands, responses, and data formats which an IMAP4rev1 + implementation can encounter when used with an earlier implementation + are described in [IMAP-OBSOLETE]. + + Other compatibility issues with IMAP2bis, the most common variant of + the earlier protocol, are discussed in [IMAP-COMPAT]. A full + discussion of compatibility issues with rare (and presumed extinct) + + + + +Crispin Standards Track [Page 5] + +RFC 3501 IMAPv4 March 2003 + + + variants of [IMAP2] is in [IMAP-HISTORICAL]; this document is + primarily of historical interest. + + IMAP was originally developed for the older [RFC-822] standard, and + as a consequence several fetch items in IMAP incorporate "RFC822" in + their name. With the exception of RFC822.SIZE, there are more modern + replacements; for example, the modern version of RFC822.HEADER is + BODY.PEEK[HEADER]. In all cases, "RFC822" should be interpreted as a + reference to the updated [RFC-2822] standard. + +2. Protocol Overview + +2.1. Link Level + + The IMAP4rev1 protocol assumes a reliable data stream such as that + provided by TCP. When TCP is used, an IMAP4rev1 server listens on + port 143. + +2.2. Commands and Responses + + An IMAP4rev1 connection consists of the establishment of a + client/server network connection, an initial greeting from the + server, and client/server interactions. These client/server + interactions consist of a client command, server data, and a server + completion result response. + + All interactions transmitted by client and server are in the form of + lines, that is, strings that end with a CRLF. The protocol receiver + of an IMAP4rev1 client or server is either reading a line, or is + reading a sequence of octets with a known count followed by a line. + +2.2.1. Client Protocol Sender and Server Protocol Receiver + + The client command begins an operation. Each client command is + prefixed with an identifier (typically a short alphanumeric string, + e.g., A0001, A0002, etc.) called a "tag". A different tag is + generated by the client for each command. + + Clients MUST follow the syntax outlined in this specification + strictly. It is a syntax error to send a command with missing or + extraneous spaces or arguments. + + There are two cases in which a line from the client does not + represent a complete command. In one case, a command argument is + quoted with an octet count (see the description of literal in String + under Data Formats); in the other case, the command arguments require + server feedback (see the AUTHENTICATE command). In either case, the + + + + +Crispin Standards Track [Page 6] + +RFC 3501 IMAPv4 March 2003 + + + server sends a command continuation request response if it is ready + for the octets (if appropriate) and the remainder of the command. + This response is prefixed with the token "+". + + Note: If instead, the server detected an error in the + command, it sends a BAD completion response with a tag + matching the command (as described below) to reject the + command and prevent the client from sending any more of the + command. + + It is also possible for the server to send a completion + response for some other command (if multiple commands are + in progress), or untagged data. In either case, the + command continuation request is still pending; the client + takes the appropriate action for the response, and reads + another response from the server. In all cases, the client + MUST send a complete command (including receiving all + command continuation request responses and command + continuations for the command) before initiating a new + command. + + The protocol receiver of an IMAP4rev1 server reads a command line + from the client, parses the command and its arguments, and transmits + server data and a server command completion result response. + +2.2.2. Server Protocol Sender and Client Protocol Receiver + + Data transmitted by the server to the client and status responses + that do not indicate command completion are prefixed with the token + "*", and are called untagged responses. + + Server data MAY be sent as a result of a client command, or MAY be + sent unilaterally by the server. There is no syntactic difference + between server data that resulted from a specific command and server + data that were sent unilaterally. + + The server completion result response indicates the success or + failure of the operation. It is tagged with the same tag as the + client command which began the operation. Thus, if more than one + command is in progress, the tag in a server completion response + identifies the command to which the response applies. There are + three possible server completion responses: OK (indicating success), + NO (indicating failure), or BAD (indicating a protocol error such as + unrecognized command or command syntax error). + + Servers SHOULD enforce the syntax outlined in this specification + strictly. Any client command with a protocol syntax error, including + (but not limited to) missing or extraneous spaces or arguments, + + + +Crispin Standards Track [Page 7] + +RFC 3501 IMAPv4 March 2003 + + + SHOULD be rejected, and the client given a BAD server completion + response. + + The protocol receiver of an IMAP4rev1 client reads a response line + from the server. It then takes action on the response based upon the + first token of the response, which can be a tag, a "*", or a "+". + + A client MUST be prepared to accept any server response at all times. + This includes server data that was not requested. Server data SHOULD + be recorded, so that the client can reference its recorded copy + rather than sending a command to the server to request the data. In + the case of certain server data, the data MUST be recorded. + + This topic is discussed in greater detail in the Server Responses + section. + +2.3. Message Attributes + + In addition to message text, each message has several attributes + associated with it. These attributes can be retrieved individually + or in conjunction with other attributes or message texts. + +2.3.1. Message Numbers + + Messages in IMAP4rev1 are accessed by one of two numbers; the unique + identifier or the message sequence number. + + +2.3.1.1. Unique Identifier (UID) Message Attribute + + A 32-bit value assigned to each message, which when used with the + unique identifier validity value (see below) forms a 64-bit value + that MUST NOT refer to any other message in the mailbox or any + subsequent mailbox with the same name forever. Unique identifiers + are assigned in a strictly ascending fashion in the mailbox; as each + message is added to the mailbox it is assigned a higher UID than the + message(s) which were added previously. Unlike message sequence + numbers, unique identifiers are not necessarily contiguous. + + The unique identifier of a message MUST NOT change during the + session, and SHOULD NOT change between sessions. Any change of + unique identifiers between sessions MUST be detectable using the + UIDVALIDITY mechanism discussed below. Persistent unique identifiers + are required for a client to resynchronize its state from a previous + session with the server (e.g., disconnected or offline access + clients); this is discussed further in [IMAP-DISC]. + + + + + +Crispin Standards Track [Page 8] + +RFC 3501 IMAPv4 March 2003 + + + Associated with every mailbox are two values which aid in unique + identifier handling: the next unique identifier value and the unique + identifier validity value. + + The next unique identifier value is the predicted value that will be + assigned to a new message in the mailbox. Unless the unique + identifier validity also changes (see below), the next unique + identifier value MUST have the following two characteristics. First, + the next unique identifier value MUST NOT change unless new messages + are added to the mailbox; and second, the next unique identifier + value MUST change whenever new messages are added to the mailbox, + even if those new messages are subsequently expunged. + + Note: The next unique identifier value is intended to + provide a means for a client to determine whether any + messages have been delivered to the mailbox since the + previous time it checked this value. It is not intended to + provide any guarantee that any message will have this + unique identifier. A client can only assume, at the time + that it obtains the next unique identifier value, that + messages arriving after that time will have a UID greater + than or equal to that value. + + The unique identifier validity value is sent in a UIDVALIDITY + response code in an OK untagged response at mailbox selection time. + If unique identifiers from an earlier session fail to persist in this + session, the unique identifier validity value MUST be greater than + the one used in the earlier session. + + Note: Ideally, unique identifiers SHOULD persist at all + times. Although this specification recognizes that failure + to persist can be unavoidable in certain server + environments, it STRONGLY ENCOURAGES message store + implementation techniques that avoid this problem. For + example: + + 1) Unique identifiers MUST be strictly ascending in the + mailbox at all times. If the physical message store is + re-ordered by a non-IMAP agent, this requires that the + unique identifiers in the mailbox be regenerated, since + the former unique identifiers are no longer strictly + ascending as a result of the re-ordering. + + 2) If the message store has no mechanism to store unique + identifiers, it must regenerate unique identifiers at + each session, and each session must have a unique + UIDVALIDITY value. + + + + +Crispin Standards Track [Page 9] + +RFC 3501 IMAPv4 March 2003 + + + 3) If the mailbox is deleted and a new mailbox with the + same name is created at a later date, the server must + either keep track of unique identifiers from the + previous instance of the mailbox, or it must assign a + new UIDVALIDITY value to the new instance of the + mailbox. A good UIDVALIDITY value to use in this case + is a 32-bit representation of the creation date/time of + the mailbox. It is alright to use a constant such as + 1, but only if it guaranteed that unique identifiers + will never be reused, even in the case of a mailbox + being deleted (or renamed) and a new mailbox by the + same name created at some future time. + + 4) The combination of mailbox name, UIDVALIDITY, and UID + must refer to a single immutable message on that server + forever. In particular, the internal date, [RFC-2822] + size, envelope, body structure, and message texts + (RFC822, RFC822.HEADER, RFC822.TEXT, and all BODY[...] + fetch data items) must never change. This does not + include message numbers, nor does it include attributes + that can be set by a STORE command (e.g., FLAGS). + + +2.3.1.2. Message Sequence Number Message Attribute + + A relative position from 1 to the number of messages in the mailbox. + This position MUST be ordered by ascending unique identifier. As + each new message is added, it is assigned a message sequence number + that is 1 higher than the number of messages in the mailbox before + that new message was added. + + Message sequence numbers can be reassigned during the session. For + example, when a message is permanently removed (expunged) from the + mailbox, the message sequence number for all subsequent messages is + decremented. The number of messages in the mailbox is also + decremented. Similarly, a new message can be assigned a message + sequence number that was once held by some other message prior to an + expunge. + + In addition to accessing messages by relative position in the + mailbox, message sequence numbers can be used in mathematical + calculations. For example, if an untagged "11 EXISTS" is received, + and previously an untagged "8 EXISTS" was received, three new + messages have arrived with message sequence numbers of 9, 10, and 11. + Another example, if message 287 in a 523 message mailbox has UID + 12345, there are exactly 286 messages which have lesser UIDs and 236 + messages which have greater UIDs. + + + + +Crispin Standards Track [Page 10] + +RFC 3501 IMAPv4 March 2003 + + +2.3.2. Flags Message Attribute + + A list of zero or more named tokens associated with the message. A + flag is set by its addition to this list, and is cleared by its + removal. There are two types of flags in IMAP4rev1. A flag of + either type can be permanent or session-only. + + A system flag is a flag name that is pre-defined in this + specification. All system flags begin with "\". Certain system + flags (\Deleted and \Seen) have special semantics described + elsewhere. The currently-defined system flags are: + + \Seen + Message has been read + + \Answered + Message has been answered + + \Flagged + Message is "flagged" for urgent/special attention + + \Deleted + Message is "deleted" for removal by later EXPUNGE + + \Draft + Message has not completed composition (marked as a draft). + + \Recent + Message is "recently" arrived in this mailbox. This session + is the first session to have been notified about this + message; if the session is read-write, subsequent sessions + will not see \Recent set for this message. This flag can not + be altered by the client. + + If it is not possible to determine whether or not this + session is the first session to be notified about a message, + then that message SHOULD be considered recent. + + If multiple connections have the same mailbox selected + simultaneously, it is undefined which of these connections + will see newly-arrived messages with \Recent set and which + will see it without \Recent set. + + A keyword is defined by the server implementation. Keywords do not + begin with "\". Servers MAY permit the client to define new keywords + in the mailbox (see the description of the PERMANENTFLAGS response + code for more information). + + + + +Crispin Standards Track [Page 11] + +RFC 3501 IMAPv4 March 2003 + + + A flag can be permanent or session-only on a per-flag basis. + Permanent flags are those which the client can add or remove from the + message flags permanently; that is, concurrent and subsequent + sessions will see any change in permanent flags. Changes to session + flags are valid only in that session. + + Note: The \Recent system flag is a special case of a + session flag. \Recent can not be used as an argument in a + STORE or APPEND command, and thus can not be changed at + all. + +2.3.3. Internal Date Message Attribute + + The internal date and time of the message on the server. This + is not the date and time in the [RFC-2822] header, but rather a + date and time which reflects when the message was received. In + the case of messages delivered via [SMTP], this SHOULD be the + date and time of final delivery of the message as defined by + [SMTP]. In the case of messages delivered by the IMAP4rev1 COPY + command, this SHOULD be the internal date and time of the source + message. In the case of messages delivered by the IMAP4rev1 + APPEND command, this SHOULD be the date and time as specified in + the APPEND command description. All other cases are + implementation defined. + +2.3.4. [RFC-2822] Size Message Attribute + + The number of octets in the message, as expressed in [RFC-2822] + format. + +2.3.5. Envelope Structure Message Attribute + + A parsed representation of the [RFC-2822] header of the message. + Note that the IMAP Envelope structure is not the same as an + [SMTP] envelope. + +2.3.6. Body Structure Message Attribute + + A parsed representation of the [MIME-IMB] body structure + information of the message. + + + + + + + + + + + +Crispin Standards Track [Page 12] + +RFC 3501 IMAPv4 March 2003 + + +2.4. Message Texts + + In addition to being able to fetch the full [RFC-2822] text of a + message, IMAP4rev1 permits the fetching of portions of the full + message text. Specifically, it is possible to fetch the + [RFC-2822] message header, [RFC-2822] message body, a [MIME-IMB] + body part, or a [MIME-IMB] header. + +3. State and Flow Diagram + + Once the connection between client and server is established, an + IMAP4rev1 connection is in one of four states. The initial + state is identified in the server greeting. Most commands are + only valid in certain states. It is a protocol error for the + client to attempt a command while the connection is in an + inappropriate state, and the server will respond with a BAD or + NO (depending upon server implementation) command completion + result. + +3.1. Not Authenticated State + + In the not authenticated state, the client MUST supply + authentication credentials before most commands will be + permitted. This state is entered when a connection starts + unless the connection has been pre-authenticated. + +3.2. Authenticated State + + In the authenticated state, the client is authenticated and MUST + select a mailbox to access before commands that affect messages + will be permitted. This state is entered when a + pre-authenticated connection starts, when acceptable + authentication credentials have been provided, after an error in + selecting a mailbox, or after a successful CLOSE command. + +3.3. Selected State + + In a selected state, a mailbox has been selected to access. + This state is entered when a mailbox has been successfully + selected. + + + + + + + + + + + +Crispin Standards Track [Page 13] + +RFC 3501 IMAPv4 March 2003 + + +3.4. Logout State + + In the logout state, the connection is being terminated. This + state can be entered as a result of a client request (via the + LOGOUT command) or by unilateral action on the part of either + the client or server. + + If the client requests the logout state, the server MUST send an + untagged BYE response and a tagged OK response to the LOGOUT + command before the server closes the connection; and the client + MUST read the tagged OK response to the LOGOUT command before + the client closes the connection. + + A server MUST NOT unilaterally close the connection without + sending an untagged BYE response that contains the reason for + having done so. A client SHOULD NOT unilaterally close the + connection, and instead SHOULD issue a LOGOUT command. If the + server detects that the client has unilaterally closed the + connection, the server MAY omit the untagged BYE response and + simply close its connection. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Crispin Standards Track [Page 14] + +RFC 3501 IMAPv4 March 2003 + + + +----------------------+ + |connection established| + +----------------------+ + || + \/ + +--------------------------------------+ + | server greeting | + +--------------------------------------+ + || (1) || (2) || (3) + \/ || || + +-----------------+ || || + |Not Authenticated| || || + +-----------------+ || || + || (7) || (4) || || + || \/ \/ || + || +----------------+ || + || | Authenticated |<=++ || + || +----------------+ || || + || || (7) || (5) || (6) || + || || \/ || || + || || +--------+ || || + || || |Selected|==++ || + || || +--------+ || + || || || (7) || + \/ \/ \/ \/ + +--------------------------------------+ + | Logout | + +--------------------------------------+ + || + \/ + +-------------------------------+ + |both sides close the connection| + +-------------------------------+ + + (1) connection without pre-authentication (OK greeting) + (2) pre-authenticated connection (PREAUTH greeting) + (3) rejected connection (BYE greeting) + (4) successful LOGIN or AUTHENTICATE command + (5) successful SELECT or EXAMINE command + (6) CLOSE command, or failed SELECT or EXAMINE command + (7) LOGOUT command, server shutdown, or connection closed + + + + + + + + + + +Crispin Standards Track [Page 15] + +RFC 3501 IMAPv4 March 2003 + + +4. Data Formats + + IMAP4rev1 uses textual commands and responses. Data in + IMAP4rev1 can be in one of several forms: atom, number, string, + parenthesized list, or NIL. Note that a particular data item + may take more than one form; for example, a data item defined as + using "astring" syntax may be either an atom or a string. + +4.1. Atom + + An atom consists of one or more non-special characters. + +4.2. Number + + A number consists of one or more digit characters, and + represents a numeric value. + +4.3. String + + A string is in one of two forms: either literal or quoted + string. The literal form is the general form of string. The + quoted string form is an alternative that avoids the overhead of + processing a literal at the cost of limitations of characters + which may be used. + + A literal is a sequence of zero or more octets (including CR and + LF), prefix-quoted with an octet count in the form of an open + brace ("{"), the number of octets, close brace ("}"), and CRLF. + In the case of literals transmitted from server to client, the + CRLF is immediately followed by the octet data. In the case of + literals transmitted from client to server, the client MUST wait + to receive a command continuation request (described later in + this document) before sending the octet data (and the remainder + of the command). + + A quoted string is a sequence of zero or more 7-bit characters, + excluding CR and LF, with double quote (<">) characters at each + end. + + The empty string is represented as either "" (a quoted string + with zero characters between double quotes) or as {0} followed + by CRLF (a literal with an octet count of 0). + + Note: Even if the octet count is 0, a client transmitting a + literal MUST wait to receive a command continuation request. + + + + + + +Crispin Standards Track [Page 16] + +RFC 3501 IMAPv4 March 2003 + + +4.3.1. 8-bit and Binary Strings + + 8-bit textual and binary mail is supported through the use of a + [MIME-IMB] content transfer encoding. IMAP4rev1 implementations MAY + transmit 8-bit or multi-octet characters in literals, but SHOULD do + so only when the [CHARSET] is identified. + + Although a BINARY body encoding is defined, unencoded binary strings + are not permitted. A "binary string" is any string with NUL + characters. Implementations MUST encode binary data into a textual + form, such as BASE64, before transmitting the data. A string with an + excessive amount of CTL characters MAY also be considered to be + binary. + +4.4. Parenthesized List + + Data structures are represented as a "parenthesized list"; a sequence + of data items, delimited by space, and bounded at each end by + parentheses. A parenthesized list can contain other parenthesized + lists, using multiple levels of parentheses to indicate nesting. + + The empty list is represented as () -- a parenthesized list with no + members. + +4.5. NIL + + The special form "NIL" represents the non-existence of a particular + data item that is represented as a string or parenthesized list, as + distinct from the empty string "" or the empty parenthesized list (). + + Note: NIL is never used for any data item which takes the + form of an atom. For example, a mailbox name of "NIL" is a + mailbox named NIL as opposed to a non-existent mailbox + name. This is because mailbox uses "astring" syntax which + is an atom or a string. Conversely, an addr-name of NIL is + a non-existent personal name, because addr-name uses + "nstring" syntax which is NIL or a string, but never an + atom. + + + + + + + + + + + + + +Crispin Standards Track [Page 17] + +RFC 3501 IMAPv4 March 2003 + + +5. Operational Considerations + + The following rules are listed here to ensure that all IMAP4rev1 + implementations interoperate properly. + +5.1. Mailbox Naming + + Mailbox names are 7-bit. Client implementations MUST NOT attempt to + create 8-bit mailbox names, and SHOULD interpret any 8-bit mailbox + names returned by LIST or LSUB as UTF-8. Server implementations + SHOULD prohibit the creation of 8-bit mailbox names, and SHOULD NOT + return 8-bit mailbox names in LIST or LSUB. See section 5.1.3 for + more information on how to represent non-ASCII mailbox names. + + Note: 8-bit mailbox names were undefined in earlier + versions of this protocol. Some sites used a local 8-bit + character set to represent non-ASCII mailbox names. Such + usage is not interoperable, and is now formally deprecated. + + The case-insensitive mailbox name INBOX is a special name reserved to + mean "the primary mailbox for this user on this server". The + interpretation of all other names is implementation-dependent. + + In particular, this specification takes no position on case + sensitivity in non-INBOX mailbox names. Some server implementations + are fully case-sensitive; others preserve case of a newly-created + name but otherwise are case-insensitive; and yet others coerce names + to a particular case. Client implementations MUST interact with any + of these. If a server implementation interprets non-INBOX mailbox + names as case-insensitive, it MUST treat names using the + international naming convention specially as described in section + 5.1.3. + + There are certain client considerations when creating a new mailbox + name: + + 1) Any character which is one of the atom-specials (see the Formal + Syntax) will require that the mailbox name be represented as a + quoted string or literal. + + 2) CTL and other non-graphic characters are difficult to represent + in a user interface and are best avoided. + + 3) Although the list-wildcard characters ("%" and "*") are valid + in a mailbox name, it is difficult to use such mailbox names + with the LIST and LSUB commands due to the conflict with + wildcard interpretation. + + + + +Crispin Standards Track [Page 18] + +RFC 3501 IMAPv4 March 2003 + + + 4) Usually, a character (determined by the server implementation) + is reserved to delimit levels of hierarchy. + + 5) Two characters, "#" and "&", have meanings by convention, and + should be avoided except when used in that convention. + +5.1.1. Mailbox Hierarchy Naming + + If it is desired to export hierarchical mailbox names, mailbox names + MUST be left-to-right hierarchical using a single character to + separate levels of hierarchy. The same hierarchy separator character + is used for all levels of hierarchy within a single name. + +5.1.2. Mailbox Namespace Naming Convention + + By convention, the first hierarchical element of any mailbox name + which begins with "#" identifies the "namespace" of the remainder of + the name. This makes it possible to disambiguate between different + types of mailbox stores, each of which have their own namespaces. + + For example, implementations which offer access to USENET + newsgroups MAY use the "#news" namespace to partition the + USENET newsgroup namespace from that of other mailboxes. + Thus, the comp.mail.misc newsgroup would have a mailbox + name of "#news.comp.mail.misc", and the name + "comp.mail.misc" can refer to a different object (e.g., a + user's private mailbox). + +5.1.3. Mailbox International Naming Convention + + By convention, international mailbox names in IMAP4rev1 are specified + using a modified version of the UTF-7 encoding described in [UTF-7]. + Modified UTF-7 may also be usable in servers that implement an + earlier version of this protocol. + + In modified UTF-7, printable US-ASCII characters, except for "&", + represent themselves; that is, characters with octet values 0x20-0x25 + and 0x27-0x7e. The character "&" (0x26) is represented by the + two-octet sequence "&-". + + All other characters (octet values 0x00-0x1f and 0x7f-0xff) are + represented in modified BASE64, with a further modification from + [UTF-7] that "," is used instead of "/". Modified BASE64 MUST NOT be + used to represent any printing US-ASCII character which can represent + itself. + + + + + + +Crispin Standards Track [Page 19] + +RFC 3501 IMAPv4 March 2003 + + + "&" is used to shift to modified BASE64 and "-" to shift back to + US-ASCII. There is no implicit shift from BASE64 to US-ASCII, and + null shifts ("-&" while in BASE64; note that "&-" while in US-ASCII + means "&") are not permitted. However, all names start in US-ASCII, + and MUST end in US-ASCII; that is, a name that ends with a non-ASCII + ISO-10646 character MUST end with a "-"). + + The purpose of these modifications is to correct the following + problems with UTF-7: + + 1) UTF-7 uses the "+" character for shifting; this conflicts with + the common use of "+" in mailbox names, in particular USENET + newsgroup names. + + 2) UTF-7's encoding is BASE64 which uses the "/" character; this + conflicts with the use of "/" as a popular hierarchy delimiter. + + 3) UTF-7 prohibits the unencoded usage of "\"; this conflicts with + the use of "\" as a popular hierarchy delimiter. + + 4) UTF-7 prohibits the unencoded usage of "~"; this conflicts with + the use of "~" in some servers as a home directory indicator. + + 5) UTF-7 permits multiple alternate forms to represent the same + string; in particular, printable US-ASCII characters can be + represented in encoded form. + + Although modified UTF-7 is a convention, it establishes certain + requirements on server handling of any mailbox name with an + embedded "&" character. In particular, server implementations + MUST preserve the exact form of the modified BASE64 portion of a + modified UTF-7 name and treat that text as case-sensitive, even if + names are otherwise case-insensitive or case-folded. + + Server implementations SHOULD verify that any mailbox name with an + embedded "&" character, used as an argument to CREATE, is: in the + correctly modified UTF-7 syntax, has no superfluous shifts, and + has no encoding in modified BASE64 of any printing US-ASCII + character which can represent itself. However, client + implementations MUST NOT depend upon the server doing this, and + SHOULD NOT attempt to create a mailbox name with an embedded "&" + character unless it complies with the modified UTF-7 syntax. + + Server implementations which export a mail store that does not + follow the modified UTF-7 convention MUST convert to modified + UTF-7 any mailbox name that contains either non-ASCII characters + or the "&" character. + + + + +Crispin Standards Track [Page 20] + +RFC 3501 IMAPv4 March 2003 + + + For example, here is a mailbox name which mixes English, + Chinese, and Japanese text: + ~peter/mail/&U,BTFw-/&ZeVnLIqe- + + For example, the string "&Jjo!" is not a valid mailbox + name because it does not contain a shift to US-ASCII + before the "!". The correct form is "&Jjo-!". The + string "&U,BTFw-&ZeVnLIqe-" is not permitted because it + contains a superfluous shift. The correct form is + "&U,BTF2XlZyyKng-". + +5.2. Mailbox Size and Message Status Updates + + At any time, a server can send data that the client did not request. + Sometimes, such behavior is REQUIRED. For example, agents other than + the server MAY add messages to the mailbox (e.g., new message + delivery), change the flags of the messages in the mailbox (e.g., + simultaneous access to the same mailbox by multiple agents), or even + remove messages from the mailbox. A server MUST send mailbox size + updates automatically if a mailbox size change is observed during the + processing of a command. A server SHOULD send message flag updates + automatically, without requiring the client to request such updates + explicitly. + + Special rules exist for server notification of a client about the + removal of messages to prevent synchronization errors; see the + description of the EXPUNGE response for more detail. In particular, + it is NOT permitted to send an EXISTS response that would reduce the + number of messages in the mailbox; only the EXPUNGE response can do + this. + + Regardless of what implementation decisions a client makes on + remembering data from the server, a client implementation MUST record + mailbox size updates. It MUST NOT assume that any command after the + initial mailbox selection will return the size of the mailbox. + +5.3. Response when no Command in Progress + + Server implementations are permitted to send an untagged response + (except for EXPUNGE) while there is no command in progress. Server + implementations that send such responses MUST deal with flow control + considerations. Specifically, they MUST either (1) verify that the + size of the data does not exceed the underlying transport's available + window size, or (2) use non-blocking writes. + + + + + + + +Crispin Standards Track [Page 21] + +RFC 3501 IMAPv4 March 2003 + + +5.4. Autologout Timer + + If a server has an inactivity autologout timer, the duration of that + timer MUST be at least 30 minutes. The receipt of ANY command from + the client during that interval SHOULD suffice to reset the + autologout timer. + +5.5. Multiple Commands in Progress + + The client MAY send another command without waiting for the + completion result response of a command, subject to ambiguity rules + (see below) and flow control constraints on the underlying data + stream. Similarly, a server MAY begin processing another command + before processing the current command to completion, subject to + ambiguity rules. However, any command continuation request responses + and command continuations MUST be negotiated before any subsequent + command is initiated. + + The exception is if an ambiguity would result because of a command + that would affect the results of other commands. Clients MUST NOT + send multiple commands without waiting if an ambiguity would result. + If the server detects a possible ambiguity, it MUST execute commands + to completion in the order given by the client. + + The most obvious example of ambiguity is when a command would affect + the results of another command, e.g., a FETCH of a message's flags + and a STORE of that same message's flags. + + A non-obvious ambiguity occurs with commands that permit an untagged + EXPUNGE response (commands other than FETCH, STORE, and SEARCH), + since an untagged EXPUNGE response can invalidate sequence numbers in + a subsequent command. This is not a problem for FETCH, STORE, or + SEARCH commands because servers are prohibited from sending EXPUNGE + responses while any of those commands are in progress. Therefore, if + the client sends any command other than FETCH, STORE, or SEARCH, it + MUST wait for the completion result response before sending a command + with message sequence numbers. + + Note: UID FETCH, UID STORE, and UID SEARCH are different + commands from FETCH, STORE, and SEARCH. If the client + sends a UID command, it must wait for a completion result + response before sending a command with message sequence + numbers. + + + + + + + + +Crispin Standards Track [Page 22] + +RFC 3501 IMAPv4 March 2003 + + + For example, the following non-waiting command sequences are invalid: + + FETCH + NOOP + STORE + STORE + COPY + FETCH + COPY + COPY + CHECK + FETCH + + The following are examples of valid non-waiting command sequences: + + FETCH + STORE + SEARCH + CHECK + STORE + COPY + EXPUNGE + + UID SEARCH + UID SEARCH may be valid or invalid as a non-waiting + command sequence, depending upon whether or not the second UID + SEARCH contains message sequence numbers. + +6. Client Commands + + IMAP4rev1 commands are described in this section. Commands are + organized by the state in which the command is permitted. Commands + which are permitted in multiple states are listed in the minimum + permitted state (for example, commands valid in authenticated and + selected state are listed in the authenticated state commands). + + Command arguments, identified by "Arguments:" in the command + descriptions below, are described by function, not by syntax. The + precise syntax of command arguments is described in the Formal Syntax + section. + + Some commands cause specific server responses to be returned; these + are identified by "Responses:" in the command descriptions below. + See the response descriptions in the Responses section for + information on these responses, and the Formal Syntax section for the + precise syntax of these responses. It is possible for server data to + be transmitted as a result of any command. Thus, commands that do + not specifically require server data specify "no specific responses + for this command" instead of "none". + + The "Result:" in the command description refers to the possible + tagged status responses to a command, and any special interpretation + of these status responses. + + The state of a connection is only changed by successful commands + which are documented as changing state. A rejected command (BAD + response) never changes the state of the connection or of the + selected mailbox. A failed command (NO response) generally does not + change the state of the connection or of the selected mailbox; the + exception being the SELECT and EXAMINE commands. + + + +Crispin Standards Track [Page 23] + +RFC 3501 IMAPv4 March 2003 + + +6.1. Client Commands - Any State + + The following commands are valid in any state: CAPABILITY, NOOP, and + LOGOUT. + +6.1.1. CAPABILITY Command + + Arguments: none + + Responses: REQUIRED untagged response: CAPABILITY + + Result: OK - capability completed + BAD - command unknown or arguments invalid + + The CAPABILITY command requests a listing of capabilities that the + server supports. The server MUST send a single untagged + CAPABILITY response with "IMAP4rev1" as one of the listed + capabilities before the (tagged) OK response. + + A capability name which begins with "AUTH=" indicates that the + server supports that particular authentication mechanism. All + such names are, by definition, part of this specification. For + example, the authorization capability for an experimental + "blurdybloop" authenticator would be "AUTH=XBLURDYBLOOP" and not + "XAUTH=BLURDYBLOOP" or "XAUTH=XBLURDYBLOOP". + + Other capability names refer to extensions, revisions, or + amendments to this specification. See the documentation of the + CAPABILITY response for additional information. No capabilities, + beyond the base IMAP4rev1 set defined in this specification, are + enabled without explicit client action to invoke the capability. + + Client and server implementations MUST implement the STARTTLS, + LOGINDISABLED, and AUTH=PLAIN (described in [IMAP-TLS]) + capabilities. See the Security Considerations section for + important information. + + See the section entitled "Client Commands - + Experimental/Expansion" for information about the form of site or + implementation-specific capabilities. + + + + + + + + + + + +Crispin Standards Track [Page 24] + +RFC 3501 IMAPv4 March 2003 + + + Example: C: abcd CAPABILITY + S: * CAPABILITY IMAP4rev1 STARTTLS AUTH=GSSAPI + LOGINDISABLED + S: abcd OK CAPABILITY completed + C: efgh STARTTLS + S: efgh OK STARTLS completed + + C: ijkl CAPABILITY + S: * CAPABILITY IMAP4rev1 AUTH=GSSAPI AUTH=PLAIN + S: ijkl OK CAPABILITY completed + + +6.1.2. NOOP Command + + Arguments: none + + Responses: no specific responses for this command (but see below) + + Result: OK - noop completed + BAD - command unknown or arguments invalid + + The NOOP command always succeeds. It does nothing. + + Since any command can return a status update as untagged data, the + NOOP command can be used as a periodic poll for new messages or + message status updates during a period of inactivity (this is the + preferred method to do this). The NOOP command can also be used + to reset any inactivity autologout timer on the server. + + Example: C: a002 NOOP + S: a002 OK NOOP completed + . . . + C: a047 NOOP + S: * 22 EXPUNGE + S: * 23 EXISTS + S: * 3 RECENT + S: * 14 FETCH (FLAGS (\Seen \Deleted)) + S: a047 OK NOOP completed + + + + + + + + + + + + + +Crispin Standards Track [Page 25] + +RFC 3501 IMAPv4 March 2003 + + +6.1.3. LOGOUT Command + + Arguments: none + + Responses: REQUIRED untagged response: BYE + + Result: OK - logout completed + BAD - command unknown or arguments invalid + + The LOGOUT command informs the server that the client is done with + the connection. The server MUST send a BYE untagged response + before the (tagged) OK response, and then close the network + connection. + + Example: C: A023 LOGOUT + S: * BYE IMAP4rev1 Server logging out + S: A023 OK LOGOUT completed + (Server and client then close the connection) + +6.2. Client Commands - Not Authenticated State + + In the not authenticated state, the AUTHENTICATE or LOGIN command + establishes authentication and enters the authenticated state. The + AUTHENTICATE command provides a general mechanism for a variety of + authentication techniques, privacy protection, and integrity + checking; whereas the LOGIN command uses a traditional user name and + plaintext password pair and has no means of establishing privacy + protection or integrity checking. + + The STARTTLS command is an alternate form of establishing session + privacy protection and integrity checking, but does not establish + authentication or enter the authenticated state. + + Server implementations MAY allow access to certain mailboxes without + establishing authentication. This can be done by means of the + ANONYMOUS [SASL] authenticator described in [ANONYMOUS]. An older + convention is a LOGIN command using the userid "anonymous"; in this + case, a password is required although the server may choose to accept + any password. The restrictions placed on anonymous users are + implementation-dependent. + + Once authenticated (including as anonymous), it is not possible to + re-enter not authenticated state. + + + + + + + + +Crispin Standards Track [Page 26] + +RFC 3501 IMAPv4 March 2003 + + + In addition to the universal commands (CAPABILITY, NOOP, and LOGOUT), + the following commands are valid in the not authenticated state: + STARTTLS, AUTHENTICATE and LOGIN. See the Security Considerations + section for important information about these commands. + +6.2.1. STARTTLS Command + + Arguments: none + + Responses: no specific response for this command + + Result: OK - starttls completed, begin TLS negotiation + BAD - command unknown or arguments invalid + + A [TLS] negotiation begins immediately after the CRLF at the end + of the tagged OK response from the server. Once a client issues a + STARTTLS command, it MUST NOT issue further commands until a + server response is seen and the [TLS] negotiation is complete. + + The server remains in the non-authenticated state, even if client + credentials are supplied during the [TLS] negotiation. This does + not preclude an authentication mechanism such as EXTERNAL (defined + in [SASL]) from using client identity determined by the [TLS] + negotiation. + + Once [TLS] has been started, the client MUST discard cached + information about server capabilities and SHOULD re-issue the + CAPABILITY command. This is necessary to protect against man-in- + the-middle attacks which alter the capabilities list prior to + STARTTLS. The server MAY advertise different capabilities after + STARTTLS. + + Example: C: a001 CAPABILITY + S: * CAPABILITY IMAP4rev1 STARTTLS LOGINDISABLED + S: a001 OK CAPABILITY completed + C: a002 STARTTLS + S: a002 OK Begin TLS negotiation now + + C: a003 CAPABILITY + S: * CAPABILITY IMAP4rev1 AUTH=PLAIN + S: a003 OK CAPABILITY completed + C: a004 LOGIN joe password + S: a004 OK LOGIN completed + + + + + + + + +Crispin Standards Track [Page 27] + +RFC 3501 IMAPv4 March 2003 + + +6.2.2. AUTHENTICATE Command + + Arguments: authentication mechanism name + + Responses: continuation data can be requested + + Result: OK - authenticate completed, now in authenticated state + NO - authenticate failure: unsupported authentication + mechanism, credentials rejected + BAD - command unknown or arguments invalid, + authentication exchange cancelled + + The AUTHENTICATE command indicates a [SASL] authentication + mechanism to the server. If the server supports the requested + authentication mechanism, it performs an authentication protocol + exchange to authenticate and identify the client. It MAY also + negotiate an OPTIONAL security layer for subsequent protocol + interactions. If the requested authentication mechanism is not + supported, the server SHOULD reject the AUTHENTICATE command by + sending a tagged NO response. + + The AUTHENTICATE command does not support the optional "initial + response" feature of [SASL]. Section 5.1 of [SASL] specifies how + to handle an authentication mechanism which uses an initial + response. + + The service name specified by this protocol's profile of [SASL] is + "imap". + + The authentication protocol exchange consists of a series of + server challenges and client responses that are specific to the + authentication mechanism. A server challenge consists of a + command continuation request response with the "+" token followed + by a BASE64 encoded string. The client response consists of a + single line consisting of a BASE64 encoded string. If the client + wishes to cancel an authentication exchange, it issues a line + consisting of a single "*". If the server receives such a + response, it MUST reject the AUTHENTICATE command by sending a + tagged BAD response. + + If a security layer is negotiated through the [SASL] + authentication exchange, it takes effect immediately following the + CRLF that concludes the authentication exchange for the client, + and the CRLF of the tagged OK response for the server. + + While client and server implementations MUST implement the + AUTHENTICATE command itself, it is not required to implement any + authentication mechanisms other than the PLAIN mechanism described + + + +Crispin Standards Track [Page 28] + +RFC 3501 IMAPv4 March 2003 + + + in [IMAP-TLS]. Also, an authentication mechanism is not required + to support any security layers. + + Note: a server implementation MUST implement a + configuration in which it does NOT permit any plaintext + password mechanisms, unless either the STARTTLS command + has been negotiated or some other mechanism that + protects the session from password snooping has been + provided. Server sites SHOULD NOT use any configuration + which permits a plaintext password mechanism without + such a protection mechanism against password snooping. + Client and server implementations SHOULD implement + additional [SASL] mechanisms that do not use plaintext + passwords, such the GSSAPI mechanism described in [SASL] + and/or the [DIGEST-MD5] mechanism. + + Servers and clients can support multiple authentication + mechanisms. The server SHOULD list its supported authentication + mechanisms in the response to the CAPABILITY command so that the + client knows which authentication mechanisms to use. + + A server MAY include a CAPABILITY response code in the tagged OK + response of a successful AUTHENTICATE command in order to send + capabilities automatically. It is unnecessary for a client to + send a separate CAPABILITY command if it recognizes these + automatic capabilities. This should only be done if a security + layer was not negotiated by the AUTHENTICATE command, because the + tagged OK response as part of an AUTHENTICATE command is not + protected by encryption/integrity checking. [SASL] requires the + client to re-issue a CAPABILITY command in this case. + + If an AUTHENTICATE command fails with a NO response, the client + MAY try another authentication mechanism by issuing another + AUTHENTICATE command. It MAY also attempt to authenticate by + using the LOGIN command (see section 6.2.3 for more detail). In + other words, the client MAY request authentication types in + decreasing order of preference, with the LOGIN command as a last + resort. + + The authorization identity passed from the client to the server + during the authentication exchange is interpreted by the server as + the user name whose privileges the client is requesting. + + + + + + + + + +Crispin Standards Track [Page 29] + +RFC 3501 IMAPv4 March 2003 + + + Example: S: * OK IMAP4rev1 Server + C: A001 AUTHENTICATE GSSAPI + S: + + C: YIIB+wYJKoZIhvcSAQICAQBuggHqMIIB5qADAgEFoQMCAQ6iBw + MFACAAAACjggEmYYIBIjCCAR6gAwIBBaESGxB1Lndhc2hpbmd0 + b24uZWR1oi0wK6ADAgEDoSQwIhsEaW1hcBsac2hpdmFtcy5jYW + Mud2FzaGluZ3Rvbi5lZHWjgdMwgdCgAwIBAaEDAgEDooHDBIHA + cS1GSa5b+fXnPZNmXB9SjL8Ollj2SKyb+3S0iXMljen/jNkpJX + AleKTz6BQPzj8duz8EtoOuNfKgweViyn/9B9bccy1uuAE2HI0y + C/PHXNNU9ZrBziJ8Lm0tTNc98kUpjXnHZhsMcz5Mx2GR6dGknb + I0iaGcRerMUsWOuBmKKKRmVMMdR9T3EZdpqsBd7jZCNMWotjhi + vd5zovQlFqQ2Wjc2+y46vKP/iXxWIuQJuDiisyXF0Y8+5GTpAL + pHDc1/pIGmMIGjoAMCAQGigZsEgZg2on5mSuxoDHEA1w9bcW9n + FdFxDKpdrQhVGVRDIzcCMCTzvUboqb5KjY1NJKJsfjRQiBYBdE + NKfzK+g5DlV8nrw81uOcP8NOQCLR5XkoMHC0Dr/80ziQzbNqhx + O6652Npft0LQwJvenwDI13YxpwOdMXzkWZN/XrEqOWp6GCgXTB + vCyLWLlWnbaUkZdEYbKHBPjd8t/1x5Yg== + S: + YGgGCSqGSIb3EgECAgIAb1kwV6ADAgEFoQMCAQ+iSzBJoAMC + AQGiQgRAtHTEuOP2BXb9sBYFR4SJlDZxmg39IxmRBOhXRKdDA0 + uHTCOT9Bq3OsUTXUlk0CsFLoa8j+gvGDlgHuqzWHPSQg== + C: + S: + YDMGCSqGSIb3EgECAgIBAAD/////6jcyG4GE3KkTzBeBiVHe + ceP2CWY0SR0fAQAgAAQEBAQ= + C: YDMGCSqGSIb3EgECAgIBAAD/////3LQBHXTpFfZgrejpLlLImP + wkhbfa2QteAQAgAG1yYwE= + S: A001 OK GSSAPI authentication successful + + Note: The line breaks within server challenges and client + responses are for editorial clarity and are not in real + authenticators. + + +6.2.3. LOGIN Command + + Arguments: user name + password + + Responses: no specific responses for this command + + Result: OK - login completed, now in authenticated state + NO - login failure: user name or password rejected + BAD - command unknown or arguments invalid + + The LOGIN command identifies the client to the server and carries + the plaintext password authenticating this user. + + + + + + +Crispin Standards Track [Page 30] + +RFC 3501 IMAPv4 March 2003 + + + A server MAY include a CAPABILITY response code in the tagged OK + response to a successful LOGIN command in order to send + capabilities automatically. It is unnecessary for a client to + send a separate CAPABILITY command if it recognizes these + automatic capabilities. + + Example: C: a001 LOGIN SMITH SESAME + S: a001 OK LOGIN completed + + Note: Use of the LOGIN command over an insecure network + (such as the Internet) is a security risk, because anyone + monitoring network traffic can obtain plaintext passwords. + The LOGIN command SHOULD NOT be used except as a last + resort, and it is recommended that client implementations + have a means to disable any automatic use of the LOGIN + command. + + Unless either the STARTTLS command has been negotiated or + some other mechanism that protects the session from + password snooping has been provided, a server + implementation MUST implement a configuration in which it + advertises the LOGINDISABLED capability and does NOT permit + the LOGIN command. Server sites SHOULD NOT use any + configuration which permits the LOGIN command without such + a protection mechanism against password snooping. A client + implementation MUST NOT send a LOGIN command if the + LOGINDISABLED capability is advertised. + +6.3. Client Commands - Authenticated State + + In the authenticated state, commands that manipulate mailboxes as + atomic entities are permitted. Of these commands, the SELECT and + EXAMINE commands will select a mailbox for access and enter the + selected state. + + In addition to the universal commands (CAPABILITY, NOOP, and LOGOUT), + the following commands are valid in the authenticated state: SELECT, + EXAMINE, CREATE, DELETE, RENAME, SUBSCRIBE, UNSUBSCRIBE, LIST, LSUB, + STATUS, and APPEND. + + + + + + + + + + + + +Crispin Standards Track [Page 31] + +RFC 3501 IMAPv4 March 2003 + + +6.3.1. SELECT Command + + Arguments: mailbox name + + Responses: REQUIRED untagged responses: FLAGS, EXISTS, RECENT + REQUIRED OK untagged responses: UNSEEN, PERMANENTFLAGS, + UIDNEXT, UIDVALIDITY + + Result: OK - select completed, now in selected state + NO - select failure, now in authenticated state: no + such mailbox, can't access mailbox + BAD - command unknown or arguments invalid + + The SELECT command selects a mailbox so that messages in the + mailbox can be accessed. Before returning an OK to the client, + the server MUST send the following untagged data to the client. + Note that earlier versions of this protocol only required the + FLAGS, EXISTS, and RECENT untagged data; consequently, client + implementations SHOULD implement default behavior for missing data + as discussed with the individual item. + + FLAGS Defined flags in the mailbox. See the description + of the FLAGS response for more detail. + + EXISTS The number of messages in the mailbox. See the + description of the EXISTS response for more detail. + + RECENT The number of messages with the \Recent flag set. + See the description of the RECENT response for more + detail. + + OK [UNSEEN ] + The message sequence number of the first unseen + message in the mailbox. If this is missing, the + client can not make any assumptions about the first + unseen message in the mailbox, and needs to issue a + SEARCH command if it wants to find it. + + OK [PERMANENTFLAGS ()] + A list of message flags that the client can change + permanently. If this is missing, the client should + assume that all flags can be changed permanently. + + OK [UIDNEXT ] + The next unique identifier value. Refer to section + 2.3.1.1 for more information. If this is missing, + the client can not make any assumptions about the + next unique identifier value. + + + +Crispin Standards Track [Page 32] + +RFC 3501 IMAPv4 March 2003 + + + OK [UIDVALIDITY ] + The unique identifier validity value. Refer to + section 2.3.1.1 for more information. If this is + missing, the server does not support unique + identifiers. + + Only one mailbox can be selected at a time in a connection; + simultaneous access to multiple mailboxes requires multiple + connections. The SELECT command automatically deselects any + currently selected mailbox before attempting the new selection. + Consequently, if a mailbox is selected and a SELECT command that + fails is attempted, no mailbox is selected. + + If the client is permitted to modify the mailbox, the server + SHOULD prefix the text of the tagged OK response with the + "[READ-WRITE]" response code. + + If the client is not permitted to modify the mailbox but is + permitted read access, the mailbox is selected as read-only, and + the server MUST prefix the text of the tagged OK response to + SELECT with the "[READ-ONLY]" response code. Read-only access + through SELECT differs from the EXAMINE command in that certain + read-only mailboxes MAY permit the change of permanent state on a + per-user (as opposed to global) basis. Netnews messages marked in + a server-based .newsrc file are an example of such per-user + permanent state that can be modified with read-only mailboxes. + + Example: C: A142 SELECT INBOX + S: * 172 EXISTS + S: * 1 RECENT + S: * OK [UNSEEN 12] Message 12 is first unseen + S: * OK [UIDVALIDITY 3857529045] UIDs valid + S: * OK [UIDNEXT 4392] Predicted next UID + S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) + S: * OK [PERMANENTFLAGS (\Deleted \Seen \*)] Limited + S: A142 OK [READ-WRITE] SELECT completed + + + + + + + + + + + + + + + +Crispin Standards Track [Page 33] + +RFC 3501 IMAPv4 March 2003 + + +6.3.2. EXAMINE Command + + Arguments: mailbox name + + Responses: REQUIRED untagged responses: FLAGS, EXISTS, RECENT + REQUIRED OK untagged responses: UNSEEN, PERMANENTFLAGS, + UIDNEXT, UIDVALIDITY + + Result: OK - examine completed, now in selected state + NO - examine failure, now in authenticated state: no + such mailbox, can't access mailbox + BAD - command unknown or arguments invalid + + The EXAMINE command is identical to SELECT and returns the same + output; however, the selected mailbox is identified as read-only. + No changes to the permanent state of the mailbox, including + per-user state, are permitted; in particular, EXAMINE MUST NOT + cause messages to lose the \Recent flag. + + The text of the tagged OK response to the EXAMINE command MUST + begin with the "[READ-ONLY]" response code. + + Example: C: A932 EXAMINE blurdybloop + S: * 17 EXISTS + S: * 2 RECENT + S: * OK [UNSEEN 8] Message 8 is first unseen + S: * OK [UIDVALIDITY 3857529045] UIDs valid + S: * OK [UIDNEXT 4392] Predicted next UID + S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) + S: * OK [PERMANENTFLAGS ()] No permanent flags permitted + S: A932 OK [READ-ONLY] EXAMINE completed + + +6.3.3. CREATE Command + + Arguments: mailbox name + + Responses: no specific responses for this command + + Result: OK - create completed + NO - create failure: can't create mailbox with that name + BAD - command unknown or arguments invalid + + The CREATE command creates a mailbox with the given name. An OK + response is returned only if a new mailbox with that name has been + created. It is an error to attempt to create INBOX or a mailbox + with a name that refers to an extant mailbox. Any error in + creation will return a tagged NO response. + + + +Crispin Standards Track [Page 34] + +RFC 3501 IMAPv4 March 2003 + + + If the mailbox name is suffixed with the server's hierarchy + separator character (as returned from the server by a LIST + command), this is a declaration that the client intends to create + mailbox names under this name in the hierarchy. Server + implementations that do not require this declaration MUST ignore + the declaration. In any case, the name created is without the + trailing hierarchy delimiter. + + If the server's hierarchy separator character appears elsewhere in + the name, the server SHOULD create any superior hierarchical names + that are needed for the CREATE command to be successfully + completed. In other words, an attempt to create "foo/bar/zap" on + a server in which "/" is the hierarchy separator character SHOULD + create foo/ and foo/bar/ if they do not already exist. + + If a new mailbox is created with the same name as a mailbox which + was deleted, its unique identifiers MUST be greater than any + unique identifiers used in the previous incarnation of the mailbox + UNLESS the new incarnation has a different unique identifier + validity value. See the description of the UID command for more + detail. + + Example: C: A003 CREATE owatagusiam/ + S: A003 OK CREATE completed + C: A004 CREATE owatagusiam/blurdybloop + S: A004 OK CREATE completed + + Note: The interpretation of this example depends on whether + "/" was returned as the hierarchy separator from LIST. If + "/" is the hierarchy separator, a new level of hierarchy + named "owatagusiam" with a member called "blurdybloop" is + created. Otherwise, two mailboxes at the same hierarchy + level are created. + + +6.3.4. DELETE Command + + Arguments: mailbox name + + Responses: no specific responses for this command + + Result: OK - delete completed + NO - delete failure: can't delete mailbox with that name + BAD - command unknown or arguments invalid + + + + + + + +Crispin Standards Track [Page 35] + +RFC 3501 IMAPv4 March 2003 + + + The DELETE command permanently removes the mailbox with the given + name. A tagged OK response is returned only if the mailbox has + been deleted. It is an error to attempt to delete INBOX or a + mailbox name that does not exist. + + The DELETE command MUST NOT remove inferior hierarchical names. + For example, if a mailbox "foo" has an inferior "foo.bar" + (assuming "." is the hierarchy delimiter character), removing + "foo" MUST NOT remove "foo.bar". It is an error to attempt to + delete a name that has inferior hierarchical names and also has + the \Noselect mailbox name attribute (see the description of the + LIST response for more details). + + It is permitted to delete a name that has inferior hierarchical + names and does not have the \Noselect mailbox name attribute. In + this case, all messages in that mailbox are removed, and the name + will acquire the \Noselect mailbox name attribute. + + The value of the highest-used unique identifier of the deleted + mailbox MUST be preserved so that a new mailbox created with the + same name will not reuse the identifiers of the former + incarnation, UNLESS the new incarnation has a different unique + identifier validity value. See the description of the UID command + for more detail. + + Examples: C: A682 LIST "" * + S: * LIST () "/" blurdybloop + S: * LIST (\Noselect) "/" foo + S: * LIST () "/" foo/bar + S: A682 OK LIST completed + C: A683 DELETE blurdybloop + S: A683 OK DELETE completed + C: A684 DELETE foo + S: A684 NO Name "foo" has inferior hierarchical names + C: A685 DELETE foo/bar + S: A685 OK DELETE Completed + C: A686 LIST "" * + S: * LIST (\Noselect) "/" foo + S: A686 OK LIST completed + C: A687 DELETE foo + S: A687 OK DELETE Completed + + + + + + + + + + +Crispin Standards Track [Page 36] + +RFC 3501 IMAPv4 March 2003 + + + C: A82 LIST "" * + S: * LIST () "." blurdybloop + S: * LIST () "." foo + S: * LIST () "." foo.bar + S: A82 OK LIST completed + C: A83 DELETE blurdybloop + S: A83 OK DELETE completed + C: A84 DELETE foo + S: A84 OK DELETE Completed + C: A85 LIST "" * + S: * LIST () "." foo.bar + S: A85 OK LIST completed + C: A86 LIST "" % + S: * LIST (\Noselect) "." foo + S: A86 OK LIST completed + + +6.3.5. RENAME Command + + Arguments: existing mailbox name + new mailbox name + + Responses: no specific responses for this command + + Result: OK - rename completed + NO - rename failure: can't rename mailbox with that name, + can't rename to mailbox with that name + BAD - command unknown or arguments invalid + + The RENAME command changes the name of a mailbox. A tagged OK + response is returned only if the mailbox has been renamed. It is + an error to attempt to rename from a mailbox name that does not + exist or to a mailbox name that already exists. Any error in + renaming will return a tagged NO response. + + If the name has inferior hierarchical names, then the inferior + hierarchical names MUST also be renamed. For example, a rename of + "foo" to "zap" will rename "foo/bar" (assuming "/" is the + hierarchy delimiter character) to "zap/bar". + + If the server's hierarchy separator character appears in the name, + the server SHOULD create any superior hierarchical names that are + needed for the RENAME command to complete successfully. In other + words, an attempt to rename "foo/bar/zap" to baz/rag/zowie on a + server in which "/" is the hierarchy separator character SHOULD + create baz/ and baz/rag/ if they do not already exist. + + + + + +Crispin Standards Track [Page 37] + +RFC 3501 IMAPv4 March 2003 + + + The value of the highest-used unique identifier of the old mailbox + name MUST be preserved so that a new mailbox created with the same + name will not reuse the identifiers of the former incarnation, + UNLESS the new incarnation has a different unique identifier + validity value. See the description of the UID command for more + detail. + + Renaming INBOX is permitted, and has special behavior. It moves + all messages in INBOX to a new mailbox with the given name, + leaving INBOX empty. If the server implementation supports + inferior hierarchical names of INBOX, these are unaffected by a + rename of INBOX. + + Examples: C: A682 LIST "" * + S: * LIST () "/" blurdybloop + S: * LIST (\Noselect) "/" foo + S: * LIST () "/" foo/bar + S: A682 OK LIST completed + C: A683 RENAME blurdybloop sarasoop + S: A683 OK RENAME completed + C: A684 RENAME foo zowie + S: A684 OK RENAME Completed + C: A685 LIST "" * + S: * LIST () "/" sarasoop + S: * LIST (\Noselect) "/" zowie + S: * LIST () "/" zowie/bar + S: A685 OK LIST completed + + C: Z432 LIST "" * + S: * LIST () "." INBOX + S: * LIST () "." INBOX.bar + S: Z432 OK LIST completed + C: Z433 RENAME INBOX old-mail + S: Z433 OK RENAME completed + C: Z434 LIST "" * + S: * LIST () "." INBOX + S: * LIST () "." INBOX.bar + S: * LIST () "." old-mail + S: Z434 OK LIST completed + + + + + + + + + + + + +Crispin Standards Track [Page 38] + +RFC 3501 IMAPv4 March 2003 + + +6.3.6. SUBSCRIBE Command + + Arguments: mailbox + + Responses: no specific responses for this command + + Result: OK - subscribe completed + NO - subscribe failure: can't subscribe to that name + BAD - command unknown or arguments invalid + + The SUBSCRIBE command adds the specified mailbox name to the + server's set of "active" or "subscribed" mailboxes as returned by + the LSUB command. This command returns a tagged OK response only + if the subscription is successful. + + A server MAY validate the mailbox argument to SUBSCRIBE to verify + that it exists. However, it MUST NOT unilaterally remove an + existing mailbox name from the subscription list even if a mailbox + by that name no longer exists. + + Note: This requirement is because a server site can + choose to routinely remove a mailbox with a well-known + name (e.g., "system-alerts") after its contents expire, + with the intention of recreating it when new contents + are appropriate. + + + Example: C: A002 SUBSCRIBE #news.comp.mail.mime + S: A002 OK SUBSCRIBE completed + + +6.3.7. UNSUBSCRIBE Command + + Arguments: mailbox name + + Responses: no specific responses for this command + + Result: OK - unsubscribe completed + NO - unsubscribe failure: can't unsubscribe that name + BAD - command unknown or arguments invalid + + The UNSUBSCRIBE command removes the specified mailbox name from + the server's set of "active" or "subscribed" mailboxes as returned + by the LSUB command. This command returns a tagged OK response + only if the unsubscription is successful. + + Example: C: A002 UNSUBSCRIBE #news.comp.mail.mime + S: A002 OK UNSUBSCRIBE completed + + + +Crispin Standards Track [Page 39] + +RFC 3501 IMAPv4 March 2003 + + +6.3.8. LIST Command + + Arguments: reference name + mailbox name with possible wildcards + + Responses: untagged responses: LIST + + Result: OK - list completed + NO - list failure: can't list that reference or name + BAD - command unknown or arguments invalid + + The LIST command returns a subset of names from the complete set + of all names available to the client. Zero or more untagged LIST + replies are returned, containing the name attributes, hierarchy + delimiter, and name; see the description of the LIST reply for + more detail. + + The LIST command SHOULD return its data quickly, without undue + delay. For example, it SHOULD NOT go to excess trouble to + calculate the \Marked or \Unmarked status or perform other + processing; if each name requires 1 second of processing, then a + list of 1200 names would take 20 minutes! + + An empty ("" string) reference name argument indicates that the + mailbox name is interpreted as by SELECT. The returned mailbox + names MUST match the supplied mailbox name pattern. A non-empty + reference name argument is the name of a mailbox or a level of + mailbox hierarchy, and indicates the context in which the mailbox + name is interpreted. + + An empty ("" string) mailbox name argument is a special request to + return the hierarchy delimiter and the root name of the name given + in the reference. The value returned as the root MAY be the empty + string if the reference is non-rooted or is an empty string. In + all cases, a hierarchy delimiter (or NIL if there is no hierarchy) + is returned. This permits a client to get the hierarchy delimiter + (or find out that the mailbox names are flat) even when no + mailboxes by that name currently exist. + + The reference and mailbox name arguments are interpreted into a + canonical form that represents an unambiguous left-to-right + hierarchy. The returned mailbox names will be in the interpreted + form. + + + + + + + + +Crispin Standards Track [Page 40] + +RFC 3501 IMAPv4 March 2003 + + + Note: The interpretation of the reference argument is + implementation-defined. It depends upon whether the + server implementation has a concept of the "current + working directory" and leading "break out characters", + which override the current working directory. + + For example, on a server which exports a UNIX or NT + filesystem, the reference argument contains the current + working directory, and the mailbox name argument would + contain the name as interpreted in the current working + directory. + + If a server implementation has no concept of break out + characters, the canonical form is normally the reference + name appended with the mailbox name. Note that if the + server implements the namespace convention (section + 5.1.2), "#" is a break out character and must be treated + as such. + + If the reference argument is not a level of mailbox + hierarchy (that is, it is a \NoInferiors name), and/or + the reference argument does not end with the hierarchy + delimiter, it is implementation-dependent how this is + interpreted. For example, a reference of "foo/bar" and + mailbox name of "rag/baz" could be interpreted as + "foo/bar/rag/baz", "foo/barrag/baz", or "foo/rag/baz". + A client SHOULD NOT use such a reference argument except + at the explicit request of the user. A hierarchical + browser MUST NOT make any assumptions about server + interpretation of the reference unless the reference is + a level of mailbox hierarchy AND ends with the hierarchy + delimiter. + + Any part of the reference argument that is included in the + interpreted form SHOULD prefix the interpreted form. It SHOULD + also be in the same form as the reference name argument. This + rule permits the client to determine if the returned mailbox name + is in the context of the reference argument, or if something about + the mailbox argument overrode the reference argument. Without + this rule, the client would have to have knowledge of the server's + naming semantics including what characters are "breakouts" that + override a naming context. + + + + + + + + + +Crispin Standards Track [Page 41] + +RFC 3501 IMAPv4 March 2003 + + + For example, here are some examples of how references + and mailbox names might be interpreted on a UNIX-based + server: + + Reference Mailbox Name Interpretation + ------------ ------------ -------------- + ~smith/Mail/ foo.* ~smith/Mail/foo.* + archive/ % archive/% + #news. comp.mail.* #news.comp.mail.* + ~smith/Mail/ /usr/doc/foo /usr/doc/foo + archive/ ~fred/Mail/* ~fred/Mail/* + + The first three examples demonstrate interpretations in + the context of the reference argument. Note that + "~smith/Mail" SHOULD NOT be transformed into something + like "/u2/users/smith/Mail", or it would be impossible + for the client to determine that the interpretation was + in the context of the reference. + + The character "*" is a wildcard, and matches zero or more + characters at this position. The character "%" is similar to "*", + but it does not match a hierarchy delimiter. If the "%" wildcard + is the last character of a mailbox name argument, matching levels + of hierarchy are also returned. If these levels of hierarchy are + not also selectable mailboxes, they are returned with the + \Noselect mailbox name attribute (see the description of the LIST + response for more details). + + Server implementations are permitted to "hide" otherwise + accessible mailboxes from the wildcard characters, by preventing + certain characters or names from matching a wildcard in certain + situations. For example, a UNIX-based server might restrict the + interpretation of "*" so that an initial "/" character does not + match. + + The special name INBOX is included in the output from LIST, if + INBOX is supported by this server for this user and if the + uppercase string "INBOX" matches the interpreted reference and + mailbox name arguments with wildcards as described above. The + criteria for omitting INBOX is whether SELECT INBOX will return + failure; it is not relevant whether the user's real INBOX resides + on this or some other server. + + + + + + + + + +Crispin Standards Track [Page 42] + +RFC 3501 IMAPv4 March 2003 + + + Example: C: A101 LIST "" "" + S: * LIST (\Noselect) "/" "" + S: A101 OK LIST Completed + C: A102 LIST #news.comp.mail.misc "" + S: * LIST (\Noselect) "." #news. + S: A102 OK LIST Completed + C: A103 LIST /usr/staff/jones "" + S: * LIST (\Noselect) "/" / + S: A103 OK LIST Completed + C: A202 LIST ~/Mail/ % + S: * LIST (\Noselect) "/" ~/Mail/foo + S: * LIST () "/" ~/Mail/meetings + S: A202 OK LIST completed + + +6.3.9. LSUB Command + + Arguments: reference name + mailbox name with possible wildcards + + Responses: untagged responses: LSUB + + Result: OK - lsub completed + NO - lsub failure: can't list that reference or name + BAD - command unknown or arguments invalid + + The LSUB command returns a subset of names from the set of names + that the user has declared as being "active" or "subscribed". + Zero or more untagged LSUB replies are returned. The arguments to + LSUB are in the same form as those for LIST. + + The returned untagged LSUB response MAY contain different mailbox + flags from a LIST untagged response. If this should happen, the + flags in the untagged LIST are considered more authoritative. + + A special situation occurs when using LSUB with the % wildcard. + Consider what happens if "foo/bar" (with a hierarchy delimiter of + "/") is subscribed but "foo" is not. A "%" wildcard to LSUB must + return foo, not foo/bar, in the LSUB response, and it MUST be + flagged with the \Noselect attribute. + + The server MUST NOT unilaterally remove an existing mailbox name + from the subscription list even if a mailbox by that name no + longer exists. + + + + + + + +Crispin Standards Track [Page 43] + +RFC 3501 IMAPv4 March 2003 + + + Example: C: A002 LSUB "#news." "comp.mail.*" + S: * LSUB () "." #news.comp.mail.mime + S: * LSUB () "." #news.comp.mail.misc + S: A002 OK LSUB completed + C: A003 LSUB "#news." "comp.%" + S: * LSUB (\NoSelect) "." #news.comp.mail + S: A003 OK LSUB completed + + +6.3.10. STATUS Command + + Arguments: mailbox name + status data item names + + Responses: untagged responses: STATUS + + Result: OK - status completed + NO - status failure: no status for that name + BAD - command unknown or arguments invalid + + The STATUS command requests the status of the indicated mailbox. + It does not change the currently selected mailbox, nor does it + affect the state of any messages in the queried mailbox (in + particular, STATUS MUST NOT cause messages to lose the \Recent + flag). + + The STATUS command provides an alternative to opening a second + IMAP4rev1 connection and doing an EXAMINE command on a mailbox to + query that mailbox's status without deselecting the current + mailbox in the first IMAP4rev1 connection. + + Unlike the LIST command, the STATUS command is not guaranteed to + be fast in its response. Under certain circumstances, it can be + quite slow. In some implementations, the server is obliged to + open the mailbox read-only internally to obtain certain status + information. Also unlike the LIST command, the STATUS command + does not accept wildcards. + + Note: The STATUS command is intended to access the + status of mailboxes other than the currently selected + mailbox. Because the STATUS command can cause the + mailbox to be opened internally, and because this + information is available by other means on the selected + mailbox, the STATUS command SHOULD NOT be used on the + currently selected mailbox. + + + + + + +Crispin Standards Track [Page 44] + +RFC 3501 IMAPv4 March 2003 + + + The STATUS command MUST NOT be used as a "check for new + messages in the selected mailbox" operation (refer to + sections 7, 7.3.1, and 7.3.2 for more information about + the proper method for new message checking). + + Because the STATUS command is not guaranteed to be fast + in its results, clients SHOULD NOT expect to be able to + issue many consecutive STATUS commands and obtain + reasonable performance. + + The currently defined status data items that can be requested are: + + MESSAGES + The number of messages in the mailbox. + + RECENT + The number of messages with the \Recent flag set. + + UIDNEXT + The next unique identifier value of the mailbox. Refer to + section 2.3.1.1 for more information. + + UIDVALIDITY + The unique identifier validity value of the mailbox. Refer to + section 2.3.1.1 for more information. + + UNSEEN + The number of messages which do not have the \Seen flag set. + + + Example: C: A042 STATUS blurdybloop (UIDNEXT MESSAGES) + S: * STATUS blurdybloop (MESSAGES 231 UIDNEXT 44292) + S: A042 OK STATUS completed + + + + + + + + + + + + + + + + + + +Crispin Standards Track [Page 45] + +RFC 3501 IMAPv4 March 2003 + + +6.3.11. APPEND Command + + Arguments: mailbox name + OPTIONAL flag parenthesized list + OPTIONAL date/time string + message literal + + Responses: no specific responses for this command + + Result: OK - append completed + NO - append error: can't append to that mailbox, error + in flags or date/time or message text + BAD - command unknown or arguments invalid + + The APPEND command appends the literal argument as a new message + to the end of the specified destination mailbox. This argument + SHOULD be in the format of an [RFC-2822] message. 8-bit + characters are permitted in the message. A server implementation + that is unable to preserve 8-bit data properly MUST be able to + reversibly convert 8-bit APPEND data to 7-bit using a [MIME-IMB] + content transfer encoding. + + Note: There MAY be exceptions, e.g., draft messages, in + which required [RFC-2822] header lines are omitted in + the message literal argument to APPEND. The full + implications of doing so MUST be understood and + carefully weighed. + + If a flag parenthesized list is specified, the flags SHOULD be set + in the resulting message; otherwise, the flag list of the + resulting message is set to empty by default. In either case, the + Recent flag is also set. + + If a date-time is specified, the internal date SHOULD be set in + the resulting message; otherwise, the internal date of the + resulting message is set to the current date and time by default. + + If the append is unsuccessful for any reason, the mailbox MUST be + restored to its state before the APPEND attempt; no partial + appending is permitted. + + If the destination mailbox does not exist, a server MUST return an + error, and MUST NOT automatically create the mailbox. Unless it + is certain that the destination mailbox can not be created, the + server MUST send the response code "[TRYCREATE]" as the prefix of + the text of the tagged NO response. This gives a hint to the + client that it can attempt a CREATE command and retry the APPEND + if the CREATE is successful. + + + +Crispin Standards Track [Page 46] + +RFC 3501 IMAPv4 March 2003 + + + If the mailbox is currently selected, the normal new message + actions SHOULD occur. Specifically, the server SHOULD notify the + client immediately via an untagged EXISTS response. If the server + does not do so, the client MAY issue a NOOP command (or failing + that, a CHECK command) after one or more APPEND commands. + + Example: C: A003 APPEND saved-messages (\Seen) {310} + S: + Ready for literal data + C: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST) + C: From: Fred Foobar + C: Subject: afternoon meeting + C: To: mooch@owatagu.siam.edu + C: Message-Id: + C: MIME-Version: 1.0 + C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII + C: + C: Hello Joe, do you think we can meet at 3:30 tomorrow? + C: + S: A003 OK APPEND completed + + Note: The APPEND command is not used for message delivery, + because it does not provide a mechanism to transfer [SMTP] + envelope information. + +6.4. Client Commands - Selected State + + In the selected state, commands that manipulate messages in a mailbox + are permitted. + + In addition to the universal commands (CAPABILITY, NOOP, and LOGOUT), + and the authenticated state commands (SELECT, EXAMINE, CREATE, + DELETE, RENAME, SUBSCRIBE, UNSUBSCRIBE, LIST, LSUB, STATUS, and + APPEND), the following commands are valid in the selected state: + CHECK, CLOSE, EXPUNGE, SEARCH, FETCH, STORE, COPY, and UID. + +6.4.1. CHECK Command + + Arguments: none + + Responses: no specific responses for this command + + Result: OK - check completed + BAD - command unknown or arguments invalid + + The CHECK command requests a checkpoint of the currently selected + mailbox. A checkpoint refers to any implementation-dependent + housekeeping associated with the mailbox (e.g., resolving the + server's in-memory state of the mailbox with the state on its + + + +Crispin Standards Track [Page 47] + +RFC 3501 IMAPv4 March 2003 + + + disk) that is not normally executed as part of each command. A + checkpoint MAY take a non-instantaneous amount of real time to + complete. If a server implementation has no such housekeeping + considerations, CHECK is equivalent to NOOP. + + There is no guarantee that an EXISTS untagged response will happen + as a result of CHECK. NOOP, not CHECK, SHOULD be used for new + message polling. + + Example: C: FXXZ CHECK + S: FXXZ OK CHECK Completed + + +6.4.2. CLOSE Command + + Arguments: none + + Responses: no specific responses for this command + + Result: OK - close completed, now in authenticated state + BAD - command unknown or arguments invalid + + The CLOSE command permanently removes all messages that have the + \Deleted flag set from the currently selected mailbox, and returns + to the authenticated state from the selected state. No untagged + EXPUNGE responses are sent. + + No messages are removed, and no error is given, if the mailbox is + selected by an EXAMINE command or is otherwise selected read-only. + + Even if a mailbox is selected, a SELECT, EXAMINE, or LOGOUT + command MAY be issued without previously issuing a CLOSE command. + The SELECT, EXAMINE, and LOGOUT commands implicitly close the + currently selected mailbox without doing an expunge. However, + when many messages are deleted, a CLOSE-LOGOUT or CLOSE-SELECT + sequence is considerably faster than an EXPUNGE-LOGOUT or + EXPUNGE-SELECT because no untagged EXPUNGE responses (which the + client would probably ignore) are sent. + + Example: C: A341 CLOSE + S: A341 OK CLOSE completed + + + + + + + + + + +Crispin Standards Track [Page 48] + +RFC 3501 IMAPv4 March 2003 + + +6.4.3. EXPUNGE Command + + Arguments: none + + Responses: untagged responses: EXPUNGE + + Result: OK - expunge completed + NO - expunge failure: can't expunge (e.g., permission + denied) + BAD - command unknown or arguments invalid + + The EXPUNGE command permanently removes all messages that have the + \Deleted flag set from the currently selected mailbox. Before + returning an OK to the client, an untagged EXPUNGE response is + sent for each message that is removed. + + Example: C: A202 EXPUNGE + S: * 3 EXPUNGE + S: * 3 EXPUNGE + S: * 5 EXPUNGE + S: * 8 EXPUNGE + S: A202 OK EXPUNGE completed + + Note: In this example, messages 3, 4, 7, and 11 had the + \Deleted flag set. See the description of the EXPUNGE + response for further explanation. + + +6.4.4. SEARCH Command + + Arguments: OPTIONAL [CHARSET] specification + searching criteria (one or more) + + Responses: REQUIRED untagged response: SEARCH + + Result: OK - search completed + NO - search error: can't search that [CHARSET] or + criteria + BAD - command unknown or arguments invalid + + The SEARCH command searches the mailbox for messages that match + the given searching criteria. Searching criteria consist of one + or more search keys. The untagged SEARCH response from the server + contains a listing of message sequence numbers corresponding to + those messages that match the searching criteria. + + + + + + +Crispin Standards Track [Page 49] + +RFC 3501 IMAPv4 March 2003 + + + When multiple keys are specified, the result is the intersection + (AND function) of all the messages that match those keys. For + example, the criteria DELETED FROM "SMITH" SINCE 1-Feb-1994 refers + to all deleted messages from Smith that were placed in the mailbox + since February 1, 1994. A search key can also be a parenthesized + list of one or more search keys (e.g., for use with the OR and NOT + keys). + + Server implementations MAY exclude [MIME-IMB] body parts with + terminal content media types other than TEXT and MESSAGE from + consideration in SEARCH matching. + + The OPTIONAL [CHARSET] specification consists of the word + "CHARSET" followed by a registered [CHARSET]. It indicates the + [CHARSET] of the strings that appear in the search criteria. + [MIME-IMB] content transfer encodings, and [MIME-HDRS] strings in + [RFC-2822]/[MIME-IMB] headers, MUST be decoded before comparing + text in a [CHARSET] other than US-ASCII. US-ASCII MUST be + supported; other [CHARSET]s MAY be supported. + + If the server does not support the specified [CHARSET], it MUST + return a tagged NO response (not a BAD). This response SHOULD + contain the BADCHARSET response code, which MAY list the + [CHARSET]s supported by the server. + + In all search keys that use strings, a message matches the key if + the string is a substring of the field. The matching is + case-insensitive. + + The defined search keys are as follows. Refer to the Formal + Syntax section for the precise syntactic definitions of the + arguments. + + + Messages with message sequence numbers corresponding to the + specified message sequence number set. + + ALL + All messages in the mailbox; the default initial key for + ANDing. + + ANSWERED + Messages with the \Answered flag set. + + + + + + + + +Crispin Standards Track [Page 50] + +RFC 3501 IMAPv4 March 2003 + + + BCC + Messages that contain the specified string in the envelope + structure's BCC field. + + BEFORE + Messages whose internal date (disregarding time and timezone) + is earlier than the specified date. + + BODY + Messages that contain the specified string in the body of the + message. + + CC + Messages that contain the specified string in the envelope + structure's CC field. + + DELETED + Messages with the \Deleted flag set. + + DRAFT + Messages with the \Draft flag set. + + FLAGGED + Messages with the \Flagged flag set. + + FROM + Messages that contain the specified string in the envelope + structure's FROM field. + + HEADER + Messages that have a header with the specified field-name (as + defined in [RFC-2822]) and that contains the specified string + in the text of the header (what comes after the colon). If the + string to search is zero-length, this matches all messages that + have a header line with the specified field-name regardless of + the contents. + + KEYWORD + Messages with the specified keyword flag set. + + LARGER + Messages with an [RFC-2822] size larger than the specified + number of octets. + + NEW + Messages that have the \Recent flag set but not the \Seen flag. + This is functionally equivalent to "(RECENT UNSEEN)". + + + + +Crispin Standards Track [Page 51] + +RFC 3501 IMAPv4 March 2003 + + + NOT + Messages that do not match the specified search key. + + OLD + Messages that do not have the \Recent flag set. This is + functionally equivalent to "NOT RECENT" (as opposed to "NOT + NEW"). + + ON + Messages whose internal date (disregarding time and timezone) + is within the specified date. + + OR + Messages that match either search key. + + RECENT + Messages that have the \Recent flag set. + + SEEN + Messages that have the \Seen flag set. + + SENTBEFORE + Messages whose [RFC-2822] Date: header (disregarding time and + timezone) is earlier than the specified date. + + SENTON + Messages whose [RFC-2822] Date: header (disregarding time and + timezone) is within the specified date. + + SENTSINCE + Messages whose [RFC-2822] Date: header (disregarding time and + timezone) is within or later than the specified date. + + SINCE + Messages whose internal date (disregarding time and timezone) + is within or later than the specified date. + + SMALLER + Messages with an [RFC-2822] size smaller than the specified + number of octets. + + + + + + + + + + + +Crispin Standards Track [Page 52] + +RFC 3501 IMAPv4 March 2003 + + + SUBJECT + Messages that contain the specified string in the envelope + structure's SUBJECT field. + + TEXT + Messages that contain the specified string in the header or + body of the message. + + TO + Messages that contain the specified string in the envelope + structure's TO field. + + UID + Messages with unique identifiers corresponding to the specified + unique identifier set. Sequence set ranges are permitted. + + UNANSWERED + Messages that do not have the \Answered flag set. + + UNDELETED + Messages that do not have the \Deleted flag set. + + UNDRAFT + Messages that do not have the \Draft flag set. + + UNFLAGGED + Messages that do not have the \Flagged flag set. + + UNKEYWORD + Messages that do not have the specified keyword flag set. + + UNSEEN + Messages that do not have the \Seen flag set. + + + + + + + + + + + + + + + + + + +Crispin Standards Track [Page 53] + +RFC 3501 IMAPv4 March 2003 + + + Example: C: A282 SEARCH FLAGGED SINCE 1-Feb-1994 NOT FROM "Smith" + S: * SEARCH 2 84 882 + S: A282 OK SEARCH completed + C: A283 SEARCH TEXT "string not in mailbox" + S: * SEARCH + S: A283 OK SEARCH completed + C: A284 SEARCH CHARSET UTF-8 TEXT {6} + C: XXXXXX + S: * SEARCH 43 + S: A284 OK SEARCH completed + + Note: Since this document is restricted to 7-bit ASCII + text, it is not possible to show actual UTF-8 data. The + "XXXXXX" is a placeholder for what would be 6 octets of + 8-bit data in an actual transaction. + + +6.4.5. FETCH Command + + Arguments: sequence set + message data item names or macro + + Responses: untagged responses: FETCH + + Result: OK - fetch completed + NO - fetch error: can't fetch that data + BAD - command unknown or arguments invalid + + The FETCH command retrieves data associated with a message in the + mailbox. The data items to be fetched can be either a single atom + or a parenthesized list. + + Most data items, identified in the formal syntax under the + msg-att-static rule, are static and MUST NOT change for any + particular message. Other data items, identified in the formal + syntax under the msg-att-dynamic rule, MAY change, either as a + result of a STORE command or due to external events. + + For example, if a client receives an ENVELOPE for a + message when it already knows the envelope, it can + safely ignore the newly transmitted envelope. + + There are three macros which specify commonly-used sets of data + items, and can be used instead of data items. A macro must be + used by itself, and not in conjunction with other macros or data + items. + + + + + +Crispin Standards Track [Page 54] + +RFC 3501 IMAPv4 March 2003 + + + ALL + Macro equivalent to: (FLAGS INTERNALDATE RFC822.SIZE ENVELOPE) + + FAST + Macro equivalent to: (FLAGS INTERNALDATE RFC822.SIZE) + + FULL + Macro equivalent to: (FLAGS INTERNALDATE RFC822.SIZE ENVELOPE + BODY) + + The currently defined data items that can be fetched are: + + BODY + Non-extensible form of BODYSTRUCTURE. + + BODY[
]<> + The text of a particular body section. The section + specification is a set of zero or more part specifiers + delimited by periods. A part specifier is either a part number + or one of the following: HEADER, HEADER.FIELDS, + HEADER.FIELDS.NOT, MIME, and TEXT. An empty section + specification refers to the entire message, including the + header. + + Every message has at least one part number. Non-[MIME-IMB] + messages, and non-multipart [MIME-IMB] messages with no + encapsulated message, only have a part 1. + + Multipart messages are assigned consecutive part numbers, as + they occur in the message. If a particular part is of type + message or multipart, its parts MUST be indicated by a period + followed by the part number within that nested multipart part. + + A part of type MESSAGE/RFC822 also has nested part numbers, + referring to parts of the MESSAGE part's body. + + The HEADER, HEADER.FIELDS, HEADER.FIELDS.NOT, and TEXT part + specifiers can be the sole part specifier or can be prefixed by + one or more numeric part specifiers, provided that the numeric + part specifier refers to a part of type MESSAGE/RFC822. The + MIME part specifier MUST be prefixed by one or more numeric + part specifiers. + + The HEADER, HEADER.FIELDS, and HEADER.FIELDS.NOT part + specifiers refer to the [RFC-2822] header of the message or of + an encapsulated [MIME-IMT] MESSAGE/RFC822 message. + HEADER.FIELDS and HEADER.FIELDS.NOT are followed by a list of + field-name (as defined in [RFC-2822]) names, and return a + + + +Crispin Standards Track [Page 55] + +RFC 3501 IMAPv4 March 2003 + + + subset of the header. The subset returned by HEADER.FIELDS + contains only those header fields with a field-name that + matches one of the names in the list; similarly, the subset + returned by HEADER.FIELDS.NOT contains only the header fields + with a non-matching field-name. The field-matching is + case-insensitive but otherwise exact. Subsetting does not + exclude the [RFC-2822] delimiting blank line between the header + and the body; the blank line is included in all header fetches, + except in the case of a message which has no body and no blank + line. + + The MIME part specifier refers to the [MIME-IMB] header for + this part. + + The TEXT part specifier refers to the text body of the message, + omitting the [RFC-2822] header. + + Here is an example of a complex message with some of its + part specifiers: + + HEADER ([RFC-2822] header of the message) + TEXT ([RFC-2822] text body of the message) MULTIPART/MIXED + 1 TEXT/PLAIN + 2 APPLICATION/OCTET-STREAM + 3 MESSAGE/RFC822 + 3.HEADER ([RFC-2822] header of the message) + 3.TEXT ([RFC-2822] text body of the message) MULTIPART/MIXED + 3.1 TEXT/PLAIN + 3.2 APPLICATION/OCTET-STREAM + 4 MULTIPART/MIXED + 4.1 IMAGE/GIF + 4.1.MIME ([MIME-IMB] header for the IMAGE/GIF) + 4.2 MESSAGE/RFC822 + 4.2.HEADER ([RFC-2822] header of the message) + 4.2.TEXT ([RFC-2822] text body of the message) MULTIPART/MIXED + 4.2.1 TEXT/PLAIN + 4.2.2 MULTIPART/ALTERNATIVE + 4.2.2.1 TEXT/PLAIN + 4.2.2.2 TEXT/RICHTEXT + + + It is possible to fetch a substring of the designated text. + This is done by appending an open angle bracket ("<"), the + octet position of the first desired octet, a period, the + maximum number of octets desired, and a close angle bracket + (">") to the part specifier. If the starting octet is beyond + the end of the text, an empty string is returned. + + + + +Crispin Standards Track [Page 56] + +RFC 3501 IMAPv4 March 2003 + + + Any partial fetch that attempts to read beyond the end of the + text is truncated as appropriate. A partial fetch that starts + at octet 0 is returned as a partial fetch, even if this + truncation happened. + + Note: This means that BODY[]<0.2048> of a 1500-octet message + will return BODY[]<0> with a literal of size 1500, not + BODY[]. + + Note: A substring fetch of a HEADER.FIELDS or + HEADER.FIELDS.NOT part specifier is calculated after + subsetting the header. + + The \Seen flag is implicitly set; if this causes the flags to + change, they SHOULD be included as part of the FETCH responses. + + BODY.PEEK[
]<> + An alternate form of BODY[
] that does not implicitly + set the \Seen flag. + + BODYSTRUCTURE + The [MIME-IMB] body structure of the message. This is computed + by the server by parsing the [MIME-IMB] header fields in the + [RFC-2822] header and [MIME-IMB] headers. + + ENVELOPE + The envelope structure of the message. This is computed by the + server by parsing the [RFC-2822] header into the component + parts, defaulting various fields as necessary. + + FLAGS + The flags that are set for this message. + + INTERNALDATE + The internal date of the message. + + RFC822 + Functionally equivalent to BODY[], differing in the syntax of + the resulting untagged FETCH data (RFC822 is returned). + + RFC822.HEADER + Functionally equivalent to BODY.PEEK[HEADER], differing in the + syntax of the resulting untagged FETCH data (RFC822.HEADER is + returned). + + RFC822.SIZE + The [RFC-2822] size of the message. + + + + +Crispin Standards Track [Page 57] + +RFC 3501 IMAPv4 March 2003 + + + RFC822.TEXT + Functionally equivalent to BODY[TEXT], differing in the syntax + of the resulting untagged FETCH data (RFC822.TEXT is returned). + + UID + The unique identifier for the message. + + + Example: C: A654 FETCH 2:4 (FLAGS BODY[HEADER.FIELDS (DATE FROM)]) + S: * 2 FETCH .... + S: * 3 FETCH .... + S: * 4 FETCH .... + S: A654 OK FETCH completed + + +6.4.6. STORE Command + + Arguments: sequence set + message data item name + value for message data item + + Responses: untagged responses: FETCH + + Result: OK - store completed + NO - store error: can't store that data + BAD - command unknown or arguments invalid + + The STORE command alters data associated with a message in the + mailbox. Normally, STORE will return the updated value of the + data with an untagged FETCH response. A suffix of ".SILENT" in + the data item name prevents the untagged FETCH, and the server + SHOULD assume that the client has determined the updated value + itself or does not care about the updated value. + + Note: Regardless of whether or not the ".SILENT" suffix + was used, the server SHOULD send an untagged FETCH + response if a change to a message's flags from an + external source is observed. The intent is that the + status of the flags is determinate without a race + condition. + + + + + + + + + + + +Crispin Standards Track [Page 58] + +RFC 3501 IMAPv4 March 2003 + + + The currently defined data items that can be stored are: + + FLAGS + Replace the flags for the message (other than \Recent) with the + argument. The new value of the flags is returned as if a FETCH + of those flags was done. + + FLAGS.SILENT + Equivalent to FLAGS, but without returning a new value. + + +FLAGS + Add the argument to the flags for the message. The new value + of the flags is returned as if a FETCH of those flags was done. + + +FLAGS.SILENT + Equivalent to +FLAGS, but without returning a new value. + + -FLAGS + Remove the argument from the flags for the message. The new + value of the flags is returned as if a FETCH of those flags was + done. + + -FLAGS.SILENT + Equivalent to -FLAGS, but without returning a new value. + + + Example: C: A003 STORE 2:4 +FLAGS (\Deleted) + S: * 2 FETCH (FLAGS (\Deleted \Seen)) + S: * 3 FETCH (FLAGS (\Deleted)) + S: * 4 FETCH (FLAGS (\Deleted \Flagged \Seen)) + S: A003 OK STORE completed + + +6.4.7. COPY Command + + Arguments: sequence set + mailbox name + + Responses: no specific responses for this command + + Result: OK - copy completed + NO - copy error: can't copy those messages or to that + name + BAD - command unknown or arguments invalid + + + + + + + +Crispin Standards Track [Page 59] + +RFC 3501 IMAPv4 March 2003 + + + The COPY command copies the specified message(s) to the end of the + specified destination mailbox. The flags and internal date of the + message(s) SHOULD be preserved, and the Recent flag SHOULD be set, + in the copy. + + If the destination mailbox does not exist, a server SHOULD return + an error. It SHOULD NOT automatically create the mailbox. Unless + it is certain that the destination mailbox can not be created, the + server MUST send the response code "[TRYCREATE]" as the prefix of + the text of the tagged NO response. This gives a hint to the + client that it can attempt a CREATE command and retry the COPY if + the CREATE is successful. + + If the COPY command is unsuccessful for any reason, server + implementations MUST restore the destination mailbox to its state + before the COPY attempt. + + Example: C: A003 COPY 2:4 MEETING + S: A003 OK COPY completed + + +6.4.8. UID Command + + Arguments: command name + command arguments + + Responses: untagged responses: FETCH, SEARCH + + Result: OK - UID command completed + NO - UID command error + BAD - command unknown or arguments invalid + + The UID command has two forms. In the first form, it takes as its + arguments a COPY, FETCH, or STORE command with arguments + appropriate for the associated command. However, the numbers in + the sequence set argument are unique identifiers instead of + message sequence numbers. Sequence set ranges are permitted, but + there is no guarantee that unique identifiers will be contiguous. + + A non-existent unique identifier is ignored without any error + message generated. Thus, it is possible for a UID FETCH command + to return an OK without any data or a UID COPY or UID STORE to + return an OK without performing any operations. + + In the second form, the UID command takes a SEARCH command with + SEARCH command arguments. The interpretation of the arguments is + the same as with SEARCH; however, the numbers returned in a SEARCH + response for a UID SEARCH command are unique identifiers instead + + + +Crispin Standards Track [Page 60] + +RFC 3501 IMAPv4 March 2003 + + + of message sequence numbers. For example, the command UID SEARCH + 1:100 UID 443:557 returns the unique identifiers corresponding to + the intersection of two sequence sets, the message sequence number + range 1:100 and the UID range 443:557. + + Note: in the above example, the UID range 443:557 + appears. The same comment about a non-existent unique + identifier being ignored without any error message also + applies here. Hence, even if neither UID 443 or 557 + exist, this range is valid and would include an existing + UID 495. + + Also note that a UID range of 559:* always includes the + UID of the last message in the mailbox, even if 559 is + higher than any assigned UID value. This is because the + contents of a range are independent of the order of the + range endpoints. Thus, any UID range with * as one of + the endpoints indicates at least one message (the + message with the highest numbered UID), unless the + mailbox is empty. + + The number after the "*" in an untagged FETCH response is always a + message sequence number, not a unique identifier, even for a UID + command response. However, server implementations MUST implicitly + include the UID message data item as part of any FETCH response + caused by a UID command, regardless of whether a UID was specified + as a message data item to the FETCH. + + + Note: The rule about including the UID message data item as part + of a FETCH response primarily applies to the UID FETCH and UID + STORE commands, including a UID FETCH command that does not + include UID as a message data item. Although it is unlikely that + the other UID commands will cause an untagged FETCH, this rule + applies to these commands as well. + + Example: C: A999 UID FETCH 4827313:4828442 FLAGS + S: * 23 FETCH (FLAGS (\Seen) UID 4827313) + S: * 24 FETCH (FLAGS (\Seen) UID 4827943) + S: * 25 FETCH (FLAGS (\Seen) UID 4828442) + S: A999 OK UID FETCH completed + + + + + + + + + + +Crispin Standards Track [Page 61] + +RFC 3501 IMAPv4 March 2003 + + +6.5. Client Commands - Experimental/Expansion + + +6.5.1. X Command + + Arguments: implementation defined + + Responses: implementation defined + + Result: OK - command completed + NO - failure + BAD - command unknown or arguments invalid + + Any command prefixed with an X is an experimental command. + Commands which are not part of this specification, a standard or + standards-track revision of this specification, or an + IESG-approved experimental protocol, MUST use the X prefix. + + Any added untagged responses issued by an experimental command + MUST also be prefixed with an X. Server implementations MUST NOT + send any such untagged responses, unless the client requested it + by issuing the associated experimental command. + + Example: C: a441 CAPABILITY + S: * CAPABILITY IMAP4rev1 XPIG-LATIN + S: a441 OK CAPABILITY completed + C: A442 XPIG-LATIN + S: * XPIG-LATIN ow-nay eaking-spay ig-pay atin-lay + S: A442 OK XPIG-LATIN ompleted-cay + +7. Server Responses + + Server responses are in three forms: status responses, server data, + and command continuation request. The information contained in a + server response, identified by "Contents:" in the response + descriptions below, is described by function, not by syntax. The + precise syntax of server responses is described in the Formal Syntax + section. + + The client MUST be prepared to accept any response at all times. + + Status responses can be tagged or untagged. Tagged status responses + indicate the completion result (OK, NO, or BAD status) of a client + command, and have a tag matching the command. + + Some status responses, and all server data, are untagged. An + untagged response is indicated by the token "*" instead of a tag. + Untagged status responses indicate server greeting, or server status + + + +Crispin Standards Track [Page 62] + +RFC 3501 IMAPv4 March 2003 + + + that does not indicate the completion of a command (for example, an + impending system shutdown alert). For historical reasons, untagged + server data responses are also called "unsolicited data", although + strictly speaking, only unilateral server data is truly + "unsolicited". + + Certain server data MUST be recorded by the client when it is + received; this is noted in the description of that data. Such data + conveys critical information which affects the interpretation of all + subsequent commands and responses (e.g., updates reflecting the + creation or destruction of messages). + + Other server data SHOULD be recorded for later reference; if the + client does not need to record the data, or if recording the data has + no obvious purpose (e.g., a SEARCH response when no SEARCH command is + in progress), the data SHOULD be ignored. + + An example of unilateral untagged server data occurs when the IMAP + connection is in the selected state. In the selected state, the + server checks the mailbox for new messages as part of command + execution. Normally, this is part of the execution of every command; + hence, a NOOP command suffices to check for new messages. If new + messages are found, the server sends untagged EXISTS and RECENT + responses reflecting the new size of the mailbox. Server + implementations that offer multiple simultaneous access to the same + mailbox SHOULD also send appropriate unilateral untagged FETCH and + EXPUNGE responses if another agent changes the state of any message + flags or expunges any messages. + + Command continuation request responses use the token "+" instead of a + tag. These responses are sent by the server to indicate acceptance + of an incomplete client command and readiness for the remainder of + the command. + +7.1. Server Responses - Status Responses + + Status responses are OK, NO, BAD, PREAUTH and BYE. OK, NO, and BAD + can be tagged or untagged. PREAUTH and BYE are always untagged. + + Status responses MAY include an OPTIONAL "response code". A response + code consists of data inside square brackets in the form of an atom, + possibly followed by a space and arguments. The response code + contains additional information or status codes for client software + beyond the OK/NO/BAD condition, and are defined when there is a + specific action that a client can take based upon the additional + information. + + + + + +Crispin Standards Track [Page 63] + +RFC 3501 IMAPv4 March 2003 + + + The currently defined response codes are: + + ALERT + + The human-readable text contains a special alert that MUST be + presented to the user in a fashion that calls the user's + attention to the message. + + BADCHARSET + + Optionally followed by a parenthesized list of charsets. A + SEARCH failed because the given charset is not supported by + this implementation. If the optional list of charsets is + given, this lists the charsets that are supported by this + implementation. + + CAPABILITY + + Followed by a list of capabilities. This can appear in the + initial OK or PREAUTH response to transmit an initial + capabilities list. This makes it unnecessary for a client to + send a separate CAPABILITY command if it recognizes this + response. + + PARSE + + The human-readable text represents an error in parsing the + [RFC-2822] header or [MIME-IMB] headers of a message in the + mailbox. + + PERMANENTFLAGS + + Followed by a parenthesized list of flags, indicates which of + the known flags the client can change permanently. Any flags + that are in the FLAGS untagged response, but not the + PERMANENTFLAGS list, can not be set permanently. If the client + attempts to STORE a flag that is not in the PERMANENTFLAGS + list, the server will either ignore the change or store the + state change for the remainder of the current session only. + The PERMANENTFLAGS list can also include the special flag \*, + which indicates that it is possible to create new keywords by + attempting to store those flags in the mailbox. + + + + + + + + + +Crispin Standards Track [Page 64] + +RFC 3501 IMAPv4 March 2003 + + + READ-ONLY + + The mailbox is selected read-only, or its access while selected + has changed from read-write to read-only. + + READ-WRITE + + The mailbox is selected read-write, or its access while + selected has changed from read-only to read-write. + + TRYCREATE + + An APPEND or COPY attempt is failing because the target mailbox + does not exist (as opposed to some other reason). This is a + hint to the client that the operation can succeed if the + mailbox is first created by the CREATE command. + + UIDNEXT + + Followed by a decimal number, indicates the next unique + identifier value. Refer to section 2.3.1.1 for more + information. + + UIDVALIDITY + + Followed by a decimal number, indicates the unique identifier + validity value. Refer to section 2.3.1.1 for more information. + + UNSEEN + + Followed by a decimal number, indicates the number of the first + message without the \Seen flag set. + + Additional response codes defined by particular client or server + implementations SHOULD be prefixed with an "X" until they are + added to a revision of this protocol. Client implementations + SHOULD ignore response codes that they do not recognize. + +7.1.1. OK Response + + Contents: OPTIONAL response code + human-readable text + + The OK response indicates an information message from the server. + When tagged, it indicates successful completion of the associated + command. The human-readable text MAY be presented to the user as + an information message. The untagged form indicates an + + + + +Crispin Standards Track [Page 65] + +RFC 3501 IMAPv4 March 2003 + + + information-only message; the nature of the information MAY be + indicated by a response code. + + The untagged form is also used as one of three possible greetings + at connection startup. It indicates that the connection is not + yet authenticated and that a LOGIN command is needed. + + Example: S: * OK IMAP4rev1 server ready + C: A001 LOGIN fred blurdybloop + S: * OK [ALERT] System shutdown in 10 minutes + S: A001 OK LOGIN Completed + + +7.1.2. NO Response + + Contents: OPTIONAL response code + human-readable text + + The NO response indicates an operational error message from the + server. When tagged, it indicates unsuccessful completion of the + associated command. The untagged form indicates a warning; the + command can still complete successfully. The human-readable text + describes the condition. + + Example: C: A222 COPY 1:2 owatagusiam + S: * NO Disk is 98% full, please delete unnecessary data + S: A222 OK COPY completed + C: A223 COPY 3:200 blurdybloop + S: * NO Disk is 98% full, please delete unnecessary data + S: * NO Disk is 99% full, please delete unnecessary data + S: A223 NO COPY failed: disk is full + + +7.1.3. BAD Response + + Contents: OPTIONAL response code + human-readable text + + The BAD response indicates an error message from the server. When + tagged, it reports a protocol-level error in the client's command; + the tag indicates the command that caused the error. The untagged + form indicates a protocol-level error for which the associated + command can not be determined; it can also indicate an internal + server failure. The human-readable text describes the condition. + + + + + + + +Crispin Standards Track [Page 66] + +RFC 3501 IMAPv4 March 2003 + + + Example: C: ...very long command line... + S: * BAD Command line too long + C: ...empty line... + S: * BAD Empty command line + C: A443 EXPUNGE + S: * BAD Disk crash, attempting salvage to a new disk! + S: * OK Salvage successful, no data lost + S: A443 OK Expunge completed + + +7.1.4. PREAUTH Response + + Contents: OPTIONAL response code + human-readable text + + The PREAUTH response is always untagged, and is one of three + possible greetings at connection startup. It indicates that the + connection has already been authenticated by external means; thus + no LOGIN command is needed. + + Example: S: * PREAUTH IMAP4rev1 server logged in as Smith + + +7.1.5. BYE Response + + Contents: OPTIONAL response code + human-readable text + + The BYE response is always untagged, and indicates that the server + is about to close the connection. The human-readable text MAY be + displayed to the user in a status report by the client. The BYE + response is sent under one of four conditions: + + 1) as part of a normal logout sequence. The server will close + the connection after sending the tagged OK response to the + LOGOUT command. + + 2) as a panic shutdown announcement. The server closes the + connection immediately. + + 3) as an announcement of an inactivity autologout. The server + closes the connection immediately. + + 4) as one of three possible greetings at connection startup, + indicating that the server is not willing to accept a + connection from this client. The server closes the + connection immediately. + + + + +Crispin Standards Track [Page 67] + +RFC 3501 IMAPv4 March 2003 + + + The difference between a BYE that occurs as part of a normal + LOGOUT sequence (the first case) and a BYE that occurs because of + a failure (the other three cases) is that the connection closes + immediately in the failure case. In all cases the client SHOULD + continue to read response data from the server until the + connection is closed; this will ensure that any pending untagged + or completion responses are read and processed. + + Example: S: * BYE Autologout; idle for too long + +7.2. Server Responses - Server and Mailbox Status + + These responses are always untagged. This is how server and mailbox + status data are transmitted from the server to the client. Many of + these responses typically result from a command with the same name. + +7.2.1. CAPABILITY Response + + Contents: capability listing + + The CAPABILITY response occurs as a result of a CAPABILITY + command. The capability listing contains a space-separated + listing of capability names that the server supports. The + capability listing MUST include the atom "IMAP4rev1". + + In addition, client and server implementations MUST implement the + STARTTLS, LOGINDISABLED, and AUTH=PLAIN (described in [IMAP-TLS]) + capabilities. See the Security Considerations section for + important information. + + A capability name which begins with "AUTH=" indicates that the + server supports that particular authentication mechanism. + + The LOGINDISABLED capability indicates that the LOGIN command is + disabled, and that the server will respond with a tagged NO + response to any attempt to use the LOGIN command even if the user + name and password are valid. An IMAP client MUST NOT issue the + LOGIN command if the server advertises the LOGINDISABLED + capability. + + Other capability names indicate that the server supports an + extension, revision, or amendment to the IMAP4rev1 protocol. + Server responses MUST conform to this document until the client + issues a command that uses the associated capability. + + Capability names MUST either begin with "X" or be standard or + standards-track IMAP4rev1 extensions, revisions, or amendments + registered with IANA. A server MUST NOT offer unregistered or + + + +Crispin Standards Track [Page 68] + +RFC 3501 IMAPv4 March 2003 + + + non-standard capability names, unless such names are prefixed with + an "X". + + Client implementations SHOULD NOT require any capability name + other than "IMAP4rev1", and MUST ignore any unknown capability + names. + + A server MAY send capabilities automatically, by using the + CAPABILITY response code in the initial PREAUTH or OK responses, + and by sending an updated CAPABILITY response code in the tagged + OK response as part of a successful authentication. It is + unnecessary for a client to send a separate CAPABILITY command if + it recognizes these automatic capabilities. + + Example: S: * CAPABILITY IMAP4rev1 STARTTLS AUTH=GSSAPI XPIG-LATIN + + +7.2.2. LIST Response + + Contents: name attributes + hierarchy delimiter + name + + The LIST response occurs as a result of a LIST command. It + returns a single name that matches the LIST specification. There + can be multiple LIST responses for a single LIST command. + + Four name attributes are defined: + + \Noinferiors + It is not possible for any child levels of hierarchy to exist + under this name; no child levels exist now and none can be + created in the future. + + \Noselect + It is not possible to use this name as a selectable mailbox. + + \Marked + The mailbox has been marked "interesting" by the server; the + mailbox probably contains messages that have been added since + the last time the mailbox was selected. + + \Unmarked + The mailbox does not contain any additional messages since the + last time the mailbox was selected. + + + + + + +Crispin Standards Track [Page 69] + +RFC 3501 IMAPv4 March 2003 + + + If it is not feasible for the server to determine whether or not + the mailbox is "interesting", or if the name is a \Noselect name, + the server SHOULD NOT send either \Marked or \Unmarked. + + The hierarchy delimiter is a character used to delimit levels of + hierarchy in a mailbox name. A client can use it to create child + mailboxes, and to search higher or lower levels of naming + hierarchy. All children of a top-level hierarchy node MUST use + the same separator character. A NIL hierarchy delimiter means + that no hierarchy exists; the name is a "flat" name. + + The name represents an unambiguous left-to-right hierarchy, and + MUST be valid for use as a reference in LIST and LSUB commands. + Unless \Noselect is indicated, the name MUST also be valid as an + argument for commands, such as SELECT, that accept mailbox names. + + Example: S: * LIST (\Noselect) "/" ~/Mail/foo + + +7.2.3. LSUB Response + + Contents: name attributes + hierarchy delimiter + name + + The LSUB response occurs as a result of an LSUB command. It + returns a single name that matches the LSUB specification. There + can be multiple LSUB responses for a single LSUB command. The + data is identical in format to the LIST response. + + Example: S: * LSUB () "." #news.comp.mail.misc + + +7.2.4 STATUS Response + + Contents: name + status parenthesized list + + The STATUS response occurs as a result of an STATUS command. It + returns the mailbox name that matches the STATUS specification and + the requested mailbox status information. + + Example: S: * STATUS blurdybloop (MESSAGES 231 UIDNEXT 44292) + + + + + + + + +Crispin Standards Track [Page 70] + +RFC 3501 IMAPv4 March 2003 + + +7.2.5. SEARCH Response + + Contents: zero or more numbers + + The SEARCH response occurs as a result of a SEARCH or UID SEARCH + command. The number(s) refer to those messages that match the + search criteria. For SEARCH, these are message sequence numbers; + for UID SEARCH, these are unique identifiers. Each number is + delimited by a space. + + Example: S: * SEARCH 2 3 6 + + +7.2.6. FLAGS Response + + Contents: flag parenthesized list + + The FLAGS response occurs as a result of a SELECT or EXAMINE + command. The flag parenthesized list identifies the flags (at a + minimum, the system-defined flags) that are applicable for this + mailbox. Flags other than the system flags can also exist, + depending on server implementation. + + The update from the FLAGS response MUST be recorded by the client. + + Example: S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) + + +7.3. Server Responses - Mailbox Size + + These responses are always untagged. This is how changes in the size + of the mailbox are transmitted from the server to the client. + Immediately following the "*" token is a number that represents a + message count. + +7.3.1. EXISTS Response + + Contents: none + + The EXISTS response reports the number of messages in the mailbox. + This response occurs as a result of a SELECT or EXAMINE command, + and if the size of the mailbox changes (e.g., new messages). + + The update from the EXISTS response MUST be recorded by the + client. + + Example: S: * 23 EXISTS + + + + +Crispin Standards Track [Page 71] + +RFC 3501 IMAPv4 March 2003 + + +7.3.2. RECENT Response + + Contents: none + + The RECENT response reports the number of messages with the + \Recent flag set. This response occurs as a result of a SELECT or + EXAMINE command, and if the size of the mailbox changes (e.g., new + messages). + + Note: It is not guaranteed that the message sequence + numbers of recent messages will be a contiguous range of + the highest n messages in the mailbox (where n is the + value reported by the RECENT response). Examples of + situations in which this is not the case are: multiple + clients having the same mailbox open (the first session + to be notified will see it as recent, others will + probably see it as non-recent), and when the mailbox is + re-ordered by a non-IMAP agent. + + The only reliable way to identify recent messages is to + look at message flags to see which have the \Recent flag + set, or to do a SEARCH RECENT. + + The update from the RECENT response MUST be recorded by the + client. + + Example: S: * 5 RECENT + + +7.4. Server Responses - Message Status + + These responses are always untagged. This is how message data are + transmitted from the server to the client, often as a result of a + command with the same name. Immediately following the "*" token is a + number that represents a message sequence number. + +7.4.1. EXPUNGE Response + + Contents: none + + The EXPUNGE response reports that the specified message sequence + number has been permanently removed from the mailbox. The message + sequence number for each successive message in the mailbox is + immediately decremented by 1, and this decrement is reflected in + message sequence numbers in subsequent responses (including other + untagged EXPUNGE responses). + + + + + +Crispin Standards Track [Page 72] + +RFC 3501 IMAPv4 March 2003 + + + The EXPUNGE response also decrements the number of messages in the + mailbox; it is not necessary to send an EXISTS response with the + new value. + + As a result of the immediate decrement rule, message sequence + numbers that appear in a set of successive EXPUNGE responses + depend upon whether the messages are removed starting from lower + numbers to higher numbers, or from higher numbers to lower + numbers. For example, if the last 5 messages in a 9-message + mailbox are expunged, a "lower to higher" server will send five + untagged EXPUNGE responses for message sequence number 5, whereas + a "higher to lower server" will send successive untagged EXPUNGE + responses for message sequence numbers 9, 8, 7, 6, and 5. + + An EXPUNGE response MUST NOT be sent when no command is in + progress, nor while responding to a FETCH, STORE, or SEARCH + command. This rule is necessary to prevent a loss of + synchronization of message sequence numbers between client and + server. A command is not "in progress" until the complete command + has been received; in particular, a command is not "in progress" + during the negotiation of command continuation. + + Note: UID FETCH, UID STORE, and UID SEARCH are different + commands from FETCH, STORE, and SEARCH. An EXPUNGE + response MAY be sent during a UID command. + + The update from the EXPUNGE response MUST be recorded by the + client. + + Example: S: * 44 EXPUNGE + + +7.4.2. FETCH Response + + Contents: message data + + The FETCH response returns data about a message to the client. + The data are pairs of data item names and their values in + parentheses. This response occurs as the result of a FETCH or + STORE command, as well as by unilateral server decision (e.g., + flag updates). + + The current data items are: + + BODY + A form of BODYSTRUCTURE without extension data. + + + + + +Crispin Standards Track [Page 73] + +RFC 3501 IMAPv4 March 2003 + + + BODY[
]<> + A string expressing the body contents of the specified section. + The string SHOULD be interpreted by the client according to the + content transfer encoding, body type, and subtype. + + If the origin octet is specified, this string is a substring of + the entire body contents, starting at that origin octet. This + means that BODY[]<0> MAY be truncated, but BODY[] is NEVER + truncated. + + Note: The origin octet facility MUST NOT be used by a server + in a FETCH response unless the client specifically requested + it by means of a FETCH of a BODY[
]<> data + item. + + 8-bit textual data is permitted if a [CHARSET] identifier is + part of the body parameter parenthesized list for this section. + Note that headers (part specifiers HEADER or MIME, or the + header portion of a MESSAGE/RFC822 part), MUST be 7-bit; 8-bit + characters are not permitted in headers. Note also that the + [RFC-2822] delimiting blank line between the header and the + body is not affected by header line subsetting; the blank line + is always included as part of header data, except in the case + of a message which has no body and no blank line. + + Non-textual data such as binary data MUST be transfer encoded + into a textual form, such as BASE64, prior to being sent to the + client. To derive the original binary data, the client MUST + decode the transfer encoded string. + + BODYSTRUCTURE + A parenthesized list that describes the [MIME-IMB] body + structure of a message. This is computed by the server by + parsing the [MIME-IMB] header fields, defaulting various fields + as necessary. + + For example, a simple text message of 48 lines and 2279 octets + can have a body structure of: ("TEXT" "PLAIN" ("CHARSET" + "US-ASCII") NIL NIL "7BIT" 2279 48) + + Multiple parts are indicated by parenthesis nesting. Instead + of a body type as the first element of the parenthesized list, + there is a sequence of one or more nested body structures. The + second element of the parenthesized list is the multipart + subtype (mixed, digest, parallel, alternative, etc.). + + + + + + +Crispin Standards Track [Page 74] + +RFC 3501 IMAPv4 March 2003 + + + For example, a two part message consisting of a text and a + BASE64-encoded text attachment can have a body structure of: + (("TEXT" "PLAIN" ("CHARSET" "US-ASCII") NIL NIL "7BIT" 1152 + 23)("TEXT" "PLAIN" ("CHARSET" "US-ASCII" "NAME" "cc.diff") + "<960723163407.20117h@cac.washington.edu>" "Compiler diff" + "BASE64" 4554 73) "MIXED") + + Extension data follows the multipart subtype. Extension data + is never returned with the BODY fetch, but can be returned with + a BODYSTRUCTURE fetch. Extension data, if present, MUST be in + the defined order. The extension data of a multipart body part + are in the following order: + + body parameter parenthesized list + A parenthesized list of attribute/value pairs [e.g., ("foo" + "bar" "baz" "rag") where "bar" is the value of "foo", and + "rag" is the value of "baz"] as defined in [MIME-IMB]. + + body disposition + A parenthesized list, consisting of a disposition type + string, followed by a parenthesized list of disposition + attribute/value pairs as defined in [DISPOSITION]. + + body language + A string or parenthesized list giving the body language + value as defined in [LANGUAGE-TAGS]. + + body location + A string list giving the body content URI as defined in + [LOCATION]. + + Any following extension data are not yet defined in this + version of the protocol. Such extension data can consist of + zero or more NILs, strings, numbers, or potentially nested + parenthesized lists of such data. Client implementations that + do a BODYSTRUCTURE fetch MUST be prepared to accept such + extension data. Server implementations MUST NOT send such + extension data until it has been defined by a revision of this + protocol. + + The basic fields of a non-multipart body part are in the + following order: + + body type + A string giving the content media type name as defined in + [MIME-IMB]. + + + + + +Crispin Standards Track [Page 75] + +RFC 3501 IMAPv4 March 2003 + + + body subtype + A string giving the content subtype name as defined in + [MIME-IMB]. + + body parameter parenthesized list + A parenthesized list of attribute/value pairs [e.g., ("foo" + "bar" "baz" "rag") where "bar" is the value of "foo" and + "rag" is the value of "baz"] as defined in [MIME-IMB]. + + body id + A string giving the content id as defined in [MIME-IMB]. + + body description + A string giving the content description as defined in + [MIME-IMB]. + + body encoding + A string giving the content transfer encoding as defined in + [MIME-IMB]. + + body size + A number giving the size of the body in octets. Note that + this size is the size in its transfer encoding and not the + resulting size after any decoding. + + A body type of type MESSAGE and subtype RFC822 contains, + immediately after the basic fields, the envelope structure, + body structure, and size in text lines of the encapsulated + message. + + A body type of type TEXT contains, immediately after the basic + fields, the size of the body in text lines. Note that this + size is the size in its content transfer encoding and not the + resulting size after any decoding. + + Extension data follows the basic fields and the type-specific + fields listed above. Extension data is never returned with the + BODY fetch, but can be returned with a BODYSTRUCTURE fetch. + Extension data, if present, MUST be in the defined order. + + The extension data of a non-multipart body part are in the + following order: + + body MD5 + A string giving the body MD5 value as defined in [MD5]. + + + + + + +Crispin Standards Track [Page 76] + +RFC 3501 IMAPv4 March 2003 + + + body disposition + A parenthesized list with the same content and function as + the body disposition for a multipart body part. + + body language + A string or parenthesized list giving the body language + value as defined in [LANGUAGE-TAGS]. + + body location + A string list giving the body content URI as defined in + [LOCATION]. + + Any following extension data are not yet defined in this + version of the protocol, and would be as described above under + multipart extension data. + + ENVELOPE + A parenthesized list that describes the envelope structure of a + message. This is computed by the server by parsing the + [RFC-2822] header into the component parts, defaulting various + fields as necessary. + + The fields of the envelope structure are in the following + order: date, subject, from, sender, reply-to, to, cc, bcc, + in-reply-to, and message-id. The date, subject, in-reply-to, + and message-id fields are strings. The from, sender, reply-to, + to, cc, and bcc fields are parenthesized lists of address + structures. + + An address structure is a parenthesized list that describes an + electronic mail address. The fields of an address structure + are in the following order: personal name, [SMTP] + at-domain-list (source route), mailbox name, and host name. + + [RFC-2822] group syntax is indicated by a special form of + address structure in which the host name field is NIL. If the + mailbox name field is also NIL, this is an end of group marker + (semi-colon in RFC 822 syntax). If the mailbox name field is + non-NIL, this is a start of group marker, and the mailbox name + field holds the group name phrase. + + If the Date, Subject, In-Reply-To, and Message-ID header lines + are absent in the [RFC-2822] header, the corresponding member + of the envelope is NIL; if these header lines are present but + empty the corresponding member of the envelope is the empty + string. + + + + + +Crispin Standards Track [Page 77] + +RFC 3501 IMAPv4 March 2003 + + + Note: some servers may return a NIL envelope member in the + "present but empty" case. Clients SHOULD treat NIL and + empty string as identical. + + Note: [RFC-2822] requires that all messages have a valid + Date header. Therefore, the date member in the envelope can + not be NIL or the empty string. + + Note: [RFC-2822] requires that the In-Reply-To and + Message-ID headers, if present, have non-empty content. + Therefore, the in-reply-to and message-id members in the + envelope can not be the empty string. + + If the From, To, cc, and bcc header lines are absent in the + [RFC-2822] header, or are present but empty, the corresponding + member of the envelope is NIL. + + If the Sender or Reply-To lines are absent in the [RFC-2822] + header, or are present but empty, the server sets the + corresponding member of the envelope to be the same value as + the from member (the client is not expected to know to do + this). + + Note: [RFC-2822] requires that all messages have a valid + From header. Therefore, the from, sender, and reply-to + members in the envelope can not be NIL. + + FLAGS + A parenthesized list of flags that are set for this message. + + INTERNALDATE + A string representing the internal date of the message. + + RFC822 + Equivalent to BODY[]. + + RFC822.HEADER + Equivalent to BODY[HEADER]. Note that this did not result in + \Seen being set, because RFC822.HEADER response data occurs as + a result of a FETCH of RFC822.HEADER. BODY[HEADER] response + data occurs as a result of a FETCH of BODY[HEADER] (which sets + \Seen) or BODY.PEEK[HEADER] (which does not set \Seen). + + RFC822.SIZE + A number expressing the [RFC-2822] size of the message. + + + + + + +Crispin Standards Track [Page 78] + +RFC 3501 IMAPv4 March 2003 + + + RFC822.TEXT + Equivalent to BODY[TEXT]. + + UID + A number expressing the unique identifier of the message. + + + Example: S: * 23 FETCH (FLAGS (\Seen) RFC822.SIZE 44827) + + +7.5. Server Responses - Command Continuation Request + + The command continuation request response is indicated by a "+" token + instead of a tag. This form of response indicates that the server is + ready to accept the continuation of a command from the client. The + remainder of this response is a line of text. + + This response is used in the AUTHENTICATE command to transmit server + data to the client, and request additional client data. This + response is also used if an argument to any command is a literal. + + The client is not permitted to send the octets of the literal unless + the server indicates that it is expected. This permits the server to + process commands and reject errors on a line-by-line basis. The + remainder of the command, including the CRLF that terminates a + command, follows the octets of the literal. If there are any + additional command arguments, the literal octets are followed by a + space and those arguments. + + Example: C: A001 LOGIN {11} + S: + Ready for additional command text + C: FRED FOOBAR {7} + S: + Ready for additional command text + C: fat man + S: A001 OK LOGIN completed + C: A044 BLURDYBLOOP {102856} + S: A044 BAD No such command as "BLURDYBLOOP" + + + + + + + + + + + + + + +Crispin Standards Track [Page 79] + +RFC 3501 IMAPv4 March 2003 + + +8. Sample IMAP4rev1 connection + + The following is a transcript of an IMAP4rev1 connection. A long + line in this sample is broken for editorial clarity. + +S: * OK IMAP4rev1 Service Ready +C: a001 login mrc secret +S: a001 OK LOGIN completed +C: a002 select inbox +S: * 18 EXISTS +S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) +S: * 2 RECENT +S: * OK [UNSEEN 17] Message 17 is the first unseen message +S: * OK [UIDVALIDITY 3857529045] UIDs valid +S: a002 OK [READ-WRITE] SELECT completed +C: a003 fetch 12 full +S: * 12 FETCH (FLAGS (\Seen) INTERNALDATE "17-Jul-1996 02:44:25 -0700" + RFC822.SIZE 4286 ENVELOPE ("Wed, 17 Jul 1996 02:23:25 -0700 (PDT)" + "IMAP4rev1 WG mtg summary and minutes" + (("Terry Gray" NIL "gray" "cac.washington.edu")) + (("Terry Gray" NIL "gray" "cac.washington.edu")) + (("Terry Gray" NIL "gray" "cac.washington.edu")) + ((NIL NIL "imap" "cac.washington.edu")) + ((NIL NIL "minutes" "CNRI.Reston.VA.US") + ("John Klensin" NIL "KLENSIN" "MIT.EDU")) NIL NIL + "") + BODY ("TEXT" "PLAIN" ("CHARSET" "US-ASCII") NIL NIL "7BIT" 3028 + 92)) +S: a003 OK FETCH completed +C: a004 fetch 12 body[header] +S: * 12 FETCH (BODY[HEADER] {342} +S: Date: Wed, 17 Jul 1996 02:23:25 -0700 (PDT) +S: From: Terry Gray +S: Subject: IMAP4rev1 WG mtg summary and minutes +S: To: imap@cac.washington.edu +S: cc: minutes@CNRI.Reston.VA.US, John Klensin +S: Message-Id: +S: MIME-Version: 1.0 +S: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII +S: +S: ) +S: a004 OK FETCH completed +C: a005 store 12 +flags \deleted +S: * 12 FETCH (FLAGS (\Seen \Deleted)) +S: a005 OK +FLAGS completed +C: a006 logout +S: * BYE IMAP4rev1 server terminating connection +S: a006 OK LOGOUT completed + + + +Crispin Standards Track [Page 80] + +RFC 3501 IMAPv4 March 2003 + + +9. Formal Syntax + + The following syntax specification uses the Augmented Backus-Naur + Form (ABNF) notation as specified in [ABNF]. + + In the case of alternative or optional rules in which a later rule + overlaps an earlier rule, the rule which is listed earlier MUST take + priority. For example, "\Seen" when parsed as a flag is the \Seen + flag name and not a flag-extension, even though "\Seen" can be parsed + as a flag-extension. Some, but not all, instances of this rule are + noted below. + + Note: [ABNF] rules MUST be followed strictly; in + particular: + + (1) Except as noted otherwise, all alphabetic characters + are case-insensitive. The use of upper or lower case + characters to define token strings is for editorial clarity + only. Implementations MUST accept these strings in a + case-insensitive fashion. + + (2) In all cases, SP refers to exactly one space. It is + NOT permitted to substitute TAB, insert additional spaces, + or otherwise treat SP as being equivalent to LWSP. + + (3) The ASCII NUL character, %x00, MUST NOT be used at any + time. + +address = "(" addr-name SP addr-adl SP addr-mailbox SP + addr-host ")" + +addr-adl = nstring + ; Holds route from [RFC-2822] route-addr if + ; non-NIL + +addr-host = nstring + ; NIL indicates [RFC-2822] group syntax. + ; Otherwise, holds [RFC-2822] domain name + +addr-mailbox = nstring + ; NIL indicates end of [RFC-2822] group; if + ; non-NIL and addr-host is NIL, holds + ; [RFC-2822] group name. + ; Otherwise, holds [RFC-2822] local-part + ; after removing [RFC-2822] quoting + + + + + + +Crispin Standards Track [Page 81] + +RFC 3501 IMAPv4 March 2003 + + +addr-name = nstring + ; If non-NIL, holds phrase from [RFC-2822] + ; mailbox after removing [RFC-2822] quoting + +append = "APPEND" SP mailbox [SP flag-list] [SP date-time] SP + literal + +astring = 1*ASTRING-CHAR / string + +ASTRING-CHAR = ATOM-CHAR / resp-specials + +atom = 1*ATOM-CHAR + +ATOM-CHAR = + +atom-specials = "(" / ")" / "{" / SP / CTL / list-wildcards / + quoted-specials / resp-specials + +authenticate = "AUTHENTICATE" SP auth-type *(CRLF base64) + +auth-type = atom + ; Defined by [SASL] + +base64 = *(4base64-char) [base64-terminal] + +base64-char = ALPHA / DIGIT / "+" / "/" + ; Case-sensitive + +base64-terminal = (2base64-char "==") / (3base64-char "=") + +body = "(" (body-type-1part / body-type-mpart) ")" + +body-extension = nstring / number / + "(" body-extension *(SP body-extension) ")" + ; Future expansion. Client implementations + ; MUST accept body-extension fields. Server + ; implementations MUST NOT generate + ; body-extension fields except as defined by + ; future standard or standards-track + ; revisions of this specification. + +body-ext-1part = body-fld-md5 [SP body-fld-dsp [SP body-fld-lang + [SP body-fld-loc *(SP body-extension)]]] + ; MUST NOT be returned on non-extensible + ; "BODY" fetch + + + + + + +Crispin Standards Track [Page 82] + +RFC 3501 IMAPv4 March 2003 + + +body-ext-mpart = body-fld-param [SP body-fld-dsp [SP body-fld-lang + [SP body-fld-loc *(SP body-extension)]]] + ; MUST NOT be returned on non-extensible + ; "BODY" fetch + +body-fields = body-fld-param SP body-fld-id SP body-fld-desc SP + body-fld-enc SP body-fld-octets + +body-fld-desc = nstring + +body-fld-dsp = "(" string SP body-fld-param ")" / nil + +body-fld-enc = (DQUOTE ("7BIT" / "8BIT" / "BINARY" / "BASE64"/ + "QUOTED-PRINTABLE") DQUOTE) / string + +body-fld-id = nstring + +body-fld-lang = nstring / "(" string *(SP string) ")" + +body-fld-loc = nstring + +body-fld-lines = number + +body-fld-md5 = nstring + +body-fld-octets = number + +body-fld-param = "(" string SP string *(SP string SP string) ")" / nil + +body-type-1part = (body-type-basic / body-type-msg / body-type-text) + [SP body-ext-1part] + +body-type-basic = media-basic SP body-fields + ; MESSAGE subtype MUST NOT be "RFC822" + +body-type-mpart = 1*body SP media-subtype + [SP body-ext-mpart] + +body-type-msg = media-message SP body-fields SP envelope + SP body SP body-fld-lines + +body-type-text = media-text SP body-fields SP body-fld-lines + +capability = ("AUTH=" auth-type) / atom + ; New capabilities MUST begin with "X" or be + ; registered with IANA as standard or + ; standards-track + + + + +Crispin Standards Track [Page 83] + +RFC 3501 IMAPv4 March 2003 + + +capability-data = "CAPABILITY" *(SP capability) SP "IMAP4rev1" + *(SP capability) + ; Servers MUST implement the STARTTLS, AUTH=PLAIN, + ; and LOGINDISABLED capabilities + ; Servers which offer RFC 1730 compatibility MUST + ; list "IMAP4" as the first capability. + +CHAR8 = %x01-ff + ; any OCTET except NUL, %x00 + +command = tag SP (command-any / command-auth / command-nonauth / + command-select) CRLF + ; Modal based on state + +command-any = "CAPABILITY" / "LOGOUT" / "NOOP" / x-command + ; Valid in all states + +command-auth = append / create / delete / examine / list / lsub / + rename / select / status / subscribe / unsubscribe + ; Valid only in Authenticated or Selected state + +command-nonauth = login / authenticate / "STARTTLS" + ; Valid only when in Not Authenticated state + +command-select = "CHECK" / "CLOSE" / "EXPUNGE" / copy / fetch / store / + uid / search + ; Valid only when in Selected state + +continue-req = "+" SP (resp-text / base64) CRLF + +copy = "COPY" SP sequence-set SP mailbox + +create = "CREATE" SP mailbox + ; Use of INBOX gives a NO error + +date = date-text / DQUOTE date-text DQUOTE + +date-day = 1*2DIGIT + ; Day of month + +date-day-fixed = (SP DIGIT) / 2DIGIT + ; Fixed-format version of date-day + +date-month = "Jan" / "Feb" / "Mar" / "Apr" / "May" / "Jun" / + "Jul" / "Aug" / "Sep" / "Oct" / "Nov" / "Dec" + +date-text = date-day "-" date-month "-" date-year + + + + +Crispin Standards Track [Page 84] + +RFC 3501 IMAPv4 March 2003 + + +date-year = 4DIGIT + +date-time = DQUOTE date-day-fixed "-" date-month "-" date-year + SP time SP zone DQUOTE + +delete = "DELETE" SP mailbox + ; Use of INBOX gives a NO error + +digit-nz = %x31-39 + ; 1-9 + +envelope = "(" env-date SP env-subject SP env-from SP + env-sender SP env-reply-to SP env-to SP env-cc SP + env-bcc SP env-in-reply-to SP env-message-id ")" + +env-bcc = "(" 1*address ")" / nil + +env-cc = "(" 1*address ")" / nil + +env-date = nstring + +env-from = "(" 1*address ")" / nil + +env-in-reply-to = nstring + +env-message-id = nstring + +env-reply-to = "(" 1*address ")" / nil + +env-sender = "(" 1*address ")" / nil + +env-subject = nstring + +env-to = "(" 1*address ")" / nil + +examine = "EXAMINE" SP mailbox + +fetch = "FETCH" SP sequence-set SP ("ALL" / "FULL" / "FAST" / + fetch-att / "(" fetch-att *(SP fetch-att) ")") + +fetch-att = "ENVELOPE" / "FLAGS" / "INTERNALDATE" / + "RFC822" [".HEADER" / ".SIZE" / ".TEXT"] / + "BODY" ["STRUCTURE"] / "UID" / + "BODY" section ["<" number "." nz-number ">"] / + "BODY.PEEK" section ["<" number "." nz-number ">"] + + + + + + +Crispin Standards Track [Page 85] + +RFC 3501 IMAPv4 March 2003 + + +flag = "\Answered" / "\Flagged" / "\Deleted" / + "\Seen" / "\Draft" / flag-keyword / flag-extension + ; Does not include "\Recent" + +flag-extension = "\" atom + ; Future expansion. Client implementations + ; MUST accept flag-extension flags. Server + ; implementations MUST NOT generate + ; flag-extension flags except as defined by + ; future standard or standards-track + ; revisions of this specification. + +flag-fetch = flag / "\Recent" + +flag-keyword = atom + +flag-list = "(" [flag *(SP flag)] ")" + +flag-perm = flag / "\*" + +greeting = "*" SP (resp-cond-auth / resp-cond-bye) CRLF + +header-fld-name = astring + +header-list = "(" header-fld-name *(SP header-fld-name) ")" + +list = "LIST" SP mailbox SP list-mailbox + +list-mailbox = 1*list-char / string + +list-char = ATOM-CHAR / list-wildcards / resp-specials + +list-wildcards = "%" / "*" + +literal = "{" number "}" CRLF *CHAR8 + ; Number represents the number of CHAR8s + +login = "LOGIN" SP userid SP password + +lsub = "LSUB" SP mailbox SP list-mailbox + + + + + + + + + + + +Crispin Standards Track [Page 86] + +RFC 3501 IMAPv4 March 2003 + + +mailbox = "INBOX" / astring + ; INBOX is case-insensitive. All case variants of + ; INBOX (e.g., "iNbOx") MUST be interpreted as INBOX + ; not as an astring. An astring which consists of + ; the case-insensitive sequence "I" "N" "B" "O" "X" + ; is considered to be INBOX and not an astring. + ; Refer to section 5.1 for further + ; semantic details of mailbox names. + +mailbox-data = "FLAGS" SP flag-list / "LIST" SP mailbox-list / + "LSUB" SP mailbox-list / "SEARCH" *(SP nz-number) / + "STATUS" SP mailbox SP "(" [status-att-list] ")" / + number SP "EXISTS" / number SP "RECENT" + +mailbox-list = "(" [mbx-list-flags] ")" SP + (DQUOTE QUOTED-CHAR DQUOTE / nil) SP mailbox + +mbx-list-flags = *(mbx-list-oflag SP) mbx-list-sflag + *(SP mbx-list-oflag) / + mbx-list-oflag *(SP mbx-list-oflag) + +mbx-list-oflag = "\Noinferiors" / flag-extension + ; Other flags; multiple possible per LIST response + +mbx-list-sflag = "\Noselect" / "\Marked" / "\Unmarked" + ; Selectability flags; only one per LIST response + +media-basic = ((DQUOTE ("APPLICATION" / "AUDIO" / "IMAGE" / + "MESSAGE" / "VIDEO") DQUOTE) / string) SP + media-subtype + ; Defined in [MIME-IMT] + +media-message = DQUOTE "MESSAGE" DQUOTE SP DQUOTE "RFC822" DQUOTE + ; Defined in [MIME-IMT] + +media-subtype = string + ; Defined in [MIME-IMT] + +media-text = DQUOTE "TEXT" DQUOTE SP media-subtype + ; Defined in [MIME-IMT] + +message-data = nz-number SP ("EXPUNGE" / ("FETCH" SP msg-att)) + +msg-att = "(" (msg-att-dynamic / msg-att-static) + *(SP (msg-att-dynamic / msg-att-static)) ")" + +msg-att-dynamic = "FLAGS" SP "(" [flag-fetch *(SP flag-fetch)] ")" + ; MAY change for a message + + + +Crispin Standards Track [Page 87] + +RFC 3501 IMAPv4 March 2003 + + +msg-att-static = "ENVELOPE" SP envelope / "INTERNALDATE" SP date-time / + "RFC822" [".HEADER" / ".TEXT"] SP nstring / + "RFC822.SIZE" SP number / + "BODY" ["STRUCTURE"] SP body / + "BODY" section ["<" number ">"] SP nstring / + "UID" SP uniqueid + ; MUST NOT change for a message + +nil = "NIL" + +nstring = string / nil + +number = 1*DIGIT + ; Unsigned 32-bit integer + ; (0 <= n < 4,294,967,296) + +nz-number = digit-nz *DIGIT + ; Non-zero unsigned 32-bit integer + ; (0 < n < 4,294,967,296) + +password = astring + +quoted = DQUOTE *QUOTED-CHAR DQUOTE + +QUOTED-CHAR = / + "\" quoted-specials + +quoted-specials = DQUOTE / "\" + +rename = "RENAME" SP mailbox SP mailbox + ; Use of INBOX as a destination gives a NO error + +response = *(continue-req / response-data) response-done + +response-data = "*" SP (resp-cond-state / resp-cond-bye / + mailbox-data / message-data / capability-data) CRLF + +response-done = response-tagged / response-fatal + +response-fatal = "*" SP resp-cond-bye CRLF + ; Server closes connection immediately + +response-tagged = tag SP resp-cond-state CRLF + +resp-cond-auth = ("OK" / "PREAUTH") SP resp-text + ; Authentication condition + + + + + +Crispin Standards Track [Page 88] + +RFC 3501 IMAPv4 March 2003 + + +resp-cond-bye = "BYE" SP resp-text + +resp-cond-state = ("OK" / "NO" / "BAD") SP resp-text + ; Status condition + +resp-specials = "]" + +resp-text = ["[" resp-text-code "]" SP] text + +resp-text-code = "ALERT" / + "BADCHARSET" [SP "(" astring *(SP astring) ")" ] / + capability-data / "PARSE" / + "PERMANENTFLAGS" SP "(" + [flag-perm *(SP flag-perm)] ")" / + "READ-ONLY" / "READ-WRITE" / "TRYCREATE" / + "UIDNEXT" SP nz-number / "UIDVALIDITY" SP nz-number / + "UNSEEN" SP nz-number / + atom [SP 1*] + +search = "SEARCH" [SP "CHARSET" SP astring] 1*(SP search-key) + ; CHARSET argument to MUST be registered with IANA + +search-key = "ALL" / "ANSWERED" / "BCC" SP astring / + "BEFORE" SP date / "BODY" SP astring / + "CC" SP astring / "DELETED" / "FLAGGED" / + "FROM" SP astring / "KEYWORD" SP flag-keyword / + "NEW" / "OLD" / "ON" SP date / "RECENT" / "SEEN" / + "SINCE" SP date / "SUBJECT" SP astring / + "TEXT" SP astring / "TO" SP astring / + "UNANSWERED" / "UNDELETED" / "UNFLAGGED" / + "UNKEYWORD" SP flag-keyword / "UNSEEN" / + ; Above this line were in [IMAP2] + "DRAFT" / "HEADER" SP header-fld-name SP astring / + "LARGER" SP number / "NOT" SP search-key / + "OR" SP search-key SP search-key / + "SENTBEFORE" SP date / "SENTON" SP date / + "SENTSINCE" SP date / "SMALLER" SP number / + "UID" SP sequence-set / "UNDRAFT" / sequence-set / + "(" search-key *(SP search-key) ")" + +section = "[" [section-spec] "]" + +section-msgtext = "HEADER" / "HEADER.FIELDS" [".NOT"] SP header-list / + "TEXT" + ; top-level or MESSAGE/RFC822 part + +section-part = nz-number *("." nz-number) + ; body part nesting + + + +Crispin Standards Track [Page 89] + +RFC 3501 IMAPv4 March 2003 + + +section-spec = section-msgtext / (section-part ["." section-text]) + +section-text = section-msgtext / "MIME" + ; text other than actual body part (headers, etc.) + +select = "SELECT" SP mailbox + +seq-number = nz-number / "*" + ; message sequence number (COPY, FETCH, STORE + ; commands) or unique identifier (UID COPY, + ; UID FETCH, UID STORE commands). + ; * represents the largest number in use. In + ; the case of message sequence numbers, it is + ; the number of messages in a non-empty mailbox. + ; In the case of unique identifiers, it is the + ; unique identifier of the last message in the + ; mailbox or, if the mailbox is empty, the + ; mailbox's current UIDNEXT value. + ; The server should respond with a tagged BAD + ; response to a command that uses a message + ; sequence number greater than the number of + ; messages in the selected mailbox. This + ; includes "*" if the selected mailbox is empty. + +seq-range = seq-number ":" seq-number + ; two seq-number values and all values between + ; these two regardless of order. + ; Example: 2:4 and 4:2 are equivalent and indicate + ; values 2, 3, and 4. + ; Example: a unique identifier sequence range of + ; 3291:* includes the UID of the last message in + ; the mailbox, even if that value is less than 3291. + +sequence-set = (seq-number / seq-range) *("," sequence-set) + ; set of seq-number values, regardless of order. + ; Servers MAY coalesce overlaps and/or execute the + ; sequence in any order. + ; Example: a message sequence number set of + ; 2,4:7,9,12:* for a mailbox with 15 messages is + ; equivalent to 2,4,5,6,7,9,12,13,14,15 + ; Example: a message sequence number set of *:4,5:7 + ; for a mailbox with 10 messages is equivalent to + ; 10,9,8,7,6,5,4,5,6,7 and MAY be reordered and + ; overlap coalesced to be 4,5,6,7,8,9,10. + +status = "STATUS" SP mailbox SP + "(" status-att *(SP status-att) ")" + + + + +Crispin Standards Track [Page 90] + +RFC 3501 IMAPv4 March 2003 + + +status-att = "MESSAGES" / "RECENT" / "UIDNEXT" / "UIDVALIDITY" / + "UNSEEN" + +status-att-list = status-att SP number *(SP status-att SP number) + +store = "STORE" SP sequence-set SP store-att-flags + +store-att-flags = (["+" / "-"] "FLAGS" [".SILENT"]) SP + (flag-list / (flag *(SP flag))) + +string = quoted / literal + +subscribe = "SUBSCRIBE" SP mailbox + +tag = 1* + +text = 1*TEXT-CHAR + +TEXT-CHAR = + +time = 2DIGIT ":" 2DIGIT ":" 2DIGIT + ; Hours minutes seconds + +uid = "UID" SP (copy / fetch / search / store) + ; Unique identifiers used instead of message + ; sequence numbers + +uniqueid = nz-number + ; Strictly ascending + +unsubscribe = "UNSUBSCRIBE" SP mailbox + +userid = astring + +x-command = "X" atom + +zone = ("+" / "-") 4DIGIT + ; Signed four-digit value of hhmm representing + ; hours and minutes east of Greenwich (that is, + ; the amount that the given time differs from + ; Universal Time). Subtracting the timezone + ; from the given time will give the UT form. + ; The Universal Time zone is "+0000". + + + + + + + + +Crispin Standards Track [Page 91] + +RFC 3501 IMAPv4 March 2003 + + +10. Author's Note + + This document is a revision or rewrite of earlier documents, and + supercedes the protocol specification in those documents: RFC 2060, + RFC 1730, unpublished IMAP2bis.TXT document, RFC 1176, and RFC 1064. + +11. Security Considerations + + IMAP4rev1 protocol transactions, including electronic mail data, are + sent in the clear over the network unless protection from snooping is + negotiated. This can be accomplished either by the use of STARTTLS, + negotiated privacy protection in the AUTHENTICATE command, or some + other protection mechanism. + +11.1. STARTTLS Security Considerations + + The specification of the STARTTLS command and LOGINDISABLED + capability in this document replaces that in [IMAP-TLS]. [IMAP-TLS] + remains normative for the PLAIN [SASL] authenticator. + + IMAP client and server implementations MUST implement the + TLS_RSA_WITH_RC4_128_MD5 [TLS] cipher suite, and SHOULD implement the + TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA [TLS] cipher suite. This is + important as it assures that any two compliant implementations can be + configured to interoperate. All other cipher suites are OPTIONAL. + Note that this is a change from section 2.1 of [IMAP-TLS]. + + During the [TLS] negotiation, the client MUST check its understanding + of the server hostname against the server's identity as presented in + the server Certificate message, in order to prevent man-in-the-middle + attacks. If the match fails, the client SHOULD either ask for + explicit user confirmation, or terminate the connection and indicate + that the server's identity is suspect. Matching is performed + according to these rules: + + The client MUST use the server hostname it used to open the + connection as the value to compare against the server name + as expressed in the server certificate. The client MUST + NOT use any form of the server hostname derived from an + insecure remote source (e.g., insecure DNS lookup). CNAME + canonicalization is not done. + + If a subjectAltName extension of type dNSName is present in + the certificate, it SHOULD be used as the source of the + server's identity. + + Matching is case-insensitive. + + + + +Crispin Standards Track [Page 92] + +RFC 3501 IMAPv4 March 2003 + + + A "*" wildcard character MAY be used as the left-most name + component in the certificate. For example, *.example.com + would match a.example.com, foo.example.com, etc. but would + not match example.com. + + If the certificate contains multiple names (e.g., more than + one dNSName field), then a match with any one of the fields + is considered acceptable. + + Both the client and server MUST check the result of the STARTTLS + command and subsequent [TLS] negotiation to see whether acceptable + authentication or privacy was achieved. + +11.2. Other Security Considerations + + A server error message for an AUTHENTICATE command which fails due to + invalid credentials SHOULD NOT detail why the credentials are + invalid. + + Use of the LOGIN command sends passwords in the clear. This can be + avoided by using the AUTHENTICATE command with a [SASL] mechanism + that does not use plaintext passwords, by first negotiating + encryption via STARTTLS or some other protection mechanism. + + A server implementation MUST implement a configuration that, at the + time of authentication, requires: + (1) The STARTTLS command has been negotiated. + OR + (2) Some other mechanism that protects the session from password + snooping has been provided. + OR + (3) The following measures are in place: + (a) The LOGINDISABLED capability is advertised, and [SASL] + mechanisms (such as PLAIN) using plaintext passwords are NOT + advertised in the CAPABILITY list. + AND + (b) The LOGIN command returns an error even if the password is + correct. + AND + (c) The AUTHENTICATE command returns an error with all [SASL] + mechanisms that use plaintext passwords, even if the password + is correct. + + A server error message for a failing LOGIN command SHOULD NOT specify + that the user name, as opposed to the password, is invalid. + + A server SHOULD have mechanisms in place to limit or delay failed + AUTHENTICATE/LOGIN attempts. + + + +Crispin Standards Track [Page 93] + +RFC 3501 IMAPv4 March 2003 + + + Additional security considerations are discussed in the section + discussing the AUTHENTICATE and LOGIN commands. + +12. IANA Considerations + + IMAP4 capabilities are registered by publishing a standards track or + IESG approved experimental RFC. The registry is currently located + at: + + http://www.iana.org/assignments/imap4-capabilities + + As this specification revises the STARTTLS and LOGINDISABLED + extensions previously defined in [IMAP-TLS], the registry will be + updated accordingly. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Crispin Standards Track [Page 94] + +RFC 3501 IMAPv4 March 2003 + + +Appendices + +A. Normative References + + The following documents contain definitions or specifications that + are necessary to understand this document properly: + [ABNF] Crocker, D. and P. Overell, "Augmented BNF for + Syntax Specifications: ABNF", RFC 2234, + November 1997. + + [ANONYMOUS] Newman, C., "Anonymous SASL Mechanism", RFC + 2245, November 1997. + + [CHARSET] Freed, N. and J. Postel, "IANA Character Set + Registration Procedures", RFC 2978, October + 2000. + + [DIGEST-MD5] Leach, P. and C. Newman, "Using Digest + Authentication as a SASL Mechanism", RFC 2831, + May 2000. + + [DISPOSITION] Troost, R., Dorner, S. and K. Moore, + "Communicating Presentation Information in + Internet Messages: The Content-Disposition + Header", RFC 2183, August 1997. + + [IMAP-TLS] Newman, C., "Using TLS with IMAP, POP3 and + ACAP", RFC 2595, June 1999. + + [KEYWORDS] Bradner, S., "Key words for use in RFCs to + Indicate Requirement Levels", BCP 14, RFC 2119, + March 1997. + + [LANGUAGE-TAGS] Alvestrand, H., "Tags for the Identification of + Languages", BCP 47, RFC 3066, January 2001. + + [LOCATION] Palme, J., Hopmann, A. and N. Shelness, "MIME + Encapsulation of Aggregate Documents, such as + HTML (MHTML)", RFC 2557, March 1999. + + [MD5] Myers, J. and M. Rose, "The Content-MD5 Header + Field", RFC 1864, October 1995. + + + + + + + + + +Crispin Standards Track [Page 95] + +RFC 3501 IMAPv4 March 2003 + + + [MIME-HDRS] Moore, K., "MIME (Multipurpose Internet Mail + Extensions) Part Three: Message Header + Extensions for Non-ASCII Text", RFC 2047, + November 1996. + + [MIME-IMB] Freed, N. and N. Borenstein, "MIME + (Multipurpose Internet Mail Extensions) Part + One: Format of Internet Message Bodies", RFC + 2045, November 1996. + + [MIME-IMT] Freed, N. and N. Borenstein, "MIME + (Multipurpose Internet Mail Extensions) Part + Two: Media Types", RFC 2046, November 1996. + + [RFC-2822] Resnick, P., "Internet Message Format", RFC + 2822, April 2001. + + [SASL] Myers, J., "Simple Authentication and Security + Layer (SASL)", RFC 2222, October 1997. + + [TLS] Dierks, T. and C. Allen, "The TLS Protocol + Version 1.0", RFC 2246, January 1999. + + [UTF-7] Goldsmith, D. and M. Davis, "UTF-7: A Mail-Safe + Transformation Format of Unicode", RFC 2152, + May 1997. + + The following documents describe quality-of-implementation issues + that should be carefully considered when implementing this protocol: + + [IMAP-IMPLEMENTATION] Leiba, B., "IMAP Implementation + Recommendations", RFC 2683, September 1999. + + [IMAP-MULTIACCESS] Gahrns, M., "IMAP4 Multi-Accessed Mailbox + Practice", RFC 2180, July 1997. + +A.1 Informative References + + The following documents describe related protocols: + + [IMAP-DISC] Austein, R., "Synchronization Operations for + Disconnected IMAP4 Clients", Work in Progress. + + [IMAP-MODEL] Crispin, M., "Distributed Electronic Mail + Models in IMAP4", RFC 1733, December 1994. + + + + + + +Crispin Standards Track [Page 96] + +RFC 3501 IMAPv4 March 2003 + + + [ACAP] Newman, C. and J. Myers, "ACAP -- Application + Configuration Access Protocol", RFC 2244, + November 1997. + + [SMTP] Klensin, J., "Simple Mail Transfer Protocol", + STD 10, RFC 2821, April 2001. + + The following documents are historical or describe historical aspects + of this protocol: + + [IMAP-COMPAT] Crispin, M., "IMAP4 Compatibility with + IMAP2bis", RFC 2061, December 1996. + + [IMAP-HISTORICAL] Crispin, M., "IMAP4 Compatibility with IMAP2 + and IMAP2bis", RFC 1732, December 1994. + + [IMAP-OBSOLETE] Crispin, M., "Internet Message Access Protocol + - Obsolete Syntax", RFC 2062, December 1996. + + [IMAP2] Crispin, M., "Interactive Mail Access Protocol + - Version 2", RFC 1176, August 1990. + + [RFC-822] Crocker, D., "Standard for the Format of ARPA + Internet Text Messages", STD 11, RFC 822, + August 1982. + + [RFC-821] Postel, J., "Simple Mail Transfer Protocol", + STD 10, RFC 821, August 1982. + +B. Changes from RFC 2060 + + 1) Clarify description of unique identifiers and their semantics. + + 2) Fix the SELECT description to clarify that UIDVALIDITY is required + in the SELECT and EXAMINE responses. + + 3) Added an example of a failing search. + + 4) Correct store-att-flags: "#flag" should be "1#flag". + + 5) Made search and section rules clearer. + + 6) Correct the STORE example. + + 7) Correct "BASE645" misspelling. + + 8) Remove extraneous close parenthesis in example of two-part message + with text and BASE64 attachment. + + + +Crispin Standards Track [Page 97] + +RFC 3501 IMAPv4 March 2003 + + + 9) Remove obsolete "MAILBOX" response from mailbox-data. + + 10) A spurious "<" in the rule for mailbox-data was removed. + + 11) Add CRLF to continue-req. + + 12) Specifically exclude "]" from the atom in resp-text-code. + + 13) Clarify that clients and servers should adhere strictly to the + protocol syntax. + + 14) Emphasize in 5.2 that EXISTS can not be used to shrink a mailbox. + + 15) Add NEWNAME to resp-text-code. + + 16) Clarify that the empty string, not NIL, is used as arguments to + LIST. + + 17) Clarify that NIL can be returned as a hierarchy delimiter for the + empty string mailbox name argument if the mailbox namespace is flat. + + 18) Clarify that addr-mailbox and addr-name have RFC-2822 quoting + removed. + + 19) Update UTF-7 reference. + + 20) Fix example in 6.3.11. + + 21) Clarify that non-existent UIDs are ignored. + + 22) Update DISPOSITION reference. + + 23) Expand state diagram. + + 24) Clarify that partial fetch responses are only returned in + response to a partial fetch command. + + 25) Add UIDNEXT response code. Correct UIDVALIDITY definition + reference. + + 26) Further clarification of "can" vs. "MAY". + + 27) Reference RFC-2119. + + 28) Clarify that superfluous shifts are not permitted in modified + UTF-7. + + 29) Clarify that there are no implicit shifts in modified UTF-7. + + + +Crispin Standards Track [Page 98] + +RFC 3501 IMAPv4 March 2003 + + + 30) Clarify that "INBOX" in a mailbox name is always INBOX, even if + it is given as a string. + + 31) Add missing open parenthesis in media-basic grammar rule. + + 32) Correct attribute syntax in mailbox-data. + + 33) Add UIDNEXT to EXAMINE responses. + + 34) Clarify UNSEEN, PERMANENTFLAGS, UIDVALIDITY, and UIDNEXT + responses in SELECT and EXAMINE. They are required now, but weren't + in older versions. + + 35) Update references with RFC numbers. + + 36) Flush text-mime2. + + 37) Clarify that modified UTF-7 names must be case-sensitive and that + violating the convention should be avoided. + + 38) Correct UID FETCH example. + + 39) Clarify UID FETCH, UID STORE, and UID SEARCH vs. untagged EXPUNGE + responses. + + 40) Clarify the use of the word "convention". + + 41) Clarify that a command is not "in progress" until it has been + fully received (specifically, that a command is not "in progress" + during command continuation negotiation). + + 42) Clarify envelope defaulting. + + 43) Clarify that SP means one and only one space character. + + 44) Forbid silly states in LIST response. + + 45) Clarify that the ENVELOPE, INTERNALDATE, RFC822*, BODY*, and UID + for a message is static. + + 46) Add BADCHARSET response code. + + 47) Update formal syntax to [ABNF] conventions. + + 48) Clarify trailing hierarchy delimiter in CREATE semantics. + + 49) Clarify that the "blank line" is the [RFC-2822] delimiting blank + line. + + + +Crispin Standards Track [Page 99] + +RFC 3501 IMAPv4 March 2003 + + + 50) Clarify that RENAME should also create hierarchy as needed for + the command to complete. + + 51) Fix body-ext-mpart to not require language if disposition + present. + + 52) Clarify the RFC822.HEADER response. + + 53) Correct missing space after charset astring in search. + + 54) Correct missing quote for BADCHARSET in resp-text-code. + + 55) Clarify that ALL, FAST, and FULL preclude any other data items + appearing. + + 56) Clarify semantics of reference argument in LIST. + + 57) Clarify that a null string for SEARCH HEADER X-FOO means any + message with a header line with a field-name of X-FOO regardless of + the text of the header. + + 58) Specifically reserve 8-bit mailbox names for future use as UTF-8. + + 59) It is not an error for the client to store a flag that is not in + the PERMANENTFLAGS list; however, the server will either ignore the + change or make the change in the session only. + + 60) Correct/clarify the text regarding superfluous shifts. + + 61) Correct typographic errors in the "Changes" section. + + 62) Clarify that STATUS must not be used to check for new messages in + the selected mailbox + + 63) Clarify LSUB behavior with "%" wildcard. + + 64) Change AUTHORIZATION to AUTHENTICATE in section 7.5. + + 65) Clarify description of multipart body type. + + 66) Clarify that STORE FLAGS does not affect \Recent. + + 67) Change "west" to "east" in description of timezone. + + 68) Clarify that commands which break command pipelining must wait + for a completion result response. + + 69) Clarify that EXAMINE does not affect \Recent. + + + +Crispin Standards Track [Page 100] + +RFC 3501 IMAPv4 March 2003 + + + 70) Make description of MIME structure consistent. + + 71) Clarify that date searches disregard the time and timezone of the + INTERNALDATE or Date: header. In other words, "ON 13-APR-2000" means + messages with an INTERNALDATE text which starts with "13-APR-2000", + even if timezone differential from the local timezone is sufficient + to move that INTERNALDATE into the previous or next day. + + 72) Clarify that the header fetches don't add a blank line if one + isn't in the [RFC-2822] message. + + 73) Clarify (in discussion of UIDs) that messages are immutable. + + 74) Add an example of CHARSET searching. + + 75) Clarify in SEARCH that keywords are a type of flag. + + 76) Clarify the mandatory nature of the SELECT data responses. + + 77) Add optional CAPABILITY response code in the initial OK or + PREAUTH. + + 78) Add note that server can send an untagged CAPABILITY command as + part of the responses to AUTHENTICATE and LOGIN. + + 79) Remove statement about it being unnecessary to issue a CAPABILITY + command more than once in a connection. That statement is no longer + true. + + 80) Clarify that untagged EXPUNGE decrements the number of messages + in the mailbox. + + 81) Fix definition of "body" (concatenation has tighter binding than + alternation). + + 82) Add a new "Special Notes to Implementors" section with reference + to [IMAP-IMPLEMENTATION]. + + 83) Clarify that an untagged CAPABILITY response to an AUTHENTICATE + command should only be done if a security layer was not negotiated. + + 84) Change the definition of atom to exclude "]". Update astring to + include "]" for compatibility with the past. Remove resp-text-atom. + + 85) Remove NEWNAME. It can't work because mailbox names can be + literals and can include "]". Functionality can be addressed via + referrals. + + + + +Crispin Standards Track [Page 101] + +RFC 3501 IMAPv4 March 2003 + + + 86) Move modified UTF-7 rationale in order to have more logical + paragraph flow. + + 87) Clarify UID uniqueness guarantees with the use of MUST. + + 88) Note that clients should read response data until the connection + is closed instead of immediately closing on a BYE. + + 89) Change RFC-822 references to RFC-2822. + + 90) Clarify that RFC-2822 should be followed instead of RFC-822. + + 91) Change recommendation of optional automatic capabilities in LOGIN + and AUTHENTICATE to use the CAPABILITY response code in the tagged + OK. This is more interoperable than an unsolicited untagged + CAPABILITY response. + + 92) STARTTLS and AUTH=PLAIN are mandatory to implement; add + recommendations for other [SASL] mechanisms. + + 93) Clarify that a "connection" (as opposed to "server" or "command") + is in one of the four states. + + 94) Clarify that a failed or rejected command does not change state. + + 95) Split references between normative and informative. + + 96) Discuss authentication failure issues in security section. + + 97) Clarify that a data item is not necessarily of only one data + type. + + 98) Clarify that sequence ranges are independent of order. + + 99) Change an example to clarify that superfluous shifts in + Modified-UTF7 can not be fixed just by omitting the shift. The + entire string must be recalculated. + + 100) Change Envelope Structure definition since [RFC-2822] uses + "envelope" to refer to the [SMTP] envelope and not the envelope data + that appears in the [RFC-2822] header. + + 101) Expand on RFC822.HEADER response data vs. BODY[HEADER]. + + 102) Clarify Logout state semantics, change ASCII art. + + 103) Security changes to comply with IESG requirements. + + + + +Crispin Standards Track [Page 102] + +RFC 3501 IMAPv4 March 2003 + + + 104) Add definition for body URI. + + 105) Break sequence range definition into three rules, with rewritten + descriptions for each. + + 106) Move STARTTLS and LOGINDISABLED here from [IMAP-TLS]. + + 107) Add IANA Considerations section. + + 108) Clarify valid client assumptions for new message UIDs vs. + UIDNEXT. + + 109) Clarify that changes to permanentflags affect concurrent + sessions as well as subsequent sessions. + + 110) Clarify that authenticated state can be entered by the CLOSE + command. + + 111) Emphasize that SELECT and EXAMINE are the exceptions to the rule + that a failing command does not change state. + + 112) Clarify that newly-appended messages have the Recent flag set. + + 113) Clarify that newly-copied messages SHOULD have the Recent flag + set. + + 114) Clarify that UID commands always return the UID in FETCH + responses. + +C. Key Word Index + + +FLAGS (store command data item) ............... 59 + +FLAGS.SILENT (store command data item) ........ 59 + -FLAGS (store command data item) ............... 59 + -FLAGS.SILENT (store command data item) ........ 59 + ALERT (response code) ...................................... 64 + ALL (fetch item) ........................................... 55 + ALL (search key) ........................................... 50 + ANSWERED (search key) ...................................... 50 + APPEND (command) ........................................... 45 + AUTHENTICATE (command) ..................................... 27 + BAD (response) ............................................. 66 + BADCHARSET (response code) ................................. 64 + BCC (search key) .................................. 51 + BEFORE (search key) ................................. 51 + BODY (fetch item) .......................................... 55 + BODY (fetch result) ........................................ 73 + BODY (search key) ................................. 51 + + + +Crispin Standards Track [Page 103] + +RFC 3501 IMAPv4 March 2003 + + + BODY.PEEK[
]<> (fetch item) ............... 57 + BODYSTRUCTURE (fetch item) ................................. 57 + BODYSTRUCTURE (fetch result) ............................... 74 + BODY[
]<> (fetch result) ............. 74 + BODY[
]<> (fetch item) .................... 55 + BYE (response) ............................................. 67 + Body Structure (message attribute) ......................... 12 + CAPABILITY (command) ....................................... 24 + CAPABILITY (response code) ................................. 64 + CAPABILITY (response) ...................................... 68 + CC (search key) ................................... 51 + CHECK (command) ............................................ 47 + CLOSE (command) ............................................ 48 + COPY (command) ............................................. 59 + CREATE (command) ........................................... 34 + DELETE (command) ........................................... 35 + DELETED (search key) ....................................... 51 + DRAFT (search key) ......................................... 51 + ENVELOPE (fetch item) ...................................... 57 + ENVELOPE (fetch result) .................................... 77 + EXAMINE (command) .......................................... 33 + EXISTS (response) .......................................... 71 + EXPUNGE (command) .......................................... 48 + EXPUNGE (response) ......................................... 72 + Envelope Structure (message attribute) ..................... 12 + FAST (fetch item) .......................................... 55 + FETCH (command) ............................................ 54 + FETCH (response) ........................................... 73 + FLAGGED (search key) ....................................... 51 + FLAGS (fetch item) ......................................... 57 + FLAGS (fetch result) ....................................... 78 + FLAGS (response) ........................................... 71 + FLAGS (store command data item) ................ 59 + FLAGS.SILENT (store command data item) ......... 59 + FROM (search key) ................................. 51 + FULL (fetch item) .......................................... 55 + Flags (message attribute) .................................. 11 + HEADER (part specifier) .................................... 55 + HEADER (search key) .................. 51 + HEADER.FIELDS (part specifier) ............... 55 + HEADER.FIELDS.NOT (part specifier) ........... 55 + INTERNALDATE (fetch item) .................................. 57 + INTERNALDATE (fetch result) ................................ 78 + Internal Date (message attribute) .......................... 12 + KEYWORD (search key) ................................ 51 + Keyword (type of flag) ..................................... 11 + LARGER (search key) .................................... 51 + LIST (command) ............................................. 40 + + + +Crispin Standards Track [Page 104] + +RFC 3501 IMAPv4 March 2003 + + + LIST (response) ............................................ 69 + LOGIN (command) ............................................ 30 + LOGOUT (command) ........................................... 25 + LSUB (command) ............................................. 43 + LSUB (response) ............................................ 70 + MAY (specification requirement term) ....................... 4 + MESSAGES (status item) ..................................... 45 + MIME (part specifier) ...................................... 56 + MUST (specification requirement term) ...................... 4 + MUST NOT (specification requirement term) .................. 4 + Message Sequence Number (message attribute) ................ 10 + NEW (search key) ........................................... 51 + NO (response) .............................................. 66 + NOOP (command) ............................................. 25 + NOT (search key) .............................. 52 + OK (response) .............................................. 65 + OLD (search key) ........................................... 52 + ON (search key) ..................................... 52 + OPTIONAL (specification requirement term) .................. 4 + OR (search key) ................ 52 + PARSE (response code) ...................................... 64 + PERMANENTFLAGS (response code) ............................. 64 + PREAUTH (response) ......................................... 67 + Permanent Flag (class of flag) ............................. 12 + READ-ONLY (response code) .................................. 65 + READ-WRITE (response code) ................................. 65 + RECENT (response) .......................................... 72 + RECENT (search key) ........................................ 52 + RECENT (status item) ....................................... 45 + RENAME (command) ........................................... 37 + REQUIRED (specification requirement term) .................. 4 + RFC822 (fetch item) ........................................ 57 + RFC822 (fetch result) ...................................... 78 + RFC822.HEADER (fetch item) ................................. 57 + RFC822.HEADER (fetch result) ............................... 78 + RFC822.SIZE (fetch item) ................................... 57 + RFC822.SIZE (fetch result) ................................. 78 + RFC822.TEXT (fetch item) ................................... 58 + RFC822.TEXT (fetch result) ................................. 79 + SEARCH (command) ........................................... 49 + SEARCH (response) .......................................... 71 + SEEN (search key) .......................................... 52 + SELECT (command) ........................................... 31 + SENTBEFORE (search key) ............................. 52 + SENTON (search key) ................................. 52 + SENTSINCE (search key) .............................. 52 + SHOULD (specification requirement term) .................... 4 + SHOULD NOT (specification requirement term) ................ 4 + + + +Crispin Standards Track [Page 105] + +RFC 3501 IMAPv4 March 2003 + + + SINCE (search key) .................................. 52 + SMALLER (search key) ................................... 52 + STARTTLS (command) ......................................... 27 + STATUS (command) ........................................... 44 + STATUS (response) .......................................... 70 + STORE (command) ............................................ 58 + SUBJECT (search key) .............................. 53 + SUBSCRIBE (command) ........................................ 38 + Session Flag (class of flag) ............................... 12 + System Flag (type of flag) ................................. 11 + TEXT (part specifier) ...................................... 56 + TEXT (search key) ................................. 53 + TO (search key) ................................... 53 + TRYCREATE (response code) .................................. 65 + UID (command) .............................................. 60 + UID (fetch item) ........................................... 58 + UID (fetch result) ......................................... 79 + UID (search key) ............................ 53 + UIDNEXT (response code) .................................... 65 + UIDNEXT (status item) ...................................... 45 + UIDVALIDITY (response code) ................................ 65 + UIDVALIDITY (status item) .................................. 45 + UNANSWERED (search key) .................................... 53 + UNDELETED (search key) ..................................... 53 + UNDRAFT (search key) ....................................... 53 + UNFLAGGED (search key) ..................................... 53 + UNKEYWORD (search key) .............................. 53 + UNSEEN (response code) ..................................... 65 + UNSEEN (search key) ........................................ 53 + UNSEEN (status item) ....................................... 45 + UNSUBSCRIBE (command) ...................................... 39 + Unique Identifier (UID) (message attribute) ................ 8 + X (command) .......................................... 62 + [RFC-2822] Size (message attribute) ........................ 12 + \Answered (system flag) .................................... 11 + \Deleted (system flag) ..................................... 11 + \Draft (system flag) ....................................... 11 + \Flagged (system flag) ..................................... 11 + \Marked (mailbox name attribute) ........................... 69 + \Noinferiors (mailbox name attribute) ...................... 69 + \Noselect (mailbox name attribute) ......................... 69 + \Recent (system flag) ...................................... 11 + \Seen (system flag) ........................................ 11 + \Unmarked (mailbox name attribute) ......................... 69 + + + + + + + +Crispin Standards Track [Page 106] + +RFC 3501 IMAPv4 March 2003 + + +Author's Address + + Mark R. Crispin + Networks and Distributed Computing + University of Washington + 4545 15th Avenue NE + Seattle, WA 98105-4527 + + Phone: (206) 543-5762 + + EMail: MRC@CAC.Washington.EDU + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Crispin Standards Track [Page 107] + +RFC 3501 IMAPv4 March 2003 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2003). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. v This + document and the information contained herein is provided on an "AS + IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK + FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT + LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL + NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY + OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + + +Crispin Standards Track [Page 108] + diff --git a/RFCs/rfc4035.txt b/RFCs/rfc4035.txt new file mode 100644 index 0000000..b701cd2 --- /dev/null +++ b/RFCs/rfc4035.txt @@ -0,0 +1,2971 @@ + + + + + + +Network Working Group R. Arends +Request for Comments: 4035 Telematica Instituut +Obsoletes: 2535, 3008, 3090, 3445, 3655, 3658, R. Austein + 3755, 3757, 3845 ISC +Updates: 1034, 1035, 2136, 2181, 2308, 3225, M. Larson + 3007, 3597, 3226 VeriSign +Category: Standards Track D. Massey + Colorado State University + S. Rose + NIST + March 2005 + + + Protocol Modifications for the DNS Security Extensions + +Status of This Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2005). + +Abstract + + This document is part of a family of documents that describe the DNS + Security Extensions (DNSSEC). The DNS Security Extensions are a + collection of new resource records and protocol modifications that + add data origin authentication and data integrity to the DNS. This + document describes the DNSSEC protocol modifications. This document + defines the concept of a signed zone, along with the requirements for + serving and resolving by using DNSSEC. These techniques allow a + security-aware resolver to authenticate both DNS resource records and + authoritative DNS error indications. + + This document obsoletes RFC 2535 and incorporates changes from all + updates to RFC 2535. + + + + + + + + + + +Arends, et al. Standards Track [Page 1] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.1. Background and Related Documents . . . . . . . . . . . . 4 + 1.2. Reserved Words . . . . . . . . . . . . . . . . . . . . . 4 + 2. Zone Signing . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 2.1. Including DNSKEY RRs in a Zone . . . . . . . . . . . . . 5 + 2.2. Including RRSIG RRs in a Zone . . . . . . . . . . . . . 5 + 2.3. Including NSEC RRs in a Zone . . . . . . . . . . . . . . 6 + 2.4. Including DS RRs in a Zone . . . . . . . . . . . . . . . 7 + 2.5. Changes to the CNAME Resource Record. . . . . . . . . . 7 + 2.6. DNSSEC RR Types Appearing at Zone Cuts. . . . . . . . . 8 + 2.7. Example of a Secure Zone . . . . . . . . . . . . . . . . 8 + 3. Serving . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 + 3.1. Authoritative Name Servers . . . . . . . . . . . . . . . 9 + 3.1.1. Including RRSIG RRs in a Response . . . . . . . 10 + 3.1.2. Including DNSKEY RRs in a Response . . . . . . . 11 + 3.1.3. Including NSEC RRs in a Response . . . . . . . . 11 + 3.1.4. Including DS RRs in a Response . . . . . . . . . 14 + 3.1.5. Responding to Queries for Type AXFR or IXFR . . 15 + 3.1.6. The AD and CD Bits in an Authoritative Response. 16 + 3.2. Recursive Name Servers . . . . . . . . . . . . . . . . . 17 + 3.2.1. The DO Bit . . . . . . . . . . . . . . . . . . . 17 + 3.2.2. The CD Bit . . . . . . . . . . . . . . . . . . . 17 + 3.2.3. The AD Bit . . . . . . . . . . . . . . . . . . . 18 + 3.3. Example DNSSEC Responses . . . . . . . . . . . . . . . . 19 + 4. Resolving . . . . . . . . . . . . . . . . . . . . . . . . . . 19 + 4.1. EDNS Support . . . . . . . . . . . . . . . . . . . . . . 19 + 4.2. Signature Verification Support . . . . . . . . . . . . . 19 + 4.3. Determining Security Status of Data . . . . . . . . . . 20 + 4.4. Configured Trust Anchors . . . . . . . . . . . . . . . . 21 + 4.5. Response Caching . . . . . . . . . . . . . . . . . . . . 21 + 4.6. Handling of the CD and AD Bits . . . . . . . . . . . . . 22 + 4.7. Caching BAD Data . . . . . . . . . . . . . . . . . . . . 22 + 4.8. Synthesized CNAMEs . . . . . . . . . . . . . . . . . . . 23 + 4.9. Stub Resolvers . . . . . . . . . . . . . . . . . . . . . 23 + 4.9.1. Handling of the DO Bit . . . . . . . . . . . . . 24 + 4.9.2. Handling of the CD Bit . . . . . . . . . . . . . 24 + 4.9.3. Handling of the AD Bit . . . . . . . . . . . . . 24 + 5. Authenticating DNS Responses . . . . . . . . . . . . . . . . . 25 + 5.1. Special Considerations for Islands of Security . . . . . 26 + 5.2. Authenticating Referrals . . . . . . . . . . . . . . . . 26 + 5.3. Authenticating an RRset with an RRSIG RR . . . . . . . . 28 + 5.3.1. Checking the RRSIG RR Validity . . . . . . . . . 28 + 5.3.2. Reconstructing the Signed Data . . . . . . . . . 29 + 5.3.3. Checking the Signature . . . . . . . . . . . . . 31 + 5.3.4. Authenticating a Wildcard Expanded RRset + Positive Response. . . . . . . . . . . . . . . . 32 + + + +Arends, et al. Standards Track [Page 2] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + + 5.4. Authenticated Denial of Existence . . . . . . . . . . . 32 + 5.5. Resolver Behavior When Signatures Do Not Validate . . . 33 + 5.6. Authentication Example . . . . . . . . . . . . . . . . . 33 + 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 + 7. Security Considerations . . . . . . . . . . . . . . . . . . . 33 + 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 34 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34 + 9.1. Normative References . . . . . . . . . . . . . . . . . . 34 + 9.2. Informative References . . . . . . . . . . . . . . . . . 35 + A. Signed Zone Example . . . . . . . . . . . . . . . . . . . . . 36 + B. Example Responses . . . . . . . . . . . . . . . . . . . . . . 41 + B.1. Answer . . . . . . . . . . . . . . . . . . . . . . . . . 41 + B.2. Name Error . . . . . . . . . . . . . . . . . . . . . . . 43 + B.3. No Data Error . . . . . . . . . . . . . . . . . . . . . 44 + B.4. Referral to Signed Zone . . . . . . . . . . . . . . . . 44 + B.5. Referral to Unsigned Zone . . . . . . . . . . . . . . . 45 + B.6. Wildcard Expansion . . . . . . . . . . . . . . . . . . . 46 + B.7. Wildcard No Data Error . . . . . . . . . . . . . . . . . 47 + B.8. DS Child Zone No Data Error . . . . . . . . . . . . . . 48 + C. Authentication Examples . . . . . . . . . . . . . . . . . . . 49 + C.1. Authenticating an Answer . . . . . . . . . . . . . . . . 49 + C.1.1. Authenticating the Example DNSKEY RR . . . . . . 49 + C.2. Name Error . . . . . . . . . . . . . . . . . . . . . . . 50 + C.3. No Data Error . . . . . . . . . . . . . . . . . . . . . 50 + C.4. Referral to Signed Zone . . . . . . . . . . . . . . . . 50 + C.5. Referral to Unsigned Zone . . . . . . . . . . . . . . . 51 + C.6. Wildcard Expansion . . . . . . . . . . . . . . . . . . . 51 + C.7. Wildcard No Data Error . . . . . . . . . . . . . . . . . 51 + C.8. DS Child Zone No Data Error . . . . . . . . . . . . . . 51 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 52 + Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 53 + +1. Introduction + + The DNS Security Extensions (DNSSEC) are a collection of new resource + records and protocol modifications that add data origin + authentication and data integrity to the DNS. This document defines + the DNSSEC protocol modifications. Section 2 of this document + defines the concept of a signed zone and lists the requirements for + zone signing. Section 3 describes the modifications to authoritative + name server behavior necessary for handling signed zones. Section 4 + describes the behavior of entities that include security-aware + resolver functions. Finally, Section 5 defines how to use DNSSEC RRs + to authenticate a response. + + + + + + + +Arends, et al. Standards Track [Page 3] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + +1.1. Background and Related Documents + + This document is part of a family of documents defining DNSSEC that + should be read together as a set. + + [RFC4033] contains an introduction to DNSSEC and definitions of + common terms; the reader is assumed to be familiar with this + document. [RFC4033] also contains a list of other documents updated + by and obsoleted by this document set. + + [RFC4034] defines the DNSSEC resource records. + + The reader is also assumed to be familiar with the basic DNS concepts + described in [RFC1034], [RFC1035], and the subsequent documents that + update them; particularly, [RFC2181] and [RFC2308]. + + This document defines the DNSSEC protocol operations. + +1.2. Reserved Words + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [RFC2119]. + +2. Zone Signing + + DNSSEC introduces the concept of signed zones. A signed zone + includes DNS Public Key (DNSKEY), Resource Record Signature (RRSIG), + Next Secure (NSEC), and (optionally) Delegation Signer (DS) records + according to the rules specified in Sections 2.1, 2.2, 2.3, and 2.4, + respectively. A zone that does not include these records according + to the rules in this section is an unsigned zone. + + DNSSEC requires a change to the definition of the CNAME resource + record ([RFC1035]). Section 2.5 changes the CNAME RR to allow RRSIG + and NSEC RRs to appear at the same owner name as does a CNAME RR. + + DNSSEC specifies the placement of two new RR types, NSEC and DS, + which can be placed at the parental side of a zone cut (that is, at a + delegation point). This is an exception to the general prohibition + against putting data in the parent zone at a zone cut. Section 2.6 + describes this change. + + + + + + + + + +Arends, et al. Standards Track [Page 4] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + +2.1. Including DNSKEY RRs in a Zone + + To sign a zone, the zone's administrator generates one or more + public/private key pairs and uses the private key(s) to sign + authoritative RRsets in the zone. For each private key used to + create RRSIG RRs in a zone, the zone SHOULD include a zone DNSKEY RR + containing the corresponding public key. A zone key DNSKEY RR MUST + have the Zone Key bit of the flags RDATA field set (see Section 2.1.1 + of [RFC4034]). Public keys associated with other DNS operations MAY + be stored in DNSKEY RRs that are not marked as zone keys but MUST NOT + be used to verify RRSIGs. + + If the zone administrator intends a signed zone to be usable other + than as an island of security, the zone apex MUST contain at least + one DNSKEY RR to act as a secure entry point into the zone. This + secure entry point could then be used as the target of a secure + delegation via a corresponding DS RR in the parent zone (see + [RFC4034]). + +2.2. Including RRSIG RRs in a Zone + + For each authoritative RRset in a signed zone, there MUST be at least + one RRSIG record that meets the following requirements: + + o The RRSIG owner name is equal to the RRset owner name. + + o The RRSIG class is equal to the RRset class. + + o The RRSIG Type Covered field is equal to the RRset type. + + o The RRSIG Original TTL field is equal to the TTL of the RRset. + + o The RRSIG RR's TTL is equal to the TTL of the RRset. + + o The RRSIG Labels field is equal to the number of labels in the + RRset owner name, not counting the null root label and not + counting the leftmost label if it is a wildcard. + + o The RRSIG Signer's Name field is equal to the name of the zone + containing the RRset. + + o The RRSIG Algorithm, Signer's Name, and Key Tag fields identify a + zone key DNSKEY record at the zone apex. + + The process for constructing the RRSIG RR for a given RRset is + described in [RFC4034]. An RRset MAY have multiple RRSIG RRs + associated with it. Note that as RRSIG RRs are closely tied to the + RRsets whose signatures they contain, RRSIG RRs, unlike all other DNS + + + +Arends, et al. Standards Track [Page 5] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + + RR types, do not form RRsets. In particular, the TTL values among + RRSIG RRs with a common owner name do not follow the RRset rules + described in [RFC2181]. + + An RRSIG RR itself MUST NOT be signed, as signing an RRSIG RR would + add no value and would create an infinite loop in the signing + process. + + The NS RRset that appears at the zone apex name MUST be signed, but + the NS RRsets that appear at delegation points (that is, the NS + RRsets in the parent zone that delegate the name to the child zone's + name servers) MUST NOT be signed. Glue address RRsets associated + with delegations MUST NOT be signed. + + There MUST be an RRSIG for each RRset using at least one DNSKEY of + each algorithm in the zone apex DNSKEY RRset. The apex DNSKEY RRset + itself MUST be signed by each algorithm appearing in the DS RRset + located at the delegating parent (if any). + +2.3. Including NSEC RRs in a Zone + + Each owner name in the zone that has authoritative data or a + delegation point NS RRset MUST have an NSEC resource record. The + format of NSEC RRs and the process for constructing the NSEC RR for a + given name is described in [RFC4034]. + + The TTL value for any NSEC RR SHOULD be the same as the minimum TTL + value field in the zone SOA RR. + + An NSEC record (and its associated RRSIG RRset) MUST NOT be the only + RRset at any particular owner name. That is, the signing process + MUST NOT create NSEC or RRSIG RRs for owner name nodes that were not + the owner name of any RRset before the zone was signed. The main + reasons for this are a desire for namespace consistency between + signed and unsigned versions of the same zone and a desire to reduce + the risk of response inconsistency in security oblivious recursive + name servers. + + The type bitmap of every NSEC resource record in a signed zone MUST + indicate the presence of both the NSEC record itself and its + corresponding RRSIG record. + + The difference between the set of owner names that require RRSIG + records and the set of owner names that require NSEC records is + subtle and worth highlighting. RRSIG records are present at the + owner names of all authoritative RRsets. NSEC records are present at + the owner names of all names for which the signed zone is + authoritative and also at the owner names of delegations from the + + + +Arends, et al. Standards Track [Page 6] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + + signed zone to its children. Neither NSEC nor RRSIG records are + present (in the parent zone) at the owner names of glue address + RRsets. Note, however, that this distinction is for the most part + visible only during the zone signing process, as NSEC RRsets are + authoritative data and are therefore signed. Thus, any owner name + that has an NSEC RRset will have RRSIG RRs as well in the signed + zone. + + The bitmap for the NSEC RR at a delegation point requires special + attention. Bits corresponding to the delegation NS RRset and any + RRsets for which the parent zone has authoritative data MUST be set; + bits corresponding to any non-NS RRset for which the parent is not + authoritative MUST be clear. + +2.4. Including DS RRs in a Zone + + The DS resource record establishes authentication chains between DNS + zones. A DS RRset SHOULD be present at a delegation point when the + child zone is signed. The DS RRset MAY contain multiple records, + each referencing a public key in the child zone used to verify the + RRSIGs in that zone. All DS RRsets in a zone MUST be signed, and DS + RRsets MUST NOT appear at a zone's apex. + + A DS RR SHOULD point to a DNSKEY RR that is present in the child's + apex DNSKEY RRset, and the child's apex DNSKEY RRset SHOULD be signed + by the corresponding private key. DS RRs that fail to meet these + conditions are not useful for validation, but because the DS RR and + its corresponding DNSKEY RR are in different zones, and because the + DNS is only loosely consistent, temporary mismatches can occur. + + The TTL of a DS RRset SHOULD match the TTL of the delegating NS RRset + (that is, the NS RRset from the same zone containing the DS RRset). + + Construction of a DS RR requires knowledge of the corresponding + DNSKEY RR in the child zone, which implies communication between the + child and parent zones. This communication is an operational matter + not covered by this document. + +2.5. Changes to the CNAME Resource Record + + If a CNAME RRset is present at a name in a signed zone, appropriate + RRSIG and NSEC RRsets are REQUIRED at that name. A KEY RRset at that + name for secure dynamic update purposes is also allowed ([RFC3007]). + Other types MUST NOT be present at that name. + + This is a modification to the original CNAME definition given in + [RFC1034]. The original definition of the CNAME RR did not allow any + other types to coexist with a CNAME record, but a signed zone + + + +Arends, et al. Standards Track [Page 7] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + + requires NSEC and RRSIG RRs for every authoritative name. To resolve + this conflict, this specification modifies the definition of the + CNAME resource record to allow it to coexist with NSEC and RRSIG RRs. + +2.6. DNSSEC RR Types Appearing at Zone Cuts + + DNSSEC introduced two new RR types that are unusual in that they can + appear at the parental side of a zone cut. At the parental side of a + zone cut (that is, at a delegation point), NSEC RRs are REQUIRED at + the owner name. A DS RR could also be present if the zone being + delegated is signed and seeks to have a chain of authentication to + the parent zone. This is an exception to the original DNS + specification ([RFC1034]), which states that only NS RRsets could + appear at the parental side of a zone cut. + + This specification updates the original DNS specification to allow + NSEC and DS RR types at the parent side of a zone cut. These RRsets + are authoritative for the parent when they appear at the parent side + of a zone cut. + +2.7. Example of a Secure Zone + + Appendix A shows a complete example of a small signed zone. + +3. Serving + + This section describes the behavior of entities that include + security-aware name server functions. In many cases such functions + will be part of a security-aware recursive name server, but a + security-aware authoritative name server has some of the same + requirements. Functions specific to security-aware recursive name + servers are described in Section 3.2; functions specific to + authoritative servers are described in Section 3.1. + + In the following discussion, the terms "SNAME", "SCLASS", and "STYPE" + are as used in [RFC1034]. + + A security-aware name server MUST support the EDNS0 ([RFC2671]) + message size extension, MUST support a message size of at least 1220 + octets, and SHOULD support a message size of 4000 octets. As IPv6 + packets can only be fragmented by the source host, a security aware + name server SHOULD take steps to ensure that UDP datagrams it + transmits over IPv6 are fragmented, if necessary, at the minimum IPv6 + MTU, unless the path MTU is known. Please see [RFC1122], [RFC2460], + and [RFC3226] for further discussion of packet size and fragmentation + issues. + + + + + +Arends, et al. Standards Track [Page 8] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + + A security-aware name server that receives a DNS query that does not + include the EDNS OPT pseudo-RR or that has the DO bit clear MUST + treat the RRSIG, DNSKEY, and NSEC RRs as it would any other RRset and + MUST NOT perform any of the additional processing described below. + Because the DS RR type has the peculiar property of only existing in + the parent zone at delegation points, DS RRs always require some + special processing, as described in Section 3.1.4.1. + + Security aware name servers that receive explicit queries for + security RR types that match the content of more than one zone that + it serves (for example, NSEC and RRSIG RRs above and below a + delegation point where the server is authoritative for both zones) + should behave self-consistently. As long as the response is always + consistent for each query to the name server, the name server MAY + return one of the following: + + o The above-delegation RRsets. + o The below-delegation RRsets. + o Both above and below-delegation RRsets. + o Empty answer section (no records). + o Some other response. + o An error. + + DNSSEC allocates two new bits in the DNS message header: the CD + (Checking Disabled) bit and the AD (Authentic Data) bit. The CD bit + is controlled by resolvers; a security-aware name server MUST copy + the CD bit from a query into the corresponding response. The AD bit + is controlled by name servers; a security-aware name server MUST + ignore the setting of the AD bit in queries. See Sections 3.1.6, + 3.2.2, 3.2.3, 4, and 4.9 for details on the behavior of these bits. + + A security aware name server that synthesizes CNAME RRs from DNAME + RRs as described in [RFC2672] SHOULD NOT generate signatures for the + synthesized CNAME RRs. + +3.1. Authoritative Name Servers + + Upon receiving a relevant query that has the EDNS ([RFC2671]) OPT + pseudo-RR DO bit ([RFC3225]) set, a security-aware authoritative name + server for a signed zone MUST include additional RRSIG, NSEC, and DS + RRs, according to the following rules: + + o RRSIG RRs that can be used to authenticate a response MUST be + included in the response according to the rules in Section 3.1.1. + + + + + + + +Arends, et al. Standards Track [Page 9] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + + o NSEC RRs that can be used to provide authenticated denial of + existence MUST be included in the response automatically according + to the rules in Section 3.1.3. + + o Either a DS RRset or an NSEC RR proving that no DS RRs exist MUST + be included in referrals automatically according to the rules in + Section 3.1.4. + + These rules only apply to responses where the semantics convey + information about the presence or absence of resource records. That + is, these rules are not intended to rule out responses such as RCODE + 4 ("Not Implemented") or RCODE 5 ("Refused"). + + DNSSEC does not change the DNS zone transfer protocol. Section 3.1.5 + discusses zone transfer requirements. + +3.1.1. Including RRSIG RRs in a Response + + When responding to a query that has the DO bit set, a security-aware + authoritative name server SHOULD attempt to send RRSIG RRs that a + security-aware resolver can use to authenticate the RRsets in the + response. A name server SHOULD make every attempt to keep the RRset + and its associated RRSIG(s) together in a response. Inclusion of + RRSIG RRs in a response is subject to the following rules: + + o When placing a signed RRset in the Answer section, the name server + MUST also place its RRSIG RRs in the Answer section. The RRSIG + RRs have a higher priority for inclusion than any other RRsets + that may have to be included. If space does not permit inclusion + of these RRSIG RRs, the name server MUST set the TC bit. + + o When placing a signed RRset in the Authority section, the name + server MUST also place its RRSIG RRs in the Authority section. + The RRSIG RRs have a higher priority for inclusion than any other + RRsets that may have to be included. If space does not permit + inclusion of these RRSIG RRs, the name server MUST set the TC bit. + + o When placing a signed RRset in the Additional section, the name + server MUST also place its RRSIG RRs in the Additional section. + If space does not permit inclusion of both the RRset and its + associated RRSIG RRs, the name server MAY retain the RRset while + dropping the RRSIG RRs. If this happens, the name server MUST NOT + set the TC bit solely because these RRSIG RRs didn't fit. + + + + + + + + +Arends, et al. Standards Track [Page 10] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + +3.1.2. Including DNSKEY RRs in a Response + + When responding to a query that has the DO bit set and that requests + the SOA or NS RRs at the apex of a signed zone, a security-aware + authoritative name server for that zone MAY return the zone apex + DNSKEY RRset in the Additional section. In this situation, the + DNSKEY RRset and associated RRSIG RRs have lower priority than does + any other information that would be placed in the additional section. + The name server SHOULD NOT include the DNSKEY RRset unless there is + enough space in the response message for both the DNSKEY RRset and + its associated RRSIG RR(s). If there is not enough space to include + these DNSKEY and RRSIG RRs, the name server MUST omit them and MUST + NOT set the TC bit solely because these RRs didn't fit (see Section + 3.1.1). + +3.1.3. Including NSEC RRs in a Response + + When responding to a query that has the DO bit set, a security-aware + authoritative name server for a signed zone MUST include NSEC RRs in + each of the following cases: + + No Data: The zone contains RRsets that exactly match + but does not contain any RRsets that exactly match . + + Name Error: The zone does not contain any RRsets that match either exactly or via wildcard name expansion. + + Wildcard Answer: The zone does not contain any RRsets that exactly + match but does contain an RRset that matches + via wildcard name expansion. + + Wildcard No Data: The zone does not contain any RRsets that exactly + match and does contain one or more RRsets that + match via wildcard name expansion, but does not + contain any RRsets that match via wildcard + name expansion. + + In each of these cases, the name server includes NSEC RRs in the + response to prove that an exact match for was + not present in the zone and that the response that the name server is + returning is correct given the data in the zone. + + + + + + + + + +Arends, et al. Standards Track [Page 11] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + +3.1.3.1. Including NSEC RRs: No Data Response + + If the zone contains RRsets matching but contains no + RRset matching , then the name server MUST + include the NSEC RR for along with its associated + RRSIG RR(s) in the Authority section of the response (see Section + 3.1.1). If space does not permit inclusion of the NSEC RR or its + associated RRSIG RR(s), the name server MUST set the TC bit (see + Section 3.1.1). + + Since the search name exists, wildcard name expansion does not apply + to this query, and a single signed NSEC RR suffices to prove that the + requested RR type does not exist. + +3.1.3.2. Including NSEC RRs: Name Error Response + + If the zone does not contain any RRsets matching + either exactly or via wildcard name expansion, then the name server + MUST include the following NSEC RRs in the Authority section, along + with their associated RRSIG RRs: + + o An NSEC RR proving that there is no exact match for . + + o An NSEC RR proving that the zone contains no RRsets that would + match via wildcard name expansion. + + In some cases, a single NSEC RR may prove both of these points. If + it does, the name server SHOULD only include the NSEC RR and its + RRSIG RR(s) once in the Authority section. + + If space does not permit inclusion of these NSEC and RRSIG RRs, the + name server MUST set the TC bit (see Section 3.1.1). + + The owner names of these NSEC and RRSIG RRs are not subject to + wildcard name expansion when these RRs are included in the Authority + section of the response. + + Note that this form of response includes cases in which SNAME + corresponds to an empty non-terminal name within the zone (a name + that is not the owner name for any RRset but that is the parent name + of one or more RRsets). + +3.1.3.3. Including NSEC RRs: Wildcard Answer Response + + If the zone does not contain any RRsets that exactly match but does contain an RRset that matches + via wildcard name expansion, the name server MUST include the + + + +Arends, et al. Standards Track [Page 12] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + + wildcard-expanded answer and the corresponding wildcard-expanded + RRSIG RRs in the Answer section and MUST include in the Authority + section an NSEC RR and associated RRSIG RR(s) proving that the zone + does not contain a closer match for . If space does + not permit inclusion of the answer, NSEC and RRSIG RRs, the name + server MUST set the TC bit (see Section 3.1.1). + +3.1.3.4. Including NSEC RRs: Wildcard No Data Response + + This case is a combination of the previous cases. The zone does not + contain an exact match for , and although the zone + does contain RRsets that match via wildcard + expansion, none of those RRsets matches STYPE. The name server MUST + include the following NSEC RRs in the Authority section, along with + their associated RRSIG RRs: + + o An NSEC RR proving that there are no RRsets matching STYPE at the + wildcard owner name that matched via wildcard + expansion. + + o An NSEC RR proving that there are no RRsets in the zone that would + have been a closer match for . + + In some cases, a single NSEC RR may prove both of these points. If + it does, the name server SHOULD only include the NSEC RR and its + RRSIG RR(s) once in the Authority section. + + The owner names of these NSEC and RRSIG RRs are not subject to + wildcard name expansion when these RRs are included in the Authority + section of the response. + + If space does not permit inclusion of these NSEC and RRSIG RRs, the + name server MUST set the TC bit (see Section 3.1.1). + +3.1.3.5. Finding the Right NSEC RRs + + As explained above, there are several situations in which a + security-aware authoritative name server has to locate an NSEC RR + that proves that no RRsets matching a particular SNAME exist. + Locating such an NSEC RR within an authoritative zone is relatively + simple, at least in concept. The following discussion assumes that + the name server is authoritative for the zone that would have held + the non-existent RRsets matching SNAME. The algorithm below is + written for clarity, not for efficiency. + + To find the NSEC that proves that no RRsets matching name N exist in + the zone Z that would have held them, construct a sequence, S, + consisting of the owner names of every RRset in Z, sorted into + + + +Arends, et al. Standards Track [Page 13] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + + canonical order ([RFC4034]), with no duplicate names. Find the name + M that would have immediately preceded N in S if any RRsets with + owner name N had existed. M is the owner name of the NSEC RR that + proves that no RRsets exist with owner name N. + + The algorithm for finding the NSEC RR that proves that a given name + is not covered by any applicable wildcard is similar but requires an + extra step. More precisely, the algorithm for finding the NSEC + proving that no RRsets exist with the applicable wildcard name is + precisely the same as the algorithm for finding the NSEC RR that + proves that RRsets with any other owner name do not exist. The part + that's missing is a method of determining the name of the non- + existent applicable wildcard. In practice, this is easy, because the + authoritative name server has already checked for the presence of + precisely this wildcard name as part of step (1)(c) of the normal + lookup algorithm described in Section 4.3.2 of [RFC1034]. + +3.1.4. Including DS RRs in a Response + + When responding to a query that has the DO bit set, a security-aware + authoritative name server returning a referral includes DNSSEC data + along with the NS RRset. + + If a DS RRset is present at the delegation point, the name server + MUST return both the DS RRset and its associated RRSIG RR(s) in the + Authority section along with the NS RRset. + + If no DS RRset is present at the delegation point, the name server + MUST return both the NSEC RR that proves that the DS RRset is not + present and the NSEC RR's associated RRSIG RR(s) along with the NS + RRset. The name server MUST place the NS RRset before the NSEC RRset + and its associated RRSIG RR(s). + + Including these DS, NSEC, and RRSIG RRs increases the size of + referral messages and may cause some or all glue RRs to be omitted. + If space does not permit inclusion of the DS or NSEC RRset and + associated RRSIG RRs, the name server MUST set the TC bit (see + Section 3.1.1). + +3.1.4.1. Responding to Queries for DS RRs + + The DS resource record type is unusual in that it appears only on the + parent zone's side of a zone cut. For example, the DS RRset for the + delegation of "foo.example" is stored in the "example" zone rather + than in the "foo.example" zone. This requires special processing + rules for both name servers and resolvers, as the name server for the + child zone is authoritative for the name at the zone cut by the + normal DNS rules but the child zone does not contain the DS RRset. + + + +Arends, et al. Standards Track [Page 14] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + + A security-aware resolver sends queries to the parent zone when + looking for a needed DS RR at a delegation point (see Section 4.2). + However, special rules are necessary to avoid confusing + security-oblivious resolvers which might become involved in + processing such a query (for example, in a network configuration that + forces a security-aware resolver to channel its queries through a + security-oblivious recursive name server). The rest of this section + describes how a security-aware name server processes DS queries in + order to avoid this problem. + + The need for special processing by a security-aware name server only + arises when all the following conditions are met: + + o The name server has received a query for the DS RRset at a zone + cut. + + o The name server is authoritative for the child zone. + + o The name server is not authoritative for the parent zone. + + o The name server does not offer recursion. + + In all other cases, the name server either has some way of obtaining + the DS RRset or could not have been expected to have the DS RRset + even by the pre-DNSSEC processing rules, so the name server can + return either the DS RRset or an error response according to the + normal processing rules. + + If all the above conditions are met, however, the name server is + authoritative for SNAME but cannot supply the requested RRset. In + this case, the name server MUST return an authoritative "no data" + response showing that the DS RRset does not exist in the child zone's + apex. See Appendix B.8 for an example of such a response. + +3.1.5. Responding to Queries for Type AXFR or IXFR + + DNSSEC does not change the DNS zone transfer process. A signed zone + will contain RRSIG, DNSKEY, NSEC, and DS resource records, but these + records have no special meaning with respect to a zone transfer + operation. + + An authoritative name server is not required to verify that a zone is + properly signed before sending or accepting a zone transfer. + However, an authoritative name server MAY choose to reject the entire + zone transfer if the zone fails to meet any of the signing + requirements described in Section 2. The primary objective of a zone + transfer is to ensure that all authoritative name servers have + identical copies of the zone. An authoritative name server that + + + +Arends, et al. Standards Track [Page 15] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + + chooses to perform its own zone validation MUST NOT selectively + reject some RRs and accept others. + + DS RRsets appear only on the parental side of a zone cut and are + authoritative data in the parent zone. As with any other + authoritative RRset, the DS RRset MUST be included in zone transfers + of the zone in which the RRset is authoritative data. In the case of + the DS RRset, this is the parent zone. + + NSEC RRs appear in both the parent and child zones at a zone cut and + are authoritative data in both the parent and child zones. The + parental and child NSEC RRs at a zone cut are never identical to each + other, as the NSEC RR in the child zone's apex will always indicate + the presence of the child zone's SOA RR whereas the parental NSEC RR + at the zone cut will never indicate the presence of an SOA RR. As + with any other authoritative RRs, NSEC RRs MUST be included in zone + transfers of the zone in which they are authoritative data. The + parental NSEC RR at a zone cut MUST be included in zone transfers of + the parent zone, and the NSEC at the zone apex of the child zone MUST + be included in zone transfers of the child zone. + + RRSIG RRs appear in both the parent and child zones at a zone cut and + are authoritative in whichever zone contains the authoritative RRset + for which the RRSIG RR provides the signature. That is, the RRSIG RR + for a DS RRset or a parental NSEC RR at a zone cut will be + authoritative in the parent zone, and the RRSIG for any RRset in the + child zone's apex will be authoritative in the child zone. Parental + and child RRSIG RRs at a zone cut will never be identical to each + other, as the Signer's Name field of an RRSIG RR in the child zone's + apex will indicate a DNSKEY RR in the child zone's apex whereas the + same field of a parental RRSIG RR at the zone cut will indicate a + DNSKEY RR in the parent zone's apex. As with any other authoritative + RRs, RRSIG RRs MUST be included in zone transfers of the zone in + which they are authoritative data. + +3.1.6. The AD and CD Bits in an Authoritative Response + + The CD and AD bits are designed for use in communication between + security-aware resolvers and security-aware recursive name servers. + These bits are for the most part not relevant to query processing by + security-aware authoritative name servers. + + A security-aware name server does not perform signature validation + for authoritative data during query processing, even when the CD bit + is clear. A security-aware name server SHOULD clear the CD bit when + composing an authoritative response. + + + + + +Arends, et al. Standards Track [Page 16] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + + A security-aware name server MUST NOT set the AD bit in a response + unless the name server considers all RRsets in the Answer and + Authority sections of the response to be authentic. A security-aware + name server's local policy MAY consider data from an authoritative + zone to be authentic without further validation. However, the name + server MUST NOT do so unless the name server obtained the + authoritative zone via secure means (such as a secure zone transfer + mechanism) and MUST NOT do so unless this behavior has been + configured explicitly. + + A security-aware name server that supports recursion MUST follow the + rules for the CD and AD bits given in Section 3.2 when generating a + response that involves data obtained via recursion. + +3.2. Recursive Name Servers + + As explained in [RFC4033], a security-aware recursive name server is + an entity that acts in both the security-aware name server and + security-aware resolver roles. This section uses the terms "name + server side" and "resolver side" to refer to the code within a + security-aware recursive name server that implements the + security-aware name server role and the code that implements the + security-aware resolver role, respectively. + + The resolver side follows the usual rules for caching and negative + caching that would apply to any security-aware resolver. + +3.2.1. The DO Bit + + The resolver side of a security-aware recursive name server MUST set + the DO bit when sending requests, regardless of the state of the DO + bit in the initiating request received by the name server side. If + the DO bit in an initiating query is not set, the name server side + MUST strip any authenticating DNSSEC RRs from the response but MUST + NOT strip any DNSSEC RR types that the initiating query explicitly + requested. + +3.2.2. The CD Bit + + The CD bit exists in order to allow a security-aware resolver to + disable signature validation in a security-aware name server's + processing of a particular query. + + The name server side MUST copy the setting of the CD bit from a query + to the corresponding response. + + The name server side of a security-aware recursive name server MUST + pass the state of the CD bit to the resolver side along with the rest + + + +Arends, et al. Standards Track [Page 17] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + + of an initiating query, so that the resolver side will know whether + it is required to verify the response data it returns to the name + server side. If the CD bit is set, it indicates that the originating + resolver is willing to perform whatever authentication its local + policy requires. Thus, the resolver side of the recursive name + server need not perform authentication on the RRsets in the response. + When the CD bit is set, the recursive name server SHOULD, if + possible, return the requested data to the originating resolver, even + if the recursive name server's local authentication policy would + reject the records in question. That is, by setting the CD bit, the + originating resolver has indicated that it takes responsibility for + performing its own authentication, and the recursive name server + should not interfere. + + If the resolver side implements a BAD cache (see Section 4.7) and the + name server side receives a query that matches an entry in the + resolver side's BAD cache, the name server side's response depends on + the state of the CD bit in the original query. If the CD bit is set, + the name server side SHOULD return the data from the BAD cache; if + the CD bit is not set, the name server side MUST return RCODE 2 + (server failure). + + The intent of the above rule is to provide the raw data to clients + that are capable of performing their own signature verification + checks while protecting clients that depend on the resolver side of a + security-aware recursive name server to perform such checks. Several + of the possible reasons why signature validation might fail involve + conditions that may not apply equally to the recursive name server + and the client that invoked it. For example, the recursive name + server's clock may be set incorrectly, or the client may have + knowledge of a relevant island of security that the recursive name + server does not share. In such cases, "protecting" a client that is + capable of performing its own signature validation from ever seeing + the "bad" data does not help the client. + +3.2.3. The AD Bit + + The name server side of a security-aware recursive name server MUST + NOT set the AD bit in a response unless the name server considers all + RRsets in the Answer and Authority sections of the response to be + authentic. The name server side SHOULD set the AD bit if and only if + the resolver side considers all RRsets in the Answer section and any + relevant negative response RRs in the Authority section to be + authentic. The resolver side MUST follow the procedure described in + Section 5 to determine whether the RRs in question are authentic. + However, for backward compatibility, a recursive name server MAY set + the AD bit when a response includes unsigned CNAME RRs if those CNAME + + + + +Arends, et al. Standards Track [Page 18] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + + RRs demonstrably could have been synthesized from an authentic DNAME + RR that is also included in the response according to the synthesis + rules described in [RFC2672]. + +3.3. Example DNSSEC Responses + + See Appendix B for example response packets. + +4. Resolving + + This section describes the behavior of entities that include + security-aware resolver functions. In many cases such functions will + be part of a security-aware recursive name server, but a stand-alone + security-aware resolver has many of the same requirements. Functions + specific to security-aware recursive name servers are described in + Section 3.2. + +4.1. EDNS Support + + A security-aware resolver MUST include an EDNS ([RFC2671]) OPT + pseudo-RR with the DO ([RFC3225]) bit set when sending queries. + + A security-aware resolver MUST support a message size of at least + 1220 octets, SHOULD support a message size of 4000 octets, and MUST + use the "sender's UDP payload size" field in the EDNS OPT pseudo-RR + to advertise the message size that it is willing to accept. A + security-aware resolver's IP layer MUST handle fragmented UDP packets + correctly regardless of whether any such fragmented packets were + received via IPv4 or IPv6. Please see [RFC1122], [RFC2460], and + [RFC3226] for discussion of these requirements. + +4.2. Signature Verification Support + + A security-aware resolver MUST support the signature verification + mechanisms described in Section 5 and SHOULD apply them to every + received response, except when: + + o the security-aware resolver is part of a security-aware recursive + name server, and the response is the result of recursion on behalf + of a query received with the CD bit set; + + o the response is the result of a query generated directly via some + form of application interface that instructed the security-aware + resolver not to perform validation for this query; or + + o validation for this query has been disabled by local policy. + + + + + +Arends, et al. Standards Track [Page 19] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + + A security-aware resolver's support for signature verification MUST + include support for verification of wildcard owner names. + + Security-aware resolvers MAY query for missing security RRs in an + attempt to perform validation; implementations that choose to do so + must be aware that the answers received may not be sufficient to + validate the original response. For example, a zone update may have + changed (or deleted) the desired information between the original and + follow-up queries. + + When attempting to retrieve missing NSEC RRs that reside on the + parental side at a zone cut, a security-aware iterative-mode resolver + MUST query the name servers for the parent zone, not the child zone. + + When attempting to retrieve a missing DS, a security-aware + iterative-mode resolver MUST query the name servers for the parent + zone, not the child zone. As explained in Section 3.1.4.1, + security-aware name servers need to apply special processing rules to + handle the DS RR, and in some situations the resolver may also need + to apply special rules to locate the name servers for the parent zone + if the resolver does not already have the parent's NS RRset. To + locate the parent NS RRset, the resolver can start with the + delegation name, strip off the leftmost label, and query for an NS + RRset by that name. If no NS RRset is present at that name, the + resolver then strips off the leftmost remaining label and retries the + query for that name, repeating this process of walking up the tree + until it either finds the NS RRset or runs out of labels. + +4.3. Determining Security Status of Data + + A security-aware resolver MUST be able to determine whether it should + expect a particular RRset to be signed. More precisely, a + security-aware resolver must be able to distinguish between four + cases: + + Secure: An RRset for which the resolver is able to build a chain of + signed DNSKEY and DS RRs from a trusted security anchor to the + RRset. In this case, the RRset should be signed and is subject to + signature validation, as described above. + + Insecure: An RRset for which the resolver knows that it has no chain + of signed DNSKEY and DS RRs from any trusted starting point to the + RRset. This can occur when the target RRset lies in an unsigned + zone or in a descendent of an unsigned zone. In this case, the + RRset may or may not be signed, but the resolver will not be able + to verify the signature. + + + + + +Arends, et al. Standards Track [Page 20] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + + Bogus: An RRset for which the resolver believes that it ought to be + able to establish a chain of trust but for which it is unable to + do so, either due to signatures that for some reason fail to + validate or due to missing data that the relevant DNSSEC RRs + indicate should be present. This case may indicate an attack but + may also indicate a configuration error or some form of data + corruption. + + Indeterminate: An RRset for which the resolver is not able to + determine whether the RRset should be signed, as the resolver is + not able to obtain the necessary DNSSEC RRs. This can occur when + the security-aware resolver is not able to contact security-aware + name servers for the relevant zones. + +4.4. Configured Trust Anchors + + A security-aware resolver MUST be capable of being configured with at + least one trusted public key or DS RR and SHOULD be capable of being + configured with multiple trusted public keys or DS RRs. Since a + security-aware resolver will not be able to validate signatures + without such a configured trust anchor, the resolver SHOULD have some + reasonably robust mechanism for obtaining such keys when it boots; + examples of such a mechanism would be some form of non-volatile + storage (such as a disk drive) or some form of trusted local network + configuration mechanism. + + Note that trust anchors also cover key material that is updated in a + secure manner. This secure manner could be through physical media, a + key exchange protocol, or some other out-of-band means. + +4.5. Response Caching + + A security-aware resolver SHOULD cache each response as a single + atomic entry containing the entire answer, including the named RRset + and any associated DNSSEC RRs. The resolver SHOULD discard the + entire atomic entry when any of the RRs contained in it expire. In + most cases the appropriate cache index for the atomic entry will be + the triple , but in cases such as the response + form described in Section 3.1.3.2 the appropriate cache index will be + the double . + + The reason for these recommendations is that, between the initial + query and the expiration of the data from the cache, the + authoritative data might have been changed (for example, via dynamic + update). + + + + + + +Arends, et al. Standards Track [Page 21] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + + There are two situations for which this is relevant: + + 1. By using the RRSIG record, it is possible to deduce that an + answer was synthesized from a wildcard. A security-aware + recursive name server could store this wildcard data and use it + to generate positive responses to queries other than the name for + which the original answer was first received. + + 2. NSEC RRs received to prove the non-existence of a name could be + reused by a security-aware resolver to prove the non-existence of + any name in the name range it spans. + + In theory, a resolver could use wildcards or NSEC RRs to generate + positive and negative responses (respectively) until the TTL or + signatures on the records in question expire. However, it seems + prudent for resolvers to avoid blocking new authoritative data or + synthesizing new data on their own. Resolvers that follow this + recommendation will have a more consistent view of the namespace. + +4.6. Handling of the CD and AD Bits + + A security-aware resolver MAY set a query's CD bit in order to + indicate that the resolver takes responsibility for performing + whatever authentication its local policy requires on the RRsets in + the response. See Section 3.2 for the effect this bit has on the + behavior of security-aware recursive name servers. + + A security-aware resolver MUST clear the AD bit when composing query + messages to protect against buggy name servers that blindly copy + header bits that they do not understand from the query message to the + response message. + + A resolver MUST disregard the meaning of the CD and AD bits in a + response unless the response was obtained by using a secure channel + or the resolver was specifically configured to regard the message + header bits without using a secure channel. + +4.7. Caching BAD Data + + While many validation errors will be transient, some are likely to be + more persistent, such as those caused by administrative error + (failure to re-sign a zone, clock skew, and so forth). Since + requerying will not help in these cases, validating resolvers might + generate a significant amount of unnecessary DNS traffic as a result + of repeated queries for RRsets with persistent validation failures. + + To prevent such unnecessary DNS traffic, security-aware resolvers MAY + cache data with invalid signatures, with some restrictions. + + + +Arends, et al. Standards Track [Page 22] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + + Conceptually, caching such data is similar to negative caching + ([RFC2308]), except that instead of caching a valid negative + response, the resolver is caching the fact that a particular answer + failed to validate. This document refers to a cache of data with + invalid signatures as a "BAD cache". + + Resolvers that implement a BAD cache MUST take steps to prevent the + cache from being useful as a denial-of-service attack amplifier, + particularly the following: + + o Since RRsets that fail to validate do not have trustworthy TTLs, + the implementation MUST assign a TTL. This TTL SHOULD be small, + in order to mitigate the effect of caching the results of an + attack. + + o In order to prevent caching of a transient validation failure + (which might be the result of an attack), resolvers SHOULD track + queries that result in validation failures and SHOULD only answer + from the BAD cache after the number of times that responses to + queries for that particular have failed to + validate exceeds a threshold value. + + Resolvers MUST NOT return RRsets from the BAD cache unless the + resolver is not required to validate the signatures of the RRsets in + question under the rules given in Section 4.2 of this document. See + Section 3.2.2 for discussion of how the responses returned by a + security-aware recursive name server interact with a BAD cache. + +4.8. Synthesized CNAMEs + + A validating security-aware resolver MUST treat the signature of a + valid signed DNAME RR as also covering unsigned CNAME RRs that could + have been synthesized from the DNAME RR, as described in [RFC2672], + at least to the extent of not rejecting a response message solely + because it contains such CNAME RRs. The resolver MAY retain such + CNAME RRs in its cache or in the answers it hands back, but is not + required to do so. + +4.9. Stub Resolvers + + A security-aware stub resolver MUST support the DNSSEC RR types, at + least to the extent of not mishandling responses just because they + contain DNSSEC RRs. + + + + + + + + +Arends, et al. Standards Track [Page 23] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + +4.9.1. Handling of the DO Bit + + A non-validating security-aware stub resolver MAY include the DNSSEC + RRs returned by a security-aware recursive name server as part of the + data that the stub resolver hands back to the application that + invoked it, but is not required to do so. A non-validating stub + resolver that seeks to do this will need to set the DO bit in order + to receive DNSSEC RRs from the recursive name server. + + A validating security-aware stub resolver MUST set the DO bit, + because otherwise it will not receive the DNSSEC RRs it needs to + perform signature validation. + +4.9.2. Handling of the CD Bit + + A non-validating security-aware stub resolver SHOULD NOT set the CD + bit when sending queries unless it is requested by the application + layer, as by definition, a non-validating stub resolver depends on + the security-aware recursive name server to perform validation on its + behalf. + + A validating security-aware stub resolver SHOULD set the CD bit, + because otherwise the security-aware recursive name server will + answer the query using the name server's local policy, which may + prevent the stub resolver from receiving data that would be + acceptable to the stub resolver's local policy. + +4.9.3. Handling of the AD Bit + + A non-validating security-aware stub resolver MAY chose to examine + the setting of the AD bit in response messages that it receives in + order to determine whether the security-aware recursive name server + that sent the response claims to have cryptographically verified the + data in the Answer and Authority sections of the response message. + Note, however, that the responses received by a security-aware stub + resolver are heavily dependent on the local policy of the + security-aware recursive name server. Therefore, there may be little + practical value in checking the status of the AD bit, except perhaps + as a debugging aid. In any case, a security-aware stub resolver MUST + NOT place any reliance on signature validation allegedly performed on + its behalf, except when the security-aware stub resolver obtained the + data in question from a trusted security-aware recursive name server + via a secure channel. + + A validating security-aware stub resolver SHOULD NOT examine the + setting of the AD bit in response messages, as, by definition, the + stub resolver performs its own signature validation regardless of the + setting of the AD bit. + + + +Arends, et al. Standards Track [Page 24] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + +5. Authenticating DNS Responses + + To use DNSSEC RRs for authentication, a security-aware resolver + requires configured knowledge of at least one authenticated DNSKEY or + DS RR. The process for obtaining and authenticating this initial + trust anchor is achieved via some external mechanism. For example, a + resolver could use some off-line authenticated exchange to obtain a + zone's DNSKEY RR or to obtain a DS RR that identifies and + authenticates a zone's DNSKEY RR. The remainder of this section + assumes that the resolver has somehow obtained an initial set of + trust anchors. + + An initial DNSKEY RR can be used to authenticate a zone's apex DNSKEY + RRset. To authenticate an apex DNSKEY RRset by using an initial key, + the resolver MUST: + + 1. verify that the initial DNSKEY RR appears in the apex DNSKEY + RRset, and that the DNSKEY RR has the Zone Key Flag (DNSKEY RDATA + bit 7) set; and + + 2. verify that there is some RRSIG RR that covers the apex DNSKEY + RRset, and that the combination of the RRSIG RR and the initial + DNSKEY RR authenticates the DNSKEY RRset. The process for using + an RRSIG RR to authenticate an RRset is described in Section 5.3. + + Once the resolver has authenticated the apex DNSKEY RRset by using an + initial DNSKEY RR, delegations from that zone can be authenticated by + using DS RRs. This allows a resolver to start from an initial key + and use DS RRsets to proceed recursively down the DNS tree, obtaining + other apex DNSKEY RRsets. If the resolver were configured with a + root DNSKEY RR, and if every delegation had a DS RR associated with + it, then the resolver could obtain and validate any apex DNSKEY + RRset. The process of using DS RRs to authenticate referrals is + described in Section 5.2. + + Section 5.3 shows how the resolver can use DNSKEY RRs in the apex + DNSKEY RRset and RRSIG RRs from the zone to authenticate any other + RRsets in the zone once the resolver has authenticated a zone's apex + DNSKEY RRset. Section 5.4 shows how the resolver can use + authenticated NSEC RRsets from the zone to prove that an RRset is not + present in the zone. + + When a resolver indicates support for DNSSEC (by setting the DO bit), + a security-aware name server should attempt to provide the necessary + DNSKEY, RRSIG, NSEC, and DS RRsets in a response (see Section 3). + However, a security-aware resolver may still receive a response that + lacks the appropriate DNSSEC RRs, whether due to configuration issues + such as an upstream security-oblivious recursive name server that + + + +Arends, et al. Standards Track [Page 25] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + + accidentally interferes with DNSSEC RRs or due to a deliberate attack + in which an adversary forges a response, strips DNSSEC RRs from a + response, or modifies a query so that DNSSEC RRs appear not to be + requested. The absence of DNSSEC data in a response MUST NOT by + itself be taken as an indication that no authentication information + exists. + + A resolver SHOULD expect authentication information from signed + zones. A resolver SHOULD believe that a zone is signed if the + resolver has been configured with public key information for the + zone, or if the zone's parent is signed and the delegation from the + parent contains a DS RRset. + +5.1. Special Considerations for Islands of Security + + Islands of security (see [RFC4033]) are signed zones for which it is + not possible to construct an authentication chain to the zone from + its parent. Validating signatures within an island of security + requires that the validator have some other means of obtaining an + initial authenticated zone key for the island. If a validator cannot + obtain such a key, it SHOULD switch to operating as if the zones in + the island of security are unsigned. + + All the normal processes for validating responses apply to islands of + security. The only difference between normal validation and + validation within an island of security is in how the validator + obtains a trust anchor for the authentication chain. + +5.2. Authenticating Referrals + + Once the apex DNSKEY RRset for a signed parent zone has been + authenticated, DS RRsets can be used to authenticate the delegation + to a signed child zone. A DS RR identifies a DNSKEY RR in the child + zone's apex DNSKEY RRset and contains a cryptographic digest of the + child zone's DNSKEY RR. Use of a strong cryptographic digest + algorithm ensures that it is computationally infeasible for an + adversary to generate a DNSKEY RR that matches the digest. Thus, + authenticating the digest allows a resolver to authenticate the + matching DNSKEY RR. The resolver can then use this child DNSKEY RR + to authenticate the entire child apex DNSKEY RRset. + + Given a DS RR for a delegation, the child zone's apex DNSKEY RRset + can be authenticated if all of the following hold: + + o The DS RR has been authenticated using some DNSKEY RR in the + parent's apex DNSKEY RRset (see Section 5.3). + + + + + +Arends, et al. Standards Track [Page 26] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + + o The Algorithm and Key Tag in the DS RR match the Algorithm field + and the key tag of a DNSKEY RR in the child zone's apex DNSKEY + RRset, and, when the DNSKEY RR's owner name and RDATA are hashed + using the digest algorithm specified in the DS RR's Digest Type + field, the resulting digest value matches the Digest field of the + DS RR. + + o The matching DNSKEY RR in the child zone has the Zone Flag bit + set, the corresponding private key has signed the child zone's + apex DNSKEY RRset, and the resulting RRSIG RR authenticates the + child zone's apex DNSKEY RRset. + + If the referral from the parent zone did not contain a DS RRset, the + response should have included a signed NSEC RRset proving that no DS + RRset exists for the delegated name (see Section 3.1.4). A + security-aware resolver MUST query the name servers for the parent + zone for the DS RRset if the referral includes neither a DS RRset nor + a NSEC RRset proving that the DS RRset does not exist (see Section + 4). + + If the validator authenticates an NSEC RRset that proves that no DS + RRset is present for this zone, then there is no authentication path + leading from the parent to the child. If the resolver has an initial + DNSKEY or DS RR that belongs to the child zone or to any delegation + below the child zone, this initial DNSKEY or DS RR MAY be used to + re-establish an authentication path. If no such initial DNSKEY or DS + RR exists, the validator cannot authenticate RRsets in or below the + child zone. + + If the validator does not support any of the algorithms listed in an + authenticated DS RRset, then the resolver has no supported + authentication path leading from the parent to the child. The + resolver should treat this case as it would the case of an + authenticated NSEC RRset proving that no DS RRset exists, as + described above. + + Note that, for a signed delegation, there are two NSEC RRs associated + with the delegated name. One NSEC RR resides in the parent zone and + can be used to prove whether a DS RRset exists for the delegated + name. The second NSEC RR resides in the child zone and identifies + which RRsets are present at the apex of the child zone. The parent + NSEC RR and child NSEC RR can always be distinguished because the SOA + bit will be set in the child NSEC RR and clear in the parent NSEC RR. + A security-aware resolver MUST use the parent NSEC RR when attempting + to prove that a DS RRset does not exist. + + + + + + +Arends, et al. Standards Track [Page 27] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + + If the resolver does not support any of the algorithms listed in an + authenticated DS RRset, then the resolver will not be able to verify + the authentication path to the child zone. In this case, the + resolver SHOULD treat the child zone as if it were unsigned. + +5.3. Authenticating an RRset with an RRSIG RR + + A validator can use an RRSIG RR and its corresponding DNSKEY RR to + attempt to authenticate RRsets. The validator first checks the RRSIG + RR to verify that it covers the RRset, has a valid time interval, and + identifies a valid DNSKEY RR. The validator then constructs the + canonical form of the signed data by appending the RRSIG RDATA + (excluding the Signature Field) with the canonical form of the + covered RRset. Finally, the validator uses the public key and + signature to authenticate the signed data. Sections 5.3.1, 5.3.2, + and 5.3.3 describe each step in detail. + +5.3.1. Checking the RRSIG RR Validity + + A security-aware resolver can use an RRSIG RR to authenticate an + RRset if all of the following conditions hold: + + o The RRSIG RR and the RRset MUST have the same owner name and the + same class. + + o The RRSIG RR's Signer's Name field MUST be the name of the zone + that contains the RRset. + + o The RRSIG RR's Type Covered field MUST equal the RRset's type. + + o The number of labels in the RRset owner name MUST be greater than + or equal to the value in the RRSIG RR's Labels field. + + o The validator's notion of the current time MUST be less than or + equal to the time listed in the RRSIG RR's Expiration field. + + o The validator's notion of the current time MUST be greater than or + equal to the time listed in the RRSIG RR's Inception field. + + o The RRSIG RR's Signer's Name, Algorithm, and Key Tag fields MUST + match the owner name, algorithm, and key tag for some DNSKEY RR in + the zone's apex DNSKEY RRset. + + o The matching DNSKEY RR MUST be present in the zone's apex DNSKEY + RRset, and MUST have the Zone Flag bit (DNSKEY RDATA Flag bit 7) + set. + + + + + +Arends, et al. Standards Track [Page 28] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + + It is possible for more than one DNSKEY RR to match the conditions + above. In this case, the validator cannot predetermine which DNSKEY + RR to use to authenticate the signature, and it MUST try each + matching DNSKEY RR until either the signature is validated or the + validator has run out of matching public keys to try. + + Note that this authentication process is only meaningful if the + validator authenticates the DNSKEY RR before using it to validate + signatures. The matching DNSKEY RR is considered to be authentic if: + + o the apex DNSKEY RRset containing the DNSKEY RR is considered + authentic; or + + o the RRset covered by the RRSIG RR is the apex DNSKEY RRset itself, + and the DNSKEY RR either matches an authenticated DS RR from the + parent zone or matches a trust anchor. + +5.3.2. Reconstructing the Signed Data + + Once the RRSIG RR has met the validity requirements described in + Section 5.3.1, the validator has to reconstruct the original signed + data. The original signed data includes RRSIG RDATA (excluding the + Signature field) and the canonical form of the RRset. Aside from + being ordered, the canonical form of the RRset might also differ from + the received RRset due to DNS name compression, decremented TTLs, or + wildcard expansion. The validator should use the following to + reconstruct the original signed data: + + signed_data = RRSIG_RDATA | RR(1) | RR(2)... where + + "|" denotes concatenation + + RRSIG_RDATA is the wire format of the RRSIG RDATA fields + with the Signature field excluded and the Signer's Name + in canonical form. + + RR(i) = name | type | class | OrigTTL | RDATA length | RDATA + + name is calculated according to the function below + + class is the RRset's class + + type is the RRset type and all RRs in the class + + OrigTTL is the value from the RRSIG Original TTL field + + All names in the RDATA field are in canonical form + + + + +Arends, et al. Standards Track [Page 29] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + + The set of all RR(i) is sorted into canonical order. + + To calculate the name: + let rrsig_labels = the value of the RRSIG Labels field + + let fqdn = RRset's fully qualified domain name in + canonical form + + let fqdn_labels = Label count of the fqdn above. + + if rrsig_labels = fqdn_labels, + name = fqdn + + if rrsig_labels < fqdn_labels, + name = "*." | the rightmost rrsig_label labels of the + fqdn + + if rrsig_labels > fqdn_labels + the RRSIG RR did not pass the necessary validation + checks and MUST NOT be used to authenticate this + RRset. + + The canonical forms for names and RRsets are defined in [RFC4034]. + + NSEC RRsets at a delegation boundary require special processing. + There are two distinct NSEC RRsets associated with a signed delegated + name. One NSEC RRset resides in the parent zone, and specifies which + RRsets are present at the parent zone. The second NSEC RRset resides + at the child zone and identifies which RRsets are present at the apex + in the child zone. The parent NSEC RRset and child NSEC RRset can + always be distinguished as only a child NSEC RR will indicate that an + SOA RRset exists at the name. When reconstructing the original NSEC + RRset for the delegation from the parent zone, the NSEC RRs MUST NOT + be combined with NSEC RRs from the child zone. When reconstructing + the original NSEC RRset for the apex of the child zone, the NSEC RRs + MUST NOT be combined with NSEC RRs from the parent zone. + + Note that each of the two NSEC RRsets at a delegation point has a + corresponding RRSIG RR with an owner name matching the delegated + name, and each of these RRSIG RRs is authoritative data associated + with the same zone that contains the corresponding NSEC RRset. If + necessary, a resolver can tell these RRSIG RRs apart by checking the + Signer's Name field. + + + + + + + + +Arends, et al. Standards Track [Page 30] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + +5.3.3. Checking the Signature + + Once the resolver has validated the RRSIG RR as described in Section + 5.3.1 and reconstructed the original signed data as described in + Section 5.3.2, the validator can attempt to use the cryptographic + signature to authenticate the signed data, and thus (finally!) + authenticate the RRset. + + The Algorithm field in the RRSIG RR identifies the cryptographic + algorithm used to generate the signature. The signature itself is + contained in the Signature field of the RRSIG RDATA, and the public + key used to verify the signature is contained in the Public Key field + of the matching DNSKEY RR(s) (found in Section 5.3.1). [RFC4034] + provides a list of algorithm types and provides pointers to the + documents that define each algorithm's use. + + Note that it is possible for more than one DNSKEY RR to match the + conditions in Section 5.3.1. In this case, the validator can only + determine which DNSKEY RR is correct by trying each matching public + key until the validator either succeeds in validating the signature + or runs out of keys to try. + + If the Labels field of the RRSIG RR is not equal to the number of + labels in the RRset's fully qualified owner name, then the RRset is + either invalid or the result of wildcard expansion. The resolver + MUST verify that wildcard expansion was applied properly before + considering the RRset to be authentic. Section 5.3.4 describes how + to determine whether a wildcard was applied properly. + + If other RRSIG RRs also cover this RRset, the local resolver security + policy determines whether the resolver also has to test these RRSIG + RRs and how to resolve conflicts if these RRSIG RRs lead to differing + results. + + If the resolver accepts the RRset as authentic, the validator MUST + set the TTL of the RRSIG RR and each RR in the authenticated RRset to + a value no greater than the minimum of: + + o the RRset's TTL as received in the response; + + o the RRSIG RR's TTL as received in the response; + + o the value in the RRSIG RR's Original TTL field; and + + o the difference of the RRSIG RR's Signature Expiration time and the + current time. + + + + + +Arends, et al. Standards Track [Page 31] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + +5.3.4. Authenticating a Wildcard Expanded RRset Positive Response + + If the number of labels in an RRset's owner name is greater than the + Labels field of the covering RRSIG RR, then the RRset and its + covering RRSIG RR were created as a result of wildcard expansion. + Once the validator has verified the signature, as described in + Section 5.3, it must take additional steps to verify the non- + existence of an exact match or closer wildcard match for the query. + Section 5.4 discusses these steps. + + Note that the response received by the resolver should include all + NSEC RRs needed to authenticate the response (see Section 3.1.3). + +5.4. Authenticated Denial of Existence + + A resolver can use authenticated NSEC RRs to prove that an RRset is + not present in a signed zone. Security-aware name servers should + automatically include any necessary NSEC RRs for signed zones in + their responses to security-aware resolvers. + + Denial of existence is determined by the following rules: + + o If the requested RR name matches the owner name of an + authenticated NSEC RR, then the NSEC RR's type bit map field lists + all RR types present at that owner name, and a resolver can prove + that the requested RR type does not exist by checking for the RR + type in the bit map. If the number of labels in an authenticated + NSEC RR's owner name equals the Labels field of the covering RRSIG + RR, then the existence of the NSEC RR proves that wildcard + expansion could not have been used to match the request. + + o If the requested RR name would appear after an authenticated NSEC + RR's owner name and before the name listed in that NSEC RR's Next + Domain Name field according to the canonical DNS name order + defined in [RFC4034], then no RRsets with the requested name exist + in the zone. However, it is possible that a wildcard could be + used to match the requested RR owner name and type, so proving + that the requested RRset does not exist also requires proving that + no possible wildcard RRset exists that could have been used to + generate a positive response. + + In addition, security-aware resolvers MUST authenticate the NSEC + RRsets that comprise the non-existence proof as described in Section + 5.3. + + To prove the non-existence of an RRset, the resolver must be able to + verify both that the queried RRset does not exist and that no + relevant wildcard RRset exists. Proving this may require more than + + + +Arends, et al. Standards Track [Page 32] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + + one NSEC RRset from the zone. If the complete set of necessary NSEC + RRsets is not present in a response (perhaps due to message + truncation), then a security-aware resolver MUST resend the query in + order to attempt to obtain the full collection of NSEC RRs necessary + to verify the non-existence of the requested RRset. As with all DNS + operations, however, the resolver MUST bound the work it puts into + answering any particular query. + + Since a validated NSEC RR proves the existence of both itself and its + corresponding RRSIG RR, a validator MUST ignore the settings of the + NSEC and RRSIG bits in an NSEC RR. + +5.5. Resolver Behavior When Signatures Do Not Validate + + If for whatever reason none of the RRSIGs can be validated, the + response SHOULD be considered BAD. If the validation was being done + to service a recursive query, the name server MUST return RCODE 2 to + the originating client. However, it MUST return the full response if + and only if the original query had the CD bit set. Also see Section + 4.7 on caching responses that do not validate. + +5.6. Authentication Example + + Appendix C shows an example of the authentication process. + +6. IANA Considerations + + [RFC4034] contains a review of the IANA considerations introduced by + DNSSEC. The following are additional IANA considerations discussed + in this document: + + [RFC2535] reserved the CD and AD bits in the message header. The + meaning of the AD bit was redefined in [RFC3655], and the meaning of + both the CD and AD bit are restated in this document. No new bits in + the DNS message header are defined in this document. + + [RFC2671] introduced EDNS, and [RFC3225] reserved the DNSSEC OK bit + and defined its use. The use is restated but not altered in this + document. + +7. Security Considerations + + This document describes how the DNS security extensions use public + key cryptography to sign and authenticate DNS resource record sets. + Please see [RFC4033] for terminology and general security + considerations related to DNSSEC; see [RFC4034] for considerations + specific to the DNSSEC resource record types. + + + + +Arends, et al. Standards Track [Page 33] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + + An active attacker who can set the CD bit in a DNS query message or + the AD bit in a DNS response message can use these bits to defeat the + protection that DNSSEC attempts to provide to security-oblivious + recursive-mode resolvers. For this reason, use of these control bits + by a security-aware recursive-mode resolver requires a secure + channel. See Sections 3.2.2 and 4.9 for further discussion. + + The protocol described in this document attempts to extend the + benefits of DNSSEC to security-oblivious stub resolvers. However, as + recovery from validation failures is likely to be specific to + particular applications, the facilities that DNSSEC provides for stub + resolvers may prove inadequate. Operators of security-aware + recursive name servers will have to pay close attention to the + behavior of the applications that use their services when choosing a + local validation policy; failure to do so could easily result in the + recursive name server accidentally denying service to the clients it + is intended to support. + +8. Acknowledgements + + This document was created from the input and ideas of the members of + the DNS Extensions Working Group and working group mailing list. The + editors would like to express their thanks for the comments and + suggestions received during the revision of these security extension + specifications. Although explicitly listing everyone who has + contributed during the decade in which DNSSEC has been under + development would be impossible, [RFC4033] includes a list of some of + the participants who were kind enough to comment on these documents. + +9. References + +9.1. Normative References + + [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", + STD 13, RFC 1034, November 1987. + + [RFC1035] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, November 1987. + + [RFC1122] Braden, R., "Requirements for Internet Hosts - + Communication Layers", STD 3, RFC 1122, October 1989. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS + Specification", RFC 2181, July 1997. + + + + +Arends, et al. Standards Track [Page 34] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + + [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 + (IPv6) Specification", RFC 2460, December 1998. + + [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC + 2671, August 1999. + + [RFC2672] Crawford, M., "Non-Terminal DNS Name Redirection", RFC + 2672, August 1999. + + [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC + 3225, December 2001. + + [RFC3226] Gudmundsson, O., "DNSSEC and IPv6 A6 aware server/resolver + message size requirements", RFC 3226, December 2001. + + [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. + Rose, "DNS Security Introduction and Requirements", RFC + 4033, March 2005. + + [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. + Rose, "Resource Records for DNS Security Extensions", RFC + 4034, March 2005. + +9.2. Informative References + + [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS + NCACHE)", RFC 2308, March 1998. + + [RFC2535] Eastlake 3rd, D., "Domain Name System Security + Extensions", RFC 2535, March 1999. + + [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic + Update", RFC 3007, November 2000. + + [RFC3655] Wellington, B. and O. Gudmundsson, "Redefinition of DNS + Authenticated Data (AD) bit", RFC 3655, November 2003. + + + + + + + + + + + + + + + +Arends, et al. Standards Track [Page 35] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + +Appendix A. Signed Zone Example + + The following example shows a (small) complete signed zone. + + example. 3600 IN SOA ns1.example. bugs.x.w.example. ( + 1081539377 + 3600 + 300 + 3600000 + 3600 + ) + 3600 RRSIG SOA 5 1 3600 20040509183619 ( + 20040409183619 38519 example. + ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h + 7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF + vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW + DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB + jV7j86HyQgM5e7+miRAz8V01b0I= ) + 3600 NS ns1.example. + 3600 NS ns2.example. + 3600 RRSIG NS 5 1 3600 20040509183619 ( + 20040409183619 38519 example. + gl13F00f2U0R+SWiXXLHwsMY+qStYy5k6zfd + EuivWc+wd1fmbNCyql0Tk7lHTX6UOxc8AgNf + 4ISFve8XqF4q+o9qlnqIzmppU3LiNeKT4FZ8 + RO5urFOvoMRTbQxW3U0hXWuggE4g3ZpsHv48 + 0HjMeRaZB/FRPGfJPajngcq6Kwg= ) + 3600 MX 1 xx.example. + 3600 RRSIG MX 5 1 3600 20040509183619 ( + 20040409183619 38519 example. + HyDHYVT5KHSZ7HtO/vypumPmSZQrcOP3tzWB + 2qaKkHVPfau/DgLgS/IKENkYOGL95G4N+NzE + VyNU8dcTOckT+ChPcGeVjguQ7a3Ao9Z/ZkUO + 6gmmUW4b89rz1PUxW4jzUxj66PTwoVtUU/iM + W6OISukd1EQt7a0kygkg+PEDxdI= ) + 3600 NSEC a.example. NS SOA MX RRSIG NSEC DNSKEY + 3600 RRSIG NSEC 5 1 3600 20040509183619 ( + 20040409183619 38519 example. + O0k558jHhyrC97ISHnislm4kLMW48C7U7cBm + FTfhke5iVqNRVTB1STLMpgpbDIC9hcryoO0V + Z9ME5xPzUEhbvGnHd5sfzgFVeGxr5Nyyq4tW + SDBgIBiLQUv1ivy29vhXy7WgR62dPrZ0PWvm + jfFJ5arXf4nPxp/kEowGgBRzY/U= ) + 3600 DNSKEY 256 3 5 ( + AQOy1bZVvpPqhg4j7EJoM9rI3ZmyEx2OzDBV + rZy/lvI5CQePxXHZS4i8dANH4DX3tbHol61e + k8EFMcsGXxKciJFHyhl94C+NwILQdzsUlSFo + vBZsyl/NX6yEbtw/xN9ZNcrbYvgjjZ/UVPZI + + + +Arends, et al. Standards Track [Page 36] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + + ySFNsgEYvh0z2542lzMKR4Dh8uZffQ== + ) + 3600 DNSKEY 257 3 5 ( + AQOeX7+baTmvpVHb2CcLnL1dMRWbuscRvHXl + LnXwDzvqp4tZVKp1sZMepFb8MvxhhW3y/0QZ + syCjczGJ1qk8vJe52iOhInKROVLRwxGpMfzP + RLMlGybr51bOV/1se0ODacj3DomyB4QB5gKT + Yot/K9alk5/j8vfd4jWCWD+E1Sze0Q== + ) + 3600 RRSIG DNSKEY 5 1 3600 20040509183619 ( + 20040409183619 9465 example. + ZxgauAuIj+k1YoVEOSlZfx41fcmKzTFHoweZ + xYnz99JVQZJ33wFS0Q0jcP7VXKkaElXk9nYJ + XevO/7nAbo88iWsMkSpSR6jWzYYKwfrBI/L9 + hjYmyVO9m6FjQ7uwM4dCP/bIuV/DKqOAK9NY + NC3AHfvCV1Tp4VKDqxqG7R5tTVM= ) + 3600 RRSIG DNSKEY 5 1 3600 20040509183619 ( + 20040409183619 38519 example. + eGL0s90glUqcOmloo/2y+bSzyEfKVOQViD9Z + DNhLz/Yn9CQZlDVRJffACQDAUhXpU/oP34ri + bKBpysRXosczFrKqS5Oa0bzMOfXCXup9qHAp + eFIku28Vqfr8Nt7cigZLxjK+u0Ws/4lIRjKk + 7z5OXogYVaFzHKillDt3HRxHIZM= ) + a.example. 3600 IN NS ns1.a.example. + 3600 IN NS ns2.a.example. + 3600 DS 57855 5 1 ( + B6DCD485719ADCA18E5F3D48A2331627FDD3 + 636B ) + 3600 RRSIG DS 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + oXIKit/QtdG64J/CB+Gi8dOvnwRvqrto1AdQ + oRkAN15FP3iZ7suB7gvTBmXzCjL7XUgQVcoH + kdhyCuzp8W9qJHgRUSwKKkczSyuL64nhgjuD + EML8l9wlWVsl7PR2VnZduM9bLyBhaaPmRKX/ + Fm+v6ccF2EGNLRiY08kdkz+XHHo= ) + 3600 NSEC ai.example. NS DS RRSIG NSEC + 3600 RRSIG NSEC 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + cOlYgqJLqlRqmBQ3iap2SyIsK4O5aqpKSoba + U9fQ5SMApZmHfq3AgLflkrkXRXvgxTQSKkG2 + 039/cRUs6Jk/25+fi7Xr5nOVJsb0lq4zsB3I + BBdjyGDAHE0F5ROJj87996vJupdm1fbH481g + sdkOW6Zyqtz3Zos8N0BBkEx+2G4= ) + ns1.a.example. 3600 IN A 192.0.2.5 + ns2.a.example. 3600 IN A 192.0.2.6 + ai.example. 3600 IN A 192.0.2.9 + 3600 RRSIG A 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + + + +Arends, et al. Standards Track [Page 37] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + + pAOtzLP2MU0tDJUwHOKE5FPIIHmdYsCgTb5B + ERGgpnJluA9ixOyf6xxVCgrEJW0WNZSsJicd + hBHXfDmAGKUajUUlYSAH8tS4ZnrhyymIvk3u + ArDu2wfT130e9UHnumaHHMpUTosKe22PblOy + 6zrTpg9FkS0XGVmYRvOTNYx2HvQ= ) + 3600 HINFO "KLH-10" "ITS" + 3600 RRSIG HINFO 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + Iq/RGCbBdKzcYzlGE4ovbr5YcB+ezxbZ9W0l + e/7WqyvhOO9J16HxhhL7VY/IKmTUY0GGdcfh + ZEOCkf4lEykZF9NPok1/R/fWrtzNp8jobuY7 + AZEcZadp1WdDF3jc2/ndCa5XZhLKD3JzOsBw + FvL8sqlS5QS6FY/ijFEDnI4RkZA= ) + 3600 AAAA 2001:db8::f00:baa9 + 3600 RRSIG AAAA 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + nLcpFuXdT35AcE+EoafOUkl69KB+/e56XmFK + kewXG2IadYLKAOBIoR5+VoQV3XgTcofTJNsh + 1rnF6Eav2zpZB3byI6yo2bwY8MNkr4A7cL9T + cMmDwV/hWFKsbGBsj8xSCN/caEL2CWY/5XP2 + sZM6QjBBLmukH30+w1z3h8PUP2o= ) + 3600 NSEC b.example. A HINFO AAAA RRSIG NSEC + 3600 RRSIG NSEC 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + QoshyPevLcJ/xcRpEtMft1uoIrcrieVcc9pG + CScIn5Glnib40T6ayVOimXwdSTZ/8ISXGj4p + P8Sh0PlA6olZQ84L453/BUqB8BpdOGky4hsN + 3AGcLEv1Gr0QMvirQaFcjzOECfnGyBm+wpFL + AhS+JOVfDI/79QtyTI0SaDWcg8U= ) + b.example. 3600 IN NS ns1.b.example. + 3600 IN NS ns2.b.example. + 3600 NSEC ns1.example. NS RRSIG NSEC + 3600 RRSIG NSEC 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + GNuxHn844wfmUhPzGWKJCPY5ttEX/RfjDoOx + 9ueK1PtYkOWKOOdiJ/PJKCYB3hYX+858dDWS + xb2qnV/LSTCNVBnkm6owOpysY97MVj5VQEWs + 0lm9tFoqjcptQkmQKYPrwUnCSNwvvclSF1xZ + vhRXgWT7OuFXldoCG6TfVFMs9xE= ) + ns1.b.example. 3600 IN A 192.0.2.7 + ns2.b.example. 3600 IN A 192.0.2.8 + ns1.example. 3600 IN A 192.0.2.1 + 3600 RRSIG A 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + F1C9HVhIcs10cZU09G5yIVfKJy5yRQQ3qVet + 5pGhp82pzhAOMZ3K22JnmK4c+IjUeFp/to06 + im5FVpHtbFisdjyPq84bhTv8vrXt5AB1wNB+ + +iAqvIfdgW4sFNC6oADb1hK8QNauw9VePJhK + + + +Arends, et al. Standards Track [Page 38] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + + v/iVXSYC0b7mPSU+EOlknFpVECs= ) + 3600 NSEC ns2.example. A RRSIG NSEC + 3600 RRSIG NSEC 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + I4hj+Kt6+8rCcHcUdolks2S+Wzri9h3fHas8 + 1rGN/eILdJHN7JpV6lLGPIh/8fIBkfvdyWnB + jjf1q3O7JgYO1UdI7FvBNWqaaEPJK3UkddBq + ZIaLi8Qr2XHkjq38BeQsbp8X0+6h4ETWSGT8 + IZaIGBLryQWGLw6Y6X8dqhlnxJM= ) + ns2.example. 3600 IN A 192.0.2.2 + 3600 RRSIG A 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + V7cQRw1TR+knlaL1z/psxlS1PcD37JJDaCMq + Qo6/u1qFQu6x+wuDHRH22Ap9ulJPQjFwMKOu + yfPGQPC8KzGdE3vt5snFEAoE1Vn3mQqtu7SO + 6amIjk13Kj/jyJ4nGmdRIc/3cM3ipXFhNTKq + rdhx8SZ0yy4ObIRzIzvBFLiSS8o= ) + 3600 NSEC *.w.example. A RRSIG NSEC + 3600 RRSIG NSEC 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + N0QzHvaJf5NRw1rE9uxS1Ltb2LZ73Qb9bKGE + VyaISkqzGpP3jYJXZJPVTq4UVEsgT3CgeHvb + 3QbeJ5Dfb2V9NGCHj/OvF/LBxFFWwhLwzngH + l+bQAgAcMsLu/nL3nDi1y/JSQjAcdZNDl4bw + Ymx28EtgIpo9A0qmP08rMBqs1Jw= ) + *.w.example. 3600 IN MX 1 ai.example. + 3600 RRSIG MX 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + OMK8rAZlepfzLWW75Dxd63jy2wswESzxDKG2 + f9AMN1CytCd10cYISAxfAdvXSZ7xujKAtPbc + tvOQ2ofO7AZJ+d01EeeQTVBPq4/6KCWhqe2X + TjnkVLNvvhnc0u28aoSsG0+4InvkkOHknKxw + 4kX18MMR34i8lC36SR5xBni8vHI= ) + 3600 NSEC x.w.example. MX RRSIG NSEC + 3600 RRSIG NSEC 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + r/mZnRC3I/VIcrelgIcteSxDhtsdlTDt8ng9 + HSBlABOlzLxQtfgTnn8f+aOwJIAFe1Ee5RvU + 5cVhQJNP5XpXMJHfyps8tVvfxSAXfahpYqtx + 91gsmcV/1V9/bZAG55CefP9cM4Z9Y9NT9XQ8 + s1InQ2UoIv6tJEaaKkP701j8OLA= ) + x.w.example. 3600 IN MX 1 xx.example. + 3600 RRSIG MX 5 3 3600 20040509183619 ( + 20040409183619 38519 example. + Il2WTZ+Bkv+OytBx4LItNW5mjB4RCwhOO8y1 + XzPHZmZUTVYL7LaA63f6T9ysVBzJRI3KRjAP + H3U1qaYnDoN1DrWqmi9RJe4FoObkbcdm7P3I + kx70ePCoFgRz1Yq+bVVXCvGuAU4xALv3W/Y1 + + + +Arends, et al. Standards Track [Page 39] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + + jNSlwZ2mSWKHfxFQxPtLj8s32+k= ) + 3600 NSEC x.y.w.example. MX RRSIG NSEC + 3600 RRSIG NSEC 5 3 3600 20040509183619 ( + 20040409183619 38519 example. + aRbpHftxggzgMXdDlym9SsADqMZovZZl2QWK + vw8J0tZEUNQByH5Qfnf5N1FqH/pS46UA7A4E + mcWBN9PUA1pdPY6RVeaRlZlCr1IkVctvbtaI + NJuBba/VHm+pebTbKcAPIvL9tBOoh+to1h6e + IjgiM8PXkBQtxPq37wDKALkyn7Q= ) + x.y.w.example. 3600 IN MX 1 xx.example. + 3600 RRSIG MX 5 4 3600 20040509183619 ( + 20040409183619 38519 example. + k2bJHbwP5LH5qN4is39UiPzjAWYmJA38Hhia + t7i9t7nbX/e0FPnvDSQXzcK7UL+zrVA+3MDj + q1ub4q3SZgcbLMgexxIW3Va//LVrxkP6Xupq + GtOB9prkK54QTl/qZTXfMQpW480YOvVknhvb + +gLcMZBnHJ326nb/TOOmrqNmQQE= ) + 3600 NSEC xx.example. MX RRSIG NSEC + 3600 RRSIG NSEC 5 4 3600 20040509183619 ( + 20040409183619 38519 example. + OvE6WUzN2ziieJcvKPWbCAyXyP6ef8cr6Csp + ArVSTzKSquNwbezZmkU7E34o5lmb6CWSSSpg + xw098kNUFnHcQf/LzY2zqRomubrNQhJTiDTX + a0ArunJQCzPjOYq5t0SLjm6qp6McJI1AP5Vr + QoKqJDCLnoAlcPOPKAm/jJkn3jk= ) + xx.example. 3600 IN A 192.0.2.10 + 3600 RRSIG A 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + kBF4YxMGWF0D8r0cztL+2fWWOvN1U/GYSpYP + 7SoKoNQ4fZKyk+weWGlKLIUM+uE1zjVTPXoa + 0Z6WG0oZp46rkl1EzMcdMgoaeUzzAJ2BMq+Y + VdxG9IK1yZkYGY9AgbTOGPoAgbJyO9EPULsx + kbIDV6GPPSZVusnZU6OMgdgzHV4= ) + 3600 HINFO "KLH-10" "TOPS-20" + 3600 RRSIG HINFO 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + GY2PLSXmMHkWHfLdggiox8+chWpeMNJLkML0 + t+U/SXSUsoUdR91KNdNUkTDWamwcF8oFRjhq + BcPZ6EqrF+vl5v5oGuvSF7U52epfVTC+wWF8 + 3yCUeUw8YklhLWlvk8gQ15YKth0ITQy8/wI+ + RgNvuwbioFSEuv2pNlkq0goYxNY= ) + 3600 AAAA 2001:db8::f00:baaa + 3600 RRSIG AAAA 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + Zzj0yodDxcBLnnOIwDsuKo5WqiaK24DlKg9C + aGaxDFiKgKobUj2jilYQHpGFn2poFRetZd4z + ulyQkssz2QHrVrPuTMS22knudCiwP4LWpVTr + U4zfeA+rDz9stmSBP/4PekH/x2IoAYnwctd/ + + + +Arends, et al. Standards Track [Page 40] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + + xS9cL2QgW7FChw16mzlkH6/vsfs= ) + 3600 NSEC example. A HINFO AAAA RRSIG NSEC + 3600 RRSIG NSEC 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + ZFWUln6Avc8bmGl5GFjD3BwT530DUZKHNuoY + 9A8lgXYyrxu+pqgFiRVbyZRQvVB5pccEOT3k + mvHgEa/HzbDB4PIYY79W+VHrgOxzdQGGCZzi + asXrpSGOWwSOElghPnMIi8xdF7qtCntr382W + GghLahumFIpg4MO3LS/prgzVVWo= ) + + The apex DNSKEY set includes two DNSKEY RRs, and the DNSKEY RDATA + Flags indicate that each of these DNSKEY RRs is a zone key. One of + these DNSKEY RRs also has the SEP flag set and has been used to sign + the apex DNSKEY RRset; this is the key that should be hashed to + generate a DS record to be inserted into the parent zone. The other + DNSKEY is used to sign all the other RRsets in the zone. + + The zone includes a wildcard entry, "*.w.example". Note that the + name "*.w.example" is used in constructing NSEC chains, and that the + RRSIG covering the "*.w.example" MX RRset has a label count of 2. + + The zone also includes two delegations. The delegation to + "b.example" includes an NS RRset, glue address records, and an NSEC + RR; note that only the NSEC RRset is signed. The delegation to + "a.example" provides a DS RR; note that only the NSEC and DS RRsets + are signed. + +Appendix B. Example Responses + + The examples in this section show response messages using the signed + zone example in Appendix A. + +B.1. Answer + + A successful query to an authoritative server. + + ;; Header: QR AA DO RCODE=0 + ;; + ;; Question + x.w.example. IN MX + + ;; Answer + x.w.example. 3600 IN MX 1 xx.example. + x.w.example. 3600 RRSIG MX 5 3 3600 20040509183619 ( + 20040409183619 38519 example. + Il2WTZ+Bkv+OytBx4LItNW5mjB4RCwhOO8y1 + XzPHZmZUTVYL7LaA63f6T9ysVBzJRI3KRjAP + H3U1qaYnDoN1DrWqmi9RJe4FoObkbcdm7P3I + + + +Arends, et al. Standards Track [Page 41] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + + kx70ePCoFgRz1Yq+bVVXCvGuAU4xALv3W/Y1 + jNSlwZ2mSWKHfxFQxPtLj8s32+k= ) + + ;; Authority + example. 3600 NS ns1.example. + example. 3600 NS ns2.example. + example. 3600 RRSIG NS 5 1 3600 20040509183619 ( + 20040409183619 38519 example. + gl13F00f2U0R+SWiXXLHwsMY+qStYy5k6zfd + EuivWc+wd1fmbNCyql0Tk7lHTX6UOxc8AgNf + 4ISFve8XqF4q+o9qlnqIzmppU3LiNeKT4FZ8 + RO5urFOvoMRTbQxW3U0hXWuggE4g3ZpsHv48 + 0HjMeRaZB/FRPGfJPajngcq6Kwg= ) + + ;; Additional + xx.example. 3600 IN A 192.0.2.10 + xx.example. 3600 RRSIG A 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + kBF4YxMGWF0D8r0cztL+2fWWOvN1U/GYSpYP + 7SoKoNQ4fZKyk+weWGlKLIUM+uE1zjVTPXoa + 0Z6WG0oZp46rkl1EzMcdMgoaeUzzAJ2BMq+Y + VdxG9IK1yZkYGY9AgbTOGPoAgbJyO9EPULsx + kbIDV6GPPSZVusnZU6OMgdgzHV4= ) + xx.example. 3600 AAAA 2001:db8::f00:baaa + xx.example. 3600 RRSIG AAAA 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + Zzj0yodDxcBLnnOIwDsuKo5WqiaK24DlKg9C + aGaxDFiKgKobUj2jilYQHpGFn2poFRetZd4z + ulyQkssz2QHrVrPuTMS22knudCiwP4LWpVTr + U4zfeA+rDz9stmSBP/4PekH/x2IoAYnwctd/ + xS9cL2QgW7FChw16mzlkH6/vsfs= ) + ns1.example. 3600 IN A 192.0.2.1 + ns1.example. 3600 RRSIG A 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + F1C9HVhIcs10cZU09G5yIVfKJy5yRQQ3qVet + 5pGhp82pzhAOMZ3K22JnmK4c+IjUeFp/to06 + im5FVpHtbFisdjyPq84bhTv8vrXt5AB1wNB+ + +iAqvIfdgW4sFNC6oADb1hK8QNauw9VePJhK + v/iVXSYC0b7mPSU+EOlknFpVECs= ) + ns2.example. 3600 IN A 192.0.2.2 + ns2.example. 3600 RRSIG A 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + V7cQRw1TR+knlaL1z/psxlS1PcD37JJDaCMq + Qo6/u1qFQu6x+wuDHRH22Ap9ulJPQjFwMKOu + yfPGQPC8KzGdE3vt5snFEAoE1Vn3mQqtu7SO + 6amIjk13Kj/jyJ4nGmdRIc/3cM3ipXFhNTKq + rdhx8SZ0yy4ObIRzIzvBFLiSS8o= ) + + + + +Arends, et al. Standards Track [Page 42] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + +B.2. Name Error + + An authoritative name error. The NSEC RRs prove that the name does + not exist and that no covering wildcard exists. + + ;; Header: QR AA DO RCODE=3 + ;; + ;; Question + ml.example. IN A + + ;; Answer + ;; (empty) + + ;; Authority + example. 3600 IN SOA ns1.example. bugs.x.w.example. ( + 1081539377 + 3600 + 300 + 3600000 + 3600 + ) + example. 3600 RRSIG SOA 5 1 3600 20040509183619 ( + 20040409183619 38519 example. + ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h + 7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF + vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW + DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB + jV7j86HyQgM5e7+miRAz8V01b0I= ) + b.example. 3600 NSEC ns1.example. NS RRSIG NSEC + b.example. 3600 RRSIG NSEC 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + GNuxHn844wfmUhPzGWKJCPY5ttEX/RfjDoOx + 9ueK1PtYkOWKOOdiJ/PJKCYB3hYX+858dDWS + xb2qnV/LSTCNVBnkm6owOpysY97MVj5VQEWs + 0lm9tFoqjcptQkmQKYPrwUnCSNwvvclSF1xZ + vhRXgWT7OuFXldoCG6TfVFMs9xE= ) + example. 3600 NSEC a.example. NS SOA MX RRSIG NSEC DNSKEY + example. 3600 RRSIG NSEC 5 1 3600 20040509183619 ( + 20040409183619 38519 example. + O0k558jHhyrC97ISHnislm4kLMW48C7U7cBm + FTfhke5iVqNRVTB1STLMpgpbDIC9hcryoO0V + Z9ME5xPzUEhbvGnHd5sfzgFVeGxr5Nyyq4tW + SDBgIBiLQUv1ivy29vhXy7WgR62dPrZ0PWvm + jfFJ5arXf4nPxp/kEowGgBRzY/U= ) + + ;; Additional + ;; (empty) + + + + +Arends, et al. Standards Track [Page 43] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + +B.3. No Data Error + + A "no data" response. The NSEC RR proves that the name exists and + that the requested RR type does not. + + ;; Header: QR AA DO RCODE=0 + ;; + ;; Question + ns1.example. IN MX + + ;; Answer + ;; (empty) + + ;; Authority + example. 3600 IN SOA ns1.example. bugs.x.w.example. ( + 1081539377 + 3600 + 300 + 3600000 + 3600 + ) + example. 3600 RRSIG SOA 5 1 3600 20040509183619 ( + 20040409183619 38519 example. + ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h + 7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF + vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW + DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB + jV7j86HyQgM5e7+miRAz8V01b0I= ) + ns1.example. 3600 NSEC ns2.example. A RRSIG NSEC + ns1.example. 3600 RRSIG NSEC 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + I4hj+Kt6+8rCcHcUdolks2S+Wzri9h3fHas8 + 1rGN/eILdJHN7JpV6lLGPIh/8fIBkfvdyWnB + jjf1q3O7JgYO1UdI7FvBNWqaaEPJK3UkddBq + ZIaLi8Qr2XHkjq38BeQsbp8X0+6h4ETWSGT8 + IZaIGBLryQWGLw6Y6X8dqhlnxJM= ) + + ;; Additional + ;; (empty) + +B.4. Referral to Signed Zone + + Referral to a signed zone. The DS RR contains the data which the + resolver will need to validate the corresponding DNSKEY RR in the + child zone's apex. + + ;; Header: QR DO RCODE=0 + ;; + + + +Arends, et al. Standards Track [Page 44] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + + ;; Question + mc.a.example. IN MX + + ;; Answer + ;; (empty) + + ;; Authority + a.example. 3600 IN NS ns1.a.example. + a.example. 3600 IN NS ns2.a.example. + a.example. 3600 DS 57855 5 1 ( + B6DCD485719ADCA18E5F3D48A2331627FDD3 + 636B ) + a.example. 3600 RRSIG DS 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + oXIKit/QtdG64J/CB+Gi8dOvnwRvqrto1AdQ + oRkAN15FP3iZ7suB7gvTBmXzCjL7XUgQVcoH + kdhyCuzp8W9qJHgRUSwKKkczSyuL64nhgjuD + EML8l9wlWVsl7PR2VnZduM9bLyBhaaPmRKX/ + Fm+v6ccF2EGNLRiY08kdkz+XHHo= ) + + ;; Additional + ns1.a.example. 3600 IN A 192.0.2.5 + ns2.a.example. 3600 IN A 192.0.2.6 + +B.5. Referral to Unsigned Zone + + Referral to an unsigned zone. The NSEC RR proves that no DS RR for + this delegation exists in the parent zone. + + ;; Header: QR DO RCODE=0 + ;; + ;; Question + mc.b.example. IN MX + + ;; Answer + ;; (empty) + + ;; Authority + b.example. 3600 IN NS ns1.b.example. + b.example. 3600 IN NS ns2.b.example. + b.example. 3600 NSEC ns1.example. NS RRSIG NSEC + b.example. 3600 RRSIG NSEC 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + GNuxHn844wfmUhPzGWKJCPY5ttEX/RfjDoOx + 9ueK1PtYkOWKOOdiJ/PJKCYB3hYX+858dDWS + xb2qnV/LSTCNVBnkm6owOpysY97MVj5VQEWs + 0lm9tFoqjcptQkmQKYPrwUnCSNwvvclSF1xZ + vhRXgWT7OuFXldoCG6TfVFMs9xE= ) + + + +Arends, et al. Standards Track [Page 45] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + + ;; Additional + ns1.b.example. 3600 IN A 192.0.2.7 + ns2.b.example. 3600 IN A 192.0.2.8 + +B.6. Wildcard Expansion + + A successful query that was answered via wildcard expansion. The + label count in the answer's RRSIG RR indicates that a wildcard RRset + was expanded to produce this response, and the NSEC RR proves that no + closer match exists in the zone. + + ;; Header: QR AA DO RCODE=0 + ;; + ;; Question + a.z.w.example. IN MX + + ;; Answer + a.z.w.example. 3600 IN MX 1 ai.example. + a.z.w.example. 3600 RRSIG MX 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + OMK8rAZlepfzLWW75Dxd63jy2wswESzxDKG2 + f9AMN1CytCd10cYISAxfAdvXSZ7xujKAtPbc + tvOQ2ofO7AZJ+d01EeeQTVBPq4/6KCWhqe2X + TjnkVLNvvhnc0u28aoSsG0+4InvkkOHknKxw + 4kX18MMR34i8lC36SR5xBni8vHI= ) + + ;; Authority + example. 3600 NS ns1.example. + example. 3600 NS ns2.example. + example. 3600 RRSIG NS 5 1 3600 20040509183619 ( + 20040409183619 38519 example. + gl13F00f2U0R+SWiXXLHwsMY+qStYy5k6zfd + EuivWc+wd1fmbNCyql0Tk7lHTX6UOxc8AgNf + 4ISFve8XqF4q+o9qlnqIzmppU3LiNeKT4FZ8 + RO5urFOvoMRTbQxW3U0hXWuggE4g3ZpsHv48 + 0HjMeRaZB/FRPGfJPajngcq6Kwg= ) + x.y.w.example. 3600 NSEC xx.example. MX RRSIG NSEC + x.y.w.example. 3600 RRSIG NSEC 5 4 3600 20040509183619 ( + 20040409183619 38519 example. + OvE6WUzN2ziieJcvKPWbCAyXyP6ef8cr6Csp + ArVSTzKSquNwbezZmkU7E34o5lmb6CWSSSpg + xw098kNUFnHcQf/LzY2zqRomubrNQhJTiDTX + a0ArunJQCzPjOYq5t0SLjm6qp6McJI1AP5Vr + QoKqJDCLnoAlcPOPKAm/jJkn3jk= ) + + ;; Additional + ai.example. 3600 IN A 192.0.2.9 + ai.example. 3600 RRSIG A 5 2 3600 20040509183619 ( + + + +Arends, et al. Standards Track [Page 46] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + + 20040409183619 38519 example. + pAOtzLP2MU0tDJUwHOKE5FPIIHmdYsCgTb5B + ERGgpnJluA9ixOyf6xxVCgrEJW0WNZSsJicd + hBHXfDmAGKUajUUlYSAH8tS4ZnrhyymIvk3u + ArDu2wfT130e9UHnumaHHMpUTosKe22PblOy + 6zrTpg9FkS0XGVmYRvOTNYx2HvQ= ) + ai.example. 3600 AAAA 2001:db8::f00:baa9 + ai.example. 3600 RRSIG AAAA 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + nLcpFuXdT35AcE+EoafOUkl69KB+/e56XmFK + kewXG2IadYLKAOBIoR5+VoQV3XgTcofTJNsh + 1rnF6Eav2zpZB3byI6yo2bwY8MNkr4A7cL9T + cMmDwV/hWFKsbGBsj8xSCN/caEL2CWY/5XP2 + sZM6QjBBLmukH30+w1z3h8PUP2o= ) + +B.7. Wildcard No Data Error + + A "no data" response for a name covered by a wildcard. The NSEC RRs + prove that the matching wildcard name does not have any RRs of the + requested type and that no closer match exists in the zone. + + ;; Header: QR AA DO RCODE=0 + ;; + ;; Question + a.z.w.example. IN AAAA + + ;; Answer + ;; (empty) + + ;; Authority + example. 3600 IN SOA ns1.example. bugs.x.w.example. ( + 1081539377 + 3600 + 300 + 3600000 + 3600 + ) + example. 3600 RRSIG SOA 5 1 3600 20040509183619 ( + 20040409183619 38519 example. + ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h + 7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF + vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW + DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB + jV7j86HyQgM5e7+miRAz8V01b0I= ) + x.y.w.example. 3600 NSEC xx.example. MX RRSIG NSEC + x.y.w.example. 3600 RRSIG NSEC 5 4 3600 20040509183619 ( + 20040409183619 38519 example. + OvE6WUzN2ziieJcvKPWbCAyXyP6ef8cr6Csp + + + +Arends, et al. Standards Track [Page 47] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + + ArVSTzKSquNwbezZmkU7E34o5lmb6CWSSSpg + xw098kNUFnHcQf/LzY2zqRomubrNQhJTiDTX + a0ArunJQCzPjOYq5t0SLjm6qp6McJI1AP5Vr + QoKqJDCLnoAlcPOPKAm/jJkn3jk= ) + *.w.example. 3600 NSEC x.w.example. MX RRSIG NSEC + *.w.example. 3600 RRSIG NSEC 5 2 3600 20040509183619 ( + 20040409183619 38519 example. + r/mZnRC3I/VIcrelgIcteSxDhtsdlTDt8ng9 + HSBlABOlzLxQtfgTnn8f+aOwJIAFe1Ee5RvU + 5cVhQJNP5XpXMJHfyps8tVvfxSAXfahpYqtx + 91gsmcV/1V9/bZAG55CefP9cM4Z9Y9NT9XQ8 + s1InQ2UoIv6tJEaaKkP701j8OLA= ) + + ;; Additional + ;; (empty) + +B.8. DS Child Zone No Data Error + + A "no data" response for a QTYPE=DS query that was mistakenly sent to + a name server for the child zone. + + ;; Header: QR AA DO RCODE=0 + ;; + ;; Question + example. IN DS + + ;; Answer + ;; (empty) + + ;; Authority + example. 3600 IN SOA ns1.example. bugs.x.w.example. ( + 1081539377 + 3600 + 300 + 3600000 + 3600 + ) + example. 3600 RRSIG SOA 5 1 3600 20040509183619 ( + 20040409183619 38519 example. + ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h + 7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF + vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW + DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB + jV7j86HyQgM5e7+miRAz8V01b0I= ) + example. 3600 NSEC a.example. NS SOA MX RRSIG NSEC DNSKEY + example. 3600 RRSIG NSEC 5 1 3600 20040509183619 ( + 20040409183619 38519 example. + O0k558jHhyrC97ISHnislm4kLMW48C7U7cBm + + + +Arends, et al. Standards Track [Page 48] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + + FTfhke5iVqNRVTB1STLMpgpbDIC9hcryoO0V + Z9ME5xPzUEhbvGnHd5sfzgFVeGxr5Nyyq4tW + SDBgIBiLQUv1ivy29vhXy7WgR62dPrZ0PWvm + jfFJ5arXf4nPxp/kEowGgBRzY/U= ) + + ;; Additional + ;; (empty) + +Appendix C. Authentication Examples + + The examples in this section show how the response messages in + Appendix B are authenticated. + +C.1. Authenticating an Answer + + The query in Appendix B.1 returned an MX RRset for "x.w.example.com". + The corresponding RRSIG indicates that the MX RRset was signed by an + "example" DNSKEY with algorithm 5 and key tag 38519. The resolver + needs the corresponding DNSKEY RR in order to authenticate this + answer. The discussion below describes how a resolver might obtain + this DNSKEY RR. + + The RRSIG indicates the original TTL of the MX RRset was 3600, and, + for the purpose of authentication, the current TTL is replaced by + 3600. The RRSIG labels field value of 3 indicates that the answer + was not the result of wildcard expansion. The "x.w.example.com" MX + RRset is placed in canonical form, and, assuming the current time + falls between the signature inception and expiration dates, the + signature is authenticated. + +C.1.1. Authenticating the Example DNSKEY RR + + This example shows the logical authentication process that starts + from the a configured root DNSKEY (or DS RR) and moves down the tree + to authenticate the desired "example" DNSKEY RR. Note that the + logical order is presented for clarity. An implementation may choose + to construct the authentication as referrals are received or to + construct the authentication chain only after all RRsets have been + obtained, or in any other combination it sees fit. The example here + demonstrates only the logical process and does not dictate any + implementation rules. + + We assume the resolver starts with a configured DNSKEY RR for the + root zone (or a configured DS RR for the root zone). The resolver + checks whether this configured DNSKEY RR is present in the root + DNSKEY RRset (or whether the DS RR matches some DNSKEY in the root + DNSKEY RRset), whether this DNSKEY RR has signed the root DNSKEY + RRset, and whether the signature lifetime is valid. If all these + + + +Arends, et al. Standards Track [Page 49] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + + conditions are met, all keys in the DNSKEY RRset are considered + authenticated. The resolver then uses one (or more) of the root + DNSKEY RRs to authenticate the "example" DS RRset. Note that the + resolver may have to query the root zone to obtain the root DNSKEY + RRset or "example" DS RRset. + + Once the DS RRset has been authenticated using the root DNSKEY, the + resolver checks the "example" DNSKEY RRset for some "example" DNSKEY + RR that matches one of the authenticated "example" DS RRs. If such a + matching "example" DNSKEY is found, the resolver checks whether this + DNSKEY RR has signed the "example" DNSKEY RRset and the signature + lifetime is valid. If these conditions are met, all keys in the + "example" DNSKEY RRset are considered authenticated. + + Finally, the resolver checks that some DNSKEY RR in the "example" + DNSKEY RRset uses algorithm 5 and has a key tag of 38519. This + DNSKEY is used to authenticate the RRSIG included in the response. + If multiple "example" DNSKEY RRs match this algorithm and key tag, + then each DNSKEY RR is tried, and the answer is authenticated if any + of the matching DNSKEY RRs validate the signature as described above. + +C.2. Name Error + + The query in Appendix B.2 returned NSEC RRs that prove that the + requested data does not exist and no wildcard applies. The negative + reply is authenticated by verifying both NSEC RRs. The NSEC RRs are + authenticated in a manner identical to that of the MX RRset discussed + above. + +C.3. No Data Error + + The query in Appendix B.3 returned an NSEC RR that proves that the + requested name exists, but the requested RR type does not exist. The + negative reply is authenticated by verifying the NSEC RR. The NSEC + RR is authenticated in a manner identical to that of the MX RRset + discussed above. + +C.4. Referral to Signed Zone + + The query in Appendix B.4 returned a referral to the signed + "a.example." zone. The DS RR is authenticated in a manner identical + to that of the MX RRset discussed above. This DS RR is used to + authenticate the "a.example" DNSKEY RRset. + + Once the "a.example" DS RRset has been authenticated using the + "example" DNSKEY, the resolver checks the "a.example" DNSKEY RRset + for some "a.example" DNSKEY RR that matches the DS RR. If such a + matching "a.example" DNSKEY is found, the resolver checks whether + + + +Arends, et al. Standards Track [Page 50] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + + this DNSKEY RR has signed the "a.example" DNSKEY RRset and whether + the signature lifetime is valid. If all these conditions are met, + all keys in the "a.example" DNSKEY RRset are considered + authenticated. + +C.5. Referral to Unsigned Zone + + The query in Appendix B.5 returned a referral to an unsigned + "b.example." zone. The NSEC proves that no authentication leads from + "example" to "b.example", and the NSEC RR is authenticated in a + manner identical to that of the MX RRset discussed above. + +C.6. Wildcard Expansion + + The query in Appendix B.6 returned an answer that was produced as a + result of wildcard expansion. The answer section contains a wildcard + RRset expanded as it would be in a traditional DNS response, and the + corresponding RRSIG indicates that the expanded wildcard MX RRset was + signed by an "example" DNSKEY with algorithm 5 and key tag 38519. + The RRSIG indicates that the original TTL of the MX RRset was 3600, + and, for the purpose of authentication, the current TTL is replaced + by 3600. The RRSIG labels field value of 2 indicates that the answer + is the result of wildcard expansion, as the "a.z.w.example" name + contains 4 labels. The name "a.z.w.w.example" is replaced by + "*.w.example", the MX RRset is placed in canonical form, and, + assuming that the current time falls between the signature inception + and expiration dates, the signature is authenticated. + + The NSEC proves that no closer match (exact or closer wildcard) could + have been used to answer this query, and the NSEC RR must also be + authenticated before the answer is considered valid. + +C.7. Wildcard No Data Error + + The query in Appendix B.7 returned NSEC RRs that prove that the + requested data does not exist and no wildcard applies. The negative + reply is authenticated by verifying both NSEC RRs. + +C.8. DS Child Zone No Data Error + + The query in Appendix B.8 returned NSEC RRs that shows the requested + was answered by a child server ("example" server). The NSEC RR + indicates the presence of an SOA RR, showing that the answer is from + the child . Queries for the "example" DS RRset should be sent to the + parent servers ("root" servers). + + + + + + +Arends, et al. Standards Track [Page 51] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + +Authors' Addresses + + Roy Arends + Telematica Instituut + Brouwerijstraat 1 + 7523 XC Enschede + NL + + EMail: roy.arends@telin.nl + + + Rob Austein + Internet Systems Consortium + 950 Charter Street + Redwood City, CA 94063 + USA + + EMail: sra@isc.org + + + Matt Larson + VeriSign, Inc. + 21345 Ridgetop Circle + Dulles, VA 20166-6503 + USA + + EMail: mlarson@verisign.com + + + Dan Massey + Colorado State University + Department of Computer Science + Fort Collins, CO 80523-1873 + + EMail: massey@cs.colostate.edu + + + Scott Rose + National Institute for Standards and Technology + 100 Bureau Drive + Gaithersburg, MD 20899-8920 + USA + + EMail: scott.rose@nist.gov + + + + + + + +Arends, et al. Standards Track [Page 52] + +RFC 4035 DNSSEC Protocol Modifications March 2005 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2005). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at ietf- + ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + +Arends, et al. Standards Track [Page 53] + diff --git a/RFCs/rfc4288.txt b/RFCs/rfc4288.txt new file mode 100644 index 0000000..7405600 --- /dev/null +++ b/RFCs/rfc4288.txt @@ -0,0 +1,1347 @@ + + + + + + +Network Working Group N. Freed +Request for Comments: 4288 Sun Microsystems +BCP: 13 J. Klensin +Obsoletes: 2048 December 2005 +Category: Best Current Practice + + + Media Type Specifications and Registration Procedures + +Status of This Memo + + This document specifies an Internet Best Current Practices for the + Internet Community, and requests discussion and suggestions for + improvements. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2005). + +Abstract + + This document defines procedures for the specification and + registration of media types for use in MIME and other Internet + protocols. + + + + + + + + + + + + + + + + + + + + + + + + + + + +Freed & Klensin Best Current Practice [Page 1] + +RFC 4288 Media Type Registration December 2005 + + +Table of Contents + + 1. Introduction ....................................................3 + 2. Media Type Registration Preliminaries ...........................4 + 3. Registration Trees and Subtype Names ............................4 + 3.1. Standards Tree .............................................4 + 3.2. Vendor Tree ................................................5 + 3.3. Personal or Vanity Tree ....................................5 + 3.4. Special x. Tree ............................................5 + 3.5. Additional Registration Trees ..............................6 + 4. Registration Requirements .......................................6 + 4.1. Functionality Requirement ..................................6 + 4.2. Naming Requirements ........................................6 + 4.2.1. Text Media Types ......................................7 + 4.2.2. Image Media Types .....................................8 + 4.2.3. Audio Media Types .....................................8 + 4.2.4. Video Media Types .....................................8 + 4.2.5. Application Media Types ...............................9 + 4.2.6. Multipart and Message Media Types .....................9 + 4.2.7. Additional Top-level Types ............................9 + 4.3. Parameter Requirements ....................................10 + 4.4. Canonicalization and Format Requirements ..................10 + 4.5. Interchange Recommendations ...............................11 + 4.6. Security Requirements .....................................11 + 4.7. Requirements specific to XML media types ..................13 + 4.8. Encoding Requirements .....................................13 + 4.9. Usage and Implementation Non-requirements .................13 + 4.10. Publication Requirements .................................14 + 4.11. Additional Information ...................................15 + 5. Registration Procedure .........................................15 + 5.1. Preliminary Community Review ..............................16 + 5.2. IESG Approval .............................................16 + 5.3. IANA Registration .........................................16 + 5.4. Media Types Reviewer ......................................16 + 6. Comments on Media Type Registrations ...........................17 + 7. Location of Registered Media Type List .........................17 + 8. IANA Procedures for Registering Media Types ....................17 + 9. Change Procedures ..............................................18 + 10. Registration Template .........................................19 + 11. Security Considerations .......................................20 + 12. IANA Considerations ...........................................20 + 13. Acknowledgements ..............................................20 + 14. References ....................................................20 + Appendix A. Grandfathered Media Types ............................22 + Appendix B. Changes Since RFC 2048 ...............................22 + + + + + + +Freed & Klensin Best Current Practice [Page 2] + +RFC 4288 Media Type Registration December 2005 + + +1. Introduction + + Recent Internet protocols have been carefully designed to be easily + extensible in certain areas. In particular, many protocols, + including but not limited to MIME [RFC2045], are capable of carrying + arbitrary labeled content. A mechanism is needed to label such + content and a registration process is needed for these labels, to + ensure that the set of such values is developed in an orderly, well- + specified, and public manner. + + This document defines media type specification and registration + procedures that use the Internet Assigned Numbers Authority (IANA) as + a central registry. + + Historical Note + + The media type registration process was initially defined for + registering media types for use in the context of the asynchronous + Internet mail environment. In this mail environment there is a + need to limit the number of possible media types, to increase the + likelihood of interoperability when the capabilities of the remote + mail system are not known. As media types are used in new + environments in which the proliferation of media types is not a + hindrance to interoperability, the original procedure proved + excessively restrictive and had to be generalized. This was + initially done in [RFC2048], but the procedure defined there was + still part of the MIME document set. The media type specification + and registration procedure has now been moved to this separate + document, to make it clear that it is independent of MIME. + + It may be desirable to restrict the use of media types to specific + environments or to prohibit their use in other environments. This + revision attempts for the first time to incorporate such + restrictions into media type registrations in a systematic way. + See Section 4.9 for additional discussion. + +1.1. Conventions Used in This Document + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [RFC2119]. + + This specification makes use of the Augmented Backus-Naur Form (ABNF) + [RFC4234] notation, including the core rules defined in Appendix A of + that document. + + + + + + +Freed & Klensin Best Current Practice [Page 3] + +RFC 4288 Media Type Registration December 2005 + + +2. Media Type Registration Preliminaries + + Registration of a new media type or types starts with the + construction of a registration proposal. Registration may occur + within several different registration trees that have different + requirements, as discussed below. In general, a new registration + proposal is circulated and reviewed in a fashion appropriate to the + tree involved. The media type is then registered if the proposal is + acceptable. The following sections describe the requirements and + procedures used for each of the different registration trees. + +3. Registration Trees and Subtype Names + + In order to increase the efficiency and flexibility of the + registration process, different structures of subtype names may be + registered to accommodate the different natural requirements for, + e.g., a subtype that will be recommended for wide support and + implementation by the Internet community, or a subtype that is used + to move files associated with proprietary software. The following + subsections define registration "trees" that are distinguished by the + use of faceted names, e.g., names of the form + "tree.subtree...subtype". Note that some media types defined prior + to this document do not conform to the naming conventions described + below. See Appendix A for a discussion of them. + +3.1. Standards Tree + + The standards tree is intended for types of general interest to the + Internet community. Registrations in the standards tree MUST be + approved by the IESG and MUST correspond to a formal publication by a + recognized standards body. In the case of registration for the IETF + itself, the registration proposal MUST be published as an RFC. + Standards-tree registration RFCs can either be standalone + "registration only" RFCs, or they can be incorporated into a more + general specification of some sort. + + Media types in the standards tree are normally denoted by names that + are not explicitly faceted, i.e., do not contain period (".", full + stop) characters. + + The "owner" of a media type registration in the standards tree is + assumed to be the standards body itself. Modification or alteration + of the specification requires the same level of processing (e.g., + standards track) required for the initial registration. + + + + + + + +Freed & Klensin Best Current Practice [Page 4] + +RFC 4288 Media Type Registration December 2005 + + +3.2. Vendor Tree + + The vendor tree is used for media types associated with commercially + available products. "Vendor" or "producer" are construed as + equivalent and very broadly in this context. + + A registration may be placed in the vendor tree by anyone who needs + to interchange files associated with the particular product. + However, the registration formally belongs to the vendor or + organization producing the software or file format being registered. + Changes to the specification will be made at their request, as + discussed in subsequent sections. + + Registrations in the vendor tree will be distinguished by the leading + facet "vnd.". That may be followed, at the discretion of the + registrant, by either a media subtype name from a well-known producer + (e.g., "vnd.mudpie") or by an IANA-approved designation of the + producer's name that is followed by a media type or product + designation (e.g., vnd.bigcompany.funnypictures). + + While public exposure and review of media types to be registered in + the vendor tree is not required, using the ietf-types@iana.org + mailing list for review is strongly encouraged to improve the quality + of those specifications. Registrations in the vendor tree may be + submitted directly to the IANA. + +3.3. Personal or Vanity Tree + + Registrations for media types created experimentally or as part of + products that are not distributed commercially may be registered in + the personal or vanity tree. The registrations are distinguished by + the leading facet "prs.". + + The owner of "personal" registrations and associated specifications + is the person or entity making the registration, or one to whom + responsibility has been transferred as described below. + + While public exposure and review of media types to be registered in + the personal tree is not required, using the ietf-types list for + review is strongly encouraged to improve the quality of those + specifications. Registrations in the personal tree may be submitted + directly to the IANA. + +3.4. Special x. Tree + + For convenience and symmetry with this registration scheme, subtype + names with "x." as the first facet may be used for the same purposes + for which names starting in "x-" are used. These types are + + + +Freed & Klensin Best Current Practice [Page 5] + +RFC 4288 Media Type Registration December 2005 + + + unregistered, experimental, and for use only with the active + agreement of the parties exchanging them. + + However, with the simplified registration procedures described above + for vendor and personal trees, it should rarely, if ever, be + necessary to use unregistered experimental types. Therefore, use of + both "x-" and "x." forms is discouraged. + + Types in this tree MUST NOT be registered. + +3.5. Additional Registration Trees + + From time to time and as required by the community, the IANA may, by + and with the advice and consent of the IESG, create new top-level + registration trees. It is explicitly assumed that these trees may be + created for external registration and management by well-known + permanent bodies; for example, scientific societies may register + media types specific to the sciences they cover. In general, the + quality of review of specifications for one of these additional + registration trees is expected to be equivalent to registrations in + the standards tree. Establishment of these new trees will be + announced through RFC publication approved by the IESG. + +4. Registration Requirements + + Media type registration proposals are all expected to conform to + various requirements laid out in the following sections. Note that + requirement specifics sometimes vary depending on the registration + tree, again as detailed in the following sections. + +4.1. Functionality Requirement + + Media types MUST function as an actual media format. Registration of + things that are better thought of as a transfer encoding, as a + charset, or as a collection of separate entities of another type, is + not allowed. For example, although applications exist to decode the + base64 transfer encoding [RFC2045], base64 cannot be registered as a + media type. + + This requirement applies regardless of the registration tree + involved. + +4.2. Naming Requirements + + All registered media types MUST be assigned type and subtype names. + The combination of these names serves to uniquely identify the media + type, and the format of the subtype name identifies the registration + tree. Both type and subtype names are case-insensitive. + + + +Freed & Klensin Best Current Practice [Page 6] + +RFC 4288 Media Type Registration December 2005 + + + Type and subtype names beginning with "X-" are reserved for + experimental use and MUST NOT be registered. This parallels the + restriction on the x. tree, as discussed in Section 3.4. + + + Type and subtype names MUST conform to the following ABNF: + + type-name = reg-name + subtype-name = reg-name + + reg-name = 1*127reg-name-chars + reg-name-chars = ALPHA / DIGIT / "!" / + "#" / "$" / "&" / "." / + "+" / "-" / "^" / "_" + + Note that this syntax is somewhat more restrictive than what is + allowed by the ABNF in [RFC2045]. + + In accordance with the rules specified in [RFC3023], media subtypes + that do not represent XML entities MUST NOT be given a name that ends + with the "+xml" suffix. More generally, "+suffix" constructs should + be used with care, given the possibility of conflicts with future + suffix definitions. + + While it is possible for a given media type to be assigned additional + names, the use of different names to identify the same media type is + discouraged. + + These requirements apply regardless of the registration tree + involved. + + The choice of top-level type name MUST take into account the nature + of media type involved. New subtypes of top-level types MUST conform + to the restrictions of the top-level type, if any. The following + sections describe each of the initial set of top-level types and + their associated restrictions. Additionally, various protocols, + including but not limited to MIME, MAY impose additional restrictions + on the media types they can transport. (See [RFC2046] for additional + information on the restrictions MIME imposes.) + +4.2.1. Text Media Types + + The "text" media type is intended for sending material that is + principally textual in form. A "charset" parameter MAY be used to + indicate the charset of the body text for "text" subtypes, notably + including the subtype "text/plain", which is a generic subtype for + plain text defined in [RFC2046]. If defined, a text "charset" + + + + +Freed & Klensin Best Current Practice [Page 7] + +RFC 4288 Media Type Registration December 2005 + + + parameter MUST be used to specify a charset name defined in + accordance to the procedures laid out in [RFC2978]. + + Plain text does not provide for or allow formatting commands, font + attribute specifications, processing instructions, interpretation + directives, or content markup. Plain text is seen simply as a linear + + sequence of characters, possibly interrupted by line breaks or page + breaks. Plain text MAY allow the stacking of several characters in + the same position in the text. Plain text in scripts like Arabic and + Hebrew may also include facilities that allow the arbitrary mixing of + text segments with opposite writing directions. + + Beyond plain text, there are many formats for representing what might + be known as "rich text". An interesting characteristic of many such + representations is that they are to some extent readable even without + the software that interprets them. It is useful to distinguish them, + at the highest level, from such unreadable data as images, audio, or + text represented in an unreadable form. In the absence of + appropriate interpretation software, it is reasonable to present + subtypes of "text" to the user, while it is not reasonable to do so + with most non-textual data. Such formatted textual data should be + represented using subtypes of "text". + +4.2.2. Image Media Types + + A media type of "image" indicates that the content specifies or more + separate images that require appropriate hardware to display. The + subtype names the specific image format. + +4.2.3. Audio Media Types + + A media type of "audio" indicates that the content contains audio + data. + +4.2.4. Video Media Types + + A media type of "video" indicates that the content specifies a time- + varying-picture image, possibly with color and coordinated sound. + The term 'video' is used in its most generic sense, rather than with + reference to any particular technology or format, and is not meant to + preclude subtypes such as animated drawings encoded compactly. + + Note that although in general this document strongly discourages the + mixing of multiple media in a single body, it is recognized that many + so-called video formats include a representation for synchronized + audio and/or text, and this is explicitly permitted for subtypes of + "video". + + + +Freed & Klensin Best Current Practice [Page 8] + +RFC 4288 Media Type Registration December 2005 + + +4.2.5. Application Media Types + + The "application" media type is to be used for discrete data that do + not fit in any of the media types, and particularly for data to be + processed by some type of application program. This is information + that must be processed by an application before it is viewable or + usable by a user. Expected uses for the "application" media type + include but are not limited to file transfer, spreadsheets, + presentations, scheduling data, and languages for "active" + (computational) material. (The latter, in particular, can pose + security problems that must be understood by implementors, and are + considered in detail in the discussion of the "application/ + PostScript" media type in [RFC2046].) + + For example, a meeting scheduler might define a standard + representation for information about proposed meeting dates. An + intelligent user agent would use this information to conduct a dialog + with the user, and might then send additional material based on that + dialog. More generally, there have been several "active" languages + developed in which programs in a suitably specialized language are + transported to a remote location and automatically run in the + recipient's environment. Such applications may be defined as + subtypes of the "application" media type. + + The subtype of "application" will often be either the name or include + part of the name of the application for which the data are intended. + This does not mean, however, that any application program name may be + used freely as a subtype of "application". + +4.2.6. Multipart and Message Media Types + + Multipart and message are composite types, that is, they provide a + means of encapsulating zero or more objects, each labeled with its + own media type. + + All subtypes of multipart and message MUST conform to the syntax + rules and other requirements specified in [RFC2046]. + +4.2.7. Additional Top-level Types + + In some cases a new media type may not "fit" under any currently + defined top-level content type. Such cases are expected to be quite + rare. However, if such a case does arise a new top-level type can be + defined to accommodate it. Such a definition MUST be done via + standards-track RFC; no other mechanism can be used to define + additional top-level content types. + + + + + +Freed & Klensin Best Current Practice [Page 9] + +RFC 4288 Media Type Registration December 2005 + + +4.3. Parameter Requirements + + Media types MAY elect to use one or more media type parameters, or + some parameters may be automatically made available to the media type + by virtue of being a subtype of a content type that defines a set of + parameters applicable to any of its subtypes. In either case, the + names, values, and meanings of any parameters MUST be fully specified + + when a media type is registered in the standards tree, and SHOULD be + specified as completely as possible when media types are registered + in the vendor or personal trees. + + Parameter names have the syntax as media type names and values: + + parameter-name = reg-name + + Note that this syntax is somewhat more restrictive than what is + allowed by the ABNF in [RFC2045] and amended by [RFC2231]. + + There is no defined syntax for parameter values. Therefore + registrations MUST specify parameter value syntax. Additionally, + some transports impose restrictions on parameter value syntax, so + care should be taken to limit the use of potentially problematic + syntaxes; e.g., pure binary valued parameters, while permitted in + some protocols, probably should be avoided. + + New parameters SHOULD NOT be defined as a way to introduce new + functionality in types registered in the standards tree, although new + parameters MAY be added to convey additional information that does + not otherwise change existing functionality. An example of this + would be a "revision" parameter to indicate a revision level of an + external specification such as JPEG. Similar behavior is encouraged + for media types registered in the vendor or personal trees but is not + required. + +4.4. Canonicalization and Format Requirements + + All registered media types MUST employ a single, canonical data + format, regardless of registration tree. + + A precise and openly available specification of the format of each + media type MUST exist for all types registered in the standards tree + and MUST at a minimum be referenced by, if it isn't actually included + in, the media type registration proposal itself. + + The specifications of format and processing particulars may or may + not be publicly available for media types registered in the vendor + tree, and such registration proposals are explicitly permitted to + + + +Freed & Klensin Best Current Practice [Page 10] + +RFC 4288 Media Type Registration December 2005 + + + limit specification to which software and version produce or process + such media types. References to or inclusion of format + specifications in registration proposals is encouraged but not + required. + + Format specifications are still required for registration in the + personal tree, but may be either published as RFCs or otherwise + deposited with the IANA. The deposited specifications will meet the + same criteria as those required to register a well-known TCP port + and, in particular, need not be made public. + + Some media types involve the use of patented technology. The + registration of media types involving patented technology is + specifically permitted. However, the restrictions set forth in + [RFC2026] on the use of patented technology in IETF standards-track + protocols must be respected when the specification of a media type is + part of a standards-track protocol. In addition, other standards + bodies making use of the standards tree may have their own rules + regarding intellectual property that must be observed in their + registrations. + +4.5. Interchange Recommendations + + Media types SHOULD interoperate across as many systems and + applications as possible. However, some media types will inevitably + have problems interoperating across different platforms. Problems + with different versions, byte ordering, and specifics of gateway + handling can and will arise. + + Universal interoperability of media types is not required, but known + interoperability issues SHOULD be identified whenever possible. + Publication of a media type does not require an exhaustive review of + interoperability, and the interoperability considerations section is + subject to continuing evaluation. + + These recommendations apply regardless of the registration tree + involved. + +4.6. Security Requirements + + An analysis of security issues MUST be done for all types registered + in the standards Tree. A similar analysis for media types registered + in the vendor or personal trees is encouraged but not required. + However, regardless of what security analysis has or has not been + done, all descriptions of security issues MUST be as accurate as + possible regardless of registration tree. In particular, a statement + that there are "no security issues associated with this type" MUST + + + + +Freed & Klensin Best Current Practice [Page 11] + +RFC 4288 Media Type Registration December 2005 + + + NOT be confused with "the security issues associates with this type + have not been assessed". + + There is absolutely no requirement that media types registered in any + tree be secure or completely free from risks. Nevertheless, all + known security risks MUST be identified in the registration of a + media type, again regardless of registration tree. + + The security considerations section of all registrations is subject + to continuing evaluation and modification, and in particular MAY be + extended by use of the "comments on media types" mechanism described + in Section 6 below. + + Some of the issues that should be looked at in a security analysis of + a media type are: + + o Complex media types may include provisions for directives that + institute actions on a recipient's files or other resources. In + many cases provision is made for originators to specify arbitrary + actions in an unrestricted fashion that may then have devastating + effects. See the registration of the application/postscript media + type in [RFC2046] for an example of such directives and how they + should be described in a media type registration. + + o All registrations MUST state whether or not they employ such + "active content", and if they do, they MUST state what steps have + been taken to protect users of the media type from harm. + + o Complex media types may include provisions for directives that + institute actions that, while not directly harmful to the + recipient, may result in disclosure of information that either + facilitates a subsequent attack or else violates a recipient's + privacy in some way. Again, the registration of the + application/postscript media type illustrates how such directives + can be handled. + + o A media type that employs compression may provide an opportunity + for sending a small amount of data that, when received and + evaluated, expands enormously to consume all of the recipient's + resources. All media types SHOULD state whether or not they + employ compression, and if they do they should discuss what steps + need to be taken to avoid such attacks. + + o A media type might be targeted for applications that require some + sort of security assurance but not provide the necessary security + mechanisms themselves. For example, a media type could be defined + for storage of confidential medical information that in turn + + + + +Freed & Klensin Best Current Practice [Page 12] + +RFC 4288 Media Type Registration December 2005 + + + requires an external confidentiality service, or which is designed + for use only within a secure environment. + +4.7. Requirements specific to XML media types + + There are a number of additional requirements specific to the + registration of XML media types. These requirements are specified in + [RFC3023]. + +4.8. Encoding Requirements + + Some transports impose restrictions on the type of data they can + carry. For example, Internet mail traditionally was limited to 7bit + US-ASCII text. Encoding schemes are often used to work around such + transport limitations. + + It is therefore useful to note what sort of data a media type can + consist of as part of its registration. An "encoding considerations" + field is provided for this purpose. Possible values of this field + are: + + 7bit: The content of the media type consists solely of CRLF-delimited + 7bit US-ASCII text. + + 8bit: The content of the media type consists solely of CRLF-delimited + 8bit text. + + binary: The content consists of unrestricted sequence of octets. + + framed: The content consists of a series of frames or packets without + internal framing or alignment indicators. Additional out-of-band + information is needed to interpret the data properly, including + but not necessarily limited to, knowledge of the boundaries + between successive frames and knowledge of the transport + mechanism. Note that media types of this sort cannot simply be + stored in a file or transported as a simple stream of octets; + therefore, such media types are unsuitable for use in many + traditional protocols. A commonly used transport with framed + encoding is the Real-time Transport Protocol, RTP. Additional + rules for framed encodings defined for transport using RTP are + given in [RFC3555]. + + Additional restrictions on 7bit and 8bit text are given in [RFC2046]. + +4.9. Usage and Implementation Non-requirements + + In the asynchronous mail environment, where information on the + capabilities of the remote mail agent is frequently not available to + + + +Freed & Klensin Best Current Practice [Page 13] + +RFC 4288 Media Type Registration December 2005 + + + the sender, maximum interoperability is attained by restricting the + media types used to those "common" formats expected to be widely + implemented. This was asserted in the past as a reason to limit the + number of possible media types, and it resulted in a registration + process with a significant hurdle and delay for those registering + media types. + + However, the need for "common" media types does not require limiting + the registration of new media types. If a limited set of media types + is recommended for a particular application, that should be asserted + by a separate applicability statement specific for the application + and/or environment. + + Therefore, universal support and implementation of a media type is + NOT a requirement for registration. However, if a media type is + explicitly intended for limited use, this MUST be noted in its + registration. The "Restrictions on Usage" field is provided for this + purpose. + +4.10. Publication Requirements + + Proposals for media types registered in the standards tree by the + IETF itself MUST be published as RFCs. RFC publication of vendor and + personal media type proposals is encouraged but not required. In all + cases the IANA will retain copies of all media type proposals and + "publish" them as part of the media types registration tree itself. + + As stated previously, standards tree registrations for media types + defined in documents produced by other standards bodies MUST be + described by a formal standards specification produced by that body. + Such specifications MUST contain an appropriate media type + registration template taken from Section 10. Additionally, the + copyright on the registration template MUST allow the IANA to copy it + into the IANA registry. + + Other than IETF registrations in the standards tree, the registration + of a data type does not imply endorsement, approval, or + recommendation by the IANA or the IETF or even certification that the + specification is adequate. To become Internet Standards, a protocol + or data object must go through the IETF standards process. This is + too difficult and too lengthy a process for the convenient + registration of media types. + + The standards tree exists for media types that do require a + substantive review and approval process in a recognized standards + body. The vendor and personal trees exist for those media types that + do not require such a process. It is expected that applicability + statements for particular applications will be published from time to + + + +Freed & Klensin Best Current Practice [Page 14] + +RFC 4288 Media Type Registration December 2005 + + + time in the IETF, recommending implementation of, and support for, + media types that have proven particularly useful in those contexts. + + As discussed above, registration of a top-level type requires + standards-track processing in the IETF and, hence, RFC publication. + +4.11. Additional Information + + Various sorts of optional information SHOULD be included in the + specification of a media type if it is available: + + o Magic number(s) (length, octet values). Magic numbers are byte + sequences that are always present at a given place in the file and + thus can be used to identify entities as being of a given media + type. + + o File name extension(s) commonly used on one or more platforms to + indicate that some file contains a given media type. + + o Mac OS File Type code(s) (4 octets) used to label files containing + a given media type. + + o Information about how fragment/anchor identifiers [RFC3986] are + constructed for use in conjunction with this media type. + + In the case of a registration in the standards tree, this additional + information MAY be provided in the formal specification of the media + type. It is suggested that this be done by incorporating the IANA + media type registration form into the specification itself. + +5. Registration Procedure + + The media type registration procedure is not a formal standards + process, but rather an administrative procedure intended to allow + community comment and sanity checking without excessive time delay. + + The normal IETF processes should be followed for all IETF + registrations in the standards tree. The posting of an Internet + Draft is a necessary first step, followed by posting to the + ietf-types@iana.org list as discussed below. + + Registrations in the vendor and personal tree should be submitted + directly to the IANA, ideally after first posting to the + ietf-types@iana.org list for review. + + Proposed registrations in the standards tree by other standards + bodies should be communicated to the IESG (at iesg@ietf.org) and to + the ietf-types list (at ietf-types@iana.org). Prior posting as an + + + +Freed & Klensin Best Current Practice [Page 15] + +RFC 4288 Media Type Registration December 2005 + + + Internet Draft is not required for these registrations, but may be + helpful to the IESG and is encouraged. + +5.1. Preliminary Community Review + + Notice of a potential media type registration in the standards tree + MUST be sent to the "ietf-types@iana.org" mailing list for review. + This mailing list has been established for the purpose of reviewing + proposed media and access types. Registrations in other trees MAY be + sent to the list for review as well. + + The intent of the public posting to this list is to solicit comments + and feedback on the choice of type/subtype name, the unambiguity of + the references with respect to versions and external profiling + information, and a review of any interoperability or security + considerations. The submitter may submit a revised registration or + abandon the registration completely and at any time. + +5.2. IESG Approval + + Media types registered in the standards tree MUST be approved by the + IESG prior to registration. + +5.3. IANA Registration + + Provided that the media type meets all of the relevant requirements + and has obtained whatever approval is necessary, the author may + submit the registration request to the IANA. Registration requests + can be sent to iana@iana.org. A web form for registration requests + is also available: + + http://www.iana.org/cgi-bin/mediatypes.pl + + Sending to ietf-types@iana.org does not constitute submitting the + registration to the IANA. + + When the registration is either part of an RFC publication request or + a registration in the standards tree submitted to the IESG, close + coordination between the IANA and the IESG means IESG approval in + effect submits the registration to the IANA. There is no need for an + additional registration request in such cases. + +5.4. Media Types Reviewer + + Registrations submitted to the IANA will be passed on to the media + types reviewer. The media types reviewer, who is appointed by the + IETF Applications Area Director(s), will review the registration to + make sure it meets the requirements set forth in this document. + + + +Freed & Klensin Best Current Practice [Page 16] + +RFC 4288 Media Type Registration December 2005 + + + Registrations that do not meet these requirements will be returned to + the submitter for revision. + + Decisions made by the media types reviewer may be appealed to the + IESG using the procedure specified in [RFC2026] section 6.5.4. + + Once a media type registration has passed review, the IANA will + register the media type and make the media type registration + available to the community. + +6. Comments on Media Type Registrations + + Comments on registered media types may be submitted by members of the + community to the IANA. These comments will be reviewed by the media + types reviewer and then passed on to the "owner" of the media type if + possible. Submitters of comments may request that their comment be + attached to the media type registration itself, and if the IANA + approves of this, the comment will be made accessible in conjunction + with the type registration. + +7. Location of Registered Media Type List + + Media type registrations are listed by the IANA at: + + http://www.iana.org/assignments/media-types/ + +8. IANA Procedures for Registering Media Types + + The IANA will only register media types in the standards tree in + response to a communication from the IESG stating that a given + registration has been approved. Vendor and personal types will be + registered by the IANA automatically and without any formal approval + process as long as the following minimal conditions are met: + + o Media types MUST function as an actual media format. In + particular, charsets and transfer encodings MUST NOT be registered + as media types. + + o All media types MUST have properly formed type and subtype names. + All type names MUST be defined by a standards-track RFC. All + type/subtype name pairs MUST be unique and MUST contain the proper + tree prefix. + + o Types registered in the personal tree MUST either provide a format + specification or a pointer to one. + + + + + + +Freed & Klensin Best Current Practice [Page 17] + +RFC 4288 Media Type Registration December 2005 + + + o All media types MUST have a reasonable security considerations + section. (It is neither possible nor necessary for the IANA to + conduct a comprehensive security review of media type + registrations. Nevertheless, the IANA has the authority to + identify obviously incompetent material and return it to the + submitter for revision.) + + Registrations in the standards tree MUST satisfy the additional + requirement that they originate from the IETF itself or from another + standards body recognized as such by the IETF. + +9. Change Procedures + + Once a media type has been published by the IANA, the owner may + request a change to its definition. The descriptions of the + different registration trees above designate the "owners" of each + type of registration. The same procedure that would be appropriate + for the original registration request is used to process a change + request. + + Changes should be requested only when there are serious omissions or + errors in the published specification. When review is required, a + change request may be denied if it renders entities that were valid + under the previous definition invalid under the new definition. + + The owner of a media type may pass responsibility to another person + or agency by informing the IANA and the ietf-types list; this can be + done without discussion or review. + + The IESG may reassign responsibility for a media type. The most + common case of this will be to enable changes to be made to types + where the author of the registration has died, moved out of contact + or is otherwise unable to make changes that are important to the + community. + + Media type registrations may not be deleted; media types that are no + longer believed appropriate for use can be declared OBSOLETE by a + change to their "intended use" field; such media types will be + clearly marked in the lists published by the IANA. + + + + + + + + + + + + +Freed & Klensin Best Current Practice [Page 18] + +RFC 4288 Media Type Registration December 2005 + + +10. Registration Template + + To: ietf-types@iana.org + Subject: Registration of media type XXX/YYY + + Type name: + + Subtype name: + + Required parameters: + + Optional parameters: + + Encoding considerations: + + Security considerations: + + Interoperability considerations: + + Published specification: + + Applications that use this media type: + + Additional information: + + Magic number(s): + File extension(s): + Macintosh file type code(s): + + Person & email address to contact for further information: + + Intended usage: + + (One of COMMON, LIMITED USE or OBSOLETE.) + + Restrictions on usage: + + (Any restrictions on where the media type can be used go here.) + + Author: + + Change controller: + + (Any other information that the author deems interesting may be added + below this line.) + + Some discussion of Macintosh file type codes and their purpose can be + found in [MacOSFileTypes]. Additionally, please refrain from writing + + + +Freed & Klensin Best Current Practice [Page 19] + +RFC 4288 Media Type Registration December 2005 + + + "none" or anything similar when no file extension or Macintosh file + type is specified, lest "none" be confused with an actual code value. + +11. Security Considerations + + Security requirements for media type registrations are discussed in + Section 4.6. + +12. IANA Considerations + + The purpose of this document is to define IANA registries for media + types. + +13. Acknowledgements + + The current authors would like to acknowledge their debt to the late + Dr. Jon Postel, whose general model of IANA registration procedures + and specific contributions shaped the predecessors of this document + [RFC2048]. We hope that the current version is one with which he + would have agreed but, as it is impossible to verify that agreement, + we have regretfully removed his name as a co-author. + +14. References + +14.1. Normative References + + [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet + Mail Extensions (MIME) Part One: Format of Internet + Message Bodies", RFC 2045, November 1996. + + [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet + Mail Extensions (MIME) Part Two: Media Types", RFC + 2046, November 1996. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2978] Freed, N. and J. Postel, "IANA Charset Registration + Procedures", BCP 19, RFC 2978, October 2000. + + [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media + Types", RFC 3023, January 2001. + + [RFC3555] Casner, S. and P. Hoschka, "MIME Type Registration + of RTP Payload Formats", RFC 3555, July 2003. + + + + + + +Freed & Klensin Best Current Practice [Page 20] + +RFC 4288 Media Type Registration December 2005 + + + [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, + "Uniform Resource Identifier (URI): Generic Syntax", + STD 66, RFC 3986, January 2005. + + [RFC4234] Crocker, D. Ed., and P. Overell, "Augmented BNF for + Syntax Specifications: ABNF", RFC 4234, October + 2005. + +14.2. Informative References + + [MacOSFileTypes] Apple Computer, Inc., "Mac OS: File Type and Creator + Codes, and File Formats", Apple Knowledge Base + Article 55381, June 1993, + . + + [RFC2026] Bradner, S., "The Internet Standards Process -- + Revision 3", BCP 9, RFC 2026, October 1996. + + [RFC2048] Freed, N., Klensin, J., and J. Postel, "Multipurpose + Internet Mail Extensions (MIME) Part Four: + Registration Procedures", BCP 13, RFC 2048, November + 1996. + + [RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and + Encoded Word Extensions: Character Sets, Languages, + and Continuations", RFC 2231, November 1997. + + + + + + + + + + + + + + + + + + + + + + + + + +Freed & Klensin Best Current Practice [Page 21] + +RFC 4288 Media Type Registration December 2005 + + +Appendix A. Grandfathered Media Types + + A number of media types, registered prior to 1996, would, if + registered under the guidelines in this document, be placed into + either the vendor or personal trees. Reregistration of those types + to reflect the appropriate trees is encouraged but not required. + Ownership and change control principles outlined in this document + apply to those types as if they had been registered in the trees + described above. + +Appendix B. Changes Since RFC 2048 + + o Media type specification and registration procedures have been + moved out of the MIME document set to this separate specification. + + o The various URLs and addresses in this document have been changed + so they all refer to iana.org rather than isi.edu. Additionally, + many of the URLs have been changed to use HTTP; formerly they used + FTP. + + o Much of the document has been clarified in the light of + operational experience with these procedures. + + o The unfaceted IETF tree is now called the standards tree, and the + registration rules for this tree have been relaxed to allow use by + other standards bodies. + + o The text describing the media type registration procedure has + clarified. + + o The rules and requirements for constructing security + considerations sections have been extended and clarified. + + o RFC 3023 is now referenced as the source of additional information + concerning the registration of XML media types. + + o Several of the references in this document have been updated to + refer to current versions of the relevant specifications. + + o A note has been added discouraging the assignment of multiple + names to a single media type. + + o Security considerations and IANA considerations sections have been + added. + + + + + + + +Freed & Klensin Best Current Practice [Page 22] + +RFC 4288 Media Type Registration December 2005 + + + o Concerns regarding copyrights on media type registration templates + produced by other standards bodies have been dealt with by + requiring that the IANA be allowed to copy the registration + template into the registry. + + o The basic registration requirements for the various top-level + types have been moved from RFC 2046 to this document. + + o A syntax is now specified for media type, subtype, and parameter + names. + + o Imposed a maximum length of 127 on all media type and subtype + names. + + o A note has been added to caution against excessive use of + "+suffix" constructs in subtype names. + + o The encoding considerations field has been extended to allow the + value "framed". + + o A reference describing Macintosh Type codes has been added. + + o Ietf-types list review of registrations in the standards tree is + now required rather than just recommended. + + +Authors' Addresses + + Ned Freed + Sun Microsystems + 3401 Centrelake Drive, Suite 410 + Ontario, CA 92761-1205 + USA + + Phone: +1 909 457 4293 + EMail: ned.freed@mrochek.com + + + John C. Klensin + 1770 Massachusetts Ave, #322 + Cambridge, MA 02140 + + EMail: klensin+ietf@jck.com + + + + + + + + +Freed & Klensin Best Current Practice [Page 23] + +RFC 4288 Media Type Registration December 2005 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2005). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at ietf- + ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + +Freed & Klensin Best Current Practice [Page 24] + diff --git a/RFCs/rfc4289.txt b/RFCs/rfc4289.txt new file mode 100644 index 0000000..4ba25c0 --- /dev/null +++ b/RFCs/rfc4289.txt @@ -0,0 +1,619 @@ + + + + + + +Network Working Group N. Freed +Request for Comments: 4289 Sun Microsystems +BCP: 13 J. Klensin +Obsoletes: 2048 December 2005 +Category: Best Current Practice + + + Multipurpose Internet Mail Extensions (MIME) Part Four: + Registration Procedures + +Status of This Memo + + This document specifies an Internet Best Current Practices for the + Internet Community, and requests discussion and suggestions for + improvements. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2005). + +Abstract + + This document specifies IANA registration procedures for MIME + external body access types and content-transfer-encodings. + + + + + + + + + + + + + + + + + + + + + + + + + + + +Freed & Klensin Best Current Practice [Page 1] + +RFC 4289 MIME Registration December 2005 + + +Table of Contents + + 1. Introduction ....................................................2 + 2. External Body Access Types ......................................3 + 2.1. Registration Requirements ..................................3 + 2.1.1. Naming Requirements ...................................3 + 2.1.2. Mechanism Specification Requirements ..................3 + 2.1.3. Publication Requirements ..............................4 + 2.1.4. Security Requirements .................................4 + 2.2. Registration Procedure .....................................4 + 2.2.1. Present the Access Type to the Community ..............4 + 2.2.2. Access Type Reviewer ..................................4 + 2.2.3. IANA Registration .....................................5 + 2.3. Location of Registered Access Type List ....................5 + 2.4. IANA Procedures for Registering Access Types ...............5 + 3. Transfer Encodings ..............................................5 + 3.1. Transfer Encoding Requirements .............................6 + 3.1.1. Naming Requirements ...................................6 + 3.1.2. Algorithm Specification Requirements ..................6 + 3.1.3. Input Domain Requirements .............................6 + 3.1.4. Output Range Requirements .............................6 + 3.1.5. Data Integrity and Generality Requirements ............7 + 3.1.6. New Functionality Requirements ........................7 + 3.1.7. Security Requirements .................................7 + 3.2. Transfer Encoding Definition Procedure .....................7 + 3.3. IANA Procedures for Transfer Encoding Registration .........8 + 3.4. Location of Registered Transfer Encodings List .............8 + 4. Security Considerations .........................................8 + 5. IANA Considerations .............................................8 + 6. Acknowledgements ................................................8 + 7. References ......................................................9 + A. Changes Since RFC 2048 .........................................9 + +1. Introduction + + Recent Internet protocols have been carefully designed to be easily + extensible in certain areas. In particular, MIME [RFC2045] is an + open-ended framework and can accommodate additional object types, + charsets, and access methods without any changes to the basic + protocol. A registration process is needed, however, to ensure that + the set of such values is developed in an orderly, well-specified, + and public manner. + + This document defines registration procedures that use the Internet + Assigned Numbers Authority (IANA) as a central registry for these + values. + + + + + +Freed & Klensin Best Current Practice [Page 2] + +RFC 4289 MIME Registration December 2005 + + + Note: + + Registration of media types and charsets for use in MIME are + specified in separate documents [RFC4288] [RFC2978] and are not + addressed here. + +1.1. Conventions Used in This Document + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [RFC2119]. + +2. External Body Access Types + + [RFC2046] defines the message/external-body media type, whereby a + MIME entity can act as pointer to the actual body data in lieu of + including the data directly in the entity body. Each + message/external-body reference specifies an access type, which + determines the mechanism used to retrieve the actual body data. RFC + 2046 defines an initial set of access types but allows for the + registration of additional access types to accommodate new retrieval + mechanisms. + +2.1. Registration Requirements + + New access type specifications MUST conform to the requirements + described below. + +2.1.1. Naming Requirements + + Each access type MUST have a unique name. This name appears in the + access-type parameter in the message/external-body content-type + header field and MUST conform to MIME content type parameter syntax. + +2.1.2. Mechanism Specification Requirements + + All of the protocols, transports, and procedures used by a given + access type MUST be described, either in the specification of the + access type itself or in some other publicly available specification, + in sufficient detail for the access type to be implemented by any + competent implementor. Use of secret and/or proprietary methods in + access types is expressly prohibited. The restrictions imposed by + [RFC2026] on the standardization of patented algorithms must be + respected as well. + + + + + + + +Freed & Klensin Best Current Practice [Page 3] + +RFC 4289 MIME Registration December 2005 + + +2.1.3. Publication Requirements + + All access types MUST be described by an RFC. The RFC may be + informational rather than standards-track, although standards-track + review and approval are encouraged for all access types. + +2.1.4. Security Requirements + + Any known security issues that arise from the use of the access type + MUST be completely and fully described. It is not required that the + access type be secure or that it be free from risks, but it is + required that the known risks be identified. Publication of a new + access type does not require an exhaustive security review, and the + security considerations section is subject to continuing evaluation. + Additional security considerations SHOULD be addressed by publishing + revised versions of the access type specification. + +2.2. Registration Procedure + + Registration of a new access type starts with the publication of the + specification as an Internet Draft. + +2.2.1. Present the Access Type to the Community + + A proposed access type specification is sent to the + "ietf-types@iana.org" mailing list for a two-week review period. + This mailing list has been established for the purpose of reviewing + proposed access and media types. Proposed access types are not + formally registered and must not be used. + + The intent of the public posting is to solicit comments and feedback + on the access type specification and a review of any security + considerations. + +2.2.2. Access Type Reviewer + + When the two-week period has passed, the access type reviewer, who is + appointed by the IETF Applications Area Director(s), either forwards + the request to iana@iana.org or rejects it because of significant + objections raised on the list. + + Decisions made by the reviewer must be posted to the ietf-types + mailing list within 14 days. Decisions made by the reviewer may be + appealed to the IESG as specified in [RFC2026]. + + + + + + + +Freed & Klensin Best Current Practice [Page 4] + +RFC 4289 MIME Registration December 2005 + + +2.2.3. IANA Registration + + Provided that the access type either has passed review or has been + successfully appealed to the IESG, the IANA will register the access + type and make the registration available to the community. The + specification of the access type must also be published as an RFC. + +2.3. Location of Registered Access Type List + + Access type registrations are listed by the IANA on the following web + page: + + http://www.iana.org/assignments/access-types + +2.4. IANA Procedures for Registering Access Types + + The identity of the access type reviewer is communicated to the IANA + by the IESG. The IANA then only acts either in response to access + type definitions that are approved by the access type reviewer and + forwarded to the IANA for registration, or in response to a + communication from the IESG that an access type definition appeal has + overturned the access type reviewer's ruling. + +3. Transfer Encodings + + Transfer encodings are transformations applied to MIME media types + after conversion to the media type's canonical form. Transfer + encodings are used for several purposes: + + o Many transports, especially message transports, can only handle + data consisting of relatively short lines of text. There can be + severe restrictions on what characters can be used in these lines + of text. Some transports are restricted to a small subset of US- + ASCII, and others cannot handle certain character sequences. + Transfer encodings are used to transform binary data into a + textual form that can survive such transports. Examples of this + sort of transfer encoding include the base64 and quoted-printable + transfer encodings defined in [RFC2045]. + + o Image, audio, video, and even application entities are sometimes + quite large. Compression algorithms are often effective in + reducing the size of large entities. Transfer encodings can be + used to apply general-purpose non-lossy compression algorithms to + MIME entities. + + o Transport encodings can be defined as a means of representing + existing encoding formats in a MIME context. + + + + +Freed & Klensin Best Current Practice [Page 5] + +RFC 4289 MIME Registration December 2005 + + + IMPORTANT: The standardization of a large number of different + transfer encodings is seen as a significant barrier to widespread + interoperability and is expressly discouraged. Nevertheless, the + following procedure has been defined in order to provide a means of + defining additional transfer encodings, should standardization + actually be justified. + +3.1. Transfer Encoding Requirements + + Transfer encoding specifications MUST conform to the requirements + described below. + +3.1.1. Naming Requirements + + Each transfer encoding MUST have a unique name. This name appears in + the Content-Transfer-Encoding header field and MUST conform to the + syntax of that field. + +3.1.2. Algorithm Specification Requirements + + All of the algorithms used in a transfer encoding (e.g., conversion + to printable form, compression) MUST be described in their entirety + in the transfer encoding specification. Use of secret and/or + + proprietary algorithms in standardized transfer encodings is + expressly prohibited. The restrictions imposed by [RFC2026] on the + standardization of patented algorithms MUST be respected as well. + +3.1.3. Input Domain Requirements + + All transfer encodings MUST be applicable to an arbitrary sequence of + octets of any length. Dependence on particular input forms is not + allowed. + + It should be noted that the 7bit and 8bit encodings do not conform to + this requirement. Aside from the undesirability of having + specialized encodings, the intent here is to forbid the addition of + additional encodings similar to, or redundant with, 7bit and 8bit. + +3.1.4. Output Range Requirements + + There is no requirement that a particular transfer encoding produce a + particular form of encoded output. However, the output format for + each transfer encoding MUST be fully and completely documented. In + particular, each specification MUST clearly state whether the output + format always lies within the confines of 7bit or 8bit or is simply + pure binary data. + + + + +Freed & Klensin Best Current Practice [Page 6] + +RFC 4289 MIME Registration December 2005 + + +3.1.5. Data Integrity and Generality Requirements + + All transfer encodings MUST be fully invertible on any platform; it + MUST be possible for anyone to recover the original data by + performing the corresponding decoding operation. Note that this + requirement effectively excludes all forms of lossy compression as + well as all forms of encryption from use as a transfer encoding. + +3.1.6. New Functionality Requirements + + All transfer encodings MUST provide some sort of new functionality. + Some degree of functionality overlap with previously defined transfer + encodings is acceptable, but any new transfer encoding MUST also + offer something no other transfer encoding provides. + +3.1.7. Security Requirements + + To the greatest extent possible, transfer encodings SHOULD NOT + contain known security issues. Regardless, any known security issues + that arise from the use of the transfer encoding MUST be completely + and fully described. If additional security issues come to light + after initial publication and registration, they SHOULD be addressed + by publishing revised versions of the transfer encoding + specification. + +3.2. Transfer Encoding Definition Procedure + + Definition of a new transfer encoding starts with the publication of + the specification as an Internet Draft. The draft MUST define the + transfer encoding precisely and completely, and it MUST also provide + substantial justification for defining and standardizing a new + transfer encoding. This specification MUST then be presented to the + IESG for consideration. The IESG can: + + o reject the specification outright as being inappropriate for + standardization, + + o assign the specification to an existing IETF working group for + further work, + + o approve the formation of an IETF working group to work on the + specification in accordance with IETF procedures, or + + o accept the specification as-is for processing as an individual + standards-track submission. + + Transfer encoding specifications on the standards track follow normal + IETF rules for standards-track documents. A transfer encoding is + + + +Freed & Klensin Best Current Practice [Page 7] + +RFC 4289 MIME Registration December 2005 + + + considered to be defined and available for use once it is on the + standards track. + +3.3. IANA Procedures for Transfer Encoding Registration + + There is no need for a special procedure for registering Transfer + Encodings with the IANA. All legitimate transfer encoding + registrations MUST appear as a standards-track RFC, so it is the + IESG's responsibility to notify the IANA when a new transfer encoding + has been approved. + +3.4. Location of Registered Transfer Encodings List + + The list of transfer encoding registrations can be found at: + + http://www.iana.org/assignments/transfer-encodings + +4. Security Considerations + + Security requirements for access types are discussed in Section + 2.1.4. Security requirements for transfer encodings are discussed in + Section 3.1.7. + +5. IANA Considerations + + The sole purpose of this document is to define IANA registries for + access types and transfer encodings. The IANA procedures for these + registries are specified in Section 2.4 and Section 3.3 respectively. + +6. Acknowledgements + + The current authors would like to acknowledge their debt to the late + Dr. Jon Postel, whose general model of IANA registration procedures + and specific contributions shaped the predecessors of this document + [RFC2048]. We hope that the current version is one with which he + would have agreed but, as it is impossible to verify that agreement, + we have regretfully removed his name as a co-author. + + + + + + + + + + + + + + +Freed & Klensin Best Current Practice [Page 8] + +RFC 4289 MIME Registration December 2005 + + +7. References + +7.1. Normative References + + [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail + Extensions (MIME) Part One: Format of Internet Message + Bodies", RFC 2045, November 1996. + + [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail + Extensions (MIME) Part Two: Media Types", RFC 2046, + November 1996. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and + Registration Procedures", BCP 13, RFC 4288, December 2005. + +7.2. Informative References + + [RFC2026] Bradner, S., "The Internet Standards Process -- Revision + 3", BCP 9, RFC 2026, October 1996. + + [RFC2048] Freed, N., Klensin, J., and J. Postel, "Multipurpose + Internet Mail Extensions (MIME) Part Four: Registration + Procedures", BCP 13, RFC 2048, November 1996. + + [RFC2978] Freed, N. and J. Postel, "IANA Charset Registration + Procedures", BCP 19, RFC 2978, October 2000. + + + + + + + + + + + + + + + + + + + + + + +Freed & Klensin Best Current Practice [Page 9] + +RFC 4289 MIME Registration December 2005 + + +Appendix A. Changes Since RFC 2048 + + o Media type registration procedures are now described in a separate + document [RFC4288]. + + o The various URLs and addresses in this document have been changed + so they all refer to iana.org rather than isi.edu. Additionally, + many of the URLs have been changed to use HTTP; formerly they used + FTP. + + o Much of the document has been clarified in the light of + operational experience with these procedures. + + o Several of the references in this document have been updated to + refer to current versions of the relevant specifications. + + o The option of assigning the task of working on a new transfer + encoding to an existing working group has been added to the list + of possible actions the IESG can take. + + o Security considerations and IANA considerations sections have been + added. + + o Registration of charsets for use in MIME is specified in [RFC2978] + and is no longer addressed by this document. + +Authors' Addresses + + Ned Freed + Sun Microsystems + 3401 Centrelake Drive, Suite 410 + Ontario, CA 92761-1205 + USA + + Phone: +1 909 457 4293 + EMail: ned.freed@mrochek.com + + + John C. Klensin + 1770 Massachusetts Ave, #322 + Cambridge, MA 02140 + + EMail: klensin+ietf@jck.com + + + + + + + + +Freed & Klensin Best Current Practice [Page 10] + +RFC 4289 MIME Registration December 2005 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2005). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at ietf- + ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + +Freed & Klensin Best Current Practice [Page 11] + diff --git a/RFCs/rfc4880.txt b/RFCs/rfc4880.txt new file mode 100644 index 0000000..a02674a --- /dev/null +++ b/RFCs/rfc4880.txt @@ -0,0 +1,5043 @@ + + + + + + +Network Working Group J. Callas +Request for Comments: 4880 PGP Corporation +Obsoletes: 1991, 2440 L. Donnerhacke +Category: Standards Track IKS GmbH + H. Finney + PGP Corporation + D. Shaw + R. Thayer + November 2007 + + + OpenPGP Message Format + +Status of This Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Abstract + + This document is maintained in order to publish all necessary + information needed to develop interoperable applications based on the + OpenPGP format. It is not a step-by-step cookbook for writing an + application. It describes only the format and methods needed to + read, check, generate, and write conforming packets crossing any + network. It does not deal with storage and implementation questions. + It does, however, discuss implementation issues necessary to avoid + security flaws. + + OpenPGP software uses a combination of strong public-key and + symmetric cryptography to provide security services for electronic + communications and data storage. These services include + confidentiality, key management, authentication, and digital + signatures. This document specifies the message formats used in + OpenPGP. + + + + + + + + + + + + + +Callas, et al Standards Track [Page 1] + +RFC 4880 OpenPGP Message Format November 2007 + + +Table of Contents + + 1. Introduction ....................................................5 + 1.1. Terms ......................................................5 + 2. General functions ...............................................6 + 2.1. Confidentiality via Encryption .............................6 + 2.2. Authentication via Digital Signature .......................7 + 2.3. Compression ................................................7 + 2.4. Conversion to Radix-64 .....................................8 + 2.5. Signature-Only Applications ................................8 + 3. Data Element Formats ............................................8 + 3.1. Scalar Numbers .............................................8 + 3.2. Multiprecision Integers ....................................9 + 3.3. Key IDs ....................................................9 + 3.4. Text .......................................................9 + 3.5. Time Fields ...............................................10 + 3.6. Keyrings ..................................................10 + 3.7. String-to-Key (S2K) Specifiers ............................10 + 3.7.1. String-to-Key (S2K) Specifier Types ................10 + 3.7.1.1. Simple S2K ................................10 + 3.7.1.2. Salted S2K ................................11 + 3.7.1.3. Iterated and Salted S2K ...................11 + 3.7.2. String-to-Key Usage ................................12 + 3.7.2.1. Secret-Key Encryption .....................12 + 3.7.2.2. Symmetric-Key Message Encryption ..........13 + 4. Packet Syntax ..................................................13 + 4.1. Overview ..................................................13 + 4.2. Packet Headers ............................................13 + 4.2.1. Old Format Packet Lengths ..........................14 + 4.2.2. New Format Packet Lengths ..........................15 + 4.2.2.1. One-Octet Lengths .........................15 + 4.2.2.2. Two-Octet Lengths .........................15 + 4.2.2.3. Five-Octet Lengths ........................15 + 4.2.2.4. Partial Body Lengths ......................16 + 4.2.3. Packet Length Examples .............................16 + 4.3. Packet Tags ...............................................17 + 5. Packet Types ...................................................17 + 5.1. Public-Key Encrypted Session Key Packets (Tag 1) ..........17 + 5.2. Signature Packet (Tag 2) ..................................19 + 5.2.1. Signature Types ....................................19 + 5.2.2. Version 3 Signature Packet Format ..................21 + 5.2.3. Version 4 Signature Packet Format ..................24 + 5.2.3.1. Signature Subpacket Specification .........25 + 5.2.3.2. Signature Subpacket Types .................27 + 5.2.3.3. Notes on Self-Signatures ..................27 + 5.2.3.4. Signature Creation Time ...................28 + 5.2.3.5. Issuer ....................................28 + 5.2.3.6. Key Expiration Time .......................28 + + + +Callas, et al Standards Track [Page 2] + +RFC 4880 OpenPGP Message Format November 2007 + + + 5.2.3.7. Preferred Symmetric Algorithms ............28 + 5.2.3.8. Preferred Hash Algorithms .................29 + 5.2.3.9. Preferred Compression Algorithms ..........29 + 5.2.3.10. Signature Expiration Time ................29 + 5.2.3.11. Exportable Certification .................29 + 5.2.3.12. Revocable ................................30 + 5.2.3.13. Trust Signature ..........................30 + 5.2.3.14. Regular Expression .......................31 + 5.2.3.15. Revocation Key ...........................31 + 5.2.3.16. Notation Data ............................31 + 5.2.3.17. Key Server Preferences ...................32 + 5.2.3.18. Preferred Key Server .....................33 + 5.2.3.19. Primary User ID ..........................33 + 5.2.3.20. Policy URI ...............................33 + 5.2.3.21. Key Flags ................................33 + 5.2.3.22. Signer's User ID .........................34 + 5.2.3.23. Reason for Revocation ....................35 + 5.2.3.24. Features .................................36 + 5.2.3.25. Signature Target .........................36 + 5.2.3.26. Embedded Signature .......................37 + 5.2.4. Computing Signatures ...............................37 + 5.2.4.1. Subpacket Hints ...........................38 + 5.3. Symmetric-Key Encrypted Session Key Packets (Tag 3) .......38 + 5.4. One-Pass Signature Packets (Tag 4) ........................39 + 5.5. Key Material Packet .......................................40 + 5.5.1. Key Packet Variants ................................40 + 5.5.1.1. Public-Key Packet (Tag 6) .................40 + 5.5.1.2. Public-Subkey Packet (Tag 14) .............40 + 5.5.1.3. Secret-Key Packet (Tag 5) .................41 + 5.5.1.4. Secret-Subkey Packet (Tag 7) ..............41 + 5.5.2. Public-Key Packet Formats ..........................41 + 5.5.3. Secret-Key Packet Formats ..........................43 + 5.6. Compressed Data Packet (Tag 8) ............................45 + 5.7. Symmetrically Encrypted Data Packet (Tag 9) ...............45 + 5.8. Marker Packet (Obsolete Literal Packet) (Tag 10) ..........46 + 5.9. Literal Data Packet (Tag 11) ..............................46 + 5.10. Trust Packet (Tag 12) ....................................47 + 5.11. User ID Packet (Tag 13) ..................................48 + 5.12. User Attribute Packet (Tag 17) ...........................48 + 5.12.1. The Image Attribute Subpacket .....................48 + 5.13. Sym. Encrypted Integrity Protected Data Packet (Tag 18) ..49 + 5.14. Modification Detection Code Packet (Tag 19) ..............52 + 6. Radix-64 Conversions ...........................................53 + 6.1. An Implementation of the CRC-24 in "C" ....................54 + 6.2. Forming ASCII Armor .......................................54 + 6.3. Encoding Binary in Radix-64 ...............................57 + 6.4. Decoding Radix-64 .........................................58 + 6.5. Examples of Radix-64 ......................................59 + + + +Callas, et al Standards Track [Page 3] + +RFC 4880 OpenPGP Message Format November 2007 + + + 6.6. Example of an ASCII Armored Message .......................59 + 7. Cleartext Signature Framework ..................................59 + 7.1. Dash-Escaped Text .........................................60 + 8. Regular Expressions ............................................61 + 9. Constants ......................................................61 + 9.1. Public-Key Algorithms .....................................62 + 9.2. Symmetric-Key Algorithms ..................................62 + 9.3. Compression Algorithms ....................................63 + 9.4. Hash Algorithms ...........................................63 + 10. IANA Considerations ...........................................63 + 10.1. New String-to-Key Specifier Types ........................64 + 10.2. New Packets ..............................................64 + 10.2.1. User Attribute Types ..............................64 + 10.2.1.1. Image Format Subpacket Types .............64 + 10.2.2. New Signature Subpackets ..........................64 + 10.2.2.1. Signature Notation Data Subpackets .......65 + 10.2.2.2. Key Server Preference Extensions .........65 + 10.2.2.3. Key Flags Extensions .....................65 + 10.2.2.4. Reason For Revocation Extensions .........65 + 10.2.2.5. Implementation Features ..................66 + 10.2.3. New Packet Versions ...............................66 + 10.3. New Algorithms ...........................................66 + 10.3.1. Public-Key Algorithms .............................66 + 10.3.2. Symmetric-Key Algorithms ..........................67 + 10.3.3. Hash Algorithms ...................................67 + 10.3.4. Compression Algorithms ............................67 + 11. Packet Composition ............................................67 + 11.1. Transferable Public Keys .................................67 + 11.2. Transferable Secret Keys .................................69 + 11.3. OpenPGP Messages .........................................69 + 11.4. Detached Signatures ......................................70 + 12. Enhanced Key Formats ..........................................70 + 12.1. Key Structures ...........................................70 + 12.2. Key IDs and Fingerprints .................................71 + 13. Notes on Algorithms ...........................................72 + 13.1. PKCS#1 Encoding in OpenPGP ...............................72 + 13.1.1. EME-PKCS1-v1_5-ENCODE .............................73 + 13.1.2. EME-PKCS1-v1_5-DECODE .............................73 + 13.1.3. EMSA-PKCS1-v1_5 ...................................74 + 13.2. Symmetric Algorithm Preferences ..........................75 + 13.3. Other Algorithm Preferences ..............................76 + 13.3.1. Compression Preferences ...........................76 + 13.3.2. Hash Algorithm Preferences ........................76 + 13.4. Plaintext ................................................77 + 13.5. RSA ......................................................77 + 13.6. DSA ......................................................77 + 13.7. Elgamal ..................................................78 + 13.8. Reserved Algorithm Numbers ...............................78 + + + +Callas, et al Standards Track [Page 4] + +RFC 4880 OpenPGP Message Format November 2007 + + + 13.9. OpenPGP CFB Mode .........................................78 + 13.10. Private or Experimental Parameters ......................79 + 13.11. Extension of the MDC System .............................80 + 13.12. Meta-Considerations for Expansion .......................80 + 14. Security Considerations .......................................81 + 15. Implementation Nits ...........................................84 + 16. References ....................................................86 + 16.1. Normative References .....................................86 + 16.2. Informative References ...................................88 + +1. Introduction + + This document provides information on the message-exchange packet + formats used by OpenPGP to provide encryption, decryption, signing, + and key management functions. It is a revision of RFC 2440, "OpenPGP + Message Format", which itself replaces RFC 1991, "PGP Message + Exchange Formats" [RFC1991] [RFC2440]. + +1.1. Terms + + * OpenPGP - This is a term for security software that uses PGP 5.x + as a basis, formalized in RFC 2440 and this document. + + * PGP - Pretty Good Privacy. PGP is a family of software systems + developed by Philip R. Zimmermann from which OpenPGP is based. + + * PGP 2.6.x - This version of PGP has many variants, hence the term + PGP 2.6.x. It used only RSA, MD5, and IDEA for its cryptographic + transforms. An informational RFC, RFC 1991, was written + describing this version of PGP. + + * PGP 5.x - This version of PGP is formerly known as "PGP 3" in the + community and also in the predecessor of this document, RFC 1991. + It has new formats and corrects a number of problems in the PGP + 2.6.x design. It is referred to here as PGP 5.x because that + software was the first release of the "PGP 3" code base. + + * GnuPG - GNU Privacy Guard, also called GPG. GnuPG is an OpenPGP + implementation that avoids all encumbered algorithms. + Consequently, early versions of GnuPG did not include RSA public + keys. GnuPG may or may not have (depending on version) support + for IDEA or other encumbered algorithms. + + "PGP", "Pretty Good", and "Pretty Good Privacy" are trademarks of PGP + Corporation and are used with permission. The term "OpenPGP" refers + to the protocol described in this and related documents. + + + + + +Callas, et al Standards Track [Page 5] + +RFC 4880 OpenPGP Message Format November 2007 + + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [RFC2119]. + + The key words "PRIVATE USE", "HIERARCHICAL ALLOCATION", "FIRST COME + FIRST SERVED", "EXPERT REVIEW", "SPECIFICATION REQUIRED", "IESG + APPROVAL", "IETF CONSENSUS", and "STANDARDS ACTION" that appear in + this document when used to describe namespace allocation are to be + interpreted as described in [RFC2434]. + +2. General functions + + OpenPGP provides data integrity services for messages and data files + by using these core technologies: + + - digital signatures + + - encryption + + - compression + + - Radix-64 conversion + + In addition, OpenPGP provides key management and certificate + services, but many of these are beyond the scope of this document. + +2.1. Confidentiality via Encryption + + OpenPGP combines symmetric-key encryption and public-key encryption + to provide confidentiality. When made confidential, first the object + is encrypted using a symmetric encryption algorithm. Each symmetric + key is used only once, for a single object. A new "session key" is + generated as a random number for each object (sometimes referred to + as a session). Since it is used only once, the session key is bound + to the message and transmitted with it. To protect the key, it is + encrypted with the receiver's public key. The sequence is as + follows: + + 1. The sender creates a message. + + 2. The sending OpenPGP generates a random number to be used as a + session key for this message only. + + 3. The session key is encrypted using each recipient's public key. + These "encrypted session keys" start the message. + + + + + + +Callas, et al Standards Track [Page 6] + +RFC 4880 OpenPGP Message Format November 2007 + + + 4. The sending OpenPGP encrypts the message using the session key, + which forms the remainder of the message. Note that the message + is also usually compressed. + + 5. The receiving OpenPGP decrypts the session key using the + recipient's private key. + + 6. The receiving OpenPGP decrypts the message using the session key. + If the message was compressed, it will be decompressed. + + With symmetric-key encryption, an object may be encrypted with a + symmetric key derived from a passphrase (or other shared secret), or + a two-stage mechanism similar to the public-key method described + above in which a session key is itself encrypted with a symmetric + algorithm keyed from a shared secret. + + Both digital signature and confidentiality services may be applied to + the same message. First, a signature is generated for the message + and attached to the message. Then the message plus signature is + encrypted using a symmetric session key. Finally, the session key is + encrypted using public-key encryption and prefixed to the encrypted + block. + +2.2. Authentication via Digital Signature + + The digital signature uses a hash code or message digest algorithm, + and a public-key signature algorithm. The sequence is as follows: + + 1. The sender creates a message. + + 2. The sending software generates a hash code of the message. + + 3. The sending software generates a signature from the hash code + using the sender's private key. + + 4. The binary signature is attached to the message. + + 5. The receiving software keeps a copy of the message signature. + + 6. The receiving software generates a new hash code for the received + message and verifies it using the message's signature. If the + verification is successful, the message is accepted as authentic. + +2.3. Compression + + OpenPGP implementations SHOULD compress the message after applying + the signature but before encryption. + + + + +Callas, et al Standards Track [Page 7] + +RFC 4880 OpenPGP Message Format November 2007 + + + If an implementation does not implement compression, its authors + should be aware that most OpenPGP messages in the world are + compressed. Thus, it may even be wise for a space-constrained + implementation to implement decompression, but not compression. + + Furthermore, compression has the added side effect that some types of + attacks can be thwarted by the fact that slightly altered, compressed + data rarely uncompresses without severe errors. This is hardly + rigorous, but it is operationally useful. These attacks can be + rigorously prevented by implementing and using Modification Detection + Codes as described in sections following. + +2.4. Conversion to Radix-64 + + OpenPGP's underlying native representation for encrypted messages, + signature certificates, and keys is a stream of arbitrary octets. + Some systems only permit the use of blocks consisting of seven-bit, + printable text. For transporting OpenPGP's native raw binary octets + through channels that are not safe to raw binary data, a printable + encoding of these binary octets is needed. OpenPGP provides the + service of converting the raw 8-bit binary octet stream to a stream + of printable ASCII characters, called Radix-64 encoding or ASCII + Armor. + + Implementations SHOULD provide Radix-64 conversions. + +2.5. Signature-Only Applications + + OpenPGP is designed for applications that use both encryption and + signatures, but there are a number of problems that are solved by a + signature-only implementation. Although this specification requires + both encryption and signatures, it is reasonable for there to be + subset implementations that are non-conformant only in that they omit + encryption. + +3. Data Element Formats + + This section describes the data elements used by OpenPGP. + +3.1. Scalar Numbers + + Scalar numbers are unsigned and are always stored in big-endian + format. Using n[k] to refer to the kth octet being interpreted, the + value of a two-octet scalar is ((n[0] << 8) + n[1]). The value of a + four-octet scalar is ((n[0] << 24) + (n[1] << 16) + (n[2] << 8) + + n[3]). + + + + + +Callas, et al Standards Track [Page 8] + +RFC 4880 OpenPGP Message Format November 2007 + + +3.2. Multiprecision Integers + + Multiprecision integers (also called MPIs) are unsigned integers used + to hold large integers such as the ones used in cryptographic + calculations. + + An MPI consists of two pieces: a two-octet scalar that is the length + of the MPI in bits followed by a string of octets that contain the + actual integer. + + These octets form a big-endian number; a big-endian number can be + made into an MPI by prefixing it with the appropriate length. + + Examples: + + (all numbers are in hexadecimal) + + The string of octets [00 01 01] forms an MPI with the value 1. The + string [00 09 01 FF] forms an MPI with the value of 511. + + Additional rules: + + The size of an MPI is ((MPI.length + 7) / 8) + 2 octets. + + The length field of an MPI describes the length starting from its + most significant non-zero bit. Thus, the MPI [00 02 01] is not + formed correctly. It should be [00 01 01]. + + Unused bits of an MPI MUST be zero. + + Also note that when an MPI is encrypted, the length refers to the + plaintext MPI. It may be ill-formed in its ciphertext. + +3.3. Key IDs + + A Key ID is an eight-octet scalar that identifies a key. + Implementations SHOULD NOT assume that Key IDs are unique. The + section "Enhanced Key Formats" below describes how Key IDs are + formed. + +3.4. Text + + Unless otherwise specified, the character set for text is the UTF-8 + [RFC3629] encoding of Unicode [ISO10646]. + + + + + + + +Callas, et al Standards Track [Page 9] + +RFC 4880 OpenPGP Message Format November 2007 + + +3.5. Time Fields + + A time field is an unsigned four-octet number containing the number + of seconds elapsed since midnight, 1 January 1970 UTC. + +3.6. Keyrings + + A keyring is a collection of one or more keys in a file or database. + Traditionally, a keyring is simply a sequential list of keys, but may + be any suitable database. It is beyond the scope of this standard to + discuss the details of keyrings or other databases. + +3.7. String-to-Key (S2K) Specifiers + + String-to-key (S2K) specifiers are used to convert passphrase strings + into symmetric-key encryption/decryption keys. They are used in two + places, currently: to encrypt the secret part of private keys in the + private keyring, and to convert passphrases to encryption keys for + symmetrically encrypted messages. + +3.7.1. String-to-Key (S2K) Specifier Types + + There are three types of S2K specifiers currently supported, and + some reserved values: + + ID S2K Type + -- -------- + 0 Simple S2K + 1 Salted S2K + 2 Reserved value + 3 Iterated and Salted S2K + 100 to 110 Private/Experimental S2K + + These are described in Sections 3.7.1.1 - 3.7.1.3. + +3.7.1.1. Simple S2K + + This directly hashes the string to produce the key data. See below + for how this hashing is done. + + Octet 0: 0x00 + Octet 1: hash algorithm + + Simple S2K hashes the passphrase to produce the session key. The + manner in which this is done depends on the size of the session key + (which will depend on the cipher used) and the size of the hash + + + + + +Callas, et al Standards Track [Page 10] + +RFC 4880 OpenPGP Message Format November 2007 + + + algorithm's output. If the hash size is greater than the session key + size, the high-order (leftmost) octets of the hash are used as the + key. + + If the hash size is less than the key size, multiple instances of the + hash context are created -- enough to produce the required key data. + These instances are preloaded with 0, 1, 2, ... octets of zeros (that + is to say, the first instance has no preloading, the second gets + preloaded with 1 octet of zero, the third is preloaded with two + octets of zeros, and so forth). + + As the data is hashed, it is given independently to each hash + context. Since the contexts have been initialized differently, they + will each produce different hash output. Once the passphrase is + hashed, the output data from the multiple hashes is concatenated, + first hash leftmost, to produce the key data, with any excess octets + on the right discarded. + +3.7.1.2. Salted S2K + + This includes a "salt" value in the S2K specifier -- some arbitrary + data -- that gets hashed along with the passphrase string, to help + prevent dictionary attacks. + + Octet 0: 0x01 + Octet 1: hash algorithm + Octets 2-9: 8-octet salt value + + Salted S2K is exactly like Simple S2K, except that the input to the + hash function(s) consists of the 8 octets of salt from the S2K + specifier, followed by the passphrase. + +3.7.1.3. Iterated and Salted S2K + + This includes both a salt and an octet count. The salt is combined + with the passphrase and the resulting value is hashed repeatedly. + This further increases the amount of work an attacker must do to try + dictionary attacks. + + Octet 0: 0x03 + Octet 1: hash algorithm + Octets 2-9: 8-octet salt value + Octet 10: count, a one-octet, coded value + + + + + + + + +Callas, et al Standards Track [Page 11] + +RFC 4880 OpenPGP Message Format November 2007 + + + The count is coded into a one-octet number using the following + formula: + + #define EXPBIAS 6 + count = ((Int32)16 + (c & 15)) << ((c >> 4) + EXPBIAS); + + The above formula is in C, where "Int32" is a type for a 32-bit + integer, and the variable "c" is the coded count, Octet 10. + + Iterated-Salted S2K hashes the passphrase and salt data multiple + times. The total number of octets to be hashed is specified in the + encoded count in the S2K specifier. Note that the resulting count + value is an octet count of how many octets will be hashed, not an + iteration count. + + Initially, one or more hash contexts are set up as with the other S2K + algorithms, depending on how many octets of key data are needed. + Then the salt, followed by the passphrase data, is repeatedly hashed + until the number of octets specified by the octet count has been + hashed. The one exception is that if the octet count is less than + the size of the salt plus passphrase, the full salt plus passphrase + will be hashed even though that is greater than the octet count. + After the hashing is done, the data is unloaded from the hash + context(s) as with the other S2K algorithms. + +3.7.2. String-to-Key Usage + + Implementations SHOULD use salted or iterated-and-salted S2K + specifiers, as simple S2K specifiers are more vulnerable to + dictionary attacks. + +3.7.2.1. Secret-Key Encryption + + An S2K specifier can be stored in the secret keyring to specify how + to convert the passphrase to a key that unlocks the secret data. + Older versions of PGP just stored a cipher algorithm octet preceding + the secret data or a zero to indicate that the secret data was + unencrypted. The MD5 hash function was always used to convert the + passphrase to a key for the specified cipher algorithm. + + For compatibility, when an S2K specifier is used, the special value + 254 or 255 is stored in the position where the hash algorithm octet + would have been in the old data structure. This is then followed + immediately by a one-octet algorithm identifier, and then by the S2K + specifier as encoded above. + + + + + + +Callas, et al Standards Track [Page 12] + +RFC 4880 OpenPGP Message Format November 2007 + + + Therefore, preceding the secret data there will be one of these + possibilities: + + 0: secret data is unencrypted (no passphrase) + 255 or 254: followed by algorithm octet and S2K specifier + Cipher alg: use Simple S2K algorithm using MD5 hash + + This last possibility, the cipher algorithm number with an implicit + use of MD5 and IDEA, is provided for backward compatibility; it MAY + be understood, but SHOULD NOT be generated, and is deprecated. + + These are followed by an Initial Vector of the same length as the + block size of the cipher for the decryption of the secret values, if + they are encrypted, and then the secret-key values themselves. + +3.7.2.2. Symmetric-Key Message Encryption + + OpenPGP can create a Symmetric-key Encrypted Session Key (ESK) packet + at the front of a message. This is used to allow S2K specifiers to + be used for the passphrase conversion or to create messages with a + mix of symmetric-key ESKs and public-key ESKs. This allows a message + to be decrypted either with a passphrase or a public-key pair. + + PGP 2.X always used IDEA with Simple string-to-key conversion when + encrypting a message with a symmetric algorithm. This is deprecated, + but MAY be used for backward-compatibility. + +4. Packet Syntax + + This section describes the packets used by OpenPGP. + +4.1. Overview + + An OpenPGP message is constructed from a number of records that are + traditionally called packets. A packet is a chunk of data that has a + tag specifying its meaning. An OpenPGP message, keyring, + certificate, and so forth consists of a number of packets. Some of + those packets may contain other OpenPGP packets (for example, a + compressed data packet, when uncompressed, contains OpenPGP packets). + + Each packet consists of a packet header, followed by the packet body. + The packet header is of variable length. + +4.2. Packet Headers + + The first octet of the packet header is called the "Packet Tag". It + determines the format of the header and denotes the packet contents. + The remainder of the packet header is the length of the packet. + + + +Callas, et al Standards Track [Page 13] + +RFC 4880 OpenPGP Message Format November 2007 + + + Note that the most significant bit is the leftmost bit, called bit 7. + A mask for this bit is 0x80 in hexadecimal. + + +---------------+ + PTag |7 6 5 4 3 2 1 0| + +---------------+ + Bit 7 -- Always one + Bit 6 -- New packet format if set + + PGP 2.6.x only uses old format packets. Thus, software that + interoperates with those versions of PGP must only use old format + packets. If interoperability is not an issue, the new packet format + is RECOMMENDED. Note that old format packets have four bits of + packet tags, and new format packets have six; some features cannot be + used and still be backward-compatible. + + Also note that packets with a tag greater than or equal to 16 MUST + use new format packets. The old format packets can only express tags + less than or equal to 15. + + Old format packets contain: + + Bits 5-2 -- packet tag + Bits 1-0 -- length-type + + New format packets contain: + + Bits 5-0 -- packet tag + +4.2.1. Old Format Packet Lengths + + The meaning of the length-type in old format packets is: + + 0 - The packet has a one-octet length. The header is 2 octets long. + + 1 - The packet has a two-octet length. The header is 3 octets long. + + 2 - The packet has a four-octet length. The header is 5 octets long. + + 3 - The packet is of indeterminate length. The header is 1 octet + long, and the implementation must determine how long the packet + is. If the packet is in a file, this means that the packet + extends until the end of the file. In general, an implementation + SHOULD NOT use indeterminate-length packets except where the end + of the data will be clear from the context, and even then it is + better to use a definite length, or a new format header. The new + format headers described below have a mechanism for precisely + encoding data of indeterminate length. + + + +Callas, et al Standards Track [Page 14] + +RFC 4880 OpenPGP Message Format November 2007 + + +4.2.2. New Format Packet Lengths + + New format packets have four possible ways of encoding length: + + 1. A one-octet Body Length header encodes packet lengths of up to 191 + octets. + + 2. A two-octet Body Length header encodes packet lengths of 192 to + 8383 octets. + + 3. A five-octet Body Length header encodes packet lengths of up to + 4,294,967,295 (0xFFFFFFFF) octets in length. (This actually + encodes a four-octet scalar number.) + + 4. When the length of the packet body is not known in advance by the + issuer, Partial Body Length headers encode a packet of + indeterminate length, effectively making it a stream. + +4.2.2.1. One-Octet Lengths + + A one-octet Body Length header encodes a length of 0 to 191 octets. + This type of length header is recognized because the one octet value + is less than 192. The body length is equal to: + + bodyLen = 1st_octet; + +4.2.2.2. Two-Octet Lengths + + A two-octet Body Length header encodes a length of 192 to 8383 + octets. It is recognized because its first octet is in the range 192 + to 223. The body length is equal to: + + bodyLen = ((1st_octet - 192) << 8) + (2nd_octet) + 192 + +4.2.2.3. Five-Octet Lengths + + A five-octet Body Length header consists of a single octet holding + the value 255, followed by a four-octet scalar. The body length is + equal to: + + bodyLen = (2nd_octet << 24) | (3rd_octet << 16) | + (4th_octet << 8) | 5th_octet + + This basic set of one, two, and five-octet lengths is also used + internally to some packets. + + + + + + +Callas, et al Standards Track [Page 15] + +RFC 4880 OpenPGP Message Format November 2007 + + +4.2.2.4. Partial Body Lengths + + A Partial Body Length header is one octet long and encodes the length + of only part of the data packet. This length is a power of 2, from 1 + to 1,073,741,824 (2 to the 30th power). It is recognized by its one + octet value that is greater than or equal to 224, and less than 255. + The Partial Body Length is equal to: + + partialBodyLen = 1 << (1st_octet & 0x1F); + + Each Partial Body Length header is followed by a portion of the + packet body data. The Partial Body Length header specifies this + portion's length. Another length header (one octet, two-octet, + five-octet, or partial) follows that portion. The last length header + in the packet MUST NOT be a Partial Body Length header. Partial Body + Length headers may only be used for the non-final parts of the + packet. + + Note also that the last Body Length header can be a zero-length + header. + + An implementation MAY use Partial Body Lengths for data packets, be + they literal, compressed, or encrypted. The first partial length + MUST be at least 512 octets long. Partial Body Lengths MUST NOT be + used for any other packet types. + +4.2.3. Packet Length Examples + + These examples show ways that new format packets might encode the + packet lengths. + + A packet with length 100 may have its length encoded in one octet: + 0x64. This is followed by 100 octets of data. + + A packet with length 1723 may have its length encoded in two octets: + 0xC5, 0xFB. This header is followed by the 1723 octets of data. + + A packet with length 100000 may have its length encoded in five + octets: 0xFF, 0x00, 0x01, 0x86, 0xA0. + + It might also be encoded in the following octet stream: 0xEF, first + 32768 octets of data; 0xE1, next two octets of data; 0xE0, next one + octet of data; 0xF0, next 65536 octets of data; 0xC5, 0xDD, last 1693 + octets of data. This is just one possible encoding, and many + variations are possible on the size of the Partial Body Length + headers, as long as a regular Body Length header encodes the last + portion of the data. + + + + +Callas, et al Standards Track [Page 16] + +RFC 4880 OpenPGP Message Format November 2007 + + + Please note that in all of these explanations, the total length of + the packet is the length of the header(s) plus the length of the + body. + +4.3. Packet Tags + + The packet tag denotes what type of packet the body holds. Note that + old format headers can only have tags less than 16, whereas new + format headers can have tags as great as 63. The defined tags (in + decimal) are as follows: + + 0 -- Reserved - a packet tag MUST NOT have this value + 1 -- Public-Key Encrypted Session Key Packet + 2 -- Signature Packet + 3 -- Symmetric-Key Encrypted Session Key Packet + 4 -- One-Pass Signature Packet + 5 -- Secret-Key Packet + 6 -- Public-Key Packet + 7 -- Secret-Subkey Packet + 8 -- Compressed Data Packet + 9 -- Symmetrically Encrypted Data Packet + 10 -- Marker Packet + 11 -- Literal Data Packet + 12 -- Trust Packet + 13 -- User ID Packet + 14 -- Public-Subkey Packet + 17 -- User Attribute Packet + 18 -- Sym. Encrypted and Integrity Protected Data Packet + 19 -- Modification Detection Code Packet + 60 to 63 -- Private or Experimental Values + +5. Packet Types + +5.1. Public-Key Encrypted Session Key Packets (Tag 1) + + A Public-Key Encrypted Session Key packet holds the session key used + to encrypt a message. Zero or more Public-Key Encrypted Session Key + packets and/or Symmetric-Key Encrypted Session Key packets may + precede a Symmetrically Encrypted Data Packet, which holds an + encrypted message. The message is encrypted with the session key, + and the session key is itself encrypted and stored in the Encrypted + Session Key packet(s). The Symmetrically Encrypted Data Packet is + preceded by one Public-Key Encrypted Session Key packet for each + OpenPGP key to which the message is encrypted. The recipient of the + message finds a session key that is encrypted to their public key, + decrypts the session key, and then uses the session key to decrypt + the message. + + + + +Callas, et al Standards Track [Page 17] + +RFC 4880 OpenPGP Message Format November 2007 + + + The body of this packet consists of: + + - A one-octet number giving the version number of the packet type. + The currently defined value for packet version is 3. + + - An eight-octet number that gives the Key ID of the public key to + which the session key is encrypted. If the session key is + encrypted to a subkey, then the Key ID of this subkey is used + here instead of the Key ID of the primary key. + + - A one-octet number giving the public-key algorithm used. + + - A string of octets that is the encrypted session key. This + string takes up the remainder of the packet, and its contents are + dependent on the public-key algorithm used. + + Algorithm Specific Fields for RSA encryption + + - multiprecision integer (MPI) of RSA encrypted value m**e mod n. + + Algorithm Specific Fields for Elgamal encryption: + + - MPI of Elgamal (Diffie-Hellman) value g**k mod p. + + - MPI of Elgamal (Diffie-Hellman) value m * y**k mod p. + + The value "m" in the above formulas is derived from the session key + as follows. First, the session key is prefixed with a one-octet + algorithm identifier that specifies the symmetric encryption + algorithm used to encrypt the following Symmetrically Encrypted Data + Packet. Then a two-octet checksum is appended, which is equal to the + sum of the preceding session key octets, not including the algorithm + identifier, modulo 65536. This value is then encoded as described in + PKCS#1 block encoding EME-PKCS1-v1_5 in Section 7.2.1 of [RFC3447] to + form the "m" value used in the formulas above. See Section 13.1 of + this document for notes on OpenPGP's use of PKCS#1. + + Note that when an implementation forms several PKESKs with one + session key, forming a message that can be decrypted by several keys, + the implementation MUST make a new PKCS#1 encoding for each key. + + An implementation MAY accept or use a Key ID of zero as a "wild card" + or "speculative" Key ID. In this case, the receiving implementation + would try all available private keys, checking for a valid decrypted + session key. This format helps reduce traffic analysis of messages. + + + + + + +Callas, et al Standards Track [Page 18] + +RFC 4880 OpenPGP Message Format November 2007 + + +5.2. Signature Packet (Tag 2) + + A Signature packet describes a binding between some public key and + some data. The most common signatures are a signature of a file or a + block of text, and a signature that is a certification of a User ID. + + Two versions of Signature packets are defined. Version 3 provides + basic signature information, while version 4 provides an expandable + format with subpackets that can specify more information about the + signature. PGP 2.6.x only accepts version 3 signatures. + + Implementations SHOULD accept V3 signatures. Implementations SHOULD + generate V4 signatures. + + Note that if an implementation is creating an encrypted and signed + message that is encrypted to a V3 key, it is reasonable to create a + V3 signature. + +5.2.1. Signature Types + + There are a number of possible meanings for a signature, which are + indicated in a signature type octet in any given signature. Please + note that the vagueness of these meanings is not a flaw, but a + feature of the system. Because OpenPGP places final authority for + validity upon the receiver of a signature, it may be that one + signer's casual act might be more rigorous than some other + authority's positive act. See Section 5.2.4, "Computing Signatures", + for detailed information on how to compute and verify signatures of + each type. + + These meanings are as follows: + + 0x00: Signature of a binary document. + This means the signer owns it, created it, or certifies that it + has not been modified. + + 0x01: Signature of a canonical text document. + This means the signer owns it, created it, or certifies that it + has not been modified. The signature is calculated over the text + data with its line endings converted to . + + 0x02: Standalone signature. + This signature is a signature of only its own subpacket contents. + It is calculated identically to a signature over a zero-length + binary document. Note that it doesn't make sense to have a V3 + standalone signature. + + + + + +Callas, et al Standards Track [Page 19] + +RFC 4880 OpenPGP Message Format November 2007 + + + 0x10: Generic certification of a User ID and Public-Key packet. + The issuer of this certification does not make any particular + assertion as to how well the certifier has checked that the owner + of the key is in fact the person described by the User ID. + + 0x11: Persona certification of a User ID and Public-Key packet. + The issuer of this certification has not done any verification of + the claim that the owner of this key is the User ID specified. + + 0x12: Casual certification of a User ID and Public-Key packet. + The issuer of this certification has done some casual + verification of the claim of identity. + + 0x13: Positive certification of a User ID and Public-Key packet. + The issuer of this certification has done substantial + verification of the claim of identity. + + Most OpenPGP implementations make their "key signatures" as 0x10 + certifications. Some implementations can issue 0x11-0x13 + certifications, but few differentiate between the types. + + 0x18: Subkey Binding Signature + This signature is a statement by the top-level signing key that + indicates that it owns the subkey. This signature is calculated + directly on the primary key and subkey, and not on any User ID or + other packets. A signature that binds a signing subkey MUST have + an Embedded Signature subpacket in this binding signature that + contains a 0x19 signature made by the signing subkey on the + primary key and subkey. + + 0x19: Primary Key Binding Signature + This signature is a statement by a signing subkey, indicating + that it is owned by the primary key and subkey. This signature + is calculated the same way as a 0x18 signature: directly on the + primary key and subkey, and not on any User ID or other packets. + + 0x1F: Signature directly on a key + This signature is calculated directly on a key. It binds the + information in the Signature subpackets to the key, and is + appropriate to be used for subpackets that provide information + about the key, such as the Revocation Key subpacket. It is also + appropriate for statements that non-self certifiers want to make + about the key itself, rather than the binding between a key and a + name. + + + + + + + +Callas, et al Standards Track [Page 20] + +RFC 4880 OpenPGP Message Format November 2007 + + + 0x20: Key revocation signature + The signature is calculated directly on the key being revoked. A + revoked key is not to be used. Only revocation signatures by the + key being revoked, or by an authorized revocation key, should be + considered valid revocation signatures. + + 0x28: Subkey revocation signature + The signature is calculated directly on the subkey being revoked. + A revoked subkey is not to be used. Only revocation signatures + by the top-level signature key that is bound to this subkey, or + by an authorized revocation key, should be considered valid + revocation signatures. + + 0x30: Certification revocation signature + This signature revokes an earlier User ID certification signature + (signature class 0x10 through 0x13) or direct-key signature + (0x1F). It should be issued by the same key that issued the + revoked signature or an authorized revocation key. The signature + is computed over the same data as the certificate that it + revokes, and should have a later creation date than that + certificate. + + 0x40: Timestamp signature. + This signature is only meaningful for the timestamp contained in + it. + + 0x50: Third-Party Confirmation signature. + This signature is a signature over some other OpenPGP Signature + packet(s). It is analogous to a notary seal on the signed data. + A third-party signature SHOULD include Signature Target + subpacket(s) to give easy identification. Note that we really do + mean SHOULD. There are plausible uses for this (such as a blind + party that only sees the signature, not the key or source + document) that cannot include a target subpacket. + +5.2.2. Version 3 Signature Packet Format + + The body of a version 3 Signature Packet contains: + + - One-octet version number (3). + + - One-octet length of following hashed material. MUST be 5. + + - One-octet signature type. + + - Four-octet creation time. + + - Eight-octet Key ID of signer. + + + +Callas, et al Standards Track [Page 21] + +RFC 4880 OpenPGP Message Format November 2007 + + + - One-octet public-key algorithm. + + - One-octet hash algorithm. + + - Two-octet field holding left 16 bits of signed hash value. + + - One or more multiprecision integers comprising the signature. + This portion is algorithm specific, as described below. + + The concatenation of the data to be signed, the signature type, and + creation time from the Signature packet (5 additional octets) is + hashed. The resulting hash value is used in the signature algorithm. + The high 16 bits (first two octets) of the hash are included in the + Signature packet to provide a quick test to reject some invalid + signatures. + + Algorithm-Specific Fields for RSA signatures: + + - multiprecision integer (MPI) of RSA signature value m**d mod n. + + Algorithm-Specific Fields for DSA signatures: + + - MPI of DSA value r. + + - MPI of DSA value s. + + The signature calculation is based on a hash of the signed data, as + described above. The details of the calculation are different for + DSA signatures than for RSA signatures. + + With RSA signatures, the hash value is encoded using PKCS#1 encoding + type EMSA-PKCS1-v1_5 as described in Section 9.2 of RFC 3447. This + requires inserting the hash value as an octet string into an ASN.1 + structure. The object identifier for the type of hash being used is + included in the structure. The hexadecimal representations for the + currently defined hash algorithms are as follows: + + - MD5: 0x2A, 0x86, 0x48, 0x86, 0xF7, 0x0D, 0x02, 0x05 + + - RIPEMD-160: 0x2B, 0x24, 0x03, 0x02, 0x01 + + - SHA-1: 0x2B, 0x0E, 0x03, 0x02, 0x1A + + - SHA224: 0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x04 + + - SHA256: 0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x01 + + - SHA384: 0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x02 + + + +Callas, et al Standards Track [Page 22] + +RFC 4880 OpenPGP Message Format November 2007 + + + - SHA512: 0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x03 + + The ASN.1 Object Identifiers (OIDs) are as follows: + + - MD5: 1.2.840.113549.2.5 + + - RIPEMD-160: 1.3.36.3.2.1 + + - SHA-1: 1.3.14.3.2.26 + + - SHA224: 2.16.840.1.101.3.4.2.4 + + - SHA256: 2.16.840.1.101.3.4.2.1 + + - SHA384: 2.16.840.1.101.3.4.2.2 + + - SHA512: 2.16.840.1.101.3.4.2.3 + + The full hash prefixes for these are as follows: + + MD5: 0x30, 0x20, 0x30, 0x0C, 0x06, 0x08, 0x2A, 0x86, + 0x48, 0x86, 0xF7, 0x0D, 0x02, 0x05, 0x05, 0x00, + 0x04, 0x10 + + RIPEMD-160: 0x30, 0x21, 0x30, 0x09, 0x06, 0x05, 0x2B, 0x24, + 0x03, 0x02, 0x01, 0x05, 0x00, 0x04, 0x14 + + SHA-1: 0x30, 0x21, 0x30, 0x09, 0x06, 0x05, 0x2b, 0x0E, + 0x03, 0x02, 0x1A, 0x05, 0x00, 0x04, 0x14 + + SHA224: 0x30, 0x31, 0x30, 0x0d, 0x06, 0x09, 0x60, 0x86, + 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x04, 0x05, + 0x00, 0x04, 0x1C + + SHA256: 0x30, 0x31, 0x30, 0x0d, 0x06, 0x09, 0x60, 0x86, + 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x01, 0x05, + 0x00, 0x04, 0x20 + + SHA384: 0x30, 0x41, 0x30, 0x0d, 0x06, 0x09, 0x60, 0x86, + 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x02, 0x05, + 0x00, 0x04, 0x30 + + SHA512: 0x30, 0x51, 0x30, 0x0d, 0x06, 0x09, 0x60, 0x86, + 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x03, 0x05, + 0x00, 0x04, 0x40 + + DSA signatures MUST use hashes that are equal in size to the number + of bits of q, the group generated by the DSA key's generator value. + + + +Callas, et al Standards Track [Page 23] + +RFC 4880 OpenPGP Message Format November 2007 + + + If the output size of the chosen hash is larger than the number of + bits of q, the hash result is truncated to fit by taking the number + of leftmost bits equal to the number of bits of q. This (possibly + truncated) hash function result is treated as a number and used + directly in the DSA signature algorithm. + +5.2.3. Version 4 Signature Packet Format + + The body of a version 4 Signature packet contains: + + - One-octet version number (4). + + - One-octet signature type. + + - One-octet public-key algorithm. + + - One-octet hash algorithm. + + - Two-octet scalar octet count for following hashed subpacket data. + Note that this is the length in octets of all of the hashed + subpackets; a pointer incremented by this number will skip over + the hashed subpackets. + + - Hashed subpacket data set (zero or more subpackets). + + - Two-octet scalar octet count for the following unhashed subpacket + data. Note that this is the length in octets of all of the + unhashed subpackets; a pointer incremented by this number will + skip over the unhashed subpackets. + + - Unhashed subpacket data set (zero or more subpackets). + + - Two-octet field holding the left 16 bits of the signed hash + value. + + - One or more multiprecision integers comprising the signature. + This portion is algorithm specific, as described above. + + The concatenation of the data being signed and the signature data + from the version number through the hashed subpacket data (inclusive) + is hashed. The resulting hash value is what is signed. The left 16 + bits of the hash are included in the Signature packet to provide a + quick test to reject some invalid signatures. + + There are two fields consisting of Signature subpackets. The first + field is hashed with the rest of the signature data, while the second + is unhashed. The second set of subpackets is not cryptographically + + + + +Callas, et al Standards Track [Page 24] + +RFC 4880 OpenPGP Message Format November 2007 + + + protected by the signature and should include only advisory + information. + + The algorithms for converting the hash function result to a signature + are described in a section below. + +5.2.3.1. Signature Subpacket Specification + + A subpacket data set consists of zero or more Signature subpackets. + In Signature packets, the subpacket data set is preceded by a two- + octet scalar count of the length in octets of all the subpackets. A + pointer incremented by this number will skip over the subpacket data + set. + + Each subpacket consists of a subpacket header and a body. The header + consists of: + + - the subpacket length (1, 2, or 5 octets), + + - the subpacket type (1 octet), + + and is followed by the subpacket-specific data. + + The length includes the type octet but not this length. Its format + is similar to the "new" format packet header lengths, but cannot have + Partial Body Lengths. That is: + + if the 1st octet < 192, then + lengthOfLength = 1 + subpacketLen = 1st_octet + + if the 1st octet >= 192 and < 255, then + lengthOfLength = 2 + subpacketLen = ((1st_octet - 192) << 8) + (2nd_octet) + 192 + + if the 1st octet = 255, then + lengthOfLength = 5 + subpacket length = [four-octet scalar starting at 2nd_octet] + + The value of the subpacket type octet may be: + + 0 = Reserved + 1 = Reserved + 2 = Signature Creation Time + 3 = Signature Expiration Time + 4 = Exportable Certification + 5 = Trust Signature + 6 = Regular Expression + + + +Callas, et al Standards Track [Page 25] + +RFC 4880 OpenPGP Message Format November 2007 + + + 7 = Revocable + 8 = Reserved + 9 = Key Expiration Time + 10 = Placeholder for backward compatibility + 11 = Preferred Symmetric Algorithms + 12 = Revocation Key + 13 = Reserved + 14 = Reserved + 15 = Reserved + 16 = Issuer + 17 = Reserved + 18 = Reserved + 19 = Reserved + 20 = Notation Data + 21 = Preferred Hash Algorithms + 22 = Preferred Compression Algorithms + 23 = Key Server Preferences + 24 = Preferred Key Server + 25 = Primary User ID + 26 = Policy URI + 27 = Key Flags + 28 = Signer's User ID + 29 = Reason for Revocation + 30 = Features + 31 = Signature Target + 32 = Embedded Signature + 100 To 110 = Private or experimental + + An implementation SHOULD ignore any subpacket of a type that it does + not recognize. + + Bit 7 of the subpacket type is the "critical" bit. If set, it + denotes that the subpacket is one that is critical for the evaluator + of the signature to recognize. If a subpacket is encountered that is + marked critical but is unknown to the evaluating software, the + evaluator SHOULD consider the signature to be in error. + + An evaluator may "recognize" a subpacket, but not implement it. The + purpose of the critical bit is to allow the signer to tell an + evaluator that it would prefer a new, unknown feature to generate an + error than be ignored. + + Implementations SHOULD implement the three preferred algorithm + subpackets (11, 21, and 22), as well as the "Reason for Revocation" + subpacket. Note, however, that if an implementation chooses not to + implement some of the preferences, it is required to behave in a + polite manner to respect the wishes of those users who do implement + these preferences. + + + +Callas, et al Standards Track [Page 26] + +RFC 4880 OpenPGP Message Format November 2007 + + +5.2.3.2. Signature Subpacket Types + + A number of subpackets are currently defined. Some subpackets apply + to the signature itself and some are attributes of the key. + Subpackets that are found on a self-signature are placed on a + certification made by the key itself. Note that a key may have more + than one User ID, and thus may have more than one self-signature, and + differing subpackets. + + A subpacket may be found either in the hashed or unhashed subpacket + sections of a signature. If a subpacket is not hashed, then the + information in it cannot be considered definitive because it is not + part of the signature proper. + +5.2.3.3. Notes on Self-Signatures + + A self-signature is a binding signature made by the key to which the + signature refers. There are three types of self-signatures, the + certification signatures (types 0x10-0x13), the direct-key signature + (type 0x1F), and the subkey binding signature (type 0x18). For + certification self-signatures, each User ID may have a self- + signature, and thus different subpackets in those self-signatures. + For subkey binding signatures, each subkey in fact has a self- + signature. Subpackets that appear in a certification self-signature + apply to the user name, and subpackets that appear in the subkey + self-signature apply to the subkey. Lastly, subpackets on the + direct-key signature apply to the entire key. + + Implementing software should interpret a self-signature's preference + subpackets as narrowly as possible. For example, suppose a key has + two user names, Alice and Bob. Suppose that Alice prefers the + symmetric algorithm CAST5, and Bob prefers IDEA or TripleDES. If the + software locates this key via Alice's name, then the preferred + algorithm is CAST5; if software locates the key via Bob's name, then + the preferred algorithm is IDEA. If the key is located by Key ID, + the algorithm of the primary User ID of the key provides the + preferred symmetric algorithm. + + Revoking a self-signature or allowing it to expire has a semantic + meaning that varies with the signature type. Revoking the self- + signature on a User ID effectively retires that user name. The + self-signature is a statement, "My name X is tied to my signing key + K" and is corroborated by other users' certifications. If another + user revokes their certification, they are effectively saying that + they no longer believe that name and that key are tied together. + Similarly, if the users themselves revoke their self-signature, then + the users no longer go by that name, no longer have that email + address, etc. Revoking a binding signature effectively retires that + + + +Callas, et al Standards Track [Page 27] + +RFC 4880 OpenPGP Message Format November 2007 + + + subkey. Revoking a direct-key signature cancels that signature. + Please see the "Reason for Revocation" subpacket (Section 5.2.3.23) + for more relevant detail. + + Since a self-signature contains important information about the key's + use, an implementation SHOULD allow the user to rewrite the self- + signature, and important information in it, such as preferences and + key expiration. + + It is good practice to verify that a self-signature imported into an + implementation doesn't advertise features that the implementation + doesn't support, rewriting the signature as appropriate. + + An implementation that encounters multiple self-signatures on the + same object may resolve the ambiguity in any way it sees fit, but it + is RECOMMENDED that priority be given to the most recent self- + signature. + +5.2.3.4. Signature Creation Time + + (4-octet time field) + + The time the signature was made. + + MUST be present in the hashed area. + +5.2.3.5. Issuer + + (8-octet Key ID) + + The OpenPGP Key ID of the key issuing the signature. + +5.2.3.6. Key Expiration Time + + (4-octet time field) + + The validity period of the key. This is the number of seconds after + the key creation time that the key expires. If this is not present + or has a value of zero, the key never expires. This is found only on + a self-signature. + +5.2.3.7. Preferred Symmetric Algorithms + + (array of one-octet values) + + Symmetric algorithm numbers that indicate which algorithms the key + holder prefers to use. The subpacket body is an ordered list of + octets with the most preferred listed first. It is assumed that only + + + +Callas, et al Standards Track [Page 28] + +RFC 4880 OpenPGP Message Format November 2007 + + + algorithms listed are supported by the recipient's software. + Algorithm numbers are in Section 9. This is only found on a self- + signature. + +5.2.3.8. Preferred Hash Algorithms + + (array of one-octet values) + + Message digest algorithm numbers that indicate which algorithms the + key holder prefers to receive. Like the preferred symmetric + algorithms, the list is ordered. Algorithm numbers are in Section 9. + This is only found on a self-signature. + +5.2.3.9. Preferred Compression Algorithms + + (array of one-octet values) + + Compression algorithm numbers that indicate which algorithms the key + holder prefers to use. Like the preferred symmetric algorithms, the + list is ordered. Algorithm numbers are in Section 9. If this + subpacket is not included, ZIP is preferred. A zero denotes that + uncompressed data is preferred; the key holder's software might have + no compression software in that implementation. This is only found + on a self-signature. + +5.2.3.10. Signature Expiration Time + + (4-octet time field) + + The validity period of the signature. This is the number of seconds + after the signature creation time that the signature expires. If + this is not present or has a value of zero, it never expires. + +5.2.3.11. Exportable Certification + + (1 octet of exportability, 0 for not, 1 for exportable) + + This subpacket denotes whether a certification signature is + "exportable", to be used by other users than the signature's issuer. + The packet body contains a Boolean flag indicating whether the + signature is exportable. If this packet is not present, the + certification is exportable; it is equivalent to a flag containing a + 1. + + Non-exportable, or "local", certifications are signatures made by a + user to mark a key as valid within that user's implementation only. + + + + + +Callas, et al Standards Track [Page 29] + +RFC 4880 OpenPGP Message Format November 2007 + + + Thus, when an implementation prepares a user's copy of a key for + transport to another user (this is the process of "exporting" the + key), any local certification signatures are deleted from the key. + + The receiver of a transported key "imports" it, and likewise trims + any local certifications. In normal operation, there won't be any, + assuming the import is performed on an exported key. However, there + are instances where this can reasonably happen. For example, if an + implementation allows keys to be imported from a key database in + addition to an exported key, then this situation can arise. + + Some implementations do not represent the interest of a single user + (for example, a key server). Such implementations always trim local + certifications from any key they handle. + +5.2.3.12. Revocable + + (1 octet of revocability, 0 for not, 1 for revocable) + + Signature's revocability status. The packet body contains a Boolean + flag indicating whether the signature is revocable. Signatures that + are not revocable have any later revocation signatures ignored. They + represent a commitment by the signer that he cannot revoke his + signature for the life of his key. If this packet is not present, + the signature is revocable. + +5.2.3.13. Trust Signature + + (1 octet "level" (depth), 1 octet of trust amount) + + Signer asserts that the key is not only valid but also trustworthy at + the specified level. Level 0 has the same meaning as an ordinary + validity signature. Level 1 means that the signed key is asserted to + be a valid trusted introducer, with the 2nd octet of the body + specifying the degree of trust. Level 2 means that the signed key is + asserted to be trusted to issue level 1 trust signatures, i.e., that + it is a "meta introducer". Generally, a level n trust signature + asserts that a key is trusted to issue level n-1 trust signatures. + The trust amount is in a range from 0-255, interpreted such that + values less than 120 indicate partial trust and values of 120 or + greater indicate complete trust. Implementations SHOULD emit values + of 60 for partial trust and 120 for complete trust. + + + + + + + + + +Callas, et al Standards Track [Page 30] + +RFC 4880 OpenPGP Message Format November 2007 + + +5.2.3.14. Regular Expression + + (null-terminated regular expression) + + Used in conjunction with trust Signature packets (of level > 0) to + limit the scope of trust that is extended. Only signatures by the + target key on User IDs that match the regular expression in the body + of this packet have trust extended by the trust Signature subpacket. + The regular expression uses the same syntax as the Henry Spencer's + "almost public domain" regular expression [REGEX] package. A + description of the syntax is found in Section 8 below. + +5.2.3.15. Revocation Key + + (1 octet of class, 1 octet of public-key algorithm ID, 20 octets of + fingerprint) + + Authorizes the specified key to issue revocation signatures for this + key. Class octet must have bit 0x80 set. If the bit 0x40 is set, + then this means that the revocation information is sensitive. Other + bits are for future expansion to other kinds of authorizations. This + is found on a self-signature. + + If the "sensitive" flag is set, the keyholder feels this subpacket + contains private trust information that describes a real-world + sensitive relationship. If this flag is set, implementations SHOULD + NOT export this signature to other users except in cases where the + data needs to be available: when the signature is being sent to the + designated revoker, or when it is accompanied by a revocation + signature from that revoker. Note that it may be appropriate to + isolate this subpacket within a separate signature so that it is not + combined with other subpackets that need to be exported. + +5.2.3.16. Notation Data + + (4 octets of flags, 2 octets of name length (M), + 2 octets of value length (N), + M octets of name data, + N octets of value data) + + This subpacket describes a "notation" on the signature that the + issuer wishes to make. The notation has a name and a value, each of + which are strings of octets. There may be more than one notation in + a signature. Notations can be used for any extension the issuer of + the signature cares to make. The "flags" field holds four octets of + flags. + + + + + +Callas, et al Standards Track [Page 31] + +RFC 4880 OpenPGP Message Format November 2007 + + + All undefined flags MUST be zero. Defined flags are as follows: + + First octet: 0x80 = human-readable. This note value is text. + Other octets: none. + + Notation names are arbitrary strings encoded in UTF-8. They reside + in two namespaces: The IETF namespace and the user namespace. + + The IETF namespace is registered with IANA. These names MUST NOT + contain the "@" character (0x40). This is a tag for the user + namespace. + + Names in the user namespace consist of a UTF-8 string tag followed by + "@" followed by a DNS domain name. Note that the tag MUST NOT + contain an "@" character. For example, the "sample" tag used by + Example Corporation could be "sample@example.com". + + Names in a user space are owned and controlled by the owners of that + domain. Obviously, it's bad form to create a new name in a DNS space + that you don't own. + + Since the user namespace is in the form of an email address, + implementers MAY wish to arrange for that address to reach a person + who can be consulted about the use of the named tag. Note that due + to UTF-8 encoding, not all valid user space name tags are valid email + addresses. + + If there is a critical notation, the criticality applies to that + specific notation and not to notations in general. + +5.2.3.17. Key Server Preferences + + (N octets of flags) + + This is a list of one-bit flags that indicate preferences that the + key holder has about how the key is handled on a key server. All + undefined flags MUST be zero. + + First octet: 0x80 = No-modify + the key holder requests that this key only be modified or updated + by the key holder or an administrator of the key server. + + This is found only on a self-signature. + + + + + + + + +Callas, et al Standards Track [Page 32] + +RFC 4880 OpenPGP Message Format November 2007 + + +5.2.3.18. Preferred Key Server + + (String) + + This is a URI of a key server that the key holder prefers be used for + updates. Note that keys with multiple User IDs can have a preferred + key server for each User ID. Note also that since this is a URI, the + key server can actually be a copy of the key retrieved by ftp, http, + finger, etc. + +5.2.3.19. Primary User ID + + (1 octet, Boolean) + + This is a flag in a User ID's self-signature that states whether this + User ID is the main User ID for this key. It is reasonable for an + implementation to resolve ambiguities in preferences, etc. by + referring to the primary User ID. If this flag is absent, its value + is zero. If more than one User ID in a key is marked as primary, the + implementation may resolve the ambiguity in any way it sees fit, but + it is RECOMMENDED that priority be given to the User ID with the most + recent self-signature. + + When appearing on a self-signature on a User ID packet, this + subpacket applies only to User ID packets. When appearing on a + self-signature on a User Attribute packet, this subpacket applies + only to User Attribute packets. That is to say, there are two + different and independent "primaries" -- one for User IDs, and one + for User Attributes. + +5.2.3.20. Policy URI + + (String) + + This subpacket contains a URI of a document that describes the policy + under which the signature was issued. + +5.2.3.21. Key Flags + + (N octets of flags) + + This subpacket contains a list of binary flags that hold information + about a key. It is a string of octets, and an implementation MUST + NOT assume a fixed size. This is so it can grow over time. If a + list is shorter than an implementation expects, the unstated flags + are considered to be zero. The defined flags are as follows: + + + + + +Callas, et al Standards Track [Page 33] + +RFC 4880 OpenPGP Message Format November 2007 + + + First octet: + + 0x01 - This key may be used to certify other keys. + + 0x02 - This key may be used to sign data. + + 0x04 - This key may be used to encrypt communications. + + 0x08 - This key may be used to encrypt storage. + + 0x10 - The private component of this key may have been split + by a secret-sharing mechanism. + + 0x20 - This key may be used for authentication. + + 0x80 - The private component of this key may be in the + possession of more than one person. + + Usage notes: + + The flags in this packet may appear in self-signatures or in + certification signatures. They mean different things depending on + who is making the statement -- for example, a certification signature + that has the "sign data" flag is stating that the certification is + for that use. On the other hand, the "communications encryption" + flag in a self-signature is stating a preference that a given key be + used for communications. Note however, that it is a thorny issue to + determine what is "communications" and what is "storage". This + decision is left wholly up to the implementation; the authors of this + document do not claim any special wisdom on the issue and realize + that accepted opinion may change. + + The "split key" (0x10) and "group key" (0x80) flags are placed on a + self-signature only; they are meaningless on a certification + signature. They SHOULD be placed only on a direct-key signature + (type 0x1F) or a subkey signature (type 0x18), one that refers to the + key the flag applies to. + +5.2.3.22. Signer's User ID + + (String) + + This subpacket allows a keyholder to state which User ID is + responsible for the signing. Many keyholders use a single key for + different purposes, such as business communications as well as + personal communications. This subpacket allows such a keyholder to + state which of their roles is making a signature. + + + + +Callas, et al Standards Track [Page 34] + +RFC 4880 OpenPGP Message Format November 2007 + + + This subpacket is not appropriate to use to refer to a User Attribute + packet. + +5.2.3.23. Reason for Revocation + + (1 octet of revocation code, N octets of reason string) + + This subpacket is used only in key revocation and certification + revocation signatures. It describes the reason why the key or + certificate was revoked. + + The first octet contains a machine-readable code that denotes the + reason for the revocation: + + 0 - No reason specified (key revocations or cert revocations) + 1 - Key is superseded (key revocations) + 2 - Key material has been compromised (key revocations) + 3 - Key is retired and no longer used (key revocations) + 32 - User ID information is no longer valid (cert revocations) + 100-110 - Private Use + + Following the revocation code is a string of octets that gives + information about the Reason for Revocation in human-readable form + (UTF-8). The string may be null, that is, of zero length. The + length of the subpacket is the length of the reason string plus one. + An implementation SHOULD implement this subpacket, include it in all + revocation signatures, and interpret revocations appropriately. + There are important semantic differences between the reasons, and + there are thus important reasons for revoking signatures. + + If a key has been revoked because of a compromise, all signatures + created by that key are suspect. However, if it was merely + superseded or retired, old signatures are still valid. If the + revoked signature is the self-signature for certifying a User ID, a + revocation denotes that that user name is no longer in use. Such a + revocation SHOULD include a 0x20 code. + + Note that any signature may be revoked, including a certification on + some other person's key. There are many good reasons for revoking a + certification signature, such as the case where the keyholder leaves + the employ of a business with an email address. A revoked + certification is no longer a part of validity calculations. + + + + + + + + + +Callas, et al Standards Track [Page 35] + +RFC 4880 OpenPGP Message Format November 2007 + + +5.2.3.24. Features + + (N octets of flags) + + The Features subpacket denotes which advanced OpenPGP features a + user's implementation supports. This is so that as features are + added to OpenPGP that cannot be backwards-compatible, a user can + state that they can use that feature. The flags are single bits that + indicate that a given feature is supported. + + This subpacket is similar to a preferences subpacket, and only + appears in a self-signature. + + An implementation SHOULD NOT use a feature listed when sending to a + user who does not state that they can use it. + + Defined features are as follows: + + First octet: + + 0x01 - Modification Detection (packets 18 and 19) + + If an implementation implements any of the defined features, it + SHOULD implement the Features subpacket, too. + + An implementation may freely infer features from other suitable + implementation-dependent mechanisms. + +5.2.3.25. Signature Target + + (1 octet public-key algorithm, 1 octet hash algorithm, N octets hash) + + This subpacket identifies a specific target signature to which a + signature refers. For revocation signatures, this subpacket + provides explicit designation of which signature is being revoked. + For a third-party or timestamp signature, this designates what + signature is signed. All arguments are an identifier of that target + signature. + + The N octets of hash data MUST be the size of the hash of the + signature. For example, a target signature with a SHA-1 hash MUST + have 20 octets of hash data. + + + + + + + + + +Callas, et al Standards Track [Page 36] + +RFC 4880 OpenPGP Message Format November 2007 + + +5.2.3.26. Embedded Signature + + (1 signature packet body) + + This subpacket contains a complete Signature packet body as + specified in Section 5.2 above. It is useful when one signature + needs to refer to, or be incorporated in, another signature. + +5.2.4. Computing Signatures + + All signatures are formed by producing a hash over the signature + data, and then using the resulting hash in the signature algorithm. + + For binary document signatures (type 0x00), the document data is + hashed directly. For text document signatures (type 0x01), the + document is canonicalized by converting line endings to , + and the resulting data is hashed. + + When a signature is made over a key, the hash data starts with the + octet 0x99, followed by a two-octet length of the key, and then body + of the key packet. (Note that this is an old-style packet header for + a key packet with two-octet length.) A subkey binding signature + (type 0x18) or primary key binding signature (type 0x19) then hashes + the subkey using the same format as the main key (also using 0x99 as + the first octet). Key revocation signatures (types 0x20 and 0x28) + hash only the key being revoked. + + A certification signature (type 0x10 through 0x13) hashes the User + ID being bound to the key into the hash context after the above + data. A V3 certification hashes the contents of the User ID or + attribute packet packet, without any header. A V4 certification + hashes the constant 0xB4 for User ID certifications or the constant + 0xD1 for User Attribute certifications, followed by a four-octet + number giving the length of the User ID or User Attribute data, and + then the User ID or User Attribute data. + + When a signature is made over a Signature packet (type 0x50), the + hash data starts with the octet 0x88, followed by the four-octet + length of the signature, and then the body of the Signature packet. + (Note that this is an old-style packet header for a Signature packet + with the length-of-length set to zero.) The unhashed subpacket data + of the Signature packet being hashed is not included in the hash, and + the unhashed subpacket data length value is set to zero. + + Once the data body is hashed, then a trailer is hashed. A V3 + signature hashes five octets of the packet body, starting from the + signature type field. This data is the signature type, followed by + the four-octet signature time. A V4 signature hashes the packet body + + + +Callas, et al Standards Track [Page 37] + +RFC 4880 OpenPGP Message Format November 2007 + + + starting from its first field, the version number, through the end + of the hashed subpacket data. Thus, the fields hashed are the + signature version, the signature type, the public-key algorithm, the + hash algorithm, the hashed subpacket length, and the hashed + subpacket body. + + V4 signatures also hash in a final trailer of six octets: the + version of the Signature packet, i.e., 0x04; 0xFF; and a four-octet, + big-endian number that is the length of the hashed data from the + Signature packet (note that this number does not include these final + six octets). + + After all this has been hashed in a single hash context, the + resulting hash field is used in the signature algorithm and placed + at the end of the Signature packet. + +5.2.4.1. Subpacket Hints + + It is certainly possible for a signature to contain conflicting + information in subpackets. For example, a signature may contain + multiple copies of a preference or multiple expiration times. In + most cases, an implementation SHOULD use the last subpacket in the + signature, but MAY use any conflict resolution scheme that makes + more sense. Please note that we are intentionally leaving conflict + resolution to the implementer; most conflicts are simply syntax + errors, and the wishy-washy language here allows a receiver to be + generous in what they accept, while putting pressure on a creator to + be stingy in what they generate. + + Some apparent conflicts may actually make sense -- for example, + suppose a keyholder has a V3 key and a V4 key that share the same + RSA key material. Either of these keys can verify a signature + created by the other, and it may be reasonable for a signature to + contain an issuer subpacket for each key, as a way of explicitly + tying those keys to the signature. + +5.3. Symmetric-Key Encrypted Session Key Packets (Tag 3) + + The Symmetric-Key Encrypted Session Key packet holds the + symmetric-key encryption of a session key used to encrypt a message. + Zero or more Public-Key Encrypted Session Key packets and/or + Symmetric-Key Encrypted Session Key packets may precede a + Symmetrically Encrypted Data packet that holds an encrypted message. + The message is encrypted with a session key, and the session key is + itself encrypted and stored in the Encrypted Session Key packet or + the Symmetric-Key Encrypted Session Key packet. + + + + + +Callas, et al Standards Track [Page 38] + +RFC 4880 OpenPGP Message Format November 2007 + + + If the Symmetrically Encrypted Data packet is preceded by one or + more Symmetric-Key Encrypted Session Key packets, each specifies a + passphrase that may be used to decrypt the message. This allows a + message to be encrypted to a number of public keys, and also to one + or more passphrases. This packet type is new and is not generated + by PGP 2.x or PGP 5.0. + + The body of this packet consists of: + + - A one-octet version number. The only currently defined version + is 4. + + - A one-octet number describing the symmetric algorithm used. + + - A string-to-key (S2K) specifier, length as defined above. + + - Optionally, the encrypted session key itself, which is decrypted + with the string-to-key object. + + If the encrypted session key is not present (which can be detected + on the basis of packet length and S2K specifier size), then the S2K + algorithm applied to the passphrase produces the session key for + decrypting the file, using the symmetric cipher algorithm from the + Symmetric-Key Encrypted Session Key packet. + + If the encrypted session key is present, the result of applying the + S2K algorithm to the passphrase is used to decrypt just that + encrypted session key field, using CFB mode with an IV of all zeros. + The decryption result consists of a one-octet algorithm identifier + that specifies the symmetric-key encryption algorithm used to + encrypt the following Symmetrically Encrypted Data packet, followed + by the session key octets themselves. + + Note: because an all-zero IV is used for this decryption, the S2K + specifier MUST use a salt value, either a Salted S2K or an + Iterated-Salted S2K. The salt value will ensure that the decryption + key is not repeated even if the passphrase is reused. + +5.4. One-Pass Signature Packets (Tag 4) + + The One-Pass Signature packet precedes the signed data and contains + enough information to allow the receiver to begin calculating any + hashes needed to verify the signature. It allows the Signature + packet to be placed at the end of the message, so that the signer + can compute the entire signed message in one pass. + + A One-Pass Signature does not interoperate with PGP 2.6.x or + earlier. + + + +Callas, et al Standards Track [Page 39] + +RFC 4880 OpenPGP Message Format November 2007 + + + The body of this packet consists of: + + - A one-octet version number. The current version is 3. + + - A one-octet signature type. Signature types are described in + Section 5.2.1. + + - A one-octet number describing the hash algorithm used. + + - A one-octet number describing the public-key algorithm used. + + - An eight-octet number holding the Key ID of the signing key. + + - A one-octet number holding a flag showing whether the signature + is nested. A zero value indicates that the next packet is + another One-Pass Signature packet that describes another + signature to be applied to the same message data. + + Note that if a message contains more than one one-pass signature, + then the Signature packets bracket the message; that is, the first + Signature packet after the message corresponds to the last one-pass + packet and the final Signature packet corresponds to the first + one-pass packet. + +5.5. Key Material Packet + + A key material packet contains all the information about a public or + private key. There are four variants of this packet type, and two + major versions. Consequently, this section is complex. + +5.5.1. Key Packet Variants + +5.5.1.1. Public-Key Packet (Tag 6) + + A Public-Key packet starts a series of packets that forms an OpenPGP + key (sometimes called an OpenPGP certificate). + +5.5.1.2. Public-Subkey Packet (Tag 14) + + A Public-Subkey packet (tag 14) has exactly the same format as a + Public-Key packet, but denotes a subkey. One or more subkeys may be + associated with a top-level key. By convention, the top-level key + provides signature services, and the subkeys provide encryption + services. + + Note: in PGP 2.6.x, tag 14 was intended to indicate a comment + packet. This tag was selected for reuse because no previous version + of PGP ever emitted comment packets but they did properly ignore + + + +Callas, et al Standards Track [Page 40] + +RFC 4880 OpenPGP Message Format November 2007 + + + them. Public-Subkey packets are ignored by PGP 2.6.x and do not + cause it to fail, providing a limited degree of backward + compatibility. + +5.5.1.3. Secret-Key Packet (Tag 5) + + A Secret-Key packet contains all the information that is found in a + Public-Key packet, including the public-key material, but also + includes the secret-key material after all the public-key fields. + +5.5.1.4. Secret-Subkey Packet (Tag 7) + + A Secret-Subkey packet (tag 7) is the subkey analog of the Secret + Key packet and has exactly the same format. + +5.5.2. Public-Key Packet Formats + + There are two versions of key-material packets. Version 3 packets + were first generated by PGP 2.6. Version 4 keys first appeared in + PGP 5.0 and are the preferred key version for OpenPGP. + + OpenPGP implementations MUST create keys with version 4 format. V3 + keys are deprecated; an implementation MUST NOT generate a V3 key, + but MAY accept it. + + A version 3 public key or public-subkey packet contains: + + - A one-octet version number (3). + + - A four-octet number denoting the time that the key was created. + + - A two-octet number denoting the time in days that this key is + valid. If this number is zero, then it does not expire. + + - A one-octet number denoting the public-key algorithm of this key. + + - A series of multiprecision integers comprising the key material: + + - a multiprecision integer (MPI) of RSA public modulus n; + + - an MPI of RSA public encryption exponent e. + + V3 keys are deprecated. They contain three weaknesses. First, it is + relatively easy to construct a V3 key that has the same Key ID as any + other key because the Key ID is simply the low 64 bits of the public + modulus. Secondly, because the fingerprint of a V3 key hashes the + key material, but not its length, there is an increased opportunity + for fingerprint collisions. Third, there are weaknesses in the MD5 + + + +Callas, et al Standards Track [Page 41] + +RFC 4880 OpenPGP Message Format November 2007 + + + hash algorithm that make developers prefer other algorithms. See + below for a fuller discussion of Key IDs and fingerprints. + + V2 keys are identical to the deprecated V3 keys except for the + version number. An implementation MUST NOT generate them and MAY + accept or reject them as it sees fit. + + The version 4 format is similar to the version 3 format except for + the absence of a validity period. This has been moved to the + Signature packet. In addition, fingerprints of version 4 keys are + calculated differently from version 3 keys, as described in the + section "Enhanced Key Formats". + + A version 4 packet contains: + + - A one-octet version number (4). + + - A four-octet number denoting the time that the key was created. + + - A one-octet number denoting the public-key algorithm of this key. + + - A series of multiprecision integers comprising the key material. + This algorithm-specific portion is: + + Algorithm-Specific Fields for RSA public keys: + + - multiprecision integer (MPI) of RSA public modulus n; + + - MPI of RSA public encryption exponent e. + + Algorithm-Specific Fields for DSA public keys: + + - MPI of DSA prime p; + + - MPI of DSA group order q (q is a prime divisor of p-1); + + - MPI of DSA group generator g; + + - MPI of DSA public-key value y (= g**x mod p where x + is secret). + + Algorithm-Specific Fields for Elgamal public keys: + + - MPI of Elgamal prime p; + + - MPI of Elgamal group generator g; + + + + + +Callas, et al Standards Track [Page 42] + +RFC 4880 OpenPGP Message Format November 2007 + + + - MPI of Elgamal public key value y (= g**x mod p where x + is secret). + +5.5.3. Secret-Key Packet Formats + + The Secret-Key and Secret-Subkey packets contain all the data of the + Public-Key and Public-Subkey packets, with additional algorithm- + specific secret-key data appended, usually in encrypted form. + + The packet contains: + + - A Public-Key or Public-Subkey packet, as described above. + + - One octet indicating string-to-key usage conventions. Zero + indicates that the secret-key data is not encrypted. 255 or 254 + indicates that a string-to-key specifier is being given. Any + other value is a symmetric-key encryption algorithm identifier. + + - [Optional] If string-to-key usage octet was 255 or 254, a one- + octet symmetric encryption algorithm. + + - [Optional] If string-to-key usage octet was 255 or 254, a + string-to-key specifier. The length of the string-to-key + specifier is implied by its type, as described above. + + - [Optional] If secret data is encrypted (string-to-key usage octet + not zero), an Initial Vector (IV) of the same length as the + cipher's block size. + + - Plain or encrypted multiprecision integers comprising the secret + key data. These algorithm-specific fields are as described + below. + + - If the string-to-key usage octet is zero or 255, then a two-octet + checksum of the plaintext of the algorithm-specific portion (sum + of all octets, mod 65536). If the string-to-key usage octet was + 254, then a 20-octet SHA-1 hash of the plaintext of the + algorithm-specific portion. This checksum or hash is encrypted + together with the algorithm-specific fields (if string-to-key + usage octet is not zero). Note that for all other values, a + two-octet checksum is required. + + Algorithm-Specific Fields for RSA secret keys: + + - multiprecision integer (MPI) of RSA secret exponent d. + + - MPI of RSA secret prime value p. + + + + +Callas, et al Standards Track [Page 43] + +RFC 4880 OpenPGP Message Format November 2007 + + + - MPI of RSA secret prime value q (p < q). + + - MPI of u, the multiplicative inverse of p, mod q. + + Algorithm-Specific Fields for DSA secret keys: + + - MPI of DSA secret exponent x. + + Algorithm-Specific Fields for Elgamal secret keys: + + - MPI of Elgamal secret exponent x. + + Secret MPI values can be encrypted using a passphrase. If a string- + to-key specifier is given, that describes the algorithm for + converting the passphrase to a key, else a simple MD5 hash of the + passphrase is used. Implementations MUST use a string-to-key + specifier; the simple hash is for backward compatibility and is + deprecated, though implementations MAY continue to use existing + private keys in the old format. The cipher for encrypting the MPIs + is specified in the Secret-Key packet. + + Encryption/decryption of the secret data is done in CFB mode using + the key created from the passphrase and the Initial Vector from the + packet. A different mode is used with V3 keys (which are only RSA) + than with other key formats. With V3 keys, the MPI bit count prefix + (i.e., the first two octets) is not encrypted. Only the MPI non- + prefix data is encrypted. Furthermore, the CFB state is + resynchronized at the beginning of each new MPI value, so that the + CFB block boundary is aligned with the start of the MPI data. + + With V4 keys, a simpler method is used. All secret MPI values are + encrypted in CFB mode, including the MPI bitcount prefix. + + The two-octet checksum that follows the algorithm-specific portion is + the algebraic sum, mod 65536, of the plaintext of all the algorithm- + specific octets (including MPI prefix and data). With V3 keys, the + checksum is stored in the clear. With V4 keys, the checksum is + encrypted like the algorithm-specific data. This value is used to + check that the passphrase was correct. However, this checksum is + deprecated; an implementation SHOULD NOT use it, but should rather + use the SHA-1 hash denoted with a usage octet of 254. The reason for + this is that there are some attacks that involve undetectably + modifying the secret key. + + + + + + + + +Callas, et al Standards Track [Page 44] + +RFC 4880 OpenPGP Message Format November 2007 + + +5.6. Compressed Data Packet (Tag 8) + + The Compressed Data packet contains compressed data. Typically, this + packet is found as the contents of an encrypted packet, or following + a Signature or One-Pass Signature packet, and contains a literal data + packet. + + The body of this packet consists of: + + - One octet that gives the algorithm used to compress the packet. + + - Compressed data, which makes up the remainder of the packet. + + A Compressed Data Packet's body contains an block that compresses + some set of packets. See section "Packet Composition" for details on + how messages are formed. + + ZIP-compressed packets are compressed with raw RFC 1951 [RFC1951] + DEFLATE blocks. Note that PGP V2.6 uses 13 bits of compression. If + an implementation uses more bits of compression, PGP V2.6 cannot + decompress it. + + ZLIB-compressed packets are compressed with RFC 1950 [RFC1950] ZLIB- + style blocks. + + BZip2-compressed packets are compressed using the BZip2 [BZ2] + algorithm. + +5.7. Symmetrically Encrypted Data Packet (Tag 9) + + The Symmetrically Encrypted Data packet contains data encrypted with + a symmetric-key algorithm. When it has been decrypted, it contains + other packets (usually a literal data packet or compressed data + packet, but in theory other Symmetrically Encrypted Data packets or + sequences of packets that form whole OpenPGP messages). + + The body of this packet consists of: + + - Encrypted data, the output of the selected symmetric-key cipher + operating in OpenPGP's variant of Cipher Feedback (CFB) mode. + + The symmetric cipher used may be specified in a Public-Key or + Symmetric-Key Encrypted Session Key packet that precedes the + Symmetrically Encrypted Data packet. In that case, the cipher + algorithm octet is prefixed to the session key before it is + encrypted. If no packets of these types precede the encrypted data, + the IDEA algorithm is used with the session key calculated as the MD5 + hash of the passphrase, though this use is deprecated. + + + +Callas, et al Standards Track [Page 45] + +RFC 4880 OpenPGP Message Format November 2007 + + + The data is encrypted in CFB mode, with a CFB shift size equal to the + cipher's block size. The Initial Vector (IV) is specified as all + zeros. Instead of using an IV, OpenPGP prefixes a string of length + equal to the block size of the cipher plus two to the data before it + is encrypted. The first block-size octets (for example, 8 octets for + a 64-bit block length) are random, and the following two octets are + copies of the last two octets of the IV. For example, in an 8-octet + block, octet 9 is a repeat of octet 7, and octet 10 is a repeat of + octet 8. In a cipher of length 16, octet 17 is a repeat of octet 15 + and octet 18 is a repeat of octet 16. As a pedantic clarification, + in both these examples, we consider the first octet to be numbered 1. + + After encrypting the first block-size-plus-two octets, the CFB state + is resynchronized. The last block-size octets of ciphertext are + passed through the cipher and the block boundary is reset. + + The repetition of 16 bits in the random data prefixed to the message + allows the receiver to immediately check whether the session key is + incorrect. See the "Security Considerations" section for hints on + the proper use of this "quick check". + +5.8. Marker Packet (Obsolete Literal Packet) (Tag 10) + + An experimental version of PGP used this packet as the Literal + packet, but no released version of PGP generated Literal packets with + this tag. With PGP 5.x, this packet has been reassigned and is + reserved for use as the Marker packet. + + The body of this packet consists of: + + - The three octets 0x50, 0x47, 0x50 (which spell "PGP" in UTF-8). + + Such a packet MUST be ignored when received. It may be placed at the + beginning of a message that uses features not available in PGP 2.6.x + in order to cause that version to report that newer software is + necessary to process the message. + +5.9. Literal Data Packet (Tag 11) + + A Literal Data packet contains the body of a message; data that is + not to be further interpreted. + + The body of this packet consists of: + + - A one-octet field that describes how the data is formatted. + + + + + + +Callas, et al Standards Track [Page 46] + +RFC 4880 OpenPGP Message Format November 2007 + + + If it is a 'b' (0x62), then the Literal packet contains binary data. + If it is a 't' (0x74), then it contains text data, and thus may need + line ends converted to local form, or other text-mode changes. The + tag 'u' (0x75) means the same as 't', but also indicates that + implementation believes that the literal data contains UTF-8 text. + + Early versions of PGP also defined a value of 'l' as a 'local' mode + for machine-local conversions. RFC 1991 [RFC1991] incorrectly stated + this local mode flag as '1' (ASCII numeral one). Both of these local + modes are deprecated. + + - File name as a string (one-octet length, followed by a file + name). This may be a zero-length string. Commonly, if the + source of the encrypted data is a file, this will be the name of + the encrypted file. An implementation MAY consider the file name + in the Literal packet to be a more authoritative name than the + actual file name. + + If the special name "_CONSOLE" is used, the message is considered to + be "for your eyes only". This advises that the message data is + unusually sensitive, and the receiving program should process it more + carefully, perhaps avoiding storing the received data to disk, for + example. + + - A four-octet number that indicates a date associated with the + literal data. Commonly, the date might be the modification date + of a file, or the time the packet was created, or a zero that + indicates no specific time. + + - The remainder of the packet is literal data. + + Text data is stored with text endings (i.e., network- + normal line endings). These should be converted to native line + endings by the receiving software. + +5.10. Trust Packet (Tag 12) + + The Trust packet is used only within keyrings and is not normally + exported. Trust packets contain data that record the user's + specifications of which key holders are trustworthy introducers, + along with other information that implementing software uses for + trust information. The format of Trust packets is defined by a given + implementation. + + Trust packets SHOULD NOT be emitted to output streams that are + transferred to other users, and they SHOULD be ignored on any input + other than local keyring files. + + + + +Callas, et al Standards Track [Page 47] + +RFC 4880 OpenPGP Message Format November 2007 + + +5.11. User ID Packet (Tag 13) + + A User ID packet consists of UTF-8 text that is intended to represent + the name and email address of the key holder. By convention, it + includes an RFC 2822 [RFC2822] mail name-addr, but there are no + restrictions on its content. The packet length in the header + specifies the length of the User ID. + +5.12. User Attribute Packet (Tag 17) + + The User Attribute packet is a variation of the User ID packet. It + is capable of storing more types of data than the User ID packet, + which is limited to text. Like the User ID packet, a User Attribute + packet may be certified by the key owner ("self-signed") or any other + key owner who cares to certify it. Except as noted, a User Attribute + packet may be used anywhere that a User ID packet may be used. + + While User Attribute packets are not a required part of the OpenPGP + standard, implementations SHOULD provide at least enough + compatibility to properly handle a certification signature on the + User Attribute packet. A simple way to do this is by treating the + User Attribute packet as a User ID packet with opaque contents, but + an implementation may use any method desired. + + The User Attribute packet is made up of one or more attribute + subpackets. Each subpacket consists of a subpacket header and a + body. The header consists of: + + - the subpacket length (1, 2, or 5 octets) + + - the subpacket type (1 octet) + + and is followed by the subpacket specific data. + + The only currently defined subpacket type is 1, signifying an image. + An implementation SHOULD ignore any subpacket of a type that it does + not recognize. Subpacket types 100 through 110 are reserved for + private or experimental use. + +5.12.1. The Image Attribute Subpacket + + The Image Attribute subpacket is used to encode an image, presumably + (but not required to be) that of the key owner. + + The Image Attribute subpacket begins with an image header. The first + two octets of the image header contain the length of the image + header. Note that unlike other multi-octet numerical values in this + document, due to a historical accident this value is encoded as a + + + +Callas, et al Standards Track [Page 48] + +RFC 4880 OpenPGP Message Format November 2007 + + + little-endian number. The image header length is followed by a + single octet for the image header version. The only currently + defined version of the image header is 1, which is a 16-octet image + header. The first three octets of a version 1 image header are thus + 0x10, 0x00, 0x01. + + The fourth octet of a version 1 image header designates the encoding + format of the image. The only currently defined encoding format is + the value 1 to indicate JPEG. Image format types 100 through 110 are + reserved for private or experimental use. The rest of the version 1 + image header is made up of 12 reserved octets, all of which MUST be + set to 0. + + The rest of the image subpacket contains the image itself. As the + only currently defined image type is JPEG, the image is encoded in + the JPEG File Interchange Format (JFIF), a standard file format for + JPEG images [JFIF]. + + An implementation MAY try to determine the type of an image by + examination of the image data if it is unable to handle a particular + version of the image header or if a specified encoding format value + is not recognized. + +5.13. Sym. Encrypted Integrity Protected Data Packet (Tag 18) + + The Symmetrically Encrypted Integrity Protected Data packet is a + variant of the Symmetrically Encrypted Data packet. It is a new + feature created for OpenPGP that addresses the problem of detecting a + modification to encrypted data. It is used in combination with a + Modification Detection Code packet. + + There is a corresponding feature in the features Signature subpacket + that denotes that an implementation can properly use this packet + type. An implementation MUST support decrypting these packets and + SHOULD prefer generating them to the older Symmetrically Encrypted + Data packet when possible. Since this data packet protects against + modification attacks, this standard encourages its proliferation. + While blanket adoption of this data packet would create + interoperability problems, rapid adoption is nevertheless important. + An implementation SHOULD specifically denote support for this packet, + but it MAY infer it from other mechanisms. + + For example, an implementation might infer from the use of a cipher + such as Advanced Encryption Standard (AES) or Twofish that a user + supports this feature. It might place in the unhashed portion of + another user's key signature a Features subpacket. It might also + present a user with an opportunity to regenerate their own self- + signature with a Features subpacket. + + + +Callas, et al Standards Track [Page 49] + +RFC 4880 OpenPGP Message Format November 2007 + + + This packet contains data encrypted with a symmetric-key algorithm + and protected against modification by the SHA-1 hash algorithm. When + it has been decrypted, it will typically contain other packets (often + a Literal Data packet or Compressed Data packet). The last decrypted + packet in this packet's payload MUST be a Modification Detection Code + packet. + + The body of this packet consists of: + + - A one-octet version number. The only currently defined value is + 1. + + - Encrypted data, the output of the selected symmetric-key cipher + operating in Cipher Feedback mode with shift amount equal to the + block size of the cipher (CFB-n where n is the block size). + + The symmetric cipher used MUST be specified in a Public-Key or + Symmetric-Key Encrypted Session Key packet that precedes the + Symmetrically Encrypted Data packet. In either case, the cipher + algorithm octet is prefixed to the session key before it is + encrypted. + + The data is encrypted in CFB mode, with a CFB shift size equal to the + cipher's block size. The Initial Vector (IV) is specified as all + zeros. Instead of using an IV, OpenPGP prefixes an octet string to + the data before it is encrypted. The length of the octet string + equals the block size of the cipher in octets, plus two. The first + octets in the group, of length equal to the block size of the cipher, + are random; the last two octets are each copies of their 2nd + preceding octet. For example, with a cipher whose block size is 128 + bits or 16 octets, the prefix data will contain 16 random octets, + then two more octets, which are copies of the 15th and 16th octets, + respectively. Unlike the Symmetrically Encrypted Data Packet, no + special CFB resynchronization is done after encrypting this prefix + data. See "OpenPGP CFB Mode" below for more details. + + The repetition of 16 bits in the random data prefixed to the message + allows the receiver to immediately check whether the session key is + incorrect. + + The plaintext of the data to be encrypted is passed through the SHA-1 + hash function, and the result of the hash is appended to the + plaintext in a Modification Detection Code packet. The input to the + hash function includes the prefix data described above; it includes + all of the plaintext, and then also includes two octets of values + 0xD3, 0x14. These represent the encoding of a Modification Detection + Code packet tag and length field of 20 octets. + + + + +Callas, et al Standards Track [Page 50] + +RFC 4880 OpenPGP Message Format November 2007 + + + The resulting hash value is stored in a Modification Detection Code + (MDC) packet, which MUST use the two octet encoding just given to + represent its tag and length field. The body of the MDC packet is + the 20-octet output of the SHA-1 hash. + + The Modification Detection Code packet is appended to the plaintext + and encrypted along with the plaintext using the same CFB context. + + During decryption, the plaintext data should be hashed with SHA-1, + including the prefix data as well as the packet tag and length field + of the Modification Detection Code packet. The body of the MDC + packet, upon decryption, is compared with the result of the SHA-1 + hash. + + Any failure of the MDC indicates that the message has been modified + and MUST be treated as a security problem. Failures include a + difference in the hash values, but also the absence of an MDC packet, + or an MDC packet in any position other than the end of the plaintext. + Any failure SHOULD be reported to the user. + + Note: future designs of new versions of this packet should consider + rollback attacks since it will be possible for an attacker to change + the version back to 1. + + NON-NORMATIVE EXPLANATION + + The MDC system, as packets 18 and 19 are called, were created to + provide an integrity mechanism that is less strong than a + signature, yet stronger than bare CFB encryption. + + It is a limitation of CFB encryption that damage to the ciphertext + will corrupt the affected cipher blocks and the block following. + Additionally, if data is removed from the end of a CFB-encrypted + block, that removal is undetectable. (Note also that CBC mode has + a similar limitation, but data removed from the front of the block + is undetectable.) + + The obvious way to protect or authenticate an encrypted block is + to digitally sign it. However, many people do not wish to + habitually sign data, for a large number of reasons beyond the + scope of this document. Suffice it to say that many people + consider properties such as deniability to be as valuable as + integrity. + + OpenPGP addresses this desire to have more security than raw + encryption and yet preserve deniability with the MDC system. An + MDC is intentionally not a MAC. Its name was not selected by + accident. It is analogous to a checksum. + + + +Callas, et al Standards Track [Page 51] + +RFC 4880 OpenPGP Message Format November 2007 + + + Despite the fact that it is a relatively modest system, it has + proved itself in the real world. It is an effective defense to + several attacks that have surfaced since it has been created. It + has met its modest goals admirably. + + Consequently, because it is a modest security system, it has + modest requirements on the hash function(s) it employs. It does + not rely on a hash function being collision-free, it relies on a + hash function being one-way. If a forger, Frank, wishes to send + Alice a (digitally) unsigned message that says, "I've always + secretly loved you, signed Bob", it is far easier for him to + construct a new message than it is to modify anything intercepted + from Bob. (Note also that if Bob wishes to communicate secretly + with Alice, but without authentication or identification and with + a threat model that includes forgers, he has a problem that + transcends mere cryptography.) + + Note also that unlike nearly every other OpenPGP subsystem, there + are no parameters in the MDC system. It hard-defines SHA-1 as its + hash function. This is not an accident. It is an intentional + choice to avoid downgrade and cross-grade attacks while making a + simple, fast system. (A downgrade attack would be an attack that + replaced SHA-256 with SHA-1, for example. A cross-grade attack + would replace SHA-1 with another 160-bit hash, such as RIPE- + MD/160, for example.) + + However, given the present state of hash function cryptanalysis + and cryptography, it may be desirable to upgrade the MDC system to + a new hash function. See Section 13.11 in the "IANA + Considerations" for guidance. + +5.14. Modification Detection Code Packet (Tag 19) + + The Modification Detection Code packet contains a SHA-1 hash of + plaintext data, which is used to detect message modification. It is + only used with a Symmetrically Encrypted Integrity Protected Data + packet. The Modification Detection Code packet MUST be the last + packet in the plaintext data that is encrypted in the Symmetrically + Encrypted Integrity Protected Data packet, and MUST appear in no + other place. + + A Modification Detection Code packet MUST have a length of 20 octets. + + + + + + + + + +Callas, et al Standards Track [Page 52] + +RFC 4880 OpenPGP Message Format November 2007 + + + The body of this packet consists of: + + - A 20-octet SHA-1 hash of the preceding plaintext data of the + Symmetrically Encrypted Integrity Protected Data packet, + including prefix data, the tag octet, and length octet of the + Modification Detection Code packet. + + Note that the Modification Detection Code packet MUST always use a + new format encoding of the packet tag, and a one-octet encoding of + the packet length. The reason for this is that the hashing rules for + modification detection include a one-octet tag and one-octet length + in the data hash. While this is a bit restrictive, it reduces + complexity. + +6. Radix-64 Conversions + + As stated in the introduction, OpenPGP's underlying native + representation for objects is a stream of arbitrary octets, and some + systems desire these objects to be immune to damage caused by + character set translation, data conversions, etc. + + In principle, any printable encoding scheme that met the requirements + of the unsafe channel would suffice, since it would not change the + underlying binary bit streams of the native OpenPGP data structures. + The OpenPGP standard specifies one such printable encoding scheme to + ensure interoperability. + + OpenPGP's Radix-64 encoding is composed of two parts: a base64 + encoding of the binary data and a checksum. The base64 encoding is + identical to the MIME base64 content-transfer-encoding [RFC2045]. + + The checksum is a 24-bit Cyclic Redundancy Check (CRC) converted to + four characters of radix-64 encoding by the same MIME base64 + transformation, preceded by an equal sign (=). The CRC is computed + by using the generator 0x864CFB and an initialization of 0xB704CE. + The accumulation is done on the data before it is converted to + radix-64, rather than on the converted data. A sample implementation + of this algorithm is in the next section. + + The checksum with its leading equal sign MAY appear on the first line + after the base64 encoded data. + + Rationale for CRC-24: The size of 24 bits fits evenly into printable + base64. The nonzero initialization can detect more errors than a + zero initialization. + + + + + + +Callas, et al Standards Track [Page 53] + +RFC 4880 OpenPGP Message Format November 2007 + + +6.1. An Implementation of the CRC-24 in "C" + + #define CRC24_INIT 0xB704CEL + #define CRC24_POLY 0x1864CFBL + + typedef long crc24; + crc24 crc_octets(unsigned char *octets, size_t len) + { + crc24 crc = CRC24_INIT; + int i; + while (len--) { + crc ^= (*octets++) << 16; + for (i = 0; i < 8; i++) { + crc <<= 1; + if (crc & 0x1000000) + crc ^= CRC24_POLY; + } + } + return crc & 0xFFFFFFL; + } + +6.2. Forming ASCII Armor + + When OpenPGP encodes data into ASCII Armor, it puts specific headers + around the Radix-64 encoded data, so OpenPGP can reconstruct the data + later. An OpenPGP implementation MAY use ASCII armor to protect raw + binary data. OpenPGP informs the user what kind of data is encoded + in the ASCII armor through the use of the headers. + + Concatenating the following data creates ASCII Armor: + + - An Armor Header Line, appropriate for the type of data + + - Armor Headers + + - A blank (zero-length, or containing only whitespace) line + + - The ASCII-Armored data + + - An Armor Checksum + + - The Armor Tail, which depends on the Armor Header Line + + An Armor Header Line consists of the appropriate header line text + surrounded by five (5) dashes ('-', 0x2D) on either side of the + header line text. The header line text is chosen based upon the type + of data that is being encoded in Armor, and how it is being encoded. + Header line texts include the following strings: + + + +Callas, et al Standards Track [Page 54] + +RFC 4880 OpenPGP Message Format November 2007 + + + BEGIN PGP MESSAGE + Used for signed, encrypted, or compressed files. + + BEGIN PGP PUBLIC KEY BLOCK + Used for armoring public keys. + + BEGIN PGP PRIVATE KEY BLOCK + Used for armoring private keys. + + BEGIN PGP MESSAGE, PART X/Y + Used for multi-part messages, where the armor is split amongst Y + parts, and this is the Xth part out of Y. + + BEGIN PGP MESSAGE, PART X + Used for multi-part messages, where this is the Xth part of an + unspecified number of parts. Requires the MESSAGE-ID Armor + Header to be used. + + BEGIN PGP SIGNATURE + Used for detached signatures, OpenPGP/MIME signatures, and + cleartext signatures. Note that PGP 2.x uses BEGIN PGP MESSAGE + for detached signatures. + + Note that all these Armor Header Lines are to consist of a complete + line. That is to say, there is always a line ending preceding the + starting five dashes, and following the ending five dashes. The + header lines, therefore, MUST start at the beginning of a line, and + MUST NOT have text other than whitespace following them on the same + line. These line endings are considered a part of the Armor Header + Line for the purposes of determining the content they delimit. This + is particularly important when computing a cleartext signature (see + below). + + The Armor Headers are pairs of strings that can give the user or the + receiving OpenPGP implementation some information about how to decode + or use the message. The Armor Headers are a part of the armor, not a + part of the message, and hence are not protected by any signatures + applied to the message. + + The format of an Armor Header is that of a key-value pair. A colon + (':' 0x38) and a single space (0x20) separate the key and value. + OpenPGP should consider improperly formatted Armor Headers to be + corruption of the ASCII Armor. Unknown keys should be reported to + the user, but OpenPGP should continue to process the message. + + Note that some transport methods are sensitive to line length. While + there is a limit of 76 characters for the Radix-64 data (Section + 6.3), there is no limit to the length of Armor Headers. Care should + + + +Callas, et al Standards Track [Page 55] + +RFC 4880 OpenPGP Message Format November 2007 + + + be taken that the Armor Headers are short enough to survive + transport. One way to do this is to repeat an Armor Header key + multiple times with different values for each so that no one line is + overly long. + + Currently defined Armor Header Keys are as follows: + + - "Version", which states the OpenPGP implementation and version + used to encode the message. + + - "Comment", a user-defined comment. OpenPGP defines all text to + be in UTF-8. A comment may be any UTF-8 string. However, the + whole point of armoring is to provide seven-bit-clean data. + Consequently, if a comment has characters that are outside the + US-ASCII range of UTF, they may very well not survive transport. + + - "MessageID", a 32-character string of printable characters. The + string must be the same for all parts of a multi-part message + that uses the "PART X" Armor Header. MessageID strings should be + unique enough that the recipient of the mail can associate all + the parts of a message with each other. A good checksum or + cryptographic hash function is sufficient. + + The MessageID SHOULD NOT appear unless it is in a multi-part + message. If it appears at all, it MUST be computed from the + finished (encrypted, signed, etc.) message in a deterministic + fashion, rather than contain a purely random value. This is to + allow the legitimate recipient to determine that the MessageID + cannot serve as a covert means of leaking cryptographic key + information. + + - "Hash", a comma-separated list of hash algorithms used in this + message. This is used only in cleartext signed messages. + + - "Charset", a description of the character set that the plaintext + is in. Please note that OpenPGP defines text to be in UTF-8. An + implementation will get best results by translating into and out + of UTF-8. However, there are many instances where this is easier + said than done. Also, there are communities of users who have no + need for UTF-8 because they are all happy with a character set + like ISO Latin-5 or a Japanese character set. In such instances, + an implementation MAY override the UTF-8 default by using this + header key. An implementation MAY implement this key and any + translations it cares to; an implementation MAY ignore it and + assume all text is UTF-8. + + + + + + +Callas, et al Standards Track [Page 56] + +RFC 4880 OpenPGP Message Format November 2007 + + + The Armor Tail Line is composed in the same manner as the Armor + Header Line, except the string "BEGIN" is replaced by the string + "END". + +6.3. Encoding Binary in Radix-64 + + The encoding process represents 24-bit groups of input bits as output + strings of 4 encoded characters. Proceeding from left to right, a + 24-bit input group is formed by concatenating three 8-bit input + groups. These 24 bits are then treated as four concatenated 6-bit + groups, each of which is translated into a single digit in the + Radix-64 alphabet. When encoding a bit stream with the Radix-64 + encoding, the bit stream must be presumed to be ordered with the most + significant bit first. That is, the first bit in the stream will be + the high-order bit in the first 8-bit octet, and the eighth bit will + be the low-order bit in the first 8-bit octet, and so on. + + +--first octet--+-second octet--+--third octet--+ + |7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0| + +-----------+---+-------+-------+---+-----------+ + |5 4 3 2 1 0|5 4 3 2 1 0|5 4 3 2 1 0|5 4 3 2 1 0| + +--1.index--+--2.index--+--3.index--+--4.index--+ + + Each 6-bit group is used as an index into an array of 64 printable + characters from the table below. The character referenced by the + index is placed in the output string. + + Value Encoding Value Encoding Value Encoding Value Encoding + 0 A 17 R 34 i 51 z + 1 B 18 S 35 j 52 0 + 2 C 19 T 36 k 53 1 + 3 D 20 U 37 l 54 2 + 4 E 21 V 38 m 55 3 + 5 F 22 W 39 n 56 4 + 6 G 23 X 40 o 57 5 + 7 H 24 Y 41 p 58 6 + 8 I 25 Z 42 q 59 7 + 9 J 26 a 43 r 60 8 + 10 K 27 b 44 s 61 9 + 11 L 28 c 45 t 62 + + 12 M 29 d 46 u 63 / + 13 N 30 e 47 v + 14 O 31 f 48 w (pad) = + 15 P 32 g 49 x + 16 Q 33 h 50 y + + The encoded output stream must be represented in lines of no more + than 76 characters each. + + + +Callas, et al Standards Track [Page 57] + +RFC 4880 OpenPGP Message Format November 2007 + + + Special processing is performed if fewer than 24 bits are available + at the end of the data being encoded. There are three possibilities: + + 1. The last data group has 24 bits (3 octets). No special processing + is needed. + + 2. The last data group has 16 bits (2 octets). The first two 6-bit + groups are processed as above. The third (incomplete) data group + has two zero-value bits added to it, and is processed as above. A + pad character (=) is added to the output. + + 3. The last data group has 8 bits (1 octet). The first 6-bit group + is processed as above. The second (incomplete) data group has + four zero-value bits added to it, and is processed as above. Two + pad characters (=) are added to the output. + +6.4. Decoding Radix-64 + + In Radix-64 data, characters other than those in the table, line + breaks, and other white space probably indicate a transmission error, + about which a warning message or even a message rejection might be + appropriate under some circumstances. Decoding software must ignore + all white space. + + Because it is used only for padding at the end of the data, the + occurrence of any "=" characters may be taken as evidence that the + end of the data has been reached (without truncation in transit). No + such assurance is possible, however, when the number of octets + transmitted was a multiple of three and no "=" characters are + present. + + + + + + + + + + + + + + + + + + + + + +Callas, et al Standards Track [Page 58] + +RFC 4880 OpenPGP Message Format November 2007 + + +6.5. Examples of Radix-64 + + Input data: 0x14FB9C03D97E + Hex: 1 4 F B 9 C | 0 3 D 9 7 E + 8-bit: 00010100 11111011 10011100 | 00000011 11011001 11111110 + 6-bit: 000101 001111 101110 011100 | 000000 111101 100111 111110 + Decimal: 5 15 46 28 0 61 37 62 + Output: F P u c A 9 l + + Input data: 0x14FB9C03D9 + Hex: 1 4 F B 9 C | 0 3 D 9 + 8-bit: 00010100 11111011 10011100 | 00000011 11011001 + pad with 00 + 6-bit: 000101 001111 101110 011100 | 000000 111101 100100 + Decimal: 5 15 46 28 0 61 36 + pad with = + Output: F P u c A 9 k = + Input data: 0x14FB9C03 + Hex: 1 4 F B 9 C | 0 3 + 8-bit: 00010100 11111011 10011100 | 00000011 + pad with 0000 + 6-bit: 000101 001111 101110 011100 | 000000 110000 + Decimal: 5 15 46 28 0 48 + pad with = = + Output: F P u c A w = = + +6.6. Example of an ASCII Armored Message + + -----BEGIN PGP MESSAGE----- + Version: OpenPrivacy 0.99 + + yDgBO22WxBHv7O8X7O/jygAEzol56iUKiXmV+XmpCtmpqQUKiQrFqclFqUDBovzS + vBSFjNSiVHsuAA== + =njUN + -----END PGP MESSAGE----- + + Note that this example has extra indenting; an actual armored message + would have no leading whitespace. + +7. Cleartext Signature Framework + + It is desirable to be able to sign a textual octet stream without + ASCII armoring the stream itself, so the signed text is still + readable without special software. In order to bind a signature to + such a cleartext, this framework is used. (Note that this framework + is not intended to be reversible. RFC 3156 [RFC3156] defines another + way to sign cleartext messages for environments that support MIME.) + + + + + +Callas, et al Standards Track [Page 59] + +RFC 4880 OpenPGP Message Format November 2007 + + + The cleartext signed message consists of: + + - The cleartext header '-----BEGIN PGP SIGNED MESSAGE-----' on a + single line, + + - One or more "Hash" Armor Headers, + + - Exactly one empty line not included into the message digest, + + - The dash-escaped cleartext that is included into the message + digest, + + - The ASCII armored signature(s) including the '-----BEGIN PGP + SIGNATURE-----' Armor Header and Armor Tail Lines. + + If the "Hash" Armor Header is given, the specified message digest + algorithm(s) are used for the signature. If there are no such + headers, MD5 is used. If MD5 is the only hash used, then an + implementation MAY omit this header for improved V2.x compatibility. + If more than one message digest is used in the signature, the "Hash" + armor header contains a comma-delimited list of used message digests. + + Current message digest names are described below with the algorithm + IDs. + + An implementation SHOULD add a line break after the cleartext, but + MAY omit it if the cleartext ends with a line break. This is for + visual clarity. + +7.1. Dash-Escaped Text + + The cleartext content of the message must also be dash-escaped. + + Dash-escaped cleartext is the ordinary cleartext where every line + starting with a dash '-' (0x2D) is prefixed by the sequence dash '-' + (0x2D) and space ' ' (0x20). This prevents the parser from + recognizing armor headers of the cleartext itself. An implementation + MAY dash-escape any line, SHOULD dash-escape lines commencing "From" + followed by a space, and MUST dash-escape any line commencing in a + dash. The message digest is computed using the cleartext itself, not + the dash-escaped form. + + As with binary signatures on text documents, a cleartext signature is + calculated on the text using canonical line endings. The + line ending (i.e., the ) before the '-----BEGIN PGP + SIGNATURE-----' line that terminates the signed text is not + considered part of the signed text. + + + + +Callas, et al Standards Track [Page 60] + +RFC 4880 OpenPGP Message Format November 2007 + + + When reversing dash-escaping, an implementation MUST strip the string + "- " if it occurs at the beginning of a line, and SHOULD warn on "-" + and any character other than a space at the beginning of a line. + + Also, any trailing whitespace -- spaces (0x20) and tabs (0x09) -- at + the end of any line is removed when the cleartext signature is + generated. + +8. Regular Expressions + + A regular expression is zero or more branches, separated by '|'. It + matches anything that matches one of the branches. + + A branch is zero or more pieces, concatenated. It matches a match + for the first, followed by a match for the second, etc. + + A piece is an atom possibly followed by '*', '+', or '?'. An atom + followed by '*' matches a sequence of 0 or more matches of the atom. + An atom followed by '+' matches a sequence of 1 or more matches of + the atom. An atom followed by '?' matches a match of the atom, or + the null string. + + An atom is a regular expression in parentheses (matching a match for + the regular expression), a range (see below), '.' (matching any + single character), '^' (matching the null string at the beginning of + the input string), '$' (matching the null string at the end of the + input string), a '\' followed by a single character (matching that + character), or a single character with no other significance + (matching that character). + + A range is a sequence of characters enclosed in '[]'. It normally + matches any single character from the sequence. If the sequence + begins with '^', it matches any single character not from the rest of + the sequence. If two characters in the sequence are separated + by '-', this is shorthand for the full list of ASCII characters + between them (e.g., '[0-9]' matches any decimal digit). To include a + literal ']' in the sequence, make it the first character (following a + possible '^'). To include a literal '-', make it the first or last + character. + +9. Constants + + This section describes the constants used in OpenPGP. + + Note that these tables are not exhaustive lists; an implementation + MAY implement an algorithm not on these lists, so long as the + algorithm numbers are chosen from the private or experimental + algorithm range. + + + +Callas, et al Standards Track [Page 61] + +RFC 4880 OpenPGP Message Format November 2007 + + + See the section "Notes on Algorithms" below for more discussion of + the algorithms. + +9.1. Public-Key Algorithms + + ID Algorithm + -- --------- + 1 - RSA (Encrypt or Sign) [HAC] + 2 - RSA Encrypt-Only [HAC] + 3 - RSA Sign-Only [HAC] + 16 - Elgamal (Encrypt-Only) [ELGAMAL] [HAC] + 17 - DSA (Digital Signature Algorithm) [FIPS186] [HAC] + 18 - Reserved for Elliptic Curve + 19 - Reserved for ECDSA + 20 - Reserved (formerly Elgamal Encrypt or Sign) + 21 - Reserved for Diffie-Hellman (X9.42, + as defined for IETF-S/MIME) + 100 to 110 - Private/Experimental algorithm + + Implementations MUST implement DSA for signatures, and Elgamal for + encryption. Implementations SHOULD implement RSA keys (1). RSA + Encrypt-Only (2) and RSA Sign-Only are deprecated and SHOULD NOT be + generated, but may be interpreted. See Section 13.5. See Section + 13.8 for notes on Elliptic Curve (18), ECDSA (19), Elgamal Encrypt or + Sign (20), and X9.42 (21). Implementations MAY implement any other + algorithm. + +9.2. Symmetric-Key Algorithms + + ID Algorithm + -- --------- + 0 - Plaintext or unencrypted data + 1 - IDEA [IDEA] + 2 - TripleDES (DES-EDE, [SCHNEIER] [HAC] - + 168 bit key derived from 192) + 3 - CAST5 (128 bit key, as per [RFC2144]) + 4 - Blowfish (128 bit key, 16 rounds) [BLOWFISH] + 5 - Reserved + 6 - Reserved + 7 - AES with 128-bit key [AES] + 8 - AES with 192-bit key + 9 - AES with 256-bit key + 10 - Twofish with 256-bit key [TWOFISH] + 100 to 110 - Private/Experimental algorithm + + Implementations MUST implement TripleDES. Implementations SHOULD + implement AES-128 and CAST5. Implementations that interoperate with + + + + +Callas, et al Standards Track [Page 62] + +RFC 4880 OpenPGP Message Format November 2007 + + + PGP 2.6 or earlier need to support IDEA, as that is the only + symmetric cipher those versions use. Implementations MAY implement + any other algorithm. + +9.3. Compression Algorithms + + ID Algorithm + -- --------- + 0 - Uncompressed + 1 - ZIP [RFC1951] + 2 - ZLIB [RFC1950] + 3 - BZip2 [BZ2] + 100 to 110 - Private/Experimental algorithm + + Implementations MUST implement uncompressed data. Implementations + SHOULD implement ZIP. Implementations MAY implement any other + algorithm. + +9.4. Hash Algorithms + + ID Algorithm Text Name + -- --------- --------- + 1 - MD5 [HAC] "MD5" + 2 - SHA-1 [FIPS180] "SHA1" + 3 - RIPE-MD/160 [HAC] "RIPEMD160" + 4 - Reserved + 5 - Reserved + 6 - Reserved + 7 - Reserved + 8 - SHA256 [FIPS180] "SHA256" + 9 - SHA384 [FIPS180] "SHA384" + 10 - SHA512 [FIPS180] "SHA512" + 11 - SHA224 [FIPS180] "SHA224" + 100 to 110 - Private/Experimental algorithm + + Implementations MUST implement SHA-1. Implementations MAY implement + other algorithms. MD5 is deprecated. + +10. IANA Considerations + + OpenPGP is highly parameterized, and consequently there are a number + of considerations for allocating parameters for extensions. This + section describes how IANA should look at extensions to the protocol + as described in this document. + + + + + + + +Callas, et al Standards Track [Page 63] + +RFC 4880 OpenPGP Message Format November 2007 + + +10.1. New String-to-Key Specifier Types + + OpenPGP S2K specifiers contain a mechanism for new algorithms to turn + a string into a key. This specification creates a registry of S2K + specifier types. The registry includes the S2K type, the name of the + S2K, and a reference to the defining specification. The initial + values for this registry can be found in Section 3.7.1. Adding a new + S2K specifier MUST be done through the IETF CONSENSUS method, as + described in [RFC2434]. + +10.2. New Packets + + Major new features of OpenPGP are defined through new packet types. + This specification creates a registry of packet types. The registry + includes the packet type, the name of the packet, and a reference to + the defining specification. The initial values for this registry can + be found in Section 4.3. Adding a new packet type MUST be done + through the IETF CONSENSUS method, as described in [RFC2434]. + +10.2.1. User Attribute Types + + The User Attribute packet permits an extensible mechanism for other + types of certificate identification. This specification creates a + registry of User Attribute types. The registry includes the User + Attribute type, the name of the User Attribute, and a reference to + the defining specification. The initial values for this registry can + be found in Section 5.12. Adding a new User Attribute type MUST be + done through the IETF CONSENSUS method, as described in [RFC2434]. + +10.2.1.1. Image Format Subpacket Types + + Within User Attribute packets, there is an extensible mechanism for + other types of image-based user attributes. This specification + creates a registry of Image Attribute subpacket types. The registry + includes the Image Attribute subpacket type, the name of the Image + Attribute subpacket, and a reference to the defining specification. + The initial values for this registry can be found in Section 5.12.1. + Adding a new Image Attribute subpacket type MUST be done through the + IETF CONSENSUS method, as described in [RFC2434]. + +10.2.2. New Signature Subpackets + + OpenPGP signatures contain a mechanism for signed (or unsigned) data + to be added to them for a variety of purposes in the Signature + subpackets as discussed in Section 5.2.3.1. This specification + creates a registry of Signature subpacket types. The registry + includes the Signature subpacket type, the name of the subpacket, and + a reference to the defining specification. The initial values for + + + +Callas, et al Standards Track [Page 64] + +RFC 4880 OpenPGP Message Format November 2007 + + + this registry can be found in Section 5.2.3.1. Adding a new + Signature subpacket MUST be done through the IETF CONSENSUS method, + as described in [RFC2434]. + +10.2.2.1. Signature Notation Data Subpackets + + OpenPGP signatures further contain a mechanism for extensions in + signatures. These are the Notation Data subpackets, which contain a + key/value pair. Notations contain a user space that is completely + unmanaged and an IETF space. + + This specification creates a registry of Signature Notation Data + types. The registry includes the Signature Notation Data type, the + name of the Signature Notation Data, its allowed values, and a + reference to the defining specification. The initial values for this + registry can be found in Section 5.2.3.16. Adding a new Signature + Notation Data subpacket MUST be done through the EXPERT REVIEW + method, as described in [RFC2434]. + +10.2.2.2. Key Server Preference Extensions + + OpenPGP signatures contain a mechanism for preferences to be + specified about key servers. This specification creates a registry + of key server preferences. The registry includes the key server + preference, the name of the preference, and a reference to the + defining specification. The initial values for this registry can be + found in Section 5.2.3.17. Adding a new key server preference MUST + be done through the IETF CONSENSUS method, as described in [RFC2434]. + +10.2.2.3. Key Flags Extensions + + OpenPGP signatures contain a mechanism for flags to be specified + about key usage. This specification creates a registry of key usage + flags. The registry includes the key flags value, the name of the + flag, and a reference to the defining specification. The initial + values for this registry can be found in Section 5.2.3.21. Adding a + new key usage flag MUST be done through the IETF CONSENSUS method, as + described in [RFC2434]. + +10.2.2.4. Reason for Revocation Extensions + + OpenPGP signatures contain a mechanism for flags to be specified + about why a key was revoked. This specification creates a registry + of "Reason for Revocation" flags. The registry includes the "Reason + for Revocation" flags value, the name of the flag, and a reference to + the defining specification. The initial values for this registry can + be found in Section 5.2.3.23. Adding a new feature flag MUST be done + through the IETF CONSENSUS method, as described in [RFC2434]. + + + +Callas, et al Standards Track [Page 65] + +RFC 4880 OpenPGP Message Format November 2007 + + +10.2.2.5. Implementation Features + + OpenPGP signatures contain a mechanism for flags to be specified + stating which optional features an implementation supports. This + specification creates a registry of feature-implementation flags. + The registry includes the feature-implementation flags value, the + name of the flag, and a reference to the defining specification. The + initial values for this registry can be found in Section 5.2.3.24. + Adding a new feature-implementation flag MUST be done through the + IETF CONSENSUS method, as described in [RFC2434]. + + Also see Section 13.12 for more information about when feature flags + are needed. + +10.2.3. New Packet Versions + + The core OpenPGP packets all have version numbers, and can be revised + by introducing a new version of an existing packet. This + specification creates a registry of packet types. The registry + includes the packet type, the number of the version, and a reference + to the defining specification. The initial values for this registry + can be found in Section 5. Adding a new packet version MUST be done + through the IETF CONSENSUS method, as described in [RFC2434]. + +10.3. New Algorithms + + Section 9 lists the core algorithms that OpenPGP uses. Adding in a + new algorithm is usually simple. For example, adding in a new + symmetric cipher usually would not need anything more than allocating + a constant for that cipher. If that cipher had other than a 64-bit + or 128-bit block size, there might need to be additional + documentation describing how OpenPGP-CFB mode would be adjusted. + Similarly, when DSA was expanded from a maximum of 1024-bit public + keys to 3072-bit public keys, the revision of FIPS 186 contained + enough information itself to allow implementation. Changes to this + document were made mainly for emphasis. + +10.3.1. Public-Key Algorithms + + OpenPGP specifies a number of public-key algorithms. This + specification creates a registry of public-key algorithm identifiers. + The registry includes the algorithm name, its key sizes and + parameters, and a reference to the defining specification. The + initial values for this registry can be found in Section 9. Adding a + new public-key algorithm MUST be done through the IETF CONSENSUS + method, as described in [RFC2434]. + + + + + +Callas, et al Standards Track [Page 66] + +RFC 4880 OpenPGP Message Format November 2007 + + +10.3.2. Symmetric-Key Algorithms + + OpenPGP specifies a number of symmetric-key algorithms. This + specification creates a registry of symmetric-key algorithm + identifiers. The registry includes the algorithm name, its key sizes + and block size, and a reference to the defining specification. The + initial values for this registry can be found in Section 9. Adding a + new symmetric-key algorithm MUST be done through the IETF CONSENSUS + method, as described in [RFC2434]. + +10.3.3. Hash Algorithms + + OpenPGP specifies a number of hash algorithms. This specification + creates a registry of hash algorithm identifiers. The registry + includes the algorithm name, a text representation of that name, its + block size, an OID hash prefix, and a reference to the defining + specification. The initial values for this registry can be found in + Section 9 for the algorithm identifiers and text names, and Section + 5.2.2 for the OIDs and expanded signature prefixes. Adding a new + hash algorithm MUST be done through the IETF CONSENSUS method, as + described in [RFC2434]. + +10.3.4. Compression Algorithms + + OpenPGP specifies a number of compression algorithms. This + specification creates a registry of compression algorithm + identifiers. The registry includes the algorithm name and a + reference to the defining specification. The initial values for this + registry can be found in Section 9.3. Adding a new compression key + algorithm MUST be done through the IETF CONSENSUS method, as + described in [RFC2434]. + +11. Packet Composition + + OpenPGP packets are assembled into sequences in order to create + messages and to transfer keys. Not all possible packet sequences are + meaningful and correct. This section describes the rules for how + packets should be placed into sequences. + +11.1. Transferable Public Keys + + OpenPGP users may transfer public keys. The essential elements of a + transferable public key are as follows: + + - One Public-Key packet + + - Zero or more revocation signatures + + + + +Callas, et al Standards Track [Page 67] + +RFC 4880 OpenPGP Message Format November 2007 + + + - One or more User ID packets + + - After each User ID packet, zero or more Signature packets + (certifications) + + - Zero or more User Attribute packets + + - After each User Attribute packet, zero or more Signature packets + (certifications) + + - Zero or more Subkey packets + + - After each Subkey packet, one Signature packet, plus optionally a + revocation + + The Public-Key packet occurs first. Each of the following User ID + packets provides the identity of the owner of this public key. If + there are multiple User ID packets, this corresponds to multiple + means of identifying the same unique individual user; for example, a + user may have more than one email address, and construct a User ID + for each one. + + Immediately following each User ID packet, there are zero or more + Signature packets. Each Signature packet is calculated on the + immediately preceding User ID packet and the initial Public-Key + packet. The signature serves to certify the corresponding public key + and User ID. In effect, the signer is testifying to his or her + belief that this public key belongs to the user identified by this + User ID. + + Within the same section as the User ID packets, there are zero or + more User Attribute packets. Like the User ID packets, a User + Attribute packet is followed by zero or more Signature packets + calculated on the immediately preceding User Attribute packet and the + initial Public-Key packet. + + User Attribute packets and User ID packets may be freely intermixed + in this section, so long as the signatures that follow them are + maintained on the proper User Attribute or User ID packet. + + After the User ID packet or Attribute packet, there may be zero or + more Subkey packets. In general, subkeys are provided in cases where + the top-level public key is a signature-only key. However, any V4 + key may have subkeys, and the subkeys may be encryption-only keys, + signature-only keys, or general-purpose keys. V3 keys MUST NOT have + subkeys. + + + + + +Callas, et al Standards Track [Page 68] + +RFC 4880 OpenPGP Message Format November 2007 + + + Each Subkey packet MUST be followed by one Signature packet, which + should be a subkey binding signature issued by the top-level key. + For subkeys that can issue signatures, the subkey binding signature + MUST contain an Embedded Signature subpacket with a primary key + binding signature (0x19) issued by the subkey on the top-level key. + + Subkey and Key packets may each be followed by a revocation Signature + packet to indicate that the key is revoked. Revocation signatures + are only accepted if they are issued by the key itself, or by a key + that is authorized to issue revocations via a Revocation Key + subpacket in a self-signature by the top-level key. + + Transferable public-key packet sequences may be concatenated to allow + transferring multiple public keys in one operation. + +11.2. Transferable Secret Keys + + OpenPGP users may transfer secret keys. The format of a transferable + secret key is the same as a transferable public key except that + secret-key and secret-subkey packets are used instead of the public + key and public-subkey packets. Implementations SHOULD include self- + signatures on any user IDs and subkeys, as this allows for a complete + public key to be automatically extracted from the transferable secret + key. Implementations MAY choose to omit the self-signatures, + especially if a transferable public key accompanies the transferable + secret key. + +11.3. OpenPGP Messages + + An OpenPGP message is a packet or sequence of packets that + corresponds to the following grammatical rules (comma represents + sequential composition, and vertical bar separates alternatives): + + OpenPGP Message :- Encrypted Message | Signed Message | + Compressed Message | Literal Message. + + Compressed Message :- Compressed Data Packet. + + Literal Message :- Literal Data Packet. + + ESK :- Public-Key Encrypted Session Key Packet | + Symmetric-Key Encrypted Session Key Packet. + + ESK Sequence :- ESK | ESK Sequence, ESK. + + Encrypted Data :- Symmetrically Encrypted Data Packet | + Symmetrically Encrypted Integrity Protected Data Packet + + + + +Callas, et al Standards Track [Page 69] + +RFC 4880 OpenPGP Message Format November 2007 + + + Encrypted Message :- Encrypted Data | ESK Sequence, Encrypted Data. + + One-Pass Signed Message :- One-Pass Signature Packet, + OpenPGP Message, Corresponding Signature Packet. + + Signed Message :- Signature Packet, OpenPGP Message | + One-Pass Signed Message. + + In addition, decrypting a Symmetrically Encrypted Data packet or a + Symmetrically Encrypted Integrity Protected Data packet as well as + decompressing a Compressed Data packet must yield a valid OpenPGP + Message. + +11.4. Detached Signatures + + Some OpenPGP applications use so-called "detached signatures". For + example, a program bundle may contain a file, and with it a second + file that is a detached signature of the first file. These detached + signatures are simply a Signature packet stored separately from the + data for which they are a signature. + +12. Enhanced Key Formats + +12.1. Key Structures + + The format of an OpenPGP V3 key is as follows. Entries in square + brackets are optional and ellipses indicate repetition. + + RSA Public Key + [Revocation Self Signature] + User ID [Signature ...] + [User ID [Signature ...] ...] + + Each signature certifies the RSA public key and the preceding User + ID. The RSA public key can have many User IDs and each User ID can + have many signatures. V3 keys are deprecated. Implementations MUST + NOT generate new V3 keys, but MAY continue to use existing ones. + + The format of an OpenPGP V4 key that uses multiple public keys is + similar except that the other keys are added to the end as "subkeys" + of the primary key. + + + + + + + + + + +Callas, et al Standards Track [Page 70] + +RFC 4880 OpenPGP Message Format November 2007 + + + Primary-Key + [Revocation Self Signature] + [Direct Key Signature...] + User ID [Signature ...] + [User ID [Signature ...] ...] + [User Attribute [Signature ...] ...] + [[Subkey [Binding-Signature-Revocation] + Primary-Key-Binding-Signature] ...] + + A subkey always has a single signature after it that is issued using + the primary key to tie the two keys together. This binding signature + may be in either V3 or V4 format, but SHOULD be V4. Subkeys that can + issue signatures MUST have a V4 binding signature due to the REQUIRED + embedded primary key binding signature. + + In the above diagram, if the binding signature of a subkey has been + revoked, the revoked key may be removed, leaving only one key. + + In a V4 key, the primary key MUST be a key capable of certification. + The subkeys may be keys of any other type. There may be other + constructions of V4 keys, too. For example, there may be a single- + key RSA key in V4 format, a DSA primary key with an RSA encryption + key, or RSA primary key with an Elgamal subkey, etc. + + It is also possible to have a signature-only subkey. This permits a + primary key that collects certifications (key signatures), but is + used only for certifying subkeys that are used for encryption and + signatures. + +12.2. Key IDs and Fingerprints + + For a V3 key, the eight-octet Key ID consists of the low 64 bits of + the public modulus of the RSA key. + + The fingerprint of a V3 key is formed by hashing the body (but not + the two-octet length) of the MPIs that form the key material (public + modulus n, followed by exponent e) with MD5. Note that both V3 keys + and MD5 are deprecated. + + A V4 fingerprint is the 160-bit SHA-1 hash of the octet 0x99, + followed by the two-octet packet length, followed by the entire + Public-Key packet starting with the version field. The Key ID is the + low-order 64 bits of the fingerprint. Here are the fields of the + hash material, with the example of a DSA key: + + a.1) 0x99 (1 octet) + + a.2) high-order length octet of (b)-(e) (1 octet) + + + +Callas, et al Standards Track [Page 71] + +RFC 4880 OpenPGP Message Format November 2007 + + + a.3) low-order length octet of (b)-(e) (1 octet) + + b) version number = 4 (1 octet); + + c) timestamp of key creation (4 octets); + + d) algorithm (1 octet): 17 = DSA (example); + + e) Algorithm-specific fields. + + Algorithm-Specific Fields for DSA keys (example): + + e.1) MPI of DSA prime p; + + e.2) MPI of DSA group order q (q is a prime divisor of p-1); + + e.3) MPI of DSA group generator g; + + e.4) MPI of DSA public-key value y (= g**x mod p where x is secret). + + Note that it is possible for there to be collisions of Key IDs -- two + different keys with the same Key ID. Note that there is a much + smaller, but still non-zero, probability that two different keys have + the same fingerprint. + + Also note that if V3 and V4 format keys share the same RSA key + material, they will have different Key IDs as well as different + fingerprints. + + Finally, the Key ID and fingerprint of a subkey are calculated in the + same way as for a primary key, including the 0x99 as the first octet + (even though this is not a valid packet ID for a public subkey). + +13. Notes on Algorithms + +13.1. PKCS#1 Encoding in OpenPGP + + This standard makes use of the PKCS#1 functions EME-PKCS1-v1_5 and + EMSA-PKCS1-v1_5. However, the calling conventions of these functions + has changed in the past. To avoid potential confusion and + interoperability problems, we are including local copies in this + document, adapted from those in PKCS#1 v2.1 [RFC3447]. RFC 3447 + should be treated as the ultimate authority on PKCS#1 for OpenPGP. + Nonetheless, we believe that there is value in having a self- + contained document that avoids problems in the future with needed + changes in the conventions. + + + + + +Callas, et al Standards Track [Page 72] + +RFC 4880 OpenPGP Message Format November 2007 + + +13.1.1. EME-PKCS1-v1_5-ENCODE + + Input: + + k = the length in octets of the key modulus + + M = message to be encoded, an octet string of length mLen, where + mLen <= k - 11 + + Output: + + EM = encoded message, an octet string of length k + + Error: "message too long" + + 1. Length checking: If mLen > k - 11, output "message too long" and + stop. + + 2. Generate an octet string PS of length k - mLen - 3 consisting of + pseudo-randomly generated nonzero octets. The length of PS will + be at least eight octets. + + 3. Concatenate PS, the message M, and other padding to form an + encoded message EM of length k octets as + + EM = 0x00 || 0x02 || PS || 0x00 || M. + + 4. Output EM. + +13.1.2. EME-PKCS1-v1_5-DECODE + + Input: + + EM = encoded message, an octet string + + Output: + + M = message, an octet string + + Error: "decryption error" + + To decode an EME-PKCS1_v1_5 message, separate the encoded message EM + into an octet string PS consisting of nonzero octets and a message M + as follows + + EM = 0x00 || 0x02 || PS || 0x00 || M. + + + + + +Callas, et al Standards Track [Page 73] + +RFC 4880 OpenPGP Message Format November 2007 + + + If the first octet of EM does not have hexadecimal value 0x00, if the + second octet of EM does not have hexadecimal value 0x02, if there is + no octet with hexadecimal value 0x00 to separate PS from M, or if the + length of PS is less than 8 octets, output "decryption error" and + stop. See also the security note in Section 14 regarding differences + in reporting between a decryption error and a padding error. + +13.1.3. EMSA-PKCS1-v1_5 + + This encoding method is deterministic and only has an encoding + operation. + + Option: + + Hash - a hash function in which hLen denotes the length in octets of + the hash function output + + Input: + + M = message to be encoded + + mL = intended length in octets of the encoded message, at least tLen + + 11, where tLen is the octet length of the DER encoding T of a + certain value computed during the encoding operation + + Output: + + EM = encoded message, an octet string of length emLen + + Errors: "message too long"; "intended encoded message length too + short" + + Steps: + + 1. Apply the hash function to the message M to produce a hash value + H: + + H = Hash(M). + + If the hash function outputs "message too long," output "message + too long" and stop. + + 2. Using the list in Section 5.2.2, produce an ASN.1 DER value for + the hash function used. Let T be the full hash prefix from + Section 5.2.2, and let tLen be the length in octets of T. + + 3. If emLen < tLen + 11, output "intended encoded message length + too short" and stop. + + + +Callas, et al Standards Track [Page 74] + +RFC 4880 OpenPGP Message Format November 2007 + + + 4. Generate an octet string PS consisting of emLen - tLen - 3 + octets with hexadecimal value 0xFF. The length of PS will be at + least 8 octets. + + 5. Concatenate PS, the hash prefix T, and other padding to form the + encoded message EM as + + EM = 0x00 || 0x01 || PS || 0x00 || T. + + 6. Output EM. + +13.2. Symmetric Algorithm Preferences + + The symmetric algorithm preference is an ordered list of algorithms + that the keyholder accepts. Since it is found on a self-signature, + it is possible that a keyholder may have multiple, different + preferences. For example, Alice may have TripleDES only specified + for "alice@work.com" but CAST5, Blowfish, and TripleDES specified for + "alice@home.org". Note that it is also possible for preferences to + be in a subkey's binding signature. + + Since TripleDES is the MUST-implement algorithm, if it is not + explicitly in the list, it is tacitly at the end. However, it is + good form to place it there explicitly. Note also that if an + implementation does not implement the preference, then it is + implicitly a TripleDES-only implementation. + + An implementation MUST NOT use a symmetric algorithm that is not in + the recipient's preference list. When encrypting to more than one + recipient, the implementation finds a suitable algorithm by taking + the intersection of the preferences of the recipients. Note that the + MUST-implement algorithm, TripleDES, ensures that the intersection is + not null. The implementation may use any mechanism to pick an + algorithm in the intersection. + + If an implementation can decrypt a message that a keyholder doesn't + have in their preferences, the implementation SHOULD decrypt the + message anyway, but MUST warn the keyholder that the protocol has + been violated. For example, suppose that Alice, above, has software + that implements all algorithms in this specification. Nonetheless, + she prefers subsets for work or home. If she is sent a message + encrypted with IDEA, which is not in her preferences, the software + warns her that someone sent her an IDEA-encrypted message, but it + would ideally decrypt it anyway. + + + + + + + +Callas, et al Standards Track [Page 75] + +RFC 4880 OpenPGP Message Format November 2007 + + +13.3. Other Algorithm Preferences + + Other algorithm preferences work similarly to the symmetric algorithm + preference, in that they specify which algorithms the keyholder + accepts. There are two interesting cases that other comments need to + be made about, though, the compression preferences and the hash + preferences. + +13.3.1. Compression Preferences + + Compression has been an integral part of PGP since its first days. + OpenPGP and all previous versions of PGP have offered compression. + In this specification, the default is for messages to be compressed, + although an implementation is not required to do so. Consequently, + the compression preference gives a way for a keyholder to request + that messages not be compressed, presumably because they are using a + minimal implementation that does not include compression. + Additionally, this gives a keyholder a way to state that it can + support alternate algorithms. + + Like the algorithm preferences, an implementation MUST NOT use an + algorithm that is not in the preference vector. If the preferences + are not present, then they are assumed to be [ZIP(1), + Uncompressed(0)]. + + Additionally, an implementation MUST implement this preference to the + degree of recognizing when to send an uncompressed message. A robust + implementation would satisfy this requirement by looking at the + recipient's preference and acting accordingly. A minimal + implementation can satisfy this requirement by never generating a + compressed message, since all implementations can handle messages + that have not been compressed. + +13.3.2. Hash Algorithm Preferences + + Typically, the choice of a hash algorithm is something the signer + does, rather than the verifier, because a signer rarely knows who is + going to be verifying the signature. This preference, though, allows + a protocol based upon digital signatures ease in negotiation. + + Thus, if Alice is authenticating herself to Bob with a signature, it + makes sense for her to use a hash algorithm that Bob's software uses. + This preference allows Bob to state in his key which algorithms Alice + may use. + + Since SHA1 is the MUST-implement hash algorithm, if it is not + explicitly in the list, it is tacitly at the end. However, it is + good form to place it there explicitly. + + + +Callas, et al Standards Track [Page 76] + +RFC 4880 OpenPGP Message Format November 2007 + + +13.4. Plaintext + + Algorithm 0, "plaintext", may only be used to denote secret keys that + are stored in the clear. Implementations MUST NOT use plaintext in + Symmetrically Encrypted Data packets; they must use Literal Data + packets to encode unencrypted or literal data. + +13.5. RSA + + There are algorithm types for RSA Sign-Only, and RSA Encrypt-Only + keys. These types are deprecated. The "key flags" subpacket in a + signature is a much better way to express the same idea, and + generalizes it to all algorithms. An implementation SHOULD NOT + create such a key, but MAY interpret it. + + An implementation SHOULD NOT implement RSA keys of size less than + 1024 bits. + +13.6. DSA + + An implementation SHOULD NOT implement DSA keys of size less than + 1024 bits. It MUST NOT implement a DSA key with a q size of less + than 160 bits. DSA keys MUST also be a multiple of 64 bits, and the + q size MUST be a multiple of 8 bits. The Digital Signature Standard + (DSS) [FIPS186] specifies that DSA be used in one of the following + ways: + + * 1024-bit key, 160-bit q, SHA-1, SHA-224, SHA-256, SHA-384, or + SHA-512 hash + + * 2048-bit key, 224-bit q, SHA-224, SHA-256, SHA-384, or SHA-512 + hash + + * 2048-bit key, 256-bit q, SHA-256, SHA-384, or SHA-512 hash + + * 3072-bit key, 256-bit q, SHA-256, SHA-384, or SHA-512 hash + + The above key and q size pairs were chosen to best balance the + strength of the key with the strength of the hash. Implementations + SHOULD use one of the above key and q size pairs when generating DSA + keys. If DSS compliance is desired, one of the specified SHA hashes + must be used as well. [FIPS186] is the ultimate authority on DSS, + and should be consulted for all questions of DSS compliance. + + Note that earlier versions of this standard only allowed a 160-bit q + with no truncation allowed, so earlier implementations may not be + able to handle signatures with a different q size or a truncated + hash. + + + +Callas, et al Standards Track [Page 77] + +RFC 4880 OpenPGP Message Format November 2007 + + +13.7. Elgamal + + An implementation SHOULD NOT implement Elgamal keys of size less than + 1024 bits. + +13.8. Reserved Algorithm Numbers + + A number of algorithm IDs have been reserved for algorithms that + would be useful to use in an OpenPGP implementation, yet there are + issues that prevent an implementer from actually implementing the + algorithm. These are marked in Section 9.1, "Public-Key Algorithms", + as "reserved for". + + The reserved public-key algorithms, Elliptic Curve (18), ECDSA (19), + and X9.42 (21), do not have the necessary parameters, parameter + order, or semantics defined. + + Previous versions of OpenPGP permitted Elgamal [ELGAMAL] signatures + with a public-key identifier of 20. These are no longer permitted. + An implementation MUST NOT generate such keys. An implementation + MUST NOT generate Elgamal signatures. See [BLEICHENBACHER]. + +13.9. OpenPGP CFB Mode + + OpenPGP does symmetric encryption using a variant of Cipher Feedback + mode (CFB mode). This section describes the procedure it uses in + detail. This mode is what is used for Symmetrically Encrypted Data + Packets; the mechanism used for encrypting secret-key material is + similar, and is described in the sections above. + + In the description below, the value BS is the block size in octets of + the cipher. Most ciphers have a block size of 8 octets. The AES and + Twofish have a block size of 16 octets. Also note that the + description below assumes that the IV and CFB arrays start with an + index of 1 (unlike the C language, which assumes arrays start with a + zero index). + + OpenPGP CFB mode uses an initialization vector (IV) of all zeros, and + prefixes the plaintext with BS+2 octets of random data, such that + octets BS+1 and BS+2 match octets BS-1 and BS. It does a CFB + resynchronization after encrypting those BS+2 octets. + + Thus, for an algorithm that has a block size of 8 octets (64 bits), + the IV is 10 octets long and octets 7 and 8 of the IV are the same as + octets 9 and 10. For an algorithm with a block size of 16 octets + (128 bits), the IV is 18 octets long, and octets 17 and 18 replicate + octets 15 and 16. Those extra two octets are an easy check for a + correct key. + + + +Callas, et al Standards Track [Page 78] + +RFC 4880 OpenPGP Message Format November 2007 + + + Step by step, here is the procedure: + + 1. The feedback register (FR) is set to the IV, which is all zeros. + + 2. FR is encrypted to produce FRE (FR Encrypted). This is the + encryption of an all-zero value. + + 3. FRE is xored with the first BS octets of random data prefixed to + the plaintext to produce C[1] through C[BS], the first BS octets + of ciphertext. + + 4. FR is loaded with C[1] through C[BS]. + + 5. FR is encrypted to produce FRE, the encryption of the first BS + octets of ciphertext. + + 6. The left two octets of FRE get xored with the next two octets of + data that were prefixed to the plaintext. This produces C[BS+1] + and C[BS+2], the next two octets of ciphertext. + + 7. (The resynchronization step) FR is loaded with C[3] through + C[BS+2]. + + 8. FR is encrypted to produce FRE. + + 9. FRE is xored with the first BS octets of the given plaintext, now + that we have finished encrypting the BS+2 octets of prefixed + data. This produces C[BS+3] through C[BS+(BS+2)], the next BS + octets of ciphertext. + + 10. FR is loaded with C[BS+3] to C[BS + (BS+2)] (which is C11-C18 for + an 8-octet block). + + 11. FR is encrypted to produce FRE. + + 12. FRE is xored with the next BS octets of plaintext, to produce + the next BS octets of ciphertext. These are loaded into FR, and + the process is repeated until the plaintext is used up. + +13.10. Private or Experimental Parameters + + S2K specifiers, Signature subpacket types, user attribute types, + image format types, and algorithms described in Section 9 all reserve + the range 100 to 110 for private and experimental use. Packet types + reserve the range 60 to 63 for private and experimental use. These + are intentionally managed with the PRIVATE USE method, as described + in [RFC2434]. + + + + +Callas, et al Standards Track [Page 79] + +RFC 4880 OpenPGP Message Format November 2007 + + + However, implementations need to be careful with these and promote + them to full IANA-managed parameters when they grow beyond the + original, limited system. + +13.11. Extension of the MDC System + + As described in the non-normative explanation in Section 5.13, the + MDC system is uniquely unparameterized in OpenPGP. This was an + intentional decision to avoid cross-grade attacks. If the MDC system + is extended to a stronger hash function, care must be taken to avoid + downgrade and cross-grade attacks. + + One simple way to do this is to create new packets for a new MDC. + For example, instead of the MDC system using packets 18 and 19, a new + MDC could use 20 and 21. This has obvious drawbacks (it uses two + packet numbers for each new hash function in a space that is limited + to a maximum of 60). + + Another simple way to extend the MDC system is to create new versions + of packet 18, and reflect this in packet 19. For example, suppose + that V2 of packet 18 implicitly used SHA-256. This would require + packet 19 to have a length of 32 octets. The change in the version + in packet 18 and the size of packet 19 prevent a downgrade attack. + + There are two drawbacks to this latter approach. The first is that + using the version number of a packet to carry algorithm information + is not tidy from a protocol-design standpoint. It is possible that + there might be several versions of the MDC system in common use, but + this untidiness would reflect untidiness in cryptographic consensus + about hash function security. The second is that different versions + of packet 19 would have to have unique sizes. If there were two + versions each with 256-bit hashes, they could not both have 32-octet + packet 19s without admitting the chance of a cross-grade attack. + + Yet another, complex approach to extend the MDC system would be a + hybrid of the two above -- create a new pair of MDC packets that are + fully parameterized, and yet protected from downgrade and cross- + grade. + + Any change to the MDC system MUST be done through the IETF CONSENSUS + method, as described in [RFC2434]. + +13.12. Meta-Considerations for Expansion + + If OpenPGP is extended in a way that is not backwards-compatible, + meaning that old implementations will not gracefully handle their + + + + + +Callas, et al Standards Track [Page 80] + +RFC 4880 OpenPGP Message Format November 2007 + + + absence of a new feature, the extension proposal can be declared in + the key holder's self-signature as part of the Features signature + subpacket. + + We cannot state definitively what extensions will not be upwards- + compatible, but typically new algorithms are upwards-compatible, + whereas new packets are not. + + If an extension proposal does not update the Features system, it + SHOULD include an explanation of why this is unnecessary. If the + proposal contains neither an extension to the Features system nor an + explanation of why such an extension is unnecessary, the proposal + SHOULD be rejected. + +14. Security Considerations + + * As with any technology involving cryptography, you should check the + current literature to determine if any algorithms used here have + been found to be vulnerable to attack. + + * This specification uses Public-Key Cryptography technologies. It + is assumed that the private key portion of a public-private key + pair is controlled and secured by the proper party or parties. + + * Certain operations in this specification involve the use of random + numbers. An appropriate entropy source should be used to generate + these numbers (see [RFC4086]). + + * The MD5 hash algorithm has been found to have weaknesses, with + collisions found in a number of cases. MD5 is deprecated for use + in OpenPGP. Implementations MUST NOT generate new signatures using + MD5 as a hash function. They MAY continue to consider old + signatures that used MD5 as valid. + + * SHA-224 and SHA-384 require the same work as SHA-256 and SHA-512, + respectively. In general, there are few reasons to use them + outside of DSS compatibility. You need a situation where one needs + more security than smaller hashes, but does not want to have the + full 256-bit or 512-bit data length. + + * Many security protocol designers think that it is a bad idea to use + a single key for both privacy (encryption) and integrity + (signatures). In fact, this was one of the motivating forces + behind the V4 key format with separate signature and encryption + keys. If you as an implementer promote dual-use keys, you should + at least be aware of this controversy. + + + + + +Callas, et al Standards Track [Page 81] + +RFC 4880 OpenPGP Message Format November 2007 + + + * The DSA algorithm will work with any hash, but is sensitive to the + quality of the hash algorithm. Verifiers should be aware that even + if the signer used a strong hash, an attacker could have modified + the signature to use a weak one. Only signatures using acceptably + strong hash algorithms should be accepted as valid. + + * As OpenPGP combines many different asymmetric, symmetric, and hash + algorithms, each with different measures of strength, care should + be taken that the weakest element of an OpenPGP message is still + sufficiently strong for the purpose at hand. While consensus about + the strength of a given algorithm may evolve, NIST Special + Publication 800-57 [SP800-57] recommends the following list of + equivalent strengths: + + Asymmetric | Hash | Symmetric + key size | size | key size + ------------+--------+----------- + 1024 160 80 + 2048 224 112 + 3072 256 128 + 7680 384 192 + 15360 512 256 + + * There is a somewhat-related potential security problem in + signatures. If an attacker can find a message that hashes to the + same hash with a different algorithm, a bogus signature structure + can be constructed that evaluates correctly. + + For example, suppose Alice DSA signs message M using hash algorithm + H. Suppose that Mallet finds a message M' that has the same hash + value as M with H'. Mallet can then construct a signature block + that verifies as Alice's signature of M' with H'. However, this + would also constitute a weakness in either H or H' or both. Should + this ever occur, a revision will have to be made to this document + to revise the allowed hash algorithms. + + * If you are building an authentication system, the recipient may + specify a preferred signing algorithm. However, the signer would + be foolish to use a weak algorithm simply because the recipient + requests it. + + * Some of the encryption algorithms mentioned in this document have + been analyzed less than others. For example, although CAST5 is + presently considered strong, it has been analyzed less than + TripleDES. Other algorithms may have other controversies + surrounding them. + + + + + +Callas, et al Standards Track [Page 82] + +RFC 4880 OpenPGP Message Format November 2007 + + + * In late summer 2002, Jallad, Katz, and Schneier published an + interesting attack on the OpenPGP protocol and some of its + implementations [JKS02]. In this attack, the attacker modifies a + message and sends it to a user who then returns the erroneously + decrypted message to the attacker. The attacker is thus using the + user as a random oracle, and can often decrypt the message. + + Compressing data can ameliorate this attack. The incorrectly + decrypted data nearly always decompresses in ways that defeat the + attack. However, this is not a rigorous fix, and leaves open some + small vulnerabilities. For example, if an implementation does not + compress a message before encryption (perhaps because it knows it + was already compressed), then that message is vulnerable. Because + of this happenstance -- that modification attacks can be thwarted + by decompression errors -- an implementation SHOULD treat a + decompression error as a security problem, not merely a data + problem. + + This attack can be defeated by the use of Modification Detection, + provided that the implementation does not let the user naively + return the data to the attacker. An implementation MUST treat an + MDC failure as a security problem, not merely a data problem. + + In either case, the implementation MAY allow the user access to the + erroneous data, but MUST warn the user as to potential security + problems should that data be returned to the sender. + + While this attack is somewhat obscure, requiring a special set of + circumstances to create it, it is nonetheless quite serious as it + permits someone to trick a user to decrypt a message. + Consequently, it is important that: + + 1. Implementers treat MDC errors and decompression failures as + security problems. + + 2. Implementers implement Modification Detection with all due + speed and encourage its spread. + + 3. Users migrate to implementations that support Modification + Detection with all due speed. + + * PKCS#1 has been found to be vulnerable to attacks in which a system + that reports errors in padding differently from errors in + decryption becomes a random oracle that can leak the private key in + mere millions of queries. Implementations must be aware of this + attack and prevent it from happening. The simplest solution is to + report a single error code for all variants of decryption errors so + as not to leak information to an attacker. + + + +Callas, et al Standards Track [Page 83] + +RFC 4880 OpenPGP Message Format November 2007 + + + * Some technologies mentioned here may be subject to government + control in some countries. + + * In winter 2005, Serge Mister and Robert Zuccherato from Entrust + released a paper describing a way that the "quick check" in OpenPGP + CFB mode can be used with a random oracle to decrypt two octets of + every cipher block [MZ05]. They recommend as prevention not using + the quick check at all. + + Many implementers have taken this advice to heart for any data that + is symmetrically encrypted and for which the session key is + public-key encrypted. In this case, the quick check is not needed + as the public-key encryption of the session key should guarantee + that it is the right session key. In other cases, the + implementation should use the quick check with care. + + On the one hand, there is a danger to using it if there is a random + oracle that can leak information to an attacker. In plainer + language, there is a danger to using the quick check if timing + information about the check can be exposed to an attacker, + particularly via an automated service that allows rapidly repeated + queries. + + On the other hand, it is inconvenient to the user to be informed + that they typed in the wrong passphrase only after a petabyte of + data is decrypted. There are many cases in cryptographic + engineering where the implementer must use care and wisdom, and + this is one. + +15. Implementation Nits + + This section is a collection of comments to help an implementer, + particularly with an eye to backward compatibility. Previous + implementations of PGP are not OpenPGP compliant. Often the + differences are small, but small differences are frequently more + vexing than large differences. Thus, this is a non-comprehensive + list of potential problems and gotchas for a developer who is trying + to be backward-compatible. + + * The IDEA algorithm is patented, and yet it is required for PGP + 2.x interoperability. It is also the de-facto preferred + algorithm for a V3 key with a V3 self-signature (or no self- + signature). + + * When exporting a private key, PGP 2.x generates the header "BEGIN + PGP SECRET KEY BLOCK" instead of "BEGIN PGP PRIVATE KEY BLOCK". + All previous versions ignore the implied data type, and look + directly at the packet data type. + + + +Callas, et al Standards Track [Page 84] + +RFC 4880 OpenPGP Message Format November 2007 + + + * PGP 2.0 through 2.5 generated V2 Public-Key packets. These are + identical to the deprecated V3 keys except for the version + number. An implementation MUST NOT generate them and may accept + or reject them as it sees fit. Some older PGP versions generated + V2 PKESK packets (Tag 1) as well. An implementation may accept + or reject V2 PKESK packets as it sees fit, and MUST NOT generate + them. + + * PGP 2.6.x will not accept key-material packets with versions + greater than 3. + + * There are many ways possible for two keys to have the same key + material, but different fingerprints (and thus Key IDs). Perhaps + the most interesting is an RSA key that has been "upgraded" to V4 + format, but since a V4 fingerprint is constructed by hashing the + key creation time along with other things, two V4 keys created at + different times, yet with the same key material will have + different fingerprints. + + * If an implementation is using zlib to interoperate with PGP 2.x, + then the "windowBits" parameter should be set to -13. + + * The 0x19 back signatures were not required for signing subkeys + until relatively recently. Consequently, there may be keys in + the wild that do not have these back signatures. Implementing + software may handle these keys as it sees fit. + + * OpenPGP does not put limits on the size of public keys. However, + larger keys are not necessarily better keys. Larger keys take + more computation time to use, and this can quickly become + impractical. Different OpenPGP implementations may also use + different upper bounds for public key sizes, and so care should + be taken when choosing sizes to maintain interoperability. As of + 2007 most implementations have an upper bound of 4096 bits. + + * ASCII armor is an optional feature of OpenPGP. The OpenPGP + working group strives for a minimal set of mandatory-to-implement + features, and since there could be useful implementations that + only use binary object formats, this is not a "MUST" feature for + an implementation. For example, an implementation that is using + OpenPGP as a mechanism for file signatures may find ASCII armor + unnecessary. OpenPGP permits an implementation to declare what + features it does and does not support, but ASCII armor is not one + of these. Since most implementations allow binary and armored + objects to be used indiscriminately, an implementation that does + not implement ASCII armor may find itself with compatibility + issues with general-purpose implementations. Moreover, + implementations of OpenPGP-MIME [RFC3156] already have a + + + +Callas, et al Standards Track [Page 85] + +RFC 4880 OpenPGP Message Format November 2007 + + + requirement for ASCII armor so those implementations will + necessarily have support. + +16. References + +16.1. Normative References + + [AES] NIST, FIPS PUB 197, "Advanced Encryption Standard + (AES)," November 2001. + http://csrc.nist.gov/publications/fips/fips197/fips- + 197.{ps,pdf} + + [BLOWFISH] Schneier, B. "Description of a New Variable-Length + Key, 64-Bit Block Cipher (Blowfish)" Fast Software + Encryption, Cambridge Security Workshop Proceedings + (December 1993), Springer-Verlag, 1994, pp191-204 + + + [BZ2] J. Seward, jseward@acm.org, "The Bzip2 and libbzip2 + home page" + + [ELGAMAL] T. Elgamal, "A Public-Key Cryptosystem and a + Signature Scheme Based on Discrete Logarithms," IEEE + Transactions on Information Theory, v. IT-31, n. 4, + 1985, pp. 469-472. + + [FIPS180] Secure Hash Signature Standard (SHS) (FIPS PUB 180- + 2). + + + [FIPS186] Digital Signature Standard (DSS) (FIPS PUB 186-2). + FIPS 186-3 describes keys + greater than 1024 bits. The latest draft is at: + + + [HAC] Alfred Menezes, Paul van Oorschot, and Scott + Vanstone, "Handbook of Applied Cryptography," CRC + Press, 1996. + + + [IDEA] Lai, X, "On the design and security of block + ciphers", ETH Series in Information Processing, J.L. + Massey (editor), Vol. 1, Hartung-Gorre Verlag + Knostanz, Technische Hochschule (Zurich), 1992 + + + + +Callas, et al Standards Track [Page 86] + +RFC 4880 OpenPGP Message Format November 2007 + + + [ISO10646] ISO/IEC 10646-1:1993. International Standard -- + Information technology -- Universal Multiple-Octet + Coded Character Set (UCS) -- Part 1: Architecture + and Basic Multilingual Plane. + + [JFIF] JPEG File Interchange Format (Version 1.02). Eric + Hamilton, C-Cube Microsystems, Milpitas, CA, + September 1, 1992. + + [RFC1950] Deutsch, P. and J-L. Gailly, "ZLIB Compressed Data + Format Specification version 3.3", RFC 1950, May + 1996. + + [RFC1951] Deutsch, P., "DEFLATE Compressed Data Format + Specification version 1.3", RFC 1951, May 1996. + + [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet + Mail Extensions (MIME) Part One: Format of Internet + Message Bodies", RFC 2045, November 1996 + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2144] Adams, C., "The CAST-128 Encryption Algorithm", RFC + 2144, May 1997. + + [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for + Writing an IANA Considerations Section in RFCs", BCP + 26, RFC 2434, October 1998. + + [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, + April 2001. + + [RFC3156] Elkins, M., Del Torto, D., Levien, R., and T. + Roessler, "MIME Security with OpenPGP", RFC 3156, + August 2001. + + [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography + Standards (PKCS) #1: RSA Cryptography Specifications + Version 2.1", RFC 3447, February 2003. + + [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO + 10646", STD 63, RFC 3629, November 2003. + + [RFC4086] Eastlake, D., 3rd, Schiller, J., and S. Crocker, + "Randomness Requirements for Security", BCP 106, RFC + 4086, June 2005. + + + + +Callas, et al Standards Track [Page 87] + +RFC 4880 OpenPGP Message Format November 2007 + + + [SCHNEIER] Schneier, B., "Applied Cryptography Second Edition: + protocols, algorithms, and source code in C", 1996. + + [TWOFISH] B. Schneier, J. Kelsey, D. Whiting, D. Wagner, C. + Hall, and N. Ferguson, "The Twofish Encryption + Algorithm", John Wiley & Sons, 1999. + +16.2. Informative References + + [BLEICHENBACHER] Bleichenbacher, Daniel, "Generating Elgamal + signatures without knowing the secret key," + Eurocrypt 96. Note that the version in the + proceedings has an error. A revised version is + available at the time of writing from + + + [JKS02] Kahil Jallad, Jonathan Katz, Bruce Schneier + "Implementation of Chosen-Ciphertext Attacks against + PGP and GnuPG" http://www.counterpane.com/pgp- + attack.html + + [MAURER] Ueli Maurer, "Modelling a Public-Key + Infrastructure", Proc. 1996 European Symposium on + Research in Computer Security (ESORICS' 96), Lecture + Notes in Computer Science, Springer-Verlag, vol. + 1146, pp. 325-350, Sep 1996. + + [MZ05] Serge Mister, Robert Zuccherato, "An Attack on CFB + Mode Encryption As Used By OpenPGP," IACR ePrint + Archive: Report 2005/033, 8 Feb 2005 + http://eprint.iacr.org/2005/033 + + [REGEX] Jeffrey Friedl, "Mastering Regular Expressions," + O'Reilly, ISBN 0-596-00289-0. + + [RFC1423] Balenson, D., "Privacy Enhancement for Internet + Electronic Mail: Part III: Algorithms, Modes, and + Identifiers", RFC 1423, February 1993. + + [RFC1991] Atkins, D., Stallings, W., and P. Zimmermann, "PGP + Message Exchange Formats", RFC 1991, August 1996. + + [RFC2440] Callas, J., Donnerhacke, L., Finney, H., and R. + Thayer, "OpenPGP Message Format", RFC 2440, November + 1998. + + + + + +Callas, et al Standards Track [Page 88] + +RFC 4880 OpenPGP Message Format November 2007 + + + [SP800-57] NIST Special Publication 800-57, Recommendation on + Key Management + + + +Acknowledgements + + This memo also draws on much previous work from a number of other + authors, including: Derek Atkins, Charles Breed, Dave Del Torto, Marc + Dyksterhouse, Gail Haspert, Gene Hoffman, Paul Hoffman, Ben Laurie, + Raph Levien, Colin Plumb, Will Price, David Shaw, William Stallings, + Mark Weaver, and Philip R. Zimmermann. + +Authors' Addresses + + The working group can be contacted via the current chair: + + Derek Atkins + IHTFP Consulting, Inc. + 4 Farragut Ave + Somerville, MA 02144 USA + + EMail: derek@ihtfp.com + Tel: +1 617 623 3745 + + The principal authors of this document are as follows: + + Jon Callas + EMail: jon@callas.org + + Lutz Donnerhacke + IKS GmbH + Wildenbruchstr. 15 + 07745 Jena, Germany + EMail: lutz@iks-jena.de + + Hal Finney + EMail: hal@finney.org + + David Shaw + EMail: dshaw@jabberwocky.com + + Rodney Thayer + EMail: rodney@canola-jones.com + + + + + +Callas, et al Standards Track [Page 89] + +RFC 4880 OpenPGP Message Format November 2007 + + +Full Copyright Statement + + Copyright (C) The IETF Trust (2007). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND + THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS + OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF + THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + + + + + + + + + + + + +Callas, et al Standards Track [Page 90] + diff --git a/RFCs/rfc5246.txt b/RFCs/rfc5246.txt new file mode 100644 index 0000000..869c345 --- /dev/null +++ b/RFCs/rfc5246.txt @@ -0,0 +1,5827 @@ + + + + + + +Network Working Group T. Dierks +Request for Comments: 5246 Independent +Obsoletes: 3268, 4346, 4366 E. Rescorla +Updates: 4492 RTFM, Inc. +Category: Standards Track August 2008 + + + The Transport Layer Security (TLS) Protocol + Version 1.2 + +Status of This Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Abstract + + This document specifies Version 1.2 of the Transport Layer Security + (TLS) protocol. The TLS protocol provides communications security + over the Internet. The protocol allows client/server applications to + communicate in a way that is designed to prevent eavesdropping, + tampering, or message forgery. + +Table of Contents + + 1. Introduction ....................................................4 + 1.1. Requirements Terminology ...................................5 + 1.2. Major Differences from TLS 1.1 .............................5 + 2. Goals ...........................................................6 + 3. Goals of This Document ..........................................7 + 4. Presentation Language ...........................................7 + 4.1. Basic Block Size ...........................................7 + 4.2. Miscellaneous ..............................................8 + 4.3. Vectors ....................................................8 + 4.4. Numbers ....................................................9 + 4.5. Enumerateds ................................................9 + 4.6. Constructed Types .........................................10 + 4.6.1. Variants ...........................................10 + 4.7. Cryptographic Attributes ..................................12 + 4.8. Constants .................................................14 + 5. HMAC and the Pseudorandom Function .............................14 + 6. The TLS Record Protocol ........................................15 + 6.1. Connection States .........................................16 + 6.2. Record Layer ..............................................19 + 6.2.1. Fragmentation ......................................19 + + + +Dierks & Rescorla Standards Track [Page 1] + +RFC 5246 TLS August 2008 + + + 6.2.2. Record Compression and Decompression ...............20 + 6.2.3. Record Payload Protection ..........................21 + 6.2.3.1. Null or Standard Stream Cipher ............22 + 6.2.3.2. CBC Block Cipher ..........................22 + 6.2.3.3. AEAD Ciphers ..............................24 + 6.3. Key Calculation ...........................................25 + 7. The TLS Handshaking Protocols ..................................26 + 7.1. Change Cipher Spec Protocol ...............................27 + 7.2. Alert Protocol ............................................28 + 7.2.1. Closure Alerts .....................................29 + 7.2.2. Error Alerts .......................................30 + 7.3. Handshake Protocol Overview ...............................33 + 7.4. Handshake Protocol ........................................37 + 7.4.1. Hello Messages .....................................38 + 7.4.1.1. Hello Request .............................38 + 7.4.1.2. Client Hello ..............................39 + 7.4.1.3. Server Hello ..............................42 + 7.4.1.4. Hello Extensions ..........................44 + 7.4.1.4.1. Signature Algorithms ...........45 + 7.4.2. Server Certificate .................................47 + 7.4.3. Server Key Exchange Message ........................50 + 7.4.4. Certificate Request ................................53 + 7.4.5. Server Hello Done ..................................55 + 7.4.6. Client Certificate .................................55 + 7.4.7. Client Key Exchange Message ........................57 + 7.4.7.1. RSA-Encrypted Premaster Secret Message ....58 + 7.4.7.2. Client Diffie-Hellman Public Value ........61 + 7.4.8. Certificate Verify .................................62 + 7.4.9. Finished ...........................................63 + 8. Cryptographic Computations .....................................64 + 8.1. Computing the Master Secret ...............................64 + 8.1.1. RSA ................................................65 + 8.1.2. Diffie-Hellman .....................................65 + 9. Mandatory Cipher Suites ........................................65 + 10. Application Data Protocol .....................................65 + 11. Security Considerations .......................................65 + 12. IANA Considerations ...........................................65 + Appendix A. Protocol Data Structures and Constant Values ..........68 + A.1. Record Layer ..............................................68 + A.2. Change Cipher Specs Message ...............................69 + A.3. Alert Messages ............................................69 + A.4. Handshake Protocol ........................................70 + A.4.1. Hello Messages .....................................71 + A.4.2. Server Authentication and Key Exchange Messages ....72 + A.4.3. Client Authentication and Key Exchange Messages ....74 + A.4.4. Handshake Finalization Message .....................74 + A.5. The Cipher Suite ..........................................75 + A.6. The Security Parameters ...................................77 + + + +Dierks & Rescorla Standards Track [Page 2] + +RFC 5246 TLS August 2008 + + + A.7. Changes to RFC 4492 .......................................78 + Appendix B. Glossary ..............................................78 + Appendix C. Cipher Suite Definitions ..............................83 + Appendix D. Implementation Notes ..................................85 + D.1. Random Number Generation and Seeding ......................85 + D.2. Certificates and Authentication ...........................85 + D.3. Cipher Suites .............................................85 + D.4. Implementation Pitfalls ...................................85 + Appendix E. Backward Compatibility ................................87 + E.1. Compatibility with TLS 1.0/1.1 and SSL 3.0 ................87 + E.2. Compatibility with SSL 2.0 ................................88 + E.3. Avoiding Man-in-the-Middle Version Rollback ...............90 + Appendix F. Security Analysis .....................................91 + F.1. Handshake Protocol ........................................91 + F.1.1. Authentication and Key Exchange ....................91 + F.1.1.1. Anonymous Key Exchange ....................91 + F.1.1.2. RSA Key Exchange and Authentication .......92 + F.1.1.3. Diffie-Hellman Key Exchange with + Authentication ............................92 + F.1.2. Version Rollback Attacks ...........................93 + F.1.3. Detecting Attacks Against the Handshake Protocol ...94 + F.1.4. Resuming Sessions ..................................94 + F.2. Protecting Application Data ...............................94 + F.3. Explicit IVs ..............................................95 + F.4. Security of Composite Cipher Modes ........................95 + F.5. Denial of Service .........................................96 + F.6. Final Notes ...............................................96 + Normative References ..............................................97 + Informative References ............................................98 + Working Group Information ........................................101 + Contributors .....................................................101 + + + + + + + + + + + + + + + + + + + + +Dierks & Rescorla Standards Track [Page 3] + +RFC 5246 TLS August 2008 + + +1. Introduction + + The primary goal of the TLS protocol is to provide privacy and data + integrity between two communicating applications. The protocol is + composed of two layers: the TLS Record Protocol and the TLS Handshake + Protocol. At the lowest level, layered on top of some reliable + transport protocol (e.g., TCP [TCP]), is the TLS Record Protocol. + The TLS Record Protocol provides connection security that has two + basic properties: + + - The connection is private. Symmetric cryptography is used for + data encryption (e.g., AES [AES], RC4 [SCH], etc.). The keys for + this symmetric encryption are generated uniquely for each + connection and are based on a secret negotiated by another + protocol (such as the TLS Handshake Protocol). The Record + Protocol can also be used without encryption. + + - The connection is reliable. Message transport includes a message + integrity check using a keyed MAC. Secure hash functions (e.g., + SHA-1, etc.) are used for MAC computations. The Record Protocol + can operate without a MAC, but is generally only used in this mode + while another protocol is using the Record Protocol as a transport + for negotiating security parameters. + + The TLS Record Protocol is used for encapsulation of various higher- + level protocols. One such encapsulated protocol, the TLS Handshake + Protocol, allows the server and client to authenticate each other and + to negotiate an encryption algorithm and cryptographic keys before + the application protocol transmits or receives its first byte of + data. The TLS Handshake Protocol provides connection security that + has three basic properties: + + - The peer's identity can be authenticated using asymmetric, or + public key, cryptography (e.g., RSA [RSA], DSA [DSS], etc.). This + authentication can be made optional, but is generally required for + at least one of the peers. + + - The negotiation of a shared secret is secure: the negotiated + secret is unavailable to eavesdroppers, and for any authenticated + connection the secret cannot be obtained, even by an attacker who + can place himself in the middle of the connection. + + - The negotiation is reliable: no attacker can modify the + negotiation communication without being detected by the parties to + the communication. + + + + + + +Dierks & Rescorla Standards Track [Page 4] + +RFC 5246 TLS August 2008 + + + One advantage of TLS is that it is application protocol independent. + Higher-level protocols can layer on top of the TLS protocol + transparently. The TLS standard, however, does not specify how + protocols add security with TLS; the decisions on how to initiate TLS + handshaking and how to interpret the authentication certificates + exchanged are left to the judgment of the designers and implementors + of protocols that run on top of TLS. + +1.1. Requirements Terminology + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119 [REQ]. + +1.2. Major Differences from TLS 1.1 + + This document is a revision of the TLS 1.1 [TLS1.1] protocol which + contains improved flexibility, particularly for negotiation of + cryptographic algorithms. The major changes are: + + - The MD5/SHA-1 combination in the pseudorandom function (PRF) has + been replaced with cipher-suite-specified PRFs. All cipher suites + in this document use P_SHA256. + + - The MD5/SHA-1 combination in the digitally-signed element has been + replaced with a single hash. Signed elements now include a field + that explicitly specifies the hash algorithm used. + + - Substantial cleanup to the client's and server's ability to + specify which hash and signature algorithms they will accept. + Note that this also relaxes some of the constraints on signature + and hash algorithms from previous versions of TLS. + + - Addition of support for authenticated encryption with additional + data modes. + + - TLS Extensions definition and AES Cipher Suites were merged in + from external [TLSEXT] and [TLSAES]. + + - Tighter checking of EncryptedPreMasterSecret version numbers. + + - Tightened up a number of requirements. + + - Verify_data length now depends on the cipher suite (default is + still 12). + + - Cleaned up description of Bleichenbacher/Klima attack defenses. + + + + +Dierks & Rescorla Standards Track [Page 5] + +RFC 5246 TLS August 2008 + + + - Alerts MUST now be sent in many cases. + + - After a certificate_request, if no certificates are available, + clients now MUST send an empty certificate list. + + - TLS_RSA_WITH_AES_128_CBC_SHA is now the mandatory to implement + cipher suite. + + - Added HMAC-SHA256 cipher suites. + + - Removed IDEA and DES cipher suites. They are now deprecated and + will be documented in a separate document. + + - Support for the SSLv2 backward-compatible hello is now a MAY, not + a SHOULD, with sending it a SHOULD NOT. Support will probably + become a SHOULD NOT in the future. + + - Added limited "fall-through" to the presentation language to allow + multiple case arms to have the same encoding. + + - Added an Implementation Pitfalls sections + + - The usual clarifications and editorial work. + +2. Goals + + The goals of the TLS protocol, in order of priority, are as follows: + + 1. Cryptographic security: TLS should be used to establish a secure + connection between two parties. + + 2. Interoperability: Independent programmers should be able to + develop applications utilizing TLS that can successfully exchange + cryptographic parameters without knowledge of one another's code. + + 3. Extensibility: TLS seeks to provide a framework into which new + public key and bulk encryption methods can be incorporated as + necessary. This will also accomplish two sub-goals: preventing + the need to create a new protocol (and risking the introduction of + possible new weaknesses) and avoiding the need to implement an + entire new security library. + + 4. Relative efficiency: Cryptographic operations tend to be highly + CPU intensive, particularly public key operations. For this + reason, the TLS protocol has incorporated an optional session + caching scheme to reduce the number of connections that need to be + established from scratch. Additionally, care has been taken to + reduce network activity. + + + +Dierks & Rescorla Standards Track [Page 6] + +RFC 5246 TLS August 2008 + + +3. Goals of This Document + + This document and the TLS protocol itself are based on the SSL 3.0 + Protocol Specification as published by Netscape. The differences + between this protocol and SSL 3.0 are not dramatic, but they are + significant enough that the various versions of TLS and SSL 3.0 do + not interoperate (although each protocol incorporates a mechanism by + which an implementation can back down to prior versions). This + document is intended primarily for readers who will be implementing + the protocol and for those doing cryptographic analysis of it. The + specification has been written with this in mind, and it is intended + to reflect the needs of those two groups. For that reason, many of + the algorithm-dependent data structures and rules are included in the + body of the text (as opposed to in an appendix), providing easier + access to them. + + This document is not intended to supply any details of service + definition or of interface definition, although it does cover select + areas of policy as they are required for the maintenance of solid + security. + +4. Presentation Language + + This document deals with the formatting of data in an external + representation. The following very basic and somewhat casually + defined presentation syntax will be used. The syntax draws from + several sources in its structure. Although it resembles the + programming language "C" in its syntax and XDR [XDR] in both its + syntax and intent, it would be risky to draw too many parallels. The + purpose of this presentation language is to document TLS only; it has + no general application beyond that particular goal. + +4.1. Basic Block Size + + The representation of all data items is explicitly specified. The + basic data block size is one byte (i.e., 8 bits). Multiple byte data + items are concatenations of bytes, from left to right, from top to + bottom. From the byte stream, a multi-byte item (a numeric in the + example) is formed (using C notation) by: + + value = (byte[0] << 8*(n-1)) | (byte[1] << 8*(n-2)) | + ... | byte[n-1]; + + This byte ordering for multi-byte values is the commonplace network + byte order or big-endian format. + + + + + + +Dierks & Rescorla Standards Track [Page 7] + +RFC 5246 TLS August 2008 + + +4.2. Miscellaneous + + Comments begin with "/*" and end with "*/". + + Optional components are denoted by enclosing them in "[[ ]]" double + brackets. + + Single-byte entities containing uninterpreted data are of type + opaque. + +4.3. Vectors + + A vector (single-dimensioned array) is a stream of homogeneous data + elements. The size of the vector may be specified at documentation + time or left unspecified until runtime. In either case, the length + declares the number of bytes, not the number of elements, in the + vector. The syntax for specifying a new type, T', that is a fixed- + length vector of type T is + + T T'[n]; + + Here, T' occupies n bytes in the data stream, where n is a multiple + of the size of T. The length of the vector is not included in the + encoded stream. + + In the following example, Datum is defined to be three consecutive + bytes that the protocol does not interpret, while Data is three + consecutive Datum, consuming a total of nine bytes. + + opaque Datum[3]; /* three uninterpreted bytes */ + Datum Data[9]; /* 3 consecutive 3 byte vectors */ + + Variable-length vectors are defined by specifying a subrange of legal + lengths, inclusively, using the notation . When + these are encoded, the actual length precedes the vector's contents + in the byte stream. The length will be in the form of a number + consuming as many bytes as required to hold the vector's specified + maximum (ceiling) length. A variable-length vector with an actual + length field of zero is referred to as an empty vector. + + T T'; + + In the following example, mandatory is a vector that must contain + between 300 and 400 bytes of type opaque. It can never be empty. + The actual length field consumes two bytes, a uint16, which is + sufficient to represent the value 400 (see Section 4.4). On the + other hand, longer can represent up to 800 bytes of data, or 400 + uint16 elements, and it may be empty. Its encoding will include a + + + +Dierks & Rescorla Standards Track [Page 8] + +RFC 5246 TLS August 2008 + + + two-byte actual length field prepended to the vector. The length of + an encoded vector must be an even multiple of the length of a single + element (for example, a 17-byte vector of uint16 would be illegal). + + opaque mandatory<300..400>; + /* length field is 2 bytes, cannot be empty */ + uint16 longer<0..800>; + /* zero to 400 16-bit unsigned integers */ + +4.4. Numbers + + The basic numeric data type is an unsigned byte (uint8). All larger + numeric data types are formed from fixed-length series of bytes + concatenated as described in Section 4.1 and are also unsigned. The + following numeric types are predefined. + + uint8 uint16[2]; + uint8 uint24[3]; + uint8 uint32[4]; + uint8 uint64[8]; + + All values, here and elsewhere in the specification, are stored in + network byte (big-endian) order; the uint32 represented by the hex + bytes 01 02 03 04 is equivalent to the decimal value 16909060. + + Note that in some cases (e.g., DH parameters) it is necessary to + represent integers as opaque vectors. In such cases, they are + represented as unsigned integers (i.e., leading zero octets are not + required even if the most significant bit is set). + +4.5. Enumerateds + + An additional sparse data type is available called enum. A field of + type enum can only assume the values declared in the definition. + Each definition is a different type. Only enumerateds of the same + type may be assigned or compared. Every element of an enumerated + must be assigned a value, as demonstrated in the following example. + Since the elements of the enumerated are not ordered, they can be + assigned any unique value, in any order. + + enum { e1(v1), e2(v2), ... , en(vn) [[, (n)]] } Te; + + An enumerated occupies as much space in the byte stream as would its + maximal defined ordinal value. The following definition would cause + one byte to be used to carry fields of type Color. + + enum { red(3), blue(5), white(7) } Color; + + + + +Dierks & Rescorla Standards Track [Page 9] + +RFC 5246 TLS August 2008 + + + One may optionally specify a value without its associated tag to + force the width definition without defining a superfluous element. + + In the following example, Taste will consume two bytes in the data + stream but can only assume the values 1, 2, or 4. + + enum { sweet(1), sour(2), bitter(4), (32000) } Taste; + + The names of the elements of an enumeration are scoped within the + defined type. In the first example, a fully qualified reference to + the second element of the enumeration would be Color.blue. Such + qualification is not required if the target of the assignment is well + specified. + + Color color = Color.blue; /* overspecified, legal */ + Color color = blue; /* correct, type implicit */ + + For enumerateds that are never converted to external representation, + the numerical information may be omitted. + + enum { low, medium, high } Amount; + +4.6. Constructed Types + + Structure types may be constructed from primitive types for + convenience. Each specification declares a new, unique type. The + syntax for definition is much like that of C. + + struct { + T1 f1; + T2 f2; + ... + Tn fn; + } [[T]]; + + The fields within a structure may be qualified using the type's name, + with a syntax much like that available for enumerateds. For example, + T.f2 refers to the second field of the previous declaration. + Structure definitions may be embedded. + +4.6.1. Variants + + Defined structures may have variants based on some knowledge that is + available within the environment. The selector must be an enumerated + type that defines the possible variants the structure defines. There + must be a case arm for every element of the enumeration declared in + the select. Case arms have limited fall-through: if two case arms + follow in immediate succession with no fields in between, then they + + + +Dierks & Rescorla Standards Track [Page 10] + +RFC 5246 TLS August 2008 + + + both contain the same fields. Thus, in the example below, "orange" + and "banana" both contain V2. Note that this is a new piece of + syntax in TLS 1.2. + + The body of the variant structure may be given a label for reference. + The mechanism by which the variant is selected at runtime is not + prescribed by the presentation language. + + struct { + T1 f1; + T2 f2; + .... + Tn fn; + select (E) { + case e1: Te1; + case e2: Te2; + case e3: case e4: Te3; + .... + case en: Ten; + } [[fv]]; + } [[Tv]]; + + For example: + + enum { apple, orange, banana } VariantTag; + + struct { + uint16 number; + opaque string<0..10>; /* variable length */ + } V1; + + struct { + uint32 number; + opaque string[10]; /* fixed length */ + } V2; + + struct { + select (VariantTag) { /* value of selector is implicit */ + case apple: + V1; /* VariantBody, tag = apple */ + case orange: + case banana: + V2; /* VariantBody, tag = orange or banana */ + } variant_body; /* optional label on variant */ + } VariantRecord; + + + + + + +Dierks & Rescorla Standards Track [Page 11] + +RFC 5246 TLS August 2008 + + +4.7. Cryptographic Attributes + + The five cryptographic operations -- digital signing, stream cipher + encryption, block cipher encryption, authenticated encryption with + additional data (AEAD) encryption, and public key encryption -- are + designated digitally-signed, stream-ciphered, block-ciphered, aead- + ciphered, and public-key-encrypted, respectively. A field's + cryptographic processing is specified by prepending an appropriate + key word designation before the field's type specification. + Cryptographic keys are implied by the current session state (see + Section 6.1). + + A digitally-signed element is encoded as a struct DigitallySigned: + + struct { + SignatureAndHashAlgorithm algorithm; + opaque signature<0..2^16-1>; + } DigitallySigned; + + The algorithm field specifies the algorithm used (see Section + 7.4.1.4.1 for the definition of this field). Note that the + introduction of the algorithm field is a change from previous + versions. The signature is a digital signature using those + algorithms over the contents of the element. The contents themselves + do not appear on the wire but are simply calculated. The length of + the signature is specified by the signing algorithm and key. + + In RSA signing, the opaque vector contains the signature generated + using the RSASSA-PKCS1-v1_5 signature scheme defined in [PKCS1]. As + discussed in [PKCS1], the DigestInfo MUST be DER-encoded [X680] + [X690]. For hash algorithms without parameters (which includes + SHA-1), the DigestInfo.AlgorithmIdentifier.parameters field MUST be + NULL, but implementations MUST accept both without parameters and + with NULL parameters. Note that earlier versions of TLS used a + different RSA signature scheme that did not include a DigestInfo + encoding. + + In DSA, the 20 bytes of the SHA-1 hash are run directly through the + Digital Signing Algorithm with no additional hashing. This produces + two values, r and s. The DSA signature is an opaque vector, as + above, the contents of which are the DER encoding of: + + Dss-Sig-Value ::= SEQUENCE { + r INTEGER, + s INTEGER + } + + + + + +Dierks & Rescorla Standards Track [Page 12] + +RFC 5246 TLS August 2008 + + + Note: In current terminology, DSA refers to the Digital Signature + Algorithm and DSS refers to the NIST standard. In the original SSL + and TLS specs, "DSS" was used universally. This document uses "DSA" + to refer to the algorithm, "DSS" to refer to the standard, and it + uses "DSS" in the code point definitions for historical continuity. + + In stream cipher encryption, the plaintext is exclusive-ORed with an + identical amount of output generated from a cryptographically secure + keyed pseudorandom number generator. + + In block cipher encryption, every block of plaintext encrypts to a + block of ciphertext. All block cipher encryption is done in CBC + (Cipher Block Chaining) mode, and all items that are block-ciphered + will be an exact multiple of the cipher block length. + + In AEAD encryption, the plaintext is simultaneously encrypted and + integrity protected. The input may be of any length, and aead- + ciphered output is generally larger than the input in order to + accommodate the integrity check value. + + In public key encryption, a public key algorithm is used to encrypt + data in such a way that it can be decrypted only with the matching + private key. A public-key-encrypted element is encoded as an opaque + vector <0..2^16-1>, where the length is specified by the encryption + algorithm and key. + + RSA encryption is done using the RSAES-PKCS1-v1_5 encryption scheme + defined in [PKCS1]. + + In the following example + + stream-ciphered struct { + uint8 field1; + uint8 field2; + digitally-signed opaque { + uint8 field3<0..255>; + uint8 field4; + }; + } UserType; + + The contents of the inner struct (field3 and field4) are used as + input for the signature/hash algorithm, and then the entire structure + is encrypted with a stream cipher. The length of this structure, in + bytes, would be equal to two bytes for field1 and field2, plus two + bytes for the signature and hash algorithm, plus two bytes for the + length of the signature, plus the length of the output of the signing + + + + + +Dierks & Rescorla Standards Track [Page 13] + +RFC 5246 TLS August 2008 + + + algorithm. The length of the signature is known because the + algorithm and key used for the signing are known prior to encoding or + decoding this structure. + +4.8. Constants + + Typed constants can be defined for purposes of specification by + declaring a symbol of the desired type and assigning values to it. + + Under-specified types (opaque, variable-length vectors, and + structures that contain opaque) cannot be assigned values. No fields + of a multi-element structure or vector may be elided. + + For example: + + struct { + uint8 f1; + uint8 f2; + } Example1; + + Example1 ex1 = {1, 4}; /* assigns f1 = 1, f2 = 4 */ + +5. HMAC and the Pseudorandom Function + + The TLS record layer uses a keyed Message Authentication Code (MAC) + to protect message integrity. The cipher suites defined in this + document use a construction known as HMAC, described in [HMAC], which + is based on a hash function. Other cipher suites MAY define their + own MAC constructions, if needed. + + In addition, a construction is required to do expansion of secrets + into blocks of data for the purposes of key generation or validation. + This pseudorandom function (PRF) takes as input a secret, a seed, and + an identifying label and produces an output of arbitrary length. + + In this section, we define one PRF, based on HMAC. This PRF with the + SHA-256 hash function is used for all cipher suites defined in this + document and in TLS documents published prior to this document when + TLS 1.2 is negotiated. New cipher suites MUST explicitly specify a + PRF and, in general, SHOULD use the TLS PRF with SHA-256 or a + stronger standard hash function. + + First, we define a data expansion function, P_hash(secret, data), + that uses a single hash function to expand a secret and seed into an + arbitrary quantity of output: + + + + + + +Dierks & Rescorla Standards Track [Page 14] + +RFC 5246 TLS August 2008 + + + P_hash(secret, seed) = HMAC_hash(secret, A(1) + seed) + + HMAC_hash(secret, A(2) + seed) + + HMAC_hash(secret, A(3) + seed) + ... + + where + indicates concatenation. + + A() is defined as: + + A(0) = seed + A(i) = HMAC_hash(secret, A(i-1)) + + P_hash can be iterated as many times as necessary to produce the + required quantity of data. For example, if P_SHA256 is being used to + create 80 bytes of data, it will have to be iterated three times + (through A(3)), creating 96 bytes of output data; the last 16 bytes + of the final iteration will then be discarded, leaving 80 bytes of + output data. + + TLS's PRF is created by applying P_hash to the secret as: + + PRF(secret, label, seed) = P_(secret, label + seed) + + The label is an ASCII string. It should be included in the exact + form it is given without a length byte or trailing null character. + For example, the label "slithy toves" would be processed by hashing + the following bytes: + + 73 6C 69 74 68 79 20 74 6F 76 65 73 + +6. The TLS Record Protocol + + The TLS Record Protocol is a layered protocol. At each layer, + messages may include fields for length, description, and content. + The Record Protocol takes messages to be transmitted, fragments the + data into manageable blocks, optionally compresses the data, applies + a MAC, encrypts, and transmits the result. Received data is + decrypted, verified, decompressed, reassembled, and then delivered to + higher-level clients. + + Four protocols that use the record protocol are described in this + document: the handshake protocol, the alert protocol, the change + cipher spec protocol, and the application data protocol. In order to + allow extension of the TLS protocol, additional record content types + can be supported by the record protocol. New record content type + values are assigned by IANA in the TLS Content Type Registry as + described in Section 12. + + + + + +Dierks & Rescorla Standards Track [Page 15] + +RFC 5246 TLS August 2008 + + + Implementations MUST NOT send record types not defined in this + document unless negotiated by some extension. If a TLS + implementation receives an unexpected record type, it MUST send an + unexpected_message alert. + + Any protocol designed for use over TLS must be carefully designed to + deal with all possible attacks against it. As a practical matter, + this means that the protocol designer must be aware of what security + properties TLS does and does not provide and cannot safely rely on + the latter. + + Note in particular that type and length of a record are not protected + by encryption. If this information is itself sensitive, application + designers may wish to take steps (padding, cover traffic) to minimize + information leakage. + +6.1. Connection States + + A TLS connection state is the operating environment of the TLS Record + Protocol. It specifies a compression algorithm, an encryption + algorithm, and a MAC algorithm. In addition, the parameters for + these algorithms are known: the MAC key and the bulk encryption keys + for the connection in both the read and the write directions. + Logically, there are always four connection states outstanding: the + current read and write states, and the pending read and write states. + All records are processed under the current read and write states. + The security parameters for the pending states can be set by the TLS + Handshake Protocol, and the ChangeCipherSpec can selectively make + either of the pending states current, in which case the appropriate + current state is disposed of and replaced with the pending state; the + pending state is then reinitialized to an empty state. It is illegal + to make a state that has not been initialized with security + parameters a current state. The initial current state always + specifies that no encryption, compression, or MAC will be used. + + The security parameters for a TLS Connection read and write state are + set by providing the following values: + + connection end + Whether this entity is considered the "client" or the "server" in + this connection. + + PRF algorithm + An algorithm used to generate keys from the master secret (see + Sections 5 and 6.3). + + + + + + +Dierks & Rescorla Standards Track [Page 16] + +RFC 5246 TLS August 2008 + + + bulk encryption algorithm + An algorithm to be used for bulk encryption. This specification + includes the key size of this algorithm, whether it is a block, + stream, or AEAD cipher, the block size of the cipher (if + appropriate), and the lengths of explicit and implicit + initialization vectors (or nonces). + + MAC algorithm + An algorithm to be used for message authentication. This + specification includes the size of the value returned by the MAC + algorithm. + + compression algorithm + An algorithm to be used for data compression. This specification + must include all information the algorithm requires to do + compression. + + master secret + A 48-byte secret shared between the two peers in the connection. + + client random + A 32-byte value provided by the client. + + server random + A 32-byte value provided by the server. + + These parameters are defined in the presentation language as: + + enum { server, client } ConnectionEnd; + + enum { tls_prf_sha256 } PRFAlgorithm; + + enum { null, rc4, 3des, aes } + BulkCipherAlgorithm; + + enum { stream, block, aead } CipherType; + + enum { null, hmac_md5, hmac_sha1, hmac_sha256, + hmac_sha384, hmac_sha512} MACAlgorithm; + + enum { null(0), (255) } CompressionMethod; + + /* The algorithms specified in CompressionMethod, PRFAlgorithm, + BulkCipherAlgorithm, and MACAlgorithm may be added to. */ + + + + + + + +Dierks & Rescorla Standards Track [Page 17] + +RFC 5246 TLS August 2008 + + + struct { + ConnectionEnd entity; + PRFAlgorithm prf_algorithm; + BulkCipherAlgorithm bulk_cipher_algorithm; + CipherType cipher_type; + uint8 enc_key_length; + uint8 block_length; + uint8 fixed_iv_length; + uint8 record_iv_length; + MACAlgorithm mac_algorithm; + uint8 mac_length; + uint8 mac_key_length; + CompressionMethod compression_algorithm; + opaque master_secret[48]; + opaque client_random[32]; + opaque server_random[32]; + } SecurityParameters; + + The record layer will use the security parameters to generate the + following six items (some of which are not required by all ciphers, + and are thus empty): + + client write MAC key + server write MAC key + client write encryption key + server write encryption key + client write IV + server write IV + + The client write parameters are used by the server when receiving and + processing records and vice versa. The algorithm used for generating + these items from the security parameters is described in Section 6.3. + + Once the security parameters have been set and the keys have been + generated, the connection states can be instantiated by making them + the current states. These current states MUST be updated for each + record processed. Each connection state includes the following + elements: + + compression state + The current state of the compression algorithm. + + cipher state + The current state of the encryption algorithm. This will consist + of the scheduled key for that connection. For stream ciphers, + this will also contain whatever state information is necessary to + allow the stream to continue to encrypt or decrypt data. + + + + +Dierks & Rescorla Standards Track [Page 18] + +RFC 5246 TLS August 2008 + + + MAC key + The MAC key for this connection, as generated above. + + sequence number + Each connection state contains a sequence number, which is + maintained separately for read and write states. The sequence + number MUST be set to zero whenever a connection state is made the + active state. Sequence numbers are of type uint64 and may not + exceed 2^64-1. Sequence numbers do not wrap. If a TLS + implementation would need to wrap a sequence number, it must + renegotiate instead. A sequence number is incremented after each + record: specifically, the first record transmitted under a + particular connection state MUST use sequence number 0. + +6.2. Record Layer + + The TLS record layer receives uninterpreted data from higher layers + in non-empty blocks of arbitrary size. + +6.2.1. Fragmentation + + The record layer fragments information blocks into TLSPlaintext + records carrying data in chunks of 2^14 bytes or less. Client + message boundaries are not preserved in the record layer (i.e., + multiple client messages of the same ContentType MAY be coalesced + into a single TLSPlaintext record, or a single message MAY be + fragmented across several records). + + struct { + uint8 major; + uint8 minor; + } ProtocolVersion; + + enum { + change_cipher_spec(20), alert(21), handshake(22), + application_data(23), (255) + } ContentType; + + struct { + ContentType type; + ProtocolVersion version; + uint16 length; + opaque fragment[TLSPlaintext.length]; + } TLSPlaintext; + + type + The higher-level protocol used to process the enclosed fragment. + + + + +Dierks & Rescorla Standards Track [Page 19] + +RFC 5246 TLS August 2008 + + + version + The version of the protocol being employed. This document + describes TLS Version 1.2, which uses the version { 3, 3 }. The + version value 3.3 is historical, deriving from the use of {3, 1} + for TLS 1.0. (See Appendix A.1.) Note that a client that + supports multiple versions of TLS may not know what version will + be employed before it receives the ServerHello. See Appendix E + for discussion about what record layer version number should be + employed for ClientHello. + + length + The length (in bytes) of the following TLSPlaintext.fragment. The + length MUST NOT exceed 2^14. + + fragment + The application data. This data is transparent and treated as an + independent block to be dealt with by the higher-level protocol + specified by the type field. + + Implementations MUST NOT send zero-length fragments of Handshake, + Alert, or ChangeCipherSpec content types. Zero-length fragments of + Application data MAY be sent as they are potentially useful as a + traffic analysis countermeasure. + + Note: Data of different TLS record layer content types MAY be + interleaved. Application data is generally of lower precedence for + transmission than other content types. However, records MUST be + delivered to the network in the same order as they are protected by + the record layer. Recipients MUST receive and process interleaved + application layer traffic during handshakes subsequent to the first + one on a connection. + +6.2.2. Record Compression and Decompression + + All records are compressed using the compression algorithm defined in + the current session state. There is always an active compression + algorithm; however, initially it is defined as + CompressionMethod.null. The compression algorithm translates a + TLSPlaintext structure into a TLSCompressed structure. Compression + functions are initialized with default state information whenever a + connection state is made active. [RFC3749] describes compression + algorithms for TLS. + + Compression must be lossless and may not increase the content length + by more than 1024 bytes. If the decompression function encounters a + TLSCompressed.fragment that would decompress to a length in excess of + 2^14 bytes, it MUST report a fatal decompression failure error. + + + + +Dierks & Rescorla Standards Track [Page 20] + +RFC 5246 TLS August 2008 + + + struct { + ContentType type; /* same as TLSPlaintext.type */ + ProtocolVersion version;/* same as TLSPlaintext.version */ + uint16 length; + opaque fragment[TLSCompressed.length]; + } TLSCompressed; + + length + The length (in bytes) of the following TLSCompressed.fragment. + The length MUST NOT exceed 2^14 + 1024. + + fragment + The compressed form of TLSPlaintext.fragment. + + Note: A CompressionMethod.null operation is an identity operation; + no fields are altered. + + Implementation note: Decompression functions are responsible for + ensuring that messages cannot cause internal buffer overflows. + +6.2.3. Record Payload Protection + + The encryption and MAC functions translate a TLSCompressed + structure into a TLSCiphertext. The decryption functions reverse + the process. The MAC of the record also includes a sequence + number so that missing, extra, or repeated messages are + detectable. + + struct { + ContentType type; + ProtocolVersion version; + uint16 length; + select (SecurityParameters.cipher_type) { + case stream: GenericStreamCipher; + case block: GenericBlockCipher; + case aead: GenericAEADCipher; + } fragment; + } TLSCiphertext; + + type + The type field is identical to TLSCompressed.type. + + version + The version field is identical to TLSCompressed.version. + + length + The length (in bytes) of the following TLSCiphertext.fragment. + The length MUST NOT exceed 2^14 + 2048. + + + +Dierks & Rescorla Standards Track [Page 21] + +RFC 5246 TLS August 2008 + + + fragment + The encrypted form of TLSCompressed.fragment, with the MAC. + +6.2.3.1. Null or Standard Stream Cipher + + Stream ciphers (including BulkCipherAlgorithm.null; see Appendix A.6) + convert TLSCompressed.fragment structures to and from stream + TLSCiphertext.fragment structures. + + stream-ciphered struct { + opaque content[TLSCompressed.length]; + opaque MAC[SecurityParameters.mac_length]; + } GenericStreamCipher; + + The MAC is generated as: + + MAC(MAC_write_key, seq_num + + TLSCompressed.type + + TLSCompressed.version + + TLSCompressed.length + + TLSCompressed.fragment); + + where "+" denotes concatenation. + + seq_num + The sequence number for this record. + + MAC + The MAC algorithm specified by SecurityParameters.mac_algorithm. + + Note that the MAC is computed before encryption. The stream cipher + encrypts the entire block, including the MAC. For stream ciphers + that do not use a synchronization vector (such as RC4), the stream + cipher state from the end of one record is simply used on the + subsequent packet. If the cipher suite is TLS_NULL_WITH_NULL_NULL, + encryption consists of the identity operation (i.e., the data is not + encrypted, and the MAC size is zero, implying that no MAC is used). + For both null and stream ciphers, TLSCiphertext.length is + TLSCompressed.length plus SecurityParameters.mac_length. + +6.2.3.2. CBC Block Cipher + + For block ciphers (such as 3DES or AES), the encryption and MAC + functions convert TLSCompressed.fragment structures to and from block + TLSCiphertext.fragment structures. + + + + + + +Dierks & Rescorla Standards Track [Page 22] + +RFC 5246 TLS August 2008 + + + struct { + opaque IV[SecurityParameters.record_iv_length]; + block-ciphered struct { + opaque content[TLSCompressed.length]; + opaque MAC[SecurityParameters.mac_length]; + uint8 padding[GenericBlockCipher.padding_length]; + uint8 padding_length; + }; + } GenericBlockCipher; + + The MAC is generated as described in Section 6.2.3.1. + + IV + The Initialization Vector (IV) SHOULD be chosen at random, and + MUST be unpredictable. Note that in versions of TLS prior to 1.1, + there was no IV field, and the last ciphertext block of the + previous record (the "CBC residue") was used as the IV. This was + changed to prevent the attacks described in [CBCATT]. For block + ciphers, the IV length is of length + SecurityParameters.record_iv_length, which is equal to the + SecurityParameters.block_size. + + padding + Padding that is added to force the length of the plaintext to be + an integral multiple of the block cipher's block length. The + padding MAY be any length up to 255 bytes, as long as it results + in the TLSCiphertext.length being an integral multiple of the + block length. Lengths longer than necessary might be desirable to + frustrate attacks on a protocol that are based on analysis of the + lengths of exchanged messages. Each uint8 in the padding data + vector MUST be filled with the padding length value. The receiver + MUST check this padding and MUST use the bad_record_mac alert to + indicate padding errors. + + padding_length + The padding length MUST be such that the total size of the + GenericBlockCipher structure is a multiple of the cipher's block + length. Legal values range from zero to 255, inclusive. This + length specifies the length of the padding field exclusive of the + padding_length field itself. + + The encrypted data length (TLSCiphertext.length) is one more than the + sum of SecurityParameters.block_length, TLSCompressed.length, + SecurityParameters.mac_length, and padding_length. + + Example: If the block length is 8 bytes, the content length + (TLSCompressed.length) is 61 bytes, and the MAC length is 20 bytes, + then the length before padding is 82 bytes (this does not include the + + + +Dierks & Rescorla Standards Track [Page 23] + +RFC 5246 TLS August 2008 + + + IV. Thus, the padding length modulo 8 must be equal to 6 in order to + make the total length an even multiple of 8 bytes (the block length). + The padding length can be 6, 14, 22, and so on, through 254. If the + padding length were the minimum necessary, 6, the padding would be 6 + bytes, each containing the value 6. Thus, the last 8 octets of the + GenericBlockCipher before block encryption would be xx 06 06 06 06 06 + 06 06, where xx is the last octet of the MAC. + + Note: With block ciphers in CBC mode (Cipher Block Chaining), it is + critical that the entire plaintext of the record be known before any + ciphertext is transmitted. Otherwise, it is possible for the + attacker to mount the attack described in [CBCATT]. + + Implementation note: Canvel et al. [CBCTIME] have demonstrated a + timing attack on CBC padding based on the time required to compute + the MAC. In order to defend against this attack, implementations + MUST ensure that record processing time is essentially the same + whether or not the padding is correct. In general, the best way to + do this is to compute the MAC even if the padding is incorrect, and + only then reject the packet. For instance, if the pad appears to be + incorrect, the implementation might assume a zero-length pad and then + compute the MAC. This leaves a small timing channel, since MAC + performance depends to some extent on the size of the data fragment, + but it is not believed to be large enough to be exploitable, due to + the large block size of existing MACs and the small size of the + timing signal. + +6.2.3.3. AEAD Ciphers + + For AEAD [AEAD] ciphers (such as [CCM] or [GCM]), the AEAD function + converts TLSCompressed.fragment structures to and from AEAD + TLSCiphertext.fragment structures. + + struct { + opaque nonce_explicit[SecurityParameters.record_iv_length]; + aead-ciphered struct { + opaque content[TLSCompressed.length]; + }; + } GenericAEADCipher; + + AEAD ciphers take as input a single key, a nonce, a plaintext, and + "additional data" to be included in the authentication check, as + described in Section 2.1 of [AEAD]. The key is either the + client_write_key or the server_write_key. No MAC key is used. + + Each AEAD cipher suite MUST specify how the nonce supplied to the + AEAD operation is constructed, and what is the length of the + GenericAEADCipher.nonce_explicit part. In many cases, it is + + + +Dierks & Rescorla Standards Track [Page 24] + +RFC 5246 TLS August 2008 + + + appropriate to use the partially implicit nonce technique described + in Section 3.2.1 of [AEAD]; with record_iv_length being the length of + the explicit part. In this case, the implicit part SHOULD be derived + from key_block as client_write_iv and server_write_iv (as described + in Section 6.3), and the explicit part is included in + GenericAEAEDCipher.nonce_explicit. + + The plaintext is the TLSCompressed.fragment. + + The additional authenticated data, which we denote as + additional_data, is defined as follows: + + additional_data = seq_num + TLSCompressed.type + + TLSCompressed.version + TLSCompressed.length; + + where "+" denotes concatenation. + + The aead_output consists of the ciphertext output by the AEAD + encryption operation. The length will generally be larger than + TLSCompressed.length, but by an amount that varies with the AEAD + cipher. Since the ciphers might incorporate padding, the amount of + overhead could vary with different TLSCompressed.length values. Each + AEAD cipher MUST NOT produce an expansion of greater than 1024 bytes. + Symbolically, + + AEADEncrypted = AEAD-Encrypt(write_key, nonce, plaintext, + additional_data) + + In order to decrypt and verify, the cipher takes as input the key, + nonce, the "additional_data", and the AEADEncrypted value. The + output is either the plaintext or an error indicating that the + decryption failed. There is no separate integrity check. That is: + + TLSCompressed.fragment = AEAD-Decrypt(write_key, nonce, + AEADEncrypted, + additional_data) + + If the decryption fails, a fatal bad_record_mac alert MUST be + generated. + +6.3. Key Calculation + + The Record Protocol requires an algorithm to generate keys required + by the current connection state (see Appendix A.6) from the security + parameters provided by the handshake protocol. + + + + + + +Dierks & Rescorla Standards Track [Page 25] + +RFC 5246 TLS August 2008 + + + The master secret is expanded into a sequence of secure bytes, which + is then split to a client write MAC key, a server write MAC key, a + client write encryption key, and a server write encryption key. Each + of these is generated from the byte sequence in that order. Unused + values are empty. Some AEAD ciphers may additionally require a + client write IV and a server write IV (see Section 6.2.3.3). + + When keys and MAC keys are generated, the master secret is used as an + entropy source. + + To generate the key material, compute + + key_block = PRF(SecurityParameters.master_secret, + "key expansion", + SecurityParameters.server_random + + SecurityParameters.client_random); + + until enough output has been generated. Then, the key_block is + partitioned as follows: + + client_write_MAC_key[SecurityParameters.mac_key_length] + server_write_MAC_key[SecurityParameters.mac_key_length] + client_write_key[SecurityParameters.enc_key_length] + server_write_key[SecurityParameters.enc_key_length] + client_write_IV[SecurityParameters.fixed_iv_length] + server_write_IV[SecurityParameters.fixed_iv_length] + + Currently, the client_write_IV and server_write_IV are only generated + for implicit nonce techniques as described in Section 3.2.1 of + [AEAD]. + + Implementation note: The currently defined cipher suite which + requires the most material is AES_256_CBC_SHA256. It requires 2 x 32 + byte keys and 2 x 32 byte MAC keys, for a total 128 bytes of key + material. + +7. The TLS Handshaking Protocols + + TLS has three subprotocols that are used to allow peers to agree upon + security parameters for the record layer, to authenticate themselves, + to instantiate negotiated security parameters, and to report error + conditions to each other. + + The Handshake Protocol is responsible for negotiating a session, + which consists of the following items: + + + + + + +Dierks & Rescorla Standards Track [Page 26] + +RFC 5246 TLS August 2008 + + + session identifier + An arbitrary byte sequence chosen by the server to identify an + active or resumable session state. + + peer certificate + X509v3 [PKIX] certificate of the peer. This element of the state + may be null. + + compression method + The algorithm used to compress data prior to encryption. + + cipher spec + Specifies the pseudorandom function (PRF) used to generate keying + material, the bulk data encryption algorithm (such as null, AES, + etc.) and the MAC algorithm (such as HMAC-SHA1). It also defines + cryptographic attributes such as the mac_length. (See Appendix + A.6 for formal definition.) + + master secret + 48-byte secret shared between the client and server. + + is resumable + A flag indicating whether the session can be used to initiate new + connections. + + These items are then used to create security parameters for use by + the record layer when protecting application data. Many connections + can be instantiated using the same session through the resumption + feature of the TLS Handshake Protocol. + +7.1. Change Cipher Spec Protocol + + The change cipher spec protocol exists to signal transitions in + ciphering strategies. The protocol consists of a single message, + which is encrypted and compressed under the current (not the pending) + connection state. The message consists of a single byte of value 1. + + struct { + enum { change_cipher_spec(1), (255) } type; + } ChangeCipherSpec; + + The ChangeCipherSpec message is sent by both the client and the + server to notify the receiving party that subsequent records will be + protected under the newly negotiated CipherSpec and keys. Reception + of this message causes the receiver to instruct the record layer to + immediately copy the read pending state into the read current state. + Immediately after sending this message, the sender MUST instruct the + record layer to make the write pending state the write active state. + + + +Dierks & Rescorla Standards Track [Page 27] + +RFC 5246 TLS August 2008 + + + (See Section 6.1.) The ChangeCipherSpec message is sent during the + handshake after the security parameters have been agreed upon, but + before the verifying Finished message is sent. + + Note: If a rehandshake occurs while data is flowing on a connection, + the communicating parties may continue to send data using the old + CipherSpec. However, once the ChangeCipherSpec has been sent, the + new CipherSpec MUST be used. The first side to send the + ChangeCipherSpec does not know that the other side has finished + computing the new keying material (e.g., if it has to perform a + time-consuming public key operation). Thus, a small window of time, + during which the recipient must buffer the data, MAY exist. In + practice, with modern machines this interval is likely to be fairly + short. + +7.2. Alert Protocol + + One of the content types supported by the TLS record layer is the + alert type. Alert messages convey the severity of the message + (warning or fatal) and a description of the alert. Alert messages + with a level of fatal result in the immediate termination of the + connection. In this case, other connections corresponding to the + session may continue, but the session identifier MUST be invalidated, + preventing the failed session from being used to establish new + connections. Like other messages, alert messages are encrypted and + compressed, as specified by the current connection state. + + enum { warning(1), fatal(2), (255) } AlertLevel; + + enum { + close_notify(0), + unexpected_message(10), + bad_record_mac(20), + decryption_failed_RESERVED(21), + record_overflow(22), + decompression_failure(30), + handshake_failure(40), + no_certificate_RESERVED(41), + bad_certificate(42), + unsupported_certificate(43), + certificate_revoked(44), + certificate_expired(45), + certificate_unknown(46), + illegal_parameter(47), + unknown_ca(48), + access_denied(49), + decode_error(50), + decrypt_error(51), + + + +Dierks & Rescorla Standards Track [Page 28] + +RFC 5246 TLS August 2008 + + + export_restriction_RESERVED(60), + protocol_version(70), + insufficient_security(71), + internal_error(80), + user_canceled(90), + no_renegotiation(100), + unsupported_extension(110), + (255) + } AlertDescription; + + struct { + AlertLevel level; + AlertDescription description; + } Alert; + +7.2.1. Closure Alerts + + The client and the server must share knowledge that the connection is + ending in order to avoid a truncation attack. Either party may + initiate the exchange of closing messages. + + close_notify + This message notifies the recipient that the sender will not send + any more messages on this connection. Note that as of TLS 1.1, + failure to properly close a connection no longer requires that a + session not be resumed. This is a change from TLS 1.0 to conform + with widespread implementation practice. + + Either party may initiate a close by sending a close_notify alert. + Any data received after a closure alert is ignored. + + Unless some other fatal alert has been transmitted, each party is + required to send a close_notify alert before closing the write side + of the connection. The other party MUST respond with a close_notify + alert of its own and close down the connection immediately, + discarding any pending writes. It is not required for the initiator + of the close to wait for the responding close_notify alert before + closing the read side of the connection. + + If the application protocol using TLS provides that any data may be + carried over the underlying transport after the TLS connection is + closed, the TLS implementation must receive the responding + close_notify alert before indicating to the application layer that + the TLS connection has ended. If the application protocol will not + transfer any additional data, but will only close the underlying + transport connection, then the implementation MAY choose to close the + transport without waiting for the responding close_notify. No part + + + + +Dierks & Rescorla Standards Track [Page 29] + +RFC 5246 TLS August 2008 + + + of this standard should be taken to dictate the manner in which a + usage profile for TLS manages its data transport, including when + connections are opened or closed. + + Note: It is assumed that closing a connection reliably delivers + pending data before destroying the transport. + +7.2.2. Error Alerts + + Error handling in the TLS Handshake protocol is very simple. When an + error is detected, the detecting party sends a message to the other + party. Upon transmission or receipt of a fatal alert message, both + parties immediately close the connection. Servers and clients MUST + forget any session-identifiers, keys, and secrets associated with a + failed connection. Thus, any connection terminated with a fatal + alert MUST NOT be resumed. + + Whenever an implementation encounters a condition which is defined as + a fatal alert, it MUST send the appropriate alert prior to closing + the connection. For all errors where an alert level is not + explicitly specified, the sending party MAY determine at its + discretion whether to treat this as a fatal error or not. If the + implementation chooses to send an alert but intends to close the + connection immediately afterwards, it MUST send that alert at the + fatal alert level. + + If an alert with a level of warning is sent and received, generally + the connection can continue normally. If the receiving party decides + not to proceed with the connection (e.g., after having received a + no_renegotiation alert that it is not willing to accept), it SHOULD + send a fatal alert to terminate the connection. Given this, the + sending party cannot, in general, know how the receiving party will + behave. Therefore, warning alerts are not very useful when the + sending party wants to continue the connection, and thus are + sometimes omitted. For example, if a peer decides to accept an + expired certificate (perhaps after confirming this with the user) and + wants to continue the connection, it would not generally send a + certificate_expired alert. + + The following error alerts are defined: + + unexpected_message + An inappropriate message was received. This alert is always fatal + and should never be observed in communication between proper + implementations. + + + + + + +Dierks & Rescorla Standards Track [Page 30] + +RFC 5246 TLS August 2008 + + + bad_record_mac + This alert is returned if a record is received with an incorrect + MAC. This alert also MUST be returned if an alert is sent because + a TLSCiphertext decrypted in an invalid way: either it wasn't an + even multiple of the block length, or its padding values, when + checked, weren't correct. This message is always fatal and should + never be observed in communication between proper implementations + (except when messages were corrupted in the network). + + decryption_failed_RESERVED + This alert was used in some earlier versions of TLS, and may have + permitted certain attacks against the CBC mode [CBCATT]. It MUST + NOT be sent by compliant implementations. + + record_overflow + A TLSCiphertext record was received that had a length more than + 2^14+2048 bytes, or a record decrypted to a TLSCompressed record + with more than 2^14+1024 bytes. This message is always fatal and + should never be observed in communication between proper + implementations (except when messages were corrupted in the + network). + + decompression_failure + The decompression function received improper input (e.g., data + that would expand to excessive length). This message is always + fatal and should never be observed in communication between proper + implementations. + + handshake_failure + Reception of a handshake_failure alert message indicates that the + sender was unable to negotiate an acceptable set of security + parameters given the options available. This is a fatal error. + + no_certificate_RESERVED + This alert was used in SSLv3 but not any version of TLS. It MUST + NOT be sent by compliant implementations. + + bad_certificate + A certificate was corrupt, contained signatures that did not + verify correctly, etc. + + unsupported_certificate + A certificate was of an unsupported type. + + certificate_revoked + A certificate was revoked by its signer. + + + + + +Dierks & Rescorla Standards Track [Page 31] + +RFC 5246 TLS August 2008 + + + certificate_expired + A certificate has expired or is not currently valid. + + certificate_unknown + Some other (unspecified) issue arose in processing the + certificate, rendering it unacceptable. + + illegal_parameter + A field in the handshake was out of range or inconsistent with + other fields. This message is always fatal. + + unknown_ca + A valid certificate chain or partial chain was received, but the + certificate was not accepted because the CA certificate could not + be located or couldn't be matched with a known, trusted CA. This + message is always fatal. + + access_denied + A valid certificate was received, but when access control was + applied, the sender decided not to proceed with negotiation. This + message is always fatal. + + decode_error + A message could not be decoded because some field was out of the + specified range or the length of the message was incorrect. This + message is always fatal and should never be observed in + communication between proper implementations (except when messages + were corrupted in the network). + + decrypt_error + A handshake cryptographic operation failed, including being unable + to correctly verify a signature or validate a Finished message. + This message is always fatal. + + export_restriction_RESERVED + This alert was used in some earlier versions of TLS. It MUST NOT + be sent by compliant implementations. + + protocol_version + The protocol version the client has attempted to negotiate is + recognized but not supported. (For example, old protocol versions + might be avoided for security reasons.) This message is always + fatal. + + + + + + + + +Dierks & Rescorla Standards Track [Page 32] + +RFC 5246 TLS August 2008 + + + insufficient_security + Returned instead of handshake_failure when a negotiation has + failed specifically because the server requires ciphers more + secure than those supported by the client. This message is always + fatal. + + internal_error + An internal error unrelated to the peer or the correctness of the + protocol (such as a memory allocation failure) makes it impossible + to continue. This message is always fatal. + + user_canceled + This handshake is being canceled for some reason unrelated to a + protocol failure. If the user cancels an operation after the + handshake is complete, just closing the connection by sending a + close_notify is more appropriate. This alert should be followed + by a close_notify. This message is generally a warning. + + no_renegotiation + Sent by the client in response to a hello request or by the server + in response to a client hello after initial handshaking. Either + of these would normally lead to renegotiation; when that is not + appropriate, the recipient should respond with this alert. At + that point, the original requester can decide whether to proceed + with the connection. One case where this would be appropriate is + where a server has spawned a process to satisfy a request; the + process might receive security parameters (key length, + authentication, etc.) at startup, and it might be difficult to + communicate changes to these parameters after that point. This + message is always a warning. + + unsupported_extension + sent by clients that receive an extended server hello containing + an extension that they did not put in the corresponding client + hello. This message is always fatal. + + New Alert values are assigned by IANA as described in Section 12. + +7.3. Handshake Protocol Overview + + The cryptographic parameters of the session state are produced by the + TLS Handshake Protocol, which operates on top of the TLS record + layer. When a TLS client and server first start communicating, they + agree on a protocol version, select cryptographic algorithms, + optionally authenticate each other, and use public-key encryption + techniques to generate shared secrets. + + + + + +Dierks & Rescorla Standards Track [Page 33] + +RFC 5246 TLS August 2008 + + + The TLS Handshake Protocol involves the following steps: + + - Exchange hello messages to agree on algorithms, exchange random + values, and check for session resumption. + + - Exchange the necessary cryptographic parameters to allow the + client and server to agree on a premaster secret. + + - Exchange certificates and cryptographic information to allow the + client and server to authenticate themselves. + + - Generate a master secret from the premaster secret and exchanged + random values. + + - Provide security parameters to the record layer. + + - Allow the client and server to verify that their peer has + calculated the same security parameters and that the handshake + occurred without tampering by an attacker. + + Note that higher layers should not be overly reliant on whether TLS + always negotiates the strongest possible connection between two + peers. There are a number of ways in which a man-in-the-middle + attacker can attempt to make two entities drop down to the least + secure method they support. The protocol has been designed to + minimize this risk, but there are still attacks available: for + example, an attacker could block access to the port a secure service + runs on, or attempt to get the peers to negotiate an unauthenticated + connection. The fundamental rule is that higher levels must be + cognizant of what their security requirements are and never transmit + information over a channel less secure than what they require. The + TLS protocol is secure in that any cipher suite offers its promised + level of security: if you negotiate 3DES with a 1024-bit RSA key + exchange with a host whose certificate you have verified, you can + expect to be that secure. + + These goals are achieved by the handshake protocol, which can be + summarized as follows: The client sends a ClientHello message to + which the server must respond with a ServerHello message, or else a + fatal error will occur and the connection will fail. The ClientHello + and ServerHello are used to establish security enhancement + capabilities between client and server. The ClientHello and + ServerHello establish the following attributes: Protocol Version, + Session ID, Cipher Suite, and Compression Method. Additionally, two + random values are generated and exchanged: ClientHello.random and + ServerHello.random. + + + + + +Dierks & Rescorla Standards Track [Page 34] + +RFC 5246 TLS August 2008 + + + The actual key exchange uses up to four messages: the server + Certificate, the ServerKeyExchange, the client Certificate, and the + ClientKeyExchange. New key exchange methods can be created by + specifying a format for these messages and by defining the use of the + messages to allow the client and server to agree upon a shared + secret. This secret MUST be quite long; currently defined key + exchange methods exchange secrets that range from 46 bytes upwards. + + Following the hello messages, the server will send its certificate in + a Certificate message if it is to be authenticated. Additionally, a + ServerKeyExchange message may be sent, if it is required (e.g., if + the server has no certificate, or if its certificate is for signing + only). If the server is authenticated, it may request a certificate + from the client, if that is appropriate to the cipher suite selected. + Next, the server will send the ServerHelloDone message, indicating + that the hello-message phase of the handshake is complete. The + server will then wait for a client response. If the server has sent + a CertificateRequest message, the client MUST send the Certificate + message. The ClientKeyExchange message is now sent, and the content + of that message will depend on the public key algorithm selected + between the ClientHello and the ServerHello. If the client has sent + a certificate with signing ability, a digitally-signed + CertificateVerify message is sent to explicitly verify possession of + the private key in the certificate. + + At this point, a ChangeCipherSpec message is sent by the client, and + the client copies the pending Cipher Spec into the current Cipher + Spec. The client then immediately sends the Finished message under + the new algorithms, keys, and secrets. In response, the server will + send its own ChangeCipherSpec message, transfer the pending to the + current Cipher Spec, and send its Finished message under the new + Cipher Spec. At this point, the handshake is complete, and the + client and server may begin to exchange application layer data. (See + flow chart below.) Application data MUST NOT be sent prior to the + completion of the first handshake (before a cipher suite other than + TLS_NULL_WITH_NULL_NULL is established). + + + + + + + + + + + + + + + +Dierks & Rescorla Standards Track [Page 35] + +RFC 5246 TLS August 2008 + + + Client Server + + ClientHello --------> + ServerHello + Certificate* + ServerKeyExchange* + CertificateRequest* + <-------- ServerHelloDone + Certificate* + ClientKeyExchange + CertificateVerify* + [ChangeCipherSpec] + Finished --------> + [ChangeCipherSpec] + <-------- Finished + Application Data <-------> Application Data + + Figure 1. Message flow for a full handshake + + * Indicates optional or situation-dependent messages that are not + always sent. + + Note: To help avoid pipeline stalls, ChangeCipherSpec is an + independent TLS protocol content type, and is not actually a TLS + handshake message. + + When the client and server decide to resume a previous session or + duplicate an existing session (instead of negotiating new security + parameters), the message flow is as follows: + + The client sends a ClientHello using the Session ID of the session to + be resumed. The server then checks its session cache for a match. + If a match is found, and the server is willing to re-establish the + connection under the specified session state, it will send a + ServerHello with the same Session ID value. At this point, both + client and server MUST send ChangeCipherSpec messages and proceed + directly to Finished messages. Once the re-establishment is + complete, the client and server MAY begin to exchange application + layer data. (See flow chart below.) If a Session ID match is not + found, the server generates a new session ID, and the TLS client and + server perform a full handshake. + + + + + + + + + + +Dierks & Rescorla Standards Track [Page 36] + +RFC 5246 TLS August 2008 + + + Client Server + + ClientHello --------> + ServerHello + [ChangeCipherSpec] + <-------- Finished + [ChangeCipherSpec] + Finished --------> + Application Data <-------> Application Data + + Figure 2. Message flow for an abbreviated handshake + + The contents and significance of each message will be presented in + detail in the following sections. + +7.4. Handshake Protocol + + The TLS Handshake Protocol is one of the defined higher-level clients + of the TLS Record Protocol. This protocol is used to negotiate the + secure attributes of a session. Handshake messages are supplied to + the TLS record layer, where they are encapsulated within one or more + TLSPlaintext structures, which are processed and transmitted as + specified by the current active session state. + + enum { + hello_request(0), client_hello(1), server_hello(2), + certificate(11), server_key_exchange (12), + certificate_request(13), server_hello_done(14), + certificate_verify(15), client_key_exchange(16), + finished(20), (255) + } HandshakeType; + + struct { + HandshakeType msg_type; /* handshake type */ + uint24 length; /* bytes in message */ + select (HandshakeType) { + case hello_request: HelloRequest; + case client_hello: ClientHello; + case server_hello: ServerHello; + case certificate: Certificate; + case server_key_exchange: ServerKeyExchange; + case certificate_request: CertificateRequest; + case server_hello_done: ServerHelloDone; + case certificate_verify: CertificateVerify; + case client_key_exchange: ClientKeyExchange; + case finished: Finished; + } body; + } Handshake; + + + +Dierks & Rescorla Standards Track [Page 37] + +RFC 5246 TLS August 2008 + + + The handshake protocol messages are presented below in the order they + MUST be sent; sending handshake messages in an unexpected order + results in a fatal error. Unneeded handshake messages can be + omitted, however. Note one exception to the ordering: the + Certificate message is used twice in the handshake (from server to + client, then from client to server), but described only in its first + position. The one message that is not bound by these ordering rules + is the HelloRequest message, which can be sent at any time, but which + SHOULD be ignored by the client if it arrives in the middle of a + handshake. + + New handshake message types are assigned by IANA as described in + Section 12. + +7.4.1. Hello Messages + + The hello phase messages are used to exchange security enhancement + capabilities between the client and server. When a new session + begins, the record layer's connection state encryption, hash, and + compression algorithms are initialized to null. The current + connection state is used for renegotiation messages. + +7.4.1.1. Hello Request + + When this message will be sent: + + The HelloRequest message MAY be sent by the server at any time. + + Meaning of this message: + + HelloRequest is a simple notification that the client should begin + the negotiation process anew. In response, the client should send + a ClientHello message when convenient. This message is not + intended to establish which side is the client or server but + merely to initiate a new negotiation. Servers SHOULD NOT send a + HelloRequest immediately upon the client's initial connection. It + is the client's job to send a ClientHello at that time. + + This message will be ignored by the client if the client is + currently negotiating a session. This message MAY be ignored by + the client if it does not wish to renegotiate a session, or the + client may, if it wishes, respond with a no_renegotiation alert. + Since handshake messages are intended to have transmission + precedence over application data, it is expected that the + negotiation will begin before no more than a few records are + received from the client. If the server sends a HelloRequest but + does not receive a ClientHello in response, it may close the + connection with a fatal alert. + + + +Dierks & Rescorla Standards Track [Page 38] + +RFC 5246 TLS August 2008 + + + After sending a HelloRequest, servers SHOULD NOT repeat the + request until the subsequent handshake negotiation is complete. + + Structure of this message: + + struct { } HelloRequest; + + This message MUST NOT be included in the message hashes that are + maintained throughout the handshake and used in the Finished messages + and the certificate verify message. + +7.4.1.2. Client Hello + + When this message will be sent: + + When a client first connects to a server, it is required to send + the ClientHello as its first message. The client can also send a + ClientHello in response to a HelloRequest or on its own initiative + in order to renegotiate the security parameters in an existing + connection. + + Structure of this message: + + The ClientHello message includes a random structure, which is used + later in the protocol. + + struct { + uint32 gmt_unix_time; + opaque random_bytes[28]; + } Random; + + gmt_unix_time + The current time and date in standard UNIX 32-bit format + (seconds since the midnight starting Jan 1, 1970, UTC, ignoring + leap seconds) according to the sender's internal clock. Clocks + are not required to be set correctly by the basic TLS protocol; + higher-level or application protocols may define additional + requirements. Note that, for historical reasons, the data + element is named using GMT, the predecessor of the current + worldwide time base, UTC. + + random_bytes + 28 bytes generated by a secure random number generator. + + The ClientHello message includes a variable-length session + identifier. If not empty, the value identifies a session between the + same client and server whose security parameters the client wishes to + reuse. The session identifier MAY be from an earlier connection, + + + +Dierks & Rescorla Standards Track [Page 39] + +RFC 5246 TLS August 2008 + + + this connection, or from another currently active connection. The + second option is useful if the client only wishes to update the + random structures and derived values of a connection, and the third + option makes it possible to establish several independent secure + connections without repeating the full handshake protocol. These + independent connections may occur sequentially or simultaneously; a + SessionID becomes valid when the handshake negotiating it completes + with the exchange of Finished messages and persists until it is + removed due to aging or because a fatal error was encountered on a + connection associated with the session. The actual contents of the + SessionID are defined by the server. + + opaque SessionID<0..32>; + + Warning: Because the SessionID is transmitted without encryption or + immediate MAC protection, servers MUST NOT place confidential + information in session identifiers or let the contents of fake + session identifiers cause any breach of security. (Note that the + content of the handshake as a whole, including the SessionID, is + protected by the Finished messages exchanged at the end of the + handshake.) + + The cipher suite list, passed from the client to the server in the + ClientHello message, contains the combinations of cryptographic + algorithms supported by the client in order of the client's + preference (favorite choice first). Each cipher suite defines a key + exchange algorithm, a bulk encryption algorithm (including secret key + length), a MAC algorithm, and a PRF. The server will select a cipher + suite or, if no acceptable choices are presented, return a handshake + failure alert and close the connection. If the list contains cipher + suites the server does not recognize, support, or wish to use, the + server MUST ignore those cipher suites, and process the remaining + ones as usual. + + uint8 CipherSuite[2]; /* Cryptographic suite selector */ + + The ClientHello includes a list of compression algorithms supported + by the client, ordered according to the client's preference. + + enum { null(0), (255) } CompressionMethod; + + + + + + + + + + + +Dierks & Rescorla Standards Track [Page 40] + +RFC 5246 TLS August 2008 + + + struct { + ProtocolVersion client_version; + Random random; + SessionID session_id; + CipherSuite cipher_suites<2..2^16-2>; + CompressionMethod compression_methods<1..2^8-1>; + select (extensions_present) { + case false: + struct {}; + case true: + Extension extensions<0..2^16-1>; + }; + } ClientHello; + + TLS allows extensions to follow the compression_methods field in an + extensions block. The presence of extensions can be detected by + determining whether there are bytes following the compression_methods + at the end of the ClientHello. Note that this method of detecting + optional data differs from the normal TLS method of having a + variable-length field, but it is used for compatibility with TLS + before extensions were defined. + + client_version + The version of the TLS protocol by which the client wishes to + communicate during this session. This SHOULD be the latest + (highest valued) version supported by the client. For this + version of the specification, the version will be 3.3 (see + Appendix E for details about backward compatibility). + + random + A client-generated random structure. + + session_id + The ID of a session the client wishes to use for this connection. + This field is empty if no session_id is available, or if the + client wishes to generate new security parameters. + + cipher_suites + This is a list of the cryptographic options supported by the + client, with the client's first preference first. If the + session_id field is not empty (implying a session resumption + request), this vector MUST include at least the cipher_suite from + that session. Values are defined in Appendix A.5. + + compression_methods + This is a list of the compression methods supported by the client, + sorted by client preference. If the session_id field is not empty + (implying a session resumption request), it MUST include the + + + +Dierks & Rescorla Standards Track [Page 41] + +RFC 5246 TLS August 2008 + + + compression_method from that session. This vector MUST contain, + and all implementations MUST support, CompressionMethod.null. + Thus, a client and server will always be able to agree on a + compression method. + + extensions + Clients MAY request extended functionality from servers by sending + data in the extensions field. The actual "Extension" format is + defined in Section 7.4.1.4. + + In the event that a client requests additional functionality using + extensions, and this functionality is not supplied by the server, the + client MAY abort the handshake. A server MUST accept ClientHello + messages both with and without the extensions field, and (as for all + other messages) it MUST check that the amount of data in the message + precisely matches one of these formats; if not, then it MUST send a + fatal "decode_error" alert. + + After sending the ClientHello message, the client waits for a + ServerHello message. Any handshake message returned by the server, + except for a HelloRequest, is treated as a fatal error. + +7.4.1.3. Server Hello + + When this message will be sent: + + The server will send this message in response to a ClientHello + message when it was able to find an acceptable set of algorithms. + If it cannot find such a match, it will respond with a handshake + failure alert. + + Structure of this message: + + struct { + ProtocolVersion server_version; + Random random; + SessionID session_id; + CipherSuite cipher_suite; + CompressionMethod compression_method; + select (extensions_present) { + case false: + struct {}; + case true: + Extension extensions<0..2^16-1>; + }; + } ServerHello; + + + + + +Dierks & Rescorla Standards Track [Page 42] + +RFC 5246 TLS August 2008 + + + The presence of extensions can be detected by determining whether + there are bytes following the compression_method field at the end of + the ServerHello. + + server_version + This field will contain the lower of that suggested by the client + in the client hello and the highest supported by the server. For + this version of the specification, the version is 3.3. (See + Appendix E for details about backward compatibility.) + + random + This structure is generated by the server and MUST be + independently generated from the ClientHello.random. + + session_id + This is the identity of the session corresponding to this + connection. If the ClientHello.session_id was non-empty, the + server will look in its session cache for a match. If a match is + found and the server is willing to establish the new connection + using the specified session state, the server will respond with + the same value as was supplied by the client. This indicates a + resumed session and dictates that the parties must proceed + directly to the Finished messages. Otherwise, this field will + contain a different value identifying the new session. The server + may return an empty session_id to indicate that the session will + not be cached and therefore cannot be resumed. If a session is + resumed, it must be resumed using the same cipher suite it was + originally negotiated with. Note that there is no requirement + that the server resume any session even if it had formerly + provided a session_id. Clients MUST be prepared to do a full + negotiation -- including negotiating new cipher suites -- during + any handshake. + + cipher_suite + The single cipher suite selected by the server from the list in + ClientHello.cipher_suites. For resumed sessions, this field is + the value from the state of the session being resumed. + + compression_method + The single compression algorithm selected by the server from the + list in ClientHello.compression_methods. For resumed sessions, + this field is the value from the resumed session state. + + extensions + A list of extensions. Note that only extensions offered by the + client can appear in the server's list. + + + + + +Dierks & Rescorla Standards Track [Page 43] + +RFC 5246 TLS August 2008 + + +7.4.1.4. Hello Extensions + + The extension format is: + + struct { + ExtensionType extension_type; + opaque extension_data<0..2^16-1>; + } Extension; + + enum { + signature_algorithms(13), (65535) + } ExtensionType; + + Here: + + - "extension_type" identifies the particular extension type. + + - "extension_data" contains information specific to the particular + extension type. + + The initial set of extensions is defined in a companion document + [TLSEXT]. The list of extension types is maintained by IANA as + described in Section 12. + + An extension type MUST NOT appear in the ServerHello unless the same + extension type appeared in the corresponding ClientHello. If a + client receives an extension type in ServerHello that it did not + request in the associated ClientHello, it MUST abort the handshake + with an unsupported_extension fatal alert. + + Nonetheless, "server-oriented" extensions may be provided in the + future within this framework. Such an extension (say, of type x) + would require the client to first send an extension of type x in a + ClientHello with empty extension_data to indicate that it supports + the extension type. In this case, the client is offering the + capability to understand the extension type, and the server is taking + the client up on its offer. + + When multiple extensions of different types are present in the + ClientHello or ServerHello messages, the extensions MAY appear in any + order. There MUST NOT be more than one extension of the same type. + + Finally, note that extensions can be sent both when starting a new + session and when requesting session resumption. Indeed, a client + that requests session resumption does not in general know whether the + server will accept this request, and therefore it SHOULD send the + same extensions as it would send if it were not attempting + resumption. + + + +Dierks & Rescorla Standards Track [Page 44] + +RFC 5246 TLS August 2008 + + + In general, the specification of each extension type needs to + describe the effect of the extension both during full handshake and + session resumption. Most current TLS extensions are relevant only + when a session is initiated: when an older session is resumed, the + server does not process these extensions in Client Hello, and does + not include them in Server Hello. However, some extensions may + specify different behavior during session resumption. + + There are subtle (and not so subtle) interactions that may occur in + this protocol between new features and existing features which may + result in a significant reduction in overall security. The following + considerations should be taken into account when designing new + extensions: + + - Some cases where a server does not agree to an extension are error + conditions, and some are simply refusals to support particular + features. In general, error alerts should be used for the former, + and a field in the server extension response for the latter. + + - Extensions should, as far as possible, be designed to prevent any + attack that forces use (or non-use) of a particular feature by + manipulation of handshake messages. This principle should be + followed regardless of whether the feature is believed to cause a + security problem. + + Often the fact that the extension fields are included in the + inputs to the Finished message hashes will be sufficient, but + extreme care is needed when the extension changes the meaning of + messages sent in the handshake phase. Designers and implementors + should be aware of the fact that until the handshake has been + authenticated, active attackers can modify messages and insert, + remove, or replace extensions. + + - It would be technically possible to use extensions to change major + aspects of the design of TLS; for example the design of cipher + suite negotiation. This is not recommended; it would be more + appropriate to define a new version of TLS -- particularly since + the TLS handshake algorithms have specific protection against + version rollback attacks based on the version number, and the + possibility of version rollback should be a significant + consideration in any major design change. + +7.4.1.4.1. Signature Algorithms + + The client uses the "signature_algorithms" extension to indicate to + the server which signature/hash algorithm pairs may be used in + digital signatures. The "extension_data" field of this extension + contains a "supported_signature_algorithms" value. + + + +Dierks & Rescorla Standards Track [Page 45] + +RFC 5246 TLS August 2008 + + + enum { + none(0), md5(1), sha1(2), sha224(3), sha256(4), sha384(5), + sha512(6), (255) + } HashAlgorithm; + + enum { anonymous(0), rsa(1), dsa(2), ecdsa(3), (255) } + SignatureAlgorithm; + + struct { + HashAlgorithm hash; + SignatureAlgorithm signature; + } SignatureAndHashAlgorithm; + + SignatureAndHashAlgorithm + supported_signature_algorithms<2..2^16-2>; + + Each SignatureAndHashAlgorithm value lists a single hash/signature + pair that the client is willing to verify. The values are indicated + in descending order of preference. + + Note: Because not all signature algorithms and hash algorithms may be + accepted by an implementation (e.g., DSA with SHA-1, but not + SHA-256), algorithms here are listed in pairs. + + hash + This field indicates the hash algorithm which may be used. The + values indicate support for unhashed data, MD5 [MD5], SHA-1, + SHA-224, SHA-256, SHA-384, and SHA-512 [SHS], respectively. The + "none" value is provided for future extensibility, in case of a + signature algorithm which does not require hashing before signing. + + signature + This field indicates the signature algorithm that may be used. + The values indicate anonymous signatures, RSASSA-PKCS1-v1_5 + [PKCS1] and DSA [DSS], and ECDSA [ECDSA], respectively. The + "anonymous" value is meaningless in this context but used in + Section 7.4.3. It MUST NOT appear in this extension. + + The semantics of this extension are somewhat complicated because the + cipher suite indicates permissible signature algorithms but not hash + algorithms. Sections 7.4.2 and 7.4.3 describe the appropriate rules. + + If the client supports only the default hash and signature algorithms + (listed in this section), it MAY omit the signature_algorithms + extension. If the client does not support the default algorithms, or + supports other hash and signature algorithms (and it is willing to + use them for verifying messages sent by the server, i.e., server + certificates and server key exchange), it MUST send the + + + +Dierks & Rescorla Standards Track [Page 46] + +RFC 5246 TLS August 2008 + + + signature_algorithms extension, listing the algorithms it is willing + to accept. + + If the client does not send the signature_algorithms extension, the + server MUST do the following: + + - If the negotiated key exchange algorithm is one of (RSA, DHE_RSA, + DH_RSA, RSA_PSK, ECDH_RSA, ECDHE_RSA), behave as if client had + sent the value {sha1,rsa}. + + - If the negotiated key exchange algorithm is one of (DHE_DSS, + DH_DSS), behave as if the client had sent the value {sha1,dsa}. + + - If the negotiated key exchange algorithm is one of (ECDH_ECDSA, + ECDHE_ECDSA), behave as if the client had sent value {sha1,ecdsa}. + + Note: this is a change from TLS 1.1 where there are no explicit + rules, but as a practical matter one can assume that the peer + supports MD5 and SHA-1. + + Note: this extension is not meaningful for TLS versions prior to 1.2. + Clients MUST NOT offer it if they are offering prior versions. + However, even if clients do offer it, the rules specified in [TLSEXT] + require servers to ignore extensions they do not understand. + + Servers MUST NOT send this extension. TLS servers MUST support + receiving this extension. + + When performing session resumption, this extension is not included in + Server Hello, and the server ignores the extension in Client Hello + (if present). + +7.4.2. Server Certificate + + When this message will be sent: + + The server MUST send a Certificate message whenever the agreed- + upon key exchange method uses certificates for authentication + (this includes all key exchange methods defined in this document + except DH_anon). This message will always immediately follow the + ServerHello message. + + Meaning of this message: + + This message conveys the server's certificate chain to the client. + + The certificate MUST be appropriate for the negotiated cipher + suite's key exchange algorithm and any negotiated extensions. + + + +Dierks & Rescorla Standards Track [Page 47] + +RFC 5246 TLS August 2008 + + + Structure of this message: + + opaque ASN.1Cert<1..2^24-1>; + + struct { + ASN.1Cert certificate_list<0..2^24-1>; + } Certificate; + + certificate_list + This is a sequence (chain) of certificates. The sender's + certificate MUST come first in the list. Each following + certificate MUST directly certify the one preceding it. Because + certificate validation requires that root keys be distributed + independently, the self-signed certificate that specifies the root + certificate authority MAY be omitted from the chain, under the + assumption that the remote end must already possess it in order to + validate it in any case. + + The same message type and structure will be used for the client's + response to a certificate request message. Note that a client MAY + send no certificates if it does not have an appropriate certificate + to send in response to the server's authentication request. + + Note: PKCS #7 [PKCS7] is not used as the format for the certificate + vector because PKCS #6 [PKCS6] extended certificates are not used. + Also, PKCS #7 defines a SET rather than a SEQUENCE, making the task + of parsing the list more difficult. + + The following rules apply to the certificates sent by the server: + + - The certificate type MUST be X.509v3, unless explicitly negotiated + otherwise (e.g., [TLSPGP]). + + - The end entity certificate's public key (and associated + restrictions) MUST be compatible with the selected key exchange + algorithm. + + Key Exchange Alg. Certificate Key Type + + RSA RSA public key; the certificate MUST allow the + RSA_PSK key to be used for encryption (the + keyEncipherment bit MUST be set if the key + usage extension is present). + Note: RSA_PSK is defined in [TLSPSK]. + + + + + + + +Dierks & Rescorla Standards Track [Page 48] + +RFC 5246 TLS August 2008 + + + DHE_RSA RSA public key; the certificate MUST allow the + ECDHE_RSA key to be used for signing (the + digitalSignature bit MUST be set if the key + usage extension is present) with the signature + scheme and hash algorithm that will be employed + in the server key exchange message. + Note: ECDHE_RSA is defined in [TLSECC]. + + DHE_DSS DSA public key; the certificate MUST allow the + key to be used for signing with the hash + algorithm that will be employed in the server + key exchange message. + + DH_DSS Diffie-Hellman public key; the keyAgreement bit + DH_RSA MUST be set if the key usage extension is + present. + + ECDH_ECDSA ECDH-capable public key; the public key MUST + ECDH_RSA use a curve and point format supported by the + client, as described in [TLSECC]. + + ECDHE_ECDSA ECDSA-capable public key; the certificate MUST + allow the key to be used for signing with the + hash algorithm that will be employed in the + server key exchange message. The public key + MUST use a curve and point format supported by + the client, as described in [TLSECC]. + + - The "server_name" and "trusted_ca_keys" extensions [TLSEXT] are + used to guide certificate selection. + + If the client provided a "signature_algorithms" extension, then all + certificates provided by the server MUST be signed by a + hash/signature algorithm pair that appears in that extension. Note + that this implies that a certificate containing a key for one + signature algorithm MAY be signed using a different signature + algorithm (for instance, an RSA key signed with a DSA key). This is + a departure from TLS 1.1, which required that the algorithms be the + same. Note that this also implies that the DH_DSS, DH_RSA, + ECDH_ECDSA, and ECDH_RSA key exchange algorithms do not restrict the + algorithm used to sign the certificate. Fixed DH certificates MAY be + signed with any hash/signature algorithm pair appearing in the + extension. The names DH_DSS, DH_RSA, ECDH_ECDSA, and ECDH_RSA are + historical. + + + + + + + +Dierks & Rescorla Standards Track [Page 49] + +RFC 5246 TLS August 2008 + + + If the server has multiple certificates, it chooses one of them based + on the above-mentioned criteria (in addition to other criteria, such + as transport layer endpoint, local configuration and preferences, + etc.). If the server has a single certificate, it SHOULD attempt to + validate that it meets these criteria. + + Note that there are certificates that use algorithms and/or algorithm + combinations that cannot be currently used with TLS. For example, a + certificate with RSASSA-PSS signature key (id-RSASSA-PSS OID in + SubjectPublicKeyInfo) cannot be used because TLS defines no + corresponding signature algorithm. + + As cipher suites that specify new key exchange methods are specified + for the TLS protocol, they will imply the certificate format and the + required encoded keying information. + +7.4.3. Server Key Exchange Message + + When this message will be sent: + + This message will be sent immediately after the server Certificate + message (or the ServerHello message, if this is an anonymous + negotiation). + + The ServerKeyExchange message is sent by the server only when the + server Certificate message (if sent) does not contain enough data + to allow the client to exchange a premaster secret. This is true + for the following key exchange methods: + + DHE_DSS + DHE_RSA + DH_anon + + It is not legal to send the ServerKeyExchange message for the + following key exchange methods: + + RSA + DH_DSS + DH_RSA + + Other key exchange algorithms, such as those defined in [TLSECC], + MUST specify whether the ServerKeyExchange message is sent or not; + and if the message is sent, its contents. + + + + + + + + +Dierks & Rescorla Standards Track [Page 50] + +RFC 5246 TLS August 2008 + + + Meaning of this message: + + This message conveys cryptographic information to allow the client + to communicate the premaster secret: a Diffie-Hellman public key + with which the client can complete a key exchange (with the result + being the premaster secret) or a public key for some other + algorithm. + + Structure of this message: + + enum { dhe_dss, dhe_rsa, dh_anon, rsa, dh_dss, dh_rsa + /* may be extended, e.g., for ECDH -- see [TLSECC] */ + } KeyExchangeAlgorithm; + + struct { + opaque dh_p<1..2^16-1>; + opaque dh_g<1..2^16-1>; + opaque dh_Ys<1..2^16-1>; + } ServerDHParams; /* Ephemeral DH parameters */ + + dh_p + The prime modulus used for the Diffie-Hellman operation. + + dh_g + The generator used for the Diffie-Hellman operation. + + dh_Ys + The server's Diffie-Hellman public value (g^X mod p). + + + + + + + + + + + + + + + + + + + + + + + +Dierks & Rescorla Standards Track [Page 51] + +RFC 5246 TLS August 2008 + + + struct { + select (KeyExchangeAlgorithm) { + case dh_anon: + ServerDHParams params; + case dhe_dss: + case dhe_rsa: + ServerDHParams params; + digitally-signed struct { + opaque client_random[32]; + opaque server_random[32]; + ServerDHParams params; + } signed_params; + case rsa: + case dh_dss: + case dh_rsa: + struct {} ; + /* message is omitted for rsa, dh_dss, and dh_rsa */ + /* may be extended, e.g., for ECDH -- see [TLSECC] */ + }; + } ServerKeyExchange; + + params + The server's key exchange parameters. + + signed_params + For non-anonymous key exchanges, a signature over the server's + key exchange parameters. + + If the client has offered the "signature_algorithms" extension, the + signature algorithm and hash algorithm MUST be a pair listed in that + extension. Note that there is a possibility for inconsistencies + here. For instance, the client might offer DHE_DSS key exchange but + omit any DSA pairs from its "signature_algorithms" extension. In + order to negotiate correctly, the server MUST check any candidate + cipher suites against the "signature_algorithms" extension before + selecting them. This is somewhat inelegant but is a compromise + designed to minimize changes to the original cipher suite design. + + In addition, the hash and signature algorithms MUST be compatible + with the key in the server's end-entity certificate. RSA keys MAY be + used with any permitted hash algorithm, subject to restrictions in + the certificate, if any. + + Because DSA signatures do not contain any secure indication of hash + algorithm, there is a risk of hash substitution if multiple hashes + may be used with any key. Currently, DSA [DSS] may only be used with + SHA-1. Future revisions of DSS [DSS-3] are expected to allow the use + of other digest algorithms with DSA, as well as guidance as to which + + + +Dierks & Rescorla Standards Track [Page 52] + +RFC 5246 TLS August 2008 + + + digest algorithms should be used with each key size. In addition, + future revisions of [PKIX] may specify mechanisms for certificates to + indicate which digest algorithms are to be used with DSA. + + As additional cipher suites are defined for TLS that include new key + exchange algorithms, the server key exchange message will be sent if + and only if the certificate type associated with the key exchange + algorithm does not provide enough information for the client to + exchange a premaster secret. + +7.4.4. Certificate Request + + When this message will be sent: + + A non-anonymous server can optionally request a certificate from + the client, if appropriate for the selected cipher suite. This + message, if sent, will immediately follow the ServerKeyExchange + message (if it is sent; otherwise, this message follows the + server's Certificate message). + + Structure of this message: + + enum { + rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4), + rsa_ephemeral_dh_RESERVED(5), dss_ephemeral_dh_RESERVED(6), + fortezza_dms_RESERVED(20), (255) + } ClientCertificateType; + + opaque DistinguishedName<1..2^16-1>; + + struct { + ClientCertificateType certificate_types<1..2^8-1>; + SignatureAndHashAlgorithm + supported_signature_algorithms<2^16-1>; + DistinguishedName certificate_authorities<0..2^16-1>; + } CertificateRequest; + + certificate_types + A list of the types of certificate types that the client may + offer. + + rsa_sign a certificate containing an RSA key + dss_sign a certificate containing a DSA key + rsa_fixed_dh a certificate containing a static DH key. + dss_fixed_dh a certificate containing a static DH key + + + + + + +Dierks & Rescorla Standards Track [Page 53] + +RFC 5246 TLS August 2008 + + + supported_signature_algorithms + A list of the hash/signature algorithm pairs that the server is + able to verify, listed in descending order of preference. + + certificate_authorities + A list of the distinguished names [X501] of acceptable + certificate_authorities, represented in DER-encoded format. These + distinguished names may specify a desired distinguished name for a + root CA or for a subordinate CA; thus, this message can be used to + describe known roots as well as a desired authorization space. If + the certificate_authorities list is empty, then the client MAY + send any certificate of the appropriate ClientCertificateType, + unless there is some external arrangement to the contrary. + + The interaction of the certificate_types and + supported_signature_algorithms fields is somewhat complicated. + certificate_types has been present in TLS since SSLv3, but was + somewhat underspecified. Much of its functionality is superseded by + supported_signature_algorithms. The following rules apply: + + - Any certificates provided by the client MUST be signed using a + hash/signature algorithm pair found in + supported_signature_algorithms. + + - The end-entity certificate provided by the client MUST contain a + key that is compatible with certificate_types. If the key is a + signature key, it MUST be usable with some hash/signature + algorithm pair in supported_signature_algorithms. + + - For historical reasons, the names of some client certificate types + include the algorithm used to sign the certificate. For example, + in earlier versions of TLS, rsa_fixed_dh meant a certificate + signed with RSA and containing a static DH key. In TLS 1.2, this + functionality has been obsoleted by the + supported_signature_algorithms, and the certificate type no longer + restricts the algorithm used to sign the certificate. For + example, if the server sends dss_fixed_dh certificate type and + {{sha1, dsa}, {sha1, rsa}} signature types, the client MAY reply + with a certificate containing a static DH key, signed with RSA- + SHA1. + + New ClientCertificateType values are assigned by IANA as described in + Section 12. + + Note: Values listed as RESERVED may not be used. They were used in + SSLv3. + + + + + +Dierks & Rescorla Standards Track [Page 54] + +RFC 5246 TLS August 2008 + + + Note: It is a fatal handshake_failure alert for an anonymous server + to request client authentication. + +7.4.5. Server Hello Done + + When this message will be sent: + + The ServerHelloDone message is sent by the server to indicate the + end of the ServerHello and associated messages. After sending + this message, the server will wait for a client response. + + Meaning of this message: + + This message means that the server is done sending messages to + support the key exchange, and the client can proceed with its + phase of the key exchange. + + Upon receipt of the ServerHelloDone message, the client SHOULD + verify that the server provided a valid certificate, if required, + and check that the server hello parameters are acceptable. + + Structure of this message: + + struct { } ServerHelloDone; + +7.4.6. Client Certificate + + When this message will be sent: + + This is the first message the client can send after receiving a + ServerHelloDone message. This message is only sent if the server + requests a certificate. If no suitable certificate is available, + the client MUST send a certificate message containing no + certificates. That is, the certificate_list structure has a + length of zero. If the client does not send any certificates, the + server MAY at its discretion either continue the handshake without + client authentication, or respond with a fatal handshake_failure + alert. Also, if some aspect of the certificate chain was + unacceptable (e.g., it was not signed by a known, trusted CA), the + server MAY at its discretion either continue the handshake + (considering the client unauthenticated) or send a fatal alert. + + Client certificates are sent using the Certificate structure + defined in Section 7.4.2. + + + + + + + +Dierks & Rescorla Standards Track [Page 55] + +RFC 5246 TLS August 2008 + + + Meaning of this message: + + This message conveys the client's certificate chain to the server; + the server will use it when verifying the CertificateVerify + message (when the client authentication is based on signing) or + calculating the premaster secret (for non-ephemeral Diffie- + Hellman). The certificate MUST be appropriate for the negotiated + cipher suite's key exchange algorithm, and any negotiated + extensions. + + In particular: + + - The certificate type MUST be X.509v3, unless explicitly negotiated + otherwise (e.g., [TLSPGP]). + + - The end-entity certificate's public key (and associated + restrictions) has to be compatible with the certificate types + listed in CertificateRequest: + + Client Cert. Type Certificate Key Type + + rsa_sign RSA public key; the certificate MUST allow the + key to be used for signing with the signature + scheme and hash algorithm that will be + employed in the certificate verify message. + + dss_sign DSA public key; the certificate MUST allow the + key to be used for signing with the hash + algorithm that will be employed in the + certificate verify message. + + ecdsa_sign ECDSA-capable public key; the certificate MUST + allow the key to be used for signing with the + hash algorithm that will be employed in the + certificate verify message; the public key + MUST use a curve and point format supported by + the server. + + rsa_fixed_dh Diffie-Hellman public key; MUST use the same + dss_fixed_dh parameters as server's key. + + rsa_fixed_ecdh ECDH-capable public key; MUST use the + ecdsa_fixed_ecdh same curve as the server's key, and MUST use a + point format supported by the server. + + - If the certificate_authorities list in the certificate request + message was non-empty, one of the certificates in the certificate + chain SHOULD be issued by one of the listed CAs. + + + +Dierks & Rescorla Standards Track [Page 56] + +RFC 5246 TLS August 2008 + + + - The certificates MUST be signed using an acceptable hash/ + signature algorithm pair, as described in Section 7.4.4. Note + that this relaxes the constraints on certificate-signing + algorithms found in prior versions of TLS. + + Note that, as with the server certificate, there are certificates + that use algorithms/algorithm combinations that cannot be currently + used with TLS. + +7.4.7. Client Key Exchange Message + + When this message will be sent: + + This message is always sent by the client. It MUST immediately + follow the client certificate message, if it is sent. Otherwise, + it MUST be the first message sent by the client after it receives + the ServerHelloDone message. + + Meaning of this message: + + With this message, the premaster secret is set, either by direct + transmission of the RSA-encrypted secret or by the transmission of + Diffie-Hellman parameters that will allow each side to agree upon + the same premaster secret. + + When the client is using an ephemeral Diffie-Hellman exponent, + then this message contains the client's Diffie-Hellman public + value. If the client is sending a certificate containing a static + DH exponent (i.e., it is doing fixed_dh client authentication), + then this message MUST be sent but MUST be empty. + + Structure of this message: + + The choice of messages depends on which key exchange method has + been selected. See Section 7.4.3 for the KeyExchangeAlgorithm + definition. + + + + + + + + + + + + + + + +Dierks & Rescorla Standards Track [Page 57] + +RFC 5246 TLS August 2008 + + + struct { + select (KeyExchangeAlgorithm) { + case rsa: + EncryptedPreMasterSecret; + case dhe_dss: + case dhe_rsa: + case dh_dss: + case dh_rsa: + case dh_anon: + ClientDiffieHellmanPublic; + } exchange_keys; + } ClientKeyExchange; + +7.4.7.1. RSA-Encrypted Premaster Secret Message + + Meaning of this message: + + If RSA is being used for key agreement and authentication, the + client generates a 48-byte premaster secret, encrypts it using the + public key from the server's certificate, and sends the result in + an encrypted premaster secret message. This structure is a + variant of the ClientKeyExchange message and is not a message in + itself. + + Structure of this message: + + struct { + ProtocolVersion client_version; + opaque random[46]; + } PreMasterSecret; + + client_version + The latest (newest) version supported by the client. This is + used to detect version rollback attacks. + + random + 46 securely-generated random bytes. + + struct { + public-key-encrypted PreMasterSecret pre_master_secret; + } EncryptedPreMasterSecret; + + pre_master_secret + This random value is generated by the client and is used to + generate the master secret, as specified in Section 8.1. + + + + + + +Dierks & Rescorla Standards Track [Page 58] + +RFC 5246 TLS August 2008 + + + Note: The version number in the PreMasterSecret is the version + offered by the client in the ClientHello.client_version, not the + version negotiated for the connection. This feature is designed to + prevent rollback attacks. Unfortunately, some old implementations + use the negotiated version instead, and therefore checking the + version number may lead to failure to interoperate with such + incorrect client implementations. + + Client implementations MUST always send the correct version number in + PreMasterSecret. If ClientHello.client_version is TLS 1.1 or higher, + server implementations MUST check the version number as described in + the note below. If the version number is TLS 1.0 or earlier, server + implementations SHOULD check the version number, but MAY have a + configuration option to disable the check. Note that if the check + fails, the PreMasterSecret SHOULD be randomized as described below. + + Note: Attacks discovered by Bleichenbacher [BLEI] and Klima et al. + [KPR03] can be used to attack a TLS server that reveals whether a + particular message, when decrypted, is properly PKCS#1 formatted, + contains a valid PreMasterSecret structure, or has the correct + version number. + + As described by Klima [KPR03], these vulnerabilities can be avoided + by treating incorrectly formatted message blocks and/or mismatched + version numbers in a manner indistinguishable from correctly + formatted RSA blocks. In other words: + + 1. Generate a string R of 46 random bytes + + 2. Decrypt the message to recover the plaintext M + + 3. If the PKCS#1 padding is not correct, or the length of message + M is not exactly 48 bytes: + pre_master_secret = ClientHello.client_version || R + else If ClientHello.client_version <= TLS 1.0, and version + number check is explicitly disabled: + pre_master_secret = M + else: + pre_master_secret = ClientHello.client_version || M[2..47] + + Note that explicitly constructing the pre_master_secret with the + ClientHello.client_version produces an invalid master_secret if the + client has sent the wrong version in the original pre_master_secret. + + An alternative approach is to treat a version number mismatch as a + PKCS-1 formatting error and randomize the premaster secret + completely: + + + + +Dierks & Rescorla Standards Track [Page 59] + +RFC 5246 TLS August 2008 + + + 1. Generate a string R of 48 random bytes + + 2. Decrypt the message to recover the plaintext M + + 3. If the PKCS#1 padding is not correct, or the length of message + M is not exactly 48 bytes: + pre_master_secret = R + else If ClientHello.client_version <= TLS 1.0, and version + number check is explicitly disabled: + premaster secret = M + else If M[0..1] != ClientHello.client_version: + premaster secret = R + else: + premaster secret = M + + Although no practical attacks against this construction are known, + Klima et al. [KPR03] describe some theoretical attacks, and therefore + the first construction described is RECOMMENDED. + + In any case, a TLS server MUST NOT generate an alert if processing an + RSA-encrypted premaster secret message fails, or the version number + is not as expected. Instead, it MUST continue the handshake with a + randomly generated premaster secret. It may be useful to log the + real cause of failure for troubleshooting purposes; however, care + must be taken to avoid leaking the information to an attacker + (through, e.g., timing, log files, or other channels.) + + The RSAES-OAEP encryption scheme defined in [PKCS1] is more secure + against the Bleichenbacher attack. However, for maximal + compatibility with earlier versions of TLS, this specification uses + the RSAES-PKCS1-v1_5 scheme. No variants of the Bleichenbacher + attack are known to exist provided that the above recommendations are + followed. + + Implementation note: Public-key-encrypted data is represented as an + opaque vector <0..2^16-1> (see Section 4.7). Thus, the RSA-encrypted + PreMasterSecret in a ClientKeyExchange is preceded by two length + bytes. These bytes are redundant in the case of RSA because the + EncryptedPreMasterSecret is the only data in the ClientKeyExchange + and its length can therefore be unambiguously determined. The SSLv3 + specification was not clear about the encoding of public-key- + encrypted data, and therefore many SSLv3 implementations do not + include the length bytes -- they encode the RSA-encrypted data + directly in the ClientKeyExchange message. + + This specification requires correct encoding of the + EncryptedPreMasterSecret complete with length bytes. The resulting + PDU is incompatible with many SSLv3 implementations. Implementors + + + +Dierks & Rescorla Standards Track [Page 60] + +RFC 5246 TLS August 2008 + + + upgrading from SSLv3 MUST modify their implementations to generate + and accept the correct encoding. Implementors who wish to be + compatible with both SSLv3 and TLS should make their implementation's + behavior dependent on the protocol version. + + Implementation note: It is now known that remote timing-based attacks + on TLS are possible, at least when the client and server are on the + same LAN. Accordingly, implementations that use static RSA keys MUST + use RSA blinding or some other anti-timing technique, as described in + [TIMING]. + +7.4.7.2. Client Diffie-Hellman Public Value + + Meaning of this message: + + This structure conveys the client's Diffie-Hellman public value + (Yc) if it was not already included in the client's certificate. + The encoding used for Yc is determined by the enumerated + PublicValueEncoding. This structure is a variant of the client + key exchange message, and not a message in itself. + + Structure of this message: + + enum { implicit, explicit } PublicValueEncoding; + + implicit + If the client has sent a certificate which contains a suitable + Diffie-Hellman key (for fixed_dh client authentication), then + Yc is implicit and does not need to be sent again. In this + case, the client key exchange message will be sent, but it MUST + be empty. + + explicit + Yc needs to be sent. + + struct { + select (PublicValueEncoding) { + case implicit: struct { }; + case explicit: opaque dh_Yc<1..2^16-1>; + } dh_public; + } ClientDiffieHellmanPublic; + + dh_Yc + The client's Diffie-Hellman public value (Yc). + + + + + + + +Dierks & Rescorla Standards Track [Page 61] + +RFC 5246 TLS August 2008 + + +7.4.8. Certificate Verify + + When this message will be sent: + + This message is used to provide explicit verification of a client + certificate. This message is only sent following a client + certificate that has signing capability (i.e., all certificates + except those containing fixed Diffie-Hellman parameters). When + sent, it MUST immediately follow the client key exchange message. + + Structure of this message: + + struct { + digitally-signed struct { + opaque handshake_messages[handshake_messages_length]; + } + } CertificateVerify; + + Here handshake_messages refers to all handshake messages sent or + received, starting at client hello and up to, but not including, + this message, including the type and length fields of the + handshake messages. This is the concatenation of all the + Handshake structures (as defined in Section 7.4) exchanged thus + far. Note that this requires both sides to either buffer the + messages or compute running hashes for all potential hash + algorithms up to the time of the CertificateVerify computation. + Servers can minimize this computation cost by offering a + restricted set of digest algorithms in the CertificateRequest + message. + + The hash and signature algorithms used in the signature MUST be + one of those present in the supported_signature_algorithms field + of the CertificateRequest message. In addition, the hash and + signature algorithms MUST be compatible with the key in the + client's end-entity certificate. RSA keys MAY be used with any + permitted hash algorithm, subject to restrictions in the + certificate, if any. + + Because DSA signatures do not contain any secure indication of + hash algorithm, there is a risk of hash substitution if multiple + hashes may be used with any key. Currently, DSA [DSS] may only be + used with SHA-1. Future revisions of DSS [DSS-3] are expected to + allow the use of other digest algorithms with DSA, as well as + guidance as to which digest algorithms should be used with each + key size. In addition, future revisions of [PKIX] may specify + mechanisms for certificates to indicate which digest algorithms + are to be used with DSA. + + + + +Dierks & Rescorla Standards Track [Page 62] + +RFC 5246 TLS August 2008 + + +7.4.9. Finished + + When this message will be sent: + + A Finished message is always sent immediately after a change + cipher spec message to verify that the key exchange and + authentication processes were successful. It is essential that a + change cipher spec message be received between the other handshake + messages and the Finished message. + + Meaning of this message: + + The Finished message is the first one protected with the just + negotiated algorithms, keys, and secrets. Recipients of Finished + messages MUST verify that the contents are correct. Once a side + has sent its Finished message and received and validated the + Finished message from its peer, it may begin to send and receive + application data over the connection. + + Structure of this message: + + struct { + opaque verify_data[verify_data_length]; + } Finished; + + verify_data + PRF(master_secret, finished_label, Hash(handshake_messages)) + [0..verify_data_length-1]; + + finished_label + For Finished messages sent by the client, the string + "client finished". For Finished messages sent by the server, + the string "server finished". + + Hash denotes a Hash of the handshake messages. For the PRF + defined in Section 5, the Hash MUST be the Hash used as the basis + for the PRF. Any cipher suite which defines a different PRF MUST + also define the Hash to use in the Finished computation. + + In previous versions of TLS, the verify_data was always 12 octets + long. In the current version of TLS, it depends on the cipher + suite. Any cipher suite which does not explicitly specify + verify_data_length has a verify_data_length equal to 12. This + includes all existing cipher suites. Note that this + representation has the same encoding as with previous versions. + Future cipher suites MAY specify other lengths but such length + MUST be at least 12 bytes. + + + + +Dierks & Rescorla Standards Track [Page 63] + +RFC 5246 TLS August 2008 + + + handshake_messages + All of the data from all messages in this handshake (not + including any HelloRequest messages) up to, but not including, + this message. This is only data visible at the handshake layer + and does not include record layer headers. This is the + concatenation of all the Handshake structures as defined in + Section 7.4, exchanged thus far. + + It is a fatal error if a Finished message is not preceded by a + ChangeCipherSpec message at the appropriate point in the handshake. + + The value handshake_messages includes all handshake messages starting + at ClientHello up to, but not including, this Finished message. This + may be different from handshake_messages in Section 7.4.8 because it + would include the CertificateVerify message (if sent). Also, the + handshake_messages for the Finished message sent by the client will + be different from that for the Finished message sent by the server, + because the one that is sent second will include the prior one. + + Note: ChangeCipherSpec messages, alerts, and any other record types + are not handshake messages and are not included in the hash + computations. Also, HelloRequest messages are omitted from handshake + hashes. + +8. Cryptographic Computations + + In order to begin connection protection, the TLS Record Protocol + requires specification of a suite of algorithms, a master secret, and + the client and server random values. The authentication, encryption, + and MAC algorithms are determined by the cipher_suite selected by the + server and revealed in the ServerHello message. The compression + algorithm is negotiated in the hello messages, and the random values + are exchanged in the hello messages. All that remains is to + calculate the master secret. + +8.1. Computing the Master Secret + + For all key exchange methods, the same algorithm is used to convert + the pre_master_secret into the master_secret. The pre_master_secret + should be deleted from memory once the master_secret has been + computed. + + master_secret = PRF(pre_master_secret, "master secret", + ClientHello.random + ServerHello.random) + [0..47]; + + The master secret is always exactly 48 bytes in length. The length + of the premaster secret will vary depending on key exchange method. + + + +Dierks & Rescorla Standards Track [Page 64] + +RFC 5246 TLS August 2008 + + +8.1.1. RSA + + When RSA is used for server authentication and key exchange, a 48- + byte pre_master_secret is generated by the client, encrypted under + the server's public key, and sent to the server. The server uses its + private key to decrypt the pre_master_secret. Both parties then + convert the pre_master_secret into the master_secret, as specified + above. + +8.1.2. Diffie-Hellman + + A conventional Diffie-Hellman computation is performed. The + negotiated key (Z) is used as the pre_master_secret, and is converted + into the master_secret, as specified above. Leading bytes of Z that + contain all zero bits are stripped before it is used as the + pre_master_secret. + + Note: Diffie-Hellman parameters are specified by the server and may + be either ephemeral or contained within the server's certificate. + +9. Mandatory Cipher Suites + + In the absence of an application profile standard specifying + otherwise, a TLS-compliant application MUST implement the cipher + suite TLS_RSA_WITH_AES_128_CBC_SHA (see Appendix A.5 for the + definition). + +10. Application Data Protocol + + Application data messages are carried by the record layer and are + fragmented, compressed, and encrypted based on the current connection + state. The messages are treated as transparent data to the record + layer. + +11. Security Considerations + + Security issues are discussed throughout this memo, especially in + Appendices D, E, and F. + +12. IANA Considerations + + This document uses several registries that were originally created in + [TLS1.1]. IANA has updated these to reference this document. The + registries and their allocation policies (unchanged from [TLS1.1]) + are listed below. + + + + + + +Dierks & Rescorla Standards Track [Page 65] + +RFC 5246 TLS August 2008 + + + - TLS ClientCertificateType Identifiers Registry: Future values in + the range 0-63 (decimal) inclusive are assigned via Standards + Action [RFC2434]. Values in the range 64-223 (decimal) inclusive + are assigned via Specification Required [RFC2434]. Values from + 224-255 (decimal) inclusive are reserved for Private Use + [RFC2434]. + + - TLS Cipher Suite Registry: Future values with the first byte in + the range 0-191 (decimal) inclusive are assigned via Standards + Action [RFC2434]. Values with the first byte in the range 192-254 + (decimal) are assigned via Specification Required [RFC2434]. + Values with the first byte 255 (decimal) are reserved for Private + Use [RFC2434]. + + - This document defines several new HMAC-SHA256-based cipher suites, + whose values (in Appendix A.5) have been allocated from the TLS + Cipher Suite registry. + + - TLS ContentType Registry: Future values are allocated via + Standards Action [RFC2434]. + + - TLS Alert Registry: Future values are allocated via Standards + Action [RFC2434]. + + - TLS HandshakeType Registry: Future values are allocated via + Standards Action [RFC2434]. + + This document also uses a registry originally created in [RFC4366]. + IANA has updated it to reference this document. The registry and its + allocation policy (unchanged from [RFC4366]) is listed below: + + - TLS ExtensionType Registry: Future values are allocated via IETF + Consensus [RFC2434]. IANA has updated this registry to include + the signature_algorithms extension and its corresponding value + (see Section 7.4.1.4). + + In addition, this document defines two new registries to be + maintained by IANA: + + - TLS SignatureAlgorithm Registry: The registry has been initially + populated with the values described in Section 7.4.1.4.1. Future + values in the range 0-63 (decimal) inclusive are assigned via + Standards Action [RFC2434]. Values in the range 64-223 (decimal) + inclusive are assigned via Specification Required [RFC2434]. + Values from 224-255 (decimal) inclusive are reserved for Private + Use [RFC2434]. + + + + + +Dierks & Rescorla Standards Track [Page 66] + +RFC 5246 TLS August 2008 + + + - TLS HashAlgorithm Registry: The registry has been initially + populated with the values described in Section 7.4.1.4.1. Future + values in the range 0-63 (decimal) inclusive are assigned via + Standards Action [RFC2434]. Values in the range 64-223 (decimal) + inclusive are assigned via Specification Required [RFC2434]. + Values from 224-255 (decimal) inclusive are reserved for Private + Use [RFC2434]. + + This document also uses the TLS Compression Method Identifiers + Registry, defined in [RFC3749]. IANA has allocated value 0 for + the "null" compression method. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Dierks & Rescorla Standards Track [Page 67] + +RFC 5246 TLS August 2008 + + +Appendix A. Protocol Data Structures and Constant Values + + This section describes protocol types and constants. + +A.1. Record Layer + + struct { + uint8 major; + uint8 minor; + } ProtocolVersion; + + ProtocolVersion version = { 3, 3 }; /* TLS v1.2*/ + + enum { + change_cipher_spec(20), alert(21), handshake(22), + application_data(23), (255) + } ContentType; + + struct { + ContentType type; + ProtocolVersion version; + uint16 length; + opaque fragment[TLSPlaintext.length]; + } TLSPlaintext; + + struct { + ContentType type; + ProtocolVersion version; + uint16 length; + opaque fragment[TLSCompressed.length]; + } TLSCompressed; + + struct { + ContentType type; + ProtocolVersion version; + uint16 length; + select (SecurityParameters.cipher_type) { + case stream: GenericStreamCipher; + case block: GenericBlockCipher; + case aead: GenericAEADCipher; + } fragment; + } TLSCiphertext; + + stream-ciphered struct { + opaque content[TLSCompressed.length]; + opaque MAC[SecurityParameters.mac_length]; + } GenericStreamCipher; + + + + +Dierks & Rescorla Standards Track [Page 68] + +RFC 5246 TLS August 2008 + + + struct { + opaque IV[SecurityParameters.record_iv_length]; + block-ciphered struct { + opaque content[TLSCompressed.length]; + opaque MAC[SecurityParameters.mac_length]; + uint8 padding[GenericBlockCipher.padding_length]; + uint8 padding_length; + }; + } GenericBlockCipher; + + struct { + opaque nonce_explicit[SecurityParameters.record_iv_length]; + aead-ciphered struct { + opaque content[TLSCompressed.length]; + }; + } GenericAEADCipher; + +A.2. Change Cipher Specs Message + + struct { + enum { change_cipher_spec(1), (255) } type; + } ChangeCipherSpec; + +A.3. Alert Messages + + enum { warning(1), fatal(2), (255) } AlertLevel; + + enum { + close_notify(0), + unexpected_message(10), + bad_record_mac(20), + decryption_failed_RESERVED(21), + record_overflow(22), + decompression_failure(30), + handshake_failure(40), + no_certificate_RESERVED(41), + bad_certificate(42), + unsupported_certificate(43), + certificate_revoked(44), + certificate_expired(45), + certificate_unknown(46), + illegal_parameter(47), + unknown_ca(48), + access_denied(49), + decode_error(50), + decrypt_error(51), + export_restriction_RESERVED(60), + protocol_version(70), + + + +Dierks & Rescorla Standards Track [Page 69] + +RFC 5246 TLS August 2008 + + + insufficient_security(71), + internal_error(80), + user_canceled(90), + no_renegotiation(100), + unsupported_extension(110), /* new */ + (255) + } AlertDescription; + + struct { + AlertLevel level; + AlertDescription description; + } Alert; + +A.4. Handshake Protocol + + enum { + hello_request(0), client_hello(1), server_hello(2), + certificate(11), server_key_exchange (12), + certificate_request(13), server_hello_done(14), + certificate_verify(15), client_key_exchange(16), + finished(20) + (255) + } HandshakeType; + + struct { + HandshakeType msg_type; + uint24 length; + select (HandshakeType) { + case hello_request: HelloRequest; + case client_hello: ClientHello; + case server_hello: ServerHello; + case certificate: Certificate; + case server_key_exchange: ServerKeyExchange; + case certificate_request: CertificateRequest; + case server_hello_done: ServerHelloDone; + case certificate_verify: CertificateVerify; + case client_key_exchange: ClientKeyExchange; + case finished: Finished; + } body; + } Handshake; + + + + + + + + + + + +Dierks & Rescorla Standards Track [Page 70] + +RFC 5246 TLS August 2008 + + +A.4.1. Hello Messages + + struct { } HelloRequest; + + struct { + uint32 gmt_unix_time; + opaque random_bytes[28]; + } Random; + + opaque SessionID<0..32>; + + uint8 CipherSuite[2]; + + enum { null(0), (255) } CompressionMethod; + + struct { + ProtocolVersion client_version; + Random random; + SessionID session_id; + CipherSuite cipher_suites<2..2^16-2>; + CompressionMethod compression_methods<1..2^8-1>; + select (extensions_present) { + case false: + struct {}; + case true: + Extension extensions<0..2^16-1>; + }; + } ClientHello; + + struct { + ProtocolVersion server_version; + Random random; + SessionID session_id; + CipherSuite cipher_suite; + CompressionMethod compression_method; + select (extensions_present) { + case false: + struct {}; + case true: + Extension extensions<0..2^16-1>; + }; + } ServerHello; + + struct { + ExtensionType extension_type; + opaque extension_data<0..2^16-1>; + } Extension; + + + + +Dierks & Rescorla Standards Track [Page 71] + +RFC 5246 TLS August 2008 + + + enum { + signature_algorithms(13), (65535) + } ExtensionType; + + enum{ + none(0), md5(1), sha1(2), sha224(3), sha256(4), sha384(5), + sha512(6), (255) + } HashAlgorithm; + enum { + anonymous(0), rsa(1), dsa(2), ecdsa(3), (255) + } SignatureAlgorithm; + + struct { + HashAlgorithm hash; + SignatureAlgorithm signature; + } SignatureAndHashAlgorithm; + + SignatureAndHashAlgorithm + supported_signature_algorithms<2..2^16-1>; + +A.4.2. Server Authentication and Key Exchange Messages + + opaque ASN.1Cert<2^24-1>; + + struct { + ASN.1Cert certificate_list<0..2^24-1>; + } Certificate; + + enum { dhe_dss, dhe_rsa, dh_anon, rsa,dh_dss, dh_rsa + /* may be extended, e.g., for ECDH -- see [TLSECC] */ + } KeyExchangeAlgorithm; + + struct { + opaque dh_p<1..2^16-1>; + opaque dh_g<1..2^16-1>; + opaque dh_Ys<1..2^16-1>; + } ServerDHParams; /* Ephemeral DH parameters */ + + + + + + + + + + + + + + +Dierks & Rescorla Standards Track [Page 72] + +RFC 5246 TLS August 2008 + + + struct { + select (KeyExchangeAlgorithm) { + case dh_anon: + ServerDHParams params; + case dhe_dss: + case dhe_rsa: + ServerDHParams params; + digitally-signed struct { + opaque client_random[32]; + opaque server_random[32]; + ServerDHParams params; + } signed_params; + case rsa: + case dh_dss: + case dh_rsa: + struct {} ; + /* message is omitted for rsa, dh_dss, and dh_rsa */ + /* may be extended, e.g., for ECDH -- see [TLSECC] */ + } ServerKeyExchange; + + enum { + rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4), + rsa_ephemeral_dh_RESERVED(5), dss_ephemeral_dh_RESERVED(6), + fortezza_dms_RESERVED(20), + (255) + } ClientCertificateType; + + opaque DistinguishedName<1..2^16-1>; + + struct { + ClientCertificateType certificate_types<1..2^8-1>; + DistinguishedName certificate_authorities<0..2^16-1>; + } CertificateRequest; + + struct { } ServerHelloDone; + + + + + + + + + + + + + + + + +Dierks & Rescorla Standards Track [Page 73] + +RFC 5246 TLS August 2008 + + +A.4.3. Client Authentication and Key Exchange Messages + + struct { + select (KeyExchangeAlgorithm) { + case rsa: + EncryptedPreMasterSecret; + case dhe_dss: + case dhe_rsa: + case dh_dss: + case dh_rsa: + case dh_anon: + ClientDiffieHellmanPublic; + } exchange_keys; + } ClientKeyExchange; + + struct { + ProtocolVersion client_version; + opaque random[46]; + } PreMasterSecret; + + struct { + public-key-encrypted PreMasterSecret pre_master_secret; + } EncryptedPreMasterSecret; + + enum { implicit, explicit } PublicValueEncoding; + + struct { + select (PublicValueEncoding) { + case implicit: struct {}; + case explicit: opaque DH_Yc<1..2^16-1>; + } dh_public; + } ClientDiffieHellmanPublic; + + struct { + digitally-signed struct { + opaque handshake_messages[handshake_messages_length]; + } + } CertificateVerify; + +A.4.4. Handshake Finalization Message + + struct { + opaque verify_data[verify_data_length]; + } Finished; + + + + + + + +Dierks & Rescorla Standards Track [Page 74] + +RFC 5246 TLS August 2008 + + +A.5. The Cipher Suite + + The following values define the cipher suite codes used in the + ClientHello and ServerHello messages. + + A cipher suite defines a cipher specification supported in TLS + Version 1.2. + + TLS_NULL_WITH_NULL_NULL is specified and is the initial state of a + TLS connection during the first handshake on that channel, but MUST + NOT be negotiated, as it provides no more protection than an + unsecured connection. + + CipherSuite TLS_NULL_WITH_NULL_NULL = { 0x00,0x00 }; + + The following CipherSuite definitions require that the server provide + an RSA certificate that can be used for key exchange. The server may + request any signature-capable certificate in the certificate request + message. + + CipherSuite TLS_RSA_WITH_NULL_MD5 = { 0x00,0x01 }; + CipherSuite TLS_RSA_WITH_NULL_SHA = { 0x00,0x02 }; + CipherSuite TLS_RSA_WITH_NULL_SHA256 = { 0x00,0x3B }; + CipherSuite TLS_RSA_WITH_RC4_128_MD5 = { 0x00,0x04 }; + CipherSuite TLS_RSA_WITH_RC4_128_SHA = { 0x00,0x05 }; + CipherSuite TLS_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x0A }; + CipherSuite TLS_RSA_WITH_AES_128_CBC_SHA = { 0x00,0x2F }; + CipherSuite TLS_RSA_WITH_AES_256_CBC_SHA = { 0x00,0x35 }; + CipherSuite TLS_RSA_WITH_AES_128_CBC_SHA256 = { 0x00,0x3C }; + CipherSuite TLS_RSA_WITH_AES_256_CBC_SHA256 = { 0x00,0x3D }; + + The following cipher suite definitions are used for server- + authenticated (and optionally client-authenticated) Diffie-Hellman. + DH denotes cipher suites in which the server's certificate contains + the Diffie-Hellman parameters signed by the certificate authority + (CA). DHE denotes ephemeral Diffie-Hellman, where the Diffie-Hellman + parameters are signed by a signature-capable certificate, which has + been signed by the CA. The signing algorithm used by the server is + specified after the DHE component of the CipherSuite name. The + server can request any signature-capable certificate from the client + for client authentication, or it may request a Diffie-Hellman + certificate. Any Diffie-Hellman certificate provided by the client + must use the parameters (group and generator) described by the + server. + + + + + + + +Dierks & Rescorla Standards Track [Page 75] + +RFC 5246 TLS August 2008 + + + CipherSuite TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA = { 0x00,0x0D }; + CipherSuite TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x10 }; + CipherSuite TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA = { 0x00,0x13 }; + CipherSuite TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00,0x16 }; + CipherSuite TLS_DH_DSS_WITH_AES_128_CBC_SHA = { 0x00,0x30 }; + CipherSuite TLS_DH_RSA_WITH_AES_128_CBC_SHA = { 0x00,0x31 }; + CipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_SHA = { 0x00,0x32 }; + CipherSuite TLS_DHE_RSA_WITH_AES_128_CBC_SHA = { 0x00,0x33 }; + CipherSuite TLS_DH_DSS_WITH_AES_256_CBC_SHA = { 0x00,0x36 }; + CipherSuite TLS_DH_RSA_WITH_AES_256_CBC_SHA = { 0x00,0x37 }; + CipherSuite TLS_DHE_DSS_WITH_AES_256_CBC_SHA = { 0x00,0x38 }; + CipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_SHA = { 0x00,0x39 }; + CipherSuite TLS_DH_DSS_WITH_AES_128_CBC_SHA256 = { 0x00,0x3E }; + CipherSuite TLS_DH_RSA_WITH_AES_128_CBC_SHA256 = { 0x00,0x3F }; + CipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 = { 0x00,0x40 }; + CipherSuite TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 = { 0x00,0x67 }; + CipherSuite TLS_DH_DSS_WITH_AES_256_CBC_SHA256 = { 0x00,0x68 }; + CipherSuite TLS_DH_RSA_WITH_AES_256_CBC_SHA256 = { 0x00,0x69 }; + CipherSuite TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 = { 0x00,0x6A }; + CipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 = { 0x00,0x6B }; + + The following cipher suites are used for completely anonymous + Diffie-Hellman communications in which neither party is + authenticated. Note that this mode is vulnerable to man-in-the- + middle attacks. Using this mode therefore is of limited use: These + cipher suites MUST NOT be used by TLS 1.2 implementations unless the + application layer has specifically requested to allow anonymous key + exchange. (Anonymous key exchange may sometimes be acceptable, for + example, to support opportunistic encryption when no set-up for + authentication is in place, or when TLS is used as part of more + complex security protocols that have other means to ensure + authentication.) + + CipherSuite TLS_DH_anon_WITH_RC4_128_MD5 = { 0x00,0x18 }; + CipherSuite TLS_DH_anon_WITH_3DES_EDE_CBC_SHA = { 0x00,0x1B }; + CipherSuite TLS_DH_anon_WITH_AES_128_CBC_SHA = { 0x00,0x34 }; + CipherSuite TLS_DH_anon_WITH_AES_256_CBC_SHA = { 0x00,0x3A }; + CipherSuite TLS_DH_anon_WITH_AES_128_CBC_SHA256 = { 0x00,0x6C }; + CipherSuite TLS_DH_anon_WITH_AES_256_CBC_SHA256 = { 0x00,0x6D }; + + Note that using non-anonymous key exchange without actually verifying + the key exchange is essentially equivalent to anonymous key exchange, + and the same precautions apply. While non-anonymous key exchange + will generally involve a higher computational and communicational + cost than anonymous key exchange, it may be in the interest of + interoperability not to disable non-anonymous key exchange when the + application layer is allowing anonymous key exchange. + + + + +Dierks & Rescorla Standards Track [Page 76] + +RFC 5246 TLS August 2008 + + + New cipher suite values have been assigned by IANA as described in + Section 12. + + Note: The cipher suite values { 0x00, 0x1C } and { 0x00, 0x1D } are + reserved to avoid collision with Fortezza-based cipher suites in + SSL 3. + +A.6. The Security Parameters + + These security parameters are determined by the TLS Handshake + Protocol and provided as parameters to the TLS record layer in order + to initialize a connection state. SecurityParameters includes: + + enum { null(0), (255) } CompressionMethod; + + enum { server, client } ConnectionEnd; + + enum { tls_prf_sha256 } PRFAlgorithm; + + enum { null, rc4, 3des, aes } BulkCipherAlgorithm; + + enum { stream, block, aead } CipherType; + + enum { null, hmac_md5, hmac_sha1, hmac_sha256, hmac_sha384, + hmac_sha512} MACAlgorithm; + + /* Other values may be added to the algorithms specified in + CompressionMethod, PRFAlgorithm, BulkCipherAlgorithm, and + MACAlgorithm. */ + + struct { + ConnectionEnd entity; + PRFAlgorithm prf_algorithm; + BulkCipherAlgorithm bulk_cipher_algorithm; + CipherType cipher_type; + uint8 enc_key_length; + uint8 block_length; + uint8 fixed_iv_length; + uint8 record_iv_length; + MACAlgorithm mac_algorithm; + uint8 mac_length; + uint8 mac_key_length; + CompressionMethod compression_algorithm; + opaque master_secret[48]; + opaque client_random[32]; + opaque server_random[32]; + } SecurityParameters; + + + + +Dierks & Rescorla Standards Track [Page 77] + +RFC 5246 TLS August 2008 + + +A.7. Changes to RFC 4492 + + RFC 4492 [TLSECC] adds Elliptic Curve cipher suites to TLS. This + document changes some of the structures used in that document. This + section details the required changes for implementors of both RFC + 4492 and TLS 1.2. Implementors of TLS 1.2 who are not implementing + RFC 4492 do not need to read this section. + + This document adds a "signature_algorithm" field to the digitally- + signed element in order to identify the signature and digest + algorithms used to create a signature. This change applies to + digital signatures formed using ECDSA as well, thus allowing ECDSA + signatures to be used with digest algorithms other than SHA-1, + provided such use is compatible with the certificate and any + restrictions imposed by future revisions of [PKIX]. + + As described in Sections 7.4.2 and 7.4.6, the restrictions on the + signature algorithms used to sign certificates are no longer tied to + the cipher suite (when used by the server) or the + ClientCertificateType (when used by the client). Thus, the + restrictions on the algorithm used to sign certificates specified in + Sections 2 and 3 of RFC 4492 are also relaxed. As in this document, + the restrictions on the keys in the end-entity certificate remain. + +Appendix B. Glossary + + Advanced Encryption Standard (AES) + AES [AES] is a widely used symmetric encryption algorithm. AES is + a block cipher with a 128-, 192-, or 256-bit keys and a 16-byte + block size. TLS currently only supports the 128- and 256-bit key + sizes. + + application protocol + An application protocol is a protocol that normally layers + directly on top of the transport layer (e.g., TCP/IP). Examples + include HTTP, TELNET, FTP, and SMTP. + + asymmetric cipher + See public key cryptography. + + authenticated encryption with additional data (AEAD) + A symmetric encryption algorithm that simultaneously provides + confidentiality and message integrity. + + authentication + Authentication is the ability of one entity to determine the + identity of another entity. + + + + +Dierks & Rescorla Standards Track [Page 78] + +RFC 5246 TLS August 2008 + + + block cipher + A block cipher is an algorithm that operates on plaintext in + groups of bits, called blocks. 64 bits was, and 128 bits is, a + common block size. + + bulk cipher + A symmetric encryption algorithm used to encrypt large quantities + of data. + + cipher block chaining (CBC) + CBC is a mode in which every plaintext block encrypted with a + block cipher is first exclusive-ORed with the previous ciphertext + block (or, in the case of the first block, with the initialization + vector). For decryption, every block is first decrypted, then + exclusive-ORed with the previous ciphertext block (or IV). + + certificate + As part of the X.509 protocol (a.k.a. ISO Authentication + framework), certificates are assigned by a trusted Certificate + Authority and provide a strong binding between a party's identity + or some other attributes and its public key. + + client + The application entity that initiates a TLS connection to a + server. This may or may not imply that the client initiated the + underlying transport connection. The primary operational + difference between the server and client is that the server is + generally authenticated, while the client is only optionally + authenticated. + + client write key + The key used to encrypt data written by the client. + + client write MAC key + The secret data used to authenticate data written by the client. + + connection + A connection is a transport (in the OSI layering model definition) + that provides a suitable type of service. For TLS, such + connections are peer-to-peer relationships. The connections are + transient. Every connection is associated with one session. + + Data Encryption Standard + DES [DES] still is a very widely used symmetric encryption + algorithm although it is considered as rather weak now. DES is a + block cipher with a 56-bit key and an 8-byte block size. Note + that in TLS, for key generation purposes, DES is treated as having + an 8-byte key length (64 bits), but it still only provides 56 bits + + + +Dierks & Rescorla Standards Track [Page 79] + +RFC 5246 TLS August 2008 + + + of protection. (The low bit of each key byte is presumed to be + set to produce odd parity in that key byte.) DES can also be + operated in a mode [3DES] where three independent keys and three + encryptions are used for each block of data; this uses 168 bits of + key (24 bytes in the TLS key generation method) and provides the + equivalent of 112 bits of security. + + Digital Signature Standard (DSS) + A standard for digital signing, including the Digital Signing + Algorithm, approved by the National Institute of Standards and + Technology, defined in NIST FIPS PUB 186-2, "Digital Signature + Standard", published January 2000 by the U.S. Department of + Commerce [DSS]. A significant update [DSS-3] has been drafted and + was published in March 2006. + + digital signatures + Digital signatures utilize public key cryptography and one-way + hash functions to produce a signature of the data that can be + authenticated, and is difficult to forge or repudiate. + + handshake An initial negotiation between client and server that + establishes the parameters of their transactions. + + Initialization Vector (IV) + When a block cipher is used in CBC mode, the initialization vector + is exclusive-ORed with the first plaintext block prior to + encryption. + + Message Authentication Code (MAC) + A Message Authentication Code is a one-way hash computed from a + message and some secret data. It is difficult to forge without + knowing the secret data. Its purpose is to detect if the message + has been altered. + + master secret + Secure secret data used for generating encryption keys, MAC + secrets, and IVs. + + MD5 + MD5 [MD5] is a hashing function that converts an arbitrarily long + data stream into a hash of fixed size (16 bytes). Due to + significant progress in cryptanalysis, at the time of publication + of this document, MD5 no longer can be considered a 'secure' + hashing function. + + + + + + + +Dierks & Rescorla Standards Track [Page 80] + +RFC 5246 TLS August 2008 + + + public key cryptography + A class of cryptographic techniques employing two-key ciphers. + Messages encrypted with the public key can only be decrypted with + the associated private key. Conversely, messages signed with the + private key can be verified with the public key. + + one-way hash function + A one-way transformation that converts an arbitrary amount of data + into a fixed-length hash. It is computationally hard to reverse + the transformation or to find collisions. MD5 and SHA are + examples of one-way hash functions. + + RC4 + A stream cipher invented by Ron Rivest. A compatible cipher is + described in [SCH]. + + RSA + A very widely used public key algorithm that can be used for + either encryption or digital signing. [RSA] + + server + The server is the application entity that responds to requests for + connections from clients. See also "client". + + session + A TLS session is an association between a client and a server. + Sessions are created by the handshake protocol. Sessions define a + set of cryptographic security parameters that can be shared among + multiple connections. Sessions are used to avoid the expensive + negotiation of new security parameters for each connection. + + session identifier + A session identifier is a value generated by a server that + identifies a particular session. + + server write key + The key used to encrypt data written by the server. + + server write MAC key + The secret data used to authenticate data written by the server. + + SHA + The Secure Hash Algorithm [SHS] is defined in FIPS PUB 180-2. It + produces a 20-byte output. Note that all references to SHA + (without a numerical suffix) actually use the modified SHA-1 + algorithm. + + + + + +Dierks & Rescorla Standards Track [Page 81] + +RFC 5246 TLS August 2008 + + + SHA-256 + The 256-bit Secure Hash Algorithm is defined in FIPS PUB 180-2. + It produces a 32-byte output. + + SSL + Netscape's Secure Socket Layer protocol [SSL3]. TLS is based on + SSL Version 3.0. + + stream cipher + An encryption algorithm that converts a key into a + cryptographically strong keystream, which is then exclusive-ORed + with the plaintext. + + symmetric cipher + See bulk cipher. + + Transport Layer Security (TLS) + This protocol; also, the Transport Layer Security working group of + the Internet Engineering Task Force (IETF). See "Working Group + Information" at the end of this document (see page 99). + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Dierks & Rescorla Standards Track [Page 82] + +RFC 5246 TLS August 2008 + + +Appendix C. Cipher Suite Definitions + +Cipher Suite Key Cipher Mac + Exchange + +TLS_NULL_WITH_NULL_NULL NULL NULL NULL +TLS_RSA_WITH_NULL_MD5 RSA NULL MD5 +TLS_RSA_WITH_NULL_SHA RSA NULL SHA +TLS_RSA_WITH_NULL_SHA256 RSA NULL SHA256 +TLS_RSA_WITH_RC4_128_MD5 RSA RC4_128 MD5 +TLS_RSA_WITH_RC4_128_SHA RSA RC4_128 SHA +TLS_RSA_WITH_3DES_EDE_CBC_SHA RSA 3DES_EDE_CBC SHA +TLS_RSA_WITH_AES_128_CBC_SHA RSA AES_128_CBC SHA +TLS_RSA_WITH_AES_256_CBC_SHA RSA AES_256_CBC SHA +TLS_RSA_WITH_AES_128_CBC_SHA256 RSA AES_128_CBC SHA256 +TLS_RSA_WITH_AES_256_CBC_SHA256 RSA AES_256_CBC SHA256 +TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA DH_DSS 3DES_EDE_CBC SHA +TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA DH_RSA 3DES_EDE_CBC SHA +TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA DHE_DSS 3DES_EDE_CBC SHA +TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA DHE_RSA 3DES_EDE_CBC SHA +TLS_DH_anon_WITH_RC4_128_MD5 DH_anon RC4_128 MD5 +TLS_DH_anon_WITH_3DES_EDE_CBC_SHA DH_anon 3DES_EDE_CBC SHA +TLS_DH_DSS_WITH_AES_128_CBC_SHA DH_DSS AES_128_CBC SHA +TLS_DH_RSA_WITH_AES_128_CBC_SHA DH_RSA AES_128_CBC SHA +TLS_DHE_DSS_WITH_AES_128_CBC_SHA DHE_DSS AES_128_CBC SHA +TLS_DHE_RSA_WITH_AES_128_CBC_SHA DHE_RSA AES_128_CBC SHA +TLS_DH_anon_WITH_AES_128_CBC_SHA DH_anon AES_128_CBC SHA +TLS_DH_DSS_WITH_AES_256_CBC_SHA DH_DSS AES_256_CBC SHA +TLS_DH_RSA_WITH_AES_256_CBC_SHA DH_RSA AES_256_CBC SHA +TLS_DHE_DSS_WITH_AES_256_CBC_SHA DHE_DSS AES_256_CBC SHA +TLS_DHE_RSA_WITH_AES_256_CBC_SHA DHE_RSA AES_256_CBC SHA +TLS_DH_anon_WITH_AES_256_CBC_SHA DH_anon AES_256_CBC SHA +TLS_DH_DSS_WITH_AES_128_CBC_SHA256 DH_DSS AES_128_CBC SHA256 +TLS_DH_RSA_WITH_AES_128_CBC_SHA256 DH_RSA AES_128_CBC SHA256 +TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 DHE_DSS AES_128_CBC SHA256 +TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 DHE_RSA AES_128_CBC SHA256 +TLS_DH_anon_WITH_AES_128_CBC_SHA256 DH_anon AES_128_CBC SHA256 +TLS_DH_DSS_WITH_AES_256_CBC_SHA256 DH_DSS AES_256_CBC SHA256 +TLS_DH_RSA_WITH_AES_256_CBC_SHA256 DH_RSA AES_256_CBC SHA256 +TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 DHE_DSS AES_256_CBC SHA256 +TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 DHE_RSA AES_256_CBC SHA256 +TLS_DH_anon_WITH_AES_256_CBC_SHA256 DH_anon AES_256_CBC SHA256 + + + + + + + + + +Dierks & Rescorla Standards Track [Page 83] + +RFC 5246 TLS August 2008 + + + Key IV Block +Cipher Type Material Size Size +------------ ------ -------- ---- ----- +NULL Stream 0 0 N/A +RC4_128 Stream 16 0 N/A +3DES_EDE_CBC Block 24 8 8 +AES_128_CBC Block 16 16 16 +AES_256_CBC Block 32 16 16 + + +MAC Algorithm mac_length mac_key_length +-------- ----------- ---------- -------------- +NULL N/A 0 0 +MD5 HMAC-MD5 16 16 +SHA HMAC-SHA1 20 20 +SHA256 HMAC-SHA256 32 32 + + Type + Indicates whether this is a stream cipher or a block cipher + running in CBC mode. + + Key Material + The number of bytes from the key_block that are used for + generating the write keys. + + IV Size + The amount of data needed to be generated for the initialization + vector. Zero for stream ciphers; equal to the block size for + block ciphers (this is equal to + SecurityParameters.record_iv_length). + + Block Size + The amount of data a block cipher enciphers in one chunk; a block + cipher running in CBC mode can only encrypt an even multiple of + its block size. + + + + + + + + + + + + + + + + +Dierks & Rescorla Standards Track [Page 84] + +RFC 5246 TLS August 2008 + + +Appendix D. Implementation Notes + + The TLS protocol cannot prevent many common security mistakes. This + section provides several recommendations to assist implementors. + +D.1. Random Number Generation and Seeding + + TLS requires a cryptographically secure pseudorandom number generator + (PRNG). Care must be taken in designing and seeding PRNGs. PRNGs + based on secure hash operations, most notably SHA-1, are acceptable, + but cannot provide more security than the size of the random number + generator state. + + To estimate the amount of seed material being produced, add the + number of bits of unpredictable information in each seed byte. For + example, keystroke timing values taken from a PC compatible's 18.2 Hz + timer provide 1 or 2 secure bits each, even though the total size of + the counter value is 16 bits or more. Seeding a 128-bit PRNG would + thus require approximately 100 such timer values. + + [RANDOM] provides guidance on the generation of random values. + +D.2. Certificates and Authentication + + Implementations are responsible for verifying the integrity of + certificates and should generally support certificate revocation + messages. Certificates should always be verified to ensure proper + signing by a trusted Certificate Authority (CA). The selection and + addition of trusted CAs should be done very carefully. Users should + be able to view information about the certificate and root CA. + +D.3. Cipher Suites + + TLS supports a range of key sizes and security levels, including some + that provide no or minimal security. A proper implementation will + probably not support many cipher suites. For instance, anonymous + Diffie-Hellman is strongly discouraged because it cannot prevent man- + in-the-middle attacks. Applications should also enforce minimum and + maximum key sizes. For example, certificate chains containing 512- + bit RSA keys or signatures are not appropriate for high-security + applications. + +D.4. Implementation Pitfalls + + Implementation experience has shown that certain parts of earlier TLS + specifications are not easy to understand, and have been a source of + interoperability and security problems. Many of these areas have + + + + +Dierks & Rescorla Standards Track [Page 85] + +RFC 5246 TLS August 2008 + + + been clarified in this document, but this appendix contains a short + list of the most important things that require special attention from + implementors. + + TLS protocol issues: + + - Do you correctly handle handshake messages that are fragmented to + multiple TLS records (see Section 6.2.1)? Including corner cases + like a ClientHello that is split to several small fragments? Do + you fragment handshake messages that exceed the maximum fragment + size? In particular, the certificate and certificate request + handshake messages can be large enough to require fragmentation. + + - Do you ignore the TLS record layer version number in all TLS + records before ServerHello (see Appendix E.1)? + + - Do you handle TLS extensions in ClientHello correctly, including + omitting the extensions field completely? + + - Do you support renegotiation, both client and server initiated? + While renegotiation is an optional feature, supporting it is + highly recommended. + + - When the server has requested a client certificate, but no + suitable certificate is available, do you correctly send an empty + Certificate message, instead of omitting the whole message (see + Section 7.4.6)? + + Cryptographic details: + + - In the RSA-encrypted Premaster Secret, do you correctly send and + verify the version number? When an error is encountered, do you + continue the handshake to avoid the Bleichenbacher attack (see + Section 7.4.7.1)? + + - What countermeasures do you use to prevent timing attacks against + RSA decryption and signing operations (see Section 7.4.7.1)? + + - When verifying RSA signatures, do you accept both NULL and missing + parameters (see Section 4.7)? Do you verify that the RSA padding + doesn't have additional data after the hash value? [FI06] + + - When using Diffie-Hellman key exchange, do you correctly strip + leading zero bytes from the negotiated key (see Section 8.1.2)? + + - Does your TLS client check that the Diffie-Hellman parameters sent + by the server are acceptable (see Section F.1.1.3)? + + + + +Dierks & Rescorla Standards Track [Page 86] + +RFC 5246 TLS August 2008 + + + - How do you generate unpredictable IVs for CBC mode ciphers (see + Section 6.2.3.2)? + + - Do you accept long CBC mode padding (up to 255 bytes; see Section + 6.2.3.2)? + + - How do you address CBC mode timing attacks (Section 6.2.3.2)? + + - Do you use a strong and, most importantly, properly seeded random + number generator (see Appendix D.1) for generating the premaster + secret (for RSA key exchange), Diffie-Hellman private values, the + DSA "k" parameter, and other security-critical values? + +Appendix E. Backward Compatibility + +E.1. Compatibility with TLS 1.0/1.1 and SSL 3.0 + + Since there are various versions of TLS (1.0, 1.1, 1.2, and any + future versions) and SSL (2.0 and 3.0), means are needed to negotiate + the specific protocol version to use. The TLS protocol provides a + built-in mechanism for version negotiation so as not to bother other + protocol components with the complexities of version selection. + + TLS versions 1.0, 1.1, and 1.2, and SSL 3.0 are very similar, and use + compatible ClientHello messages; thus, supporting all of them is + relatively easy. Similarly, servers can easily handle clients trying + to use future versions of TLS as long as the ClientHello format + remains compatible, and the client supports the highest protocol + version available in the server. + + A TLS 1.2 client who wishes to negotiate with such older servers will + send a normal TLS 1.2 ClientHello, containing { 3, 3 } (TLS 1.2) in + ClientHello.client_version. If the server does not support this + version, it will respond with a ServerHello containing an older + version number. If the client agrees to use this version, the + negotiation will proceed as appropriate for the negotiated protocol. + + If the version chosen by the server is not supported by the client + (or not acceptable), the client MUST send a "protocol_version" alert + message and close the connection. + + If a TLS server receives a ClientHello containing a version number + greater than the highest version supported by the server, it MUST + reply according to the highest version supported by the server. + + A TLS server can also receive a ClientHello containing a version + number smaller than the highest supported version. If the server + wishes to negotiate with old clients, it will proceed as appropriate + + + +Dierks & Rescorla Standards Track [Page 87] + +RFC 5246 TLS August 2008 + + + for the highest version supported by the server that is not greater + than ClientHello.client_version. For example, if the server supports + TLS 1.0, 1.1, and 1.2, and client_version is TLS 1.0, the server will + proceed with a TLS 1.0 ServerHello. If server supports (or is + willing to use) only versions greater than client_version, it MUST + send a "protocol_version" alert message and close the connection. + + Whenever a client already knows the highest protocol version known to + a server (for example, when resuming a session), it SHOULD initiate + the connection in that native protocol. + + Note: some server implementations are known to implement version + negotiation incorrectly. For example, there are buggy TLS 1.0 + servers that simply close the connection when the client offers a + version newer than TLS 1.0. Also, it is known that some servers will + refuse the connection if any TLS extensions are included in + ClientHello. Interoperability with such buggy servers is a complex + topic beyond the scope of this document, and may require multiple + connection attempts by the client. + + Earlier versions of the TLS specification were not fully clear on + what the record layer version number (TLSPlaintext.version) should + contain when sending ClientHello (i.e., before it is known which + version of the protocol will be employed). Thus, TLS servers + compliant with this specification MUST accept any value {03,XX} as + the record layer version number for ClientHello. + + TLS clients that wish to negotiate with older servers MAY send any + value {03,XX} as the record layer version number. Typical values + would be {03,00}, the lowest version number supported by the client, + and the value of ClientHello.client_version. No single value will + guarantee interoperability with all old servers, but this is a + complex topic beyond the scope of this document. + +E.2. Compatibility with SSL 2.0 + + TLS 1.2 clients that wish to support SSL 2.0 servers MUST send + version 2.0 CLIENT-HELLO messages defined in [SSL2]. The message + MUST contain the same version number as would be used for ordinary + ClientHello, and MUST encode the supported TLS cipher suites in the + CIPHER-SPECS-DATA field as described below. + + Warning: The ability to send version 2.0 CLIENT-HELLO messages will + be phased out with all due haste, since the newer ClientHello format + provides better mechanisms for moving to newer versions and + negotiating extensions. TLS 1.2 clients SHOULD NOT support SSL 2.0. + + + + + +Dierks & Rescorla Standards Track [Page 88] + +RFC 5246 TLS August 2008 + + + However, even TLS servers that do not support SSL 2.0 MAY accept + version 2.0 CLIENT-HELLO messages. The message is presented below in + sufficient detail for TLS server implementors; the true definition is + still assumed to be [SSL2]. + + For negotiation purposes, 2.0 CLIENT-HELLO is interpreted the same + way as a ClientHello with a "null" compression method and no + extensions. Note that this message MUST be sent directly on the + wire, not wrapped as a TLS record. For the purposes of calculating + Finished and CertificateVerify, the msg_length field is not + considered to be a part of the handshake message. + + uint8 V2CipherSpec[3]; + struct { + uint16 msg_length; + uint8 msg_type; + Version version; + uint16 cipher_spec_length; + uint16 session_id_length; + uint16 challenge_length; + V2CipherSpec cipher_specs[V2ClientHello.cipher_spec_length]; + opaque session_id[V2ClientHello.session_id_length]; + opaque challenge[V2ClientHello.challenge_length; + } V2ClientHello; + + msg_length + The highest bit MUST be 1; the remaining bits contain the length + of the following data in bytes. + + msg_type + This field, in conjunction with the version field, identifies a + version 2 ClientHello message. The value MUST be 1. + + version + Equal to ClientHello.client_version. + + cipher_spec_length + This field is the total length of the field cipher_specs. It + cannot be zero and MUST be a multiple of the V2CipherSpec length + (3). + + session_id_length + This field MUST have a value of zero for a client that claims to + support TLS 1.2. + + + + + + + +Dierks & Rescorla Standards Track [Page 89] + +RFC 5246 TLS August 2008 + + + challenge_length + The length in bytes of the client's challenge to the server to + authenticate itself. Historically, permissible values are between + 16 and 32 bytes inclusive. When using the SSLv2 backward- + compatible handshake the client SHOULD use a 32-byte challenge. + + cipher_specs + This is a list of all CipherSpecs the client is willing and able + to use. In addition to the 2.0 cipher specs defined in [SSL2], + this includes the TLS cipher suites normally sent in + ClientHello.cipher_suites, with each cipher suite prefixed by a + zero byte. For example, the TLS cipher suite {0x00,0x0A} would be + sent as {0x00,0x00,0x0A}. + + session_id + This field MUST be empty. + + challenge + Corresponds to ClientHello.random. If the challenge length is + less than 32, the TLS server will pad the data with leading (note: + not trailing) zero bytes to make it 32 bytes long. + + Note: Requests to resume a TLS session MUST use a TLS client hello. + +E.3. Avoiding Man-in-the-Middle Version Rollback + + When TLS clients fall back to Version 2.0 compatibility mode, they + MUST use special PKCS#1 block formatting. This is done so that TLS + servers will reject Version 2.0 sessions with TLS-capable clients. + + When a client negotiates SSL 2.0 but also supports TLS, it MUST set + the right-hand (least-significant) 8 random bytes of the PKCS padding + (not including the terminal null of the padding) for the RSA + encryption of the ENCRYPTED-KEY-DATA field of the CLIENT-MASTER-KEY + to 0x03 (the other padding bytes are random). + + When a TLS-capable server negotiates SSL 2.0 it SHOULD, after + decrypting the ENCRYPTED-KEY-DATA field, check that these 8 padding + bytes are 0x03. If they are not, the server SHOULD generate a random + value for SECRET-KEY-DATA, and continue the handshake (which will + eventually fail since the keys will not match). Note that reporting + the error situation to the client could make the server vulnerable to + attacks described in [BLEI]. + + + + + + + + +Dierks & Rescorla Standards Track [Page 90] + +RFC 5246 TLS August 2008 + + +Appendix F. Security Analysis + + The TLS protocol is designed to establish a secure connection between + a client and a server communicating over an insecure channel. This + document makes several traditional assumptions, including that + attackers have substantial computational resources and cannot obtain + secret information from sources outside the protocol. Attackers are + assumed to have the ability to capture, modify, delete, replay, and + otherwise tamper with messages sent over the communication channel. + This appendix outlines how TLS has been designed to resist a variety + of attacks. + +F.1. Handshake Protocol + + The handshake protocol is responsible for selecting a cipher spec and + generating a master secret, which together comprise the primary + cryptographic parameters associated with a secure session. The + handshake protocol can also optionally authenticate parties who have + certificates signed by a trusted certificate authority. + +F.1.1. Authentication and Key Exchange + + TLS supports three authentication modes: authentication of both + parties, server authentication with an unauthenticated client, and + total anonymity. Whenever the server is authenticated, the channel + is secure against man-in-the-middle attacks, but completely anonymous + sessions are inherently vulnerable to such attacks. Anonymous + servers cannot authenticate clients. If the server is authenticated, + its certificate message must provide a valid certificate chain + leading to an acceptable certificate authority. Similarly, + authenticated clients must supply an acceptable certificate to the + server. Each party is responsible for verifying that the other's + certificate is valid and has not expired or been revoked. + + The general goal of the key exchange process is to create a + pre_master_secret known to the communicating parties and not to + attackers. The pre_master_secret will be used to generate the + master_secret (see Section 8.1). The master_secret is required to + generate the Finished messages, encryption keys, and MAC keys (see + Sections 7.4.9 and 6.3). By sending a correct Finished message, + parties thus prove that they know the correct pre_master_secret. + +F.1.1.1. Anonymous Key Exchange + + Completely anonymous sessions can be established using Diffie-Hellman + for key exchange. The server's public parameters are contained in + the server key exchange message, and the client's are sent in the + + + + +Dierks & Rescorla Standards Track [Page 91] + +RFC 5246 TLS August 2008 + + + client key exchange message. Eavesdroppers who do not know the + private values should not be able to find the Diffie-Hellman result + (i.e., the pre_master_secret). + + Warning: Completely anonymous connections only provide protection + against passive eavesdropping. Unless an independent tamper-proof + channel is used to verify that the Finished messages were not + replaced by an attacker, server authentication is required in + environments where active man-in-the-middle attacks are a concern. + +F.1.1.2. RSA Key Exchange and Authentication + + With RSA, key exchange and server authentication are combined. The + public key is contained in the server's certificate. Note that + compromise of the server's static RSA key results in a loss of + confidentiality for all sessions protected under that static key. + TLS users desiring Perfect Forward Secrecy should use DHE cipher + suites. The damage done by exposure of a private key can be limited + by changing one's private key (and certificate) frequently. + + After verifying the server's certificate, the client encrypts a + pre_master_secret with the server's public key. By successfully + decoding the pre_master_secret and producing a correct Finished + message, the server demonstrates that it knows the private key + corresponding to the server certificate. + + When RSA is used for key exchange, clients are authenticated using + the certificate verify message (see Section 7.4.8). The client signs + a value derived from all preceding handshake messages. These + handshake messages include the server certificate, which binds the + signature to the server, and ServerHello.random, which binds the + signature to the current handshake process. + +F.1.1.3. Diffie-Hellman Key Exchange with Authentication + + When Diffie-Hellman key exchange is used, the server can either + supply a certificate containing fixed Diffie-Hellman parameters or + use the server key exchange message to send a set of temporary + Diffie-Hellman parameters signed with a DSA or RSA certificate. + Temporary parameters are hashed with the hello.random values before + signing to ensure that attackers do not replay old parameters. In + either case, the client can verify the certificate or signature to + ensure that the parameters belong to the server. + + If the client has a certificate containing fixed Diffie-Hellman + parameters, its certificate contains the information required to + complete the key exchange. Note that in this case the client and + server will generate the same Diffie-Hellman result (i.e., + + + +Dierks & Rescorla Standards Track [Page 92] + +RFC 5246 TLS August 2008 + + + pre_master_secret) every time they communicate. To prevent the + pre_master_secret from staying in memory any longer than necessary, + it should be converted into the master_secret as soon as possible. + Client Diffie-Hellman parameters must be compatible with those + supplied by the server for the key exchange to work. + + If the client has a standard DSA or RSA certificate or is + unauthenticated, it sends a set of temporary parameters to the server + in the client key exchange message, then optionally uses a + certificate verify message to authenticate itself. + + If the same DH keypair is to be used for multiple handshakes, either + because the client or server has a certificate containing a fixed DH + keypair or because the server is reusing DH keys, care must be taken + to prevent small subgroup attacks. Implementations SHOULD follow the + guidelines found in [SUBGROUP]. + + Small subgroup attacks are most easily avoided by using one of the + DHE cipher suites and generating a fresh DH private key (X) for each + handshake. If a suitable base (such as 2) is chosen, g^X mod p can + be computed very quickly; therefore, the performance cost is + minimized. Additionally, using a fresh key for each handshake + provides Perfect Forward Secrecy. Implementations SHOULD generate a + new X for each handshake when using DHE cipher suites. + + Because TLS allows the server to provide arbitrary DH groups, the + client should verify that the DH group is of suitable size as defined + by local policy. The client SHOULD also verify that the DH public + exponent appears to be of adequate size. [KEYSIZ] provides a useful + guide to the strength of various group sizes. The server MAY choose + to assist the client by providing a known group, such as those + defined in [IKEALG] or [MODP]. These can be verified by simple + comparison. + +F.1.2. Version Rollback Attacks + + Because TLS includes substantial improvements over SSL Version 2.0, + attackers may try to make TLS-capable clients and servers fall back + to Version 2.0. This attack can occur if (and only if) two TLS- + capable parties use an SSL 2.0 handshake. + + Although the solution using non-random PKCS #1 block type 2 message + padding is inelegant, it provides a reasonably secure way for Version + 3.0 servers to detect the attack. This solution is not secure + against attackers who can brute-force the key and substitute a new + ENCRYPTED-KEY-DATA message containing the same key (but with normal + padding) before the application-specified wait threshold has expired. + Altering the padding of the least-significant 8 bytes of the PKCS + + + +Dierks & Rescorla Standards Track [Page 93] + +RFC 5246 TLS August 2008 + + + padding does not impact security for the size of the signed hashes + and RSA key lengths used in the protocol, since this is essentially + equivalent to increasing the input block size by 8 bytes. + +F.1.3. Detecting Attacks Against the Handshake Protocol + + An attacker might try to influence the handshake exchange to make the + parties select different encryption algorithms than they would + normally choose. + + For this attack, an attacker must actively change one or more + handshake messages. If this occurs, the client and server will + compute different values for the handshake message hashes. As a + result, the parties will not accept each others' Finished messages. + Without the master_secret, the attacker cannot repair the Finished + messages, so the attack will be discovered. + +F.1.4. Resuming Sessions + + When a connection is established by resuming a session, new + ClientHello.random and ServerHello.random values are hashed with the + session's master_secret. Provided that the master_secret has not + been compromised and that the secure hash operations used to produce + the encryption keys and MAC keys are secure, the connection should be + secure and effectively independent from previous connections. + Attackers cannot use known encryption keys or MAC secrets to + compromise the master_secret without breaking the secure hash + operations. + + Sessions cannot be resumed unless both the client and server agree. + If either party suspects that the session may have been compromised, + or that certificates may have expired or been revoked, it should + force a full handshake. An upper limit of 24 hours is suggested for + session ID lifetimes, since an attacker who obtains a master_secret + may be able to impersonate the compromised party until the + corresponding session ID is retired. Applications that may be run in + relatively insecure environments should not write session IDs to + stable storage. + +F.2. Protecting Application Data + + The master_secret is hashed with the ClientHello.random and + ServerHello.random to produce unique data encryption keys and MAC + secrets for each connection. + + Outgoing data is protected with a MAC before transmission. To + prevent message replay or modification attacks, the MAC is computed + from the MAC key, the sequence number, the message length, the + + + +Dierks & Rescorla Standards Track [Page 94] + +RFC 5246 TLS August 2008 + + + message contents, and two fixed character strings. The message type + field is necessary to ensure that messages intended for one TLS + record layer client are not redirected to another. The sequence + number ensures that attempts to delete or reorder messages will be + detected. Since sequence numbers are 64 bits long, they should never + overflow. Messages from one party cannot be inserted into the + other's output, since they use independent MAC keys. Similarly, the + server write and client write keys are independent, so stream cipher + keys are used only once. + + If an attacker does break an encryption key, all messages encrypted + with it can be read. Similarly, compromise of a MAC key can make + message-modification attacks possible. Because MACs are also + encrypted, message-alteration attacks generally require breaking the + encryption algorithm as well as the MAC. + + Note: MAC keys may be larger than encryption keys, so messages can + remain tamper resistant even if encryption keys are broken. + +F.3. Explicit IVs + + [CBCATT] describes a chosen plaintext attack on TLS that depends on + knowing the IV for a record. Previous versions of TLS [TLS1.0] used + the CBC residue of the previous record as the IV and therefore + enabled this attack. This version uses an explicit IV in order to + protect against this attack. + +F.4. Security of Composite Cipher Modes + + TLS secures transmitted application data via the use of symmetric + encryption and authentication functions defined in the negotiated + cipher suite. The objective is to protect both the integrity and + confidentiality of the transmitted data from malicious actions by + active attackers in the network. It turns out that the order in + which encryption and authentication functions are applied to the data + plays an important role for achieving this goal [ENCAUTH]. + + The most robust method, called encrypt-then-authenticate, first + applies encryption to the data and then applies a MAC to the + ciphertext. This method ensures that the integrity and + confidentiality goals are obtained with ANY pair of encryption and + MAC functions, provided that the former is secure against chosen + plaintext attacks and that the MAC is secure against chosen-message + attacks. TLS uses another method, called authenticate-then-encrypt, + in which first a MAC is computed on the plaintext and then the + concatenation of plaintext and MAC is encrypted. This method has + been proven secure for CERTAIN combinations of encryption functions + and MAC functions, but it is not guaranteed to be secure in general. + + + +Dierks & Rescorla Standards Track [Page 95] + +RFC 5246 TLS August 2008 + + + In particular, it has been shown that there exist perfectly secure + encryption functions (secure even in the information-theoretic sense) + that combined with any secure MAC function, fail to provide the + confidentiality goal against an active attack. Therefore, new cipher + suites and operation modes adopted into TLS need to be analyzed under + the authenticate-then-encrypt method to verify that they achieve the + stated integrity and confidentiality goals. + + Currently, the security of the authenticate-then-encrypt method has + been proven for some important cases. One is the case of stream + ciphers in which a computationally unpredictable pad of the length of + the message, plus the length of the MAC tag, is produced using a + pseudorandom generator and this pad is exclusive-ORed with the + concatenation of plaintext and MAC tag. The other is the case of CBC + mode using a secure block cipher. In this case, security can be + shown if one applies one CBC encryption pass to the concatenation of + plaintext and MAC and uses a new, independent, and unpredictable IV + for each new pair of plaintext and MAC. In versions of TLS prior to + 1.1, CBC mode was used properly EXCEPT that it used a predictable IV + in the form of the last block of the previous ciphertext. This made + TLS open to chosen plaintext attacks. This version of the protocol + is immune to those attacks. For exact details in the encryption + modes proven secure, see [ENCAUTH]. + +F.5. Denial of Service + + TLS is susceptible to a number of denial-of-service (DoS) attacks. + In particular, an attacker who initiates a large number of TCP + connections can cause a server to consume large amounts of CPU for + doing RSA decryption. However, because TLS is generally used over + TCP, it is difficult for the attacker to hide his point of origin if + proper TCP SYN randomization is used [SEQNUM] by the TCP stack. + + Because TLS runs over TCP, it is also susceptible to a number of DoS + attacks on individual connections. In particular, attackers can + forge RSTs, thereby terminating connections, or forge partial TLS + records, thereby causing the connection to stall. These attacks + cannot in general be defended against by a TCP-using protocol. + Implementors or users who are concerned with this class of attack + should use IPsec AH [AH] or ESP [ESP]. + +F.6. Final Notes + + For TLS to be able to provide a secure connection, both the client + and server systems, keys, and applications must be secure. In + addition, the implementation must be free of security errors. + + + + + +Dierks & Rescorla Standards Track [Page 96] + +RFC 5246 TLS August 2008 + + + The system is only as strong as the weakest key exchange and + authentication algorithm supported, and only trustworthy + cryptographic functions should be used. Short public keys and + anonymous servers should be used with great caution. Implementations + and users must be careful when deciding which certificates and + certificate authorities are acceptable; a dishonest certificate + authority can do tremendous damage. + +Normative References + + [AES] National Institute of Standards and Technology, + "Specification for the Advanced Encryption Standard (AES)" + FIPS 197. November 26, 2001. + + [3DES] National Institute of Standards and Technology, + "Recommendation for the Triple Data Encryption Algorithm + (TDEA) Block Cipher", NIST Special Publication 800-67, May + 2004. + + [DSS] NIST FIPS PUB 186-2, "Digital Signature Standard", + National Institute of Standards and Technology, U.S. + Department of Commerce, 2000. + + [HMAC] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- + Hashing for Message Authentication", RFC 2104, February + 1997. + + [MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, + April 1992. + + [PKCS1] Jonsson, J. and B. Kaliski, "Public-Key Cryptography + Standards (PKCS) #1: RSA Cryptography Specifications + Version 2.1", RFC 3447, February 2003. + + [PKIX] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet + X.509 Public Key Infrastructure Certificate and + Certificate Revocation List (CRL) Profile", RFC 3280, + April 2002. + + [SCH] B. Schneier. "Applied Cryptography: Protocols, Algorithms, + and Source Code in C, 2nd ed.", Published by John Wiley & + Sons, Inc. 1996. + + [SHS] NIST FIPS PUB 180-2, "Secure Hash Standard", National + Institute of Standards and Technology, U.S. Department of + Commerce, August 2002. + + + + + +Dierks & Rescorla Standards Track [Page 97] + +RFC 5246 TLS August 2008 + + + [REQ] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an + IANA Considerations Section in RFCs", BCP 26, RFC 2434, + October 1998. + + [X680] ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002, + Information technology - Abstract Syntax Notation One + (ASN.1): Specification of basic notation. + + [X690] ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002, + Information technology - ASN.1 encoding Rules: + Specification of Basic Encoding Rules (BER), Canonical + Encoding Rules (CER) and Distinguished Encoding Rules + (DER). + +Informative References + + [AEAD] McGrew, D., "An Interface and Algorithms for Authenticated + Encryption", RFC 5116, January 2008. + + [AH] Kent, S., "IP Authentication Header", RFC 4302, December + 2005. + + [BLEI] Bleichenbacher D., "Chosen Ciphertext Attacks against + Protocols Based on RSA Encryption Standard PKCS #1" in + Advances in Cryptology -- CRYPTO'98, LNCS vol. 1462, + pages: 1-12, 1998. + + [CBCATT] Moeller, B., "Security of CBC Ciphersuites in SSL/TLS: + Problems and Countermeasures", + http://www.openssl.org/~bodo/tls-cbc.txt. + + [CBCTIME] Canvel, B., Hiltgen, A., Vaudenay, S., and M. Vuagnoux, + "Password Interception in a SSL/TLS Channel", Advances in + Cryptology -- CRYPTO 2003, LNCS vol. 2729, 2003. + + [CCM] "NIST Special Publication 800-38C: The CCM Mode for + Authentication and Confidentiality", + http://csrc.nist.gov/publications/nistpubs/800-38C/ + SP800-38C.pdf + + [DES] National Institute of Standards and Technology, "Data + Encryption Standard (DES)", FIPS PUB 46-3, October 1999. + + + + + + +Dierks & Rescorla Standards Track [Page 98] + +RFC 5246 TLS August 2008 + + + [DSS-3] NIST FIPS PUB 186-3 Draft, "Digital Signature Standard", + National Institute of Standards and Technology, U.S. + Department of Commerce, 2006. + + [ECDSA] American National Standards Institute, "Public Key + Cryptography for the Financial Services Industry: The + Elliptic Curve Digital Signature Algorithm (ECDSA)", ANS + X9.62-2005, November 2005. + + [ENCAUTH] Krawczyk, H., "The Order of Encryption and Authentication + for Protecting Communications (Or: How Secure is SSL?)", + Crypto 2001. + + [ESP] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC + 4303, December 2005. + + [FI06] Hal Finney, "Bleichenbacher's RSA signature forgery based + on implementation error", ietf-openpgp@imc.org mailing + list, 27 August 2006, http://www.imc.org/ietf-openpgp/ + mail-archive/msg14307.html. + + [GCM] Dworkin, M., NIST Special Publication 800-38D, + "Recommendation for Block Cipher Modes of Operation: + Galois/Counter Mode (GCM) and GMAC", November 2007. + + [IKEALG] Schiller, J., "Cryptographic Algorithms for Use in the + Internet Key Exchange Version 2 (IKEv2)", RFC 4307, + December 2005. + + [KEYSIZ] Orman, H. and P. Hoffman, "Determining Strengths For + Public Keys Used For Exchanging Symmetric Keys", BCP 86, + RFC 3766, April 2004. + + [KPR03] Klima, V., Pokorny, O., Rosa, T., "Attacking RSA-based + Sessions in SSL/TLS", http://eprint.iacr.org/2003/052/, + March 2003. + + [MODP] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) + Diffie-Hellman groups for Internet Key Exchange (IKE)", + RFC 3526, May 2003. + + [PKCS6] RSA Laboratories, "PKCS #6: RSA Extended Certificate + Syntax Standard", version 1.5, November 1993. + + [PKCS7] RSA Laboratories, "PKCS #7: RSA Cryptographic Message + Syntax Standard", version 1.5, November 1993. + + + + + +Dierks & Rescorla Standards Track [Page 99] + +RFC 5246 TLS August 2008 + + + [RANDOM] Eastlake, D., 3rd, Schiller, J., and S. Crocker, + "Randomness Requirements for Security", BCP 106, RFC 4086, + June 2005. + + [RFC3749] Hollenbeck, S., "Transport Layer Security Protocol + Compression Methods", RFC 3749, May 2004. + + [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., + and T. Wright, "Transport Layer Security (TLS) + Extensions", RFC 4366, April 2006. + + [RSA] R. Rivest, A. Shamir, and L. M. Adleman, "A Method for + Obtaining Digital Signatures and Public-Key + Cryptosystems", Communications of the ACM, v. 21, n. 2, + Feb 1978, pp. 120-126. + + [SEQNUM] Bellovin, S., "Defending Against Sequence Number Attacks", + RFC 1948, May 1996. + + [SSL2] Hickman, Kipp, "The SSL Protocol", Netscape Communications + Corp., Feb 9, 1995. + + [SSL3] A. Freier, P. Karlton, and P. Kocher, "The SSL 3.0 + Protocol", Netscape Communications Corp., Nov 18, 1996. + + [SUBGROUP] Zuccherato, R., "Methods for Avoiding the "Small-Subgroup" + Attacks on the Diffie-Hellman Key Agreement Method for + S/MIME", RFC 2785, March 2000. + + [TCP] Postel, J., "Transmission Control Protocol", STD 7, RFC + 793, September 1981. + + [TIMING] Boneh, D., Brumley, D., "Remote timing attacks are + practical", USENIX Security Symposium 2003. + + [TLSAES] Chown, P., "Advanced Encryption Standard (AES) + Ciphersuites for Transport Layer Security (TLS)", RFC + 3268, June 2002. + + [TLSECC] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. + Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites + for Transport Layer Security (TLS)", RFC 4492, May 2006. + + [TLSEXT] Eastlake, D., 3rd, "Transport Layer Security (TLS) + Extensions: Extension Definitions", Work in Progress, + February 2008. + + + + + +Dierks & Rescorla Standards Track [Page 100] + +RFC 5246 TLS August 2008 + + + [TLSPGP] Mavrogiannopoulos, N., "Using OpenPGP Keys for Transport + Layer Security (TLS) Authentication", RFC 5081, November + 2007. + + [TLSPSK] Eronen, P., Ed., and H. Tschofenig, Ed., "Pre-Shared Key + Ciphersuites for Transport Layer Security (TLS)", RFC + 4279, December 2005. + + [TLS1.0] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", + RFC 2246, January 1999. + + [TLS1.1] Dierks, T. and E. Rescorla, "The Transport Layer Security + (TLS) Protocol Version 1.1", RFC 4346, April 2006. + + [X501] ITU-T Recommendation X.501: Information Technology - Open + Systems Interconnection - The Directory: Models, 1993. + + [XDR] Eisler, M., Ed., "XDR: External Data Representation + Standard", STD 67, RFC 4506, May 2006. + +Working Group Information + + The discussion list for the IETF TLS working group is located at the + e-mail address . Information on the group and + information on how to subscribe to the list is at + + + Archives of the list can be found at: + + +Contributors + + Christopher Allen (co-editor of TLS 1.0) + Alacrity Ventures + ChristopherA@AlacrityManagement.com + + Martin Abadi + University of California, Santa Cruz + abadi@cs.ucsc.edu + + Steven M. Bellovin + Columbia University + smb@cs.columbia.edu + + Simon Blake-Wilson + BCI + sblakewilson@bcisse.com + + + + +Dierks & Rescorla Standards Track [Page 101] + +RFC 5246 TLS August 2008 + + + Ran Canetti + IBM + canetti@watson.ibm.com + + Pete Chown + Skygate Technology Ltd + pc@skygate.co.uk + + Taher Elgamal + taher@securify.com + Securify + + Pasi Eronen + pasi.eronen@nokia.com + Nokia + + Anil Gangolli + anil@busybuddha.org + + Kipp Hickman + + Alfred Hoenes + + David Hopwood + Independent Consultant + david.hopwood@blueyonder.co.uk + + Phil Karlton (co-author of SSLv3) + + Paul Kocher (co-author of SSLv3) + Cryptography Research + paul@cryptography.com + + Hugo Krawczyk + IBM + hugo@ee.technion.ac.il + + Jan Mikkelsen + Transactionware + janm@transactionware.com + + Magnus Nystrom + RSA Security + magnus@rsasecurity.com + + Robert Relyea + Netscape Communications + relyea@netscape.com + + + +Dierks & Rescorla Standards Track [Page 102] + +RFC 5246 TLS August 2008 + + + Jim Roskind + Netscape Communications + jar@netscape.com + + Michael Sabin + + Dan Simon + Microsoft, Inc. + dansimon@microsoft.com + + Tom Weinstein + + Tim Wright + Vodafone + timothy.wright@vodafone.com + +Editors' Addresses + + Tim Dierks + Independent + EMail: tim@dierks.org + + Eric Rescorla + RTFM, Inc. + EMail: ekr@rtfm.com + + + + + + + + + + + + + + + + + + + + + + + + + + +Dierks & Rescorla Standards Track [Page 103] + +RFC 5246 TLS August 2008 + + +Full Copyright Statement + + Copyright (C) The IETF Trust (2008). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND + THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS + OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF + THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + + + + + + + + + + + + +Dierks & Rescorla Standards Track [Page 104] + diff --git a/RFCs/rfc5321.txt b/RFCs/rfc5321.txt new file mode 100644 index 0000000..4c33ddd --- /dev/null +++ b/RFCs/rfc5321.txt @@ -0,0 +1,5323 @@ + + + + + + +Network Working Group J. Klensin +Request for Comments: 5321 October 2008 +Obsoletes: 2821 +Updates: 1123 +Category: Standards Track + + + Simple Mail Transfer Protocol + +Status of This Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Abstract + + This document is a specification of the basic protocol for Internet + electronic mail transport. It consolidates, updates, and clarifies + several previous documents, making all or parts of most of them + obsolete. It covers the SMTP extension mechanisms and best practices + for the contemporary Internet, but does not provide details about + particular extensions. Although SMTP was designed as a mail + transport and delivery protocol, this specification also contains + information that is important to its use as a "mail submission" + protocol for "split-UA" (User Agent) mail reading systems and mobile + environments. + + + + + + + + + + + + + + + + + + + + + + +Klensin Standards Track [Page 1] + +RFC 5321 SMTP October 2008 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 + 1.1. Transport of Electronic Mail . . . . . . . . . . . . . . . 5 + 1.2. History and Context for This Document . . . . . . . . . . 5 + 1.3. Document Conventions . . . . . . . . . . . . . . . . . . . 6 + 2. The SMTP Model . . . . . . . . . . . . . . . . . . . . . . . . 7 + 2.1. Basic Structure . . . . . . . . . . . . . . . . . . . . . 7 + 2.2. The Extension Model . . . . . . . . . . . . . . . . . . . 9 + 2.2.1. Background . . . . . . . . . . . . . . . . . . . . . . 9 + 2.2.2. Definition and Registration of Extensions . . . . . . 10 + 2.2.3. Special Issues with Extensions . . . . . . . . . . . . 11 + 2.3. SMTP Terminology . . . . . . . . . . . . . . . . . . . . . 11 + 2.3.1. Mail Objects . . . . . . . . . . . . . . . . . . . . . 11 + 2.3.2. Senders and Receivers . . . . . . . . . . . . . . . . 12 + 2.3.3. Mail Agents and Message Stores . . . . . . . . . . . . 12 + 2.3.4. Host . . . . . . . . . . . . . . . . . . . . . . . . . 13 + 2.3.5. Domain Names . . . . . . . . . . . . . . . . . . . . . 13 + 2.3.6. Buffer and State Table . . . . . . . . . . . . . . . . 14 + 2.3.7. Commands and Replies . . . . . . . . . . . . . . . . . 14 + 2.3.8. Lines . . . . . . . . . . . . . . . . . . . . . . . . 14 + 2.3.9. Message Content and Mail Data . . . . . . . . . . . . 15 + 2.3.10. Originator, Delivery, Relay, and Gateway Systems . . . 15 + 2.3.11. Mailbox and Address . . . . . . . . . . . . . . . . . 15 + 2.4. General Syntax Principles and Transaction Model . . . . . 16 + 3. The SMTP Procedures: An Overview . . . . . . . . . . . . . . . 17 + 3.1. Session Initiation . . . . . . . . . . . . . . . . . . . . 18 + 3.2. Client Initiation . . . . . . . . . . . . . . . . . . . . 18 + 3.3. Mail Transactions . . . . . . . . . . . . . . . . . . . . 19 + 3.4. Forwarding for Address Correction or Updating . . . . . . 21 + 3.5. Commands for Debugging Addresses . . . . . . . . . . . . . 22 + 3.5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 22 + 3.5.2. VRFY Normal Response . . . . . . . . . . . . . . . . . 24 + 3.5.3. Meaning of VRFY or EXPN Success Response . . . . . . . 25 + 3.5.4. Semantics and Applications of EXPN . . . . . . . . . . 26 + 3.6. Relaying and Mail Routing . . . . . . . . . . . . . . . . 26 + 3.6.1. Source Routes and Relaying . . . . . . . . . . . . . . 26 + 3.6.2. Mail eXchange Records and Relaying . . . . . . . . . . 26 + 3.6.3. Message Submission Servers as Relays . . . . . . . . . 27 + 3.7. Mail Gatewaying . . . . . . . . . . . . . . . . . . . . . 28 + 3.7.1. Header Fields in Gatewaying . . . . . . . . . . . . . 28 + 3.7.2. Received Lines in Gatewaying . . . . . . . . . . . . . 29 + 3.7.3. Addresses in Gatewaying . . . . . . . . . . . . . . . 29 + 3.7.4. Other Header Fields in Gatewaying . . . . . . . . . . 29 + 3.7.5. Envelopes in Gatewaying . . . . . . . . . . . . . . . 30 + 3.8. Terminating Sessions and Connections . . . . . . . . . . . 30 + 3.9. Mailing Lists and Aliases . . . . . . . . . . . . . . . . 31 + 3.9.1. Alias . . . . . . . . . . . . . . . . . . . . . . . . 31 + + + +Klensin Standards Track [Page 2] + +RFC 5321 SMTP October 2008 + + + 3.9.2. List . . . . . . . . . . . . . . . . . . . . . . . . . 31 + 4. The SMTP Specifications . . . . . . . . . . . . . . . . . . . 32 + 4.1. SMTP Commands . . . . . . . . . . . . . . . . . . . . . . 32 + 4.1.1. Command Semantics and Syntax . . . . . . . . . . . . . 32 + 4.1.2. Command Argument Syntax . . . . . . . . . . . . . . . 41 + 4.1.3. Address Literals . . . . . . . . . . . . . . . . . . . 43 + 4.1.4. Order of Commands . . . . . . . . . . . . . . . . . . 44 + 4.1.5. Private-Use Commands . . . . . . . . . . . . . . . . . 46 + 4.2. SMTP Replies . . . . . . . . . . . . . . . . . . . . . . . 46 + 4.2.1. Reply Code Severities and Theory . . . . . . . . . . . 48 + 4.2.2. Reply Codes by Function Groups . . . . . . . . . . . . 50 + 4.2.3. Reply Codes in Numeric Order . . . . . . . . . . . . . 52 + 4.2.4. Reply Code 502 . . . . . . . . . . . . . . . . . . . . 53 + 4.2.5. Reply Codes after DATA and the Subsequent + . . . . . . . . . . . . . . . . . . . . . 53 + 4.3. Sequencing of Commands and Replies . . . . . . . . . . . . 54 + 4.3.1. Sequencing Overview . . . . . . . . . . . . . . . . . 54 + 4.3.2. Command-Reply Sequences . . . . . . . . . . . . . . . 55 + 4.4. Trace Information . . . . . . . . . . . . . . . . . . . . 57 + 4.5. Additional Implementation Issues . . . . . . . . . . . . . 61 + 4.5.1. Minimum Implementation . . . . . . . . . . . . . . . . 61 + 4.5.2. Transparency . . . . . . . . . . . . . . . . . . . . . 62 + 4.5.3. Sizes and Timeouts . . . . . . . . . . . . . . . . . . 62 + 4.5.3.1. Size Limits and Minimums . . . . . . . . . . . . . 62 + 4.5.3.1.1. Local-part . . . . . . . . . . . . . . . . . . 63 + 4.5.3.1.2. Domain . . . . . . . . . . . . . . . . . . . . 63 + 4.5.3.1.3. Path . . . . . . . . . . . . . . . . . . . . . 63 + 4.5.3.1.4. Command Line . . . . . . . . . . . . . . . . . 63 + 4.5.3.1.5. Reply Line . . . . . . . . . . . . . . . . . . 63 + 4.5.3.1.6. Text Line . . . . . . . . . . . . . . . . . . 63 + 4.5.3.1.7. Message Content . . . . . . . . . . . . . . . 63 + 4.5.3.1.8. Recipients Buffer . . . . . . . . . . . . . . 64 + 4.5.3.1.9. Treatment When Limits Exceeded . . . . . . . . 64 + 4.5.3.1.10. Too Many Recipients Code . . . . . . . . . . . 64 + 4.5.3.2. Timeouts . . . . . . . . . . . . . . . . . . . . . 65 + 4.5.3.2.1. Initial 220 Message: 5 Minutes . . . . . . . . 65 + 4.5.3.2.2. MAIL Command: 5 Minutes . . . . . . . . . . . 65 + 4.5.3.2.3. RCPT Command: 5 Minutes . . . . . . . . . . . 65 + 4.5.3.2.4. DATA Initiation: 2 Minutes . . . . . . . . . . 66 + 4.5.3.2.5. Data Block: 3 Minutes . . . . . . . . . . . . 66 + 4.5.3.2.6. DATA Termination: 10 Minutes. . . . . . . . . 66 + 4.5.3.2.7. Server Timeout: 5 Minutes. . . . . . . . . . . 66 + 4.5.4. Retry Strategies . . . . . . . . . . . . . . . . . . . 66 + 4.5.5. Messages with a Null Reverse-Path . . . . . . . . . . 68 + 5. Address Resolution and Mail Handling . . . . . . . . . . . . . 69 + 5.1. Locating the Target Host . . . . . . . . . . . . . . . . . 69 + 5.2. IPv6 and MX Records . . . . . . . . . . . . . . . . . . . 71 + 6. Problem Detection and Handling . . . . . . . . . . . . . . . . 71 + + + +Klensin Standards Track [Page 3] + +RFC 5321 SMTP October 2008 + + + 6.1. Reliable Delivery and Replies by Email . . . . . . . . . . 71 + 6.2. Unwanted, Unsolicited, and "Attack" Messages . . . . . . . 72 + 6.3. Loop Detection . . . . . . . . . . . . . . . . . . . . . . 73 + 6.4. Compensating for Irregularities . . . . . . . . . . . . . 73 + 7. Security Considerations . . . . . . . . . . . . . . . . . . . 75 + 7.1. Mail Security and Spoofing . . . . . . . . . . . . . . . . 75 + 7.2. "Blind" Copies . . . . . . . . . . . . . . . . . . . . . . 76 + 7.3. VRFY, EXPN, and Security . . . . . . . . . . . . . . . . . 76 + 7.4. Mail Rerouting Based on the 251 and 551 Response Codes . . 77 + 7.5. Information Disclosure in Announcements . . . . . . . . . 77 + 7.6. Information Disclosure in Trace Fields . . . . . . . . . . 78 + 7.7. Information Disclosure in Message Forwarding . . . . . . . 78 + 7.8. Resistance to Attacks . . . . . . . . . . . . . . . . . . 78 + 7.9. Scope of Operation of SMTP Servers . . . . . . . . . . . . 78 + 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 79 + 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 80 + 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 81 + 10.1. Normative References . . . . . . . . . . . . . . . . . . . 81 + 10.2. Informative References . . . . . . . . . . . . . . . . . . 82 + Appendix A. TCP Transport Service . . . . . . . . . . . . . . . . 85 + Appendix B. Generating SMTP Commands from RFC 822 Header + Fields . . . . . . . . . . . . . . . . . . . . . . . 85 + Appendix C. Source Routes . . . . . . . . . . . . . . . . . . . . 86 + Appendix D. Scenarios . . . . . . . . . . . . . . . . . . . . . . 87 + D.1. A Typical SMTP Transaction Scenario . . . . . . . . . . . 88 + D.2. Aborted SMTP Transaction Scenario . . . . . . . . . . . . 89 + D.3. Relayed Mail Scenario . . . . . . . . . . . . . . . . . . 90 + D.4. Verifying and Sending Scenario . . . . . . . . . . . . . . 92 + Appendix E. Other Gateway Issues . . . . . . . . . . . . . . . . 92 + Appendix F. Deprecated Features of RFC 821 . . . . . . . . . . . 93 + F.1. TURN . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 + F.2. Source Routing . . . . . . . . . . . . . . . . . . . . . . 93 + F.3. HELO . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 + F.4. #-literals . . . . . . . . . . . . . . . . . . . . . . . . 94 + F.5. Dates and Years . . . . . . . . . . . . . . . . . . . . . 94 + F.6. Sending versus Mailing . . . . . . . . . . . . . . . . . . 94 + + + + + + + + + + + + + + + +Klensin Standards Track [Page 4] + +RFC 5321 SMTP October 2008 + + +1. Introduction + +1.1. Transport of Electronic Mail + + The objective of the Simple Mail Transfer Protocol (SMTP) is to + transfer mail reliably and efficiently. + + SMTP is independent of the particular transmission subsystem and + requires only a reliable ordered data stream channel. While this + document specifically discusses transport over TCP, other transports + are possible. Appendices to RFC 821 [1] describe some of them. + + An important feature of SMTP is its capability to transport mail + across multiple networks, usually referred to as "SMTP mail relaying" + (see Section 3.6). A network consists of the mutually-TCP-accessible + hosts on the public Internet, the mutually-TCP-accessible hosts on a + firewall-isolated TCP/IP Intranet, or hosts in some other LAN or WAN + environment utilizing a non-TCP transport-level protocol. Using + SMTP, a process can transfer mail to another process on the same + network or to some other network via a relay or gateway process + accessible to both networks. + + In this way, a mail message may pass through a number of intermediate + relay or gateway hosts on its path from sender to ultimate recipient. + The Mail eXchanger mechanisms of the domain name system (RFC 1035 + [2], RFC 974 [12], and Section 5 of this document) are used to + identify the appropriate next-hop destination for a message being + transported. + +1.2. History and Context for This Document + + This document is a specification of the basic protocol for the + Internet electronic mail transport. It consolidates, updates and + clarifies, but does not add new or change existing functionality of + the following: + + o the original SMTP (Simple Mail Transfer Protocol) specification of + RFC 821 [1], + + o domain name system requirements and implications for mail + transport from RFC 1035 [2] and RFC 974 [12], + + o the clarifications and applicability statements in RFC 1123 [3], + and + + o material drawn from the SMTP Extension mechanisms in RFC 1869 + [13]. + + + + +Klensin Standards Track [Page 5] + +RFC 5321 SMTP October 2008 + + + o Editorial and clarification changes to RFC 2821 [14] to bring that + specification to Draft Standard. + + It obsoletes RFC 821, RFC 974, RFC 1869, and RFC 2821 and updates RFC + 1123 (replacing the mail transport materials of RFC 1123). However, + RFC 821 specifies some features that were not in significant use in + the Internet by the mid-1990s and (in appendices) some additional + transport models. Those sections are omitted here in the interest of + clarity and brevity; readers needing them should refer to RFC 821. + + It also includes some additional material from RFC 1123 that required + amplification. This material has been identified in multiple ways, + mostly by tracking flaming on various lists and newsgroups and + problems of unusual readings or interpretations that have appeared as + the SMTP extensions have been deployed. Where this specification + moves beyond consolidation and actually differs from earlier + documents, it supersedes them technically as well as textually. + + Although SMTP was designed as a mail transport and delivery protocol, + this specification also contains information that is important to its + use as a "mail submission" protocol, as recommended for Post Office + Protocol (POP) (RFC 937 [15], RFC 1939 [16]) and IMAP (RFC 3501 + [17]). In general, the separate mail submission protocol specified + in RFC 4409 [18] is now preferred to direct use of SMTP; more + discussion of that subject appears in that document. + + Section 2.3 provides definitions of terms specific to this document. + Except when the historical terminology is necessary for clarity, this + document uses the current 'client' and 'server' terminology to + identify the sending and receiving SMTP processes, respectively. + + A companion document, RFC 5322 [4], discusses message header sections + and bodies and specifies formats and structures for them. + +1.3. Document Conventions + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119 [5]. As each + of these terms was intentionally and carefully chosen to improve the + interoperability of email, each use of these terms is to be treated + as a conformance requirement. + + Because this document has a long history and to avoid the risk of + various errors and of confusing readers and documents that point to + this one, most examples and the domain names they contain are + preserved from RFC 2821. Readers are cautioned that these are + + + + +Klensin Standards Track [Page 6] + +RFC 5321 SMTP October 2008 + + + illustrative examples that should not actually be used in either code + or configuration files. + +2. The SMTP Model + +2.1. Basic Structure + + The SMTP design can be pictured as: + + +----------+ +----------+ + +------+ | | | | + | User |<-->| | SMTP | | + +------+ | Client- |Commands/Replies| Server- | + +------+ | SMTP |<-------------->| SMTP | +------+ + | File |<-->| | and Mail | |<-->| File | + |System| | | | | |System| + +------+ +----------+ +----------+ +------+ + SMTP client SMTP server + + When an SMTP client has a message to transmit, it establishes a two- + way transmission channel to an SMTP server. The responsibility of an + SMTP client is to transfer mail messages to one or more SMTP servers, + or report its failure to do so. + + The means by which a mail message is presented to an SMTP client, and + how that client determines the identifier(s) ("names") of the + domain(s) to which mail messages are to be transferred, is a local + matter, and is not addressed by this document. In some cases, the + designated domain(s), or those determined by an SMTP client, will + identify the final destination(s) of the mail message. In other + cases, common with SMTP clients associated with implementations of + the POP (RFC 937 [15], RFC 1939 [16]) or IMAP (RFC 3501 [17]) + protocols, or when the SMTP client is inside an isolated transport + service environment, the domain determined will identify an + intermediate destination through which all mail messages are to be + relayed. SMTP clients that transfer all traffic regardless of the + target domains associated with the individual messages, or that do + not maintain queues for retrying message transmissions that initially + cannot be completed, may otherwise conform to this specification but + are not considered fully-capable. Fully-capable SMTP + implementations, including the relays used by these less capable + ones, and their destinations, are expected to support all of the + queuing, retrying, and alternate address functions discussed in this + specification. In many situations and configurations, the less- + capable clients discussed above SHOULD be using the message + submission protocol (RFC 4409 [18]) rather than SMTP. + + + + + +Klensin Standards Track [Page 7] + +RFC 5321 SMTP October 2008 + + + The means by which an SMTP client, once it has determined a target + domain, determines the identity of an SMTP server to which a copy of + a message is to be transferred, and then performs that transfer, is + covered by this document. To effect a mail transfer to an SMTP + server, an SMTP client establishes a two-way transmission channel to + that SMTP server. An SMTP client determines the address of an + appropriate host running an SMTP server by resolving a destination + domain name to either an intermediate Mail eXchanger host or a final + target host. + + An SMTP server may be either the ultimate destination or an + intermediate "relay" (that is, it may assume the role of an SMTP + client after receiving the message) or "gateway" (that is, it may + transport the message further using some protocol other than SMTP). + SMTP commands are generated by the SMTP client and sent to the SMTP + server. SMTP replies are sent from the SMTP server to the SMTP + client in response to the commands. + + In other words, message transfer can occur in a single connection + between the original SMTP-sender and the final SMTP-recipient, or can + occur in a series of hops through intermediary systems. In either + case, once the server has issued a success response at the end of the + mail data, a formal handoff of responsibility for the message occurs: + the protocol requires that a server MUST accept responsibility for + either delivering the message or properly reporting the failure to do + so (see Sections 6.1, 6.2, and 7.8, below). + + Once the transmission channel is established and initial handshaking + is completed, the SMTP client normally initiates a mail transaction. + Such a transaction consists of a series of commands to specify the + originator and destination of the mail and transmission of the + message content (including any lines in the header section or other + structure) itself. When the same message is sent to multiple + recipients, this protocol encourages the transmission of only one + copy of the data for all recipients at the same destination (or + intermediate relay) host. + + The server responds to each command with a reply; replies may + indicate that the command was accepted, that additional commands are + expected, or that a temporary or permanent error condition exists. + Commands specifying the sender or recipients may include server- + permitted SMTP service extension requests, as discussed in + Section 2.2. The dialog is purposely lock-step, one-at-a-time, + although this can be modified by mutually agreed upon extension + requests such as command pipelining (RFC 2920 [19]). + + Once a given mail message has been transmitted, the client may either + request that the connection be shut down or may initiate other mail + + + +Klensin Standards Track [Page 8] + +RFC 5321 SMTP October 2008 + + + transactions. In addition, an SMTP client may use a connection to an + SMTP server for ancillary services such as verification of email + addresses or retrieval of mailing list subscriber addresses. + + As suggested above, this protocol provides mechanisms for the + transmission of mail. Historically, this transmission normally + occurred directly from the sending user's host to the receiving + user's host when the two hosts are connected to the same transport + service. When they are not connected to the same transport service, + transmission occurs via one or more relay SMTP servers. A very + common case in the Internet today involves submission of the original + message to an intermediate, "message submission" server, which is + similar to a relay but has some additional properties; such servers + are discussed in Section 2.3.10 and at some length in RFC 4409 [18]. + An intermediate host that acts as either an SMTP relay or as a + gateway into some other transmission environment is usually selected + through the use of the domain name service (DNS) Mail eXchanger + mechanism. + + Usually, intermediate hosts are determined via the DNS MX record, not + by explicit "source" routing (see Section 5 and Appendix C and + Appendix F.2). + +2.2. The Extension Model + +2.2.1. Background + + In an effort that started in 1990, approximately a decade after RFC + 821 was completed, the protocol was modified with a "service + extensions" model that permits the client and server to agree to + utilize shared functionality beyond the original SMTP requirements. + The SMTP extension mechanism defines a means whereby an extended SMTP + client and server may recognize each other, and the server can inform + the client as to the service extensions that it supports. + + Contemporary SMTP implementations MUST support the basic extension + mechanisms. For instance, servers MUST support the EHLO command even + if they do not implement any specific extensions and clients SHOULD + preferentially utilize EHLO rather than HELO. (However, for + compatibility with older conforming implementations, SMTP clients and + servers MUST support the original HELO mechanisms as a fallback.) + Unless the different characteristics of HELO must be identified for + interoperability purposes, this document discusses only EHLO. + + SMTP is widely deployed and high-quality implementations have proven + to be very robust. However, the Internet community now considers + some services to be important that were not anticipated when the + protocol was first designed. If support for those services is to be + + + +Klensin Standards Track [Page 9] + +RFC 5321 SMTP October 2008 + + + added, it must be done in a way that permits older implementations to + continue working acceptably. The extension framework consists of: + + o The SMTP command EHLO, superseding the earlier HELO, + + o a registry of SMTP service extensions, + + o additional parameters to the SMTP MAIL and RCPT commands, and + + o optional replacements for commands defined in this protocol, such + as for DATA in non-ASCII transmissions (RFC 3030 [20]). + + SMTP's strength comes primarily from its simplicity. Experience with + many protocols has shown that protocols with few options tend towards + ubiquity, whereas protocols with many options tend towards obscurity. + + Each and every extension, regardless of its benefits, must be + carefully scrutinized with respect to its implementation, deployment, + and interoperability costs. In many cases, the cost of extending the + SMTP service will likely outweigh the benefit. + +2.2.2. Definition and Registration of Extensions + + The IANA maintains a registry of SMTP service extensions. A + corresponding EHLO keyword value is associated with each extension. + Each service extension registered with the IANA must be defined in a + formal Standards-Track or IESG-approved Experimental protocol + document. The definition must include: + + o the textual name of the SMTP service extension; + + o the EHLO keyword value associated with the extension; + + o the syntax and possible values of parameters associated with the + EHLO keyword value; + + o any additional SMTP verbs associated with the extension + (additional verbs will usually be, but are not required to be, the + same as the EHLO keyword value); + + o any new parameters the extension associates with the MAIL or RCPT + verbs; + + o a description of how support for the extension affects the + behavior of a server and client SMTP; and + + + + + + +Klensin Standards Track [Page 10] + +RFC 5321 SMTP October 2008 + + + o the increment by which the extension is increasing the maximum + length of the commands MAIL and/or RCPT, over that specified in + this Standard. + + In addition, any EHLO keyword value starting with an upper or lower + case "X" refers to a local SMTP service extension used exclusively + through bilateral agreement. Keywords beginning with "X" MUST NOT be + used in a registered service extension. Conversely, keyword values + presented in the EHLO response that do not begin with "X" MUST + correspond to a Standard, Standards-Track, or IESG-approved + Experimental SMTP service extension registered with IANA. A + conforming server MUST NOT offer non-"X"-prefixed keyword values that + are not described in a registered extension. + + Additional verbs and parameter names are bound by the same rules as + EHLO keywords; specifically, verbs beginning with "X" are local + extensions that may not be registered or standardized. Conversely, + verbs not beginning with "X" must always be registered. + +2.2.3. Special Issues with Extensions + + Extensions that change fairly basic properties of SMTP operation are + permitted. The text in other sections of this document must be + understood in that context. In particular, extensions can change the + minimum limits specified in Section 4.5.3, can change the ASCII + character set requirement as mentioned above, or can introduce some + optional modes of message handling. + + In particular, if an extension implies that the delivery path + normally supports special features of that extension, and an + intermediate SMTP system finds a next hop that does not support the + required extension, it MAY choose, based on the specific extension + and circumstances, to requeue the message and try later and/or try an + alternate MX host. If this strategy is employed, the timeout to fall + back to an unextended format (if one is available) SHOULD be less + than the normal timeout for bouncing as undeliverable (e.g., if + normal timeout is three days, the requeue timeout before attempting + to transmit the mail without the extension might be one day). + +2.3. SMTP Terminology + +2.3.1. Mail Objects + + SMTP transports a mail object. A mail object contains an envelope + and content. + + The SMTP envelope is sent as a series of SMTP protocol units + (described in Section 3). It consists of an originator address (to + + + +Klensin Standards Track [Page 11] + +RFC 5321 SMTP October 2008 + + + which error reports should be directed), one or more recipient + addresses, and optional protocol extension material. Historically, + variations on the reverse-path (originator) address specification + command (MAIL) could be used to specify alternate delivery modes, + such as immediate display; those variations have now been deprecated + (see Appendix F and Appendix F.6). + + The SMTP content is sent in the SMTP DATA protocol unit and has two + parts: the header section and the body. If the content conforms to + other contemporary standards, the header section consists of a + collection of header fields, each consisting of a header name, a + colon, and data, structured as in the message format specification + (RFC 5322 [4]); the body, if structured, is defined according to MIME + (RFC 2045 [21]). The content is textual in nature, expressed using + the US-ASCII repertoire [6]. Although SMTP extensions (such as + "8BITMIME", RFC 1652 [22]) may relax this restriction for the content + body, the content header fields are always encoded using the US-ASCII + repertoire. Two MIME extensions (RFC 2047 [23] and RFC 2231 [24]) + define an algorithm for representing header values outside the US- + ASCII repertoire, while still encoding them using the US-ASCII + repertoire. + +2.3.2. Senders and Receivers + + In RFC 821, the two hosts participating in an SMTP transaction were + described as the "SMTP-sender" and "SMTP-receiver". This document + has been changed to reflect current industry terminology and hence + refers to them as the "SMTP client" (or sometimes just "the client") + and "SMTP server" (or just "the server"), respectively. Since a + given host may act both as server and client in a relay situation, + "receiver" and "sender" terminology is still used where needed for + clarity. + +2.3.3. Mail Agents and Message Stores + + Additional mail system terminology became common after RFC 821 was + published and, where convenient, is used in this specification. In + particular, SMTP servers and clients provide a mail transport service + and therefore act as "Mail Transfer Agents" (MTAs). "Mail User + Agents" (MUAs or UAs) are normally thought of as the sources and + targets of mail. At the source, an MUA might collect mail to be + transmitted from a user and hand it off to an MTA; the final + ("delivery") MTA would be thought of as handing the mail off to an + MUA (or at least transferring responsibility to it, e.g., by + depositing the message in a "message store"). However, while these + terms are used with at least the appearance of great precision in + other environments, the implied boundaries between MUAs and MTAs + often do not accurately match common, and conforming, practices with + + + +Klensin Standards Track [Page 12] + +RFC 5321 SMTP October 2008 + + + Internet mail. Hence, the reader should be cautious about inferring + the strong relationships and responsibilities that might be implied + if these terms were used elsewhere. + +2.3.4. Host + + For the purposes of this specification, a host is a computer system + attached to the Internet (or, in some cases, to a private TCP/IP + network) and supporting the SMTP protocol. Hosts are known by names + (see the next section); they SHOULD NOT be identified by numerical + addresses, i.e., by address literals as described in Section 4.1.2. + +2.3.5. Domain Names + + A domain name (or often just a "domain") consists of one or more + components, separated by dots if more than one appears. In the case + of a top-level domain used by itself in an email address, a single + string is used without any dots. This makes the requirement, + described in more detail below, that only fully-qualified domain + names appear in SMTP transactions on the public Internet, + particularly important where top-level domains are involved. These + components ("labels" in DNS terminology, RFC 1035 [2]) are restricted + for SMTP purposes to consist of a sequence of letters, digits, and + hyphens drawn from the ASCII character set [6]. Domain names are + used as names of hosts and of other entities in the domain name + hierarchy. For example, a domain may refer to an alias (label of a + CNAME RR) or the label of Mail eXchanger records to be used to + deliver mail instead of representing a host name. See RFC 1035 [2] + and Section 5 of this specification. + + The domain name, as described in this document and in RFC 1035 [2], + is the entire, fully-qualified name (often referred to as an "FQDN"). + A domain name that is not in FQDN form is no more than a local alias. + Local aliases MUST NOT appear in any SMTP transaction. + + Only resolvable, fully-qualified domain names (FQDNs) are permitted + when domain names are used in SMTP. In other words, names that can + be resolved to MX RRs or address (i.e., A or AAAA) RRs (as discussed + in Section 5) are permitted, as are CNAME RRs whose targets can be + resolved, in turn, to MX or address RRs. Local nicknames or + unqualified names MUST NOT be used. There are two exceptions to the + rule requiring FQDNs: + + o The domain name given in the EHLO command MUST be either a primary + host name (a domain name that resolves to an address RR) or, if + the host has no name, an address literal, as described in + Section 4.1.3 and discussed further in the EHLO discussion of + Section 4.1.4. + + + +Klensin Standards Track [Page 13] + +RFC 5321 SMTP October 2008 + + + o The reserved mailbox name "postmaster" may be used in a RCPT + command without domain qualification (see Section 4.1.1.3) and + MUST be accepted if so used. + +2.3.6. Buffer and State Table + + SMTP sessions are stateful, with both parties carefully maintaining a + common view of the current state. In this document, we model this + state by a virtual "buffer" and a "state table" on the server that + may be used by the client to, for example, "clear the buffer" or + "reset the state table", causing the information in the buffer to be + discarded and the state to be returned to some previous state. + +2.3.7. Commands and Replies + + SMTP commands and, unless altered by a service extension, message + data, are transmitted from the sender to the receiver via the + transmission channel in "lines". + + An SMTP reply is an acknowledgment (positive or negative) sent in + "lines" from receiver to sender via the transmission channel in + response to a command. The general form of a reply is a numeric + completion code (indicating failure or success) usually followed by a + text string. The codes are for use by programs and the text is + usually intended for human users. RFC 3463 [25], specifies further + structuring of the reply strings, including the use of supplemental + and more specific completion codes (see also RFC 5248 [26]). + +2.3.8. Lines + + Lines consist of zero or more data characters terminated by the + sequence ASCII character "CR" (hex value 0D) followed immediately by + ASCII character "LF" (hex value 0A). This termination sequence is + denoted as in this document. Conforming implementations MUST + NOT recognize or generate any other character or character sequence + as a line terminator. Limits MAY be imposed on line lengths by + servers (see Section 4). + + In addition, the appearance of "bare" "CR" or "LF" characters in text + (i.e., either without the other) has a long history of causing + problems in mail implementations and applications that use the mail + system as a tool. SMTP client implementations MUST NOT transmit + these characters except when they are intended as line terminators + and then MUST, as indicated above, transmit them only as a + sequence. + + + + + + +Klensin Standards Track [Page 14] + +RFC 5321 SMTP October 2008 + + +2.3.9. Message Content and Mail Data + + The terms "message content" and "mail data" are used interchangeably + in this document to describe the material transmitted after the DATA + command is accepted and before the end of data indication is + transmitted. Message content includes the message header section and + the possibly structured message body. The MIME specification (RFC + 2045 [21]) provides the standard mechanisms for structured message + bodies. + +2.3.10. Originator, Delivery, Relay, and Gateway Systems + + This specification makes a distinction among four types of SMTP + systems, based on the role those systems play in transmitting + electronic mail. An "originating" system (sometimes called an SMTP + originator) introduces mail into the Internet or, more generally, + into a transport service environment. A "delivery" SMTP system is + one that receives mail from a transport service environment and + passes it to a mail user agent or deposits it in a message store that + a mail user agent is expected to subsequently access. A "relay" SMTP + system (usually referred to just as a "relay") receives mail from an + SMTP client and transmits it, without modification to the message + data other than adding trace information, to another SMTP server for + further relaying or for delivery. + + A "gateway" SMTP system (usually referred to just as a "gateway") + receives mail from a client system in one transport environment and + transmits it to a server system in another transport environment. + Differences in protocols or message semantics between the transport + environments on either side of a gateway may require that the gateway + system perform transformations to the message that are not permitted + to SMTP relay systems. For the purposes of this specification, + firewalls that rewrite addresses should be considered as gateways, + even if SMTP is used on both sides of them (see RFC 2979 [27]). + +2.3.11. Mailbox and Address + + As used in this specification, an "address" is a character string + that identifies a user to whom mail will be sent or a location into + which mail will be deposited. The term "mailbox" refers to that + depository. The two terms are typically used interchangeably unless + the distinction between the location in which mail is placed (the + mailbox) and a reference to it (the address) is important. An + address normally consists of user and domain specifications. The + standard mailbox naming convention is defined to be + "local-part@domain"; contemporary usage permits a much broader set of + applications than simple "user names". Consequently, and due to a + long history of problems when intermediate hosts have attempted to + + + +Klensin Standards Track [Page 15] + +RFC 5321 SMTP October 2008 + + + optimize transport by modifying them, the local-part MUST be + interpreted and assigned semantics only by the host specified in the + domain part of the address. + +2.4. General Syntax Principles and Transaction Model + + SMTP commands and replies have a rigid syntax. All commands begin + with a command verb. All replies begin with a three digit numeric + code. In some commands and replies, arguments are required following + the verb or reply code. Some commands do not accept arguments (after + the verb), and some reply codes are followed, sometimes optionally, + by free form text. In both cases, where text appears, it is + separated from the verb or reply code by a space character. Complete + definitions of commands and replies appear in Section 4. + + Verbs and argument values (e.g., "TO:" or "to:" in the RCPT command + and extension name keywords) are not case sensitive, with the sole + exception in this specification of a mailbox local-part (SMTP + Extensions may explicitly specify case-sensitive elements). That is, + a command verb, an argument value other than a mailbox local-part, + and free form text MAY be encoded in upper case, lower case, or any + mixture of upper and lower case with no impact on its meaning. The + local-part of a mailbox MUST BE treated as case sensitive. + Therefore, SMTP implementations MUST take care to preserve the case + of mailbox local-parts. In particular, for some hosts, the user + "smith" is different from the user "Smith". However, exploiting the + case sensitivity of mailbox local-parts impedes interoperability and + is discouraged. Mailbox domains follow normal DNS rules and are + hence not case sensitive. + + A few SMTP servers, in violation of this specification (and RFC 821) + require that command verbs be encoded by clients in upper case. + Implementations MAY wish to employ this encoding to accommodate those + servers. + + The argument clause consists of a variable-length character string + ending with the end of the line, i.e., with the character sequence + . The receiver will take no action until this sequence is + received. + + The syntax for each command is shown with the discussion of that + command. Common elements and parameters are shown in Section 4.1.2. + + Commands and replies are composed of characters from the ASCII + character set [6]. When the transport service provides an 8-bit byte + (octet) transmission channel, each 7-bit character is transmitted, + right justified, in an octet with the high-order bit cleared to zero. + More specifically, the unextended SMTP service provides 7-bit + + + +Klensin Standards Track [Page 16] + +RFC 5321 SMTP October 2008 + + + transport only. An originating SMTP client that has not successfully + negotiated an appropriate extension with a particular server (see the + next paragraph) MUST NOT transmit messages with information in the + high-order bit of octets. If such messages are transmitted in + violation of this rule, receiving SMTP servers MAY clear the high- + order bit or reject the message as invalid. In general, a relay SMTP + SHOULD assume that the message content it has received is valid and, + assuming that the envelope permits doing so, relay it without + inspecting that content. Of course, if the content is mislabeled and + the data path cannot accept the actual content, this may result in + the ultimate delivery of a severely garbled message to the recipient. + Delivery SMTP systems MAY reject such messages, or return them as + undeliverable, rather than deliver them. In the absence of a server- + offered extension explicitly permitting it, a sending SMTP system is + not permitted to send envelope commands in any character set other + than US-ASCII. Receiving systems SHOULD reject such commands, + normally using "500 syntax error - invalid character" replies. + + 8-bit message content transmission MAY be requested of the server by + a client using extended SMTP facilities, notably the "8BITMIME" + extension, RFC 1652 [22]. 8BITMIME SHOULD be supported by SMTP + servers. However, it MUST NOT be construed as authorization to + transmit unrestricted 8-bit material, nor does 8BITMIME authorize + transmission of any envelope material in other than ASCII. 8BITMIME + MUST NOT be requested by senders for material with the high bit on + that is not in MIME format with an appropriate content-transfer + encoding; servers MAY reject such messages. + + The metalinguistic notation used in this document corresponds to the + "Augmented BNF" used in other Internet mail system documents. The + reader who is not familiar with that syntax should consult the ABNF + specification in RFC 5234 [7]. Metalanguage terms used in running + text are surrounded by pointed brackets (e.g., ) for clarity. + The reader is cautioned that the grammar expressed in the + metalanguage is not comprehensive. There are many instances in which + provisions in the text constrain or otherwise modify the syntax or + semantics implied by the grammar. + +3. The SMTP Procedures: An Overview + + This section contains descriptions of the procedures used in SMTP: + session initiation, mail transaction, forwarding mail, verifying + mailbox names and expanding mailing lists, and opening and closing + exchanges. Comments on relaying, a note on mail domains, and a + discussion of changing roles are included at the end of this section. + Several complete scenarios are presented in Appendix D. + + + + + +Klensin Standards Track [Page 17] + +RFC 5321 SMTP October 2008 + + +3.1. Session Initiation + + An SMTP session is initiated when a client opens a connection to a + server and the server responds with an opening message. + + SMTP server implementations MAY include identification of their + software and version information in the connection greeting reply + after the 220 code, a practice that permits more efficient isolation + and repair of any problems. Implementations MAY make provision for + SMTP servers to disable the software and version announcement where + it causes security concerns. While some systems also identify their + contact point for mail problems, this is not a substitute for + maintaining the required "postmaster" address (see Section 4). + + The SMTP protocol allows a server to formally reject a mail session + while still allowing the initial connection as follows: a 554 + response MAY be given in the initial connection opening message + instead of the 220. A server taking this approach MUST still wait + for the client to send a QUIT (see Section 4.1.1.10) before closing + the connection and SHOULD respond to any intervening commands with + "503 bad sequence of commands". Since an attempt to make an SMTP + connection to such a system is probably in error, a server returning + a 554 response on connection opening SHOULD provide enough + information in the reply text to facilitate debugging of the sending + system. + +3.2. Client Initiation + + Once the server has sent the greeting (welcoming) message and the + client has received it, the client normally sends the EHLO command to + the server, indicating the client's identity. In addition to opening + the session, use of EHLO indicates that the client is able to process + service extensions and requests that the server provide a list of the + extensions it supports. Older SMTP systems that are unable to + support service extensions, and contemporary clients that do not + require service extensions in the mail session being initiated, MAY + use HELO instead of EHLO. Servers MUST NOT return the extended EHLO- + style response to a HELO command. For a particular connection + attempt, if the server returns a "command not recognized" response to + EHLO, the client SHOULD be able to fall back and send HELO. + + In the EHLO command, the host sending the command identifies itself; + the command may be interpreted as saying "Hello, I am " (and, + in the case of EHLO, "and I support service extension requests"). + + + + + + + +Klensin Standards Track [Page 18] + +RFC 5321 SMTP October 2008 + + +3.3. Mail Transactions + + There are three steps to SMTP mail transactions. The transaction + starts with a MAIL command that gives the sender identification. (In + general, the MAIL command may be sent only when no mail transaction + is in progress; see Section 4.1.4.) A series of one or more RCPT + commands follows, giving the receiver information. Then, a DATA + command initiates transfer of the mail data and is terminated by the + "end of mail" data indicator, which also confirms the transaction. + + The first step in the procedure is the MAIL command. + + MAIL FROM: [SP ] + + This command tells the SMTP-receiver that a new mail transaction is + starting and to reset all its state tables and buffers, including any + recipients or mail data. The portion of the first or + only argument contains the source mailbox (between "<" and ">" + brackets), which can be used to report errors (see Section 4.2 for a + discussion of error reporting). If accepted, the SMTP server returns + a "250 OK" reply. If the mailbox specification is not acceptable for + some reason, the server MUST return a reply indicating whether the + failure is permanent (i.e., will occur again if the client tries to + send the same address again) or temporary (i.e., the address might be + accepted if the client tries again later). Despite the apparent + scope of this requirement, there are circumstances in which the + acceptability of the reverse-path may not be determined until one or + more forward-paths (in RCPT commands) can be examined. In those + cases, the server MAY reasonably accept the reverse-path (with a 250 + reply) and then report problems after the forward-paths are received + and examined. Normally, failures produce 550 or 553 replies. + + Historically, the was permitted to contain more than + just a mailbox; however, contemporary systems SHOULD NOT use source + routing (see Appendix C). + + The optional are associated with negotiated SMTP + service extensions (see Section 2.2). + + The second step in the procedure is the RCPT command. This step of + the procedure can be repeated any number of times. + + RCPT TO: [ SP ] + + The first or only argument to this command includes a forward-path + (normally a mailbox and domain, always surrounded by "<" and ">" + brackets) identifying one recipient. If accepted, the SMTP server + returns a "250 OK" reply and stores the forward-path. If the + + + +Klensin Standards Track [Page 19] + +RFC 5321 SMTP October 2008 + + + recipient is known not to be a deliverable address, the SMTP server + returns a 550 reply, typically with a string such as "no such user - + " and the mailbox name (other circumstances and reply codes are + possible). + + The can contain more than just a mailbox. + Historically, the was permitted to contain a source + routing list of hosts and the destination mailbox; however, + contemporary SMTP clients SHOULD NOT utilize source routes (see + Appendix C). Servers MUST be prepared to encounter a list of source + routes in the forward-path, but they SHOULD ignore the routes or MAY + decline to support the relaying they imply. Similarly, servers MAY + decline to accept mail that is destined for other hosts or systems. + These restrictions make a server useless as a relay for clients that + do not support full SMTP functionality. Consequently, restricted- + capability clients MUST NOT assume that any SMTP server on the + Internet can be used as their mail processing (relaying) site. If a + RCPT command appears without a previous MAIL command, the server MUST + return a 503 "Bad sequence of commands" response. The optional + are associated with negotiated SMTP service + extensions (see Section 2.2). + + Since it has been a common source of errors, it is worth noting that + spaces are not permitted on either side of the colon following FROM + in the MAIL command or TO in the RCPT command. The syntax is exactly + as given above. + + The third step in the procedure is the DATA command (or some + alternative specified in a service extension). + + DATA + + If accepted, the SMTP server returns a 354 Intermediate reply and + considers all succeeding lines up to but not including the end of + mail data indicator to be the message text. When the end of text is + successfully received and stored, the SMTP-receiver sends a "250 OK" + reply. + + Since the mail data is sent on the transmission channel, the end of + mail data must be indicated so that the command and reply dialog can + be resumed. SMTP indicates the end of the mail data by sending a + line containing only a "." (period or full stop). A transparency + procedure is used to prevent this from interfering with the user's + text (see Section 4.5.2). + + The end of mail data indicator also confirms the mail transaction and + tells the SMTP server to now process the stored recipients and mail + + + + +Klensin Standards Track [Page 20] + +RFC 5321 SMTP October 2008 + + + data. If accepted, the SMTP server returns a "250 OK" reply. The + DATA command can fail at only two points in the protocol exchange: + + If there was no MAIL, or no RCPT, command, or all such commands were + rejected, the server MAY return a "command out of sequence" (503) or + "no valid recipients" (554) reply in response to the DATA command. + If one of those replies (or any other 5yz reply) is received, the + client MUST NOT send the message data; more generally, message data + MUST NOT be sent unless a 354 reply is received. + + If the verb is initially accepted and the 354 reply issued, the DATA + command should fail only if the mail transaction was incomplete (for + example, no recipients), if resources were unavailable (including, of + course, the server unexpectedly becoming unavailable), or if the + server determines that the message should be rejected for policy or + other reasons. + + However, in practice, some servers do not perform recipient + verification until after the message text is received. These servers + SHOULD treat a failure for one or more recipients as a "subsequent + failure" and return a mail message as discussed in Section 6 and, in + particular, in Section 6.1. Using a "550 mailbox not found" (or + equivalent) reply code after the data are accepted makes it difficult + or impossible for the client to determine which recipients failed. + + When the RFC 822 format ([28], [4]) is being used, the mail data + include the header fields such as those named Date, Subject, To, Cc, + and From. Server SMTP systems SHOULD NOT reject messages based on + perceived defects in the RFC 822 or MIME (RFC 2045 [21]) message + header section or message body. In particular, they MUST NOT reject + messages in which the numbers of Resent-header fields do not match or + Resent-to appears without Resent-from and/or Resent-date. + + Mail transaction commands MUST be used in the order discussed above. + +3.4. Forwarding for Address Correction or Updating + + Forwarding support is most often required to consolidate and simplify + addresses within, or relative to, some enterprise and less frequently + to establish addresses to link a person's prior address with a + current one. Silent forwarding of messages (without server + notification to the sender), for security or non-disclosure purposes, + is common in the contemporary Internet. + + In both the enterprise and the "new address" cases, information + hiding (and sometimes security) considerations argue against exposure + of the "final" address through the SMTP protocol as a side effect of + the forwarding activity. This may be especially important when the + + + +Klensin Standards Track [Page 21] + +RFC 5321 SMTP October 2008 + + + final address may not even be reachable by the sender. Consequently, + the "forwarding" mechanisms described in Section 3.2 of RFC 821, and + especially the 251 (corrected destination) and 551 reply codes from + RCPT must be evaluated carefully by implementers and, when they are + available, by those configuring systems (see also Section 7.4). + + In particular: + + o Servers MAY forward messages when they are aware of an address + change. When they do so, they MAY either provide address-updating + information with a 251 code, or may forward "silently" and return + a 250 code. However, if a 251 code is used, they MUST NOT assume + that the client will actually update address information or even + return that information to the user. + + Alternately, + + o Servers MAY reject messages or return them as non-deliverable when + they cannot be delivered precisely as addressed. When they do so, + they MAY either provide address-updating information with a 551 + code, or may reject the message as undeliverable with a 550 code + and no address-specific information. However, if a 551 code is + used, they MUST NOT assume that the client will actually update + address information or even return that information to the user. + + SMTP server implementations that support the 251 and/or 551 reply + codes SHOULD provide configuration mechanisms so that sites that + conclude that they would undesirably disclose information can disable + or restrict their use. + +3.5. Commands for Debugging Addresses + +3.5.1. Overview + + SMTP provides commands to verify a user name or obtain the content of + a mailing list. This is done with the VRFY and EXPN commands, which + have character string arguments. Implementations SHOULD support VRFY + and EXPN (however, see Section 3.5.2 and Section 7.3). + + For the VRFY command, the string is a user name or a user name and + domain (see below). If a normal (i.e., 250) response is returned, + the response MAY include the full name of the user and MUST include + the mailbox of the user. It MUST be in either of the following + forms: + + User Name + local-part@domain + + + + +Klensin Standards Track [Page 22] + +RFC 5321 SMTP October 2008 + + + When a name that is the argument to VRFY could identify more than one + mailbox, the server MAY either note the ambiguity or identify the + alternatives. In other words, any of the following are legitimate + responses to VRFY: + + 553 User ambiguous + + or + + 553- Ambiguous; Possibilities are + 553-Joe Smith + 553-Harry Smith + 553 Melvin Smith + + or + + 553-Ambiguous; Possibilities + 553- + 553- + 553 + + Under normal circumstances, a client receiving a 553 reply would be + expected to expose the result to the user. Use of exactly the forms + given, and the "user ambiguous" or "ambiguous" keywords, possibly + supplemented by extended reply codes, such as those described in RFC + 3463 [25], will facilitate automated translation into other languages + as needed. Of course, a client that was highly automated or that was + operating in another language than English might choose to try to + translate the response to return some other indication to the user + than the literal text of the reply, or to take some automated action + such as consulting a directory service for additional information + before reporting to the user. + + For the EXPN command, the string identifies a mailing list, and the + successful (i.e., 250) multiline response MAY include the full name + of the users and MUST give the mailboxes on the mailing list. + + In some hosts, the distinction between a mailing list and an alias + for a single mailbox is a bit fuzzy, since a common data structure + may hold both types of entries, and it is possible to have mailing + lists containing only one mailbox. If a request is made to apply + VRFY to a mailing list, a positive response MAY be given if a message + so addressed would be delivered to everyone on the list, otherwise an + error SHOULD be reported (e.g., "550 That is a mailing list, not a + user" or "252 Unable to verify members of mailing list"). If a + request is made to expand a user name, the server MAY return a + + + + + +Klensin Standards Track [Page 23] + +RFC 5321 SMTP October 2008 + + + positive response consisting of a list containing one name, or an + error MAY be reported (e.g., "550 That is a user name, not a mailing + list"). + + In the case of a successful multiline reply (normal for EXPN), + exactly one mailbox is to be specified on each line of the reply. + The case of an ambiguous request is discussed above. + + "User name" is a fuzzy term and has been used deliberately. An + implementation of the VRFY or EXPN commands MUST include at least + recognition of local mailboxes as "user names". However, since + current Internet practice often results in a single host handling + mail for multiple domains, hosts, especially hosts that provide this + functionality, SHOULD accept the "local-part@domain" form as a "user + name"; hosts MAY also choose to recognize other strings as "user + names". + + The case of expanding a mailbox list requires a multiline reply, such + as: + + C: EXPN Example-People + S: 250-Jon Postel + S: 250-Fred Fonebone + S: 250 Sam Q. Smith + + or + + C: EXPN Executive-Washroom-List + S: 550 Access Denied to You. + + The character string arguments of the VRFY and EXPN commands cannot + be further restricted due to the variety of implementations of the + user name and mailbox list concepts. On some systems, it may be + appropriate for the argument of the EXPN command to be a file name + for a file containing a mailing list, but again there are a variety + of file naming conventions in the Internet. Similarly, historical + variations in what is returned by these commands are such that the + response SHOULD be interpreted very carefully, if at all, and SHOULD + generally only be used for diagnostic purposes. + +3.5.2. VRFY Normal Response + + When normal (2yz or 551) responses are returned from a VRFY or EXPN + request, the reply MUST include the name using a + "" construction, where "domain" is a fully- + qualified domain name. In circumstances exceptional enough to + justify violating the intent of this specification, free-form text + MAY be returned. In order to facilitate parsing by both computers + + + +Klensin Standards Track [Page 24] + +RFC 5321 SMTP October 2008 + + + and people, addresses SHOULD appear in pointed brackets. When + addresses, rather than free-form debugging information, are returned, + EXPN and VRFY MUST return only valid domain addresses that are usable + in SMTP RCPT commands. Consequently, if an address implies delivery + to a program or other system, the mailbox name used to reach that + target MUST be given. Paths (explicit source routes) MUST NOT be + returned by VRFY or EXPN. + + Server implementations SHOULD support both VRFY and EXPN. For + security reasons, implementations MAY provide local installations a + way to disable either or both of these commands through configuration + options or the equivalent (see Section 7.3). When these commands are + supported, they are not required to work across relays when relaying + is supported. Since they were both optional in RFC 821, but VRFY was + made mandatory in RFC 1123 [3], if EXPN is supported, it MUST be + listed as a service extension in an EHLO response. VRFY MAY be + listed as a convenience but, since support for it is required, SMTP + clients are not required to check for its presence on the extension + list before using it. + +3.5.3. Meaning of VRFY or EXPN Success Response + + A server MUST NOT return a 250 code in response to a VRFY or EXPN + command unless it has actually verified the address. In particular, + a server MUST NOT return 250 if all it has done is to verify that the + syntax given is valid. In that case, 502 (Command not implemented) + or 500 (Syntax error, command unrecognized) SHOULD be returned. As + stated elsewhere, implementation (in the sense of actually validating + addresses and returning information) of VRFY and EXPN are strongly + recommended. Hence, implementations that return 500 or 502 for VRFY + are not in full compliance with this specification. + + There may be circumstances where an address appears to be valid but + cannot reasonably be verified in real time, particularly when a + server is acting as a mail exchanger for another server or domain. + "Apparent validity", in this case, would normally involve at least + syntax checking and might involve verification that any domains + specified were ones to which the host expected to be able to relay + mail. In these situations, reply code 252 SHOULD be returned. These + cases parallel the discussion of RCPT verification in Section 2.1. + Similarly, the discussion in Section 3.4 applies to the use of reply + codes 251 and 551 with VRFY (and EXPN) to indicate addresses that are + recognized but that would be forwarded or rejected were mail received + for them. Implementations generally SHOULD be more aggressive about + address verification in the case of VRFY than in the case of RCPT, + even if it takes a little longer to do so. + + + + + +Klensin Standards Track [Page 25] + +RFC 5321 SMTP October 2008 + + +3.5.4. Semantics and Applications of EXPN + + EXPN is often very useful in debugging and understanding problems + with mailing lists and multiple-target-address aliases. Some systems + have attempted to use source expansion of mailing lists as a means of + eliminating duplicates. The propagation of aliasing systems with + mail on the Internet for hosts (typically with MX and CNAME DNS + records), for mailboxes (various types of local host aliases), and in + various proxying arrangements has made it nearly impossible for these + strategies to work consistently, and mail systems SHOULD NOT attempt + them. + +3.6. Relaying and Mail Routing + +3.6.1. Source Routes and Relaying + + In general, the availability of Mail eXchanger records in the domain + name system (RFC 1035 [2], RFC 974 [12]) makes the use of explicit + source routes in the Internet mail system unnecessary. Many + historical problems with the interpretation of explicit source routes + have made their use undesirable. SMTP clients SHOULD NOT generate + explicit source routes except under unusual circumstances. SMTP + servers MAY decline to act as mail relays or to accept addresses that + specify source routes. When route information is encountered, SMTP + servers MAY ignore the route information and simply send to the final + destination specified as the last element in the route and SHOULD do + so. There has been an invalid practice of using names that do not + appear in the DNS as destination names, with the senders counting on + the intermediate hosts specified in source routing to resolve any + problems. If source routes are stripped, this practice will cause + failures. This is one of several reasons why SMTP clients MUST NOT + generate invalid source routes or depend on serial resolution of + names. + + When source routes are not used, the process described in RFC 821 for + constructing a reverse-path from the forward-path is not applicable + and the reverse-path at the time of delivery will simply be the + address that appeared in the MAIL command. + +3.6.2. Mail eXchange Records and Relaying + + A relay SMTP server is usually the target of a DNS MX record that + designates it, rather than the final delivery system. The relay + server may accept or reject the task of relaying the mail in the same + way it accepts or rejects mail for a local user. If it accepts the + task, it then becomes an SMTP client, establishes a transmission + channel to the next SMTP server specified in the DNS (according to + the rules in Section 5), and sends it the mail. If it declines to + + + +Klensin Standards Track [Page 26] + +RFC 5321 SMTP October 2008 + + + relay mail to a particular address for policy reasons, a 550 response + SHOULD be returned. + + This specification does not deal with the verification of return + paths for use in delivery notifications. Recent work, such as that + on SPF [29] and DKIM [30] [31], has been done to provide ways to + ascertain that an address is valid or belongs to the person who + actually sent the message. A server MAY attempt to verify the return + path before using its address for delivery notifications, but methods + of doing so are not defined here nor is any particular method + recommended at this time. + +3.6.3. Message Submission Servers as Relays + + Many mail-sending clients exist, especially in conjunction with + facilities that receive mail via POP3 or IMAP, that have limited + capability to support some of the requirements of this specification, + such as the ability to queue messages for subsequent delivery + attempts. For these clients, it is common practice to make private + arrangements to send all messages to a single server for processing + and subsequent distribution. SMTP, as specified here, is not ideally + suited for this role. A standardized mail submission protocol has + been developed that is gradually superseding practices based on SMTP + (see RFC 4409 [18]). In any event, because these arrangements are + private and fall outside the scope of this specification, they are + not described here. + + It is important to note that MX records can point to SMTP servers + that act as gateways into other environments, not just SMTP relays + and final delivery systems; see Sections 3.7 and 5. + + If an SMTP server has accepted the task of relaying the mail and + later finds that the destination is incorrect or that the mail cannot + be delivered for some other reason, then it MUST construct an + "undeliverable mail" notification message and send it to the + originator of the undeliverable mail (as indicated by the reverse- + path). Formats specified for non-delivery reports by other standards + (see, for example, RFC 3461 [32] and RFC 3464 [33]) SHOULD be used if + possible. + + This notification message must be from the SMTP server at the relay + host or the host that first determines that delivery cannot be + accomplished. Of course, SMTP servers MUST NOT send notification + messages about problems transporting notification messages. One way + to prevent loops in error reporting is to specify a null reverse-path + in the MAIL command of a notification message. When such a message + is transmitted, the reverse-path MUST be set to null (see + + + + +Klensin Standards Track [Page 27] + +RFC 5321 SMTP October 2008 + + + Section 4.5.5 for additional discussion). A MAIL command with a null + reverse-path appears as follows: + + MAIL FROM:<> + + As discussed in Section 6.4, a relay SMTP has no need to inspect or + act upon the header section or body of the message data and MUST NOT + do so except to add its own "Received:" header field (Section 4.4) + and, optionally, to attempt to detect looping in the mail system (see + Section 6.3). Of course, this prohibition also applies to any + modifications of these header fields or text (see also Section 7.9). + +3.7. Mail Gatewaying + + While the relay function discussed above operates within the Internet + SMTP transport service environment, MX records or various forms of + explicit routing may require that an intermediate SMTP server perform + a translation function between one transport service and another. As + discussed in Section 2.3.10, when such a system is at the boundary + between two transport service environments, we refer to it as a + "gateway" or "gateway SMTP". + + Gatewaying mail between different mail environments, such as + different mail formats and protocols, is complex and does not easily + yield to standardization. However, some general requirements may be + given for a gateway between the Internet and another mail + environment. + +3.7.1. Header Fields in Gatewaying + + Header fields MAY be rewritten when necessary as messages are + gatewayed across mail environment boundaries. This may involve + inspecting the message body or interpreting the local-part of the + destination address in spite of the prohibitions in Section 6.4. + + Other mail systems gatewayed to the Internet often use a subset of + the RFC 822 header section or provide similar functionality with a + different syntax, but some of these mail systems do not have an + equivalent to the SMTP envelope. Therefore, when a message leaves + the Internet environment, it may be necessary to fold the SMTP + envelope information into the message header section. A possible + solution would be to create new header fields to carry the envelope + information (e.g., "X-SMTP-MAIL:" and "X-SMTP-RCPT:"); however, this + would require changes in mail programs in foreign environments and + might risk disclosure of private information (see Section 7.2). + + + + + + +Klensin Standards Track [Page 28] + +RFC 5321 SMTP October 2008 + + +3.7.2. Received Lines in Gatewaying + + When forwarding a message into or out of the Internet environment, a + gateway MUST prepend a Received: line, but it MUST NOT alter in any + way a Received: line that is already in the header section. + + "Received:" header fields of messages originating from other + environments may not conform exactly to this specification. However, + the most important use of Received: lines is for debugging mail + faults, and this debugging can be severely hampered by well-meaning + gateways that try to "fix" a Received: line. As another consequence + of trace header fields arising in non-SMTP environments, receiving + systems MUST NOT reject mail based on the format of a trace header + field and SHOULD be extremely robust in the light of unexpected + information or formats in those header fields. + + The gateway SHOULD indicate the environment and protocol in the "via" + clauses of Received header field(s) that it supplies. + +3.7.3. Addresses in Gatewaying + + From the Internet side, the gateway SHOULD accept all valid address + formats in SMTP commands and in the RFC 822 header section, and all + valid RFC 822 messages. Addresses and header fields generated by + gateways MUST conform to applicable standards (including this one and + RFC 5322 [4]). Gateways are, of course, subject to the same rules + for handling source routes as those described for other SMTP systems + in Section 3.3. + +3.7.4. Other Header Fields in Gatewaying + + The gateway MUST ensure that all header fields of a message that it + forwards into the Internet mail environment meet the requirements for + Internet mail. In particular, all addresses in "From:", "To:", + "Cc:", etc., header fields MUST be transformed (if necessary) to + satisfy the standard header syntax of RFC 5322 [4], MUST reference + only fully-qualified domain names, and MUST be effective and useful + for sending replies. The translation algorithm used to convert mail + from the Internet protocols to another environment's protocol SHOULD + ensure that error messages from the foreign mail environment are + delivered to the reverse-path from the SMTP envelope, not to an + address in the "From:", "Sender:", or similar header fields of the + message. + + + + + + + + +Klensin Standards Track [Page 29] + +RFC 5321 SMTP October 2008 + + +3.7.5. Envelopes in Gatewaying + + Similarly, when forwarding a message from another environment into + the Internet, the gateway SHOULD set the envelope return path in + accordance with an error message return address, if supplied by the + foreign environment. If the foreign environment has no equivalent + concept, the gateway must select and use a best approximation, with + the message originator's address as the default of last resort. + +3.8. Terminating Sessions and Connections + + An SMTP connection is terminated when the client sends a QUIT + command. The server responds with a positive reply code, after which + it closes the connection. + + An SMTP server MUST NOT intentionally close the connection under + normal operational circumstances (see Section 7.8) except: + + o After receiving a QUIT command and responding with a 221 reply. + + o After detecting the need to shut down the SMTP service and + returning a 421 response code. This response code can be issued + after the server receives any command or, if necessary, + asynchronously from command receipt (on the assumption that the + client will receive it after the next command is issued). + + o After a timeout, as specified in Section 4.5.3.2, occurs waiting + for the client to send a command or data. + + In particular, a server that closes connections in response to + commands that are not understood is in violation of this + specification. Servers are expected to be tolerant of unknown + commands, issuing a 500 reply and awaiting further instructions from + the client. + + An SMTP server that is forcibly shut down via external means SHOULD + attempt to send a line containing a 421 response code to the SMTP + client before exiting. The SMTP client will normally read the 421 + response code after sending its next command. + + SMTP clients that experience a connection close, reset, or other + communications failure due to circumstances not under their control + (in violation of the intent of this specification but sometimes + unavoidable) SHOULD, to maintain the robustness of the mail system, + treat the mail transaction as if a 451 response had been received and + act accordingly. + + + + + +Klensin Standards Track [Page 30] + +RFC 5321 SMTP October 2008 + + +3.9. Mailing Lists and Aliases + + An SMTP-capable host SHOULD support both the alias and the list + models of address expansion for multiple delivery. When a message is + delivered or forwarded to each address of an expanded list form, the + return address in the envelope ("MAIL FROM:") MUST be changed to be + the address of a person or other entity who administers the list. + However, in this case, the message header section (RFC 5322 [4]) MUST + be left unchanged; in particular, the "From" field of the header + section is unaffected. + + An important mail facility is a mechanism for multi-destination + delivery of a single message, by transforming (or "expanding" or + "exploding") a pseudo-mailbox address into a list of destination + mailbox addresses. When a message is sent to such a pseudo-mailbox + (sometimes called an "exploder"), copies are forwarded or + redistributed to each mailbox in the expanded list. Servers SHOULD + simply utilize the addresses on the list; application of heuristics + or other matching rules to eliminate some addresses, such as that of + the originator, is strongly discouraged. We classify such a pseudo- + mailbox as an "alias" or a "list", depending upon the expansion + rules. + +3.9.1. Alias + + To expand an alias, the recipient mailer simply replaces the pseudo- + mailbox address in the envelope with each of the expanded addresses + in turn; the rest of the envelope and the message body are left + unchanged. The message is then delivered or forwarded to each + expanded address. + +3.9.2. List + + A mailing list may be said to operate by "redistribution" rather than + by "forwarding". To expand a list, the recipient mailer replaces the + pseudo-mailbox address in the envelope with each of the expanded + addresses in turn. The return (backward-pointing) address in the + envelope is changed so that all error messages generated by the final + deliveries will be returned to a list administrator, not to the + message originator, who generally has no control over the contents of + the list and will typically find error messages annoying. Note that + the key difference between handling aliases (Section 3.9.1) and + forwarding (this subsection) is the change to the backward-pointing + address in this case. When a list constrains its processing to the + very limited set of modifications and actions described here, it is + attempting to emulate an MTA; such lists can be treated as a + continuation in email transit. + + + + +Klensin Standards Track [Page 31] + +RFC 5321 SMTP October 2008 + + + There exist mailing lists that perform additional, sometimes + extensive, modifications to a message and its envelope. Such mailing + lists need to be viewed as full MUAs, which accept a delivery and + post a new message. + +4. The SMTP Specifications + +4.1. SMTP Commands + +4.1.1. Command Semantics and Syntax + + The SMTP commands define the mail transfer or the mail system + function requested by the user. SMTP commands are character strings + terminated by . The commands themselves are alphabetic + characters terminated by if parameters follow and + otherwise. (In the interest of improved interoperability, SMTP + receivers SHOULD tolerate trailing white space before the terminating + .) The syntax of the local part of a mailbox MUST conform to + receiver site conventions and the syntax specified in Section 4.1.2. + The SMTP commands are discussed below. The SMTP replies are + discussed in Section 4.2. + + A mail transaction involves several data objects that are + communicated as arguments to different commands. The reverse-path is + the argument of the MAIL command, the forward-path is the argument of + the RCPT command, and the mail data is the argument of the DATA + command. These arguments or data objects must be transmitted and + held, pending the confirmation communicated by the end of mail data + indication that finalizes the transaction. The model for this is + that distinct buffers are provided to hold the types of data objects; + that is, there is a reverse-path buffer, a forward-path buffer, and a + mail data buffer. Specific commands cause information to be appended + to a specific buffer, or cause one or more buffers to be cleared. + + Several commands (RSET, DATA, QUIT) are specified as not permitting + parameters. In the absence of specific extensions offered by the + server and accepted by the client, clients MUST NOT send such + parameters and servers SHOULD reject commands containing them as + having invalid syntax. + +4.1.1.1. Extended HELLO (EHLO) or HELLO (HELO) + + These commands are used to identify the SMTP client to the SMTP + server. The argument clause contains the fully-qualified domain name + of the SMTP client, if one is available. In situations in which the + SMTP client system does not have a meaningful domain name (e.g., when + its address is dynamically allocated and no reverse mapping record is + + + + +Klensin Standards Track [Page 32] + +RFC 5321 SMTP October 2008 + + + available), the client SHOULD send an address literal (see + Section 4.1.3). + + RFC 2821, and some earlier informal practices, encouraged following + the literal by information that would help to identify the client + system. That convention was not widely supported, and many SMTP + servers considered it an error. In the interest of interoperability, + it is probably wise for servers to be prepared for this string to + occur, but SMTP clients SHOULD NOT send it. + + The SMTP server identifies itself to the SMTP client in the + connection greeting reply and in the response to this command. + + A client SMTP SHOULD start an SMTP session by issuing the EHLO + command. If the SMTP server supports the SMTP service extensions, it + will give a successful response, a failure response, or an error + response. If the SMTP server, in violation of this specification, + does not support any SMTP service extensions, it will generate an + error response. Older client SMTP systems MAY, as discussed above, + use HELO (as specified in RFC 821) instead of EHLO, and servers MUST + support the HELO command and reply properly to it. In any event, a + client MUST issue HELO or EHLO before starting a mail transaction. + + These commands, and a "250 OK" reply to one of them, confirm that + both the SMTP client and the SMTP server are in the initial state, + that is, there is no transaction in progress and all state tables and + buffers are cleared. + + Syntax: + + ehlo = "EHLO" SP ( Domain / address-literal ) CRLF + + helo = "HELO" SP Domain CRLF + + Normally, the response to EHLO will be a multiline reply. Each line + of the response contains a keyword and, optionally, one or more + parameters. Following the normal syntax for multiline replies, these + keywords follow the code (250) and a hyphen for all but the last + line, and the code and a space for the last line. The syntax for a + positive response, using the ABNF notation and terminal symbols of + RFC 5234 [7], is: + + ehlo-ok-rsp = ( "250" SP Domain [ SP ehlo-greet ] CRLF ) + / ( "250-" Domain [ SP ehlo-greet ] CRLF + *( "250-" ehlo-line CRLF ) + "250" SP ehlo-line CRLF ) + + + + + +Klensin Standards Track [Page 33] + +RFC 5321 SMTP October 2008 + + + ehlo-greet = 1*(%d0-9 / %d11-12 / %d14-127) + ; string of any characters other than CR or LF + + ehlo-line = ehlo-keyword *( SP ehlo-param ) + + ehlo-keyword = (ALPHA / DIGIT) *(ALPHA / DIGIT / "-") + ; additional syntax of ehlo-params depends on + ; ehlo-keyword + + ehlo-param = 1*(%d33-126) + ; any CHAR excluding and all + ; control characters (US-ASCII 0-31 and 127 + ; inclusive) + + Although EHLO keywords may be specified in upper, lower, or mixed + case, they MUST always be recognized and processed in a case- + insensitive manner. This is simply an extension of practices + specified in RFC 821 and Section 2.4. + + The EHLO response MUST contain keywords (and associated parameters if + required) for all commands not listed as "required" in Section 4.5.1 + excepting only private-use commands as described in Section 4.1.5. + Private-use commands MAY be listed. + +4.1.1.2. MAIL (MAIL) + + This command is used to initiate a mail transaction in which the mail + data is delivered to an SMTP server that may, in turn, deliver it to + one or more mailboxes or pass it on to another system (possibly using + SMTP). The argument clause contains a reverse-path and may contain + optional parameters. In general, the MAIL command may be sent only + when no mail transaction is in progress, see Section 4.1.4. + + The reverse-path consists of the sender mailbox. Historically, that + mailbox might optionally have been preceded by a list of hosts, but + that behavior is now deprecated (see Appendix C). In some types of + reporting messages for which a reply is likely to cause a mail loop + (for example, mail delivery and non-delivery notifications), the + reverse-path may be null (see Section 3.6). + + This command clears the reverse-path buffer, the forward-path buffer, + and the mail data buffer, and it inserts the reverse-path information + from its argument clause into the reverse-path buffer. + + If service extensions were negotiated, the MAIL command may also + carry parameters associated with a particular service extension. + + + + + +Klensin Standards Track [Page 34] + +RFC 5321 SMTP October 2008 + + + Syntax: + + mail = "MAIL FROM:" Reverse-path + [SP Mail-parameters] CRLF + +4.1.1.3. RECIPIENT (RCPT) + + This command is used to identify an individual recipient of the mail + data; multiple recipients are specified by multiple uses of this + command. The argument clause contains a forward-path and may contain + optional parameters. + + The forward-path normally consists of the required destination + mailbox. Sending systems SHOULD NOT generate the optional list of + hosts known as a source route. Receiving systems MUST recognize + source route syntax but SHOULD strip off the source route + specification and utilize the domain name associated with the mailbox + as if the source route had not been provided. + + Similarly, relay hosts SHOULD strip or ignore source routes, and + names MUST NOT be copied into the reverse-path. When mail reaches + its ultimate destination (the forward-path contains only a + destination mailbox), the SMTP server inserts it into the destination + mailbox in accordance with its host mail conventions. + + This command appends its forward-path argument to the forward-path + buffer; it does not change the reverse-path buffer nor the mail data + buffer. + + For example, mail received at relay host xyz.com with envelope + commands + + MAIL FROM: + RCPT TO:<@hosta.int,@jkl.org:userc@d.bar.org> + + will normally be sent directly on to host d.bar.org with envelope + commands + + MAIL FROM: + RCPT TO: + + As provided in Appendix C, xyz.com MAY also choose to relay the + message to hosta.int, using the envelope commands + + MAIL FROM: + RCPT TO:<@hosta.int,@jkl.org:userc@d.bar.org> + + + + + +Klensin Standards Track [Page 35] + +RFC 5321 SMTP October 2008 + + + or to jkl.org, using the envelope commands + + MAIL FROM: + RCPT TO:<@jkl.org:userc@d.bar.org> + + Attempting to use relaying this way is now strongly discouraged. + Since hosts are not required to relay mail at all, xyz.com MAY also + reject the message entirely when the RCPT command is received, using + a 550 code (since this is a "policy reason"). + + If service extensions were negotiated, the RCPT command may also + carry parameters associated with a particular service extension + offered by the server. The client MUST NOT transmit parameters other + than those associated with a service extension offered by the server + in its EHLO response. + + Syntax: + + rcpt = "RCPT TO:" ( "" / "" / + Forward-path ) [SP Rcpt-parameters] CRLF + + Note that, in a departure from the usual rules for + local-parts, the "Postmaster" string shown above is + treated as case-insensitive. + +4.1.1.4. DATA (DATA) + + The receiver normally sends a 354 response to DATA, and then treats + the lines (strings ending in sequences, as described in + Section 2.3.7) following the command as mail data from the sender. + This command causes the mail data to be appended to the mail data + buffer. The mail data may contain any of the 128 ASCII character + codes, although experience has indicated that use of control + characters other than SP, HT, CR, and LF may cause problems and + SHOULD be avoided when possible. + + The mail data are terminated by a line containing only a period, that + is, the character sequence ".", where the first is + actually the terminator of the previous line (see Section 4.5.2). + This is the end of mail data indication. The first of this + terminating sequence is also the that ends the final line of + the data (message text) or, if there was no mail data, ends the DATA + command itself (the "no mail data" case does not conform to this + specification since it would require that neither the trace header + fields required by this specification nor the message header section + required by RFC 5322 [4] be transmitted). An extra MUST NOT + be added, as that would cause an empty line to be added to the + message. The only exception to this rule would arise if the message + + + +Klensin Standards Track [Page 36] + +RFC 5321 SMTP October 2008 + + + body were passed to the originating SMTP-sender with a final "line" + that did not end in ; in that case, the originating SMTP system + MUST either reject the message as invalid or add in order to + have the receiving SMTP server recognize the "end of data" condition. + + The custom of accepting lines ending only in , as a concession to + non-conforming behavior on the part of some UNIX systems, has proven + to cause more interoperability problems than it solves, and SMTP + server systems MUST NOT do this, even in the name of improved + robustness. In particular, the sequence "." (bare line + feeds, without carriage returns) MUST NOT be treated as equivalent to + . as the end of mail data indication. + + Receipt of the end of mail data indication requires the server to + process the stored mail transaction information. This processing + consumes the information in the reverse-path buffer, the forward-path + buffer, and the mail data buffer, and on the completion of this + command these buffers are cleared. If the processing is successful, + the receiver MUST send an OK reply. If the processing fails, the + receiver MUST send a failure reply. The SMTP model does not allow + for partial failures at this point: either the message is accepted by + the server for delivery and a positive response is returned or it is + not accepted and a failure reply is returned. In sending a positive + "250 OK" completion reply to the end of data indication, the receiver + takes full responsibility for the message (see Section 6.1). Errors + that are diagnosed subsequently MUST be reported in a mail message, + as discussed in Section 4.4. + + When the SMTP server accepts a message either for relaying or for + final delivery, it inserts a trace record (also referred to + interchangeably as a "time stamp line" or "Received" line) at the top + of the mail data. This trace record indicates the identity of the + host that sent the message, the identity of the host that received + the message (and is inserting this time stamp), and the date and time + the message was received. Relayed messages will have multiple time + stamp lines. Details for formation of these lines, including their + syntax, is specified in Section 4.4. + + Additional discussion about the operation of the DATA command appears + in Section 3.3. + + Syntax: + + data = "DATA" CRLF + + + + + + + +Klensin Standards Track [Page 37] + +RFC 5321 SMTP October 2008 + + +4.1.1.5. RESET (RSET) + + This command specifies that the current mail transaction will be + aborted. Any stored sender, recipients, and mail data MUST be + discarded, and all buffers and state tables cleared. The receiver + MUST send a "250 OK" reply to a RSET command with no arguments. A + reset command may be issued by the client at any time. It is + effectively equivalent to a NOOP (i.e., it has no effect) if issued + immediately after EHLO, before EHLO is issued in the session, after + an end of data indicator has been sent and acknowledged, or + immediately before a QUIT. An SMTP server MUST NOT close the + connection as the result of receiving a RSET; that action is reserved + for QUIT (see Section 4.1.1.10). + + Since EHLO implies some additional processing and response by the + server, RSET will normally be more efficient than reissuing that + command, even though the formal semantics are the same. + + There are circumstances, contrary to the intent of this + specification, in which an SMTP server may receive an indication that + the underlying TCP connection has been closed or reset. To preserve + the robustness of the mail system, SMTP servers SHOULD be prepared + for this condition and SHOULD treat it as if a QUIT had been received + before the connection disappeared. + + Syntax: + + rset = "RSET" CRLF + +4.1.1.6. VERIFY (VRFY) + + This command asks the receiver to confirm that the argument + identifies a user or mailbox. If it is a user name, information is + returned as specified in Section 3.5. + + This command has no effect on the reverse-path buffer, the forward- + path buffer, or the mail data buffer. + + Syntax: + + vrfy = "VRFY" SP String CRLF + + + + + + + + + + +Klensin Standards Track [Page 38] + +RFC 5321 SMTP October 2008 + + +4.1.1.7. EXPAND (EXPN) + + This command asks the receiver to confirm that the argument + identifies a mailing list, and if so, to return the membership of + that list. If the command is successful, a reply is returned + containing information as described in Section 3.5. This reply will + have multiple lines except in the trivial case of a one-member list. + + This command has no effect on the reverse-path buffer, the forward- + path buffer, or the mail data buffer, and it may be issued at any + time. + + Syntax: + + expn = "EXPN" SP String CRLF + +4.1.1.8. HELP (HELP) + + This command causes the server to send helpful information to the + client. The command MAY take an argument (e.g., any command name) + and return more specific information as a response. + + This command has no effect on the reverse-path buffer, the forward- + path buffer, or the mail data buffer, and it may be issued at any + time. + + SMTP servers SHOULD support HELP without arguments and MAY support it + with arguments. + + Syntax: + + help = "HELP" [ SP String ] CRLF + + + + + + + + + + + + + + + + + + + +Klensin Standards Track [Page 39] + +RFC 5321 SMTP October 2008 + + +4.1.1.9. NOOP (NOOP) + + This command does not affect any parameters or previously entered + commands. It specifies no action other than that the receiver send a + "250 OK" reply. + + This command has no effect on the reverse-path buffer, the forward- + path buffer, or the mail data buffer, and it may be issued at any + time. If a parameter string is specified, servers SHOULD ignore it. + + Syntax: + + noop = "NOOP" [ SP String ] CRLF + +4.1.1.10. QUIT (QUIT) + + This command specifies that the receiver MUST send a "221 OK" reply, + and then close the transmission channel. + + The receiver MUST NOT intentionally close the transmission channel + until it receives and replies to a QUIT command (even if there was an + error). The sender MUST NOT intentionally close the transmission + channel until it sends a QUIT command, and it SHOULD wait until it + receives the reply (even if there was an error response to a previous + command). If the connection is closed prematurely due to violations + of the above or system or network failure, the server MUST cancel any + pending transaction, but not undo any previously completed + transaction, and generally MUST act as if the command or transaction + in progress had received a temporary error (i.e., a 4yz response). + + The QUIT command may be issued at any time. Any current uncompleted + mail transaction will be aborted. + + Syntax: + + quit = "QUIT" CRLF + +4.1.1.11. Mail-Parameter and Rcpt-Parameter Error Responses + + If the server SMTP does not recognize or cannot implement one or more + of the parameters associated with a particular MAIL FROM or RCPT TO + command, it will return code 555. + + If, for some reason, the server is temporarily unable to accommodate + one or more of the parameters associated with a MAIL FROM or RCPT TO + command, and if the definition of the specific parameter does not + mandate the use of another code, it should return code 455. + + + + +Klensin Standards Track [Page 40] + +RFC 5321 SMTP October 2008 + + + Errors specific to particular parameters and their values will be + specified in the parameter's defining RFC. + +4.1.2. Command Argument Syntax + + The syntax of the argument clauses of the above commands (using the + syntax specified in RFC 5234 [7] where applicable) is given below. + Some of the productions given below are used only in conjunction with + source routes as described in Appendix C. Terminals not defined in + this document, such as ALPHA, DIGIT, SP, CR, LF, CRLF, are as defined + in the "core" syntax in Section 6 of RFC 5234 [7] or in the message + format syntax in RFC 5322 [4]. + + Reverse-path = Path / "<>" + + Forward-path = Path + + Path = "<" [ A-d-l ":" ] Mailbox ">" + + A-d-l = At-domain *( "," At-domain ) + ; Note that this form, the so-called "source + ; route", MUST BE accepted, SHOULD NOT be + ; generated, and SHOULD be ignored. + + At-domain = "@" Domain + + Mail-parameters = esmtp-param *(SP esmtp-param) + + Rcpt-parameters = esmtp-param *(SP esmtp-param) + + esmtp-param = esmtp-keyword ["=" esmtp-value] + + esmtp-keyword = (ALPHA / DIGIT) *(ALPHA / DIGIT / "-") + + esmtp-value = 1*(%d33-60 / %d62-126) + ; any CHAR excluding "=", SP, and control + ; characters. If this string is an email address, + ; i.e., a Mailbox, then the "xtext" syntax [32] + ; SHOULD be used. + + Keyword = Ldh-str + + Argument = Atom + + Domain = sub-domain *("." sub-domain) + + + + + + +Klensin Standards Track [Page 41] + +RFC 5321 SMTP October 2008 + + + sub-domain = Let-dig [Ldh-str] + + Let-dig = ALPHA / DIGIT + + Ldh-str = *( ALPHA / DIGIT / "-" ) Let-dig + + address-literal = "[" ( IPv4-address-literal / + IPv6-address-literal / + General-address-literal ) "]" + ; See Section 4.1.3 + + Mailbox = Local-part "@" ( Domain / address-literal ) + + Local-part = Dot-string / Quoted-string + ; MAY be case-sensitive + + + Dot-string = Atom *("." Atom) + + Atom = 1*atext + + Quoted-string = DQUOTE *QcontentSMTP DQUOTE + + QcontentSMTP = qtextSMTP / quoted-pairSMTP + + quoted-pairSMTP = %d92 %d32-126 + ; i.e., backslash followed by any ASCII + ; graphic (including itself) or SPace + + qtextSMTP = %d32-33 / %d35-91 / %d93-126 + ; i.e., within a quoted string, any + ; ASCII graphic or space is permitted + ; without blackslash-quoting except + ; double-quote and the backslash itself. + + String = Atom / Quoted-string + + While the above definition for Local-part is relatively permissive, + for maximum interoperability, a host that expects to receive mail + SHOULD avoid defining mailboxes where the Local-part requires (or + uses) the Quoted-string form or where the Local-part is case- + sensitive. For any purposes that require generating or comparing + Local-parts (e.g., to specific mailbox names), all quoted forms MUST + be treated as equivalent, and the sending system SHOULD transmit the + form that uses the minimum quoting possible. + + Systems MUST NOT define mailboxes in such a way as to require the use + in SMTP of non-ASCII characters (octets with the high order bit set + + + +Klensin Standards Track [Page 42] + +RFC 5321 SMTP October 2008 + + + to one) or ASCII "control characters" (decimal value 0-31 and 127). + These characters MUST NOT be used in MAIL or RCPT commands or other + commands that require mailbox names. + + Note that the backslash, "\", is a quote character, which is used to + indicate that the next character is to be used literally (instead of + its normal interpretation). For example, "Joe\,Smith" indicates a + single nine-character user name string with the comma being the + fourth character of that string. + + To promote interoperability and consistent with long-standing + guidance about conservative use of the DNS in naming and applications + (e.g., see Section 2.3.1 of the base DNS document, RFC 1035 [2]), + characters outside the set of alphabetic characters, digits, and + hyphen MUST NOT appear in domain name labels for SMTP clients or + servers. In particular, the underscore character is not permitted. + SMTP servers that receive a command in which invalid character codes + have been employed, and for which there are no other reasons for + rejection, MUST reject that command with a 501 response (this rule, + like others, could be overridden by appropriate SMTP extensions). + +4.1.3. Address Literals + + Sometimes a host is not known to the domain name system and + communication (and, in particular, communication to report and repair + the error) is blocked. To bypass this barrier, a special literal + form of the address is allowed as an alternative to a domain name. + For IPv4 addresses, this form uses four small decimal integers + separated by dots and enclosed by brackets such as [123.255.37.2], + which indicates an (IPv4) Internet Address in sequence-of-octets + form. For IPv6 and other forms of addressing that might eventually + be standardized, the form consists of a standardized "tag" that + identifies the address syntax, a colon, and the address itself, in a + format specified as part of the relevant standards (i.e., RFC 4291 + [8] for IPv6). + + Specifically: + + IPv4-address-literal = Snum 3("." Snum) + + IPv6-address-literal = "IPv6:" IPv6-addr + + General-address-literal = Standardized-tag ":" 1*dcontent + + Standardized-tag = Ldh-str + ; Standardized-tag MUST be specified in a + ; Standards-Track RFC and registered with IANA + + + + +Klensin Standards Track [Page 43] + +RFC 5321 SMTP October 2008 + + + dcontent = %d33-90 / ; Printable US-ASCII + %d94-126 ; excl. "[", "\", "]" + + Snum = 1*3DIGIT + ; representing a decimal integer + ; value in the range 0 through 255 + + IPv6-addr = IPv6-full / IPv6-comp / IPv6v4-full / IPv6v4-comp + + IPv6-hex = 1*4HEXDIG + + IPv6-full = IPv6-hex 7(":" IPv6-hex) + + IPv6-comp = [IPv6-hex *5(":" IPv6-hex)] "::" + [IPv6-hex *5(":" IPv6-hex)] + ; The "::" represents at least 2 16-bit groups of + ; zeros. No more than 6 groups in addition to the + ; "::" may be present. + + IPv6v4-full = IPv6-hex 5(":" IPv6-hex) ":" IPv4-address-literal + + IPv6v4-comp = [IPv6-hex *3(":" IPv6-hex)] "::" + [IPv6-hex *3(":" IPv6-hex) ":"] + IPv4-address-literal + ; The "::" represents at least 2 16-bit groups of + ; zeros. No more than 4 groups in addition to the + ; "::" and IPv4-address-literal may be present. + +4.1.4. Order of Commands + + There are restrictions on the order in which these commands may be + used. + + A session that will contain mail transactions MUST first be + initialized by the use of the EHLO command. An SMTP server SHOULD + accept commands for non-mail transactions (e.g., VRFY or EXPN) + without this initialization. + + An EHLO command MAY be issued by a client later in the session. If + it is issued after the session begins and the EHLO command is + acceptable to the SMTP server, the SMTP server MUST clear all buffers + and reset the state exactly as if a RSET command had been issued. In + other words, the sequence of RSET followed immediately by EHLO is + redundant, but not harmful other than in the performance cost of + executing unnecessary commands. + + If the EHLO command is not acceptable to the SMTP server, 501, 500, + 502, or 550 failure replies MUST be returned as appropriate. The + + + +Klensin Standards Track [Page 44] + +RFC 5321 SMTP October 2008 + + + SMTP server MUST stay in the same state after transmitting these + replies that it was in before the EHLO was received. + + The SMTP client MUST, if possible, ensure that the domain parameter + to the EHLO command is a primary host name as specified for this + command in Section 2.3.5. If this is not possible (e.g., when the + client's address is dynamically assigned and the client does not have + an obvious name), an address literal SHOULD be substituted for the + domain name. + + An SMTP server MAY verify that the domain name argument in the EHLO + command actually corresponds to the IP address of the client. + However, if the verification fails, the server MUST NOT refuse to + accept a message on that basis. Information captured in the + verification attempt is for logging and tracing purposes. Note that + this prohibition applies to the matching of the parameter to its IP + address only; see Section 7.9 for a more extensive discussion of + rejecting incoming connections or mail messages. + + The NOOP, HELP, EXPN, VRFY, and RSET commands can be used at any time + during a session, or without previously initializing a session. SMTP + servers SHOULD process these normally (that is, not return a 503 + code) even if no EHLO command has yet been received; clients SHOULD + open a session with EHLO before sending these commands. + + If these rules are followed, the example in RFC 821 that shows "550 + access denied to you" in response to an EXPN command is incorrect + unless an EHLO command precedes the EXPN or the denial of access is + based on the client's IP address or other authentication or + authorization-determining mechanisms. + + The MAIL command (or the obsolete SEND, SOML, or SAML commands) + begins a mail transaction. Once started, a mail transaction consists + of a transaction beginning command, one or more RCPT commands, and a + DATA command, in that order. A mail transaction may be aborted by + the RSET, a new EHLO, or the QUIT command. There may be zero or more + transactions in a session. MAIL (or SEND, SOML, or SAML) MUST NOT be + sent if a mail transaction is already open, i.e., it should be sent + only if no mail transaction had been started in the session, or if + the previous one successfully concluded with a successful DATA + command, or if the previous one was aborted, e.g., with a RSET or new + EHLO. + + If the transaction beginning command argument is not acceptable, a + 501 failure reply MUST be returned and the SMTP server MUST stay in + the same state. If the commands in a transaction are out of order to + the degree that they cannot be processed by the server, a 503 failure + + + + +Klensin Standards Track [Page 45] + +RFC 5321 SMTP October 2008 + + + reply MUST be returned and the SMTP server MUST stay in the same + state. + + The last command in a session MUST be the QUIT command. The QUIT + command SHOULD be used by the client SMTP to request connection + closure, even when no session opening command was sent and accepted. + +4.1.5. Private-Use Commands + + As specified in Section 2.2.2, commands starting in "X" may be used + by bilateral agreement between the client (sending) and server + (receiving) SMTP agents. An SMTP server that does not recognize such + a command is expected to reply with "500 Command not recognized". An + extended SMTP server MAY list the feature names associated with these + private commands in the response to the EHLO command. + + Commands sent or accepted by SMTP systems that do not start with "X" + MUST conform to the requirements of Section 2.2.2. + +4.2. SMTP Replies + + Replies to SMTP commands serve to ensure the synchronization of + requests and actions in the process of mail transfer and to guarantee + that the SMTP client always knows the state of the SMTP server. + Every command MUST generate exactly one reply. + + The details of the command-reply sequence are described in + Section 4.3. + + An SMTP reply consists of a three digit number (transmitted as three + numeric characters) followed by some text unless specified otherwise + in this document. The number is for use by automata to determine + what state to enter next; the text is for the human user. The three + digits contain enough encoded information that the SMTP client need + not examine the text and may either discard it or pass it on to the + user, as appropriate. Exceptions are as noted elsewhere in this + document. In particular, the 220, 221, 251, 421, and 551 reply codes + are associated with message text that must be parsed and interpreted + by machines. In the general case, the text may be receiver dependent + and context dependent, so there are likely to be varying texts for + each reply code. A discussion of the theory of reply codes is given + in Section 4.2.1. Formally, a reply is defined to be the sequence: a + three-digit code, , one line of text, and , or a multiline + reply (as defined in the same section). Since, in violation of this + specification, the text is sometimes not sent, clients that do not + receive it SHOULD be prepared to process the code alone (with or + without a trailing space character). Only the EHLO, EXPN, and HELP + commands are expected to result in multiline replies in normal + + + +Klensin Standards Track [Page 46] + +RFC 5321 SMTP October 2008 + + + circumstances; however, multiline replies are allowed for any + command. + + In ABNF, server responses are: + + Greeting = ( "220 " (Domain / address-literal) + [ SP textstring ] CRLF ) / + ( "220-" (Domain / address-literal) + [ SP textstring ] CRLF + *( "220-" [ textstring ] CRLF ) + "220" [ SP textstring ] CRLF ) + + textstring = 1*(%d09 / %d32-126) ; HT, SP, Printable US-ASCII + + Reply-line = *( Reply-code "-" [ textstring ] CRLF ) + Reply-code [ SP textstring ] CRLF + + Reply-code = %x32-35 %x30-35 %x30-39 + + where "Greeting" appears only in the 220 response that announces that + the server is opening its part of the connection. (Other possible + server responses upon connection follow the syntax of Reply-line.) + + An SMTP server SHOULD send only the reply codes listed in this + document. An SMTP server SHOULD use the text shown in the examples + whenever appropriate. + + An SMTP client MUST determine its actions only by the reply code, not + by the text (except for the "change of address" 251 and 551 and, if + necessary, 220, 221, and 421 replies); in the general case, any text, + including no text at all (although senders SHOULD NOT send bare + codes), MUST be acceptable. The space (blank) following the reply + code is considered part of the text. Whenever possible, a receiver- + SMTP SHOULD test the first digit (severity indication) of the reply + code. + + The list of codes that appears below MUST NOT be construed as + permanent. While the addition of new codes should be a rare and + significant activity, with supplemental information in the textual + part of the response being preferred, new codes may be added as the + result of new Standards or Standards-Track specifications. + Consequently, a sender-SMTP MUST be prepared to handle codes not + specified in this document and MUST do so by interpreting the first + digit only. + + In the absence of extensions negotiated with the client, SMTP servers + MUST NOT send reply codes whose first digits are other than 2, 3, 4, + + + + +Klensin Standards Track [Page 47] + +RFC 5321 SMTP October 2008 + + + or 5. Clients that receive such out-of-range codes SHOULD normally + treat them as fatal errors and terminate the mail transaction. + +4.2.1. Reply Code Severities and Theory + + The three digits of the reply each have a special significance. The + first digit denotes whether the response is good, bad, or incomplete. + An unsophisticated SMTP client, or one that receives an unexpected + code, will be able to determine its next action (proceed as planned, + redo, retrench, etc.) by examining this first digit. An SMTP client + that wants to know approximately what kind of error occurred (e.g., + mail system error, command syntax error) may examine the second + digit. The third digit and any supplemental information that may be + present is reserved for the finest gradation of information. + + There are four values for the first digit of the reply code: + + 2yz Positive Completion reply + The requested action has been successfully completed. A new + request may be initiated. + + 3yz Positive Intermediate reply + The command has been accepted, but the requested action is being + held in abeyance, pending receipt of further information. The + SMTP client should send another command specifying this + information. This reply is used in command sequence groups (i.e., + in DATA). + + 4yz Transient Negative Completion reply + The command was not accepted, and the requested action did not + occur. However, the error condition is temporary, and the action + may be requested again. The sender should return to the beginning + of the command sequence (if any). It is difficult to assign a + meaning to "transient" when two different sites (receiver- and + sender-SMTP agents) must agree on the interpretation. Each reply + in this category might have a different time value, but the SMTP + client SHOULD try again. A rule of thumb to determine whether a + reply fits into the 4yz or the 5yz category (see below) is that + replies are 4yz if they can be successful if repeated without any + change in command form or in properties of the sender or receiver + (that is, the command is repeated identically and the receiver + does not put up a new implementation). + + 5yz Permanent Negative Completion reply + The command was not accepted and the requested action did not + occur. The SMTP client SHOULD NOT repeat the exact request (in + the same sequence). Even some "permanent" error conditions can be + corrected, so the human user may want to direct the SMTP client to + + + +Klensin Standards Track [Page 48] + +RFC 5321 SMTP October 2008 + + + reinitiate the command sequence by direct action at some point in + the future (e.g., after the spelling has been changed, or the user + has altered the account status). + + It is worth noting that the file transfer protocol (FTP) [34] uses a + very similar code architecture and that the SMTP codes are based on + the FTP model. However, SMTP uses a one-command, one-response model + (while FTP is asynchronous) and FTP's 1yz codes are not part of the + SMTP model. + + The second digit encodes responses in specific categories: + + x0z Syntax: These replies refer to syntax errors, syntactically + correct commands that do not fit any functional category, and + unimplemented or superfluous commands. + + x1z Information: These are replies to requests for information, such + as status or help. + + x2z Connections: These are replies referring to the transmission + channel. + + x3z Unspecified. + + x4z Unspecified. + + x5z Mail system: These replies indicate the status of the receiver + mail system vis-a-vis the requested transfer or other mail system + action. + + The third digit gives a finer gradation of meaning in each category + specified by the second digit. The list of replies illustrates this. + Each reply text is recommended rather than mandatory, and may even + change according to the command with which it is associated. On the + other hand, the reply codes must strictly follow the specifications + in this section. Receiver implementations should not invent new + codes for slightly different situations from the ones described here, + but rather adapt codes already defined. + + For example, a command such as NOOP, whose successful execution does + not offer the SMTP client any new information, will return a 250 + reply. The reply is 502 when the command requests an unimplemented + non-site-specific action. A refinement of that is the 504 reply for + a command that is implemented, but that requests an unimplemented + parameter. + + + + + + +Klensin Standards Track [Page 49] + +RFC 5321 SMTP October 2008 + + + The reply text may be longer than a single line; in these cases the + complete text must be marked so the SMTP client knows when it can + stop reading the reply. This requires a special format to indicate a + multiple line reply. + + The format for multiline replies requires that every line, except the + last, begin with the reply code, followed immediately by a hyphen, + "-" (also known as minus), followed by text. The last line will + begin with the reply code, followed immediately by , optionally + some text, and . As noted above, servers SHOULD send the + if subsequent text is not sent, but clients MUST be prepared for it + to be omitted. + + For example: + + 250-First line + 250-Second line + 250-234 Text beginning with numbers + 250 The last line + + In a multiline reply, the reply code on each of the lines MUST be the + same. It is reasonable for the client to rely on this, so it can + make processing decisions based on the code in any line, assuming + that all others will be the same. In a few cases, there is important + data for the client in the reply "text". The client will be able to + identify these cases from the current context. + +4.2.2. Reply Codes by Function Groups + + 500 Syntax error, command unrecognized (This may include errors such + as command line too long) + + 501 Syntax error in parameters or arguments + + 502 Command not implemented (see Section 4.2.4) + + 503 Bad sequence of commands + + 504 Command parameter not implemented + + + 211 System status, or system help reply + + 214 Help message (Information on how to use the receiver or the + meaning of a particular non-standard command; this reply is useful + only to the human user) + + + + + +Klensin Standards Track [Page 50] + +RFC 5321 SMTP October 2008 + + + 220 Service ready + + 221 Service closing transmission channel + + 421 Service not available, closing transmission channel + (This may be a reply to any command if the service knows it must + shut down) + + + 250 Requested mail action okay, completed + + 251 User not local; will forward to (See Section 3.4) + + 252 Cannot VRFY user, but will accept message and attempt delivery + (See Section 3.5.3) + + 455 Server unable to accommodate parameters + + 555 MAIL FROM/RCPT TO parameters not recognized or not implemented + + 450 Requested mail action not taken: mailbox unavailable (e.g., + mailbox busy or temporarily blocked for policy reasons) + + 550 Requested action not taken: mailbox unavailable (e.g., mailbox + not found, no access, or command rejected for policy reasons) + + 451 Requested action aborted: error in processing + + 551 User not local; please try (See Section 3.4) + + 452 Requested action not taken: insufficient system storage + + 552 Requested mail action aborted: exceeded storage allocation + + 553 Requested action not taken: mailbox name not allowed (e.g., + mailbox syntax incorrect) + + 354 Start mail input; end with . + + 554 Transaction failed (Or, in the case of a connection-opening + response, "No SMTP service here") + + + + + + + + + + +Klensin Standards Track [Page 51] + +RFC 5321 SMTP October 2008 + + +4.2.3. Reply Codes in Numeric Order + + 211 System status, or system help reply + + 214 Help message (Information on how to use the receiver or the + meaning of a particular non-standard command; this reply is useful + only to the human user) + + 220 Service ready + + 221 Service closing transmission channel + + 250 Requested mail action okay, completed + + 251 User not local; will forward to (See Section 3.4) + + 252 Cannot VRFY user, but will accept message and attempt delivery + (See Section 3.5.3) + + 354 Start mail input; end with . + + 421 Service not available, closing transmission channel + (This may be a reply to any command if the service knows it must + shut down) + + 450 Requested mail action not taken: mailbox unavailable (e.g., + mailbox busy or temporarily blocked for policy reasons) + + 451 Requested action aborted: local error in processing + + 452 Requested action not taken: insufficient system storage + + 455 Server unable to accommodate parameters + + 500 Syntax error, command unrecognized (This may include errors such + as command line too long) + + 501 Syntax error in parameters or arguments + + 502 Command not implemented (see Section 4.2.4) + + 503 Bad sequence of commands + + 504 Command parameter not implemented + + 550 Requested action not taken: mailbox unavailable (e.g., mailbox + not found, no access, or command rejected for policy reasons) + + + + +Klensin Standards Track [Page 52] + +RFC 5321 SMTP October 2008 + + + 551 User not local; please try (See Section 3.4) + + 552 Requested mail action aborted: exceeded storage allocation + + 553 Requested action not taken: mailbox name not allowed (e.g., + mailbox syntax incorrect) + + 554 Transaction failed (Or, in the case of a connection-opening + response, "No SMTP service here") + + 555 MAIL FROM/RCPT TO parameters not recognized or not implemented + +4.2.4. Reply Code 502 + + Questions have been raised as to when reply code 502 (Command not + implemented) SHOULD be returned in preference to other codes. 502 + SHOULD be used when the command is actually recognized by the SMTP + server, but not implemented. If the command is not recognized, code + 500 SHOULD be returned. Extended SMTP systems MUST NOT list + capabilities in response to EHLO for which they will return 502 (or + 500) replies. + +4.2.5. Reply Codes after DATA and the Subsequent . + + When an SMTP server returns a positive completion status (2yz code) + after the DATA command is completed with ., it accepts + responsibility for: + + o delivering the message (if the recipient mailbox exists), or + + o if attempts to deliver the message fail due to transient + conditions, retrying delivery some reasonable number of times at + intervals as specified in Section 4.5.4. + + o if attempts to deliver the message fail due to permanent + conditions, or if repeated attempts to deliver the message fail + due to transient conditions, returning appropriate notification to + the sender of the original message (using the address in the SMTP + MAIL command). + + When an SMTP server returns a temporary error status (4yz) code after + the DATA command is completed with ., it MUST NOT make a + subsequent attempt to deliver that message. The SMTP client retains + responsibility for the delivery of that message and may either return + it to the user or requeue it for a subsequent attempt (see + Section 4.5.4.1). + + + + + +Klensin Standards Track [Page 53] + +RFC 5321 SMTP October 2008 + + + The user who originated the message SHOULD be able to interpret the + return of a transient failure status (by mail message or otherwise) + as a non-delivery indication, just as a permanent failure would be + interpreted. If the client SMTP successfully handles these + conditions, the user will not receive such a reply. + + When an SMTP server returns a permanent error status (5yz) code after + the DATA command is completed with ., it MUST NOT make + any subsequent attempt to deliver the message. As with temporary + error status codes, the SMTP client retains responsibility for the + message, but SHOULD not again attempt delivery to the same server + without user review of the message and response and appropriate + intervention. + +4.3. Sequencing of Commands and Replies + +4.3.1. Sequencing Overview + + The communication between the sender and receiver is an alternating + dialogue, controlled by the sender. As such, the sender issues a + command and the receiver responds with a reply. Unless other + arrangements are negotiated through service extensions, the sender + MUST wait for this response before sending further commands. One + important reply is the connection greeting. Normally, a receiver + will send a 220 "Service ready" reply when the connection is + completed. The sender SHOULD wait for this greeting message before + sending any commands. + + Note: all the greeting-type replies have the official name (the + fully-qualified primary domain name) of the server host as the first + word following the reply code. Sometimes the host will have no + meaningful name. See Section 4.1.3 for a discussion of alternatives + in these situations. + + For example, + + 220 ISIF.USC.EDU Service ready + + or + + 220 mail.example.com SuperSMTP v 6.1.2 Service ready + + or + + 220 [10.0.0.1] Clueless host service ready + + The table below lists alternative success and failure replies for + each command. These SHOULD be strictly adhered to. A receiver MAY + + + +Klensin Standards Track [Page 54] + +RFC 5321 SMTP October 2008 + + + substitute text in the replies, but the meanings and actions implied + by the code numbers and by the specific command reply sequence MUST + be preserved. + +4.3.2. Command-Reply Sequences + + Each command is listed with its usual possible replies. The prefixes + used before the possible replies are "I" for intermediate, "S" for + success, and "E" for error. Since some servers may generate other + replies under special circumstances, and to allow for future + extension, SMTP clients SHOULD, when possible, interpret only the + first digit of the reply and MUST be prepared to deal with + unrecognized reply codes by interpreting the first digit only. + Unless extended using the mechanisms described in Section 2.2, SMTP + servers MUST NOT transmit reply codes to an SMTP client that are + other than three digits or that do not start in a digit between 2 and + 5 inclusive. + + These sequencing rules and, in principle, the codes themselves, can + be extended or modified by SMTP extensions offered by the server and + accepted (requested) by the client. However, if the target is more + precise granularity in the codes, rather than codes for completely + new purposes, the system described in RFC 3463 [25] SHOULD be used in + preference to the invention of new codes. + + In addition to the codes listed below, any SMTP command can return + any of the following codes if the corresponding unusual circumstances + are encountered: + + 500 For the "command line too long" case or if the command name was + not recognized. Note that producing a "command not recognized" + error in response to the required subset of these commands is a + violation of this specification. Similarly, producing a "command + too long" message for a command line shorter than 512 characters + would violate the provisions of Section 4.5.3.1.4. + + 501 Syntax error in command or arguments. In order to provide for + future extensions, commands that are specified in this document as + not accepting arguments (DATA, RSET, QUIT) SHOULD return a 501 + message if arguments are supplied in the absence of EHLO- + advertised extensions. + + 421 Service shutting down and closing transmission channel + + + + + + + + +Klensin Standards Track [Page 55] + +RFC 5321 SMTP October 2008 + + + Specific sequences are: + + CONNECTION ESTABLISHMENT + + S: 220 + E: 554 + + EHLO or HELO + + S: 250 + E: 504 (a conforming implementation could return this code only + in fairly obscure cases), 550, 502 (permitted only with an old- + style server that does not support EHLO) + + MAIL + + S: 250 + E: 552, 451, 452, 550, 553, 503, 455, 555 + + RCPT + + S: 250, 251 (but see Section 3.4 for discussion of 251 and 551) + E: 550, 551, 552, 553, 450, 451, 452, 503, 455, 555 + + DATA + + I: 354 -> data -> S: 250 + + E: 552, 554, 451, 452 + + E: 450, 550 (rejections for policy reasons) + + E: 503, 554 + + RSET + + S: 250 + + VRFY + + S: 250, 251, 252 + E: 550, 551, 553, 502, 504 + + EXPN + + S: 250, 252 + E: 550, 500, 502, 504 + + + + +Klensin Standards Track [Page 56] + +RFC 5321 SMTP October 2008 + + + HELP + + S: 211, 214 + E: 502, 504 + + NOOP + + S: 250 + + QUIT + + S: 221 + +4.4. Trace Information + + When an SMTP server receives a message for delivery or further + processing, it MUST insert trace ("time stamp" or "Received") + information at the beginning of the message content, as discussed in + Section 4.1.1.4. + + This line MUST be structured as follows: + + o The FROM clause, which MUST be supplied in an SMTP environment, + SHOULD contain both (1) the name of the source host as presented + in the EHLO command and (2) an address literal containing the IP + address of the source, determined from the TCP connection. + + o The ID clause MAY contain an "@" as suggested in RFC 822, but this + is not required. + + o If the FOR clause appears, it MUST contain exactly one + entry, even when multiple RCPT commands have been given. Multiple + s raise some security issues and have been deprecated, see + Section 7.2. + + An Internet mail program MUST NOT change or delete a Received: line + that was previously added to the message header section. SMTP + servers MUST prepend Received lines to messages; they MUST NOT change + the order of existing lines or insert Received lines in any other + location. + + As the Internet grows, comparability of Received header fields is + important for detecting problems, especially slow relays. SMTP + servers that create Received header fields SHOULD use explicit + offsets in the dates (e.g., -0800), rather than time zone names of + any type. Local time (with an offset) SHOULD be used rather than UT + when feasible. This formulation allows slightly more information + about local circumstances to be specified. If UT is needed, the + + + +Klensin Standards Track [Page 57] + +RFC 5321 SMTP October 2008 + + + receiver need merely do some simple arithmetic to convert the values. + Use of UT loses information about the time zone-location of the + server. If it is desired to supply a time zone name, it SHOULD be + included in a comment. + + When the delivery SMTP server makes the "final delivery" of a + message, it inserts a return-path line at the beginning of the mail + data. This use of return-path is required; mail systems MUST support + it. The return-path line preserves the information in the from the MAIL command. Here, final delivery means the message + has left the SMTP environment. Normally, this would mean it had been + delivered to the destination user or an associated mail drop, but in + some cases it may be further processed and transmitted by another + mail system. + + It is possible for the mailbox in the return path to be different + from the actual sender's mailbox, for example, if error responses are + to be delivered to a special error handling mailbox rather than to + the message sender. When mailing lists are involved, this + arrangement is common and useful as a means of directing errors to + the list maintainer rather than the message originator. + + The text above implies that the final mail data will begin with a + return path line, followed by one or more time stamp lines. These + lines will be followed by the rest of the mail data: first the + balance of the mail header section and then the body (RFC 5322 [4]). + + It is sometimes difficult for an SMTP server to determine whether or + not it is making final delivery since forwarding or other operations + may occur after the message is accepted for delivery. Consequently, + any further (forwarding, gateway, or relay) systems MAY remove the + return path and rebuild the MAIL command as needed to ensure that + exactly one such line appears in a delivered message. + + A message-originating SMTP system SHOULD NOT send a message that + already contains a Return-path header field. SMTP servers performing + a relay function MUST NOT inspect the message data, and especially + not to the extent needed to determine if Return-path header fields + are present. SMTP servers making final delivery MAY remove Return- + path header fields before adding their own. + + The primary purpose of the Return-path is to designate the address to + which messages indicating non-delivery or other mail system failures + are to be sent. For this to be unambiguous, exactly one return path + SHOULD be present when the message is delivered. Systems using RFC + 822 syntax with non-SMTP transports SHOULD designate an unambiguous + address, associated with the transport envelope, to which error + reports (e.g., non-delivery messages) should be sent. + + + +Klensin Standards Track [Page 58] + +RFC 5321 SMTP October 2008 + + + Historical note: Text in RFC 822 that appears to contradict the use + of the Return-path header field (or the envelope reverse-path address + from the MAIL command) as the destination for error messages is not + applicable on the Internet. The reverse-path address (as copied into + the Return-path) MUST be used as the target of any mail containing + delivery error messages. + + In particular: + o a gateway from SMTP -> elsewhere SHOULD insert a return-path + header field, unless it is known that the "elsewhere" transport + also uses Internet domain addresses and maintains the envelope + sender address separately. + + o a gateway from elsewhere -> SMTP SHOULD delete any return-path + header field present in the message, and either copy that + information to the SMTP envelope or combine it with information + present in the envelope of the other transport system to construct + the reverse-path argument to the MAIL command in the SMTP + envelope. + + The server must give special treatment to cases in which the + processing following the end of mail data indication is only + partially successful. This could happen if, after accepting several + recipients and the mail data, the SMTP server finds that the mail + data could be successfully delivered to some, but not all, of the + recipients. In such cases, the response to the DATA command MUST be + an OK reply. However, the SMTP server MUST compose and send an + "undeliverable mail" notification message to the originator of the + message. + + A single notification listing all of the failed recipients or + separate notification messages MUST be sent for each failed + recipient. For economy of processing by the sender, the former + SHOULD be used when possible. Note that the key difference between + handling aliases (Section 3.9.1) and forwarding (this subsection) is + the change to the backward-pointing address in this case. All + notification messages about undeliverable mail MUST be sent using the + MAIL command (even if they result from processing the obsolete SEND, + SOML, or SAML commands) and MUST use a null return path as discussed + in Section 3.6. + + The time stamp line and the return path line are formally defined as + follows (the definitions for "FWS" and "CFWS" appear in RFC 5322 + [4]): + + Return-path-line = "Return-Path:" FWS Reverse-path + + Time-stamp-line = "Received:" FWS Stamp + + + +Klensin Standards Track [Page 59] + +RFC 5321 SMTP October 2008 + + + Stamp = From-domain By-domain Opt-info [CFWS] ";" + FWS date-time + ; where "date-time" is as defined in RFC 5322 [4] + ; but the "obs-" forms, especially two-digit + ; years, are prohibited in SMTP and MUST NOT be used. + + From-domain = "FROM" FWS Extended-Domain + + By-domain = CFWS "BY" FWS Extended-Domain + + Extended-Domain = Domain / + ( Domain FWS "(" TCP-info ")" ) / + ( address-literal FWS "(" TCP-info ")" ) + + TCP-info = address-literal / ( Domain FWS address-literal ) + ; Information derived by server from TCP connection + ; not client EHLO. + + Opt-info = [Via] [With] [ID] [For] + [Additional-Registered-Clauses] + + Via = CFWS "VIA" FWS Link + + With = CFWS "WITH" FWS Protocol + + ID = CFWS "ID" FWS ( Atom / msg-id ) + ; msg-id is defined in RFC 5322 [4] + + For = CFWS "FOR" FWS ( Path / Mailbox ) + + Additional-Registered-Clauses = CFWS Atom FWS String + ; Additional standard clauses may be + added in this + ; location by future standards and + registration with + ; IANA. SMTP servers SHOULD NOT use + unregistered + ; names. See Section 8. + + Link = "TCP" / Addtl-Link + + Addtl-Link = Atom + ; Additional standard names for links are + ; registered with the Internet Assigned Numbers + ; Authority (IANA). "Via" is primarily of value + ; with non-Internet transports. SMTP servers + ; SHOULD NOT use unregistered names. + + + + +Klensin Standards Track [Page 60] + +RFC 5321 SMTP October 2008 + + + Protocol = "ESMTP" / "SMTP" / Attdl-Protocol + + Attdl-Protocol = Atom + ; Additional standard names for protocols are + ; registered with the Internet Assigned Numbers + ; Authority (IANA) in the "mail parameters" + ; registry [9]. SMTP servers SHOULD NOT + ; use unregistered names. + +4.5. Additional Implementation Issues + +4.5.1. Minimum Implementation + + In order to make SMTP workable, the following minimum implementation + MUST be provided by all receivers. The following commands MUST be + supported to conform to this specification: + + EHLO + HELO + MAIL + RCPT + DATA + RSET + NOOP + QUIT + VRFY + + Any system that includes an SMTP server supporting mail relaying or + delivery MUST support the reserved mailbox "postmaster" as a case- + insensitive local name. This postmaster address is not strictly + necessary if the server always returns 554 on connection opening (as + described in Section 3.1). The requirement to accept mail for + postmaster implies that RCPT commands that specify a mailbox for + postmaster at any of the domains for which the SMTP server provides + mail service, as well as the special case of "RCPT TO:" + (with no domain specification), MUST be supported. + + SMTP systems are expected to make every reasonable effort to accept + mail directed to Postmaster from any other system on the Internet. + In extreme cases -- such as to contain a denial of service attack or + other breach of security -- an SMTP server may block mail directed to + Postmaster. However, such arrangements SHOULD be narrowly tailored + so as to avoid blocking messages that are not part of such attacks. + + + + + + + + +Klensin Standards Track [Page 61] + +RFC 5321 SMTP October 2008 + + +4.5.2. Transparency + + Without some provision for data transparency, the character sequence + "." ends the mail text and cannot be sent by the user. + In general, users are not aware of such "forbidden" sequences. To + allow all user composed text to be transmitted transparently, the + following procedures are used: + + o Before sending a line of mail text, the SMTP client checks the + first character of the line. If it is a period, one additional + period is inserted at the beginning of the line. + + o When a line of mail text is received by the SMTP server, it checks + the line. If the line is composed of a single period, it is + treated as the end of mail indicator. If the first character is a + period and there are other characters on the line, the first + character is deleted. + + The mail data may contain any of the 128 ASCII characters. All + characters are to be delivered to the recipient's mailbox, including + spaces, vertical and horizontal tabs, and other control characters. + If the transmission channel provides an 8-bit byte (octet) data + stream, the 7-bit ASCII codes are transmitted, right justified, in + the octets, with the high-order bits cleared to zero. See + Section 3.6 for special treatment of these conditions in SMTP systems + serving a relay function. + + In some systems, it may be necessary to transform the data as it is + received and stored. This may be necessary for hosts that use a + different character set than ASCII as their local character set, that + store data in records rather than strings, or which use special + character sequences as delimiters inside mailboxes. If such + transformations are necessary, they MUST be reversible, especially if + they are applied to mail being relayed. + +4.5.3. Sizes and Timeouts + +4.5.3.1. Size Limits and Minimums + + There are several objects that have required minimum/maximum sizes. + Every implementation MUST be able to receive objects of at least + these sizes. Objects larger than these sizes SHOULD be avoided when + possible. However, some Internet mail constructs such as encoded + X.400 addresses (RFC 2156 [35]) will often require larger objects. + Clients MAY attempt to transmit these, but MUST be prepared for a + server to reject them if they cannot be handled by it. To the + maximum extent possible, implementation techniques that impose no + limits on the length of these objects should be used. + + + +Klensin Standards Track [Page 62] + +RFC 5321 SMTP October 2008 + + + Extensions to SMTP may involve the use of characters that occupy more + than a single octet each. This section therefore specifies lengths + in octets where absolute lengths, rather than character counts, are + intended. + +4.5.3.1.1. Local-part + + The maximum total length of a user name or other local-part is 64 + octets. + +4.5.3.1.2. Domain + + The maximum total length of a domain name or number is 255 octets. + +4.5.3.1.3. Path + + The maximum total length of a reverse-path or forward-path is 256 + octets (including the punctuation and element separators). + +4.5.3.1.4. Command Line + + The maximum total length of a command line including the command word + and the is 512 octets. SMTP extensions may be used to + increase this limit. + +4.5.3.1.5. Reply Line + + The maximum total length of a reply line including the reply code and + the is 512 octets. More information may be conveyed through + multiple-line replies. + +4.5.3.1.6. Text Line + + The maximum total length of a text line including the is 1000 + octets (not counting the leading dot duplicated for transparency). + This number may be increased by the use of SMTP Service Extensions. + +4.5.3.1.7. Message Content + + The maximum total length of a message content (including any message + header section as well as the message body) MUST BE at least 64K + octets. Since the introduction of Internet Standards for multimedia + mail (RFC 2045 [21]), message lengths on the Internet have grown + dramatically, and message size restrictions should be avoided if at + all possible. SMTP server systems that must impose restrictions + SHOULD implement the "SIZE" service extension of RFC 1870 [10], and + SMTP client systems that will send large messages SHOULD utilize it + when possible. + + + +Klensin Standards Track [Page 63] + +RFC 5321 SMTP October 2008 + + +4.5.3.1.8. Recipients Buffer + + The minimum total number of recipients that MUST be buffered is 100 + recipients. Rejection of messages (for excessive recipients) with + fewer than 100 RCPT commands is a violation of this specification. + The general principle that relaying SMTP server MUST NOT, and + delivery SMTP servers SHOULD NOT, perform validation tests on message + header fields suggests that messages SHOULD NOT be rejected based on + the total number of recipients shown in header fields. A server that + imposes a limit on the number of recipients MUST behave in an orderly + fashion, such as rejecting additional addresses over its limit rather + than silently discarding addresses previously accepted. A client + that needs to deliver a message containing over 100 RCPT commands + SHOULD be prepared to transmit in 100-recipient "chunks" if the + server declines to accept more than 100 recipients in a single + message. + +4.5.3.1.9. Treatment When Limits Exceeded + + Errors due to exceeding these limits may be reported by using the + reply codes. Some examples of reply codes are: + + 500 Line too long. + + or + + 501 Path too long + + or + + 452 Too many recipients (see below) + + or + + 552 Too much mail data. + +4.5.3.1.10. Too Many Recipients Code + + RFC 821 [1] incorrectly listed the error where an SMTP server + exhausts its implementation limit on the number of RCPT commands + ("too many recipients") as having reply code 552. The correct reply + code for this condition is 452. Clients SHOULD treat a 552 code in + this case as a temporary, rather than permanent, failure so the logic + below works. + + When a conforming SMTP server encounters this condition, it has at + least 100 successful RCPT commands in its recipients buffer. If the + server is able to accept the message, then at least these 100 + + + +Klensin Standards Track [Page 64] + +RFC 5321 SMTP October 2008 + + + addresses will be removed from the SMTP client's queue. When the + client attempts retransmission of those addresses that received 452 + responses, at least 100 of these will be able to fit in the SMTP + server's recipients buffer. Each retransmission attempt that is able + to deliver anything will be able to dispose of at least 100 of these + recipients. + + If an SMTP server has an implementation limit on the number of RCPT + commands and this limit is exhausted, it MUST use a response code of + 452 (but the client SHOULD also be prepared for a 552, as noted + above). If the server has a configured site-policy limitation on the + number of RCPT commands, it MAY instead use a 5yz response code. In + particular, if the intent is to prohibit messages with more than a + site-specified number of recipients, rather than merely limit the + number of recipients in a given mail transaction, it would be + reasonable to return a 503 response to any DATA command received + subsequent to the 452 (or 552) code or to simply return the 503 after + DATA without returning any previous negative response. + +4.5.3.2. Timeouts + + An SMTP client MUST provide a timeout mechanism. It MUST use per- + command timeouts rather than somehow trying to time the entire mail + transaction. Timeouts SHOULD be easily reconfigurable, preferably + without recompiling the SMTP code. To implement this, a timer is set + for each SMTP command and for each buffer of the data transfer. The + latter means that the overall timeout is inherently proportional to + the size of the message. + + Based on extensive experience with busy mail-relay hosts, the minimum + per-command timeout values SHOULD be as follows: + +4.5.3.2.1. Initial 220 Message: 5 Minutes + + An SMTP client process needs to distinguish between a failed TCP + connection and a delay in receiving the initial 220 greeting message. + Many SMTP servers accept a TCP connection but delay delivery of the + 220 message until their system load permits more mail to be + processed. + +4.5.3.2.2. MAIL Command: 5 Minutes + +4.5.3.2.3. RCPT Command: 5 Minutes + + A longer timeout is required if processing of mailing lists and + aliases is not deferred until after the message was accepted. + + + + + +Klensin Standards Track [Page 65] + +RFC 5321 SMTP October 2008 + + +4.5.3.2.4. DATA Initiation: 2 Minutes + + This is while awaiting the "354 Start Input" reply to a DATA command. + +4.5.3.2.5. Data Block: 3 Minutes + + This is while awaiting the completion of each TCP SEND call + transmitting a chunk of data. + +4.5.3.2.6. DATA Termination: 10 Minutes. + + This is while awaiting the "250 OK" reply. When the receiver gets + the final period terminating the message data, it typically performs + processing to deliver the message to a user mailbox. A spurious + timeout at this point would be very wasteful and would typically + result in delivery of multiple copies of the message, since it has + been successfully sent and the server has accepted responsibility for + delivery. See Section 6.1 for additional discussion. + +4.5.3.2.7. Server Timeout: 5 Minutes. + + An SMTP server SHOULD have a timeout of at least 5 minutes while it + is awaiting the next command from the sender. + +4.5.4. Retry Strategies + + The common structure of a host SMTP implementation includes user + mailboxes, one or more areas for queuing messages in transit, and one + or more daemon processes for sending and receiving mail. The exact + structure will vary depending on the needs of the users on the host + and the number and size of mailing lists supported by the host. We + describe several optimizations that have proved helpful, particularly + for mailers supporting high traffic levels. + + Any queuing strategy MUST include timeouts on all activities on a + per-command basis. A queuing strategy MUST NOT send error messages + in response to error messages under any circumstances. + +4.5.4.1. Sending Strategy + + The general model for an SMTP client is one or more processes that + periodically attempt to transmit outgoing mail. In a typical system, + the program that composes a message has some method for requesting + immediate attention for a new piece of outgoing mail, while mail that + cannot be transmitted immediately MUST be queued and periodically + retried by the sender. A mail queue entry will include not only the + message itself but also the envelope information. + + + + +Klensin Standards Track [Page 66] + +RFC 5321 SMTP October 2008 + + + The sender MUST delay retrying a particular destination after one + attempt has failed. In general, the retry interval SHOULD be at + least 30 minutes; however, more sophisticated and variable strategies + will be beneficial when the SMTP client can determine the reason for + non-delivery. + + Retries continue until the message is transmitted or the sender gives + up; the give-up time generally needs to be at least 4-5 days. It MAY + be appropriate to set a shorter maximum number of retries for non- + delivery notifications and equivalent error messages than for + standard messages. The parameters to the retry algorithm MUST be + configurable. + + A client SHOULD keep a list of hosts it cannot reach and + corresponding connection timeouts, rather than just retrying queued + mail items. + + Experience suggests that failures are typically transient (the target + system or its connection has crashed), favoring a policy of two + connection attempts in the first hour the message is in the queue, + and then backing off to one every two or three hours. + + The SMTP client can shorten the queuing delay in cooperation with the + SMTP server. For example, if mail is received from a particular + address, it is likely that mail queued for that host can now be sent. + Application of this principle may, in many cases, eliminate the + requirement for an explicit "send queues now" function such as ETRN, + RFC 1985 [36]. + + The strategy may be further modified as a result of multiple + addresses per host (see below) to optimize delivery time versus + resource usage. + + An SMTP client may have a large queue of messages for each + unavailable destination host. If all of these messages were retried + in every retry cycle, there would be excessive Internet overhead and + the sending system would be blocked for a long period. Note that an + SMTP client can generally determine that a delivery attempt has + failed only after a timeout of several minutes, and even a one-minute + timeout per connection will result in a very large delay if retries + are repeated for dozens, or even hundreds, of queued messages to the + same host. + + At the same time, SMTP clients SHOULD use great care in caching + negative responses from servers. In an extreme case, if EHLO is + issued multiple times during the same SMTP connection, different + answers may be returned by the server. More significantly, 5yz + responses to the MAIL command MUST NOT be cached. + + + +Klensin Standards Track [Page 67] + +RFC 5321 SMTP October 2008 + + + When a mail message is to be delivered to multiple recipients, and + the SMTP server to which a copy of the message is to be sent is the + same for multiple recipients, then only one copy of the message + SHOULD be transmitted. That is, the SMTP client SHOULD use the + command sequence: MAIL, RCPT, RCPT, ..., RCPT, DATA instead of the + sequence: MAIL, RCPT, DATA, ..., MAIL, RCPT, DATA. However, if there + are very many addresses, a limit on the number of RCPT commands per + MAIL command MAY be imposed. This efficiency feature SHOULD be + implemented. + + Similarly, to achieve timely delivery, the SMTP client MAY support + multiple concurrent outgoing mail transactions. However, some limit + may be appropriate to protect the host from devoting all its + resources to mail. + +4.5.4.2. Receiving Strategy + + The SMTP server SHOULD attempt to keep a pending listen on the SMTP + port (specified by IANA as port 25) at all times. This requires the + support of multiple incoming TCP connections for SMTP. Some limit + MAY be imposed, but servers that cannot handle more than one SMTP + transaction at a time are not in conformance with the intent of this + specification. + + As discussed above, when the SMTP server receives mail from a + particular host address, it could activate its own SMTP queuing + mechanisms to retry any mail pending for that host address. + +4.5.5. Messages with a Null Reverse-Path + + There are several types of notification messages that are required by + existing and proposed Standards to be sent with a null reverse-path, + namely non-delivery notifications as discussed in Section 3.7, other + kinds of Delivery Status Notifications (DSNs, RFC 3461 [32]), and + Message Disposition Notifications (MDNs, RFC 3798 [37]). All of + these kinds of messages are notifications about a previous message, + and they are sent to the reverse-path of the previous mail message. + (If the delivery of such a notification message fails, that usually + indicates a problem with the mail system of the host to which the + notification message is addressed. For this reason, at some hosts + the MTA is set up to forward such failed notification messages to + someone who is able to fix problems with the mail system, e.g., via + the postmaster alias.) + + All other types of messages (i.e., any message which is not required + by a Standards-Track RFC to have a null reverse-path) SHOULD be sent + with a valid, non-null reverse-path. + + + + +Klensin Standards Track [Page 68] + +RFC 5321 SMTP October 2008 + + + Implementers of automated email processors should be careful to make + sure that the various kinds of messages with a null reverse-path are + handled correctly. In particular, such systems SHOULD NOT reply to + messages with a null reverse-path, and they SHOULD NOT add a non-null + reverse-path, or change a null reverse-path to a non-null one, to + such messages when forwarding. + +5. Address Resolution and Mail Handling + +5.1. Locating the Target Host + + Once an SMTP client lexically identifies a domain to which mail will + be delivered for processing (as described in Sections 2.3.5 and 3.6), + a DNS lookup MUST be performed to resolve the domain name (RFC 1035 + [2]). The names are expected to be fully-qualified domain names + (FQDNs): mechanisms for inferring FQDNs from partial names or local + aliases are outside of this specification. Due to a history of + problems, SMTP servers used for initial submission of messages SHOULD + NOT make such inferences (Message Submission Servers [18] have + somewhat more flexibility) and intermediate (relay) SMTP servers MUST + NOT make them. + + The lookup first attempts to locate an MX record associated with the + name. If a CNAME record is found, the resulting name is processed as + if it were the initial name. If a non-existent domain error is + returned, this situation MUST be reported as an error. If a + temporary error is returned, the message MUST be queued and retried + later (see Section 4.5.4.1). If an empty list of MXs is returned, + the address is treated as if it was associated with an implicit MX + RR, with a preference of 0, pointing to that host. If MX records are + present, but none of them are usable, or the implicit MX is unusable, + this situation MUST be reported as an error. + + If one or more MX RRs are found for a given name, SMTP systems MUST + NOT utilize any address RRs associated with that name unless they are + located using the MX RRs; the "implicit MX" rule above applies only + if there are no MX records present. If MX records are present, but + none of them are usable, this situation MUST be reported as an error. + + When a domain name associated with an MX RR is looked up and the + associated data field obtained, the data field of that response MUST + contain a domain name. That domain name, when queried, MUST return + at least one address record (e.g., A or AAAA RR) that gives the IP + address of the SMTP server to which the message should be directed. + Any other response, specifically including a value that will return a + CNAME record when queried, lies outside the scope of this Standard. + The prohibition on labels in the data that resolve to CNAMEs is + discussed in more detail in RFC 2181, Section 10.3 [38]. + + + +Klensin Standards Track [Page 69] + +RFC 5321 SMTP October 2008 + + + When the lookup succeeds, the mapping can result in a list of + alternative delivery addresses rather than a single address, because + of multiple MX records, multihoming, or both. To provide reliable + mail transmission, the SMTP client MUST be able to try (and retry) + each of the relevant addresses in this list in order, until a + delivery attempt succeeds. However, there MAY also be a configurable + limit on the number of alternate addresses that can be tried. In any + case, the SMTP client SHOULD try at least two addresses. + + Two types of information are used to rank the host addresses: + multiple MX records, and multihomed hosts. + + MX records contain a preference indication that MUST be used in + sorting if more than one such record appears (see below). Lower + numbers are more preferred than higher ones. If there are multiple + destinations with the same preference and there is no clear reason to + favor one (e.g., by recognition of an easily reached address), then + the sender-SMTP MUST randomize them to spread the load across + multiple mail exchangers for a specific organization. + + The destination host (perhaps taken from the preferred MX record) may + be multihomed, in which case the domain name resolver will return a + list of alternative IP addresses. It is the responsibility of the + domain name resolver interface to have ordered this list by + decreasing preference if necessary, and the SMTP sender MUST try them + in the order presented. + + Although the capability to try multiple alternative addresses is + required, specific installations may want to limit or disable the use + of alternative addresses. The question of whether a sender should + attempt retries using the different addresses of a multihomed host + has been controversial. The main argument for using the multiple + addresses is that it maximizes the probability of timely delivery, + and indeed sometimes the probability of any delivery; the counter- + argument is that it may result in unnecessary resource use. Note + that resource use is also strongly determined by the sending strategy + discussed in Section 4.5.4.1. + + If an SMTP server receives a message with a destination for which it + is a designated Mail eXchanger, it MAY relay the message (potentially + after having rewritten the MAIL FROM and/or RCPT TO addresses), make + final delivery of the message, or hand it off using some mechanism + outside the SMTP-provided transport environment. Of course, neither + of the latter require that the list of MX records be examined + further. + + If it determines that it should relay the message without rewriting + the address, it MUST sort the MX records to determine candidates for + + + +Klensin Standards Track [Page 70] + +RFC 5321 SMTP October 2008 + + + delivery. The records are first ordered by preference, with the + lowest-numbered records being most preferred. The relay host MUST + then inspect the list for any of the names or addresses by which it + might be known in mail transactions. If a matching record is found, + all records at that preference level and higher-numbered ones MUST be + discarded from consideration. If there are no records left at that + point, it is an error condition, and the message MUST be returned as + undeliverable. If records do remain, they SHOULD be tried, best + preference first, as described above. + +5.2. IPv6 and MX Records + + In the contemporary Internet, SMTP clients and servers may be hosted + on IPv4 systems, IPv6 systems, or dual-stack systems that are + compatible with either version of the Internet Protocol. The host + domains to which MX records point may, consequently, contain "A RR"s + (IPv4), "AAAA RR"s (IPv6), or any combination of them. While RFC + 3974 [39] discusses some operational experience in mixed + environments, it was not comprehensive enough to justify + standardization, and some of its recommendations appear to be + inconsistent with this specification. The appropriate actions to be + taken either will depend on local circumstances, such as performance + of the relevant networks and any conversions that might be necessary, + or will be obvious (e.g., an IPv6-only client need not attempt to + look up A RRs or attempt to reach IPv4-only servers). Designers of + SMTP implementations that might run in IPv6 or dual-stack + environments should study the procedures above, especially the + comments about multihomed hosts, and, preferably, provide mechanisms + to facilitate operational tuning and mail interoperability between + IPv4 and IPv6 systems while considering local circumstances. + +6. Problem Detection and Handling + +6.1. Reliable Delivery and Replies by Email + + When the receiver-SMTP accepts a piece of mail (by sending a "250 OK" + message in response to DATA), it is accepting responsibility for + delivering or relaying the message. It must take this responsibility + seriously. It MUST NOT lose the message for frivolous reasons, such + as because the host later crashes or because of a predictable + resource shortage. Some reasons that are not considered frivolous + are discussed in the next subsection and in Section 7.8. + + If there is a delivery failure after acceptance of a message, the + receiver-SMTP MUST formulate and mail a notification message. This + notification MUST be sent using a null ("<>") reverse-path in the + envelope. The recipient of this notification MUST be the address + from the envelope return path (or the Return-Path: line). However, + + + +Klensin Standards Track [Page 71] + +RFC 5321 SMTP October 2008 + + + if this address is null ("<>"), the receiver-SMTP MUST NOT send a + notification. Obviously, nothing in this section can or should + prohibit local decisions (i.e., as part of the same system + environment as the receiver-SMTP) to log or otherwise transmit + information about null address events locally if that is desired. If + the address is an explicit source route, it MUST be stripped down to + its final hop. + + For example, suppose that an error notification must be sent for a + message that arrived with: + + MAIL FROM:<@a,@b:user@d> + + The notification message MUST be sent using: + + RCPT TO: + + Some delivery failures after the message is accepted by SMTP will be + unavoidable. For example, it may be impossible for the receiving + SMTP server to validate all the delivery addresses in RCPT command(s) + due to a "soft" domain system error, because the target is a mailing + list (see earlier discussion of RCPT), or because the server is + acting as a relay and has no immediate access to the delivering + system. + + To avoid receiving duplicate messages as the result of timeouts, a + receiver-SMTP MUST seek to minimize the time required to respond to + the final . end of data indicator. See RFC 1047 [40] for + a discussion of this problem. + +6.2. Unwanted, Unsolicited, and "Attack" Messages + + Utility and predictability of the Internet mail system requires that + messages that can be delivered should be delivered, regardless of any + syntax or other faults associated with those messages and regardless + of their content. If they cannot be delivered, and cannot be + rejected by the SMTP server during the SMTP transaction, they should + be "bounced" (returned with non-delivery notification messages) as + described above. In today's world, in which many SMTP server + operators have discovered that the quantity of undesirable bulk email + vastly exceeds the quantity of desired mail and in which accepting a + message may trigger additional undesirable traffic by providing + verification of the address, those principles may not be practical. + + As discussed in Section 7.8 and Section 7.9 below, dropping mail + without notification of the sender is permitted in practice. + However, it is extremely dangerous and violates a long tradition and + community expectations that mail is either delivered or returned. If + + + +Klensin Standards Track [Page 72] + +RFC 5321 SMTP October 2008 + + + silent message-dropping is misused, it could easily undermine + confidence in the reliability of the Internet's mail systems. So + silent dropping of messages should be considered only in those cases + where there is very high confidence that the messages are seriously + fraudulent or otherwise inappropriate. + + To stretch the principle of delivery if possible even further, it may + be a rational policy to not deliver mail that has an invalid return + address, although the history of the network is that users are + typically better served by delivering any message that can be + delivered. Reliably determining that a return address is invalid can + be a difficult and time-consuming process, especially if the putative + sending system is not directly accessible or does not fully and + accurately support VRFY and, even if a "drop messages with invalid + return addresses" policy is adopted, it SHOULD be applied only when + there is near-certainty that the return addresses are, in fact, + invalid. + + Conversely, if a message is rejected because it is found to contain + hostile content (a decision that is outside the scope of an SMTP + server as defined in this document), rejection ("bounce") messages + SHOULD NOT be sent unless the receiving site is confident that those + messages will be usefully delivered. The preference and default in + these cases is to avoid sending non-delivery messages when the + incoming message is determined to contain hostile content. + +6.3. Loop Detection + + Simple counting of the number of "Received:" header fields in a + message has proven to be an effective, although rarely optimal, + method of detecting loops in mail systems. SMTP servers using this + technique SHOULD use a large rejection threshold, normally at least + 100 Received entries. Whatever mechanisms are used, servers MUST + contain provisions for detecting and stopping trivial loops. + +6.4. Compensating for Irregularities + + Unfortunately, variations, creative interpretations, and outright + violations of Internet mail protocols do occur; some would suggest + that they occur quite frequently. The debate as to whether a well- + behaved SMTP receiver or relay should reject a malformed message, + attempt to pass it on unchanged, or attempt to repair it to increase + the odds of successful delivery (or subsequent reply) began almost + with the dawn of structured network mail and shows no signs of + abating. Advocates of rejection claim that attempted repairs are + rarely completely adequate and that rejection of bad messages is the + only way to get the offending software repaired. Advocates of + "repair" or "deliver no matter what" argue that users prefer that + + + +Klensin Standards Track [Page 73] + +RFC 5321 SMTP October 2008 + + + mail go through it if at all possible and that there are significant + market pressures in that direction. In practice, these market + pressures may be more important to particular vendors than strict + conformance to the standards, regardless of the preference of the + actual developers. + + The problems associated with ill-formed messages were exacerbated by + the introduction of the split-UA mail reading protocols (Post Office + Protocol (POP) version 2 [15], Post Office Protocol (POP) version 3 + [16], IMAP version 2 [41], and PCMAIL [42]). These protocols + encouraged the use of SMTP as a posting (message submission) + protocol, and SMTP servers as relay systems for these client hosts + (which are often only intermittently connected to the Internet). + Historically, many of those client machines lacked some of the + mechanisms and information assumed by SMTP (and indeed, by the mail + format protocol, RFC 822 [28]). Some could not keep adequate track + of time; others had no concept of time zones; still others could not + identify their own names or addresses; and, of course, none could + satisfy the assumptions that underlay RFC 822's conception of + authenticated addresses. + + In response to these weak SMTP clients, many SMTP systems now + complete messages that are delivered to them in incomplete or + incorrect form. This strategy is generally considered appropriate + when the server can identify or authenticate the client, and there + are prior agreements between them. By contrast, there is at best + great concern about fixes applied by a relay or delivery SMTP server + that has little or no knowledge of the user or client machine. Many + of these issues are addressed by using a separate protocol, such as + that defined in RFC 4409 [18], for message submission, rather than + using originating SMTP servers for that purpose. + + The following changes to a message being processed MAY be applied + when necessary by an originating SMTP server, or one used as the + target of SMTP as an initial posting (message submission) protocol: + + o Addition of a message-id field when none appears + + o Addition of a date, time, or time zone when none appears + + o Correction of addresses to proper FQDN format + + The less information the server has about the client, the less likely + these changes are to be correct and the more caution and conservatism + should be applied when considering whether or not to perform fixes + and how. These changes MUST NOT be applied by an SMTP server that + provides an intermediate relay function. + + + + +Klensin Standards Track [Page 74] + +RFC 5321 SMTP October 2008 + + + In all cases, properly operating clients supplying correct + information are preferred to corrections by the SMTP server. In all + cases, documentation SHOULD be provided in trace header fields and/or + header field comments for actions performed by the servers. + +7. Security Considerations + +7.1. Mail Security and Spoofing + + SMTP mail is inherently insecure in that it is feasible for even + fairly casual users to negotiate directly with receiving and relaying + SMTP servers and create messages that will trick a naive recipient + into believing that they came from somewhere else. Constructing such + a message so that the "spoofed" behavior cannot be detected by an + expert is somewhat more difficult, but not sufficiently so as to be a + deterrent to someone who is determined and knowledgeable. + Consequently, as knowledge of Internet mail increases, so does the + knowledge that SMTP mail inherently cannot be authenticated, or + integrity checks provided, at the transport level. Real mail + security lies only in end-to-end methods involving the message + bodies, such as those that use digital signatures (see RFC 1847 [43] + and, e.g., Pretty Good Privacy (PGP) in RFC 4880 [44] or Secure/ + Multipurpose Internet Mail Extensions (S/MIME) in RFC 3851 [45]). + + Various protocol extensions and configuration options that provide + authentication at the transport level (e.g., from an SMTP client to + an SMTP server) improve somewhat on the traditional situation + described above. However, in general, they only authenticate one + server to another rather than a chain of relays and servers, much + less authenticating users or user machines. Consequently, unless + they are accompanied by careful handoffs of responsibility in a + carefully designed trust environment, they remain inherently weaker + than end-to-end mechanisms that use digitally signed messages rather + than depending on the integrity of the transport system. + + Efforts to make it more difficult for users to set envelope return + path and header "From" fields to point to valid addresses other than + their own are largely misguided: they frustrate legitimate + applications in which mail is sent by one user on behalf of another, + in which error (or normal) replies should be directed to a special + address, or in which a single message is sent to multiple recipients + on different hosts. (Systems that provide convenient ways for users + to alter these header fields on a per-message basis should attempt to + establish a primary and permanent mailbox address for the user so + that Sender header fields within the message data can be generated + sensibly.) + + + + + +Klensin Standards Track [Page 75] + +RFC 5321 SMTP October 2008 + + + This specification does not further address the authentication issues + associated with SMTP other than to advocate that useful functionality + not be disabled in the hope of providing some small margin of + protection against a user who is trying to fake mail. + +7.2. "Blind" Copies + + Addresses that do not appear in the message header section may appear + in the RCPT commands to an SMTP server for a number of reasons. The + two most common involve the use of a mailing address as a "list + exploder" (a single address that resolves into multiple addresses) + and the appearance of "blind copies". Especially when more than one + RCPT command is present, and in order to avoid defeating some of the + purpose of these mechanisms, SMTP clients and servers SHOULD NOT copy + the full set of RCPT command arguments into the header section, + either as part of trace header fields or as informational or private- + extension header fields. Since this rule is often violated in + practice, and cannot be enforced, sending SMTP systems that are aware + of "bcc" use MAY find it helpful to send each blind copy as a + separate message transaction containing only a single RCPT command. + + There is no inherent relationship between either "reverse" (from + MAIL, SAML, etc., commands) or "forward" (RCPT) addresses in the SMTP + transaction ("envelope") and the addresses in the header section. + Receiving systems SHOULD NOT attempt to deduce such relationships and + use them to alter the header section of the message for delivery. + The popular "Apparently-to" header field is a violation of this + principle as well as a common source of unintended information + disclosure and SHOULD NOT be used. + +7.3. VRFY, EXPN, and Security + + As discussed in Section 3.5, individual sites may want to disable + either or both of VRFY or EXPN for security reasons (see below). As + a corollary to the above, implementations that permit this MUST NOT + appear to have verified addresses that are not, in fact, verified. + If a site disables these commands for security reasons, the SMTP + server MUST return a 252 response, rather than a code that could be + confused with successful or unsuccessful verification. + + Returning a 250 reply code with the address listed in the VRFY + command after having checked it only for syntax violates this rule. + Of course, an implementation that "supports" VRFY by always returning + 550 whether or not the address is valid is equally not in + conformance. + + On the public Internet, the contents of mailing lists have become + popular as an address information source for so-called "spammers." + + + +Klensin Standards Track [Page 76] + +RFC 5321 SMTP October 2008 + + + The use of EXPN to "harvest" addresses has increased as list + administrators have installed protections against inappropriate uses + of the lists themselves. However, VRFY and EXPN are still useful for + authenticated users and within an administrative domain. For + example, VRFY and EXPN are useful for performing internal audits of + how email gets routed to check and to make sure no one is + automatically forwarding sensitive mail outside the organization. + Sites implementing SMTP authentication may choose to make VRFY and + EXPN available only to authenticated requestors. Implementations + SHOULD still provide support for EXPN, but sites SHOULD carefully + evaluate the tradeoffs. + + Whether disabling VRFY provides any real marginal security depends on + a series of other conditions. In many cases, RCPT commands can be + used to obtain the same information about address validity. On the + other hand, especially in situations where determination of address + validity for RCPT commands is deferred until after the DATA command + is received, RCPT may return no information at all, while VRFY is + expected to make a serious attempt to determine validity before + generating a response code (see discussion above). + +7.4. Mail Rerouting Based on the 251 and 551 Response Codes + + Before a client uses the 251 or 551 reply codes from a RCPT command + to automatically update its future behavior (e.g., updating the + user's address book), it should be certain of the server's + authenticity. If it does not, it may be subject to a man in the + middle attack. + +7.5. Information Disclosure in Announcements + + There has been an ongoing debate about the tradeoffs between the + debugging advantages of announcing server type and version (and, + sometimes, even server domain name) in the greeting response or in + response to the HELP command and the disadvantages of exposing + information that might be useful in a potential hostile attack. The + utility of the debugging information is beyond doubt. Those who + argue for making it available point out that it is far better to + actually secure an SMTP server rather than hope that trying to + conceal known vulnerabilities by hiding the server's precise identity + will provide more protection. Sites are encouraged to evaluate the + tradeoff with that issue in mind; implementations SHOULD minimally + provide for making type and version information available in some way + to other network hosts. + + + + + + + +Klensin Standards Track [Page 77] + +RFC 5321 SMTP October 2008 + + +7.6. Information Disclosure in Trace Fields + + In some circumstances, such as when mail originates from within a LAN + whose hosts are not directly on the public Internet, trace + ("Received") header fields produced in conformance with this + specification may disclose host names and similar information that + would not normally be available. This ordinarily does not pose a + problem, but sites with special concerns about name disclosure should + be aware of it. Also, the optional FOR clause should be supplied + with caution or not at all when multiple recipients are involved lest + it inadvertently disclose the identities of "blind copy" recipients + to others. + +7.7. Information Disclosure in Message Forwarding + + As discussed in Section 3.4, use of the 251 or 551 reply codes to + identify the replacement address associated with a mailbox may + inadvertently disclose sensitive information. Sites that are + concerned about those issues should ensure that they select and + configure servers appropriately. + +7.8. Resistance to Attacks + + In recent years, there has been an increase of attacks on SMTP + servers, either in conjunction with attempts to discover addresses + for sending unsolicited messages or simply to make the servers + inaccessible to others (i.e., as an application-level denial of + service attack). While the means of doing so are beyond the scope of + this Standard, rational operational behavior requires that servers be + permitted to detect such attacks and take action to defend + themselves. For example, if a server determines that a large number + of RCPT TO commands are being sent, most or all with invalid + addresses, as part of such an attack, it would be reasonable for the + server to close the connection after generating an appropriate number + of 5yz (normally 550) replies. + +7.9. Scope of Operation of SMTP Servers + + It is a well-established principle that an SMTP server may refuse to + accept mail for any operational or technical reason that makes sense + to the site providing the server. However, cooperation among sites + and installations makes the Internet possible. If sites take + excessive advantage of the right to reject traffic, the ubiquity of + email availability (one of the strengths of the Internet) will be + threatened; considerable care should be taken and balance maintained + if a site decides to be selective about the traffic it will accept + and process. + + + + +Klensin Standards Track [Page 78] + +RFC 5321 SMTP October 2008 + + + In recent years, use of the relay function through arbitrary sites + has been used as part of hostile efforts to hide the actual origins + of mail. Some sites have decided to limit the use of the relay + function to known or identifiable sources, and implementations SHOULD + provide the capability to perform this type of filtering. When mail + is rejected for these or other policy reasons, a 550 code SHOULD be + used in response to EHLO (or HELO), MAIL, or RCPT as appropriate. + +8. IANA Considerations + + IANA maintains three registries in support of this specification, all + of which were created for RFC 2821 or earlier. This document expands + the third one as specified below. The registry references listed are + as of the time of publication; IANA does not guarantee the locations + associated with the URLs. The registries are as follows: + + o The first, "Simple Mail Transfer Protocol (SMTP) Service + Extensions" [46], consists of SMTP service extensions with the + associated keywords, and, as needed, parameters and verbs. As + specified in Section 2.2.2, no entry may be made in this registry + that starts in an "X". Entries may be made only for service + extensions (and associated keywords, parameters, or verbs) that + are defined in Standards-Track or Experimental RFCs specifically + approved by the IESG for this purpose. + + o The second registry, "Address Literal Tags" [47], consists of + "tags" that identify forms of domain literals other than those for + IPv4 addresses (specified in RFC 821 and in this document). The + initial entry in that registry is for IPv6 addresses (specified in + this document). Additional literal types require standardization + before being used; none are anticipated at this time. + + o The third, "Mail Transmission Types" [46], established by RFC 821 + and renewed by this specification, is a registry of link and + protocol identifiers to be used with the "via" and "with" + subclauses of the time stamp ("Received:" header field) described + in Section 4.4. Link and protocol identifiers in addition to + those specified in this document may be registered only by + standardization or by way of an RFC-documented, IESG-approved, + Experimental protocol extension. This name space is for + identification and not limited in size: the IESG is encouraged to + approve on the basis of clear documentation and a distinct method + rather than preferences about the properties of the method itself. + + An additional subsection has been added to the "VIA link types" + and "WITH protocol types" subsections of this registry to contain + registrations of "Additional-registered-clauses" as described + above. The registry will contain clause names, a description, a + + + +Klensin Standards Track [Page 79] + +RFC 5321 SMTP October 2008 + + + summary of the syntax of the associated String, and a reference. + As new clauses are defined, they may, in principle, specify + creation of their own registries if the Strings consist of + reserved terms or keywords rather than less restricted strings. + As with link and protocol identifiers, additional clauses may be + registered only by standardization or by way of an RFC-documented, + IESG-approved, Experimental protocol extension. The additional + clause name space is for identification and is not limited in + size: the IESG is encouraged to approve on the basis of clear + documentation, actual use or strong signs that the clause will be + used, and a distinct requirement rather than preferences about the + properties of the clause itself. + + In addition, if additional trace header fields (i.e., in addition to + Return-path and Received) are ever created, those trace fields MUST + be added to the IANA registry established by BCP 90 (RFC 3864) [11] + for use with RFC 5322 [4]. + +9. Acknowledgments + + Many people contributed to the development of RFC 2821. That + document should be consulted for those acknowledgments. For the + present document, the editor and the community owe thanks to Dawn + Mann and Tony Hansen who assisted in the very painful process of + editing and converting the internal format of the document from one + system to another. + + Neither this document nor RFC 2821 would have been possible without + the many contribution and insights of the late Jon Postel. Those + contributions of course include the original specification of SMTP in + RFC 821. A considerable quantity of text from RFC 821 still appears + in this document as do several of Jon's original examples that have + been updated only as needed to reflect other changes in the + specification. + + Many people made comments or suggestions on the mailing list or in + notes to the author. Important corrections or clarifications were + suggested by several people, including Matti Aarnio, Glenn Anderson, + Derek J. Balling, Alex van den Bogaerdt, Stephane Bortzmeyer, Vint + Cerf, Jutta Degener, Steve Dorner, Lisa Dusseault, Frank Ellerman, + Ned Freed, Randy Gellens, Sabahattin Gucukoglu, Philip Guenther, Arnt + Gulbrandsen, Eric Hall, Richard O. Hammer, Tony Hansen, Peter J. + Holzer, Kari Hurtta, Bryon Roche Kain, Valdis Kletnieks, Mathias + Koerber, John Leslie, Bruce Lilly, Jeff Macdonald, Mark E. Mallett, + Mark Martinec, S. Moonesamy, Lyndon Nerenberg, Chris Newman, Douglas + Otis, Pete Resnick, Robert A. Rosenberg, Vince Sabio, Hector Santos, + David F. Skoll, Paul Smith, and Brett Watson. + + + + +Klensin Standards Track [Page 80] + +RFC 5321 SMTP October 2008 + + + The efforts of the Area Directors -- Lisa Dusseault, Ted Hardie, and + Chris Newman -- to get this effort restarted and keep it moving, and + of an ad hoc committee with the same purpose, are gratefully + acknowledged. The members of that committee were (in alphabetical + order) Dave Crocker, Cyrus Daboo, Tony Finch, Ned Freed, Randall + Gellens, Tony Hansen, the author, and Alexey Melnikov. Tony Hansen + also acted as ad hoc chair on the mailing list reviewing this + document; without his efforts, sense of balance and fairness, and + patience, it clearly would not have been possible. + +10. References + +10.1. Normative References + + [1] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, + August 1982. + + [2] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, November 1987. + + [3] Braden, R., "Requirements for Internet Hosts - Application and + Support", STD 3, RFC 1123, October 1989. + + [4] Resnick, P., "Internet Message Format", RFC 5322, October 2008. + + [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + [6] American National Standards Institute (formerly United States + of America Standards Institute), "USA Code for Information + Interchange", ANSI X3.4-1968, 1968. + + ANSI X3.4-1968 has been replaced by newer versions with slight + modifications, but the 1968 version remains definitive for the + Internet. + + [7] Crocker, D. and P. Overell, "Augmented BNF for Syntax + Specifications: ABNF", STD 68, RFC 5234, January 2008. + + [8] Hinden, R. and S. Deering, "IP Version 6 Addressing + Architecture", RFC 4291, February 2006. + + [9] Newman, C., "ESMTP and LMTP Transmission Types Registration", + RFC 3848, July 2004. + + [10] Klensin, J., Freed, N., and K. Moore, "SMTP Service Extension + for Message Size Declaration", STD 10, RFC 1870, November 1995. + + + + +Klensin Standards Track [Page 81] + +RFC 5321 SMTP October 2008 + + + [11] Klyne, G., Nottingham, M., and J. Mogul, "Registration + Procedures for Message Header Fields", BCP 90, RFC 3864, + September 2004. + +10.2. Informative References + + [12] Partridge, C., "Mail routing and the domain system", RFC 974, + January 1986. + + [13] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. + Crocker, "SMTP Service Extensions", STD 10, RFC 1869, + November 1995. + + [14] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, + April 2001. + + [15] Butler, M., Postel, J., Chase, D., Goldberger, J., and J. + Reynolds, "Post Office Protocol: Version 2", RFC 937, + February 1985. + + [16] Myers, J. and M. Rose, "Post Office Protocol - Version 3", + STD 53, RFC 1939, May 1996. + + [17] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION + 4rev1", RFC 3501, March 2003. + + [18] Gellens, R. and J. Klensin, "Message Submission for Mail", + RFC 4409, April 2006. + + [19] Freed, N., "SMTP Service Extension for Command Pipelining", + STD 60, RFC 2920, September 2000. + + [20] Vaudreuil, G., "SMTP Service Extensions for Transmission of + Large and Binary MIME Messages", RFC 3030, December 2000. + + [21] Freed, N. and N. Borenstein, "Multipurpose Internet Mail + Extensions (MIME) Part One: Format of Internet Message Bodies", + RFC 2045, November 1996. + + [22] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. + Crocker, "SMTP Service Extension for 8bit-MIMEtransport", + RFC 1652, July 1994. + + [23] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part + Three: Message Header Extensions for Non-ASCII Text", RFC 2047, + November 1996. + + + + + +Klensin Standards Track [Page 82] + +RFC 5321 SMTP October 2008 + + + [24] Freed, N. and K. Moore, "MIME Parameter Value and Encoded Word + Extensions: Character Sets, Languages, and Continuations", + RFC 2231, November 1997. + + [25] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 3463, + January 2003. + + [26] Hansen, T. and J. Klensin, "A Registry for SMTP Enhanced Mail + System Status Codes", BCP 138, RFC 5248, June 2008. + + [27] Freed, N., "Behavior of and Requirements for Internet + Firewalls", RFC 2979, October 2000. + + [28] Crocker, D., "Standard for the format of ARPA Internet text + messages", STD 11, RFC 822, August 1982. + + [29] Wong, M. and W. Schlitt, "Sender Policy Framework (SPF) for + Authorizing Use of Domains in E-Mail, Version 1", RFC 4408, + April 2006. + + [30] Fenton, J., "Analysis of Threats Motivating DomainKeys + Identified Mail (DKIM)", RFC 4686, September 2006. + + [31] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, J., and + M. Thomas, "DomainKeys Identified Mail (DKIM) Signatures", + RFC 4871, May 2007. + + [32] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service + Extension for Delivery Status Notifications (DSNs)", RFC 3461, + January 2003. + + [33] Moore, K. and G. Vaudreuil, "An Extensible Message Format for + Delivery Status Notifications", RFC 3464, January 2003. + + [34] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, + RFC 959, October 1985. + + [35] Kille, S., "MIXER (Mime Internet X.400 Enhanced Relay): Mapping + between X.400 and RFC 822/MIME", RFC 2156, January 1998. + + [36] De Winter, J., "SMTP Service Extension for Remote Message Queue + Starting", RFC 1985, August 1996. + + [37] Hansen, T. and G. Vaudreuil, "Message Disposition + Notification", RFC 3798, May 2004. + + [38] Elz, R. and R. Bush, "Clarifications to the DNS Specification", + RFC 2181, July 1997. + + + +Klensin Standards Track [Page 83] + +RFC 5321 SMTP October 2008 + + + [39] Nakamura, M. and J. Hagino, "SMTP Operational Experience in + Mixed IPv4/v6 Environments", RFC 3974, January 2005. + + [40] Partridge, C., "Duplicate messages and SMTP", RFC 1047, + February 1988. + + [41] Crispin, M., "Interactive Mail Access Protocol: Version 2", + RFC 1176, August 1990. + + [42] Lambert, M., "PCMAIL: A distributed mail system for personal + computers", RFC 1056, June 1988. + + [43] Galvin, J., Murphy, S., Crocker, S., and N. Freed, "Security + Multiparts for MIME: Multipart/Signed and Multipart/Encrypted", + RFC 1847, October 1995. + + [44] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. + Thayer, "OpenPGP Message Format", RFC 4880, November 2007. + + [45] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions + (S/MIME) Version 3.1 Message Specification", RFC 3851, + July 2004. + + [46] Internet Assigned Number Authority (IANA), "IANA Mail + Parameters", 2007, + . + + [47] Internet Assigned Number Authority (IANA), "Address Literal + Tags", 2007, + . + + + + + + + + + + + + + + + + + + + + + +Klensin Standards Track [Page 84] + +RFC 5321 SMTP October 2008 + + +Appendix A. TCP Transport Service + + The TCP connection supports the transmission of 8-bit bytes. The + SMTP data is 7-bit ASCII characters. Each character is transmitted + as an 8-bit byte with the high-order bit cleared to zero. Service + extensions may modify this rule to permit transmission of full 8-bit + data bytes as part of the message body, or, if specifically designed + to do so, in SMTP commands or responses. + +Appendix B. Generating SMTP Commands from RFC 822 Header Fields + + Some systems use an RFC 822 header section (only) in a mail + submission protocol, or otherwise generate SMTP commands from RFC 822 + header fields when such a message is handed to an MTA from a UA. + While the MTA-UA protocol is a private matter, not covered by any + Internet Standard, there are problems with this approach. For + example, there have been repeated problems with proper handling of + "bcc" copies and redistribution lists when information that + conceptually belongs to the mail envelope is not separated early in + processing from header field information (and kept separate). + + It is recommended that the UA provide its initial ("submission + client") MTA with an envelope separate from the message itself. + However, if the envelope is not supplied, SMTP commands SHOULD be + generated as follows: + + 1. Each recipient address from a TO, CC, or BCC header field SHOULD + be copied to a RCPT command (generating multiple message copies + if that is required for queuing or delivery). This includes any + addresses listed in a RFC 822 "group". Any BCC header fields + SHOULD then be removed from the header section. Once this + process is completed, the remaining header fields SHOULD be + checked to verify that at least one TO, CC, or BCC header field + remains. If none do, then a BCC header field with no additional + information SHOULD be inserted as specified in [4]. + + 2. The return address in the MAIL command SHOULD, if possible, be + derived from the system's identity for the submitting (local) + user, and the "From:" header field otherwise. If there is a + system identity available, it SHOULD also be copied to the Sender + header field if it is different from the address in the From + header field. (Any Sender header field that was already there + SHOULD be removed.) Systems may provide a way for submitters to + override the envelope return address, but may want to restrict + its use to privileged users. This will not prevent mail forgery, + but may lessen its incidence; see Section 7.1. + + + + + +Klensin Standards Track [Page 85] + +RFC 5321 SMTP October 2008 + + + When an MTA is being used in this way, it bears responsibility for + ensuring that the message being transmitted is valid. The mechanisms + for checking that validity, and for handling (or returning) messages + that are not valid at the time of arrival, are part of the MUA-MTA + interface and not covered by this specification. + + A submission protocol based on Standard RFC 822 information alone + MUST NOT be used to gateway a message from a foreign (non-SMTP) mail + system into an SMTP environment. Additional information to construct + an envelope must come from some source in the other environment, + whether supplemental header fields or the foreign system's envelope. + + Attempts to gateway messages using only their header "To" and "Cc" + fields have repeatedly caused mail loops and other behavior adverse + to the proper functioning of the Internet mail environment. These + problems have been especially common when the message originates from + an Internet mailing list and is distributed into the foreign + environment using envelope information. When these messages are then + processed by a header-section-only remailer, loops back to the + Internet environment (and the mailing list) are almost inevitable. + +Appendix C. Source Routes + + Historically, the was a reverse source routing list of + hosts and a source mailbox. The first host in the was + historically the host sending the MAIL command; today, source routes + SHOULD NOT appear in the reverse-path. Similarly, the + may be a source routing lists of hosts and a destination mailbox. + However, in general, the SHOULD contain only a mailbox + and domain name, relying on the domain name system to supply routing + information if required. The use of source routes is deprecated (see + Appendix F.2); while servers MUST be prepared to receive and handle + them as discussed in Section 3.3 and Appendix F.2, clients SHOULD NOT + transmit them and this section is included in the current + specification only to provide context. It has been modified somewhat + from the material in RFC 821 to prevent server actions that might + confuse clients or subsequent servers that do not expect a full + source route implementation. + + For relay purposes, the forward-path may be a source route of the + form "@ONE,@TWO:JOE@THREE", where ONE, TWO, and THREE MUST be fully- + qualified domain names. This form is used to emphasize the + distinction between an address and a route. The mailbox (here, JOE@ + THREE) is an absolute address, and the route is information about how + to get there. The two concepts should not be confused. + + If source routes are used, RFC 821 and the text below should be + consulted for the mechanisms for constructing and updating the + + + +Klensin Standards Track [Page 86] + +RFC 5321 SMTP October 2008 + + + forward-path. A server that is reached by means of a source route + (e.g., its domain name appears first in the list in the forward-path) + MUST remove its domain name from any forward-paths in which that + domain name appears before forwarding the message and MAY remove all + other source routing information. The reverse-path SHOULD NOT be + updated by servers conforming to this specification. + + Notice that the forward-path and reverse-path appear in the SMTP + commands and replies, but not necessarily in the message. That is, + there is no need for these paths and especially this syntax to appear + in the "To:" , "From:", "CC:", etc. fields of the message header + section. Conversely, SMTP servers MUST NOT derive final message + routing information from message header fields. + + When the list of hosts is present despite the recommendations above, + it is a "reverse" source route and indicates that the mail was + relayed through each host on the list (the first host in the list was + the most recent relay). This list is used as a source route to + return non-delivery notices to the sender. If, contrary to the + recommendations here, a relay host adds itself to the beginning of + the list, it MUST use its name as known in the transport environment + to which it is relaying the mail rather than that of the transport + environment from which the mail came (if they are different). Note + that a situation could easily arise in which some relay hosts add + their names to the reverse source route and others do not, generating + discontinuities in the routing list. This is another reason why + servers needing to return a message SHOULD ignore the source route + entirely and simply use the domain as specified in the Mailbox. + +Appendix D. Scenarios + + This section presents complete scenarios of several types of SMTP + sessions. In the examples, "C:" indicates what is said by the SMTP + client, and "S:" indicates what is said by the SMTP server. + + + + + + + + + + + + + + + + + +Klensin Standards Track [Page 87] + +RFC 5321 SMTP October 2008 + + +D.1. A Typical SMTP Transaction Scenario + + This SMTP example shows mail sent by Smith at host bar.com, and to + Jones, Green, and Brown at host foo.com. Here we assume that host + bar.com contacts host foo.com directly. The mail is accepted for + Jones and Brown. Green does not have a mailbox at host foo.com. + + S: 220 foo.com Simple Mail Transfer Service Ready + C: EHLO bar.com + S: 250-foo.com greets bar.com + S: 250-8BITMIME + S: 250-SIZE + S: 250-DSN + S: 250 HELP + C: MAIL FROM: + S: 250 OK + C: RCPT TO: + S: 250 OK + C: RCPT TO: + S: 550 No such user here + C: RCPT TO: + S: 250 OK + C: DATA + S: 354 Start mail input; end with . + C: Blah blah blah... + C: ...etc. etc. etc. + C: . + S: 250 OK + C: QUIT + S: 221 foo.com Service closing transmission channel + + + + + + + + + + + + + + + + + + + + + +Klensin Standards Track [Page 88] + +RFC 5321 SMTP October 2008 + + +D.2. Aborted SMTP Transaction Scenario + + S: 220 foo.com Simple Mail Transfer Service Ready + C: EHLO bar.com + S: 250-foo.com greets bar.com + S: 250-8BITMIME + S: 250-SIZE + S: 250-DSN + S: 250 HELP + C: MAIL FROM: + S: 250 OK + C: RCPT TO: + S: 250 OK + C: RCPT TO: + S: 550 No such user here + C: RSET + S: 250 OK + C: QUIT + S: 221 foo.com Service closing transmission channel + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Klensin Standards Track [Page 89] + +RFC 5321 SMTP October 2008 + + +D.3. Relayed Mail Scenario + + Step 1 -- Source Host to Relay Host + + The source host performs a DNS lookup on XYZ.COM (the destination + address) and finds DNS MX records specifying xyz.com as the best + preference and foo.com as a lower preference. It attempts to open a + connection to xyz.com and fails. It then opens a connection to + foo.com, with the following dialogue: + + S: 220 foo.com Simple Mail Transfer Service Ready + C: EHLO bar.com + S: 250-foo.com greets bar.com + S: 250-8BITMIME + S: 250-SIZE + S: 250-DSN + S: 250 HELP + C: MAIL FROM: + S: 250 OK + C: RCPT TO: + S: 250 OK + C: DATA + S: 354 Start mail input; end with . + C: Date: Thu, 21 May 1998 05:33:29 -0700 + C: From: John Q. Public + C: Subject: The Next Meeting of the Board + C: To: Jones@xyz.com + C: + C: Bill: + C: The next meeting of the board of directors will be + C: on Tuesday. + C: John. + C: . + S: 250 OK + C: QUIT + S: 221 foo.com Service closing transmission channel + + + + + + + + + + + + + + + +Klensin Standards Track [Page 90] + +RFC 5321 SMTP October 2008 + + + Step 2 -- Relay Host to Destination Host + + foo.com, having received the message, now does a DNS lookup on + xyz.com. It finds the same set of MX records, but cannot use the one + that points to itself (or to any other host as a worse preference). + It tries to open a connection to xyz.com itself and succeeds. Then + we have: + + S: 220 xyz.com Simple Mail Transfer Service Ready + C: EHLO foo.com + S: 250 xyz.com is on the air + C: MAIL FROM: + S: 250 OK + C: RCPT TO: + S: 250 OK + C: DATA + S: 354 Start mail input; end with . + C: Received: from bar.com by foo.com ; Thu, 21 May 1998 + C: 05:33:29 -0700 + C: Date: Thu, 21 May 1998 05:33:22 -0700 + C: From: John Q. Public + C: Subject: The Next Meeting of the Board + C: To: Jones@xyz.com + C: + C: Bill: + C: The next meeting of the board of directors will be + C: on Tuesday. + C: John. + C: . + S: 250 OK + C: QUIT + S: 221 foo.com Service closing transmission channel + + + + + + + + + + + + + + + + + + + +Klensin Standards Track [Page 91] + +RFC 5321 SMTP October 2008 + + +D.4. Verifying and Sending Scenario + + S: 220 foo.com Simple Mail Transfer Service Ready + C: EHLO bar.com + S: 250-foo.com greets bar.com + S: 250-8BITMIME + S: 250-SIZE + S: 250-DSN + S: 250-VRFY + S: 250 HELP + C: VRFY Crispin + S: 250 Mark Crispin + C: MAIL FROM: + S: 250 OK + C: RCPT TO: + S: 250 OK + C: DATA + S: 354 Start mail input; end with . + C: Blah blah blah... + C: ...etc. etc. etc. + C: . + S: 250 OK + C: QUIT + S: 221 foo.com Service closing transmission channel + +Appendix E. Other Gateway Issues + + In general, gateways between the Internet and other mail systems + SHOULD attempt to preserve any layering semantics across the + boundaries between the two mail systems involved. Gateway- + translation approaches that attempt to take shortcuts by mapping + (such as mapping envelope information from one system to the message + header section or body of another) have generally proven to be + inadequate in important ways. Systems translating between + environments that do not support both envelopes and a header section + and Internet mail must be written with the understanding that some + information loss is almost inevitable. + + + + + + + + + + + + + + +Klensin Standards Track [Page 92] + +RFC 5321 SMTP October 2008 + + +Appendix F. Deprecated Features of RFC 821 + + A few features of RFC 821 have proven to be problematic and SHOULD + NOT be used in Internet mail. + +F.1. TURN + + This command, described in RFC 821, raises important security issues + since, in the absence of strong authentication of the host requesting + that the client and server switch roles, it can easily be used to + divert mail from its correct destination. Its use is deprecated; + SMTP systems SHOULD NOT use it unless the server can authenticate the + client. + +F.2. Source Routing + + RFC 821 utilized the concept of explicit source routing to get mail + from one host to another via a series of relays. The requirement to + utilize source routes in regular mail traffic was eliminated by the + introduction of the domain name system "MX" record and the last + significant justification for them was eliminated by the + introduction, in RFC 1123, of a clear requirement that addresses + following an "@" must all be fully-qualified domain names. + Consequently, the only remaining justifications for the use of source + routes are support for very old SMTP clients or MUAs and in mail + system debugging. They can, however, still be useful in the latter + circumstance and for routing mail around serious, but temporary, + problems such as problems with the relevant DNS records. + + SMTP servers MUST continue to accept source route syntax as specified + in the main body of this document and in RFC 1123. They MAY, if + necessary, ignore the routes and utilize only the target domain in + the address. If they do utilize the source route, the message MUST + be sent to the first domain shown in the address. In particular, a + server MUST NOT guess at shortcuts within the source route. + + Clients SHOULD NOT utilize explicit source routing except under + unusual circumstances, such as debugging or potentially relaying + around firewall or mail system configuration errors. + +F.3. HELO + + As discussed in Sections 3.1 and 4.1.1, EHLO SHOULD be used rather + than HELO when the server will accept the former. Servers MUST + continue to accept and process HELO in order to support older + clients. + + + + + +Klensin Standards Track [Page 93] + +RFC 5321 SMTP October 2008 + + +F.4. #-literals + + RFC 821 provided for specifying an Internet address as a decimal + integer host number prefixed by a pound sign, "#". In practice, that + form has been obsolete since the introduction of TCP/IP. It is + deprecated and MUST NOT be used. + +F.5. Dates and Years + + When dates are inserted into messages by SMTP clients or servers + (e.g., in trace header fields), four-digit years MUST BE used. Two- + digit years are deprecated; three-digit years were never permitted in + the Internet mail system. + +F.6. Sending versus Mailing + + In addition to specifying a mechanism for delivering messages to + user's mailboxes, RFC 821 provided additional, optional, commands to + deliver messages directly to the user's terminal screen. These + commands (SEND, SAML, SOML) were rarely implemented, and changes in + workstation technology and the introduction of other protocols may + have rendered them obsolete even where they are implemented. + + Clients SHOULD NOT provide SEND, SAML, or SOML as services. Servers + MAY implement them. If they are implemented by servers, the + implementation model specified in RFC 821 MUST be used and the + command names MUST be published in the response to the EHLO command. + +Author's Address + + John C. Klensin + 1770 Massachusetts Ave, Suite 322 + Cambridge, MA 02140 + USA + + EMail: john+smtp@jck.com + + + + + + + + + + + + + + + +Klensin Standards Track [Page 94] + +RFC 5321 SMTP October 2008 + + +Full Copyright Statement + + Copyright (C) The IETF Trust (2008). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND + THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS + OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF + THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + + + + + + + + + + + + +Klensin Standards Track [Page 95] + diff --git a/RFCs/rfc5322.txt b/RFCs/rfc5322.txt new file mode 100644 index 0000000..f330686 --- /dev/null +++ b/RFCs/rfc5322.txt @@ -0,0 +1,3195 @@ + + + + + + +Network Working Group P. Resnick, Ed. +Request for Comments: 5322 Qualcomm Incorporated +Obsoletes: 2822 October 2008 +Updates: 4021 +Category: Standards Track + + + Internet Message Format + +Status of This Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Abstract + + This document specifies the Internet Message Format (IMF), a syntax + for text messages that are sent between computer users, within the + framework of "electronic mail" messages. This specification is a + revision of Request For Comments (RFC) 2822, which itself superseded + Request For Comments (RFC) 822, "Standard for the Format of ARPA + Internet Text Messages", updating it to reflect current practice and + incorporating incremental changes that were specified in other RFCs. + + + + + + + + + + + + + + + + + + + + + + + + + +Resnick Standards Track [Page 1] + +RFC 5322 Internet Message Format October 2008 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 1.2. Notational Conventions . . . . . . . . . . . . . . . . . . 5 + 1.2.1. Requirements Notation . . . . . . . . . . . . . . . . 5 + 1.2.2. Syntactic Notation . . . . . . . . . . . . . . . . . . 5 + 1.2.3. Structure of This Document . . . . . . . . . . . . . . 5 + 2. Lexical Analysis of Messages . . . . . . . . . . . . . . . . . 6 + 2.1. General Description . . . . . . . . . . . . . . . . . . . 6 + 2.1.1. Line Length Limits . . . . . . . . . . . . . . . . . . 7 + 2.2. Header Fields . . . . . . . . . . . . . . . . . . . . . . 8 + 2.2.1. Unstructured Header Field Bodies . . . . . . . . . . . 8 + 2.2.2. Structured Header Field Bodies . . . . . . . . . . . . 8 + 2.2.3. Long Header Fields . . . . . . . . . . . . . . . . . . 8 + 2.3. Body . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 + 3. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 + 3.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 10 + 3.2. Lexical Tokens . . . . . . . . . . . . . . . . . . . . . . 10 + 3.2.1. Quoted characters . . . . . . . . . . . . . . . . . . 10 + 3.2.2. Folding White Space and Comments . . . . . . . . . . . 11 + 3.2.3. Atom . . . . . . . . . . . . . . . . . . . . . . . . . 12 + 3.2.4. Quoted Strings . . . . . . . . . . . . . . . . . . . . 13 + 3.2.5. Miscellaneous Tokens . . . . . . . . . . . . . . . . . 14 + 3.3. Date and Time Specification . . . . . . . . . . . . . . . 14 + 3.4. Address Specification . . . . . . . . . . . . . . . . . . 16 + 3.4.1. Addr-Spec Specification . . . . . . . . . . . . . . . 17 + 3.5. Overall Message Syntax . . . . . . . . . . . . . . . . . . 18 + 3.6. Field Definitions . . . . . . . . . . . . . . . . . . . . 19 + 3.6.1. The Origination Date Field . . . . . . . . . . . . . . 22 + 3.6.2. Originator Fields . . . . . . . . . . . . . . . . . . 22 + 3.6.3. Destination Address Fields . . . . . . . . . . . . . . 23 + 3.6.4. Identification Fields . . . . . . . . . . . . . . . . 25 + 3.6.5. Informational Fields . . . . . . . . . . . . . . . . . 27 + 3.6.6. Resent Fields . . . . . . . . . . . . . . . . . . . . 28 + 3.6.7. Trace Fields . . . . . . . . . . . . . . . . . . . . . 30 + 3.6.8. Optional Fields . . . . . . . . . . . . . . . . . . . 30 + 4. Obsolete Syntax . . . . . . . . . . . . . . . . . . . . . . . 31 + 4.1. Miscellaneous Obsolete Tokens . . . . . . . . . . . . . . 32 + 4.2. Obsolete Folding White Space . . . . . . . . . . . . . . . 33 + 4.3. Obsolete Date and Time . . . . . . . . . . . . . . . . . . 33 + 4.4. Obsolete Addressing . . . . . . . . . . . . . . . . . . . 35 + 4.5. Obsolete Header Fields . . . . . . . . . . . . . . . . . . 35 + 4.5.1. Obsolete Origination Date Field . . . . . . . . . . . 36 + 4.5.2. Obsolete Originator Fields . . . . . . . . . . . . . . 36 + 4.5.3. Obsolete Destination Address Fields . . . . . . . . . 37 + 4.5.4. Obsolete Identification Fields . . . . . . . . . . . . 37 + 4.5.5. Obsolete Informational Fields . . . . . . . . . . . . 37 + + + +Resnick Standards Track [Page 2] + +RFC 5322 Internet Message Format October 2008 + + + 4.5.6. Obsolete Resent Fields . . . . . . . . . . . . . . . . 38 + 4.5.7. Obsolete Trace Fields . . . . . . . . . . . . . . . . 38 + 4.5.8. Obsolete optional fields . . . . . . . . . . . . . . . 38 + 5. Security Considerations . . . . . . . . . . . . . . . . . . . 38 + 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39 + Appendix A. Example Messages . . . . . . . . . . . . . . . . . 43 + Appendix A.1. Addressing Examples . . . . . . . . . . . . . . . 44 + Appendix A.1.1. A Message from One Person to Another with + Simple Addressing . . . . . . . . . . . . . . . . 44 + Appendix A.1.2. Different Types of Mailboxes . . . . . . . . . . . 45 + Appendix A.1.3. Group Addresses . . . . . . . . . . . . . . . . . 45 + Appendix A.2. Reply Messages . . . . . . . . . . . . . . . . . . 46 + Appendix A.3. Resent Messages . . . . . . . . . . . . . . . . . 47 + Appendix A.4. Messages with Trace Fields . . . . . . . . . . . . 48 + Appendix A.5. White Space, Comments, and Other Oddities . . . . 49 + Appendix A.6. Obsoleted Forms . . . . . . . . . . . . . . . . . 50 + Appendix A.6.1. Obsolete Addressing . . . . . . . . . . . . . . . 50 + Appendix A.6.2. Obsolete Dates . . . . . . . . . . . . . . . . . . 50 + Appendix A.6.3. Obsolete White Space and Comments . . . . . . . . 51 + Appendix B. Differences from Earlier Specifications . . . . . 52 + Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . 53 + 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 55 + 7.1. Normative References . . . . . . . . . . . . . . . . . . . 55 + 7.2. Informative References . . . . . . . . . . . . . . . . . . 55 + + + + + + + + + + + + + + + + + + + + + + + + + + + +Resnick Standards Track [Page 3] + +RFC 5322 Internet Message Format October 2008 + + +1. Introduction + +1.1. Scope + + This document specifies the Internet Message Format (IMF), a syntax + for text messages that are sent between computer users, within the + framework of "electronic mail" messages. This specification is an + update to [RFC2822], which itself superseded [RFC0822], updating it + to reflect current practice and incorporating incremental changes + that were specified in other RFCs such as [RFC1123]. + + This document specifies a syntax only for text messages. In + particular, it makes no provision for the transmission of images, + audio, or other sorts of structured data in electronic mail messages. + There are several extensions published, such as the MIME document + series ([RFC2045], [RFC2046], [RFC2049]), which describe mechanisms + for the transmission of such data through electronic mail, either by + extending the syntax provided here or by structuring such messages to + conform to this syntax. Those mechanisms are outside of the scope of + this specification. + + In the context of electronic mail, messages are viewed as having an + envelope and contents. The envelope contains whatever information is + needed to accomplish transmission and delivery. (See [RFC5321] for a + discussion of the envelope.) The contents comprise the object to be + delivered to the recipient. This specification applies only to the + format and some of the semantics of message contents. It contains no + specification of the information in the envelope. + + However, some message systems may use information from the contents + to create the envelope. It is intended that this specification + facilitate the acquisition of such information by programs. + + This specification is intended as a definition of what message + content format is to be passed between systems. Though some message + systems locally store messages in this format (which eliminates the + need for translation between formats) and others use formats that + differ from the one specified in this specification, local storage is + outside of the scope of this specification. + + Note: This specification is not intended to dictate the internal + formats used by sites, the specific message system features that + they are expected to support, or any of the characteristics of + user interface programs that create or read messages. In + addition, this document does not specify an encoding of the + characters for either transport or storage; that is, it does not + specify the number of bits used or how those bits are specifically + transferred over the wire or stored on disk. + + + +Resnick Standards Track [Page 4] + +RFC 5322 Internet Message Format October 2008 + + +1.2. Notational Conventions + +1.2.1. Requirements Notation + + This document occasionally uses terms that appear in capital letters. + When the terms "MUST", "SHOULD", "RECOMMENDED", "MUST NOT", "SHOULD + NOT", and "MAY" appear capitalized, they are being used to indicate + particular requirements of this specification. A discussion of the + meanings of these terms appears in [RFC2119]. + +1.2.2. Syntactic Notation + + This specification uses the Augmented Backus-Naur Form (ABNF) + [RFC5234] notation for the formal definitions of the syntax of + messages. Characters will be specified either by a decimal value + (e.g., the value %d65 for uppercase A and %d97 for lowercase A) or by + a case-insensitive literal value enclosed in quotation marks (e.g., + "A" for either uppercase or lowercase A). + +1.2.3. Structure of This Document + + This document is divided into several sections. + + This section, section 1, is a short introduction to the document. + + Section 2 lays out the general description of a message and its + constituent parts. This is an overview to help the reader understand + some of the general principles used in the later portions of this + document. Any examples in this section MUST NOT be taken as + specification of the formal syntax of any part of a message. + + Section 3 specifies formal ABNF rules for the structure of each part + of a message (the syntax) and describes the relationship between + those parts and their meaning in the context of a message (the + semantics). That is, it lays out the actual rules for the structure + of each part of a message (the syntax) as well as a description of + the parts and instructions for their interpretation (the semantics). + This includes analysis of the syntax and semantics of subparts of + messages that have specific structure. The syntax included in + section 3 represents messages as they MUST be created. There are + also notes in section 3 to indicate if any of the options specified + in the syntax SHOULD be used over any of the others. + + Both sections 2 and 3 describe messages that are legal to generate + for purposes of this specification. + + + + + + +Resnick Standards Track [Page 5] + +RFC 5322 Internet Message Format October 2008 + + + Section 4 of this document specifies an "obsolete" syntax. There are + references in section 3 to these obsolete syntactic elements. The + rules of the obsolete syntax are elements that have appeared in + earlier versions of this specification or have previously been widely + used in Internet messages. As such, these elements MUST be + interpreted by parsers of messages in order to be conformant to this + specification. However, since items in this syntax have been + determined to be non-interoperable or to cause significant problems + for recipients of messages, they MUST NOT be generated by creators of + conformant messages. + + Section 5 details security considerations to take into account when + implementing this specification. + + Appendix A lists examples of different sorts of messages. These + examples are not exhaustive of the types of messages that appear on + the Internet, but give a broad overview of certain syntactic forms. + + Appendix B lists the differences between this specification and + earlier specifications for Internet messages. + + Appendix C contains acknowledgements. + +2. Lexical Analysis of Messages + +2.1. General Description + + At the most basic level, a message is a series of characters. A + message that is conformant with this specification is composed of + characters with values in the range of 1 through 127 and interpreted + as US-ASCII [ANSI.X3-4.1986] characters. For brevity, this document + sometimes refers to this range of characters as simply "US-ASCII + characters". + + Note: This document specifies that messages are made up of + characters in the US-ASCII range of 1 through 127. There are + other documents, specifically the MIME document series ([RFC2045], + [RFC2046], [RFC2047], [RFC2049], [RFC4288], [RFC4289]), that + extend this specification to allow for values outside of that + range. Discussion of those mechanisms is not within the scope of + this specification. + + Messages are divided into lines of characters. A line is a series of + characters that is delimited with the two characters carriage-return + and line-feed; that is, the carriage return (CR) character (ASCII + value 13) followed immediately by the line feed (LF) character (ASCII + value 10). (The carriage return/line feed pair is usually written in + this document as "CRLF".) + + + +Resnick Standards Track [Page 6] + +RFC 5322 Internet Message Format October 2008 + + + A message consists of header fields (collectively called "the header + section of the message") followed, optionally, by a body. The header + section is a sequence of lines of characters with special syntax as + defined in this specification. The body is simply a sequence of + characters that follows the header section and is separated from the + header section by an empty line (i.e., a line with nothing preceding + the CRLF). + + Note: Common parlance and earlier versions of this specification + use the term "header" to either refer to the entire header section + or to refer to an individual header field. To avoid ambiguity, + this document does not use the terms "header" or "headers" in + isolation, but instead always uses "header field" to refer to the + individual field and "header section" to refer to the entire + collection. + +2.1.1. Line Length Limits + + There are two limits that this specification places on the number of + characters in a line. Each line of characters MUST be no more than + 998 characters, and SHOULD be no more than 78 characters, excluding + the CRLF. + + The 998 character limit is due to limitations in many implementations + that send, receive, or store IMF messages which simply cannot handle + more than 998 characters on a line. Receiving implementations would + do well to handle an arbitrarily large number of characters in a line + for robustness sake. However, there are so many implementations that + (in compliance with the transport requirements of [RFC5321]) do not + accept messages containing more than 1000 characters including the CR + and LF per line, it is important for implementations not to create + such messages. + + The more conservative 78 character recommendation is to accommodate + the many implementations of user interfaces that display these + messages which may truncate, or disastrously wrap, the display of + more than 78 characters per line, in spite of the fact that such + implementations are non-conformant to the intent of this + specification (and that of [RFC5321] if they actually cause + information to be lost). Again, even though this limitation is put + on messages, it is incumbent upon implementations that display + messages to handle an arbitrarily large number of characters in a + line (certainly at least up to the 998 character limit) for the sake + of robustness. + + + + + + + +Resnick Standards Track [Page 7] + +RFC 5322 Internet Message Format October 2008 + + +2.2. Header Fields + + Header fields are lines beginning with a field name, followed by a + colon (":"), followed by a field body, and terminated by CRLF. A + field name MUST be composed of printable US-ASCII characters (i.e., + characters that have values between 33 and 126, inclusive), except + colon. A field body may be composed of printable US-ASCII characters + as well as the space (SP, ASCII value 32) and horizontal tab (HTAB, + ASCII value 9) characters (together known as the white space + characters, WSP). A field body MUST NOT include CR and LF except + when used in "folding" and "unfolding", as described in section + 2.2.3. All field bodies MUST conform to the syntax described in + sections 3 and 4 of this specification. + +2.2.1. Unstructured Header Field Bodies + + Some field bodies in this specification are defined simply as + "unstructured" (which is specified in section 3.2.5 as any printable + US-ASCII characters plus white space characters) with no further + restrictions. These are referred to as unstructured field bodies. + Semantically, unstructured field bodies are simply to be treated as a + single line of characters with no further processing (except for + "folding" and "unfolding" as described in section 2.2.3). + +2.2.2. Structured Header Field Bodies + + Some field bodies in this specification have a syntax that is more + restrictive than the unstructured field bodies described above. + These are referred to as "structured" field bodies. Structured field + bodies are sequences of specific lexical tokens as described in + sections 3 and 4 of this specification. Many of these tokens are + allowed (according to their syntax) to be introduced or end with + comments (as described in section 3.2.2) as well as the white space + characters, and those white space characters are subject to "folding" + and "unfolding" as described in section 2.2.3. Semantic analysis of + structured field bodies is given along with their syntax. + +2.2.3. Long Header Fields + + Each header field is logically a single line of characters comprising + the field name, the colon, and the field body. For convenience + however, and to deal with the 998/78 character limitations per line, + the field body portion of a header field can be split into a + multiple-line representation; this is called "folding". The general + rule is that wherever this specification allows for folding white + space (not simply WSP characters), a CRLF may be inserted before any + WSP. + + + + +Resnick Standards Track [Page 8] + +RFC 5322 Internet Message Format October 2008 + + + For example, the header field: + + Subject: This is a test + + can be represented as: + + Subject: This + is a test + + Note: Though structured field bodies are defined in such a way + that folding can take place between many of the lexical tokens + (and even within some of the lexical tokens), folding SHOULD be + limited to placing the CRLF at higher-level syntactic breaks. For + instance, if a field body is defined as comma-separated values, it + is recommended that folding occur after the comma separating the + structured items in preference to other places where the field + could be folded, even if it is allowed elsewhere. + + The process of moving from this folded multiple-line representation + of a header field to its single line representation is called + "unfolding". Unfolding is accomplished by simply removing any CRLF + that is immediately followed by WSP. Each header field should be + treated in its unfolded form for further syntactic and semantic + evaluation. An unfolded header field has no length restriction and + therefore may be indeterminately long. + +2.3. Body + + The body of a message is simply lines of US-ASCII characters. The + only two limitations on the body are as follows: + + o CR and LF MUST only occur together as CRLF; they MUST NOT appear + independently in the body. + o Lines of characters in the body MUST be limited to 998 characters, + and SHOULD be limited to 78 characters, excluding the CRLF. + + Note: As was stated earlier, there are other documents, + specifically the MIME documents ([RFC2045], [RFC2046], [RFC2049], + [RFC4288], [RFC4289]), that extend (and limit) this specification + to allow for different sorts of message bodies. Again, these + mechanisms are beyond the scope of this document. + + + + + + + + + + +Resnick Standards Track [Page 9] + +RFC 5322 Internet Message Format October 2008 + + +3. Syntax + +3.1. Introduction + + The syntax as given in this section defines the legal syntax of + Internet messages. Messages that are conformant to this + specification MUST conform to the syntax in this section. If there + are options in this section where one option SHOULD be generated, + that is indicated either in the prose or in a comment next to the + syntax. + + For the defined expressions, a short description of the syntax and + use is given, followed by the syntax in ABNF, followed by a semantic + analysis. The following primitive tokens that are used but otherwise + unspecified are taken from the "Core Rules" of [RFC5234], Appendix + B.1: CR, LF, CRLF, HTAB, SP, WSP, DQUOTE, DIGIT, ALPHA, and VCHAR. + + In some of the definitions, there will be non-terminals whose names + start with "obs-". These "obs-" elements refer to tokens defined in + the obsolete syntax in section 4. In all cases, these productions + are to be ignored for the purposes of generating legal Internet + messages and MUST NOT be used as part of such a message. However, + when interpreting messages, these tokens MUST be honored as part of + the legal syntax. In this sense, section 3 defines a grammar for the + generation of messages, with "obs-" elements that are to be ignored, + while section 4 adds grammar for the interpretation of messages. + +3.2. Lexical Tokens + + The following rules are used to define an underlying lexical + analyzer, which feeds tokens to the higher-level parsers. This + section defines the tokens used in structured header field bodies. + + Note: Readers of this specification need to pay special attention + to how these lexical tokens are used in both the lower-level and + higher-level syntax later in the document. Particularly, the + white space tokens and the comment tokens defined in section 3.2.2 + get used in the lower-level tokens defined here, and those lower- + level tokens are in turn used as parts of the higher-level tokens + defined later. Therefore, white space and comments may be allowed + in the higher-level tokens even though they may not explicitly + appear in a particular definition. + +3.2.1. Quoted characters + + Some characters are reserved for special interpretation, such as + delimiting lexical tokens. To permit use of these characters as + uninterpreted data, a quoting mechanism is provided. + + + +Resnick Standards Track [Page 10] + +RFC 5322 Internet Message Format October 2008 + + + quoted-pair = ("\" (VCHAR / WSP)) / obs-qp + + Where any quoted-pair appears, it is to be interpreted as the + character alone. That is to say, the "\" character that appears as + part of a quoted-pair is semantically "invisible". + + Note: The "\" character may appear in a message where it is not + part of a quoted-pair. A "\" character that does not appear in a + quoted-pair is not semantically invisible. The only places in + this specification where quoted-pair currently appears are + ccontent, qcontent, and in obs-dtext in section 4. + +3.2.2. Folding White Space and Comments + + White space characters, including white space used in folding + (described in section 2.2.3), may appear between many elements in + header field bodies. Also, strings of characters that are treated as + comments may be included in structured field bodies as characters + enclosed in parentheses. The following defines the folding white + space (FWS) and comment constructs. + + Strings of characters enclosed in parentheses are considered comments + so long as they do not appear within a "quoted-string", as defined in + section 3.2.4. Comments may nest. + + There are several places in this specification where comments and FWS + may be freely inserted. To accommodate that syntax, an additional + token for "CFWS" is defined for places where comments and/or FWS can + occur. However, where CFWS occurs in this specification, it MUST NOT + be inserted in such a way that any line of a folded header field is + made up entirely of WSP characters and nothing else. + + FWS = ([*WSP CRLF] 1*WSP) / obs-FWS + ; Folding white space + + ctext = %d33-39 / ; Printable US-ASCII + %d42-91 / ; characters not including + %d93-126 / ; "(", ")", or "\" + obs-ctext + + ccontent = ctext / quoted-pair / comment + + comment = "(" *([FWS] ccontent) [FWS] ")" + + CFWS = (1*([FWS] comment) [FWS]) / FWS + + + + + + +Resnick Standards Track [Page 11] + +RFC 5322 Internet Message Format October 2008 + + + Throughout this specification, where FWS (the folding white space + token) appears, it indicates a place where folding, as discussed in + section 2.2.3, may take place. Wherever folding appears in a message + (that is, a header field body containing a CRLF followed by any WSP), + unfolding (removal of the CRLF) is performed before any further + semantic analysis is performed on that header field according to this + specification. That is to say, any CRLF that appears in FWS is + semantically "invisible". + + A comment is normally used in a structured field body to provide some + human-readable informational text. Since a comment is allowed to + contain FWS, folding is permitted within the comment. Also note that + since quoted-pair is allowed in a comment, the parentheses and + backslash characters may appear in a comment, so long as they appear + as a quoted-pair. Semantically, the enclosing parentheses are not + part of the comment; the comment is what is contained between the two + parentheses. As stated earlier, the "\" in any quoted-pair and the + CRLF in any FWS that appears within the comment are semantically + "invisible" and therefore not part of the comment either. + + Runs of FWS, comment, or CFWS that occur between lexical tokens in a + structured header field are semantically interpreted as a single + space character. + +3.2.3. Atom + + Several productions in structured header field bodies are simply + strings of certain basic characters. Such productions are called + atoms. + + Some of the structured header field bodies also allow the period + character (".", ASCII value 46) within runs of atext. An additional + "dot-atom" token is defined for those purposes. + + Note: The "specials" token does not appear anywhere else in this + specification. It is simply the visible (i.e., non-control, non- + white space) characters that do not appear in atext. It is + provided only because it is useful for implementers who use tools + that lexically analyze messages. Each of the characters in + specials can be used to indicate a tokenization point in lexical + analysis. + + + + + + + + + + +Resnick Standards Track [Page 12] + +RFC 5322 Internet Message Format October 2008 + + + atext = ALPHA / DIGIT / ; Printable US-ASCII + "!" / "#" / ; characters not including + "$" / "%" / ; specials. Used for atoms. + "&" / "'" / + "*" / "+" / + "-" / "/" / + "=" / "?" / + "^" / "_" / + "`" / "{" / + "|" / "}" / + "~" + + atom = [CFWS] 1*atext [CFWS] + + dot-atom-text = 1*atext *("." 1*atext) + + dot-atom = [CFWS] dot-atom-text [CFWS] + + specials = "(" / ")" / ; Special characters that do + "<" / ">" / ; not appear in atext + "[" / "]" / + ":" / ";" / + "@" / "\" / + "," / "." / + DQUOTE + + Both atom and dot-atom are interpreted as a single unit, comprising + the string of characters that make it up. Semantically, the optional + comments and FWS surrounding the rest of the characters are not part + of the atom; the atom is only the run of atext characters in an atom, + or the atext and "." characters in a dot-atom. + +3.2.4. Quoted Strings + + Strings of characters that include characters other than those + allowed in atoms can be represented in a quoted string format, where + the characters are surrounded by quote (DQUOTE, ASCII value 34) + characters. + + + + + + + + + + + + + +Resnick Standards Track [Page 13] + +RFC 5322 Internet Message Format October 2008 + + + qtext = %d33 / ; Printable US-ASCII + %d35-91 / ; characters not including + %d93-126 / ; "\" or the quote character + obs-qtext + + qcontent = qtext / quoted-pair + + quoted-string = [CFWS] + DQUOTE *([FWS] qcontent) [FWS] DQUOTE + [CFWS] + + A quoted-string is treated as a unit. That is, quoted-string is + identical to atom, semantically. Since a quoted-string is allowed to + contain FWS, folding is permitted. Also note that since quoted-pair + is allowed in a quoted-string, the quote and backslash characters may + appear in a quoted-string so long as they appear as a quoted-pair. + + Semantically, neither the optional CFWS outside of the quote + characters nor the quote characters themselves are part of the + quoted-string; the quoted-string is what is contained between the two + quote characters. As stated earlier, the "\" in any quoted-pair and + the CRLF in any FWS/CFWS that appears within the quoted-string are + semantically "invisible" and therefore not part of the quoted-string + either. + +3.2.5. Miscellaneous Tokens + + Three additional tokens are defined: word and phrase for combinations + of atoms and/or quoted-strings, and unstructured for use in + unstructured header fields and in some places within structured + header fields. + + word = atom / quoted-string + + phrase = 1*word / obs-phrase + + unstructured = (*([FWS] VCHAR) *WSP) / obs-unstruct + +3.3. Date and Time Specification + + Date and time values occur in several header fields. This section + specifies the syntax for a full date and time specification. Though + folding white space is permitted throughout the date-time + specification, it is RECOMMENDED that a single space be used in each + place that FWS appears (whether it is required or optional); some + older implementations will not interpret longer sequences of folding + white space correctly. + + + + +Resnick Standards Track [Page 14] + +RFC 5322 Internet Message Format October 2008 + + + date-time = [ day-of-week "," ] date time [CFWS] + + day-of-week = ([FWS] day-name) / obs-day-of-week + + day-name = "Mon" / "Tue" / "Wed" / "Thu" / + "Fri" / "Sat" / "Sun" + + date = day month year + + day = ([FWS] 1*2DIGIT FWS) / obs-day + + month = "Jan" / "Feb" / "Mar" / "Apr" / + "May" / "Jun" / "Jul" / "Aug" / + "Sep" / "Oct" / "Nov" / "Dec" + + year = (FWS 4*DIGIT FWS) / obs-year + + time = time-of-day zone + + time-of-day = hour ":" minute [ ":" second ] + + hour = 2DIGIT / obs-hour + + minute = 2DIGIT / obs-minute + + second = 2DIGIT / obs-second + + zone = (FWS ( "+" / "-" ) 4DIGIT) / obs-zone + + The day is the numeric day of the month. The year is any numeric + year 1900 or later. + + The time-of-day specifies the number of hours, minutes, and + optionally seconds since midnight of the date indicated. + + The date and time-of-day SHOULD express local time. + + The zone specifies the offset from Coordinated Universal Time (UTC, + formerly referred to as "Greenwich Mean Time") that the date and + time-of-day represent. The "+" or "-" indicates whether the time-of- + day is ahead of (i.e., east of) or behind (i.e., west of) Universal + Time. The first two digits indicate the number of hours difference + from Universal Time, and the last two digits indicate the number of + additional minutes difference from Universal Time. (Hence, +hhmm + means +(hh * 60 + mm) minutes, and -hhmm means -(hh * 60 + mm) + minutes). The form "+0000" SHOULD be used to indicate a time zone at + Universal Time. Though "-0000" also indicates Universal Time, it is + + + + +Resnick Standards Track [Page 15] + +RFC 5322 Internet Message Format October 2008 + + + used to indicate that the time was generated on a system that may be + in a local time zone other than Universal Time and that the date-time + contains no information about the local time zone. + + A date-time specification MUST be semantically valid. That is, the + day-of-week (if included) MUST be the day implied by the date, the + numeric day-of-month MUST be between 1 and the number of days allowed + for the specified month (in the specified year), the time-of-day MUST + be in the range 00:00:00 through 23:59:60 (the number of seconds + allowing for a leap second; see [RFC1305]), and the last two digits + of the zone MUST be within the range 00 through 59. + +3.4. Address Specification + + Addresses occur in several message header fields to indicate senders + and recipients of messages. An address may either be an individual + mailbox, or a group of mailboxes. + + address = mailbox / group + + mailbox = name-addr / addr-spec + + name-addr = [display-name] angle-addr + + angle-addr = [CFWS] "<" addr-spec ">" [CFWS] / + obs-angle-addr + + group = display-name ":" [group-list] ";" [CFWS] + + display-name = phrase + + mailbox-list = (mailbox *("," mailbox)) / obs-mbox-list + + address-list = (address *("," address)) / obs-addr-list + + group-list = mailbox-list / CFWS / obs-group-list + + A mailbox receives mail. It is a conceptual entity that does not + necessarily pertain to file storage. For example, some sites may + choose to print mail on a printer and deliver the output to the + addressee's desk. + + Normally, a mailbox is composed of two parts: (1) an optional display + name that indicates the name of the recipient (which can be a person + or a system) that could be displayed to the user of a mail + application, and (2) an addr-spec address enclosed in angle brackets + + + + + +Resnick Standards Track [Page 16] + +RFC 5322 Internet Message Format October 2008 + + + ("<" and ">"). There is an alternate simple form of a mailbox where + the addr-spec address appears alone, without the recipient's name or + the angle brackets. The Internet addr-spec address is described in + section 3.4.1. + + Note: Some legacy implementations used the simple form where the + addr-spec appears without the angle brackets, but included the + name of the recipient in parentheses as a comment following the + addr-spec. Since the meaning of the information in a comment is + unspecified, implementations SHOULD use the full name-addr form of + the mailbox, instead of the legacy form, to specify the display + name associated with a mailbox. Also, because some legacy + implementations interpret the comment, comments generally SHOULD + NOT be used in address fields to avoid confusing such + implementations. + + When it is desirable to treat several mailboxes as a single unit + (i.e., in a distribution list), the group construct can be used. The + group construct allows the sender to indicate a named group of + recipients. This is done by giving a display name for the group, + followed by a colon, followed by a comma-separated list of any number + of mailboxes (including zero and one), and ending with a semicolon. + Because the list of mailboxes can be empty, using the group construct + is also a simple way to communicate to recipients that the message + was sent to one or more named sets of recipients, without actually + providing the individual mailbox address for any of those recipients. + +3.4.1. Addr-Spec Specification + + An addr-spec is a specific Internet identifier that contains a + locally interpreted string followed by the at-sign character ("@", + ASCII value 64) followed by an Internet domain. The locally + interpreted string is either a quoted-string or a dot-atom. If the + string can be represented as a dot-atom (that is, it contains no + characters other than atext characters or "." surrounded by atext + characters), then the dot-atom form SHOULD be used and the quoted- + string form SHOULD NOT be used. Comments and folding white space + SHOULD NOT be used around the "@" in the addr-spec. + + Note: A liberal syntax for the domain portion of addr-spec is + given here. However, the domain portion contains addressing + information specified by and used in other protocols (e.g., + [RFC1034], [RFC1035], [RFC1123], [RFC5321]). It is therefore + incumbent upon implementations to conform to the syntax of + addresses for the context in which they are used. + + + + + + +Resnick Standards Track [Page 17] + +RFC 5322 Internet Message Format October 2008 + + + addr-spec = local-part "@" domain + + local-part = dot-atom / quoted-string / obs-local-part + + domain = dot-atom / domain-literal / obs-domain + + domain-literal = [CFWS] "[" *([FWS] dtext) [FWS] "]" [CFWS] + + dtext = %d33-90 / ; Printable US-ASCII + %d94-126 / ; characters not including + obs-dtext ; "[", "]", or "\" + + The domain portion identifies the point to which the mail is + delivered. In the dot-atom form, this is interpreted as an Internet + domain name (either a host name or a mail exchanger name) as + described in [RFC1034], [RFC1035], and [RFC1123]. In the domain- + literal form, the domain is interpreted as the literal Internet + address of the particular host. In both cases, how addressing is + used and how messages are transported to a particular host is covered + in separate documents, such as [RFC5321]. These mechanisms are + outside of the scope of this document. + + The local-part portion is a domain-dependent string. In addresses, + it is simply interpreted on the particular host as a name of a + particular mailbox. + +3.5. Overall Message Syntax + + A message consists of header fields, optionally followed by a message + body. Lines in a message MUST be a maximum of 998 characters + excluding the CRLF, but it is RECOMMENDED that lines be limited to 78 + characters excluding the CRLF. (See section 2.1.1 for explanation.) + In a message body, though all of the characters listed in the text + rule MAY be used, the use of US-ASCII control characters (values 1 + through 8, 11, 12, and 14 through 31) is discouraged since their + interpretation by receivers for display is not guaranteed. + + message = (fields / obs-fields) + [CRLF body] + + body = (*(*998text CRLF) *998text) / obs-body + + text = %d1-9 / ; Characters excluding CR + %d11 / ; and LF + %d12 / + %d14-127 + + + + + +Resnick Standards Track [Page 18] + +RFC 5322 Internet Message Format October 2008 + + + The header fields carry most of the semantic information and are + defined in section 3.6. The body is simply a series of lines of text + that are uninterpreted for the purposes of this specification. + +3.6. Field Definitions + + The header fields of a message are defined here. All header fields + have the same general syntactic structure: a field name, followed by + a colon, followed by the field body. The specific syntax for each + header field is defined in the subsequent sections. + + Note: In the ABNF syntax for each field in subsequent sections, + each field name is followed by the required colon. However, for + brevity, sometimes the colon is not referred to in the textual + description of the syntax. It is, nonetheless, required. + + It is important to note that the header fields are not guaranteed to + be in a particular order. They may appear in any order, and they + have been known to be reordered occasionally when transported over + the Internet. However, for the purposes of this specification, + header fields SHOULD NOT be reordered when a message is transported + or transformed. More importantly, the trace header fields and resent + header fields MUST NOT be reordered, and SHOULD be kept in blocks + prepended to the message. See sections 3.6.6 and 3.6.7 for more + information. + + The only required header fields are the origination date field and + the originator address field(s). All other header fields are + syntactically optional. More information is contained in the table + following this definition. + + + + + + + + + + + + + + + + + + + + + +Resnick Standards Track [Page 19] + +RFC 5322 Internet Message Format October 2008 + + + fields = *(trace + *optional-field / + *(resent-date / + resent-from / + resent-sender / + resent-to / + resent-cc / + resent-bcc / + resent-msg-id)) + *(orig-date / + from / + sender / + reply-to / + to / + cc / + bcc / + message-id / + in-reply-to / + references / + subject / + comments / + keywords / + optional-field) + + The following table indicates limits on the number of times each + field may occur in the header section of a message as well as any + special limitations on the use of those fields. An asterisk ("*") + next to a value in the minimum or maximum column indicates that a + special restriction appears in the Notes column. + + + + + + + + + + + + + + + + + + + + + + +Resnick Standards Track [Page 20] + +RFC 5322 Internet Message Format October 2008 + + + +----------------+--------+------------+----------------------------+ + | Field | Min | Max number | Notes | + | | number | | | + +----------------+--------+------------+----------------------------+ + | trace | 0 | unlimited | Block prepended - see | + | | | | 3.6.7 | + | resent-date | 0* | unlimited* | One per block, required if | + | | | | other resent fields are | + | | | | present - see 3.6.6 | + | resent-from | 0 | unlimited* | One per block - see 3.6.6 | + | resent-sender | 0* | unlimited* | One per block, MUST occur | + | | | | with multi-address | + | | | | resent-from - see 3.6.6 | + | resent-to | 0 | unlimited* | One per block - see 3.6.6 | + | resent-cc | 0 | unlimited* | One per block - see 3.6.6 | + | resent-bcc | 0 | unlimited* | One per block - see 3.6.6 | + | resent-msg-id | 0 | unlimited* | One per block - see 3.6.6 | + | orig-date | 1 | 1 | | + | from | 1 | 1 | See sender and 3.6.2 | + | sender | 0* | 1 | MUST occur with | + | | | | multi-address from - see | + | | | | 3.6.2 | + | reply-to | 0 | 1 | | + | to | 0 | 1 | | + | cc | 0 | 1 | | + | bcc | 0 | 1 | | + | message-id | 0* | 1 | SHOULD be present - see | + | | | | 3.6.4 | + | in-reply-to | 0* | 1 | SHOULD occur in some | + | | | | replies - see 3.6.4 | + | references | 0* | 1 | SHOULD occur in some | + | | | | replies - see 3.6.4 | + | subject | 0 | 1 | | + | comments | 0 | unlimited | | + | keywords | 0 | unlimited | | + | optional-field | 0 | unlimited | | + +----------------+--------+------------+----------------------------+ + + The exact interpretation of each field is described in subsequent + sections. + + + + + + + + + + + +Resnick Standards Track [Page 21] + +RFC 5322 Internet Message Format October 2008 + + +3.6.1. The Origination Date Field + + The origination date field consists of the field name "Date" followed + by a date-time specification. + + orig-date = "Date:" date-time CRLF + + The origination date specifies the date and time at which the creator + of the message indicated that the message was complete and ready to + enter the mail delivery system. For instance, this might be the time + that a user pushes the "send" or "submit" button in an application + program. In any case, it is specifically not intended to convey the + time that the message is actually transported, but rather the time at + which the human or other creator of the message has put the message + into its final form, ready for transport. (For example, a portable + computer user who is not connected to a network might queue a message + for delivery. The origination date is intended to contain the date + and time that the user queued the message, not the time when the user + connected to the network to send the message.) + +3.6.2. Originator Fields + + The originator fields of a message consist of the from field, the + sender field (when applicable), and optionally the reply-to field. + The from field consists of the field name "From" and a comma- + separated list of one or more mailbox specifications. If the from + field contains more than one mailbox specification in the mailbox- + list, then the sender field, containing the field name "Sender" and a + single mailbox specification, MUST appear in the message. In either + case, an optional reply-to field MAY also be included, which contains + the field name "Reply-To" and a comma-separated list of one or more + addresses. + + from = "From:" mailbox-list CRLF + + sender = "Sender:" mailbox CRLF + + reply-to = "Reply-To:" address-list CRLF + + The originator fields indicate the mailbox(es) of the source of the + message. The "From:" field specifies the author(s) of the message, + that is, the mailbox(es) of the person(s) or system(s) responsible + for the writing of the message. The "Sender:" field specifies the + mailbox of the agent responsible for the actual transmission of the + message. For example, if a secretary were to send a message for + another person, the mailbox of the secretary would appear in the + "Sender:" field and the mailbox of the actual author would appear in + the "From:" field. If the originator of the message can be indicated + + + +Resnick Standards Track [Page 22] + +RFC 5322 Internet Message Format October 2008 + + + by a single mailbox and the author and transmitter are identical, the + "Sender:" field SHOULD NOT be used. Otherwise, both fields SHOULD + appear. + + Note: The transmitter information is always present. The absence + of the "Sender:" field is sometimes mistakenly taken to mean that + the agent responsible for transmission of the message has not been + specified. This absence merely means that the transmitter is + identical to the author and is therefore not redundantly placed + into the "Sender:" field. + + The originator fields also provide the information required when + replying to a message. When the "Reply-To:" field is present, it + indicates the address(es) to which the author of the message suggests + that replies be sent. In the absence of the "Reply-To:" field, + replies SHOULD by default be sent to the mailbox(es) specified in the + "From:" field unless otherwise specified by the person composing the + reply. + + In all cases, the "From:" field SHOULD NOT contain any mailbox that + does not belong to the author(s) of the message. See also section + 3.6.3 for more information on forming the destination addresses for a + reply. + +3.6.3. Destination Address Fields + + The destination fields of a message consist of three possible fields, + each of the same form: the field name, which is either "To", "Cc", or + "Bcc", followed by a comma-separated list of one or more addresses + (either mailbox or group syntax). + + to = "To:" address-list CRLF + + cc = "Cc:" address-list CRLF + + bcc = "Bcc:" [address-list / CFWS] CRLF + + The destination fields specify the recipients of the message. Each + destination field may have one or more addresses, and the addresses + indicate the intended recipients of the message. The only difference + between the three fields is how each is used. + + The "To:" field contains the address(es) of the primary recipient(s) + of the message. + + + + + + + +Resnick Standards Track [Page 23] + +RFC 5322 Internet Message Format October 2008 + + + The "Cc:" field (where the "Cc" means "Carbon Copy" in the sense of + making a copy on a typewriter using carbon paper) contains the + addresses of others who are to receive the message, though the + content of the message may not be directed at them. + + The "Bcc:" field (where the "Bcc" means "Blind Carbon Copy") contains + addresses of recipients of the message whose addresses are not to be + revealed to other recipients of the message. There are three ways in + which the "Bcc:" field is used. In the first case, when a message + containing a "Bcc:" field is prepared to be sent, the "Bcc:" line is + removed even though all of the recipients (including those specified + in the "Bcc:" field) are sent a copy of the message. In the second + case, recipients specified in the "To:" and "Cc:" lines each are sent + a copy of the message with the "Bcc:" line removed as above, but the + recipients on the "Bcc:" line get a separate copy of the message + containing a "Bcc:" line. (When there are multiple recipient + addresses in the "Bcc:" field, some implementations actually send a + separate copy of the message to each recipient with a "Bcc:" + containing only the address of that particular recipient.) Finally, + since a "Bcc:" field may contain no addresses, a "Bcc:" field can be + sent without any addresses indicating to the recipients that blind + copies were sent to someone. Which method to use with "Bcc:" fields + is implementation dependent, but refer to the "Security + Considerations" section of this document for a discussion of each. + + When a message is a reply to another message, the mailboxes of the + authors of the original message (the mailboxes in the "From:" field) + or mailboxes specified in the "Reply-To:" field (if it exists) MAY + appear in the "To:" field of the reply since these would normally be + the primary recipients of the reply. If a reply is sent to a message + that has destination fields, it is often desirable to send a copy of + the reply to all of the recipients of the message, in addition to the + author. When such a reply is formed, addresses in the "To:" and + "Cc:" fields of the original message MAY appear in the "Cc:" field of + the reply, since these are normally secondary recipients of the + reply. If a "Bcc:" field is present in the original message, + addresses in that field MAY appear in the "Bcc:" field of the reply, + but they SHOULD NOT appear in the "To:" or "Cc:" fields. + + Note: Some mail applications have automatic reply commands that + include the destination addresses of the original message in the + destination addresses of the reply. How those reply commands + behave is implementation dependent and is beyond the scope of this + document. In particular, whether or not to include the original + destination addresses when the original message had a "Reply-To:" + field is not addressed here. + + + + + +Resnick Standards Track [Page 24] + +RFC 5322 Internet Message Format October 2008 + + +3.6.4. Identification Fields + + Though listed as optional in the table in section 3.6, every message + SHOULD have a "Message-ID:" field. Furthermore, reply messages + SHOULD have "In-Reply-To:" and "References:" fields as appropriate + and as described below. + + The "Message-ID:" field contains a single unique message identifier. + The "References:" and "In-Reply-To:" fields each contain one or more + unique message identifiers, optionally separated by CFWS. + + The message identifier (msg-id) syntax is a limited version of the + addr-spec construct enclosed in the angle bracket characters, "<" and + ">". Unlike addr-spec, this syntax only permits the dot-atom-text + form on the left-hand side of the "@" and does not have internal CFWS + anywhere in the message identifier. + + Note: As with addr-spec, a liberal syntax is given for the right- + hand side of the "@" in a msg-id. However, later in this section, + the use of a domain for the right-hand side of the "@" is + RECOMMENDED. Again, the syntax of domain constructs is specified + by and used in other protocols (e.g., [RFC1034], [RFC1035], + [RFC1123], [RFC5321]). It is therefore incumbent upon + implementations to conform to the syntax of addresses for the + context in which they are used. + + message-id = "Message-ID:" msg-id CRLF + + in-reply-to = "In-Reply-To:" 1*msg-id CRLF + + references = "References:" 1*msg-id CRLF + + msg-id = [CFWS] "<" id-left "@" id-right ">" [CFWS] + + id-left = dot-atom-text / obs-id-left + + id-right = dot-atom-text / no-fold-literal / obs-id-right + + no-fold-literal = "[" *dtext "]" + + The "Message-ID:" field provides a unique message identifier that + refers to a particular version of a particular message. The + uniqueness of the message identifier is guaranteed by the host that + generates it (see below). This message identifier is intended to be + machine readable and not necessarily meaningful to humans. A message + identifier pertains to exactly one version of a particular message; + subsequent revisions to the message each receive new message + identifiers. + + + +Resnick Standards Track [Page 25] + +RFC 5322 Internet Message Format October 2008 + + + Note: There are many instances when messages are "changed", but + those changes do not constitute a new instantiation of that + message, and therefore the message would not get a new message + identifier. For example, when messages are introduced into the + transport system, they are often prepended with additional header + fields such as trace fields (described in section 3.6.7) and + resent fields (described in section 3.6.6). The addition of such + header fields does not change the identity of the message and + therefore the original "Message-ID:" field is retained. In all + cases, it is the meaning that the sender of the message wishes to + convey (i.e., whether this is the same message or a different + message) that determines whether or not the "Message-ID:" field + changes, not any particular syntactic difference that appears (or + does not appear) in the message. + + The "In-Reply-To:" and "References:" fields are used when creating a + reply to a message. They hold the message identifier of the original + message and the message identifiers of other messages (for example, + in the case of a reply to a message that was itself a reply). The + "In-Reply-To:" field may be used to identify the message (or + messages) to which the new message is a reply, while the + "References:" field may be used to identify a "thread" of + conversation. + + When creating a reply to a message, the "In-Reply-To:" and + "References:" fields of the resultant message are constructed as + follows: + + The "In-Reply-To:" field will contain the contents of the + "Message-ID:" field of the message to which this one is a reply (the + "parent message"). If there is more than one parent message, then + the "In-Reply-To:" field will contain the contents of all of the + parents' "Message-ID:" fields. If there is no "Message-ID:" field in + any of the parent messages, then the new message will have no "In- + Reply-To:" field. + + The "References:" field will contain the contents of the parent's + "References:" field (if any) followed by the contents of the parent's + "Message-ID:" field (if any). If the parent message does not contain + a "References:" field but does have an "In-Reply-To:" field + containing a single message identifier, then the "References:" field + will contain the contents of the parent's "In-Reply-To:" field + followed by the contents of the parent's "Message-ID:" field (if + any). If the parent has none of the "References:", "In-Reply-To:", + or "Message-ID:" fields, then the new message will have no + "References:" field. + + + + + +Resnick Standards Track [Page 26] + +RFC 5322 Internet Message Format October 2008 + + + Note: Some implementations parse the "References:" field to + display the "thread of the discussion". These implementations + assume that each new message is a reply to a single parent and + hence that they can walk backwards through the "References:" field + to find the parent of each message listed there. Therefore, + trying to form a "References:" field for a reply that has multiple + parents is discouraged; how to do so is not defined in this + document. + + The message identifier (msg-id) itself MUST be a globally unique + identifier for a message. The generator of the message identifier + MUST guarantee that the msg-id is unique. There are several + algorithms that can be used to accomplish this. Since the msg-id has + a similar syntax to addr-spec (identical except that quoted strings, + comments, and folding white space are not allowed), a good method is + to put the domain name (or a domain literal IP address) of the host + on which the message identifier was created on the right-hand side of + the "@" (since domain names and IP addresses are normally unique), + and put a combination of the current absolute date and time along + with some other currently unique (perhaps sequential) identifier + available on the system (for example, a process id number) on the + left-hand side. Though other algorithms will work, it is RECOMMENDED + that the right-hand side contain some domain identifier (either of + the host itself or otherwise) such that the generator of the message + identifier can guarantee the uniqueness of the left-hand side within + the scope of that domain. + + Semantically, the angle bracket characters are not part of the + msg-id; the msg-id is what is contained between the two angle bracket + characters. + +3.6.5. Informational Fields + + The informational fields are all optional. The "Subject:" and + "Comments:" fields are unstructured fields as defined in section + 2.2.1, and therefore may contain text or folding white space. The + "Keywords:" field contains a comma-separated list of one or more + words or quoted-strings. + + subject = "Subject:" unstructured CRLF + + comments = "Comments:" unstructured CRLF + + keywords = "Keywords:" phrase *("," phrase) CRLF + + These three fields are intended to have only human-readable content + with information about the message. The "Subject:" field is the most + common and contains a short string identifying the topic of the + + + +Resnick Standards Track [Page 27] + +RFC 5322 Internet Message Format October 2008 + + + message. When used in a reply, the field body MAY start with the + string "Re: " (an abbreviation of the Latin "in re", meaning "in the + matter of") followed by the contents of the "Subject:" field body of + the original message. If this is done, only one instance of the + literal string "Re: " ought to be used since use of other strings or + more than one instance can lead to undesirable consequences. The + "Comments:" field contains any additional comments on the text of the + body of the message. The "Keywords:" field contains a comma- + separated list of important words and phrases that might be useful + for the recipient. + +3.6.6. Resent Fields + + Resent fields SHOULD be added to any message that is reintroduced by + a user into the transport system. A separate set of resent fields + SHOULD be added each time this is done. All of the resent fields + corresponding to a particular resending of the message SHOULD be + grouped together. Each new set of resent fields is prepended to the + message; that is, the most recent set of resent fields appears + earlier in the message. No other fields in the message are changed + when resent fields are added. + + Each of the resent fields corresponds to a particular field elsewhere + in the syntax. For instance, the "Resent-Date:" field corresponds to + the "Date:" field and the "Resent-To:" field corresponds to the "To:" + field. In each case, the syntax for the field body is identical to + the syntax given previously for the corresponding field. + + When resent fields are used, the "Resent-From:" and "Resent-Date:" + fields MUST be sent. The "Resent-Message-ID:" field SHOULD be sent. + "Resent-Sender:" SHOULD NOT be used if "Resent-Sender:" would be + identical to "Resent-From:". + + resent-date = "Resent-Date:" date-time CRLF + + resent-from = "Resent-From:" mailbox-list CRLF + + resent-sender = "Resent-Sender:" mailbox CRLF + + resent-to = "Resent-To:" address-list CRLF + + resent-cc = "Resent-Cc:" address-list CRLF + + resent-bcc = "Resent-Bcc:" [address-list / CFWS] CRLF + + resent-msg-id = "Resent-Message-ID:" msg-id CRLF + + + + + +Resnick Standards Track [Page 28] + +RFC 5322 Internet Message Format October 2008 + + + Resent fields are used to identify a message as having been + reintroduced into the transport system by a user. The purpose of + using resent fields is to have the message appear to the final + recipient as if it were sent directly by the original sender, with + all of the original fields remaining the same. Each set of resent + fields correspond to a particular resending event. That is, if a + message is resent multiple times, each set of resent fields gives + identifying information for each individual time. Resent fields are + strictly informational. They MUST NOT be used in the normal + processing of replies or other such automatic actions on messages. + + Note: Reintroducing a message into the transport system and using + resent fields is a different operation from "forwarding". + "Forwarding" has two meanings: One sense of forwarding is that a + mail reading program can be told by a user to forward a copy of a + message to another person, making the forwarded message the body + of the new message. A forwarded message in this sense does not + appear to have come from the original sender, but is an entirely + new message from the forwarder of the message. Forwarding may + also mean that a mail transport program gets a message and + forwards it on to a different destination for final delivery. + Resent header fields are not intended for use with either type of + forwarding. + + The resent originator fields indicate the mailbox of the person(s) or + system(s) that resent the message. As with the regular originator + fields, there are two forms: a simple "Resent-From:" form, which + contains the mailbox of the individual doing the resending, and the + more complex form, when one individual (identified in the "Resent- + Sender:" field) resends a message on behalf of one or more others + (identified in the "Resent-From:" field). + + Note: When replying to a resent message, replies behave just as + they would with any other message, using the original "From:", + "Reply-To:", "Message-ID:", and other fields. The resent fields + are only informational and MUST NOT be used in the normal + processing of replies. + + The "Resent-Date:" indicates the date and time at which the resent + message is dispatched by the resender of the message. Like the + "Date:" field, it is not the date and time that the message was + actually transported. + + The "Resent-To:", "Resent-Cc:", and "Resent-Bcc:" fields function + identically to the "To:", "Cc:", and "Bcc:" fields, respectively, + except that they indicate the recipients of the resent message, not + the recipients of the original message. + + + + +Resnick Standards Track [Page 29] + +RFC 5322 Internet Message Format October 2008 + + + The "Resent-Message-ID:" field provides a unique identifier for the + resent message. + +3.6.7. Trace Fields + + The trace fields are a group of header fields consisting of an + optional "Return-Path:" field, and one or more "Received:" fields. + The "Return-Path:" header field contains a pair of angle brackets + that enclose an optional addr-spec. The "Received:" field contains a + (possibly empty) list of tokens followed by a semicolon and a date- + time specification. Each token must be a word, angle-addr, addr- + spec, or a domain. Further restrictions are applied to the syntax of + the trace fields by specifications that provide for their use, such + as [RFC5321]. + + trace = [return] + 1*received + + return = "Return-Path:" path CRLF + + path = angle-addr / ([CFWS] "<" [CFWS] ">" [CFWS]) + + received = "Received:" *received-token ";" date-time CRLF + + received-token = word / angle-addr / addr-spec / domain + + A full discussion of the Internet mail use of trace fields is + contained in [RFC5321]. For the purposes of this specification, the + trace fields are strictly informational, and any formal + interpretation of them is outside of the scope of this document. + +3.6.8. Optional Fields + + Fields may appear in messages that are otherwise unspecified in this + document. They MUST conform to the syntax of an optional-field. + This is a field name, made up of the printable US-ASCII characters + except SP and colon, followed by a colon, followed by any text that + conforms to the unstructured syntax. + + The field names of any optional field MUST NOT be identical to any + field name specified elsewhere in this document. + + + + + + + + + + +Resnick Standards Track [Page 30] + +RFC 5322 Internet Message Format October 2008 + + + optional-field = field-name ":" unstructured CRLF + + field-name = 1*ftext + + ftext = %d33-57 / ; Printable US-ASCII + %d59-126 ; characters not including + ; ":". + + For the purposes of this specification, any optional field is + uninterpreted. + +4. Obsolete Syntax + + Earlier versions of this specification allowed for different (usually + more liberal) syntax than is allowed in this version. Also, there + have been syntactic elements used in messages on the Internet whose + interpretations have never been documented. Though these syntactic + forms MUST NOT be generated according to the grammar in section 3, + they MUST be accepted and parsed by a conformant receiver. This + section documents many of these syntactic elements. Taking the + grammar in section 3 and adding the definitions presented in this + section will result in the grammar to use for the interpretation of + messages. + + Note: This section identifies syntactic forms that any + implementation MUST reasonably interpret. However, there are + certainly Internet messages that do not conform to even the + additional syntax given in this section. The fact that a + particular form does not appear in any section of this document is + not justification for computer programs to crash or for malformed + data to be irretrievably lost by any implementation. It is up to + the implementation to deal with messages robustly. + + One important difference between the obsolete (interpreting) and the + current (generating) syntax is that in structured header field bodies + (i.e., between the colon and the CRLF of any structured header + field), white space characters, including folding white space, and + comments could be freely inserted between any syntactic tokens. This + allowed many complex forms that have proven difficult for some + implementations to parse. + + Another key difference between the obsolete and the current syntax is + that the rule in section 3.2.2 regarding lines composed entirely of + white space in comments and folding white space does not apply. See + the discussion of folding white space in section 4.2 below. + + Finally, certain characters that were formerly allowed in messages + appear in this section. The NUL character (ASCII value 0) was once + + + +Resnick Standards Track [Page 31] + +RFC 5322 Internet Message Format October 2008 + + + allowed, but is no longer for compatibility reasons. Similarly, US- + ASCII control characters other than CR, LF, SP, and HTAB (ASCII + values 1 through 8, 11, 12, 14 through 31, and 127) were allowed to + appear in header field bodies. CR and LF were allowed to appear in + messages other than as CRLF; this use is also shown here. + + Other differences in syntax and semantics are noted in the following + sections. + +4.1. Miscellaneous Obsolete Tokens + + These syntactic elements are used elsewhere in the obsolete syntax or + in the main syntax. Bare CR, bare LF, and NUL are added to obs-qp, + obs-body, and obs-unstruct. US-ASCII control characters are added to + obs-qp, obs-unstruct, obs-ctext, and obs-qtext. The period character + is added to obs-phrase. The obs-phrase-list provides for a + (potentially empty) comma-separated list of phrases that may include + "null" elements. That is, there could be two or more commas in such + a list with nothing in between them, or commas at the beginning or + end of the list. + + Note: The "period" (or "full stop") character (".") in obs-phrase + is not a form that was allowed in earlier versions of this or any + other specification. Period (nor any other character from + specials) was not allowed in phrase because it introduced a + parsing difficulty distinguishing between phrases and portions of + an addr-spec (see section 4.4). It appears here because the + period character is currently used in many messages in the + display-name portion of addresses, especially for initials in + names, and therefore must be interpreted properly. + + obs-NO-WS-CTL = %d1-8 / ; US-ASCII control + %d11 / ; characters that do not + %d12 / ; include the carriage + %d14-31 / ; return, line feed, and + %d127 ; white space characters + + obs-ctext = obs-NO-WS-CTL + + obs-qtext = obs-NO-WS-CTL + + obs-utext = %d0 / obs-NO-WS-CTL / VCHAR + + obs-qp = "\" (%d0 / obs-NO-WS-CTL / LF / CR) + + obs-body = *((*LF *CR *((%d0 / text) *LF *CR)) / CRLF) + + obs-unstruct = *((*LF *CR *(obs-utext *LF *CR)) / FWS) + + + +Resnick Standards Track [Page 32] + +RFC 5322 Internet Message Format October 2008 + + + obs-phrase = word *(word / "." / CFWS) + + obs-phrase-list = [phrase / CFWS] *("," [phrase / CFWS]) + + Bare CR and bare LF appear in messages with two different meanings. + In many cases, bare CR or bare LF are used improperly instead of CRLF + to indicate line separators. In other cases, bare CR and bare LF are + used simply as US-ASCII control characters with their traditional + ASCII meanings. + +4.2. Obsolete Folding White Space + + In the obsolete syntax, any amount of folding white space MAY be + inserted where the obs-FWS rule is allowed. This creates the + possibility of having two consecutive "folds" in a line, and + therefore the possibility that a line which makes up a folded header + field could be composed entirely of white space. + + obs-FWS = 1*WSP *(CRLF 1*WSP) + +4.3. Obsolete Date and Time + + The syntax for the obsolete date format allows a 2 digit year in the + date field and allows for a list of alphabetic time zone specifiers + that were used in earlier versions of this specification. It also + permits comments and folding white space between many of the tokens. + + obs-day-of-week = [CFWS] day-name [CFWS] + + obs-day = [CFWS] 1*2DIGIT [CFWS] + + obs-year = [CFWS] 2*DIGIT [CFWS] + + obs-hour = [CFWS] 2DIGIT [CFWS] + + obs-minute = [CFWS] 2DIGIT [CFWS] + + obs-second = [CFWS] 2DIGIT [CFWS] + + obs-zone = "UT" / "GMT" / ; Universal Time + ; North American UT + ; offsets + "EST" / "EDT" / ; Eastern: - 5/ - 4 + "CST" / "CDT" / ; Central: - 6/ - 5 + "MST" / "MDT" / ; Mountain: - 7/ - 6 + "PST" / "PDT" / ; Pacific: - 8/ - 7 + ; + + + + +Resnick Standards Track [Page 33] + +RFC 5322 Internet Message Format October 2008 + + + %d65-73 / ; Military zones - "A" + %d75-90 / ; through "I" and "K" + %d97-105 / ; through "Z", both + %d107-122 ; upper and lower case + + Where a two or three digit year occurs in a date, the year is to be + interpreted as follows: If a two digit year is encountered whose + value is between 00 and 49, the year is interpreted by adding 2000, + ending up with a value between 2000 and 2049. If a two digit year is + encountered with a value between 50 and 99, or any three digit year + is encountered, the year is interpreted by adding 1900. + + In the obsolete time zone, "UT" and "GMT" are indications of + "Universal Time" and "Greenwich Mean Time", respectively, and are + both semantically identical to "+0000". + + The remaining three character zones are the US time zones. The first + letter, "E", "C", "M", or "P" stands for "Eastern", "Central", + "Mountain", and "Pacific". The second letter is either "S" for + "Standard" time, or "D" for "Daylight Savings" (or summer) time. + Their interpretations are as follows: + + EDT is semantically equivalent to -0400 + EST is semantically equivalent to -0500 + CDT is semantically equivalent to -0500 + CST is semantically equivalent to -0600 + MDT is semantically equivalent to -0600 + MST is semantically equivalent to -0700 + PDT is semantically equivalent to -0700 + PST is semantically equivalent to -0800 + + The 1 character military time zones were defined in a non-standard + way in [RFC0822] and are therefore unpredictable in their meaning. + The original definitions of the military zones "A" through "I" are + equivalent to "+0100" through "+0900", respectively; "K", "L", and + "M" are equivalent to "+1000", "+1100", and "+1200", respectively; + "N" through "Y" are equivalent to "-0100" through "-1200". + respectively; and "Z" is equivalent to "+0000". However, because of + the error in [RFC0822], they SHOULD all be considered equivalent to + "-0000" unless there is out-of-band information confirming their + meaning. + + Other multi-character (usually between 3 and 5) alphabetic time zones + have been used in Internet messages. Any such time zone whose + meaning is not known SHOULD be considered equivalent to "-0000" + unless there is out-of-band information confirming their meaning. + + + + + +Resnick Standards Track [Page 34] + +RFC 5322 Internet Message Format October 2008 + + +4.4. Obsolete Addressing + + There are four primary differences in addressing. First, mailbox + addresses were allowed to have a route portion before the addr-spec + when enclosed in "<" and ">". The route is simply a comma-separated + list of domain names, each preceded by "@", and the list terminated + by a colon. Second, CFWS were allowed between the period-separated + elements of local-part and domain (i.e., dot-atom was not used). In + addition, local-part is allowed to contain quoted-string in addition + to just atom. Third, mailbox-list and address-list were allowed to + have "null" members. That is, there could be two or more commas in + such a list with nothing in between them, or commas at the beginning + or end of the list. Finally, US-ASCII control characters and quoted- + pairs were allowed in domain literals and are added here. + + obs-angle-addr = [CFWS] "<" obs-route addr-spec ">" [CFWS] + + obs-route = obs-domain-list ":" + + obs-domain-list = *(CFWS / ",") "@" domain + *("," [CFWS] ["@" domain]) + + obs-mbox-list = *([CFWS] ",") mailbox *("," [mailbox / CFWS]) + + obs-addr-list = *([CFWS] ",") address *("," [address / CFWS]) + + obs-group-list = 1*([CFWS] ",") [CFWS] + + obs-local-part = word *("." word) + + obs-domain = atom *("." atom) + + obs-dtext = obs-NO-WS-CTL / quoted-pair + + When interpreting addresses, the route portion SHOULD be ignored. + +4.5. Obsolete Header Fields + + Syntactically, the primary difference in the obsolete field syntax is + that it allows multiple occurrences of any of the fields and they may + occur in any order. Also, any amount of white space is allowed + before the ":" at the end of the field name. + + + + + + + + + +Resnick Standards Track [Page 35] + +RFC 5322 Internet Message Format October 2008 + + + obs-fields = *(obs-return / + obs-received / + obs-orig-date / + obs-from / + obs-sender / + obs-reply-to / + obs-to / + obs-cc / + obs-bcc / + obs-message-id / + obs-in-reply-to / + obs-references / + obs-subject / + obs-comments / + obs-keywords / + obs-resent-date / + obs-resent-from / + obs-resent-send / + obs-resent-rply / + obs-resent-to / + obs-resent-cc / + obs-resent-bcc / + obs-resent-mid / + obs-optional) + + Except for destination address fields (described in section 4.5.3), + the interpretation of multiple occurrences of fields is unspecified. + Also, the interpretation of trace fields and resent fields that do + not occur in blocks prepended to the message is unspecified as well. + Unless otherwise noted in the following sections, interpretation of + other fields is identical to the interpretation of their non-obsolete + counterparts in section 3. + +4.5.1. Obsolete Origination Date Field + + obs-orig-date = "Date" *WSP ":" date-time CRLF + +4.5.2. Obsolete Originator Fields + + obs-from = "From" *WSP ":" mailbox-list CRLF + + obs-sender = "Sender" *WSP ":" mailbox CRLF + + obs-reply-to = "Reply-To" *WSP ":" address-list CRLF + + + + + + + +Resnick Standards Track [Page 36] + +RFC 5322 Internet Message Format October 2008 + + +4.5.3. Obsolete Destination Address Fields + + obs-to = "To" *WSP ":" address-list CRLF + + obs-cc = "Cc" *WSP ":" address-list CRLF + + obs-bcc = "Bcc" *WSP ":" + (address-list / (*([CFWS] ",") [CFWS])) CRLF + + When multiple occurrences of destination address fields occur in a + message, they SHOULD be treated as if the address list in the first + occurrence of the field is combined with the address lists of the + subsequent occurrences by adding a comma and concatenating. + +4.5.4. Obsolete Identification Fields + + The obsolete "In-Reply-To:" and "References:" fields differ from the + current syntax in that they allow phrase (words or quoted strings) to + appear. The obsolete forms of the left and right sides of msg-id + allow interspersed CFWS, making them syntactically identical to + local-part and domain, respectively. + + obs-message-id = "Message-ID" *WSP ":" msg-id CRLF + + obs-in-reply-to = "In-Reply-To" *WSP ":" *(phrase / msg-id) CRLF + + obs-references = "References" *WSP ":" *(phrase / msg-id) CRLF + + obs-id-left = local-part + + obs-id-right = domain + + For purposes of interpretation, the phrases in the "In-Reply-To:" and + "References:" fields are ignored. + + Semantically, none of the optional CFWS in the local-part and the + domain is part of the obs-id-left and obs-id-right, respectively. + +4.5.5. Obsolete Informational Fields + + obs-subject = "Subject" *WSP ":" unstructured CRLF + + obs-comments = "Comments" *WSP ":" unstructured CRLF + + obs-keywords = "Keywords" *WSP ":" obs-phrase-list CRLF + + + + + + +Resnick Standards Track [Page 37] + +RFC 5322 Internet Message Format October 2008 + + +4.5.6. Obsolete Resent Fields + + The obsolete syntax adds a "Resent-Reply-To:" field, which consists + of the field name, the optional comments and folding white space, the + colon, and a comma separated list of addresses. + + obs-resent-from = "Resent-From" *WSP ":" mailbox-list CRLF + + obs-resent-send = "Resent-Sender" *WSP ":" mailbox CRLF + + obs-resent-date = "Resent-Date" *WSP ":" date-time CRLF + + obs-resent-to = "Resent-To" *WSP ":" address-list CRLF + + obs-resent-cc = "Resent-Cc" *WSP ":" address-list CRLF + + obs-resent-bcc = "Resent-Bcc" *WSP ":" + (address-list / (*([CFWS] ",") [CFWS])) CRLF + + obs-resent-mid = "Resent-Message-ID" *WSP ":" msg-id CRLF + + obs-resent-rply = "Resent-Reply-To" *WSP ":" address-list CRLF + + As with other resent fields, the "Resent-Reply-To:" field is to be + treated as trace information only. + +4.5.7. Obsolete Trace Fields + + The obs-return and obs-received are again given here as template + definitions, just as return and received are in section 3. Their + full syntax is given in [RFC5321]. + + obs-return = "Return-Path" *WSP ":" path CRLF + + obs-received = "Received" *WSP ":" *received-token CRLF + +4.5.8. Obsolete optional fields + + obs-optional = field-name *WSP ":" unstructured CRLF + +5. Security Considerations + + Care needs to be taken when displaying messages on a terminal or + terminal emulator. Powerful terminals may act on escape sequences + and other combinations of US-ASCII control characters with a variety + of consequences. They can remap the keyboard or permit other + modifications to the terminal that could lead to denial of service or + even damaged data. They can trigger (sometimes programmable) + + + +Resnick Standards Track [Page 38] + +RFC 5322 Internet Message Format October 2008 + + + answerback messages that can allow a message to cause commands to be + issued on the recipient's behalf. They can also affect the operation + of terminal attached devices such as printers. Message viewers may + wish to strip potentially dangerous terminal escape sequences from + the message prior to display. However, other escape sequences appear + in messages for useful purposes (cf. [ISO.2022.1994], [RFC2045], + [RFC2046], [RFC2047], [RFC2049], [RFC4288], [RFC4289]) and therefore + should not be stripped indiscriminately. + + Transmission of non-text objects in messages raises additional + security issues. These issues are discussed in [RFC2045], [RFC2046], + [RFC2047], [RFC2049], [RFC4288], and [RFC4289]. + + Many implementations use the "Bcc:" (blind carbon copy) field, + described in section 3.6.3, to facilitate sending messages to + recipients without revealing the addresses of one or more of the + addressees to the other recipients. Mishandling this use of "Bcc:" + may disclose confidential information that could eventually lead to + security problems through knowledge of even the existence of a + particular mail address. For example, if using the first method + described in section 3.6.3, where the "Bcc:" line is removed from the + message, blind recipients have no explicit indication that they have + been sent a blind copy, except insofar as their address does not + appear in the header section of a message. Because of this, one of + the blind addressees could potentially send a reply to all of the + shown recipients and accidentally reveal that the message went to the + blind recipient. When the second method from section 3.6.3 is used, + the blind recipient's address appears in the "Bcc:" field of a + separate copy of the message. If the "Bcc:" field sent contains all + of the blind addressees, all of the "Bcc:" recipients will be seen by + each "Bcc:" recipient. Even if a separate message is sent to each + "Bcc:" recipient with only the individual's address, implementations + still need to be careful to process replies to the message as per + section 3.6.3 so as not to accidentally reveal the blind recipient to + other recipients. + +6. IANA Considerations + + This document updates the registrations that appeared in [RFC4021] + that referred to the definitions in [RFC2822]. IANA has updated the + Permanent Message Header Field Repository with the following header + fields, in accordance with the procedures set out in [RFC3864]. + + Header field name: Date + Applicable protocol: Mail + Status: standard + Author/Change controller: IETF + Specification document(s): This document (section 3.6.1) + + + +Resnick Standards Track [Page 39] + +RFC 5322 Internet Message Format October 2008 + + + Header field name: From + Applicable protocol: Mail + Status: standard + Author/Change controller: IETF + Specification document(s): This document (section 3.6.2) + + Header field name: Sender + Applicable protocol: Mail + Status: standard + Author/Change controller: IETF + Specification document(s): This document (section 3.6.2) + + Header field name: Reply-To + Applicable protocol: Mail + Status: standard + Author/Change controller: IETF + Specification document(s): This document (section 3.6.2) + + Header field name: To + Applicable protocol: Mail + Status: standard + Author/Change controller: IETF + Specification document(s): This document (section 3.6.3) + + Header field name: Cc + Applicable protocol: Mail + Status: standard + Author/Change controller: IETF + Specification document(s): This document (section 3.6.3) + + Header field name: Bcc + Applicable protocol: Mail + Status: standard + Author/Change controller: IETF + Specification document(s): This document (section 3.6.3) + + Header field name: Message-ID + Applicable protocol: Mail + Status: standard + Author/Change controller: IETF + Specification document(s): This document (section 3.6.4) + + Header field name: In-Reply-To + Applicable protocol: Mail + Status: standard + Author/Change controller: IETF + Specification document(s): This document (section 3.6.4) + + + + +Resnick Standards Track [Page 40] + +RFC 5322 Internet Message Format October 2008 + + + Header field name: References + Applicable protocol: Mail + Status: standard + Author/Change controller: IETF + Specification document(s): This document (section 3.6.4) + + Header field name: Subject + Applicable protocol: Mail + Status: standard + Author/Change controller: IETF + Specification document(s): This document (section 3.6.5) + + Header field name: Comments + Applicable protocol: Mail + Status: standard + Author/Change controller: IETF + Specification document(s): This document (section 3.6.5) + + Header field name: Keywords + Applicable protocol: Mail + Status: standard + Author/Change controller: IETF + Specification document(s): This document (section 3.6.5) + + Header field name: Resent-Date + Applicable protocol: Mail + Status: standard + Author/Change controller: IETF + Specification document(s): This document (section 3.6.6) + + Header field name: Resent-From + Applicable protocol: Mail + Status: standard + Author/Change controller: IETF + Specification document(s): This document (section 3.6.6) + + Header field name: Resent-Sender + Applicable protocol: Mail + Status: standard + Author/Change controller: IETF + Specification document(s): This document (section 3.6.6) + + Header field name: Resent-To + Applicable protocol: Mail + Status: standard + Author/Change controller: IETF + Specification document(s): This document (section 3.6.6) + + + + +Resnick Standards Track [Page 41] + +RFC 5322 Internet Message Format October 2008 + + + Header field name: Resent-Cc + Applicable protocol: Mail + Status: standard + Author/Change controller: IETF + Specification document(s): This document (section 3.6.6) + + Header field name: Resent-Bcc + Applicable protocol: Mail + Status: standard + Author/Change controller: IETF + Specification document(s): This document (section 3.6.6) + + Header field name: Resent-Reply-To + Applicable protocol: Mail + Status: obsolete + Author/Change controller: IETF + Specification document(s): This document (section 4.5.6) + + Header field name: Resent-Message-ID + Applicable protocol: Mail + Status: standard + Author/Change controller: IETF + Specification document(s): This document (section 3.6.6) + + Header field name: Return-Path + Applicable protocol: Mail + Status: standard + Author/Change controller: IETF + Specification document(s): This document (section 3.6.7) + + Header field name: Received + Applicable protocol: Mail + Status: standard + Author/Change controller: IETF + Specification document(s): This document (section 3.6.7) + Related information: [RFC5321] + + + + + + + + + + + + + + + +Resnick Standards Track [Page 42] + +RFC 5322 Internet Message Format October 2008 + + +Appendix A. Example Messages + + This section presents a selection of messages. These are intended to + assist in the implementation of this specification, but should not be + taken as normative; that is to say, although the examples in this + section were carefully reviewed, if there happens to be a conflict + between these examples and the syntax described in sections 3 and 4 + of this document, the syntax in those sections is to be taken as + correct. + + In the text version of this document, messages in this section are + delimited between lines of "----". The "----" lines are not part of + the message itself. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Resnick Standards Track [Page 43] + +RFC 5322 Internet Message Format October 2008 + + +Appendix A.1. Addressing Examples + + The following are examples of messages that might be sent between two + individuals. + +Appendix A.1.1. A Message from One Person to Another with Simple + Addressing + + This could be called a canonical message. It has a single author, + John Doe, a single recipient, Mary Smith, a subject, the date, a + message identifier, and a textual message in the body. + + ---- + From: John Doe + To: Mary Smith + Subject: Saying Hello + Date: Fri, 21 Nov 1997 09:55:06 -0600 + Message-ID: <1234@local.machine.example> + + This is a message just to say hello. + So, "Hello". + ---- + + If John's secretary Michael actually sent the message, even though + John was the author and replies to this message should go back to + him, the sender field would be used: + + ---- + From: John Doe + Sender: Michael Jones + To: Mary Smith + Subject: Saying Hello + Date: Fri, 21 Nov 1997 09:55:06 -0600 + Message-ID: <1234@local.machine.example> + + This is a message just to say hello. + So, "Hello". + ---- + + + + + + + + + + + + + +Resnick Standards Track [Page 44] + +RFC 5322 Internet Message Format October 2008 + + +Appendix A.1.2. Different Types of Mailboxes + + This message includes multiple addresses in the destination fields + and also uses several different forms of addresses. + + ---- + From: "Joe Q. Public" + To: Mary Smith , jdoe@example.org, Who? + Cc: , "Giant; \"Big\" Box" + Date: Tue, 1 Jul 2003 10:52:37 +0200 + Message-ID: <5678.21-Nov-1997@example.com> + + Hi everyone. + ---- + + Note that the display names for Joe Q. Public and Giant; "Big" Box + needed to be enclosed in double-quotes because the former contains + the period and the latter contains both semicolon and double-quote + characters (the double-quote characters appearing as quoted-pair + constructs). Conversely, the display name for Who? could appear + without them because the question mark is legal in an atom. Notice + also that jdoe@example.org and boss@nil.test have no display names + associated with them at all, and jdoe@example.org uses the simpler + address form without the angle brackets. + +Appendix A.1.3. Group Addresses + + ---- + From: Pete + To: A Group:Ed Jones ,joe@where.test,John ; + Cc: Undisclosed recipients:; + Date: Thu, 13 Feb 1969 23:32:54 -0330 + Message-ID: + + Testing. + ---- + + In this message, the "To:" field has a single group recipient named + "A Group", which contains 3 addresses, and a "Cc:" field with an + empty group recipient named Undisclosed recipients. + + + + + + + + + + + +Resnick Standards Track [Page 45] + +RFC 5322 Internet Message Format October 2008 + + +Appendix A.2. Reply Messages + + The following is a series of three messages that make up a + conversation thread between John and Mary. John first sends a + message to Mary, Mary then replies to John's message, and then John + replies to Mary's reply message. + + Note especially the "Message-ID:", "References:", and "In-Reply-To:" + fields in each message. + + ---- + From: John Doe + To: Mary Smith + Subject: Saying Hello + Date: Fri, 21 Nov 1997 09:55:06 -0600 + Message-ID: <1234@local.machine.example> + + This is a message just to say hello. + So, "Hello". + ---- + + When sending replies, the Subject field is often retained, though + prepended with "Re: " as described in section 3.6.5. + + ---- + From: Mary Smith + To: John Doe + Reply-To: "Mary Smith: Personal Account" + Subject: Re: Saying Hello + Date: Fri, 21 Nov 1997 10:01:10 -0600 + Message-ID: <3456@example.net> + In-Reply-To: <1234@local.machine.example> + References: <1234@local.machine.example> + + This is a reply to your hello. + ---- + + Note the "Reply-To:" field in the above message. When John replies + to Mary's message above, the reply should go to the address in the + "Reply-To:" field instead of the address in the "From:" field. + + + + + + + + + + + +Resnick Standards Track [Page 46] + +RFC 5322 Internet Message Format October 2008 + + + ---- + To: "Mary Smith: Personal Account" + From: John Doe + Subject: Re: Saying Hello + Date: Fri, 21 Nov 1997 11:00:00 -0600 + Message-ID: + In-Reply-To: <3456@example.net> + References: <1234@local.machine.example> <3456@example.net> + + This is a reply to your reply. + ---- + +Appendix A.3. Resent Messages + + Start with the message that has been used as an example several + times: + + ---- + From: John Doe + To: Mary Smith + Subject: Saying Hello + Date: Fri, 21 Nov 1997 09:55:06 -0600 + Message-ID: <1234@local.machine.example> + + This is a message just to say hello. + So, "Hello". + ---- + + Say that Mary, upon receiving this message, wishes to send a copy of + the message to Jane such that (a) the message would appear to have + come straight from John; (b) if Jane replies to the message, the + reply should go back to John; and (c) all of the original + information, like the date the message was originally sent to Mary, + the message identifier, and the original addressee, is preserved. In + this case, resent fields are prepended to the message: + + + + + + + + + + + + + + + + +Resnick Standards Track [Page 47] + +RFC 5322 Internet Message Format October 2008 + + + ---- + Resent-From: Mary Smith + Resent-To: Jane Brown + Resent-Date: Mon, 24 Nov 1997 14:22:01 -0800 + Resent-Message-ID: <78910@example.net> + From: John Doe + To: Mary Smith + Subject: Saying Hello + Date: Fri, 21 Nov 1997 09:55:06 -0600 + Message-ID: <1234@local.machine.example> + + This is a message just to say hello. + So, "Hello". + ---- + + If Jane, in turn, wished to resend this message to another person, + she would prepend her own set of resent header fields to the above + and send that. (Note that for brevity, trace fields are not shown.) + +Appendix A.4. Messages with Trace Fields + + As messages are sent through the transport system as described in + [RFC5321], trace fields are prepended to the message. The following + is an example of what those trace fields might look like. Note that + there is some folding white space in the first one since these lines + can be long. + + ---- + Received: from x.y.test + by example.net + via TCP + with ESMTP + id ABC12345 + for ; 21 Nov 1997 10:05:43 -0600 + Received: from node.example by x.y.test; 21 Nov 1997 10:01:22 -0600 + From: John Doe + To: Mary Smith + Subject: Saying Hello + Date: Fri, 21 Nov 1997 09:55:06 -0600 + Message-ID: <1234@local.node.example> + + This is a message just to say hello. + So, "Hello". + ---- + + + + + + + +Resnick Standards Track [Page 48] + +RFC 5322 Internet Message Format October 2008 + + +Appendix A.5. White Space, Comments, and Other Oddities + + White space, including folding white space, and comments can be + inserted between many of the tokens of fields. Taking the example + from A.1.3, white space and comments can be inserted into all of the + fields. + + ---- + From: Pete(A nice \) chap) + To:A Group(Some people) + :Chris Jones , + joe@example.org, + John (my dear friend); (the end of the group) + Cc:(Empty list)(start)Hidden recipients :(nobody(that I know)) ; + Date: Thu, + 13 + Feb + 1969 + 23:32 + -0330 (Newfoundland Time) + Message-ID: + + Testing. + ---- + + The above example is aesthetically displeasing, but perfectly legal. + Note particularly (1) the comments in the "From:" field (including + one that has a ")" character appearing as part of a quoted-pair); (2) + the white space absent after the ":" in the "To:" field as well as + the comment and folding white space after the group name, the special + character (".") in the comment in Chris Jones's address, and the + folding white space before and after "joe@example.org,"; (3) the + multiple and nested comments in the "Cc:" field as well as the + comment immediately following the ":" after "Cc"; (4) the folding + white space (but no comments except at the end) and the missing + seconds in the time of the date field; and (5) the white space before + (but not within) the identifier in the "Message-ID:" field. + + + + + + + + + + + + + + +Resnick Standards Track [Page 49] + +RFC 5322 Internet Message Format October 2008 + + +Appendix A.6. Obsoleted Forms + + The following are examples of obsolete (that is, the "MUST NOT + generate") syntactic elements described in section 4 of this + document. + +Appendix A.6.1. Obsolete Addressing + + Note in the example below the lack of quotes around Joe Q. Public, + the route that appears in the address for Mary Smith, the two commas + that appear in the "To:" field, and the spaces that appear around the + "." in the jdoe address. + + ---- + From: Joe Q. Public + To: Mary Smith <@node.test:mary@example.net>, , jdoe@test . example + Date: Tue, 1 Jul 2003 10:52:37 +0200 + Message-ID: <5678.21-Nov-1997@example.com> + + Hi everyone. + ---- + +Appendix A.6.2. Obsolete Dates + + The following message uses an obsolete date format, including a non- + numeric time zone and a two digit year. Note that although the day- + of-week is missing, that is not specific to the obsolete syntax; it + is optional in the current syntax as well. + + ---- + From: John Doe + To: Mary Smith + Subject: Saying Hello + Date: 21 Nov 97 09:55:06 GMT + Message-ID: <1234@local.machine.example> + + This is a message just to say hello. + So, "Hello". + ---- + + + + + + + + + + + + +Resnick Standards Track [Page 50] + +RFC 5322 Internet Message Format October 2008 + + +Appendix A.6.3. Obsolete White Space and Comments + + White space and comments can appear between many more elements than + in the current syntax. Also, folding lines that are made up entirely + of white space are legal. + + ---- + From : John Doe + To : Mary Smith + __ + + Subject : Saying Hello + Date : Fri, 21 Nov 1997 09(comment): 55 : 06 -0600 + Message-ID : <1234 @ local(blah) .machine .example> + + This is a message just to say hello. + So, "Hello". + ---- + + Note especially the second line of the "To:" field. It starts with + two space characters. (Note that "__" represent blank spaces.) + Therefore, it is considered part of the folding, as described in + section 4.2. Also, the comments and white space throughout + addresses, dates, and message identifiers are all part of the + obsolete syntax. + + + + + + + + + + + + + + + + + + + + + + + + + + +Resnick Standards Track [Page 51] + +RFC 5322 Internet Message Format October 2008 + + +Appendix B. Differences from Earlier Specifications + + This appendix contains a list of changes that have been made in the + Internet Message Format from earlier specifications, specifically + [RFC0822], [RFC1123], and [RFC2822]. Items marked with an asterisk + (*) below are items which appear in section 4 of this document and + therefore can no longer be generated. + + The following are the changes made from [RFC0822] and [RFC1123] to + [RFC2822] that remain in this document: + + 1. Period allowed in obsolete form of phrase. + 2. ABNF moved out of document, now in [RFC5234]. + 3. Four or more digits allowed for year. + 4. Header field ordering (and lack thereof) made explicit. + 5. Encrypted header field removed. + 6. Specifically allow and give meaning to "-0000" time zone. + 7. Folding white space is not allowed between every token. + 8. Requirement for destinations removed. + 9. Forwarding and resending redefined. + 10. Extension header fields no longer specifically called out. + 11. ASCII 0 (null) removed.* + 12. Folding continuation lines cannot contain only white space.* + 13. Free insertion of comments not allowed in date.* + 14. Non-numeric time zones not allowed.* + 15. Two digit years not allowed.* + 16. Three digit years interpreted, but not allowed for generation.* + 17. Routes in addresses not allowed.* + 18. CFWS within local-parts and domains not allowed.* + 19. Empty members of address lists not allowed.* + 20. Folding white space between field name and colon not allowed.* + 21. Comments between field name and colon not allowed. + 22. Tightened syntax of in-reply-to and references.* + 23. CFWS within msg-id not allowed.* + 24. Tightened semantics of resent fields as informational only. + 25. Resent-Reply-To not allowed.* + 26. No multiple occurrences of fields (except resent and received).* + 27. Free CR and LF not allowed.* + 28. Line length limits specified. + 29. Bcc more clearly specified. + + + + + + + + + + + +Resnick Standards Track [Page 52] + +RFC 5322 Internet Message Format October 2008 + + + The following are changes from [RFC2822]. + 1. Assorted typographical/grammatical errors fixed and + clarifications made. + 2. Changed "standard" to "document" or "specification" throughout. + 3. Made distinction between "header field" and "header section". + 4. Removed NO-WS-CTL from ctext, qtext, dtext, and unstructured.* + 5. Moved discussion of specials to the "Atom" section. Moved text + to "Overall message syntax" section. + 6. Simplified CFWS syntax. + 7. Fixed unstructured syntax. + 8. Changed date and time syntax to deal with white space in + obsolete date syntax. + 9. Removed quoted-pair from domain literals and message + identifiers.* + 10. Clarified that other specifications limit domain syntax. + 11. Simplified "Bcc:" and "Resent-Bcc:" syntax. + 12. Allowed optional-field to appear within trace information. + 13. Removed no-fold-quote from msg-id. Clarified syntax + limitations. + 14. Generalized "Received:" syntax to fix bugs and move definition + out of this document. + 15. Simplified obs-qp. Fixed and simplified obs-utext (which now + only appears in the obsolete syntax). Removed obs-text and obs- + char, adding obs-body. + 16. Fixed obsolete date syntax to allow for more (or less) comments + and white space. + 17. Fixed all obsolete list syntax (obs-domain-list, obs-mbox-list, + obs-addr-list, obs-phrase-list, and the newly added obs-group- + list). + 18. Fixed obs-reply-to syntax. + 19. Fixed obs-bcc and obs-resent-bcc to allow empty lists. + 20. Removed obs-path. + +Appendix C. Acknowledgements + + Many people contributed to this document. They included folks who + participated in the Detailed Revision and Update of Messaging + Standards (DRUMS) Working Group of the Internet Engineering Task + Force (IETF), the chair of DRUMS, the Area Directors of the IETF, and + people who simply sent their comments in via email. The editor is + deeply indebted to them all and thanks them sincerely. The below + list includes everyone who sent email concerning both this document + and [RFC2822]. Hopefully, everyone who contributed is named here: + + +--------------------+----------------------+---------------------+ + | Matti Aarnio | Tanaka Akira | Russ Allbery | + | Eric Allman | Harald Alvestrand | Ran Atkinson | + | Jos Backus | Bruce Balden | Dave Barr | + + + +Resnick Standards Track [Page 53] + +RFC 5322 Internet Message Format October 2008 + + + | Alan Barrett | John Beck | J Robert von Behren | + | Jos den Bekker | D J Bernstein | James Berriman | + | Oliver Block | Norbert Bollow | Raj Bose | + | Antony Bowesman | Scott Bradner | Randy Bush | + | Tom Byrer | Bruce Campbell | Larry Campbell | + | W J Carpenter | Michael Chapman | Richard Clayton | + | Maurizio Codogno | Jim Conklin | R Kelley Cook | + | Nathan Coulter | Steve Coya | Mark Crispin | + | Dave Crocker | Matt Curtin | Michael D'Errico | + | Cyrus Daboo | Michael D Dean | Jutta Degener | + | Mark Delany | Steve Dorner | Harold A Driscoll | + | Michael Elkins | Frank Ellerman | Robert Elz | + | Johnny Eriksson | Erik E Fair | Roger Fajman | + | Patrik Faltstrom | Claus Andre Faerber | Barry Finkel | + | Erik Forsberg | Chuck Foster | Paul Fox | + | Klaus M Frank | Ned Freed | Jochen Friedrich | + | Randall C Gellens | Sukvinder Singh Gill | Tim Goodwin | + | Philip Guenther | Arnt Gulbrandsen | Eric A Hall | + | Tony Hansen | John Hawkinson | Philip Hazel | + | Kai Henningsen | Robert Herriot | Paul Hethmon | + | Jim Hill | Alfred Hoenes | Paul E Hoffman | + | Steve Hole | Kari Hurtta | Marco S Hyman | + | Ofer Inbar | Olle Jarnefors | Kevin Johnson | + | Sudish Joseph | Maynard Kang | Prabhat Keni | + | John C Klensin | Graham Klyne | Brad Knowles | + | Shuhei Kobayashi | Peter Koch | Dan Kohn | + | Christian Kuhtz | Anand Kumria | Steen Larsen | + | Eliot Lear | Barry Leiba | Jay Levitt | + | Bruce Lilly | Lars-Johan Liman | Charles Lindsey | + | Pete Loshin | Simon Lyall | Bill Manning | + | John Martin | Mark Martinec | Larry Masinter | + | Denis McKeon | William P McQuillan | Alexey Melnikov | + | Perry E Metzger | Steven Miller | S Moonesamy | + | Keith Moore | John Gardiner Myers | Chris Newman | + | John W Noerenberg | Eric Norman | Mike O'Dell | + | Larry Osterman | Paul Overell | Jacob Palme | + | Michael A Patton | Uzi Paz | Michael A Quinlan | + | Robert Rapplean | Eric S Raymond | Sam Roberts | + | Hugh Sasse | Bart Schaefer | Tom Scola | + | Wolfgang Segmuller | Nick Shelness | John Stanley | + | Einar Stefferud | Jeff Stephenson | Bernard Stern | + | Peter Sylvester | Mark Symons | Eric Thomas | + | Lee Thompson | Karel De Vriendt | Matthew Wall | + | Rolf Weber | Brent B Welch | Dan Wing | + | Jack De Winter | Gregory J Woodhouse | Greg A Woods | + | Kazu Yamamoto | Alain Zahm | Jamie Zawinski | + | Timothy S Zurcher | | | + +--------------------+----------------------+---------------------+ + + + +Resnick Standards Track [Page 54] + +RFC 5322 Internet Message Format October 2008 + + +7. References + +7.1. Normative References + + [ANSI.X3-4.1986] American National Standards Institute, "Coded + Character Set - 7-bit American Standard Code for + Information Interchange", ANSI X3.4, 1986. + + [RFC1034] Mockapetris, P., "Domain names - concepts and + facilities", STD 13, RFC 1034, November 1987. + + [RFC1035] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, November 1987. + + [RFC1123] Braden, R., "Requirements for Internet Hosts - + Application and Support", STD 3, RFC 1123, + October 1989. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for + Syntax Specifications: ABNF", STD 68, RFC 5234, + January 2008. + +7.2. Informative References + + [RFC0822] Crocker, D., "Standard for the format of ARPA + Internet text messages", STD 11, RFC 822, + August 1982. + + [RFC1305] Mills, D., "Network Time Protocol (Version 3) + Specification, Implementation", RFC 1305, + March 1992. + + [ISO.2022.1994] International Organization for Standardization, + "Information technology - Character code structure + and extension techniques", ISO Standard 2022, 1994. + + [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet + Mail Extensions (MIME) Part One: Format of Internet + Message Bodies", RFC 2045, November 1996. + + [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet + Mail Extensions (MIME) Part Two: Media Types", + RFC 2046, November 1996. + + + + + +Resnick Standards Track [Page 55] + +RFC 5322 Internet Message Format October 2008 + + + [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail + Extensions) Part Three: Message Header Extensions + for Non-ASCII Text", RFC 2047, November 1996. + + [RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet + Mail Extensions (MIME) Part Five: Conformance + Criteria and Examples", RFC 2049, November 1996. + + [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, + April 2001. + + [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, + "Registration Procedures for Message Header + Fields", BCP 90, RFC 3864, September 2004. + + [RFC4021] Klyne, G. and J. Palme, "Registration of Mail and + MIME Header Fields", RFC 4021, March 2005. + + [RFC4288] Freed, N. and J. Klensin, "Media Type + Specifications and Registration Procedures", + BCP 13, RFC 4288, December 2005. + + [RFC4289] Freed, N. and J. Klensin, "Multipurpose Internet + Mail Extensions (MIME) Part Four: Registration + Procedures", BCP 13, RFC 4289, December 2005. + + [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", + RFC 5321, October 2008. + +Author's Address + + Peter W. Resnick (editor) + Qualcomm Incorporated + 5775 Morehouse Drive + San Diego, CA 92121-1714 + US + + Phone: +1 858 651 4478 + EMail: presnick@qualcomm.com + URI: http://www.qualcomm.com/~presnick/ + + + + + + + + + + + +Resnick Standards Track [Page 56] + +RFC 5322 Internet Message Format October 2008 + + +Full Copyright Statement + + Copyright (C) The IETF Trust (2008). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND + THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS + OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF + THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + + + + + + + + + + + + +Resnick Standards Track [Page 57] + diff --git a/RFCs/rfc6376.txt b/RFCs/rfc6376.txt new file mode 100644 index 0000000..8ecbafa --- /dev/null +++ b/RFCs/rfc6376.txt @@ -0,0 +1,4259 @@ + + + + + + +Internet Engineering Task Force (IETF) D. Crocker, Ed. +Request for Comments: 6376 Brandenburg InternetWorking +Obsoletes: 4871, 5672 T. Hansen, Ed. +Category: Standards Track AT&T Laboratories +ISSN: 2070-1721 M. Kucherawy, Ed. + Cloudmark + September 2011 + + + DomainKeys Identified Mail (DKIM) Signatures + +Abstract + + DomainKeys Identified Mail (DKIM) permits a person, role, or + organization that owns the signing domain to claim some + responsibility for a message by associating the domain with the + message. This can be an author's organization, an operational relay, + or one of their agents. DKIM separates the question of the identity + of the Signer of the message from the purported author of the + message. Assertion of responsibility is validated through a + cryptographic signature and by querying the Signer's domain directly + to retrieve the appropriate public key. Message transit from author + to recipient is through relays that typically make no substantive + change to the message content and thus preserve the DKIM signature. + + This memo obsoletes RFC 4871 and RFC 5672. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc6376. + +Copyright Notice + + Copyright (c) 2011 IETF Trust and the persons identified as the + document authors. All rights reserved. + + + + + + +Crocker, et al. Standards Track [Page 1] + +RFC 6376 DKIM Signatures September 2011 + + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + + This document may contain material from IETF Documents or IETF + Contributions published or made publicly available before November + 10, 2008. The person(s) controlling the copyright in some of this + material may not have granted the IETF Trust the right to allow + modifications of such material outside the IETF Standards Process. + Without obtaining an adequate license from the person(s) controlling + the copyright in such materials, this document may not be modified + outside the IETF Standards Process, and derivative works of it may + not be created outside the IETF Standards Process, except to format + it for publication as an RFC or to translate it into languages other + than English. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 1.1. DKIM Architecture Documents . . . . . . . . . . . . . . . 5 + 1.2. Signing Identity . . . . . . . . . . . . . . . . . . . . . 5 + 1.3. Scalability . . . . . . . . . . . . . . . . . . . . . . . 5 + 1.4. Simple Key Management . . . . . . . . . . . . . . . . . . 6 + 1.5. Data Integrity . . . . . . . . . . . . . . . . . . . . . . 6 + 2. Terminology and Definitions . . . . . . . . . . . . . . . . . 6 + 2.1. Signers . . . . . . . . . . . . . . . . . . . . . . . . . 6 + 2.2. Verifiers . . . . . . . . . . . . . . . . . . . . . . . . 7 + 2.3. Identity . . . . . . . . . . . . . . . . . . . . . . . . . 7 + 2.4. Identifier . . . . . . . . . . . . . . . . . . . . . . . . 7 + 2.5. Signing Domain Identifier (SDID) . . . . . . . . . . . . . 7 + 2.6. Agent or User Identifier (AUID) . . . . . . . . . . . . . 7 + 2.7. Identity Assessor . . . . . . . . . . . . . . . . . . . . 7 + 2.8. Whitespace . . . . . . . . . . . . . . . . . . . . . . . . 8 + 2.9. Imported ABNF Tokens . . . . . . . . . . . . . . . . . . . 8 + 2.10. Common ABNF Tokens . . . . . . . . . . . . . . . . . . . . 9 + 2.11. DKIM-Quoted-Printable . . . . . . . . . . . . . . . . . . 9 + 3. Protocol Elements . . . . . . . . . . . . . . . . . . . . . . 10 + 3.1. Selectors . . . . . . . . . . . . . . . . . . . . . . . . 10 + 3.2. Tag=Value Lists . . . . . . . . . . . . . . . . . . . . . 12 + 3.3. Signing and Verification Algorithms . . . . . . . . . . . 13 + 3.4. Canonicalization . . . . . . . . . . . . . . . . . . . . . 14 + 3.5. The DKIM-Signature Header Field . . . . . . . . . . . . . 18 + + + +Crocker, et al. Standards Track [Page 2] + +RFC 6376 DKIM Signatures September 2011 + + + 3.6. Key Management and Representation . . . . . . . . . . . . 26 + 3.7. Computing the Message Hashes . . . . . . . . . . . . . . . 29 + 3.8. Input Requirements . . . . . . . . . . . . . . . . . . . . 32 + 3.9. Output Requirements . . . . . . . . . . . . . . . . . . . 32 + 3.10. Signing by Parent Domains . . . . . . . . . . . . . . . . 33 + 3.11. Relationship between SDID and AUID . . . . . . . . . . . . 33 + 4. Semantics of Multiple Signatures . . . . . . . . . . . . . . . 34 + 4.1. Example Scenarios . . . . . . . . . . . . . . . . . . . . 34 + 4.2. Interpretation . . . . . . . . . . . . . . . . . . . . . . 35 + 5. Signer Actions . . . . . . . . . . . . . . . . . . . . . . . . 36 + 5.1. Determine Whether the Email Should Be Signed and by + Whom . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 + 5.2. Select a Private Key and Corresponding Selector + Information . . . . . . . . . . . . . . . . . . . . . . . 37 + 5.3. Normalize the Message to Prevent Transport Conversions . . 37 + 5.4. Determine the Header Fields to Sign . . . . . . . . . . . 38 + 5.5. Compute the Message Hash and Signature . . . . . . . . . . 43 + 5.6. Insert the DKIM-Signature Header Field . . . . . . . . . . 43 + 6. Verifier Actions . . . . . . . . . . . . . . . . . . . . . . . 43 + 6.1. Extract Signatures from the Message . . . . . . . . . . . 44 + 6.2. Communicate Verification Results . . . . . . . . . . . . . 49 + 6.3. Interpret Results/Apply Local Policy . . . . . . . . . . . 50 + 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 51 + 7.1. Email Authentication Methods Registry . . . . . . . . . . 51 + 7.2. DKIM-Signature Tag Specifications . . . . . . . . . . . . 51 + 7.3. DKIM-Signature Query Method Registry . . . . . . . . . . . 52 + 7.4. DKIM-Signature Canonicalization Registry . . . . . . . . . 52 + 7.5. _domainkey DNS TXT Resource Record Tag Specifications . . 53 + 7.6. DKIM Key Type Registry . . . . . . . . . . . . . . . . . . 53 + 7.7. DKIM Hash Algorithms Registry . . . . . . . . . . . . . . 54 + 7.8. DKIM Service Types Registry . . . . . . . . . . . . . . . 54 + 7.9. DKIM Selector Flags Registry . . . . . . . . . . . . . . . 55 + 7.10. DKIM-Signature Header Field . . . . . . . . . . . . . . . 55 + 8. Security Considerations . . . . . . . . . . . . . . . . . . . 55 + 8.1. ASCII Art Attacks . . . . . . . . . . . . . . . . . . . . 55 + 8.2. Misuse of Body Length Limits ("l=" Tag) . . . . . . . . . 55 + 8.3. Misappropriated Private Key . . . . . . . . . . . . . . . 56 + 8.4. Key Server Denial-of-Service Attacks . . . . . . . . . . . 56 + 8.5. Attacks against the DNS . . . . . . . . . . . . . . . . . 57 + 8.6. Replay/Spam Attacks . . . . . . . . . . . . . . . . . . . 57 + 8.7. Limits on Revoking Keys . . . . . . . . . . . . . . . . . 58 + 8.8. Intentionally Malformed Key Records . . . . . . . . . . . 58 + 8.9. Intentionally Malformed DKIM-Signature Header Fields . . . 58 + 8.10. Information Leakage . . . . . . . . . . . . . . . . . . . 58 + 8.11. Remote Timing Attacks . . . . . . . . . . . . . . . . . . 59 + 8.12. Reordered Header Fields . . . . . . . . . . . . . . . . . 59 + 8.13. RSA Attacks . . . . . . . . . . . . . . . . . . . . . . . 59 + 8.14. Inappropriate Signing by Parent Domains . . . . . . . . . 59 + + + +Crocker, et al. Standards Track [Page 3] + +RFC 6376 DKIM Signatures September 2011 + + + 8.15. Attacks Involving Extra Header Fields . . . . . . . . . . 60 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 61 + 9.1. Normative References . . . . . . . . . . . . . . . . . . . 61 + 9.2. Informative References . . . . . . . . . . . . . . . . . . 62 + Appendix A. Example of Use (INFORMATIVE) . . . . . . . . . . . . 64 + A.1. The User Composes an Email . . . . . . . . . . . . . . . . 64 + A.2. The Email is Signed . . . . . . . . . . . . . . . . . . . 65 + A.3. The Email Signature is Verified . . . . . . . . . . . . . 66 + Appendix B. Usage Examples (INFORMATIVE) . . . . . . . . . . . . 67 + B.1. Alternate Submission Scenarios . . . . . . . . . . . . . . 67 + B.2. Alternate Delivery Scenarios . . . . . . . . . . . . . . . 69 + Appendix C. Creating a Public Key (INFORMATIVE) . . . . . . . . . 71 + C.1. Compatibility with DomainKeys Key Records . . . . . . . . 72 + C.2. RFC 4871 Compatibility . . . . . . . . . . . . . . . . . . 73 + Appendix D. MUA Considerations (INFORMATIVE) . . . . . . . . . . 73 + Appendix E. Changes since RFC 4871 . . . . . . . . . . . . . . . 73 + Appendix F. Acknowledgments . . . . . . . . . . . . . . . . . . . 75 + +1. Introduction + + DomainKeys Identified Mail (DKIM) permits a person, role, or + organization to claim some responsibility for a message by + associating a domain name [RFC1034] with the message [RFC5322], which + they are authorized to use. This can be an author's organization, an + operational relay, or one of their agents. Assertion of + responsibility is validated through a cryptographic signature and by + querying the Signer's domain directly to retrieve the appropriate + public key. Message transit from author to recipient is through + relays that typically make no substantive change to the message + content and thus preserve the DKIM signature. A message can contain + multiple signatures, from the same or different organizations + involved with the message. + + The approach taken by DKIM differs from previous approaches to + message signing (e.g., Secure/Multipurpose Internet Mail Extensions + (S/MIME) [RFC5751], OpenPGP [RFC4880]) in that: + + o the message signature is written as a message header field so that + neither human recipients nor existing MUA (Mail User Agent) + software is confused by signature-related content appearing in the + message body; + + o there is no dependency on public- and private-key pairs being + issued by well-known, trusted certificate authorities; + + o there is no dependency on the deployment of any new Internet + protocols or services for public-key distribution or revocation; + + + + +Crocker, et al. Standards Track [Page 4] + +RFC 6376 DKIM Signatures September 2011 + + + o signature verification failure does not force rejection of the + message; + + o no attempt is made to include encryption as part of the mechanism; + and + + o message archiving is not a design goal. + + DKIM: + + o is compatible with the existing email infrastructure and + transparent to the fullest extent possible; + + o requires minimal new infrastructure; + + o can be implemented independently of clients in order to reduce + deployment time; + + o can be deployed incrementally; and + + o allows delegation of signing to third parties. + +1.1. DKIM Architecture Documents + + Readers are advised to be familiar with the material in [RFC4686], + [RFC5585], and [RFC5863], which provide the background for the + development of DKIM, an overview of the service, and deployment and + operations guidance and advice, respectively. + +1.2. Signing Identity + + DKIM separates the question of the identity of the Signer of the + message from the purported author of the message. In particular, a + signature includes the identity of the Signer. Verifiers can use the + signing information to decide how they want to process the message. + The signing identity is included as part of the signature header + field. + + INFORMATIVE RATIONALE: The signing identity specified by a DKIM + signature is not required to match an address in any particular + header field because of the broad methods of interpretation by + recipient mail systems, including MUAs. + +1.3. Scalability + + DKIM is designed to support the extreme scalability requirements that + characterize the email identification problem. There are many + millions of domains and a much larger number of individual addresses. + + + +Crocker, et al. Standards Track [Page 5] + +RFC 6376 DKIM Signatures September 2011 + + + DKIM seeks to preserve the positive aspects of the current email + infrastructure, such as the ability for anyone to communicate with + anyone else without introduction. + +1.4. Simple Key Management + + DKIM differs from traditional hierarchical public-key systems in that + no certificate authority infrastructure is required; the Verifier + requests the public key from a repository in the domain of the + claimed Signer directly rather than from a third party. + + The DNS is proposed as the initial mechanism for the public keys. + Thus, DKIM currently depends on DNS administration and the security + of the DNS system. DKIM is designed to be extensible to other key + fetching services as they become available. + +1.5. Data Integrity + + A DKIM signature associates the "d=" name with the computed hash of + some or all of the message (see Section 3.7) in order to prevent the + reuse of the signature with different messages. Verifying the + signature asserts that the hashed content has not changed since it + was signed and asserts nothing else about "protecting" the end-to-end + integrity of the message. + +2. Terminology and Definitions + + This section defines terms used in the rest of the document. + + DKIM is designed to operate within the Internet Mail service, as + defined in [RFC5598]. Basic email terminology is taken from that + specification. + + Syntax descriptions use Augmented BNF (ABNF) [RFC5234]. + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in + [RFC2119]. These words take their normative meanings only when they + are presented in ALL UPPERCASE. + +2.1. Signers + + Elements in the mail system that sign messages on behalf of a domain + are referred to as Signers. These may be MUAs (Mail User Agents), + MSAs (Mail Submission Agents), MTAs (Mail Transfer Agents), or other + agents such as mailing list exploders. In general, any Signer will + + + + +Crocker, et al. Standards Track [Page 6] + +RFC 6376 DKIM Signatures September 2011 + + + be involved in the injection of a message into the message system in + some way. The key issue is that a message must be signed before it + leaves the administrative domain of the Signer. + +2.2. Verifiers + + Elements in the mail system that verify signatures are referred to as + Verifiers. These may be MTAs, Mail Delivery Agents (MDAs), or MUAs. + In most cases, it is expected that Verifiers will be close to an end + user (reader) of the message or some consuming agent such as a + mailing list exploder. + +2.3. Identity + + A person, role, or organization. In the context of DKIM, examples + include the author, the author's organization, an ISP along the + handling path, an independent trust assessment service, and a mailing + list operator. + +2.4. Identifier + + A label that refers to an identity. + +2.5. Signing Domain Identifier (SDID) + + A single domain name that is the mandatory payload output of DKIM and + that refers to the identity claiming some responsibility for the + message by signing it. It is specified in Section 3.5. + +2.6. Agent or User Identifier (AUID) + + A single identifier that refers to the agent or user on behalf of + whom the Signing Domain Identifier (SDID) has taken responsibility. + The AUID comprises a domain name and an optional . The + domain name is the same as that used for the SDID or is a subdomain + of it. For DKIM processing, the domain name portion of the AUID has + only basic domain name semantics; any possible owner-specific + semantics are outside the scope of DKIM. It is specified in + Section 3.5. + + Note that acceptable values for the AUID may be constrained via a + flag in the public-key record. (See Section 3.6.1.) + +2.7. Identity Assessor + + An element in the mail system that consumes DKIM's payload, which is + the responsible Signing Domain Identifier (SDID). The Identity + Assessor is dedicated to the assessment of the delivered identifier. + + + +Crocker, et al. Standards Track [Page 7] + +RFC 6376 DKIM Signatures September 2011 + + + Other DKIM (and non-DKIM) values can also be used by the Identity + Assessor (if they are available) to provide a more general message + evaluation filtering engine. However, this additional activity is + outside the scope of this specification. + +2.8. Whitespace + + There are three forms of whitespace: + + o WSP represents simple whitespace, i.e., a space or a tab character + (formal definition in [RFC5234]). + + o LWSP is linear whitespace, defined as WSP plus CRLF (formal + definition in [RFC5234]). + + o FWS is folding whitespace. It allows multiple lines separated by + CRLF followed by at least one whitespace, to be joined. + + The formal ABNF for these are (WSP and LWSP are given for information + only): + + WSP = SP / HTAB + LWSP = *(WSP / CRLF WSP) + FWS = [*WSP CRLF] 1*WSP + + The definition of FWS is identical to that in [RFC5322] except for + the exclusion of obs-FWS. + +2.9. Imported ABNF Tokens + + The following tokens are imported from other RFCs as noted. Those + RFCs should be considered definitive. + + The following tokens are imported from [RFC5321]: + + o "local-part" (implementation warning: this permits quoted strings) + + o "sub-domain" + + The following tokens are imported from [RFC5322]: + + o "field-name" (name of a header field) + + o "dot-atom-text" (in the local-part of an email address) + + The following tokens are imported from [RFC2045]: + + o "qp-section" (a single line of quoted-printable-encoded text) + + + +Crocker, et al. Standards Track [Page 8] + +RFC 6376 DKIM Signatures September 2011 + + + o "hex-octet" (a quoted-printable encoded octet) + + INFORMATIVE NOTE: Be aware that the ABNF in [RFC2045] does not + obey the rules of [RFC5234] and must be interpreted accordingly, + particularly as regards case folding. + + Other tokens not defined herein are imported from [RFC5234]. These + are intuitive primitives such as SP, HTAB, WSP, ALPHA, DIGIT, CRLF, + etc. + +2.10. Common ABNF Tokens + + The following ABNF tokens are used elsewhere in this document: + + hyphenated-word = ALPHA [ *(ALPHA / DIGIT / "-") (ALPHA / DIGIT) ] + ALPHADIGITPS = (ALPHA / DIGIT / "+" / "/") + base64string = ALPHADIGITPS *([FWS] ALPHADIGITPS) + [ [FWS] "=" [ [FWS] "=" ] ] + hdr-name = field-name + qp-hdr-value = dkim-quoted-printable ; with "|" encoded + +2.11. DKIM-Quoted-Printable + + The DKIM-Quoted-Printable encoding syntax resembles that described in + Quoted-Printable [RFC2045], Section 6.7: any character MAY be encoded + as an "=" followed by two hexadecimal digits from the alphabet + "0123456789ABCDEF" (no lowercase characters permitted) representing + the hexadecimal-encoded integer value of that character. All control + characters (those with values < %x20), 8-bit characters (values > + %x7F), and the characters DEL (%x7F), SPACE (%x20), and semicolon + (";", %x3B) MUST be encoded. Note that all whitespace, including + SPACE, CR, and LF characters, MUST be encoded. After encoding, FWS + MAY be added at arbitrary locations in order to avoid excessively + long lines; such whitespace is NOT part of the value, and MUST be + removed before decoding. Use of characters not listed as "mail-safe" + in [RFC2049] is NOT RECOMMENDED. + + ABNF: + + dkim-quoted-printable = *(FWS / hex-octet / dkim-safe-char) + ; hex-octet is from RFC2045 + dkim-safe-char = %x21-3A / %x3C / %x3E-7E + ; '!' - ':', '<', '>' - '~' + + + + + + + + +Crocker, et al. Standards Track [Page 9] + +RFC 6376 DKIM Signatures September 2011 + + + INFORMATIVE NOTE: DKIM-Quoted-Printable differs from Quoted- + Printable as defined in [RFC2045] in several important ways: + + 1. Whitespace in the input text, including CR and LF, must be + encoded. [RFC2045] does not require such encoding, and does + not permit encoding of CR or LF characters that are part of a + CRLF line break. + + 2. Whitespace in the encoded text is ignored. This is to allow + tags encoded using DKIM-Quoted-Printable to be wrapped as + needed. In particular, [RFC2045] requires that line breaks in + the input be represented as physical line breaks; that is not + the case here. + + 3. The "soft line break" syntax ("=" as the last non-whitespace + character on the line) does not apply. + + 4. DKIM-Quoted-Printable does not require that encoded lines be + no more than 76 characters long (although there may be other + requirements depending on the context in which the encoded + text is being used). + +3. Protocol Elements + + Protocol Elements are conceptual parts of the protocol that are not + specific to either Signers or Verifiers. The protocol descriptions + for Signers and Verifiers are described in later sections ("Signer + Actions" (Section 5) and "Verifier Actions" (Section 6)). NOTE: This + section must be read in the context of those sections. + +3.1. Selectors + + To support multiple concurrent public keys per signing domain, the + key namespace is subdivided using "selectors". For example, + selectors might indicate the names of office locations (e.g., + "sanfrancisco", "coolumbeach", and "reykjavik"), the signing date + (e.g., "january2005", "february2005", etc.), or even an individual + user. + + Selectors are needed to support some important use cases. For + example: + + o Domains that want to delegate signing capability for a specific + address for a given duration to a partner, such as an advertising + provider or other outsourced function. + + o Domains that want to allow frequent travelers to send messages + locally without the need to connect with a particular MSA. + + + +Crocker, et al. Standards Track [Page 10] + +RFC 6376 DKIM Signatures September 2011 + + + o "Affinity" domains (e.g., college alumni associations) that + provide forwarding of incoming mail, but that do not operate a + mail submission agent for outgoing mail. + + Periods are allowed in selectors and are component separators. When + keys are retrieved from the DNS, periods in selectors define DNS + label boundaries in a manner similar to the conventional use in + domain names. Selector components might be used to combine dates + with locations, for example, "march2005.reykjavik". In a DNS + implementation, this can be used to allow delegation of a portion of + the selector namespace. + + ABNF: + + selector = sub-domain *( "." sub-domain ) + + The number of public keys and corresponding selectors for each domain + is determined by the domain owner. Many domain owners will be + satisfied with just one selector, whereas administratively + distributed organizations can choose to manage disparate selectors + and key pairs in different regions or on different email servers. + + Beyond administrative convenience, selectors make it possible to + seamlessly replace public keys on a routine basis. If a domain + wishes to change from using a public key associated with selector + "january2005" to a public key associated with selector + "february2005", it merely makes sure that both public keys are + advertised in the public-key repository concurrently for the + transition period during which email may be in transit prior to + verification. At the start of the transition period, the outbound + email servers are configured to sign with the "february2005" private + key. At the end of the transition period, the "january2005" public + key is removed from the public-key repository. + + INFORMATIVE NOTE: A key may also be revoked as described below. + The distinction between revoking and removing a key selector + record is subtle. When phasing out keys as described above, a + signing domain would probably simply remove the key record after + the transition period. However, a signing domain could elect to + revoke the key (but maintain the key record) for a further period. + There is no defined semantic difference between a revoked key and + a removed key. + + While some domains may wish to make selector values well-known, + others will want to take care not to allocate selector names in a way + that allows harvesting of data by outside parties. For example, if + per-user keys are issued, the domain owner will need to decide + + + + +Crocker, et al. Standards Track [Page 11] + +RFC 6376 DKIM Signatures September 2011 + + + whether to associate this selector directly with the name of a + registered end user or make it some unassociated random value, such + as a fingerprint of the public key. + + INFORMATIVE OPERATIONS NOTE: Reusing a selector with a new key + (for example, changing the key associated with a user's name) + makes it impossible to tell the difference between a message that + didn't verify because the key is no longer valid and a message + that is actually forged. For this reason, Signers are ill-advised + to reuse selectors for new keys. A better strategy is to assign + new keys to new selectors. + +3.2. Tag=Value Lists + + DKIM uses a simple "tag=value" syntax in several contexts, including + in messages and domain signature records. + + Values are a series of strings containing either plain text, "base64" + text (as defined in [RFC2045], Section 6.8), "qp-section" (ibid, + Section 6.7), or "dkim-quoted-printable" (as defined in + Section 2.11). The name of the tag will determine the encoding of + each value. Unencoded semicolon (";") characters MUST NOT occur in + the tag value, since that separates tag-specs. + + INFORMATIVE IMPLEMENTATION NOTE: Although the "plain text" defined + below (as "tag-value") only includes 7-bit characters, an + implementation that wished to anticipate future standards would be + advised not to preclude the use of UTF-8-encoded ([RFC3629]) text + in tag=value lists. + + Formally, the ABNF syntax rules are as follows: + + tag-list = tag-spec *( ";" tag-spec ) [ ";" ] + tag-spec = [FWS] tag-name [FWS] "=" [FWS] tag-value [FWS] + tag-name = ALPHA *ALNUMPUNC + tag-value = [ tval *( 1*(WSP / FWS) tval ) ] + ; Prohibits WSP and FWS at beginning and end + tval = 1*VALCHAR + VALCHAR = %x21-3A / %x3C-7E + ; EXCLAMATION to TILDE except SEMICOLON + ALNUMPUNC = ALPHA / DIGIT / "_" + + Note that WSP is allowed anywhere around tags. In particular, any + WSP after the "=" and any WSP before the terminating ";" is not part + of the value; however, WSP inside the value is significant. + + + + + + +Crocker, et al. Standards Track [Page 12] + +RFC 6376 DKIM Signatures September 2011 + + + Tags MUST be interpreted in a case-sensitive manner. Values MUST be + processed as case sensitive unless the specific tag description of + semantics specifies case insensitivity. + + Tags with duplicate names MUST NOT occur within a single tag-list; if + a tag name does occur more than once, the entire tag-list is invalid. + + Whitespace within a value MUST be retained unless explicitly excluded + by the specific tag description. + + Tag=value pairs that represent the default value MAY be included to + aid legibility. + + Unrecognized tags MUST be ignored. + + Tags that have an empty value are not the same as omitted tags. An + omitted tag is treated as having the default value; a tag with an + empty value explicitly designates the empty string as the value. + +3.3. Signing and Verification Algorithms + + DKIM supports multiple digital signature algorithms. Two algorithms + are defined by this specification at this time: rsa-sha1 and rsa- + sha256. Signers MUST implement and SHOULD sign using rsa-sha256. + Verifiers MUST implement both rsa-sha1 and rsa-sha256. + + INFORMATIVE NOTE: Although rsa-sha256 is strongly encouraged, some + senders might prefer to use rsa-sha1 when balancing security + strength against performance, complexity, or other needs. In + general, however, rsa-sha256 should always be used whenever + possible. + +3.3.1. The rsa-sha1 Signing Algorithm + + The rsa-sha1 Signing Algorithm computes a message hash as described + in Section 3.7 using SHA-1 [FIPS-180-3-2008] as the hash-alg. That + hash is then signed by the Signer using the RSA algorithm (defined in + Public-Key Cryptography Standards (PKCS) #1 version 1.5 [RFC3447]) as + the crypt-alg and the Signer's private key. The hash MUST NOT be + truncated or converted into any form other than the native binary + form before being signed. The signing algorithm SHOULD use a public + exponent of 65537. + +3.3.2. The rsa-sha256 Signing Algorithm + + The rsa-sha256 Signing Algorithm computes a message hash as described + in Section 3.7 using SHA-256 [FIPS-180-3-2008] as the hash-alg. That + hash is then signed by the Signer using the RSA algorithm (defined in + + + +Crocker, et al. Standards Track [Page 13] + +RFC 6376 DKIM Signatures September 2011 + + + PKCS#1 version 1.5 [RFC3447]) as the crypt-alg and the Signer's + private key. The hash MUST NOT be truncated or converted into any + form other than the native binary form before being signed. The + signing algorithm SHOULD use a public exponent of 65537. + +3.3.3. Key Sizes + + Selecting appropriate key sizes is a trade-off between cost, + performance, and risk. Since short RSA keys more easily succumb to + off-line attacks, Signers MUST use RSA keys of at least 1024 bits for + long-lived keys. Verifiers MUST be able to validate signatures with + keys ranging from 512 bits to 2048 bits, and they MAY be able to + validate signatures with larger keys. Verifier policies may use the + length of the signing key as one metric for determining whether a + signature is acceptable. + + Factors that should influence the key size choice include the + following: + + o The practical constraint that large (e.g., 4096-bit) keys might + not fit within a 512-byte DNS UDP response packet + + o The security constraint that keys smaller than 1024 bits are + subject to off-line attacks + + o Larger keys impose higher CPU costs to verify and sign email + + o Keys can be replaced on a regular basis; thus, their lifetime can + be relatively short + + o The security goals of this specification are modest compared to + typical goals of other systems that employ digital signatures + + See [RFC3766] for further discussion on selecting key sizes. + +3.3.4. Other Algorithms + + Other algorithms MAY be defined in the future. Verifiers MUST ignore + any signatures using algorithms that they do not implement. + +3.4. Canonicalization + + Some mail systems modify email in transit, potentially invalidating a + signature. For most Signers, mild modification of email is + immaterial to validation of the DKIM domain name's use. For such + Signers, a canonicalization algorithm that survives modest in-transit + modification is preferred. + + + + +Crocker, et al. Standards Track [Page 14] + +RFC 6376 DKIM Signatures September 2011 + + + Other Signers demand that any modification of the email, however + minor, result in a signature verification failure. These Signers + prefer a canonicalization algorithm that does not tolerate in-transit + modification of the signed email. + + Some Signers may be willing to accept modifications to header fields + that are within the bounds of email standards such as [RFC5322], but + are unwilling to accept any modification to the body of messages. + + To satisfy all requirements, two canonicalization algorithms are + defined for each of the header and the body: a "simple" algorithm + that tolerates almost no modification and a "relaxed" algorithm that + tolerates common modifications such as whitespace replacement and + header field line rewrapping. A Signer MAY specify either algorithm + for header or body when signing an email. If no canonicalization + algorithm is specified by the Signer, the "simple" algorithm defaults + for both header and body. Verifiers MUST implement both + canonicalization algorithms. Note that the header and body may use + different canonicalization algorithms. Further canonicalization + algorithms MAY be defined in the future; Verifiers MUST ignore any + signatures that use unrecognized canonicalization algorithms. + + Canonicalization simply prepares the email for presentation to the + signing or verification algorithm. It MUST NOT change the + transmitted data in any way. Canonicalization of header fields and + body are described below. + + NOTE: This section assumes that the message is already in "network + normal" format (text is ASCII encoded, lines are separated with CRLF + characters, etc.). See also Section 5.3 for information about + normalizing the message. + +3.4.1. The "simple" Header Canonicalization Algorithm + + The "simple" header canonicalization algorithm does not change header + fields in any way. Header fields MUST be presented to the signing or + verification algorithm exactly as they are in the message being + signed or verified. In particular, header field names MUST NOT be + case folded and whitespace MUST NOT be changed. + +3.4.2. The "relaxed" Header Canonicalization Algorithm + + The "relaxed" header canonicalization algorithm MUST apply the + following steps in order: + + o Convert all header field names (not the header field values) to + lowercase. For example, convert "SUBJect: AbC" to "subject: AbC". + + + + +Crocker, et al. Standards Track [Page 15] + +RFC 6376 DKIM Signatures September 2011 + + + o Unfold all header field continuation lines as described in + [RFC5322]; in particular, lines with terminators embedded in + continued header field values (that is, CRLF sequences followed by + WSP) MUST be interpreted without the CRLF. Implementations MUST + NOT remove the CRLF at the end of the header field value. + + o Convert all sequences of one or more WSP characters to a single SP + character. WSP characters here include those before and after a + line folding boundary. + + o Delete all WSP characters at the end of each unfolded header field + value. + + o Delete any WSP characters remaining before and after the colon + separating the header field name from the header field value. The + colon separator MUST be retained. + +3.4.3. The "simple" Body Canonicalization Algorithm + + The "simple" body canonicalization algorithm ignores all empty lines + at the end of the message body. An empty line is a line of zero + length after removal of the line terminator. If there is no body or + no trailing CRLF on the message body, a CRLF is added. It makes no + other changes to the message body. In more formal terms, the + "simple" body canonicalization algorithm converts "*CRLF" at the end + of the body to a single "CRLF". + + Note that a completely empty or missing body is canonicalized as a + single "CRLF"; that is, the canonicalized length will be 2 octets. + + The SHA-1 value (in base64) for an empty body (canonicalized to a + "CRLF") is: + + uoq1oCgLlTqpdDX/iUbLy7J1Wic= + + The SHA-256 value is: + + frcCV1k9oG9oKj3dpUqdJg1PxRT2RSN/XKdLCPjaYaY= + +3.4.4. The "relaxed" Body Canonicalization Algorithm + + The "relaxed" body canonicalization algorithm MUST apply the + following steps (a) and (b) in order: + + a. Reduce whitespace: + + * Ignore all whitespace at the end of lines. Implementations + MUST NOT remove the CRLF at the end of the line. + + + +Crocker, et al. Standards Track [Page 16] + +RFC 6376 DKIM Signatures September 2011 + + + * Reduce all sequences of WSP within a line to a single SP + character. + + b. Ignore all empty lines at the end of the message body. "Empty + line" is defined in Section 3.4.3. If the body is non-empty but + does not end with a CRLF, a CRLF is added. (For email, this is + only possible when using extensions to SMTP or non-SMTP transport + mechanisms.) + + The SHA-1 value (in base64) for an empty body (canonicalized to a + null input) is: + + 2jmj7l5rSw0yVb/vlWAYkK/YBwk= + + The SHA-256 value is: + + 47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU= + +3.4.5. Canonicalization Examples (INFORMATIVE) + + In the following examples, actual whitespace is used only for + clarity. The actual input and output text is designated using + bracketed descriptors: "" for a space character, "" for a + tab character, and "" for a carriage-return/line-feed sequence. + For example, "X Y" and "XY" represent the same three + characters. + + Example 1: A message reading: + + A: X + B : Y + Z + + C + D E + + + + when canonicalized using relaxed canonicalization for both header and + body results in a header reading: + + a:X + b:Y Z + + and a body reading: + + C + D E + + + +Crocker, et al. Standards Track [Page 17] + +RFC 6376 DKIM Signatures September 2011 + + + Example 2: The same message canonicalized using simple + canonicalization for both header and body results in a header + reading: + + A: X + B : Y + Z + + and a body reading: + + C + D E + + Example 3: When processed using relaxed header canonicalization and + simple body canonicalization, the canonicalized version has a header + of: + + a:X + b:Y Z + + and a body reading: + + C + D E + +3.5. The DKIM-Signature Header Field + + The signature of the email is stored in the DKIM-Signature header + field. This header field contains all of the signature and key- + fetching data. The DKIM-Signature value is a tag-list as described + in Section 3.2. + + The DKIM-Signature header field SHOULD be treated as though it were a + trace header field as defined in Section 3.6 of [RFC5322] and hence + SHOULD NOT be reordered and SHOULD be prepended to the message. + + The DKIM-Signature header field being created or verified is always + included in the signature calculation, after the rest of the header + fields being signed; however, when calculating or verifying the + signature, the value of the "b=" tag (signature value) of that DKIM- + Signature header field MUST be treated as though it were an empty + string. Unknown tags in the DKIM-Signature header field MUST be + included in the signature calculation but MUST be otherwise ignored + by Verifiers. Other DKIM-Signature header fields that are included + in the signature should be treated as normal header fields; in + particular, the "b=" tag is not treated specially. + + + + + +Crocker, et al. Standards Track [Page 18] + +RFC 6376 DKIM Signatures September 2011 + + + The encodings for each field type are listed below. Tags described + as qp-section are encoded as described in Section 6.7 of MIME Part + One [RFC2045], with the additional conversion of semicolon characters + to "=3B"; intuitively, this is one line of quoted-printable encoded + text. The dkim-quoted-printable syntax is defined in Section 2.11. + + Tags on the DKIM-Signature header field along with their type and + requirement status are shown below. Unrecognized tags MUST be + ignored. + + v= Version (plain-text; REQUIRED). This tag defines the version of + this specification that applies to the signature record. It MUST + have the value "1" for implementations compliant with this version + of DKIM. + + ABNF: + + sig-v-tag = %x76 [FWS] "=" [FWS] 1*DIGIT + + INFORMATIVE NOTE: DKIM-Signature version numbers may increase + arithmetically as new versions of this specification are + released. + + a= The algorithm used to generate the signature (plain-text; + REQUIRED). Verifiers MUST support "rsa-sha1" and "rsa-sha256"; + Signers SHOULD sign using "rsa-sha256". See Section 3.3 for a + description of the algorithms. + + ABNF: + + sig-a-tag = %x61 [FWS] "=" [FWS] sig-a-tag-alg + sig-a-tag-alg = sig-a-tag-k "-" sig-a-tag-h + sig-a-tag-k = "rsa" / x-sig-a-tag-k + sig-a-tag-h = "sha1" / "sha256" / x-sig-a-tag-h + x-sig-a-tag-k = ALPHA *(ALPHA / DIGIT) + ; for later extension + x-sig-a-tag-h = ALPHA *(ALPHA / DIGIT) + ; for later extension + + b= The signature data (base64; REQUIRED). Whitespace is ignored in + this value and MUST be ignored when reassembling the original + signature. In particular, the signing process can safely insert + FWS in this value in arbitrary places to conform to line-length + limits. See "Signer Actions" (Section 5) for how the signature is + computed. + + + + + + +Crocker, et al. Standards Track [Page 19] + +RFC 6376 DKIM Signatures September 2011 + + + ABNF: + + sig-b-tag = %x62 [FWS] "=" [FWS] sig-b-tag-data + sig-b-tag-data = base64string + + bh= The hash of the canonicalized body part of the message as + limited by the "l=" tag (base64; REQUIRED). Whitespace is ignored + in this value and MUST be ignored when reassembling the original + signature. In particular, the signing process can safely insert + FWS in this value in arbitrary places to conform to line-length + limits. See Section 3.7 for how the body hash is computed. + + ABNF: + + sig-bh-tag = %x62 %x68 [FWS] "=" [FWS] sig-bh-tag-data + sig-bh-tag-data = base64string + + c= Message canonicalization (plain-text; OPTIONAL, default is + "simple/simple"). This tag informs the Verifier of the type of + canonicalization used to prepare the message for signing. It + consists of two names separated by a "slash" (%d47) character, + corresponding to the header and body canonicalization algorithms, + respectively. These algorithms are described in Section 3.4. If + only one algorithm is named, that algorithm is used for the header + and "simple" is used for the body. For example, "c=relaxed" is + treated the same as "c=relaxed/simple". + + ABNF: + + sig-c-tag = %x63 [FWS] "=" [FWS] sig-c-tag-alg + ["/" sig-c-tag-alg] + sig-c-tag-alg = "simple" / "relaxed" / x-sig-c-tag-alg + x-sig-c-tag-alg = hyphenated-word ; for later extension + + d= The SDID claiming responsibility for an introduction of a message + into the mail stream (plain-text; REQUIRED). Hence, the SDID + value is used to form the query for the public key. The SDID MUST + correspond to a valid DNS name under which the DKIM key record is + published. The conventions and semantics used by a Signer to + create and use a specific SDID are outside the scope of this + specification, as is any use of those conventions and semantics. + When presented with a signature that does not meet these + requirements, Verifiers MUST consider the signature invalid. + + Internationalized domain names MUST be encoded as A-labels, as + described in Section 2.3 of [RFC5890]. + + + + + +Crocker, et al. Standards Track [Page 20] + +RFC 6376 DKIM Signatures September 2011 + + + ABNF: + + sig-d-tag = %x64 [FWS] "=" [FWS] domain-name + domain-name = sub-domain 1*("." sub-domain) + ; from [RFC5321] Domain, + ; excluding address-literal + + h= Signed header fields (plain-text, but see description; REQUIRED). + A colon-separated list of header field names that identify the + header fields presented to the signing algorithm. The field MUST + contain the complete list of header fields in the order presented + to the signing algorithm. The field MAY contain names of header + fields that do not exist when signed; nonexistent header fields do + not contribute to the signature computation (that is, they are + treated as the null input, including the header field name, the + separating colon, the header field value, and any CRLF + terminator). The field MAY contain multiple instances of a header + field name, meaning multiple occurrences of the corresponding + header field are included in the header hash. The field MUST NOT + include the DKIM-Signature header field that is being created or + verified but may include others. Folding whitespace (FWS) MAY be + included on either side of the colon separator. Header field + names MUST be compared against actual header field names in a + case-insensitive manner. This list MUST NOT be empty. See + Section 5.4 for a discussion of choosing header fields to sign and + Section 5.4.2 for requirements when signing multiple instances of + a single field. + + ABNF: + + sig-h-tag = %x68 [FWS] "=" [FWS] hdr-name + *( [FWS] ":" [FWS] hdr-name ) + + INFORMATIVE EXPLANATION: By "signing" header fields that do not + actually exist, a Signer can allow a Verifier to detect + insertion of those header fields after signing. However, since + a Signer cannot possibly know what header fields might be + defined in the future, this mechanism cannot be used to prevent + the addition of any possible unknown header fields. + + INFORMATIVE NOTE: "Signing" fields that are not present at the + time of signing not only prevents fields and values from being + added but also prevents adding fields with no values. + + i= The Agent or User Identifier (AUID) on behalf of which the SDID is + taking responsibility (dkim-quoted-printable; OPTIONAL, default is + an empty local-part followed by an "@" followed by the domain from + the "d=" tag). + + + +Crocker, et al. Standards Track [Page 21] + +RFC 6376 DKIM Signatures September 2011 + + + The syntax is a standard email address where the local-part MAY be + omitted. The domain part of the address MUST be the same as, or a + subdomain of, the value of the "d=" tag. + + Internationalized domain names MUST be encoded as A-labels, as + described in Section 2.3 of [RFC5890]. + + ABNF: + + sig-i-tag = %x69 [FWS] "=" [FWS] [ Local-part ] + "@" domain-name + + The AUID is specified as having the same syntax as an email + address but it need not have the same semantics. Notably, the + domain name need not be registered in the DNS -- so it might not + resolve in a query -- and the local-part MAY be drawn from a + namespace unrelated to any mailbox. The details of the structure + and semantics for the namespace are determined by the Signer. Any + knowledge or use of those details by Verifiers or Assessors is + outside the scope of this specification. The Signer MAY choose to + use the same namespace for its AUIDs as its users' email addresses + or MAY choose other means of representing its users. However, the + Signer SHOULD use the same AUID for each message intended to be + evaluated as being within the same sphere of responsibility, if it + wishes to offer receivers the option of using the AUID as a stable + identifier that is finer grained than the SDID. + + INFORMATIVE NOTE: The local-part of the "i=" tag is optional + because in some cases a Signer may not be able to establish a + verified individual identity. In such cases, the Signer might + wish to assert that although it is willing to go as far as + signing for the domain, it is unable or unwilling to commit to + an individual user name within the domain. It can do so by + including the domain part but not the local-part of the + identity. + + INFORMATIVE DISCUSSION: This specification does not require the + value of the "i=" tag to match the identity in any message + header fields. This is considered to be a Verifier policy + issue. Constraints between the value of the "i=" tag and other + identities in other header fields seek to apply basic + authentication into the semantics of trust associated with a + role such as content author. Trust is a broad and complex + topic, and trust mechanisms are subject to highly creative + attacks. The real-world efficacy of any but the most basic + bindings between the "i=" value and other identities is not + well established, nor is its vulnerability to subversion by an + attacker. Hence, reliance on the use of these options should + + + +Crocker, et al. Standards Track [Page 22] + +RFC 6376 DKIM Signatures September 2011 + + + be strictly limited. In particular, it is not at all clear to + what extent a typical end-user recipient can rely on any + assurances that might be made by successful use of the "i=" + options. + + l= Body length count (plain-text unsigned decimal integer; OPTIONAL, + default is entire body). This tag informs the Verifier of the + number of octets in the body of the email after canonicalization + included in the cryptographic hash, starting from 0 immediately + following the CRLF preceding the body. This value MUST NOT be + larger than the actual number of octets in the canonicalized + message body. See further discussion in Section 8.2. + + INFORMATIVE NOTE: The value of the "l=" tag is constrained to + 76 decimal digits. This constraint is not intended to predict + the size of future messages or to require implementations to + use an integer representation large enough to represent the + maximum possible value but is intended to remind the + implementer to check the length of this and all other tags + during verification and to test for integer overflow when + decoding the value. Implementers may need to limit the actual + value expressed to a value smaller than 10^76, e.g., to allow a + message to fit within the available storage space. + + ABNF: + + sig-l-tag = %x6c [FWS] "=" [FWS] + 1*76DIGIT + + q= A colon-separated list of query methods used to retrieve the + public key (plain-text; OPTIONAL, default is "dns/txt"). Each + query method is of the form "type[/options]", where the syntax and + semantics of the options depend on the type and specified options. + If there are multiple query mechanisms listed, the choice of query + mechanism MUST NOT change the interpretation of the signature. + Implementations MUST use the recognized query mechanisms in the + order presented. Unrecognized query mechanisms MUST be ignored. + + Currently, the only valid value is "dns/txt", which defines the + DNS TXT resource record (RR) lookup algorithm described elsewhere + in this document. The only option defined for the "dns" query + type is "txt", which MUST be included. Verifiers and Signers MUST + support "dns/txt". + + ABNF: + + sig-q-tag = %x71 [FWS] "=" [FWS] sig-q-tag-method + *([FWS] ":" [FWS] sig-q-tag-method) + + + +Crocker, et al. Standards Track [Page 23] + +RFC 6376 DKIM Signatures September 2011 + + + sig-q-tag-method = "dns/txt" / x-sig-q-tag-type + ["/" x-sig-q-tag-args] + x-sig-q-tag-type = hyphenated-word ; for future extension + x-sig-q-tag-args = qp-hdr-value + + s= The selector subdividing the namespace for the "d=" (domain) tag + (plain-text; REQUIRED). + + Internationalized selector names MUST be encoded as A-labels, as + described in Section 2.3 of [RFC5890]. + + ABNF: + + sig-s-tag = %x73 [FWS] "=" [FWS] selector + + t= Signature Timestamp (plain-text unsigned decimal integer; + RECOMMENDED, default is an unknown creation time). The time that + this signature was created. The format is the number of seconds + since 00:00:00 on January 1, 1970 in the UTC time zone. The value + is expressed as an unsigned integer in decimal ASCII. This value + is not constrained to fit into a 31- or 32-bit integer. + Implementations SHOULD be prepared to handle values up to at least + 10^12 (until approximately AD 200,000; this fits into 40 bits). + To avoid denial-of-service attacks, implementations MAY consider + any value longer than 12 digits to be infinite. Leap seconds are + not counted. Implementations MAY ignore signatures that have a + timestamp in the future. + + ABNF: + + sig-t-tag = %x74 [FWS] "=" [FWS] 1*12DIGIT + + x= Signature Expiration (plain-text unsigned decimal integer; + RECOMMENDED, default is no expiration). The format is the same as + in the "t=" tag, represented as an absolute date, not as a time + delta from the signing timestamp. The value is expressed as an + unsigned integer in decimal ASCII, with the same constraints on + the value in the "t=" tag. Signatures MAY be considered invalid + if the verification time at the Verifier is past the expiration + date. The verification time should be the time that the message + was first received at the administrative domain of the Verifier if + that time is reliably available; otherwise, the current time + should be used. The value of the "x=" tag MUST be greater than + the value of the "t=" tag if both are present. + + INFORMATIVE NOTE: The "x=" tag is not intended as an anti- + replay defense. + + + + +Crocker, et al. Standards Track [Page 24] + +RFC 6376 DKIM Signatures September 2011 + + + INFORMATIVE NOTE: Due to clock drift, the receiver's notion of + when to consider the signature expired may not exactly match + what the sender is expecting. Receivers MAY add a 'fudge + factor' to allow for such possible drift. + + ABNF: + + sig-x-tag = %x78 [FWS] "=" [FWS] + 1*12DIGIT + + z= Copied header fields (dkim-quoted-printable, but see description; + OPTIONAL, default is null). A vertical-bar-separated list of + selected header fields present when the message was signed, + including both the field name and value. It is not required to + include all header fields present at the time of signing. This + field need not contain the same header fields listed in the "h=" + tag. The header field text itself must encode the vertical bar + ("|", %x7C) character (i.e., vertical bars in the "z=" text are + meta-characters, and any actual vertical bar characters in a + copied header field must be encoded). Note that all whitespace + must be encoded, including whitespace between the colon and the + header field value. After encoding, FWS MAY be added at arbitrary + locations in order to avoid excessively long lines; such + whitespace is NOT part of the value of the header field and MUST + be removed before decoding. + + The header fields referenced by the "h=" tag refer to the fields + in the [RFC5322] header of the message, not to any copied fields + in the "z=" tag. Copied header field values are for diagnostic + use. + + ABNF: + + sig-z-tag = %x7A [FWS] "=" [FWS] sig-z-tag-copy + *( "|" [FWS] sig-z-tag-copy ) + sig-z-tag-copy = hdr-name [FWS] ":" qp-hdr-value + + INFORMATIVE EXAMPLE of a signature header field spread across + multiple continuation lines: + + DKIM-Signature: v=1; a=rsa-sha256; d=example.net; s=brisbane; + c=simple; q=dns/txt; i=@eng.example.net; + t=1117574938; x=1118006938; + h=from:to:subject:date; + z=From:foo@eng.example.net|To:joe@example.com| + Subject:demo=20run|Date:July=205,=202005=203:44:08=20PM=20-0700; + bh=MTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTI=; + b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZVoG4ZHRNiYzR + + + +Crocker, et al. Standards Track [Page 25] + +RFC 6376 DKIM Signatures September 2011 + + +3.6. Key Management and Representation + + Signature applications require some level of assurance that the + verification public key is associated with the claimed Signer. Many + applications achieve this by using public-key certificates issued by + a trusted third party. However, DKIM can achieve a sufficient level + of security, with significantly enhanced scalability, by simply + having the Verifier query the purported Signer's DNS entry (or some + security-equivalent) in order to retrieve the public key. + + DKIM keys can potentially be stored in multiple types of key servers + and in multiple formats. The storage and format of keys are + irrelevant to the remainder of the DKIM algorithm. + + Parameters to the key lookup algorithm are the type of the lookup + (the "q=" tag), the domain of the Signer (the "d=" tag of the DKIM- + Signature header field), and the selector (the "s=" tag). + + public_key = dkim_find_key(q_val, d_val, s_val) + + This document defines a single binding, using DNS TXT RRs to + distribute the keys. Other bindings may be defined in the future. + +3.6.1. Textual Representation + + It is expected that many key servers will choose to present the keys + in an otherwise unstructured text format (for example, an XML form + would not be considered to be unstructured text for this purpose). + The following definition MUST be used for any DKIM key represented in + an otherwise unstructured textual form. + + The overall syntax is a tag-list as described in Section 3.2. The + current valid tags are described below. Other tags MAY be present + and MUST be ignored by any implementation that does not understand + them. + + v= Version of the DKIM key record (plain-text; RECOMMENDED, default + is "DKIM1"). If specified, this tag MUST be set to "DKIM1" + (without the quotes). This tag MUST be the first tag in the + record. Records beginning with a "v=" tag with any other value + MUST be discarded. Note that Verifiers must do a string + comparison on this value; for example, "DKIM1" is not the same as + "DKIM1.0". + + ABNF: + + key-v-tag = %x76 [FWS] "=" [FWS] %x44.4B.49.4D.31 + + + + +Crocker, et al. Standards Track [Page 26] + +RFC 6376 DKIM Signatures September 2011 + + + h= Acceptable hash algorithms (plain-text; OPTIONAL, defaults to + allowing all algorithms). A colon-separated list of hash + algorithms that might be used. Unrecognized algorithms MUST be + ignored. Refer to Section 3.3 for a discussion of the hash + algorithms implemented by Signers and Verifiers. The set of + algorithms listed in this tag in each record is an operational + choice made by the Signer. + + ABNF: + + key-h-tag = %x68 [FWS] "=" [FWS] key-h-tag-alg + *( [FWS] ":" [FWS] key-h-tag-alg ) + key-h-tag-alg = "sha1" / "sha256" / x-key-h-tag-alg + x-key-h-tag-alg = hyphenated-word ; for future extension + + k= Key type (plain-text; OPTIONAL, default is "rsa"). Signers and + Verifiers MUST support the "rsa" key type. The "rsa" key type + indicates that an ASN.1 DER-encoded [ITU-X660-1997] RSAPublicKey + (see [RFC3447], Sections 3.1 and A.1.1) is being used in the "p=" + tag. (Note: the "p=" tag further encodes the value using the + base64 algorithm.) Unrecognized key types MUST be ignored. + + ABNF: + + key-k-tag = %x76 [FWS] "=" [FWS] key-k-tag-type + key-k-tag-type = "rsa" / x-key-k-tag-type + x-key-k-tag-type = hyphenated-word ; for future extension + + n= Notes that might be of interest to a human (qp-section; OPTIONAL, + default is empty). No interpretation is made by any program. + This tag should be used sparingly in any key server mechanism that + has space limitations (notably DNS). This is intended for use by + administrators, not end users. + + ABNF: + + key-n-tag = %x6e [FWS] "=" [FWS] qp-section + + p= Public-key data (base64; REQUIRED). An empty value means that + this public key has been revoked. The syntax and semantics of + this tag value before being encoded in base64 are defined by the + "k=" tag. + + INFORMATIVE RATIONALE: If a private key has been compromised or + otherwise disabled (e.g., an outsourcing contract has been + terminated), a Signer might want to explicitly state that it + knows about the selector, but all messages using that selector + + + + +Crocker, et al. Standards Track [Page 27] + +RFC 6376 DKIM Signatures September 2011 + + + should fail verification. Verifiers SHOULD return an error + code for any DKIM-Signature header field with a selector + referencing a revoked key. (See Section 6.1.2 for details.) + + ABNF: + + key-p-tag = %x70 [FWS] "=" [ [FWS] base64string] + + INFORMATIVE NOTE: A base64string is permitted to include + whitespace (FWS) at arbitrary places; however, any CRLFs must + be followed by at least one WSP character. Implementers and + administrators are cautioned to ensure that selector TXT RRs + conform to this specification. + + s= Service Type (plain-text; OPTIONAL; default is "*"). A colon- + separated list of service types to which this record applies. + Verifiers for a given service type MUST ignore this record if the + appropriate type is not listed. Unrecognized service types MUST + be ignored. Currently defined service types are as follows: + + * matches all service types + + email electronic mail (not necessarily limited to SMTP) + + This tag is intended to constrain the use of keys for other + purposes, should use of DKIM be defined by other services in the + future. + + ABNF: + + key-s-tag = %x73 [FWS] "=" [FWS] key-s-tag-type + *( [FWS] ":" [FWS] key-s-tag-type ) + key-s-tag-type = "email" / "*" / x-key-s-tag-type + x-key-s-tag-type = hyphenated-word ; for future extension + + t= Flags, represented as a colon-separated list of names (plain- + text; OPTIONAL, default is no flags set). Unrecognized flags MUST + be ignored. The defined flags are as follows: + + y This domain is testing DKIM. Verifiers MUST NOT treat messages + from Signers in testing mode differently from unsigned email, + even should the signature fail to verify. Verifiers MAY wish + to track testing mode results to assist the Signer. + + + + + + + + +Crocker, et al. Standards Track [Page 28] + +RFC 6376 DKIM Signatures September 2011 + + + s Any DKIM-Signature header fields using the "i=" tag MUST have + the same domain value on the right-hand side of the "@" in the + "i=" tag and the value of the "d=" tag. That is, the "i=" + domain MUST NOT be a subdomain of "d=". Use of this flag is + RECOMMENDED unless subdomaining is required. + + ABNF: + + key-t-tag = %x74 [FWS] "=" [FWS] key-t-tag-flag + *( [FWS] ":" [FWS] key-t-tag-flag ) + key-t-tag-flag = "y" / "s" / x-key-t-tag-flag + x-key-t-tag-flag = hyphenated-word ; for future extension + +3.6.2. DNS Binding + + A binding using DNS TXT RRs as a key service is hereby defined. All + implementations MUST support this binding. + +3.6.2.1. Namespace + + All DKIM keys are stored in a subdomain named "_domainkey". Given a + DKIM-Signature field with a "d=" tag of "example.com" and an "s=" tag + of "foo.bar", the DNS query will be for + "foo.bar._domainkey.example.com". + +3.6.2.2. Resource Record Types for Key Storage + + The DNS Resource Record type used is specified by an option to the + query-type ("q=") tag. The only option defined in this base + specification is "txt", indicating the use of a TXT RR. A later + extension of this standard may define another RR type. + + Strings in a TXT RR MUST be concatenated together before use with no + intervening whitespace. TXT RRs MUST be unique for a particular + selector name; that is, if there are multiple records in an RRset, + the results are undefined. + + TXT RRs are encoded as described in Section 3.6.1. + +3.7. Computing the Message Hashes + + Both signing and verifying message signatures start with a step of + computing two cryptographic hashes over the message. Signers will + choose the parameters of the signature as described in "Signer + Actions" (Section 5); Verifiers will use the parameters specified in + the DKIM-Signature header field being verified. In the following + discussion, the names of the tags in the DKIM-Signature header field + that either exists (when verifying) or will be created (when signing) + + + +Crocker, et al. Standards Track [Page 29] + +RFC 6376 DKIM Signatures September 2011 + + + are used. Note that canonicalization (Section 3.4) is only used to + prepare the email for signing or verifying; it does not affect the + transmitted email in any way. + + The Signer/Verifier MUST compute two hashes: one over the body of the + message and one over the selected header fields of the message. + + Signers MUST compute them in the order shown. Verifiers MAY compute + them in any order convenient to the Verifier, provided that the + result is semantically identical to the semantics that would be the + case had they been computed in this order. + + In hash step 1, the Signer/Verifier MUST hash the message body, + canonicalized using the body canonicalization algorithm specified in + the "c=" tag and then truncated to the length specified in the "l=" + tag. That hash value is then converted to base64 form and inserted + into (Signers) or compared to (Verifiers) the "bh=" tag of the DKIM- + Signature header field. + + In hash step 2, the Signer/Verifier MUST pass the following to the + hash algorithm in the indicated order. + + 1. The header fields specified by the "h=" tag, in the order + specified in that tag, and canonicalized using the header + canonicalization algorithm specified in the "c=" tag. Each + header field MUST be terminated with a single CRLF. + + 2. The DKIM-Signature header field that exists (verifying) or will + be inserted (signing) in the message, with the value of the "b=" + tag (including all surrounding whitespace) deleted (i.e., treated + as the empty string), canonicalized using the header + canonicalization algorithm specified in the "c=" tag, and without + a trailing CRLF. + + All tags and their values in the DKIM-Signature header field are + included in the cryptographic hash with the sole exception of the + value portion of the "b=" (signature) tag, which MUST be treated as + the null string. All tags MUST be included even if they might not be + understood by the Verifier. The header field MUST be presented to + the hash algorithm after the body of the message rather than with the + rest of the header fields and MUST be canonicalized as specified in + the "c=" (canonicalization) tag. The DKIM-Signature header field + MUST NOT be included in its own "h=" tag, although other DKIM- + Signature header fields MAY be signed (see Section 4). + + When calculating the hash on messages that will be transmitted using + base64 or quoted-printable encoding, Signers MUST compute the hash + after the encoding. Likewise, the Verifier MUST incorporate the + + + +Crocker, et al. Standards Track [Page 30] + +RFC 6376 DKIM Signatures September 2011 + + + values into the hash before decoding the base64 or quoted-printable + text. However, the hash MUST be computed before transport-level + encodings such as SMTP "dot-stuffing" (the modification of lines + beginning with a "." to avoid confusion with the SMTP end-of-message + marker, as specified in [RFC5321]). + + With the exception of the canonicalization procedure described in + Section 3.4, the DKIM signing process treats the body of messages as + simply a string of octets. DKIM messages MAY be either in plain-text + or in MIME format; no special treatment is afforded to MIME content. + Message attachments in MIME format MUST be included in the content + that is signed. + + More formally, pseudo-code for the signature algorithm is: + + body-hash = hash-alg (canon-body, l-param) + data-hash = hash-alg (h-headers, D-SIG, body-hash) + signature = sig-alg (d-domain, selector, data-hash) + + where: + + body-hash: is the output from hashing the body, using hash-alg. + + hash-alg: is the hashing algorithm specified in the "a" parameter. + + canon-body: is a canonicalized representation of the body, produced + using the body algorithm specified in the "c" parameter, + as defined in Section 3.4 and excluding the + DKIM-Signature field. + + l-param: is the length-of-body value of the "l" parameter. + + data-hash: is the output from using the hash-alg algorithm, to hash + the header including the DKIM-Signature header, and the + body hash. + + h-headers: is the list of headers to be signed, as specified in the + "h" parameter. + + D-SIG: is the canonicalized DKIM-Signature field itself without + the signature value portion of the parameter, that is, an + empty parameter value. + + signature: is the signature value produced by the signing algorithm. + + sig-alg: is the signature algorithm specified by the "a" + parameter. + + + + +Crocker, et al. Standards Track [Page 31] + +RFC 6376 DKIM Signatures September 2011 + + + d-domain: is the domain name specified in the "d" parameter. + + selector: is the selector value specified in the "s" parameter. + + NOTE: Many digital signature APIs provide both hashing and + application of the RSA private key using a single "sign()" + primitive. When using such an API, the last two steps in the + algorithm would probably be combined into a single call that would + perform both the "a-hash-alg" and the "sig-alg". + +3.8. Input Requirements + + A message that is not compliant with [RFC5322], [RFC2045], and + [RFC2047] can be subject to attempts by intermediaries to correct or + interpret such content. See Section 8 of [RFC4409] for examples of + changes that are commonly made. Such "corrections" may invalidate + DKIM signatures or have other undesirable effects, including some + that involve changes to the way a message is presented to an end + user. + + Accordingly, DKIM's design is predicated on valid input. Therefore, + Signers and Verifiers SHOULD take reasonable steps to ensure that the + messages they are processing are valid according to [RFC5322], + [RFC2045], and any other relevant message format standards. + + See Section 8.15 for additional discussion. + +3.9. Output Requirements + + The evaluation of each signature ends in one of three states, which + this document refers to as follows: + + SUCCESS: a successful verification + + PERMFAIL: a permanent, non-recoverable error such as a signature + verification failure + + TEMPFAIL: a temporary, recoverable error such as a DNS query timeout + + For each signature that verifies successfully or produces a TEMPFAIL + result, output of the DKIM algorithm MUST include the set of: + + o The domain name, taken from the "d=" signature tag; and + + o The result of the verification attempt for that signature. + + + + + + +Crocker, et al. Standards Track [Page 32] + +RFC 6376 DKIM Signatures September 2011 + + + The output MAY include other signature properties or result meta- + data, including PERMFAILed or otherwise ignored signatures, for use + by modules that consume those results. + + See Section 6.1 for discussion of signature validation result codes. + +3.10. Signing by Parent Domains + + In some circumstances, it is desirable for a domain to apply a + signature on behalf of any of its subdomains without the need to + maintain separate selectors (key records) in each subdomain. By + default, private keys corresponding to key records can be used to + sign messages for any subdomain of the domain in which they reside; + for example, a key record for the domain example.com can be used to + verify messages where the AUID ("i=" tag of the signature) is + sub.example.com, or even sub1.sub2.example.com. In order to limit + the capability of such keys when this is not intended, the "s" flag + MAY be set in the "t=" tag of the key record, to constrain the + validity of the domain of the AUID. If the referenced key record + contains the "s" flag as part of the "t=" tag, the domain of the AUID + ("i=" flag) MUST be the same as that of the SDID (d=) domain. If + this flag is absent, the domain of the AUID MUST be the same as, or a + subdomain of, the SDID. + +3.11. Relationship between SDID and AUID + + DKIM's primary task is to communicate from the Signer to a recipient- + side Identity Assessor a single Signing Domain Identifier (SDID) that + refers to a responsible identity. DKIM MAY optionally provide a + single responsible Agent or User Identifier (AUID). + + Hence, DKIM's mandatory output to a receive-side Identity Assessor is + a single domain name. Within the scope of its use as DKIM output, + the name has only basic domain name semantics; any possible owner- + specific semantics are outside the scope of DKIM. That is, within + its role as a DKIM identifier, additional semantics cannot be assumed + by an Identity Assessor. + + Upon successfully verifying the signature, a receive-side DKIM + Verifier MUST communicate the Signing Domain Identifier (d=) to a + consuming Identity Assessor module and MAY communicate the Agent or + User Identifier (i=) if present. + + To the extent that a receiver attempts to intuit any structured + semantics for either of the identifiers, this is a heuristic function + that is outside the scope of DKIM's specification and semantics. + + + + + +Crocker, et al. Standards Track [Page 33] + +RFC 6376 DKIM Signatures September 2011 + + + Hence, it is relegated to a higher-level service, such as a delivery- + handling filter that integrates a variety of inputs and performs + heuristic analysis of them. + + INFORMATIVE DISCUSSION: This document does not require the value + of the SDID or AUID to match an identifier in any other message + header field. This requirement is, instead, an Assessor policy + issue. The purpose of such a linkage would be to authenticate the + value in that other header field. This, in turn, is the basis for + applying a trust assessment based on the identifier value. Trust + is a broad and complex topic, and trust mechanisms are subject to + highly creative attacks. The real-world efficacy of any but the + most basic bindings between the SDID or AUID and other identities + is not well established, nor is its vulnerability to subversion by + an attacker. Hence, reliance on the use of such bindings should + be strictly limited. In particular, it is not at all clear to + what extent a typical end-user recipient can rely on any + assurances that might be made by successful use of the SDID or + AUID. + +4. Semantics of Multiple Signatures + +4.1. Example Scenarios + + There are many reasons why a message might have multiple signatures. + For example, suppose SHA-256 is in the future found to be + insufficiently strong, and DKIM usage transitions to SHA-1024. A + Signer might immediately sign using the newer algorithm but also + continue to sign using the older algorithm for interoperability with + Verifiers that had not yet upgraded. The Signer would do this by + adding two DKIM-Signature header fields, one using each algorithm. + Older Verifiers that did not recognize SHA-1024 as an acceptable + algorithm would skip that signature and use the older algorithm; + newer Verifiers could use either signature at their option and, all + other things being equal, might not even attempt to verify the other + signature. + + Similarly, a Signer might sign a message including all header fields + and no "l=" tag (to satisfy strict Verifiers) and a second time with + a limited set of header fields and an "l=" tag (in anticipation of + possible message modifications en route to other Verifiers). + Verifiers could then choose which signature they prefer. + + Of course, a message might also have multiple signatures because it + passed through multiple Signers. A common case is expected to be + that of a signed message that passes through a mailing list that also + + + + + +Crocker, et al. Standards Track [Page 34] + +RFC 6376 DKIM Signatures September 2011 + + + signs all messages. Assuming both of those signatures verify, a + recipient might choose to accept the message if either of those + signatures were known to come from trusted sources. + + In particular, recipients might choose to whitelist mailing lists to + which they have subscribed and that have acceptable anti-abuse + policies so as to accept messages sent to that list even from unknown + authors. They might also subscribe to less trusted mailing lists + (e.g., those without anti-abuse protection) and be willing to accept + all messages from specific authors but insist on doing additional + abuse scanning for other messages. + + Another related example of multiple Signers might be forwarding + services, such as those commonly associated with academic alumni + sites. For example, a recipient might have an address at + members.example.org, a site that has anti-abuse protection that is + somewhat less effective than the recipient would prefer. Such a + recipient might have specific authors whose messages would be trusted + absolutely, but messages from unknown authors that had passed the + forwarder's scrutiny would have only medium trust. + +4.2. Interpretation + + A Signer that is adding a signature to a message merely creates a new + DKIM-Signature header, using the usual semantics of the "h=" option. + A Signer MAY sign previously existing DKIM-Signature header fields + using the method described in Section 5.4 to sign trace header + fields. + + Note that Signers should be cognizant that signing DKIM-Signature + header fields may result in signature failures with intermediaries + that do not recognize that DKIM-Signature header fields are trace + header fields and unwittingly reorder them, thus breaking such + signatures. For this reason, signing existing DKIM-Signature header + fields is unadvised, albeit legal. + + INFORMATIVE NOTE: If a header field with multiple instances is + signed, those header fields are always signed from the bottom up. + Thus, it is not possible to sign only specific DKIM-Signature + header fields. For example, if the message being signed already + contains three DKIM-Signature header fields A, B, and C, it is + possible to sign all of them, B and C only, or C only, but not A + only, B only, A and B only, or A and C only. + + A Signer MAY add more than one DKIM-Signature header field using + different parameters. For example, during a transition period, a + Signer might want to produce signatures using two different hash + algorithms. + + + +Crocker, et al. Standards Track [Page 35] + +RFC 6376 DKIM Signatures September 2011 + + + Signers SHOULD NOT remove any DKIM-Signature header fields from + messages they are signing, even if they know that the signatures + cannot be verified. + + When evaluating a message with multiple signatures, a Verifier SHOULD + evaluate signatures independently and on their own merits. For + example, a Verifier that by policy chooses not to accept signatures + with deprecated cryptographic algorithms would consider such + signatures invalid. Verifiers MAY process signatures in any order of + their choice; for example, some Verifiers might choose to process + signatures corresponding to the From field in the message header + before other signatures. See Section 6.1 for more information about + signature choices. + + INFORMATIVE IMPLEMENTATION NOTE: Verifier attempts to correlate + valid signatures with invalid signatures in an attempt to guess + why a signature failed are ill-advised. In particular, there is + no general way that a Verifier can determine that an invalid + signature was ever valid. + + Verifiers SHOULD continue to check signatures until a signature + successfully verifies to the satisfaction of the Verifier. To limit + potential denial-of-service attacks, Verifiers MAY limit the total + number of signatures they will attempt to verify. + + If a Verifier module reports signatures whose evaluations produced + PERMFAIL results, Identity Assessors SHOULD ignore those signatures + (see Section 6.1), acting as though they were not present in the + message. + +5. Signer Actions + + The following steps are performed in order by Signers. + +5.1. Determine Whether the Email Should Be Signed and by Whom + + A Signer can obviously only sign email for domains for which it has a + private key and the necessary knowledge of the corresponding public + key and selector information. However, there are a number of other + reasons beyond the lack of a private key why a Signer could choose + not to sign an email. + + INFORMATIVE NOTE: A Signer can be implemented as part of any + portion of the mail system as deemed appropriate, including an + MUA, a SUBMISSION server, or an MTA. Wherever implemented, + Signers should beware of signing (and thereby asserting + responsibility for) messages that may be problematic. In + particular, within a trusted enclave, the signing domain might be + + + +Crocker, et al. Standards Track [Page 36] + +RFC 6376 DKIM Signatures September 2011 + + + derived from the header according to local policy; SUBMISSION + servers might only sign messages from users that are properly + authenticated and authorized. + + INFORMATIVE IMPLEMENTER ADVICE: SUBMISSION servers should not sign + Received header fields if the outgoing gateway MTA obfuscates + Received header fields, for example, to hide the details of + internal topology. + + If an email cannot be signed for some reason, it is a local policy + decision as to what to do with that email. + +5.2. Select a Private Key and Corresponding Selector Information + + This specification does not define the basis by which a Signer should + choose which private key and selector information to use. Currently, + all selectors are equal as far as this specification is concerned, so + the decision should largely be a matter of administrative + convenience. Distribution and management of private keys is also + outside the scope of this document. + + INFORMATIVE OPERATIONS ADVICE: A Signer should not sign with a + private key when the selector containing the corresponding public + key is expected to be revoked or removed before the Verifier has + an opportunity to validate the signature. The Signer should + anticipate that Verifiers can choose to defer validation, perhaps + until the message is actually read by the final recipient. In + particular, when rotating to a new key pair, signing should + immediately commence with the new private key, and the old public + key should be retained for a reasonable validation interval before + being removed from the key server. + +5.3. Normalize the Message to Prevent Transport Conversions + + Some messages, particularly those using 8-bit characters, are subject + to modification during transit, notably conversion to 7-bit form. + Such conversions will break DKIM signatures. In order to minimize + the chances of such breakage, Signers SHOULD convert the message to a + suitable MIME content-transfer encoding such as quoted-printable or + base64 as described in [RFC2045] before signing. Such conversion is + outside the scope of DKIM; the actual message SHOULD be converted to + 7-bit MIME by an MUA or MSA prior to presentation to the DKIM + algorithm. + + If the message is submitted to the Signer with any local encoding + that will be modified before transmission, that modification to + canonical [RFC5322] form MUST be done before signing. In particular, + bare CR or LF characters (used by some systems as a local line + + + +Crocker, et al. Standards Track [Page 37] + +RFC 6376 DKIM Signatures September 2011 + + + separator convention) MUST be converted to the SMTP-standard CRLF + sequence before the message is signed. Any conversion of this sort + SHOULD be applied to the message actually sent to the recipient(s), + not just to the version presented to the signing algorithm. + + More generally, the Signer MUST sign the message as it is expected to + be received by the Verifier rather than in some local or internal + form. + +5.3.1. Body Length Limits + + A body length count MAY be specified to limit the signature + calculation to an initial prefix of the body text, measured in + octets. If the body length count is not specified, the entire + message body is signed. + + INFORMATIVE RATIONALE: This capability is provided because it is + very common for mailing lists to add trailers to messages (e.g., + instructions on how to get off the list). Until those messages + are also signed, the body length count is a useful tool for the + Verifier since it can, as a matter of policy, accept messages + having valid signatures with extraneous data. + + The length actually hashed should be inserted in the "l=" tag of the + DKIM-Signature header field. (See Section 3.5.) + + The body length count allows the Signer of a message to permit data + to be appended to the end of the body of a signed message. The body + length count MUST be calculated following the canonicalization + algorithm; for example, any whitespace ignored by a canonicalization + algorithm is not included as part of the body length count. + + A body length count of zero means that the body is completely + unsigned. + + Signers wishing to ensure that no modification of any sort can occur + should specify the "simple" canonicalization algorithm for both + header and body and omit the body length count. + + See Section 8.2 for further discussion. + +5.4. Determine the Header Fields to Sign + + The From header field MUST be signed (that is, included in the "h=" + tag of the resulting DKIM-Signature header field). Signers SHOULD + NOT sign an existing header field likely to be legitimately modified + or removed in transit. In particular, [RFC5321] explicitly permits + + + + +Crocker, et al. Standards Track [Page 38] + +RFC 6376 DKIM Signatures September 2011 + + + modification or removal of the Return-Path header field in transit. + Signers MAY include any other header fields present at the time of + signing at the discretion of the Signer. + + INFORMATIVE OPERATIONS NOTE: The choice of which header fields to + sign is non-obvious. One strategy is to sign all existing, non- + repeatable header fields. An alternative strategy is to sign only + header fields that are likely to be displayed to or otherwise be + likely to affect the processing of the message at the receiver. A + third strategy is to sign only "well-known" headers. Note that + Verifiers may treat unsigned header fields with extreme + skepticism, including refusing to display them to the end user or + even ignoring the signature if it does not cover certain header + fields. For this reason, signing fields present in the message + such as Date, Subject, Reply-To, Sender, and all MIME header + fields are highly advised. + + The DKIM-Signature header field is always implicitly signed and MUST + NOT be included in the "h=" tag except to indicate that other + preexisting signatures are also signed. + + Signers MAY claim to have signed header fields that do not exist + (that is, Signers MAY include the header field name in the "h=" tag + even if that header field does not exist in the message). When + computing the signature, the nonexisting header field MUST be treated + as the null string (including the header field name, header field + value, all punctuation, and the trailing CRLF). + + INFORMATIVE RATIONALE: This allows Signers to explicitly assert + the absence of a header field; if that header field is added + later, the signature will fail. + + INFORMATIVE NOTE: A header field name need only be listed once + more than the actual number of that header field in a message at + the time of signing in order to prevent any further additions. + For example, if there is a single Comments header field at the + time of signing, listing Comments twice in the "h=" tag is + sufficient to prevent any number of Comments header fields from + being appended; it is not necessary (but is legal) to list + Comments three or more times in the "h=" tag. + + Refer to Section 5.4.2 for a discussion of the procedure to be + followed when canonicalizing a header with more than one instance of + a particular header field name. + + Signers need to be careful of signing header fields that might have + additional instances added later in the delivery process, since such + header fields might be inserted after the signed instance or + + + +Crocker, et al. Standards Track [Page 39] + +RFC 6376 DKIM Signatures September 2011 + + + otherwise reordered. Trace header fields (such as Received) and + Resent-* blocks are the only fields prohibited by [RFC5322] from + being reordered. In particular, since DKIM-Signature header fields + may be reordered by some intermediate MTAs, signing existing DKIM- + Signature header fields is error-prone. + + INFORMATIVE ADMONITION: Despite the fact that [RFC5322] does not + prohibit the reordering of header fields, reordering of signed + header fields with multiple instances by intermediate MTAs will + cause DKIM signatures to be broken; such antisocial behavior + should be avoided. + + INFORMATIVE IMPLEMENTER'S NOTE: Although not required by this + specification, all end-user visible header fields should be signed + to avoid possible "indirect spamming". For example, if the + Subject header field is not signed, a spammer can resend a + previously signed mail, replacing the legitimate subject with a + one-line spam. + +5.4.1. Recommended Signature Content + + The purpose of the DKIM cryptographic algorithm is to affix an + identifier to the message in a way that is both robust against normal + transit-related changes and resistant to kinds of replay attacks. An + essential aspect of satisfying these requirements is choosing what + header fields to include in the hash and what fields to exclude. + + The basic rule for choosing fields to include is to select those + fields that constitute the "core" of the message content. Hence, any + replay attack will have to include these in order to have the + signature succeed; however, with these included, the core of the + message is valid, even if sent on to new recipients. + + Common examples of fields with addresses and fields with textual + content related to the body are: + + o From (REQUIRED; see Section 5.4) + + o Reply-To + + o Subject + + o Date + + o To, Cc + + o Resent-Date, Resent-From, Resent-To, Resent-Cc + + + + +Crocker, et al. Standards Track [Page 40] + +RFC 6376 DKIM Signatures September 2011 + + + o In-Reply-To, References + + o List-Id, List-Help, List-Unsubscribe, List-Subscribe, List-Post, + List-Owner, List-Archive + + If the "l=" signature tag is in use (see Section 3.5), the Content- + Type field is also a candidate for being included as it could be + replaced in a way that causes completely different content to be + rendered to the receiving user. + + There are trade-offs in the decision of what constitutes the "core" + of the message, which for some fields is a subjective concept. + Including fields such as "Message-ID", for example, is useful if one + considers a mechanism for being able to distinguish separate + instances of the same message to be core content. Similarly, "In- + Reply-To" and "References" might be desirable to include if one + considers message threading to be a core part of the message. + + Another class of fields that may be of interest are those that convey + security-related information about the message, such as + Authentication-Results [RFC5451]. + + The basic rule for choosing fields to exclude is to select those + fields for which there are multiple fields with the same name and + fields that are modified in transit. Examples of these are: + + o Return-Path + + o Received + + o Comments, Keywords + + Note that the DKIM-Signature field is also excluded from the header + hash because its handling is specified separately. + + Typically, it is better to exclude other optional fields because of + the potential that additional fields of the same name will be + legitimately added or reordered prior to verification. There are + likely to be legitimate exceptions to this rule because of the wide + variety of application-specific header fields that might be applied + to a message, some of which are unlikely to be duplicated, modified, + or reordered. + + Signers SHOULD choose canonicalization algorithms based on the types + of messages they process and their aversion to risk. For example, + e-commerce sites sending primarily purchase receipts, which are not + expected to be processed by mailing lists or other software likely to + modify messages, will generally prefer "simple" canonicalization. + + + +Crocker, et al. Standards Track [Page 41] + +RFC 6376 DKIM Signatures September 2011 + + + Sites sending primarily person-to-person email will likely prefer to + be more resilient to modification during transport by using "relaxed" + canonicalization. + + Unless mail is processed through intermediaries, such as mailing + lists that might add "unsubscribe" instructions to the bottom of the + message body, the "l=" tag is likely to convey no additional benefit + while providing an avenue for unauthorized addition of text to a + message. The use of "l=0" takes this to the extreme, allowing + complete alteration of the text of the message without invalidating + the signature. Moreover, a Verifier would be within its rights to + consider a partly signed message body as unacceptable. Judicious use + is advised. + +5.4.2. Signatures Involving Multiple Instances of a Field + + Signers choosing to sign an existing header field that occurs more + than once in the message (such as Received) MUST sign the physically + last instance of that header field in the header block. Signers + wishing to sign multiple instances of such a header field MUST + include the header field name multiple times in the "h=" tag of the + DKIM-Signature header field and MUST sign such header fields in order + from the bottom of the header field block to the top. The Signer MAY + include more instances of a header field name in "h=" than there are + actual corresponding header fields so that the signature will not + verify if additional header fields of that name are added. + + INFORMATIVE EXAMPLE: + + If the Signer wishes to sign two existing Received header fields, + and the existing header contains: + + Received: + Received: + Received: + + then the resulting DKIM-Signature header field should read: + + DKIM-Signature: ... h=Received : Received :... + + and Received header fields and will be signed in that + order. + + + + + + + + + +Crocker, et al. Standards Track [Page 42] + +RFC 6376 DKIM Signatures September 2011 + + +5.5. Compute the Message Hash and Signature + + The Signer MUST compute the message hash as described in Section 3.7 + and then sign it using the selected public-key algorithm. This will + result in a DKIM-Signature header field that will include the body + hash and a signature of the header hash, where that header includes + the DKIM-Signature header field itself. + + Entities such as mailing list managers that implement DKIM and that + modify the message or a header field (for example, inserting + unsubscribe information) before retransmitting the message SHOULD + check any existing signature on input and MUST make such + modifications before re-signing the message. + +5.6. Insert the DKIM-Signature Header Field + + Finally, the Signer MUST insert the DKIM-Signature header field + created in the previous step prior to transmitting the email. The + DKIM-Signature header field MUST be the same as used to compute the + hash as described above, except that the value of the "b=" tag MUST + be the appropriately signed hash computed in the previous step, + signed using the algorithm specified in the "a=" tag of the DKIM- + Signature header field and using the private key corresponding to the + selector given in the "s=" tag of the DKIM-Signature header field, as + chosen above in Section 5.2. + + The DKIM-Signature header field MUST be inserted before any other + DKIM-Signature fields in the header block. + + INFORMATIVE IMPLEMENTATION NOTE: The easiest way to achieve this + is to insert the DKIM-Signature header field at the beginning of + the header block. In particular, it may be placed before any + existing Received header fields. This is consistent with treating + DKIM-Signature as a trace header field. + +6. Verifier Actions + + Since a Signer MAY remove or revoke a public key at any time, it is + advised that verification occur in a timely manner. In many + configurations, the most timely place is during acceptance by the + border MTA or shortly thereafter. In particular, deferring + verification until the message is accessed by the end user is + discouraged. + + A border or intermediate MTA MAY verify the message signature(s). An + MTA who has performed verification MAY communicate the result of that + verification by adding a verification header field to incoming + messages. This simplifies things considerably for the user, who can + + + +Crocker, et al. Standards Track [Page 43] + +RFC 6376 DKIM Signatures September 2011 + + + now use an existing mail user agent. Most MUAs have the ability to + filter messages based on message header fields or content; these + filters would be used to implement whatever policy the user wishes + with respect to unsigned mail. + + A verifying MTA MAY implement a policy with respect to unverifiable + mail, regardless of whether or not it applies the verification header + field to signed messages. + + Verifiers MUST produce a result that is semantically equivalent to + applying the steps listed in Sections 6.1, 6.1.1, and 6.1.2 in order. + In practice, several of these steps can be performed in parallel in + order to improve performance. + +6.1. Extract Signatures from the Message + + The order in which Verifiers try DKIM-Signature header fields is not + defined; Verifiers MAY try signatures in any order they like. For + example, one implementation might try the signatures in textual + order, whereas another might try signatures by identities that match + the contents of the From header field before trying other signatures. + Verifiers MUST NOT attribute ultimate meaning to the order of + multiple DKIM-Signature header fields. In particular, there is + reason to believe that some relays will reorder the header fields in + potentially arbitrary ways. + + INFORMATIVE IMPLEMENTATION NOTE: Verifiers might use the order as + a clue to signing order in the absence of any other information. + However, other clues as to the semantics of multiple signatures + (such as correlating the signing host with Received header fields) + might also be considered. + + Survivability of signatures after transit is not guaranteed, and + signatures can fail to verify through no fault of the Signer. + Therefore, a Verifier SHOULD NOT treat a message that has one or more + bad signatures and no good signatures differently from a message with + no signature at all. + + When a signature successfully verifies, a Verifier will either stop + processing or attempt to verify any other signatures, at the + discretion of the implementation. A Verifier MAY limit the number of + signatures it tries, in order to avoid denial-of-service attacks (see + Section 8.4 for further discussion). + + In the following description, text reading "return status + (explanation)" (where "status" is one of "PERMFAIL" or "TEMPFAIL") + means that the Verifier MUST immediately cease processing that + signature. The Verifier SHOULD proceed to the next signature, if one + + + +Crocker, et al. Standards Track [Page 44] + +RFC 6376 DKIM Signatures September 2011 + + + is present, and completely ignore the bad signature. If the status + is "PERMFAIL", the signature failed and should not be reconsidered. + If the status is "TEMPFAIL", the signature could not be verified at + this time but may be tried again later. A Verifier MAY either + arrange to defer the message for later processing or try another + signature; if no good signature is found and any of the signatures + resulted in a TEMPFAIL status, the Verifier MAY arrange to defer the + message for later processing. The "(explanation)" is not normative + text; it is provided solely for clarification. + + Verifiers that are prepared to validate multiple signature header + fields SHOULD proceed to the next signature header field, if one + exists. However, Verifiers MAY make note of the fact that an invalid + signature was present for consideration at a later step. + + INFORMATIVE NOTE: The rationale of this requirement is to permit + messages that have invalid signatures but also a valid signature + to work. For example, a mailing list exploder might opt to leave + the original submitter signature in place even though the exploder + knows that it is modifying the message in some way that will break + that signature, and the exploder inserts its own signature. In + this case, the message should succeed even in the presence of the + known-broken signature. + + For each signature to be validated, the following steps should be + performed in such a manner as to produce a result that is + semantically equivalent to performing them in the indicated order. + +6.1.1. Validate the Signature Header Field + + Implementers MUST meticulously validate the format and values in the + DKIM-Signature header field; any inconsistency or unexpected values + MUST cause the header field to be completely ignored and the Verifier + to return PERMFAIL (signature syntax error). Being "liberal in what + you accept" is definitely a bad strategy in this security context. + Note, however, that this does not include the existence of unknown + tags in a DKIM-Signature header field, which are explicitly + permitted. Verifiers MUST return PERMFAIL (incompatible version) + when presented a DKIM-Signature header field with a "v=" tag that is + inconsistent with this specification. + + INFORMATIVE IMPLEMENTATION NOTE: An implementation may, of course, + choose to also verify signatures generated by older versions of + this specification. + + + + + + + +Crocker, et al. Standards Track [Page 45] + +RFC 6376 DKIM Signatures September 2011 + + + If any tag listed as "required" in Section 3.5 is omitted from the + DKIM-Signature header field, the Verifier MUST ignore the DKIM- + Signature header field and return PERMFAIL (signature missing + required tag). + + INFORMATIVE NOTE: The tags listed as required in Section 3.5 are + "v=", "a=", "b=", "bh=", "d=", "h=", and "s=". Should there be a + conflict between this note and Section 3.5, Section 3.5 is + normative. + + If the DKIM-Signature header field does not contain the "i=" tag, the + Verifier MUST behave as though the value of that tag were "@d", where + "d" is the value from the "d=" tag. + + Verifiers MUST confirm that the domain specified in the "d=" tag is + the same as or a parent domain of the domain part of the "i=" tag. + If not, the DKIM-Signature header field MUST be ignored, and the + Verifier should return PERMFAIL (domain mismatch). + + If the "h=" tag does not include the From header field, the Verifier + MUST ignore the DKIM-Signature header field and return PERMFAIL (From + field not signed). + + Verifiers MAY ignore the DKIM-Signature header field and return + PERMFAIL (signature expired) if it contains an "x=" tag and the + signature has expired. + + Verifiers MAY ignore the DKIM-Signature header field if the domain + used by the Signer in the "d=" tag is not associated with a valid + signing entity. For example, signatures with "d=" values such as + "com" and "co.uk" could be ignored. The list of unacceptable domains + SHOULD be configurable. + + Verifiers MAY ignore the DKIM-Signature header field and return + PERMFAIL (unacceptable signature header) for any other reason, for + example, if the signature does not sign header fields that the + Verifier views to be essential. As a case in point, if MIME header + fields are not signed, certain attacks may be possible that the + Verifier would prefer to avoid. + +6.1.2. Get the Public Key + + The public key for a signature is needed to complete the verification + process. The process of retrieving the public key depends on the + query type as defined by the "q=" tag in the DKIM-Signature header + field. Obviously, a public key need only be retrieved if the process + of extracting the signature information is completely successful. + + + + +Crocker, et al. Standards Track [Page 46] + +RFC 6376 DKIM Signatures September 2011 + + + Details of key management and representation are described in + Section 3.6. The Verifier MUST validate the key record and MUST + ignore any public-key records that are malformed. + + NOTE: The use of a wildcard TXT RR that covers a queried DKIM + domain name will produce a response to a DKIM query that is + unlikely to be a valid DKIM key record. This problem is not + specific to DKIM and applies to many other types of queries. + Client software that processes DNS responses needs to take this + problem into account. + + When validating a message, a Verifier MUST perform the following + steps in a manner that is semantically the same as performing them in + the order indicated; in some cases, the implementation may + parallelize or reorder these steps, as long as the semantics remain + unchanged: + + 1. The Verifier retrieves the public key as described in Section 3.6 + using the algorithm in the "q=" tag, the domain from the "d=" + tag, and the selector from the "s=" tag. + + 2. If the query for the public key fails to respond, the Verifier + MAY seek a later verification attempt by returning TEMPFAIL (key + unavailable). + + 3. If the query for the public key fails because the corresponding + key record does not exist, the Verifier MUST immediately return + PERMFAIL (no key for signature). + + 4. If the query for the public key returns multiple key records, the + Verifier can choose one of the key records or may cycle through + the key records, performing the remainder of these steps on each + record at the discretion of the implementer. The order of the + key records is unspecified. If the Verifier chooses to cycle + through the key records, then the "return ..." wording in the + remainder of this section means "try the next key record, if any; + if none, return to try another signature in the usual way". + + 5. If the result returned from the query does not adhere to the + format defined in this specification, the Verifier MUST ignore + the key record and return PERMFAIL (key syntax error). Verifiers + are urged to validate the syntax of key records carefully to + avoid attempted attacks. In particular, the Verifier MUST ignore + keys with a version code ("v=" tag) that they do not implement. + + + + + + + +Crocker, et al. Standards Track [Page 47] + +RFC 6376 DKIM Signatures September 2011 + + + 6. If the "h=" tag exists in the public-key record and the hash + algorithm implied by the "a=" tag in the DKIM-Signature header + field is not included in the contents of the "h=" tag, the + Verifier MUST ignore the key record and return PERMFAIL + (inappropriate hash algorithm). + + 7. If the public-key data (the "p=" tag) is empty, then this key has + been revoked and the Verifier MUST treat this as a failed + signature check and return PERMFAIL (key revoked). There is no + defined semantic difference between a key that has been revoked + and a key record that has been removed. + + 8. If the public-key data is not suitable for use with the algorithm + and key types defined by the "a=" and "k=" tags in the DKIM- + Signature header field, the Verifier MUST immediately return + PERMFAIL (inappropriate key algorithm). + +6.1.3. Compute the Verification + + Given a Signer and a public key, verifying a signature consists of + actions semantically equivalent to the following steps. + + 1. Based on the algorithm defined in the "c=" tag, the body length + specified in the "l=" tag, and the header field names in the "h=" + tag, prepare a canonicalized version of the message as is + described in Section 3.7 (note that this canonicalized version + does not actually replace the original content). When matching + header field names in the "h=" tag against the actual message + header field, comparisons MUST be case-insensitive. + + 2. Based on the algorithm indicated in the "a=" tag, compute the + message hashes from the canonical copy as described in + Section 3.7. + + 3. Verify that the hash of the canonicalized message body computed + in the previous step matches the hash value conveyed in the "bh=" + tag. If the hash does not match, the Verifier SHOULD ignore the + signature and return PERMFAIL (body hash did not verify). + + 4. Using the signature conveyed in the "b=" tag, verify the + signature against the header hash using the mechanism appropriate + for the public-key algorithm described in the "a=" tag. If the + signature does not validate, the Verifier SHOULD ignore the + signature and return PERMFAIL (signature did not verify). + + + + + + + +Crocker, et al. Standards Track [Page 48] + +RFC 6376 DKIM Signatures September 2011 + + + 5. Otherwise, the signature has correctly verified. + + INFORMATIVE IMPLEMENTER'S NOTE: Implementations might wish to + initiate the public-key query in parallel with calculating the + hash as the public key is not needed until the final decryption is + calculated. Implementations may also verify the signature on the + message header before validating that the message hash listed in + the "bh=" tag in the DKIM-Signature header field matches that of + the actual message body; however, if the body hash does not match, + the entire signature must be considered to have failed. + + A body length specified in the "l=" tag of the signature limits the + number of bytes of the body passed to the verification algorithm. + All data beyond that limit is not validated by DKIM. Hence, + Verifiers might treat a message that contains bytes beyond the + indicated body length with suspicion and can choose to treat the + signature as if it were invalid (e.g., by returning PERMFAIL + (unsigned content)). + + Should the algorithm reach this point, the verification has + succeeded, and DKIM reports SUCCESS for this signature. + +6.2. Communicate Verification Results + + Verifiers wishing to communicate the results of verification to other + parts of the mail system may do so in whatever manner they see fit. + For example, implementations might choose to add an email header + field to the message before passing it on. Any such header field + SHOULD be inserted before any existing DKIM-Signature or preexisting + authentication status header fields in the header field block. The + Authentication-Results: header field ([RFC5451]) MAY be used for this + purpose. + + INFORMATIVE ADVICE to MUA filter writers: Patterns intended to + search for results header fields to visibly mark authenticated + mail for end users should verify that such a header field was + added by the appropriate verifying domain and that the verified + identity matches the author identity that will be displayed by the + MUA. In particular, MUA filters should not be influenced by bogus + results header fields added by attackers. To circumvent this + attack, Verifiers MAY wish to request deletion of existing results + header fields after verification and before arranging to add a new + header field. + + + + + + + + +Crocker, et al. Standards Track [Page 49] + +RFC 6376 DKIM Signatures September 2011 + + +6.3. Interpret Results/Apply Local Policy + + It is beyond the scope of this specification to describe what actions + an Identity Assessor can make, but mail carrying a validated SDID + presents an opportunity to an Identity Assessor that unauthenticated + email does not. Specifically, an authenticated email creates a + predictable identifier by which other decisions can reliably be + managed, such as trust and reputation. Conversely, unauthenticated + email lacks a reliable identifier that can be used to assign trust + and reputation. It is reasonable to treat unauthenticated email as + lacking any trust and having no positive reputation. + + In general, modules that consume DKIM verification output SHOULD NOT + determine message acceptability based solely on a lack of any + signature or on an unverifiable signature; such rejection would cause + severe interoperability problems. If an MTA does wish to reject such + messages during an SMTP session (for example, when communicating with + a peer who, by prior agreement, agrees to only send signed messages), + and a signature is missing or does not verify, the handling MTA + SHOULD use a 550/5.7.x reply code. + + Where the Verifier is integrated within the MTA and it is not + possible to fetch the public key, perhaps because the key server is + not available, a temporary failure message MAY be generated using a + 451/4.7.5 reply code, such as: + + 451 4.7.5 Unable to verify signature - key server unavailable + + Temporary failures such as inability to access the key server or + other external service are the only conditions that SHOULD use a 4xx + SMTP reply code. In particular, cryptographic signature verification + failures MUST NOT provoke 4xx SMTP replies. + + Once the signature has been verified, that information MUST be + conveyed to the Identity Assessor (such as an explicit allow/ + whitelist and reputation system) and/or to the end user. If the SDID + is not the same as the address in the From: header field, the mail + system SHOULD take pains to ensure that the actual SDID is clear to + the reader. + + While the symptoms of a failed verification are obvious -- the + signature doesn't verify -- establishing the exact cause can be more + difficult. If a selector cannot be found, is that because the + selector has been removed, or was the value changed somehow in + transit? If the signature line is missing, is that because it was + never there, or was it removed by an overzealous filter? For + diagnostic purposes, the exact reason why the verification fails + SHOULD be made available and possibly recorded in the system logs. + + + +Crocker, et al. Standards Track [Page 50] + +RFC 6376 DKIM Signatures September 2011 + + + If the email cannot be verified, then it SHOULD be treated the same + as all unverified email, regardless of whether or not it looks like + it was signed. + + See Section 8.15 for additional discussion. + +7. IANA Considerations + + DKIM has registered namespaces with IANA. In all cases, new values + are assigned only for values that have been documented in a published + RFC that has IETF Consensus [RFC5226]. + + This memo updates these registries as described below. Of note is + the addition of a new "status" column. All registrations into these + namespaces MUST include the name being registered, the document in + which it was registered or updated, and an indication of its current + status, which MUST be one of "active" (in current use) or "historic" + (no longer in current use). + + No new tags are defined in this specification compared to [RFC4871], + but one has been designated as "historic". + + Also, the "Email Authentication Methods" registry is revised to refer + to this update. + +7.1. Email Authentication Methods Registry + + The "Email Authentication Methods" registry is updated to indicate + that "dkim" is defined in this memo. + +7.2. DKIM-Signature Tag Specifications + + A DKIM-Signature provides for a list of tag specifications. IANA has + established the "DKIM-Signature Tag Specifications" registry for tag + specifications that can be used in DKIM-Signature fields. + + + + + + + + + + + + + + + + +Crocker, et al. Standards Track [Page 51] + +RFC 6376 DKIM Signatures September 2011 + + + +------+-----------------+--------+ + | TYPE | REFERENCE | STATUS | + +------+-----------------+--------+ + | v | (this document) | active | + | a | (this document) | active | + | b | (this document) | active | + | bh | (this document) | active | + | c | (this document) | active | + | d | (this document) | active | + | h | (this document) | active | + | i | (this document) | active | + | l | (this document) | active | + | q | (this document) | active | + | s | (this document) | active | + | t | (this document) | active | + | x | (this document) | active | + | z | (this document) | active | + +------+-----------------+--------+ + + Table 1: DKIM-Signature Tag Specifications Registry Updated Values + +7.3. DKIM-Signature Query Method Registry + + The "q=" tag-spec (specified in Section 3.5) provides for a list of + query methods. + + IANA has established the "DKIM-Signature Query Method" registry for + mechanisms that can be used to retrieve the key that will permit + validation processing of a message signed using DKIM. + + +------+--------+-----------------+--------+ + | TYPE | OPTION | REFERENCE | STATUS | + +------+--------+-----------------+--------+ + | dns | txt | (this document) | active | + +------+--------+-----------------+--------+ + + Table 2: DKIM-Signature Query Method Registry Updated Values + +7.4. DKIM-Signature Canonicalization Registry + + The "c=" tag-spec (specified in Section 3.5) provides for a specifier + for canonicalization algorithms for the header and body of the + message. + + IANA has established the "DKIM-Signature Canonicalization Header" + Registry for algorithms for converting a message into a canonical + form before signing or verifying using DKIM. + + + + +Crocker, et al. Standards Track [Page 52] + +RFC 6376 DKIM Signatures September 2011 + + + +---------+-----------------+--------+ + | TYPE | REFERENCE | STATUS | + +---------+-----------------+--------+ + | simple | (this document) | active | + | relaxed | (this document) | active | + +---------+-----------------+--------+ + + Table 3: DKIM-Signature Canonicalization Header Registry Updated + Values + + +---------+-----------------+--------+ + | TYPE | REFERENCE | STATUS | + +---------+-----------------+--------+ + | simple | (this document) | active | + | relaxed | (this document) | active | + +---------+-----------------+--------+ + + Table 4: DKIM-Signature Canonicalization Body Registry Updated Values + +7.5. _domainkey DNS TXT Resource Record Tag Specifications + + A _domainkey DNS TXT RR provides for a list of tag specifications. + IANA has established the DKIM "_domainkey DNS TXT Record Tag + Specifications" registry for tag specifications that can be used in + DNS TXT resource records. + + +------+-----------------+----------+ + | TYPE | REFERENCE | STATUS | + +------+-----------------+----------+ + | v | (this document) | active | + | g | [RFC4871] | historic | + | h | (this document) | active | + | k | (this document) | active | + | n | (this document) | active | + | p | (this document) | active | + | s | (this document) | active | + | t | (this document) | active | + +------+-----------------+----------+ + + Table 5: _domainkey DNS TXT Record Tag Specifications Registry + Updated Values + +7.6. DKIM Key Type Registry + + The "k=" (specified in Section 3.6.1) and the "a=" (specified in Section 3.5) tags provide for a list of + mechanisms that can be used to decode a DKIM signature. + + + + +Crocker, et al. Standards Track [Page 53] + +RFC 6376 DKIM Signatures September 2011 + + + IANA has established the "DKIM Key Type" registry for such + mechanisms. + + +------+-----------+--------+ + | TYPE | REFERENCE | STATUS | + +------+-----------+--------+ + | rsa | [RFC3447] | active | + +------+-----------+--------+ + + Table 6: DKIM Key Type Registry Updated Values + +7.7. DKIM Hash Algorithms Registry + + The "h=" (specified in Section 3.6.1) and the "a=" (specified in Section 3.5) tags provide for a list of + mechanisms that can be used to produce a digest of message data. + + IANA has established the "DKIM Hash Algorithms" registry for such + mechanisms. + + +--------+-------------------+--------+ + | TYPE | REFERENCE | STATUS | + +--------+-------------------+--------+ + | sha1 | [FIPS-180-3-2008] | active | + | sha256 | [FIPS-180-3-2008] | active | + +--------+-------------------+--------+ + + Table 7: DKIM Hash Algorithms Registry Updated Values + +7.8. DKIM Service Types Registry + + The "s=" tag (specified in Section 3.6.1) provides for a + list of service types to which this selector may apply. + + IANA has established the "DKIM Service Types" registry for service + types. + + +-------+-----------------+--------+ + | TYPE | REFERENCE | STATUS | + +-------+-----------------+--------+ + | email | (this document) | active | + | * | (this document) | active | + +-------+-----------------+--------+ + + Table 8: DKIM Service Types Registry Updated Values + + + + + + +Crocker, et al. Standards Track [Page 54] + +RFC 6376 DKIM Signatures September 2011 + + +7.9. DKIM Selector Flags Registry + + The "t=" tag (specified in Section 3.6.1) provides for a + list of flags to modify interpretation of the selector. + + IANA has established the "DKIM Selector Flags" registry for + additional flags. + + +------+-----------------+--------+ + | TYPE | REFERENCE | STATUS | + +------+-----------------+--------+ + | y | (this document) | active | + | s | (this document) | active | + +------+-----------------+--------+ + + Table 9: DKIM Selector Flags Registry Updated Values + +7.10. DKIM-Signature Header Field + + IANA has added DKIM-Signature to the "Permanent Message Header Field + Names" registry (see [RFC3864]) for the "mail" protocol, using this + document as the reference. + +8. Security Considerations + + It has been observed that any introduced mechanism that attempts to + stem the flow of spam is subject to intensive attack. DKIM needs to + be carefully scrutinized to identify potential attack vectors and the + vulnerability to each. See also [RFC4686]. + +8.1. ASCII Art Attacks + + The relaxed body canonicalization algorithm may enable certain types + of extremely crude "ASCII Art" attacks where a message may be + conveyed by adjusting the spacing between words. If this is a + concern, the "simple" body canonicalization algorithm should be used + instead. + +8.2. Misuse of Body Length Limits ("l=" Tag) + + Use of the "l=" tag might allow display of fraudulent content without + appropriate warning to end users. The "l=" tag is intended for + increasing signature robustness when sending to mailing lists that + both modify their content and do not sign their modified messages. + However, using the "l=" tag enables attacks in which an intermediary + with malicious intent can modify a message to include content that + solely benefits the attacker. It is possible for the appended + + + + +Crocker, et al. Standards Track [Page 55] + +RFC 6376 DKIM Signatures September 2011 + + + content to completely replace the original content in the end + recipient's eyes and to defeat duplicate message detection + algorithms. + + An example of such an attack includes altering the MIME structure, + exploiting lax HTML parsing in the MUA, and defeating duplicate + message detection algorithms. + + To avoid this attack, Signers should be extremely wary of using this + tag, and Assessors might wish to ignore signatures that use the tag. + +8.3. Misappropriated Private Key + + As with any other security application that uses private- or public- + key pairs, DKIM requires caution around the handling and protection + of keys. A compromised private key or access to one means an + intruder or malware can send mail signed by the domain that + advertises the matching public key. + + Thus, private keys issued to users, rather than one used by an + ADministrative Management Domain (ADMD) itself, create the usual + problem of securing data stored on personal resources that can affect + the ADMD. + + A more secure architecture involves sending messages through an + outgoing MTA that can authenticate the submitter using existing + techniques (e.g., SMTP Authentication), possibly validate the message + itself (e.g., verify that the header is legitimate and that the + content passes a spam content check), and sign the message using a + key appropriate for the submitter address. Such an MTA can also + apply controls on the volume of outgoing mail each user is permitted + to originate in order to further limit the ability of malware to + generate bulk email. + +8.4. Key Server Denial-of-Service Attacks + + Since the key servers are distributed (potentially separate for each + domain), the number of servers that would need to be attacked to + defeat this mechanism on an Internet-wide basis is very large. + Nevertheless, key servers for individual domains could be attacked, + impeding the verification of messages from that domain. This is not + significantly different from the ability of an attacker to deny + service to the mail exchangers for a given domain, although it + affects outgoing, not incoming, mail. + + A variation on this attack involves a very large amount of mail being + sent using spoofed signatures from a given domain: the key servers + for that domain could be overwhelmed with requests in a denial-of- + + + +Crocker, et al. Standards Track [Page 56] + +RFC 6376 DKIM Signatures September 2011 + + + service attack (see [RFC4732]). However, given the low overhead of + verification compared with handling of the email message itself, such + an attack would be difficult to mount. + +8.5. Attacks against the DNS + + Since the DNS is a required binding for key services, specific + attacks against the DNS must be considered. + + While the DNS is currently insecure [RFC3833], these security + problems are the motivation behind DNS Security (DNSSEC) [RFC4033], + and all users of the DNS will reap the benefit of that work. + + DKIM is only intended as a "sufficient" method of proving + authenticity. It is not intended to provide strong cryptographic + proof about authorship or contents. Other technologies such as + OpenPGP [RFC4880] and S/MIME [RFC5751] address those requirements. + + A second security issue related to the DNS revolves around the + increased DNS traffic as a consequence of fetching selector-based + data as well as fetching signing domain policy. Widespread + deployment of DKIM will result in a significant increase in DNS + queries to the claimed signing domain. In the case of forgeries on a + large scale, DNS servers could see a substantial increase in queries. + + A specific DNS security issue that should be considered by DKIM + Verifiers is the name chaining attack described in Section 2.3 of + [RFC3833]. A DKIM Verifier, while verifying a DKIM-Signature header + field, could be prompted to retrieve a key record of an attacker's + choosing. This threat can be minimized by ensuring that name + servers, including recursive name servers, used by the Verifier + enforce strict checking of "glue" and other additional information in + DNS responses and are therefore not vulnerable to this attack. + +8.6. Replay/Spam Attacks + + In this attack, a spammer sends a piece of spam through an MTA that + signs it, banking on the reputation of the signing domain (e.g., a + large popular mailbox provider) rather than its own, and then re- + sends that message to a large number of intended recipients. The + recipients observe the valid signature from the well-known domain, + elevating their trust in the message and increasing the likelihood of + delivery and presentation to the user. + + Partial solutions to this problem involve the use of reputation + services to convey the fact that the specific email address is being + used for spam and that messages from that Signer are likely to be + spam. This requires a real-time detection mechanism in order to + + + +Crocker, et al. Standards Track [Page 57] + +RFC 6376 DKIM Signatures September 2011 + + + react quickly enough. However, such measures might be prone to + abuse, if, for example, an attacker re-sent a large number of + messages received from a victim in order to make the victim appear to + be a spammer. + + Large Verifiers might be able to detect unusually large volumes of + mails with the same signature in a short time period. Smaller + Verifiers can get substantially the same volume of information via + existing collaborative systems. + +8.7. Limits on Revoking Keys + + When a large domain detects undesirable behavior on the part of one + of its users, it might wish to revoke the key used to sign that + user's messages in order to disavow responsibility for messages that + have not yet been verified or that are the subject of a replay + attack. However, the ability of the domain to do so can be limited + if the same key, for scalability reasons, is used to sign messages + for many other users. Mechanisms for explicitly revoking keys on a + per-address basis have been proposed but require further study as to + their utility and the DNS load they represent. + +8.8. Intentionally Malformed Key Records + + It is possible for an attacker to publish key records in DNS that are + intentionally malformed, with the intent of causing a denial-of- + service attack on a non-robust Verifier implementation. The attacker + could then cause a Verifier to read the malformed key record by + sending a message to one of its users referencing the malformed + record in a (not necessarily valid) signature. Verifiers MUST + thoroughly verify all key records retrieved from the DNS and be + robust against intentionally as well as unintentionally malformed key + records. + +8.9. Intentionally Malformed DKIM-Signature Header Fields + + Verifiers MUST be prepared to receive messages with malformed DKIM- + Signature header fields and thoroughly verify the header field before + depending on any of its contents. + +8.10. Information Leakage + + An attacker could determine when a particular signature was verified + by using a per-message selector and then monitoring their DNS traffic + for the key lookup. This would act as the equivalent of a "web bug" + for verification time rather than the time the message was read. + + + + + +Crocker, et al. Standards Track [Page 58] + +RFC 6376 DKIM Signatures September 2011 + + +8.11. Remote Timing Attacks + + In some cases, it may be possible to extract private keys using a + remote timing attack [BONEH03]. Implementations should consider + obfuscating the timing to prevent such attacks. + +8.12. Reordered Header Fields + + Existing standards allow intermediate MTAs to reorder header fields. + If a Signer signs two or more header fields of the same name, this + can cause spurious verification errors on otherwise legitimate + messages. In particular, Signers that sign any existing DKIM- + Signature fields run the risk of having messages incorrectly fail to + verify. + +8.13. RSA Attacks + + An attacker could create a large RSA signing key with a small + exponent, thus requiring that the verification key have a large + exponent. This will force Verifiers to use considerable computing + resources to verify the signature. Verifiers might avoid this attack + by refusing to verify signatures that reference selectors with public + keys having unreasonable exponents. + + In general, an attacker might try to overwhelm a Verifier by flooding + it with messages requiring verification. This is similar to other + MTA denial-of-service attacks and should be dealt with in a similar + fashion. + +8.14. Inappropriate Signing by Parent Domains + + The trust relationship described in Section 3.10 could conceivably be + used by a parent domain to sign messages with identities in a + subdomain not administratively related to the parent. For example, + the ".com" registry could create messages with signatures using an + "i=" value in the example.com domain. There is no general solution + to this problem, since the administrative cut could occur anywhere in + the domain name. For example, in the domain "example.podunk.ca.us", + there are three administrative cuts (podunk.ca.us, ca.us, and us), + any of which could create messages with an identity in the full + domain. + + INFORMATIVE NOTE: This is considered an acceptable risk for the + same reason that it is acceptable for domain delegation. For + example, in the case above, any of the domains could potentially + simply delegate "example.podunk.ca.us" to a server of their choice + + + + + +Crocker, et al. Standards Track [Page 59] + +RFC 6376 DKIM Signatures September 2011 + + + and completely replace all DNS-served information. Note that a + Verifier MAY ignore signatures that come from an unlikely domain + such as ".com", as discussed in Section 6.1.1. + +8.15. Attacks Involving Extra Header Fields + + Many email components, including MTAs, MSAs, MUAs, and filtering + modules, implement message format checks only loosely. This is done + out of years of industry pressure to be liberal in what is accepted + into the mail stream for the sake of reducing support costs; + improperly formed messages are often silently fixed in transit, + delivered unrepaired, or displayed inappropriately (e.g., by showing + only the first of multiple From: fields). + + Agents that evaluate or apply DKIM output need to be aware that a + DKIM Signer can sign messages that are malformed (e.g., violate + [RFC5322], such as by having multiple instances of a field that is + only permitted once), that become malformed in transit, or that + contain header or body content that is not true or valid. Use of + DKIM on such messages might constitute an attack against a receiver, + especially where additional credence is given to a signed message + without adequate evaluation of the Signer. + + These can represent serious attacks, but they have nothing to do with + DKIM; they are attacks on the recipient or on the wrongly identified + author. + + Moreover, an agent would be incorrect to infer that all instances of + a header field are signed just because one is. + + A genuine signature from the domain under attack can be obtained by + legitimate means, but extra header fields can then be added, either + by interception or by replay. In this scenario, DKIM can aid in + detecting addition of specific fields in transit. This is done by + having the Signer list the field name(s) in the "h=" tag an extra + time (e.g., "h=from:from:..." for a message with one From field), so + that addition of an instance of that field downstream will render the + signature unable to be verified. (See Section 3.5 for details.) + This, in essence, is an explicit indication that the Signer + repudiates responsibility for such a malformed message. + + DKIM signs and validates the data it is told to and works correctly. + So in this case, DKIM has done its job of delivering a validated + domain (the "d=" value) and, given the semantics of a DKIM signature, + essentially the Signer has taken some responsibility for a + problematic message. It is up to the Identity Assessor or some other + + + + + +Crocker, et al. Standards Track [Page 60] + +RFC 6376 DKIM Signatures September 2011 + + + subsequent agent to act on such messages as needed, such as degrading + the trust of the message (or, indeed, of the Signer), warning the + recipient, or even refusing delivery. + + All components of the mail system that perform loose enforcement of + other mail standards will need to revisit that posture when + incorporating DKIM, especially when considering matters of potential + attacks such as those described. + +9. References + +9.1. Normative References + + [FIPS-180-3-2008] + U.S. Department of Commerce, "Secure Hash Standard", FIPS + PUB 180-3, October 2008. + + [ITU-X660-1997] + "Information Technology - ASN.1 encoding rules: + Specification of Basic Encoding Rules (BER), Canonical + Encoding Rules (CER) and Distinguished Encoding Rules + (DER)", 1997. + + [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", + STD 13, RFC 1034, November 1987. + + [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail + Extensions (MIME) Part One: Format of Internet Message + Bodies", RFC 2045, November 1996. + + [RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet Mail + Extensions (MIME) Part Five: Conformance Criteria and + Examples", RFC 2049, November 1996. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography + Standards (PKCS) #1: RSA Cryptography Specifications + Version 2.1", RFC 3447, February 2003. + + [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax + Specifications: ABNF", STD 68, RFC 5234, January 2008. + + [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, + October 2008. + + + + + +Crocker, et al. Standards Track [Page 61] + +RFC 6376 DKIM Signatures September 2011 + + + [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, + October 2008. + + [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, + July 2009. + + [RFC5890] Klensin, J., "Internationalized Domain Names for + Applications (IDNA): Definitions and Document Framework", + RFC 5890, August 2010. + +9.2. Informative References + + [BONEH03] "Remote Timing Attacks are Practical", Proceedings 12th + USENIX Security Symposium, 2003. + + [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) + Part Three: Message Header Extensions for Non-ASCII Text", + RFC 2047, November 1996. + + [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO + 10646", STD 63, RFC 3629, November 2003. + + [RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For + Public Keys Used For Exchanging Symmetric Keys", BCP 86, + RFC 3766, April 2004. + + [RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain + Name System (DNS)", RFC 3833, August 2004. + + [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration + Procedures for Message Header Fields", BCP 90, RFC 3864, + September 2004. + + [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. + Rose, "DNS Security Introduction and Requirements", + RFC 4033, March 2005. + + [RFC4409] Gellens, R. and J. Klensin, "Message Submission for Mail", + RFC 4409, April 2006. + + [RFC4686] Fenton, J., "Analysis of Threats Motivating DomainKeys + Identified Mail (DKIM)", RFC 4686, September 2006. + + [RFC4732] Handley, M., Rescorla, E., and IAB, "Internet Denial-of- + Service Considerations", RFC 4732, December 2006. + + + + + + +Crocker, et al. Standards Track [Page 62] + +RFC 6376 DKIM Signatures September 2011 + + + [RFC4870] Delany, M., "Domain-Based Email Authentication Using + Public Keys Advertised in the DNS (DomainKeys)", RFC 4870, + May 2007. + + [RFC4871] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, + J., and M. Thomas, "DomainKeys Identified Mail (DKIM) + Signatures", RFC 4871, May 2007. + + [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. + Thayer, "OpenPGP Message Format", RFC 4880, November 2007. + + [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an + IANA Considerations Section in RFCs", BCP 26, RFC 5226, + May 2008. + + [RFC5451] Kucherawy, M., "Message Header Field for Indicating + Message Authentication Status", RFC 5451, April 2009. + + [RFC5585] Hansen, T., Crocker, D., and P. Hallam-Baker, "DomainKeys + Identified Mail (DKIM) Service Overview", RFC 5585, + July 2009. + + [RFC5672] Crocker, D., "RFC 4871 DomainKeys Identified Mail (DKIM) + Signatures -- Update", RFC 5672, August 2009. + + [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet + Mail Extensions (S/MIME) Version 3.2 Message + Specification", RFC 5751, January 2010. + + [RFC5863] Hansen, T., Siegel, E., Hallam-Baker, P., and D. Crocker, + "DomainKeys Identified Mail (DKIM) Development, + Deployment, and Operations", RFC 5863, May 2010. + + [RFC6377] Kucherawy, M., "DomainKeys Identified Mail (DKIM) and + Mailing Lists", RFC 6377, September 2011. + + + + + + + + + + + + + + + + +Crocker, et al. Standards Track [Page 63] + +RFC 6376 DKIM Signatures September 2011 + + +Appendix A. Example of Use (INFORMATIVE) + + This section shows the complete flow of an email from submission to + final delivery, demonstrating how the various components fit + together. The key used in this example is shown in Appendix C. + +A.1. The User Composes an Email + + From: Joe SixPack + To: Suzie Q + Subject: Is dinner ready? + Date: Fri, 11 Jul 2003 21:00:37 -0700 (PDT) + Message-ID: <20030712040037.46341.5F8J@football.example.com> + + Hi. + + We lost the game. Are you hungry yet? + + Joe. + + Figure 1: The User Composes an Email + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Crocker, et al. Standards Track [Page 64] + +RFC 6376 DKIM Signatures September 2011 + + +A.2. The Email is Signed + + This email is signed by the example.com outbound email server and now + looks like this: + + DKIM-Signature: v=1; a=rsa-sha256; s=brisbane; d=example.com; + c=simple/simple; q=dns/txt; i=joe@football.example.com; + h=Received : From : To : Subject : Date : Message-ID; + bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=; + b=AuUoFEfDxTDkHlLXSZEpZj79LICEps6eda7W3deTVFOk4yAUoqOB + 4nujc7YopdG5dWLSdNg6xNAZpOPr+kHxt1IrE+NahM6L/LbvaHut + KVdkLLkpVaVVQPzeRDI009SO2Il5Lu7rDNH6mZckBdrIx0orEtZV + 4bmp/YzhwvcubU4=; + Received: from client1.football.example.com [192.0.2.1] + by submitserver.example.com with SUBMISSION; + Fri, 11 Jul 2003 21:01:54 -0700 (PDT) + From: Joe SixPack + To: Suzie Q + Subject: Is dinner ready? + Date: Fri, 11 Jul 2003 21:00:37 -0700 (PDT) + Message-ID: <20030712040037.46341.5F8J@football.example.com> + + Hi. + + We lost the game. Are you hungry yet? + + Joe. + + Figure 2: The Email is Signed + + The signing email server requires access to the private key + associated with the "brisbane" selector to generate this signature. + + + + + + + + + + + + + + + + + + + +Crocker, et al. Standards Track [Page 65] + +RFC 6376 DKIM Signatures September 2011 + + +A.3. The Email Signature is Verified + + The signature is normally verified by an inbound SMTP server or + possibly the final delivery agent. However, intervening MTAs can + also perform this verification if they choose to do so. The + verification process uses the domain "example.com" extracted from the + "d=" tag and the selector "brisbane" from the "s=" tag in the DKIM- + Signature header field to form the DNS DKIM query for: + brisbane._domainkey.example.com + + Signature verification starts with the physically last Received + header field, the From header field, and so forth, in the order + listed in the "h=" tag. Verification follows with a single CRLF + followed by the body (starting with "Hi."). The email is canonically + prepared for verifying with the "simple" method. The result of the + query and subsequent verification of the signature is stored (in this + example) in the X-Authentication-Results header field line. After + successful verification, the email looks like this: + + X-Authentication-Results: shopping.example.net + header.from=joe@football.example.com; dkim=pass + Received: from mout23.football.example.com (192.168.1.1) + by shopping.example.net with SMTP; + Fri, 11 Jul 2003 21:01:59 -0700 (PDT) + DKIM-Signature: v=1; a=rsa-sha256; s=brisbane; d=example.com; + c=simple/simple; q=dns/txt; i=joe@football.example.com; + h=Received : From : To : Subject : Date : Message-ID; + bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=; + b=AuUoFEfDxTDkHlLXSZEpZj79LICEps6eda7W3deTVFOk4yAUoqOB + 4nujc7YopdG5dWLSdNg6xNAZpOPr+kHxt1IrE+NahM6L/LbvaHut + KVdkLLkpVaVVQPzeRDI009SO2Il5Lu7rDNH6mZckBdrIx0orEtZV + 4bmp/YzhwvcubU4=; + Received: from client1.football.example.com [192.0.2.1] + by submitserver.example.com with SUBMISSION; + Fri, 11 Jul 2003 21:01:54 -0700 (PDT) + From: Joe SixPack + To: Suzie Q + Subject: Is dinner ready? + Date: Fri, 11 Jul 2003 21:00:37 -0700 (PDT) + Message-ID: <20030712040037.46341.5F8J@football.example.com> + + Hi. + + We lost the game. Are you hungry yet? + + Joe. + + Figure 3: Successful Verification + + + +Crocker, et al. Standards Track [Page 66] + +RFC 6376 DKIM Signatures September 2011 + + +Appendix B. Usage Examples (INFORMATIVE) + + DKIM signing and validating can be used in different ways, for + different operational scenarios. This Appendix discusses some common + examples. + + NOTE: Descriptions in this Appendix are for informational purposes + only. They describe various ways that DKIM can be used, given + particular constraints and needs. In no case are these examples + intended to be taken as providing explanation or guidance + concerning DKIM specification details when creating an + implementation. + +B.1. Alternate Submission Scenarios + + In the most simple scenario, a user's MUA, MSA, and Internet + (boundary) MTA are all within the same administrative environment, + using the same domain name. Therefore, all of the components + involved in submission and initial transfer are related. However, it + is common for two or more of the components to be under independent + administrative control. This creates challenges for choosing and + administering the domain name to use for signing and for its + relationship to common email identity header fields. + +B.1.1. Delegated Business Functions + + Some organizations assign specific business functions to discrete + groups, inside or outside the organization. The goal, then, is to + authorize that group to sign some mail but to constrain what + signatures they can generate. DKIM selectors (the "s=" signature + tag) facilitate this kind of restricted authorization. Examples of + these outsourced business functions are legitimate email marketing + providers and corporate benefits providers. + + Here, the delegated group needs to be able to send messages that are + signed, using the email domain of the client company. At the same + time, the client often is reluctant to register a key for the + provider that grants the ability to send messages for arbitrary + addresses in the domain. + + There are multiple ways to administer these usage scenarios. In one + case, the client organization provides all of the public query + service (for example, DNS) administration, and in another, it uses + DNS delegation to enable all ongoing administration of the DKIM key + record by the delegated group. + + + + + + +Crocker, et al. Standards Track [Page 67] + +RFC 6376 DKIM Signatures September 2011 + + + If the client organization retains responsibility for all of the DNS + administration, the outsourcing company can generate a key pair, + supplying the public key to the client company, which then registers + it in the query service using a unique selector. The client company + retains control over the use of the delegated key because it retains + the ability to revoke the key at any time. + + If the client wants the delegated group to do the DNS administration, + it can have the domain name that is specified with the selector point + to the provider's DNS server. The provider then creates and + maintains all of the DKIM signature information for that selector. + Hence, the client cannot provide constraints on the local-part of + addresses that get signed, but it can revoke the provider's signing + rights by removing the DNS delegation record. + +B.1.2. PDAs and Similar Devices + + PDAs demonstrate the need for using multiple keys per domain. + Suppose that John Doe wants to be able to send messages using his + corporate email address, jdoe@example.com, and his email device does + not have the ability to make a Virtual Private Network (VPN) + connection to the corporate network, either because the device is + limited or because there are restrictions enforced by his Internet + access provider. If the device is equipped with a private key + registered for jdoe@example.com by the administrator of the + example.com domain and appropriate software to sign messages, John + could sign the message on the device itself before transmission + through the outgoing network of the access service provider. + +B.1.3. Roaming Users + + Roaming users often find themselves in circumstances where it is + convenient or necessary to use an SMTP server other than their home + server; examples are conferences and many hotels. In such + circumstances, a signature that is added by the submission service + will use an identity that is different from the user's home system. + + Ideally, roaming users would connect back to their home server using + either a VPN or a SUBMISSION server running with SMTP AUTHentication + on port 587. If the signing can be performed on the roaming user's + laptop, then they can sign before submission, although the risk of + further modification is high. If neither of these are possible, + these roaming users will not be able to send mail signed using their + own domain key. + + + + + + + +Crocker, et al. Standards Track [Page 68] + +RFC 6376 DKIM Signatures September 2011 + + +B.1.4. Independent (Kiosk) Message Submission + + Stand-alone services, such as walk-up kiosks and web-based + information services, have no enduring email service relationship + with the user, but users occasionally request that mail be sent on + their behalf. For example, a website providing news often allows the + reader to forward a copy of the article to a friend. This is + typically done using the reader's own email address, to indicate who + the author is. This is sometimes referred to as the "Evite" problem, + named after the website of the same name that allows a user to send + invitations to friends. + + A common way this is handled is to continue to put the reader's email + address in the From header field of the message but put an address + owned by the email posting site into the Sender header field. The + posting site can then sign the message, using the domain that is in + the Sender field. This provides useful information to the receiving + email site, which is able to correlate the signing domain with the + initial submission email role. + + Receiving sites often wish to provide their end users with + information about mail that is mediated in this fashion. Although + the real efficacy of different approaches is a subject for human + factors usability research, one technique that is used is for the + verifying system to rewrite the From header field to indicate the + address that was verified, for example: From: John Doe via + news@news-site.example . (Note that such rewriting + will break a signature, unless it is done after the verification pass + is complete.) + +B.2. Alternate Delivery Scenarios + + Email is often received at a mailbox that has an address different + from the one used during initial submission. In these cases, an + intermediary mechanism operates at the address originally used, and + it then passes the message on to the final destination. This + mediation process presents some challenges for DKIM signatures. + +B.2.1. Affinity Addresses + + "Affinity addresses" allow a user to have an email address that + remains stable, even as the user moves among different email + providers. They are typically associated with college alumni + associations, professional organizations, and recreational + organizations with which they expect to have a long-term + relationship. These domains usually provide forwarding of incoming + email, and they often have an associated Web application that + authenticates the user and allows the forwarding address to be + + + +Crocker, et al. Standards Track [Page 69] + +RFC 6376 DKIM Signatures September 2011 + + + changed. However, these services usually depend on users sending + outgoing messages through their own service provider's MTAs. Hence, + mail that is signed with the domain of the affinity address is not + signed by an entity that is administered by the organization owning + that domain. + + With DKIM, affinity domains could use the Web application to allow + users to register per-user keys to be used to sign messages on behalf + of their affinity address. The user would take away the secret half + of the key pair for signing, and the affinity domain would publish + the public half in DNS for access by Verifiers. + + This is another application that takes advantage of user-level + keying, and domains used for affinity addresses would typically have + a very large number of user-level keys. Alternatively, the affinity + domain could handle outgoing mail, operating a mail submission agent + that authenticates users before accepting and signing messages for + them. This is, of course, dependent on the user's service provider + not blocking the relevant TCP ports used for mail submission. + +B.2.2. Simple Address Aliasing (.forward) + + In some cases, a recipient is allowed to configure an email address + to cause automatic redirection of email messages from the original + address to another, such as through the use of a Unix .forward file. + In this case, messages are typically redirected by the mail handling + service of the recipient's domain, without modification, except for + the addition of a Received header field to the message and a change + in the envelope recipient address. In this case, the recipient at + the final address' mailbox is likely to be able to verify the + original signature since the signed content has not changed, and DKIM + is able to validate the message signature. + +B.2.3. Mailing Lists and Re-Posters + + There is a wide range of behaviors in services that take delivery of + a message and then resubmit it. A primary example is with mailing + lists (collectively called "forwarders" below), ranging from those + that make no modification to the message itself, other than to add a + Received header field and change the envelope information, to those + that add header fields, change the Subject header field, add content + to the body (typically at the end), or reformat the body in some + manner. The simple ones produce messages that are quite similar to + the automated alias services. More elaborate systems essentially + create a new message. + + + + + + +Crocker, et al. Standards Track [Page 70] + +RFC 6376 DKIM Signatures September 2011 + + + A Forwarder that does not modify the body or signed header fields of + a message is likely to maintain the validity of the existing + signature. It also could choose to add its own signature to the + message. + + Forwarders that modify a message in a way that could make an existing + signature invalid are particularly good candidates for adding their + own signatures (e.g., mailing-list-name@example.net). Since + (re-)signing is taking responsibility for the content of the message, + these signing forwarders are likely to be selective and forward or + re-sign a message only if it is received with a valid signature or if + they have some other basis for knowing that the message is not + spoofed. + + A common practice among systems that are primarily redistributors of + mail is to add a Sender header field to the message to identify the + address being used to sign the message. This practice will remove + any preexisting Sender header field as required by [RFC5322]. The + forwarder applies a new DKIM-Signature header field with the + signature, public key, and related information of the forwarder. + + See [RFC6377] for additional related topics and discussion. + +Appendix C. Creating a Public Key (INFORMATIVE) + + The default signature is an RSA-signed SHA-256 digest of the complete + email. For ease of explanation, the openssl command is used to + describe the mechanism by which keys and signatures are managed. One + way to generate a 1024-bit, unencrypted private key suitable for DKIM + is to use openssl like this: + + $ openssl genrsa -out rsa.private 1024 + + For increased security, the "-passin" parameter can also be added to + encrypt the private key. Use of this parameter will require entering + a password for several of the following steps. Servers may prefer to + use hardware cryptographic support. + + The "genrsa" step results in the file rsa.private containing the key + information similar to this: + + + + + + + + + + + +Crocker, et al. Standards Track [Page 71] + +RFC 6376 DKIM Signatures September 2011 + + + -----BEGIN RSA PRIVATE KEY----- + MIICXwIBAAKBgQDwIRP/UC3SBsEmGqZ9ZJW3/DkMoGeLnQg1fWn7/zYtIxN2SnFC + jxOCKG9v3b4jYfcTNh5ijSsq631uBItLa7od+v/RtdC2UzJ1lWT947qR+Rcac2gb + to/NMqJ0fzfVjH4OuKhitdY9tf6mcwGjaNBcWToIMmPSPDdQPNUYckcQ2QIDAQAB + AoGBALmn+XwWk7akvkUlqb+dOxyLB9i5VBVfje89Teolwc9YJT36BGN/l4e0l6QX + /1//6DWUTB3KI6wFcm7TWJcxbS0tcKZX7FsJvUz1SbQnkS54DJck1EZO/BLa5ckJ + gAYIaqlA9C0ZwM6i58lLlPadX/rtHb7pWzeNcZHjKrjM461ZAkEA+itss2nRlmyO + n1/5yDyCluST4dQfO8kAB3toSEVc7DeFeDhnC1mZdjASZNvdHS4gbLIA1hUGEF9m + 3hKsGUMMPwJBAPW5v/U+AWTADFCS22t72NUurgzeAbzb1HWMqO4y4+9Hpjk5wvL/ + eVYizyuce3/fGke7aRYw/ADKygMJdW8H/OcCQQDz5OQb4j2QDpPZc0Nc4QlbvMsj + 7p7otWRO5xRa6SzXqqV3+F0VpqvDmshEBkoCydaYwc2o6WQ5EBmExeV8124XAkEA + qZzGsIxVP+sEVRWZmW6KNFSdVUpk3qzK0Tz/WjQMe5z0UunY9Ax9/4PVhp/j61bf + eAYXunajbBSOLlx4D+TunwJBANkPI5S9iylsbLs6NkaMHV6k5ioHBBmgCak95JGX + GMot/L2x0IYyMLAz6oLWh2hm7zwtb0CgOrPo1ke44hFYnfc= + -----END RSA PRIVATE KEY----- + + To extract the public-key component from the private key, use openssl + like this: + + $ openssl rsa -in rsa.private -out rsa.public -pubout -outform PEM + + This results in the file rsa.public containing the key information + similar to this: + + -----BEGIN PUBLIC KEY----- + MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDwIRP/UC3SBsEmGqZ9ZJW3/DkM + oGeLnQg1fWn7/zYtIxN2SnFCjxOCKG9v3b4jYfcTNh5ijSsq631uBItLa7od+v/R + tdC2UzJ1lWT947qR+Rcac2gbto/NMqJ0fzfVjH4OuKhitdY9tf6mcwGjaNBcWToI + MmPSPDdQPNUYckcQ2QIDAQAB + -----END PUBLIC KEY----- + + This public-key data (without the BEGIN and END tags) is placed in + the DNS: + + $ORIGIN _domainkey.example.org. + brisbane IN TXT ("v=DKIM1; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQ" + "KBgQDwIRP/UC3SBsEmGqZ9ZJW3/DkMoGeLnQg1fWn7/zYt" + "IxN2SnFCjxOCKG9v3b4jYfcTNh5ijSsq631uBItLa7od+v" + "/RtdC2UzJ1lWT947qR+Rcac2gbto/NMqJ0fzfVjH4OuKhi" + "tdY9tf6mcwGjaNBcWToIMmPSPDdQPNUYckcQ2QIDAQAB") + +C.1. Compatibility with DomainKeys Key Records + + DKIM key records were designed to be backward compatible in many + cases with key records used by DomainKeys [RFC4870] (sometimes + referred to as "selector records" in the DomainKeys context). One + area of incompatibility warrants particular attention. The "g=" tag + value may be used in DomainKeys and [RFC4871] key records to provide + + + +Crocker, et al. Standards Track [Page 72] + +RFC 6376 DKIM Signatures September 2011 + + + finer granularity of the validity of the key record to a specific + local-part. A null "g=" value in DomainKeys is valid for all + addresses in the domain. This differs from the usage in the original + DKIM specification ([RFC4871]), where a null "g=" value is not valid + for any address. In particular, see the example public-key record in + Section 3.2.3 of [RFC4870]. + +C.2. RFC 4871 Compatibility + + Although the "g=" tag has been deprecated in this version of the DKIM + specification (and thus MUST now be ignored), Signers are advised not + to include the "g=" tag in key records because some [RFC4871]- + compliant Verifiers will be in use for a considerable period to come. + +Appendix D. MUA Considerations (INFORMATIVE) + + When a DKIM signature is verified, the processing system sometimes + makes the result available to the recipient user's MUA. How to + present this information to users in a way that helps them is a + matter of continuing human factors usability research. The tendency + is to have the MUA highlight the SDID, in an attempt to show the user + the identity that is claiming responsibility for the message. An MUA + might do this with visual cues such as graphics, might include the + address in an alternate view, or might even rewrite the original From + address using the verified information. Some MUAs might indicate + which header fields were protected by the validated DKIM signature. + This could be done with a positive indication on the signed header + fields, with a negative indication on the unsigned header fields, by + visually hiding the unsigned header fields, or some combination of + these. If an MUA uses visual indications for signed header fields, + the MUA probably needs to be careful not to display unsigned header + fields in a way that might be construed by the end user as having + been signed. If the message has an "l=" tag whose value does not + extend to the end of the message, the MUA might also hide or mark the + portion of the message body that was not signed. + + The aforementioned information is not intended to be exhaustive. The + MUA can choose to highlight, accentuate, hide, or otherwise display + any other information that may, in the opinion of the MUA author, be + deemed important to the end user. + +Appendix E. Changes since RFC 4871 + + o Abstract and introduction refined based on accumulated experience. + + o Various references updated. + + + + + +Crocker, et al. Standards Track [Page 73] + +RFC 6376 DKIM Signatures September 2011 + + + o Several errata resolved (see http://www.rfc-editor.org/): + + * 1376 applied + + * 1377 applied + + * 1378 applied + + * 1379 applied + + * 1380 applied + + * 1381 applied + + * 1382 applied + + * 1383 discarded (no longer applies) + + * 1384 applied + + * 1386 applied + + * 1461 applied + + * 1487 applied + + * 1532 applied + + * 1596 applied + + o Introductory section enumerating relevant architectural documents + added. + + o Introductory section briefly discussing the matter of data + integrity added. + + o Allowed tolerance of some clock drift. + + o Dropped "g=" tag from key records. The implementation report + indicates that it is not in use. + + o Removed errant note about wildcards in the DNS. + + o Removed SMTP-specific advice in most places. + + o Reduced (non-normative) recommended signature content list, and + reworked the text in that section. + + + + +Crocker, et al. Standards Track [Page 74] + +RFC 6376 DKIM Signatures September 2011 + + + o Clarified signature generation algorithm by rewriting its pseudo- + code. + + o Numerous terminology subsections added, imported from [RFC5672]. + Also, began using these terms throughout the document (e.g., SDID, + AUID). + + o Sections added that specify input and output requirements. Input + requirements address a security concern raised by the working + group (see also new sections in Security Considerations). Output + requirements are imported from [RFC5672]. + + o Appendix subsection added discussing compatibility with DomainKeys + ([RFC4870]) records. + + o Referred to [RFC5451] as an example method of communicating the + results of DKIM verification. + + o Removed advice about possible uses of the "l=" signature tag. + + o IANA registry updated. + + o Added two new Security Considerations sections talking about + malformed message attacks. + + o Various copy editing. + +Appendix F. Acknowledgments + + The previous IETF version of DKIM [RFC4871] was edited by Eric + Allman, Jon Callas, Mark Delany, Miles Libbey, Jim Fenton, and + Michael Thomas. + + That specification was the result of an extended collaborative + effort, including participation by Russ Allbery, Edwin Aoki, Claus + Assmann, Steve Atkins, Rob Austein, Fred Baker, Mark Baugher, Steve + Bellovin, Nathaniel Borenstein, Dave Crocker, Michael Cudahy, Dennis + Dayman, Jutta Degener, Frank Ellermann, Patrik Faeltstroem, Mark + Fanto, Stephen Farrell, Duncan Findlay, Elliot Gillum, Olafur + Gudmundsson, Phillip Hallam-Baker, Tony Hansen, Sam Hartman, Arvel + Hathcock, Amir Herzberg, Paul Hoffman, Russ Housley, Craig Hughes, + Cullen Jennings, Don Johnsen, Harry Katz, Murray S. Kucherawy, Barry + Leiba, John Levine, Charles Lindsey, Simon Longsdale, David Margrave, + Justin Mason, David Mayne, Thierry Moreau, Steve Murphy, Russell + Nelson, Dave Oran, Doug Otis, Shamim Pirzada, Juan Altmayer Pizzorno, + Sanjay Pol, Blake Ramsdell, Christian Renaud, Scott Renfro, Neil + + + + + +Crocker, et al. Standards Track [Page 75] + +RFC 6376 DKIM Signatures September 2011 + + + Rerup, Eric Rescorla, Dave Rossetti, Hector Santos, Jim Schaad, the + Spamhaus.org team, Malte S. Stretz, Robert Sanders, Rand Wacker, Sam + Weiler, and Dan Wing. + + The earlier DomainKeys was a primary source from which DKIM was + derived. Further information about DomainKeys is at [RFC4870]. + + This revision received contributions from Steve Atkins, Mark Delany, + J.D. Falk, Jim Fenton, Michael Hammer, Barry Leiba, John Levine, + Charles Lindsey, Jeff Macdonald, Franck Martin, Brett McDowell, Doug + Otis, Bill Oxley, Hector Santos, Rolf Sonneveld, Michael Thomas, and + Alessandro Vesely. + +Authors' Addresses + + Dave Crocker (editor) + Brandenburg InternetWorking + 675 Spruce Dr. + Sunnyvale, CA 94086 + USA + + Phone: +1.408.246.8253 + EMail: dcrocker@bbiw.net + URI: http://bbiw.net + + + Tony Hansen (editor) + AT&T Laboratories + 200 Laurel Ave. South + Middletown, NJ 07748 + USA + + EMail: tony+dkimsig@maillennium.att.com + + + Murray S. Kucherawy (editor) + Cloudmark + 128 King St., 2nd Floor + San Francisco, CA 94107 + USA + + EMail: msk@cloudmark.com + + + + + + + + + +Crocker, et al. Standards Track [Page 76] + diff --git a/RFCs/rfc6409.txt b/RFCs/rfc6409.txt new file mode 100644 index 0000000..bb56a70 --- /dev/null +++ b/RFCs/rfc6409.txt @@ -0,0 +1,1123 @@ + + + + + + +Internet Engineering Task Force (IETF) R. Gellens +Request for Comments: 6409 QUALCOMM Incorporated +STD: 72 J. Klensin +Obsoletes: 4409 November 2011 +Category: Standards Track +ISSN: 2070-1721 + + + Message Submission for Mail + +Abstract + + This memo splits message submission from message relay, allowing each + service to operate according to its own rules (for security, policy, + etc.), and specifies what actions are to be taken by a submission + server. + + Message relay is unaffected, and continues to use SMTP over port 25. + + When conforming to this document, message submission uses the + protocol specified here, normally over port 587. + + This separation of function offers a number of benefits, including + the ability to apply specific security or policy requirements. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc6409. + + + + + + + + + + + + + +Gellens & Klensin Standards Track [Page 1] + +RFC 6409 Message Submission for Mail November 2011 + + +Copyright Notice + + Copyright (c) 2011 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Gellens & Klensin Standards Track [Page 2] + +RFC 6409 Message Submission for Mail November 2011 + + +Table of Contents + + 1. Introduction ....................................................4 + 2. Document Information ............................................5 + 2.1. Definitions of Terms Used in This Memo .....................5 + 2.2. Conventions Used in This Document ..........................6 + 3. Message Submission ..............................................6 + 3.1. Submission Identification ..................................6 + 3.2. Message Rejection and Bouncing .............................6 + 3.3. Authorized Submission ......................................7 + 4. Mandatory Actions ...............................................8 + 4.1. General Submission Rejection Code ..........................8 + 4.2. Ensure All Domains Are Fully Qualified .....................8 + 4.3. Require Authentication .....................................8 + 5. Recommended Actions .............................................9 + 5.1. Enforce Address Syntax .....................................9 + 5.2. Log Errors .................................................9 + 5.3. Apply Shorter Timeouts .....................................9 + 6. Optional Actions ...............................................10 + 6.1. Enforce Submission Rights .................................10 + 6.2. Enforce Permissions .......................................10 + 6.3. Check Message Data ........................................10 + 6.4. Support for the Postmaster Address ........................10 + 6.5. Adjust Character Encodings ................................11 + 7. Interaction with SMTP Extensions ...............................12 + 8. Message Modifications ..........................................13 + 8.1. Add 'Sender' ..............................................14 + 8.2. Add 'Date' ................................................14 + 8.3. Add 'Message-ID' ..........................................14 + 8.4. Transfer Encode ...........................................14 + 8.5. Sign the Message ..........................................14 + 8.6. Encrypt the Message .......................................14 + 8.7. Resolve Aliases ...........................................15 + 8.8. Header Rewriting ..........................................15 + 9. Security Considerations ........................................15 + 10. IANA Considerations ...........................................16 + 11. Acknowledgments ...............................................16 + 12. References ....................................................17 + 12.1. Normative References .....................................17 + 12.2. Informative References ...................................17 + Appendix A. Major Changes from RFC 4409 ...........................20 + + + + + + + + + + +Gellens & Klensin Standards Track [Page 3] + +RFC 6409 Message Submission for Mail November 2011 + + +1. Introduction + + SMTP [SMTP-MTA] was defined as a message *transfer* protocol, that + is, a means to route (if needed) and deliver finished (complete) + messages. + + Message Transfer Agents (MTAs) are not supposed to alter the message + text, except to add 'Received', 'Return-Path', and other header + fields as required by [SMTP-MTA]. However, SMTP is now also widely + used as a message *submission* protocol, that is, a means for Message + User Agents (MUAs) to introduce new messages into the MTA routing + network. The process that accepts message submissions from MUAs is + termed a "Message Submission Agent" (MSA). + + In order to permit unconstrained communications, SMTP is not often + authenticated during message relay. + + Authentication and authorization of initial submissions have become + increasingly important, driven by changes in security requirements + and rising expectations that submission servers take responsibility + for the message traffic they originate. + + For example, due to the prevalence of machines that have worms, + viruses, or other malicious software that generate large amounts of + spam, many sites now prohibit outbound traffic on the standard SMTP + port (port 25), funneling all mail submissions through submission + servers. + + In addition to authentication and authorization issues, messages + being submitted are, in some cases, finished (complete) messages and, + in other cases, are unfinished (incomplete) in one or more aspects. + Unfinished messages may need to be completed to ensure they conform + to the Message Format specification [MESSAGE-FORMAT] and related + requirements. For example, the message may lack a proper 'Date' + header field, and domains might not be fully qualified. In some + cases, the MUA may be unable to generate finished messages (e.g., it + might not know its time zone). Even when submitted messages are + complete, local site policy may dictate that the message text be + examined or modified in some way, e.g., to conceal local name or + address spaces. Such completions or modifications have been shown to + cause harm when performed by downstream MTAs -- that is, MTAs after + the first-hop submission MTA -- and are, in general, considered to be + outside the province of standardized MTA functionality. + + + + + + + + +Gellens & Klensin Standards Track [Page 4] + +RFC 6409 Message Submission for Mail November 2011 + + + Separating messages into submissions and transfers allows developers + and network administrators to do the following more easily: + + o Implement security policies and guard against unauthorized mail + relaying or injection of unsolicited bulk mail. + + o Implement authenticated submission, including off-site submission + by authorized users such as travelers. + + o Separate the relevant software code differences, thereby making + each code base more straightforward and allowing for different + programs for relay and submission. + + o Detect configuration problems with a site's mail clients. + + o Provide a basis for adding enhanced submission services. + + This memo describes a low-cost, deterministic means for messages to + be identified as submissions, and it specifies what actions are to be + taken by a submission server. + +2. Document Information + +2.1. Definitions of Terms Used in This Memo + + Many of the concepts and terms used in this document are defined in + [SMTP-MTA]; familiarity with those documents is assumed here. + + Fully Qualified + + Containing or consisting of a domain that can be globally resolved + using the Domain Name Service, that is, not a local alias or partial + specification. + + Message Submission Agent (MSA) + + A process that conforms to this specification. An MSA acts as a + submission server to accept messages from MUAs, and it either + delivers them or acts as an SMTP client to relay them to an MTA. + + Message Transfer Agent (MTA) + + A process that conforms to [SMTP-MTA]. An MTA acts as an SMTP server + to accept messages from an MSA or another MTA, and it either delivers + them or acts as an SMTP client to relay them to another MTA. + + + + + + +Gellens & Klensin Standards Track [Page 5] + +RFC 6409 Message Submission for Mail November 2011 + + + Message User Agent (MUA) + + A process that acts (often on behalf of a user and with a user + interface) to compose and submit new messages, and to process + delivered messages. + + For delivered messages, the receiving MUA may obtain and process the + message according to local conventions or, in what is commonly + referred to as a split-MUA model, Post Office Protocol [POP3] or IMAP + [IMAP4] is used to access delivered messages, whereas the protocol + defined here (or SMTP) is used to submit messages. + +2.2. Conventions Used in This Document + + Examples use the 'example.net' domain. + + The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" + in this document are to be interpreted as defined in [KEYWORDS]. + +3. Message Submission + +3.1. Submission Identification + + Port 587 is reserved for email message submission as specified in + this document. Messages received on this port are defined to be + submissions. The protocol used is ESMTP [SMTP-MTA], with additional + restrictions or allowances as specified here. + + Although most email clients and servers can be configured to use port + 587 instead of 25, there are cases where this is not possible or + convenient. A site MAY choose to use port 25 for message submission + by designating some hosts to be MSAs and others to be MTAs. + +3.2. Message Rejection and Bouncing + + MTAs and MSAs MAY implement message rejection rules that rely, in + part, on whether the message is a submission or a relay. + + For example, some sites might configure their MTAs to reject all RCPT + commands for messages that do not reference local users, and they + might configure their MSA to reject all message submissions that do + not come from authorized users, with authorization based on either + the authenticated identity or the submitting endpoint being within a + protected IP environment. + + NOTE: It is better to reject a message than to risk sending one that + is damaged. This is especially true for problems that are + correctable by the MUA, for example, an invalid 'From' field. + + + +Gellens & Klensin Standards Track [Page 6] + +RFC 6409 Message Submission for Mail November 2011 + + + If an MSA is not able to determine a return path to the submitting + user, from a valid MAIL FROM, a valid source IP address, or based on + authenticated identity, then the MSA SHOULD immediately reject the + message. A message can be immediately rejected by returning a 550 + code to the MAIL command. + + Note that a null return path, that is, MAIL FROM:<>, is permitted and + MUST NOT, in itself, be cause for rejecting a message. (MUAs need to + generate null return-path messages for a variety of reasons, + including disposition notifications.) + + Except in the case where the MSA is unable to determine a valid + return path for the message being submitted, text in this + specification that instructs an MSA to issue a rejection code MAY be + complied with by accepting the message and subsequently generating a + bounce message. (That is, if the MSA is going to reject a message + for any reason except being unable to determine a return path, it can + optionally do an immediate rejection or accept the message and then + mail a bounce.) + + NOTE: In the normal case of message submission, immediately rejecting + the message is preferred, as it gives the user and MUA direct + feedback. To properly handle delayed bounces, the client MUA needs + to maintain a queue of messages it has submitted and match bounces to + them. Note that many contemporary MUAs do not have this capability. + +3.3. Authorized Submission + + Numerous methods have been used to ensure that only authorized users + are able to submit messages. These methods include authenticated + SMTP, IP address restrictions, secure IP and other tunnels, and prior + POP authentication. + + Authenticated SMTP [SMTP-AUTH] has seen widespread deployment. It + allows the MSA to determine an authorization identity for the message + submission, one that is not tied to other protocols. + + IP address restrictions are very widely implemented, but they do not + allow for travelers and similar situations, and they can be easily + spoofed unless all transport paths between the MUA and MSA are + trustworthy. + + Secure IP [IPSEC], and other encrypted and authenticated tunneling + techniques, can also be used and provide additional benefits of + protection against eavesdropping and traffic analysis. + + Requiring a POP [POP3] authentication (from the same IP address) + within some amount of time (e.g., 20 minutes) prior to the start of a + + + +Gellens & Klensin Standards Track [Page 7] + +RFC 6409 Message Submission for Mail November 2011 + + + message submission session has also been used, but this does impose + restrictions on clients as well as servers, which may cause + difficulties. Specifically, the client must do a POP authentication + before an SMTP submission session, and not all clients are capable + and configured for this. Also, the MSA must coordinate with the POP + server, which may be difficult. There is also a window during which + an unauthorized user can submit messages and appear to be a + previously authorized user. Since it is dependent on the MUA's IP + addresses, this technique is substantially as subject to IP address + spoofing as validation based on known IP addresses alone (see above). + +4. Mandatory Actions + + An MSA MUST do all of the following: + +4.1. General Submission Rejection Code + + Unless covered by a more precise response code, response code 554 is + to be used to reject a MAIL, RCPT, or DATA command that contains + something improper. + +4.2. Ensure All Domains Are Fully Qualified + + The MSA MUST ensure that all domains in the SMTP envelope are fully + qualified. + + If the MSA examines or alters the message text in any way, except to + add trace header fields [SMTP-MTA], it MUST ensure that all domains + in address header fields are fully qualified. + + Reply code 554 is to be used to reject a MAIL, RCPT, or DATA command + that contains improper domain references. + + A frequent local convention is to accept single-level domains (e.g., + 'sales') and then to expand the reference by adding the remaining + portion of the domain name (e.g., to 'sales.example.net'). Local + conventions that permit single-level domains SHOULD reject, rather + than expand, incomplete multi-level domains (e.g., 'squeaky.sales'), + since such expansion is particularly risky. + +4.3. Require Authentication + + The MSA MUST, by default, issue an error response to the MAIL command + if the session has not been authenticated using [SMTP-AUTH], unless + it has already independently established authentication or + authorization (such as being within a protected subnetwork). + + Section 3.3 discusses authentication mechanisms. + + + +Gellens & Klensin Standards Track [Page 8] + +RFC 6409 Message Submission for Mail November 2011 + + + Reply code 530 [SMTP-AUTH] is used for this purpose. + +5. Recommended Actions + + The MSA SHOULD do all of the following. + +5.1. Enforce Address Syntax + + An MSA SHOULD reject messages with illegal syntax in a sender or + recipient SMTP envelope address. + + If the MSA examines or alters the message text in any way, except to + add trace header fields, it SHOULD reject messages with illegal + address syntax in address header fields. + + Reply code 501 is to be used to reject a MAIL or RCPT command that + contains a detectably improper address. + + When addresses are resolved after submission of the message body, + reply code 554 (with a suitable enhanced status code from + [SMTP-CODES]) is used after end-of-data, if the message contains + invalid addresses in the header. + +5.2. Log Errors + + The MSA SHOULD log message errors, especially apparent + misconfigurations of client software. + + It can be very helpful to notify the administrator when problems are + detected with local mail clients. This is another advantage of + distinguishing submission from relay: system administrators might be + interested in local configuration problems, but not in client + problems at other sites. + + Note that it is important to impose limits on such logging to prevent + certain forms of denial-of-service (DoS) attacks. + +5.3. Apply Shorter Timeouts + + The timeouts specified in Section 4.5.3.2 of RFC 5321 [SMTP-MTA] are + designed to deal with the many types of situations that can be + encountered on the public Internet. The relationship among clients + and servers corresponding to this specification is typically much + closer and more predictable. Submission clients behave differently + from relay client in some areas, especially tolerance for timeouts. + In practice, message submission clients tend to have short timeouts + (perhaps 2-5 minutes for a reply to any command). Submission servers + SHOULD respond to any command (even DATA) in fewer than 2 minutes. + + + +Gellens & Klensin Standards Track [Page 9] + +RFC 6409 Message Submission for Mail November 2011 + + + When the submission server has a close administrative and/or network + relationship with the submission client(s) -- e.g., with a webmail + interface calling on a tightly bound submission server -- mutual + agreement on much shorter timeouts MAY be appropriate. + +6. Optional Actions + + The MSA MAY do any of the following. + +6.1. Enforce Submission Rights + + The MSA MAY issue an error response to a MAIL command if the address + in MAIL FROM appears to have insufficient submission rights or is not + authorized with the authentication used (if the session has been + authenticated). + + Reply code 550 with an appropriate enhanced status code per + [SMTP-CODES], such as 5.7.1, is used for this purpose. + +6.2. Enforce Permissions + + The MSA MAY issue an error response to a RCPT command if inconsistent + with the permissions given to the user (if the session has been + authenticated). + + Reply code 550 with an appropriate enhanced status code per + [SMTP-CODES], such as 5.7.1, is used for this purpose. + +6.3. Check Message Data + + The MSA MAY issue an error response to the DATA command or send a + failure result after end-of-data if the submitted message is + syntactically invalid, seems inconsistent with permissions given to + the user (if known), or violates site policy in some way. + + Reply code 554 is used for syntactic problems in the data. Reply + code 501 is used if the command itself is not syntactically valid. + Reply code 550 with an appropriate enhanced status code per + [SMTP-CODES] (such as 5.7.1) is used to reject based on the + submitting user. Reply code 550 with an appropriate enhanced status + code (such as 5.7.0) is used if the message violates site policy. + +6.4. Support for the Postmaster Address + + If appropriate under local conditions and to facilitate conformance + with the "postmaster" requirements of [SMTP-MTA], the MSA MAY permit + a reduced degree of authentication for mail addressed to the + "postmaster" (or one of its alternate spelling forms, see + + + +Gellens & Klensin Standards Track [Page 10] + +RFC 6409 Message Submission for Mail November 2011 + + + [SMTP-MTA]), in one or more domains, as compared to requirements + enforced for other addresses. Among other benefits, this provides an + address of last resort that can be used by authorized users to report + problems that otherwise prevent them from submitting mail. + +6.5. Adjust Character Encodings + + Subject to limits imposed by other protocols and specifications, the + MSA MAY convert among character sets or string encodings to improve + message usefulness, likelihood of delivery, or conformance with other + specifications or recommendations. Such conversions MAY include, + when necessary, replacement of addresses whose encoding does not + conform to RFC 5321 with ones that do, using information available + out of band. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Gellens & Klensin Standards Track [Page 11] + +RFC 6409 Message Submission for Mail November 2011 + + +7. Interaction with SMTP Extensions + + The following table lists Standards Track and Experimental SMTP + extensions whose documents do not explicitly specify their + applicability to this protocol. Listed are the EHLO keyword, name, + an indication as to the use of the extension on the submit port, and + a reference. + ++--------------------+----------------------+--------+-----------------+ +| Keyword | Name |Sub- | Reference | +| | |mission | | ++--------------------+----------------------+--------+-----------------+ +|PIPELINING |Pipelining |SHOULD |[PIPELINING] | +|ENHANCEDSTATUSCODES |Enhanced Status Codes |SHOULD |[CODES-EXTENSION]| +|ETRN |Extended Turn |MUST NOT|[ETRN] | +| ... |Extended Codes |SHOULD |[SMTP-CODES] | +|DSN |Delivery Status |SHOULD |[DSN] | +| | Notification | | | +|SIZE |Message size |MAY |[SIZE] | +| ... |521 reply code |MUST NOT|[REPLY-521] | +|CHECKPOINT |Checkpoint/Restart |MAY |[CHECKPOINT] | +|BINARYMIME |Binary MIME |MAY |[CHUNKING] | +|CHUNKING |Chunking |MAY |[CHUNKING] | +|8BITMIME |Use 8-bit data |SHOULD |[RFC6152] | +|AUTH |Authentication |MUST |[SMTP-AUTH] | +|STARTTLS |Start TLS |MAY |[START-TLS] | +|NO-SOLICITING |Notification of |MAY |[RFC3865] | +| | no soliciting | | | +|MTRK |Message Tracking |MAY |[MSG-TRACK] | +|ATRN |On-Demand Relay |MUST NOT|[RFC2645] | +|DELIVERBY |Deliver By |MAY |[RFC2852] | +|CONPERM |Content Conversion |MAY |[RFC4141] | +| | Permission | | | +|CONNEG |Content Conversion |MAY |[RFC4141] | +| | Negotiation | | | ++--------------------+----------------------+--------+-----------------+ + Table 1 + + Future SMTP extensions SHOULD explicitly specify if they are valid on + the Submission port. + + Some SMTP extensions are especially useful for message submission: + + Extended Status Codes [SMTP-CODES] SHOULD be supported and used + according to [CODES-EXTENSION]. This permits the MSA to notify the + client of specific configuration or other problems in more detail + than the response codes listed in this memo. Because some rejections + + + + +Gellens & Klensin Standards Track [Page 12] + +RFC 6409 Message Submission for Mail November 2011 + + + are related to a site's security policy, care should be used not to + expose more detail to unauthenticated senders than is needed. + + [PIPELINING] SHOULD be supported by the MSA. + + [SMTP-AUTH] allows the MSA to validate the authority and determine + the identity of the submitting user and MUST be supported by the MSA. + + [START-TLS] is the most widely used mechanism, at the time this + document was written, that allows the MUA and MSA to protect message + submission integrity and privacy. + + Any references to the DATA command in this memo also refer to any + substitutes for DATA, such as the BDAT command used with [CHUNKING]. + +8. Message Modifications + + Sites MAY modify submissions to ensure compliance with standards and + site policy. This section describes a number of such modifications + that are often considered useful. + + NOTE: As a matter of guidance for local decisions to implement + message modification, a paramount rule is to limit such actions to + remedies for specific problems that have clear solutions. This is + especially true with address elements. For example, indiscriminately + appending a domain to an address or element that lacks one typically + results in more broken addresses. An unqualified address must be + verified to be a valid local part in the domain before the domain can + be safely added. + + Any message forwarded or delivered by the MSA MUST conform to the + requirements of [SMTP-MTA] and [MESSAGE-FORMAT] or the requirements + permitted by extensions that are supported by the MSA and accepted by + the next-hop server. + + Message modification can affect the validity of an existing message + signature, such as by DomainKeys Identified Mail (DKIM) [DKIM], + Pretty Good Privacy (PGP) [RFC4880], or Secure MIME (S/MIME) + [RFC5751], and can render the signature invalid. This, in turn, can + affect message handling by later receivers, such as filtering engines + that consider the presence or absence of a valid signature. + + + + + + + + + + +Gellens & Klensin Standards Track [Page 13] + +RFC 6409 Message Submission for Mail November 2011 + + +8.1. Add 'Sender' + + The MSA MAY add or replace the 'Sender' field, if the identity of the + sender is known and this is not given in the 'From' field. + + The MSA MUST ensure that any address it places in a 'Sender' field + is, in fact, a valid mail address. + +8.2. Add 'Date' + + The MSA MAY add a 'Date' field to the submitted message, if it lacks + it, or correct the 'Date' field if it does not conform to + [MESSAGE-FORMAT] syntax. + +8.3. Add 'Message-ID' + + The MSA SHOULD add or replace the 'Message-ID' field, if it lacks it, + or it is not valid syntax (as defined by [MESSAGE-FORMAT]). Note + that a number of clients still do not generate 'Message-ID' fields. + +8.4. Transfer Encode + + The MSA MAY apply transfer encoding to the message according to MIME + conventions, if needed and not harmful to the MIME type. + +8.5. Sign the Message + + The MSA MAY (digitally) sign or otherwise add authentication + information to the message. + +8.6. Encrypt the Message + + The MSA MAY encrypt the message for transport to reflect + organizational policies. + + NOTE: To be useful, the addition of a signature and/or encryption by + the MSA generally implies that the connection between the MUA and MSA + must, itself, be secured in some other way, for example, by operating + inside of a secure environment, by securing the submission connection + at the transport layer, or by using an [SMTP-AUTH] mechanism that + provides for session integrity. + + + + + + + + + + +Gellens & Klensin Standards Track [Page 14] + +RFC 6409 Message Submission for Mail November 2011 + + +8.7. Resolve Aliases + + The MSA MAY resolve and rewrite aliases (e.g., Canonical Name (CNAME) + records) for domain names, in the SMTP envelope and/or in address + fields of the header, subject to local policy. + + NOTE: SMTP [SMTP-MTA] prohibits the use of domain name aliases in + addresses and the session-opening announcement. As with other SMTP + requirements, RFC 5321 effectively prohibits an MSA from forwarding + such messages into the public Internet. Nonetheless, unconditionally + resolving aliases could be harmful. For example, if www.example.net + and ftp.example.net are both aliases for mail.example.net, rewriting + them could lose useful information. + +8.8. Header Rewriting + + The MSA MAY rewrite local parts and/or domains in the SMTP envelope + and, optionally, in address fields of the header, according to local + policy. For example, a site may prefer to rewrite 'JRU' as + 'J.Random.User' in order to hide login names and/or to rewrite + 'squeaky.sales.example.net' as 'zyx.example.net' to hide machine + names and make it easier to move users. + + However, only addresses, local-parts, or domains that match specific + local MSA configuration settings should be altered. It would be very + dangerous for the MSA to apply data-independent rewriting rules, such + as always deleting the first element of a domain name. So, for + example, a rule that strips the leftmost element of the domain, if + the complete domain matches '*.foo.example.net', would be acceptable. + + The MSA MUST NOT rewrite a forward-pointing (destination) address in + a way that violates the constraints of [SMTP-MTA] on modifications of + local-parts. Changes to addressing and encoding, carried out in + conjunction with the action of Section 6.5, do not violate this + principle if the MSA has sufficient information available to + successfully and accurately apply the substitution. + +9. Security Considerations + + Separation of submission and relay of messages allows a site to + implement different policies for the two types of services, including + requiring the use of additional security mechanisms for one or both. + It can do this in a way that is simpler, both technically and + administratively. This increases the likelihood that policies will + be applied correctly. + + + + + + +Gellens & Klensin Standards Track [Page 15] + +RFC 6409 Message Submission for Mail November 2011 + + + Separation also can aid in tracking and preventing unsolicited bulk + email. + + For example, a site could configure its mail servers such that the + MSA requires authentication before accepting a message, and the MTA + rejects all RCPT commands for non-local users. This can be an + important element in a site's total email security policy. + + If a site fails to require any form of authorization for message + submissions (see Section 3.3 for discussion), it is allowing open use + of its resources and name; unsolicited bulk email can be injected + using its facilities. + + Section 3 includes further discussion of issues with some + authentication methods. + + Section 5.2 includes a cautionary note that unlimited logging can + enable certain forms of denial-of-service attacks. + +10. IANA Considerations + + The entries in Table 1 have been corrected (reference for NO- + SOLICITING) and extended (ATRN, DELIVERBY, CONPERM, and CONNEG). The + "SMTP Service Extensions" registry has been updated to reflect the + changed and new entries. Entries in the registry that do not appear + in the table above are correct and should not be altered. + + The entry in the "SMTP Service Extensions" registry for RFC 4409 has + been updated to reference this document. The original reference for + Submit (RFC 2476), which should have been corrected earlier, has also + been updated to point to this document. + + The entry in the "Service Name and Transport Protocol Port Number + Registry" for port 587 has been updated to point to this document. + +11. Acknowledgments + + The preparation and development of the current version of this + specification was stimulated by discussions in the IETF YAM and EAI + Working Groups. Dave Crocker, Subramanian Moonesamy, Barry Leiba, + John Levine, and others provided text that appeared in this document + or versions leading up to it. + + Nathaniel Borenstein and Barry Leiba were instrumental in the + development of RFC 4409, the update to RFC 2476. + + The original memo (RFC 2476) was developed, in part, based on + comments and discussions that took place on and off the IETF-Submit + + + +Gellens & Klensin Standards Track [Page 16] + +RFC 6409 Message Submission for Mail November 2011 + + + mailing list. The help of those who took the time to review that + document and make suggestions is appreciated, especially that of Dave + Crocker, Ned Freed, Keith Moore, John Myers, and Chris Newman. + + Special thanks to Harald Alvestrand, who got this effort started. + +12. References + +12.1. Normative References + + [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [SMTP-AUTH] Siemborski, R. and A. Melnikov, "SMTP Service Extension + for Authentication", RFC 4954, July 2007. + + [SMTP-MTA] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, + October 2008. + +12.2. Informative References + + [CHECKPOINT] Crocker, D. and N. Freed, "SMTP Service Extension for + Checkpoint/Restart", RFC 1845, September 1995. + + [CHUNKING] Vaudreuil, G., "SMTP Service Extensions for Transmission + of Large and Binary MIME Messages", RFC 3030, + December 2000. + + [CODES-EXTENSION] + Freed, N., "SMTP Service Extension for Returning + Enhanced Error Codes", RFC 2034, October 1996. + + [DKIM] Crocker, D., Hansen, T., and M. Kucherawy, "DomainKeys + Identified Mail (DKIM) Signatures", RFC 6376, + September 2011. + + [DSN] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service + Extension for Delivery Status Notifications (DSNs)", + RFC 3461, January 2003. + + [ETRN] De Winter, J., "SMTP Service Extension for Remote + Message Queue Starting", RFC 1985, August 1996. + + [IMAP4] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION + 4rev1", RFC 3501, March 2003. + + [IPSEC] Kent, S. and K. Seo, "Security Architecture for the + Internet Protocol", RFC 4301, December 2005. + + + +Gellens & Klensin Standards Track [Page 17] + +RFC 6409 Message Submission for Mail November 2011 + + + [MESSAGE-FORMAT] + Resnick, P., Ed., "Internet Message Format", RFC 5322, + October 2008. + + [MSG-TRACK] Allman, E. and T. Hansen, "SMTP Service Extension for + Message Tracking", RFC 3885, September 2004. + + [PIPELINING] Freed, N., "SMTP Service Extension for Command + Pipelining", STD 60, RFC 2920, September 2000. + + [POP3] Myers, J. and M. Rose, "Post Office Protocol - Version + 3", STD 53, RFC 1939, May 1996. + + [REPLY-521] Durand, A. and F. Dupont, "SMTP 521 Reply Code", + RFC 1846, September 1995. + + [RFC2645] Gellens, R., "ON-DEMAND MAIL RELAY (ODMR) SMTP with + Dynamic IP Addresses", RFC 2645, August 1999. + + [RFC2852] Newman, D., "Deliver By SMTP Service Extension", + RFC 2852, June 2000. + + [RFC3865] Malamud, C., "A No Soliciting Simple Mail Transfer + Protocol (SMTP) Service Extension", RFC 3865, + September 2004. + + [RFC4141] Toyoda, K. and D. Crocker, "SMTP and MIME Extensions for + Content Conversion", RFC 4141, November 2005. + + [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and + R. Thayer, "OpenPGP Message Format", RFC 4880, + November 2007. + + [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose + Internet Mail Extensions (S/MIME) Version 3.2 Message + Specification", RFC 5751, January 2010. + + [RFC6152] Klensin, J., Freed, N., Rose, M., and D. Crocker, "SMTP + Service Extension for 8-bit MIME Transport", STD 71, + RFC 6152, March 2011. + + [SIZE] Klensin, J., Freed, N., and K. Moore, "SMTP Service + Extension for Message Size Declaration", STD 10, + RFC 1870, November 1995. + + + + + + + +Gellens & Klensin Standards Track [Page 18] + +RFC 6409 Message Submission for Mail November 2011 + + + [SMTP-CODES] Vaudreuil, G., "Enhanced Mail System Status Codes", + RFC 3463, January 2003. + + [START-TLS] Hoffman, P., "SMTP Service Extension for Secure SMTP + over Transport Layer Security", RFC 3207, February 2002. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Gellens & Klensin Standards Track [Page 19] + +RFC 6409 Message Submission for Mail November 2011 + + +Appendix A. Major Changes from RFC 4409 + + The protocol specified by this document is not substantively + different from that of RFC 4409. However, the present specification + contains several clarifications and updates to reflect changes and + revisions to other documents subsequent to the publication of RFC + 4409. The following specific changes may be of interest to some + readers. + + o Updated several references to reflect more recent versions of the + various specifications. As part of this, reclassified RFC 4954 to + a normative reference (SMTP AUTH is a MUST for RFC 4409 and this + specification). + + o Updated the text in Section 7 to reflect the existence and partial + population of the registry and the included table (Table 1) to + correct one entry and add others. See Section 10 for more + information. + + o Added new text (Section 5.3) to clarify that Submission Servers + should respond quickly. + + o Added text to make it explicit that character encoding changes are + permitted. + + o Added text to make it clear that modifications to signed messages + may cause problems and that they should be carefully considered. + +Authors' Addresses + + Randall Gellens + QUALCOMM Incorporated + 5775 Morehouse Drive + San Diego, CA 92121-2779 + USA + + EMail: rg+ietf@qualcomm.com + + + John C Klensin + 1770 Massachusetts Ave, #322 + Cambridge, MA 02140 + USA + + Phone: +1 617 491 5735 + EMail: john-ietf@jck.com + + + + + +Gellens & Klensin Standards Track [Page 20] + diff --git a/RFCs/rfc7457.txt b/RFCs/rfc7457.txt new file mode 100644 index 0000000..7fc7818 --- /dev/null +++ b/RFCs/rfc7457.txt @@ -0,0 +1,731 @@ + + + + + + +Internet Engineering Task Force (IETF) Y. Sheffer +Request for Comments: 7457 Porticor +Category: Informational R. Holz +ISSN: 2070-1721 Technische Universitaet Muenchen + P. Saint-Andre + &yet + February 2015 + + + Summarizing Known Attacks on Transport Layer Security (TLS) + and Datagram TLS (DTLS) + +Abstract + + Over the last few years, there have been several serious attacks on + Transport Layer Security (TLS), including attacks on its most + commonly used ciphers and modes of operation. This document + summarizes these attacks, with the goal of motivating generic and + protocol-specific recommendations on the usage of TLS and Datagram + TLS (DTLS). + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for informational purposes. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Not all documents + approved by the IESG are a candidate for any level of Internet + Standard; see Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc7457. + + + + + + + + + + + + + + + +Sheffer, et al. Informational [Page 1] + +RFC 7457 TLS Attacks February 2015 + + +Copyright Notice + + Copyright (c) 2015 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + +Table of Contents + 1. Introduction ....................................................3 + 2. Attacks on TLS ..................................................3 + 2.1. SSL Stripping ..............................................3 + 2.2. STARTTLS Command Injection Attack (CVE-2011-0411) ..........4 + 2.3. BEAST (CVE-2011-3389) ......................................4 + 2.4. Padding Oracle Attacks .....................................4 + 2.5. Attacks on RC4 .............................................5 + 2.6. Compression Attacks: CRIME, TIME, and BREACH ...............5 + 2.7. Certificate and RSA-Related Attacks ........................5 + 2.8. Theft of RSA Private Keys ..................................6 + 2.9. Diffie-Hellman Parameters ..................................6 + 2.10. Renegotiation (CVE-2009-3555) .............................6 + 2.11. Triple Handshake (CVE-2014-1295) ..........................6 + 2.12. Virtual Host Confusion ....................................7 + 2.13. Denial of Service .........................................7 + 2.14. Implementation Issues .....................................7 + 2.15. Usability .................................................8 + 3. Applicability to DTLS ...........................................8 + 4. Security Considerations .........................................8 + 5. Informative References ..........................................8 + Acknowledgements ..................................................13 + Authors' Addresses ................................................13 + + + + + + + + + + + + + +Sheffer, et al. Informational [Page 2] + +RFC 7457 TLS Attacks February 2015 + + +1. Introduction + + Over the last few years, there have been several major attacks on TLS + [RFC5246], including attacks on its most commonly used ciphers and + modes of operation. Details are given in Section 2, but a quick + summary is that both AES-CBC and RC4, which together make up for most + current usage, have been seriously attacked in the context of TLS. + + This situation was one of the motivations for the creation of the UTA + working group, which was tasked with the creation of generic and + protocol-specific recommendations for the use of TLS and DTLS + [RFC6347] (unless otherwise noted under Section 3, all of the + information provided in this document applies to DTLS). + + There is an old saying attributed, ironically enough, to the US + National Security Agency (NSA): "Attacks always get better; they + never get worse." Unfortunately, that saying is true, so any + description of security attacks can only be a snapshot in time. + Therefore this document reflects our knowledge as of this writing. + It seems likely that new attacks will be discovered in the future. + + For a more detailed discussion of the attacks listed here, the + interested reader is referred to [Attacks-iSec]. + +2. Attacks on TLS + + This section lists the attacks that motivated the current + recommendations in [SECURE-TLS]. This list is not intended to be an + extensive survey of the security of TLS. + + While there are widely deployed mitigations for some of the attacks + listed below, we believe that their root causes necessitate a more + systematic solution, which we have attempted to develop in + [SECURE-TLS]. + + When an identifier exists for an attack, we have included its Common + Vulnerabilities and Exposures (CVE) ID. CVE [CVE] is an extensive, + industry-wide database of software vulnerabilities. + +2.1. SSL Stripping + + Various attacks attempt to remove the use of Secure Socket Layer / + Transport Layer Security (SSL/TLS) altogether by modifying + unencrypted protocols that request the use of TLS, specifically + modifying HTTP traffic and HTML pages as they pass on the wire. + These attacks are known collectively as "SSL Stripping" (a form of + the more generic "downgrade attack") and were first introduced by + Moxie Marlinspike [SSL-Stripping]. In the context of Web traffic, + + + +Sheffer, et al. Informational [Page 3] + +RFC 7457 TLS Attacks February 2015 + + + these attacks are only effective if the client initially accesses a + Web server using HTTP. A commonly used mitigation is HTTP Strict + Transport Security (HSTS) [RFC6797]. + +2.2. STARTTLS Command Injection Attack (CVE-2011-0411) + + Similarly, there are attacks on the transition between unprotected + and TLS-protected traffic. A number of IETF application protocols + have used an application-level command, usually STARTTLS, to upgrade + a cleartext connection to use TLS. Multiple implementations of + STARTTLS had a flaw where an application-layer input buffer retained + commands that were pipelined with the STARTTLS command, such that + commands received prior to TLS negotiation are executed after TLS + negotiation. This problem is resolved by requiring the application- + level command input buffer to be empty before negotiating TLS. Note + that this flaw lives in the application layer code and does not + impact the TLS protocol directly. + + STARTTLS and similar mechanisms are vulnerable to downgrade attacks, + whereby the attacker simply removes the STARTTLS indication from the + (unprotected) request. This cannot be mitigated unless HSTS-like + solutions are added. + +2.3. BEAST (CVE-2011-3389) + + The BEAST attack [BEAST] uses issues with the TLS 1.0 implementation + of Cipher Block Chaining (CBC) (that is, the predictable + initialization vector) to decrypt parts of a packet, and specifically + to decrypt HTTP cookies when HTTP is run over TLS. + +2.4. Padding Oracle Attacks + + A consequence of the MAC-then-encrypt design in all current versions + of TLS is the existence of padding oracle attacks [Padding-Oracle]. + A recent incarnation of these attacks is the Lucky Thirteen attack + (CVE-2013-0169) [CBC-Attack], a timing side-channel attack that + allows the attacker to decrypt arbitrary ciphertext. + + The Lucky Thirteen attack can be mitigated by using authenticated + encryption like AES-GCM [RFC5288] or encrypt-then-MAC [RFC7366] + instead of the TLS default of MAC-then-encrypt. + + An even newer variant of the padding oracle attack, one that does not + use timing information, is the POODLE attack (CVE-2014-3566) [POODLE] + on SSL 3.0. This attack has no known mitigation. + + + + + + +Sheffer, et al. Informational [Page 4] + +RFC 7457 TLS Attacks February 2015 + + +2.5. Attacks on RC4 + + The RC4 algorithm [RC4] has been used with TLS (and previously, SSL) + for many years. RC4 has long been known to have a variety of + cryptographic weaknesses, e.g., [RC4-Attack-Pau], [RC4-Attack-Man], + and [RC4-Attack-FMS]. Recent cryptanalysis results [RC4-Attack-AlF] + exploit biases in the RC4 keystream to recover repeatedly encrypted + plaintexts. + + These recent results are on the verge of becoming practically + exploitable; currently they require 2^26 sessions or 13x2^30 + encryptions. As a result, RC4 can no longer be seen as providing a + sufficient level of security for TLS sessions. For further details, + the reader is referred to [CIPHER-SUITES] and the references it + cites. + +2.6. Compression Attacks: CRIME, TIME, and BREACH + + The CRIME attack [CRIME] (CVE-2012-4929) allows an active attacker to + decrypt ciphertext (specifically, cookies) when TLS is used with TLS- + level compression. + + The TIME attack [TIME] and the later BREACH attack [BREACH] (CVE- + 2013-3587, though the number has not been officially allocated) both + make similar use of HTTP-level compression to decrypt secret data + passed in the HTTP response. We note that compression of the HTTP + message body is much more prevalent than compression at the TLS + level. + + The TIME attack can be mitigated by disabling TLS compression. We + are not aware of mitigations at the TLS protocol level to the BREACH + attack, and so application-level mitigations are needed (see + [BREACH]). For example, implementations of HTTP that use Cross-Site + Request Forgery (CSRF) tokens will need to randomize them. Even the + best practices and recommendations from [SECURE-TLS] are insufficient + to thwart this attack. + +2.7. Certificate and RSA-Related Attacks + + There have been several practical attacks on TLS when used with RSA + certificates (the most common use case). These include + [Bleichenbacher98] and [Klima03]. While the Bleichenbacher attack + has been mitigated in TLS 1.0, the Klima attack, which relies on a + version-check oracle, is only mitigated by TLS 1.1. + + The use of RSA certificates often involves exploitable timing issues + [Brumley03] (CVE-2003-0147), unless the implementation takes care to + explicitly eliminate them. + + + +Sheffer, et al. Informational [Page 5] + +RFC 7457 TLS Attacks February 2015 + + + A recent certificate fuzzing tool [Brubaker2014using] uncovered + numerous vulnerabilities in different TLS libraries related to + certificate validation. + +2.8. Theft of RSA Private Keys + + When TLS is used with most non-Diffie-Hellman cipher suites, it is + sufficient to obtain the server's private key in order to decrypt any + sessions (past and future) that were initiated with that server. + This technique is used, for example, by the popular Wireshark network + sniffer to inspect TLS-protected connections. + + It is known that stolen (or otherwise obtained) private keys have + been used as part of large-scale monitoring [RFC7258] of certain + servers. + + Such attacks can be mitigated by better protecting the private key, + e.g., using OS protections or dedicated hardware. Even more + effective is the use of cipher suites that offer "forward secrecy", + the property where revealing a secret such as a private key does not + expose past or future sessions to a passive attacker. + +2.9. Diffie-Hellman Parameters + + TLS allows the definition of ephemeral Diffie-Hellman (DH) and + Elliptic Curve Diffie-Hellman parameters in its respective key + exchange modes. This results in an attack detailed in + [Cross-Protocol]. Using predefined DH groups, as proposed in + [FFDHE-TLS], would mitigate this attack. + + In addition, clients that do not properly verify the received + parameters are exposed to man-in-the-middle (MITM) attacks. + Unfortunately, the TLS protocol does not mandate this verification + (see [RFC6989] for analogous information for IPsec). + +2.10. Renegotiation (CVE-2009-3555) + + A major attack on the TLS renegotiation mechanism applies to all + current versions of the protocol. The attack and the TLS extension + that resolves it are described in [RFC5746]. + +2.11. Triple Handshake (CVE-2014-1295) + + The triple handshake attack [BhargavanDFPS14] enables the attacker to + cause two TLS connections to share keying material. This leads to a + multitude of attacks, e.g., man-in-the-middle, breaking safe + renegotiation, and breaking channel binding via TLS Exporter + [RFC5705] or "tls-unique" [RFC5929]. + + + +Sheffer, et al. Informational [Page 6] + +RFC 7457 TLS Attacks February 2015 + + +2.12. Virtual Host Confusion + + A recent article [Delignat14] describes a security issue whereby + SSLv3 fallback and improper handling of session caches on the server + side can be abused by an attacker to establish a malicious connection + to a virtual host other than the one originally intended and approved + by the server. This attack is especially serious in performance + critical environments where sharing of SSLv3 session caches is very + common. + +2.13. Denial of Service + + Server CPU power has progressed over the years so that TLS can now be + turned on by default. However, the risk of malicious clients and + coordinated groups of clients ("botnets") mounting denial-of-service + attacks is still very real. TLS adds another vector for + computational attacks, since a client can easily (with little + computational effort) force the server to expend relatively large + computational work. It is known that such attacks have in fact been + mounted. + +2.14. Implementation Issues + + Even when the protocol is properly specified, this does not guarantee + the security of implementations. In fact, there are very common + issues that often plague TLS implementations. In particular, when + integrating into higher-level protocols, TLS and its PKI-based + authentication are sometimes the source of misunderstandings and + implementation "shortcuts". An extensive survey of these issues can + be found in [Georgiev2012]. + + o Implementations might omit validation of the server certificate + altogether. For example, this is true of the default + implementation of HTTP client libraries in Python 2 (e.g., CVE- + 2013-2191). + + o Implementations might not validate the server identity. This + validation typically amounts to matching the protocol-level server + name with the certificate's Subject Alternative Name field. Note: + this same information is often also found in the Common Name part + of the Distinguished Name, and some validators incorrectly + retrieve it from there instead of from the Subject Alternative + Name. + + o Implementations might validate the certificate chain incorrectly + or not at all, or use an incorrect or outdated trust anchor list. + + + + + +Sheffer, et al. Informational [Page 7] + +RFC 7457 TLS Attacks February 2015 + + + An implementation attack of a different kind, one that exploits a + simple coding mistake (bounds check), is the Heartbleed attack (CVE- + 2014-0160) that affected a wide swath of the Internet when it was + discovered in April 2014. + +2.15. Usability + + Many TLS endpoints, such as browsers and mail clients, allow the user + to explicitly accept an invalid server certificate. This often takes + the form of a UI dialog (e.g., "do you accept this server?"), and + users have been conditioned to respond in the affirmative in order to + allow the connection to take place. + + This user behavior is used by (arguably legitimate) "SSL proxies" + that decrypt and re-encrypt the TLS connection in order to enforce + local security policy. It is also abused by attackers whose goal is + to gain access to the encrypted information. + + Mitigation is complex and will probably involve a combination of + protocol mechanisms (HSTS, certificate pinning [KEY-PINNING]), and + very careful UI design. + +3. Applicability to DTLS + + DTLS [RFC4347] [RFC6347] is an adaptation of TLS for UDP. + + With respect to the attacks described in the current document, DTLS + 1.0 is equivalent to TLS 1.1. The only exception is RC4, which is + disallowed in DTLS. DTLS 1.2 is equivalent to TLS 1.2. + +4. Security Considerations + + This document describes protocol attacks in an informational manner + and in itself does not have any security implications. Its companion + documents, especially [SECURE-TLS], certainly do. + +5. Informative References + + [Attacks-iSec] + Sarkar, P. and S. Fitzgerald, "Attacks on SSL, a + comprehensive study of BEAST, CRIME, TIME, BREACH, Lucky13 + and RC4 biases", August 2013, + . + + [BEAST] Rizzo, J. and T. Duong, "Browser Exploit Against SSL/TLS", + 2011, . + + + +Sheffer, et al. Informational [Page 8] + +RFC 7457 TLS Attacks February 2015 + + + [BREACH] Prado, A., Harris, N., and Y. Gluck, "The BREACH Attack", + 2013, . + + [BhargavanDFPS14] + Bhargavan, K., Delignat-Lavaud, A., Fournet, C., Pironti, + A., and P. Strub, "Triple handshakes and cookie cutters: + breaking and fixing authentication over tls", 2014, + . + + [Bleichenbacher98] + Bleichenbacher, D., "Chosen Ciphertext Attacks Against + Protocols Based on the RSA Encryption Standard PKCS #1", + 1998, . + + [Brubaker2014using] + Brubaker, C., Jana, S., Ray, B., Khurshid, S., and V. + Shmatikov, "Using Frankencerts for Automated Adversarial + Testing of Certificate Validation in SSL/TLS + Implementations", 2014, + . + + [Brumley03] + Brumley, D. and D. Boneh, "Remote Timing Attacks are + Practical", 2003, + . + + [CBC-Attack] + AlFardan, N. and K. Paterson, "Lucky Thirteen: Breaking + the TLS and DTLS Record Protocols", IEEE Symposium on + Security and Privacy, 2013, . + + [CIPHER-SUITES] + Popov, A., "Prohibiting RC4 Cipher Suites", Work in + Progress, draft-ietf-tls-prohibiting-rc4-01, October 2014. + + [CRIME] Rizzo, J. and T. Duong, "The CRIME Attack", EKOparty + Security Conference, 2012. + + [CVE] MITRE, "Common Vulnerabilities and Exposures", + . + + + + + + + + + +Sheffer, et al. Informational [Page 9] + +RFC 7457 TLS Attacks February 2015 + + + [Cross-Protocol] + Mavrogiannopoulos, N., Vercauteren, F., Velichkov, V., and + B. Preneel, "A cross-protocol attack on the TLS protocol", + Proceedings of the 2012 ACM Conference in Computer and + Communications Security, pages 62-72, 2012, + . + + [Delignat14] + Delignat-Lavaud, A. and K. Bhargavan, "Virtual Host + Confusion: Weaknesses and Exploits", Black Hat 2014, 2014, + . + + [FFDHE-TLS] + Gillmor, D., "Negotiated Finite Field Diffie-Hellman + Ephemeral Parameters for TLS", Work in Progress, + draft-ietf-tls-negotiated-ff-dhe-05, December 2014. + + [Georgiev2012] + Georgiev, M., Iyengar, S., Jana, S., Anubhai, R., Boneh, + D., and V. Shmatikov, "The most dangerous code in the + world: validating SSL certificates in non-browser + software", Proceedings of the 2012 ACM conference on + Computer and Communications Security, pages 38-49, 2012, + . + + [KEY-PINNING] + Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning + Extension for HTTP", Work in Progress, + draft-ietf-websec-key-pinning-21, October 2014. + + [Klima03] Klima, V., Pokorny, O., and T. Rosa, "Attacking RSA-based + Sessions in SSL/TLS", 2003, + . + + [POODLE] Moeller, B., Duong, T., and K. Kotowicz, "This POODLE + Bites: Exploiting the SSL 3.0 Fallback", September 2014, + . + + [Padding-Oracle] + Vaudenay, S., "Security Flaws Induced by CBC Padding + Applications to SSL, IPSEC, WTLS...", EUROCRYPT 2002, + 2002, . + + [RC4] Schneier, B., "Applied Cryptography: Protocols, + Algorithms, and Source Code in C", Second Edition, October + 1996. + + + + +Sheffer, et al. Informational [Page 10] + +RFC 7457 TLS Attacks February 2015 + + + [RC4-Attack-AlF] + AlFardan, N., Bernstein, D., Paterson, K., Poettering, B., + and J. Schuldt, "On the Security of RC4 in TLS", Usenix + Security Symposium 2013, August 2013, + . + + [RC4-Attack-FMS] + Fluhrer, S., Mantin, I., and A. Shamir, "Weaknesses in the + Key Scheduling Algorithm of RC4", Selected Areas in + Cryptography, August 2001, + . + + [RC4-Attack-Man] + Mantin, I. and A. Shamir, "A Practical Attack on Broadcast + RC4", April 2001, + . + + [RC4-Attack-Pau] + Paul, G. and S. Maitra, "Permutation After RC4 Key + Scheduling Reveals the Secret Key", August 2007, + . + + [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer + Security", RFC 4347, April 2006, + . + + [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security + (TLS) Protocol Version 1.2", RFC 5246, August 2008, + . + + [RFC5288] Salowey, J., Choudhury, A., and D. McGrew, "AES Galois + Counter Mode (GCM) Cipher Suites for TLS", RFC 5288, + August 2008, . + + [RFC5705] Rescorla, E., "Keying Material Exporters for Transport + Layer Security (TLS)", RFC 5705, March 2010, + . + + [RFC5746] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov, + "Transport Layer Security (TLS) Renegotiation Indication + Extension", RFC 5746, February 2010, + . + + + + + + +Sheffer, et al. Informational [Page 11] + +RFC 7457 TLS Attacks February 2015 + + + [RFC5929] Altman, J., Williams, N., and L. Zhu, "Channel Bindings + for TLS", RFC 5929, July 2010, + . + + [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer + Security Version 1.2", RFC 6347, January 2012, + . + + [RFC6797] Hodges, J., Jackson, C., and A. Barth, "HTTP Strict + Transport Security (HSTS)", RFC 6797, November 2012, + . + + [RFC6989] Sheffer, Y. and S. Fluhrer, "Additional Diffie-Hellman + Tests for the Internet Key Exchange Protocol Version 2 + (IKEv2)", RFC 6989, July 2013, + . + + [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an + Attack", BCP 188, RFC 7258, May 2014, + . + + [RFC7366] Gutmann, P., "Encrypt-then-MAC for Transport Layer + Security (TLS) and Datagram Transport Layer Security + (DTLS)", RFC 7366, September 2014, + . + + [SECURE-TLS] + Sheffer, Y., Holz, R., and P. Saint-Andre, + "Recommendations for Secure Use of TLS and DTLS", Work in + Progress, draft-ietf-uta-tls-bcp-08, December 2014. + + [SSL-Stripping] + Marlinspike, M., "sslstrip", February 2009, + . + + [TIME] Be'ery, T. and A. Shulman, "A Perfect CRIME? Only TIME + Will Tell", Black Hat Europe 2013, 2013, + . + + + + + + + + + + + + +Sheffer, et al. Informational [Page 12] + +RFC 7457 TLS Attacks February 2015 + + +Acknowledgements + + We would like to thank Stephen Farrell, Simon Josefsson, John + Mattsson, Yoav Nir, Kenny Paterson, Patrick Pelletier, Tom Ritter, + Rich Salz, and Meral Shirazipour for their feedback on this document. + We thank Andrei Popov for contributing text on RC4, Kohei Kasamatsu + for text on Lucky13, Ilari Liusvaara for text on attacks and on DTLS, + Aaron Zauner for text on virtual host confusion, and Chris Newman for + text on STARTTLS command injection. Ralph Holz gratefully + acknowledges the support of NICTA (National ICT of Australia) in the + preparation of this document. + + During IESG review, Richard Barnes, Barry Leiba, and Kathleen + Moriarty caught several issues that needed to be addressed. + + The authors gratefully acknowledge the assistance of Leif Johansson + and Orit Levin as the working group chairs and Pete Resnick as the + sponsoring Area Director. + + The document was prepared using the lyx2rfc tool, created by Nico + Williams. + +Authors' Addresses + + Yaron Sheffer + Porticor + 29 HaHarash St. + Hod HaSharon 4501303 + Israel + + EMail: yaronf.ietf@gmail.com + + + Ralph Holz + Technische Universitaet Muenchen + Boltzmannstr. 3 + Garching 85748 + Germany + + EMail: holz@net.in.tum.de + + + Peter Saint-Andre + &yet + + EMail: peter@andyet.com + URI: https://andyet.com/ + + + + +Sheffer, et al. Informational [Page 13] + diff --git a/RFCs/rfc821.txt b/RFCs/rfc821.txt new file mode 100644 index 0000000..d877b72 --- /dev/null +++ b/RFCs/rfc821.txt @@ -0,0 +1,4050 @@ + + + + RFC 821 + + + + + + SIMPLE MAIL TRANSFER PROTOCOL + + + + Jonathan B. Postel + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + August 1982 + + + + Information Sciences Institute + University of Southern California + 4676 Admiralty Way + Marina del Rey, California 90291 + + (213) 822-1511 + + + + +RFC 821 August 1982 + Simple Mail Transfer Protocol + + + + TABLE OF CONTENTS + + 1. INTRODUCTION .................................................. 1 + + 2. THE SMTP MODEL ................................................ 2 + + 3. THE SMTP PROCEDURE ............................................ 4 + + 3.1. Mail ..................................................... 4 + 3.2. Forwarding ............................................... 7 + 3.3. Verifying and Expanding .................................. 8 + 3.4. Sending and Mailing ..................................... 11 + 3.5. Opening and Closing ..................................... 13 + 3.6. Relaying ................................................ 14 + 3.7. Domains ................................................. 17 + 3.8. Changing Roles .......................................... 18 + + 4. THE SMTP SPECIFICATIONS ...................................... 19 + + 4.1. SMTP Commands ........................................... 19 + 4.1.1. Command Semantics ..................................... 19 + 4.1.2. Command Syntax ........................................ 27 + 4.2. SMTP Replies ............................................ 34 + 4.2.1. Reply Codes by Function Group ......................... 35 + 4.2.2. Reply Codes in Numeric Order .......................... 36 + 4.3. Sequencing of Commands and Replies ...................... 37 + 4.4. State Diagrams .......................................... 39 + 4.5. Details ................................................. 41 + 4.5.1. Minimum Implementation ................................ 41 + 4.5.2. Transparency .......................................... 41 + 4.5.3. Sizes ................................................. 42 + + APPENDIX A: TCP ................................................. 44 + APPENDIX B: NCP ................................................. 45 + APPENDIX C: NITS ................................................ 46 + APPENDIX D: X.25 ................................................ 47 + APPENDIX E: Theory of Reply Codes ............................... 48 + APPENDIX F: Scenarios ........................................... 51 + + GLOSSARY ......................................................... 64 + + REFERENCES ....................................................... 67 + + + + +Network Working Group J. Postel +Request for Comments: DRAFT ISI +Replaces: RFC 788, 780, 772 August 1982 + + SIMPLE MAIL TRANSFER PROTOCOL + + +1. INTRODUCTION + + The objective of Simple Mail Transfer Protocol (SMTP) is to transfer + mail reliably and efficiently. + + SMTP is independent of the particular transmission subsystem and + requires only a reliable ordered data stream channel. Appendices A, + B, C, and D describe the use of SMTP with various transport services. + A Glossary provides the definitions of terms as used in this + document. + + An important feature of SMTP is its capability to relay mail across + transport service environments. A transport service provides an + interprocess communication environment (IPCE). An IPCE may cover one + network, several networks, or a subset of a network. It is important + to realize that transport systems (or IPCEs) are not one-to-one with + networks. A process can communicate directly with another process + through any mutually known IPCE. Mail is an application or use of + interprocess communication. Mail can be communicated between + processes in different IPCEs by relaying through a process connected + to two (or more) IPCEs. More specifically, mail can be relayed + between hosts on different transport systems by a host on both + transport systems. + + + + + + + + + + + + + + + + + + + + + + + + +Postel [Page 1] + + + +August 1982 RFC 821 +Simple Mail Transfer Protocol + + + +2. THE SMTP MODEL + + The SMTP design is based on the following model of communication: as + the result of a user mail request, the sender-SMTP establishes a + two-way transmission channel to a receiver-SMTP. The receiver-SMTP + may be either the ultimate destination or an intermediate. SMTP + commands are generated by the sender-SMTP and sent to the + receiver-SMTP. SMTP replies are sent from the receiver-SMTP to the + sender-SMTP in response to the commands. + + Once the transmission channel is established, the SMTP-sender sends a + MAIL command indicating the sender of the mail. If the SMTP-receiver + can accept mail it responds with an OK reply. The SMTP-sender then + sends a RCPT command identifying a recipient of the mail. If the + SMTP-receiver can accept mail for that recipient it responds with an + OK reply; if not, it responds with a reply rejecting that recipient + (but not the whole mail transaction). The SMTP-sender and + SMTP-receiver may negotiate several recipients. When the recipients + have been negotiated the SMTP-sender sends the mail data, terminating + with a special sequence. If the SMTP-receiver successfully processes + the mail data it responds with an OK reply. The dialog is purposely + lock-step, one-at-a-time. + + ------------------------------------------------------------- + + + +----------+ +----------+ + +------+ | | | | + | User |<-->| | SMTP | | + +------+ | Sender- |Commands/Replies| Receiver-| + +------+ | SMTP |<-------------->| SMTP | +------+ + | File |<-->| | and Mail | |<-->| File | + |System| | | | | |System| + +------+ +----------+ +----------+ +------+ + + + Sender-SMTP Receiver-SMTP + + Model for SMTP Use + + Figure 1 + + ------------------------------------------------------------- + + The SMTP provides mechanisms for the transmission of mail; directly + from the sending user's host to the receiving user's host when the + + + +[Page 2] Postel + + + +RFC 821 August 1982 + Simple Mail Transfer Protocol + + + + two host are connected to the same transport service, or via one or + more relay SMTP-servers when the source and destination hosts are not + connected to the same transport service. + + To be able to provide the relay capability the SMTP-server must be + supplied with the name of the ultimate destination host as well as + the destination mailbox name. + + The argument to the MAIL command is a reverse-path, which specifies + who the mail is from. The argument to the RCPT command is a + forward-path, which specifies who the mail is to. The forward-path + is a source route, while the reverse-path is a return route (which + may be used to return a message to the sender when an error occurs + with a relayed message). + + When the same message is sent to multiple recipients the SMTP + encourages the transmission of only one copy of the data for all the + recipients at the same destination host. + + The mail commands and replies have a rigid syntax. Replies also have + a numeric code. In the following, examples appear which use actual + commands and replies. The complete lists of commands and replies + appears in Section 4 on specifications. + + Commands and replies are not case sensitive. That is, a command or + reply word may be upper case, lower case, or any mixture of upper and + lower case. Note that this is not true of mailbox user names. For + some hosts the user name is case sensitive, and SMTP implementations + must take case to preserve the case of user names as they appear in + mailbox arguments. Host names are not case sensitive. + + Commands and replies are composed of characters from the ASCII + character set [1]. When the transport service provides an 8-bit byte + (octet) transmission channel, each 7-bit character is transmitted + right justified in an octet with the high order bit cleared to zero. + + When specifying the general form of a command or reply, an argument + (or special symbol) will be denoted by a meta-linguistic variable (or + constant), for example, "" or "". Here the + angle brackets indicate these are meta-linguistic variables. + However, some arguments use the angle brackets literally. For + example, an actual reverse-path is enclosed in angle brackets, i.e., + "" is an instance of (the + angle brackets are actually transmitted in the command or reply). + + + + + +Postel [Page 3] + + + +August 1982 RFC 821 +Simple Mail Transfer Protocol + + + +3. THE SMTP PROCEDURES + + This section presents the procedures used in SMTP in several parts. + First comes the basic mail procedure defined as a mail transaction. + Following this are descriptions of forwarding mail, verifying mailbox + names and expanding mailing lists, sending to terminals instead of or + in combination with mailboxes, and the opening and closing exchanges. + At the end of this section are comments on relaying, a note on mail + domains, and a discussion of changing roles. Throughout this section + are examples of partial command and reply sequences, several complete + scenarios are presented in Appendix F. + + 3.1. MAIL + + There are three steps to SMTP mail transactions. The transaction + is started with a MAIL command which gives the sender + identification. A series of one or more RCPT commands follows + giving the receiver information. Then a DATA command gives the + mail data. And finally, the end of mail data indicator confirms + the transaction. + + The first step in the procedure is the MAIL command. The + contains the source mailbox. + + MAIL FROM: + + This command tells the SMTP-receiver that a new mail + transaction is starting and to reset all its state tables and + buffers, including any recipients or mail data. It gives the + reverse-path which can be used to report errors. If accepted, + the receiver-SMTP returns a 250 OK reply. + + The can contain more than just a mailbox. The + is a reverse source routing list of hosts and + source mailbox. The first host in the should be + the host sending this command. + + The second step in the procedure is the RCPT command. + + RCPT TO: + + This command gives a forward-path identifying one recipient. + If accepted, the receiver-SMTP returns a 250 OK reply, and + stores the forward-path. If the recipient is unknown the + receiver-SMTP returns a 550 Failure reply. This second step of + the procedure can be repeated any number of times. + + + +[Page 4] Postel + + + +RFC 821 August 1982 + Simple Mail Transfer Protocol + + + + The can contain more than just a mailbox. The + is a source routing list of hosts and the + destination mailbox. The first host in the + should be the host receiving this command. + + The third step in the procedure is the DATA command. + + DATA + + If accepted, the receiver-SMTP returns a 354 Intermediate reply + and considers all succeeding lines to be the message text. + When the end of text is received and stored the SMTP-receiver + sends a 250 OK reply. + + Since the mail data is sent on the transmission channel the end + of the mail data must be indicated so that the command and + reply dialog can be resumed. SMTP indicates the end of the + mail data by sending a line containing only a period. A + transparency procedure is used to prevent this from interfering + with the user's text (see Section 4.5.2). + + Please note that the mail data includes the memo header + items such as Date, Subject, To, Cc, From [2]. + + The end of mail data indicator also confirms the mail + transaction and tells the receiver-SMTP to now process the + stored recipients and mail data. If accepted, the + receiver-SMTP returns a 250 OK reply. The DATA command should + fail only if the mail transaction was incomplete (for example, + no recipients), or if resources are not available. + + The above procedure is an example of a mail transaction. These + commands must be used only in the order discussed above. + Example 1 (below) illustrates the use of these commands in a mail + transaction. + + + + + + + + + + + + + + +Postel [Page 5] + + + +August 1982 RFC 821 +Simple Mail Transfer Protocol + + + + ------------------------------------------------------------- + + Example of the SMTP Procedure + + This SMTP example shows mail sent by Smith at host Alpha.ARPA, + to Jones, Green, and Brown at host Beta.ARPA. Here we assume + that host Alpha contacts host Beta directly. + + S: MAIL FROM: + R: 250 OK + + S: RCPT TO: + R: 250 OK + + S: RCPT TO: + R: 550 No such user here + + S: RCPT TO: + R: 250 OK + + S: DATA + R: 354 Start mail input; end with . + S: Blah blah blah... + S: ...etc. etc. etc. + S: . + R: 250 OK + + The mail has now been accepted for Jones and Brown. Green did + not have a mailbox at host Beta. + + Example 1 + + ------------------------------------------------------------- + + + + + + + + + + + + + + + + +[Page 6] Postel + + + +RFC 821 August 1982 + Simple Mail Transfer Protocol + + + + 3.2. FORWARDING + + There are some cases where the destination information in the + is incorrect, but the receiver-SMTP knows the + correct destination. In such cases, one of the following replies + should be used to allow the sender to contact the correct + destination. + + 251 User not local; will forward to + + This reply indicates that the receiver-SMTP knows the user's + mailbox is on another host and indicates the correct + forward-path to use in the future. Note that either the + host or user or both may be different. The receiver takes + responsibility for delivering the message. + + 551 User not local; please try + + This reply indicates that the receiver-SMTP knows the user's + mailbox is on another host and indicates the correct + forward-path to use. Note that either the host or user or + both may be different. The receiver refuses to accept mail + for this user, and the sender must either redirect the mail + according to the information provided or return an error + response to the originating user. + + Example 2 illustrates the use of these responses. + + ------------------------------------------------------------- + + Example of Forwarding + + Either + + S: RCPT TO: + R: 251 User not local; will forward to + + Or + + S: RCPT TO: + R: 551 User not local; please try + + Example 2 + + ------------------------------------------------------------- + + + + +Postel [Page 7] + + + +August 1982 RFC 821 +Simple Mail Transfer Protocol + + + + 3.3. VERIFYING AND EXPANDING + + SMTP provides as additional features, commands to verify a user + name or expand a mailing list. This is done with the VRFY and + EXPN commands, which have character string arguments. For the + VRFY command, the string is a user name, and the response may + include the full name of the user and must include the mailbox of + the user. For the EXPN command, the string identifies a mailing + list, and the multiline response may include the full name of the + users and must give the mailboxes on the mailing list. + + "User name" is a fuzzy term and used purposely. If a host + implements the VRFY or EXPN commands then at least local mailboxes + must be recognized as "user names". If a host chooses to + recognize other strings as "user names" that is allowed. + + In some hosts the distinction between a mailing list and an alias + for a single mailbox is a bit fuzzy, since a common data structure + may hold both types of entries, and it is possible to have mailing + lists of one mailbox. If a request is made to verify a mailing + list a positive response can be given if on receipt of a message + so addressed it will be delivered to everyone on the list, + otherwise an error should be reported (e.g., "550 That is a + mailing list, not a user"). If a request is made to expand a user + name a positive response can be formed by returning a list + containing one name, or an error can be reported (e.g., "550 That + is a user name, not a mailing list"). + + In the case of a multiline reply (normal for EXPN) exactly one + mailbox is to be specified on each line of the reply. In the case + of an ambiguous request, for example, "VRFY Smith", where there + are two Smith's the response must be "553 User ambiguous". + + The case of verifying a user name is straightforward as shown in + example 3. + + + + + + + + + + + + + + +[Page 8] Postel + + + +RFC 821 August 1982 + Simple Mail Transfer Protocol + + + + ------------------------------------------------------------- + + Example of Verifying a User Name + + Either + + S: VRFY Smith + R: 250 Fred Smith + + Or + + S: VRFY Smith + R: 251 User not local; will forward to + + Or + + S: VRFY Jones + R: 550 String does not match anything. + + Or + + S: VRFY Jones + R: 551 User not local; please try + + Or + + S: VRFY Gourzenkyinplatz + R: 553 User ambiguous. + + Example 3 + + ------------------------------------------------------------- + + + + + + + + + + + + + + + + + +Postel [Page 9] + + + +August 1982 RFC 821 +Simple Mail Transfer Protocol + + + + The case of expanding a mailbox list requires a multiline reply as + shown in example 4. + + ------------------------------------------------------------- + + Example of Expanding a Mailing List + + Either + + S: EXPN Example-People + R: 250-Jon Postel + R: 250-Fred Fonebone + R: 250-Sam Q. Smith + R: 250-Quincy Smith <@USC-ISIF.ARPA:Q-Smith@ISI-VAXA.ARPA> + R: 250- + R: 250 + + Or + + S: EXPN Executive-Washroom-List + R: 550 Access Denied to You. + + Example 4 + + ------------------------------------------------------------- + + The character string arguments of the VRFY and EXPN commands + cannot be further restricted due to the variety of implementations + of the user name and mailbox list concepts. On some systems it + may be appropriate for the argument of the EXPN command to be a + file name for a file containing a mailing list, but again there is + a variety of file naming conventions in the Internet. + + The VRFY and EXPN commands are not included in the minimum + implementation (Section 4.5.1), and are not required to work + across relays when they are implemented. + + + + + + + + + + + + + +[Page 10] Postel + + + +RFC 821 August 1982 + Simple Mail Transfer Protocol + + + + 3.4. SENDING AND MAILING + + The main purpose of SMTP is to deliver messages to user's + mailboxes. A very similar service provided by some hosts is to + deliver messages to user's terminals (provided the user is active + on the host). The delivery to the user's mailbox is called + "mailing", the delivery to the user's terminal is called + "sending". Because in many hosts the implementation of sending is + nearly identical to the implementation of mailing these two + functions are combined in SMTP. However the sending commands are + not included in the required minimum implementation + (Section 4.5.1). Users should have the ability to control the + writing of messages on their terminals. Most hosts permit the + users to accept or refuse such messages. + + The following three command are defined to support the sending + options. These are used in the mail transaction instead of the + MAIL command and inform the receiver-SMTP of the special semantics + of this transaction: + + SEND FROM: + + The SEND command requires that the mail data be delivered to + the user's terminal. If the user is not active (or not + accepting terminal messages) on the host a 450 reply may + returned to a RCPT command. The mail transaction is + successful if the message is delivered the terminal. + + SOML FROM: + + The Send Or MaiL command requires that the mail data be + delivered to the user's terminal if the user is active (and + accepting terminal messages) on the host. If the user is + not active (or not accepting terminal messages) then the + mail data is entered into the user's mailbox. The mail + transaction is successful if the message is delivered either + to the terminal or the mailbox. + + SAML FROM: + + The Send And MaiL command requires that the mail data be + delivered to the user's terminal if the user is active (and + accepting terminal messages) on the host. In any case the + mail data is entered into the user's mailbox. The mail + transaction is successful if the message is delivered the + mailbox. + + + +Postel [Page 11] + + + +August 1982 RFC 821 +Simple Mail Transfer Protocol + + + + The same reply codes that are used for the MAIL commands are used + for these commands. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +[Page 12] Postel + + + +RFC 821 August 1982 + Simple Mail Transfer Protocol + + + + 3.5. OPENING AND CLOSING + + At the time the transmission channel is opened there is an + exchange to ensure that the hosts are communicating with the hosts + they think they are. + + The following two commands are used in transmission channel + opening and closing: + + HELO + + QUIT + + In the HELO command the host sending the command identifies + itself; the command may be interpreted as saying "Hello, I am + ". + + ------------------------------------------------------------- + + Example of Connection Opening + + R: 220 BBN-UNIX.ARPA Simple Mail Transfer Service Ready + S: HELO USC-ISIF.ARPA + R: 250 BBN-UNIX.ARPA + + Example 5 + + ------------------------------------------------------------- + + ------------------------------------------------------------- + + Example of Connection Closing + + S: QUIT + R: 221 BBN-UNIX.ARPA Service closing transmission channel + + Example 6 + + ------------------------------------------------------------- + + + + + + + + + + +Postel [Page 13] + + + +August 1982 RFC 821 +Simple Mail Transfer Protocol + + + + 3.6. RELAYING + + The forward-path may be a source route of the form + "@ONE,@TWO:JOE@THREE", where ONE, TWO, and THREE are hosts. This + form is used to emphasize the distinction between an address and a + route. The mailbox is an absolute address, and the route is + information about how to get there. The two concepts should not + be confused. + + Conceptually the elements of the forward-path are moved to the + reverse-path as the message is relayed from one server-SMTP to + another. The reverse-path is a reverse source route, (i.e., a + source route from the current location of the message to the + originator of the message). When a server-SMTP deletes its + identifier from the forward-path and inserts it into the + reverse-path, it must use the name it is known by in the + environment it is sending into, not the environment the mail came + from, in case the server-SMTP is known by different names in + different environments. + + If when the message arrives at an SMTP the first element of the + forward-path is not the identifier of that SMTP the element is not + deleted from the forward-path and is used to determine the next + SMTP to send the message to. In any case, the SMTP adds its own + identifier to the reverse-path. + + Using source routing the receiver-SMTP receives mail to be relayed + to another server-SMTP The receiver-SMTP may accept or reject the + task of relaying the mail in the same way it accepts or rejects + mail for a local user. The receiver-SMTP transforms the command + arguments by moving its own identifier from the forward-path to + the beginning of the reverse-path. The receiver-SMTP then becomes + a sender-SMTP, establishes a transmission channel to the next SMTP + in the forward-path, and sends it the mail. + + The first host in the reverse-path should be the host sending the + SMTP commands, and the first host in the forward-path should be + the host receiving the SMTP commands. + + Notice that the forward-path and reverse-path appear in the SMTP + commands and replies, but not necessarily in the message. That + is, there is no need for these paths and especially this syntax to + appear in the "To:" , "From:", "CC:", etc. fields of the message + header. + + If a server-SMTP has accepted the task of relaying the mail and + + + +[Page 14] Postel + + + +RFC 821 August 1982 + Simple Mail Transfer Protocol + + + + later finds that the forward-path is incorrect or that the mail + cannot be delivered for whatever reason, then it must construct an + "undeliverable mail" notification message and send it to the + originator of the undeliverable mail (as indicated by the + reverse-path). + + This notification message must be from the server-SMTP at this + host. Of course, server-SMTPs should not send notification + messages about problems with notification messages. One way to + prevent loops in error reporting is to specify a null reverse-path + in the MAIL command of a notification message. When such a + message is relayed it is permissible to leave the reverse-path + null. A MAIL command with a null reverse-path appears as follows: + + MAIL FROM:<> + + An undeliverable mail notification message is shown in example 7. + This notification is in response to a message originated by JOE at + HOSTW and sent via HOSTX to HOSTY with instructions to relay it on + to HOSTZ. What we see in the example is the transaction between + HOSTY and HOSTX, which is the first step in the return of the + notification message. + + + + + + + + + + + + + + + + + + + + + + + + + + + +Postel [Page 15] + + + +August 1982 RFC 821 +Simple Mail Transfer Protocol + + + + ------------------------------------------------------------- + + Example Undeliverable Mail Notification Message + + S: MAIL FROM:<> + R: 250 ok + S: RCPT TO:<@HOSTX.ARPA:JOE@HOSTW.ARPA> + R: 250 ok + S: DATA + R: 354 send the mail data, end with . + S: Date: 23 Oct 81 11:22:33 + S: From: SMTP@HOSTY.ARPA + S: To: JOE@HOSTW.ARPA + S: Subject: Mail System Problem + S: + S: Sorry JOE, your message to SAM@HOSTZ.ARPA lost. + S: HOSTZ.ARPA said this: + S: "550 No Such User" + S: . + R: 250 ok + + Example 7 + + ------------------------------------------------------------- + + + + + + + + + + + + + + + + + + + + + + + + + +[Page 16] Postel + + + +RFC 821 August 1982 + Simple Mail Transfer Protocol + + + + 3.7. DOMAINS + + Domains are a recently introduced concept in the ARPA Internet + mail system. The use of domains changes the address space from a + flat global space of simple character string host names to a + hierarchically structured rooted tree of global addresses. The + host name is replaced by a domain and host designator which is a + sequence of domain element strings separated by periods with the + understanding that the domain elements are ordered from the most + specific to the most general. + + For example, "USC-ISIF.ARPA", "Fred.Cambridge.UK", and + "PC7.LCS.MIT.ARPA" might be host-and-domain identifiers. + + Whenever domain names are used in SMTP only the official names are + used, the use of nicknames or aliases is not allowed. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Postel [Page 17] + + + +August 1982 RFC 821 +Simple Mail Transfer Protocol + + + + 3.8. CHANGING ROLES + + The TURN command may be used to reverse the roles of the two + programs communicating over the transmission channel. + + If program-A is currently the sender-SMTP and it sends the TURN + command and receives an ok reply (250) then program-A becomes the + receiver-SMTP. + + If program-B is currently the receiver-SMTP and it receives the + TURN command and sends an ok reply (250) then program-B becomes + the sender-SMTP. + + To refuse to change roles the receiver sends the 502 reply. + + Please note that this command is optional. It would not normally + be used in situations where the transmission channel is TCP. + However, when the cost of establishing the transmission channel is + high, this command may be quite useful. For example, this command + may be useful in supporting be mail exchange using the public + switched telephone system as a transmission channel, especially if + some hosts poll other hosts for mail exchanges. + + + + + + + + + + + + + + + + + + + + + + + + + + + +[Page 18] Postel + + + +RFC 821 August 1982 + Simple Mail Transfer Protocol + + + +4. THE SMTP SPECIFICATIONS + + 4.1. SMTP COMMANDS + + 4.1.1. COMMAND SEMANTICS + + The SMTP commands define the mail transfer or the mail system + function requested by the user. SMTP commands are character + strings terminated by . The command codes themselves are + alphabetic characters terminated by if parameters follow + and otherwise. The syntax of mailboxes must conform to + receiver site conventions. The SMTP commands are discussed + below. The SMTP replies are discussed in the Section 4.2. + + A mail transaction involves several data objects which are + communicated as arguments to different commands. The + reverse-path is the argument of the MAIL command, the + forward-path is the argument of the RCPT command, and the mail + data is the argument of the DATA command. These arguments or + data objects must be transmitted and held pending the + confirmation communicated by the end of mail data indication + which finalizes the transaction. The model for this is that + distinct buffers are provided to hold the types of data + objects, that is, there is a reverse-path buffer, a + forward-path buffer, and a mail data buffer. Specific commands + cause information to be appended to a specific buffer, or cause + one or more buffers to be cleared. + + HELLO (HELO) + + This command is used to identify the sender-SMTP to the + receiver-SMTP. The argument field contains the host name of + the sender-SMTP. + + The receiver-SMTP identifies itself to the sender-SMTP in + the connection greeting reply, and in the response to this + command. + + This command and an OK reply to it confirm that both the + sender-SMTP and the receiver-SMTP are in the initial state, + that is, there is no transaction in progress and all state + tables and buffers are cleared. + + + + + + + +Postel [Page 19] + + + +August 1982 RFC 821 +Simple Mail Transfer Protocol + + + + MAIL (MAIL) + + This command is used to initiate a mail transaction in which + the mail data is delivered to one or more mailboxes. The + argument field contains a reverse-path. + + The reverse-path consists of an optional list of hosts and + the sender mailbox. When the list of hosts is present, it + is a "reverse" source route and indicates that the mail was + relayed through each host on the list (the first host in the + list was the most recent relay). This list is used as a + source route to return non-delivery notices to the sender. + As each relay host adds itself to the beginning of the list, + it must use its name as known in the IPCE to which it is + relaying the mail rather than the IPCE from which the mail + came (if they are different). In some types of error + reporting messages (for example, undeliverable mail + notifications) the reverse-path may be null (see Example 7). + + This command clears the reverse-path buffer, the + forward-path buffer, and the mail data buffer; and inserts + the reverse-path information from this command into the + reverse-path buffer. + + RECIPIENT (RCPT) + + This command is used to identify an individual recipient of + the mail data; multiple recipients are specified by multiple + use of this command. + + The forward-path consists of an optional list of hosts and a + required destination mailbox. When the list of hosts is + present, it is a source route and indicates that the mail + must be relayed to the next host on the list. If the + receiver-SMTP does not implement the relay function it may + user the same reply it would for an unknown local user + (550). + + When mail is relayed, the relay host must remove itself from + the beginning forward-path and put itself at the beginning + of the reverse-path. When mail reaches its ultimate + destination (the forward-path contains only a destination + mailbox), the receiver-SMTP inserts it into the destination + mailbox in accordance with its host mail conventions. + + + + + +[Page 20] Postel + + + +RFC 821 August 1982 + Simple Mail Transfer Protocol + + + + For example, mail received at relay host A with arguments + + FROM: + TO:<@HOSTA.ARPA,@HOSTB.ARPA:USERC@HOSTD.ARPA> + + will be relayed on to host B with arguments + + FROM:<@HOSTA.ARPA:USERX@HOSTY.ARPA> + TO:<@HOSTB.ARPA:USERC@HOSTD.ARPA>. + + This command causes its forward-path argument to be appended + to the forward-path buffer. + + DATA (DATA) + + The receiver treats the lines following the command as mail + data from the sender. This command causes the mail data + from this command to be appended to the mail data buffer. + The mail data may contain any of the 128 ASCII character + codes. + + The mail data is terminated by a line containing only a + period, that is the character sequence "." (see + Section 4.5.2 on Transparency). This is the end of mail + data indication. + + The end of mail data indication requires that the receiver + must now process the stored mail transaction information. + This processing consumes the information in the reverse-path + buffer, the forward-path buffer, and the mail data buffer, + and on the completion of this command these buffers are + cleared. If the processing is successful the receiver must + send an OK reply. If the processing fails completely the + receiver must send a failure reply. + + When the receiver-SMTP accepts a message either for relaying + or for final delivery it inserts at the beginning of the + mail data a time stamp line. The time stamp line indicates + the identity of the host that sent the message, and the + identity of the host that received the message (and is + inserting this time stamp), and the date and time the + message was received. Relayed messages will have multiple + time stamp lines. + + When the receiver-SMTP makes the "final delivery" of a + message it inserts at the beginning of the mail data a + + + +Postel [Page 21] + + + +August 1982 RFC 821 +Simple Mail Transfer Protocol + + + + return path line. The return path line preserves the + information in the from the MAIL command. + Here, final delivery means the message leaves the SMTP + world. Normally, this would mean it has been delivered to + the destination user, but in some cases it may be further + processed and transmitted by another mail system. + + It is possible for the mailbox in the return path be + different from the actual sender's mailbox, for example, + if error responses are to be delivered a special error + handling mailbox rather than the message senders. + + The preceding two paragraphs imply that the final mail data + will begin with a return path line, followed by one or more + time stamp lines. These lines will be followed by the mail + data header and body [2]. See Example 8. + + Special mention is needed of the response and further action + required when the processing following the end of mail data + indication is partially successful. This could arise if + after accepting several recipients and the mail data, the + receiver-SMTP finds that the mail data can be successfully + delivered to some of the recipients, but it cannot be to + others (for example, due to mailbox space allocation + problems). In such a situation, the response to the DATA + command must be an OK reply. But, the receiver-SMTP must + compose and send an "undeliverable mail" notification + message to the originator of the message. Either a single + notification which lists all of the recipients that failed + to get the message, or separate notification messages must + be sent for each failed recipient (see Example 7). All + undeliverable mail notification messages are sent using the + MAIL command (even if they result from processing a SEND, + SOML, or SAML command). + + + + + + + + + + + + + + + +[Page 22] Postel + + + +RFC 821 August 1982 + Simple Mail Transfer Protocol + + + + ------------------------------------------------------------- + + Example of Return Path and Received Time Stamps + + Return-Path: <@GHI.ARPA,@DEF.ARPA,@ABC.ARPA:JOE@ABC.ARPA> + Received: from GHI.ARPA by JKL.ARPA ; 27 Oct 81 15:27:39 PST + Received: from DEF.ARPA by GHI.ARPA ; 27 Oct 81 15:15:13 PST + Received: from ABC.ARPA by DEF.ARPA ; 27 Oct 81 15:01:59 PST + Date: 27 Oct 81 15:01:01 PST + From: JOE@ABC.ARPA + Subject: Improved Mailing System Installed + To: SAM@JKL.ARPA + + This is to inform you that ... + + Example 8 + + ------------------------------------------------------------- + + SEND (SEND) + + This command is used to initiate a mail transaction in which + the mail data is delivered to one or more terminals. The + argument field contains a reverse-path. This command is + successful if the message is delivered to a terminal. + + The reverse-path consists of an optional list of hosts and + the sender mailbox. When the list of hosts is present, it + is a "reverse" source route and indicates that the mail was + relayed through each host on the list (the first host in the + list was the most recent relay). This list is used as a + source route to return non-delivery notices to the sender. + As each relay host adds itself to the beginning of the list, + it must use its name as known in the IPCE to which it is + relaying the mail rather than the IPCE from which the mail + came (if they are different). + + This command clears the reverse-path buffer, the + forward-path buffer, and the mail data buffer; and inserts + the reverse-path information from this command into the + reverse-path buffer. + + SEND OR MAIL (SOML) + + This command is used to initiate a mail transaction in which + the mail data is delivered to one or more terminals or + + + +Postel [Page 23] + + + +August 1982 RFC 821 +Simple Mail Transfer Protocol + + + + mailboxes. For each recipient the mail data is delivered to + the recipient's terminal if the recipient is active on the + host (and accepting terminal messages), otherwise to the + recipient's mailbox. The argument field contains a + reverse-path. This command is successful if the message is + delivered to a terminal or the mailbox. + + The reverse-path consists of an optional list of hosts and + the sender mailbox. When the list of hosts is present, it + is a "reverse" source route and indicates that the mail was + relayed through each host on the list (the first host in the + list was the most recent relay). This list is used as a + source route to return non-delivery notices to the sender. + As each relay host adds itself to the beginning of the list, + it must use its name as known in the IPCE to which it is + relaying the mail rather than the IPCE from which the mail + came (if they are different). + + This command clears the reverse-path buffer, the + forward-path buffer, and the mail data buffer; and inserts + the reverse-path information from this command into the + reverse-path buffer. + + SEND AND MAIL (SAML) + + This command is used to initiate a mail transaction in which + the mail data is delivered to one or more terminals and + mailboxes. For each recipient the mail data is delivered to + the recipient's terminal if the recipient is active on the + host (and accepting terminal messages), and for all + recipients to the recipient's mailbox. The argument field + contains a reverse-path. This command is successful if the + message is delivered to the mailbox. + + The reverse-path consists of an optional list of hosts and + the sender mailbox. When the list of hosts is present, it + is a "reverse" source route and indicates that the mail was + relayed through each host on the list (the first host in the + list was the most recent relay). This list is used as a + source route to return non-delivery notices to the sender. + As each relay host adds itself to the beginning of the list, + it must use its name as known in the IPCE to which it is + relaying the mail rather than the IPCE from which the mail + came (if they are different). + + This command clears the reverse-path buffer, the + + + +[Page 24] Postel + + + +RFC 821 August 1982 + Simple Mail Transfer Protocol + + + + forward-path buffer, and the mail data buffer; and inserts + the reverse-path information from this command into the + reverse-path buffer. + + RESET (RSET) + + This command specifies that the current mail transaction is + to be aborted. Any stored sender, recipients, and mail data + must be discarded, and all buffers and state tables cleared. + The receiver must send an OK reply. + + VERIFY (VRFY) + + This command asks the receiver to confirm that the argument + identifies a user. If it is a user name, the full name of + the user (if known) and the fully specified mailbox are + returned. + + This command has no effect on any of the reverse-path + buffer, the forward-path buffer, or the mail data buffer. + + EXPAND (EXPN) + + This command asks the receiver to confirm that the argument + identifies a mailing list, and if so, to return the + membership of that list. The full name of the users (if + known) and the fully specified mailboxes are returned in a + multiline reply. + + This command has no effect on any of the reverse-path + buffer, the forward-path buffer, or the mail data buffer. + + HELP (HELP) + + This command causes the receiver to send helpful information + to the sender of the HELP command. The command may take an + argument (e.g., any command name) and return more specific + information as a response. + + This command has no effect on any of the reverse-path + buffer, the forward-path buffer, or the mail data buffer. + + + + + + + + +Postel [Page 25] + + + +August 1982 RFC 821 +Simple Mail Transfer Protocol + + + + NOOP (NOOP) + + This command does not affect any parameters or previously + entered commands. It specifies no action other than that + the receiver send an OK reply. + + This command has no effect on any of the reverse-path + buffer, the forward-path buffer, or the mail data buffer. + + QUIT (QUIT) + + This command specifies that the receiver must send an OK + reply, and then close the transmission channel. + + The receiver should not close the transmission channel until + it receives and replies to a QUIT command (even if there was + an error). The sender should not close the transmission + channel until it send a QUIT command and receives the reply + (even if there was an error response to a previous command). + If the connection is closed prematurely the receiver should + act as if a RSET command had been received (canceling any + pending transaction, but not undoing any previously + completed transaction), the sender should act as if the + command or transaction in progress had received a temporary + error (4xx). + + TURN (TURN) + + This command specifies that the receiver must either (1) + send an OK reply and then take on the role of the + sender-SMTP, or (2) send a refusal reply and retain the role + of the receiver-SMTP. + + If program-A is currently the sender-SMTP and it sends the + TURN command and receives an OK reply (250) then program-A + becomes the receiver-SMTP. Program-A is then in the initial + state as if the transmission channel just opened, and it + then sends the 220 service ready greeting. + + If program-B is currently the receiver-SMTP and it receives + the TURN command and sends an OK reply (250) then program-B + becomes the sender-SMTP. Program-B is then in the initial + state as if the transmission channel just opened, and it + then expects to receive the 220 service ready greeting. + + To refuse to change roles the receiver sends the 502 reply. + + + +[Page 26] Postel + + + +RFC 821 August 1982 + Simple Mail Transfer Protocol + + + + There are restrictions on the order in which these command may + be used. + + The first command in a session must be the HELO command. + The HELO command may be used later in a session as well. If + the HELO command argument is not acceptable a 501 failure + reply must be returned and the receiver-SMTP must stay in + the same state. + + The NOOP, HELP, EXPN, and VRFY commands can be used at any + time during a session. + + The MAIL, SEND, SOML, or SAML commands begin a mail + transaction. Once started a mail transaction consists of + one of the transaction beginning commands, one or more RCPT + commands, and a DATA command, in that order. A mail + transaction may be aborted by the RSET command. There may + be zero or more transactions in a session. + + If the transaction beginning command argument is not + acceptable a 501 failure reply must be returned and the + receiver-SMTP must stay in the same state. If the commands + in a transaction are out of order a 503 failure reply must + be returned and the receiver-SMTP must stay in the same + state. + + The last command in a session must be the QUIT command. The + QUIT command can not be used at any other time in a session. + + 4.1.2. COMMAND SYNTAX + + The commands consist of a command code followed by an argument + field. Command codes are four alphabetic characters. Upper + and lower case alphabetic characters are to be treated + identically. Thus, any of the following may represent the mail + command: + + MAIL Mail mail MaIl mAIl + + This also applies to any symbols representing parameter values, + such as "TO" or "to" for the forward-path. Command codes and + the argument fields are separated by one or more spaces. + However, within the reverse-path and forward-path arguments + case is important. In particular, in some hosts the user + "smith" is different from the user "Smith". + + + + +Postel [Page 27] + + + +August 1982 RFC 821 +Simple Mail Transfer Protocol + + + + The argument field consists of a variable length character + string ending with the character sequence . The receiver + is to take no action until this sequence is received. + + Square brackets denote an optional argument field. If the + option is not taken, the appropriate default is implied. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +[Page 28] Postel + + + +RFC 821 August 1982 + Simple Mail Transfer Protocol + + + + The following are the SMTP commands: + + HELO + + MAIL FROM: + + RCPT TO: + + DATA + + RSET + + SEND FROM: + + SOML FROM: + + SAML FROM: + + VRFY + + EXPN + + HELP [ ] + + NOOP + + QUIT + + TURN + + + + + + + + + + + + + + + + + + + + +Postel [Page 29] + + + +August 1982 RFC 821 +Simple Mail Transfer Protocol + + + + The syntax of the above argument fields (using BNF notation + where applicable) is given below. The "..." notation indicates + that a field may be repeated one or more times. + + ::= + + ::= + + ::= "<" [ ":" ] ">" + + ::= | "," + + ::= "@" + + ::= | "." + + ::= | "#" | "[" "]" + + ::= "@" + + ::= | + + ::= + + ::= | + + ::= | + + ::= | | "-" + + ::= | "." + + ::= | + + ::= """ """ + + ::= "\" | "\" | | + + ::= | "\" + + ::= "." "." "." + + ::= | + + ::= + + + + +[Page 30] Postel + + + +RFC 821 August 1982 + Simple Mail Transfer Protocol + + + + ::= the carriage return character (ASCII code 13) + + ::= the line feed character (ASCII code 10) + + ::= the space character (ASCII code 32) + + ::= one, two, or three digits representing a decimal + integer value in the range 0 through 255 + + ::= any one of the 52 alphabetic characters A through Z + in upper case and a through z in lower case + + ::= any one of the 128 ASCII characters, but not any + or + + ::= any one of the ten digits 0 through 9 + + ::= any one of the 128 ASCII characters except , + , quote ("), or backslash (\) + + ::= any one of the 128 ASCII characters (no exceptions) + + ::= "<" | ">" | "(" | ")" | "[" | "]" | "\" | "." + | "," | ";" | ":" | "@" """ | the control + characters (ASCII codes 0 through 31 inclusive and + 127) + + Note that the backslash, "\", is a quote character, which is + used to indicate that the next character is to be used + literally (instead of its normal interpretation). For example, + "Joe\,Smith" could be used to indicate a single nine character + user field with comma being the fourth character of the field. + + Hosts are generally known by names which are translated to + addresses in each host. Note that the name elements of domains + are the official names -- no use of nicknames or aliases is + allowed. + + Sometimes a host is not known to the translation function and + communication is blocked. To bypass this barrier two numeric + forms are also allowed for host "names". One form is a decimal + integer prefixed by a pound sign, "#", which indicates the + number is the address of the host. Another form is four small + decimal integers separated by dots and enclosed by brackets, + e.g., "[123.255.37.2]", which indicates a 32-bit ARPA Internet + Address in four 8-bit fields. + + + +Postel [Page 31] + + + +August 1982 RFC 821 +Simple Mail Transfer Protocol + + + + The time stamp line and the return path line are formally + defined as follows: + + ::= "Return-Path:" + + ::= "Received:" + + ::= ";" + + + ::= "FROM" + + ::= "BY" + + ::= [] [] [] [] + + ::= "VIA" + + ::= "WITH" + + ::= "ID" + + ::= "FOR" + + ::= The standard names for links are registered with + the Network Information Center. + + ::= The standard names for protocols are + registered with the Network Information Center. + + ::=
::= the one or two decimal integer day of the month in + the range 1 to 31. + + ::= "JAN" | "FEB" | "MAR" | "APR" | "MAY" | "JUN" | + "JUL" | "AUG" | "SEP" | "OCT" | "NOV" | "DEC" + + ::= the two decimal integer year of the century in the + range 00 to 99. + + + + + +[Page 32] Postel + + + +RFC 821 August 1982 + Simple Mail Transfer Protocol + + + + ::= the two decimal integer hour of the day in the + range 00 to 24. + + ::= the two decimal integer minute of the hour in the + range 00 to 59. + + ::= the two decimal integer second of the minute in the + range 00 to 59. + + ::= "UT" for Universal Time (the default) or other + time zone designator (as in [2]). + + + + ------------------------------------------------------------- + + Return Path Example + + Return-Path: <@CHARLIE.ARPA,@BAKER.ARPA:JOE@ABLE.ARPA> + + Example 9 + + ------------------------------------------------------------- + + ------------------------------------------------------------- + + Time Stamp Line Example + + Received: FROM ABC.ARPA BY XYZ.ARPA ; 22 OCT 81 09:23:59 PDT + + Received: from ABC.ARPA by XYZ.ARPA via TELENET with X25 + id M12345 for Smith@PDQ.ARPA ; 22 OCT 81 09:23:59 PDT + + Example 10 + + ------------------------------------------------------------- + + + + + + + + + + + + + +Postel [Page 33] + + + +August 1982 RFC 821 +Simple Mail Transfer Protocol + + + + 4.2. SMTP REPLIES + + Replies to SMTP commands are devised to ensure the synchronization + of requests and actions in the process of mail transfer, and to + guarantee that the sender-SMTP always knows the state of the + receiver-SMTP. Every command must generate exactly one reply. + + The details of the command-reply sequence are made explicit in + Section 5.3 on Sequencing and Section 5.4 State Diagrams. + + An SMTP reply consists of a three digit number (transmitted as + three alphanumeric characters) followed by some text. The number + is intended for use by automata to determine what state to enter + next; the text is meant for the human user. It is intended that + the three digits contain enough encoded information that the + sender-SMTP need not examine the text and may either discard it or + pass it on to the user, as appropriate. In particular, the text + may be receiver-dependent and context dependent, so there are + likely to be varying texts for each reply code. A discussion of + the theory of reply codes is given in Appendix E. Formally, a + reply is defined to be the sequence: a three-digit code, , + one line of text, and , or a multiline reply (as defined in + Appendix E). Only the EXPN and HELP commands are expected to + result in multiline replies in normal circumstances, however + multiline replies are allowed for any command. + + + + + + + + + + + + + + + + + + + + + + + + +[Page 34] Postel + + + +RFC 821 August 1982 + Simple Mail Transfer Protocol + + + + 4.2.1. REPLY CODES BY FUNCTION GROUPS + + 500 Syntax error, command unrecognized + [This may include errors such as command line too long] + 501 Syntax error in parameters or arguments + 502 Command not implemented + 503 Bad sequence of commands + 504 Command parameter not implemented + + 211 System status, or system help reply + 214 Help message + [Information on how to use the receiver or the meaning of a + particular non-standard command; this reply is useful only + to the human user] + + 220 Service ready + 221 Service closing transmission channel + 421 Service not available, + closing transmission channel + [This may be a reply to any command if the service knows it + must shut down] + + 250 Requested mail action okay, completed + 251 User not local; will forward to + 450 Requested mail action not taken: mailbox unavailable + [E.g., mailbox busy] + 550 Requested action not taken: mailbox unavailable + [E.g., mailbox not found, no access] + 451 Requested action aborted: error in processing + 551 User not local; please try + 452 Requested action not taken: insufficient system storage + 552 Requested mail action aborted: exceeded storage allocation + 553 Requested action not taken: mailbox name not allowed + [E.g., mailbox syntax incorrect] + 354 Start mail input; end with . + 554 Transaction failed + + + + + + + + + + + + + +Postel [Page 35] + + + +August 1982 RFC 821 +Simple Mail Transfer Protocol + + + + 4.2.2. NUMERIC ORDER LIST OF REPLY CODES + + 211 System status, or system help reply + 214 Help message + [Information on how to use the receiver or the meaning of a + particular non-standard command; this reply is useful only + to the human user] + 220 Service ready + 221 Service closing transmission channel + 250 Requested mail action okay, completed + 251 User not local; will forward to + + 354 Start mail input; end with . + + 421 Service not available, + closing transmission channel + [This may be a reply to any command if the service knows it + must shut down] + 450 Requested mail action not taken: mailbox unavailable + [E.g., mailbox busy] + 451 Requested action aborted: local error in processing + 452 Requested action not taken: insufficient system storage + + 500 Syntax error, command unrecognized + [This may include errors such as command line too long] + 501 Syntax error in parameters or arguments + 502 Command not implemented + 503 Bad sequence of commands + 504 Command parameter not implemented + 550 Requested action not taken: mailbox unavailable + [E.g., mailbox not found, no access] + 551 User not local; please try + 552 Requested mail action aborted: exceeded storage allocation + 553 Requested action not taken: mailbox name not allowed + [E.g., mailbox syntax incorrect] + 554 Transaction failed + + + + + + + + + + + + + +[Page 36] Postel + + + +RFC 821 August 1982 + Simple Mail Transfer Protocol + + + + 4.3. SEQUENCING OF COMMANDS AND REPLIES + + The communication between the sender and receiver is intended to + be an alternating dialogue, controlled by the sender. As such, + the sender issues a command and the receiver responds with a + reply. The sender must wait for this response before sending + further commands. + + One important reply is the connection greeting. Normally, a + receiver will send a 220 "Service ready" reply when the connection + is completed. The sender should wait for this greeting message + before sending any commands. + + Note: all the greeting type replies have the official name of + the server host as the first word following the reply code. + + For example, + + 220 USC-ISIF.ARPA Service ready + + The table below lists alternative success and failure replies for + each command. These must be strictly adhered to; a receiver may + substitute text in the replies, but the meaning and action implied + by the code numbers and by the specific command reply sequence + cannot be altered. + + COMMAND-REPLY SEQUENCES + + Each command is listed with its possible replies. The prefixes + used before the possible replies are "P" for preliminary (not + used in SMTP), "I" for intermediate, "S" for success, "F" for + failure, and "E" for error. The 421 reply (service not + available, closing transmission channel) may be given to any + command if the SMTP-receiver knows it must shut down. This + listing forms the basis for the State Diagrams in Section 4.4. + + CONNECTION ESTABLISHMENT + S: 220 + F: 421 + HELO + S: 250 + E: 500, 501, 504, 421 + MAIL + S: 250 + F: 552, 451, 452 + E: 500, 501, 421 + + + +Postel [Page 37] + + + +August 1982 RFC 821 +Simple Mail Transfer Protocol + + + + RCPT + S: 250, 251 + F: 550, 551, 552, 553, 450, 451, 452 + E: 500, 501, 503, 421 + DATA + I: 354 -> data -> S: 250 + F: 552, 554, 451, 452 + F: 451, 554 + E: 500, 501, 503, 421 + RSET + S: 250 + E: 500, 501, 504, 421 + SEND + S: 250 + F: 552, 451, 452 + E: 500, 501, 502, 421 + SOML + S: 250 + F: 552, 451, 452 + E: 500, 501, 502, 421 + SAML + S: 250 + F: 552, 451, 452 + E: 500, 501, 502, 421 + VRFY + S: 250, 251 + F: 550, 551, 553 + E: 500, 501, 502, 504, 421 + EXPN + S: 250 + F: 550 + E: 500, 501, 502, 504, 421 + HELP + S: 211, 214 + E: 500, 501, 502, 504, 421 + NOOP + S: 250 + E: 500, 421 + QUIT + S: 221 + E: 500 + TURN + S: 250 + F: 502 + E: 500, 503 + + + + +[Page 38] Postel + + + +RFC 821 August 1982 + Simple Mail Transfer Protocol + + + + 4.4. STATE DIAGRAMS + + Following are state diagrams for a simple-minded SMTP + implementation. Only the first digit of the reply codes is used. + There is one state diagram for each group of SMTP commands. The + command groupings were determined by constructing a model for each + command and then collecting together the commands with + structurally identical models. + + For each command there are three possible outcomes: "success" + (S), "failure" (F), and "error" (E). In the state diagrams below + we use the symbol B for "begin", and the symbol W for "wait for + reply". + + First, the diagram that represents most of the SMTP commands: + + + 1,3 +---+ + ----------->| E | + | +---+ + | + +---+ cmd +---+ 2 +---+ + | B |---------->| W |---------->| S | + +---+ +---+ +---+ + | + | 4,5 +---+ + ----------->| F | + +---+ + + + This diagram models the commands: + + HELO, MAIL, RCPT, RSET, SEND, SOML, SAML, VRFY, EXPN, HELP, + NOOP, QUIT, TURN. + + + + + + + + + + + + + + + +Postel [Page 39] + + + +August 1982 RFC 821 +Simple Mail Transfer Protocol + + + + A more complex diagram models the DATA command: + + + +---+ DATA +---+ 1,2 +---+ + | B |---------->| W |-------------------->| E | + +---+ +---+ ------------>+---+ + 3| |4,5 | + | | | + -------------- ----- | + | | | +---+ + | ---------- -------->| S | + | | | | +---+ + | | ------------ + | | | | + V 1,3| |2 | + +---+ data +---+ --------------->+---+ + | |---------->| W | | F | + +---+ +---+-------------------->+---+ + 4,5 + + + Note that the "data" here is a series of lines sent from the + sender to the receiver with no response expected until the last + line is sent. + + + + + + + + + + + + + + + + + + + + + + + + + +[Page 40] Postel + + + +RFC 821 August 1982 + Simple Mail Transfer Protocol + + + + 4.5. DETAILS + + 4.5.1. MINIMUM IMPLEMENTATION + + In order to make SMTP workable, the following minimum + implementation is required for all receivers: + + COMMANDS -- HELO + MAIL + RCPT + DATA + RSET + NOOP + QUIT + + 4.5.2. TRANSPARENCY + + Without some provision for data transparency the character + sequence "." ends the mail text and cannot be sent + by the user. In general, users are not aware of such + "forbidden" sequences. To allow all user composed text to be + transmitted transparently the following procedures are used. + + 1. Before sending a line of mail text the sender-SMTP checks + the first character of the line. If it is a period, one + additional period is inserted at the beginning of the line. + + 2. When a line of mail text is received by the receiver-SMTP + it checks the line. If the line is composed of a single + period it is the end of mail. If the first character is a + period and there are other characters on the line, the first + character is deleted. + + The mail data may contain any of the 128 ASCII characters. All + characters are to be delivered to the recipient's mailbox + including format effectors and other control characters. If + the transmission channel provides an 8-bit byte (octets) data + stream, the 7-bit ASCII codes are transmitted right justified + in the octets with the high order bits cleared to zero. + + In some systems it may be necessary to transform the data as + it is received and stored. This may be necessary for hosts + that use a different character set than ASCII as their local + character set, or that store data in records rather than + + + + + +Postel [Page 41] + + + +August 1982 RFC 821 +Simple Mail Transfer Protocol + + + + strings. If such transforms are necessary, they must be + reversible -- especially if such transforms are applied to + mail being relayed. + + 4.5.3. SIZES + + There are several objects that have required minimum maximum + sizes. That is, every implementation must be able to receive + objects of at least these sizes, but must not send objects + larger than these sizes. + + + **************************************************** + * * + * TO THE MAXIMUM EXTENT POSSIBLE, IMPLEMENTATION * + * TECHNIQUES WHICH IMPOSE NO LIMITS ON THE LENGTH * + * OF THESE OBJECTS SHOULD BE USED. * + * * + **************************************************** + + user + + The maximum total length of a user name is 64 characters. + + domain + + The maximum total length of a domain name or number is 64 + characters. + + path + + The maximum total length of a reverse-path or + forward-path is 256 characters (including the punctuation + and element separators). + + command line + + The maximum total length of a command line including the + command word and the is 512 characters. + + reply line + + The maximum total length of a reply line including the + reply code and the is 512 characters. + + + + + +[Page 42] Postel + + + +RFC 821 August 1982 + Simple Mail Transfer Protocol + + + + text line + + The maximum total length of a text line including the + is 1000 characters (but not counting the leading + dot duplicated for transparency). + + recipients buffer + + The maximum total number of recipients that must be + buffered is 100 recipients. + + + **************************************************** + * * + * TO THE MAXIMUM EXTENT POSSIBLE, IMPLEMENTATION * + * TECHNIQUES WHICH IMPOSE NO LIMITS ON THE LENGTH * + * OF THESE OBJECTS SHOULD BE USED. * + * * + **************************************************** + + Errors due to exceeding these limits may be reported by using + the reply codes, for example: + + 500 Line too long. + + 501 Path too long + + 552 Too many recipients. + + 552 Too much mail data. + + + + + + + + + + + + + + + + + + + +Postel [Page 43] + + + +August 1982 RFC 821 +Simple Mail Transfer Protocol + + + +APPENDIX A + + TCP Transport service + + The Transmission Control Protocol [3] is used in the ARPA + Internet, and in any network following the US DoD standards for + internetwork protocols. + + Connection Establishment + + The SMTP transmission channel is a TCP connection established + between the sender process port U and the receiver process port + L. This single full duplex connection is used as the + transmission channel. This protocol is assigned the service + port 25 (31 octal), that is L=25. + + Data Transfer + + The TCP connection supports the transmission of 8-bit bytes. + The SMTP data is 7-bit ASCII characters. Each character is + transmitted as an 8-bit byte with the high-order bit cleared to + zero. + + + + + + + + + + + + + + + + + + + + + + + + + + + +[Page 44] Postel + + + +RFC 821 August 1982 + Simple Mail Transfer Protocol + + + +APPENDIX B + + NCP Transport service + + The ARPANET Host-to-Host Protocol [4] (implemented by the Network + Control Program) may be used in the ARPANET. + + Connection Establishment + + The SMTP transmission channel is established via NCP between + the sender process socket U and receiver process socket L. The + Initial Connection Protocol [5] is followed resulting in a pair + of simplex connections. This pair of connections is used as + the transmission channel. This protocol is assigned the + contact socket 25 (31 octal), that is L=25. + + Data Transfer + + The NCP data connections are established in 8-bit byte mode. + The SMTP data is 7-bit ASCII characters. Each character is + transmitted as an 8-bit byte with the high-order bit cleared to + zero. + + + + + + + + + + + + + + + + + + + + + + + + + + + +Postel [Page 45] + + + +August 1982 RFC 821 +Simple Mail Transfer Protocol + + + +APPENDIX C + + NITS + + The Network Independent Transport Service [6] may be used. + + Connection Establishment + + The SMTP transmission channel is established via NITS between + the sender process and receiver process. The sender process + executes the CONNECT primitive, and the waiting receiver + process executes the ACCEPT primitive. + + Data Transfer + + The NITS connection supports the transmission of 8-bit bytes. + The SMTP data is 7-bit ASCII characters. Each character is + transmitted as an 8-bit byte with the high-order bit cleared to + zero. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +[Page 46] Postel + + + +RFC 821 August 1982 + Simple Mail Transfer Protocol + + + +APPENDIX D + + X.25 Transport service + + It may be possible to use the X.25 service [7] as provided by the + Public Data Networks directly, however, it is suggested that a + reliable end-to-end protocol such as TCP be used on top of X.25 + connections. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Postel [Page 47] + + + +August 1982 RFC 821 +Simple Mail Transfer Protocol + + + +APPENDIX E + + Theory of Reply Codes + + The three digits of the reply each have a special significance. + The first digit denotes whether the response is good, bad or + incomplete. An unsophisticated sender-SMTP will be able to + determine its next action (proceed as planned, redo, retrench, + etc.) by simply examining this first digit. A sender-SMTP that + wants to know approximately what kind of error occurred (e.g., + mail system error, command syntax error) may examine the second + digit, reserving the third digit for the finest gradation of + information. + + There are five values for the first digit of the reply code: + + 1yz Positive Preliminary reply + + The command has been accepted, but the requested action + is being held in abeyance, pending confirmation of the + information in this reply. The sender-SMTP should send + another command specifying whether to continue or abort + the action. + + [Note: SMTP does not have any commands that allow this + type of reply, and so does not have the continue or + abort commands.] + + 2yz Positive Completion reply + + The requested action has been successfully completed. A + new request may be initiated. + + 3yz Positive Intermediate reply + + The command has been accepted, but the requested action + is being held in abeyance, pending receipt of further + information. The sender-SMTP should send another command + specifying this information. This reply is used in + command sequence groups. + + 4yz Transient Negative Completion reply + + The command was not accepted and the requested action did + not occur. However, the error condition is temporary and + the action may be requested again. The sender should + + + +[Page 48] Postel + + + +RFC 821 August 1982 + Simple Mail Transfer Protocol + + + + return to the beginning of the command sequence (if any). + It is difficult to assign a meaning to "transient" when + two different sites (receiver- and sender- SMTPs) must + agree on the interpretation. Each reply in this category + might have a different time value, but the sender-SMTP is + encouraged to try again. A rule of thumb to determine if + a reply fits into the 4yz or the 5yz category (see below) + is that replies are 4yz if they can be repeated without + any change in command form or in properties of the sender + or receiver. (E.g., the command is repeated identically + and the receiver does not put up a new implementation.) + + 5yz Permanent Negative Completion reply + + The command was not accepted and the requested action did + not occur. The sender-SMTP is discouraged from repeating + the exact request (in the same sequence). Even some + "permanent" error conditions can be corrected, so the + human user may want to direct the sender-SMTP to + reinitiate the command sequence by direct action at some + point in the future (e.g., after the spelling has been + changed, or the user has altered the account status). + + The second digit encodes responses in specific categories: + + x0z Syntax -- These replies refer to syntax errors, + syntactically correct commands that don't fit any + functional category, and unimplemented or superfluous + commands. + + x1z Information -- These are replies to requests for + information, such as status or help. + + x2z Connections -- These are replies referring to the + transmission channel. + + x3z Unspecified as yet. + + x4z Unspecified as yet. + + x5z Mail system -- These replies indicate the status of + the receiver mail system vis-a-vis the requested + transfer or other mail system action. + + The third digit gives a finer gradation of meaning in each + category specified by the second digit. The list of replies + + + +Postel [Page 49] + + + +August 1982 RFC 821 +Simple Mail Transfer Protocol + + + + illustrates this. Each reply text is recommended rather than + mandatory, and may even change according to the command with + which it is associated. On the other hand, the reply codes + must strictly follow the specifications in this section. + Receiver implementations should not invent new codes for + slightly different situations from the ones described here, but + rather adapt codes already defined. + + For example, a command such as NOOP whose successful execution + does not offer the sender-SMTP any new information will return + a 250 reply. The response is 502 when the command requests an + unimplemented non-site-specific action. A refinement of that + is the 504 reply for a command that is implemented, but that + requests an unimplemented parameter. + + The reply text may be longer than a single line; in these cases + the complete text must be marked so the sender-SMTP knows when it + can stop reading the reply. This requires a special format to + indicate a multiple line reply. + + The format for multiline replies requires that every line, + except the last, begin with the reply code, followed + immediately by a hyphen, "-" (also known as minus), followed by + text. The last line will begin with the reply code, followed + immediately by , optionally some text, and . + + For example: + 123-First line + 123-Second line + 123-234 text beginning with numbers + 123 The last line + + In many cases the sender-SMTP then simply needs to search for + the reply code followed by at the beginning of a line, and + ignore all preceding lines. In a few cases, there is important + data for the sender in the reply "text". The sender will know + these cases from the current context. + + + + + + + + + + + + +[Page 50] Postel + + + +RFC 821 August 1982 + Simple Mail Transfer Protocol + + + +APPENDIX F + + Scenarios + + This section presents complete scenarios of several types of SMTP + sessions. + + A Typical SMTP Transaction Scenario + + This SMTP example shows mail sent by Smith at host USC-ISIF, to + Jones, Green, and Brown at host BBN-UNIX. Here we assume that + host USC-ISIF contacts host BBN-UNIX directly. The mail is + accepted for Jones and Brown. Green does not have a mailbox at + host BBN-UNIX. + + ------------------------------------------------------------- + + R: 220 BBN-UNIX.ARPA Simple Mail Transfer Service Ready + S: HELO USC-ISIF.ARPA + R: 250 BBN-UNIX.ARPA + + S: MAIL FROM: + R: 250 OK + + S: RCPT TO: + R: 250 OK + + S: RCPT TO: + R: 550 No such user here + + S: RCPT TO: + R: 250 OK + + S: DATA + R: 354 Start mail input; end with . + S: Blah blah blah... + S: ...etc. etc. etc. + S: . + R: 250 OK + + S: QUIT + R: 221 BBN-UNIX.ARPA Service closing transmission channel + + Scenario 1 + + ------------------------------------------------------------- + + + +Postel [Page 51] + + + +August 1982 RFC 821 +Simple Mail Transfer Protocol + + + + Aborted SMTP Transaction Scenario + + ------------------------------------------------------------- + + R: 220 MIT-Multics.ARPA Simple Mail Transfer Service Ready + S: HELO ISI-VAXA.ARPA + R: 250 MIT-Multics.ARPA + + S: MAIL FROM: + R: 250 OK + + S: RCPT TO: + R: 250 OK + + S: RCPT TO: + R: 550 No such user here + + S: RSET + R: 250 OK + + S: QUIT + R: 221 MIT-Multics.ARPA Service closing transmission channel + + Scenario 2 + + ------------------------------------------------------------- + + + + + + + + + + + + + + + + + + + + + + + +[Page 52] Postel + + + +RFC 821 August 1982 + Simple Mail Transfer Protocol + + + + Relayed Mail Scenario + + ------------------------------------------------------------- + + Step 1 -- Source Host to Relay Host + + R: 220 USC-ISIE.ARPA Simple Mail Transfer Service Ready + S: HELO MIT-AI.ARPA + R: 250 USC-ISIE.ARPA + + S: MAIL FROM: + R: 250 OK + + S: RCPT TO:<@USC-ISIE.ARPA:Jones@BBN-VAX.ARPA> + R: 250 OK + + S: DATA + R: 354 Start mail input; end with . + S: Date: 2 Nov 81 22:33:44 + S: From: John Q. Public + S: Subject: The Next Meeting of the Board + S: To: Jones@BBN-Vax.ARPA + S: + S: Bill: + S: The next meeting of the board of directors will be + S: on Tuesday. + S: John. + S: . + R: 250 OK + + S: QUIT + R: 221 USC-ISIE.ARPA Service closing transmission channel + + + + + + + + + + + + + + + + + +Postel [Page 53] + + + +August 1982 RFC 821 +Simple Mail Transfer Protocol + + + + Step 2 -- Relay Host to Destination Host + + R: 220 BBN-VAX.ARPA Simple Mail Transfer Service Ready + S: HELO USC-ISIE.ARPA + R: 250 BBN-VAX.ARPA + + S: MAIL FROM:<@USC-ISIE.ARPA:JQP@MIT-AI.ARPA> + R: 250 OK + + S: RCPT TO: + R: 250 OK + + S: DATA + R: 354 Start mail input; end with . + S: Received: from MIT-AI.ARPA by USC-ISIE.ARPA ; + 2 Nov 81 22:40:10 UT + S: Date: 2 Nov 81 22:33:44 + S: From: John Q. Public + S: Subject: The Next Meeting of the Board + S: To: Jones@BBN-Vax.ARPA + S: + S: Bill: + S: The next meeting of the board of directors will be + S: on Tuesday. + S: John. + S: . + R: 250 OK + + S: QUIT + R: 221 USC-ISIE.ARPA Service closing transmission channel + + Scenario 3 + + ------------------------------------------------------------- + + + + + + + + + + + + + + + +[Page 54] Postel + + + +RFC 821 August 1982 + Simple Mail Transfer Protocol + + + + Verifying and Sending Scenario + + ------------------------------------------------------------- + + R: 220 SU-SCORE.ARPA Simple Mail Transfer Service Ready + S: HELO MIT-MC.ARPA + R: 250 SU-SCORE.ARPA + + S: VRFY Crispin + R: 250 Mark Crispin + + S: SEND FROM: + R: 250 OK + + S: RCPT TO: + R: 250 OK + + S: DATA + R: 354 Start mail input; end with . + S: Blah blah blah... + S: ...etc. etc. etc. + S: . + R: 250 OK + + S: QUIT + R: 221 SU-SCORE.ARPA Service closing transmission channel + + Scenario 4 + + ------------------------------------------------------------- + + + + + + + + + + + + + + + + + + + +Postel [Page 55] + + + +August 1982 RFC 821 +Simple Mail Transfer Protocol + + + + Sending and Mailing Scenarios + + First the user's name is verified, then an attempt is made to + send to the user's terminal. When that fails, the messages is + mailed to the user's mailbox. + + ------------------------------------------------------------- + + R: 220 SU-SCORE.ARPA Simple Mail Transfer Service Ready + S: HELO MIT-MC.ARPA + R: 250 SU-SCORE.ARPA + + S: VRFY Crispin + R: 250 Mark Crispin + + S: SEND FROM: + R: 250 OK + + S: RCPT TO: + R: 450 User not active now + + S: RSET + R: 250 OK + + S: MAIL FROM: + R: 250 OK + + S: RCPT TO: + R: 250 OK + + S: DATA + R: 354 Start mail input; end with . + S: Blah blah blah... + S: ...etc. etc. etc. + S: . + R: 250 OK + + S: QUIT + R: 221 SU-SCORE.ARPA Service closing transmission channel + + Scenario 5 + + ------------------------------------------------------------- + + + + + + +[Page 56] Postel + + + +RFC 821 August 1982 + Simple Mail Transfer Protocol + + + + Doing the preceding scenario more efficiently. + + ------------------------------------------------------------- + + R: 220 SU-SCORE.ARPA Simple Mail Transfer Service Ready + S: HELO MIT-MC.ARPA + R: 250 SU-SCORE.ARPA + + S: VRFY Crispin + R: 250 Mark Crispin + + S: SOML FROM: + R: 250 OK + + S: RCPT TO: + R: 250 User not active now, so will do mail. + + S: DATA + R: 354 Start mail input; end with . + S: Blah blah blah... + S: ...etc. etc. etc. + S: . + R: 250 OK + + S: QUIT + R: 221 SU-SCORE.ARPA Service closing transmission channel + + Scenario 6 + + ------------------------------------------------------------- + + + + + + + + + + + + + + + + + + + +Postel [Page 57] + + + +August 1982 RFC 821 +Simple Mail Transfer Protocol + + + + Mailing List Scenario + + First each of two mailing lists are expanded in separate sessions + with different hosts. Then the message is sent to everyone that + appeared on either list (but no duplicates) via a relay host. + + ------------------------------------------------------------- + + Step 1 -- Expanding the First List + + R: 220 MIT-AI.ARPA Simple Mail Transfer Service Ready + S: HELO SU-SCORE.ARPA + R: 250 MIT-AI.ARPA + + S: EXPN Example-People + R: 250- + R: 250-Fred Fonebone + R: 250-Xenon Y. Zither + R: 250-Quincy Smith <@USC-ISIF.ARPA:Q-Smith@ISI-VAXA.ARPA> + R: 250- + R: 250 + + S: QUIT + R: 221 MIT-AI.ARPA Service closing transmission channel + + + + + + + + + + + + + + + + + + + + + + + + + +[Page 58] Postel + + + +RFC 821 August 1982 + Simple Mail Transfer Protocol + + + + Step 2 -- Expanding the Second List + + R: 220 MIT-MC.ARPA Simple Mail Transfer Service Ready + S: HELO SU-SCORE.ARPA + R: 250 MIT-MC.ARPA + + S: EXPN Interested-Parties + R: 250-Al Calico + R: 250- + R: 250-Quincy Smith <@USC-ISIF.ARPA:Q-Smith@ISI-VAXA.ARPA> + R: 250- + R: 250 + + S: QUIT + R: 221 MIT-MC.ARPA Service closing transmission channel + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Postel [Page 59] + + + +August 1982 RFC 821 +Simple Mail Transfer Protocol + + + + Step 3 -- Mailing to All via a Relay Host + + R: 220 USC-ISIE.ARPA Simple Mail Transfer Service Ready + S: HELO SU-SCORE.ARPA + R: 250 USC-ISIE.ARPA + + S: MAIL FROM: + R: 250 OK + S: RCPT TO:<@USC-ISIE.ARPA:ABC@MIT-MC.ARPA> + R: 250 OK + S: RCPT TO:<@USC-ISIE.ARPA:Fonebone@USC-ISIQA.ARPA> + R: 250 OK + S: RCPT TO:<@USC-ISIE.ARPA:XYZ@MIT-AI.ARPA> + R: 250 OK + S: RCPT + TO:<@USC-ISIE.ARPA,@USC-ISIF.ARPA:Q-Smith@ISI-VAXA.ARPA> + R: 250 OK + S: RCPT TO:<@USC-ISIE.ARPA:joe@FOO-UNIX.ARPA> + R: 250 OK + S: RCPT TO:<@USC-ISIE.ARPA:xyz@BAR-UNIX.ARPA> + R: 250 OK + S: RCPT TO:<@USC-ISIE.ARPA:fred@BBN-UNIX.ARPA> + R: 250 OK + + S: DATA + R: 354 Start mail input; end with . + S: Blah blah blah... + S: ...etc. etc. etc. + S: . + R: 250 OK + + S: QUIT + R: 221 USC-ISIE.ARPA Service closing transmission channel + + Scenario 7 + + ------------------------------------------------------------- + + + + + + + + + + + + +[Page 60] Postel + + + +RFC 821 August 1982 + Simple Mail Transfer Protocol + + + + Forwarding Scenarios + + ------------------------------------------------------------- + + R: 220 USC-ISIF.ARPA Simple Mail Transfer Service Ready + S: HELO LBL-UNIX.ARPA + R: 250 USC-ISIF.ARPA + + S: MAIL FROM: + R: 250 OK + + S: RCPT TO: + R: 251 User not local; will forward to + + S: DATA + R: 354 Start mail input; end with . + S: Blah blah blah... + S: ...etc. etc. etc. + S: . + R: 250 OK + + S: QUIT + R: 221 USC-ISIF.ARPA Service closing transmission channel + + Scenario 8 + + ------------------------------------------------------------- + + + + + + + + + + + + + + + + + + + + + + +Postel [Page 61] + + + +August 1982 RFC 821 +Simple Mail Transfer Protocol + + + + ------------------------------------------------------------- + + Step 1 -- Trying the Mailbox at the First Host + + R: 220 USC-ISIF.ARPA Simple Mail Transfer Service Ready + S: HELO LBL-UNIX.ARPA + R: 250 USC-ISIF.ARPA + + S: MAIL FROM: + R: 250 OK + + S: RCPT TO: + R: 251 User not local; will forward to + + S: RSET + R: 250 OK + + S: QUIT + R: 221 USC-ISIF.ARPA Service closing transmission channel + + Step 2 -- Delivering the Mail at the Second Host + + R: 220 USC-ISI.ARPA Simple Mail Transfer Service Ready + S: HELO LBL-UNIX.ARPA + R: 250 USC-ISI.ARPA + + S: MAIL FROM: + R: 250 OK + + S: RCPT TO: + R: OK + + S: DATA + R: 354 Start mail input; end with . + S: Blah blah blah... + S: ...etc. etc. etc. + S: . + R: 250 OK + + S: QUIT + R: 221 USC-ISI.ARPA Service closing transmission channel + + Scenario 9 + + ------------------------------------------------------------- + + + + +[Page 62] Postel + + + +RFC 821 August 1982 + Simple Mail Transfer Protocol + + + + Too Many Recipients Scenario + + ------------------------------------------------------------- + + R: 220 BERKELEY.ARPA Simple Mail Transfer Service Ready + S: HELO USC-ISIF.ARPA + R: 250 BERKELEY.ARPA + + S: MAIL FROM: + R: 250 OK + + S: RCPT TO: + R: 250 OK + + S: RCPT TO: + R: 552 Recipient storage full, try again in another transaction + + S: DATA + R: 354 Start mail input; end with . + S: Blah blah blah... + S: ...etc. etc. etc. + S: . + R: 250 OK + + S: MAIL FROM: + R: 250 OK + + S: RCPT TO: + R: 250 OK + + S: DATA + R: 354 Start mail input; end with . + S: Blah blah blah... + S: ...etc. etc. etc. + S: . + R: 250 OK + + S: QUIT + R: 221 BERKELEY.ARPA Service closing transmission channel + + Scenario 10 + + ------------------------------------------------------------- + + Note that a real implementation must handle many recipients as + specified in Section 4.5.3. + + + +Postel [Page 63] + + + +August 1982 RFC 821 +Simple Mail Transfer Protocol + + + +GLOSSARY + + ASCII + + American Standard Code for Information Interchange [1]. + + command + + A request for a mail service action sent by the sender-SMTP to the + receiver-SMTP. + + domain + + The hierarchially structured global character string address of a + host computer in the mail system. + + end of mail data indication + + A special sequence of characters that indicates the end of the + mail data. In particular, the five characters carriage return, + line feed, period, carriage return, line feed, in that order. + + host + + A computer in the internetwork environment on which mailboxes or + SMTP processes reside. + + line + + A a sequence of ASCII characters ending with a . + + mail data + + A sequence of ASCII characters of arbitrary length, which conforms + to the standard set in the Standard for the Format of ARPA + Internet Text Messages (RFC 822 [2]). + + mailbox + + A character string (address) which identifies a user to whom mail + is to be sent. Mailbox normally consists of the host and user + specifications. The standard mailbox naming convention is defined + to be "user@domain". Additionally, the "container" in which mail + is stored. + + + + + +[Page 64] Postel + + + +RFC 821 August 1982 + Simple Mail Transfer Protocol + + + + receiver-SMTP process + + A process which transfers mail in cooperation with a sender-SMTP + process. It waits for a connection to be established via the + transport service. It receives SMTP commands from the + sender-SMTP, sends replies, and performs the specified operations. + + reply + + A reply is an acknowledgment (positive or negative) sent from + receiver to sender via the transmission channel in response to a + command. The general form of a reply is a completion code + (including error codes) followed by a text string. The codes are + for use by programs and the text is usually intended for human + users. + + sender-SMTP process + + A process which transfers mail in cooperation with a receiver-SMTP + process. A local language may be used in the user interface + command/reply dialogue. The sender-SMTP initiates the transport + service connection. It initiates SMTP commands, receives replies, + and governs the transfer of mail. + + session + + The set of exchanges that occur while the transmission channel is + open. + + transaction + + The set of exchanges required for one message to be transmitted + for one or more recipients. + + transmission channel + + A full-duplex communication path between a sender-SMTP and a + receiver-SMTP for the exchange of commands, replies, and mail + text. + + transport service + + Any reliable stream-oriented data communication services. For + example, NCP, TCP, NITS. + + + + + +Postel [Page 65] + + + +August 1982 RFC 821 +Simple Mail Transfer Protocol + + + + user + + A human being (or a process on behalf of a human being) wishing to + obtain mail transfer service. In addition, a recipient of + computer mail. + + word + + A sequence of printing characters. + + + + The characters carriage return and line feed (in that order). + + + + The space character. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +[Page 66] Postel + + + +RFC 821 August 1982 + Simple Mail Transfer Protocol + + + +REFERENCES + + [1] ASCII + + ASCII, "USA Code for Information Interchange", United States of + America Standards Institute, X3.4, 1968. Also in: Feinler, E. + and J. Postel, eds., "ARPANET Protocol Handbook", NIC 7104, for + the Defense Communications Agency by SRI International, Menlo + Park, California, Revised January 1978. + + [2] RFC 822 + + Crocker, D., "Standard for the Format of ARPA Internet Text + Messages," RFC 822, Department of Electrical Engineering, + University of Delaware, August 1982. + + [3] TCP + + Postel, J., ed., "Transmission Control Protocol - DARPA Internet + Program Protocol Specification", RFC 793, USC/Information Sciences + Institute, NTIS AD Number A111091, September 1981. Also in: + Feinler, E. and J. Postel, eds., "Internet Protocol Transition + Workbook", SRI International, Menlo Park, California, March 1982. + + [4] NCP + + McKenzie,A., "Host/Host Protocol for the ARPA Network", NIC 8246, + January 1972. Also in: Feinler, E. and J. Postel, eds., "ARPANET + Protocol Handbook", NIC 7104, for the Defense Communications + Agency by SRI International, Menlo Park, California, Revised + January 1978. + + [5] Initial Connection Protocol + + Postel, J., "Official Initial Connection Protocol", NIC 7101, + 11 June 1971. Also in: Feinler, E. and J. Postel, eds., "ARPANET + Protocol Handbook", NIC 7104, for the Defense Communications + Agency by SRI International, Menlo Park, California, Revised + January 1978. + + [6] NITS + + PSS/SG3, "A Network Independent Transport Service", Study Group 3, + The Post Office PSS Users Group, February 1980. Available from + the DCPU, National Physical Laboratory, Teddington, UK. + + + + +Postel [Page 67] + + + +August 1982 RFC 821 +Simple Mail Transfer Protocol + + + + [7] X.25 + + CCITT, "Recommendation X.25 - Interface Between Data Terminal + Equipment (DTE) and Data Circuit-terminating Equipment (DCE) for + Terminals Operating in the Packet Mode on Public Data Networks," + CCITT Orange Book, Vol. VIII.2, International Telephone and + Telegraph Consultative Committee, Geneva, 1976. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +[Page 68] Postel + diff --git a/RFCs/rfc822.txt b/RFCs/rfc822.txt new file mode 100644 index 0000000..35b09a3 --- /dev/null +++ b/RFCs/rfc822.txt @@ -0,0 +1,2901 @@ + + + + + + + RFC # 822 + + Obsoletes: RFC #733 (NIC #41952) + + + + + + + + + + + + + STANDARD FOR THE FORMAT OF + + ARPA INTERNET TEXT MESSAGES + + + + + + + August 13, 1982 + + + + + + + Revised by + + David H. Crocker + + + Dept. of Electrical Engineering + University of Delaware, Newark, DE 19711 + Network: DCrocker @ UDel-Relay + + + + + + + + + + + + + + + + Standard for ARPA Internet Text Messages + + + TABLE OF CONTENTS + + + PREFACE .................................................... ii + + 1. INTRODUCTION ........................................... 1 + + 1.1. Scope ............................................ 1 + 1.2. Communication Framework .......................... 2 + + 2. NOTATIONAL CONVENTIONS ................................. 3 + + 3. LEXICAL ANALYSIS OF MESSAGES ........................... 5 + + 3.1. General Description .............................. 5 + 3.2. Header Field Definitions ......................... 9 + 3.3. Lexical Tokens ................................... 10 + 3.4. Clarifications ................................... 11 + + 4. MESSAGE SPECIFICATION .................................. 17 + + 4.1. Syntax ........................................... 17 + 4.2. Forwarding ....................................... 19 + 4.3. Trace Fields ..................................... 20 + 4.4. Originator Fields ................................ 21 + 4.5. Receiver Fields .................................. 23 + 4.6. Reference Fields ................................. 23 + 4.7. Other Fields ..................................... 24 + + 5. DATE AND TIME SPECIFICATION ............................ 26 + + 5.1. Syntax ........................................... 26 + 5.2. Semantics ........................................ 26 + + 6. ADDRESS SPECIFICATION .................................. 27 + + 6.1. Syntax ........................................... 27 + 6.2. Semantics ........................................ 27 + 6.3. Reserved Address ................................. 33 + + 7. BIBLIOGRAPHY ........................................... 34 + + + APPENDIX + + A. EXAMPLES ............................................... 36 + B. SIMPLE FIELD PARSING ................................... 40 + C. DIFFERENCES FROM RFC #733 .............................. 41 + D. ALPHABETICAL LISTING OF SYNTAX RULES ................... 44 + + + August 13, 1982 - i - RFC #822 + + + + + Standard for ARPA Internet Text Messages + + + PREFACE + + + By 1977, the Arpanet employed several informal standards for + the text messages (mail) sent among its host computers. It was + felt necessary to codify these practices and provide for those + features that seemed imminent. The result of that effort was + Request for Comments (RFC) #733, "Standard for the Format of ARPA + Network Text Message", by Crocker, Vittal, Pogran, and Henderson. + The specification attempted to avoid major changes in existing + software, while permitting several new features. + + This document revises the specifications in RFC #733, in + order to serve the needs of the larger and more complex ARPA + Internet. Some of RFC #733's features failed to gain adequate + acceptance. In order to simplify the standard and the software + that follows it, these features have been removed. A different + addressing scheme is used, to handle the case of inter-network + mail; and the concept of re-transmission has been introduced. + + This specification is intended for use in the ARPA Internet. + However, an attempt has been made to free it of any dependence on + that environment, so that it can be applied to other network text + message systems. + + The specification of RFC #733 took place over the course of + one year, using the ARPANET mail environment, itself, to provide + an on-going forum for discussing the capabilities to be included. + More than twenty individuals, from across the country, partici- + pated in the original discussion. The development of this + revised specification has, similarly, utilized network mail-based + group discussion. Both specification efforts greatly benefited + from the comments and ideas of the participants. + + The syntax of the standard, in RFC #733, was originally + specified in the Backus-Naur Form (BNF) meta-language. Ken L. + Harrenstien, of SRI International, was responsible for re-coding + the BNF into an augmented BNF that makes the representation + smaller and easier to understand. + + + + + + + + + + + + + August 13, 1982 - ii - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + 1. INTRODUCTION + + 1.1. SCOPE + + This standard specifies a syntax for text messages that are + sent among computer users, within the framework of "electronic + mail". The standard supersedes the one specified in ARPANET + Request for Comments #733, "Standard for the Format of ARPA Net- + work Text Messages". + + In this context, messages are viewed as having an envelope + and contents. The envelope contains whatever information is + needed to accomplish transmission and delivery. The contents + compose the object to be delivered to the recipient. This stan- + dard applies only to the format and some of the semantics of mes- + sage contents. It contains no specification of the information + in the envelope. + + However, some message systems may use information from the + contents to create the envelope. It is intended that this stan- + dard facilitate the acquisition of such information by programs. + + Some message systems may store messages in formats that + differ from the one specified in this standard. This specifica- + tion is intended strictly as a definition of what message content + format is to be passed BETWEEN hosts. + + Note: This standard is NOT intended to dictate the internal for- + mats used by sites, the specific message system features + that they are expected to support, or any of the charac- + teristics of user interface programs that create or read + messages. + + A distinction should be made between what the specification + REQUIRES and what it ALLOWS. Messages can be made complex and + rich with formally-structured components of information or can be + kept small and simple, with a minimum of such information. Also, + the standard simplifies the interpretation of differing visual + formats in messages; only the visual aspect of a message is + affected and not the interpretation of information within it. + Implementors may choose to retain such visual distinctions. + + The formal definition is divided into four levels. The bot- + tom level describes the meta-notation used in this document. The + second level describes basic lexical analyzers that feed tokens + to higher-level parsers. Next is an overall specification for + messages; it permits distinguishing individual fields. Finally, + there is definition of the contents of several structured fields. + + + + August 13, 1982 - 1 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + 1.2. COMMUNICATION FRAMEWORK + + Messages consist of lines of text. No special provisions + are made for encoding drawings, facsimile, speech, or structured + text. No significant consideration has been given to questions + of data compression or to transmission and storage efficiency, + and the standard tends to be free with the number of bits con- + sumed. For example, field names are specified as free text, + rather than special terse codes. + + A general "memo" framework is used. That is, a message con- + sists of some information in a rigid format, followed by the main + part of the message, with a format that is not specified in this + document. The syntax of several fields of the rigidly-formated + ("headers") section is defined in this specification; some of + these fields must be included in all messages. + + The syntax that distinguishes between header fields is + specified separately from the internal syntax for particular + fields. This separation is intended to allow simple parsers to + operate on the general structure of messages, without concern for + the detailed structure of individual header fields. Appendix B + is provided to facilitate construction of these parsers. + + In addition to the fields specified in this document, it is + expected that other fields will gain common use. As necessary, + the specifications for these "extension-fields" will be published + through the same mechanism used to publish this document. Users + may also wish to extend the set of fields that they use + privately. Such "user-defined fields" are permitted. + + The framework severely constrains document tone and appear- + ance and is primarily useful for most intra-organization communi- + cations and well-structured inter-organization communication. + It also can be used for some types of inter-process communica- + tion, such as simple file transfer and remote job entry. A more + robust framework might allow for multi-font, multi-color, multi- + dimension encoding of information. A less robust one, as is + present in most single-machine message systems, would more + severely constrain the ability to add fields and the decision to + include specific fields. In contrast with paper-based communica- + tion, it is interesting to note that the RECEIVER of a message + can exercise an extraordinary amount of control over the + message's appearance. The amount of actual control available to + message receivers is contingent upon the capabilities of their + individual message systems. + + + + + + August 13, 1982 - 2 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + 2. NOTATIONAL CONVENTIONS + + This specification uses an augmented Backus-Naur Form (BNF) + notation. The differences from standard BNF involve naming rules + and indicating repetition and "local" alternatives. + + 2.1. RULE NAMING + + Angle brackets ("<", ">") are not used, in general. The + name of a rule is simply the name itself, rather than "". + Quotation-marks enclose literal text (which may be upper and/or + lower case). Certain basic rules are in uppercase, such as + SPACE, TAB, CRLF, DIGIT, ALPHA, etc. Angle brackets are used in + rule definitions, and in the rest of this document, whenever + their presence will facilitate discerning the use of rule names. + + 2.2. RULE1 / RULE2: ALTERNATIVES + + Elements separated by slash ("/") are alternatives. There- + fore "foo / bar" will accept foo or bar. + + 2.3. (RULE1 RULE2): LOCAL ALTERNATIVES + + Elements enclosed in parentheses are treated as a single + element. Thus, "(elem (foo / bar) elem)" allows the token + sequences "elem foo elem" and "elem bar elem". + + 2.4. *RULE: REPETITION + + The character "*" preceding an element indicates repetition. + The full form is: + + *element + + indicating at least and at most occurrences of element. + Default values are 0 and infinity so that "*(element)" allows any + number, including zero; "1*element" requires at least one; and + "1*2element" allows one or two. + + 2.5. [RULE]: OPTIONAL + + Square brackets enclose optional elements; "[foo bar]" is + equivalent to "*1(foo bar)". + + 2.6. NRULE: SPECIFIC REPETITION + + "(element)" is equivalent to "*(element)"; that is, + exactly occurrences of (element). Thus 2DIGIT is a 2-digit + number, and 3ALPHA is a string of three alphabetic characters. + + + August 13, 1982 - 3 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + 2.7. #RULE: LISTS + + A construct "#" is defined, similar to "*", as follows: + + #element + + indicating at least and at most elements, each separated + by one or more commas (","). This makes the usual form of lists + very easy; a rule such as '(element *("," element))' can be shown + as "1#element". Wherever this construct is used, null elements + are allowed, but do not contribute to the count of elements + present. That is, "(element),,(element)" is permitted, but + counts as only two elements. Therefore, where at least one ele- + ment is required, at least one non-null element must be present. + Default values are 0 and infinity so that "#(element)" allows any + number, including zero; "1#element" requires at least one; and + "1#2element" allows one or two. + + 2.8. ; COMMENTS + + A semi-colon, set off some distance to the right of rule + text, starts a comment that continues to the end of line. This + is a simple way of including useful notes in parallel with the + specifications. + + + + + + + + + + + + + + + + + + + + + + + + + + + + August 13, 1982 - 4 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + 3. LEXICAL ANALYSIS OF MESSAGES + + 3.1. GENERAL DESCRIPTION + + A message consists of header fields and, optionally, a body. + The body is simply a sequence of lines containing ASCII charac- + ters. It is separated from the headers by a null line (i.e., a + line with nothing preceding the CRLF). + + 3.1.1. LONG HEADER FIELDS + + Each header field can be viewed as a single, logical line of + ASCII characters, comprising a field-name and a field-body. + For convenience, the field-body portion of this conceptual + entity can be split into a multiple-line representation; this + is called "folding". The general rule is that wherever there + may be linear-white-space (NOT simply LWSP-chars), a CRLF + immediately followed by AT LEAST one LWSP-char may instead be + inserted. Thus, the single line + + To: "Joe & J. Harvey" , JJV @ BBN + + can be represented as: + + To: "Joe & J. Harvey" , + JJV@BBN + + and + + To: "Joe & J. Harvey" + , JJV + @BBN + + and + + To: "Joe & + J. Harvey" , JJV @ BBN + + The process of moving from this folded multiple-line + representation of a header field to its single line represen- + tation is called "unfolding". Unfolding is accomplished by + regarding CRLF immediately followed by a LWSP-char as + equivalent to the LWSP-char. + + Note: While the standard permits folding wherever linear- + white-space is permitted, it is recommended that struc- + tured fields, such as those containing addresses, limit + folding to higher-level syntactic breaks. For address + fields, it is recommended that such folding occur + + + August 13, 1982 - 5 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + between addresses, after the separating comma. + + 3.1.2. STRUCTURE OF HEADER FIELDS + + Once a field has been unfolded, it may be viewed as being com- + posed of a field-name followed by a colon (":"), followed by a + field-body, and terminated by a carriage-return/line-feed. + The field-name must be composed of printable ASCII characters + (i.e., characters that have values between 33. and 126., + decimal, except colon). The field-body may be composed of any + ASCII characters, except CR or LF. (While CR and/or LF may be + present in the actual text, they are removed by the action of + unfolding the field.) + + Certain field-bodies of headers may be interpreted according + to an internal syntax that some systems may wish to parse. + These fields are called "structured fields". Examples + include fields containing dates and addresses. Other fields, + such as "Subject" and "Comments", are regarded simply as + strings of text. + + Note: Any field which has a field-body that is defined as + other than simply is to be treated as a struc- + tured field. + + Field-names, unstructured field bodies and structured + field bodies each are scanned by their own, independent + "lexical" analyzers. + + 3.1.3. UNSTRUCTURED FIELD BODIES + + For some fields, such as "Subject" and "Comments", no struc- + turing is assumed, and they are treated simply as s, as + in the message body. Rules of folding apply to these fields, + so that such field bodies which occupy several lines must + therefore have the second and successive lines indented by at + least one LWSP-char. + + 3.1.4. STRUCTURED FIELD BODIES + + To aid in the creation and reading of structured fields, the + free insertion of linear-white-space (which permits folding + by inclusion of CRLFs) is allowed between lexical tokens. + Rather than obscuring the syntax specifications for these + structured fields with explicit syntax for this linear-white- + space, the existence of another "lexical" analyzer is assumed. + This analyzer does not apply for unstructured field bodies + that are simply strings of text, as described above. The + analyzer provides an interpretation of the unfolded text + + + August 13, 1982 - 6 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + composing the body of the field as a sequence of lexical sym- + bols. + + These symbols are: + + - individual special characters + - quoted-strings + - domain-literals + - comments + - atoms + + The first four of these symbols are self-delimiting. Atoms + are not; they are delimited by the self-delimiting symbols and + by linear-white-space. For the purposes of regenerating + sequences of atoms and quoted-strings, exactly one SPACE is + assumed to exist, and should be used, between them. (Also, in + the "Clarifications" section on "White Space", below, note the + rules about treatment of multiple contiguous LWSP-chars.) + + So, for example, the folded body of an address field + + ":sysmail"@ Some-Group. Some-Org, + Muhammed.(I am the greatest) Ali @(the)Vegas.WBA + + + + + + + + + + + + + + + + + + + + + + + + + + + + + August 13, 1982 - 7 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + is analyzed into the following lexical symbols and types: + + :sysmail quoted string + @ special + Some-Group atom + . special + Some-Org atom + , special + Muhammed atom + . special + (I am the greatest) comment + Ali atom + @ atom + (the) comment + Vegas atom + . special + WBA atom + + The canonical representations for the data in these addresses + are the following strings: + + ":sysmail"@Some-Group.Some-Org + + and + + Muhammed.Ali@Vegas.WBA + + Note: For purposes of display, and when passing such struc- + tured information to other systems, such as mail proto- + col services, there must be NO linear-white-space + between s that are separated by period (".") or + at-sign ("@") and exactly one SPACE between all other + s. Also, headers should be in a folded form. + + + + + + + + + + + + + + + + + + + August 13, 1982 - 8 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + 3.2. HEADER FIELD DEFINITIONS + + These rules show a field meta-syntax, without regard for the + particular type or internal syntax. Their purpose is to permit + detection of fields; also, they present to higher-level parsers + an image of each field as fitting on one line. + + field = field-name ":" [ field-body ] CRLF + + field-name = 1* + + field-body = field-body-contents + [CRLF LWSP-char field-body] + + field-body-contents = + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + August 13, 1982 - 9 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + 3.3. LEXICAL TOKENS + + The following rules are used to define an underlying lexical + analyzer, which feeds tokens to higher level parsers. See the + ANSI references, in the Bibliography. + + ; ( Octal, Decimal.) + CHAR = ; ( 0-177, 0.-127.) + ALPHA = + ; (101-132, 65.- 90.) + ; (141-172, 97.-122.) + DIGIT = ; ( 60- 71, 48.- 57.) + CTL = ; ( 177, 127.) + CR = ; ( 15, 13.) + LF = ; ( 12, 10.) + SPACE = ; ( 40, 32.) + HTAB = ; ( 11, 9.) + <"> = ; ( 42, 34.) + CRLF = CR LF + + LWSP-char = SPACE / HTAB ; semantics = SPACE + + linear-white-space = 1*([CRLF] LWSP-char) ; semantics = SPACE + ; CRLF => folding + + specials = "(" / ")" / "<" / ">" / "@" ; Must be in quoted- + / "," / ";" / ":" / "\" / <"> ; string, to use + / "." / "[" / "]" ; within a word. + + delimiters = specials / linear-white-space / comment + + text = atoms, specials, + CR & bare LF, but NOT ; comments and + including CRLF> ; quoted-strings are + ; NOT recognized. + + atom = 1* + + quoted-string = <"> *(qtext/quoted-pair) <">; Regular qtext or + ; quoted chars. + + qtext = , ; => may be folded + "\" & CR, and including + linear-white-space> + + domain-literal = "[" *(dtext / quoted-pair) "]" + + + + + August 13, 1982 - 10 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + dtext = may be folded + "]", "\" & CR, & including + linear-white-space> + + comment = "(" *(ctext / quoted-pair / comment) ")" + + ctext = may be folded + ")", "\" & CR, & including + linear-white-space> + + quoted-pair = "\" CHAR ; may quote any char + + phrase = 1*word ; Sequence of words + + word = atom / quoted-string + + + 3.4. CLARIFICATIONS + + 3.4.1. QUOTING + + Some characters are reserved for special interpretation, such + as delimiting lexical tokens. To permit use of these charac- + ters as uninterpreted data, a quoting mechanism is provided. + To quote a character, precede it with a backslash ("\"). + + This mechanism is not fully general. Characters may be quoted + only within a subset of the lexical constructs. In particu- + lar, quoting is limited to use within: + + - quoted-string + - domain-literal + - comment + + Within these constructs, quoting is REQUIRED for CR and "\" + and for the character(s) that delimit the token (e.g., "(" and + ")" for a comment). However, quoting is PERMITTED for any + character. + + Note: In particular, quoting is NOT permitted within atoms. + For example when the local-part of an addr-spec must + contain a special character, a quoted string must be + used. Therefore, a specification such as: + + Full\ Name@Domain + + is not legal and must be specified as: + + "Full Name"@Domain + + + August 13, 1982 - 11 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + 3.4.2. WHITE SPACE + + Note: In structured field bodies, multiple linear space ASCII + characters (namely HTABs and SPACEs) are treated as + single spaces and may freely surround any symbol. In + all header fields, the only place in which at least one + LWSP-char is REQUIRED is at the beginning of continua- + tion lines in a folded field. + + When passing text to processes that do not interpret text + according to this standard (e.g., mail protocol servers), then + NO linear-white-space characters should occur between a period + (".") or at-sign ("@") and a . Exactly ONE SPACE should + be used in place of arbitrary linear-white-space and comment + sequences. + + Note: Within systems conforming to this standard, wherever a + member of the list of delimiters is allowed, LWSP-chars + may also occur before and/or after it. + + Writers of mail-sending (i.e., header-generating) programs + should realize that there is no network-wide definition of the + effect of ASCII HT (horizontal-tab) characters on the appear- + ance of text at another network host; therefore, the use of + tabs in message headers, though permitted, is discouraged. + + 3.4.3. COMMENTS + + A comment is a set of ASCII characters, which is enclosed in + matching parentheses and which is not within a quoted-string + The comment construct permits message originators to add text + which will be useful for human readers, but which will be + ignored by the formal semantics. Comments should be retained + while the message is subject to interpretation according to + this standard. However, comments must NOT be included in + other cases, such as during protocol exchanges with mail + servers. + + Comments nest, so that if an unquoted left parenthesis occurs + in a comment string, there must also be a matching right + parenthesis. When a comment acts as the delimiter between a + sequence of two lexical symbols, such as two atoms, it is lex- + ically equivalent with a single SPACE, for the purposes of + regenerating the sequence, such as when passing the sequence + onto a mail protocol server. Comments are detected as such + only within field-bodies of structured fields. + + If a comment is to be "folded" onto multiple lines, then the + syntax for folding must be adhered to. (See the "Lexical + + + August 13, 1982 - 12 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + Analysis of Messages" section on "Folding Long Header Fields" + above, and the section on "Case Independence" below.) Note + that the official semantics therefore do not "see" any + unquoted CRLFs that are in comments, although particular pars- + ing programs may wish to note their presence. For these pro- + grams, it would be reasonable to interpret a "CRLF LWSP-char" + as being a CRLF that is part of the comment; i.e., the CRLF is + kept and the LWSP-char is discarded. Quoted CRLFs (i.e., a + backslash followed by a CR followed by a LF) still must be + followed by at least one LWSP-char. + + 3.4.4. DELIMITING AND QUOTING CHARACTERS + + The quote character (backslash) and characters that delimit + syntactic units are not, generally, to be taken as data that + are part of the delimited or quoted unit(s). In particular, + the quotation-marks that define a quoted-string, the + parentheses that define a comment and the backslash that + quotes a following character are NOT part of the quoted- + string, comment or quoted character. A quotation-mark that is + to be part of a quoted-string, a parenthesis that is to be + part of a comment and a backslash that is to be part of either + must each be preceded by the quote-character backslash ("\"). + Note that the syntax allows any character to be quoted within + a quoted-string or comment; however only certain characters + MUST be quoted to be included as data. These characters are + the ones that are not part of the alternate text group (i.e., + ctext or qtext). + + The one exception to this rule is that a single SPACE is + assumed to exist between contiguous words in a phrase, and + this interpretation is independent of the actual number of + LWSP-chars that the creator places between the words. To + include more than one SPACE, the creator must make the LWSP- + chars be part of a quoted-string. + + Quotation marks that delimit a quoted string and backslashes + that quote the following character should NOT accompany the + quoted-string when the string is passed to processes that do + not interpret data according to this specification (e.g., mail + protocol servers). + + 3.4.5. QUOTED-STRINGS + + Where permitted (i.e., in words in structured fields) quoted- + strings are treated as a single symbol. That is, a quoted- + string is equivalent to an atom, syntactically. If a quoted- + string is to be "folded" onto multiple lines, then the syntax + for folding must be adhered to. (See the "Lexical Analysis of + + + August 13, 1982 - 13 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + Messages" section on "Folding Long Header Fields" above, and + the section on "Case Independence" below.) Therefore, the + official semantics do not "see" any bare CRLFs that are in + quoted-strings; however particular parsing programs may wish + to note their presence. For such programs, it would be rea- + sonable to interpret a "CRLF LWSP-char" as being a CRLF which + is part of the quoted-string; i.e., the CRLF is kept and the + LWSP-char is discarded. Quoted CRLFs (i.e., a backslash fol- + lowed by a CR followed by a LF) are also subject to rules of + folding, but the presence of the quoting character (backslash) + explicitly indicates that the CRLF is data to the quoted + string. Stripping off the first following LWSP-char is also + appropriate when parsing quoted CRLFs. + + 3.4.6. BRACKETING CHARACTERS + + There is one type of bracket which must occur in matched pairs + and may have pairs nested within each other: + + o Parentheses ("(" and ")") are used to indicate com- + ments. + + There are three types of brackets which must occur in matched + pairs, and which may NOT be nested: + + o Colon/semi-colon (":" and ";") are used in address + specifications to indicate that the included list of + addresses are to be treated as a group. + + o Angle brackets ("<" and ">") are generally used to + indicate the presence of a one machine-usable refer- + ence (e.g., delimiting mailboxes), possibly including + source-routing to the machine. + + o Square brackets ("[" and "]") are used to indicate the + presence of a domain-literal, which the appropriate + name-domain is to use directly, bypassing normal + name-resolution mechanisms. + + 3.4.7. CASE INDEPENDENCE + + Except as noted, alphabetic strings may be represented in any + combination of upper and lower case. The only syntactic units + + + + + + + + + August 13, 1982 - 14 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + which requires preservation of case information are: + + - text + - qtext + - dtext + - ctext + - quoted-pair + - local-part, except "Postmaster" + + When matching any other syntactic unit, case is to be ignored. + For example, the field-names "From", "FROM", "from", and even + "FroM" are semantically equal and should all be treated ident- + ically. + + When generating these units, any mix of upper and lower case + alphabetic characters may be used. The case shown in this + specification is suggested for message-creating processes. + + Note: The reserved local-part address unit, "Postmaster", is + an exception. When the value "Postmaster" is being + interpreted, it must be accepted in any mixture of + case, including "POSTMASTER", and "postmaster". + + 3.4.8. FOLDING LONG HEADER FIELDS + + Each header field may be represented on exactly one line con- + sisting of the name of the field and its body, and terminated + by a CRLF; this is what the parser sees. For readability, the + field-body portion of long header fields may be "folded" onto + multiple lines of the actual field. "Long" is commonly inter- + preted to mean greater than 65 or 72 characters. The former + length serves as a limit, when the message is to be viewed on + most simple terminals which use simple display software; how- + ever, the limit is not imposed by this standard. + + Note: Some display software often can selectively fold lines, + to suit the display terminal. In such cases, sender- + provided folding can interfere with the display + software. + + 3.4.9. BACKSPACE CHARACTERS + + ASCII BS characters (Backspace, decimal 8) may be included in + texts and quoted-strings to effect overstriking. However, any + use of backspaces which effects an overstrike to the left of + the beginning of the text or quoted-string is prohibited. + + + + + + August 13, 1982 - 15 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + 3.4.10. NETWORK-SPECIFIC TRANSFORMATIONS + + During transmission through heterogeneous networks, it may be + necessary to force data to conform to a network's local con- + ventions. For example, it may be required that a CR be fol- + lowed either by LF, making a CRLF, or by , if the CR is + to stand alone). Such transformations are reversed, when the + message exits that network. + + When crossing network boundaries, the message should be + treated as passing through two modules. It will enter the + first module containing whatever network-specific transforma- + tions that were necessary to permit migration through the + "current" network. It then passes through the modules: + + o Transformation Reversal + + The "current" network's idiosyncracies are removed and + the message is returned to the canonical form speci- + fied in this standard. + + o Transformation + + The "next" network's local idiosyncracies are imposed + on the message. + + ------------------ + From ==> | Remove Net-A | + Net-A | idiosyncracies | + ------------------ + || + \/ + Conformance + with standard + || + \/ + ------------------ + | Impose Net-B | ==> To + | idiosyncracies | Net-B + ------------------ + + + + + + + + + + + + August 13, 1982 - 16 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + 4. MESSAGE SPECIFICATION + + 4.1. SYNTAX + + Note: Due to an artifact of the notational conventions, the syn- + tax indicates that, when present, some fields, must be in + a particular order. Header fields are NOT required to + occur in any particular order, except that the message + body must occur AFTER the headers. It is recommended + that, if present, headers be sent in the order "Return- + Path", "Received", "Date", "From", "Subject", "Sender", + "To", "cc", etc. + + This specification permits multiple occurrences of most + fields. Except as noted, their interpretation is not + specified here, and their use is discouraged. + + The following syntax for the bodies of various fields should + be thought of as describing each field body as a single long + string (or line). The "Lexical Analysis of Message" section on + "Long Header Fields", above, indicates how such long strings can + be represented on more than one line in the actual transmitted + message. + + message = fields *( CRLF *text ) ; Everything after + ; first null line + ; is message body + + fields = dates ; Creation time, + source ; author id & one + 1*destination ; address required + *optional-field ; others optional + + source = [ trace ] ; net traversals + originator ; original mail + [ resent ] ; forwarded + + trace = return ; path to sender + 1*received ; receipt tags + + return = "Return-path" ":" route-addr ; return address + + received = "Received" ":" ; one per relay + ["from" domain] ; sending host + ["by" domain] ; receiving host + ["via" atom] ; physical path + *("with" atom) ; link/mail protocol + ["id" msg-id] ; receiver msg id + ["for" addr-spec] ; initial form + + + August 13, 1982 - 17 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + ";" date-time ; time received + + originator = authentic ; authenticated addr + [ "Reply-To" ":" 1#address] ) + + authentic = "From" ":" mailbox ; Single author + / ( "Sender" ":" mailbox ; Actual submittor + "From" ":" 1#mailbox) ; Multiple authors + ; or not sender + + resent = resent-authentic + [ "Resent-Reply-To" ":" 1#address] ) + + resent-authentic = + = "Resent-From" ":" mailbox + / ( "Resent-Sender" ":" mailbox + "Resent-From" ":" 1#mailbox ) + + dates = orig-date ; Original + [ resent-date ] ; Forwarded + + orig-date = "Date" ":" date-time + + resent-date = "Resent-Date" ":" date-time + + destination = "To" ":" 1#address ; Primary + / "Resent-To" ":" 1#address + / "cc" ":" 1#address ; Secondary + / "Resent-cc" ":" 1#address + / "bcc" ":" #address ; Blind carbon + / "Resent-bcc" ":" #address + + optional-field = + / "Message-ID" ":" msg-id + / "Resent-Message-ID" ":" msg-id + / "In-Reply-To" ":" *(phrase / msg-id) + / "References" ":" *(phrase / msg-id) + / "Keywords" ":" #phrase + / "Subject" ":" *text + / "Comments" ":" *text + / "Encrypted" ":" 1#2word + / extension-field ; To be defined + / user-defined-field ; May be pre-empted + + msg-id = "<" addr-spec ">" ; Unique message id + + + + + + + August 13, 1982 - 18 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + extension-field = + + + user-defined-field = + + + 4.2. FORWARDING + + Some systems permit mail recipients to forward a message, + retaining the original headers, by adding some new fields. This + standard supports such a service, through the "Resent-" prefix to + field names. + + Whenever the string "Resent-" begins a field name, the field + has the same semantics as a field whose name does not have the + prefix. However, the message is assumed to have been forwarded + by an original recipient who attached the "Resent-" field. This + new field is treated as being more recent than the equivalent, + original field. For example, the "Resent-From", indicates the + person that forwarded the message, whereas the "From" field indi- + cates the original author. + + Use of such precedence information depends upon partici- + pants' communication needs. For example, this standard does not + dictate when a "Resent-From:" address should receive replies, in + lieu of sending them to the "From:" address. + + Note: In general, the "Resent-" fields should be treated as con- + taining a set of information that is independent of the + set of original fields. Information for one set should + not automatically be taken from the other. The interpre- + tation of multiple "Resent-" fields, of the same type, is + undefined. + + In the remainder of this specification, occurrence of legal + "Resent-" fields are treated identically with the occurrence of + + + + + + + + + August 13, 1982 - 19 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + fields whose names do not contain this prefix. + + 4.3. TRACE FIELDS + + Trace information is used to provide an audit trail of mes- + sage handling. In addition, it indicates a route back to the + sender of the message. + + The list of known "via" and "with" values are registered + with the Network Information Center, SRI International, Menlo + Park, California. + + 4.3.1. RETURN-PATH + + This field is added by the final transport system that + delivers the message to its recipient. The field is intended + to contain definitive information about the address and route + back to the message's originator. + + Note: The "Reply-To" field is added by the originator and + serves to direct replies, whereas the "Return-Path" + field is used to identify a path back to the origina- + tor. + + While the syntax indicates that a route specification is + optional, every attempt should be made to provide that infor- + mation in this field. + + 4.3.2. RECEIVED + + A copy of this field is added by each transport service that + relays the message. The information in the field can be quite + useful for tracing transport problems. + + The names of the sending and receiving hosts and time-of- + receipt may be specified. The "via" parameter may be used, to + indicate what physical mechanism the message was sent over, + such as Arpanet or Phonenet, and the "with" parameter may be + used to indicate the mail-, or connection-, level protocol + that was used, such as the SMTP mail protocol, or X.25 tran- + sport protocol. + + Note: Several "with" parameters may be included, to fully + specify the set of protocols that were used. + + Some transport services queue mail; the internal message iden- + tifier that is assigned to the message may be noted, using the + "id" parameter. When the sending host uses a destination + address specification that the receiving host reinterprets, by + + + August 13, 1982 - 20 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + expansion or transformation, the receiving host may wish to + record the original specification, using the "for" parameter. + For example, when a copy of mail is sent to the member of a + distribution list, this parameter may be used to record the + original address that was used to specify the list. + + 4.4. ORIGINATOR FIELDS + + The standard allows only a subset of the combinations possi- + ble with the From, Sender, Reply-To, Resent-From, Resent-Sender, + and Resent-Reply-To fields. The limitation is intentional. + + 4.4.1. FROM / RESENT-FROM + + This field contains the identity of the person(s) who wished + this message to be sent. The message-creation process should + default this field to be a single, authenticated machine + address, indicating the AGENT (person, system or process) + entering the message. If this is not done, the "Sender" field + MUST be present. If the "From" field IS defaulted this way, + the "Sender" field is optional and is redundant with the + "From" field. In all cases, addresses in the "From" field + must be machine-usable (addr-specs) and may not contain named + lists (groups). + + 4.4.2. SENDER / RESENT-SENDER + + This field contains the authenticated identity of the AGENT + (person, system or process) that sends the message. It is + intended for use when the sender is not the author of the mes- + sage, or to indicate who among a group of authors actually + sent the message. If the contents of the "Sender" field would + be completely redundant with the "From" field, then the + "Sender" field need not be present and its use is discouraged + (though still legal). In particular, the "Sender" field MUST + be present if it is NOT the same as the "From" Field. + + The Sender mailbox specification includes a word sequence + which must correspond to a specific agent (i.e., a human user + or a computer program) rather than a standard address. This + indicates the expectation that the field will identify the + single AGENT (person, system, or process) responsible for + sending the mail and not simply include the name of a mailbox + from which the mail was sent. For example in the case of a + shared login name, the name, by itself, would not be adequate. + The local-part address unit, which refers to this agent, is + expected to be a computer system term, and not (for example) a + generalized person reference which can be used outside the + network text message context. + + + August 13, 1982 - 21 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + Since the critical function served by the "Sender" field is + identification of the agent responsible for sending mail and + since computer programs cannot be held accountable for their + behavior, it is strongly recommended that when a computer pro- + gram generates a message, the HUMAN who is responsible for + that program be referenced as part of the "Sender" field mail- + box specification. + + 4.4.3. REPLY-TO / RESENT-REPLY-TO + + This field provides a general mechanism for indicating any + mailbox(es) to which responses are to be sent. Three typical + uses for this feature can be distinguished. In the first + case, the author(s) may not have regular machine-based mail- + boxes and therefore wish(es) to indicate an alternate machine + address. In the second case, an author may wish additional + persons to be made aware of, or responsible for, replies. A + somewhat different use may be of some help to "text message + teleconferencing" groups equipped with automatic distribution + services: include the address of that service in the "Reply- + To" field of all messages submitted to the teleconference; + then participants can "reply" to conference submissions to + guarantee the correct distribution of any submission of their + own. + + Note: The "Return-Path" field is added by the mail transport + service, at the time of final deliver. It is intended + to identify a path back to the orginator of the mes- + sage. The "Reply-To" field is added by the message + originator and is intended to direct replies. + + 4.4.4. AUTOMATIC USE OF FROM / SENDER / REPLY-TO + + For systems which automatically generate address lists for + replies to messages, the following recommendations are made: + + o The "Sender" field mailbox should be sent notices of + any problems in transport or delivery of the original + messages. If there is no "Sender" field, then the + "From" field mailbox should be used. + + o The "Sender" field mailbox should NEVER be used + automatically, in a recipient's reply message. + + o If the "Reply-To" field exists, then the reply should + go to the addresses indicated in that field and not to + the address(es) indicated in the "From" field. + + + + + August 13, 1982 - 22 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + o If there is a "From" field, but no "Reply-To" field, + the reply should be sent to the address(es) indicated + in the "From" field. + + Sometimes, a recipient may actually wish to communicate with + the person that initiated the message transfer. In such + cases, it is reasonable to use the "Sender" address. + + This recommendation is intended only for automated use of + originator-fields and is not intended to suggest that replies + may not also be sent to other recipients of messages. It is + up to the respective mail-handling programs to decide what + additional facilities will be provided. + + Examples are provided in Appendix A. + + 4.5. RECEIVER FIELDS + + 4.5.1. TO / RESENT-TO + + This field contains the identity of the primary recipients of + the message. + + 4.5.2. CC / RESENT-CC + + This field contains the identity of the secondary (informa- + tional) recipients of the message. + + 4.5.3. BCC / RESENT-BCC + + This field contains the identity of additional recipients of + the message. The contents of this field are not included in + copies of the message sent to the primary and secondary reci- + pients. Some systems may choose to include the text of the + "Bcc" field only in the author(s)'s copy, while others may + also include it in the text sent to all those indicated in the + "Bcc" list. + + 4.6. REFERENCE FIELDS + + 4.6.1. MESSAGE-ID / RESENT-MESSAGE-ID + + This field contains a unique identifier (the local-part + address unit) which refers to THIS version of THIS message. + The uniqueness of the message identifier is guaranteed by the + host which generates it. This identifier is intended to be + machine readable and not necessarily meaningful to humans. A + message identifier pertains to exactly one instantiation of a + particular message; subsequent revisions to the message should + + + August 13, 1982 - 23 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + each receive new message identifiers. + + 4.6.2. IN-REPLY-TO + + The contents of this field identify previous correspon- + dence which this message answers. Note that if message iden- + tifiers are used in this field, they must use the msg-id + specification format. + + 4.6.3. REFERENCES + + The contents of this field identify other correspondence + which this message references. Note that if message identif- + iers are used, they must use the msg-id specification format. + + 4.6.4. KEYWORDS + + This field contains keywords or phrases, separated by + commas. + + 4.7. OTHER FIELDS + + 4.7.1. SUBJECT + + This is intended to provide a summary, or indicate the + nature, of the message. + + 4.7.2. COMMENTS + + Permits adding text comments onto the message without + disturbing the contents of the message's body. + + 4.7.3. ENCRYPTED + + Sometimes, data encryption is used to increase the + privacy of message contents. If the body of a message has + been encrypted, to keep its contents private, the "Encrypted" + field can be used to note the fact and to indicate the nature + of the encryption. The first parameter indicates the + software used to encrypt the body, and the second, optional + is intended to aid the recipient in selecting the + proper decryption key. This code word may be viewed as an + index to a table of keys held by the recipient. + + Note: Unfortunately, headers must contain envelope, as well + as contents, information. Consequently, it is neces- + sary that they remain unencrypted, so that mail tran- + sport services may access them. Since names, + addresses, and "Subject" field contents may contain + + + August 13, 1982 - 24 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + sensitive information, this requirement limits total + message privacy. + + Names of encryption software are registered with the Net- + work Information Center, SRI International, Menlo Park, Cali- + fornia. + + 4.7.4. EXTENSION-FIELD + + A limited number of common fields have been defined in + this document. As network mail requirements dictate, addi- + tional fields may be standardized. To provide user-defined + fields with a measure of safety, in name selection, such + extension-fields will never have names that begin with the + string "X-". + + Names of Extension-fields are registered with the Network + Information Center, SRI International, Menlo Park, California. + + 4.7.5. USER-DEFINED-FIELD + + Individual users of network mail are free to define and + use additional header fields. Such fields must have names + which are not already used in the current specification or in + any definitions of extension-fields, and the overall syntax of + these user-defined-fields must conform to this specification's + rules for delimiting and folding fields. Due to the + extension-field publishing process, the name of a user- + defined-field may be pre-empted + + Note: The prefatory string "X-" will never be used in the + names of Extension-fields. This provides user-defined + fields with a protected set of names. + + + + + + + + + + + + + + + + + + + August 13, 1982 - 25 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + 5. DATE AND TIME SPECIFICATION + + 5.1. SYNTAX + + date-time = [ day "," ] date time ; dd mm yy + ; hh:mm:ss zzz + + day = "Mon" / "Tue" / "Wed" / "Thu" + / "Fri" / "Sat" / "Sun" + + date = 1*2DIGIT month 2DIGIT ; day month year + ; e.g. 20 Jun 82 + + month = "Jan" / "Feb" / "Mar" / "Apr" + / "May" / "Jun" / "Jul" / "Aug" + / "Sep" / "Oct" / "Nov" / "Dec" + + time = hour zone ; ANSI and Military + + hour = 2DIGIT ":" 2DIGIT [":" 2DIGIT] + ; 00:00:00 - 23:59:59 + + zone = "UT" / "GMT" ; Universal Time + ; North American : UT + / "EST" / "EDT" ; Eastern: - 5/ - 4 + / "CST" / "CDT" ; Central: - 6/ - 5 + / "MST" / "MDT" ; Mountain: - 7/ - 6 + / "PST" / "PDT" ; Pacific: - 8/ - 7 + / 1ALPHA ; Military: Z = UT; + ; A:-1; (J not used) + ; M:-12; N:+1; Y:+12 + / ( ("+" / "-") 4DIGIT ) ; Local differential + ; hours+min. (HHMM) + + 5.2. SEMANTICS + + If included, day-of-week must be the day implied by the date + specification. + + Time zone may be indicated in several ways. "UT" is Univer- + sal Time (formerly called "Greenwich Mean Time"); "GMT" is per- + mitted as a reference to Universal Time. The military standard + uses a single character for each zone. "Z" is Universal Time. + "A" indicates one hour earlier, and "M" indicates 12 hours ear- + lier; "N" is one hour later, and "Y" is 12 hours later. The + letter "J" is not used. The other remaining two forms are taken + from ANSI standard X3.51-1975. One allows explicit indication of + the amount of offset from UT; the other uses common 3-character + strings for indicating time zones in North America. + + + August 13, 1982 - 26 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + 6. ADDRESS SPECIFICATION + + 6.1. SYNTAX + + address = mailbox ; one addressee + / group ; named list + + group = phrase ":" [#mailbox] ";" + + mailbox = addr-spec ; simple address + / phrase route-addr ; name & addr-spec + + route-addr = "<" [route] addr-spec ">" + + route = 1#("@" domain) ":" ; path-relative + + addr-spec = local-part "@" domain ; global address + + local-part = word *("." word) ; uninterpreted + ; case-preserved + + domain = sub-domain *("." sub-domain) + + sub-domain = domain-ref / domain-literal + + domain-ref = atom ; symbolic reference + + 6.2. SEMANTICS + + A mailbox receives mail. It is a conceptual entity which + does not necessarily pertain to file storage. For example, some + sites may choose to print mail on their line printer and deliver + the output to the addressee's desk. + + A mailbox specification comprises a person, system or pro- + cess name reference, a domain-dependent string, and a name-domain + reference. The name reference is optional and is usually used to + indicate the human name of a recipient. The name-domain refer- + ence specifies a sequence of sub-domains. The domain-dependent + string is uninterpreted, except by the final sub-domain; the rest + of the mail service merely transmits it as a literal string. + + 6.2.1. DOMAINS + + A name-domain is a set of registered (mail) names. A name- + domain specification resolves to a subordinate name-domain + specification or to a terminal domain-dependent string. + Hence, domain specification is extensible, permitting any + number of registration levels. + + + August 13, 1982 - 27 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + Name-domains model a global, logical, hierarchical addressing + scheme. The model is logical, in that an address specifica- + tion is related to name registration and is not necessarily + tied to transmission path. The model's hierarchy is a + directed graph, called an in-tree, such that there is a single + path from the root of the tree to any node in the hierarchy. + If more than one path actually exists, they are considered to + be different addresses. + + The root node is common to all addresses; consequently, it is + not referenced. Its children constitute "top-level" name- + domains. Usually, a service has access to its own full domain + specification and to the names of all top-level name-domains. + + The "top" of the domain addressing hierarchy -- a child of the + root -- is indicated by the right-most field, in a domain + specification. Its child is specified to the left, its child + to the left, and so on. + + Some groups provide formal registration services; these con- + stitute name-domains that are independent logically of + specific machines. In addition, networks and machines impli- + citly compose name-domains, since their membership usually is + registered in name tables. + + In the case of formal registration, an organization implements + a (distributed) data base which provides an address-to-route + mapping service for addresses of the form: + + person@registry.organization + + Note that "organization" is a logical entity, separate from + any particular communication network. + + A mechanism for accessing "organization" is universally avail- + able. That mechanism, in turn, seeks an instantiation of the + registry; its location is not indicated in the address specif- + ication. It is assumed that the system which operates under + the name "organization" knows how to find a subordinate regis- + try. The registry will then use the "person" string to deter- + mine where to send the mail specification. + + The latter, network-oriented case permits simple, direct, + attachment-related address specification, such as: + + user@host.network + + Once the network is accessed, it is expected that a message + will go directly to the host and that the host will resolve + + + August 13, 1982 - 28 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + the user name, placing the message in the user's mailbox. + + 6.2.2. ABBREVIATED DOMAIN SPECIFICATION + + Since any number of levels is possible within the domain + hierarchy, specification of a fully qualified address can + become inconvenient. This standard permits abbreviated domain + specification, in a special case: + + For the address of the sender, call the left-most + sub-domain Level N. In a header address, if all of + the sub-domains above (i.e., to the right of) Level N + are the same as those of the sender, then they do not + have to appear in the specification. Otherwise, the + address must be fully qualified. + + This feature is subject to approval by local sub- + domains. Individual sub-domains may require their + member systems, which originate mail, to provide full + domain specification only. When permitted, abbrevia- + tions may be present only while the message stays + within the sub-domain of the sender. + + Use of this mechanism requires the sender's sub-domain + to reserve the names of all top-level domains, so that + full specifications can be distinguished from abbrevi- + ated specifications. + + For example, if a sender's address is: + + sender@registry-A.registry-1.organization-X + + and one recipient's address is: + + recipient@registry-B.registry-1.organization-X + + and another's is: + + recipient@registry-C.registry-2.organization-X + + then ".registry-1.organization-X" need not be specified in the + the message, but "registry-C.registry-2" DOES have to be + specified. That is, the first two addresses may be abbrevi- + ated, but the third address must be fully specified. + + When a message crosses a domain boundary, all addresses must + be specified in the full format, ending with the top-level + name-domain in the right-most field. It is the responsibility + of mail forwarding services to ensure that addresses conform + + + August 13, 1982 - 29 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + with this requirement. In the case of abbreviated addresses, + the relaying service must make the necessary expansions. It + should be noted that it often is difficult for such a service + to locate all occurrences of address abbreviations. For exam- + ple, it will not be possible to find such abbreviations within + the body of the message. The "Return-Path" field can aid + recipients in recovering from these errors. + + Note: When passing any portion of an addr-spec onto a process + which does not interpret data according to this stan- + dard (e.g., mail protocol servers). There must be NO + LWSP-chars preceding or following the at-sign or any + delimiting period ("."), such as shown in the above + examples, and only ONE SPACE between contiguous + s. + + 6.2.3. DOMAIN TERMS + + A domain-ref must be THE official name of a registry, network, + or host. It is a symbolic reference, within a name sub- + domain. At times, it is necessary to bypass standard mechan- + isms for resolving such references, using more primitive + information, such as a network host address rather than its + associated host name. + + To permit such references, this standard provides the domain- + literal construct. Its contents must conform with the needs + of the sub-domain in which it is interpreted. + + Domain-literals which refer to domains within the ARPA Inter- + net specify 32-bit Internet addresses, in four 8-bit fields + noted in decimal, as described in Request for Comments #820, + "Assigned Numbers." For example: + + [10.0.3.19] + + Note: THE USE OF DOMAIN-LITERALS IS STRONGLY DISCOURAGED. It + is permitted only as a means of bypassing temporary + system limitations, such as name tables which are not + complete. + + The names of "top-level" domains, and the names of domains + under in the ARPA Internet, are registered with the Network + Information Center, SRI International, Menlo Park, California. + + 6.2.4. DOMAIN-DEPENDENT LOCAL STRING + + The local-part of an addr-spec in a mailbox specification + (i.e., the host's name for the mailbox) is understood to be + + + August 13, 1982 - 30 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + whatever the receiving mail protocol server allows. For exam- + ple, some systems do not understand mailbox references of the + form "P. D. Q. Bach", but others do. + + This specification treats periods (".") as lexical separators. + Hence, their presence in local-parts which are not quoted- + strings, is detected. However, such occurrences carry NO + semantics. That is, if a local-part has periods within it, an + address parser will divide the local-part into several tokens, + but the sequence of tokens will be treated as one uninter- + preted unit. The sequence will be re-assembled, when the + address is passed outside of the system such as to a mail pro- + tocol service. + + For example, the address: + + First.Last@Registry.Org + + is legal and does not require the local-part to be surrounded + with quotation-marks. (However, "First Last" DOES require + quoting.) The local-part of the address, when passed outside + of the mail system, within the Registry.Org domain, is + "First.Last", again without quotation marks. + + 6.2.5. BALANCING LOCAL-PART AND DOMAIN + + In some cases, the boundary between local-part and domain can + be flexible. The local-part may be a simple string, which is + used for the final determination of the recipient's mailbox. + All other levels of reference are, therefore, part of the + domain. + + For some systems, in the case of abbreviated reference to the + local and subordinate sub-domains, it may be possible to + specify only one reference within the domain part and place + the other, subordinate name-domain references within the + local-part. This would appear as: + + mailbox.sub1.sub2@this-domain + + Such a specification would be acceptable to address parsers + which conform to RFC #733, but do not support this newer + Internet standard. While contrary to the intent of this stan- + dard, the form is legal. + + Also, some sub-domains have a specification syntax which does + not conform to this standard. For example: + + sub-net.mailbox@sub-domain.domain + + + August 13, 1982 - 31 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + uses a different parsing sequence for local-part than for + domain. + + Note: As a rule, the domain specification should contain + fields which are encoded according to the syntax of + this standard and which contain generally-standardized + information. The local-part specification should con- + tain only that portion of the address which deviates + from the form or intention of the domain field. + + 6.2.6. MULTIPLE MAILBOXES + + An individual may have several mailboxes and wish to receive + mail at whatever mailbox is convenient for the sender to + access. This standard does not provide a means of specifying + "any member of" a list of mailboxes. + + A set of individuals may wish to receive mail as a single unit + (i.e., a distribution list). The construct permits + specification of such a list. Recipient mailboxes are speci- + fied within the bracketed part (":" - ";"). A copy of the + transmitted message is to be sent to each mailbox listed. + This standard does not permit recursive specification of + groups within groups. + + While a list must be named, it is not required that the con- + tents of the list be included. In this case, the
+ serves only as an indication of group distribution and would + appear in the form: + + name:; + + Some mail services may provide a group-list distribution + facility, accepting a single mailbox reference, expanding it + to the full distribution list, and relaying the mail to the + list's members. This standard provides no additional syntax + for indicating such a service. Using the address + alternative, while listing one mailbox in it, can mean either + that the mailbox reference will be expanded to a list or that + there is a group with one member. + + 6.2.7. EXPLICIT PATH SPECIFICATION + + At times, a message originator may wish to indicate the + transmission path that a message should follow. This is + called source routing. The normal addressing scheme, used in + an addr-spec, is carefully separated from such information; + the portion of a route-addr is provided for such occa- + sions. It specifies the sequence of hosts and/or transmission + + + August 13, 1982 - 32 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + services that are to be traversed. Both domain-refs and + domain-literals may be used. + + Note: The use of source routing is discouraged. Unless the + sender has special need of path restriction, the choice + of transmission route should be left to the mail tran- + sport service. + + 6.3. RESERVED ADDRESS + + It often is necessary to send mail to a site, without know- + ing any of its valid addresses. For example, there may be mail + system dysfunctions, or a user may wish to find out a person's + correct address, at that site. + + This standard specifies a single, reserved mailbox address + (local-part) which is to be valid at each site. Mail sent to + that address is to be routed to a person responsible for the + site's mail system or to a person with responsibility for general + site operation. The name of the reserved local-part address is: + + Postmaster + + so that "Postmaster@domain" is required to be valid. + + Note: This reserved local-part must be matched without sensi- + tivity to alphabetic case, so that "POSTMASTER", "postmas- + ter", and even "poStmASteR" is to be accepted. + + + + + + + + + + + + + + + + + + + + + + + + August 13, 1982 - 33 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + 7. BIBLIOGRAPHY + + + ANSI. "USA Standard Code for Information Interchange," X3.4. + American National Standards Institute: New York (1968). Also + in: Feinler, E. and J. Postel, eds., "ARPANET Protocol Hand- + book", NIC 7104. + + ANSI. "Representations of Universal Time, Local Time Differen- + tials, and United States Time Zone References for Information + Interchange," X3.51-1975. American National Standards Insti- + tute: New York (1975). + + Bemer, R.W., "Time and the Computer." In: Interface Age (Feb. + 1979). + + Bennett, C.J. "JNT Mail Protocol". Joint Network Team, Ruther- + ford and Appleton Laboratory: Didcot, England. + + Bhushan, A.K., Pogran, K.T., Tomlinson, R.S., and White, J.E. + "Standardizing Network Mail Headers," ARPANET Request for + Comments No. 561, Network Information Center No. 18516; SRI + International: Menlo Park (September 1973). + + Birrell, A.D., Levin, R., Needham, R.M., and Schroeder, M.D. + "Grapevine: An Exercise in Distributed Computing," Communica- + tions of the ACM 25, 4 (April 1982), 260-274. + + Crocker, D.H., Vittal, J.J., Pogran, K.T., Henderson, D.A. + "Standard for the Format of ARPA Network Text Message," + ARPANET Request for Comments No. 733, Network Information + Center No. 41952. SRI International: Menlo Park (November + 1977). + + Feinler, E.J. and Postel, J.B. ARPANET Protocol Handbook, Net- + work Information Center No. 7104 (NTIS AD A003890). SRI + International: Menlo Park (April 1976). + + Harary, F. "Graph Theory". Addison-Wesley: Reading, Mass. + (1969). + + Levin, R. and Schroeder, M. "Transport of Electronic Messages + through a Network," TeleInformatics 79, pp. 29-33. North + Holland (1979). Also as Xerox Palo Alto Research Center + Technical Report CSL-79-4. + + Myer, T.H. and Henderson, D.A. "Message Transmission Protocol," + ARPANET Request for Comments, No. 680, Network Information + Center No. 32116. SRI International: Menlo Park (1975). + + + August 13, 1982 - 34 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + NBS. "Specification of Message Format for Computer Based Message + Systems, Recommended Federal Information Processing Standard." + National Bureau of Standards: Gaithersburg, Maryland + (October 1981). + + NIC. Internet Protocol Transition Workbook. Network Information + Center, SRI-International, Menlo Park, California (March + 1982). + + Oppen, D.C. and Dalal, Y.K. "The Clearinghouse: A Decentralized + Agent for Locating Named Objects in a Distributed Environ- + ment," OPD-T8103. Xerox Office Products Division: Palo Alto, + CA. (October 1981). + + Postel, J.B. "Assigned Numbers," ARPANET Request for Comments, + No. 820. SRI International: Menlo Park (August 1982). + + Postel, J.B. "Simple Mail Transfer Protocol," ARPANET Request + for Comments, No. 821. SRI International: Menlo Park (August + 1982). + + Shoch, J.F. "Internetwork naming, addressing and routing," in + Proc. 17th IEEE Computer Society International Conference, pp. + 72-79, Sept. 1978, IEEE Cat. No. 78 CH 1388-8C. + + Su, Z. and Postel, J. "The Domain Naming Convention for Internet + User Applications," ARPANET Request for Comments, No. 819. + SRI International: Menlo Park (August 1982). + + + + + + + + + + + + + + + + + + + + + + + + August 13, 1982 - 35 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + APPENDIX + + + A. EXAMPLES + + A.1. ADDRESSES + + A.1.1. Alfred Neuman + + A.1.2. Neuman@BBN-TENEXA + + These two "Alfred Neuman" examples have identical seman- + tics, as far as the operation of the local host's mail sending + (distribution) program (also sometimes called its "mailer") + and the remote host's mail protocol server are concerned. In + the first example, the "Alfred Neuman" is ignored by the + mailer, as "Neuman@BBN-TENEXA" completely specifies the reci- + pient. The second example contains no superfluous informa- + tion, and, again, "Neuman@BBN-TENEXA" is the intended reci- + pient. + + Note: When the message crosses name-domain boundaries, then + these specifications must be changed, so as to indicate + the remainder of the hierarchy, starting with the top + level. + + A.1.3. "George, Ted" + + This form might be used to indicate that a single mailbox + is shared by several users. The quoted string is ignored by + the originating host's mailer, because "Shared@Group.Arpanet" + completely specifies the destination mailbox. + + A.1.4. Wilt . (the Stilt) Chamberlain@NBA.US + + The "(the Stilt)" is a comment, which is NOT included in + the destination mailbox address handed to the originating + system's mailer. The local-part of the address is the string + "Wilt.Chamberlain", with NO space between the first and second + words. + + A.1.5. Address Lists + + Gourmets: Pompous Person , + Childs@WGBH.Boston, Galloping Gourmet@ + ANT.Down-Under (Australian National Television), + Cheapie@Discount-Liquors;, + Cruisers: Port@Portugal, Jones@SEA;, + Another@Somewhere.SomeOrg + + + August 13, 1982 - 36 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + This group list example points out the use of comments and the + mixing of addresses and groups. + + A.2. ORIGINATOR ITEMS + + A.2.1. Author-sent + + George Jones logs into his host as "Jones". He sends + mail himself. + + From: Jones@Group.Org + + or + + From: George Jones + + A.2.2. Secretary-sent + + George Jones logs in as Jones on his host. His secre- + tary, who logs in as Secy sends mail for him. Replies to the + mail should go to George. + + From: George Jones + Sender: Secy@Other-Group + + A.2.3. Secretary-sent, for user of shared directory + + George Jones' secretary sends mail for George. Replies + should go to George. + + From: George Jones + Sender: Secy@Other-Group + + Note that there need not be a space between "Jones" and the + "<", but adding a space enhances readability (as is the case + in other examples. + + A.2.4. Committee activity, with one author + + George is a member of a committee. He wishes to have any + replies to his message go to all committee members. + + From: George Jones + Sender: Jones@Host + Reply-To: The Committee: Jones@Host.Net, + Smith@Other.Org, + Doe@Somewhere-Else; + + Note that if George had not included himself in the + + + August 13, 1982 - 37 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + enumeration of The Committee, he would not have gotten an + implicit reply; the presence of the "Reply-to" field SUPER- + SEDES the sending of a reply to the person named in the "From" + field. + + A.2.5. Secretary acting as full agent of author + + George Jones asks his secretary (Secy@Host) to send a + message for him in his capacity as Group. He wants his secre- + tary to handle all replies. + + From: George Jones + Sender: Secy@Host + Reply-To: Secy@Host + + A.2.6. Agent for user without online mailbox + + A friend of George's, Sarah, is visiting. George's + secretary sends some mail to a friend of Sarah in computer- + land. Replies should go to George, whose mailbox is Jones at + Registry. + + From: Sarah Friendly + Sender: Secy-Name + Reply-To: Jones@Registry. + + A.2.7. Agent for member of a committee + + George's secretary sends out a message which was authored + jointly by all the members of a committee. Note that the name + of the committee cannot be specified, since names are + not permitted in the From field. + + From: Jones@Host, + Smith@Other-Host, + Doe@Somewhere-Else + Sender: Secy@SHost + + + + + + + + + + + + + + + August 13, 1982 - 38 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + A.3. COMPLETE HEADERS + + A.3.1. Minimum required + + Date: 26 Aug 76 1429 EDT Date: 26 Aug 76 1429 EDT + From: Jones@Registry.Org or From: Jones@Registry.Org + Bcc: To: Smith@Registry.Org + + Note that the "Bcc" field may be empty, while the "To" field + is required to have at least one address. + + A.3.2. Using some of the additional fields + + Date: 26 Aug 76 1430 EDT + From: George Jones + Sender: Secy@SHOST + To: "Al Neuman"@Mad-Host, + Sam.Irving@Other-Host + Message-ID: + + A.3.3. About as complex as you're going to get + + Date : 27 Aug 76 0932 PDT + From : Ken Davis + Subject : Re: The Syntax in the RFC + Sender : KSecy@Other-Host + Reply-To : Sam.Irving@Reg.Organization + To : George Jones , + Al.Neuman@MAD.Publisher + cc : Important folk: + Tom Softwood , + "Sam Irving"@Other-Host;, + Standard Distribution: + /main/davis/people/standard@Other-Host, + "standard.dist.3"@Tops-20-Host>; + Comment : Sam is away on business. He asked me to handle + his mail for him. He'll be able to provide a + more accurate explanation when he returns + next week. + In-Reply-To: , George's message + X-Special-action: This is a sample of user-defined field- + names. There could also be a field-name + "Special-action", but its name might later be + preempted + Message-ID: <4231.629.XYzi-What@Other-Host> + + + + + + + August 13, 1982 - 39 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + B. SIMPLE FIELD PARSING + + Some mail-reading software systems may wish to perform only + minimal processing, ignoring the internal syntax of structured + field-bodies and treating them the same as unstructured-field- + bodies. Such software will need only to distinguish: + + o Header fields from the message body, + + o Beginnings of fields from lines which continue fields, + + o Field-names from field-contents. + + The abbreviated set of syntactic rules which follows will + suffice for this purpose. It describes a limited view of mes- + sages and is a subset of the syntactic rules provided in the main + part of this specification. One small exception is that the con- + tents of field-bodies consist only of text: + + B.1. SYNTAX + + + message = *field *(CRLF *text) + + field = field-name ":" [field-body] CRLF + + field-name = 1* + + field-body = *text [CRLF LWSP-char field-body] + + + B.2. SEMANTICS + + Headers occur before the message body and are terminated by + a null line (i.e., two contiguous CRLFs). + + A line which continues a header field begins with a SPACE or + HTAB character, while a line beginning a field starts with a + printable character which is not a colon. + + A field-name consists of one or more printable characters + (excluding colon, space, and control-characters). A field-name + MUST be contained on one line. Upper and lower case are not dis- + tinguished when comparing field-names. + + + + + + + + August 13, 1982 - 40 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + C. DIFFERENCES FROM RFC #733 + + The following summarizes the differences between this stan- + dard and the one specified in Arpanet Request for Comments #733, + "Standard for the Format of ARPA Network Text Messages". The + differences are listed in the order of their occurrence in the + current specification. + + C.1. FIELD DEFINITIONS + + C.1.1. FIELD NAMES + + These now must be a sequence of printable characters. They + may not contain any LWSP-chars. + + C.2. LEXICAL TOKENS + + C.2.1. SPECIALS + + The characters period ("."), left-square bracket ("["), and + right-square bracket ("]") have been added. For presentation + purposes, and when passing a specification to a system that + does not conform to this standard, periods are to be contigu- + ous with their surrounding lexical tokens. No linear-white- + space is permitted between them. The presence of one LWSP- + char between other tokens is still directed. + + C.2.2. ATOM + + Atoms may not contain SPACE. + + C.2.3. SPECIAL TEXT + + ctext and qtext have had backslash ("\") added to the list of + prohibited characters. + + C.2.4. DOMAINS + + The lexical tokens and have been + added. + + C.3. MESSAGE SPECIFICATION + + C.3.1. TRACE + + The "Return-path:" and "Received:" fields have been specified. + + + + + + August 13, 1982 - 41 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + C.3.2. FROM + + The "From" field must contain machine-usable addresses (addr- + spec). Multiple addresses may be specified, but named-lists + (groups) may not. + + C.3.3. RESENT + + The meta-construct of prefacing field names with the string + "Resent-" has been added, to indicate that a message has been + forwarded by an intermediate recipient. + + C.3.4. DESTINATION + + A message must contain at least one destination address field. + "To" and "CC" are required to contain at least one address. + + C.3.5. IN-REPLY-TO + + The field-body is no longer a comma-separated list, although a + sequence is still permitted. + + C.3.6. REFERENCE + + The field-body is no longer a comma-separated list, although a + sequence is still permitted. + + C.3.7. ENCRYPTED + + A field has been specified that permits senders to indicate + that the body of a message has been encrypted. + + C.3.8. EXTENSION-FIELD + + Extension fields are prohibited from beginning with the char- + acters "X-". + + C.4. DATE AND TIME SPECIFICATION + + C.4.1. SIMPLIFICATION + + Fewer optional forms are permitted and the list of three- + letter time zones has been shortened. + + C.5. ADDRESS SPECIFICATION + + + + + + + August 13, 1982 - 42 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + C.5.1. ADDRESS + + The use of quoted-string, and the ":"-atom-":" construct, have + been removed. An address now is either a single mailbox + reference or is a named list of addresses. The latter indi- + cates a group distribution. + + C.5.2. GROUPS + + Group lists are now required to to have a name. Group lists + may not be nested. + + C.5.3. MAILBOX + + A mailbox specification may indicate a person's name, as + before. Such a named list no longer may specify multiple + mailboxes and may not be nested. + + C.5.4. ROUTE ADDRESSING + + Addresses now are taken to be absolute, global specifications, + independent of transmission paths. The construct has + been provided, to permit explicit specification of transmis- + sion path. RFC #733's use of multiple at-signs ("@") was + intended as a general syntax for indicating routing and/or + hierarchical addressing. The current standard separates these + specifications and only one at-sign is permitted. + + C.5.5. AT-SIGN + + The string " at " no longer is used as an address delimiter. + Only at-sign ("@") serves the function. + + C.5.6. DOMAINS + + Hierarchical, logical name-domains have been added. + + C.6. RESERVED ADDRESS + + The local-part "Postmaster" has been reserved, so that users can + be guaranteed at least one valid address at a site. + + + + + + + + + + + August 13, 1982 - 43 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + D. ALPHABETICAL LISTING OF SYNTAX RULES + + address = mailbox ; one addressee + / group ; named list + addr-spec = local-part "@" domain ; global address + ALPHA = + ; (101-132, 65.- 90.) + ; (141-172, 97.-122.) + atom = 1* + authentic = "From" ":" mailbox ; Single author + / ( "Sender" ":" mailbox ; Actual submittor + "From" ":" 1#mailbox) ; Multiple authors + ; or not sender + CHAR = ; ( 0-177, 0.-127.) + comment = "(" *(ctext / quoted-pair / comment) ")" + CR = ; ( 15, 13.) + CRLF = CR LF + ctext = may be folded + ")", "\" & CR, & including + linear-white-space> + CTL = ; ( 177, 127.) + date = 1*2DIGIT month 2DIGIT ; day month year + ; e.g. 20 Jun 82 + dates = orig-date ; Original + [ resent-date ] ; Forwarded + date-time = [ day "," ] date time ; dd mm yy + ; hh:mm:ss zzz + day = "Mon" / "Tue" / "Wed" / "Thu" + / "Fri" / "Sat" / "Sun" + delimiters = specials / linear-white-space / comment + destination = "To" ":" 1#address ; Primary + / "Resent-To" ":" 1#address + / "cc" ":" 1#address ; Secondary + / "Resent-cc" ":" 1#address + / "bcc" ":" #address ; Blind carbon + / "Resent-bcc" ":" #address + DIGIT = ; ( 60- 71, 48.- 57.) + domain = sub-domain *("." sub-domain) + domain-literal = "[" *(dtext / quoted-pair) "]" + domain-ref = atom ; symbolic reference + dtext = may be folded + "]", "\" & CR, & including + linear-white-space> + extension-field = + + + + August 13, 1982 - 44 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + field = field-name ":" [ field-body ] CRLF + fields = dates ; Creation time, + source ; author id & one + 1*destination ; address required + *optional-field ; others optional + field-body = field-body-contents + [CRLF LWSP-char field-body] + field-body-contents = + + field-name = 1* + group = phrase ":" [#mailbox] ";" + hour = 2DIGIT ":" 2DIGIT [":" 2DIGIT] + ; 00:00:00 - 23:59:59 + HTAB = ; ( 11, 9.) + LF = ; ( 12, 10.) + linear-white-space = 1*([CRLF] LWSP-char) ; semantics = SPACE + ; CRLF => folding + local-part = word *("." word) ; uninterpreted + ; case-preserved + LWSP-char = SPACE / HTAB ; semantics = SPACE + mailbox = addr-spec ; simple address + / phrase route-addr ; name & addr-spec + message = fields *( CRLF *text ) ; Everything after + ; first null line + ; is message body + month = "Jan" / "Feb" / "Mar" / "Apr" + / "May" / "Jun" / "Jul" / "Aug" + / "Sep" / "Oct" / "Nov" / "Dec" + msg-id = "<" addr-spec ">" ; Unique message id + optional-field = + / "Message-ID" ":" msg-id + / "Resent-Message-ID" ":" msg-id + / "In-Reply-To" ":" *(phrase / msg-id) + / "References" ":" *(phrase / msg-id) + / "Keywords" ":" #phrase + / "Subject" ":" *text + / "Comments" ":" *text + / "Encrypted" ":" 1#2word + / extension-field ; To be defined + / user-defined-field ; May be pre-empted + orig-date = "Date" ":" date-time + originator = authentic ; authenticated addr + [ "Reply-To" ":" 1#address] ) + phrase = 1*word ; Sequence of words + + + + + August 13, 1982 - 45 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + qtext = , ; => may be folded + "\" & CR, and including + linear-white-space> + quoted-pair = "\" CHAR ; may quote any char + quoted-string = <"> *(qtext/quoted-pair) <">; Regular qtext or + ; quoted chars. + received = "Received" ":" ; one per relay + ["from" domain] ; sending host + ["by" domain] ; receiving host + ["via" atom] ; physical path + *("with" atom) ; link/mail protocol + ["id" msg-id] ; receiver msg id + ["for" addr-spec] ; initial form + ";" date-time ; time received + + resent = resent-authentic + [ "Resent-Reply-To" ":" 1#address] ) + resent-authentic = + = "Resent-From" ":" mailbox + / ( "Resent-Sender" ":" mailbox + "Resent-From" ":" 1#mailbox ) + resent-date = "Resent-Date" ":" date-time + return = "Return-path" ":" route-addr ; return address + route = 1#("@" domain) ":" ; path-relative + route-addr = "<" [route] addr-spec ">" + source = [ trace ] ; net traversals + originator ; original mail + [ resent ] ; forwarded + SPACE = ; ( 40, 32.) + specials = "(" / ")" / "<" / ">" / "@" ; Must be in quoted- + / "," / ";" / ":" / "\" / <"> ; string, to use + / "." / "[" / "]" ; within a word. + sub-domain = domain-ref / domain-literal + text = atoms, specials, + CR & bare LF, but NOT ; comments and + including CRLF> ; quoted-strings are + ; NOT recognized. + time = hour zone ; ANSI and Military + trace = return ; path to sender + 1*received ; receipt tags + user-defined-field = + + word = atom / quoted-string + + + + + August 13, 1982 - 46 - RFC #822 + + + + Standard for ARPA Internet Text Messages + + + zone = "UT" / "GMT" ; Universal Time + ; North American : UT + / "EST" / "EDT" ; Eastern: - 5/ - 4 + / "CST" / "CDT" ; Central: - 6/ - 5 + / "MST" / "MDT" ; Mountain: - 7/ - 6 + / "PST" / "PDT" ; Pacific: - 8/ - 7 + / 1ALPHA ; Military: Z = UT; + <"> = ; ( 42, 34.) + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + August 13, 1982 - 47 - RFC #822 + diff --git a/RFCs/rfc974.txt b/RFCs/rfc974.txt new file mode 100644 index 0000000..97d79a4 --- /dev/null +++ b/RFCs/rfc974.txt @@ -0,0 +1,399 @@ + + +Network Working Group Craig Partridge +Request for Comments: 974 CSNET CIC BBN Laboratories Inc + January 1986 + + MAIL ROUTING AND THE DOMAIN SYSTEM + + +Status of this Memo + + This RFC presents a description of how mail systems on the Internet + are expected to route messages based on information from the domain + system described in RFCs 882, 883 and 973. Distribution of this memo + is unlimited. + +Introduction + + The purpose of this memo is to explain how mailers are to decide how + to route a message addressed to a given Internet domain name. This + involves a discussion of how mailers interpret MX RRs, which are used + for message routing. Note that this memo makes no statement about + how mailers are to deal with MB and MG RRs, which are used for + interpreting mailbox names. + + Under RFC-882 and RFC-883 certain assumptions about mail addresses + have been changed. Up to now, one could usually assume that if a + message was addressed to a mailbox, for example, at LOKI.BBN.COM, + that one could just open an SMTP connection to LOKI.BBN.COM and pass + the message along. This system broke down in certain situations, + such as for certain UUCP and CSNET hosts which were not directly + attached to the Internet, but these hosts could be handled as special + cases in configuration files (for example, most mailers were set up + to automatically forward mail addressed to a CSNET host to + CSNET-RELAY.ARPA). + + Under domains, one cannot simply open a connection to LOKI.BBN.COM, + but must instead ask the domain system where messages to LOKI.BBN.COM + are to be delivered. And the domain system may direct a mailer to + deliver messages to an entirely different host, such as SH.CS.NET. + Or, in a more complicated case, the mailer may learn that it has a + choice of routes to LOKI.BBN.COM. This memo is essentially a set of + guidelines on how mailers should behave in this more complex world. + + Readers are expected to be familiar with RFCs 882, 883, and the + updates to them (e.g., RFC-973). + + + + + + + + + +Partridge [Page 1] + + + +RFC 974 January 1986 +Mail Routing and the Domain System + + +What the Domain Servers Know + + The domain servers store information as a series of resource records + (RRs), each of which contains a particular piece of information about + a given domain name (which is usually, but not always, a host). The + simplest way to think of a RR is as a typed pair of datum, a domain + name matched with relevant data, and stored with some additional type + information to help systems determine when the RR is relevant. For + the purposes of message routing, the system stores RRs known as MX + RRs. Each MX matches a domain name with two pieces of data, a + preference value (an unsigned 16-bit integer), and the name of a + host. The preference number is used to indicate in what order the + mailer should attempt deliver to the MX hosts, with the lowest + numbered MX being the one to try first. Multiple MXs with the same + preference are permitted and have the same priority. + + In addition to mail information, the servers store certain other + types of RR's which mailers may encounter or choose to use. These + are: the canonical name (CNAME) RR, which simply states that the + domain name queried for is actually an alias for another domain name, + which is the proper, or canonical, name; and the Well Known Service + (WKS) RR, which stores information about network services (such as + SMTP) a given domain name supports. + +General Routing Guidelines + + Before delving into a detailed discussion of how mailers are expected + to do mail routing, it would seem to make sense to give a brief + overview of how this memo is approaching the problems that routing + poses. + + The first major principle is derived from the definition of the + preference field in MX records, and is intended to prevent mail + looping. If the mailer is on a host which is listed as an MX for the + destination host, the mailer may only deliver to an MX which has a + lower preference count than its own host. + + It is also possible to cause mail looping because routing information + is out of date or incomplete. Out of date information is only a + problem when domain tables are changed. The changes will not be + known to all affected hosts until their resolver caches time out. + There is no way to ensure that this will not happen short of + requiring mailers and their resolvers to always send their queries to + an authoritative server, and never use data stored in a cache. This + is an impractical solution, since eliminating resolver caching would + make mailing inordinately expensive. What is more, the out-of-date + RR problem should not happen if, when a domain table is changed, + + +Partridge [Page 2] + + + +RFC 974 January 1986 +Mail Routing and the Domain System + + + affected hosts (those in the list of MXs) have their resolver caches + flushed. In other words, given proper precautions, mail looping as a + result of domain information should be avoidable, without requiring + mailers to query authoritative servers. (The appropriate precaution + is to check with a host's administrator before adding that host to a + list of MXs). + + The incomplete data problem also requires some care when handling + domain queries. If the answer section of a query is incomplete + critical MX RRs may be left out. This may result in mail looping, or + in a message being mistakenly labelled undeliverable. As a result, + mailers may only accept responses from the domain system which have + complete answer sections. Note that this entire problem can be + avoided by only using virtual circuits for queries, but since this + situation is likely to be very rare and datagrams are the preferred + way to interact with the domain system, implementors should probably + just ensure that their mailer will repeat a query with virtual + circuits should the truncation bit ever be set. + +Determining Where to Send a Message + + The explanation of how mailers should decide how to route a message + is discussed in terms of the problem of a mailer on a host with + domain name LOCAL trying to deliver a message addressed to the domain + name REMOTE. Both LOCAL and REMOTE are assumed to be syntactically + correct domain names. Furthermore, LOCAL is assumed to be the + official name for the host on which the mailer resides (i.e., it is + not a alias). + +Issuing a Query + + The first step for the mailer at LOCAL is to issue a query for MX RRs + for REMOTE. It is strongly urged that this step be taken every time + a mailer attempts to send the message. The hope is that changes in + the domain database will rapidly be used by mailers, and thus domain + administrators will be able to re-route in-transit messages for + defective hosts by simply changing their domain databases. + + Certain responses to the query are considered errors: + + Getting no response to the query. The domain server the mailer + queried never sends anything back. (This is distinct from an + answer which contains no answers to the query, which is not an + error). + + Getting a response in which the truncation field of the header is + + + +Partridge [Page 3] + + + +RFC 974 January 1986 +Mail Routing and the Domain System + + + set. (Recall discussion of incomplete queries above). Mailers + may not use responses of this type, and should repeat the query + using virtual circuits instead of datagrams. + + Getting a response in which the response code is non-zero. + + Mailers are expected to do something reasonable in the face of an + error. The behaviour for each type of error is not specified here, + but implementors should note that different types of errors should + probably be treated differently. For example, a response code of + "non-existent domain" should probably cause the message to be + returned to the sender as invalid, while a response code of "server + failure" should probably cause the message to be retried later. + + There is one other special case. If the response contains an answer + which is a CNAME RR, it indicates that REMOTE is actually an alias + for some other domain name. The query should be repeated with the + canonical domain name. + + If the response does not contain an error response, and does not + contain aliases, its answer section should be a (possibly zero + length) list of MX RRs for domain name REMOTE (or REMOTE's true + domain name if REMOTE was a alias). The next section describes how + this list is interpreted. + +Interpreting the List of MX RRs + + NOTE: This section only discusses how mailers choose which names to + try to deliver a message to, working from a list of RR's. It does + not discuss how the mailers actually make delivery. Where ever + delivering a message is mentioned, all that is meant is that the + mailer should do whatever it needs to do to transfer a message to a + remote site, given a domain name for that site. (For example, an + SMTP mailer will try to get an address for the domain name, which + involves another query to the domain system, and then, if it gets an + address, connect to the SMTP TCP port). The mechanics of actually + transferring the message over the network to the address associated + with a given domain name is not within the scope of this memo. + + It is possible that the list of MXs in the response to the query will + be empty. This is a special case. If the list is empty, mailers + should treat it as if it contained one RR, an MX RR with a preference + value of 0, and a host name of REMOTE. (I.e., REMOTE is its only + MX). In addition, the mailer should do no further processing on the + list, but should attempt to deliver the message to REMOTE. The idea + + + + +Partridge [Page 4] + + + +RFC 974 January 1986 +Mail Routing and the Domain System + + + here is that if a domain fails to advertise any information about a + particular name we will give it the benefit of the doubt and attempt + delivery. + + If the list is not empty, the mailer should remove irrelevant RR's + from the list according to the following steps. Note that the order + is significant. + + For each MX, a WKS query should be issued to see if the domain + name listed actually supports the mail service desired. MX RRs + which list domain names which do not support the service should be + discarded. This step is optional, but strongly encouraged. + + If the domain name LOCAL is listed as an MX RR, all MX RRs with a + preference value greater than or equal to that of LOCAL's must be + discarded. + + After removing irrelevant RRs, the list can again be empty. This is + now an error condition and can occur in several ways. The simplest + case is that the WKS queries have discovered that none of the hosts + listed supports the mail service desired. The message is thus deemed + undeliverable, though extremely persistent mail systems might want to + try a delivery to REMOTE's address (if it exists) before returning + the message. Another, more dangerous, possibility is that the domain + system believes that LOCAL is handling message for REMOTE, but the + mailer on LOCAL is not set up to handle mail for REMOTE. For + example, if the domain system lists LOCAL as the only MX for REMOTE, + LOCAL will delete all the entries in the list. But LOCAL is + presumably querying the domain system because it didn't know what to + do with a message addressed to REMOTE. Clearly something is wrong. + How a mailer chooses to handle these situations is to some extent + implementation dependent, and is thus left to the implementor's + discretion. + + If the list of MX RRs is not empty, the mailer should try to deliver + the message to the MXs in order (lowest preference value tried + first). The mailer is required to attempt delivery to the lowest + valued MX. Implementors are encouraged to write mailers so that they + try the MXs in order until one of the MXs accepts the message, or all + the MXs have been tried. A somewhat less demanding system, in which + a fixed number of MXs is tried, is also reasonable. Note that + multiple MXs may have the same preference value. In this case, all + MXs at with a given value must be tried before any of a higher value + are tried. In addition, in the special case in which there are + several MXs with the lowest preference value, all of them should be + tried before a message is deemed undeliverable. + + + +Partridge [Page 5] + + + +RFC 974 January 1986 +Mail Routing and the Domain System + + +Minor Special Issues + + There are a couple of special issues left out of the preceding + section because they complicated the discussion. They are treated + here in no particular order. + + Wildcard names, those containing the character '*' in them, may be + used for mail routing. There are likely to be servers on the network + which simply state that any mail to a domain is to be routed through + a relay. For example, at the time that this RFC is being written, all + mail to hosts in the domain IL is routed through RELAY.CS.NET. This + is done by creating a wildcard RR, which states that *.IL has an MX + of RELAY.CS.NET. This should be transparent to the mailer since the + domain servers will hide this wildcard match. (If it matches *.IL + with HUJI.IL for example, a domain server will return an RR + containing HUJI.IL, not *.IL). If by some accident a mailer receives + an RR with a wildcard domain name in its name or data section it + should discard the RR. + + Note that the algorithm to delete irrelevant RRs breaks if LOCAL has + a alias and the alias is listed in the MX records for REMOTE. (E.g. + REMOTE has an MX of ALIAS, where ALIAS has a CNAME of LOCAL). This + can be avoided if aliases are never used in the data section of MX + RRs. + + Implementors should understand that the query and interpretation of + the query is only performed for REMOTE. It is not repeated for the + MX RRs listed for REMOTE. You cannot try to support more extravagant + mail routing by building a chain of MXs. (E.g. UNIX.BBN.COM is an MX + for RELAY.CS.NET and RELAY.CS.NET is an MX for all the hosts in .IL, + but this does not mean that UNIX.BBN.COM accepts any responsibility + for mail for .IL). + + Finally, it should be noted that this is a standard for routing on + the Internet. Mailers serving hosts which lie on multiple networks + will presumably have to make some decisions about which network to + route through. This decision making is outside the scope of this + memo, although mailers may well use the domain system to help them + decide. However, once a mailer decides to deliver a message via the + Internet it must apply these rules to route the message. + + + + + + + + + +Partridge [Page 6] + + + +RFC 974 January 1986 +Mail Routing and the Domain System + + +Examples + + To illustrate the discussion above, here are three examples of how + mailers should route messages. All examples work with the following + database: + + A.EXAMPLE.ORG IN MX 10 A.EXAMPLE.ORG + A.EXAMPLE.ORG IN MX 15 B.EXAMPLE.ORG + A.EXAMPLE.ORG IN MX 20 C.EXAMPLE.ORG + A.EXAMPLE.ORG IN WKS 10.0.0.1 TCP SMTP + + B.EXAMPLE.ORG IN MX 0 B.EXAMPLE.ORG + B.EXAMPLE.ORG IN MX 10 C.EXAMPLE.ORG + B.EXAMPLE.ORG IN WKS 10.0.0.2 TCP SMTP + + C.EXAMPLE.ORG IN MX 0 C.EXAMPLE.ORG + C.EXAMPLE.ORG IN WKS 10.0.0.3 TCP SMTP + + D.EXAMPLE.ORG IN MX 0 D.EXAMPLE.ORG + D.EXAMPLE.ORG IN MX 0 C.EXAMPLE.ORG + D.EXAMPLE.ORG IN WKS 10.0.0.4 TCP SMTP + + In the first example, an SMTP mailer on D.EXAMPLE.ORG is trying to + deliver a message addressed to A.EXAMPLE.ORG. From the answer to its + query, it learns that A.EXAMPLE.ORG has three MX RRs. D.EXAMPLE.ORG + is not one of the MX RRs and all three MXs support SMTP mail + (determined from the WKS entries), so none of the MXs are eliminated. + The mailer is obliged to try to deliver to A.EXAMPLE.ORG as the + lowest valued MX. If it cannot reach A.EXAMPLE.ORG it can (but is + not required to) try B.EXAMPLE.ORG. and if B.EXAMPLE.ORG is not + responding, it can try C.EXAMPLE.ORG. + + In the second example, the mailer is on B.EXAMPLE.ORG, and is again + trying to deliver a message addressed to A.EXAMPLE.ORG. There are + once again three MX RRs for A.EXAMPLE.ORG, but in this case the + mailer must discard the RRs for itself and C.EXAMPLE.ORG (because the + MX RR for C.EXAMPLE.ORG has a higher preference value than the RR for + B.EXAMPLE.ORG). It is left only with the RR for A.EXAMPLE.ORG, and + can only try delivery to A.EXAMPLE.ORG. + + In the third example, consider a mailer on A.EXAMPLE.ORG trying to + deliver a message to D.EXAMPLE.ORG. In this case there are only two + MX RRs, both with the same preference value. Either MX will accept + messages for D.EXAMPLE.ORG. The mailer should try one MX first (which + one is up to the mailer, though D.EXAMPLE.ORG seems most reasonable), + and if that delivery fails should try the other MX (e.g. + C.EXAMPLE.ORG). + + +Partridge [Page 7] + diff --git a/Webseiten/Docker - Build, Ship, and Run Any App, Anywhere.html b/Webseiten/Docker - Build, Ship, and Run Any App, Anywhere.html new file mode 100644 index 0000000..5d41885 --- /dev/null +++ b/Webseiten/Docker - Build, Ship, and Run Any App, Anywhere.html @@ -0,0 +1,716 @@ + + + + + + + + + + + + + + + + + + + + + + Docker - Build, Ship, and Run Any App, Anywhere + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+
+ + + + + + + +Get Started +
+
+
+ +
+
+
+
+
+
+
+
+
+
+

Build, Ship, Run

+ +

An open platform for distributed applications for developers and sysadmins

+ +

Get Started with Docker

+ +
+
+
+ +
+
+
    +
  • +

    #SwarmWeek Wrap Up!

    +

    Thanks for joining us for #SwarmWeek. Here is a recap of some useful tutorials, case studies and articles all about Swarm.

    +Catch up on the news »
    +
    • +
  • +

    Get Trial Access to Docker Datacenter

    +

    Docker Datacenter brings container management and deployment services to enterprises with a production-ready platform supported by Docker and hosted locally behind the firewall.

    + Sign up for a 30-day trial now » +
    • +
+
+
+
+
+
+
+

The Docker Solution

+ docker platform
+
+ + + +
+
+

Docker runs any app, anywhere. Those apps can be managed on-premises or in the cloud with Docker Universal Control Plane and Docker Cloud.

+Get started On-PremisesGet started In-Cloud
+
+
+
+
+
+
+

Why Docker?

+

Achieve agility and control for Development and IT Operations teams to build, ship, and run any app, anywhere

+ + + +
+
+ Learn about common use cases for Docker
+
+
+
+
+ +
+
+

Docker Use Cases

Enterprises are using the Docker Containers-as-a-Service platform within their enterprise. Here are some of the main use cases. To learn more just click the buttons underneath each.

+ +
+
+ +
+
+
+ +
+
+
+
+
+
+
+

+

+
+
+
+
+
+
+ +
+
+
+
+
+
Docker
+
+
+
+
+
+
+
+
+
+
+
Connect
+

Subscribe to our newsletter

+
+ +
+ +
+
+
Related Links
+
+
+ +
+
+
+
+

© 2016 Docker

+ +
+
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + +
Docker - Build, Ship, and Run Any App, Anywherehttps://darkmail.info/downloads/dark-internet-mailThunderbird — Software made to make email easier. OpenBSD 5.3OpenSMTPDwww.radicati.com/wp/wp-content/uploads/2013/04/EmaOpen Source - Sendmail.comThe GNU Privacy GuardTor Browsertorbirdy – Tor Bug Tracker & WikiHaraka SMTP Email Server \ No newline at end of file diff --git a/Webseiten/Docker - Build, Ship, and Run Any App, Anywhere_files/Logo-Docker.svg b/Webseiten/Docker - Build, Ship, and Run Any App, Anywhere_files/Logo-Docker.svg new file mode 100644 index 0000000..1b0a162 --- /dev/null +++ b/Webseiten/Docker - Build, Ship, and Run Any App, Anywhere_files/Logo-Docker.svg @@ -0,0 +1,108 @@ + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/Webseiten/Docker - Build, Ship, and Run Any App, Anywhere_files/Swarmnado-357x627-15.gif b/Webseiten/Docker - Build, Ship, and Run Any App, Anywhere_files/Swarmnado-357x627-15.gif new file mode 100644 index 0000000000000000000000000000000000000000..a5a76e45b3cfaf74af0236c3879eafa3ebfd536a GIT binary patch literal 938202 zcmaI7XIv9qw>LbKPH3SQ5kl_}LJiH(JA@938me?c?;1kyp$RBpq&E>oiU=AI5U?Sr zU=Iocii#D~OY?G_bMEszAD-X4zs$^@RrgwZ%73qIV`ptZ@DB##A#YCsk9XOPeKSIi zap>b`fgyHWb*ppCS!E@4fc`oD0y`(S^zjB8D7hDVYrXuz2LJ$G?y^M$_@zaJZ5>>@ zp8o)o9)v|FgjTKq%5ED!*-3-!{dW7)Uq5BL-hrWr@t21@5-4Zi4c%TI+1T^F_HuD? z5vOkxIR0|x*-l;Opoo&Tw5YVo=vU`!Tj8Vc&?g7I{KJI}y-Mm^MYOH?P)MSZF1M&W zAaDDU&GyY6fB*h{MEgH?Ha@|o*atAE__keD`dmcYM_#i~-PWh^ZJ&;IOvSgcWu>u# z%I4CI@8ZW_z;(R9^DGd>Uo!P7{=#nX;Jtgh?2yi90Zvg7gS&x)kFy8ZzP^6T+n-EL zOfrVDmn$Y*>(qjJK{6&WU0X92#bu78mTE=Ijxe77<7Yk~w6GHBK>1iK0XWC-`Gi zq9UW?4O2{H{DWcwf(`f2|LxY4!TuLXLWGHo*}pfi|LU}ei3`T+YUrs4YH4X<^$8kU zx(3>KT{SEor=_cjBWP;j)NxvdS~x>I4*Ne%W?x%eP>7+MrS<>l+P^Z92~9|#7;0)J zCnswpYiq>BozT=G5D1z$ye1y6zE7bZpBkOupQ0WeFZ&+}mcj9Xabc8%u$XA0Ph3yB$KhiQLFfl4PI>FA;L}vev zMo?Igp;mxC&LG&|U!9<3V4#k}>jbO&8xU~n2HFO?Iw3j+0Xo|H|B>_m;@8!}n^|h( ztSl|G&9t(>A$_U42}y+3J$W4i;2Si z*Ek!7{XcB*4>1VR^T*-U@p?M@85N|XuTBUK2~^h&&^8G24+t>82O7xy4}Z}AHGcn{ zr~5toeo+2njv+z&U)S}5)Pn-G_0+Yrf_2sX@!BEkfdqVjwyr@)5MEbXMswdp&3{wp z|4OC*bnWNozo-8@G4?P1cWMPk@6V^W{fPsz|Ni;s_phIOyFb2v`}*bc&Zmzbw%@A*39(O&B+PojqBrM*G8|7 z3=a)n8Mu6@|6<>T-k$ER&W`rB)|Te;jB`zm4QJ2P*VUe`sjjN5pqH1GmJ}Bi7UbvU z=48{dsHaY5W~8U3rX(jNCd9|ZQevW`A|t}XLQjMQ2L%TBlaC)e>UZR@uaCEvr-!?n zE6K&#$>a~3@;Bi7bltng+#z%P{{t{NBSoW4h2pDYWq(j;NO=7fMioo(Xw-L z^YRM{i;7E1%gX5$l~vU>r)%r#&zx;&Y&yp{-`vvL*51+C)!oy3q3>ex= z8@`?MSqcFB_)o$JaY0t6No^;I;N7kUGpthk2b1khk0}w+h`mO(~)1g6w+Zo*o}KXTByk8ynK*Q zv$5D=6t*Z-UklCWqe3|)w`*^%DnFSP$zC6md`>NpoE(`@^uoOt-h{nAHSN-{^x&xczoyx?8yr$0RzX&`edSbH9Ed<&^PDqjg_9_LxJokaHeD+|>oJQl;k zbfQl91Oy&@LaHCIg<(qrO6kZNiL_Z6`y{=0p|uhBh7^z4LSUV$0-(=xca^)#Z#iNN zCyv*ZpAJ`POI<{Gww*p!RAkHbL-~DoiuhAvGY_eMqpIV_yZ0`+uJ2^L`YO$v>IR%Q zJvsypK$V8#=wI)zEOm=}y3`0Cu=f;xxBej=TgqbQDe5p(TOPLeLu(4an!o z$@#tGGw_#T-uZ0G4CKR-$IM1TwU=LaXFrKICfrI}R{oAdc$*sRv4^-t1* z76)PWB6@&il)N7XM61mb!#y{%Aif7Yus9mGE)}{FFUA8} zhi!ra0jzAT9RTSxb%tBFS#oMC7qS~h{Q=vxkZdJ$+3bM)2xbnBpIHuNm+PAf9~;q~UdPGt-=5bmoW zB(d^2m#+?#`ZF?j_y-G~+CW8l&1%f;#ra&{W{C@Q*^d2luR`L^3-sWum5@*6>A{i^ zQ864;N~z-bgvY&F#Lc_WG?bD5T>Co-ANx$p1-wLOrGUpQ+!XVmVBk)x&W4z^0*VDF zC{ZIvz8<_^&~CrS(Md#xw{6hd!A_8u_T%SW%3;1rm)?9-ZJYg9LT{O*=uNO;4oFL@ zhGT=xIBiKel|`!rm{XU%_q^M|iV#CCZr9>oJ?u%~gEAp*&B6f=NGg#b$bt#ZUz@H@ zc~{`F>PiU=*@ZU4?_H$QZjZ+K#f_X9?bmF=9WE1v{)`cx8rhNih6nSq0n!(EUBiYe zq553c==U!5(g^og^By(t6wUB2x&>s#dHY_3(02VLeBBqOMKRyYBcfD~)^@M7<%KYc zOYentsw~e~*DxyoV9@Ua^sa|nnY?H&97uTA&y_-isMLX|Jggg!l`zBElg2N4B)3x7 z%;TYdr~aUO-NaP8(Vqk!qV_GXgHA%1C13N6#@P@H<36Yo3|E~$RLk=iOaN9`P<(9X zY1_PTn;bFR*32GAPjamlBi+_~GIZ=>Yr(mmFu>l-)9*H3k70zr6PF3EoLtQ|ZYho~ zFh=p~`D^ODXuOzWao7VgMueLh(AZpiH5wvXR@&cUCnMd_-dPIC-do`{CTW2>zZ-VE zWq;m2-|g{ynif8x7P@0RtwcrbvCuLL5sP#W*4-(Q^t})L5eIPH=7_?EWAG^V)82ic zQFvBUWemMT{LBvCX9j<74d5X=!5d;n={K|LjHVm(=5|N+q~o45CFCs)^}U$A?#(CIav)-sdN>T03tQ@}l z><0Ms8HG9J{BqHzIdWrkhL0N#nDbXssa~8+qzWL*02}8-JieliSzi(VJe6-6vDraPP=i`s-FQbOz z<^!7_^;ITh=_vB7na$hlCg$%AC`#Ly-uOg)xD-e-# zOg4xku5pox@MFxcO}iNYQHlyEP><#ud2BBpIC9L=kr&W>a%$*t2Lz@16={lCpVK$tiYo~n z9B2dwVL)1TJIb4VV5$;drer<1|lXWR5 z-rgWt6AOdhvI&!SGQs59P(pR%PQ62tJcF$6PKT)uD9Z)Oo5Kk7G_0!@((fZ{?k=AwWc+a$ z>u6IrU0}jPQoZb+xWJ!{K>>K`;d$@0x7O7ACmhywfe|GTi3Rk$LGxs`C5i;v>=X&N z@XN3w__1l!(BjxzrJM#HPeh#@Ny+$~;`Fb&Me<%sIV!KdQhw*!ck86zwe_`Z$4}QK zDfheD*`{eSgB85X*S|v?l|Y@1>UEjP)iLSh+mM&s*r6d2+CaBvF(cR3fLMAB=+r_209F=qEMJ22oq^&DN zH^Qo9*X)&d%=NIaPX(20Uf`}^v`bxFP<8&s8zXIk*A>XA&oC>Rr%-%8C0|XcCZsg@QXxigpT;mVTYQxH zWciO86PYfJz67`_4*G?VtW5z-mCCfRF#hg%>Ew9xj`(-=b^HrWX%nD@phpVf9EwqC z9(;}}b=m z!aCjA=b+@hz7l`p zjhlSVEl)q7=x%N879lR*u2uL<(}-_0k_GnHS(O*YXj9vO{0cyyqPo*SWnzargu+|% zl@ksZ0*VfS=QmSN{n!QLGEhJ4YkMN4ama515;0%CMz%wj{}fR3Gl zkQj-cnAqs}`ScmtT4UYp)TuLZ!|ZOG(Tcvqt;f3JwHY<0vlV=FxD19MOorN`6DqoT zoWv5wyJI>J_s)nrne2pLdm@?iK)vf*Z+*A013rrS$j9TG{!2)Z@U*7^3-kq&UJ;`A zX1WV}`wq;VaVjh}B|(qu^!cNTbZ3E|h|b*lnDwrV*PGcD$@!3li*>sfP03(QXKoT* z;JT~qy&|{w-x}D|^ad59l3CQN%<3n@ zFCDj6@4EsQt?y3oF3S&N=f`-1HaQnn$bm=zs!Xv4U_iKN+Ped!Q%g@CX}zmkx#X3Ov%qsp<3z&0?K&yixcwCu`4L1dq6&!q!mP^ZGd z)U_-$7P7FCGBR2;^DO)@A+@KI@!q%W@wMQCxuYjJ{E-XD)3;4u-|S5~Yohsv@@>KP zW@o*eW#Z-A_5!zqwa8hW9hZWSlu4xKc$2O|uj&gkAe4uu&`l)u}<7H=C0o#GD zbU>EVQo%s+!KkS2B>deGvo(+Q9dhoc2z>Wi`E`e*&PGtMAg#9`M*V#a=55vyCen`; zcU`{}YCP0>jopnRHMv|J(hV)!4CysWi3p?zYV6AGxC=ab>h(>3V(~EVxiqP_+9M8^ z8XP$F;YDYZa0t^PfESVcExf|T5X3Xi;UusEN8%1fbO^`&2Rhfh1W0PlAjvVhbKzR7(a5$Pcw)I*A2k~{uSxK?{w?ay@F%YPMH9t`!o!JyAK5*w8xoV7++tk6Zw7JRx%+PEy2Ec!klHAC>w?qyMsfJer>FNm zK0oqO=RgP<@|6olz`@kU7v*)`G@aa5bz$EdV47q|XmAk>8=7N1>7U?W7MdCTq?~Y= zcCnX->o+KVVKz_AYY;l^=#g32Tc+tZo!cQ0?3W+jdq>JQ8rvWK{m!ENv~&PPY84)+ zCG2GUp=DtTws_}k&Sd@M$~>!5cMDggh=Z7YQ%YGZ@$k@5_OP)^0np3`=9ROzX>5ot zm05Ck&M$I&_i;5kZ3zpw*$zhSN*^PVA$vK|r$wMgfaS1&3t76i&EGG)V&1ysF#AyG z-Y@<14l!JxAkZBaXhZ5s7*M!5Hn;db`$0s6-*zJ-Jzr(v4h(lpodhRQ5qG%ZUP-|X z)o>qXh?Ln=PW5ms+S zuy|azpje@(`eYbHq5p90A8=sM|Fte`G{?&81$OXxy~ns z5)gdqo0HQHX^V`TRe5Tg4b5ahS@S*3s(=cq>7GvWgJK}(=Y7J3S3?TylO5?E>U62g zZLk0q{3=ae#`i@Sn#A|aL_C8#{dqZ0|MEjO)v#a7#+Y~o7WC8}*?&1px8H%Poh|Cy z^liQ7VntI>R*1{ z*S)f#WWa_DC5b`rsJUFUK7F+m;?1D)W5DX_!#QFJqvEONiU3?9`cw|poK>1<8=(n6 z|5_eDxcDYhk?}S6L5H~nyO3LNvDY%wRXG2|t}CotVcZ6@VDzF5dtKW^9wLc_W|Bbx zIvm`9x}Aho-dpFjZ@cigqAuvz-4oB%!yp;m0eiKCwz5-+R&1lBGKD}lZo)Ud?hnS( zZ|v~^6wdM>EJFCi-kkXs{*K$gOF9HQ0hPf3c;Yr%6x6}43wCZF6nh02Pz5+LAqz-9 zK4o`(@5xz%SJ4tuYpi(^CNr)OeYEOo_Ej`1UkiZgfAly;f`?^N$2OsO?5f{)zJQQV zdrc5@Kir$NT~@X|d4@5ano2Zz!CiSQkIU0V;xl3(K`@5v=?CM|^ z#Cs8a^} zc0NA{C^tC(UU#?3C37P(E=7?6<8<$yj#2nZ6PY`-eA7jsuk}oUYTWLX@v{#PKjuIw zN;#*>O88+gfZzWCY^wl37=mihL~_CY1#DZ@)Z}PVQr*3Zirj({brp4h1W#Z8<)YKq zYcZ$(4`6$Qc?l(eoBxL+hXW^3hNNLQIZ=&-kNvXvnJ3>=WEH6Dz@X`2_rA zmuBk9Cj8m#V8l$>jn-1NIrqvXEmMy^*zW6DYBSVVFiWOFp*Q(64$z9pzU#@)l{;akME`8}losrPj8nEK~IcslwzK1 z59!!Gm*sw1IctnZ(WfvLS8&Vm5;B&P%B`r_TxTPH^DK?jk&TKlPv6T0lp~FbZ?v|$ zlnQ-1UCDu_#gVJfxUaGJn_P~toO4PhxL8YJC7+sE82}wxo8_TLC8vB=3Pm~dC2g(O zE>N)TrvW#5KGfN#{vq|Ccmgc}`&OUGt+ZXo4HJ~Jq(SAZX&cCa5maD_w(zf8p+6hg zd2}f6+qJ+$W-{0*&`Qz{Eud}7GE1U|PUnV%I@_&xj$I85j^_DC_+@wR(0q7z=;5&S zfL6ohw`LSK?<2gI+n8J7is(2RH0$N;1Ttf^uIgYCCVVrs;3)?OEcHqpjeq(yoO-Yv zkLlX~XC=3`oktO~AqLwkPdd;|_3fRHAFF&C`*!+WNPzZuoKM3VKQ0@d`2{wC>g}IY zlE+x)Jdr05zHXP?8_9PMgUeP2!~)+|Z*sjvJXsuB<6+$tO0vCOkR!%o*b1I$RF)s} zc&YN$?E7W6+yr$l5QZB4;b6}T37W{BTj9!h%Ax+!0HWsKxV>}peAc5bS`vhfsW{6` z?xn&cZ0vc6rUJ|!m}8kY2Vfi-J1uynw+h3(9}+ z{>I!9f5omzKF~6ngGW;0JY*Sy;=9SEP)D~C7Vz`WdZs+%%lby7#UATQl>=Pt;!fZZw^eoQttk4ex*QgQ1ZP zQ$g9&-&q`((K18v)3eef7LjruL_me^0$0IN!Ee!s0i#Ji9^%;G92=V|&&o1&%Y)Xa zR3c*EO4oaQi#r#yT!gkQ=x#pJ&(6`n*% zMzpmnDgz8)<0e(?d48nQV@+5Zrvd3;Y<_O!^MMA!ZC96>)j$O4!tR3)q9p zS=oXT{zXuR;8jr^)h-N&$b_v(yh$Du@Z*xRUs=MQ3z-VuUJt_H?@mneTlTuHNgAN2 zAKMM2w7up}{93)g(DXVBnh{77!c0aU)@N!}UMe|CY(YfOb5&b`#OwqFu}+mMSjIQXK16mB@RuvtbN#QbJnxWA_q*#fcNxiJNdbf; zJ{~y-JgG<-Y*lyx1<-Y7qyl9C-A%2n5NC1DDpAEG{JH2B=j?>FKrBZWwe+k%_n%Z4 z(XF3m#_?3C@kxQX5dH$!~-3Y`Mwntf;Z3w2st=OBgoWx1SW)459{{r>Mz8JNu{ z{Uj31m`*dV!$NYI^BHM(5H>3i^y0dR#5XheswleBeBxHXJ7?6~l`c$%NH)h)GAI5! zXA?jFJ?Hf>pT{}WgNA3Ey3A%Xchcv*Kh@}bVPH8`xEGB>jtT*?l2Uq zINYPy1t|)Zk|2T>cZ209-aJE{3|pNm?DH@$${n;!l>q7cdj%$(P-I%wQ@htK@Y<$4 zq@u=J;0)~TsJ(3xiUzevfbop*Ef4B^-%l#)UVs50PItW2wLdEfS&jh;+6ey6cVzEw zh*Xd?{1>TLb|DGa@qLhI)42^(w{_`?Ywo_iU7j!ix%)unLLAo|+Qy~F348f<^XE6T zzbec0t$^kn1LmY?By*1Pa0lQwfOt$ia&!2s0tq%c2=w*CVvY_$JgpQwes-EoXe2szAkG-pZZzuH@VYF zIVf9zVR_dE5yU+1j05PXe)1>1&%`ckon{Cb;Lp)}*(-57zZ(Q}Y|>i3Cw*(FA)Ujd zySe4~Avl#-*_DbU=nE^xrAyKZ(Xw@pw^f$Z6EivD{7cFozR|3`o<=ldK|rEvgt%w`Qz|WvVz! zZTeMRe)ld7lEPqL{u?XJNeuW*k^f$L`>$vBYy*pH6Bcv>CH_Qqd{33-Ai4C;N5>jr zH}SNn+;VO5spsqjrzjJ4DffQ+pXaP`MFXC7FIJu2pv*~gLY{gE9InfVFG_86&+GAd z8QZ>1%4>xPam^KJiS8EezKG%azBx^|oO=I?dCahi^ zSl=3d{B7^nxrcAsYWiM3z+}Pu=-C@O4ETnvTVi3Cb-oNE?}o)C`{?Td!%TTQn>v7Z z$GPy~`coRuP~@0zY53W{ctJ;$3G~NL`%CPPTQ22h4{sgyqx=LW23uMVdh@(IpYHqa z*}-|f3{0vR+i!8@oZ(YBt$B2a{_i(f?+0EzW~l>_SqOw- zfrm!^9lmd{F0t)?T)1ex^@L4p^jnK?V@QHblJ8i%U;THo+8*y~Z^20q^!Zz`KS|yz ze8;`XF$wKQ1$6}V$RWNs1Re{qh&P{k8(4GGQt_swfaoF7P|Jm(tmBE0?XS+8C#0$u zp`HC~QTqxgv7e?;N2_1=p7)F<37Z$_LwVPA?WofdTe^w3I=3ad*2xHj2T49UDv z2^Tq>o8@JfmlLR%T_)Y3qw5;@(Ezj+I?-3bvy9Iq(gTu|l#fr*Ue(5b8_KtZXkdO~ z4X6-r7Sz+zYHo^VxOs8|QEEO5$ZD7PUeeX=FD(G5uY5Re4@X)A=}yvgvJ=YUy(?vE zF-yYSpOgf{DtIoELF9B*y@NqO)sLy99O_(WCGlLts3!SBaRiArah zJ%@;GXDwG?u6%2mXPB^ju&u>Iizu7J{{r| zW37j*)$HWQJS^D=IcU=1V|ZSuwW2~9Ab)SoP7sDhafIjAOI@B|%e~2UI4~!sC>_*` zJDio*5VDdX>0fl*S2tHD<6|AXv0h?TA04$KtxktceIx32Id=arnqNy$VagTwavC#& zg!|#1qDL`!X8~+Aq&52w4%q*KyCH@)p<9(asYBRMJP1dj&?3oH+0{_OpEr>~HHS}p zO*$@mC0 zsu*-ewEUW9OMq;t_s%&$T$)VaeNzqRr^3W_z#}Yhe<83C2XR|ffMcNogJrE%NQ7cn zhizv$$yRQ)LGh~>qQ=9VfKg|`BPXS;$N=AN&flqY@0}*-e338(jQ-UgWe-CT3-K6S z=Nr(Mcn)3LNL4}S24@=@9+g=@MlK=oK&#kKnfe4k4{*%TfrfZNMYdqGc^Co?M3TXq z1~{vErK4R!=fd#-qtz`j3JU>=`DiLIEV#K)RYAca?hjrFI@G8q zj{*?Lsvj{37YyXkLVx2lYSW%uN6$ucvhTrFNt>kx{$D2jpF>WBwLk!f)lTI>8UhaV z1fPM3^;e8QA?UM%;uwekop>aNLz&U}J*b3R%t&SlIrOzElL64(8y;W^6fh8%9jG(~ zjI%E^AJnyU^R}ZyNen?NI@FQ@Mu$UiLjz^jaSaoU{1Ble zz-WFOn|B5Q5KjQtp0-D)fmnw1T-&+xS9uzLgCqa~hCr}%s0emc3=nFK7i+a=loUJh zyu;k-YH+GL`S-B{fH-6O1>!n%1Fo+A+z^@cSv3}7wI zV(z;)B7=#{2tfD7v@XZ|5l&k)KvWE%G8sK)0OX&F0l~I*8#;9Q_6;*KM4bb#^;x2D zt#Lr5Utb477w0p+otwPa>il%vyS^bzU;V0kn<`)VtbI1*840=|fp>@7_haHb!sSPA z9Co0!>K)0XSSXMI5%Mq=2P&n(P14}rq( zCS6o6O8Q!@o0<9vIq4KtUH>WlF`px3$RWlQ`T#^YjI(eQf~9~_;bS?s`_ZI9IX8V{ zDny2Kdq@qE!2*@(5d6aJ>wdXXS$bDT`w0x|@W@!8A8y0w;Y(HK4c;gIKR~OUAdo^Ej2-+a~cvp`Ri!L@`2B0BP(z zT6G*uJS)KHk-Bq(fIW7+vSKfB0oAyWJU`R%dj@JJQH(>}_G6E6rCTr`j>+wS(Vfq#oPgq_y$6R9X zeXavwCLJ7}YX_a~RBjAmXmA|!j)Md^+4)c~7A|nNM=sRa=7ECZg0_|Gq|j31sXHBY zwu_2AG7CUsQNyCufLEbI>eyMh9uu%5pNWX|M#1g1q*XtU&0VGoECrNeDGxgw<^`}& zBysH5^LE6-rF#j3ztqO>{F3yzd*=`tKmri4I8~`Qx%zDd6In-Vr4uSds9mP)U74G# zXLHRy>dryjNtK`^06}2#8(XVP19Noco>?*G#?06#F4y~lW_{Aw74&b|Vmd6Vai!?) z3NMZ0$j%bC(+XSli79Ksg$_k9F5W*Yc(znZ>(T?Mg$Iw-EId8hW$igNWxP7MuZJHL z?){)JD|0nu0v^%~M^d^Yvixdqp98@O1Zu`P-|>u*$d7=ids!lBtA|YK&xuh0t>OOs z1<*6&-cuSx09du}1rZp~uJhm!6O>nhYf!La^P2h}4*RKNnlMSKbnm6hFS(zNFA1sb zPLA_M=+uHzeP%uh@_G!Dv;Z`DCMTVXYQMjVjiw{rqz4euVvf>d2#y!Ok34YeyRU#b zdk?n1RB@wu`;Gu{^==ZUEJfjh3QhbV`{3&jFT}>tG8L~OS?B(S?k@!1=9ckNE#>-f zRHypgVJT+UG5|hb-3YDXufQuah!!~=X4O8v3Zm`5Y-0F`gMPTTf9BV8T9$Z7z{BEI zdkGj}2R8qrU4#OgZcnPGt`u@Z3`R$acBFz{@4o?P$jLoyV#RLH(|d+N8^lC|AYDMtq4econeGiqrM-0U0Ges2j|R1@Qph ziAlaI;&vxIJ#^G#oqK$>BI@`Rmhq(k?3t+dHv1(>AKyN91V$tUdEP?P>Eo}Sy`S27 z?-Va%>x$!C1wOTmlz1MAcp!W!ob9VBoCHmwegDa=MFA={bpkZ7iCWq{EQrPq?6vd9 zXvY=ubpca7KV37;IpS4?K>_T}@z@() zV%xi46iOx!p-(pUPXxryq*0Ws5+8f(4>}%~3?0Y4W&Qe$WrHl|FXuH@O&2}}XF=03 z!{;SoNE|{8*ePbc`-E4qKd-1rf?HA0!A6*f>u6K<*MXt4S*h{-_ z7RQCGS9ZEFBCos~6~F5bO0hR&E*$%+FZDx%g^+dm;Tr+yP}fUeAQ=+xx;UXJ*$P)= zKHZo8bk!f!4=Q0S?1rYY->!~-RVh0gn^bIUP+D-GOW<;aMUgoCGG=lfs%d|*O6o+h zO#z85g)4dHY7` z?>pU1Kad9i5eSs2in$HH7Ss{8Ut(LLrY>bKrKqk}T3ZX{w}GOdDvc-zq>116)c=;) z_U&W4fZutX2a{f`Xjf}zA z#`v6stRRoGQ~)>k)P9NWcf~2i0Fo59GtU=PE0L08mMy^_N9-W2nsH*AjL*NG%sn8o z$1ZXjy>+SSti)k!wT56$ph!*i7!Jb-sG^D#rjgSGx1byjb#eUkt}Wt-=z~7bPKJzm zZ;Ne}Od}j@bU!*I!PP?V$m-9yS@vi$_f1gFi3L#!eoyd>o=c;s2L@Mt;fb@><(>ZT z55q28kU&#sSKC{Tmw7{v4=xi6jrYq-M&e~$3IpxFefiV)&oaD5Q9Mq9m7N`}0pPiE z4`M86IZ(~|Sr1EhH~B`xbQ~WmaAv{ToUap}Pb}bVV`f87yu13buhacRY^R~Ydz3~( zY(b~=s+A5*D6&e|!CoS1NQfsazBuTP*P9vb6gulBHBV7U`S!Bn$n`(JZ@&Fq!}k09 zr3wZpFhG>RooPaAu&Cpz9Py z`0y+fvr1LrN}cTFjf1XXI^n1VScA+KflMHLT6@(>j^R!#+kTI+uAI?;zz> z$>;7WI`da?dywNFvU%3v$-HUU@wSMPsA_Mt)P`UG1?4 zk2kMRwskg_%)fmQWvKnwU_}cPgoSczCs;g9?ujcnT6sZ|FN@byf?_45TtIEPaPBo3 z$t$zNM?~XWsc~q@oh%yMl**X6qka5rHi!E>^QPgpk^*n-Q4Q6EOwR_YYyBU)AayFi zkNROyToh||)+Ly34vVv{vgGtrJbzY?r?0r+T4tH;-SaDU#^`1VmHAK4>`jWA)Sb!e zOeRTJ*WB}H5*oZ?UcjG{!snhiW# z4-;<4=K+#*w2Ay{Jgb8vs4*;)t5~Yi)*1gmFS~o?;9=o{711+y`EE>n`0M)jbtWg^ z=Ja~%7B;?O%UF(1p+N=di%Paxjgi=o0UhKi(7$nQWJg2pGhE$X#zOSoj>h7prNzoy7T`J=4yRSS zCtT5Z=g*t|^i31*V|Z1gnz`PU353JF`~xmr&TNzx`8FW9oWGmOC;Zp^mS+E#EI!od z<8|{ljsEF?iAwmxSu0K4xTGA8Z~KdYb+^}iLM7s7$q-|i)h!K7j#MWPF^_8kUSfq6 z5Tuz%`}u9^4CUTh=L1IER*yD)lXFzTLJ*t&yxIdaH3qBX{+mhBhS(`DJTV=~6b(Pd z(om?jCTYz!E0(ni7ls9@^UXtg(08JI>3i>&XTG3Xd>4b#vLDxc2HvJc23HYw#J7O;XIprbUDY_h=5P4#R3gMk)LU6Ma z$3dL|DMoRua;NGng$dQr7wQ+; z5DmO54&04Q8d&pKW0Rlxu8^ZAVTFTKh}#UZrJ0H}CT1mBv9bh}m=Nze>Q>y2i|gxe zNNL<@4lfcE&ivSRZbFFH4VZOeBmpgMQL5_pt(V6bQCkA#(|u&plMA}T$K~b-z4$@| z1-L$0iu0f>ATbiVllt7ke2Y(P6HUH!rsOyNKayG&BZTV1?W=`qAr=rm>V)zkSqoUY>%?p;HRx}?J;#yy;cl{X;R!8>Zdx2yQ0RF+`Qi(e7e8VSj~^@Kpf3a8 z55A&juq8?dQ=vv)Iduwkx3atM@eVuZ9jH!p9WFKAo3FD*@kAudD_Mj5X3pLZg*(od~@ zr+yt=iUc`5^>8qmyBFyYGVA~$O90ytwkp#(();(y$Sv+icbHfk&DKkO02MAs{&?-+ zwuJE^$5DySU+o;IEYOiGF86Ka*61DXq!~r@(l_wb7I7=9>u#srM)S$4S!m<6s9;h( z>*d7K5OK}r;l?i=EhHh-y=uOl|mn#lzH;XzZl~v z3uPacQo76)v&WU}8s=YD@!Iy{v}n*!?AN>lR}F+7^A=!e-N#w)ybldtN}5l^1fAzS z!i-EIbo2=U-y1`IY`xx2=sopVCv{?!dHsp3USM%C$WVH9IN|z~UhIKIvrn}*&uc5= zkBM)2&G;iy=x}xYqp6?75>YQDN%3wb@7q2aBDH6K@|D-$VeD=lxPSdiYWDShyn6J~ z->(VOaN^rbmLG0h8a4^-&-rAtbIlW!+8deP(Uv9eaEMbWQ>sE$S1-fo_Q+YqhmNI6 z`zUUnK>s9fc{G0ho8dov|Bq9~$ZwXu6H3eA*ux9X&nFi3Z&Vm(KS5eGKk;#xabtar zUtr5$Uiz5n_B`!Fq`<2^Ty92V#nC!hXeJIJK!WCCwC^XYyO4ogdI)UN6iYg$+U~xH zv=hxvJHMPIDVo-lAJU*t6O%jE9&c!gbFS8p){X}g6X4qd;NQ2h3v`Fv(^`@^-=Qy| zoE@hwF;A`J39*sXL;4ZJA-+d2$E4PvI#>_6Denu*35NiPdnMG8?EFAq-cu%dQU7FU z2u*P|@m6zUfKT3G?{J@dL(k#72vL~wY^>^D##21#Lk^@`#zV;mH7P*w>H%L8k0Lz5 zbT9k6{-FuQoP3)cC0*(WBBm@s%XB}~9w)1kK_n}MTWNoDCy1criYe&A@N7d`PM$Q$ zR_t+XXQ*>mK~eo|@Y&EKP7_Fd>*Rbu`idF3Y{qU(zd*^YAV)DHSSPkHKclvaAQ+@o zks>ahVA$PW6djVqEvjonE!1D9@dM6l(`m6QMb9_W5G*L3%rmQhT$rV*dIBs(_?1r< z&&ZY3=yBNC#17N2k~lLeO-n?lsI#TiMIWoM5auKTVF~7nQ$Vq5=$nV7=(*r}KJe|T zSX~f*eHGl70W|A+zn?AZ#ig99K)Nf$z7VcZ!T{?9B|qx|qK8Xwnwvit)n)JLn9DxW77TB!haFaCLm>Yhk-H?yKzFZeUck1s6Wp`M7KfSz$Rlw`00Rr^LEIbTQZ z37+nIwe~Dr!vjiPJbfzQC-U?g!SOcU8#Uf_Q*cQ#C?sgEv7w_9c8sv2nxGt=C#U8@ zuh)l`X8f$D*yK8y=UgWv#gtFy*4s0cycHjbwI{-yHsh3khPejT`&_MezlFe&{TWZr zQg%ymtSWEeI$Br7weN!Cxk9@GE_HGcVW#Qw%4ys!+SyQJALVdQWc2l`jij%o0_1Ax zpGwnnWkIPDm}Cf6Oxf>W5CNK)L$59L$5LRAud?ax!+DWp`kCp*f5fodVfM$B{azF5 zy6n7jhxty}c`wGob+BN%R-@B~i!LG2Lj)4pAJg>Y-1V!*e##|<$!E+`EoLel|JD}V zUvkpHxz|+`x-gx^RBCp^&cDxz6(4P^pO9@ZJ3}itGkKLWFi4;EgcC!D!~_8mL$Tr* zn3o8|h@p<$X|4~o6;h#(`L;YyZE>$EuCundX4_=)u0@igRZ(1}R`lGhL=f8#mn1>r z$@tTItpaK14p<-cdT>Z7oi%JUtN^Ab8K~bO?x*ts2>0Blx zHYLJpi@L^r=|WfF4Wn&F;?3YMv1YWoAW7m?Qf$bmuiH}AJ~S$iLH3LHBx7|w>TAS> zVUK^Et`FD3BI}xp&PblIZz*bO0>N$Hb7J{zlA>TbtCw=7hJC4U>2Q_09_@8-%q{U! z0^`CfasL7)7P2v-H3bk=XOV9cYgJ6s3e!oW#Yd_oJ(!7 zLv)8e3Cgysvk)mTQ{qZ)k)2*jxcxONW(_oCXuRDQZdl5Hn}(pkqeuvq2=Qs{fwdvy z1HXIXTdI!QH?4QcMo+n3H8q4JR`F^q zBp`^0BlN&vYmz*(^8gFfVJ2*LfWJ;_R9+dO-S+Ks7(o!m4*(j&5n6#bq%V22>{=mT z|Am{Wr?8{!q3HFYS_iIZfPQ2MiohY?z4sHTzWy+M_y~5yINcpTe9}KXZ6>$p)it^c z00}0JdjsPt`+#3R7{1V_I~T*p==tYx#JJ&D}S8)f5dft*7scJI*zJcY}ki9@Kcq3a8#owV>-&i*yun( z{N6u{VnD2*l|U3~butj{*_-d#s;5z0XBY0?QJMV_TQ6$R%p;3Xu7(ZiA%6)pwb$01 z8?ZJSrOpErZ(1D%C2$@*SkTDnV|xJvkz++FV=gq@&o~?5<;}!mXip7H4NriBME8Jm zs)e%U^O4%W5hLM7dGhHXd>r~&qS3;SK*PA<6qRo8I?!`8bS#;7l_+EhHnz_7PH+ae zlr_1s2IQB;*u+L?uK8)$v&}Vsa*fZ`hd>J| zhCU;<97{lC#>9Lj6tAObstQeZ>|f9|iIY7^Gy~H;pLDK@OHr5-FanX~`H>A68=?m0 z4WU20Sb+)Y1a?$_u`Kwrrr%!E5!`u9d8z$Q0y=dTj7T8RVN}Efh!HFz=AFNf9k94I zgWC;a^8@MDJ%9o4!X;F`z-GphX<+7gP+JM;2aQof6viHF`OCboEUJ#$+`w;tDtjZ< zy*g&AQHDQN^rAw$ZDywjXf&WUKvusAwJNBR4Pa_wE<(WmW%rEK`pkSh$aNFo7x~n0 zEkeTv2JSrlXkmot&BffWqDcC}aa(Q$KzG!jXrwIWl{~0foVUEVfrDf4$x~ zno;~wR@!!TS@{An(7_-{<7_HDlK=f-=wfDwHIYv z%r!Y|EE|C>TOo+N4QxMK8y1~664hTNoqmKi#>wEMRuD^vn(D6u`S z3_X%ER?b+{Y2D_Yn*RJIlWY$5n)5T~i=8>u^{=?J?1WQdL2MM?cW$u!_my{7RA}W< z5HB=Dv1UV_hk-yiRh8YXz^tab8{(qzO~^=c3uD!=CnSFTYX;W->(Td?(9L1K&(?Gg zGzoS)`74rQ|7^5G%3lpbGZDM48^C$OX1;}es+v{tBC{=l^n|Kz$M0Z41~B1|T+ks{ zh-(IghMAdAMNiGyhHV?yq$}=xN>$a6%$NoD9Ny{eAX=B4&kT8clC^C&N+R??< z{p3}u!iE^Px8{n_FR(f_(3e9lgZD?y`r%g}?7VlGGGen_Ie^ls=OtV1n>~~8Hmqo3 z05*DmFK5^Hw26E`f&)PKME+Qx8so^q_3g8>qi9&?k6bL&Q!*Cy^seV*I}bSwn=1&% zb4H1yBwU8S6XywQCrHP3^A{H+>S6Oe>a(V6GF{zrM^_Jwfs*E&FPa?nn)$WnkYO^X#WWlIt7xbNqugFZD&a^MAqnj>W)BIZO* zov`1_2XS!=bs3P z;j_x0M?4^YKz~-NBz2M#CWe_;-A|I4%RpbXqL7dZ=KW~=Lpc;{EY2?x?qAPs$g`sV z2>e61qW=iz&ACp*ePLHzR49BMX-+n?-^K?1p34t3(K%ARtHr0;$k8;$xvu9p*Qy0nvrXrt84lC ze^3N$k{|{mB7WC{Z${V%1e2E+6G9C8@^DW>-)7+ii&;K)sZR0$npmQmjVUx|;-`Z_ z0RWJ2l@O-Y#xh7pU{G@F%0*KfNJ?n#_z8w1abJi^94SOo(dw$SnIQ%cS{w&J8l|f& zGzLkmOqxa$b$iKv)k)Z&QHH`m87j+9BjHC6{J7-SN{>t5S7W*evuLC7mg?GsI*puH z$zK9uX(GCmR5-URLqF59*vEg0CJ`i*%I6f{H?h^%0untj?oxaIN;!?+;?(xfTr3t@ zt9e%B0;#ZpqjsgMp%$+VuP{g3x?^Y)SM zCTgy=+y{*n6XWxJIK2-q*y2VQeWv@Z^yBFA;3bs$FBJfPhTPWETk4@Dgn_~S6w197 z@gXO4S0YghNda4b7yV)y9utl4BRq$SV@kqn0-5}rHb8H zY4`>Z;6>Q68327L5jf}LOZ!0ruqI6SK*PA9`ZUBJkIW?rK_pCWuAQu?v(8GQbpRqI z=P&F#B&kUO!J5A7cU<0!>4j!H^{9l3;ogQ#1)|iE^e^0n1vGjQ_^D^0|C7SSPohjulZG zLv%ZnWvZ5cEeD@)1!{%M(0l+%?$)uXu7ZSuAsPZRXe;me^*$E?K&L15fjfrLL;X)}{j@8EQG-ApMO_#I83GXUYnWY4Zs z1d;#f#ek&&0)WunxPFMfp#uPuI4uvsK{+QZiASF+0dmC^=4)_5m{EYNm(v))@GH7@ zwSu#G+U!X@zsNVPB$lPM({F*@B=`gbf2-s+5kJ~KeGvT1$jLNPH%R(M`DwH$b_&sN zN5LyrF#fYU)xN`w-4iJL)rCS(mn?5GX#Gj0bfqW^4bPq|PW{_DMc*bVI~^qI4Ezwq z*>ht9eR+D%!xjyD;K37?FoDs(v#I&J?^uJ9pl=#Bxc#;(`iF&SS#76Zi~rysF9a%+ zm*lH@aVqicd1CCF&AmG%uZy9`A=8NBt^(F$56mEABbs11#k`E??4~hp*E6X2eDr&@ zbJ|UspVgcskLTNgy%=mW)!s8F3Wzj6{D>kyzoj!Dy48q(LS>)dub=q>?jt%%7{MU2 zbLn1%JOUfS7l$8uK|cfY1n?vZH`34`FMXUt#3ly0eVroR_%=*TAL9u^5=%{E^)EtV zh(F^Z%9^E+tV~ysRRA50$G3{(@v6V6x|+IujPccLi!?AzuTlav1xy#nQH1*;ES?%4 zqv)3e>-H|&0}o#>>B>Iuu7;oZ0+0^ZYGjm4$R@;Ke)H@=SpHc>wE3ZaGF|ai;QbXJ zjA7&r11-c)3`dJpQjCQOyg)}7)fY>MS%M5c?50vdgOcW{bufssZriLi^6%58L=-1~ z0^eI@-!E`zav?{mk+5YvED7Hv8ijO=5Y zngAh1CiKZy#BiGPAljxM1SaLL@ge{a1W7(TBka4N;PWx=g>!HT4dt^~<}h0CM0w84 z5G*=q3Nr#73JwH7)Q|xKj9jT_UOB&tLIb#O&@Wxep6&^Kb9)LIi}+Q z&uep&aXt&dqS(Z8PxOPN7{)H#s({rucLeZE{M47oT4y7V9pAUZzYF5G!6Hkq9#EV9 z;F(R&EwfrN5MWh{X0w;T=aHNx>dzI`3-XThf1$kz#6K|WWI8~>x!r=f#oTSl5^J@% z<2cd$#C|4!!WG7gD%rQ)#PHBD;DN$;Fi6-2^qT-rCQpjKPPqzB)=QyF0GxXMXS5&Z z`)vWuM6!cg+A(u5z1`2v3?q!uRwoINm@QlWt+FNz03_5Gz|_oY@*^1O|MvQpQ7>(O z7&ycQuCIgaG)xP>a3OdhQx^=bI>$^_ZNg%ju$HrX(igtbkfMt8FXte!V{8MgCC%#X z^{CXDFJMPCydrjsN}LQj$ErVYA}XAOfS7OIyvO>Z<+kmi)hDPcrxo`Q%xRU6uj!>! zRYwiLreR2v2T0;c5d=Mk&2}?BLQVM&&9>@y?=+<^AjY8j6%~#wLZqZdis%fVA+#qX zTdu*%P*_gV?-KwG!vFpQ?*0sSL1|_Hi)M3He*Mov!t5nFFBpW4U`>Oi`GIZ#mN7pi zfy5dS<<1g3IIIEkMC0yWt*0-rp#V=tiMn8t2lVFBv7!HWrnrNcz6LniSX7aa(0Xd~ zNwUZf7z6TV$TY~$6UB^auG(9eVLC>DF1sgr>Y(Hp4T<2{}Y}MgPSIOZO>lpD87zLgkpwK-ZSbd zs0gHaN|5q;zF%B2XA4~Nq?4GtLAP#K-Wv^Oj(h(>2G}_N7@soDm)gzugLheN)OG#W zQXS}8Ee}h{WlW5z+c?OPI`U}q$XOWh+$TU6-%H~GApOeLOwv^h^|3A<#C8sb#2c_A z`-Bl-ENcN~1>CXq^>EYZ_Jf!x^UQ_#1=C4w;&cttUkR>4`98@Ij%~hvti}*pd16@w z)G^tQNa9_`fxJjiGcJm24ZKFd96S zjALAi`H}!5UC1Gg3`0m?H;4i5Uay1<2!8uCpe+%C%mb*ytasvwwk7bd2>@^g0}BPX z3foKK8FBd?DgY{o80|24i4pWJ6gx1~V~GqO)Bo{b1e5#lp)5?Sfi3(-HG&{u`6=#* zE5HB+p|Dg35&&+|uyNsckEeHg&DOBRhv!PeAHDr33T1p8i+q7yMx$ z4h92go^G`;!ha6%ae;0>EXE<;{bdjsfr4;KnO&5T56^{N2zwe5M?|yWa>XSmnfnV$ zhEooiP96Z6bzQV};>D#QMFWO^g~%b7Z^_!pD9XjSfK&(9@tD6b;!JRPQ+cYalLEqc z2IQkxhZB@#Y?KtDAM`E$go%!keF|cZx!(aywj#xUC)&r`y(}WsLjjmDxy*iY(WkuOFFms195 zL0%){C5LTs+|$$ALjfj_FU1VEaAR?#TEL%>8B`WtI0>Ui#!R`qi6Y{$0u1pJ78|vd zI>?krPmdS|>zyM@4{2@L=r656oJ54vCLjlj>{Bf6xo}xqEryLz!WUTHYm`KiP%D{* z95+QSVt|ulU`})ya3ECrEIlueAXgs)QqBML*--QXbL1aIqF;&v(kZ$-%beL*T8(^| z>KZoiTjR!b>CS?ubUP1uAwp2TFjkaiKDj|;(FYEyPpSR&p8nf{wu8FA1Pd%d%zajZ z^a?aaWFbBJziGBFPI2r!pa_K8o>QSCtef&+*83s@F;0HAW!TTM}8*71Ws(SrBtK= zb*Tf2%s?$nj6ovwD%*;DEWCdt!L6kLCXE;Uq*06>6KRwe7zY zR~$I@q<_SQwGP-o1vAsYrEcT8Ykc|vL#lqjEwTY(jro37o9>^5U2a8g{wK9mtqQm2 zg4FJUSOm)3%MTSqA9PooJ?l9u9}l0{BrqmW1^3P%ZHSaz0wl%7`2mC4>9zNhPgS1{ zf~1F1tf^S1jzVBt#4wZM`3{@~xFq3Y&c{&s7=h~fRWNWews$<$Kq)c%;nNS{&k-jT zOP0DEm7gjRiLxg#NxZ%M#P|yAs(XPMS7&|OQOge$P}+U6%vs4A2ibHlz%pdiA;3UN z#G(D-!i(%k?dr*~iPGKGxHQ4SpNe&NoUW;`Oyg_W#&Nci8kFi`Ag)Sp6M*$Qadj>F z_w5j(%ElxQfq!2cEBNpVs6L9J3@|gKgWB?<8L-lSo3M5^O{KqnEL6e?n&mOUS{n2Z zmpCty9#XC;@krn;Okav33R9Gh3+={RKu&EaJ4_?yRt{>QEkQFi62{xe?gb+jAr7 zx{eV93}7OOtg~fICN8W<(duYXO!7F$V@9f2B%>T(rfJt+GLD%G0CkQx%g>d6KK3&k z52btDQXS_&w=nHJ#r#+5-8{rtC7@O%FN!3fNu5A*bPARPhLAhyN@mF#b(f27{g(1a zSxg}HcpFwmo4qJ}XtixvyVF90B}2Mb!}D{nP?23E!AGnD;+gIfcriqU$xvDOtp1_+ zRFtrBwl@#elrV$0kKNiV*iMat8fZkr9)IJWpPl0@v4L1I8d!SqCG=v&VhfqfQFc4j z9}NkB_$tE3%RLx`4GCx{X>ZQtI5PtZ0;&Z67b4cdSPAN`JAn#GV0!|r`&CSC8jO+V z#OvRhYip- z;>7K%JS@T1Q8-Qn=l&!mt7CwMc?b;t8~;3HfNLOz3C(~w`;A<8!nVlL>>umH_n#@X z$P#HP6zoS+?T3p$KnP7bEE51T1S;8VmX~}3!-Y(wi(LgsAXnsw3-Y0NWOQV-eW;9^ zAzj3KaICQ-$_~VB&R<7T;Koy}rNcTL9$LW5a9%darDKo>710<%oeLClI7D>~g)0!Y zYrpVco$MVPul7R=Tnv15q6fE0>G?5Nk+Sm1;dUJ4RC!>wnHm_Ppyo4B2NX0q!sU0C zjr}-gbX87$5a`~%>L0f@;Ee#10C)un{hIJt3Kjpm?}NK-Y|O{{vB3W1UUT7Rh~$`@ z#2Z0YQD4^Zv@tS}4bFI4$&i0mNlGxtxNnjj*ZfF0@YDoIh7^3>mT^uBBHIx>p3`Md z!$a3UVbq7ymg;iYe|Y1-r+nZ|7Pc@J!btMe!7giPo*Qdp<$-u;1Z>RzwL_<`L$^hs z4kE??Hb)3*2s=1-TYC-9A|({18QH~&13nkc5w25)OJMZ5rI8>yuSCgSjNy!AE+(M+ z;7$+-*3wzhY_%WQ8fr$8zD) z_(IZ8g|LwDWMKK4vnW}W2&R5~mxTRf4v>nD;Oj!PLd_&x*aSGtsyjIINy37SR68M# zI$Y>ovief$8}Q=2^*5@T=Y_P0yUE_U~~n ze#@Uspgc8+!%)17-ysxlrBz$`H;yT64hW|G%I32@_OnqIlZWgaV%}?Pf==C$c zhi(#c$LRg#J}{DMgY41?xiIs_&^U+_{@upQI9`ua+gUX`Y>L@`|8q0|U`84*`j_ov zf#dh08sTBIjorp4a-ss+1V~3eB$judK<8nM;D(1HPEr$*m zI2ywb64TTEIk#QuLXz!oTu=tc2?2#wlW-x=$X-gC)k99T@vRJbmhygxrjh~Z&-eMx zUk(7Fx$ydY66%Db#Q3wIPoffAHh~K;HcR54ju*5j;(s>*&T|Ynu|I}ervHWHvb-JU zPRSk0}PQx&r>CB|P`p7t2Y&PC$(etRB=IecdMJZmLP5 zIgiH-ueY>dxe zeB*oqtFsNZx{8mb!}vyL&O+xc3>;bDW^7(rn4NU_ZWJm$2erM~|c z#rC18w4kdyp9Yt?sEa_1jEIO3W{8NI3P{Bh=@&sTh|s*qDTS zj?2p1{}*FhN6>%#2cSlh(_PAsC!>%e3x)G;v}r1wD`c_QkxS4>xUwv#1W`QY)jvQb zgwU`xveuYXjd3vz1LH8#ml-mh5$mtxJKht6+UPb7Fa)Gn`X|LLkG-ZY>yAS zlG5qY2pR#B47A@YCfiM%*Yk>b#T1kNh*uu?^oyFz;!$aTVnadxBX~xNz5RGnWkDJm z?)=R}&%wkgaw7>+GAWqyoN5H7u-YA|n4l1VrlvMowUtNutw>Ab{&WK%ZSr9P5)g<_ zBNti0(FZch_7)TH>;eRX6{K^6kSLP$1|Bigl2{gn9ekyUSc=s90ufQUCk5z4@VU&lG47&ED`(IN-5u4LcqCtnAGVP-U2U>_oyI0%k6$pQ|-wdtVX zP3}A!h@Jys(o1T<9h{4G`_-HbZ%D>ZpP$$r$>2}*;}_<0c~Z9^kdg4srsb)I^ zmQ(&mT!A<$y%GRJ9~mPq%aR0}8Y&p#jbP}{e9t*E98GNgLE_!P17qSG&};?*#M}Cs z6d<7n4>R}gOh~QN-B;j zJ{@`ZVG-N+CZe*PtcY<)s*!1u@^oX-nBGB2;WaRXUvN^Ik5qP1ve5Afy@ja~5X-pX zD`Os0QQaU0TT;YPg_O^6R=A#h?}lXGdSbc=P`0kmL-hGxB@?EHi9ePlQ!#xW{w))g z%QRHwusH2|Jx6F!ItYQ!ucoG&#HIWbyMbMp-R<%ge9tx)`2!#tEfiOtUoPwNT7c#@J&B8UICx*Yb^M1^>SQ?f6^#{{nMBnUTN&5wWLjTHZl9`R5Vem#5 zX%RRR216i(SYC{Jr94d;;PZJa^bHgZ0AV7}KQ?v@CpP$;oyYEBo##s+rNAs+ z>^MK~-(~{KkZFKhoVY*`$(G+Mg**y1G#V;${@{;uFOkZo&SB0YhozEm&W_k6g&%sZpA#3e~wk?Djm;1c&*NnIiER(_(onF_6(G z%jh64qB%@6urv{}aGe+*-GOZOrV-gE5%r*OLBkW$xUHem3}@bvd(2-&IdW;Aj{1d1qW{Un*4_TAjG z5`qf`A(UiSd4>0;B6p^Za#B|%DR67Owua$3q(%hg-liO%Yy{yANs=+mJH_CR^rY|g z<$PZ3D*KAl#Ji>i4^9ZR)?0Wuf0Dq9W@~V$wLIq66FRzRD}udrwFas$fnB=@(LZeq zH2gEb)swNwwlO_D4VV_wam<6}@+VM~C4tn{su^8Uoi3~+x%`8-t-OQ5B5%SYyO?6o za>$^#=aVZbhBN2OIa`H>h6e2+>Rz5e3Yml>r?Pk#Q(HaiS!mOF(Z+q1qpzFnV1!Fj z*sckd=!)Wk9J0)m$ibekl@k7uugHU;bo-<7n;Bz;_QK=}LEOv{ZB$;{<$$FIbNkxQ zfBinw)g=zi0_#V*i>#@0Q#fB=uN);eWCW`g(oC+Z$~%`s3uy)EtxUb76HErfl%4@J~p8@(fcDJk{${|H1lFHQv7oumtSb zsf+RmdE@OaHLw+JLy-J%tBYTF6PWQU&y~|ic_@UWu|1j3WqRnPmWE&bp_roz<{kPe z@2|Il|M*Uw> zT_2f~_Lre1wdtdG5BJ|0YxT@aYqRq(IQ4$5N}Xu&MN>`&P~WF5tiDSz1&>zYr>D;7ZZyij;{TRiq7dN zWYMfoo_8!CV2~bBnbvn3bYOjYkse61g!8fk;|=KpT@Vmx)} zNmtN=*Pb5d?U&dGgG*$11F??!oiX0hucG~@yHQ>N^NT*es)t{M=Bq_DzlVSO?B;n8 z_{8g)=(7*>4uDmV={3`6Tsi6c_fqo17BQgvHrV&=@2A~=)e%dVn|k7x!=HEeOSAlO z^So|%L~*8EQ~o}6eTh8feE9R!?eERL!Ti>fyKCCN`@XOcZ(y2logN&5NrzcxAzk8! zE$pRn?E|IoM|>9-dgZU=>eOwbNl@m0@8a#f?~ftm&|UXh4durY#z7qtz;WaLD^P0q zI$#{ak;xd?RN|3HB6$}W7%%A0J`#xI&PeKJ@QOX?hcv6)joXPdoT)8HCC!iTCP@C~ z3Dnt(7ZGGw@L;bO7L0R%MY`{;qaSQvWD7uqkd?7k3I?nmq8; zjI0NPOK?T`4DQ;;NG1+7IfxQldN(cWVjO08Z555}4*#XApUx7L zc@PZ@3%v$gyAMWm?FM}x3G^MY;e`3x^~UJ##+-!(@NQuV-56cBM7?YY{8JWt&Prvd zuOwmi5UaWn4IcGrv4kInyq1Q!6pKvKFhh zj%Pajgj>eVo@DGM7_-H0!sQWDSwfjEWr!Q3IMV8G@G4QL+%rL6nJrx{Ehyo8ad-q~ zQna2=+vS^U7o+vTi1&~ErNB^?a9?8=vXb)zLJ~>s0VVGt0dTXUq1B6}r!N)~lXv!$ zgrDob#qzynO?pTCN?;cQJ5`A#P6A5?t(L_ zYBM!{)MRCjb#3SUO|W#3hbx1Ej&ZtKW?v$7Az919AbweQD@A>W4X!#2FD;VJ{PXcV z_`xX)YMi$mU;9c2k3iPX#=?xWwyyTTe!H97py=_tP>2PUMElD6GbDqr`31>5 zytX|Lhcok%`E@~l=)h(05b-;V*LjTc3bZRpzG+(P`9iubh64GtcTkIDUFWY&1;IAi z0{|ROmc*6cPF^hD;RenkD=E9ni7z5v&bCF}P+%iRCFD5+l@YOo5lKaa3ED@|7WEIx z9M8M~N)hTE#Z&Hyt3fa4pRsZ(mSj=z+?Y@i!s9B2O3uQHi}^tF1x1d;*&ib!w*}zn z8CRL+5^tsO*k_6+w+wdrWsysGXjC|bR9VzYiMudQ+8!ciHY)KpqKrV@t*Er}i+`p_ z91Ze$2D|)Xad}}xr27i~Zj(W8dj(Uuke$E#El1^_FsZyj?vEjrDh7%@BE>8ORq`TL z104lJpQ>;&)W%lwM^~!0JwP)@xo-rjFT!6gaOU8~Rj-UyM_&UrZvn{-)fdp3jSBcy zMor=@KsL|nkh6xi1B3gb=Ij&e8-B|xcr8u`#yw{(BEI%Yi81ph@Dx(FMfFhoccu2q zr0$OhV`8Bpj%OWaX5Bp%KA~M5Q3J}*rT$2yo}{v_4P8&@NlPSCQ_s@y>!|**0^97@ zKpsgeZQj7V+W_n=;PPy2l4xX#qHnz<)%Z@i&b~c-Jw%l?`*&jEw#I=y# zMLKylnVh${ueMAlv`TSdyNow{ylW-NgnAja(PC4Dh_=))v|-srM`hLpWws@BHYR%3 ztH!lfoVRHlw`D{EQw`hms5=U<>s0gFGmoP)Ji+;$STJNqO=Tll;X~6ilMcV*s0`26 zWNM(pWBiT;*4}jzdP2+rFjO8uO0=^{G%l99Jy8@$ecojY=$gH&Awof?@48$VfFjsX zF+^-Fm^09Yq_jKyGoRxyspJ3&!B2Ah44 z6=EerZil*l88O&nk|#$~Lx_Ye9(S53qg}>RY&^kyRgHR^L&jnwo+yB87tmQ^@L;u1 z>wcL0F)#NU3Y_SK=Z$P-Ko&Dc%qoYS#)mDBd!2ZK$n7t@xzrt*{(@P73kT~=S4%1S>7Z*3d2ld+Wj6t zcHU=iH+W``jy3!&W!SUW3Bfs@`L0~6M*wTR|7`a7QJ4T7G+@>^FqiZGL!25<)bO3> z2zA}qp;GT+CG=T#ji$-~dDLjd$%xYUs9|JB(`qdychj4!A#zW^#Mbk7ooC60reCTH4Y*r%IiC#vF=uu>Rmv4o!P8djU9V6zL}T}LI&)_8^*puT0zed+ zU_YHP+4I2!_-q|xPz%IrvY}7~Q1F@}!mZit27ZY9w)J|6T4M#*djtho(jWgK92va) zw^b8&M3SdLUSshuZjI011;WndFtPc1@2PJpTU0Sac>vR_+WJsnIh4!+Ga7 z&6qJOVr`pFtD6FbOB-*#8owCaj2I9xnE~8E#3mQwCOc_;roW3V{fQXJi(b{P2Fv~f zC`_zoX0=dxwa_7Ua@QW3s$am^9P1RSwkfK=&~Pmsz4#J4#=Q5XReEoJ*~=UF^6u0S+4o(cSdPItp>vO4ODePeaSe ziE8Ac$JDVW-k6f|23gjw-RVjBzXKe@d5et`5#jk8;b?F`hgZk^l?e8>!@AULmh}*A> zS>-jNrh1%BHV;=Y@O-;lUWopk=(%@XR=tDhJsxbwff!8ImvJvW*MBC}w`|cYf4@5l zn!3`&-%Aj?O7-e?iMt5(8Fz_0+q{LO(QY{VU7EjbCe--lMF4o@)9`#d20yetGXYd4 zLOjkIe)oJgR)K1&uiEFH9Et#&9X2oR51Ce1c25Q?#jj_2W^Dmy`qaR~xoe+X5Gd~# zb__7^$wM0zH@KV`{2kar^5!Qia`LfzOzig)-*0W&bLsFNB78DkX?$hzZ`~1R<+KOZ zO?$O1HbU^XMF@TEb9PN<0(iFhQ@>`voD0CA@fSD)^9Q!5#&LE%%oVOd9gwhp_FK4r z?`=(v-=Y8_z9U05t8FLWwv>Lc;$u30aAx(?BgFq7?^v`v8Hd*+0GWtM(Y6hCaZF4PXY|tSDAkqyX!{2l;Sf z=ONqP$6g7M!1t4Ifv>>Cwj>VFv!cn9KQV%u#SVbJ+297DZ!{T#ZE`c7yWy#JwOwc;-X~VVN1XtS2=Xzfs?r#P@-P2z5sG_lE^s2enRrhv~JlG2Tw^=yH zGui936)ye5ECWXhbwd<}9CFu2h+vs4Tl~u_Gh+s1yM((TM-jVmH4{$KINt7l%&MYz z)^i5lfJ3r)9bJxb_P;!odWohUC0cNv_M7lz^OW=mcEPc{BBiYl|%GPSl>%Df-=k+VuB`mw{3HfU$kqk47AeqpbPuHBF3CCkbmEo-jFKUz0KxK7)4Q|wOL4@xReJ5E}TxxwchTxaxN zI#_4jmyVSoRFx=XEA%A*tOB4{_oPB2JsC24%t(i z*3vKmD(!1R(=J9`i9gq?uCJ54?owZPNe)xuk`K*h2&Q58hybY<;%__XVg{Ownimj*h{dRThPmzAI}cqkqALDty;`e=#2Xf^(%Y9DdgQsIgKc6u*$QcE5T0Z7{|yMW^aLN$FFg`ORVB z?O#7guMHtn+`^xI#MJ3a`SsXXv{+9|9sFOklg8Vkw+dZ5> z%0N0i#g-0^^a6G(ZcPpVg@krpyq{_k7KnIhu!vOVlYUe>hS_5|rp?a3C#q5iP9 z*crYh_aMn$Ve!i@&2VLveE9U$fLJ{;lvL*nZTCT&IL>K^&&Mt7ALI&$`AiZ2!rn0{ z)+_uIj3cqP-$A^y8GXLckPzOn%UHZL*65NDVn@t+V6LykAHzo$Ni)7w~R$&)OV`V@T{%0 zzMKVtO?-J9c_OD-TW{e9Y4-ue83<8hn%pWYBW}kGwo_S7;>XgLtp<-w$Ap}Vfdhi~ zqkY0cN%TK3SboK5YXk(uhlc1N$fw)27{p032`%>6oUbRMc)yf93qE9(Oq))7_cM06 zGKitlvc*3|CoP)maZp;;@cH-AHXSg{`bA+bLMk!Gt+QEIU;8ETy^9@m1yP9cxx%tcB8rFXa}mUOxkh z(2-N6ae zp)#{)<7f@2CWX}O_yNA8t>?Osu03J2$eYbY<2}h&13X7+=DOKP8 zo`?m0*8@`v_wLI&e(LTt)e+J|m-?MS9~G9jIX{X-`p+(DI!*tH*JsFK)CnjWZGR?f zk7l6J&L)eR|J@@sMp}UNWwm1HTH$7pk%OShC_T+oJN}pV? zbH+549GBk8)a~TubJ3G;yz}3$KgbRV>CPtBn8rMKG>;D% z%ze?e)RTWCKnGKmKHLdLT)WvC>MhM#TF6#@xwX}QdfoFe$3@%C%PLsOsgTjN_Bu%Q zfY9v@{XwR-Ui*iMTxG$e@NuA*^v=l|FIj$1)nyYGg_YL9r$x7JGllLqE04R{rT(14 zHooYk-!&PNF}#@)(Q~KJajK2NHdG>I)@RQ%s%R$YQ#37>qE>2#7x-H#n`u^rML$nR zykjf4^x3S(1Gs*pu+H7IyyFZwp5V#;PdN9Lm}5wV!AMn@3HyFjuCtoh26t%7_}elI zPi*M)>i@>rD6|#HUkfiFUe*_4x3N^@MhwPpE|ju^HsH{ zwL1KI2V1K#Tr9Ej?S#u$#(Kzpjs0Td>Dr`c@FOr*ur%@5s!_>%o(}eL*CoaTrME%i z!S1z_xDNmP06a&)_V2HJH2UdtHpAbed`EHIx=uY$^IC4d{_(ojG5@!;EG`@cwsG>W z&MYci6r)qkRdegSCvk)sKLYaHeXd1+C$`@2@x1q}Ir}?(*7Nh*xNe8#UDj2<`mICs zw{4!&<%gPeTFM3&b*FvoNyq16$$a?T+36?x{1t?O%-`tlFE)!m{eI8heOt_QHT`Kjy0E96jG=Z@Ki1yA!F z(RKN9{l4Lu=N!!OE4$ipsY6nW?`o*fL!UqG>0@p7?Vp9TQ7X+_W(>v20%L=C0UOK5}-w?$1XMNQpA%}_+o3P;cDM=!WX zFQrAVv_-EiMQ_|hZ&Ji;3&-s0$9#8>IY^5+YKu8piaEWBIj4yIDI9yHAN$)qc7_7; zKV2`@|LA(D0HlCtz(L^uyRJ9ewe)|A4mAX||EufGEpL0&^|k?e{?qja8$}t74nFF7 zYlmCV0W(wohpxAfB%*$E@B8%r{Qm#ydYg_euI55!e?97Y|7UClOJ%Uv<@G-5dO5R- z>=|1)acPtWej%85w##C%58cqDK=P=s9S{cD>_TSW8qM9?MdccicItPfyWNg~r@%?tm* zw%lWQ;mRV$a{g)DidN&w==%9$SBBv?UI8~DyfvO;+##0xa^Uwlvl_M7;atAIHMV-b zs2;&P?zaMwYPl?T{{rr>RdoX~50cE57))^e0h~;Mk~p8t8J-StkmSE4r{mueB<9}r zb1AJ3pnKXu;f!gIyTYF>#!(}z;B>mwg5{efTQ?FRHo(6X!r>&JY_w^=u)}u4CvCb3d z8NNW!juhnd^Q9;ark_H@s&eTwBUzeWzhh@UqGNG0Ok~k)g7B~M`#dDr>F2mq9H>zF){PfzrnO&w9o!2sLJ2moH)7;- z8h0@vF{H9kT;9aJ5)`j8JWat8i$uJ;l5RV=EULLg&5j9AE=PJukVo^b@9mHH&HI?< zGUCMV%x!K=t*jk${G5nxZE;P~c%#k9!S1UG^`E&KwPI4-?4a&9mWRKF%QKfKy&gm- z^a`3;_nl|k*ltiCClc$k8$NMpr4WlU=3&p?GW@X||d@6-^JaBNJl)ZXH zqp%5+fLjcP`$eel%{F;|S{Pr*a9BtCwvRE^5L84d>y2Py@a*&b9LMv0 zeth;P?AUSdx?k7pI!~W6=9U_P?+_cWqT2GSE90V$K{kmgM;i7MbOIH1f_5uQ*;j%B z0?mSWFAAk*<{dSfstn}1JsrC_Pw%6VMa;SoX;zTyx+c-HUK)I14y;cKFh401y?T<9 zwPARN^&q~&yOxf!01K4S7w7h4U*TMBduPn{1}FZ_5Au&PW^#~XXZJIz?!&&c6pliF z@NK-hrqc_3e=8TH2VuR$;wY@uvJ3gEu(VEtne4N19r?67Y6~f%<&mjvoIQzl(xi>?p<3zSREU!sf<9|?AU^RB+LhA zFF0pB=9qU>(wXIIzQG%9>jNvmKY2QHqpQhjHt@F3n(uf2t`q4n8)o`z5BQIx{xu4@(ScIpcyOmin=OYC(=EnJK4RN-? zO+C^j7l_w<(i_$U=6eY)-tN~eVkJ{OFH8Gbu__kHDm}iTB=b>rfF-W3*>vE&$!tR5 z=jO%-bI06*>Z16+=QM!IHN{hjBX^7bjM$#+{^m6Mp)}?pZV~!(7FqYp>%S(%!`3HfNvD zbbWMlv5Uo)5O?s6^UqP5A%a@wp1pH_F*4%k(7V`}kM>``O%-)rlELgPEL>`b(HvxZ znomp`V(4ak-rwBQx1OAjp`*KXzD-L1_pimQ_5+F`M_K>G^)mlP(|Q5e3UJkDA^UOk z&2AZO6Pp*K<dp2(` ztgafXPXR^mR!r1|9kyzHR#{#9hFNIHD0)>^Y+qT19#FueX2N z_VdP!!sgUOq(u20j_9(D>%+;hLWsBFI(-7VC^TZ8deHZsirZ1X<0-v8g}q<>(LHl5Hyz5kg`Ca0!nX6IS%B zOHY?q{y)>n)|>6O@BZg*{^0%pPA6ZEj%lRRA3y(hI;lc|MnBCDE2y;Tgs$7yyasE; z!em9dL9Q{*i~-b!XYPxQWuukiZRi1jha@pjE8<>1LCqBadV)dD*qcp3chQ$Vp`#$Q;P7TiOZuw&-mft8VvHn%EjxU^~ zUF&#GRr4NUfA~z*DyBWnOZe__p;qyHGJK|C(MytK1 zRx5ksBX2lA-{mj=w0oDKOjZc8ZkR@Ar9X2^&wcj8#<|E3&p%O9iZ||6e~lq$j`^@i z?a=+n`FdcxxQQxA9>BG2EZc~z>~v~h|Bp`iT$aI?n$g4Usq4N|pVj4lOyr*F`=>bk zGmG+~D&yHcTY_3iIGeYdo$TXZTIEn z2V9wgc3xq;h1cfME4Q5P++Vwa-Bf?>9*5G{B3=EV+#s02_kF)EeSY$%YnB*#uOyqN z#v<=DC@sus&1GI@w~Ac~>v{`1^=6gxx3R#GolG5NYbgKreWt^P&@!H9zZZ+n$BY8v~ly*N4Hd+-TDG5Di$zLU7p0gusI37vLe_b&W_{;Y++tCr9q3qczJN(E&;rp6;6zQ9Y zRoPtEoO*`s_YK0(w~ydLnDCrOR;nPK%aqnu*9 z{zBlNWWu$cy+7KEdsu%zkR5J?-3JiuUg0ON%&T%0m*X}p;}7mk|BHEF!|0_3f8zvE z|JeCM@%#BjBd=f1am8iRha*x3>W7(Dau@_NZMk~1a^17Nh$Sqa3$~cs9{X*JY2n`K zwJ@Q6PMFwY{MZ+V%>VQ|1&r?Cc1ShCuTIW9ym#%vTk9Ko*HP5!xTD39zkDcXxf)Lk zm^m*%e+c88c@2?@Yr8E?5bf0whKrg&UfCa}O@s3b*hrCM2$1mZU~Aip&S)~ipTus- zOl`02{1#6RK~W)q2?b!???_L2%Xo|l>f{N-xz4omvk<6hoE~ogn&KS^5TR(v@GQ7x z{%teVE!O^zv5uQ>xG7DkkYOyK-w!e-2Tk_n`$wHpczbMWN9cVNC8f!uFmY50?=X=; zkNzF){0z#f)|!tOWMpeqZRgkaj@NpZf{-Tw3}|lviN>@smw5Zirt`>`qZo zAD9h&p;`r!i7BC zz1sF~0q9wU6)e2BZP&c4(wc5!3qUW9k&~eU>v?-EuBQtv&V6&wTBlZYCoJvKZ~6@0 z@x#jo>%69)SSFHUm_X@rDw_|681lThS;#-d%WW~0n~Zk#{3dIIuwENu(db}fJm-4c zgX_{jg(PKHl-^LGY-B1En7!)pzUSUs<+dQET-Wx3(hkoDMOX7CPP^>)8VC_s+jcdnl?aN_@!0JIRSgI7!=OU1NIlpp()iva`!+`AfMB z!v@#Q>bkinzc(3or{TY=1Rpo2`!1EmlT5QS-@85Bp2*DGOT-*9BqZ%V_E~Obx2U7P znRrk3hyc3HbT^*8d%zHPvdlqa6hz`+(j|MdU0>c$MdmacjF*o8t^Rn8=_R+nCzEbd za&WQ8Cip;`|6WznD6(H>4xfR#E|V1ib38?*(HPBeSzw3ptK}zp*NqqYGcf_z2>^%5 z4g5e%XUBypJMCb zs~6x!!-S==nasY-y}IF>9MUOHZO#IN*2#~+hT%@Dkt_WVE|3IQZXRIuiQ$RumnG{5 zUY~w;pd!2u({%p+cTO0)!isY_wXKa{TCkdJ*8aS4{d!gOuHxd_o0@Qr=Zh~zyPT)` zUwxCyN4Kl~OVpR3dJgVYK|pjp@W8_p^2BCTw~>?pN#Mw;pbO*_~w{o9X~br+W45D6F~dlNIa;7S6VB45^;YR6uPa z1bXy8L7osHO;|A5QPyI4=Hx@u-(NpMsULnio_jl#=96ydDTQ^vv!wobHLhS+qlwNq1^sul zwShgiTB|DWnX+chv)mP%D7@tkueHz=h`Lw5kFqD|=@O_yO*m~~t< zh)-wWap3>KrA@NeM?nO3amdN+xo< z%kyld;`p6hj(*zP;4DY`BcCI$G9W?w&8FC7IsVklQbogl zHeF8>hekr|%!#nhAH}w@X0im}xP)A-e#xC!km0N=ya#+M;}bWJ=Wz=a#7ewNIlZyX zrX(6GV{jj?btkzi^J>E#>vhNLK9(+A=;G*fK&m;|UR3+xI21RW4SSqYn1Zx#5qk$Ef zN@WTGzMJ)n6l^hF8LJhSzM6THWX3^BVT9x!?0T7>vKvlk)ji$>^++MfT!{a&788fN+x7JMW zIubutgg5Y__Gfe6EvdX7_Xp5W%1XiK8PYA8Vs*D7MypDMENo5dG*vOgjKu}QG+o&% zRl=cJQ~4F7Q8h&=CCQ@YZ|)ZgC6rI^$tu;?V^)EnwE#^rXpVwN@TDr_>);yIsK7c^ zZHjtM^)EH3Dk^M+&I&;RgS4xe7$aDIfO?gLPds7n(p8&%)|(o^NZ+)nXEm3PYS0(7 zZ!Z^4aS6qfAy3kwNn|*pF|)uGlKL~(CxJpITj`Yp6lpf!wu~@BL4z5sR=9(Cro*5b zP(b_24e9!U3D|#o##1Vum>(7y+Dhk6>VJ;H)g24&Oj&WPE3BzQZdfK>s%U0NXs)ej zE|INFl_D|zsJI<`=c#Nlqg8cHP9q>&YTk5*gCEMiczT_XTId0F{4s7LFm*nC4$en~ z2!wbz$`T#<+h$aX_WN$z#I_aA)WI9u{A4QyOsmEA8%%gxJgpj;a`K+Z-uMl^Q=@5{xIP%BE@Ah^Ap;Cbzu9k$%<4s}+^*x`7Ex$){bYs$I@3XT?9`Sk?ra-f5^>;WJxnLwjHi-YcD>5wn^Zb6`HdDo6IsOLG!F z1r6pMsttP#H2r@jg$WsL6)$4d-tb&UNiy$q>*l zV;rF)Y2W*?q_a;3s!qnEY-~8EClF+T1(Tpo)UB zTG#0FKr7VgD*H_gQoux-E}Pol%UK0t=-ORkF04dFCIkTFTu_Jt zxRBwPY|DW=mPm3c-y(`TLhgB})Y=Cw#`_t+4%-C>vp2E}Io>BA!FYghMg)}4hwP@K9Y)X-qF7>Vnu zTadgK#Wl!H?#&(@)21&d?H$c~X=20=Vq-Mn3OBj8K6@lWyZg2bur+Nq?c}bk_W>WWRGUkovXBbS33-`p{2D@t404m3W|26~8&|9QQbN zn(%1qstr0@S{nL34n{1QiIxIfR^>u(gv1lF1n3s?&)R>UeJZA7KlMjh{3BG3=xBa0 zrqW@?{#R6*4Cl!oKa1?}%X#SB)Pmh~TYs0VkApJO4xG>+z+azu0=l5bBp|aNR-PpL zOzz=lpLi^Lj_Ij?E%*7WjG{t+^7;KI2O63$NJhZ1?(-iubG0A!-LN8AN@dF)1jVdc zo8uw>%uY>ZP+=Bwx4t87I>#R5Xcs!aWl@@Wvf>eX$S0Bs9Vi3Ki}oOgI#!6Qa_${q z@6f|k-pUx8X06<5NdOk0u@S(1$uw(?+nrsL0vIz5zaD&=7G>hx0DJDQT!iS{A>@lu zo9?k=(Zl+a4^&lGB&^j|JhUEvOC0YT8Y)~XP>V0l&$sSg0I_&rw;Jkjg-=kG?t!Ln z|F9zz_sCv)9qPAwyOYiTZ>m5=r((*jA9b+XA0!NvEwgL~y;7kNRF-LC-e;ah?rO?T z-bhMN_P89x(NGRDB@&>P#c0D|~r*66j!qibg8S$0F5K9;O|h?NJHFQ?x> zH4#OTNBnN7Kq0RAuzJhl+MMe_2g$nf??{@^A77_wtmrITX@~?U{0cP1!ICF~@~5KA zn(2(B;>WHUl*g)Q)D3K)Z&DMKSZCMq%gPR}mOitj3|=*p9&?7F4sL~(b(=Z!T)_U$ zv!9%h%<4IhRL@_bi40RNiv2+koOj~59!wr_NS?E=uWDWGFchA)c{R4bO_!5f#8Yfy z_FtfNyyf<<9yrUwo-7fDm!&*=@wPT$kJ;VMUN6j;+iZ;{Vj@&C-nsqryPLD9P-ek? z|GRYWeHk&?MZTQPXK0k%=lhK3*}ay_y;fE9*{oFva8W1g&u5{;?nFvHHh$$4;Y$n# zTEg`H4uMsr%`C6D_mhpL5S@xe!*`>N=gS6fJ<9yoB8j&cO1MFD;n0Hzk2(Z5#dc%5 zF^^aZ*;JCi*kq@yJ+m3hjs#feiN`heKpF}`Wf8&PVY%*{*T2(focq3~K6hLL@+I^o z$4f+&?0&&_H!mKcZ|4AT5uvaAaqwU=;fLM7GNgN|@Tk`2lI`KMneun8FpduJpzm=~ zk_&gv+wjNi&%)S6w`fAJem5M{hBx?yWa*iU^{s(No)Hbb?S#l5uVC1HVG7LgDeb2O z(d}4Q{dDEk?>jEu{*Q@C7RsH4m$n{&K$J>=FaTG}{K`_5JN|sP0Dfw1ZQ>}6`X)p8 z!cBnR3YbwsKE4RLND}jwEx&I+z(@NCD4n$rJ7a`9>d}6990K>+7HL{=G?f9M7#yto z3x6&h%siLmRsN1LVifND5*&j{1A$(zMPmqX`4AdL7ksSWaQEGIxzUdqoJqjh<*gXjr(;b0@LEH~8X8eX0So=IsEkE{Z_(`;jtCUfpuNXoxcW+)PEG*G1_ zKr05Cx){1;7(En8PolR}kP^-jW)>D#kcSn)^pNK4GMXO$+rq4={ht=*O-&)?G?FT) zS4<0RVgF;W$`zIxW@af67iQrU1b{m;^#BTW?eza9wof0SrfL8|=IkM1G1TlXWrv#$ zO#ei(G&UXVFCZ6#`W(8`d$bzn9UyDQp@vN4>t?s|@y@-~ZpM7XDNu+IWMH=v%#)sC zMXLm?8RZCSIc)UW32MflXIEUxDiE?g(}ngX4pkY!kPI4jOAHn^0gL-}GL1`hy8wQ` zr+6_}42hTV2$J)7!m9O%@FpN{oE~ANcq<5-Vy#tQTbd$1+Z$#{A5##q!HA!rzadDY zXJ^N(*a+KR=GUd-MQU4za)>jc;PmDQSp>Q-R{t^&;t;H?oA(nc4sq#C(4MNYCrahH6YV;#T53a`f(5JMs(^H(_VukZrPelx(BDCl%)$u;MiAl*~dmAgnTxt5cfXyuC5!Vei zkOVO$Jm<3}$7xz4eRZGP1{a9evXuz&L51@!%}M%7eSaps>m0wcCVYA7r|S+8*@OlP zD@7t}Q-{zMSxS$?P8}aJ(z5)fFwWI9zT@yv#DJ z@g&ny&Imi|8e3~#SADxNI}NG-2!j_0#TP)<-|bm9I1|clM&Z5x$!d{z(>agxnE?N^V~V4l3En_N(-QFShtyLeW-mCrkC~VtRln6 zjcw;@EMze0Ejbk?>)8K+F!@H2LEq%ri`uhZ_A9+Jb!jdqzcLyhAMVddRAq8Vx?ZOe z?1P1wpr8fn^VY~X&01e27*jwQ|y8LE zZL*#((y^ISi#WE-C1*HZNcg5g^|AKJquxZhj|g=xK@q^!WKLy@NMh_)p-Z;9z#dQm zQv%<>>3}-LQF29Pa05gRBo6>|05i6h=3Hr+mU+Udi5i7m0_Kt@DZwx1ZzBcM?r^=R2cHWP z83S-naDzv1s6`V%!a&8Fwg5zvA@>OtDmWbFafGyivydOSPLKiBwm0b33S4N2`Q=QL z`c(8;eilti!LGERR$Wb(?L;;Yom%=;4OnY#j_55nS3|>yNS)uzRK!)R!ry=j5aIvZ@z$%#pGGV zJi`Ij;qa83zvUz+wn}zQ8PA_)za)j9rI^!rz#{@TKb>sRb7NCXiy;s;&L-4VZ6l;> zqU}e<(dN>-HvhVRNe>*w#*bOZcp)z7Znmj4nCh}$JB<#_Q{ercz*CB~l}1V@NfTR_ zM-7Fg&#o`La;;G&_y@WeZhvT|A`m#N>1k{p!+s9x=GFfU(>!v`tPPmP*4`wQEDR- zo%NyE?3!%1O5A-Nlr~hrt1*)PkcZ=@GXsOk*>V2e@m$kSj!iLTo5e5NVLlz3DsL~t z-!fC3LvQ3%qQJW^eg&4_bN{d~D0){JpVztf?ev52j{;cA?n{-NPe>h7YJbeaJ+Gvr zl&A$cF41s=T7#B@*2OL?24)|R`ok(HO=(`Ayb{_sPyAHNML~InT3$R%WyDa29IqN8 zMF}M3Ly_(vkjf}`e8J^K#g4F7(2hs^OI4{GrtsH=Pz$u{t8W_jo@OsA-mI1s5(*BQ zLWa@(q#7|XP)m|k4q_J0?Edn8?5;!CCp& zhg7fD_iN#@kB;FO?KS76tei-H&IcBs=XOrN0TKn2StZs&%`@3k^2_MR)T%w+NH5dd z^sZ+l3Tv(H>*CNLUpbAB5%AwUFcWf7yq8w`;$`^yVi=z(P1yFU5*LX~U&tNBGhTR;kZzJ<~IO_wuQ@lZlEDJKo}J zCbBps^6K=3e*w{PQ!EQ4J0UJ(;cp_(rh(PWt1qPD5GaTw5srK6b8R)LBG$I*4k(9) zATTtQ2Poa)B<{j^B}M$eQFtWkn)5W_F-D25lrY*QRI0*#4wbg_E)9WmYxi@|@{YdZ z95NCc%;{{!u_a@#BEg0W_li07>~!M0nt9o1(foTcYGoP*U38UFR*F80`?#8}iid8O z!M{j>zloX-KKPSW1}XLk!F|#-ApNe(6?1!mb431&E`TI1%%k6JX~LX~61B>C@vABQ z#+%DF#@Qpp@HJ@N3Rq-UhqZ|T8T%29emR$Vhu{in_@=`c2e50)3WZ zUDSW&eTgKrJl~`4lvh$cl!WnJf6lp~Oux+=_`=(DYSi^5jZjYlUACaVzk9zhO!Y1g zJLtboRY}^CjOHK)a4gb}Oj+p*sWc2ZnL`_A50o#jOlJfVN^p<5uCDIwEuaUpnDi~&`%)%v8 zwR5QKmgv)*#yDRs@0>7~0?~nj^7}I89R`BZAU6i`G#Da7g*G3s)<}R_d;xOiA@mrl zdP}D2otyR`M3<0v*DXO|^x`y1ZI&*-BjlMsLDgG`yhGlV3Xwfakm0#D$KWlrYa)m50OEFL1J zt*C+r_$d$upg{`&Z%rarwKP2lk^B7-Ko6sJ-F2Y^R{ajU;5AD(JXDzo(~moaGg1-8 zSy09hBp)S6p^)@*wWQSVwg<{&a;ofjyX;Htox>Hx+!gw)CHhEwd2f^_ECJ9ich-qx zSkSs7m<7iWAPnT@3fYE~6-0oy9E1!Xc-oMBRBeQ6{2``ZJS*0ABrgM)rn5Q7Qls1e zsLEj})`dkH4I0+b<2rPv-`HR&La_VsoXLC4bE#sT=NN<|q8a8e0| zS2lcXaJ?4otxpWN^d8a^2ysmn%>5E2J6d};7Qc4DkFpevKRiA2-z@*5oUlWJ3^NW+ zhl_f)lCEBVHxZu1#!VU zOH!$*zJp=L(_e#5){V4<;kh%?-#J6p)T(kG-=jC z{IFsblnvV`Q(w)F2fqlw>`&@<8QYTNK+6p;qmD88&9TfrXN-pf6dR>x6NSVW%XSRw zj=>rGn|bgcG2*N|hWnTdMPNFl=5ljH+ z0C;r`Mp~82j%}3DYLuInf7=m9-&PKv;E{ci##-1BoK-vBB4VzN0n!0adNj?Ap(EE&F|V4ziThi~TbvUZJ=Nj&@(1lhCe#a6%sT14N5K_yV^!d?J|4v3x!4LJ zfsayv!wFIh^5Rgfg7#$LCKn414hLX{+ufe9yT^+nl|BsY6o6xxK{6I5LY;cc2reA( zUM0Zj4q;dF`uOnxrlUTc>CW?yyvv;ox*ZGBiwm!i)pTU&_9cKR4lYA%EfTRqQy^Ld zhW zJ#|}OMm4KW3Hf`oQGl5hAJw}{yn-P6ARIw}_%SckTQ7``!@0>&#j0Te`R-Y&V@kKu zfzCwM=sd%lMJ>;(^gUZk;$-o~eL%qv4 zqV?o!lGcWDq?4G!FZWAcRS7#s9WtVtp7v}!hTOL+H`O9S#*{5iKdle8&C*i3^9hL> z)WAA>*KZG&wD4flr&o4(FoPtuB|CP>rr`lE#{sb*Vu&xB*to<<6m= zO2gU`<)f>sC&#kmHNUI%rXrQ4T;Qnv>)T>S$L^i zd-JEMlfQZ%hyVR|tl_J;{SuT;FJO|Qd@ROIm72zt?u2pt$89FE?*Ei2l$LYv&iTrL*R zs(}rlUcKu4TGf^d>nKoaEU)Tw3%T%3d3GcxbEJ_B0|KV5cG`%}*7!yT0EkRBz^Zb?$U^>@E}h zRLzEL;1Ppbod~BVzVk)@D!zTI0dvQu4V%hur+(2Br8sUI<-8Z z2{D&#px@YRYj18e;^G3ikgr>}pm#z2Buzn17UoCkm9&bju;L#_M>~EaBAEa;%?P6B z5Utm+@iwC8GZCDr5lNYp;yt~6_%`+)+5GAWQk{UKn#j^A!J5cukqj|VF9GM{EhAie z?v~^?JZ3zzKcf9YwZLJN#JxI;Vxe!}a%+}@;*o5TD7$rr7TfA`?2o*($^ zn0}>YqW!5Ew_zT?Yx3W1jOdeLLt(>=VMK!kn^e4X9KWWVW#w9>Jsn!KDo1C{1&aBpAUU!=B4MuN^se&^(6Sc?*qO8D04>L`-(#%}7cgztpWXxN+vtIy|gwc4W%;mj;J)(wmjc7kPmn4aXzikk(62ItCyQaK&KH97 zP1&2pRP|)(Y&d2fv6k{;t(iWPE9OD_Z#_7tEjOtv5_rYD_~Y;-}?!j$jt zGIu*B_-FDYPm>4U7*&Oj9JHCT2Bd)1(_bUr-?BtPHj*niy#ab~7|6EC7$Y^Ywuqu( zEeck%&Lw7UvX>*Ky%CS1sfW;YD&uUEv=_D~}9lKplx?T>dVWI z^^sj}w^{;=lr`Cc%5%7))97_QY~Ggwhg2w|=%GmemMDd4>~iMGpIr`27I541*e~+v z-Kk$l?L;yQwlIxzKA=919wVpUHScza{ekn%}YgIHS_d0IRVN82PjEE?*15SAYl7 z=2w3$iU@MskS8ICEJ=euZhjFH^Z!S*W!T?5ddfQJWW;M+K8oEX##`V)=mZuaj#7c^ z=3UW6)0Ui{Q+aKuSO;>K@LwZXF&n3726{*@Wk_kQRe6q7{}rAzbrh!_m!;2GFvCq=XzgHD2>Tia}2Iq zI%*U`1@!l!!V)lX#G_0U4qd|_HJe}Z2nbe2t%fm{j+?dBaydk;XqrR-LMrgArusr9 z?sz1N-!6)o;>tcfbz@}$ox@**Wu79OU9Nayw(~XxDM>AYPAFgFp*KXOVo3q)BJ?8t zSeB6+W}Dq#DwR|Wxj8ZVLKf1#xfK%X1T-55s)oF8QV-AidUO8~)PR{j58h!un-Do3 zCX334O}!oJI9#@ui=2cc;X!>tQX$Hs!N@Y!y~mqtMzdc|(F zLy{oU4-~?hd8c|m*M5VB3T?fFkhZ!O&ppk4M}AQ^X0IFBhVO}w3R0V3bl;gRb!;c? ze~q-pXAmY~X)ECbNYm31=i~lR&X0d3F?8^)64vzND$Jknebfdl#J3zP7=?ljzjA8e z!C?Kn&}mOTE}Z8XPet_N4X#=N3~iB0u5@I@ZWCG0Z?=vwJo)vzOU(~2y#08bqe(BZ z*-OPeXJ?f}Il|p50upxQ)LVmXOJ{8JQq|u^nkJ>o_1{arEEs|MEbADYJbw?-pNc%n zFd?Uro&ozs?RC=B&nxkH=aC=BA4^Z8{ty?8m_hodN$~L;tkLSal6gEDWSzky z|MO)y%3%O!*khlt_rGMq3OGT43RB%zuf{pi)(Yz>56QRejk8mfj4afaw|XC!wEj7W zlsngubfyRLeBtw-PfwoR)}X@th~AfL{~OqS3vTIej?DEgP5o$I$wY#jVXVNN` zF4;O6Jeo>dxR`C%qWReiSk%X9bj9AxH`l5z5&W2-JQwn<)%T^gz~v06_+HMl82-+BscdShokzvCW7SE{{&nP`8BIFrhUEn)6iy==B^Tqq7eaN`vSQ# z=1IDc25Vk4iMav4eW7-6Qto=mDWlkNCN6ZZN8D5JPwMK(=QMab>Z7AI9<0{?`{?tF zN5aUYziy3*)=RF5^v0)al|y|G|6RFkrX{KR(qkx#InnPYFjV+S@vvQI9`;5=tq zRM$1Nro?08M9nO-_P+4{zJ~yQF$p((u3hn+cHtks&s)c#kAp!?7m{c z#moHB&{LQWx>FW1>ks~mJ!c#UavG*eOQ4d?u8Eqm(S~kCO;UKYS;V`9j6HrLWfKY9gkJOGP;TXY#+j$+i`a>~=tVEIWJ=&K^`$mt z#u%36FvZZ`G~pgw5N?zM8wI4bOKDwIZk%5p7jo74N>LCKn}w`R4A?sv@0+GSED3d? z=Dg-0%&Zs~xW?tufb62V{~;7Kx0(XEc9?{QJGpcO*mWm|Z<I{1ks2Kg`n~Mn;=@)1U}1>;im=S z1E(djE{^uGNSR-Pn=|fEhT_F95hg3h`)W5<$VHh@C`#+>5930DaaNvAC zn7d(l%1VMuX$hyo0NKBx>{$@`N>M)NTE2fB5Lm}ACQ&5*1C1c(rj;A;yh{jntLSXb zQ5u7K%(_<1R@m)VjN`e4_LM#rf*csrYo$>Apah=T;P>>GpVY>TOJ&^Gs_NnczeE*P zuaYoYOeI-@Zf?QUY!E{cF|6=hItc!u35ghp36-jNx_;}nFUUqUd=qoVY5lZ9<$!aU z&3@BW|G*S#I1sS&D_8{U0!c^+U5&Z4=Af=C0LVkY z;`jue!nPX8&_uEdvPV`wnxQ{r@qD9t|E)swFa{>p+rRJ z;WaIEt@XOi<>^wHIf^M9$~8z{)2bOhz-f2pZ}!2<)@vHepjWyO5)^0@6%mThGHNbB z*;R*l0U1W*WW6vUe`&j4Fb zF-{1~sb|A!_pRrDlgYk(qC1PFf8oNMWt?h=wdw6Ma|aLt9j6F2OjEOK)A$X_o${t2 ze%hu5%xBELx6^2S!YM}PgZ8Sr;SKqn$p4^8^lH0IBSwph?Y#j&z9Np+#N%~wy;JajV*|z4H zw#VAHV;ZZ57$7l=E$pdxttez2-}*)#scU_$Z!fg(4VJu*hfI|uTQ@^=wo(=0=95$9 zT@3f0S=qab-(4Q8&NGFi`MB#x;$K~e$>i+#wb}}kYawa7MLSiP$Xx!hm+ov;G5DU= z$5k45-gu6`*|-ELzI7j1L|hI|2(|3&jjc!yX*ZldEiue#wVCxqFVYm&%|jP#0<0?9 z;$Uh+WL)q)WyaQ@7o-GMy95CUH@RCPv&2M>f95Sj0NW9uQ17AOyVXT*?cxtiAFw_ju zA}42+41C*Hxv7H~h7KM_!jbwHv3A8raAYuiv*E7Yw6R1OWFI7{l2>buPTP~5V_4L9mX?meFf zL=i`&KMVyjJfIVFsnY5n#5oUq6T}X&ZU|hKz>n&G9Jg5+GZ@HtHJKy*F)&YNOq>C9 zrwq*`PW0+PlIQMzWbDh3hCDs$xkegP^B_;xOkSZS&M27o7O0ctuSM-O7@m5_Ut+S= zPI*3>z&Mx{!e-@hz14z_`x2ywX^@>l7nVq8rZonQNba3=etKBsDQMy{;QS(@h2MKh zA{N5Eb?4Hh(O7F2w$>8KzEc;v>DFIz{8!ox^W&!On3t&IM#FRvfzZLnK_e2V62hP0 ziRg-o3c;&in{q!+Dz|Z2tFZ-3&58#CHxp-h^7`no9X zJr;(2&xzRJL^jINw2esUs03={ryLE+O7{ji>V}?(lPyrtwjLawS6-h#=PlLwQJxqS z-swzNIy_}R1kV16G1V>nEO{;Yng38M@N5%;e7VT{sUL&2fQ~-=_j}=>ZAhC!H}eyo zdIKJUA8Ac$^>2=8yyUMg){aVefU%+;+4LvTjyA?0yGWuq2y_wnQEe<;ig-p?nawOG zc!@9>{QL5o3s9D;rzAJPKAyJZ@1~V6yQ>oRyC`3QdsZ4)mqO#*Hmcyh@pttMCQo`x ze(PlAeNc|xrAJeO6AZZ8iJaU8&gYDctqbpKZv~#AF7^cLW&2;5M?AXw5=na5^XSnZ z=oG(g(-~XCh1KJ?tHk^jIkW;3I(qBHa6VuCyOy;wU6;)D7zxJp_YBYd%?DkF8&4W$ zs_t?QSU#CLoXPk!lp6OUyll0VezNz@;yvcILk{5Nxx7U@tXD5 zm1nN&zMu8{-aaqxweEl5d~vS5*53QGKi}i<(QH*SeA*PAAGvZ>eLHVvrtH1V;@hdT zYn7m9d>5++KGiGw&)-t5&hSAf@Bk76TQJT=OV69<*L!-e4^Y5~;qL3dAHVg6WT#mS zuvgr8pk(X)@mWrZeM?5KC%(3MJ!tY>`|S-HDhh_c4GIiQ0YkS$HttLs`XU-How-U+ z4QG-7-6?zL`&n;H|2{xLu{ciqL+sOXZ&CTRsLj3ggT@fyk#)-QQTWCut>`+*`VhB z>NkHas|1bg*#28^b_Vg%?!uK;S*lvVp}Rw2VUZ!QFvOLlhczU^aQ#jzBq9^WaU6Ju zD)ef2{lLTbPGu9l;mYi*?T76v*!5=HR~v?9KxX(hsn>_(k-ee7B4J=(A{|`fOJ|`7 zB1-*O{7cDYg4TC-NbZ89{}G2FK^B!HHU~}qhVXy|k_R#xj>r#<=?Cg|jn6JTKKjhu zlbv{S_a;Br4z&QCpMJFZvnm01PtBpdFyq3&DcIzVEvdVbZu_Ye8=xov@+`fWEy!ZB zn>1S5&$0_xN;ghu;GqqK1?oT4L_;{TpKY%%ihNrW=*^13*R2)_gU0%FjNeJeVxQ#;a=u z5;b0D7b;)_qWoo|Pf^%=&qWcIA+k#9+(*a-F)#U%47)EN|I}My3HJ*%Vhqkv{<4V~ z@a1+nZ!O{h7My&wCh|?MUE}B8(t!}o;brG*ua{>xz8+tEcrT2oeens*jrq+|TgYEB z^0K-`G1l#GqOBFH_-^QZO}nI`X)j2E+4jF~|9EwbzY0bkDSh|@jYj_}4|#g?(;HEu_uQN; zmW-W*o=%WABn=rULC&0G6D0xSMcRhgQj`&xw{#^bFvVL(`THOeDMFRDrG=&rs0u>KzSPxbbHLJ_u(kAaV8 z8vrvM3HzwQ4Q{2rFhQz!47Bv=OM3*oY8ojy=Q()*;uVy!q7QeF-?Amb7()+j3gJf! zW%No_+p0HXx*h=#!As@ZBFO@|M?7k<7~SCrbktmoW>@2@8qLqMYiE*sGMrreg^0bI zyM)qs6@=|-=H^uvgxC5^C3bFn?umOSoeJwF`MX|j)lZSfu{zJNkT|Nrr0&N}e46~& zxQ(Utm*H9rqIP;x6GQ$=6p}j)|M6>C{|Yl6hZT+Z8HJK zZmSt;*)fyzt^@0_*74W+YlbJ?6h1+;hvgoNxPg1au|nS?RfW3oiGZ1425M+X>el;c zN*R)CIP`L0oJ--bGmBs8ZB;dDhFBpxD$SWAZSN6Uab=a{#D#Z}qE&|EywS^3pLAjt zf*nGByPRKrOdtLeJV_1@tJKFS^Q>%SX;s(c2F!pE;~*0=q`r7DjDHb^NPJ^PMSoJI z>sx1QNGD=-)bT0xT9be)?{U>zI&wz2fP#nezgM_3{zb{S7QCVhH@HnMD2&Y3U4d-M zE@}fRw8lC$I1)hGa0l+rm<6FU@qSx}=8tp}+@hoeLy9vg088FVmm z!fs(J@8|}Qj{HSMFcSgC{g=ai-h_ zE6$*7Ced+bt3u3p7YS>oDm9&f*Ek5Low)#IX2e|Y0ZIEuv)ajR0Iek6((ITM&T$~>n_R3`Q*@XjPxu3f8p{9e zNKwRYQ*1$K=Wi0`rEaCdo-#jBSt+r)SW3L<*PcG7WK{IegB)qz5fCxB?>{^-zHX1k&%km@)sTg`3y zDOi-dSoB*6%@j2Xrv%+#zWy2mkqc9$c@PkE%8O&w2Bst){79)4-K4(!Rebj^tq?ou z_+3B}2eIXmP>0UZ<;+Y6qB1QD6jYc|^&O;YXfL#J1%4{ zdkFHD*7|32Faf=eEh1)uD~m#lCvEJ6=O+$qBA`CXDmHyJ*$Z@TQGpj4$H2^(0=$Fq)yO5++$#1w>(S zy%NkgL|Z~Jmg9{y)sNUuO&Ugb5R(ythG>6@I1e1V5dHjHex*VziB%?@+LJv%bfYSa zF3gJCQ$Ajq3(%o1!QKs>Gb!7>-(WSPLPaVJ;yy=!i@mOp@68V;k{<4=?aN1lB0&!6eX1g@c zna6q<%Jp&9B2%@M`hR%tit!@T8;docs<4TcJJE8zzlZkd$l$z%02My~VM;R#2_f<& zwCE+doU!-iX0V!KQ*e~+XMF=z)Y=I{*J7-2)Lo00v94OH3p=SDb0A8rOZsd|3>M=fnu*sjhhhxS$}|~ ziKNBBjnVeMNeGbcFc?i37AEFh)6KOP(|g4%U@#UxHz=BysOGgy193NTs`t+2xl4C% zpWU64t+D;5-F`#&+yP48|FJdM0=lJrxYBUKe5J8;=A`P z(1;Fqb0#;cVO}d?Yy#|OqUue%)>!)>fRT2};C0En`%-_Tpz0R}g~QSJGW=oIj^g*q zXmMb}p>Bzii)Z1>Ew;ZNEInR2dtN-)G?Dsd!K3{|N@HrSrmOmWEEWOPeQ3mt_jiG$ zVW3pCH}Y`m#!ok~5bmiK(DxAgZoj==b^` z6qmsl;sCq~?U2(@Y}o#jpHBkwE1(pu~(7V`3*& zlhdXcXI04?;)9&Nkws>({*_K*RplB(RR;vS0d986AF!GddsKVZiY#&EDVHmj0?PAY z-q?m(D?3qiGQAb)4{${Y1`m8rQsXHIv* zLqYjeG}Wcm=A_*MwD9)P0L;cvu!R;or65-d#;S1v^3-V z2j34K>@|H;}Pvvb%&wR`$oz$V;KyediV$kfL04M?)QR+Efv(R z6(`w0ECeQ&^g%x!6h81>j zj@*1NVd#<*$7DOk?{$hjq;Tv~E3|RMQ{#?r((0cwZ9=Iwu%Ao1G+%Jf9v0m+CjtB& z)4G2z$-{!zB*}joc3vNk;fsC@a?<*Cx2&}ctqefDk5aE;D4TV-pv}{k9#D`|#a76U z8|nNp^sh4@oEbdb6TC9b$(+v#5a3P#>x}}j7rb7b8qm&Hz6__l^-_uz;$iMP9>%}? zA_^#kKopy2SLWI)5mqRZr>_}LkK}{h$d`^G5K_v}O|Z&m5KAbcn7CJ901Nj54KZc8gS1jc#y-PE!8*-_GhtGI_v7B!2ZGlPNJEungG>r(dzga1 zFabx)J{<@OVFV;<;d+eegZ)<)hc&#Oi8SvppuY)1tDDNE8)AZ(gvri$vg(AgX|jrf zds;4lv}WQzWvZHUjf_qn1UlZ7au3X%5@iuyrg z$A864= zhcud(?)tEnX}z0k<7X5?{=O65X2>jQ)7(Th*tf?x8Fs;|ghnSx1}x+!P!}<#G&rfZ*TM6lLwJ|rkX$RP8Y zxV(eCk;A*N9J!(#4F{`@u1CA|x6mG>MwYJ8q?DI}nSM$72WQBjtO6NLY|E3Y+}F`c zcW0eWSMu!0XookIq2fBkV$5t!W@=!*yEdceY)%x4DYQu6_?44N0j)`$3<(Ov7F?j! zWE9a+sOiCTe^1#Wi-{O}GWeT;pJ10|iwu9JEl> z1Lz-=a53q!lIK=-RImwy*1}0sgsQ_kWw2~{zWdz40hEQg)q{P0^niI(Wd@ym8KqoJ zE?b$7Q_Xo(`elCIfmLS$TIax=@gNRExB$WzWKH^OvmUVo_*UjV zw=n%6Y2wA?lGW7kLb>YH!+6ajYpTgVRX}hB*XW~Oi)Gjt!8|o4l{dsQ`1dF^Q(0H6p6P#dD}rVEQ_6vzs29M zB@o+kd7tlIkOp52i7Nn6F@soPZBk;%Y|-*@%tdqqt%i$6$xan;RMQ(q@!((3h^okS z9?(ux8-dV9S1ZnC*up`8lOSM;@}l`cVD$|sBi_ER#$G+FmApRTx>0ESE6?(Jd}6AWAD61ktwZIcByQClKm&jXVCrBhUD+O8+B{vL zE&uiGbhL2&2+(ab-%0wT6Lkp@%I+YDz>^pcF-P&H3}XKD7IcM9$dB5)bm`t z(*y!AuvYJ0K!Pc*<3oDQB1$X7olc>!f&)DlCzWsvi9CV(wIwMF2BZ~H7k%odqTR$(@6jodqN)lb9g!i9#;+#YW0O5HkjRX-qnCL{Wb<)RL(ASYcRGrD86| zN)rS2k0_Vw=nPIFT|FE|;9lO?#^8kbSNqO3czxN|7Fs69`%J@&R2_OHJ`Y}Rc}TK|fH^ZV3%G|x1;SpUhuvvhK} z8&>>9WPhUK81x5J5Cify8(sY)*Q3Wztf<-l$l+rTLQJ{n?r4C5UW6+;90ZcwT6h|a zCUL@B&iBrVc`+!I0*oE7^s2E-u}RCkvgJ)%v%&Oep|}Td@{&K?Njur=&oHQhTMn1D z_iMF0H;8UAl20LGOv8~c6~`RzL!*df$;($646gyyV7!GNbPqW{o<6)<8$PWh{WH*c zfZ@hh)8~%;SSwH3#SkL>;Prja#n&MrrI9R{SE8c57NU@AK1;38{xj4pt_l!3lebOs zyKuegH=Fg)%!Bdm(p8#@>K%B<8wTF|%Jx7wms{A9r+;+2QHCxR7qK~c+#1P6UQC|} zP6xedU21KD0>lY#DSu5QvBr(^vl})Puk&F>1>2qrir!ub@bFbDT76!f`})54aU;Rd z`O*E>;eu=3`Kig81bErkw^96W5>>8EKPRIw)Gb6>zJ&x2E^FEM(BH)@D-Tqgb&t~X zVWmj}i`j_)leN*b+tEBvFIA?GZ5dv-%Gedd>dlts{z^S7J?9tBFb0XU>`R>UfAkkT1MOlBv zYN09#JN<`SB@8?7RCla-)eV=1?<`f|73UqlDZZADIZ$2{U%KiQ4F%=)hA}bAQf6oyhbph?k59 zLJva!)&6L(J5y}ua`Bal5d+eE${u4U>YW8c638O)BYW4CTg$%$-C*UFSo6AZB}i*@ zSorX8Wyc8ce}cq-l|!Q2vt+KSib{^jo<2NStvQ%$|6-eMjFnV`XYqby-Cj~^_IlsL zmkEO$i+2Wlc2RZ7AA#>b9-`Vx9t-7w^qsXr zCQOBI=y<(0jLoBKNRy^V9YJaK8Tna1bn~j$-}Lqc-*rV;7xd8F{NDc!YT5f}iwX4Y zzS|3GP3J7~^&Tz|e({Ig4&TRvjj`M4*Dl=_`f5(RJx`{p*ne^eylO*=FjGb zd};l?db);yZ_3yZP13QND`@16iMmZ;KGZVb6L~@N=mT}><8cIrxS2gJbLADghDXD4c z8JSsGNV2^Ag2EyaO?rAbmz?c?pa{0Kv>~*QTHD$mn-%suh|*XIxe-D=(AYTmzc994 zw7~ZB5;)JxBs$u?O|xg zlB$$B1Dux6%12A&0uSEH=D6bNgc3ozNIt6uJ``9>jVujZo?6&RH#^p55=+Kq?EfhU zO|tlSM@(h7o@W|ySJWALqWyCB1yN0P0PV~75hkV9GSss4u8LEcr?%DJe8#^DLvkw4 z7Ji+DK?L99zDz*i)ND2iR{kM0!%!YIhx@b-%CQjFJxfas3C!)WxiS0GIyiC{Qi8vEB z`-N$-rzvUo?SW~_g&EAT0yGxD&7V>Za@ zF6`~bR(b-^VvWA(RWgPaXk;gnk~;@1kt2L?<26<0nyy9lL^Tz+=ZoEx=J2JRoKnR^ z#00ZeywqN0_-=Cx8H23@4lMj9bnda(Z?l<7O2KZ^PVf!FH1i93@O9%zto7G>&c28E zrZYg{WiNjzZTqB;QNnm87nBxFF2UGDn31U67|T?&oG z6NhyMaog6m{qo%J_qj;Ychcj4Yg-HjEj~yX=_R%K^VN_U^~K!-n~om|0LW9bwjX{G zk;H)wbhsWY6#QzpGbmmpA&^q_d4vX63sta-1l_XXsiOQO=Qpc(h6Ho3KC<1;dUClD zBeAND8D|wXHMcuHKKgd~yB+374&{{F+$Ez<#r7VbXMo34By3+%wP})(4G98ZS^@z; z$ss7o&l~O(ZCv3F=qVi#nYf?Ae%BA2DoD0?+cz$FX>JTW|BNmerC;HLR8^XQsWM}D z`)J7x8>3lwH7C|0H{z*gHmM8@VXOnRRMayN7!nmt=TETyP+WRbqHj#_K+WL^jzC&! zC{Fh-BUZrF2JLD*sYuC}fLYq4n%0_R1xSBOq1zGpJb7!EpU2;Z zi{;pG=wg{B+-m5ZwHyk3Q)EovEQo=f2-(+&_kS2Ps1J#DS6iO!U~RypU6b9^-o4th8fO|x_RG&XuS~2`M#+s zVGPDv@I>P*=hR)FTv`p8TN~x!GYv|=_Mb*PG)jHt%`aV+39ol}<*s*9ui|6G8-8w_ zOpS3dJkES!(w;=o95gPm*f`~RS0YhOj2EuqIosfqr6<@eph0Fe$@Ab98I@tQnoYO{ zyU1pSrIY~6g6eeK@7${LA$OijxjSC;i`5JeQl32F=SAiW6}(J#H%&!ma#rH%7{m4z zN~}#p%Xux|{BE)gbjUD-#X=ahtf^iV&BnF4Hc^Fb^NF6BCY!&`Jy5IDAuC$xGhR%6 z_{Z}~d*as0_%Uzkh@3!Uw)`TAA!CVGw7o>qyJs}CUD?9Y^)~a(I-}!HQm34(b;!I{ zU%yb%*D@2~F56#Cp39<8jjDG!44vfnlnKh6aJT+Qwn~E7wl0=x^S5_cvl*AEPBN`U zJwE3$O~r!Q^LEKZLKeM@PkYW8w2~G?MqhrTm1UEoS&P@T`?PzKzf;>P6&JqrfbwSb z>#}cfcM7X7?+Vla?fTF=hzfGSuAzytgYDzNckJ1OPDXVvNHfynjQQ8dUWy5tHYJ(T z83Rp7{S232vnBFZndVes)(Ld>95QCvjKMc!zh6pim={8x^3~WW>TOw)vPOZ}MBF{D zeuD%Iu@p?UKYY6P9VPCqsypQxq!oNghSP+FiEB6oixyk(lq^@N`>v8^Myk?p<7P28 zy#C#9eI@?yv@|!;DX;BWHSYxP91k?GP&xI^d6RV7&*!Q^n@v;N@0PQ@S8PP4E?tWU zv|s3@TP7w=e`d(Me?9JfU=7n-K*svl6fWI6!3y+IBAY;#XxCXCFgUHjZBR0@@T2Hb zZ`SyJ*mK&I8&&exR2F0qOVuHrg`R<*X&>HTC7VUMJlA`!vv{0XG~`<^9W{um@xw!eAa?3QA$ST2=X%btgRnejVt z>(7@4NGY&b_(D1>Rk2}iN73_%Al0te8(z1;8B;gGd*zlid&_iexpi9un|#se5?_Yg zLZ^cJGm*ZtJ`e9(4&2_%6KH(Xlt!))tCOsygrk3UV_W`H$$>qzcje=amjmfoc%Vgp zI~)vL@DzP7;`*Ye@$Pl&`jb5gCSu9sz%P^e2P5;{p-*kYLo#u+8d=;dGn&d5b8c6` z6?d*KloD8tGX||rzS$|>-u+sAQLE&~!xA1FZNOpV!~To7h4krh=f3~*?}AV+eay!7 z-TvsGx>3Tv&MSo|cG)O|G5?@pm%+nrpC^}9zI%P;>3@$4u4<<>uM$S>Q^P+_U3?R| zy4ZOcgueoRU)%xS7CaK`k@+$GXuIwqR6GPu9K>ezdYyn>*L-vu;CB8C+mxUTN8&&l zxY|ndtppq!DWLdNpHmJuu%bC46g}GeNXXJB2t+B8Xe!3)@NC88W@7Z`WzFynthBpI zeHTuC6{oN#c>6rYeAh5nGB$DdQ4JwRDKWNIgIr}MmdujtW3`kNGHyyhQP=${Za={~ ztSZjdT~BN)8nYS;77Up(iMLu()}4&D9l9wnNXJK z6{SWQ=ANjNm`E3vtUDc9Wf@gt8QET#h}ZJrsfD5i?{?3G-N;WlE?~Kl4QDz@WYu!6 z6-eFtr4_4{;@cQIKa=_=6!Tyjluqh(XD@l_JX(C$-99e$dqVsNBrg0jH2O4U(K4O0 zQR^fpy+|wl%M7kyHR8xJKIt^>=S*zquKO8D(&N4idL-qyJ)0J-hkeMa%$Wr8(=d*+ zoP^(vney&5PAmbxEMr=Dvdk@c88buwg=MZyC$Y~yLXZF~GTvu=>AQm2d`SeG|mJo$k^Q31!Wa(asjP1S|NPa46@V&*juu-?U*Q462yD?H$f7HSC!ur`B z200!<9LuJy`@!mgx~bA0Z94^Mh>b^ZNzjg4cY^&i+|8M>RJJLC;isM2GA3h(>wR#^ zg96tT`pBg7d$MX}6bS`IO?l-{jh1sU{Po3TyLKnadFQCIUHSY4xf@^99CPB`)WcKn zo6`JV(D@Z!4oR>Zba8JB@>V7l1MoC1rj<2rxqeATp1}b}&iZ*!TiQ97uYy&d*>ZjB z%7eGm52Q`lrvvy5E8L;g<4NUP*?Q$pe*OYR#h>q;CmUN| zsux$x3fEuUuAxXu00kr&6`AzZ>ikJ6Ry+&QJIIdA(hqdH%H&d0t|&6UO9(t%F%!zH z6GB#BO~WY8yw;5!+(j~%KU4UK9OUD{HVHJw z3}l%KgjBdT991=@%*B2H-?<%vYi_s`eya&@Ddj{O-U@zHDv~7tW=te+KndiI*(iZ9|I|ZM2M zf8fbWcza1O%n^^_3LOkd>5HG3wL^^`v_I&4oxcv>hwrWJj4e~BMFAD95CkG%H*N%dLSBIZ+$G_rk z>%nf@wQjr1ZVX3{qe73fO^<6tk9$dv=U|WbT95B#k3UE6eTCj2o8FL!-msG12ZOzl zYrPLId$AmS(F%RBHhu9CeTgM~$%B2VYkldLeVH8n*$Vx+HvRb#{e>m{#e@B&YyIVy z{goU8)d~Z(HUsq$1C1pE&4UB2YXj|<19*;t!A^z2E}Oxgh{3*+!GXcSp|!!0%RvIi z(73|Tq|MM&#L!I1(A?nAv$dfYmqQC2!><*Fmu!YtB8FE>{sTpLzc##nIlRF!@=0N2 z+h$}pVq~vmJ=J8+|6$Urn=e2){nw=T{J)ocqDk*%1v-ZOn$CY}Sz0+F z_vZeWNl&Ltr@MK%#qx>ghq>;SH;*wB$=7syTHii#Uu?cN-_y3%>wmR1SEk$hACunC zgAemWliny6Lcyiihu@q?B-XN?^>u7b6J0gsdj0<~=}CI6KkI)&6i}}dkqS0$5Nla`8!@yR$jw+rbN9_SR@cVOc+L=_e;N^w{FKO_@BS$XS>O06S*&O8 zQwnMdxs@ul;=Yw8x7)atu6VY$m4PM^-p*8G_SnwS5^UPm$<~wE-_9}A5Z=i(HTT%b zvvh6R$+r#J-zmVv3;$=3)?>HGy}oI;*t=(cx5R%+_;YE{3Q<5Ew%hc%Jo0S+a|M<} zWUtbkJ=MUA%Zi9BNoEzIw5sDLUJ1%TeXYldzd5l5@4bI=%2U6w{G z;kgaQ&a3C~J7qI!|IE;fWedC?Kvvl>mk*#i-@pA?X^^kvCjzqy{P;SCBMO{%%k&=XO>S+=sJrV4AjxTDjcQoGmhVRG{hjGT?$1`GVNiH02^j~|5ChM8%!9EXaUKhvnAa#t zTHjd*qScW~sZ>tcvG+Rzw~}E@eSxo8JQ%TO;KrfXs0a^iO3 z+430sdsUli7#!n2>1#m>0)qC=&%#64@5%lsNLA77?_G(7rPo(MbiQar`%{O6d~|2} z&+=j_c3n*_4tHNN;U#}!h(o#xtSWcQuK-tm!@`?tTwKg9yy?W{C14YROJK|86w6(- zpoaCQs0Y!>*M-vhJCs1UbK!ij^8K(K;_^z`E*3ABS$=exq^+yzwr*CXqp;h-AI`0~ z@8lIMbKqVRdW%HJ?t`{RRz>?H<6c@wTfZ|CajY1CRe;X-ni^He(b>;ELaT9l4$0)& z%1jz{A$+XwT>Ys0!_ArrBwlp}t?3&FN#{KLUcx^5R?a${h8xfv?(Nw|{Hm)>oieAC z>lZJND)kSY6}C_WRxn=Iq2XtqtO)#$hv@eq+1EX+LmTuid7az7ymV%2e}f&1`?++Y z=?%$szK>Hfc&rY4SSQvi|8zXRwH@D?7)6=%6%Q1H{ z`0&v1Y07ZOMaPU>%zI~Yq zC6Mx%Z@0GdI?V$Xq^N(NROuKloE{P{%gm#l*-a>Sjg09B^TR^lZyh;WD@EQb{(gr0 zmLcjF^&;RR=~wJ^dBPeoD#{$YI^DkcC@h%Yv9$gdVQ16$;z;w`6U!Gh<-1+p8Q91_ ze@1U#`)#K~2hX4ExpDd(J5o}iwb0WJ`c@A*QmKTFYV_3ex9ia++JRbR$EfF0f@pY5 zLM6hGLTU>!$Y)l?g_@Zsb?(ps5ch$xmTD%>5OISs72+~8=1tt& z;ebnalxi6$i-HS}CXbd=`#0MjM?YXq5><2O3(N>gJ`)Y)MSv)d0JxbL_guOhyMI8X zy3owTKSDk|SM3J5W+H*ojt~n{!+?1S$~236cbI=q1T{i{%Tj~{X{8Y~infLvN&vto zm2hYnj*1!)!%c5|749|Z5adbx<9=*zjCe{hCRYprxqcbbM+|zv# zI^)$(mmbc_U#2(rA_$%rBC45~ z_%RTkqaWGN_1wgWqeU6twcO|Wnk43K{dgYy5$DH2Q*QHa9K zcP&lH9A9~0>2otnKZc#QV5nLwA2F1+l}{_*zL$|3J1e!~jOAttB2&V}%=uMgz;v|Z z5>@QWBaW{D20$5_`FU zm5YXwU|)=Aq|8yxBNbXtbEyUL;v;|0~GoyAOJ##l-AR;~&dM z3RKqT33ysil)jZ=?$qPW2x`#%aFG8Q-x=%^#oVosb&rml{(g!sM$2N}kqRd5e?aF* zfR2y^^#qrVLdmDeJHR%w3r?OAXm2tJ$(9- zaRvdyP(LXg`+}2*Aa)axfq=0gR*4Z)pS5{lQIWD*JJwQ6G2g1#s=>&^@HWKeXp9)8 zJJ7NcW_h_XJdNhT!PQG}%`l-G26gmYYCixvL=BD1^ZmP*h{d9OY@_CNPi}9X#I9F{ z&Xg&ZoR=D=wGYaNP$iuaN8v(WDBAH4kui`VM7Q@mRg?kVed%`|8CWiwM(`>#`qy$3 z(iYf)PRYf9ENy^QW)(_T!dKsyXxIjIFL|=)0VyX?uI>HYEN}8)cZH=RIlG&NW5_L{ zS>VkN@7##{b+NpOg|biY`rZ=1h<4{11NVM$s53#4=o!$@#-@i&vY~$@+YEu3!f*gJ z0>{RGNs5~+y-O>_Z7!PMdKa;r&#i7?<3=Y+c>XKTKd+K?++1S715^XMVFso|)L9)7 z=B$pjV0s&*qKz^TexeFVAqo(eQ|TshD%rFU+kp`t?W<}lId@PF5)CKH>j%e1&2d;p z(uiSF^PlFU%;YdYr6&BvPcBqt8U5-wo6(6X>1xL&eOTWj{Cm(92_@mcq}O>liWZQ1 zv0t~zQ@O@XQF`>_yu|6|W%rAbk}ets>rHVn@1)zY{FLY}2>Ql{zs1^>5d@#|*jm=p zM!oU1hoA2F?Z~^3>2uEze!Pq~A5**X?NRpF^H}_;@a1p*wSz#L7IGTSy3ePoc}isT zcZQ+Rh4tm1Lm47+1O*&;vd)eufV0HO7d(tu`&ibuYZ@g6+lWyDJ{oCSnUuWOznJ5o zHDghyd8Wze7i8*Lpk_<^;GRV!6@~->1l;`vmfV0y5**eGYztzIr54~fNdR6v%yAo% zV+#5j8WCz?o9k>0MiX(IkAOn?uPRZ{c+`vdM;`^SK3!ML4|_sB@P>B@+}%g@&zna{62d*zrf^z_ zfE=(l9re)Ny0A9Z=#35p8z7DVWxC!?a*s%O6EIj{dy|leL?hCPnqYN?wOFq;LPFIr)g2*B}Sr=V^LD;-+4wD3Grl$R(C?aA>|Z) zBapGkAhBS|zxpsj&iXd-Bht~VLeRS^Oe;xLq%%VaYayTID4;5L+ifxE$YPj1?JSYbPDw!!vKrkE;ru#MsCKQ~W82h{{ zj2xRy^+fWEDh6^PXR?KPr^X-Xa%Cf`9eyn*FE9oILfeKnCJrJ~4s*44W(xLLgAdIj z!e@gLrVIFY3icWG8+N4~X0mhLRN$7%XO;2MS)g^Nz{|q4+;|8P##y5t7cpZ8UC=z* zE21<6si1s$>+)-~bKChJHEIJVZXo+rqgSdJ+FaSrqWB-qNxGjr(|_t$x+H$EjHd6) znvBabmve6rvOZ*js9=3oWPqDTU?y~cfO{B^aK@|se8>h7I9DXIjXssmEY+$}A28l$Q^>lu-T{t+hyxYJ9zLf{0h4*rf3>r3 zRvPD!%2K>DdpUir0e4k7A1ZlW8PwNgIsLPeF&d)i4`V#fjAf}H^$!iSD)R2t zHa;L&9(cQ3h0yV=T}jMXtp>S-(i=j=Zxwd+>n3mea>R-yH5JxN*!{M&AK=kMTl1-S zf_P_2^<@i4F>!R7b?nLcceLwPNb2Z?>P&R%z?DAq2x#5Yx_fibO(AfA4u3jSjp+N~ z#bZD@^u27V_hajClI6r@(J2mOCkEG3<_O~A6M7RG9_U0z{tj$T2CgOh5Zzbd%|1sL zIVQ;gbP2f)vyEvY){*`h83~Y1Iv=8iM>7xs8w^eA z^+2S1MC-e&wDxzkN0#N0#SI4J!2^5A?A9&sWa4IBafAcCA}Jh$f9l622K06)S7j^T zToxrQvW);t39?HBa0g5U|@No(g2+<%Qe7;yJ*Q#Lt}<%03#&$5A6@pOU0 zmzf|=>>b~CsbW9!MmED8*#WCe3k~8&k~`Qho52Jh9^KB);tm7r&M(@XALZPc@SQ)& zbz$%)7PP?harosNB(jpk2?Y{F#69k6obUi!7Vy@eSaKgd(rBT1Q)HRu6t50jpEn@pYdaov zu>Y=oJwH?&(ftt#wIxrCXf&3#R>r-Yw*hqf?468 zP@;_=h?-Gizv_(al*rd(9%xPs|s^DNYzw3 zEVaGgy;C5?*_6FgX(%8sHuimsw^b!D?QW-&2MY@uc_0~{cxvTYOc$uwM zcmwiot@EJ(z>FV(WrIj;hGudM<(jGQy*INQx?aU9LJZ$jtsCeYTU08&H3{CfSP0cc zj%RA8xYz(lw7pVvFzQ|Y)~e>5Ipm{)M{Yg9xJuA?24Dv6h;WX-y^yf!rxv1AmMl>g zOUipM(m>giE=Unfw*isHfFh4nhcse2IO>*c$}L1&jt-LDBCc$M;q$NgJ!sxBFcW;l z)~ZD+Np6sWQd&6-y%fe$soO6s^(OoD2ge;#U&^d{WyV8y4Cs4b*9P}s2AWu|NfVt&Y%J-2-$HI? z!p_;9UD;m-s=L3BWb+Kjdww?f?)DeY&qWlzIO$7)W8XaR5uk|^W6uMBVXv?ifi|qr#|?87l*+gx zsZ}m5Q%@@SYumh4LDy|tH@BxVvOzu1M)e+a;8`oWJ-a`&R;kGQL;XWV{ofS~B*}a- z6xuaW!$HV5Iud$cK~Nwuqcwg^rQ@%e)l7Jn_o`EBh6dkl8fUTdKdP1p$P+gZ_yJ$; z+Z0c|0>cMBox!As7u2kTO_8=x;b?#oja z^W7Y`WJA9*iF{|)dp{ujMW51D6E%2EL}&>`(cG4{D6ez6!#k6O6a}%}eS|ui?)$5X zTA{BlceNAzhC-1%8TvBOxn%gRN&w~!xP9k3J4{&y22^iuRMYtkL@I}U_ZyXt_I(TlhOBVI?2vkxcbYm_i~!X- ziult0OGQG*Z2$KDFayu5enJuK!-?B4(V}Q%}H?p3a>f z+ICyE|Wi8y1)ijh0bT{hwF9Y~3c&;bw*gH!s=-erSsvfP6ZNi3pkN5erxbFSk zUSx10j8ft|ZQS?LpI+##JT;_MDr}a#VNW?~^6B+fc+02lB^pxO=$P2J_=Lm+0FclW zC(Xe2rvuYVOy%XwF5fRQ#D;N%|I<({59oR_~Qe3{Ed3_aN6=YkRiWUl)vBd0l#=C>BV?hUY-mOm9CTNi*Ff05%$VYKqFd z2_U+M>fk@RY$8u6nW6k_*@s9$;=@Ap!H-W^QWF=pNB#uR`1YLd)?7K2&y6d9l<~_{ zseGfrM+P}jK8Y}ZY+;O)^%*VVo%^Kj0K43bB=2$coADdV zlkfY#?|Z>Ea@1%T-8c~hlo*YGFp&mzG=k`85YREYM>mXa1OW-r*Jv;)DQl!+qJo9W zckj>R`xo3l?7p^L&+~a6$AJCqlAFu~6lVS`IJh!!g?PaY`+Ajk4KFVd)^p42u0Sw!{OI^oHCjTf7jryR7Yz zK3F7~ccEWNswdaGtV%U3_9 zI_~MBLkF*pq-VXH1?!t2n3LY%EZf$_N8{|~QS_=3DLdwZd3yKmr@OVa@VUZy9mf7F zoVoT5+Ls@B^kHng|Mqq`VLn#Ro4@&uE4~;pKEc>_Q2xi!^6>28l-1ik)ce}cr+y1Cm#Gay8;;T9x>X@R>A@+Twb8h{AN6CohG`-k zzu(H+AU_vzmb6Nqa6n;aLdu5D0#N8UiLP**9Xrk+b2l^6_3IgayVp1JynR@UR{R~5a~Zzx@K-_KW1|p* z8a)_%ZYwCb{5kt?r+9Fm3xqbuBTb^TcqgotPT3L92u^d1IyC!WTTpfTj)qQq3|4N^ zg@)RKmW%_eUSqe2p~XNEMeIYO?Sc`fcIcQ?FAWJ-FtW3t7GMNJkf|o#JeWZXERF#` zCP@CDWQhO8Rp!Ibz$NMRy~puzC|2NKK;&tD@f zx%N)x~@`2Rl^S6{!&ky6Cvdfg;)u<|9J66TdWhM zle9D*BvCyRR^fbOyvg9>xg7NJas`i3i6Vt@o5VDor9Z>z1RjY%9m(gJfpx=Dd!Syq zHdM0L4$kw_-#NDjE#Ym*;%?C<36LqmvGx@m1@$jFH%vO79F%pIkAUyO=%$+KP3Kox z)Szq}YTxBe9|yv9hV$CCK5g;W{A~ngF{>dTKOmdBRobI)pycA>&B(&QkFJUUN)%|X z<4B)$oaN%eGb%C$M*m=gZ5{G{DD4+`>&ad&VKpJQCQmGBA!UZwAsVvmv6J7zYO)JI zJd00*e)2hwzA*pJ7E<&0mAu?_n~$6jAQtz?w?@GU1d{3qqD^Q_!Nq8MJdzvRbmo>4 z6eW|$G?ns2&758?jVMYpO0Ba?;;V>Xe@J7I`*h-HpOVdFWx2iw@ORLzbrs@of!aco z7tEkix*|j&rBu`a_~2oxfQJus?7C?kZu~pDj8nPVP4Fcw>8CPIK1UlmP7TckUhjtt zmTzU_u2m}pY7&)-c^2ZhC8re{Fn{W{9F0ax$|arcZ?X}vJSX}WUc9CI_LK;$#n-* z36bp`gpT1e*^_(a5R{l5&*~XVR-R@&0o4+<+6#+stFU#APc#s~Ek;=ADbvrObQ=!& zS@ka8T0ps}OmXwcnah?p!$ZS!`ACTxPhI~bf9mPEprh8mor!XODk$@&<$;2ZJDhk; z`_`ZeD7^PXjHg-bMzQg-+=Hxp=F=3o9hS1#8sQ>}%k}JE?=85dFh6gxC*iA>y}{y5 zb{|BYn~G05K2BVLGFGj;-W$|5MRl5697I2`I@jF7PvZzHPMwPyl-U_;5r)f}#hC8Tq0vX;Y3TMK?V zFhJo_SDF!Ap(A*(kzvciex5>WO9~Tym{VFt!aP@9d#w)7T`k^;Worl;{0d5qiDb+o z&AZOxOx<2-L2o!l_ZCJR_^DYFp~JkfquoeF5|irSs}2v3cieM6~8YRDOg!Fz2vavPyRdg>)m$Wlt`ounX9WHuIeyJRi6(8}K76 zx=0EnOk6)fh3juccR>^vHji9#e|WwxJ{M+c+g6{@G6nE-QCb@OxY3cJO={ZID}~+e z&qn3#%pgztc&B+UKLODBa@Z1_c1*(6&~Ycu9$^&_?L_w7_ldFM3m5Zo((JJe@H+GT zJoo=V`(0x3f~k964%%e68x|~e0Hva?m+^;p@>xdw#BLWtPOMYzO+h~&q_2X&RA10N zFiosmrGGAw(l7DOms8`1m&emh*hMNRV83u6Zd+up-?7S4m z`8$aP&Ah3_QIcavaG^cU09bm_hRa8jOZ^J|4XKyB6)bD9z%g337z+^51((~)Th#*9 z8OCN&_$zOrSN$#T_$YSr%HGqK*Plg*O=ka{S9#O#RPLyH{hPWnzW zq{I@03J+@}=WzlRcM`wV2q;IUMbj@-Xb1AiQ(pgoVDXAxF6VQIdXMIy3;gH)kO2J? zLI8LK6<~^k2o>X{P&vGfzmLNP4d4NaI)$Qt)< zerf=@Jta#nLH`Y=U{LfZZ?oiUf`cf>oN1x8brU2$de|*0X#j?zjv)BY-3g z(86JNn}BeE)HhS?OwW3hm%w;I)pdbb?XR}u@M^0f)tj_ZO%#u6ZrO@I3-6vu9t;*+ z06l}Z)fFnrUyRrc%ckQ1_IJX!0LZvd4Z0Q7nTfnwW6S!2VFzp?aexxt|g2B9Fz?=AnV4+kuB5>hd!=zB7zlCWTtT~ne#!`b} zk|j*p%jIR0pX1ip*76qZf<*cm-maT##y5M;pEf5qf!ZtuGrW@p|I>y4&vzD&@+1I9 zNc4lAsMp_1<9Sq<=}v~H?AdhC*FB`(Nwe(i)oXfXR7?a0$p;B0`y3;s*Lt*yQ$a6U zYrAj_QJBeuqw0=8=Pf&qmBQD5<-BDD#Bq9`e$-$C*s`OKRCOgG*}T3#cv<&Z$BdRj5w#eCjGGRRUdqMl;o&dGQQ}7!yD%Z0mB-`eo z7N*rblA(kZNcjw`FMg(oU+q_M$#Og-wCRA<@*7j~tj;f|Rf^Z>1bg01YVFODS zd{o$nG6**(LW#@&vA-c%pd&ctBZhYZ|NHJ}18cezBcj=e-7LR;4GJ@zHR1r^SRw>V zuE5ZAQQ@5!c<6BfZ5cyOn?3f|)YS9S9DEFz#W~cM5x6w5ewZ+Vqhg!FPA`_~)dvIm zd$g*+3YI-42`AXVE`))VA_oSr!wlAaIb(fZAO}; z({;E>m#(`(b9wsMBU!F?MO9Ki2LUEWZi)(kEC-;ZN&j^KqsQN*%H>AhBnrF=AmAzx z7uO~B=7c44d)^J*GsYj!O$Z1SRjFPav)vmbDuEahnq_YcuM1iYyLJes3NcXtBrrA_ zu0RFp@@L)Y(9TTAU!I3j^sb=eO~)B+r=}s8U6hdY87vW1!ho|7{mcXh&imUQ|W2cR03`8Mv)VRvP87yOFE!dESJVacJ2eD^A zxl81olTo1EgmgX5|AscrN2!vtIfMIkXb=r@a$lnKCT;3Le`?4G+`La-{Ex>AD#AHW zYfkrw3Z%(D+7^;0SM>kMza|6Ivxa>WslgKOV;|3aWrH})&XS)abY>fvW*j*ZOr2U; zooqNMJo7l0?N^0VjUk{)XH(gOC_g~Zlf<+=ADz{{yh)Xi@Dk8oAITugbAR-nb2sZB zfx6;Gs=n}K$M^nsmy3s3TonkI&(6zL0!+IPhCC(VfyNPLF0np|o>(Hs8)__Ms9+_3 zbUmfh9xjP4BDzFF@43dDk3Gm;d`6%86(6P3f9)K{91ZgLWZsnXEJE(IcrgK9NxD-_ zhi$_l27A2%M1b^o=9ub2m|l`Qeg0b;$jH3Vq9-a?9x>RyP|Yh}O=ja9gOrsYm6+4U zOF|brN9$5Ah>(J*(RraS=EbY+R4*T&`#>^u!9nq}LRII)_0Hb7T^HWANWus}{DRhE zbxc(iAUHJaXy^&=ULQHW+cs$dy&=k(@O2`R=exZ{PmZu-~6sY2`i{`l%;m!(|PSQ2}QZqkh z=&?5`v=ywMd7N7yJ5F$iH_s|q3BMusq_tfH?2M7t#a0-I!ro^Do#sBeE7GB;`f1=U zgH8S4#tt1)^%45YiQ+^=oc^?F@DBqKkD3@AkRVrm^r+`KJ9j?S?ob}ZEpAMpLUHIP zeTbmM#(E#Ic{lMcwXZW{=Zb6M#^pGz1+T*_h)?4_Zd8x4?N>fGxVL<5%UZL!7S5Dl za`wdNUoO34nobjF36+1)&Je5FT{}}E3`5!6Uw9gfGR490=qp9@f$Eycro-D8hn^V8 zort5ai;F{^Sw3tgzZEY@h!c~{e#n0*_vO%IHkzagt?=9*W14se(5ElbtDl?rQ9zos z6)|$PYfhV+d@;A{ZDfX&1eH1X1&#rHvnOo|)joDyKke&Yy<2~@T_w`Dbph?S300bn zht6)yX^C5sU%olM`Su@pXe~T+Ju74FWzX5Eq6P&e*9x5pYo42T+2mq$9RiUB9ej^N?Y55>{l8mz*#PWlOcSw^u7Hlpy$X zNXS=KRY@@A^>y+x|1%|-D;YtpVS2Eh9%f!!Un`^1+s%GL--sW20y6qPPZB>8YV=SE zadTnu+0ydL>KYTQnfly)eZw8#tE`ph5Jhi({PcP6%SXT+qyGT;>(|U<=r8``$%qY6b#!_GGDa_YHW!m?g)>?aFJNH4;9b>~4 zW`o;l6LMA5wGX#CpYU)v`n0IR?ZtZ{{G~6!>!qmScaiiA0T!ZvaM$GptH%urZI^C| z$N7GnHg>7ynaO2=x=g;{J$h^~LzR+H;Io9nhKd$dZX+4_7h*085KcVM-7WyQy(NuU zl8{a7$iBtvYNry$SY5X3Mgey1LavA?*%JFp!~g zPv-3y``By*`-wk5;!A++5LF|VoH?;xee?QTNlom|`U>hnWwSzhtSAj~f?fBwefHh( zl*-G>CQR|ruNf>vhmy%{$eC?olqS2|-Sn=tP0c%vE#Cw(3f6mGZtM6VM)HstdAs>q zm0d`4ob7l!BLQ}#grwukt;c5SD0%KMIDXbClzEF6J0GyH6VZh?s zeTr71VLWdWc@;Jb4uF#bP$7Oo-!`-}t6G0t!G=v)^qcRXD;65^el}+ZGx5&I!ubrBTg}mfG zl5=kPS}5s!V=&Iu7t};Zmw*ffYOo!z&7YT=*6g}sBfm4IMZF$5tQihG<<O zdLDd!{&VmJX{+K84ZoYxp__`n!ac%0s-6G&K4zK`k5G4}^}{q~8OAWi`{(x>^~8e7 zDBg++W6qn1e=wvJgW##1yL|2F@6V@PT%1obhJPL1ks58cqawbclkklTF7GfUyrAfa z)ty5`#h#~tx57gg?k@WJ_(@GhG)`n6ySy%nle5vr-+XAb&hqgK{+mzDb$~Y>B1bRa zui%2opCEHa`U7ZdIt)QfhsEN@zg8ZLV_||lqeuhBCN@c)`K2hP&=b&KKZ58W3H%m7 zy3`hcZ1$oFe*Q{9%{N2XX|#_rFtmiIAxQBTkkq#@4`4qQ=#J)AGb0-*DCLN;Hdi4` z=wSSpbykEn9rhDL!8)HIQTbl*QpgkH|8S{#GxglR`rtw^JWPR3+1g4$8i+HA{(vFB z6-(Or;0<+D@Th4NW7xaTKXc&4sjx>?{E)!dR3XhQ^#^3n@!nf%0x>iDWOz;fW zLN}ilne}AwLL<_$3klbSC=E`Nla&EW;ouqi>On$r#F3Gi{aO@EX!e`x;vYx#kv{7X zLpmWqGFPKvP!xEy4X{K}v<{-%M&O1OMX*}ArzrjE_MXZkik~FX(I9&9R@n#ih`0(V zUdd>K=U=-KC!QD&@Y&x?V^ENH2+(RIqln$%B`iLTtg(c0)7K`mZ~4{gT-9**65{)E z$9L2}+de6^i;Pn1vMajEnP-3;fqSN(Ih*`B`rWXRyg?d7oa!I&s#c!Wgi6t;T`mv5 zXQzB_n}SP>XEk&Vkm@H>3lpufU&Qj_i*Y2_o3E<7=w58E-umm9u31o!#+kUyS8 zB9^FTw>&yiG=S0c*6JAUc(2I^K(+mNSBb;Pfis?8hV|@|P~?*7ZyiD@vERxqN21+1 z{?Jc&HGjfJ6A}4pOHf6m4Eyz?SXkJSU-bI#;ZKHJUY=h<%_^2OC$dDO*1lo9!ofF175HT*du?f3Dq#Nyi0 zv3umMlsMl%y=U*nbO3hrnu7WH4Y zNoc6sVm&}H;hoX;p+t9d5KVRVf;G>VXgN7Qq?+ja8~qx2IatcYjC;nS8+$2%Hc{mQ zRnr)wn8xqn191&mo&ndg=L#dF33pWIgw`$KgCak^{`7VWjg;-EzOy;F^p|L0sU5Ia zcuelV)YEiQ2c~#GN9ph5Z%0Xky?MudLgOTD_P>_$ZkXTHp0ldB_Wf~bLl#||`}5t| zD6#cpXBWiW9|nb7{duN;1ppFG=cW|dp5T`A`GDCGiT@Ti2wF6^O5U2f#1qQSNgGG`LACu0^Apw&iEmztmCO8>Ls;?)=f+l z*k?1>ktdJ3t7#vk`ArrVpM3umr1Uy7Z1`1hA(S^!;4_fe!g+Y-wsLJ`>XfDTD92Tj zxLWbgajk!x%Ts@LPFz}%^!I+Un;jEyH|oBLbrCS!K}r9s0oyCJUZ$$6#UwFoo6fVZWO<4vdQ~REp0?#*ks@jKe7SoVq4cu zrbk1O;lh{---zU>YvM@pQb^6a(JO1f^!KFl>FDXg( zpyB}Qu@(Krev0QKWvxuJ&o-bv5RYGC^ z@)N%2LU+6XS#52dSzgH#epJ6CPh_|x%?8+vRzm#u^&o zX_IH=6p~m-K)+v-07?IF$u7~iwu1B9uC?r=EdVvkxH z84^bhD$DcFPC1G^D7N)#W=)7vj&G)<4W$2NfpAkH{{EKKmEB@q7x2gAQrq(h-*AL<0rRBr1e= zPfyX=-b35hr#W5O`R3#R&VcCgajG-n(dTNxKn zMxC?0mT)}e>>o{_BmlWNpswm{zo(u1JCW*wmZ58A{PZ_3a2A~yL(L{iN#Q^ZvR!Co zCJPpPkec9ZudcXctZ0_2e&(ig6i`{1E7qGE(VG)x!YNbFNy1ZHUD+ePcB@R~r2uEY7$mMm`Q>Tob|=oNTySKgh=JJrl3x6}cMB|tK_ zwNLJ^;q2meWuQ=UEBB=lC`02^^~1ecDEQ$NQxO99 z!68IwP;n*!kk7a6ClumTtV05LT8e3_o^oi=>!3KGxsX39%l9~!%)Z+m07~r%g`~yk zz9sX|vxszo-hfF-T52?ZT)2)hmr$9V5TtGu@$#*=P(%JrT3O;5gUj(HpNV!qHOloO zC9Ky;NhiTmU0^uwlFCkb8LGm7FMqtW*fq~kKsKXqqT*U=e6>%>hwq~5jH6ONm)y!h z#kFXdGM}>n${<>4~H4`m=$;3%iB4N)enVIkl;fJH_Oc!D`Mo)uB`i zX{BV?gVL6;YVGMjv$BL;9Z(SE#KBtfXtiQXt3-l_>o1cV00H8Js^23J{p*D_(Pji}Q41lOILtD4(nV5%-1KPuNHu;i*FK%&<0xEy0MwY2IqgN6Wvl>s_T)Ro&6lnr@TZMHOgr+u2qb$EwC@3mV}E=qqDEMm~HXx+C*CY^^LcvN7+wQj+QbLIlThiO_lAQ~kNQ zbIjFt-0?}1b?3z6L6}L6>XAU58S%m;WGrOd0ViMUOcrz380my zJg8HqAJci4$uY(!aHd_fpj-HPQ||=ai{3Dha&#;2S54q*345POvlD4B~*+~>47K8 z4>+b==31WmBN!ge=p(vyDi49ize<_kGd%QK{6k%traLQps)x?RO6RV>MNszB{h@4# z@7SKF{y}HPc~5BGc3~URZkF{UbsVyGa}^lAa=G;cS!^(0Th`3HNe_y;q{&mD2RaqH z0uWqRZ^dCRD;_F+m^skuvWjZtp_jM>w%M0MUGT%FuwouDFz_y1j#!oU6SmM=m1AXa zx$VxS{9*M9H;g)Rly-2rQeHg;_Jy{E&;FDB<|&RF2w_8bli)33aUs`JZ!aNZG%x*h z>-_z`-{N#KQ~wy6L5F5GGu3fGMY%UVNif#Ea)z(L#gR5D&;21hu)IlNXiU{1hPn#| z&9e9rnB*>D`k<4xMo`Zb&S2TNWNU~gGIDYks(K|!0XY`>oJp1RzO)A~%Y(;|#MuGS zMl*d3P%+X>$qP_(51%P?1Y597_tKu6U_%7aSVDW+Y((g%J|N3VJv%-GUX7uWE*pQz zZxUo1i5~7A`g1vbURQ3m|5SkATybFJ9yCdJBH4Yq?~G1hGRZQsr=VhHK6A#v6Ydn! z_1|#%+x!O;&mS`-VD=?I`I%zv;>K=WU)OnFzxPcK&)pwX8S$(kl19Kg@9&~AQ*8;g z^uec+Bt)_+^TT+&pgUVG3M|FSk_LOcoNpq~{jc1IU+<<&xzkLjjkeKG%vaTud_maG z`KUinh}=5r@6LZbA>& zg<)|lh$TJxV|_%sY}u#i;%^|@8^bz3;(_25Es$maK_D>4J!v#FuM&rFMlNv4ES%7r zRmOqUlm)9@-b^N5pJt;hvKUqlSEfSE9?v^&1V*J$ZU@8qM0+P$pZ&KkS#1e&Ff{kc zwjtKF{P$M)|3X!xdUTbRy!0L`6Ctr(02>3Q^RlNcGa+jn$HIVmF(yeJP%rYZ3P;7| zwUwyK&P(@d-$!FUv9Dk(Mm}x;60_~vvk3F9r77n=TcH;a*y^F;YJS#?19S3`w8}@v z{c3r(YuVCMn;E$Sb)%0MUV!{Q?lfmkRtcIr^Ei~`;?Ii9nmqoz_c4c0ZbdYyM4Adw zzH*cl5pl6E@2PDm5cXjRL3#mIZ3oG#C0UTN{62*P=;;ca002ok$r45GyRXf{d13fe z7s7=Bo$;TB7O!Dmu66rX>?lDvMH6@9u6itIZPQUUv}v}FCHmcY@7@hfK7Q>W3*xX4 zCNLB67rAg9))Fv*P>i;6@MkvG*%*LMkc1>U8_@+1qCu~+BTf+@^Q`*3jF)3Y>#cfK zX<|8Hq9FU4+7ImwVM>#Kun?i^Y=2qXW41{ZmMq+p*QLW!{6e8DP541mmbV_iD0~r%qq&Jmh#&_Td(@3tw&b2KWS+k&^zcA(H>a zV*tO<^m;~t6IHj&L)L2##(4ZObh+PKe^yU}d@Us4QA_1Vw&c~ieRzlm6Rq%*DspK>?e zCp$3|e`iCUKY1|JA0vQH=db)|uA0942VbRTE~WPA&5lX87*|LzTnCG7z5niYL3M%3 zl4iwb)Iaimk)nw3X7H<99&7fGJ3k**Z7TdEpS-d8>(z}!v-4ZL&i^1sw!iN0wdn^g zKYAv7^+~PvDdsbsc+?dVxaeyKA+tPUk z0p*;h>OJZUhFkVbmDjzCO6zT^;rE@Tm`>QO!?!uBkyTIXqxW}@j{Y59RcwEvMc(K$Ilo_j%IQIWP3Le7Ml;Mz;n*2>FEsM*`vR<*Ya z8?eY}iuLyOYVx?T-R0{LW-&MC#@wBloSL3_Fv)kiovBoEQF!=lX^Kf4PsQ(pgj|J#>6K%4I;j#k6ZFHpym9#YflKo#ZnT`f~s zXYKQJ6fJX>Hyr89k?7G`pc+@ggxvA1Ch-&s6v1J3{Eu&ES!Bg zRzm9TI9{aYF)8EmAPrik4P{gNk+BJKYnLcBdcT>Qo1#j}Cv_Dl0(`vLf>E_KJ#7h& z=9OeSIyp)4;%NqJ`J?m`wg&hQ8j_>g7w)d={$-5_`DiY#`fc(Li2{4gbwiQBt1~bd z`cgKbgPI%F{a?d3>`L0BdolOx4U`YZM#e_vpgJM$NN&nB*LTzO)XTV7zQ0`l=>^I0 zLzCQW3O^$R&c1Dyw#G;yqn?}Ji!vHFn_o;iOFE`g15=#*5>DZnIWwKX{WK|+_moJb zPrU6Cm?S3is_(6o6eH~omygu{Aey`-w4=>zIngc@I~;F#Den6O%#>S)4?ltw$1GsO zSe_IzC|3rH=*RR;Nb?ZBQw$TR0FRTU;$-P)4fKISetGJZygHEk6w0_bQ}N%oe6M3W zrSef3XEr!VQq#mdSR&?nA_}`j7)Sg_T2hFcQH;#x$KJN%shQvN5GiDDHA>=p%TE|5 zc@+h;@^H{*@+>)rmv-7nGjfkSo;?#CY;(5>Q$l^(o+* zH`UtnrR^x@{bz1Ol*1T|g%*4y+3Q&N{)+V%Ntf~7W2P$I#WwcV)jWdvwOu{gCkg4j zZ$chC8v5|yIwt)71LYiBl~?b-di`od#bGzcC*-kRy@T%{su)1_rw9G$~bN9=n zMLE+6J}y>T1+}hK{;KAf_rcvzPGTt zC@!vN)!Tm=WsuRU;CCH5>cYKW!&qE#j??6pvl>e{ec{A2=Z7BV+4eHtImJdW#J-1N zHUbzvgW;vmnzKsLh*OM*QHMMwwThMfC1=V-F>H~@FEv~O7oi4Pjzo0{SA09 zi`OVOYyFD>*-KWRhNTOXpB}+EV@10u5O*5g9C#5!H{ZQWyW!T)xZaY;7BVeq$#05Z zzrp`0#zUio!(Qb}f1YKWli6&A4+XJtc;Q*1A14pTdn6WVlw(34*q)F+O^vC7aTyM} z1&=`VOR~jI9-O|@JC0hjz@zc>IM6Q4X_z1^OX)EwK?+y{l&09!7~si zWyF0bAd<;|r6{DD@24TWX6G@G#SwU4Js|hRu!uFO2z4bs3~U{zC>)3A7Wk|EmVQy@ zAC=8rwVhcWOhw%$=t$h(3_iftiXQEyE+|fljh0yfWlV!WyC{t2P~t6qbMNz)_=`Er4T%Obj5SKyvWYHRQ?aVu%A@8un8R&N83J`6Ko~q zEh&r;OhBsRXDJ&%33F}$W|^8QePucCnocfqBq;Rzu;h=g$bUL@Mm_9LmNXF+Z|@!) z&tFfhY_3Q|zZTMwUQ5@-DC~eL)KS-0a>yyUcp%;&#JF>F^ZZY&trMcT)ny}givv8=rV7p(PtRJu#~CRra= ze(ffyL9}{vbgqOh-el=e;SRLDr!}kikbTPi0T>2*902%%nnov>Zi#ux!zEqyVjbPe z$2Q-8Vy8teg!GRzAB#W6uzyPZV!82wdqj=2x$Y9-h+&LDt~@wWMR&YM(pu1`6VyD ze<I_cuhXAc4 zqN})E?UTPy36T{5RRvf|JyD;vdtr+CaYat!Dn;o1>=stS{4T!hnNw2FZ9k1WFlzu> zG<6WEfCgo6ku%CnH<2zSvR%4tfFPN?Iu#gDJ+Uq%b>ue*DSfr`*GGE=`tISmKvE(ExBhd2f9>a3knM}_FMfsi%`6~{ z;_>x#gF#S^d}EBi{`HifMa#Ah+mf`IshiRrLd!|;B?689fhRWsEVH7vSk}J+oHOG$ z3`~wa2X78jVv2H6yf^{b;+qNF0=2zYE6*LpcJFykP7nsRkFokg4!#Gy7I1vU5`4Q5 zDqwNLVf}hyyp7u|{=cs`#E~byzA*!GA(bcM|N9Ye!%T1`&nMXlZ9pQ96{-&L`_O9>@+T( z{t*@r3fJLNWuEDT2s(y2r?e=XG-wwj0H#OEMk0Glk_s^qEA69`%dK=?ngRzB_n>VEDFRxKxvnRD<)ABn(qhUFZ7m<~_pX zIIa7yQ1V1svP@HgL{KNhf8nvEQNPT2$~;1D;V6pJtUtH&EPkcYBu}f4WOfo<7(X+s zp4p)7V{`_&K4{qTGV*_!8||7!>W~yJ31yruW^P?xwGY-(WB5z%Y3Wnp@9fjHE*Coe z5_8!Fd2vO_DXOMAoHu)pt`FsMqL{ttuNm^l{HGzTHqo*sXtp&0i~@gFm`ia)nkAZC zeBC9L%?0mK>T*(}Br!UKKbiPp;CfX_(Ri@dRcB-Vos#ZEz1&^iCW}(l+v!)sO5H9~ z{-fX2tihX}u_OzXQP$nx;XpqI7|<1+CKYZ~swGh3WnyM&Cu7wpqt|n${MCr|X+=J9 zYM!*tjUB4OEjmm0dgW*|@0aiAHt+l||74nhm_gHzCNKN=lF0LcwtG;+u4uO-euRY?Pjh)f+@q_m-p=|b#Sz4)`aB3{p=DaP z6ul<-%k)ZDemjazDPSgnAt$v`41&{x!)RZM3uDpQzJqF9mNyJ$>pmQ>*`*c>y5fbE z#IBtLW$AD=ZeEFRr}&~}3lC0eQKV-ySTJ1{B|GHulR_G<_4?G08;@xUqD9g~nTX z;#i_;=i=%=opf6=8K2N7KS?Q$W1T>+qB)P8I z?gx{SL&V5|d8b-PUtqLa1y6#836F63bynL`oGf%icZ-y_adXp<{Bu;66A4gCE9gpZ z6zDnlJ;=4Q-ZUnutn=kuPP77)8yA0Ow>ihMEW z>n)S9He+>RQzF0=0!07_@ps@8)*2i>g54M0(ft+O8~PJ>p0!wz%3ruET(p1M@oo zlTp%rqSi53=C`CffZ>Q?)QGpTyjl(InyXtUf$|wKZy($~MoCc$71HOafbCN^U3>gexp1$UU?wlp$&K(?UJGW`e!GDF_5EFBQjTyiMpVC{iBd%wTXg z+)M-^OMnz-42$4dB$FDW-;1*f-J>N-)dsXad#LQPn*Jm}yRbnv=b4grZgo^ff0qC| z$M3tcb2WP+L$VAB9duh{8-1wzW`=Pg6Swr&&G!;3fSK(|eBe7NkDY^J zsh*a8?(e5s42f}Q_Wwv-h_ec}{NIURx8fa}fSb6F^Y*r{K1=T%8h>1O_nNrx??P#TK3^3b|I7sGSXi(tb>Ugd zXoP>MA(RI_r5efpFgzqE4a0(mxwd6g1*aYkR#y@pbeS7nJI~_N1vd#7|7O{-_`8mH z<-aN#-U$GO_J*=VJ##WqAPG|(b&3B)@P9vH&QZGhcxayJk=6q|nD0=sv7dF;iCX2I znrcy&F(3^ydw{-N`#VYeqhv>a?9hkfMQ=$kFUCVPOzWwyvg^F6&*8|W7VC5 z0oA+aM9-Rxsc>~zKqW?ZuP2_^eQ&0}YUH!l7DJP%6^aHrV1}oV`2u z%RN<`CjO;*iSeix5NbFXy8AM3lk-<#7JDGziuYHTmD`O2p68Q3RtC(9z2;QI?FYRa zl@8G$EI!|1Hk$0hKJq$al@N^6!Uq_skc>Iv5s0Qk6-n?>`U+x}!S!zg(zBtC-4IK9 z-B4fovU1%=wza<$!GdT0RwEoA8@*PRqLVQoQH0+6>gM(a?%&oOGUmC_Cj4v;2HPy& zzS%dpE;`HXw4Vz*?$Gd8RLWezBm1->R)F>G7J+knfC^7A+jfl1L)y@oxU?TeeXlej z@;FG!L*B%QSJ}xnqv*8>D$`~(e|lmk=-cOv z0Ukk8%EPKy#Suh;w_fI}w=L@u@2T)bU-p~bYCbmvpZ#?CQ@(p@*X+{mMCDK1GqMw5 zQ>QJmPlai^DSv;_dX>%H@SHNM)?2$HM%TQWtbS`~%j&@W?SIpt1Oq7GMvra1uYWu$ zJ#XM9ztytI1S~`+jGhF(z4)a6@`~{}&CQdF98S=n@L7_r0_k34-uCj1X8-n&HjLK* z;b!93U18a`k1+D{vokZq=vC>6lXh_lvd=L&)=mJ_t;^zdPhe9hhYitTwu@7~K}zS} z=krz{73a4(X#crmRpyw3qetef$C562b4!43xqNYUde7|dDRoU?Y`==)bv}ATd{sD# z=iGux(7}~2Uz5~9p!e*Fu&6~<=YL!eSwWv_goy&mTJRh%6>_-9woz46zZiwI z{SnlCuuj^Nxzyh9<9VDdpVCe9Xgoyqm^c9DaciC*x^u?ivs?#C(tk>%itU%mxO;be ztU_I6Z1t}nIFvXFSi1qC9C7Z;vv2x>zZVU;@BBQPikhRsIT6qgs-XJk-%5s$-wHt{ z7P!lA2K8M#{7y7Ex+jRHA{=G`nFK)v;3UnhC9DrxsPf8piN-L3bm|!=vis~c z4zG)xg>XAo0Eq_N{|7}#1kf4ioBvZG<>fO2Tc!%Bth}Ov8HT3TCMR&naMq*%+U|-j z+}u3e2wqlDf$b=f?d~vBUVo2|(^1$~fQ4DX<+;u6B;J;&Ep>|--k3}VM^@|gfa2Ymsw*l7pO&@=d zl^dQX<~*sgl*s2!s%Jf;O6hY^4>{{TGhdz%yu;%^OC3v0%tzP_e@j8~6-OUZn3UwO z*HTq`+9d(>8k(UfQr`XUsx?HFO&yYoAK@2V&H(Kcx^R+g=DxSvv%jE2yd^~yh~usp zFd3<)`t98X1{Sm~6~N<8>lh|l)ax07st=fukXH9#K~3%f=Lw zlKeWXSEog{u#osf#V(Ou@By*rBeIQ2N#4m3rFPJv=?E--z`Y9Gc&XuvadM{NS*7-9 zsTQ0M5X+clM(@Oh!;dM&On=ew5*5ULw|mBtVg!R?f^o4=fMa-Se4b0f{~vpA`4!b4 zzHRR*hGyu70qGn%g`pb;q)R$ghHf0XVdxYFK~iAoG5|qBP(mauKw4A;L`D5_&+oq9 zJb%Fb;#uo?Uhh|Xuf6tOpX)l$8TJsp+e_;+PP2bM%O{1E}=MB+Es<9gUG3b$4)Kos3(Klh_>4c!j!?jQ;yMg5E8*} z>@`~$4NvRvhIOFJD4cfES*t&6PNsvc<|jX~#p&K?5lflVu^CVPU7FwH}9UuogmjF zk0;2X9=9VV#tLK1Bo?2%q3^BxjU1pOj=eY4VTl?|zD?W7ablqpA{j;SmQvM*P|2Bo zUia;so^0l!m5moF{r5!J8U*{M=eGrgU6a=Y!yTrmgT)-H?)*D6{7NypmHCwC z&oSN4Ss45p`6pe-K~wF2C&vR>P=uzLBhL)Bc%;&s0|%D3Tpd=gD^FY zrp@F9XR&`IKivcbiNsjexjI_$^0A-m-=hDEL5Nbyjx%t`sGe;uC-)DGe;qToq_Lhv zA`bxJclac>IReYT^yKXENfyHq@|;a1%aHkdh94912zWk05%W!$CWVQalK@ppqE9~$ z#4#!#;5073=i}5rUVhEcqY^Tw@Syfk|GVELueu~t8?}W*96aCsx06aMVfdT$x7B_g zIZ_EkY<6KXCi1F^A9Jst~*=fM@rz)+y=XxxCSY{8_Mg);Cc8 zcu~swBA2UPYWUfL`oWK*il;G+zmSH{&VDS!XEOSbReR{az874!No_13(_&OkP|0LetlTP{v-V==bet-BGe>b~?XS1` z8}0rMQ6-E8!~53_@t4+^*0&`{pXb^vl)80)syuiQ!cTAUm*mLp@@~rFK~gz{%&xg@ zxcVOHhp!6sSCFaL6-B!8(F>dBZBdU6E?$y877{<| zI+Fdb&WK`TC@{Tm5Y0_~E8$g5w%(43P_(P?X9{9kXM??7Gi%quFi9ttddKXRkK^v5 zK}v2EFX3UpZ};^>njf7Lq1bTOQ8_e98a%iqJD3%Nadsi($pUc*~ zW4;mcG|+PCdgLQv)VHwcthID4Tx_LHwapdfTIEW9^l6_|y!eFu_dGlI%Mz)(%o49t zy2_xQ^{>@BW?w%%Ivbt#o=D1GZ>rJPrr^lEopM)=t|W20S7Hvr^uX{**SKuI>pNuR z;g!nA0kXNf1@?u142d3xSy3_CrI;dY{fy^E7xDck0$kc?ae~a0$9f)j&9;2|f_`XP zg3MjMC`UZpcrQ`z;Z{+d#8dC>SH;`e{4bvG?@0B0>u{qD&HowZxN3(LLAqFGgF7>%AEWqZ4G>v zjvI$+MaaHF#m;h&Vv>pUdLL{?n2lzAa`QocK90H{dFZEO;d+Aa$~!60Q3ii-)VI4| zG{v<1Zbq9|tzzxTULQ^ME!3-F75N)$-gh|1vl}am6kl(%uKt^}h$Oy^*8g@SauRU0 z`d+m)xRKP`eIFR{$@)G0Z64N5N&n~<>5!K%b?!cGW22PNU}S8C{1`WB^zO#A1p!;D_8u{OefVLhIpqVx=6#FEn9O_P;n%;hgNrTgmwWy@ zZ;pIFZEcZ)?=p|L?4FzOtv&C4F`Zbd>b7DV6;U?w6?$1r6hGNn3Q`Oze#e_ENmF2KRLoujN_8@g#xFh6FxnY$XPfNy z=Bn^r`vlS+r@TKQAu1!@&S`7h)oC*Q_G(66R75sDqiQlNY%QiVD%0vGMbd&VIO1+C zc@|f?0Kv_jAw>kY7y3RWt7*XQ%EqpwK-{I={}h?s!)C47D(4JqwiRo zZwgXnDX}E%_CZwW2Yb`>A`gZTIn_1c;zHy9l=aWnvcIG=!3yA#-qyzGE0C0zR7i0^ zlJ%`GXMyGj{Nk_3R)Xu+THe&Ii@EIWR-q^XG}s1JNEC=7v9yRxg(Q#GxnIHcI@c5% zYm4*n%3fszU{qO%`iyZ$v8~vQ)7Y~@=&DEdw%yl0Tb~j(TW`0NtCg-OpqVmBBf6xe*s-Owviav`OHn1Vn$oHvrisAOS~g43 za@4XM+&XgJnl#+{aHF*X-PWMWU0tj{eAL_@-8P;@@$|BFiI2Z(`clD%&@P+uv=pf4FSl_mS90x5V3SsXyH)&K_B{9(ku8#n>L@ zsvgym9`(098h?7woW0s=y}C}l`mw!+RlUX|y{2z_NqhnfXP=c?pS4q;ZET-?)&ETu zk~8D~!yY6IumKXF@&Df*^#6H#kj4Kcdr%5Xz(L(3=>K~aLL@_#mK}mYjAW?dgX&Vz z8SCy6x3$$MWITGO3*7567S9zQL%7J3CjJY^W}+;W}|d^h-GH6?@Ehp7e{I<#(y=(xk@#hHKJ~@_J&=n%V!(+ zG-`^go{k-2ztr0l>_^3hBUusSJkR-(`1NoRn?BbctvjguGBC>MQ)TRCgH|#fuesZY zx!=hQf~CR+jSJ;pjUQnd`P&`oJvW1dhCHe_7{0hqNZfqMt>u2Y%P3%IO<}&BvPV~X z&(xJ4%47K8=j-kVYV?t0-kmCSM)Xf;1(n&@yWkv$hV~nZPn%!gf5F|dkqxKa z$TC$MZrLE$@nLxff3ut6_uyfF*1lzVBgbkH`^L_ps9gK-R( zlS`{xeP`Y#cWgEKe4;Epsfy97`vX(lP?9a9todc`IV6DR~4@`mG;+%IFuzLz~0S$K3=a*`^~$g3q4 z(n#5jh?h#KqumcLzX0h5@j4@E_iQ#4fBke}64_!%#YPqdP{77$Gi;yS_6IW=oR ztx*8kBQy+dIL5U9>$)_VfEXy5|8nO*@R~L3lL#E69ol7 zdnhUY$q=}6yY$(ZSS-pZEuCWpzJk`2dN`h%hDSfIO_1&jRv zOn_kSrMBucAM(s^KB4OM~h-78xh}D3F2#1z42|X_v**LyJrds1pLqvEB3j6#Xg2#RlQ`b~daif@@J7si;%-8dQIc|0EH`TZo$Ra7 za% z?fUE6%r`ke6u&lKM&_Y8&zyZJe*J!x@TP||8m%r`H`zsPE*q)FxO%e-I$J!BRd-Zm z9@BQr=2u2jKl)(Q#3n~z{gw5rCC=GYi0!;CYPd%7xmwi;g+6dig)$4NjX3SP`G6> zK#SHY&gWC{TV(gz?H^WPHe2w-WpQ4u;Mz-)*n z`zB>;#iG+HcD-uxUeB9eP9gs&OeNJ9v;GO3-;tUWzo)J-*`w0>KM)=i4`6)m-5~`|{^mz&p#{yUq z=-U9)v+s0R@d|*Y1w9ItfJq^rm*nZ-fgJE?;#7IiOccO>kn^)7oCRyS93|J;km|5| zt)tvsx+ng*4456IyED+;)>+! z3GDwrz8+%GsX_FMD0{4m#q|>~13EQkM#GsjRFWyFa}bZ3qLmv|=fWwdAE+|gsR0CF ze?MD3GGb5&IvN2~p8HmY0b&c~c@!1>iWQ)yoQr`9*-4<%I`!!dKLj46jLD4}GF38U zhDFC$ZS(Var5!LTHmRt~Vxi)MJn!_-%uL|Q7Svx_^{5d%N#=KYm}1gWeLevt+XpQv zs|2S(*he8e3vfFOAh&&!1}_mI=ji;5F;X<)hA2t{4iepr+WVb-y6b(+UU8UNcg0dM zP#RbwoONMjF*1Trs+4l&q;#Cb4rn8S0Tt zNE${F(wix+LfFCQfhD3qt|)YGrsnFo|M4_%seFIL>&Bv?vsB%ElI|w}MdpAdz2cZ! z0ld*yJkO!hUyc4;Y=yA_LCl*?rn8CQ{c;(%;^XoJ z+YJ-#7Be`Z7T1hnABDLFfZQF6(;uYYQvs=?^#9w9ob zZjMtR6YVkB-Ga&@GVKbjjA%E7Mg5Yu+Xk&!R|)dzHAfDC2E+b)m);8A zVvcEGRgGqG0LhKkuoy*OmUav^2IZ>U$J%2rn*foMk}$C#N}y55EvWK$XZ3He9ggSN zvJz5m`G%6tIoc^2C3nM$pm18;vCSZgG*pEb>SuMuR+=2EMsv1x?9V1@V*x~8MONgE zczk!$ksx9e?(Wzu6B|Xc-|X+KRvN?Lpp^1MXTOvnYK5Fexp1$X*?9oNs>F z%OUP@w$jU$5o%3Y<`4_8Ai?pkulih*Af9Ll6S=W$w!JnI!cM%dJkm%JL)Su%o*@I? zs~AxiwQ3+c`dY!At$9NiP5c)FN9>Sz%E2EBL+&L}pCfKKA;FES3Sz+n8MDO@6j@nS zzjO=pEfcyHL$Kxs->f$m6Qacs9zJ&9t=u$xB!cB@$;?2(R`i}$1yQ^$L=7uRy zv}Hqsg&3y}zZ)1Sa{ovPLP?BYOte`~X8!I(+hU(V^N8i=XH|%yw7z_u#%4p6eBV$& zAd#vsX`_o%+*l0Tm*IV7c1r~06Rt~0hQy*EtpWtPHWYIC(2&u zzF%^1_N2+KDUzzz@=tG%YQE&dt|a5qqs-xJ5zw19&nRx)VD{GSN`_G4IMPA<4cOJ zI8F?j`+{69z_!_adH{FjR{Mh0)Hb?)(K3TzmzNmI1ZrVFe}N2i|jnyf3zu^&it`9bw+`XrgOBoY$Z-?ll4?xyXg1O#8tm*=VxOU+qvrjTyHC% zwv>QmN4?n`ubKz;THF43Lv9s-F{93kH%yz2NEWJ+N4ooOJE~Nk)>fMf>(ctgIMJZy zTLd-v!@{hKLHt;#7J+8_v$G!egI6ei|ZF_67)Pw{H(f49j$AS4z zJWJ-Q=+Tf0ZjcXmb@hCnYLl75f|(7s8rKROf``)kjppUpx5v**;GpA_$(P%63s_vl zdXIlr801-@SMgHzwE|hd?7@o$4^yDt>%QfZ0m-W~-wv=~VeYe45kl`{8hzc{Egrl_ zIkG^uB|jiBALJ&%0-J8t!6DjipoQ3&b@%ug0!Ku2(G&0bciRkhj~%?^Nl&jh?yGk-sC@*%a@z+w?0_bOmcF1i-C zsj0{0C4TkWx%LkHn`-q7n@xUx%#>p2*9AFo9G!>=PZmNa==Rm^xX91#IW$;T-ozxB z?bEmk;A1llQia7#)IL)Qff)0Zxp`dchv%I$UnZ%p8#p5aBUnPKZ5zf7Z&-;OTr~(Q z6Jgr8pdo9Q{Ro$`74W(4STgON0}r*+li5`Ad41E{F^`h&LAZF5jdF9LJcr(u5&%8S zM?q~1BLCVDnJ9y_v`RP{N;d>cGDUx^-MIRBo~ zEDw6Lx40@$cD?4SrtBO`OHj&$$s56M6_x>a&A&a?&59)+J+nIK#ckiOY@Cx9yd!>+ zAE4j}z)JN3G)16dm_dd~sKYA!{k^ZXPoTeSo4tL$^ST8v-Q+@RTF8t>|El5c_zxbu zc<<^{p__>A19iM%(V_wX=8tp`#z0X3RQ7GfjpjkxkAgZh&&f%0CO0R0&GWd9o9w)0 zp+>>&cc|$2Q1<`o<&7Rqe7zP=%02xtGvCrus`r=gH3LdY&NM=6I_!enZL_{vU;$;!amwsV?_Y&ut6!hxSmoN7E zEPD=}6ITbcf8R{Nd3(v6>M!k&b;{Y2v@-sC@(hQ;{h2|ANa*VB*<$b=QV10sdxi*O zxug%%v2*YzBbR{wZ-r2bga8fAHD|#2|D@$g002>ixLZ?8AOR^G9yHbh>|DIUybq19 zAsmA|%|qdD{R6yT1SE}wAQ_i`u3x7nvoTc8T*<9gGORehr8-Hhdxp6;h~8Wn zeM4d2?UU;!7^JI}j1=D@XGvs}_0pzA9VSk*Qv|%;cwDtV0qUpc;;HyUx*(KUg(YXE z)T&;*hhMUE+oyGX)YzW2W9VVJ{-iDWlHQHPkA$+*x~gvCyL>xuQ}MRCIJJ6Ab(aEI z48u2Fo*EyT?M)fJaa_?fl*?`OR4n`1E9aSqpTm5TE0sd^RkM^j1pxKurfi;LNnmzS z^%MF;FpQ4ppjgV=u7K1v%hgn#d8U!fdK{ig2gaAZrH2s8 zTy0I8@u}oT%3b!i-i`g-fFm>%Yt5q9>^{c(HCFh<`>>&OX;qjO!4v}4?!L^fjf_@ zSLTcu%RMy6x$?j9XN4)MzsEtpO`{E|85(dpmIpcLF;&M8%EG7*#F{+ckYSW4) zG)#I-Za7#x?zsVldUYr}tLGdx$1NRC{w`CLa`OOyJj}oW4uq2e3G+wto^6HLBhkF- zi0z4H8aAVsPu@ivd=o@G;?R1yBST06`g!SW}d4e6wHu`oJ|`juR(&&mXE2z%tM z$gWti=MuFH{isuf5me(MeU#$14vXvw4kCcaK)1iU3wFx#CfjD_ z4a>gz9~+}X(DZl(0Zum(fA+J+FRDRvd=mG_DPHgEbMm_F%u+Q+(4Nb`lCSA9>M;}0 z`Fk9lF1^VUnU9++Sk*q)F}OzbGom^{M-e-mRc^K(iX?HmF?>_!!0)_vo87{U?Ytyj z8JQ%3xcUS;8h@8gM(lp-XAwL6eT?}R0OGPIDN{tB0|Es8usU%+GY|R(RpH+7-)>fq z>^Ibg(*#l*9^9qfDi$LDmG1m2h3XD{=`tA^z$F4i4lmQVb10MZ?F1x|Nle|n@MX&K zM$;&cy364Dhkh(B=m>`u?#1EcnHrF~&ks|d*lgR$j1y7!F?=$cF|NCF1O8Q%Od;5!cXb5_AY z5iAC$_yxEEaTMgitO=Dr(&;$&UifcNaFG{y zy~$tRb~xKa#>r!3>G-4&9|7;D3N5t$WXM=YruQ7k)aO)1D_d;qgEC~V(?NMCN6TM6 z+Qj(;IIr$*vi4Hqv86J-!ftFxp!5sT=+LTuAw>xK?tJ+H7z3iYL@&8o8`%8*LnhB% zIk6T!PEl~8YXKlzrCeUiDkHRL6e))~2pQhg@|=uV*l?kgY>A1Tcjmk}BSfQ@Qz)wwd3*#gzLhmEj8ASAlQk zEUi9z^YF+NnNv7wG!b z4ywAl*xZe)7{mVb=dW$)WJ59(d~@AQrXVc$`KYu&9S^5|GQZAGlptd`9ZLa!Ea@nF zRxKO#!tJAnRP*;7UP!SPrtCQy_Uig5w0{%CWVrKW6H66wFS+zf>G%lamSI$VCF_vx z;-f5UG1d-TN_mJNnTXY5eIciI$*(++h$?Wz)(np^7- z{`>J_O5v3OO`YR7>Jk8D^fr`Sigig=#H$0UZG{p!$}4XFjh2vu zUD!KT4UP~_Q}A&+6t})suI`4XN1pzizs5EFA|JfBmq2!9%18#c%BL0Qk3s2#q@8DX zNXhz0Y(m_paJIO3Yt%<2fH&ERms&|8O8`G8#$fTrKypPWkcKj<{(e9W(L~T+fC@|* zDA5T4(la1-1dXFXm|)|43V!5HeZ-b@`R+O!G3iHf=u0vZz+-xTHW(iD2V+*f30FeETu^)Bp}w!q(dxg6lc3wSc! z6e`VRFkYYa=0)!QokUk*D8!cEo1Eu0&M|q)1v$pG-0AY+?#UgI4ULJH8bwrH!nTpq zA(=&azRNK|p6Xkx0?5G`1seK%xKW6{-XMWKBcQl8BV1pN!3;>gQ#Yh%bVPD%KyXZf@PWs95 zn|pL5t$iOjVsI(SUBt!4IwI;h2)Gv7OE7u`^=&Ro`0hjbek)B0HER2V&$+c4FTJUZFpJLLu- z5@HFc5OZGWfOXuifCF&Yp8+qaNpq@tNAhx>hA@D{%woXUe#~HxLqbRgOuJ2Xeq0)v zC6g#=I=B$ya?Ea&V;{tv^Sx(f;Gbr;3@R4!!hj*5#QNyJ~UC_!+j(QKa?pYNs{ zQl8L+2=enqS70Mf_klb-Z8S=0&Je8P2FUItbHc-P4KQO{kizNcOKheJ!TrY#JrM#x z8Y{w2QjjNQNL*ouLbS>DZMB_X8hIVd2$7p`E>=h2tEPxMrJYs zSN=GDhyxaibOTsVAQZ%E3M>e76xg%+4@DNG>C=1~pjY6C|1YS5$GFU30V~qER4l~YN-b*v;G+VLEKMOC zO%7?|)J6BwyX6iUim}l^tV%r@0_TjI;1dF7HO(PhzKwx@(y)lsI zjKoV>gdYpFk&vG$na_J8gQ`z_GK4HwRq~l8z)P&zFQATHl}tdn+`${ZhyR*YF@7EVS;2h)_3}A8v=^<1#%6SFeCEqM^PUt^Sl?J4Bo7azOEBt}~XSsjHYD zL5v%P$Gh40fgf&Ju@!~7Gh%@63$zw^U}htMsqczr`H~`nz+%wa!jwWA`%CZyD0Ow< zBNgc^7vO_EO|NWxMA33W@;6c+6z!(SX#n6eF|k&>Vm? zD1hQOLFPxXfg)cQ8D=v} z;HXrM!AK$)Y6bC;kLrQA1ZtY=FQrK75pB$pu=1jrgAJq(#%4r<&RwFl zM@OCn0^TBnOakD<${sQz*a4}vt~Dr{G?4q2AybP+@&qh~8TzsSxVr%iquRT~#|APD zA56>~Idgp83Zf3kN1G`^ehPjR>)*iWiK0wA<#dE%S|#c@kqaZN98gLR_$50nX$PZ% z?cuIQZo*q0Niwtn$*9Y2QnH{5v89#<|V zXfp2bsqg(|yP(Mx$g2QEiM_k?9py5cM_J{~y${ihtK)D3G-zO{oCtQ+OJ+~J zU!R{xnu?7slxSqaPZi6bDa;jF-8kwrsaBmv=>{lOHL4I4pQf?L1A<1k$X_ntI~FFA z0qC1HHUT_zm_98zjy)%Arecoeae2wFa<1AODmn+XLsZQ4Uycw6LW+huNsbUd*t|fZo_PSDGSNT6t_}ILQRStvFY)#Ji zd=uwonkjyOh`Nee$%j?b<`ZiXei*LsHZO9GXB54%6V zNu9~}*wi_WvVD3P1uehelh`%U3`<)!d%sLS>^o+fdL-X3*$~pj)O9F<7^h6A&qZRf zxL$oVFS!G-1so4(5p&@uVVrps2se=2`vI*uX#6OnZCKGRJ;ZY_NE#2#*sA1{qGL{4 znE6Ld&p>B`*`~|mRA&NtV&<95whVWusw5?H@vn?$#g8@tJ{sA27pQ>F74^R`zw|fe z?-fDjpCK@bZ08x);P{VxSilZj7Fz(5C(fq%T@PO3@v50KXrFKcGfJW#lePNyFpGZS zr&`I`HC>@{>IgbFNL7C)j&y@%Ou+=)7N{r)5UQ!>(^Ip?bE9tRuF|*0P%niTUz*sGQ7&xYBD`~Uk=Cap!R4%pH zjbCQ;f9I9g@)dR6*8yA7!#|w(dJzpM9SNSFPtCM zBhP-^l)gKnaX_Z=W*uT}i0ddfF+P5k=%%f2wZ@~wO-XH7a9+&8*&)DR<=knA~K%?($kMn|&q<(XGscR;)FoW22dGDv^sbI_cy)^;o;}W8L2|uRRPIpwzC^h>+2#E>g4C zy&c2Xrr@5^Teug3$l%G=knGrD6$o5Ei_QgI4>zc3b#do}iCXRYT-=Pk`7TboRd8Q0w% z9DxE!&OC0I(v&Ep+#5KxD6CC8)p|B!b+tP_pRS)j%|dZ|VABUFDJ|hSFGp>9Hb{$n&GtLHe3|*L%AZ#X~Ucig=yi&hNp=drw>GUp}@(e7B3?giGQ_A;W3`8G%J!w zr+$ep$UWM{jxnlujlpOoT$?=52m(HpLhW#X{;m{GmQ_GVe@XiWjORd561T{(Wk+W- zibK4V5YU41xQo=L@jO3t58F?HfMCCN>UIj_WHTX@q~>(JUMhK}C3!{~78F3%;G2}E zR%lm4A#<^nNUqM6`K;0C!hw!f*3b=COmVVbTVfltG)kc-VwnPB1QcJC_1-DT(SDPn z!mO?4nwaFm{x!6sdZJ%}?%vhiu!vVuA~8o2nttCG(sNRr36`EY6=`1>wNRAf^>TSi z1-iT5!KpCH1|*o$o{%cw8y6w>oSxP6Ha9`aZgP`S~9sz65hVQA>i#AW7gin zK|Nld(DPE$9Hq~DbRU1{eX{M%PLv&dIQBU6KrK_G0W)TgAmb{~qcq|dO#(9-%0pzR zJ_+IMC<=y5VcMp>lLeyEtKZ+A{#Z_v>3N8z;zLe4WwkMw^%f}R5Eo0*-5RA#gOJ(*zYLw#0wx}Js zL)vK#C&7{U#PuyVx5T1ESO>Bh%dSff!K{^eV3-1+o#ITEXm3oK`fm8KJ(9}dxcNqR zktLnun;t4U%qEEad<@Juos<{W57tr^li8)ZpV0jy8L>v~mK*x+CI87aMlW|T>Ocq7 zs65GKFLMRgQ-+$;D(O~o2ZQrx$Jx|Jli4ZFL5#2Kbjt^muqs~zr3otlEu!m0UVtpE z0F+%LC^1lhF&8o2Iy>geeDwH4B0^GYC=;O?v+ z`zVKgs!Z_W;dH9mbm1bD*EO=7xoK-eM&<+3um`BR7$6cJ(2 z^vOjuwK7iIt3*+eJwN5c=p1h*v*B=}r;YFiBL(9OoFd7RUn5FDPbfOkT2TmeT?T|u zn0Z+~_AsO8Zv$x0$RfsdG3(qkUqg7*g6p@O0sekLbRIFuGA~>I(|39leX{u!+jpml ztCadRAAnizff>R9ov3(EaNhsV-fmGt@LJg99`{Zz|ZOuBLXeU_4DjYo!p-ufvJ9;6j*l?|*Tss9%FA$g2?1NYy9 z#XYWUZvN|ujE2+PObw%8hqVHeB90s8#-dQ6!B=McsyEVIH+?K@0`ueKUq7K-X~szg zh>9{dAk@d&ttvM_=@d28X-%!E%K*J8Hr4lZk<&@gz)l5vZ@{?-N~_GHG#3D3)J0co zFfF+c9hko?ekV5T?fW-9n4i7t%&g2w7dzHPxenY{x8n)m z@i{b@(Owv=8Dgk>`%PO2V?)N1MPT8Myh}!u2zx&SwN`g{VpMnb>}442SEJ%6xdK&*MqV&8wzklg{^IKJst)o-R`s~hreG8J}w(?Os0#mce;imNG{Z17Y+CelpvK-myebb?! z_dJo2RAL9{=OcChK_cIV!PUrT2m0rB*`{n(u-6qH3D?ZjJVa8dA6yhZ%>EYl*(sGj z6vrsEbE3SU(Cm6%LSD`hNWwjdPG9;&({ZWWdSje{@WS0rDZqB-6;fBBVO&ARk5 zhX9(tghQiHiR6Qkd)lvo6;ooWTrogPnhNM^|MS(qVYc1aa`_QJ+7DIlC zuTknnZ#8BoDe?gy>oRhbYas8J-#ye57u89QSU&DJ7UnN}h<^M1C?(?as zKWqd1Nv9KfhtNY0Rhk$Oq(})!Z-(BHUZfa$?;Szu9SlXf7?5rY3eqeAK|xUg8{kjb zJkRXx?CX8CGrNC6&g3NLd!OsRJ|xa7=+nCXzZ+{zb2RGY0?zu3pL$Txah^%~!_G;a zy^J6hHiOg~a_2wK)-H6z)?Q0abk`mWSp`hYG4ISVBPpPwGLMTa_TUxxEju{tVSE#3 zLRK=`Vk+dsFe+c|#(!K2{0Kr|lE59GaPO8x1~kZl7|%z9v2foC7stQIKzkb|^Qg!1 zse^c;wf{*5pkkPwzKk=d;3`vu&u}?4&Ji|#M^kMOxwSxOIr^euif6?&dHa}_v`{gG zYt_$N7rCvrB$01IU|qC$jXXs+MSNamff zOxQcmI0Rgs3t=TO*MtE`I0jx6kuFmQHyH+nU_e1M2}_31Wl8DVG1n~cfK7!hK~>(Q zKYXsj(!p0nXf18;(B|w)cFS;%-yn>dKG*68vyl^f)pPFq<^+=9mqW9YW_eLKcqA#C zfm@!|D73&Qmv1O#ah~bAD#3e+ac|N~n2d-7VthTNG?6*CTJ!RU{h=+16kqQyH*o7J z;(ACvOwff2ajZN; zEL0V^@)3T6Dnzr4TyQoj3cV&tK&JvYM{XlKIE8@PFX-QkC;MI#sL%NZKL>MC61(RM z(QELZ=#q;W$r{|UkCID{usjA_T(7-3f4G5vuljJ25tmPk>?jaP(g2N&ft@10 z!$i3SD+g*HV4=H`LpnLKY#jttHJAB=Ql*<>qe0RiX1yM?W%`^(2jL){K83XrcHcb{ zXhY&}&|bFyz{L4@ZyI|R44g^}eMH>&Bnc{u%>75XmFySv5gQ@=`v!Q4tDN?FcRf4= zQyN(Z*L)EvGs|r@qlxw6Zrr8|X)ZV9xxrNk^FN6W#pXrsgKiDMaL2*7HCQm@r0?_9 z-TO@1!!Dt^T;T{VkwdnHQ*P>9+b#qijzdt#%T%kupRDBNdk+4XWll@Rr-fSAtZn_FT4Z{#JC<_9IX z9pzfpJX|=$_j821)kkXt%wC6byTT8wuo3vFs?MYhkmbnzE>S@(0Q_s5)yM@Jst5@8 zu4m6?;z0@M8u9QWY16F}BU_8;=JChYUT@GTz%>P%O1ZQ3h9q&&$^wfd0({BOn`*MC zb)*VnbFQYQdyxxF*5DtigfzIEE?y8VisoXAZTeK$bWh4CN)J?l0hjbvFOLMy{4$qt zOv)?H`Z?pCdjyR(aJtKrD}jw0@C8Tm`j(cpnAo2q6vAL18{kiQa&$}r!7VK9*)b0t z(v^?HqumfrGp$FI);)6EOG}s}7R2H&sf1NvG?BKjPkIrJo%FP?8IZg4LoOC(kHA5w z`^{u&7R(vslVtgm^2;GN%kS{!_+tWTu}RP?&>cs-I%harZw9EBx!$Pr8&2iFL22>E z`Y5YA0%ysO9FzXdcwAsLwNtTp!fXBccb5Q;y5CGxJ#6d>=~guMS1C)+Td&NmbkE^U znepoB@=sM#y77QcuC%D^>!R=mJJ*|C+VN3IfFfqK=zH$f`@@b`@?$fY&mI~_R0|-! z%0%#4rr#X#zbFi<<>^JO!wr!x9F^$zqv!4RS6KA2<7$1Hg!!1q?U<1y(6OTuKkmkC zI81`jHfZ02?__bctuU~GT!W2sfiXLDb6fIhY`;!Z1Z##X-*gNFUnU~Q5nAAZ1oAPpCCVV67Fh66#SI*EgH5*{=4@Nh~ywMbGB zqo7mxK*`8CTd(V18H*>kPCG5Km~$#*Fn8y$H{@jS!&awYFVtDI!8~*qLnHU7W)KdP8n%u%bE@a*oZK%IyfCQ zM-Nn~P~ZAc=ijk$Xxk?bUVOZNLDgZRv~~CQ3|@9>hcFST43^bb62d_>Fy*}~yhT5{ zDmq7ODI|-P;t116v^nW?1aO=z$*4w?hy*3z5%egq5&)TOa<$IH>yyyk9vnq1Bn?xL z@(NxCX|95K_OUGMQsK~M+(3d;D3N5vR##iQ<=y!of7KG>Aoa7+tEw;gz)k1;H|IJn zRY}fsezzMjghz9-Bz8RX@nb(b;v5sP}04Y^K>qsUtjKXAD0u}S3rMO0>pnXS*tjK z`}4}Zi)SvAlgcBxQfS9RR@)zpqll}poN9qLYxHOkClY8@HIa9CM3vlN;tPCv<8=ZX zHJ|4$a)EdZ-ux|GTdpN9)VyeR={aB7)b&i(oqZLz_3B0~=qJAxcu6dcd=7x8Hqmkp zU69uTaNt+>8Qd?d^bg zZyiOo0$tU$pvq5wU;WH|yG5WLeLyI(iph~mRvjIm8&-nw?zEfn<(tQt=xPk=4TK+f z;{i$=h9zJ%K5wtHO)TdLtOd9W8%*pVgWjuFYSyAzM0U2e>-dHLy{M~itxMj9alyX} z&}Cs^RwPYrm+_0G;FlLkTD=6>6-3;B%%oC+K9<30Vqg@qL?)jo`-t(-32xf2 z6cVOV_{KEvqj){5Ihn>B8O=_lFt~2rdiJ6Ffmk2!X5Yoln*Lhchik)LfB^tIKiVxe z--qFq)gu7A!nt}z@+BD-iMr*6iJgHSx{IMEj;OGF(!>}U2$lSNH6LuAf2;G&hxwxl z5y;dSQ$aQ8c~oD729nHZvPh@N;0nlRE*6 z>AGKv3Xb~iR87ZV`)_ZJB7VMIU&Kp6e2tuf{Og7yU|2SiAJbBYIjhFIPx++p5?0WS zdw+4HPxk~5Z%!Q2S-g(cym9~GA8`DR<^{JM5s(LP{!L2hzv*v^9@@8+Ff(P!>N>$7 zEEA0qNCZuvo{>oOxX!yGQiw7WGt7=(C|z`|&Q5mOm}O5yl#cY|ckRE6i>`%Gk_ZPr`LK%;az@ zODLx^isZ8+d`&4YpWijMFvnXfMMAF-OeM7}Lz*YC?NRaW#VOXrRtrX9BdJnAWUffj znOD!5_h3yw57%gNpT@cJZg1J_{&j+V0Ax4qvl z-yK(yo=j5@sz>mfLJ(9hr(^3;#yyublsh=DQRKy<&5XfxWju>W7l~tQ9tsnY5WUHc zd+}7}P+wBd@_A1{H7&!=%d29O4>&xgY2Q9g!)(7JDN4I$r)0oruQUCi?RG57ltU;9 z5%Iz|r=CdQ=P4zQa&!n=l^uJYNxg83d)FZbMz2V0j6D+klo>6|pvUC*&$rZS)VX+s z@As!6Tx+8%?ja4c1V zSnn^??&=1vknACvdsh|t>v7`E37xbE>nW!0`{h%gvsiZ8CFvqg9X!Aq)0y-%y4-Y+ zVTSWWbYq?l@BW}=Xp<;FrS0EnJ`^napMfo2;&$!8f?*A&lBnnH{L7!NTW9C?jUwVN z`p&M0;HxqtbOQKuFb#@31jM52;-ee=QFybpZ_ouuu2p)0mXj5>j*}bQ;J?f=B<2&r zFs}{(TlYXtVV|LPBy26r>4)wc?g(#7W1>s(=kL$42)O}rIk&d%6nqDn9K@?)24!iH zVh1r`_7}?gcmYkP3N~kAsH`qOUTz+l<$S!(0Xmg~0-kV6`AR2`H2?b?}KY5$@+Pu=1>^r*)TH!W0hM#R4+ z2+-e`^2GkSEK-pB>+^q+1EUHQ&bbT*&b?7q2jba*(u>>-B$TCFHR!)1vzHO^atoq2 z{$nnA=zrcx8}}#S$jtq6{9Dl|KV&NC6N8s=JtQj{$nR$pZCWP|J!CL6X}+!n)gGuy zW=L@E9jib{Cg>tfl?7)KSyTB5q_DsAuE<0@GYC${B}33PSC7truE>n0JhGSSAtTtF z2`JSCJu6}oWYF!hk$CRA;8%9szefs#_FuwjmFtvXv3}rx9{6K;rN3I1iP3oB`enar^nAk zo|wn%!BhHzf%aSf!291*hV|hOny@8D%U|BM%-46Z!porIUxo>fj@O%%Y5!ag za6U>!onVSy($3jjIbjbPEV!)*<)V{4?Bf3qRl7Uzn3=VF37U$+B}*G{&Jt_&fE1;N zdo?s*!kDI8zQ8qo5eDjeBYFZJb%|02Dz_~xNHm5@Yww=%Z%kCR^riyG=b-xeb<1#Y zaNX`S9z!j1ma!*Ue|EoCtvM&bGQ6MYL`b^&<%$iPJqePp;*SYIrQD{|4_mU5q?rYl zu6w@MVHB6%h@k#S*Wnp-DwpD_9p_N`#l%5c7m;tv%}FB+b{UUsIMX>WiR=B!9~WD7 z?k7Q*2|!0bY0o8$ng)cf^fWAgc3m-16HZD+hZ-CJ0ZJgU8i!7?7XJA#6qCf58%@+C zL3?aNo}3%)U?F5mC+ViKrRX1PC#938Ongen)o{mO+k?G60 z=K`3uy>yCg^!KpTWnH?djn|tW>g?k=uJAY+xdgZ8S+1o8#hl;1nZ)|@3pnLLj@U_` ziv#!bx{?y_w@7ujR0oC1GwyblwNIejdaa`b5Ni4Ke&b| z;0VeUPlDN(=tIv)8-W8oGnv1N8k};HX%DSmHmZ}FUEIz~Ag`+>o}S%rq5Z54Djr=H zIsrJWzT~;oyt@4|?`O`VCvCzY+{^9W2svF!iu$AExy$^6!#+s|%ryYnp09wpkC0sO z)BWLpWok{{c}hB_l#MV!gCLGTO#B$w?LE_pj7gAxxC~!_Md8!YrPg=Li&{&|Eu{!k z$~WH2H&=UyD_33J>~GNXuUeyrCzk{s#}#h#F|6Jg5YqYbBeHyZ4Ss#bqbR80`hV~H z|5l6LMIL+p`ENPttMSWV219yvt2P;*)A74cZ&%QdO(ukPV()wog6FqRs9O}k>k#Ub zUm_^C{+&Lr=>FNwcSxg>NrGBoZ)^xS?*H>T3wHgdYj!SaI*{NO+!|0aKkD-!?$SJ7 zYaW-ZR+BVwk?YU%6!Y+p2Ek8R>p;#{1lZ0C>e6YF>TBWq7JXX;X2juG)i?9P*Sj}L@3?=B7Ucev|afcvAGVsAWQ70NKNg;@Rw0I;5 zQKA@hB`5Jt(H~#9b-zy(>1@4pv zOp04YAZtvbyHBDy7KFrs=T-2k^*{#%|KKRf)LtnHXZJIS@vJdno09-ui?gqU=jF1#YRc)yfUy!nw_o|m`6lFjx4h-+ zojf0Y>sMO3Zzkg!KusBs8o=|{GJS9abua2VV`yIA_3{(F%3*dS3c^AO1tSP{YwCIL zGf+V0zGb#+Om_Q8?j@hZPJ5U^$hl8VC?Jl^p$_K+*$HJU#^dAP1PjZ8C3{ zZ;+NFlL~GKD;!eAe{IW7y3lj4MR%An#5o!8JpR97fea<(tX#;qBA97}B9oz%2 z?okIXk}BsUf;DgnZPDdc!{tZsU5(wYG%w^FKZ0nMl)~J+>N)sa*AdzP5|>r-HrCSN zO3q*`8igs$r$K1eK`N!nsaU#fW;ugrZ4cIwiioaJ_@1}hZLO7aB6I)CD9f8OWUaGy zQDkPjR(tHAcuK5*)A+@q%8@4Ua%48x2nw7)ARKzL94^!y?PpbYnA9gNj|;l zCkW(3=Ak{&HLC`i;X>e2r;JK?sSYU9ma#{ z9$DM7HIp(tpy47qk4zjlu(KbsbgH{lqOUt0c0u_9{Ge$%c)=_Rz(}3>?AjcJu`09J z2+nwvuJ_ID<59>CYMJHr4=rYhTm(ipUL-$=;LH9amR1z{QyUpivO(oUHCmStvXMeq3TU73uAu(ecOlEF);>KWm26KcO_yT z9cUw_R42wrfx=lEwLP&Peh!3d-7|OUgT0hdC67&Pj(r{)fr(a{oYuaai*e`##63q_ zWrmkG(DoE=2^5$;1neclmD?$sq^B^o`CwubMB$s*)|wCi#v`xNE^9;{aMPWHK-H(* zpLRMT9fX9Au5gk8rVv>OJ6M8f;)K+B^I75D)d{FGiLyENPmlfcA6|zjSl^@Zqk!s^ z03l}#Tm}a<33*Ub^dPC4OQ9ZBzVZM;9)mkiNjRTRsA6Ruh;V_KhdLOwr7|;?0~{Ma z_ZAq!hzI@)k-fJsLc;>e*d(6wO+{!;Nybl0@(Uo4029UsPBi&>8jRF_gsixNq(CJ@ zWE46?bos8nuSY5s(mi(*zy(Yj#m~aE(I67cOxE>;LY2MEf@z1XpUAa8Ml<1{vbKxZZ6{j!4%#4RL&CVp5I4i2)7+)lxq20_WF53r1J1tu zs0TzmAkFb_6WK5dtT;&a_~NdNOaQ{7K-+16cTU=Rp`5>BwG1JK1=ZP!sXv~ff1+K+ z3A%GYRfKqCh~SPVixSQd1WKmr_?$^xmsuO?S8N(I82^~q$oE`^!JPP*hdP-&ehhyx zv#$${6$T{`X(kBZiXYMo+EZd(^CWrtRFhqdjI345f%-2LM!+}LRMT7=dE50b4d5FaRRQSkmQY* zX|=iq)hy|570KN`d+{=T!K?8xV@NE+Qzi-Q67q`(UnH9ZQA1)1Y_z!~t0Cm$F+{B;uf|>M{2|u5wb}lFj-Nq~PnF%x$+wlAB|>)dbW83H1Hgn& ztTwxL?j}%5VLj94VJ9GXH&rrIdHg?uXaXc#88;T*T+K`10{cs5vzpkMz3H=kbe6WB zW3;fzaY(c%I5u9XM)lG#=V{#kulNdFQ~cHdq3 zH(N0-8T|O*cmeMKcEAoJjS+XY+XYFKSz!~be!WEG7+jdCbr*tw>@o24*F1ED_nmd` zRgZ6;5lt=y3mr=AbgDj7Dt#kK*fgTy7OZ3aPf2FV-Nt^m-@p5n>raUjWl7Bxj~~Z8 zSPrsr66|jkJu7+MovD+lMU_QIe0lUkAk)h;vulHLNlfI`PbEqsbwGn2rf*6aULsTE zGeR5m^az51*!Xu9uE=tD))OFz<&)B6q{S2 z5BLINy$k-`2yhl8Ns-)qlk^nLvVcM`{ZwK=2Il}%qhp`yXA09>^Q;H?hZo(~TT2li zxIXezKFGkYU#|SFX_1O~sCSkqV2Gj=2!3i#_?WvxL2Mq&KNJc#x)R7x%viS``^GGJ zQVj&eSzR_wn%1Bx274L{Hx|R_$idevu2Cj_{Ml;PJ^tZViFm93GvtQdj4-6O_U9wS zu0{7br=SQ}>QJpw#Gsa)Nv*(4H~*LT%kO{0zN7Y`szSf>6)fq<50m>$*vN>OTVJw> zzd?0C&++dXmLI3qzkWHKq~G;jO zL>MQ^Hsz~*g%{@?_Ak~JXS2+qlGE(l1Ts$H=MwX8N;0gj*jPAs7xLa|l%B?rmC6D+ zV3g1RH4^)O5<&p70(px{2-W^yr3kHU?H!dB&UvK;d9hRiet?Pp97+6NLMT5+U0X20 zP68pr`o9xfRznH91VQZ_ip+UOZWiZTuiFtR(3Zc+)M9`#)9 zcquy0S?4N@aL!~34XtZ0*$^%yh*a{NFaK7dXH0&f3`9mJMv$? zZ`)n!Ci*^Qy{&JfDg5(A#`5yw9Bte%&gkf&p7&C8{q3W z+XWqnW!(smapygEo;`fHvR0^Qw`nZYG*BF^@U#4t<7|~( z1#19Id>I#O?dvAU<~mr;$_O{Cu@h3))s=s&k&%_fbK1I{EjSb9;?BRLONkP#$}Gd2J7Sq zhZM7(-;?pN`)POcP7m&{I&5ncI@}D2g%@Z$pPQ;Qm&N~*Vv-mGVUpP-YMb;0#lCX3 zczNDQeOtw}6S?L|Gqqij%w7J`wf62(!?gCzmc5T{O~qheoplD^$2W%s)SY6~5{P~! z_o1pH)J_HH9u4=z`yC&#_|fa_)0~eNvSj!5lJ1!;J_6k?u2h|JHy7mE?@!;A=8}D(RL^3^*g@` zzl-_h@WT1w;6Sir`G4Kc&t9-ato%L`w|VuhnEZ1yC4n&tE?OF`G%Nh#g4D)_>w~DJ zni0m|6r256wF`i~HkXsPyK|0jlh@-5YxXH&y_8fR*UFtysg~O1H>0b5+U9#tPj`OX zel<3(sjWNx%)ju(O6%K`v>f?2igXR{CDEaB{uzyexuPB6R&hQ=$s5nI$b-xIuS7bR zUpFlOGs&rHFkW;z^!54vTgY5x;{NeY!ArW|B>)!WF|<=YAy0qPsB?Z$WajqaJ2#Of z32~k`wx<9U%MlsW*^DQEpLRl9l)lR-JaDSJT0Kcb$6E&;VCk=bs>6?$w7_nVyLt=5a$jJXq}Upd<1ke;Mlp*{ziVc15;F_VF6uk)dhE2ftTm37tRQQ@YEJ}#kQ-C9wA1gd0%_&8 z&nz?VFg$a#Mz?1g>02*7*_BV4?BexPzAEv_>_U!JDV-PkGDkxzZ$^{QGG3&1-&sa9mq*(@nd1pykJd5PN{b%l0Pd9$cHgp1XV6Et|_SYa7EU8bXgzHnD08v{pra z*%O7CWEofQG>GT<`AxK16;$W2PK1$ky%q=Z8v0v?r&9%FIjnx-P?g%^`;Q5{X7z*Y zsrLzf)G=&UMoVeCS}hcMwn}LCe<{U0E8CroFYf!R=`EdK`mSkz(^&h#A9F^BkJ|sc=!mw>o9rlxSLnGL<;BN;6=iLc9*8G{T9_xll zxY%g5X5s3Xj7}HvorR%?U(#(>H=V!iOpY(lw8d+fyn7OM1mVXxCn{^c`{!=wGSK}c zmOc=F;6K#QcG?xjr@I07s7Mep+Kp{AxJLh3E!BH7#7662i+OAY^p&l5!{qh#S8w#D z2D>piy^m+ufN;`A=}~UR`Iy1x8u#qV%29r#jMHWzwpIPkYpaZ0m(g{((FNF-;wtUe znagG_oCY1GX{Nh#t|E|&QS{8s2ScBucseD);X*u+atQP#*P3FU#7C*H({f!=QIQzu>6JD^+b{skwIVkbRZA%-XS1 zY<9pt+HVyUGb87d+ie!A z`KZ-V+aR0Uvt14zGLe`-@r<^$I}YnGz4>PcD(gk}ykG8Nexd2jq6VZjXPQAT;U9l? z6n?S%rpdY}y;j>|t8m`Glj&H%>rDb5r{IBPVF(3b{`rBu8QM|B@ zuCTbY2l(O6JsGRer&Sr zEri6!_%9#Zb0f!!&;LCWv;O<3>OdD5*IDe}IzI6G)?sW5T5!m&JBYrt6X@U$MO&)L zj$er1=DI5-s&OrQNKZRk>-@CRo?*Mc>Cflr)5oHyB%et+zBY!9KV7e89Id?*#m`g@ z_JqPt9>+~MeZTN8|J4MJ=jN^d*fjNT;}PgGr+*hh3~dQ-?F?v!Un%Ew; zq%lbu_TjjLsHDzSfLA?^e=W)MCm?bHyy)d@6iY^N(}@lzliiYI29m{SVy}`}Ff=JW zTgj@{DT?TrtK<~r7$!~ol&++dUA9zFbc)Vi$}T=t(}<0DhCj0D`nC!O7?2h5=uC?r*lWZb)PM> zv4u2MHidK}g$(P3Os9oNo+4I_B6f!&&e$UEsv_QzBL4Lv!P6q@#8yP3nA%1w5nGI| zDwZB8mR&EFKP|@alqhMGs5q3U#g?d7m1vHXXs?&(oR$o8|KBu|3jhzm2b%otiPO|i$d4ff2#kVkdA+#Z>H!>L7rN6APs=Mq7`)| zpMM9rqg%#AB}}F;UJJ#_!mn!_`dZB8m6E{NEY=p2ivM!e2Evuwu2q@)fXgOExt(7<)#d7axAh^;^WNZHlV_c_wG!X;7&m^o;h03h*Xj!A zk|2_dyz%OjR5o@_h?Vb|vO002mov?M)@XHeeoQfR+f!ymp<*D3Ueq-{8JZ>CV_b8B z97!s9lpg;1Ri3?Kz+92QPVYF6f^{vYmWQ&x@;!1}fY2R5-4mkwEYU}1veu!v_OVE?vIt`iY@cxhCN87u4m98f@16hU8ON5ZOd8El}c1IkpF?>T3U z>lNQFU9MWI4v=KqPwa9OhU5=f$+|=D~oqtOkVPJ*T^a}6|EfR4lJ_t zrX+-@ecHPn8;S+FGv$)ryUr=j_}uOAh5F`dg32@4G8WZPu)x97y^b!E_Lq5@`MCFv z=6(zNQlb|fJn9*1Xz^)q&DBrDX}uAde5MdgXXWj;pR!ubW_YCYeeTpjByG4dY=*P27#u5AmtDGPs0)U z%D`K3xq-`4>qpAlu5)H=4<7y%=%JLp%k9`Y6(71mwqkuN)6TEvt9IKjWSpw| z7QdYn{rt+F7Z&UMk4=Z5e|OG#f__aK5-GI)wvcJQl6j3jk>N?*6kNS1$G1y`AB#Vy z$|WOiyYd1%{MV;jQmIQusTgbCC$9nHrw+eeh z&43-n6hcU5&)ou8)RV!(1c-`YsJjn+rk_3(M5mGtc8f1H4#6W>ehAaE;wAxC6hNB` zf~k}0gyudLGIaHxUtx>b-c;dfHEqDc*$N4a?o`m^M;!vnjfM76lJBGySN{gMkQ{5}2z7B;*y}FUTHSnKndV|8g&6DDo>;nc`ZpE9(%6X%Yfqq&u}E z_3%AZNos@r8jUX3ljWomM4VAGawkVx+;rOkIcF)t1DqO5@=CKL904cT=W*}G z?*G-a>)?L-)VDU|c8lhhN6{;XzV(aOAL>QlOZoZCesGcaC9$lQ z%$kXX#@G1@sh=(7+Nv}p0FXI@SGw}GwD^w8juSncGi7?bYeY1&oQc6u!Bi4L3 zeQ%WYYQ7!^*u-ssV4vIg#3JqR+H6sIVY4FYdJN8AJ{8WQXuozJCjOM|=NzCmJ$vej z8)T>A`~SQHnAOL4$aqilV;Tpf?tNj7ZW;mj!$Dh%q00&PIO$^qU(m{U%zi=xb#?GP zuV_{V9DsgZ4gD4T4asz4S=6eX!tKqS%>A257$iJadzkMeV$dt>^u>eQq$Qt5pSmgWHRi=e4JW@V) z%`U}nvKHLgn|&QR!k-|>qn?9wNSVI^LP4B~0L>1g%lSnQmtDsUaq+um4qo{Q2OMZE z!%MY++7PS0`RgdSCD7p{)I9nJQdJYW4S{ zLM{?ZK8oO#_@j=FTVYdJzx7>{+RbQi^xx?(Oez&0NJ4FGx#|+*d$z&|3;^D}Z|?ji zN2N+}?(dW9D5x(psch4(6&X*2jUwc&s5&^=r$qMm#~yXauZkGl#l|>}?$PH4;LC+j z24bQHr!{N^pZ_aN0hQ?f8?1-|Awm-GP1_3F_%%c;AFjr-tn$)|#RvCk8x7&K-Gax& z<%+EmKA1$2n2Pm~so^+gPzQwY0cq$hqP_eJ^Ew|?pB z%giQ~Y=|hZK`I-Soc&=3NRSDITuF)~Kmh|G!vnX5(g3d57t3+i(Q*G{s-VDE&^n)r z5w0q?Zh71a3}q3Gu})Lr3p>#Qv)v-7-pZQt7Ni8+L`MbhLdGgg-3&89hKaLjnfnGne1$$qlOU1<*)(D&m`j)o!jtNPuK;_PQZ2+2eu8P_;z43fmrZh;y{-M=m$W z3WR|e2O=BVieboH(UcVXhwA6aLQwXr7i|C3=e&k%Mkgz(qrmOUxpHff6s|mAHLc7m zPpB-41qFHStIx1?vEGP^1&F^+3pEsHyZavMj0Mr?rwUP^Z4L1e5il0A|G{kJ!>H_E zd;TYF9{p_vWvk|NhXsaB$~i0%l*V}XDP5ZO_z#>#QnB$sajtO+L>mKtm5n z=~*CUI8A9jZbGs+fEu4eqzA^pZ9cBEQ7@Bft}^-lJ#tw!kYQn zz{>V=uUKCyvC?B*J#YeM#ipB{s!AMj3VsA7kOLmJn95;q+}wp)r%GMB<_}W?D;lRV zi{2Dhba;ve0(c;*!!?V)ZY*e21^CrYrR5poAj4IQ|jEV1#Y zKDjqDa~3O@#7P&{f{3*(5P%AqNQKxU2+$AgIF4c4i)wuA(yF#2_EfV4Jd)$5l+`ik zw3`NXvjaJ81c$1%S@ZfhfAr5-EYbMT98*OwqCix!W(Dmo+Qd2u3?zB4CBMU5M>^DO zNHKEM{@`U2?X+3W5-?esL^XcYkZoXcF66MOceI8ySYwmj8EOkM!~nJad9a@u9ljts z!>0?>}X{qd4o%eA3><4QRv_+KB>G7dtT>NU($;w=G{64Hh%=Iyx?Z6?qo34thm9x9d@hB{Gg6 zWgMvAzj?&5Q~R`ujt`>H5u=C%v4+4vB*WPacWo-?gMz+V?_&K3>`Sp{YB1l3i04$P z89OfJGo)rh>TLbnu2py1X?6-%cj}QFn*DmS)u`DYD*+iL!3t_&zw0NuR`J_Lgz5N$ z!#kf?v_x^7&Yrp8sjQXJrqJWor0Px@QeaL8F|)dpjxVary7uhE1Uc+$M*-oj2SgzN zRrJX4uMPF@D@sfKLID7!TYE90j%->D%9icY39mV;rs@G0r26 zAtm>hk13xc^x;-ewiG8c9{lS?=x#Ikdcc@9?|B=O^P|UArdHA*e|l?tbuE{+L1M(f z%{BZ}E$1;bz=@d}d2iK(U^4g2s56Wfx9sSux5yM{<0Rp~%$gJp5l^!K&D=+xe1ohZ z4;_C$I?OSC`{xo8H`F~3NE2qCR6ELI05;@<@kl+yJ|ho)I5Zl}D&_x9AGCI+#(ri- zN9leXTV?Fj{EH{>`tNQU@|e5*J@8CVzZhh>d@}j_Y}DgmMZo!NIHzni(=<>PiTAz( za?D-eEq*!MEL?cgraPV%BozYv`|9rWtN9ZLa~IRVUmAg3)R^xem8vLZ7PucBG1m`5|&hD`R_d{LquX7rMKI zwfgDraFXiMKloCsJ*6qnf_VauoEHoUiHbLY1d797XT91#BL}}CuRaFD1nghs=Doa9 zg9;0M7Sej>ee6eDSu==zov6&!PyAH!gW7{ihk-v(8_$IY)vcG$t2M9^O(A%Qs7)8c z3@YSF@GmK6u^dMeGWgRpRDuH9czsJR+3a~p>#f75=$hg{+lbgt_xh+I6h*_MRB${B zl2F(Pq}_LDu|edX9vQIV-$H3gS0Z zVqDh=E{S(wF!u^IDQpTJ{T=C2Q7eIiRK<-uJw-VkHYqTsU=5yrQe59>PiMoWW53w& zAJ5&G&Z>Rd7cQrOcF?U;E^2BTiKjNs896Yn^&=(HF$6H0)Y~s7s!l`*uLhs|XXzF+ z=Qu~r`IT)9! zbD@dXGHp{XYgkuynTxfrDd})J5rYrXs~81W?K2z{@ZjYuN}O-$qfM5CNL#L_2*S9x z(bs5av8>ie$B^$R5h6?#2|E9KLxB|Mm{E%e$#F0rld1#DCIZ%6s~#7f!(^wt6F<20 ztsmyiBj10pSl~?<)pb^px@V(XR{=)gA$lPm&L;uJ`;fT(g@2I6r|OXg6lbxJ8%QQ= z7vl7+BgfR?+W}!3O%>i-fU>ewYggh02aourYfv}zP>Lquf)z1LA*V4_koR$VV4xl~#1YL7_wWHKNLU3&e0@N^b#O}&5I zKPxsyjSh*?BOMJAj_wpB#Sscpj&2z#%?PD&l$0O{BB`Sh5NQ!mN28)5`W3Nw_IsY| zdj5i)>s)8&KKJ|nykD;-&!6jKR@#9+bcU!`F@`IGyYA_cISIKdTc5Wd6B_pZ!T*!w zOa=hKr#y8nS1RA0d#v$T4x8$cb@0qDS_iv%+ID3^Px`^KPv_@PY(L!JRz<|4_VtxM zcacDQvtf7-M0Qi%7zCt_0_ad57geBW>>Pd)c-{N#jewLjBGrsYXGlEWc?0g$u~8s? zf#)5y6B;&T5Ek%5RiTDzGflz1`<&QtrAn8K#1M#(y(eu6lvDqqhN;*$H2GC43xJi- zFAl}e4afn|wT?w|hRB#@ViE^?Vd>)M;7Br^AdXH1O?%)WS~e1ED~SmsOJf^8J)BLTdRDDO5iUiOEU2TNsH4=lGT#YsPX-S40Vh%>-n~$BRwUH zPFY#G%9`yOGoiZrV;i1eGZZly(O>V{gAsn`&?pl8&rQrWgv3giSt`x-!+Zc28?d=Z}WM zFh6%az;EzohjK9gFnz@`9gD7VzH8yV*7vF=RXstVGcbFNk^xDCS_f0{Sm#G6LYxVK6-~ZTh$W( zx62l2K9g#}a|-O#WH)_zH(l|M{^WMcay@_vSRR*q@=ez>zDR}PCIv*-aCL1&lKFT% zK6F2~`6IQBk{EN+eD&qi__wSa9L49q)Fry*=5L2QD%tT#<%T?vFrc|Kh>P-z!W0T4 zWKxXX60$Lxh0;2;*JadHNGGD;=|l*OjM`leO*56DD3kjG0)e7|ufVHQ;6#;whGYdQD%CL0@eCYVKF;(Y^2o zJt8<+<&L|HR$wG`(dy#Z+#)L%KNJLKCQ)&=DuSL{8B#xi27iy{>$L8lMxza=uVr6@@#7lBTtet7gE zBg|`P_TezND?)pKI>HmN6o=4D{R_J}khxpkyZ0^p^J!e!#L3&3B(cs}X)ZX!0|0U? zmI6iIwtT}V{dicSoM*r7N1EQurOS-YWK^W>LIKqvG(s~=jbL@9e#74W3PS~2@uj-f zrufaopS7yJUFve$SiC-$7V1*1ewy&5-m57c_jL49ain3;P+F;sOfNK+2z8o%y1=UA zK`f7W^4MefizJw2Vhu$l>hyd>h58Y{k|K2wCBD&8eN&f4t8;Y8XN?%y3miX!(jc&a zJaga8`7P;iDVCh0RCou#wsIe>R{zP9p@;$!l<4O+AqFbo$RBRi6oO9cINjKZNM9Ss zCTCkzG-<$C&CN}+Il#mp|YkB zXX|RwMS#c~jbY~g?Tuo_cxW)SuP_9Yl0vnS+zQlpe1XDUa)(A%hFM-!1Ztva(Y44c zq3jUpGzq+b#qBP03E319CF8Fx@sZxT)i?)kb=8~u%y<&a=#AD=*HPf-AZ_UpZosX6 z8O3l=%XyTXE+7xQt~XKynSa`t$S->*wDsm97ngew7GyEWO)yf6l+^cr!HCOd2&Be= zzRGmudE?R$P(mScJ9Sk*NH$dTAplqVZa7_NLcQ|Dqv;Rkz*0C6H-R+mwRGcLnSGT; zam~>Ff2~={;s*bz25SW;!Qdi|iNa%C!WBPjBs0s!89K3SERz&4d!w%LZ~R=cBGgCk z@tgB+zT0MgYEGcva4_fRU>8)_e2^G7)T*;qC}uVZmr!}nYDY?ZQ@34EjuOovXe`Ra z*d+rzi5G&KIrN|r4RS3XLhbTXtNXxr)uYcWT@$vZo!QWL*?aVua>+^Zhfr?g_Im5q z=3I`Fua5uqlYG;A9qwVj#aW6T+#H?2T7I5nk~}ss;sGaQMICULJ%-6keFQF(f&Kzjfq^0lBTGg{*9$V3 zaWV)c(>@Y!*WBMuxo_p({^pT9C#=@cpnJ4>YM;NZVp!m_5F(rtZjoxl_vginBK^9% z4#&-IJo+f%@E4GsDNdd~c~-9u^#ug=fvgGBxpzM(-)d^lDXJ5hq7?6+T%Kv^XJ`o@ zfVQE>@u}yF@cxpvt=@#EqrkNk`7clMR0NLc0{;f_Me}s z-bY*yQA+>l?T<->Ci~HTgpO1C_M!$r(zOZ-u@{ps2=|}*92=>UC`=U<+8km-;LyI~ z3LbR&{$DGyK(tYM3b>tNC6;0G{-aWJ+GmzrJ--iVtV;Cy_~MQv=O;!Z&1416&I z${*+p}mMK@c{ggApVql&)1a{tN! zNpF2jQ?6u=kK^pSw!m`Qd(UFGur01)-T~fpTd@riYs&U!G`2e=G=oQJhm3Unf}jt< zVnIRS7a&Qiujxs8i_h>dV;dY`M+E_AZpHA7VCZEZ*NEEd60T_5W4mVEc?LMFr{9x^L29qYYl$DfA$=mg}1B=EJbyXhVnU51Zm`!$>=~BccI*ChT z+#1iXA(&14p9h;!J%~LW=lIDyKNQ5viQ;re=7H>&M;09ZUXp2BW=jcU-@YALCk&!V z8MtZYj^OT?3=-&&3i(b9X#$!5hB!Xq^u~FG2#RV<&N2PZJ4u1Zk?mw2u_h~p88}8w zrp7U>5DS0E&BCRtQ1NAo;AkrFa)R}pEjN}bBN%1ENfzev(OmS-*9JL=g)zMuB8#Sd8kkUgkD|KL2l&Kd1_Q;dVFhk&>QxP10 z=ZTX)&8qCZSw#JY?jcxG)P?ETfXO3V_jM2})mq~S%7@Kze-GYnXR?iC9QC=IWn5r# znYWHon}3JPy_MDXHWJUoL3l>|f`^7F%B8}@n$H@M!^pMhb$d3Bo*EO7JdW&dyN zN%}Wpa_Q0hY^7z@fFK3Jdz7S1qv^jdbw7oYd69-R?F}V;Aoym6paFJlmc&iS!e>Hzc;)iYja+7;~Sivx>O~Zsa4wum2DijDJ(E;48o2p z)NC?fCF?ulDuuS?k+yoOXcHd=`D|yY_R9ga8g~mJ0FuIxbV@d>=klqKgnI(+(e(mm zVjch(4&bkLNFF>7;QB6NnO@U3U-czSh>3KTD}$77@@{Z0#<_A|4vpq_p!*60CsBV1m1DTux7#L zE}LqGT4BLUZs{sKve8Ca)FzPS1mrNn?eFMs83PPxut~C(f4yWxuP5+ORO;a*G$s<3 zDs8Mq16<6(i1TO3{Rs{up{S z5vxD4aH_9idlYsn+F+>zJ;U2ba;bLzAooBliw^~+X@zJ-?6$}>`hFu-*K!CRtjoqL zkL}>_2Ur0DpSjhY?GC4PMz!R&Z71XgDtOW+wZ8BC)={%!jN>5@s>jFjUA$G65NTssVHwchiwk((&>fCimTcViNX zBg8u#cRBJs2Cbgi_3ZTIt(%%nnkJKLs+_uuvxsHGWfJQ(v{Rk;CCw#SkZVv?qG?i5 zjVDS`0`7T58cn2JdlI$Yj|MdV8ulA&0<2VXeKh=6Qjg=W&L>-X;z~6mA0-=4W$Q0# z6~%(BY&gSQ72VpKD}AM9e>W$qxxlNn`=!Y~C44?GG%3SED9u2+9e(jAC!=)Mpm|pJ z9d>qy?8hwvlo$YQ17$528u&eAfCVYj7@y(KhRdHl%~#y%(;BeN2w}Zv8WT|3*emlp z1IeGBs$csV+jo(pno~tW;F{|oNhWaFCSXzcqJ_T}0O39wqDhJRu@c??6<%-}?jk|` zxWqho&v<_bKNDgE>tJb(v#K2bktp^@so|#2WfC2=tX`aBzG2q=#-sb53`y64kLi-h zt0g`qiiMVf!m)~_$3&mlusNDC=Kg;C!4X)G0M#MLQy(YiX0nJ;VWkb{MJC2NdAbC) zYN=)u;Q=+0og-D4RER}cqG66~2IbydZ=A4Xe?F-C9C=As_WPvD+q<}NZ)2Vjz=QyM zo5?{t>Ja=h#7BatcVJZzrh<24Sz=f!0r6kQAUUc!JMj3bDO6X}k+3w?maR5XtUEoX z3ov@X?=U(z<;wS+-;)?T7~Oj_b1>GtZ*LU(P?7pj=~4@5pd0 znI;ZQN9clJc<`zWi$CP*aFV89Ctpo4wtv{Oe+RUToac;vL2NQ0*+>3Ulk!RPI}HZs zcCh@=1)CCGMrzVJonA=HJ%=#lAI>abJSR*dO&7PKd}7^?E-f+>%uXv7*QhW<8|a^E z@m4gBALVj!&w^j2i1T+{g;4M%;Z(C5s7VS;<%*E;!o2NbLAlQvD-Mh8SInjt z*yz>YpmcV6MZ;>C=G~(~zen^9#DTks!#DzKJsYo!B`;0{Uca^M&U5uAI|zLQ-CqwC zBvx=VuC@Ht-8YbI*XIAOwa#ZAU$!b`8T!hB?XE}DvKS5=_h}uH?Am3=WrC$kROdms zD^Uwzi!&Q^RLHqKq>D%p*F2ZQ(fK;Y*^+p0paN9H5h}9|#y^pP6yYZ7DtF^yf_4uD z`rpPI5@*OzIOd)C8dJIFVpY=lJ~`x#I3eDSSL;4>d%_pK=%PMV3!;`99{z?}yxp;C z1K9x(EP*vJ`21;-kY!SkV`X?fBa*F1oE(2st3w{c?8rqqgT!w11Ps3YofUVU>D^;3 zf8#=)-LJu~2Dkm<-jPLAtQN$qj`kDUpgA4GQEltKG>{_zfsH`<1h}sR0(2ujX3#tx zn>{#TML{zP|6%J{{>Z{nzVeU{+IC%Y*(g(V`Agy+oF{zs0 zYz<8o=hJ|eGr^Wu#cK6F?o|o>0Et%-#GMMn+mZm6B)`Vtnk(ASfx-*-a=b>5$92(< zeVz_Y3%0%Z$5>^>lmuIsS1MT2v62+dx4Q!w{Cx%~+3<cj(u zRHzSx9BahSlWp{hzWg*&IP!J9{Hs#}clKC}eL(Y>FXjV2q1{S9;pe*;HuVvB);(Cm z)l;5(`Fy1iZWNTJfNJ%i=TP|Dck|i5GV0^*#)sy=+#_tmz|TFmkAW0)M*7vjG&^IGp%yT zR$Wu0Q(tWihf7Gn+37Tdt@%3nBoujzNqzm9C`|K3`r#3JYioP?AbFt~CZ?IWx!E~M zIek-8#M=7$|7<1@Fef7;Cm4+2{HVlcOgG9cA*ep^Bcl+7O8bB25+uK`@4I{EU;)xk zB`{c6|3t)WN8|<@bG+MGRQjB^hhBpnt4(PMP*ay!h|#sc@7`F-FK#w@s;H1wql4g- z{M?L@O3oJ5Q058MEn3T9pDz&9M#7L8{;zvX?_3bQ0uzQTrT)Hem6`|9&G?J0CRbUR z^aioHO?S%;#UtPaliTg@UiT+Q*$tPnrlxZ!cDp?fq3-4*ge{3t;lc)37m|-QJ)6kw z!~$8e49HZE#e%wYts7>WTD- zx8hA=7wJm(Spa7HO^SX5@9XrKJ6-S+STg4x#Pf4@mlHELv|5+B)s1{LA)s4IfGFE+ zPsPBKqA5x7heH#-4|?x=1Td>ZYHp|8!shUZDe5m}V7gDem|?2wL*~+mBXG_-f>l2R z%!s9gywHvu%EP%6QWy@Z{EyI7kJRu+>WyxUtxrH zNWpi_@0xuyWpbpD#-vkuBc=wQ2an(!CZGG(HcFgu?~s^zD`W~7ivL=VfOK&~ZXTE7 zD#z51D7V3m99%=if(+;MP`|=o?3GHSP}QbVloqF%5eAj?1;7PJNx|xA2yTVX_BBzbMTA82d>}B#Pgs!UlM1N zv%iPn$RDG>B=O9kD{ZQgW7$m>kH|1q3`R(Za&YP3TMDSCUY@Ck0rp*q2YS8uV&|rO zq(u!yn9wuw-ANCMEGd$*_aHL-!9}B%te+Q5j?$JtMY}|CD>JP|gh z)(%Dsq2GHOIYQg-=azNV>K^MlGxk}gP90zN7ly*44iH%xv<>kP3xj3MeTe!|-H2~K z)GfcugJi0*&6rFL8Z(-urs1T2PuS$ z!jv0fMN^j_y5nKal>0I)bkj|bt_iV-r;7w-umBihjwaJy-mUiMs6!%8=6gSpWHAtm zpVj0Bqra% zWhcTDbH6ei9FP5j0sp5k&nM@+BWp2nvAW9i-HhcerdUsC7_X?J)`@+m2mjpnI% z&ADK0Db2FT1|dKs9wsfPF3Nc?nw*+oVtMJTPL5T2fuAtMztfaIXrd3+$B*=J@)7kYY5c%$Z^(6jk_ZXLy2^V# zYBu!ZAxegMr$k8W>2ScCURt=)+a&T9NB^DvhB5L}L4Yr7r0A!uqNKpK(v>jb3;q7D zc#1WnH;16tKRG~BMrVxCBMEA_wDIn~{H&*S{YwTP)s=n#aR^sJXzRyyfgRM7L5#nU-C_8=I0;GjR*?DMB!uhRw`&eYmT0 z(z(nD%qX$BJ74KB9IL{}=T#3ySBIAOqB|opNH( zU=3N<{%~nx`iAuIiSs<}b(ytJBD5b{X2189hfUWI29s= zg9EJmNWc6K(i`3iv^ai%inW8kSB-smH1X?+Fcr!cM})x7?uo@|{kg`A`}AxgPH4mZ zpO|zRVqD1Y*gAkH+jZsv@%pLvVdzBJPjU^q#2uBy9s9aLb2}J({z(*M$j22I`7aEF zrN+KLxk@0whSl6l!{WZ(wmT*yq+R#>y-)8qN5mO94=&$qd%_-OPmJ7Uu_ACV+X!Z$ zQE?Iwon32PMY@!`w`fj~Y9M;2KC$pW2s@eX%mEB<2MZr)2%_LuU)^HiaJ{y7lU+Az zb0Vn^!s_ybgBcLy8ut+-KyPtd(2*i^e1b#Cbk-0ePTgG(bHjEgG}s1${uyW34Pxp^ z#O(SCih|cJr@l^1m5Y+0LdC^^*91PI(fJ$bdg7C$6?mPJ;)M7=C#x?Q^V_1-2o;Canx;v6GvYaO0<^YWi}EF8^+QL z00^b5zzzZXq$uHIVW#TzT`_vcBOl3?jF~Vv0FE)1w7!VW-r80W6BqD?g|wzi7ZNhu9AN?|lV&3GaDHYdz1xX*xJW z8Kgpjd9}lROcL{q88hz!{A$Vur&^EyqmMtjy$XtToGem+-QjzlYt4Cee<@v`Co-26 zES?XEmoi%@GP>t=8^R@aKL4)yvdCh|Edm)5PD#GKa{c>W^pRvt&ge}xH1WM{N!lr` zLJHy_W_{#I?oMHO+UQzZR2GTT9sS9ZtLS7SW+3Z)_Y`9xy^}5(Dj|bUVOOs_N1!{3 zfE(%GeBE0X?Q9_!;e5-0*x5^btpGMdiwJGmB;61QPrj-3pJ--xaSX3yq4Sx9z7%62 zt6aze+h!>3hCu{SWbhg&?4Up!b~Es?ZL>+`GdSD};0U0Y3b&Uvomy;iBE!cSI5et| z`Usll0-0EqK!u9h+{r+@uu)5sQjH9kt_R&085Cyo6p^$jEV&m@+tAIv#Q3OemT0bUPU#$j0sX>7n@K`J;y`#-o$teBI&e@zQ(_60L>L$|I0#etO*(;ec493k^3wOKG)7H19C)lFth`g2~IP-AaeT02Cg8V#$D)4J5MD%J3DBY^>=TeJAUZ$ZcKh ze}0{6{WkyFSvcA|#U3>pqG5MT)%lJfr(IndNJkOu;{}?8s-X#(>VizwenURCmFXRA zw=Lp&?8E>W;pM&P*_Xv&2xDV&oa?a7YJJY_dSkSZOi{0MFt|vplUaWxzG@;F1;wb9 zd{}NtXt@Rm_oTF(6QY9O4;yscu`Vv}WhJz7;2!JVsn}#6ELjI3ngFe%K3mtpg|ASI zrkES*@&DWx?QBA$kGz%?%|g|Tv1g!oG?@CkuWDUrD2lgCNg__aKyKPJ>SOV7X3?hU zz}RmVvs>%x8`@^;r(=J#D zi>JUl;-1mGBWrvh?A(hTx7mmNLzW!(9)GYhIAC6h5oX(bLSaPl5(!SQ>y7}}kP4p2 zo*^;9w)Nz>0LUeqIp;X2Yy0>)#@VbL$Q?QZyYKWeNB21X-m|SmI+6iY&BR{zEPVX- z>iE>2)`IOv+JJlyYNw1HmFpn+^4msu9&nut%k~-!L#)1>`Yk6!qysF^Y2fLYaUebI zB@7YFfjYZH({8)JV6=li@IBCw6KxpoCzz~3?iC`ux&aH0=&y%5MWQ+q=UV{vMWV>obhNV}o zTA|NH&#k8ZUCsLhEnt#2!@bT*61hrS@EBJvf13A{!+yp-Jc^5tmM!-aKyj|D99FZ& zqmT*;ufhXgtrxt?x4@7BFn?VzMjq?ty5OgO*LyY@vjmnnsINzG*KMR1Dg>tIWLE@# z%qeDTDUNSU71u}rX!v>#+y2^xJ|q@cB7K4ueR{Qi{HmLERhvmZ zN#u2&_LAO}r6cVHC+(H0Ir|@$3yu8OUi_LhmC8M(zIzkA)jJI1!cnP(V+tEcB>vg% zgH3h!rOSX+erT(()k3@lqbhJb`_CkR~XOr(WR2pSDaMD-z>ODZBCK;{52vKn# zH~I`f#F0pw9iv;bz8kHRpSsQo?)k{RJH5X{#k>J_b{Z^&HLIhYQ9LriW|4}Zs;_8P zhCRF-7_!WEHFxig1!%TWU6Hzf@pFe9muub)WC(wE;kn;9Lqikw59;{mR;lzI-N4`@qd30@Op-8aj7h!8qo$jhI&DHl& zbP%?*Pw#~W*95)8%#FY$9y%Tk4$JTP={QdmG&SN^LW@><|8enDGk}8<5%GKTPbb(p z*PKzn_UyzT1+LGB+wW%&`e5q!RR`_Nyg*Mr`FjXQv)XErBX_1=ynp+`jRY=TGym`0 z(Tg{&z9C3T?$KhKz24Srv&{|JTU;l(Uv4I1B|oFsQ@dS>htCD~0<#}|{*zO$^;uNj z`?270h4xmL%4P5OdH08(wAX&(d5Pu8FM7QRawdgJ5RPPDzTQ7)vh?6g-HZpxPBnM7(D3qytx;(Z@Y>vdbeo`lXAG~(xCaxrph^O>Ob|DJ0P7SRKt(&=b9Y?-|c_o zR)_gc9>?1up-i08Q-&VAhlJ|}C zo(%rp4>IWm*AZF-#}_S2^WGx@4u2<8xp^?p$1)nOAPimIHUj#w!Za+$N1~%`Fey z8W}JmacNkI%DmhxM@-wp|CvjMFqbvyCno=AE}7)Bri1t9((z66X|PGDx4wD%?j3;I zPM~q{{=aMb(>99wUo)Vtj#12D`&X3>R$U9jEg};k8i9K0*y3SJ0G?Dv7#rq-DSFo- zNVaK7I)$>Y!9T5sL9Tfs7AWBd_2wSTWzQ>0WpC3b^jNsHj~@7)Ve=uuN@LjynlPZ$ZTH)Oq&^Cci?caCCCqIPK~it)WOSEtSpCu4ct(Wr zP*uQOKT`rV4pbBA8EIK4p}AwlC7`!y9Dl=@qic>ez5@K__CpiLO2t*v?MdX4)@Efm zH$NJz_L<&L(DwbZub0-x;Q2H6?CsqVeWYVaiHG0KRPq*4^p`juZ2bo{TB!TyXq0^d z5k(FfU@BendopzQilj6Q*eYQ-yhCJNzCwDVJY0$z&RlstI+A;#z(+E#rO0t9C+Fetv0Uml#9e&-q1VG|_V=eJ7X(R~7bg}}wsGcl_=ib;!H+4-XBTMH#T^kF7 z>L@fdNC|+FeJ)7dpm2WFeay@Ky{W)D_w)Pr`w!z5YHP_oD)ys#) z*AbICw(h_WDJsn7X94P{bnLhYoJbn+cx@yTthCCpbHqY4%z6RcFd_hq|1y6IBbliR zO(gI5!$g7dO>~kKt0a38yIh>4AcL*7Y-jQ zSj&bh@)EhghC(?mTB@4`8K8ZDwjoBRic)FlQ-K(im3+EmK80hZ$cQbB_6#oItf)g0&25K0)aht1JZ*?HN_<=B$CHk?(~gnIJZjIYDd{Il#AA$W^u#ejbFwkBC`iJ-JR6c-&P!BG3;ix&HToif-c#^DD`*`uo|pCG(25qWj`f zSyByk&Q8C}hD7#`@>ysuDE}jhm?7iH=zlV`HFj5JJBceXrpDye$@K_OpEAHjoO?Cn z*wR?nJn%LD`$9O|mH8rLN;pTVR;FkkBQpww8pw!2d8fIyHK;fwlGPURqqAw>$ue#p zj9z2|aihY5N|mikRanziEn;dMwE3L64e_t9XGOL+Jr+#_fk!r5z`qCr=SSInWRKLR z4Uf_tJ}f;ZH8T3A;2pe!5t$-2ciXf^W2@LJ<`fG-yfdf_hyJ9YJ>y!TvJU=Oq-XYF zcq)Pi7h_RmI-ZUaKlj#BCAiKBT;)srLok%Fm7SJ&GzYgGGtSAQ8F_AvYD&2817}{V zn_ha3<4P`U`JnCL;lsPe8qGI!8AD30ULSvM#fFLX8(v6#T2P&&j=2)>TyI~ef%kNk zUQvE05#EjOM~^B*vXXSa9*gBJGR+nE*z+;l5r}qWcD!yMp?(%Slv4Z%)F5i_4fuNs znrC1AVWK6X<~#S{A)Up!nPE;NRzN46!tv#SvyeeyS>>N&u<_*Zv+P&;-Y#~f|J9<| znc4;3YMWY4l~LHrtN9ZBE?t7T*pC0~(Gi-%`$%Zun2Z+7(|D(m@bAHL4 z?>>qdFyh+lZ`HGtX^=s79`>KqtZDQ$6OWh?=pV9P%O5jL<>N~^ylAj<$ywpo^bm_X zY$S#Rbsnf0Ria8n6d_3ut^kWN`G|~2oPR9MllK*}maYUXJ-#B@vX>4pvM2rxYvxsW zUD8xWDZbpg#yY%akhHbL``om}$mb}p}k$z<^ICCwMQ-;-!{W1FJdi8V4 zHqA>s<1-@;=Hl_HvRiXf()n>MD)q+Lz?vg{)PL|7($YSXs^Zc%H(I$%aI>;Rm|R0x98+?x+rpF-)N}w zj80eet&U2STeuX9U2^IC9k;rtH|iwqParE}pIJe*+LhOYVVTSM3TNefZyOdKE68io ze0vvkpAB5g^9{VI%*B5-!x^iBoz!KuqHNNo=ssK8zJDZwONN9U)MdeLCKf)ay2$T@ zk=F$KTfU~2{vi%_3MU2JBItg*tZwQzPI%pxj0_9lGR_W-n!|SVNqBlnD3!i$cVkCzy_jkI6#sSlJqrgf^0_UA z&S)@Eb+xxqD~ROe>CDP|qQJZKm%%HEAP$mo>G5fo&9 z%=-G=;o47rO*O;C9aZ_8ANr^V0`T4ijqG>W)zKZK^APJAt$7r%`A|7}`HWv*`P&?S zDYH-;T#WeN3-CIVuW>)e%F_r2J|dEk*T1o!`@Qe%)s^>AFJlMu+G>QH^ga-auG2R^ zy-oZrj=-+^NVNV5Pe_ZOrfqIY8`SEJGfEK#IL!u)KVQ{8{{2Q~`8)A-`ecXhIyfE? zXZDDk+&p6bCL=M?PC@D0xZ1`Td^Stb4o7X%0GLm%N#PJ2I z^$qSz?D&*IZ;N;*e8QwCO;W-HmHRQ4xT+{O6$0g=uw7HsaQLQfW0ElofZ1)}E0NiC z-LR`iw#UU%q6nv^Rlx;c$;WzU{;ej7<`@q8TEsx{jg?(S#}Et~79@odXb{nmE4alw zdFho0_!=>L1rEPPxO9B`vR35ngn45pl4#6U_^X4=*S;(}U$s&}cFML{BKOZtDds9t z7@kqM3-oP}-MP*Gx%&Z`M~x6yGTX@Iy!%nEy-J|!#k@21pxRn>b#zvrFX(2qLwN|J zHPwTU>W$36(1t>p=-HhyDq5EfIOs2ZQK7rZlP74C?5KbBzg2g&G{#YN{}rc#oX6p= zMrt~9!pL^?UyopgQgnX@_yRrOMv2%1WD0nE2?ixkG zI=M)o*Go5@vE5K+3x0NoGN!dP2iGB6hbnQ3?Qqhe>Ci-sAUm>+?n2!+l4g^N>Q{9- zvcvc_CTl!@yr^&+NX5PoXc zCbo7MFEy|0hHtkN$qi?~P8Hti1eoUl4z!~1u)j;8MgoL8B1M}xU+PvWPO0WR1C(Y> zFLO>*zM=PgW^#VVxymu3>OTM^NWm$h;}^)q(LW%5Wv(F+2*AhwEOio6-_zi(t9LCI>Q0%G`T?o1>H)noK483*+NYcI82guI8{hZWqnQM&B9jA_*`;eQ>8O|*J_m@vT+7p6EtFp^rJ2IlZ5>!sm`+C_!*;PvAMD?y6(|y*?;X#) zJAW~dnpNbI>=g;HEK&=yqh*M%ZHw*C$4mHEr{?gFm)dm9RPDXQsamiUO}c4Z`^6V4M>t8taxz5P$vTw z>h}xduzIN01L&dfqup~DtKTNKfEn#oUMT|?ui!$psRt!$Fl z=jF9rd)P-VW2UQiL^*XIfn|W+eDgLqQDmtJxMP0bChJkNx(mzi-rMYb`bvE?_k%bI zmQ4V5OZu$O$yt;6$>NNCQk>X!)kpo{ezShFmZndl{Z3+c>-6tFT^0Ft;W5VH@$g6e zm(rmLv0!Erh+`VTzeW1d+{d>l(u3+6CaCfcUEp8VVIvJfW&0r;X6#?J$DDOWjs{i> zACmver1aN+G{j9e0FWH20xi|*lpaZhM1Zn^>!vZ)#KD+!*nk% zJ#J*^-b$(v4QRQy0Kf5P#3X7wRK>jn1k#G3bt>us6mb8e50(lVf8QAE(KAZ|l0boM z6#2j|gflQ4$0$Oxc)hB2%>p3ljJVW*NvG?fTOiQ*`nY>Di)%aL%{L_mLbtD(V&fxk z>y(KYc6IqeHL~nfZCpi(g+k>PBGP=cb?t1bZRY9jk9vUo_~;yFivmxI(t{HVWvjG7?w_E$_i2TnvEhz$n;3EH5EyZ*GmUG1Uj~OppaXGpJFJ&bz zL?ykj!fS0%9`-Pz)}}S;NOO9L$PV&_cr0D5E!#8$1eff&MF!x92xR-b=(p*aff4e? zh?^SzdccBl=mkv<5`gU!GzL|;&I`7ueK+TV2=ikp=XvwN-j*x8Ahsf$o>(xKAY>L8 zvDT9d|A(cs30T@rTC(3x?4_P{hz#2QVqB(#@G2y|=;CKi3ArOK{mTCPIr}iZ23Gp2 zWR_8LK_r2JZ1FrIhubcWv3FOc52M~?TtH;%YvIF+QiFxmz;h2w+|ZmCa&-L?xzvN% z*pIaDg_`ImLj=hKQXZb+m9HsikqT{|K{?143R|VQ#-%k$MNd~WK%3=Ar_{N)Bi=$A zdX^A+2|`&hj+HjFs{BWz+RL0dlf_&M^$!c;Vc3ZAfQfIZRL;OVR0R`SH=vLgVCVY+ zcSlnooRNA$``@g-q=3m@lJcV);bSlc1EOGO7DM2x)M0732Y6K0Ks@jrSN6NHn#Y2- zN4ulV#k5(_vs$8`&a?!)JTFYWJ@LdG#RFV(BP$i2);XKL15;zeFtv}tRumAQ)z(a> zi6VL6UXp#P{qx#GWcxHu|MQlJ%{*~6T*+$t_9aQT;vpfQ`}3c+UH)AW!GqqIaY^7o zp5T|u7cS_xs0P%kaiK0cxnARt-PI`~%*aif5q9U^Y`e-k(B?%Q38)^bPe)-#RpK7~ zyms~RimajOP3C=l*?nsTu+d&HO{NrBwg07q7ewwRJ{h1T|6@&aFN3)|NZ@ayX}nNX z>qEV-7i76-4-VI#>Vw`p&Q9J5dcW`jCIvti%5)`Ik$;osR0DRTW>_^Ug#v%>3qll= zlK1sRw{1V4eHbz4pu$0ybJxzz9CkCOmnX_H+8;>maK8EUW>t=@J_j4-6;*?ARX#RBQy_FnU;?lPfoe&j3sr7lOk<4L2@$t60Y zTXT1xc=%mKOFEJma_-I-dAVPGAtYB;ek8|%ZRJyH%LCTMnRS70U6lyK&j3m{;5pWz5Au zg6TKF8ec|ceLgv__X~t)$NEE4*J}Y~okZ_&o zsD74;DwgTgwR9CQU@Z(O3#l1K$}UJdcaOyPm3^we z+GmXxVdfK}IcL({Xq~F+Gq(T4BVi9Fw)`sl)NG}b z3Vz{CE%u*FeH)1Urq9(^^7qLdz3<-^yM(@d`QVS+E?oY3?yYT@*!tv9#`jlGMV;I} zM@>SSpHN<^J}ebSad%wOzC0Ithrwlw{@tf|yZJR!s$n$&e$iunaRJxgJ*gaVjmct* zgkB?&54VshX}8UZNX2yQf_dX=2E)%ehcvY>)ph(IU^wPSc4usGNm^F+l%=m7@5lge@_70*!xD z#?9@Gw~?PPY~=+1QDz!5AA<~1S)q62Rx>m6q}!#t?t*MWY0AnU1GmN9Ih*RsnjMXh z^uI`mR`!4^4Q(&Eq(m&|G#G`xE*iUtWl!p6w-3oq;0&HI2kbmrv|DslnYy(mE!c74 zsaty%wy9kRd!t9&dZUBq7FUztV&Rc!4MLXdeC1i@~4I-xps%EJIx^7`jK=DBYF7U#>Xg^xIJ3 z2s-o)s*5T@ZM$Si=?qi3`al^iGgb3BEe&;n7ba}sLBHnJGI`ixtd2VPC^-#L<$1eW zk96jHNkQF`Mq+nqBx*YL)9)%4e_&dOnEEo+E>v+8nlIecVr`=L=IYT(npkY#)9!2g z!=90bXLro5f*sOu^ake}JH(sIYHO#l3&SpBat!6FZ$6QCMGi#|esPZX6` zYd5q`SF5au&}|}rPxvq|{w)Fj>(v{~uJvGN(dw+!cVma23Y>or^{i!?VGQWg@O_U_ zVI<_yE)`H=4 z^~7A}&jDBWSv^w)EPiIXoiZP5#B0jDqK)U+Vd8w}NLNbG#nSIpb4BVRGaQBDB|U5T zlC5tGi)N$;7hV<^C>guJ-FbWV;pcC+*o?H@gm3$6)(Mk4GMUi+=|O>>jyu{Dv=;jX zBOU9)`?>LE{`<1BQo`a65|i)rcM6RY)+K$ovf9i?sAUI)qz4nn#pjp{1J#k}aIQ`_ zgZ<(b@;c?%VLZKne4R2;=XKYJ!Y7dLEL}rhm8*U6@_S@f{{D!ld1a*8^|`rFF-~pS zaPe1rk*_OWYvw?S{heV8>v#9E8op@}<3pE&rPt%Vweps_jMa$u$goB%;&jTZUh!%J zop3s*#w@75V!&-CeskZ*`Z_~eArt+&&iT_R7JYolZiTqcMCW0Jas3yY($GtRM-t6nr-`;# z9Of^(v9-K5t24e*Y~9k#+B&q8Y;PGdRm}XW)K~wj+stDYei(zHHBmc*#dt%Ff-h|`eb}m_Q^Cv`(%0b;_k=I`(rMgUm}tEw5Ks)N{2)T?iiWN7^v~SdS4AE#aUd z^8Jsm@E)V{HrHMFl1GLublKJ0I_y5^lGsdXv-w|O3&$XK-c_P6z}URP(*!m#saBCa znoZfdVPWYw<|JEt=D6%j>HM`1Vj4OW)~2T&&ZGUJTopG{yxA{we#w62cR@aqm6nw{ z=(?xh@ZIl|bekPCoask{t>7?iy1km^YqmkXTEsx-VaTpW&DJHOzu|XEVphY-86<-# z^tA=`s;r0}io% zL1||HTYhrkRkE1gYDd#;`^^g2BYp24!GVe0LucmT`hnC^8;RARp1}B3hOEiu<@~C0$PWUloDkdoM12+7v;0eUTb6n@mIm-+|tuRtxXf^=J4sIjtF_ zc^oknTp64Kd-65-chY*c>_Iilxs5ltTeDyGf5jUATepb2_4?k;(1s!XE&CrD3pd(A zADq|Sv5A|K$w)q`yfLtYzhdxyFqTyw=Ko!jKjW40tK+AC{{0{@J|-b7Peypo_R=gL zuX4ldpSdYH!R7g@5yH; zGec*`Gvu>BWHP`>fT&S0H3X^%0c%IKr5je7(t$<3-Hc5WZ^e?Bnye|=y8 z<bn`7Qf|`|d20fxEV`20M*B5)Zvy~c;6Iz^oGf_1Zb zf_ty=gh*R;6(3iIVM{`bB!zJ^u^-;6e*S#xS+IEd@!-}(BTuyBlR@npPlq2dn}2%U z*O_|ozOvpWT=pi?{3pERmRK&~a+sL-%BLvO?c;kk8iyO76JJx8e7YspXE==fdD|dA zW|VHe!gnV9>wFwwq)I}xd-ah#Bdyi$Bq=Ry7NyNukC&wIj=^i>isjk3yPFTNqKf1?w)0e<=)Qy3dSY-E6FaUSJrtk467W%QPr?`Q?fe`KG)MpGB(=E^JV} zqdL*rhVp?aeeZVQ+g8p+AV&1l-gsXf8+o0j;-4ZM3b(KR7{zdwv{6@RV_Z=d9ZQ12 z2@uByZ$7qW6GOdHeGiMM-X-6Zpdeqb`i?Pw34)N-#wVnqeQ91}13GmsEA3MW$l)Ye z`tbqpTZwO-(?_68se4qdmQo?G_8GQHe7Dz19*q`I9?C|S!G`)7zkHVvU zmVz%29`Xxnz!m4SG|aUpeKxM$%y7M~sS3kgza3J8yBGcF^DVKn;0HF}*Hzk$x}M}O zyZ@nXTrFv#BY37U-u`T`$DpMI=gi+5zGvmrrZE(qQ@oipn$G>3B815+A8XmLkOz27 zt~d1jSl;-u>3+OB_ig`HgT>jYkXL*_NoD>*gseU(7$4EqT>e&m~;$dc!E!FX;%T|33xr2HVB5#77 zJI#!AxxxFc9@g38C>t!4N+jiKxjTKT(H;7u0D?>ss;m#t6DvtevkJL96f`js2ir=Q z@F#3pkO*Sla-mjq9;G{-&q^oYnXY(9!a&IgHxnG;ii$_#XAR`9&c=dVZcc=WvC|a* zBAz?UmW_vTErQu$W}d^-NHi+HKB46%5ni-`;)@_c5NSj@%0n443nars%<4Fom>V>; zo;wK0kNUR4T#g3HvXL2T*)a;lo&hhVk=asi?l(C-3z! z&S@$XDFoI^QCk1-$BLB;S&b%Q%f{4!!{xjo#Ul~ym19m4IyLL!TB`=^1$WV2U-suWGGX&hTnSw+K{Q3-%B2KXy#HzY&26opJ8Exi&| z&9Ivd>w_*dL%y~&u1GpuDU{e5xMZM-y@$Xo+w_>mfmDG?8oYILQsUg1UE*~ zJ7P9iwGCQyUd}n>5^0aJfVqX^GW7TE!r`KC z!ouQ@zhhOYC|1@=bQkeYHnI6LoD}(6=}o?%8$R`i6VaYc<#JxP%ZBBR!t;;YMtm?)t6?Siiy>6fe~~?AO(vyP2|^LL zuUsLH4G>M-+aEjet(M~w^fMq`&-`tPRhD0V=XqX~V z02i(^c4TW8Li~DxEYGGNf9|agNWx)m95~Jm^${*vz4WS=n}TuCB@rZ1u~1B`V&nCv zs?fQ&R@=v}5S;U&m`V43;>-Kkf*R%RA}MbHJQ0F+Vpg$3@H}+~4XcuAB9ht00f<%f zuvq-bVKU3!O>R4Ok2Hao?*N@&2Gs}gsH8amG%j8gfh%9vaU|*HrkFJms<3BK9ugT* za{X&+Y;cb!GyH}VIxW#C%~UAPjyN8#kpr*%G!xnTBha@7PHm2@+B!M1;L; zBxjxOHD2E_xMH-CYT6KDuo2SKDD}9D@BRjiqFdRiQ3dm5QIJqa6-_&RRh*Ak`P%4{2;UzU;kS zLMaiqULnvic#1^CowyJnM+7P-2y&?K%HwR7zDTgcfyAm97!UOuhF?QN;iN!myr~%u z^2?VU&FX!Gx#S6gZ-RqvPKfM4fYvc5`Kn|?z)#NT3ZjaF?T2!U0!+UlZ1_m0zU0e| zc}$})c@i|=AjdZkZ0|;}=fZU*09``P6b9=| zsb(I9adLnklrqDTpau;P2IZ1aFOAOn5EcTwlG*!DI-|RQ4sVG7tRD8phFc0EA9NMG zs8Ot!;RzwuYWWB2Zr5UO!CofUg%q0~+XhCAC$%@EHIb&}@ji5|Lrbd7SG&LVU1k!>TvMb zYrxZVGDLz1@BeM8=MKtqLb;vDH3z>T6Y5nztxXPqyU;L=m};Ro4w+}pl9$1H;&Ipw z$>vFuI=pJE(Qkj0GiZc{t*4vb;sj5GGvA-)xne*&@%s5w_pVV09UeGdl08N+f+aVy z1=5px_*#-erH1_#@sZW1O?I46>}l=ClvXIA6FFPJF^~nTO06$~cOpC0NBvbE88epK zt}Z}eC<^4iLoWQ`F8cN(J4bWD+pZy!6nJ4!f7Er2=9|mc^qfJ-D1zaDr&6Y+1j#&h zIk9ZCon(?BjlM38t8|*wA}U*a&wWTr4tlE1>gIqxb6{`h1}m4_Kc;lfXf&%B_MAxG zUtZ|4mH?zkJ&ss%cTt={VhRM$*sZ)Z_29Wg)cx6$+#eeS>=3&mC|XsZ}5AtIB4 z3-fUdh@H4q{L25XJWyRH(lUE!WmXkQkqCW!-Zyj7EKj^9iEHLFXgn|mSRISrtL3iG z_7|rW;0pC&Y_$b2P!JEi^zR9oY>N5gzmQ)1rrGn0)1V>FIwrTmeb5@fffE@3i+?Xu zlsN=L#XC?_b%|ljvwpRY$Kk$(?Xzy-S$*iFzY(g(Ud>#lyb~+w@G%SsF7?Uhv1aia zM0CJ|*Wr{B2l#3ZA?C$885wP#iC`q~D0Sj-{tr~RAzQ46O; zx;X@2a%WZGBL?!Ft>J9Y(l0o7E<)KO&s8h;X@xMrI)FFYs$3rQnKN_i0 zqyoKV4-z@7m0Y0A(`I5LW?%kXl&yG5bbayDFDP8vxj56gu(Rb=$0XS)r7bJwiNC6A zE*aF!y_U-k{z`@!q!%{#7dB2A>i{ptot3_fdt}ngar+^gao<(rhkbAdp!DJvlnJmjLRW9{R@yJV zl5C2M&QR5ihlY{BPTN3xI*S{cogczttMvQhiftdA&QWB#!z*;Ixd>{mw_=6^(>luI zh1fUyh7!Y2aUw#3vRNe-t$c&p{!5U=y$V;at8X?xd29M!!-ldo$M!?0E5fH>iY z<#6|HB_Agb*g)|an(T^FlXOB=u!OHlX3(m?5VXVuUn5KY#Pr+$*femU1Cd;mV=%vN z_G+>D0ZWRN1NK$YGNh>v5Qgl^bcA2@7KzxsD zPZH2G@Q8~LlD@Pyn3XkxgfNNyuAKIUfIdZxKTX> zT6<3lb0=tq+Rk~m@3Yjb`%l;CbCI9T9xiPf%vpH52v@C2Swz2(!P0)DRd|&VZ`-@297 zc6EJ-q1D1mg=>%TIe4ildPS>*Y&X-1wVVVU7l99bPYG<{B;xqJ6)u_jLp^p!6#~;-f77QcI@h^0{fR8LJf_KD>JIJM}AMl zh~;klII+^ng`>|VrNwAZOA+?m#$2Im^7m){iAKF_xWRw}?jHXDZ#aDY{gs#TD|@Cy z^Xe==!D~}1U@Y6zr1=@%O(HXd_Vfi*Y!AV|huD`DNP7HpKvyBO_D2gCLLU)gtXX7N zsjVXK_dF>|)7?j#&8vSrrLJshNCNr9G;Dh>Uqwec<-+xqSHG9qqP`p=fZs#*V83Xy5is<{^l!>lL>vZ^h^pm7 zA^~1{F@FAJA;9&20^1yvtA`c@i8R)gNlvLwtu{%Ok&$kKwY0XFNjiyV6jB1)9H1XS zW$+47+9mY0^v`O>`GqMEHaRjBq9bppQ(g{HG<$FXW=02{GnCYUva!v`D`I7^h7xLz z_HJjOP;vjA*q$85^{I7)*MO-`JxDH%n^%+SBTzybot^@hdi;$wVot4SmgH0J+dOm> zxot^x87b22S(oW1cST4X#xvF-D(*RIA#ED;@IC=b*Zc%n_TVYtxR}FRDu4s}%|BO+ zH4@Q=46I!CBefgtE$`anfU}jo_$u89hU=9RzpPr`8)r!RZ!ZM{NK4fVw=}IqQn_eY z4e*?g#W~~(2ZRL;wmRR*l`x0vm!N&jA^laJq*jMZf+%}`u=y5`M8LZcC^fq`gROO zEQR@3DPH6kEGO?szcvD@$%mYKCljL#)@}WdP%kC*Q#jG8xG^SBTR#;GCtnsOzz~gu zvP*1qi?(ocdgSFKMPBp>l3tA%A2cnalXLw^@M!{+#oHO{k7Vk9|uoVntn`PQKuu(G`l>1JGx{D!o}&Lq@Pz_`ZIL zNsL$AJD#Sa*IL7sLh01z0Vc-|TEvL(zMxQ8wD{`X)3;D8_9!>^gP=IOY6A1bO*J1q zc@r{lmq6Eu#%AYk_pOC~T&gRMw(xHDYtULwx@>O3%f*TC$W6y4q3#qo!xfDHTnMFZ zN)nZ?qo!AHuP$3|`l1)S&BXV(fELc*5xOahUTxaB@q5CL(b+$Sv|639Qbk}?TA-wD z@_O4cb!ao(m|2NGC79hz>1>KIT=3@O=qI6d=>6=`dWlCm;@Af$!4lESaz=YUXfJ(f z@ox9(9lJ(%Y+p6Pwx<9Y&S2#{W$%0;JLPhLaAv)LKld3zMAk~f6nap*g3q!*8gZD) z`{-}i7@;RPko_@!B{M3IX$foijp|980DZR$pF2O_7?MF@VjFGSB$0KarTvf`LZMJ= zvDgMO-?{XSK*zAye4gc8xP2;TLF3IEQD^cA7kZPWgPgay^>`<{Nx2EIEB=32SmdYZ z{21l*@NjlyPxq8`;=^&pd;?jDI_A%8Z`vZ(z_CgkFEMKITK}9J}waSxc%`T(tTg}Ny$kemY~BPyt~bvAWsH*omT4=FNYqE};X_K2z%68yhI$#3}h@6 zN`u!hS~EnG9Nva$K62V~ni8T7s+`b?oUgi}Jn#uHi_o#>HKLNDyL{ELkrQyl!l}E) zwipbasXes-K1Red`k<4fZrAdDMJ3P(lb|4kYtMjsaY{1D0JyZyhllv@lCy< z^r{O~$`5GApa3^79J`NN+#}w7-2nkqNz-=;xoL{rRDjcP>au5J zOf!GmFryY-o@A>RakYu21SQd{IR2aw;;rKKP!PW4MzplYtklur2z+;c(ou&f#^)z7 zaY*~Uidoby0Dr>IKTI25^YzKEvwhCCv&2%z3urTO=hEQc&Nw)33Rk_UM=)!|Lxmgd zp;p7vQNOLycV!%U%Y;ytcJ1#lB8FyrIZ7FetW+nzif&x?wx)Rm*NyKKaD4(d57=fj z>Q>C8v3{rV%fuK61hboWa%@h#vhTajJov{;CQy3t8ma|{3&a4FSQJu}LUha9xl;?i z*STwAn(kVMre!j^O)sM{=-|G^Eu!3X_V>kmUZz+0ssexN zod3g>*1cy$={a|(L`%?400DrYJ02nJBA5-u4b^qis*$B1rIA!s;{_v~-t6dWR^I|9 zrEo1~7yoiMPdukYz4Ju)*&P%)8ry56Mo6HSWq3@-vhwun8q?G$DWk$g{_zSCitwdj z&L+T)m+GHaHtJ+t+*4E`@AzOZQAz4d!C0o##^{ik8*sGgxhOmzvI54igRZS#4&c4y z4(PiF!yH8Wv&bP$ssh!5%xdn>3S%*BEjv6~BE?KjXX`gB&YOJ2;@p^K-5Jd*yv13Q zjK?RaS!pmEdDv}i#+;1nA1)~W1jiexC4HccGV$31iih652loTAG0!@3lq!a6k9QKa zlsF4xGlDWQ0$eYwg!EURc{*&qtM$C$(!&H%{r+fM6e|4*u zE%aRxyz5u*y&S2$cnd-T& zj;pZzVx9HjnS1MZ<-7%{epP15*>*BN&5CaRo0o^@yZf5f9y6A4!xFA#g-zIif#(B< z5sF4zKrRW&&r4WDJn~A|NT>E$*fZ@74H@;a@A_D6iAs_Tj}iL%GlyTb;BVvJs2V9L z|6;hV#5*T5;Y6;Th;@bEAmoYV;j>KtZtXLWcgPMCPse^^f~QOY7|*An;w)5GRQ1f;oB5AT)-|-TV9N)34va zYU&nu^^@N`w=thIzEYBxG@muE>~Q+-DOEQ_VBH8QiX3KS7@`(XDqHP{)}JN6tl;y} z+2j3U@TL5_4d(=LvG=hT&`AghHhLC&B>QigMm6487g8Yu=@pdh_p^u^Y*&K|ajssk z#qq3msXfJpOWMoAt6}m8my;2>rY_r%=aOAQ82MjZ>Q$fsHpaH?q8MoFw70t33_Qb-?gE&_xd4W^{%iU`Mj8u6j2!UwDiKo2l=vV-t4V<5s$Ke{ zilmdbkhm0PoTfh*ui}c8zPdFmI7+)+0B=yRN2Q449!%)W9{+QKm?&_3fJJ|k>`Sq&{ju2H@!#MZoTJp;1| z2n8q#2&%~3R|_oiXiPojXoU`W)`(1|a>`t!pTQVGlh7YJFTbbM`<5=xv)-9sXSH}} zbE{57kHTio&E%fFgT{fa#c|<_amJ05W}~z##(x>iDYE84xF=LUgR>AEpC5$3BVyL8 zxb;{QsZfx>h(hEN*Mqr4t>P4BVg%8E$%rE%b20T3p59PD7U~IMLCI3CI-;mDWIkMZ zwv4NZ^<}qta$U-`$ie~2Pa2C9oAt7x%4;e~|JOlIGBc6^a>19OvRotCnJkR^tMS;k zfrk*A1Xj=@+&18(q?fBSM8GB8p%h!}vAlr%weFGsC{2+?F*fadie4E{W2PmA{Ede> zkw8ZxG)MeDNSf0o06~IoH{9v<%eBOCv2|5w^L*+IMp^X=UnnTQ<%$}}Rt!yLM}fVy zk`Gp)`=ybBIMc^?xDo&Xn={WDk!$pm(G|aa-@gfP=+NWu)}mFfHSVRq_u7mDRm1D+ zGi<}Dh5{(G!+?^8?@h8+R@bR*Im6J|mdk8+I;s?k5HA24<)2af)+ko19M0!Zrw-eP z@vxVLa1S(e5C%?!VWV@;@A{QnVoI89>3i8ywT|;BdpYr{Tc(P2t{L~=jKL6{+|2k! z!zNHWw@eU6eZ`x*J)_Qqn}!Mpiv2YGGaeVh)#M{q0XRBB)0*f6auQdnEGJMFRTV2+ z$T=bKHfv%GDzs0JcMuIiVOZ zkVrpV?&;ZWD^3?@PY*bJ%@ayo+U*E=YF6k=2(BC2n7AZbnitVwFGU_?8WKcP3N$w`^;66i7-Y2Ou6Xn=y)I2cd`ch#1G(nVwxW?E-(ui7;BLkO z8d^Qn@CP85gbdE%7XtGjgL9yXy95 zcd+NiB3EZ9Q1RPs%Sqtj3s%dA)TVg&PiDZd1ETUlcWH0P`~}Q3#Swxb$`iSw#~yb` z!mak0_=(TYm$x!SGgq08aw|5mN4rBgpH@diwYns?xp0}F`3^Rj?{#abXEv4x0PNi7 zI_KLB+-v7TBFytj&~|c?s3ayu(Df9uun_{(1dNr}?7qu!55m=G_WRIkd6dg6BqMU$X`%Pg%541EQb zw1T2ci-xmAU-O1nF<(TI*ingvR3;8UYcG$baDrJ52*rkUknUFm@%vPDR&m0m?Uob zx7}qZsc6!Lj9EPO@6>2TAYQXJO5?nTnywqmMT-2yWLao-da~RUh6WNZ{_DrJyp~&f zV58zMI(~jOQQCc)aQA9Bmk!@S<6Qfr`rVdV^{PZy2&Ub=R!)~e2X_(m=v~w~s4|+? z^x2R_tx2kx(Hq>`%(NTLqcSW-qS_!#op4Smo-W^PzB~#P#XX9blz%rpFBmi$uMoCI zW$8A}`*PMW4;{9hMuXDEQQ*@uwb40*FC76 z=<8nJGb(a{eYAZ4%tvUO8~%$MiUV}fOC5K5$^w?~*B}=6hiua1D<4Q#{kwqsIC?O; zASE`rX7=iUN%DLCbq?H;HYH%g2z4-DB(Dxnc={3G?X~bNh1a&%fPaxdQ#heXZFJ=$+qJcP3CIE)>{Y`q^VVe=`-nMZYq%8& zBKw_aiF#=XK%?<8qj#+>K;`JWl9RLopNKugBHEy886=6Whi*brT5{(GF zBWp#XVtqAf|FX?#@68k8Y~D{ReAhL5s*2fkSI2c2gABz&eMTH9C_KUT~Vf#(yrpg5L`Et>NQ1H{_`_ zi0Nn%41VGEln2eg;WDP}dFJ!zq2h3rFr5)WPK-vHk4xA|L^Dt1O5!Zt>ih86DJDUf zoSmtz#d`W-y++zPDfAo#a%WvB`{5=;A9c^)w=VzeesVWldO)-6>6Tdu?TSHCYE@Ky z%%@V7?IEk}qS~f0zG!|DJQWMstmM~41sfB5T7q=t_3l{YQF#!c_Y#@WtYCu0I#+c# z6`_1fWM%EUkS=~60YLvXUDw0BM`aR4`{(d0WOWzw-7lOPiC75L!`%;VS7e51#b*&1 zU_MuKPfc5Cd3bfpi)}|4cJJ^7}gFgyeDrvm_ zE{TOY?YRh60d`&xb?m$V@gvKg3uAxWUGv@34zV&;4a)}D)ki-KeSajEz!9@0-?`Rg zzfVi^96U5o!pf=FbO?X`30}oRzP24LyB}}QL8z)GLO2hRFwhB%WFbzn)01Aeu^IUu zMqXuf=pJB!ZM((EZ>7TdaG)~gDBE~m{tQ<9ZFT(9uf}W&$5*zdec5K0sU8cN2I&7? zRV#_bqV^)QGaFrKixl8Z8Dz#RelnqN*7Y*~Z-tiTU+bWYRmb+&PJU$rMU#@d0$5bR z^fAZRdxdp^PwU&4gT7L)dHqWv!J997oL-gNxutjqXR4W-$b@^|YYd}IM!RSyS#ngAj$vq0tyBb$t_h zdK3QUmS(a4RBYSn`NghUS=qG8so=)5d$bx}bz*X?gRyWfAfmX@Hx{wJ_KBOjp`FNM#XOJWk^#S+Hd`u49XbFtCqF+B3LZ>-o;qZPQk$O&z9dOsopWssH- z{t;UJ?@5Uza-rl8nEp96(FB5f{*u1Jf%`Db zDViO;d@fIoCc0Z+bvSi_SKz8`mY`%jW3K3AdewsqdC!={Juwvt%2eYF*_v?uLa0T> zoSjS$o~^D)_squA&Q886q2R6BFFI$oM!<_wj@T13wBjauMN`A_@=M6Uz0VwC{Z%qW z%dek}YD2R{Xq~*49a#aNO3DKH4qtlMRb*#TU3^Naq{&u#dornQu=$#rcB+&njbB}c zfygj>bQ)pAe3#UC$r4NLW!rSWF27m29Ts`l-inoC-*A6I^KI0Q8UxLTs!^Le5AfxU zRue>NM&Qr2AR}yY&fgetr|MF_E|Rx|NXW?P&HX9B%rn)SCQJUt9i|gtGeoRmv0nWg zy`)RAupc&=$EMMn0Af5J^oTp;*kGBweXC(3_X{8FjnLhH&@0vL`p6{bf{j2jC^}sa zakh1j{z;3-`E0yG*wrr}+RhM#8Q$N<9u2V6+$X|NaIyD(mT zG^gCux87#d3ZDBySP@K9-PiLINEZ0B;|2Y#z1uflGrjEJZWCs0!Ah};w6~~PAT47= zhg+fR55nmPLRB|ORbT+USgpj|Eg?5P0cdCTc!BG5e({WV`Rg`C2x5f{*VYiE>wNtv zK09GGuvIAg9TS!B(7&TmUGv8SV?8YoMJX9A8Zz7f7vuC2N7Z5ZVnZ-*%toFEu1u6S>=O<+HUP9)}W=XaZ&`dL^Cdm9X6E`rts7+P4WQ_)KQn0C~+o-FvN{uP35xYB~A$7e`*9l@s>#{g1-M60|9#Wr5 z^GM(D!Tz1Tb-^@dGO#Sqt50+k^pYn@$Ki->1bXO z#Y4a{J#jqk^RG7M!kP|%!vowWXr<@m9np(COq1!(N@3g)Iw4m5lc-2v>nxoOLqqPl z+>y>~ahW_&^?=K6f2JnSXnl3P@Y!F@&MH4a-&0q1PA%6JBt~0L%zg5SaaC61s^+^( zR;BIu2i?kTe(wftSmv91X_Y(DUo!UkKOT%gMe=3{+A#SMkaa+Gc~_IgO@B_`U5{Wj zY&?bd){UCRw`Ksz;y+J^#AfMD3U!!vYQh|zG6yhe1L^K;H{+3xB<44^QZDntxhmB+ z?t4ro(V1Zrh0r4~pwm*)nK;?AZ=+)&(%=+ zheB4e=S}Ch^1z)kps|BvVDHdVFs8%I#QxpDwVqUq&hn~VZvhC}YR6HxBL#rr=-Y25 zJ*)_J6|7<~xt%cQU*-Gh#5saD;^#2?Y?<_5HI|_yrfJI%4N>ybgU9z@j?ZQ!T+>3)WhVaTPlF}DjGQvQpWPmM`H1|D6XymP&`-tqz0sw`~O- zjf;sIMBdKF@d`%3+vs_zhmw-t{Ke4IOpQ1GY(8ALydeY?LW4bo-C_%VV&8@`u`!go z-pl7V-Mz5g;uGF`JS^{*a}ClNPx0SWGk-LE`iiJ9s)CJ^emetwI*~v9TSE&@Y4EsS z?riMZXwZgm=L?Ya=e28r&cv5iR1w5u5EMf{!y=Apy*q(xv1eRMgSOBvRa`t&O{2R$ z>N!jAz&!c9QrX)4m?&NLW5vrk(dG>JWF0EOmjTsi+5=CC`s}i|O&`&K- zPDx_&;9kR0;=ILUYR>T!*UY~^Pq1lopDj>RhE%^~I5yy{9iW2ezJr7BvrR-y+Q}LA z@Y0h)HMe$fvqN+^CiX#lCpK#AJl}CaAfRA@1wXT_?~6AMKat^v!1W%(m?U+11fTw8 zjvz1mp5c#X7!g?4$EP;&x#r!oHqiIa^e}X%ICLsQ z3J5rKBi$fKBkIr~HFV?9B_Z7mC8bDriL@vqsVE9qnCyAqz4qGY=kwEE`XB9FbO%BH8v6o_IQZA@a9?9M z_fGUlmp_^f?1Qsa!6hfN>3$Ph|56A`}}y*XHnNH|@g3B|w_|S-@S`n1x2*N2?E14+77S4#_g` z*@U#8@~k$-2*t%T{knTTK|#;+@4$4~`0%3jJAe_3j|~x*TFv9IE8|n1$>0P|MLLMy z_8CGte4F&~r@Ki0$p(rbxUIQ{wB+inVlRinJtS?|r0bb|)I()>6KbtoUgtz%>l2#< zO$c=Ex=G2SY;m0B@Tr2}q5?N=tS_C25u+2ex)34TB;BT-mXttfJ^?We5~!jf#XxGy ze#TyVlwf&5TLEAxjkZ37_ z+&nJwTH`gxr+frX6fU2sdE)}5J)%aR_@@o}k0=-&1wqAdmNLT(k-a4cfe6+wt=xwRb)ZyH}Ms!07eL8<>*PW!#nb?vu_b8V}f-bssmAP~`7-+XhX^lTz7n z7d8qJv_Hcti{UP&!$9uuQlbNNXYMp?S1;a}_- z)5;Va;UQ#r3|pCv%1581#;&D$qs&4;92*HGG@=dOU^XrSqTcrLBnfz+NXz6|cIf7b z&lC7khx{yZslu7J(HXEFHL*oCUBb1V7qz}6CPf8RwjXJbWl=XweWfR0W4Q83M0%b;KT(3gU5 zkSz<*(!C3~ljyas>pA-Qe7A*Y8v~Yfmnm$scuXM@VNZVafnD%mXG)4A1($27_N;i@ zl)M`fLiJwO2ycQe8jy(OY(`I7Fn+6C`$b2&-uW+Dt7Wt3%_hd&4yH+hx2iW=xIg)M z#1p>wgn)K&ouQYEe&Wg5!Ak^+J|J&m0#$Vl7`u@El;$=BFb&?IPzL^`J6aJ3FJ+~P z{J??KzpBtsPcPza90T6fO*csG$1i=C1`n{<@D zJGrHT@mbWfh$<%D(vIKJ=;1t|gTz1m^Vrg`kB)rhWJJWMRiN(CJFHf#!}&BxDus^6hEB1MM3r+)pz9B|A06Rlzc=}MbcU` zJwaDypJ4v@351S|+C$Hg0%W&(Wf12Q^S%fk5SVV;(Rn|T3qEYxH0re<#gW{ka0Pde7%9ez|I~$ zu|b1(?It9)kT;H!5xAMFoXO{R7Ut8O4;q2Ftzmo204qI@6()g+0>VP4mG%?}!YyVz zdRE$5shw1#*hgdu>|1?M^8CkC`BOogkE~amL1H8>4m!AU#q>1(dLx~rCIMoLWx_^- zX)wLioHtiKEMUR}Y|s!&rx#b#E+)<-SsBqYtPaaZ#BpKt%!kEg!%O|$g_T}KHA<|h zkEY#6!$SETmYD9Cg%?sp5EL`C7&`c__n66HUdw%G8j`)DZLO|N&cHffrurU7|7NjB8-kFv{x_Sg<4+fnvDzSgo?a+g00$tlBnNwWuvYFuk^~H zj3XQ;im1<25LN|V8Oe*j_~Y4X&XID}_2(tq=EqPShr1GMiT4lY@=JQA?N-;ppy&I^ zxGfMi3}C_ZJ%2r;90UZUfkA_1pIwpUYZCI!^uLO2{OfIDUjZv%M{s^7(Zgjz5QM^Q zLA(&|QY2{U2R~^>fQ+ z8$bMdgI`|rz716ZfCdko6=GPM#LC}x%`KZ;g{<~1<7jrCeca;$?Wf*bUr;)HR3xyy zyYq;_!`A4ccDk|i{t|-Rp5z=d`Un-U0U#(kAc5vkcrlrt2+O>>?=z3=w9IYf{*WPl z*tY7u`pdUqUc~v?`vPh%dJxDC3t>cqPb-D!p21M$Z@0>}K?`TOiG&pTxTkdeui;@< z`f;kt`~H6ds}EpSZ=9hbAMJH^6J`*I6BuR?A_m$eKbzms9F~fxsg@pRl`hY~%hl0isRok;rqwm6>2X#J& zR`|oDj1PLaM`dP>pMw?seWCueU&3y<2A>}p-T#p!*S?b7x8k)m>-uy$;%tv! zhYJtLgvq?%+>WFtuStm+{}ypV=spzKC}Z$h_?dr`rp~40`Gvg&T-=|P!Ho6$OXvk# z?B&~APshRmi2q~V=-VJv`QAS;QkXI}&OYuxGKN%y)qj;^gq4UrdjYSN_9F%c8x${P zLSl7IZOwn2jOLb`Xa<6|R8?JfPc>7^(`RHs;~9qr9MMi-yHwmqn2NN9hDY(1wxG$_0FHEx84 zmOurwGr%4355>g;N*~v!H5p!rTDHgx9%y-M9fA< z2`|@F`&cYGA7f}jB(G7xAdGU;4Y}PXVAM??(SNc{1@jPv$Y}Y&N{5x1wJNpOv%S)0 z_2!ZuBcSLBUP?w8HI7$wEq5}UTxRZF8k$HE$1p+Zct0rG++N3f?4}z=f4`VdJN1cOd1#+hj>S{ScG4o@dxQ}fPuz+6 z?G-O{bxyMqy&6sSKA$zeEjRI|+66iX7U?Jz_fSQUzkU|h5Gn;ng+wQzU?Bu+UTGfr z@k|PZ9$~7qjZ>`ro$jWA?tV#xgTj`Y?Y;L? z*0%$DX(NB1)|N$%`Z5eb!zX_-plH%2>*1kl-7iwEELEw}Aj;8vm8Uuu!WEO7b?+)h z9r{}q*JSAmm>;xF?tXy%r`xIFaZK?#@#XACImqQ(z%YhrBo%Ia6Bc>XMi_ZEdQojc? zfS-1SgyR{L^8$vM&3~TnnvdS| zZyGYVA zr(qR_A34XjIiQaZUo%dk^&a^!?mU5nIO#qT&m`TYunha*V1{H&0-}*p<(7~LFGFJd zCi3Mwnrj)?w$1lUckvg)ET3+_etEDiHvXHQoJc%Q7SYR!hk4IzJrLoo!gHu|U2=*> zBt4H+M+thqwx_XyMq%&zWrhI@WyrA(j(wWD>qDVPjYJ(aJ`8eJf>MRVnA5I3ic5%dOkIpj&P0Wt1?%{j??Rj+W|56zX{ zbJIFyCPAjhcM!_q%SF()wiHKGvbeRx7{|eoQn0aNC6N9{yE%SA3>;R4zox_%C-V`j zl}S)j=0yU0dk|6GQP}OhMgxY2F)jgC?r}lAzX>MsgQV1Ooq*+Si;L<69gsB|d z8$x(RW7#h((p&@M)HQX#?}JCCZd>!83Y=RHf+LIpEftE`*t%+SclH&O0r}^bIb8Xa zG|WtOGFt2;BGvVgk6v&WG{cnYl%%xRUQ|uZ&Vw+E{XKn8yK{F?H2W-{sGif84@mwp-Ryg(LWpM-Jji!m z70`fGo%YalC;KmitC5+MH0HI-Ew>Y|Y?)-;#HcEk#2W`ak&f2zLDRNa>PG$oXKODS ztDILApiibA<>h4Mh9JuqUI>-DO;>1R&now9+&JHx+@cY**8HG>g%8ZauTzDZ@cG3m zr43&Uy$Lybkz+r|=C!j9RdNPu{w3cx{KlNy1eJOyFy(^&O^M~qiod$KkIPu1XAJ?A zmhppyc{1-o_QD!!%oYWzZcI@3WK(^|6C|9jBqtJgiGrm)mSHD#i3ShBV*0URHWDl@UBA3Tr)i1`R3nq z7jS)F&JUFtL5{D^*2~y?e(6P4+#oFU+sk|41c;22{RyyOn0y!@v|So`OaUY;tz9Uk zh%uf!fpgnZ9;~IlfH8asKAk&;Rlky;n9O5MK5k9;nar5<(`cyLjktRtEQ~zNA6)O6 zG7~Xqdv))8OeA8yUkU$4jlp6R$uIfP;E~;jg7Se!kk*@#SZIp!w_%Kt-x`NMl!FUD zp3+F4kzPdHzJ%_FvSi$DQlGgTS3ao;x4fJC)OFn3NIbl5UsEQcmIb z2lwduoJ-Lc1td;ADwwT$IXD^O+5CZCzDS|h`EuX;Cb|Bfot19OmB6bt(KDg^8E`K zKd+vkN4(kN@sXavE<=+tZHIr&KV&Hknp=NIe1Gj@DjjRs>^#X5V0=v7srrg#Bp3Iz zxM-m_HTzY#TaGT-1$`Kj8Kw+Gb+D3(fI`-rCsNOf13~EVrwV;wlw)5AT+Gl!r^iLfJcS`5A5!uy=NCA!Ooe-4_sNp4{Sr|yVn zGcO|ptwz<#TR7B*8cU9se&~bPaXBB|ZsuH4usvaO_~eEoMISAhEzhc4-&EZWxyE*x zdg59nJ(V$3RG!>pOB^_?mH4*6xc#y6`M-@@|33bH2Kz=osdmZoMq=-84*2EO59z+2 zjfP#c9{l>{&s;|I`6bQyd*k`QyBmwZ-~aU3biy%KyhI#T-8Bkm_XC#2JE`s8@uOdkFf|q1Uh3B2iHP=vf{}-woR*`Z-);C{6PPl@U8S0k-OawHpaPF>1_KF zsk^U5_tt8#;6nzq@K@>J<~aRF9U-pW_sLZVE$g6>AAT5*7&~{sp(>{36vje)(DcJ4 zl|B|{$)v{@EvFML?aB0o5hOg}JHrC!!SkvRqMx1cYn(vG58>RCQGbKubgbh_tpbhX zjP5S-wDM58k}os~^aijIlKQD`0CRn(hgUlD5>B&xA8(U$GS9W(Y z@FZLl6UTENlDX!)00pxE2s<>ZG%H9}J01r(^5iFHYbQzgCCzm4+4Ur)B_&Cp(O5Y- zUq@2iB;Ge)M2(?YSx9o%81EOZr!i$i=$EfOx|aTO{o>Z@;|Gcuc-9F^CJ_ulB;5t9 zgV8?4=loGp@TbVz_I0WAm3Lym01BNjv`+a|DB096fhQ11*!h2 z;S|dOZxgf?4lajCV!@GLGrcrd(-;HNlh`ob;~9xx<1Ij-aFT%a6Si+X(F(f?9DcAi zDJ1#SU<1OGAp4Mm1$@&I=er2!#=->_3HWy)h7+9Iw+#LeTIMaMLNY zU#v72V^S;?NTXf^Owrdj%qgsNkzFwt%D~Soho6+J%PG#f@#MU}m=o|tE0nR&>)PWy z9haOBKk{(wvUGUxZ-1pTkUdj}LD&JD+8CN`!dXUyffn-<$quLMrS|fK^6z4wAbE+Q zaLScedMe-qk|7JXMCP(s(Z(HGvaEqogVZJzJ&UH~Ra2FP zS_di=T+fGjV2fAah`Sj0C6he6wE}FiBzGoAD>!FJA%u$}AsnCpq1E1Zz%l?)gfT$v z1ke4Z8GOn>LrmL-h%2*a*~mIY@KdQ`*xjn(9=QLwE786R_S$}mU)^{SGIKa+#9*oH zd1-zj<}(11!NC&I7t~27Xd|Z}8Z?qOhbuHB;ra_3OsH67r+UNft3s8sS1WLbF_%fX zvZ3yw?7!R$!LHAFK~g})Cy|OFrZT4jaF7c{Efz$LBcHBFHyUdyU@RD%v{f;VMbZLd zE9w%moLXm=k!k{S@)^Z)_YI|dG%ybI1h5gR`XOBTy(H)s2DI{C@iG={rzp*YEw}HW zD#&59>M(Pi<|2M)Ei>ge7B(&g*bB5={X{c$i+s$+5TOmV_iA$Xqah&D)yt+RJ#5|K z%j$pMpaq?DCIV6YkbCv2^>z7;qA}$bygtRY8I~}@#ZJ{t(FSw4>_<8HwLMTG83$Pe zq7@~WoGv6n3xMtK)gPthcsiuSvn3U$Mavm*eTps0UNLPw$t7~Bs=5SvV&1V=ll&@; zDT-De4W@zA{aN>8!l?*8R#n9dZ0~S5@K%vlOkKg8x#V?m4(FlOv?EmE5C9HN;U1)D z{qRkO9|elQ(LRm`>*2sggROt8RTth~-Pug^<`C^Sg^1fhE}gVvC_AoPSEAH!{K}Sk z^LET7TgdQjmt3zlR)JQFaq=kxg%qhtkFL3Sw?Y5Axe9?!sF4UAYnQa^vb@tJ&UqF0 zB0CQXR&fFmvQx3e_H-ntlYoY|`PK2F?MXlZ=1er4K!1T?|l=~Iw;PXQujQdjbr>UV|q_da?Bk|ka3 zJjoCB1l}fs2Q&)f@ASZ9+rH?TY_0+pq@IV3T*Zu()prn-SlZv&L{8`KlHdKI*V!ls zJ2xN%`bEUCz>@~f&Sw2qUI0dI3}DJT4?D8lP~xB3VYiw1sinI;-u4f24p`Vhy6J%g z?9&atHbFw<3SG#|%+mq|u+So~97ulcQu$k_(1xb8)I;*pUHRd}LJ}K*+C$o%K)hJg zyRc^)GpWqK2VxH+D?p%7%yW!!F2$doM3b8A>lExyi=^n-=rM!P*;Pk&=}|KZ|i2HhnetezF&;vD7Y*)+K)D8j2ky`T(i? zRN)3tgTjW;Dvf+xd3vl5x{{9&A>R1RAkoCvTr6$zN$OcGnwpF@qX3Ba+n{Bs4jk9S z#qKyP3uZ-xHFN-ywkYAjIDy;!$S3wvK4W}Z4f!C@S!1=i3vDSr%UN73DY|Y5EwDjB zv8gYS>coS5i$mVQ-;x4h@My|mP61zX^TV1vp_rbP8TU~>VJkDa3Cd;M>h$Ys1n#-C zdVet36jTd5e~e@@p=WWXFA$)o+2IW3=}SiOQ8$I%+nCn+b}?-`33_}DY&Aq)j7Gl| zg7k=sb)G@9>?PYcC}@Wm;w05Hhvb@iUEv%xbe>GHRCB#~@u})_zeHQf!iT2ab;feJ zhiP14ZE2=wtv05)Tgw5WSzrz&X(PJ%S37K%Oza!~bex6TvVCwgTJ)m^jFc7;{bH2$ z9f~U-01}lU@kqhl4@f=08i=r7avq?(A{6mQIezT9td@y-ZXfeqVb)6?$>CroT;I3N zXO(^c8KVxTEBEPO{Wq%KVMczs=_i?Kx1U@U!S_p2FVd7Sl#I|zp;s6UUtBKtt+|g3yndUZ@51W9L{zWqmBjJx(oT6!M7S&GusmWT& zu>Sg#^SYJhb%t_ai7KRNYuy0C0UN!WyvYuFthZp!#OnMh7>=Fk`1SV?D1k80^Dna6zinv01v^YA+NHEPC<*OVSFDWajPu{#5AUq^P`wdcb}kinLbjo=qfYiDmwzkyip znq0noMmog z?c4m5K@5ahlU@jM?=1Ik*JG)!f1!}V_goKpW%7x9hD5rGShl88-Xbp=5f`XlEVvjQ z^rjLzeE~Z_Gdd(M zgvwO@>CjntxfWYynUcRD)BR-;Jgf@z$&}G+t>u)hny*Jkhnu#2i2Dpw22vt@S`uXI zI>orR(fy{os*>3}WQG z^|;*~?7NpesBr5juHvO**~J~V{#UABY1C;yx<`G_3NjZafrg|nzb$HaGnud=FNHub zOky9+=odmS8>F+*a-okT=SeX)K5jZ~`^eG{i|bY0{586T=6M_JV1zv&!>kKVZk%5& zU%aY3^a};fO3Hf5TKAuB|0bu}wWCvmAO2{Sc%!*1-g)`Z*7kev_MdS#vl>U4o6*6-wYstg9-z}?U_u6iS*&7daU4Xhj{~d0Ti5&&; z;VypM1pT^6&f6eELuumTjHr{6Q>cyNLYeru?8%k}U{9{t7UYwAw&mqfl~v>e+q!x( zdHlaBwl(F&Jr_BAdgPjdkPrCEFJx-RmJ?Fl(!+faTuLB~hUza~V@w3kJ}74ngh)#C;EBU+;_?n-#pr29zNmy^$T zPyDf6cSh;NL$rEIn#Dbm0D_+v>@TIpHthXOk?jR-Q9QQh915yvY%E-b;$v@bG-8A}!`=8|$qaAEf*i z>XcBK`{?NPOt(b6ox~T}@?WW=&+#_74jh>iy3WJbo@GXSHDIW{sUzL5AwTIZ_c$|m z@9hPtyYu}^?&H^H<3mHOkHzx^<~7rNV<*)w8MVw#WqsTjTbk0U!y3AGXIR7-X z(YTTMAr9P|zw%BZ-?yB!{`l09gx0nF&UyavZ5nMvsgCT!FF#K5U+Ei&FU&0ZbzC$I!eO~gV`iQ)w zhXSvt;Ty&bPu|`3#+MwvRk>wS%_A^Q(iysI9{6nzzgH;CubM0G|JL{K)4IK^PE!1( zsAgHu-2^K)wb=|B=j?6do|3{|ey_1#j*6J$$X=mmLyT4K!4>J4J8bZgY5}VTHX9R% zivgpC1KE}98Bm_!pT@tUg{mbsEmRagaqOS+VLwDwC~CkdmiD z-S+I@4wD-jMdFa7#7oPm7G{3I@)8#)p(9eT4l6QCkrl$wA{PxEU)exq%AIAe2hou+7i?-?~BFF8Gks z4oZU}OmhZeZWtUu3RmM^cGU6C=jCWvo?I)lu5V754m`}|RpPZu44D*3^ucHOa znu_sHoe#Q7kNk$zr(Ck{e&7DG?!yiB{;^~llrMgMYgPVOE~C$ac0(v-k?HV@dK|c= zSIKibT~{UZQYrHToMY)Lk0huAdo)+(;RC^z>@`Ki=oMFqFd^50pPxR}F)G{5!y^9{TfuU?=mJ(g_U_W03y#V90R6o6%dao)COhe`TuQY+mrUV=CUe6d{Y$s3^WyDU7Br}*#!00zmqH~Fm z%+YU@h_w5+BC_7tR{0{^dQR|C1`c0(G&1`Cd`K{Mg;CItMqkL_V>D-8e5g94@+4MY ziI<1+ahN2jA%{bE&$&!1Cbg{ga5vVIIppHt1v^`we)d{bg~MJ1Zq z;e~%-&X${CVl!5efw`e~_Ao?vK*MyF>sd7Zvc&gEqksEh*~FI#;x?Vz7%7QTgMFch zmlTW5dx=$4d6)lw)3(?=qm|1>-OwQ*tjA6LuFvQw$cO6NwZtkuzrengIL*_ZQ)(+{ zcp6`l&^C*jPRL7-tC5qspIBv;J&KN6Gm?iOV;G5m>VaAh#^ZSYM$Ogp?Rya5F9 zwwEB6pbBLo3%8fPSe+Z>s3)taN748 z)&t9Bt2i`Wad-e$Z0NcbliQ@wZzC~dv{IM3(j+8Z{-ii0uWoj|(eplg3wH$m?(Mmq zJxk7;#yKo(=BamQ9_iWnC+s{KIv3NvwQ9Hh@4Jan`GGZ0F_(+KhFoXAhk~ z>F504h)A(yUSiE2Ijl3wtKk08?Sa&9V(xZwJABszlNYE=q28W8TY#22~H#|Be)qQi)E-RXS zxdjVPX=PHJ1s0tX-!NTE2oX^5;y)A@_IodM$5!%SWHT`_rd6P(Eulr{R(+Sqdzxxw z@*CsQegRSean_v8?q z{>W9PE~0nr{1AnAZdf?}f-+I`y;_DzuWzL`f71=ot+=R@VSVGc(l7?#9=|m0nmIpc zH29SpP5IV>eS@mU{aLmCEoycWidBAH%Xo?CF7%fE)_GZ$e-3jP=MMX=raOJ^8S8hU zdpx&%+++*AQii4XpOs7t`@NeD8wqclvVj@ir*V9J8oo-V+N)!)1}HKoS8U5IU)cnK0#J)~2d#ET{H~($P{!)~E>#yp3QYJC+nZ)w5Jk!w=Wrd}#^pUQ;^>_Lz1mNH}j{95@MksJRPkWkR6u zIA!1Xy~}es)XJ6nly9oHUFF6PQ~!Too6&#w+FBkw54(VVvi-k8(CCR(T8~vZkHxaZ zsmaG_SjTCF#OV~o>Gi}Jtj8Ih#~HK5o65(VTgO|5#9J4{+xEoUug5!{v&TEJC6LWy zSL+1#kOa?y1n-^%pY?=&R^+BZS>3}O1Q7t8X~-8hT4!neTer(0BYGuw{M7US61csDSKogmUSW8uYfiPBO7Q zG;TWg8G9CT1H3A@USrwnr*3CB>pbc*WyB$4eD*f(E<=y5d3{!Y_vh`NyJhESJ3sd^ zx4X9c3bsWPotG#RbCWqfPp`J{P29tAUc3MHa?a#E(q8-SmqXdc;J@-xACJ3+uHguW z^7d79<Z#jBS3ZQ13l3^lv7q9I0$K{5A7=sg_W(|m($z4Y703xcReuW>~b4^=Zp z4Os_pSUWh!Z`!-FCpjfh!nL=;zh0UEIR}*pucgZeX}%0x*BpOM@nv5!#=|1ICpD>- zqJWQFUr`vmeQ#tA;p`E#?@8ueXmoP!7;S!!hN#C>ZR%((?PO+I4~z~)-|S=CbJsd9 z*eCNYHp}|SZ4^}m*_FEONVk@=7kH~8Sv6NZ@$*ZeG_FBHCP7-F?;nNuO2$CCWU(Lw zW1$XTrU1-4B`R=rxhT79|9dp!1Wf*YBXOyIsffl$UJXviKW6cWJ6SX(Dr8>aMg0v_ ztwtpmz(&?LP?SSOTMC2klb4eZ#DsV=ldAReZZ~jJn8ZwpRFU2U5r4`>3hjOQgGv>FWlpgdTm;%lGbSAoRg~PA|rs zl~d~(kKcqa7ou)}nYs{BZXyH2APPZ!0hf5U6C=+;xp{%GN^R59gC+C4}^ryo_DTz=2HR# zd`imhbv(QFpR@85Gus*AWhLL=%&O6`SKrrWy00DB5a2ZpTbTW^!`fO^zbbS2iA)le zhgV2*w^xJw?jr=%P;}5d^nRh|i_R<1#Mp_ednMg87$E(q*~&7zb)UsV@vsQ7vy}DW z*XKhpPNZa+VXAD)s!v9(?UoVcpD!0@9|s%7>Y>3myKguIOgsIe`TJwm4}E;mjxJ+* zz2$#}_7je2mge8@xB0Jse50Mav)>WwnRM;L$&VW%h%-COIhotf1+Lr-3_C3Y3kWEo zavJ%d_B2a>y0ZRI)H;2#D~BiNvp=(G2|}orPK+jE|J^-_)3;@u#p=*K^7nj7{kZ@B4O3?^P#b^`OBIPyrY7B;*PxZnfX%w-7! zrIllu1YYAoXhu00gnkQ15q1S3a(s#j<3dAc>!3szJvcZEA;P9kZAljk!bAfGbTQB; zm`Tz3Gjam9n&bNZRUT9#Sa6Gl+})TK*D24XLgVEr$klHo+1VhC$dyga=W4hWZS1AI zu6Z}x4}3vsqYo%EZ03D4`~iCT7%+Tl-ex*3GL^~An+qGWiJMJ`+B;x*S|0<7>nQs- z`;Ib$1Yt|U6G|FQRfPhzBYH4b%le(#g*A0((|F1x*FCg6icJ2adf1!{Di(j!MUtky z{vGWF6rIuAu=wExVcx%XzC=4NeasIluLG{?y=+M7Kp0#kMbq+^16T1(IN6`?Em^WJ zO@an$DXa3*iPg0DO!XmlK>t zz{A<&!vgpEG6JD9=eUY{ zA7~UegVE!ie8%-}aC890C>E(5G88j46URZWuZw%CQgXI!vNup<3wd9 zhgrX4d=tY9f7K;QGpJdoYoswNxlBmvWcWNv{O$S^H|bN3g#f$Z*|SHKM(reRQl7Wg@ZY%39psA5T3S`qmXoK*`U~r zZBD0m@&uY$#YAg4h1a9Rg4O7nZWLae#DMUFfMx;FM`w;#m}-{R43JM6FE)G59$Qy*S?>hZz3Qx5mWsX~7kgzi>cG(h_JI(z2H`3AYYlY zj*^PaG;2`&gqRZU+`c=*YfTf!)e!=Bc9gDoDQRi-ixb`3g(NG$vSzjsD55%uWI{F&oQ>&Z$lbb#KFXl3|I5k_Tv3t2vCk`N`XOBnQ za4QxxXQ3VrVCi)s=MGWO1;shGP42Q++4Mggb>>`X^TCRS6lvSO!djlj__r~L1occz z91tS@TKSy;7%h;Hl5+uC4@=y)#!bKYyJpQ_E>%DbJ6figC)ymeUvHq5*WXe!uc*1S z4XY3TS|#xeFvrCeELcA}%HCJCB0t^}!!0qv0bL`mhR;6{ zSF*Q%pvXJJ2;4s(a=gmGMHVhofZv)>vAX?&TL&(EgIP6nZAD}S6f6Ugq#@z%*Vu<8 zhJRf1!;A<1(QxEtH3MTHWaq{P4_md;8Sz6KthfphZ>+p!NDjWiqKbzVsL-$m*GETm ztl_(~z~QXX5o;G-$ko6FZ8Oe5r_*bI4i2U@7A4H9R50v3+@=`SX-Gbd2Mt0VyrdV` zv3)ZleFGeO>r|X~J>*+gq&(8ECh>tp`2#8~;D#{3j0c#@$wMIlT1Z(P`54~=Ach|- zg@M};qoqzPxJNX^tZ8==pLPmoj|P?xQq~3`q#uM9z#n{MVrS~mkHt+UlAI_EjeU#ny34TP?U$fnE?(!3Ih2B z$;HU;wTsKjJ)|D|`i;+J$sswutW4 zxiGth2pO;jk?)0z*wSA53XSTdDUry#127E6d13_+C*71LB0gA4KI2Vdv`XL5iS=Iv zIwq4MCcK>Cc7NhrXnqoY7NknBLI#k=gOeGONs!SbSUBdPEM1DkAQ<`+M85$c*YxFr znQD_#U?G?<{F0NoJes8RG$a%bfH4G!VxE-68dzQ~fAOz4c z#{F5oc?HWkk^4~j1S~iRVPul`@$fBzGD;|9k@GJYC$K0P?7%=I^4uZBJc$!9712)} z1HDqt=~-_1b0?dgB1cBR@08U~W8+~l5;WKeW5fZXXlR?J5#>0zOYXu*lngD^GNUt% z*{dYG+U)rWPzb?YjSeC`7>+G~E!5mMHio?&a($eb|G>sk0u7pD^n{jua`i1XxRLWu~lUmv|&ua9U?-(*e5*K^SMyx9*}V#0YCQ@DaZP$>X-liq;njep_RRVLtTN zs_|b6UyI;uuNv|zbq;j1WHP{q#O|j(h-jE{XvqugyK)ud7SKr~_>OSgodWmVyudI;$h2p5Uy?PZJ8wn^WQC4* z5(NvABGm><=)LXX4QA>v)gMItDlL0spu9)~%4}@lgS6v0tbg2Bi@;Zsu^9+4TD2g$ zMFAvLUe}Qf;VuVXLDV&d*1XMpC`p8g)XCV@(>&Dhb{wn+J0+JKMCR#an)M|xqZ^Ve z66#Ydq7t1-d%-v{mBJZcOgs>(rI1q!>#g-voe z(xH4OWgrogS`Qi0_wWiztXG}0Kp-u9^~I*@iE2qwlfa$Uh+mxxw$+VO?Y7;4+f&hY zCnnGPh)uGfGs_1Ew95nb`cX~r;x)LY=VNg%8YXNNU9c)sw(6FNz3yVQP-8;*uO`E5 z?F)Sgk~kpRw%qgFuca3Zf?YHU13H(jjklKTzG!7OCI^qM6n_+H6isSd$0u!iii`1S z5Bqm_WkSO_{BC||by^K5Lv>}ji}PrY}o_C~j@jitQ;=@D;gMTw=)L_;f40eIKzMeMf_ z!vPoqIM#gNfKnC(w0x0+&=se8+Hvky)mRau>UmhyUQo~3RS^y%oNWQ>p3Z4Spz5gB zRKI=xy_=P{BUjf&4~jsPI?d4&81ZS7{qgsLAO$aB8rUZ{kA$iN5#!z$L@!eeZ6|& zR0Y3Wm!#atUW|$paCNcF7yx@0M0;797<}l?69i4?nHXRI>0p=$$s(g)eF(|uf@{r% z+j+3%j#ocv^Z?!MmsMM%n%uz8a|TPNFuxH1$pK(vx_eua(D~j%kMX{arws!kKJ8%^ zp7Q>TCzEsrrmwzE73WMy1Agq2PHF~OMNevq^pz6WhUW)i8k`;;i2>D1whXv_g+;vP zqR(9KMMCcQBM*2pgVSL9z8^gSM)PRoafhLZ6Ubq#pOVabl!HlBmB~I9qjpcF$xkWc z$KZ7;KDt!05%5Iy@~c`~-%$uJ`e8&ljQIejfX(x)&-+I?&%78OI|ir`=G%VF43OOw z{LOdOKyA3Xvtmv9WMEdo?4zbsY2zGUnTe+a&}Th+I5mFN{1!oQ!BD4T>5n5dKwiu; zQNb;5SAo5zCZmIW5amF+*n+<*dDs-5a9Bhx6bhxQ0~k1sotOD$tT;M%ysM;fZRlyS z^!@8pVP6rjyNj0xuj=SeKVS16=Ib6cfkqHvE*MbQd5QKhr?#~=}}uMSIhuZFLWzZ2N9lEX8-!N;xJ9bbLL569ji|<^r23#0Uf3&g6X$?=)R#+OXs5Wv^U<0gLn!z#`ecw_nOE~m_1zDu?TrB zri!#b$?AF`SE`{#H6KxYwre*6dFl|-y%GF5e@6A^I<1Npd69cU`93+uH1&@UvKnt{jly zh-SJoZ}}}yW$G_1wwEx`Di@UE3!pAl_101(Jjxlleb;(f zfQpuTzm5I+_Lr$2k@upi;jACoTLtrndG&7EKYH-CIp_V&*4P$>Z#%PnIvBXWk+RK& zSQLqY>Ko!&CvwyA*497e5vgBt_k-4Z{pfodaFGd)DW_qv{)szK_gZ`7#qDxXTuZ&3}hVj>0s{RGVqUV1I{tK-A zq-X^~a`7>d1&zx>$wHUY($lFOuV4iwnWd$Xg-8g(Kp9E}QA03jOM@Yhx(fho+EP^pwZc*xf3?$`yg($rsM-2XP1j_D9DrOI@%XIHThEEl<3$*aX~zl zm+I}i%XQ{<*3YKF+ZU-wtI}jc(I?kb+xg(kQdRuTw!z*vh5rXx=l;(0%sDq>w|-=V~a2B6B{bIUmcMa!iwiLUUHcoJyi5hor+t=|sxC?|ohO zPxqg&YvCFc7c0`}oB1KCigre_6;1aN zbq|eqMsm4sx)w^d9MeoJ`*Q%SFh)Vk&{}K0=8m64Xqx`_vamDjo)mro62^_}=hslB z*XtX-f)m`(ln5J9K)ep)+4l7^5Z$JlM>b4NPJ)P^v8!XQ$?-fv=j;SWiGUo!~yB{<%lY8hlCex+P9R$t(5?q zBcXZ>HIX1K2Dc)EnTDhu<2)aG+D2tUuaMaO7EzI)qNd^P-jS*g;bXhYrF@l*7r9~NVDu-W_ocu%l6mBeo**a*TfV|ioQqFrl4YO84wz9?8&WD z^?Y)0Q<2V*35}wvomaZ7Y_R!6dyw>` zEbQj`J;lR;^5nD7*|W)@IYU(G%w5qCbxud=gXR`!lK18fgU4{?#OlIo$ERK<$S@f6 z@X)(wiiOGbeC{`ksuO{(jXe{rB5MN#>MS@CB>S1_mH4@dYks}N&w6%K2Y-!-Ow$mD zglbEhU}l*zEDs(>$Vq5ppskMYVEI zT-e?HiIhn|P_b*RA1!&l_YI{c293k4s7g+%#pk{~!*6%hKjoM@$1?ARjZ@9RG)tUFkG(C@Q9({XO zz>``!HidIP;ZzvD-j7@wLWiroN>!?@JjT@IzYDZUlyyQrz}xZmO)6BL`kSJo(kib^TN} zux8`RAy5S*C402r&V3o}aJb&^c?$o(MN0T)JMIal-#d+pYqY;&j|y=vpP8AHVbB1f ztI7xx6$01hmuqnLcAFYa9!~$Err%H{elVTpz|F9HyLIYwxMKoj`fMu%PYAP?d-7)Q z;Z@&>l-_?^!0OeTAqdV%7qRUH4qLrPY5Jf5jp;c34jNG=SNIXfNZJPdD~i_Y*724a zfg`@SSPU_LWbsH}9SaDo8($*b*L}DV-t+62^hOQ<`8VW%gMYoG<`;TB1CHJrSS03BDuBh|3k~F2iBbWkp85499-f0FD-0fjILM zdbSAWCZ?i6o!`ufkzkY^**+qWPT{?Ckv6>_%GQifcyGQLxD}<)qwb7@D>#3x@ET3h zR6iLw|FyEAdm{K-*-KCwPq$_H1p0PqOlSIkH&MpT{yyXf``DmOYuE#|jUtg8c*2d>XeM5`$9N?Yzv$jCN@_~Lp%dzKehpjsIu*KWu^(oR!J7=k@zIvJKpf-yPv zFTA#`Rrvl5Ld|`w0A*Un6#A<1v$JG_E(V;N)Os>&fp&F>>)caOZ^a(gQDa&HEc6yc zFyhAA8mrtTj(S}F!q#Da%Ss>?m!wP%Vz$F9?09-3Kg12*`?E4~a@Y%P{hqyNfIGU< zH!6%5D3K=oks-vh#de|jhXb0I+}C&#CH4tWYFaFM|5dIi{%>EOy!qtL?+g+}KANuq zOS=j-%fpCFenj(27|knmIQf|BpIwQGGe(cBJ<+%GBn4M6b$ zWwc7x6?*)^H=S29W~DeH9VeCcGT~xMM5*>Q4p!VsRO0IUlP^yB8~lXGoZ?-7U~T_P z8H+PQ(BwhSt4?WG1mqN*7*|Zfuea6n;`)v436Q^<{9>KgidVQ}bWXStz(s}<4?gNv zJ_0Kgo=Jn*t2HDM)d>hR}KJ!?Kq|M#Qdle`}CMY3cA8`Tri=Rd$fbufI9BG<~a6V<5VRwL5RoyoS*lx+baIr8CS z=CM<_AWVAfNE^;$K|R8s%ZFqZ>KDD-kJ2Q|Rnt&uX@KaoFb9wpCURZO6Hsm7%mS}z zJ`g-Yx#aaSjs1mLNB!R<)hn69UaB4$e5&3YZQ2d^GGL$UjhqxYnW5Ji4f6@%tLgg*p-0LF_ab0Sb z7$aj^t_sz41yk5r0-PkkOamYZB@pC$_J@I$G6fPx5k@eh-2^YL6hS%9T+5*QdU<7- z7;wKQ95WY1XZgEaeR%V&vgNTN-u5t#E*i7g z2zq$}{Pc`7EZCnp^#YgDqF3sroGCH*l+dqW%r^JQ(yMF}Z~Q2V?}6OAch|>P%Y?UK zRK0R!BXzYsajVEuGFR9%J?0k!w$EZilq!FKfV*fB8+^|}hqw?_XXm`MJs}33i2^7H z|F)4=gWFcSVoL<@_iqL7MC_$})HxMv{_V1VoJD|G+GAx9`V93r z!y2)e&Uy9x%PNSR3)iLhvitx|j10o6tI`r7ksJ^+R!w(cl{p0|ux<2&Y`Wf9UGyRO zP?Nx^v4heW%M<~IsF6N;u0Sg?EEiD#m-(7{uv-I&K@{obqjE6yK;F{M6V_V+K2DrE z1H@iZ4ML^vy3I8PrOud?=vJ0>k&aWs^C&e%ss!KBKSgQGyRv|HyA~B2pNHhxzVrF3 zG;}3IlLC7h9ir^1DfS%}`>YZ# zw3jiX1=xd?tix{yx)F98X<|(uOETJFVA)q~9x8&Id0_{sJpR7mM*B_cY9N-xyvKwpp9!_P>X6Crq7T7*|;iS(BQN%!gWm0zy!8y^q z_Ei&MP6D4EeZ$d%Cyh@z44eIkD}9Ep!v%?Bz#G060yglQ_!z0}zP3XQTeBsWyoZHtj7ciO1;!3sAH$4~hRRH_@FpGUwMVwtw zuZPTbj)q}k2=A~C)Af8ooOU*#_WGZi)c`=Kx%k;fBtrdq_+$8#>m76jKOofKg=-z0 z7b^#=T%ypzpL(B;qE-K-IK~zmT?Uqa)x5t3P(+Ui?&z<|9b{_@6(4(G)_JrA?rJ86 zjO*iqo;1J+5ui9m7xHPvNdg1yF!ZkY-sN%+o1US*D?IZbZFrbsXMT5gr=h~l7nDC>rG>b3ud#9DfL|O1LivxZL+U}P_*pYct zdGphwLpcOEQN4&YWIUZT=JL@VX9*c}iu&m@EI^4Wa640z_3++KBs+J;GM^I4pm@Tq zQR^;C3QX_YVT8bBTHy&@WuUNtrlAZ*^mD#6dyp|F99b9m$GI{44=mn|5&vy`#qzQ* zf`9wz-J#fSZ67Yc3S!TczN3bj$ZndNP|8_K5nz5gSK<9W75P^Io4KZ zQwIbl_n9Z}N{qjkn4*F;yAQp(+0T|SWZJ8?QBsB9;Ef3i{Nd5Ebb@CgwSV(gZo%65bUMPiW!>04@vS>>CzIJlE$yYQ6WVb~8h`FeZ#lZ8*efXn8>O}k8c zLf*ba5eE)BdY5ZYAN+T&2yxBmw$kDPaZ&TTCWo4qAn8!=>T$JPR8|$xo9nqnS30%A z(fz#s+~x7Pzdk>F5MGXf3_H>9-x={NSUl#=iMxk=WF*i+euZvu?`=?HoAp~_`Asnt zm3772U#)9KIQ5EAk_>7soE;B5;dms{O3=M@y6kWP>T`>~T^2h3#loTx2SR-X8B{g+ zL95jE^#1bO??lmul+cVr&R$r4lts|ui`$>KS$)~f>Eh4iooZA)6*U^L61UZ!K;KSP~P)Bdv;-^CYx%3!+hKd)gw)L(W-R5qRUy8nn zBxG8zu9&Y4afsDwNY*xqje2TgkM2Vsf9pa;8t%=?k`SEl~!}MFF*-wS4m+ ztf@bI%1=E}_LbDOK9*H=$>VOg8Yo2T8y8~o*v>Unzt>v_-np=@+uz3bgX~*l@XYCH z9f5NdE-pu=v8qD)_&(PDe7(U3+UFHkfeJ7rw;)SIZbNKRaHb>}iNTXb*i`U7^K-KR z_LY~do`^OCy|R14|JX{{J%6(N_TUEhg6EM(U*3Ci083|18NaN2n)MPbt3IT)$s6%0 zQ0=J5>h)LPXAOCCQJDjPK!vT0xE&(F&1twC+?QJ_%E^gteHbet7F3b2`kd?Woon8Y zqTY{D?wkv0z18-SAmktUe@Bj4n`H;rW_R~l-y87Uvv}@-aC0U^z1V!B@H?##W_$0u zedTvM_IP9avng>?;s8fFeY3ble7G2l-L6MBXHAy%C5?;k7&FZpxsQiQzmVIx4)aft zhg_q5iSDn&HH{y8iymLTqcreq`;a@Yg-iaK&E$K(o_#I7Y_EnP$A?c=fU4E>FHMlR z_p{gd{ia1PJo)I24SGF{7@xC^u7Vt0jJx*ek^A1LfhR{Q%X77rm2$90KR`;8zrWt^ zk$1w#GOo(=9<1$O+Rt$3?;M4MABt9Ix9Wa*Jv}=-hqdWH|Y4g32E#Z_)_= z#Q`FXWM$cd1}7JUB_CD|p@`!!kl`#WDrQdu%f&ccjM)6Onp(Fz5)yJv0_+vxJ-R(l z`vV>u8NAmKAp7i!AN&hdg9X)f#lmM|b=9j@Cl&kK%TzCcO1F}L0EFT}jK&+fo z%)mt%c*R}@E@F1#fBZjP^1mOS_xuKh@6m`CfDI!1VhyhpK&jhW4UJjWSmqvZyCJKq zYB*FKZ>I|cS+Cv1$v8C0e_MTOVEX}`&NxLb7%0~lEP9uSGN%~h31$$jH772tet(|C3Y9f*haIi((g7#ati({Khb&dI1>2l zHU9qLf3Gia!HESW>sB!7^ig8oWf>UuvgF|#mx%@w>d!QmtfmWV+Cl4E5pIDJ@?%zc zh1zcV)WkzZj&z^qvfj)>HD|O~^r>eL^xF8%i$Jg+Af|{wa$M&zYmEBH?a)*{8K1KMO-Tdv@cat-p#}kz(zTOVQh!+Qi)CAxpd#`XFy_T_Hkd%@aW4 zV~b3&r1UCQBA3YuE9n_7-vt{u<}jWj@}k;IQ|a>NN}AN(SzD+yyGn4_lsh+>6DlG+ z2#ofN3_5ejvzD>3U5d|i^@l8%MHJH`hGh9lJSivs)o~2Ks=ER(m-TKbtrz@Y{XhWm zu`edhVR18nY~wvU&9b%3yyOp18)*_A4hLANePD2_vQ zlP3MsVpCn|AtN!<8pmp=flQD<2y|$>I-F00*3XZ#VwTw*+uJ0X{m4kVrEhU@)IXSG z40fydziHF;mdKT1u=vlXVc`~!ltzXiV(ER7H!gjo((<6$|9&H=DADHZ6I@;MG>Ev+ zJ>G%N)bvhG7c<@LOya9CWB=u$rGWe;WD3fJo3vDOvyV*3(v-!oV$1GaF++(a&rlIs zz?rwQD;0+JZ4wG0PvMqhG`W`l7G%`!3cM{$P(6#P^((f&xEd0dX3h$g7j6(O9ViRL zBwpcPBdbTDDg_4M5VU^(bAIF*Rsc=1i%Y;md)p>;^@W4R#k(Z@>$^3+)P6yWBE!k7 z|BQn_)aIYPLIH_um^BelIuF^8O>T$e`sb-1dR7=6HLQ#g7VsOs{63-$TD{+{IU4tM z%=AkCIqh%qA?jST`T4L`1a?|rF1_zAM8qcc5}Kg=qcP%G{&Iv5+jbML0|uZ zA$q6e9hDo;wy#ir-kAOJ7%G8Rfu32f|027q>F|(hT7ArZGI=mGTFEjU0wKyK=|u5og+zzwdFT5$(~Phj07Z`LnACsMzR9cgkypLAjjMxSS#YM^#BO_aq=?)j4!(pAZVXA zM{AF0Zl1}8$g?T7KNS@^)rZ6_X$fQ5mlJrz?j_;9ikiqJ>Nf)!VGv0FmnEf~`-O*& zyOb~lJ#ma>EVm}sc%=fL?0DFNkgW_}v}A2#3-!-qONcw(Oc<9AL+KGD|W zKl=&B(}3WbniZ5_P&v$1U-0TXkJw^l!t_3^?izhdE`?9Sw(h%a$EJyhF$tMxS}NGB zo_-m-@Vs>HqDIV9Yi*Q*+~upH((uOGwPV>aoMCTvmaOVHYVlC8&4WnZ?u2ryovD$p zQ!w;`$bZm^_2tG?Bwy~X@EamjS>Mqr{$OZ$Ls3DSzZx_ll?7X<>2&X}$8%#6Fs+*6 z7kt+XDhLpTK+Y5GnWMU91}V7qGllu4SS$O#u&GY->tV#khJkqSQ%_)T7^*wpLX2r9eWVAWB7#faW>$xz_V zm9I?XS?5_HSu@bwp+fgeev&{sL&-mILSe=sr`G!j?Xflk`z-jyLkK@?*+^lCWg^v3 zG-_(p<#6Uh`i%=?ILIQlY47F2o z^)XTZtZ|RzR>y9hxS)tX*ybKu8%dQcBiT?&jz6+oB`NJp7ZspqAc(d0pYT#U=vSmed+HVd)My% zjUyot=}`0TnXg~n3c?{7)i0VpGiXJp?v#0IzG6>zzg}o33l?1E8G3Jp=zG!Q_oj@( zAw>P?rf{I>|Nh@d#Y(P%>3zn+-SC~~0U=2h@7eXSTLq_!e)78PE(O#kQaJF=%Bugp zTs3)Hqw)m%jXLd?cz=$+(l&=7wAPcL+fq22{g@J&C%|tMb#)v^v0(pL&2cE-lk&aD z_m$uA}sZnjqyYsi{*<^ zvwE-Qd?K&^=L88~J8CUVVsLEWIrz@6&>wthh37E0YcpLH@Rn;nlIWGomIOt+b-{>3 zw|Niv1Xg*`&Q?Xt?8NPVT5HQGrkrCWh<@$<5F>b(6i+3WnC<}lv@rkY34Dbm6C>o| zU9qUih*;Vqm3Wd)SqwGB_M;YT|N7qS3aPU6Wbf8lUM5zN>EY%74Lj7X6}A#=<2X|H z>41RJ+|q=EZ0kI?%Bcr!aK8#hWu8S=YR%t$QzG%8sB1iLOyKP=);m69%LaMvcYjx4 zZ}zJ|(fUr0Om)W94Nornd$BW}7?9uhU+ue*Yd#L%l&MSZFRulf3R&37Lj!y7vdO2k zwR$O$JahE!cRoQ!#HtEcP%pDpk&qN2No2Ev*GU<0Aw;TUcB!5*-kQL{cKZ} zkhmxK-6_6*_4-9Y7*RIP!vyvBef&=XNcbrpq=$;EIw!Re^5i=dM}_;)I4+PN7swoo zM;x?|BwX}Mz$2VwkuE`D9OBHdi8KO&#Bt$Qn31o`D#6RJKJl{5v2Bja5)}IgO~a{; zNEt=5TV|%A3=YlI>lc2&9Mhs?=wxGZvhuKsAJbimncTmMyg)}F8xpurrx;kq&8MaO zqk`wUqLsF<3Tz{q3)C+4N9G2QBu`mQ4RJ)V^sm;Zet4Ox5|-Mpn1(AnK=b20A95su zx`-=;0Ea+hPF*yARN@V*^gWig9H2bt$;+-f$x$)wopPl7>t>`YK~@P2;aD?rDnBNT z>6Es7B}V$UKNinn{}NG_?s%X8R$|gm&XDfw3rFXIY*PT3o`t4od333nzd%U&o!v@H z-OZ&~52vmcWz&>1nq`8N?f_HH);>gzWpj>B|Fa)Pko;7)cbe(T3%sHvUapw*v7g|2 zv_h<@d&~NT)0S6`V|?PAefo95za6J;QQ?Y_-fVi@pDwF&VcrpB7yot1>}}o3c|nyD zD)+9D94@E+Ct{G4Gq+>3zzVg*WLOEte(*7v7CI?OgiXmGIQO5uQ5Bs86-G#jpp|1_ zD8ltHQc&}lzM}|vQA84HogWDTS%HyKvf7W8FUJi>D&nZHb^Yhwxrqe@m-4LSe&iN2 z3%1h>NV}J%0QGD<+J|yesi@E-NX|<3VswV-RYmk0ZK*cpqRZ1%8(RL4ZE>l0uoyff z8!7qP6I3H4e%e>jR%SiGFJRJG#i1h>2fN!wBjMn%C)RN(lDWBk@I;+Ft@kR$c_o6u%-fHm;LAl( zIn#V1yOBRnQUC5LjB(PgV6&X>WAuWuil55J%&h;PbUI*{=fLNC5M77_PTRHC#NT zf#J&vG7dI3K#-t1tn$XMuuJ!)L+*1DX~ypiyo-|w>zw?uk+%lB?Tqo&j)psFDVT&IkKd_Ke%!UipY(LE-gNVD|UZoz&Eqni=&@=eb z;-kBo>6p(zQ}?ute0XbbZfn@0t0k-TzjM%Y{c!a5X_a=dtTpo=PWAuF+9g>{AmLs) z&NXAl+lVb-VW=CEVXmwLn85=GADf6}5T!uNVKPPdPqe8K3;fLJZ1wJlsN~oAyHX)i zrW=(tI0*b5hXzhoBAi<}M9!lfVtDN?Tj}sFqS2;ITD`gb-{J!BK?4LETZ!x8B7o9QCD_8-D`jvOa(!AGBqJiVBB0|;XI-{w z;=*)CxX*!Cb2D|1s;Mp@Y2+!%ag@)IBHHl>?7%VPO}M*Bz%djAj)xfGdX&is3ks)f zWansBPhaK@SzM3JHMB6r$A!_WOoi}iDv8OHo&;IZBSfy%1ELeX5#<5b1Eg~RP6Gn$ zB&N|h_{vSqV)x7ogStfP}yU>4!uhzBVja36`&1 zHo@j9AXL$=Q4W8t)+4}_+>HUeCVJ;Uo#IvN4|&#VR1pLjj-vPWe;kNVqsRO-<$Eon zTL6?74|@EHREUOs`y(%?G~}2k^$UMOcs=-4vbqJ%maP$w8Gl@41Sf(Je_U%D`}w!0 z!Ae#jm+s5kJ6a1a4NC%DvYrTB#rIJF zI&YMZ`hG93D2eJXRa{PSC)L!glWX0r461jg<J-hu~6lxSeBaMzU`I>g0k5Fkm!smJWpmWqxjH*I{FH0Os|N zmI}xo;O`8chp9|zv^KiPFu3?6**&!l9&8qO8}*Pkj@K`fcXLk2Q}zJq=|wE8?bKl* zU2#*Ic2m2Yi3-d2FA8;$;wB-Vt6&*Znt$gH+f5ny@*)487&8@8rZ#SwMH1a97IwFk z@$;WP4d+n1JU=te;>R4Vi49A0t7NzqbzbW)UlUPYBkpCoBy)H_L_A&cW(-vWK6ha` zPD9{jbo4X3ICgb=CgWJAS0@~gQNQLs)B5azv)*VT&#cU$lZRiuYF+NteyMxnXV39Z zQu5lb-pd5L_rvkzJo|;_$Sov46A`fVDw1}S-UG17fORv-$i1cfSlvkwszo|}t9O3G z+92)kqUW)DS-pNk8U4)AIrNR!P7bflDG@}gNlVCfBCl6KquDxPoCKYo;R8n1~-p6&4j-BN5?RGc<=xZ z8!qU>uQZ80zO!?N_u{A%fqIC0K$-bYor!&^JI>(>u}6r;${8!LYZn+PvUegbs6VzF4G zr}ysL%<`@1TOV3X9tp9w-nd8TMysNaym^NmqFsMN%-L8Voap@wb-^rL^>{B!KbG27 zIoh|L{f950cKNx-s?U;#8M*OXKhJjIqrByhKXF?eSQN_h1UmRrtNnCJ+b3E4XM2rR z6@H&A&kv1XzKC^c`Sd?vRek)@|MAUjUPI!WSNli#83V18_Wh?nNZEbVKKA-s*_QX` zw4_)z%kh(}z^lK;HN=Z^4<5i%vFNfxP|;Y{(%q>!>|&qkBLoiGnlo9(vC;lz+x5Lp z!A_6B`LFxezb>h2-VPdz7cIHr2?>_~6tDAK{C6V#gcp!7o__$?N`^E2^*m>Q_|e5Fi@MLJRf3Xj0~Tel4XG@ zp3?$eX4jOUMsyR2d+x)=>y92DkMwo$tZupIB;Pmpu5N?iMSmJ=Y;OGhZ&On8!5Zi@ z^VQUF;2Vmu@N+bg9CErbCe zOhxd~%98{XhH0+!)5~$;i?mfYDz8jFe@iRJ2sKR8T_vh}#c3 zc9OOcioX?cfBtJv!74t45xkmM@`z@WHNeZ8iQ`20ic|zaOzH*0G`^f#e@nU?b7nFX;&!&t;_8kL=$=Pa%jd{cHOAsWKBYdq3BWp%=EH=~N zHawA7r7q;VEz^Y)IWV`1{6umHq*NJQmGaBpdlm^QoDf~Li1Q}AFy-XeSUU%o!efuI1_H56m#!I71CHP7GiqzLJTup-V=DXZEiI$0G<8r!@2K|WvyNZFwcB9{| z9h3ju&gIZAc5gjqm0k|UYscUdWMqT$KK6;}j8`~v`=til zG#=?Vz}6=^504XGI3(YNo^{5WxHv8snoBFQ@Epi-ch5v5^{eM31*J^QK^pZ~OL=WS z{N$d!6PyG^2{C28`}a2{0@Qzrkej>0b(BsFq}tLLXY+L>p4J-oGs|%)u}uKVz=hG) zZ{XGsmu88T$(!+q%BY|}iRIrJ4;1IvX}lSOZ{{@ERM&gLAu;Vy5)r~@=5CJ)X9%LA z*>1x5`|t@_u5_x2bWdTVnO|BhWgyy(#Z2QQ-i#T>77;~0Ro;}AMZHq)Yw%udXm^bC zdG#I41&;%_etnvo7wr7BA58zn!C^EQ{FyVqXa~4NT~kGr4%HcTnB{pYbF)9W-+1_hwbXsDv`HN z-8oI9AY7b@R__9i$Eld92s2-XC*l(%=%kBFTWR@gUv-F**2j-7y?vWAl7uMZf$I$2 za`5e{aGOiv&DMPV+rnztuR+~j>@@N3Ib~s9><8d;MkU9y0dw3jFKvJ9v-}rhBf59) z@aC-!2tLl`5m{h*c0WtubnsMFNu_5xR;*@_8EMeaw(Qnu2=aP_fc^Rya1hQ3S-SYU zZwdq6h)+z*js0EwzkLmY38ysC4#JfXvo3k!G&rwuv6B zcD-{12f4OrUfJ@l3?*2<(-ZHxQzB=IGe027iK~FuL(}Jwox{Q4P3vs zT*icDM@14eNt1=A1>PfHMpmC+OSv7BU(1HY5`TB*vJ@!ZKY zb=#-FSGPbb1;E&+$D#U6?dG#+@^r5MGayx<_=}LhtnDzQ(75BE(rQdg{+zt^aWx8) zP31B%pJ70F1v#>pQf9;M^JJviHl3odcLmv7HP-Hd8aa&u{sY?q#yS9jV393wMUZ+b zR?t~fwbPw8EBKfYqL_{c+waWR|FZq$^)@D1U`OOP;n|6MF2B{heX4qy)G#Nr-~GJd;#t*sKRZ7xjrFn* zjPnrF`*#mX`yR?lR2PX9Jn3BIa7nzF%Z=hBgEKiD?kYS9`SrMPA0$N-oO5c^?LJfS zQolm2b@LIccly?{2z(s1?A@vI+s_mtGH_~pgC`(%zBK5-M+Ox8G~M-9|L|4I1`my7 zF1eGm0fgc{_q`Bn62)Zh=%GIQ-%(pUU}?1J=EeD*s;&=N7>~Fep-d2;Cu?+ z7)YM~v=e3{eg^1rs^3ZdEFtIqfqe7vkX@gT@WD`NR(f-79 z#kXSb8Wyex;zBeyh$#LXy@qxBmN62!$mNedTX@euqB~V`f0P#D= zk9qh+4pcemaPv?Gj9&s?(vSbVV02b_oJ?uh*EM;u1Z(cz{KV&RtCgm3lgO{|-z zI0#Ryr|K?6{(!Jh6+)gZWPcv^5S|RvVSxe^6;UtP&mWXW^P+k)(blQh<9INDz>&-h z$Fix+v@3=TkCTAl;~&uDk@35Fash(}@q7xAO-fL#=ZTn|3-AT3Hd)4v0{Kvkl?yy? zff4LBOAuT@2{&-KzQ=_KfNbyZxlZr`z!ybzeOwp(s89t*iC3=XOC3#=T}y0{gKT5Y zUNfPb0UWi-fXLwgUR=8-!JP>W|%q;Ndd+{LUp0l}Mc)F#wnhy?&Cwc!|JIq#;1fPXT=E5y^ zvZxfugZvYU^rVq!P8=EjWFy;d6Ctz>ulM!ED7&x8rYCvvp$gg%HH_&apgSjk}wf zD3w!f&IYk~q>3lvA{KD4P&gj}z?py&4W76oh@4JMqDLxp$3&Opi4!>5Wo27mc+CYS z-jd0S)t1V_+UvzQu^JNbf3c*q=k08jDlX2rOed>Mt4cJ@zpPQaqOqdvTL6OO49$1$X4F2O zQ4 zyt;D($cs6mSusc7cMWWeNb(NYF-KPx{m|R;r z^b;p)d;=D|0TgW^!wvMLPIFn6G*xe55QHX4ddtLO%j6&A<>?dvES_Z0H~9vVEkhE({s=%!+YPKwM;*=NMsen`9ZLx z(>kR!i)E*C&N&%f5#{hK=sVY1e6BX;yFELQ%fy=71mPD70-1zV(ZDt2|_QY%1N)NWQ^|PUX6ASG8BV_ko zUHZQ1Z+}d%G6clqgaG!i9f!(;o7xWj)#L!=p#y`0Y}ai=`Q!V{gnMVWlU>;}#jB@n zr7%=P$OyP01Kn@J=Y~HE8w}>7i>76RuRi*#EUgSa9adL#aogUI$z`6 z$CZvKAY%nY+EvE_cVwZiV~Unwb}kQyck7_m#xd~eHQEK+qJ_5dXY;gHy}(pvr``Tj z{;E;pk<&M45xdvier7#us(zM(IsoLT{`)6_HoWA{5_zBS>vQjqFvI{w!6pP9u5NMI z4S@E?0{PYx1q1i58MWLz!ckbrclYB&gQw|&LtV#Kk59f%Fg#nrbx4%=EI*xryMqvB_V|*6#<1y0IEtNc#*)lhM2P!a*e@B=KSZ@Je^urunSFMclDYNl@O?Ky z!{@;-fFlsmJW${dG~Og^_Lum%ioS(T3`| z6VK}6y2fTP>Y{!yDvZ>dpJg2F7q)f0EufL$aQf~RQ}@}sXDQc|HwRZ`&(UoW72 zCQj%IBznG(`+M(s_N!)DpObda)0SQ*kbf+Ux)xXi1Y z{Ma&gr+V(Cpq<5jOl{B$V8+pY{=u@AmXZ+db*2a~dkiZSwrncL%g;dMj~Fh0UJmk^ z)C1=g;~s7WJp+J|cIFuC&zo8XT$Z6{76G70uLM<__m1hz ztqmquGSXaN2sv%PuJn#8mTusTM&Vhx$Nvcik0Fk)bl(XBEIkZF(KG%Y4=U}zL~5F!?xi@dGj@A~6)mHkWRr#b2{SW@bbrfxO0 z9^9T<1<&3+erWml!8AfaZc*X%B2uA1El&8Js%|0l&5`h>6CR%|9*d0GA1-e6>D~G? zbvu9R^t=5zz2mj>=b`aYVPanS5cA7#|0!*58oNx~kW900?9F`h)#KC{gN+aQsPos6 z@>$%p6u#Ou+uyg9a&+4>l}FcaEI4u|t8Y8(GZ)7^`cMk*Px`m{SI32D!1-gOiDN!q zonIy1eoZeQZu#^@3HMF@-d4t^#V2I(%WmHx)g5!T> zqYvWFo&0q1;O8gVRaK*y*6d$ArHZJ^AMe86sI}kleEVx(Z^vEecfq+Ia`(Qf4uTSR z2>YHHLq(vscWM6t_AFS{`8_mqH--QvN|@GS&7un*1~Q z_=8u}U4iXg9vaN@*X5D;{jr<-k6r?mQ+pDOQ2+bCI_^=WF8x4EU6UvMTKo55HFx*+ zlWRjU`_)DJYv=!sorFZ(%VM9*XXaEr4gY$H{*hbyV(=4ue12E@IlS~>H;4l%FRzp= zohqH2k(rTZ!*i2*Gc7$UJ3lQWNg6F6fvKd$SO5R^4I0L+>!ABlHy~l3Qoths0FOsT z$DX=Xy2%Nkd9q3hm85g*(dZZf0l7DCB;+JkSKhw;Uq9EL$EKjDIFlzvLR1vOJWLogZ>bs0=`qe668uuiuP~!= zYHe{12k0N+1P9V%N7+D6OBDJ(p?A$N9mW2&6@_>XXoyMaBy zG5*2J&pOm>U5N=MB43+j6_n%#jF-)`p(z>J0&#&fJBi5#`^ zii78l)bl8F>}=%VZ+oBu4{jElNhcA||XDh|vx=^thr4wjR8Vl-Vm)ucO( zbqy}dSlEBdW-fJizDau?T5fJ7+wpaE%t>eYTGqg%=l8j*9E4ZjGGZRr?Y-#}rW`{* z{6FNqS5Q-N`?kB%AoS2XgkF^Z0-+ju5h3&rp-NMO^roSA3`KegMVgBACTM62{Pl$U7T+vs8b7-YlcwNSe%NP+)*Ww?Iz2F$12OB0ph_MIqXT| ziHk}~lBeb8c!Q%d(lm@@d}Vh-mPq(LJMSWP?X}v?VlJgq;|o*<%2w$W`wU^lLhYpz zh^r4?xFqaGSN6GEXUqPJbpFQ~+c!?zdCSZSHlGf=g-eS31O>BRO1<-nzX~FqY+3^Wn$6{t2rA zw+x^B8M2cT>n=F&x zhIr3IMV=z`^&vmDJw?w?H;USd@bA>*{W(|z^Tfj6{K%`Fu=wFHCL8|e;DxJ7%zmuv zp0koIF@Y<`mF?_`68st88_tI&3f|9;+EjD&?KGuk?prUQuP_~^iz>t>vQtlfN6H3v zOv?*0y7@0u*9iK|`kNJXFEwl%#Sh|~cfN48KHaX_dZcOTV2%!Z`#?#>K#h&g$fAus zgN=CIC1d(EwE5?jTY}ewv$tE3J?Z($ICD!Och1Sjg5oNPHfG${n3ss<_V1I)STa6k z^v1e_YB+!EuW#hDmQSC@Ms*$)NTCsZ37&WAUhX#03jA45e>FZ;Gk)daow9OWoR}zq z`}Ymgk27B^j&|#=O%9dn;%*=BKl4$1`Z_S+_c&80m#zBC=R>(4z92J2kW0+Q7%=~e ze|ek#{6ovJZ)XV}d1gQV(CGXDZ3Xlr)8@x&beW#ESRs>1aF2YR#x^%=6P7}NQ-9}(8;#t3kplP$2V*kC& zn}z2@DnCkpHqPL9S7^n%5Fm1Q(!9Eg19Pog#D*iQTdGer1^6w^X zvxXVgwYyOv#p!y#}m`+wj6-<`~lroy& zrzxd1EnCzAW4FM1s%I zt6I%IB;!CYKWKmeC(qq;w`^16F5sn)4D~K1m5sGm$$@R zYPi>AlK3ra1=fEzxM&D2<+|8#y2|w=Qe#s@)%@Ly%Qn*b4DIPx#j?={b8T&ydJ)I7 ziYbv88c}`IQp5Yj7-q0tb0d6DJZg2JODRcKiudrw?Zmub$2TEH!_bAlnUp=JjV?OAyf)#WF_=&x}%N;~zu)3RMo zE{iy6D?t?H{qxF>xSmWZ+p50xucTLe;)={PX3g9*(=6jP5zW*eAMv-mwZe5fon0-` z6K4}N&sEcGT;lxYlY`n1=q=lv{BLfbg??{F2GZli!~E1ol*lbI{47zYp*!-}EJGg#~4oz6i{W#MS9(69S3zyIuD zSO#X&ERJgV|L&St4$Kw5JZjMV`w@G4V7}4fM~lnfPmZq!7JFa*XpQ~*8OQQydBWnj zqx|olzvZKqrI*J&kN$q4PHb0qEPf8W{rffQ)uVSmU;cdj`|mdb%OHi;@??bn-+sE~ z;0E`rlc$>h4v4o0H>E63r(OOXmb@C=R(o~&GWOqh63fu8vE{G1@_$E7)J0u~SHBh? zUH|u^?f)(N#;wP+|8)@1L4aF;JQpAUXo3c*xb8E;t;D3{l+-k;J1r~wf8utkG3|c} zQWcd|)ufvLo6}o&&;KB;h8{oppSb-$hqwQ0+`dRHNUgkGU3>RmqSfZs_Rj9dPoMYx zw>s_U{}iOo00_N+NgHW63C=F-N_7y7rXj@4DoomI$Fq2p16L>i$3c)OVA@eXRUmEC z;yU%;xZQiY!nCvDML9b3)9O@bjURAB$T-2m#x7ZeKq|K{yh{vYMVe{MGs#57NPU41rE3fzQN zs-Mcbg^CG|VoMav1kC)PWQm5$`AWV$tLhF>iV|tgOy<4Qy!6ncGEq>|*59VqS21uas@v7BSoG}rijS;)vqPg-&0|>qeDLea zt3yK)pL(y`bQp$@giY5Rq)!mVE)}ho=wE&u70~j9ciH(_vC&Sxwx+#;H?x@Z=F|sr z0=pEG*R2!$1~lVsU+8B^tJsJ=8VhI5NqtX)56`k*=`9Rcd0+A6TC(pd==-`m$9`MG z;)Qe1m$!B%$vbPmlk(p`@wmtG?$?j&E8RgKbUby?As+;8ENZPBs<(f%dSPel5b-6l z(wZYAfe-c|`e$X-5NP6EAP2`!M_(RiBd*l^=0y_Q;Q|oCN|;O7e6N7!MW2b8IjKd0Ah@1Vw{ zjVm6uF!MMzI=#5|2ksCapS@N?H_@2fv)Zs1I{huz@%&^ySUyw~Tg0~jpUB-axF>Zc zuQG8{oiwCc-k%lHo%-upGBF{2^tnLctYo`d zA==>6nRe072>mC&{{S5JfA`en(x01#1O6V@UAf6L5kZ88=_-9@9`S$Ujb0m}B$|84 zs1HmG67qTFZ~HKyj(CE{*;^9*ltIOb-Ha%smB*KsZNfiad2&3;sxY%&mH?btH-X9ju7;6nGYPBKg6Ak$Odaa!C2(I1~JsgiB^tR#J0X)!tA z*Y_fuDrv+>&eOyPk7{@wmbJu`&g1b6CWf-KMcq~h5Ds)LahvDSwiPl*_Spx^j)LLs z*;G}tHZPVZk|ui0S(44VK4TX`pWGxv&m1^*U(i*cF6`wbLqvB+Ikk|+mlhe6?p(NQ zzS4JJEj2%LGt>7n9soEdDfG0|dLT0r0#L|zto3v1!ZNhyIElj5gUq{=iydZs?6g|@ z1Xv(4ftQg$XO191pHi_gqU^p+>z*sUC8CIzqSy@cG2CEYVIAa){w9!dtlN91ZK z4+h#nHuJ0cF89&4@!fRSWaQUZfd@5}491BsII`CPw)A0!5&#R1ny*$skFfTTle~or zV|3_+^lMDnIvDeG#QjT2*>r?hKi%p-f0`^Jrvc6rs@en9X!bUIPWPiYME){!-!B>) zDSsvT!6PzHE^#*J>rspF*%uJI7bOW&577FI723)hqS~a7u3E`|%2-jq-Svr>9{7oS zvrQ%`ZUxzRHrC>PCIbi?5b7nVJlU?!O8Ryq^hg3zuvcC3)0cj#I~gy65Sjwi4He@g z6>l#N)7xA*hIU=U$kv!)PJ^ zQq_56RT52jUG|&O=s9OC!masM5ub9Hw-j0qZ^ePd8A;Xmu0Dw9p0@MSp?8dPK?LFI z-o79B*1miBVa(Dq_oK32t^6N$-h@r^R*zk?hB!ZL#Ee_OHGu}ae* ztBauHI=z}4vd4d9;@?sDAh={9NoZp6WQg_nYB4H!=GxU|p>q#-ZGLiI6gZ;h`#hL} z;VFX7@6%VeXs)oe$cyq_jCgwR;C@POc}?3)u?%m^b8p7CRjdEFM#R3`+}!P-K|b=n zE!XRG9=b9>^P5S&&1IfXo3fgv>+ljtYxecUd)bFtRQU|4xL92YkJ- z`&`WXdc)S)+vzkrX!G|;%tx{c_@`l{IWI-uh!zE*tFQ;a2t7tGR1)vZ3IHSM6@_c_ zOLNq~o%@1kXKL5my)F-`j#yon8Qk;ej&4v&=+Qd%7lh9fRmFr}t3;CkI&>TjI0^)o z)Hx7mtf7yeD@Z7?EoG!0A9^mMWV&J;tLihO*T-{&MepDu*`cSv0m4oS}qq|V?>z#ns6;YvTy4zK2 z%`4p@i7%w5lQ>-0;X2D#V2L`(hO>?zx&nqLe!N)`LJ{s6V*ze(>|DNdx~}a+N9;4M z?`H+xdl6OF(w6Srz_aZ+m`v>Tdki@ph`7GdV!g>Smwg& zwo<9)twPjecaNDba_PYFk00kR*Tr9XD*G4AIhYI+ zA<;{Omq!G*i2%|M(7v~2Jl=+ta#>*}Au%mL9Fb^B02Gi=S;}RBySFqsZ$JnsPKJOv zimGdXh;rI4?5K__sjf6C!%!eu1cX%z%1$OsblM9%W!7&H3=fUvCBv-40oFFlOK9lj z6PzG-B8M8Fh=C9*OuGhJU-1B}x_C2}w zMqn%!fDs`T#ZaqBKp78v5n;h`haf~UyDtgF%z&r2qe0;?OGA`PsK=SNxd0$4jD>*- zfr7g^pJAfsP+48*LX4*(Na?Fx2)umM2@H6h$~Y8vxSb)^`)Ie|i*KGjCM&HZ{oMtB zJJqn1BKMqyJHPDHsh7YMxaGBcnJSj>=S|f^0Z$x2vN)omsm?=Duts_TqPO7H1UL!J zU$q1aY)f0@X2Tz=Oca9IDY2KEC0Hf1Y}L;~qV0p!F+v*KAv?QP5kK+FjS+JF5$Syq zoHO~VK!Ih; zLf#o#R?1ab0u+gbAr>A<0gEAKOC*N{2R&loZ}pH@ z&9&f_d@B2kHpXx$%;u5*S*_rkWa`Qk7hW}QG(4#kB!mD#W)kod?pV?_L*wdWr&@GO z1%v`oq|_d~sXfP6i5h?@XBudwdC5}ZEX{zJQg<38_=7qJT`3EfEZC{7W}v6o9SbYu zZGatv*XnEIivj`qN=OVe9#Q-{2_m$Ax7DQ4tIXXH0T9${I-*(TwgEeQ{b-sPc0XAk z0E7IRU`9Z^3S?u_(r%zpex=A52~kWpr=*h7xpQKy8iPk$sQxi!aJjx+7R+p z6^cRR{ZWUMIY*k4Z@p8!iz{ig=gXt?RInl;Gtx<1#99SB@YkS`CC1+lX_{Nq@Eu`v z)EsPxI7`H(7p?Y0fbqaI_kA~$`-!z@OY9GHc)1V zYp}Df+9%1rA8@xrqy&`)KH;uZCYR2)w0`Eh@s_JnhL6OR6)5+nMHLBhA^}Au4=)c> z`GuA14b4l=-p)t~CvT6h7=th2Vs?>W)BV!lP9Q}}X=_QKF)4BQm!$%xU76Ua&{8Yk zUqJ=-4N+|fSZjiYw$>GJP;uaHV3W7Aw;uuK5yq7f$vhU?*2&rmCqj1(!Occp49{BB zVxj-c8ZnpJgP*m;trWGQAL>vy@Y`T#KjTkjo9=0ZFya9n{)Wqr060r7=Tmny`Yh^D z5o)trirIHGn*ndh_SW%L{`P4)8v{0cidcgByLU^2Ga}efpv#&CmU0)-MDQ(!?9yK? zx4Y}uWF0f)n1>2dm%V5tN$mlefFZ_!^07j0rIZtU&2yk1+y?f`0RGDM%9j=?Q^{CV z*GOArGXus-v)i`36)hV_T`b|kxA2TUcu&!SI`Zdq3>avHJdWwP6$VC<+6`O=gQTE# zZ%Jny7SlmsHUgAwX)t{`AB-7bCjqgsL!d&^3~#0Oqsj+&I>hoJPRKMPJ2nLo=8cX! zX%XP>7g$B{fXuJf^Su3!t@8cVpJ>Wi;HJ}^Rmf3t)Lsf~C@oMk>#V3cBZ5kI1Yxb? z}_N?YHTgb-3&M@RKP++VqX|`jy)%W7HouKO@;fP z3(Fv;>h0jdQtCn#l|coJh*o4qq`7Q z>VSI0%Ax!US0hG(is}*eLF17k;KuNDit4rM=A3Jv`2B*$hvJ}eTJ1s%9a*$?gGXKV zdM1g#?lze}VBRBr@~u!r)(!XwPKCZStA8ors`phT@IxB7fiq7vy9hj8q=y4O8iFw> z2zPnny}QotabEGb47jVM77}dPt&1RlrHw+g7kZ!(-Nf0*H!8Mu8d@!gMH!S`* zk)_J9b?I~yg5aJ4Z9$w{&YZ;Wz4*}J2EQhBZOBF&u?A{2k~k3NViGn(m^^}X!mnTz zJ>NZKTa3et+x6D@kztZj+7su%F4PAJ*6z43%UR-hv`1=jCfukMX9{s??AfJ z!rFOm1Ve>BNN;v%<|O& z+m4NL|Mpi<;-#$Bin`B+;G&zg8;r4gW1?>oH7?_}gU5f5o@* zRHvaoI{7xa9ZgnaLCg-cqi0vu!lbLfrOUo z%xb6Euo>Tpk$lSV6{2%)+nYEeUzWJ>&i%>bFtG3E4BLC1WX_V%tA4P~ZjpnFNv7&a z!QYf$vvv;9;vhi*Uu=1;X|9!$BB47s4G~C4-pfHGvE;KvWL@zSG3iue0wjHhdkiIDDUBx6(h{KI?@L}p zZ)^PnOFf0Gx|>*e%4gYC)4QLH#&Dm+i%l@uU#U4+Bz@1?;P%~fiiZU>;C?{TKLx=X1Fnn z$p--7wg7ckLs+U-m|Dj(q)AOSR{$%svB~N|I2qxbik-?3IK-G%mX+;^lLHsMC>khv zUU*hkj=1%oKHh%6qx8LvVzF4bduBqLq|0Zk^Eha{MSBMsMlI?*5 z5SpVOiHO>y40nUR5nrc)G?t+dp1g^SM^+6638ISPQvjVg9L0H`?i z`4Bq{wqr4i8v=!wvhEQWg{G0t&QC9wQv-s=kWe@)0E?;-KyjLJu1NxWe1l27cCHXw z4kNt(Nw7zem;$uLaDQVGNP>TmbylqLTzKSD9a35{k&w?Wj`9;ok)$OO7@41^hisad zIV*=VBiL-n=J`Y7eXa~`i3mC;YoIcQ+j;JF)7=ndsd<@scI$)bf0DDW&&HQrF2+5W z009^I1Johr^2pW@eXuwbr~Rl@@>=YdAK_rx-sZO+#`Q$993`8x(|&tUepBM%0o-=3 z5aAl7z{%DM1rQt$D{Gs-^Kbbz$`V+4RWQz>P>YQha1O`$1+<$A#efwBZ6EZE;QtDlf6Ru-twr1VoSO z8(@sXL@ou+?lx|!B93;139c$QhcsKh6L@0vA73}EZx^tFbmtgnt=LRaR6hok99|Gz)ys+2@9d;joX#G zaOp4KRK@Y~M{>LSjnc+@;-40G9M^azN1cX;Im9ppYocSmigY2;KC%M)uj? zf5tpDDq>nT13NON7ih%>Gd?xP92mNFJXd1K%)s>^@eiP#fS!NYiubFEG1+XK5JEWi zKKr~(O>mV&8JwqjFfW{rIZj|$5bSs8bv5SvWj}95<+ToP3*!@{O#em6ol&UFa(ini zdEoc?COh?m6*%U7P?)>i2%yKB@Z(-dzZ?AbA&W1>@d2W%QnO_(o}-|Y z$0YBVwPrOkW8sUV4mnZbHr^K%tg?)GNAZ_U3roXB`y~(ak?uY$K_;)b^@<9c&sm$DyN12ch-gv!1#!pfOSHhRwnV`^ zCL`6v>>NL2ho^KZmq}EXNC{b=W)&)>?zzSoCHlmp373AHWNKl~mH-bnxlT5-2Hn0v z-p1gd4{IFgd3S~3N1#L<=jRWYbx{x=f)Lv!Z$6m@qjW1u4s*GUc&#*97K98lL2>NO z6tkZ&jw*JQ7%DI$@{^7z#B^JBmS%h zaqc8q5U+o#Yb!3X?5PQX@yEK3^pSfD(cswv1ylI*@C7UV9U;25V5OUXQp}irn@YQq z@1&ZGi$*SwGP;R4LpJrkU5GB!p!p_q_ThxkY-Ec3RZoG3vNIF?NM=4wd8bnB>Gr$0hCzA@e_GcA^##TcoJ0N%5%cM36I*o(CVoiYT9Oaa);H}lR zRB~_NJJrii{Ll;emOoB`%P`Ii`VIov_YXZ^NPe>9$|*c*nha)d8fNW4TArT^Wn^78 z{Or6Ts=EzE>PYyQOhsY)QNRVQlhx3A_-v4YcNXi^Xiy<`Fl*$aIv)&P+9TT_vPpFd zOzN`IW1);O`}h5|?N8)LdBBnMtHdBgwn|ng`AJ9wlgr$syK~GlMEyTN6Xvw zN~sHL347VF-09@sWT0}EtLHm|_46NLzP#|%raAeJWoj+xZC9WqhC@)E6G`ir@-BRE zY~|Afd$|C+plgo5Ii>t-02)HVuI*u>o=`rWGAY29w~vm+XT3_9RWI7C_klY{rZFr* zo|m;2?)LFzN5j;8)%`7i&1VesiQ@}hoeHb>!M#iKuWg>xOAT2E?+3QlexW5{lYiOQ z(0lEgk)1JZ;@KB?v0t_`TZyj)yOT>U8Uns^`jd9d3-+{AMA*pZ?92Y#{FmwR2GT7U zrnd(KM>G3{rk@WV7=9HL8l;c|RiFqSLNbH*as_~)<=_AsoKT?a1&I8_(~@x{A>pez z+VT9+x_E|faPC<|J(%9CH_=cVikF}ytlMw!vJACZ|HECD)639}-ro;CG-Q=>40bBe z{6^P;wO8cD=qZ!{2!U+4BvPcUS4&3C8kt1WY!a$uc_9?p%8*3K7OebiLj@DjH{G zg=eikR81F%fC4$AZz0II<3YEGiqLTf(5OA!r1yEB=BU&I2}mpA)(TP zmv|q0ezlB+>L=9E;dw7V{wfL;yPZbw?jmxGHYvv`0QNRY;?H^?Um)=VM?hB}5? z14JPaJV{J`VDa+L(!=+&p8H*M7r7zi!UO)U6lV9;n}&L? zTDK-k>$hJf6QD{>AgPNJcFVfIvnp|Fo(Fu&cnS#bb+5krtJ@Lc^aIFKpK*DSWFWl67 zwK-DjuvTh=93fM9qY8Vgvs>LOgpYp+cm2+(U{CNH<771l*R%`#|M>wrn{;U83rPs*Ji@SCb| z{cifx!Z2=heA=9gNJu)~+91M^_f!OdtR}M4VPBMRriFHW}$%U{B15mXZ zY&`bDGn}VFA5*na+QcY~W1l+-bPGJjR7pa*th+JID0U=s|DF+5Uka9HCm5iEx+n}g z>s+RhAgaiKmW*{JU(aNRY#D^y$FP~H#TOdmp-7;_DAN{91$05^Nq`asB#qDQO$Jk6 z0imWu7aRy40P=1lI-o$3vl)Npb#8TmOO8Q?y=P$3I$XBf)|@lDW!QJjU(3-mjrTtm zhZqM%aCMvf?5@=6F%udIxt4Hl=;t}eu4+GtO(FC=EfK;;0;%HxyG6WSTW){}!0E`A zKap~~197~3Ic`Qr5^F$35`7wBYMitV(G!lt!>;&)&lf?sQAIR}6d@wm84s3eEBe>O z&79{Z)XzjjI6on(Fn=9)Row+8`SGkOY&QSy+ue;-6!I#qe10VFb)jtEd` zXj(+jA6%FuI$%kPjg#l1%Q6pjNR{RnNVRs*;z7CyFgFo`q(%_L^E-~7OvBgX@xYz= zl8gHV7fS&?1Xz+xJ2VHF5zZjIq&xim0U-eqe?@NCha1MDd0vbZ*ZZOosB_6CaUZQp zf+4)>2lPcsAQ}X?zZ4L`Q%As{I3i3bw2(W$^oz8CqL^!hIG7d(@a>oMnL^dcWu$&( zA|~tts+!_deOsNh5df9}01FJ51H~!KmNs#kchd=pAcMp|R{Sg$eeJJ>427l#6bu#X z3~yF)lggnjAR3JC;c46_UhAtOROEfRwQrm(H65Z*ub=wx24yXlfSv1(O>z^Llyr_gwOI^<`~2W6|9$!L*bQMnh%De42a-mM3-B=?iIbG(V*-n}aTyw$z)g2W;G>la1zI zs$rFqiC`Lou_F^I74<_PMd}FfKt>~^1*D6*!-a*&;!=DyjHV7QJrY+6%(S8^NsUpp z*8{5!$eG)_mveOM9+WlHpg?1z0(hCGH~Y3h&V1}E%$MubUzBG5pftL6)l^(LKZ`HtGUkV+t|xMrlnM+#J<%4PtRsr18%izT6m~$obwtf3p)AvO06i7;|s?R|yRk zx=938jS3Hz@o}rv#4TT7rbr2p(|DEXXXs+rpdc=!_yWDXF6HjGfpT_~%_E<}H$YZ`&xo+iU#$bCxk^OPYc>$It!D|qq_F7ju!l`~(NC9wguLR@HoD50 zv`A^@zbpJt=nD>cK}dWvvb>oa2WG=UZiuzB%W;#pAOH{VY7IPF1d=U#%azi;wbItx zlF3RPZ~um#$IxR@rMo*Fwqw3yhS%1@YotFivYUa>B@k< ze27{e=+aSxSo~&_#q&N+mV1cHy&KYfFSGf~9lk+5rdGY5Fg3Ll zsEls%bLC}R<4AdJht(ATsz^SE!W^-af=RR0I8WPhv<^#XYnLLbg)&-vO`9mw02qC zw-LuY+dCCK{Z5yL~ugU_1nnM46)C(z|ZUY)H= z3VE%}0yr`J!~oZhx@qdaZeS#oBD#P!*@;U>^4j~te39VXb(r5b@^piVrL*^!SB zt=zyk;mL6KJO*~#6pExkQd1|Q8K0G<=q2da)Nc7d66UX?{F=%vu(r@rWcOF*%Dholh)z*I1Cz38REs6VJ<=G_Mx`>FY3R5 zg_!C$%}t%iL5zHKKS50&2jBQjOpvYyekLvMEXsRW0qof6?HG^{T-N5qs(X~n<~-fX~OkgevGh{Fwe^zPP`- zCdBSls6XkxzUq7~1D&m$sWvV4`dzSRLP44(|8A&co?~YFR5uByGUwAMrt~Zv;FGyU zD{g!}O`;m1J}|8C%I)5V$uc$^h+#sx?7`YRL7d%UT_};0kyQrg0*7y7kyvT$2*xP&{8L70hKnyVCOL z&4Lnsk^hvDkhy8z(Qf|F^O7Q%#TtsGI5$vM^Zjet39!|x+)!0zm#^<6)_X6EDfQvS z)VSl!<5kJ=Y&ju-O|Z3zEbE-EV6FX*e80K{4)n$5-8SE*n*N#tZ2jW>&1$#Z(BxNL zy28^q2PG7Z5Cd2pcymDBrN+uIBvp7|Y`>b>75Z^>mOi$7z7iyM@lNus$n!TfK`un< z3IJ_v8_XLI^TvVVF<-A2O1x0=A}sUIvG~9S285ZcP~fxteGKp`q_)w`gnDoJZ;f=sv!o= z(tbZJoiyHo9;;f|ySy|(k}uyZjyuMx?hc7s=b6u9{V zj3i$};f$OK^55-XKaE|a{BF6|sL$=HJ1k;dkc_{6-{o!tN4oV2O6}^)b8=Qbd>=1$ zUqZ3>uFGyL8!q~X0ik>?Zkqqa>cd)h%Tf0|&R<^DUb2heA6vRVf9Ssb3>)zDLYFIA zKw$2apYSJiNAzcgw<#dQ#+4XmFgx-{m3jXsA2SE$q1pS*J&to$w;kefAU|NhZ_%S5o{Rr-g+W2UU1%(Q76wMIG1<{CA`Kom9_K_t5#_kug3byDO=zs4^ms zi=qNEafAMCsVt)bLXH@Zc&bVV(76A)t8z!Vt{VP2QBRv&eQ=N%S0V{>!B zlcJZ7{Ky8>ja+h2y}J7RKrfBCG?hWl$7k6I0hVSKFhW0Lf04m1fz6aou}%@_Yoy%B z_>CRIfN@-J4e4_Wnoji$>Drc%agAAn=P;}=)l5qskJzWutxIQ1rm+>gw?$UGfeFl20>OdY80UkqP zV0x7A$+=JcaTut}$yTmMWt0~!OIth4;RJC)4+Up z>2>l*Q|+g*5eD`j+3ZSWTq4l~z7K}wZbn6?x;GY05j=|1iCuTI{he`=#yf)?4o6BR5;z=`cz@?eq!i^>=l?st!9d zU!x^^ld|ES>{#N6lo)S{515NMe1IjuEbs|VO1q;xeyaV1gl~W{S`R+K{g|z6KN|4EP&04D(~VQ5p6&snC{# z^MWxnwEGDNx+a4kQS>?S@&(Q}i5OS}OI(KMIQ>)or%D=M^Df@lyehENcZj+clJU%E z!{RV0?m&^~L^lFzohc{vv*ym0($fiGo&+~DgSD0uqv)X~SV;<)whwdes*FiD;e`jg z$#|5OuUG+MJzK`+%~bx>bIZdH0!B|)uorUCR?>%Gd}jT^Zzza^jJXY2y_;KwNmjW( zjMqdVHOEfP%Ml6gUj~2$?BdIql{s^^-DyS%EBzq%(3_?o*83$9psqF>ZCw<==tE9Z zFC;^P&X%1N^++{IE6TjwJVX$q&umuAytO*UX7|?x(Oa_6v=v)H=~g5N()C?(SWAzo z1DC)SOkx(A)YT}+gRlpGsT-pQHwM$r*RC9b*>D#8OkQ)hT4e7wj16!R66B#d7Z_Afg|`&sjRo{FE(* z2||0A<9GAuID+N{W*DNNdiRv#KMO0 z`bx6MP)ggXMm8wJkh6saL%LL`Ekc_$EAgA}(HgjM0?;Ao%5-lP9OVB*eCGv;lgpc4 z+TSS-6nNmV(6&l0(gkxL@3LU<$#}k*zCG=YaHi)Q@g=5@ua|pX6n0H-p3GCw+?1rh z|JFVH7iQE)op3|*erhL|9pS8;K*vT*f>4^rvFBfxu9$gdv}HWaTz;w|E^t90ojmYG zpdD|dS)m<ru5r6jxZ^56JdOD(i%dM%35!Ja*i>_StRE?$V+3i9bBp3?FvMf%EUqFI%_j>h+P<}`Gzw0lV8hZ#^JGpn=_7=QMFhrlS>_(Pxr zk-&NT4n^8B2A&vjv~p|`T(Kgs)bn{?hfxD{=fSDSq1PVX)bT?Rd6;wa&vORX;Vxa4 zJpp)3as%WCEscZ5w8HlBs8?XjdJylkoKJX$U@nxy;(+KON+JYJfH)Y3m&q}iDZ6o#2TB(KeHoh@!Md-xEOo$K4gZJaXiF_JodM`K z1+TD5Q0(`Z-pGyCu)y(_&Ib7@rYd#WEiO%}u`< zC%Nyllor#{C}_SApM|51Cdr~X&Qq!XE0J_r`B&|Kc=U?MN(|HRl~^4*L{CUXYIpFA z{cybqj^;uNofXq7e{j9sjr7ltVhtg{o8Y`;5Hp!@gX1QZ))2(TT{-S9w52jmrkU!E z4z#;vMvFV0h~)LP38xNr(9+6PTEqP%I{DY;eFE6Jg{V zJ;f~^e&t4BNtgjCSu8z>o#Jnqo_NL$@@)eJJiY3@!15EHLYTPb90k{ArE@otE>B=$ zq5xuqs6%SJjE9CwdreHx^vx$2pQO_MgvfU$=l7g3>i2-8N)of6VORIB2aY?CAW;?A zba+U*_An@V2Edght?#5GO3rQ3dVNo0q!^h5pJX{%;SKQFCnHK_(g8>uNU$h#f85^z zaU&cblok%6vb*e!(%byuX;dz!BG`f?>sFk_vdfGnfT4QX6Z= z9c{Je^4_@Okrxgxh07!g-k%^c zzY(^mVWMt&{*eeU-|@=T5K!dsN+th~5sf!1=)yjX>f=-i_d9=TGe*8D zbZS15XRCP3=@eDq(nKsDr=uqQ%t+4TVc{K0+RreM=SN8DF=S*mBtF>@un|KAFkaq< z#GG2A6@$8HXeHWc<4M33Ai68U!<8=b7qZlY&dm6N0DV!gYCusYGV5daxpfoJRny#y z>YR^}#fHf$n;#0-R7(2Td9@Fn$(Mh1rfwGn#k<+R8OFY zo*qaNwJxf7Q~KV-GjIx~KU=g;%N#<7;X^o&Y-;DgaO^Wty*|KWh{xkTF5@l_?{5C@ z!j=<~e=Y0)dS;Y>m?dDOL zA+-h->-srlycTUU(--6gNO|0vZikw#FN%23=ZLqQU8m*xBQAS?%#H=DTZdKp<(ET zA*CHUq@+`akX8|-lo+~kKqMp_LK+-GS{*t?FbD-4N)T%h5fPO=_x;;@?X~}ay`J@~ zz29E1zb~$Je$MkaENV^h;7Br{ZOq8=)nFcQrVd#RXi-x|tYXPjc=d$BI*M%_jhE&46HZbne_<0{<|Uv_enJ*8=F8g{e~ zeY{^I6J&rv62YfUYy`jwE8Q!mfg~E(Pt?+3%owxJ?uihA^Pg&Xj3MxO_*FFglm@P4 z3-(7*9m)w)&aJ$`8WkMnbQdHBZU|GY(qyfU&8#9eI3USgpnkEiO@?T|1}M8fI_AYl zYq*6EbVgf7_$^`ey3Y_}u>eGA8j2 zsu4|&EI?{}n2{>r-vB^0%$>TK;KP+R7L?-sS5Sca=F3o<*FMT zUgwlmBzGV>&-ezjeL+&hu|C;e0cBE&{iybBk|_Z=yU=Hs0;lUOY3XA+ z*e=F*{7KN}6Jtj~Vq#~_Ltx|gl8A#dhHkZ+ULXWtbm;M%&K`= zOREnO6o+~a8G8Cgj#hl&RsjwYOAM%9q8cga-}BEM6o;+;R{IWCFgO=gnl{S zw|lo(1zw(CU0_W2M6m|HOo>R>n5P@+R>}Yy9VhI5Ca8A6K)`~?Rro^;b z+nMnkaN6Lga^M+wS@xx{{4C?ds2{^TTklJ`ID~>#QyjKf$y=q!9+|DLLm&Fef@#dT zVqs|XO~mIOrXXR}YQQ{h)@oqX)ClR0SQPm?$Jo>A>qUKy^DUAABkFG)I8a3iZr7AZ#)~_;jnEidX zY0iJeIpU=?;~VfrE8uCj;8(6_j&&cxkZRrlV`VOFB^6yOSemhJeCZLdb;P&58H|qw zYJF>+iG^bb4vn~nBre!oY9G7!-X^c-x)o2A&XUdCYrCfbCGI;;PuFxWy}Qbf*zJJL z7c4AY*kXA4ynS)*O5S_A;jH%i+pnH%zkA~=c@-Q>*iw>u6E3)1lhqC2!8Yvjsu53E z^v>35C;~S{F5@nJxOk1|oA^3SaJ8n=sfouoch2yE#BRPGtybUGN2!sE9Bj^5oiDiq z6kLx80!RZ1wxH3H6)@kYAIjuNzDl67yv?cAFdLGx-wj};)h?3Y|C;|(gU^-hO;t4& z{^8DLG#2Dey-bIGW#a($*5M96n$_%)uJiCat1l$bTQ>18)E5R0e~%isP062AJa-os zI%nvC`|@`ER>ngX zO>*DO7yK6=rlvA_%p<&q^Y5}sP!3Ytub?@c*f>-IEJyBGFwiB^>LXsVvoG$`31l%< z4*ZwFVZkhji!u77Px9ZuoM)#AgYuYlemWC1X_w&dy&0C8l2*#>TMCRM8SzNlL1_`r zX^b#;IZ_Eebz}H$ssuN;4)>^eA>6mugE7Zow$$_L2lPj|S1J72d4DzLcimpUSb3W2 zW6|IBv4%p@hqW?+nOWUi1T|_K>X+VSi>cWEIu>>F$4v;1zsB3QZVfRAxF`%FUAbdT zlq%z=m6Rq6xM8K1KhaJi-J+>xpG%MY7ZBFXm!GYFeD&r7h)k{`W1ua<%3JFXbcZ4# z-f=fqaif1DOK_5I^Y@@$<^^7*xv+<;+dNA+C#CpofqWIYxJB?jBHHJ9tnC^_Abr zJnt)%7p3+HA9U{d1ZWVj`Vx}#9~<X^!RfZeD6BDpjlZo$QrM8s#%*_I?_e<_3xlO zD0^M6Uj`0`xLst(q%rbvS)s2i*UA!T%$tJsF%Za!VDyj2wuW#L9?a5qfKLSxOu$KC zP|n3&#Gx!1MU?u&T)IhFE$;lIzpAPO*#?o#w$e#KdCUMI_;ar3S`Z z)u%IkdyCWQjBy?t3X(z>@Ww(Sp%+_pJZMc0M7E@Fa^7Qiqb0<>A%uqOrb*0DUhbci z*2KEc&+m<&>I!?&W_|XTf2!?#0UD)Q^>7i2lmd$3u?{Iov?7!Zefp@Y3vJ?KD+a5E z$Y{*xg*Z3Bpv{>F|DeeEn!k&88hxtZtDNFAN|i<}B9SUY5OAd(5a*V^rth)%cuZt& z*spBNm^kb;E6{EJk*)kIpYZklT*&(sGAfx)RrjE_%gCT#d^1aS^%upg@h9;KD)w58 zvgV{;hPWO-?(Dj6hunF|9^@riR4BZS{5KI^`DUI~m_Zi&r0aTeGF-wpca~-F&~z6X z`La{v;MX&Vb!UDVCFLl83UmTJKHr=Ou)k6+))}1LJp6)(5CQH8pU1c3ADe< zKQNu(LD13;!3t^v)aQy}^vQ({P4a>qAcaZ<+hpGye7qjNuqjNxZP7c4w z!GX_2=NB9RY$Ce*fOV^iU%4(iMY%2`vAC<8KhuT(d;ar~03Y{vV3P7vtg(-h2btB# zwsL;;dVV$(-WRIQL4|#QtS1e{`T#Tiq&WZ{df6%rmH12;f(c^W8RrI_cg5Qw^l&R- zdg^7EZdRxsktA%M*z%gpRy=-zo9jCzkzJJpa?StH&Dh>4Bqen}G`2toWG3b^>5a6I zNl9u@?Nxt^M~Fmw1c=4Vg@65K!#|nKW)_;n5=(+P{JJdFxG{AfEqXrhmwug5Q+3`~ zm9)D}9E%14v!)9l*_3Ui)UU1Bnyl{yvK|>gWP%p5{TymU21%f82mHy-F5C!pHq2gN zk*QJfqtRx}MI$D2a^baVv2rd8m&^(-@@H4QLg)}Xj=tXl&&d;H5JX#GAuY1HQDd9? zNu2M7p^!)7B`1e%$9CF8&&UH8pm!KrxRLaTcd?pVpt-vx!pU4mzc$1+@S$?5Sf87E znmc&eGdRYe`Rlz$wkMz3<;dqvb*hNzR##nAWW<;}0BCM%jhpy8ClR^%(qfqBx9Yd@ zr)DH@w5OES`Q~B1+`DRsj9lf3thcY-en97qLtG|!-F=`#z#A)^S)i<|I&H+Qtmjwp z4bsB2uIBgOdYKq@ppv(yA-1=~ul?(w7p0xVfQ^o(0xM1(_kMG=yn5KCbf$oNVH#50 z%^LKHT>+h#PwO)Hhvy3s|bNjqzDi%q~TO;`iJ`y$vF`K;e#9&Qp;&IHX z`w;ggF;TCWG`x~pc%SyrX5lJ0(tX}ttH*0juIAMf0tna2j0l*>S{d^dJWOz%{a`&% zMQa?ITxxpN?~R0d+qrE)i#F1(-X|<0ap#4yB|cRyL`4J9zIC#Fc;>9F`gWm@dh7jg z1NNs|6=Y+3BV0D?qoww{KF_hPgnB0OgG=gf$l8|B-}AeA6C0Ptp?J95u)1DttB4MM z;xj64M;1KLJ1qDU8H?L&Qi>WYi;t|6eTxg&J*@_{{m@gY+oxRdVqROv@Ri>xqvoao z_U5@k>&dEN{ikbVJE$BHF3_r5PX9EsA!pP4W?OK$%R!G-KR&T#cPw4Od9U5CIAjqfdh&Vf)beUPy$V#Ek8UIc2b`pPPx+g*lC2zN_-*d;z1I+ z!GIVgr-KHu;$fc)I3Me4 zJ)lrD&1StFFd5^|33erZTo}kt?IE0nj6|cNs(f)tj_E&d~Ok@}SLhQ%~L&1D~QGkwk!6iuJ(; z`*MEL{-}cD9ALH6#Sh)6v!0nZaXr9K?}X=p*27p`c9-iD>EXiW{(YhQ3(oKKK zeMH_KZ3r)1Q-pxX%BNo=0?dG?1tM2|1Go}FSGa|f+;Qvr0D4)U5Q?GkUd9%BU+Vnj zB6kH)BjdmA1P^fM@73nnc!5-j8S;r>?Fg`dxquYf>K-CnmBTsUm&s*)D4o(RL0fRR zE!fGpE_HWB>hjd>^Yw_ZooadxqP^HWAlS$KaPp3DDCTl^ zA&s$^nu)N1VL%3OCaAmN7Tha#h5+Z^!=hcO=ppv;5|A&z8&X-{CaEhWp@>B7_Z=Cqq!PJPN z09u-V60pB~#gz;Z`@vuhcvha2GN6kIhIDirEF$^0d1#Fm%u#j6tS`frZcRD$t~kL= zBw4W_9@LGYlkjumnd<~#fJo10UU_D1&lUDtW~?cO!!1W<5L%P$SmIzO9d!;g`wc@f5y0;v9&=KV9G@nGQll$(Nb2wT9MYYON-!@}hRSzRr~Po4=C5m6}25WuLbV z1$2#0Vqo3x?%$|-!Yq0z4CAZs?9BPpwJsFB)d=sXue;we9n^H2zCnsLxX8ya!05~o z2`}%k&|#lCAB$-*1+psonhi2)VK*?Tg&+}I&atNIs{WSGZ`rDjY1jUS znx%c)yL7zyujs_0z+Cigb?6j@)T^rcGFoH6>Tq2bO`ZwY4?KXYd5#w z-OdI`AniARCRR((sf$~Su`G*D7G2eVg-a0tiF{%E+dXQbS`t{02>L7sa-ky68}MI% zueh}?{(j78--`wVqVv{F7&HHTm^4a)ywA-WgkW?Mfum|~WP_>T`?&O$D89~^+gidk zK*)6Srdz~l5ZHuWCq28Dq4Uv2rS9^NP@m9qJ_rHu4E=pK2Z2}jNBc93Wx>O|sP#@T zf%kFkyO!wyi(xkUXT&?%5gn`qpqx{*U3Orat^2+I!2Ay2VJlRQ7j~zlfj5CrLHQIJ47(46C3WpnrUObMfE3BeoZsFsZH zteU>UpbHlSmI1~UT$R#+RKGog66`kJ=aH0-b{3h@3QhY%VTi6be_a=>{w0G%%~&Kl zM+Cue(USj~LD!vq1LhlATq^@5K_j{x_d&`*(OVJ*Wff!QA=IQe#+nk9>#Oxow$E4X(B63*ynpRlN#RJ|`62g7{#q7%T zN;@O{LVuT0DLHl?W7<06)R@;iGo+&Jf&vRtQ)49>YPT`zNS5>x$yTNBIJ@wnT~E@g z1wGFoqAMZxmop-eA=qLbwl*U7Bzj-7+b{+!N=bcBGUe!zyj^`Q7CJSOM%6S3NhyH@ zNuw8@(4&RZr$dDUD_*knzjVws9`F_1i9G|e{y{5zU+Nm@{q#ySql!CZZE>)v5j!N# zs6?aABSaIol)U+JqGLYq!irz%$}(OGjXlSP?#$2?0DBahTG7%2bu4cs9pqPJjI1BK zH_n=Xwpv!+M=@<@vq=yD3xT)#fw1uXl_0CdABdHfR=KY1H?!(fT~AgWcR=3D;yviT z^e3-t@hs0t2&W5jOdhx~`O=u&6)gjhP6Rjx{ciRz`fvdrV1;x>NW8L|d`bq@USTMs zh|@h@YZ7Q)%XL)QVe&0oRgPQVl^+^Q6E+1P9KY5F+;W_4hcc9Cx_s9Kj8;#dkT8s( z&FAxM3go1#Q$0;|%w9522xPbNGX-g&-~WczC1o0i*cU9*Yn*x3jTc$?iA!!zHuwdF zGOO3e_7Utz;G@YV38yed+s|y>!ZX}6DACO!xP^?L$>H;?SRrY~3udzMjb%--t1H(K z$C^9Ff|Fl)CnA*$(-5XRZMn+LU$&L?Zv4$<;ydx^@Z90o(!+;l zb1qkc?hGw|$>&*z51VdBmm--y=Iu*TSa_d}~5%%>@K`QK# zGU}qM5r6lIf}aNdynpfL3;@M{g6L_Z;j;A&1D<~#Oi#YvWWN0S zD^nxua(><0W5VaN$}8iYyZ{*xqj+rRexyQOLV~B_H4iDO0xBu$<$w=sS zTG-K@LOAL5b;+pXvxjHUr@KH5U@i*$w7Byl|CYk$wV(N!KXcTaWnd1hJPyg4K0)ZZIKD<4~vufJZr z9DVt;JKxY0mo4?%CI4@`b|dVcgeGkq?jmE?&1r|9vI& z_wV8#sfkj_V`~o7QH{_atv<@=gL3`%00;U<>0gfgZ@}Bjr^v_0ao>&;5{~#$96!Dt zabS+y-~U^H(F!F=rbr4gi+b=N5DEWv6#qY=$q6|*9uMp4>kuByDM>;p%=}FaU5~pT z17}U5F-(tIQ(KvssB#NYetr*NW+rELre}J#X4ZpWbb$E@sqJYBlW1<$|C!j9*E|Fk zrkh)nCCT&Oj=K;5KZo^tsu&}aN}8pcS}bj#Zl`)uQn$fctiWb<+kdIa1>ql<-*>Pw zZJ%VR$$F`JG8Y2L8t4^+yJ%g7fe#q(9w*-aP?OmO)NUW6La|o@E^ung_t-#wcXW1pU>F&WS(JWBB^y#+xLtqm*|4eWax&p@ zZZ1)3E9VYs`M!2iq6As?NUV4BPIpd+aE>aHZc`+|IIZUVlJO7FjR}5eZPt7MEfs|1 z7l=yY%nQi1Pc|B56FJORzY^y74_=3J>n;^cI(h!^oxL^qm7U%1v+_(og|pHnE6!^) zyaL5-`jk>(NtB&E#_Hc;B0C~)ytLBk1fJ+^#VfK`M>SQw@R%`+HV|~_>sfX>T;{oV z!OxDD$;pEji7ycd3kvp2N#eB;=GdNcXc>&&@@*2+;d!I=miV zy`W0rCo)FU3YOJDo1r5d$suWWU;Ve#hW5GLa$a^1I2Sy)FBa7OXurU;XZ`zlZu^Ab z-5gbZUHdj^@Hv$=HD)zJ3NeCh^Xo{@$#N-VjIF@5ymzmFay~bH;1L^>hJH@(@~>=5 z{fFf(%F4^OcvC^8KJtG5%WAAWC@xRnN+5mNW-N2pR zGp`mi(Ly;dHXrhHU$S;CcM@U!@Z|F)R+(aL>`R~HLa_Tt*heM9Hp;MHl&IybB42V# zTFv~|!J8h|DqwWBV(^88^7_G!=@Vb_-{a7%!#}^YQXjo|9N~W6dk8kNB2vCR@t(b$ zKg8WOC*|Ej;4FA`{HGZMmfar3O`GYL%0mIpoX5Ax zYm979>2KMJzLGUMQjHd+6Qm?dS;Ap5KS8da^HLD1UiAJAd7}%W3Z6+`2EJw^g7-zE zm`Vzn6KKv0@!sGMubB`D(=htiJA(bAUCnVmf0Rb9J@Y&SCm^9Qrf{t~i+@N2%DO$K z90a~-G0)6CR?;qY{~-5Xg8|NCa(ph7H7`2FsQr>s(%I`9`qyS_Pzg7bF8@7noTaZt z9rQk?(W2m?16v{o875i=%2HY7+kEFuLFX@h7btjL%i}m)!xe9rP|9(I>rq6KUS-Fn zMu#1agawjXymDbjxrnUi$+UVUy4dqiD!bc}`Df5!uKJmdK8?)^tCZkjZf)%Z?d{Sk z7rj^Miq&P(EOcX+FCAvYgDd2{mS>OSUgdb0RVxdvj9#mJm7}x#7G5_s?uR_6xCA9D zeweZbUxOF_QWX(pe%KoygwFvTZA#GwDJ5^RRM9y~iF*6AU;WK)vzQaW!a8cphOe!V ze<{UJ#UttCM)16|V@P8yJ7_Kn1DZ}YPW)kXrKRwpyr&6`b#encw_iE3$wVPEYoguP zSnvrQ-1az`v--n*v?PaH9O)&u!BS4|Y2S2w{-BrX(j;)C zua&NWiMHYkwoWhxeVW}u1l^EIC?C3Wn^iHwvBBVMKcGmfuZZ7*(1(XQUa#B>1r;%3cTWo#BC2#%ZxRu&=vF4||iYdpJQV`;OPzr0v;OTX6>q|w}6{!s1| z4X&wgMtD5?kz4N*;)JbrM*^^oGmhQQq!05eGNw<&TQwPj2X;$De+wEHzQWmD3O5Ls z%VHVfnF)JZmnyz6q{FUuF}_l10Q`ik&;I*Kn%>Qu$1QtgyVeD%SX`|TiOa;_`X#=5 zwDz1pk?H08uQoiBwA8JFEN+jz3Xy%>STm5~l>L^!Ng=}7mZ{yvM(cH3q?%?(Yf$C9 zo7>=1wYKoJAY16WMXejSfjp)lC-$=C3T!0NU+Suz|L?cUbKTuN&%a!|efo~f+|xT@ z^);;Qbal_Vr+?}B*U0}EhVyy`cdfo{-FkPr{%fx1>GAV#@u#Qn0hV4WC61EB_lHbt z(>u&HM@iHEvw^tNJ1S{?kmdeollw*Q__?`*yxV`aP%M3urqy1_%IppsxR4Gx7g<&4kPU zE1C(}MBqP(wctaP37yMxYu4jxYasyFZ3co zSKG{2$y{x;-autS!udgN7BBN z{N9?ER>*oVI{7{G_w6dez{%bKht2t)eLY9S!lo~Cx^C{W+XVi|Q|5KdR62{~%eyWw zo@U+tNii?au-T0J&Ayu|>96N~bA~Z6kn3*5(9Iv*KIT)40`BY^>R{MbX?o?Yqp9Nc z7zK)4^ zSiBn6A6K{K8tr=T-C6S1iP;97g$BvPX5p`~a}LLIvkSQmJKV)CRl0k)yN8bLm01(4 zC*>}IN*~1CGhv((cl9b8smh2hvx`1=;%XntibR~$c|@l!ZKWJe9S^1bY5n+tfPZ?= zGnzw#U{pPk3xIINOt6wm;(uMUOwkd%fe$=#&=S?h`kDR-_>JiO7WXgGAK=pJ7!cgt zZ(Jg{`j)btV~0Ws2mGEoelJd_cIEQTE)(tMR_58LB*-o0J%8f;5@cDI`N1Camj7lH ze>nfD#FzeswA2>%L(MAbtCv!zuZj!Ch|61Vw7%V^+x;ymFaYhjz;Wl7CaF2fGv?+a zF^(11cailSuOFRtoY8o=4)I5=zNEFr&ttOlrjU|WEay7d#yEw_;p4MGa{d#lQH;y9 zOn5?QyBVmgLl}EdF8Yik=Uq@|Or3VB>YH;9t-4$ngOJ%Ti`oi(I`K3R62M@1g#@>5vUn+BW ztob1B2l;`O{uw04kk`kd_I3>V_~TS?^e;*$1L+qh!;Xp(x2KWrg{FU>bUqz0pn9{q z+fLQQE?>XJ+gy$Tb<$B1zcg|5#&hQ1Y4~>2gOBGuYEs_}L^}8W_RIlCM+Z}UCghE` zlOX@{5YiwE@^$9^2(m+YN;fxndB1`oYFU8R3>`eLM8*^>RoofMfeHm+X=5h!t49$Y zKlwHgeGYu2+E4>}2#UQYfSdN0Nj5+G=6SStvCQVI0Z_)pwdBGrq$TVrSX01#0xD9D z4~*ZN+M*wt9M_Y1XcwAOlik9F*ZPTPkpBFZQnWYm>m=0Q>y&w#eg(zuCw_f;xcW8k zlzEXE{w&|Pu-2-;SBrj|_51_Km5bm}^XDKOWV*d}!iWyf6-blHWlXX(gvZelY@*$S4sC<)g)c7&C@gIY_YJq)x1n{$ktYM}74Z(S-eNK>Kckp^rZB zKgJ4T(tnH<&^>(?S`?1fL%#$H+m(&FtNH#SKF>FY0m{K^wQOQHZ<_?ktRcK=<}!GY@Mx{}oo%Uui1NK-gZEa%B(7O9jqEQ{z+3#;eMINTyu7_&NVXzO zZu=!a2m?~ZfFT<1-m{rH1Mm_YkIDAhcdcJz=)CqEAK96UzSsJI`9!EGMQhM~gJxWDBDGH%GY$4rx%US6M%D8^5J8$Q@maw4Zz($G4B z*fJ8W4zjk(WlE=L$CdA$rJDRvZPsX8LuCG(-QARP(cQdvBf9LUX@R&@o7|FK(z21ymU%iIQ`IDB%6uuwkcM04qK?DAc5 zbeEwp+|cEASttG5kHZ23`p?@-defqCak+32vlwKzt=99&_M^|ZM~)3&KV6!(-(e*N z!fx99T=&uZVu8f5(2zcE_#eSkD4#y;D3GQplc0?1Fi01W3_`OD{f(qkvn4XH1LN~b0A*L~nmdt+WdK~+xwN3tM+0x&3{j)z!z07`8q z2t=8BYp~QpIi#GS@2>zl8j-JmCQI4^C;-gr;;jon*#YqNao-LX{|if4i_mNy5&oSd zY?otD?y#ZUjj)BK3@VNoObT&+=*!uQr9l8n+-dRb5dp0B;o=}o{8e*wz^H|u9>cGaM1UjDSYpK@cv0e3rM)?wE2pRz3sWXc znh>T<8>ttVPm6|Hop_7cW-1fY7+8-~23E)$jL{3`}1O)}-0L2wJ z_DxJ288TCMS%=Q^LRu6vDF$vQ@B;^aQxfgXb3Dq&=fz z%ZoL}0F;?0a;Lxmn}c>PVkN?^np+wvfj+@YB~0+DAAq_yD#kG^KA}MGxvYfDE1#8u z?CS&z(-W&7f@M)4MS?Sw1cjg>h0?$kO<;>FTtT{=69Eb-jeS}O(?bCkCC(Rlg09yZ zOD4yCC0KbP61UR7;8K|b-+J(qGdGF=IXG(dsCB?hl!buDP-Uh+~Bhnw^4?@qND(G-{=ylUjVCG5= z22oXI60@)ZQAB}MP>B$7&6!!be`%2-SEQIlwWLfb)!863ZI1Y_?;(JvMp@>TK%GE= zQS#?d=%{Ov-$|G<987Qt<)W>7Fa}i{OM~F*Mly>GP*B?WuprlJoZCa4)Q7WypxEDK zXLNPulsZZ8`<`}nccCn%_@bc3I!+Q`h`aIuSs!-a(UMrR1&>rjK*prY<8C$la4r8~ z{_y8YJsTeEx^HT90~Y8Ck|CB=ye&fkh49iK7ZH}Ay#h@cD2**ln%l?N7CKzqJZcJ% zG_z{lit27P#ocehSyX@f*tE{!&~OeUAyYj&eRgq4s;V=JJK48xHxw#^EmfQcPwZpA zYCz3_wvGGFFU3J{L=!Ed^(Rl0ziVrP*26=(@X^w$SVVJN*8>UiqkpB%CR(6t5rSd} z-_XrVUon9}nt(B-Ev6PLMhUyZ12K1bq_I;5$JMs+w0{5is6po8kCQM3NvgHxq8PV> z1{q{7(*#F*_f113ur&B6ur)q&CBpg>CUC1byxS$>{Rs#|uKvD4-1wd79q5}4PZ*o( z0Ax!Y@3n(*(Ch!PP;{y{(|GbmBE|22l?2@J=2x8JI+YARg+ecoE12r!_{|@1MuWxr zYom6EPgk6^o4^t>k&5>pAJIL8XrEQ9e1gEKbqk8E-JbTjvQDfdph9Y4`P6-7M8#6L zXBP)cD!I3JkSiZpUV2~1n9^ZN0S5)gBx<|46Ysz& z5puZ_Db2FCX(FbIhoL-An?`Wn<}QPtkrGYn3}EuJ|0)s!!(Y8Ymf+$3Wa4%B!6 zE9HzFUZls-A{ZhG@$1p|sd`RZM+H3A7z=I-j)9VZ@hI3~Ha<5WT$}Hm+8TGeMf))nFcx5&m)&)%HPV4HQk5OEdsKWSa>*~VupL<6FPP@W2ixT=-pEr*^*LV*=C!RcehGXLIbY+9g7kR|4uo)1ds!#ER7X$$pLdsE@e~4M zxBObT+9j0-z}hf6aBTmREz{@8{0~5$APfN0zdi4=Q${tic%M278*#*uLbiH`e*|W6TpAnHe_+MtL!b9MP*;5CPacSJ@gsn{qp_ca!n|U;HSf^; z3PgesKYOwIJ7^F`DI;t?#Fxdlfp4pRi2dNZ!M4-Dn+#RuZ-#!7%E~`REAG7wyJCJ8 zu0*Ng4yr~v;_vlbMD0NstQNk!xgZEYM5SI|Pl70;yuJJb8yR0PI6?EvG)!a}pMWon zKrnh;IZul~NDM@l09L^j1->N&PZK@jps_N_duCuc3fK&@vL3SH&JjYzYo=L3kU&pa z_yU}KKbYpl-DSWL3s%O=c80M|5Y8KW1$eYOBtM7opuj$8>i)Dt4@Y<$_wKOtUAk5I zX@5JtAHYtaVO%pCggV+CMeg5%zT;gowrY%sTlxd5a-4vgQC1Bq-ae&>bS1v5UTXFN z#R&qIA3Y)OUaw!T2b-a)Gg|AE5F_tl%jJKyG;oD7>FM4lAzD`5KN-#dBx(3`dg1Cg z*y^?jMiOvEZK*-nmNxpFas{JYdGmiRdf=!sE{HpRU4mGXwz_`m_f9qx3QEU*1ephO zAir;y2e|~^?Z0S1hNRG+uWSYH2m5MP-oW_Rg7b*3BTLUvg)*GCXXSKAPFBVf5KBQo znE+6!r_O}+PjP@6^=Bzon5kJLHU6~NR1snk6CR?UvVyFKZz>Qj&JM@Q!bd>Ynz z7|$%I*H8?jS+AdJ?yl{_2JI%!-Ga?OQQXsF@O9xnrIu{OB^}s{d3#4^JymR>Uj~fJt&V7uQ%T1bK@yW z?H|;{Ih~%W+V})6+x2(yN2jm@+s_~%W&A<_Lj|O7>q>>aB?bH}<~p@NIr&9(&{O7uuyx}^J@sx z9R77s48n$4>X#e}Vey>&x)(LV=1%y)n_G7wlC->*|8DzT-@a+{9|YD7$W)bPih%7 z{UeqMfc-s}kNRDy>RjF``&Z&DOr;*Ij)h!L-=l7^dlY|Ro_v1`{?khNZp?9;jh>d- z#t2%4g`3;I~P??OdO39CmF;*u=A?0Ob z{=f`-Q4UxZzq`3P9S3BNM2CQ1#i>CJXix~0e*M^khW?B8!d}_5{JoJeo3)Rq7V00r zIH?VOaymN)O~LA|02B;P-+HNHTkHibb5B7*d9*LhygisX;Iml|{I000ZNpB`JbOCp zWl=S$@t53mC`B0zJL0geGgyg3$aaX_x?|6n@=IeL4zo+55V8bySt=_s04W#Ue1FBu zZ50SDZrR0`XPGotUesMR3f%;W-AiQFAYnz<`oXbK#EIKQ(Py}!m&okTkW69BuzoYD zw$A#iS}PMCMec}!LL7cgiX>0?Cs&!zT&K7B!bVtcuas zAf<4GaZrPuPgo?4#5bMK1Y)wqK32KN_ zizPuv0R$33B=z!C<)tepGU}hO4#x~UHUO6Q{l_?4Am`D#! ziQ$(QwmMo3_xLl`2&uG&2Q}PP#g0Q;mD4W8?2XOm0vm5QMu5z*Xd{nTS{e8Ap53F=;)0>-4>cGr!v?;KUdF^%+CiE z{;V_*Yx|QdY|i$8UJaJtqzTA5Qid~@O-Fd&&ihNEKra-OWIFf8E$$lVGvSHV>(X^T z;9nJ*5Gd;z?H~rONV?VJ3WUne!9-`J9;JDX%sR_Kpost9FnTxSBgyaOCP4Vg!<9!pH%=l)OvoHBv!w@&f1SNI>L?X|d8C-udPSgKF4QDuZ6zGZnV2Pi5oarj_@w^Th#6^J*%Nt>ePYi~idLQ&9 z#b2YX3J1fG{qxD1Kd=tkVj^@B#2eC5A}(4adTOvb=z@YtmjE&QsyP400h~4|4B2^T zuCV?txFRJH=5dl2rIq^N-^JCS4(}HeH-ur%B_wDY0br#B{2x@EWmuE{`~L5BP#ZBC zMmG+m%TW>{3{+YiDJbG-M8J)1N4J24q>eJMMu(t7K>>@9@*|3h2-bf4{-6Dy?%0DJ z_whdNy|42+&-0}M*%~@xH(Ku4KPxnWLM?RfR)cP5IB+{-;E+6q)xR6z!y7UZ=`!?&fp`LKCFoqu>Ay#Y=$m zaVOiS|78bC>E5v9KUt3~Zx0RBAG`MqGyuibErz|LwL4M#B!MLm+GJ-=omy}djX8hB z<@`w`9wuBvAHcd2?LySoV`5Z8^z#W%`}KI5&F+G6l&=!TJEx?-dN(+V4!#&D3~0yQ zrNVEw)9@cSR19K}RvR(5G+_GbC~5H0RhglI%sX_RG-bKAU%Z+fu5esAkte?nEc!Mt zWYv7l)*%_`+%kz6EppCv=`Z@mO>H7;hn4%`X^f|3D$hm`j<1mO_6b13%L@qFMJ!c< zGyv0FT8(mlPLR00f0Zgx@L(P0e6yL%CEy-_@*KDj>jf|d_Hp8E0&Zi&AZ@^ad+ zpPoBd8AZU<#uvC!gf5MB4sB79anU2C) z_0gXV9PXZXXNR_P{@n+>jas{)6ewKX({;;U#2z};vm}IT zV@&>%Lt`E43e>-y7%Bc4>M`R7){r~X*Lk`!>3tEGqX-;rn$+{_=u@qP}+sR)x5qu*m)3`}}Ir+$pQygYsLryBI;*p#RQlFF~$%)wiD z=l3>VOf+{Y_6c{J0_3A+4aPE3x4#~L<=YwVofw#6mf7lY$p9QBxuagk3Zkxj&Y&#DOw}%U==Lo%vjFa z-5S?PF>o4qHUr>hB|L+lSYJB(agdioXt-At{J};hw#)GoA^tyvO7k80F9_8_7Jy$* z%4e#K1fafMzakfd%%i{*F;I3H04I8Dt_VB|{}5d+c3zn_<+dAsef&6m29zq67OK%no#7->d)ge~$9 z0nE@p;&MIZZ7h;=eNv-C?%lX-P6l5H3^t>s8g>bo5g^rw3km|lhSxPbcASrRyYll)33hl0wF7k5n2csT+umFsGHJ1^`PtKe&NX^Ss=h}mu>ud#L;<4sqBcNgm{x{U0yPDv-2*_%OoS8@k+M~O zqvVw598#3Uwcm7RT+UozsnCRYNS0LDJb`Gjt0=f#g4!zaCW5@y3B0XBh_6B~mvzyB z1x?n+a)d#5g;QmiZ0^^zOIG0tr^m4F@{x1JaD=deF!@OYMCvqcpf;(#ynd<}SW zY%$EA4t^zocJ~A65{@n+d<-cdLo#@?4AfW%l7WIm85Pu?61SHnFMlL4c5@tejuwM0 zP2?2%WxTeu(HqQy{;|v8V7-kU@R)~iyhoM}KPYh_0f1${yi4=^nU-IH^lD0M-8+q^ z0FCpA25o_KKY!UCQkL2@wF)at|V%>>b6suqMvf z*OVq9#EFkH2xB9p0m;<~lX~yYHGX_6O%5$Z3B^-D_g^*NKMP#^WnovJ9No{S(GUXh zy#mcZ{S);wV8E)hVo@J+3*z!J;=Q5FP_UIK?kjdAx`?|@%8PZutPrM1X}!<}3Ks?8 z7#yDjdYue70WFPaum^y{ucH=v+E_vapY?c#4h}MS*vhDN)t_btfEO!)a1Zo@#rFAe zsC50MkHJ`OQqdf$Y5yZ+V$r~Tv%1kUR{Pf>>0y*MF&i1rh|&iUSb#@8yKSY-chEh8 z-3qmu%-BRLboXoa2p(VGVT5l%z@%Gy=%&9$TG5y4&6jV9i!l6|kY?c`b+KFJ@v*p| zP6V|bQw4B(U+5Cbfg_*DV}}$i5(#@0f37B{)Jbgmy3(sbEC@~G~^oPv<_61;4q*V@!l{1 zroy)*+l$~`dstmEAMZtCq^kH_kMJkQCzgetVj zKp)p8+Fg+MR0YoxON+mbHxpBY-M!9g=R9J_W7Hj$mjI{*z^V@jB-|JKUD<7XfBkpA zB^+>L6etpW^j7W#78eer{nl-MKG3P(FH8nrq|z=UOw?9F z$6vP-qAz)ar9?6X)Yggz(SlR!brWX=?2CD{28?axq4CL3e`dUC@Nn(xW*K~&`7xLq z7Cvyv{&?P`;wM8wk?s+7_Y$5ZC!liAgLgabM4?%3imaO({bSsG$YtmUE`=ew_fQ%vOvZy>W{2?e79Bt`Vf#eHYk!%7OMWO;OrElSqV)b zK6@JfEcz#u#{{Lx%2i}Y$r5drCtv6b9X{t=ddLbi*+0%6P_Z&KuNZu4^NBB z#3W9>Cd@n;D?gDqNEc@;-yq{4ZbK-Z(}LiEipOn$96LqtuK&y6NG+rAxcC7sDL^?v zqBl8IQh2*B-EaGm=L*nNy%R5R-X9{EESH z9urb}7EBa>_)ux#d6AVNzjj$(`hvcTYBWzt{haZPBq|udn~8eM4!wQzPEnHQUW1Zx zy-3xs=dg4z-^TKWzCF!CwbhP%W|N06F`Up7nu*E^ zLCy+b)7*)-D!v1L1J42FnAaCOFI$@wy>iL&6Vz8UkxJ6mw;n!HE}xWZ_}U_FqP%P3 zhU9zIzmi}NHjf^eD|?qWt>O&4j$hsP%T!A{0uM2s^lsxcZha1shS$Cfj2LOL4B4_g zFN(gMCYaCyBjMozx4-TswLZNI*1f6EHdf3<-G(8BKP6Bv7p5X^y+7c6IrROq?wAPn zDz@N5HIA+fb0r|ZTQncGU3~X-3|A@nQBJpHiM(~x(Q$s_LRCa*=?QJ*pY&5LfoF&n zXBH60GZHd&&0s;=RlveyiUG+ogn^2j{0rPYLSf29SrTm2~rv3~EXr@<|p$)|iXZ3p>Z?nif*Fa^2= z6NqNupw&-5ACPZcd08SyOlo?PBuF$)7D z?StTWMTCta9&Tv$zt*yX!UCt0n$qRcN)^>L<@V)DO7a?(&31Okw)Tz=$YCL*5Lk%2 z3vAJ?)nn1ak0q!m3e$^53&h}Ns#*_)gdi4*9s+X$cmYK>Z4(JO4s?Rok*DJN#%7h{ z|8jEP7*Tf|*2ZvTbb?=ngRo!&5VQmm1Ei*0;aBw@XVed6VC3`!n_35Ixe@HY*f--{ z4K`N+3#mUD$xhi|!))S0@lA8XvUXU?no%UUST*RRn6T+0u}zw|3uSD;upLl2%UG7+V@Mo*RTrtt}@6-wM`OmybnYQ)7XsS9w zet(CCJZkS)W#l~dA?WPW>eC8qy~8h*KF!x8pX0Z_9+%V8Lld?kizv zi76`GV(s?NYU5Z}+TcW>;gZ>w%Y*;qZ{5F=ue&GIwZ_3poYwUwuw}rAjl6%mKjs6V zI9m^8`43++{4oK0?^6KqjwoP~i66qb)$Qf*B};}AWplhSgM9b51M(HG)s@-By}k76 zRMtbDjn}yq4?eg!ZN$+g@^t>a^v_n(p(KlF_T6}e{4(%jiO3Hoo;k;F3s{8Zf1tzA zycX`56nM;nf|9%e#p9@FsRyaZWJiXBw2;6Kococ`V#_OQ_SM$6=uOZ{)>hN1U7WG= z%*ut6w!T!4ivvGauRod|4Gy&UA$SdLNW~8t%lr^>vEh$cror~CRho|9+ZwCA67;X3 zz~AS#s%R)qBh#a_RdZbwP;O+5K=(QoY1KKYtnr$Y>+pBi*bEN1n3SIczyy7W_0R3E zYPVg>)^QET)oF6azm_+bpo?^3R{#*7iuZCe)P`}M*j4a{Lgj9GiI#4^x&E6Jh#oon zCFuD2BuCMmuse&%XSVNXrH;xMU0Oe-Ry922``g@by@oWBzn!%T_3&jVx75AcLJY#V zjKPE0zchK@BPMaIF=*IL)=jA52l_XtoBF}6LdZw8C<}(6mSV+`$X^~)5F7kFNI--F z8dPyhd?DwQN&$Iz*II9nV7||9_D#bPg35<#@E24JMF30S^Me;6!fqW*p$DEf973R8 zL}sIT?Sax_rC9gn9u%C^Nzq1-D|8-N{`cGKF}qxWhkQgS%WmqM1x$-^8}S@irdvSwvwS|n zNZ(obrFAgX+DP&dzGzb9^l)`Deh+<5Uga}pBzuB>$~j>p*{L0CF>HI zCb(k`b8d-3|IUhY(LLOJ~!R;^Up9-Aha92UIM4O_)KUAdEzB$H% zXxDjqsnGj-EyvM8Q>zY&Hu|)T4Z}6@X@Gq_W~Grg1FVo)P#L>F{EwAiO?uj8B7StC zR~RkU8(U|=21S*}gS!oE11_9TC8V~*Z$5+sETeHGBHD@x0j9Jd2IE3f?;FQJgu0aB z?*mX0b((nq;d&*&BfSqmR7`JBp@L*RPOcVolef6xK?N^N4pg;PRQyTX9Z7ukM789W z&uuF|bsnh16IOR=5F2fW?k1)jUk5T<)i>uNsF{~BMQNH-m7*|%$-w5PAyO-i+$MOi zruuQXSZ*QuB!wy}F#uL>A@STHgI-jRVls9%v@`5yuZw-IWy^mAn-{0h_>VOdAj@ES zfrmh_3-z}=r8R0cUA+JKfeje~C#`SLFzy9N(H{z37OdL=*TPyZ#(Uz(tc;LsJV!(z z+tp6A^UUCBl*M{yMElW3v6y0zARaU@KHj^2u_V7;wTxj@p%6BgxbPsE52N(5OUxf( zto%~o=CViJOlt1mNHwDKnA2HDGPkI92vJn|**Rtp^(EsdvPwz+t!p+096fHGFw4 za3mdULdY=al>vm2+ww`&yNK_?qOnFnULouChQ}|I@Bd|F>z;dwI{BjXXTK_qZtkQRq>$u>;7hD@@S9G1MT2kI6TdS5e(Fv;mfwBW=1I53A{RJ@{xw(9 zj|`R0JH$q#xOs`(|JL!k><$}oJqC?mggAu4*A;u*twj}IdKxFChU5?g2|oj$@NY%X zN7>LB_7V}kw?moRO$ll|x`d{Xdk_*2q@^|t0~>VBF@lL(jvGTjf|`!MPir9YFjPP< zCV1^;ZnBsT-~9~3b1r-sgx*CW=;uytg7NmCOU=R4YrJ}?krW}qjqKTGO-i1nO!HP& zrIrDSii*iQohb40xNeJX)oU_!=8@-Qqudi1^FJYo195&ceFv7$w4WH%UhwwWqa39c z05-*8?=`nEfi*$4uf=$AJGD(5sye&i8?ZD~bjPqJ%*pZ#ked3Hy8IAxsUed~H12jM z32;q6lt2H^sbY z0Z3{udxcQv(}7`3 z1hj?S^O$EnD@`^{FN0vAWWKPEEa=NO2Ry~gNGmo$@AkVAOtm^c>-FD{_uj<|ODD-8 zx`sZvBl5j9D0lc?|{YT+Z+z+|TNLF|S-_ufX)=S~GOtB)_4Sur)TV2>{KI7DKmcu>J zh_w2vpUUNn5Uhjt39Hy4`L5&m{mEcy99Vz^cA1aTCDm6>%F3sdaeZ{%7h8BfQ#;0JOt`;Mq*-J$RBIA%Fq~W@J*i$rWk z0MBDXXyMTRkTM~g`3|#qIV~_RK*+FJ4xwrA;r(xntwnw4tFcBWMStfuoWvjsUBL_@fw-{jk;OBycP23po;5K z#rcY}da-aeJk~}O6o?O*u&td?0BzsSd2U$4KTw$vr57q`U--btD9G_E8Kyg z#EQ8*?ez8`a~anpnlf&`gzJ*>(@UZjUBNBN*Ytg(s&@UV>TB_;*W2~ZRju#@(IMh; zxo-!r!%n%bzpNn}g3Oi*+uYC4197Qwmt|cFh%dptj}}+zk&p zLvi6Jz>Ox^K}K{~%sFm(exD#Ah4hWaMD%rPR^Zb;>AT-#$Z_gw&m}zr8q%U;n_e}o zWbyI2#y^gza(0dHT~E5eaoXs>(fAuY!PfhjGkRZZnmj#!98_piYv=E@bu6~^fH?*o z2$o)~@LU#?o{<)fOzmoS70Lc1P?TMla!}wciVlNQptT>9p1CK){M6J%o}oj}EJx=k z7FUA4*1t9qy|UO?86Ny#(f>C#R+j{kWM#m1kUR_iDAtk0J_iBd*4n7%lwGGG2E^Z= z@%dGVZP(m9B>Ys{EKPNe*dqNd`oQiQYE~ zTx9nIo>C$CxyQabgFn_-$kF)-a7C|#dix+9mCS#Yy>4jJ?dvx%KkRkA@TlKyoN=1x zKab)FKn>qzA>NB6z`4k<`skqibDrD3j-&4t3A((F7N_< z>ZKwGO=JXk-442ZJ0k;gFV)1miM=A9qe_TLt{e6C*T~H*7 zB2&yC4;G|wn=fT1vf!%7JR>6fhdBf}mS&=o`RLxgoR~_3)fCAAnxTZ~+4G1t?QbV*Di@;ZiNs`zf89%br|Jo6p_5k|QnracdU7${^xEnTHqw`)_! zg8`FejVsfoeH;kXQ+#AyS(L}M{!hoqzpL9?$CwT^W5yXA4#4+WuUp?85wn(y5_eib z5M}!C3zLUmLPhRmPILX8;%6bamZs5>B3P#Mi>l!S!r}WrjG_wd!gP-)Vz~KCrKH-QdSNim>kvXbix20palX`Sp%7y5<$xPr7Br zABoPF{rmI+3z{9zi6aRb?2-$FPeb(lK^h~o*uUesF;VGjQzy0`m>N0SeR?S^tl%m+ z!zMnARe+#5TSE?cfP??w7!sG}GPlP)i;L*PeZG~?4i0;Mav3tNQ9(Dof_4ub7mVST zg@m0OIQamK03cG7#mo!6%*(~LrzgTzSb5&l=#;X@veUyg3wdwmhTo1$Ok0qD-P&1O zd?Yw0k==-&5iz~+nm4@XRYq=ZjZ>X?*QX%RjRf{vY#x{we{1~j{PwhFB585@A(KOa zdam{!?D*!`n`61hQnaUT{~pks)IHZ$_-g&{i?88vj{K?*Yo@VWZz2^S+o5kEW)Edq z*It#rp-U=oOx044X8vuT7gl*I{ci>N>5Z{SYZnhBal5upa=D;uNZ$;DVZfx{Dh5us zN_}(iA{-~=&wGZy-{+aOy8&pJzK^AA>;2^NqJOY+1gSlWpCGveWp>7Oc4G72<%0g_ zI2Pc5Ygs4U00?epA#C`)d;WZ8jE}ALiuvmd=Rz2o_4LN^g`A#xyy*tSX9;(Ae*5`Z z#-y-^;<~?P$(8Cc74n)l^W_VNx2ZQj)S}q9|Gqh$=-kNU^qS!}hPQ$E$jXGGEy!o6 z*VAZ%*lRb|5PN3R$md??R-%MEKMNG_`ANeAq|T>0FU$P;;0`~^5+*i z2}jSRKTLY7Or6_`$&rXpx3TK!(-hTzk{ZK8I2NrxFx$T3cp5`m^#Gy-50Fn=YDx`sOds% z2^c30s0V(D4EtCf6vf&%VXy$arW{qr+VZJrBe@QaUNiFH8D^a)0q*zc3p zgr&V7^r(lm2dD=J2TbRqSqHRR?0?@7DMu@!CLjOFzqT*%DCb{+p%x5@P3BKcPD#z= zPtUR8sI0OWQCR_g8?1+vH&=Ddwc5J+dSzGC{~#01a1L@Qq3U{fPo1lA+ueKp_iu>F z;B5xVWevPX$HpfnpFH6hXjwDQU(C+EbnL z+Sxc!qyb2Ct&a zEM=M6gp{m3cN#x)o$cl=mL$T6-vzYFf-6AO1Ba&9cPJ;~55Lsbc-yD-n6}FKHMnw< z{c#chlQY+mS;bNXbcM98PQLrD!*}DpmNe7lUjLdrSV=>bXjB*!UcY(zew^Lt>FNGx z9c0X-8u&e&qM?+EdceJ?OcqE$kw_(w@flya;1<%f8Nzqs#EBxV`=6@uyH6kJkmc|1 z6Z0|0UOm0GJ>7TkJz^vO%xGx_f=etBk2Ce%|A}wz{qI$6%H>puS0?GL`m3$$Anf12 z0-$IJ|6S3T2i^c!#-@TogQLnh5$xtpC6`N^Y04|Q@8*{|bP52U4EC@kLi`@{#DbE3 zNm`X0wXr6%lVJ(!WSf*)!FjIq@w~lfQPUumY={#PiNpF|2tXmt$t@rxqK>tkwM;cw zDLeDDPvM-w{MUCNvwap4Y3R*rjHwR645zyM`-wzz8R+6wP`0qMNVo%8NcL-JDoXl@ zswf)9XVf|%AnJU#9A#K{eZakdqQdWWfwrX*|Fqno`PeE2%M{{o2}uSCW1Jg`ngdQQ z_$5mKDclK5t@5=;Qt6g;DPe-usUJH45;{9OIawfIkq!xVkuq0Ef4E!L+AMSFVC#1K zCArt3gbL5B{0=jaQb(&qIi$2lR^geG%8m>e-5-DbEM4ak-mPRouPu z;!Ft&5%=AlmBFnIU7|gZ-5Ia}RF>Y@I0^`^J5Dhb60LYr{|-Hcf%Kww`>JQ0W<9Jo&I2kVWT0({{#6$>vm?noiT>0n3Os;b_zkI zEU#Cmkj*djC91#6iYw4G(`&wR@ztW&us`wDEz6d-e8b{+@8_2h*Ls)XW8C|+mOew9Dc1Ja@>lzk}R1NkZ*=;J8ed;1B2pcEtr0`IfNC$m!?9B!jrE2l?Ydeacj<10;4-=8+ z<{vTSNiKpBsbCZ84Sy4;sJGS_uESPlNP-Ej#AhIQ31go=;JMgd!37CoGIwk6nx|~; zTFAcGE6hs_PvFJV1dcLcXB%OFGHERBd2m5AXhXjvVpTH?3U=#y?m|y?ts(1x;=bnk z^n(@6k`zF zsZjfIh{|IaKXP{fT6urXe7(4hDQSKj&Q!EcX0!!&e{;T>;PIX=dR1MdSjqaZ@=7p_ zFa0xxn=XPF&DR=GC*=yu&_&yo$F#Sh=B|lEFM|<7$FG-C5RP~d%4`XWrT~f!ZJX9> z_j05isL?+~rE0hdqRXsVB5J>7S1`75aT}yXtNnIHb-hHBn(5Ho-bs02zQ!~CbBK3Ro ze_)$(s#!Qz`A^*)59#B0%hLt0Og~cZ2NoA@%GsK#`>j-T8a!W)72n{WKk-piGg%H=q9mUT;hMj6Fg<^Izp3qiqwJq>P*h=<{Mla~&{Q zA-A*0L&kqSe|R*2x2Pf{B?zHI9teG^Q}uQUY}oS+@z*5tlGZLn_Cp2IY04ILkYM3* zYsYOk>&NHymf(9AY{1$S9c{P-J4B+&rBQATfNAE196!GZqwMv*Ihu&+O2wx)D_S5) zHB@3++1&g;l~XJoIJp6Nf&TeNCikapieD%cWk##YoBqs)H-38bvqOZN#|xJpx5ZC^ z{)yew7cYg4A+Ej9y*s24h8;*R+V;-DMX)}{)KaI%KlgU4X)DFA%07GOcWd;9#y08a z@73E$77@X$0zfV06^ySa%dwbd+JQ&-Qp|_WUfaqXs*>%R8fn#k`u)h|8!s1f^~aAm zme>Pt^F* z29@V|JHJp1Cfq>UXB&Tm)BO-hlV-ei?j3RAS0ahga$bIpJ#ux+DJxCAd}*4Ea$Dk!M32)Z*q0oc)z$m_OPo{jV=2D|MY3?>$5vCRP9YN zM7)kO2*L2wOM2gwt?Ddt&PpUjqxczeDon_rb?mB5lAIrc6fMSav92~Hy4;BFLB!F7 zuh0+)gZdXv$@m`Fu(5v&1PxP#IIc&Ioa9eBHot6ttJomb1tP%Ugzy!_ilbW2($;A- z(Q=#t9ei<>_JAJKt#r94_ENXaWz+S`N_WFCMV=1x7c~sr%P255f*MVv*7yP@sew4c z|5~#B88H16bN)W}>gVQG$kXx5GODtN;hO;{;BuEzvh)&saX3<}EbT*IvigfOpSvRG z@G0U1ga;)P@m1Y3%IN1Qvnm%_v_Y6arkDu{^(odu)K@0R26hq=9@-n3YH(pr5mcC& z*-C^ObZ3?k;FP7zvt+Q8D;5rrH3m#=$~7$SX02<5tajmWELw=X5)+^}6$8a%{xxvZ zrgZi>v5a%gFSBnUa}Ea3y>Wsb7(~81XTFR&0zeMK&HRt%2ENSNC<2?+d3Kh1x5`?( z64O36#|%WCo6ihC?gvbc=e1#=bzk#x3Se5BnYg-S5uwHsz}+{8vy49TE1oHn+iXuYe* zRvFSEkZq1Sa@|IShZ1sj4cHz+bF0vs0k9VVq01;tj06-&B|9_n%L;{Ch3pcqi6Voo z5;?!D__0`{Ldg1HOj5c;-7+T>4g}Yg@=}#Jiqfqiv;a`nR%c4c5>ZzHIE)1 z1ttz40-54pC_uwOVZc)MfZT<@^BKRQRQ!Qb=Mu47s4B@5!krV`oP};F%j=Y&M9*F{ zL(#OAAEZlx!RnyHFM%gLoaSZ2d1oP^(PHUzED}WxAd2V`52NX2r%;IG=c+&T3K?TH z@9czARIZVewboR4Yi&6hT#i5{yG1&ZWvO9xZXwc%j;xM)L}cAZgM!)Az#$=P#FxOzORMr+P=*`u*RK(D3O$crH~RC*oai-{O= z`YO_(`~hib)C|PIZ|+F?Zdibenh%@kVf=pAWi2v(3q_C%u-RsuAT z#RnT)$qjY>ZIDEI`I(Hg=cQ-obqF|2s^CWrx~EG!LbLS)WOE$MhIaNnuVJ7u zvBl-y4ZA?e(MBR7>);xGrfS2+shQ0Sn`|!Ny19gWdyjp4T?)i6>wNxq)O}A^$2uWp z=Jj8kbu`SQyHC0i2mSovG({ywv%QJI+flH(r&<0(zs_eX`UElaE z>kJw9eiBuqaFhPET}B_*5qSzQ5)$b?{^gRF9YkVp`BG^i@W#sE{t!HrVUZKtq6uv@ zq@EXLn(OYhK+n6_p!x0MoZOg@ZbmzL9jKszzl$jBx81yrJNZ@4)cL6KrJl2;gEvtW zgwLJqPiq@6^iG?hmE#|UF!LsZvRR1h^j6;gBrsk!79)XcvbQ4TqPGKkseyEB zSo8ztRZ>oki&}#X9;|V>&*L)NgVEI&rwsPkkqN6T12dhSjl)~J1co?+KL}SO(x;>NhRJA%e#uCctGFa6JAHR53 z19HBs{mA{ETk6GKTx*9axbC#}W&Fv^YrS-*eF@^l>JIa)zrl6dxk-iK3rfcOcj0d< z5pEJ)su|zZQsv!gefoyu`j;B?W&8C9UhALv<&H5bEFW_^`5Rj~a_8A^>+bq~rJq^J z6j4q#d+rA%>$jlApr})wZe7K_-qkb&3Bm!9@cv<9xCgksAqkc_eEYdFTUYakMff)_ zL~s5i4^u!My^AL3VawLmsC}lh(MZ84IWJu3@#PttTumkTw9f(f#wOIm1D!DX^ z4{PT_GMgbG|v@mWz^N0B_D)MyH+6(H%|o4ua?4Fm$jr%b!#S zl+TQ+bDZZ^o z+5-twZQU9pQ9KuSCsE9?3zdMe8(>VoO&H^T!0CeF)26y#TY`3e5<31srtcj0P{-3Z z+LM|y9$&nHqaAV{!zK>TCxJlb$KU#U+}cZD@f~Ph*M9{x=Ag$iwb0T@O}MCm@#hDab3n)F|I_4ChGlb$)cFjL9kv*wfTUN6IGFQf`za_NE3 zcj>7o3!W&2?XtY8m*#u$R=@7SA8VhSnJ^gm;gvIs#sSzQc?Z)~Q2*a!yAg|5>xDwI zG&}GwHq`aX@)jt*xl4l!d>ad~G_bm#@!?2LuiT+T9jj%6)z#Ai`q=Ana!5rCzNz=T zHr+A@bQ{*I)U+i391HTtS5;|K2sv-6_gTxsAd~esf-sN+R4mh1JyrYd1*D(~27rex zSy<|PBnv%sR*MCn*yILE+D^_@znfbg^O1=d#86to-|TK{bvh+=UL%60KCHmK2{(&{AzXUP$ ze1|O7hYa|k6M`9Ew~I>ZftJM89R6bGSu_F|ZCQO_?vq=YXm9;)0jbYBLIo$A&l}g1 zWZPr}>gLP~)PjrrZ2Dsbh^ze6cb>d&xN4*eTtvx9_DhEA1@VttXzx>OK%EB*%(+tu zG`@W**aQe;3NgH8Etr3j{V~idK3r0r%RW*7L$%y5e{;jPJUBeWxV@jb*%EI)6Wrz6 zlPP4!|M6MDst52t=pH6<}m+jpE9tmpjY#aXWDtM0O-`N_`;18(TUKMz_th2&>6twquyE56V zWTrpQ_w%K5FcE&ObU&~*;oX1EFLunXZDa)9Oak*RZSVh+;Vd(z|4HW-tz8L2C^O)r ztJEnOPN(|^)HAWE5dxtv05BM`Bv*|F{#qIQ`DsmSe zhurKz2YpdJv+HF2)wva^ST}k2nNaU1YH#=MveH9Y_ILR+>w>x~DX)N|7k5{w;0r~& z<-n}|Bh>Luae~Q0;u1F9Tevms#}CutNy@kG%U@1kk(EthtJ-}*Po%huux%`7XOBXE zJm}i>4EWiLZKquAuh8Z9YbSeO`DtA%tHRjudu-{&w1GlJubP{ubcrK!1qB#Zl}S_o z-QBPKU@8dXy=k_KIdstLtXOizu=N}DP6S`wJCu$uFPf#3!qSJC!Yf(bYFBq!oQ&SR z;K%IjE3vHqRQ-Gyy@)PSokyyFFZvYaVV1mH_-kDk1Ik|b>Kw80-{~t0@f4!k5 zjk8q}RFal%m&4?Db@y-}6IavNCJAUa4n7!*HBUqL@vc=PTLbR!Wtv5*9iQ@vHl3_wgic(GiC#8pBEK=)fCHI0 zP!Ur_h&p|sDfG0=RPYq3o?hJ9ynbS?<7>5jpXyWF%;5t6=#^o$8{{DlJYJ)1t|$0~ zUrsUaV5X~g2?cL-`{wBzIt})xp4_?h{^ASc5{Ua3``wc<}ugeXcvPcpQXs z?W~?UHFd8?4$zZH&1XCG_nzv=9v%p^UXeKcEUu#2U;cHA&x^Z}8y&aDx6eh&1r7PU zDds}($|;k^i^gb?2*>L-S3Xk>)39>+M^w#tULAkCG<13O@9qT_{7i<^;V7gbY{OBE zvTgtPQR43oF`bsAzXrO?-6rzys8AnEpNs3hG2r-Htu|G*Z1bmh^kWRTKIyi9I z=lQsA#$;fu1j3X(Sz0VR=6k0)GQ5!Fn`r35w1&%7wg$(wz*>R|({U)Aymv0XA>H>g zGRs9$BhWkIlEI99T0_hnwLVj`tt~EZbOmQycTt6Ks`tw~UI;LqD zDcW(aBTTt}2t?|-X20cJ?CE(f%_x7Vrm^}$wnUF;p8Y`AQt8V!V}P{tx`p>aa;Fi4 zL^yg@r2AiPu0UatGhP=p(j*oxxXJCF z?+QqJ13o6TagDN2C}SU)c|ZC2o%iMNBcE*Hs}3E*BZS&gb<4HEbM=g4MkZW?dm7%1 zNr{j-4U`sJcv`?q<;LyMM+2$_-}_tK7km18!PAcLtJjuNXS~m>orvX+H9iM9=5q9P z_X{KQzBy}iaB=dXSdCb#Ir+EZ!k@KGYx%dr%7ot8&)y;Egi4ptRM$GRf3Cd68-3T2 zpmh9fkv0Hzdx5LOLYB3gAk5{1n34U>#o6N$i$zu5lHR99gY-9gi(vz=zZZlVt2l=X z_Cboz*ls2dyYl?D;qf&Mhul$;&fe;W;5AxBuT{QX9m@G*$Vc8i zwFIYIkw3aDQ=<0p%+Mrgm%Y$QYQL5vE_5mH2 z#GsC&?>?AYEI6fJVhLU*AT>JX(W!ms>oIJqq7-kCCD&pu`OU7HxGKh{oyB*>tXC2- zs;Kz+o*>3X=#C5;8)Divg4N%wtY9XmOTY0$qE0n^{D3iDY`uPMeZJV3HktAwegz@1 zG-8%?6^9{K8y4GYo=H>nUA-@wzaF5VzrJHMpVcU@)LOkh-U13Ad?pY$H|EG6t_?ro ztd_1|(rBA^$u(*9uXVO8Hl4}Y;bVbZkT zXb}D8>dCg}wv60pp*iUb!9B&VcXnH9r+~k%1M>CSR)ksPv|~a1Ecg8Xv3K5GO$FYX zKIsWH^bVnS2)&A-cL=?zp*O|QJA@7*7xWfk><{B#HhBw zGr^X1%g&7z;$7z_KK%M{_bh0mv<=CB<2kLL|(hU*2j>M>t2Hy4; zQw62BiktQg<@uH?ecyLfz21iluP*=9hup4zE%}k3xO}HfykGZ8ZHN0u#}*3bokxFm z(*8KFH2ZQ6JQ`te2(nyw3yvu>Tl2g8&3EnHvE8jlNpwCn?au;}Nu5pB77?vFMq=B- zkmsfEqK8%upz5?UguGl_xq0fN+nd81ub;*)dgw2gg$;dZx~07OsFdQrXnMlf9O`D| z$ri3gePo4arN7wUy96EGXuRIBE92N_5L@Xv*NNx;)17x-vxcAi31Rk|D*p7xLw40S za9iAFXWI6-luZw2xCk+^@}3jW?o?K2W*29e+x-jCfof%Uyv6@^oIh{#P1)KD zdD{8Y(Zl)b&emgxI=EaUz4y|!k6=JgltWg`(v!j$?IXh%Ul+2?T{%_OWxesfu{)>G z)UpYxcqV>o%eQii{a&Eu$In;q1W)Lg3NJBSwS2=|?>lgjSaPjcURg*N>;UJSW0F&ul&G)d|R>VMPv z(@S-}>K`nQd@)?{a;uP^B_hirOwPzLly3#$wRwXan{ zgG5^)LRM`jr44MFjqOW(A?k>F)N6lPv48lqVY(5V+foAMMxBq0>N@|I2vp&wg6^#m z+vGN}vfARq2Muss_xkIOHlEVr1lxWl%DeEh z(#Y&+ueCGF-VJ(wH1?hucJl75zNy@vyV8_*_9vrsmxTdA%};~xtKU6-T`@c+aEHG- z!|~(OrQzmd$eX;rw+{5w(W%(XEZdRIYji&+QnPmvgl8_Z7 zxFTlRnic8VgXy|U>3ToYaoiaOni)o}878qAW)&G0gBey!88$yN z@Z6d9nwgHSna;79u1o3vV?+2K^#&77y(aa8#l-%GJB0B&MRh^ z|63Fs!}=9wVcz3;%`(CNT@NhaHdHtX+@VpV0joAoY2|v05;Q)%lBd|xs!}TA>EoG* zZJS!zboYyKw!21^dbHVP_V(V3YE6gQ8rK(6cF`sd$B`#5o1ZoTgIPzjeixUk)o$3| zo;j4!tjC@{ntc`Itgtv7TfF(5mvhf^_`FYWhxWYuopQBD3+JrVZ@rtcDXi*zq$)Rm zC9Ab^zHLcy>lrzM_l(8R-d3NzG!w0Ku{8Bm=TjM6fLCJTF2Bj{n|sx1U*57uN32s^ ze1axh&)#A3AL-kg=?i+>e@6WW@@*V{;AQIHhuLiF5A%e+{Du60+uYunVXOJ+_M-W> z#E-$mMZ&Vh4a;kfD=kCmmZN^WMv1WpQc~Yt$G=IV&oVXOK{Q%rs6=dTkl%RHm^%A){ns%Yt+9d6C8XF|f=)U@G6 zVX{@)`>iN%rV2tS(|F6$rP>L%N@wNDB`N}`zD`A6H0I*;;_c^|txh_T4sacURfwQA z{#G=H8c0Y;7q^1&trbvbFR6xFXaB|<)sfKE=Hl&bYJv2XA3h25qirF{rj=&9D4VTO zeTzcWf>e9C7>a{%m-P_{*7&AUF#p1*;7->P`#B(0h`;KCZKQbizSyJ_{Z6u!(}#@f z>q!(SIlv_T)5t_P==~i@O&Y6;0Jmm!yPeI zTl;@YM8KO)3V$HR3Ck9y}wM^ z;WLr0eNvj}K^|AN%4t~9=xASmz2@!Oc8&Zsr(p;^RX*0?xB=*JKmB^ zpK?Iix9Eqg&vW^^79F--{4!Tzk|ecVR4yn9c>6CmRw-Y2#ouTB?&6(Jn+o%Wy+OqF zsOLUhrWGFVYoFe_vz2cX^?BNGGPS5nZtcj~1B z13XvXBKsxV=q+aDc;%*FC`jJ^Dz)LwT~m*)Yj_ai1_z5PnL(yFaaKvq9=~}T*ef^H z#Vhb(s^;~$;O&8ljS$?Mq7C+lojaYduMR#l8)tt)wUYbyGu`txxOdEoSuR>%4Nnll zEi@?W)H3@-)`-4;%-tiRe@%$lXLFy*J%KA=5sxDph}xA6oq1CbB>nXr{aK=tE+^s? z5fItPva{&c@Aq661@IH~p>)$}P)C|M zfdL2h!KG?-#@+1}dmLT((nrsE(DE#kRAsDOfQkb)3(|psE7I2T@i-Ef8HRpuci1pojA$DhMmj}qNp$Qc1B2!7YTa@M(-j*38-fqLfroMz{DyJDZTmvzupokFuCKfY|$9g!*1 z<)`Vzop=;}VY5W}RqHS2clg3+37Cti2*u6sKG}V#%a(h?TCblqs ziA|LE6G|qj(mWtN^3}P{-0H8GeT~r*0Rx3%g!JGT%UqlD3~za-B0iN_f{IxBFm5vU z!Y;6s(g$_>ad+v7LM8)DRBmQL`}5GQb5g^^D3gP9=x?btBbl-y8yw8c=|kAgs-pxF z14fYbFZZ&oeDE*V2bj7^2v5OJy}P>A4VU^ETArLqejyEGuijl$-hmN&YmV}3xO9Bz_9liwPP;_MU+@?~;urFQ)6W0b^7*!e2k2)& z{^4#KywTb`?$e* zJMU>=S6}Dj2zSjsXU&H*HylqQUEUC~A23qBMOlt?>rS+{oqq(J`MJc7daHD{?`nTX zfWSwF@A_a490`rJBAIAty#Q`@akT-k&*yVZ+*tF=*-v+yvKdV^yjUGt9(guhq1{mc zxX3hc@ymdCovWk;v?{VlMO+Q1q|(>ik<+$QXx1cWJNL&RSId}|h5d;EvmB&O8#9F$ zW&e4Hz@~!e@K8l0a_JXSZ&)$C3vB%RM9JFsVk76*Ap;-r{OhSmUkboJub$6aIT#lJ zABl&MaI#GbBYZqeNV-#PR<4mVW zj4i>Fe!L*iv%g_}@%Up2?~W|Q^8h!sC`~%$!mJN12KM|GR5!yfDWdG|{h z1J~08Tlw*t;m$}GL0G%rFc4vaTS=9X=~Hz_tbs5)9Gp!P{EDmY=ZYu>RZ#FJ_a2Zb zvR@4=W!5u9P}WdZ96L?vB7Dk7=x!p1E%C_u5|-4D*B?geam@ z??{pixG!cLCdf`e5orJS8c;a)@`>{$2js==dhf7o_YWIvN z1HE@P1lC4<;~ijZz23Xe&sF*xJ#7SBsOd^`Hc>x)^kXk^I#~0Fa!K?!Xacd%A^|-j z-nd)d0t>wpkX+yjdmx$n03H<29Te|?5p#uV&1Gs~p-)_OI$-?sIazbg`I?7roZ;ea z5!xc?1QmR2JMuK8FeiI4TI!XgWU!gg5gBCf;zoN@9$EmueV(^vnhJ>q?@5yUC9*7t z?j~g-;!Kz*Vzg@419p?kv!x0C_=F$REH0P^x4i!x4DjG0DX0)#k7wT|;Nz{2_04H%TY(A%dh z7N*QWT*=Z}$@#Il(4RREckzNPImiR>pcFvw=gBbfAGb#7M5$qGdBk8jk_2U=SgpSF zbHf0hLD`u@ctt#|90RJF$9#lw3Vf~jdJxu%%zWokCM^*x2IN}3f-p6KC*2atvkT8G z)If>kT!{*BH`ys0fKaQDm}?vqaI%&GfB{PYB}&BVqW6x7ZUp5!j?tBHKl8ln3{xpb zvf)hS)$E#r!I~1&3k+oP@0rSy_o)mM_;B-bQ}UHqX}|zo@J1TQo&pT;pm$mzsEPqC zzB0F0`D&*2A_s(%!p%bkeajWeX(EaKVnVsq{4q~1-SY)jibu0gGik~srIkty)^mat>mBc1)uwZ? zXNN=tC&XO285b87FLNy^xKUfCoI4o8iS<);4Aj;J5C_REvrr`pz%ABVa<^e(?9#jL zQofw}*r2HRp;iezjn327GV6G`ALg;%p;L8*?aFEWpgZWccKxt@h3nq$7ce(8^QFl%`eUC)1dnU5}%vL3eL{YqNj42k`&^x^A1|)|~Z~ z>&WhAZuhQai~88sW_1ei(H*xF1pdtfp;UG&Vx06#&RfF;HEwd5gK{<~fp%>zy(e97 zDo2pFY&y3&ExUk_#@5)VH6D;)NbT-W9aW~|szrzNL60Zi zM`{ylI)vL^FEiA>9XHer#}_*h09-dleYWomF`6bcP$siUV-gH?l8tq`&E31U+-0t*F>WGNtGJbhA0`-6b3xGT^ zuBZCS#S>6SLUlm1Ct?o4Jj1@-Sd#6WfR69l7$PU>0J+cT;{p+~GCp_{=Tnm2IW?(TK-IgChrv?f>?RWd3+0^^gdzo=$^F+Y%YCj?DuBCZ`UCn(f%dXiYd=l2lO4nG*3)IS2t8y?r z6cqWZaPn=BA0p!6k|g6FFi4jS>(Bz=#AMXt(v1(-6J}@!tD%D*#VVu=9{90y8IZR* zh58IldmjgaVrW_?aK+Jdgl}Q>a~!Z306$XD-hZ~^xh7Z z=W?IZ~U7ZZNuSbG9=yqd9z^lWs#O{f6kJSfjYOgd0`dAgH zkYW_7Zw2$KDw{o-#)qNj5T@ji;|0JN*PgALz5b^Qj0f(TKE3n`Z-5*A>=8y0o*js8 zcJ!>etphS{PEqM+yHFGB{$m)tPA&#Lxff;3w58(qouOl!jh62WT?Tu*!4&bcj%%YN zi+V5td=va=QoOu0iuSVgSm;yZU<=JB0a7D?K-kAWYHR@lNQqiDv-YfXr^dAVK@W?~ z8-1|azMg^o6TwStB19;LlE5T??WxXu%H2^K8x^wt(xQ{bhXyVuz@!P!dd0xav8OO) zLL~l-!z6zyL}v2aEL7&;w)&{Y5wdzW?ID$TKK^+Zd<3I#0Ctoc=b+4DYC@WF>$O%O zVuY*eADl@c!#A@d8sxwgeXqjVLQ-l{(qG{lDjj@=|7EYLoCw(~Ev=)ZvXd=ui65KrZ5hb*nSG z(xcb(yds?c8gq@wQJ&_BtCdk+9zAUgjnWgZ-|K^E)q2{- zhw)HW2O$smV}RQqU0tizSc}2wm9h7AmSqT_z`wRe3TKb<=?_>mD?X9bNl>xX0Xe2; z@o|8O4Crtcf9*#|)@BoR?^&G}S$_qAo%NqWEe@tGaO{cu72X`nqz+82{z_ zY+Npc^Xn;U>-IvD)~@&OIw3l_-FyDf&ljYt+j)PY{DB#?k7BK$9w+S%4870m{pBYd)}dP1(N$fV zZG`ZVlL%uY!_ zP5k%rCOPBPR6>%LP4qv#WS@E20NG@n_WmEa)7W_7p51EXH1& z!lWxh-ww69#R6_*ma``?q*q|oNOItKFAH?^v-&d@-7G0oz3CA;34t6pZ^^~LxPHX=;2 z?t8{F2)O?!GoAH;5B)6#jnq(|b8<5NDy8)Sy5(kRPDQ%`=6m>N+f8%qV+cy$k2n|78g=d{<(Lar*CB8Rc4gKL69`> z29uDaq)=|QB;$W;H$4A$+N7AK-!N4|-e{yzVj)l(&<$#(!lJBMbGri2RWoRUAQ(E% zoaurXs9=nR7;|THEyPZ7GAa-mQ%KXoBJw}}4VsKY$?PR7E5eN}NmsL|CJp^1l9#ig}c^(5OO4xLJi=eHuESLsRD7&HPmjF_zxO^92SndVd#I9k&YCP~vdk?^X@e}h zVcg1XP%(nW%IBr}Xvc~CUbix{<7n}Ad}sWrYbQj}@n^;QsDqo;!C>3@GheO?lmaHI zs`Hrc(@VF#0%W~u*nm&z5g(OZEv}k(-+NGD#RmHMLkyW%fLwb2ZaNipt?*OHpL*n+ zm%g~wEgXC5^ZKl_?WP#g8i(GOz$Sm|v+XXWXy3f3^|feyx|x=KPLWGtbGeuQq9n#x z%ov(W00eiors4h@kWyZ%96LcUF{7RaOVR|IGRLgncu-T=M*2~ zufrY-BWDtij$EJV(MGOS)E{wfE?OFdY)ZPz^8#(eew9GM@MveJBh^#~*%cM}HN4D} z_(wg{$gV^v#GK)|0mn*yjui*4XMo2JGG986<(T(%gDFuo-UWd9Hw+o+THdV|xc)kA z3Do^Ddb3W%n3tyl!!K3oQJjYX+X>oxbDNjSoO4U3GnYOZV>y>>ULVeO0LU1yiEE{C zYB{oyt1ojFW@u~+n^>uRvX%_UgNze*K$|l^B~9bH*3%sw?J@!z@=mygJbM^qNQGF1?)Y;U0(Ojb5PD(K z6%Jweyxe{^ehz@m%+Wk@11tDhU{(Jj`jX@%Z@(ej}wDF z?Q{%G71+neag=%j*7|}>n)TzM;DSN68gs`>jxU)dJzuhHJwA9Y1=h^(S4d2DaHJr( z6Nws%BlwcukI%(+LA3582pUaHRA0F)Fmy-6=JxA5cTXl6Kd)^DuaI8Ht$$KRIQU}> zI9Y(FcIU0oPiN`vzLG(QIKs+No1{ov#brTuEntcBe zCKe+rbs39Ymg&}2mTaLYWg?{_)d}NyhUwIbEqIWYWC}2r=Mdy&8t_&8gf>+ zzhqpcuR1K7Vmp$zm5i2618tUP@UC=cHL9d$5GT_FduayDxwN?&O7YB4clcT%-y;IC z`w*QTapPc(p~k5|R%)Hj)YWxy+DGkM$y5r`%nl#FAudr-2&A+88s=8W}^ zVDVHWzdl^BkrVmp;qWSvlyN(59EI3xP0R<9j10Z$&q;}F58XmKVN%5;&COW{4%Eb(~OfBIV|x~4|8*=%CS+`NmS(vz#a z=4f3Uh}je7l!BQh>*onRssUh98Ig@UBfhq^Q@y*^mwmL(MyA9f#l-Gq3%f@<&dDd(JwjpRN_hy zpSoeeYeZy=@g;h9e8z$^Yolq6Z;02D^Ip?!w!A($(;*U=j0LMv|0-{eGU;a>(PO<(x8y^oY8JBJRhFzfF}aZ0VHGsqD$CoCu) zjHN4>`ksNo(6YgxCE?|S8#6aSfL)Vw_+;*LBe021BMqDdsA(_-N-A&2I!X(h3Z2B? zsMqud0-n@mQ-qOQz z#xY6wpTdq(g^z2W$`QTUPo=6*v)85rzrE&K^;f{m;lRfuJA5~|;0C^KzH_Z4(6)->VxHQZ$4NyUbl~CabUG8+|B3Wo|e@^%Iuj>diEIPjnV@&Zu*+U#%gX^$=0wMck$QqSU2U z1@>49v$M1Q%kxyy=f8(sYSp-Md1ZPSDKt5TwQO`L0*dZCv4n72`vhF~e&h@Vb2iCk zMP4Ec@bm)4$aH#l%~O%1OQtAo^H@j;=|JR4OW|X};JA2~KxEq&2-2mwL>KSJrh7nm zZ4zugxW+HlybgFNlvdtI1ui}CaJrR40{dEjIcwx>KM-y2_p1|?qQMlJFQ;tFs-SWG zw)%`b_DkHiJoj(l`jM71ms65*zKac%)oiB8Yx7|q@<`}&w3oSz=$t!D=n0vxR$2h| zMcC8t^J|GoXCsyI--I~E-*9b!)gG22Ms6I)mmd0yaOnT^V;Jd&OW{gx#^fm>LzG_P z#zwEOvWsCJAHuC(Wte$G=>K#ivLg@2mVcldiYc%&R{KkK_~`YFD*kVMGm&7w`GK9s zh>JH9UI%^pk#}kqCBJyP??G|-ecu$qk|PD&eVG9~_e2HufmRM2#Ab;Tec-0uJY&lI zqE)&buIA>HVUH&=a%<m$mY@}$r#^6&^ z;jikTZziOx-Xt;60F)W$J%r!ca)ix#dUulmZ?neBau|k~niLI^SchO(7*vIMqs2i{ zsi)XC6rQ0iE>(&~xq@(3Txnmj9K#0- zxH4HonBvmB97Rp`XsdKT{kr&uYHR06+iZBeX*M#EzZ)97ESZfr!icl+t$3KCn$BnQ@iJ7*jh4ZChS za%xG_v_>u@tH4~V+1q6ogCL)a&>(>^Vj>5C5Sw>mdDg>czxvc#fYw2hx_=-|K(Ly(Z4UH*dSrKKI zuW%*IfSIF8i+h-5}GB5ZUE& z^&jQLLZP7^P9}1QtQ|Vr$bgY5J+H#@Gze8kgh~KlLzb#5YHV*vNxyPR|jZ&5`26SJ7vVYG&y?N5Pi@A=ku6+~zQ*vR_t(X~4;8f{N;z8Dn^G}(P<;w%)JkF?9dfn?sx?`wcFOY8z- zvKC_VM=@4;skO3gRK@u3qFAzls+`25@T09Hm)Yjk*)~lh*%$UzsBiGf_#Z09(s1;fv z&|XD{DB1NkL3<{NEBH~0if0+fg8?-CBvLxX4@6T_g?#G4>Y zH>|XXH9@rV%?I??J}N8DY9_W4$Gf`e0?sn6RigxQ&-+cVfM?`VVK zB(mb8L2N{&_7BXwA0agO2a43Kpab$)M>74^M|+TN3HP9J$kLZ+*Lb&D9M{Jyz5INv zQOd@h2A%S+v@PpZ&ix8C@DjK$k(C6mTsEt!#c`X`#3Gcw^S_}I1WUCME0WF9@77-&*NKM?jKq+Bd81ERu7^D5th_t$c^+d!KPc+eoc>6Vl?>*}l?NyQ z{V&Y=Nw}EODdV}}AzmVAanvcjUSIXjPz$opo#aq2d-ry<)Ap`%O}wHffT%z8 zl7`eDbai`Z-lD2C*@I+>HSRc$ZFrIfDOyw1$iHK!zI*NriZt0AA zx!w6rU+KWtSM}&Yq67?!4tXX^UCSAUKURD{*80?ZfHS!DDv8RorlN~??~oe3a0upt zD>>d!p__YH-|HYSCg)*TE3(~V6Lymoo%Q`Ulm^B+VIPsH0lWwRR+EI)rGAzYS{M>@ z2|j)3w^8)Qdmy5CvOQ1UH=*Q})VOe%%-FQ#IzHPW&rMc|+p~|onN_&=*aW{K%9wUn_q`YsP)202F&Dhe^D&$iL3l`*w zf08IRV3u}om0|YG6v*IR-`b;@^lmXz9fi894pd=?R~aMPUZ85@lC5Q-9$qj*jh{oz z1VRvgeU(?50AL7AAd><@6>L95rt>i){E~oBwuOv=HriK?fp#y$%=}xOusr~I;YL_- zPq;5VSt&*H=MMNSpP0FU0c^9lAC20qxkt>Wo;ia`R|=j5$8C{M=g0np##-SJB(;}H z{9!qDcUDzg0m#h9fEycCmB6(1RYtX5?3)AG$5E2i&$aGi*ge;li>hAoy%$ zcs@x7+)IBsLkbgK%_Nv#vb#5M4)uk2-7FHBJ7n`(4rSaj*hpMVQ)X8>S#8sJ6vxWw zZ=&{azQ)Q z<-9j#gF4wI(%kNE5nq|;o&!bS&9B=}@@gYBw4Or3n+mYACF?fVp0JOc6WC{nJ~-(? zKE0MMzr^=6ND7bmm z=QAeiD-dG@7DD{_AJ%4)Z zQJq|~ww=+MAS+~r#N+f76`OS@QR2yrz-wLVEkNGU>%3ZP?Q-Q4+pW>8tBbo71;m*=#!3^yvna9rrGk1%(m7tV6}?BUkxO-u-&QS=XU48n&fc+&~t*QL@Kk zHfpVHJ8O@Rv=7=XypB_KL^qOyuwDY5OFF-YoN7Irbwa0^E%Nw!I-(ptpYiT)tSn zm4F}}laHX2=(D)7tbZpmv=wWOz?;3Jx-@;RM%Hzs=O6q+UxU<^O~L?owFW1CFy(&0 zNiA}=yw5jKiIbAU`@uI-;jUpg7}~QS^*v&jJ2j=iq1mfKBlm8>ynrzlTKP@#2jsZx zYWB1fyY;)ueI>z%AV--7#~7n`MMT*4=U#aCsmeee%R4Q)`W|f=jo+p6Ur^t&%m@%K zLk?ZqZ3hRLzPp`x^9zV&CaKKln;67O(d8-MFSJKbHV!l_x}UNmUzrkS|F-Fjmiq7w zv^&B1ePn#&g_H9swe@TgsZF8y++!hTq>P^Fe_R-}eqb(I#7&r{;3!7%3Y)qB*?Ct0 zO=X%e8L6m3^KLM3(EJ+=knU~+GgDbsRy7w|u`nAzC%TxjvT@le2nk6FDcBbCY9UnJ z1hZ-ubE-UPc(*ri*EcrbZN1;#d^95|7MHSyu3n-oY`<4!i^kc^O8))#SBO`0#?T9j z5R@{CB|qP>D1#s*xXDFUZWDQ2r;GjEMPf58*D!{)-tP_B!62|+ZyO0W4L}*t3~06W z9A>sxo6mpyj`1|rp{(X{_1{*6>Gd+E8+jn&9ZnE`^Mei11{jZE&Sv*9J(!8fJ)AxD z1;ty%f>(i`#x>0BkH4-OreiwL^*Wr#Jn>yLbJyDkN4LW$>lFP5y?_2C;WwLdQc)qy z6@VAUG)D+ki`SoIz7gOjrXJ329&a*Rtmx)k@im;fSJ_@*G%d0z?}_BZ0e@RZsVppL z&bSo|T}Zi-o~LXlHL(=U!IEgCsqAG*$8zt^SOS7%s3+;iS0Yb-xMM3KAttp1*ZjOT zeDLnwy_Oiok%mv-PD@YoMAN^r*x-asa5>`eIh2#wZW^2c+*C;)ies4z;Fbohm|$$0b7-3dXNM}3gN?NiXp<9Sk@az1~}I*Q%VE^AxQXpbOkJ`s{5VenDStcD(1FHG zWYEGDGG*2d5hOWmD}ET!@(*@K9Ffi~Hi3rhD|QU6C@c`sd^@}-sAWwVbVd4*oC%V< z!;MnKhS%pJlXN39d?iYP$DnKsH`3@>`3onw>Cnp;;0r`bBP3JW0fw@HmrNl=Fp{8~ z!zK?G=wIyBV3 z@DJJu`Fx(l5nUU&c}|Z>(`!R}So@b)2|E!0n3a85M!PEy%M3a1IaWW>d3vmS!T2aQ zsQW4LZ@4_Opwv3~qN8<;%m^25b6u(CN#18;Z=4-8F8Oot(JKy)rE7JWALt=|BC!GO zoy(C?b?VESMd|Rkh3h-ETosr!0qrUR4qc@j2r!6}J;Nc##}C_Qq1yO4q~~|UH|Xhr z8O0;-UcORfLg?>(Elom}iu`krv2+7EPG4aUC`$*1XM$7bA>m2Y_7G11AwlB2+rO>a zgjDEZZ2{}1R_e#EQ#zp9Sc~b(tJj|_og0ALQ`a+ih%CjX6 zy{*R|{JuQaI26urq}!E$M)Ho`D|pmacBG^6Opnl7AUg3SvU$vt25P&~2~lo6kHO zbk8T{cxiUeUZYgsY7*dVhk~=0L{`JD*=!CY59XXOU&VZ4*snIQ?>LPz1Y=Kg>%vm& zaAv7fJx?5xK<}IfiFai?nw$o(`laZWGJ}1^EamU4jNcH<{N4}Q@{t@bW1%`%S-xIF z)?CK~aAg^AzOV^BD6XU6Go=nKLPqR;>wo$J@^}n$g;DKcw4}PUGTvYs=lkPxMzbW* z0)9E&V>QbMDL99Ow-r#m?%?DHa^md)*#q=hvZ|LJN{Wbl0$z z{J`fj($#I1UCuOm{0m^|vA>@TCs;)D9f}J`9T&UN!bRSOAb+yjFKhY9sl0m6-Ag(AQ})w8XExiBntHB^8AH8LHJHPZ4)c zi`FMyobY+qxdzUCuOcN|i#ir)ZZ63=Nk0c^Pa88l^}QLRq~zno3ehzsIW=vQd?}UB z1N<@yIOU5a@q|>!;LFP}&ky!IkswF~sZ90yp*Qt1upwm)=sMiUwAd%DK> zh~5XbMu0>5)ec`ty8$7za1HCyn4=$sB<~sp&hWb~cdh%CUE!k=X|)A~sg?ZR;O`yk z-!qj`3c+lH5#aZ!H$5e|)M)+rRNfIo;=)p-_rHTK#m;E` zLpPuG0Fij)ovlN**Q=JdWG~pkR_yoKMLeE-uqu6|H-pCK48!z|&3EoB++FD4Xsu6r z(I&)yKm~U^{NxfNYt0A+S)x?3Fm6)Q8=PG2`<9=b1F#T|$2hRdI;iuF`n80sGo^Iq zpnw4^oLe)))WQ1;&BnV)-E;L=^g+C!a4PG<`Cf``HVqysAd2Yeb}b;1*^)_O~6s=?Z0 zd2q__+@QgwP1ieZj#2l6Cd35#(Sxh6_X`FZ4bd6-QQr_}TdIE_j$DFz=Q7VXaiTt1 zUJS=Q;?qdH(ZqxuNS4IVt|p$G$K9!nB^1EE*ys)K=L4$R^r-Xw@aAR7mE7gZH#bZ6 z)1EgR77QmkXyKpLMP)rty9Tjh{Amc+wzzN#T-^Zf>}#k-%4}3#uiuQ=h1`<;+Esq~ zoW%D#bo!-=(j&*Tw>HmCJby8q{kH(ARo6gp2y{o>dib8r@r8WqOM^(-Fb|GuiREKh zXOoEV{K(c6VkFiUJ@WfZ)ns`6(=y|O?!0%&aZ5vg08*OeQPM!EiNe)5)$A)YZ;8`~ zeAJ(xKhCO0fo(sJ?3TOli2|NezG}Lffw5`2yUcSZVrdT(M1Rc)Q4Tp2K@5kV2BxkF z%17V({w4d=6m5iqgIr|G9WOA+9zO)_w=M`z0^qlbYUTZkC(w1mFGg32w*)eN2N8#x zb*=lk`?ds>xE|2=$miE%jh{744^t~;PxBC9&XYWXXQWzW3M7GK&4!7W8&i7w-YF>{ zW~V%Pe36f3E-D?7@>PS$W<5~|2Wl%3x>}yH8ZEwD?%7ulIbDQPUR`u+rVSA;O_?6f z;INu05;liZiRo1TQZr-HHvtS!BsV+yY>g=R_xxop0w^A%GSd$>*#(&of-X_5 zEO#PnimQvI)(ExhmF60onV97>vzUHvH?zSIlvT*|cO5E9PE8fopy#&cq5yn2 zxRk1Z%N#sx5F|*@8hv#dc9AQ2&X>R{ns{+4Bb7USk`)wc6p@{iliM z1I#qXSd6W5*6|cdQAME`X{JK}!YBpiEpU^TD@==ypUqH5Ca9+HYd?`VPU!? z5c*oR%!mM0iYZK)!mNKk$Khj7zZdyysqFJ2>K}Lcjbh{vGBYEw+-4?%mIA{KRN9tn z(7r3RsYyiKrC^FSc0IJHzQUcWtl(Gm=VQo6(@OVdkPgWqxzy7sz<0O&nrcgGy>wOL zMp+{dzvZ%+5Gikkgk_%zg!{YDwwOLt36=@?MKmKsGrkN~vtJ23+^f1@2H_+cyc9n5 zD!pOCuv?>bBlQ8HWCv6Jo%UC;A2#3SZmxUoNu7@h7l_hIT6N{jurX0sXBeRo(mH2)yU;Fo~4i&&Wx*-tPonsT{G*KDwkq5jJ2W7t! zqw%5Q+i~?-oYw2gs6$P76cK(yykR!8cs!=z*)J~QPy=$Y!T1}!=Yhbc9TY>VaLc}& zAIAfq(`(4SthW++_9S#qsnG@jHql0e)HkxiS?Es^6w?~&q*LwVOC00vUMqp!u`IEh zF$7d)4EmV0@k5M3SAA8^5>v7(x1VHFHJEg?I6mrbu5@m#m3JEhDQfkbc( ze;n(*-CDd?;?B?32Dn@2uf(OynzO#Fl$!zwupc3=*rK&p3C_2ElaIHPQM{yXueFZXR`o}O#|*`Y8Zuqg z)^@jJKh8}X)+tb-A&xD6Na$q2h4IZ5-S`15VFL*TMFZsg(O@PW$*%cL*MqizGJ;F7 zu+Gd$!ugXX?lw-CCoRWWzrrUG$pY}MQC{1Z<`SAzL|J+( z2^zMqqH#N>B^FWUUD-l5FGJz-SFZ%|VnHqkDPdU9g@e>yyHm(F_pksW6z5vQo{*TS z$!w?HJwDD=wd?2F-KS+)=C|yqN9Yr93F0JYgb_fj2e8mGC${d} z9ND?SRmCAcL^=P}TNjIIS?=JIvL|zSWnDNOvaNqAsrHUh0N1 zZ%FtM;d_B`g5>BTpp55R>0i#9y1khxA^iu!gVWnwnrI*w-j`aev0?uoo|+m41jA^K zQ>$^+0GZFaG@9-H>gCdC*!AH88ZeNVCp)+s9HG*3RjbTzFQhP_IfZ_(?a^JsU&&?R z(6Q$3xODn~RnRs)iwFTWhXJ{3CCJ&k$g3%+|2j2gBeHp(gadZa*Qoc-5=&P^IEBjE$5_}P-ce5I1mIly8c0H-`lMa49QdLIQeho z!>^-vJF5-P^N$vyZHzp})z)wQ$2>wAjY}_P`Ey@p@VrRygyWiwwXRDEelm4tf@1)| zf=+%sTQQp8%PtE_Gwok#pLCEJWb|Z4lTN`!VPk~;ZUejVMk@v>;uJj&WI`zWG8SVu ziP1k8KML+F=fx|z^cW0CV&+DJ!+_q|i3FT`8R#+>Z`p*7otHMlsW!9b)tST5$?6d{ zW%MviVm88RR+a!xq{3QirgYFKO=F*Hi`JFnEHDZ=7E(v=)a6YKf++e8xx<) zl3`|7XJb0XtHCzHrZ{fHr*ESDcI15SgbZ`myx328Ag|mzzhU*+N<&i|n@E7Y)kVPx z^d5My$Hlk^Vznx+VSKHvfakQQeZ-?inSqVmFeY4ty2LfNAC*0a$gB(t*77_^a2X^% zkF;VCp+4bHn$omJ$r%UWmt0)o(^5%Kni8)XIZm45f|nu#@RI}#BW|1wrl-REK8f7P zLr7BKnxXz7bdS$^E(l<`}E8HryIuk6lo%`uob@!Go){)@f4 zZfo+7|A&9B*chGCjBXsA;^>Cat&If$yxFKfTia5`8)k(L;odpBgy9PXOZoKm6>D#_L`Fjgr z<7Ug+X4j`1XdN81hCNx0*7~9WMe=H^C1{A_zKPb_rN3|aNoQar0sL5umlHp}zDNBX zcE#G=czdf|jDh>Px$`~Ho=N6D_i&bfs$yURu8?@MMzW@(X&JFi7<1Ds^Iq`+s! z{pVNXUQB-4IB&)4od}<}VDQWsp_lc}+uPSM6xJwwk8>8TxbLGX@HsLj)^nv@A>%6g zjTFc=-*K?Nl<)Z=sk95zbYFXe`w0vu@VT&kV{2&R1H;+7ZxsWpvWs{4u}?H<3UwAG zu^;MQtX9ig&JR5FHD9qQoMDO}R{%zFgA28NT1@75 z3Z`W3-+C|`>TM%;jSUTal+HfzZQMQ@e04nnDCIc&+>(WP(f{p&HT8+f(@!?KEpymo zby)sk;1>rImmoqh02&2p6!=Wb=ooP2UF_u@<2y;;m!%)ZfmJQ? z$!0%3Gh2tDf8L9S2%s1YZfsN`1kAMv)NxADsylGK=OZ$Ze0(U z?+iSCGWe7{H2hzo8<}}>@zyzvAl96EsV~o7+#jvz4|fLu`!?L9K4-P z`_q1gqt@1sIzfjj|dhVTcxoGgo z`m`ZVv6cX#`&=N~C|k+c7eOM5?TjMY7`;pIpQgCzihm!icwU()pmkX`Jp`?c&T|-x z9;MRdfiD#B&=a4B6o#sHh2FGQtU9lEX)v0DQNT*Ox^pDuM;cK5@qsQA{l z0+)~^vy^Szmx$hP7fJ|h&wduy+}d2+H&DIA5)~&x!))(=@cSf3&fu*QCnKO8QAOrr zOU&oFHCL_r+AyXHk6;pxz+4J2o&c62)3G?H<<3?u&)v$Ix=WTk(BR4FgUKbq*gKy# zH_}a-w%*-g4yyzF(DsgJ-1MA*)fl8x5H(WfMg~f0;Up1TnYVE#rV+=D!mI&`>MN-b zk;Qy{XYcL&nlv4TqmAMdez>nb_&tgFoc5#11buD*HEay)jHldUccoMnWKsBFc0)WVB#!%)28{7+aL-Gpo)2*d1s0xbj>mrf~P#IE@8y)wx>8 zIsO^=XG(+3x}Dy*IXR^9NfOqn{0CFR}K0%(J^~e`VBs$`JV2 z2AmDAR*N)e&Ef5obp=86@j~Y$)p27?t-OT4yYrWD7*1_()NrDWhYjnfq8M6Thjy#| zi)#y83xtkWfakZx%_7DGT;AdrsUN6DHj9DJHaU)BVOu$!AV{vDX@F|FP zX3)#OFVm>88@ivICOanjnvEL6e054JuMB)$yYg4pVV4`JB`NEaEdU5)pTwz)yn!0Sc*1hE3K9 zd&ODmrl*r)nMt@M_G{ip`XQKLqWMX zD@!0`zN}d9Ia(~Y#Jf3ONv2^`drufLAJ|9*Awg{Pxn=bcep^$1gJ2=kta?R<=H8Ee ze2L`vHPM`!w_^jcfkTDvziUh8p2T8-YOy^r7p;N%$sHBXEhdLyK7-8<7IF zsv@v-h0!6ZfRtM>8Ldzn7YnFGBgrM%*ls|f<}_E9=t4w1=tMjfk53dv06DnXo)CdX z;ml8ZGpjDzmc3nXUM(Cya|vjAeiZR7*X1m&!)cSLQ)}9_YG?x!L!M< zjjF90CeM%BqiF>RxT2F;myLVZ#x61*V_q?T@;;Nz<5mta%5<6l^YTNusXc^r0ueiR zetqvq{RFVx8z7$sA7_ z?CW~YT}kDC8qUgo?afV~sup}T-&nrE7H@K|gP3>txs%l=nfLGCBG)ZI$tTJr&)#NL$FRJF!3oO-R(KGHZ4 zEm2VBhJ{hsK|-i_*~bg)7iaN>=L#VSiubQwv2vkNB*$q>f&$s(I#~HJaV&U>P|%{1 z*7>~;x2T9G$=9U>h5c3Y#YDMZ_Lwqdpz$m@o!P_c}{(b1n zbR<+<{K$X-OR%ue*K%R7pn*$bg1*;qEl4!R^ST4qNp~@gidmV^Jqr_a0%iTWIp%(y zs<(|5jxL(xm{gz;$P1{t)}-K|tXHI0;GKD89@ zN(sCT$kf+!(;QKIM%#11p=pE#+Y{)aLh;RqS4@y5_+R8-38edgtx9&^%;9`zC4gJi z=s9MU+614&zTd1-0=3!w7!W*L{tGuyUoI4Qa`c0=StgT#AzMgIiT*{8Jo@4gC``_d zOpo3BdF2wuTOnRsnF6U)>0Py153Br{_I0bV@Y%zppN|D)9b$X#)of@i=0CHkgYj-< ze29iJDG#_zC;pkaapp5+2W)~YTsKmS7MQQK>?#IE+6!G_kc1F!lWdz$<8 zb(Z6cp8m$ZdFifW{h9nc9h>xm@$yNKU+?A@8#(TG6%5yWbXb;2jA`a)|1d?|7b7mN zevN)-=moi5VGDWj0~!>5yX;)R=w_JC&zlceVsrMPVM{Rw=kBP70WryUcp7=vJCVv1 zv9tY%GbcVDI3GZOLib5BE{ zg6ikpMdC%&`NDAUKVZNK4}3PFW$-6#Z-Nn$0k7*Z@+3Tc?`_sz$K~7v92Yo{Y~RS7 z)+Yh_ye|Pt1La~9eIEujulZY;gHZ}PhkHDc98!wsmz5 z#?7us-rc3R`*p?J^%CO!Q^p(oKF*t+BUv?bLN%x-X_~N$SCYe>#oxZBcjo{xrv!i0 zk8@0rD?UjwsM0ZHrm>%hbXz7|_t)Kl@DwZ1pfPeG&n&y^b*|__*2V(=il@~^2!;{a z{r)>{gR&y-ur;1Jwx`HlBTSQ<7QP@t|L4AVYP zwl)!FP#uHIIVMi^W{k107lU<8zbBeY#HAF=*`i?U&Kmg-Gu=GzP@IwBU7}8CI4?Tq z=Bzt#l}Xe=u1$ict;*?7y+cW^?`dQ9s7<{1gf9!3IO)rDk#ZBB>UkXns~@K+V$NXL zCjMsgzf6R&YUG4c+a#(|rG-?Gz7cp)ZYMm80Qtt5uH~?9Zh>d+BoyGR@_O`HHB99~ z1CAioof&!VPT)Qys@77?^s0uGe+K|(>jQ=2sSyyS2MVBQpHQz`90??>rIe=;qF@S~ z`?C0qT1HYR19vK}x>Z1q_c(=KZc2zu4mZh-^Wmo56!wo3mkc5m@?yd8s$3!sm`W{6 z)Sh2+O8z%qEOVV`i@pRybqFeSRYGL_r1HAk(#~b!MFRb_B{_YJ z``^pju{6UgG~$?hgSikzAWbpXu5Pltp`^Tr06}6P@!R435Et=%wEL{`dXvH1KF;jP zvRtCa7H#=3H{69>LgxiUQ_3fmbB|5qYx^98QD&?GY~0=ztW^?}55U6Rq%Zzw$PZ0b zL~?@9EEj_`t2e5gDiSws1#~;fT9;H$#FrN92|7_A_R19n)Jls;s1u1+ZPUeJ48JqP zX^hKz%nfG4&~Rc{wo2GE_p4NS?84NLC<^HNRavg7+OY@KF~Mo91ZVlzs`?{xynf2@ z;Xqd+m=B1-eSlgKYqs$6f~D!2c3^K3cyqS?Eg+!fbH1c9; zY@)(@r1DwRK}6*3K5S*)j154}6l{;fQD)O9CmP1Ih1cah8 zs;U}?T(lqXL8RcftHGO7g9YPuq{mh8Sa+W;zmf@|JlyAoSTP{ zIoiRFMs=Kjm2o6Y=Y)Yc%_7JSp`y3UKZXP~uS&$EA$PHU2GX&+=-OVMM{~>fI2z@^ zeVXFfPN5QZiS$k{Tg#bv2nf@d7*Ac*CMmli-np`&D3I}IHM9Vj3hC&kHwvK4E^o!u zg@^M!WHh^GQN8^L@kmA19P$Xn=0vAzhJP56b0(%N4$`lydc>OJqm@Io*yA^B+qmwq z^(OE=L{^qay%Oz7^R6a?GTTW!`vmX@2Mse~R~q)BNC?~B@Go80g_m>mL~Kim$)gT&jcbSs{QCsm)^ph#IYa z1HABh_v1u}_U^G6kBi*WuLR~iqX?xJ9*J*#|Eq6a;oz=R{02+>m3#KQmd~YAg?{{XFc(w3| zogSZT)6`4IWyJ~I!`Dd6w)sEka+dPu7LUekHT8xKN4%q}4($+iU;HT*fNqZ=998)3818tRnQ06$P+Vqwq_lD`@QHX{h#{yua( zD?n2-6Qyl+r~XBaJ!GHn<#+9uH`%9NJf5UTJs>hKRv2*7bUPk_D=zE~fx*v*lv!q^nOz7WSm(}W-fj=2WmRo8tT?eSyKD8~2+=L>UNPfoYOoAZUE#_cG1h zU|OmH9)<#QqUTjSAQ}~~U4!OSFq|sPz^`cJqxhyv;&lHU7fv>qj4LW7D60^Y`R?;%{sP~>>gvR23|Q#6M)hZ6 z9YjPjb$mL@wcoi?@pp~G19JTVEPD9am+!CsTht91Y-*F;kr8ZXSSVnZS7SfNNKt0X zD|pC0`XmXg2uOD!*Ei(WuPe|j{c_VNlRT(f*wK3Ryh8S6kgN#Ch5-kX^dIdFvKV@2lV zS2iw zXcKwN>J+&-ne`fLjVmZTBA&Fx7~aC)2Dz>uFPKfskAM)TAdxEH5LOmX7TjxO$Tddi z3fz{2vM8oxrq1ir+6;_|B{{2xf&T%=aHvrk6+(Lei$#SBvy0|rJQN8L7FMdSgUyD? zbKO0t6~P9@>d+O7Q0oxnOq5!3L6A${91cCZj!s5?_w7T!`^^)qh4;PF`GFQsP@nL| z$9;nrXH2bzBJBp2ZGJy937991-dg=mFg z9I|OV5MmzTsflIkoMUt*R2p3WV#Gp_27}mv0IKfs^`GEdOLst(AJMr#m#b^{ARp9O9$B$(M^td@a>PhsyKrDoU-`9BiC@!vak``qCO>rdcP)sf4g|lM4icovi znFLOd$qIFRPW|X|a%FJGu~hAk3%a9Lc#|}y?aaG%8Jio?cX&VlQ6*RhiaWng6bzcA z1uD{;C7+(a7TD*|ygB@*-+s3#btw&AiPi~RE@65nDEK0#eYxsJ+P4oU?&9+G-)QNl z6*$;rHRe40;!iuQr5J>y#5)YuFZ~`nWacDES3UW?f|4nHbg_*Dv*vI(cKtJvP!C*o zptbxxQ(5VbGVFZ^??3B$}cgC{Mxo>`c3wU$=BS z>k&&OxE0|xRDxq-gvYv0To#%l8Qdr)uY2D0Vlh}o^y%mXi25CA@?S|yDZhyl}aKNLwg#4tLVwW`*HCEvoiqF)dtuQSSDqhMhM;9@}}A zgE6O9l8nlMlPkDyKWQ#k6BXi4@b%hE-jj;eX9Y5UElKY{)o2xN9~Q0#0wU^%xPa+r zLrEdWj=hm2*4|Gbff&B-1U5k=E?H1SG*^8!wKk_$Pf`XwoJad6l`w{8)KPz*scx%6 z5A}#8WMFv1B)#>TgWs=kI(Y{JadL%Q_w$Um)P}f_5rlZXmIFuUB<9aspNdW&hgjUz zWxOh02<*>tha!(2B*DB!r5ehqV_yRO^qC=aNXkdxqgBvGoYYp;clr;|>k2_WpKD(B ze%Pwa)Il~Sxch%PS6%F@xh9kHe(_Re#$9CN{oH#}_pX)JH%rUO{@C)mUX>=@(wOVo zzth&zIXY(EVOzD;N~Y0juJhOk*sI#VUsUY*6uG-c?6L~odsMnp8rO0$WOnc2x@IFs z7sb(BL^}CbaZu|UO{1OrnVGk)_U^M%>r;~Det+=XZg!ifjmJ|uo{B*KbUYoYSxYmK z9cv*~anG2ahwYZ|&LY-6uSrI^bdN?D$@Xq#2cjP|%yu%{fz|5CH_l#MEIdcii;a8&Yf6a4u zL@q>(O4y-^(_aUFAAjf=lgpI`W<0v@(u_1@J!8z!K8Bl>?_mU_;IjK$^_xhSP|F)!X~lCq7=_(8-_GL1n}|w`hfMvJfk9uUiXm0!nBf-IAun0qAsBsh z;mg%mm@TfD-g-@sz*AIRK2%yL{>*600PfBmqJH@Mi(4Haxkd4qzxF1hm(khWja6i( zE8js(p3Fk3qC$Jxz3KvKQ%UH2XMwbdu}IO5yCRLKN#W1B17pc_W(K9K->X#b>3YfZ z&o$BgI?WCN5Fh_7&I78B z%@%Ie1opgYeWm^b&)}E>2$$)U8{Y#PU|rB6e|GXsuUDeU{Cl>GE+g36b@{#JNsbuU zW9^jSjC^~(0p!8(G7GWr_Sxzb)6KkT-+%A(XHlPN9QrUW$DQ#*t?Y^{U;;fR@#)^kW;{SL|0*LknfpXKiAI^=Wl3 zY_TvH>8=x=*D6*>{aPqoFdSp3Z%#CY)I`|~GmALp#F%RR6{B8Jt8n}A^8Ye={km~0 z?dGzqw9=&OVg~0Z*JGscS(W0VV^868e9g_(saJlEm8P}9Blt?T6V644?**-s3G5Nr zI1>`{M?yvP8{@dE>h)rdJ`G;n3yTG53&As9sD!uvBHd%to{O!CI3vlMkioEhh<`O~ z-JeNKTd+j7UBJAZt#DwSXwx0@u+BRuXnM)x1uOWSwv#gBi3*A*te20kETW>>i4`5x zzt9!rrAtlD?CsrqPFKo?v+bRV|2cT_dY85t4|c5o`LusDNP469-p_vJ&X%&kh%aTA z{}eI>i2$TT2)*9khLPHr5SX;`;)55NfkSmqI+ihNWZJS~hkeO3%>|?=V`d^3kDJG? zLD=#^l-MnSTC%(K*^C$a(oETBLmJrI?FL&P+0goVg>93D58}Hg5eo?z8tn21>2WG} z@QY<>*;v+7qcg~n@lb{)jrVfSktdq&Vew^M3TGvED$em{@rROPwvX>~{MswZKkZrm z+;FLhdi$_cY4)=kT={u?w<540ZJ_^QE-tnGdvW3)zg%I>R~L+CTIlz-95Foe5_g@u zr5U!Y6QYJ|7*nD(pCIijdC2VOj^@;LIj5(ZPa>)P*-_Iwxtd=WS+lyrqASwOAzDwG z9EY1zzw8PL{O-K%+iidQZ{W_x-T6@g(=IXhO)c}X=@)Oit+_3Cf^^bWH^i@H|Joh6 zv8MS(1~x%EGZT0gKBV=;<;8OoQ{>lZyCSk6m#!7RM=|DiSqG9`xXtfJ6<)CX9wRZ7 zJYCWL(Co|mSsH}1^Ba7|n(79+`e&Ke*MsR0)H^o8(=qcGOM5g1Wdx(;0T;#t)JVX4 zy%6Ked{&3}uRFtp#juz2TH9<;n;111dw;UkqE#yEXEg@)`FV4j4k8A{-thWW!&f^g zCKc4X5shmRFG8Cfe>lX>L@`avUy=I#p*;V7@v_I%G25ncdg``^hm=@u|6%WyTy`1W zpKrNBPo7MLC%=hWG?~DHDEp2y+O+WTlf?ewJ)+Zj${p&}!;3ddB}EVO=Zc+bD=`%& zOy=wAdw>}3ECot!S=j@z{yOUS$V+PwnwSJzGUy)!5 zJGvpnTPHu`5VO-M8gVH14(LO&QvP1*XQ#yRN9cC$tPK({(}TyEJ%5VsI!3LQhR}ow z86Td7%ZN<6UCHxx&9}Tsv{^jYO}0CR;~tIpJOkW8M;g^P-G%jChLf#e>Q^4=Yar^? z1R$QO$2M#co^r1l)yH5xLKk)CH4XG#Z;xE&_xF*D)9t7-pjUSO8}Hp*Ya%1*FDS{u zhrS#Mgx-6`Y8RGJ_UYO<39H3Awha*GxU zbx1k8+8?6W)Z?1xdE;_KfNi(G-jU4RV8UE{q@S~oVC@CsYoB05pwR^EXdXWrl01G4 zQgx<_-AaDBXqPw<;uV^r91c$FP0372$u2f$LZ>p}Z{%^M<`<`a%1Lq0Pc3i`Gbga# z+e&>flq#*9Ryh%BPD-mzVQN%Q>kx`%I!en&q_s|@9b?iPxwtwbF7!L6cSoeRs53n^ zNoRG;DCJ6}&RS=dGhUoz%yMPEQqNp)&ZI`nmy0u3do$OUGvA(MQn<1<)U!T1XMK*y z+A7Z4>CM_(&iZZ*`iF zk%3Qi$Bvr*^M+@T>g{CQ$R5g!p0@2Mg-WAPZ;Dsezw zy|3}3?M=^@rRq1nKcZFMoV|z6n;I=zXu#HDYt1Um3L2kh%6L#|6~=nU0@X~;y3#|b zm1f@yuAe5AK1}7ipN$PYMs~}(4fq}Ih|%5Jd;S!AVTYbujrV!Ql`mOurh6ZF4eDkO zCSi+Luhhf|UVA&EanrktM@9=0sS>m~-)M8j@#|-u{}rA#`K%Eh zYs;ynbVu@Pich_NLr8H5ZJ<{`uxKfcN=h1CxsXLpjne$_;q$g{Bo$s87+_{YD zXqHHStu^llVf}l*zC{ityT0Yjyzc%^L^4QdtjG%b=diSLR>Lok!}{J{)cZ2y*MU75 z7mj9m<^P`jjA3~<`{Sb>$LZ>;OH-OB6#ZH6fF;{!vmcr@+|U&L%Zz7d_NF$!rW!~k zC(TM1*WSgJ6XDqm%mni88eDRp9FW5x6sw0iXSFFL(c2Nv{HNlN6|wh)XloRFWzF~c zm@XYZeWK7GeqhiDbT)SbEummyY_eHgRxWQQQJQ<`X)?NoM;WTl2)-q85Fy9RfE>Ne z?|u7G=|TV7=$T8PGhLQvSD#&*5?Q2cGkLZYTx~i(FxLgOtveqg#B@!|nRS{=55e~U zBxdjRp?B*se9;^Fn=XfM+xb~vT}pD4LG{JeWiBmEf{swg5+5xsIkjA#>6_hiOT8Ww zqp;^^M2TkW@y=oi1O=CyAA|iKcz0@jyE#v5&-Im_MoU>v?s;{9fbd4eyVrMWXXSsK zo+)DDmxt}FwETNQOX6yDrbaZ6Yop1H1Y6hE5V$I1Zd(uSp298 z4rL}VwG+UX7a!u40g2X(A7yO7?Tg6zYNg{W2u`k zyEVP8Sp+_l-d_r^`-TIiTtm++oIbI_6pIPaKx$^P_oxn?*=*rJfpFR9-{?G>lqU0q zvgJFx2rsttzToLn;BvdM(C`b7S%XFb=n;FfO=gQZH=0WN5tul~9RBv^6^oqy=pek# z^5*JtaNjo3)Sus+*4E6XC(dXY|6z{ZFLoR(&!ZEdiYQsL_C-@a9tM8_u_aOxAj|n3 zUN+Xb%+sPjA8%eXOKA)AGk0702gkIvG3I0_J7YEc3|)V}b9#n+)r<$Z#vc`n=V-=> zJo?dAmDz4j4Ult~kio+KjM2mFm0gh&*al=r#P~IFP@U-ogU$le=dXFz#%j}Jf`N*y z4?w(*QIQ*!%G3Of-8L(N0aWiK4TF=M@OzvL&WS%aL!pu38WOaPKg*jP6|QM>!rj>3 z)TXrPe+|;3I~4A{~YLn%2DdL zKGWAogPG%T{B-hE2p}y9fx;{?XSMQXROK}TAy-SMUe4+4=DNXxV`6b02xb_ppc%2 z+V4g>a0C2q$0;or0T>(l2dpjo;@6iJ*SXR`45^)Ddi$qQ>u3Fd;jGXn&S0#npl*%L zwu8_5oPOUZM7WB^3m>~eg;1F7*3WqWj!-yf0PhK?dBkqw*^N6!Ox~eZ%qTE%0not2 z9V|teV(t*1$;$#zI1Z#e2hXTK^UgJlhBW#z!F^uR2!8I8-eR$LM~5yofb}qOvxc`S z#ei5q`DK{jLp|M2RlbakOL5Qm>qj91Xd0SX!M>&Vzf0gq)nGJ71dN<;!Nh9=CMJr- zJ%G7|Eecw5#%M{3rVUFQfk296tAd~QR$Ly61u$nIR4zaASjeF57N2vC4>!TeR18Ed z!~3uR_D%uLb9w0|UzffsO>q)p6c2G^yY=Ka97N;#_lK1N4h#n%+WSt1H6CWKu6{Xi z-M`{@az)tIQzE>E6OHx!tCAw|3`*sfvS6W;`m*nTg4Pq2T(&}g?BAMIrh!u+#$>E- z1oe(M^#O)dGCIK!d2yh7E*r3)cw9H5WBHOl2$qXH=4p?(cuPF$elgIlUKu8)?l zc67zD8U?UnAbR^*2InBL6lZQ-m2wV7T)?aFAFA5Y?kVAz;V)0i_PS~64M0<*<>c~T}l#~o(1y8zu>%huFutE3Dhkx9;%N+$VCP2AY z3i}(dPn?38$DrSx^H!4czDoizsik-NRG3L{X)>UP0+P2cE0JJy6F$76hT*CurM4x< z6o|}g`=AnNc;U5v$y=3U*O7Rc&5s~B+LzQ9bsnGjj61LE)Ji21;7ZL?z(o2dQzNe+ zJ;pNuqAZ@g%9h*@&=QX%+#X%KzWg?!W0fjgVu4@#rcEMufATiW1 zD{$vi-*p`zui6ku3!{oM(0nHl2O8im36q;FqlyBzY1LG&fb=L)UgBp(MpAZgGQ91m zxY}6|!BY{n!6;T*_Gz-jb}{vQN-FSvIStwO6DdQjnR>eW_1XlT3jP5IW<3Q zO#ghc|KrH})P78_V=G0qxc#P@Bkp=HSCCIsz1w_*3%Wk+wDJaz1DJCEogJINaXC&R z-c_CP$iL$DRFrQoPIx72`?yK*6U1zV|K%;14z||VtelnHASIoxqFLE*+$3jKN$rd~ z(XbH4fjeA4#$-S}fM`+zlSE_c`r|H#@n(oImigpel{l;S_ywjiFdfEsD<*M<*!)T! zS9&~DrRtW=fdwZ8@_VV}i$VRERJPPqS@TkzgKLv~6jXrJ%9Q|-q8=zpV&?;h^f<5p z>KZ_7J2Jc-yT$s6m>Do0CXKlnt$9z0x$?3mKH0V06!xE={e@;YH9AFvI0o9j1h_As!L%OrWahIrcf%xlD} z;uut040)XtsL{%FnLEWDio6h+U#)6dm1hC1g*!EHREPg+Yey>eThPYvI}3t`H8^tY zIz6alk6Opo$d!iWP8Hd@fiPIun=zd0z*(2Pn9Y>twL25hUS&B6*B+{ubvvxqdzRLC z;Gx&cn%t>D8H_C2E~q{?&=*>Id7sck=m{arr8kx5@rQkW8A9}2IEIQbYhlx-Hj>kKNO5|P(0yG*& zihR)XAVGvSuX%|CR*!txV%#mCTBCpiYFEGz9FRKD`^b#?dH(Bs6Gmxmih^B8EoGBY zQBw7Ck=@wzFv)-c7V1Jd3c}$Na+~u}phnND{w_TnXut463!Q1?D6a-c(;}Zi>~o=4 zf1h_cfT6(TXkZvjr8saFEK&6|Ve08#7&I2&7JU%nh3g1TCqFZ*mul|wkOq_pw~PUZ z!2Wg4Ks_km!!!+`emC*;6a;0DZY?uv7j|6Ue>Bz{&DEEUB&=3bq##OtVm0n z=7}<*&%ig)k&DS&&anEf_YF4jlA#rA9&{>bQ5uGe!2eEO{AR zm?39rIdj*VPUuWAdSD0FS`7`rxdE!4F(xbxW!W38KQct5-)mc{*Bt0(;)BRwU8#ve zbB&3_hffq{qqxGo4b!2qm_fgT2{Y!&8P?n8! z?JZ}n%utmFLNbHw0{XrUO#Yn%90-#f_<(6{Es4xdRXH(v8r)0gpz`(#8N5 zgy(;+%yEoE!6fk8KQFp=;TG@mMh+D$9f%;yemph%0>0OLwybXoadP?(%Ux2b~*VY)w% z58*~u1v)s%t9%SEH@F`nh_PwffC^>ALuBy-MB_MtzSWnVn*Mt+Q=~_Jh5|1{rOt+> z)|7KN2wq*SE?8B@+ARevI|+lmaIb``Zm@V`+xXd~GsnTRuO(&dCe3C_Sy!BvO-4NE z`xQFwM9fkRm_r+wP=1H=*w;wxP+B-!!|0o?U^8J7Ocj<{J@ESG z^s;12r$G6I6<5KjF6%=E-Y^U&X4)mj1%}#yp)h@gGxJdzkR1lQ*Kf|i=Lyj6Qc43< zX{9Bip31S{p$i%f-qn@J>8P~rdP5oLT`qgmYa_ZyNdaB@Ge=J9zbtRJ&O;D1s9;k5 zMOi~16%Gj#;3@OaxPx0^aJ3LbwQ{%A%;l$i7O&jNe ze||ItpnsKJ6S}M#17?48BY}nf&h>L%c&Op*fCL%ncX=`=Qy;ig_JhwM%@GJ&?bo_( zqYAR5b*SKy0BY*$E?*P#nw@S{>v?L`BCSPZ7|fKq| zyoZBR1{0-ux?)npkmY$ZUv0bl8e&P*wI_v%!0oH;=144=rK$u`m8hU%2QH~nKiI5!vbb>ALKlr|7W%+98U{9`y8_{M zuR{ShX0j6W_K#{PJL>Hp0j_Ix1qxb_n*t7d;veOv;k9p~wi#wdd++s3TKTR9_bW$g zpa_4d9ScO53$+XY2Z}{OsLYBm0nBs5jN#HAh@bD109Ue|5Ca+FOvX#i!oAQSMG24& zrh8cwn{(^7##NAteF~kbIOB=R%K8! z^xOTqr_z;h0+>PzlEOUAdm)b@j`B?}sD%IULcN#5;jdV~<-5b1_Xp`c#`U=jZbAFI z?iu`l!5Akr$c5Sj9S%5AK%0puqLfQnk4@oMmWkU?(8b=?pP$Z2+Wbsu@Tvm0g@1IK z0kT~0mkmUD;9=53dj2FF!z@_#>PL=!u)oBnG!BAvs8Ol<<@W9u?j;)o<9|Ct@xWc? zl$1N^8JStx|Ajp7qyUMb2UE!Z9FW_vTV}s=Xr7SJ@}Q z5Lv_g=zl_<{sMGm^#Z-LF-X0X+U+;{N;z5IU=K3<01KM3= z*jK1_6z3DpLKHh@(sl=aK|E$df0)SO27mp;MzAu0K}|ZVCTd0fbj9QdqePUq)cjL= z{+)Dn{iIAtEOw?Q)FfweoM;_SFHNM-BJ+}Y1`I%c<`sfbA#oVHhuiasX#$xbE>Hpl zTifiVIFfvpfiIT#DN$&P?+RPy8ZDCmwGH+x_^z|%;>n4^_h>m=YkE${65Af0_ukht zNt9J2$-Y?N())NQE(hy^1vo)$8ndYf-RThd%OXZaSuX|aZD?CT&j8oXw)qh{Rz8BB zZ#)GT$8g&)VbK|GLae%QjrP5T@{AC6i2gji%_zLW#LtEC=V;z+GGNsBCVin1^Cm(YJ&5Vpp=@4_|8XDMoh$3VRA1c^+!_)@Mo-A<=#zza;5-20okgn{=%ifuWZlr zMMw)mO@B%A=P?{DvXeUtYRxe-{qUnTSCyp&nYBv-SK<@EEX7I`x9A;O5`al@P8vQ=`fTU8EOu7m2qSHz z@~5MGTPwy`Pl$%dP6GS)2~lgUg-NNkK&f*gAK!=6(;e0%vN2+bl~P;%a#;wKMv|w!z> zkM!tSOmLC_H}y$c&2Ey*@0LHUVC@gqI#8Sm{d{4#@BWVqnbOZPLq2Q&0BwVDzN7{SS>Z-h<9@ zPZ0P+618%1yUKxwZ=#6#@b?Pa(M+N_5O3A^53hyAD_M0p9Vyy()z9>!Y_?woO?V;c z3doy;#%%`hQLXYaB$@ez&#m)p|@7V14~&8l_iw8F;L*9Z`ce%x3kW|J+8gwkU~X z#-#K{X9{_5ZD6RN8x4fL+UmTh$w?Iv0x3q(IbjKid^MhsR)1$f#fqv@wm#SAC>o22 z%D*&+=Wj9Fz_@HcEDsV5#N-cdm*!JnHh37z!q+q!ZNUK6Wy9wmgQ0SCB6(X!7>~po z@lh?f9`+<-RaFGcg=@aR7bC67O1b1h8LGoesY%QTh$FGW>=DVQfxbo8UFbPwEnRiRKl{h07YH82}PR^Z{ON00_K}kJE92#VBJOp|5 z$0Ubjo1OA{=kkSCu6C29atIofNTzL8-6}Etx_)?hGOZr-K>dYDkU8zXhJVb$1nhz) znN~hVazViC*}ewo23x+1z;`TxmJ3DeZ`tCS2PA%pJ!+Hnk8?N0IQ8dDD1~Wkmsg?m z+4w@}-{&VuXPDL@^0RnGI+K|Wpri^jD?Kp&to~&@4`#m|>2O0zj2+Pbd{p zo{a5_r`3snS}Fv7WqMbXsNdMveOTs0lru&XFA*Khn#o|!J!UcvkI9x3xhikp;;`EP z^U1d_V$pPpx)2L8R0d_wDN6*i=V#`K8o(^+h5jF&-ukb}|Bc(f)@&mN8zY6$EdxO* zade1;BCU=N6-GCXZW!G#Is^%kGzKV*A|jv|0})X{5k%)lgdtgBe0|OJUEq-Er>W*=jbChUk&U)bif8t<&o=b_d0h)IAc|ECsN(K}k;e^f zi{Aq89D?5+0rALzzfJZ^XRm>|4w#_#Pc0L5TO4$cz)6N~ zwa*M5)4Y>DhqlEzXz*03&zb86gT+G~E{OwrrW{?XNLsd@U*Y@6U#6hJOQDa<$$?p} z*H*=Gpmz7?tHfuoPOV3g^T1wNg39q=-AOXqo;=R&!7vr3Gr&BgF97+wm=7tddy)2~ zu<;c2D|u~NXT3`)a=E%C&QTWV8p8+CHSOaKwKff=N=-qq>&}aJB0&p#wJ; zt}xb(1c6b@O~UwhzV0#J>!kf&d^8}-R!yVE{rdA9K9I)#oSv_m8?*-N|bfkHDw3IC{t8!CbP8mn(e}X#U*`N|zL2Wcdt44>NJ0<73{|!&JM4 z*a3)C3-oJT66G+s^=EJD`2#o#>OlrL4*qNj4p7^98IVi;j%#Z-Gc)bAKcp295Sm*^ zL1o#1^D#;2XJ5vke)C!UI*A+GEs73ogrqpC8D4x~H1N4T2S`y${4Y^>?(FkMl?@lw zO9<3)#qZS&M68;#?C+=8-K6oWB$R_a*ueSoe48@+_&~>n!9Ds1&t*Z_Vqah2W$U0j zd}$~DtqdwgbS1O3Q&U4_?DXBJU+(dx34J#md8=G`SN3SXa)z^OdM!SShadM3X-kPm zyE!jh_CJy3mZqEjX#+NT$n=winx$B^W~W5LE$xl10XEIHu*Bg24#3YW@z`clA*gLQCBQE6ypPcFtET= zfZsm&jR*J%040&UlriTGh)_5U^3cv6H9(EzYO!%}3%$5eh zVt_uH@eE6ZK?e9RU{+1kCjx}G2D@X92>5!i0u`#0#I;C;`njf-HHE(GILTM=werr(Lz|?DB#!EWrmloM89!E z=Yvrk%ybma!|pjUg!kHgI!qA;=FNv8$Y3!_rtyc2e?Otp|G(#1hXO+|{EoIV1Of0w zGIwyA<;+tD?G3Rtha=@)`_p`dfwDhCmY}F@DdRy;fYcRU)RL`x9w$q7vHF%6rIF(n zFE2vL`Q~*3L-O0+%8?J2sM|WLzKPAb0CCSZ6LuFvknJ=v(Edpp90T$QhW#C&v6n$s z!ql(Ei)nlM*MAR+*x_oOR98r$E2!r+@wxRvhFuv0{&(=2Nn2t zviWb!5vy}q`SU{MxMt8{LFJ)=tqNHvCf&7q??&-AP$VJdLb4l@&q8R*w1f`i{RG>r zaq zy|mIAFEKsHQ5^BSWK4fC>V>;_Vx0kUo)2PYo*3nZw76C0o0Sm=pbP{p^B1J2xTq-c z!u14vkBK7NX4z9LE;|s8JY?sa zuFHcd<{m7`Oo(~2Dr=}DKu}#UXEMm0R%TDBwP(~RwUKU2c}g;&o56xnA(vg2jUN?x z2#4PIzLDwbUd^9Z_@7The*`Pch9d-3Xh}tN1~rScqUm^Un~4Ei>CJ5f~f*jh2|qk`@I#g0jzWbK^fmfBH>v*v z=Pt8eLcUC*rFvj1U?>7AZcXMj)2b^I=7L0jIYIbHA!PPt{{`K=qskHOnjOt=ul)_g zg{qu_$k-9EN2jaBg z&bw#cNVCDNc5Q5Er_ewEUGnD|kU3Ofdme&ONV*~>tZyy$9@!wl4~2Kd2>>@^*E~i? z4O)Jia*w!pB`D99viv6+%RlpNo;Gr}75C&-oEi|&pu$ARpjiUQX2V{(%f}~0VxldW z2JU$99ozgK$VZg^(gP{2ini(1QHH}^^UPM8I`Glg5j3z4K$2sY)yZp32i9;&Yu&CB zL#o0v)|9$XCQg3%))zK`p|{h%Cw>m^lGm%n5b)&p84?c8$4b-rTsIZ7IH~^2JZllKHCKDJ^{-3 zfxUHBo%$_N_s+e*ikm;rccbXTMq*$h=A`>p2lG>F$8a8R%H6WGf#j(!uQ5`vzWw{2 zQzevw8kpXqrl9#GESBPO8(mN+k1tgKxaa-hWw55-L5E#pyHqZZyem9RXKK@Me)MV3 z9^aWsi=PTYA;TQ6nGk0T)rcEVC;d-va|Tn>>61QCYs@C>N2?1o%NM2GwwAGm>5B`t zg(D*YLG-hnWg%Q{e!a%_2&qWJ(?-^4 z^m&i#TF{$FoIC)yVyab;RCLR*_gt2zpYdt)s*_J)h4JE9CuxNA4bXqQ zJ`JHrcZQyz`kmq#=%vw~Mv|H|P*WKd0&3<*=*(s^@+Qe_fJ$V9f%t>nM}{LH=ev^k zb|v-gUEG7_LVhF?&T??iA0gI&n>QDy|GvKx6Fl+nsl4>I;Vl~>?%`r65n#~_b%>nY z#3%Q+GY%#p<84nI>69&-RAQ8`HShn zEdofKq}Fb{1c`y-X-gJH^WXClWFgC~d0h<}^V87QNVb-+Gmzk;vUg%&*{W&+?>_h|P9{ZX7DdHixWgUMtLE(KLIH-2jwKd6s2ol)mv&@qU zj~v`3;d%ABNL0+fknnj5BG z9l?j$gG|gC*uDe^ex_CIFrVJLhOD4gTUQY+dnpo_??tB=^VeFGLW%O~F%sz7vo)RW zV$ z%0^cBB;Qk}#pB5|dM}O;`utCCi`{z}Og?wJta@NURp3-L^*x3LdS7U>YS+C_1U|&B zlioi@>W4c|SyuIBQQ~+-hzSN-pk93EhV|Huk#~OF8`kAokMC?c2deNf0!sfuk7MBG zA1X7eFXg@hMw+lY8t)Fnqt7Jwk)Ci(RwhUQjv87nBzR-+p6H-V!I5xq#moS*=Rxb5S#5NTF*pSm=s zdxUf$1-OKbT&NCc;dptFXB^O=2EBdjTWCw-iIeh&t*2S=&%^2` znAM;4k7{v~5z&)Po7bg|+BE-nD3u?cg7)$(lbxYgO!-7P74hh6II`_px&5NJbo95bm8@DKFO%|#* z-hULI(Bu8MTAh;b4NbLaG(DW|+kV*R{6?1soXQaf2XAQ|^PQlQxFS!NKBO@M7~J`? zR@GVGtRB%p2qoD<`R9CDrdS1-N+1A(j&rm3paUMIJsFR@KN7l%l)>&aLCI*^#psD6)}ChG`k);+_$Q$SmV8#>KHeVFg*<=Pe>3GtJyI~ z)0N~fzAPHXY^hg4Q3+3}1<*he-l4S2T^WDCWCQO^F0&=c?F_ogd@dz3V20GKmuZsa ztXo16Cc)eP`S#DctU?i^`fS(JQC_S`u%8_{%7JL$F)y`YKsUu`4>3xLtw|@;dY%`b z`6CR?7yD~!>HynE!bQQ#v(!3p{WUFi;K;#+o4W!RPf229t40D`*aN0zOtwQ>4vM?| z!Wb`V5-{LESkMyTwkzTUBWYs*VqGqB);6GM>9cu(dRtI^_uumf5^hS3up8#6XAi>} zB}wFH7|0697xYIUJYl97{8~xmNuHM^NM!^GHL+i@nnzPXJ9BcA8(vw9T}^_Z91W?D zOQK&gAsLQYVu=XZ?Gin>EDq4;>?4@lu)X7+5%n^B@%e}Rt31Z^eeqy(6sN#9f<6kB zl?P*k<3P#$Tn5`&;T*SL>c8-+nb+rr1Fn+37~fU{V^mj!YL{?r=Lg5E9uO$l3dzFJzxl`Tg6^V%tC()2(t=XZ}&{ zm+qZc4>Am_4MjP-3^75XK~{gIZ&NKfdrA z!%VR19uq2qoIPSEXfROhWK~R7JQZ2a2UbW{hEIQqS16z(`p6^IhExOc%m`u_Q71#A zMK}oXqkc_R@oKdKnygSW(cLDb(l@#QBAdmD47)oIz>XwqMgC2^dg{j6% z`fYe?Oai$n9=tNLBW9u$lE^HOC~-G0bGCdI2=!o?Wpf*M{vmBYPBUgbAQ5t1j4v^} z;}X|)S*AX!s_2xW_DdU-QCibVuK`il=|b+)zy$ebl?MN)MjDgdTTEy@Q$b@d4{J?= z>rf>jP}ed*&7~e!XeyV#0J4-l%iBgm`&tuV_H>>|@>Dy>0T z==cG+E7|o{y^C;+j856qEM^0Mmb@Zh1eX%>^O+4(pW!G3ysCJ}wz1*-D5KXb-Z$$+ zp5pKv8JrAcsuV52$KUioG=<5&6Rd_TJHs^BjfX zo4!tE-_JG>dwF(FvAgZo-7P5m(LMFRA02OosUVAa?00s8WU@o)W&1}XDUUjmCFb-v zGpH#|_kVOL|D#&;uLBo1Yn$FkN+J{q1J!#Ep&zDekEy#-!5d;+*>m2I%a7RO5;D3^ za!BzV(5bJDm~6IMfF2T&prAqXy>iFXA#XuaYAe%kWvrY{{$+uDyb`oL>E=<8)c2=Y zGX_zak{N!nag}hAb%rrr_iSM zTOR!^0U7n36NRJ;od8g%L*C&XzaS!iY{Vc}P5yi%3`qXcS6la6N!i;ZW35^itgp^s zz8ZSPi8YmhlP*Sjv96IryoQuD7~-atY@B9fbdLD6exW(&>-q(9r~FC;*Hs4x6{Mgp zPiNSW81cI9Qd7f$BfN_W=1NnD>y@(#n}bzAuP_1mRoleSKV(O>DbOS23`DM#ibj7j z5Zdo5zbTxAhVnFkj|HY%{iXAVG>L*I{W$Fy25gTrOPDTx+1HO0U%q>4+Nj?rEp5I9 zhcHOcVGQ9=$8D$BGm4dxis zM?&^X$KlfS-*}fbcGuY$I&b%gt=RobRTMp_A7wkBayL{AY-!O2rgA)prjeFzwf{H1?St!=}$o< zrGi%r4?x^$n52_enD2>v?X#j^+AGUWph=5AI&Y&_k2LI&1=sf}fcF%+>ytLV)@_`v z?jS(KfeP=D(r-cQrXQoIAzD}6#v_jwWxTXdKSlHxzdEan~ zd}g*71&yG<1TE+uw#}xPCDLzo7sk@;@A%u$J8Nnc+e|U(F2q2e=q;G zbC7oD3uM{E-i!)t(i3?i7>U=S5@4^*{?+*%>EFU`Vc1@?fBQT0W;ywn^q>sn+(U>9 zQ&Xi$qe2FZYw&;fROys~#m;67E&^JGH{>sk=jT6Me;1>#!@^qxbg}Oje)_^FFfFm>t{tKFDz@5Jf5qW+?nh~?X?YVaX zM5KpZn}D%zsc(nHmn_DMY*AEC1#|tPILihTe+7vVQ#>?Ml)SZMPbDO|Yv3`F7vdA- zB9zbMBm4)r@696=XpVmTLhqgiSEM8gVGyzNiRo@&QcDW9`?~(X)&CIA+TPK7iP5B9 zFnU67fe#8^4=o=^uXMPPc3@YKcLd7}l&0{fc39(IF@eTn!Z9)D>Md9JMRFWJh=t?Q zbO6JNSVE6o=RtZ`w}lwv2DeGHHlM8XDeSAw%xR4Toe>0Ek#M6=MmrOjW3aaksP!5s z`K@Q_tfjtLfol$cqG^s&=N)GzZDu@@{PCt36MIN_&h9}vKF?F8G+<#8B|rlC1fn?^ zpp{AfBiFQh8UdQjY`7zMjUPcICK=*#kM&uov4PKjpyA9yrNlw8cDcX!(X1&;f|}u_ z0zTsB#dN`Lj%4?2W%JNrT9_ObMQze6jn^?&+B)t;WWfxtQ0a+`O8sL(NOU6xwU~w; zAc2%jEnVn}HIqlFa+;aW%zPmh@t(&`qt&ISHuYjzk#Mpaf&i9C7k+wB;A(>sEjz!w z!tcPyOmpDw^rYPi0oXp~OYKG`sM1c9W*Mp5549ASvY(ejQLeoPaqDLS5&R*L&pI1-%)4-2IzK;MLHX<6cRlEA=VmRee%frNvYos=fy zNKuneFke=aE?Z^am2oq;s*_yG0|Qpg(7mnYlRb7d{NPw?gw_heogUX$S}jC}@4c&> zo=lxsvXk`|M-Y?JTS|Uw)=9bnkrM?lC@2h|-`b7V=O(^30)Ve0Me}r_*6GIBJq-Dp6x50Wm_-d0|b`UAO8p%?>+r( z>q3G-tX7C6Rz<+TuOY^f`{H_0@My!b9Q{Qq`#~W>m@F+dbs@SGf}%Gb*Q}JDkLQf^ z>?i<=p#ZZPS6N0C5e$MtOQaAH-WY3J-{h?D0 zWDh!-(QZggG2FfNy&O1mP&vI}QD$2HWeUlS>A2~eo0n1bAKsXl*aB+?ZFz(LC&QUH z-QWpuUoqd#DEQhI^Fu*l_VSr-5B?Uwc1oGG28CiM{vT6$h@hF)7M=KVg;h+~r=IaV ziKFiJze8SM+PbNKYEOOa_mEBT5CW@TwP^WuI}?o%AxGq%mBP*sopKxu(dIpWwcpmc z3zh^{@5=T?cN$0ZHJ%-4{;a3xe4F2UnDe7iD1f+qa`?t6xIM8ACwF5*FE?PNCoCHE ztN4bK_P}I@+UCLS$;=`BKafh=0M3ycOU{hyI?`VJQ-PX?zx+K2J0-9I>JnPJ_ZHnO zHw054x8H9;_MOCT&h*D--gR%e?_ruSr(FPl-x_cFVE+%SBv^#e`-~AT_TN?stf2zoJ7Ge7cqR}7tjTf2_ zt%ejvC1!;p6~OO#a({iis*B;)io8FjJ*K9U!gKA>Zi|6uSEK*u>?^y4Lc~hByM?g9 zrW`+Zb796Qw+{Vyc@^O(_&O@ij?v=YGd>;pIT@&xlD)Yct`}cw!>44J5{JWLy?eXntTO%){h(IrFUqa}rz+SfHy9P&(0z;(~nMq?7S6nei$b&GJI7ZQ{}_FX{Axw!?oYGm|4aAOjI{x~E_txcuCv0>)wJ&+bl3scoCZ{H~)`yx+h zc8swYaqfxbw7AsrG}mC4oze|JqalIg^ zpmQ@8Sbe=vC<}SB^BPA)imJY-pXsqp(eaU0=67YYS)-depb-e9t((VuFb-d~I5NLwZiaMYJ!mM)puW)uj zs*!=t;Xy!Q=k=wWYP$!go8KTsrb=Ni^uq@p_sGgI?Vb$5g6WN2&Po&G>ll}m-`6Rx z`9ZN%dQr@~PUd3iD}I2182!;~w3uvYC=j^B{LclFhh9DVuip>>DQh zTUyJ7?3P=6=H*YEjv%p^a>I5D@(0D<7C@Hu$Na$7%Lorf94jdeB_giV;dVxl(mOBQ z*han!c3!^kLVsPt!vYyBx*WDQ3*BRBibFUM#5 zguR($8eQHH`Y;-htk#<(>IgzV_6ur}sComW2F{q{W$S<7)B6 zc9+{rMPXflEDikeq+0VYmUbMdk=xiz7iV3^pT@4)kwf(a!QIPPHIju>ILMfs# zs3}soa@6vO7zq<)B5I~OS|)Q>cTD1-Dh~kj%iqp&KAT(L^`H7?bR0zN0z^gM!c!Cl$=Dwk|$@m=dyy)STaB&Q<6cD~~`ESPKUrA#Vf)&$&9Vvlt5MO4dqLP2O*Q*hC!ryuI^fTbkj3yeTcd4nUk<KPUqGiw;km`x+*YF~KW>0k^Tsiq9B?d|13!fqe3mmwSJk z!=<#Pwq92u(Xx(2YkpdPDA+NS03(??S`Iqgo$O{|`4~EJg})2YN1Q=w{+l@Su=s=$ z;>>fp+3oQ>HffKD`d+NBgkA7Vn_(WN_3eW{(`Fik^^40H=kr`I%?`9JwOqQ|s6mpL zA>8wDr6tA^&_pq<>zz~M=0$Eh#t-&@8H|R+>)n8oRvEs;eB#ET=h_E_v{L7;ycDGsU-}rHz^si zQsrzscluYOe-z2Sb>B{w%mbSo0QRCsP+5W|w`>;)z-ufXz2#Q_vGoqL#Bp*2k3qd> zBpLr>(xCs5HLAIVjU(CQl^Zd2Y1U?*dFd{{H*KO1BWXrA>PD;^vZC||2}sfV3Hm^+ zOWq?;hzMC9k7dl8pj7GvI8oGZ--}_EUTF=5-LR$%D9R=Mz2cpR%kLZPUo<<%>0Ap0 z%Gz}t1Qk8vGr*#;E%*^=aJu|x+s!EK+2Hbn{lstuVP<>{I6t-JTI*}Ck=R_jUa7{1 zTGGNERxiXy`PqKTG{96tu&z?Fbb>yh%F03$7FZ<&uH=;Z&o;c(DF1;1p87X){4-6gm`>UAIR{u>ul>MH|o6Js%_$C5CsWNtz%hZyTiFU9WxEOS3PmW-y;gu7+p@{__@t=HE^l-lK!OX9 z0E2kSH|}2Qr^m(9@{T?wA+Ifz>qfAaZ%=~K&RfL>J(sGcM>MkbpAJeI+cSx5A`Nts zy1fPc5W4IzpUN(h#=8HjpPn}vL!gR(y_)05Uc{Q4Q6BXsdj^LStxFOX{ zm3+)A2UbzC+JnO6?UX$J(mP z5%DrH+*!W~ZkqJKvW6EqE=R}#fQ_Gx`&e-@7?qX(1uVnwypx$@^@4e<%JczOB@o$5 z6OWV32lETZ!zp4LT=#u&jME(?B6IANMhaM`!A3L>st4k`IEDCq-u!a!nt_OFJT5*+ zyiQn3J zkwng)(V>E5Tl&10RN@vYrPZxkxr`Lp+-mLar&~NXIn#La-LzM?d*<)#?uffa0++RN z!tQ>T`-(K3r(Wg{IhAvo_w2iyT*`H}rTd{e z0qWEq4@{shLAu;et)`5C;CP(`ClTSzieLF>6;w)T{1A?U zM&=YnQQxJSeqdXj3z8ub64^~Hq5u6;u8F{Cs)&x~c)>Z5xMn*pEmx>Z#O(}^uA>Cu zq=UzQG^_(3pdO2J;isfc!+O;FnPGAJU{|9;zC^kWS4ryvASfqAQXj-!Te}sZE|k`< zr6Jvmu)lezZa%{h4sn; zLV>4(IiCuZ)N4|GZp3d5`fi%l?Yn1~0E$9J zSA2*8CkZ6n`07p+lTAx-7uDm$+D*MUch)Ikqdk6v-r{#v-EEu}W9ec0o|)+G&pG|) z&68BL#H0Zv&hqMSvHKt++0ju=<-@)3k}v=Dv$2Aix#k%4@$k5xE-#v64~k@>V1&FA zCf4z+r#&_99iMX_tQK}|=R@3sK=$j98<9*X<5bK~lQYMe;6HpvdV-IP6v9E37f}tw zSa>NHC$ED541A-QlXKz9P%?PonP1?hsyG=G)UROl4DsNd$g!>X%i=nhi*F9hP|gus4@WOS754etPG4NHEJd znNBA`M}0C-De39rdYWl2Z}a>QLSd}#9G;mKtS|FM?da@)K{$%wb#pR9s_wEzDB68D z0&N15+XDX#PmbIG511Z5`6JD_2x8P{Bu2~?BWHXXOB zt{bp7Z)GKR`IV1&KOmZW9<4cwWd8-VCFRIDT=u8uq^}_JJu+DF>oroYI5O+x!^}f| zDGOc$_C6~;dMM+W3M$DbxSSgw{PK90?eOz1c&%3yHPUP!|7FY3#&V@;4Y95fVhsyIh~Hv11e60 zco2v|CNx$l+W(dpI*d`v-pcOq5o7_byesZ}>mp`EHcL*6zW)Jy-a3m|&LtPhxi=3# zIRpybz5Xl`7t7~5CPiWem?#X;zU1%xuGoBtTWrxpha>|#D0|}yHjqoScgmEL&vGe* z@q@!LYayHjN+*wY#R2-bt0EB7HuY|^c3C9zIGi;h)A5`XnfWPrILJ6pfASlc_ z6z!ek;HT_QY8ms%Nb!rm^wNkpMdfC3QHDTT^8sE0*9d#uzk?MW7Fw&#MKv8&uW;8* z8bY%Pf4ibSyUatjfZseQiezaqRHMGG5iU%FolKFQ)vq(>XGeDk>$B{ z(q8ZK@AByW%Y*gj+eS~cIkY6C1BDmzQLj+-;bYW@3-!4}*3d%;UvKHKcft0j%ERI_ zF0AW)OcyFXs~}0(86YH)Vb-c0$p;`o-&4GqEr*T{&>0k5yU7^yYoUE)S7%zWF*i)P1*OlOn%9bkmR7%nSw%PIMh~ zXRBwnJD|@=g80IJHJ6=o{uc;%sXF4AfO%J^$xTo5U!~@M9N|QGG_x0b0Y27Enp`bjI&zNVKWp=fyH zjIX^52b)sOmPaWQn)U&Tqi}6<^Dp@Jz|&Cn0Ag-f?$j8{n>@r?-h|jyIjd#mukf|Z zdpZoW=kW}`)gBhfC{krYl5Dt`WF@y#VORQ{x36+>Qk+CKfV|z)#x`mpzDEzHCxRM> zLDzS$JI*)xb@dE8AzTx~f0(AfkncymQk^E<=F*Wf|Do!*3p24r_5c`MSKrmda6f``}`I1jFFQib>FV%v!qp*wc&Z#EhhU`_ z4^9qu3ch=+(Mf34&-+4*j0baqrSx&0chdDMOcF#@lfigGv&-5MPUPEkn!8)42?RkQ zMd!@~v124>v1=D7(SrStqX2gjJV&c3)EZpg1FrJ)Xwb>GA~PbxfG3LjUtQZ5EtJ!? zbss%tJrVU@vtvX~Jou%?|Fvk8`~z~@udu;7GC$~Z1Nb|fe1&l6q&!@`(S7ZIKYi{BfLvUf2?@CHnZOK1Z5O-R!o@8FhW?iKcm zY4-6C22zcio_9eDVyA~CIM5g%{GpWNI(SsHYXRhHbA0Y1Z?>n^$A#shL^F6)g0xS8 zy?30!*;LG;t7d-1Jevp&?OR?rM6EE z7M>kOO$P&+<33ijd?Z^`=B3qDROCg$;_ly0#8Q|8X2vP+#op}~0+QbQ8Q20Q0FDLQ zox{Ine|$E1r8nEbQPSXyput2FIlW`$&h=H>KY15XH#HRdf<8l>=l!RNbEB8kLpgMQ ztAHk|usC2;d|S}r-^18uDzSDYB;gq@<-UrIjP7|z=)!Au+~i@`(2DtF6vZ&;Iu7985>T@d< z?Rfu)CpAQk$B{Z`M5K$vSw5LV7XCXHOXKnR5C8i0M!0kp4IevsAu(fdCS~Xry)0--@;Q(Gf7%(~fc}ao@Y3uUmk0 z>m~(=I)-%Fm5#M`xU(+t`-_CsguZ{2Ya#O?zpU}rZw)7f?~{IOCEyJaHSiy>>BHx- z2I7#_1ga<%~j_X zQpC^@Gv`2lmFyP{gWE8Yh?B(fU=AYYzp}(Ip0R&w1@;3o4ch(8i04_<%DXD3IrHrTyhcJtP0BGol#9|RV+&on#3RM-{^$nG^ zb(JR4SiGvZi-tyCT9=#&PyZ1f{r}Y0taukWIW;{qi?o6d=;9N4pCfsk6F!2eg`Y8oI)emb4qe{rw<9@GEv!%v4b7~k+q@+F`r_msikG$Qn z+E2MOT`0*r%4VFsN3z!T^=@a0RNi55EPtUHzCEFQ^3FFq9C_?Ak$VrQ=}qbE&Yl^( z{o(P8y5im=xLEF8EY8^b^4t&xDq`PWe1|&Py_3Ot-`J8amfGZu&>=t0I=}ki-DJVd z%!YD26tSn9<@07}$VphXhbbTZ{`t<=ksy<$-7!Xovtv^K@mqKA{rUBJ0M{h&Ra)}% zf%7{|o>AWmz=bM9R<_$3w+JXqE`*6jck~OyV2s%WL-Q&0B%NIA(zhwS+skjcJ&(~D zRLSFnH>!eAS4M#6Il?HVy;gE9OYMFrM=0QswiYY=(-a$KAF+UB7cZ2hLy%iP4LFh2 z-XJbw&rfo;t=*t-vhd;rTdr=H?>Q%wF!KstRnlYQI?iFuh7()auMd@Opkv}xoqRu3 zy+874X$%pJ`uI*##DY17`fzCtB<6k63xR@BDVH62FjLsL3+uig8*j`?)<|ZmB{G(Tp&(nAAU-T0)^S!4Ro*f^%OT3=ljw`*2B{lt`@Ufb6OMx{tc__ zxaHzO((4r9xu&Y9u?vD^dRCzfP!{p2V3dgL?kCyR$RHz>gT>4GJ`u#fZi2wkt7N_! znF(%I@r{C2!uL-Pv9DK=j1dn2qGO*T{vtH!IdIU1wBz=ix@Orkr_6(G}cYQDk<3TR( z&!L$051g$h7)V!y^nhg>YZ5X)wFV%jWfe?!rh5gKpZ|P6U@$p$F54RT@`0}GfzbUe zOaVT%%RKqb9eW`=;q;vkXzH>45B{;yE|akdSO$dao|POwr@^}8uKVA^tqLNB-C0-? z%!R(L@QF}(CEzH!;;q`~*VhWKmkBydy=6lZ11w0B164v@srwH;{ZFJaAprW?*Wdcz z{?{9*#bUS$|1EYWbOHf-u34v%4_&^Sls`|H(4W+Q!k-;%YEaAmc~g+1Z#Si8iV87h zb{MOXQ%JVus6bQ0c@IMLJuN+C;^adPm5CIiEOGB1n_gr!`Np|f@kU|UN5@AEonNoJ zK)PBUscxRtb@@>z=vX(Rcx;Z_L#-aG(xN{)+pKl;n<@CKl=BAf4m3d6{m1mAo<4;N zkuYr#=WCrbsBTbBnRp>Cc?=QJZTL8Y>x@Zs4)x8x5NncNYj9- z9*`yL+E$hoQ%ruy;WTrX3KuAte|5f~O<3Y+_^%JP!aMi?i(^kTX2vyECB=+;=jn@}Z z8%&J${cNr$KUbHCxMux9<=DU{Nt277(ifUPp2aqWLa*+#Y}J&hTj%?#|I=dU+hb^l z#Syr?_S=K?KT*-$=aJmm-gv~CeSY`SozBK)PcC=9Io%(9wD}#Sqrq7&4N(80qI)nT z<<-VsNOuYqK%5-1v{DE9_at&63^G^J)_V(*TGoAynXfy?`^s-$OfZ}I|Jb|hzb50y zef0N|(W4tiw~Ug;(JiAHppKFdbke1a(LFkpZUhAZX&ou4gtX!WRKUU(48D86KPSGA z^ZWVfoc#~mz59Ayuj|P;)%GSrokV!A@>Jl$ue%dcQKAOIhgV)^Y5NStzfedpkQ*L7 z8#cNGtGp0p2Bt&zjriGkdJ3IjP5XKqa=Xz!LNzN)S4tVh|6o$j#V!7hQK^6O;{6Zm zX&JL|+s}KJ->=0m$1%?f*-Wazl`qi>a({)(8sAo&&y`;EnfihpJoEA58`H+867o33 zbHeiRzvXSb^LvZ-B}2|k#Oy^!Mc;b_<~o~mye=I(Q{TiHYNkr|{p2g&_1md|eY?%Y z`irm9Ue-}*?03-1&$#*YzP+?6CUZjv?jh}0!53!lSo%L)F5dXy19!4M;BYy5C(SC&M9BVM1yiQ1U^!SnFJY=5LSzOnuMAsvI9RT0bY0+~0NboB17 zr}_C&i{}B2Z1we=sH*Yo*OmLqv6&ykG(um%gIfn#9n6h~I2(cNvrR5#*KWk(lK(wf zMCf=Jke~GQvfD=5Tl|@!ja;$H*hU+&4q$!tm#LO7IwusfKL@7d?bapiookO-znZCA zfuS3i+OPl%-;90Jze@GpnDiB4D1H@t+{9t3|E<;i@1Yt@f^d)-cH>&dE_+sv*&WF= z>}27gtLmkl}Z#w(427yE?kHKCNPkOYogB<8Id)AJ5q8Te+>ORF=(BBo&{YSbLss zPgS<+yl6{5K3?d|DG1hkuF)KAzHHJo&>NMTx%#y;GX~ku`tPIfQtZn$LjKI9hfxQ@ zUS8mHCl^!y7I(ZbcyPe>d(>*4gSHy_i*Ge-sTEa@Q4tz|svIQ*}3 z?aMPpv7h!Ps5MG{cpJ+skswy;!}=?smy;yxdZ|K%mB-&y_#3HzRgu$}nCMG9`|Gl} zw}`5y2Z>11o5H{Ki91^1S#wF6UP)jf7)wn#S^EcQ{xUK^7v}->M3599lq48N!ft0W-=D+OnHPf58O|uB;JdQ@?eL)d~%h_+P zZ6})6Ag%_zk@bb8GbP<@DfPLte(9x;K^FjYYKBh0jH1!fq_oU_&Cs$QuY}hbJ>aYn z%}`n}``bH9S%rRDCQ6*@6Tg!2q?E6NH@kn*=b=+Jdw8}$!GBPd=!I;~pV>Ex(|0wa z&cS?qQgUhyO?Emg-yyD=y>^EI?%J- zlptIY^^0*?k<-H|`{~G%V4Pdfa?Y^pOck*Z`y%k+ZLdjrZHvsvP)PxkO+2e!5agv}#{A>X%m4(~YWs z$5jA-HCVeE>Q)VpsYaAnGYnKSZC10KR3rIo*tKgo-DNLyivRH|z9I>M;EEhT8SU zZuO=y_2%XEmIL+HoAu{U>aqL{_Sy}OZVk>c4X))4ZUYS-n>h^^Pa5$2jb7S~K5mVd zV`!b(#=wEbpv}gsCyfODrV#C>Ft?_Nn5L-mrkH`IxXq@UCrw2DW|DSul3R01OmiBo zGCR;Ee(j&H($ z4JH@_hzAq^+Q%0Z3I^y-iSeYw|0W5v>ev4{uSlzYm6Vp1-@084>*>8Y`)_9F)Hb~horFDwS)ES4XMGjg@6C1>DrXAY419Szf4l4$HvAy`fF`m^|G2H~ zx_syE_1W$DTWVMHxIV5jjo!2Cr#R)d=J&!t0mU$le=Y|-!4+`wM?jd*mXgh&Lq1iY|f{ZoE zmauN#%~5y0UYD(Pa{-egkh37_Q{>y^a++S=1~1L9$Wg;5AkH8>v!(H}o{79-`wc14 zL5P>7@RVcUA}0Oy-E3)@SH{AoAw^y{n_wCo1$pZS_7{E`lZN?$WVfDI>i}Y&us(twjayIdNV8 zT=_toLH5Jo2#cMqLBK~c< zINz#x-*Ngve`zYmJJV)#Y6xwh(v4FluMYD2F5*Jiw!eU7!P(49@$(0&1 z8vpv>0Kw80cyh12ar@6t0E;m^74~v35iTQvBDR3e|w=l=BFO#($VLnoYvArQmDg)=jZe`%_g%xFN zK0~{X%z*F)t2$K%S9kT60U%aOpnO8cWt2bW3KZVvwBtpGWGR-C6epL~2!{=jHjdJS zcZg*BKBK3w@zf>NQl#j5qwf26MDu$5hnr@jV_GJ(W&dm|Q$S1ZEG0v2&Wqk8zi0ou zY5YG#-L($5sIxjg<$|O5mi>~c!VlZ4dhcfhzf$CM4&}3B+Ng|tdy{+hJ~6+^b;nbh z;~C*fdFGt-up`*ep-1wmEMJ;9=WiIO&8d~_JSQ%-=4?q9NAYUyW|H}B*WPzMfm{?e zy6Tm#YBFHTbsYdI2SyyTRO8Xz1f4eCEw`Ky4_Py(0nO#Sn$R5dlaVhT9lD zpHexCPh1kzvVlF0K6)Bm7>0cnw^5OCM1gqI?mBzXaGlaZz+CZwF^E80#=5PDiyE?(JDv2T|% zfsHU;%G3?T;Rp8d4;i?MvYHK z{kp0zaE`svZt4+aGEm%=rOF(##6`4+J3eo|BruVvXN`x+@dj9k%x?9l7yxurB)%Po zMyO&lh{p??_}r!W&6%H&X%kM;WH-)q#rI4C$u90h8`Cyvl%K*U2)%S*djP_;;jjtF zjF@NJQbn*MUjxQBTVMeL5X1cZr{dB(m;QzX7^IV&5;$KginA|Na;b}@0oe7=fjL^j z9hg(@%LM12?5KxdSGGbm-d7VsevP46I@8RazcReuV!$6#(stRs5-iXqL@k=pNbPfY zbA$)0At_h$GG1}>W{hK4zJ$0-?ungS8|TUQcv?!gj%E1avztIcoVO5Vh*OV8QbwUU zD5B_8Z_XVRmGs|MZ&akM=jLowo;JThKS%KjE1$_IY>5Li%smM3l{aLoroz;6*A1Bm zlsMyFCoxsXT6=y8O3-zeGQP5JrNZ#F=-Y#rs4jUULAOfd3x9UPp$cm5Oik~i(*54I z%#PiJe;Y8zy!>^a3X`IZl3l)ER5ltUi3aS+|K9tw&FrCd$ZoA zn5pE)WFYOs;ek=xdeAJiv#Xu9qL_B=L6;CN$rR5d)_1pWLl7lMb8B3Y3H*~}7zdFG zyZ8j%k)XGyU8x-W^oPw2_EKul2@8pNf3JNQvaAyFXUfp+41EY5Kv5#8x)I^I2eV(r z_E2;%v|6eDmhksxn9^%KL11ng#x_OVp~HT{l~LT8Tt;q)zLt>$eZ%d8csQRhVA~v zvG8EYBt;+5L*>$#*si}Mder{2@V$=J_=#|*+Ht8%R%e-wF0{ZEh7TA@G0gX|iK~9E zzPDZa%f&!^Id`q}!f`DHdYMSv{`n7vqKzG@ov%Uv)_U=8m|Vj(A!DYv4Y^TDq<36^ zfjE2Wb0)Mn9H|LRWcN+2&>(IUI1?^{CQ0c}UD65h2xKQ{JWd{(0O%<8O{1J=jbwIGmE2Vwum%E;jkT;E zLsXYgCMW=cN!9RA6`Mr)V(Sem=kET=@2x84ow@SO!!L@3Ny$) zs)50){hnPG6+XUJo)&tMb{Gygaj|7HJDN)DJGmz1e0HW4EJ0!mbT}$Ris~6S0J6^0GBVlG#h#CSq6Asq0$o+dc zc|;>_!AW*)k_PX9al})wCf4fWb=X-f$R;`wf=*QGAX|jnGaZptWq`tT078JuQj712 zvU4LL2#n{)*O3f}3&i5$++-+civn0&ayKo|I4q;*fyfCSq)vsfV?3FNz;}P8o~Trt zJ`ZLh91eit$iniz%-jj6H7vss1fq!oXOF-|2eEaspt#5B(yz%herQY!C@d?g?FR>M zgma((1PV~D&eAiDi0#XyffN!rw?nhDcO6r9pWWKmVD;ew^}nuo7} z3Jqkd6KD<%`%$G+0z?e3@A_2{{nnXYtLVxKSqTN~m$~C`AP5SoimEDUsW}~o;Lw>6 z!YRPeQl`~JY=c9kh!soXzT{A!VXvI9`zc?jkT_i8ghi^bRIbs2l*sCBI4aZeadQ4^ zNW(F=CYBgWSF4FA(qh0t3AOKx6Aw3HSp#lBfI4<0&?svvMgX=qoFSN6ZT?GebkZu! zI$6y}HWKspXZ``9D37OH``E)EAlF$Fc;7Wj9iu%Uh8sPTPFt?Vye0jy=WRR zBmj^jve{8B^OZV7O67K7YpraRGkyJ?0hskhEElFJivLb!bE{CHgV7IdMJ+q|U(99% zU^VrgM)N%pXDF`pE^QK)ro8;5O`v0)85n9yT51(&2upQ2^Hwa~N_)*lBZAzyBgd~v z>D1tbXkYFcmIQ<~-5b7$u?XtwLK|tB4yYPQL2qo$i-% z(ClbGnmm-&T2zJ`2>M-TE3YShlyQMe@>>S8)@tMTCNLeLXld)d9JX5-(_?~)td}2R z)`FO!z)6GbniM+qmX;0yNW(yPPiCTpPE{R$w9W4ak&`fvqXDIv;TN+-bDsB$mdr0W z^sitb_XcTsSjVPY{JSvVA;L?M_$W{ks*kzhgzX-5G;@UFBi5pLItMf!5zWkrvEm_|s9Y>i+w@ez{hD%iyD?FiX~A z37c+a91YA8j1HdZRmH?t^R=B5^q*~jGG{%?XYu(#Kcck*^lPR48_MlZS}(j-Ke$1jP&5(NtOhRN%gj(khH)^$te~aDJZoqeK9&hd23fYWaNp@~^Z;2L zc{%~$hM0n_fUo%sSnN8?~{~fC~!3XtMP0d28BXdgRQo z(oy=yABMg`=Q_Vlt7b7tr^9ggQR~5xZbqo!Dj-4VJ=+R4qBRAOccj0A3&NqfQ=`R; z4cx?PhLhUw3YkhrWHt=WoeHu|o^u6(WYE(N?p4pXoK?uvUsQa3=*9*Uc%B@IBGGU; za&KY!3KtqW+d{KcPDjpaw?D?oI^r6Y7pA%z1Fnt37|@Ab<~>;5R(4qs4Owat2$>t9 zb*M*bwHAtp$jayrD)&4~?b_eapm~(p=@6L2JfTc20eCa{<_g`k00q>5(|o$CUZOXJ z?)}uNM;`c{an+afr~1IMFa?&|@;r&wR44XfPQx`ke)#1Y7k}(A3x)!_~;2-6=*47=U9O8F_qWI zOJIl(lbI%x1R?t|FBP|wA4$^oszJgXVT>PjJ;>ndis!8b>(FW%mq;e~t|T>Il5 z5%I!G@QH)CC#cSP&|%oqh`3`r)c#d#!6Nx(Y^mcV;Wx5)I^e4M8^^uRV1R)#@i6ky z=(}Wgl#SgNm0P!m^yb$dd=An?K`zZ~3l^_82GwnA1E%tzOL6F?3=Lnxd-exqX=p0qtiXFQDTa~A!w&RvDvguq_rQb@RGIc zv}otpRpFn9UKxx7Ki7Zv-HQY;4*#%L76cV~zZD6C%7eYp@EZ$s4ApR93Y{1hEYtB` z+Wmz`uWO)!(ipN;liO6@VPlu^ik>lMPW?}Xz*>}bLO|3 zE~{o}kOdvBsSWbWhCYog!cpS|xdAb1gk0toukO8Gq+gR^om>ZHj&Gk87w>$2vE}xL zYIUFVM51G}739(9`oa>$-&9pJ#Q8#{bViLCI&b0~hYQA2nKni33R0rZ2*4rlzs1nH z{tPG@*Z5TzZ3jMgv|aR-?o`Da5B~U~;Lw7i9Y=Zo_npg3nQ{l18!&vme){cv74KUK z2#O1|{d)j&=F9rymv?h2$7D0B`o3=-+^_c-Q^Gv%rGv%_Kz>St8eiVu(}%lP1F{Q0 z)ES<$u7f<9})lkEnxMpPrDJc%FWi z4U2#4LFwVl2j9ShH~<9Bj9p)!O4*&sqj&ckq@_81W+tX-)vpv+1>;}o4@TKQ z2D#|{5pCHnzC@OBe`99Qse@@I(y_y{#!*2~#Z+2UIpTJ{pwY6N*(`>VA&U0D2fC!wB~@QP3Orp(I{H~>5Mx^U%j&8Se~(-_k94h zga`^AXXLT~r+hv#EXaV$8uDu4G`GG&v~vMuh%BNF{wB@r#CUcJbL#;;CL3rDmm4c> z_%&tkyQc8SGjBex(Tn>GDnge->_1qo<*SrFK$Um8c8&B7<&So$EkPRhBQ+l zVYsqWvx{Ra-c9Ii_QWp+6QVAD_aK%XYn8ErXSEIEL{cxj3}Yx9^3b(LnE>%d$_)Z7 z2;Ft1B#+6CG&NO0lp)+BOYzC%L>|#Y$^P%1-T`OdW6l6ur8SR=qG}?<^6ybWc$R7i z++dAF`Vf)an3esYr$((hA}$#>bRxezO&#l-p(kKoOn#$K0_qv1+tQqyA*#~gLftv*n)@t& zz8l2#?rv+tp3RhO=!)tvwArZcA6yFeS*UuA4pyJSljdWt-+5$n1}>vobhVEM!eM<1 zz_qZXNs?4OoEMV_Wk^{Zja2(PrvM*9&j&S&0Zf~77Mk6B15eh{zS$(+Fo<@5T88x9 zd}e#az0U66(BwJT&Kb$Os#~t`Um!_Md_?k29!DJv;KNKLm_;SLAR9FGNaR|%Einf- ziUCLp1%MI3scO!GvNJgl5Wu!)=quO6XLEtk>lJ8R)6`eSSMg(Y4Km1_U0TvGRmZr< zVcUgtEc97>{KPu@pP|fFu$|8#h`Lj6&LWqw0E$NAxmE3SdS9OhtF9MmUqq%G!fhS0 zkDe}eC*6J1vkQYy8L(wgleMm-qi5K|WlKLf@>0Klj+7&= zyliv6!b&Y;2?GU+0t`*u2~S-E)T%@XB$bV`Rn{IObkkP~zWj-rl<7xjJqT;@;Mq*% zF{Uy^VEk-Y4Ha$+&r~SZ5HH2fhsS{H#vJ^T^@X^9-80Jm4Ak$hI zSYo&pg_2>_%)yMNjB08P2X`{nw`5B;EZvUqj3u$gulQ@^OM`7SPUU7iBDd`6EvdI% zx9(t8r=PGPS|wRf@BQ|~6&dzM{L+O21Nqz)+4xsFU5sCc_P!$u^5PMS&COB0+M9Bm zHFuhAu6ccmcD%{m+M_kEaK^gfO!v*PjK6Z>8rB!QTYrv)3(_XM-&`!CtTlP`gB9}Lj?SydkS7ZO z=x;0UqT^~-h*U?FaDxTI^L;4E7p)VG2O)X+pu+uNky8~ibIi$Hv%ow$t;yOqdx>rE zPY_pbuu5q{6UIMPoEsqE6xs~OPwt)|AafB{ET0L*_VfSD$xHSF2zd0w}er}K9q zw+Rp`lnRY9G zeJQEL-+``?0+HJ-U;hSGIIvMrh#{6f_!;~u3Gq!-_rl!^4z_lxV9ROI;hm;;R!D)0F}40=wm#;OmkTkn_2o&&`jf z8NKe>_@I){{naY^{195}IQv|N{aXS!Br7y+gAQnpm9|Z&x=0NV@_!=W|2dQ(G8}6GD-P*M&cAjMD_TPw-`x~@8@t9z1U8V9} zkn_pTZx0kXLGjODdRs!m$HyTrI8Gg3RlY)|@>XNwc3eh={1Jg&6_h_s0$j`{zy8vD zkfoGd<8$Wqr6x3t%_LDhOC~2a&mDIoN>osAhu=dC-?rJ0bXnp6E(3Wc;GSyWa+EKP0QPm)}lzL!4brO0D_~H++TsD$bxftup}V`FFB{bdYK4`L3L*huo+BuchR`g~McrqhWerjk z$+}4n{YBk>OS-C*Q$`3Lj6u28^(dQ4hG+MXg2zmB?BrEZp`)QZ%$KGVZ1!*tNU1C`nARRBF)QR2#9stt|njs z1(+j2Kk&530bKCQQDu<}1>_!=0-^+f_NGjClw-1S1x|*!qNTz_`2%RbD*K3fd-*dy zm$}qpTDT!Ns#e=GOYX@aUbxPERq(j00KW$Cv@|gc%ti864a1d?C7@C1CC&Fs5KBe} zUrP+B5N>RKt6$`OBJp|NHKkWTth7o9TY*J0sf$BVYXnA%_mlzMc~Nx-ha6#))X{4^ z2Lal!UPzAyJtgMa93E?A4=`CkbM!!?faC4K( zT}c=M%Z=TlhSaOdMg(kjT2)4+djX|7`Ps}U zS4|ThPJ#!CJzzY+ky5h6gv4Qv;clky2uE*f*Y1ELfv^mzp zCeM42&t(NDi+D@j`^j!($WSk53m^e?vdF)lDl3ox+d_jn8gw26HpXZ4$23+&vH$Z1 zouw3aMc0sb)t0(bj&^GFC~Dva|QfCl;t8J{AP2z`dWK8hBv=laTRoT zYz4n-3AQ9gRL@XBn-rKc<*%ciYO+Tt(<`d z$eh|YF)c|cIG%a8!$n^tYeu<4_F}MDUxCC3^xf1z zsXId7-||HRYFSzwe}VQopR?hvmecB8|GW$2$Zel`ncOWAw$}kyUw~)fp5b6Q>d5_> zT~!=Lw@1@H2j3Q3S0e6<(EggXiRsj+W8rjy`cs20-3gSVQvmA-0Vpu-dhdy)q@!3+ zuDpurvj;av`&B+8C90uiHNplarxyasG_3;lxI(YV8pw8jD;8{Fy7!9nUo|R%#RBst+sUMv8*GcL9Gc0*DY={2*iX+Z;3tIFgU~?2?!JEg#k#o ziZKTO9w~%Wndf^r4nA@R0my}YB7lEO580D-~06|OZ0V=vuz7$nM?JUDTW_fAT<=g z6*RI|Z$lDb6%hl`JamGoAB{{Jynp0NhpADlKa;SoYh45WNxKQVP|*60rukrJ46GE& z#{?UodPDAK+X|%cfa&veDRiXU>iG2^<2$bgi|qV9$kwumHak8q^$2R1l9?PVvVk5c zKE*c<|A3miK)e}8puQ?NaHi}K_(C}>b`HW}@bIi>wA7dc$YDgw!$gAEUZ>yyN5YSP zLFs^LKwpHh_66{#&Jnn7oE&yBpEJJ;9p^XH&ZX|a7A z_&nwAzphi^xg~|l+pJ=QR^H=zL3&gkAT?YJ#J_={f%`NNa!3)wP9~;enAKi@t5^Oj4&?;2KSy4Mw`J!IVyYJ6+Du|-R9%;YV{mn zRF|4!wAVDiKqoq}~3aEhbKQ+8VoQ|ZK6Z2e4 z!Dnz!Je!-;J^MvwDn-}%8H96D#ZE|^LMirKFT=OS-x+eg!9=EnFsWp~N?@{t;rx8C z?m>Y}&FsRL$DQ?p3H^(VMPuW-YjX>n*jH>39}3y1pqP1=w#ao(jGozxO8e+|!|$iU z11}h4uWuQxE7X(0IPy@QUMOfxavO~}5-&F0@kQV8>+jN;{Vb(n<l(F@uWWcpDqBXfp79ol3_o@FLpOHQ zx=|h}?YGD|Pi5QD)$BQDxj2eg8W)MU@I<(CkEasEsYr|_tP?}xf9(h-*y!xHKXdy> ze-R7CRO^@b?u3T}gQ0S#_HqLT>{9I>dHbM+7w0soAl(t%0mjPC?yZs$>TQ8;&msaD z0_~R~&@R||Q{N);K&+tkb4?b9*Y^#VWTZ@$EdTE9VToCUke}_B{nutyL*4gFz*hxr z>sY`{X{^gEDl32ct#`~~_+ps7ikt&F5Y=EQ3>5r$l8*Qe!Pd()+`AaO|5b>EqYRU* z47Man4Y?3e9gH()W-7!kzsoP0e`QFrm_~7=pK?RZr5^-7R0J@mvO}TVsz#TTCQ&^# zXUg?IHj2I)E`}tcAn>UH`D3&~3I7Wp204e;4NSJ~4eoi4~!ID*N)OA#wneFL}}K zXrSich#fDZbe9|b?kjJQF!GyDNL5HEcl1M)n!}|Pyl#h}*dK!@TKEHZ^cT3@4k!A> z?CU|di-z6}e3Vz*RIH#W3%RLE1v;PqMD(jKfBPxR&E0RclUI4}8GHbX z2DDwFG&X}*=iEf{SkUL9qm=QFlP_qUtaUtJt5vUcbIewn1w}P8bpV1}JtmZy7!SnVA*;KY}@} zVp}XBQcknFjDNf)x*pzVuF?e|3|xd zy08d^u$w`+n3xP{*3Jv%ZHOUaXH9v9q3#Z?V%t#1t;J9O?K?d`T;E;u}s0abP~W!LBpOAzaVmDU2woQ>G*|n7l-Iov92{oGM>#G_fFPL0DjWk)b_qd1 zd5icSqR&$A8fIA`lVA4rUF2y}dBa=hSx>VPvAbF1R1W!h(&pt>W&_d{V|A(t8*LPg zqQ&$%V&1^@I^_A;7v_b+h;#mg5s>hlB;Fc0B22&*EnHYV#5{Vv&egh7$21}1)kXL< zCMjr)zUEm27JDe0VLF_%B-sPB8d>H0+bMnN^1r{z_JtakHI@;ad!9@|8lLp8NFq@n z6Sl5A$P*36YzJOvCMQA;^vYsa9+Ov8kv;!gSrc;y1BDo%gUk5>1FcPDRdkp zMI`$0D(^U?!F0d%XUG&9;9obF1ihJ#Z0EC`&l< z=3Kfq8h}-YuYXOXKjkL0$jKq60B}ukGGUyzT5*s8s%woL0nw)?8bj60v16bp_$yQ1 zQf{{wY%0d^WtqY}xqA|g`aAhOnsTHu8L|3>$6Po;JM%ncj|n$M*27kGU`GXo0|B*x zz6JJ#QMT?VYYg|p)-;vLu7yo+LvCGTtp=+VhBO+5qxry49hX%@Yw(p~jUi_`oc3X6 zy8ZV`BGR-!EyM>kCJomR{>UcirlBBApx+n>Gn=(r3q5-qdi&xzA#1}?MtLRydQLFN z&}0H9D6Yp(B;U@qd{hwJDcZ$63X)kz$nnUeQ69e(tHy@R%(Vw4z*J~#1NYrpEQZBv zPhpqiltbd}!C*F0@t&o$V7u?q%$Yk%fJ}YI1eErpnix|w5IIt9%!^K-$Vu$Yez?F| zqch5C=s$Ot{ZQgo!<98}3MkIwZkU_Y9#&(^X4RjEN9@n73DCNOgowM6teIyP8mh544 zSu}1r=+W3TY3dtDWA8nEP)!ch9$*0GKbdM$6DKMob9Yy!ZVLB-f2{9T3id4|o452F)7k<&+(;EH8yAx|)J`GnJqn^8O56A3)z?q%zhn zO_$hOi=yL$as+{{mRc1h+{SWlSWxKX`*^!C1alB`UfS>Im-K?h7lS>Y{L3~F&jMZ+0*T47R5(HXX<0BWXI<}ClPhyLce?{7oq8bs zVO=!YER7hWzy*%wR|gqPjmTYjYZrfUaIm`l8K;-{W$23{#zL z1!egWSZpHw`_INfCcZ2*S4{f}n{~8iz$ia@@!<#2cratzsctB0bFsXdRjk2kAt_}& z^w2SVe9u6H1(PW5+S*^te2vQ~U41^}Gm)voRD)!^V$k`aPz8Jd(w<1pPdVs*fNc-F zH0HMaMl|PM53ySAO0L2xb0Q)lklbdflVttO3%b~z8DWf0SV^E1zRJFCo!9#8i?CEA(B)wmV-^U% z7OGkwu88}IOrS{U=7HZ2>9f7Hcon$k}J&6O6Qnvrbr7{T+jr!A>iJ-`}vuhQ5pWPZoQAu@p2{P$_c1wq9ZpzwQX_ zQyvd@=)s8wt_v@`nR#l(ZLOa&Ku6z2yd~bJJa`M0A|_vM5_5b!$>d$6$H-70Rjx@k zfLfzn0|a7-?wUsQ-xg8;kHM=a@4rucP1im(pXD%3wDw2LwU??lz1`2(#&AoaQ}m}$ zKtfmMUqmm9Nq4K$x*ZJRnK^H2zjnYoom}xRAxV;35<##Y04V*Rr+&0{F+4OyfsUS5|RPFe2*G^Q68-i z0*5?tW*U9Fd?O<5PSdv=<{%NO&9&bnrupbv5z^y!wW3BoIuA3dI8- zVS3TVaYvFD4|;F<_(gnNQ{DO+#(7!0YwT*#s3BuoFfIQzrVSku@rWM~lfEPaB-AX5 zm5(#bUNc!4ksu)vy)-7s9hG2SAeVs#3+^XKH!*B|COJ=?)mn%MtNQyRZOT&EzoGw6IiGHlmDNgtJE!{ZB&%Bn8B>kRXUo z`91={k=^}V&85~Og7#Ag_)}2g%2||mn%Q?qR2t|0kJKx@A#Xxi8+kLsnhmB66WTBr zvNh?e?6~XDU{9y?zW`E-9PHdI8`zxULroDNz{9%O@+C5V`1sgjpiwdc1WzCYp1o-v z#Shr4P6)m)$Q(eR=0-syTsJ;;2sK2d6fUQ8@_=yFkQrC7Q!*<@wdxkHHz^FnXApP% zEB8lz0Iu0hJDv?nstMs=I%_Wew0C0HD`qrU~?pLv4yNV^~rrv z`IQFY7r!W{_yeJ6Ivh6E3=fJS(tI0;9jA$&MbvSgqIB=|?MBn?JF;W;{B(`hAz(dxIPGhfI=w~gKW&Z}~cQj!*3p5CuGbGjoZtDLMs?E_>luP(B^y+aWBqK&qV1B}HC0DRoSugouviK20lc3J_aC@w9D}=1dnW zcM1(_Wol7D{pm&8WEi|J`$d`_92xB7NQ(CI*FqJ~wA`NL0m+6GE*zAuJMqYtm?cM@ zg4_YRjg~C;4rhM)>_YF9q!5kqH071D%H{yEqdc(0G>gI4N^*7KmjjTlaVoqc>bM`| ziv*#`ke7R9kC)4olW!OGT!*(-O4}DQ9tO2 zjj@R1F_TI5DV5YN7BGPP#`3t!tNQp((kx zN06i$?xaIvz^{6gMOqWC9!+d)Ar>ky)cAn_!Pia6ykN_4BF|%ZtoCVGdQ&!dFYg<= zIn^?I{c@6JUlNNeDT9GbZxYt4W^yAS17Qhq0a`j68b58+hACH3e>NzmWf+#GTx-p4 zl1rMAOENKUrpJ<|kMoYZZQre4L8uoa4j~+Gby80lmZ`IDHO11 zp546L64QJRgV;T+IEM#rVBySb5eIo}>oK)k45XpM>iH(G?(eOQu6Nf{?y}=M=&s!T zxOvxXJ?AS!c2x`fIvUP#K#&kCe8%Q@8pxe5*YQ*AMjeU-1hmc{w)R*?vfOD~d(hU} znnY0U?DQ9tqTJv{6+Ldghr;+|mZvyPw~O%bZ4X3J<@kSVomSVn-Tgk$Auk`?IMBu< zlcY4;7OB}~D<3Q{azmKh8CVK?eo*iWD=4C4BPxGCH@#kk#)!wJM3}QaX}vFfC+Wis z(dkZ`X_VNtqMjtFo9>h-yZ){~8ITJBuDfl3-}SVALC(p^ofp@AUEfbqkN+p# zgC5WYsh-Mk7?pBy>C5r^VdO?`(Yf}}z_jTbF%?c|dcdubnj{|jpf_LI4e^_TF6+MQ z@VL<0$a5o!XR7bp3Os+c8j#EtsBTFkJSrgRd4CeM^zKXac%bD8)-pwuulKg3J^o_S z7qwn6!2czgajd0(ywebKasR~c1D(!_ykqukchMOak0vroscYM2i zS*2tGJ`{s-gO9C)D+l;y_|cLA6o7sM`uudJs}v~hBP4{%tkF#*op62+uP(KNtK4pD zn!0D;)jU<6q-|~dWsdy*bBdkstl}U{Xmxa)7X0P&tO|;{?e~22o+R7G^Wfv6C`4_> zy+AGG5W6X&L~`!JYNxfzpqXh|ZVmYhzKi7xV*B3c2MKU)!9rBRmD7jwgRjo!Ie~?P z&wx0w@>R-n6OPCJT*-yj(;|BJ?j zXqb%IGh(f9xYm1XH-ng$)MlIn`Q_-Jd*40<{Xn-)c0OQ~aTZ08AJ}Scii0@U7VoFm zPP8;DOlLBf_q>x417W&{z8U)$35E#p)uBfGP-zS+oB6yo9BG3r z{?blBUki?pSG8?GKWpJ1>zD+=Bt}7j)X3Jvg-P)DePN5T70IzuK<#dW>!ZB zMhz_XuF|k!Ae?M{Kvwt5#%3KqJJhy0Bz3jq?<>D&^~xj67VkrRR3-hpZ#87D5xIbk z)|V25;mc^vua?(pGOvBQu;LRAD3xz2eYO&Dx)8vyhE{!|$9Nt-2j};nJQ}D@{{*tQ zmvM0e#7Vu(nbVZ}-4Q0eDy!uw%6+Y~xSoD?gYilFi-+!^`!&wLr@7wD!^uE%|2vd9 z2zK4g@}&-g#JM%UO}`7nTyH@9=8J}lS)VsS4wyIA;byk%i{D*9La68Ag!lcevaBQ+ zCz-}`0~AH@s9~3rH|R8YaxeH+Lc;MFTUeL{({>Td>wpS6wT&|&o7vYYge6V_ICNvX zg>mPFi^QWH{KwX$SI_2EC^QL$F+T<&(I{LYE7a=5dD;wGY$IZaRxXK+dG(hIl{`ePl_n|fzv zq24#*Z$37Bng76)hbenWkNJ<80obDHy}EY_lbaq~BnkkUxUV;~J|`|@?jFT+c}B2) zZu@B-25%FX{jhbV@=I0TXvL*~m^lxk>9EpcurvvVMnRlnzn-%IU7yytpKRhbz+T@;+H}#Lh(HJe*&nFl>7$R9&bmz(aNHs1$qECMT@&wtDTzk7YUb7^S8?axc*1t#Ec+w;lx z`!l8jdl6T2Z~0Ah5?C)e4TJ?ksmTZl*PvJ z$jC>;ncW3)c)o&b8@nbGLtXM;LVCrT}MsdQq|VduI%+0bEE3L$;XC8 ziux4n_nK)K)0>KNV>VWGb5^sI{Sit-TO1}He902&H57B{@;gjmqCtX;B6cOhJI9nR zi%;99B~XNTmOyLiAmAgOS5FhQyI|>*JmmhYTS;YWB3MtSq3)7-1?yC|{5_&R%SZc^ zqVxtW!)T+48bZxVXUaXDt4+rCjIHZE`f7kMEbXSkTb~|0`BULIDX%wvn)i(;+c6F) z_bPk(^3$F`$Uj{0{^!R`;(FY%14KA`<5hWz@FwsCKucVO*u}T>LTuclO|w#n>!m;2 zTCB5V96$ZY8wz_yB#QgRKE`fW%CqkezUhq>9~~UlS$=0|Ha8wfAKg(HCjrF`c?e-p zL@pqu^&YT_m>ET%?ycEPOAY)a%pB@Q>Ynl0yStKdDTIF@IqI9jL#`NQ)`t#Q z!_mew65Qqw9LI^4KoSsDj8-csiEz{~w_X0yB2;t5G6x|kfdetvI4UH;=qAuxp0AqN zcpbg?SqRBuLLDh-QiTsD=_CiZ-7ZHidhN(h(n1-^v+@ zaxefw5-4w{onl?dyJ~->8pT#70f+@%LZr|w&(|-KJACZ5rEb-4y2tT%w(*)&+z*{L zxu>(u?S}qy$!ieGY6AG)|M)M`f|EB0fuVWU$&IO>Dur{2E%QTK1y3!a7T6Y-Zk~ZS zkzSv!w!Dcv*K&`z-O%a`?4yXeF}CUkDvbo~4kJgi7@e=uIlk^G;$;~sd0ll`x> zkDW(vukDN?vtskWrWXc^XviAW9ip2KcNk`hKj$BNIzL9=+k8MEP6;6=A)JHm04A3% zW3WAML2uuC7U-@Q&>~MU2tB`)44hMDwH?sy(vLr2TVT9AQxp&a`4KFq27S^Aclg}b zrXG?RJ{s=+jjw3EF!xeQn6FLl@H&m~tL}M*_g|W|+uvM}ejW2RO^1%t{hjb;LMZ@7 z(2P{}Ky6UszrcP9We{a9F==&}!8QM@V4As`vz(;?v)TNHQU5*;$GuxVOFu~Zp4|75 z24BL=ew#qcJrJd5M4%btqV1g%1&g63zwjBdkwxWTAAT482^Zs<@e{MC zt96e4bNtk%8WahE8p$#2(K2TUDwG8}F%4bNrptN{4tS9O^DTPNS+Y%Aq_N0i1zg@% zBL^Kmc$twaoPh+yIYo(=GoVzQkMI&MlcQN-LaJQn-h>;YmTt{!^hwzL7%G52tNZha{A2hW6E6ykaxXr zIkH&Bi=e)IyeHaBVgu3){(|(+)y99vjt?ReF=-)o#xEFpW%a}kEYg)zFnke4EE(UW z)lo#=t9nd*!P^Kl0<)&0uWpj@4NTMX-d%?JREDEcP99aTIItybS{tzCt`W<Zpl0DD1kX?H89_5*Lw=fMQFjHK0QQ#)y4T!DHUdFA^x( z`QWRivWgg_87_`JH_u^r#zBr}HI1i3NsW6ZPINVt_IGcfg4={=oLK@GZmXSnnIMK( zP~kE8#|Gm;@GdJkZzm-ZH(R(7&P~-oEOuT z%>lf0Uh?I$dkBj~7EK%kbmZ%=30=Vu+0;N>4_Qa8Iw)Ys%+-eygCdTm!bUeD?$!&k z@f3;;v}d(*VIC#EhRE+<+W)%&*F(e+&VH3aAdltR1{2Fz2U%@9J73cIm*9|pXt6!p zTP@Y1&n!&lpElUB)UN)$!O{0f|2Ni}HiFxp=1GsN24GUT*O_`brtAii6x6m*{OMgs z7!y2F9(q|Vz$@8s5amc7P%3C4KA1~pdd(DOf%kXi_`OKCgQC}*^B!$95J`YpB(5;F z?>3t3$mafnFp>edrcbepjLKN{g!?DpBIqA)c=zXuTld9=-#|u`pc&jj=D5hMlEM(B z)m00ug34WX_AHwQMl2d8s|~S5K^!;Y!EO8PZ<)ftoGED=CZ2GGt4kmgiQCpqCPZd6 z?Ppz<6Wk0K@Ak@3czPxdO!7JdJHlOvR}eav>G>YH?ryBiX@W%u?LS?%AR%had>>I> zBn$FPiqZ`6pLeIgFx9GsT+Kg>M889jht)UTuQ8~^o-;kq=fV(;&bZ3u@ez4-0K|w+ zX>M5~Xl4Mg5Pwx;#tjHE!-42~I0$|6VmL|TaX2e~y;qg-QottHOS%c^9E@mTQ_~E@ zdciht?dJE}8GA}iWxe)Vean5~2L-jw8 zb!n5jlCO|DUhO=ylR5kPr<`sc#$|v3kuQ)z?z6{m#|`3L-S%)?L4xCmN4OD1;iFYI zEo*Iwr*@&0?J(`0_c6nLP&I)}ZPwEc8Kwrgg>T30{OsI&GW5tZtYUyv{9JM)L8wRY ziX2(z{i?EMfekS~perHHGW!kf*x_u%*woHzhZ2Us4{D3?{qbU$Q{z7y%Oh2%uoc~7 z+x6E!WfL&h{WutyvFG!ykipcy=!Dldg5(BmqM1a1Uxt4!fc#tTY{@D-DW2tCSinfw ziz_CubES*9?jxvZ~!2ESwW`2v1zoGhY32_X^ zX4|yLo+GMk1u)yI+<$fBx<{1N;0(;|arjV9 z6q1?p;*Q?_4ZZz@%llBK{1_>X25-|Cx6XC{}9^U%08_Mc=Ya0a$)XB{8%6zS; z`?`TylOXq7-1iWfvALJ(3*4cEXF*q$wl^R#B*MOB=3%(F?~=G9Ah8&h^^g1Z-^Cl? zBgnjR4s10i{z&PgPI}^?=8qN9vP5j{oH%v7%Yw_2I)Q?YQr`~WfNxUrT@eX-oRR@>=2aTyDf8TJ6UKkxD!4|D{bWWUzt#iwsBFxy%MwkpOoAX|BhnR8zNuZF!Z=MuP`*`fte9%BO=^Jy)x#m! z6@0u<;LO8(&Cr(_>IG5vdVWoF&FwZ_FX?hg;h~@?-2?WgHxrB^lFuY?zDQC!2aO!% zT=R7#akaoQLcqDV^j=fA(cu*;vF0-ecV@ei?p^Hj^2(VqA67w`oBLM&2hE%h%As=x za!o=Cqd8k*MVluHc6KmVRPdvBG>Ju}>XV4thn_c)@N)qCHl9YZp&ZBKITY%CcbhLo z3}Uww)5TrRq<*P|NWGng7#d3j2}+KCKm^j_s*E%ANCjd?VfCq{%RIDDH?ylRY0go| z7b&oS@G_&Li|{1e@MeR zfrRy#YrS1zIR%zHHl@F6NE>2P$;^0MEp_DnYL6F%rpX$FS;d2GYMI%U@|}w7hCaBo z4AG-EAiumhi`WQUtM%V zCp9xncGxd$%YiKZba?}B9`dG!A^BLbRk$YSvpR0o!_`Jh<7wVqgs1CA(`@xP$H#8hqjQdK8)_o2<=AHhcAs zzt+w*@d7hwz47P*$Y(>bFOo@Rt>rce7O{rV03gx(DRQI|FvRCEhd($Z_P*0tFQ8>N`7UPnAH zV~_yC^#Z|+8&)a2LLIjCnICO8`aqgiE@rCmN78NnzaW*|j|cV;zSkbF9W+h+mSWcs zX9@xkJUXQIzQs>YRr4k|W4wBE$0h`9v(XuX1q*C|+%ZqK>EUkq5MShNb3`Hu58ADL z5Hs}Pd%Ch-?c=-Xsy&LAk52#T4v;`Olf0+Rdno=W$BQ+VJa=ji z4{aigDwnH_9j)b<q9L(fZ1l%1j40CJtj6r4$!>)G~lOV1CNfbIN(P6dEq_- zj3%PD3FS`$n{JIBMx0)iPR^LH3>lkpYroQNHieu7Z8>S8`u759{Ss0`UuC*@Cn|E< zxM68LF*E{HEoy*+4H&F9J1bH+zA>_gxR!DC?%Y%uWIA8v>FpuE@HOn26jt?G3J$?f2xtdN!Y&`+)SFNNmM z%7+k%?$X*QB&cHJj9$TM&gQR_XU3dA@2pb=AC7VSmdoUOyJR<7Z^lE6Iws>&W7cw* zyHS#y5#w?x;{`ajGw|rqz`3=2dRn$brmxy`oL-A}o(;Yq?|n9~$QwMg#V}7&n3s%x znKO0q@y!g?B)KOyT}r!Ghhm^Jr_BQrYiFHNLG55Rl4kkoR15z!k)N(Yl&|?3BDST* z?JsMWIU9$QWa;1es4b@vVfmKWVtcaq@K&P&i31l z;+8a`30P|bjy>C;iQQbr^5@V&G=!v^U0`06(j#FH!VK?Ngta#6ib2THHFYxR$Q?)8V;&AX?Rw_ewQ**G=-IiY@#JXatHN!>>gI%vh@zLtO-OG)1v zoDu7F8X5H3 z^qjwKJ2!>El86#%tVeVt1viSq{Wo&?K?fc-KO|}Ie~MF5zpp5Nrm}zv&HCqHf8i`8 zyz|@qIzKz(xfAl`&vNgtJXJ<8f>7Up@2$v&7mtR)uijUzUsUD$S}3@9z0UlB3PMy> z`aVMTJdnhFl+Fr($Ojeo8QMN#{qi}@0wyeOoK&Y#E0sSNe}jZE7wX@8fwGT=hvYux z+LOf~bMQ#cM99<{N5Y|dYRv2KlIXEvreAEcjU{r*j3A&C38pXaXL z5Udpyd2fHa_U3Uh$i_vs;r<^{1+U>K=FOK~*R=ljd?&ph0`bOzg#iT8kvgzV1dwWK zNFHnuZ@VXRGV{Q zQ*HgPJ9YX7m3oXuOZ!c&w@M>GQ+U!Z=&=vIH$^u zAMEHLLiv&)8<@>hO`;fGzWkaY#(g@yeGPQt&CTQG|Ngm?!c+j$ZA9tqQ z!Py4t_7f(uIz_Q0r__ECa{rDSZ+ab$z3VeE|GX-tP$w~v(X@x+;*}YiwKo2~S`gnV6uToRR+iW!8t4eF|c1&&e#p_1+_ zgL14Bq7b^bcO{tVBpn6m2rR{90K@Mr;%27m(R5Q`2wLlQ!Qw<>NARKF_c{$$_i6$n zRHUg+((&b};d$zHMjSKz?C`ryft)&VyO6LXQH;9RJ2qIHVg&}y+vp8g`onDplEVU+ zItWzGhU65ezca~N^@WjhuaSdktu%=d5BSuy$00CuY>wMm%+hA4c!b2M7!^n#`RFAf zEZ`zdy};yJuc{N%s7CXYubDTubgVUpD4y_65#f&WhIBoJn>$i(s|n!ql7}GOimV`B z6oVw-?(0sJl$K9KDt~%G>up>nk)k;uMc1G!kTVM9ltAeM(J5p~4_*3zA)qLM8>H^u zZdeSE|CA1Z zayo=>d>!XJQxCe^C@kJz&X)8fJt!NsP)LN8o|dntXmXYO^!q}{?R;h`P~@DyrJ@-5q32v7 zoc1UL!v3WN{#2gJW7q$&i^$2L_LHFtXAe~pgroi(-k=`qHE*chzf@E6*5dE+jgmhg zT8v-7lh~{%=6|QoO__xscgF*6e*e7ut$^R`_^bKHgX7Ej{7M~Fz)dT8fs_E<)gM*h z=PU!Di^wyzL_W@V zgSm_yxC9B)o%ue??3@@EMBPZ~;sc`mYMP88366_Y2s~t<(^&U5@swjt8u1l9`>Z~9 zJJga?1NGEBU^A6-WJ~}3$^b!oS1U=ZBR>7Mo}R6wIh|SX4I--1?r7q9zz~$I*DDV5 zI339?WzUfqWfqb^8Wu*zlU%2uq7RH;U{7D9NW{-uuysFW_!peXBs+30%Jn6qU_q@w zYn^Jppb1AQGnj8fsu&q)os{(;%W*&3OgxjQsbi4}ZV72G;HVeNB$5qPdY^ zMQGa|Z9T)~E~PLP^^1)PqLG2-dsAH0BEnsJwxZ;hcb6)ErromKrrl_H@`D$xBj@z= z(G~53;Byv6)A3bYF3$yehW!3|s_|C8I}uQ;iJ*K<`I#tOVsK6OJSNZsb{4I7?$ODk zel|BA4*l1Q#<^rOYv16I&ue!K(#s2EnsaMQ)CBKbO*~DM6yA?8W=hYW9N}j-xcG_C z8`(Q-BlF(fa<8_`YQ6?jDPIhdna#Gl&~x0UP;fk99`JFFq(6qHYf3RJ9pf3fy%eZc zH511iSv#`_?GWfsnO4XROu3__N6TnwVe(HgJE`!HHg`8c@AwaRn})76Ej zf3-2Zm{0b*2WdS|gwVGbee8xK&y_0IH<`|Wf6w6@MiY4xq2AC6oo&gi;db;;X> z`S+UL=$J{>&xPQZ+}U&WT|MKn{wC*ttnK-G6e;Jt8N;;KhKzaQ(i_|@r|C&#` z@3{4AJ0JKtv0s|p;594bW4Ttr*YYqRbw1$W_q)GG$EF|OYs8HoX=@xFa(MUaC$O<) zyn1|im6kp*MWZCVRh>TDNCJDy-7y7ocvn75awNb)m8dP-J1hS=WjdCe=U|g{ z8hT|{UYW#3AJ>9l*4Cl`O zcc|ph@!-#E;>3-;qfXPKPa5Ay@0SB#KXr+EpPPZ7&x^BKCn%lP9r_Lsx`su@g@#SL~&Ua(s~wLKN!&*!W>F#~=AOPdDS2 z$CT^0O(=Q^dtEp~m~a4>;NOOXWg5e-V0%8SOn?p1%GSk9?aIi5v-nL6tz}Q*2ZL+Z zwi#(*Ng>ck_Y-^s+GXJ-&SJvSekI9_#=G9y=7tgflxOnAUEs%(RkBb*mUVJ0!sBk| zmH0z-<}sN`yj!xG=LAQ}E0mFsn7-asd50wT_YaJ7Ia6ELGkpu@D}sfUjTk$!`>qxHKihU>x$d#>GbkUb zcR4@HsN26B`E{xB<vGo&^F)i>ruJhm@`RY|=N%Pg>XgLlWAlwl@+S`fvtPi-c)tE>z7_3x#sLGX5BVk~ z1@?9f*1ZM&%hb_pp{shKyIrA2M4?wnp-*q2?`om{uR=UeQIL8OHHr`#Q50TM6xmx8 zy;>CetBAl;OjIvUuq#fAC{8IUPU|hspzgo^Dkkxi{Ab|Ul@vyl6ql4x0rT?JlFDBt zWS-I*_0l@KQmSg*SW?)4i zpE7G5N{*<*3C8?*K9#Fxo~5T8B*Y~rcrytaiSU@YY`_dlRPWe1UlRYhZblL>K2@vA zrkyAmjJ&2}%rp4s7yEz(!aYZ;&$xikK^HiS<>hZywOr8&JI7LyT6AxwU+`+I%IZ>? zwVw8%RNFMSwQXrU{KsFV0_^q>EAy49vM%n|MOPHAzHnssvYK4oOlm#3u1u*Y%FOyp zf9l|BQ0KJUaaz!_JhrFPwe)P-$3Lq3rn8vVCpG2Xxmr^y3GVal@yv}Jv9#0W;EuP$ zSMKmQefu`M>f{|Nm2uJP`~Leo;_@~!D?P7YMA@J3mOHZB?&mu14rM*zha*gE$Z^|? z4R2*V7+II@v|%n~MSGo5$j6*q9!k2)To#7M!v! z9&9bz8ZSgNdad2i-k8=KsM2QQ^=RxrM75-+zpQs0K(aaRY!we7uxt-2FG zAbgW8i_;Qc@J#F^Gd-4U$P0G8^DwETkSihv5CUkmB>|Ni&F7Qf}q z#Z@xNv~D*ZV|?#@!~+PZLqzSJYM@ow&ZKW(wwZeVdF8Cu*&qAnIs&)@t@>{Pw-Y(x zL*rjX+U0aI`qU{_q~AxZxgz+po}v>`;h#(rE`Q52nN5PVFoC$6V+G1r=1flX&x@Sq z$Ipr!)k5B0+*;^nL7>HTS1Vo+f*!HdJrB5pSc0REp4|BZ1v8=IKp`XNviy?b9Lbos z|L|a~3NoloieB3+PyEzwh>311d7ulHT9wdxlPvu1%xdK!M`$*biBk1~vx99BS7Ye< z8$v6D5O>WS5QEpjd&|k%f>OjJ(5f-R7gshpHM}v4FYAn=$7sw14E*M{4*U59_9c*o zhmeR1cgYr%4ihNodFTvrY)oweLBUq5HG*brd{l%VUbUYzH~&`s{THn>$c- z)p<~AFrwF}XI$l?-kEMQD0dLp*Vp|zN2q4MD`hh|b-nMPpjppUfG?HPHVLlC`5`&U zXL5=n=x1@l`#!_hc*d3YM{(;bhqnhL1$TpwBEK6a&~7|KPYUoBOcU3oD%4T_kw3~_ z5lvQKQ#DGq?-IZP~_Udu7ZOz-G@kFW?H(k0g<0B_BViOi^nHLC6soSL{e z;d>Yu>k60)Pgp3uZeAGdTCcg=RGKBVz{jD$sG+MSuI8;=eGJ81(kBySj0R}HI55Z= z8AqE!u2em{E3x||MMusZXrlYsbP2;-wa#%^!HDCv9c;RW*hj%^)QF4;R72*F42SLw z(qF?vc~EjK+j@M@t(1wephCyFI=J1auvOTQk^_ge6reW;ZxC_;7$&4as*hF$&^Q_@ zX+uY$>-H!KZRNXk9%gdQP^bEOi>etFN}{Xk!Qza+$*fzfUd-tp`-uo%l<`b{WG9A* zqfs%6TkBG9-qE4IRxMPdZf-ggAJNuXt|61;{(C-kfYRlt_9=IvZ+>7ZrNg3P5U5MD z*<>w(?W+I?969l-HQg0k-TBI+1aTR^X4^4h+b7O^F=tU3Q}<|D+-Ru-0BHx;BPoCzi`)LYi31dPYiIxf?W9By<$ek6u2wzsJz>dhNOh zgfVnqcKDV_tW;02vNp((85#eRl{|dDem%BmW=l-t*QBXdU|M^fXd%b6%WA6v$+p(E z>Yj?6+qCQpD|!%*84ipBhLT&L+p3R#Q5}~1sp$=Op+7&3uWbj#Thi|cWdADTF?ltS zhD~4tOV9dg&8KoXy?iBfT0zsAo639CEa=VC9y<5KciKTk;KmQgozQxco`IsSR^+6K zkxJbaEKG+BWGeOV{yk6g8n)K8D`qw4zHi>^T(!0zS78*rg(AGC85W^XMF{-X%IhF>h{HpC7 z=~YJ06o=R+0FviR>02Eo%P;-4lV6+SH@|Z9N)ielFHYVC%W6W@CNMM<6qqOD-3$#d zgv8u)m;TZ>IWoLJCh)KHxJR!1oGT30^TFP6>U_i#KC!O<*#|i?3@i359y}vf<_VBPKDyUaUTe?!uA13d!#0^U^w%QSxA3*0=l&tveR=V* zFSb=|-r}hx?y4g%*5D`imBa!C++AoWRlku8ID*h0Z>Qeuv&xi)J)hz3lS|wKPzq_z zDW~tHgN?ZLf<3znZ@njh>mgne9q2+1^Tn6?7cxn+v$@SUQerJ>9s<3Zo9 zMJgvcvyxoofv9#kG%?i6Y6Z{-AZ%!eGWv{0#Wq;(h)s<|z5WDNR1Q+&oC97i>LS*lBoquS#-XL!-N@ZYx z<&zxQ4R6+JW#66uRX2#{_EnD%qsW8HsSlkF#B|v}fsVM)5?A1}QK{Qx;-5t@1{+q>>oPnF zRl-AmOPoiNflsz&Uu;3&Q;H*+Zr_^(bUze;v7i;T{O^)ZHs~UGJfPZJ4jqTWQ4pJA zxe;CM1s(ymK@hiSLH4Nk)B>O=CdsebD_#yxv$O7X535q2!K>d+ae(bE8=7DV4W(n&m##rfm zsm(Zu&=7hVx%Ar^XygGWipr&aD}|F>`6Vk` zT%@Vm_FY!7Yj;Cp4sjl=NKhgjv|bhZMXgXcqV#ez7)&l4-EE-5mP3dT#etfrwAya< z2F9tptnge2^&`>%9TZe|DvJuWWL~@~fQC$$lIcyF9(^E>P$wi)(f2~nbp9yDTu=d9 zMpR%%JQ-A(&)H?_pi7PSn?D$Wcf7?PN~Lz2G-&KLI1IG(mx3+13e`@*TEPYSAlA}5_@&85|y+iscQiK?N!+oukR*|>kbspF282%)jh26FbB=f>d{^_wWD< zuEl6QOBCj<76ty$1pYW$`?L5C)oSoxHI*xY{hVz0HbGTN&fF(W>OLFQwR<+QM0G0Q zo7S&AR8c3x0g{U;^*E(=awMQq$-un@C6?YnR*ip2+r7C_pwD?PIHFtl7f2lmkwP_` znq)_cg8U)~vZ>&tsM_dL@QtQ>jO+JU>7%Z#H(a02D$wYe1AzvlDGaE5-j<@Ty>Nj? zCaX7ZlDsY12fAK|nU=f7Y-2NVsXYi(i<$$JZNK1lWPf;f;r$Pfo<_m6P*93#5yw8| zn{C}$+2drX-e>8Z#7E|Vf#fgTkd)Qla#1KJrN2#C*jEvCEJip#XBIKhw~7WWs+E2; zePESBgT@2D)_Tpz;DzSCo1+jn3`BwQ^s6msw)yPgb&Vn$jR9+ofzQ;V32Yx_q4SGc zetAo4Azi;+qVG3o+_~tWxBD;_Y^DNw6pXE7_zjlFf*2^HpVr+wAC(?BWPjrUWE`&p z6j-%g_p#k@Ui$F+-pAie>Og5#m&>t8Wd5K%Nbkcygmr&3YLIW#4ZH%dX@;($K;P^~ za~g-%kIL3LL%>+*PZM!{6cvyjhvJIDd`uN{8w?%F{%X`+kQtbvevg^}Rc&BSyM`}; zy{C;zPMw6JA&(+$1LIQ6TrsULGghz=9YQ7p`QFeBg^?btKad#-hU(9Z6MpB(AGh=v z7j<~n)kb%6pn=)Q#uZ1lOuyArlTkC z>pn8cNO`&>m6v`xHv6%MK?9<-0kOk@1U9U1WCU^9)*y@dRk_U6xK zMbA@=?IEtQ_h;@Y;m&3mcp-y`g)!yGdUm~;Py<{AgRa`uwhNWO%smJ>bK(`?Yf{(o z8+7Kl*pc#*c6Vj#cZ)Q-lHO@Fi+N@5anR_iJC9%_lrFH`xZM;A$!3157c`l#n2! zzt5Dc=NxZA6utZT%^$y}vqhp!NjqKghAH<2E0h&ze*SqnMF(|8dFt-BB}+Bb`n{f> zEHj7!VmADYw{zL3JzSYitC(j-gnBmII>Yvg#ox&l?$qM)AqQkLN1}FpFt{(;tfZcy zgyy;}e+T#NyaXtQ#gTIkoY7IKYVnKDDl4 z;$U{D$3q|1U8JG?k8n%~AFM^iIADTyUQ)NPsqL2&0R~97rV#sJ>_DcL*3+vhQE=3j z#$R)LKk_+WKEkvi!u|5QkrC8VBMj7bp(rJC zCJNlbne|NfbQ%JHu@vzDrij3-dL8F#7Z^yA1hb>SqS05yEXHJOi?9OwNr`0U*;b??1)Yb_};iOz$y$ zZph^C^ZE?Yz6cS+Q zw_RPJJZA#R@$|-W#S2zskE!{VK!DlbOz1cB#oY{>eDY4xmja*Er_326;TQNoJfm{Y+VI+ovX;|5s<`+s|3Z znfn#p#Dxjx00%K}v9q`{04+*!CcRk!>k=}Fm2 z5+zFp+Vx*K5NL0cj=}FwIfMoIRGCqh=x#u}OjB8qAUyMr)*C+rP+))WNM)BN;J3%! z?r%eLE9DpwN??eB4uV60BUy=q!w_-_nkysDc)qB}IRfAT{yR?nAF;a*&}36Uv?JuR zb8@?Ty1V`pUkq8L6d;*W@(hM>A+?sOv)20z$q)oYD!XIFSfu!sF~eJVc?g86z8EbT zPO>TTsZ};r0zfG8=+6I;-QQQ^=VaKEX~fYgz=F|yb&vvdgca>I5a$ZU|HN5t>FJmi z9N>#>DAb&wgq@!yi}_LpcdzRkSDmj^<%O7{&W^EhurG_9A2-cSbD zs#ef%G_-8dmO&~-n999yFavK|50ug5)dya`7&U3*h~uV=K`WH+xizx}^HQYrK?LZA zagOtd8WwnGm`%%{!Cl(X{(hW{uOktHU9UJOM6iHE-EC_FO_}*8SK?FYXhFrTL)9B8 zHFP?MOtqo7;IoHIx>sT*xaC&meVm)R+J(e!7C73;_B zR_)a{#V!#{amlU;@!frIrBs=E`+s{Nv3w+n^d)+SF7CtAPVgkz;3Yy(k3mX8Xn=)b zMUlYFwhu5%RhrE$14-Dt2|*n`+<@wNqn{w!$G^l}W0X$t1Dp~m9NB@#=v`O)BTZW* zRM^OxmaCPFBEl7I(b|lLCj|abRWGg_WHtj%mr-#a02#A$k7Y&*p?@+j_IWJW`P{v1U;DYARi05*?G!4A-<;*qG`p61#O2$10m4(I_(j^Cp5d z8_#UhG}UzWH)}!KIJg@Ow2_d>K2s|RRnwdt&Qd&77~^2Gg=at;m*xy>6u|@9`6+Q* zIc)41!FLOLw32kst71gc)qfZKs`7<68(GRcphXSR^Y)|S6oX2M@eI;tkaJdNJlKS) z^UByo^2RJ{JXFg)2h5e0Cghe*>MDC~@4Fao3#p%pAMQWiX{?1yPLOocW)p`5?(Ky% zI=7BZ7JnLQiNNrvLdeZTWY{P%MQ97>B`chD$eu?{M(2E$sC2YMCEce5ji?rG(ZG=J z#>~u9o#QxUB`15=fLlnSh7A10dA?32w^2Uq5; zfDGQ40!eEs`XWBF_c^8LB$7l+3~)u=D$Jn1#w-D0)XN%pB5WWCdrKarkfJx`A-#A+ zhG3*$#wn~h)9bokHDqFnckPw*0`2P-nwxSzTRd}cutKk4B7Ua(ZTGEJU1c$BB6bV; zh*ASv-@$+4+`f{65J6?G;%<@^pv{`&;iFF|=#(CWD3T92heE{ZRt4#Af<)h-S9$$$B9UX;**W2ZbLoqh7cKFFPeN!$p|K~mL!5`HVh{om;G?EH z528!i{UH*D8ZMbqOrCP@(Kk_Q6zZR?24r>3jA9Lgvt@#izqk={sw_~@-5T)8UTsiQ zcsqHZm{qBg+k7Cr=7x_!ccN^epA4Qb7Qp8&jIkS4P}?1OXgv{h?k~K9B2N`1#-+i; zj-depgrhGI2JROrb&vs^6gT!{eo+>WUPei}p6J&72$N^tGch}Fz2~OG)qaSp9yHBv z0;EB4qzOMC?s|smk)vG|ESRBLQF6uEtqUDCz1&=ZK`gh;mDF90d~K%6`wA`$nM5s@ z+0Tj3u)vnFj7>e`<<|u#j{G?5cDbQE4VudorYO2M)HYu!mV56ja9yn1Vp`BypS^`_ zeK%Nwuc&{T;>z->={(~{YZN(Yw__l#*c!joq7w*m`^-ZGE-|@Z)@o>B-7<&JVfk-R zmyekbv?ve?t})@!d9HLY{KP_!^;?b1jb=%j$@gBmeuTkI)hC%YTA4hj@O!KiL%Gj4 zqR(QP5e90Y9D$k^;n5xG>w8Pq^9R(K_y#6VM_Ku8c%1`Zp8Orew}kj{cR1O6sD~nT zc1v(5(j{7*KM8^~O)3u1X!kv|s1xn+blAgx3uSO0{2-omi%;L)OR=_iL`n{lIyd9E z+#2w-jCu3Z&0S>YS&x)l7TOHwukhQ#rEnn!lVgOY=17%`{lq!@24U0LZ0%9O-x`Gq zXL@q4Y`8ZIGf-(kiV5Kr!dv$_l1WY+rVlvkN3Y>t&Jx?T{GUHuy- zwn60TkME8OOgW^uvjOaz29QNx|kwBsx%=rFXZ?UN2Y#BbOT6=H z9$Ctk=NAGpxT?wJqh4o>!WH^L#bD(0 z>o$#5$9Gb_|MsVqrjfzksAr!e!Q{4i5m{#Z-tN(yJ&@FBWGSdn@i-85?EgV5sSgZe zjxs=V&g&Y+;x!_=?K>Fj;j5S%da+7U!7%c%u3_IMHY_P|yONuS4E3f$?j@mb#R_f; zapkofbgD=B1t3|;n(Gf(h*x$X4$e8T@;u3s=L`UP6Tn09peP2i5(daqvqCQ9JPA*eZOy{vBGT4F z<+jrLZ6IplfFK5_eH--v07mu1^sRscBzfCF?MCg)l!UW_L@zrO^$&$Vrpar6%)5@F ziqp1Ht+(Etk5Nu=eeuqS6KeI}%33T7D@dXh{(vcypuB75Tw#1{Tekn{{S=En_|;N57AU4iQ-ctc?_}i}h8mdl zBvH#V?}x<)*HfIC=jMcM0z;_tH}jR?v8<J!0zFS83ns%zIR$Q2(6cHc zqcDgZDMnO`b5mw#sA|)c3A_iWic;UiN!Ww)_#$IMxCajL@ohlm6V1J5e|6Wm1xDDL zWbX1U=;pZD_6f^}WpL*&#k=?jn;*!d$rukp)}<#RTQLgX1oWjv!&Zdo9xNaCn~n%B zTX!S$UcH>lJvtW!L{i{&WDp4?_^zbNks&s@0!Ac#Y#{H$eTlbJ`|Cd>`t~5oWZ;AK z!Kln|b^G9&O4B+5;;J_H`wX`)wpzLr&kr~Lmvt(Kxt_~%CN3ajujke+M^RNOFdhnu zEOOJ&5ZUzn+cu%O8!)m;v`3cr$zKQV80j3(|yI(Uwcn*UhIYmf8WDi4YPwT&+4hB~0C1usS2pjF!n=KIpRDbNPj;)M`85r6wyi zDr{rMswUn(Q4TPmz`XQot5%`_D*vu|sv@bRYeS8vKfZPn?)>f4Y87epSnziO&6{Z` zNU?VQ!gtG4z^Df<&_llw0f;97qKu28Ta_a-44qwgeZ44$i&-MdzNK8UTQe4>!gK*w z2rG6mq4trtH!sfOnc(5-I3f|`GO`9f3h{lKXf(6td&_V^G9#MH;QCDa)^s(8vp{>e z-RBv8KSoV(jEo8k#+!uJOE2MCJ5}!)*(=8QjNt!D4BB8ou=E&TIz*nu#%YHO7_kU~ zgo}Rm2`VBnH{K_ER9#RWHSi|M31tbbmfGfGqSP}_WaYVG6`+;(t_UEaU*^QhxhQd( zILHmrpE)L_HSH!!dD{$t!GxMJ6yymVO%5G+M%2++{yo*^2R(Yc4EJ_A810h!)}WI2 zTS^@R7^Rrp#s!3%G@)4_-=eC!m>hp(eUT^xNroJzv=)a0OR&QoIPoMmCxX7&c@wt+ z0+79xhPw)&OC`HO2%&e&o^K4hzb(W%WAADXE=N(O|tySM;|H@PGZ z2Ivn6D$SyV%9JOKtq*Q$myr!Jg_127+VCEPrC?B-)V?(?@GIxs0j5(-19_sn;}1a< z=P0CrQ#wN~2~+ewyj0dd=Aes&-Z3bbz;Xo(Kvir!l>zAJ*^UXc+!sqIj@c`f0*=dd z2d|+`4J7TclE)k4By_PoEY1QdppS8%2ECUReNVf*NV2*K_*ZiQcxg4 zjS=s-V6zvToavOTmoIs=hX<=)^i9Q>my2m(1XH?yP7;Wm>K1A(ho>$AlNmgS`jSusIz0Q zCVvh}GO!4I0tNbNW%z7t0@px&qIl9hXMJ<6)L_Ul3Mcv8du+@=83P9Yx$~g4;6z-8 zg~DN#a@(oA-7b5LwJYZ zZ3?_uQT9?^;QlQG1=7?)sp?}c;96s!@vo_MGN1W+kEPE&JmI(?d0glRl;dF#=5Om5 zir=_(e1cNPOS3niv><WLS559D8PLs0(Q#cph!q+v|D`5nVX~ciViuhtcB@>?52<;7` zHR3sPzHrz_M-xkA%i0sdU+ja%yM@z#1V2i`cILUf|K9#$B;torA}FgbU~Pmb6Gmg8 zBUC_^eq(3!j{cLWzT4dEMC>Iw5Ql61mkKH~&mXE$$~6S{-`M(m^}r{>{%4dCdQ1LV z-&%)O(g5MKNU_VX?LnL}1%LTV`G%=T5p+s>+uhY7uwcQYj&5h~-K?;iXoj;lxLj_O z<;=6||0uQ~Ni7CJ37YF1=kZZVljHUJqY>{nO!|+cBnaMC;EoIPCJ|uM7fr$(YRJ-0 z$rq9EC_?BFQz>FI^p=dEldJ343Y;KoWdF?4hC7|XCqQn!(N0@Pg0%=e>6C-+zvVWd z#{`qu!{ZVUt}9M!EJz;vPemmD+|>7Ddnz)#77qdKMcUsL8JLB_9_}lVP|rK0=(Y&o z!8W!&w-V8oYJ?ESx^Db}&JUZU0t=tkxCr!n7)e0j1C_6e{-5KjB?c_W6^Vf#dOg-WQXY+v=N<`QCz#W)hey3Dn@hfe>Y8Ip{?DauiHHnz&jLSl-p|uAb`i{f31-%feIH2+nEq{xt0FlCxV7!#oL8i0u5w_2m zwswO8w=fRWp}%?bGDI)d2zYa4Rpm)g zlR1b~5Yy55*_w+yTOr`gTd4m1N>TEJ*TXIEvDQ2A_i8vGq77zEhK$WiA0D@CB%-x4;#sJjpw8iO2z?c9A)Th)ak8f^CO4kVQV{zZdF)#as5a(4M zGnmn`s=v58NAIvsG}#2$K#Y4%g-bw+C;?Og zmIomK9)OyYV$!-}c1~F+#R(<_3%l_D&O8j9FVN|IgGv6v-OP_MrB^sJJ|3SiQW5rO z^MqeJ4N<261l;DuBna)()O(p{-$dK8H-mE+5F~&y=i;ZZR{~heH8o&Ae*XG#=zy)jEl3#8 zPmjP0baX%JRT*`LF2{@O*Z5-7E5wJzvCj!TU$S?ZENKQ9)AHa%hv>E3nTEFx%gmrY zPZ3E;UV#LL;O2DVpN@@GF&3x_tzwGv?twS z@Y6FL!1qeJCp48hy+NmEC;H_}T%JQQmHML(va1&PEy<(0cb|L9=jlld zuC4Hpidgn^;}ewUysU7U!+47L^f%}frBAWLK(f=WHmxVW2L*fO>U80H$ZO%n#|`3^ z$s$7H#Ehp-cmL@`J#!|p*vdallu-Dkp0Pj_qor2g!M&LgbweAQ!LLj5q@NxoFo`@T zXj!jLjjwt5LFA-ZrRQJ4!l*gfRLp3u;<@+*aFvEL=jkWlUTKY@0G`kflLF&BYF3z0 zthX1Z5V|*GcqPp#s3lYXX(3SvulcW)%CFtD?{J_UtYoEgm(j;zz<+&S=J17yi^RK4 z7OOcKrhyi+|9KeOCldUq4Zd<=qn4Kw%hD~;NGs0yK>+w_k%>aBNuJ$?D_%N`T_T&K z<#(wSf?Eh!G11KLDjx8t;#^EdzvFhRP*=+HT#gNsIX$5S5WU0egDr zBo-|qg*88>&Dw4}ymTj+8Dpu&%U+AYGmSCf zM)oX)Vn$I41%T~OGNDKIP68FhgG2)&$8P^xgCQ9VsRvCMr7;oZC{xQ60nP~>hTEW+ zV(1@;{qQ(<7tNv`icNJ#%=MF>5pPN z8D7rF^<}5Ih=^MK^@PQqht6*Km1jdmGHbit`Q%LN!2sM(3LK3uj~$RcGjQL#V&j5L zEvgG0;>k3Z4^wRF5E9fE%?jYbyIj}A{Z z&5*qK0yAmrz5-D(Uu@MZ=?8~}i1y|uwge|LkZH`?!-}mCaHA{P=ekRDq$>uu!3cMb zsFU;~W~rFc&Ss!W;eW%l9jgHo6!$1rV_tOr?@>@>Fdco348of@!Dz*Wmpu$>pLaJ# zjzEL&5C=|AgxdcQ6gF_CBX?G2;@RBf`c#5qshk5O$^thMzk$90<6&Fc0}wYVLRr)c z6KGBt?fHku*QNp)Rz?6vtWw&1|Cr?Rb5dN60Qpv%Ray0lu0gsQud69vFp)W$Tb{sfKT|@XQg#~ zkq}HxH~9srr3d9ePmGfxoJlBgDFF7^a@kj8N^0IukDt#gOy#x`jf>>$jSy2v?66;~ zn^xgh#N@l#(uB+gE6Oe?wz})@WyZ_TBGrrv4kj361hUYU!aeW6Sn9lrkjL>~V+f%N z7H3_K3`;l}SsC@+oTqjIRyfJH)X#GNRdE_dPM`{+DOr&T&FWs?R%1}Zp8fs$Dh}%w zP&=Gb@Omt_{XvW8Qrj+}oQ~N=r&=~_*?tgA4HpUiP`MJl?A5rbB1xaTDsYJfpbM#~ zhfQDm(Ei-doyi>@)nPu4e21zmIt>%D>o&eY0=VfDzAqrBVz}z7!d&*7+G-#pga6#JT?2{dVWaGpue=`?f*%UGm?iV1h-U7*! zDggzIb*m*ehYZ1d9|x64G{eh;zJ-a4H(^+v^leqvvsjU>Ks z!C`18+K>fAs4bTX6Fc~3gtMTxT}TOxQ-;~V$LkQ>mV`K5rSY)0nnLj90|$5Hnw>eC zQ8L=W-gNz>9`)ACBQgFJY(0~pkrNQHC3Qqx^-V=#>&b(OOg9FwA#^9k_u4m4r_voV zW{KJ#FaEx~6&uQ=FhN!*pQr}G|Jj+9QHf=9RC*8eNOVP+ixrbwBQ=bRnphrODJ7_+ zq8RwbFyw^f%JUO{hX+(~(COP6C4x7?&B}j5Hz~x>1D)&c&-nGkmn~rPe%%jSo&#(qgjKukVEpl;qe2 z2`s1Tr;LApbP3pEn{Ln`&Lju39OwOd+tKUtH~chYk6-!Y_rhU!?BvtqS&Vop(bG4xQbLbK_8;Tgg9O8V%8l8cwnmuT z6Ge)U0x~Ja8EYhdqqL>)wBOIpTU^)X#0+9pIFCCJQ-Y9-=ZTBgQJ7ZX*se_nDdScM zgmYh&QL!~i#+#kU=p==F-8@V5$}khNb)^}d6ii$E5h;O@4@{yCA$e~ZiprP5kxyu+ z!ElFUFh4mte>qo_aPsi3WBi3|F}+yAhG>I9*4%vhIT}=_=TOB@ zHsQDI9>_VTu<6B1Nc-d+iPg|tTBZCPc*Qzp0#9*b|5|<%V3T zi!p%nuL^g2>S3l@Dy~Fsp|CNr#N4=oRSo3;9hUMm$}*BduZSdor%SUuRuW^E%1#?s zW$qg2FnK+vE01ng#%tq|R9byCG=+rp#(?TXRa*uSQBx60r(961n(<0bskGd%sk)Ho zY1U(NW~JP$J>_wT(76@kKrZ?zoV_h0B)+QRUbxK>@5=kg@Gjlp#ZpR@_eIxl#zGk- zSxYsCS5$?ewKBL$I+sfNnN*W`#3=%@puIMR4tLcC?}n61U|`!#3C9vVeUxnbhb~{Y zE}MiE0nCddTonv)qe^?KC=S{&ROetU^>VL5suUd&mzx{JCSV0^?%uonTQy&OS1)6O z7oZ+ok0_Czk-`(i#(&8zwL^E#l*N&t5#@o4?V=p?mh%C_A)%J~3v*Vx@=yB}{Y2QD z-C@v#0sCFEIstw7z8Jwk@JeKxuw0{*D-CNb|Dfyy=vNl%oh5(Q|85smZ>Wr)thxQG z@SwQI$DfJeyA4VN@XkHNgMC}U6{qDDkzCdVuE*YH!_CC)VDniCc~zA}SDPm5$R;69Ius~l{mdM{0S~8M z3h6=m?%LoeU=+m-wOxkk6}bshk&|yd8+p-Khz&}Hq>#4@e+*LV?MpA}f!=g@j*hb& zq217gATCg9oRqLi>lfKf87ZDJ=1!O8PZ5GRG#I@^rWcGwhR7(t`2w2 zp_624yFAZ!?+Jk$Br zq}?mHPe}Ee%%48?^DdG20L6=^7eQzUgN^t%s3}Ofw!3ouwQ-5IdSC6N)Si4dE4RDc zBo_Ur!t75Uxs!AGQ}a65`jG@VMR#-jqkdtfBvkn3dvu@M!8(r=AzDWJ>Go?mi#J97 z+}t0|mATkmT5T!)<$|vV#DrAss7_0W9Q^aW-}&anILCoR*40m>UZFE?BNc$CkUV*) z_uQY{IrQM4=iQe`gYK%*-Xw^F_k{vq&tP)fReLe)d`~~L&8<_he(yR!*LIf7f7~9B zRjPrz?wESAT87~q$lOhA1+I4ZPyjVO8juZO0$X{jKP-MR%% z7?ueTM(#apG5u3)t^o!-*LU0D8TMuP$1#w^DUxxy00|m!X<8cSz~iO_qH2~UZm`dG zXEV8s9V!EF!0mtCl?-NIAlz)iXNS%Kxn_SB2xZhN?Y2pbb8>#et%Jx0C)7gT)HGh9oh~(SarV*f zy|@JIo$R5$R(Au_xq#FO0*8AcfA*tk+qkZN|q(JxdIn zkbYH2&!xcUel>I$BV60N9@KWPsx?bVP29XSb~t|i5nXY8;K+l(+w_R*{!$A!cDVe= z58pWr@=6!KS7gUt5L$FisC2NL&WRNG6Sc@U>?pD`$2^#i1N9-H;@7-*h*NxpMZ zC2e!#*!7*qoj9n4|3Y$)v~{;f+7rI3m1$#A!FT%Sx>1L<)SeWIgS^6nU({|q{_E4C z!L@d9vTkim6aP4&5m1V$hk7MPO*?f`o?_FgBS)TYI)RUA0}_WW8^Lw_tI^`TDv&?- zKj&I14Njz{rAC}2m^s0Ab{4aCe3XHK;G|_uC&+`{Ck5T}szCef)HQ8!*qiEP+?&U5 zc224?R!*LRhgUQBJuiFP=D$0615z-YGn*}T0yyrqsO%5Pil}dVaXVf80YB=nL}Se{ zgxGKzQ0 zSWPwnXme!2a9&WgGTlU3bL~`XdVZi5C4|G`K>yg)FX@NIm za8n#ah5$=m=37{={6=_I=GV2f+FE%4aVAo+chF3e z_0?&??9=MjCBU3m-1*pKY><9RB;EhS_=U^UmWi*I{rn(be8u=t#5ssGd%}o0p2_Q9T{qnr-L{0 zWLWJS_wCL*#3vw&c=_tHj%Te2O=1s$S7501X5ABEkZK~r5VCSUBw?_k+ye;<22*iM z$&B~eM4iX61s%0|dL+-&zX#f!ul?unLcqCRfa%fEunsi|3Tu5(dQiYlgBG4Pe!dle z1+d1VS!vF}a*O9X?|pc1b;}k5cxtV!p42h_@5s#e+zi{~bJ0ByCO(EL?H1ye_;8;j z_h8HxZ9O9NNQD7sTJzA(_}}OGeyB7zItEs&X^;Yl|TBpF}p! zM$@EUY;|YFE(&9N?v*lbUFY*|`hIVAA?RZoe3b^_CcXjb5Rem6CjRAMFvYL;x2;;Bk;t3@~%|?}Y4^BUj#^y7#b5>PFu+_CjX8w$>ln z5ZlL|^@4X~(eWA3Q~-rE6O_mJ<>YYZ7yRFgEk0Plw(>&N1%2s@moC>`)E7Xi`sE98 zwfzr(X_GLv#d_oE#d$Xeoey^3zJ2)aT`T6@k;y48IpqplRioTTj{pF(ggMUvV4lBN zefjD&>$&V3&iQuj*^_MyF#pL9^FJ>}rg`w^uOdI4>VK6;Gp>Dih4eh&hX^A%_P&=6 z7bowxWZS#Yo_(*5CpfpaQ4Ld}$Yd>klGck@ns4`;5qQZJD{I%~ckCl+Ch0Mxnh`?; zOY(#>)C6M4D~GAj@~2*MYx%i(_^#v)xXu{N$0Ez-^6br%>}$s=t@0>gU;J-gIPthY zQ@mX1NW|hSgee!4&fm#VR3GG*%w0g)>M98jE-`q7Qo47()UrHW!cu;%yWStvImRm| z<49s&?ON%Jv@Ce_T_9|3Am-2;RkCw@l zQb47gL#2+h?e!T4d(htwXjAjc|b55hV z))$`0^-B|MLpSPeYfO@wSN^{8YbZ&d#oCR$x8@KuhS z=SE{Fd`dp!ys23_M25)MHVQAXCWBeFwR%U&91XUQl*?Z7(z`mj1mZ(_s3=uV{8uDs_6$)(kO`>C-nj3@eQq4? zQla7deP#MGZSw~y-c+n?%U)4?YpeeSQBAc%QOQV@KTL~zq2=>T#2Ba?QaU+2(r{}H z{dp>OvRJRyC$cKd)ziC9V1F%25ww|Oi-pZj1VPX?0Vx6}R&D+wn@Y{Nq8s8ss>RjY z!^xlSy^C#Y&sXnBv6lV5FIWJFzUlJ|HL{2&259<*?2bOpf6_DlG(uf_K&bJibF-)g z6$&$DJ>Tx!{T;`=Cg|6j#UtZ>5d^$)sX zXx9Iwso(Bjuvp=@OHD_0wBW{H*PkV-@r!?D(Rh5BJtuGLetrKgSs9b ztaoCpLC;d}MS;$5gH>~1C&L#D8g_zw;(jB&SA%A`U6ihyhW>gBmv!3O5qRl5T2k|M zz501_W3eVIG1tswzPVFx|J~GqTDD>s{w-OWBEpmm4_n<;&=wA)~k-{}7J~K&|}G zLwiO;Bc@+p)$)n{$qms+hdgiH%DAsg1=2y|K_V)B7q*`@p*po*x}x#*5*qeuMy(`{O{hZcRaOJDA_1&Q^Wq4pd(|@qGH|O;6LI@xHA}FwuIW_NZ!$zUzah(*T94@WDioK1 z$-R7ReJ*ys6Sevw@$l^x5#HVEtwMPIzGHwum94f)RKRD5n+ z<_dun*XD8~@jcWr9t=clGY55Nf`!!pMr+ePi)HSFy0~sgilJi44mA}ieSJK)KPk`s zA+E(Q74cx9s7&f{*XH}NW?PwQB1U-{#FDubp^MiI@19vTPT9+l%8U~~hLac7ph)Vf zeTm^?q2ko0Z5lZg2hUui%FAa*&l{*RUNIG%w{&Q)#K`rLR+~Dm8*-fVRB4A@E9k`P z6)g>N$nIfNF)GZQPcA@PRePI`({NAN_SbUFtW8IIMrO3)wdh<*_AHSCW_R?~9sKw} zc)qbJc{^DBDsF>ciws~U_;86M7KoNifxGveMf}H`De*&dDqc%<6}zuB+_z`uLvJ>} z#nFtFeS4!W>2#G5?D&+o(BlFLi4g*m!a^9}56(g-hqEcGMbD_e8kZRR`}i&AZ{UAShou5 zb7AtXDzlk+T8BiG)gWZ6JF)txfmLiCfGNenY+UB}?HK@rC+LMd<+x`Y$mZ422wR|1g`p~OzV;7S4eRGtw#||%;673gY zJQJxsTW}#}l+TYy<00eTsvfHmmcwO!SoM9wW%U5Uc_R}kZdtva{QI$YbKXrH3&b!? z+7P=SN@RFa(}3`x^HeuGy717B_lxt19u&ibQ%)Ay%!Us<++<~{j>GR=M?&(cdKCug z+%0*e^XQUV1VvPRfr_}^c66%Y$0>^C*PyTqw4p~YtEKD!7+?4<4)Okh%HZl-ZP@9` zp_G2j;=zduJ3;bw0J>P$(f!CP^Q^FZI)MA+@yWguKRx_1X!$1MZ4Hy1sie!?`_ti`wU$%|jkaU6#N>BtJhnm24;W^|N~3 z(^J>sj~aarD{sYV*HI6N^;;-RlZ`$fKH$FF|4%k^YT}ZIBAR^UqpA^0UGysJZvbk3 zZOh4~lrZJD@uN@LuwCfgi@Ra%jpaq@73jqu&@noYPL7y`^(Dl%wIoU`qfMIFVK6ZsD;y7gFby@0K1w|H z3z}j}|6eUFIVqr3Kqf(#*Uc58Lk6CTYLa^mY{y*Xj7(~O(3I?AXNVE^Fc2IDaufrR zBU0sd(+}^Wl_{CJZN^;W40O0m8cx!W8u9)fUs8slJPs-X*wthxARAn{7c-9=lIlRf zmkf~?4l)s*-{)?2g;VoOio6tug|z~&|ALfi}TrV%W7vH6&F9x8-rKzso| zj}T145&7|ibZlbk?x3R7cUme1_7|CVzQ5?dPp67Nq8OIq#$~2?1`7x=ho7{ndu0w^tbFf5pMTBQ{h9u!Elc0K zJZBma;$C#fyK-y8ZX*U}ot|T9U%}^EDvJVwG2nN**c)xR$oHkbD60QnZ1gXfJEqEg z_d+~ZoM(+}=$2zw#ZlHmWxxs>Hw`UyZ2+)6$7vC0;e5dPxhAo0zFNZVtPX2-i=9vn{jqZS6{wQ34d1 zlY z4~dJYnxHwc^$~F#KZb}1Wu9yJd4P^|JU`{bQaYZk487Fk_nND&I5ui_AR&>i8k(na z%7)`pUlg*Y9>`^v=l)EOW+7y8h&PlgHR7Dy-<25gB+Hv_FIEte^Nn%4Iqvq^=2O9z zn`xf{WzbBdXyh4z_IloQylDofxW1;Z&%RXM?1AtT#m>CG-83h5l$wG$5;EBe{D4c zM)JKS!K`tNqzJN`$MFd~cieo7BneSyEIdPqYF|v+vNp2mGk+EwL49evj zj14#lkik9|r;%OQ9r4EM_mJP_&80q_^H?z~15xdR)Ksi30wL)6?Dqp*rro`-Yb87f6b`EejuNgC)*#9qAdYtR&@WiujjNt(S5NsM zZ{=V`$>5tIzZ_Q8&wOc`cd7xcVg!ViUpVQX*;AI3P?#hmn{}`YbCqp%75Sm3E5Dm= zg!d*vKSUl7dC?L~jTI~9{M=oP;M5-y*X2KCw`D+e2v$1e;3qTT&ru=WH?`C%GJNTx zx8cSGU=`Z&>ehab$-(U3+K6&uuP?RzkV#HM4HQkho;Droq^_+Mab{B-lx|~3skok| z-qNxUKM{eF;)=(96E~D4RMiGw^@yzG^F>6`wW^6+A*_B$in3l#A*Z_(*LgHCWuU{T z`)UNJm@nn?lmXQHl7KV@ zwE7k((gPVx%>DF-n#Dok94^(vp1d%Rsy|{UubX29ga)P z@#KAbkV?BuN%|c@CL(_;{qscthr7EYI4t#7_g9X|B9oIhN9Jwn{PX2gVF7}Z!b`2u z;RiE}ToDFQEC{UG{q=;xKJQEH)4S(jf#Y9f8Qe#uK_%7Hu~s^BNF$pVUT_xyU3|M@Uc zCy#})nEYMPNSyNdsB)pg+)3YTB;mZMfQjP=_Uzu4J*|V#Kdw~v_inV4J-3`@Vrju8 z4LtwvYf%+&Um_w7gN)(8Iz61$IfUn3g|v4;c5Y!$PvwJ?Ve@Ja1TxP5^yO$F68C5i z`u|Q00-Ef_FqJAOQqmNw7Gkw+;b8CjVNvUIL$EPp+;C_?=u)oLZt|931q?3wf%!-? z>xLMI9}C3`n}d$=5b8DD^H;BK692@w%F@dxM?jCuO+5Q zEHCOY2Tl|nX;nt7uzn0iJ*fDH=SjcR-85bN(^g>K?`~ape*I;WZgZ~dXkq91slofA z!+v(t^UI~Y;s1R-jP-ANn;bqY{VH&6 z%;|u($RkQ2`OK+bhhEN%K6i6rx3M)}4UQ`BnTv7po!dBs!;$ir>Qfh4<|60TjvF7I zgMm$c)2IJ-oH#|$pgIn+2oi{&FMd&1$!PV8@u8EVQi9{JUb-5;JP@U%v=Cpwwb8xX>baw zQ<7!jX1)mNsJ`hdH6Yr-n_e-=&`0k66300|n0zA%i9m(KcDoWOtM_eyH?(6`Zj6BLf? z>-wBBu9mMb80Q&Iu?Po1jk@%_i3ZUhy-)IaxmD#CUq$Sv9+r^FygPGe|EN^rW4hj) zjeE&~ld@l_QWgOh?DTU>2fmF%Ke{A8yTqR|jy$IjEJ6kenEwa_gh&sZQKq!jJVj@| zuC=sL)j`;^ovwY(Y`T@nhx_@${O74RJa~#x$DH~PxC&)m{gcjbRiZ{i$2pEMbc-8h zixtFkXXoVR<@)*M=M)x~mI)o?x=>YJQ_CeGiWI$82f$!D&UbZRz1GwFKLDnG zV30jDJkWsw+L*0?f~<<{B;Vc9=KnD=cTG+4czO9$nU$5Ni+;c(qdT*6ZAS7)Z2GaR zvX7rWf5v-W+^>}|R^~9?GDaKhkwh*jyB-bzbHg1J`|+p(8a!!6Aum(b#sXM6*?o4s zas(-`*bbwIsGBKQR(;}o=CdGP{GVyV@F2SW!9}Auz8j5{`ul;{g12%?eQhp{My^uc z5~GlV6{JRq>#h;aBT`pj-)MZ`RM7lg`N`|NU6DX)y@3Vv`+c=~2MSfy<8veb`f)$!X_dW&;s1dcmOSWw&8>Z2AM zMMtb!Qud8JwoC-48B|u2i?#Ha|`zK-7f%OBm#VneNL?y9zkb$7tg&L}3-K z4T5<}#_n1{^cVjVZ;E>VT3|^hUv93IFf}&JMXHNJXkqx+>~!emo@2*Me0Q0`MGI>u z-d18`Y5rDI6y!!#0C>Wje7^<Q`i{EKg zWW+37Pqms9k{9069(K@=L5J{o=LzNWxF#kE#V2!0&zI7o!`m6J(lXNF3_`*LtO7C6 zCZ9-=ONSh=A(X+)q~?)m-E1^)R48)$WY&mY`AZ*#Ris*VNAmoO@_Ia((SSFQ=RoBQ zOCOl>s!8biTi<_w7}#$w8||SBr)adjrpQ@}K+yuDphy$7>I{BY4%&pBc38)9teS@< z9_i}4@t8u%C9ci70xc@KCq?t_UOow>s9brSIHD7!J*x8C;Ve^F)h?pz{B6FdFR2?M zgl_0n4IL3Q^p2rP$I$z2=v9pfDAv%6i1ec99f}}e!H$)k|FfU9 z_sqPSc{gj#n~)kF+G?YKX!T$$(I zfk8gNLQg>$So0xq(G19Oqf}nkmLaK)pa^5z4cvm`{Xgj0Y@)x#k5bDK zPqImxeG`fQ-1v}E!bd?7rpeFh@pAc#v(bX*nHTQG^2?-rEVzvoHp9#VTK^P@iAk~{ zzUikKJ2J0Qns5>XI^oiTZTXw&jZy&)Sl=m)yx3vx{X{F)b_n2%06z_OyHArBulB8Z?g0Mx%#y3leYV>Mx6eL0T?ZA zQ-3;|V*2986H*AOd0Kh|SxaR2-<|CshhnZ-%ux1pG^FgAT=*BrRJui3$)lw9BgyX_ zHRo_H9sJ`s)VdO}OS9qTsfYV=Wg<4BvyNR4-v&USc}r_wT}*#Esrb1lx&@Ng=~ww% zAzvm{drtt7x-UcBcAN(uMJV2C{391;GrMfWa4nH=fA=?H-fh9UOtn^4rA?DDJifJ5 z6Ig|cky2g_jp?~9{xLH=&*9;sqe~Wmlny?Autqr%Bld`P!Rm9?+6Tb^$*5lC&>!u@ zgJOK=Nu`_dBJ(_sTRzpXnH;E6=9wQwkZxG$hl^)|rw?y5gMPx={T_~`8s+OSYJST~ z?knfdpNM+&{;8y&1@6q0d0gv&)Rex(&wnq3Xx0pJUMpX!W|k;@ch6tF_;>s$(HC{P za`42Bi(mbZIsLwYy;}L?Z>(8~;_Bepfoar8P z`X{q1`1D4QLx9ok^4SLgh8{0%2sJ;4PhQVf{{nG$y%WEDZR(T4PW$f36E*+vkEfs1 zNDj5Q(9IV5qqlv1%9+wOa=LP@_twqOrwfnnR&U<;7T9||OndX=3!ZvLla|u^qbRR? zYukOX#zoekm|rh+p0dNC3bf;XwGOw)nbv9fnDe3f0%E>CNl}tL@Y6pK@6jnH z;H43JU<3QTbhmFywvG{HYxrl^*6m);QQIy)h`BfW+2FqNdjYu=3RJ9t?>A-rZMV>; zWNj8j+50N;#;I~|`9o6c$Z~%1t%qB)$>LUd^%(&Xw`M#ZC*IHb^kDn>=xb~E1E$@p zcOsFBZ_VFsZ2aN;^7{})v?%?(g*fG=#`!uQc=@~JJ|_qa=K82HBg^4%Z>%fa-9(~{A|GQ;|9;teN%birm0Xt0g-iXD zZX%SO>bmI7ITP@Skb=?oTun8QrkENy$4bPd8ID9uV3X}e60yN9iu^qI-X!(7bi=Q4 z+Hof5*3$#ale2aL_Lq~*D!sht1jXLyC3I)RS&)0yU8R~b94ozs12efQGh1Sg42ov; zo;OOL4G!_k;1F9fW_P&q81Csbl4d$`-00 z>w>dm;uP~qv5orSqs_-P%5%l*rMp&g`IdeA%}5#L{v(Bem1XB>F0v(*tLZn6g1lYXWOiv*9SNkVR zq4{)2?H#Mb(u#>)J{L;4NhvEk#Tv!`lb!lM_7isgpGNWid-oqaeDs(xFgWyop;+e^7MK2ac4~cNbL;i? z&YRu6{kN=1{D4KVe);;1b?y4|*Y7`nj{peU|D42;d`jNq^!lMJbQKGf;Te=Nj6u7s zxob2KtoRTCV*a<#fQfuR!2E<@Oqj@P;FYY3x5qO11w49g7t2~#D5rOS`9TOct!A0{ zsEc*B@whhETS}m*Sizygo%4*WHvel(*%ge6fc7V%Q|o(L^=}9$^jSmJQQyxm{l$DX z?XFkt&qN8T>i6c@KYGh1w75hwf1P4}qBP*#<8{0g@0#YvrE7jZ8fsDT;Wm>Q;-)Eb ztNx4qQI9Q5YlRuZMGXXL!@N5oYhgBqLb<9nLUuIlhnU5u1#M4WJqg~sm|qwt^=kZ_ zqTW9SuNH1CHZF&F#!8%7aK3#Z$VF7zeeh7tt653w%b{cQ!;68)Zx7oK%Vtgermmf8 z_~HE(L6hBB9n0}I>ea?*g5NJP(^+|^Yn0-q4BjZXvEy90lPZ!Ulh+uzkgXQ3&6AUm zDLmnQHelSDJa!o5k)hBs4njz8wQUwk6Im%UgI96Vmv4Yz4Uyim76M1bY8GYASU!BV zl%w9>8$a=QTl>}J%TiXb+fEyPx}Vvgnh z%*{x>k>PhWUic>gl53%)Ty_4&`TdqF+Z~&;W#U@Bvq#q2%0pLP zs@8lZNC{>1?F~!Znof|b^xoKODa6}f@s)Dvo>ZVEp%nJQ)>(q|25Lv`(cv1A4fM0SZ%Tx_FTWtGke#L=;KSO0*g7BSyv9<-Ke-_wz0gZR`dm zxX3etOMzd%y*S$*CH!gJpIb`#d2RR9x7yB}5fF^0WQKvfc#K!w|M-PkRFOH?I|^@x znf2iv8@;*$8?h~izLBRt7fWB4A70->n#DePvvaCgX-QwLfC*jXGP_Y{cPcC5+@qMm-JaLLBJ@>{-nBaK*0=@w0%>qF}LR7Zyr?fu_JfT&BX1+#s zjgHd}!X*TXWO$!hT5876IZY+C=#Pnv^=%CVwoUnCf7~iEEp{lG_!6i(Vf8FwR3ny? zT>H{Ykw4d&H#Mxp53E;Zamf+m@r|E{i+7SZxA*~q;A~aa1J5K6IH;Uza-kc=i(Ub< zA@rH4Nbk+r@ZyCi`L-Ifqc;9r-JoyyoQWf!M2Kr+~L5Vjt1l0;$SqJoQyqpt%~!H`d+JGG0St1tE{ zbQBtl7kJuTzxzN5=&sI`Zo>f_7)r4D3y9n>vsFP@c|1hBVQ8{FEvRS3Xn(@B<&ks^ zZ@~oZfBlR?@UI&t>nfzp?2|o8mRDomTmCS-`9ZKR|f_b;< z)yl+IIe2)LZIt1@eOJf7b3`Rfxmnkt*`m>YRdH)bV%2 z>6_&(NLRXk=G%LUp?Om)iw~ua>k|Lg65`JDFQ(zYv}`14aD!(M!ot8~QS*}G{{m$^ zY~{C?7|3reJI~!C6@QgGczX$mIXR9MC!?X$9y4QSRyt^6)qFH!hSUnjnbU>0Yjj#Qrb4LkqrWR=60SJI6AN)6ZlESrL2ZP$8|!GX+bwWxLwGo$Fj1Q$pDFmAwwg#eu-WXov)o z_U7YAU#}Og>&Vh&;K0Q)sS0_jeIU^r5M-n}*(^MF@yKJg-$=Z*5*O+S@m3muehC{< zpuJRNd#{o#t2ZLvV%{tU7O_m_hEpid)%D!o+a>49?RtY*$4kQ<0t12F)B;A^*WX5r!J_vU%)SRU;+lWCG!@O0O2i4 z$)j`KH#VR7JF`#Ck(IEY%)il9HO_t39g6oUJ%64MI%2`aQ?4S7vy`CPf0yyoC*Z8* zQtEvDC^BFK8q%8u>?5FjSP+g9CZ(T-(T$T_3N$Axb`dW7$YV480wU84CJ=^s7O}xn zDFg5$0?ab>5FMzjq1F1`d9e&P!lyAX78yK$azR$shzir9rykP>2xKS(h;!BV1XEJR z&C|Y)B)$NvMCx8TxE-XCZ7}SVP8g5;cQ_gW2h@Tn$fz^xPJwF#>5&YW5d$Jvdc{%K z=0^}|ToG9QLXX@l-ZN5hQ zWJXx{5>yu`zXbh^sBRMaAVDG!OiGts0*F)y_8`@_IUOK@lo>#Vd!hgqVoXUiUCwS~ zktA4%5(5~r%;y{fvx*Zdf-ci7V?u6cn0yZ9xto@`;LiIs=iI10jo%LT`Uq%^bJ53u zJ)@zzGcYg-xHy`1UNg^89>mLpXaf+6u%teQWe?A_M~>9Dq4c5fci47K3Vzh+st+475}y zmu0K;456RZyoIbv{4IjDQ!DW{BIKO2atRlf1yN=`y6MF=vJm3{2%c5RI0FvXEwLhI z{}-a-ot_D9MM~~iW}13rCw`5cT7l^00P0vO`|eR`Ls>N2K}CtS=JT(YXTK$B?1*~H zTXqqYC7lZwV<~Si3L7iaeoMvbQ$ceXx&|}Vd&~dW!aInE zU=3>ONI=I#=26Gt-3|pTi07aqU4+Vu$!{LH?xYU^Q(7P*nFwm)15tN5Oj*^}6ONk+ z`Mvd)ThKyqK#RUdNQEGuWW13M$QLcAN=u1a^;Z?WrbPx^g04{z5iGamnU#g44m?GO z*882Dh-ysOb%8LiCMUECkV~0+r5ZGNxV3eTMf&V^R#+23!JICiqvV^~+=xn4RP;V$ z?yGtNY8M0MJ65ZA{+3pCHbw}<$<}2u0ue;#18lWPV{VFGAPBXkM;<^>Za9y1j>`gm zGq-*>6-8_+xRpwkmUX=t>zex>)L_L~S_(3v!THEQ^6RTBN-Dhj4M<8$h-XLE1i(u@ zf=OpuhTVewooHmlm;BWS@aUUoWoh@=GJP-HOlOO5vN`R@gDc>pIKvb)%ew4oean{Z zTg-^rT=0H05RS@Rne=xuyDNZ!ChWQudU&RE+`It=*f5|NQJOlrHh8kJN*S=N>Q!fU z2igF(EZF6|+wbbrg^|QU7!J3R(7Jjhu$|Kv-~*A&_?#N}T6U`}giWPYgb9+XPBERho>|ikQlYKw9S!!m-JIWV z5wq#lt#H>Gaxl^Gktuh~X6so(r?XOxtkd|E-25?NNQEI_X>;Djt4YA?n(SKk#XU%o zi1l^_O!C*&HBZnJ!=cK~)XX?2^k;uwe~ovbt4yrN#!3Rqfr;ZuAan^?)xz-1-gC-; z1|?sP2-v#9Fu=%k;z)MQP+Lcb(VE0g9L)X2V=de$phEN6@4YNq>sK>UP#LXBe*DTj z0}8R1H5gEQ8?C9E z-x%QCw7c_w#GZ+tDSaRYaYIkZ2DqLA1M@#)u8m1dpEy?Be*`o1ysJg-$5C{zop^F@ z^2u{Sciw}}W;mcpcYEUr8c&*-J~s5}{E&Ia=s!uB*&YzC=Rp)R)rE~1U8gL@!qXAJ ziM#tMfq7K`=WWgcVzAHxU1(X}&|Z?aE!`XUb^Ij?0MUnaZJ(9D?VYw6?c0NBQF}RX znFd{VZIouv5t9!~Cu7DZhZr-yqX<8*yKo}xR+XF#)5R1sU`}j;Ogs@&1(eB9K?)di zohXF`m4wb!@4H;thwzeN2?0~PMh`uN;{)v=@4ZTDn`;=}-5IcfU&G@P zKM2ZM&wy3)N_}6p8k1p3B=>%PM=be2`bM(s(G#y^K#&RYp2>KllzG9Z4NQfdTupWj zn4iy>ZyQ`(_z_XeH>S!e#?Xi~?3mTd@+djkkfPGhZ>Ed(Fr)20*ej?IQ;31WZ;El_jn zgR;(40RSBPRCO`8saf{glq|%Ex%8_VOhAJK??ZWJ7Bw-8>utaUGILXGUU>%5AV!vK z2KeZ(ll@LC>?A%LwvBY;;(EETCc)z!*rnWBV#W~`epUnx@SX8BMMHwE6CbyAtIq`A zcv!p38LmSE+M{2b81MM{CyZ67{DL|)IJ(yVzzAaad&7uX&cZyrIUI!*KnP~of4~zG zC>aA`MY^S^Otgm-Cg2Q3X1LYO&h6fOWm7s|p`36X^_=o_&-dQur>gP{Ff87C?_rb? z&67jGQIolXiO#WWdp7Y0JXUurd2iH@U-Kl_=-1^g&9zp?l_u3)w@w7)lqcFyLB^%B_A7ElNBL)F&& z0}9u-c>NA)YE^*vzoiq$C&7=Ll7Z3v1OSrLfs2NnR=Adk%H$w|bk6r{P@uYW@K?*N zq7+zJ%B}+S=xJ*ysG(`54;|Tt-`jpS*vYj4?s$;w4Z<;Drgq@qzoqn7u?QLv_I_hy zYo<64Nd4Wv@T8RoXw`0TN}{=W+j-j;?2N_%$)sD4;ym&6M-Rt=S+4Pd6zH;XCLaJJ zwm=oADi^tI2{P}ynUns*yQELA%U+D_6;d-_jG4263+MMZW4+h*AP724_3V-#e`V3r zXI4KdlkT}W-CZ*=ZE&OfbG)T;^iTN2$xQT_{*=kbpr3Dr)S(6xIU*LMgWWwe{)7tq zG$*+S8f*4Vo4wCIi#fZz(bX+g2o-mI;v@B8+`JQy+Y-dMg5H0go6ET6efRXyo-MI6 zzWwNNvMkilUWTv8#q~JI=S26H_AoqS4qdnM`0kBAYTd-R1z9*0Y5mU8>xJ*BWQ&hi zVr|%rI0^Fwx^U)TRUQys*Z)|5dv`3h2LbL%PG6Su1oeXrCDwl0d+C!vzaFM4(K|(+ z%qE4@m~n0UcY&ct4rmN`$o?v7ckWv6^hCk?Y4(la6Pd2+-S27?xu5hX%`Adw9>rgR z`f=|!dMN?h89djq_JN7f_3 z2wP}tTieN#P+RpTUS5_!BhXh5CP?WQ1Kvqq2wo*HtpUlQrP1Dc@<^T4VJOgpglGxO zY4B={j=gHIlDU#)^{)V)hagypuBighAJLcp*T(ka`wF18RzaIQ3_W&7iNifud9=%8 zmG05Gy$NFv-()jU+<@ZX=Z^5XVv4+J*${By$;5$N4`n#SSFDKaU#^;o4>aqfZLrCx z>Br?8_?nIb@PE-;{&SjTfXvFYk15)(bx@k%D0i~lpESz-x{r&vzKN4YVyq(Kp_jxT z-yv^qWm0tzHxPli$UK!0T zXNZgmi^bW}nw3XxISZdOQo7|E3YKbOj=;c2SCw@OFCLGkm^eAxav@PVxC@!WY+DM0#*d<)a7S#l!5V z7n2gXD@tJXEn?=`tT&5{fWPDxW?I={^ssaNFr5R0oiLkM`GKO;YA-uWLm@^11L^90 zXV!(IAz~lXY?@EQO_f*Y ztytu6_lbJ~_%68@xN5udnMgdq9Z@oK;^lhhF4-SPm!X|RWXl{qJ+$&QtlkPAM;ZTB zm~_XttiFt8Dz=B5dPkN+o9w3!3qti5_Sm^yzkwi0gXGnKWG%^CctP_9ox$p}y+2GK z@nqmxZL~!m3Q$-;r(3(b^#1EpA(+LlGq##G43aw3y24#httHyTP?Y9r7E>~73!fkM zrL@l4$%i;Dg~bmGDllh4ETj5+_XfUV+eH8|oD~%^^X-%6^;SnkJfNvS9}#wAu)-C% zRDYH3%{Mw!zKWB|?S{U6&e?7()x=v=rk6y>vA{?UkjC}fW{BaLC>X((k$K$fkhXZy#^u!{$MKj)V)l1A z5E-C|{J)Cm+*_9!e}COpmn>+rdAa9_kU^O-pvky_&(DjM)?UBoel~CR0SPsFb4E&> z)zt?nr91!^9WkNSIFZj={w6RGg>?deR|vdP(DGD4YTmLI-=Haonrh+R{>7tM+3-ln z660iTIA)InGLGAAJE;VZC{{AemYOe0Y8Rt_1u{+vP$n+FYBX14ZR1e-4FMbv>L5c} z+`&2@B=~G!AZlIkl%8}*y#86l3p1LY1IAwI!e%^%1j@+w)vs`zoX;q!Y=0}ylAW)@ z?xOFm)7tdj`i@3NeUqA<-Dj4f1G7RY}Rr26tx5@KrH~g>V|VKVL|=1{SBi%)FlJ zC$lN>W;B(@jA+fjVgp%eBTx=~q2Uj_K2h&H*gm;m9`<%PM?03QDe8v)n$k3fE2asO zUvGJ&xiWgyahUgOUD|1f)tT_KK!zBzAj$<8$bB#|J*T~?*XVyHcU<5Bb~M5Y-4q~> z2UEOx{VT>*Bt12QjeNLn7nX}idV%k;s%~-mA37~uw7*E96`@5d26(|y41~bM)Yvo@ z=1J}HN*+=I;lhJx8Zp~0qMMC23FCfYZ7*y@_aj zSV~hzS|ig1vn%Z_+cd7O+MIjvR_C9_5xb^-u=;Tl*vk^c7UI+yI!&RxV&(uLlTeT? z1CYU(ELtu*$|liZ1^_5K&|&_OXaQ=fssQ>!&f;1zBJB&!>;tgJg%tkkVp#6 zVlZ7)NQ}mbTQDAAHA`jmk+o#JLuI9mqa|x?m_73ei5#cN1#@zqTb%$4_RwHEO`W`= zK>j>UqU=IjcXijNt9z zC>&nk`SWX7%LJ`kxxR(y)NWfEH;Bkwp8MqBG5k%q)XyR8(l3*Hp4UMx!eBJBw>J1K z^)AxboFj<_JbwUDoeFz@avSvWjdc!tv5DW=xtO%xfLNcuq>k7>iF#Y_bUWhjZX%Z* z|5>lgLh!k#0vTjaRFf+dw_6ww(57k}f)r1-T@MSd@w&(5A9YLwj68Z}F1Fo=^}nfWRf0^%*PTE}9LP*ZFnFU#=4m;s7#)FrUa}9Pj0?919Tq ziUW)(sqr^!U#DPnZ{Dmq`^tPvltXtwR71oURJ-W4e>SLZuTTfEqyriQHsL?tYj>Umu_Rq9-|5%pK z-bW-pRGDy3@~|Gid($Q~yx_vG%`A)wI|q;+F#uYng5^<8ArG_SbJa1m9-rU6~m&oOWUm<@f~*Gu`*rxnRpU+K_< z;q?#CUxTC_IzldZJy`G~)PSiHeR1-qe{c#8z$#-w0&NFS&R`5ej!NNJIBPSx4ccc$ z>o2=K`xzGGrG7`pQ0wAex@!JCU3Vg*JW7+Z@u&?Ws#$gZrLtZ?!o{=?$*~uWA^+06 z!O48~j(+Qny>XWM|J>%+e+a3iM&H-1g}NXwH?s4*mGUNiuDzW0^BNW4%)oqUtSHOt zXU4trd)R)?EqQ-8Bpe?HdTP$PbCCDHW|lM>5Xt%ufv7NLH+Bg9RNu_Wp=EpaK+qle zIC^Ok3KBQ992sE-N+6(2E8@DheVZ$izkg5W)eDDqdkqQ(jcpr=kYOwpmKdA5QbtEII@AG6iH8;TdV#B3!(wVRgpTT*(-i)*dqZvW zJ1-aR0(Gb);{fQivv#s9pE%=6>^Mx5L0K9)HW+(FE!BzdAoc@2?h-QVqpQzXxib;N zAs?8L%h5JrA8k_FqR;Aur|M@%$jN^G&gD*p>DB&1=>s_wPPJTX?+~}n9XXl(R;G{~)HN_+jXE}Xb)|Cr~@zBA&Sg(8IQWSHD zCKWWcb7jDiyGzF=!tw|e7YD{DnDqAujc2D$$0ZyJ6+n3Kjyf*OZD;rZaPD})yPa&o z8Lr7*7%vHIFcY8G2ErU%WN(aeEC%xdP!%B4fC$`=33r8@ms$n`R*7CSdPfX)O%`d4 zGgslUc4tMVM69)TOmz+l=fS{}vdB*smxNe`hy^A=Uv;-AD-^{l32qGrt+A`E{cPN5hH8gw(@QrA~K5fX@i22qoA&&pR`#37pSv=Li{Df@WKx|5&XornEr|FxgzuOUe0ZrbLrr1?e> z$s&hWo|V;nm?@7IHkw6vjQM(m`fC2^HFB6a{-m8y$Ar8Pu0v5F1OVbks#~e5^JCP> zMICc#cM&S%&72ceZPMnTLQw?&u^(jF^Mr7zYf+JS*%?Hk4||J@M0=Ga5Y;5AY5vLQ z+UI(wsbEB36*js)U;-KF;CMPJxR$vH*wa0xi$O+IuzsNOwP+b5GQhGa#H){h4;5TO z#D+C}(2IV}g$Td~tDh+&mzKeiQ^Z*&6RR1+_Uo(3T8u~7mD<=XBUB};cM~+dZu*2? z7W2LO83vRLlwIU+zGIaiw2C>_BE&^;PSgWS>(@`tH`lp{E3`)Fjs~$U_zDga#MoN( zk>K0+TK2PX3LTg_MuhrS>wCYGuRTbMOyS3~kk5W_>D^%eAWXT2ODP4yqKBtVc<|Ir zhd#DvOh_`V!VzDdTp{ADWYSTtTfcYwg+P5%I+1Nr&!z&_U$3Ye2-0MNq#OM5cR>U) za7naIlmwj5?L;xN8^<&cW(W=@od2Zr@tSCz)RGKx3&^#;JhlNH5s4AY z6O{0}KF$z>V3Ve?d~E0(75I(y1fOpdi^uIk_Dq$rPoTMM4`@B~Z4m`H@WjsZcacSP z%3)uWz~2+PrBfpYNdP#n^E3&(;nV`%1S!n=SNd5Q`kWlQ#g}{{_Ude((JK3(hlgLD zhgM!tia*!M`}Ug4ea3Xl9u4JcrToo=q}W8TL)nquneTF^HPQT7`FB85kbqUzFE*WT zF3Fgd=|FtFi=ee(Kjp_wVyhpbg>x{kfs= zYwuX}GGv141RB!&dx6`ql?F}MJ@y@xD6P!T#3I*}OiZf5Oold$FKJL#yZ-KsjYgpt zYElLSULMeE1D#MfX744h5TrUi%=wY;=-&An-Yd5xa((`@PGoBmToS7PNdW7-<&10v z_g7xGrIXH(IYJeKLeqI23;_`pT*8c%{iV>?)h!f@1IbVKCPd3 zrhcgtWI~I`%jiGZ4_gvDW%-e!ix;LucrKNKjd03uIf{FGO#WSb@(Kv?HoOl7LUfp* zF%F@lnen)J6L`1o=&`4C$0Mj5=04w{M3b{v_QF}dDTn-DQ@O7-5lt;SEGdR~zu~!s zd=$E}QPTI5l#sa{tD=#$MKUTM>7T;#W6=FDB~Y00Jr+Siow+pYe%u2y)i4~t2~7Kn z$7!Tx5-IE+qAfnwRK)?&UM?P|bA*|Zk{XEf>h)h!A_}okNm6zPRc18CSO$eOIzrHLC8KR$d8=}eM5vq$$f9%zL7I|?Hd!;yR-+;|8 z2!_g~NtwU=*?|YGqd$Aw<7KG-iNMXS0&}{`6^4nb*rurC+SFyBtH%1BT%Vbg zHx{yEaR8&+6;a#_f5U6_%v zGl~%>*VG0sE^GJ^(0Pyisb}96pC+#Ep|KZV)=5!e+MEyRAyGnsAOsp(*akL_vX4~d z{FFMR>#`{Nu<7N{s{hAVU$ObBT2aK}JHFfO{OH^F>_A2&P)*%M6|%iNW{rK~;uMd! z@(igGbN$X<@%tdKANk2c5fAx=yWIAznelZ7xL~bZ^-SjcGa}pAJ+o3pyB{8W2Np}SPAhuI=Oa2Y^!OJPf-pN3cZ%f z$BVp5fioe6TmNoikDp#*tcF^1Y49nd|MBZ~8Ij~MCT$1V>+$~CNPN{O!hf58xO9rX zx%qDMwz8-^-V=XNur}f68&^5|15$1I=HB#a;xYQ^pw6AmH<{RFBMpb7Ir+mP363Jp z)CL2&*SnKb-OGzx2jkn823#_jMWOl(kLf+sQlI>sY8F_Pl-;r?T*oT6S$MR6-(K}2 zsLnt*p@5gGb^@IEd+tXO-Oa`!y_nvImYK0HqWv}8zxBQhXsO?nQ_Doc+V-sL-VNy; z#i|5x(mEZ~lIY5${l6hV{MdW(Q>w&YwYn?WgT(8mOaV?Tbi-N8XYK?2qc-;Gsyoj? zKzciRrra#(AZiG*7+PpfI<<1v3yRyJ&%ImqoN*2$J=pP|s()WX5yUC=U-%i1#qQmL zPq)AQsH_V5V?F6&{J0+T)*Qp>Cne2h$fyO!2MW7Z@vX1sc+2OFd@z9q?lAQ`CyT+IM%%7_Z{PG^U8-~qP#)6n{4x_<<{&4ZjH<0CG{^pl}Iqig{k7DyF zPK@JE_EZ44_EWXIDESs9uH1B-Xo>*9;0?KnNU#28=z|Y-Uw@fuL6Jxn5hIX^7ZA`Q zNX3Y|5ipXXsQ*N4QKA?x{r^RPH|Q(EMMVt|1Wf>FWnH^A0U!cGvg$O(7>^tpM&fbu zobpyV8adfR>1i25;2b61%l}*f8l_IC+Z$w(v@&?u<7cFIR3xGK|&T9}anyg2ousjF9*YjIv8eB=9AkTd168_H9 z=wY+mvC)B7{=4jEP}s<3?3JTf96q2ZUzRY%u4Uw8!pq5@It!?C_}WQ!b4r}2mOG3ftxTrZ`;y_AshE`&d6&+Xj%#`|2 zR?*hy^Q^JnR-RnS-adquYNZKNLG4PaxZL&M=d*!;k8hZOd=KE_Y}v)Eh3eRnQd!%S zgKfId=q?m>#5G>*pY6Z9`!)x0c+koUh0L0At35j8#*tk#GC-$wv>co_I4PXSQrGHA zINU!K+}_Nh!Vzz7T=+Nfqx}S-M=mZm2V@+jNWlupYFhHZ&Csb(0_zVDU4dNh1LxSi3^8sXC!}I*$l2kp!jiQ zZGU|zW`IL-tN@q3V|DNiutj4T*&Kj_nK!u(H;AUo4vG%J*B-o@(LBhHayPOiS2iDE zESV;ySC`Y$Sz9L33ZeY>#t;wQx!@U38-Z#L@B>s3S4b9&vf{t|s^E%rEw!(uJ3qC0 zEyAhbsT#pZ$C=mki}W%oM=)*pO^))7vx$OT1z#TUK~p2SctY3XwyQtWaDv8N2R~%Z zoFC<(Fv7%mD3-N+MMzgl<*971+&H@QTL0GlmKsAaFNMIsBbi7IlJ&V3T>#R<8j6%G zc}UpQ7OP7q0>ln*a4`c4$igp2f|YiZjKg;p(g4FA2q4A; zP(g^)KSfW)M1%*9nw;@7NQxq?^jH^ksErLXfKJKdf&Q5Vgqrq`(j-Bt_q&ADJ-k6s zQ%7!O2uXXjjP)u`IjdXOeUPIGkPzoVDSO^ZQ#k-3yob#VlJxuN;XcrKC_9u0lziAy z%#oF%NhCa55L`IGz>G#gi7{*CEQ3zSV^dW_dC$vc;DGVvo7mi8pn9s= z@YC`Wy-Zc=r>f&@#5eNyuOq95gIh>3JqmDfN$sqoc(8ysb|N>0k-H+pdtZj4ei2VP z_iv9gmo4U$7>&e^Af4k8Z>!-+k%IboXl3AOTQd0S@y(!9s{FdW zpanSqZ6Yx)ui7WffX0}Dd#Q@044f%eW-=Sv9rTQ)0yQi=P_WRchM<^PHN1&_mdj=7 zD#CVf4{RzZ4Le2*VL;v78&d+uV9nwrA0s>4#1o<-^<2Gr=CT3BzWocxt^hFnE``IU zB;8hXs?w_Kc_*boI(vl^8pWC8b_Q?_DPHOfJu@Kqh0Pe**4tV?H2^iE%n1w%%E+~y zE!JLGHm>B8NEPTp`O{9zzWYee{v&$?^aF00yPM!szyzNf0B*D2r%EQKnk8*nJ`-#y z-xCQte?9Vfe%}Vtj}*3zVZ8*S@XF-p?0c?u+}?QqIbV#N2D7D{U``9k)Mg(K;>cU; z{9Tf*&m4mC%emcqwWL|vT-5W(FZ-@}SXJF($QQLk7dqS4&|*)Eo0o8FW<`b3wgnz=7vgY))8x9zt@aJ7=@#d+R^{hT?SRD z=uF6JWUB}U5NM95zrJ@kZw3`cFAj?hG1s}r#$k?FUhaDae(wKFLPa=He!pS%Pga-n zEeg`my+lA57wr>L+{rO;^na* zgYF%$x;CYa@Mo~B&w0vcrMwE&kO9}na7)ifa=%y;@o*=>qPTKw7n?zXt+8Q;^Hh~L zg#UzIpKW`mzFd$2^;=Y1nmRG+^vp@->8AZ3HP!_j%l6qFrJ$uTTwny*R>e(U{cNBM zm=Q)nRWeRb=iKQLzGDBa_foS74KM6yH*$lrvPhqnELv3XkN+siTfvb7zo_{5mq4$W z_xL*U6BDXHdiruIaHY_Y^>dn@Q73m}Lhbq)-R!JdIW%)XAc>-O^>cMMA8{V^a}a=s z>PZh|Mj-$3+&wze6a~g06J}l}+uxr^TvdFi*TzXIy_{4Dy=axydCo4?eV;D#UHS0s z#Xsj1oWN7Gq2Uro227j=z@#h_pVu*=2!(p2LGYbx{Bodx4|hj?Rc1V~;+u|*2;7p9 z&k}t%oT+gb^dVQ-Zpz_~-;nVl`LeC8tLn^D0bt!msIoDQfP|~aXQ;eHaG+3XL z!|}9Eyg-AoIf9rBy)~M!6r`8KatJ%+{#J*x)ow5Zk#fwd{j2|4-eJvG(T+cMr(T+V4y~B6ydfma z`EB`Yk^K0P^TO;i{oCBsOca9we&Uu8wgcE#By@hi1hI_fCq~nkDM9l8siMB(mh`^d zekUqbI6HNJ!5B^i%mG*j0!Bt83%C;(vZ9uROnoZIWoSQ9erNM<$!knPUA^{)k+gD> zC`U;OtG!!p2H{492~sasGlZ44NGk4bHH5U^(P;~J*h9e-Mdm5?O2iE}3LF_7C>Kp$ zhe;u0Vd&T)`4IK3)ajihBJ~Op0|!Z_g(D!dZs!Si()ax?l?#Dqd(-rTQ4L$MnF8sW zZJaAh8s0$E>sI}}p>&1|m{pX1j0U%x6X%;rNo2*xNtbO8+3YQ2oi#vyGYCb-5rP$= z;Z!h-CuMT6UIkJVf(}zVme03@j2?uwW^2PS5daaM6B4qGnmnx_%*LJF?9$xkV7F9srdR zDbYNS`fvrD6>}~%&X5-+a+?feQ9BR6vE^2t@M07#Si-*+115Kl3N#I5GT=hv?qK zhlr%I*JmyDE0R`A4VaL+gV=F}bi;{~qWS2=Lnx~$$5gQ}WTyNW8gWuED*1d-7n7}% zQCikt6{=(7XB9@OD#=uoX!R{e34sN%2sbonPaYHiAgBf`mFBV>rLtD>qz2sLPJd0A zzBb}O?YNeq4=TmNg-rcyRoyNwIfEe2z%QG}dXV8%tAel@b?HUk2UXXD&OL3Y>{7eMNe%s9TY}~xsgDLXvDl#K?vzcwzR)S^Z*h!;b`CJ@NVgUu=id; zP5t5j=Shc9482GRJrpq@U8G7CFd)52?;yP+A%JuU(wm0fmEP5WbVR9A6h(Sd5gUkK z`RDha*_qwTz1WML-Me#{Ihpf0bKcMUdA&T>I7o-zpepLN1jSN< z!eb&e!UCHTI8wIK5wxBh7Fb06Ilde`Swuz^LLQK)y%4b$;q+oTaB@E5YCca3INx2U zbOnjqrqs$WbwyCuv{v%{sf?zg#U2-R;8leuRWY2U=P*)KAq06`p)Fd{U}87hS>#c# z5jlpujWuChuarwIQ{${Dhho)7bA~)CUUZO100>DEyLLv=5W{hOpdeHbc37n(!rp)7 zj=Cp!)milRNR<<^>WGmN-e{jl6(%SaV+z3L;EHmJ&In!hof_eegBZMo7gE>HjH;~G zUHE^JQA`B|$6Gfv1y{L=Oc|X#H2LL6PDWFEm-9;<E9vI( z)W@zNQ2Qdr*L`){qP&Sc71k4e-`TBvW*VRWW<&t?RuhuP`hu_(4YNr57V9TFsh9Tq zL>b$kFid#pcHT8pDnJ$ist!+I6c`b_va>^M`Vn_j)u30*h}?%JSIwwDxu`pGw#NTS zhc`4Jr=Eb#nfNp+yU$E`qMlmKJ*7Av3dpUphf$Jd?W*Tb^&_AaVx*6(#PGt4HV;a> zG%av*q9Gp9{#mw#wKwXff9I7Er@o1j%kSEM|LNqNYVG^&r&Ur`{VhYISB2wN-K{8d z*>4@VMv^`OEQ@cC(QD^vtWO-QpPO%WIPbplvt3e4^z$GMD3Sx-0(*eSxGX{)9i?|! z2t;YDR<|_h=$B4vRXG|buZ(wc*_dyMJ(Pm=R2`c1vDrPRuIaYoM3dkRMfvG$5m|?n zeac>4ShtR~DLI%?RkNerTeR4MS|BaIyq|d6ztjF*R&3gU#brB*otlA&`&o+cCdFLS zv&K^^#fP_gD`(mq_2RK5;H0I3Gm4eoje7XJA9B!rcgkdvri=fwo#M=eQ*2*fjWImS z^4Z&WcSRS=qwAk_H3}9)`Em|HnEeB%Q=LLD=d?}w zL4@%y{97E(Z{;;q4X)Kc8y)ZODd|^V0C+1J5!Zvgd;a5BhmzXnI&^yTVHV zSFNFLPrw-{Q6j=xrs65IOD(QJnu)>C`Ht@OXO0{dxdOx8_3$Ab_T?a2C+K89F8DPrG$$n~do-${ElPEm~PAt&@jCv2K{!b=8}(+wvZ`l2TWPp7hl zjxG2~hZih|ZEPyP_tVr{SB17renfML5D^ZQ=^}#?vq$Nmz^R`1<4kypPy+Hyc_MGQ z)BV-JRabip>n>D@5D!qPB%3Ra0%^X=rcAzO)AIX)(vphF<@a>-s1O0NYCQW0#@}f4 z72%26>up_f;9`P|dc8K$iiMHh^vtf@oSUzQcoCcb zx`Tv#bDaVA>o(Pf+&Q25G9yN`=#%E(lV}fSfI=Jk%7=`~`1-X;ZyPVLhTUs%oQL)^ zfSCvYl?#RwNotBOHf@S_wd&_n8hvr#6UFi`+M?#~X1|F)T&=w$Xk8T@T_uP@(PQKL zqD<@86%DMOGvSuDqm5h&mUPyZ$PJIbT+3qcyUgUT#H(vDxLvlBTCm+{=p~#h} znX$V%*afOD@uL1~5gCZTEK46k$9JNXlyyIB(3#OR<>dvv+2gK04hJ25Zl7+9`f4Yt zUVn#P(dB0bsVL*)+RXGtN52*l;5p7b8IS8`58m&HrLv#389~ryu5KbLa?!3{PS2*h zMq>_{Z0VXDt74c?<=pg$1#iGrqAk8Zk8HQ1;{5i*%*Mew9rnXYUxE&1CNt(Z(mFOO{ES0>|8^*SYYR##8n?S- z2vT2H$=`Jlt0AtN+v!M-ouWRlb#$a?PPJ3U8hAtK0mQi_J7^Uyj@Z90vCscuAfLW> ze!wi*8d>^bKer0XapIruMWf$-aQ<%dq{U1Wx6tx>ogUpf(|zfid&*Cdr!Tg5_iM+0 z-T%sJH{L3?EG8&;Q}R>or*VFV+trR>8C01GeUT8>pd6(6<^0IacK>Ca%J1^qgFD+F zaok{aa)qSJG5-F!_`(VKfac%9KF`+S7slI*PHH;QXJb42B5U(>yYXc)RuxL3GlPg18-KVE4jhC7yWrqNHOM1@{WtWVuWm=p`+YAyEzxpbjSNelEVHpU{ETF(`Nn9}P9&J>D_27Y7kh-`fUnRSTA)l7={=Hf;xGwln@d)dq%5hJi{ zdmgrZ?5{~*np(-U0isQCaJK(O;tKR6xfEF+vdL zs$f1+7Wca-p_HzSSeW$jFX4L&=A_qEv)&(1{Z!o}W?44!eTr(hCgrSptM0uGkuKsQO*EFqc0%KN+65l*gbZj((?Q?YZapgN};0Cp+FJhWx4+cijXYsOoO5R-%x}c zPPh(3j4jP$Vl>ji3V{%=tE(wtV9>F`O7mk#oiy~{r`X>Z15f)iSX{OeOm%nf35)h2o)?1s*7gj9|cc{ zVlDs>NKu*Lx=$4>OdjPukmia9Gzk8ie|Pn60x;Gm2ICrmLo75gCdcL5Dd@!1H~0Ty z+$5}$ounNPa;x}~NK{t1nf5Ul07UFR6tkQBaj8FaZ!6@bTrS3pLnqpn!LgQfvGf$8 z*kG3ydlLN*Jm3HSb+?*S8pu&ihN2~i#g^9 zKS|f&02Gq_wZyH)iFff$(MRIL5}OUgjtG-H#zb&SXFMe5U8E2@C0t34XQW< z;cwRrNIVqxlAxBozgPl&K;9Sdy`Oliw9aW`obxI6C?&9BJu^C??Y;@5u+=A~KD}q@fv9y=2yU7x#O=Onx#wwR=)g9wm}w8}6X4{YTDQ zpH(;`ZjLnugN_H=_((m_6_$A~5iIRO@!?35amZlCj=t|uXABA-X-8Lkxp=+4yTr~u#zw6qtjadx5G2B)7C55)&TOg~yj zkZIp%S=vD34iQMuvDB@61rrBoF}rUY!wNViMlLp}?ZE4u-$&=7_rY(lE zzC8>>#tL=`iN}&SlMCMGl&j`RBfCe58_d{k65Q!`_!X{YPtM z_%KC|z`Lf;a_CA4v@w=Iye`x5$M3Ajx+)$v<>Z$8yjFjMwa5$YBlRdjNoqC6pwlO{9?$|jv;8d-Q9I3`1E_8xC!Iv|s7N8a|KB(r(|5b!=Ak7Cj@zWY)GV#f^~+{zo*x z_$?5vG^76L_BZe=Ju+4zAe)y13o~tUx^kwOpe1=V&bO`nN}?kkR_#wCvgvwbW9Qjj za1ggglie#}b|H>*q1@0{>Qq&VhPw$4*$ajCe8&Fcn?44?K-D9Kdv$SW7aAoU99~Mc zNHVN%Uc*dxQ$Yr!9mTbM&x#aRNb4Wx@FPfslL&Y586FU`&z65V9>;_zXW{u9P~v__ zEy?z~AycERg0-{mp$sQ|#7Kk1uOAnK3~I!9G*!H+C~OdIKdflY%ACZO?ZqrF^&sJ) zU-`#5@})^VR?@L!)WMHB<5iA@u7{cyVT>6FVN@IhzYd;DXR_i$LZEY~Cf11q!u=qC zn9Bk`sONWx5Tq?y6-rEYwX^>COS9X$t8U~yiXMl3&=7})-i8%8#|8p49j4_9A)`!z zq{RkqNAa9iHLHuT`Fn|KOfFWXv6 zQ5da%%S%^2m`r67%n4FD-$w+8_lP-jdf~^&yGZw+p4Ou5?|=ORJy}hjW2G&O=PfmL zp7SC2 zkndM3@D;tYKB(jW1pNW(pytluAQ{BJt_gr!o|kj@f@MjZ+=f^X>ODi2Vx1I^9UY+x zlof6POnjAdya2D(Ywf~b*kYCvsEQE0Rq6&{phZ%Z2O+{taPlLIk))@r@a`pfTulpV7`NtLn` znWZKuSCF$b;UMIlbv2zWowYUyT^P*Px*h-KG#(f!inbvzVtoo^(mD1A<&IkRdH94pXZhRB)(Fh!>24;p}HWBTWLf zPO4^f#w#;Q3OfRpq*&k|zNwVGwlp>RJt|s|FVUbc=c47?(tCsOw(K7S6~2Bi4kARi z^9VC~amI=Ge)MT5<%9X@90b1nIuy+1OmMIrk{3peV$%cSM&n9bv_K#OSvFE*UJs664VD9#=*Y1`YSnu&Ia9`2ImNUQYcD2{JtU_@pquM+o zzY>UoL>@C)E0+*18l}74ZoO1sB|9C=(s8sP7~C1) zLjLj_7u=U66H@LmyI4A0|6G+%We?{A2)`j|kG1GZC zlMkLyahf$SOC$UCrh=P7NsqdtPrMBkhRuA813Ikd3aY%cn%M@{c+q3zqo-0+CHG#@iSIpS%%+X58OqI`n zZs8$=g?G4LGEvMc`s9Df=_=##g9{H@p0n^!j$9uAEWw^1T`!fma{*x(%slDI_etUS z+Rb<70KV**e72XPx{}AYE)cj7P^yL0UY1ya8dTsQtib`Q#Wzwk? zb1N0R>y&G1?CwpqS$NP4+`R?HL?#8y-5$j`7YZj->4W98F3j`8-#;15p$Nu zQ!{FF+ea%y78R(5tAZ^b-EQCxm{;OzvwOy&8}bQa)xx-I$v&0Mb!G)MTjyrwCmpVr zj!hKG^p%?7pl|@9_x-YrKQszg8xjc@9ltE?>dpB5a^q4)=qMkmi0)cM9n-_Q=6Hyx zgPK;uo#qyITR=0x5vqL*om9Mjv<{b=EEdtekfKa-WZfDFYVf8$ke35E2Ezs?!hW`^ zAaPGLoK>?6!&3Vi2gLZEi{%LOgGNNzZpqQLir^j-t!Et2Z&o;XX8_3qFkHXr@^`l; zIHdh8f}^FG6{uh-*X5_wM#B8xmWR14Ji&<-26UDPqdnIm^qcm4>%FWSznPq`J`Md2 zGQ;aY#GBKY-FV$~_{kvKmKKV?JrYR=M|1S9DjlV^?kbjZ=!>d>{PQfRQ-4G6)?R9L z2SuXC{Fm{U5~*7hn{dOfm8k(#!w3zdtN>rFyC*HP0Ue5g9NK z=;f8buz0KJID+avb-&pJ24zU%?=M$?qdzv@>3s*6tx%v0VRri|0~XUT9OYEc;(!cu zr4R3E3~QA#Yoyb0S6pH}wxFK@VmIg$Z?O+0#qxS5S8RYn8{p0;RaO$b_uWXDY=oeG z2A8#?`+)kl{?XA}#y0E7aP=F^>mnDu^u`h*k4nf*DOW5={r&*L?p1>qE?^u-D?dxC z_$_#DcJvu^LPDV9xhp?$au`Ga8=*;g9TWOHxhH*NQg!G?>&e|i5FA=G>CgTO%TDut z{IbSHdD|=LgFbcCF^}Aa*^xS^q_3V%4fM7`if+Go=qR=bH8^_I6I^xse7Sn|$19I> zITe{{ChDoY0GNI?a8(=C_i9RH9XKn08pr@;0t$tGJu@+bhd8_nLfb6Cb0=+?UbSRL zdUA{fGw(Xr{TL8A_%Zqf1*`~i(XYRuD0XB!1nzG2=3Bo0Y3X4_qQp>$Dq2K<8r+76 z3JXcKqb|BhOjMDGE(*W-e334+WtPR|jh_TWvQ6%s7Fm$4U3>sYN!R=9nuq0C5Pn0{ zN%N6E{8Wp`0H)6Z`?lIahYj^GD=c+lCg+DDbp;{++kiQb&q60*A&<|7Gj0kjbumY2 zfP6GSfeoKV2~ruj-j(3CjQ{N?XYOt09#V^~G8Z$S*XmQ9fS+*8PQAaZ(hBoC_lT$% z4Q}QL{VX3W1iJX{)c<}7xPpx{WN*qtStl)e@YC8*-RpAm{2r?_ z;YvDEtxiXfrQA;23^c`kQp}lc`8R!{#Ck67(^Qg&a}C*)&%tC__g!sxpu#UVXLh#_ zoD~fNS;6}g|An*p-f1n!e(x%CX&?a-O&0C`#CZFN!-zDEJ1lclo5{-a`?EkB>fJrA z?$DJHx_SLW0{Ic2b#XmcGF(gyfd_M}C+L9W*=Rnp2!3QgklP*u+X7gt?T=CbsXKYFaFqGRiP%ZqMdM}qLvhWiJ4hfX z4+0!=3mYk|=eZ2|+g$6U9&|+HvL89?9*jQvlF~v=;V?0icbAumA#EvMG^=wTy4sA4 z6|i$hGk_wgs_4-a=K}&e{C>mbDp4D`;dp!6V3JVQTiyeebR46Clzn~s}xk9+#WBd)OA)poq z{$}v#>GN-^e1uK;f6bN!aXN~_snmI9m!;2*vp0jMnEn!=^n?;Rki zW@%7@i`MZIrsspyoAo=74SyW7|G1+M8u$wma6s@-%s~Gx0$OmY7hnw#M1!9)oNrNC zl9x?xkKosMp}vD;K#g_zH;FoA2mko#5PO6`OCbQrhzZT3%`$dAVYRRAoL_%M5f)Hb zaF8mvVphJ))J`nHGp*877zF9KQ2BPpuZbA{l<4gj7uGik5iz0jnPY(6K^DH*KKQcD z*bW|^k6((KOHU-c0Oc{sY*jtx4xRay*fwQk1j-ubLy;jMbd>@`%Pl#6@9DLu$6&wm z>m0@4yg;bd=o?-~tlpgmX6=7ndj9^sL?y0+5Vo?gk&edDPz>NS7<20XO|i{aMKdxm zSpv4@6_r($0IDvQVgUcY2xZ#qNTllLRVZc=-eD2?XH~U;GQTt{69U0l%0R)`GBCzl zF|i^=`7yS@)_C=n%_<`TWSjN%3x*#ginMXIU}CcR`}dCpR^mr?Hosa=7!|i7dAP-q zAX4)7+u*mx4U8!&(DVIxYvov0OX#<@@J!8kM_wbDb%!rpP%c!@_;;el1H&lRK%}V} zF^h_4)1NG;W3tdD&XB1)&Ocaoci7!f2dJ9qzg< zd3|`r(L6qd(yo%YcuPLnzPk;6{3Ka(IPN7AtL!7gbMDmfLK(G%2d7`WjEk<*@EX~& zj^+#AW#SjFMtiDli?HZxp%D<%jJX$t-&O zf-@;yfPlI_{hHTX@JqHQY6yBjDR@TAz`8#WXd~fq-2Nc+QlJ1@=VM|WXeLR{!EnYj z7A>4G#MI+SjHiad@$2`tFw5&{STAT{qILk*TK~kcPC#$VlE`dn)xoqu%*2uN;OgNc zm#-_#V3tKCM={&EZ3-NdQ9))soB6Kau%lUr7`3fJ8uk@p3g$jb95uq4!!g%%RJ2ws zv`%|6LG+?|OSphtgB%YNuM-$#=O-#wWdo6H1ki%$wqp+4FWKFy+<)qodO?bdYq#dkKHcd^t%elFiw;67za;sYW2$B(ljaRjWKkOp&#%MSQRbZIbbG5; zYd=;vfGh{?r5gGWFDjo<#kdTn6mLzgHw-XzVZ=vdD1}|yYTx%yZFmfb8O4wi8pnz9 z3ljPz%hLc$!``bwqCwNRk2H8Dg~New-In8|wmEOVa^2RGap0x5>b2`}Q$%fv@01qT z6)vc0j$8BM`_R(19(^HMbzYF|*kfhUA92C5v`-pHc+Gw%b>`DakT`0pN!@k7QTJ$iGJJU0lZE z@Ce-TmFN(0^Nh{MaCySRSzKl`Xv-{(;vFNeK;UP4Nz~@!LmK{@$PYl0LauuMnS+14 z!qIq!iAJ32Y0U$^j!&W#GAqw9UQG9997B}WFikPPxnerMj#4;S z-SNfap)`)8O8&d*Ium7x^u+Wk)a_YT&nqVn+m1h8NMI(6ifh@ThO02{poM}b zFx*!T00hnf$`!t)HsXQvcO%mmbJ4*nL=7=<;0l344~Tw|vAfrg8U>*^!^`Ul%6R67 zA0+B!`Oqr8!Kg}lhZGs9lNkma8N@n*F{;&HY@n|M(X*@H$j~q;H)mqeGQ`+%&XflF zNkkbXiWxTk0SPITS4NP?I_E35dySYIOs3yr+q^_Dkv~h=jh!!eLVHS;F`dM1j|PM9 z4YQa07b?+oo=rW4#YduVsl8!>GR}n8gnyk`F%x7eeZ|}9at_t)RhNeq(6gy+ER8C# zJvKV(>LeAG$`LfhRK>RNMv^I;i?nJib&!B8`k5o8cc@o)U^%WY*Lt0Ql8Os&(|5$0 z`5Y#~-|Mh2HzZPD|BQ=TbUk5UhozDC^J2g^Fn)jT8?^VtCsh4i0Y1~A_k-DlJ|D;0 zmWh1jZV3K%6w8OdAUwEorHpged*;utRLI)&JqYcTUadO5b1Lx-b!o~6qPYUza>EhM zZfjBlu6;&Fbibbmd;mY*Vdfgwd?4jD+SHctVl9E3kba@=^t7wi!dA^+L$<^$UuAbl zd-^S+R4wjOs5B%3E07f>VagOmGto2sRKFwD*91C`&)1!= z+_r3Vfx8jEmCVk6uzc9MF+}w`njmxWQ{i45djzP-b&Q^UthVQC)KBp_-M4b1GC~jh z{`+gC7G(D3g8PXZ-L&gTHg?Eat68v!b3TpHS}6C|6;gJ2`o4BwM+qxdcg%ub>k>qT zS^G#5oob=MB)_;~SgVLO_qxl**_F-h({aog_DIDpOv9%U?B=inQWapTRX z^^a#RFb9+rm2cgLh3Unblg^|vTaH^SZ#TID&D{+TFYYUL)H8Feu>!`!-_jbh&>MxM({_rVJ` zxpc2o1R^cc>~mW+e?2i$T?f)@Z8ll?5Kj&1PU3As9!Xy6o5~|Wue5jW?lkvKOJ&{` zFVpCduTYqC^j&Nii$2)Z{yJA6c~p@gd|>dUbD`GgSKImfcRXu-t7eX#4j+*9GlY7B zw0}YE1^?~t!S+{w-ye~Ey!m-+OYAx6%6!q#`-5aQMV(tly`d*%`>MaRqL^s!lID)f z8Q#ciC1(D}M*PJtH zoyxzd*nf1AcE{+iB!u*EK=s+zTjfukWzGZpZ$Dq%RHk=)Z(UM$lo(z8^vh&6b}+JH z`&aMnjqNn2vDLtU%VW3yofTi)XtKEYQ~B{(3(IJ`+nPGS!Ob3N>eOM{fS*42d2x^B#D^}LSs)&}{<}9V%rg#r{A)+|7P3&LR1M z=>y!wrXHy(%4+Wct#*RpUV>MAbZDVpcn_o5vLWMq(*7ufQya7)kObFF{u1o=x;8mv zJo&pU7|_ONFT_49bmQ_!uue!RT6PBOvbiQ()*h#@hq>kCBu7AzH6B6KHL-EyQk65Q zaykh=nA40luXOYTe+!NotxBRtAhUbY1Z%Dj3|no_^AGog{Ash{0MZ3y)2DQu)T4X2WeF>V=(+KX8*sOf2N@Ra$y=uuiNjyvzP1C&`JvstprT_YPDykfWP zuGS|QjCjARxg%qhQ!Zi=RBf9c;;%}b3uR&2mJ7J7oof~r{`YO}h5Hp+wtz&PVDkt+ zj>Noq5x7I&depwEYf=-=2S+-cF~?i%W-4WD8#ei-H85t zp4rWxnp|fElS^zN4}G~8xxAouzR87kyIQPzAjy!TY|)~e6eRZu$SWZ+S&&$q67W7G zy*wqM(khmF5m{bT%u$Fi-zxU2yMVS?m2^dv^i14PB$f=Ulsu;xyE#gS6ibJ#N=G9~ z$BRlQdrM!fl)gSIouMSQie(E{Wp5+?2T`!vTlRjX?88~vI>)08#YbCKk9Hy+?G-&b z=zVmw^61OiqhpT8CyI}MSUvs~@%XgpF$Ic1No@a}Jq9>QU?mdNngov|Q5BPreI(jd z68#?%inE+ishrumoHeqXy||pSul)ZJp^SC4d1SR^akX_{we6}@wf&!J2hJKNr5YFO z8n?(AkK!7yz8as^8oxg^{+zXeO0~h(wV{!<;l;I)eYK(NRR3oe%}qe&|98>6>;C_| ziw66D%SCgKvNikv1{IB_K8jzXMZkFDWm=t>Mluv2YbWzcrJ9D+lKAAbtZ)R-x7Rzk)H{P{YGEz6w18G z6goWka#u5s?NCTUlE1wC+F3=}--TA`?%YPJ{C(-B_59LujzwzrU=KIm?7pg0nWOHB z^pDSZSZ(T^20q(fVtihb?|MDd@>17Y=E2d;;k0f}yW$Y9FkI|MS1!BA`q{dtn>6nk zk7iWYo<)H#%>I&d_ZNelc!PTXp65jKyQwg`d;U0eJef7{F@C$?q%^`t(u4FZWjLX< zG3D_E3n9q_8u}hU+G#G$p24=Pl}-!wvmP%-D9(P^f{zLfUlX# zAWeo)xME;XGX`6}}M@)j;RYKQ5 z(zhJl3T!g{tMwUN-#TSvu!np~p?lj^8G464Vm{A0l%ob>r0`7#!pr<;kUCkoVXq=x zuGphoUk1I$8-XJUA^xp|u$2ZJ>}{a~BUh1+LLw4e^rHjM+#z&-1L`VUM#T;*1Q+xP zmAtyhnqpg1#R>uU?VYj*rE`SZdd7h4>ISE_KXK@GelPLLUhRY7LZ{+--vW=oiRP|l zxc**a*V{iHRrHpt;?NSg4K95Z*?Ls?$WWk9$)xm@Sb6--#y!MaHyh7l%b{D_M5;?E zTfFs=)R^+jf1k)y&%7c9E(9zV8z<9?cCHT<{Czm{v?;MI@=9TT!vtu++?6#oTiI0) zMA9FK9BR%ri7pnbkPK$Io8jvv)?lmh_h`IlC$hPy;K{4NyrJg=iI-aP=quE`Rqq-{ zlU;PIbg$pDb-8&)h?bd4+gVlX%C}#c&l+{fuZEbHydzU-{Q4_e*FDB}O*!IQI{y$%T zz~AZcpz;tADIWHBK_hm{Kc)KqE05h$QvZ72{nlpX_TEUEW*iq1L*UL!~PnZ;hCuP8HrkaSdwSlE9+KDTV- zcfTe?{E~#Ir$OZU6Zp)X?q8rw(z`6B{!=8oIT(CA?a>{TF8-G8VNjVsQH1lg(PXGe zzfyTvJt`W&my{K0_Cy#lp!DZk7M`{$9l)z2JPy)BXOXI6;PG4>K9=OYF)SuLu5W$v zFeCwg-f%i9Gn9Uzayp~SeM5Rk=Z09!&7mqWiwS*dbv%R)9S7m8ACLCfBD!|02^gke zm=9nMcHU$Uzhj#txwiTtMngP1+#mj#ybyhLA$R6Kwv?O%2 zN)^XV^qGtos$ArHbzg_Tzvn>&)p<d3>}WcoDvQtBgfP8!`eyy7*JtJYOmr(#NTsBESgr_lKgMdpFo8Ml6)@ zDf7X0BI$oWBGV(j@9r!%L^+2Lm{s&;oj!~gy(sW1 z?EWIt_9{KUOSt6h#im$5(VL^Ypj${M?@bn{G;tIAGHl4tuwGmdr#!QER9NV`O-S2; zCN~#NKj>Sn$iD@~B%IEgwXiT_BCiF>B4-P_0&-)bw*|H%G#D5C<=Mn^@2myHE=adC zn)_a3#8NcIuId5Qy~NDT5$xY^=dbFV)aA-YK6D+bF}fPaB5<6M z+rgvm&;PotBKsNRo-mN{?57Su`7?zH&$Vytg=8obJHFrW(R+)l@(Amhw_SZ&Sgy;W z5Rb8?w&$iEE|onyUYyo;_e*b)b1gEzvEO@of|vE$oPH=%zgnIpsdORLIW551JV=Wo zhl6z00E3wx5AT>m$nw(KD;zo+h2@|L_y5w;@hX4NasM|=)GSD6+N`5>mgtTXw(_r`|?MoX{d)m4MFR}XzQ ziW|K@c@M)ZTB4_SqZ$2ys}8o{b%+!h;1G#mXNwzS@t!t=E=fyDyp8qilDS9}TmGbciK`|WbgXhB_&PIVYBA*y%GAcfiG zK3i~nuIe==!lkfy5fao0=lb-iaa!LV75N9oI z1tM4n3#g5UQ^YffWbas(s32jZrVG?U}J+qmT0_5Fk6TC+1FecS0 zlJfrFb>u!*Ivxl4ItS@gQ>A!xi34g3wqyu~Oj$*sqWsoiFe)v544_DCB0Ul)$8l=n&HV73qE0#TrVHpDP2f9O{DnzhQ(XDd@ zH(&Yi3qtzghVtFvy8_8Xb79|gnFn36TK9ixEGsBC-bw#goh|GSrPy&)P$28xJVrD~ z1`EpU)Do2fNz_05z85`<$iZVQql5r`jQLNQ;GR3drsI~u)#jynf{Iz; zA;$syzXLGDqMbcZ-hL6x5=1o~{@t=zcNqf4L#fb!EWU{FR>!P8F*jegBQ94ceVz3H|G3RErk_3H z;cmFUr#3|B0&L{~2_Fydej6RRho|R^Gf>OX@CT+j-1vVeZ$(_=J&rsUD&;B0Ia&#R z_)*Z;ZMa}=LLOF&si`9RS6lB>}yxGI;(G&YKIh6H#v z)L{H!4C^&uTzJ0YK}SdUu6rt{hOI;P z`*6$|M?KXsxQ7)oEL2;OSkKzhz!-SP83o!u1z$s#U7G;L4@d^b0aj||$$7qm2<@@) zivo%(Fy$90c30p%?D6hMN~d$|LYM5Iypx!9=}>BZe|QuA6kID??KKHwMS)_rGtc#M zmJUc7D3HTM)5|K$kCPaxv&0OqV8)w|Kko5L5$vu~Y409{=XqVAdppdkk**=>pKd6B5 z+BoT>+J+_pEYcb)YAH^HVMr|?k0eHPL!D@hOi93>NZ9q{c5W$or78>+HSjseKPBJa zl32%9!>YGe{@c@u^SGSoYMVAuSv(DX~m+L0(7OoP+zAQbF8QOd6oUB>#1OY zFwGFMq8y)DmmC%eEsSdJG_-WO(goh?QO29W*Q<$QO%oFqr`8QpXb`BS4;c#EUyfdM zufKa8c&F5(F{1VasdU$=TO?IiU61Zw0zr8OA?pBEB)a_z>HgU_aADOK6j}5BI$uan zxQbG7%=OOLDMU$Re-2BpNR``|OwZ%o-o`XYG#Z2kU|+m3I9#otA}|0iVj%;Z%55^D zm2KiVMUgM24?qYaX*#T|t-mJ*{S4f6>!qIYu65YAuCat^_JWUJp&?OaD3LyLQ9q?(q! z=SFmuNMrRGTF@)@JsPDFAM-Lz62sy9_L6x2c1x3oj!ZLeHL;V%HKlrnyeGiaYkIpJZ_fa!^{97X0bf0nA9o`#BqD(p{*qCpHKvrsQ^FZ|*E z2v2ZttP)%JkKZ(4aC;KIU-W&KG+I++Uk)CR$Q{k3yag;;pc%V0{c=#@d`P*~6waW1 zRH#|SpW-~4YfOMh&lJHFAlFKUYWrb93aP9uW)yW5=c_^pu2u>UO<2scivZ+(-~5kI zg$(gInXhGha5ABp`bR-~?P6l~XvF(JzQy-U^I1mmLtvFmfd%&@3vxsCUb+BgtsSF7m*VZi4hEFnz9dF0Ge zEZwqPb*iq}v|343VTE?u4H|tq{^EuH`vsI63SBvxevNpo0oV!4K_S?8;kLy#pM!PK zGYzMfB35JR^2t8RwSr+|P)=RcdS7UI-(k~ZE_d%>-z9U7c?xEg90Rk#zK{0rRHOz? zM}zaP>lf0j&Hm?{__;qk9x}sGyn1CSM+vy%;8YT`vY-fv-mt#xZjG2hoQ+SszOtgm z9%$`r+h>pla9!wf&%Rwz1~NsVGu@Rx`!dr#y@R+RH=^?*d_gs9D$i(?xZt|xku(gB zOzy*7?#tpB9Aq(Vu}yhtUjd40T4}Kb>7x3@o&_MHKGblN2L<1f-$!e$uEtSq{uL$J zalDcFFznhp#gS2*B~o_d$-|!MkHSv?40@aK=BDOUN}rleuVA5J%oBhZy?zu;N*!gQ z1AoZK=EXwM#C-4GfXpx`E2-E+(m>uIXME-L9hyyUowVGdS>2YQ6Iu|6w7TXw*seUQ zB-s+f^Pvi^iTWaYnUg@50ao}2ynQlW`%)yF3nb}%BJeQnPZiVr@zb)S{>$!bpI%0%y{ zcb^Nv>xXM^k2z|m5@g{wVpd^hA3HvTBi461cLL1o!ToNd<$XtCO@P2!YSvig;`z}; z(JTu#hmo{)g*T1c-bo7!D(6{HD$-5AVaDF|J@c8Ka9_2)#TcXh5~F^N`rSi4qB=wL z1!lA6hYl8Azx{&^2JBhlzxdkv+ehT4eBnqx?B5CaR9Y;S`GOw@QOR0dE6VIFEiFGA zsCoV?-QtwT4|rAvBYZj4SQ;tDw@x~lRMo7<)NYY~>?ub6K|dz_wW?js_yak%O}f;C zZaHPTeV+9=`aN|mzx_{Mi?mwahOwt>kN%4uq1E-~1PQAivuA9M@$RelbSi(?y?W0{ z9}9i?XF#+BT&!gvd%^88A9S8z%mq;KitrNXZIhCdfd9qQS-3Uzzj6PZH85bKo6!v; z1qnwKM@h@*hS9B~LzDp`q2fRZ5pb9Ys6$XeMNvV;;@R(cuIu>=cI`T6 zXP@)F-}mbUr0^BJ64Hk8kC_!B)O8bBhG#q%CXQ=F>W&^2*Oy~+WOfSExUa*-P+1%RFuy1R% z+=Qx{@p&a1Efc+MU@<1GP4{O zK~Zo(oe(k9o;?n&;yFt88SHJJ_cAoGH5{@_&nGo3q*+pW(y0#6Q}TY=X*rYiSGt2; zWbUqNH%(>YFJm&EQ=s=TGv)M;)^G&+ag(@3bK?zuyT{rX^4)1Hmn^`F=kzGOor;2T zN&P`utQAO@={3BydYw1fxBGhKenw6%prh{4iFIu)K^agT`1s5T#j;BBeD;l_<`?tz ze$Q6H0qcVzkxkg$;m3Bl)E8Dm5NTDmt590!>%5u#6T~yQiQ@PDdaHiqme(-D!%?&w zoMqa|w@4qZyJrYRK536R^$a3?>;6dRuVcewe<|7f3lfpCCI7s%IHDkM%*TOT)t~f} zwMSFD$yqip_GQh5R5oO2;lip%L1gzI;a83Yg#nhnC_GcpWi?l!IOeE~2gmWbP9l^O zK9vLI<+s{_KyOD(G#`SBSPGo=Z-n~8k2LK~a48D@s0WF|mifX6fslv5u}`^A6&I|? zFm!^(A!*W&$~+A0{8E!Nz(b|Z>VfT^ixCA5RXAZ28V(|@63@suBDbM!AAYW_JrgQE zd+=^8=NAii$EofnT^#zbsirW7g>JF1J88|#i5f7cSQMYwCp$&@3)Rl$nV-*i3~KG- zKJ=Jk7?5MGR}pv5>BhWMi$mJ#SfaHl^5eojh6;*x*|l2{=KC_=AJ$)s#JuB>dpy(G zjB#yM~4Ay$Y8ogH0WLf)rD9ku08>+Ta$DNvmNNBHOOebPfl5z_cY%O;j_Xcye0G~-88mO{3n6RHIa^FJ#_)#L-6JDlh5 z5u;m73c;{Eq(D#jgt?SutLJF$H~vYXa_VUn4LbeH>cGOhHb3+y^YK&OrspO1HN~eU zrE@u6zp~8Z)I_EF(UG{1I57C@JsxAn$T(%W;EO0{0zb zHJ39Fsj_VZ!`pF}^Hz3*LWiVok}UN2%D+~HDC)uQ3SwwdL9&*n=H3VAl9w!D!$%1q z5^W!4(bB*#ff?JUPz|nw+0+<*^rJ2uWOrslB#43R`1mHPmwg!A>A2WyOFDGt=h1&3 zgXxYUG`I)G^4QCxnrsX}zBoGtxK2lLJj_Y|p3Z2jgX60w zq$uYhe3M>((+F~<&`b% zoVIOA5M{$QN1<^Y4?e{s!g_(P>2G=`RElNydfGH@h$t&jxw2emTcoi1>Hn$bmzoQh z({bl5Z`^$VRi@5KCuC=sISka*;a$)*I}m;cb`Gg*!PYoaRMOoVHXKwYYsdfxiU4(ah(Y7h>p!&SjCJ|dQOfxyAN^G1u;{V~Lm zg4pdG=dosF!5rPC6HC*0$r+3C0NAQQms7FlTtLJ>%vUY?03=%g2zK0RLhTZB^LfP3 zD=1_u3+JQ;^if2Hb~Z*;V@kk*C!&`oKsz8vePvN*eV=kD28VMt{(3CfkLNvl!=Lji z9e!ku)hW8Op62;`ZnD3s+art7l39_ttQdeAcD!u0)ct(6wi%@^65{VMn<-jj@2Rx| zp4bx;J^y{LG5BtnQ>to5-4&Nedz!*`?^hHKytzU4eG^r_;ZQRgm zRJK*>SSy%jB0;6sf0GlII_5KH@Z{#XY+ZL#u4QI3fRM4JT>R1VPI`l8tiom>Jm(Bi zi0hrqb-MNgt)a&@X~T_bC>-x&=N)isfP3)=WpkZ3m14ZTrbUy&H3JIi|CVdo$-fd4l{ZP-HB8kL4#Rc4>_K@^DuKm|xy7Gs0WXI`AN zOaeKrJJVYtjbRuHE5Aj3x=S7taISn{*jPr2|E+d*?c@61_lh%JE-7m~Jj#!AC=6$> za_{Ay*DsBZHo3j}@VTphU~ocycs%b6z)|Cx`Gm-@G4W+cxUWK-zGwzH7oH12irx~B z>kfZ!m^n~)lMkoH<667}sR;Cg*yN3){r{bTOA}VPgD8<2r0AA)lXpPg)9hgFU2U!R zg~b7T*2Ts5E!X>sp>JA7J%7vCND`LZ-bJHWO49okpXG2f<`?&S(j=5|(Y@B07bX{8 z%`E@>{?)Xv{#fGo!v~&g3_+v?A3e}G`|qt4bn-ZuOo2r+-|sU^#&%1O4Bb3ln})7I zuBBZd-W6y6%dX+X%_Rz&k}y@0Uu!ucZ~0hki`{N;_T4WggWQ=H9*6D0#I)~dsQm@zA)71YZ~rnTBvq< z=$bZ~sjZBP=YIsnKa1kJ7G_3IDUFPOiM#+c7cY{*J?9hc7BV&cru!l~!OD`&Ym8mW z_+JWOgs1#?mZ(ODFOoncJ<}nSEQ|*On!Uf4f>LDI*cZu_7(dxTzcFi6h6O|)0h<`q zR!1GUnXo`FjKLT_C*~)L4+9#?^RdM(E800@eCoQG+_d<^feQAVo@cXi%=I=?wx^=$ ztnh(r%G6=8=jq4H+E3z3l_i_Aa&f8$URh1TFh#1m9|^J-mzsDURAg#3pul9ND=Css zaq$S6KL!x`Hpx-~zfs!c6%%q7+ zdpZuUoMAMWYlL(bp9&Cuno;7Cs3eN};H~LIm+8oI-x1*|wtymld_)K6Aq*b!DS`Y9 z>FLY@a8Nazz|&G=jzGH;0g`B9Br!9PXG@5+9<%Od_Fp+yx)Rv<_KcWFhBr$~6gjMmt=@v}n#J`~Lu z`9{lV<=#G9=g7t-6}BFz^hE+(nd-Y{gi&`ZBTd2|4~lUE;&P0O=h~Z%mpn|!@Sp3X z*h&EzZ5bgdL>bSIYI9~!8Gff%n{}1oaO@kcWW~e9T2#wEOv@HLY-3^UYh=&2lL+rO zJ!Wl`bIPcGS_086wT#t%Y!loP?ZlN6Z89)EkcaO1+E}RyjZZqD z{_>fAS1+wBOa6WjGXaN{EIBg(a)j8r=N-ZEqc|T9=#JtYH}H3;M@G{Gp0~!;;$XTv z5LGW{$|n>U?t#|lt7)U_eW zR5(P}WN^Yo>xt;j0NiBRV=p@MZ8YrIOy>_9m{An(!1Fv#1$qBc4y)2QWJVW*!F@B$ z(y`Rpwx#W$_1K#Uj2w*^n~sECR~5m1y?kTYUClRB`%D-XFOxz( zdoAExRs4xJuK_rNOGLpAO6V1cmf)lIHu+TPgP`e>JNKHFD6GdCfT`|vG)Es!=savZ z>+y1;?|2*0WTf6Yzi)Q0{&}~u5QgehXKbep)fbTG_F&_|eAjiQeV5DB%@u};jy?$k zhR1+tYp97@-68Orx{4lqBl1NJ+Yst{x+ZOURz7=IbSDt}uHy2aprd8@prb7eNAp*| zG1wT&U6C(&hivEJrmk|?!{og~YQ=?U7|{v}x1>siyMQ%5?JwEv>C=~kw$27+mqjgK ze&CLS6Jh1L!>>FK)X+PSd+$ZNqv0kSmOt&xdS@;PsZqLZp|n#YSE>9bX3RWYZM|Ds zn(A-z321gDoUnlMzHcJMyc^|KRO^2a?N=+l=BJ^4k1svy1`p*ThI|A;^%<*oWglJ} z$cG!XJEyt2$o4JcN3UENO2(<&y255@l2k`%R-Jd6_?gHH5b!~r-f}t8P)@;~0O_vh ziH-$U?vZ|r-;C)S*q=SSeT>VW1v~plOo9rI_;zHLA!W&IWHD^WmD8T4E%p42M6kXM zCC8~g>o=8OL;p&V7!1Ku;A9qYqHSTP`TpJLF$qVWXmdUn2I4RX_e?2q`*yncM8ttO_&@z`kQ#I zCjix9WZHFaDDkGY22R1uWJusndJGm!vNSuc9P3yERR{#Pk^WA zsrHWnspp8M^&!HX{3zCdisR7VWrQXVsi`}UY+Nju1brDdZrwKsIf}ZJd7noy{w)Uj z=c`4tEA&!GYamtFUTjjgbh3&IP$9$qc7-fT5T#f7q2zhbN3IG3D*Blm4OH3a*n^>M znCIgs(iw%B>~USh7on#|fx(7_==(sxx}axB09PRd3CuNhl&j#%|42MC`KD~2+~-P! z)lS|U!2{2!^J6%U3bKM%I?eoyR$QXTS_dQ{Z zps$9T!DX@+>_8l|(`ZLUC*>*cB1(Tg;LE?z2v|DaE(oY26i6_?f}7(-1>b zBWVYYm7T1)9i~b;`m(Ih80GQ&!;-_n#ZnWTI%L4>)R=3L%#&>Gfz<<&%tt|&XcN*K z<+%^#&XlaFo6lwLqC8d}%8($CEBD%Hqjy{^m0VTqDy&u*%PB?Dyek0$ECX#ZE0Dz% zi=3U{_djb%dJ}vVY&HFYSgHHq>t&F)_P{3^7ue5zeeMgtoe zAZu%`Z=3mIqfT}_fZDnGY!1!kM1+_9$OTDLP+HOOaqVIssS$|Rr8$_d9^v*E?kS4A zVvASeI8=!Cs<68}UH#D$5*V*t3jR~B?kO=My;NuMSmIPdz_k~uH~kAb|_ifF!X!>DcRQe&$T8z}<*)0HnLasPuovzMWJVV5CVH;zQPPnd1~9g8@4*k00-a z=N4JH8ft_3>lsqID1TzaqJ<2{{HsMOtwGv6?e&CT1Zbvz6}QWy_#>~%a}49 z395uyWNdgvN@BN{EM9OVZ-0Dw1yeh(o3_E&!X0k?!zJnDBy?v*o!n|m;He~`qrvxz zGD3SesMih_NlmoEe=7$4V;B98QWpTBpBd;l#!=I22)vfjCF9o1DyRv0zM zCoA*u^Xv)iYm6nsh*yLZCB{z-?`<}|ly*iT5wO8^Jus72i)TMpAYIiV zT>}gC6UlJ5b0da0M*-t+VmqrB7Y+a%!Ih0~#X4SXT{lagmE`2wd-Y?dZ*B#|5Elt zj7w9ra9AVEr7;hc=3j|s54x%Ix>P^AMQc7JV7%*e(DdfSd|uYszn$koSshYqSXfN{gFQV&l!P$7+U|MnAS&AH&9187VF#?1)f)3|8;XT!*5rg%$M)N1X8r56)W}{3I(l3@}l0n zrh@4m*%+iEdAwmH#@g6TCgX;fW7pFpK0<@xS|$=EVTcR3KJfI)=U3UXWf$^Wc#qzk zNh;MDj0G|RAx9(k^l=CGuLl=^Y-|L~KyX{y{-hml)Dxcsn(-T}z0$3CaX=HB9f3DwuvISlkL!z}5 zdg_oEP$HrH#&V+e=|Uv`se1&pZoCdZe&3y#hPfkO3Ozrv^pGO%+_Tw^5SD17P>iFX zpmgaT>>bvRxxXPd{HEQnahX5`c~!j03@ppmjaQX(DUB^1(WAkTj-DGc6%CpYuXgSz zZFAUUkkJ~~?c}9nT1AU`g}?<-A|Rmk=CwurSyx0I+#K6Ie@YSeWDmRMbi8u*iDPq<1k5aswK+YWbHfukxVMP zXcM!oRsqCQtzpQ=OUrQN&82yibRq5ArS~sayU3rbp0<<(HbAZg9#|Gk2wwi3sI2(N zMg-&d*zH;P;EIp#H<*#K#EExCftik?s1(v=Wt6Z9)_Ev05m+x4{uVHfP5%9&4s6!1 zZH0Ds)DOQ#zFi&mC+4#W2?fm-?YH=SJ9qJ$j4IV|$$;igZ^_Qhv{k&B~C z-x!(}LW++=TXgq^ZyJ}B|61^W$A*@PTs%~VH6%#7oILTZyY+A^3*h3MN#~U(L7@ID zwk>#E#T|D|{T2%#@lA}0eXALJ!7JvXc4k|B`P8q~nNFfH)MyI^`b0 z2=JN_X8~ad9^uwQ3%khXqDfS7bCM~i>RoAR-FJ^*LysK<8~q&Dd5wj=mNb`_Zy=(7 zDOgMywi_$PJmN=qUKSi(3-2|y02bcpqm)^wS9bYeGVS8MAZv1an(JANLNBU^pcW=y z#&PoJAl3vc39#nBw&vpU^r)u*>bUTS5aZBL7Kg}V8m~Lq^yZ(IB>9g{LGhg(@tNk1 z@)Pi16XO>Jn0-MQvW@iKlIRX>9Cjo#AE(RE<&BWx;>!ghqCDXqwk$5Qa%v23u@^yOpAVP%gqb8pn3OwTca#tI(< zLTSgkk}59%*(_7C-*k8o%8qbgX&l|}GU}EEMEUUq>`(ItiDgcHj(y4{03FVO>W%q% z-yC+Gz_7KNz^3uZ@>;Rd%>2h;zStR^65_aIwhgqZPkdLtc5%pChw49!LLIJMh|k1j z{3j8NRHKx9wj-exb_hJ@*{R4}kx}Pn4F`d+G?9q5Y+6*gLfS8r6=9$y;+x&Fxqn!grf|@F;vhi0`duJ>OAb zZkiVazTeNcFTXzMarcaFMg{=j2kM?Mc;9Aw1d$^U^m`T@#Vd&KN9B;-@bP6nvhk7E z$o5}fWM)V-@6X?%H@PwAq-Ml@?qaFp&fEgPReM zSQkyY#6>q8cpnr}c;vufDPC+&XrOjJH|ithOEIIgB>8=i(qEs&uT9r{GZLU#;(_7ZPOs?^ereX69F07 zO8XoTT#WU-q37ubmKDBtd{A*8CDhYZE&;)7EzK`1Ju!P0@WD?hJ%6I1^dhKPYzVDi z@EiVySRkD=^q@X(Yx%@`al7w)QsLRpbL=h>GJgmg_L6g$(rPd5@Wq#=;97zycqrYq&f+qI}FhN%42oEE(dy2!!4 z&g-{Mq2Gej_p^uYdue`^^-fw;I+P&tbm2RmxE6k{APJL>`%muApHDNz6!T-2o-NXU z2X^eoVHdN1D6#n8GwxeR$d9FI|J;V)CX@VX&0*%BZQ6a!Ca^AP-d;98klqEqSLB@& zTc6%RrqK4>a36mhZSc^entty9(8wB6_F@tn& zP}~X3r;qK0W#57*5`HB{1fXXdq6yalzQ=LP60C#sJ)r2Yn$;HlB9x3I8qIj zMy0>(K&WBt?@wOXW9rby*@ZHX3NV2UX+3KzkHt99y|TW&LpiygmZI9m#etm6loQI4 z7AQyrF&$+K`)F>yGAP}SQ4eSr;0K83MDi|HK-G3GgrDNzw@o`=BMQ(s)_+7JXa^ao z!(c4C*aaLHp1xp?(^5s8_74ICVkln*C}rLSsTrigYl$(Pd66!uD^ztKIvE`Ydf`u| z8X{E!fe7-2OG`-~1At!r<8vS~NGb0|4^63oz& zOz!hBK!1GPrBZXBouJ)EzB1&}k9yv3W@JULmCh5(7jbSfK4pVH4~`vsQ-Jc(g*?|} zi3lg)Woy2wsZeapyOhK`f*^ZPv%J!G?@Hr-Q1(Q)zdS*c*U=r8DfS~JRwM`;l_sGe zKoqUaqLA4%9w!2Xn_QXI%n_6q_jLzanNxc5xsjidsE9l_S?<3tS*2g#hpY&&auuG< zA636?xv_Ms>iFt-JJhAus0|B|6R!|tqiNL3aj14 zDBW@|_zbU(Qpw>i%Y%qwEjECB0|@kxVL z8_z%z=jb*Wb{E+0k#Hik;ZR5iEy8{#{UsmhLpXIl@1jeBGQTgrgX5Coy7R4(3m;=5 zR`LvX?_D^!cgeWAv9hai4uB+E(a!S0a708T9iEdJ?_MhFgi>lJw^YFEFuo`WW((XB zw6G#KTa<5f1c=_%Ry@jmk6xFZ&<~1xZHbfxPu8^@ zR;3=enCU`WD*-Tt)$uJJl+WUv!Kug8wSJgBs9Q=fPguT0{003Asc#GE#(F_|T{>;> z!8lxfP$=)5Ud$G=^W`Sc?t@pNHCTcmh!Iaslxqhf%FJOB>s=ej?!V7lbGsTVYk}KA zU1*eNATxz?2Y$6%(1(B+H|&vt7tFa=59MFJ(h&+@hY{1IliKsM{V2aXvli+@Lr&{=u88H3X^5O<3gqzBir}jkavJbW?Qa8Igs|Yh<@9Xf z7JVXAlFc-y!s98m-+wj4)%8B>s<-Yk7ycdH(SnF;M`ZdYMUQ}qJ6F_lo%sOh24@h@ z>6pz#h&=-?im|g?sVc{vN&0+qS=6h9!(Ch5El z!2(b&I>19J^WDn6w%_^{p101hL9+)?v|{Tg!}ns~1#$kOqy1=PyD!%9jcGZHrxRrWNXxNNsnhI0eN>q-D&5^m4QpQ8Ikxh(K@lJEz7vu3Ep;;q@MGSX zwnh|2S@h=z`1BnV0bMFnNjLFdz^ggrEhZ0^P@u77ZEkbR;kT|1b+qd={4eKKrO;#% z#Ms%cRz>m+h#@kGaMp(m4`w1>z5^fE0bv{yU#)9$Y^2IK6@Db4M(b{8uzb8wb}uoY z_Xj(h8uLfTZfSM{sKQ&1cgD+<4pn!Y6!}h}VsEz&>F0k)Arp~yfBHL669DJ1TymUg zPv`Y~&9KukYW`-wRwgc4kWEPW_owWCf_J@R@3h`fPNCmHeFR(&-#OPGppzw2w%+I? z*CvunVPh^@Q0Z)fqTW_{n)sy5#~2FK1R7)LTse6(=jMP+-NiQ*e)QU}1McB0orYudL zq3RSicPxb0U*E4eYj7oJcOff%WUTNe{1FheZBkvK-ct57&X_5E8eB|fp3|6D#yq=} zY5wU{xWjqxpNNQKD|3QM22SwhHDy$RaxKV(XW{9`C$>+xkD&>xI*?L$3J$`>Sl-i+ z;@I)R0^xd;vzyh>2=anlVvW4!=@`X^x{2p&8c%7G%Y|;KJnV)Y9Z<#qIy81K8mfa~ zn?@kYto7W5sdyH7#dqWAr@5%R@Ox(x-^Gm@-z4G*N3J3cjyJ0&|JHT`&CLUWS51Ge z70W*R{Us>oOsis2zm-p$qEtqK!~=}4n*2`O9kiVe)#3C zqRzyiw8rvO=Hc%&A`p@vzmMIC)7uD**iagQqaxk|7aeqPuTaU%mM8zse^pPr2r+*7 z2KHe4;0peGLO*@wt-8+A4DC6JL->Q{OZ?(%%}+iqosEj0cv~=QdGG;a|6s`J<>I?1Is|DX{f+Xa zZ>UC%qTgh#S93~X5Sqg`?0<)|lVB>CJ=X_Q0>JJ!=B?zqL3*F`!u`5$27@h15GRjv^+D6>X8_BPhl`;Kw&&hRlWiBo;=Psel zW-mh%9^B4_nvg)5fR+^Ut&>`NLd3mjp`RY@Y!*JmgnP&CuNa8`Rgn6#gx9kZlj9{( z4ENd(xMETJ;C2=SP{El)T+~nX0Xz#ocs}imy#88Z#+;3T@0kA5zvS~Me5>HquiOVE z-~95hB7!#_{LW>yC{cHZol@gJ$z3dYIm3?U=m+bS)Xj1_u-2|znQL%hv+;-fuK_2@ zFPV#-*k-Ybh6QZ0VM&n~f=|r`^v|iStFONcy#2jWe z?1J$t>(E#&EPJ7jgW{ia{f^lOx$yINJF84=1p-r{o+o))oTjJ@?pq0^Ha>FI;pne^y_vIh0NFJN{+ZEfB(BV=csUFiqf4FKY{qyAL4>oxv3nSOo8LJ zgFCUSX(+_Eapasf^abS_3nv4-{bF7R@e8VHg0v;zPbA3B(6c;D_lMG9d(Wrql)mW8 z`w0ElrHnoMdr~P+)yQY(0GHX1e&)p{QE!!Hn9K$hWa9c@88QIn8uUdRvRgUxJrYS=3=J-5Q|+R=|W)PCA-jVl9K0@2Ay!xXjJA zG(_nJPL$sJwvMCV%i@#pp_f(bV!fQ&yQghT0Hp}^yJBkRBJ0kIy*Ozgxf5Z4+aQng za*)Jli*6m4IY^g$BlR$}V7?my9eLBdBQ$#BIK4FW(Mxjh$Id+-ATl@vo*)%<*e)q+;k#@p#W;I&> zC&_}R`)TJVCUQ3oGXLgRVJX6SgB5Se-^vs%F8hXlH6N(SqcY_ak7K>niT$_#)pB-Z z2-PS_Iv~6+erT3#>O*eCziH0g{)tslV`RAVlPv8%>$_2qJHMZgT?yhnUHHd#R`=Y2 z=CEx?Dkrjsu=iw>Pi#t-3WwjF@$3H$yUrGJ9PzM&e2IqhSW)5MB+bF&euNr#VF;#1 zMG1+o|MM2v`|HK$3lE+P#H#O9NOWrO39URmuQN~!Z4wV|=9qUBB|7hEtI*Zo@_5iJv^ewH<`ReVro=mQfU6NSzkfm`52sfgu`*tG zYAW!Kcz+foKi&c*mRq6v=V~ytu8IBO528TJ_ zLB=$^wMd}@dEIxFFg4}wZHGgM|6-cmALA<8Mj+2+$rO!T64l2d4Jr^YW4pUkeUMtO93NcQT(zxXz};>F25A@}xQk;my^0sHCabo$(Lg%K&9WBLgg0ti z+Jh3n*`EGUA!urDev>r=mQHWdbYW%cH$+~A3|>w~)8U#sO}x81AouzE}kNI!Oi;qBg&54N8b4*$iD6kO3lozD<@ zi_icsM9IYcmwScF|M4|&DO$1V`7UJ!a>GIyrr9@J9Y!FQ#!xGN%5{slWAy(H!kFeW8W!J=ed*VKol!P@L}R9CzgU*N%^mZhh4c-(A@2v|OAFnehu(T_MK6VslKI2ZKITAJ%)Haau?!jt{HH-h1c;61J z`5KR-+o;a~uwI^vOGLt4QmyauBwyZO!A);FjER8a-|-mXv7O9%-Dhu$t$fB;9-cV2 z3lI{n!Q1~7mEglloLzH3-?_`#4md}XUxyf4Z%k@wI4O<@2i>w#VO0Iurk8@=^qBNh@8*Yu~UB{ylrg0!*)u{keD7AnDK1 z_t#NJUIoY|qjDKa=^M#X`2DO)6rUq9jQ}D{{(XxLu@Mc z5M=>*{*{mbS|q*c)X`t*M%c}BDC;!A(1TbQ1YmDSYd{)mQE6Q6!Z`pX|S30tc`4g$w>STb7w(F zsO+;W2$yU2src;BVO)SM-0Y`L$U93s$*IlttNlz#nDj;SWQTZ(mP0zSI|5b& z?UU>OiT&g_(Q)Cj*XcCH^Y?{=OhvLo;?Wh}c~$XwHSu{NsO$(4N&zWAJQ4_JB7$fL zIh|8a)^)6?XSWH?-(#$WXL3?PCDw%{018~x+cZK>pY5*ryNlxJ$Q_>%pPS71Zxd18 znHMIKJ!cDF_*uyOSvY5#eb4(KyJ03Hju8OF^}s1>2vft!#c zn|V=d8UNW9of1J<1JKwY-ls&w%gv%7Ai7@|FB#(_e^ddKvHua2_6c=iCsZN;lzB+@ z#q8^t$Qyj$!8d7_iv&0!^RlN&MVib!vu7FX!k!Tk#@2oiiGawKI$Pi?IRXZe5BG;? zdohum7^kz{th|h?9AI$~_<~FiEB$C`{s1n7ki_JGvuQ z(=t-Yk`NJ$y5TD1%-$F2%#Kh_A87N8(FdJ9VAeF4015dLh3pH#3X{M{elB>r$rsn! zW*c`X1eBuk2a>?Q{YlS<8ZOtI$Ff5UGQ2)b?VmDdTORe)5)j9ceOM*6D9c6OQ$Z02 zO<)2%cnCW$S0qF=Q=zqi#B!r528W1hf>!D~D4xL+Z1-%Ji0t<#GoNpnqyKuD=53RrLEAAPU5aR*h`Ts#a%Lo`rgw{OH zXeI$tKy!ucB}Y!3=qWi-c6&FTpbypD4Xz8$Me}T-jO=qxC7xF#LO3bh;bLG4vzZGkOaqVIm5qAX|)K;MBN;9-# z6lt@gr9YkfaZAnC)*@c4J2AZD0R>vpEp&XHgc9)Lr3?1MR@;(Q8O59@%=H${hO2v1Nz zhy{`fUE(azWd?!vimsXUwz0h$4&l3#c$Lzpvh|A-gM;qj+qR;sPt{OgsCXc6^Tt5vXF3+#VpK9Yw&LeQs*|$btF(ct{XnWBh z9FlY`k|~NH(b2-815Z!-@b@&l=H&Goz$Oj!Q=rLIetf!t(@r_(KIl#}T<*Ud9(Hyh z3Pw!0=3<0=GthJ>B--gi2>9)S<(}T1{!CBt67Ty5^@en~!x}c@HDH#6=4QbNT%67} zXG3lT1-l}Y)#y@GIA%B5@xx^$xbB1VTGw`LlTNFnKNNe1aDR}IV?!QDr-ubt`nNkn zoTnXvPPOC9;o*2B=vN;}MtCtT7M~>^vN>I=W>9~+;11Y*$xl63M%{OXNBN|5Pvs~Z z7Q@5TP^O6oM_tGf@z6q?=N>f(6SnumIoUSp$dKq)ru)<0_O}5LAI3Rmnh35`L@V;9 zwC*8x>E1KltbGHxN2N})U~L-(KbH(_m|BB=fPr}{ zi1IpUcq-tR-knsfbh3Ci`Cm_ayKZil&1tF4%NKKnU>;{qM_fH4(V(oP?)1b1Pj;>) zfbn^aE+#^55$B_KmDaZGH#f8nMqIbOuhoW*^ zCKxfXH}2KLb>{B=(Vkx%X+Q%hL6n7Ld7NwG}1wPf$S)!8AY2 z+$S?N|33Uh;WZc22v$|Q78QpUzg^ukB)HvbuO7>P?S_jtoFlJV?TO+slX9<4~TCjBZiF{pQ8s`rs@jWL_A%X4X zG;KR}d8hw)rxOW$LJ(angX4)Yp6z0NWRy=fkE{;Db;85BNz|Wls6y=-%^xL;=j9jE znE(3q%@%- zC&5Cmu-iuuB9Qdr?Odn|MSFYpr3$mcjhmHJB%JN9AB zR-6cScUmt6QfF5C_z!(N>+ngkNnUDCGVSV4`cxN34WLkY9r72q{s(aLi7b26rOfOx zEN80Lt5FJw6-_tWh!Bis2`7Sw|j*i83aYA}obY3s#NL-)5$ zisDz&S#8(fJ}l-7iztv_ElpFle|E?N(mVIc1}^C8j&4XndJMG%G+s{Mvq}COuX{HU z1Y3%!JeZB0dxt1ig#DDAh|bBMq-2MAlo$?cUw}BlV&Sx$4#t*)ke$Lq+Qxu?% zMxWTVjs9S0L3lT|ivhoK-ZfaU&&G<`@*CR7hIKeDbppz7ZRpA|DELD;^eg3a&bd`N zug|y1B|mN5xKePdWiqxU4?ZLnYQ%edmx=i<|9QRk+@hEJm%nHCY3B<3anNmo$zId$ zz@9Ha+b9gb|R<{Uwte8&PpA;PDKuEe}2o0^8ddT+iU<( z@xiiFSw4OhE`P47>Kb-n+t64ko8m*YQNtpIlnsHLo+~*RdTRgwVeh=cnhF~&z0)A{ z(2JDNyM}5&#L$a?0qLNGF4cfY6ELB7La#z-(h-pkYUo8oqzEcv=vYt`1;oPSKWEOx zT+Zb@&)nx~=VI?~eQUk%qmIt5?w-@$|4D2gw;@=iMMTC0n_BAg{*5V?2o3pAH2U~f2C};q3cLZq30>w{)b|(i-;mcc%YgSE&b+Rj>uG}Jd)UPFen7EDM zai5^jv(5YeBx}9pu3t|*8VH>hsnLM1r6kYxw$^-}>abMVzV^12-$WCk~b=mP|1!@<`N>qJ?S`l5u8JW9hk9Ol5b< zI^aC33>K&MljL;A!<1_TXF9pvlDc2T$)R^%Htbg2?KvJ)P&$$QP_s|rm#!`{G}&U{ z+U=FDB`2ORLX*9GKbEciI*>_M>XQA~wA&&kuLLgll}{_xqz{pj3~}3H!${41dLVzeE{_URcsKd=DO|kDqY83ac z--w>lbk4Kp>8LW^q(63J4S~%y;|DWSZ4(MtYad+NKTHem;_mi8upaY20m1BNv}S!U z=Q%@EhfY`hf0%?0lua|Rj%+-d{jNGO2)DjUG7@G*Q{y>VLf&<9I_&5S!UabTWGV6@ zE$Z4^L_5WDp-TawHCMARIIK@9y@KKFbW<+H(GWi3|NV zXu)|Qx*HO4?(fld*{xLqMBMnFKP9!0m3ae!#qQrTqa8%LMyvz7U$NX+)lk0XEp)gz z;BNkVwd5`kxu#Yc_~%?lCZ4)6zR7<6QJZy4H)mv6pf?1UX0Ar>c?SAp_O^R8`Ch2{ zU#oB9buXA&1bYm(=2-Uq&t~l5m2`zWe+T?ls}vtVCmo-$b89Ib#;u7RD)# z@U&B=O!w9O?WG!H9|ZuVZH5=OmG2-F z(1fQ{pZ#0zDig20HZs$N^iYmEf{aPKvX6q0u{ZCy{J-)%d2IGKE7Z{cIXIoRoiY%NPtmG8Vly_F&=js`QjlSRk6L^oxU^( z&4@s}FeStL5{Rga{747E9s6-ZT{*+_3+r>HUE_m_)A9&%B}n=Mlu=rRJ+;&;xjdc)Ta=fZk8EB8Cz(FqaM!ej?QXEipjHcmW#9Taf)%es@STA!uk<4GZC2%#r& zQj7E|r}SM%gSHNbg5T6kZNyt=`DaG+_ao&ZtDFohMj;RV6IE?o#2XH~=qX<#I#XkB zG`wq0?4AxfTN9gIb#>{)TB;KQXpADS6h>a~kQwxISiJY8XIo8jH>1e(apUQB&9ZEl zz^nT$q$CX`>E$u-t4Pu!+5J5o`jr2$JwWKA)1GwexZ~}1GE0m1`Q^*gC9kgHU_}?% zjxT&lIqXE`H)~zF?6fe$26kO3{FCYXvUOCwoxrgOiSaH z?ij&t4F*V1+PbhEYi~l25%wmtXcvQZj(PP#x^J#LAm)B}e@_EytVI=cT4kl@b3EpE zEk~4k3|gxFJdPQAc;@Q)2`ytTTe;zzIrNc=pYfCd3v$q-R83FTc~0OjIx%}|tLE&T zU*<3WR3=YOBhQpZ+^dMi2-pA2B9MAVZ+iKCwsl=qt6=hoc%|Z_jEWWE=^c;$SWpUy zHg!$VcxI%Is%{YM*S=IdDpjUxo-zn}t`Rm;{7SW!;jfLIE4$-JPVj2I=fm^Kr70Iu8zY?e@X-zT-#JWke^ej6S@WOP zB+fVr20dzup3+S^@OUo9-L3T2!Q$FU@y6KavV`a_`gLzR=BCy2K>LBG^Ivjqehcm_ z;IOuq7#+ODNOx!X z^~d!9q3YNTsVz4j`o5d!+<);O-uCymsq@;*#hh2N_!V@kpBRzI zal1;!jza%QTanGbj;4)YM+Kz24Wn8EGLBMRg4&*>IsJK<{c+;-g4Dcym?T$e5AlokH0EN|<$i`&T1dSEuwQ^wb99_MCIesWJA%zwD)xR*}O zt*^fOdi-ujt(N${v4I}J>lMIw?8m%J=(U9+&_pg{X*N8O4dugYPZV4x3Lg_``WZ2F ztb~26RCugRQLG&8@h!)mJ&r~3#VMoXRPE!`!{g9Jahg4G{~g$3_~LcZ@%r}hhT-wX zMe(LR@n*~M7RT{ez62|Dg0+2uZFquxQG#Png7b31_2VZAIKD(TbfSm-eiM~CF z{>zDh$BB5pq+oPXh<#FMcv5&#Qe;n3)N)eHaT0+qIToE9Z=akPo}65ioZ6F|zMPzS zoJ`_N$w8<5@5Ht!rKBgNY&oU;IEBoYT7^!nu}{4po?2g&+SrrYyqwy4oZ7~h){ai= zuutm>PwOd4>+4AySWbI#oJQeGA3~>(*r$($r%x26PxYivFQ@+}vE|E{LuV}5XS@o} zST4$V)01)e|MY_B0xJLC3-bTHAe(3ZFT5bXT#^4zSV4w$5n`rg#z6=Go+!s!mHe%8 z+?0d+^}}O&j0phr;FaQox2lsx+;z()lxwH*cq|#MdUJL}3NP9GQ6gE}z+pcY;IUbg=^(^3KWr0+Hz;_e*Z=!|gJC*-!qy4B&M77HsZ}Ml? zpU>dHo&5P{SA6~Ue7BPYimlFONBegEQLNof?~EJlQ0c^9m>x5yf3L>#;azxWWfkm6 zRKZ-w#Oa!0M4x8!Cuw%KP>ufnFzk}}+dt-{+s-->&nsR)pZu^`WjdJoTGJ8YR~-ML z`@JM0eMBHec+D%B05O~sjP+nQu!>_1^;q=Yk?mnmFcFpFN=llfuX0Py&|6HAp{cS{ zZ0Rq_ljaK%M>u6Y z+eK~zUd2gHdgsu|K{zf^cDu+U)MqQ7z02Q#%0`TGM?F*9kvbdT zNjI3|l8FITurinIie|m?{nXO4&DcP;_(N>C?+}@qFJbt2V%e>Zb(`~ESj;cq3KrxE zh(Q8T^{F#cu5qtxB{(ghS_0*}`=B(m(_b>2CO0<csG z#xb&?JTgbNt?*h-?@nzDV@Z9>TKWE9k2s#RRacO_JA0bcmDA;!?vYFur0h zp5sZ_Y0?(!t!o3(hei5>RU+hj63t0$Ot3G}rPYG#F<}pWN1uy2=Pq($L4|^I>XGs8 zIdoSSIHqJpomTrDgbgVT_X76gWy~rW?TU1PO`>Iqlj{Oym@TCZWhCS*{4cifQrU;; ztLK@k5J|@RTp4FWSxK$~H+r&EK`qG+ns49naqE_4W6cewt9ZI6hUiGh6gmGC7hij% z0^>IeE`02(*g7aZ*Nb@P^lHJK2{HPp?1anC6^CvK zZ|E`bm|`;T8b%m{E%kn0Eh;IZDsKQq=p1%m{4v4WFu9+_N|um6pn#+~ zXjTw?%f0EaSS<<892E~Q&Cd(E@N`T@(~9F#Y_U1(Iza!~-C;@PTCjyUlqnBYj-o!oFY2I5#zLMNmH| z8GAOI0#>uvfwogY;h76rJ2keD#z})Wv%|$zo4RttHjmiif0Ul{WY+~D!Te?zup9z_ z6d@oCGK8x-i)8&hW3c2VsL}b9dB;2`wK@$Om~V26F!E3KMVi)+8hR3j`8v%N@`FrI zBY{E3sMz*`&QKRgo$VW`6HbAhp`UAZnC4S7uy52#^|*=PcESP(MQMR1H+#?{h>!_@ zNzU)J>qe2@xsTix_?0T#XKv5WRC-itnLBQ`2`su@hr(q4<1Rr$yPnvz_ju~C5pZBm zF633~F-B4mn=l0nJhW~umE7LuDoub);{Xhf816I+ z_PsV^8P=pbA*LpKDc|hs`AG$FraC>2;|{<1=W>SC&#pXtC_|2K*_HR~Z7>gNvyfdQ z!WnS@f@T}p*(*4W=Z4ub-c3s#2zDA-Z)$IydWIJXDPpTI9?x4QiuXt;1_gRp*qrt6 z{3Ut6km}v#twv!oAb_{I)YpW6ACL2NEza@LyXemCW&LFQwr_YmtoJ5f+$_Y%Cj(A6 zWy!O&p!!|dutA?Wz>_hokGe+`T%B1ou7*e2CL8pu$)5Q>iET|Py=irANJ?p}E#0y3 zrId$qTDn)NRVzO0!(le9Gy`-;+@?92 ze6u3^;MIxK%i!7V@_82LO1R!PdH4Ny%BcaT2LD9>pp+SiP%|=iln!R2U7qjCqdnbHaLu=B608D0-{@Iw%0b9cR!ZgE5O+_dh zMfx}9 zo#R@7kW$JTj)@%;>;6{rWTCJeM32*5c`V{U2dBd62}C$^9Stz=VAXR|Mc^0LI^$`K zU*Li_f7*k);~N_zzHZvj>wNT8m8>=|@-6Az@RE=jgg78T=TI@5OQ9+VBBzW4{wG+4 z3ZZo%5c}94vFcyCZ-~1a&>b4p#t{;{O%^)>oW1q`c3(LnhdYFMu38f|IZvbGyA|EN z4OH)&i;-+!h7yC9Xx4^E{bZsU>Ob6Q9;}^Fm-j<(DDJj=n%>#OYSTkIlV5e=*I<`q z#c{|bq4-IvU`MsxsX}9`OYsFQc|l>H*jq-DeIUffi=w=Cnvo&LL?ot6Mv>+4i?$mMK8Gi1)jt_Mruft%-n zC|N)k2~|QA5j7yj1gIRoNCgko7qmfyk$0aK&bkHJE+p!cHy z993+L1LZH-lp7Nr0aAF9`6L7Tlko7K*bYZ9Lx zfl3ap*E1td$Y*JfUSC>zntT**+77+ktr<#9zl*9GPJw4c4qxS9&PLJLy&hy4um!Bmq zn^42rqKe7W#ufocBuxxsb4w0OquQG3dxD21>*;Z=v2SY18^FduzMEkA|!;HwkHu2=W_1*0PP8&WZ~GJZWfLHzn5<=5P1aWG~jx zbTXO69GtTcDvLv71srzh%S1jF8cpO~`1oLyv5jN4NPN-Z->xDHP$3w9Te+Ua?#M+P zlUrn3$bF`Tiv+gAL*@5F$-NK9BFLs&(Pok$5VZ_JtsD835&kCQ{!w=N)B`7m0B+f` z497=yn!tIda)esLcCMq`4)CzS+`pKmr$8)(-{Z);QF*`gmR#qkPYgyASf_8F?dDbXJ}1Z<-pd;OBmAwgo30{D9H*C}8?bAWR5!FfefPHhW2(j_sF4tq-FLp+h@p%UG$2U~WMPIHnuq6>3^e>t263R>ys`DYNBdoY5`X!aSktF#lLK;5`83=i z4~4!eyw5S`(cO_Krdx68`W4-6l+c8h{ri)tIZ*48=O@obQ`4s!wNCS18jgm-(q}Rzc74O zi|ONiU4);j&##7>^kV1F_o61pbBmv!Yf4%#i#L=3%|7FtHR*qw9G_m6&;9tR5f!3_ z0|`?gf6J}`1h5?mW(PoMZNX?H3q8hL5M2dmd;=I038;}^G#d$8@f7kOR|s_;_-paqhTD6wBj0A` z(FiEVPDQ?NOj4iOcTzSdPkfc>=AbS2*ZVRyBxrhLhFAYnk(1D0v~GChE9ibII~Jmh zye%69>s`s?z`c5BJfwmEnf)PU-`D2>Mt629D<=W&eQ*>*QIaf38wuLATTX5P(iFj$ z9=|B~3__8MUhP5b@Gq`)cJ~*jXmG0y?Y}M@o7DA8c`9{(bOg5BBBO@|2{(?OT;syn@HBj^nmHxU}I)uq|b zhx`r`1!X6_`X&I;2KpY2z^2P&9vi=>hn;pXJZF6Dm2&_0BM&&H_L`X%fzGuKstADX zwYrqwK5+e;k^3nLj9GEVw1?BtcCQbvl{WEC(q5r3e&m|&$dXLc`*PX2i;ZiudxfdZ zV08p&WDl|!4V5F?(m7@(89Xnl<_P)}C9SIW6qpJLRk@$Xae-CuI~}0BA9(_XVXz>* z>CrQNy)6M-`f$5#-aI?flJj-5|IpX_E1y1o*{}rB#X^86Lj=v$MZK4mxu(A|9=S3= zV5v!Es9~R_FU%B2pn^T&m+EVw`vDP;9GL#r+~1!6^rmL9SSkxa0!!g`Pn4m015e%i z^G5|L#hgc>6lm}kgw}J83^;Xk#>3v&kBEHu;9q#_fec6tIa{?!Si26oWt@$>PSiIe z&#=4;jRvAfpq=on<71DXHFmy#68_dPo%z|uwQq3udWW4<^)*TGfF|_G5@3KVt~;uH zAq<%jda!xcVY#))4gtJqXkf$+r3_4%oq*rh7d<+8u`QVN*YRbH?4Hl<=7X7PcFk#7 z#CJ5;`17#GZ}q|4dDj}!m~PPl;#3sK#jI!5JbRaLQUbMUQ&d%f3fOm3R{Oi^;!yBY=~1aOb9D z@#@>lD>DY+dvuIxuQG}UO@<0C>eKjND%5*=f=Bk#c@hdB)tg6G{Q_wFS?pQs3r}Q{ zZ#o3 zbzPhb3lS00BKJh3Sp*A;Y7pWq;?*@x&CWmp;(rP-y}gLg7C=x$g0->5S&*fyVtBL# zeJab5z^%k>63kM*Y(vKk2kX8wVuo&PZe4_)Q_*%%*2g30zw5jE0{r-AXHsY?&uT(>5?I@fYZC*a!9SvrDIK~@r<|4hFn*{cNt zFjCcVl|VDZ);_%RU4u9Gfecy1Uubh zq!46K9?YH*l<}vTe#X&xPQx|9p9d`%u=*5w-! zLnx~5uh<#1QHIc(rdYkp+S`)}D$c@U6bwvggeHG9=_Pq^(`eglm9M-fxz+W%5a4WE zTcRr@R7Tu7xn3eX`=XKlN>1zKoA_T)OjtHU3WNueg zX-&)~!8kocu{YSYO3FY6_Hr9)(jBOH1~nO~MN5?~EGwN}_b2ye z9-<(GxWU&WAZwKrc|q2%`^Z?hvVV{PkJvBjFe7sMRHH@O06nNHqdxNgb6;jTww*meL`v?KD7M)0IZBaPB$WQN#y zj5R|g$_Ks8+nafNn7)3_R7SGOTpV$)zWxC~P-R8P?CH$AcQEOJZt4Eax3bv$=J+8W z;=oS)pmo9je57}}h&BVSG65QGpY}+Svl+qvhVna7qUm>okj3pAYclA=GG&lHJI>rG zoOYgyT{7lcn%1EWUtQ7>imZSndeDx3#xp-FV=^!CsQ-vr$d2oP_oXW z4jLb-`I{Dju+XbgvBx%Wund~Q$itH%>3KSh3a>8DZZ{g@$ccmH_vM+{(*(Z9IHn!F zikStwGnk;tXim@)S;1b+a|Cs{wx1+vNF~htWh0pS5Fj#`%D1FUw2Dm5w?rHMC(Lx0 zir5Pnb#n(qK8|p>?}J1Ya?5?GpOCJ*C@wb-9Ql7a3m93=*zURKh<4e z**qPNVD2aUTw>=dOD?E=Pdi2Qq(DfOT&5Nr3YRwlP_~8~|1s4QsS0;NLpT(5hpyU@ zh;TC_i=Ltxh{HZ{Py!~L0lFeSj{}~C6kp^z49*Nypy#wk61i})#od-dj2}Nt@YA-Q zp>6RBse{k;G!sfH+P2m9eldxiyeNHFmck*60)sV`gl#l*Yo4qnTN}_JqcyfbQaB=4 zGS2!<@BI&00HPE;jk@7MSq`u5RuBG~F;G@5&C!xteuFE_mO3=jzUXu*B>EfJq@3-}?!6mo=$96Xs`w53m4&0KiQEFycA@=2Qr* zb228nDHAkPuQy4{*6To-x0P_OpW}>^i41B9x;L+9G~W0y$fT;rP&-NO;4oIiT?drG zz!w;Mk)Vbm=uC60N8V#? zD(oB?#E6vv3-}rld0cvG9iHD0cG*52P^YI z7Eae~NW3VFNNkfY!KJF+Q-F_`VA>QbG?_qGfvFkYbxrm%vl?@=AO3s5n0#T{OZ{#U z6yFLii(}?_yiKg-YR9T?oY*rlLkq?u7WrU38q}Hf5p(hAcG!rRtJ#>K49YFEwev2{1PeG3oHalEJj+=z&Az>6#Yg z1IKz)P-2idKF+Q_1aTL}D22HXDWbykCWw!6+40<=XqS>H^*X3BVKAjkgj_qw-G&&x z6my4nkF#58=O_gp-BBowwkv;g5zI*W4gLP)Q_`K55#sq3DlmaLgCP;_OH&!HEFaM~ zBI(*{tQ&8Zhf(~ZcX)Z7%W$Wf?i7pAgmWt(uL&LQMuOWp!j{!+`8B3wXOC==E3gxE zug3RX2vhT%6fEYK;-SJpXQaczO69Mjy9=CWfBf088#fI45dO7wn9tZ?P)KSU1ZF}1 zJz#(j!AhQgRJ+x+cyI`%7<`U*lt2185%Bo4(VveJkt^>pb^WUh(#dB|_hLlOp<~%j zNS6Kqj{E8gTJpj2+!eQbS6IjIZ-_gXXqsP7xn|V2Eg1`8;-egp!%jGvkwhhll^xRE z{-+nyPY(N^u6}y@X+`hf?_*_Z{?GUQ``!Ct$-<{wj|`aJb8u2#-c7JRE7BIop`^dS z8_~&&zoTZ6?kNx8VeffkD(XOVR7AbF`xs#21za!yUX^eABFhffPqrqT7*`|oEW@G2KwU5D}`^Pv`y_%nC9w46yW-ejVM z5mahly^&-ti-+;hgX!=ftNjE6935+$-{MY;tV~F2B8w!?O-0fv1Vwd5QeFBwF1{5H zRsmS*)(us5Z*bt^o*=?wjhG0*Oxo4Pa)cG$bzO&Hk*5Q8&Fb|UL#J0IX=ov(JXkN~J0vxB>>&zKrWIhO_*@QZ!7H=8=k~4p&$~=qHKVDYyL6nUmKZ-6 zD$*G<-rUlAf@3r~zGTYoVXB`p>TwA`fjEJf;vzt_?P@EQ`%4bw3NnlT1`Q13&Tb^) zu@mUkjqjzq)0X7dz3pa+1oxq1B@5gPP*4n67(RH)Ycqrv=*>G13q%t z9Ak{sR1Qkb$a0$Phq>f+~`&nt4tOU$%kI>n0H&VO>WVwP>R3*|N(AWio9rc8Y~So51bxX*Zg9>u4|B|q&|nxg0vMF z0NRh~@M*Ti2G6YTq zj(t1m=?Sn_=`xFveQ9HKwu8NTU^&0`)%)UU;{ERSchTb5*}!Uv^6^XRyZ zeK12X&3@byjffu4D)Xz)vEqM7!*&OiD<;9D{aj%f3~3)(&#O!2b-;nXL#@9uotQBH7m`!gL@U?|Ly( z0&@PLZ`)Y;MjnGLNLVUJ>leQ5b%FTV4)9z_)Z&}`x}cWN{O08wo-9}(p1^b3#^E0X zW2Df3nZ0&SK!TP6iq3ZN)t9j2VHR%*QaNqPTDJ~) zai*8!C0E3(2K2bW9K@+&6}C+hKScsgTmtk!pD;%L-R-VsY{^b!oqQ=IjT5-q_(b#% zbLfGbG82-%8eF%4{_dgqZ9W`rY4?YTkrgBAj-aHIYGG!qp*j#;WYmR1kfwDY*FMKB z2>1qpg{%1@l+4S=%)qGJm6~t~`G;eK*uM3wb%zFd!ZdB3FwQZYnyykL994%oXG^@~ zqtV}z->W7%;G3jGu{)|G1aa()e2d$O*-sE>L7o*W1v07*(c9;~T6QtwW$#du{rkRA z?EIM4Ttr2NGz}+Au4eX(e=uvp@T2}PV+q(0D&anrCU)=+k7yowU1>FbhkkOSFNr}H&a z{p&-{nxoet)fW{d_UBTl&9ETl^lEVYOZEs^ACGDa)lPKBH4*(!#%L-?txfPsf-Ybb z781O`KLyPK5VmtK(=AJ;_CjbFSbNI*S(bMI6=XzSSyB|g-vY1G<=bd6Tt&Q<(5Vps ziTo~Gt(sev6Q751uZW<+QtsU~eMynPiX0f*>XjLK)hSeN9{V?KE;HlOzNXj~A?T`Q1nDwSEatXS4U0Ez3?NjraJc9wTT5h)j z2ST4_V+jw2D(TcQ`*`bGYqbucK4*#QHiY;bf1aORvhe3-dyA3QUwY07Cugc@V92J3 z_Jzxt;xIog%6Hwl$DCdopyGjcUYs^AfI$pJt?S6Y+T|s*F3?yjn!9B0)g6AGysIp zbJqJC>rR>NJzqlTP@tdRx%KefnClJ$VpHvZFW`m{{;S)(IeB78j*^GMd?%mtJa)d- zil2B$(LF-gZ~z=$r^9;DG%FNzuQdfpSeNr>h$caJ0dUpe%g&i_UqA4zzE&yJ^TIg* zL+XFPEZ;W5^4p?@_ZRB#m#-Bp;dWF=wit(z80*uc(#E69nJc>5RN?*{_PQLcf_X0C zwmjMBZ-2vK4XgGu`_TgA5?RPM@tg9tK~PcrH-UN`Bu08LD*N;o3(Kvw0(P1Kva48| zNjJU=galdsU<*6uU84IK1YN&s;}M>Re0qTK%H+?e-qT6ZbVkxn8Xsk!w{A6+aH1?f zUJyi)`X2g%J^rk;y%mbBU2Kz!yvYO}7>F(UHpRlJ@L}-$#vaSK@KH(m=bZk7&+!s> zyN<-h!StP{H#SMlZ4#0v*Vm+nU-DQ@(jxv}GrBt%(Q|5u3J5S%*VNvxtG*(|h<0xM4`Yrt zS){4MQKEG;^qiVle%J8G=tDH9jJJNeT1QG7tjHoF!h%VKfR)m?xgii;6(bI9Z4M5j zyPrPqefhfo?fb!Z#33-|3;^yglTYD%%*i?yL+PM%MTlJ;a^-Lmn?ncMvc-{|FYeS0 zj$AN4BMudouP;KnKZ_SI$}9rD$r9_mP?ki#N9QV@N1;9VaQ8)xpiF8v8J{QJjAcV8 zMf^%d;T#PRS#&;}VG={V5QnkZw^N->cAGB%sk5R#)X6t zx`pO!6bkOq&F3Qz7$P9|Oc8Wvp+UtRL9#4#?fZNeI+PWncnZ`YqJw(!&&WP&#_Vgx znT45mgh?o}>2;2CLk%QEWk`X%lSkCM=lw^0ZHPn5Rv0kObJutAiH!A^fED3epU!&V z$ne!vi9{5~+%CIVzC}70su>l#>auLQm9okryd217@h0Ai*}6@9g43R!f$-tRT*>6-- z$Kx>~8ayV?)K7&YH!?gRcDH%v1w z;z{wt6a?gz22_<3A^N3#he%3@e*GpVm*HCm(-8aMwAjknvSB)e%{}iH0dz@WIt|oe zjvVTh#sVKae|s=|o&Fj!DaXUvydV2mi%EjQ{tw<|T%I8_H-W%f>zlLd6iv6eBLxY% z^Qf>0xp)p!3-%m;>Ek<%gAX=QX^>#kz(R+wC`ChHizT-pD?2d0_20T8J@tviS(lUIf$d4EUbUZ z1u+`F3p71vZ~4L=ASLx}iG~l!bAL-Mlq+R{Svu7dq1O1O?Tinwem7^Bn+=hfM@;+! zP)O&Duj-4&1+ThW?=BQReTJNjGGWj21~C1QHV@v)30KyNHHAj*26UA1T#kA!?5Fen zFbOWN}MY4{25Y+IJUT2kKbh%jI39^4&cDty< z$(^R@84N@QeF~(L2yj*0N&)$ziW?t(1)`PtfnjN;zS^dYR zrDHH6mj>C#olh>177;|!Plto~Q#v1isb$Atf@&%qZ6JJOoBWJLnDp=VjGVLj`FcbQ zT@R+eF>21|VlhU<9YkQqdO$Nh*2T{J(3feiGZiM+ILY)p+D@rIv!WAk9KL0O9n;T~ zP<55Pims5SoV}Yo6?=;N4&hvG^~nGsvc+J;tev3bT<}-PBOR`Ww4b@deIHe4SYdwN` zP|hFwNqzc6u#7_q$}Lq|V*>myzA#CGQ8k-Mp}ukGd-q{74*W+65avXHAw|HAKe1`e z%=9TnpBYG(t2||{VRQ#Jx8hfrbm6)P5uq51nqmJ+?Gq%ibO;KKNv#8AqF&5~2NXsX zc?4L2#k;|iytflzP($ifcNwet>ks)&5_ZZZ25p=L;IVoybj+1UsfgIuHn6smI3d6{ ziB~2zrS*WwiK&Fs0YqPRm2w1PP*Ov1G%BRe{tuM`>AJ;iy1}o>RCXX0_O2H0fi)N= zZNS48d{4n|CdV9@5238aQoO8b_N|D{`t!YezM*0w_cgh1aA0&{i^0vA;qL03Z~`2R zB`}4ntI_;CzHGp1J{Q2~#z*qG1;o`|_q^Tw7y}%`)X39FG13c7z6QfbNjJx%onEw<-;p{v#|QnGI)0{`7{=tDHI?~ zNgheZUkpOZoh3YnD5HfEqp>9{ZxMM@23J^FDfG~f)gTG=L?N@N^$6$gt~Qy=Jj$nU zBrGSEp3*hoq+T?w!J|aMc16Q<)V8Fk?_yBPt0~#^%x{--z-694KGIwG0en4dH?}cG z(zscA{&0+rR#B@xV9qQkg8|bjy1uD=a>}_8ue=P2a9V!@=D)^R*J>W1>d$vZ?zUk8 zr?tpuW`KSZR0!EqiElk)Fym>nq>uhl9FGK|J0&G|TT@}wHX=*?;DfW1L!rW(B7X>Qorz<6J*11A z^aMm0j$yPyLSR2!ncOjlFzv{8zPMy8!puHgH&$nF0|SfG(GzbI(#Bv@%i3^Db|5!g{%if4$ZS_y~AbpEvs zBXBQl%XRzwY_deD%ir=>z%{j%9AzFot$wRGaplSP!YjvHXO5!3seFe`rA8K!v#^iI z0KP#!qHP7DN|O_r%pYG04$^k9VEfCb+3fiJ?$w{p&->~t@s6!ar!PM3{u>P#!-1H7 z=zye_?#hO7*toLt+p;!nM=>5pMHPmz8sCXJ($<%{)M60*#hY<&8+oe=im}c6=~yw)h(w z8dOL#0ju+qxVmG;_5<$`Zc0Z9j<5UAwDK0M-4uKZDzu7D<1^*A7NHw8>(7a;mLeYLAQvZyWd=x4`w~Xnk&j%?)wq0^KVB#22X}YY!pUC2Epjbq}uu zp*a(#d1%G4bYC=m zVHIOxPsX(Z$a^c{ljAJI9Sb6N$kW|hgFW`gC@||j$hj~%*Ru#g;ls%3{JvEe}V@DaWWf0IZYQYV{C#0PHy^R&`=?7+`;tOFQY$gS5&s z>Pu5Ej}{-pi7&gEoeJ4wbNyqa28UtfVIJoW@Q`xVY$&|s-S)c^MPuyO4q{6*-3|DX zWlr*PPOZ$lZ<5&3zqr!{>^p2&1dk`4Ft`ArArTC$O zqS*zt1Y7U=;$Ajrqo#f#Rf*|jRjOpJW>7MF#xKH3z1U;~M=>(KD0f5QZy;NjJA{Ji@?`KEl}9rYVXb`~6k7Zxmp zq3}Rc{P;=5rRc_N8($nYF@t&5SK^9wwau)aLzJNTOTy5Nu0J^72~o>o@S}(+t)g zA17vcoNY2V9&z8pN1N!QO{&XWsi{I45!q||?=f*$vxn+d%0n*V!##AR1f<0xtIn)_ zGCb-UAJ)IO_F>I$z$5Cl(e>5yW{l{xf}&zwpUb46S_=<4S_~NWQ!H`^VQX0-wB69b z0oFOw5VcLN^Qc=u)Tf<6a)ux8cIMz+YSwEJhbL*;nq_4TMod_AwZ9@*M`O7tWy%mb zo17zX3VE&4y11h76mR!H48b@5K*!x#2vRM)-|TNIUdBPEwogDdNF@x>#US#hU3{n_ zHFk?q4h>tu!p+%;wuAUqqvZz+IblV=S|3nVn%!&~(ImqD(E8ofsx)MgnYU~f59DU& zW#DX$^Qbe|Z)N9{f(_jgWQS4^05^<5Ndm33R^esl3*EGyaIrtM0+Gb(HvqK=_4gNT zz1!FYF}rfvw%(J5*F_y{s*Ol$b`4U8W-$33jzR?~<5qBGr9O>R-znTE{cI&%!btM+ z6YX^;aBEkhR$&rH08_=hsJ&hC?UWAI(6;!MIw{92SL*xw=33z+- z^CJlp5oCXkJIw?N#E4C!LR*P74T*Ds&_sY~f9T!&XY=Cq3Xf2^^l5J@TAINXzh2b8p@!rToBV&84s_?2{K>*Y`b+iNt@@9Qe`;!qbt0m!fa#LtL=kwpZ53pe3ho*JL>*w|PDM6sh#SbjhxYzOE6=M%XGXX}gd846 z^}O)F&Iti}1D?%7?(ur4vLJ)mHv_cNVhz@Z;qh@``FY;D-;hrzjwcSyc#V;gok5sJlM(dcND$97+S;)S*^yt_Z0ZO9Z&L` z|A9pt$fd99vV`qxOcO7rGY%NCj&CvDdSxaFW-EO~O+dI9j$Yr;n64eZFkSeeHb-W9 z8ra`@0396?W1S&USMmLH3b~c31Mj%H9uem^m1$f)Ycz^FeEb8sD->9N{D5J8(c1Va zKkChfF-UZ6=0Gr~DA0Zu{_2)%mUeB%L!AuA+3a7zARWWuHz85;p5qV2)V$Q6pXrdZ zCX0c}eB^JA;|lKAdc``&tvD!_!1j=`S|IlF8xxXwt!dub*{w1E_^26CQO4yrg%AnM zv)tKiFAVRDN^_R@+zqD)dbF33d5;)pLjdEu*;p?ZVNbFdJd^L;{sDC44+}%S>ACfC zdmvfD!o84H{(0KPGqRglzBajdLZgR%Jo&*}1qbsIs`<&mt5iykU^0O4%4BoH(0)q5 zVFf<hGtB?>wrHr`c2(_S+nolW?l_cP`t>Bly5nL3Ktela>H53Wxiit>aIL( zMSS4vD!3X&8WCK7W4vDd!Po`jcx5-(jcutj9I(QJu{;}J!(Wyi-{sf~Y`xTeOXH)p zB)M|5)F9>J{=T2#RdJ9U8WiM!Xh81d%x3!|ub&@KnNxPlt69EPAx&p>u16{dO>V)x zN>EGs4cdJ9#+(e8Z6ddeSQIlFk7^m*PK|ik-c=B%_xX$0SL;DsiW0z(4pp75!U``w-}U+A|jk#EfE^VAN5uhL}b2|#_Cyz;!<@9t}V zH%$&t*4e&6Ki@_i>OwffU@SzK=$3{C-h5WwGKsUhMJJ+D3Ix4Oy;}Rjt}Q=!|3`%E zMc0@i2V@qutK%z%1a_DeXnBv#N~sxc1TpTSilWIF@tN`;F(?gKU6>`HybPXOvV7pBQeE(a<LeY^f9gN z`EtP7!j)k5bbrz68ul%iI03@rQs)MUr`KNTb?nqH6WIOoW7|5q|sBrl=IBAUWP zRa;lz&{)qwp-0bxrxqn6A7U~xVr2BAsw2fxwQ02R>V){~00@a2_T5 z)ej%-0pyo2k2W^9$d2>>Y;1Q-3^&-Y8~o?2~v=(~*or<+K5c7?`h@}kAO0GVRz2BB8SYG(F zjt?%B#@~HpG-d^7vrf?-z{}W-!E}0>Af!tshO5HRre9d1rreto%g)tiT5DTQcQ3b92hO zepxfkcGwom$byDL?%7_W+(IDZ6t)LDf9G&m4)qUJihM5%xYu~+dHxl}pJ(8d-ovhc zQ4%sIfWU2}L^5FK>=O&M5yinIGr0NKMeo=IbG z)R`_+FfY+WU8WDpYpg_$uRS*nEBtYj4Y2SLKleB01i#F>a>_*772B)xMK7-~-#Ou$`ZSEvAlm^FSBlym%bnOG*|(F9FN z=R+dWbueZ8|4w^96;uYldu!*ITg2W_AMrajsIr^oei(AeaksC%d?`P9Ejk85Yn_PK z;&mcFe7_law?B@Chm5WaIO$KmXIb$bzwo+uwTi;(MMl_4^F5NQfcKLh2TYv(Y->6E zqbCDTF41+JOT>T$*CwXZRbPh2Q6=i`7r4pzO`&ZVB5WpRn7odO_qa`hV`-E+m%TMQ zTs@Dji!sa|g!(^iyz4-=RbadnGUA?Ezdc40W@z$lZ0p`}WrE*1sSLMV{g(XD z?95i+ocy2J}mZqGAj7dyX19Hu5|em12LfU_b(k#)cCJU|DKCGA6T?IXcu> zGGa)hAeAzLO>X=^qbH433;|_50Uh@)qU1%mw4nLiaLyNGt=b5`tNiyu)z^=elZSfiVj(7qf&S}Ti-aMEYw zLzPuNiXWeqPfwg+s0qyrvSHjRDMc-2JxDzs9eq&l?9Yde91<5GR$xu-EW=Rpt98Qc zz(&eZXfa#h(zVAVfULqFL{Tl)MakZaq%<|3rFS59DGQH!zP8TgNw8qjsKQ)-dFE6P z4(>MWH;KkMbMk*>9n%?Wz0%1POGiF;5i$35qab`193z3olYS&O1`WY5^HpLnD0PN8 zM#!vQ-7AMGGl4cL(yUtw?aLdy7Ob(;mZCw?f-z~Td z#Tb>1;9pu>&4sp0K0XVD@!Dq7QOk|mEEktHFc3_wYX*JkgjkyerzUXy)O;u<5#5`a z5Ler~4{V4Rn22ADX72P*SWqv<^m^prxbdk~BP_?O_vkX?lI=+eWf_w6(8oy4 z*#yLBTE_6;7J0i0!Vt&GUHwYSY*tg-aY9^P$$IAJnUr7@B;@Z7uLkO^lkuQ+gCPn1 zZ_x& z=exG8z*ev_5tF#6c~Y|HiU@`sTK1QBlq-TsPZW_Kj&v z6xJp^K2JNQ)!33gsOU=pCx zqP(bTxPv50g5yptge>=$lsv|LL~%om0k{ueH%uK7^62@X!JN{{q*=x+zs2?cau=?_mzFQ;PJNUWa?e4V9FOY22yF z+`f+C%vg_l?nl3T7?C$OR>l7FjW_*6(8sQ$K936X+>nmo#dIaNGKc$GKkH@W&BU+#o2ukKcmdJefzTvY zDZYtq9(yL(QKVD1W6@-i!b$&aOPA)MvZ>!@nqynYA7N#PVC1;=NtA3N9^k#$vfuvO zAyO72DY+tJiH#1C2FEcY0!)UWCzIfiCuP8`;_560`q0Fk!yoOBr)h`j%P55>PZHup zwqFH-WtWiPFxkqZT2RQ=0Z**z@CgG=%Y)Bb5|R>*VJQAc(2&JOKa>7HHRqnNqyb7= z`bFS~%^!A{k(v5h^@4q8RsCaQ{wNP;uK`swjnKaltL+LDm)c0N>TQM=qjiMi|x$gcneZ9K=b z9=Q&)V5B?076eek!QglmhquuUXa>%SJ4dx9^1q`#@>#rtJBKfD%C<+V^{RgUOg=)2 z%w`Rf*XIl%ShgPAkRSx;PB0+5ZWt2Ekt(#rB`1E|3g`NiquS7b!nLsV@@cG&VSt96%bR zfC+uSdz~Te?jfA|fn^kFg619{HgTq%M$%4cvU)MgN}RtVImwY}xA;_6l=wK?B_W^m z2?u+^gz60({ssnyFo01m<7sWUn|oZ(gxq90#rG}PtOnt>?g>lQ8FFomd}L-G5G8JN z@2tz%4XQ6-7#_MY)Jj{ymV@B+cqweQ{3%GOFk7WBTdgo#;VT%ijNg!T|8H<2fjs7Y zQ0u`SqR|&bH^fospk4-#4d=#}NP80Vh5KdO5jAo(gc?pJyZ_GZubRnGUb$@i_#_6Bm`NeId~N4bg%3QlB!4}k(>#nJc^0uBg)Qh<%y!AbJu zGI&rQU&gzoOp8<6_iR}RoU3%wtwkb37Ly*dlRebHoB^LFb1z%{6y(>Jef6}6NL8$^ zoUic}{Fl<{jx>covVaU)jO!HL)Uillkj%ykkS`OnbqblC3iH3xzE`>$tx46}t7W*E zYx$Ws(2a%rFoWtVxUn$%flYBp68_@?o@~r`6S6N6%Ps*h9g@>aO^DrKF((?{FwU$w zSinNGV?k5=E3~s`{n;?P^SWJFLpOOz` zwXdi-sIu|X|2z<&bY(AS6S{Q7O(6_(Bo=)>1<6n1bqj=(s&5ozL3H*(yEahUK?wU` zu^lNw^Z>swBvpRHU3=US?C=@nx~*83?Y}teq(31u>%^AGr4ffbwfDK2??tETI73g7^`g9as$iw4Z> zW3@!D{9?`wfQ>67U!ZQ-A3!pWbw=w|6o z{bNIEr9pT(TH!|Sh4=BH#3M6^K`l_sulG<}RaCPP*H_fjkp9H-%48do9{rdTfInLS zZUZoLjx=QgFsWiRJ=H|npGivzia}vbbf^~=1d_1c`h0Z@K+EU;Y#kJg*RZ7)02`db zRzyH0k=jL&AWri&nmXW zb;!?=Sg7GPq=*~%GAZ(5>u4L#6U#uh_I6XLJsBw}Y07jN456x=YPTryVY%}TvEBjf z0l=NG9eHmkSl$=w5xoRIQ#h+KlsE!S(zZEnox&9fYtax8Kn=Zl-6fj%g`>6B!Ig2o z@HPAb{F9yhlf0u^DDkr{7l%~ega@7&XlHUy0|b2UiRJI9?x0tm$Ne>Sp#XwOgTlGT z>oo7`G{UaxuW5Lrfq0bZt96Xt-Mmk1)?V54k3|6`v zs&8W9T~pcR_i5fadWA{&y&-kgH9{UD;W*@z-5oOuOvr5H1E2h&o5fF2GY4Tmq`hBvYmo;ttS5mJ)JQV0=VaAM(JM3~uKlWWE) zuFE(<5d||@Ikf}E&*WVE!u8E#W)Kqxz3wpXG|vQsaISXxa zh<2>1UpKI}AErgA5}aA4oiF()sQcAC(pU2Q$?Oy=oBp#3aTPby85E)sgrIr|2qES2 zje=onv+_}cm-j#~=`qxuvr$dZ)>ZUdUyl7{?}g!>MS+k3V~cocVHLdv&V$ z5H!P`vz$8**p$xW-afE)7&4I5{QLF+s3UDW>oR+w#|s1*vpUbYsM#H7HNB*G^MiC4 z^1(YasJM}mmiP>30H*kB!05{IrPrI9?@okB5P0ov{=P`j(`DQ@)q)_ROCig0FgH9B z%vdQWtJL>MUF6^DP}ZPnJcil?1GX`K?Poqwa_}&0VVUvztK5CT={6LWVKLu2k#3St z4o&gKe!M<>q47GSaq6}A^KgsHTfwvE&DMSf?4O(E}*2k@@Top_d-W9`7RSbUM(s`Qk0WQ2BVUVTupdJA^^E5gQHG; z3=*hKzdel`#$SW!zwS40o|nSE3_^a#gqzD;^jbqiBUytI+8d=hM5r7~tfJ;d-8Q6h zm}{nFZustQT@s>kWe@MBq|b`y{sKW0SF_y~M!v7@w{%Y29uD4TKqBS%9U>FrzPH00DY4m-;$`8R>{Z@~T~6{RHs(KXOT7TEQ{ufNe? zHH^3a!OX*hrq=8hZa%R-BJ3voXYtdE<*2)MfBL8^ztj6WUv3&2-=J5kPdirj*!uv0 z1W>R4&XU6mbAP@|OM86HNrK2=gBqilMog)@2jPV00$^3*VlHJbcUpg%M7XzEGQ zgCVZS54f+#QKdJfK-f6*vj|sWM*ibbu-wh?;-kYF=L&qZvzylh2un@MV2kJV!l^JTG*zz8(kr?XiFNfg)04@(zblU! zkH2x))0NQ@&x@z%;Ix!_3~({(|5b`WUf9yAQe|c5goU_ z@=;?`^Z!1v{T~&ir@p?X3duw!oOy=@fM=6a(=#(l{P1FWxJ>%ncS~uOnR$5}R1~jD zZ1@SYv%o$NdjFO`cRs13*4ePn9Yj6#Tgb3hef6rN| zSRBZBtWMDLK!FL#bkX=$Py(L$W&;fjNJx!hAV=$?h_2V;R@q!vM(%0#<<>0va~XEJ zzsf*e2TeR|Ws3{PRQ|g!cFlecQ0Q&)^KaulGXgC$#*Kw zgSSl|Tu>0_BwXxk5KOJtoqHy+QSg#Bjr-1Y4_$t{nP!a#`2*R->JPSzTde2Bhq-MW zA@YJA)D$Zb24%dRmKe=^>4waUoNd0ZZk_oLcW*bcTfb(c-HGP8jWD-(7V#$$J6lBL zW>O74{Ges|&{;|=@cyS3A0{aLx`CRI$?dNlRMjwpoT%vFhq3n9iC!7}>#xAq#I?X#YNJE$H{|20|xTbxa|`O7?u*Wuqh(L#x39Z-l@o!#6uj$ zOuCG{u0r&35>ChZl3^7l^t(Y&qJwA^ZWQ!&nS23bO(K21^(WJPJ+rxBX*t;#4An$1 zHlc1og{_gmbp;-NEd)yeQZu927_a3|aXWUsP+#1}Ec-gY=rtDU(V#(SxP2cc4SrD{ zuLU3m9flANCXnF*tp<1DqQtDAFH~ihCTk*)`}?lOYH{+lFqwTma9-ejHY|MU}h{J z@U-R>p>+|DJ8fM9+FTnyG>tBbuQt0xe|f>ec(meRd?y}OiE<48`n`Y8I}29B-+AN} zrQ^}~!)29r7y@OAPLTjYvy%DxtLq#0hY+=)BdvDWKTCR^(QIFyvGt68gA1-7z|ABP z_O2=u1X2`@U8=Mui!c}Ia2n0~xt+?!KB^u*ow+CaY{0(cU{2R7ESjh>yOa2%N z23ljtAcT&POak$mTg}2>7E@4wUNcdz%Fa97H#U|QA!a3e8C*q}sTlWs>wd4#=Ot>Z zk>I7MCzv|xBk{8&_t&S${Pth(0$ELR=CzAI_>)p=F9G6998#ycB3ZMFqrQqQeG4ql zRZh1!<>M;8q&)EMk8nHQQ{HYG7wAVbF@^v7+WF8VaJTnC&hMqvf0>{wh3}-oWE-}; z2XwWze*W1TR-B`g@p~73ezd!nJ_lDj=Nb65kC{zt(^En-c_ON)7b(chy1R>5Ad7zW+aFzgvz z@&6vhR;2?y-2$Fl%ty0K6DVCw`|jcg1-Je z_JT{1^g+aEcPc7)jeeBc`U?=wGmN*VI$q%>N0fcwB_+|c$gEASixVJLij7A%dIiXHq>P;t#sl#g!n{zsi&;+Rs_ zrR)O1c!qU-BU`hDti-BmmJ3k~Rs+wY?>PItb4F>?)an`+u-@)cFcKm}8I zosOAyTUutPz_JD=sw#Fq{|aDHCc4<<`ytvSU%iCY(9(5xN zxY(R%?kod{66Z`;13d}lw^vlfUx1jNCaT{=fNDqr5sg3HQ5Je2-}J@wOPGxnn$bAD zotsh}(XK2}@2Y<6J;Xd+{Hhn4_sZ*Ej%kvbftEl=2EEc?!%A#DyJkS6!^<6Vtg*o) zDnFS%)u%vkcE?zvVxi0!h5D&Izb6!nk($3M&On%@OEhuqsh;IM)5HIz%I_Ith<45M6{Pj{{5%KF9 z-n|2&QmtM*YGBVXpLEExMl@;%pm8ebuC}goE4&bMSUqIRn2QzQ`k=qg&uBA2izf<} zzc;2T11ea$+j4wXb^JBj%W03>GKvkN$rQ-6L%gVD*UZ)Yx7JhcFLCPGZBx#=zFF%6 z9VJ`FZu1}MD-3a3dkZseD_H?42JE6{+ zj_18xmt2<6(GBf?_2`$E?wpF;Pyg9Wi`c5H&n5Tlr+o7+MY_t>CY9DjgiI}}!=blB zpQ@E)>R^~)DfRB73LJ$amLqprwhZRJd^lV7_~$PZ!2R{^zxkx4m)%GkUqZST=PdC4 zV~fGJSaa~pQ02c0m4!VtYu`H_{k)9tdE@1D5pY8_!TG2E!1QZONbRz_>d)CH;}84& z{`~ngJo=LI<SJ+y~!)`*Mffna;Mx{R%6rW*pw9)MS@!nW@3jFMFLNTEA{+h123^( z&A2mv>h-)-F}!<*Q_;Xx{|W!?zhfPcq{#%9pSE^?cccGOLX~ji8Smzo-N%phWRNsW zm)qi5Q&ngG6e*I7OVxtksrKH?1i_EEH&Aqaq|^7*TRUbC`ApBhjK2?3)%aI{e5^L~ zDI|E}@vWa7m%~1(e(Ifx;hC)nOkU8*OMe}DQ3MXBqg}tb6>{TYRKez3`)^mDUhQlt zGsyh(w|3X$*YijECy)Or!zlZ-*6HpPA8vF{cz!!SNawDN5cEEN@OO%I9`Qu7{NJzf zP`w{Up*qdH7tPa;NlBdBKX>w*xo=EFeJXvdwx99bwOlQAL-wlkNrKN=f@|g`aQr*m z6r>C}@uZM*;w9bx#Chh$;)4IYHBj-t``U~_+DnEi-L)J}54Ot@NI%-;{J z6dg8Z{8`ARv6`W|D_U~G4a9N_U4WZH$1stF5LX9Be;rpnEB@`6^HGy+=38hB)9weF9l^cu}IzI1%yd~4JAK>Pkun_5FQ$Sw%iFl?ww5q~#; zu1&#N$nyFMc9P-%v`8$wx5Zuzi$)Gx~lwZIynd zw0{)Wmx4mvy3?`~>_3vPNtM#qtJJd!<=K{=DjCX*#NldUk5T#CT8 zoJlT4K(S}>D`yGXWC;gni56yw_hpgUWvSCFG<&v;a<-gJwnA|B|GBYU&ek~1#<1sT zDd%Y0KJ&lX;eU&QWseE}GdtA$&#}k;}hxg7jmE4|9$N7Up()Bfr4j$$fLsr06}o+6A3S3 zC>h1=Cy3;D9#ViTV6;_?rm)G9M~Ak`@eI_pWUl`K1x0T**iW`sPv@hZrb-O{JN8g| zxU)LhQ9JjT+^5EE*je|gQa@Y#)>LQx>soB(|A2yT8m&7#K9JLS?^+#($sl2O({hLV zYx3yO-TeO}D*vw#6=nPX42z4H_$+%5Ig|?Nrx_I`MnU+fFA=CN-y#e7* zEKB>fy6RU2amflB$~T*?Uvn)?zHH05v#5LZqV3sh!^Hb$)vgw0hSYCrte=|S-#I=r z^;YgTzZ1Q&nx`|?c>$;S~C+?S8U4j-m|6u@2ji@1^&oN3a&SvU>+m#&T=)I3`}p)cb-$6a{?oDT&(t;K$RFm}tb_ zocK6olT^KyuJ(Ot%Gkxx`lH{o>#qeeBzfxBFEaI{*^_U|J>B5PD*nr($yWKk{yNWI zyr(Lw`0G+q0KabFTEqaVe$fcISH%R!rK7e=m=+7iO9S85i@+ZK5)&!Gwba`edq;?E z3Zs2KbGf&uA5-5h4n7qw4OSvyAO+&(Bk&Sht)be-Ea08G$})!?RFQbpJ&1{t<2`bb z0Qye&J%TmXQ~f0k-`fwMhjHd+jp{yL%n;;?wmtO)9|d<4%>F zy5?RPTNf##uBv9@h~BU5j=BNGHZA$z&_6GZkBS@YTymFC0D9^m# zA7aJmV(&;UtBi~inb?YnLy8iso=-3BOWwDN)%{gDzk-PFT*y}m4_GnJXyg~Pf^_;1 z)+;RuFBu7hQNEnkE$xP=i*&!1*17-%@NBI-mHf!5d`3yql$8?tMv7 zr0snFTJqh(I;F@zIBdzH!d*+^cUltZ4rAz7R86;0$o{>p_e|wq)TAEnO(~$k#<`M) z_~_4lG=i+pIK35WMMSv{sSK4I&o9>Yg1QFUA1Mujp#6+l{u;MA#V_((9wGxEZm%UY zU}v}8kIw-b0sz+^Mdiw-L%tjxT&2g%m!nTBQs32YowLUfanS9uPfBYEbNk~&tYYLviv zqS7h2)Ji%&H26F`5^`H^QJbG~SdD|+%}P_oQJXlfICX$e6y$?)VWL&fObx_+9Mw@~ zy72CM(EO}Cj@-dsE)AKBOahG%jC~nUVA@!PD`le(UCP^1LKta?YD+B2+u6u z{(O8$PHHj@!nnAOa+n4k#E$RX@NFM1X`(4bCWy(bupgFR_)*f41F(=K6qpeSq7^-x z&qKEt(&RW^Sv$a|Qqad>Y06Z|+YW?^IW&Ai3yMbr!e|T(t{X1P<4uXj*Ww0+b|}@phDLAz57U1W`*Id*nrKkLYgl$(zA! zX)J8O#MEZ=~!zkcaM~Z5iyr6(J>VaWN;;Mdv@EQ+7V!pYe3;V_jHs7Q< zR_Wczs4~@DX$JA62@nvw*WQ(5C>ZgP2jPd4~boeiAkA@4;UK6t0A5)YYSq5N{`0X54i7+Wpv;Sq+u zsI}}8x4LDNr#I6CD%5YHj!1qUl_}V7>H_}&D47o-K&qQ*MB|z>ZqY>f=$m^^HHv7NO$WS6edcypQPXrmF_#X^iL&{jRS$iq)!m-4T-N_)y0E zy?4r@FXS4>&6fTHWY#{IF%m`frL=pB-Sb;s$~yp!{xK%%xmjw{h|ByX-LaoHtoZN7 zmzJLf;%oUF{@&=d1oIi9tFX8JmDEq`%uz9tq!pySQ`lL-M546ZZ;M9iH}%VH?$m9%(+kXGi; z5l2&St1Wyaryz8yMhtlW23&3 zXWSPNXN1d0Je5u>+WAUYH*TXkjiQDX}0jyrPA-lwyUr2Rde@i zPu}Wk_Xuw1c~|6u1dxx!*8{m+6Q2Y=8kGghpdr#|NYF_r1P>D>nvqNWX;2B|S0w`` zIPfH?Z!}Ur7wlN)w=9tO!pTv#*5XV4bu0a=ty_r;IUwN)brT2O7}>b|2@|tL1C>k= z3lTao?%%TgKra`3xCmEp@UK$>^!9_Ol+s%D0UGoL0LMVAuz~cyZzDu5AAzNfCPH85 zDyLG~65rX|JLs8Q13Bv3w#KB^xWqrv)d|m`XG8&%1TbVi`SlWv1$85ooG*<`w)zcL z7X>hs>GyRq+l2rH2hg@V=61GvPhP4;ko~QV6ecS=Je%76P9rA2RGwcM_q&~QY7`wt zHGutiya*r-r2i8JZ2mhyfzt!Q3`xM8Rl>qa5`Gi_J4B{gfS3tj1PRO7d7Zy6N@gbu3fgz{DMr^^@@aNp{AVTqOX+kB3PR3K%BSJ}!mDo`R+4(>h%InNa{<5lFq4 zt9qnada9klqPBRPndZKc`Wr635`$9o*`)>R$P39D732*h*zy(#ZCl=@ zl} z5lK1HB#1OF^IYU2J)WvS8V#7;^M?>C%}yWFBMCOqZ*~b*WDDfcdu!h`b3yBa|p5-bSRbvmNOJor6kssf|KrW zs91jJtocEimT+7}odi-WQ1Z&Rad_9}8OuclGqO!k=AilQ@ zGB~I>=Av2eG)I;ICMMTvp>n?(R&?9eP}C=T*cu(LWyI}x|9qo09Fnyg&~(|RI;SDE zE>153YN@nu%ZP*0&s*1XJpRlPd<9v6I8CC#0pfA7Vpz*B;+dtrkNL#`S!5M6F1f3} z_IpvX9=2^tuzt6QP zZWj1f*Kg(GVV=ye|?ZD*xvDahjD2O8O$W--) z0_Szzc4dj)eK6sT@*0VRt0BOUSbnCWUHKGL580|}Mzq3Ic8B^uH)@ZkZr@Ax4?L?> zK!sB^*!Z~&9KNf%(-k*LvcDXq_2X9)ZE_;kD2kL(kb50f9S=3LD1MEl%8LIB1%#Rcnb0-`7RDAkgI9yn$MBjbx zfwA5gI@Bwyf`J4qlIMG$s%+=zTbO&m!lWI-R`v5+sB_dvdS3hxIJTI3V1#ENW{qkn zD5Uo3SIB?R2qv6f)M}Xl%Nt`0wv=;iyw=H(RBi529anlkhoDSl7qBuI$XT+PJo53) zBRIZ+@k!Xq8Bz2;=DLJ=v{8k%WN(McbFYp6d=U^PTsjPEhVTj$a*$i4_AcQNR(e!I zZN2Jrt?PG!7>PWlH(r^aq9Kf{OpHrMTFOv9vtos)C)E%q6Wa}*NaGu>HjMIfK{R&S zT!h9d3qWl)qLYF*Txbjy?hi^)VTKH8*s23fn8($@+6|WV3vVuT0s>(Q_*#7n%WOA? z5~Z5wc8!qvDdxz2r4#U{lLrA)BT-?U9&F_3?sEyvBJ=SV8&pHP#*I(KK#_&y_y7M4 zk}wolbP$r<&h>J@>>IP*qeehX(xm+L?6Z)%zwak|FilEr!v2fKJb&%wcRe`F-K0Fl z&ra+SkZG>IU^5UX%A4WPhQogAfvBfiZeuM>YlAJ}AJ5h(M> z0}09=ea(=bFBv{8Lpsnjx8r@^LRVYSkzqgIpurQts# z>c<20+|LT%t9=&H?>Jc+c2lMB*?zX@g)jH=ckJJy1RAugE22GXvuDX|Kc5Z1U=e7L z-5}haFoP+98R3#UIjY+IKWY7$YPN5*YzB*r+QCV7a|6|Pne8~kEQKY~TE#$RZlVgI zU~=~AgJ!GdR{9iWGkdCKb|nRZoGYq@)9Ks= zV@6~EWO6CprF!%~00 zi_LFNmCM{Fe$IL%*;#y59jbJ9?5VKWhpZE!%>c+tm6E&SV<2|)C)>Tsul+6Gibu_M z+d`+qK0cjT6`k|%vlJ)J{ex*K;TmFZH9C3pHd1zJtF?Rxf`N!!7=OUdyVyqW2NWNq zG5>zf)>C2Kn3jK21UJ=9d%d4zU&N_D*(?xVdP7&&Q*BS~rNDMl!7C+s}*UhcuzoI1$O2~QEqUN3>v{HlraM-{Bc?E~C5Z+>pBI%0pttVh|v#Mxh zG!pwoF=cj0a z`ryiPi~Ik<)LXbU^*`X>=PVgHYBY=<=_n<2qnn9HtD_`D97+p1x^Ys{4gqN;q{JBA z3Q7w)KvWR@47+*ueV*s~UB5qJ=h}6y_xnEg{d(OTRrj*OLWiWP9TUp{zO;Elsg#VkiDG3^%<3jqwj3|78H~G9`3)sJO=y1 zGKFpBLIyYnzF<6KYqw2Jp%uBe%TyaqHWa9i0>G+Mw^Xu+l8kwfv?7{9<3`ygVAZ59>EYwW+VfE6|$ z9@a5`LSHn6kfR-mB_A)Pa1^N+qIhv@@@zgG*(0%zyHAlo?2O}_163R7b+V=;9R}BY zlELjWVk^mS{9ZRuU^4n7N{~{tc;w32n8jM<)P(LS&a~0c2Ak?y4#Nfkxm{a17+jP! zP(%Co8x%4qVQx}*PNIu*?PENL^7LaaX2I1mO3~&5SXmA74-#t6c-5RT67uV#YBHaI zL#jXgzpoa}ST;Ze+I1*Y$AMc~YW5XB^2=T*_nd9NLzfS)oYRffB!xvTT?Q@RR$2eJ z5CPCXU?Wk)L{qb>K1Mmnid-#(07-Xq33u&|%9ec$(%;)iMj5a$cqJ0|b#tQWYyr=c zY`hkg2Z^Ja4i_?MNiYGFT#CWE3QGQnma~O}DSs`k`BA+$f8x;stJHutH}MqtBdQ$u z#hpp5>Nw;1)%efcCS#9uIz30p#gY1$Lw>?;G z-;V9c6VWb%9WHRhtz5r#CkZP$KNXU4U%WLB)V)+`MPBNRlOzOx#0{=#L#vtl2Nz%p z_;UN4G0oQ}Gft7cghXD}qLeq}h{tPQYFWYoX*vPsNV3c-B*6ohL#4b7lHinWq7%pP zQLl}uINmoR>Gpm`t0mLhUjlk_|8P<-$3EpQduH$-Bgc@7+YfrA%g{+`P)Z$}C;%xI zLsA&YKq3Ju35=D-_?}X-e<=f?yW9FwLe(0#mSdiqiXj5d`AwNQJI@1$>^Wgd?^c9= z0EsI35M)9I;L`+A-wc&^m(G?cLAXOdi3$Mm`UDuaer~Fx;n3UL+{g@4XoKiUg)d{`g%qIF`^1}I7wF-@`>%uFX^-|H6zfAU*SO><3^}pM z8H9c!M820ju4E*O#{{^~k)OJ#cCmMGSXMh#L{U`kTWrgS_%}uy5Jhw^T z($~b63r{j2t!B@GX8OgPe?-Bxnq^N^BG2^}>*A zd!$GZU2-m?Hnez88ya26%*tBQF$jKB-D^bF<#PdcbpBQ9+B~6KISldf-#!GO9=Kh9}{) zX<%7WB)7-7qmy36ETBbzd;Fl7^eFj0FN}#Dhwq@O&T+*OgRaI}z#a7QkWfRAY~)Cy zA6ecqmH0KQ|BourE9U<@q`SL#BMG7l$@L*V$viGeO{|-qg7bNDdyWzjZCHqycQqnt zAT7XeX=d@N1%g7EPY>jX73>16ZQhtFMHVRvhn%H7%%6uF*`Kn@Wm{z2b}qA-S}* zERpSvc`Go@> zpDA14d$0Y;L+454$HU}YWh_zH-FS>Y13(C{5=~iYE%q0F6>oGbPhauU8t*bsgkBU`(dsLDD5%j-N zy|Ir8b8%4*^U=@FT`(GSI0F+s@E;(nzyI)30Jm_l+-vU1%W!!cQkXfOf%qw*%-O-{ z#9cDHaa5GAMI@DT^4gCX>Bx!DB;o@);78gv+ z-~p%s+ttB1{p?N3zaF9jIYynvfs7=6n1z}Kg6u4;UR!1ldx@5qBuGymVQKDdaS)w;7Br8)@#b}XtLk;3{@qF2O3f&nrBh+zr?|q5qQ2Qw9`6nc9Alh7PK1_ z_g*w8H8B1o;bet2){Wp&D+@tVR8!k{hplYT4c9{3rHo`@@ULo-1oAaBz>Q=H7cLW@~^<5Hnz8qkR;XCps1nEmG-_r5`BS2P;4 z9KSF}*k;Pm63^mDI7Wu5i4JKAiHVJ&t>2*CVOY%s`JU}Mci~InyPh+OgKi$e=aYiY zFOTM09(P1iz(Ub{iyu%W+OZmfDux160w4xx*st^yO)T7^?ebmz?6hzBF+c5I!0^6| z(*|Vr6NF&#JSlxVX~8ABewLe-eCA8n9%*ybFNhAib68Cz#9PNUwOh5b_<9+p&Vmw? z7P;BZa!bp8k@X(VfnxvkQ+$I{g|S$N!aTG+!Ehlv260BlF-LwD^*ZG(|*kL&cPk0}lEW z83^v)D*O);c=ZPn?~?rQTh+5d35RiFlA^bFY{tW+tF0a>;uO$|0{;^UU@7IkKiR() zbv}uDt|wgbZTR|#!$eP>EjqQPHxkaa;IQ1uo9?_EFrOd(gc|c-^Js2<{tX>nZZsCT zfTX$Vzp@d2M@>=;N_rDaQ?AbWi8xd)X60WXrf9)=NiT5V1ovi=Uwv$TqsrkrUx?32 z8Alv|V}f0!fRkz-$7&_o!pjpUf=SOJ8(vNeG8SXcFqtPz>6p*J0nCgB#ptULuy%A^ zH7l~ApE>Vg3VcWbwe3vLZh0)ZopzuPWTs1Ocn8BF~@6c1^xQ z(Bi+rbqK7v2jga`EeuJod*n*34WW)Pb7Qo~nn!qSNCDdmkgGq{tZ6(|+Bq9&Xx(dK zf@;k>I$nU>934{=_dmso;H7Y^fX$(kI=D-V0*VmMZz`OOla29ZkfQ*^O*K!PkhfIU zXekP*zMnAvi!W_Ue)qM3n;d|}!)~-mXaKk7X#D0jz}Ruu?%DcG9sUdZ&3RTNSZRVB z4YX;jY9@JgU}cXPa$lS)J+Z?l!~zxHk_Po!x8e@C+zAOKt2brQHexSszK8<~UD|uX zIlbB-?}@^oIl9x9V^uzb?fm@D5Y%fDwjzj)Qtyg{d!pv=_N1gg8VP{?)}$=dj3f)) z)wPi!x9)hS6QwZzmhyZqwcmJplYx}jM{*2x}X~!h-W~HYWvF1X`=_qil@2^ z&>$!F&P+eru5DE&3!~ukxTCn?=Zkx#8?fUlLdnkn zI2P0b1U})R{45ngI{T>pV6&DnpA0pT0}(7nt3m$JS>&SKK(=-QMB)C`4XG2y4Ie|) zRPn=X7->8Zx(q9jAs-BOji~9-+*6NpWNZy)upmj-;l$s{=9e?PX##w5oD#}MEU-W{ zm)I{^u|HbuPz>^#Xf~70i6M1~03)kqP&IO~>-6FDTxT7 z*m+7#X|^?guk3XUkQ+PUk_`2lee^*~xcl>na$IF?%lMR0nefl@`cjaS34P$nzstA_ zHNe=j&}XRqGeOptobBapVgH^RDqlSq=dT$))d;Zl;Zj^9bD?+Vy^XK; zLa1|?J1GY+qTVEiJ?zt&{o|MWRV71+0b;1yY5N#sm6M+_e5)-wR^-P&?4IV{LOIfP zEP$Y%4B>-tDJx1PJ5jfYAGWNUc6Jl_0fXdMTvgcdI=MDmhc7>9;Jc$RsYiJrN1L0r zvtNRVPpf7);z1>&XB;D)EeO750k!8VN5|Tq#ZMJJ@X~I;L-K^uV6%`XuFu!x6m(cm zkK!lsbO535E&d^P?=pbcZ52nuu&l%1Z_mF;l#YA*G(B`!Y`wQK)!7k%QwE28-Yv-Z zJkO*)YtI)I59d3RMCjqZQl$*-S^<7f`<4=xfKM{Gzfz0Ad>IuGISSWR4YR$i;T6?` zVz`;W^OoiO8~$uZkRKKbIkoVHzgwxzWQyUyHjSO;;q`|RPlRKh{k*oeF^^1K>@~Xg zq~V44EK;KV)^x_g`b(?$4Bc0 z-miD&$!@#?JV^k>`k0rtm(xa|5A1 zI#7m%<;8C3>vbvVm)KFLwO;22&63vf)VX+bF*k{yFeThWCd zEdpjgp3Y3;fsTJPLBG@f0FxZ%S8q|^|91yZ`uA4oy+CIvJQKe7z}&4>>f{H!03f6; zfJc0h64E-f{7@=Se&wC5!wE0a@U2_>c~ADuE@TQ)0G%021mTn8!)PtCjM_n;dNKjH z@BwAq;qq%pS4QCOKd}9gCr?eZPyTH&^_fFw^tToEQBorY8$_ARYN{TBru)t zrt*XQVk{cwbSO`jl0!XE_?CNByse$T4SpzW1fXb#IUXzn;vkk#@Ps5YrzxEI{Ot>3 ziNV*eZd|rLb|4CFjG-P^Yl-2LGAF^Uwu60t=w1kCK^>FBFI-su) z;8gsON(iDj>VGZmHF0c${>=Yc+HcCe3|7|>{C>t&J72$j2jq}Q*;oHw7!V}gwHTN? zUKXlCY6|pfz#J+xL)y*9y#Y@WF})(?zOXBN_XfJXyo`{Xs8;zgczqI;#36d@PaP6V{XRb$d^GTYCUtn8RL2f->s%Lg{_B-Ux&l3?=dRB zPVE0T217|_ApGN*jWU zoW*Uq94nzyFRESCNg04L2e!09B1a#;E#$DnWpBI}wI z{@&MXhyz(;y=!e#Djuca#a+x`oLU2!nuo=ak-TCNT*TYV{2L{{IqY37r$gGV0<@-y zw8C%Nw#j*gAe3kawEz-VgOO#ftAMH`4azTS`Qludt4fA+=bIS4f%6HAC6Yr7*)9v1 zl{cB?GM+?+a3Ff;N(H?A87SwiwB}EiTbg^^FbuWn&iy@3<{dt@iDp%GD4=gHoOgv_ zDggVZF#fnv^fGI}RSFBK5-Lv~k`}aH3gqPv1taHw(A%mQ5+{V~!EbLq4RB0HXy36? z>v6D|`pP70-q%_B`w~oS{FIdNIql81o`Qeu)a+T_HUTGnwTBUR`=vnK(ylvTx_qz( z+jnW(kxDgqeL8?R#6CDRRU@3J=mA*8_9kJ~vh~Ba_t&tc{xaGxOgjCuOX3I#_VmH^ z8wID3UurBwu}aZ8%$EJl>GBxm*Sjt74-ta%Z7s*2n%5XOubN#;UOHNFM{ApjZa;18 zNQp9qO2%v+os9B_{C?lDRO5r=f5 z@F+W-O4!W5P&JS$WIiq~15FfP&<90h$l0-R2u^=|Vgi+Het?B=1kqB3{FAtNNjITo z#A_p8X4A`7g(P!3FcKxh8J7OkNN)byN>UlJwz>o^&+P`h`-dz$oy0)}QBICpX11%n zC?5p?`R4gmMK}hPd-hY%qI5GaKT+piY|>ZJT^YZ=!RJqOAR6s=4O)L=9x%TV1tdoPs7TA9Vg8Z{MS)J*vK9VD0~)W%Y*V4tBpwGCS~HG_5=+teJWS8z+s*e zGI!tnHqKV>;e|a*2!_m$)1ReEs8%Pu)1Q>Rp`zIv3|EmmST@Dj@*fI$vInoR$!(4I z3W$c8Yf)+JI&pK)A0yhuay9t*5#{d}0hwq%+Q$UfcrAM(wo5LYa-9`?O}uMl zykUCHtIDC0TmND~H5WAL$dpT0SyceTOd)4|ctNjao#(Coxl$-JCMNgX7fR|&p`^B) z8;1NOfZ7)&#AVG$`o{se5GkkvSMTw)QSoy@e$HNZ4m6+-FJVLHHVVcTdp{aUo1GUZ@QT~gh7P*W>9Uin9zoEJ>v|$d$hNd;flf?9{ zwwT_2VfxKIcI)9Lnd{Ia{GcX<`m*9kHRm>l_kWo$gAImC({u=MQTC}xZ#ZJSYf`xP z4st|CzW^aIMhkeq=D9d&Ur{T#GW! z_D6!CaS(}9h@5D6r(!H5>O{3qRkD18?wq^nJCmI9&(@3&Z*EcnPQ!nf<}QA3VOlfb zYo%TaUtZfG%Vx7(pFW4)+t^XWGvWs3exzqUk@1KIJ^D^NH}-BJ$vt0T!yj3XUw-Ex zbWph=qWMq^b6FPk*(1@ba*U_%`>8RxxE>*yw-*5+*{GK9axME2 z5=^if&O7ZI{Q1V^{wchvl=v0uUl4gn;us zXMSMOn|AJZ8((w%+03B$k0PnOV{xrPJfwZ4VnmXgzi?ic> zM~`R3JSw)78KrCmC4CG^s{fJqY5CltB+Ib0kj{+M=RR`Z1BE0hT=^mie~zThz^Kad zCbgZ3Jp?$9i`>)g91rEd{3Qmn&4H6k!PIN(^miv+1jerbUWz}U^?)F;N z_MS@wuRVE}HDjHwY>=gEQ*a)kEuR+B5ph{;g2&^F7eD|Nm;eyu@AvL%*T|)Z3J35P zy)+qRkwZV_9F?zo0UG@q;U+s6k0Y)QvFQ8J6nH_T(YxgO(d3#j3L2Rm;&M(JkrKA^ zznv%HM>2c)X&iGSS`0=ZUj5~sttWS}0&NYhWLw#!m5~b347SYW@ac)POTLn#(CdBx zQlO6w0!$B?zu{4u>pN03@~%jeLh(VDA>E7>P!K%c*BNW~vn1gT8_6ej`d&$qa+kzW z^68rdl6fq~(xU_(oF+*_4%W%bFiS2u%i-||Est~$JhG?{3?xHP3|YKo`SN(F3$2nZ z!9mcVTZ*pg!N_$Ig0g3 zaFQU)-EnGY(1Qed+6P|7R`%##-c>o>8H=yG1Vhk5cs#4cf(;fgN%P{ZgXYSuVoMw& zh2$xO-?2HPv3P?vWN~ba6&ZXIOHUv}-XvegO!Am6`CJ$*cvGlV=23HW7jt41IfsWh z;!6f_Hw}=tzE6M_b@C)Ee6jSF(-Oj_0fC64v$1vOqd?t-8oLv6khv^Dw0zEy=worW zmGv;arN|&bN$FqNHr*yXI=7PCU2U04i?N_Kwa$GNArNOL)KrCF$+h=V4ml@2=jTnx zxSg{~LlB@CDpay9NM9*UhVvE|6p+VPRBoL4-~Cs&%#}Ecj2^Eq^5BsryZ5BZ41ay~M1Wz=?>y zbDFqyI@8cSF{F8!^Mo4Ozu&VY4Mj#%+<*5SwJOSXqXe47f_O?@JSQ@Q?aRPM1TE8f zRhpUjhC`9+-Nmhc3=Neo!al*}9;`M;Q4KaYTil=B*05|nZU~-;r7PkQYE08mhT_kV z%B(Vp%ul8-;KENN|akp!FNa6Z}@zLcJ@e|Nx2s);itre>UT+68{T|e3hEu{dJrV^i&XiyFXwzL zXwHJ3&JOWr=f&b8gcm$c)b1QRm@K+Cm#gpng6`64_aAYX5<^@}L}1^q!@5y4Gx)Il z!tI^**x{xseOywEirc%a+qu~{%+dYVB>EHW9Hoco#o6~F1=w1VRK7Y=)$cwT5R5i* zK1j89!&ct;4b8iJBRBefb5?hZ!NVAoNcOpIkHY@d->}kbVMM9@fZ79ZY?tS)tEIb= zf7%{&c==v8?dG}PJ1_CLQ{tfitWo8s+J}8p59_!3`Sf}yWhgN`gz10jEj~EDxhhDl zKS~+=*jzQE_ITb7=8@hl6C~H_)x0VK6Ss$bsqHT{vem~tdQ}FdFNjJ0vi}7<)LZS1 z23oCNsAd0VLb=&x#obiujv+SS(CeK5mIfm&??T#Q8B`>aOHPw|A=!udP;F#t)a$hWiNGloTNhP3veJ zXyTo?!G!XJR-QC|7$x>N|D0RYpTVA8%gcE56L+x}X{}$a=;HpPa`6gc^ikzD!)yif zDbMQKA;pK?-6yp$(V+*G(`rLH6(je~`Brd`=Uj4Q+mQr?iymXEZ%^w^3`S&63tP>N z=e3NU4$|KKB;?z#KYmeiDpY^;6S1m%DCEjTM#WZwh7H`$Oo z6k)DT3zU3>CJe3_Ltf_a>eGQK!x6FZ(=hRF9CCnyH5(&*SeNYkJ0-e2m(DTqQB%>z&za^`-gqBkn7e3_>qfmd@oxI=lGkI2Pu(`TfziT90S-3H@@a%9s6?p? zpa7ZgYu3EP&?&Ku@|nD8c!1)>Tn}c#H5-L@FK}3yQ-E@{0XXW4s^rsEbT8k1{gQKI zLBG@rRT7&*S0iyC)+Et5>vp>&_;>m7JqOf!K2o9WsB#3~lTXWR9`s|LwFgFPLmvPX z`2a}GubLD^D;hYtxhQ{r*d&NYJY7L3TtBbIazoM)0z38oGt;@>x$KQDzB+|clJAlP zZdOyF_dc(@#E$VgtOQ9p2vQ**9oAgYDu>q#F1*tksV9hB#{Dt@FXfJXkDwdU5otF# zJ;>nQXy#d4yQ32;U8o`}Y7p-~CR2lvX|eGHk5fY%M#7WG%INnzYkR?_vX9s+JJ~RYv40htnB3V(+y@eq%=W1uz6B*(_38XNtSH061w$I{{4{w9^C_smRAjy z1~;U(++IbhQNXS*y*G^~eF8R5AnyKc;r0B>MAMGKK19vF0sUsfgHsCRRr2hjVaM|p z<6D7i(wjKoc9?H)j+vqNm7SIruhtp;iqn1fR7CjHc8eOJ6=P$$c5m!EnJpX59<6W1 zv>r7lcg%_KBw59HP|l2u#SJ`qu1Adq8SoM5O(C@Fy>Ck49bvNiNs+I&pPt@4qbgFi zS7Xoy!B9USn_95UuKC{+FHf@?S;|ir4PRIBD{TQ?Vee-VJW7|~Q#R@Q(heS2Xz|7W zPJV=)+=m6mUNb5k7_iDerOD!z+MA158$%VL{)JzVO)+@FYU|mJ=xx0$jmz)3j{f>s8QgKtgmM#L+{t^?f57Ye`fK~z^t91_=47a9q9bbIpfC9@f9ip|EC{#} z=pK}q=H-h-2#0n&j?0_t|K)0A3b{H73RtnZ8b!$ePog5FC&1~AL$S5j4UG+00RcZw zguyYCcvE+SxVV!DLW$qXPtKdys1adxR50ZHrASKTrSq5lkh)e_*%et4k(KpT*<;6K z&7FGQHi@@b@q6iev$+~u&t64xY(oW50HPxf%Ww?^lV|F(N+1zVQMzWJ%&3lm6(P@D%}~ zV%9=pXP}kV#tk1^Md9eCcGD!dX$JP7TX@h7^FB^|8w_DM=-p#& z*Yo<*@L>am7$W-iAG*W^CK_CfdmBV3_6V{-@_Bt%f4h-BuJ?A0GTc~1lDX`_Kt`>0 zjdMi4N>r{=Msh0-$qkcA4kiWP!x(aQ{O7|{UGyZ$wJvV%0Mk;snrz|T$C{_>n;S2m zEZU5}U88DjD?ntgm#joG{ENkAGlp#3Bmr$n)(FVSc)MA_l|k~%u}V3zrJV2WGcVVA zKGxQLuVr{H1ebw@$i(BaAhO4zYF`#Rkvz8RZk$zVI9E9Ht?G>Ust>KSwz!P1OgtkA^XZPC%T*dZfv zfia)-+h@7t$~cM|(11RjOoW{bsHTRDKrG)Y@Ta(BR%Kp4GB5l9@~yTLWq!-KcITow z=OdItvkIe^I(+a1W*k%A6uuntzU|`L?Nt##MUvUXKA$nvjQ^@ah(MJb+knu6tc<#GmiuX?!Cl0yD) zj>7rm#wjBMncuWdMyky-zb;u62Y$MmY(6vocpwCA>T#w_$C9T~k(jnq>#w_sdLXwS`tb-x=oJ6LmB-(2 zSona;#}6`OGqqP6INpU<+?h(+oDP!-du+0^`(x1f1;}pdqSL#2t}2~Ef&Vmk(R3`7 z`^1NZFtuL?9}f;5>kDuT(Wy|5ZS@Va$^rm`dR~1;eog+&_lt)!NgR#|TpLLZ;%^@D zR&idjv=fHG(jn6pA7eW=ZgT$g>wt1xfZ(T-P^$Y)r%ljS*GsYe-4wID9LFTXj@e2% zd>Yz!*7GZiF7Oo`l+UB+yKI?pD&#*<^RAZjA_2lhfwiAR?+EW{yYM|ls0R`U)z!rP z=pjF*7XH~smCv}Cf+7CqYo`}gPz>z# zgUlbY64gQ})@?&DIaaCU(%>UQ&HcP`UH)EnSyza`h|b3kB={0}Jr&4O`7|OVpqmii zy2a6v@)|OG*anvh6u*1!kK5KVa*CTZSQl3^c`2Ku;h*UJw~t5dCb}-rg6l@-o;xf# zM)r9?r+fBZK%yzx#-^4~GHGwEl^Z*KKgBs3q^C9W0ua~YTNrp#t-`NM@~5PI$xDLBP77?DRT-x0X*{aMIgegwZe7}${c^oGgec9e>Fq>RcGNrbZc-* zt-oRrdv_?$1-9*;T!1Vy;sm0t1c{hT0A)A@6SsG@dn!KQL<2vgBl4m&5~}4RfBB}B=^t24tHk0XRObE7ayyr*(~m%idwN1z2sNFzg^e(ZF1gCmXVBVVF2^q zJI;sQ2CD7JTu#Y_-`)*tA>Dl>5ZK&Uhr@|gp4Oi8rWxF?f2nSo>Veh{FPvY;O$agP zhF`^nWnEKg;sF^Dt8p;#a%nb~E;?u1MsZV!mNX(OCmlr{JF`6?z#oH!AJH1PvKC2| zi&lai`{|6J5Q0pnfSeCsf%F}7(AeA{!%oAVGg;PCUBqh2tGL1N=j^JMvJ1Uw?NV-E z6ikp%CzpVua^v%pR3-_aU}EAYr9UIW-Luv`u5A|n^aFlrf4ak-A>o+C?nZ4=ukK{m zMM;gy0Q7(-z*(hCy}x7o<-e;n-){1GFKEgy1nMBHqm!ulA7^IA zsN{$Z(H2XT%@<;8NJI+1^r>o@*NhR_oon!tslC*RFDv&hJDRFv-}HC5K(JW$dv8dn zppKHNmU5OcBR2yB?|XD*I7cN@>Dc$N7rz!$Z-yCJ3hDbI|BS*jlnL9e)Z*dPCkEC1 zSph=w-kEcw5N`30ESY($%_EoV`1GHD{H6bQ=V$5gc|)D-n_>4bTYzmSZaNRTR=#Z# z@w349&V2FWgJbU`bTQ`mk*)I^a?%8_x6H`?=D~sYt%QvM;S9}_lPoC_B0k?K_EXBB zL{*DMT_A7UxyZ$ZP2~sc^?V(yQ&&Ge8zbdSpJU$NhYtHf(BVo(qYiO0U(!z-H|W}b zxDs79+IPjR@vwxC{>nKC!nb?+2;VbY=FpRib{{@K@0;6#$R9t(446@Gb3=iK5~Z@Q z_R+K*d7(?ygs=ZiUwE%rhFLy1Rq^5H(UiMBT;U3Ikvk&^iSp~Qxu*i>R_Dl-ACGJl zes-z3A0#}wXOkVGgyncZhIGl=Mcg>j(vy%dWc9NC%4(60xSj_V57v{f@a6*=dSu=s zxW|QRopYK>WUvuD-I0$2XOZ$lk!Qn&t=$ed4Ti)7(k~;l12AOs@(3yiPM32@WKH%; zsF0x2toj{(|2ihNSev)~Mq)2nww4(1cuU5Mac+4_Zb8T5x{eucEZkt=G72m1sqbML z;m8{xd8CA*&>=ezc{y5G5R1j!(&BwhmpFOxia zd?t92)5r|f`{sOjB&`0ODL#b<9tDbE(thb>-geGRnD;$bl12#Uo$yucA3$h)rAD~R z76t(A;Th|$YQduha-XAw+GB3@9w>?vE|t1OAI`|W?JMU^fh*CS3x>IR2#V-iJkf1p zW6Q2#isDN3fg(#eO&r-a&yX-71B+t!iX!%n7_QsE26N@sLiD+!fzcAu7AbG=9S@Tx zY^G0s7CKDlR}%uu+;q@S*7;}MxQ%+WIva`E#KlT_N_Iq zzfWn#O6eV+vzNnPT3 z4%t}hSQlJ|mOmAp2nFeCzu)=JE0yz_mJ67QKe}EXo*60AlTl&eQKuE_dbsQcreZKt za_+Y5hFr|5unXoAa1JXrEmyKaRXj$Jd4^I95%mAjE;hfM+|}k)M}#8V;BvDiz)s~W z6_H^N$tX0rLd^W}JrN}|V5KMq8B%|yj%VheYnR10bQUG@Plp?N~k2JGo@ z0Gvv6J&+gGp#b7^h#~!gY-vO~RJ$$W!cMBjNhwudKnSn@@#=Bk7`D#wO_5Z38}Sgs%Bs8yA94T@JI<--FZBsBPh3Rg2&w;0kW*A2S8uxnXau=9^$MC zlPygNC`QEAM2>SUP+(qIY}c^06|>Cuc#Op^LUXoO8QY*tYDkM~$jEAN;H;aUR}`u7 zR;1OjGyl)wwEXt+xU&Q`tWZG#+-(-=Wag`3dpwrSxHc=ENkz9pAX*sn`?Pq>^J`tg zHd;tU11uOH$K^z-P28=uH*84WZMF@mrS3LodN$a4!YxPu0)Togak5P;hS-Bf3K?v< zFD(@be{k3WR%;<93o$0}1?YRe2x>AnD^7_FLMwCSx?vBLeO_OLeHr8sBEy2A0(~Kz zse!eFsx3KL)g77DS67>DRsqDhHW>gual}lQj>x|chEp@qVuCsimkf{Gd7V{wF60h0 zyl@T#1}w~&=`Nv=s~03MzaG3cyQcF zADgc5flH0IP8ZN1&ypc3WDxh|yzF&2eiq4d*p8Q}zFh?Mq1A@H2MeLMLQOU$xK!nIQ=rhAHSk=jG0K%z6tF zTn2sLZWj^mRiH)8Q1nB!5}JOLxA{_U@lmU0p-Z?7omO4{r?r*j@1&1DB_5o zJG42XsQcost?I)`yYyWWB82i#jvu_tYGY@%L0E*-FEN5Om%%Jj`dsjK(<5`gelcC} zakewswk^r9r8c|#w-Hj$S9H#>m9HOk10Xkz4jO8v)Zx#Ov>;zT?g3a?a=Tx}Wm(Su z^d5hGarY$9^E116w+${qN4VOejD#EIy&+2!iO_(d!CW1X;gghvxXW#ibVkYRamglZ{pe*m#fVSI~oLSRRZ8>za6 z7K%z3vDXKBpU_7n#dNa=91ZVdv?WB{M>#9ta^4V5JYw!07>OVBFhuH+A*YCnP87!3 zma*x@{+$Fa!yRYK-jGRux{(*x)NXYx~tw@0PcN+yjme{xYp+N*q_(P*a zCn?5eR{)Eh{Jx-37cgm=Ik`_dIM&?d##)lY(ZRdZwKbP@u>AGi#wXoZr%JqA&ro^# zkEirEb^g3Hy>m}?_3iZ8TfMslBHX+Fh;6`@$^N6x^Z*)mfm3xPXF>Fn&5AlhGHCam z=K)di7#Wrx3fbEu#dALmkQ+Fyr>PfVHZpd9cIs(Cq-=|7eFTSw2OD7V5cHpw%77O< z1k+V3fG`?Vg$B<4(Ku;8H|{fMHX*g3g=jDX9mx%cvsxDmQi*@}J@m zGi_6|6ogybRge8b&cDJlD(XsPggo{sSF$;pjMT5x*srnQJt?kQ?Lf?Jp?fv(pb;h& zyq~sXGZmlx_yko@J`i_b;X$>eeDksRFY2n>2ObX%*KY2 zVYKP!Z9qVp1`08kPh-{;2l454E7GQSbSIBt(03O19)|sWkh}}fb2)e^W5j#qx^5ws zX-hWlT;|NY|1j6gB(GH|=l%PhS-K*DsyJkYg{-|05xAsL7rK^dcLz;6bvYbf4;AHQ z%$fZKc}b*&zuNr_uM=(^HWrmN)q$<8yWy(A{IY6ywZ1n zemM8lhp+C^!~^i(`idhqiL0&ePyv?#)Y4cC@`l{;?>p>B@I^zFYrG%NS2U`-nQj~z zy5`4{REqT-P3%AMenTeTzIjZ^ZY%P~sKEK$&MK4jKPF2@I=R{=*)Nzd_r9zD)9bt=dRj+7bz=Q3>4-IEF-mK0;EqOASav*V0gZ$= z{9CzjiDWP=2)YyLV@Q0PZd=}mm80)pJki8cy3cl^Es);>iF-^QBtg@&c9HQ{NapCyaw_=yxN)Q zb*_E8Rp232KZ&{bf*;^&-hXoGsG2W_%-vgQTAvi2{&$DK0bIz%wnO4)2Y)CU+5Gzi zYkD3F1?6Yo>Z^_Z-7<#GpFO^;Z~_PQVzwA)qCBwiQTeY{I@vC3qYs}nt&V+v?E@L= z{vu&3f@B8~-H?D_p-MDxFyTy&q>wKT*aR4uW-@kKMT@MITFb*(4ftPc%1YxhL62o~+ z$0m7*YcNl!q~nY_#JRlj2bC|6Z(k~?_-EC9y(gsto@W{0hEuoS%6#zXUjdM1wx>3x zq{ZZ2Nf&c}V}8U;g~N#FZX*zKaP{QV|4CF*lauA-IE~?4t{^mXX;~@v8OEyrK*%+M z+Hg*|7}D*35*2#d+Jn6QKZ(lFz55RyKB5lONyrb7^vr3xbGCyHOOO_MAuY`|b-P;& z&_xT&s4%&@^73LFw;VCNu1qSzVrbpvH;+4~Tse$6oW6*40u2e(l0#B+gLF5_PRmxSyl=c*CMdwE%n zlg&k}{u;|0IUg+ow|bi@Zyw{Zm__GHWmG0<b$btRmwk-9;9cjM#IMSeQVOPq01nKM?S7i z6}pbARz#*Va`MmM{+@B&Sz77|{s{B@xn2D->ep?nf5L16?7uEweERTg!2FXlfkg9o z<`;WzyP+SRiTv*PEw4{WQ+pYYAhvIVm7PN6ZV7Fy;lls8E)uY+$Td#V;EYTAg@q<05zwOmTaGMKU`obp=(NU0f< zs|6j{UArVsCnDKj&7nL4VwBx9%+A1~`PT02u~rtvrzDU?!Qh<{UY(nJS|U-ahH@c^ z!)+z6IQqnc@g`bQzge8gQ#QJ^JefDhJT3J0DzqT&!6!6d-jgHbIS{T~I>#ZsVVH}- z@a{7nbj!f1yRcwT8>MZjI42`muxzV-{Vc;m100QAXmrp)K8Gc;^^;*v&syXPPgH-#(^PYeQ;#}&Ze32IfBU2ecyDuYm32oJs+KU{JEfQ ziU3qeO<{cRs#!TzfSOsQ?PZ@jIED;Czm*oM%yqDxLbR zcU6{JUq8*_wmY@_8Zz8Hs6Myb!@fT^dB0FtnL&h4?pGcn!AJQE6NeC9KL`||B{gk$ za^;o8y>r^MuQL`ioMF(FpCOI#&rJ`!M&*~RrOxY^}I@czb*MDz(`1=V6cR$Pt_aYN5=u znJhZli<)OyhBa8z+~`ruw{g-cEW9&v?TQq=ytZ%jZl6bGH>^EQsFs?>!n=D~KS@_4 zf1J0K__X(Qed+B#meSQzT074|_mA)63=}e8zT@Y40?9R?6Xo&4Fy0J{o)c%sT0 zDzi1p(~ZRzQIOY#p`Hj)di7}v3*B{HfjNGs^6BLBWxF^r6xff>O_NUznUl08=8EOZ zXjyoux6?#t%IEJWUV!Yub#uzdZQvUOt8I6&=;HV_){TgWb$v~Z(MeUYM&Yfvmsgif zOgz+{Vax_#JUaoSWPET3I?x7X#H=wWRm%XJ)NEiHR zkS&dzRL?D-G|JD(2=vUjcu;t!;u;kr@=Zr8_waXFnnuyi)9$${h0-S`4PqySW}Z5Q zl4J5s%6ZQGqwD&)vmu+R{TUO+R{J*w(>F3Y87)F9Y^85WoYH!Aly+W_4*Mxv6?$fB zUCUBXb;vD!W4*O4_PB@V*O;{4i_QBi0sA*^MmA!bk0!WU*=mtb@(lQbEW)HruflWC zKhUQ0xyxRd1zr7~)#i(?GvJu#KejX(gZQO&dmEk#-O#Zg!j%-%fSx4~f(bjuDe z4p%3pY$D_+%ohD^XfE21XuqH~>$t!6>>dyWO}>hS2-ds~D*M^nV)-TT+#CSM5j9U$ zpnY?+vmR>@p$}ema8X^X3ZIghg-{(_b+yZ@g1-h90xn{`HUC+r@zZB8+)>RR^Z!(TU)YN_PrxEH#_;@b}EBZxg3RLg3vx8w93 zZ&BvyM-rQg^W!-tk`>S4NiX#G*GNm(P`L}^UzPIrPOCLt3BR0e zLZqE{z>f~qlujKoe=-QaQ%_MCdGQz%ZleBu3FAisx{tAdTuSPGe>3!3pTcpA1W~) zL22CLlz$tbZpG0SEJkW8jHhviElrkvy%TCEsm7pLftN(eD)E)Wc$V^u|XyA-pa}C)u;&@%P(q*maJ_CHr21) zvZ-*Z-Tvd(-QPcJJhH};?MBbMHw>ERIXLw(RqEcO^2^xhNoE>w#-VdVs&mTND!d@+ z&${%vJDv-1SDtWgt}IsvJGtBVGKFZq<$I(RWJ=wSyME>)*81|ZnCf8ksL*?*@W3Mx_7q^Zl8h^mVf11+Q|7qX{KMjAa#&&C>{ zCZ4PXOOzYXirVA5YA%Ju=v(1={qcJ(C!<#!y>Gx&PvZOC6}7xQ>|;pc1LLhC8Wn={ zT+ZhoB!(t0E`8&7M}!SprX-bSI%6OuHh73R_s{BSn^&;>wGOt_e|JBT@7i=vf9sEb z_%r`~pudE?uJ)Jpnu%xEKJ{_wDZ8%yo0%Ek^hf{NHWRxDiMEZA zhYMyv!1W7zELnBV`oq^7OA;7OoH?#>n?&#)L~Mb1L>$a zUgmj{aeA_;mY8&X{Jj;2*@NpiM3`JY=yN#ObmPRKjhN!xlF~D0&up7~=*efUks4PT z$vkmN9-SJ(pHd3<4ZUzZ;*i`!1vT+-4@;!QAi~^gT(3KkN$B)39`bNxdVwbMSRa{j zJiTx-WgtJ%TQZ~N+Np1bNwuR)Wo5B>(Fvy{nQx}Yx|fOlRm*HFi&fJAGo++ODr>Zt z#oF;ZcP?=gwX)h$brz`>IYn7RT7iv?YOD;28~X9XWl_zIYHAIkgGJdb{w@+U8(YIu z{af*=h@7@2FEb3dZBmW1CCAhufsKG3^`TqkbK`jZS&cz$*RGRoVpdvm*IMFVM5Ef9 zNuNye;+mlT%?@xc+;LgXAFYtL_TGnOC!{GSN_?qHu;j&0s(CDf{(l>N?~iBvqOdrr z=dU@21&s%Q`B9wH`Gt2cH8(=7sKJhgViG0=pPLCwQCE6+eIBA6t+xu|H7~rI@HQ;< z#WFY?fe1^eEUoE8(`NSwW3c^Pc*jBXlPE%oebGUheE_G^ByZu_kC)aiguX`?ua!n_ zp{)gZT}IWf`85{>yvE%tfr}8B7uJi{U!C5tiOc)poN~>{_fz=!Yf;k-rPu+V2a-Cy zc<1BB;=3r1Gzr#3fdp6Su(2O38Xu$G2g@!omPibwX~2Diu;p9>K2z9YTW)WeY1ih- z@~Rko=&$HJDeIS5^<2B^rE}F{Ox03()$(8!J>I0tsc8b$tJ>A;&efYS)m!D& z+k@4gUsr!Us@@g2xu<>ehx5&!F*gtCuCu|Le_r4GcXadr#;s778hX_gQBlJ*RKv1d z!**PQ6s+acspWR5<&CZ7uc#FqsufzU6+W&-3D$|})JeG1NyXNoE9zv2>g1Q}6p!mL zg7qpo^=dBl8nN|S74a_QRW!N`HM%VuG&OR7r^>HlS>;Rg%=3@G>iH`5SK)@G{A`)|Ly7yaKs z)_>>2BO-)Z*kYh_Wi*{j&SQ3|oEwXEo=uge`}9KfP$N zZTEOG)JMO^ydPIv-n;wd%|OJ?`zQDMzkQ%4F^gE;ANWqc$K)Dj{vzkltnJ-%uE=;7brhx zcWX5ZGl5>qR$B~M%hB3wp=(8cZms2E8D!QehP;96`6g1W>+%H_8lTn+aYiy5MRpE> z8^un3ts5n7QJ*$S@u@PKW%Pq=vpk@wb+f_>2L4ZN1pA-b2%!J@f+D~G{Qpa8BVjU? zQah41AZQk%HI-YX5Aa&PHQ}f;w%}xUAB#?ZETSl&>IKE@`Is9Dok{$|UobabgdW@y zDza@hy(z_bq${Jgb+ZU4X!BXeZCYIC;wXo97NSMlQVV!_dV7($dh7|-sjW9y3}O9k zK|Z7VGfv;=g!MrVv+0Iaz1j6@yV#eK7R`Z=FZ9J+lwN2{P-SRrp9y_CscWqwoUB36 zqS_X|-w=GF{P7&0oa-XPVSv@ZnJyPdaK&CgFq<>^XKSDA>SeU$i;Y8<^7Cixct$sl zBf2#oxF{%oww$e9?;QOgv)Hyk3D~?>DZ&<{@&0Xn6tnxJp1D+HJSF2>pOtWl#ghs6 zbE)H&@vl=@s#=@oS*EJ4RjEoI_TmZr^U>mAgDYFK?D;R~V*3O} zPM7O-p0K(TibqPbHy)n2zwp0*pu!GR>Vo;5C+UsK_Iq}|&OV#h8ngTpKV^7$d0ulT z%*0={FW^Ab`@y~FTN4aFKY&=!eG>J)ssshuuF zz59Duq`7IPtvxhla6PAPCCJP^Cagxfkxgy)lgLJeIilqY@0qrNCY|63W zbvFQTdBq9FIKeBz!V$y4Wu-pB$mx*>1@lgBhRflin{2<0hs=a>dM1Tt1<=wY&O?RA z2F#yta~4an0t@FeSUmC>^$CS9n&mf@9)rCTMyReLZ`9l7$nRR}g%-Qz`ea+PqnbV^ z&JiKpCawzk`SN{q9!d|n@KKQl)}*U;NGQ6?3|Xz3lC9Jed^N5oyLBkU@!#Fbf`%xh z%iy&8^wqLlkK;vXsoYV|zF*0Jx^9v%p$o=$<_KYS#c_J?Wb9|=r=)IXb_rp~P+lCF`(+x; za;gOygiK%(7u>ES_T~-eq+(g>knAQrOf5K1ZX$}oJ3TK0eKGl`D++$KY)DvaH{<+l z9dCb&8XN7I6E{H=#Bq32%FGalTPHK*m7PCLwszTDs}uTIHr^jb1wCH_cwZPA9geSM z$Bp3^2us6{ET4sw8tTRPWJaLE^B^U|X{fm>J63AXLZHZtEk|-t_-@MoyfpNF3`snf zR$%8MBzc0sLYAL_4EMREV@w{1WbTy=MEVM6UY+4<>(1T-*7;43#x(@Z6Z#B&6)jt4 zefPpjrMG;=9goLBEbe=o)Qc=^5&r*ix|%5sd~+2@$cXv z`@5DAGx?QTSQ3j=4RD4=t%fF35pxT`*<4E1aLC3V6kxqJy>~^vLm1n4s3EjVg?MX` zSt&@8Tun_SmnGMEOPL8~GYQB+*^0p+mc*{b?LC$44RYtP!RFY~Wi(`{9bHC)q`@>= zNN}vn3%inTCr_ajCEFR~nb|w(#-H(;+W5yD$2;C!C*#upS#HFI^btzCG9bhpL~0fb zW}=Rq%R1&E>2)V3{HWLA4wCE_vpim=Lk;0@%J3Hh zvtkad8aK8-@_)&y(}j0cdmQSRbk0nTybk}4N!Xq~d!^z9&n&UC{qn8INgbm2Ar*|C z`=Y=V;96Qu1=&5Q@mpn@4YFa)V!1jZWlh6wsHjAR-jElWoQ5+CVPP#iJCVQ6Eb>)e z1q%;w3V8DvatnTk+T)dAZ-Z^#|B1>2w02KE%pH&piq(qf^t!#dE%UY_JiDV7mZj#5 z18>>km{ce!)82y2+dlx4KpU`SQgo!34kw<<3RzyF&#&qTzOw6nhDy3maxe!OcBIXJ zMRNv63>Q^vFY`>yK~p1T-x^w{We5u3R5V6^BJ`or8M8!Vp>CmIwu zA?ZmFdi&Ha+;f0G!XWxfhILjfmO-qHyO*Yw@9~AvjfZOq&eOm#>j*-!S(gYG8XM%GZ1WhxD&M~f>Nxrc@2DJkMDKnDvy zmKRskJ?H!R)s|KN`h@Of59#1=D;$|ti3ut9xTg^L@3JXuX!>oNAXsZEis>$f^jpyr zU@;lVaK$C3g{xFQ4D}w%*;wUq{j(~kXaLH@K`p-wy;9u|VF*aTifP=)==if@BK@bI zm#iYA#V^gIizRTi;K#81U}n3wp&EDJ%nNYs*ZFotaNj69?MB=ja3akM>^3?J3>Xxs3LOCa7vUV3^ zZyMzBJpBC}@3#%-V{0+0DSq+1`}-n|Am|G}I_d-g$oCGhV~C_rS-U@9p190=xV|GY zRu(BQ5kY--{sK`IE)Bo`{!6eX18g`5Y!^lA9MM9rpyRl%&N`ZiV9fyv$Xhhw4IKUQ z6?-}aD4+CTus1H21oKjSRewfprz%R+cwzAX{=D;n$~mo07{@O7yYzKq6y4(!sWNrR z+~3_11! zbU3>UmO_CIjj&oM2nPmGaEhbLar97t1=3x0Ak}9a3Pyt9HGo^E!#!Vp%?8VJ=(E*L z?%A9q(=rgx5@79jeqb}=kwc1XRHPa|Bo3R#mkbdGlDwVbSTGPhBqVSuHDti$-$JBV zjYTcYm_^HE?69NT^ z5dbhIqX-S{IM@Ao)V7Dq9I0gf2R z5&w0iT{0NwBoX6uPLg7b0>A|5c^=$b9*hJvP@1BHT!V5mgv3tiS^H|DrP&3j5bgnOu8V4Cc91Dxu?q&vfSw(c^hpEiMDSuNwqi3PhB3sJr#Nk% z_;i8|d{AVDDFaX7J~VjXeWEL2;{YZu?E0A1feKj>BF;JnDH3tL!q^uG#)(*bpu(uj00S0`9tx!~W`RF#aBrs)!;feHw!j)hn!UQs7^Ty4`D zm^vNJYx;{DTFaI%ZO^}!2y4*_p|)^oQNZ=iCGcHv;B@g>DgdWeAcz&l zNQlxdxZ9}FED7w01dSsqYGptH+SMA`5HP06!liC2rg~30Rhd>jIqn{VEfS6?i#2LJ z^y7#y6D(~~BOPfHmU-irL*E`om;OjGnIlWZwos1T2-=Xm3YQE)koRu0o!3QrJH?=; zl@J5e3xv)vwTUs6O1Xe|2q)FTK@DD7khP|!gBOL3PB)+n$>w$mZ}FCQMqn|W=R`2| z?nUs%ft+X;XAm?aX`5`aTv?zEQN?D@nmMp^f*pZMv2mCywe_ZH2@8s{B-pkcSVt&t zT@$2tv4G7P$kuX9$Z=cu`jvYdT;}Dh{k95S(w@J?vr>m`E=t;uH(DWyU@2Nv&JZ}Y zqQ+?o&^#&&a&n+U(!@^b)9Ght##dvP5l?sTq37tZ}gPvQy1#N=*01EO0UcvLb zgg*=5!S%tmPr96$OE;D~#hC~G85Aj9$fb>^*`;E+l3Cl*uUz|4$ObLDVF)5J*1t_3 zM7IEk{MUcOdpp#Y&8zMgiZ{4E3RYbnhw=I6Ai@C(}ooYa2oz3SgQ5Kbh(5Q7z<_mT*y)~6uiL-%su z-1B?gAf^Lo>~`eKd9c{uIoFK&A<-V-+CJK;wxGfb-}F;u0^J+CQxa$9)ojm10G!RT zZ@;+&r)1nZa6uoX^JP9fnyP-sRC@nSg}+Xd0UpBH>2%O;7v)>T2E8Q>y)#*3bNQdKBj zx1CmPpWycM#6by8RC_pqaML+8yRAieYp6hb_~{Y&^una>wjqYE1x{=v2~}jZKirlX zS-c83QoteyQ~VPl(l5vRjx-lGz5m@{j)ZYX^-Y^-fC+J#zh)lo^x8Y_-tuCu6URCvU| zIL8lbH(yYXxg^8v?Q!zN)umbb#}9c=L%~-b&w@7gy`z==q&FY@Bl{8r*}8R9u8g~N z955MUUNAP5ZIspP+zcR@8ddRNDGJP)0Q2sIc@u!PBQOiDD~09JO4}3{5b$r?ac!Oc zQD5r_2t`RvvmfAS3l?Utg&OW=ZrRCGl70Bf6DI6%LY6#^c!;D9M3w*qE#3JV1_dP$p|s`Y2Nr$s$2|xn z#C3W`2?e?q;$%R8{+Kcr!$DHwJNvT$7G!HeLMQ1jnUj*uH3yfOd;0AyZ|Q4q7w(8g zo?zJ;Fedtq$(byGK&?odWlvd-FS^f>;IUIQ&-%ca`Q2SR-_b8F4=#OAk=-q^)ouED ztD22vjEm(}&@|K-1IQ}?TsjY#6d<6)zO$ACJiA~ES%B67_ULwIUD)#P2}5_KU*K31ax-vxfswOGQ?Hg8CXo!hgZj=i_7FspJ)kx zU&(d8MFqWZ#MU~nT>v$c3T{<+4OI43wM>`I5xquv%dpWu-ACRSKir+|6@71VAt%Z# z_v`ZeH-@A4Qs}_tzDIJ<71^no=zittnT6ui%9eNDbA66t+3NV`Ap(6(yHs!%t$lUx3k9s$kn>0L#x!O1#{C1Lb zujQ27^^c#nil+*`!}~Zw96B3;ufkaExV&A>FMX5M;>TnI+`jCG0zZLZx?l(L#T(rT zQ%8ah)wlVsbhtf&-EG*p5qSsn`5W1!e)9oSq5lbg%sKw%A2l4N3ZOxeO z`5kQ$VvhHkv%@Y|thaVd54%wd6_Pw$y`fcwNL`X zIXU64cp&QN-qAil*IAWkLHQW*^$!9HbRf@Qq|4|DD_LX?HZ+aoEv(G#D1i!@ z!lod@Gh;E@Vxq8I6M;QSr(r7yo^=Bt;P$37FtPa-!^_h>A7yQ$@Fg>AJIRpR23^U= z5nTQfCNYX#P~XTgc`E=FauM)tTkkI zPPY}3PcN1_%KuHKgpI2zCN&+Y_k%Qw=(ji^+5Z4=LXuV;r92@$#Ycf)fv*xFyxwki zopemi%1qc#pFTliQ*E_rMHT{HBaK0K$^$;hb%v2YXfhhzdz6J57Qr3m@?S_ zR0Vc%Nytki?R9{2mV$%9S?1ndlh9`@i6=dYc@ocot`Tl6$UuQQ_F0`l^ag#iwFdO! zzPu**NzDkzT9|f=N!BS)*aF>x3lbgUDR9wKrJ_SPpr~H5n_Q%qXM& zwteg;YFi~3E8ExM$H>SwFeRKVJ(b>(DWrv32$R;*2f?}GO(`+5_y}Q9AH=}@R7WqekpK2j;w=QTefBNScOwVp#batVGf{8oLM^kiBHJ2m z@17XD^}JU;$O>v}<^e`nRMQzt5@`{I6ymz?8`i%0JS7sUFm&FKd9OH|)zbPx0CWC3VNuL_`4qmwz)7K~pv&~a ziJ4ttUA2@EEjeqW9mI+Tvvk+6F?OKbUM)FP>HVr2=xh}H7`W*8ez=%v2@if!#?NL$ zOQL)kwKzglVEK1d13#yrluc^5&qWLg-^W`@*`_5^zWvH;UunsO(`nn8bxd8$`Ch&96> z=i}lAMS%qDlC#TZea=P$N$TZ+x?Zskv$}jb!B;P5wirUiX?@5iSd&a-fg z3l*l2zyYaTh#J=D1HAXC1g{$`K?Lro?0LwypBcKzn7oBGYU^>70k;knbTVL<1iRZb zdSoB0C;t2G8K@?}MV9~znKbLX8no)jMnl{v!*mO)NU%^t;^D04U*RG%JF#ukMNdTS z;YR@_az2UGiH9jXki__sX38-DrkB~6aX5VWh>(;u3J>=dj^Gw*sDBrKo`*@7t3p|z zcKlx%OPfR_RA>s!2^E!^JKHSB0FXi9nB?laH86=5Fn8)P=z}tng0^Vmx*hXG7e@q( zBd9!M;>`mHk~28N9$R-2BoW_mv&AR*3$F_CZ$b`C-f8;cMJJ+y+e&S)&SU098I9!i28syYGl{`8wC-lQhpZVd^Yj$ot*ckCj zjlbsfQ-VLB$A2DKZVYBz&bc$WA1wcmfXSQ4IV-QibS3_Xu~b4MuZOa^)Y4k($}I}F z$L+wW0WaSVIhHKNeG|#qzQ={FWm3>m`k$~G_YpB(b?a+@dXkQ$&#A#eO6b}Svl>5M zPzkNL%{`1@ZfWX#vhgatAx>=ju9#=)0_&rSk8i)(DBTyII?wpQ)sFX)L9Yag6yQHw z!T-2yLXnsLmNExksI#YD@*ZIsXdQ>3FbaVQcQ{W>C{V^1Sq8jiEvoTr(7p?$qaB!~ zv?}Go4=wp;-OAQXErl#>F+bH5qrT-7&Ae>d9B#GF>8X_2-PG)V4YD%Xj&`p1=dGu3 z>Ke&06D`=}1SM)1wdsJh*;QT^mrSv8eeusOS*CV_rG!xxYq8y8xRVudc!eJm!8;$wH-@zVf#E*K$ z(@D$9hN|n>_H6d$H(XjnH^l@fDfz3(=GV|KDnell{T7*-{~jxi#+b|8t2#Xro6&iUFh4JEffG{)WkN^yPvX zd>HQNCWkJ_UCKy0xT&}Fa}=?Y?d+!gw(mP;a5!5QPhSj6N?sMVyeQ68L{V25kAajN zzpUaVEv=99qdOQEXxZpjjSPT?MNRX5{G@NELFiZL-xu$W$tzAL#BR|i2-g^I1qc(| z<=T!Hx5F@?jMxofRUql1{&KXp2?+eo+>;;m;@>Q(RxA)uE_eO@&l(Na)TW;Wxum!sYVvszeC(rUBFF3uP%koR-x)D zTvphxeP_(XkitKu%vHWNg1!yS&p8SEw7x=rb^GjR{PDG9Ln3>%g-v|csp}=XINyo+ zkIKy4OZHqsnDZQNlubV7hb_7v`#MxV{mPu`NniIA(`+!gT9cSBm1~q>LWv`4wcZ7A z=~^a}oXoaGNVzCtQq?jy?s9OKSUv1`3ooG*&UAg{!4LQ}6r z$2Dm50*t%_kl-%Vng)LRD&f6jh`D|As&w!jPb0wzxIh>9xPb%Oc*f3{=X?Jd`5G5S zILrfxF>AW|DizU7MlOUUwe+%b)&N)hHBUKQi-L!eQn*@dyqxmg-}`#SNmyz&N3h`{ z|CGc7C@=~MW~8JBnvkUqPnchgUf2E=fBedBUNiBpMuOQSgb8D93dKXvmzno%3!ASW zOn5CiBxe$m$#~wb#$?+ft^3W!Of7+SPASpGHqt=QXHtf1x(yK?@PjuMb2Typ2BII% z=W0^h22%BFT+E0h`2#1d3BMG$|NW>eB@lg-0UPd1WRwV?wz%5!c@xsf#Jfp>wdv$t z@LL;nvXR`qU&)fj*KE?6_uhzJnuJ#eLgRv?9hstjg|5&$fe(X15w7W|*7M#2O} z-+)S^V`_Yh$TDT#`I$LoIz&R%fnuil5Mu@(N_y^Sez8+(4q;tT z9Lp8M#VFyY9lsCqJmjosEnyV57OeqYX-yRbz{YcQ*C@=GklOhvSCBv_HQE12KkYTF?Se>^=q>jOocnoAVVDNE?KB^Rr2T7sGUFE=oK(H9VwVr12U)L+v zpI*TV{b@H)X4Oa&p9M?A53_5kiCp58zuv{yD+cU8htQ*UG2#h?cUO|-qC<`rF@wwZ z>v{dPX(kHcT0^&3pae_%_fwagnd_ITJ50r?8zsh>4ZYeR_-;i;+f8_9!*&1gUZcbk zv&6emG4)g-R_KGPD@RjSKE`EJcx3E=?krm=u z0QdxC##HrF+B9cZAPl?p_X7dPh?^Oi4cY`?Z@1m2gon2i{CAGecTYb3yE0vaqFoF% zMWL#$0m~#b$K1`Hxh4i9htITZtltG$EaYRPeC6x%yF)UW8>ey$P@)V5PlvA1W7YTJ zpuAYnV0lNN)(w|}`rkv$Xq2r@xAwC=ws|ofTQKze+zD8_(?FyO7D03ar!YKFck z|HpKSAFmz;6ujJZZ8=b8q?pTAutkQ6V!)$1bA|DSG5tA74FD?(+|UQWfO)4N9_&ac z)|4|8#vzgbK+SOd{OuXXn zZvKL5fa30?m3kc2tNQ%TzFJ4dau4WD@>SXXmum%8GrhGEI{#{{FR!v;>FZn^lmX9B z`bxY!;x@Cs=sTIa++N^#3dr9TBdZy&YFr<)%ROG2kvIbhm4t|ON|uiGYjJeI@eR=5 zExqM^ZOoR>Fm-ii=hBoV;dAWAE2mZQClI>k$`6sL9r&J8z+9?bLE669E<{+xmCpVN& zsWJdl>Tr2{Qv@QThx+&h)rXx`H5vx$*9!anb%d?+&L8SC#iQB8prf z=-yPm{KH@$*_Hx>CxiUAVy7sB5*OA^E549>w}1M&#n_dXfk813O6U{h7<5K9+xbmM zurA0Ic$i3@Nok98tr>Td9}z@?>1YD)PRXiDCwg#xS#p;;2Bxxz(1Y~1cQVpSe{}qPqpSqDML?; z@zY~%5BaE(-q@4C*Pk;KKS4O~$SIbGNZJG%1`;61RyID((3cYtWute4!Seb%nAlhy5SQa}ITL5!74Hzj*yKRBCkt5sYPdG#&U(PICpBy%Mz&IHUM&VvF;GmNe zK3A3>(1u^XKQFxQCG0-0?QnsWoAXsgTswL}oQohJs970Pg^l|&#(GOy9ltK1E#z|eqqQHESHQ?UkoL1xNK4gS z-Y0OEq)7$fO|U;(oDf77m!BIClfg_!he0u|4<}-Q1eEW1!iUc!usXgU7TlqVfwpqK z+ZDCC%zBkJcF$T(;@L%3iTQU%7Wblu6{6!2U51QZRg+a=Y7fmJvlR;u#_FZ!UK%rj zd9kX(xgXGOH~-v9#k=8o*ur*Z8(%0Z_yj4?B5mXKoAOp@>a4jOp;M@fE7F9OCBF;% zLV$F({Fzwbd(}-84YV8iA;*0lIVY4}m1>B8I8T9wV=sICMZOT@8#Pb>c}iKUort`o zB6J@z!3*o1Jxj&2e2xs(TYa8$2Z}CNf;l@^RZI&LkQ=!PJhN_ZfjRikqxu)Kkw2B8 ztVISJqxaU7C2edr`OH2&xl5npcvMzINyNQ6bCy{2l2w)ftF(}PHaEnsaO0r>ckVlJ z@6JaBq}7est@{FCDXOI@HB1BpEqK^lH+wHH8M&+wSQeT=D+9$U0$+96szVtgh3BBC zVo%Oi>8~t_k3U{Hf^y-&lMj~92LY%~F#60^l`gY4{Q>Uw_FYLtcD0gy=OXs`j^=nH zvRx#>{c{^;BUl2`|0^rvUzi1IaDgc7#nO?u^TvP~EOl`ng(g#Cp(@yux85ONx2m^~ zO|kDO(4l;#`-y8FUD`7WPd-_PRpX`6d;G|#nOKL{B(3pdrv(M3U=>8Iq)o7%X2u4ksVvl<9|WO)!_q)c7%cO&zoJWPcNP?dWwLtr!eM# zL#_i1v=%WTDBbdX_D;$9qJ34)cvyJAJk>k~k5u7eTE)OL z5^xif;dM5aVh|N%e6{p?`Hdioce-q4b!~maO-mT{W=T++!?kF0Z~q5?cIMPx-1)38 zr3YqMH^8l=R5IMrizX>=6I=9jKl>03yXwZX(oUqpJf)Og^Af8OOl6|_BiZza_=B>( z%<+t51*gT#6>*~!kOl|62!zzfR&o0HQ1vs?dKBouK@3Q2vM}LKo!<*Q9?YKmqkA!_ za~ybi*;-0Sxv4M2*^f8Ar7+f#Zh+#nTe?5!W5kinsKk%q@MKA55kTREECzNZ2zzSU ze|Yw6SuPrT)kw^FOPYgkaZc2Y(+ks=z+Q+If$T60+4y$)ZVlezxwtv&I--Ck=i2(k zB0b&z?lrAAE=5|DKM3ydVQO^6M08~e_GahpzcY2*%tp=a@I~smmP5;)xkGBkHAog7)0{wYqZ4%(%^Exddm|Syn$d5 zKCJ*BVGsF>9|56vjaJeCyfVp!&CGuUikjjzKwA6!(&xZX)Tg7>7R%;6_p#LTYDyii zoZ@8fUmFY9ci&`^muHz1vNk{fEJTRbCq|-y35Jx}r~eV3Bp9l^lI9l!C70L=ph(I1 zri}AIUGxTuLp}&4eI`1AK!(tY{MV{ii_@I6wWeyS^F)>Bs{MD1ZG6m?9@qeg-}aOj zN*6iRN`Z%VF)Nj>QA1Clj%B4y4!|xU<;H+Jid4ETvH!7UO`>p-<2YK!9--}X4Gb$P zYL>o9wORkzzPeO6&UA8?bEvu&4E+R=X__lFV>i~A!*XB`*VmOAdD1^6s68n%LSSK3o>T5%fbEbIrvK3J*6&m7Tyq5Aezn=PG51dN@UY6vp{!FU zQYpNwJ!2Y0LeBWH%z*TCU737~lsQJBh)2)CNNvW$7l7>N2C|EFk({dic>Jd;+Q!u89;YCvn(&!v=2op#IWPtS9d%-rzNsnpkrPn<@Mjsl<|IFdK z=FFTMTQ;Kz|p38BY0Ti<@14B|y-h4S#xM zi1_%`C}BtYQkWsM&U?y%t;rhC0u>KoeT=ZYcO3kg`qYCR@J`1rhc|05$mdBHgBcL1 z1oCQM%~`ELtNlu8t*zm;_*=^(2SS>uEHyNySI)QvHI&jP&s`7QT`F%kfk-oKjO6G9 z*dI0wIZ~*>WdQv1VZU_RLa30|lHp^7iQ#nmI^TVa7&5&%nVkg$eIm*ao0hyIhh#oU zIt3y!@V!)pWDi4}5mpOJAkk6JFmbIZ;=KT(?BxIy)Xa4FCV(Mx-Cu`V1-P&ckDfnu zgp<=AO=B|CAIn}D<2qN%JyBPbl%z&whS6Sg`x+(R{JR?u;HV&pj8hP*(P?kBSJ3U0 z@wi%|=$R}g1RE8;wv+|=8H_hRT$wl{~Ly%rab|!xS+X1$Rq>N(h$q(g>aDNi6A; z$Y#G}+-CE=mVLeqBudIKkp>L|SQGFb<^rk}DG6ujtQh9rJHq6PTiYG+Tuf z9+HXR(_qFL0+{npA)ihL$;zW-2C7S9V)8}v2WU)xrbr+b!r@uMyhi8}NN}cAl3L(J zMy`G=DT|$fF?m|UjFBcej4V0MBART&61f}~s*x_K44z7L0lAF$8+CWW4|?gkuAm!` z8%Glwk3clOaO?#8RVwvd)U#tJ=0r+y#B zv*`R12tQ56_K4&V0i=9(+JTtM%p-coARa0*28?!J|VkyCxbi(@<$r1T*$T)%`z}v|DoVIhMVd3-9S5SXSEoO<)!Ma-gnOY8;Jj)Jr)xVK(3pOUOi|o<)zd>Ef{Nw#Ps~G@3YDDI#VZ6VwTeL0 zpEN(dAhgCeNIBpc-AUj`C2yK-`P&6Zj?ld)4>T*cZX)2A6wzyc&qR z8eh*T#fkge1h|!_>c>5s!mBZKgRy@p{7rww(t~^)qWrsd5?Ujzt_XA6KrGi!Ale9M zPy`6sW^3ycK#sRile3MuWW6w$elbj@jYa2bfV`ngt(aG7qo9|F3hSiRFL^Lc+6`y9 zz%2GKpL*@R5;t0(|7+qfC1!QdTit!0lnJsz^lKhW#-dN90dO@W1YQJ znNc@Ett>q-XH03*>i>>w`y3)&a8kpp?|s?R|$ZJkw|WKg!nGpQ>l zP?IT7MhTCRFPx-%ju_xbHGni>q5-#14e?UK@2`I zWil~)U&^}>6psN4Rh(MSqRRGT^x)VK6ljUW@JKJ$X*ewiojuotef9B9gMNm_?;Ky> zbZ?c6Q_6yqXhrciwr6Lysz_%k9p@wmnP5*n9&H0IHV4PT%2h~feMtNGqo}^U#%w6#Nd8@zr<1X7B@iz)*P7LwPm?3(B0lD zUS+mKuB8djmNxrli#l?Dx)ImQYWHll*s~#tIjuCHJzNtj`r|uDcpjjjGBi+4Rgw45 zoGEGiY5Ij6<3bf~+EWAv7jhF|)zN?qs<+xloP-62VwSMnhBmD!4HqvtI3*5jyS>%?=SIUjwz1 zk9oH%t0xYM=Zj%3I8a1M;-kp&7741{OobO&VKUfK3M~rIKBp8)cGajlIJkfrU9*P0 zJ;&(mqy%cjrUgdu(hAlc9~8E*m#C1SVUCyOd2O^*S(G_q4slswoklV?3$-EyxX(OA zno%|PNmU$Ue)R!^nrNa|DTMy1(Pp^Q<#`>)sEE6zijWqV9|b-vzwx!?o+oqdWKr&@ z74(^5?w4Q+%51zB9?aBHS4~xN0q~~wThf8^b1LgK5A~5GNCH8rajiz!pVDYeQnp#j z7X?yO(_^29!!H^D75HWtkWyA{6JjPC?sQL_m3yu5x>`#Uq$J9+X-2NWpaVBAQQH8c zp(jvTsOha3HE)Qsu?IUzjaHUU;MZ`iapWZ@qn6Z*D2jQ21<}yEUGrKMvxQT8@9pRk z%#cXkj6%fPIDwh9!dlqtCXFsxMNjVCMk@URb_EnI~e)9JSPgAy@QsbIm z7m(*-#kz<-p=*7ApVP<5^@5$-KJTzKoS3mR5NK#>d%yq>(&_UAN5%4Q<9i?ctW=y*2<>6=_wHz0k|&XouwP z6ChI1x(@`LLp?hO6jbd*;`*pa3{%vDZComMK5-@hF7`QthR+Ezco#ZPTyqgD?5Oul zvN!89aCs`#`Sg0k51x{JRH{NGjEVrk8$Hv*b!tRL4YC zkHCKr<@Np@`5~j*#YWXV7u1?3)+4DMmEfF_TlkUww<9^eva&y!kl9rGTRfVhJpm^W zkKSRvm|=NNyRMm`GszK~Ug!HJxj{1pU$Q!a+^xns+eSqCqgCYw6dr~9U0eOH@wbzu zOLl$7@Q~v9>vvb@Si>K4j>P@qxQO(0XMq8 z@zJAg%D#N5vB1vJimlNKF<1n7i z?nbrA&c|s-#dQOB8;J^Txlie> z?P&M+OZ&K*8^5vDntrxgvp3;r2w`FJX8f}{j~?IhJtUQE1XGFcX&X| zcnY(hPrTo-KYrL|(M9=zv9n|zIJ1@pFd+Mv&j&3#?%P6m(Q{HbSadL*Tl|yM*q)`M zIZIIKfQz>(4i<|E2mP3`W+U314REg0ZL&Z1Z<)=CdKtK`CUi18#SPdcm-_#aUgDW2 zhxQV*K<$+5A72iCiR0d;o#XTX`;!I3u2)AwX`X2F>)CZoCv@3Ww3A)Yv`6N^M;;+* zUM8(Mkn0@bDVzp3r`i9w#*dC?|H-E}^Pw)U_5#BB@GmT5psSAX;loCHNl?tYg&!N2 ziNA7P-m-}MCq41@28-9e;YH1}5dazzbWlzZ5pQ_pF@v9i-x>x6@+c1rZ#sWsUb5N*tw@9I^1y4lf{ms+=MQqMZ)k^% zExo=Cwra~Fqkj|LS&!7=fCGhG&D4p47b<6*e~vOSlJDihbW?vM`tJ&ej+-o%*o^^p z^QmtTLl!vKZ-W{6S6J`#I&=8PRz??wp(u`o;>aX)1syhyuo4;|N^tM4f;d#y06icVO=69e3)m21Gp=BC{jsOGZeG<)V2 zGg&R?JluHw>Q=1U@;f*NWYYl=L4!lEcs*&J59&h~*`>%Jk&2fuA?BoIZ+ddyx-)`X zZdP!WnB)=dgsWedxI#`+ftmiTi<91P@i_}Nk?aP;&h_5k>AIzHgs(fRL+-#MFB(3~ z7M?iusjJ)l;u@;09m(CBnEyigUC~7FB!umDdbv=B9h_U&ZB7XzB1l>{3R`>xI=eLvi`z3!pr*d_9yo*uRBxQU4tq-kxDw(9)94t9D2#i5eTzQ;f{A7Rv{Wk3ZO_#bbbDpMm~@4 z2wm;+JbIa9_=#Sh+c8rRY{*TGDtf!TISU9 zW8Brxa5Q~yURBL~gHfMgl6OKWEf|f=`c=1O)alX^uN-$QU&7-wzp>o>_MKvz^8+c0 z@7MqVBzhgCK(5>AC^ed%UZTH>A3+>(UtKlf{Y8)o$uTzdT~V5oVaAWQz8zGeKTd9Z z|GFaSLVCGru%qz+Jh`lsfB<^yeqg@><}f|ZyU#6p)??g&NCLp3^%ICeniVFEdBt$A zS>Hl}*?Q>K!=VXU2VY#l)MyBJ@svOMm%{m1>w)GY2&C#A>RJI~hSKkdba1eHWXwvw zaY(QPa@COGjHLkl(rkg-;uAytC+jAG&?^vUkwn1Xb}ho*9{Y*#<%|k_&e%iY8N5vv zjQmj)JkMTu@{hTTJk0u&{rVH$nhle@l-qO1VWIi*!4%UC8Z7vU806PIaCbVG22J&t zfs!UUB{hx4B_7UXK%UswpJg6nI)4_Ia6oaL)*KG!#~;U0l#dq zcg{}lK`TEXee4ri<6z<9>~M7!pG?Xu5Vz`b|Bi(* z`cbK#9Sp3dK{Q1QDT$+M>u^ z7?e<*?7{+?a_GHv9#U)e@Yh(+-*G#oR+1qG6OhvRrJwe`?ntS$=AS_v`0#B*W<_-7 zRRL;E2^I&AFt71csaw+GhT1V#s9(-AXY!e?D;6%kUi6`__hsboAlGyZ%{{pc*!W!0 zSgi(Vk=W=A0xWBTX_<6*ZZUNMmcla;XozS*9>~-!Jy`IbxPTr3mXTJYKuKMyB%aC2 zpV;?44)s`!EA~pZ2emAl7V44|Y zL#aZ;YeR{wYTqUh21>C-DT1P(p&}`9Y3CEM0oiQc-l`~T(ZuuGkFOK8ciZ>)Z?H+Q z(W?jajw^^dkdn%MBw4U#Y}Z5`8R!OTkB7ZRRVCVl7f1#2(i;tgH=x#I2YY*pI9kh4#R+aIWrJPtp$dG8ewg?D{VLbXx)pnbrae;BYUw=F+lB6@pbETUiyn`ff?`90!6QBlS>FXYL# zivxzevWW8^fstlzW?Qyv7R-NA_8{=v6>~ze_9ED44BFvs+SQBYl{q7JS)OFD4v;>@ zt_lH}TA;#M3iA{8WHDcFw#1mFBJB4kA?*h)@|gN5H0Ie`tfznX({b%g@iIzdMCSH) zE{2#ii0x_)8aboQ>{ZY8H|;afxactqp1GQ%N5ouybYOo1VxnN8gWVGT7&MSR_02Ij z?-DS&NBLPV1u`KA4NuLNqn{@BpWTU2dh1Eq6rIMYX6F2w+f#g^HG`92~p`PylV>e!cJ_V*yN@4WTe70;Ultf`JhEeznr`gal78b#7 zdchRPJd#Tn<=#d;TSe*e6gziABs@Q9blz|KZhUx)wEjr$4Xgetkh`!l??{0F)4rjR zS~4hc-XwI35ELng=c{jeRUk|PkFN6Y#XTdk#21Ap^LT!6o6NBiWx5B*O)LGboJ%Y* zMP>s}Vbo6dvqNlz;qwRvwyJKA=QXM3_99P37@anBK72?75i*u7N0qv7liZLiqJsYkitIy9w zHhB1&BwowBo7txE`D@+u9m7I-EVFH8N+11|oBxG!yg`$&&Xh2_pVe4JMInWVEi6Of z=nQpMC6OQ5Ungq#wCj}1eiZ1C~yWO ziB>x6d$?(%nLFrc?4Bh#TZt#u}CSNgU<9Zs+8dc2_4o!b2_3X;ma~dAaDSE%HQL(bEGOt0K>@)+C$yuU=fKw{zFYT5m?dF6!6jjaEgA=+ zJESZ!*9$G;Z{6bi0)p~uZZRTUbD zs1T}PR=>MfwvHK6CZO79hGshEG=I&IA3Ago-*OeBbqncXZ{4g7yg`uHe&B*(ID?c)0O6d%;Yzuh$v)&={T7I%8KYqqNuH3_9 zK7>o&@ZU6{F4lHu5m20w>HYC?IqIe&1Pr6)-Q?_1umAfth&dqkyC_CoW!baJpWyx# ziPDJ4tEZXK`6VF#@XD)PRyl7N?X|~a;Q8lMxq7)3`0nKFuiyOgr>H)h>K$8Nm6Ldl zZ2Q4|n=8+16%%z3_vpy$XT(p1E99dR+dTZFA4Wk5*}j_SZJStN$)c(i`l*j=17h{` zccOUz4TuNQfE3>G1KLBPJF?_j#M5MX`@EvK)RB!$xU%eVFU6xm-|HV-LjW(qHl4W9 zoD_Fz!-qsG?aO&yrM~@!uUWuRyCPXs*G@FuO^#A+nptPIC61TbBVpdgb09^%LhPRn zy&zfKQZc;v%_NgVck$6(VqfntiN@cXBN&q8v`ovGd0l`#ou5eqeqy|&c+ELl9>HuS zPCl;SW3nP?Jblw;>S zS43q{GA|+MBE@rFIT(m)K|Um>={8-aJz3>Xqfmx0CcJV;HMUI0E$6;g$V1~5G`S^>=bFw-Tm#Qf%K z`36xGC}5inpTc9xJjSOCX?NViBQf^za) z@(RW6mJSb56#i%m=U~`$4~jg|L0& zyy&JDf3IO_JM+SH8>oYiovk&1}(EDpvx zEil)lCE#A?-yk_}RJ$_rzb%K^wLy5A*GwrDZz#5nC}!Ey6BIyvB!*og1nES-9~Q%^ zfA1$%Zo%xOlnV(Fshwew>R+vGHys0IMnZfS1kBrwU{xiQ9e9RyycnYC`g6RtQPRBZs2-s+#%yJJLXs9X* z#Z0W~HmdvYj82jb6O!gR;LqAuvzF(3zAJI8Q)%_wUmsr}aaCH&34 zuqY$2zQB8Q&b!SBTm#8Hb=M;gUVpZ=4vga8WOefO*E^oHpvpMzqXG0uCmoq!2?o>Q z;4b6>ppkNRl;BGzGtuu|e;B*phnXld`eXq2k5UBHk(8tkK~5O2fPPfWA$Uo(^Tr|g zfpLK)1ibAoQuCcd(w%}H4;91oh>_a(OztEg2m`xa(1)xNYB4Gp(9(0$`_z6MQk~o{ zdat}wYerK9;sd9@(~1y4kwgd!3CO+x$q;MxQ9^N*5ZM>a1c82qPF7vj+Xi5cs4%T? zqttmSm`Cvah1uFZO0XA!+yVh(6kzg4HFIOZn~C*O6rG5$B(0(&@)NVC>-0)ebQX2bes-w@%8#o#FOKx3>teZg3kvYIG0-+|3z0 zAZE1RzV~QGN*#jZy&lU657eRvM8T`CHTxq$^p$j3}>r0tLeSmgcjKK>V$R z0G$iW2?r8+KIxjvdh?N)AVMOt_$tdhpm&J3>?~1fva)Hjl=Y8{^Sg_42l)q6_~0pU zp>`22>9PW`x>!y`1UM%6$#*}qq$#iiSlxup-dq?+;`#o1Ft=0;8MzX>SX zzgZfY#j0wNW5gmYM`sl++(_9+&FIUMnV%Pu;|}7^ zFSOSIbFGJYY@WF&kmvM^Hc`pCU+EznI=DyW)xCUFWSs}~s9BpU$dRUn2nT>UVW+td z5KYa{x#2g@*JuH&Q0kgBBt7oIienSmaVeGSeaP;7kBv?h?J~*PsKe-@f15{LWL!o* zU37*n!jV}V2jZCrgs{yIx5T`KhbdjTM^i#FawK&79RmtybR;_s4xuarxqAn6RrL$G z#D$3cyRxw~ua;98DAPiu+z?rBq-pt^;y_X;kVX+1=m2=;ZS(|@{kImcZst?h&V89$ z93NoQy7Fp1z&Koz-w5|U-7w7f)Fr33nbCowXybm_^>CV}OvcHI$vU}M+ zqsQ>h@s~COMa#}NonCiie5C0evP+`{Djs9-p_?gl2Q}C*cq(Fbieh_jq;qRFv=CRg=@=(Z-&{Nfn6m#&E+kjwlm0f~wL5 zK^#95>iU-U4cagPL;x$U@xI$g5MVvs+^Y4OK2+00D@|Ml^I)FwJ*W4f`%pf%{FM@r z0Hn|4LFV`w=7c7CocNO2WwD?*6AESYTZfc4zX|`h&01(`^5!)w z+&Yo3ZFaW~}py&T~Hn>WMDTfhk!*UT<_yABmNj{aAkp=wGp^oPfURt$7F=-*q zg$M#^uYLXUF;=kq_KLh7k!+4peCT*O1=g}7rb|~yFrkgPS1heGG%|=VK{C4~CvaEuuzY^0 zT4`TNkaw?5M%QLB=bua?>!)23FhAB;mLpqG2rD*M_!gniGX+1@yU8}sixj^4oDeIB zg=r6}`_(gg6ko!UqM!-php0pe(Ruh)$$f*dI029SduLqt{~gAi`sC3AG3X;Y9Qdge z)4}91C?Z7^20s9v5dv-%z3+C}-9F}@ z9=o=u*{OX9-1>6Rg~tu^y>_1RQW4=xfXi`lR}Nv zNz>RDGi{58;z`NpCv^9oJxmT^{MyfgVjJ^NS`mm_?@)eftv=bPym9DOlJwPo*1g8_ zszNyZN
##JfAm9jTK-FhB6GX#ykhfAP2qnRz-!Nr{vyB~t)uHBQm1p0UB*A1vQ z1Z-8;V3!T|TTpz+n|vhD)fBLT(vQF&lPV;TwGgQ0J_2|KKW*&J0kOXscRM!X``f_A z$0RB6jpLv#f8y`23v~aOAt?MVIP!Xo)4G^r$K+zChP;+PO_Cs;&`r>Z+gH|`!-EMv z@&#QSb zQ=GS-=h0h{hi3G>JK5ZS>Bj%7-1?6hpTV*JYwae1p@1Gi0)&xo=@I|TBTNEelm?8V z@sa-r5+@IA^TjQw$OGH55-utVCMHIByoyUhV-pz?CwnxVcf0TR5PJLi2L}Idm*zny z(AI_!5)tveaj(>Ps#{IHe; z07w)NbC!VA2kA_e%Z4ac`Y=e<%i6 z+FTj8vMGBr`3vdF8@Cy?moxw6J->f{=SBFvI-cIs)hzWOF$69Q*w{Bmb zW>fYz=FS37QECf~IFI*p&IeP)676*-84pz?fO%0}@u-Pp%78BW#$b{{U9PuF@864M>l$RErJl5} zSN;JbLn$wKwO2u}j9LWQg+!FLak~FPUdw*s{fJGzzO7$GR=t6GF_a9jnVY@(G>uZ; z6ju+`G$iq`n_k#E7W$@(XQOJn!@)PrWHNc!brc9d-8_B>E`F?g;3 z7^v{1D=HU+EVykNPz^8C_goyIKmgIs_#3_CP*S|7KqfY?RS2# z#M?vo%q6)R*tb>alwNp&QfNV$ggxMiOXy8Cpy6)NJf8Vl&M6R8@JSvKLF!3(s z&yTU`_kVsqYEx7{j+v zzG6?~ou~}`et-2O&??8JWsad=teJf2XP(h+0uQ#XGA|LS)bXE{&nFi4eD;P=oHMX= z7_zebY`?1Dl-sPTa&&*3(UiHX8ZdrHO4ScjQc(I+AKa|@X*cIMtvgDEZy*z5n&gVPY!2|P(YVvPTh>fZPL2w_sTY4pSaNQw2xvWus zQ#AgGS-Ke0~_4;sXTD%WB@N<17%1oFaa9vY1^l#INT z%HksykJ!?&3(%+okd|4duzt7g}}FKKoC_tPxw zg5PUu{iV>>K*Jq6Bca2Q&ca)vYDSJzx11kh!RKjrHx&&Ptq&`vhJF=2WXC;C{58&x zCu(`wp+kHsB6i$<1#27{T{;iG+uYS_ksomNabdP<_&s$sxBeFm{0BE@5z8h6tj;f5 z>e&Y61;8zJjjK=o(bh#;jwWJaHkO&TiJhJB%%ZSBxN`m@^qSYqocigL5CPf0hS5hw z!>8A#gEmD+e=`8Px(%aB>mefu1}8l4X4BA!#?&w7y4GW z^3~=I=&_Jq=nkFr$g-oRGGMbwr5;uEdRo)@&rV~tLzBqNn#}33z||JJm{^zn{E+2J z*DAzv-150hXj8~m?LWhZmOx+B_-|KM9#Sjw03|TZe=V}6J$w77Km5hb$NfRzxg+_b z7?G63Jj^|tgUP=xiB*@=5uH&FOx~-W&pl~6?VWxgREqr0xy$$A8HP&8(fHy6JJ+{Y zLx2Be-}!S54(GJC-yl_AdK?4=FNZi?`>7ypCUQawel8aC@qz4dN8DwwjKS-(**k%! zHN^j_68)nqU;mST_6yRJUVkBBczGe^7*@YRJ=K`FxObPc1!@=R#~H;6Tf9rr=4q`B zHYTc)eBx++V~>|P+0qP7rot36l8#%@ATO2n-_8Ig1etl~gK&uOnShuBR^rSfd@A|V zQ1k$6iU8c&m^`ZGK>X>augypi5OXPHHB$H$ur8MBHRNhtYBiR|@MjNeoauMyWf`#x z?bJgL_UTyV#Ls}h$(02jV9P?-&FDenSEcDndoGqgtpgok z!^(c_{&yv5*@SerZlOF-B07T(@z`rjy42)IQZ}r{PQyJ;Cz|> zhOw)o{0oMBe=ViQ)*DrdM~oDkzgjZwd`ms7#A8l^MhsZCW@aZWWcesL_zl{W+vNyE zg$>Ub-Y&CxtP0j}~c{Ts|EdPX~;8dmHheN@y=z_C~f{WpTKdS}*&I-t-2w+tl z)DcG!gQKiG!cmXlXxDJ`=QspsA(Lt$i(?^MOd&^QA=gMD&srhhc_EUsNKmy%*s(}7 zrbxW9NOGh|daX$2yoj8xl~*lRbSzemDORa0RvRf+Un|x;FV^BL(NQhYbu7`3DKV@p zF&-%~T`Ms^FF|vbTB(-WIF{PQlsZ(FI*pXNtd+W*mtr`}JXFg(9m~99%6u!!{71?H z*2;p;%Yr$}LsiSe9m^wQ%A+gGV@Jy4*UA&m%dwml$*L8pjuq)K6`7S4*&`LXYZdwD z6*$hyBGt+g$I7yp%8JU$s*y_aQheQcC7!dYLA5G^k@A213#$M1FPH%>Kmk|BnHcfT06XNAmsc|J{hnrMANiq5fG~B&CLnL!0|}P7{|t50r#p&j!@eKRaXz zOcfW3G6_mh0_-v=nDltn?+h=m3mQ;w%QFK|ZEk_Tx>*Yi_4%?fAze*NH__F&G5bavzIV$OPASijw)Q`>Vp>A}&M)$^FXdkJ6WCRt3r z!BmXw3( znXs>6$ekrGInM4Saev1lKR-8$IXg{`LkL&cJ#p(Y0`)87lL-I$58lF$pS+sWo}val z3%&pDua$PCiPS}74sCafJBj;F@=05YMK{_?XJK%%nzC1VOIf$Y$-d#7s&q_Cgy}|L z2x`1u2#xpU%T*(_F`FwQ51Q!2wGW!h)wcFq=uuU0SY{}SwLXdtz9fykV0J5$pETO5 z&ry>+fDa^UQBn!l;BSi$Q|oj#S4DR0*Ebwgyyz*yB$o z^5xZ}8(7~-gbB(&%k}O0YyAA=*^W7FN88lcLz_n>0U7faQCm5Nkc=9a(C4FxK)?(9 z6wgwHCM<6-Iw#<7%QEj6_0i1IX?*fT)xWNaQuC10I<4z+Qz2rSJJtLA=89jA7T-6R z$@Mnej|j=>jn_EiU$80KhygM>axEvhOcfCDgtn#hBjUUGQ@4u59Pp<97=t>6N zr$YxnoPU!sfu;!KK)%tcPhi5I_mI8NB$9n>rQG@oC`(& zkPi8rmf0nR-y7daWmM^jh&VvDXIJQ!=VG#`)!$Q@tLUBxe9OVa^HF9Q=)gD3b2p1U zzAMkb3ROXwP9+szmf5D%)_d;;h64z0(!@W#Z+v|5?ts)iwgb-9Q)i%(az<0s7WaDn!u#K}(RZmH54#t`)PW-Da_^_-U00 zIEY>an_B1)c4O$e;I4m8M2!MZ(>+~~;(5?dueJ~dCNBx#=nnXd8e?HAS z#SfI!^!Vu;urbvm&Ny zcaO!2Kc6}|BRHNC=}lVJQUL~a6a`_51T)=#YQbyrjt?b3p*fQbU-q+U3k@qWiqA4O z?|8;KD%`Q>+`^nAseh5wQJM4U&`c~CI{7PnXkaeL5k^W85+^n`(PpVyXn{IKLx#&= znpRR%uQ(NA3mz#o4Ahydqn26V;%F_ld~*ES|M!ytULvEgiA|%Ge225?mQ>EI*_P$2 zvO5Eq%YFUZZ;7LyD_;f%0n!+-FfC~mpzpoKiG9b_q*Z$J$Lt9gw)62n+t~fu40eIs zwXu8@!?!`%J@MeJzg`>`ZZEL#aBAnZ>TphsfEP2jvs8t`D6m#vs8g8EJ{t$u&}w>HUd% z{&r3q9)ny{hjtIwml!%rn~+QGJDaxXlt&FeooY0`Cl-s!MV_P-a5=ex7FYC3!~w!3 zk}R&cKcV(Ly53)wM2wY*QGd0zcab}9ANSuo(ys7pitZt~Iirx=``~{+u6}IpYmR%* z9O>-B8upAlLRBXM+pkioTmhsek39Mk7)tr2mEmbtoKkd{eBTT_IiC3G#rI zA|0+4Ub!xKie-59Y8-?k{w)8EIi@bDw;7x3zsW1@P+PRr@z)MO00LBPV&52{q??Qn zH6I$G07_akV6y4r@}cwR(l~H^ zb1=#EN~3TQ|6ATO;l)j-hyGn>giZx_)gFghT;Di)?4!lLb#X=uSAqjgRc-`Ml#~yH6b3L478~-^`j;F=!=jW41#zM;T~Y~rBB?Iy=P8OV($x7Ev zFNMkB)11UHOei4tXKay!oh$-kfB}i4b$wTF(84oCnp}8(+k~v99AQ(mqLr;%Rm+4N zV%q>k1O!UN)}8rlie(ym+nJ&ueCR+CF>RM%m;y1==?ttuf^=oL7VpRQO#+j?AZyBi zy>vZ#N?mi3m8v0gv|eLI6O!YCOz<^N{uPg45 zgGZ7?V7wyDQw2hc&7G}q?VE(kBB8(oay?aQ%JdEUiQukZR}@Q9=6?hgc{6Zg9qYs5 zoxK8!w(Xn8Z?K@D&d?ySdGMFETv;?k5Q)uf0}L<)zbn$Xchbn0S+7Z`xhROw4kSrl z!)n#7wn=gRWPe5>T4H1W4OJKy0X8RIM~0god`h=2Gl-8$9vb%iI|G$OLd0Wq5eT4Q zwdh$iP#|9HqXz(fSxiVfhs=>#F$-&z;wl@h)_9>i2HhvZPWQm0wk!riUIFVw@ zZZX4Yk&<#pU;)mEgcfI|oeviX{<5Y;0SfbJ9;{VdN{}K)5EG#cD(vRpR<$8q?x^ZT z6f^J5D(`GFII^?-zO1j&9=-bpOaWv)J}96?ggL4*3zAorQFyY7N{-A?H}_euG(^vfTY@tNkp%_8=}1C>RO&kGA_Av}mF_7@;P~qc|$I zf~P61TPU;uC^hbr6+>CWjIh&1F-RN-Ys*f1&)GEi6D*2vR)T>Ro2_*a-K@_uSJy5p zR}LWCs?p?%G9>~ygR2%i6`@1wsG+WUH$52s3(|c$#gF}lndnI~S>Mny?j8|`s17@^p&`oW?jN3KuC#-<53Oa%i?g^o z+f0WewMxH1a8HM&912oD+w#MyKhVFP2^nUnXefD@HO1!QLd1+`(@|#Refe$};NS-9 zB*faLES#1rTd^-nXJK18P@wmEcHfWlMF{8=1qHhlzRnmz!bJB$9^(j`@cny30x^$BfQIv6S zb7~`h^|tgZJ2Z&0^lXWbZnJKsMr!L~^$3S-I7AZ}`vUAKFBxF3e*wDkGcJFe%PGP`T$l$cjuyYY|~JaPT` zb01?sGLi#3e67s~QldAI0mqN}u{tl@w)1x$b8yIlpEwm(xS9q-l~6U6VR8xN&pkZ) zv#M;bIxVzws74Y{o*&D#K~GK_%?#y*Z}izTd4kUy{O;6pYY$1OnVEV!_p7|GC)xXk{&}RKoVW! zzYWaaosA@}NwdbKl4!QBc z4bi1Z>=Dy4RJGl4J$Gn2`_=l_DxDMNC-2fYJfoQEIKNV{YvH&^`&c2G`i1Xp(^fmZ z0CLd{9XuCRlW>~ia==Zu#nitcF3Mya9+FF*@Km@??9VcClX zZeBc-oqzFHyur<}u8b1kN829S>aOUxUF?H8(P5KN*xFY2s*l9bW3+QI@OVaqJk(T>OfFX^gR_7lY5`qkN8&~vB;paLtPMBS~+SiKnYN) znPw##%aD)N3Ol7p_T1D3SZj$F@k(qFk$?D{P$#>{3BTFt)0aZLG-JnJ7J~k2!MjJ3 zd&cfFH_|llJsK=%MhV1a2$2dtqlJeA*|cv&z@$iz<`XNAKRTgEganKxkGCAn_p!BW z(7=yFSQ$(E59pK0-<}~D5M_LA4colW0HMglKd!NK-ZZ0^C|W)X1PUHe0)IMgy-p*~ zluJJj9(!aCy?6hr5%ZgMETz^%uT$|v_s9vCUn=7Wpz4P~EjT-O;?jKN9k5IJ1`DP^ zC_zBXm8H1zp9?_~StF}+RqnA+7O^9)^NOT>`bFEg*UIpK>Jika2AKSQGcm*Gx~Iwe z%52X|>=$$iFz1kK0n`@53$cUi+}}EsN6Yv`8p19;JkxbH5cZ7JI;$GpT5iDl;2Kyg z9XA6K9tQ~B-4w^Y6awyY)4;EU+;xDpj~}O>@|=;XIqzWI>eW)sQnRq6{HACc2a}s* z8&_5M{Ep|nfXt9g3dz-IqqEdubXi4HolwkI5 z3wGNtf4$c6T=`d*y(pi5ru$(k>litRifUCx(Nie(sOp)b_pl(OZZ53Fqrh;Qeok=% z;+myHb2%1~za;ZcM#sLRXu*Qk&k6y6iJm+vpkG0@kqY}0eq(cfyV{a{qnHOX<{wA4 z_RCE_e%HOSi>9CGGQi*&%D=}PKUIkMy^u_C5fL2hdtcR6;Wn7{Np<+?a1mHf;lHm& zXY~0%uh#C*BQyV`Ey>yPK+lY&dtPbX9?BRedHqc>Nq=*!_|_G}uzN$$I zkY3w$27F8VvN2pe2V8BRPaS!R#X;LLzqlK{$KpYw(_0qXJem}@4CnW5g1sWunL6j( zEgpY$jCV?8vlSD-n&h&Z<;pu}mn>-eTkJt^r5sK8x@_BA1dUsk5ytj-RG_z;SL*f# z+=jkgv00H<|IQG0_Y9d+JLA|T3KHl4KJ7&}7TsA+%AVGBSl$16DVAD|-i~4iMPojO znwtYR3mxPs@QTAT?5De8q2=u>&c{9fqV7l>O%BI>dLUXJlifs8{8ahh{i+Z1>>M5c zDc6>APAjiH)HZr<82{s4y?dqkzsQ?;A0gtlVvkv1>4?N3Cl4b^=K(PP8lnOo=t#EX zL_+^};F)p)YKw+wAS{$@Q<5PT5F`>@jLfPi(*Ps+G_Z*BlIH&*D$VNkM(%8edVm)z zFEl(dIt=J(Vl_IN3)R!|6HlNmu!=`|UO=?G#Iq&Q{t=8c$C89R=jxbOBn@2l7ix(mxN3MK-fN`gyFskdZCyKrU*+!wR3$AtfcJ4xJ}8 znat)%+vZ4SYSf#w2+C>1W4!|jR?tjN=yi>brbjkvvX-UP1a{SU!u3r{?)kTw)_fcs zOpSO1lyd`pgMEcsbB_nu0V%xeYG1j%%UG*bQhT2cU+FWsV;x^hxMcTB=peEf+?Rq; zX(5p_#z7z}Sq&i^;cbRcnG*8Ql6y^)SdmoPf%l;(6lBS{w&2VrxIwX3GVJ;-lXIo< zW+Ad7g)7Uv7XC^8I|Ae*hKWY3!YuKLxXU0%qx038Tv1orY(aG<>(7hxmBRz`UPM=a zrw6YvbvKeWp4K^>B3>Jv;Va{NLQO4We4l`RsHohMR_jf%Y{Y7#D7Nkzz917XDKkGl zbWH-Z=#lPvK!(`nB*?SndqKqLA-Ez$M+2XT8RV;*=SHM4fNQU{??aAgZp2CJhB`$zT zE+}uS?qh4$OMo<>w9d_;3FEGNIE&VrqP)EUK{F@V(F#L2aF->Ml!P(-`bPC`6q$Zb zw``?06=HcrG=rG^Qs6o{`6z%rQ{83VP9I~r{xIzoM!rh>pVJR{?RE0xODbm;?a5gl zT)Z{xjcnp<%=}cbn*w-f_=1AcJpL`3Pb1XKtmLc-!$$4G_t!V8FIeTXAeiI-i=`b7z4g|t<3$M@PHl}Um5LKju}`d6dV-lp>0RN@uH$tg(E zv3BwT18S1CQ}gu7&`%am(N8tstko=^%ltfuH6xp`u_7pm`MT6&^WJtnHb@9lO_aPi zMmYMF+u+$hd!^A!EX&48krNGSe${7wS?$b@hD=@rh!H>A%zLWTc2dqitc%(iE9BRG zN%K|Q-p`0B-?Ah{bXj#}p~F_;nw(V()k5ELK4bn*La&Tf`_fy^335q<#R~q`>1o4g z1s-z+)`8Y?Sy5_3;pID5^v}KS@j3b9?cs)dbv4JXqx3E76?Z#d?nPPk-K0{#;_eWK z&1viaDnWKK=)9&avgS`orssF8pQ_(ndvUh@%gfu;GiqPw)yzpCp#L@Y7wZ`2(m!15 zZSj*eKyOZF)~|fAm3iaaFN!RceJjfUQ`)W^nl%p!m^H?x*;kvR2}qgfTV*m!>3H`e zZ)qVj01Kt0iKE{l-FFjhpY~NhDzvp#crpKg$e#g<-@mb+AWt2NRi@Du4X^acMlrd=h|@iKoIX!5FsaS;E#F6hg0+ zfpr%ulP=t}cxVE(9cTNg$C;i^x2z0fB+EsrtM7RrD;IZ$#%M1fdD{ z1|5i_ysic?W6oRV!CePz(0zKc8+_X7_Cxz@bg|9et^!vRR=$24W9yr8Maws1$zLrB z2$}%k@LABYS|FJV-zITayT$I>x>@BdO4Wb9@iNzGg(@|;8$agXot}s2QB0P~{!?r* z_N3dw6ben2hJ_)L!uHn|9@h~EV7=Zt>{fNmb07*d4$qH#UJl&s(*bS3|nhA z)(Uo9`>xY`!ujIyNaAbA6%~}2;73EfjGLT=T^uU(A>07c$y8R z-YLQE82Z1cR%7s6IUgY`LFLZ!3obq#U*-Rbb|sF2KrVZ3(>Jxh+((cb&c_&&z*=d0 zk=80Y)k>1L*XALxQv`p`QXyfc%~u!N0^&q}caGK+WTKarbl|jI;a>|F=xdFu zef&M!I_vJI8fRVzm6}-*;AJL)2!(7Nw{s)PU#isO#0X$nCj$XMq`hS^rVk|uRLK|^ zr(J7HLL66tIGMW11u}(%5+(?0POgR=pO5TF*LD`^Ip0uLn5nV^o8VZ$ngQ7&JMG{*Ec~Xv@ zqZ`C;HayVXWqC(6{oIL{%CFu=oO{RI5*;#<)rIL%6Zlj{)w6(-ztC|oj+db_b4e<< z<)e1+&5b#S@NX{n9_8Gwt2}3iiyygKOS^je_sxDmkmXJ`Lu#Ae1+$DtM$vL}UxjzV zKi!Yy_u5aXAC4@`kMFdJPq!u|tk_-@xUN!j4I#5JXnXKm(m9WNq&rEAid5$Tg)E4l zdAiRN#*z2#-#wQev5nf9z_{4!&n``Z zJ4AR<8lfCB6pfreK4KVQiM8ZJ$>k_p2G-Q(!H}MXtX&<a=;Jn5n2c|t0WV*YsKLq$9R}q7(UaeBkT0CH^<>EV%f(ito%R5(oTGUzuDBk%4>l;pP7&D9 zxKt?PC`&vwq;?1R2|u~KnzWim`CW9{H#FUkCx?#U#o!>@0Xb@cfCUX!b$ zIaPe+@x|i*oH_X-C|d(WQ7Xb7E*7d-qTd6PV?ra{|Hr3TFpc^bvIlJc?y#sS*xbV*i1bAbGT%f8zfpbrp+a5&pX~Lsb+XduF?`Pg?r1GZZ@&#&k z{g!AD!aRI2uqWCDLrE|uR}8tQwb`@Bk)b?fP`z7Dvn9-&2;6EmV1=CK+_UZ$xh6cX zeD7pQplW7c#R_Xd2n(z@7ff&>B*OCIDM66&02lfi-V&bvmQwy67Zf2-@t=^mCK*by ztZrZtHsnivBoKlMLDhf;SxyTcRO0K8*aPgCeu(jFu$TtR2c>(@IIxG;QlU`8G#=SJ zp$eizEfcFGjaH`?>MVx*ypRW_Dtz+s$64Iknd5ZU6{8Iw)iLJ~79_xctsaE|TaaOQ z1HkIm)rRFTe478G`!IsF|4PznleU^)@^N%O%=so)j<+PtOgd*Xkd@4%n1});$X!TK z!C2#1!{Srp==9=f3u6eL9{coj-r&1)fk8H(=9=!l!MGDE!mKmo$bc&uh;D0UVJUGB z2=0*JvN~eCwf~ey$4pEI>j@5mcd)^LNIYDZid7A7eB~pTUXOLK7Brn=TjpbaR+y-M{u3+;PznZJIu(}jaq5xhT~Ag{Gd z{~EI-nOfHjtVpf)hIL+bnJJnijHg@lo;s@ABO%J<@`s(y{~(lqU^9rtf#mSj_y_e^ z06gG+8%Kq0{p_wk#rwy;buRx@1@pvZDX6k3O4if>`Lw9)qDhkmhoGHxi~zEIAMYfAgTxq0>x#TbG*s5wKH;QF*m4YhKz{sAm7P_t1Pa0#z z-BzQo|6(_@h?A?dOZ-D~#%$jJS^Jjp?Sr3C8PD7L7|=n(;Ker>S6Z*qxPadTQn2Az zNCVhJ3&e&Aa4lgQ-Yg4CLzd`+-e3pAYz8+6F1t+TeIaYJC|xNAk6_E7=LL{9zK7}2 zACplcMNUnrxNfaUW9AvddX5~x&u!glFmZerKUE^NFsqGPC2HVwzXmzH$gAPj_qw>4 zevy9zsld7{GCAO8^`*uFiF(w*kaC%FD7e>VR4uT_2SXYDEq@Q=Q-Wi={M1nHDo)&B zY+5;(Qv+0y1bkb$(T0;apJBQuEz3GO)4Tv4Y3X?O`x5bx(lK)D9t7Q^A*e;Y=Zb?Q z9=p4!P@%jwxYvGHLl`PYEgAZK_kg9{Gw*#Jb=Y6DReg?_{xI$os+~g+Z;3qB%4k#v zZrEeBK<2W}6WEeD?^WPrZ7@anx{KUe_j4o=w@@a@EsMqhO`*cCJtxJ->i$0D{cAPR zD42pHrMkBdVkk#vo|_5^iGoxcW7}U$kKuW_$!dTh$&|vT`?fQ$0I3BzZO{vLk;*Hi zTzWn`MB|cSKOP)5ujrq{WJARKlr?3EOmOnD1@eAr_2v=>NQ2&i& zO^S_(5FcEWF(OP4KYjly%H{xMm?gj1qn0mi4W8D&6sD~H$565-lWRV*wJd*~;`nuo z-H>qhk+O1LKX*|__0)AIJxm7!3F#IYdfyIWu{{kjR!w6B&rFl4!N)`PiB@PVWPSyUwGv(L=UaExg;~*?Y1(L_4pl#(@9^Lv+NPoz&&7++k1D=hT5V)Sdkuik6FHx@)_K69-BK$K^? zu|ulw>!io-8k2x0ZVw!*Mz=H!+F20D0&tE9_0H_IlsCl+H9oC3E@ePcyv&2{EQg^K z&*7mPRvHH#53oeYwT~c6v7B>)AOVhg{hCF04B&irb(sBRy#M`=A&&BR=wQ#$G0`OD z;!75Cxq|mw*NUwZ~h4LVAy*JF8~_gN@*63 zi%=(GS-AGmH;@boc<3u9^Y4Yf7ziSC{O~X5{N_~7yjv3fjRf)NO<1Wy88r{diSE2q zqUkZT{gL(3fbeB7gL9jyzcF(7X5|L9xjIdC(py~4PO{_LW$hDhQrpg-t5X42s}ESE zFkfqPHqDXq_EjVrHaz;t?UKwDpGpWn?TvEz3?2g&rq|2=sS@V^4rNA1GoBBFUn3Vb zGXsHwJGN=v5?cjoF>|}w{}8JG%%9-lJn?A%oVNwOCiA{$O^B}>{+(oPkg&|RgF@h^ zzwdf}7!;;_70yP$*Hk8OJdFj~x^XK+twaGe*Ft^_(*Z3|PaUKJA3ubi*bD z0NeUH>XVM?Xh977^xbK@%A5(h+t4rPLpPct(HYv9Eu#uSO z&;T2y{%s4$jAgCj4!V>+Supp6&dbWxO3F{4sv&?My#%XMpz{m14J2@~pw!{O7u}a% z_7q!DU|E}sZ+BoX&1E#zLX9ipwFcYy?$TkJ42v6{{hA|tDZ%dr@7)z31F>!I+`eJ3 zv>zvlGk3Aws@)%y_~bK9IEZ+V1@K+NygxA*w1VD06zA8_RKhSo5}U{(Zq%I_utV+s zAWQrG@u`$%3%kk0&>@<55Q||W<{mAY1Rny*5IE-c>&FM@=3#jHdanrh^gr-%Pm51? zxi42j;F53w40xdI{R4GS%+IuHb^Av@%&P8MMSl@`#Wxqh|K;Lkxvn5#vw8x6@pNkuZtQ_;^J#|5OaV2ej?XhjWk}D&p;t1c%po1y$?&DR1*@v zm<(jS=~3o}Tbj~I^eiVWIG(UlFT#$sF08~|d+fypKl55Y`4|BJ_pnZuDD*Sqr79L~ zJ4ns2y0dn;E`>L;4Fb~oXA5x^iP7s z3QF==kMsrl3URAXZEhm5aGOT^<6DqIr?w4`*^tHOp1A@DnK2%MS75Rr^Kp46S>_?% zP^f3}Z0ul+`D7d4j}vS^yWkkCp~5q}SKORJ+_tvzf?FnO@|Dml>ndN9(xrn-vUQIh z-Mgvr?4hqkx+ec&jZ?_yQmJ?@3$y;y&aQDae6DBjkf*pIqJtZTNMtAp23Fupv~#G6EFvrs!fJ(midv%3QPWFilgBZMRO=(03DpgxBgV@^DN!n6U{#hpKPd>i$Gf zL^p90tWZe`!$BR%t4r!OnvXEBcv@_O{-d>ez-z`z!rx&RrdaMVtb z`{ih}G+Ww&NuCVRtq3qm1B;aVs-{*NHr99p4P)Zo2{7GP!wa%J-HAV^z zq;aVGGomR!j~gx#83`SIqv>-;52S zn`#rcU7&c4t>YTVcsd|@D_Il_hT1-0v!IBm-NxCHTWK8J0TY#SS+!YeQdyw{FCGes zJ`1N{G|*D9*5c4?jUnY~<8>Jj2ah(!j#bM|Rs{C^AAEXp_u!A3)=vdSqWjm!p6?SZ zD8wlgD^5HyBs7Cb>=3_|Omk?WL}gEMJ!y>xec!eHO!LYL?XKhriC19b2g1jB3BTMn=CxVAn56ipYzD<# z01jL#x2Rtq-}-{qhvugq$xuwSuD)6s6WBO%$M5N>4WQl@;mf zg8lkU$on;0rbMBeCQYFZwtbJ8{9%;NHdt!NW0R!4E_i1{oq-&t!e~}!`Kw_%w+ivD z?Yc2&dDXdr6Hovdlb~`9PLQ-2bC-cH$?5JX$kLUX5Z|1L;cY(^BSONmbFC#&5R9<} zgQcKMvopx}BWwO{l-{#ixg!yGPBk8|)RerPt0BRzFG?4v0iwjlY>-*9@)OS(`HR~^ zoD6>s3?5S`k}ZkoGil`_6Z}4gU%Z)AEN$2s&OUCHd?_fMBKD71-K}TLP9cdp2$GP* zU;;NAK_EB?hx}(_rW8vQsl8m(ezq|SW#TXN!;*$yexoprqlkyd+55vo8m#SsaU|<| zl2JwW?3aJjXsVEf)c)gMhd1$JnGVu%y5o~51xtS|_(QE|9 z3Z>4>#&aK^!{)jB*R_ZVA#H1(!y=0MRD=Wq)RGlMd377T4pVtyg2$OMQ#2#LOmGir z#n$OL?v~!GBX1falZS{a%0YIJvW?wNxqOmLv3cUP6%K;XYmn!tA*H_*?}2cewq6zY z4P;0ZdBaVx1IAt;lJ5#*Z_ zb$ZJ=?!}`^d!|s&Lo@ktz4`S0Z_L>^-bLKB{8KOzXTCGzRmA3!A?+mPls?JFOO0V%^_-*ieZ5rh~D*1O2Q zVgkB!siK~3&_e*ACm>l})H2_LFam%vvD%5ZTYq;agoK>d%3cJ z=DwY))vY%A49zA_xkH)kV5K!FI=%Z+#%UPm!n25HbZ{_IOMwHE@;K&uZ-vn!mk|ep z{dC#0$mhF)yc8054V|c*B+qpynW*Yz>?fQ;rPgC1C@f zc*-=YI&KQIQdQRA1p@50!CBNx9S72RFM2`M=cJ-+-F9VM)x@gUViKcJ_VYyWxH;jZ_nV6L$mwIV zDq3RJ{8CU})=xo|3jPqP&-hgub)iIqnSmg{<0!_3FTH}YuQ{lBr}83;IZ((#+VH!! z(msSb`U|W@GNkH2()(4^R)iGdXm=aUiBDudyUXrgItkaMM>iH6MGwLhN9OZxh2Oug zSbOICc{v`x4rhv_k4H(ZuS?%~6h00v2SLq1BI&SXhgd0cyx=TC90MrUM8qvboJSaj zTLfY0__|XTi7u=78N z3z`w`05)XzhSRBpR#HM|Y67Yyfolo1U1$Q-=xq|fcEH&hu+a;P#5)*^AQ(V$L1wO4 zXom*(nf{l`wuR9ha!2n+-`hI$TbhEcNyn2S%z7u{aDxve3U&m@j zm041!f{RoEL|Qf@1yD@|p{|`$eBr18;1iP$*^>oACB7+SDqMAN6T8LCpzityQIbT6 zaH@tb4>gOrbvIQ(_aRhhEsALS;7}q;cCgq%g=AF4rSL^9%CLR5&|N@1K1C< z9*_V{)`6$+Poij`hm5p+i%vdI1n84}roc|NagUiNUOaL+L}Q4XH3&{Z1k)qL%c+3j ztPLnyVAh2CNr2@5Ko;B(uB7}m{=5r`N7+soxC13n)=I#7P5z~csuTggWg4r|940$7mQtmE{adiG&OBz{Cr*ea^e{z(SpSWb`JbD<%SqeM}*6 z-#Gax5XB8uU6wmi<9%$8>jFLP??u3u0a9jWD3e@S?S7rZtmu^oNxG7+8~d^Uyz-XS zfQ2AgvuN_?t&^n?BN9l6ew3=$TM2nuIew_88yNLgt6cXxD7!Qqz5pjvq8fEU7a3KZ z?g;3iRZn`V)mnu<*|ktxmkh2JZp*hRdjv}gQ%ud2;#eG*mc zR~2EJjj1Rk6eRHSc>y2yDU)A~RtLs#X6z(H(M)2x$W3yyyWoZN<<Fwjh%5tE^Bah#sA95}2#>eDZw8el z+RvIn%_z2L8KJeety8~RA2|d6S_Lm=G@0df#6^J37ov+<7WM*M%L8$pmI9~4`zKpP z*4sygyZHFJ?mj58wlIG0((%46jYfnG9X97NPQ_=Sc?3h_RscL8(-R1=U}AARB7%qr zU4REMxjO0a!nRwa^7gHD+Ga+3Sq$daNEfdS^0*Kj&Vaa6z|0uw(7nn>1}dUNMSh|R zcX@D!PJ|8}`zfB5{KksCy`A#~?e0kXz4y^B9^Jg`$v#&(6n3N}MyqA5wRg3_nq)xC z;;8ZrkRm{bUt{!)mLm@l)qiz*&s+9hh;DTop&GO|t6?~`7kgED%)bb?1O}ajXo5ND z!p?>DmER$nB3%x@8_~*La)JG0<+eL}ooAIB4(xC6jpIZ8n&g`sn1ut;GzT4ef6q@S zS!D1Qr7xU)kTW=6Ua{-0N0<9*Xa4%&6&;@M*CZ1&{gc_t4<6VbdoHLi)G*xEj%3F= z{=O9<(sk{6KSySJ(t=xAOS2EE$#6H3*S;1@cYWY7l5)InAL`V7yt4DfdD`#B9M4`3 z&(W>*v1BIKsB*(sIg0dE(4JD|3;&oC$Hy=i!;FJR9<`Z=^n+tXYEe|%b(!IC<)b@M z*GE&B#$O(ey1^h@3QnOH0IT3KZTQ%`ayB+fwXFZZeNy6kW$@{xVO!lRA1@2@`QKKWGl#wVB8LDt#3Dqg#auO*O#fW7jT6jN3Y!#gD8R!wj-+h6HO27d;lvgTYnRCsY3Vh zs`Zhw50fW5!j1pj(SLB8#qbE0OwshZW7x!r9TOT(1CCy4zjp;HpCwJ{tIbDo^f#Zz z|DMKVwmZ1pk|WJ*&)qJ&2s%%nF+-|mu~(Bf%s%^$v2AFzYshLEcAB;v<%D*N2MEpT zdx*U?kR~O~mMC^Cw?U?MX3blG>lkdzuYzsQu?XAg+&7AlI>J8tIOG5_6b(Fm3KFA% zc_@e^0(5-wuH)g|j~B+rObDs_gRJsP5e%Z5@!&BMAz9xn;gm4N9`Nq^TvyWl_%{!& zUD;QNkSW`F9b7su4WjcIH9zl(0;1Catf>42i2frH4{lTan;W8_t_`bY;fD(<6|w0O zJI8TvY#)dAO(+1PyYnbnNzner;r2>wEyM~h<2$Ny7PNU-BXLmtZG zM9TG^2J9n+_G?N5sLuRbXy77{JpySW z+r|}rU2sIN%;HsUf}XmILH}f|SaM($=`h=u&%US#^_C{v>gIJeK1x-6s(1FuD>v@! zm*t@g2zN%zl}K2QSm|iJtGsGP8kG(EwYc)-8sP-ajSQnU6v~^d%aPVC&q6G4koK1= zUqWn;_%IH`z5+VPk@qK$7Umw!rdW#Fxj#y9yK}T^f!|ng0|$}FK18@UuHF)fC^?IK z%hv5BCdy5-k87@NT>g9U#yIR8G}31}&wlxy^5>mTm8jU7b*E1+A-rId z*^CgC`Gi|94==#1rb;fWj3#fk1^%l#Uw8ze2KNpN7r#1uL@La@8}JU5^Nv$2M4U)I zbBy%q8jx@fva*0sAnyu4-mIWhtas!n{oBFPo(+lX-eO9d1OeR4rZUcKar%W5A-$h; zX0Rzs8gc$L2@K;`YLl~ea*E_Ls4M~7O4C+-e(Z7N{)4ex&7`?pKH3l@0@<7B?H z3Dm2wt^6+-d5aA7tJ>FI|JWDM|LDU|=qoF3%;Th(k2huaWj@9eMuDTfzk^vTHOIIw zenjSeWTo#o?G`w1FDffX@Uu4DSB^dp-1wwZ`=M+8Gg0jW0s}=gV^7GQzwo5JVb#|e#@eiisftB{mCC#_Zs%_~IQG)P zsa!B8Gp!5#VgJ^OUc zQ>g#laU!E{c;&Il^}$m}9g784yqleba4{md-wXcP31>BxKl$Rl4(so~KCIi`em{Hl z`@qH|c)LCKA$tGUxbcVHl%rTzd59t%@$b~GzC}0t-}vu_exc8$rnDUk3(=9Y2Vc@=7CF| z43WG)J2z*R|L8H*Ob%|6{NJFJim<>frtcHInYjd88{^P;q>ztXDX^)SI#+PZMNAKC zY?7^^X$JI7%q|zOw-R;_!X+&epL!lA zvQh3I@m**8g%Y*V#f?j2J*2dEX&)zqm8C?>Fa;`Xh89(Uv*S;}^jvB_ zHB6PRM_eUw3|`r^)*F+hPp$WBTCjCLguc1iLrgi!Ufgvlv$iaYdY)hq5SfGEqmA zHj$Kiww8i;!Xfx7CMSS59{me>ASNZf94U}mU?x}QS7M&xttIS5drFRt<*zoZi}N{p zonzRPC;{!5);hz6SiphKDkNFr;-&V(2mnTf0+!H(7AK?J{53#m&shw`)(3>Z}vP|V7Mc_h-CmO*m9wL4HAFAxN6dww{7QR+v^azRyBY}(zg1F8IT z9#4AwAJ!HJE)-}jjh#Lg*-`%Wh1(sTfLMS50BpF<-<^xGKTbznxFdPusZw}3hOn&6 z#p=j?YE~1rnx=bhh76}2<(s*iEm?S7QuI`YUlYxT}JBJO~D zHS2b+FMa=g_LsEJpM=E6n0J)#AL868sGnd?%oE9$Z$}#z zyvlw*lbF&d8$U@RozuoZOF6dKa$_V`3QbJ|S&MGbvYIV}UHVOq`&u$ywWu>`CX21C z|Fl;nKY6dxzx}CkQvnh4aTb|#Vt%~(rF3Jdg}Yz(f>Of{Qvzi3E|3-kx5YW?gPVo0hl|p6?I5_Sog#h}aCCtF4><^Sn{2AfPxUVHZg8WMC> zIPPWH+sEzMHf`5#+BFu#(3ta5pUlBH;)lce?{^A!x2KO=rH9|SxQ=0V^ESDKD!Qff zls^toL?ACpKa8~0$WUR&F0M|$_dmypaG^=exTk?gsmkb*p_AhdCoX}&c^N&Y&DS#3 zPJxYXz(DfRMZOYI%yn~ndRM(>pcK#3zQ;j(Y+G34m-+8)6fAy{#FFnryKEox@EBmT zj+-c4s>`eR)i708{;_u}VN#dpDdTxwlmayv$LDwX_mF!r7#vV5Q3khgfoafy*U5ZE-R(W{gcMG~>>@)9URn z%U*Pi2|ujR?~_TO(x=O{rfG5&@cFXYLR44+y=$6tOfSPlxD3BEvR=q0#(*~ zfBtpLy};vF9uS`oqz7JS>9r(qZknxw98*r^Si-=1tpDxcvQNi!$W1yCV*6ngW9t|P*p+5K5CY$j zUzkATi1fQf2(FVQ8)pbH)~-Fo4<_wf3VJ`sH5Tf5>YMYH9``}DJx6-773mds7MsS* zhsAFyo>*_cF;e&qlB;q=FBww1pO%s2Jz97?c3|dT$kYH8++*WtCYHxp^b1I=jkkFd zg9g1A)i`286B_7k#4#Wt?m#p!}CCkH^jT?ZJyvYHFOa5&dhbNPpROwv6ya{ z!mzhbe-6xH<$RRIK2P&adu>h%I6(RNUioY8ccBLw{+Me`b-DAz9PZ<{ZyJGq=(a43 ze=}`Ryc8JuJ;d5mD*V#F8?Op}NOP!A-anK+`SZJw7$?S)yk#T_eN3G{D9N_{a1^)U z^89?Rv)~QW8~0Nj0$@ga2>F9BlnsI)gSgoV7S_W-xEa?tn{Pg-3Hgz7v*n`Y$ps&& zO@rS%UbMoHTE#TLQNJlzjsf9By6Jl-R~$QGNK^ZEEJZmVEgEp#`B+L%QDOr$l|RDXi9azsiceBb z1|TX3>ak`;F(%{i;;(6xsPywr7Z5-yXyL~D?F;F%@{3xw?Dc>)`C8#s_9j2x`eQ-` z0RV!UT56fn@*^~G(L)`XSSFBR_{EbL4`HbXo|aBm6EXzs#SNp-uD)P9z03!-5%Lb% zG0`f^<@vfKsXP4Q3SXFBP5z6aOjoNTiR5G| zo&n*(MSnFhZGQ*BlCA$SpkJ57S$%%b`-10mL`8lUUnhazq(xYUUFY-B2x(Fh@lSL4 zS@Mp-p`E70s@zc32>7-gv9)BKV61 ztfxg@Md4C~8m9WoPtbvT_4nxNL-%TDD%S3&wJiuSzXsPT5jf-xYmKaGY^{3BaJr*? zQ=2TuDogla; zgx0zf5%VY(6I=TT1LnskBieLPZ8bX!x(!j%i4)jErh_8wgra#+hN3&Z22jWR! z{!k09jZ3Ct#bSwKnwXa4iyG|ovysLs;_oBI${N4THIl6BzU+aW@Rfzab^1iWp9(Pt zU|t?gzP~`61dt&W#6rq18z||Mg(H&M-nyqq{*HF` z@OE2o$@$fCpjch7UZDU6`;ijm1&>#;KolI@)A|VPOaRNXI0+&ErxxtlpKcv#t1hjg ztxKC&Yca{N>oF?nz2aXZ+OioHYPgQc^1APV9l@)b4?GY&OxWXOZGS4lj%A?`z|he~ zHB!p`7rBaTLxWs0%F_tKq}n)5wan8&GVjmmp^;dDHwEI##HKC8RBR#7M2t0 ztTTp(8_+;xD#(xk;#>g4e}gVl#7#gP;(7V%>SR zrq9v0qb>rjK#eS!5U3%_(v5+UCh|g)1HJEH4}LtIH{e09%t0GLq&-$qb=O;04-5Yd@=_Xj<2b+}!WU36 z@K?Hf6b6a|MEYdR!farfzq_Z)2V;K6|MLbVUmv;R4(8T8K8qI$f7rNn11LbI&vyx8g;YAS9v^ImQpBclZ1H28@jbpGcN2{KKN1{It>N_{mpu#yO=_Tx^x}3t5964T2!qtWFXWHd z2}GEPE8Wrq5|Z`es4;(?EU3?MkaX8i>y}hH@4(V&KLT8qHJl~FUlkG{k)#vz@siB3 zzBd)#Z7}t~wCIU@Vk(^NpHC%Du=&*J@G_vM*;@;O*!v=ES<_oB86)FGp9a2}rfG}G zVs^Luq*q@P`C>`$x+ADHt?~?@Q@DB8SxaV{Nb6gUg53zykfR3Lz?Nu6IksuefF z1m{Ey4YR4UJ{ksRe%10ID5} zb-16lK|A8RSNLGrdjRT#J6324^`3A>4{!p+yI+eEjQ!0ADXkW43%foKVDtO7g7b&y z&eE)RwJEL5j_wqg5FWg;-ev?*UecF%7OVQ? L+RgdXW-(hft*(dWXxA-?hSmsu!DcQAQ8x=R{W){2_udZ_ZFLe1ewoBDxGnywQvAL)Is2*MM~> z17=!nv%6RNC5`?p5e5>Pw_Alm+6>QOUOegg^U_z>vKK8pKFVVCcYz7a+wcU%G$z-Y z?Bz}`jP6MI4F8V~CK|Ym|GPqxowtf)P{cpKO?;lO|JXIAm7t9tr4d#qabQpYqupw7 z=xU?(o6BF(hJ0C%Q#ex78Ga3|T&#TEF!Z{%fA)ihgf~iYKoD%d_R@^7X0E7pOISy} z!>JfhW<_z{m3^}`{O-!e@^dtV*G$Yq7355otzQH@Jd_k<->U1s#yck>q-8`o5&C`dY??iIXR?mikuqXP8EFd0Uc1F^APW-Id+UsJzJ@#^Uoi(SKVnhQWxOO)hEv4=I|HaCQ_1 z+;{o?J^Fd&1lfUDPi_=UDYlvcfDID4GDqP(aK{26#}}Qke%sFBmmI?lg#>aVVG5hL ze;)~7^VADB4;$EKe>njZP&7tcmG$MN11ZLYXko(GSlMK=x3p=us5j2VZGN}>g$pcV zH!k`9WFob>uaajc8HWe?ZGXJ+^c`UV{Y2K1Mb%8&D(-d`11}cj-l>)QZ)Z5*$yb1? zv)ScuhH+5vTOVWAyDq}G&Oi)`pv^_TSQ=3K0w?GzGX_wUCckTcx~zg_s5<}w3RbmV zR)ICw7RN!t80`_A_mqQ&mSXz=WlsAqXehVNZNB=k%AQlK>X|RKCIJ@0q>iLRByh-p zOP#MgMV&-JZ~B%g3(G8BPF6935DSpQKd#RkYFZlFycAIJ?@wPn1qAlZCl4CD%hulz zA@`EyN?yRrRA{V^l*@G#B-cT(cb;_UkxG7HIYQCdP1&WTu z7{1C}zE?GT7xm60Uy;Smy$j2?7vIW}8XW%q%FXoRg%%O?bev=5^HKv38;O8RU?F_N zefx7JSxxj}sbf#oU9C?t8-7^$e;L~Y603tsQBHofPl~M3DY=t0>^C9EFDVyhwKaFO zElJM_d$1VBU;_t$<-=Kw4kV9@j zr;{S?)Zx{y>8tD>S4|nQVAoZEm-L%>zif$g`rP{OKVbEV9u#BOxt8bo_Ux|%=rpPQ znG_R(ffwbTnszfiBQq;I8$i)A8&kC^Ai9#$vhs?`s_JU0RfQ^1xu^c0AeJRw4an*0 zc1QKz=s%-U5&mb#c50j|0Pg{K&BO&3=7m$Jh`u?1qo5G3NTw#XRc!SicrMVuo11AL ztsJ`Np{D<%z5aDN`e?QrU?dyt_ktth~Ng7P>B}OB5H!zl;&h0v%NRdxbz_ENa)U9 z0CY4F*1X6Uf&dtqoiz3e3EQ?4-6ZPu|J_>-qTE_d%#J=z?H`|2IdQO@(F-!YWDFVR&t@~0EXm=rVRpgnOC!llX(^=LVKHqNCNxNnRm9p(Fb z=DJ4?nCB#1y6Zri=cY-7I~^N6y2*OXOhovCQo#a}$DyzgoioDoSz0k?3LL6b;6kVE z$+36W{Knr&-P=i5R6GH1O7C-8X5Q#jm|`6Y5Fpg9@74<)GGl2KLqOwDIBs(@3+^rm zp(QGsy}OBE_}loFt~AUUgk_)@pxWWzToRqi+3*+@MiR3;fvHp zi}DMPudk0^T2C6xBe>aQF)w|JKjWXe*IzDJ7T@|hZ8laadws?rxb?@I(~i$rxm7Fe zpYN{8cFWg9aeCU;LM3bH91G;V{znLLl6>~5l{bX`0;CI^)Mx@XR1?%5W zi2X|Za&Y=>g$eQpnfXwb=ljyMZS1#K#b@S6cdHLWSGfn(RlZ&hPQ`*H?I7#bb52CpLnv^^bGW z7(~Kc>`|#R>|7iQX>0($uGKtIYbhz?b=W4Wbx9(#)_AmCk07Yi1he(^N*0nTJL#WS zn6q3!Ho6FL8`l~t$INqFQp$nVpMc4z8&MZFOW>nn@7+F!a_ufhc~?MQ`MA zv3RsXNPIejJuLSK!hrjLXp2Gw7}=HCcTOT&28>S#&+@Xst{k^?%?O##D*%QD?1E`x zApe)_FIs|YJnGh=UaVrf$8}oN`=lGk&p`|)_1fy(IW*|!AoP=D6GK{CQjBuNmWVEY zOEJ#L>?;4!e$BbFM(E`>yJ9_7Q5dFa;f9`Yr7E=>?SRzS$Sx=xK4!L1qm0}h39rf7 z0$@HG&qJjIOZE8J44D<4FmHiMK8lEIyeNH7`$pby)$+>6*zzuYv@8m0o_Zt$yZTJN3D{L%U} z`!h1L)OGNmed(P2=0Tm*@-xPtRV>=gcb0Zo28@!SR)?*Tt;OjL2glsSvU1o3?pM)C zeHAJm^}5LC8gdrw_XQ|zkss;S4kBMvZ^#~8$S}1yuS&VKG`V}Neqe>k9z-0kY)=|q z&XZyHFV@@+PWaw@F)yvK)VI=D!WX1b`HgJ^8u&Jeo&H6+AVcFrYB($T2iNJ!HPFf@ z+SlTgV-xdz9G#YtZhU63NtLpWo51{y0@at7XqBC&Wf~PtPaosMx=Oa=tRtg`)=xh; z$8za?~H24;x~;WGbe&NdU|70aD z>@1nixI&1o`HA$IN!Ph&I!3`N1Ap|LyhCa~ja*kgx;&&h3r*H#b(e;Xc=$`pzO^6P z_{Z^-@Qy``8AW;FUpcSWbpOgL_P+iH3jAV8YNPK?%R(vo2ev~T_l&D6k*~1uu-jQf zquUBkV6jg$i0x}1ih8=V@Kx+F{x;W_X-@ltor)IYI82<6j2DYWjyF{FZ#9*&NCkQeV)GUU(Y_e zy!|Ble97{H7jg2;KPTq;gs%Cs7$xh_qrkWHra|&oDmf=MTwS%laQ>N08j^i8&;0L@ zUCZ$Iu6pP4$-60WMul@i^n*KFotL<6^XGnYo@$!l&+APS9$I+U0B4xS2|xd2+Wu|l z?lial?MqtsFa9ldjWY3-PSo;K4i4&}(_v3fQcHiLs*|2>+>f#&ZKun8)UY~%D->DX z=8D#INUGe)m}Sc>DYmFfkG>w6nZK;vw369&lG(wP)uoozx5#Fa-ZoCOi4xstNigcwwb&D zD2ffvkmkqI(JGd_$0*_A0&cset+9eEbP?bhmeClRKb|5O9%J8tAU-OQOB@U-UD$qH za>J+BB8bgzp-h!;@6YlAZkC*!&HpX>k+_qtYy8u~(gIRtCMWD`g+_ajW47Lzi{FbT z2ln|ouF=^^S7jU1-W?s+;mjVKi;Mm!N0X*guq$O7%G71oe`q_jz+!jrgtM#ne)z!C zm&+@q556bylR(JEYe<)atgVIGGEByW?8NeT{woYVaxYm@yB9I~# z)Q}!`INi{Yuu5bt(;!O1l4&v}%C1Of>I{ zm3!T2z4y@SYbl{)jN^6Sl5KbVXM|F;$IlI~pO1Mj&@Ez)HS7zEll+l&%NI=r4PXj(r zaJCnkc@`f4t8CrzDvzhek%d0l?cCZclBIkRU)ZynG-sXK<804px-VY+_iOr7^bsO@ zM@D{+LF?kD?~*nTt>5pkvfFh$hP-Y0dC0Q%0x{k7Yx@fkA!7DeWV$hWk|{X0iO+Js zI4^bUnXxrZd+&p|$+u@@#C51oMyZ%9A{ zUzyB|^P62wq}Sg#;eF^crcB!jVpDs>%x+vC;oK4Vul5p~4c7(d zN@#Ytg$Rd#$xR;B#~@xz1^q29ra!52!jbO6^XW5PDVa62IRate}n0G zyR^&Kz@q>Ks8NesJ_HyHk10g0WBF@;fLPSXB`e{Vv}Mwt@~4JZJktX0wM`Csy)7Vo z?)e}ZN&?B$;pvUlz$_vd8vbM3VgPZk+X(mM*<@QmYfCxDbcP0y02Ih-uKnApf5zcw z2aTW6gW6-LywCQWrI(jCE}qexgYDo+!hhXqA8E)lEq!l3pa=gdI!e{um>bgI1Q8IQR8*#e~839um8ixc$(LIZ< zM>l1Cbiqmzjdn<^)8G#xQsHov-GH)q@xw-bdlpiW-PTUjZ>hv3=OeNL^}I(Red<0izA!622ht>2GU0QGR}K*F$=%) zP!D2lgr_IEFFeLSQ^X>48WPXwTQVmJK`&~4Ts9AUGzPPC{Rxep5oJ2RH{~kD0+z&# z(o-c11F9#Jk)o7PQ9Ow4_6X`>MNqWRoG1tfA+M)YL4r!RzE?rX0J;GReW zCMaar@7sSr#opDuaz#yh|AC3u$#jeRWoTvaxN*#{Vqfoz&GwOYuLZw|ncJ^(QEL;R zlET?2KX6LkJUm&b!}qYl-y(5#dQx{OSWi$1(EoFh`6({>SZ4jrzbFZQHd@EAS^H+y zR!OBTG6E){M`vWYXInl9lQFs9E195=_@fQ&c5l3 zgyLQg``M5w{F9)r&u6zuwywb!Z)}#|D~5NSGn2i{rC-#m&)#*p*|O@6ToMQiK*V{? zt`(%(J+6{?mib|$T>B{^7#W+FUgZPzrTN+=nr_L#f1gQm{rlI*ew}}xTV}{foFCeT zjjn3`*+BjL@knA>vv)g~aJA*#AC8hK8vK>p&B5WD>ubgl25eyAm8;!v-?)eTV1e=P zjI&#i!RL6fQ17=J)hUyWDblJ$W~RaUn^xB(?=i;x*0aNL_bSb4cSLBLx&L*1?TWr- zoE30X1$jDc4jdAhX#4dzSXx}fFqdc))g+>Ss17iIhj%3YsE&s=e9jvEd+;)W<8{k+ z|v5f2fkmMi^An6q#ktj%V);w z2MeJR%2wqgfI23EIqY!PPC6@=JpG_|S=D^Zml)^7-C_j0=p0YMRA{ogK-eyX@val$ zLZn2P7zu{rLc{g3-?z1YgSi6s);k4;4-O+joj^>u`1fohX*8e5L{s8eJ3tT=CE*7h z7A%FQL@zwvb13Hd(PjLiX>1zy%~x_|C7ktNhZr|DggB0C+X@>l0=p4ltm|>=08E4! zbY$$*_!2CFriuA@Iq;79TPI~>VVxdDjamK6g2Kx0mf>QD;LpnmR7e_22R_Q^2B(@^ z*iQ@Ik~4LyLoL+$4W0X2TDl0ifUe(tcbI;#wipfMGZs^s@csqVVJdC#<#@ zG24zfDR%L<5t};&p7)dZ%n8QHnp)+M%v68fxkPbOUp0s0>iPTUg~>1smF9*IXB&XTY-Fos2 zDvt(?u~aF8<;59s;^GBDlzxMOj_pV9M?O@Q$vA*AOafm}tuCFb4|^04G2d(10`=(tDp}A7c0gVJRq>`Nwi=#Yq8&xpG~MbY~`!HQ-i6gcH2O z78|Xlhz5aih0D$$ss=_6?XINePEX8dAy7##Ah{?iQO|~U6x&&MrYb@%0;04|L4KaF z+g2z}*;_`wE((k&Knw$Xopx#bQBuQ6noxnbVKSW9SmRM3hKyoa#3d#44Gc{Q1Os6K zoFF)=>k0(M08}4N`mS?Kf$3v41OJ!7V@9P3P|!UQ#d&s<95(r{;~+IMjR^$^eF3pU zgx-_PeLVwdDkWaFt?C#zr^4;Jk>#J^`IeJ-4t2m1>6FS{1V&LmI+PNaD}+k-?<#p7 zT``hOwEY=;Kt?^|R$-hE(M`EgQHWB*gA`B|G>0W`(xfy^eW`SLICaM0qIEGHETmB@ zB2}wJsFj$72uXp3s6&4e7)}PKJ*paw225Pe+_xkERWr{AE}%3?Ko4I6Ar$}lRg>g= zanoM^osq?ZkMa)Z8Dk2_;(#eA#*E2~m8#bPlc042m#24bD@8@p5**+Y=E*ybE~I-w zgZDya?}-rrw+=^sjHisrotVJlaF|1)Is|kV55d$??H3m`?%c=({-{@_b{m?}V*eKT zUQ>>k@d=9=(?jwoFa0ts$pB-h4I~$<*4u^GL;)vkoM9^Db)mf!xf&}4rP@NMbiIz# zrVbulw-iVR?HcFnK&26>0u{ z=vODB6!o^lg4Mq9?C65$H4`7^Gskqb*mtFc@+6o9zSVZwoXYD_L4!;%z^9KSdR+UD znD*@w7X>sZtg%@rqWIw{Scw2Yn(^$Iy6ft7pBr07TpJV!;pseW+&ve83FpN0yVfxb z&7$c;4vj+3?bfAOzp%vxLGF?FT>Oi{J~0MH5iZ80rijz#<*4!$$s3S$h}3JAdoeH_ zphNi-9P!}}k+yCWS@GSq`nyXH0tMOO>D;yR=rSN@jI$g$hCS=Jgv|$WE2sIGI5MXg zJ(rTw^aj2}cTI{y-PRj=z2nw>L08$^m87~q_tmQedqPm4K=CfBXiWzNIifA6r+%RZ zTSmA`MrHvM^9IVJv!2ag{+kA!0@C;M?g|{;X4qD;ljv*6|D7-K@zUx`uxUrWUzVqK z1}x`8*lT5~rU$Hm>JEFHklsxFD@wlh9sKBimy8cchX@UID@@dE*mvqr%>>fvhDHYZ zS?Bwah2CliJI<^t%dQN?R2=3&lUl0DA8pM#G-Zn5UEx(!* zM5OwZWC|~`x%nKa(6m2FkmeW@e+{8}q83(!1-9FS@485@C0LZ=F>`o&0@Q^(G<{SH zr*iLNb8rJKKLY!0)B)YoX+1oIxfiD9KjCvJPA@Tx^hxI3>ClJeiQ&VEYs#ZHPC(gd z5jWJpuAc@v?OUnERfAVmaMVcE3&_Vz@Q)P8ze0PS-9c%KZW%FO`YEUs4zeqyy`%<; z|K0bwZ+c{}9R9l;{HNZM8${J0DB^K@gS{v;Sdu&|J38aABXi$ZlTn5~Cg~#YI@Cb* z>~6k~`C5?A7!=FJ&bkx;4*d;gLFeBKak4-azkzAKE`&*=+DFz#t_Ay#tN8lgERk+z zo34K#1w5wk4(V#t-H0jgD}!;YgB)MXJ%9s3c#ts)#EO10b~_Bbmla)To%xL-^t0N8 z*Zk-Ot}NuTKJkkJ>yErMdiyX zL*k%4zn(V4g*&a8g9xx0m6BGe2T)DOiOXEflk$=M<&r2*NYy6M-58SD(?AcpmW%917o<``ybS2`)n88j08OWv z)VD_Dp3X_HB#E#uU-Nw&_%UMaq{|px9q|K<$n9v20k|_>LC>vOa=WvauIZ4`Cd;gPkAHEi|wN2aeT9PmX!lj_1xvHjlU|j z+(5eXHfa34_c%nJuUu*U-8FWI6D3Nr1Ke#^IPz=uxNIFexNcQizK2|Un6XZekGzUp z+GPioi`zjMZb*M9mqJmm4ChyehXn2dPZ``Nr5qFp{ta=yJa2^81}UzuUu`X|;^<$p zFu$7~2MzaoPhNZXwGR6IZv)F}(%37n(8_2y1v2WqKDOIU4$M)W1&}&*_EqJM|JGeb zmc?LG7I=vA9}Ra>m9Q`5Q48>@^1b2rIjUev=dkeGY666A#Q!5iwK5=pp;B_=eNd&x z9@|Udzbdwa-VWURM>(rP9J61~_jP}Ica8@nNdgJsAU9mk)+Zj9%hEe_$aD|?0)yt7 zAa2_y<{hFc`4&WI_`dVX7HH0YW_9?DK_Vm)`ud<6437MHAQ>coBQJUm&iXiS7NnV zwt3|RZBjcjB%Gvh&ZO%)<3)DF1qmde4L>#-U4G|T*^tHD{ zk;B6QQ|lBVZ=V;1%x;+3QRx$(XHTig7cJI*#H@dTufpn)SLoIH-$BLOY9*{`Up|cg zR4Drth3tVGdeyLhk$anE{_d;&+*jjO`TVOaEU7O=@ROwQUt1yrHWd>`Ft*6G2hx6@ zEzqEN5{Msgk`kC1ef7g;puPL|sd8q1pU$`hHaI-vx8iISJGKP#@>4wCKr)_q(R_a! ziePjH+*4D5bQJ1F_WwZW-O2*8(@M*d8N~&}8IsFO0bYixYBOO}If}Qkp<0}gHw7i6 z0zo`LfZ-O<|Bld`Qep*!SoG-6sE!o&XL^u%g+Yk%+~Uxix9`^9vg@t7&`PMK+@VTO z4!)@I!==_X=#})QCbi{RsNg;-W<6qa0ufP$#+@AN-X>e7_si58bk-W0unzpuooQQ= zv~FIF7Fj`WN$7R(%-ZVd3Kb*u27O}}^s6nsRge=6qr$0B4+ITj1=czS1SzHI9l@0= zp4Si2%#qfGv*=}Z-v+*!Euv#&KH5voQb;y^T0ROrAu{JbmMo%CFW?!)ali&{vU#jM z<`lkTUa|%v;|LsYQ!06qd|u?!Z8&#TWK$N5Q@cIr84+q(kryrhV`EV(NWGaVyw>np zW7VAcZrRptn*J5sbapuwVt+y+OhSl6k7T-^QbLdOSFKb3Y{qrNS=m`^*NNEkj_#35 zbW;Bagu=HY>+*ir>RypCd6jsK9ZwavFL*?apm))73rmB`f zr4TsFAQ!^IwDp7jLDxjEmgEHPC!!-5#%@vKOaI`52BlNpoju4kj>AxA2#CGJinVFQNDpcNdcg>f806ncXMRS}ebO3n< z(;Y++p;{E!doB}|VH8-|9da&>yCGGj`P~z(EcZmpR+< zUr1jEduF0S3OW(IpC?%J+$_KU4x?Vh0TH%FM?I@mGP6yHd@`BiATezjMo;FZA*=>K%utNmn=Pu_(qx?TdU*|6;iisbDyzF))TS zq`ZM@`vP1%Eh=onb{0!XCcw-(z>E`Aj!c!_>9kaNpZ+NLn=U$13)09eNQ_^CZH2hxB_!zi;t zut16kFbWv1e5j{|lxD6T-%Aw)Av5uS61B=G%mspftF1{GNk(xTf?iV=`WS2X5u>c! zUxJ+J?=R(nSgE_O0lUWnl8M?WihLmCti<=NMCc_C!?I;5+~DH;p?LYuf1VUg#6< zxfwGFnM>Za{B8$3;(ZEldnb+KEcO8q)eQkX(7zN(YtE*vB zkjusqh#7CFTo{QY&bcfV8ZH=?nS>Q!V`gT|CQ`fe`po2xOS7s5y>bbi+5WMfm8;J6 zvi+U8{;nmD9BJUcjm%c%4=X8Q1BnHf%oYZxCtXJKP zdd@*V3S_AOh%~@Tk`q$#a?OvKcKxCY+r%>!_OPg|IZqZQFkBJeb>2)A)2-&pwc66? zmBco=p^Rybex+C}d8w^{*XVW^HZMg9wAXKRHFW?yCVf^eKdU#2jGoc=HO0ZEZF^_T za6KSm$9eyiCMwhN<%(7O-bZu`o33G~-_MZ1Zbr zq-ygLX+%W%aa5l#cbFRq;!F)_&FVF))tDFwV|hE0V`GXxUB zJ4=c#-%2yVYqc$ZZJ9^6M%U9MSe686ff9z?bBo%Uv_jOK85ee*y{~alv;b6lW(56o z#Ijl#R`J_lcPmMG%XN->)c`d%A)fndPFl`KKhI38l%DqYz2l?7Ua|lS4tVnzA>t9N zw`+dWU{OS{guLmiOC+S(UV;^{MT5yw=VpHIclsG)l?~hvksJDji3(DuLgG9;-yL+Qw4f&33h!o8qB$%zgs@mbUC!W+n%a1Egu z1o%9GSLjTVwk|ra7`*>6;kja3o-rc&r?+aVXUR4ch5`N9=85%9`8CSq0k{2_f^h4= zq^kgE0K)3zyYU@K4KU>~AoWAZ_pmh88V+M}6paM4gfl*%BrU`w`0@!C!@VTKk1@O} z?A59MW;j?9iw`HK6by4&o&bPM($5P*bvj@z{p=5G06IIdjbt%)Jdpk&&Q8KboRSex z!;#^CGk+16ULbL=pP6Gp@JfFs0l{nt2XT`Dbuvf}>gff?xMIQ;jcbB8qXh3LbaKL_aT(lccYh(6347`-TF2`yfU61{Ouy zm6?#b?_1JDhb{ih_}I<s<6q%yMU?9(Fpji%3;s6mX z=~4{i)Xj($I?i~hMtiu(j4CyYBnw(Dr&%G5a2YyOxHsz|)bUlRQy{>Kr(wi}Lw3DS zMQFT`CAV&8(Etz(0p^4Ox!@o@F6Hx^F4v>Yt~VmDr(NF=yAnfl24gc0*@pQ$L)_#X zNni;*AwT%vl;A(tSXTR}YDiyCBTYtfMr&kg1UN{HQd$*Qq)WPuF1oHLo*}^PN$joK zk9K+X0cv>L<(qo-Bh~7U(Jq9@E6Prun=kyczF&vn!GG^suRCP)i^pq>L;m)Nz#k)O z4|XA@UsM1|17J={sk14}mAgQS_Kr_k)kJXxZXPWE;*4%pQAh`Kb=3fDHh*Vriiu4T zq_@gk^{uco#q9M?{Qd9D410AiH?MG#L3T~~Ja~YGXz~>Y5hFC%#egt}c4K|l<;-sQ zmc^91ay7gPNmIRir$Cz7J67-bo?(OKu4v9cF?Cn1t}n&x56cz$TH@o7Bqm|j0hp%* ziT4qpG{lCCCXgTjswKjNK7@|(R8gfgVnnbnJWiaZB8Dbl{YB$SS!?Hdm0_=ocqA-L ziSeO*lh+u1eN1eFk(0nYxc&pL5>5xut%HGrk>BfMZN!&3D~B`NAzt8&pdv9GM3Dp= zJ#Bw-$^=UF`LGrC(53oFvicBNy^jp|DtT7@sMm#?(_YV4!@OVBV8Q9Bl9-UP(mM*! z=4)-|h|(#GZFOM(8icqS8>NBv6awrrC!3Tq1Cua72m{{Ncycu;xlX}KgqQUhDu17r9XhGwM<-xL(`Iqm16K!CYnJy5W>k?lj zrOws&pJE-3Ala4AC2yGz6ltE7@|{?-$JjsDOI~Zt%ku8yJ%y-aiww&F0|IrUkyr1A zI1Okc2FuV0v9T#C;1miIl}!vqOcf{!(m05r>QJ6P{NZCawR8Et6UxKC8C%EzEd{RU zYE_H`BB{n_Qp>a7L;O6T2$x}<$67}D5!4&Hzxm-C==dYY^!KmN--2qj6)-rF;IDT{ zKQ#D>ne9abSCLN`@H})J&#sh#mdWqlyq|w5ki{rp%1i zzVbPb_uQj+gQRm9FII=|BnDVVNgW>l`EgF6f4qfK!v%X@7UD&DG*opRqC$ZEEPvQu zk`8oe!O26IwX@Q!J&39E_{&An(PXHgBgA_?K?^s;4RAzzofE1vP)U5imTlm5q@ebQ zZt(@3F$LbaS7P&rQy|2=DWH@u5fX=kObcGH9gV2#gn>v8r#|TehvNq2Q&pyY_dZQU zHUgiD!4iiF+Si8TgB3380e`B=}A87YLGE=Uk6FL-|VBgc$Mct>?Tu^lG+LJ zahfO_Bd4{IprsUv{`7Zj{^CsbyxUYrJa)`c=#s_V+v<(BVuQL6V+_a*8^cob@C6uP zcF;LDc=iNIf+W8OW&L^L`t@A(kmTOhuysDS3CiP3HgC7TO#FAo5?SdId(~ zgrSi>5*l|O*ikZDwW;Azlvco{Jh7Rm>5O>rb&{4e#_M6vSq2tuc@h``B#+0wY*{dR zl=R7mDa>0d?MOim2Bstd&n(2+Ko2;lV=D9co!xn^rKbj%0x~y( zrTP7&Ekwxb1klsp)TIz8EFW9=*%FHq*u!7VvqVy^AXAJm)y zk2D9vKeZgLF03I}w43vcJEocThi^~Nu?w?>M?}pYn?DC+?u0hndC=g5D}+qE3{;EG zRL&nV<5duT9dW8s(@CM~Rcfba*JN2RtRQ*baT=lp2a)j#-GU@mZ^9!#9Sy-b^h>f? z;B$bc#9QK>=R9wjA z3u49fjKu?r>nz%I3-Lg@sLs@HI>7uMIMq#IG$|t9SDFHb1`ba8jxSOzO_WN22RHaJ z+>9d^d-z+;=sG{|VS|lgo>2*F%n?}Xu<2=O9{v*806PfBJ{ZKz0i7+{Br}1z{f#V5ASt;A ze2?CRTysVXrbdIl|LXX09Xu##hBnRhwPvbV19N!qE#VTE!#W}SBSMJbp99Re^OZ4i z>Rce$d!EC@btey3Y2%_IK!RMjyq$f(O9+z@E?gKA1M8pbQKY1lyG3vir)WC#Ypfbj zL|GkR5&uR{K*XZ)3Y()Qpg#{dP_ze_?{08IjnUa>AKpBazSIWz@6Ya3ZnX8-f}}BC zzjj_*J!w(LgJu#+PfrGdLV)0n54dRA93(2%XOX=9-6Qvy%IwkHpUNtSwEL5T6p|ky&{p!5Z5EkbNo~f;CsNV0}cYz*Yg=rG(JqjaI#Q8 z`}ZQuceB@UMLT_2Oub9{_n&M!f=f~fzN>vd1oMMd^sfIXD;A8$yyJNYzWuJ5yUS;q z`9S~b{K7s{pv%^!Hc)z5E*1AY7X(mIC)-=~Y3*le9#2;smXkUJMYYLod0#eE1mllU zmfnl^1w>UIjzVZrF@mU*yA_Z=tE1W!+4C3fTDH%`NK3O2p%Y_hV*}Hg>7O37;BLmX zF6-Zw+~B0-cl-~3=Msd|tMf9iUi>!$$N~rkGjSQ{e=Ra^Qq3efRLO|~m>mIzAoN(M zC_HzdR!h+ZPGil3Y;I|7C5Tc(Q&zUaL>32;Q7A~8w|It1W9?j~ zhXfou874%hZ%7J?VEN-)>2IZ4efbI{(u?^lm(U3Eb{bx(>2WH7YyD?m7}>Mzt{=-a-^v_l*~`-kk>iZ3++elbQf;J`0 z!^9>$Z%tqx(W66-CaSD)8})R=K`gAg-h%)L>@vJ!0^CZ-e9Z7{L2eg`8BCg_F)z6h z>EbS!jKE3F!k~aD)~;YX6_|vJV@LIA?wh!5x14R<-u6+OA*>e7daAAx0M8t98#-7|nRM<}<3J zb~ta$u!Jfahn;wml0j$-^mwZ*$IdwOQOzu^j2Q9oGmnK`XP!g1xFaxA!sws{q^640VMy)1D=duXMOte0J-|-`5w7CSYTl?|A>lOQ_ApayV zHx{kWkm=i<<7a-3KtyOg^k=7saAxme;3ou1)7xBpkwn)9P3MHqbMNL@ukEtpDIW0! zu)86V^j&GPAOr!C3P4P#$o99SuqcLqDtvrpB|9ARH)dH${RieA za~sz5F(`8jo?_F$gC5Q2&&I7Gtx~{_D_+H)V|4r>Lp#3GQIAyHuZ&-&GVu7&6gpP0 zE?e&=^l4MynjF*+WSAa%;%9Y-_u70zAg8)gxUmj0?CY+Kg@gfM-KNl1hfzZU!X1HhB_$)BrsbOO#0SK;ep76SPu+|9_Fj|*QwYQFFZNB*G z;HD}kyD7N$lfZ%6OCm=PmJwl5YsVph4ai}HzRFtnJJi>s`v5+p77UybcF-iQ%L-hq z&Ne4$1{}8NDGeDPGdRt2f>7h~t$REJQJNh45)TDHH1+5zfmO1T22LBQi&8o4Z>{=3| zh!$&;&RWVC4`z5T^+_)C`%6q7g-Jx8%{)C`Ff!oYL`fwXrjIi>`rw1K3iyggB9cZ< ze8H>%du7WlVuq5ExgU!{t0d;Fe<>U`No+LA5OU^4i~n_Z*NxrPn#owyswPC$#@_jrp|zx;bT}MaY(w>*H)GIrRBtkvTxJ(g*Q! z&@t|Fa~6C@La#obE7xzsPHVO}wF(V;U^0=)h+k6lNhjm?7akSnP0) z_sw)un!WxtKxD$GflXVzi6~UfxhRk>bH^!2on8=`Fp!J3#z4_NJ~TJf zUq#_TNfsW)f#&+N(n-IeCf|a=FAG1NDc9-dAhT(c2HEGxc(Xj{f04Tl<*EIyUW1eOvh>_`4Y~8qxZH_bX3qT?Ctnl0C-V| zB2@D)13{P369+oSy9-{Mw-0=FQ>ji%x9qCr!OjPsLoov<0XJa^UB0vi*@T`Sjn|d(Wn(;#l&%H@1O!Dz1uQ)I-}iIR zeqQdG{btYXoiC7?WX)Q?>sse|9M16DA2)e_GTi`4pV=oUAfR>nPE^)Y2NBwr3p^S| zE%z3s?;0SfTpf-=oi&!LP)8>wd~`*f!h55^lW5Z!Odpp&%7Z>cBp&HwM6PvaNUdxR z@*Ok6XzCSWpAT|ZBQ$USU6d|X+uUL%-|gqW0iyesO2tD!LnHMxd7X%T%!~3mA`~E> zOf2kY*(c}xtPv!>>~&HZ+Lt#!7$%jGbLNh<)Pe&eUis*WkJEm>1q3 z;Y;!2!4kvpv26N{gsd2t(fp?jF=6KQ0RJrA@ppm06y6@TOh$gV?|=EXhGphGxh{jv z5~cUcS$46rw*?+J0wr<;jwGS_v;eTE1O;a9dS6I9C)B%2VTI2LH+B>#!*YAi%EpRb_6^7t102RGJ`Sl(Z8iz=@uvumOsWM-TSieg+`+YLIrCHnH=CCxM;%sHo<4nQ>>pxQgHhq?m%xKH z$n6w`6vfH{zL?q`>Fruc!`}bacv$VwJW$@p4<}o2eJ%n4a_9WEgQKraK(rTHLbZ0v zWY29)qQE@O+KX8y`mpGmmL&@ z2Zv4ijZXS{=Zh}S2l#xXY*!>JgMs8E-|jYvF3B*efte$jt#%*iXdCK zZ>C8miofxE-ufY5cuaQi@vqqKpV5zpMM%51emM4!*I{>8HjvEEQDj@0O53-6-#$$90GdZ1lwX#Oel~pU+jbBX2 zDSLk9SQ0It69bRJ-`LRRjnINg?#D{Ad5q~m@zvp8<5C+t%5Q=I!@l@cCaa>wMA`xm zh7*oE$sXjP+-*tN=UC{pClv`Qa~G-`hV**#{W8H>neNRm$D#P>7GzkB6{=t|IqeOc z6OkrFA}?!QsZZ93iVcqM2yW1X);cHD$1vefEvJ}GAMPjrr;({_Rm7j*l|YjZO|R#> zNo&o1q!T*VOI@j)>Vi_-4}=lo8T`?5yoG`XA5zH{=-b)SqVVhkAIy}Wi+t-#8ztOw zFgK<^J#57T$Q7ChB~>?(lznAWvoX4HuWsdDC>M83Q*P(N8apHHNot_s!U|#`r?(Jfkq)*^GlGU~qqFT+ z&^AEI9cAWwCq*QMju;`fDlFx6>`EIZ8ntNW@H4mbyiED|EzEP6#ku5~_3fwUB^m6c z$L7ck2I|I`Qaew;hj2+&Qj}pcPd48ViXs|(TZ>lGEG=1(@?~pnT7Ytji)KMP9Cj018%td+eB*7AeaY5S*b7q!_F*>3>M|PbLx!pO(9%4j3&d; zcDyEJAIKpZ^F|t|`?vGtR-;~3Rd7nf!<9g!yj*$zqhO?oBxRmbd$9{k`aoQTlxodK z1(WN+;IQG6;?Szi)hty?fsDN9$U+DYHb1!Sk=Oxr`by3aE5AT9qzK?`6L zn^#x5&Q`H}DXG0%XLnKPjH*zYgl8nxJ*0=SAmAw%MLuod<*tVJ>~%Sfxqj{q!9M&0 zolRvIO)RR)8kSYBCTkqTJdYC{41K~?2!QTIW5kL6kWLfH?{N*=)K}aT^dh&Jm_2;a z?AjA$fX$2Zc#KbZ+$qP@xXyMB0K1<&o^OEI&9k&)q0Sd&qz$h@N<+&DB(=STNJ*G> z1+=f_<%*TB2!PpWhVM;p<*G>)lC ztqKKCYYQQ?-FuBfQN|7Az(^Vc_coYkmzLi!89t$%IGwxtqMfTGH&V3D`g${e8o@jC zl2K#$rX)Y-;o8IfC%Sqb3_?Dc4zF`=jF8=_5&b1rqLJ35Dc<$u5Px&2TbHVQeNu9F z--U6w!!Y5VGDr6m@gAR{@3;GKj+d5+qn+L1%?1sY&I7p`0}c+*OwZqCf&(14c3jN) z8jHz$C&emWC4m*%9>;k%Kkc(rEfMvI=wB&r#m6`0``B(U`>qG~!HavYn1%BSgudVE zGNI}Yi>K})DwAJy^9_@|9q)}Q>A!f=+Jd|(SX}2YY5DX;{uWVI!>7(|n*ULNdHc&O zm2gdyH~kpzrW-N(gK8zqhrQ1X8-k0=o~IGyJEW!(@Mg+)BMN&`H?9zW$!Dmsh;m+5 zEDccgcYuSb;xtNtb>E@#-~E+pT{n=_Dg-U_M$k1UfCUfB*tbh~k~FPGd)Ei-w&wMO zeyGj0aS$!`2wJW%()`!3COf<#(3Xb`2sV3R7l9_DPS3byQ6M!P#dg@rZ1k8_{@JN` z@4YUeI`NXcUSscg{hu!y-Wt|jvNH#rSBh9#!=Bke^ zrs|h90n`Mv=k3NkU7HZlfV^klCq0+qxq+7xaixOf_sGPjOQ8q8b{I&y-zB4#NX>{7 zYL@d^)X`+0v)c;%#do+3&vIgNDF@T$bgo|}R|4i+J|ReD8ubmzh#_n5gE#*fbF%@v z4_DP^_k`MKFJgf?aTff*xJzfpmg`mVli~O!7`WUfC;w zX&#d91<~%KI=P641t8!yz+8EH@OKeahWWln&Tu=UsJh3ll*lQmWCaGoEH`$Z8ws)^ z0$n!7(jq$SHFFq+{L@Gd@vO0{YM^9}YCkQe_&&2^pTSFnGsuME!zAMyB&mnLArOSKAj^>gmLN%~_E1A)L@5oh5~``HnWgvJHaC8a7j2)B^<`Zr=JV zL34e!g%LOUo;|eXNk+i1iYq&avMu8dz7cK!W%{$=Fvuv@{AO5R#x)*N{`xtBo65~$ z`IH|*MLPGMP&)of=cuOinaOm7Tk-6^SdUyMA(1<%A92frCaJRiRze=Bz~Sy80{hNi zo@5ANDW42hhSGzI-DGOGhIGD9_P7ZKUlqtJfaN(Xkz)IBq0ET-;Xk zG#A+xl)t`Jc+0X_wpQG{+#tI!8|qOroBU3a2=NEK;nw8s9P*<8+aNdeY{5Kja2^c! zgd^<^7U~<;%p?9jQB0NWt3&G5&H1B;_dbzk-k_1>;%iX=B6|MSkcPbzv8ZhM<8G?v z+qWwJ-s%Z}8KdXiC?=$*G~Le|G5(MCAWx&~n;K-^??a={^BmQ;w*RK<#uc-vU=qIe z%8$E04PDsG=LWsm`#^RRL_UXOQePpf*wgv9DLV{9N53*GU#aYbW6JB(d|cO5yM%8R zR?h6n^^Tl3hq`(_;M?0XrIiB-2g`VFzBtzidmCMxKrz1_FFv)O~QM&ZGfP9WzodpIh#`rqd6 z;)im7;%n}Y1$rN=X}1)Jn(Fv9TKr+|rbFY}#_ks770cSTmhAAh(p5rh#bm4PFPU>b zo3w8;Pv;g-6?Bukc}fHhU-%yvr-MUIj{Gygp@e05*^l?^j}bQ=t>zC@xHT)eGK@bj zq566axc37{FPEI!E5v)M?M8E=JT3-NLmFS6wTyJVM8Tzq3PfM&VK_i{Lh~R)^!Cn; zay}9&kO~Lxcm!I!QgXE<_Inb`(wx9Crx4GLtRq%ZgH2LyF zLpNj|e!;_(KlDxY!#AnRZ%j_GA6LK2XU?CFS{EK4MDS$VwwxZmbh(C<;OT+gL{OUs zkWLg^UaD|Pyn?~AuQ9%ZNjx4qE~XOxZsxatbVS4)=7G5%W^9zM%N>gf>>WANeV1zOslW+U+PXyfMA92Q22rIC&bcV#}Mr24A}F; z+@MD*oT|_GOIoY(G=>gh-JCN2@+>36TWv}0()Xz)4akGB20NDB2n#8gLH$6kBB@?mhQnL|h9Ka3AVgNQC5cyx*iSC4CK*(+2^zsbCD%yU0 zX=$vi>1o<&*C_Jx3rGw-O%gUwmq*#Ys=B5cQIB}=pN(y6TYE=mS9eE4Up)ZSRv}Pj zQ6NfbMjIPOD_1*N5I>4)VR7m8n`J6#dR;gJefgse?(Gjd+X~|4jFkKCc z<@z}s)S;8zbC=?UCgf0M?VE@g9uw#HR@EqKvwh&nvcDWPU(WC>R@ ztt##3fX{OmBB|FeO}$TUmXj3Ju@oVTm{1IMJbr`X-?pPU+sMXp%QA*s{=C{L;~8tL zdAL^f$y8SEnAlUM${doET6-j2g|UtVT<|=2J-);QrMK~Nqj37zbg)EaD#4ZW>iQ!J zc*f&GW6n)WD%mr%p-=IsOAb;{4?n`W{Z!Jb!|CeqAD}~q(p25f$34lKX0_ce{M(15 zt*nHUpvxiUT?48zk(_KBmCoP4l;!;1{petVYE;lo4JSQ$rZ9hVO@@*(a%w&aCOzyl z!V)Df=MYdoblp*yW2bHY>Pos66D9x2ND}$d7NkOf)>>&RXihsj2Bje*Pop8mB4k~B}q2ogdwqsF1>PJ>Agw7y30L_cC4s%zC#4?V6Zv11f zD9nRSW>?heC+|BsX;4-f=<4BNl)<&<0uha42MrnbJPxS&39Z+~lr;9A|b@mOzH z0HRFq7jtY%pQ3N6q$XWxO&&VP=ZjZi+=X6hR+A^ZaWvGh~R~99yr$tNoUw&OwuU%XlvL|^=cv;-| z-gIpstB5R=>OagWMb&GDSzOr!P|xhx@z=3^?~Xd;&U_1driLv4iXGf1ikGg6HlKHhLrzm94&57tMe-ybu=8M`JF((wNR!kQ?bGJI8 zF17RSUw`zZxi~_$YN4%3-=L%`>3!e4TYkNdtESTK!GzF{MXEC@QBSdgeC&PB) zDg1vMY3}cA*+5;~pY%CM8LTzE25Bu^{V_jnyq$(Te~~0#L?p(l<26~-ox$A+IP!@8 z_rZaLYbL{Jt8!n4L$F@vpP^Q|+O$>B%kOcs+|Jfa@o$OzQ_t<^KYE!OY8KJX(~ltU zda~}9fO~OZ(3W4qN(G$UpdNiVbo@Y0;uYg+Pb@iV*oNka0vd)IDRVM%TUaC`zv6W5 zwl@;G_-O*vLlC>C8NkDFHnJ`TyOtmkkGntM%JPvO8X~!qrgG#MF~z3A`^50-C4v|O zX6d*=|KuwL*)a0~t#l$VMQIlRA!^5B5tFA2K!QC5btqp|7XLhZ5r5QUaN~B$?*LZoQrVVPKt& ziC{qQNGjwRt{rEG^kI>-J;6}lIq6K5WXeBhq45&KXwcj$jp$7?%1S5^3FG9^y@KmE z*fhvjGOEbIEzhR7nMQO$KPX28KE9XzHRLJ?%{vnqBj9lhVq#rF;lili<-SG9vTqA$ zoKjcyF=P*`1+=F!giJf~esK?{YPjy}ZjnEmWRlG4-MLJ-B1!VYjX?p* zWPqG<-8jx5tC~#UZI^mGy&I{SC*3z{^^lKT!(X9ENdag3hO&@uPYT9jJq>1V)B+r( z;09ghD7@;NqC2jE^^Rp3AsB#|zbU!3mY5#Ps zkRs4UbLx=<>D=I9e41_ulTbDGt&_wN+X~ohb-CInUpzdGdj5ON&3(+G_s{h^D%ddr z4$X~c$Q}MPg;kH^pNep{n8NWt6B50{5WDi94hD8(a>(AG%u*?b0{w~dC~l(1m=p3^Mh7du+1BVY{8tc5T&xqFV^fPzVJ*e;)=4 z%bp{3R^#eZOz(<&;c^#m{BRXh2{2M0fkq)h+4>z$9&SCEf!7CFT#opEM#s|V=c*JR zC+WMspeK_>Q_abD(Xlx}-{?)WH3uSMoM&x?C3)qF$;JIvL&i2GDfP)$=eKWvQSWKF z!hUe5l1R8M?nFmFBJD&}%i^sl<`wPFV%Dm%xnxv7RNGFE!l1SLFU5pZC$&>=Y-hH< ztm40t`2G&p>GX78+;!XY9Vbd@ZmN2cde5 z{GC`3ua{VYm-c=ySnWnXnBYz($7z#bmvcY*$5J?o9!l!pw{+fl#QNY%1&=bq!s6G1 zcNGsF4wGZQKB!?azR)qvVzzmr6LCqT2ajChR&MFVF|eB`#V{qagJs#3i691K08%*= ze?qRG8-qOKT+>9H*H{M7v-&dMo-~U*997c50y=WO_Q*K7Q1(nRLH;)Sg}SKCuiPYD zQ4DLmg!b*9InEL&)z3fUb%kQgtrL_MoN_e7-L;$ze{!l%k=x$~&O{PLTpYa=>Awns zNN3xK?mH(R6T>`htKa|&5rS5hkyxfrT}a^S3#Ql#jzp<8*E(k6qj{O{=n_d8CNdNu zuy@QWxiHy^Tu>Bg;koY_L++NgAe6{Q!739~wC~xHkFaWkv0xOrZ~1A;(MLJciz8D> zOC)}Q1hdt|20g}2m_9$^njPv={`> zexO;TCXp4qPopref9pfE?uYbOg^X|(S$mAIGfHWDm8R=dka1CnY2iLGlv`Wj4#`nM zO9A)9!!q@FHj@y60d~Q+Ojw*G`CT*XnLW<;dDz@zDA8`MY<3igzBZK3CwrU1og?CRI69& z>3UZ@+|7b8AaZ2AF=m0dFZZB($vK{F{yVnU&xPW%E2JQQm6eYq#}51+oy z9La^0*R!pDg(kCJrjo=h6*p+C``N@s@*IkQMMyqXJ52ci|A`GvhB1uIlRu>|pph>K zI_JS!YkaDvu_7pzOvJC$g0uk)oCt|?0deT^M};sXg=K4aIHynFW(44wHed>+G#!`J z8FGDt{vyjWukz{pj$?3Fj5=tzL6eWq+$vI zYD*wfC72>CdlP8!A86iUOWq&Y?goHZq#x`R3GWw`6BfgU0RN6Ga7~tmuQO;m3+7*; zpc8f(Qp;zaw(uyNkzh^)%ZgR;VyYCwt3>css!yua!@&x+|ABevU;y|69py+g$z$#A z1pX&NuX3Wqnp*J`m&p-M6>BCjrwd`@r{UN(b*$ji(<)2ds!Rq~T_KVwU4YbzYyH-1 z{nu-05OskUAPgR25nH0{4Kfl7y+$-(b^+-=cJ46>&Sx zwaSfEcWoQ;4{KF9>afLC21I~q7-9{uN@}Hjptm#OsE=(FPBX9nax2br3}!_ve{_0V zq>>@x1uNK~N;$kCXT4TVwF=Hb02M=E(qMiJ;9~}8iB*$4C+dffd6Ct(M=!~?7V6sE z09RaNY_a^~Cju?0GD>}j^;7i(Zw8h?U_g=0gwUjLSXEG5 ze1%N^V?3Gnsq!b1r2xXqKA6?U=39+LZ^g2&b(N=|#m9x|Fv}&O zS%@X%H|jG>1WKJVm6XY^x%byqu)0?E8~gV4o%NG6(ym3-LPW9GAy4=#$hCH z9uD=bCeI)YrXzV0D*8WDf+^8MtWT&sB8I|5!o??HYffG7e>2bR4Hg`NO%Yt&^2NM) z+)=mUkH#&b3Era9&fm}JSaHuZl8*=@^U+pu;w;@}1&A4NjXZ6U8{?p(8W1%uxk+_v}Gxb_W90GRj@l#3{^ z-gKQ===rKzkNYx3^$$rD5x8pKfL5oIu$1P`ZE@ju(N{O#u*qrYNh+96ND3I`o3ExI z`Ecg}!FfOc4=M;Nw|XL4?*w=HBl;tzs5kBT%nuPJ(ilb6`jn%4MUx&}Uz&@1YNAdL z%^HJPm(<$JVAJ^>$$7S8()iHK>grPhg!`YrsnQ$rh73^tbSgxMD;~r}1O!h& zOecXpV1;V~!ZL#|i(-aZDAlr#D2!g)sQdLEQ?`~D1Fh_K(JHZ<4WW0p=vXMg_hfLv zk+XGvZ> zNaVDFk^eaGHjAJ%lB?-JeFZxqUe>^bmwU(|klBu)j+)gfTC!|kw#-`Eo-ET*lqv4* zyCN~w`N!PM_>IM#%QqW|u$&#j*JW+N>Zmi-*o z^2(Mr8Py_|VFX(kp$Kzwld{AB{`Xz}oy|HqnI8yH)bQq4hPv+sE3}4h z$yUZSI0d7m$={+ONF3S3xn)e+3%p3u7yQwIo zG-~Q2d)Ub(hzldKIMn#Bj0E8b((HiEI0M*q;AR_ex6Ooo(S&Oo^hersw2CJ9JED1E zV>oAvGkWJ^8+i6Rg7>K$%V@OY9u*;K<(+`C{`WcYE7@mJZ`hGwoq51-9ZgKyt!|-T%(s{g@1Fm?Nfl_0ES2UKvJAXV!A#+@Y!@=RRKHSC`Sp>?=iGHidzo!Y~?}>z~MacRw&4J$IZ5 zBjiu=S)y%hymq;|S-D?1IUU5*M|OctZqR@`)uJ%e=rGT&5kmI}*A&iFtg6!CAv}B3 ztsDnIC0?ap;o=)8a{x?;nKGamMabzT2xJ_)B=>)nTnl znv(H1oJkxv=mg%ID?Ozk$zed)S6>5P<+}R*B1U~SGkFDcAZ&oMm`i4t@Y79c!}4Q8 zF2XNsN)OEYvsV0&{y5Ac^Vi3@KE=X>XkK5{bUBG|ZaNFm?P^gb>~_^%r<%JLE$El3 zT^GNp-?rS1X_PU1Iqp}~dLDNdv*s$y`wC>-N@~vi(fX8?eC(x+4J{*6Bm zWh)F`OWx98eG=`n2^C4bQu_; z0Kh&wC-*-KTSPJ90ZDp7sHh|@Y-{W48ycJH5LtzVStL|KH?IioWosKrdNKfn*wLq@ zv7qd!reD0AnVowzKgUF&mJrLqicHs~*OkRT-FjC1c=x|F)iuS$r-(3-u5J+;t|!~) z7rDbx8=H(^ZBD&5f*g}&Bh4a0aDm@n*pxWjEA_rMm`%=SGr7eE!!w(w?e#wAIdfkhjuLJ6F;Rkd|yl=KWvzC#&>w{5PSbOuNYU{at7>@GmFeW<59<~V%!6vO6|C!O-sr7g{|c7gw$zXC`TlKmL}vn2=q{OjW}wW$ z$|Tx?zsm4B&#}pG%b=Y4KBE+Qr$IE^!s%Dne4D5i)a8IqeD!ETRtjDw#xI^iw2%77 z=1bJ>MxTmp#(0IMxqX@UwLS6YP!dDc$Zx9?U_UHQf>`f|*^ffmtv#rc#ur0Ae<7-= z_CRAszc4Z_`rm%QoRIKLmo1N*5x4iMphwomF_y^a#^5O9OpPVuK(dz`0)v+roedX(;Z z?P~K3OS?o?(cBw`vY_y>aFW+~v^1y^;R%RdPPL6Q+n^XUAD|7|YN=5~B%$yobNy~5 z`OVn1yElq-c{$F(jcp+Ygh0*B5n?;z5`0)|$pCBsHY#UiseY2U3y{e0! zoWfkl81|_Uf%J$;E>`3}YMY|}J#SLalQqsvc|uRD7_bCSKkl~V%N0{ajmn6Nm%zaJhQrE!@y*?mm4tk>Job z=_f3dQzycd>h`;0gMUJ-zKp+rgE9&KGx0LJg7G^4x2b>sKHZ$WH@(3>Az@Pcl|rOK z;(MxKrusb%-r0?BbNWLwUuV(q=2u=H^CES{!6dvSgM-M$mL z|G32ET$1+B9o56GwDkL*`Z{G*B?bP(^nU14J3c?`XEiZ+6Y>=gG8%N znXiJfzP!6JNc1)Q@>g`qZg%l!>HW*UB-c3Y@6DYR8ilX>lkX|MiTp=;a$M!0{O8*w z@6*3r^N#;;Jp@!WzV475AWi4M8C5C;9uNn>#aF5)oxjsKWVi21bG*ehk& zm+BZNC>K^hXV_T=lgQv(b2$^ou=7>>Y70YQRBq8!AM&N`UIz$kC?MA>N_R($)H%o1 zUh$i}=1Q3z7QZtrSY)H`p@=N~mAqFyd~4RuC8y*lo>SwO4V`7>PQuO5NX#f)*!Y$g-C9 z8M8#7vEI`bUk4ob_)0sW9un>tt!R8?h?9t^ev6Fz#DD%FUdZ0@B6P;lN5MbbovW)%FKlwft#CN2Y~sUYvo-U zkJ;4GF?vGwW8S}qm$Ces7Vo_}i!6i1mA6ze-~P0<-EsHe@Fh2?zhS``H7-CQ4PPDp zcjcBnq0zQ?+OkPZz6N`Ib51MbMN!AS_JD_tFCwim<{8bM+J6t3YIakr4T2h&a*w>X zC~mzsj}fen5|J-pwJ?>vTg^K!e3b)dHyo{~EZ+R_ZcLL_$iMv9yUZRIs_eFu%FabO zHE@c?4Vzk^rN%6w!P{_SS^XlX|66*($9jDWII7}l?-@hH#>?Ey#|drSL8BoDcD6!~ z7YkIo{bu!qQ>+(dD^uJL5%6@oP6nMTZ_>TQ3=Nka|C6m#slh3&K-YUa$;$Qs9-pq8dNLc}u)*oigt9Cwp-CPSFw~1*)gP$A; zra;!~?Wlge&hIrpc_7#5nx;so9V+c8p3c_~$Te-iUKjQBx0ZW++*K#`w4vN0(xr?n zhsu{$zNEx=a`_!;b3EUaC!)TkN~t>kkedT24P6Px7ELh+>{L-~?%m#$8EPDqemfrRjcM8{MjWlst*~g!QOS?DkaS&ZeJ|zpXfS8hWq!Q^)of?%@7I z$^>JkR+f?%7VmVzj=)+1@BGqVu>^L>IhQv@568~%NFh7lI%nDouk|KZ0{s?RfiKTq z|3Tls`q+5%Qt*l0MxZyPb*I9Y;0S8MuZjCu9(UI8oRhFt+E6rABt=#=J_Zfx8~r-; z8Cf~`-Y4g5O!TRpX$CYz^ZCz-3Q4qj;=wuvZ`fnw6;4EA!~&0nN{q=KHphv}QnVoK zu{SkccJhgb%!*3gH82jTh{I_~{n)H!)`kO;2T!hSR4uOt2xc=Jj=$3eXa4&(x6Ad3 z%fIr~-MMl?+|?rDhEq1XH;@e8K_m5_c zYPRY><)F`q)3aaHC8SR5F@Lr@hi28!S`NeMi*`gzLOo20-_9MT(|^vLgRFQ?w-h-K z3}3ywGjZwfJ;wB*Yke;K#ga?sgW2|eRzm1 ze&x%m`u9h7R#5L$g}%uBKCSb!5{aZgr&&4snfCUt_TAsCA9yZ1b*0zkHI{1dHcu~H z)lE;My!U|PJW;fG((sUR^rC0^fX>;d=w1G#*hbT^J|%1~e!BB~r%DR1yX*RCtb zk*eO9PBD(>%;a~0PNuHa&q-Vt(p^K(UxGe9cucz-d0SF3_ETQ`uZft-dE?|Cn&$P` zm#3iW;Y&-q!aKn_4$dT!r)8qQm6g|ih+AKx|5+lIEh$hrDabl0Bs3|sFe$t*DRMO_ z`YZ{@_8-ehymfM7XfkO7o7$J0zM7nImW*dh$yQFuwNA+oO(`r)Deg-tT}>%JOChkO zlH#z{)~U6jsr7}ajeV()|6e3M(fNNYJ<(5z0RX;pCI9z#h4P?oJX&P&<1Q(PF0L2QOTwHSSP1(rvp%9C^~R^>>A%C7UYy& zV|asA#;4RKtBQ~uYh7He*RgXmRRj)tn_}u_kb6~MwL{OWVm2c#($u_&abdc_iWS7H zs^F|wrpr3*mrA#VEHzCbdz0$jWYMT{*?I_7wVc=N_%g$A5&olk(b0^i;jd5qm3OiC z`EDGiFr!{(_@)UdM6%g$SL#`%#&as$O=X6N-<4xy-qq_9Q@i&e-tZ zoO-8vsiVyv(l$^Ww(X%L@4c#79d$_-CST*T9pmXrQ(_<1@=}#z(b5O*dG}LuKI4hrhriwX3Y(Kc>LJ_v=@s6u->oA6%io5@a=Eo672x@o+Vf;U=OixxkMZEShqOmx`6I$j&m-7JP7em7*qtOxANZFXseRoU;?q zkYaj+R&XibMJsgmddL)N)&%>x(6%(7Hq61?OU!lNKj^25sR>Ko{zvIBhWJ~SBV0<% z@FdKMF3$sH?4Bg99KIv;(0nedDPZ2uw`%)Rq*8dbN+;L4Sb)~un4 z#D1mtHYf3QVlI$Nvc4ii?63#F0(b+8i(`*3GZ^x&edu{M%;e81aPn#GGa?np8wLgFNo?PpfKhq%B zd}j9jLHO0!Q4!Q#zt4-5yvu~a&P>pMo! zuTi#Gzk6x-fX~XIV8IOBrQj6-R{`BM5vhM|w~K<1{MQaf^Ummb-axoG@1EUA`HIOB zcjgk;pMIG|1mNl?XkKkx99rvca@U{@kG8(PRnO;4_^l7G$%-CF+1EJq$iZ5g_COH(RCg+cZW{GRvxm(}OxC(dB zOYoaOGJ#GZ8AnMr4E>LO1j>e^6GqQuQnua}zzM=4DeDrkT`90XD5x?)fA;{JCzQuw z*i(>%Ysn>yUuwrt3nM|C3*5 zi)`&5IsZZ|EQbDdry->Gp&8itR^gELHVX+x7h;@5=x{4K9?c`D_&PUcoR8bW6A40? zavR82jo68K{|>W#e?bHLU_avQE4I99+Y6_8h=VRZv6Qsz0@=xlnjNOdW@C^+@@DJs z#8mtJA88PZDzw3MLj!YKMJh4uv2pXu+Y@`I?N95jt&9}xF;G1tcUskss`b=G8 zp6l%w-_m69lE$qBo=v(5;eak*Q1^>M9|QrNVg#57qd~xi zA+W#NCRKk0KdFwJyg3Z1t>J^$?&BJwv^z_VU366R7B4>2nJH!A#0DC59=^A4X5UQxW?a2KtCe^iE$0|RfiFwK6$sCC*DJO3>=U`?gFI~`uX zr#Wv)BhORFK}ND%0Avnk*Du-XAb7wH_GhWbU}hwxs>}Xkv3bsZe(J;vNWrtq2C@FU z#^iFSbA#Q)(|GPXentaqPX~bnH|7dJ$1A39ayB-wWMersYJ{4Bd;12bf7j=#;dqw+*d#mGLpu#P*y=9duI|pN`cA{b}j{%?n#Ov)tsD*M2!$iR%b!1kI^AhJK=Q{~c(U|S4y6XqGt|>kl zDF0ZZs>zJ~yYtF}W&5`Nj4$WsK>`*slkbc}SX6L^{vAeZd(_$7P$ z9y!!8m74eO2gQ6*FZ~w*yf~JIdiTR`C6CrMs{m?h>G+=m56D%3UbUs)7f+HhfA)y) zNFM7465+h{C8HeIl3I&778kEVM(;(910+^ssgY1!1cZ7X!tUwMnxytv_wv4Br-64}$VI11 zgvH%IIK~H z_o!CnIhCXTEGja_Ka*%d{Cz-}n5;9epM{b$ zn*uMxpdNt!X@NSqRYb&OV2&_zWwPj+u8J)l^0@%It$dlWeFheG0(0B|6#6nGa7ijb z;l+XA_m)uiPLm>XbV;9yD1C#${|7GcxQ2IkgsSF zKjGT$2L;yT7z?Ir^&j+{3SA!TMZnJJV$a3gf18BhEk=BD8u`3$tdZj3f~i zK@gxQ;0&B81Q;Pb+7rx3(iRycC~-IYKMoTlG${e-oPbAq%XTvs2znb@)C6IE@|sQ3 zI#d;0>?w7c>v5Wu%&p$0pS~wD55DdM_CGHn^{g~vASh|jn0F~Q*-NIabT-9-q?Mrv z2CkeJg0a@j(f}Blq&r+@xT5g>Ac*)K^iuwAWxR{$YZ~FI@)wqB9P3v|DVwjNk0hl7 z)ar8OoIu{o?!!wuSFQ10$Ap%x8sePigb-We^JZQ1`B)w zi*f>Ki2>qMRqJ7ZF2VzPQYtfStL;;kqXg)QCF!eHNKaKSb(zNpWy&vA>{>9K=F;M- zuZ2(RhvvaWr6K>((n!bksz~X(mbi_R{vkVMOU#HHNCD|!h=Ym|z~V>{J+`U$5b~t4 ziGJ9Y0T~yb3P|Y{fu)Ps6@jV7GCf<6M}Pj6>HO4iAf3Z+VW}MBBXJXrt=P?62S9i8 zRSFF*AK3cj)Yk(J!?D>S9>=JlT1q>TGl56dKvL-DPIW%yB3laIdQsduMOo$v^B56J z(f}&xQ_HjnW#i`!uPz?1t5nEfApFDLQA#?ljMwBYA~tPl?%k@&WGNRJF8S()aFwnI zJgaf-Zuu^o;3^DQ5keonmLh@V;cZ0_d>!ahs?0D!3hxUaPE~&a$ek2v5wjCh+eUrL zW?r;Sb3i;(AAWJS;h{1qb@%(ILbE5Qb{3@cr9(G$jDZo~CWUCcicb5!*z(81QdqkA z8^_HLLD2KvP9^cjj*Xp)VpNqC7& z6=<=D)T1;H0txXD=>ft)~TJ?+Tegp^*@@~OTF#8_pw zhpmA-P^d&h&_-JnikysL9$PyQfDOZI<74oU#wUv6Po?mkRJ*Q!Ys|8Z7-TUwDX5Zs zO52zT1KCNB!8j;A-iy?5PM-+069G$Op}md3RKnfu#=DkeQ_qo8DU9aHlNG#6Dn$lh zarj+zYN#;AH*?VXDiUBsm)jPMkpJkhCEcsj>dH4SZ(k*tu^@}nY#(#cKK_q+xjR|tVJaM$%~ZGJdknUb zCJSf;Wbt4gBp8JQ*Z-6`$i3-2<&vjP#%B4#_77NVewwK z_}x$*mLC=clWF#p&%G)2W5~m(Oimi|y2dQ-WkKfg64Q7^-lvFq#+gSbJuZZ5=ehp9 zuGJhhFh3S3;_QjOm~zj{XBZ}|tid`O!8u`ojWmb^1+*isi6X(3#(iVg8Ab#}O9>sL)M&;hTWkT^h#^dBDssg42u-h#8VK}_|MzUcwK=6b6|s@15c`wKR2 z@O6gm*^1%o)Z}5uG567!YZ|G~w2Gcs;x|#4r_DAegJrIK;0@YF)1|L@|KYi+6v_O^ zwWgj}KY4D>I(`4s%M*P4x0Qd;DvBcQ826N!F0q5r8^23>MW7m#iWPgSF1X}{*F^|uji>j=jU}CuffvyjqaEy-kadRq9TC^ztQ$ZgN+W7GR%;6N6HX# z{cv3BGNV)HT&fu3Vx%*(q^h>Wm3GWIiJEUk8r;3|BAEA1!G$AOnc&SwBZH+mZwKeR z-Wc|1V4$W?uR%v>n{T|FldV}B>%rU^H?}H(3HqV9fc(95oGqR%hUlF)bF6hmX^>nN^P&YPnob9Er znfgt_s@$7W#sziTwgx$(BADpOO<7u7-(_joudm+E(alL5TP(jlC|G=xmw0DSIY*7~ z@#}@qz4im+p{hvM$7BzXZPah=t4AvJ&FQj*>BtDqJEx9Jj<{%1qEC;x#bke?>OI$V z36i3IU2ul&>W4=~GH;XvHos`+cH8dMj0AI5tIF3q|LZcLEy=QeuT+3xndn#C6k_U& zBJP)R-9BM@@aH&p+A)oc|G2D9Pl*f3Dm#2SZ~p$W_{$%!o~yUOIAmW4yTBY5(>rwm ztp}$Ezg2bJ+0A$O)@ShRihOm_^V>Fx)n8t`3l;>C%xbys_d?I#$@y=0?)cG9ty~=Z zbmv?|aN#uCSsxmQBHge)jO^H-PMiYB& zoA?!L)S#Lg?B?*u=%|_oFVjbI=YM28=rmNrP)+q{@BxFF*fQ8mEV+;~CUi?SgR!k` z*d`l9$&yb}Tf32oyUWy;)Ka{=I)${`d^v2urYPMS>fYtnW#458GGZAZ(m0cAJ@0>h z67y1+ap4IRJ(p8jB;wChewl)th$|LCpUCTRm&;xdqFp+D$LFXRRW-|Abrr4QkLn^C zQ(*OM2MWH)5!sm$MwiC>lVbR_Wp|1Tx1hkJRWa$m#rfvRYG?38=Zp7h^!qR|VI2X@ zI7tavfYrW%Ob-f>RN;rRp3DMfzHChqV4ir3`crY>&3yUY zdMeWF#r05ZA~%F80GH*OBqnP)RNS|{s!4>Q>=vFtxh)ShfeRCCm<82VwXRlmu1<_s zTHh_qT^Hf~hwIe-57Rm4bew0F^|>iGT;WI*L&8DT44*9ryhlA`;hca@Br2?+s^Zs2 zcI7Mt?`cmed?MgF6rRA3PE7h3Brm5^RjaHQ9PD|`yDlKmY8e<+o;b71Gvkc66jx_x zTNpG{fumB<3~vmO@)h=Q|66myT%4iQn(!Cut!S-W0*h@6eMrDENwjs!^x|>bHEA9p zFaLmy=AF!BKd0t<3j5_I5Z1pwUnkit|2Tsef3j!`$Us<|g zX_^LFrrjs8_&!e0R(eJz^Ka7Ll@W)#1fub`suQBrm6dHdmGc7*9gsT z+`b#zaBpu;z|1unXBCc7_8uH#qh`}0-k|UHm3010U~98nlIG=R%gtW^etk7jy=A#} z{_2H$Y`Axw*0+u*k6oOXM9%T4lhVkO{@e7sFhioE{jyaLv2+SHbRB*wwI2EK`ufQN zHOY;wzflSJ>>aG)if?p)Z(0T%K%W^n_-w4kP0xJv%0hu&PGH?FZToqT$}?KJ)cn@a zAXDs@iXF!Hkab4d;4WL3IC%=aD-uO{xTY^N;cDQ)(mZiG!@g-Pu=XtO9mK3*u|w6W zZmdV2KFcu9Wc~g}f&B4kks^FBIKRO!Dg_2&L+-~D>Y7cW#a_LLEw;*jd zrtyC0)e^mRy=nJGdF1G_^&Wh$UkwPiqLHqBuAfXKXAP*)AXWtvi^W8vuJV1GIxH77 z@FvIf(9sSqmbKVYEFeEKbSgQ$I#V>zJPlhV&(pVN`%S2YvW+95Dxw^rf57_?>5_|*2Lqy1s- zICK_)BpgQ2>Cw_kI@YS_-K7pXqw3vwSA553Yw-HCKAKYjl z%UoyK9W5i^%2F6X;jY`HWWSN%&Gf{#kdHsQodMWMsM&`+zbC3Fx-Fn(c(x#%oa^Ca`#NISra9MlB&HP>bSDzO! z;z6zXYlg0B(emME3Tm8jsCWF&$IFkoRhZs4q?UyEB6po|Tq zK$CD1hd=!7ZLJCdvUeYz76*?_cx_uGe-;JIsO{Bjstt%vh}5!smIMVbHU;PYywB+) zy?>=~C=D3?PIABUs}%O9@M_A=*aOK|IHXNzs40I9<6ni#bzk%U-2Jv-PznGWy>(2b zIEmuFVhItWgK)3qQ`<{6wKH0oFDmA9sX7UnwV}ZAw)rd;Dkr#S;?JNEVKTG_LFSY+ zmVa?7ylXob2x{4Y9X>PVmp~(W>7JTPa@ENj&gD|Mp<+jedzpygs-Ba+SI!T=Qu49Pl@Ra$<_`(R3SM!xy5nf$%v13Uw%F-r^ulnoHx-U*fc|- z6-=vB{YL-^2ht#(CDaHTKs{H=%`!u)6-{evy*>j!*<1p#ja2s?pY!?=Tz%Gi|8wQ+ zGM|7pMa8rJi=RVR{we8-3f61li~kL~U@&RL!HB*or<75O z-sL}k76Hc7E~dkQ#OUz%9T+h@;?5Iht=u-fKhdH83{NNd`H84`h6n=1#}w>t;9w;X zb_+GAa~$j1_lxZ^o*+Z-#Qm_`W*@O1X&aZ5UP$@Nbz(4>l=sMEA_S0wsNDWFs?a5a zHVv%flyy+4Via81mkdV#k%&o^$gjgJ&qokbdXN?^PG>kR87k1v7oGwOajA0manE|V z#d}P`HKHSWE8Fqk!`zn`-TQ%H=5S0v0Q4S-hh2k}jUJ?iQQLb2vCz&T4zYP|g2y@u z(gLQE%YN^2E>tCWlw(aos*(izkq9aj2S9a*Fn?Umb7%O;;M0vcnnV{Se}>&!yFlnJ zJb(nXo6Ke$K#(V4>pKMnQqk%y7O>LH(is8SyULl%`GWGY7Q>g(VZuy~Jj(lDu?I5+5 zA|xJDDt{DGheKU#^1EV{@W3+ojXYJ~&3~^7U{2atsDK3(a6Evi5Mib=8Mk*&ivz@9 za%mF9=E@M4vi2FnGfqb9yc>M{PE0X2HDWB(4IWhFay;4$mH&J)Rhhz@AqVZq4UXsL zQck}h(ski^C<~A5ImslK|6)P;>XOjv3JIn*WD}Nz$=IAOgWR)n&L#$YC30m2_5=o| zBn4Ks2XbBy@L4wc?$0J>M)9`5y*iEQ6=E!3J z0wxP!ovK7rXZ%WM&0qg0-$8+^ZY8bN6+#ETqA*a9PCx<>XQpO_Tok2Hc~z%j>rCw% zGe`*>VvRZbmtJL10+l5|y$|vyn(VzERi9sxi)g=~1m-6CS2xU>%M+mpa>c{y5+N#- zi)xp+1$tuQCGa)J-j*DDbFnL^K>*$09alAMons-xT4e@3m+1XHQ1A+15kO?#{ex@i z?iKyPv+Kd7pZt<7#g=pmn44%%0D?%Su^d2~V(|(j2o3`?u&Lo@MirL>f0q-7tQ%hE zB@@w+>_D6j2_R6ZI9>KS0W~yV4#W+Rr8Y0+DBBJ5R{`hMMvr`6%FFV6y8zmR17tYz z0A^TIfg{71L`hi^kdR*?i-X>2vMUch(~)^5eLc|OTdRu@$?wr=j`B(o`nlr_O@VE^ z!-P@+qTMYF;3J)tEOQA>76^ZQc{Z+PO2<+~sDmYgg2mMv*3g)41XyzG!=JD;ulCf- zXT5klvb$}tyuA}bRhNZ&yQeC79+mo*Wh)YlzZ2Lk%u-MC=M-9Wu-U70HW!uW*ys4 z5R`h-++9wy3|$id0tZ;#NPh7vT;I<~UfjA8p?Fj$<#xHUI1o z>hI%ix%Og;z#|PBFmrH-d*N|i=34RcL(O1U;H_G?vXh|TPY$tJ(e{lKQZsPGR%B;l zmQ7W-7{)?sucdLP4;2Pj;vgr&C=4AvP(r`GguNx0SH0l)Eu!8!!R#)DFPOQ>qj1qD zxB|1$IwlFf&vch;)@k4D9?6DyGmzFfS>gx~&)i#4`wV|UiL9Lx&esvS(7Z>z3~lyC zwdPl(ek~XMHDatilngcD86pFZWi2T&EK2Yac_^ot^|k-r`2~6&6Pz~>P`jAP56~-z z(5Ajz2iLOBcd!V7sk9#Xo}_@yBj}worYcIp#wMCpOqa8n@p!BBcS7MUhPWabt}Ktf z+0NBOgLUU$+4z$A&RyWdMqOv8`rsE^rtU*&6ME|jQjClr*gFCA!~J+5HoG`@y7|E5re1ox{-di?w!AGa8V*je zx8$IbG-s#YjJ!CQ&gRi%OErz_fbXo$-RBy|4H*MJHqX&1n$$q6UutYtP_|pJ*dI|c z*kB*)Y3K73%WbVG>}CQ@2AYXIFi7K z5zRL3@XN}x3cZA439CDIp?7Ti!=qR)X~d4Mo=0yozxan}6Q_B(07tOrQ0Y2y6RapK z{<-6$XGQoy3mIdJHA<5nNl{6CfDj zi(tI42y4cX(t8EF;tbud#*?13bnsxNHHAOAu~!TX zHp2`yI)jHZQ@pm6?c3lybdz4upT&b?&XqyGvPcP1hn)4w+uoii+k2637;2Iy(mn1n zv?FSq?+mAEAZvAlOhGcm7u@Zm+=Oa}(;;y%8-~BQQ*Z$M10Uo)X ze;%U8zE&5&F->L<9_G>q?pTt5&wDLqn5&9SShnZ45>KQ@x1Q5l$l&Nqc|}JPnk@11@P`vV@FRyT16_FsiB5Znl*>4 z8dQcb2(H$x@o)Aqg-nEn+}$+$?5uZNj2-4ioKD!IVEcLr zJcAqKm-{qM9)Ru^(IkK;od2Su+4{|Wgv>v&vK`=;Fh*u+3UA^xjZ$C}+bkH85*M-c zi)}qRd7vD(wVgY<611fVIiq^(-m|~CBQeaI9mGoHOu#|6?Wvl!M7&buk(~NwM|jFM z{n?zt;AHIk2pxw9W@)NZp`r5?x@r^{n8xmoN!Lk+Q+~q&iYxHSU<&4WDQ=zO_Po>T zwZIE3O8$!Hzg!rJCp#NcyQylo}2IS2SlR_ zY_Y%3(vz2l%_`ZsNdP|ykob2yW2r=iFz|TxEik*w+jRDzQo!w0E*dvq9{JYLO2LE( z-G7eN4TBg{U$|2)z8cNwN~Pi7Lo-udv@yWJAN(v{xMo$w#9jPGDLbMb`m|vcM}`ZM z`Zg|9s3;7#=Jg;PoC=EH7jZoLmipX(ogYJd@>t}9wo^2#_7OLhxGxkrX7~$+JJ<-A zjgk4+$8=iJY$}9Qc-anO7N*DV3k!cXY5nN&(NYK|y9uV^1`K||#5X@?UjVsC;F6O7 z>`2n2Ab);!Q0JXX-G_tWEuLA1_;EaVT#HYZGAA7lyxy;7=zyyKCT0J=-d#gFsmBrS zJEWgT_JfBo}^D-&wqKy0x`tTpp6cUP9HoMu#ABjo>-8$k#+cr_&L}_ zs1pnQ&ia+6vaf^73)$z$7v4`u-adEv`*(wjN72$&o);Yo4M@Df9kFQ|tYN4SElf>T!x~9753jeNZ6opGRKol!HBxHPhNgLPy`fEFBf1uyxp1P zI(Z*JTe~PvTY*c~D4jW;WYLl6?sODqT3v(?SZ*Io9%lUF?K|}UXOzA_F^;)Zvbc2l z5)ZpHJ6=hZ4XVL~gs9pX7{LBt#rFTXPf-7hciDJNK57`s>hz^M9syt&Adw*`XZe6j zF%y<{DUVg?SN#fkYlbf)??^XkV+Pw|LKLb@T9DbMV{^G&zGb}je{>lt7W?5{RxcBG zr+p+ZJVKTLI5-@bv@k#{9W*H>f3d)cjCK$o-J_BnUo4;hh*%J2a`SlkNq47(Y~v$% z<=I!-UNlQgO6&iXcP)Py+(3 zSh>s{P=Cqky`SF%H7Z?tG!8!1PqGNz!8{o{1Ekt5G)FX_lM>Mnw8JOSGxJyuWQL5e~!&;%w+t;#Vjl6QI28??_8RIGgvMFH96mnUm2+z!05)Yyn2*+)D5 zbQ5f78?Su6Tp#LjQ&Jj!+MjmeKD_m%pH3GNX@^Pgs(r(>gER)$VmbJJkj*$=HP~Ec z!CEmaiR@&`a_G=E;f>Inx@ZbqbDWXRbrvH09#E5yGrJa7a@T})QQ=cW{v7XRQ;yYB zIz&DXSg(qdo*2db)b%RYuyHP(+1Z);PvopIM4j&C5knE2DMCuVGRICZZ}#dPGbt$9 z0w3ed^}ondBonPVUNi;)qMjl7G!mkeQ{Dhmtg=?X{&Y~jwKmoSkSBA^cdu@n zc9mnJ3Fxr9Y-w#@)A9RVh?z5x7Z@^ye7j#)J$AW}Q=`Tz{KSeS?C1*)KlL!uqKM84 z5g=0dy}!?iu$Z!aFYX^pBNQNdZ|>_>=)~51-&iD2#h-f!(UPAVm+`BA7&~C()Qus) zn@R|)&5XiUcpL;yxMTOSs>uE7!{u;Ox+$L(p0tXQP9Y?(S`**DzenUz%LG+%#5991 zDB3DahZ1_{uka4p7-hBqNifd=#GVqV@J~d9wL4@2`vYUJVT^MR&<1+g2*>l*Oqlo& z<53(#qpANG|6|szmw(g;ECLA#uFg8Ax$jIHMU$5Df)}lukuD+a2bfPt=#yu3)~pB$ zhNxyt2CBAl7zwl3SovpnxsAzp@rIOTzLEy64zx)hC804y9z77i&TKk!j`+jEs1V^} z+j8tg4x~_`h49}A4vC0oFL9N}RGR5fKJ9dL@|X6{^^{oULJrSyV%7@#X6na+iQoHa zrsw}K47dr+`-PciKda1=coqH6+u>$K#&cLjCARojJkUy`&3sD3lOLNCEkptVA8e=p zv*>=vn@`e3(m$$;wLc+&L-pdq+7|hbEm*Nc66@ZlEzW}1w|KKTiF|s-?58QbJ&6w# zA-TrqGN~HS14l_m)CBw;67o~tyxLrU(pE(R%9%?+j;x_XpU5&zTk~bTwl7N8hVS_V z`6coCtejtY%m!#b0RJqY@K;VuR_eUtPB~gL;VZ_ZC5ukLymf0~-_{I`AT~9sn)wmM z&Skw*^we8<#!H)V`mWbhKs(8f^Gk2<=3CHnjoz7}e^4Ou2IK}>GOpFj&&I1$5fZRz zY;uNQT2O@95-xhW&UnoRyz>@z|>VHAc;_K)8LJtB?Qnb80#>x8X-Y@>v4iE!!&g0ccf-R9baQhvW9kriIo;)-CCdE|>xtXB ziT8iAh$SvV+$qNG5z{B3jBrQ_#oq|r1OOT7S4UW7-XLUu;t$U!?fjuJF|Jrb-8>U50QT z7{l;<69rHl6z)NSz%^Hr_ohepf)g$Ty+8MgOv&Q0qcq#-5H9>yQ+Q^wdFKK5!O5g9 zZpe{s6*4jt*}dwG@gZHgm}Tzivza}(c;+}>lOyvKEj@vmnwlIOe9p!AV_PQU%;=Fi z>^%-VzbOb!RI~l>qw!5tFU^3NmVSEoC;wOV55TjZf_#trZzj(F+`F#O#=q~bCC0F5H!`pL7kk}i8yuRNv ztGFH;WE)VdSG(TZ%SK(KUl&B-{z~1y{Ur_AVB2dLWyvc4qn+c6cRhBl1cZZ3%% zV|L)O4xj#hJ%?FkpMdEDjzw(Tu1_13`4^Nj)a+K9IiB7xSD|T0#B6tOKV&}Cw&vr< zp2}Vtyjx_L4n6Wnu3lzIOuubJ|5(<)&lE8%(w7&W`R)~`vtJrr7FUTgq2u`1`?|OF zCj@z5?VNaA35>{5OMXq+Dz{!0Fl@L?V;Toq5Ehb=|04Y)uXNvV30b751UG-zi?s8~ z;2!TBqnuk6Ubh=AxqHxDZ2k8WRosmE*1%YL{QF!bzGzW30lj)22R}Z2&D!~osrac_ z+wfyghn(n+nv?O*Tfb#3zKvuXQ#Iq^ukW*&@;Mw&T!971n+k8zpjaM40+RR(bnWkP zhrRmfbkX(`?q`k%NfPs2EG{FlU&_}^a20ReC(zC1>AKNJ-@f6K!BVWl0(){No0 zj*5bfTOXxotSq}f%P{ud5DzFeFh2L;(}{A4U{|7`P@Dsj1_<|q$vEimj1)550mP=V z;5~i@=s!GxUHJ|(!$k2^8ohQ6NM$g~tm%9JR1pRJ1d4kS35z!(-rcLi2|@qd&+Dam7xo(@fUyQ!cZg(B|2^kYu8EbWMM z^!_O<)+H;!qhHO;L^|jH#*?OV22py{Y@L*ae2IBWJsOMq8YyjlP8#N(nNEXtpdMcteGh(-@ z_}ve&&sb}#!{YDUmv94W+)R#`N!;U3P=fieok2;_v=*B#{ysr+<15S!RbmA}ZxZ3* zle~qsLS3LJ27ta%&wuzGW;yNbtaai>m5epApsvj9aM(x!1CtemJ@^ilODd5`iel-{ z_`IX5u2A}T_&oD1^EFM=0T7kj1f0~_+JkcuEcl!1G9N<4=WKH7N z(!r+16kgpF`@C)a?BK$$jFP9hms|uZ{-|NNHWkLmZcXu!YvmY%!g)jzl_gyYpg;~Y z%Hm4(ZD+H^4$6f4k<88;1DVt{pmfn3g~L?+#c2ON2ve1*DE4&CWD@iXI&p808yDUIwnLjBhk7jMRMIV?HaB<5UwQ2Gv0+Ec*fKyoY(q{a#}GL z5=s)?pv3ee!!|+buts4r+;yl)@>`>7O`Df)3p81yt*nJ)BZwgQD1HWw(5*bbYIAa_ zmNtZ+3K0@CpiQAI#S`)lR&(iXn%8KDieigTvLi~UJss_^ybOfow@=WS_K?hox#O-S zHPo9>1g0$(UG!m~VZ)l1GTQY`AXZcH2z4u_B?H}VYAI@iA+=*$BQ;z370rFf@GApin#YOEaQ8wDBya z@j`&dfASSi=dQf4De?T(kxq1YrQ6vi#7gXsQh8FFhc+>_X&uK<6#5%Z=F9K{;$aMC z{0)s_;_XP_2R|T!QUAO9O3g;kEp&e>y04v~cg?FG9o82h0cQsDqn*9%-c376vMgOn z&7*nsaENMd0QHr<)O_?v_fZcx*QGi-^k*!FKxh4!m&~B{HT^*b2P^)PU{-P4CchlYZdLWpkyaV;7-{e+I(4FsYaq?t+TjR2R zHLpipjkRwa-AfHW?pD*%mh1baGo$pWIPy0b3EaHK4LY{syloBi<_B5Qpy~(52j4c@ z+WIHdv_R)ZSJ%}`3R-wB`_4~ipUGmr=0<*hOE}DN-QVEe+qgbUp-y^oIfoYkHvY2L zhO32o6)($AkJWeiGyQx-1cyrwX@+y%yL<8S*k8u2zqy0A@d*^xx+bM2+hGru{5IK7 zgB;(PqI!Qb4EeoIIgc869)mnrUda*Q=+tp5GrekvQebs2KGZ9$NAWg!BnEyDj>lZ} z7sPIBvbNJ{9BkFUwEYhJq$Pa>pU>Xb(z)uQ*eIfWd@^{1;U_O&sxMR5*E;P6k7!EY zW7DPqSHmal{kd@c894goOHTrT1b@qefs==KHx#DM6Q)G$q<8jmO`nJmho=JWdpZ1J zRp^~m`g5y*5fczGVMZg&xtd=_b#ab2`bp&(#okp&8zPLS-7@VlU6_au1knMasw-l~wu&wB_5@UdJQY zQAlpubjt`+mVKPsLr}CQaEy(L>I1ee7 z`+a^=*J`K1QzaT;=kS62wED+zIN-f`Z}s)%6FN^($3XRdU_13`2ah)YVqw~c=eEAK^28^@^(hfWM{}0+ zHAkjwh74CtgohCuQ%2yjE#SO?nD4Jdwq#b+ALHQE$4MeG=Ut$((CQul@>cW-7ap;F z>;(_$Nz~owoyBbKz8A<3n<*qD2W{(Q*$C)c%Ik!9)D6|ecetJf1HN#Y(GlHxEr$!I zM3%+^o?ARTb{qJ?)=a6f`svIq`*iT^qB{k`Z}>vCuURsoHj zpdjoI>gDx!PdztJNbL>b!)Om`*GmNm&MOP(;>YTLZ=xwRB!ma{TBGH+ExS}!yBDum zsau`tl{;5)|k?Ltv7Or{Ee|idbWO?r2#T!WW zIP8E`bd>A&w3n_Pr>%BTi({$#JF#cC51(vxpL%VHdBI-{(cy4#``o7HgGvS7F6bc5 zqQP>pew8rvKZUq8l&~itv%#lSe~R1VB$2t;OC<~q{3w=v^Ca^WG$(kkPvymjD_gg| ztclpY?yP5Esc?||+J65<`|7a?9RYgCn zM3UOl&YrToaPGP{;0h1tnxioi9E>q`QVE|b?X`i#}Xy-)(T%8W(|M)IX zrDo^FCsa|OI|i`j+;ucCDjLpX|LaPrMl+|LJ0foa4;(oqqBO+&gVv0WtE!5qfQzTf z>LT8e(_UQa&LRIkQ2w$r+m1{G@Px0a|GgS6b{t8C@puk= zsk|9{gYt6!Yh);RmiX+~J{UmL_uaZ$>-B|whg#x!P`>j9<;eD^KGzv0Cb^g$#r)-x zfYxq)cl${Fk?M8n$~$=K4{jPD*$)(a-1%_jwO`B$1^lG~i_|isvjIbJ$vZ$I-nJCJ&tS#vgevGM*z?D3wz^`7cYGAIA{vt z&+w(+Z~(={g_c)$XSzhNNG&Z<(IPFR5|^c{J32+4wT_9qW94A^Kipjlu3Ri$9^}I@ zWzj4`H*U1t9Cnn@L2x6nTuk#wL!w@XkTF8mGCw`vumGoH6e00HD1uSvf1B;y54@QW zz1_F(-U68Yi~oO6gdh8V|Gn88t{TKhuofy?avAGIZ_;4`sm=mW^K093h7)$Vlzu{H zp_-?ih_=aqUj<7553DM5Su&rD4;REp-{lsEyUR|M#5Hw15V=hNY-6PhvVdAc9jk1c zyQQoM0tN495?0LG(jWD-rpW4O;cAWx5#Vw>B)-Q3YxwaTY3gvayPba@J5b* z-4WLodPQ*dTo=sYi;mEe+sceG-YF&sv_p;2mMLm!sQ4;5NppES%!Gz|ruKIJN&1^c zMeO17M*g!V#&%lkTKti48f+sNSKNv5Gm+t%p=4xm-UzVFwg#*})fbHuO2D zzF^go^xqXK0}FS$)4i{khJUOktZ+?7v)kvA< zmMPx_C>bcv6zqh+{*@#_{|8kv?Jd$T5;v3cSsC~Ht;WG5=Ck9W7* z(SrH&-A#H1oQpxGz*G9CyUcxXLJj`4`*V36+TD}1{_^y0We-QTpM~(uhB*%1*=u1R zGWl#eip$hR@QYvoj#s(OXTfW>UcPX?t0=hmYhn9L`pTPu!|C7;f2ZLkC7&)U#y3YvtsuCQPe&DTy^hx4#>^+IUpKMmCD) zL5BD0%Tu#V3VfPsNJ=-}2slijV(6}0L0I~|2IV-?ee-VHt~Oy+rHVnWvcZ9wl+l2k zS=TWw_o4U1oAC4byLI_e=srsj(Za%b{s8hQVNl!=W7b?Ro-aG7Y-^yS~IpE+p{par& zLXN(kwupiW8r@IXH7mjF8ei3P+nVJZNXVBHAi3tvn5e~GH|%F16qk0z*gj9^-5U9L z;w3Hf@;A#nu7A^_e%NlYNZstX&Vz)b37Mv?lDyD0j66TeB$-RI8xritI*n>f3goX1 zdIi7&)#~pLl%2>+#b`g@gFd!N6q#-!X8jnenPJoF$)r&D21l~0Jvye$L;!?3YP&D` zzM3~|D|a!b;j4BjrU-S}!sNXF&&`BBly*`6WH^!!IWoCR#k(mSRIo(T3CTKbf=59- z*({9CM!g%Ekm{eHYr8Yyp(p2gp<(`b{~cq4C0W=@oaG#_KB>f|p7pn?SvSzU2P&}1 zG8EN_xIoQls#C&pX;X}+ERJhklNG&hCOb`}=kOf*DOw)}YLTtcb_N9*f*L_CyWi%I z1?HApMZZ=W6cCjbRb<8f@K^boI1#MbOUXYdG3~==GilDMm$ovHVx{S~4ksY^Dgexi zQdzVI;)YkV-tAUVYc!n_-oIkIT=UJITpUrCQ7E&`@d#rPrlIVh(|ktXg3HG05-lB9 z|HYx(tR$>BTdVAzn+XBNez*@PY?8#T|C~{EGXZ;sb{nShmVe(HXa+WqjIB)imo7a< z6t^l_%dw*j(o0qYY$9^sbWXZmIrX(o&~65tEIT2W;;KB&)x*{*?RuuZzf)0pN0&?k zxbcs=M4q0K>7KOyZ=ERb!`{mhE6EE9F1~tVd=5T<&BTSigb;rA5cI4|P*oI8#ZeCh zcqKGMW-27&>|R&4rR(r<4oE!V5llb-$%Y*r`3Pll?uB+M%c|yyXQ)Z;hLys~&t^By zvRQt+fPu_dytajJWyn|#d0I9P_}#@ABXXrS_(~oRy{aol$pX`lWeL29PIC_v5@ap^ zgfa`}j9WDAu0_pTKCU7j&otTm=W*YBSZ#`spQY#DMQ>eMJ0=!(wDS(c5DxSFbs(sk zIkkjq6+C8}FC>je#)!pX*e|yP;8Z8oA(Mojb4sid8(XJ`VA=)7MQ&-gmc44l2sz)> z&nd{?n1R=PPBEK&8*M&iK|J;{?M@j%D?j{MS1%3WO#tI;>o|bMA45$=ZfIG$|9CdN zg6((~m4o41>j0b&al>3@I&aXY7C=Ys1F?_4ZM~f}_=hAWv4SO#4|q?U!v*z62>p2l z_n*C-nQG}vJIgTp%|*X#608rny;kkEX#W$GzSy-n#us%y;Cf8nmXnvk>4FDu>1mDL z%4NzAf|U_8d(6r3u=wb~0ol&k;+!f$t0$8w7rd!50_#U%)O0$;sV}m@z*pTqM;9)O zIrNNM*%P^@TbA=JQbjUi)W%1`Zg8IiEkfK|UzddKvkiO=Lz{$(4rD%&xiR}HIbtmN zN%ErXJ-5UtMxy2Fpj`Syn6?!dDQpFew(u8pw2WMow$lC*9zOc$?^V`Ct;-%~j`iFH z<+cZ!2CLVouQ{WzBmf&tv<5WI%Vql#Tk|> zeDF<2F|m3N!Ur!B>$F=Qafxl!c<{d7=VN1nHXqATS^jKl_vjre669GWO8z zF2(x3A4xP(ogKiL^SnlTQzvZZf^P)X*u#oJ8rsw^dWwd1z+ zS16sgm<+x$!hZ9DxK*d%G;NPrc)`Q%^s(2NWBA5t4yw#8ETKO{u%PQ%r;Gk7K=&osHN-b_bySZiy? z>#gx}mPHu~D6%kE32LmPBpZo)28R6*K3X6#H`2u_Yb`qNJ_rPmE_$K(>f?a#A!var z;fVg2+2h$rNTj41=-m$wAj79`<_whrHLGm)i7=*Agj+lAkx7oj3g`KBs5${k>BxNW z8hYcNGHBuhDW_y>$CsYO1onf%G-x0Zf&8jaWaeZ3hRqNcD@Kx!vNEro$+O?i+meRd zewZ~pW8W?hscsT9G&#l1$mh#EvU!~V^QJ)uhQYHm?%+vVCu36yZIhk(DRt@*ZG1K-c`wOlL!gsgfPzREf+_A-i@pgz?`-n2@PrR#VyP?ND- z0T`?#Rc;Df*bBS(!J{xfmrt94Z0^*Ixoc3-2I%9JKYS4mnY{E@fa9?l#d0$$q`yd* z$XuLW>ZI#tQaJRf$MtcTzomKav~&1pMLvc)ND{a-XHzYvvMuTI4HQU1zo`x`P(hHR zYpUb{8IB(T!$^=`ZDB+|T>C(AriqWIi_9lj=2mt24E9n133zL%7YVcE+JuH2YS0)y z-z3Xjy4d1E%2}O{piw|+6u#6k#3g0(!aMn6A$b*C{)HWo`~tlAbWSEZi?v3&^41U2 z5ofHPxt>N^$$141V7BCxI?{6lP7~yI1fWSJRfigdh3g_G1svotY|Ph`Iwt)ZF_X&6 zv&6_WNhp3-V$XM2-E;=c&(JxwU3r_k3O`almxz`CpdQ4EJQkpUyH=n}bmurmlOlKJ z08M91r}8N2y*`$FFycv-l;i2m2D)cPgsev zT!v)&2^LF;7bH3=HO0SKu738UVPDWDfC!n`)Sq8BP^~TxBIcfYBHV$1a_lxf9FPX{ zFB4;qI06ppr>9taNJu=oCH#csl&7K7Y`OS#Z{1OES4NA<6Gf@c+}E+$I4lL5%~UO*opAKBU<-8E%-=_Ghx#>m8qh>E#^& zs!8Je^G%rJMvgwybMmfToD7K&>TcHUZvE9o>u!&&>F(-=IsBiuBpze>xL-Ibz4JQI zSYXpE{iTz~#7LWh-Nv>vet7-usHuGiX{+gNMt3xZbw?|9h!Z=c@kdu4ps$>NhZyFC zfRnh_T@`%9XNzW1|C%BY;tk>1h@ z2+i*e^Sb&a>}upei)(+2ZZa-*5RPX-lBu8|38{~V{Cxx15aBeNfv|TFV*$Al9M8zF zQf}L8=dfK9P*8m{ss*Mk^OM)fI!1^9k0cJ%+YAtD29$a->-@ltwO0Hrvc41=zKL+# z>q5;7JL-Y%Kn9kz)B){;1zzZ*c6jt8FPfgow09BV|Y+ zTbi!f4TLiV(ee)QcliWURDtc`GZ(&jQsd^zq|+o-lHk(vQE?!4AbANV`KNOvu9YjEDK+8Cc{!mBQw7#1!uk z2bUESzTG}}TD4(fv_lc7X!H3o26ZKks%#!17W*MLYl*SxtiUeo%Ot{uJhuty6I%yy zoW1NZauc!15DtQW;QH;~=@L8C5#jMRlL(Okf60oV%1`MK2g;4vnyW@!WGO!boxqao z%d9Vi?KSl8mJ>>!b_);t33nb?=$?l-&_O{$#Y1&3$A_JkBJ!p^s@g=!e2UE8OV|b5 zZc4!^7OL^c<#~kJu5f3wdBHe^OTl zl2-4bd%wr|ete;PLuKH4wi*v@R)43C3ZI)H=J-GuIN{li}Wl}#?B z9HCE9;bkd0K)qjBdZ+Ka@U{9y*&7|27MWMm+^;xo3z*@jD9R13?GU&FyOSqA&7^t6Cmt#FkW7? zDqI5kocyRwRLzX&iGwD(2t0kW=>8jYAb{3s!J{q-8{=^Pux07%OCt5FHqVzz2+kAI z*!*XT09-e zM_er~WX7{k5`CfY)gz?8(8`3gucs*(sS9y`BIgDX_5JYZ-#znGa+6#%eDcg=8_MGs z?}208JPDhU$7N7V)Qf~9B<4fXh3e%*-;G3jmQ>n_y&5rY_6Q{?$U%VE&{mp6=FIi^ z^X#=~KEBzIjaPr7c4q~g3LiIwt^b}lyZxF_t|fLKwh^1U+AhjWW1&izaM3bN99dG5 zO5WIlF})>O&pRRYPhG&>echACrQ$8&+5n$VP*Cm9C%2_qyV$R z9l=c;OF5F9ke;-!u6+P(LLxU-4IVe*Rc!{v{y*;i`mgE#5B&X~D>h)j=!Ve^BShNK zAmKn7#L;05kQ8)uN_T@aC{sGr5zp)T4L5w2g7jx-}b$qC{&UB+?$s?P>xymYw@hi#H&OSwk3gHp zb4g`6u#IJP3|{bouIgVelPGbJs}e#hA^gwVEBC5^UmKj+R_3WkmCX;)EbO4a;U*~b zQnk+TTfHyuT;rvcgI!P`Mfd9%W~csplM_4u;ka}3RO!g={q--iaE~pVu&`YEprD*f zD01z9C#H?BQUOtM$k)Hb(7I6e8x%fUp&R+bG)<^o*p5azPzGE@BVjf0_WtjA;1Y7w z;rF_{0%yh70lvyFWjseqx1VU?cHCd}>&$pu~h% z$c`JIjupos;@^=TwhNBexuSpYs-2u8qwo`uiunM^Wv>-!Ao`2n`SPv3p?3bKPh%zm zE3O8w@Q0V!e_|DI#!tkr%p|}09(`RXSU@ZO{LtZZg?$PHM7ipDa(aQ~%$>#Q zxAjky3aDiF&&yU#cPqu~N_-E_kKOM)Sugtw-33anELa&LpU3LARv7Rf!pP~5L@}UYABJ~ zVbF>jbCCc0H|TbhL*45JWJ|}|>SrpJ z&`Uyg=JO-0jQ(pb6H;s`a&Y1P96AwlOoVLP3nwu>(A0xkaVSMEbJw^G8QpYkGGC(W z3d*Py;nS$A-WH|+KEzJErK5#Esi8#MHcuEzTBj)Lq*oDpb~>9!Hq91x>%peDJ{eULgc{2wY(iC=&C@hB?>8I|_5(p0SIZ81_yQV`2Oa&NqXXf3|@VSWa1QY;!4tuoQ}%qP%X8O09#ntTCRt_-U0)` zs(w8~|CZZkrLjt_m?dIaec2}Q$!~on`U7lPP5Be0rRK%2nd9S|puU5)E4TlAdqdGF zcrNwhHffA3asBnklOU`9qf_D5zsGYp^j|SPEvElSjaR=#{hXRHKRlV!Z2k3Xhu;0a zotzD3&9k16ihqA&JTsa96o`6U{F}XLaemG{J3q7ZD_YAl<3UOG%K7YK8j`Sju6%j} zfN8{G>7)qJD<56Tz7sW*)UglPYi3}ICff8~eo%()Pe!tev~bTm4}`Qvw@uV8u|_~+ zWIWv<$kTkTHNyy%<8s=$n88EZ1BhTvCDX6XKD6|VUi>;3{;;t0G!n&zadBUr-Zl^l zw2%-X0Q5oKif|k`+%ZiE)mQjJAf}qzutu2v3VI;0ChLKmhX_NezH~+!nbyN))x}8- ztoc3tn!ZeeaB;)vH@Ud$sfUlaHq}P?Ih3;6^lOyV$fmJrm6>J3!gm&yOn&P=RZl^z z^Nn{aniYRbpE`RetYu2|Nys2ef*vGymUvl(QoztHrZmeXZIu7)Vcq%A8sa;KJg0k; zWuRYl`)h8!V>%Js^>>pGKK}Z4$Pb96+9QUH_hVO!x18C44RlcVYu`X1RhXw(*MFDj z8lfEdYsyDVbI>r5hB@WJ94%-5dvl-8H)(LwE$h4P7S11XO2E7un}ws3*EK)|y^+2b zOSWdx!N=DcOE(PO)6U_oEBWZI(KumZUSHd~S}np*2cf1wEd#$Zm%50fg%;+@RV}MD z6vsptP3ME1SZYI9cNF)+W0GGSLzEsjzKZi^w2&8t5W;3gOek;483R~-9h;2a(<-u0 zAEOVUQk=-aDW*((&BwSc#}z5Fj$KjWPVTVi&XR4b6M_YA2t9Yc;6HmykG<;7)Elfb zoz;-E+mo!)I*G4zeK){?HBS4@*RM7$+)(;i(sENwPdyVJ{G_d9U`k)eFqyIG>}hRt zJCv5E(y`*cjeX2DZ|(JzOVupFBI0>r z?EW;B-_`n>q(3H_QyaZ@SoAxxF^2u-wdC(VUv@-o{Nd2Rc`Id^faCy|O1ioj(#e^pvZtsc@J~4kwg;ZFrqK8bU0=aW0J73x9 zUDhHix>`MB(@-wf{!o55a-SU3BP`2#c|!eCK^rHxZlGh~@TwE(`u%^caWh#-KX(Z+ z2|Deitk)(Cn~$S;Z>)em=NVs?`7jvvYw_wgt)=a`p-*j z@@hglIfaz+2RlxVGd$C;9Y2VUjP7#(j#z+r(^TrQ?uHe&R*YII`zR_IxfeM3%rPEG zMadqVdD3UkPM=ixedg{dZF!%~*wtP8(3ISHCjV)ux_43g_IWMtp8T?Whvm*^Pg{L3 zUk)*}v1{tv_uss4CX!tTwx^6ekc5~c%i+QQ`io4S@vQ8KGrR;a0hi%R;hdLrU$8C( zINnI0XPW6AG5dPsHgXmuJwrd>n7-wW#RT=Gf1UD6_wK=boYLG@FX+j1Db%0$)urku zLR^Yu;cL5d3vRCp9wFj&wLiqZ{hVWZ^F=eYT+X(1?T*Hm;OjF1(BNX8);}&M>aDC_ z{PTIfe7Jv*HK@J4oEbX5JMDR!B}0Y&DP-l*3zytg?Pos(v~sq0pxu-Iy-le<()bL& zsr7trFDoM?(5Gbf!j<4}Mc04xt(3lEPHNzmpt*6mpNbC)9RPO$#F>l^IRmpLUD^*K4ZZwGlGJoET?C2t6#VniKc zEEZhE3uC0aW2hNh`O_E-S1fe^tKtx=8WyWo7^~48tF;uXa~g}~iqlhzGjNDA3X3x- zjJw<&XTB6?c^Ze~inmsar()4|Vet-y@lM_GE=%#Qr=Q~STnX-K37!rK-eC#8g$e%M z2{)Jizu=Qtav}czYzPCOO=Ux}LH{oSAE=VwKrDh)+GULNe?KXgnmnz3mHI!)Z|v!# z(G0YH3ZLn-n(-XTt4%KB&uS+NFdh@7rfvVbj25)_Y5adr%Gg*s{>$wRb5zMs`r1T$ z2{NHNB`T9heS=W=#ePKWL zK2LVFuDm2d=mpHXNvlIitTL`s-A~s?GeykG&3mYi%7w}|mZy5!wr48!Qw1z~+jrkI zTy1uJ-P^IhNb;C0x9IEq^07N;fBAJ^*S8gNEWMy*fA`V)SdPr~>HeM{+p~|%DlDJ( z{@h<`yRkC;yzkdH%22A{l^6YIKX%?UU!QsL{Lin$^~s7WFJJuk=k&+^%FN4`=jQ;8 zB!vj&@TEi}#2Y9vNYx!mEXqi7HIB{BcQu~NyJ0nfFJxym5uG5pmL!_*yOu0j*RYl% z+ewxDFe8%dX(|i8>krko8rIXbPIlHauryK|nFbtw8(AjejT=h;&)5(`1l#}l82!J~ z4Pl_VAqZAIwHlI}UJS}!n-5A%MQg^Qmq6q!vsahsX@lc7FrLFX**qz18_eX2bQjq` z&$Cfsp$viR^HaNl*}Az{ZUL2zY>!uk@$S+WJe8&1=w80}?56aN$D<0}|Afpv-%46H zTx|57;BNDoELNK2=vZg=sCw*pzG*S+@O0g(x_x-z6YYZZQ1>3iF23jProD3nC%d5r zD@G&swqg0Th%klrRyC25yDhgQCyR{bR4qy^ZW+aw*8X?1QAO@`U^TDAhtl6%p1t>8 zWy>$Jw!eMTk?JNU6Vav79RHA~n%{+Uq3_X;j`EbG@E}JAI4@jMdOU5 z>o~M&;k;g&<4%$TjX&2)EL}uWK8{+^V~G`$wzf}cv#McDP3z8G6}%lBb}b5Hy=LvH z@}clUa^9w-sT;e%X<23-YNy~lOME=eQ(SV{WIaMiXBPozsrt-cvkQ5@W~geryD98) z$~Bkoo_>~81YS*I%<`wpDa*+s;LYsiX=!pq`Kl6pZuos=;l&SG?Ie}8q$P5|(*iMr zk3|0Jf?(krM~RSFwW`LtxSMpC0FL7TLmRX{)QrqlS+% ztm*tA43U(5xCE5iJ4uXqMS?tc z(mERAQ=Z)Kud>_wF@ycX*HoujlBzs1>GW52?Cs#e@f$VTx_4bTLD^fA%XTVY7{ek` z@fGL(C+zbYJ?UGI8rK?6KDbH+H@$bx_}IZ>Z2Y(R^Rxzb;GLuWm(VG8)6Y!rMD71m z8We_5Bwtg{+3%7>Gf_83Jv8y(-ut!vcX93J(6D4pud4aQjq4w^Lj+(~pR2!(YP#5M z6!-Y6)j)F!l^Y2UlapQIsYnlh;Xf(=cfenUk9CMKC;h0ckyEFiEd32qbTlJlse6My zh@oX8XXUfz^Ly*ft>-^x3NoIJjU;N`{?0?s8$R05=KX^FSTK1;m-m(Y-$$|; zlG4$_{O&VuQsiUE;=(^T`SS%Jm~W>9^e`q9X~HC=ri+G}Y(h)5EgfFazaL{X8Dz?UDQCDLiM(9gF zUT0eDl2#Adb^sT5%U6Eb4qslQ)t>fXOP%(>%SiY4N`;J2}{|NUdCIf!oG-W*B#shBWB zFRFD@()9P|^z%f*#yX2SrU|L~J=Y-?VC<%VxGT}wH>t;$D@%j>!QVaSSU1pR3r08% z%Usz0ShpI{)P^VLeimCaSe$yF)>9Ws8g}F5uY_`x(gs5d_`QWhz7if@C6`ySsM0{~hjzDzOlFT&dmrUI~#_3Hrn; zp-Ri6EWa^8D}oU*Fq2dYbzMa;7y208!xE{lGSquHG4Q)|IH141LOrVZT42w3EV)HE z{2W+VA4#?>o}a0$m}oQ!o#?gw?nZwh31Fci$E9)ne0=B20KF&$LVt+Q+thcn6BAdY zOFEXMeOk%$u*<|T#=6eki=Q)O2XIf%Yw5n}Lw7#{3hF1)8pJnyKl}}5Kc&#kM&2BE znb3c1O>TzkTWGgLD5diq7X+HiVmUQcbM@?sQP^mtWbZ+|Fyh6O1PkSX_<(^RBo&B+tBs{$%E*j;Ev7r=Se8QJUgmx0_=U6i6 z87cdwZgtu3s#T@0l-(8(aMG?{kg5N*dD~*eFNTZs?(wz-$%=N?QP7;oG*>Eo9vQ#6 zXk*>c6#S{uE@}yQKYitfinDvsryJ&oBy{6JP3Lec<%=@6{3c-GJRWhdfe-*#eEP<9AuD89MZ zJA;5ti|@Q;P%%&pkC`4guKw_#vo&d>QA_=N zk)C%`YoQHH1Q4bsF#sd#mS3|&_po*h*o0xs9^MT4{P>$T^fM1tn7u8ic7ge2H_7Gk z$7LoFU3P=}M;V`QEcZ&=Kg=t5nx8TE`E)CfGX)pVu~Z6E8|@ibjd<&S1>cxx$<68O z=(eUVD!B526Z-5x`(X|yAm!fM-%DR!j0I$@xa_}UsdfD}67|I!&(yaxTKzi}7!S2g^!O6#iq& zRWYbdMT`y^pz(I7ns*7ifbhiT8`p@fKmVuw>`Y^RF#Xb#KntlJt2TroWm#d>T{iYV@vveL7f(8b|UIV!9m3YMy*wyOXd;saZv%F}JR z?NCie`-{Af6n}NfFsBAAkWZ3`mg(fH=@ zi5;v*lETRV=0dC?YQva*^CF)jjWiiRWF|%wCL%EeRsgE*6Qn2>$2ufKMe1qrG}eg* zE?$~y3&fC%4w9nLsBM!>DBvVXy-yT<&DZ0T))JK{xeo+(7S~PDix@=#F zO;jHkGK;DNvy&1#lK}o;s8pR}^b$B*Kk08`SZB!nnNS_;1}2&;kjSidtubyHZ0dsk zUy*2KG2VSvkyTkk4uA^&G&JlWZc_yV+Prm=2YOd;yJXK%kOaPm2RUZK(3y}+Vam^q z!5UpwaKKH%AZBkV!&v`*O8Yg39R0_VMk0wRUl6J3CnmzPoet=JBQE)?Mk(1~ z$KJ>Y+rtFM9(a1((G1aNl^tJ*G4R8 zta2?;?9{%ycqRB68o*L=D^Aa4G9~g#-a#N3P}fyM^n1OH0nf^st!yh0V@qrcsN=*QsFT~=A3Fi{B5vJzFjgfk^RMNXpt;$oU z5{#V%U+1#X@%G4C)E!!(ACJ+9Fzx z0#zF0zM&j{JMXlOaN@iq2m?CLhiWZVX^mCUU_dmPLG&X~YUS&lxa(KPk`A?sa5doP zd#hWR7~|u6f;Q)#7z3TFUYYw;G3UL}rKLiHu}X%BfI&`USv7Z){HRw@fIAax=2+oh zl*o>TGE+Q@-X+3uRy1~?4sHk-1L=?iI(#b>c|fx^3FchsXl~Q`|sCDp^J z4wC{&ASRVyX*^`_l_zGmfy$03;;eq`*1Aap-V=#>nT-lg6_QS1ZVZMim-t9S{m;)5 zE5&pD?M#$^PNv;k8CyJXD>&y*feJ_xu*Wy`@F;tGfi951$^@%>V*oq$%CQQB1q}_` zX@Fo;5rpa=jwN#w021>!s-bZq0-)A5k0C;nK1FH22-o7($h*W(l^WhQ@qaF=8)iZg zB)f7N7g@A-dSiW{Ekqa_ZIXYX_X5Zm4_S|IneJ>U-fEC2Zjtw|nC)#u?vp&79+wuw z98h;1haOjn%7)`^e`9CWy3AnOrGT>LnAq_cSOb&@vE7nTx)Cs^Pt=rBP4O$JG!^$y zZG}J{3IJKgnXQoKws1*+1zmUbcN;r3SlLW6_()p2rBNTHDey znED8cuFJ)FNA0x3^bV_~@j3ktom1S+22M75c+mHWYX>%MEa)r8zFmJlG%9rV{&cu9 z9?`DXM~X=W@E^)${2{C)X0c@LirlA*Dw(B_=tgOYyac6)pY8Sti1h>@J?mFia;J*d zK4(1QcB*#s2I%l^Y5QcaO-i-$A^6u)L#M-)Z>D|3j}349>*D*sEQff9?#nOen^Zfx zy|;lb&!>PtZx-)0jz#^&I2bGW1^6((y;t$wWDpV$jzqUHdqrQ^hv<5}pvW}p)mkZ# zYG)%-mDRiVG~0hVmU!;f>QNlw7#abT$K!XFlPVxZP2a>#?di~S9jn!+V|d$IXYr{~ z`$dCfNgO$X$_UNc1-!3+*G?vjLFs^jExT6dCh!XVi~I=Seo2Ph7DT%*vFu%Su|~UI zWgmoCJz4;ZLW46lD%6NDDGasQM7^p5T5`U6FHeOVKA>if{48q9m*s_yvt+|tu;D@c zr7gXMWVT1c0~Y`fZ2#h!$<0U@3$cv@`Qpg$Rbk#UgLhV?or!{JjS9s*u1?)|gQ51B z;Lx8XGdq^7xEAACbEVnNC1voMcaM^c(j-RPo94RW&&QS>ZmM>Y)j0A zy5+(4+l?+3OqU5WCfNm>y+WcY&WgwBRDskF4YMWZjq%PEu5_eV9WdY0Na)#A-_H?g zQY{2ye}M>AxsWV!&)Oq?@*n+e5wXw#>uV_YCxVqQaa^kDEcnV9h^r^a@D)^<+?kno zWyKb<2J5rY>XXiV&C}r?_-Y{1*Q#3*Kr=j&IDph0TyEN^;6%9IE@*ulLWa&-aRBkm zYR{7I&iuE}XFq9n_7n6cz9aI)i~$coFwmONPWsY08F8pHdUC)0Idx6%uJc?(ST*bO zC&38>P)Xw1-V2X@unrEwK>;CslBxd4XPGNMX`d@noRI{mF*)nQ?>DB8UgB~_)ygg{ z=U%@&>ms#2`jVxjatV;D#3Lu63H&YwV&_GTbNa;tb++8hRXcc$YOT)PS!uFR6hDO$@+Q2Q9M}7dUxczN@ zALY!xUb8Dm{1Pvp(}#k7Ui&r^%&UdSar@F|6$=Y+Oe2(vCZR!a0!)cuzw_6&hy67R z3S{k47w&r{D8W@41$vsMc0WqKF4XouH!{N8Tci@oxk#w?# z#XXc~r*AX(C=;NpBp4kU@;~2%3=sgCa;PO|nozrJpvVg%;j zs&K(g()m9_UHEgMiy>=&kqP5ADGT;wkrtGEi z?6=)_Sxi?_Bf(5?sgT)KH}gY`Q{A_oL)Qtvk@PifVwV6pZ$uKpLVBfm2G09=2%QZH zJkSEr8;jc?9Nc&7(Z0eRch|p;DT*wT-3wl3LvLvVQqG(B<`$6_um#PRg{jSEot863 zCl15~H4NCb`h$Gf@GQQg*sF2JJ&ABeam{@N;Sur2~cMs6cc+6 z5hgdZr5;D!>r&h+pZHKMFZYw)h{$}1|CRQWOE4$E``yP<8?5U|1YGu`z=>6AM@k_5 zk6Ye+AMoyL>PnZzoeGU_T@NnR!v4IYL(gm{fgORzQO>Eh zy?+I-^_B8G3b}FyaUd#@2fb-PQkX8M*2J;t9_cN2XR?hDlXLBrOp3v-R~G&CEsKh0 zUh_Y{d(I4XE&|hij+s0!re40o(j!>l5XAotJtrW+EIN)#)bGAaenDYDp1oo`IF4PB zy#fKzLp(wvz~EYCbLi7&ZS5UTwV?`%%opgi)bff32LY6nv2s&tIUIT3-Px&)G=>YH zhVmID1V2fHFD|(NjDjKqg%2J8y9ZyWZphL1@2H>Kt4k=6@Ly*l3=-gSUkvz@7=p2h z;Cu=ill5akbyyg=G445&x2Z}%eY_AE~lkCK*0cfI;E0@rk@2h zf6O;s+kYY;)?y?VP>GhW)p_cEMU6sa2bdsq-1mKjnnwXz0b^6X*~`RCF0elxv#4Ut zrv5{lQ#G)@!P8td&jx}N_MOC4cG@hu_&qUrr>{{S#mY1o<8?Sm1=iBc=YZ*nKI$o=?0c3vY zy#`=70@(q?L8-ARE2H{c;W#B#Q-Xot`C0v>NY-C)!F9(ew)eT!E%S69@x$0LB)D=X z=O!51VVEcgmSSX#d`ki+PudW$rGfK<21sf*4YQRx3G+<10@Bd=EE$%e>*-pso zF|c)PUIK&|0}%~~VTrkbgCSV5+{NNBMbvf^?`y!fK*&#J9xA>`U8A>`U7ho<&WtIx z80r)rMh^a*g|G%+#z*_)68vitxev2o1hgWC$~G+s6Pf6^&fbMREGOHCen8qRYA$$5 z-_a-u{JpNG&!Qrt=wd!=$|6@Oy#&`c-!=6-s#1aoK_YKti5O!~<^hF%90+2*>SQ7U z5eSHfhiuRea6ErXyKh$O@D?ut<|7ZsGbt((8FX9*Mt!h6$q z6qqV%UXLA|@$d}5E=!|D)P(iABUKWRCOC-I*~Wkd3E9X_C;!kg3z_&T7!Bys-GuT&3v?%?#5J4fG3(^e~j7+^%WWW%M z0crrs?*s-3e)@2n?7?J|6bL)A1wO@JdOyZ>drQWB!`sIN3lj9iN7JTRf>nucS_<*i zPv!Km(}+bm8_{S0eZDQ@=9tlUzlJFq`;cG#!{_wQ^}ZEaQ`rs(GZcq|q=XFu6K3qR z*<`wZVs(0Um(2(7EB6el?I&rD3$S8Fw2z~|-Ck#1`TRWu%992Xd(;&DQ7PsHuAA1f zwOYXFiE(NLS{LkbXbw^wP~S*G!<-5DKX$~pLJYv6GhjF`nwe%`ayyvB4DM;VfQ-W= z%lx^V9H@is`=krVNl#g7M;`a(hWVQ?`mSyr5MZKwYZtL5%VZuL6kRwdMjK@Nv3gsH zLHH=?8E%cGXOznhdJFmP`y^Btt(f+9IJ^ajU*TCu`8F2=QtU2Gy#1){a{nCoV_*f{ zr(>$i{EXu~;Yb&$bp%!u!@q{`^p)u$Fu>$nK4W$A~4o5J%-_~7?DB+ zafL=x3oce6Py>*`S3SNRP!pIRFq8BMHFNFfk+PL`det^8-V} z`WX4h>f$a!gB;^#tY=s%ZY7uILi&%qU;(8v=Qk7B1sI^YB;<;FXJc2daiRIXoR8L6 z%tx)KV#ZLF7RV1hsdqL>w!%4%H{RiqV=#^p)qF79SnOSX>}MKD5Cd-PcE}th{%b_2 zkSlfw&V!k?%I*SLO2&W!aSj~ai_b4bEg(-%wY7S))smk{@`7--Cn$r)K?k3UV}bdX z$f})3#C@Bm(XB+}j1$16@6H6a@4)R;;};;N7(Um)(1dMu~)#loo$mgyvN=pnP?n8wNU z?8DmvHdF3gqdOxT>TQ+be?3k=3>x5yb7+RtX#zQ7Ar|*P+|t}^k8T(;vCEgsz2;#1 z#Pdu>c*#0|RigqAiRVRqE2FYJ{ydWX&Z z<<8&ydrD#_fF4JpdjFXaC%HGpzg04U!Oaz0cW`+e zyQO%wptG0|##=_R+5KU4fCbTy{$I+I0J(x5GLgE0qzh`oo`V?#Ki(X7RYjRoAVN!= ze$pB-@Z%ezbeZ=??K^^9Y-AppMe_>8P5siHjUQ`Vt7J;j#Y#KB!U%gn5r^r&X!9+; zl{ZL&O*zgMQlevI4ag$mN+0e;eTs=;a++wdWkM-D* zbI2f57i<-5+}`Wfxv0tE3L>x?3Yy{ruKm;a^auL=R1M}Za5OtPf?zR;%a=SOi&SbE-H=NwV$vGzarpK`yY#e?9BTp;y2 z#_%6F9X>um*R7s^93Q*(n}kQBVK)JTtaLUj=A|iUWlzx<>J4Cs>mV@;?rUFm8SmWY z`KsLMvOGEdEBaD*D%@ko56KSy1E7pX1wLlN?LtFO;xu28gTE5JI_;gy^P{Lf@V!L3 zM>swaD~Nq15P3*XeJQwM&&pv3!e&BnM8bhCcNa zM@&@=nwlNKP_LtyOc@I>;!raZ(tN~QuB-}ge7qK{?g?{B*>%XDB|s#}ymbU4>U|LB zOzNur^!@Cf9Vb#$x*1va9J z!4YXTyb0j}?q}`zvWrp<@!`lZ#)W{SJWrde4M9dqAQikCm6udPgL44ne>h|$$*j7Q zjwMr9HuC{og5w}j*c3u5Nr($AFbp|0b*i>Irh)DlCn>H)*coz?d`+E%IEs#CEDHS; ze4S2*!$Aa?GYV+!R>pO!yD!0YMd%E#($_bnA`-)HInc+n!(N&s-&KQfiXxEcP$-3s z6$ky$5NnAi@^l4RkML#q;vbGNt~!|5UPyb|Eg=M#0w|z98x4-{myPeH$Q>q*jwIYV zm3;(z5SYY!x7#@xZF1lE{La@rh#?`SQ8LYeJ;T|<bww5$?X6->PS6e6q#n$`Yeca_Sbb>?ijF0>QBvhCdSXXcQ9%z~W2k-dACUnGl*v*u&r(*6;GF zm2#tn@102Soi64gj0Gk{P$oY?hD+JUHngdt9QGZIYxoSiqP#*tB*&;geq5RQwwpf= zQ4|9g?hVh%?IE`HyGvRE94uM5C?iLxcH6j!$xx-EA^^FDo6r^DC z;UW}%HdNeuqw~1u+_`_n^kAzt;#8`U>j98en4KK@io)@er2Mu=nVU$>!b5p7flG%F zs-a>-0Yif=$Lu_OVqF=kR==S7B zGGdbY)CzICOxvR2q>jRIZs&92%eqd-;qhAjM*yGv3#hm)j814zxqUc1DdgQ-R zk1S2|I^n3x*m(Ph&_6Y`F1=MectCB`dO6zN8wc?A)b~4hghn*^(D{M`>g9}@ZZzDK zaWI17B-%TTepW_uN^po)LSHm^rSvkW#^}-e=Ba%reqkxf^AE(bLW_E9b@AX|cC^${ znlk|au|p}l;5AdC%2v~+X|?3eV-s87&ywsfK@H#hM1!)LK>_aHxbc>;oYzHKa6Hbk z$?{D3Ew*7uPEy(H;;NG0_wB-9a6B+IQM)1qQ>Q@PnwmaKKSA}mjpP%e_RcR)E0wg@ zsqZ<}JQOa3a|s;LwYciG4*TPooSgqQwAzlrSu!F2ez)=vsIyv-of=3S1y(3&^RRxL!IzHRQ zRHd2)7G%6!ZP*ATE!b+{y@20v~37Y{U!RFQ8XSsXCaDPP-HVq zKm!`52~|x&w07QG%{DL_=6Y2n7OZkT>hQ@;C}{t(07xYeQ{Sz`jox4DYSz+AwCbq_lUB@p;wignwaUpSxMeV5SA@;=RTA1yqH8LvNy3t^5H zn!%V^Y8nb`igP`sOV0M%D~89>NxQma^ zzS@!|G5Nk;T2iCdWOnyGQSFQULeWnRa~+>z%$9$2hX(;Ho{EX&OFuqJO(gaR;zS+B zJqw#TGfnvMr_U+-h1Oir(y4i4zal-Kfxo48y7~kA^j&Dw<2qhpIu>T3BY%y#muIWm zR}C~+M65X+%qlCv4~@ce(ZS$=hRhSPVGPrC=T?NBg4Gxdh<5s2jJ7AhO2V*Pn#eyJ z5K>>SE|n$#UUL72Qq#j$k+oEI%1N&xg?vf*tlcB|9H}g8ExAsYDFk>KvPTgc-~+Jt zB|V1z9b-Ir1DD}dvnvQIk-Pmty;hK|H&)c)S!p5fgDHFuJ7}-@l~W5y9SsTy8!Ul< z=&;`ZY=pypSSh$EdY^Kw1PLCmUJ>&eM-?gKvxxEj0wqTLQ3s>3Q+PLB@VH4;PXO}1 zgt9bVjpuZj_miI6!3z=DaXx==$Bo*p5g5m;V|^?FNzjhRSQARc?~6?Q31Yp}W-BwJAWDgowz+hj&Q>Th9kL!?N&3su! z9-LHmo&nC{)uqa^u6-dZghh$@pC@ZW(?O8cok8I#ZGb!CdM4AU=Ky=7J#pXFg9EMv85BDH}BWkDK;#k~c<{T|9`R4N4CMQ~MIq*a zqSyT~|LMad5sKuVIWk^L6-c*uO425{sBw2kV?{tzg@y-3%I90Pm4v82u2LsJ9r2;R z7vP>oBXyt7nX~>=OO9rB&u8X{hUzTC#j#L@zA_;^wX4?ll7PyZFU0}*zT7XJo7T0a zg{M4MC?k3r+dvI{a#-S$2_ZMIKpP?t<$cN>76hmtLUPQZXcSwt(+jF};@Hx7{XY4( zD$Q&fcYqcvqEc1t-|TRlP9>&|+9fTVcwrw2<#t6**b}HT|BxI=OnKv#Spbs>a{xG7 z**9qO&CWgpf66k9gdt!1H@Yo=e}A|hDSv9d@rgQQ8|UGnnVl&u9$E!JS_Bw%n-x1O zF0bpqP%6$H&8#E@^%145OzzB$1TLV#ms&V2$zNHCZOyzi>Uiq>&vcqG@Rv)WciFk+ z%R=6g1HzJkld(-MoHSF!14Ym3Z~&U)dz_fc-q*j6qWKvw+?xfgmGXolZn2sR8Cr9A zLslggwLLnUdAnehTKAYMbSRyNf1rlsu!^MvhVuh`#-p@cQ)35YiA%{&l7+reM5E?l z$sR=U{>Di)?{aw~H58nX&Sd!Te{oi%x;Rd&`jnIQ0=B%rY;(+ z{NpGV)2czj0rRAixyY-NupcLQMhG1WQ2wkw&jV!sZKdqe$dejdb3jU{^Wz6hFBN&I zzg_`zMaRW7U)GveSXyh+1erN2ToSV|t*Ri0JAhQh0PNQHbDk3q1!-4rt!38tH*fA{ zpcae9qJx+o3JL!So~g2#{X+|YH?v_E?@b*{HnMVx#$9QdZw$((M_7t7x&SVTNy#ZL zYAzho3fj<|T&nb3Sd^a)VNqnSMCciF^3c{d(DJA|KTK^UJ$;s{CdGQGv8SE~%`EWb zDFD#1NGpR8>=3ZBF|!T}oYh%MSc^)I3_eu@F{67|n>Zcm;Ocd2y}IJ?#bngcgCEB~ zsdpOBe*gJ%bkqiLf+!R`u8J6sbI~2dX4fU61TRxl$c||s#JL8yNrBl=ybPQ%MSHsH`Ej2jzEF;l9JJD<>siW*FM5-L$S4^F+P4s6SfWhpXo~th`r##(}8L150=PTWM4FpTkn< zQ<9<2AX)We9NXU2kGEU`vf#7~Y4{Rhu=mqJ0MbAhMnVvakbn`><3W&!c&soO(T^vi z4B3EqdcotJM;Q{(|E+2>o~^?fR48#F;Yk;l!`;FOfWP69^^oS$PCc33F^;3ytFY=& zFaZq0Brqjqoj_b`{3@eC%$`Dnx06g9R?EU%O~hpZ+$@<`KCO&L@Tn#XwWkVVi22qPH! zqPg%`#{TdA0D|?HdA>XeCCx@X|E#UkWrmw%g3E&Sh}-SqdPcI%E^34r77?s7SG2+` zRh4@!AVhRbcO4uC#EBRvEw1$UZhvKhzjU^#{J3Y>hPGdMI0%FuYNpP1KqA6v0RTch zZEI@?b)7&&$}!V}=%95)E!H%=Xnmg_hK66p+IGXgTnEw)eJYp5t<4PAgozDM9X^8m zBe`c(!^F_$snm1qN=YLN)mJaiIiKcqi-?8Yv_z0ner&OK6ygVAO_IJ~Gl@rVG6(ag z4#iOw>VJ-KNOntzt$66e@&t*yi0{`EOi{O|R9;}8SZqIeCn+x5KC4%cy;ruA zpqIzFkvRa)K^5ZpZF()Qx2r8muR%1P*Sr|vf7d!KD-A1;mKuGraemAW6bblV?emj^ zzxWHkZ}6#s8Y)u&nDX+P{F|F9;D*ysN*w3?y*gcvr!wsGyY5&HhxW*OvX2Ga(3hJ} zJD+bLS(p)*%!L@wqlAAj^74~^h-Srw8YJh_cm*ZpXOtNLJr;>jSAH~9IjTGRN*q@(hKmra#Z}G9{ zZ4(cm_>0$VJ`?LAp0hDQRhEolrQv^>OF78ON*cu_(ZlT7n2P@-O{@80K-O%WIE1eE zc%_+9HCImI-w}WGm@T6`k?LeUR#@ui2e2OC>(!S0b!SU*3Psde6@_==+-8C`VopPV zgbVG}<>oxV!?SF2LKgp`6tCvP;W#W*AQKdg5w?V8wnbM8>oVd|PrPi%!moS$wDJO= z$}yGv+K+v-zo|!u*g#<0RqS{U|CVWf8&00nXusc>i>B_eaH;NhgQU9jWN#czh_8n( z%Pvcq+V@8{=-sh*Andmeu}~!vQG#JsRuHXQ4~~>-=q-%%Yyd>+`*)SBi@(T*&H=xgMFI6psO!OvDJU_G zey<%|(Li)l;9{-ci$Mq-zPlnMV^j5SM9E`E-#cjV{fh%rF10Z%-4oRhEzw^QN?aWN zb2*@sNRQZg6ze~LBqV{HLp`7j3Iasu4#Q{hS-R0kJh|A%py^s4ogUX94vJDSgMk~c zLHD57cIggb%H53srrJF%DXUMo#aiP&YWX^-qn{PGc zK*{Zy2Sn2jCo7cmH#SESjN&ZG)h<=oy5l}X1m?7p;YsH0M}JcgSHiltauPtNQj@iD zx^(J0*`T%j8kVkHBTiGJByOAoj_`|*7`Hc6evb3Nf9~#QvIz2$BRc9N0kAVS9?q~s zJDo8+J*E)*WVWy+QH(+xq!JCCh=$!d=(1EpMZ?mmJIYuKzGk;|Swv|g|A_FEAHVV) z-c=BN(g(QeIQzmUHW`NQ|BJo<`fBq30x01pJ@n9v2%%Ro^p5nd^o|&$7cms+VCY>! z?;3j7(2Ifr={7)6KvY1w=odkns7!wEI~Q|1ceB<^{)epfe9qZtZ$1}Z91q8T+|O79 zu%mKK_zpMoj+;`8EQtaB8Vp(9hkujXR}(S<|?&av1Sqd^yB0!hnm;0Em>l+ zAWr1zT+#%bnuRn-Yf06lTntcyn_3wbxY!P{`@AaYe$uz{S|js^puYSp$;y)QYP&f! zL8QUkiKlNSK$0>KFW>gP^?0zvWc+rQy35qGq;ML%`<2g10Qo^5Axqh#ulv4q*)1g~h+1hf;tG+^qHa5RAy)m>|YDEoW?7yIN z&f_npdy$V6#q`y0VMb)VkDgn&_}{+fx{>wQM&sn6+0CESh3&MRbD9L$5m@aY`%jeZhVZtnYZ&)0v1ymcM9_x zcY;}?7u>Kt^H1u|yZFX}KSyzGTw5@KCpw3GK0fa0IS4fs#)JiubU=j$W^#U622l$` zhwVP@HlTRQ8jx>%^zyM*wOy^q`bzzvGJNl+aFKfp(@Fe?fj<^J;5hb+N3D0{yO5Sx z5cs=NL%CIGwYN53M6bfVa_Jo@b7 z(DrdhBD~ei9I7*%qFA3HdFMe!>(Qe)m>W1aUOfUO2)A{5AI3^6%DU9!)JcYT@oSqi z-)G$xJ`0I`kpSId3R(~Xq4y2=P9eIC@uFLdcD5mT%nYesNN#gpF_fKiyyu{WnXf{k zTQKN!UO#nTL{QVI9mhc3ouJlW3p1plylR8kL-mRQEfhGm7t&AS`oZYpy+tL9OXU~D z_m8_jsP*yFPpaNvv_si`PYN$g4G%H&Q8VY|M*%WKzzK5!-_>_fQAj?n@l-KL?B9n_ zh6MZ`hUM{wGhs+J{uDMQhRYicjhp7NHR(HUu`wt>)Eo>VfZ2gmu~pwjz!wg|f9^`H zowstCl`NM{BJ{F6>&eumJn3Gf@soHfIDoa&BpLGu)I=bL1lxc^b_!wNHC;AF-K4_O zISSJUIp}$k!7rd7`3W(v!{lRB3XOM$ovSJ+P@0(pzTT61T^RH~&P5Y`2|x&$1Jy%l zW`Z&m#(*|Bds#r*a}J|5ox;79*k+v=if~~k+eg$(MA=!}>Nxyo$VnO4s&<353%qMN zm=C=3Hj{$=lG%BTv<=XHXqlKmtCTe0B8A$3aI%kE?lHi_)0)ktB=*fEh;T|SCXfi2 zzeo@1q|rIcsjM`0^`fR@Ds;dqa#QOI334b3b#VET?D~`m+)GS37^h!@ z@c%`Mb{J-W7V~fTICb&qcHkj-ZG;fJf-By6h-tW!G9pb#n!p*ai?+OM5VB=1Yxj{aEtGhAU>vhkWL=!SD~-CJE5-vxnU)lrMO*_F z_?F8S)(p|-Ipi^#!=3s-JR}K`u&hQMJIn$jF|Ps<6nAaZH+wwb`)pXh<->uXhZ`ji z2ZnPc`f~5=r0jD((!wO6+%76C-lqqNPKlikHrJ8e(# z#h~BVZ!@^lM7|prQ(1om z;!FWK5(sTE8PnpogR@>IR?lEdW*Q+h)iumVB@I|}Gjx(}W!?K!YB4C-v!NzP<$jBF z!eXwNmbNYE=OY_q2AL^VCa;QDY1NDvIBta)jHxr?y1PoK^EHO9z)UQWjk@HzK7uxz zN`2{)&w!?MC;UR|uNV`~Fat7)&svwG0>|^r2vPs8rSAvbLF<&IQ)hEM>ZUd+5KrnO z>ia4;4=xGASI|o43E{s%Lt?cljR_-X^+VGLPNM=i5svLB%?W}(5wEDTsy-4*>RD>- zYpOGG1)P32ua{~lYkD{)*W!=74OOB6?9Sh(%y>e}&)6C;rY}F@UL!ZFVTc1 zL**K(v1j+;&$HHobn1Bfc3P(@K6Bt2lVXWT`HQp14?ig2n=%Q-5T-uRJ#(-S5yJPh z0GoHwXkA<<`YlDgxqbhvHD)q!f~mu{jNPF9%D4*CcWPa>GFHTnxMx$8GPczqs?|=j zy^InK`B-RvsVjfUq={f==hU;R33G@7UnsSiHg@d$Uf~rKax)3zn?|HWcB}5HW1dQz z`Zb%K8%um^=miQh{CW-+EMOx)&(rc!wuZ_+F<)xUrWuB&uDErtjxu ze{=+OUVUewM7g+j^a?073cl9ZU#8M{$B)!j#x(EnbfYwK zGC@!e3;LlWeDmc~x~-?qLy%J2zQ%X%9z?{2Be;1ix=R14wNm4&Zz)%z8mmA9v{4sN zA6Y^RD)XaMYNs4)dpXR9SNt@%;wgi-L@$u9Cfxmh9z2PwyMl(Gd!tf|vO0g@Q5D-W_o+I6;~^GtI$O2oI!#h+ zZ}7@T8_p9kYdkfTBRGkQU}M)7<6C<%T}9cbsz)70Ts4dx<#T#bl{(>|cW- z?Jk?p%)Z0f7ybAN-{R*!uO@_Odxrp!8+OQ;Ybb0Q{qR}pCFQ&MIi@xXlk2;TXd?WM zCc2f2E)5o6_eZSZS$frbuI9`RK3Y~kNg}(9E+v0bL+TfaLTssk9Jte(5)!raN_J^% zhDu)wHEDPeAvcn%rNSt~vNvuzumoByb?w;I>5{=2t@P!o`Ih3bNjeIv9K7q3trEDb zT*|}uSbd{**BRs8KAz{*`i}ao0%y%p*Q>-m_%GASw|j5V&dA69O$LA1MM)Um%kjba z5WlIEv(D*?I?!i_H~W$-$fwdiJI&1&{X#gXdRnz&4@@36*-yThF_?X299W%3JIu&5 z{XTm3Zm&QP6c(r%Y-le%oGwP1FR0q1zK*j80xpoX7M1=n=lbnltYcw#s zdOod{$*1EyD}3k5sQ{a=YGufL{EYd0Q(){cn~CABPvTfki>p~PCzt&Gf;@^#opr`o z`aR+@E|65fgPL>k1qTx$4#4g5&2N@}aQ6Hh1(ms6a>Oq7{O3YwV6IsG1$*|%o&D2!xd`CJo#o%x zm-CYlqA4l)SIBvYI;Ta%-uGGqRA>Ch22K&dG>Cf6qzVG^nZJek>-Eof)HH(@ z)0>dd0Wk9lrC0e@V{(By{mc2l+QqBLmYW!-5i<_p@{UZp z*sDqYOQHrQays&7!K)lD#U{E>^z3ud0n3!UI5i%;oTtt4X~E*n+W7$3jts#_y>Eqo zF*Xj@&uH-Zc1Oxf!wJ{>wxaxH^wlh#uN8Ira&92beV4hG^&C zSYUi`&A12#0uH5b?e8$ROqA6$qd>J$7oC(8Jj)8Sehm=7!*Ce*($~T6B@+>+oudsh zBWCrP(6_Y3gwwp&-c@DG)u7ES*DGH@iuHSHU-lYT$PTf`5*iyxrOax)dm8tb(pBqy zicFObYpF&6(J#S0S-@s$M{@d`@`J?gPS&K6qnD8fXnxKwn8bdENAhD_ z61Y9>RS@{?AwBA=T=op^%eR+B;Cl>*EatZw?#vy*B%W#ha`Hi_Y4V)SoX~S2s1`9W zr^W|MKlO5m256PsyQ@NXuQ}KWi+5q3&VJ;ZPLU`H(_^*v%3h9={(bN2Ar*dO-~UkY z3rK#2*1-I3$d})*eta>j)i-3km}tVrR&6j=x|VQ~&-t1mUf}v0G)TVqcwJpS-D_#r zs3;n`YyyED!NlYs3ON5yLstp_sQdrFZb(C8Q*%pe9g0K>C6-hGN@`+GcFYdK&z~a@ z1_cEM2J)AuUcQnra1y1NeK#j+n+YG!XB_`D@oHsCUS5I`fe{mRp4*%Kkh7nyCCntu z$My5`b*V=hyW- zd`%NE0)gfUyY)H0>XmMy#kjpMO%q7Sd|1o?d^i7U$i}(b+Z{|;0h3K=)ci{@{z>0h zU-VzbNDqN+TdOjv$jl3jhE&Wf921Q3x9-NDN^t<9tJD_M9=sb$D*_o{ncxs|V|D!q zCyhh2Au!Zag&yQoeHXg)BnkkCl;A8?DeACi~s*lu|zl$y-TJy#_ho0re zk_gsJ0OgNOG$kiJjMl!E+FodOEva{7KV#t(| zIT*QhtxCK6_n)7f8({|_Cj#tK_N{jNG}${^h{ymYLTf0=cPgRL$DOx_-meaqb3)hrGol zsgp41zcWCgm*id8CDjxC@TmZqfI@ zk6NJqH1uN2_wck5m+r5yEsJ&~ojTw9$C_3Ujz8bLqImUM6rZk?&X+l_G^XP}&EPtb zo|PBxKI`P4aAwm`Z^IL`6Eu8Bu3~0q=UKTH3eFs+8O=mLMHLoaGqZnkA1#;^Ysk;* zY_AE{P>K(p)*tc-$qr-Q*QELOi+of`9Smo=bReaq@{sW>z)!w~@U!SdC8LCI=Q2pT z0|XW(Z%Y=n94llnZ7>Tyj!t(d@JFo#$18KLyI)-osc+Y@E5Llx zo>WAJGu}X~<5itB-liQp;`yM1x}^i*>pjT%(0X>u6DULXlDw96dhvrXeSko zLbo+!7CHp%Cy6cT*_WB7j27COghi)eej&Bw+Z;y?dwUo8mAXCE+$%Cgd?jSIDUXy~ z@PC)DL=MBOsUP3wCR+SZek7nL`0l}UNDdPL)QX#WH2>4OvTX$o+zl*7PNE&G)qE9W zEkr5w2rnce=UQE{NkB0Gm)Qp%{MwdOPsh?Zdx)7m2+0;pS_iWHD}PUMWp{|zGWdB& zH0!Ru?>S~ji-l;y!?7SNUnBpw^wx-f)E!?t8w_r$CqIq`%BYC`I_v&U@^iLbK#i=c z==!8TEzCZ4WRmHbKbB7UX*D|k0Y^-4jdzK@ee)_wEFD{b4)e}DYq zDDVGNf<|m_NNT+Q*6{a6K8OD6x>Q+Xy;vzzLs8*;P_iuJyWV<+Tg#I7CKqI3emz5F zMAk$B$=4Vkb_Df42x%XJjcRSSNTePsd1leRfVaQYaRy6|tGxBemVc^W9enD!{Sx9; zT}Rz3{ovZnO`enR$cJPQuPqkOf33p8t6``ExgqoWd z75a8enN9L*$aBZT{+h#Y^T@L+i_&mR8C$~+Q)64dt9=*j+D9@7ZsQ$GP2?)hejoRZ9S4XI07nXpO(YxAoti5fi33R}+=eGA8+o;M%LR(O!fe{%$|#p(%@L(eW3 zB#8Jg#mm{IQ^}ZUQLDMWwojKciDmb?z0zxj}Kk*+CJ@XpMie3a*=`+ z#Nvu|@WW<~Oz2^+1`(j(4y>$n8N5uy<=SyI}LE zc{nuc?_-qD%<<=wfAQfX9ylO^w|9&E!#IO@kn7i?dm9^=IB->&9)kSY5Vt6{^2xtMmmC`(!QR(H8IMswXoccAtn0BXR%G4t(=Y;G$9jfw8%oq#?Qj94i`$ zvwET5-#9(yS0;h`>v5&-7x)+hSEUsY+sXa2I{wrX_IOQE8Br_mHtsQeoL!*7_E&p~ zJfQE0w_@#vvbPDqhZpZPlH9(k2nR*upm0K>`iPWn5i$YGWn&ok>%|?uO0kD=_LtkK zoL|6fx(uiR$OO!$Zp32zX8^PLJ#h|Rioy;t!3(pB)C*NiJAiQfWboWddQ*MBlU-`) z_9Y&oOk|b9SQpJoJM$YXZAFm3ZExTv83CKew#KJi$OK>iO7p@XPF?`XWSF{L6{KTh zuPS|MIiF8v|2hbhvBi=>t;x3wwa7)@=CerK=;GnR-dx5Cm84jOZKvIAze?dw3HAaz;SWUr_Jojyu{OC_Z!K!Pus<8Lp=r;EV}Q3T=Hx`i8zj@W;*8@5p^}_ z4O11ud1~yk3SWpeFSwYDnHg-{N|uQ`n&s#1VkS_&ZM&}RAth{!g0(%fsW90r7SZ$( zY*)0sl5Ay)EA5uZS6=)SYhokZ+mdJ0%Di`~NX02ZBL+SK2*AmGxjeyljM>aPp$=Ux z?3^A+mZC9i;2)MwD)0DxKwt??hygjA$}X2TB-a@n-4YMWUb_LgZq+b0wX!c7)2oDaX6PlLRu9i%)NwTFcB*CI_H1J7VBhI3r$^6uuU^!y+ z!6Ad#93s1jA&sE5$5!m+dXqO4dW+ITC86$-U`#{BPDY|%s=QFO7FMIC20MkN(4x{w zj=&@#oV&4P2_+FgCsqR(d$G;tMm9AvOjzIkgcTGbqdd?R-`uzkZ1_ZvE1XDt{A37f zzl`jY@=d8cBMz^;A#YEW`Kn$*nBYw_?Qy;j>BuR6cZPfjLz{pQG$2F?8;2Q++p?NU zjYOnMXWCK1mrOp)8Y(#ix$o;|eXBN`3xr~T7-goY2jR*Qfk#3L@!|(zh{xNrlfduwPcB-<@#agVlx>I9b_Q3t_3rEhWa$$coH>DbGR(94k}a*_3qR4QZbGEpR07c-YA3Wy=z5M953h|LvrQBKTI(&%=b z3}0g!?`D`ZNC+?C?+6dpg6}0WC|4s1)871=E##fX@$_1hxy_soroATgt+xEvM0v-r zk{QSRM|q{)yUx#y;jN2ww=kfAev~gcpuUlj=ynwkej?N;bl6`~L`BV}32FFg#>01o z&5kru2wQA~n+4M5M!>|EQ1|d+p*l#VJb(~lQcP~V<5A1m%;e`mP~ie$j`cja7*I2w zf~pK&MARJ&T+oVgH2}YdVgFyOoLqfyTX8S4nKh%Md%sYX2ID=_h7VDd9g)6z8(m?p?F;R41_8FHF~EhM^v37BmyMbmqrB5Yef z9MBagzm-v2tcwvQDqZqc(|IZ|Dh#^f%jSO$4fpE_i2~O+^;bpp*PHb7P6KrxfydwC zc#09xeh5y=?qo&YkY5~M*aeqRcYaBw$I_RzYDy%jYF=`?c+WWH3En(mz4Hwo8U?PF z7-(=Bcpo*uYu>*U1s0qhnEeP)NbDDFaHnu&GQMl#m|^hz=@3=l@Jps2X)4vb^2HuD zZ*u#-JNBWct1G(H0>6Q)Oa>NI$xv?cO!L6v(}Bk(Jpn85Bn;9f&A-p<;hw~k|5TOO zUaCuZJRdtSq_B+Io0&3@e!!XB`1E36{#$ntO^@sJuq(a?CjrwlhkCE{EBL>FER&P> z*(cy&2Ry9Iu|7L$$b@rb?nPUTHTFtP!!Ik9AcKwozu|Wh6bK^a&gWQo|Sz>S(>)VHEcO%+aIuPluiV z$YhdY4U)@N&+2dPKAKt;jXt`SK!RJMVP56K%FIyP)v>wtLXJ!0dVh#YcEYOCB1T@e z6c}Ggax@@nRFCVP1FYmS+XDl6hwdI(NX}^3KBUreFdhZXGaZ#83s71=WOmi8G9lcn zN&BhZuU@pg9U~pb&|1?Avf>|5K-nlyrEhC!&NJ@{6I&|u^fLlRmVx`Ku{Lztc{r2? zHU#2K(s`w%uRWgmYO>|k&p60BGt=*Mjd%Cn%q|1G=Fo3o?2Mu|e8IyN& zH!67fDui0PB)VT*4E1SI+9WgYC14UqS*n*`{%)ZAiefDr;q4LU=QYyDKPL-^d0KKD8NaI*2)xiJMLs{YK@C&KO1d!dMU&jh63kTU)rBo+{0dBZTO z$1HDF=u|&{Rl7m|r9%XLa>=UHO@J^q_ImO9zg07ywbGb-@_}}%!*tA=Qr^`YAk%(I zD~9ZLpW%#cxJLf%ROV9WrvK*^-`Pqh#&xkRkzi5GkJkhAEBX;PK14m>W%s*YEobnM zk^2UDDdopn`WyPkg5c?0(a%69Z##YTv_YBnPQkyGb+nYiENk;#Uu_ z_wvn)-R}!qZtu;nGfIiN2THp1JjqZ9Jur^O-*5sT#qFV|~4Z!|M_WyH+uEoNb zvTqHNZV7Z}4Gm{r(+!#<(QC~kblSxp5B*5Hc_3`Y`UG@Is~z^@w&A?yf8Bat+1~I{ z`ZJZEyCzz=!;3YyQd)pznsVv-Q}}@eXYB=@ zNHt%&%{?U`0HxW)1`&;DXC2u9ZRLa08E$}3&aQ6H9a#ucq5s*YtcsW~7kRD^eLHrk zs?UW3+?eH*9{~RfDB~)GdK%$G`W>@!-Q^3PrH)-djpsQWQgp5t5dYk3_4e8@V)Bg~ zw`LDFKFoLIj3iTZFLm{?OV3E_I_Lh$H1FTpY)Eh);i@20Pxd*vW9Jw4hZlpf0Pc*N z;8^DW2eEL-lfUW|3#P~X@v+`t){A{Jt-5qox<6a0>)7E7gE0$$6pR3zDN=-F%4jwd zbw8Vslly-nw*MR07GpjddDT0}(X1W-FiHHmDD zeT;6RqZa^#z8YIoG6dy%$T58{k(VK)LrK&J%kZ9Ge?#VfHe_Z2UsjXWgz=_Nl$F4C zlJg`CkxliR>jr8_kNCRm1^1p(ujz{^IeQBUZ6Ewmcg5Gk}- zk~B;`%nLVle=p=J{9v!@M$CkO`X_!>)5>pOo>SpI`2FZShznYJ-JOcS=mkS*qcgX# z*Ke$2!8#Ab$Pjwgidj5lKkzHveRQ(-o4|KBVIN(OSW`dPImvat1vyQx6WyJO=oe5H zeNueDKRyF3$bwj5QK~K*l`(c6SaHOE$2F|wQB36do{Ysra)9ibU_98NWqcYc2H;n{ zoYz;Oaq%~;*Gu_%e0bUC2Xrh_%wjh!c@Y=e6E18qavUy&LvxAR)NbpXc@LN;aC{YY zxD`zvwAe9US-$oMWVL{Uh+{>$IR7w*RJ+$OhZqq%{)nMaz5(VSx6W22CaH3nU0}VE zuDa9Iap!SE-y~f*XgGnRek7d=h-Vtf-(!r9Tw!R+tt3-qc%6}#0vWl11jLoq$O$A% zCdnsG=fL;zt)k&DV^@&~lf4j*I{eqJ{_VUZn9P1${Ix-j*^KAUiD+$rIx{D!QtL{Y zUMA{U4--Nl_1oi=$O^xoE?L%Jp?MJ;1p#wFzOMQ1f!myG*_bc`Qnk% z2m+oV{TrUz*FU3ObnMgP^r}Z|ZB_^>mCX zc?m+SYdg31z(yawM>z8(Aa5TV-b-ecy%J{i3kO5{zZm@6R;+|w9b#intXN!;pbb!3 zz1`9C8N_UlmZJ~&M%ObNZ1*_lvLKhG9VysYL;j0%Dj^=M;^hinNUN7pSa2`}ba=&5 zaeV8BQS>IugKQCnuQ9xeB;7hcA*~oh9Pg#*T(3)x$o%)`*MBiF=ciHHNT@Ki=>5L{Es=mL zdJYZ(gE`5`!hH^~uP7BL|DNIcN}2A_9D*oa=Ior`UzzKf47F5p-7ZsF)0LuwJSwvprk!t) zGMGv3v8vo6S`R@aCj(>XY|Zx4K-7ukWb3oZ7~y$rrE;y zPOOpP3e@UY2H$wmB7}iawK$JeCyggoo)#LtzGhgH)r9wyyJPUu*HRXuHnErwg{DhxIt>l&(%i#O+-PHT$a*vRlhxN-3kW;M{geVK>izV7OJeJoOVRGG+(u;w=w z9eVnZtaS?a`6O>5DJcCR!+_w~4Zb(b6+Vn?1KU?+RrC(7@IN|Nn?Z16vV$D+bLfS3 z*kATs14s!3;gYw#+NE_lQ=K&%kaZ+|sY#w3nxQJNQCa%8RhG*Xi?OlZrL1&o!a<0X zp})A6Y_~f7I$!-8YnaK)@Og_6i{?2fOqWgCn$(nEYjowC`t5XE15aB1EpLe%*O{_$ zSr(7$%snq|e&3Z)nVkX!yq==UC(q{pu_|=9?CJoDZxAjDCJ35}Rj3;*~r1%AYna%J5`{!;c>Y@%;O<;&n&KlZ`g zlY#x1Cw_`z3qNdwqgQpl<1$oTUh{`B8h63*eSq|~!b<!kQq6VN$5+w)+XT;H?O zMdsez4mKkzQR+S5o8v;kUiyFH`IsEI5?{aQgC8M7)C`Dgy+qdQP<7vX*n?yn)*GaP zfSn6#t|Ln_NWNP-zU}tf_9mZmp9dN}8D<|wAP!0Ce+$btl#uN^8RK0bj5K_3qet|0 z?f)g~@+7T0D$#XjP2fv;106&R&PJ#71a8Js;%dVQZLt-tMeL@zbc@E$JsBPN5?U#= zRWHFfJox52JzHhF#p#2AgERsCEyIrsZ&!_*h(3L;JS>s@g#m3t>hE-FSB+mhae2B;;4Wo=4K7L$W`$()r>m zPlfb)lTUmGOM=h-k)N2H&jDYgAjV8}w{2qFG|E)%e;yrmM@e`?sET?Aga6ZQiTQrv z{_*30tL;hu_mAK455W`IZk$@ko-?&((SXBh*Ra-~&q=b*uY^612Mu1^1pQU5Umx8M z+%)2MQgvDqqd%*5xhyRu=e71xsw*xZIvnF``;wjFuTku`kpHL#5xvzj1ru-{>341+ zbv1pCE)AwQewzgOjNArV^MA8d%xzWESSb26>)(H~9ulKco}-^yHptz$^@(q$>+{^Z z*f9&ETRtYWjl%8E`-q>Jr0zfRxi?uc|J}k zCsk(0pU;-ZmeuKZp$lHfbLERW{EZL>?qSp)$7`*)>s9827^c7BSC4+L&cvQTfPV>Z z?KgMK{({yX{UmBKSlZkliRZoWir^Hm*%VRx5QY~k(%eVu>exllrv@oN8S2(!{?mzL zRSNvxi66D3_?Y6(^{w~k#Oy!d1$*y&Uk6;r%`Yy8825 z5h~lE|3*P8@B{&l#BawzQHg>+Oy1(DiO)B0sgaE+?5YSN>Cp$rk3#;MsYwAv7gnh= z_tRDq&9;-OyB$UOlHZ3VdiDk&^uVb_;kBe>kA>vt$;tfIig(xS{k>DZ9owA$3Y#6$ zOUqA)RSG;4#A&WMurWF(ho_#0QeO&oCE2oQczebm({hx+dEwwE8}?a-R@n_{Imm$W zhSVo$zs+~oYf@v7zwYvOTk;F~t-nj(4l^5urPgc#jfNQ|-WhM}HU2B4ew^qWO7y&k z%oH_X=xwmG!Qj-0nKBcwYqo~$g@{?vgmVwqx5XZd4GAL?xG$m!%|f^(g$II$0VP7{ zt<(o^6m9f29GI^+sREp9f5@%VvGILp{Ls@r3S#L>Me_z?N z#WM2$HMc?yXaS0#%>OU9^8fnWiuC`z+zKrm{J&@q3IfXB;1QGsnX0yJTJp8Fcx&^kc6tPV$z+ z-1@zIO0KunJ%?@LTe}3Y7dfTY-sRU(ArtN*qv~Rusp&Y3N6tUxh}1$Sl`7{4m-y-h z1-bE@oBW=7VYNl6HAbd(A)z+(<+L|T90UcXZ|B??yi>4AOq@zH43bkfxa~#(^QaIp zO$X&>J`XTpScLm7xvorQRTn}hS~-HKDf}JRP!-?g3wfx*mkNnMGBuVOXcW@kaweQ* zrx$3dOj$ZxM~c-|JTTs+5)|~Cpb~MPZQ*MQ_-#;ESeLf#;`cy?Pk1mi_cLFF5+L4q zACr;VSSx-YDOw{wB;LYe{SsshVJvAC4qKf>B3LA;Ck=SdxcnN@2~Nn4&4;&lhqhw( z19*N0Y0kv|>z287@esB15eb9nA3SQ_;&~RpSMzwPiMd<_b7h33b1&#+YQvwDdg4D< z$>B7~Oj$m9RnSl5p`&%6_!StZ`5;%v0Cg{`uXl6Ps$O~S_VF| zTb&;Q&cAntv2GX=T>5<=Ej>Jc5P2qQs2>v|kIG&Dpjq+`dY-$?8wsqhjw}dvx`=-h zdSM(9*{*Z--^J;=Kz{^jUgSaKuBSj0_~#Q7waBxnlw=0&xLLEvqk>?IzejscH@|W1 zcPxCraUW?)JRpByGGz3NX_9q1&L=9Iy*7(;iZIezsmp%7VHSt#WqA&83>`NH`2M{8 z5hgt`%ohJc@?SN+mrX=1@%kNTffFCi(1*)$;pQn{RjHn%Maj%fbSbsLl}ts*0m0w& z@&B28qBH3jNng0j0|Ql^iVj~zOp{XSRrv?d_e|2x5Qx4ryznBX?OwpE0=Ac71fJVJqko$)AbvEca}8dNjrmh8 z942bWGog6_cP4`l8p6hP2H#S#tdK!r6Kb#LC2}hdZ}Tul7*M-obIM+Aupx#a4E990 zL@JrX95bv@xS7 z7R+QG2XO3zS>1;qqq@}>+(hX7B8H(a$Wvm=kYW##Eu32Bp~@#1i+8(QHL=udXDv>$ zWUc}dsY5iyns}aHc#xq|Ja`X1bp@UQ4tK9+*4G?^9+=zh;&`Nbz@WRfOi|F<+c*Gc zkSq18j`#uu)tyd}tO*8a8$?0LjuyfrWP}|`ORdaXh0uT3pO>g9oEN4SZrG8=ckxH_ z7`lLuZJiC~6C_>>6u+_m6AiN?XhIYB6Px5+9t)(NT+4-oN}*$VMYRAT}gfNjMal|!GKOkn9kw}i$*29k~$sL`3?%~K;g%i-n?)N27Z+@ecB6^ zN<13bjMj@*eU~PY^GPod)rWyoaj(EilYVAgjhqws#n<_c8)R*Uwpj+fAIyH%yd&EnRJ{aOq*6-vQ4~(0|-4 z&9kgelm9)#57*=s+y}p<##31o%0^yQf$)+P^S?R=1P7Kl=0AqyV&(VbzZiU37Ps?{ z*#3`39h|3i@3p1WOY2_Cv2QM3Q+MZwFVnlD<3MO~$CWpobx9W=A;L&Bm9p80gCEI%#an+J2%DR!Qsfvz>+E zaiLcB1U-U>fJdQl{vxuPi!a%JWLg2B8S!iibJOv?lkR%#@7|@~8{ewFls$A(VJ%2K zXJJV&IEcI^`K5;k#1QaTKD6hO^+~eLe3MYTByIW1RV8pO^Wcgn4Ify8aBP{!{&UG^ z`fZ)mD+#YD(6`Nn=@j}etD%=I#|omu|2ud%KX+NmJZpFNr&Pp((Z4uxYb|;~Z!MZ+ zAc3m0V5>}+OyjAUV5a(KjJrYP*7zL_%t>!{g2wwK#eiQIktIJYS1p(KB^`{SUeJV2 zmh}JTxPLFi;orf3u|AU{$;lDT6)>U~X!+|@qKe49?ar5EB zEbBdb=P)<~g^ccf@?4WogE9QqKg@q8$Kif9vW{11%Fe;zXB$OoXUATHhcjL0+ZjA# zA)!#p(lo5_&L`(S@okc7b%F%&7f4AK!Us zg{bYw29=y>h_d+i%f^}gik1wwH&&9*Mno(ldepV`1ekMA35DXK2Tjbyh zWMHW`2Z;tKC5^j^)~liqzH6tu2_Ptq7xaqkWhKiM$UQs5>=Sbo3K4fz(D47Cf?*>- z^oaMXwZY0L;9UbA0up1jH(KsU)Kk9ZwJP@^PcpUk-k4j?uLMXm4iMi5b2nzu+4^t7 z>?#d%Ep^hDg9GAh-C5&8G`s_^hg}!M-Kk+V{JU-9u#$DHF&ZNpsZD}~eYiX2ZNyug zn(r1qww`!1MKU=xjzRfCwOR-)kA+YkzGa5a+ISyowg;6;4~}}&=}^(OJ|Wi^3i0nP zJ4FK41&#kLAee~-(pW%mC7>CS5O_oZwrt0()pheDq7sZIly2PkrJ0#0>63TYPFA`- z*iOkjm=WurZ-m?3fXL!YhDV{a7(f~erle_Xu(?y#TF#j0bww+w)tKc%n`Q+tC&`H# z2Mb$-LH5Bqc>BUIa3`m;DG_YkrFOlmEIv(p+%QY8SCyqVQv@3-qMIbEcs01hk&_Iu zLxI5i=8RZilG-K-7qd5WZ)UGl?Rndh5|lsE)47N}6Fy@gD+ zRe@6ch|1`KrLR)L9qKj&h|YAHra9E9HbQvBG`X>m#;|k;xa8oWz`X*}z(b4mtKECm zm71{X7=Rh2lCPWTYHfayYBjN_>3pK*2y9c9$zNCq527njKQV#P}76jD<#x#9#Z2Mf=wi*dj z1DI*&^dc1>D6HEs*Ry1tHZ77L@3TZ;J=M;!x*UU#IYxeMtkWF^PMr`eBwkfrMNh@u z`nnZO5--Y6L*aJ1DxJfeL3u}tWHH1D56GgtelLLw+4Ci*Az&N~+~4Pt3<=eA&>-HR zdYQvY1cTZ8FZuL*RHZ{P%?Zw52&--v9mqL?&|#`JD<**FW?eC5mwD5V`L z(_&6>t678Pe$0{Hzb%RBs6D+eqwrX#zb|gxh`8!_(GdG-3yLJ44F~)vBT!D57Fe|ytIf#tduV*0kXs)uEsVb8X9`u55_~8R(#mVh*eG@k!LUj zaA#EL`DCrLREz1U?j1*y7a{rFE^M}qO;Nw~z|$qq)L)foaXZJH73n>*uS%q_jL%s1 zM#_|c7Ew?{S({BuCsbsRt9eixjpuIx_|XpQomMfpF{Tywy=EX@t!N&aCPKiwyuTY5 z&0X0ym8=IAW(#+-s)RjrxI!*Dn{tSy&P#ZfT_g(8s2xaumh+(zTqGYR2_LkMZezt& zs6TC8I2)xX=y*`Z7u`-`dz2(Zdj8l2aHIQ?zJb%Aufm#b;?(qWCupGHw9QIFcC8GQ zGYTN<0e$}6iqsw3qfiQ5^1NKtT@Y;K51Da(wPfFhAUrGH44yq}g%H8Z={-9%!^`Ec z7!qX}L;38V2obWNQviZCAZ%E-D+P!f2%FzZfd#>|yU+9-yPw9|+^N$BkG}+p<{=t? z?rF9(UloS>nonKOy726quOGF-Zt$y z5pgsq;ON%TsSfGxMi`ySKvBdRDvE%<06Y2Z{rUd>fnDd?*|nYB&-;EnCJEEm{gxHp zjrg8W*)N~OGlu#a79AA;ALih3tk*SqC$4M;k$nq^uRPc9ej9#pAylZLuqkv&VQMnJ z6moxMwybN|Wf4Yj6(4lu7feq4?%C|gkz(PC{8}QF6kHQBWJX0q-VfzynmQ;K*9S(^ zVjg+*XKaV9juwRS;-J_g_h0PX`}l)*qwD?)wMnri$V02EO?5!b{VBGvVml1x$K2G38*GzUHBh_J_oRl93;+VyARy2eGmZ{mAOM+B0JTg zJT}bZ^EnU-fK0t}OK+K7CJ+&d_tzP3+nt+(>h#GyEW7~VslCIO+m4)mrOkY8QMNAj z;EmL$S~n)6ED4GMmbMz(BL>?Ve{_a;z4G|EF|6)Ttp2i0-iO_N@x)b72Jd;Hb2nE~ zc2JLQn>n$*f!FH_e~WEMng?Y_CKK^6)i%4b8M~n2jf&?V2y3tR4Bj1LE{fnSEARCH zkpS13E-Q|P%Nk3jtY_NHXNQfiYEH2qn&9jv@y)DJN)Ng8Zx^@Fllt-zzHgh&jK>$k z#)}TawobpAY0lnpz6fb+`|{#LMLE-g0Alb5|C7}0ojg>Rdisb9bn5XygxGy9u@(OL zt-Pbqo;a`jJ)OMP6$Z6KWmABY?Hq^sydvSnAphFi;4Ob+Z&{pg>HD4LXU|U9R$xhB zK}v7CG4#tlNJR`xmj-twgR$h5H$io57Oz=m`<>EZkD+EwkB=3C2c%m*(^xb}jAKHj*TSmC_8GUKaBn0+7A z?)H4(WM=QPfVcSDltTxdn)VfEU+x>IEHBgLGPXXI#PK-x1k%smp#bCu;I46> zIyD?DUlnklz4-DPT$0}63kNR^@5}yo@a~x?w8F4`72RO}_-n|weO?;;!;5Y4pRXPn z_<5^?8z24twfLC$9-e)`a^cTRJMIWj;exobnq>gNY}WqKxitJ8`8SjeqLm^38c2dF z)3-!p0tGYMm&ym+xcl%%R|AEiJR~S)_imxoFwk-lGW>J~+S-WNeVZpu(!k^l?;saX z#D3*H%2xIfX$V$1$1!Mv-EXHR$n75Z!w9E5fyrlcKVBHN=O69DWdiD4C|E*bQgVtB z46Dh5JgtPWFh#M8MR^blY+6criZ-u|z9)MLT8)cl7mF0RfSR`U>g&Mup5DIxfx#hm z4Vcl|F+R}&0PNCG1ON0vB@kl)v1(|1Yz8$I5GYwY2)m>KH4G-AXoA?;&(L) zn>}zb>?!E7AOR(Da_;Ru=52Zz=Lwn|oH&|+K~a;s3T5d4LcsWb6xgmjA*3zyqnMV! zu~6ccZX%rcb{)7T(6usn*r#j+gy1ZFy>s{s(AlQzH0g6w0Lqj3d+yeTTJPK5dFf`CovUhN%yY#n|gOz0kKTtK{{_e`Wz zj8K_+1ns@gp+oM4bTu4_e%r3S%Aecd8`j}$tl4v?MStEOP<+6lFX1;JTX=n6H5^;) z>VM(ln?<+Yb!{SC1=S`EO5D|jUW8%j2{6~b6U&#he$XLKI8DMhHgME3E!g7G0WQO4 z2Kx;}di8vMQ#DlleS?6@B0NP~j)g1;s01p&oXSm>7DLQVF0`Q55 z&P^yPGrm2@eq7EZp4!Rw<`BxCdbZk1zCmBGO`c6iEdE)yVGp+)VkYp~#{qEM^Qz%SlxOAsF>qT1Tl1~#J$@P!il;Gg=c3wCJ?IuMAM`56r)3J z>;k=oZ@ejDkwt?{JkLn9qNMOTz6j5`iphzDGL``f598Em&w_iPmdJye$;HJxBKt* z59ErAVubE`D@q}^sMYgaVjcOt>nUEj@?URbXW~vTr7XBkL_E7vDNlW_eH6R*6=}nz zE~|t}?_SJrWc|p0M$t|j=jmMQy}ur!MTEJh(c+QFrd*C48537gg1V z6K_%&fuFo>KJxQn$M$?LHv6B+HODpI|Dvia$y@juLmv92b3lbzQ9PGQr-w|A-gKAD z^&+zNk0JMyIJDXr0v*J|gY~Qwfy$>FYZr31=&~F_A=Y7EI*yriSvtH6vB(L^)o`7d zLdyw{LKIhsNC;lwa4;2?H-Y>|@|T+Q;B8EywVllU6efN=P&B7&t6*Ck}lM z@HO`vIQ4W+w=@V+mnSd8mXlm{#Q(1@Ba*>bR4ERo9+r+Lo+dI~esvU0X~x5J9;%z} zQ4Upq9u;P7@~Ev@pkFLlYd1#Q2719Sm6Y4mJ`ctk+c1zP9X#E{e#7%h$11Ax#rPvDzv*PeAdDW0a~6Q=(X;# z1v8lZ;`H-ssJ`vr5$<}wfm7KYMq?KWp1EjbRhaP9bM!q@di3E`Woul4G8$|B+!RYi z__+N?u$zcq%IMWHOZX_Yk2~_EBf?AW;R6}JvVz$AhYtntteocp_^$|Lz!mYuHV1ifQa8X$jLV`p8$2PydS9&UIEk11_m0pLKFVmX8q@ zo<7QvLQ9k(@XR@!I>CVj5=nJm`AgpJ@7b}EvJ_AP4Z@$*eJ`A!S_NlXPHQ%##zTML z&xQQTjyH1aCM*dgz#n2;cI%O~$+DF*sCsD|7_v+fZ}cyJb%iqt9{Kod z%QahCuta3ZSR6vA1$QuGZEgYS;R@vT0xtP}tP$tu*>d%}3YjsK=9Z=M8%f|j7g=wQ zd{8)XwXXiS2W{X{XQEZe^~qbyUKx5`JBT3F6BlHA;ZJhj=@xLbQ~dY9F6yT-~1^|UW4HJ)i(LpeJ|yubbmo-gt}RIcM^g>jS7q)7s!K<)EKHHw`dxb<1{ zJ1bR|5n4y`8xL;>x!i&h?%axs!fLn{0~d-nIwL*5W2Xeyn3Hef1Jy8eaJa>|>Awj+;0MW|?_@S@M$WbtSC zYF(H)$J~3~2u5_L!13D()MU_PjOOEiJ zlD4@Va^Si_OR)kVa8jaYowKKY@b|kKhDr(5cw#e+SI2>>Je_K-ZF^hcWUDkpkN~TR(gx4= z#HJe%&X6dXAwr~PLL9+_SGLWsKPqwDB4TYRWR3~=6~q+wX1RSfu_LAhg&$!5S1dwf z=XvBzI&zc%h|n%f?gK=F6&qa_b^cBK$F$2*={a(f@K_cU1LYYRb&FpiliDzPeNhce z;2<*NLEB|U8m%BFNH+3NGS86&%Ovz&Z#kw;i-kT11cIipi$#Dv5w7?%?>nzwnT&}3 zI_&4fjVjBNi}W1P5>Fp%&ViUnSk$X?pK{s5sQ=Tz?zQ` zW*Q1pV8y{Gq@gcvX439Tv&nbdFF$#gFZQm8pAj5ipUQvyKrXk}yQ|V;Zl+jk&%_Q^ z^2J*}&%MMw8bs2y;a1@ut9ks9sVe=LJ3mXj>R@mZ46b|otrg^tGt4`hMpue-sD=3& zWYj2$DUQKeUkjjbVR&RvgErA2uh>?k{QZ)bOPj{R({e#FglSd6mXh#Nomv^710J&O z3OkaXyHb5CGVPY&Kt(;wk3@obFmnmB)Mtg630B2l$7pkmpnvsQNdKIT^K#kF^g~bn z2g65~7MRdZitmZW5Y1$)a!+5(RYa54W-Ba9s~#7WNM*Py>=KmO%%vHxFa5SJDl~rf zd;X3-w47*x*zDy7Le|sAN{JQ6cSz^S4Q225Oco<+I@bs=3pB}_ve=u=O^|8iX^@hx6KH!^~10>w9!+7V*a?4HlP~lYTVP#7S1=@ z|144%kX+;O^2Au!pli0mtwuTy%(ru!m1{!85P)kNM2OJBL__jrTP|HK;0S1W8jO{E zDjZ-X^Z+5jHx8sT)if!J`JIs0X2z-sg27I%Gcsh<@BEV2ZSGx{vL0a-O!$ms+PC19 zD(^x{1F$@+Mhl>1=sFY+bYKDi9=7s?)Ztd*4g|z`w!xMBQr34ND&)hfvg&6YjQcf> z$m=~Bm7EzwH{sK~ayeMntJQDhIZXToY_3JieKz3`?*0SuCyv__m&2 z3Plq8$z^~71@81q9$-NEly2HOaJ55ved4*B_60g>1a(UkMB^dRM@~zmq&5;_#5k~t zVl|Vla64*W8*so5su4USZc9Ljos-4@gS1NmUOo_MQill*T5_#Ghyt5?YpS6)WG4-L zW^mqoqyC$e_nfLm9v!%BA=}>A+qrGSg|C)T?CT$lIoB&8N9`IuBBn%vpEVP|e;1-d z;Syx^bxLCtzm^*`bicg{i@|k$YQyJ!E?jRLIHxI(Y8&v`!@bD_-iL7yIdH|&hOMjo zGQ*Byw|O$y?MD&s()~pIQNHwIIA8lw%JN8*Gka$XtOxvb)%k-i{d+!84TrTPKSPT-t`?8_LM&G9{xd>I@iv*;^d~W0DZCv&K_Yf zt1f4GzzAdr0*}~COR8$?I-@ocJq-??m<1zcl!Y{?C5BYkD%RxSa1AjE<@p1iokz4rTJ0pGdN@nSs*6_D{=mg6t2#I z1{EUQ7nrkUnKYl-@eq8f1oNOz6NNs0k2rb(7ovryfDrp|@EE1x%FY~ifQR_qNOHIF z!f(z7li|KU^Z%&)K0JEwjsU7u&&Daw>Z{;VAi(zaMlbg-V2d|55hiU9LGeVHq1*boe9he)0}#t9&sH+H6$sf$?fE`5 z@r5QB{FwWzfNIFI2&C#lu4;>VbAb>U;O>NP?Ou)hz|4FLY4j|4RSLm9s@CXV>L=HG zT+mCkB+D%oDz93XF{K}N_E4*Cs(qZZXLRrJE$(BXwO2ts^?@R~N$k*QZx;X4w$sji zoL>%;wcGI)jPVw67@`fr*QRu8uV|qG!(ni7sZjlUPlX;;9~H#S1^c05#p31*BRbiOwe-OLmSU2jJP z);>+V&W6zqMpOq8R>H4>s?_VHLsmyXurTYXS6~h)tZ%OS5FZXi3$0C_TV8OKxD`;V zz}Al80?F!-kgYibW=1|<{Vz@5AY0IRwe^y!z|@i0wre?pv>Lkg6L(^&mpe=r-Ba-^ zv}CN>HF#`qzT@MGk>~368mDf)Ru>oM(YByIP{n~ZoKKvUp@^6UYz8@@gS%?tUgI_H zw>pZB=hoO_ZDl+}d@t*%CIv~ap{u}e=!tOBpzIU6?Isp>K9OLsOFW1EU2bz`g& zkh??ZU$7vSiB}X{2luXo1A?R)(!ZtR;%0gO<&(VDU&%srsW7?NjiW*mN={tTpEl-` zOQlYi*yB5@^5dRSBMSWw^ATcaPfprBP!cDA;as=unFWtYFa!WfQoEbQVN)>yv2~b& z(YFP>a<|Ji9fPpWk`HJv(M#=O0q5F|K788urJHF5Yl@B7Sa>z{9H|@kW`6Kgy#~we z>DJ~C(6M<+stl_PJmK}_4)K)xkv1P}w zwA(pjb4`*!dW{)aQ=pR&V{9x0coz>*25zkP!L?Z6O6s1n>W~2r@l|@|!N)lv_NR$^ z+5iWZUu$8X~FXO|Ib#`s0B^1n@l7zC$$2)2-2B z?pCZo>3R23op`uAty}&8wjx&Dx+jUcV`P8ulaB!6aSYS)4sjB2=f|Gk;+6t&AJa;@ zzWxYD1M$+|L#1{W$=^SJIOyNqOW@L0XE}Z@Uy)h+4Ph4pzGvK?Z>xP)pSjSQd-IMx zf%U7Peho>|xZMo6Gt&_iP#U*%4EIl(%v7KQUdOOv?*VIE+=JWwLd<{U!4K2j#}&1H zfAjtwdi|fAF2oCk632P66Wi3ZQ~(gi!; z?rUjO{C|GzMhy-7LG-<0w6sEuh@^X!^vLWzQH1+ZAblxSoPR}DTn4FXAUgN*6$_0p zc2`PF$^>w@>({M6vh~>i&$hC+jbkqVTf*t<`xDPCjU*;fe9PkL>r`R3NJW^z;;qZ1 zAGl#>9p0KJy5gOliW+G7s%k2l*Vq(fy0(%feZ>Kjs?&WiQKAiNnY%)oix}MkB}^gH z$}I00fjsL}q~Z6O?(=f|JJ?N0)g$kx@*D^B%nm zPj}`t9vFbD3Z}c)=f4eqO>av)8r|S7Hrl7@L#N3?k86%nQ_d7?5B@nPGYVR(Q*ozw^|7dOn&@JhMdE?p=rruf z;fuHl7>^~LK}lWhd6s~E_fX9Km-O8SDDq_iX)a88_w$hZR**B;L!=85is8*ww=9qI zYfj*Z!oVz#eZ98xRi1yHX>g0S!bdQ=e6#1NGV+{EH10B95C zc$|AF8`@&^^2-Fgrc zD1=TVYyv|5i@F`~;wP&8vV`S8tDDF^W$hw_4uC5fvod*e9~4J1`t$A!%_cljmo2<({zQ` zHu5`&4poR}a9ow)akxDz$&ubZC-D1q6^|8e^uN4f!l-cU433IYLRCjUW0N7B=B)!L z@n{Pr(v_Eha4k_V?@#PQYN@gNzI61?be`eO+C%nl7oMPOH=g(!qqt?N=+w>I66@Ds z7UHB!O?7V`pgn32A!pr@2wHkCu%`fvY!Dp{-2400BETdn39F534;Eoe(xi|s&sWEi$H{_F`!bC zGSJj^IYYrcBx-e(%jEe}+_#?~%VK-zfJhYsD#N~(pN!Pv=l@|stJcu5 zk2wAQ1wg#Tpi+-b%&+g?pvTjqTvLprLc$&ViPo zNouA4$@J#ppJOt^5^MOKP2^Pu%ComLA~i`Tu{!dHTYt%*q{(j{$?2OEW?Y7=;!c}a zrZGA2l{9P280@`U4}Tg<EHDEz`QZ;CGE=K0UqiXtcBJqdk7@(t8&Evb z+zkNk9kz7X+=SZYuI+ZPGwxY}bMdW2x7S;|by zwlmimiHfXl-rrFTC~>khK)K}2X#zOC`So20uIh`zl0499Uo!@6w#SobO@9r4Oz2Mq z+a*2nT-ZxY64WPJOA9{*K1?|H1_Nj%`qOH*5ng19)0taMx~_^GX1wW@9y(O@VfLdI zIegx2KA+I~;@i|)9nB*9p*Q2*o%y%!-hnU;-da&lGHjOXv-Rmod=z@@9)pq}d7$lA zZ%TyuMA>n|MIP!NN}p`UmPnhhMr2WZQz%;T_+!I(8RRBu^hH3Qc(V_Vl9BeIZxwH- z2<0H^R11{P>gSj)ZvTP;{JWO*RqMVrTpow@#kf*Mo~6o4#7{H`5Q-Fmgqt#zu6Pn<$8V@T;p=$D#Z`+PPU@q;^&M{0qS}ZP(RsoqW%89P{IY zBg58h_2Tl$HdMs)iTsWy;#oahx}Z>0-MK?bz zc^jV?wO-T@8iZL9lFrDiJSBT%*H?U5d>L5V+9$hf%$U{xe0mOge})&8EKBYA9>=>|F@61 z*4rD>*v@aL54#2zf~X5}v6PL9F@6lQPbOzZemT(h_RxcjoNbWsXnWrI%AH|GYnT9lL)Jp0V!uIbE6a^FtlH z{Fww?tVPUJB)3=uE)f#vqR91+&%yowWl6u{=jdb|Zw+28Ppt5rM;!ZtDBN@vm6XNl6qZGb06kWr98iuASoRmI5CSY|%-% zt9Z5IaZ1Iv)6zJ|#MgM?I;=DW=7Ya-;tSYL!WjpLmI)-8M#)!s%O0g!>#oPVeVxGZ z1i>SWM1=!ln=v!TVgH>EK1L3f?(}{HO^GQW#eF@1-i)*X^_*QJGwS>k!;7)|qiS8F z;6d%BV^N`ct}%(0Nhl@0yr@Ku>9n&zJkKhENB0uP583=8z@C;qX9-)V%Q{Ac&24fP zclh^3W;8}+|103*r9s{UoY6uY8J|;Q71I)b_$EhPT24s5aROF7ndZ$0GKAxCeqoJu z>BF?F5=&UHaO%S9&AhJb|Yz(d%;QW zeriugo9Kma4sOCLn@;Q?rBdY-sKVXSNBd4sa94*@+QRu3b+m|-wMR@sOZ;;~-&FaO+W zk%FaSpkV3NVsy4WlSgLh09daphOQRhn7xuoCky)n@@=4e8@#R;?z@{b!dAGD`ERj@ zvi-LmpJp)#(QHYJ@DG><9Rs-CN^2|Ld{{j5-Y%950s7Ay;OIPVNcM&C^wFJ#@_rWI zzA6Hlu&UJk;q}G8!Z0JYZ5RA*B`z6|X*#1fBF$&8tC*#Lf+Xb0Qo10kDn9+DRz|K<19s(WmFrfy zJrhI1V}s6%W?J3Y5WdR>x5Q8iTrL26eKlfu<@eF0njV$^^h;-P*sZ8q&Gd?^0qkHd zKzF~^)Z>6!wQP*TDHP24g;yd}OWB4Ngeu8nf&Hc`m6oiQqk6;62hPst;a!1P35x3(>3l@!T={Gw?xxyo}`mSa>?_xBF zVa9ae%v${sbREBP-2*sq@j|oNdlDZ7E=WT7wZU2Z$Au_JeUy8nn`P|9vf{C3&8IFM zu)J5lFo&-KI!xq-sB~L;OMF918Wk#Qt=`yY6DogPnt>1>Y_%9TpPWze^)GD+R)<`p zy}-K$6hqbCH{&ZfM516iZE#Mprg*)kiHyPnnrLoXwn9o#ux?hb%1PA|7a!=L6)znq zl^*U|;)^B_6NHjlZ8Brs*D%UU`NwjV1(~%znn}Ohb3Xbc*+kN2g=^b$x(cP+fxYUBNMbs%BB z+pu5n?4a?zB|U!C-URlz+sY}V7u)}vS7*h0D067|blhv9A!r%Yos|~bRyK3(02ZKF zVr@EbsthxK#C@?H{z&zP-i5v=nVCy8(Kk=%4^}y38r#2ZMyqf*ECvtj5=M2IprFm@ z!iDyvu3@QXtwR6fY=RUb{_{x^BA{+Br+RRXeb3<)JYvR-wxoHhCb1e`4zs6ieUp8R z#Hw7~Iwi7vik6$x66sb@h-Ss(qbzww>8>D&Jj^^<5Y_keARXH_AG~z*HrXk-FubQz{42du78-;UFKQXW_}{ z>ft&0=LrJOr<;Z#v28$8a-tt54^KdZd;r;_#gdCdnVA(Lb3!eIS+S;|@~t-B{@HS@ z2Mz~3*6Y>Z^BPh;qoJK$9|LP#n2Q~P@KGUb)5Q^rXP#+?i=vw!zKFs^(FY-t%44Sl zE)J5qRhuyCqvykgcw%-(D&%D^d2*)>O0ks!c^}xs$%!wSNHh81`k4Ex3)89;HiaC{ zK}Ei@u@pnkd7iMpwp(UMKwuF?ytF!uAk3MCSgYXh5!ZjKr7Vvt)Js?>FL(Ci0juZE z7k8*()ImWO@QRp^zQ>I9gy!J@+&#dKu(afKu&Di_5J|5ZK_i!c#r@F+rPanF7|`=1 zSZf<^5PA6}Li+)uf)~>MdtvIPyLb$#d2WFJ@A$MXAge@%p`wSgq5$K+4=p}`X7|{X z$VY?nah9(aUgG0K?%%!20%Hk?&(;W)IkwvncD7!qiG>JaX31yxBy1dUWh_5{oB3Sk z7GY}poKGj?rYZv85m>) zO`nT-;rgCXbPgt0ed_)Uf?1dI-{#1hZWWEc-FH3?Oy)o$ntW^^&#cw-z_zt(e>qM{ zKWPwuX8ruJZ3XZ=@L6Lv1aU?^Gxy*HqF>3Carca87R@kzWe^mo{#re zWZd>I)7p9HjQguxZHB+kz<=MDu%jVm8E`Qs(sB&3!~WU(C@P`|ayExM7R)}pxA^-M z<0%dK_KVZ&Jo6| z>(auhnvkPpWW8v)YGsi*-X1o5{!7)dY{+AWkhebft~}9J+ItkD`~^n#TNmPjZeM<; zM93&mI|}<+m=QO+#^iU!LuG)2cjf;!@lZ%9@3c!VM@~6r>WnZyT~CD8Fk*mwFK-!* z&dxvc6tA7lOQ)eVUSL0I{3avukFF#ij^-%HK;s>6xqXPsdYJv-B|q?F(s+)oHs8=C zjdVgtcB5-FS9Yvi`ryOMVL*ut?>1KE3sM@yA7Z_{_MXsKUp|ooKus$u|DeLDHl)A&&47_@I|5eNY4=ptUZw4zp zcF0XLjGui!kv#u>G(4mJHPB44P{f%C7bU_sEt28I51Pe;5Aqhm_gJC9W|~5xKQZ->)58E?fG~uc(n9A+3>zRpb%Gl z{r@Gl^a?h-@2*I3T`}OPAZR_35fwxW~$H{Eyu?&YytK;&D})e6Yw| zJar^(1&!e4#f&Ry3Gyl6@rbtu25;Zu6_Bbtyt+PG49^L!N2#J{>Gz1&Z-tJ*c+e(o zbdyA|S$U$!r!Wb9)T94y7lzp2D6AduJWbQ3!IckGnmN_@Hb+zxUwa^e{;`pz~f_d^z6pNoqScy7E|dWASRPzp9GAXVvO*y1~!gFJes}aLYis zd0{8z&MkJL(~8Mqa`38j3b@)o)86u8u;!>~o16nLz@u>EQ5La}a_)qJLSV@N^|qbA zQWH6Jb$aj3{CE>xg5UQeXuL$)MdQsAf7AQZD9zOt&M`D{+gN2~V_hBxr~9M?~y!8tA5 za58rcO=zaJ+2U=Jw~M{f3+ca(lSFDJDX7hc)T22zvaW63by+$J1Dnl}(P0Xz`gFnx zn6YmKP**27J}oR1p==^}S;Jj1y)2$`jy4%GzSW(?ie3k0Vhk=>HZha8`$Tjz#N}y9 zyFRcnN0-Y!956CS;w{D%Ygu@%=XSa@TrEJ@3lmPlFuU^y?{!u?w$_t{1b?YF>*T5i zpE&;w4sgZT5Z&$x?p)eU%AwOBSmG>X3~p{YU#R9f!(5o=GbF<@e+d)7+OJ+7%`WIm zRw}Z_Zf)D+|5o((mMVmmmL`vWap+KU599&bU&Gsu3ufaB%^;p4xc7{Ef$QLks3X-P z{pU`lU5DyvKs(Rw+t6M5C0z&)%zQB*UBdGFtuPfcA2y;hldR_f)@{%PMBbR&FsQPl!#Pj41ow zd+_t)HN}B}5KSS;g+WcHtfRUhRxt3~nTz!WH3vi~L1HhLlb95cuu&{_*Kpf92eu-p zmG*CWoP#)Hfr+gfkKVQ@CNtokV{_w!qj=BXx6IW#nvpNpUS!F98-%<=2?URhp7o_9 z*S6m$G;fQ4yJ5lm^9=RUz!DJ`(q@pW?;A4b^YSxLv ziogHTH8W6nN@57Npf;>Mnw{*B;S8I>c7_jLh7%)XLa1E5Vc>I#bsh_>x2Kxvgt1|U zKy(ZorbSLwf21nGa!ci}^>0OIjROY;s8MWd)Sa$iS~w}p+iBIC*Mq*~MYqX1hF5OB zsEoe;t4vmA^KtbN71GU=trxi8n@8Tl9C>l9Q2`kMBICP(K8Bxxr-&rrap2+nKMzmo z5R*8{p|Et%w~EKn_rv8b3EtsP)vG{rDR*R_%cg?=mTRpA|5g=f35%*FLgV|H9ckCG z=@Kn%5NKFydE%vF9CDESd*J_Sw`Ur?%2%DtNcq;VxiBC?$0e+Z3nWrah#PNQ>~cVH zT{(-Gcl4lHYhEs$0A~?tmwGt%qNUuVOI-k5jE{cSxQ&-^BG6X#Sk75o?ra183(eNK zp>X8wluc{6U4~uzqusT&JH2Bok)iP?ONrzs3$}Y9DXZDsHbf_G2?j9y{H)-%AgGre zZpu$`SbSj3dxA>5Q+9+Q{G&~1Zfc_=*snpALWAJSyUNQdrDXV}!E2A(t3&^|*RDNs zdfK9rc_V!0;-ymV;+luO6!6o3Zw);~gnK)GMsKNzX@Rcwt_3w8mqB0Js`sRAiR6H5 zhYj7+3^xiW;NmFT^C+@f9n~`xJ%AyT`-%suH`>wcu%$^ z*pkn<7{^!Jf3ns$++N1XnGMJ4Zw!)H)QkQGr`^AHT$WOMBYxEUlplgovUIdXpi|h+ zyltDCHAH)Mujs*(G(M*eR!6V~E38otf*hS~%bRq^-AZTB(gWR39GY8Fvm50>Wjnf_ zVTytV+s&HI2L&89)N@I*reN49b^e(NjQh{g@2vOzA9)^&;@xm}=L2sniGc3?WvGUt9OxQFBY9%ttbO(olOmwKWctN>E{@Z zRnHqN1jHocZ*(0t9`rn2YeNKm5?u>c6B7U>7Djh>Pdd`5fm@k)YxubHh!8wvgigGM z897zGyVML&&9X4q)BYl;WX!KK?!ea&_G8*gR=!j;r~ zM`1ZB{rKBBK?f&~Ew>FVYHPYtEpZZ(#z93NXNaP5{wAs9gI`;y`6v3urEiCB!N;Cg z;1A@+kp$K#^`zQ0UOKv$&AODx3yDe7|TO%Xhzf937DhwO>LADDvF&)PR?36z_^ z|0q4LfRz^zd{`!c`~52;+^7#Zj8Vau-4MgY6i#JrlQVp+KjI$2;=1v&{Nt7!ic>nd zq1$bln3P}HJ$JvK0+UO|NVNj9C&~6=1nzYr<`v6ESTn@VhYhQcX3#`sCpw2 zWkcl-v<>?&_h#h=w=3*xX~(0HyE_I>XaCr5wv(ob(R7=ooSV+arExg@6>0qf!_5;= z?i`3GE$&xO+|C8rgLhJ%R9*2@_0{mxM$%F`>oMPZq!d1k`#Qh7y;>yOD$VhaVH?yl~z|mnk$g@SW}PlM>1K-Qb{i*3QW?LfjG)t_o_B1 zJE2%#CAPZj8q#MS=FgkOL`3z0mlY!C$W5RKVwVE} znW0+Ar1>xQ+~L{|AxY{cdK{!vM!__5w;(**HjU@d?nmlI=hgOzX)*GQM0jzi{9{V_ z!J|<3UHEAR{3s3LLnKvnaeZV#vuJRM&sr_*A*r+jY|M{bG~s_@T~)?4`B9DFT^jm{ zfYW<{3P0e8d!gy0H2;e?1M1zi06D0LmNFgq;~Jggn&vnv`Z0x1ZB}NfCktJV3Lxis zmJ}md;7lJVPw|MvOZALK4^{w`7A1TpH;b$^#YM{5ARuFk*(lKvw_HB|(_?D)0-+xt zr=05E4+ih5mhlI&xqks|kke*TWKfL%l;kkF{J3oSxI3mqL_C&~1Wh-K_x86`Djp1m zN1~9|m_)}flu%OH>d!EC76^9`baoX?W>>w^Z;w5U+_n<;b$8D-h5E2A4o9JWwqJI& zx=>|`h(aMlNsv%VDlh;F;y?uX0Otn^J}d$-zsfePh}@V8{2oDO6opl~W5jd$qkQoU z1@7Q>_oWrIS6)!b^xTymI@S>VNWXIY91;QplxXlBnF5#G^fZDJ?^A8`O10NoHT&=9 z*ND&$sVyUx?};{X?t(5P*l{w~A2L7ypwD0s0+s7633iT9m$23;aH%ecMoQj2 z{~Ur=70Wi65VHN%v9{H%rdR!m!go!tCH`*sjeMvJu{*o8?i``l84rK*-geg1q$J4* zNj;!Zw-D69mQP!dnqT~EIVy7%19F_a#?#}?Q4vAxQF{lvC-xk1x|OmE)4+9^oa~-9 z>^;YDMY-7qzA?eNXW0eECzD}S)`HY+MDTW_21}Yh;N%5Io~h}oV?X=E`W+^|N}RY* z9bAR8XLM$4wM++eQ&r)>S5jl>wZ6!K&!u`>-#b0QbwWN4*cfe`*uP@Dzq zmm(j!Rd$RCVX?EThO=@OPQ>!~ZjsJo_fMAH#?H76Lhvrsy zrgd3!9KgJ>wg}KA#E);~+Ewb~$Ts91Wi-XaAOU4!wVWpSJ4A$^4!bkdazmvif$T37 zqB2UHd*sRcr2Iatd2EOb-p7eN$vuvwMy4S^SysCgaVmRf{KL=#3o~DvPWTrY4%rlm zQ{Iaa3yo4N04HPdh-9W8AmYj79QhUjmw2c=#Gy*@8>2IuUaS1jBS*b~Wv;Q!4rDC!StC^Gh))Z&~` z*^{s{TI9alGv^#eAY9G?Kymys7bTmlDt^L9^F!l-h2WmhOovq(k3hQF^s#Go$36la zYAYYi_=PUmo0WAD7)nrOf`J!vHL(2EG6cj*|4 z7@Bkl(u)|S7crn9-O!~PItbFM6cLmrVCWznK@mYCT|lH*K-6r$-{GF^*DRI2f84*uP%qId0A$Mo(f+NCQKqM;$eRA!d1fB!J11UfEf*k)l2mKP~63yuk4PhNj@ zRU}l%TC0I&fxIN*cT4DR7NbMyJ*9q7{}U*mJch{dG3`p<6?YaQ3ap6F(x2&k=m?{5 ze_9-%&|3&D3K3wTuj!>pR$uyx)Dwe2@@uYJMY{oy)S|08pCuG$-TrrDob8(R<)S6d zk5S2I$pE2)iA)uz)V&%u0$n)oiqWc%t}}Wr3^eC3WK|SbpMTRMsvapQa8Dw%xmFly z=y`QsKk8PVxF&0k>1ywR=-)v<6ye*F3;;OPcgZ0S9l-i^j(YEW?&JgtKVZ+n8KL#KH>d(@#qVbW;Wk{QJf5P zI^P@|l20YC4(#)i_pb)S{l@$&sD6|U)803TuRH%@-0g40Dsu)&(Gz~)H1LGbYE!R9naZg)!-1|Rd3Rks$kdF-XGHj zi2(C1;Snf-qaaX~um#IfPZRjtLGxV&ejHfl>Da#S&aWU#uXsWG=64-~d+eA&j{W1g zsP)v8V=>Ckm2WR4noV8@!b%U1276sUqHl`<&5e^VKIUD;!hOf<&G)*@k=H1TDPccI z1s5<1@}}RuF5HAm%(zNhNv_2F0Lgv3PTvy;=WulZTOQB`*!Uf@zpt(6o zJWNX!#E)Znsk9_QhPF*B9XLN}E39^n6{OPm*V=-%g9#xZ3;@p5h;35x17zC& zZd-YbjEhgH0QdyN1?p6~1%j?g>1D`_a^_SScmzkbSYI4W%en2Z1~fW0mWF*Z%~TI@9vUL= z`nu@LlzZn@#{D{8ZU3t29FV&y*?#g}GQ^=N^^36Xm1K61rly&oZXYK%o4j$M?aaHU z(u!CNva`jln1*TiuUqJa^ONoPwO;*qKAZ$ibqh6ed)w1%e9oHo+_m-fc1_R}R?VW0 zM@>%^_2Qr#Z~S64&rX_don39(nl8PR@rE*yscRk~PIG!~c^l>JBQhdDD_67?67 z-PW)SE>uc_a4}@Q;DigOV)_tkd++S-1J$)RO%dsVj#8%*60W|oLE9^77mdZqiKxuQ zL>g}ApNn?-ko5Ya)uD9$5nMG-#>a87q=d_08t91|b;M2S7|a-X2x*(RpB z;UrS)K%LuFd32}S)p|O_KEylAC9&$t+^`4LMb%Gk(r7jm(9trv;dUC5lXa?}bo?HP zXEh2l+ILqcqKJES|W@;79 zxNIWd7q@sLv6;?}A+IYe{_NmIylF)J5NccxL<wvK>w=!J)& zKh8xT@W0Dkj-DZ;A(5A-0!rBCCF0ZUgpm3H>Jo%k1(WtDf58&X&F+x<($o zgSxsA8Q{>-Scv%?Fz;ORKm@TaaJe*YyjDK#K~dc9(MUW?(Z)k+!p_lpyJPbCjFw=3 z1*B+ZL|W%4i~IY!Kn`*As*Vs9=?{Hi4mL6_TU9)(6$#j$6TYObOEdHM&2&M_=ppiP>*v>BZ$l04TdG^A`Ca?D-{_2iXq?+hhKF#FHD z*JcyV6nCuj5GtP1*E+G!ms?XUSIbTEhb`lJjw8VOBHH&AnOW3G`8}1M5Nz1Qdj;jk zSakyfef0UW?}k|`6QWu=Qghr*Gve!-V}B&nXWyIA%bxPM^5?ytzjYK)r6;@dJcQSr zZgr~Ec90BC<6ZDJe^dLa!bd*x2@0EEnN^$Nfm-XdY3f>dILls%f=Joohw+5eZj_W` zXp!m8;iGKUN{XGfq`kHM8&Hs$-(5G_`Kv|ojhUvKXeQeSayr%zm)6%+o)%2r`uL{I z8Qb8+mGVw9fSeJoUqUCFXWYH;?8Tq;Z7+^py;nrYi{m>niY6LUkyE*CwxZra<{{@r zm5J@apRpBD=jN8cKkgstt-1|8m))eB?|g4uD!vhNS%ZS}y=?7Zi%1E+DDk^J+uS<$(Z50PA~JPZM_O$R|d={@atbK?Zy`ZZTSU5ljNwG`Dp* zKd5w6;t6{{DJ(Y+mhyYXFM9xB>;)Yp*Z_me|I(5S*;Q~*~_I6n_$L9yy4h4Me zyp$>w-tS&h{Ej250?*I6+sV|ukQ}a2vSoF;W<)dTX~YsUaUwJcqR-aTgO`6u z`1D~7LnGF^o9r91#w9024k1gXhx5&%wl0!GS`O1oG^bI__kyiQpNqfx^IGsJm^BoC z$E(DeIJQUC*l`=K(Or7agzwnn#ecuSmIu9itE;}EfUfTN(cRmPT??=Nw7l2W*>y@h z_86J^-dy;1&&%TF(z~gjZ7=_R#Xo$xyk-8Y>%-sukm;8ne@*@BJ^TBOz}!uSTb%Tt z`*-lbqI;EV`eaz+-y!i~_qw>n>1(HdNBPs;n-`}~r^5domooQk8(93FEByDp)}m*} zZuf$4;Rk{?i%I{*TUp4$uV9psfEd z#rS_-igEG(Op1XYmfR}3`-lhef1?_s014J<7RHia#g5TQX+m!x0U(*(SouNo&H9*l zexEqRAv4zn026qKt}S~^tBhi$V|mL>|^NuQ`|sd)WRB$f$m#FlYh zPxgkCtfbY9WeJ)Mq(b%O&SdD=CEP`C*On1XC@MjSLt(Sxgl3nG`Db2ckJTx@2_laW ze)gfRJwNr-f;?qk=su&fsc+j^3BGXKpHHn_Mmb&0d*@b22%o-&#nx}pPMhuLQ&up` zrisZ5f?bg?UpD8rvIDb~WzkjRFCKsHdRFlM@sfj!PeT(We@b@Zf_Y!zrx(>>$I=0~ z>RSmPxlXHns;BQT8obO_*x!3*>f0T5smgFWPfy$(tGNpktX^1Xo}LX#C#~-(L0+d<#?X+R8Wg&v zZ6crJna^0gR8sk)iWp`2QQDZ3ozdo(S9D_9KdX`l1(^P5_X(K1_Q5IS{uG`Gz%TgT zc8l@}{?>a|%!@U2PA3{PGVbyEHIv1bcl#LV>kpb4HT;?&W535h6vN}A`om$qdl4nC z22Pcp_VN$>kb;TiMO?=?Lp7Tl1@!*l2bFbAk0+T&CJx|3bG$o4l%we$&`9&n@3>DunM|7Aza)Ea zggGr={BYdmBaDeb!Z`iSQ&8_&|~XMvq%PuBVFe}%!JQ9aQ~2hDE=JJU(Qj5v%j}+L%JXL%*kzv zkJF?7IF5dYmcKd%m3n&!83X4Cn%_=eJ5QV$4$F`Bm+60tjfx?k(Vb|u$0ySp`QC7o z_h=8pPDhkONb_2XF{B)Pg2Z#&x4WZ*-D#eYPs6Vt(Jd0N(dLP>!Yi6lhOevw$|9Kx zSHE5j84`Omdv7+ykz8s2g1LLr^o+jz@6nAeH0Re?O9t0-=SZ6O-yfzDDnHzm=VYyG zoV{`I@*_+EJrX|8l7^(3MYBr{HonUGM^CtI0|W?AN>yWUBDKXYbH32@H@7!$UKJ>L zI}qZAi7rfa<2N)MSdYIAO_{H}kTh(>cR+%0*7mXZVPn}tp1Gh|xMeLub>PakbEJGl zHEX#{jOGGwDU9p#+#8$B3}6L>uozB}QZPuKKno@kU?GIqC~X40zO%>DGGgS|dnR!z z>m1;G>Cra~agLUv;79&e<_`Asntqw4q zBGRA;TMAmECNrPy=y1faD^OyJk!NGGo*uWM#&}-k)}^7!+2=GY9ba_s8NVI=NuZ^I zlR=u8cMO4_8~=XK!5!NY8OV2{bi->PCtaPp(W>Em9XS}cfQ$?LzaqT`9-WJ7A;zyg#h`J9-Xhpkm;Y zzgVWKrWKge-wOMZVbK*J$Xt0Tnxb@_cM@XJ(MvxV4fZ0$4gLN#;JPB|zmODT8NBy6 z)a&WtbDl|!d6OqG42#@(( zyf|dKG5+mp_|@a36Bhw?a@^DIwJ>iqSV3Y-H&JsPI3ojeWF3vO;b_qjQ(D2wbJ>Sm z%W}4zAS3;?db-@iuwVy&v|%(e4gM`pYQcm+)E*#$bYZ(le63)DzrDrBynd6XUwOXa z?w7=yT4xSVGtcbSixxXZ70kua$Y>~(K;WWoM;OR*x1@EqS8DJ&=J@6Z!q| zVuUcnJNAVpS^rp8l!I2^v25})#?EQ@wtG`!K%<`vBxmljN{ki(K=6CU6u|IanRkA* zrS`^j-@oX1edE1L71PfESw^mlAO7shem_V0XdKgKlSW{L{%%tA|6ZAxW({InIH>LU z+9bGQ1q2|D^_*E_f(2?ub)ncch*=S`E82oBCoH=3BKAYbLr zMxG(0B*AnmGUqSpPn}vn7koZ<2}RB@FG@ey0%&Ns!Sw8}PJ}Lo1=+}=XpivUh91)` z&ZV@>XnFY+y=)~~rQk$gddeLBH4T_@`TJ>c1mC%}cSgRr+}M54!}**5+x~RvTaeEt zFS+Xkovlf$e)~^Sw*MxQ`___3qvy6j;BSQP-LD&_nr=Rc;9ClDYWRy`QLW!+h^pedT|z5~V50xM zu=-DjfCr?BFo}b!HAmL3bnZ9Y36-;T5V;#Xx~cy`SRZtv%Bg4gCs2w9usBjimy63d z2y4~0Yg8*LlGuV_0Wc}NKSDl4R~{;h*Iczrw2V)5{ZEzwr5A-lQGK%&b*c1(u7f~NH)3%yv)#Vbm>`n>Pr^==S&ssWY*aP4AR?REeL2hdHsOTve zE8h{z(j^E-R_mX% zoj55E`+>ag|N3Qav*4nz2E7{#K@$G6dKhD({_5Rx6Uk7URd-mtq{OZTQ3|ydNjj}H zLZZM9NDzdW!Q<`mV8ouE$L`s$NH1NmJ`lu#gE$dEaR`|~IPoG)*4;tHjEk;0@ZcgS zNRtEy;b^ED66O%FEDnGj`02&R%(W*OdTTcxKVUV`&O{jKglhHPrNFKlq&ut&;*D*b+y(Ei%7~t#wJp24|X%r z_SKhWJvF5|)DDl;qQ-Q6)~V}$4S@sd8pMZt-GoYhYoIAuK?B!S0tK%C;a*f?Tlxh; z0W-vgi3BNCvwtWY+;5BYxCd6{@vk3)A>2V!s);-ns_YiK_0FCF2NrEsj#^V6HIh>#YZC|IRo zZndj11Q^YWP#l4!aC_Ix8A<$CSOLKaP%sg~K1hiTvh;G0Alm{cW)g$6B}b`0KrW#ueR zZIL}MXUzpQg~CobAP@j5OHj?SD+%=~l=^k?ie4i8`<2tph|z4j-L*Rqs1}>+J>-{o zc!=B+NyvI!hP6-NdK|RF9z?akoQFdL7s1p=ix%Q?p7P}>6|R2n7#{sBaUxs@3sFS@ zOhe$HC(`$7D?&p`_Mo~~vK?M$<)cMv4Z0$cZn4P3y!i(jK4_`R7*jNgN_}%fs)xuC zAJ?Oy`dBCyfF)!}54A|Mz60w56zHAg#xP}ln|V#IfraMRj*Nr=!ADQzLvc6TC&TU(`f4C_8!g>X%Ojj0M zqjQ_Ipz6|`w|gb9Mcp+p=n^QUy;MxCX22+q8#wvl!!Xog?cgi=CH>m(j_JA=Rq+L)iQ;c2~ zK7UlA47x5_gW82iq3T%FA(?0C0w&!8886*^brl~afS!ZB_FAIvOc+W6! zMb2ouR?5-D0|yqU2PeUAwx}ynWjqEUNqdFCU)Mpdc;Gt~zT1iA|B!~tdzJR##cTS` z>vW{+KPWb=0Hia)(pa_aQG9R=^p3Kod4S{cY%J;<7n94h7 z@%B%z$$gUs;S#J~`SuTm`=c)ANOZpv4Xumt8el!JftP|=P!OBF+NZ04m_Awr<-A*{ z`0t3JO5(~7{fHil)n34>1zqZ>^3N#l1y&(!@6^v>%kJjIn63xl89j2Jn zlrw}Enfw_5DThAAX+q>k*UkN&4z!H_^rmvhCVte1JJeOz?Di%_IZHdoPZ{ zhv$lhH@>H*v<<2U*&2}Gsm@6m^FcIsAL_>PjL1)IwU%ckCQmI}$>21)Qb(7EDwxft zk&Nc6mDjT-re}F3H$`d$q+7ThXBb{gUls-2;+-Z<2E#WeWri;|M$kJCdRKQ!>te^H zNKkWAnJl|#9os@qvX|Ij4YVZqq-rp4Vos(g#W*!ur*u$A15&b#Wig&~gW;}k49^I= zsvf^lUuKRJ`h?CTUAMj3kDui8!+$hT^+ z;Xwmisk}Y_w!Sys%3;a+59}a6-4rP|83r9N`9K-3;_dx>&e7bo!RoavNcw9UZRCdg z5a4}n?yl7xbvCkvD!CcIW;X$GK-DDu1?NA4&{{#oiiY9xkld6HrkM5CA2*1ikWY*g zND_R8uBC6>M*-6bVruRY%un{DnU*P06PszvD334l2jd@=`+C4Dp2-SrnBY{SZL2Xr9~sUFK$U)j8OIJC zzaGkA_N5pCQyPw3#2`!mc88^V&!|=eeu!w@VCoC2F@}R*W_vDEt6vfh{$88kuCst% zi05G9;`M-V5TU%xFbt|?&kI-%1zX>yEY@y!V5-2qGMiRu5M#=--~Qhm$9*mc;H(O^ zFU6Zrg-*OJ`qcWFAF^tBSL0F z<`o}W?HZm8&Vf5D#&nv&;3BY3?k`6el~xM1cl!D3!i;=lf6U8ycIaDUb%_b7XaUMZkTr^*Us!-hX|c-l1L#ij=hZdmZ1ffo%qcYh86JV` zQ?(f5;I9e^a5*rm0>fLH9<&fSqc8T7%Sk>dmc7%gxcKp?>u#B-^%KzANsgK`UO=adEzmZ{J- zea-=psl?m|?F_%!kJpjw3U(64c+_Kb#HFn=>DgQ8^P()03WJK^Cxde)2?z-Sox*=s z2qj5v9oF^&E~M&`DKX|eTbDRf#HRKXEU}v?Rxf8r9CEyUMZ}U{D8Y5>Sv~o^w-^#DZwFE9wn|0CNB+9@;)4xw zkhXV%{cCPlfapF*3jKTAI@8=y5+gT=r}~Vb*oI<2Bu7WUC|6y#l0m*~=SlbDg$0&% zF*Zq)aXwWN1A-}5TF7gkPLxfGkKBhZ1d;uUmjA`S)*lVyUTMi?AGrmBJgHz<8qZSBa4JgfZZhb?&!i2j5S{MWFMS3d;!JWo%9;_jC)I!K~9 z$%M*E=rAz=5C}I33c-Ea|GufA<6p+jatz$C!z z+2rwrD1c4`5Sy~c%o3h?Gi;#DKWQ!!y6_2LUPl;LbAef}1hMcfXmuG+ij{amb8dgs zAQ&1TrE5qkar=y-sz@#3nv(?QCb$7yvxPRpI>Ph!me5U7mh?mu5^w~?P{oF*^-_e* zc9mQXrUDy*FXwQN(-9+p1(}RQVm?d2CybfIQ%iM47pkSc41qe8$%Wxy0>j66qkDA| zVYV#&EN@57U6o3%={`+kX2)EqVN?ObUQoOlSH`q37rvaIXKjG`CsN%#X&@sY29%7< zYtr(#AWPywM8(J6N{EAm%BSm@lcC+cHBF%pqz#;Ri_ItE!9zz0@D_RV+~!J^uQRV% ztWQcU1DV;YH4UHUa$1+Af3A+(X1=k2Fr=+a<$?IVM{!o47vwW<_T+V^H$GdYLHB{! zxj`y9FeWD~=E7xm{VSga2W^!N+Qr;AA6!AzIEUy$?GB=S>}_3KOPOlC1NZN+yi^sW ziZ~X|uS1(n5cF&NC5`1*9n+gLgZ*fw6|xv@@3I*uSN|+fDlpNzeE9L?Y8LCc@<9Z7 zuCFsyXn*sa3Z19}q0mb(Z(+Bc&AoyWc+V+d!*X`ms*mFTfkVeDHrMH$~W{0l$ z$Mdc{Be7o^DQWyvoYjrQPNhui<$8CBF-A z_XVYEIbAx-+!OwBrfYbgja+MST=TMf(p|W*-yODG;-SYdd{J}xrT#Cy#DJC?e0$Go zoc`Fq6E8owE_xi2nGg}A&tx4QgVEhT0%=xOhXuD}SY1jn7gBA?(YVPkX$ zs)~as%WIi@r}*}@Sq*H4$9UX_vYW48^;l@;@LrE`V1vx-GRWvKZ>%T6Vyt`mHPE>i zW401*hd5GeM#lKS4H5`ycX#C%D09@dy4fvwC?w4;B0w~3kecV70Y>43;{nLAFt|Yi zOx0URQuP+{DbLX#&G_m21TF2eAj8`zL5;;tom@X-ekKb8VoShVV_&xH_9 z23-m=F+)-DjRSok;D7_&ug3Rr#?X$*7Ua7=2b@s(L`Dqg%pHf1y*|eB@ZqnxZ#T|o zCHm-nCQ7!8Q&AjTM5+P-YC-LG5s0*Eu03~CqZ0z1$;SCFgyr4^p9$YFaz%|2IK~ga zC;&WEiS7OVfGSHi`I1R$Pim6~r*dChUd@~nk%1WM)d9(6wMlE9=LgHP)M-K3V~Eaa zo~{w>$|>mP0sXQ;ZrUhT*V7b3H1PQqcwze-b*$z9fN5|Bx&%);eO4y@RG0btrT1Jh z39kKyal0p(;j6le-tG&4C}dX_ibkrSsyGhc4jaadvr+3^=M#b~|CPx*5&Aand(uE0QGQD#~X+;3%O zM$J$sMVPuJKd1Geju|`Z3csI1QFtf_lN2g{cfjlMKQ*?;Uu+hW9#b4j!BRzKv?10b zGR~#BqnkF2TU=tXf+0h3>AxOvc;>AGT;o5BMMX-qF(u!5sDfB5o~H+h30ziExJuBu{>R6{8i@zwWBhin zwEN=j(&E&l*e7om)4#4P#1$G4A(m2AI(1aYKPWYxDp7{g96(}?OL*}hc@(&-y@c+a z&GcM}D_zBnf^=1-US>$_#XR+u5?bl(M6ui1`F$R100bC z<;G^BwW)1k^go9x;9IV>1$0@~l^M1y^gHxzDowYkG%-A&-CTb)ti%=Ba6(td)vPR% z{UEp$DE#4%AQ~VFp@VLwRO7(NX>)l_(b)TZ3_tn0u$LGLr|;?HOI4;g7`z!s&TzrXW%u|6y~K&8Ggp-WjukJd@vJj9+6+zduQ z*u;mU4)L=2*|JLZ5Yx4mZ?iJR4mhE5Ly1C}5d*=>j>@YV>@qfE;V-yGPTkxuUSFj= z-d0)&h)4;NafQa^=iid3zLxU}5Q&@?MNKxPzhs^Eb3)mk*K5Q0!V~z+vN}i~nuL#H z4}H1`(GW?j>c2LGDPBV3^EI~8PC?_=Tj8y&&9TK`(Ahcvx5RVNuA%{|z0pdjrv|8% z04P7cQYVL9hyd0k@%OZnN?8H&w)Rb2T*6OUS>KDt=e&7>sM>SG6JOj*GV@=0(c~E= zxvM-rz6D(Jtt#~(5%n(Z4aSKMT>JreTcl4_9DR)Ec;C`KUJCZB&C1S(iD3#H@Gv?Q zSXk672SrsO0S*h=SE<*Zp9q>#t~u{cUs>A0&08O~BctOu5Z(`qBwn%RQA@^lhU~^0 z$dep)@@V+FsHA-3>RLLF<^+J_^UL$~3JflaFKsiq6YoH|-CtHC&3$}L$GpMNJFugh zw))Xv54=scLADr5aN)4m?B`24nOnPKJiT!vRR?b2Au9JLfPEt45>=WA45m}vDe|-x zw1D=R^#P5Ny|zS{#u(v&nslr>9ck?GG8~QsE1#>nj0d4+I5-Jl;RqjdYPuatXN|3; z!rMO0=!WMCwxLG$jOjVs3DC_K9TWVQJ1ttRI}>AgJ-xuLs#@C^rW^pGQ+Vy^GsO}& zjzbc6y9Whf;slaIGT(Y*Z!F@00_ybq0JXacOwlieOQ8-`61#q_C_L7n`ZPgKMDV&Ulg!X9iag@&qESq)5^G4!`eKRPU5o*G$Xz0t%D1CW_BPWBG+NM_|!R;A6BF1VpOd1|bgDzM<65Iw`psKWS z;Qa|1d=j7Ur8mCDOhaYU#6nO6R@I23z^6s3w$%3hyzKpDC=$-~~mZR`_{K)Xu$+4$b~kGgYwCrq&ETsGyC= zvfcDvdH1+xjbQuXQj?+SP4fAIWTeRm5tjD&)?ufE94k7BWi&CZGqh|3ACp?1|Jf##9I z_*p3=Xz5@88qs$08=B3teCr1Lj~K9h`bOW1BYoJa<;U_b4X`2Wp8Jv;a4cp1J{$;8 z=V$R;yJ#LnH`Qle@oEpcPOW85JA+hlAYe4BBk$s;<`EW@4Sy)Cee`LfOcgJ3%72y7 zLYUV`=)yHWkRrCK@W!X}Jyo(h+NDSu?}i~g%;w-D2rKqw_*HuEg-!qBmXUUUq0hE~ z=5nv-6z(>La(*E_&pqeK#4b4k>iw9FXE*5A+JoV!rw;-`feToG52>H_Oh2QC;hb0q zKhx{COkk?Hr}7N>dl#Z;0$W}KTNB@3rvB0&bS|7h&v{sY&FP=u1$EnY9P4GcxLRaQ z3oY&d4~Umu{If6^V%=1c%_;!npO^e`P(m1#E-Ycah!7d|eP=03`9%#7LkG;s571to zzg-u7r^y? z(ThBMFGb1YBJ9KeJf*HrqF6@ud+F||A1hk~`3D3p7WF71LA65m<3B_$%PIWHsK+2p zD{WY>wAU%_fc3F}hx|l3-5Nz|jehwDN!3*V3lo*wSuh!-dRij6*iQ|wo^X7_3v@pb z8ED?f<#&{`2;g>Ky;gg)=A&n+h6S+ljgMzSs!uMHNz z6zteM!z7Pb^0)%ZrnT=|q@3|fb}ocP zrpjwi)B9)Lc?a>H*?MEGYDlbpdiZ-vtPRpKiUz?h%!ihMYtiu1{?EkrAupGh7Mldx zxu5`WMi$>MExRu+E>d1o`#)-o@?zwp7Ak1%5x^JYT-4Un`>IgWL7D?GJS+z`&|+1B zF#IRgm|u81FC!}=F0k_P6Qi*)YsE4bgeiQ=5U4a;p`Aom93;~Y`nqx#^U_<$}oIwzV(tZ%X-&U!Nm=V!1YLy2W4YNmZ6uKRb z<*^$np1@;_(TYN2ROtpVAlicmb3tpVr28DWi^y7P(%7)*RnY*dR&~M*VZ(}H2kEoG zxbe2Eb9w`M46H@y0R{=JcguG;CXg$D!9;dnt}~c40F@N26JSB@EhfnnjoL^6bcW^^vzJtGj64AU$NFIR+|) z049sz_P?BhD1JsGm=;S*@jjNwQc|ownvAN8edyn74I0=%aqmq8`|W^@6Y~n-|!Ud`Ns8! zSV?1n^~ZdNLzfZ}cCYx|X%goE9TPoMxq(;Jx&W(p13gN@S^Sk*cAT#SW|6ar@DedY zg0t91(~6N_@;Rdr781;e{gDR(-?tFwq>Brn$QCwP6W36oSw##6`aPZuRkqDbl`=KE_uxlQfUK$9W0&-Ym`{)M+_;gYQf24E)40 zbG;Z7$2E+PJXb^zlI+mF=pYZ}nV)Z024Z9?{oLR1+OtPe1&;^OMh2toCOSAU%de!CoZ1BG*Hx6MjsO}9OCsJYtIJ6Xq++0BNZH0pWWWV%1T z91_9NQ+J=VV&D4IY{?9z3V)x9$@sqMfrhC~X4gCrn{jFmY*qEFjdz`*t1{+z{pLy> z09}gq%9f{&&iQn18`RdC5Y%Mfg^Y3CC-+OMcRf|OAYr=Cm%!ARKh5`irg(Old|FJF zcQhhj9GFi7=HHHNAxO#PrX=(5Co}Y>rFA;-^K79=fO~!4VOpm)in_!~1VeyW;EF`0 z@xqheInN5%TLnWt z$7`c*9Gfe`T}QXW-hVKPDZ>P$>RNvSb_Yh@Uu1QND~Wnc%@4j^Wgp}?AY{>}+83GJ zJDu1|3;!MW@lwd;cS8pWPReZ&Z}X_aO?DyE2p4KNElSZfK)k(8#r%Lg#DB5`9#VBZ z_lO;;?Hni~H1|R1VJXPsYrGUm!mT8gPQmcdoI{vGv=9tDW$|K@xprSts8YxhynNL= zx5{o+*8n`ep@0!k#7%axr@~8VROnn}sPIOzFWmt@gMXsNxz(SuVHzYOr$;ja`D8j8 z&PmsZKWkR`t<$xFfqD=^(_!1&xiq|8JJaNLrqS*9zY8u*mD5k^9|$7^djWZYK*zo@Aer8^G*ulT1 z?$clsRM+9hg~>ja9lw;n#U#*yiv7(Sl}zFL1H+90?U# znag!m&yV!}{9oj~pYL+YjUiWZqGv3%#&=Di&%+! z%CGkmI;FPQq^OXCq(0QgnB%_PU{11GBhz@Nf~7cmp-A}S(nz{Ww4~8d)kqd}H=4dx zk}P0|hUqz%j+1{w%0K0a|9X3(ra=iGN_SLd&Qg4BSGn=WOEls<-YZam8W|3;^CeFq zVL9?;X@x`wa*F*2KY z`>SHhK8H<3s+Ica9>e5N@RzzI*PXl%7S*Si9f`fY>8=3d8qkesEkQ=D?VP6+-Ql8H z5W3_0x*IntQQ-5PduSKCKbB$S(p<69AQR?0Tzt45Gm@8GAaVqVSpK6T4OguVc~!%g zfx4R~=gnaiMIJ40jj;Xq15~dN23ianxgRDxVNi@?fV+bIbRS9!M(VZm$_0=p?uE_$ zg1jD&L`;Ot?J{L5~e-$m<9YNF{zZ>=B zoQS^D4VSYb33P~8tqQoG`*7t?++0^c5$%KA?!+`FKy4Pj@EM@oh%f1O4GADWgHzsg z0N>ONiWb7rVsLWZu;-^StrL+e7Kt=0Pw6_<9;Bx!_0 zwvNG@S|3{CFVzhS7>uI`NTwkTlB`UoK8-B;mApO?F3Am|Z>HU`ib#Mtt7oS``22~2 z6#>ix8%3{9XtEOq{!5YMy<1ePVq*J5Fu4X}pV2kYiT5!Q>U4DS@hTHr)=KL49U2fDV2g zkU>P`wqpz#eooeyt8kCpBqs0OO___GB&v%E>(IXaGTVvs=FZeHxz{dza-1dNsF|TFPzha zzM4$*T4tpB4$Vos=i6hIhspWVl@caIX>k9_F&#xhvQ(suV_xI)&VXpHjGLWpMr;Sh zH%%7a#sl*|xvrn^*CL|d1?F^k3vrBiGH(Z$lEIyELQ>{szxBhZ>3v!kaw+6OZpJ@Y zIL-dJ4$f;S)n_S^B*P-u$`E8KPWE6)mODhS4-=Xs2m{BKLVU3#PN;Gcd%Tj(odw40 z?|$5|fIdv~1u;jYCjgqo{^}L3cj2!JC1y!aM}k|nk>v>CW2FQi1xds#+-k2x)d_4} zs`ptYL|qH&mqj;hU8VD`QaTqqcN;%4p2*OxW)XY4HO6{)na=iAq4A$8xP8#qvwQd1 zO5|*^gze>HR|3@S9a5l5HwYxlI#=q}EK1fE7Alj`c%9;m$Cc|n;Y#)(cRY-Fzp}*z z5RVELIj6dFPMUO3E5lQfCQ`Rp8I})#KBN*b`$3}LfaB#-5kCBZhszq{32b!W%3F>&EbBkyzV9+a}nRU8^bn=5kJ zVPT3k*+0p{J)6C$GXf=;!AmYxNR+0R08S1AxrS(y7HyN8Em4AiVHYt(Z=Ek%be{a~ zql9{;c^cBe!jH(7GN&sp0mN-zVe=w<%U5MdU>2?mRB^cFuAV~t@qiYV^@o7R#{KIO z6m2rLol+js0SKdm2W{F*td^x|?udr9Ab?%ux#C+I*dRiup!iy@isV6QJ~oe4g}7gqH7@8rPDgq6!3akl5?1-)#7jAN;5Lf%U&$Lb0 zp03RmiDFPSN|}QFS38EiW5}R!IJR42)cU4nA)Sz=E?X~Nv?s%(Q`DY}0bvx?-BTGG z_tKvvl_HtG8KjJO{yVy>KC!fakBk0$Z!1vO#@8A`_|V!SH@*FhXylMe-+fyM zoB+4O_9;bP-BNlHo`EYP;wp9Mdw-k;+uCPLz!BKGuHdP1hi$IzvHtK2_?Pp3FTpZd zjpVUjH&xB+IpsOYvmN^lK3}E=WD>QA(GCh6SihI~r$-mX607xbM!XQ{yGz`o)jsnn z(pua0#i_0db~BZ70{$~$LXowsmElkL3mSzx(WjLnzg`el2RVsK3l(1;)gcSKOecw+ zvI@xFIubhzCl|np9>a=kBOjKUfxL%_-1sRzWm+H!G)#D@oYgGN6@z)kbkL^vPOah0 zh)3ZWe0C(m781oYM1h*1K#hJXFUCcU+4*@`H;%gF?R#aMPS1i_2_Rz(V2!+I+T^B!rO^`yeE>u01RmG+xGy|wWT-42CbUk?Hb@J#YlqWL$HxcvG8?OYAgEmq zBRD7@Fx1nJaf!|j%3-0x&A>LlYMJef@gbLWDZtY_bC3jX4N+5M_vToVDHhFrbqE+A zGm@2c&GgZJTz@mGo8HfU=hzKDWWbj}8kH!dy+{PO%z@ z-Qyr~;hMpnvLI<3xbO8`r02x0Z)IQ~j&=c+w?ke9q-Gju2t?H`ui+B0F7?<{0Np#(UEJ=|h? z?xf)T8|lHv+su$MfhyF3a}i?rJ4-K)nPk20UtCP$?85b5>U6VDWuzA$-&tJb<86oQ zeX1oTjEwAXfG#vAEb#9N?{n!-SQcwu7i|Wo*?t%`k|qimq}P}75X%}Nt@ zCSxSuLH1GvGAZf_Oysa0vFDIn|oQ+UhQ^vQWsxVrYX%axqu40A`(& z*Iv;N4|-V_SH_U8s~=OlR#Tj>U?a=w}qdZa_N(Fn18^$aZZereiT-phcr z+kf>wQ(NhEbz9HNN;igD#c@k6HqKZ0h|5NREs-^4IjrwHy)8tX=GDb<%lrGFNW1p}1Z{iYMq=Pv%0=8sv>aD{s_oD)mp z-i(et=2BX(Th`f$n+y?rN^s(RrKK(+F~HW{pB<-w&9JuO;g~k$D`dX_e{9>e&3W%W25#{Hc{f>W?PemllL@ zCx-Oljc3%!wx&k!-+2AZy*c;tE!^Wzv`VX z-tlez%6@raalF5F>84_Q@#53w{J`y2iC<}d$n*$e#x@%vBtS=RO+=}c(bCb0!mTYsg?T9KDE=d@wY4(bA|oRy z(WRy5X=)!F8WIZVCW6+;)C=gO3Bz-5g>+smERNs0vHIag*V6h18*>RAoKrD}2wKYl z(((Vvj88HmfwP=EYg$`X9_OFSj%BG}R*+Vy8_Xzw*ixu*T^fr9OVUf*T>rq5sL}0= zL>pO6v}}nwahZKSuWsdU6{Hu_X)b+UWaM`SeZM-{=GsS@AyOB-=$c7M>bI0<*9$~L zM3tzug#4p#X;u$$9O~6^k6$%0ShkS2wZ5-fZd;dSX%^z9ASYGWY-QhSYg+3?f8VDk z4~Hk2kdKhZMDq}`c;k3E_J-ZDsAs|s34HsCxw`GSGJ<~dgvUH64d&~MF z4$-xfu%-w`SyVac%|a$-+R*&8A@RYeXkc^F>DQg#ELbXa9~>$zK;z6B&n<|QzZEr- zXp2>c-!Y!I-d%t2=Qhtf72(`WiI3GG>3Pv&!QaI-VPkwPHg=k^H9R=1taZL?j5;T9u;7$%LJ&#e_Y4}*|VxH{?F7=nxTm#pD^5V5l}$mo>hFv#?M2&*k<-E3VUbr~Wxo>3FKm`4w<|Ln=!F z%Hm@WYEot_tOE35=3u#?G_JgDN{-VTNA_NCoSvI4&JTfY`Ecu5kc;^p&dl0`6BvF3}+i;zFl z60^7;R6n6SL1&XPPs-PS&YMiizI}IFatXPRDXB4OWCTVartDu5L4B&Jf4|X4s!@HQ z=eBDWC_uK~J$>mBfdYjU|D|mI(mh4pUQn1%kM4-z?mKzMv4zE0yo>VDJQcaJ0U~RJ-u0~_)N`f0{Gb6&4@p7 z-J?#INIui3l5;gs#G^hbEgQ!QTtsAnnsZCC#5qXY{WkAfoV}cr9Vho|HyzoP5&bKA zQV?>og9%~xN{#F|0ZPmoi#^;4Be5Bz1)B+`p1ygonM;rmJCT&UW=|m`WY4qg0N0WC zQBfEShYK8!=%?^%m1y0ge(lhtcktcvk@J*L+i8^9N!-oIk!g@(U@t}cet=_Pl@V!+ zo~`_wG?tqnQh~Z8`FIL;?zB4yP!C7v9(jOc8NgZCqw8_>Iq^$-s*iJQbnJuqYaf1A z{~%0Kb4=J5ZmH^!RtFl|S$Str87(QE_(N|9G(8|3ynX2Bpnu(%0ru~*h95xA%DA+Z z!i{PZg?x;$xiV$+{FN}-ksIg8*qe6@ErWgVObNK#mGZ*-Xw4w9NS@nO&l0cpT+-{` z=KgjKyByxL#$`av>7=#9`^Pi{u|lPvwQ94R)_L#SN8APbByZT0K+Stu`4-%ag{@Y= zLP+zx{oUfq2|Ds;ATZbQWW&9$0#<4K7D;Jx_GEv$g6Uf!U;LyO7^%RE!q; zsZ~Onp*QiH1xIS|HQ~)iu+_q)dUGT{gT$ueEJQK8P(7DmGdL*FHYA%5e}%c97Xj`S zz!eiFQ_XKONK|#c*C5|Bd+ld!i0*bFyfS-kkYPZxislNK#baP7)| zGQ{Q_I0rAd|1e6ArVxqX#hO+fzaUZQRlEc64%<-)jDnib)u$6< z&O);mjYmC+ioMVq+}>j`{pTr^TsPH2rPAWFzC(DL9kk-ENlTB-2~4I8Y1Ly$H4VT{ z7SF`)&G1MNe&;h?8E*?|ZMTGk+Fj$R`wr-Hwn8|_?HfL^NF8FaO|FbIx17>p&?P+s*kApTO zKv{f?s-yP14sWq|!SanZ#?$JAlEU+K(kuM^2U4#+zMS^f3a>{!T<%Rat+BXW)2_%B+^XjAr0IXzT0gP})&vdK@3v@4k8Y7jv??$Kgkhhm}I> zL;ftCyQB?v90hBkxa3j4B9T$+oAtvbx0}SP$VLCmy`|_TeAAefH3sJ6pXSRMVH`aX z;_-6+r(;dPL!3t}|D`XWgj6MR*5FZp-HgFUm^J7 zpACOicIwqmizyxT0JQo5^;0v+KcAUXuSjJKk!O)EHtFAY0v4qR|Wp#gcZueXy^#WMd4yd;qcV!9-)RsX?`i6n~~%i`b|J$pqF z^0PrE6dB7N=e_6|s4Eo?Jl5j3fIi*$6MV!J(uaMTZ%Isq`C(lEVce5rfBFoWFtMB< z3Z7tEJiiLzKD(vFt`E1Vh8d!acl|iDUjau3fSoW`kaB07XtQ6w0^E8QyJ!z^68*n% z^s~C*Oitl*Ai$RJ2!-&_xh?zWJA~t%z(*gbB_1p>BAfTb@o)&2;qT{)0-4c`N5yj1D0@1BMb{w?CwJ!1Ad^~* zS#B8M2eQV12`;#QxTowGFdR_d?!22yO6Q~(gYJxURix3|h@|y}$)ZTIk>J(O3g@4N zg94z$H=j6(su0R+fpVdNqqh87)t#v`3^rR|XGT%N6aDD#~;RPoY|j04n4m9(E7yR*oXEi+hSih-y0B z7&uKN!>BD2Z=ZTeIM?`bHyVAA6tIq#wFfQmaFH(1hIQXo!v_eRLIp4+p3Lz31o0Xa z2`2zg=mv2jKu7`!*B|eX%@1xd*nSsE71mAtl`E&{W@WYky0W7Co53^;)mrT~wZ;c} z!r{IsIEppR7Xv{*PWxVw(siuGjfaJx(r3nzV=U=!nUz`;Kx(D3H+fYTP*3kE;-Kalh*SaDJHX0+IsVL0tpu%V<#KK754EF`nq?F*CD3W$Mg}RJ9 zo8`o!eY2J7px1Dk%6PVD^B7>A?H@Lsqa}AqkCr>aEz#`pJAK%~KA4!1^;#!c-UqKP z7cE#nW<$bwr9n>3ustP`Gdf)){01|j;HBG*J9Qu=2Ga6as9NbJy++~agF=mE>Pr-( z!U>n~8SR2IZ6}XMzDd#A8HoD46mecEh$>@HE~6zcBT6BBFwh1~b$;ixZ)84!@oAIx zcxwWL6?au~rgXDhKl`t6=oPCm^IQ_U59`Y`eG7hVp9;En@kPw%6==3fjf65*o63*E zu-`J}LCZH^K8CFgh8&d!U7nTy3)K8p`ouRqcVwdwE8yScESfWjV)m&Kc1GX~l zm0E3)N}|ajp|_T%w@BNcie3OBTwk8mSx)h`Jm3Hsl#tEB0WMhIfSO6On8Sn+FlB zSM`jFH+$QKEK93e9V(WZ-Hd)qHwS@P^Q*Okz(gShM{h%G223%YMHKO9M#F7&-czkK zc^O^gbWoIe0PeB}Zcb_r=+xlos@^DPOBg(xERRo%gmiM#$=Yy!sHeR1n7hLi_^jOY zAgHNjUS4jtg>w~zWN+nJ1#x=dzUf3RT3C04bMn_x=eg)vdH7Ft6{C$ae#8y+44j$Xq>x-O%6BV)Ujp{bg z|D+DGrix`TZ)Mte&H3i*+s5|maIugZD&$Ks^{Xp}k{cx27#LS+yZ(!IkBF=5CCy-y zn;j7<-N@Azg~)rUfzQ ztLc@SFtc4nzEC-IcjIdBwOMgnM9YN9T1pCjce&`3hs|cWU)nAlKs#bwrNPHuMGrx(%9Rwurzxr zeO47c3YpY5WXV~(+50~OLF|>u2LJ;S%!CE1PQ4Zq`vJQSB437eus@)j$z2IdZC^%z z-XVB@ATMrUs9`{#hZ~(m!-LC;a?xuaWFSgv(_eMd9h7R@1M9G>guf{AD|Q0#p=D?G zQ8V(z;_iJ?Fu*%YL@o_b5kNFaCA5VD40cMMFOd7|+$TXmvS~84I>-RgPis@=fP~ez zXR6wZ3*o_*7~1fup~l3Fzz*2-3)lJ}CT?0#SXD?MzBc{<&>BS!1~;o;A~g;96bTS= z{LqYPyZCSNlfe<=%MmKv%aeDC(+->zK!VKgCax)>+xU4ki?~Fm>tY-$=?99xP>h0M z8H2sUa3GEMrIFAgpAdFj;)ipMqKGNeu#wmhO@5g{DXgiy_{fE}(s|-dH>?FL|Bd*3 zTb)wunfkyh5WFiih?+F3($~dN`$~b+dxyCh+XgSLCZ~A|^N;y=_Pr zG4BK3ourDFvu@%fj`-UsRLgkL547^ypm&6vUp%ZFhk$0`J%*y%xOQ3_*c}FtEYNjB z282S~Hyy5lmp|huqqcqZ_Ft9bOo9>zFi_AZhxhAIxGr?~!Y&Vj5GF?bFfZxco1`7x zAJD%clj3}9LS}55*d=Ir6Qp_CNA}(CY79p=Z!6ALeEEJ{gN#Wv6H!WVTkEFk6XBnR zoLUF{lU+=Ky!U(f21MqnG)fVQSjff0>B(nr?7fdLx<}?XI|2rA;K!Kq7l@t@8F5nl z^(TwU%V9QxV@XtVd>|%lcE#XpK44{5imc+9%>%_u`NL_%3W1lfdYu9!-Av(o(wudj z>c(HK6BGQ1ZyTx$+FXGQ358Hj(?=B##;}QhsBZNBGzy6cY z>rZV_E5^+$34cKhh|U!#Gt>H&bMwYW#D(o1y_vL>!Ru#8V>EasN%Ld!MiZR*bH7m@ z<$BY#iu)6=H$~CdtaV(1$wj*f>nZMx4B$8hz3eYnq!^bUXk)vZt5W=d$fq$^(=qxC z>gcA()ZW@ZgcgL0vct%igM99@%**`Uq%+$z`xvPtas8j?M=s2UkmWcN_Lgrtx1$;* z4~pl@hA@=l$?f?!CD+2vuI)aV^Kp8-bk6ikoZ z-H(%B4^Ni({4Tj4ZQpsPR~mwZ+|zX3-Nu{vA1H`z26&;d#z(o`2R`9@N$l&A#!0OM zu;K!iui**8K4dpd?hCKa`po-Z^9?nQ{r(mC^f>LuH{>Ilos?AcjiJ9OCv?7j z{;w&DU|pX5FnAicG97$!C}N9nJCk+`g7C~bGCr;O&WqTjZY<%t_mfd?-;i@Z`C`%V z2J@3buoEuUF><;DawSlr`BW)#&R8#q9{LE0(%x#HeA&!dgllJmN3d>I-a$uK|8(E{javiOB^PRM{Y%9& zfL70wDM+d8BBTDdg)Ke`VaFRt%)|29A%L`EyCOt+SY=i9{~59U4~o#*)&O)S0$03( zf?WNAff*%4nek|G7Y9R5UO~}VawkyHPR!UYE-klp#UmJA3~=!dzS-W{P2u3>We8-* zFWgHin_v0;=k)BXXeQ=k--hDP4Bh5+6!pQvvrWLgR9)*Wa<4$IrF_(eT0sdo-Oz%B z(`Y8#j%wc0(<|q@Yd6`-FR!wt@$m4y$?Rl-qOWqoUTe*pl15YNbou!lNReK~$HydQ z{IfNfJJnl!^={)825s*A6EgLS&lzhpChXsDF0{GDS3##b#RoE32j;e5($CgjtR3{M zP35du-2wcQhi{%XJ?jXi7fl(h*tD~c=6#f0>)*0HRg;NT-9T1sy&*oAwXTwS+8+oO zjHW@RZ9Z<)RXdIE1jya}vijz3M)ve-tJ6IL#l|rsRl4n0{TY8cY+iK#&>c?`Ejjw# zwK@2vjX8m&px1wtT5qn9Dvuf(Od%C1 zTTeH5|7R=v(RMc(^X-{m>YUpSb@T~#)eoj`{|rBK)Ga)7tJeF8t=%bVy^52=Co%<9 zZWVHu#qX9rkCS_cyqYBu%##M&7$!&QkSCV?OTsvmP$kXRR*d5uYbr~tH6Cyy49}{a zoUa{yVcsRw&239qMjX7?*{LK_#_^Go{>RpYfF zMqAI;VhV#FhgAiEd@U2ZQjLw1@LTUOJfC}COu6vk3crUrlIj1Lytw*ocR)%_V9lKZ z*X7@q#lXcoq9UjtJ{cnS&qy3rd07+HH%%zC4VuZUM8Mo$%o}rhHuNKyEyw%G<5(p7 z*5>s6`+v0al3xC(z|f>)R&xFq%lBL3>F0#7QY{Gegm{mz_8S>}{xMwisv8h@%D$T!qao3Xc#%Z*j2S!R?shr3eFzdy40 z-uuB*$Ek4d)w_=Y5M%q3&L4-FO;JB56pj>s<%rGusSuby5`K3|ggyB&{Ikh;|3h%t zDSw{i!1+O}W$L6#Xt0C>2|#HtYEd)r%lpft$pfw5h4}8j9N(^p#Iql7Bs=`2nanOgCYf4&r#s~xK&G|+eaWX7$0!WC_~ zX`-bm9T!alBG_z_=^ZbkzMULD-%xLg+D$A$)SL?N4pGO$dh9+P?ncch(Qvcc*`8AR zcT4A|1)WoH2@tWE^8dJ_w!1mpyC;%fs*694JuYm_ca%_giZa;Cjhd;>iT@Z~Y5erD z)0&TFywVZTR*hv-=E&6J9r9)wS}AX@jV8<{Ri|c!tnsIU0CGhg8wSM%(^s%p7z3|N z{L)g2{4yn*$=fWLGgm_ljM~YFQt-u46+fuwCjDQ*?yIqF6sFt2Mt-s|3+q224 z^uorP_#aT?i4DD@jyLk;_wB2o<5_M|GZ8y<0{h(z7AyxCJFuxv4@OAs34eTo4SnL; zX^iz_Fp&BxqgZn}4Z^21nV$c%a)b{GNNgJ`%l)j%dY$Hm#Fj>r)MqI&x)>Z1ii%qq zuxKg~nfWKVd6$!NMkWV0E1==m-ZRuIWYx<#@VuSzY^Rl(uUAz<7gwZ9H#!>Ckd?So zo;%AuTi7x~PqR(23othAUozV!e>dto%D5F#+Hl2teqb4B@VLkzbNLPhg|XtV-G&lg zF{k-DqxV}R&oW>&de1V$b(f#C&Zjx_I|ZU(*DikcMs%p63xhkK#n6YlgE`h zce?WpR2kO6Yt??MM@PQUMShU$cmw~B&+qS#DDGc3llxkne$SGS$ZwAOP&3Kl$nUaHDmMUT|h$u4Ogu5YD z4X&~kEXJ=tGrc$+MWwVPxf*V=t)7l4&a|ZXU%lSsyf__4Q@7${4YzpM&nEPYThnu1 zZwaWJO=417GiwaDMQqPrS!aYw!7^nt~T^Y_gu9gVI=Uu;&-7rJLUn*67~ z+`TwoBv5xY#~K|vvR^Ds7h9@%(MRm;5C;F7C;n4yy_$MGJ@aOE?(O{l%o8iC zABdfu{~$|S#Cc+G|9@0l$Nyb`fBiR4oL^l2{dWaG$T{?yO9vxK=|$`&n#+b`5xfS4 z|IHJLEHdsNCR!@SQ<0hp9Qv)5lNmy0^~8CiYAWYH)s}u+^)zvwIQTG0tn8GaBgwBB zwAap6=w*o9dDUJwUxTSIC^G1%f8Su$=Dzl-qhay6{cysyo1KlzZEo}Rccwa@t#qIxb(gnb33^Enix$yt3WZ)rnlmk0ICFw7x}o{E!*{o3x7@(If6nRF@|cElRbs)%xka*YnlE*9J*snE7t{&Q z>~eOhMlYTv)n`6_Vw-=9F8g}m=Rekq6eWWBCW60y)MzC9q2$^)-aj@XlRQ_tF}3=) zf0s)iZj!x*tGE`26reVTt#EUQxtaPzkP12QA#P_b@Nj4aID~x+CDli3_KcLprQdhu zPT+2;Dn;@(yG;aezfvsHFqNaLNWSwmYc7H3_XsO5FLu2!DF%dPyoy$Dz5PBhED1G~ zCcUCyrek=w7GcsU95I`sYLj_8g^QewjG2Ljb%$p)tB2J&#jrOBKc^WZ{MmDJt8a*c@!qoR^VWkV|8`cL1E zurps%4i@b(mIaPFSNuG%UF!mk$6auRq+|GJW%Z^eZIT9?s{t0*#_wa(`h4k*(cT=7 z`gxoT-O-mm>ta2hpRS|2D8>&@reuf3WTv@f<)OL4EBUA8)_dFS1m?e*9)j@DUV&;9v?R-IS}!A>;k zNjH_Ap;u4W(Ya`I82sq4=}Ko+dWOvRD|9rf|Bl~s_;=pfP1EFc^yDqxXFiP)7+NZA*A+$Pi+ z&kw%^*BBQU2^0j9i^Z^Z=B-)OOc${gwjk8?&O>LtBI**8uy z6`FXw=VDzo*;VZJ27QcBH0JG}soM00se`_!um;pL9Y-ez^8lXdOy7 zBSpi+Ud87sEJ?bKqX;1yyHZdPKH}@&jxcy}dqL@zR|DulP(HbOte#OstdZDr!*PB|rs8iDY_oIEq(J-QpwOHlonsS8gE9?cX#{sgWB$ zGyQl$WNFqp1>4**I>Sy&ZInVX0U-?v=V29E7Z;kY`(2Og_OPk+Ij ziU6)+Th(fk#rs^PxO=-W`iPONc%ciSaXKZH3nfA&!M48J(BO_L7zv|CsZ;ja*nT6f zAvJJ~lo55)_#hA4D)X;bIuP5`$xta83snIf%Zc!jy)f$6ON)e^A_qEa!9rR43=Deaory6mD)UC+)MKm z>}*9TW5d>y?jOxN@q_TYQ4RTNaolz18X$%UC#OV%HFCced6k$5!NCM(QELY?21rS4VcC(0h6P#geV|4AxIc+$kU zy5xJlP9AbBs)JIM`D~M#$MMyz<44w;2JP;!=RV72{I6eM)fpN@t=hI1B2eCPXtGH& zmJvY-<=8Jq8=)%9y~^#Ql*fa_CU;klIWnB@xyq>I`Y+Hq!R#T?>&z!7gZ^s&!R)A@ zU!|B8rZwGZL~}WRLnYwQ#&7f)YpBP1{b~2BZ72&4Nv1F455uoRKzu*9ur5Otlll6e z`RV%k>`SH;0Czhuk$C!u2jJ%ZS#!~kDx9n3J$`o;R(pMR~M=0u)On*~LJ zJ?@H(1xaRg0|ns}1!b=)-9?mk@j4WaF@5X{aOYZT4pkH-O-I+CZs)v=(L?bt^}Fc% zcOU#1!$!aO_lw-M`;h%3AcP)FpuSZM*v^8PPK#mjmfo7fi4Vrb8QZAF{0Dyh-QB?l z%}NX2Lpz5I&HQb7>Yupu@%1l-hZpZ^S(kWyI>Z(4{Q^PJxZd+JYA6c<3GaIpz8-jW zG18?1);<2!cX+V>ZINTZ)nD?Jg}cFQ7#G9i86Kmhak+}&(6_^y&nnoymD4@nl++ZI zpmmia+k}}DuJaLsHBr!L1&}n%;-!B?{2#Cs5_DhN8d$&oTVD26SI9mf{ev#B>h~2$ zO7WH!H~-0|^y@0s_3}{G5pU<+hlkqNm)jJmEmhWr{hJtM#38V2r{O<$g9k0m+DD-p zXovs~rVj&^KLM*OJ-pg=4f|~t(J8Jn9+~f?WQ_CI;*%K96fkv;oMgWDgc&^<8N_xP zi(`qS^o{Q6#QcwWVIvBBQhD!VguAqx=NT?mmNu|t993W`pU0~q36bjJ<-Y{$YGw&2 z$v-6BlZ^2Vs(>kD0&YZ{#;$6_t#x1wOCvV;ppa&$HQoTggX({SX65hH`Nr6gNZv5N z$9ErxrdKG+lsm1^egdTz8Z;2ZSqlARWcF3{*H!tw8H>=3YGzK+#$Q3W_EewOhPNyQ z6aJXT1^{$`86(E)4i@(1wkHDcb>4H52~d04ru{P}{_R-O#HQRfIN?c@q}dig*wfSH zd%Te2pUj}l)D>Fw12^v^FN_6b5UHf4Pq`JLeY>i60Vyr!xc5t7&C&>BEZ&YWRf3Gf zY1XfYH;@YFCZiXbY?1((Kq>2C<=U^mche|Yl3{(H$XY6W*H00`7rWl}xGX}#SX1O8 zLg^~&4u`Ohm9>{X0F8D9v}eIn8R21juuV5W5(7#RfP!(^L@>xhW(124>fyv)T`Rxr z8kGl@?s-cTd?+^zz9q^NsA5sGGQ7!}W+f}drf`*e@k3n^3AVO}NaC}y(-hq$h@Y|n(QvW zf?0A^1d&vwgo5VOhJ(#uBp6`G>^>3PAFSp1z}djTPrj0e}X-iV$jUQ)3aNzEOyO>x8 zAv}0+s6FuE9DJ0AIT*Y0f}lv4+oTu$wFBuZ7T#&jhy+ca`mgXPYb#!FOK<^7fp57D zHw^N(f7i4N)OxU{mblk86Y?~wS9xliyh$r&nz6YP`usl<(&-^0&YA# zlQux+zGzXQew<6goavF(#9FD&{wtT`hpaRfDvI*BVDn)_G`BM~Lhw*-E9f=Fs38~( zT;b2fUUge8X=EZ~z^b?;G1{DOkavZFd*&trSu&b8f800CIzoWFEEP*6FCB3|pfCOm(1Ad{lc%ygSU?R0Y$P}q^(2Hd)c79UYwL{_ z+f>T=(s3&n^{G3kK2}wm(DqyDMY&ABnHAKJ0-TkX%_j)jeEdZINu#lx=`e5AKmYa` zP~Gtt8A+>R{wxtr6hsOE>9OdeF!N4yGMZd1b;WOQyUKk2*iuRc*w(MfJ%Axo3AY|uhp9*U3iU3ZGAlhcI z(sq@U{R3NV`>s)d76lScgYUlA6TZ~elA(glDL!(N9PKP?iH9&DeC*`<0 zycyh`Tf<232(a;5hfRu&neX!TL7O9xA&wtMp(0oyNl!DIUpLo0hRWhfm4%I?gx@*- zwtHZ61wG1R{r-Ubb}%d$9PDW;H4Ddmn9_2&nYCpK&#FO-RLUHKA+v*YSZKGKmuGdf zBx<&+)7cQ1%w3S$8J(W`;ef56>wdxE(OB-L@N9b@NP7V0ID6BfJr&6DrcDvB#KC@f zzFA>FG|A=3Usi}tINEk(n+h7+XW43?9*7EAM^E0)F<1G+?|dtgay`&gsXk_VAF8+x znoI%+LF1~2(gIYjlz13V^INfJ&EO80HNpI{v5=@{Ia(TZ5Vw%QcROU6?RPr&nAeMR z-0paABamNq;{%1S`SV*NFEVOKq?&7FnujUO-V5(o1tUvrpIyb%y?_ZI=5M$sLay68 z-0_Olq^dGK)jo*bZtDDh`<^MN|}g)T09mxyk8>u6Q%ytl{`I}jf^)guouA$sDC zoK@{X1QiJT;WI`8a2XOO^KA7zAq$L!W>Z=8a`fH&4Sun0>2qx*WILlWlwzXlJ^oK~ zt`Hbm1Qo}mM-_QU5<~HJtEmtW4;Fe8F(reYP6z;wl3yML08+5h-FFLJzud;2Ez6C5 zu$--T(|Fdw>&JL~jkcvkZDf(296}tNx(cJA$Z8s+kGDo3)@U!cz>N~++P9Zg7q1$G z#ynK+EQuh;{4({_r(+JM^3&_dOFELwChxwib>%&~5^sY*eiuboCM?lOI9eVrUY$2c z2fyyCuTi}32+y9S!)|_*gFIC=5K8mi+n#pQU2i7n91KIk3Y9;|T7T4Gn6hx!!~v+P zPr?fjA){55CL>#-!skUcC^=h+zYSQK;4XIT$y&hrmCIuwn-9w{M|y_yt<2&S_*W`K zi5`)CheDAs&BCQiNjTR*M9!YoKRW#e6b7;LR~bSKtP0?#A4te<_(31u^%yAG^G1EdPE%pB5wveMMGb*LG%b8kBVUQSeR2O(8n%; zLhdr+KT&&4t6e+j|M#NbeLgGZAc*Y>5-{M*EA~}{$+gAURWe3NMG56wXYv!u>Cu}+ zEb_8jf6zEyWdvr~QlLa90L&J8_n`QNKwrD|&PRS|+rzI1PTfq#wW771Hw+fWzb=@M zTkW(HNq=BBHFtn>jUQ5c^igx`@`d|UjpoxleOxX1JfMx46v0AIsOrB>&OCD2F-kdB z9f1Bd$lt7P$g19=TswLA?1|D77$??zl5tZ?&@pm`oM}N;@wm0k<+X;gv9%JEj6OoR z1VT9YDqdnHk^1sV;)g~5l(5&2s5y9wp~unQvBy*c^raR4vUpVug!%1py({Kysa4cq zy9zZ^@C4?m)(D%f(G&0y2d*Ue5Kl<4r)2X${?Y26e{~0ICv-Sx_lNc}rNI41zbiOX z$vP)ezitS+?s&=reEu+D0?6-{{4}RO(ofo4Ej%L%EQdPLD9v{3iI4%H6f59_dtPRL zFLEYsE9Elj$*{}&d!QsGRe-p7r<0*1C3e6_DMh59 zsd(ZA;Chl89lfxfB4GDF7l2aWzxV)`AQeYZWpfD-h6ww=E&%NaLd#IOB9jOsDWk>& zqs-NWCKnag|3TGThBf*4Vf**J-l)+jj80*oqzI!!)Jc~*8VMcUI64FzAq|d@mJ$#J zafAXAq9TF_j#Lp814Tu7_WeEo7tjCI-tX9P+`F&q`kbc;Av4{gX+ccNVs2UGn4TGg zH9yx%LrrUVduJHHYJGLpZTs}o6|2jwm$IC}^b(Ms50@KQSh??yNhBd~`scl;kFak(D{_9b0Kn;L<;NA@ay*0tjOZzt?%D z_FUH2xhjUF$3!w(G*eU>4p1P5W1*s%K@@|*BoZ368w7te+_)`5blt$Mn_MTay@v3y z-j)>+m15PBBB?+?h+MTQ(d`zDH=cK4HrzdZ&RE6WeD_x({gpX{efCZaN2P9@gtgX5 zeAFYFkVI|pruE)d$LQ7Tk!&&Tqlec}P9m**kE;e>bMxS=DirTVs@%8J=D#zjgg6G8 z)aC+e9#`O%T*(5~vxehS964@cnMwwRSx<@r&C>6eDF9JGWb&sF>4|kzHmsjyNEzgu zZK~RsUSUIxt(4uxnMpZEPK^|W8Pz(%iWJ3< z5yDWU2+@e=Z$_rFub~cSUYu3&3?GU15#11!)x|}buyGlaM_A)bE;(J_Y>4oxj_Tk)&PEWY+?q!-#AAFC21od^ge1_8 z)5lf%i2~3?X*B|?S%6;>y!OJZg&0zVGLo+nsk1Ra%~EeVrUbIei+00c*16oj-QpbI)RVm4;i<`|-tvNpqsP``y9f{y z76Hp+0Wm;~(^qN=$0>b?-;3O=#+ex`Z$%2*Pe17q!gi`t1_nuzSI?ES^%YOOJe?Qj zik){Gy{r|$nGiPAxoR>#4d0r)7_VB!T2Jc62Sbla4Z?Et=J)%Zp+TYjsA64`LNV$(NPwm9n z+~mG^S>L?-S)KCpo^XkRGhRAeb%pZK1JLrNQA*E0_05i4{)u(SV1C6AIpSOVcU5q# z@lfHI-i*U{QPsku-~B==h^JnLe?$K0zAoACd|H+ng1y7jP|twGkjXjL!=sYK4oT4@ zM*{wFJ5I?~;ss}mPf_&|8ul1<3RY%6$f9;mU`TNITj&s_=tu%KEJ<|r4P2dUfr5w- zC$5~qL)h+rNWm*Dq2W@AiaaQk{F4Ms4sV~n*Q5%6Go2HGmEn7ThH_NP-4Q|6Me6Nl zjB5>niE2X#ReGX8sHa^Ie(Y*L0adG=*p89J*6lQN9X>0cop~?(7#PhS9!H93O4Ki* z%s`|Z0cwsd!T2gsJ3hM6JnyLR(E~j*3Pek!fL@tsl8vnDS!ts%3&pt>^}`BV5 z=^&4cVxrW#{0%L=uLiUb6Ws);lqU=Sv^9UX=X}4lLGkTc<6@3)FSflI>2;jBrkdIY zYQnQ^XuwMQy9DP&L#@-6El)DrJ=tKM)G4D-PVY2rdp8|~x%`<#IF7AR0!_mTdeXCc z%FT5u7@0r1zEzAaIL83ALW$XltLfwC9{2N^Kd@4zKn~~xvBBhlMrauNbh6>d0#Wq= zNv%Z66r=EaT;R`63C6d>t6Es^&OneOxg!$Bp48~WPTD1O6_HU}l} zMNGlZOZf52j_jS3Zzpv|?i=Y}4hv+Hb|>Dz5wZL9L;g3*x=<7l3#E z;X6Ak(HrEfIDBT%l**GW=6Vu+R`%nqn>|f%liAdWU@WBxA1P4R`Qi-W+Wf?8M7|&l zz-&hz-{X6%<9Z%__JPbK2IrRNmLMpmHK@p*MR@r9L)+Cu8!4AAu3mabHC_3|0!0JS z(%PB4>nf#WgcSM7J)dL{wcMndqZm?fks`A#`>L%qS!A0tCj8uyg z^o&UbntYHi*3}&?GQ$C#-`-mJy-*RPt7)5>s<~P)-r63ggOKpA&IW3bx3&4a_5+&}!c<74dQ6iJ_vbQ- zVV9T}|Jwz$xWTsdbvRAw+8F_Djx&T^|8tydRyDk$lEk(8BQw^GFL_04|G~SnA)v|$ z#xnp#XJFSRz9XL0cNHd!8@X~`{#Z)SR@C@8Bz~A2>+u6PPA7?dx0ZM@5FO5%&UZ0U z{tMH+$dy$L@TH$>CJ976e7&rpD8c|>$O2xL!ei%M_DM%aL)0Iu3)~*k-Tdgey^6R# zf+dgb!G}NG83++RAR{<_Fn`ZvAU_QE)cPWux=dRzpiTzrcu!3JP@AO7|F%i^S#SYH zka1`i6web`sSA{RarN(ykgJ;Urn#U$BqGeq@57H^-wubnL+l+sW>@zhviV6m#cI0q zN%F&Lgmi*oB;oq5tyh5zup2a+;{WewjL$9maHcQ-F6<+7b?7n7u2=qx7uWA3pvNex zB}7TPny9O)?aa?9Dtqa{yO_(Hhrp>`)57q?=69rRB&LVz)tDBy4}d%bNZmX3U`;UG zLwEF>$s!l1M}X?Jr|V(CocHM(*o=48kODdXV@z8E*|sY$`Cv5p^n9QXub2k|I^x6T zQwOhHsMOgGhc8Ywr)r&L~TC)WYdduH{Snu;?^9QX-#nuJ?4T$FH391w_)x)E1l z1ljzF4!afpK{G9=2q^_beA*TLPKVB?XG^qaFTMwtiy`tjs2UB3Bj#+*Bl++Mhg}}0 znVe7aIWCNZAX$-$-c-Fbj3om&13+ckPcH8&M0%6wJ7U}4n@vCBRt`R5NRza82b+## zWV{3W?qXs!6C3b{;k!7N*Ro#2a*6C%3Tt8VKozWQG>dNH*EEXvGsv#s%r(j5!OL@0 z^XKC)x!~N9KH{w1dqHPrEN`Y^PW=FhczdRT(DVZvy)ZK>HI&B7L|h($fWC5^P}UMS z6R*L}DKE2$Hk}JQ(;o3-ELDtY8!)&&KbK2>goz@!e5QlY5Xc9QG`p3o2zZijZs7Vi zcIA6T{BABF32r_3fihD- zA?hJ;b{D3ME9O%x2JMQOrzd!(&PV;U{x`|kZzj4j7b$gAbG%?t)Qz$XsNk-i2vGWG z5$3vXt|6sY?X{G@p8X~o?Q@}UIIWAXv0qB zyb^4c@8bgJu6Xd;OFY6oJXWz$1zB(sb>2Ju%HYP+V1Szh%HtruVV+Tpu;0ZJHJ2&} z(kjoUCt`DR_fX*t3|O1CtU@TnUJ?@)miKc(H0Dv>UqSpARS?vn87q{ZZ7(NMXz0xH zyFZ)@=4ftS#moeC5)HBU0|?YxIC{CG4$KIE*;w9U=EWv7cu~*Aeuv8b-b2T~NXjZQ zJBUB4A6cUzM7fvZulL&}GO~>9j1d8f_J7ql<()Kgt~C~d$WROx&8pq8Y$?IzRzi(3 zTiQ7~jc*+qEuAZKqpKw~NiOKx?GKd$>GtoEFcSh8rJ~E6e7WU8mlC&bCfYQlD$s;T z!0Isi^9m?Kf*|lP_q~f{LM=l&Ej1r5sw7;hd|j_m6LaN*r5Gb>5ub#$D2i%m`PF{0 zEz|H102$P7PKyTaIq-%cAqNZ&(+{`Y?Q&JVG>p7%aEz{IY zQkT2cG{oDmUcZ4lhCU8Mlp_KxRrTNI69pgvro~b=(dMEEu=6i7*oYUf4r> z#%Pttw7LCkk>?`$goW=pw|7w5^u`7FC8W4l+j{Y?PS3TYnmV66Ln@NNrLEgSSO^Xa zs!?6FXKwQoLoHsQ6!UMnZ`~65Q_GY?{BV?$|LU9~fynl2ydmT=7TxJNLVK90lIGAzwqHSiz4C_-)=(A30 zih*N%CqEw)W{QS6mckHt&>IhtBm(@qFar`G13)E6o+}nE8sp(VoZH{ccD5RW4fp)i zPTY~#<~_c5Ip~CqD=k*{<81`>g4VpIh_k&o`S5PfeG?s!J-+(fLZ|B_;l%FV>G8Y@ zrhGtx1fa_ReG;HZmX^I$d1o@)F9tyy@#Ih30*y!d+Z6F7bRe zkYAi{;SIXGE{?G1e=OUa5>9isOo_&=jCmk88rCDbayByWQRVwCaLs{b@&DUTPa;3zY-)BVx;>3 z^YJNycjl!ph}`YF(*zn*AM)X@|6qLvnB@QlS?x(yGH>Yeunh&?e;TwkpY+U z3Th-#OA7;(ME~J8vvDBmmBF>Iw;+m?bi6JY#{j*bA&vWA{9+mW=hP>Ig@u;^J<(&A zn#a7L+*^{!YR#@UWcj9MNaSb{Hd!+0=3jjDAEl)w zq?qN(P<^w`>1D-u_=Cb{PdMq1som+!fJYJ zGxLY&s@^vetiZ#eCl2$P)lya5LPuAV@^{5qnd+cB6)QsY)e1UVf(9gNrK{@Bi@sj1 zP+c`9Z=7WymS1h?`2(D|Ndb`cDxNdz+@{Opo_*@3pD1Q%&;n!bpW`H&_ub^>AnP&i z@ph*5?#!|f9<&l=o_xOAbFt^gLhg$~`0=-nVCIj$ei?PXcKE~lo5&C0eXGRmx1nw< zM`IwR10RknW8VJw(24g*Av2yGlcD6QWmX@F$O2qBUvgVZ@ex+H*&uv4sp#qEhb}WF zE#Sp7A2`Le%&6;*m$wbza1(sFAbUS2J`g7{*xR1^>>sD|5zHCyozHIIaU5VBd>B!H z;|u?)<~{df;ZI|gaAn~H=mJ0t@Z}OJUrky*$>9|#*z=cp?eOF#vmRT_N8c{o>+B+ng>&AWw+cEZ(3Gjadul~Iuyfo*3l}h{fZtwfw zLPzHfsH2Ut7@evZ!n6t`xjTiY$!vYQn(5E#u42VC-)&Vb)X@-H6#GRA}IwtBu9*>aLjTPTXPMmqDn_E#f$#Y( z{O8yE{+WN$b|5As$QC(^D>m@5T;hfkOdI=k{NkcQi~RRbq$ze3bF-Z&CM%Yn{QptA zuz7&%|FhXHWJau7y0L0}+)hX?E-0$KT}Ab_8AQd3=~G~Cwg;4$LWQ(+Hnwyzrcq&Z z^2uY_|2EstXXajwGdJ7g&)L{{Bwh11|2r(ROr0AMJHsw1(ZZBE{BN`UTSy!yVNL}p zTr!rMI9-Jw39wq`W?M(i0b9V_Y#$!8hY&C+S&A*ODBWOsan|D3QaZH}vl+ zZ_6Wb?@_(TT*NI*hJ;Bf>$rF*3JbNkV1=T)B{N6cRhfVrCDTqpxzlei)m->h>x-f6 ziM87EJsg%I>*5Z|MyW^j*j;;HwO!U{)&TaCA|HXB*ucYy)D_m$1fbes8 zI36h`(Fr*$2I;!sio&gT{19hLE%G(=X}6KuZpSGIDjltYWyKOf1Gsn_d65sd-ov3M zh{1>{yILdQdaU!0e%9U#X>rLH_t@Vt-kN2-o*_J#z(RV6jkMZzbN}@98#-7dqf8>Q zKKXh9&xxSkfjC2+ziP{ePY=1+IUPjYASi8EE(L*lzV{S7hG#4!(K0lK0Rk&0E6c<0 zyF;92ti;8D9wuZzofkzAJ{o5W!${*&D9cf2VdtDUw~M`|G`^An$BX3$Mer!?{`sdI zh?b%hq}KcT@f?i$Dhz#oN!BY4z2_r+RV$L12O^$_@%yyt?&F}eBlHzk2%bQ(^1rNQ zlyPO*zAW&89Ts{SiW5(OCe@mQ8T{d zA|yKZh3a~cv-}x80j1UAh>gvf)ZA!FvHP%equn_fDu$#GjO)Ww$P^5F<_ASzg)X(K zOE6X(7^q3|^n2#4-i7GzTNf0QvR!b>gh2H`Il#j5uUZ++4+m)G z5pQx|loz4p$&rRQ7&6#obbs*nT_x#1yO{KzN7TjgJ4^NxV3yCyK8$)|I@010dLf)v zbtn>;h|W4YgB06f{27lZFpt}l5&428h;h$mMx58DFqqaJ+xud(iB@Zb#eS8qJ@13c zbTCV`0ejW#Iz9PmDoUbDqVUa=9|z$VCpK-*|A<}|S|@FSPOcp( ztg*W|kruj&MJ9wxgcI@&DTEyqkP~@xF$g-)u`QQ)?f&tX=2%v@vzqm$1zt$myF@JFv*k96(th* zj8>B#pvHU((V$!q9DP|O1^7Tf zid<1XzqR~~DqBOMWYKuv-A8PASL~o!gFH1a`7=cA(2Cf4us1CvF;*a>Jr2x_sSa0c zCqK&rsuVC!;|e$sp3UzJey`>#?fS#Hu+kPrB#6}C5Q-%OV!)z;AaH@Ym`<>81 zD3aV@ON(^M=Ss*DG#NUoD+%P6v_l400}rnhg_!q>c4?hVrm>PpdAYL?*e2Ng>!5Kg z^mbw3!xKlhM26Fj?uV)5cT95lI-cs6yWW1*1dGbSCuC{x@r~U+4cDrDv+;U^I+DCY zZZ|;(Zm?c+l4}b4=+KNCbP&65O|V?iOkC1N09Of%5gbtUUawkPYKb50xuWBbp*yj` zUsUvo{f$_2J4ew>Fwl1Q0&k5EL|&`7yG0sJ_|+?+&Yi&f2XAn6t|xv`GU)O*Z-{H= zPYIEBhy2j{D}O@ghZTQcht~<&KwU|(MJH>~=KgE2H#6>74dC3z`a}(zuF3rdkHku* zl#1BwEL!I@by)_&0mH#{79mgN4t?u(EJ#c)i>O6BVw2T-8;~e&zo9i#VF1wC?Rw5e zs&mN+k{2$X?^Io9_h0*}{Zb6wODT0yP3WmCZbU~yI1{mnEc4MRiY-=xM{&L^St}Sk z#o#Hf9y5Mg`PmY;xgvI|sykk#Q8^kPohb*k7=H4+c#d2rK4+6nHioUOyna}FegZd( znf^t4azZ6M0kV`dTl-ik(S7zZ(>$+UwkEPxy0d*$=FeL*jqg>zDtr?nILoxtHSS#u zHIg08#tJNlH7QqD`h#@)Os2<-KRx6OiKl>$e0EQO8(9G~W8~nlLT$w|NV)TLr79xILC?*A4yY!Q^rF zy&umBf44vU$jjCB>EHO04xi2SFNJ#xJ{2W_)5PiCqC4;Y1ThT^D_=GQKzL;UI$iO> zm)zo!G_RTIl%$Vn1pWoAm4-MHfMb^@s=uo^oXzES`_5458$ZXs`TqK5l>wmhDdOqB zjW@f1TzmNLk#>PvvqRU#F$ZJ!k+NHo6w-qU-V@z;b51Heq#YC{%bQWp@BDU7j=@;gGYj}2-rnDf=r=+ zLzF(vc!rNZ!z_NC-`}fC_f1iPVX-PF&h3a6M2rA_MPiZ(Ui&_Yf`tNgY6uye(L{HY zikvgDm-((uG1xz?@H5V{KB*gFRAUw&$sMO5mmH9;It_*1TR+0H3r67*i|DAczKN}0 zjk=yk+14xWeM?NYhX?~m_5GA?o>Xn$)Rna0Ot@+KeCp0o z4OgE;96B@M^)lEi7sJdG_7iJ@C}b+hKmBs1T(q}&YBhiA2UYL9;%lkZic}divjDIo zTs^2l2^6ONdKIYmNW%4%3#B;4L>+-@fVK)`M6AcTqY^wKf<4kSmyEOTzmJNM1b4n9 zlnA8l)kj+RWR1NFRFn{n7w{Hd&r&2HPy)yo#R(nh*`7ajAm4J{?q5IHg>e(07y>wF za5cObecCbWCMvTm68q_Wc1jp9X-d9G0#T81Khv*krDu~0p&KAoVu54N4mOvI+#C~N z`H;buL5K@=uDAjJw{K?vK%Mh4MZUrvNO60;xgt^FKJ!T{!Iqaa^MDfQyI_cAyJ? z+Dx=Jm0C`UEw(QTm%m_OB4|I(5tl&;nL&gQi&O7`VO03y-JqZ31c4VZF@hz5`>^L# zqSVxqvUciLZ%&n#jw|EXzddLiP}o>fnkoR^$#DERa~ZLFEW%dLj8@#W5Z`kNl}<>0 zAfR}yy`)?)<Bdz>Ya8^nY}vhEpoX-t_yg?E80%l_?eJ6oWEZ z@Zgg4k9W=hrjp|lT8pGv)8&f5Bf_Yas0Jh-4wwJ)^i-53XK9Lrv}yUB>cB{j^q~m! zT~D$`$s+Zp(E>*MafQw;n+H)@CpT>PWcjP^xihtvo|IC-Mrces=EB@*b{SLUpYB?X zHLRtYF(H0N#iClTuiU5!Qt+-lpHTacrkYakq|j&+il!m<&{zV;>@U0eP`DQv;mH8~ z+TqQV^8xs9Ph;FOg#AxSG*-xYdOqNUrQZF-YXRx}2-+dS1JA|ftk1ohDZK}Ce8y(G zE1l#S`S%y{(5V`e^jT-J(%_gAq`$Sey)sfCuulaPD{Xri-3$jy? zqSa?Je1c`fyMIS_JGelhZb){9?*+v>8a;wu6pA#VM@ty=!DaV2^ZWndy)xlSk-NL{ zyY_5GVtihaZ)$?u`@23xz!$l0yHmaP{=Izd01LHu{Z4OwF_fF0|Gc-IRS^tq2Wx#( zCUWmx7`(myB4%$G8PY7k>2r63X~%^CxRs7AKkw}E;H`6YPUhXMf9`XVN;*%0nZh>6k9-CV&&$aJ5+O`*?9= zKL6`KiMJOY$h+9$DUi-SK#tLQUf4!2^YZbqN<8R)}r{F&o zZ~hJ~*@fN@Td1#~N^_C#Oh%0uKQ)z&AyFF4QF1kFI%m7guAYVH&2sg&l z&i?&55crWzF3a)3D>avyu`2qb>)VeaCt{BW)NGE5+xqwVZYQE+VY*hm2@4pf8KeZ^ zNo^J+W1C|-=}Dz*g;05A*e-#GIFU*@V#~BUFc6EbMkc{9MPi`6#N=>n*LDNC(~fH+ zCeuVsh$Wy`jWD?EtdI6SJrxctm9;3Z#He9M=B=KDD77CvijNcrulpAZl90N@iR+0I zv()Ky2EsS8@ZuvuMKaL+LhQihDK%Du&LnCo(B1C~?$vZEk|5kxqhh5-E*j>yu~UwJ z#%okTHS$!=!Qsq&e|OJp%l2JO<~UclLiwxPk@u5qtU+uaTe1Vl_p@Tmg391Z{bH2C z=ld(qt0jlI>E#A=LBe@v9SRR8fI3St@G+<$!-(KP`r!up7FVEb03Gyux z*{&aDo5FE0>U16MCb=~Pm+r_UH-~m|~NE0_97=QPCUkTETzuaCI&Tj<6j~-&2 z+565b_sL&2N?07IcHOK~9)v8dPJLOmCJMqCa^6&^2?OGWSN4nl=oioXt>*)4+>{(O zTusexpdN@}Y75(uUU)={AU}fm-uO)Pg22Udiv!M+>(|*oa0h9$-9UGCdsWmX84&#U zew3HLXm^f(j=|4=i^DDa$+{W8_2uuz#Sq{)Fvmh8;&+cFJz^q_C>f9{zc4u4(UI1; z8};iiZj%iDu6pSMZO9Aj3&l(CgNzc2A?(vT4T(FKYjz4KDsfdr-I_bWvLTt_uvY(G zCoJ&!?}nqJE#K~^-G9r2*`i<&%tLt)q+(DJf<1HJ?){*}-?Fb9Ms~6tJ`3G;F$;-U z;kJ6!a6RM9$k7n^%YhETwl9$lJM#B9YltMd86={fo)Yssj=1%(;>GWor$>kNrA5Cz zJo?Jey&l6@tm!}MLT-C9DSp}2<^3_lHgwQmrSA;+yP_#Sm$}iAg>>Htr&jjybF-{kOBVRADeiBmszPkx(l)2q#y)$}mI;Cwyk z{utU~Kik{ODyE(b-xti|xjxHVOpozD`@)=W3qSo*)2C9>)|nauXk6O5`Sg?Lq6#_S z_va&9WZ~Wy`tw)y7iHO3BMSc9iCCX>GG=S;Uk+C|bLQaDTek)%z?*Y;C*aNF{9GfG z&j-h@`0a6nio0L0a-dlLN7+b~Lo*ZGECd%PUM`JE*+{g{E-foPtACSrv%ID@`z$w? z8K(<#bo)PS7l7@-Uj2V58+RYyY10yIr2eO5cuJl5Ps@ObWeG1@k~@PwktxLAV5Z3F zq{ia9^eK(U^p=n|k_!ob{+-6Ydh767r7mbr&PPDaa?HmPA&|~A4*w+y)Bh+Ne8&Wm z7#ND8qgKxh(Z?+@18Tj@p~P+$@q@&8daRu4_Dcam$<$x?6_kA(5=N`5$3U%15s?Xj*g;7Rgy z?EP$)j3N3tB(LZSwCJ-mPiTe01(6w7sdjtGi1PXF&W%=~?671wFu^Ni=GhjF|&aVY;tA2)L3X(|7o-AhpP86t|x_M!{ z`J01}zSubmByyJ~vHjKR(KkRtuj7GiMYF;1bruAn7^_sg8(}H;kMHf-%nL)l@=CAD zJ-NJ0mJ(23J2}n7nD2!g9{V%-aX)unoBoa?WAS4;m%u zXvjXho@`ye5Y`sSL*TnunkHn2A>6gmp2 zmfNKy!&(+h5iIV7vC9T$sD*6n@uV>ZFxcbzu;~`uwGK-F{1X}rks$5TAg@!v_9Ul_ z02VSoGS&Q>TjGv$Q{SaD?B~F;oTVQN2w=%aH#Ab)EA%A{G3#3bo=3&sd4|#%VIkG$`vht)YsHQ+n7D7tk7rnv9&+CJ2!QC zS4LdCtiB#7o((X@(ky}bmkJ?*yO-tV&$B1e^y<1kNeSO4NWTBl`20M>pUu;XL^YCK zmiCS>i)3!vxrMUVRfvB+-o!+>u^gnBAY>>-W2W9Gw{8Vo4l=xmVBvyQyfN}Z?hbMi zurQN!YN&QP*Vg_wSVe=OqmClmTY}agcAu)pO$9NfVTONAd{Ptws#YS&a45qxF5sB( z>$!#=v8*I5eIS8DCp-b$6_||McmCAhV=M%o;pH}e-dbmFa&m)m79)TDlT;lb%F6T% zj5WYl>Ai-k_Hc*jp>BtNHg=d_ePc1a|!a?*yN>N zZ%69))h}`xx-Q11f;h6ItWi{gc)U_UbBQ!cvmw)Nv-!q>gjp)g$hdt01LLMAvV?pP zfqu!mI?#o|r)WFi@S5RFge{Z z(P`QwnO<2ZVs`Sl`lL*rEF>Yz{gMbx>|Z-aZpNg6AxEA_eE74QhgKJ~n$?KG?D;kC z*GCKp#2J_tj|%h1Zy?-G_*!0@kr^IkY9`= zfojh*lg#BKj#`@3_4|#W_em_S#{;SdiswCfUp64A{@RDUPG^pD!fMZZYl}t$EGVwZ zNWiMTfyen(q|#k9Rnq8Rz4LT&cX!HHIdfeyaNWSp-ipn@;hoSEu^Dcz7td3@&*qn! zFie}*Gj9bwL|{3WhoLFbisn_#N*`pBIJ8Y#+g3+rdxP(qYEwjy9oAuzct*VY+3CZV zH@PQbtZ>Nfzi9{&1rT1_bI-Kq%Fy;TUQUu3I@VU9q8z}wH<;(3-WSoNT3&% zkI%@!x^vk$>(o>7JO@SFoWZl^vWn7r(qQmc13qh__c5s8)U05qnG!DHwel}+q&mGE z{Fbz2+c?N+gKlai!v(SiA$Zc>1ba4Ds6oxdg~FFIdy9vnb6-piJp|^cAyJpC&c5qT z%{PEm{=Q`XE@GB~77XG{_rKI|%|yoE#*)!Rz&9U{^@QHWwlNZ%N&9)}>OVTtSQ7wh zYqg9h%21ar@J4EYtL%8sxILCl`0Y-Z_NmQ$ei;t~G&6Nw&Gig? zbUk~!sdp7qG56UW(lTjHwCKSdn%P=ZV&Mgh4mP7h}Ta+z^*7=mNhQB2oS$3wf&;gc1?t@nx z`WGKvKS=}_2Jfl=6r+oQQ=HlFIu$r1VO?(l@m-pfuH#?~{t)yW4E;%juoS~5?J)=j$OOhDa$V(_=e_h& zgc*(6+>${M6m1=nd(WL(s}5h#L@4t~E{~#Qllr zhQ^VSv>cVD? z#Y5skA$tfRR+x;q`W}6A_aqIM>gkvY4NmnP3xTa+@C2yCE=Gc?T2*s}$-S`Q^->jQ z@;WdLI6pa5iVP6#NshTY$I1;PWojWh_R`-P!SwOi0`*i)^9+uvq@o7=pnxEj3PG=c zJ2UKZGuke@+AXHqDx8Nh)K&KT4wAuAKDT>OOjkmfCej6)d8HbmLrWJXAh-YsStG4q z0F$)~<;G_WrDuJx&%%TpEg54jzu@NQPLh6_377I zNKnBG@`o(?f`vsLf+b^c2Ws3TN#b=bcP3CPrS!#I4+_^PsQHSX|uA+h!bs2KT+%YKvLUz3Tt(UO3 zG{lU$2#Q5I%D04%&&qsEREs#L1DQu%3BMtbS^oB?j4L*>gOu>K`{u!=()x^2Q40G$ z`LGb5SMZJKC*p1(05d}tk>`(V;z`GRYygw?niCi}kzPaCf*2~)+TyU+NU)o9#7=RQ z0GhsYAE?KE4ITTq=8vu-m>gFz{sJ?=!L5lfpWzxJ8N#+( zM;5BT@*50wt|$KnWr_8&)cUaBpy3t*?qhaJ;Y5FNZYBWX#6f?cIrqmKYA)T<waaH^??q-}1Vt^>P2Tb z|BCx&;AjH1?V(Fjg&L)|l1%Iyp+Y>&Oy$~#>R)^cFA;1&5%fefq`vg9sl)m9T=eZW zon}*=cpU18@+{6KnwR3PJM*hqSDNGWll(yZ@MCd!i;4_^P9$LkkCCX^44frw*makam;AZ`GpJe{|TZj$)!uwCpNOB1qH30mv&_o?dNQu{wUpDz?Y}S~Y$qIf7qtXm`0aONGx3D;gK4zQl-9FuZT>7vATne+K+5ebBT8#3XpR?8+bX^qhJ#a;dKe zIdf&R3aEEP!MBcG$6b=6gHepfQCmZp?S@sw$BMPr1rR~5IH(hzttgQVFOIS^0omz8 zd;Xowok+_sj4mCihDW&kU_A(jMIJn9e>3{G&e!=lQXb2#pM_q?h)q=0V*fIJ^bH`= zewxyUqqZ2XSn6U&p=y-JPw_f3mYY>A=q<8C%f?qK>Vrz8XB91CHm=)XPHx*jvBFEN<+1t(8at$BWBny9c9 z0AgmOK?dx#Rr{L*(1akZYR1<&aw|Z|*FQ+R=nh}})|gii4|!-$ z5t0_94^K1lC&f0jm?)7C-P}(_K;9+Q#WzjmA3d)adNjgJV#QhTtG9lcJ^!q3-%WiU z`FrR z8Vq~@m>`_ubA5yIKwfo8#nM6gcAIiJa#%N@Y%Wpg#L_P{`u>P;x>#m^-E+|?_(&G9|(LeEd)KHIWnd%flElFp?1?_bNpJ}2?v5;^11+{)4p-&tK~OFBbKF+y*=wO-;b2yXs}e|LHnxn1|h zzk}UC$}@qz_~q(nqRrZj=ea7(xn@SD71&VGB{r}&lh&n=c#WO96SD*O% zeUl^1A;%d1=kLZ;#72bPk@eG$zjnWCoqFVU;W4|1JhK8g7w|rf0-17kbpT3Bdf&;? z9~=rU=f~sXD^39fFmmg)B`|#Tb}ODBX5$6&XKn7#ks561n|h!;19vzMud2|$`)BL% z-@|vc6)RhRhwS1FZQaI`^z5u6v-?)Fm~@}`4XMYU%%{-cL$=L*`47_rN;98Cn9KRu z=(SKi2FG*c51Q{trAffwBTS->;Ypom3?X^Kr;%^(mzNq2AAH*W_pX&TWsvh}NPr+g z9jRH9vJRQRo#b}U^KzN;+BipISF30xd|W=ibHw5e<~k>2dV493j=gxjU{dOU|0EFs z6?e~`s#1}oBjsr?(>A}npu)|$zW(~QCQE?K#v6(*Kb3Dgj?v31Zml0&`cyK;S&-Mk z_QMGMV5TrhyWB&@w_2t#*sm%~9^PXjJ1v66L!7dne!KA9>h1Rnxj*s-H;_t`wr>w( zubOS)T)tEX2ReOLs2LJ^s-$|m&m{Er1 z>k{+x;=hg0^KRCv$wluhuY8xH!M3yi>LGv4o#lM6_2AL!<bybCKovcJ5|E~ijywE#f6?|wExFNJ}a0s!&0Gw**@On>ZHt{#>p;pym!n% zbmIT8_ugGi{NcOqq>(}ky$YdMCG;wUCPjqMi-4g?$4~_X4823B(uB~ffOHVQh9*T+ z#6lAdMFcAfC}LsfxA%Dk=by9IIVZ1RR@Tg{`P|R_TvzTt13DM^xq~8tb3x`0{-Ehu z<=>&vd5-6^_bd4FJs+*~(z(bjbs;*p_KlM331=+rwUX)}@EB=YJEt1ENe6K&&07wc z#8Eqb*uQ=`WZ_Yd#q&H;Tgg|u;S3JeNeQG!w@&OY^Ss0BM$V6t<<4j640G5|Q4Ft% zotA{YSs-v~TrZukjSMtMb>umb9~t=U*w7ZaNp$fDSfM71eY}2e=$pgv-B9bKpM(4F z7vTD$38N!Ndb3lCU$x{%e!l=@)m|Xl9%s}f4sS?{`{_$G;A3^!P3O}M)iRwJ zTz7XLWty>+J<3wkYW1Z=F#A_-$`l(g^U8i`X{eBGS8HjiXm%|6kDt4!_lNn#uthf1)y@%fpVqFK&9t_f zaRx8XmZ?t8z@8VKg;lz^U!DyLH!jGX?RuGZ<6?+FF0EC8C1UfA`SUEf&X|G%J63l_ z>)tPhpGO2jazjFiOKn32H?C>l{BZf~gL}k8Bvp#IxJ5n76|_HAVV;yRyxO!yDnqkg zU!KHxsn4kjRvBJvkBAH+Pl|li{w{*F#a?q9UvBTo!VG*m*Db>;YH2LBb+At*o(i>x zKk9dxfAm1*TF2Vsbl!NCMJ}tt?0NCBLq^z#D5hp#O)F+4f7Wb6P`JyW>=ylX|9N1> z{%1$|xU!sh&cZY9$KThq@{=g_Sd&Sag$I7WIlba6`$ga8G=sZdj-o>b9b;(8$2kCj zFKR19uT#as@3-iQ#q%7mMkCdbCz@~b+po?l7iE9paw#`Eypzbl&*{#<*YQO=>`|H$ ztHnWp+zDLS{z>9hD*sn3)qMl5cbgO{ zw6)gBY@uw((d3|;rPziH<*#>(o=71vO&Cx3`(a6s-C-k3O4{pv1)R-P!z=f$VKww} z^q2uZdv?r=`eh6OKFpP2s}xwzQEXDWr#J;#sT4yqYfi`~;0ijnymUlO^taDXNwNsm zd@e0Bny2iSbd7F1<9&KFB_+{Lygi$NypFP)!qtC&}Gm#38Zua18Q!34AmM+KDsnV=#LcB-ifvIxnUF-b+6V_~rR=hNUj-$XWHZDA#)x@~nLLJ=My~ zE7G?cY7r%8BOlE{`tEE6a))2^AH2N47L;B~y1Y2SZSrPrv$c-1+jbmU_Vh>WkNYNE z=r1Iw>+emw+JJQnz47|tk(0r8{O#7;3BMK~Pk-o%
w6RrP zj}oR(Wn^D(4A@{e7-jCJKDD-nw=9nx`F+b~Wn$)gy8NH{eywB3Y0wqU)1>JiN42bp zuiuROg z|NVUYHR1Q~w*c!96>hnoB=CoZuo@cYd9t6T{bvK6KQt+2`7P`6pH1GULl4!Te9OD> zXA8qRJY!<{y|7YeB@qBbenF8C;3goC0`%x#poRaxt>ORkwg$cb+qQ7| zi>9lvs=75O`&pF<7&6#v&g2;xfb;p8Dnq^IZ(G|JRJjy+)DB3Va)fdTD73DT)vqgw zwHBN^e=Cju9GBLCv)zAbJ11x0L-m&BN#8%*e#IfXtq0{&7;qqpyvP@C%&XK2RaU)O z?J9XnaY`&VO3+{FrhVi%o~~KzCi2*%su|Zu{4_;q8{X%XFm1*4_NIEM^yt z^*+ zdudW9$`B^KAO~4T}^t?$k8kfQjv9NCXP%6RPM~ot+Fr)x2TJ%!*5zUP3M-&dzDGnXL#O7S}yV zvB@jpMen^9ZvAK#1e%0_=Lan9`m8SzW{BQ_N& z+$R^~hd!&(NOvxXu{WEPpCI7zO|n_!GJTAV)hW_IB$ty@ATv&|&zm^0l!|l+i$>@ST$m|r9C?#2aS+{R0f#`CH8yZUQ#QL-dg3%IFIo*aaGt$6 zoR_qI;jfRJ=^!(LJ!B*&N4ryWL(3p({Nuo*;L#T>Y5}Ku1u@gReZRlR6m_{mEkJ|+ z8zRP(92h1htN!QCqg32$>f}M`-p6xip4PKNF)J7CQ@O4zmg<47eKeX)lh2u%%a{J7 zB4N%^rzEnKK$)D+JAsq*bh`?Bb=;J}RD>n;d}cWFk$TveS^fN>i2arIFVxpN9_phH z9imO|K3qMU(X#%}T4~-+?(YCbDsG{({zY2+-FD2H_^<8aH7GzA$6fxl^CWS8Y*kp} zcJw3JY@xwPj%3YiJ(B&M&v2d7LOpSu-1p9onWvo7+G|qyB5bM?e(ulyP|Q=;^gz1HZDrenhZHmmjTOPfC{vx$$7F!sKw8`s@A|u>kFwFPIC|P?<51 zj12*z?#B}+-F1^$@G@jve6-KHi}dMU^>3OgxB`cP{0H7(@ZF`Je6t7!RS{5J7m`>t z@*|ZRYLA1;6r!l-GMIvJLKLatT!5G~8omnSbJS}>e9LnBRP`R$YzR&Ol4rAAxiy!@ z9>_n+G6=GRd~c@8B8d^S)!Q7r(=f%nZ+X!jqJT6d^@BA!i}0FXNXBIH_g{#Vv)~$B zD0SeU29V`m<;?I`amJj59nb&(ls7gJ;sl(+c5a9Xa;f!liz?<$_trcqEir*hCqi@> z-wD_5>e#M6D;#R5y%0@KQWPY>6wxG94>jE)jlIw^5XT@l%h~h7FeYZwwMIzuqKy`{ zxOu)&Z7kjFTm}y0tdWF*QUNfU1TxhiF%6LuADt;mYUpF=e0ZYGDa|3GJgX}CaGBBcU#osm=BBP?KxMt zPv55$OS0t1N4DC@IX<}LzJV|~MUNW@R6OsDiUipINAy5~JaYTeupcLj)X%buL5LTi zqc>SzX3ey&mV}p0CL&I-wp`1_?e5G$mRE>SVGA6zTt$v&CT%=dwl~j_)0CkaiIz72 z9QlKVk%9|P?!}h2X^=<=c_M)HE2&MobjOm90u~m;z>0%5J%xW^r^neT6LMSHl-5V* z6DR|p1w4dIyCuRq9S+`HUw^2U z5^CIv>hhmX!!5UPJn=CkpcBOqB;@z??zHQ&AYm$SS84Q9WaN7iuLF_4=~!usMZMJiWne@1?`dcLOl(DNts(wi?PPOm+A)bX?7pE)We ze0_i$niLH@4(g5vanWtRS9O&+py+ig$IB<8F&uiyGYFZBFV zJ{L+(LLdMTSJ@aF`t~lfb_9@mo0RaAsnANC|ItHO(4!-t`v*e&%!nkknX?%Rfw$-j+CGYaO7XQ6svi71(-u5TYTO6-pVfR`?A~9nI+(A?zL5$R_ z41`hB=K+yp+z1zJtTWAHWTqciW$i<3vw*kRUQ;LOt+RrJ)I;Wne@V+PjXaTC1i=2cRHk-VtZn-iN$`RvR7Dtp(S zu7{kqox^*-=Xket>CI8M_P=kZXIytp7m~QQ0R{|^w3a@)d%@Omd8;Ji?$poy-J!_2 z=&9FlpPgCx7oujN-{CnU9r53x{=XkXPwy}D)r2W}N~d+b*6wrfj76lC8cmLd03Xol{YOcnzt^ZK!uk6p%y&;cKSzdBUZDdsE=Y)@kN2tFr1m{ha`K2Q(#YXYlKfa|^-w;Hwo z`JP5!WhZ^5dNy;$Hf{md)0eIfTG{<1!Mt&tMp03QiHC*P8SM;vY&j0oa8)OcTRxterluoJtRS`<5$fjL zgQ3-4x=Z#jpNz0C;|8jRM*R9dt$jKUWeHJ`Fq7USN5f1>DF$@CZn0yGAsNCz0C3ow zb<$ZSaM!KEw8LAr7W-iE{zYXhK#+ilUDa_Vq|1gy#QZe)O;y!bi4Wa|UVwY4L$&A$ zusv2Q;n4W(_WA6Yj8-Gv{&4NjQZXZgH};p5zAQyko6|H^(;9~|MVdbZ~r zIQaHC!uJ$*DN`|9T%(Qtl;(ZA>S84O36x%Y*?Cy5_*U?0iF!_6nlFoy1^_J%t8H0T(e)Yt51^zYIer>)iQ7G}6 zBMs90D)q8-lBg3DhKCyY7faZ}Gy$lpREgb6!E}A>gA#bSsp)Xb^-Tt)%aD}ySGa%! z?SEuY*sXj8mCH)?(Kk7x9FvKMs}@iCMKInhlA7^s_5&0`0UBF*a!!i3fNeCbax zf)*|c7%D(-pTdC8Mn?NXiL(%;P*uCSS=?tN2>R}l3<1PJ0a|1TiKaPjoW}2BGF~g! zj<#I7+5^+YUH#!)1L+2PKTM!3BI ztZ%#Rv92NmWStE-E6k*6pvzd0Bo;z0he;F7d)|}Q9WT8)xbo3idHtx`<|P_MgUA9D zxq$H2DCif7axS{&0uA8;p!BLSJR(L4Fk&fynw|wwRJYRI( zZ6zVfiG4K6G>>fMqe|Oq6iN?v|mUBKAIQcb>$$Lt_~*=~uKF9V4@?Q4%}#do;mdp7zf&o4ecg}c3|6wanQWGI6~N_L9ZEn zivkk=^K7Nhc%A7U04#9X{`88b1i+2W29n8q5>fZ+t2qrhk}~R9!}XhnYtN>deTD_! zT@7NwHSf0Aw>)g;!nZ$`Y(@Z3O$R zr1bcWD!|_7`cqXoms<{Fjbl|obR|dZ<(fFg?4QVP{ojM2K!6$$mcFJWP6a>KFN(n}`Xor%C(tsVolG`P2xIdO!;+)Da)XOVB&`i;^DV)v5m@K_AUe>F8! z7Mk#K@cvr+=o}Cl+stZPCHoxgrw+CAt(S=&-I=uQnYq;X(@oe}OCT_jo8ii4#eMk& zu!*)t;bBUzfP1!+3hVAjvsm5T>q5$q zE}N~og728XOg1l~T8Ic7$XMv^hnrwPiljURGIVS&zu|eKN=KAhRgDYRn1fh{G0kjg zu3RsUUtq?QkJR7wLNE56J8zSRJbu(KW0b&~Q|)62Un#n_JyJZc8&*FRmz>bfajm}` zoPq*lhy|MH2|O*|S32fC9F{9H?Kab=>u`04b4&^!w(JChb(f32o}Q{aGMwgacEE&+-M#qRg-6_li3|E zrnuyX4@bY*>LP|C*VXk){$NW4V@?DVmy#Lql)2pUA#)kas(;gGuz!H9*u4#@k;`Z=pf{ownI~05G3>CU?gS< zP;>=g*g0`0C`CF8x1Y9S`cM~dJN&50fO73o>ZF+kcs7p2pMJfxC}M)7w<<*97(s)R5XFyq+4;5}v42-M2;_{S6lGo8_lh%Z=Iv+PoEpgK=+1-3*9?eICSc@A&ckj*C%$$0 z5$tWq5`?{gK$ zm*a{qMao*{RXSo4aG3jYXbj{td)7#4DxWuJrqE2_q{o&hlj1-blD%RDEKQ5yG6hf~ zgX6lt>MXbcT@9jou>c9i0krQ%1LM66PiJZwxxFQ6>1XoB;eM?I{ub?W89@zaKXY+uDj-xL4A>G(# z0^T@DV={q56l2fubz2E?fK0@5*gV?KNC1MxK_3o1jLxP5=K7?myY(h^P5fHLP>?aV z$OOauOcT3saxB6{N5IBnr~6tG%G%I)hrftEZ!W=5v*}>5 zyC`@HFY{9JEE962TcoV^rF0Pp*9DE6&Me|+Lrf5@ab4&vS6V)=!kvIh>t9Mc`rx?v zWeI}&Y0lj5k-8GB2#m+H-b|BpV_bjVCc5axi;Dr?GK{iO_Gp7jEpXqtbcvOQ2AH?k z+O?hq$l`HLePeGgeCS`NGLg10^U zX0A!Tx9*>0LJ~A5JOzI7+0jbouOr0^+(yafe3{{I`2zvgA{r= z7n0U945^H!ro>cu&?U1)1b^7_O1j7^q>ZV~$kx~u1XRr;c;`;UZIq_U0@c$==(NZy z_YjLoDH?+!#X+V=B0d*>+|EdXE6K-@plr+77mS%k1pT;>CvYlv51SvCfe(1)W%CN) zG8V+e6tNC76d|$;b0J)?!6LSDa zPFme-!B9ocA5y6?_y3l@w?&(IceswFHhk(4RgBz(y0tjHyyNjb35rhRR-Ev^C%!s9 z_%s4uWUkwg{?&nv1A}AEBZqA_pXBsOBIdc$WZ5F$&LrNsG0>*f_C&%nXpv4lpT6M@oCL#aKJjiK(m_!6wI;Y zcC2QR7;>AfXa;nirMox90t+m#IaA1NtkV0|Dn;xqB<9v6o%{KYY=_Sj)*5ISLwv?k zGM6=jf>Ul0dk5|sQ$I6i5>(obPiAuJc&x=U6=qZQdUwJ3r<+J5Ln2tt+sl3a<-lOr4upw)PJz=~*nFla3%fHc3RM3&F+J)7a6E}(^$j*B2Lr7UPe#J41+5IpDIiPaR-PG1Yk zTW_OjLoPJZSOxd^3BzvVjWTnU)^U*VA79Of2MOKt;>3v4fNFrSDjb5i=F zJChecg!v4mj}sj_S)Nc%MF%0&F9j~tcdpax^^(vNfZN@)(52Dn5+gqz=01;?FWkE@ z`D#T%(vAg@H=M~6Mo1DCqTYlPa%G=Ea;SEsl7ki!>I5%r)P||?`&5D9<^;h~$O@t} zVD=>c{F86bUHcElcpctbSU@>WsAP)M2ZH#TM-!3)D3(zbADVQ9vln6Ch-(qwlJke<7 zq2!93@j=lYygKiKGb&zMIG7nn*c3eLiQTcY#(7eEI7k!+WP2@c_@NMY9O7hypfn@|>aF$4@O`P|6!V;;``;VUV;LQg0;OQP!`9HXY{kEyhE90zTLBm>6ZfzF_I~tL&?f( z4liD50;c-REsNQFBr_nDKgp@{`t6B_v_v;AkZXu&!5GV?oDq~M7|{$qHZn*gyX8U` zZmiGE0XY#dudb)Am^1t`NHb#ol8AktyzG>9UsSMGaxy$gXXdBIt(LBMRD64TJjbe39K4@@7Cn=U{QXhvnV5mUMtopP~ zyO?FkyN&H-kfQ2)IEwug`7q|Ywj`7fHS8WD;^+& z)ke25id2T4z5^|#{bxE8>a3AM+`vDOMP@BZ$- z!@>uI_}#C8r>fJIR5-&7eH(75PFFul-<;(L<3h*FHaykdb{k?s(ZTDHH+G3@ zwPZX;bD33f7A0spl(W_U_*MA9J>-RZL{5g0+Z&`Ok>~mhE_gyMG5S;I6_W(=Up$4d zGE?OgAL-iFB38d}3}$`Ub>VQ7Ed0-m4Tmk4KNRsRBD%%$AN5pR`5ENJp!nPt=)GlO zQaG%dAH&*S=p;OVWjjr~5x2idBNCvTGs!d)sz|OY3J@dWRC4VFS$N|c8Zc^<+|QDT z?OG6KKM`NE&iKqsP;lz}W?dG60o{4&lduAV1ND21`P9|?F6Up|96I8{vy?n|KL$z*!wDg7X11Ewae9BATnMy?dxdnJPH{akq-~Qpy*C0q zPu??$2Clzi6-6>gCrQfY6)|Xd{4)6c_~TIjWJ>Yd*6mV2>76Zm=ED(vmL(~JcURdS zGO~o9q3$zVkf7zsE@F`^bn|!CAoA;U+~FAL*89NyBT!gv{H4(NBUMrJ_X?#ZU@*plaIGU=}=Aq zQ)S7sn>ehgGyfEX?U?(DbbK{B?Vy=I6%>$PwjLme$~8(}ai-rUCu?2%T;iQjrxp0d%!sbg`gz4t_Cm;ztv&YNGU6EOayj zsDH&@BPIS7VL+idE$!cYF3NrfKgvoB!f6ItD#k)j^*Wlm>i7oPeuQ<6jLqgs!0 zm&B9urId(a2G#{v-d-1Q8MBmaEkvmX+=^t>8_Ya%3cig4|1uTg2k&i8rL!(H=zvyI$|2rXpeXHnL5>=6!@t@<3 zXC61aLY4jQ|(DHhe(0Qm;FomTY%F!~0B7ZC<^q3{;N5UYCa!xeBMY-fSRMkY~h zCSkJ{x@QYz0HE?TLajqsKGMO02e{}%W*ADUohrLitjru>a+H|%78$K16H%?sc8#wB$x;wz0#&(H{tagnb|KL@|}?lr{gd#=lr3Op~myEVfCYjYM(LdxgJP7l4HRsu~5*vS?6^8t5_^ zEWIxfi7J{CNA}7lT9TV%N17`M4b)XHXN}tZNU-Wi!7ep!V4=h?tK(8_9JsQ>?j6sY z)sCmAJ4}!2pKC#J1OP)%w8^Jd{~|2-fL6X|$zN^t1nFGt3i>&}vrih8Zyuwi4nEig zzGhXI#g=H)#-;Em$xOCiFYh{xMJCBagQQ}LOp>Mts~H%JoRlFMMNpKs7wM>{`~%Dn zfZ_2_aV*p>5Wv!)vX%YXg9S|<8qN!CaSOubHhDaE!(}gm60gU7^Ot7EiD^hznMQyO zeuB81qDQo(GOqV-?v>wAbeK^uwNvW&f-D6FUE0AN5sOFBN4xdh(tXv6`K9GuPM1*~kzixrT;0n- zcFGdyyCNBZzRjhldF!HpBmv0348@Zeir2cEeh&oQ8-4O|bhff{Y< zN_$;)zvZ5eh|Ca;_rFt{>UV3_#T76~JTuLn^)D^toG337DS=N5D*iu1tFEK9vDx3F z$L$aPWu;yZ>^@z)#<>CHsjI)ehx+Oq54r^xETYD6A~^uMB}3~I1BXJl4G>y6^!@U- zDqx1bYqtg#rzE`kF=`Riu7Vs7u8b3Pjm|Wms3WrY^e0lIyr8bszwIsuGb6|f?%Kjcfm<(MLvkx7rdL)9oYuax?>gy~UYLL*WF&&rr#|LQh*N{7qvY&*D zU1x7u@MuXte5b8MmxGAx&$jw9vHcLexBswZp7D)}$L752g|bfmi^5R=gogq`?myY@ z0BKSM90SI6NHsEOKol*!7ds_Q26Hdyr74dJ$j3kLyQVf1o$bO?GU|2ZH47(Yc3SMT zSos*rvoEt|!89u7v5L8FBlSdU(q@t-m0Al}+w>r}>4uZ1@_(PuT`Ri#g@zYfAI4by zBg4F?w^{$jNz?*#t;T=~XwNtJDX#DqI-YR=85YXI{CNRLkM@*)Hc@DUkb3&Vk+s8A zPwE08!P9%ID&rne2y?mf{hY;wE9x@g(b>m~M)6M@clB>k_@`ju9)L1=#~>-4Cm68e)+Es7xs7YCHcQK^pg>hIT z7dTP7!R@gy6y>R>zzu0Eh^PCN{Mo0vw92JyQ49stcWDiY1~U-A0gI0yv!@VlKo&!W z=utr5A0f{HV5MMF@BaC%wHHA?RMv0TU%bA@7Yb7$fUWiy4R)RTn&%`ZfE{Zgp)-;V zM($c(ntBDd>DC~+Zbvk`^D>hD@?Y$DyjWcYvo7oaNTvbni~Rc#1|pz}6Sq{n2=@hR zk^z1iINJbLUGT(@~`ke)QYVE+5Rt7bKd#W^Yw&6_76ksHSulLZhA%E z{69n>mICyAGd16hJgq8V^Z)$h=<}jxQ0lt$Te`MGPuL;WYKq!6$m93(*%*Cg#`Z-Os9+12^ibwAC>PIs?JeZI6au#*E+ zbbfnvKA+rgD4igHEKshIGy@eY^o&CpdcZR;cqGx_zJE`w2;j9QTuAOOTo0YoqB zB$cvZiH{$!d=eo7D8e!~0nnJ-{`WZ2FMx40ZFx@Y^z+of^OtW5r0FBkH{0KHo^?40 zUE}{!46^3aqbG~sbZ!lK9^n{z_!H>C<)zDedlxN#78_bRFy!mq-MOVtkiSK4G4 z<{o*Sc?c%C4>{LGcig~&Hb9OA4{U7uk0P`fZ z&ar&rp)0woS*~QF)On9eEf}9)I;zEy*(k62;)!V!R!bP*l9=9|LCl=SRXzg9|G^Io z0mMgJgQH)soZ0^t^f52*3Rv_w@X|3;<>|3z^+bVxZqHOgp|D@+weHR>$ntGK9{|gZ zX*a5T7iSeu6`7;mcUqtN-gXTnio5$+{`bFlQ1eR>0FC{dd&uI6>2axvtk0(+ zkT8b7dXc!1LFZGSdi&7Aw{d9Z`<oxQ*@`Tz3=+)fCrw(6wT>nliJB8>iP{MvN;Q-%vY}; zP8x9wZ7rulsEG!NqKYObC-#fmE_gPJ4C?Z{L`ujj?^V}%4S^@sWU-%dX%k#1T_Nuo zJk>cdhf~N#5c}=hY>HSB!#tU2M0yeD;KdOgY7`h?QUncxfhICRkkO zyNgrE6eug-;@^~=woZuDfBY&70v%sntQdCbQq$wh?m@ZF6{_Wi@Bc2IJbAGQNo#WEC}IrRWlLkY=%i>CGLc`z-_3I9yONXXk5~+aRk3(4Fwvw%6H*y+G67~hJ=;gQ z&7QCH+qXJ4;HMNtJbLI>%`(_)Yv869ZfihL4fUl)lSCkO6eWZu((4fTa?N*-jmCwu zQUkiYUX-*cXyF>kQz(vYG}MKkGtOZQ_B=KbBx#Ck>hh`PGwfzxe!e3zEm;}F77kWS z0pY|8j8a9C<&|cH1!z>nRbCoHn21mIom~3b8go6fMgbfq2oM;JcAF|EK)Qm&XN8Z6 z=G&@2)tFgSyzk>NSW}A<39ibE_A(!SW&fAK7AGd{U57@)FcGE~9!5;@E z*-%95ac%~czSm)Pc#*15jk$R@NJ`rbEK*MfD}gZc|C<6DtDueDJKa9hNv|g@1U5Xc z(o;Kn-$lc?ykYWR$D6a>WL6U&Gl*mjN;rK#6G zkj0n??|dAq+THUmbhvJaRT6#W#EkzB?e*DYGdEt#^qA+Qo!!tc5gJjWo9A~6K_mli z2G=WpjJO_CPW~cH;|PH^pOvX>27Z<3Pu~XaU}#aWKQ+*Q&)f1p`Dun^P|_wb454Qg z@HhBwVFmkps&gUILS?uF9N~U1dd!Bs8(>A$=k1ZY1df!hJTIR7&qklZ8c=@45GMkH zY+6NnJeuo<5(GfJlbFl1Zglck280&_wZfJu{@58LyW&ri=fjc)rO9=?von{oJ?$9I zAL=*)sc;#M$84t2g&f?>rkb;+WGYW?5a%95>60LH;IR;5^qPp4jv1PT@IaVe<53`* zvkH4qySgs{Mbb3KtP7*gXQea*m|h?!sXCwiLh-J4Y;YY@lTfO(aSY`d?*!L5sr^q< zzMP5R9Td5t#?B#CgroCl$Vj~B?t?IdyD7%KR` z&uafEC+bw=r^*U4ctU0ppGc$UtUD2R+>q62`yJQLE#`n*uExH1KY?8-lA(lA{5XrL!mOo z-R8#yn={X@ft_YZ8jHWG_w3--miwHKb@z4n1Quh zNJ`arfOW0}lp}VZ{khMq-u7(_D(IxscNJB82kXUIg@=yPJAO7~1VSFC*=C#!hD45E z`JBqp-&vwmQf`Ghp)5m;0Sh(?{1oEW-x+7geZy)-f5P?Fy=;R`5=d|%k`8FMF^w|u zJCX{3XD8X&&jKEPIJ2M?_}RRcgH zHW+=Kz%fPA(gQU2HjuF{KKA=R-k)yiqf>*QlL0u<=qF4h$CNf+-OCILuy>FG6b8KcLBcQfCZn*^k@>D0_ zL)S5?B&Jg~PMFk!`!1ex|4CyOz0GY6*bS;Q>U05{?V`1J`Wb?3zA}Qpzgs}i-7))9 zzXW}Y$C}J^L-7~;&YrmclHtAjLndIHL(j=+LYxBTn#aLbJEEmn=C7yidb){H$8D@} z$MwQzlxxirZMhcG&mt7wzWBoaBJla%zv5BqBc?IX2tD_#AwgqifF-{0w{DvNqo-cy zqyo+x#`=9GV5$1a(W@U&Xss)YLZ7o#Qa2}u2ts6tbSLEHw)~xOsOwzP_k#RC5RKDc z&M{gqzUjowIllQWp0YW6tNhx~F5|}IGdx)K{vlmBmb(){p0~F@q&*{pejzu3T3D! z61G1{?y^lVfjvb(+SP+S@xrdet6M1x>2Xfq1v=~EKdU=`osRiB1!Bg5nXy(PLqh6J z92yuf2R_{URgxc@P_IcEl5kUbC@pBlcZ8hm+>0G%m-kp?`&V%7;ga{1Z(K}E`XvSu zi8q5J9jC+#O>es1=_~PO$;Ooi-HOt1?M^jYOl3%i2;o#XFsvDVTG|Vlt%S77mQ%vf zQd+~z&Eua*{A54L{fOQRiNLX}5rI8kJ-g2-dw@69Zx=Z#3FaHR$g-cI2?7dDIo>&D z%8-Ms#r;;oL4jxh)XmUU2#iLheftSjGtFA&&9>TyNV1{W9SNVNuMcbF?SXk8zY@|b zfJ>3#%@R2iyUd@yMRsGf7#o5QCEc96VK=bwNGx242>PjbZM!V(cqy%GF-^7XrvFUf z%Bxt&FLF~aC-=VR&NNI#3H)X!@9PY6eIc6$mCc7MtLVGN?NVV?B7;CTNCFoOHp@G@ zo~sm19+N6kj=sq}fEGm-XbmH|LPPIOf|9|RJ(L20R^~J1_^-MtS)n6AMz=GL8LDH&H;aF3DPAnUv@HDQFn8Tf@hcvXGXRgI7HSRO z#Aed3FE`Zjd@iyKQqEo)<$n`M^5@I{2!MWkD_`Cc4Et5g(GAifl%t1pVXfuLyxHdZ zj+B*3Uk`u{faq_c(w^Jg#N;$N7f;P7=m6G4KJf2@3OYKw$E*_ltFXMhvJx5KG+yyv zW*T)C^>o2fuE(JOBBr^~pDVWziJ_wOV2jK%c^2#oS(w$wihYpM8J(E#FP^ zyEthwNO@7Yv9NmAxk9e7EDrAwaEs}i86?8F#%8g^ujOX5-^~Plw$;NLp^@tsL!qLy zv-0|~(=pY%!=>*DnJnhlc!;pefVY`+c__KCw-x;_ChBB5cYYFk?Psk}8z&rqs2CUA zDW&X{D}3xO(~C{iqySn#ZGWOK2Ocal3`)R)G**+0UzH7yd*Dt=Y!+NV=rgtlOr~ws zJKbg1_YyQI40N=eM5!>m8x~G%w26VSQG&kCh7b0jg1oi#_Jut@)ZSYF4C{gWyF#6$ zIvJFzL>9}HnXZiG=*ZfFg4od@W#{_X z&t_Nl&{uSk1AgEPalq#?#2M7)3u4u5PvQX}H}DMKGE*=(m&2&LacnAbetl;uD}Kaw znOCsTi^@W5H}TpGzF4>x9!{tDc@sdYR9VIU#ok@EHT}4O-~X%_&FF^F4I>2v93|Zy zBGRdVQWB1mhDk_@beA+pjF419Q3*x5RX{)xW!JvHJJ$oa?p(+5|384;*>+?5oagy| zbw5=)2#2_dcV%Flydwxrv0~O9b`*;@R^0dAgTG1j0M&$&VVMs`_*DcMFt&B5wj?)kj`_3P^V_k}fH zxWk?&3*$rw?|a_aLHzbIly-W(69g{+0wKIxHq{ zXZ3j4viB9MF%gMe#w}4Ax?YB5o`#>e5GVmpY@=QqhI;1IxpKB{MvnA8f@E|fRHuOFHbTIJ^l<1HYQgm9}V z-I}`MVH0(K{%~x0RpBrh>_k;_eY8IU;wR7S}LXr>P2s*+*e;HrbPtLf4 z8E`e(N^c$3n_eu9z9@DIqZzZ6mVry>!hLuI#$CiQLIi8?_qf6fjq@3t;E^2Um%Zg53Jsri z4R~4!NzJY5tz;nV{}+I7oqn{N{G_L76AH>|dkvbKV!Ss2OPS znM~DqIf6|QL@&t4GNf!&xS!97Y6W3GeDrxIk`GoveEex6lsz`3QP`~GF)#f05n-?; zM1U`F^PPVu@`D>Ut3#1r>jKe41U1I4n8+7+%Z!0ZufyK>^QeA#Te^ViY);sH`oW{& zgX=qPZj|>+ds`qeHfyI}=@FE+Shz6g%~SoUdP$HS0wA0H92qga|Cha_@U6%V?c>50 zA!hdPbY|p;UIseFx9*C8_E^`~o9b+or@#Ew1JhbITEWzEf_rC$4o! zE_(81USF%~WZf(b4)u`(9B z0Sdx^rPl!|P4Lkp4xV))@8+iqB;UTRvGMr^zUG~M(Ko^sCeMvx5sr7!bDIZvz^yIH zwAd9gtcpH8kdy-k;oyQeh|&FJZt?Z`f(`DE(c!~n7RFGEqfiTA!zoMW7z)!w!ekwi z-T?75^a~j^ivi^-D%Tt6#>$$&;U9k)c|AWT)Dygy<(i{e*08xIM|jFLsonLi!9VtQ zr{nHgnz>mzPcpV|4CA?E)#VM50Y+J=xy-9S;s+8_1`T?JLK}C&`rF<)CdNJ8xJd`@ z9UTxsGBMQ53CZ1|DF%Xoy&e4!QSn2o>s?DnDEt?~I*5j^g6!+20a|}i!a%xV6QIMv z{EWeb&?v3(K=$jWm%&M|$fmV`*=)1YnN^y4mBjbol?fH$i_I5AB6osPI|!-Dh!@ky zNtROtU`u%zt7Rzm0}8!+^m0>dWgQyPdPM&1$aFQ<6u~AT%{DnK_=Q`3_C&CF1j6iB z5qQ+_<@$Rp@sDtuCoL+}RAL~N8pGbUA9B=RzhCc{M665Qu|XRDJZ~INJ{$_$$cUcAZPgZt>GD%IYQ3eQ)W7*J(Jbe`_eL;6(G%$E#+LxQsaHLQYr~K2@$F|@|1@r)2fDiR7z3@_3IK@qh4v`8cok%B@eQ9D0egqj9!CBsl}~6Gn&|8& zr2M}WC&Bq~#)x8*IwQKG@UrrfY7>g=$iLNPRmM1BZ_}ECt z;UsplPa?h1hX8bwYbYkg`o_jnHg{?sZdKZgT#cap=)^ksAJL1@mLndzjHfCfYAM*7 ziLcpsZXq|oNu6p~ijxkke(&|Ekj8|iz17p4>&^*!DzMHLhfbsV=f zY2Sl8So&Tpn4B^wz|N#VKeSKn7|O}|>90nG6a^8l21c^)X8B0vYoUMSkCi%)D%Jn; z<+QhlMg2TnxYT{!AF=2L>k$}t)sI~ryc0V|D&kTCkiPeau1F=nJNw2k8e+vnS`qjV z#LufE{{pfr4TUZm7H zE>56E!ti;w`Gsum1hmeAbUQasF6^aM7s(?Sg;fIbKRn`|DkteUcF0u)6qXAqtSJXk z6XgPhL9o(EEw}ofd^BPjvzlxGKk^r-6a1ojIPlFezA0z&#|`{Oc#dM7pU-T|=r(dd z4f*4dV3+Vb?^?Cqoc$8JWHO92JUQAZNO1WXF-Q;??hCk7loTWbi~cIA5kh$m3J$?% zhLogJDpe7u)Pq5){XW)jDCGfD?T%`@xlyic#le~{j}Hc2eM1o#m&G*64;le+^RrN` zeectIQdKX|qcwwm+|!QNAAWtgS2Do@1PS_$Fw(k&oa@*pG{ZFEOwDpl=ca9qLF!au zgQOd5#ve#iv{uzOOgLw;AVw(lv<9{P@oyf zqWq;E3)&YW)fwmw{6MA}e28dq(RlXr*_>~53hGo_2>cMO7QJREG%fYVv%M5AMC?PF zT;xzry;beQ!`&T7I$>pve+YV)H*vKexAY24Y6){zqofyBZxW}zm#|4Rj(9q|&h?sb zbUQG!p6EG?J<3-yVtJakZLK=c|lnb6I{ zHK^ZQHya0x?c*|y!b!!LF#D_Y&&N{_To4FV$^iGLSx#czGzcmjI&+D76grBKqH-jH zDIs8__4EKUFEsZaAy|=-kR?DImy$iM%0dNz_Zlb)*jY@x_yLJBuBXP$_C(sd+%Zgx zC(ljZx*o0^7wH@if^C|0wo0GJiRynRwZcTfM1dF)eKc3`!@>ncg?H13vknDhgHq7| zIDHHEaP_Sz!ZbK8px;M&uRQ6Qd{C@p2!`xNm_X7d{|x2(503H}fHX3%w?O7crM!j5 zJPWt7bP&-Ut&U5;r$Q5CRxf{VDabb?1_6}wZR|r?axQLb0={NmUZ*_JFuSDH{DHR2n!4( z!+zh8LqXKbU(er2_f9|doW@UvtyD3Hmt`3nQ6k#*T- zNnn(7ilOepWmU(S`wTkvULRZcT(LS8WmS-wXF0DWe>X;>W5kX=5C3pH#1_yakeyAv zAL1&4C~%GgqD&L%+$Q{##kQ5=q%VXi_GvaFGAzv`)`#<{ z{Wg01#NZ4O$t9jR7jhF7yEi{XhoyhyiR+vFG&bIW6h!6aIH|Pdy?0Sz)?k@n{n#Rv zrQ{iS;%WILsfk|x4xV&!dv&sSyRshAVdBMiFpq}3s>DAd{ss3?%4ImRq@=f6Qv73|^mZ-~vg;9U|KD@wms;nbaMjJxI+F;V>OB z{O-`ODh?lg&$a?-?|v{MLXN$yqD5QtLN$)$scv(q!17Ao5HoP$=g2#7%$n1M?r2iK z8@;?qY}1TsAmUleXj6jv~8G~A( z2QLY^3Z&X_$4=_lyS4Pk4g=?LzoH+0`Y1suPM9j0ISi8wk>t`r z`v6GI{gHMoT~jc-T}I@-fV$?K$b$@m+d<@9e18t5TvhIbaRu8T1r$w%t(svq(GW>j z496&56uJ<$;f_*5%W=nBSw3}o^4w~OF-q#xg+QV6HG|MyATNZcMyFgPh*t?E^(jEV z77P-sj?TD&5ffzC2-IUhfDpNI+2{8)uo{bl4-_vbrq5UvXb7*0CBV7Pj*%}w;4m!6 zlP2Du2{XC=&`h2cY>D!r0r^9ZZ~B7qYgFJ9(MImiVBtg+a7?g>k}LreLCCu?8kKYGb0*E`kV}N}U5C zEl%x9NPNAU`WG7yi@{j&D*4d+Yx^q&Z9-^JAha42ofLh_v$)!YG_Pj(FD4(~*@TY? z2D(uRq^rqzrW+t3>>o6C;4^1yMmiDd_Fy3CZB^^uS(-L2at=+!!!9}GDuf~QnNB5< zqMxP$m^{KSUH#IItDA1apOgrd!Ka`tnvhYDt9mI%`TUiXA3cTYYLG6MmCKg4V2*bw zQj~zyssLcm$|R&?y6-H_th@|^G5ohSk(MJ6e3ZQvl@Ni>FuBCvd##oIZ8t}OHb%t} zbUqBXL(`&V(0P6eg26D-RnRXp8d_$Q0z##jI7ytzuG+`l9YkF&`5nv!0CR4e0>jrD3ni3)_!)8V`+y>x);D8%&&xEP z-;fo{7pL7IKBU5fatiq@fNL==WBtVslLu=$tQ&hA^2I<`rswvfLQYA_yx@eeb6gx40{ILg;3A0ajc8soel)}!j90zc&Gf(`4V}mi_amYujpaBZ zlUSsyyJX&ZWm0)w(i5D)Q>!AKp$caq7jnF1Do1a8W=Zup;jA4t9h%NJt9|v5;$duA z*wD>3cZ-JVL8NNPL-x{v*t)V8V9DLcO~g-HD(` zal41GKo>j&`5>(xJgP8!mEZTA{pM$t6feEzlIrt&@FrmdY87%+QL2;mC>pThhQFlg z!aj$YIF>0z$?0Z%@_y@BTW|)cNGkiYc#9_h52fF!#WU5l*m6oFNXsK1wbB6EJ;iI! z9=T-FGSX*SOJxq*nz44vS8SD59x>16zgS-*6U4EuxK`U`H!S_BO;t=2_pe+ZDxwZf z>&KbV#5IDXGslM2-z+sgh<3#aaxg148Ts3;9bt2s_^*3R!IMqmyG>yKxLRpN&)Rxz zYA9n+2&?=ZBcztgS+h%sW%@656&G3s?N`h!EXB_%KE$!BAceAqyt)`&xJX;XP2>2I zz*f8DgWU(+pbmWC% z2f@V}8`b2fJuzV4=&?Ji#K_L%B$sG*yR%7X=1*h|JwWpE>t8p5wcBdG-Md&UcTCs}*4r@F;)9dyiXz=d4>GJ%Ws zs$-4kWPL5x(y&#=+EK>-v9yR4OnF;PD!4m!uT|S!SbfM}E7T8*BtSs3ZB%KwQ@-%P9YHaQRKEp}woBoDVPTop!!@fkP~9U@|%(Zo(|g->s@2@KfT zMgaG}sfvz#8956h%r?R0Db*!~GY?yb?{TXsv*{Cte_29-iBitu$nm!Yv$_}}ShG82 zH`t#>pf~)3{|TA=+#{(YaXs#l6ekHHboV>&S<0g!BI@C{E*5}p77+9qFvNj) zL-Ez%C=_~s-nI1Yzcb2ch`}J1))@&g%F+Mks)I%AtZ%>j_IL1n8K6XbDn{!}waI3d z01?fw;syX#96Sn@*bHmA(x#3e0kIi>4(^*HAatA*3#2^n`S&z&tvcE#oUH^&RWCJ zY3Xvdk3FiDs49TL(YVt6F$%FJU_V5O0<-dt*tc?!Yg{R#4yf zwV-kCtUlVM2lj~%wBdco7d7VTaF;Rz)_G%R`u;$uBPO17>%&Ul+xz~A;)BeFz5d3} zolM(elKW#O+s4U~8utTYfSL~l(rMSA0LmNhIezL)aR%Q<(arAA{s8`5Yy9{y!xRK_ zMZnoIS{~U-x)v-7^T= zvuhQTA&)qEbnZ(-ASoo{1I08R3cMrfz=xejfY1_Fx4DgDHYhP0kQwZ=$@qb{$@kxHrN__clm0^8j^UfvUy#~f` z$Hj?$;zndPJ1q>wBkF7lf_TZunYp`Gj~JS%p_EsKh2szFoP`1pw`=StTKIYczv-7w z^0a&-A-!jRa$|QHFtu>Wtr|ZhQISnzvIE+_^o|#p3Qd4LbdLZg*4YP#q zB(dv#+Uj|ch)fCD+J}(99p)z4<6?xV=(v^2u_eXnaRV5L2=*DbaC(j8mI}+7<17i> z{(7RXy|I34Dp&c%i`PxxKV@X9|1!s01()@iRGX+*huO-wj>ZrN22#lRY%h0759`x) zK3~dj=*WL)pk%+l@g}s&tNtTN-1r;sog%}&`sx>{zNXm1-q*h~;~g_ERvn?In+HBt zcV`?p#?opQh=Nc0`Xe;IZS)gMo>>Y-BmO%@ZIWtSB zdP!LFtEn(W9@f@JlDJj(2?uB^@4wp@y}!p!5(U|SeMYy8q}G19zc8J#(zOhbYwiN|)=D=*w5-gKh8T{{7ABx>w*E z;ar8f9HNqL=`PKlew<9}N25|-e|;Z8niYbIn+kC}V}fK*e`T)Ddb@n?46Igx(C6N9 z#kW26t*+@KVGZxlB4dYrH}Q;LX`l>{PM&wFAFd31-?50b>!$lP>)xV7eSOr@QOS5b z@7UUA*vtH@=Pc3iG5h(FsB1IjL=!IXycZyUcm7o*b(wjTCs+A*H0Orc#Z3o%C6CLK z-}}d(V{SAq^5oV+wnU=&IXqX>-1`%kBX1LR-g;h_+`V0XcgWYJ`~2bkU1hbmA$!e6 zEjBt~a4nhxP1V3XK;HcucA`4VZRUzA2BJK6-T?E(}*S_Dzo_J-q`}m}R0^-;839 zWg?yt7$Odc0-sQmxESyDziBXzEWN3OZNpGPK1eLY3)fo8N7z~Mt2d}B0 z#VL@(E!#|6PH?;N#$nvV-mXdMye7Qql5mO`H;GbD>UeCc@lc37@d=aX6B{KS>b=jJ zG|vyy?$pjQLC)K#CMBcVlcoeM&1q4>gSXBvSm&Q!Xp!2Yq8&t;nKa*XYjJrycO*IU z+_;R_x@~-m+2svy_k69@97SZx<|YNBpf)hBlhM3s`b=&nk$qaKccrbeuJy*3FMU6wD`IVltYG@D2L=C-bxr)RO;GmqL@PvfZfnNU<} zjsCqqb7@JjP_77W$>8XWjBQmD+^L}I&HW^zFAod1^=nOyvV}FplB#_t_DIikSZ^_t znrO6hn7<00clt`=$xK{lt-w`Ut^4s=;=BVl^4;;e{A0N@KD6aYz^vYDV5;i*#PrDc>Cd9 zTPYn+c&vmorO_|nYXTMAbhI~>vLys;8bD zlHA@*VaAW&gOTx$Ew*Q&b#vjIWhB(-$e)MnEo)RM4;%sQmPpN%mk6%uCZ>#ln6DG8 zN8Pzkqx+AX1g-S4xfJJ;w$Wc$z87ezKgP8nMjE;Gru4iOJa3e=ku@E7iaoqX z@5l8$M33D$vfX-qvgdxWjo6aRGc*a_v%13b>uP&1AEfB<5-3z`JK*bPKj9D4E4Yuh z0MD`|qxpFYTy)QFxiivecqYE;h4bAVs>QLB+mwN0zLLYUOD)zeYbW+Un6C0gCha@h zmLu-r?><1S98~_UXqC!X`EL8o)Gdt`SotAG)BA;n3KP@t@*C!|z;ka2O*FB*bkT_fVcZfm|EZ07d5q2zHmq_=gFGl^! zNG{n?pz4{8H#{w6{kN-a)bl=P`n2-qzdb_Oe7?%?tk&+|zV%Gcr_SlK#xO$0mg@Dw znBjR#!M{Tfqt{EHr_VcH|NHKj{`$*~;qRX1e?LNIUa$O~{@s7|?1N~qXk(|b1sj4mhbu1|7jdbe-PTuz5w|0<^H+to7q^Sq^*voR5eo)g9Wz4yluTzo%jG>{tU%(fA=@J}tZ_-Q6HA1r-|X0J z?qFT|k=Y&2o5CUv8jp_=y1BWSPxd;k+`6gO$uwSyA01}uXz>b>FN8kOzmGAb70OQN z6zi*vi&SY?{A@G%((hjjL|>-PtmV^1(VN-}Hs`^>J1l4Ck36_LvTG7G>TOyT+Y`|7 z_xS_Ltb$eVo*3u{%C^qkkX~`EI(;>_*zQZ4ESy6Pr#!>jy0BWvH*MdcWxu7;@(cNK z+EsO?I$@Z2^JbKLr>4EQ-f?vAlb89_$06Ti6@O5^bshOL8GGsUL_&A-Uf!=z7tWAH z*!bNiM0u``;rqt|bdTYWhb;A|KWc&C2*pmv*gSGVVFU%jfnYqvqa|EdFLo1DSqX(P z4yM|!MRzGRsU<710MH;YDtesr?s|naVM5csYsc}4f}{|ynnjVvVlpQ?q{=~eQC+Ix z-mvAurN;jz4#M+juiV(FXu&)yC0t|hIo8~KJFNJOVUClMX`(XO(8-@NmvZ#8}=XF1N4m*}j+xAn@svIqfvltrA&AO(3fzyMZ z1Na|TQ8W~EUof}28V6@{TeXKFV^uI2K$acJD0gU;?S;YFws0WIeIiH?jF%TAF^Z6 z`YDjJ{s^OZzcA>1z@5XHSx@y<4UT%sNQN%~AHD{B40-6=N_#_~5Y=~TdvMu%>Q#i= zCSqg@+`2mNyZ9V^lcVL0+YT+((({IK#WHJXPCRYZmEPqhY9zg_7#Cw{_tjBf?Ty(Mtw_$jHkA9o}jk8hGak7yk) zlezPy<)r`QPuLEt-x)9Wx4)yEeXZ~A`|X%o&YYXPRMKvIa;<*%N_(@pbK(I;W=^o@9U`rxC>j%e9(%0a{HGk1{L6O{^s&z`ba&;7OGZ@K zQ}Xeq!C)F}@naqj5~_(e)WiSy?1fMB8t*f{NR2T9uB~rv^}{4R=JtG-;niv$EO#|tf_>og2>pAU}+{CkVaVV%X$zT;<5?X zV0y!GyM+T@&P&GmX5`P8XHTuX@6rr2Ogg2J0rIQS#B|s=o@z88fkab1#sTzfszmnV z=u5%kf$Phupd7a1P^MoRPHr;}YxCm?Jqmp`4%&&MDLaJTF^HqwksL0sMoxr-deW@E zRCZJ&4@VJE&(hw1J+*#AB39X7@t9qx@b0A{PM*mW{ml9%JBdp1sO=gMUqzUcNytZ2@jDvB`h0bh>T3kxjH3(PJdo}YA*lRntU-}@Dj$o8oj=Qav3c}M zy}mj(i%AS~7hNT9Z!N^e@&iieQ!IK45Qj+N-mFNLrTo=D_Zg^;~_u)@^N7k&gyb`24WAX`#ps&C8l{jF_ zXT$s_0x+)JZLwo!NLn?+e#1iQF+Ht35(UgRaZaR#k6HKzO67b&8DcKkO z=)v1P;iP6OsEb$u4(PRM-J18mzV&JfNKHrcL&x#=zhtB+qBZ!6+4) z^2=-ZYjQ{9QenbaL`g}S$I`+5bkBDW^S5<##(KY#J=Po_L{t{V)=Hy^Rg6^|?nYYC z7`4|b)g3oYiRnI4mmjj2w|HsR(5HJ&rZakN^G~<(QI@jt14LW?ygs8e4c#C>!~`a@ z#+~7#XjfrHd=CPpQQ&+NnIG;^uXw*rH6}cei5BBuN-Op@GY)>{c~QW6J9+$8ZvjW3 zr8Lt3!NM4%?LWE>2hpUVEs8+JubiuR#*RUn_v(}bPw5L1pnV(e=|=JP9=7nZ&RaaC z4kS%R8G`)Z`$4`bS_%Kd4so9Y`~n!`P8s z9ps@IG}`(wbX(leFZ43nUsN!>@yuIChMR;ZqCj2gNL}Sj-TcB5tknz^?u>sW2k>KI zM5qv2VtrfbsF=70dKT=L@=0a_v74sVspnF5{gOwuD24LJAds_ydc3UP&3=^wP zNIxM$;ytX|x>SVBq^&i;>Hri8c&i~(Mwk*e-MlDAl@FS!a{N2!uqRnFe7G#Y~V8Q34|YsE#1qULAE|3fuDl6TPv2 zvyg6BiI5DE-~SXxV(IS7#~oy@(JG@q9{31B5->xXPT25ZAhy$1P&aW0P>z7a5xAC@ z&?ks`nV_kQQCD}CLB-tuWhw6@A9|yPhppMwB=h0uDXsE^l;M&4XovCyT%$BNSjzcE zRs4-Fomm!U|M?$!*6Dq_$&e$k4wi7`d?)pk9X*~dmW2nUUFKq$^U^)h3uV;wqY|0g z=9Z7NEQ+sZ?Kan(eFJPe5g=5tWYcT?BnlX1ysUDb=IGZoUe@Ov$9YfB+w^M zDC+RZ5TkWbvc^b=ka3|9x{w1~IJpNJTZEJ1AhL;S+)Wkb3d31%M5F6kC5-Ss;=~sI(u{ln-Qs0Viw;U#-UFk~|%Xe-XV&$Z3Q45g=NG8>>6lgDzK_ zaw)-m*}ZO=@(WD_2F9=o(Z(gnv3Q#kr+|-=>$=L!1nxfmEMcGk?Fa?yU;vBGD)s~$ z4nc4N47&>;azYi&-Sq4+;Q!1EEKC{+eHa%Kj?iW^ky16+FpR%#UtWZ8zKd{#MxdBxRgV zTL}mEas(Ck80ETt zdb!QI?eK_rMz3G9fY66Hks! zP!LWQ-m=?fq`7Z`{g+YWuw_}054J;BN@HFDTjrwZD0}C|-APT)+9zI$=_8YbmbZTt zF9ePWkez&x08e?W+uBuI*R%M5z>Qc~n=Z>jjkMGKSY7^(+!gu=fviGE{UUj?QjSm! z1?Ot@(Ri@apPCXyE6wdr{G;}kP_W&UB18E@rA5_pMm2J0CCzMokROcS58#!BJg)7i zP6nitn@W4i`?NdVML;zpz|fMrGT9w83Z$Fu24U>7L)a4>+aK7-Ysf2yH?ZGXFn(lh z9=#tFna~_35orZbNOv%g$UIYje3XEqnhK zf>98@N^q%gy%=COmJhwudj>XxiLM5qeuJq|MC}eK|?9N8-L7NI>s9tb!~!h@XAey2oeN$G>}3rKHH z4xfc?D`i-0j;j!FsBr1UGegVNYpwpc#E~C?Ep>I_tB~VF;Dv>6PfdBLVy8CJf|ohO zkV$%HJf6)1FviNR!5@-0gKcn-vn?xKB}#zniNoGQ0Dwq)wTm{JTpv7(KQsqBf`pTA zE;y?g5BKqtN!#hEmTIRiT%n?5w0Y?rm$&S$Gy!XO5HsN@d=*k>XYlb;RF6U@KMI6e zZBjdI?V5-`>lyl+HDOT(<(-|tk3gTc4fdILk&sio>M0^G_k)Mx^{r7LwPJ9(<(uX} zut}GlgkJ@A$GCpz$<}1wbdCg6dQ`YpS`37+b{z6A4D4pO7nv-a`&y}5i3HhKeHI8QKiQ$kBqfaW5N=Zy_UV6efF z`TYw2r(k|e>vW-_&6m5#7hrp9b9Q&Be>d`9b!!imDIkc!w|xP$ai9b`qwz+_zBORJ z4pnf>jm>Xgi7%kLGiOn4K6|tK@#hIhdz{4W8mbb6G(RI1iBWxNTizay0|gl(h0!HW zzyESq%@MRXVW~%(W9S^b^jm6rC-rz2W~p58YvDzQ5I#LTae8N=x?TA7^2d+D79Y$v z=7c_)N;Q8Nn-`r`WFw9GB)nk_ zv3)s-2C|h9loKLNFBgKTN>jL*+dmGBHv~-DHfMZK)7=|3-hxCFFY+|VxfqZsY2Q?4 z@Q@Hw=`PbbW=acea3l8vDoA}vm}0nPK{m~4I;m+o9xrJ;(oU75hA2J?dlB)Ya!*76 zNfbob(ZJF}n^PVl4OFN#mlI7Jy=$gG4qlePBM?vp+Nwv>K07-~@1OY(i+ zq_$AYlYesaz4cd;VA5zv7y|Oias|7xBvHKGF|B^t555u~hZoHiOasUH%{dOf_rsdb z{!DS-+IM>%@Xz67c@)~@0j#(zaer8Rb+jn-O*G-kyQ$qo4JP&76D<4qRY;_Z{%XeW zY0K|65V_ft@QZJ#0k^1wtrW_i-HQAE2MKQq*jVH))XANA$Fw7x~Wj2BJt;)$^k1O3~cD& z{T-I9MIX{v57bgP9O0-88x&~Q8x(ys~S%O~>kzP?*MW8OyPqV7Uv2(>dHFQr8=FVsdL z;L#B<82@IB_}v^_zo$r9UqV{NMo39MIW?LyE}n9&E)75gArMapTOI$q!#n$NxMz>x z&;q*w;gZNaER(i*wY*>P?dK#`qNmTEsl^i0(XlWsSto#d%n%y6$lF4WvfhHSk|xi< z@PQoEWqUqiaIwBX!jc@9eX>MGVsrcQCc@k171M3_NXSzk&jveXf6rvB=4fYnDzGV} z^<$X0eve^qSgWJnCiD-TB>0LL$3Rb?0_vS82CIV9+^VgqRfnGO$o_eB*7E8gfn1(0 z>W&N-Lj@z8>FChYHxZU2DecV=zpneP;D!iL9`3tEO(hQMY7r_HeE&%+kNySq?{PdP z%hXwe@Z*e47+@pzf7BfMb)j`Ub6BtLIoWc(QVVg745q|+Hfw){-Vv=25k&GA3x%uc zkWz7n)Qi9dhfZ~+?`M8`Ba-~<-NjwC-NRx2AYJ-u#Bg}g$Z8DO3xpenW+JirIxqz@ zkm+2P92y39RO1AZk01v@5eci)!U$vBM-mD@%uD~tc56#p)TOhXB%`5V6oUM(fF6yQ zOtA(TIUQ8v-X_zL6@}gDIW=WiH8L51(1cJxw2na24=-I4AyifuM@4DmZ&481OdTN% zmDQIWHh=-Qg*2s?`Go|ljhrAMfwofW;$0{tU_qL)zAT(9Xkr+8cMJbHEjeYoEIpsM zUsE3@J>s}St+AJYrr{Ml9z?XZp*P`ZG)b04%+p7J4y7rNt3VgB1WjaLowL=DhQ`3i z9k#1I$%V0(!k}W~kE|l3+N%qI8uXEV_^9@HzBHK4|Gj|z-%xb%fukoW)R1jIyOX#7 z!*2Hz91~?XDM5COnH)iu#M4E~jlgxWSf~dtB6O%DO~f2X()?Z>MAxG`h2t^z)aHqVo0n@zN0iy86jB1 z45cjGHHjQ6Ip9u_Si_B_&@<3-^4;JO(<3YDIJ!$yc8yQQyo|Ur2q!$kYSv_IA?6wh zr&4EgL2GFvqbQ{7jbn&;oeLMa87@#UO^PZO{89QoJnCP(HFwkr5C|r=7uKL}S{N$E z$70?^UOYr?hclRT<2(1J?5>51wFP+kJG6l1^hw{v`hS# zby^{$i*5+Yu6|C1=8e_|?E=P&uw!DHm=hhmBTU%i9hsr2oN+yp%rA3A4>K3PFM9;* z0NL;pVfeMP!Ay5}V5I$37)kx&{~qTecz_|@b|R97U$gY0@gl@NuJSfgY2D|+&u8fk zpbvFy%HD}{#yrD@CPg#P-AZUdr)nnw~1^u|{|HIRL|5N$+@#DX) zv+ZMVj(zN7&p1S892#~VtL!Lyr!lZx*4Ms@dz!1hj{b& zO3Y=N%<_yosqLM!Ly(dQ-=-J5h~G|H(Aq8{_Re~J3ns?-9Q#>zqa8lLI+TjIGSWyLexP1c~(0p!+GYI?UlR`X2^zgq zN)Arirpac0j(u$n8Aekrtx_&^x*Sn;(bK0$D` zu8ytk6Sb4YP9@BVFU(bRzj#a`-=y3=p$N~clCk;0kvN*+NBU|hbg{R(xOi-rBQ+1= zWQ_u0D$U92UMHKdY_qv$%mFOd0}YXhnOu;?0Po{z#m;@P9^FWR6gGFKWnF7bs#d_G zy&5ZuhQw~KOwDH2kZE36K)8dlU7!Ks-U^QywZ=MYHqc#a$!GVxsaco;%hU*`X(!e5 z1n#O&c9J|`UpBHLnkM^F{f%|>kCPFSR(Rqm;R@foa+`7p|5pHrMjOG8J^ zCOxqaetE~K4n?!`bb+666KHy;8+7x7_YL@Avnv&XkiJ4=_qy5HXrm-xcQlP-dc^6@ zFPE6C6H)ljk=0qhhvRuJ$XO0>Siao*!!%B))$U>5iVINeKqDomk~!#S&xpfn>GQgW9JQYB1Z117XpsnZthaZ1N#V*cUsUZQu;{1oRDW)s| zj9;_!fvdpfqz;zb1(H14wnk)?E|Y@YrYch{m(HY-Sl1+<-E;GW^H)YG6Rd8|xA~Zl zu*>_8lME?GXt_|}vEaSD_NKu7$cw&D^$Ju$kuq*aAtfizoUw(Z0J$Z5I zZ%^cv9K}I{+7;ZqiCe!_53th>9IHj}$B3jj@h@;V`lR;$`vt($A9w-I*YE!fG%w?O z1gNss{zoHNcdDNFW!npwr^q04kTDt3 z|9r+In={qswH)J^osy`q6YuiFYhas;(PYg@hI*e3T=r5{)$u@(+^2m}ElpRid-`Rh zU(ZHxE5TSk4d~LkH5Uo~U-;NUBw;h%I-+O8em}Qxrzh4ogo%@pe+gbC@4`M(1Of|< zJ#;|2r`%(_8|ZlDrGLY*M4Pz8Z`#I!T-W*CPT} z_%stA+orUTtT&3vylk+qV#QC-Yja}e2`ml}W^E!E6q&A5kCLJTJCv}$g~-Nd!3NGD zA39Y|7bER(SFN8%30}nymZmCf+1x*iX3WCf3m1uV;G%eFFe*;y-fgmmG_kdWf zZnl|~D+6|@TLswh;BD<2@N(A$9Z8Hi_^FR?Hxm9;@8Ze8@u3J4; z<@}ja>uYzWKHI9om~%Q)v2s6cLntl{ezw|_BSL4V2wT(0I8$XH?e5_0Q+Fnp39$-1UE*sa# z=;43eB2|1yyhUOmWxDIf-W3V!GU4shRqQf+(IbX|#*^TgpS`|LGP>5m&3b_+oa}ar zU3x5irss;!8RXadQk<(AEZPJi**9+f;!U4U^lFP}jjaMOwd}&KyXT=zJeClU7z$HL z^n_ptNyRKZDa=EWisjL5J$i~=2K&9O^y6U>3a}Lh97;7nnfn~vx*`IHf81-aL)SL; zb-mV3IXN^`HY;|kEuvBXUR+#%6VR(jX*;Zxn0n0*sWS>QK_kdeITw_t)xd1v@Sz*K zHTtYw=mTEiv%lINSQB8L2cnGBAz9}EzhWubptUAIq`@s-<0$cVIi;E^apwD^RmYo>yr>nrskh6-`8ZQxQ zfrc<}id0*;3LO%H84$A>c4d8_7TYn(K zhJOn$n$wRFDxI7e@r#ZC1Wp;?|I319eveHm2_h?hmzp2&y;8X-BzXA~w$+p7a6r3oE z-smWwBBnKT)er;op#bwg*Dua3%i_c8KWs3pcH)ia5=3biLT+#pbU+`c7y5kQ&kNs6 zfd3&U6%2@AnW?KDE#BA=O6!hX8uRp$TRtIS@zOK$DwAFs>!|D6>C=_&5EjhCwP_4) z=o(BZ0W_w)7-$C(_{uMLtPBZI3~{|L9`wGM?=rSDYzh1CG(C+D5dt_h^zX4xa|V^q zGiLYb3!WZacLlt*BF1Li>wSv~^*JF*TtuKmdFA&BFl07ExR@2vbn3SdUDUshEkYgZsje z#+S>l{usnzPZ~NH!aR*Gc+6tZJo`_zoG}n}8WM94&P?F^7xN*Xuz#0*UkD9B;t(F! zG%ZN`OqBgJ6L`?4x2UIjQbg=d7-aI3SKHqm1b>vAC2I`l@%W_+Mo(+rB0AryTz_Tv zm%pm-+koXf!OuQF)O4wNodGx${tuwtZ&dEfWQj zKq2SRzF%YCKW<<2{2DDz`T;(Gj6YUE7J-RqmD^kl>f-c~AQVWTXj}R~Y1z*h^#&^& zG8=QhRK;MJ1NW;LjDCQV7IH!t*j^8xd4-_9cp?sCK+0;K>T9yUOHNPeJ*ql!WgUYC zl})g}9$JZv{YLHncJM(a(9qmCL;``6l?9~>=!#ib=m|0XFNeo3%VmL7Jpuc_IlM|J zmj*8{w9Zo2SV+&sMOGr~Mkf$eQWzQgSvP=u*@h<`(F%ic}Y^z@TqR{(jb6#Gr~NnlxOy&XTrEG zVCd%MmfDkcB{0iO3G1m`5Opjq8LOQ%rI-Ze2pZ$O!VieKNMi!bo|NlcnS})mhSDv8 z!VgC-+);JH-NtfHm_)75ZfGUQ6e)Pjgro1X9@SaT9klUISr~QKuX1fs%@HhuMk2#4 zNNx$E)ZA<}A_;)q!q*3Ui9=$slt*iT0n>Lnr5@&iv0aEy39_4Cj7 z+U7U2J9+9apA3C5LLGfLKyOK;7UEX=5H1z zUVUgQuA#qh^yS^o@niFe6($z}o-q=Pan}lJRRGB#fp-I%(kIaQeio99EJ&Bd&AHnq?2GqN4QI+%-YdOpqs9FiIall zK{6mMh9PB8({{69$lN+UD7JN%&z(yExQ)}0u#`5`-?B`CvW0TD$hdX|^7oJfV+Pefh`vWIoaqRy|t zK9s{QtqDVCTXo-o3+w=2CWo2?iGzm;?*P9t3P8|S(jW|da)+EEtnyW zjtS$UnPG}t9tb7$avwZWykak|iIykRXAWT~ANI8?DoZ07Yz`;$om~5*-Y&wvguDg^hu|99XelPB0y2v?`Wnh($QhL&#ax5W9p9`om3*8 zu~ieyd8H?Q4>C@KYbThb!|nQXN)pLXR>s}OfMiw!{}?Yeo~>W=7!njo@cZ%aaZ%s^ zTZ1Z+L|@#eTgUIeBnGfDPhEe!7Q`woHpb_SR-<6%Px3fSpilPFPcT�p=rKQ#LL6 zr5EoTy=6o&Qy^S4qA5F>F}$7dml&=MsNA<3#jnX2$9x+2U?_e=CHNzyVLQf=E4Zte=rg-}mB9hBgDS z{H$wVS)bN&WRWGG&y)hV!aA)EKS2A)A~iQO$z844#C&RNvBqorFh3(=wFI z=qQe!oWbRXcVU%2;x<8b&2PCUdtDx?owa>tB}>FA$98k}5Y7vz9woE3Qgk3_yeYA< zly%%3HM_X-%9ac_V|~Q7sR-ejAU*v4(=o#_5dY^C#*(L=3enOff#{P(|DMekyrTze!0fcV!^Ng~>Ecdg)>7aG2Z{5i_fWLNrlVvtTniGAx>zF|SpSD&yZ zs^v)4+ZO!B=S#zwzDrrxe$IXbzd*Qve-Iv&)rF7-rXgT`z z3F$CH(->F>_{X;LbXmGV-!sdW(>9gE*mp)gmUD66T~oa}xu0chmt<{G8_!gwI<%Bd zsM(E~AX<4=+w9s^?5D=|_heeU& zW~fP1esZPlXzlrSJt>xc%W}sSJ@!eJexn-^LC3)++$H`LJPag{@dePVW@S~ur$fMm zQDLT5fu)WR^ImrYKydrpA-QTa0{QW%L9W@P{GJ^^o z5#i&mw2n-i=X=_?0ZSbvDm}Xe<_@S9?0(QwP2SYfe<%L<%xB)hX8d*X1e6c8k;17b z@I8UVthrToU}T;oclhZsz8@WY;#gzHjY5U0calo-4v69hsxtwSrW2ne%M^58Ga+;> z+0{jaC25l5xMVgH?S1G$p1Ph~vY@;+imWv6#TvAErS`W}%G{y7?GF}9oA@0B8p~ML zZgxRsPvY@Qk2~TJYybhxcq=OweX}P@`F1FnspQPn2xmTJ4>a1xd6J9nr=)q1s`}%- zr2L^Ul$})YlDs_u6l8%y8h%k&UU50kNO2(%CN+7D$xdu~v=Jdq@_;`2do-Ope%s9Z zBBJ%%_2zDK#_iaNBQlcy^r0zQBIu#1yL-Q8qhGh}1bs3hQ!gJpnkzkcWQFQ%r?OOY zf0{Xugsu9|1Xb*pA1`8D7g2&V=814vh6}Isr0yvlM%xK9tAOVpI@NWk7M5Y`uE9C* zqZn(1;L@wKXP-4em2ZV5(I9lm%VuRk?8D#1UaG79R)OLh!3`Q&O-m1MN}%k6A|>Lkusy;3rLJ>GDb@x z0Rd4uc^MT8ja5QtjCTHBtSqZYG~r6>!wN9Z#{;~V`33?m;*VxYzO~u zWk5~(Ri)3cpO+QQ(5e0Esr}=TBW1wfABlI9bw-jgLVhUWGYN1IC&IP>OH(*IHThi>+b;=}7!LHgivI7hf2sLZajacG7mJxCOoEmn zflei1Q@fl*vv4K?OR3JfvcBD!=T`F|JQ#0@Ne#>v-<;UeYPlY)MXLb#e&s zJ613`<#!)|e$$Z3bBf$9X3h-HIH#Q&znjs$n_)&yG-{5$>a8=p9kIA_rLb9sDv&#_ zn@jALao?74Nhi%TYpnCaz}jp{{^UL2`aS@Nko7k3kOaPLWvpL~370xql`-dfA#+tc zB2jM@WsJ`0(aq@_%6$S3u$k8ipaFI}bBPp2vx= z6`F^`zBVe<42Js)6mV4t-d^RoPlkW*i7V}g8UP0Ht%5yN{>RMxPpHfb>Bs0DUH^{V zLV~<=Z?U&;^bMQmfIC5gF^oq2aMncw$W932Aej4nW*`X}NbxYBYME7};ITQDS;gG~ z5}I4F_JSqRE{dowtnU>3p{%^oR|7Xa_Mkz*E4Sm`9{F+;5Iz)W7!3ge8Nn`zSM+kO z?&W1Kaz<5@RWm_2L(jGxmKmHStdg8lD%g-kJQJ^DB`sL~M#7v35JpoTt42lJyA%_F z!m_mtCR!}lqY7$;76J{r(Mqa7fNhOos-8@eE^lID4-yD7f5hyk;|c#<$zBS-)(HxD zRkb-)NLuBXQ4t7BVQ-V{1sxr|mf9TZfuj0MT-g( zs;br;2B-731R+6ah%yi5-Cp5uCU>4JgXtK^E2Q=prkmdcIZ{JW%(3!w;c4kOg9v~U z%|PbX^ZHh+=)DvLW){sZd6u2B6N`Wp^~I(D?8@ZF{8*Fv8Z&O=U$qGbw~Xiw#a4AB z-P9bajPOkTwTfyc zndQci%E+A^XacV3cT$Wsx#`(dlWr?c>_Aj<;FxfC?Upxy6sGfM2KaBJ86Fkh%D+b` z5Gu;of)o@Yla|@z0xDC6T0R||PVw{L2a;-k)vgbL!gP+NnS#IXWDvBrw_%ZY?$z(` zfVj>Yy)iI`deR7XIxYaI?ONVi0YMUj&y_MW(-66hNs0$>7fjVeE8>{moVo4W%b&KX ztrNA?vd~&*Ot08Car;=O>Gq5L@Mra=E7$oQA;~gmTqnp(z*yiAFRa>y36OEG)Ye!r zJ>b$<0Q#{4t35@Auj;PKkQOKH?thdsI^PHzl?^MQDu{iMqTRu4P!+0;@Fg~LDRy0^ z#2vJ11ty~}AKpf)>3EnWN(RS$oNAzJ9~qm;xAj<_79rQxcN%ZkoDPp*Jp3O zKEjE06)66MM)WHFv1%65?VbL@s#{*BFpy)9RpMCcL7!#)rfwG+2#FojHh9z>DSX-x z?@=nuf*|!IR`tXYu>4ChUKWvDUtneg3!WWAF<0nd)$ovwWPTuj#mcZl1(c71NDoh= z*4g^RRh>AgxHBOqc|iGqABfn$VLRI>83p3d$QH$}0Gw2Jx#CD2W;!}^p1VJtA+FNE z_rv!;ya1;sS`WW>#AF@&^P!OezM76F+~dC4otdeOtKp4C^kWbJCRnbX-GUm{rtUxA0Uy{dRr2_T6O*NUayX8 z=kN?t=-zQ`U8K(PDOeQ#af0rc1OUxyPl_FR{Lu}{Sh=ut0zBjquuSZ1{HP15=VjGY zeDXLapItudwBD2KVpcb%%a1g3BOJ0JH!Aa#Du98fc^2;6S@A&o#)M1`q$?NV@&(p! zIQ0Vp;lp&Lk*C6j!3f&aI)BX9r<2*CH)X4?!*i#9jA7kzpyB(%Q)_u-@>E;=-2SZJ zUEbNQAh-i7mszL4K>L6!9>LXybg^ybB=!l@kg|B+m$vW_N_fd3-dze*(x%>2U$Apq zXydxPyqfQ z__=8V6U@j2I?-5Y;KMyInD)fdkEQDb3$1CF=OYE4* zO0MQ_QT#6W<-|6qKK-E+OAtr|&f!9*>4@fF5AmD)KGnB7{;qd=tnO1Don)RjOY4pU0eA_t}{0X!w@9o_W;l^kst%iGxM^DPJaKCXfuWP$Ted(S&{(J`5B@ZzvhP z!s0j9MSG@h*6`fu3ne0*X)1NxT20sVL(s7JBdC#Be)7FrxrjEifAmv!tIvr@q|&`R zNv}kHqJ(FCqa4CAG7ss4G|KE$DqN2>l|(5-sNk|3$Cg#O~k*q zvEh2qk`iGG(hVnzz|X8rzK=i3yUQM9bPv)~!`)}Zw!HIFCVwBoXUKDZrzTuX?&mW_ zoHPr0?*{#LJQq;f@dZnE3*O{@VRZDd=;R}^jXCW=Z|BVLq=of!Hp6;NK};7z0hzFY zW`&K|6F?uHrs;_DQ(u1uONh$bcm6$HKoK zhHqeOl-D6O_CGcC9$Y-iGgdYFCZ%%V>(&hqpo2bikfASafAsrt`=>`@#n5zEX~Pd@ zoS)p4UrziEOg`pYrRy3Xr1QV~PhFRE=3<|DAO9Y-KPbBMd-&Dw#+OcM4&IZA$Dg1m zHWih#_UTMaCVChPPEIZ|7pIY;EJDIqqOyv=s?zLMX5H=jhDN6UM^4>2L=-F z4Udf8f55IEvv$5}jw;4K@J@r9Jl5aIv8_sOBqFkb-Z|m7Kiu#;5nIm@MgPh7dn&7Sn z*@nzaq?gD>b8U}Ha<_MzztsN5%-r?~Q8tVldsCo{{gCTnw35Ac6%&6%pv2dpIMjK9 zx^S0r;VcO}^>k?T(6yOHzLOy%Oov`ycN0T{84;h$^ExI)n+wLh{wVc1SPm<9czu~i zg#W}M*j|78MTls7sF}DS**6>Q0#~jjo3Ws!kF9)_xn2o zn_hQ^$_o*QLCs^31KhN*A^iF#w?iKL^Za%GcMrLTd`=YZ>7uswL*m&pzTk?pQt6je z(BV{QD*RlFz&24i+Z5)+HFZ#1{-hRDaigAweHRzH84c>U!HBo=f4nJUDIg*4&DvY2 zLqT?3AL=CUg;RUY#pspJaWLV}BatjuLDD@5X&Nz6>r9#e-wzF=b&ULcw*B}y4_(9eo{Xd-(W6u0nnUuj~^I^$wXzX|b1Qjsx%U$#sD zb)SJr0dAi$deL5}vI+CE=@T5Dky5#@6}Utw?>4*F&GuhS@W;VV4+`Y@z2)<-Mfx;uCxS(A|Iv8)g6%KY0DS z$De=qVgIB!yblT?8#=1YmJ7^N*%L68&fk6i4KAbLh6}Fa zS+`oBBsDp~KVIMcmHY4Lv8e};CTQ46l_H{LA&pb)*xi((&L7ZviX>q6hTXM>HrX;Fwh$LoE%T#P8g)&*5I>mR^tV!gvx>M-w%&Vo7!Z)EI$9In; z{{=uu3%L%ts(&~E$522h8mc5-?51Q0q@4OX511V=DphW01{%`h-!0`ReRIS#g=gt! zi&#i4_LxV++Z4vlF370GwS(oY|S&Xx_i15%4w*>bo#r&okxgI9VT(R^2GG>4ePW%2h@zb6G0D84iJ zzGu&Z`^dT3EM=m|Eqtf?1B!bJJn7rhDtGimXNXn8+&oEwO>37~jDBoltDS8e9UGoF z&{?jOHw_o`k>JWB@w5KIiBUDLiDA(u%)dg@zQyF{*_ZEOuM^o|YQ;h(SnI&();nj5 zLs>aT*9rM0?VGhw4R!n&Q$+x_$>`e^%tvnaXiSQ%XJ0&~iponQCMi3g2iMowSzUiP zO(kQH{->v>iBSOBR-;2!!0)BfwF>2(h`Vm%+=_ge1%Xr>&`?t8dV17qoeZDHlsk*I zl*C3;U?(1+G24f$=c*+ zchq8DxMlrau@LA{aZ77HvAU+iweIexQ&e~x{tqX_WcVujxaTN!n-oPFs>egR8;4=i zhEE6bRd($a5Mo z>RHoEBeUWQOb^M82a}cld z?wkzY4Lq}u_D zj36P)!$+o*H} znD7^Zl&iLdBtSg}ix(xnCZA?`s1JoSx1~3~g>?KlmG&z>6fo*E*#56yFYyyHNm+#Y z?qnbTW1Cw3+OmhSQc)9N2erF3tNT`vFm&k@`vse0oX&ed8+?|ibFK2B>;CVpd#rf} zpGPbCKit+m^JwluwwKP$lNX1_t*T`HgE$-Zif^TGjZMk%zq7Jp$A2g5zNqN{}Z=`S*-ELq1JU-hFv@b{6CQ zkdym}Z(rw^-!qoI>$-GkV93R61B--aYo;WyQ;=yhVj-TJti(EUdvLPhRm9DN)YO?< zwEVB=|DHwP=jbNAXj^cPUXhaymDOzVG^u!$P&w|tahdar`Smw)M)_&(xNoG2+wKUm z$=o@CF13rNB}6|aa(7O|C&dlaRXB?=R$Aw}uxp;IwX9fvm89QDp9^~$MBnMET9k-JsQo=akz@ z$(r`#WOPBxh5k*+p)nAQihDG~=T$_DR)(fe*3WWd(Y*r0wVYh9I9DG6hAJ;h0kGYL_(x<_JrV9ugcEN8 zHwCIwQB=fmLC6<`hI9nK7m3MRp)t_Wl%TfaMA=Tr*~?%&L&}hixCl*C^=IeCAwiyk z0Cc`E9aOfI)2uu8$52Z=*3P;hON}H-B|{5c4me+%XSzywJr4&M&YxB%JXnuIhYKPO z&9!IpIk$%RVODezhlrq*`Gx|gd8EuRarJ1(D{4`}R6+Wl_+fv+Rc#ND8Y9LDaX5d* z9x)307F~CJ!(o7HhykLG9P4E3@flq3}zu#0Q>y;-s zCiM7g_GOvs(!o8vofzGbuh^`omy=bUY4jSLnO3^+8c^UAHQOVf2}d;RGLTP#1T;T( z2=qmR2r^R@CQfRsviApDEVO3-T={DkR&lE<+;}J-TJJR(V!N$>h1nuw^$|UW)@lf=t0vWUfVr zj8{={x>o^hy#|^y#DzqW1qJgZ`4F zzVWF+!~D%NCoe%<7*G0wPIUcJN=y85+s6W?wx5zjZxR1 zxQs@HZ6NTyrMrV`RE8bZpWpA2mu!DkzKdH=cv27*A=A~8zi4r1C{pLMlu(7Ir|VsY z0z3tCfRrg%eTMc=3h9?5r8WvkpE8?>xOmYUh;%-~6pEDE5{Pk?WVqEq(RaVfh8d4_ z;bZPTUPk5tP|mblyNlL?o=ljD%(6f2vR##DR`crFiG$1HSM-%U-`V$7`$_pgJ3haOa$FhnUW}G4eEvtD zfQ?nE47ayUzi-uzxT1vG7Fo!EvLUybd94~#-|2VjDMrpV==y=07Y5Zae68|Q4=Twm zfa-;>eT9hr-8!qEC+}tl)?SJWOBVv~KfEh3-s&oG9ljl&4>3tMGwbIux$kI6e?4^n zus%#(F1|HTFVMJ4GG`XU1FDZMD`p7<3Uw)xJZ-GhcX-8Ur(nH>`MtJNHtw;jYUplZ z(K9J8r9_`vMIR*b(e#;5NP$0e&z*_j4wB6&mLAQmx@J5)D&v=GNX1?#Xg&|SRF5<7 zXMz5ZmU!nj!Wj7O8^F&1P@(p*s4g?{E{;?@T+$ttL6Fl;J{GKffA5d5t^=Iq-C@V? zoWW#kYQ5U<4I7@HTtS~6Qlm7*AIKGLYK-v)jS2h_6?b41lE4Ub4%Fhr>2@@f6McLD zrr=RBxz(C9Shqe4Vs(5YgW)?X}- zj=N_6EY0430#BeQF$Te9R(LEOR#MA+gTg=(kZz&p_Q>%1_Q#9WGtUhtpZ?(>kS7Qf z7#kgixC1-;0rL0BOh_mjA7S=r?8XhHd8M7X>n`@ z_yK2J5Sr!hf;b6bPJS#{t9$1mCyr39a@&b){lKq);~Xnmu5(6?!f+uv?j1gW+AhA{ z2+@&%;BY2?%0xt!1?CHQZx1s22jT4~PoMvpAmI65C5??qf<;WKl3&j4;2xw?ISB1D z47P#aCa^nt+48g@-{T;l5F*INB<_4%cQwWPi}$cR5zmH4w~9=jBToo+xwz2oYhjr( zm{mQOBIDUOB;DlvMduPl(80lr#NnxXhR->ni~Nzch7>^VC+dRfEo@)?3PhuT844%B z8Lb))e?V&-e}IV@IVx>aA1r>O`=F^_JhfN9l+zsZ!uTbJqb&&j>A1_XKHH>gS>xUBw!bA?OW^rn7rSfXU6G>xMOO zwdP0+Ve60ks`1S&9@!|8&`(>u$PsgTTT z@vQ2JT+->IMQ7x2I~Ag6bKLb`5WnD#>5@4wGm2e1z?}vGWmG0}=E1msYY9fuOKpsF z_k&SXycih*k|8ZAE}a*EO9b?eC|b}6lF(^eNG^03rG6V8J|)9|!(VA{0n-VPSUXak z(fbnA>oLvaoP2?gf+VO2@m21pCF7TTlp4^Pwp`Z5J{oe8SzC|;!IXfe&f->?7lDw3 zFy;9V8^0Tx)gZDVbE}(-7|U{3xAW#E3W<4AbY1zvl=mJ5aA60e=zC8@FT1l2AE*co z>$U=T(3<$4!~I zSiXjQCXDQ!3|?fE2#qAGa^vklW1W;!Y?F;~4dcin5tbhb5UGQAX>Sfx7q~fJ6}jU< zxxA0TrzE#?{oMu82jmKc8Tq&W0`%CgXE4U z+t&ahBrE&Y0VuI-GW4tcRetdm#vfZGpE%l%_BGY_=l6Cc#>F!B*%pJnU?zxc7O4is zV6hW>^0$z^`9i;=|2SU!H*@6!-~Elo>&B0ZPyUcT(mhvQl%NsX1mr#Y+|PpIiwAT8 z_Y4Mgk)3WQCoae4o}N=uT7<4h{6EwMrS|^}Y#F5p4QQaa>~3dSI=fuH_(0z=yA--> zw6tB456P)$VZq5Ii&K|mac7||K3!U#XTeI!yKy7ArXEeXBuJ)q+|Rm^Um)`KU1mB^ zfo}c(apKzckDvZ!0J^k$=AGwjqL2S@CZpS{VBVY3B7;xm(oj6u)^iWBk|b7^jXX|+ zZqwumMRfulTYMl|mb4$;XC`NVYpzQ7+Df3-my7zzgGPki=iKM@INiFA5_hqjO0uF(*xt+g9ZB_u!xOhf5zn=fbY z^#wXsM2mI6s36lAdFScPgbrSI6-lE@VOYJM=FaIm`tw4#P*H^TPo6f5|7;$>A zIe#-EXl(>M|2ScMdgDO(^_`u9(__z>9&$|GvQNBT%H*wJl&|8Ux#7yjTH+eJ9&wqT zq&=Nd;~|BIoV8`)GoP|fKOo&eNk&t)(uKV;Asj&tx)l2n0>M?~U9H@LA*z4Z>jZNh zKf#|vVazVIr?2jHw&Bd}*O?k6(O%LJ6@h$NRoRvug|4Bq{ILELM`J3w=lvU$+{>e1 zNU_&rUuWB-%fFRNnA3JuhTp`Gg*f#KdMb*PM~?@y?KlXKHI7BIcFN<^f4=n8(Qj=1Ny_dL7b)i>Xp$}al! z1iLDg7Oc=_nm(~dMN+QQNGk5_u?-RhjSB5a2V@1Yn3Va}4~nPr@JUeXo%g9X^8#Am zb*}d7W_6{*-eXE;({r*U=JjbnhjcvdBkDy6^M{tTN3){Qqt!nt(4g!WmlWrWhIgfg zv)9|Y^bT3>j-UqK297>!VCuN9D-@4H&cF3ksRZ+>CU;pBe}{}?u9RhoM#l;>MWTQ7 zddmv7TYv7c!*VWnELU20mPB?69L~r6)TOi~Zz}EQ8z29g8C#rpBz8gVs@oLjc>Gui z4f2XyN(;`fdh0wduRGebpHsZ5`BbX-^w?TV{b(;VXy9h#@`uWGpVge+!k&4TcQ?87 zR~;bKh6{?I_REso;K4^04{kRtq)J`FZN^&E&{wcf8cv0Qk<8{-UW@J9p}c~c%wM;^ zswd4J-tnu%F#Xf7%{EBfFQ%5eA#u?;4>}AkO25#G`#6BSwK;?QFT^mn&GcaS;K}dt zGeNh+RTC6w3!lustQu_o`nvJDN0MHCrTXvDnIEfvf7ZR*pgd=kp8f0oFC_oppH{5j zA>qHMPdc9`m;N&@st`b_6qXo21L+}uf8TY3`mh>By8cl*HRQi=osP3Hfo7JSVY}R-qUI!eyH`L488`eP~GL zt}9_g^OWM}g?HFU`beHCG8@Nr7c5OnNZ($a)a+1=FPo6A=Nhy+{+x*|?u9cEurqtBGO-QSujI2J zBu?yDU<
@ABK=coS_Kfti5IIPU1`aLbHK2};%<+3{YCAGV}^oXch;6JsfmQyh_ z#I31wSs}nQ%%}ZoR`Bv?&?7vkYPTE)8U1-$bL9rh>)I{kAr2RQe!Jj<;p?bDS=)$e zJQGjzJM9L&x%jJ#H_xXu8NTD81i-H*+G+YpB%GREq(M#tPtE-v4I0N=FXt*+H`)Bk zVo~YZuNDoLlrUy?%vLeAT&eYx{;=HfgZKX(QI?z{HgZyG7I&^v@4dgvWPlPX3) zIv9G_fP#RiA@ru9hoXdD)lj610qHhWq$p}Y6tG<=qKICybKmpK^PAZ(_M81?&+Pvo zlL^dct#zKq5lvMKZIe#>^;DhPq4`6e&#@kn6W7E`TN3i09S?1X!VyAs{Hq=(3RR!n zXll0U&r=~R>1#sfuC~kEZdXSqbcxOB@w+@a&B^&v&;ZWo;p2han zAlsTC1LYe&@L-qcA6KvFb=h=1j0`uw5fiQ^syP3k=cvY~I&@j~#3PSp-za8peU={W z3EI8)*vx%lMDq52_;ue_n{w$@>{0T(9(kZi828QJk`u@pvVk8D zn9^Im^0W6X3>Bcu+26hLbM(hap9`{StNT}$Mw)6)m#sh1;lX~e?7etv2DN8WKZdz3}Hk$Fe^xt!r{mG;x1Dlga+M-P67|qMcFW z;@eWf-+t@H4bhiX93fv1`bRv%v>jW5Pwbn>(xXp5p9^tY6~F(WGt%OgQ(Ffi{+sHZ zUhmb6-A=bI*Z$hGANcRcaX48C^i6Kpk)0up4|2+$JPEYDm7y-;mSUl6Cq4Q7M8fZ@ z`A5gI&Wty-j;YR8(q2^FO$l}J{CrIPcZiuXU75~z*3jp|kFG;9z>2@KWr$o{T2M$( zA3ACpG`ej+bLA%GbYi_( z+)6xGz_5`&G?30xzE)`1e0BM%?v41RlA7D2ATu5JE7|GZ@0XcH{*iZWXY(!_zaNh* zoH{o%Su}lpKTmBk|EZsro!{2&se2Ev_Un_)!^#I0>G1&%d%yF_^4xAoTD zDpw<<&y=rB9bLF){P@{55VO*B*-9p*>Noi8c?rb@$5RQwvv=`eMe`4lkH}mO_%tr) z_6M)yx*|2Cs`hE{n{J-p%-dHw%tGkPS+n&omZY2fXE^HLV_vU{Jj#slKNC3V)6wZU z`cv^zXrvJ1EE2e^;G4eh;2$`x$5_f+Sx}NZ_j7cl@dRt-&H_ zOS5(}P&BTr_VG74qZ@loO!npdC;7_}Vz^AJ)$S2oo@B(4fLCuuzdq7m{}IhVZFv4a zsxCN^$Osx4H9+QCCiCo*(V}VmMrndxX~IcqqO>&efi%hGH0k{`j3`CUh@#*{QA(m< zX%y7~iuy7|bDx3}P1i9>*Yip@NJ=-NrJD?-n=PkX?5E>JGpvj1vee?v?40l<7sw^cl$XTh0vF&&VW-W(65#v4z25Nm&uJtf+yknB}a~ z`&lH>?0BQ>b6(kO({K_kJ7pj{bvgUeel}S&hhmhI;g!QCyynny@&nipCW^emHPulj5&KoyxG5(W5xZT(P zpVrv_W)LQ)*sZa-`wt#Idi>uP?eoQ@g*%<@@RlgZV-MwtIykm`hSN&wZsBYBiOjpD7Rg86>q(gV(Yzfw_oh@%` zx?h0{o~v=_Y5vcPmYqT9X?a|WPe(~P_O?E0u>VhKtheo13!%aBn&a*E=N(=>QLpB1 zcP!l^-eb$#`Z`y7BA&JT-|xHevj6}0$`8B$_sS14#|szC|F@(c?dacs691sn|9-x2 zM-abj2f*S~LZ+`YX29g19%Lhcip_N*#w^l zIehOXGev}i$16+nk6B5jUuv9q+H}Ge2X7P9`_Ah^&A^$I`Q(N?YO_33+?&I{&1}#t z5$`_u9_iU$+Ze?iIn(kYQ~WTW0~&o?UG@s<$oQ+w#S@-Gd!tj5AzxJ&MrXLrf@lOy zRvd-1$USLqv$xVE@~@ESuQ-Do>)T)Sxm?=c4qv|o>TNh5YV~Sgh8Ru_CW)j8-VA{A#DDfP9Wng!62qEtPqA{IUxs3hTHA z>h{6NSLLyT>!ohxx#Dh_fevW`4s*%Z%ZXQP77*MUZJYV&-4kUBBS&00Cyp< z-q#lfbrYmZEqWCaOCl6Po8@?nBjo^Cl~QYH)_!S@3o-9QhpY}9Nx$VtDLS5N!A`y8 zpY#5B>-~xD_wakGA)O&siWg?$7k5$?LduO;F`!S}m4T|0m=v_S{oTt(vNs@?2UK%n z^c8z5ZYGC{%pNkj+v3%;?q&K0jUE^fcVraw;>Tx|kGOWra&20U$-L$H@eykpWIPTR zdo~hh_uH&0U{p@P2{DJYmcuE_ACB$Z)9qRAxlORsxLw3;AG`P5EBg7_0sLjW-V;c+ z)Xq{!MeL82AkKn5er|hC`tjr88b4RP;h~;3f99|0LwWQVH(ry^Pb9nvxP0x$a>V8N zf7bt))a{IOnm!ufhpe-YO6Dl|nB^5xg6*_&&RkJKLjYy@q(f9*!UMV_<4`%w5Q z^Q~q+n-(;sWGdOu%2WGt=joS^Ln}ekH+RmG4zHzbujE~Nd}LVbvfIm6C*Hk9I|E|U zSLG7YH+b*TPrt){$;Tf(SVPsPv@T-)@ijuezAW=&sb^Z0WwCf!Iwkxur{KTe0D8b* zP0C%qjliUD63ZW7{OF6RJVU>VLy#Y~)j(_^iwUBKwR?bx9^v0Cx|>dEU0(Ruw<@yB>eE z<%Xut8K^QHFL~=dbI~82^X4o$*D+{XOT1g*zy1##2q|d^XeEttUBN(Ds}2_~k4W+v zC(ZCGbsb91f20pLzZv=$0if4Fi=a0Kvp| zyrq96Sk~)fcwa>|?R|Q0mPB=_Vc1^}UB2omD6{$$=3|N3X>q|KBbFsKGez9*n>3TuV_ktkZSA32q){9D)eBJC$A!c|HI+e2Kt=KpK zB#6au@}rd@N^{SykK$n#G%|v}a#)|cq%h}fWOYz`zi}4si~*Dkx$b3db%1CiAI4M{ z7^%3WgYgaBFjn}f3C4!1MBKU?MH8h^M_5ndjJ{et% z@9-A;WC_}Nh?JD&&|-!LhnqgBJ-~2EBf=K4tU=D;E>OyYk9_75yobq8{9UjbPHJ#J zqxQZIG!Zu*_?pK^(L8RMP7^hryU zlSng&4F3j%Y@ zvV^$9L}oOT4B5O|)D3B`d1ocvm`Z8S?V97`0C>CUU=9omW@p6Y9C;A@`G;)7+@~j@ z-j0;>mIJ3@2Dq|glJ7X~F54-v)UL0+EK;+lgAx0?pes1Q%J+N)*vpatVXd|Di9JmC z(gHV5Kdzj9;!(uWnktcdX&ml>K7Fsx{UtFn5hIv|%h%JOj)(p(ZjU{RkGuxg|4Qls zOzS58#hdJ^4_;c>tvH~BxH=~M;~NQ+j^F}T5cVCs(D~5t+JuV0(O6XL zs=QZ&VD!DZJ-66cJ`~h_$w}YisyH=LfsG;hR>q#rq|V4ZCW9XK{k$WF$w1f>IZO7= z+=e86vEwydmqNdA1%;L@RYY*vu7NBUqe358YM_8@VcPwEy< zyHg=Oa5kuB?TC}j+4*M~e}nn-5&?k1vA!A6Qn0# zC=5vCe9n#sNH{wVx|3QJejY5J40&s!frH{Pz(3_KH97j`^(jUIc{l9POg;~zG5cvu6r*g}(`b49s35U@1Fpm*0C}Af*8v?V%7sNFAB3e_@_|K+f8|sys z`k@nob%Qqho&CnGTAT8Q!VU9UOj8w3>C?f}!dL2q!|o?~9Ed=|p6+9%ef6fzv5J#0$Gz-R3VGgRNiqn^ zeo)%Mx{;N4+S7WNF%?o>QR+L8>Aepw^@`%3gleH7YG{xu1`45;Sz(}H0PN!hHJCLh z{%P)$aHOUblyvUAxFR@arTnxCm<^#;#DF!DuihW5m=-M;zNUE1xb?BXk}9D{B5O*cjgb@r4K6#uDV)Y>`BeZO~ppkP!YKW zZ}m^k=U7vrY<~t9y^>}G2q;(j>{Jp3R9?#kaT5UxjLV`5V1gCeHOCa+Z&E^3x-R%vENKsPr42gsy~6e#K2tUg|JLN6e)Gvn`c8l9Y_gH1wef?M zE02GH|5N#W_l4p zYlGCB|Lz%#aZnAQJYUA<=!uPLbOEN{!^2oC&=+j* z=m6N%DqV6Jeja??+f0D~94U4_{ub}%ZacZ@DwEuenDXgS0C`jUPLvRYsct(5b$uDY z*^aD)=mKvsNKhhF00Y4?eL}zcXwfs7d7VhL9=5&%gK2%#Px<)+%uj-OQ9-*qxxtW_ znuKDuf(3=+@Ma9Mbv(Wwd(`#rycdKFPO_5I0In+gSMZkCdF!#8U5l5r>q_Pc4*ZxBuQCS6iz*)=F#8&aK zan<(f5+F^9GlSJ-z6S&YH2~k_auIO$W7^x1q1rh)*31CJOR%HKWm^FJZrSZ8{2UiB z%$!Ky!W`*Zyh^_Z5!iuQp?%d^gF>J5rT>fxFd@meP24v0X?Aygp~X*kPx|dJgFKun zRiVU0U-F+2y~V!UUd-RwWd_x4M-pKw)H?;UUFeKbuLY;I1}k(}Fv5EB z+$Qr*z*}In&5#|B+by5g3K?78N?n?SDlyqz$H>DCXola+vJGKY-j6Y1&xR8kD5d+A z`&-Osd8R|K^L?mXK&s;~3uOkm;M;B;dbVd`GK&UHNuA4-=(QztM7r57NIXy_L2Z8W z#`f{pi4c=X;Xp613KbHF#3|2D|5RjC=rSa2&Z(@vw)x)z@&bPI-HY@JGPMD7g7$Po5~#rwN+ z3pc<1vUgvdtyOQrlD**gB1&HBzd8kt6RtspIb1%eIYsPSkRvS z2`MRWlZSRU4rUuw5-e#zm`?^XUV0~wYLRlaFaUg>;V}Ft5b~hs z-GIeB+&26;xsVh51pSxA%MU%;Vq{=-EhOD9m74(Icig)7&T2DPjeqI=kkj}pmzr6i zBjOF%&6au_0sbi-Ppe>9oaLoErqRPNUpj2>>xFh`!CxQf6EVovN)_UD)%i~hfzTz| z+hw!oPn5FG$4FPI(ZL%SK)4V2cyE%B) zN@V3Q)nPl;nm!Q5O0tSd%iO-zC7(>Kgy4aCT28Lui#!~#* zir};3hMh!{KUQaYO+E=jxQ!tV(@oVj=MT^q*gp0<{D^LEy?3$B6zBVvd0 z0Lsvp)y+lT5?2O-nL{TgAva!6^oc^W2}_Sf{z*0~SdL7yoNI7INc#47_ov*75{3At z6adGs9R`5R69dJXKe=3TiO>WLNGG~KzI%EamC$=L*Q~Is*-Ucmvu3EAa|mBBX*l%n zSt+S;Rf|i0j4#rvtELJ5Pfb8xioaWGQHNW<$Nl?dpofDBDm_|M2COFQb#I4vF}j2$3tAUN2gvp!m#(*xvAn z{^3N^Pt*3dyxNBSguh2Zpg{(p-;1krMqlZ;%wiWdvFoDfy1d7C`TdfIQ9FlwLL|WH z^cgVmM+XcD_@~ZL>Bs)w798hIHsY{neO!;otsZ>o^S+y|^(OzazdFW%06=u+{hftO zhUYVw-h+WA2D=0C7ggkCZG)9CFQ#3-X;IfZV4$MMRI&juLEw-2#3q-}QC5tb^|+ju;=8&VUJ!hSOdrM%;YAc038i zf;2v&3hmf8|Cp0`_^&Gj!3M}d*wzlAEbZ(}h^|m}uFzE>IK=$F(vM1WX9(t`Orwl4 z58CfP$AC@%-F5kYj{%pvM*V=B>_XyAw4kzbqcS)5p~3?}zqZM7BVjONMGNjsyY_}v zrG3F@;r(Vi0HFAExmI?*u5iJ%*M45-vhy|@+nSQ&AzEYTgiKo)x4B#dX^jiCZxooK zea}uVQNOe%dw-7V8J}?dmko5 zEuyenoA?G5xPQ~i*U;`;r+i0$9Jpm|tE=*0r;S(Sm+=Vn6 zhrW4gLgkaH(_w-Cy!l7T8vN`_nO(USzxxDk%;J8ATCh4MK)wEJ((JG< z=6wAYIzMHmADX~SHg1W#7ci74IzP3tUVg1<0c-L16U!Tvz(ApMH>aIW@IOWmfJ1-^73CT-OW-W!22(#A4~+2a6{z3M zWwU6s4S6d)eh)gzQVw+D4ek&_hU$M$1M{fdaV=o)WaZlJs^)9);>A+T znDEyXsG|Fy%-V#X;Ds=)fK_=j&9Vu8HNa;%ysoX)>g3}`gAdP5_tn3@eqZM|rALUf zsJd&no@xuV5`-cZvJ_@-nn?~zzlNqmDd&1J|LB5CxX%6^ZsnO|6eigdW2 zt8SRy#;>$y1+m5)G69GXSK1B|W5d?4pon8%oXrrT?lh>LXI!riAzz6HBssQzx2#kx zCd-pVi^HKLG3TLto%C@o73INrgBK{euqDi8qY-u<#a$p!s>-KVVI%T+sioNI8GHZ^ z$_H%u5j$5hG_Y}2{DiR!YG?>k-x6hR-08w`v2pnu2>t-woX;^uvTYRmxiJRf!Y0u0F zNgEjeV_IUq?d9h`gdh28|47$q_YGON1&u_kom;U7t9U8b$znl)GDQD^ktvH0_DVw7 znd`7_5)k^_8qgx*&(i3lM*caVXLGdhZsPc5jp^jz`e5lc5!HmPJj!xO8n};nM?IvD zW29ONS_V!tW95M5{=omG4RB)W-df9kD9Pz<5<1W#o_;=GDNy}3N zV*&2LC>krLRlB0(9CL{%Q0(<#Aoky!--VGU)(jL-rPbecHJ6>NaF zq6g3oh?KW_r{u#T$t&ri&X`kN6#NS9msa@Ac~voSh)tXEEh$UKOP?vVDu15U#TD-= z*!|89|Dz}jg?>Pzv~$o(tV}uL*NlCeWwiUA!XEQU#o74#oTER$!a-oc`^i{)&U@+F zgi>#|)_D@GdWRJMy}fgd@y6@d*Fpqq%FCFyT#1t}e7r75`Z7J5SVur{d#m z=rD2eM6Bh-fUHaB=XAS*)S~Z1kk%n#T8P{rm)IV`m!B`Czy)N=?f>KOY2*d+T~!lDFBz76!%K;D7RXGI zi`7DtiC1^f3M&rXoglmnKWEup;qB<2u9q~HmDfYp@~W{J`!M@Fr4q_s&rAq6if5-O z0|&hU4OB+caZrJiUFY49L31-YWD)$jlr@2+Lt=OCh?DRyI~)R(kA^}cdV0EwVr0pQ zmR6|e#fi^vP8nlcxW26t+(00~-fBhuo&LM$pt$0!d}vu&Xq*tk^5x;T-j=k9x3{#Z)u`oJosNgi zU5}D2ze_i*X`Z1?pH~UUnXP#& zuWdZ5yysezZRNwj8!24jm{rvxv^_3E-%Ww9K|AUik_k>rJAt(L@{e+N5OVFN+YM?C z`Sdri?IoC}kH{yPbp#wKn;L2Rcm(dDuwz9?_gOIbC6={Y-}ay>MYwjo3=X8m^tKyu za72v7y3CrO#u3OEkX**EWW~^zYVFl=^vS z4JLaCd+iFN?uMIr*7Mn!DG930hlGDWZb=U+?YUd2{(h{^(P|Z0omCST`qJQjE`k5_ z6~^HGT$c|Q5DZ7-^o4WHD&$i}MM318w}&~1MTjwb`|#1%Wxk68cKOfA=h~E^tqQTS z7Nz&b(+Q9L(q7@xZTQHT$t>N|@1K44GRVTA1~*r`z7xtfLwh$KeabyG-qgFbD&h8z zL{Q{r&kEzm%~Y##3M83`dfbxW6?(eu=*5%MkV~G4<7E(ILM(R?f}`2@gs}E50V*>O z{7wXKZVGQJUr?jV7EC3~J-2iIN#Zq>bm~W|#skOBV&C8ZKFl$UpU&zHP z*>M2w;@$aUXeu~%!bJ-mK9lI9Ixbfw%*PhG2?5~l`n0==;D56&#eUZhrh?^{CBpl_ z_9DV7hDbTrqcRaZTD1hA>_&I(xekEs^BArL4i8vBl=o?*X>z_LreWa@iG>ZT;9VOFx*coi{V| z%(DOUHK6!sstgN|I*~pbO1>8AB319~Ndh=<7@Qq)Z~jz{sDxTPfM=%oLUN^(0O2}} zzL&?Cooxx3+kFEer-RXXhRE&rwPS(Glkz@~!yYP=iKSen%IE&VIg?xY-LfHOL=Ghu zB!?v2)sxX8Vs=MSRt>DIjxU&8PJ07f=62(IbXj)r*Q+K$B>;7 zD(a;2OX9#T7_xmOmm?LvqFw5zod4#wh+b}-YnzfE1~QWr>AZZ(dM~0&R>ysf`&Uls z&5htc1HQL{l!W1&pXLjA3_ET@7GzF!&-9;-L~Kzmi%L$qPkA^7E*7^M-0<4T`Y)!&!AM zKqPiLT78FW;g_w)4A}Um_TUrIe;Kp|mY6=Nq`gVQZAve9*V+OD^2TxKpshY{Uk~8p zlBdE;ce%c`aoxmnkE&#B(zGYrv==L+VcNmp%M{FBG?)#AYbWZ<2q->Go7NtDNN zsIifB?Q;TD2>>er=TZsPK)hEIgjdbl@#Z$Nu5-HG{^C4bm<0RwT}x)S^(VT`sfy2* z?daZN>t4Zdz&IqTMSxVMA@3(Uz#I62SEi|bo6d950d(`AJ*qvO8&AU>@Tm;dzRopf zsss^|v&+8TT1}HF(Plt70bx?3(4Oky$nL_06iyGLs#P@$HI3QmcGipR3^QIn{$=SE644 zdQKhMA=Nh!J>?Z0`^g=~oVIF!XTY|g*A$_W8g5sv%a*FJZT54--UZ|>c9%@g3FKU@ z<;8?}F=5h7+$(Rg8~|Azf(;h?t=6H!4{obV^bHL*I}-W~?kD(B)8B42S7#=-FG?Bv z)~QgXg%Jf!0`B1E@K9N=Oh>;B`9M4Y+E<)bd~n#_Rh7m~hlUXVj(NEI&~4y%9F_>k z;-MUDBQd@3us!?Si*_~6k(%Lj$~H7ZOix+jgddu$Kq^WUwf=qJ|L@R{c!OVl6$4BT zPYoLuvoU%nApTcZ-10lv`eVPulkRIBcTUdxMBoRKi383~E&4vEu^<7^OJ>>=xG^2X z_B)6$Z>Y>y9CZK%d<0y`iZ3{se`IgHQR7~#)jXUk8= zTa4@~Oq?_-eXsLRqX*nW&JH)G$pRM-HNNmg-FwNE(b1bsVj|4I&Q72c>XWX{lb0$X z?u0nzDmpOeP%uIHm^V4AE5>oiX+#AX;i7hvN1f7!$b3WX?N_|X4Cs*R&kl{J zN`9AI&qOyPaxq>4H9*!M=y5#ksI!Wkdb#YM87kMTq3o^5l!+j9T1fPOlDgia`)v|J zW$7MVg(?c#8B-vPCJdBnndQ?J?^TGR%_M|ij)i&mgiFygYe7D$t|`}q!C8OqGgCnV z1R#JDb|-pv#%y+Wg$_Cd8>-ANgkT|r0G66fgLEb=CLIS_=AB6kU)Mh6Q)T5_x&S+p0C)RNmB^eY$11#kdtjAp;AKw+_q#!Ox@)|AN>P@VShSn|`h z=%F*BT=3t5C$!H%Ws$X5$$!WmuarreilEGqXIY&fV+@Fo{w(X-W8oOE9Qlsp@3DtF zww1CYj>&!FOF#f{<1_iH@gAs?UAqQ^#$+1O+(=)R3 zhd2BlqEcxvRYI!9Ut;{OD!cSOlMiOY_)Z0aj}SMES#SR`l;DKrqo>ysNBKdmTbY8cL_8^U|R?s-VwzmiHw;Jh=f1zYg;vsYFpOWZ9qZ;oO`nhPk~MkY>W= z$gtu-|GAL13)ercTvP^GE(h_fTN1&REmA703$v`nvVl)`Uwsnq(~cLA&Bq=t%S8&m zE9o~Dw9p5-yQP5u$S2m#H~u|B?318!#TQUicvAB6HlM5mKiJPkIv{&D;P+#3KN z{=J{Ox_ejsP16;XGWR0*xo_hPOMYYD5RiMVUZyp%cq4EfwnAB%oK1JGjfGRmvU3YY&kzK#A3l)nFO zeA^2N&kN_jl2c8rZ{SboJ#9hH zh(Gld^b~)}rIet04&KjDS^CT&{}^-g*NU@ZS>)NWct>F@J@irZ?|EwqS!PvfE#tCT z6XuNQ7mig5-&a-|m#<$DTe@2s5yUMYpgqP17p2~V$)Z6n=O!bl_xwF`7_z!XN$fls z(Bnm{UhZ|x3^H&OUY;*^B9ee_|B?O*)*hPm`%gEg?Snty?ROF%K-mA z@ymd^W>6Yf1)H5o+HqWXENVeRaX~DVQplrkb5-*Ji+wpf7uaZUxlQ|3sO7!rr(#_Y zZZ4RtA@qaeoB&4BG9B4IbKwf(mzUqC*;G&3r#bTQVhvPaV+Z>1^it=Tz{^BVP38AW z2g>z_mZzR%bEV=$92BZCf&Xl3AutM6?lRt@DHbCN_#_Uv{DfA4#?*b`#O2SLzUa-g zzL=5YiV~)pe>Q)dcx;0kv!mq4Jg@%p{b7G*ADk!Y$gO?l)b-G(GXrl;cVoV6EFLrM zg@?wfImOrGQ#IhmP!;q2=!y7C>KFgX~U#`WW}pnvK7Ly+Y5`E^Y@i z5BO~rICi4l)y0`wD87PULgPe#0sh2wTO#MB=~0ZsItilxahV5{<1r!sqSM$3S`h8zELL)s0w?P8 zwV1tA6>W4BHH?te0c%2ZaA{ME_D+-Lpm36&<Rz(>bKKEOIRB2IdV2{af!mp3rT7=Ur4x2MUn{W`d;^O7l;Z!gK1Y^A?zHleP+Vv z-K^`Bi|5pbg2>J$iyq}`z5!%kW581CVx(QG*t(ssDTT*#n)Y*qZ8JS2D(T0SJ-qFG zPQsC;1iNlTamp%?D_XWvmf9~Fm<8lU>Y&x)Ay<>;O3Hk?Hm~W)-@o|cT!!938Zw5e zN;%L$^1|5e4Js6~K}2X^EcpsJ<(3|`h{IGS`dtgKm{ze0r=ypB-Wdw>)f zHoBU0oz*n8PIuPr)eBk`)H|M|Ce*FHR4}=BGwESRz&}w9bxLcu$o|d5iWSPZQW+Vh z$8r-feSZGW&Em+CV?ja}n0cyWNFFR1$sZ<&E(o-H047VRi}ETyc+bmc6_vp*R zaEc7P_O*;#ipk098hDi@GD3a%TGODNBL)cD-I;I_)(#rVk2$ohGjYHYW6En06r@FS z_iaXR=cMC}DCNe*#V;K2u8c1+J?HOZ2F754143u7eR#PVa8}|Ub4#H-GRK+;zM)WW z{qt6czn2tWtRwA%t^9CdADaS^%DmcLDpLLFbcNNcy_@*OZexVsn84d(e)?QgO@B7? z?g;j1z@};y{~M2D0v0S7@(h?W_#ri)8pa3ZghIILS~)YuU`jcW=$&gEN#h_f!yEQv2#ep-wW!Qls- z=~~PoVAB+$yAfLp;^ajQ+mS`z&V{wO z2ny%I4_MvSam}RD%vjTQ0)X1zcj3w_Y>+W;q4kx|0oX^`R=wMZb0%Q6-Szf@8R+Y! z1Lm3zbImbHUUgg7#1gT^2d&eh7=%$F80dKFe75g}%<<%PFv>zNOMP|H#4MNv8x<4} ztYv~;m&SKGw|#2E4I6wf-5#!g2p99h_@8&M*%ybksoJ)jc=MNIm52B~a$y4j>5tTY zS|fPf3#RQJ-#o^!>b+}cUbV-0i5P4_`pmzPZ_#ZKXR60C?xqJgDY$W}aN)dw|bVMvMT zsZI5m7prF$tR&wi;qNa9FKzIzo8P=lLqyabAJeG%&L`<>s2WRt{ zTbObphtE^#N|WT?a24QCDEDox=1O0%u?75@RJjygN($!&G#PMc{0f?C zCV@`yytI=DOya%Kdq_N}1OBY(a`k2v4IH=E2E`kRn6zfU;LpD>kpAQ=B(e|xwmU&l zCv0IIJG!6G#JZ2}Yg}E|nA(zCEH0SaKfe6ULHAi6iwa?vI*gd0WK!m5!bM4XX3*X_ z8(E23MBZ0QOsIXH&v~e|KIv2caSjL(DV2$R}C$&yvbJVo}GxU zjxN}k`VmoB&lVSwU@MkLL2{wG0eIC2y)~aJg9r1Vuk4}o61v%5p**nR>3~Ggy`3wy ziP^hJ#c_x*q_#VIvX0v?;1DZOu#wTH%a;*&1X<9#&v?*-5@NXI)$AfM6$&*R9ZXNK z_N4YC9Lk?oEUBeuGg>tsv}zdAfW>*a>vg3rgJm8H1Qohe2@Y&BYdZB_NHRjZTN`YZ z%jQzLnzM(k5a1;A^3&x~m&$Bcr2NbJie*aJP-&T;7%j?OfW0sM=E@Va?InmVVqaL_ zB!QC|&@v!}$t0E#K*FI3f;s~e35Kn#w^MdY}#Z&Ia(TV&PC_{0w5Yq|2p z-t*!@3e}(HOMH8I-n2sfFqJWFxshwtS|wGrQ)+ApNjMswKmfnuOV?Sc>6$sLSdNEB z31=@1)>@=dBgbiyIR;k@1Lfy)%_>3bD!k&`LRH#aXSYL%Q@T0Dun-0)3JpqBDfwy- zZ8W~hCYxRDuKBZF`cx5Q_gev{_BsmwI?7!~N&@~R(rZgDrRpuv&Tm%~B z=4u*N>LgX=N7gBh?Tr{b(a9^asg%JI)Y_s14Zk&^_&`w%I6FIz%QZ)+)V2@R zvMnr2$d*nzkLy<+9^x6nz$V=n<)_v_x_t4b2Te8FaOoW#zxMd{MGZ~Yn-?Qe?hJJX zEOx^2Ji{PR0IiUlntT3i#~K23Vv4Q;WXrPoapIs*1}KD?5M|=4HXTTzp)nZwd%+@# zn>Qa+p`*YZi$)GEj6&JETff_H2!H~B-;oAEsld+`PdY>b4gZ^U-EcDT^iN&XGE%$` zFW}VmY`dv!Txbi^!R`h4BZ}&1Z z;O(g88$(Z%cl)cLZH=`mpoJzyKV0%iI>}-x!uq4(ybl`l{kGFKNEl@dY2`@3-A=i{ zVGS#ecIP_Ni_Zgh=6}0nVJQQrGSYH&C$_MvM)kqIebBr@$84TsX*Y%)D&Nz^6hz{U z@%gyNCLr?RE-hLSPAVLLiA72$1&hvu2{(a~5edPOQ zHCblDhrATUk03kbO|A4siVA`0WciSJnAYRqAV|6x{Y`vsc!X;R`Nh;%WFAh!-Feml z*$!&NHeS^#cH-u2hqLZTp~v{u$Mk_Jk8_}n55vJ|_yx=`K0UAld3S7>%V-6Fg*a3V zpOVh+7zDM*oq%|l`f?EJps7P7qJ=S&!`7tl*fKNSbQoi`ux8(T5(K#1bNow+ zM(u~OynUv%-!$I{_(R6Tjg(Qx3$PRb?n&zIz5shFMzfiZmrpg7q?X8#NlWk>2g7&o zbGD_Xsf0RrOD=NguX5C)4j~8G8i}&gNc-tTziBuXg++H=7%4L-hAC2qg#It~?yIS( zH+=a0N+SdUhF+wE-ZAuml+cTmpmb0}FM@(d6Oa&k54~e3(gdUniW+(m6)8$l1nFQw zL9}=9bx{`~vTkdytBrNu#=H_u-&2FXLQpxCiTGkt|YvZM25 zFG8A7j-7xc0rsJ9LeY_p4MUZ2o{B%)!r2J^-DearT(>r$lTW^S=whZPGtQ9u3i4Vc zA^mC3y4-Hv;7eb>Dp_WFt)Vtq2qSrhab*g2lR@QPr8vIzwlf{+&%JPkQ))o#bb~lA zPqpjx7>_V{z$M5`JbL=#dt@nkSaivXk2lRrVib;_(VsLGCxcxmv`+ypN3f(a#t54Z zUOEr|quaBbJ)%K0YM>LRt95<$yJ;?gb}P}zR(r2(F;%}r&Y$p_%KOI6qCW);5e|Ig zV*xtzo`)qM^g+}kF{&VCS3-pfzs(4rRm>$^Bt*$F-1XCZnl4mrJD1yV@ty}r9B9*9 zoD(9{SoO_kSPaRe%=k3VFkMDBHP$IOvcbsq!7NhnaYkf7m7aY!;eE{S`w3Fd$nbe_raQ&fU7wNm3xW0x zg-LcNufsr%@XHg1pCsS_L<;la@b40PE5!3)_JseYiV!HUc?7BnN7k%pnET;^6zb&O z;k>I@1!UN-tgb#0m&8MwB$I-~cxeaNHYlh%cM|`6b0^#F8g7P~%#PIm&xhJ}FAGFRWq@HK6XDN7} zIy@x@!&q;HVE1JpJQz#PR$tshaGvE({tVoZZPWef>5kpXM}N_r38~ysGAv?gv+lkR zJ04KSJ1!Bnl1o;263Howpm`oA!!L`m%Vrl7A+fw`fBYG6GaGvSOj4V2!Wgi6hNmJ0 z7=f=u;{hqEy!6wZ*{6Wq@?HK*^V`n+ubl@2DLx=}f~*(L2Mz1yPfD10^{mA5T}D;4 z=PM)mZPz)GZ$e4-v+)QPCJW}Pst*XF2dMWAFE^n+TR6$(uvL^9r&T{W;G3fUeuv zCOH1=vex?geYRpkyK;+Z-7{zdi@^gDbXW0bT=Ir2L@1_Vt0S{fIchy|=l1Tgw!+pM zIKNstc?gmY{+&5|x*q@ao`^s{D~2x5g01MQOel4VbqzW(eEdBB=j~@d&kldLn|i(1 zh}xabakdJKOtA0HKeokKCv>aoZGK($fNM;N5;w*=PT=&3h%uPnU{%Ig#}$Bax?I~w>m@KThaC2_wOlsi*Ri>kgPAl5vC_MB zaHu$%;H={}*JQf>W^NR5=cEHKTkk3VAYH)%I*%=#V?oUjZl-*&I7d=zpYaYyvZyVQcC z8T%9d>_8lJ>bY)8=#^J@lxAux^Eo8w2d;;>^ z+IJ+c?_)+-(Ca9Y``df^)3D#gQ@OcK&1hZ0zEzf5d4tLAS0Kb9%U0u!)JMV5pfe?=1NoO#!r<73BisE0(ou&ooJg2MaA$#_DPn1 zT}D?JoLdb0>mPGtmcviSsQNwK2S-Eoe@t5Su77UPxcA_=LbV#hrfJ(0rLWcTiF#g| z;q*mD{6|a;ZN{|Kkdws({cUK8h6QNKGy(cJre)_hjspgmSfurv=Vx1bHC;WS_C7>UqUcJ`nmHqE84mgItFPZX01-4;PmldW7L5sRfGJFb(44+ah zuAevHp31!|XF&l3e?ph#VI8(%-5C2kzV7R51s=)qA(`0qoEiUc<_?^XUo*nd97sho3xY;*o7{Z_|kb1InM?w?Fc~GdwogN52Kg<5njiYVR;<=R+eh#t# zRziGfxaOTg%&<%9cX#!Q!SKE`7srLv zA!Y&qAx|Y5RXaeB#zwVsvNUHEiLQCGSussPDaXl`Y{6i|n90=CQ(FVNoz{9oIZ_;c z(?M6ThcZO!A!jhR4wTWL;gn*k2?Ax_Rcos=@41&hqZr!-jfh3tG-|v_ql&Zib{W=6 zUirgdBO1ic>t587UNp6S90&y}fpk&rfcMLcRblg~7;xm^w zBu=$pvoR#GAC{$8_nue&{kC^qfk@+*dyMHKZoLyZSW1sl;*%sios5(prql8{yohWj z@yXi}bw{192g_&|6-0BMq%m0Hp2=ri%{T{;f-{UOXQifKU(?ey_aeNT=VZ7>h!cq= zrpYAnL&Pha1%=)o{%FNmi)P`|UWCEz+j**7))p(V>m}*nuQ`rnx0IB33)C-{zoQDKH1Qq+_Zpe0q(OieQR{NeZ5D zWM$qG_^YxZb0fmTj}1I~%AUN0dW&mVDNo(vd3*(4{DOI<$V~mHEK@+oqS#~OT-R2| z=kwDo+qAn#*%kiIP@7}z?kb<&wW>S=tpSd}pJCLboaQ6dODBFN9}^ULANZa7p&;}@ z;NAsRm}9cWW%s9p~3s~=jYb8x}V`hnK5DzCzmcmcVJG%Pj>O57yc;oxg>v8c%)P-^ z`C(O&D}}d{;#k*%V9sRlc9M$YAbKp&Mi>Ps5^2%_DEg9iyQs^zLdUOY1?Q>oX|>3c zw>-bqK(#_)<*m$KtEW*bNsPbRF5Q2N^9Dnr$wsHSu9{RxfTA$J7f!nd_bNnxXD;ej zfnx%jvvI3w_m*{*8mX);-ZBU#J{56`18QL}|L6^=KKqh$rJS0F-foA!NTZnE%C*yQ{OCmhIUDDsA1FV9hJB!K+ zq|oga2H9NhcgUQZJT>8IrO z?cbsm_3Qz-jwzkvaS;Dpp5f07e6dDOofeh~*D}miymVF@$MMB0H|sbB#bbR+f#@Jk z;pz3!x&Q>1Sn#H<;MzD7Ts;CYPWrKV)fiu>2v~i>h&YeuQ;J}n9l1WMg*v@3+Y~k~ z0toF>WbEaa(wh@P4;%&+v$01>x`I~}?bTh2BN`Ge2gBU=^Np2|Iy_mP1n^B$be<5o zpvT_7u*5pTYQP6vZ6Xl_O>!7en7&l%lv1q1!w}t(%R-@h)(he^&8?nSac(WDH8t0- zEt6R&SPYJ?T`4(cNr~*VP5L3G4nkI@lxKs$&KNjqu+VX(SSJF8#;|6#$vnuR?aNne zoygWVR5T1yC3bO6x7jr8m$~@5aJGU3TEP#3mBpP-Ap!g4!7Hqf zb0jv889DcDm>y|aAu2x%mVqz=?gUV_+XYU)>!fXjl5Js3$Jx$e>)wL!Upzc?sDiVB zbSgU+jlm@#-NEioXmzFLGmVT893J;#!{s0?j^Ao}yCj4li!mqlb9BU7Buwq4y5h)95J?n_;s zGr%qRtM5bpG6;-I61)?X7Y00^5>l5vxcyhUm0mxTQ_Lvk0!d+dM7P+_M3(FZ^&~Ue zTCZM%uUPiwJ$O(RbpFSk%c{Lk$^7ru@h|j!8pD0wDto`l=6^WBullV_2^{%S&%DkP zIag58ayIjR8br*`WOP(o=d6GW{TX>z?!tV>H?9fgL^<8D;&2fKG^R|xhks&^{}n2v_XxzjM+}~W2>56UQ5g$)$GQCr7h;J~{mF<8jZH#F}jocO)=Ze#2`4LVwQkbN6>4%)FKP3QcbC1$om69U2YKE1PZu}G&2;s< zysSx|+;bgXCxTnpkWO12%3h%=Rnk!e(6oAgSJR6{P1qkzm}Iv?l`<>%FIVrt^PzpE z3w)E?E~dL>$dH+rFZ0fGK6J@>ZE0rns*TV3r0Es^)GG`DM6v;dKhtLdFdrfv9!0+VQ+zE{qb)G8!&aQ4|MA2aQkbZYuYONe8D#pW`C z=OZ9OoT&~ToeOwhAJ_2u`Q@yEnL9JuGq=@gP)l#?xzkoJIEat=+grBR%U_>}a}0CZ z5rwe|Q$NZ-*j+xI6C}g=2rK{eUP8ZUN#AkuTLVpv&7`=4WM{E1=_<2{HW%EKVHarE z;m{$4xk5Y(qF?-`CzbdOYD1ehrX3mS&XFikcFcPj%O`SAl_Yq`it@+2qZSj#egA}Pu>|keaAG#_e$Zlm5tb{%(~bYlqLD&RN6pV`G%I;Mpm;b_j_Ew zlG`tLkjj{j)YP`1x{>pKIxc*>4+c@Ea7DCyU>Dlr|A)&fcGQh#;G}|RJ0eWvEzv0; zD$~h|b&YwmwU zVNSuUtI*G;UtQ0Qd0O~soPP1vp=Tn)MfTaTL>P$!DXu}Y+kP_L4X%VK$_YV86-dpP zxmU|M$3K5whp#*}yUE^qaNz^MPULZ61ZcOH1|dLA{+d6hnNz>Nth>OkJ%B5ScI$fL zyZe(Om>(PC6nFKQGzFxbtL%LLa$7iwL*fMLijO9o&HTXHYMtU={kv!dxG?sy|Jk<* z&0k^WAhRqM(#nT-SV=4ao^4?x8@Dv2gAztxy8lzdHU6*f1c)OB90AY+F8>vhT}a8O zw6vK2S0T9o1&~sb{!^Oo0es975`whzT4oUdRhI~0PlYkYtTgPy7z2`I{J#>(1{ZUwKcMWjAMS{I*A-*#mRlfN@iR7HLmDT-kaTIo@rU&mOm^!)+;^w8=O}@iE zr6S#2ilkh8{80?r(c*u0#X#K1GcJLBad6k6Cv28~IC$SCm;aYYzDXh&*F3*OI(Ro2 zcJ55!opV9o@aWdJ48D%P!f|7*+az5^JTy5RH_(|1m)-C0%3e!8(`+eO{NtjvX+ABH z?D@0dzM~$>=0$vnp4~!6^34E+)mg4tM06sLZ2>AF8BiSYIDvf{vqI<^;y*94++SnC zUe4@L>Tch7UeP$v<#$HVF8YJ;jVq_3RcGG&#-H(stwh5FStOI?(&RoqNSCv3SLXM@ z>cvAa%z9Jv`OC&Pstj|6Ci{9f9+qx|*i5H-IWvz}&w$Z-u?8Qs%a1NQRCi^Xn+XYx+bjYA;u1CooVcrO~{J+a5_P{H_B~=Niff6}FMJ4?(J)Qt$0GXy}J%dbm0-d2VA3 zmtmL~$Ed0~-@P2U@9DZ#9(G#btt%*n3}Iu|DuGSV9}RJ%V;0|IH>=YB^_!F?DHm*d zGo!%`niM2lGDh>(?oM5~SE^W5>FX*^8PPH_yp)l3e*3<9JG)PIj+1eJQ=uEfL`&b1 zSz}hM#y*eC_2LvM^;YpTk+kpZ2rB*Tf|*ClZ1=CG)`oV)_0HjJo6PnV&g4BJ->s21 z&2zO&o0NeO`bCSv+h@P@y=?PoDt$-Q(-U~txOdLDD}CyV7BimO|3p6fyWA7xRn-;` zfqSO11E+SfmedIL#%9^hnmxZkbk+|{?S|!I!9C78WG-67L)N{UscEt8(O9DYcZYiu z2Dz;8`=7p>$aa5%+S#6VP7`I}m!b-))YO>lI&y;cSG>3Xl_{FKq|*w)OsMikwup3c z=QQcgr^5w_zm4}GqEqX@g5B0SGu$coF9>1F{#UnO%mZ63+7f<#~0js6ZLv08}qs=X15!1{>+z0-p^RSGSs@s z+ugID>|g6Byz%d3;}YfRujb(QKUx)}K~D}lf>&%ebr>&p9R0a*+AI0hhdiWB<;c&t z5w+ufRe*E;>4y5$X)L47-II|d`keaDw-)EGo~jlh5_DgnP6o^%7>B-mN3uP4-q|DU zn4Z;seOTi073apn0p7;I1i48eF#%X+&W3)FDza*G{obIk8_DrI+9rh6SYJpZi2d<2 zg{7`%&`Pw*PMCd}?V*F}UxkcRLeoc%2kizGD%oi&>sbQ>V@6i3^l87Qgn74o7}r)? zGs0!r_~OEhG#WppYUT(Fz)zB)_r#nWKUE9Lg!Y|hy-D_Djqfe$8B;%M$PrE z;NI5D1vz0pr#$c7*`+2gBBqP73~K+?bQ?IUDkT`idr2u#S^v3Y2k7OjseD&63lN|^ zbJbpIQ013Bz0+k|@93eo#P#yJzGp2HAXmDtnWq_+cR4 zZn+kp54Nb052%J$jxq7rHr7i2s1gY_8@{5K&FG)@xO0;&$+=ha!bh}nKKr!ZR?zkF3ifmO!hAtNWFmdh$U&Q0+>UCV z-f+VWe(AaFK#G9E1pNB%M0=Nk(B7bcmf*_sx!at`;AXje{^sW8k@2`Ce$0{xUHcA-@fAznfMmqU%So0g{tprmV1S;^dY8uBcE)%&I;uh z|5}}T`W^Ae6L|;s^uavFMOU|}B}5_d!@9}jdZD2`!uWZR|LKzOzhv$^qAl-I?6)*z z)lQzXcwNZVL2tBuIS!RwT1>9K;3kHbc<%lW$n!S$=DDCY`KH&n`0~X31=x$>AngZkKMU+)oseb@yCs36S+gTlcz_F`=6Zb_poY| zk!i?}PwYMq(V)`FfyB*I*>aVo7OuXk^7~n5o1y387A{}NlyAMC8xZjDk*)8yBR}0z zw^Md)=5Y~AwcH0!uKPb+Dq<2~a$4Prf7vTQ0AxRhjkNg8v9B8 z`{@&UX31D+MAoQtn|AcT+W~}VAg(t5^zcitz`jWO--8z)A{Di-9%b5Mem9%}?dvR4 z79~&rR0=5Erz4Ne4o3f03;Mxz$D}j5<^Tc464|&E*r^suZ%qbAiH=)XkdkK-8 zk+{t|sNoEN^SP7T5ob6S8I~(;ij8j216yFD9a$14CERsP61vpfO_CE*?Va`3I0jT9uv-NPpKWCi$;51YVxW)GtxbkPTpSXT)&w}z(b~u*g_r2bP;6wVp}ppFB!Q&WnhUwwC%K9|^#6}y z!VH+w6qB_7qnP|}ub9v>s;WEdxp*U~jXWDW-;I0+uZE2Rm(ZP!LIUj_y~v}$ceB{1 zwqdixzk6r1G;l;}tL)Yr->vfS%?1gLSm6I(dPy}+FF_^#OaFynFM2@0+)4a2&(hh7 z0_0q*s zP1L|hhYO~47+fz}g3T3}R+p?b0szMrSyRbs!<Uwap~y@lN4eiE zldjpJ45QOgyZGKCKS%O!dX=d2-StM*qYfA2Z`)s4*1usr{dei8*sLYt1%K$aV*Tak zoa#PrJ~eF(8=8n*O>0!~v7#no(;Z$clz1Cf8tSK&unOEfZ*KO{k5PgT7i9Ri z+l-}JTy%M%;qrN8Fo{hEJND8pPed@2f^&r?jlBQk6u{v4>(C`vq{{LT9}>oV^R3W1 zkAG23hdgg1%a6-{|2+A+?JX#`WATGbWa%0$4_jGayBi1@(3{csQ|S@p5?Oy;p766C zmd)R9SU(Z}P*<2Gk@=RfgU7`btlQ;msxmF2LxrO)AN2a9>M&}BiA3|QuTtsHq}H;M zH2n0=o+c%m9KI);r>f3pnR*?tin3YbMBqOx>aG^r4vgS4Gs=#WAo~fv^!a|N5iB`9 zx>Q{VvjLBIX#lGpTTwC&rwd`6oU8`p2R&c1d&pfkt2Eiax;b7&galyAQ`cE89V>Rt`c zY4B1|;pm9oOO5+%mf_~riSI&2`5s)`X$+KZ({|fIMC?N^Jn8zjF+IE#@(u?PJp7|8 zBno|!JQY{AqEzjjdiyhdOw`+hiE>=}JiRD(qDB1lPC~Yy`m0C5uO#B-j^^Di>2(X6 zDWlr!NtpMx^6Vicq8$>NkrU7GuJNvk%=_j?3)*n`@Rc;=a)+o9@y%$J|O7+cMVq8tgnwG>EO`+-bMVPhIYPGom|9vt3i^}f=* z`smtn$D(kS`2mSr$zE}kKju%!e16d~u#43Docu0zO6t7C_sxt-@~bR4`c=VXe&thy z>v^l{@n&oP@4r+f4&H^CUqXw1y2JGszH`Lpb~|<1EE=(Q2vCfUIFvxQH^ii3Q}21r zYHhy%>a!}c^zY>s4ZVZ8Qm7NL@?Od1C!e9I^H*os!&6i6Rs#R3IVbUY^1wwHcK^|bN znD7I^=IrNSZ&-pS?+a~jA6BFuvRp?|by2^`Fho5LK%xQAZ5%*Xk2?i3tmx692h=nf z27IJGP9rYc6|vii-P}jm^~-YT!x^q;>$g*6E>+^##|U6!huE{lt)>=!?Qrwt*fZkP zB&8O57G;l*h&+sFYV-i{U;zp}z^iD#&eTD6dajIcj_~CK6*d;ppV1`5@)`gL$e5@^ zhAB~p@B10>em{!`q4v^WP^iv@bt$XX(bHQWeNU*hMv^!Z?nxRd;oaihTR*Ar%#3XF z-y-rrpwZQq*K~T}AcZYo^GIGdfR#*y;fZmOhz+tCcH^g|sf2Llj4k%Hk6ryHQHJ%N zmnOnnScn}zkwj!Wis7f=$5!EVuN0t?oND$ExrZinaI&PAhf3Vb-?{+{0Soz<$j3 zy~8iA2Z5+@3I;fOBzn_-^ujz>Jr(X~(tkZ-sY27BHCT{)+O4qk;TmbJeKF&$s#>XS zdOG?MH3NMDcvk=6#XfsiPCVmAh34e^>>pKbI@Nwigz?Sh>oAkApSUHye_Vob*`HsH zy=Esjz7qg_#?(6R*GOe~9Nw#0L}hS!4#4$``nvL|wr?Lh(NCHTic)QoK096geOrG> z-%<|fQE${S<$4;JzZZ4Y+_TSVmq8|67n!*aKKmiOPYd%vo8y}OX)U+EDEduaitI*5 ze3783U2|D@=;qEySdZ;XB|ix_5TXwNDUhka(?6ab3^;I)r*GM{5tzh7TZCO{Q$Oxg z<{i<%p)Yiqf(~_=j(PU{m1LsIWmXb0F6@|P z{We(o5mc^kEF04Cdo`R*m&prt14=mr&b6w=7YF(vTy!6<+l4ppb#G2|Exfq#ln}JR z-aBPPF40O;9`e4T&Tfu_A?vYbu;y>J&sJJf5>&F)QI}g)%Eq8=qy0O39)(E(^X!Ymj-$!;pz%TJ zE5{aWL(Ee`OIURG%$tWu%0>HAL5OBl*$=hFuWg6pzjmHfeO9jK$33;qUixxwBo=AZ z90rB{1AhGb?H}`$q(A}Q-f8UW`1pq$i+TEu>q>hnVpsB`rN@%)ChKPNi31C_KU*pUkk1ZX>tEYv9dpU!}>=>3qJ z$7r`a!&{bN-~o<1U2$$J5_i50sBCR19DY}+)Yo3S1QU`ZiQ-|xJxXR&^=E@hK4^j{ zD(2g0jN&mti)ii?3jJz#3ThUIyeM?EhO08?+pWAIJ}K}JRhvc z+$oJ!;;vR0@3h}P+3tTBoKH+TQS>@f^N8UC`X6T3-{ggU8_lo9D#kAi+?1M{FIJEicHgdfWbm& z-&nGKpn)MydrLe;5Ka2eFaf|Zp+1%2_6@Z8ry`YG$G1Zr)HlVQXk^-lqpOh6Ymp{t z9}*$Lm{VE|C~c7IM$j!Nc#5F7o$R`%t2vW!1%TO3fsexiu03>`b5q8+M`m~0=&+Mv ztHgtx+Y9id#j((gH^91*Xe@o^@URU-t^Zb!KL^G9rIE8N@L%5N>(9*EnS_}<;pNwE zzQZsxY8F_6gYiE0BG=>>&vd zWz@7R{zmMP4R{}XZYoaDu2iD$su4AMzpf|T2(o-!K;&EXE7=s>8_zITRcq6`HL zCqjMd;}j_V5L`BAUD^jnkh(WOlOpiwlB=D@_dL(@?8ia7ETezee4C9x2Hrg$2g;7Y z9Q$B!AoRN`B!o7Ku*tdvb&)yr)!Iq&9B}Y(UL^f@EQDs-EHu`i2Qb|SKPn3Ta8gw^=Klx_q4^P<-Tcwj6|PEzYn~eFfUUt|1O!dF z-f8NpN_o1Y|9jrfI4lfU$+cq;{BZ1gyE^t=F3Ekdq2gD=5I0uf@O=4q60S8lu<@?4 zS@C5INE0U{;bqKwO0fY&HR#B`yI{7#RP$H@J&2Solt>8okHxXkdq>{!b`Qq2A51xl|Yh0`XunX%cX{W6%u-aQb{PEtX{qz;3pxZ%?Run29WB z8@W@B3Juz&!@&~HHJ-;#Oh^7DLr~~3vz5~|zwStUHYk^Y@HAMTS}oL+-FhaKa3Lh3 zbp+x}E#0gSPBX1eSFgJ?UW_(7#h*{3P^zJLVhR{#B}dK|B}3&}6WmIn-;Tg~fxzG) z!9396E6{{63xN*SS&}Q`f@#mH%QDC&^0yn`Fa)#$isFfsqJ*sU`X@Es)uR?AM%L$+ z7E4IC!=^gUM_%~aqqMGMS$4s%=y5{feNSm}z0Y}vi9_ZjZ{?2UGRB$?D^6`pkGd@d zYV4U41_wEi!A%SBj#4e!X|H1|q1!JgAuW+c29y;QCpEgmX+vH_Fz1X)ba0n67Fw?M zM8E+`hqj6@uyUMY)-vn(mgeg;TX%i9;T(4&lnRzxF_22Mc50+>asn7ih(;*XU()wu zJ;4N1lQfaifB&?q5Mk^|Uq};jgb7aUiY!<%h!$|f5CB7Rv}$5lb9DyrS9dc7K z2?bVcQ_Qz{wA~SYo6`3!xrYC!UD3w_woW!dwizOvrYYc*D84d(Xb$Dt~DDG|_3 zZew5i(%k3eGMXU8z}pVIrWW}yIO^hbTJO+t!t480#uV`HQSeM2NfbS-j0Lvmm=`2W z1|GTS8iMX7P_F#(G$()saQ9}r-0(F|OEmMIbq*-(n+pFhRV0tY5I~ix-zG=3Mz}-r z@L(u96ftBIO#sL9-l&LZlfXmK`%e1|1KYLGZ1cEt`0+i$Bdv{x21en|htXX}<458^ zH2JgyBc?5a=sYp;kb||uS0LJfrW%qyDkkHOfwX;GkRth|b#D*Blg80gGUB@?E~awx%C)8Wt0u~(l$kZ6z!8a$(UQv_q?-G{rTqAj>znbQ>H z8VYkD=rPW!&8q1C4z{^Ca@$j#Zb$RRue6KxUgk+%FfJGM@6OMp_nkcJt?bF*b+cG3 z0d$p6I*kCUW5R%kN`?URPsCj$UrFo?xE(eil|0vRubWa7x{c{D>WD`1+Q^Mg6E6a3 zQBjre%yrX*1#Kpb^qsCawshS$vJ0X8X7|{J%#7yMz*pWh4BObZzLKH7ibkJ;`MP|t z6hO80?m04K$9HaQ(x^|JXo7(#5QY%%ABo7>PW}Pim9qs;z#EF0Z>zs?_!Z#%!`a>x zFS?`8i7Bmo8=}_=6Z1YF#rxLBBBvxs_$jpJ7kmCUI}k4gVM4s_YqP@v{{W z2i?@dpmh{6s3N81Dn0byUWp8EsdS)o#-BdY+GKTrIhs#(%K}K+1U2wnA6Bq)%NQ>~ zzP&eDQP8MnPxJZEz`}1&$V#JrXkcThn+%hY_I((J0M==K_RY&dX(jB?#+H>Dhxpkz z`}a+xlC0?SM_TUfbSou4ieE`JCc3CvRcc|+$T=53pBou6JrRX`eR9f_*nrc_USz_( z>9aS!>)F&>bKNHo)*BUtB!EdzoZuH%Vl-66w=2KDP5bo7vrEpFRrb}=Jr{<^7C~h! z+OjxO3y3U#^aD-3E+2isKYR14xF8Hui6+YeQA$}?C{t^PBxWR3z}(930)!J!xpPe^qppFsNnKMP z%-4|U!`;UTzmXWZ>pNc_m){##4VAZaP)xpY_ZBQFPwhZ6 z7AM{AUp|W^gB5Uok#e`SFu?O>52HPh3JT)S+cn^@Jikj)7(0!@VL)ss;JKsy^YMF^ zQ%M;zx=aMR&Ei+J%$w4UXT4b9 zv+L70gfhKNXoEQ$nA^qY%>1HGQ!dFn$gQlly);cqJ#~mCf=8FVU^*y{VDuz^nX6KW ztzg>dqnY&X56_RBPNUtyn{+y>hqg}X!+Kd3+G_dp z<)5Lqv(>jsZY}=g2>iHq?`tgE;W+%3GsVXfCJcA=EwXa7whx^blPHL}$8%LF6hjyH zyX56RFk9esu2`lD<`;)Lgk|~UV!k z)WA#+QKJ7Jt%OFIr^uNJlF4%COte)PB(YeRvhoTS+SVir6;oSR-|#<_`Td%lSVj1-4r_V{7)8O@mbaU}2)Qc{xup`U4>8xfvUuZ`waA9ow^P}Uo%E^_ASE?NJ2*k0lQ35vvMc;^bMOX45z3Br->kUOsn2>x_ zn+Jjt)-_jB_)Mp5wXG-d2j7pgFF>vchG$TIWRP;)BZ$o&JFoPSbkp3E;XxTyuMNN+ zQSMUmY4PzpRSaY*W&5?E7W8<&J-6;{g%tu}65cv6p9FekSCowzNxz@L>(Zq6U{8)L zbYb`X(r(TB2Y1oyu{=svlJX+Fd>6Wr`*QS};zhaQ9>OlET6F24jW%Csz4dD*tlptw zb(40U#+CO7a4O_As?3lWNIa#nARNm^c*mpI&>{pNb@N+%+_N5!ZQ$J(z=Er;*@3-|oa`fj0CX9w|hxK~I);llGgB0+g z&iWuwJsEn>dWZPHvP2}Tu}CmlzV;*cP^5FF{7 z+`tf0!2ctX!QP}Sb3uh#!cLHLfHn!SEd|NhX84taX3)=3H;IA8B9px zzZbRBD8+O0O-hkq3LzF2eOO6EN`<3I^pgAgEDb+o^;hW?bc;qWrZ0kV9v@y%4Jy)+ znAoOOgH3&ZtT5UJIdkzohkc;x5`tOE|2aw@(s_RhsbJpdY=G#G7LfPb^SjzLhv8lS#be<2^lIvV&ezE*V&5A<~N( zyPU3q8u|gMZu>ZR@V#*xpTCfHrv_uau0lP)0U_sa)yG^i#~q5ZN+}me)X$NSnDu1n@13l#*8$PUY|0NJGU9yW*`v? zQ(GXezrxHnsdwOBt@F26tM^-9;HXJLZv5XaMI!sAT2PmXcmo#pNb53AseKk%$&y>P zp*J7Dm7<|oVbW9%(bTH&RAsB)_Hgrhv@S#1#h0uJ0O5aZlh$DlM?MzaEt;tUW>w&m z)AThb;5jc+HFh$nHVVGLodKiAi^Cs7HC>As3TnytSUO`lAFAjgEdI=oQ#UXxmN+~z zm2|&Lo;~W?_^)s>Y^skMWIeFJXiaUxJ5b?Dtpb@9%Gxs+Av*2t!Nb|NSxJ1*&fFO5~%zak%>1OtH43O~pj7a^)o&CQ^(B z;J{~iB_>> zjj82zW=b^LfMp&IC6Jz66m3J+ATv>@j@D*1uWTy*r7lVJqYpjTjv?!!c>D`PG}r_+ z09?T|htJk|zeMuF`h%6mm?(6b5F+yMWNfNamM&f-3)+qbCntWdp(K|}>$JX{>p3WI zq$b%v8WdbI8C3mWG~I<;laKp8{Chn{Z7{kpf;;79>M$LJ78w~j_c z84Zd$KvFh2ybyP+`DfZ2PRy8qDx#TBVw}C*vh02;peZ4Zd!47f!tDm{ z6RIY4+%XoWyoqrYu)KvZp1e^|(bNzNqf8G2z|KZO?l(LE?vQUeunJ0%QPy5OkLN); z4|Ub8MvEEZpH<-gi|o*sQeo7AT~|D|jw9dc;P+10&^!_~$~-t-1J}^>mT_Z|73d`63-Y--uW8q}#=WG; zZfWI}uZz?l{U@47=)n-Uvlr1^?YvTtSRH1kDX#kPzCo*>4GCGltGuqrmmHJi2URfv zz;r1r{(5AXhGmP`9FT3CGHQLgbrTh5ZJ6St?h_jN^!RjuoyxRXWXRX6VT2AOL`bS# zfzzcWi^SL}Qqm4DQ=4d3VR%tXrD1%!X~(>Zt=ml?gq#VnwupDxa&$dF`7WZ>bmVXo zUO$V7?%X~GrCkMi5c}Es`mrLFpBA{bbJ(moM z)UR4#tER08;KnHV!*WM{tqClKwk(K-wcEdqsr2uF>6X2Xj+2G(0aX=ZLJ@qozl|T^ zjmd`+JeIf`+Hga>CDDesfgrf4z-uLLFsi{QG|)s~4V)ONc;Io(SqNkHT+-tpZsn<{ zMe10gskZvj$bPSU4K;M%rPHKS8sznj^-Y~8tsG$d!NRkqq6v>h#dMJWtOi&Vj9!zI zXjgHS#iuSGf|c_M*HIQgH?*!aoxJH?h)M0kFxwQOca?AdcTR7RH)&4xlrldh>SM~2 zDa4u#3<%#v{DK=S@%g-~kA<%>H@i!L_2;AVqSCugrSg~?n zPp*SiLC{}?;lqkv5or_%PT@-lyu7-Nzr3F$c^+Gh`epC;OCT!6a3W@mX?p3)ITK=` z${Mwy_>XR{D4^%KaWYyZKlhqF98|ocf3NKfjlq4t4e2OAUi+pYm&g}78ch>8gVjst z?&q^2C1X6JdInOzm7REc4)-jR0(#>0>W5bY0pz>FeUETKsn@#mjeql`!)S>7yaxzJ z4+*(15i~0Ew+Z=ASv*GAo%!ROGCp;kM#-vl4rGTu4?y#pp8aczhxCMZsc}EZ5wvpz9WQbTB=Wp?R?@uG{ zZc};{C6)-61iW(iwQ#j&CyxTw{$AQ2%z0wdFT7j>t_nMxQPpjCldEOGkOomttm4F` zkV(VlO9Pdu)t7&X+UT$ktS){j3G!D}XF*QR(C(Y5E6b@osgmH2@gVw_BN_s(y5MTH zg`VlxbhI7C5-V1;N>&=6ipq(v)@l&r`O4Rd%$lrqRf(S3hnvrQ0tSUJspp(h`M^ZFP)nWD&0{AEgttmLJ@z*fVH~Kq?ufGw3#5WaJzM2} z>tE&iHa!EU`k^t^=15Ro9H)~GWI9`aO1Gj}^om7pg?V3gV`7ndxMnRK_--C^rXj{z z-rxF(Gy&?~x^z%^K};^z73#oHmt#kjh$(|uISJZ%Hc!xeN*L_Bu#<+MG#ogQkm6ip z(?FKuV>U?TU+AcAsZnaY3HE4KRgTGp@|cQi-FMBPwr(uTX)wVrg;Q6SfMh&alGqqv za}B$USjf8=YT<~&gj)xgOdEiX<$Fpcw@b>QB-!-}c{OGe+`KH#PcLx2KjpeU_d9bn z<3)rO36e5V-sW-x$~eCn>-Ak!W?#SKPe@B^euwH&Szq+=259x0Jq}XfF~WgVF{V~DLh57!jW7FJd}l*nLIG)XjyfC6v%%nzFm^2|=nFO} zwK&kEQ9XB5VG{tEg;(U7^(c;J<+7x;tv9K!T66}BOOQCE$48;O{$Fz*(m)yP8 z@W-}e_YD+F>-hdobhaZ={b#StXXP}y!Q;w4+uH`tdGd$%uqz53QL|n5Z*|KPs&Hti zBO7AMS?{n4Jsuraewl+cq$3S_IC=B96bo8}W)ycsju!Yua*g}18(Y`9r)+zLg!`m) z`>J+2?+FZDxsS+v4q;y#|~hxs}v1_73dIhH_{LN3;(odr0_NB5&8#9H8-32&IY#1(J{U8Y#`G4Hmq+ zRs6e4vewzcN3Q?O?f178DFO0@Ulmw6Vq+4<3syk_^y7}-!Eh41(6Ar$3M@_rDdF#M zhO2UfTXTjQwLvMWBmhnVyHV-J{uX+6pk(6Ra~rMad^(RA-P~-?k6L4HR!HyA>>AQf zBzi?cgpCJ2la`e9P6&pN3xibAup1krU`aU{A`}KNQdjgIFd^r6Knq_7=t^KX8?tx? z5Dd8`ItP2A1(x^#jejsc>(ehKaaTHBsTZi|_(Hwmk&-Fa{dMCY)>$wJZyZGA$Vq=> zihtyKDMPP{a(BK5ZWF*=56;F*$nmj&WM;P{?tjC48#^sw=IJtdR2mH;j-KHtd9DKT z-Sb)sAbx->EEE-r5 zN8sc+LB;8v`^J$CDmv;X;4q1a9_b}hsTEu948Mi{9eTTH#)*R zp>?R!maxR}d0rGwL`prOam&t(t%iB7YHgO{B3EQ`ARIVl@(h3@Grurk?adrB8jL3& z|9}1o7j8xz4OT(}?KMRw|9g~jCRpW9hrV@jnq56%#5gVJ92Xmsb)0rdII5iZ9iYTcEWLf=g@s_@mS4=o83$R|y zS;yF|s}d@(lurMOb%z@dV_t#`*AIPN&29agGsnm>dW@BU;$v}bNw)G$Mx-3-mWC*lGKaOQs9-^|K;;IaNNfH z=9xE}W<5@MYtlW4j1|K{FeDZ_dKk`Xet!&Qj60%4-@#uP79m5oe`rl=X}=Fdh~Hd) z^`rZvVt3-pSdaDt1wD`F+LVPp4iz;sqDx&7(Cp^ge>!XnHrVZ%`bT zitWHAM^hVS!SRTrOW6Yv64eQ63O=l-Y~Jls4Kq1{pi_N+sl%JHxl77OuJt=oP`gPr zkCX;hhiwJlu)oi9=a5PvbYz@xf&O*GSh1Nc3xNjL@@Pj=cOli7qtgZt&JObYr>?Dj_mjA&+fzdH)P4s zI>mXg$+F_fgXMpCJ~cLYJ%el?ay_;b)*4T@>RXpR26}#lExx#;6&nG)%4YC_5rD&u zbSYk9?6TmeH^P%G2(k3oRw1_E>&@4y+vv|@(P(Rl22}GtLVl+ z^3`AX+*=_dM*cC!X7<5z*0c}Wbn`n^Pp%9cf2XH$4!ZE^cU3J!0Jr~P&`Hqr+vH)H z<4~lUnU%D@FQ*F+jmN;nxoE{D#o`76O2{{;Ohqg|wNxn_@s^+K-OlwfPq@y$op24*8!&7%Y;(Jt-n zk%V`UtO^R`dQi*Z>sy_T8Wx1c07CDXb*gQ9Ov~jVV&+$A2cy=_+ruTXi?=(Hl`2i9 z$2$CY8B+!FYO@tW9Km<>G@2;+;4^aXnXP)nactrOh^s_d66v=f>3)5=wn_cvvX@z* zsG7pQzS*!NfZZuGtGw3rM^;jmZd?ERK7kX!C8JY1){u z{A;!aSX?1rQITthG*#kgM9AABcxEz(|K-iw}P4`ya?+ zYTVF%NeVNaQMQz)ZR!ExaM?T%JR`gf{*8H`=kKmUW+3>r4uv0;I~agv+tN!L>(F9Gy|V97g4| zb8ajNrOw$z#_vw3<3?6_aSCl8zKS z42p^8y6I=VX=qoia7<&MOR(}zwTZNE49|ln*|eDf@)@={Qe=k&AQfuocxRWS31#{! zY+T!1c3!L{bY^#t3J_$9-!2>zWIx3mtdO40Eg52t<#vp-C=)^g_GFNdW-6N#YLrxC zgl(wed);#YQqGg!9r1xRz87lO)!`kLU3^;)}P6uO;MV0d(hO?U3!NGpSuRNaCo_mC}0{4vY=5usn^T z=t2HaC^dLWq7wSrPsxCT^a1^%x03tJQbdeXA)4;VUtHVcS{!5($BvrjbQ?! z0u^sjVZU(g*k&9strH@wKpQ$fhED}g7eN;%09mP>Q|b&jWp<2$0%H80B!SR8L_m?o zRk{l$NuOY5#of1pq8M~8P4wkku5aaUZ(Ba`jN#s>zg8YDC!wKeeU+UR5R zkk#ZV3$#2WRi6M&G8eKVYMEtiw2g%|%w7b?o8Pi~Ku~t)8Dv689p+(|^z{dKRL=%0 zoZmI?p4FzkqRa2ihMgE!&YYaUS(g}jINltk#PIneD|JpmUf;6Z*=qsutpynkDk)=v z{7+n6f?^D_!7kdC*dz-@r}rt;rp9aLw|&%1f1!%Hb__Up zv!>uWF*bI!$TA{Ffm=gz$5qoMJtE}XdBb_LZ@24DwqwViKK-P)HDZ%=29r;u$Waba zZciu#+G)G6R@K8x7uy$ZZW|(XG;<{Nw=zE z2X9wD))3PDy~%g(yBr|^NLl*5Iyk^AsnmFv<)QHe?%II#W}F?vNobfuNj!%C!5ulZ zG02lV-LQY=5Q*!g*Nibc-e|$J9!8*#U*herCquKm=3esnctv<7W|Z57-V*ukc-NKh zYt|NbmK@LMb#F4Yrk+L7eIv_{r8AMQ=hD|2Nc@6}3p0F+K^+tlclKYJ$>_oThaQE^ zV-}jRq`Or?Z|PG|C*H#f^n5SPvoSa0gFmEBXuP(M{k0N%hlq)#FNY)3;YcX+pGq6+_;T&` zHr@zD&)Z{`VWVgYkl9$=QM~gN@R!rIQ3w!k`%BiSebn>2*p;fj=7AR}eo$7k z-;3XgJgKxSHMqK}7-6O!MY?eiTr>OpQarMV6^KuqUnCi2-Srv^JGgic>7O+$CI28XGs?nSFg{3m&?ud(v9BfuO zkn?VyAoGZ5^TNP;H0|a_YfC{1BMf8;5W-ezAI-fe2?0OhyhA>^Sf7YWQlu0ITUr-` zj7dg$t(0CSMexzl1wEBn0gw(3E4896OMp6BiPR`xp#Ok8mZQ2V<58A+bBTKWlWzRw z8PTrkk-OBl=hSj{E}T^{TV8fMW=-YpIbWe0Q}qbYamz%Eqim46T+^B8ueOd=SYNV6 zAWh5ENik_xH+RhRSOWCwV44U3Ui&6|oSoNTb&w#rV|uRCEoEDyWXZ0hJ^vZy!pkFS zH#{?Z60-b)y~|ao>z0Ntlc&CX^Z8Ff3r(hE=jNVl&mEE1P~n`30eOl+M3Ke3d;SE6 z@$?d+p5wQ?HEXC>)g=ocUz}#wqMv+T{!s6<8z)-nS)S%$edxoq@dil3ig?Ixg8VSa zJKppXVD5h>RMr6x798^(ZMU_vE*xeHQ1u1xZi9sBE}lo^9?OXgA6v1ISHeTYPLvGPv{uyRS*UvF+a^iFq{&`g>m%MY6q zHZ$sg2zNn~!+6bUuxmOYrP!IO&<)DLxfrKBt`?2Oq|#D$9!HmUujVQ$xwuL_)c(zj zUa8{9F2tyob5ZoX0hiASC_c2WhPINyl&ytV+3{q&7zK=C*z1tFjFH9lE$Ikyau64n zT6lS8UNL7IB?>C85Ur|XRxMdWZXN*(EfaF#x%ZMpK?a2}s+Gap2HG?j?@Y!ge1(ga zr^BnNIG3ud8902$qWNtVgX^pT1MI;rkY@qY#T6a&)G->!>{?uHwbck5B+Y4rLxaY8 ztG3&`l~~0Ln{xN?l6XOIbw07;SS4TO_3Zx`SL%hMBmSJ7?;53 zHuwYC^u=IWJ=%C7uO?%rWcg(qs# z@-pr5;v{HeKcs?q^~`fJc!6fT0NH4>6*&0A5@Uuu={V9j5R zkyOY9%hJ=;7R9l1TDg|YU*9R%Eh=!{yuJJsMQ)Q*WWL0PHU)W!4%r=0$HtB zqVq)oN?=2Nr2U)hqe&tWXk*jas_WjZQg4f!L)*Ji*O?8z>EF+mrd-D|j^3(?b6|MX zsioGYOIJ;|+qET6)?{!FIA>9fs_Vsc&oe8AUAfD+O!AGpq${cZvO9Um%~>B_2I|gJ z`b%$pEdhV}6z1)0w*H9|=D(n-KZ`X2Z|*&9BWg9anu4Y=jDKo{J{DkGCP)ltWNukD zStaD4<%qqm_2A!wc~n_&G|3?uhpOzz1Q}`c3f_!c zKXA~dr*UmyG<}@B2=Ef+ULElYIKx=|$R)SHdV}k|+il4hIxsS<=9n*gorbWhk-SbI zDcaHaQbYmHQlTKZqn|PLl%suUO6Lj!d^s~i-(kFNw4$ANHIkSAQ~c|9!}xfup)ysql})Q$dBiHgv*vJQ1O`!^66 zSPlyg5jF!IiHmc|7dn28KM+6I7y(3(^&>qMqZlAgU7-)Xhfxb$u)F2>dpLI)GcI2H z`U!RM2*`kO(QGyzLjt8&@^e_7tz?vvtYX&EK=ki{9HCC;88Vy*j$$3)tcb}5X7K5P z5i*%mAOSph=f#BvpF3h+<#TI!BTayKr%;uNV!#$9%&tDV!~5mVmJ!c@x03y=2gHu? zK2H=qng02~u-GL`wu2)bt4a&E{OmT@BX5J>^q6IlhMx(W}-Aecrrq~!5cxGGAJZR zFo(52^prfAdbB@VfzQv|^P%v%e{_QCY9v;f>SX;+ApnlSd}%?ggQZHMqd%KlCj8nR{rD<0j01+u>^AsZEH1B``nTU*P7&YbLjG<%vc+KCsj02v!uzLPMxOBI;M}W`KAc44$$K?5VR&nhPm|V&r)ukYpxdg=AXkZ zBk^z=>^x)9hX)Y_7~+@>XCCSQm0Z!@oKYu%Q<*Ss3PNwbM=0r*ke7%cfcSYEalCMN zlQC>ag9#og-+hPiIYLingH%HvAZi}?W?=u5#p9QTF|^rfqZ64MI3ZDBJiR%q zKHyy+>U8Y%rTSc$k=H0HTwpTC)x{AvZ0Ffu8Humg`?8E6JYB4lPh|kl?*LflQ=-#y z{CQxg{vM}9_%vzIa_+GN17^)WxYrd)*kl@X66h5{5ANEH3wly$*ZcAGYpyqUCZgzo)sMDd+OqNpOqDMmy>ZFoklS%$%DGXj#%=`MQFOh*uVQVN8)E#nAgwnhQd2F5=&0Wxy_6iX=8&CP?pm z8t8a*tzBr1rYW&y>z6J_2js}RV-BGFXw0M~rqE!@gZyw#8X?(RocpWuI0Z{1LIe#7W8E}sj0XmWXk_ZWuP0qRUoa0I&OyFnf1_bGLK zxr%*y(%+7_Zv%Mp+<#MvE>NJ%BEc;rgy!+HXiE`&K9z|$o$~X{!B3GQuoK@|=lh>^ z)R_J!xeRFX(9`S~5=gZBhtCe&nE_vNC=XO|bMW~hB4spAk|xT0yHm2?V=r~{?`)5A zdgQo|Q-#eD#ZbD;U!8kTD@6^Tsds=QeFaJF^`RZKI?(n41WUFEBf^FikDg(`O=^l4 zP~BT@2Mxs0`iUqPL7AYjdla!Qf;MZoixP*5BKcN01KG@*9KD1p&Ls;+=paxk?k9%eY6xu=V|naV z-kNI5$I)kGWkojDMb_6XjvwE;{pyuCE)SE&k*q(lKeK_okLdq?{Ji-4&)UTyCV7?bjF)Z9^Vw&6U9R&-UvS#Mq1otj-6Vj1Qh zXh8wKW^4aZW|qvL%IjY-qfDr!*Fdgk)|;79Yt2S8RcFQERyE65=5zo!^I$Og^t}u6 zW(rVDo|(FzK4X`Hl;jZs6Rbt3qqmd3z7z5s^m~@{@n+}HqWTSgGXt{p+FC<5l-r%0 zg^y`IQv_FPJ7pIBt-0i(gEtlRt%T}w3YXf6q=8_Lq9*3Rp*N4h(Zz5Qg>s6J2T``w ztbeBS_Wq+zyuBnbo+2!v`{HiiCC%UDiFhly$nYN`eSB%h}4zv2SU#C8Mge;5lBCS~jhpANdttu|_Poyz4P;O1&6N}`Be-Pxju!FKQ^ zSm&Y7Bv+I>2!;)?r;3Fjb@y3<&N~2=3-16>9jOc_;RO8}*um-4GpYepB)WNOA~{ah z;(4)k_7ACZyMJK-%1e^;py+lO8;bw79(oljSV*lHf5=o)F12gMf zDnbb5{2Kr7A-2()NM&WsBo?91Tx$!d>$4EAIsMUd z_tH|aq66c~_e%2<0zv6!w994@3N4S^e_O#T{ASTml}EVXo=oFn&x$5PC6X$3S5C%f zJs3l=Z(~zhJDFUA>Rrjt&zIz>|NN!S-+?Xd)ZeBBACUEr2de`JLnwE53n@v{T z>w*SOYWMk_ulIgZP_R?60jjjC4uDFCR0)o%zPTLNbUqkdH5s|U=Z0v*Xr5bW6@{gJ4{k@}Y-Z!o9`v=xsikVs7Z zwv$|a?n)^KDM<%8hOv^@uAX=JUSK6j*1b00QJ=pwTzE+;&WBE#V)gab+eKjFy?%e} zl>GQx(}F3L4tr|&v3{pa`7CkuM`XPpEsbDtz^!L$?OI`NAlm;-PPWo#yvlt1Rv*q| zR?ZZvgm(GyQM=`O9{k&(LO8VmJc2A#q455o zr9M%LHRcG5St?Z0=n>~lOJ`H`rWARqIPU1R;TD<>}MGu z6p4QQDv3uC_|RlRGRlm5*k!fEXz4(Zq2o}Lgp79^0Ef~$IRvCMUMhy zqpY8?W|sW-gYu~6LaK%I_y>Vcmt3^m@~-p$1yp>MoRQ<|J~7|@cv+?WH-_MBQy z{&ZH51eYsVy}ycSi0qlho#^2d_f6w~RP?9{{E0cI-ybB*mf%*TQ>^dW7nHd^5@g7y z%iJNBeyOTDWxQ?!LUDmrbAwe2tkup+;kbpZO&_e~fR$YpK$Zq5j0gEHu0oSraEJ;U zpaWuSM*vku8_zEeOv}WjZxj%q=;GYEvbm~~$Y5>W-Z`o?4tSXPdb`zf{wTG_$Z>W| z4vMl&9B_%TtRv|2M~ua*_FX=?;rA?imr!J;CI7&G^#ttQ@^S(UDwf9-MWYUzX!gnN z`=nocuCf&7+}Efxav&=%!a0dAE4nI3qL021Akh27eDtLEy~f@8&F1gHI6gVpZ$ z)RbqT-{ymKu+)WP{+ao^jqZ+GGgqB=5(IW3P6guTVsZ)Dwo*8#bfc7O9)%yo40bmf zvenSk2Hp76Bp+%DeRxb3Dy|J63FybL8WLFh>4(DA8pv7K!|@I8i%s9mTHJQdL?&%g zzwV2R>@7mTiTmmjU$+zh6$0JIllkH1w0Ba&45))T;SpDov6`$2+D202&C!{G7`b@I z{d8Sz^@fiT*7Yp)kJYK~o;u!%PU>xmic);-vH9=vVE?O8VX8iSJ+HD7Ms9`@&{W36 zRL@ZI(u;!u8+V?FH+Kiry9Bo?q}D^6?|fYgI=^{+dTPl;uXTlrIxB1cTIaXLs%DnESXymm4 zsgG4%--zvyK$tN8j{X`uHtl4 z+M5G|@)@0c6T*FHuB?@#-Cld`Yn?u`bypLFmMVy%Anb$&xP29JWiMnVL<_u}T@W`3 zbe*~pH-Gokk@@T0zDEmsr@U~|1l99ypN`4B*$(oVA9LZPoO@_1Uf!&VfJ%1?&iuVjkC!UPyIhkd67>9PM~#jlHOLZ~t&~K> zrn_c!w??@-BSk*rPwi$IBD1$-v%gRvL7v&i(Pw%Gyn?H^)#R-?pP0hvC^m)YVG-p+ zOUye5_0P&l7KP@JVFGJ8zLZFcXs)PduCA`wUp;K@P;M71=Iv@I9tTOqMUBXVRTmK+ zOyQ4My>e4-?e>e=_|UVm`D}W4%aF*TMXnM(`_(sH5u)PR-u#=>2i(Vrx`!=YUIe)T zZFYEn6n@EEjvc4XfO()5|0~OjI2y|ez{J6wI9+AI5&O$k*{u|;$Qt3 zdU?r#rEcxuG5VC*VFP# zKQU3*%*Gu5liUMiU`5lx~~i@w$}svv?>djbXs5 zwtwVx)%sdavxUWJJjjq)FM)@j)XO-#f*95*;s7!Ek9lIsuDlz*Vy=DpgY_g!@%J8>$M!Xb3Rk?V&JgrAnEH-JuxrW`1Qzzw z|Kwc#H*^tN;gSZ>IXKCDn5ZlO@uby#wpK_NYkKuL_74Ow#)H(E4emd=FS?YO$6(!` zHaO?jZ#27@86v!JWkSV}jn8ypwFU;7==em~pTXnknWuv&Go^k^x%rc#V`W zt~r5Ltxy3$u`46qDKxLOrZzO+&uRD$;bBfdeBJnxZ#DTv@WIJ>xSIM1Tr(L*R|o-8 ztJ;eoO@%2ULyAt0FAsTp+t5p-9uQIGx44tlK&NW1aRJ~^{8ea$;070+OooNqm>Ae1 zoAcXSBV13`bo^ttk`3XtJqK-noz8P=f?DzCUo-4iI60*cM-`yCZwO#FigDtHvY*-)> z@#dXtr>@52vf-zW&d>QBdxlk(G4cB<#U3D25FG+Xv(LnVX=zM(cbjbZ%!~K^BQ{uOK?21Gm7?6`$N-5Q1cosMy$ne10Ar2vZ@raZj82jEZMhOQIV+@d?ebGLu zRq%QpGR)&XqDssfA{6;C2;86PCKa!zLMr{Sf~*_rIq3o!x;6yZwh9o>J;Lx!3JfnE z9WFmJ%)K;Fy}@5;-ls}KI_E^lp@CnSaUhx-ww4L|Y=3cVCp=YDA0jqnS z0D7JnPuWTIq7y1W!ke_)h`N3OCgPR4mT$PvGImt&Pp8hG_V?%<@ejIWOYW|S^2IE# z8buP(>&hvuk}eka+BWZTGGZ}CTjC3Ws$E z+jZ*}Tl_JI|4=czRJQR*xV=r&?Ppbrv9K;CJ;;NM(iFIKg!K6Q@6V8bQzj zS+}}P2Q@1xr+9wvu9%pN{zJIvZB;<*G@dw;H1MO=fKYvcx;dTj+k;m6U&`Co;D zY`^J0_@gfXAAO`D%{e=95x1DQAI6o$Ju;F??hM!zsso?6QlGML@13+@u?`{w&jm3q zb1JldI$^hL{4-V6Vr*$_<6-L7?1Nnp;gMPXoShlS&dk-ee$ctf*HFS~MK^7w_-7l< z7PDTiGg6y1++N%8rY zra`;=GP@96(UZ%WcP*o&_wn<#$D|jAi%-cD!+V#hD`6)~kv`~Scak25DITc#Y(Dw1 z^w{E&J*QLcK`fLITk|1#)zI_NnUja2q8eOm&7SFbWVUHKj4N{EIAD|)I!gD#-}O)z zwK*psm`C%P7U=C`1@uV!CElRRIS@IzlYGHw-w4&gB1;Mh2_1vfrojbcygl>bGYi7^R^MaeB9dgjeirJl16nJVW-wAAM~ls*%_ z{q)1;^HazTLA1s2N@m%-Rl*Hq8X5J8W$ryz#}(v9bmF_O0z+>1K$SXfb={es2&@>nqhMg$%c zq4IL@^JdEXvFb8x*^6M6n*^x50%-V9SMB{J9S3vWyN7(~zmFsV@)#HNrMVi?C81)owE?s%?=Hkzs7?booY>8}-iDII$xIAs1i4O@V7{Vx*(ONIsF9evQ>IZ79v zNxNX{5_T2Ih6Z4@KOOH9_-D4K)ciIZ#B((ms7D_tfBynXW+y}%EjxdDh#6@9k0s8f z9O3oC8E@bc_Rxu=+`Y+zt%d*!TA%GtD__CyO$agGP@)TPtDo@TWD?hJIpwtDM}JB0 zmj(E%9fV|k0#&_j^SPH8en4x913p7P_P0yxGeKA!@BF{-8X#2cWzvaz6)#n-Q!EuE zale%O4=1z2QKL^gE-JX5eb1}b@<5$aih=mkOyka@?PbQ@!XDL_g>kmvRqXFFw4e7i z&kN-x#WVpS@%)nbU%yMZu%yWE01{2T$k9tUC${+og_r(MFS*1StX5W4*VJ-K5o!Rm zev>}XS`Reqm$#xNvAoJXGJXC1yh8`Pd{`Ck|J~S*jo+VO@^Q_~&WelRIHC#0O1rJD zL6WamMp;I_;%e0mD!TOl=_Ps8EzZQYy>)M|7VXRE*&OIs=9S53?q*O6x-*c1s5nxP z7ns+AM>1Dw-Xh<2iyeO5QjY)bxr#~N0IQznnbKmYSLswwi=F2FUQ}=YC#X0?iEdNH z8l{h2C1g1z^=$i7C6yE`O40t*TxYgM)Xr-KziHwQF=BJJd}peXG#;BTR&e@W+N~38 zS`4YC4+2et*I!4&dL#wuQpwi=&Kezkg1o&-fef|poJc%1Hxy%}nKNMvuj}gcx~O3C zLED!rCs*CJ!E*XQE->BqR(qBh54$h`%H?t8M1@GfYTj9m?vRAJ+dtghOEcu9od&M{ zCusYHyt-F;!>2_MT;*_bQwJrMtg1aFe$aNMu18OTj$VlsT{h zy^f5z(zRQjxMQ2|_jrE7O2!M{U+Ju*!i2aUzN5ExT+^$>)8MTer%CkVvnN-A_IEym zxV|)4f)JuvF19GaOr?1T?OgmR%49BXTqtVzo3}8E&ct~FJEIS|q>omuWmyR4O{YjW zgrH)M%)hZnQ%}!?@T02OPyO_~(S*ZoEr~N=6}A&o$mUcy3#zTLFXV|P;_dXZyN7Fw z;|06|N&*f*w3DS%M~N?LhPNnYGVT$2CxwNZSuZOIX?awHwkLkn!XrNs;E`sNLp{@Z zCoe(7OG5qXo3G?3T)}8_qGJ~wlxFE(gkEsPN)>rRSR0Dt^dSI9`>xwxim5z4zQwQ> z%v{F`MsQEoOs(N{#ls9`eYCKCTt!FJSuwNh4maPVp^lJj%lFII*B*!MmLvXGalkI} z2aR~x)3Ue_x!-FzOOBfMR-^n^wyDot-``+1MPFwJbXNU7qy+h@S|BJdIpVKk%x+*d zW8ypOoo$n!eL92tlt7xoNa9C@eX?INjH%Q2dAU~a{&5)Kelu5Y%OBeO&P#@{9;b#r z;ArKjlGj-6S)3kk&$Ly0T{{x6s(y1G%I_XW)_?z@-zM+dGn?8gzv8HZ3iS`z{myyDiv#yKfmLDiag3!$avd->f()k!;kGZY-$A{;oaM3dXJ$_ zcqR$VzMw#as~{Oy3Dm3ZZ>slSw%3~Ty{aUzwu5_A{Po{EJq|p7jDH()`ed&PqCMzU zi{^+Sb#2Lj9X)m-@oAr)%)WX>p7qPmIN0$&-`=q8)9h&K_xiuG&O~#iE}i?@oMw}6 zA^ZJ9Tm0JM5gxZ4V?1Sr(&VLVPQOa^Y72MSo*g1M6h$e*NDXtIK~3=m)7X zNzTL4t#?7*X!CEsGp|H!U#6>))60%zLCTr8FYatfwlsM=_6Yah~rZ*xnmqkIX0tV|=h$L;1VLYGMU_+*_{#IS`{%d5k*A=ns#p)k_ z{7vR3MjgE#smU1>>d)9X$2!Lf-XQH5J3SpQ42dre8<|25$X>bFQ&g${ch|Nu&$jYc ze7RHnrX*MIN@Ir><@iZ8C@Ock$lb2(#HDvnaVyKs|NcMr-ZG%62mb#(XTfMjw~Q{) z(IDaIkeCS4Fd7LR-7-e^=!VfD4N{_x4pC7QK@kZ-#6lFr$sFPfl?fvL^Ws9_Sym-=iVU;Bzn}UwW zWM1`;xW_}kIBtbDww~TTG_@;SRxG(`{!!*W8&CPJTSqce?XT&!6`yeqg)ligR?!Dn zqu&O{71;!Q?KSOq7<_yyjj6*=5x;tggzY0~eVU4HefjcSxH)nq?d%y@$8M{l-hnV_ ze_KS4=E4))-6~17Xuh>Y3#q2;Pc*>=x14rWY(gw=Qn=zd5-3{QjxdbM6WD z2av=s6xw6i7~yTvapcNae|BU~0CuIKd|t83+TUDHhsUL5<~42Gmu=of z(l_Hh#|8a<#&P~pip;e2>Qx&7=Yv9Sbm={jdN zM^9$kSDHj$U0P(0nV5Ri)@Izn>t)18(0qQ-7x8Cp?mcs8&bgzm#(jmr8?R;+?jg9t z1wVUMl&|e-4;IF>51)p;s|8VYD(&hafk_W-*S~-28Sd`+5c};sQS{K=aft!1ZseFq z+`#Z~%Z&K3S}k)wP-*1_|GuScpW$5v-C!JSbapbvQ92NRL4@)e<+JyS{(zQo! z9emAjE5?)9|JJcFWlXeHIKO3hsJi^5Bg{XzD)+bJFGQ$(ScMQfHw)*;`cY11a&@DG ze`@$EpF5w$Zw70}5?k~wO)cXxLO))y-9tcfH-;}f67)a56Ijmdb@iru@?j5r$5!j) z`|#E}L!-tNT>X3c^y!uM;eg=>{H(v8xT-$n*3hC$zc!wc{`z3_ouJ$r@8$I3P*?_S zoLqp=T4??L_u{#%)AmSu@w$6kK9Bzi72V+9eRaI~DSa-L%9ZnPfn~9@$2=E*{BI}b z{(##ZS6tl-LVl(Ud08@MRmaop_}lj1hel5PPlc6r7wM zA-A+Ei71UZs~W?);`69ktaMo;a`{XX$%DVe57HvGN#r6G2d#|Tiu)29CFQ;b`6P1* z54|N)IiEYW-Y`+UT^mnz+QbV6=)QX0M_fs0wd-HMU0BB^Dkmi|sU}n-oy}=6Si8_- zZk9_|lSOEmZHG?7txD;J;UYQ;j;_X0Uw=e}*%*<+l6=y_B-OZrCzHoFuic2e4w?1! zJ+gL8NsKtT8S7<4(o3ayq{gq{uNF8$X*5eQ#MGe#rfoS3jAGcyja;7O>LWM7%_O8x zT1i^E`;IXa4ff_qI_n;DCz8Qn1=X>g-b9;mNhO2zscTnc#%IEf-W9ffs>XyCEGR|r zQl#z1GIgYAr)@YDBvXowvjh-S9Oe}vBoRN5wJ;mR+nw6O!RDaMLN%G3mo%~olI-^u zs@l!A9ZD4?fvLrp9(w1v(&os3F*Ub?KHCw6AX(o^9ga?tr+1i)baQ|6B%Le+;QQ>l zZ5Z7CG#gPyT9CTHxJnWukXY<92@NoIlf2jXysjY@zMmNceUe~QI-EVfMlD|~D$NZ* z7DVL7moi9F^5gAbafpJTBS7URkf9g>d^J-sDM-N=V16olBr#wY4Ke8jHA66|phBZo zHQL+xnLxhlM4|Ef0=e%j7)0pR;UcHiBA1^NzuoJ{)#}ebs}Fc<4%KVE+t(aN)tr>o z{2H$Lvs&}-XAQtdhFl=S9LO}$WZH5v{Ro-yC7Jmb8Oc}6c7dAotL2KWG|WQ&(!Jp@Z0yJUL-R7UG&c-DMCk&Q9hQ>JcoaPm`!%;J11c?SZG8C5SRYVwSeQ+ApDdAuhxNCxc^DRz zTNJPHUaJvJ~cWK+V1#EW0@Ayr`3reE*#Gs_23m z(W)ox8EdA-b>iZwUSc+Fg0}@0xfQ7%UHDe&*yJf2B1$a}fsnFFeI07+&E}o;N}0NY zG5)9GT~-2<5>nf>FE zkWc<6Vt8;m$@knQOP^UHwvhezR?NY~sYNWS`^aUCPDIqg9_AL)q(I*TrM{0=3$*gs`=Dzb+xYFrh zuXXo(q(Gxlmg{Yo(H;x&c5*-HEMElvSjsWWo<*1{Z6u-oCi}XaRV>qBsXf@g^=-B4 znTTgf1(tS+%3t$ zV_qL&*Iv`1(k`~V&-Jsv!k%r% zo(IravffAlSgg<~P-ChF1xI1<#zJ`ujbjHzlVBGIGq^`4(*6Yz`nCpJ^3C<5u3s6a zRsJ!`Zj~Fawrvhv0s#R41EZfM!mLpQZX_Au>q%i0!+~c#fu#IIK{%@pq~%GPYwZS3 z%Y`;UleA%18o8$b%;VzSPv@egte2AeBZaI(SrLk(A%?Z#2`$Fc%+Vy9}-kh z01C>Vy%nN8NCovV5Ne{^h?w86lV+KgqPA1=eP!$}{>oJb4?2X9(JT#?DLTBqTIBxH zCA$U~T$^l={<&SQYXBsQ&oYi%)?(~cn< z3JG9neCa+p%J^B3cdeRm^c_#6Ajm12Zt)R89%}3fBB@l2JE64-d>^j5FK+E4%hVa# z%rAe&a||Kh-Rw8`;Pn}_4y`r`V8kM^t3<5pK#>EqL23259OA6=kOc-}RGJVz{9vQ`m;gXYz^SPg*5&n<1opia^}}M=8f0Sd z46ohUgul;cWRPE61?Zk~RAgRWlejU7W3hz)>LI!R>J)=5n@# z3*#c(rG2>x2u!h)E3Fy<_N_dy@cb)RbNjMK_RRfH@MJ)U5df`<2*AFK_vd>XKxeXC z`9nuZ6@Rrsu9QCWDUgKuQgXe$rzMb;S6qee*Rzo+9eR#zK%YV93Bz@zM0IJ9?oY_m z+T>o2vY7cl#N)d`H;tO#Gk9nekU>)d%6sng$j4fPzh4cR083ijzgiGQ!#La1KKL6~ zU}XbpQj~pb-ojMw?7!fCGLu^H#~p(x5nbjBJ69(7%IDRqJ~hl3=#Bk!)#wE9UQ!9RIvsP1?7fu&`} z#=OF3t}cGc*VoHyyPq1*8PsWd$#&B1V^}nlgQ&8l+|lRjT)OQ=)eba-9{|dlGvVfU%W~({i>08Usv!go$e?M4O8ml@T}Xez+HMMt}6N!wtGJp|u)x;~x!Z1r{J^aDX0?D53^4!4f5CVN|yY1aAg0 zig}@GqKF1K7b9i5;p-9drVXc2%P=-=S*GgKY;-R9L*Nx5jc(we46Q!1=gwR@!()mOh6RI>u7ZWOVEfg>U zmbsxu-4H|RL{35>6o6q!P(2L9!B@lPik9O<0rDhnxh{&A0!K&_oWsKzyGyg?PJt3T z@H|i^k4^FSEJ{e{D&y9Q0!WnbC+-zok?(qtO9y;iRww^9jbuhMy$8K_g*)P*mTA}1Jy*L*LhU~ zewEa^xfHu@xHcJ*o?hPNoz95{sBRY1_vO#8g8kC4UXyBC9DpXnw-R;Jk}j8fc`fO) z?tWMD#yfj{ubN)H(KSetjWpCky1hS$vh1yqSB0O?7XS@G&zJX<{9YP>MVp-Eb>qBN zrb7pelw4Yh@;f*#+MO+vU*V(YxLZ)vZhO z`z@a7?B$oR8xsI+l>4SKJ5VvC*m^}&F;-n!jFd~Y7)9C>F{tW~KTG@R>Y%uk3-nk& zMPu!$x+l`gKU*%E;G3TxL$32C`pTsN$hQPGWPX}A*>o6XmV5mQF$ zw=TSF*GMf03(1wl!h=bJz8aD-rnOtX&)5_$n-MrN3nZv zWPqYL?$3x)Zh8CD0^^(83Lg^`UB0P7t$ARHJmX3r3RfYVmR2@W@`I=6C^8vKph4Ub zI2h}aOMoH?5Cv4|X&Fop=;>R6^vp*BYET50{COW|w$ZzfyJp}QDQ0zjY1;>BbP+by zM~p~TQCE~ry8X<$_JB3}zIQxNTV^ERDU>RsqQO;MwuAq((f(%WW#6alyj_vfYHemy z*`Wfn@*nuCQu5o|MD~ue8L4s~=)0Fug+X}XWv;;B3fjLxEU8f)S8*N(Y90s_2PO6; zL+<)#B1sTZcz)l7v=Eat&zD03Q6)^)uzY{z{P_wCEMQN76{`i49aY7UM9)hQsx(NK zgloDJSX9Q$_>Sz3sIMNrI7MGw#H}}D;{Qxf{Gv;Eznud?o`;2Tb&&O=@?44{ zSfXUM4YZqP|G5URQzckXJIfYvK!GxTCoJ0}40!z3MEIK9ldHw+>EVfKfbm?GLRuwT zIDjTWHs^aJzm3mcZN1Fj;Z;!*p$PLSfr-TC$}d6Al0&6pncpi9Vz~8o3cJ8tx)a7d zSQ1oi)ESBc^_&!(eos6W16L(Mh3*s>jR_aVCe_<2)v&s=6~ej!l~_cG5V#Dz`%Mc3 zEEX~9Wm9VJr?OP3H%mZlW6V--`c*iYkTLzM9@gX4^?8a_Cc~vnrdfs^h{MC}HwZLtOM0vHQ3w$o@DCp+y$juVaD*`}Y z1C*jp3l@Lf^~v=0vnL<=s*7Q#-FKT0{FoV|HKLI2QJU@?TUU%tRrRJo7Y!PFG_)w` ze%T}>Y*N*F=mDhMIg) zE^3P${)_vJZjPu~kCGd1Vs1t#nDa5@(TnEzXdqxeb)Uz@7zbrTgY+nf^W=OmciO`5 zQVbSu<*4dH&b^dvDPLs~q~-tKkvU)&5cXca8sTDf)u{JFg*R&;D;nA?`vQ`E`pEMS zgq;GtpcQU>8%|oTQb-H8tum_$g->XdOJNqMa-cIPbMC+PNa~Q&oo;dsutDCwAvZA7 zG`Ic=(l!OrP+eLx1muz6E;Y!Bd`y{o!FuH~>I!^G(fVZ7t!;P4qS3=eY8)D)VbJZS z7aVK10eUQ2PA}wecHiikb|~ndAgZv6Ag`zRyZt(jjTn9zp$Ea>QaAysXZvZloIzNX zS%08v??Y!Zisi@!=8I7g$-@orj=)LtbAe%HY0ZE!)+F$ObI3zg>Yri(K-mu9GURm8 zW(K8W0@2)xd4&75hiW%<%?@DOk{=?<)a&D_vYjV)eXp1XVx-su#`R#6wYPD-MB{Oxi`cKk8$Zk2u(nRSS z7&#cx4G%iwt~JY$+2~p8$rU&0{|K@*ZXkkoT62ARNg)Mdk4|Jf7p04bv*RG753bfN z7n!~%x7x(~>t7;D$QON789A#8yVr_BmeFEOKEDr7k3G%*Y!9j~Lx04nH~h0cjGWR# z+Zf?MV8>wQ2V+My%X=RMb|0VKn>m#TyW8S-^dF^&;2o%5#C z^Dg_$XQ46X?VpcQZT^gNnQ7dFLNmE{O#{+#XPV?u!Hq8?qxtsf(;gkYZa&-n(iaEt zIWCJ0?6a_a`Ba?R6ZvJ`sLypSK*fDWts5av2v5ifZf_(3FK>uPRs@(Y@(w18RYK{e z_@3#1J2#oAl*|8*Py1WCZfUuF#3Yn`5w5sbEjCk4qj~6gA+hAMS7x!99Huwybs&Er zu&Z=lkXLUSbMz?6X^XzkD)F7zG(4usE%y43Wz#7j*=m^WGJnHA{MQU1LvnWINiGXh z--TKe82VM~6<$tg$w0NwO$;A^zUlw?m$wv*UgE`#H%|L&`7D|= zBFOmBh#zCq`<=|6N>rT`T+U&nPPk9NVeOaj0r>2LEVKOc`A*@z}T z*l&M%|L@R*YQvWbY%29(32Ev06*8Ru{+o=|0?$zXBz{i?a4R`H)qU%Mn zJSy?hq*=az)No7sgXvt7Xb7XU!YA{~fIy3;POXGVsiZ&_K6Y5i{fzzIGMfnD+LgM4 z94>zR+vd{`Wck?0SM{?@GL7FI0lgRhzw+0-e2P|;g|PI*DJVZh+q;0mnS+mzgZ zfzj<338SObHjmg{B3JA_SzL(VV~>Y9b9RU4y8QBNw$+?mQwE@l3jl{Alz^SItu52f zlXs2ZJRuD^JB^iWx#QG|>3?;d0bubEz)!NW>En~=Z_iVM_^9yY=^%<2`7)S+((^&u(Kq)Vu8^hD0((^ob=j~(jj zr!?FvtIbJLSUoOwGyD_}*LPt(`ZH;i9*?8e@1Tc<>#isF^ui+d6^JofZ-J3M&-&ru z(E$;roQCmx{j~|&E2c@N7}4um;<{kkC)90}afIf!7?bz4HQ9iRLts(+s2hA;-u$?#WM7;R#z<_!pte*KsoEUP0 zGCy5_2pr?o7sCGpxuiM;fUB;F%7pyx^l?E-$J|uU2-X(vqH@beiRs#|{c<5{Mti+}W4+ zlc>Tp9Oe)QH)}!YBmBb3?1cWD~UZTu; zT45NQ?a!DF`6NM%@RXzx-*;sGPztLT6Gk(kz`c)NrhixUXjPDc?>&7*SxYgg16aeP zKjE4*jh8aRFF0`-56*d)w-)%U@kuci2{3PBz*CjT98Eh95hM>KZ2e0 zM6U!XLPDDzKGp5XWP&ndyXC4{q6Qpk6dEI7EN35;0e>IAx89qxwCF+({ZFWGpK2 zDg1kr3a@W=Y5z##nYwa-i1}(I1|aEbAs95p<+HK|-N#Ep=Z$sGKtrg_Falj4v`KzX z7^HLB6z20}V?M^Ty3VZLPw=Sqc02+*r<3 zih<$QEkDahTgBFyW?Ifh-C;ajY-RkME|5TH-QCa4lh$(&A7G1$QMCib*jbe6y zeL0MObA6@_l>ZzAr>?}s7)8XBDO>@LS$lp(l7A>A^cm5b|74P#>GBDT3Un?9hpp@% zGMijj_}I>u(@;SRrfGXynEUV9t&jieGqk^b1{K;qSGvS*a=MiB@)_|yf?4h!GnU16 zYF@uFd9mmhVU>QVNJN~$z~mGvX1>y7TZ`n;yYwZ<K*fW@sXnsd^=2ub<6>}iN&w6p8Y>xkH7f15Dg=6~o?^U?5lWalpW zTpKKjY`_MSN6YQ?-lsVra$6I?BHhk=(L0+8&<*;d0|kTnSG)0d>7#BBF*woKs?n_A z$_VR<7K&)dZvsSXNBK(>o%uGhd9OtxACSAQGI#Fw#uM6fI$CrDfj2F;c=$>=`tUX+ z{^m;8(JRh-owu5}s*DX~%YvYy}M9+#cb z_AYncOEAi1qDBVe9-P9=Y+s%UVugsZAQQ@Os@V){Kq~w6O8WK>xKJaK)1X4utM47r z`~S|7xx#9O-~aUIr}6SydDlVvXJkv?o`iNGPx-=9D%nr?jUpa}IO8~9_e`68e0eta zlI`~vQJ3uDlUhD?*O?9-I%A<(fnY+;r~^!{sI%%L|1p&)YScZJL55b{lbcOIM0Vfr zsV1?Uu-KlDPGFf{e9zvy)7N&r2>1t9Wj&a?@UrL9UU#Kg*Ye%{M@fKb_dj%Tsh`N< zO_sZtpmZ#r!Vsgo$(l)lSw?L4E}b=&R~yA932&rC>&%$Yj}+{)RRvp|@KC(Rn4ZSb zzT$rB*c8Dkgq=Dq_@kX^a+e=O{w$K^KxlRY^3Kl(L!-}>!F<72>|4oPc1PT)6&UuY zltj4(6OFbf7Pr2KZ?nt)otEQ-Jc|+@`h0k%nbbnN&5s$JX?DtO$>(_< z`NSVC)6Q6V79xP+)ToC(94`~Zp*(StID)fV91M^^V08sVaN0mXSOViIl6&*m{{#zG za3a^gibpgNg=W>-0lq9%)p3NEWNEx+GE@o=H&C({U%mldfv6&`(NGMmeb|+!qncqX zTau?Y2Mz+?+QytBl#K}vcYY-CE3t}_*a8OGYoBHLdT7dssMswpz+Ein*Tk>I31-Uv)vHX+fL$enGP=S=QEmPhHtmG8$IY8mRRG zJd-siUyiNndwg=YugnWEq^pX9-%OgjTFT2sAPU3Ym>|POL00G{bs?PbZko4o*R;Ja zR}{ddHG?jOlxTOpue8QKg-L zdnVV-rfC+c`$iinLB$It^0K<8r{2peJuPL@eNSgWkn6M0%bQac95_|XN7HDd?Wa-V zf`esu2$J@T8nyP>D=6kL_4L4oLL)ViAH+Nl6jZ!S>t5uQwER?2R!$CbY4%*{jvcf7 zunDO-`);dpk#XkqLGpY$D$WDk8TKMaRoA79iV9n!agf)Soh`({lUZnraD~VW{Q9=g z_72~EFaEW;Vzmi-TvkzMU-IJF#Zpm_ z>gf0jg&5)CsW6v(6jc9;whxc5BztYf9Oui8v_B@yrgd^T-_#tMYZKB~zg**y-hh(C z_c9TTo?Gp@~1Yq)cbixtYs+9Q8`LS8GHH=okrWK{N~AAWH~6MRC_5v~(; zxQtk|VY3Y-7F-9}IHL%4dJeS%Tr_TEFmR+Ppd4yMQtR<(@xnhDD25|oBG>IGgm-oGpd-mgqktWK0BfIbV|ZmCya}=cP;WG|om&rqujLhr z*#TK^?hlOYSi9bCnH_{9Fi;~@J@)~$t*wm?4Z4&|-M23e-3O0FYE)%i&m+%O%(rU$ z`)#J0w&>r4F5(R_?LH& zc+p&O<6K%~GX34WV|O|-TMml*cP0FWabxP)x^F+CWsN1lV;Laal&1bWO(+~V|Lbh3 zY}xd<4wBWqW=cA4+xp>v(&Ap1v z9%0Jm1qzh*2v1+8-msf3N%wzN1h|>rzpl|>3XHz%zJMg~p}O1J+ipE5hQ}UMk$`Yk z;4V?)uKxv)3)R;R^gVcb_V!Di{0ognn;6DjkIi0|=p~t_tUjBmp^sD~K87fWGC&PB zAa`Hg8LiM2BE#HtMj9PC&DsY{1elGpCYP-y_1ZH{G`Zd(d+w?A8sPvgfq^y|JOVA# zfuxERfWF_SQ%k?064-IclDl3}ceCp|3VwNAYQ_iY-24*exC$nTN{F`{O>5!-&Ob0q z44lp^+s3S6eQ`GD4^yV*B$nJmgPjwqAO}~nvu#X?INiAu4MVBQQ_Uq3c+l_c_#KD- zO9Nq2XVdr_lI#1@h+q;PjvzO=`Ol^?UJBx!o2^`!&tei= zge=cMkZ^Cet591q5WA@VvL1t^3O?}NRZe$wa1dpzuG=A^GQZpo^?adBGBQY^cLTcq=V1UJgt}})=E=OPe6$qPL>?WMe5U(zO((*L^ z&|XB1F)~D6kbnqCOA&eTl|wO5_#@|n%)_=1vA`4m+0-mbu=Gf-!1HV>0CW@LMp~pn z!xnKm+CPRADM(%|8hVUwN*-9u`&1;Z>A@u2AaPm5{O;P$Q?9KRdATUPIK!6UG^2!J z$c7T|l|?vTFs}V^4;Y}>ZAME6%ZE@r4!|63n z|D@=WRl64lSshWca5Sn>enNqBCgr35gkq(ij^pK}0!T!hZp$Y0;M0c4UzkL9qOCeB z7Y^du4x&(r0%z)qlFqXeHoLVz!%om^N~}okD@H@{3!2opA(3$1}=67 z*emUo@G%pvURD2T@oKivM%wkPpIbNgLDTla0Z4?8Iz0#*k5@9zI6nZiKPm~MwF{>%roQ`bMv zJgSbm3%L`Vq%8p>m>4_Uc_LV~;W7ws$l7Cm^b~;vHXbSVMxFxtNEm8SVfSY1H&4@! zaX_*DV9n*u=XGRhDDRFAgeo08(dPaA%YYpWAFkit)7tl7>Jj!h$hxqJysTLw>!S{VIh8_i4xG4xK3a1=qh78p(*DpdMHyqk8pZ&JNcab+=vXVGl^@7jyN+UxZt? z($0fiB!`lmr?2Jx>Yx99qPUY>fVxOa%Sj8>Wu&ErK-1WaQ2KmydHDr}RQ-ztD=U{K z(&@j5trN1bF+QFuf-!CB{NEAV+fDWVMQq8yecqB{8PYY+Q7zVEB}@O~@6c2O{|-o<5Vd6}np0J=NRzpjaaDZiPu-6Pi|& z!&BWI;*cgur$ozn;hJxQq;Ok8DQ*iez+-bgd&sC{1goa;CS}Z`$=n&KA5eh$iX z@O=94V%v3Wkj547A?5i7Wst%qUpn@&J^{(2?6AKFeSJPc+reajbX$o;VAb&$Rm1IC8-etRGLG890cf-D7@-tYUOoc%w3aa^H$?4L2rK?xRvSN z7}l0&7B$3goQmXYGjrIN;z8e9PUAVOB`KWgN=rh$2~4)1Mo&okAdeHc4c6D5=ga6X z5|nD_P6qYgqI4MV|D7g;tP8MCFiZ)i3V_fP^n|Xesbm^5!#HA@UcnQ;z=IGVCHku4 zmk``)i-jvD-R*}U-B%mlH?d=jK5vTaH%ewoIQC|0jGdg^#zkqGcwhQ9dTm=LvKXQs z!K`i6UL^~GLoM1wTor+~ zkdkRd=+r?b6hYO5)}To-zhHlAOF!nby);$1<2$$0Q433~fm$dn5};98q;c4r)@$tv zr-rOgnp7-w8eb-6^{f16*v9Dy#Ra&H@epWQvdO}*+j;3yA{l!OXU~aJ>J<$65@G53 zwmOVV!Ux1r&0ra3p?7}~dN70&IgbVH z4m-5*l^rD{dst5TgDt<-taU_YIlDyZWhqb7dj!9TlrpJJE%*O?S1~k%GBPdLFwXjL zicHi(0rHbiX@CR*a)}N()_nV`d_pC6GWR&Eg3`6s^Bp5~^9W|W02Mij%k2Z_{(`s^ z>dV(do>iepGx#hfyM0hx|1Zf}=`jIy0!u>dFDR-zAt!xQgd)elo&9#j$EUB`kBD^a z0GI?CaDZ?R8^*jzXCDLWQd(XBHO^%;dyUXq%tM05A14SN3w>L$-S}q)R@E#LrkP@~lSqtIQmg*? zg^dYLO<(UZkQMDtDW`E7WA2ow%AZ;5*%$oM%`pnO2|>i7b%rEB1(_i*N~X2~rnL)^ zS!25K_`$|EBK0+lXWVJ+()iPqMF<-SV|vfj?dK%&!e{Yus|r602emN-L#e31kBK)h z--uh0rD9M4-xV1cHBrfjj#OKL(CQ`*ZYvv_vSo?9mhv6jRku7%v=cD1G&CM(tHwrI ziB+&!1>X}R-*QPB%G4_lNfONxhNCy8>4$=nUT~&~A}|Rrl1fS$vpNFw1vdWW45>qvEn)eMC&0_J z;pK-t{9FmnhS=w~b%}CNQPNW+^xD8rWN@I`0R`l08Kk+;lSkzh@f6H0Sn9GxJv{q{ z#}Y%t2A?-*7OO(RkX5_wz1g7+#+Hi>66{%mD4T+T!hF0 zfsq53AnU2atF4AX_GYxtBoIn-KFqzoH!|m8fll^4vRQN5peYLPq~wBi^dObq2XY51?dM z#yY(n9V(?qO``1-`x7Q3)qTVxl@t$}d*+4C zw3{R^Cs_FO#5;tmh!Fs?P?4+ zpoKwvQbkwwZJnV;p3VVcMF-jE)UkV>iE@VFwYLF{m_nC=Rm}oahwJ-^=e#~|ly&Ff zrAj_aM&;HvkCk*5U$l#l*k{RSvZncqmENXK6b-Y{RTgi-bfLEt^FYs((%QTshNO)b z_nF7rQ~xHSfZr?QH1r*}N&s$dGqsbACMs6+a?Ba~`pZeW%>Ae)oh|wjE5r6Cx84<3 zZ`&{h!kCK4K{nKkB6$({La@O4?bRAnTu~&XCmjf2Kc&!i6|a`+bq^`@t*#g0zuHkY z)7rH+pICV=bdBq0j4i)=8thLQnhQ*Ib*BZSNC_o1w;A#B7Ij8ArE!LaFZSPluTTcU z@)$RG-*;#x@AMwd*H?#q7wSHFZ;m=&GV7fiqk*Pd%7d0e3;PCWwCkS+0fG)mow;8rQzRjyq4si z)wWa`m=VyiBDtyBIkDEKCpfz0_%}&_qgLL}CyQN*0^V4HZA<6Ke ziEiBNAuxPRh1hODWdR6eB2FYxX2~e-Piow~WB+bRf{YqL7Jbcri%ztgFr4Z+>Jx-x zjb)mEbM0x|Gh!4OL)dRXxq{-~-G*vVJPqpN`xJ*}b?D6tf80?mjY+ zkyeL^bd%THPI?oD>`v^$Mrf@t@Z>{|y@2!*Z{r@C$Zi_{MOIN`;<8Vq3G1aRL#Yu- zGHfWfVF)0AO5BZrj3P9V7%*1}!i!1i1gH-$D2QS{YI5&V0lhZB5Hd7|l(asRWU+S| zEeH}~?J^1pGOXB3!=&V)AI6d!Fi~9MpD_?8rQNWR)&is#Ctwz^f!DmX=1KmxSV+i5 z`nqa>d1PEfw@s^0MiUQ2VgpK#%DhK`%c~`pac3SJ7-j2#9|)Q8i<~~QDgaxIRg1)n zZ&!|$mCsZ8Us46pg9O<@Tr>2-DuC1sKT!d z9%RhBw6iowi@%&;?QxFGO7H}gi$lm2ptIA)TUe$LhML1)&I*Z=H29{#59pMf7LqHg znc*QR;=9`ZitD>>cDs@=6>dKLML~h|+%r*d&1ZH_04eu7*dvv8+xQf+o<`Ex%U2#F zUFr``dFra7PPKl64JVnT166f(H1{HH6OWeLAo0wwo>m&6OT^2R0s@qqp;zFDIcDr( z;Yb=kV3lqkMmOeL6vzQObAi$JR;2EbBW2Jv3Z=dQ)fyxUqZ~cFb7N_<;cA82vv5&q zRSQbC^d``Mg>A_0dSL>F`Pz-;D+MZ1FmW=VMDep1aTH5}+~IT-pe5 zjac4M@SmiEf05?PfXm~hA{q*BzkQX_2DDKDjUrWmJTMeBibT1W9<#R2?Hdokt3W`ix)9cjAV?gnoJgbP53lL zJAM-Pu8JISatiTveY?>0zZ4uq(2imn(`-v~fxZ!Vb-|+>ynqK1E<~oVfx7nB#z+W8 zDe*!CHfn=2{cGcJ%V{ee14{ij>`G{lnI{lP>3K`v7@x<%jvopi}WT2K{^o)4893B&d&x)UUM@|7!tR2TX@v_epX za&LFKMF0NgpS9;c+(Ue+yM%|G>!9H>yKabMCj9geQOqP7T3vic`fqAbTVIyl8}O#; zF@VZmwqt6RSXIt-(1LRzKsDcj1dazx5Q7Cl-EVCN87M%h1)ZQqagU#MJ3ZW;e937L z3_EQ;hozCJz1KNe+S!oZfhy3G(dEF>53(6DVd+OG_vNzAlGGG!U^$*)%Id?{O}g!A zLTv9ev_nE{X(WSyU_{40x(7~rDDDoi7X^Ee00sj1lrL|&Bc>&~daZ+|)%|=09^fJl zXl~Lt8`;@vMM*3f6HxTYw7rt4KCuhe8-V!F*R@P5drQ>WF-Qm~LiRk|=r=>j2GtWM z%ay{a;DJK-SP&zIi_xDB%}4DPwXuhpJC!P7UHTu%5WF*CLr_;~Z7u}tP-yG8h6 z+9(!lFzzq1g>4#LaWWEGnM}N{faL~WxaW@1V67%k=MAYbLoX*Qypv}H0 zwM?6d^eB3epW9`20*(ac>_;6A(ht9kM@1q5IdZI)+3vv`hW*aZJB5-J6qRyw{z z!|YO*ru{FchXWf0#hW?LhBjM%^noP+h!T22E#!I8ow6;;6eb$U-A;q;Y^Ntq#GD2l zx6WVZEfE4yw?-1fEn|Jc%P%;tIO*^zgFx}NCL=RgdM@L+=c%);d|b6x4*El75W?5K zZ$#{dx)Z_nhtIC&&2b^Ll)xi9(NfIJu@pz}DE#h30Lx{e6b{ z=$pucF1*NL2wYF=qG?|}GY+IY*>eLMBsiLdB}=YfUDpmmB$$QTLN8NfP==A`E=G2o zisf2GD|SuEdPw+W<0lQ&0@lnVZJ~=mj`qT{tN7>n9ZztenMV2-L>5uh z0}Sv&N1$LBOt2QRM-LC7?h$vr_|>_MRu2+BdXX0u5&(xWW5YsAXUg;>a1p%>p$va} zgmqhi(IG0IMM2RNP)+R| ze5vtJjWdt}@}YnNN$1$GkmpgLwfk?Td@m>F&7MLvjcP;N>xce&!{<6*T6v~3eY!rf zOzUu0)wN?a+3pPbyxOMY$VjMGk=b^ag8=qq-WN$kuCaqSh5^A^LyBDsk6sB8%eRg_ zpVmb^rJ-Xx1YYL@-9KR}=tGqwm>pbc?d6)uMa#A3$6gDp3AbS`L@%4sm-&Lcb6d<} zBaqUS+@xwUN8Ktnf~Gj+^%HhIzMk^N(D$v(3!z*ktN^6I!*TFi`!aEx(8KY81|2N$ zq*ZSJ^)b{AC|_LA2t{&4udn_6zOC-Pv@G{*#+NywceG<#=vLxKtKyHFPpQv^!;w0K z5&w?->)l5ocCXxE5YN}uiJ$aZpa;6|IS^l)o_;F0(_MrgdI=hF;2#k=nkfAyVI6kq z+Ze6t(HWo0)-$ir_Z$n@M#l{%f|D06;<)wjpD&WG-;BHQ`HhVp{}|rYo5!Dz-+32! zji`kDo?-GG2Jc;_sQ~XqffFW-7!!0ld{QoX=VwupWub0zmV@q_2e_g?dG$|31C-ZZ zk9+(`N^a)MyQ@!GbR2m=9?*rzKB zVdFphT5w7C_N(6`pKVTVoXvdwfpOKb>?thjdq@B;s$+pS7Ma<;WFfn0+i(owd z>lCa6>JSYLH~zO$gnNxW4RtlQ0c}?kVZQvw=^7HM0@NK_RW>CL2I^f0$yQ>*g^FTW zUq_)hIGDGYt(nYsh4zIc58i(`{2;`1^zPuTkolVDr*$=5F< za@E~xc1P$X)pK^#Q%P=_CB7?g?6@_?&JcLb@LHIO8;j72k}Zc3oT94Y!Sze|wCrH$ zOJ3qsf5@NYD9BqvGP|^CK35V5oLa*AC$XMl)+cRQF3}U1z%jpc1{D-MZ+t>axIEe8 z|9ohZHYwO8vu@IG`odDQ->+Qa-1Nwl;@WNlvR>pnZq6h0OAcOhlwWox6HL`U|~q0)`Z>pj0IiH5spR zKv1D$>z*b>4G#9drc>d;CW;X*zkPav@_O!XZTd9h{dEzmN3!o%-aQ}NJmnK%=3sXs z3?TmY|NYIEOo4fg+FjjNH3Y^kfta9l<_wO>RpBU)jEmk2Ns^Ql7R_4MXdb~Y<50$g z6~Wk=)N2)SVkKqfG>7@kS&ZyuxKXGTFAmGB#7Eu+mDv6`+xD#e=2eV@vt1}uQ8yx{ zfk!k<>+r^mZ1dupam%voFPTRrOauLt$}0xH3f5Yh@KIgEke zbMNJ%DCw1eC;M&?`<*!R+%PV756~D7*MFm7Z!&&@3Vjm1sjIHIyH>0ZmlaY0crYO> z?F*1JGAnX;IBFT>U=b_zGE%Pp;RMqKNM^bB|jG9MMDHB1NZf3dYcnAmFYn! zT+$qu%R&a@N9#V#dKzopO!RUR_G~N2R7Fs_8fTVX4)LXNf+K*rQs0@d{r#E7JOuX?0QhfGd< zSUSu%@9+OBISF_pUiQsw2TZ3V#PXf%@s~1Vj_($AQpWk`1<3>&lXnJyI!63zJS1+q zoD2(uF#bk(otGQsSus}YuRP66-vA2WQl*f3PWnXgUV%{u|MMdwGz{Jg8-$XKal&Cc zi-u-0X#8#Utqod}CH#e4R9OncKz^Q@$Pzurf>AIkEQ{|n=}?w6Ne&N!Gv{269WtDd z{u0Xm4m4hCUgXMSQ}uE`7xL9U3A>4en7lf^Mmw|$ z@&Qb(i`wLp`5U+Cv$R~47yu~@z$Au;RpVI`=4b&%Cxi?;4=xVQy9UB8O#Z?kg!N2` zD!b{1^pOZ$9e;)Ny#+XrC8g4tgsn05pLH3%Qqud!UE^y8g!<+-CY0wjL(_~bWC{@H zhEtH`O|IbS;nrTBiEcETxkNu(@$>_;IYvd*;@w=ZhSn(5c0wv*v`IF~#Z9xk-^c8_rt%5%CUGYctng_b!BHf+ zgG1#BFKndzG$~i>cW#J_}8N!R>)acSA@7yeXXpo?PPK07WMUn4`{KVF4 z05W?Lr^D|ITckd)f1np5O=!|f*TLwnFeiR%@27cP4o{w2=wD#XiQ2gv(^usA<5wGZ z$W6^)gYuc|wQk*$kt^P1ypL+LtFG*0n~QQT-q`G&6QF<7S^ll~cQ>xOk_*v0ZblyP z6bG4`uWE6Vp>*DKfR+zOTi0JZ6Y(?%Zy6HmyUhO{MCbT{X-5X#&9up+5*Cpi%USGc%`l@|7L|h-Pqm6?R2x{ z66S3YZuInsXd-_2P!$#_pPX;=!bS75Wkyop@kFGl-5Y(==puHPn*toN;$S|6Ox^fw zcv>*<3lA4(ljA9{Y26iX@f&sr1M!FP$lng1;Wnndl1zET&$8@ni_oxg9bPR-`Bs*Z zpEcLkh^3@G|D@DU%(VXG8J)-d&k~*H7pwlz(K5y@r7e&{J!TB~#wrlo8&-om8)q%@ z^<)S=?M7v*_uO+fYH!~txFe|LwL^#BMrV{?tE4~xy@en6ezOO7%(xqZk7!qZILFw* zr_FPC*{{ZT|Kui^E|d~+;os_~*s{3iOOI%H>j@cCs?kX4#(fg)9a-OBhlo37_ zChCZxM*i$?TXjaf(&vAVhAS0;-j+uHJ7vROnS0&ymHn@+%y64M@e~Va;p)8nygiN8y4C>7SO6l}o9TJVsaZlkGEE zWd~%xPpbWVn|S_6#$!E=h=mHPC>CRBumhk7T%-gDEJXxaO-mJ^GK}^Tgq4h<%UEM$ z&^6rzbsjX0UM2%7vqVK8eOj5Gm`OD^k$9`eco0-Mqr{)@Txr&hWR9c{h!v6Il*~2{ zWu#ZkZlujk^Uq9Z%nl*Kl4962YJnT-ISK4h{R3R%8D}cgy((w_gc(@MA(z!CCO04O z$yZlos>==|JN}grXrjsMx6gUb!yqe`a~&1FzHIYA9rOak_-Y`R@=oju!Lh}k?s{#u zCL!X$ANVkR(?dUJ{`<`x=e&uvtQ9|5WTRx_1@*_2JeKua8I;RDwK*+i{9I+3Z`TvE z@oY3lq4d1|q&?yhZNA((T$h~Vo^N9C)n$bYYf-tv(3Q{cN=v^;69RbEgJlA1v#B}- z!}tx+DcXb>SLwk5_E=>mke-Sa=pgWR={*Og_Z_e zc0P;N1_w471YO60eGB;^Sw+`um4(SP!U(V-vO+ngAPoRtCzaaqa{aGjLU|sUxuQ!t zCy}ak%C3Zf$S(@!_lxsm#hnqQ=MZqeBX@cVNRv>+-AeO-r{ZZFZPd@ALf+!|*es@l z3a&2SrCJViVXWw1MP9a*AczCv(!0XPyq*DVRYw{{5`gYg-U>saf3pT{ zs%iDgM(J8s^^vJ3fQM0a4i6+afuK;~qbC~0u34yP8ZLuKzG%GzIXSHypaHv5d6%rB z5RzPjeNFvO$f8C{DuVaV##s$cG7s3K=ixpte1Q&xS0VSn*hz9?qGrj(@_pSvMG1;S z)0UW3mx?ZDM;8bTf&2)fG?c27gQ^&_`qB(P?*4+0i?Vj>^>-KCB2T4?@|i$}p&$fs z2o60T$UDv^uSpALH*Wmt1*WEKpR`qplVDq%^`T<*4ZPqSoMsUvTJpq4gslvJoY2|U zG-S|vLkyCB;Uch1=P=>z=?|{FZ;(D1@j8|^u1N6;mPQ;6rxMB6(KI~DLS5VyvGh%1 z*`>Et1U#el%SCdW-*aU~db(z}W|?~q9l@L_rVOOQaS&56T8KR(_R$gaSCS5=n5aj( z8w#%JYOAbZcji}H-qJ?jRJW1Q9R)4NoA%pgL{4*^Wpy02Qa=jY4B6MBUbjxwO|}^F zj@yZj5+iIHVY;ry7-KdQ7#j^#h`7~Ur@xerE?2Epzw5=&Awf@X(UBCzuoKs@+pgto zmdFm2j9f5bUJxrefxcOC>MMbmmqgeGVME>a*WP z>LY12v34Z2hXu2C-FclV#{;O>>8Y!h2rA!xkgupQ<^TG!|9L}EJ&tRj*lzSG!@@y# z+)Vr2I|vs+MEy6ZcY*cpYxAUEop+D>GT!&_jWnTXfguz~ZN=!JYo$m>O6h`{NB`xT z6KF%$nGQa~_^MK$y$ln3TU$qV-(r@30RYye+Am}x?p!|;q~p}PRi~rB1Jq0NCNMt| zxM^;HxpHn${j$g#iQtASjGG)6WTKN_4AJWs8pZWR^EPGY(B_8$wy90|K^^>Fp8K4G zh@3%2@4J-?o|vev6(2-{k$jSSQKU(9y`8EmdU)A=__@|iVY&xtwiUU!-huCB&NvG{ zhJLnlgQFduF+s=>n}=Y9%J?{t6sLu*7XOwlL+T+QL6fu}n!$x51eFrq~!6h4}mg-JBDq>3J8p{E{O%N2zUyq< zMA5%JfCvtBJ1Sera?Ih+IZRdauqhoIf_iCv1m+(f93$;>(9;t|HL?sNu2(R0E5?&x zEZU0p9up41s>>5F7Z35pRCa}I1{eCtG{YVq<4M9b*ts4(W-Px2qYMO$kk54tj)jKF zPALbgQr-Ah;ZwXy0&K+kTH6e{gDJ1zK%Y4iS0Xr^f$m}$G)$%r^-YGA1TNs89&2V(wdyJTGpJ)wZ5hnJ-DII^N<539u4wYX~H7h=C%uK?`)BB;Z4vGJGQ z1I_a`<2+vP<-gSfk5#qNV@mGSWTh>jgrjjIvM>WI$3$ka1?Ep!mbbOc9wE#!RJp=R_5d_=8S~R z*6K~kBW580Mpem0seGwyt3T65>6cErd01kftC+!juCn7?gv1U?nyC)=(stzwapfy< z)1z}GW&UMLCo>ZT=(?E2A{yCW?JV{O9basB+53_L+fw|I{2vj8lVl0^+Qs{-^R-aEfxpB@(pZ3>8sg!sZBGa>FGe}5S* z=@FKJDIAwXW3Fnh! zPv{i^<3^-N%huIFmbS=sp-;?Co*W#+y@(!i0jX`e&QXaB5+%Z?<@PQn{AbZCf2`TQ zvwvrC--9h9N){|gkWfNGOy}JvdSLVlqk3$U2z`%U=~0he0cgPb?ddz!iPuMyiwIw z!m0d_CG)q9g&$t6Fp~?O%75lN{`5^=%0wB=jD0usbkoQduqJ~*=f(3=41U$~-%yeA zAi`&>nMEm`U)d>$TNyn%$84dG#)^PTr9R7(i{W z#8P}7{`pd#^Fm4J{if&Fq1(*Qb-?Qb7IuZ~Y@1(kfm5~U@7$3 zx@J&O=vy6`ioSqcL%up~Z#UGQEnF6|`Fr?HHM=}`5cwqdq_XnlUF~=H*Y%KF8MVwY z8@fNP*}Unv$l>Q{U17TsyTm=*zp=B*7>@`Zv9x@vp+7(iFcZF86IB8pooWew6ADvN zsrlgJxlig0^QL+qwLsZ{t_%?dYSli^-V7qUNXGNCMZl!6zapnW|86o{)TppL`_%zV z-?fpTSNNU01;ip>Tyx|?Ex@nNnJnK??eD&OQV-}orRdYF-DqrWzV)4n4Enf!uynQ9 zfbqxA#P5Hs_k{pjW@_63;PGFJtp^4plHh8>CSy{-Y655HQUb+`h@k3F4E3lQkQ6-^ zyMzfVD_d~^TRFW50&|w0^Wb4tI(74w%6!KnhNl6vpuS%nfAmoBfBtESJRgP8aY400&>M`_!j#EqNLDN2%nLTi}FyxK0=0I{yoaY(&0d zBNczSteNnB!^Ys$!t!$_rkrp#@XS5jShieSc>4zavF{S&D)vKH&x7}`DIy{h?M^*K zd|Q<#+exy{{f*cW)S6Sz{uhM%{rrWEyWXM}x3!}-+y}~7Ks>_s0&ns-cCJ{Tt@__> z1C%&|yU@+GBWrLkmv^F~X|#gjdwJil-hAfv-F$H1_|2C5=T*80#reqCWCatM z`}vg`aLW_XDzb++tGDTg|8phZq)qP*EWZ; zztWnq>MOkRUc43O^NQp0_H_VHfzo}EGfq6+TRm<{yQ^=Kv0mC%E zqbSC)WP>**MBanF(&rwf!q7((>m_Bj&4aWBqPwpRHJ$07V@r;M1M*{WXZvk_$_`ui zd2?$tgsUr311E)xt0$x+t3|)B?cFBE9lVNS1-lhOQn&&|O+D}n&Fop8KlLEV{;rgS zF{AeOQqxbq(~d!^0WHmY#i~sZCNl3_hV{cSkaf>$Hl=;MdEhdUH({S_k%6Zi-jiK& zlgX&rZ*N6g`}_>*sN_=$?xM*1^Ja0hiVOB+VzfqwL@^AqLraqr0WJ5{5bdoS{pVOJ zZ0UJFJ*Ib~QLreUkqlC}ZEZF(`Y}`nPuin1lY_-#fcCp$@uuzl*Yvfkh2db?@VK#K z3ubhXDk21P+wPD&%e#=i<&iRh07Kd+D7ux)6{LbeG$3t&FPg~ww zs|{x<2snb5*E>4RD!h1sy@#HiI~sbHE~ob3(C$#Vb@ev#WZ@&Kt8Y;tX*aAOigDv) zt8gp0rD-G+bw^un_K(u0`SSQ~--Ekyk+(u4bd=Z0CB>1Lww(}-D=a2D$%D*Q=Jn?9 z+8=xxRr<~N^}rhcw|nhU4}+XF^V7~|`54bot^KP^mMk-ec(Dgbnr|#^j$T^dblJNv z`K&fngVTc@cKe({LY~%2Nd1@f6qsh>Uf}Nd3FZ8g;3pfU3MIQiUj!LXUf)0SJnXAf zICIX68wb@&q89Ui|0#{mG~cbP0WOG;jPN+KakTLn*K}3EM#vcf;jlOmub4bRYaqio zhf~7#_k1uqN_hzgVAQeI%lTzg8gk6nO<;#vx zERQ?tD)`^&3Gf~BjkVFz!6Jo)l}LsrxjPJt8HM!ykQD1+p=qMzguF;tvZCb_oK!Y( zuy`}a)6!eToJMxuf>I^VQW2Q} zCv6}#bM}OEwJEhJz5n!yYm{QvL1i7?H8Yg?uP>$Kv)!AVSzTtAo1c_T8T$T>&wmn0 zdRA^za7ASpQ#J5TQ6O>5H}BuTJnB`j)$Bu@{KU^ec!_;Bv#iMv*+#9X0+i3^#w(%; zb&oDDKfmqk>Zbdxd^Yi>Up0_sqX4fk{!TH`7b~+_VT+TDR&vNgd$4o!9|^}jS}Fn$ zw~9O%lyLe-V=wfv;XaqNUBb-;ZVvp-+<#^l+Oa)NB`*avwIZbS8&9&*MI^1c&6cup zhPfXzpW5_I*H0s7ZWISdd-G{k^nr-=I--)lypVvL!sBYS&UE^jm#g&jIbi zi0JV^TA?4ud)IAV$9ZB_r*hg7%SYer)jig+>nvnCHX5NbT_UMP={YLSPk0z{_ub1SM z!!yVD(;V0#qx4$qeC-v0at@8!;M0ml-okFUeL-Qo@R^^pNO-izvlx35Z?QMwQ9Oeey0ZP2 zm2#g%i9rakdpEp(!{076PEW=26x}=)V35w1xY|(u;AH>Fp3_eam+x1U@^dz?Unm`? z>0f&<2v_?kC~^*Mt?Uqx+pcEwLt<<0!X~|JyVpS8@b~brw9Gqx^?~azSbV1=!=ua^*LVwc{ngpf;br8|YP0k3P3!A!fmas?{2q${@{Wbm9 zl<~l*c=Ae**g@pn@pOAZU-e6vEQ$NU{vt7}1(kMUo-+`<)c@UjzC6IZ+U?`Eh*IH> zhFVtK%aDED3LNDhIjy8UH(d181!NVC`TXY7nMe-a2{8>xD?(p&e%<&gK(`yyxXQD@ z#z@K2y>INbeD&<_xz~3EOA`Pf6e-fZg@E^yhM!m(fNMi}qoa-U=s%@HSayZEW2Mev zlYMD=rSmW)ITJ0v0dW@~ZdM(oIY_LA=}*JwhkLXULAv_8)E&!uvpIEhvo zhxoM^nlH9#Pe*=jUVV1`zKJbN{KUEabNyBWv?ffxNC#rxTRwmE^fd6p3p!Eh)LTaG zv6<}N&R&tkUN&wmDM>VCO?FMgn<;b*}8wR?36Q3v*y4sEAbzI{9;d^(SFJQsjvbzA@Y z(PHfPJ7>q!mhUr9mhT}=6mI_cAZr_-6|FZPJf%M?@^w86EJWobA zCL_`%BPu2%rYs|FAR~S~Bk?qY3UDW5GE-eL(_=C-%QCYEGIQ56Z=Plnd9n&HSw${c zB{5lLWmy#iSyk&~2n@1ACpcyhWiIse%&F*yTe zIYR?E57%=Zo#v2va;an3ahF^wyFFc&J2Q|wx1Rg-G|m|{`&pr@4qwPzmyq?y0bvbF6}W*svFBdh?-ZKcKx@rpd9#ex~pO8 z7SbU5e?0-C?Atw_P(x;=Xz!USYRGK95)<+M<&&P4XEoRqdI9s^*2MFK zLjMoZK}ZNh^3Rmh-`~&H|HzH1Pd^n(0@%$(GieC|@;87Z2r^$pI4cEZw+kj%=;qKH ze9`d|5j?gpVZ~?vORA=VfB)){$ z?-w`E%WZ4M<$T_+8M^jh|FVTC?r~zm$j=w|kLA3LQ-w+6TFGG8kVmIu9^-rsF0)kO zT=KeN?_2E}gP>uxib$pB$xM*YaW*0Dhq1V+^tNc%uoqi5y}!4{8VbUhb=g~d!x7$l z(|I2q<~c;50DqN13mHU?4)N*y!c?)vt)G=F)J0n(FL{mQMrzE|1nmv1A0<|)e1f8LV?FG-72>Y(B7qr`ZxTy8!@iT={;rQ= z$G*QvfSeASKFgN9xpOPDAjYIFi{@#`8)B`4n3(;37zKL~UeV{5%`F~?)Q4gKkNE>;ycQe`Hlc+TR2Dz1{sTo99?Jrpc`~G8xUv{oce`n$ zv18BmwsIIJe@zwK#2-I8PFj66^vl1}nrxLH=7ujf9A05!du7n!hm7q3A2_LBw9Gwcg6968t<2Z2 z|L{jz`)`twl0Kc^Ry~5Orr{Fml+=XVNs~RXte{}}aeprn(q_{@pHh*+nK3u)nd4uR zwTtJ#-?s@jNb1`jzdKXcnP1-LG{xUY{$hhDJsf}2K7ElCD_~{1wp_vd>DyWo{HEzU z0=J!}uzRKMn}n#k@$cftyfdxC%%}u&4;ihk#eECUi>Ju?4C_-mF^;Q$jwfqyea+^m zW0TuLK7W4*;kb8XjwB>Mh03hYoRn4YWL!ErTNJZBx_A1n<(_U)+Q#21w#8^GP0B@X zg~!d_lA%5G%w=BWGYuYn22)#Vhr4-@7^U)PphV|Syk7#svgX;BueUx2h$YiRjKXJ9 zMwqidCtr|ZUC(Uk`U=S_@~qn-aBRf>H6F5Ayp=E5d1Dyx_N@>fhWX7r#d_u-y%4NI_!tkqWGzm0<$3SU4HO_cv+8LSLB>OxrqGXOgCwR~oBxU9>@g~F?@#9Az-WV*@ zx7I+T`%7g62Z2Rw0WR;tUiR^gfV{=&{Z3Z9tS1jW*x8ll46O4-k9{_jK0KepzF*2* zlob>ITCT{^hy$~cK+=1dsjHfiHzAm0mb=Jgcp?e?`ia2`@Y5zdA6^4(I_D$pVl0zv zf}1E3+c)jCw(MuGl?mRGG?-zfPMl!$)1#~dyi@6#CoPfjN%Zl=G>$TO{<(v>0{NeI zds|bYQdaxkrtg&s!)wdU&VKKi|2&uzkw9Nxs*1Bn6bS>8K2uk&)d?>Q;?(eBtLpr`8e0dNNO2(!PG0;CTJ!iX1fd zI)Rhl3wXtUH*Q-Rpfdz$L|Qw{ZWw?@6Tda7)ce9s%x^KCj4`v^k^hBm(&lbv5qj~l z#bWq6SbPEXaAyK}2DK%uX3`^v-#cD4%#xm6^;9(e8{bxm5vM>pxCH-wguAkA5Twa! z@n(IWlef%7_YKz@wWpKm5omyJjzBjuk9NOKCh+Dy2S>_v{fak8Lev~Vtg=JS`>5aI z=x`}O)B<$Y>0PW(GE<*LhUO(icwYzOx)mtLtjuHrlHq5|>mmXRrsI-S_Q7nf&g*9F zJC@|9kaV}x+<0&$9R9^Yp)7(lH()%Rzg-qACE z^5)Iw8lki2@4PqPYt?N}LC9jt5AgN97_|-%#O_GhgmES47AHI&lZ+Vp7$Q1_e7Pg2#IEMC>|#;O&>a4w zt-Eo~?s>|Ft=$1FbLZ8I(weXSHA_Ja@dRGP%NO??Mw-}fy3)`JgTp^YYJ-ri+9oX9 z;;YjSt+sTDEDzoo$%e!d1;Y71lz}8ou-Bi>ehFi*9dLaoyI5K!RcT_EFtR&H5`#Iv&PRW2h^)} zW5HcQzTd+B{J%r@N8$^Z-LE$Kc_kNw9*DlD#x{Dgn%@S{h|Bpvl997~#gNs_s=bk6wm z*9@(xv}ahb3_`z=wHC~9`f#zBTc_}=9+$~gL+W(9#UgacnVcd0{(fTSILsRt^f@C) z7YXFv_k@z63P@nE#L2HTj!J;Aoa#lY>o-g)A&>^LrdLjkeI?#Wd;SO&D+yCFMTyg% zCB2KVcP52!W&-VRA$QboFi#{2`kQM+Mp4~{d?ye!9rRW#ycw+aLf;=lqa;J;y<_JQB|KpEH>ssf<8GX%|!z;Q{eypR!xJ?VE|>k0n!Czfr2U` zATOOjyUPh~d%=s4tB2lJB1HS*C<8V`RyY@kl>#X-g}gb*tZ)g~v$eVC6fqPjvXwy? z@9_)7I8|JTx$`6CV^h!_pA0!$n5`|8dddPLLNoxV87T*h1R$i;mudhtWtiS-C)uhk zsA!>01UnOhu8yY;(`G87AyiLOx)uy4=B?9aRhcr6aX1R(6Y6}=qBTrFO9nSvcdKkDiZ=;1C8U*qTdI zJrn07Msz;=VCs)jCpaEj9TVsSi$C$sc5#kik0u^WD{VwUrGKQz!$TKaGE7lGA_mZ> zK>w{sE%4`}QrQNdE`|6eoORERSOT$^KHi=BCH>4?9iY=>0(=Au;w z+CNoiM}QDnMP}+i_mowM5uk_!*|bSG8pev%o>?478VP1eI}R3Srb4LEO;&QqdD>fM zry0r!h<0;%U|UHdPlXwR=ufctK4#qk;bTA1t4jsD;UW|$Hwm#paV{lo^3n_#{&)K#>rce2}AbkdcB32%;-I;?8BmIhe25{eXyRLyBdl zVew>RBS0q{UkNRZ0Y?Yut$M!25na{XkUyOr{esUjs(8fAsX4-Du1UkD6>XBxWxCW= zsoJ_WUl7jzQT_!-W$pfALtSNaS|f-eE<&#M_N&R;;01e@zR2UBDrIasA5*Uu4(e9q z!|O^_#9V#(AO`5vG;btGsx2NgL){J~L~>$lg9B>K=~B@L8NXV5tDBM+CM_*t_8eIA zqA~*mKu3rOy)Tupk(m@UWv;W}&G)kiAX4MQ^)E`(H==78cw&rNBDUXgy$(~?NKsd_ zzeMd?1F1kG&08MCv_R0AdNbaNM;T3n4Omp>@M#W&0A;hia52h3xDm%zs@hYQQ?LsD zDArV|k&tSZs$JC7d}8QXL6j^?{@KW@H0@HbQSY**Si1uW|BidYPAYv~ySZ1Z#kOKo>2J;M+rySfqF$r*wWA>o5i9)4@ z9Q|wFI`FGF_4PJaLC%_7BeW52cfWY+-+(k_ylKC0j@7_dC?LyCwBn+` z4B#PJsHjCwf8gB*Dr#O=;2eQHpG%?deyJM)RP)V%yb@_0%Y3m&m8$jnwGU){cNi~n zh#9-s5#a9Sz%4=qyQ8V;f18>B&(Ips!j2st_$$x67^TE z!5%3XHym|+-kh@x>M4nJf@8$U;3O@NqX6dg>q@@w>+h%~-ZK`=;nQ*M(Dvdu2jJ{c z6cE+R*vK*0F$z`Z0QF`J*rh^1wh&z;bRi(hyfjq+b%6~H+GcQ!k5s=OX*TiTOx4jA zCK3c7k$`e+iGppV0f1p5*3lArj3}_fP3xHH@QUoRJ+xbG#Y2A5fO`an(eOcMim_5r z8a-h|nUceZa~*LHE#}G^YYlx*i=TZGr+|i-pJuRKgE|wz+SvO(-^_R?Ja`}6?`a*A zSQvp5A-0=<5xOun#WTZ1T2{d)9R7dr3P)GJ>@zmNE-j|-`^;;eEd*PW*XNjM_32WU$I2REH zUw{Qp*xvEE5iZgD<8Ay7)oRKOp<+h)w9nqEfs_bfe}`lUr=S}V(m! zxvT)4lEpVzmm3iZ>y{ke@Q^J_{fCiiw~NKBJ5+m2GeV6+Ei|k(QX`9^yvn6>U2Uh- z=iL*qQ+2()r3PLV2RU&M9#FSfhB@PR&G)Ve@ubzmKs&x{-L@38=AgZrm`sE_L$79CeA1s>8Hk7}il*iC8qK z6YhWz(6nRnv+?tx2DtYrZTx>#L`*KtsiJ-)iG=@90g>;i!O#Dj2IpLyUH{p$T$Xh6 z<%}R=_E(lE0tZr~rdp{N3$ybElp!Ogl~_Aii<%R@*x4##e&>>@R zZ%=vq=#uFB&{MXHNaJ>9jy&_@-2a8RmRyJ`bJ|Vgb)pB9vh)``0 zkgI%|U#S5tf{4jlz3-yzF=m>h8LD=E$o|#&q)tz?L|h}(MjH*v zU(GQpi7)8S`BPbF*n5W~WV=(vApx=RA;X9~H&7<1gM12DthX4n$Gv@#`l}S$YkDAw zJ8=26jI)P=aMl-8-^>6F)758+f?cI3)3<8<7ja|GG@m+AII!Q^ByYgbmhp$~b?s*k zTgP&_Y)4xup}s}Et?mwE>aI{MqSbu8V_%c5Fy?p!zkWs=ZdV!jThcDQDDU#KLxMA#u%_>MR5|HtgR9o**|Ik;3{L|TA3h!zA>oC zp}3Esg4QE{jiUur0P*%vJbmiWD&*P2X;Fv8t9@SV2%sSjTw9^B$;|jNbc)&)^U3MG z%NjqQVMzP!&v)b?kRKtR62pxqmm_zV;{`S0%ebGS#@?TQN2$sKN1?CF#~wEm0=em2tb6nemxGfX1oQ$(L7lZO3hTy zsJH5nvg&?6ltz(=zu|WyoXvAR$R+~e~UgPoBtQEoXpu@gpTS!g*S%AAUvw4AB`)y*m9DVkV9 zi;86Bgvu*4lw2@?M_nC)pGmTX15w|BK-~C$IOopJ+J_yF9zSN5EN>BQe+&Tpu}s!y zqQDgSKhL=iBLZj3qosPzv=9>oonorz4AoJPpoyg>8JWggzWvW*fL}sisC3AeTngEU z8x`Q(v))z}TJ5{01GIPB20(((%~aJ1>0o{YHjHPacvLIqtA678 zeVaSy39%^r9u~2Aw_pW{%0&8L(;mdInx(F{5-)<3N6nDVZ7*|pXvW|D!Pbu`KR`T(o5ywd2zlhIAZ?{_&2iQe%mqHUP^PNg%1#YsH~qvW1NZL;ySHe4BmFY z6M(_js}P9vG7`*eXyqq@SFgrYr!F4}8whb(5+^_=ric;xtpvEBXY{ocPZnwq9GO)W zMF2Z#h{u3o9i5{{Z)=YAnkyiuwhe--DsLUSqKeE8_taTu&+!414bl{Gr%aiOk(uY% zl}(A@ET2_ZNoJR% zEflvW8v}=%Q2J4+MhZyCI@Q6FCidp`)w49{lVrr2>s_$lWAr_o?P9Jqqk;`Vf9l%(S29q8Tg7r88i3x-q9kt#`Fp+F zAyZI3M8Z(@a`gudW+l^FumNdx^7g^N0i{VUM>h;<5FIE;hyo%d$mkL!6~q`4Voyau-zv{O z-{&8=f7x;DxUcg%@AHK;AYf>{FkxnW^yf4Jd!NieLTZjFL+KGm(t;fL(GkgYkE8zX zicW!Fcd_v)kKEqvx4gf9%#t@avVqUi88S!^(rpgPW-&!!=Ojvd6GuSTcRHRj=nzEC z=H7xvE@x{x$WoWkj>G~ftM(aggPx5RTROEbrUZrjeO0b%w+47^n(*rJzh`;GZNDyL z-w3ne$##;JNE*#qCmO@v##~c4hqsE9esqEx3;rJXm1^$0pwJg@KAquEaBr>ZExm%v z%p9C*Sp|~up+b+632fv7|1&;#h~)TGQQe2vR^MVO|i>))abzP zKFV{k^F(n*fU@kbwt%EGglZQ7Bim8O#l?V~s)ACHbg+F24R+KpPSyQc4px1!sD-N{ zCg$47_W0i#$1O8+v^?u0sb1Tin;JU_s3d?P3a&zkEFpPl#2Oi;L4I>W{a0Gtk`+v2di4F?%u<*` ze#tg_6FzrFga=2VS+8ts2-ZA~?qEdP(B;hP9BqQE*`S2%!FQkS;`iDaD(K(O6BH50a&)#3rRdy(;QqKH*aT1}aZ6<=@6UD8cX-wECL5An zDpGz8TCn$M6y0BXbk8ru_?r(gwcB_f?^sI!2Ho%Qi%~?sIE}=NUzoV3_+aj-GgHms4_&Th|BmXc35@wlit5@%T z)`6o_WvZTXuera#_LRB_FJWW^{V1q~>5?B$zag_p8Jw{Ed%vRuz@y@}OQVWsF#n$A zfXXg8`kKS~GNmYiQ{6wTe^u+fL! zYTVmF<=!6=>UsZ0*)g=FRBEQR;KS=K5%k5vX0CSjBqeH9BTSjr*xoP$mCBZPFuUgL zTui!JRIpqCgr@wp!lIN1F0tu%kXBxBIltfi&!i(W= zy={sYN5Gl}=arS2MEhSKAB*h#M2(uRoEIO;5u#f5aF!r1tXC8zsRU+KsE(UcN#=G> zO8KwbSvRLo?rIAzrZoS|Qg%%)lI7oAEy%rZHBn-nMe8-l0<@(ybJ0z*Z=^-8_-%xS zMfRO;Goga7*iZG0!7Y2|$sYWn~k2oQhfrDw` zGkp3YzvRoZ&%KU;>L}8O@0$#i20jRGU3*-*Y0w&P!-4^ocmP3F?*9o)Hw{ zM{P2*a?p7-mLKknO6@O_f+?x!W1bY9)hZ@`LhZRU&%s#pF&3}Pj)qooFb){>w0i-KJi*1-&z{NB`#vVS5@h|@q@P~?U{8C zhW78xtX@6y1S%^=2Y!GKv{-kcQilx1XG{v$P-n2^BkFs#?H|wm!bIh0MGF;`smQ?@ zy|>wTVHt+=(K$)DpbG$8g1%9`(2Ek{g^1ncej)G5N7k|d&L>%>lmX@$7ddy95GS(( z9V!E51;dAQJdaI_v!>f;dXsASqW@(_i&1#5H$ugT6wNG(`;y4bDat)5rH=t|l#AK~ z3Y!2fQiaU@TOIxl3b2Fqj}$H(%{ENDw13z&Um~;Afiu4fbED=f)R= zmY=D<0AJED7XM{-bSb@24l7NHy~S>Hop?53#EH0E|+VI|2@N+u3#nSxIK6oV{ z=&nnuEFLO{2Wfoe(CzRNT#CfLjeIS|0t}NBn*nJOLYS0Z+NZt(;t#OmDcel5Sj_d4 zy`<)v@6)7>?2a+()!rbn-40f-0bs#+lwv7LaxVp{8I^{DC{hW03y36=xk_SsK1Lp|oJ1mK$@gc*@yjc{0Nl75BYM+W?+%zof974pt_B-?;Kf ztD%faKuKh1dQM=wd4f|6z@jTGLcnrlm;|+$?yNd*nY*%x1>>%CZ3#vDOUrB*_yr_e zblYr|B_H3iY(Yq?y9-s);u2kX=4qI$G2_kDB7q7R3*b-yAW~F-jR}>aLgdI${vTxn z0dmq~-evKeo+XH5>800W*tw`8i=>dC6 zwS*tQbormweFx>Ii3C7c`;uUGl#DyMjwPz<94MW=krgf^wR6R=x6gq)KFU!0^r9vp zk*QpjVf~4i+R{?P1;AiL07M4~;|p3zAVFenPeQFA32a1S?Uj|tK>rul+tVv8X}~=k z`HXb&j2_Pcwc^Jn;0Ml$Wq@V_WRz%W7HnVy7BXICC6{pJHQO~nSQO)Av)f{~Jf8if z8&@R@@+9EBN^f|XR&()QaT4YY+5|#JV4D{!k3wqyhhN}n8~rLI2=PR;8Jt{e+;I~_ zha3y#oe~zS8^Op>ukO3m>*#R`c~slTfR*|)v7{qFkO^g@fynG&*M-_+ju9siRi8&8 zeE1@=n@wY>X!m$_L1~UwgW-0Jn*_d~Hd^&>WYu>9_~gLV&=#m318&b~vi#k|27u8W z7p5ulthfpx1CbzEPEJGc3)g#FKyU_RsHE}l2!uU7VGPvtl{M7={8;ITz~UPY*#^Lp z0Qp3&B>%pC`veFUDj)kkH4zW%ygvjb!Z`GhO1@(t*ehC_YZdL9hNNzUkUF zSe4vz^a~b}vR_az~RM0Ap73Bpm9h z5}}a9M+O-)p~h4QmYEH8=i~#V)kRM0HlJ-#oEafrn({CV)b) zP^O6ai61e%dVX(NOZfvK5@UBA-`(gBRnK#WnKPh3JqAW8(?fMmu+#8F)I|@j8O@NW^`6k}PE`(o+p@bng>ZcT9 z&q!_cJ3J=`oZyw91RkM<>m$ERWiEw8-6w{~3>a}ItFuD2g{q44m$+;TMZ3Dcb!)%m0e9S&- zSdV82;x3<^@`>X~QVH#_3qA)y3ffUWF>ES58sFBibD}99<_ZUXhx#q>*wCQ=7C7g= zj@Y3_#Xs_h4UQZ*jo`vlWtn+!e2*Lz#vud3cJ#Hkfuyik7ihPP2(^d*UDvsK7o-1R zZ2WF3Zw?zmseCdq=NoF1oIiSx?iL%SNa%UTr?SKbfs-F93_c84obb6#^$f39p#*7$ zaDRsOJ~uvc#xn1nWHucn)+Ws$gjwU1z_20b6jx1W!|pJ(tU6BJ*mgBNkAya4eb|8U zyxf?GL31mSVZr*=M-Tm*W) z;3k~h=uQHgk*97aK|R|VC^F-JZ%)OqpAg&Ny2+OEw(JT0Txn0fq>mC+-yV z_|*i)%v2mZJrD|~)(P%`18`&i5|gVA}^C^rcX zXTYE7&o7483U+`!nQUuBh&HKE%KLF{RT0Z=fioXp5F6I^a?TvD6ZC%)A-5to0&}Gs zUt5nKa7Ai%=S*Apyp0!pgMcS&>N8K z3-M@t_LKry^BtxZ4vXMHmQ4CagS7k`E0#$fDc*DQ0Zf>dqKK-A))g>LD=NXxP?PUE zeN??+u@PXtTosrIIdyzm892W&u3i@GIvK?iEAb9@_jmIX^W>Lv?I1lAXrj)D%@72n z+&oFGdylBO#g!ovFBnnB`1yPZLAWZR$M-&hgW&(-85XS7!S#w5^|>b)@rShe74_&0 zE~*-w*RHWtJ%DAdfl|g06!4=Y9faLx&o4;SfE4QRrMROgf)b{I2Sp@J*^_{c$b|=* z3h{;M#ebBRnjNr?=mIKkNFHgtZg5Mv^7mWOkDrv*?ul;?9lfx6zJO+Iw~aodsm$3k z7n^X~5{{x@<=w33UpR-#urrtJ9Q{RoLeKb|Vy79#Ic#%*Jac0ommk!yC<^bbvJ@YS z(|yOSi*|Lwz-Yp{yB-`tx_S6v3qg5$@fvs7))N6KkfQiHs8u}K=+Ym7Jy-R2%3JE) z0+%VP`Fpns{xkqYsP^63Y><0dH{``j-rcE#tk(nnMednJA4}>W$H#!iYocML65LV~ z9b&_?k1cvvtU!>xE~Dk{J6mK|)}W!*-4GD>c+ypwk1J1wue99Ix52x294F6i9ktZ< zIDIxteWCth44h)uZT@N1M<}Ms)49oSOZ=HFw~ie32z+r?@#oiK?Xg*AB8QPgFeot@X%a2vjW9u*=*oBj1~QiRy35IiusmT~>n zSY%4L<~QV$+1oS6UVqDe)S5DE%??hB(hxqT?)l0Z1x(e<;%SpYWPqMac*WOIa;$v?uRfLz(uaCDe0gNVZggUDYIvx?jHm+RW%yIY+@dUT28sI>83p3UjV8Te^I zZX*N%n)eIxG2HE4gw-RpF#c!Wg`2|p(UQ!r!3=iKN}$;;t0#c@)yk-~UR&9cJR8`cfH`7<=&A}$zsIEPyCo+7BmK{uH>z$jZq7usNgSan2J?R`% z=CNiH@{$9WU>_)HZo#PdQ-H&l_8%X9_@L`K{L)@Nh?hB}jR@Am=n`f$f?5?zuaQ2y zxd-td-RB5bNT(jr`0iQFBWT;zwuX4d6QJdG8USf}v0ZZ-!bw7<{9Fg6k{1bY^VPVn zGB&cYir+aRow$M;wARVKSNX&*{V3$S5S-i)k98V^oqZ`!BGch69VE$AD9VW!5~${|MEy>o#7o2}LfH)d0Lz zl(R@gJar`3KcuP_pWrm<TgkK9w7fIdR(ELvLY|tw8%Xh~Ke~Fu_;46Wrn%KHq5X z9lO(5$wT9H-!6r3Gwf1yb{9e}d-!2y&%xN3V7|&h#!j0_hoeo}!1L|&t3S4>FrEy! zWr@?#sI1^#7Yk>*UBBR0Dxkw9`!+aAGT^^dQB|VHyGF*+nU{QK%)WO<*qdSW0ljT9 z2yIVfJCAgCqo$ou>~8(i_D_tEH+=V}({cz`t91>V)L>K&8_p|uPsP!gnhHr#4^wk; zG!*?bIsU6b8kUzAnbsrg|6eKxE>ZOJY*xVAZ*!{mPFZo|$!G_5?7KD%Yw#m%YDi1B zFmEl4hw%i;#%FR1p&OpW0btG%KsWfk!ecb(k+-$978+?49LKW7wP#Bm6~C_sKZ!<0 z1fC|1ah#Z%C)gly(_t?kG|AONLw61`*gRkKYXQP!>Wk~H@+qgDdg>JM1EO3e3IazY zPyMbnzi7{%^^mxf7LezmiLQs@bj|p?$e<7%`}WoSa~blf%uiSm3U$IQ{cKE0oU=ObJ)2IEDP;^G&HO~`&_no$h1c?M)>_b6weqTZW z`POGe#hC2w-G$~P=~R%ocvJ@RbQo8pM1l0@#5Xd$*8s^YU_R)kN@;YeXjzc@BQ0`* zY#W$=)-}V*yqI0+#fzWXd+nU(@RzVoql|JX-@#AsV&l-?(YJ5d!f_55{+5e1LPqdaHLdWe0iESbqZO^`krvjvV-P-w1F}?l}t*+dm-&C%mNfJ)@8$0rvCeNSNYHZ#(yJhi-B>0a&D`qema{LRmr2WrvSnIcE0+9=wD5)Tf zs9ecdMC^A9q*TS07`}^-NHTrPxky_{;3~jRs!32sFt~R&^FEtn3H?EyIVAA9_4!0$ zWfN`_p)7nKf!)OW*)I}#;dA`d6}G=6PW2(E78`-m%17^yEl;f8Y0dZk%x;W~0>GKl z#xDQR;IODQ2fieJeHN^(TQ@nptqU|N{9Ukdzl4s~w16rQ0nVqL3q!XlPM>Y^6=GUJ z5bUE9zpxqbYXredcd)#Ockf(nSMS7nGw#vmEsb96tUr0P1(xc#7P>iMJTqAk%O(`& zE>mJ*QKk^A268FlMuT9`5`R>)l5QX6*`VL4i%H2Zjxvd;GaR>Nz?#@A#whTyGZSqR zMzS~UcD`n?1y`zTXpCHJ%YTkN1wXfU`pewK?S9wkr;@p(mpE2s;ik${m5P27_ilJ< zi*G(e7=J6W?we%{n1=U?FNo#=yeU}BeeKzzfV=xoKP`O*W9bq`u&)`CFCb7$p_^qs zVZM`-Pl0pFR-Ar#h!itIg~4ueQbf*d^BM^X!Z0b-CF36F{H2Tg)8Y@LQ{^)SdLlw@ zLlwRJIv;N#i2p$7Spl#%s{S^d5}Dh3s#tQtd@#O*bMEJurqpj8Jzdq$MU@UL>s1Ia z{yBAenYZ!7?li#5I992@@U4k`g?`5Fy;*i&%Bz3c9)RvW>*&GV zrhPX`{-!ZIiB5X=bH(Z7{go7Mx8Tpee?4h_4ATGX`Ci2}d-W^9Xa8FWAh}mrA=DZc z^|QImCV$!=;>F3%PqH9p3PEXETHyKMCoX(xUd=_ZNHKl=AkY6Cr{|tJJj(j8jI1dvRqZowDq}J&RrlmaESSR)zgiKrlz5Mpy*5(xxZW`@si55vLVN^@Y zEur69#$YqQHVpfVoH>-^=5y^v>EJjy?jI`;ARGp}oF3*-Jwos5FLFiwXgxH(zZ3LZ3_9Ve^A zfj=|tVz$pKzx<$0FBAGNJ*JVy6^$|maYh|F9=LCX6UN^KKKW}xVYPx#3c1}4iHd3I z;2mX`%h%)541b!;<8_R>{}`nT2pwH`P>%ir>cWGx!fDW~gUDx=fpHWY!G&bxUNV{r zd-+q>ivY@RF!)=F*pcP(GB%eXbB_yNh6IU_4>NX# zb;7hdz$$y;Wp8{>lC4EzV`V3kU&jGa&Roy&2?oI`b{!dg3sSRNz<+_<*ADa_1_=O^ zM1CR$g$1{r^Hs-WI%S?=xfa%AfoFAjjLE3g$qQ=&9%1OjL`;^y8&_}kMcHM81d_%; zmP)9V7qgO#!rP8T9&x-G%Vk-LxmDUWKeHD#L8*Po2TnX2^*nk6Xuh+s)VbK-X7<$= zQGD3QA~(PP9OPZ%(55$`XQfg@4hiR*IYjqz#eC~%&dhX)v|lgw`cC26Hn1UN^ez_sIV>1U zg{YJAo_{OHR72Ql@W=#cU;;ciw<3lHFF}LV)-gU=eka!}Ycwm_m}s+*h+mbJN>$ac z7WgtKN^s$LNuS-Kn>hmy&gd$B++4l_R3mSIh~s)e{y-2B!N-J|bWtQ0s+WWjCOxWx zWWu|0;3S17CbEW=O>3d9y?G}KE(yLJQmM4;9Z0Dd$f&7t0tb+RJ8q#w+)-9W0`5nA z)#Eeeg!uA5y4fSC5ZE?18`-K%K|>E!7mbH+>VX3Bh$Z3ruoj+I4&K*RRsUm%6L?XV zg|3M+>#-sYE6>nx-__{hK{1qy2r^V`z0w?mAmhdNtmAV~^14FhVuajB(T+>ttAz?z zmnaYr_WBdJcIC2)aw+6$KZwj4e4{p?73%=2li}oAu@lbd#ykm;1~2vo))CEx&=8Xl zA;-8J+ybFy*P!w6;1)OnpWgn|4Lm{_b-!|$Q*642R}{`3h8W04VLDuq|IVpfv8xJV zAr3Xob^Wk!?t#tw**4Fnv6aWMom~rP`qNqv}KyNTsIG{AY{O^Fq21 z+vZeUFBOr^#(ihN0H=p3a8IJcZ}wBO6NPx3NGi{@YsAq|3<{Aa(x^0BaYzD}cu=(n zEoB}o%oyTDX{q_GME{+~Vn)WFSCdJgkB8Y%-=+}O(T`pAB&)PV)QHwG+sY^qb|YuY z#2L+|UXPb9bSP}nY({A+=q|Z^aKBy0Mky2l|F?N9Xyx`}o0hW!00#qF{T>|&zLgQI ze*#rcrpBBl%0j-v5FLo67KqkD&11Q$v+T4%5=W+)E8_#;2?!QjIr6zxQaujxd z{X+JBn==@E07L3%p>q zEU_UX@bDj*9{w?D$?n}2q79rD{9g19+yWY^cm0@)J_4xEYlR%6_6vwM9wXd&t{0eV z2_;UtK@*@LW^nIFY|u20o0$5jFJbiU^=rLxa%qrcrrT4sX1_Dd;$I;pPVhuBJhTJ0 zzwOeTb;qo>&(afxp>=aU0C2>JmYmjSIY9|*9e`*noQ&{0Hn5`}*w9w@?2^KNonW2d zn04xnhc@P695mAm6$Tv?sdUsko!QohrI~pg)8jDw)2h9kb!sJ0F`NZ2p6ke|?OPB5 z$zdT+Ht4>WY+%MipJG7hg?nqFjja982b%Pyrp(P+!;1~AZ{$_pC*G1Iq>drE7~1Lv z_+gF2>$rw&UayS#8Ck;WtZv1zFE%}a3nAvhT!@$Xouzbxz*qPQ%9?# zT~MrEg05p&5X#udEO$qtQ72mFxL(n^Bo_vX`Z><)tE(n)Zk@Y3F4Lv^4LW3Fa)r0F z`_QvOooG?xE{ou7u;ZO`69pc7&Ly8}PiwuM`a91=|6~@q z){+J%lSjxjZcWPVrkF>UV<*mfra|99QcY8yy}|jtNOdwscMnKe-GZ)p#h@Xxp8Wwk zB9GrBjWIka5H+}k7?4b`R~`VXep=!Ul;GS%71}a4LWaO&Z_KjGcfpCk?FGhO`49rfd zZ%tZUGCvQLp7{h}Cm{;+!AU544Bg4U1D4FfUuY5>#ATKm(#tubJyY(WeypfU+?Y`s z*bif=eij5)?^w{42A3d$?ViJfI+j?MKhd(WVuBGV@Z)vqLFrJK+zd_@HCc7QiC%s_ z?Z;Wb`}Fa`qJ#?9L1^!K`qK~k<|Z*j5c3&b{6+G|j=#67wbH?$4s?v1?~hXP1KJwL z8jBAcD8xs{(-Wt4Sq`N1_-Ff+Z4z54ljAPq0%cT^5ecf`yLxG0I zPGdrjnFHLb(&o*7V>ba-zm=gK@ud5Ea+BwB9|f#H0u5BTyTfFauo6aO=nq~Y4$^qf z;AZFzapQ#{@}lnaPP_7fZ8koYU+C#K6{q` z)-uSo9J(*}KR){)^^r6G-R0AuaS2ri_`{XY({c}ok3nHD03t^@8GTFsd+Yn*$@k8n zYJc{M!-Bru+VPX-dOK%ezuP}(-Tv@o85sKa;f*Qix6ez(Wp7wLkR`!1pnq9Tk8p@( z5`Vrs`NQ^13*o99NV5ahoGU>J}S5~}OZAB&Sv%kA&d2_1k#06QHb)*+-wjYm}jn`cJ;=UjJFJ@VUZvUn^}?^f;>ju``Hc?0luzcwB{XiZLON zA>4FdxkH&{`@fLSKTM0C*56U7G2MS^Ol9}tA3TXUuKM6%@uYUj5trx}*@zH@DIW05 zQN0ogoWyum$%AA|OHUKgL-1PW`X_mD6jT4tb9T{BGm|qy^Wn;A_2v8-jZL@G>|5=f zRPU%db+$EkXJlFCSt{sy4LuyDkBk7QiOc^#vHkyBbC)Mp0bq1Q7sShFFLJ+0M8sGR zi_j8h=^#o7&=p)|GfRuk%|m$NiW>fvf7cYUk~Ov%zKq;*XPfG%H@zf?Qg|MvQfuzJ z)`!y2ZvWrXMtxxOIh8GQF?HFhKK%KseHCmbRS)7a>Q2WfLc}u6@+z`Wd`#;cGOaiV zrq7pGBe?C8p?tl}#+v~wkF~kkm)sEEWIy656&(9F;G%MqHMLP+q8!Wh5igb`CsswG z6NOexAXhH7O?#3n1qVP}=zWSBLol!}YGtt-0c!3N1CUwfLO9BA&`4 znTeMf(@^GNI@nYMRWb%;k<4ZoJPt)cI-HI{vD?upwyvAUG>a3k6(-zBsCb8MBJSUt z=Sj*vRi~_RV9FBcXf=KuG`Y$=qH$VDt(?&nF;FWFC_Sws$ce#GO@O2vf)x980$XEg z5|mX#^`v733q?g%>Qkk%+^taWq~swH3IosPEX4Zvnv(EcS*Gk}&)rH-YxQZQa^lvc z1QfPI1WNV1{^>YD(Tr#coBJvJhyecMZZKwOQI}snmpz7pSWo_C3SXd9!(c|LTFj(pb=L<9u)CX)jM*_vj8G#V zR$(k-?bsg$2|BMB7|C@9%7;$+Irp>As7}tV_vFgK&HzIa9yOflZK%9OV86;iPf&S-od}KW1GQ zFq|p2GBsOXkb|PWE{8ls7_a8E#oTw(9k(&<7TyyVfw{PSouA{9AQ4=)45XIN%0XRl z?PKL4KP!_C45xLux4xGl)A_iy++$_WCu-Pj?2dpmtKtW?%b+N4o$!;IMW-k`qaTN3 zUzQ8L)LSt>dXM%2A6dOmF4ld)j;2#RR_@Q7zrNX9S$yhq&nL?Cf)FnT0vbKzY++87!2uZ@IhFU{cXl(v6(O-G zWA@*)S|u-E&Sa}pKRub=ll}=qNabYHaa13ua-s+ppZi0>!8W-^z6aw*u zk3f!)N;OEU99+2&p@55xwwr?;!!MFeU&&yDanIDVgBb{TjvbkfOnbFJ!Oe&I>=Sgl zm4%L#yz!iqLg(5}ex>nrnXGup^3O1li{NAXkA=^yq102c$VZ&3_Cin<9tJs_4cBNt zTR)p*paJbVLAm!E(F^@UJC4_he z7wW=mCZ#dJ_YbR8{-w=4REW?ua{x{fa_YlF@1eFSk2?lRAZd-?3PPZcV3%edeX?!r zKt_y+NS?7;Ph1W-{x>?xPuS>pX*F+XZ+YL6B!|HFY#kF00A((2?1O)W})x$HnYA%JtB zgW}!7NZ4AW#*#~6$*)j-t*#Qz;2!7T6D?OAfwUXw(dgt~b5Jwa8?W~+Tt2S3L!cu~ zjbFH&#RB0Gme0q$_GZ;%4{5V~sI&acdY-8DU>(B17|LKzX)a>U?dbZP^gYZS9@-D< zx4Uq|e=txMUTp_fL;~C8?V*eao0r0*)`s5O1)g96w&#}CuQh@yE^@L2B*oUGHD8Ro}CxC?P0wg zP^22}ADO_pDJ~)8mR8*!nSVY!TP*Ash3{#nuA_ATv@gJnyr4(&yyUbtGV8MdF=Qt@FNlrOBUvkT^2d9iB(Gz~Tb#+Q^-9JlY^KiR~k z6(HJu`?A3Ag@#aet~+!)iwC8X#VMz6$`^)a{iPSY=b~ll6&}$F(y+rfCGOWPH6H)l zPc6NV5g>MFr5)$secEZ4e{t0;%!gxC;sFM65f%DLJW=)1Ft<4Qc|#twMePCKV# zC;iKK)uL}vY}mU<(8zhAn_Y|cljyPP%?zDP^wJ&LFC94+ZJBoufrnA74i z|H=&2R-xOF4_E5q1Z~7(Lz5-4_o7X)7U|(QA}lTYT309&s`C&h@i^sf>{w z0hFhfuppisUwnJeGx`dB=*GVceY2(;Ws>tE|7~5r72xwd23h?a4Hakf30yCHp61)n zppT4+zG+9yd^oeJ8@Zc;GCKr4B41A4GS4_T`ZX%Rp#9=vE$Tj-HOBBWK)6IKjCo-g z`S1-vE=62uJO5#Lz*~3LUD8=`3bL+4rO#jb$~biFaqJ+hn&Qj1^4C95pcs4vqG1nN}xvn&J3n$i>u9_=0Ano327&_EL7XF9=XQ20A7r#}Nm>P&qGja+=6t64;Di zZ^VaPQ}T2Z$DZYs9p>DfymTd4tA7PyM965dkT&ym<5r8VT8q_s#viZ%r&uVViE#WO zMGNpa37F2U6*STF?zml$5Xu*lIWl6=8j8N&p-w!kkpPb|1zZQ73k1H8%xlKxiPC@^ zN0}TyPz<>sksiOh4>2Paug9@tI}q*DsRG8vF;<0lveV0_A>yUE&qhrV42UJ!@-I=v z$hgQSxF~}JoE(^FGXKqw&vk3?(;fI)&_O&R=mH}+qB#d^AhfH1EpGSQO(QNI_* z4%WCzz+M3q30EMBk+Hn*T>0oF(KNUx9_~qo-$JH`;xoc2(OB!^11se7w>gVzsTU86 zmEK+Ag$h#A1=Uu<*cfhd%(#qlupuuSj#ju2*bU)IdQj*9ask;rC87g&X{0Q1q`<~f zPF}ry3@_@MdxXL18GGSDMji5aQfQWoopFZ?eB`o7Yj{GG#r1wcuxW7>2Hm7*3|6QjA&mY7m$$8>TLoos9c;-YL=pL{D>>^{ zCaX{g|2V}noNl;JMt1dj(E0>q4~ocoh(NN;bic+a_u|v;K3N?KYH&=Z<%LZ7Gz|;U zRkr+R){-jL$;nI@QO&Q2bk;EQ%&E};yDU_LRAw!iShs!QXt^G0YJnibLJ9C_6e}7( zit{88w`9pP)yY4mua|U62zAP7d+7Rq&ASJRV9Tpp6vkY_DSa?w8)hif`q~^XMaJEa zR!#Nhs?gZxKRr5uE4u=#Uv4;buhhMDUAXteTR{KO4+;JijE={RLqQ|fDwN@g+>_5! zbvt01B=Bc{Lxj5N_bBLN^`sumr5ojbTOk$!R`}QO#&9OYw)*O9Zggb`Sc_>WTGDi^ zGxhHp>+V8VKeR6FQg%crT9*Q5(}U}F1Khb-Qam^RuF0j|Kw72u#*dKEbGZE|>yahx z{ha35^~N5?Sw1?1aIxi~4KK{bs`Xo&K~2k>D|HHKkZvnO=_da7*6DC;?NQp11-6E$ z@--q^Q7l+DylcvDuK9Y7$c@SnBr9q5aV;OOx${2swo2OV=lyJpOSdJW9F8yQea!WU z{TeS>14Na2_w>7N$@--gDMH^sXPbBvdiIb7xhf6MrJY)ImcN zmnVt&%afvsdP>|UwXAN|J!e#P26$b z5}bT~)*cEw8OhgsrCV#My>+ZZn8DEv>2z&#ubtIZShOl+8a)Z+kiBvw_D!b8|AS;; zVoyexP%pSUDLA?$4l2#;0lhDd_ViE9)w0aSef@28Ls1&CXvl#DV<>)d`P`ZM0~v{Z zzpxOFR89WA(4RpqRU-YEZrzwLG>V*CM|N9Quf9dTd-@(A!R)8h9`7|78221l9+6Mg z(tILJbK!WPxD$Fwr~bq=4n4W9m{ewz+&{?G_gd-qY4}up??usM|YT$T94=liTrM=Nx8rNn8F=87Y&%Rt)%SJ6HWggQyC@u1;n5YcHaBba!>5o}=m?-m z4Lp{Vq~@k9Z_okbT4D=m88iL}9rk1YNfz;uVz+y$WoT}OK`F560~lhEwsXBhWc_Lw ztl)lN`!Nt6p27d$%qH*bRw>xaK-`t-bjkDxq#W(rPtdGJYtPR@97iFAo$Qs?N#8jj zs$w#U1&^G@>^KySR02V!8vIJkM-^8eaCgkM-Rm>GagV>;ji2es%>e9}Pq=7M8zu;9 zxByLFfc|B_i{)q~vX2dFwRELVg+IP<@JjJG=?b6Z8oz6jtHO*;! z^7kW@iwTlnSW-O=mSrrde_B#DT-JWMg#5(rMB>R|nz|Km@ts~guihUt!2u$}J`EP3 zu9#uiodp%aAUq$Nlc}7zMDETLu8t+0)62-0t3H2MN#4sE-cUUfoTYW}YuFpBtiaAW zy6naLkX2G!J^ou$%F&U{5xlBEI|8I+uAPsOfl7f6!?FK;1VBTpzIAJPLu)?mt6U5y zH~FcLj@norE!ggS0&#@4uA(X;}Vc1or!DNfr|J-`d~7Cw=)Sy0Ubyxy&#KVu#;Q7GHk%X;twWLPNPu z_1~NCzK&n(t{fJo!fjfD?xY5O=BQ(boO6QWxSwj*tqO7 zk7kxDPke635I=j^y;bpsnNv=(+@7c1pQtRBiwgUvFYL~+{F$wV!h`LAS1N{J&%Vze zxvPr)eHPE*`s%a1f9(}F6#>G7G|A@wJl*W?sFz-ZjdV*Xb)=-pt8G8rQ9cb~rO`Y* zyy)X!4+TFZ5I)^XSZkg4b$qt+dXyRi6tdJBF`q578%qVxAWo;_hTvGJ#=t<-^wnEr-eJ zS#N6z{e4^LA=wths5?l!@FV%l4UOYl+Qr{}E^mtA*F{PXCB2ACzOwz_aCnOBeKCd7 zE6=NWgNlySE;}*pqnYWK_aqm7<4k@xp5!vO{60d~TDCi^`uA$MeXl|{589|KvGL-? z-FAhF67fRt=;L6-<%8_c-|CcK%ze2u|K-mkEpY4W)lYQ@<$ueRafsZ{pqG-N#leVyFwCfN;iLYw*(k`SY68{ zHZ#yre{cW)MiJT@-v0gP^$w>AV8Z#>>-5_`xpkR^oqu0r zx%qOKGFL=nY|A`@C+Ko|ANDA`oTADcbwY#$=i3v-2irXQ?`;&Mizh*k5;P*+3kxl+ zeda~pJ3XOdNvnw(@s6ysnce&E?|Rx#aii zjF-+xvG|0XxPrWbNaUL$$-Fcf_j~IXO$vwf7z7FV6RvZ`oIjy_84pk6WHM_Of@P9V z%|fxoUUKqJoZK76CJ5TeOlJ$?iA4&Z)$?FSm1lZvx02C{=q2fB8RWFJ-zw6&p z9^Vz%x@IBAL*tAj?8dbI1y@piQ$~iPuSoo2O1?u}D@xv(&L)cWcPyVCDn%Fg&D_JyE;;%1` z&$51^{grQO->%r+Qg4s(vh&vg8^iN$f2{fa(sWMnyd_@VI3Sgm%NH=^9V^q|)!zL) z{;oGerjYu})-DPm!M7OvHlpv$e+}Pb=22Y0=S|KjVykLx(sr{7IEY_tUvep**w zHhTQw*^_^-zFgM4^2dMf*T7%EY~mZgHuaQ2@#TpdX92`8gl?A%$$~_4Q_ewZiS%3xQqrN^JC44`HI85mF)(J=tD&t!Jhn6 zTcU!2TBF_yH-)^$8y%NK`_8!aT)vykjn0&wYX0+-BzBEK5;HjAs(w{A@2-G^|CGjx z5HiG%k#5m0e0a{1U22-dBBiojZdcG*(xNB%+2=g=uj^8&mzamb9T%qF3w}xyQ}sVX z3P&#-T_u*$+9d5mQmrlsJR^0ANdd7SX8gBw`Z3=tRZUqlGv;)#<-++;Zw8 zw7U3UW7-w3w2HL*{U%DIDO z%k~ThwzfOSDPYmxsu=?xUpx``Fq*i6dBX?O`Y1q`YFbSMa+sRN8P1j%M@Y8+QiAYf zVV9d5U#MQ>4xHMXO7mJ~ofXrBU{}t0J0(}*)iiUSK41cRm}=usYYz2B6g;Gi%V`gb z4ZeBj6K&?hv+M^p8hqE4Mt&z>puTgr2WJ)kuKL1Z6|BzV!Y5a^7cMV9M>#);RfVkUmmSLwOJyS;IY8rgn8JGvJO6l(8kXm_kl{sIyaLU+( zB}dV=7XNUlTbX*>(wkVW)Ys9Y+BY#Zz^Q6#*l3Tgg@CUXfpJVwdwSBk(;Wb8x}!}Z zbmN)Iihnsx5I}dBX1sMKJXVfPem@|Lu*5wn3Ae{KwCjDB-eed-( zWBl!n8^7*BOfqjg&zd$3I9kc@Q)<*AX6vDuo%4ScTs~~+Oc#2?BP7ly zF(fovHWz~Pmk_c+CqsFQ7K5Z+i;PCb6={p1R~n<0?_;R9UJYIdcNgHlzW{BWgqhHy zlI~tRI_}7r3H@S~`5WRjZpS~jaYZ9jOkRA7k{h`CIpvWKo8wgKXq1si!Eq6l^@l2q zwa@2Vpz8MM1e8sMs&lp(9@Z+r3bklcljUNvkF_RMU5Emi;f)@J))-}&jU)q8Y1 zNYC{LAN_5AZ@l<-JoNOz=cuQ@U;qC1gTnUkAk+5G)+yS_lBHl}r++`k(SB3e9-U0u{yVCs{n@j9^o#!4J-$c#dvN{HpIuwpuNSm` zCr=;!`|*_a?>CJG@DagUM5qf99!*465E+Mv%g)ci*}+?H9uXl-!q!7Qn`2p=@)w^B^={J_l~y;b zhx^{mR;UKQelpy@`;=^yD}3(m?f1{x&Uap%yL;!uT95bajdS+~KD`(U|L}V5-r$!v zlvE}WoBMR*+*GmrrTP2AUw0Q8t?FzZ-2MJxy+8QP{DXTxzEH<+0Ij24cN}t+G*P^&^zASzK(^< zz9kv+1imdamui1|;s40D5r6!Cw~h#x+ass(1nt#lNp3|9p2+{3o*f&o>4&IEW&WnsyMTJpLH1pXl+C+CL__MajJnmNGo?uQxc2GE`9* z5A&?g5ryRFePe61a)W~i5^Ac8qZtx`t9sGqO%vsGyR~2%TfJqm6e8h|ORv~yi=eM% zt!vTle3R-KL+DTcfQ8(%?ySG0IocbVq{C(u)^E3?S^qO}>Ay1}^*NT$s?JoDwyfRy z@{f^&f#P$n#-Alq;fdtuEc(QS^NB`rY?wGAZb4t3ZuWnwa>_E)s!BPq4KQ@7`BRY+ z%viK}<9{Zu6|`Ph(HDGW{xz02ZDFB3aN8zK)8l0{G+l4u!r7gL%rBhJx=<6 zyrFbAH}P%69)4YO)J*z}W(#?KzMnpENuQ#=Y_{gx7Cd}(^tjky7aR8_+fO(FDHUDq zAp1P(QsR^NNOBTW$Ap0}tJbElFa4EoX0D|>y>$4&0Iyei9qKF+R;;~%jT0x1^JJ;5 zw!I2@(R@tJeh@D$md-T8h0pjDMsCbEm#Re5QtJ-0W)lw2wOud}_t{H>lr&2<7kNZZ zi#WW|wy??(o5;LiAc&)il{Lh?->Du_e%@4ZGfiSK;AL3(g#bqlDikL81i4F2bIQDt zDz(JV2)+L|3-2lZc9D`R9^ksyTp{LPQ`vKCe8~R(7Lh}=h^o<#jiDUTNjT!Wn&X($|s8?61;|wuR+`mwc zy=Fi3k?&NW0=SHIQ+lChH9-TvI3(+7Lw90601T{9xx>lyhjQC~+*WObKyft!7}k>V z@u<4qt}8T$Z+i-Mf64y$(R_JT943v!u*<`f2JcdRYRUx9bf3apUALI$~CHKH>Nk zQM`S32`l~Q-GUoU=wwT6U+$~3)H4JKCdf2*@{Upew8o%M_yQe+?tS`hN?zdS<6DGc z_{c=g_0PYG_6%>jy^_gCefcmnCj8s#(a{4muiM$0-v=X~Kihx#{%%D1P@*a%COxYF zuCnR%=BEt8vIhNU>-^t6KA)$aT4Wk$aoLrBKX)!!phKS7WmbKe++pI`_j&Od`e}PZ zS}gdc=N|NDvHd7QpO69;I3Oae$zV<`tfaMN!l{OW0xGY{Hp5$0s|Jq`9>=o(vTwyh zJH%75%rm>c}9fziU{At+E3fgvV?h!`l3)=?n|ItrD- zgRt7t@sJrD@NC^gf`>$dE?#Aes0t8&Hl1qibN&XT`zN z2Y^GT$_rAF{}qW~pLhxMS1A3DDTA4CS-mTaHKT9c!iJ|OU0F;r%bMYO+NNzV7p1=1 zl#}jexm6`$Eyi@~wkYcZjHDKki2Ox@F|=X-D-tP~e(H5h1gRd3fb2;EQI)~!OKHB+ z?CV6m@xs#HSn27#5hd*%KW~pz{yH%eeewCFtVB1lOhF$xfJ$T%<{JY!p;CF7!|VR$ zwd+@+iAZxilZ;kiR>hbAt=+n8HIIjEKiDd5&y~uf$ns(Qxz<3**Bb0Oe{d+jK`WPW zfeMY@H;d0s1HC=pfoo#jwHhL2MfeKr9@LZAz8oHdcr0q(KzzUX9X(dA#M)8>-jp_HYw0NkoHEJ5Vb zU%3^qTyKYSx(us56~cX=jKKJIg~Vac|JR?P6)gX=sih81Pa~<=2S`@2>3+_>$_m&S ztnI&e6T5VKU2VxL!@Y3Dl8Q9M8;1DKt|t_%Af(VT=bfQM9)ml#Z!^BiRN%XQ=nHJ!+B0T*mi`TVJ9TFer@o+gjC31MyWm4FaNskn=ePRxJ^UsliDDZ{0@Y>a5 zyCw4~3&#F%{{wXPpJT2x4&3gwETy%Hg|5T)*e_b)KYujPvEaq~g9?*77-8o^_s}DZhO9e2 zlWJC{jw7G-e|=uTX?Sg0@9p~Sr;cKr(@!LU12hwzPX$JyARn*No-C;HAH6=wkRTx8)IuMwiX2{3JslE$*=&Z0KeW%EvQoSn%f?gSRUWUiHyq zsN;c{8m5YukzwIf>dl5#6~QA6WYA&FhJ*D44H9*DxrM0E>QFy@9{%koaC0^E=4rJf z&TCIx!$Xyr@A>K$R$uE+f!Vw+-WzUKy>(w-d* zwIc-g60XL>*SHN~a^w_cu6T>9y8o)IARxh^vk>|&M!$wu*Q#0bb{|xu$3}|y_~rSo z{z1s%P6A!Dp&bQ)2{CU6VNI<%C1s}kzV=S#U=>_4Pe3x`0)mH(d{n~vlULd=GjOd* zC2;bL2bn&*A^!&b4<}-rOaW#LKrK&!ko~ta0q!1}FC$#KGd!NWohaiA(jEk}qd@wE z|40ta`9P1>($1~NKdF!Oz#G~5y9s$mi%>$N#5q5e`O9Yk-pz5ZOn^6;VLv2-=;jVE z2EyeGk|zVYNYxwR@vIapP6AXx9Z)&|L&zCmG@y*iO5uah9J59;!)yaspQ@dD-JqUn zc9l(>lZDfm0ih*T3O1vmZ97GrOsT5T-G{HQKcMZW3El_;k5Jxvg z5Hc>cMUaQUW(S#Tu=I!Ga<>M(pK}Ex5SFDw>GXIBz1R3_Hf@2`Qj2=}T3Kz7XP)8bsHMEMzcb<>O^QgaE0CokTqZfB^2ga=VkRUo6=6XNl}TjOc7mZ! zy?Ul4EeU4CfR-vCb*fmNn8Fxd2xYSH-#8#LT~IV}<*bRRcKE5U=2v%rDAR)pbVG$9 zra*o#4gvTwRAe9+GBjFAJJB&g>meLy$h$jEm2Yw4urN_@p)A?nt<1#;XK3Y`3!#=M zzKc*T4M)q$xc{U%n>i7jj%^T%;eUw`>uEKaeI-JuO z;MI!s19eLV$;$wga~B3~Z|AE|2m5=}#MSp_@qlXbS>(BOeE{ zyb3M*Fr}sp38Q-ieNiK7dP(N;Io+WpBLq$-)OP~Q}YLOdV z4wYO6M>`V*WUUovTnu{(MxUqp-1b8`M&tY&BZ~zp_WakQYMWzHjqlc)#1;o-LFuJl z8LC=GvPnV&*o*Fw!9Zo)!VcS^nH^D-UHg}VE{A2T9EG5n)Y9zC!~^?a`55_EjYcoS z^1gFHd}6|rv|4$j6OAqNL(TJ*-vBFOXi#ko6ic_v z;BKN1z*usI6uFR2-_s+3cy!e6NkF28pchM_MidjtZ$_Izg@->uUuAvo$JAY)xiCgY z&0~Wlr}K~Oq8<3+o>tp{3WJzmA?UvA3c?(c!V+OiVh zKs2L^AehFhRu@#Ja9>t8R+3iubHvxh6B^7yN%H2c`Hw~(|Xol`3cYdkMZa2c{29<1y z%1^4iSJ?qhVu8iNaJoeg7Izblff`}kTHK*QPE1)Q!h)>K!?(@v^Fr8(tP?T1teqZzczU(nLe6hFJTbuv?wcxYK~3m@FDkTnbKt-~ zBCZFv9!JV)wpAj)EF3E_3vRQ150%YH^=&j?x-ui7%FWrQd|AyrachJ}JJHZOza5!H zlPpFMOWu!n`YeML7NV*$S*@8d{P^o_poBH(o#mn%2|jn8|1!1Wf(fDk3@Mz>MJh~( z90?TCbs(;k3?&LM=3{-^7u@?xgswATC+8jerKaks;~gQ1C6uMyK)8t=o46<7u#4a_?Fub1v|)J=&C1PyYU$c68{Kt zM(3=-?vWfHIO8C4#2h25+sb74*Bo&@#(UMWsiqY$MqGfQ^c^1N=EU#XI1(h+0c4KK zQpKlYQHp6L5LL`1lmb2@Ps3Jw_&zg*aN=35@2k&WlNVj{y!2KY*9=Wow|};h=*B(k zRu;ajom1WUK_vw*U}fXctNu;qSThWK?ydEGJJ#8Jg5&*mT5`ZM=u`2DOB%)X?(WzJ!N98r zB*z5n`HYI($56SRHC+hkj9YD6z~bjmCIVFuG-b~7-J-b~RNZ$W_2UCr@0;zOm#~s} z^`q9JQQA!7c&ytNbWO)pEDlV&OFA8GO{olXlmd8AFTQ&{8V(45dNy>+1g>!ui-hZT>hCp4lo}FDmeNwDc(uxI*wR_+{V%#*h znxTwOjhzL||1OUGjq*ufI4lX6oOU23GV60_hT27EX2#l&8?l;Ah3v@(33DZfW&d`b2wN$&9cc_9Cv$g47gyoXJf%!tZ@&-VdMEfFMXviz|jUFT-RP z-l3I?M4{Wg6Y+Nsgi=etx|m}>3`#Q%`qn@)e3lz_(J z--a(6bhS@8?E#$B@2fE++RFD8*SV(WAsPs8u<4eR1RRb5rCKki8>IUqeq6Fa>Dvo$ zC}##XK{J`2BpCB2h$tkT?YIyNJ^OH7k#b99)|AR<@k$@yp<3&FB;AKUoS8Sv)I*Di zSWONZUV#BFB$x&;9q5uz)Vz1<=l7TVzPyuBP8TVMOM4rI?QASRbnKaZ?4@Qlw>GvF z25o29WW&rUzXy;=GcYtQJtH$+K|#?3CqmDi6iQ1=n3%9~af#Om-l!uBdNekXYg(&f zVpv&OEJaFsd$0FNi&)ykh&P~60KlUrZ?0?zfpAaHOmZV>+=j|vRk`VuOsq)>Nt#6* zXreZvxO#e61m840@_3N+`OCrK(bxavPLdwb+tiQVZvrDA0zQ`qh6Ig-txN1*8qGvO zz(mp(k^_!Z33|C_{TOYGHe%EQjO~~>V3H<53uHR9hwkLg`0zIv1dqPDed!6wI;J5(5^hj46gGd~3lpQE=IEVSuY1o2-X zRyXeI{jAmv5@KW*vzOtkdKZwkW>#ieTxC5)14&s!yV~jj7{Cf;vY+WcjdyjI&dP*P z*hXLME^O}qHWk36vA@IDzj}e{`H_`!hEF}d!kc+I|CwrKSQ=<`B1cX$2w&Wv;7W?@ zo9Pd9HcEP(zskh=rl!nL#2e+yWv_3HHVBb3N2M|%z9oZ`6Jh?vkVFgP0*%+CX4`8L zMSN@5RzSzq9HR+D8?AsEe7=gn0wzRb{^mFqhAE%)?h7zYQaAe3MbD$1}b##r+ z6yr>P`V?0MT+NZ*nu1aD*#4%Bl>-NaDunFRLMDuXqtt|lC+naY3%m{Em1G^4DXb}} z*`(M-8WZ7weeXqD+Dc z^s5$uBKwZ_j!Ndl*S9l}o*>q#$PbG74VNnyBA(Zh$9wy)+Q~?YqpO^5&4c8>=#H|U zLL)9M7CE;aC+ae?iY=o?9OlJvpGfOEaMw5nT@5Uc-nS25#<_|OZxUjL?g>7;_RmPD z?r@&zWA@{SEV=Fs4PsTNUeot?v-pA?C5kJvN6*Nrn)OsHhjqtSM`l54@&q?;=xr=? zamy=W?Xj5CUD4c+yV)i*TG4|$#qlgB zA+ROv=|bkX*>0^2u+FfH%^AKSx#(tJ&F8%FZ$mO0#Qp?biZZlr9A!5PsC~@MllBSJ z#Xcq&WUNKT^#hvXm{gyopp7xW{HI_P8`v7v`}($X?KN%Dt(nKp!%X8gn~SvpW?|7u z&H)k<_X)8D{K^NT$_r@Ev0%1UdWjR?ijADT$QY!|$Z3rIH8-GK7~6ctA?_})Yg_#f zB*t~=_aEx_bFm80{E#wz4TCGlj~Qxw!x_}zVPBvntYLh#*fjpSR? zXjrwkSzt5)Ht>q3V1Fjag{=Z#()I*>IgO45^r0yJ8b-N74qvpPsQ|~`w3gl1H)jAo ztOo z&N^v;`v4Aer*6%`$>Yb4mH-D|-FrB3RJe=P>x|Df({%*XpNRI1du}#$ANdrxnsaQs zIg$}v82H%@fMJ5@@^)Sz5oHlS5Ce2H2Z1^AY(rTl&A9K^C&*o#HIgPKBJ9 zmeAI}**q*#Rd^US=ED<=kpEzya{t`hb20}+<_vqtOgn{72~Y9T`5fR@~O!WhIN%^KjrMQMH=y!u)59->qbYP^V5o zf4w#yJ|t1LmT|~XSMopuG#;*k<|nc_VAA4E!N^7I7JC^IS8yMTnsV5&(<{p3(^K>O zpq;|p*E7y2h^|K;N`NGEie?@I{Ho>#OsX@EZ$iHYUJG>lvdnH@xD>3Dya{HUA}!IO z(F`_){)`FNWJQ-9I4%OCkldi|B=EOZL+lf#G(w3uUt|6J6#u~KW&r7eho7pXfnKqS zuJ}w)Wr|GTroxePH)G3$U}{<80{9uis$G*rBNIT!*K-O|Ya!7idd)hD$@6H0MuIUU z1E1$__qk&9S`c%55Y9+UT<*L?1+OCiGh|*e6F#eLj=QH(AZu z!w1<94hWLbz`{sCJto~?%z^3Zhe}SW!@ZIc?CHPmAZdL$IFzU34(;xTJP_V^gvFPj zDu+hyw2&AIt`%SEL#^-3QDLs02ka$VT(TEe_>}`P&ZCHF3?5vM*I({1Y((5*rv^R1 zn05vYV?d`ocsl0(1WM&nyt^ceuZ`bceJ@io{!DaOc2es)SEb3azi6fG9L~?^M-E^O z7GN(|SC%F8z__t;Dm>aB`)m6AWE-^Q*zuw@svSd`^HVk*dY`n|26yS#1oEGHRenun zwTm9~ffOn2Rkm7=FSV3%z*)z>lB98nmI=S@@@eHs-cQi$E_4BNp0(=R{J>fZ12rfLHg8NCl7iQd&B~mRR8`X0X@Bg2+m8vw1=n8=enu_DNNC>Fo?uh zSjmxuQ`WaDI3eRmbdG7nT?|cU$L1@Fb-gE z$3D9vW}*kml+s}58`Qkdv1!1Q7>Z#qIEgs>JsDMmO{p?(fSpzMHW&7G$;X@w`F~c- z_Q&|%JUjcL+>p<=msvUg?-nCT-KEOY#%oEa@zbeH!S|*OzSaH88Hy@bgcClqo`J;g zF_pacv6IV+I$TY@?|w($1#8 zMRPtBr03cvQHBz8X4=O4D` z`Z->ih`s24<(v~yna9Ww{WFUP^+@^pp=Y&*zMFy0xlP>p#W3W0py3vu5(=bdCg52F zYYO*M(gcztVqZu?W|PTJ%S8S#VJRC398))8XaQr_FECHw=JBBw4haf-PQsbV8dwMi z3FefQuB@8<^(&M30!PNx?A_Mj$hT3o(HVkavh`Z2D~6%xMO_sMOn;)l*8-5&MMZT- zQ?*y{F?-B~jX`$x;PY(&w*0hn57=G}@+=&hf0C5~;+ir)ivk48lXWYGt}L_}(N?oB z@Zc)Ma%3d}YgU|ajIk# z{9CiI2b(F8mMbxkP*OsiY|gUHzV3dIMK@q;;qCvlx$PPkx&6$e6bii{hs(IA|IKjw zgA*9o4bE~9_HjrGt>jw;mt^Cyf6Tx+2Vnh!Xgg%!EJl@D>m3e<@60Y%kMWU5N2P;nxJE~WpV22#g`itwG)+pX)8$dB^_ z%^k@EMw2x&EPT^W+3YtN$d)T87k&!^(@(+B2g&@uPGb>(3tbUH1~Fh-ysG{qJ8@Z# zse{o#VgTf3Y0LY-GH)CtxKEv@2VnuOJF;l}Z3cQ-1a>9>tXBa}fX?QF_{GBd#}W+% z@`2dOy&Z+sy&CwB^M&jN6;Wb02h&!Q<*n}5n_vJ>8b(*P*5}q zwB6d`!7YUsfWiq-SG-r40Bh%#GEWZ}j_E>E-8gZ;EubULO`4yA;6#Jy_`g~KaOZx9 z012|a*7?Pr^zWIx2N-iJ-9<+X+G^1*_Kl7k&@t+LLhBPcqP!W{s6$@O$u_VjIgrMElvNzj$NrCh}wXHj87&O5kZ`1o2Z0)Cd6l0AkB@hcy^%#98xlqx%6#PKyj!I%Am8xDb9% zE!}fZy&WECo>C=Bc(b2w=tCW5i`-x4XCYp6C-&lAbO=zi5*A`oMqqTtJ0~ubE&*c1 zYYaX|)O@(JX>@ri1?5h@HqS{v>;nQ&wMC@i$P5~)UKON<0eNl=+f_ph$NE59eM(F< z*%-frA&&i5SGso>KG&=t9!vxK|6UdjLo z{8X+xGZw^)X-J^d^~-~WH-<&2ZfP=Dl`+UxAfQN~VCuX6_yZUqn{H)5uDma>pt~yunl}u%W!B#!gf7wv{(6*!pp1YxwPe?pbafD zJrWN~t;W%MRS>S1!*!>Uv%VI2#lv{<6LlX(-(w!PQ6y}(xTk|2-v5of zNO$TIn==K#H+5<+j~e)dOw?L&i6M>pqn!3JGN~i>TLPn{&jR|xJnTeGO4c$b)8mnN z2l#B_8}yjt{&d|({x~;S0SbPa3O|j7E!T{#-Gz}46mR^8k2$7oJ-7T3Y)^u~sNAmc zw<~*}6jPHFFfL}8^ku&`zYPRG3gEzubSd;093=nJ6%YQ?*D1}HK)R$B$0t5AJCzOLg%gZrx8@Uae?^QA}j73i^%Owv&&nyKe?f*wV!pxF?vm&wzY6 zDZ~KfG5Z5ala=>DHwRo9g?umbg6coeuLT|;P%V48^ZnEndQosckMq1-odjjxGhb06 z#E+fhS(@8SUJdMu+xsqyL4wJ4O1 z{ZsRo3AayXXzLGOtyi*hcH;mzj)Qxel#V&~-Nj`|XS!PeDn%c>zeW4p8-g_oTVbA= z2G*4t+%_c%U9WdB!GCp~4YhTIjZRp?zgy3p);0eX=vvbQ24MupOy z0@dD4V8XR2#RB%`mtO>Xx*5UxB-8iP_p7JmLOs}vuJX-1TR8WPS#I}L$e`bT1vBc5 zUW3D|8KtKy1bRWf=k*`xrXW0PhEtq{Q?4GWGQX&%%qg0{uvfkPEN|>}d^ZA@KzESv zlN+6JT*G->nYvVVxP+-PNc!LK*6!-9w^Xma`<%Mun^_t7wdEI+K0*bX)974oJmf{n zxiYMgG6@^{{}bop%IL!%@n zqewgmdhWtl^D+bg=iz}opV$WU@?T@VBP!oB;9p1AE3*j(?&rNWT`-UkdZM1i%-$uQ`A4desdKpxY^iK10( zRLKYnf{^;3tv$3se-!&3z77=zhZMnt-A33>L3RW_W&%01(g1VO0n#7N)eG;!1a#Q- z^!cM4WAuEL=)aQ%z=YJi!g|l-C>}ED+W!s1u=$2e2;u4rydJ01_1-ODNs+{qny`0^NM&~ z(1+Z^;hD*)i^b|f&`=ww6!kWL68@|Dm$Ryd6}J-#wu88Pz&J(ae+z=XzQ-Vu6{6>5 z)3AtD{=o9?PI?BYo5Hbohv~XtT>KHst*wUBck395ToN`P^8P^J*if6Zv_l`|-xg12 zhLT?3em~+E6?T@SLOz#4JMHmvB`kqBrLaT{X&cPWg5rFOVc%qA6#PO{394C{8_i)7;K>%OM5kqo zb6Y<^rF_9kN}W+ju434K+yvsLV?xjpk|~VW;l}G=dGXU1hVx`E%-jxCx^PN!!phSi z1HrDhwMkrH6^62I*<^9Qpnzbk9`{Xr;j?2Eb_m{`fN0UQSNC|Y^5Fuu0R0r=522bK z)OeGkhf2@+djrb6NSVG0v|(SLC<{EEZ21_?VZaUMTM(QJB&P9edy}0UgIb9ts(n6l zS!(UiUJQkaf7o}ay#FSzc~xMOI_A>nXQsEa!B?KiV8*e7JcKrUCuQEuWG;$Q8nsJ? zd`;~&F<@ku=`$qp-j7lhl$GG?v8GKz8I_kD=b*!Y(>#`A~$f%snm!v2i|;-ZmFVD}3(vt8(c%Gsg+Rm>J^1!5Ijj zC%f95`Mb<%tAChAVPcoT)$8(Z3~bh1J4z{06xn(2m^D!tP{8@V>G4aIp`HM2gsoK2 z1+e-)%fXefM@LNIxch#6jTzL#D2s{sg}Dq^l|F0;_=66!4Z!6+unA;Hm=h8 z8IQTqe@=a#+fvyOLULjSF6uus?n$}MX-$AJ^W=q@EV}wE+8V+=fX4Qh+Khob30Xu4 z;7tFEjdt%yOzSH#tf!u1?4Y1=fyd)m<}(Z^0~RhZ23xm5y!p}ViI>?&Z{~@dPP3=$ zyqy4a8u9BEj>mp`{`#*c+iEnOeXT$byGH^2zP5Y>`?FZDVn;TnwMfBYw2juy574ttex3F%;gAK?j zOacL{TJYXtgETUG^{!sgA2d=FX(;-@7W9D0>HZwWX!CaiO~u#=paK(qR9BViY<$#P}U8h8GqqH)~b%4-h~OQEnz zRb2t3AuIDXW_>`8LpJ#oE}j5f8QBAK>_Nos;47S6jTxvDMMA2)2Y2^m{9yd9UM-xI zJmnv5A<+!Cj{wO<4>i4dV!%F%f@^A7if%f5iM=r6b-W>oG}d}|!LP>BL~j$(30;q% zaC59~rMCV0lg)S<&c*Oe)6_tV0v!Npr52cX43IlgvPah8@(|t~BhbSE0<6_{`s!j} z(ZvGlrK_jIhD!sHC)Pb+N!2D%QA%&+ZhWQmiHp@KZ=!4(;jYuQ5AFgL6p%3ugZBsF zp%e93yCU^>4;dC_oC^@fCZrTaYpO7a-MqRUzPq0$iZBBhYMH`7oP;|y3>fP{uH6TA z_uM>;7p#J#WYc&L?o74(2UFH8XO<@fjF2!~XgP$?)G%nsF6X z!}C4P7l^mvn6}`Dr9cE3$8II68^3+=>8T)yA@yLb{VFw8F`AU|NIw~Jcgx)i(Kxd( zt^yDOuZu&|1ZoPtE}PSzvT@vUyT^Eb5``d^Mr46&T^*9XSV>xMdwEp(M~#flo3LYX2Uz^w~nIPQqBf1->Tu z-<_^+Fmfdjr$urQj9jF2;+_x`lleLW0s5@Xx%o|Pz-r#=`pGIU82V|x+ne>3DT3?n z>vOGfrt|hOOq)amBPJP3hZUfGYQw0-*ty8W@cZilon299wmjKVqwXQVW|}s_(W&@h z-3LEzYsu`aE#(6~254=B#kWW0kaxG<6wEzh8kd&;`>T#N1F%<6LTxsxQdca^?OChGUZtMevB9m=o-B&lce#}1l5EwY|e1_Lfv&zFhiZ$go< z#9o{ZC*=|xA0M8<&*qYBA(7mHpa*i3__PAx>6(@03DOI|wiy$;4KM4JGC+-HJxF~* zc4P;@4W>2V7}D;mp1X02Wlg!u`Q%w!Bs+-;?~vvyJ; zQ!skGHBngvb0Q&t7l#qJ$YE#CJpY3LYyMQmDVGerK6SofE4qr@BUfx3&F1_ zprxf$zh0JtHfEazQ|X@U!hvhAqplj8%fw*8BGlvy%4|h;krCJ2e* z4+4s33-Pbl3g+l`V?z)>ipKAXOzP$?5(@+^8t_Z=Ut0MZF6PMr_m7M~f)5=~*Y2=! zE)?oUT~9z4W)9>|E&^NxYt+xkNe<$;Q{jWJ#nL2%EFO$l%gYB!#oFP2@u86pnP1-( zK|$cSKqT)1Tefx>RTbnz2LuwYCkFaF_lwL&gVZffp?4#_*&Uy+Nk81kBnN`@ z!?{$M({JIz-x(ab8N@&B-r)4-@b3ZX;A;4D*nDwtdH(1hoB4faR}t#QXNFjLz(6D_ zFVe6)1`N`}0gfo+7eDprAip1nwTsAlln#OsE0rsl#xpDqdLNGP(zb5wt7j72lIBQYW?L?3gH4rE_#ODfF(u zRkjJ?x+Y?~W}=c}*DBJHVDE)iUu@m?%A}^Y&J+I2uPWOWb(l~j1fIM0XoqE*$V3Tf zl%C`s3lR0dz?YXhZr;^8iw89gfx;Kyk_Y4=#%}ir1ZuFlh1=nuK+$+?7u3B=od8uK z2YXDlUn}$33~UO=Hk4Mjm+m)n=fr>V_emSzc_mQm7hxwU!_*pdGttP%0}moPBWZu zE1PMLlEJ3kIjE`Oay-k>#~@kW5*Q-9#8Oo1?SSc+X(a2FLE_N;%AIg|jF8tPx#DjB znc4nC2{02L_K+c{Tjnx3^7fD$*c-)Spvt0t&||6tm%_9b7}>~oBuOEeoPPJ(H&>A* zu6`u9T$rs3?k$vcJ6ElCfuUo_l>zd#V*s@eO7iDz-l^qxgM`26r)T(8D6pvN!4pDv z`udCgwIG55maP2# zYtMcMduGq9^*obDnd`dmGsk&+SS4BA8EP3uH5GL*9suH$9uY9BV(QJ+n%?x__fsfe zKMfr}lzGP7j?CJH{8~=5_r726*B5|6h7q_L5TTF(;?IQ=!}#>)i3LpjwokaqJwE~L z&O=!Sx~6nD=j+T^Jb0>tVK=bwfLXW)9&S%Wy>;bc8|sVg9hUWPRY8GhX1RjwGj{CA zzwh^N*M~ZyhcC%K+I0u~Ns%y3O2|<;RKZ&x!N5+2u0=>?pZyV$uTXZ7791;ut zGg!^{R8Uh?m_U_Rg+-owZzW85dc6D8Z+iR`L(AtrKjiC5C$Ki8x0U5}M^!u&M+r0` zMnh|mjN5tkJGbl!@s=0CzNf}v=cl{k8S*BK@v@VuQ}qPpkdG~$vUkk_k7_?kOkE}- z{$z5sJ61RNw?p$_ikJ(n1Ar9v*}K9-(4QI|$$`hF4=dka=;a3|OcUR>O2sslp_Q^; zIrf&9f>s)m+T+PvYtye7U*-<=b~gp^F&dJ^o-TY=OZpZ48*M+*H=cc!i5?B^ikdmx zhhA#e+cWNhdR0XQ66L+0ejfmd6Jh6eqI;bwgQhrFX>PtORl;jYu47OHx;A_x&?pb& z*pC&9r_RQaxz!6FRHXOyEZe^OW8nB_u-Ti-4#|ZeH3Z)uZ+C*65&?TOB$VMzpeaZ+ zhNmo}RN~8BzItg4A-`P}gy|n465-ok;AST-`A{xG*Z`YH`Uz_KZ!mr_!qW6}`X+B! zF2ckxXYMg>k{84?`aVrY#tx-t7{@)uo(C(sSjHI&z4p>N;39~gf{?<_Z)bzm;R^_? zbb0VyUV_(={>+1Dqy+%J=?oVqKkwm12ohnZ#Nmi*T=A`$%D*&q_i~^i_{C}|9C}5GbGE@T#zxduL76)|?Pb$!y9L0v)z zz`XumuO-1w+_VxRqd&1PLm&cuwSW`>LF*|LVF^?Q=5Mqk1lK@bWVkz~jL!U3L|dP7 zYNXBS`^c6{npl3#7)uk>9h1Kc|9&u-uOz+C`B1JHrG_rr&ro`qWJYE%Ecpv9e2x5L zE8CR?2E{vb0uUo>K}8g>(*X#{{pX?eJPiwFcLhsPV1*aWEOl$RH(j!< z!_;1dK&5F2=S3#vwQE*giIMgI)qh%e1|+K8X=2$cMB0$feJ}_T zVj+%XJ?gB!^if$JR`nyyJ!dm}b!WFiK#dO&YP(SkZM$tZ2FRpj$HlBq;zUgTQfn~$1XHt!nbCrrey>*KGD|50S8 zFu95CN33FVDmTJzD!v?oC62f9)PrsURu|YByp|N1u!-#0&(C8&-_Z`hHC(#3`ngL6 zthI_ThCtj2AR76y9k}#8XUT;5W0{saF8h_y=)M+rgP(D3pX!IX-meDN_G4!FO>?xh z59S1Uz_1Y?eX?1sm52#8(Gzq4I`?MsL8pvHf1?~jtL)KuE)^Vppb6z4RsQgy;)gTl zs)%O?{{iaC{sP0ex1ALAtCVW?Eu*UHp1u=|vdcB4fn2lKw%0aYemwsUGQo4IU;hk_ zJ9;~hJPkXzBy>`9U@R94a)zPJpJ;!svNm!`NTrt3TLAkBWx&=U1@r zY+?Gea>U8GjGW%5#FLEb*()zQVhAIC0sX9$cLHl%(QCkQ0MfldJdO)+*#Vf_(@lt$ zVmiz#uSlm~p)`pk9Bb0Vxp4p6nUTw~r{V9%->|Kd)F8gPUSi_*C`xbW!k?xyW)vD( z0Qw)s@xP2MuLaytMIiT%0INL%dpehdHY=;+d1r=dnzO`S$6Rl2PRrM}3Q0Z`qfKld zO19zkdrj&G2I`(s?n#kH$42cgrO_s~(-s!;ZExNR$;-nLhT3eJfb)NA>l+`P0RXiV zN5eSwx*vS`|3qxR@0^`&ZEgbY(VMfgt!ro|E-ZgMbeECv7+QbWsCLWw=c4Ek zeKoDxt+shN?LoCAQBBVXgG=6`Dl%PWEcG6pwah^}Vbw8-QpohI@(1DZ#!uuGGA3DN zH4bMBK0Fh!T>EaKHl*ZzGsx=E&(DNh2$%gtd*oxOH^IAm3R=RCX*C>iKg)C@Ie=U_ zZAO%=Y&s#A&f|qfCT9J<-VFkdpvk%(Z*VC-DQP$h6_hNanJh!yL|@p~O$+RfwBNs` zQf0yD(-^Lhm=aVp5@)UPkaOq9&X*fxlSL^&kS*8Q!OS`dF7oi)Xz`%2o&x=hKqu1q z?nFG8_+n9i#Yv`h);MvfhV&sgRV&b1`K^strOJXraJBxxJ9t9)Mp^AEO)+BeYNl+b zE(dg#v~>zI znY`%BP*CF?bZLAZ^mkFnJh%O-ittTgQ}QIsfXX65hyk1NiOBYM)JdpXx^aj(&CzJg zEW^y6L1x}oY0H&eJJ1troRhe3)S zJmgSU+)sb#;I$e+NHgAAT0Go=-3F-2jVggOhx+6jw>&79E@Sugl5jShh)>Gyw@Y>O zd`v|$y|3QMtgs7t zQgSGvJ1O@Wz12l_jrf?0&;Xf0rai!IeOoA zsP0o`U(Wu!#4h)4{}U?v<;Pi&1muzdsqa_0 z^2EgR^C#~$-!dCfUO?;Qw8dL)pWJoXVDtu~h_5V!cj$39Z-6sXzR7cmR^vSC?|$86 zh}r#NpMA3RlywS1EE-B+jC_k=Xb

#;rmL?J9Y4X4lv!$e}v3IJ)>XurP9?CTL9* z!u>rxRz!rXgG&Cqu$`fiUv@vd0LJp?oAs-=Yxa9vgOE+>SYg?ht7yWo;tT{Fiaf`x ziFy34hT;!G#v`7NcOKMGKx}jM@|2P!q3^{WXw{=jFs?2)V<|nH$1%sB(|*BC76xv? z2k1KQaYpFN-eAdB->8{8tCcbR=dXNgua4)nupshajb51qG(|?3+#!>Jr9)Tb&Z8ly zhpc7R2E)8y>8OaEytcFqtBUZ^l|z=%=+%!eI1fCh2mbmMOv#EW-OYe8=ur^%Yc?uh zhG8rY1WN>-NmWa^SLj+!R9q$@7tS*=h|kM==fQ=!ux9dY=uM#B(6sjobU5;hf z%*3Ri7f{a97g+r@yW9YAgjP*P+f9w?0nTyBg1Kav%hi|51ECFDdm=XWki?n4!LUgY zuTQ083eUe29=QxkdMdqm6tn7o{bt(|i^M^jh5;Q6)Q&a#QZkF~vBS2{v52`NM4HV2 z5zNaPd&T1AhHg6)jshhLOW6o$2}8B5*d-~ti*;fJy)Ok?w5X5VK>F}c^f5dC8H}>L zCF&)gQ*6gtScU-=Q&z^y&@G%=WYekxB@UvWz;>9Po+|C@9{3l87IL>AP&`85e=x-j zHY))PjJ@4SEJB@x%hT7Oewc+saL;(!!vr~h!;5zr&oHS~iW&WvldFU`E}@v%Hnb1w zmO!$UrpNMQKovnvx?Hc13{}sjSrYEr<7`tO9ok#dP)n|lf zBOCoHK;32U^^yr0zB87ep0?nUZ%?)k;vT_U%(-g`mT9Q67b?dU_!y;I*&yg^bILj2h#C74jS%Lh$8EY8wq(La zjn?sySxP`64iv@nSuPl#&!xDvD4a92K76ByXJYHL0AIQ9_;|=ED^5hcC@i# z1!19Vr4||MQQjgVdFd=nzW2O>Kog9SI+xz1LU0ssnHP+&==21cert7Fq`xSS#@;|V^lb3=!sI|xFKp1RRLVNG3Rc1SSq0;#y*#p#Xv#X%62H!+%pN1*1vbcM>f9;4q zTj6*>05N2{etsT#eA)6>D-?bMj4RRjtP|fnY1P}f0{n_ocpZDKy1e?^^>%6M4!MN0Kv6uhM={{q8mGM-2^(e2v zOG|U!des8U*t~Kbk+@1G%%Cj#w%`8P(kA^oYKzDoFL~XtSnXn{hYq_(T z;`;g%$yMs_zpu8RDWWj3dkEj=JTU|&`sf$GWl4Nbjo8mx;BG@)`CQyiLX^5h{H8t2 zu4?!K(Ub8cL0;9tPKk#qnXqb@Fpy-dHcO>pwznx^bjWaIhKMQ}sRR|4!l9!!e+4ZU z!QR;=N=OAtadXTRX{%waQ-3A0QEt9CfH2u41?!>;Az%yuktu;l{|wX6QCE3q#jD`B z62?=al1#Qt?yl8AG{$OJkC(x@I(GjHjemXj#!7SdU zl18ccp@3IKU{$y1hqW|O82Q#Np6I}xKNo690MVvz|YJUgoIJ+8Bo?sAj2n)1F~4*NHG9Dm!F0W89v_o}!|NhS1OE zI)9{OgjJx<-vEk>2@*RLnIo7B7sesMnN%n zFefr6awJc{I9atx6~_kZMJ9?HLyHsh&!0zHcjXTR!sOKv5~!qUBIv*Gd1@J#65d8! z@;UeWM2Yev^{O{Y*RfF4I1c$;$0UMZo(@5j3{js&G&vMq4{_8fExNi`@D~hf-nw)3 ziNKR?aXn)y$-OC7J23RWiTs$ge7=JK|0W=muB0sa&h3cwoD8J{;e3h#bb$cAGr<_= zQwVPYp~>(Vq8c3!$RobA5-9+_cOf^zRFb1i&nO*Ov%oES^KU^g=z^)WoW~J`$tYiO zv`RW#?#BsI2niPZ3o2rtFYbec6II*jO!jLF+E3YiMsJ^A)8*yVqAEMFDX^i}ATGOi zQwd<&=(ct@%ccNE*~zCF$8d6mt}#?^w!;2r#XM)FVV+V@S-`uDbMG^Z=fi=!K1rDr zzBfm78b=(LSqe6r1ZbmFJ^&$;qD5Pu{j!_ygch>ELRs{xaW|@y0Pt*6_1EvW{`{g= z&o|`(L|79`X&dg=O6T=y76)l#GKM}{I}bLt2p>CCcbbKd?N+@VgX7rsXd{GU<0P^2 zYTMq-t=a0}rh6yYBK;a2ZDPErG3sp(wz7>k(e_u;^QBmc8iJ2tAPNNehULLWee}dqlToBdgDe0*GqtgBn*EZ+dR&Ci_SQg<{C z<{zL*uIP!hrFBjO$}yM>Ap!^u+TSNcn7xvBnrAC*!SR?U+K>cZ=3?F^h={7V|Kb+a zxzt|M+|KBfTF@&aJ;%q*!6JeJJ})4wE_r}Z7wJ05g83+{p|?h}Xv&*F^e;(yJ7np+ zy7zNgqF1Z$l}EoLAGLKL1ySwgM{7|b-(2l(xiiwd z()~W%5huH4aqT5=rU4Yp(eD>+=O?nv+w?1tivll_);rs)xy9RHh_Ti0e?lMC*YNuZ z#qGYmH01gLD)zY2FV!hWG^UOIQXh`!1vY{31w$m~CEzqzDQ1`kcsl~LsA@RASeaI)fWCf}F4 zu;(hgR(&IE&-=_*$8L~-b7{6Uas{x3@7h`Fbk;NCK zLI(mKAqMitlP2n>$5lvITxI*OZn7;Cov|&>1&joj3gZ}xg6-V%A>4R?nz14Y#6SYu zQyOFk#_u~%>kKQbHo1y#Lt=nb``srUpQ+ljCxZ5b%X_y?zIY%9!(Xs`pG20EM*XKZ z7A>0`VEaT6DBoY4=^Ip6k1ggnOr zK+G6a+3~OX)nDtZuv8IjW7;pm`Kg*`Z!a<(zGq|$ulU`;^auCl3SJIDMV{yJ-xemCGd%WT)2JO$ul%TvA%JuwAh!K1Km*#@TNqjZ?e$B365S*p$iov&{&f$GG~X4__@m%wLo2`f$Dewc{Uul{|f) z&!h71-Gur&q&}LhzF?W(9u&)N%9Qx98kG8h!~_TekAA+D>;vv^oorpKoJ$l1%q&y0TIG3@4NCq{VirUbm`3ioD>eZ1p8t&qgH5_& z7|O+&;cI?L7o5nSNY?bsYfzJRdcvD6-hAP?@6u055W5ov&GrlDUoM#clYul;*V7XF zYdV7gTIFxm8wO!9v$>g1VVvlt3wkOGKSKX=L-?7YZ!)c*^R`+J#0mGftN!g~f;P2R zfqE=Rlmarw6_qG#M43xI+$qH-ffWHr=5T1ly!)fA@Wr=kXtq1pM+PcI<^ru~k(#Xv z7XfnB=c#|Y6XtvMRn$GzALVUdWhA~9=(*ZD5wBSM3}3lvt>^)A__}{2C8|b24CP92 z&#;u;{9O6;^W552z}K&D4z}cmK-&jOZ?wNGr>=>_Vno(JpC@)a(?Y90s@r4WO@m8C zDqrn01M?c_Zffz5#eR0Z_xT|AvrzjM@3Zgz|CsN|?^Q7GJ;v^d9<1)aTs`}zjn{s; zO~|YL&ZLR@q44a0E%S{_s2Vrsnm%XQUN_3$%+BWJO!s@*dU) zWWF$Ocdr4Wq|C^w!`+U#BIVBdSCLogbO(t_H=-ubL+0rGn&FVYTMQdAkV z+`7H;DD^T}OX!fe3b2#nj4apUzh%DDJ`ov(@uOJ-^F=ssF))#S-Z`hr*8l3oLa=0u zgqGvU?K{6XzDcuV%4+T$*2cBfpDWoS(Z;NjL4teQE-?HWwBE(+zj&}9CGo#$1t$ZA z8BH}z;-Bk^--Iw=N_D%pSo6rYyfL9v(R-&%@!x6fthOWuSVb|$VPR#RLSPg{q!{Mj&A(rGCnBim?r8YJ&`^fe(2-sQmGq>u zH#dKn`N`eNwx7RFPS1YVRV256rcD}*Ci3!KhoqSNNM6u1eFx2KW4o_LN^}Sb2NDZ* zsmp&3pU%#L9WRz~WLC~X-yG}oQpB%0sA4!p5eI0M(&tTr&#JLW^p6ok%#?DY0$#UG z*fM0|}Ek5bmOPLwD0qUzE1 z!>TWb>w%9uWRYs;Rl*%)>@7xV#mVMllg<18Mf08J@K4((O||(kfa68Ris>XYWMl&R z&Zb_uJ*h(_lt>)tp$xG30^#$|s!*XV*B?IJ-uMT4&qkzn%%tNb_*|yw1 z6*;&W--|HUIX_J&+O=RVA9~w+v&_5ia4Huh*Xv=Gj6VR;smDyB5QEf!rtMo_HCY|S z*wYttZFlbb?9|jQD2TZ8XRpoP!{q{H9>YvGt5&>dT;k6mXGdcachMz;qSVMLnW`^g@11NeNVd)8@7mC*AV`CXIRk&6tgZ zLPa-|&yTs@GXAazu>GY6H~d`wel8MOT9SHhc&VoI&5s&6I@`^?{*s4Q)^cI4&%m21 zV-bIh6WK)hnM@U)YfJBy&tA7jZ-d4xnZ0+jm@PZ#mJTE{7vKAh{wO(@ zyzAu1diU4UZQNJ~Cfdkj{a8~?FKqy2*vht4Zxc2mz0n@jwF486cED*jeGRz=;p1+T z7<&@)J;u&dRC_@+YttBvzb0GDZ|oudhj`D_ce+;lP>fsN8Oh31UW<-HjJ5nRxsyJC z;8Xgp9!|mvCS`lf+=GwnT|G2%&>WpvJppMN9~K;q=vgEhKDttFW#+F~@&*i>vNL~8 zbl3ZM-YX(gUpkTDs!g6un6WVLcxPc3W4%=58)iWRk)#2tsRX0U`DxE)w^;VRH9CH@ z?v2=h?3rnaTmC*AQkC&V^QK!|kBw)nJ%Dn>A0IDxv(4Di8;5_&-c}E2%37C7sQltD ze*Ol}tJp}lDvnl?b*RakU{g!q&}3zMcW21Q(rd&vfAB}kcTHyr zH^_uqaZxUte#=FWv`j+Kn}S=F?;Jmw%=Gyrwi$fzrMd|GuzWi6<{{sbnE2t^{7_$N zX6l#yhZNm6-w)&L~!s9$C-96MFK^pY3*L$($jH?_VDpKWexyF7$R% z=}>w8am;9nkGss=J&aXlCr;w#KFn$Lr=3na@r_Vh$nyHea7n+)1B~kvc4ku()_Wm0 ziTo25yJu{nPd5@v#Akz{4|ZVMHMJ08ow3wNM2)T*ppvo4Yi0KNr++WRzdqB@3B(cd)|L~tky&Q6<8|P;B_p+#?TT4={lk&=+n4&0 z%$r|wqtr2X@i_a` zGoANIBBi1*Er~nrrIY}F#Wl@mdAq~5VX^5sR|>^p-_)lbF&Sm-w|1S=Go8j?aS-l$ zuQxs(;rf-Y~68$9<1oZX2meXsXp%Kf*G7 z|MU4ma*uWY>SfB$Osjs6ZLng{fPt}7S--ni!Rl(->aRALOpA@<6wRI07FE^QCH=tP zEnyPB{6L61C25^59^8WBvy)Q=jDM?y{_)PlQ40ISS$v7h>d0yC0zEhXGu!BoLgg`8#;c;i7apZws@`cRhrQagG~2&^eg9g&G%V2~ zyv6zCcg(rVvK0qLTt$=2JGTb<3!dwr?W+IVjniDMzeSb&DD?ZzdoD4++{jXwYIyr; ziV%Oh_1qI}{m}SVPw05`@v!h%lvEsww$Jwo+8%c0Us%FgNdnI&;HXX*j!g8IOnke2 zF{y^mBQ>!`HDUJsEj70Y%z~dYhOWda$CT2ReuJWLr{*6Ox*I`!Ge7o6apf$<-lM$|%(vnHb!e>Td+T z8J-ZporYMz5RKBP2%YegINLR@D5TXnRQfrTEZPS8l07|6jXtp_{XVNsLsxpzN!%3- zI|-Rl2i9?EG%VuIIC%oCQp>p9kx`T`6|(@OI_Te%O3$Yy7kbV$^<>l`b*$3qnd2`! zY|Lz#$gD~~_oOs4eS-@v2B+1H-owzXyvfQgO^*=Enp()7Imw>o&UvGjGv|;qAD**N znzPiCv$Bx0dXlroox7oyyXla-6`s3On!DGN`*|Vv>q+hb_nkwvJ4X(8eum#UDZO*n zbLY>(oqs2H03H%podk6x!6Qh>vgaiFUJ~OXiTRX-;>lxG&trGYqZQ9`m*w&H=J7A) z37+PmdGbZn^TizVB_i^r%JQXq^JN$FzM@^ovn;+Z7)RFaA;X7V46$~;rP0uS%X84=NzK*_bI_%e>{7_9sryMKsR1goxOa<39Yr$yDx=GNVb)lh)BJgBp`)N~ zzf(TQCpM1jeeSo=s+|Y}fRkRc|M#!poM73L7#>RNdp_$;><}&q-ruzC6m`Jijkc3) zd&i1B76`r`J481&hGbT&Nrtd9p3Eljhazok+bfT({FuPO|D}GVyT2GgRVNGT3yw>< zhqisO-jIXX!q=UJj^DdQvV5VvVCZeJ&*pR?yDF$8%@{q`tUVTo%|e^RiOL+K?tAAP z{L1PCfIok?p)j1C&sLdj$mF%+7AeCD+hK*#>Nuv&p@d}bt)>PW`%a%sJ=5mLs1y^x zXzOm2MC4Ye>nW{$wjvT-C_tg7k_0sM+6`|#m z4cTLKltv~}L~(P^Uhnzh2PPt~qu2u1fTpx9U;nD**YEd5fgwafyJQ6^P4~H7|F)5# z{ELa0^FeurU7`29zw~&QkCMC7|Lmd)i3waiKP@cXNfLF$c$&xsXU`K0w zqv!|S;D4G3O>Q=MrGZajJ7AUVxYtzkqKz8rj6X=|nlt|#SS98g6<9Hxk8h?3H8>N; z9=JrGFa7c~s%1*qezLQgN;D4Yk03k$c%?X%_Tyn==M|k-43IYE2vyZaVz9xlfulLy zuaTlpT=F@Or)|Pw$b-M;w-1T@2h)$=dyg1e<+$}{NKb#Qs{FYE6U=rFU%-*l`nBJF z`9)+@%_;0F(ZLKq3;WmBli+&p>(60x{>r0`LcYm;)7Tr=c%kg2&gyH`_94Bd7v&g# z(1}h6oSCRmxFf4``*SNH(GPRcfMz%$0qoFd{=~dih<$ZAEsoT)AqC1zLDHKNT<7T#U2Pa}T-afqvA{kOSm`&xs6=}dOa(hRpxf+1fH}Ru?^s$yZaVOgk zFaI;&`MG#|5N9^PJ~sF@@4+R=fa&JpT7N>IWX#>6oD|-J1bT!0MD9NpFuC+0=E#F2 z!4)zqy|}<}{ALt8LzR}`QD94E=UO6$O;}lC^#+^K5Iy*?i(zZR5ki!D8 z@yWoESskZ%567O2T7^;>Yg>xkGIC4PoJ{C4Iv5g;{GP?XxegmT8DS3ko}QX%1x|ur zO3L3qo9GkOQuYhf~!_MIzXZ; z3lcBX#x=^?Z^3;(iaH&3ve=+f6}#@;xji|iK%bXZm8?T+pa*E@D;;#A{^FC#mp57e zkE8+e06_d|`mUpvLN}FrUSR$)=+3P(g+3T=O z5Ev1qLjX4gdQ0P|MvIULh@n9YWJ*O%v(edf!DO64R*8`9rq;8$(eMQ&{3DHe&C_EN zuP3dI{R^7z2c~kY5Q-3)7-oSUB&KQ~HC&DvVu>cD0BfS9MK!K*g}_^FgBK-i87x|# z@_O?gjFvW1oqVp|-muaH&!q|du{5)2Rh!&uaY86syPt`}vxI$o_0Xl=%I;k`{eO9nDlHY;h0A8$sHf9%RaiQ6aue%gdtUxO|fKIZ{^B)o8`3yXy!(m`PO zS`s&=re{3HPtScVDRWh&y~Jmtpj`cfMu@C_QrmO3Q`?I^WftatcV&#IMFyP`#Rx|{ zhzgmP0nv@9KE(#?1GF3#TOGRDGgBINfV3+Z!dJC~AS@{*#S`iYn!!ulak%n{T@uH$ zhTdU%mw13)Xbr|a?|;q(^FGss{doybVI1!ZT-kl8u`k}m#Cs>hSh-|K*58}lmr2Xv z4-`6pb}Te}#l1!l^axjcf$gH{96NESHw$cC9MyP594hMrs(;RR!F{?`w^U|7!Vva!`pNE>Ye~cr3Jx_@J&pJhkMJihPriOE>NyH zbWW^t1c_#gT{KlgVq3k;_IqdILHRQws_Iu>EATs7Xua_ey6*kC(b;}1JPW_*`yBJ{ zplH%5^mTkth|5|~|8quEA~aU^<~6q7muLgdhO}#+{uqqLgAH7RQ|~8_?%FS*ZNa1m zF>>r4AUf*JBR%132aFFLVTSFE^=V2nl9=dzr<95Q+KO}d@B2hasp~In1=;qfcfXlucuyX-{R6Bt~~0WsNlOln|P#e)w{@n z6l(|HY&gp-FHgnyTp_^0r8v%ts^(i}0wJLU7a;?h3wg%{M87k_DT__-5=_`ie!nz~ z;|NZS=jrmN7Hsd_?YC7=_K3$)bCK?041jM;m;cJ|=O z=Y9Pc&O*=Dx8@;W#$_!-Bfi6aK(nP>>S6IMnDG zjN<@&ffnFF12h&A&JCeggD8>XgH*$c$Cz2SIa6zIVwEMR_Z7E`U|IE1IiW-a;AYvF z9h3q#^b;$8LYl#oiracGN zmpE!7N$T>JSvIEl=7n$ z+x&W-rU?dAq;9j2@f;ZF<-(+ZlmBTd2sFTmb!HI{J17>q_eOr?r+Iu$+VgFN@Ef2n z`nLreW5u4B6?#RKG^9h&P;h(74@19BT8j;kl+_v5>ke{6gJjUqo%dkB#-t0x6#94g zgE6R7c&4qSHs42kc`KGwNyGebs)SGnti&)*&;c~0>TDaHQqqtD+sT3>vyYx9?b~K6 z7+q)^(WKEZEM&0e@h#&uT`^MZ+=4Z8QI2wh(y>Gc0fxyA)KG7*xcnAHk9XZ^h|=20 z4h(~q8pdbW=SuG+KBIlJQT{J)&}pgtWT~?ZDZT6D)@?hIa9AP*=JBP(YzT2HTUmy) z@yh+6i=W>FvpXs=3PVcXr6S{oDORP#WR&K1&B1uYkQ{ z?UR43md#4DEF4w0#Hiqy_UywacoVuDkMr4x_~OxHJAdP}2eqoAbt?3C4a&KBXxU`9IYF8rqUoCbG2&a*t0j!sMGQx|jFhj0yQv5O~p z@8EpJh=+x3IlFhbvsV-}$=VTVmGE2?bq8YB@XN%rL zjyQOGmY-_k1x%QxI*WsN2@iLrJeOQBowAw=NE-v$;SO4wOj!xmYX|4@bur;4XR`(M6qcmGmVm*93*VGOqm5nH<*$=27<>?5TW^ zL55$AK>JWrSkNH*c(6iOkq7~#LI%%FK#eibI%O!=QYxeuCq^ps;j|Ctz9HI|$#~@9 z0F!?xrGScuxrKV_d!^V!klT5xx;#^KL!j~Eiv^kbzHG$g2@JSQ|Uxi{ruSvq(vD^cBs)-o9b zT&=k;ph?R@kX$ZI1?X!OixC@E;9-Wepp`dHJS~UyfLWAcLlDm$+LTN3lwteG&XETa zoV|08yTNV(C^Gb91iG!n>z&3^jbz&1B`emR#^oFu#eCJ!?i2EzmTWL>xu zj5hv~B)4;k!3CkPqa--Ah>u#J$E%ot2DuJKG$~*pv$ZixzciT^+Th-RIsn@$hrnm8 zW!H2~W*fu}?`qF7cR}nfcs9O1AM&ax{OTm9vW@QJLgQXB6Pk$Q+;!Po5BJL&clOaT zWzLuhi|1^Spe3lJ<8z&QQqVr}*VG{KzK-lFL^Lt!MD!ZR(E}6JYL;2%nT%vLKVH#P zoNJoLr~=1cA>U_@cKE(&4;1}cxE)SA4GDlQ1&qb^=#o3JG*Bk(irHKp>~HXup3N?c zEQ7ynjuf^zo%new9-KVhGVeQ)wXAEhK;AKSdWcdz&@ zN|VM{65#jW^%n;9TDM4WBtYWQV9{h?!Vi3T0zWzitQV$(P4d^pK>sswu;K4{x%QIu z)w=Xw7UKBcg4Ky;`zoae;X`&(r4~|9TJ33}F;!0vc=UbDuILF^sh>Hy8G5#4G@Kgl zrka5Qb=?mEqhwr+#jpb*I&F_MeKBxHk_*F)oCB5X!42TSi4he7$oH&C?6E)pn1gm5 zuIZ{7Y{9*ar&d0E2n>J?!c9K!KRvWftSo|k!9HUrfo}E7bClvj!EU@`u)oQdg#ef| z0|ZR~2YG=|YtIYx6T-#8QRHm8F>8mH(LryUoWHDWl*tH1lF}b&0xAPIwN^7( z)GH1>@Q;;HmNCzPX-J&vGpI3Ws8xNlR3ZC5F7}duWjthC9kk3_wtwdGSq0=kxUq8s z!l0iiGzFEwhh=Oy^`-$5%i!y(FLq49>J)cc>6#0z4S&Gw__KrBz^nD!0R7sl{1xf# z**?CH(4pyPgwR0h8{_qSkn>up3Kl|jD4LZ{T-bqhFFGj#=_?g}U~(yYl8e=1me((E z^6zG^KOhZ{H{J|3$C?4AV_?Z`h{`NNiUi_T30_5&yjBFqPCuf6aer|gbt>h;pP-yX zK=~k_xRjJ%V)nz43K1dr1G9*du!`QFV0O8gt|15;amZbo48is^@af?R04ZSp=O2(h z0AV8o@94P}6`8{kqc?2Dey>|a2S}?X+&E#AL;3*%CRu#*QH!I{qZ^=KqbPSYREfCI zJN`Nv`|^m@)1I$LrZn9-2f(6?bdDBlzSteN;zaa7!z*lpEQ;&1{+yf8juHp+M7}(I z7mFH-6t-RNWtUq_L)Y$dfNHfN=HNmjMNFHCWpm|UP6sYt1%YXr2cxeetp7ZGINLpR|6W*k zLMsJ^Z6A3AP?TBD6M>SQRyMo3ZQ0E)tm{kc_Caayw#E=j@oStvpE42w!JM14Qsli) zAH5Jzbu2E}*G!yQb6;~5P zKdFQ@{#ty?ucPH>!sjIpG9rATUbMv4KkfdbE9wmE697Jc|K?69;XtRfe2u+8f@$)4 z3Dxj;;-SelP&6rmI9>8dhRBF|i-poIC#|S3fuHIR`95}QZZKNGCGGX!o0DxXzN^)c zcYVANo*!!BZoVaihBI+;Iul{h82~-UVJ|;K@ZkAKjXitNtsT>??eZkq@FrWIl*`B> zK8c8Btryflx3i2eZHp3(FKCcA+%er1l%V$1 zL=~VX`>ZGkuf8*;+CbH3CzRrw92sg$n(^}Co&oRdE&vdH!n%A=0Mj~2i`qBJxI048 zanyK7?QG24a7y@=FrngH_UXuL)S)2-t{-2wdlqojB86sHF$f76Kjty^Ur&Kk+%X^( zbl95`yZz>Y%$^i^WO3b{L^c%AO0`T{;hKDZcCwBdqv#~)d`c_&YM)?@yW0H7U})fu zYpNe0#h?>KkCfEcmrY55re|bkWid*Kpq%sbfuiDK6sjnnpI?-no%w%jo{|j>LiLTb zmOW;6QRgy1Q%dAKJtvzZf|XTUn?**NMyh~~q%VMFsI&!9H9(Z9sfCFhC|F(w*z21m znOB^bfU>w<+P3GH{{yPTm35UbZJriJw5>;+oPp{2jhNHYWer`>4ioLdV7QVS##OK5 z9>A-3FFD96vq;*ON&A5YE>SP5K#q||gp!yS&#u-Ja;SW7OA;S(s7A#4inYXEzBa@= zRKt%oRTEjRb+%BsaZd5xe{HmEK`42R$%CyoHw=z?6mjQ)27+v&AQ#JQPcE6k{YBapSUiOe1Zavl|f*KF9Etk2=;3WzymLzN?HsC7Y$a zdD8{k>b4DE;Vwl*7o|169z2sb+j6^-OhukEFP~Z68yeyV#bOdMl916KlUG{ z_C2$hYcAZv3U;uEF#9iE3u0zwyqHcF%fpkQ_>DqQ6!cG5kPd|NCfoa9bSihH#M1pS zkXpUe&`^@NC!+M+YRnT7K$mClqOV|t))hPB_RxVb(xKx`WXXDohG#MCR&l2FB1`7b zc^ez`M~}TfrOe@XD47sY13g{D!NO{qaPi`Nx-E?eM7*ou+$yr$h#!V(BhjL|5V6~$ z?vN7#F3lrQ0hbLy+X?3B-=o%fvv_7-EN3(S4837a9^K#-FQGJ@zwX!Fo5|)pK3<l={Bua@vWwLagv!ts_#3n#R>_=WlHxnAFuZe~WA*)E!#4yg>?xH`lF z#w^Q14Ecu;QQ-CVGz1*}-NmJlFy&`y{-bXia8kbgyxnoUQp zjd1Rc!zpCOLA2m7mLV`@LZ9oaeFN5~Qt5I%k$Xqhx(-zay;9Odr%#E1_U zUKnvZM7orXOFdom>jMdd!?p_kn~@FPn~`2_6brk+h{o(v3l%$p678ejz8M4MH~LI-#_)=JH_+U72>f1C0HKmw$Sxo z;*u0<8XMn!`dF8{QeElI&|5}fkER5m^Y)y&*88p{7Sq}sEG5B*6i$Rd?$4npvS8|Y zvzXYow<2WpRyPC4$n_E4-S22#Hh}bd*N_uRNy~e;e?zvQ408)ng=yX~G!pUB({db! zESf<<1RCFRVePZ)#5^%OGKy?353;XGIZ~7Ggfkwkuw%22d)(MNCU3l%ts(vr5`)0W zsdN%|9{rEA7W(Dr;61OvLVCTJ6L0B-$oD=^8N*k2aOub;28$xF97`}Ke*ufqPy`QG;3DO&hbx%tc8l#6Q_{?ZMQ6PtldBUfwk`VioHj#ZFZl%8Ggv7}| ziR+X)5#M5BH$cu&v8M5J6Ox8mglxvO;A--;q^5!ikQg)8%PHE)g)bO(ZcWv)HP=ZC zkFecQ!&v;>mFx+S1>sy*Ii?F>C|E@AjEf2-#L%$^FX`0soAWt}`#w-`R* zIj}>vgSmdR5|Zoapqa)aZz!CyTK-+Z+4g8J-Heh{pm@5jCPkhC)sYh4yDI_NX9VBh z)t6vND(5VA6Z&%~=e7kwR1B`mU@pAqwgmk0*4l=Nzt16a5AW}}i#az6&vV(I_FtI| zQE`DLrHdI3S<`}J!at@c7corAU)Bma(&(96ydj6581Y;T283m)QZ*AKzNcbgRtZnKUw&|1}4s zh^OBB8J|w&&K{mJIbqMM}UrK{g7n{ROi!myyrC${tuH(GlY zJwehu?b+t|k()nTt$+W%4~`FM3x8N;DO&LI!Kb9K@`t=$<6upq8tH&d0Ba1W)%scf zAmyGRq)OxMvyJ9@Zue;E8j1g|oTP_7OudI*w&X&Fd*_-#aJzgS*8~l9$ZBW&nWG>+ zi$={$Fw2%xc8?cz&W3v%nDs8K=%HtGX2+I!uw|o5pA$6>hIyIZ*L-^jOBUbhz&5>O z-m+FA2i$*_j=r)VEf z@f7fC>xco)1l~+s#D_wgVybj(2m5}6a6L=jWCrkSl?G0$hOTd2f2Gfz0btnUA?#xH z36D|Cjo>c|RU_zIJL(GBKTXESkwqdEqgX~#Dm~<*ox6(l&Ac^%6>Oy>RqF%i_Vlyd z_awPwIj@)1S;!Hw&rUOo&oay(ORb5rYSm2S|F{UnLIu_!HQ>z2V9xPiX!KdyGD+`Q zgl!|P$b?{yR$k{9mS^~+gF@&H?g)gA1scQ|2~#8Kz4zBb-BV$wdCqx@$nOa6IdOjB zj#DC;dVcpapHM!DH~Lcodg;YpVF(6(TEzb_Y|@Oz^6MF>`&jW4HCXW9!_DHKBG#Tu zzQVz0paH8+(Gx%8xd{+&Ec1^BJ4P${q_f3%gk>biWbRpPry1*)kz<%Q-rMK-$(!bh z@U%G9cf5m5%*HzO_Oh#qRz!}ye1I>GwKf9O=&lhZ=3rv;K_XH%!y)zPGW~xR7*=x} zD4w}v9>sdfr_YVTVx6p;myJ8RbR!v8S9>+RBA{>VGY!ZBngepI-WkspfIt0Fauf(^ z*j1fM9^Y2KHEC!julv0~ZuXv%b&YLS(m5PD&C$;55iYu>KFwtz?Giof)=ri-BwH`Q z{8OVS4^3g4oPGC2x;HI5)$_CwAspaw{GFb7IXR=smR$vX>7=g_G(aFyEjO7?8rIAe zY5;2*0g>B|ob~J&s*;K?UUJ%vxKe|<3k3#IXt6g z%`*_>xC#LDGFiL|1TzM>`bS8!j;Z zpT%nn>iukVlWtOw@dK613swabLGQ5h5OY>XRIEOzc5D>|2jpQtpcAA7_I3m`3t{|l zkURm-=$+HHN%H$)o?Dl5EeHFB-!RoyYg0&jKElsccTu>2T@WvevJ^yIdF|m?H>`q42tSmcB)rOMCG& zmGkA}z^}Ny?^3P!(7cztLGR2pJ{#tl+lvxRT%8YzdFi43?;!{PbA&w^PXvzzR$ZKm zGA3QSJQY*+J%Eko0+7L25{M~d;io{b=p;2XJ9kU*3l?(#4G_X$PBl8O6jVges7tld z>;wQufRwP*VgWGPHKe)axY~Flx%dTpmzmjH!?RR+UjG46BU?cX2T}yUH(Tm|fncUY z01iOU@%nEq$}#t8C?Zop0#I5(Ow|d~IN(GTTMeuOXf-aR7K|l+DGHD!HL_0|I05XI z8sHe3xXufJ0Dv7;TjAt8NNkG)(|_^OJQ!uzVxd*MfOri$V}RxAqAM3MrPC;o-U4D* z3ix5Ds2dAb7zQhpcx`nVZ6hHPK+BqI+ZiIDM1U-nv^*;X!_m;9SSas{QqolpZ>A#w z4en{Z11Gd#Xb36hzQ)tP&J!r`1#43~ZocX`PXs^BFiAXH89bm{CnGQ*2@Umb`XofsFd^1B^+Ef&<_TE-u4JHc?ZE8wDf@fX^>#nPO*E#TDBL%Uu^bd1I^B$=z(~UVE<}(#wFZmswQB?M6Lk1X_^O(% z`XmH5Ecs9r2;@&Q92eu7q{kAOb<)9L{xnFNSf!JJ;vfJ8Ft7=^-%gmBxb-5KJ;1=; z#CISB8EW?dZST@P+ikb`%vL4_CP?M~{5AF!<*q@#bl!-N$uRT%cno@^394f4DSQAf z>gRuo1*1r?heRC=6?Vo=O9l>JMfJdILPH-YunMt_xk`K77r%=Gt1X;NSL(GJ?Dw%! z3Yv(_@wNJ;02vKB`3RS&Sj+;uR&r*yBqODumMVRDP|$FAFdhJJSq)KjE`0JtZx4V? zDZ4o04$07zZMjM2&bSgBS@gp%6{#d&d?UokE_Xd ztYq#=HKm1}w4w{Z91K)UYfctBrODf=T(=T##bA=9f4vhVFdZ*=*!lhLEn%=ZX{d(= zi>Dd%xV9BkjKgtPpXPvHxzf%M!Mj|eKDH_zL2wvwTrQ#4{D=TS#z506N5(D#=49Hl z$w!}7C8sUrRKJNP80*@Yiv1LJzwnjS!3Xzuvx=1qqSqo@vCt61fZnf^#@3^l<`c`A zv2)jl@oN`73VZmfAUMiHr>hQmuCzj-@jLE4{JTgV^weK2?*9}zmUJw|ct8gDdstkX zA$c4oQj!;~GH6-ZpbYkjHRVth=WMXYa2ch}jAmXZ!J-Y|2NsGrc-OBJ(%+DJU&ST% zZcAK-*APMGij%z+5KFTOw-gwT@Ca4~P%W>_r67;+m|7Y})N|~&Avgnn(QbmRW3#+& zx9Of@%i8XJ%aWGScIwL^b}d4@i-W+~g=6re60wJLgNyxF=)MN@eRO7(D<>}~zGf~k zdQj)x?Mg#tCKwxL3?m%^#9FHQ}E)QG@^)v@&Wm2-OCR0^g* z4OM50GQX8!ew|w--z?kK=17>0v+s$QGI;ZYD!O~YCQvPuH}2~nQIFSgoW<_LzRC%X znX^7}f4yCW#u3u-T5ms0>mUyBFEIqbWfiAB|3fOUZTlZ;PM*PMu(M<_jv9B5XE%9<+bY1eqdb^@f3JN;?@a?{Rq%pv=pa z&B7ovL>6yYzsYwl2AuXX?3hPI?!9`*>t(+OU(Pz3Z0Q>ltBM3Sn!a1aG&2%2rOF5zc=0?PN zwDAx=3TRm$BSH%$$78gHS7KBY{3sBd$EW4$Dfj|H3Jqf#lz>(Fk`+?YFx8ldu5dd>`GbY2u4Hw_u2sWxKZ}52s+t>{$fs7{X3jyQ9 z>nF5s$Z}lbe5`v6M=C@88+ysDJ7$V2bEo_U3;)v=<+YZIe-k8W#jI8g_fQ@^q#K149)Mms@piai8fA#pyjA0F2I=wr7O=(vFI zJ+~gp%Xi7dMv8cGDw5wf6x2_eg(34N#^82)Y%@Q7e0~6{MIaoSbSIAc#gpFNgENY zp=q5H7^O-?b2D>6Ns>kOMoYt!Qk;@$s}pBNhLou9ER{=QBwv}&E|amy!cFFSm;lpV zqzz}*Y1HR=!SShVtS%(8eJ;b1{JWQAjs%oy_wpgk*(czMb-P^1V`{8HC~UgkKxPP0Q3f!WZLG$9IfM;8~5G)GCa$xF#iz{BTMcL$VnbMdcvfb{w8+{Pd4I{O(our7fK}> zC42*@<6g&UADr31mUyf$!gUD(c}{lVf+%v6do z9A$q$khrsfm-d=uP%kBV{`fuO?Ip@J3UGZV63veFhsYNs8U?*vVO;5_@Gy%dG8j7L zyRzMPHwnDcpLEqwBu8A}#nOd|mC;csVy5Xs`@M>T)Fy2fmpjq=*NRs|)b^8%q-Lov zHZvek4um-(_Zf!baA)LQJaPk<#EH3cD8Ug=e)(|%Gl$-zj!QmS1Z5S$wK`U!r}Sh|oP{T#oe~v-M|lppjFO zmt0=4@#M{z!|P_e_h&Ru&t+w_udgXWk4177-$m=5}QW?h3}uxd9@|IpAy*^ zm$Cd%UoeL=086WG$EpN#nQMzhCOxb5y@X<K6ukToi_btCL;D0!8`Zxgf2hX7X`Gv!7FI++!QAHu7CS8n$ zS#w@P4g|G!ai&TG=z?D4kgZPWMuXInU~`GhjH5 zj=zcKhZPug3a?Y$PmqQ&KaNHXz|tpvLF#UPKF$AK!`tDDrx|>Ln#@ni&pAml4a9qQ zTiRs$f|G~$U1iiKy7K+r#Co%(s3&WG+q?S3%2)AV2ducic$1pjK-{At!TZ_dT zlm@Lo%}FA(n#=QSWz5ZSUx4+fkO_(vAuc&{gB`CS9RmvlZYMK@}C=9lVVZ&rEM1;|h+N4o-@#&?E?gA8pt?A5f zr#|$`T?3KVlbi|YR0+RHon_TJ=gA;;*4%ff=hO+x`qa~syzPrD8bBl-Eh;fYY;+5z zAYl?`Kb*yb#vo4edV)(KqD9S_rfF=}_&hm+#LdW}fD3XTXZ0R1Zv^pJ8xCS$FDYv@Lswb&cWkXl`Iv^ug>*73$ zI^CsJIC(7aADE(Vuna4@5u)fOZF}0H_Ttr!X4CIZ52VagdRtlVMo(J3*{3w=y%R7u z`%{}FN8}5IFh5{k6up37k?I-9_6;2u_t8%D{rVXhX%e$Exb(&Hm2X1?f7N}s)(ZdT zRg%C6Bl)8cO&8oc?l%05#!>%6N%S)=(A?UqS9vj$L0ZRlRmiOVX0UMP-|dNBo&O|? z1q8J|2Oq7zEyLrlPcZ;8CI&Z@dV}*R6&O6hF#crp{eFAup2=$hRNlIe#gt?y(CiLK zjS#bz-sL$DSFG<5GiHdI2QVYrRwq1(#qCCT)l~lTKU1tduXikRAI5R);HbK7IOGB z@;|QXCw1W1|C)GZc<|6}2FUQsX+r9W!}n{^*?KH7^a1;+`UZ(W$t!6}2$Pe$|0M+_ zxYu|za*TY)!zJx?4!m6PQ|0>L$~U6jJ?~kBAAeLz5c~K5Q|ps=;Xf;Tr%!4CN+88@ z+z5ZSY#{3xHyP30!LeJW1LDVfa7=#VK^hLsE@5xbXTRT{{poFT6AX?a z0fTL4dBye(K~D5($HTNYn%lY*7oB7fn;004bHQz3>CmFc{R(xJ#30tgf^-PdBu73yCLLj&Ddrn?k$JWJ+pbl4f0}b>8tO z+I9v3Py-6+el3(-|DTTFx|ICd`;ag@JQ*xqL!N*AnT_kv6KuYct-@9Xk+c`RD1>8n zpU?d0kTie>vm8AUod1&}L__fH45=&Bq{ilk9wa>Q-BfqVz5VEuc7Mw_hgbzRiNiPiGZ{LpWv_8JndAGmEGxE}b zxJdOM3Br|^{0TWuHa*MXXEecbgs708kt8``xjM2O9%N~bnWKOszIws?bRhxa&6A0U zeuv|X=y|g^Xms)(Z?wE^QVa;RzYRFu(@Gsrxa!2o0kEBYq4+=z?xh-E)_swBD2fdr zNz&u{z&i3}sUJz8OI!g(lb}b~Sh=g$jpd}i41+SC0<-3rm8)nCT>S5ar2TJDBj>pP zqT+%{I-O0a!AHT|WPzemgj@}@w4cr1A|(e7@a(f*lXEZh0&x))tYyWGztnl_#Sc48bu-ck~~@5M_{Arg3LV~bS( z%s9}bdtO;;ivW|}efaA2MEEd8yVkp7J8J6ZhwC!C`KuX+l&;NZRl zFcZDkIuPx#op^=#diJ_g)Ihkdr~q6n|04H@1N$mjuF`D6@qq| zN<3CvF7Vo7m}}26+=U#^KonrKBZa7tp!dgT0&4k=%*hHdu&H;}gfipZ0XEdj93`ZI z`vM@nK;YRq)mjt1Zh{tu^D!kKfl)=DSyKN3U=tT|kT)nMy(ItLRs9dakHHaL=^nEN&4k^i3@~19T%f*b*oO4f8S&lRvH{b>N*XVA;3G+T=VnG zHRbqQqF~owChxGYIlUySujFVp^B1Ma4>JHs3asv>c?i8ss|&%m5AzYU+Nn7e0pq(} zuW*Jc)1P(aW)$oi6_M0j`R%asl#@+EOhrgkSkVqE?nrE)F^2P~f|`}K1cSkGZl!%? zxiNSdDuNRLPidjs8ePF&fxGx)^e=RI00it*1NjkMlAFah)l&6W0Mr;`+F;Mt^-|Ij zn`bA%xh_>UwSD74n0*eIEd=Y(?NjnVn<88TvA=q114^oqy?wX$>faifp9+y(r~k)) zL@_W6f_xYP9I=r93|RoxDV`=XMeBu+YH~(5Z@ooU+h^spq}C?b=L^RISD3aI9Kwl| zE1AWy>R7s<0Q&qPxHa=O|22>c{-!XHsrssHMz8_KQmWW;T>ieTEbb!y-^id1dS6*r^02U!i^ufYmI;aCDZ=>aSrb&HD$ z8pOjhETTyYpw|J%*LeU>txT;SX!UYLZ9+0Xw+?UY%DGsm6?_4Hg%W$ig`X_coa72V zyJQkkVrzH^#edVyj^#rTAQP=FpH`$o1Zt+rATBsWQY`#7@)lE6BaF;B6;z~!~jN(;T61{u$B*o`3LVn@(&n)Tjz34rCW5F2Zd4^4D0-p!HTKr5 zSvnu_`0f>wuy7EV_yDBw%D7_crY|Vt$wHSFGEa`d)BeqRqaq8P*`31+wx`+O%|4?| z=ujW*v(bSgXnyB0=XF_c>Hq18bb~0NnE-ppoFCYLc(1u6yP)-6pt+)}M9BF;P~3iV z1+t)z8u^*Ol{Y(r0_1KKAT%UJlCoM&{L|zw3tRtyDn0484rdA_`YyM%U}^ARKLPJp z*YTkK?o|*sNrGd66SNIknGQ`J>|^S4oCpx?DNxWt-9RfmclBCYzr)^d;}_fPico_$ zuCQUp*s(b)U`+>G^>*+r3R=Rtg24ls8{^8L)g&jd( zsk=E3NPuYQu%D^LjT@%<)&n}X6-7jdcX|XBkh|*72hBvPTE+f~=}};Vl|Y@Y%a*P{ zS1HUNPy3;RaAUA*(;kEmkARdOp9rREVnO%%08%da-#!#G>RcZvAU8BRpwrgIN|pfp zQP%m`EKGqD3Jv7)>s9Im(bqqWo&42n{QDuZC*wDLO>)nE_M@#Vi79M3W_}NWuh1&( zpW^V`U^wtNXlMeeG_)ZHRuh?YT;L>?Yt)xR@>(W?Su=gv$k|7e$CRnM!bpEmn5xwM z$io7j2zpvznT+sw0ma>o2xeV#FWqbH)UYzdN=rFjVH&qhr28Y&inHx%9S_pN1(rY%Z~5iRC;bz zet%=*mMnr2?$pY^W3x!Iv{nVTav8Kqs+ZEaZP2!IHA^Mr1@*Ab8Lrc0VS&2A?gEEL zFWAtMTFHT0V)|b_ML#Vf0Ehw^OjLO)Pnp}LRGu);UjCT}Rs(_1PyPd9TnIzWZ4iHK z*PY-OQM2)t>@)o1H(MrI+-oFDN3%p2D|u9*N&lvB`bsfvEsb5$ogrHL-nm5Od2DKJ zCHq*)5DbMYN`JBlyWFmX7G(NiBuTG6pL?3-f1Ho10j_lE)*3f_(Y&lieAW7zvq|qV z^QtR@LooTjG9-A69N$|~+zLqgF}r`p>DhB7k!@0tl8?{C@gR5n>y6!d1F6@dGndaj zgqdS|t$WO$57~dgEN&2^Nq$O9j3Fx-tU%_~>H=$Zx@aZv4ba}O?oWSaU)ETYx+Mfe z?uX$BZ=sXpzq}(Op7UP(H*NgKoIL`#L>AV>OG8rg^~N5o{aj6C>!%4u3j_js>K;k6 z?`DUP3lCSYC&neK`6t4k{;Yp(bN!{#o7Z8DGD4RTYPsNjGxoEGI&NgeM)nQEgjX#c zb6TIu?gsPnq5VEIyl{iL{;*@ka{-swk0*`)Gnd@OGuv?1e%U|S)&zfx;s{Xx&tu}` z`^&83)!51}#^6wnZDa@AgLVEtIqOj;p2tB8dMV)SJaFT!or#2397L#tOvv zC~e(xlgRmlU`q1j4d44a_eCDJ`CE!24_Z#N30|haCSutKaFU;H>=0EZ>k4l^+?yoN z&_W0>4qg`Z?aPDL1=g&DJyjh^~m$H7^1YgBBM0UdefOVtzy?+-EBtJn- z9_hq0_P2u(33E1MHV1W#gMV+1-v&s1T`D^agIh%=d}i!km@(`=30mpx-1_qQl)`@h zXJvF+7ucgK7R!L!vUfK@*(|XK>Y)e!eYS0x3=cZ~A=NR*b<#iL@u$l51)F0KU3L5h zCFXJ-vee^a-wEOOnczT)cQl17p$_eR)O214PbTEg=eB%y9Z$q*HXi%|>E_(7$h>bY zp!fKf;hPUb0a(^Rhw^{Qcj5f8J&MEWIIbx{&4c<+sY>x#aW6 zo-g5O3Yd#DzHx6v!~?>GJ%;dLf9|5m?(Z;a=t=qgzvDL(=$tIf)KywqPTZ2+hJ%BL zN1no3P*}i$L<;enb91W|{g2OA!=YQ+)ZEhA*51)_-u{Gmaz;-dySOPFqacWOrwua| z*zV{_CL{jI%ye&``0UeX|A*&$LSF@d@wb4Ui@AhQ=XRTrHUc5~`HQHMtR(CCRv|+y zccnRs)x8#5OEO8y$H=i4$(J|a7A4J~qVHaQ-9ToZb0OruqJPD}BCy7tt@5lDXAQ;O zH-Io&2JFO}M^jKf%$91fw6)*rRFD7sl}WGVsx0FqPRN$YgAsoQo;~_YkjZ{OEnC5X z?`MY=*cf_D%exKb$aO~7Ng;Tji>^q&S6b=!?2y0pB->}IP|hP@Kwe@5%46)0f|K`L zZQSIpD_)#Ax_L4rIn59q#W1pa&@{7Iw$HPxi%gWMCHXQkKd`vi(LBy&CFeuWSRc;P zAN(+%u~eE!{=pV%87IU>Dj?Ayd35>}zRqP`*Z12C9iX%YcI`YSYLM~hjszxiuKIO{ z7A>Q|!7=Eksg~F9mO!Z*OkBO?>p-*|yYlJqE^kR#73B zaPGu2e5jq7kVhIlt!MoIbFN4*oh$n1p3gyqcZFhg;=j6`b=EpQB#$ag1?ZTOhp?r{OWV9#Lz zZyIU*e)IY+Wad!RP}v!581J~XcX}PF%r<#f$Kq(G{>?|~WM>rwe~R+wSofvJRT2%s zfX!<#T0mbpNU+*rix{0J(0Pudp?4-Xuk&AjLCPb7(bhGW#$#+p@Sx#eX(q`b-*Q+U zl{{YYC4=!-0l+_#oh3T=ihCI_L+3wj)6U39PDz4%`OasxlS#nbso{!~6Jl#4-;Q%^2_Q!A~KOfDUQ z3QGzUhLSGSN`*qFEV$2_R%+2&OsEr9UInZ+M*uAEohl*rfU{1d#+C_a)y>>5{*~3B z{PAa_lmG)!s{Ia^g>UspX4vmeZ+8@B*(?^}3icu}VWb%98<%ha5u%Bl@b_~X>4n~I zz?#6`^Z9-jA9jt_d|xe}JajwML0H4*`{$T>WR+qXrdd)ae9L+kUx>lVPo6+uTiD1Y zLh)an)r58zg0i1*peO))H=3NCoW?3oIL5dB0D(Of$3;9*;*IF6C#=`A@ni0{NH&Eq zXTf6dJ+;~>`Id&yWQNQeA~(l!He^>I!aEf-5fT0B8TDTte9y4V)(}MD*+Kis(hc<% zYm?9dfWuP_plP7+c{q!?K7w$=_In}O#o#%W_I?a{Di(>RlRGTp*A%%XAt&0ucaUHx zkHDP^eZ61r%4$`M{Y0TT-9hIy)$nNeU=f;XQlY(~5~{MSlW>?+$9rRwLwT@h=x<9d60@Uq$iZ^LR+QAhmVY{6 zmaAl>!;TdA+d`2;A|YQqQ_)&kdxTeyq;^?tX;ex*^uM8;WP>5)L7O!rRJv@IXQq)r zcWf27lcHEwUPf09F-2GJ%-G|6U8^!N`Xy7=2>Lh0Ef%Ak<8$_!%7Eo*Y-xSHF z`uYrgW;a!2LdpB3n`?;YX_E!U>F;SN7_#94$0TA>rZX(-0FUyarYX_6V#hoqss?>p zT`EbJ4wIgB`ner1CLNWBW_%JPh6D4CMT*e8M)8l<6tLCEobam$hy6sabAS&SaRuB0 z>$xlx*{sCMuz4X;J2`6YfqfZKuA1=iI;W)Gi%T4Pa(Dt7_}GVWLIiwIckhyMYkJ@Q zwj=OfgG$5l*3BaEq0lnfy+HPm)pzJe4J4^DvLXAA>i?F#JY7ak-Y&068dBqX0w#2Z zp?^Pur!oOaXg zyPr>V+z>%|!2mH&Rq%W+&;StliR1?@veT)aueo7=IA! zp&AgdHSX=Cz-wZh zS`tJI0N?nT5ZTCF%LGLBImi+c*esky9TdfQ42&`o-$b5&Xks^bPk}xW`!^pM%oW$Y z9S?CnR$Gn`ePx?u7Rh|=P>-2{OuFr*Z$1MXRuaw*hQx@W{y1D2QbiTM1SgaDqm+(B z%1h2@VIe1@Q%V`J_oFyDERyZ$&W7|jmuB^k3kuOWu>`!GpO{E^B+D4}gt0rxu zp+C~nJhU=azsfYcg9r}Cdzyq>2BhbFC8*p<505^tQ;+;?o{>opdHq#_x5O@XAcM4> zVI4p=0j04R!Je$x1)-hSphADfp{)(udmjXXpa4Rz7-&xqz! zHiX{NI&;bHd}FuOHauHoTu%igr+{{{$jokO&Q8=yXZ@BMBA?c+b$Rb@2vex- z!z}PF1Q~DTcoyk5-W0HxMb=7ko@is9!Ekoq4hVtEVQY5&_fF!e z&&`Nv)%gP$28Z~^R0%VMrTkaS?Vi< z84Yt2(wzPey*}=~pz3%&NZ5$V0a$)zppRvB5 zZTbs3vTbhuF5g8!m?Wsj%%T4}7X%T(rI{S?gamtfh0`dlpyxDq)(JhLPa z3CVd`a@gZw1r-XzmFiGnjrUOrP=Q-n#^_(=HG=p$ZA(;*L~e^IzP#kIe`$L;YS=DO zz_1`Z5QL?KNf1FA#g!>t^3N7C9=aGm4ir_ug8Z^F#|3Y;l~?^%i@*8O*h;&Ushc?^ zz|BttIWLrI%IJpo-onHX0BT`XKtibtKmKerJ+M019~49tvy=wK)2crOg5`=J0lv4^ zxi1c7-F~@ntN(>;uY#jeR#XSN22M^GbxDfrf`t?D`Vq%~46TNbQ9}(wf?~^e(Y4$< zn6vU^K3C)4NWhIyea(;K9O!x<3-=Aax-VyIj{QKwHNYh*Zx}=?h*oor0^<~@4?q@i zS=8SumsSnCt=%fHx03u;u-Z%WY!*Lo>=UdB&asH)gp>ZKcj1DmpE(S)ov!i06^;8? zPb>vkmk7dZ8lKCZc(>hfsZ{`MUh)q~P(LMnF~6~WzeMa+V@@fo>prM2&6%yQjtzx) zaSarVy`J?8>QoVx6q~B4pc`l^u;AC6@e1RK%4*fFfe1nk6+svnx&h10ti2jowv+-H zS6vEX3E*%7g3YpgN3J#NWfQM|Yw~XjzuGa|bpf82S@m~ajStVVoi9^T&lG&^N#r7D z6kJn2&s&#{Y$pe`Ougz9qZw9>v`f%@8nRJX96W+wpn1GpGpyskiVlWR6w%mHmZJ2K zE`h`bD1)@ZlHKdL9I>iWlC7Oh3vEv1_D?#c{={f)>|F_>wYYG76X~wp1#(+Zw^3NC zTwMKsyRCq3zQDAZ;D{LWf!ff}JKfZ*7kG}#Vl!!yl|+E&iD-5ttm;*#4gs$Dv}=U_ zZk;8x`98VJ6I9;UE$>D)1OXN!-8#>^eUG~RoiDIxoow_6$u{`hT30~CC`NmE;twwV zTo*d;ApN4L^Qa8QyuJvm-Xsx@!9h5X(!STZkN0L!z2A3ZSEIV=3%wyS7iHh~l97FF z1I6>{SC|`NG!=M$&Ew7TiS6pAX-)tD}5vYs+V+k0RCxv^F}saR;(zmO_^ zelw(n+nHx4`mEvk2SrK0?nG4B1($OrN^AP?Q%Yv0qrO=}NBC8C7mzo@I>wc*Ojd@w zFt~3MH2!^j+?Idx{CA1Vi-sAe>avTd-=!0US;9giIUkk+QM5s^k6p$UsNV~$KjI!A z4R(wZc(R%1kw2aSang)0!bAlV!@MQDcgPTKw3BL`}(Qsaj1diK2_a)5?|8 z&a%{s37DXrxXIrh_RM3hD+Se6Ygg{KKUrB*e8^UQZ(96u>A)$MT4q0{dv& zxntsDb|0xA1Ce!_Wie5ISv8B=&}$AGR=FlOk<@xxXRhr#>!vc>izHQWx(#>_l`YF; z??42}%%-#~i)*5d?L6PC;#mDq0BY9EJ>?)P&qMG&;Bm191qiP5>t8md1o{66$DIT( zN;jJD#xH7|JAL2IUg^phoEvoen#8f*)3;;AEC?+pikIV(wa2#-F5K8Lu&4qrRrh#i z_laXH945IhseMDxgh0J061UE_q`p*s#l#CoT#`x!N1?ghHfIXS_G&ag8MFBdSLVG7 zU>irgF0&FN!^h8V9z7%8GK2gZ1}*sczNUjjxLMDMNOSW&-y|wwUxYt=a?RW7>nS8U zC+8zs=sA)j;ol1lo|Prn1#+QXIy*m-{hmOrol_CGP+j(B{A_sq{J}SMH{637ij+|Q z!gYOt4p(~hE!}Co@W<-HyTPVSH+X-ORTVt^y19XPbYv*lWJvGzvxj^=9UhU=8b9om z<$;;|VLndiwPuUj=D(}{7es5$VIE)bnsj(Y3|ouoU-)=UURVOxTm%mAKXH}E;`P>* zC8>vMq-(x?)-mkdKYE55EjlExyg6O^CMTI(&mv@+ws0Pp-6dgTzKMbJwXTz5#Rx&! z-plP@>8p#!I=3hct8NCHn2hS6>fLeUPw(D{BrS#f){Do!@5)8AUJ!}~L)OoANIV=> znp;;%P|+g8F7_EKORnGaF}dTJc%{qfXxNU>BIcR7uJESUxLS8>lM(v?^vpU^W#qDA z$?2P?q&D9p?Jf%M{k8wPqoWi-QhcpOfy9{LB$puHZB=5g@B@nFtj`@rHT5A6U^l?~OLm4p+R{bZ_@D-9$-&Rxc>XEVMB9DZ%hlJcZ?1DU{4-$Q3!lCRJ7d9Z?ksaLu6qHR}=9Q3V~5sq|g7ZPvK9c{mz{Ce0t{JGVbH@d~rL9MMNrwL!3QB zoC!t9mdm>-mt|?gQOrzk6im&h3}B z2>(At`LA*mQ6MjJs6oQqAdt&U+eODr53bC@2WQsj9e%eKHGg~ z%DXGzb?jjXSDhkZL8}(GUVZL*tqGmF!0ABa1?1@Xr20Cov@W>*%<~<{c-TaN!XJy? z*5_?P_phl>^(sxJ?V`GZku8?_U^u=^i$qL@30^k|c<@1?FcUyUivdEOxiN^nqN`0^n5-7wJnM%w%iZd{Wj`R~TH7@?!pN9`fpOjZeF-MY_mFnAfoQjSETV zMd@mu*5WWVJ0^P9t)C4Ruk1c`mBG?_0c4A;CQw*8=G;A7F3%j6KyvKVFTb6OuUzaD z88Jraf2(;~{G8t~2p5{Vo$7oPT#h9eeS6RS7p`Y_{R|^9>4O{rdPRYT;9R4ewl-ou zA*)_Yt~s0UYli^Ov?=V^a~7$gI_z1Ra{3!xWlc&(oCOj>3)hRL&4VU~`Bri@w)$^} zsfy)~yLICC*D`7iaU&^NRSc+h(Yb5y3anj=tyM3!sE-)olcj`UOASsNQkM6A=2#TI zBSZM>_9DiiV_nzYSNxql1!9Z8g9Rs>o^|%c866u%7(oa!Ek1>0c}(_0zOKnz`b)q)7CrHy8L*|qHWxNA5{`8?@;<{pkL18+OILd&cJ!yAXISq%&%L!E zlQF!%`|*|KVEln8=iQW7YwT2ZuQzc{k3>&bYFFiDN(&VHD6#GDIJ%W9w~3B@o?jW! zFzo05>*K4lzPYL<_39OYoMz3%JN2a|dyXR2c~&Nm-{^dGx@5=t=bO{i+~7PQu%~p# zeBQXw-`)SsA0N~&mwaU&^!k{c&0XmePZgxTC?4!xHj^(h373e^mo|Cy>V$Nr(s{8L zZ9DNl0k#?dqSXQRqualGx1jtDYv5M%`8dqY=-kUU2YR6co$&&}7q_@4br2CDRxw9U zw?-xf{yKo{^0lBc|Bt=<3To#)xV* zcusq@*fWf9-eI@buJB8-!m>NFl+MK0f4OSIeFW*qiW0rKK=YgR@22cZB>^VSG|dxB zA65Tx%MpT}IWCDl3cDky-{ zV&;dB)N6~^j0Ki8*3;gne>>+62eE>$DlY1+3 zKJue=dSOn!tz^@M=2DxR0uOJwppll>#ky*Be+lWHX|b#MK0TE~LzB@TZD%zehg zeK}4#Z^U^K=@;I*Q)gp0aBSZxEiHr%Pnnx?nF(tzxoZ>t$vW*PMQ-|SefY4#iEFE_ zn6Hi@(c0bGd^ApEDxkx!E&KK0ANzD4h%h`s!WHg3tSmUr*JYd(1T@9xFGw=X|& z{jScraOz^>AJ%#4gWjz3cf%s(AG?DXils1rgci@rm##N=mCu`L9jU)>7M}0F^5tua zxS;CyM_PBEq<#xyeEi^-&CjQTk6Yt)vfg*IK`C+S3M6FdG-Rx-@4a88_#Tzp&ctxWU7=QtnL zpcgN^B@&Q)JU<%af^!NBOLTfy&M=6Is!VGrJJm3*>{OY2qRThbA-mxaZ?k^iT>;cp z@wb)byxBGzJU6Jb92c}w{e55GxcE9>^V@^?&P6WUo{6QGVQK4%l4eI9)3=!)Hd%bu z)61p!^FdWye7Cpk%NC;r3M*)_*1IE@`DP#aXt-x1K3zQbwfQ02L6utIK%4v!$XseOn&-6dG4I=zy^a`Mc& z&ESisNdH}RtJGI9uUFgcbZ0&*XTH^Z|E+bECHea|!#_n13W6dXY}X31CB0FNKivx| zXP%!^uYNHv!l>K+=w@jJC%I8!Rbpnr+>A2KC@LC0Zty@AV@1s5ZbP`${Q$F{v<&nP9SwLWdN(KFUL zwtGs#_gPT^#4nbNcDtpduA~=I(qUYXiO-EOW*B*HBOxBV{bTteJYwwSUG$}_bAY8r&Lm!Mi|x(I39kCScPZd?jQE$xAUm0TAH?X>GscM?f|=6t&;D$_j(_sN=!EiR z5zyOF`Q$yQFiNn`7#FwQniG8?-hqbZ3oCs9X}-ufWltBQOy0nNniERB7BwCnr044kRgLfT+iz=vZKO8erAjnonI;PEiq4G!`PCwm30~dY8Y-r?Et?t zv%HTvQ$dxS#qzwPax#BKp-x4yb46)% zMR`Rm0>IEbSmqeD;uLLn<^?>dMn!&E8CAMJNT=*bS_psaISh3UDZ=j z)z@3qzgYG3sEW#8J*ZPX>|8w>T|Hh={k*q&aF z<;9x!M>RD5n`=5ZH=J)i{r|!)BmWn6`M*!*r&MRC3 zhw164hMiHaeQiD~y^DckMQ0Uwm3ohss&xl^9>wKKrnHr|x~!~JiSmwerD+juszEQd zgcnaQy?Pqwaw~nvCVx&DJJr%(_QyxDe;^7OJv?gQ`>xlQmiUd;WH$EY;cda|aQQo^ z1h&I@fJ9C$7ETh1Sg1;h_8z9G00!IcCT=-oGpJ||FXjeQwCsA$XJ>9MqrW+PlV<2g zNN#`bV_t$eYT9q3;JLN^+mkTexwYvu4Z~q4GOrDmP+;!UES0{m!G9hXDb~ZzyV|)x z&BkAA-l`Op-^ee!_onQvbJ|hV3IlgMjZ|{^*Z9^g(&aRpJYwVE)Qyy*3I}8P%8Id) zdAR&;{Wou^OSO$ZiyC9Nf^mrzY&kfYhWgR~C*v{?c_tX+B4nj8RVif~DO0UOscYOi z_Pq!;f6Q!Dvq{-zype}1Yag#e%Qyh6nMW_d;C%i>Vm7% zgN4#o>5S_k%ocHDg^xEFtjNT{o~^m6s~PWFTF1`{F?}NSvk^%RPhe&8TsFt2Hoqj! z>ktPSA?$8@!-zm;+mpdmdf)i*)!Zq7k(KX-%7~Hl@f2O-T3y&a-Xyz|r?IwS2JjfUN`v(H=(7*eu_lQSV zqZc6Vb#k7)epRzs)03%jGT8v5IeWQA>Gza%eoshzQ18D^Xwd5~-IbF|UkG#ByR5&* z6J+8EvAS%pcHhNHv>$F9qZc)zeypOZ}+FKBwT@wAG`uu-KyBwEKaXvG@566jM zBJ++vBPzLXSTf)5{xRe|`}K5gx8N{G>DLg{J!s?WnjhaRT2B2f&v<*dkA$jz;9*1U z;d*{8$&ZwL_RsB5KY&8OslpI|=#`a&IDg`wwKn3GBH zD9W?nBhRBfD?|^Ov_OwvU&D@!t}u-fQy4JrfF*|dzal7pF#4^SN&~EJm-}UY+iL9JD&?CHU zN)*MG&aUkXj{s)cZ1k>GHa?Z-$SgO*vR>eI)3^x-b1qr$Hm~TT(GxyoUYLpph3rIb zmfAhJ!pbK;g5XB)F^n-PhDb^XPCR$$+b`*`lahSvXYoUJOL@YGJo0fzx|DV6YV`PK zC1q`lwjo#Ok<*~cojK{#u39>-zHxKvwuMsgzKFt$$_IW8V}VabirH{dcgGJWz2!r5 zBxRFyvx#DME;}`QKl3@fb}b#x6*}2JCky>4(F_WZztLHTyW8S;U)(ywq(FTexm97V zT1d!N%xE%}d7dOFZ2%zY<#aqLSzq&xPQD5&riS(^+O()7XYx*3TgA;MlK3-IH!gji z;*r4U4AlESxWo5B=T&+@L7f&$3qJka8%P@!$+-s{_&`U74-3@q81D>8TTG`W1m!?C1Z)7@veMeMXkyq4lW;+=%)2zQSgAo2$FHIc1#lJ zGArv2&3A6in)As0Xk2Qfi1U2t)M;aS&RakxutLW^7G%hHv;3SV7E799qombbIOT>U z0;1&@_*W>GN@5CLdH<0~epY*q`OZanQsW~t0Z!yT4YtD3TCgKo%6XZ~tc^zBhczLg zVllvm{O_k)UO1Lm3=Uj+6ruUu?q*x|xK~~SuN+K9QSvrwG&H-+Vtimru?E9QmAl>$X^xZIVxHEX$l`q|LB)Rae zvfR2#Ms8d2twB|nK#iA{0&?PXlm@!r)^o$*8vD-|A5@ADo~bd-XGI8lo(h#e zlXdN4zoGMj9QTbGC8oC}_`5X<3p99`DV4cW0YIns-IsQNWZ9mew1Rq-XSRiX>CF@B zi#-Xb#?!pkLiICho>Fd8d73$LxzZGGMkG%L(2>mQjS~E`P%Zor5Xa#1_HR6PKd%<( z>GnnH3-sLqf&Kv_Rpx7t=GNypZ`n=OvQQ&|fv?zRU#eHsS)Jzzk4o>`ZluKVR(sCB zIvCeC{nX?pvmB_O$k`UAcy5&nMWb-T1$rM&y9zB@@{ySGI^bX4e%jE}SAM3Flw7xt zftp|J8y|o_*4xjry#(Ru8HBat*$D-Kk)mg#-;CUScT(~}-Wi}7uzGZaw{!kkasU0< z_X>u@FGP6Ych+&*1P{ont0T?!5_in#u!|Y(CkIac%(21QM`8V${G_t_J0F)~ZZQCy z<)Q1R-4bPOg+A9la)0H!cNP-%@AIQ?yfDeAR3-sjK>#-iNWuO4I7T~GD1DFwEqrXXUzDi%aP+O7lC{M+YWs2HVq!|S~8Y4lc;;xu^{2T-L z-o~i_!EW84D#{O$e1`5ty!15yQAxt3C$N+h56M~;vYc(6n{h}BjX9zlY#5QUB;*E`9X#-Q47&~T3g z#Tj{y!Q?Rz2(O%nrqBAYtJiGMd2=u44p4C?{>e7F`;UX+hapIX!0O20h2MSu39i!;eRF)SF^ zIq3vqLxx-wOu-34ZAwt1WkPAG`ozqcP5syoIFt{fhDyh007@Nc!kR$NVU8W2o%Pnm ztS&WcE&pgTWPWK{kz;x45JTq3ublAFC}E#iku4~pN8vb`-k**w z^CnGacrj*}vjQ+RT6QHoR_no)SgpkW(nYy&3J&)19Q>9(P+vzB#IVDkg~9ulgHhIa z2FG3=RTfYo#L^)Ymu~-qL-(VmXt$0W=c%~Y8Oe}E_t^|{6AZvO;VfDTkMz6N78MWq zq3hvQ;97KshmfJ!8^b0GEBT!`I+j|nlNr91s<7*h;&p+b(#l3-%jPpbMHCGnV5uqQ z+$C;%yv6KtN*q4+vyI%!P_=bF+4)ZRiCXDbtt1pfram7Oi3uIa0ID3^!lgqM8H2Ak z*_jufWd7Yb`;;NqYvLM6p$n?#M9HN!BV|Ey+|ifZ>BoP#dTX$r8(zjRa8Ch)jnQ_aD~AD{_26WREY|*BFX&R6ex87uFO}= zqm?JQR9B-prz)b8(x4Dr(AUVCcf0Og{#9xIO86yY7$Iyy>^C4d;yTC@x$xgueSpB{LSI;(Y30wq9M z0(6-Z^;OCKd@i+NTgg`1MhD?Wf-R=P0@p34+=3VZwpqNRkv2Lw@z7tBG+ykAynWw- z((Rn9x}Cho2aQKu>VpA)%i)~z_2yg29~^_s1nex1A?KevH|;=|50$64aB{~Y^*RlW z6Vi^6@Un)ou!zEk6E*k!bF<}P&m&-tRHHZ-J`@J}vLt-ODMxt^R1tAY&Bizi)7hnd>% znQu41g49Jetc6Cun|5z-XLZ8}F1adu?ISyt^D=S6dZTw3#PW>6(nJUd5olP2VF)G|Qu$oDwR08R`A?e#;CKdrVF@Aw5Oaeh zTidr!a^5_lCxRN0VHN;L9`F1idvaT`sfL>b`}NQ{^qfNXc{|NF*FZ@SkYP7`O#c*v zCXi?@;sf(+!V4KNdfPzayI?|U1)Ia1r8o+o1g>arnUu zkg)g6jk6~yMyh!AL?2QPcklubWT**NsBCxy%dMz~q1z_F&>`5O_zd$G^qjh$4MOUw z;Vxw`9Bt4rP`cZ4%w%uyZf}VhZZhJXd1dt7=Wf>7=3S1|pyOnIh9b5nFHZBL_zJ}p z@BPMZ-buWM*5o1}ba1b90H~7}h@2|9|4@oP9juN`O%e+5Qv`d}+c4u}M`OU%&7Ryh z{U%c{1XFwsy(cq&4k;1DOaKsxogN6ddRWJ{HmbhpcEOe7RI-e6T3LTI0TC4ba5Nnj zIR|As4bex+?wCTq3q}}rATRHV9LhsnGt&0MlT`qi5fjNaUr&aL;!Jyb`qX=DX*&Lo$uKGd?cO<(}v6JLgD_R*D%? zY$|->IR9jFer-!s2K(6jWo>Y3k|vR^b41N<1*{~FZ%hTlw*aYHg?zZD9|4fY=7?!0 znZ_CIXHEpKl+*W?r7etjv;t_0V#d;t?S-1Tg{SxB@<-mjc$hQN=Cy#U4y_&2*V`LE zZE`hkN$SI1X|{TM@4g*02`WKCcwolPOJqqb%o&Wp{-nm%DS^_sr<90LHPlkJ?TY&H zQ`hm%rRaIRmt(k&`@379DnM&MwJdq})ps!wpp$m~58N~xH9dPc554EXhfukQ~I0j6$b2wm^rvLC;@kr+5lQ$xNwq!Uv7YF{(U(BL0#Qxc&}9) z`n(h_{?txuU^uxfu`21*`wn(i$uKMGE%mkA|E=ffWdcToO*;LU_HRfuZLTpB8bFQ0 zm)@5?1f8cS%TM4Bobt8IpK6&8ImzBu)q?4sYM2}bMJDuRDKD>F)<|{ee+?0q&tv_E zJ(IohOh^_~lPg7+!OrKtXD=yT5{58gSEv$CQ!MWOY;$WGFBjsN{r;9Tzn$?UGFi7Q z;Y4w}>%zPG7Sq56K(8ZFA5DFj^kL6Eq~;VWlU;-1yfI8~LmUs)>^P}JN1C{#r35_q z=yTPv;jI&$P0{KfT2umDfltq;6D20@9h-fFl3?-#6ZbIl%z6hMtlb&h!h_=YR=%F~ zl)CIS&e>Ni5gVMAlAZ5O<&7Pn3WO%~_M*UZlPvX%dTgK>7GZ_%f4j1*MwuG;4RVrR z7hA8WqabD^SW#1JO(iVv)wf?&Fck_otQTNN08Kj5y&ib0X!z(gzDPgdXN0hVzc*ps z=Byp@@BRynah@|<0aM1r@p!-sDlz$0fQM@GsplHKw$Y zpkILpkPWm~X2bbiwuhgu1%tpUvJj%00a_6d+qomfVW3j%z{q%NWaFk$4&T(4dEKI* z+f>%ytp%l877c4YcIAQ`4Y}Nt!`ylQ8f8aC+)+=2yZ1Yh!@hPWzx^9NbDo5Qg#vNr zN!xYJUL7oiTk^)wgTxb~IY-JURyNAsUcrge7Tw(I?oDJqVHQUlJ{MbF=lUM-?^o)z z>>36JSW zRfbi9_MirZO8B<-egDVLU-XLY-j^>CH&<8LtjbRpe7!Z0%%HZ43zixr*`Op0tI^4f zt=TYymmCde(P5USFI!+d!6AL&&q6KM8sfnM;qzqjP#uEiS=MMazi3ckzjqmfOcT(Nf;&F#X43NW|Vv-w6TVjy~m;9x{uub=7h?*kesjSzF3vRu# zhha0HBqVD=Va}mpM)z0M;oh6>>Qk;KcFk_az`C451-w{rGf8Xyo z?8KbSZcrfj75Dgv_B)0*8MV`tWk&fX6<~Vc6 zQRL)4o$0yIKW zUrVnvs4S#HtxEZyZUWQ%U8$&NvNd}Ve^~aO(vPSlNJ@$Y6xZG6IsK~qad;MI2va;D zXQkU)wEN&V%sB{WWa#wyY>gAmh=rxPQr@!dkv56_gZ*>A2i1lY5@0cWItB9iA>rGT z1F-oUBW~@yXsq}~CgbVOYk_-;W2VlHt_$+K+(Die=dU(ik{5i(@Lvt);{cNZO{wRO zDkTZE`DmQVgd87NQL1a2vXN66#)l|a3KbY4hTGfj7Zp~{QU{l}wq7u>uNQ9)yZZQb zwz0;9Z$1L{2oP4al#`f`EERWqYO>WPowr|E`?~XkSO3$vk5O?V|9EveKXi%FK{KOT zM|4R}WrnB4yW^d(4drVcDua;3ZhtF_go^inS%=b>?Kl{y$#Itl?=(e4unUX~9&FwB zB6TLoOnQ?Q?N#bvQ}a71k*VDGmVeS)iM^TKskgE`BBX8w8hj2~r%+kYPr@Ryo0o=< zzFQ4?TP@qZdYSRz_J=2Z#B-rSJ|Q_l{jz}eI0nMuaBs13v+ZEd5VkA+tsaT&w|sPE z=vfnW{^LEx7s;>Ne>5kt{e4;barU+dY_zL)reetXKLr$<4KZcuuADs-zwF}{oTAv& z77ySO7ce%7Toxz9Kv>2A_p$Y}m%)C~JW${fZHtEqjuIVOU3tV&s^qKm1yiRD9I`kj zLfcxr)OC`Os(8ak=BLEvQB)*!D211@!<4VEc91g1P+E5Pl}Ri!ry%J2 zJt752K%bIy!EA~};Rf}E^znBFRxT=lAb@DeJ@RcP&Z~rN9=5|ZX#QVgNhvw@b38k; zCuNiMpmsEjv56*S)-x!>>x|j4q!h=Xy|jul#P_e}Lf*5?19r4z#d=bV*0KnD7f#rg z;*m-Ez6r@A0%9x_P?>X(+c0zT%dec&mw)ZmYlck%99o6vStNMzGzi=Y!;B=8SbZ>) zyiUX13VR#3)Jrcua)Z=x1bdk0qmm&`N{9;gf^5TMFat}-+t~+x=WTbMf+^=EF*NDs zW4n^sen>IwU}^+f?tl9J+Lq(X8|nY>))qc~MpY;YCYz2_#y2?dy?T>HQJ?q^3o3An zE8|1yoRZ*Ab#ZPKiD^nVIoW|wuCz?Oh!F}FQ=n2`b6CrN+)F4U29 zgAr88U4!#tfcwEOqBG9meDjhJgZ68q^M6XXdpGmiBUGg1U;vMHU#eo;52?VrpHICm zN$%;gb6&QkGJQSQ3mK+VN!|sZ`|>b|`fpW{<;mXT-ZI`vDiVn&DVoKYq7U~v7TlA9 z6OUfHvr+Teb*|falJJZ_6XWZJOZ>xawXOw=8Jx9s2victzt;zc^OTbq?WW-FsDzn(I4aYs`?+2s3K?0t8chL5)GtV!mqDJ|dm#PJrzh+m1_rg5AL)Bfy89NGc2B zfef~h4BV?PYcQ@d@aEhbu+x^KZ6WHGms$d$Oh7-H!H^}_9~o1yf1-#e)$QTYVqi&P5P@_A|x0HT+!Fs zHMsMmQyKWebBgbH%57vP?Re^W0^4hD`SHP`e{XUhElV*g_{kf-R)D1h@Q;3$a_x0L z_{2}m=MLra@%2o5$lpYH&$S!odyyZ)=w=YAW^BNEoO!Z&IrKm*VoSrPG6pYcNva)< zuoC~X<#Zu748MwS6Mv?;XjmVIYk%M;miZ}c9TrGoYC&8wD zRxK&o(TyCe{_0BJV+7!ufxEbp`}jrXX9nr9n~qsvO>N6nTrNeEB8jAyC}&4}#1gh-r)y?V_Jt{&@2D((hYaihI}CqDOjN%QjDowrL|E z`b|uokMH!oab(@*U%+)bFMy($uSbZ2+eU0nFY-;!_RZQBi3+X_e*7jMRH5S{y>&W? z-Rs*eg5nsIqvNRedfwFQ=X}G#qmhCR5CuY1GS*CdO#Z8n<=p*?2ovESk}$Ue#|mBu znh4ObOc4}w%v@ZUfswbdW8ndv2FXFDI4R>HUu9b=TL&B9@Wjev#L0wjIkJf(yP7IgE?Pn`n`7F=0a#cRDA& z@a!h?YR9I48y2BSHO={9G>=H;p~;fEPA~{6N0}JRp~ySkh}bulth2zORVu7;JJeS~ z#&t|Z8wFT$J8h@J(4saKSD;5$Dz&LMh`Kw z6cOnJ9x4Q%bcWdmh9KcpeL~|>(}NKKyK_cg95mv--`HGZ;+TrEZ!oanf@)4(cgCb% zT+Jl=Nzu>3Hgj0gi46{9!u1o_8G&{#FGchR$vDh`z0=Q%p$^9Hk<~ zF)nf`D#)Wmqer?z-Q+H*vcN%Y^Ua8P4T$OtV=O;M(i;52Zq|0HvtKyOG1?~ALT?93 zbmS|wB;c*>t=GLs; zQ;gb*!XVFsLF+VQddV+(uA4NN>eqLG_xK%*Xj6BxB&U}pC>X;0QhG{ zSW0?Si0+-xb5Y8~lw!FG8_wDTSXsUl6o~=_Pz?fmFy6himHKi|6wnV;<#twM$k2<} zCcI0t00CgXBUVDaq@%)fT`pJ;3z1u^mBcijF>cJ&0eJoN)C>Q|wftObB6TV7F~W>| zFZWcoLNQ@2qrlS}gtNSDIiY|Y&hIl&svaOj2TW{kK;?}vIi=4Q20a_c|0I1ZV5VQoC08qppbp2fW=8blNx^|bohAylN^P6)V1|Z#P z2&yZWh}Jok1T(BZwLB{jE9bWpUGap*XN7}US%X6p$XNObjULKM059y`_WDFIAVOAu zsvB_wqQ9!8$#74inRI>pk4QGI7$Q2<^H^>XCSd%n!uW5n-{+4QWiZXT)VCso>m0 z$EWFS17s@5Jc? zVCqNk8pc0RS5gTts$>W}O>x%8ndH0?vxSEYLrf3(C`DP?<*GGuRb2L16KI%SS zDH!%p2mejb)63{_C*jkS~ZUW4h@XRUz>ch!+~MnH)h+A^FLs7)%o&)S!bO)rI~K zB++W^!Vrc()v>L+KYQZAc74*gOe$fY!IB;UAWp;(7`4@N#QZb+=_~D?rLbUhBX&#r z^C#ov6o=o4P~HQ_4If{&vOCifB5Z_bIVvyI4`r?q05}b%F8KKN|GpSP?c;-e!gay{`(H(c_APIBJR`!YLXV zx@qcL21!H{^5;C6*J_#1ib+adniHjgCRB8RJ4dvKIyY3%Rvh}mb(WC~t;s2^GE^w- zVD6_5mkK?RWVtOBJ8raXwvak|%{^&AadJ$MEwbQlS}MT$QdDLt>#t5QGsk#7rP^MAgl%uBY;@Eg4Wu}(wUW) z$uq!ZB50trkiIP*!U5sz6Faw(xiG2vp4**c8cc9*QSrGJz7>M<^X+T&kajlyOk;#o z>&t~?o4&l%oskh=Yth=$@UM~ z5H9ZvbN7Yl#VMoC%b_C#k~0@J|1Y(V$~B~>0lrj%ud*ou0?Ow zl^;sw2KZi!FL%fZSWkXcM+i0v6nm}9^hz>X)MmF~QRCrt+!QEtK~k-?BT#wju-NRs zaMrR9tG1VCFA{(bQyJ=GHUTe?bnDY+dVB1Ig=~2u@dp;&6ynJpL9qUo)LbXeI~rJj zfD*X{7F|5by^3P7Dp^N3ZF55lToRtpV8-|RI?w7t`>bQh^q~MG5B|Tc4@i16W=|k! zmGy)v=e_`nZp32ZtJz1$O2P zth(mrEy_(O2NKGy0%d@LEG#Wx3kOfagNKj0dwTmG_dn@HQ8Vc=fy02dYKck*LjkC! zppQ1=^f@OZBf2EI$QmsHpwdS+HaEvmvU0AR8fF~&Gv9xF=P>(?l;*@B5IVfZ>I_`v zm~=)_PGdgRv5s0SLu?+&{Qrer)TF1#o+I3+);SDlDh7kuX0lfpq9bA4(idtyZhRat zCgt-Nln%6D>cRS(+;(2yO&&B&-+oAfFzGv_VHKiqYl>5QttV8d~95CU2WKbZ-yBdL1dN;pQJI{QQfid-Uor~?O(TnL#HfwUnRa3UQaxY+1ML0 zg?LCVa*DYTMHr%=*uFkv28+b;a8jqzSz;+vI2*qgf#LcwglxcMX6)eQZA{uTNvtR- zG5~5+WMx3MzRe*tXznKvpxhriq3}{2`X*g$pKE|yuexcc&O&apDr+p3(MJWDN5eU3 zg>cRx-{(v%)LSWuLm0$RVbUb%8FWfvWb?d;6na=*h=qxdS1vv?k;%s6w*e`YA&zfv zxY<;{UD1g9n z9tC=2$&a=&0HsSkta*~vC}HQvA6qhzNIrsm=bbFGl)?y&3EnnztV*sv&#;y#yU^#B zHzO0l15hTBal!z%!8y~8ab7+`5{xsd18<}qMI2_C9(9wELUs&JNZ;;|&SZMfux6XS z#fBv@={pg|`gk9={6);uhv1Z}mnnUI3g_}gEd zZr+$5Z$V~a7z6TR0zdRMGk_i5)GJRhRNH5Hp#@$p$>A$R`})B#2>oVo+=vAQq*p`N8%j+6H)H zCMWLy^@aOR&H#isnXj_8<1W(J`0VelvaSmjhf0&8N;~-IF&-L38{$ml5$-3M__h^x z90tnw>zt!73xeI4oTLw26G)gSV(d)kw5PwMmr*Z&zX}J~F{5(1*5}w(wq-r>)bz7n zlXIpx$e)Jx0EZXF%x<_;8SHc>IY)B9kbaW2Y)Ss@JkAHDsq_npIUE2t&(CSg@Qwz@ z-XXHeTdgKT>j~ab%V_MuVQ+)>2!zDqmCrUkWcZ$4@F;}sW7-kKRM)0(+_I4*n+Y0u z?dxAQWaI51f#|RxW-PU;b$PZ73iHQavrZJS$mC$Xi^YqD-0r2%_poPt74qpEQuJ?D zcV+W5WhLJ_wfXSjWr4zgVHQ7?+@o=6AC-!Abd~ANz2r3gRgm#yv7DhzPOHxuQ{_Cx zy!3alY!yBc1u`ZqT}KPsOzR!B`jWoGKYQZ^(vb zvPa3Pa9iM+qyhJTJycF$Tr1TyIExowNO)z-%i!|1B`TP3d4G^9d(<8&bZOyAk0*&4 z=1$-i!)Slo7%VEq12@s4lEi(muG7ElNBwSQWyEWAEJacGtv}L)oXYG+V#*F1cw!}E zcU5w(0Ip%fX1-K*x`JwXv6$s+Q-J;52<~&gwX6L8be*0uY(Dc@ELFb`YGWt-)~gsL z^T30Lt3(sZZA1s1S>99`joaMIN}A7-B_^TwWIO)orJb;Nm7&dSAe~vljsNkrvTC7< zGyS{F2&F&SpbMuUt>?-wM|9tuuKeA~dPP|TzP1*HHkbeJ#? z`>K&FK2=XPYJg>6Lrn5xB9|=9(^=avqeRZ#EP(K|An_i;keojcp1RsvqmujNM~%XN zq*^wm*WCB~Mzmx|wW}6QH#u7-9|X{l6WLc?`A^i7YwRfCzlXTvo0F! z#7h$R?$pB5^Q5zge_E8OmtEoxbW$`S#@x9v?f#De3$(yl8kK4rf zcm_Ceuf61!Y?Z zX&H+h+fU+lO6GFEs*a2JBXfQ+J=l=f8{!n!JB(VNNB%2GYUm=tq2Q^elnY$R_F;;b zeUt6X(bC$8k7;gtI|;qp5p0ko85#^Tpejp*N7flznJX%pCp((K&^_)a)~WW|kUovH zC#!P)wGoAP;>f;iKMgh52411nrDUi3lC;n>GW-&a zK2tJroIu{%0t!U~L{ZY+S~+n$iNoAk#Xjk2v*AtSQHl^3niEJb^>R9eHX_OQ?$B#~ zdbO!O-u8*eXkczT@%?;E)Z2vry7RVxq{=lwh={2Q2HwizJV(zo{$h*ifMY5O5E_Nc zfW$KVj z=92aK3NCaCd1OlX0MOnh%fQ7-Bo^sK|M3*dN{wqxo1)-gO5;)Zl?b>l1$r^Ff}$ZM zO%BO6^Qp&H#f`9sn)uvKZ>U@C`tP6BB8g{ROC}g0C=lL zSEO%A3!v-LYS37SE`a<)iAusTKH>BK;uN&8D>yiw$bW;)4F_4qS>n%~M&LoIJqrcu zX^E@`=YTpda^1;PB)^zu&yeIFxyC!*V7}MY@!u!mqFYV6L~^A7#G6p(O$6YX#4C?N zov4BUrs;}G%98>8ZJi*pDrjtGnFF&(?}PY~y>06NspBT+fSSM5%O`unmUbcxLz2h* z4tN_V-DH`&ad*xIitg~f`LTi~%^-Q)BJ~zV!IU3OBi=n>xSPbhz2TGy0S^k;;Q}FX&z#^PXV$VyvMRt!nc&Tp9J09Mt~3Rjg~?41Uewh zNJpCJORdcRhrRdwYAW#7bys@mp%)QC??{o35PDTYuVUz+h@p1~JrwD^89Jyay$Kq6 z6AcIos0d0I6%iG&aPr%G-*Lt`U+=x2?#;ijGS*mg&i8$u9cq4)u3cY>>UM%~44);x zb_@;&AwcKu55C}hfrp74HV32RmhGA`G!b`_6ZSi6N{_OKmM+|myw}H*B|*rWAHU~h z#?47VsGsZg!AJG%#zfb&kZfD^AN4A&=dkMo|RR75GT<^+}?3jFk zWedC=mTDe40G1-fXJG5!poj$>r3`jG-=cb!Kp>z1qSEX@+;mVjlSb!u20j9L<}y7E zSBQvaih9(me=k@8hhRIbY`xe=6W*?VIPi_TDbNhw6z&rcaXX-IaHhW)F91daMJAns z*wrM2a4xjUj7RDZZ>ngUmcZT&^!Pi=pk@4+9G2^V^jmLnha{cc+wID^r(0pf?o z?rC`!U&Za34F|&EHDxCN!lHXvt_HLrLPf9YEbt&u6}A&FtZN zCip$wH5(Lm1!o>p0C6P2A=mHYDR2)t$+eC1aO@)^;K|p_)&Muq_Zv^_a_v6t)Y0*v zdEM^*`#lhdg(OPE+vr14#!woUs2VR2^@5}yo>kPy#crBSRc3rU>hCKX-u3gW3r3=P zu$vm@_nf&=O4Pdm+!F)$!NP9_I@)ZWhi^RAlNeQe15yu%#^Oi6-+&oEVs7LlU*bi# zM*?EJV-rsBDHZb5omBB1ECQX}c+vZpyA8kCsf;_ct`6xWA zHI^=$0}Xb;&(a$9tjvCa`Tik=hBU)R{A;7vIpFIv{@!ExkH&x%tNpf-)Zp9{hx6+H`tpa;J#JYe+YCR6eq!rCvUOZ|2W`Iy2K{ zJwU>Ix5EKgn>nH#Hu~|2vndU1?y*S_#b|JFTKWtl&nZ`#DC9|l(^Q@BJtP}u%#$E~ zEW9{zLiaV+XQz@Q+<9ZRWAF=q7)M^Tg`2ky1_K-@KpgYD_h6E}y_g04*t94QtOG6h zu3=9`44sQc$b+J>_r+bnw7IZWPv9x1ZJ>0#$$bha2!zH$e}@xJ1eIN5Dq-_ow){js0Vf6aQpbo*d%L=lOWC71_+V>9}bWdruEEZk zv9Eixz)4bGjR{u;5j%F&)`6LszEzL5b>N{FLIWLu8rvsbk>qq@O0dj;p7Z1p=P1e&78j zzm*?1I~kiK5(va#o(p)MfwA*Hl7?ajR;l_IF@vQL2l*nuiLNGy@Iuax$ONfOL5F?lgFCR zmpr|kaUc%>!qEn!1-2Sx_iP!JzsbbIrFWb!eWWT^oZ5W(N_RGH?hdYrv&OEaeJjX4 zhMY6Bg8{JT0`L_8Mh%OLwmCnGJA{7*1`asnl(t-O2-F=U>K5X*>|X4poo}(9bEQ`I z*8qrieO$!HJ1%sOw7%5P``x)jlpxP`D0>H;@80EvQo0!?*8l?&)MNf7^2s;Vm?SYF z(ABYT8vHMeWzPEZrB*|#2b7-_mpZG)@Oy6_*wuLXvcFtuwbaAF?CgVr6f z*lZgG7?rw5x^Oz8&PMvCtG(6l(j+wVIOwJd(&U`tyozDdvJr z{E@0wB7kW)iR)xg={iq6@{kUf4AVxf86t7orX+@YiX1nzf5y;%;-Qd|afs@72mODe zHe6OK-BIoC;B^yip)b&+hYTsVPQIVskjg1WhDx)bM_0?iMGs!I1px|&@b8&maSSL$ zfB5P1UsD&3Z#^jvymlJ$&R8C-~od!*AUVZ^p#a;Lx zg9~+ITPbV9V7D*ox`Pqr7o|KwSeRcO)t zSqHm<8MdyJp+IhBqYj<9I>??`>-J18#p`1t%p;Pr{QThcye)Ey?_cTLGj8D5JvW;f zYp}nd$s~4WQ7Cz`AWw?{ZqBf8!p2N1B~frXyP5hTJ)xS`6fAjcOv}sE`8b1kP;!=( zQKg)5-t32kQH}urdt+u$@`A~HkW2J0D_xH0v=K)I{FqHLBzA#aB;(@P;G?9>{b-F( zcQPBXRazn^Oaa-D?bC?GnUx~_YgfoYl4b+PZJqZPbd%de5Rrp&3*EeGcTXHoph0uxj>0&TQD~q) z#-Jst{DkFAs;s_Pgoo@#qhn+K11&Nal%U%!#wiQfXshW<&mISdc%oS|e?#mNUFiO1od zy<<1ai4a3`A!j7~py@u8j!$lwD|QM+KyGA2BN0Mv6-Imq9Ut`pIePU3Bpr#|FsHin zCg{=UfsgtSQ*i-qnn%y1a$9_Af4yXlDJw`pc7Og|rNEtq?XrgWv@$D0@uHscAbJk}8UnpSeJ=Q&!m(Qd48H7uVJ2pNwPEMK z2!ufRk>|_q>fgKmYpcX4^&-2?^0}+RONAdUE?Pa}X69r7?tkCs3jF)lDK>rRzL}DA z6rs1w^y!uEzf)ml2eI7c_iI$RuWQCDt}-OuR%6>Zi7YHYpZz^9@(B3riJ|*j+ENw$ z?^gm1{DL05p~7|cNp&s>`tg9(dUjD*hD)a-5y^D3lhr>DJa^UVaBOw)q-w=92v`T@ zV3Y5juQ{=1CWJs{3e&2F%vCO2b2W z%mJ_CfM>!OPjDGp;y5r=*yio$M#5iPiK|L_rU)i?287^40^FYq{L#CD2aPv`tI}W- zITK`nc`?4M+e(aHv?!N#K=`6SxU zGZBL;tGN@@W((3>T3@7m5n=|)1ED+-RyCT;39!U)!sS(j-8?cOP9OQy>%BNseLpW} zB#pLUsl#dI;H}8>rIO+qI19P|%uLU7{$X4~M`eN92V}N*9B zLj^g16sG(-Kb(0X#WwD`Vja&G8mf)m6dY$xq|x{DcDuw_pe1(BKhXM)SXl<>0U3r| z2N3tfIcOtD8KXT4gm=jN zpnDmeare@7|Ea)c$5@Z982Y=aR1Bec?aTZEAOSoj2G-h;qf=^o&CW*6(X8VX1yeA5 z(ysto3RqZdMEWD?hSdEjz>!&XguOX=;l1}pm#7@!I=5a+v1wrUkcZO&hbQQt#Bs51 zmmT=eKzs3(E*72AeEKs{Jd~e;9-JLXXF8|_*w*(h^Pbp8^5mwC%#3vKEd{(>?SGhe zltBLWXz||z@kA=V94heRLd;Jc2}m-gr)aER=+)x-{DXTr{=pSJT;k&Z%XJ;1r)V~T z?K10q65JUzoOE7r29Ej!DcJff*>P_pA<+K1&{hI?M*YbXPd9qO(K@Mvby_`gt#{12 zwTab%!DDY}gw(cFyoU-1Mv;D)-rt^98<>z4$U61TMP4@s51^l)K>rTaqn_mdcco`*_&_H#Z(T> z0q^`s9MfM}lc=+gzi*t^Y2o}r{3;a}D2vuu`}ABV;e~UbKlAC!;pF(0a2tj3z~Nv` zdOhRW#L(|T(HB{KR}eHu>kwMJ6ITG5)mr&;SEZNT@lX)|?Z=FV%cmtQ1BsX4r*|;W6eg>Am0t0}o9m z7E(+^zgpGd6Zw6?=-uS@KpP8mq+Xbi3On?0J!bw8s>uS?U`eG>A&|qN94VH|-62MO z%qGiMB~T#_;tobY6n@_1)DyfMo;EL#ibD`hhA-+1Ld;Su4Y|^SRMP?yAs8cK9-3*o zk>xbpF26KAf69!R%sVB<(wFF#<-k*Jt2Kv9BXCLCBSl5mArEWP+qe=RC%J32!LInI zM<~!0D`nJ|5=BEY%8+cLlw?Ua;K4~!`?7`~l4zjsON-C^!@}}@I5SN5%$pRFF&2^L z?jwKNls4Ub`MGkWN{3naluzM%h?<+_ofEzXq|935+s3<@jpC3v@pSD&r#WSVrJuKB zzC%wfeW*i@99F1`GwPZ>0YS)iL_?l+XUhrlmB4bGg>o8R(2I(tgSKxk;#kEdbFx6Z zJVGEu+kZ)6C~z-Aj<8tj*TcjW7SL5CkObBE=c{gRn~WFF`)pkx+`%C#kiJREE5e?O z-_1)|zDUPK9UmYf{U8y*ytITR7M?W9CQd7wKil9*+)5oubW>|7Xwu2Es)vkY6Sdhb%mU*|&u~QMPiPE;8RLVx}o> z6)HBJLKupqs|3;9n1)~T1m9|5qY=W!*I^ZUy43CG^OjC6z?9U>lE(CE75h-#ma@&#g0cRo7$wImc|o>YGxO=!(4{&50X>90C& zyR&cz9V^sNl&h{Xp_W}MOWGiCk|)in14F`DDZ@UgDZz4%!ZB4Ed&9BD(Y=hzlz}rB zc3m#X-Geg_MY@Sf`GW$>t>d2cld{9yK2O&gHxpy<&{t}N6Qk6XUl1k9S`}JeRxH?y zz0w&)I)|6OXPmln;%~5@>+s`>b#a3EDpiLJcEsM1=Q&q$9R6Fb&TfYPd}JMox;4Wh zt`l&M(ya#@idyRVtmWYMze_Ssziu623*p4n>8>+y2y zQJDQ9XJwi%e|_XFA&c%bWzpn6c<|9{G)dG288mkr5=lZDmGLrhJ9W*K) zu$%Ssd-Xs3W|~9-G`Z}hr;BaVr0HJXc;YQ09NjgXU}x=YaxI+S>O@#39Db7m_awnN zP)$8O6-cQ^`0?V)#v5)~rbPBZLCOlGyVvY|*oTT>= zD{hn9!5r8YZu7u%yr$jUF>`L^ckPUB?(hz>679-mu(Zyzr77k1p7utXaJCz-U5?XV(J)M6ivwt{eEVA3BeL{wWFzFc>Z(7pwY*B7LVk{K5Ki z42tUaI%sE=%xDrPMO{s%(~TZ{NQQ)%3q&Y$<-HGuIfMu5X)1!v7YdWyG^6kOPkF8Q zchQ~A(mpCSq+@Hhp(CcxviVF`e>MD8c*}lqT5r|aU0Q?R{uzU{#(t&v$ES7h;hpybxChb#eA1U9 z^rm87irX_xS%siLdBiGH&Z~Y3cv`(0YUPC?#+O!t(v^mF=^mCTZ(XUZ3f~Mxl5XEn z3M6uH@m-5tg%qrgEbug$`-G+l3=Ow~ zLAV6JPZK*baus>243>SokmZ+M_AjkoHQ`@nk!k7B;jy}yWKHAX0!>yNNTBmLn~QwPM#Z3>L4NXRJ!*z-nk zJWX(TbtCbmYu(EWSHu=u)@J^4(vl&-ZKf{_>VHihI=gz`3V+X(_`#JEmsY#@E^yiU zpHxO{{Tx78|b{$Q}2aBs~Nmq6!eReOUgPr9bcIJC}@=5l3?)ZPmu}2sd@KK&c@7V)e z^SkdWUB!I!NakBqieOlLJ4`CZfb!Ld<`5DKS7E`2N3HEITD`;wNPU+(dx1!LynXd! zy?p!BRll{O-3et-EMXI~D4X)tJV8)1Ie#ai=HNtbo#UJEH(Msc=PUkKKBdHca;_1B zggKpulmh>Pq84dAMS~@PiIH!d-`N4QuCUpot)QyQXl@bbqtBo9+mAj=**>oBBtw2` zX{ObN`P(aqvW8O=q_mXls*8b*lQNDJ#3MHc3BdAVz=z$>jC^mE1(I1?fKTf>Eibgb zLJRf+RIOZ4fOD)uEz6k+<_nas#~6Si~S3u6%aMvc;zL=^iweiCcEPzElU@bf7ZW^DKWJ&Q|(k_ z--IS=pCmto8h_*BRuuoT1B$VaUwEA9`CPC(?8m(XhlyI?fgR@7*$+WK6?6gkq_I4l z|Go=a$Sxj$p$B?|bu_;zngVLCSbyIgk#Z-~P_a4&Bp90<*vLLvXO@&_v31PIm)uX= zxCe^+rlR{8_VkvX0?w#e;?(<0RB^1`Ag7nbLs1iQF<;=fy~o8o(C@9Ur;KgC`!ZWt z`2Tzqs1O+e@fw$=v7a4jpS^gP?10+06r_IAJsAQa+1MDbnDUDWi)Cc;-_FkY&%(AK zlSpMFP{9a*%YRJVb*P4h`2RL>Qx~@F9i7yOZ6|Pss;V2THp zmEjV(-?1BI>l0BCbo{cavSIlo1|PuN8T-& zKX*Ygf0O`1iJJ2w<2Et3rB6D|OLMRN%VVEYWqsosZZ>|3VOvYE#f31f706W_N$u6BrK#R3gM+Yj1&}?8wSOFU3y9jz;&r3v3oryGUsn#js1@+!T^_C2=9M^rlb;G6%_!tN!4aK#E zBcQrHC9B&R6>`P`P}SX$BxKCGXcE}D@cMpB>{M-v>saMny6dHRwOYJN&{P$5C1S!!g|SJMJhR@t=tQ?Chss*_QCYN{@+=rC zp1sj^oTaB@UQQ5^;#`Z0^vqz_IrmZP)%5`xE$RyOUc<%@h30 z^5Cqy)kE*!b}=kaMqX%J{&ueO;UrdJ&~xBW>rJ!jE=Pfx8LDCmJCyDu9jrAFbHgt` zF^c}^8CO8WLz_eIKM9?cXZ6x@tuwOu=?2=*4=x(IAaCx`fW9ekKX>qOaCo|f{)lN^ zmtzPW`TmYga8~cLg5H27k_2~v z(j7KUb6xh*-7XrK;gz>!d&7dqJ&7`r|9#x7q{H53V+x@-?O z-_ZCWCKc~z&b-d0Z^aw&2*I~0sy00eRr#8EZA|tWW)S^2k*kPLurUeURkQvF!8nym zxyqw?hqj3;e?624W>G^P4vexqMAcq25l-NmY-T7m77|mRuR+^+<|rSvrQwr>F1+70 ze267WUjPXS7K*1U>@zw^W(v}_7*Baj=YD%(yC7QIS&kE{JpS<;yDJ@JD zZP>`I&?n}LcfcDnM62)61m&ifd&w*mGg&~hdDi7CA2SAzY3{e@_dRWp)hjDb?ejDc zkFH%R_Mq)=IV#;h!=UYJd#0F#B@(v#t|a;T8J!QvI@|CR&odM!=$4KUQLm6lw#O z{C+nc=d*?;7?^DhH&~wMlQ+p&>X;CO%#0x+8+*xZ1GX+U=Sv-T2A*}%j#eF-zjgk( zD&N2G{o#F7)7hFTR*FRxxEnKmZ4;PXw!wNyXVe=Cv7UQbq5Px6acfWRWfT%YDC$tW zhw|o@a=6!jh*E{LI>XdfCpxTe5u=}-70T#}iZm}x7zhb1KC*C{!L-uUfd@d8*Kl`@KNR}5hQk>5%^5v3Z`3on-h>o9g9v}(AR?Jlnx{pni zamCjx{+?QAstp@zH?v_w4SlBbl=|+#C(=6ZhE1OJfvLwg5la_XW0w}@LoQxXy5w{> zB#QZ3mCQ{?vwc{_YDz|5(cNEBGj>f8<4xI0zXdgO%wMlAH9D*Zr}@9%{C7H)!_M)i zQSk;n&+lcd_XAmQc&@`~?<8egA-H7pk%20vd0{-Pr*7!eg@W4x*Zg{3R9^}RGAoNE zbV7?4uR5RAWe>b%D^?iLY?n2Rah|M;R(Sk8#@Kbt*^m6YwG46P^I*$t#4h9W>zvQ< z{I8ePc}dE<1fws1EC=6TG$cvW+#h?V)A%9D`$~;Yoa+JY(-0Js+oR7aV^Q8VbuMj? z*|%3MuO9!lV*TwO$>W(5tGp>{Y8)jb8_9+^&>ZJ*&25W&z#vAJj&hcW;uD*mGtfN$ z_;ft&`I8=F%V#bGeU(`mh9hK!xYu>pnU9Fa4_wain+KwPrixC4=p5FhW$}F5!f5PU zMq@Ad1vf>vM6UX;R;5VHfxXXulp?P^d!F`6%?IupC_L`*^0VSi%Ek)g*Ei`j^*`Nv zrC8oazA`-ftN5-WX3X`^{a0z;TP>v~AB8?`UAmbA&NQJDHdK2_v!V4fd->8A8M_Qw z5nZtcOLuM&2THK#`e}s)Lb&kBo5VY+AEN#30DFbgj-N*r{=5k?#Sy5_&$+i)uDNWT zZ`l5f-xhI6`z?5~o2yF5=xO2uG=q~(}>vHLCwfz@zk`o+i#4)Yt1RET-ipuVw(=x z;D~I&Wz_z%6VqWf6GiI4*Y3-5_FW+7q))083pGv2`P!Uf2C)3w%}Gy4ltcdzsJa)o}2O>)zX#65t+x;pZgKWXJ5(NHl}-yR1hu8 z5md|P_M?-b$;WnZv?>-r{c@ zxr?mSifkN<>>`UC%8H!&i(FQUTz?hexQpG@iai~Ry(5c#%Zjh}7yGXi2mC6=bC(3E zm4rB!ghiG_l$AvFm&B};#QiEEaF-^kl_oourbd<$%Sto)OaE_(U2gtADR$Y8tlllF z-tVtISgHQ}tNM`p&XL-kW5+u`BJZ4(-I?M>0s_CFG!P&jkY)$i0Cmv+uYKwL|Gf6) z+W(u{7v2B<&%yrdKL=2MUZ7wwfH)(>{|6%Y-vOtr|CyJm0jHAEvT~{jm0C%q&dc=; zjZOc@y!=0v)c*-MjZaKYP0#!v9@N#>Z{Gf29@Oof-Txk!|2ISMF6wvE?|)}!M>K`- zHj)k!I5>ge+ct(1P&d^6OkxEvshs_PI{R`yjO8%vrJnXNd6>xZ2#7<;EI>)|g=;;P zdsdAm`KkiMH!I>|BPr6BFWGq5M9mA0Jwz`%6?o4kssta=?-kU})S7i(e=Aua^`cH% zLon89p>DM0+uh;HhL$k9gLm6&68Qs<>%|+q#mkHm_r?5n1N=(>TovYefQ#@y)QfdZf z>_c(>QaT()FdUb-USDJue^10GOs=~yYDLi7q~uNUaq?nGZ&OWG^NgZ62bw=*YxF2t z>q#;OV^b~-bS-D`uJt*dWos($Z5FUq+hKDbsp{7gMP-W9Sb4%qxeW!hB(_Vxwf693 z{KHDj=Nd97lU(Hm{XQVC=K1YZVQZVcrKM+@gmmTA14n3FgGij!MA5q+a%5p$JCg8e zk&O_5_ZO%}rID?%wlZvgDJNU&x~buD`wvkl*Y-S6!$|QXHMLEgN;vvusLvR<1(Yvo z$v=onWM$*Jd++|(#Hx*X^a^c;Hb?iCpqY@WoG(O$&*`9hIjE?zqXN4rtUJ%RDv1d9 zy79T+L*$}JZ?S*HXNzT zk7z-SvSeFp1ha@|BeJ@HTvfB_L3_V}Qggw0YMaAOhzs@*M8nW``gL}huSslrM#pDA zgjW?af?)H7etRx&&B-&@XJw2wlPp-rPhwQA`nT}r(J$R|)yeJb)6!@S9hO*{c`zjm zmeYku=g1wr^c{6-Z_Zo0FT=U;%q(Cvgmdsm_00<|jn6bcUj6y5Iv_KA?Z@!Yw^4%F zzl)e8&WjSRE~u?+r-uY=)QR#}oRtNa5=C+oB)d{MxB$s@~oG?DsFig}3rb z|9)4FTA@*ExFMTMOr7iRFX8Xk?B@f%m=4oaKWF@Nq{%q0>eTmGEs^D0b=67HQYE#u9v9EYI-b zhFa&C5SmCb7h@Y(n70Nlf#N#j*wRkeY$mL;UfbHX*M@oOfQ?W91W6`v8&fSI;_sl* zHp9^oA1{BYBmbg=VfgCTX^n_vdN>&hJ|?G`qY{~pdY`bL-m{#oq5X}7KAuy%8RxRD z$KQbhu@fn2+QI~mcvXO(7X#8H=G<8m<{TD&kaA33Zc=T#tI0<3P%B)7gw_bM8BN}=2LKbo$HIp7h@_{?u%$15?~#2 zAk-$VP=+8PSww=`sDCS?WHnxFDx0x?kgxalYfj?CN!O6)di{-OxX)TsLjoBs{W5Aw0 zBqV%F2gK4}v2HA?Kos`WbZoIGG3_k+9Z2?C4qj;6QmD^Krdz3`*t~vgV5WGcux}<1 z1uhpjp&oR|jvO+Treeah`dME(^X3oZD5QHx!7q~Q!x zNtgQNh{lda8Q`7+=d8n}#~7Gvp$=`uW+88tPmRm_eI+laS89Hn4}atdYn(3HHzaVF zp`2SF<^3zZ<@t^01VLBQfSHNaA3c!=I;c5yI2#+Yg}3>ReGR&WEI5x4jjzjmGx|_fiFypi_KLM7AgtJJo!DYTe%6*RY z;akiZrSwZLsujlzXRC!*LwUDTA~p!|7Qc&3TNh~{S|UCSPc0ha_Jp5v>p@)!0MrHp zW8nf)(gqDWOff?s+|&s8T!i_{Waqeu{FpLsw6@o!4bLI%U+z3z}HNv?jpw;p< znwcKVRG$h9v8$dLJq9u6da?Z}AteQsfTTDk_CX8Pjn3wlsK>mhV|kj8st=EKrVo9c zwYst_9qqSza`aKCVdlX{H=sx$Sr;DGMsw)!J!*9bZLOT&_g5-=V}0%9ad^y3gMBnM zNK1&^@txdo*G9Ks!ZfJ%2^O2gUHE9Sg0X{X>87iY8G2N*(1GDnE|{AQpyjFkiKs*Y zOwjdBv7J78PZG6K{;|c@Fe`+{YyY`}>GNa5>f78mHDt{(gG@%`##nT+nf0GJc_M~G z6Swno!2(KKS_f^610a}$PBp?IbI-HyLgs&w5+r_>g3<}(ijk8T2}9&skgB{Jc&H-*+?;r(_Ts0Zd$5G2qH@ESqY$SwDhW$P1LnS@5*htsj68Wy zz`E<9b|K+@Jy42I;w@cmalGE1ZM@70-ees-ZVzQ`GN6)AKiO+Ze)ZYIn{gaz!ApEw z1;Z^yA@-OMncb)$c=Xoyyh^24AQ#N4GANpYGT}+Xhn17`N<6`Rmp&YrM6#WAfd=l3&!a|G6 zv=NVk0B&IHS!(8ZygWJuEC=*0dw@|yc2r`2UuI@vV)iaX-G(@Jg1>;zR-^{@$l&K8 z=}v4u3h1yZRg)TaS>|yctHwY84cSo2df%I)?-LTY8~UL!JDn5K>l@&+?Q!S}NhhW} zNWi!_7>tzWY)!-~$_22b8p*7i&y*VJcEPyi_=H%k?!f`c&e)O#g`)^r`aH1n&%B>I z8SN2%51Ko8G(K%*vZAR#$mo{leBX(9-(3@TSnf07TrVX! z)Hv)PM*>fv651R0D%Avq0+dj3GA9m*wg_iVV)~9p!mh_jX|^>@jual2LA>cgG6~;1 zOTkI_C8-t*EqX_?6*ONgfKm)7y|?DYZyS`#dUVE4DV}S*Sb|a1jv*xu*d>T8#_T(Q zuxb!RLZ+oeDWhR2Iz3a06d7r&#n*ah&F&J#KzORmzyDgd zw~}wKj~S~*lV>?52_i^J)Rn8eZxqc4FWPee^%@shtCjMr5eNK0ao+i=$-8hzLfn&cV2^BWrT!yPxivk>}|z(4YR$Qz6Z015R!^aIJ~>V{3`T#52v+Uy8`& zWJz=$6QZa`t!T%wCP{*rx#OWs0{Tl*G)VwLE=4%QdxMy^5>>xZ zb&94JW;~P_n!}uuBstJNhQI3AN^1y_HG6wFT{JZLq+AyRf%W4#2nnIdF~S3d0vBBi z)!b%&fgDVMr@L7$^mg?V8g}fxWk4&NHqAw( z5nm&3iZ?}?=2woeC{W)mZRM5f71fgUoHIa@1F=sW5Zye3D7C=^b4wj{yroEa89tf$ zKG7uzU1!dFigNe5!z&+~29nE-yu1qj9bQJ|fu_n$YwR&RdX~rF){Mk*)N0-%xK9wz z-M-!EuKfff?;?eD=W~YW-qaGU)Xc=)_Ke;Ld31$uU#O9Cb`q_>L{#(K9>fDh`lpTp zWhy-uR#q{s3)quqj7qz-+P0jLQ_z^b*Bl{<0_}T&BuH-jrz}5)&^i~)aOs#xJn+9OhGvAkmC-Z#+`{5IOy9^J4>EYq z#0aw*MRY$jx7KYb!9W9aT9@>l+>bKAn9ZVv@SSD;V*@arI(+=|{(mg=n!1h?Gg^_#r>o6O&#E%8!0Px;!PJdCl zw`i%&@2X_K>bK{LB2}u5C}+thcg-2F(7-StcHOx-vEb?{Bf62$Gg|OtNpYSIcOm5b zi`PbKa!@rawB814;{p{?viap{%DM#n2PJtpjwPA8ez%2Ffsj;{%po{Wb<}9J^%iaE z+i2(oayOe{OmkNe$9mi!4i0Y}rf1P$Q!nr%cY(S+6*zo4E@KO|sDuhtJPRnUHMJ(ob&&7mUHI5`Gid~p z#M|or!t2?@3-ehRUt3YhPKV*h80Td+n-3R;GzELNA@bOU(w7~__il7e0unZ|x8 z-_h4+;W#M}n|R3WOQW4{T20nx^eEsUj5trjjFPQ$Us0{LgjbQmIbQ47sNu->x#VQQ zsn^Z&Q!%DwcX0d74qo^?>#_9%vjOgN3=b zncs~8r;Fr9UZj==XIj{_W(p{E$XhX*l(%S)m+;|x9-a5bEMl>cAANd%nz}Lixn>z= zRR0L;OomZ-_D`wV{at)pOvM2F!8;|;%+(nb`&*(q)b-GlAA9}Y1Z;^*?oDj&+g!xV zvDBSk7bWV>%fB_sL%QaD)caeO$`1jU?oK$iE<*?|Q6U_n&!;Mg1E=LSQF}$s9d7s7Mq5v9&+C+IZj*YPRIaTQN`W1b0N>>7!)FU9HEFQQ*jpNtbN)Qe- z#F_e3u@G04*XVliXN@igDWYA-wqo)6>{3{2)))m2u(+BcG^8FdGl+|_`G@RR7wpUA zH@>`^v*q&*VGp2jAbOd?5TC+iuIRabSjJPT_zf&U0yx@^WVBy1w}B-I(9aqGCKs|* z?Yjv6^q_|N2_s|dFK{QV^NtnoGt5mhH>H=v{nsa-8l>XbQD?f|)#j)6A1Xdeesz=0 ze!0xV@x^%#=w*~V{_s79@|1&gMCBkm;>_(!w!cHA-xbG3UHzF{8wTMlpYqrV+;~e~ z|CuQIRNFCF|EhOBe~8cWM%MVVvIpaC9Opa0AS#IJ+De^pjgPM2(+Q5VhkQ=*hDeppEVHXVEIj*Ne}5DD?tBR|AJN>A z$`c+nZrVm5!L+I_DJ}qjN)cjD;6_lWaCXwt-h0*F2tCZN0qh!Bod03 zp@gyW-W{sE<$o`1`@6e|our3F{4Ent=gvq(S}KWfap~ovuA=!R=zli0P-#5_>PzRp zbuuaGsPSjtY5)%K5(Hts@%P`_CAiCmZWbNFFsHDx)ALIH05dOROYIKLJW`C_!ZO!~ zo*>1NS2?whyiht_Aa22;HqYd$l;8+gDEmwikR&b0rDm0Q(OWMq65UaGnq^jPReZ#Iy^(f>CeP|l zk@)#3py9#&YXdM2syva#_r~S?8Tz%R`2dVQvbnSGi1sXc3DkR#S5GMN^#dtMj2%NsP%3 zZU(CL_+;AFlr%D(5j~bq^^#o82uKihH0@OCXJ}{TQ=?}B8C>dRgkcT2y+CkbHxU$? z-m>B*&9lk%62{Lx&#aqA3`PzRZ)MI8%pX>W z7#ITC=AkNYe1DRI8XoB5E)YqLJbiXYY7i|BksQN|t3pn2pzB%S?X@}vUbVdrQ@8ztlK;ikTZT3H zK5pFi8b&y}adhM8#?c`$y8Vuj21mD!4vEo7IXXm2Qbk9%4haKepa^22pdtp(e$W3n zo)^#Cz1)uDzIUD1d44_>Bx+h}8V#^*8$$YfnJ#)KF<6zq9hba-YJa{zy2=*9F;cEs ztN_r#f5zQuqL_5`2eGS@Ol*FAudY4mj3hM`2F^4aE?q3?V)s*WdoLkw9#WI~mjPo? z`^>p&E>Fb!g&>0Wx^l2dR##$o?)${Wz>W-s)qr~lsB9qf?sYL#M@gX&z{=T!#1Gegwjt ze3J|o1UcS^VwBRMG9RtfEOK6GdBKCxE4*q-OMr%^{sQLv%jn{;1yk7>jNN=?re>C^8w6A8=R*Hm4$3HM^oUw{L`oPdsPXyS+?%HHFEV?b?+Ik-2`g zOEAia-EZ-2%6jAee!lEQi)&oruYT>SZ?}uR0R19lz?7RQ2&675Lwmn<=M@_d2QA9U zx#=uFj$0aiPG3Pj?nQq6R=?Y$gQ-)P>yuEH3YnboaS*cJrH6+znDBey8M9+=TCEV8 z$%WVGtRIc;8t75oNIa`Bgy*90og!0TG6ct8KtXoCg-Jd4%C1d{E&2hFu5Jxc4T7ainqfnLR))@1_2g zX%@+QSU^RSK8vK?XTR?oCpE|FWfPyq>HIe2oa#KrxJ)5d;Zauf)&#F8Fm`}J!byX%Op&@VE!J37f-82{7g7DJySz<*)H@8;u508b0e9GD88jyt% z1FM3szjnXWGA~%~n`MQ4PfKD{{%>6Qzp?IdB9Hh!G8y~ww_`+RkfRZ7^$;PMG(`ku zd}YuVq-&`$>3Sqo*{R}|t9SQ%woK!R(78U?Kl{;ZkzO2l%{^RIaCw#f(qknqLMt?x zTyW&|4fgt3OM#(OsuHv#-vNX@>xgGDkyQ!*FWH~DS!;QNnV15=Bv>AFDBm4fl-L%R zI`{a}s4)nm$pn`L)pBR{K+3m@@36K6Fr)#jBu}UGq_zr-QFNWjdH|;=Nfh}f?5;y4r zTrCg-8C+O!`jRc}*V@0j1Bk<4V<#1l{;uFby}#)^tRIQsGtziwx4;gTi-%x3?OmMt z1jQIZ$u{&7tB?Bq(D#jub?91twAQ?v$l<~TP#3XBh6vz)XXMB&QTV&Q&$E#TYeCvS z)Y91vL$>oWu6^gMX$&=W;@ffa3LTWp#hC8F=PKut+Kt%~KW$hT*JhxP91R6A=JY;&Uz>8R@ zDP2d1w=1t(K%RS^-=20`Y=;XTxFSbSNNGsPsujckC`Bhf(qZ@#C`=cg3gTbArSd$i z;1u~=D?r;Z`sWcLW-}J}rF}fU-ri!P@aN@5F4}AzyRBNpFlV4QBz22XDK~&}pQ&v` zG%&gEi>{v~@9Z)6jFGT;j5HK9P=Woyj9{8$-@M7@XY4s*$ehPJQ&~7#8gMbF;DmYP z^}i-F1ZA78NORfvJCbC$cj!}aoW|owTS#;=fU@?&m{ckeZWu}MfDXNySv5tfduKN; zy)1S#zI>T=nn77~H-NlSV07p3><^dHWub8dgd+aJ9re~>$(YOI*rxR+(>9-Z>0>>m zvuZ5KP?2bp2~eKu=wHt%v5P-19%RKa8|&?Zs!rDY^(Q(NsQN17i(u%O9dp-(Qx>%% z-m_fj-tJWBM?B9&aIckhhvoP)ob>N|`sGiG_D*j8h9_7fT|qG|3FapHvA}?ETyBjn zBs=k8{raj!carjUwStPe)m*~43w7ou@bFYC$MLa1$<%}iTB&+2+gNzmebl+=mKz~^ z0Ew2aaPVmBV9{LQQNo173XCq5KGxlq0L}grr+R&jw>ZRu^zFqa9A?b?e4l&+rN`44 z@b5R{Gi)&e5j(fle@a{~jH>%m+m}~HOuVBj%IP?|q53GijYnsyxf=^sdkQ|o+cWN5 zwp}Bb#-uYlo7sD~R|!%e)y zqDwH0sEz&0i-mGh5^_Dg8LzGlvW+Wz=Y5I>SDj5~e*Pr+tB9!IJ-YYId1|7o{M8Xl zk$FBjMQr48Wh_?lJ%X9KnbEU6Z}V#GS9{UYQv(4zC&{P*ZnqO+vgbI|oNg$l5|)V& zB++VG0|Hf-Hp_s{#y~lGVKP+xjmIg)Q%c3Ch#4Yt(HqB3LPXmxGopd_BahCd0Alb@ z2|7>32+LC9pAKm=H#&+R2uN2gi3`5XCHOA9FP$*FYt)sEJ%^TG92Dv-_Pea%FTVq! z=f%&Zz(r-+!h0#?eso-FG*l_VzC~F|(}rInc8LOFrKC|EPPOM%HRZA39)yBgj`3x) zprC8%SK|@@tE>^l4@}x1BQUEl#g&Aw89Be(&oSdN|Nc<)q##@w^dIF|=b>b;`|!F&8H&zHyOujOx^i>_ zFiDK3pgNlW8J86R^`Fk8%XNE{!oN;g*adp25K<6$P^$z;?m(+2CsGfTuhel4jEjkN z$Ul3DC`!VaPhg(oZHP>vvH1r#Jqg2k=#>pM0W#X$e{m$riebxH8a`xF!gZiZ^2>tZ-i zD)dnBD(v(eovA5Qkx(;UUx9}45J2Zi06(csi|QZNuL(GnnO;w8-vz-jj0%8lkXT{* zq&Kf72#y7_zA3g+mPAi93=qNGXpqt+*Uew55G*7eZ<>RKpbzS+pHw)CVG(#Bp%cVN z0z_!_f44yoeIe%n=!M&jEHtp~0kr4jW=|r>*H2^KK#uvCmDpL3M{M$>Gvp)Mbq%CD zs&W|1R9=Jr=PzBh53D3H)*J|Qp~UR9g|%F|-vxK?PqL_{gZZc#aU5cB>PYcw|>kHALIt3@aI3pL6l&_0t=AFu)Z@ z4{vViq!uRy5O*8EicS!uEI5Hmn&p#Z{)%E7ZwS2uQ{sqL*14@Jmzt__x#68_VY#_e zAYDC6n&rn;@q>FhL99v8`IZ*VUYHqnfZ1cf;GiB(Y{oaD;0K{T8MlmU+T!jz07FPHEPt)^T0p0f>sJ!6$)6+{eQO#NVyn@cQmoESs>e=FI?)Hcy2M60hY7J%=VO*%Df7KFACb!I(KD3gs_LyTJQ`zVjtcAEq-P!(E#Ni>p*#XA0o7(1DZ}bL6;8Q1 z?m3`EwN1!hn(qRkG4R)Xr??*nqZ#+8OI=EII4&z01xuV-vlIYcSmB#5Z|CcM5YTe$ z>I#5BJ}uSUf3JS@$3%72UJkWrDvrO`VlF26pxs>_T*_BdEbypAri?&!L_xQcpjwpK zD8UtuFpd-*P&)H6JoH9E37_-_d6Ho100`yvb|JSv`GsTOZhk=1$IBYbkmJE=9T8}) zDx^jgk}~6(W0u_XBQNZ5FlR;jKt#rbMRLp&N~xtrdCppwcgkQuaVJzb3iR(OTa+s1 zsvZ@76ZM#V-g#l+1xi~V+axX~C@0izuqo(?2cZun+H2|K^woQp@LCr##GMJ9vu*z* z&j2hk6+%z{+dc)~e|eK}d9t}iiT(^g)7ESkCw&iA6Am9SG;H4eRLw$!TQxna(c_y- zg68>cauqYYi`?i2XRVJziY^S6Qft<57mPBDpW%JL2O3v@#+A5$-iy3S@j{I*^S!5R zKHA=-JIh6tMA|Jx_R0gf>z2;rXQ6hI=f&2f1zwKYL9;J3JkjH`LVJJTTYXulam@H? z>t%9hFxUx4ZV#;>t$X;(ye{VPdB&xaRr~Nu+G`tBlS9z(ABFVCpTs{>S(_TpF5lAl zE8?m}TA~EEemanbAJXm!PE?SgA2A?`TNT$o7J^PrdOx_W3HfmEuJC=!bCZbIAlO;2 zY=*WA;xnh)DslcMdueL&ow4-WH9S~^(v$yUPPnB1(S-cmGw~neZ?K2EJRmR+7M5{w zFXQv(Q+XM4L#h-RT|#Co%HX)EyW_~3{KXMuPCFOZA?x{hD<1wP#~@Y~13jApK9cfb zMwh%F^1Ive?keI*vO*{1E##5z)R_COM*T7)htj=QAK22H7wyAFKUZ7Zb?D+j7>oCg z4*>-=pLiE-84{@O^ZRb_ekhw5I}wT{^*fQESD##aJ+r?7^BJsr{4~Sfs^CQr@~R(_nw;Do1)3m*&%!xeGRuA6%({V(F@8Si^NWke0S*>F7^#p!KytQi4e zAzssMUYRif?3`Krgy(dM3j+o^%gA`^_~3TRcAvu&t!3|qY9CD$pb$e7ICJMb0H#AD zp}v@&N{oBauD1{Cdof;~SJ?Lrt{VYUQ{rns00<5Z4iM*_i z%->I7?}OK$G0d3VOL>Z~ga}B?QbyzQ1Ix$nM7QO9_(?>|Ol~U{F02 zp?{5+2N0OIMOW{B3psC6;T~e-Sh*W^2s>QJ;JOrWbmnUI1qsm5)!!{F44!G}>6)T$ zY;>)Ql980<+2RrwDHFIPyS|wk2e)#vE?w81@xO{~2B6vHsVgli47x2WoGhA6#|7TI z$M}Fk;kSjGv8Q-8cPyp@4;vq?G1$U{(SaG1kDLIjAa3h` zfS+bEtYAwP&s3Z=V^c4!OJ5R-s&>yzzsA7l(e0;2pyjMI8E5muyeZg1CWHE; z#|NLlISdGU&DHtA+I$9hd!oPvXCo8`!uZGvmWpWP`LN-H7dMzFjz8T0w0ZL~(Tk`A zmG%?|48}p3e{CppBYnOz0>k@%%)R*vIn5lQrWhAus;rdFy+2fPDg-H5ALI2Y-wes* zM&F#}JJqJVlngYa>x6Fxyi*$4xO04^5 ztcvo>^4Yi^J&?YmV>`-L$mgMw{ltHl#TMWEKK^3HeLA4)RL}Oe!{;HJKC|CsD1t(U zNi>XdRtL5fkeJPu8@BTqQv5{5!zR241`Gy&(A#H>Gf)%ia3XON6!VLgetGCRevM0* zOfgdKqM_X~g$kmf47TP{&2Aj#=t*fI5YeQVkif$Oq2)?VFK$wL@C8x8fADrdkhmG*Fx`x_uGEDs? zVb87n`ewv1nMxMDcKu#pW!SJaFv+b9MT5`8(nugVop0?(Xo@*0-PJG=!YZj;7VL(E zX$Q%bfird|K@Q3dF8X>HrB-~J6WZAFR3=4>h+6zV$qM1!z?$|zvCtp7M*#vzG6G1| zuhFZjVwwlz>F4y~({8XEt_nh>9Rsio_XnP{G)cT8ZHM2tz-)#JR8w=A)i$OUM$!}y zm&S#y2&rQ~*>5)>v?EOxxb#(nZr%d*wdVqk`|A*hJXm#-EiXAYRNH4}x3YMBCfVPQ z5weeksMW9s(uL{RRF2(7Ig7x=D+G7*ep$gD#v{WQ`;LsL2!lM1gU!oO{baUrHa7}- zRY5~Ly;pSwng^pxWq@>$LGOMvSj1B_6{hP)@q~*CDoxHL-xebxV}!7;m=Nf`SIiG% zheHi&t>@jacUwsY@Ke-W=;)QyM({X;)Z5~ysJH(FkLrutf2VSsiqu7`0HNN7o0n%F z?&WHk2M=C8eJ*i8=OEI@z9YoN$%7usgc(xVl`svRFvvgGjOH|XqssjT=wX)l`BI}> z>MS8L`J;@ezvXP?j6_ng!~K<=kG^HC4_Rxew>mmP)eJ|Ot1l*|TN-P66SFYmuov8S z!FfB31Dh^(Cp+hef8POaIW(vw?>Ijy(+EC7VXgg{(ebQX+O3y}7{T?`=A=bR%wo_eQzVrn#2Z@k5!nR=y^4~8&3xc#U2VRUN) z_U@2qo)VFKN_3THazf>ZZZ@!KE^7o;1Yw{wFs}lv9=B zDPZ-&<)aV;3IgQ+wXDErtw~q4wsqvO%;YZ=Kc5p8l@E&7SXkLF5gD?pEjXjho1P_# z=g~_eo68bjoc*;?Pjn=sXDqJ+tjfSMD**O%>yen8)I6G+P4tCcdI1%%&`5jhut*Iy? zP!qYd^45GO&$Sr~T5zzu9K2d1R)tQ_J23^f((m6ei$#lm!1f4q`B=QUTA$tt>>sto z8bmf#H2KM(NeK32w3_I$-#IOp8d7T(2FuC&NR8C^r^WDC` z2@lj4a%!@4;gekvI0{KfuVLx5DzMKfE&6d0J^539+ZEh?4XiHX9$pgb{zVLmc$lfO z@!Taqdd|?5*sv*uYiJpS5yC&^O?$6>zJ?%lInI33}Bi#NxSS8!j8T+yS)uTSvoG)q)$-h)y$GrS`zk8X8sN&uZJ^ESJ z^SqkUX^Iv`H1P-+y4Va}3=aj;R2ht1LdC_e zlLXJ__vKsP%wwa*4Qjyao_1x63s3nZ#4B82{a9kqaUdElz>mMIce}V${41Txe`QG{W@a>|LG7Vr zG`s^iuzefm&CJ2u4*gNH`}wmQk+d^iZ-92=;+vc#)gNVF5h!QVYcPIL5bMZJ#8vHo zfBy7yM9)|VU}-{LJa^#Ry+L0FNF$;JA})7|O!^yQiQopiiJRV^ifc>2Fd!3D{C6k) z)}?)hoBJ{9X(YU8hARY(=?v3`ih_-tX{gFNc;`yC+&$k_2=M}pmDI)HCj$6)qdK3Y z6gz!je${yW?ATzCo+4QxVYH&)TF!Nu)?{;tmL>%d`^R$1#g{B^3#39NN$F^L%S~O| zlTB4Tk%9O}O1yBExrz&9n&tUcOiIhdN`J%o1`(`i+9;ivmIgTLs=Iy|w!8VKtR0j0 zegk&`vqBy885aqdyWDvdR1G;BDq`k&K;iazQ==5>bj$6@399G5tw#0?$h(JRt$Dza zy71!l(ju+A=+(SpEc#{XHq}(@HzG7|?kg1t+%+E&J z(9+PbOf4lO-CwK7epRC?6YCFjPGl;74>bnDB7DJ`=2=-eELQYh2ns0|7yQ08?X^^P z8`e4MlJWCd=9_4+FHsFaGDu{w&2>FZOw7im1v-3-%W0pB7M{&1XwR~2kGC4(5G2~S zywS2K10%4II`eZ^Mxu?S^DL!A(=_Ago7JrLydY4zm{U>+!?ib$+59d!M{wC!1tO3b zQ#3jYl}*qG@-58rBq!iJ)ZDSae9PHrfp1rjTA4SYxo6m}^_w%caAYGVVcaxGbY*({ z_t21Dc>mG09bQ{;dr?Lh0Tfh79u6?WDi!SI^z7yDJV`5`Qz$WK{mB5fzFjo9iV(&i zqUf&_I!TRI@LH2J<4s~n$VXZP%gq*glKekcv2l$uGinyCwIgqFfUuFI0w0GNEGGvI zBmf|IjY=$bT^NUx4dYM4vU8$h?9y1YM3xzf?WC_nsTJS?S?|u2>OFJx9#9LQD`^g3 z^!=)+J&Pq@ngI>}yrsw>r_eMq!`zkVjwpIATBM$9k%hYI$tN@$;AOTI5rKiLQqmtk zxf;QfW;KYdWEa%x#fvahBGHwarj_EANnU+g5o$%1#;o-2Aauqfx!s#{1I~@BN@27W zA#$6xT~)gTUZmo&x4rV z$PgqJG97>FGS=d0lbW-I&3T+1C5eS=6B)j^dCMKx{LUuqtCflrXE`tyFGw?>D4?(D z^(<6QFyiVwUln&RC<%K5>=LTHEr1ne*1|hx1}6TqfD2F&9x7zBVp#N(I#=;%cFc91 zahO;yc@rW1=2=ZxppqvEVJi-|?+vs5Ss%Ls7r-D)zbAa13KOZW_4vi|Aht2l#X%BP z0ear3$PY@v!Fz6BtwL4$N;Jr7Bn9)9ei^Yiqs>sGaz)Vq7T*FoX|1bwf(ww^f{7(= z{@h538h%L-*`g&axMi0C>_KXaBGoC%3IyX2ClXDUSFhS$w`O||)LGcP|3M0Ex7D3E zWlJF1yUg1+sk1gtWwS%96fba^03SXvu(DjGMOk<)Qfs;;TZ|8Hj80}t=1f{MmJL>#A=^=2Lq+#DS zQ4@Tpm9CND1Yk{;F1JtAMd+^RUXUL##Dxq<;JbyB;O9$3`TU}vRsbO#et!(B5p-+& zX21NR=(p^`+>W?|VZ^&T?I)JrF(PFGC^BzOV{%oY-W#AJCby(AgGu0&?R{2O={PLJ z*Q2TLmfI1;gW8j@kJ#Dod#4STq`;}^0ws?*Zyg!rn^enhf&y!Xf;}K9$1KV1QLU9x zvccV9IEdDw021GQ!=g^L8YX?vDo%qQ&WLr-b?EQcWH13E6@Vj#pS{KePVIBo85N+y z&G3N41YGFpIjf3>8XP28;7;&eFb5GK9?UrtbVIAHS-7UN-_GlHF)WER=o19K@+`#n zPR>^&aOmUKWg3a)PVWw*c6X_xZSQqOk-_9Pc-hTCZDPd(wYaHHZ?fE-jcY^fBrs>M z!8QBFu%tqXg*(Db2)|y~D7REF&?S6#_>Y9>+Pl#B%!ZZz)4OBWT7#+w0(~mI=!Z>; z>Ns^|?)S(561=^6Pn+Bcrwt13)vw-VeDa$y}DGEoaewPb?#6LK`8*{SAg(6;ie#~S`gTFWIw21<_VTQ{tz};}< zi%FnRg5YWraOMw1jy9|q5VnOMkEF|6sP~*}+rkK`ad^?xxoOcCF7(}%tUZ)@TkFQ^ z*^=Unae+zY+>sI~Fz~?_ck`Ci#}LV0SQvFYp%dbV2bq>bwvR=$c1Qj1PHij>xzWWc zbgd2k&I4jCyfZGK7?zkk?S2;~)1rl2_d?U6#U zCHJXXQ3?6pC2y_>AJ8R2$U4DMFkV#3UVN%^Dog%O>|G-!+!7NW_Tp~!9YUftPen!7 zAZtvMca^qpnzn3Hq9`Oc=E~+m}Se=TB{#74}DW9eoeRmk)yS4H;eMQ*X@M&qqjM?Mg zllJGyu#0L@?AC>JkB5!hr{VcSaH5E@**gykkV6Fo{3Y zeNF4dRKSGDC~kiJ#qdnN!ov$6?!LB%ocF+%>8Y|OO^Ahx#$l=h4XpUNmwtru&@a4x z={{Ha1PDM`Q6ommRL(OFr-k=1K2ZBtdG|J6Qp4^>!Y=h9=(jEbWO%}W+#&dd@z}gT zV0(t%?5r15zCTY5^6-(Ddrc=l*qlW~$o8Mpvqn3YC5;J2SSp4nvTo-^5xgVs(KVz5 zNKZwYcCs z>G8Nw80&H}vtr+UtJdh|UJiW~u2-#%^gAWudb{zn3op04SY{lzLT~1BB?IR`c+fh< z)z{e64Fjs3KuGrj#;k8tyq>@KP!H;zQ{(~O)g+Yucrw?5b)8i6plv7JfAnJ0tHeYN zuam0MO-1TGz2bJdQ;dayL#(@8&tKDH6Yt&Wuv)*TD!u7lb+vuHaRpGs>7a2r7>Q`7 zpWFHJ;JH=Ay>8%s6jQ>(-HH3a{+RSMt)=Kba3}meegM2&AM3#(g`{m`J_BdQJhaU7 zS_0Q3ba%$_FAn$M28JCol#;6U8BV+X)+=m+w-&g&Ig+$MhixEx92CU_qgU*q6;b^l z$awftE9N7(XM=(%6#n_;hc)*BSFnn+_&LRo9~$urLdaWX#}kTz#)Z1~2#^7-@q2l5O1aZb$BYod37 z6$LK(+uKhDkI;Gj<3#?=o@-3_`JZ|>O!)U)gifgnJ0p@|t72EPFni0n8ZPcP9`JtZ z&@!+zs$6|-(==o^7Ul3Wd{LJpV$KKLcRAiClAYwFy`>kk5It{(05JQ_V4 z@kHp9(x=;Jpz+NGwNIYRXZLoNIrmq9g#krB;Q*fhv%Ub*2!sLS|5;!7wIt~>_c|dp zHl(L?1)~;%E`H$pSxOndyy6<^7$S(Y;M_^x37lKy**r zqZ`=G6|syW$qZA3VO6bv@Pt7|U7=w6ao)rL(_Kd)91+}nI@iO(k%3)j>Usua6;{;y zkzr|B{-_;TBN+HVnSKWDJ3+&1+3Tdzkiu3~FL6dDhg&2z(A0xLFo!4bl~cBjpWScD zaO>c4CgX;`K%lRilTdC^*6nI|{rnz!x#paJo zUG+1YF?4ea5l92U-{M=!dHr+ppic<#*P)!FLwv%)UXcsIY|`TC3`!5vz-;`&wA8Aw z3FUl=d1+s<6bxfrX26e>DB^5>S&MBCC?N@J<>=)Gi_rmut^^bA?cCX& zwwqzwm&`CEcz)b8wWYxkQ3a&)g>L*pBDI?PYq~^cvLAa8U%J+&=ybOjFq~MB0oDtm zmZc(e4&Z+_MW(W0k)^^VT^cAF`IC=C?EbCzi$3ZGND(c<5*8jRbMYqnEja_iIdu(e z^m!bA6W0Gwpa;UL*#Nzf@*FOm4E7#8eU3!VHGjOk^zQ2i#uXbmCGS%EeF4^FzrN?g zb^cE*Sj@=nKBH3uoM|A*d(eH512FVfAJ(l;#pgti5hc^qWtzH47; zlvQ^{)~U>i+iu!MY4=tf#OCPbFt>k|9hTM6{(T1Z?~k##6*G;`$2~^|-KwiLMbgFb za(~QYt^$78@!MKq3W>ONXfSvJiYBIh@r>1=sgd~-9qPdXv&<4x9|;F} z|9v9IDW)gv16uKEj5GMYkIPUnYZRPO^v4)GvPFZ(m)QhNMethDGF^z{+?*t^KISdz zS0sf)QkrzO`C6Q(!FY@E&V)Se5u3SR9h(#Z#&pyG$S`1ELtP|fTss(C9n&~|%$Ph7 zVGY!bD*Yp^Ss?X?>L58nIbT)9bLL^Q8(A)!arY@JP+$v1W%4LlBgzGoVaB|=<%XBghkEk>h!46fx8&){+O4p~r`!R<7zrFLaSHHQ@P zJ|}ydmUU3S972S_kUK%Mp0nT19f3IQKOc#vDm;f8qny5zn-S~WO=YjOtL4&)!boD#d%Aemy%ne z+QX;Txt1=Sr}gnRN5y%Tq_oLSy5kK1yV`6cBuStjwE4_enyJu3T@Wn1(VpYqrSn`xVltpImjEbVdYPo7mByhV1#; z0glg1FBI3Dz3vL(UH_%%|1h;GInL^@F_nfL}levMxs$W`k zY_!bew~#XMg{MeRhVh2x1UC(7zSiC^VSv4^asir#e&LMX*fM|v6o@`Og7%nGWHF(n zhi0x-h|RUE2%>7s3S*mFFJ zltbe2qJ7qslzyEe)Fn*Tk5|LvHjp!mYkT+?Hm$}!x3OK^AE40x43!rOs!dg%zA@J| zsQ96mX2&EYVcooql-Ub62T?$XsR$`CTvecT*I;)-uZE3%=4VfhdH#Q2xqelZqm%|^ z)Ev$s*dm{oN|9$G*o{R!l~ZBI*wyKo%h$mX0t{;{$Q4g-FsNfOSPCc6;<$|viT7BL zq@^yuf&gOZ_meiX42+bIxu2qn?yBsT+>3$hxwQbZd~c>cuD?W?1d{kPeA-d=Rn(e4 z1y^5ZTJTQ&SKrZXQz$EtKFs}`8c!XN^Qr{{@f0XY)AWw;5fu1uBJ4@=cu8VuHcH?V zgmZ6Sbfz{qC`Dtsq9k?ZN2NYK%J|ZE_)ys<*Me^iR4(OyJGLHByOhlwtMu?mi#!HY zp0LmFOY3#Njeqa+2i-e4V+&>`!Psa`s4WSD;)N}MwfAUMB0R47)fgu1Qz#5rn@Wr| zI}H56TEo{yEBnKuH|KxE&tH+s5_ID3PD7O^)82B~S7>weIfI(t9|TF^B2v#RLX-EF z6&CfrozcWY_urW&EZ_Vl7Qw})i5=&y=z56uBocTN*~{MP$H|;JS@iC6j`%%pk6UP5 z+G0JA<(|PB>F3avjn6ILGsb)I1tPEZ4&5f-_RLwVcZS2`U&(f)viM~V>zm1a*BMqS z>o?l}_>L47Q>{?RJq@gnI-N<-6 z^k6SqnMLFEd6n1iZ=au)EJ_=QypB*&rysgJoY&(%zJ(wGp8_!z!2^~P<1<@QGW5=8 zd`8&UwzzvzQFdSvI&^cd^2&98;K_>B$*zJLkH#Wb@|jDg#&7IAPGVBnyn(ACk@PvC zdO1@sTlpMFAkN;1%B zMtj5Tvzj8dWNRIm;|tCtV`^AJX3*uI4ykIcud=S#5;QK-pqx~qo+gJ$pS0g@)@*TZ zj^PzFEyGrt(H7vRHn_A=&#Xnbv@o2_jfu$>D}^QpPb zo8o%ygQMI(0^>RXu*LC!0`jSW`TS_uR^KUt+@3{A4W=CDKG{1v#ar<8>-kZhvuGN` z`5ObRs?bnV=z6dFIz0OtA-MKw)}||O8eof}BBrGa+6Y%%44n9s3->iiP}FGoZ*yx#(z*lrEC* zSX%TuFn@68vSI{uzP-38(+?yrVV@SjCnLWTE%IpxB0T}|n7-!Kk}f;1CK<%Z&RB4V zRy2d*X2+GP^GR=rum#gqFj)8{0_@Y{Qk20pW1!4}7bHpHdfA@)Op~*&s_guDiNX^E z2R6@^fiTp@k8>+O1_^gZ1DAl){|RUaG!UH}R6d!Lsp(jaw!-&&8#5Lw%vXfHub@G$ zPd-IFg%{kgi-~Wv5ihAsOi&!{Q>uT=q>ZYgrCt>7XLMK-b~q8Wg6OF+vXZS zI22RurrmT03m3+A_#VQj^9@l{@(ds2tVJcdw=Fr3K~na53x9sw0#7nk7R=~mOKFno zYwvMC&B#4zzl}uDLw+IewAT3s0Ro(EeV)DE8d#lEj_Rsk5Pw$1lZEU0FR|-JRaaXU z_}ggbG~PxMxaH#1ZA`3<3+(A>HxTHg+vENBq5uyjY>)OoS-54BvZVW(7K)8O$om~qU=O} zzQf(xDmt71KlsWWkpw7{2U@#oT1BWmpW~3pB#?AK<51E?z9h4R0Xt#7tL%o*YDthj zB@_;48pdMIm;EQ~K^oxIyI}|6#=@g;2m*j`?|`!m+l4$IO!pYeT+A>-gZXG9FE_(O zKBNN}`1?&mCom)H58lN1`=(W}6l`FyimCn(lOpc}{@LOeM-DHHPsiW-A^G~v3!54L zNRDl)jvWMbU&&!%ly7GW^?9wMFN48vj>2q}B~o`B@~)flh1P|NI)p;5&1WK^RZ-u5 zo~e?|j5M>px~_PRm+!KRX51`XbFsav=Js?4qcqX}&h<&{IIG@h)z#s zG8%Oj?!sg+e#&4yzj@{Dlj2l+k#L^4Zi^`Pa%6Wrb0GgrzSU$YhTDw@^Ut5z%D$V2 zvU*C6w`c=O#4S|b`Uh-{_cwreh6C;W0Upf#H5m~H`Lz4aX%74vstKXD7UtGBdmg1T zj^SqpFU%hs4~b4gyl=z$i43uXCDX)ce}j8d>OxnC-0zm3F0ip*JH_O92-@`uF8W5X z*lIJ{UKmsUc&7qas7zVB?-^T>Jf8wMWDL1R3rH`!PW5i+IDs8q3?=#<=bm*f_vx1Z zQ|}Jqr*72r-yu-$y;$6}GHXYGbPwz?D3=TJ0?3(6-a9x!-xcOep|0C2YM9wS%y%Td z-W08q)uJ+a5~vJyREeXeYu*{kc;PK$Ouz(FCO(5{p|l z_`3=IPrgvZ-=~6LBs&$+Cvr8Q(J7a0AX(4Mv(x!gxvPnkZ)^%PVS3d6AV;N5a}O4_-WIrQ{hgN=?xh5KQu@UCUbKoVgo5}x$gUp+0ADP(*};oPVd`=u znCBMPr@INh5u&;z`D4=Nrh@jhyTM1*IxU>IZ9n!#`ZGm{Nt6t*41+I!dZiVH%9wBu z5oK!cvuvA_cq&vBQ1ke2LEp=Q*boWYxAjxW?_-=>5puUNNcm_Xxr6Pl!&mH|tq|B6 z^|kRjCcX_l(63v$fBtT9ym>OY2TB+a*dALV*)??n5M4A59U)T(O(1{U{+q7l7#?-1 zV)3PE={D|Z5zJG6`}UM+L`GLA2B-ialf!jk2_L zV*jBfyeIVGzw!5%3z0%fL(GS7MhZ{SI$iQX!?6#ckWcw?Fnu0AePQcMA4Ma!;jFte z_G|i|KRyaa&o8x%i9j?4Lp{i|F^xuApYL8rX^=mC67^PuKeQU^hrJEw9KQ0o!VA%@G^O)>iF z08jf={F7-y4|5G39K$@SQnr8U?0Vk8{roamU3lAn{!seIV;}z1-lnZkq$Wmv%(w|BXenLN^&U`&nsLSN(X2ym{5oH=V9ldk+-d*Vj(wzUZzD%*TJe!Y24#{L(L2)edul74iYAM{ZO!b)Z zbuzaIZIs9Po()+h8Yug&0h0z9ii6&|v^i5yw_Kwcwg1A+W|NW#KzDxeMX_}@siX)i zSd!R~ObF4rJk)qbCO{u5HQ`n)Obf*(vp$*+bv-K-m{kv?;ae`mS+Pm1&)n{Qc{e`h zBwt`a;pPYtGFv;dyHM=9EXj*GTyJ`Mn2vSlS_2E^R^DTP)Ru$6nOl#olo4H3aJBvG_B8^>5Hy509 zCUbOIH-cZ!d3^ivg*L5UFW3({2(`}Tv3+=d>}wdchb!`6D?0f7F~_fg`rSrf(#vP? zSMF!49H&xE-jc~6W_1P#!?o+q#U>##Am>ZPsZ$$K2ZW*eBy^T5Px1tdMw%(-pYs2r zzj*Ev*+(q6eNz#N$25s*)hMVu`_Tvvs&7u9Kw1C3sTL7*)tF%5#AmOV2Y{-w^H#l$ zYI9uuM@x0Sx|LQ#q%_C3@`yo`(=kDyDv>hY>vlvC2S(-Endl7*DW~|;ZN3ZK|5G_5 zTd{GRxt^|1-d^+l&i#(zr-F}!wY#b8d+k_;tObT)ElTQjKh~e_!a?=D@65!L*N8## zgHyKR%ArbG61AZd^IdgT7*lCsG7$#VwBo1=`J?sKprf(m`wD_nRrX2Krq%w(+i%KT z*DA%=W&>W}_KztbS}&^v@4dg!5tUWG_+Vi1(B0i=T_q4&^3(|{;d0YREAQ~?1&6a-OG zx`-k+ME!E|yLaZEf8frY``|pwOr9h&dnbFX&sy)-{-eKxzNd6$FsDBv-Qsd*s=jlJ zZhBRMDmxypTc^j}Xt~Eoi@h&O3w|kJmMxgx;RQe3T6*>QjK429O**z^n*VU_*~#1Ksi~_~`Oy*|>?^AupwA|#_^L2wm}i*;OR{Xl zbCSN?HRn~0YxMi?ScLlWKi%Q^ibuMap1JsDE)RMJ*2U=Z(NoRu@|V8;^okg07g80h zhc&;a-R9>eB_I6vY$|6=*sqPem?+<+v!3mj)@twDl=hs0jlJx2ubl%fD2d)?g}yde z{LvM5!$WVgtow?-R~55(-1Y+*n^hMWWUT+Gq}yrLmsJHnd0rTYWAt`}JEv{ulDKdX_6|u^It&5!MP`H0`wy zbekho3Dt9!GMep{MaT|Mm@i^ve&A`a`sKyDNL4d?uZ*CTHjEEj^wMDIM$| zFZRj=!Ohz{4o~c9ww!u83++L6c1e??#C~C>ab-iv^qN2sG@1Q72M{-BEmAcxF5l{8 za8Y^DhG|GvAwx;ltyaW$MVeh@a5T*Jy)-g%LKdBQ`m`j~g~?~foUQk3F=qMc$#F#% zs#?uz!#<<_IL7AdT(~OF;JN^~x^gqa{ zlCLsG=Y$oCX-yfHT}GWGL>q~m6eA>E`PBw&9nWRkmXv(V7H5ss3_Br-6CAzmb+*(i z*Zi_X()y~N|9yUWiAN%*#O;a4;34(e20WpbHqEjeV=lN{Xnj{-;*xt*jZDu?)e$>f z9Nk9e+x=CW+D^rnN0HRgc6rhfi(G;a-!;uv_Cqo+j?~&jL-H%Ite4EiT+6IHVGXL6 z{^-=g&1L~=$oJyAAga9hDL(Z3j;h6!>n0`&P1W4}V^D5?%G#|#AnA>j`U-c!CvL5o z?-ZxNdAD;=$3bWck3Hr-m}Z zWBt|7SNZMPi%VmL`7DUb-F7@viSq57w_;xis`RrGw%?Et8J_8S|AYn5gw& z<5s`UxYM05o2y{r$Kthd_i+)g?!Q4I_hX?V4bjxig&@t!s*3D2@4Tf5y~hK>bVPI6 zmAj(m2J7t^UXQfSygcI7=N*1#7ST=nTKjNSjcVLxy3O(XE|B_S7aqj-blQ@US_Nl&Trk1U%W{n|Ibdc7J`ZnS9hLd^K1 z$ltXK&zWHV-B8S2Qd{CuzpJ?YOHxyFu?O}np`B%4!%;E99`fZ*gO$l{O@ggJ$k)I4)vc4oU*S+DIP-qs}iQdcG8W;?m=G0JoEN@6dAWQhe_=@}`UlX5BhKHm}gNn-2f z^^sG57dPE9eMfI^$%T>j{NJd=%g>#)51a_^?a1lVv(}=Q!X)%gWT!wU`eNV9>z^skSsx{bpNmmHYDS5yg zG@qH1;$I`;OrvFVB~7|MD&ef z-)&t(slL3rZ0luw9#vQD1}eXxpF_0RNpoIrvN``|Glv*L-Xl$2t|abxNKR{9UjKy3 z>!YiDIN14g37^LJ?*fI_Dw#L>ZApBdZOw(c!FlJ)f)ASW4x8h~QJj$SA~RIhf6e(Q zUdphSD%6|8JaCf7R7Gh_&}5&?-S|e~P%N%J;^y5D4P@8=fL&klT5{No28{TrBd zfpX%Y*W^l&ESxgSC8c)-GGCU+dgnM$1T_^)i(Q}`IG9Ilsn%q+1ENgFThJu2)aR~% zkvGmtzeHQH%zS{?VYk$~L41v`+>wF62$x|3${lj#z|r7{(Q>t%a_`?|d&mk8MQLz! z)}OQrj9ta~(2AY43P1hwcLAbr<^U;+O6!4=|F_kbXaC=+FUJGd|1Mwu@Aq{;ga$UC zL49aUNi=vhjdhU5zCz~>V>N7MF#7|R_Y~=>yaW2(gqE(J`M6o z4XEk{rNIUj#&qm)16t&UrojzupBuVKH!#&V4618L!2fn-1OYxk@Bg?mum6uLbEd@c ze~b^Dwc=)(n@8woxz~l3%?iJ`-OWmTCd2p$stDbx3c1y?RUOg0yH!INSKO|>yvQ&< z61G~luciFl-M&s_Qre-V3xw^|GmMX&hJ4+RJ2xoSN{aUX_Z9d5A6162@>+xV?*w2J zuGw(pz%Y+hGuFh+CDs!(iz z07Ayd+ZKriZ^uvcX);QiZQtc`jK$C*5Xh`c&2=v&5w`U9JP(J7K1;tUoUn9cg(Ez#DD4OSRdcR5d1Ug zx8=s|{JOq2M{qnlQz&vA#{44k-Qw=A+b6@I$;+Z~G8B)xE8DP5SF2sC8>f9)TlwFg z14z2&F_J;e>6d@+S1w&l%RqfNXUH)j9@$?k$Lo-!L(Rv=lWdpVWUd8EWh&Gjka!dQ zf?Zv|yhLqKLVwH9V%I?f*G_`eIJGGG+N`@TGFmr}%pkwzY&ROlmI+V4RF-CjLqD{CSNH3^ zN#L!|gRGIcVgR2uP8~*+xi~PQZ^qvFs=Qk#f#2yM<@XL&)NQ}iy$Crln^63D@abc4 z8=}e63=Mwc^Z3sFCqV9M(0UK^DbPcX>_>mTa;9;te(Ewu8?n@j7XJPITS-#j;J`%E zVC6-;bJq`Bju(n2K;qo}hrf14B3wTu8#k}vzm=?Ew|AE=DRpiCmN0plS6+nv_md6T zs@-QwdRU~|S1JkEJTV4cv{QmQ+D)!?SNNo2112B2|05fHd#iv*xSs}a_S3UWg5JY*G3Js9og+fS)0d@QoXQ61ph^A? z62}6P6NgMw7Bd5DB!D1LBuSYO?T*v_u-@NLQV8Wz`ep!PRqx{#dqv_Bz!16I&;S#H z#%zqF1JbxOz6f0YeJ};;4#nQxoB#!A3pzGqKrEKXy!dGuko$657blre(`{ z>->qohMkfGp(34g*xe6T89Z<;HkAdk6)_wYF!v5XP>?UuvfLd@g??RQfy5 zfUcP1X{G`{65vmV8a+C!DhnbbLXaTX0iX?CDJ1p&7XK)OGK8@5R`r@sr%Dw|f>?{c zIZ=nNhav#!SLPgy2u*`tp6X{oB$FRi5Xc6=(Kd-IWU`+li+raUOyM%G$%y|I3vrGd zdaeI${>~Vto>fq#spWFWl!h3c>1o6**)s#q0zEVsv%`-0^|ZMPrSCUcBX`YQ4d#?{ z>~-G@bEyX?Or*-*s?&3L@wcDJIY@%W))uj8;=BS@9{S#bD`<6VvUjIWY1hx63>8HZ z5Bmy#KW!TJ$@|9HJAUgu5@v%L*8Gw9yv*arZI6eoejTiy>HawusN-VmW$pQ-{%4rC zN#{Pux&w#}S_|RSCx?e?F!9^gEJgQmC7QMK}S8Rpe`I#Z7aE$&T(+4>8a zsMsH&sdZ0+v7@64SJ=tvdXC# zx9&4Mb9}w(n|GS4Ybrx#<~pQTLt{^xY$+3Lrs)>=LO6E70})K^ybDeDvCynRw0ZxI(IZL_u>t%vrtB-9dQjriiLTgok2*Gzvh5ly z)1(JlcmTG3U0niA7-F9`8r6=UQOS&+ttoD6?$*CEE6>zslf~HxTzFV<|uj{TKvzq4+3EVRiX;JA7;5qefoJBw+ahOu<0#eX&E{i4T{kk`m zIH3T5A$;%cp(j|-9Rg9}$-WUye#89%zkQ*5{#0|OR>`HY-EM0vz@c{;7H15xa`2m8 zHz9M~p)+3&oTaJ+4M5!xX~NA|SZFzMQEo1}G?}z!g{E_>podkLe~T}am!BN2sW^)( zZI8Y^9pkDjE0(>+m~I@b7sh>syg1&;e=EIoo(Macvk%V_dq#$OAkqxRt3mt;Lu^dg z-&0%w+=Bk4e0UZ@W12<(8Sied-G}}foE#fbJE}EORF!yvXG$v45tKWKr03l)QOYL5 z1e)988;~%Md?IUw@ShJ)48DDxz4XTDtfBln@AM%za-n4o|Int{@rculA#nP8QzzVfqUREF0dnJ#0A2OoLJe(0kmj2pf^8h_Wo!j8;bAHV#&&Rk(q{)|w) z6DQW=xvR#dtg{d~CDBq_(E!lS=(<)j!r8D#D zxF-lq@d$qjrt;fQd-7V6xcD2KMql;3zc!6x0eIi4>b%1m(+ zo&e)0Df$hW4&U7s;xZ3PWp2i6w|GXp**>dC0F>z2V>VZK@Kc2?E0X3onW}0UR;0L@!V`3hK^$IoUG%!3Qpt7q$Wl&}Ml4s&%2iN4V{g zqXwSw`OfP6N(|15EAcSggeXOwS7(C+#Z|)Cv&bp&q`2?+Jwb?PdOQT5#gBj#=;eJ9 z0)4g(i;)7eGBlu9#XpqtGyWDS%ImYr@ zQv9`SVaPp2>frLVl%w?h0Wye~7usbev37bSxc1LLi5Iio&bB>+LE<4?1aK8&fhU-U z>-iU`{IfA(zhl9MrPf%HdUqB;6CHjWn(|wp8kay7Z>{-cm#3U?@pEhgGq&i@GC_Ga zW9?^yBl1RHh~ZRpPJHQ&8}14*0o8=w6mm>h*o!)6&)l|bvO^N};CCaoiR|28{CY8K zZoo215ftNAQ>KuZv0IH8Acx7hsI#8pZvu|YV=j1$t(E@I`D`RSI3q^uqK}7V1_Xo$ zn^5BI2O}kuYCch$_9vT2%Vqz5H>Hsv5^Lu_X2*Iq#)eu|Y0-;`p^2GO06RU4Vw(?y zC2I`8ia*j6h&g{r6;l-;KfGCZl5WksrN@Vs-AqUdzC?q_2q$h#$~|e_XSuHAl?X;d zxRD@Vpa4aIC1w>K*e8-Ei?s-VcVBFObz8Dsd%-dOoIVp;s^wBHuQkYHPU-fla`f5Vs4iLRSBNBpGZv`h@@oI*vA9+t%9{RKw7vE<?Jt!friNKI#=F@2QatRGlD{ZH1@;<6eQKOqvKb3; zXE!d(N|WwR6f5tgyDYbMF?En$owtE^e?ZZyce$P$bj~#2_<7L1(vts1@fMc|Ssd~| zl8&k1W#y-heO2-Op?3sAE-)k!OK6i038KlET=%W{Ty+w!tX%#>n<^qgz1v?fmU|_r zH~c>H?dJ+ORN0L%U#=-0*M((8T%7H=g&SfG)Ua}URUXiwH|8l{c4@iHNN!CqEhy>MazJST--NzVmLEUuR9kR?>pEn|vB4(b8ZramE z&NJurMQ)(-c2Ix-3dGy_h`@M-zb7pEfC#@+v{%{JGOT=bm$=QKgjrN{3N)Kvw44EVtm`tZxv#Z1>4TLa_$)q##{$xRa;sl%? zpP4^w5nscDzbs-4khg0!(f!V+Y4v|@ZIinX>Ejso+ePOLOIq`9m)@4ZmnhTh1-$PI zAb^$A$Tv|UodMqMr~S(LMc3+KXaH(QftD&#!EMS=J*L75Jo_6S}7((2e7?{EKWn)-mIU4=>nnpAkWX!#mWNP6Z3 z?7!|h2aD?{1n^)JMTa?wAt7q%;Jx*Mg0D!=AqbiPAlIG(x6iBMpzcKXXCyz_xo191 zU@$VuE_l*1NGxW4?obPjn&FJRKOfa>uzF8RquI<03CWEI+>|U1x?Jy*v*i<^o_UXn zC;%M^FeDgv0OrBty`tc+BVXudX5X4INYKI??uMPUBh>A9Bij2Ii@S6SmN= zeb243LGjV6;8r>r%1{Q&BX9VphG-C{`DymfLd$Sq4vStmX@=I$EQg*7yz^pFVB*2q zjl`h!8#yjXznK8ld7d3wofEpc*+paWa7MILbR@^oE5Yic*D2E!Oz_Kum|SY(@%>SD z>XYfp>_h-d_c(P^rtaYxRWy_d5BBc#P4zRsa(hP4K5X}J;LY5e!Sh6O2i^%6oay9@ zY)gV*Kl!Y6@7WDwRvT)v{^N4hjx46+uQ`u9lq>GpxXf~hOEN$sBGZizGN-3Y-)>$S zb*uZ(IZ*p_DR*P(qKHyCzm1rmb4q0h!%1^#e)S&=Bmi7KqnLL`lv+$3Rm^Yo%`Xhg z2!sOAk0~e7Oy%y(g1m&)s#kwr2ko@45G)#eXSU9zg34vwDG;MnvU14fF4-IIb!H6a z=CuH%M=*S=x>${!TI{ua*EWRV$(+q}_T>XHGjuLIYV2m}&-3pa>Tg9oUFUod@yd_m zKLUk$MPpnRtSx>CJ`T2{TLtXdpJTa-e57kcfpv~s9oaSe|4CO;&bum1eV`0w?yRj> z1$5WC9*ji{^`6nWw-)=YV&|^j8V85$5bVQ#=ccsP-kJOQ1n_^AsDIxb^(&Hxsx0zV z^L{3^M0`9Hnhb+^t! zGc41Ivru922R$h7LlIf5f2V8(GveJ7-qpKHw@bGNe=0SL)p|U7+jgp@*tRNs;K}7L zmQq*t&zY`x{~DHS02T0PZcpKejlvJXF9G(z_&YyseT2g8aImwLXYXy=cL#yo91Jj> z%pH4#@-tS7c4?_I`bK_w0CZ<<+^``)xcTt@U&o zS+0+M_d+ zb<8K<>(b$nLE@FkuSG+_3nAa$9j3XuypCcobGU4Xu$R50&h7}3gDf7bI;my9vbD+U z6Z_9z9_HJ28fH&dc~YS#(gQo~vukqdFkuv6P>sCO>JaAOpPIRDr>igODn-|D>scke27q&;T13_4f6FVSJoUl~rX`)wS1ewBJPd$#4uyo+Q$q&=O@i#KxZh z^@ywg+W~)rXjmR!YMCCAl=(FOtqI}fNzOXv&+Y%O*h-0o_f{h#fo={A3q}%R4xDYC7LJ!iJS<6Gggs&T^Nr zLB^zr;@iCErpw8hu20D+a7d$`aSnZI*N>j9Lx3;=d5ZpTLJ$c;{FE1r@=ya_YxTPM z37beDK%h~c`WOK=8l(6^Sth*zw?NupxxFw0911X zn%txWmvN#Hp2w8;MrL-0Z}*mdwty$TzD6Vb)c_0yQgC-v!kMgRd(Vj>NEYIPoHB

shsNyd_uq|LbV5H$sO*ExYTzxlo;9Y zcJnp{I(T$0VW@NT7T)ibkVRoS`~(Stm<%tC04DhXHu#l%O>pR+uURX%THK#+G|@7Z zK9*E8Z|zc>D-;7{*qbTf;8wGsCI%_DPD)41_;R-1#<@A6v+I#cDxr^*}q#4h== z5N=k4-Wmw`fyDOkbtqRGDqslPkEyu$a~;3$yb`Yg%1{yy#V_0-Lg6w~&aNDWJZW64 z?Tk*PV^iRo(K7PFO@+#>lltqBDstPsCXP-IOHPY)V<;TkiTf^dP5eEmeb3x_s4r^p zd)#d;>w+^gulciM?tEBY(SmB)5-o>6-LwC`3}r_SLGwp|G?*`nX3Z**jRdnAp~_Az z{0vA7?)-Je?#E7J_{R)V;VgIk`F2#;}5h{v)H7n&uA|=_l15v{?z@9 zu?pUdaIg}5IBTn_;Ww|oPmTf_o<`qrmtc|?diU?5LTRph^dtU!?w2rTMGEn6nH=<& zc3V);BpEJ`6$Xi&;EmyU0HTBj_Eaw8@u)4hd8<$c0gH zc4LYF#{?2kh$j7egAiUgf+a@V@XM`zwq#OaKj*epDdfIRlE8ou%Qnrdr3zVIcdvp_ zngIVaGSN=>J)5HtMD`V($;K-{KptTthbUvdvqcsOAphW`jqy)>&i;n4 zqP6o%@USDoPESwHtO#_l-cu>MNe4-CqRlMjhO@F=%h)w(M3#z9uptld9w9f(+Fo3M zG9s!dP{_Xmo-1Qea_^ylRMQJG3%d}O{R1ZLBL^KSjYLWd^3*wCG|(ethnjv~yBOe0 z1w)mov6a|Gh-D+$d@WzFCBbdanuoF7pc1{5kVJ+OoL+00d-pkJm}eXd_M~{F7B)}b z#q0q7Jyu*yB9{K+^L6~x>xetJy7K~)SKmeFXJH7{4wyN)moHcjR(k0|b!!d2+__}B z{^MbeC}8u&M7KO0a;cCT^eLzb!80f$)gFEAlj1tJ3dJ#^H;369kb;b7_xeCxO_VKB zEN#rL{OptU^Z2Sdzvs538JQc4?G?_>vPSVb3T6#!Ag&GWD&@;}HPv4gLuCp5nLpM7 zz6DgXJLa7Z%W_W*WpAq$87;S7xh;K+v%zksy&(L!i(6xZlFdO>t zK?W8JQdYC{;X;xiZtC@md0&~YZdBQttq*o}MnySb-~k_QfuC9hX8)2(hg$+n(&%&N z`Y9PEYG3LW13zaL8Jch0NmOLF>H`0km)S$FJZZt$6c40v_K_AX#^0NV|6xEnqw|13 z7_sW}FEZQ$;!e$=iJS+?f^kXg?IU7!W(3}r* zea*5izPr^WmqHp>CM+bH_c5{JN|Uk}$*Z!?fOsQ3CU9_%`OGDNJsUK&=xgZnmHp8? zOFZK_|FiU$yf)7sCsuhpcp8p>`(@dYZIr)OU{&4L=F8{DfvdB^IOwKIuYqGmfq>OR zrBX#eBaxTi-`~NgKGQ>Ns_o9h-f(rMlCdMepMv9-AcMejw^=9;_ua7oOi~*&&B3v~ zuBI~%*qn!6vyZv{>aS4w-;93u`EP$Ds){A|r%-q-L`qhiqKYWxshv$vzUZvSQZRO& z!nPfjEW`~_zXMHC#*Iy06u)N$E;#dSR`;Z`@>Ay}37K9t$AWI*&D$}_uYL8{%D$k$ zS8f(15(=PDBhmfPTlr6`SQo}hj#vXDQ$8!L+zom48S+g$K2@RMY_95s!?^cD&_Ty! zzgIPmOcc6`i{uXHo$ZxuWXKpS^0iD#h(&nd94~+b>)`xDbzMa+_>IGYyU=WXXq*t$ zs{otAPK)Z;NSW+2)}|+L$wG7yj^_dbo82OFZ2Sl1Kssn9MZ}d4zr^-4SX^~ZtCU{! z9EVyS5xM>__LC=)Ah;mB{fMHAs!Z0*YVm!6e!w=&E8tjTSC$c#bp%r7C zjQ#~rrxQ6d>ajpFSvSte?ds3&6VmHg=Ws32e?i8Pw?tQM%=d#JCP+}197MVkk$XV} z0i3pno{ISflEu5v(>dyK7tNYk(OtGy(pM*?C7Gz)4hr&&r1J;X++I{%S60TJl()() z@Pa%j56@;Ho61cBAK_hxWgQ<15`~#k9=ymD{_3HN2C)Q5lnEs-TExrpK?eCj%xF;R z8Yu8bwvMfD%cj~bSWZ4Dl>ZxZ9Q{h;rc`27%xx-c(p*3wU7%i1o*~unp$H>Ffw$nU zjODa0x)*2+o@+to9)kEHF)S|)xR;_IWM!Z-^8Q1}em}xan8SbYL1f3X0+Eo)3=@*A zA^MQ>AXqSe3##~yu~kbfm_`Z3xTcdy;J3DLb-KsF5cmWprV2zA#|EA-=aZR&_r9O0 zGZWZtNJNaDNB6m1Sc=X%$Nd#f;k*GpJ0Z^qP!9|-)}m!uHUd-q+Ea`9w<$4?>8JS9 ze0mN~zaEeAqhHyN=h0`zT7gS4GvGF-OB`+G^(hG++eHRsnI+fU$T&V|22>?h;jK1E zPt)8(!BN;cQ2d1hHb-~6F*p*Oa25ed2?4SHHVFrp-v#rHEZ}Ydpe(N|_T%N{Ogbr$ zs{l|kdQ&EvMRFY_&#?xxz&S${@;-S*t_E{!_oC#x3G-OlT`5z-PZy>B=v&R{9pBJ4 z6h~Is6Gn;`kTU1OyH2(LDU}c6dS{(&R$=2eDV`q6dbuH+dx&^_*QWbP4Fz3Y?@{?s`0n%Ne#InBr+E4)h6D zCd-mAQb0+svXHv*p_fQ%;>zVMuMWaCibY^qzQ~odG> zIo_NmaTW?@LaV19gK!5;qpaDv6?py5b_Pd+B;G{pSaW~$_$hoMlB>&mA=mZ}(qYg3 za+EembIt_?225i_ZTR`OR|GC1z@{{i$N@wiTQmofmj2+njHr9{;v&32E&@TxK(^`MG$?azSl1k}{4C-5Dj&gsyP)P}8{&u$d$PNCv64oiN@5b!v9&+7zgpcX(~OmQ4!bbJ}fy z#y|A)5!nJZG9VLVgr88bC)&NiK?;Q)qPd`bC>WlmI^up&o(znd` zyzN$gMj=1|sU?GEkLzt-R58=q*YgHkMQzA*ZfhlZRREe84>ch?ln1~wVIW~zOA0UV zcV(f8ng@T&eK4s0@fbe+VXjVZ?VEl5JmX*sdYg@?7&Hp;#z6xS1pXjOXP`Mugx0(p z3`Tdv&Kd1|6!d zzSeIclwL?4+h_wh&l%@WYD-Vu*GE9j5MYWJ*o@I2lLM#FnI$Nb)vIMmFM870?>Pft zZKBhX4;LwLZ2b@PYBdCGD1SCz7dl5``vl=ebVf*_tChyMqY5y|?Qa-?709c)bAAa* zjoEo@kRMgdz(8HYsGLjx5lLp+fIjgK^1#?J2TYrz;!1~J_Hfi53lYK7 zYA+-7d1RA(v~%vAoDm6*@I=cU*Q=&X56`ztc?htw=T0rBfEX)m4S3L!KQ>;F~T`Bn>Rvn+1pi;JR7G3v*s_Rh(U# zPX{a!jaRc9P?4Js!5~LlJ6k0pg*i?`rc+XC{>hbgsk9oHJY}Xbc|!LgOrH2Sq7Kj& z&-x27MN(!&C=ebz2&bBriiJ!~E%<%|$+&9E3$tJ7K6BT|agi;J5iFXR8T!kGwmm16 z2Cur@t6z!fDOI_sagq=5B+Nin8i|f@q zH6lnj0pey(Gdvk-aXONwt5zpO_63qw7tW|iVE@Vd3VwBzVmi`iy%Yo0CSK?6;&)Q@ zd6>|?(!(Q00j0x+^`)V&6HR^JkZgr*MuQy1wvmtZqgQC`wujSm?CfVhfZYzD&e(}$ zRggjC>txj$vCZ7;jwAY=VEF>?pBf^6zG}>*vOIf(c8C{QP{j#h+{WRxhXnOEXF6C! z-+rwIA#-v)Rl~S)cO1Goomfn1P3@)-)pFDsW%ef zrZ+4Gh}k@6>v%J^+@RDilw^+u3t!{T?T*%+W8RqIKRUNej~@E;VL^iz#@!hHX~-g( z<$~NsSkahU$JxOg`igII2JMN%( zZeTgS9=OfRJ}gvv>;yAIgV^~GQyZQ(0jBpU}Eh ztDsks-t(Mn1jrM8=>4*RrTWkc;r8rDI5ItU+-fhgH(Uz`X>8LR_zW%Zg&ALe7csAM zn}l$)kgH|=xbLb6P(X|$J+0Nn|NcSU4)&}7n2@x1_}4F8#_DPhv=uIXeeww&R{z8I zD)4bAoUr6(gZy~|26~tJ8Ox+8i3g%R;9i2?vVQ(-4ob+3_fL4_*!=he#*J7ic(;(K z{=vM?_e?6ye!v> z*x1rOaB0HHiygPF9yb<-dVXU=LSPp3oJ{0iEPs>=^S3>2SAIsvHkILk|6ePwd433# zw+WJ^)Y;ihO|nX%s<&eBlTSL3kana3;R}+Ik09gRw%dG`ww$Xq% zLXDvllT(u_Gf$t*O+ajH7($KKA{-1}GV#9p{=@pl=GOMk?snfm{^vnIPR8bhl>4uahZgvEN;YzF!UHN`GrtI|0kehufT}g-}N|%;W@-#*y}NAIm45 zntbZ~a$L^KQ{1jOJ}0~fMy)WGVz?n92+d*xeSnHnsh+{Y5~<5-iDs zZC>5y9%i(OTUic>)e3>?xhuIj4q~N?)6E#SOUB<)gC8Qppah77+3BBc?<_GmvFx6% z8v*v^&FRH1joCu(ir)6u+H>3$DCI#COi>wmo}HN9qn+_f*!))JbODR0Bw=1DlM5=J z#Ik^Xn*u3|bjVj$1dl~Vu8e@u z$<6+@ltj2diWoeq-}s5x&@oQPOsWW?z)_ZNe=_;_@zYW@z5pzDRp^#KSY(4>$;$n{ zae>?E>o+o>Ws4kAw-8=fIeqar5}|u{S?;AD1o-hf2UR`tGU0nrW7T%?mlDfI z%BTKV-lnG>ZT4OFsY2CTUa`WGCYg~hy^&;nA|6>$3Jn;B+CECNkd(0I=ZD-9f1iei zpz)5UMdg1CgLwF4vFyh7I(2R^cQoXZVrK3+!qp5bGVcdP@FtuS%alt@oLM{rH95kK z@cRnoG^*MaGGj{-2S_rrCaN<7b`mISm|js(!X1kIPsT+YuwRVDhx!qiF?ZSglB_{B7m zK;&taX7-H3r(e?fj|l-cL@N@AI^3e^uSeL+f4=AD_G<6*5ORRh;jKcy_yI&V@iIS0 z?WY_fEP)Pz(#h=`swXHEO$%q0M$mpZGd4Cugp1JLa9h0 zqKIby7yvM60P#|Z8?KI0?Y5u_7ZmIWEMELa0;0MigShSg!;tAuc zYd00U`Rp;@{`5}B5}|Xb%>q-T(&x5>P8rNHp_oG9O>n#Fa7MQ;Aq~W(Nyv*@>A5tB zV3S>F>heoxxprtoI&$=Ij$%%W>!M|Y!fhLsyu>6hbryD4~KQk1p!5@(M#EKmWH6yH7DQ*lGq&~-Aqh* zvD5av*EO{lzUS^bD~;MXe~awkmYx_k(RX-T_(C0IX}h0$fFN zA&UTJ9P(%;Uuj${Qkkm*ImnnhsOpahu=dQU0r5Q=#Wk>8Qq z{uvHucfr)%H<@<*7(mfy3C_|e)pwIzv??$`lRw_AGHO?bax&5y#ozsYxpD7$JBJ0Y z&{`ogQGj&Em_qKzbPqOE-kGzl91w%Pe-xZDTqgJuzs5;Zd_8?@n4P6~HS%bI-=bZO zFZ}M8YsW9{3qjxs?0d7fv7k&WBV=7oOyY+ zCzJx?)3yzqy?2x|y*i;iva@a^r`g$05Br(FYP@oMeMc5e%6*bE}gF=ZjnX`wbtC$Nrto5kr)&dV%~ zY`5;SdL2bF2OA07IU-Ed$th6M0Ih{%&7x-Dqvsc&#iwGAu2vI21v@V$JzIJc_jqwh z2Me9cdBLnKWZf7Dl#}pDV5bv@mx${LmlUN{TSNY?D@cf`K$GS?Q9U~^n2yVqgbR|H z&EP?)q=(zs<*+ltu3L`=8Wa6PKNp(vz2mwR-+gij*5@=wWaDUtEq=eMY{I_}GfU4g z^B$O`>M2frQw#)j(gNXGPf~XA7w}}K`RxSBC$i4cDx*9eD^Ik9Gzg#L0ck;^Gty<` zvbD~8|7e@|qwO%Itg~+gi3!1g2@*mbg@8I?zj;7PNT@o}4-pJ1($eQfk(3$|vgn{W zW;>yY3+de?y;7|qM#d_^=WBQ1L4XJ7NTUy#IPp5a!ET@OG>;#))tQt!Q_& z=&>|7kcO&dHiZQTJ1mz4A3=9x11)L#?%tI>F(6ABuye>6zvc4jtRj&cUe$;)p-~7c z0jfp*nj$JO6(I$ol_9pgFXmJi6lC1jE3=uYA~F?Wx|lawpd6O- zm5Cm{=i;37t1wKG#W_{lIo4(1qPk^2q0k~x;i9GW;yXKf0N&CBm-D}hy34<&-}ims z>y1&PQy3|sI7%8u2#CZ$YJf1LL!}!W9TKBkMmLNuV{|A8ilhO8ZvhJg6hY;?&yC;X z_bYn`VBD<$bDM|J%#A40!>wt&*)+^KC7j(ZUyEdq*{_His66rV7x4BLlDfTqD2*hN zC`tP8Fwe4j7#|Lfr=1dv;+c#f+=`hY#Sem4t2Hq|Y)SAhm70~hiYJXXdR8kRQ%<|3_}l=beiz=sKP~)j_Yiiln*&Zsxz&nQ#0+ zs7830QN+}h>g}<$(wI`)5&(>Po};j8^rt!k99||bSwReFh>tIKlq_MMs-Sx5{uaIb zu>f7Ds?b{v#-o5`5lI!Nb;X8kFbY)Bk6;-Dp|h?I?oDMO<(Kn>rwuj;8WpgUk@?y{ z9x61juEq9cWPn{D7ZT1!ZGL0qXb);B_5#@8K;C}MqalEuwA9|zd#-J#BVfF`V z!$|_CKsYEI zN$LcdaXQm}q9CUk1oEWu+HjwOh~`;dIITm{iP9le0%#Sz7N``n7eaij8o=HRSH-o! zN+b4>*}ZA`oqVEG?3K8E!%CC4Ryn%vOcp!>V#Z>klRO2Hs)jEF07octh*vxS(=ZY{n7fb7wSg= z@{!@!D66tQKdk|0sY0l6gh71hlugz16m;AHkiAg`^8v^m9A0(^Cg4ZI7QK3Z!{XZ zblPWxf0CjG7uW!b;ox7+h68cn)Spj6Lmkc7asO^U9ZC%Us5IbV*r7@u@0v^%bb=al8H0*q{rE!)(C#4Pj7!0&M8#ZluWI$H4*TQP^mQA(==(@q>O3D!Is(jnkqW4;O2Y9%D8hGpJ?T zI)((^9@Z&rH2X6ah_m|o+tP=_3DXy1Ul!qbX(C5`LYx9i@4f6$8m{3DG*v%`dxR7I zSvUM`9^!h|xHW_i971zk*W;S5jA-eL`l6qO^{~Y81O?34-UcA-r@q+3DY{Ox_yO?o zR3YzlZq#!YTG74VbT;u>aPPDk0}cCv1&U#jq~0&~Gd3T{x%)YD#*Zh15+m?Z<{!k? z&t{rD%eRF*9O$PwzJT8Qa%=vac%%;B@&+h}xJ=fJ=pK$w{&_*G&Qqs6&&5L6aAoN? zGR5~FB{IMR=V3HD$LtZjK&{wLwb-n9UKTc$?=2*bYu8KQSLJDaGb9}98~$x`uAT3N zym^fG2JM@Iz0rX%V)aR(R^G^qe}7&~UP==nz}W%m-lDxl2oN51KKiI^k&iZb9e@LN z7lp783k@v>d^#;!JoJ9-(j>(fa%U%sL*ZjL<04$|t$@^Hx_#rvAC-V^SeO_NbZ3JG zUwP8GziQcbdB4{Nr@m6ZoF+$w()!+DonqZ3ZLHWAMsKID<-YhGwZMHVy$CR5ld2R? zuGG=Xaw_MjNKNKe(08EiY(08;QtNAx2d(?+Xqez~l6-%@YD8^zIp>Wlk^<4F4lim#$4&j z2xyHcK-9t;_GPby3}I&t-D5gHS4*bgFrC-scsjyD`r8rTq2;a16N(g2A}@fL@s4H- zeG2bp;B#pmODw^I#nA6lZot0Azff|2AMkteGv|vH#vxWZ_TH|UulvQKw>EUsH$K<2 zvQgg0{@Gw1D^upoKla(=dIzkU3XcZJ3z)7mp*{p%O852ZI$|BSu~5TfW{fVs>e>15 z)8l@I#%t?0ii%7w`x#2lFJ#Ss-MZPgO7{f%xx>;&Q_bvpvG4qv?)tWA+a{a`XfDc-+I-vr(Z%oSxJFZ;2QRR)3o?U+}l+Xwau>`zh<_+Yf7oV zD{bpi6UR0dV4<=d7p0N+t)V;xtos1)&pP2*BG@5Yb*Zk@C7MYc$q>~G^M;(u3g6bJwUun4e<@Zms$96$kOI1G2cS`pjvyVkG^UJ@W#yGRk zH$Ro?4^0-IWW;lbqwTvHS0qrLg9U%`oPN(`y|enpV$TW$65ux-5mZt0)lVnlI4j7u z6QW{2DduHJem#96fRVOc9e#UG;kFnsc;RgMn91vg;9 zOVHC)nFq8T+Y|{pI$l@;#v#)o#Gy#yVRBhWNY(>uwVZ~=rsfyHrA@1uM#uYiZ77O`xeOW&cZTQM0J~^9wIuExuk_URhmRn|nJu`E0XnlFfjNm%6*xn?Gs* zS5$<5YC?~)U}{d!(yepiSea5b4E9+PZ+>3Vs2rbveZ|u3?m@|pw2%~0I|qK+GDr|Mk1tC#8fA<8?j5uej;0r|;svl;V4BDa*Vye$NT}hF zg?f771xv$coNcL(q+UJ>e-U>sTkrv^Du10;Qg{a?7j~1bw>CvYT)@<%K`7-hSnV*x zQ%W(PA~I@0pq;na#i$@UK1Ib)>3oMFig)dAn>aca)LPQlklwCObKXNh0)5C)K0?Ly zDvWb+3|Stbwx~?I!rHRbD-dpL?I$my;6-!fV_;eQ}j92#r&RG*&gUX ziT1mk!yHa{t~t*+zv0mkc54X}&$kLwFJAMDyQv5xMR~S&Z?h8Ys!sFoJDcCSS;2&^L&Coenlt-}MMF&+HXq zlG8)wddpX`=@f|M*v3PUq5%k`H8%?bi}H2!Fh|tl%737fkMpnVmF5%(WrN!vCSnCm zb9DWP$3mVD1!A|UbSD2AoAEw9iff!KL~H_VtW&?GN`;6qtnQfRZmf~OZH$$fb?c_k zA@_0YjdeR$E9&ov=bP$T_Q!fRJ$}Awi=)Ui2(=pWcDZtdfAPMDe_Sv@`;+n$uuNPD z*s&{Pnk?sf2(E1c6%xL(Z12nUpks{Y{i zaLw&erHlIIIvk(9pXBDlVe04qeNL=a)Xi3zj2`7+D-h zUMl2h<}I7-W-eX2s_38RzUMYg8@C+>Nadf)o_!w=y_2o@c^5!u6MvRWf)JG98uQ38L~eiiKi*;JVq?Zb92Qt% zL|%7@z0~*oY6?bV0zT`XJbn#4l)lgK?vWE)WqdV|6pO&4?>c98KrATTALg|c->~4u3i6XvZx4=z&mSL4RlvKK1(+cGI{_f* z(64Xj3Yvka{LYQct?3l}j2eJJokE;c1ZnjuTglWI470IUB5=4k*0K!%yl5_{VqZWT z=Lg-jB}7S_*#9qnJhNRENpGZ&p~C=LTt!J0t64nkE93tbe>@e|2h%7v zBJ=1-{4meH-)^eGQ}OxaSmk{dlyPRj8+77cG%>C}ck@&nGyzlIOuuZr#Zyj5;_sJ* z+im0?ZGso?Q42D$L;)t{Rf1_3IUsN17uT9e)A|&+I(8uEAeI4N0wZ* zOS$oaMMUiz-GcutdY+P$J5y#UOn{OUW_k<*hGl9BXp8}J9|=K)xhtY2+!E~LBzz7I zVnMle8en!n{DO3~^!ntS&BzZh?>22rC`!rQ%;B)h&34-Xf{LMCA*d-ZU09`>i$GT> z=@KJz+eW-}4T%|O7|Q@c0W@8^Vr?uLpnrzb=pi{S0ssKgV&l2?KB;6iJ{I^dc#fX4 z5*bm39(0YEr1PFnzx)TSaozbvq^U4s3B-WVAu<{91EA+E=c|}RTct1jd7*TFO_7&k z<8%Y!d_4n*THfZZ^B1Tf^(or%7Hus<#zI)%#zEVt*1eg-AkH0Kperd3psWpH=Z3%tg z70n8vAjQX7wUdXAxNt$-_~`%;NTg_!?#D*PbMK`lTFn}g2@7U3yi_eVs)t-kP_DE5 z@pwPO{b@u_;;AXQ)wdiQedcztpGXC)-Yif%7bbw1$u`wy`{Lm#wLP~=hyuK70Op*M zivT}BC`l#uTi*8DA+bY4+8&7@&D4QbdUj`SfEkJ`uvGSM<5${hnB9%HjEvACMGE}P z;mRh}baEg#iQ8JTb|W}(qdQK4%7%hgB|d%@!#RO*Ed#JJg@$I%K_ z2U~1xuqv|P5}Pp_1V9fOPUARd_&sov;GBf4WyNjd!HSv-id4#k8;A!RQS8xr=js5; z%gH<<_~KNt5oXAXrf%I8;vBZ{Elbo4!;*Ek`o-NzeIM%T46-)_GCz6CLjS%=Wnqgd)cWR*mSpzG z`{6hc;^dtO)&Ul^(s&Ptek0pb@;bpGq{g7`_7 zim?B6%>h5r3KWb=c079>ft#K4{dkiQh{YV{oVTV%Kcq~D{e07t*1K?t8p^$xFwD7Q zXYRFrbxoMqz;KF5@;G1PmVu$0p4rLA269Kq93-`sBi_I<%=l)yo&S{LNiFk?@3sXD zW9f9TTz^r@vq1XT|Jd|Di7XQ6t!_I@!zajZ9iSJ zd8+@ZJ+j#P5dG(Zigpn(=YG~9eV(o=umk%m?(&yccp$S*d)H>s?SNDd05nzni74^a z3O`QZy`naJD}Vf+-^L4|{A(y3Kfuu?DEgQqqI2c<1T^sq<3yrbIr2eGW zB4WI+dejC1mBMt}b2adYd!Tw3l_j>NJP_wNIE6^-*GJlLaQJfpMuVXYlM1Jn*O7YO zR!IzAu}}=zv!9)|ZUk^tW&vLV4lf476qCw<0o`$6bqaKp0C>X1U@Y#VS&J+%Ol`I0 zGWv8odGt0@s1xVD9YqW*M+P8i#4`q_H|jTEBgrEqS0xTMRE!-SRnnGsxVoICf&=W< zpKF>=s%3U~26r`qpt!H@HpYc$ZG_nnhCj`JC+-u(I6vyanL>B;DjeI7kToD>2H9?onFk1EwBQ{@cH zt9C9})n&X6XYIf{12CyWyK+<^VvCTJ|FDc2{vjYu*J_pj71&ms1dSqkW!JDy5?LL& zD#BfE0f*{f24 zUee=?C^Pf(SSwUyC6`{9DnKKNojdN2gDQ}*^kTd)TUJ5Gg3HHUWF};_>w*_fzxpGc zAVtDxF%O{6R-!e?BxK>iNr8J~b4Cmb1OpyELct81fOcg3_BBP@!+?u=` zQeDBQhW@{TplmTcqWi4~G1W;0HZ1Ia#19T+j{({s!+23JwGZ_0(QpQui6faHF|XA9 z@_*%vp)-u(O~xEk^;6n(Y*msF?9Ce?C|=K3zWD$<$4S`JzQ%d$;aUWmb*+QoNg8G0d99w1C(m zZUl_@920fuzp|Qcw$^4YRSEEeisR^~8ZmntNIi1+uf5V2X=QpFS9y7W_S9BBTKI|K zf{{Q)S4(B+-Cj+%q1NSDeSq+d;)&_Pzz@ih<*uKk_ES3novQ59AZRePHE^Gxzyi5= z)RrrLB}BE0#pf1no7P~z!Og3qg_5Mv9IkcNF~Jk1*KEc{28%~Ru|r5M0?>A&`{h7B zQ)!DuB&UR-L=vc1X0+#4q^khmc{gWe&|qbD=?A#@5cIV8p2CM-L0P8de7y>z@<4mm zG+GbPg6-)kghJ_yD(#I~clGDc6ln&CM|LKEu2n%x=c?he&T_JEa7sv6yxOkT8bt98 z^*OB%d*>n_2iwfo2T8?)kX1ctLN2fw`E&;39O%vI+i@JcUC^l^p)Se3=ky_Sr3|ZdY+=ob^4gCz&KwFVo0jPr z(tCk{e!OpPL?dy{;x}MPI`klUdQg>Y#zYHE%J@nzR^7ydB7v6FGHYB}w(N&!mmfm% z%xBWwY<}IUm;f2;bFj;PdvzpK%8zDzKV=-I?w+BU|D>|`3Rxg=!Wa{~$jlIbhyuBk z_Ybo884NHyP%e#-YWbgHbq52l_Gyj;WZt>~X-9!H7=+W^gKt=lDm{`9*?*G0s>h0c z90`|a{0OnvrthLuvZ05B(vfICD1?8!`UcD|JKX9Ldc1j@6YF0iBq8fF>eM2gjaRFd zy>9r3w_QgWvq9&OCTHajBz8=l&d9hCCPN>QN=gT;eV^E!PRcyc`)oIb5SzHX3G~Yz zr!NT1N1H~^VvK{ouTRA(u?3TP8M|3yTbURGqB2l_lF?p`Ex{c2SI=X1<`nVM4wm21xj|z=+5tZ%%(UjMx8<3SU39}9J;3W5-u0&cDmrQSLtQWl)_w})qpOC`n zY`(@-Gj^0a0}Jo7VJmfdtj;ve4XTS?o6K8VglQI5BI-DGgcVZswOu1U*tAuGl5WO_ z{{(*@oy0vd7KWFY4~ixv7_iJMPrm3C zH~i|R9A{$k#3)Z5@qYiZKvgS}!TEg@j6sMG7|QtK?^oyZTRl#G!m*s^(rKv+t_=lXf;k z+N94-?f}u6y7~eREHBqO0a4f;119EF&Al5;uB?ZjY*^)9Ia_^K+6^7;SG2!=am*p( zg4Vpk2IKZF`L24E>E4qz0ci}dI(~1PB}(X))jitn+CNeG7E1}jdC2{%t{Ivf4lJmn zN`$LHz^LEO)3*QUEX9v4KWkS>E($TtJo&=$@{8il0W2qA{fFcLV^|!3TknJ9UI;XS z`t|KMiAooc{~#g^{f+o8=pTD|aOO87vhkepv`A@nZ)f1T{0Ni7^#S#jLLS2+qF? zFO`>>Oxv#n-}_B!T->Ariv^i1<&;Z6;Mqe-do2zvGWvboZQQ}{J>qE+<`;A4Y0EuM z0P)j)mCXefh5BK3Jis&B=`gqwE%*In@jvl=wAz@{pHDG=rrP(JMu252e`t?xx~C)s z4^Q&n9v{v9dg6p)dD>nyVjBj!9o+O|9}BU16BhAlB7ckrK7W}!1`fT|9LeRTT_#yG9YCn1%R4B-JhO$ zMsvVl{J+F@F>Q1`9uO{qdIL}vcFAI8#YYRrb$_Fmu%_#);^oy+LBn@g#m`#cu8;T( zQ8(2i23SdQgsSCir{VrPYVHiB;}5vyz26{AO2?c5`pPF$Vh%{h%+osu#M{HoaU~Kf zgKo@%qn24rN7_On`7bU@IF9g3eJ1E6YGY6GP$;Zk&WMEYmSIoR>t;?39WjWI*+W0p z$pg{?;#PtPTW<|&!9rpID#w;E<)8Z=&rK^{yGhZpYLfo)4ms!A?HI?;Xmbt2g8jUt zYtdo!(D--L)}#Y3QAC9)F-|{IxJ>ap+ZtBU8&9}Ul@Mo^rg`e8Irur29wReu!LR&m zCV@IkmFBQ+*aRVh46OBvNWUcAb;dKT9-2NrRcM{l(&1hJC|M$uC)`y$u8yRE@om1@ z*}?$9UWpIYD4{qrBD-8KwTJ}ec)IG@DxVp+m4X4@Yf5La^^33Eph^gpeOSiZ?-NG@ z*{*xMP2#uqFi>9A{+IwJXe%;t3E0k)M4FGpN<57(5Og@j7sH76uZ$?KEq)Qr|_mDL_7!xskJFeK2IM_fk@YMIslBGh>dtm9oOb2hFS2G%Z9kpYHYdh{4OgL z5wjD+sHc$LbNqc9wj~wSHZYTcH^xjv2&7O)m0j$N7?>n%DW$iisQ}NM*pWCLKxb!B zE_BvhGBcmV>EmmVbG!E~UHF*N5u528&YzlEv zfvTO#4FBurVSlbLmi1_-tw(ket+uHLHi|+Y!!KIiIeu+xb6KCm!H4l0%QeqUqD?ps zGlJmvBbJWp-cZb+^>dk)$bWVft9@PP)8$Le!bb~E8E7IcSH4CT3SLTa(K!B)t|Su- zwsiU%26icJ4e89C`xEk}?A}Rx*PCoCW)$K?0$IBr*?m4&G{V#Dskq{Igq$aQ^q_eBfD5VO>d4&N7G zR=Pe0JL*W6TP&Y~;BzjUvu2@FnMAJ1O-xwLqE@wSPcYNZG9FzDcBz_8f1$WHk^;otJS3ZSkn0Wrp)uU8>)>}@(;)#oC zYKrMp3F~t@vsMYK+EX8|>zO>SQ~ql;rXK;_FgybP-wF0e$|ct*A4xS`&s@v}Q5 zx}mC0Ar2!I+wNLZ@-`xQ@x|IzRfRhqnt`e|i>D#Y=pVk=_yxNr$F4fDkL7DYUh544 zB0-Adb?b7c_V1Uh?~P*}&n;4w8D;$S3hZT6OQjXA37Cn}=iia8w}1N+)aP7BpN#2K z8{HZBnKE1Buxi_AxS3PPtzvJ9lk}XO%0PolUNuIpN8XC!h*yjIiU$<0Pn|Rd-M;~; zS>0H5I*$u+k7)5dUXyf&bcGIoE4P0aC+jpTm&KjaL}9C%c&eGn;mT)fuM~8?>-;4| zp~2~mPpn9NLeyYOpM;}dd_@-(5oq1>HbwT2d%6=t7Du9~I-hi;vb;cK@nrS|y)_FD zC;F}B0y)u@Y>u++t3x@hYVscy{RgJoN6e;XT%?i$L)|!XW?k%F09JQ+d1DyLFG44sWw0sz1H995&_oPobeWwWlf*{jwn>$&AC+Yt?Zr z{6EIzy78hN(=+qMj>k0m%DdO{Y>>y{LM^rTa~E6(vlNH!5}7sbQ9sOzsqF2Hf&TvN zEg#=({2$Rj(wg#OkM)VRRd40xvZqsS`)?{V`?~7gwfHMcCMTw_uojc==f8A#ZWjxM z^qrTQ^hM`CxBJGu3N!V~q>Fg|xm+grbA~rDL^3>C`s!2pLPDbbqiP{!k{6HTSHh?- zzCH47^F`AiJt_rT5{`+sJu5ejZxkeE-kuiyE&;?-zd*nw|Wo@Pd%9>+$2+y4p^qRM^YD^U&FeZ;wo@ zo z91OqEx*qnk{>5W3u1|A2`0ZWdtSr1yZS6^){3H?aYzWK6+E7w`(8N71MVJwX^I0` zAJ6dX%I{=-EH@{QM3ml+&*j6Q70XyMSKyVEgd_c!#=?Yf3xDgPP!#Ii_97ODs7qA0 zNxU`X@33$8u@Gp7i18>2jV_FP(igU|m2|Htlm~lLcrpoka>qR^`Np!G(nVdV{s?A7 z$^h5B_^=x}R*}2ODXC!$52h{|ooSnzgJe}KiCZdLjq!F|%yN>I^3*3a%+?INTP$06v~b_cpHJNo)AwGcTT zMFTx=3vkYVDZ$OJ?L4n#zrAS-v2;cz(u(W#^1GbBUv+m3@}35$bj9Z`B}I$Sg|efp zXR5W{+{85KYR~FhnB?VgHToTLG9Ddg<8~7clugQNAmOmG)X(=*x&6i6@>!4Td>EslYf-YK9_^W6Uw`nI zMVl9v{znFk^w)|NLbLotjRo*HVR4niYA5$mu(u0K$+&V=>UkmOZdSx1K#Lul0S#?c zbaCC*`J!O`^H5<970@eR`ZOd{d<1&0Rx?yr^@^L5nTt<$Zcu+CPfzhpET{gD!2DGg#VwV<^nkQy!m9boIrk0K4t|H-T~3*hxBC96 zqU=EE?01r&Fj*~ElhA1wk0&EeZhS4&41!x`?~*-=E}5|~^wZt{?-iMo7I;E{)AFn* zI+=od_YJL--g3!*4z41lTyQ{HCvtO&?^Q`4iDJX@f>S)|9@STx3|A+E>$%+o_Nw_# zgsR3b?W!2+^QNUKhw8*#uH^d9HlxcR~So9%fmsVK=Gig^HX@BdUw?AJSh zm>!1vyGNwEAHlhl;_j?HxL0ClsakKcA|Dn}-riL|HC+&sR%V5wb%&RsRZfJ{?S@vYf1CKAj_~_GybJ~rJc>BRLiJQOMe>6 zEN_c#Rg1b}Yu#zfyj{yOv2`{=?AI%kcf8GOgRO6j7`IegZRIfNYTezn=90A=4s7j5 zcI`hS+D}T_PY2uothN6;Z3pmCKx!0-Jp~r|mx3szAcrUn>lCIl3W~3TRjq^FzJoKe zgS)hYcc_DZy+h!v1I^bdtkx-N-${!-B}zM`hB_~;cgmb~V)(k`)VdVxyRJrdDVKJs z4t1%ocWIt=Vfngs)VlTTyY(Zx4NJR?hPsW{yG_r!aeO@%YCV?rJ=T#uwxvCGLp=`b zJ&tER1is$eYQ3)Zz3!2{o~6CsL%qK1y?4)g{rLI<)cS(#`$8i7!b(imXs~5{FpU@SKZEH1i!eX{5CDLKiT7gxYX1jCGjQYp literal 0 HcmV?d00001 diff --git a/Webseiten/Docker - Build, Ship, and Run Any App, Anywhere_files/XDFrame.html b/Webseiten/Docker - Build, Ship, and Run Any App, Anywhere_files/XDFrame.html new file mode 100644 index 0000000..9832f44 --- /dev/null +++ b/Webseiten/Docker - Build, Ship, and Run Any App, Anywhere_files/XDFrame.html @@ -0,0 +1,50 @@ + + + + Marketo Forms 2 Cross Domain request proxy frame + + + + +

This page is used by Marketo Forms 2 to proxy cross domain AJAX requests.

+ + \ No newline at end of file diff --git a/Webseiten/Docker - Build, Ship, and Run Any App, Anywhere_files/affix.js b/Webseiten/Docker - Build, Ship, and Run Any App, Anywhere_files/affix.js new file mode 100644 index 0000000..b1d8d2c --- /dev/null +++ b/Webseiten/Docker - Build, Ship, and Run Any App, Anywhere_files/affix.js @@ -0,0 +1,162 @@ +/* ======================================================================== + * Bootstrap: affix.js v3.3.6 + * http://getbootstrap.com/javascript/#affix + * ======================================================================== + * Copyright 2011-2016 Twitter, Inc. + * Licensed under MIT (https://github.com/twbs/bootstrap/blob/master/LICENSE) + * ======================================================================== */ + + ++function ($) { + 'use strict'; + + // AFFIX CLASS DEFINITION + // ====================== + + var Affix = function (element, options) { + this.options = $.extend({}, Affix.DEFAULTS, options) + + this.$target = $(this.options.target) + .on('scroll.bs.affix.data-api', $.proxy(this.checkPosition, this)) + .on('click.bs.affix.data-api', $.proxy(this.checkPositionWithEventLoop, this)) + + this.$element = $(element) + this.affixed = null + this.unpin = null + this.pinnedOffset = null + + this.checkPosition() + } + + Affix.VERSION = '3.3.6' + + Affix.RESET = 'affix affix-top affix-bottom' + + Affix.DEFAULTS = { + offset: 0, + target: window + } + + Affix.prototype.getState = function (scrollHeight, height, offsetTop, offsetBottom) { + var scrollTop = this.$target.scrollTop() + var position = this.$element.offset() + var targetHeight = this.$target.height() + + if (offsetTop != null && this.affixed == 'top') return scrollTop < offsetTop ? 'top' : false + + if (this.affixed == 'bottom') { + if (offsetTop != null) return (scrollTop + this.unpin <= position.top) ? false : 'bottom' + return (scrollTop + targetHeight <= scrollHeight - offsetBottom) ? false : 'bottom' + } + + var initializing = this.affixed == null + var colliderTop = initializing ? scrollTop : position.top + var colliderHeight = initializing ? targetHeight : height + + if (offsetTop != null && scrollTop <= offsetTop) return 'top' + if (offsetBottom != null && (colliderTop + colliderHeight >= scrollHeight - offsetBottom)) return 'bottom' + + return false + } + + Affix.prototype.getPinnedOffset = function () { + if (this.pinnedOffset) return this.pinnedOffset + this.$element.removeClass(Affix.RESET).addClass('affix') + var scrollTop = this.$target.scrollTop() + var position = this.$element.offset() + return (this.pinnedOffset = position.top - scrollTop) + } + + Affix.prototype.checkPositionWithEventLoop = function () { + setTimeout($.proxy(this.checkPosition, this), 1) + } + + Affix.prototype.checkPosition = function () { + if (!this.$element.is(':visible')) return + + var height = this.$element.height() + var offset = this.options.offset + var offsetTop = offset.top + var offsetBottom = offset.bottom + var scrollHeight = Math.max($(document).height(), $(document.body).height()) + + if (typeof offset != 'object') offsetBottom = offsetTop = offset + if (typeof offsetTop == 'function') offsetTop = offset.top(this.$element) + if (typeof offsetBottom == 'function') offsetBottom = offset.bottom(this.$element) + + var affix = this.getState(scrollHeight, height, offsetTop, offsetBottom) + + if (this.affixed != affix) { + if (this.unpin != null) this.$element.css('top', '') + + var affixType = 'affix' + (affix ? '-' + affix : '') + var e = $.Event(affixType + '.bs.affix') + + this.$element.trigger(e) + + if (e.isDefaultPrevented()) return + + this.affixed = affix + this.unpin = affix == 'bottom' ? this.getPinnedOffset() : null + + this.$element + .removeClass(Affix.RESET) + .addClass(affixType) + .trigger(affixType.replace('affix', 'affixed') + '.bs.affix') + } + + if (affix == 'bottom') { + this.$element.offset({ + top: scrollHeight - height - offsetBottom + }) + } + } + + + // AFFIX PLUGIN DEFINITION + // ======================= + + function Plugin(option) { + return this.each(function () { + var $this = $(this) + var data = $this.data('bs.affix') + var options = typeof option == 'object' && option + + if (!data) $this.data('bs.affix', (data = new Affix(this, options))) + if (typeof option == 'string') data[option]() + }) + } + + var old = $.fn.affix + + $.fn.affix = Plugin + $.fn.affix.Constructor = Affix + + + // AFFIX NO CONFLICT + // ================= + + $.fn.affix.noConflict = function () { + $.fn.affix = old + return this + } + + + // AFFIX DATA-API + // ============== + + $(window).on('load', function () { + $('[data-spy="affix"]').each(function () { + var $spy = $(this) + var data = $spy.data() + + data.offset = data.offset || {} + + if (data.offsetBottom != null) data.offset.bottom = data.offsetBottom + if (data.offsetTop != null) data.offset.top = data.offsetTop + + Plugin.call($spy, data) + }) + }) + +}(jQuery); diff --git a/Webseiten/Docker - Build, Ship, and Run Any App, Anywhere_files/agility_0.png b/Webseiten/Docker - Build, Ship, and Run Any App, Anywhere_files/agility_0.png new file mode 100644 index 0000000000000000000000000000000000000000..ed121f129a7390e5ed20db0be45752977ec1716f GIT binary patch literal 1199 zcmV;g1W@~lP)ZC;oB(tJn-f4zAUJ`^CR>RUSgy+6@-jQ!Aem0yP+h}(q(L%X&{b28qfx8h zyzVzW<6iG#7wg3OZ8`e-^Y=*npm8fkD8|4rwGg8cV=qSj>)WUN>_8CwM2sR|=@H01AiCRa7YyRTqVmudyx>mjDB79+yp3M*_(C&=a#OCRUT8hj9oQvk9ml#*sg zbNd>_kccU$S&iD+K=Uh4m6Cf2eXnBvOY!^AvdA&dlq<#Wib-tZ08xRl-H9qyN`=Cz zui!t@OkV;LGU!9Na;Yw1>_k!0uWp?L2SHq=UI;L+Z>l zop+^aXl1io1Pa=@MP)+eY|^!@9G&-^#~vu{a-?aOOLh+%o*})~s_f!;JJ22m#Y4L7 z`y)nXDZFEzbHP%3rLL=RQzs*~dCW>e1tVe3fsW*)oCQ)I1@x49lSODbZI$c}E zrd}&ywUG8cp7Dd)%-A%7N=erk$J39(#+2=4i7Ei5zmM>%nps+1=WG-8MdE zO.column,.row.collapse>.columns{padding-left:0;padding-right:0}.row.collapse .row{margin-left:0;margin-right:0}.row .row{margin:0 -0.9375rem;max-width:none;width:auto}.row .row:before,.row .row:after{content:" ";display:table}.row .row:after{clear:both}.row .row.collapse{margin:0;max-width:none;width:auto}.row .row.collapse:before,.row .row.collapse:after{content:" ";display:table}.row .row.collapse:after{clear:both}.column,.columns{padding-left:0.9375rem;padding-right:0.9375rem;width:100%;float:left}.column+.column:last-child,.columns+.column:last-child,.column+.columns:last-child,.columns+.columns:last-child{float:right}.column+.column.end,.columns+.column.end,.column+.columns.end,.columns+.columns.end{float:left}@media only screen{.small-push-0{position:relative;left:0;right:auto}.small-pull-0{position:relative;right:0;left:auto}.small-push-1{position:relative;left:8.33333%;right:auto}.small-pull-1{position:relative;right:8.33333%;left:auto}.small-push-2{position:relative;left:16.66667%;right:auto}.small-pull-2{position:relative;right:16.66667%;left:auto}.small-push-3{position:relative;left:25%;right:auto}.small-pull-3{position:relative;right:25%;left:auto}.small-push-4{position:relative;left:33.33333%;right:auto}.small-pull-4{position:relative;right:33.33333%;left:auto}.small-push-5{position:relative;left:41.66667%;right:auto}.small-pull-5{position:relative;right:41.66667%;left:auto}.small-push-6{position:relative;left:50%;right:auto}.small-pull-6{position:relative;right:50%;left:auto}.small-push-7{position:relative;left:58.33333%;right:auto}.small-pull-7{position:relative;right:58.33333%;left:auto}.small-push-8{position:relative;left:66.66667%;right:auto}.small-pull-8{position:relative;right:66.66667%;left:auto}.small-push-9{position:relative;left:75%;right:auto}.small-pull-9{position:relative;right:75%;left:auto}.small-push-10{position:relative;left:83.33333%;right:auto}.small-pull-10{position:relative;right:83.33333%;left:auto}.small-push-11{position:relative;left:91.66667%;right:auto}.small-pull-11{position:relative;right:91.66667%;left:auto}.column,.columns{position:relative;padding-left:0.9375rem;padding-right:0.9375rem;float:left}.small-1{width:8.33333%}.small-2{width:16.66667%}.small-3{width:25%}.small-4{width:33.33333%}.small-5{width:41.66667%}.small-6{width:50%}.small-7{width:58.33333%}.small-8{width:66.66667%}.small-9{width:75%}.small-10{width:83.33333%}.small-11{width:91.66667%}.small-12{width:100%}.small-offset-0{margin-left:0 !important}.small-offset-1{margin-left:8.33333% !important}.small-offset-2{margin-left:16.66667% !important}.small-offset-3{margin-left:25% !important}.small-offset-4{margin-left:33.33333% !important}.small-offset-5{margin-left:41.66667% !important}.small-offset-6{margin-left:50% !important}.small-offset-7{margin-left:58.33333% !important}.small-offset-8{margin-left:66.66667% !important}.small-offset-9{margin-left:75% !important}.small-offset-10{margin-left:83.33333% !important}.small-offset-11{margin-left:91.66667% !important}.small-reset-order{float:left;left:auto;margin-left:0;margin-right:0;right:auto}.column.small-centered,.columns.small-centered{margin-left:auto;margin-right:auto;float:none}.column.small-uncentered,.columns.small-uncentered{float:left;margin-left:0;margin-right:0}.column.small-centered:last-child,.columns.small-centered:last-child{float:none}.column.small-uncentered:last-child,.columns.small-uncentered:last-child{float:left}.column.small-uncentered.opposite,.columns.small-uncentered.opposite{float:right}.row.small-collapse>.column,.row.small-collapse>.columns{padding-left:0;padding-right:0}.row.small-collapse .row{margin-left:0;margin-right:0}.row.small-uncollapse>.column,.row.small-uncollapse>.columns{padding-left:0.9375rem;padding-right:0.9375rem;float:left}}@media only screen and (min-width: 40.0625em){.medium-push-0{position:relative;left:0;right:auto}.medium-pull-0{position:relative;right:0;left:auto}.medium-push-1{position:relative;left:8.33333%;right:auto}.medium-pull-1{position:relative;right:8.33333%;left:auto}.medium-push-2{position:relative;left:16.66667%;right:auto}.medium-pull-2{position:relative;right:16.66667%;left:auto}.medium-push-3{position:relative;left:25%;right:auto}.medium-pull-3{position:relative;right:25%;left:auto}.medium-push-4{position:relative;left:33.33333%;right:auto}.medium-pull-4{position:relative;right:33.33333%;left:auto}.medium-push-5{position:relative;left:41.66667%;right:auto}.medium-pull-5{position:relative;right:41.66667%;left:auto}.medium-push-6{position:relative;left:50%;right:auto}.medium-pull-6{position:relative;right:50%;left:auto}.medium-push-7{position:relative;left:58.33333%;right:auto}.medium-pull-7{position:relative;right:58.33333%;left:auto}.medium-push-8{position:relative;left:66.66667%;right:auto}.medium-pull-8{position:relative;right:66.66667%;left:auto}.medium-push-9{position:relative;left:75%;right:auto}.medium-pull-9{position:relative;right:75%;left:auto}.medium-push-10{position:relative;left:83.33333%;right:auto}.medium-pull-10{position:relative;right:83.33333%;left:auto}.medium-push-11{position:relative;left:91.66667%;right:auto}.medium-pull-11{position:relative;right:91.66667%;left:auto}.column,.columns{position:relative;padding-left:0.9375rem;padding-right:0.9375rem;float:left}.medium-1{width:8.33333%}.medium-2{width:16.66667%}.medium-3{width:25%}.medium-4{width:33.33333%}.medium-5{width:41.66667%}.medium-6{width:50%}.medium-7{width:58.33333%}.medium-8{width:66.66667%}.medium-9{width:75%}.medium-10{width:83.33333%}.medium-11{width:91.66667%}.medium-12{width:100%}.medium-offset-0{margin-left:0 !important}.medium-offset-1{margin-left:8.33333% !important}.medium-offset-2{margin-left:16.66667% !important}.medium-offset-3{margin-left:25% !important}.medium-offset-4{margin-left:33.33333% !important}.medium-offset-5{margin-left:41.66667% !important}.medium-offset-6{margin-left:50% !important}.medium-offset-7{margin-left:58.33333% !important}.medium-offset-8{margin-left:66.66667% !important}.medium-offset-9{margin-left:75% !important}.medium-offset-10{margin-left:83.33333% !important}.medium-offset-11{margin-left:91.66667% !important}.medium-reset-order{float:left;left:auto;margin-left:0;margin-right:0;right:auto}.column.medium-centered,.columns.medium-centered{margin-left:auto;margin-right:auto;float:none}.column.medium-uncentered,.columns.medium-uncentered{float:left;margin-left:0;margin-right:0}.column.medium-centered:last-child,.columns.medium-centered:last-child{float:none}.column.medium-uncentered:last-child,.columns.medium-uncentered:last-child{float:left}.column.medium-uncentered.opposite,.columns.medium-uncentered.opposite{float:right}.row.medium-collapse>.column,.row.medium-collapse>.columns{padding-left:0;padding-right:0}.row.medium-collapse .row{margin-left:0;margin-right:0}.row.medium-uncollapse>.column,.row.medium-uncollapse>.columns{padding-left:0.9375rem;padding-right:0.9375rem;float:left}.push-0{position:relative;left:0;right:auto}.pull-0{position:relative;right:0;left:auto}.push-1{position:relative;left:8.33333%;right:auto}.pull-1{position:relative;right:8.33333%;left:auto}.push-2{position:relative;left:16.66667%;right:auto}.pull-2{position:relative;right:16.66667%;left:auto}.push-3{position:relative;left:25%;right:auto}.pull-3{position:relative;right:25%;left:auto}.push-4{position:relative;left:33.33333%;right:auto}.pull-4{position:relative;right:33.33333%;left:auto}.push-5{position:relative;left:41.66667%;right:auto}.pull-5{position:relative;right:41.66667%;left:auto}.push-6{position:relative;left:50%;right:auto}.pull-6{position:relative;right:50%;left:auto}.push-7{position:relative;left:58.33333%;right:auto}.pull-7{position:relative;right:58.33333%;left:auto}.push-8{position:relative;left:66.66667%;right:auto}.pull-8{position:relative;right:66.66667%;left:auto}.push-9{position:relative;left:75%;right:auto}.pull-9{position:relative;right:75%;left:auto}.push-10{position:relative;left:83.33333%;right:auto}.pull-10{position:relative;right:83.33333%;left:auto}.push-11{position:relative;left:91.66667%;right:auto}.pull-11{position:relative;right:91.66667%;left:auto}}@media only screen and (min-width: 58.8125em){.large-push-0{position:relative;left:0;right:auto}.large-pull-0{position:relative;right:0;left:auto}.large-push-1{position:relative;left:8.33333%;right:auto}.large-pull-1{position:relative;right:8.33333%;left:auto}.large-push-2{position:relative;left:16.66667%;right:auto}.large-pull-2{position:relative;right:16.66667%;left:auto}.large-push-3{position:relative;left:25%;right:auto}.large-pull-3{position:relative;right:25%;left:auto}.large-push-4{position:relative;left:33.33333%;right:auto}.large-pull-4{position:relative;right:33.33333%;left:auto}.large-push-5{position:relative;left:41.66667%;right:auto}.large-pull-5{position:relative;right:41.66667%;left:auto}.large-push-6{position:relative;left:50%;right:auto}.large-pull-6{position:relative;right:50%;left:auto}.large-push-7{position:relative;left:58.33333%;right:auto}.large-pull-7{position:relative;right:58.33333%;left:auto}.large-push-8{position:relative;left:66.66667%;right:auto}.large-pull-8{position:relative;right:66.66667%;left:auto}.large-push-9{position:relative;left:75%;right:auto}.large-pull-9{position:relative;right:75%;left:auto}.large-push-10{position:relative;left:83.33333%;right:auto}.large-pull-10{position:relative;right:83.33333%;left:auto}.large-push-11{position:relative;left:91.66667%;right:auto}.large-pull-11{position:relative;right:91.66667%;left:auto}.column,.columns{position:relative;padding-left:0.9375rem;padding-right:0.9375rem;float:left}.large-1{width:8.33333%}.large-2{width:16.66667%}.large-3{width:25%}.large-4{width:33.33333%}.large-5{width:41.66667%}.large-6{width:50%}.large-7{width:58.33333%}.large-8{width:66.66667%}.large-9{width:75%}.large-10{width:83.33333%}.large-11{width:91.66667%}.large-12{width:100%}.large-offset-0{margin-left:0 !important}.large-offset-1{margin-left:8.33333% !important}.large-offset-2{margin-left:16.66667% !important}.large-offset-3{margin-left:25% !important}.large-offset-4{margin-left:33.33333% !important}.large-offset-5{margin-left:41.66667% !important}.large-offset-6{margin-left:50% !important}.large-offset-7{margin-left:58.33333% !important}.large-offset-8{margin-left:66.66667% !important}.large-offset-9{margin-left:75% !important}.large-offset-10{margin-left:83.33333% !important}.large-offset-11{margin-left:91.66667% !important}.large-reset-order{float:left;left:auto;margin-left:0;margin-right:0;right:auto}.column.large-centered,.columns.large-centered{margin-left:auto;margin-right:auto;float:none}.column.large-uncentered,.columns.large-uncentered{float:left;margin-left:0;margin-right:0}.column.large-centered:last-child,.columns.large-centered:last-child{float:none}.column.large-uncentered:last-child,.columns.large-uncentered:last-child{float:left}.column.large-uncentered.opposite,.columns.large-uncentered.opposite{float:right}.row.large-collapse>.column,.row.large-collapse>.columns{padding-left:0;padding-right:0}.row.large-collapse .row{margin-left:0;margin-right:0}.row.large-uncollapse>.column,.row.large-uncollapse>.columns{padding-left:0.9375rem;padding-right:0.9375rem;float:left}.push-0{position:relative;left:0;right:auto}.pull-0{position:relative;right:0;left:auto}.push-1{position:relative;left:8.33333%;right:auto}.pull-1{position:relative;right:8.33333%;left:auto}.push-2{position:relative;left:16.66667%;right:auto}.pull-2{position:relative;right:16.66667%;left:auto}.push-3{position:relative;left:25%;right:auto}.pull-3{position:relative;right:25%;left:auto}.push-4{position:relative;left:33.33333%;right:auto}.pull-4{position:relative;right:33.33333%;left:auto}.push-5{position:relative;left:41.66667%;right:auto}.pull-5{position:relative;right:41.66667%;left:auto}.push-6{position:relative;left:50%;right:auto}.pull-6{position:relative;right:50%;left:auto}.push-7{position:relative;left:58.33333%;right:auto}.pull-7{position:relative;right:58.33333%;left:auto}.push-8{position:relative;left:66.66667%;right:auto}.pull-8{position:relative;right:66.66667%;left:auto}.push-9{position:relative;left:75%;right:auto}.pull-9{position:relative;right:75%;left:auto}.push-10{position:relative;left:83.33333%;right:auto}.pull-10{position:relative;right:83.33333%;left:auto}.push-11{position:relative;left:91.66667%;right:auto}.pull-11{position:relative;right:91.66667%;left:auto}}.accordion{margin-bottom:0}.accordion:before,.accordion:after{content:" ";display:table}.accordion:after{clear:both}.accordion .accordion-navigation,.accordion dd{display:block;margin-bottom:0 !important}.accordion .accordion-navigation.active>a,.accordion dd.active>a{background:#e8e8e8}.accordion .accordion-navigation>a,.accordion dd>a{background:#EFEFEF;color:#222;display:block;font-family:"Helvetica Neue",Helvetica,Roboto,Arial,sans-serif;font-size:1rem;padding:1rem}.accordion .accordion-navigation>a:hover,.accordion dd>a:hover{background:#e3e3e3}.accordion .accordion-navigation>.content,.accordion dd>.content{display:none;padding:0.9375rem}.accordion .accordion-navigation>.content.active,.accordion dd>.content.active{background:#fff;display:block}.alert-box{border-style:solid;border-width:1px;display:block;font-size:0.8125rem;font-weight:normal;margin-bottom:1.25rem;padding:0.875rem 1.5rem 0.875rem 0.875rem;position:relative;transition:opacity 300ms ease-out;background-color:#22b8eb;border-color:#13a3d4;color:#fff}.alert-box .close{right:0.25rem;background:inherit;color:#333;font-size:1.375rem;line-height:.9;margin-top:-0.6875rem;opacity:0.3;padding:0 6px 4px;position:absolute;top:50%}.alert-box .close:hover,.alert-box .close:focus{opacity:0.5}.alert-box.radius{border-radius:5px}.alert-box.round{border-radius:1000px}.alert-box.success{background-color:#43AC6A;border-color:#3a945b;color:#fff}.alert-box.alert{background-color:#f04124;border-color:#de2d0f;color:#fff}.alert-box.secondary{background-color:#FF992E;border-color:#ff8404;color:#fff}.alert-box.warning{background-color:#f08a24;border-color:#de770f;color:#fff}.alert-box.info{background-color:#a0d3e8;border-color:#74bfdd;color:#663400}.alert-box.alert-close{opacity:0}[class*="block-grid-"]{display:block;padding:0;margin:0 -0.625rem}[class*="block-grid-"]:before,[class*="block-grid-"]:after{content:" ";display:table}[class*="block-grid-"]:after{clear:both}[class*="block-grid-"]>li{display:block;float:left;height:auto;padding:0 0.625rem 1.25rem}@media only screen{.small-block-grid-1>li{list-style:none;width:100%}.small-block-grid-1>li:nth-of-type(1n){clear:none}.small-block-grid-1>li:nth-of-type(1n+1){clear:both}.small-block-grid-2>li{list-style:none;width:50%}.small-block-grid-2>li:nth-of-type(1n){clear:none}.small-block-grid-2>li:nth-of-type(2n+1){clear:both}.small-block-grid-3>li{list-style:none;width:33.33333%}.small-block-grid-3>li:nth-of-type(1n){clear:none}.small-block-grid-3>li:nth-of-type(3n+1){clear:both}.small-block-grid-4>li{list-style:none;width:25%}.small-block-grid-4>li:nth-of-type(1n){clear:none}.small-block-grid-4>li:nth-of-type(4n+1){clear:both}.small-block-grid-5>li{list-style:none;width:20%}.small-block-grid-5>li:nth-of-type(1n){clear:none}.small-block-grid-5>li:nth-of-type(5n+1){clear:both}.small-block-grid-6>li{list-style:none;width:16.66667%}.small-block-grid-6>li:nth-of-type(1n){clear:none}.small-block-grid-6>li:nth-of-type(6n+1){clear:both}.small-block-grid-7>li{list-style:none;width:14.28571%}.small-block-grid-7>li:nth-of-type(1n){clear:none}.small-block-grid-7>li:nth-of-type(7n+1){clear:both}.small-block-grid-8>li{list-style:none;width:12.5%}.small-block-grid-8>li:nth-of-type(1n){clear:none}.small-block-grid-8>li:nth-of-type(8n+1){clear:both}.small-block-grid-9>li{list-style:none;width:11.11111%}.small-block-grid-9>li:nth-of-type(1n){clear:none}.small-block-grid-9>li:nth-of-type(9n+1){clear:both}.small-block-grid-10>li{list-style:none;width:10%}.small-block-grid-10>li:nth-of-type(1n){clear:none}.small-block-grid-10>li:nth-of-type(10n+1){clear:both}.small-block-grid-11>li{list-style:none;width:9.09091%}.small-block-grid-11>li:nth-of-type(1n){clear:none}.small-block-grid-11>li:nth-of-type(11n+1){clear:both}.small-block-grid-12>li{list-style:none;width:8.33333%}.small-block-grid-12>li:nth-of-type(1n){clear:none}.small-block-grid-12>li:nth-of-type(12n+1){clear:both}}@media only screen and (min-width: 40.0625em){.medium-block-grid-1>li{list-style:none;width:100%}.medium-block-grid-1>li:nth-of-type(1n){clear:none}.medium-block-grid-1>li:nth-of-type(1n+1){clear:both}.medium-block-grid-2>li{list-style:none;width:50%}.medium-block-grid-2>li:nth-of-type(1n){clear:none}.medium-block-grid-2>li:nth-of-type(2n+1){clear:both}.medium-block-grid-3>li{list-style:none;width:33.33333%}.medium-block-grid-3>li:nth-of-type(1n){clear:none}.medium-block-grid-3>li:nth-of-type(3n+1){clear:both}.medium-block-grid-4>li{list-style:none;width:25%}.medium-block-grid-4>li:nth-of-type(1n){clear:none}.medium-block-grid-4>li:nth-of-type(4n+1){clear:both}.medium-block-grid-5>li{list-style:none;width:20%}.medium-block-grid-5>li:nth-of-type(1n){clear:none}.medium-block-grid-5>li:nth-of-type(5n+1){clear:both}.medium-block-grid-6>li{list-style:none;width:16.66667%}.medium-block-grid-6>li:nth-of-type(1n){clear:none}.medium-block-grid-6>li:nth-of-type(6n+1){clear:both}.medium-block-grid-7>li{list-style:none;width:14.28571%}.medium-block-grid-7>li:nth-of-type(1n){clear:none}.medium-block-grid-7>li:nth-of-type(7n+1){clear:both}.medium-block-grid-8>li{list-style:none;width:12.5%}.medium-block-grid-8>li:nth-of-type(1n){clear:none}.medium-block-grid-8>li:nth-of-type(8n+1){clear:both}.medium-block-grid-9>li{list-style:none;width:11.11111%}.medium-block-grid-9>li:nth-of-type(1n){clear:none}.medium-block-grid-9>li:nth-of-type(9n+1){clear:both}.medium-block-grid-10>li{list-style:none;width:10%}.medium-block-grid-10>li:nth-of-type(1n){clear:none}.medium-block-grid-10>li:nth-of-type(10n+1){clear:both}.medium-block-grid-11>li{list-style:none;width:9.09091%}.medium-block-grid-11>li:nth-of-type(1n){clear:none}.medium-block-grid-11>li:nth-of-type(11n+1){clear:both}.medium-block-grid-12>li{list-style:none;width:8.33333%}.medium-block-grid-12>li:nth-of-type(1n){clear:none}.medium-block-grid-12>li:nth-of-type(12n+1){clear:both}}@media only screen and (min-width: 58.8125em){.large-block-grid-1>li{list-style:none;width:100%}.large-block-grid-1>li:nth-of-type(1n){clear:none}.large-block-grid-1>li:nth-of-type(1n+1){clear:both}.large-block-grid-2>li{list-style:none;width:50%}.large-block-grid-2>li:nth-of-type(1n){clear:none}.large-block-grid-2>li:nth-of-type(2n+1){clear:both}.large-block-grid-3>li{list-style:none;width:33.33333%}.large-block-grid-3>li:nth-of-type(1n){clear:none}.large-block-grid-3>li:nth-of-type(3n+1){clear:both}.large-block-grid-4>li{list-style:none;width:25%}.large-block-grid-4>li:nth-of-type(1n){clear:none}.large-block-grid-4>li:nth-of-type(4n+1){clear:both}.large-block-grid-5>li{list-style:none;width:20%}.large-block-grid-5>li:nth-of-type(1n){clear:none}.large-block-grid-5>li:nth-of-type(5n+1){clear:both}.large-block-grid-6>li{list-style:none;width:16.66667%}.large-block-grid-6>li:nth-of-type(1n){clear:none}.large-block-grid-6>li:nth-of-type(6n+1){clear:both}.large-block-grid-7>li{list-style:none;width:14.28571%}.large-block-grid-7>li:nth-of-type(1n){clear:none}.large-block-grid-7>li:nth-of-type(7n+1){clear:both}.large-block-grid-8>li{list-style:none;width:12.5%}.large-block-grid-8>li:nth-of-type(1n){clear:none}.large-block-grid-8>li:nth-of-type(8n+1){clear:both}.large-block-grid-9>li{list-style:none;width:11.11111%}.large-block-grid-9>li:nth-of-type(1n){clear:none}.large-block-grid-9>li:nth-of-type(9n+1){clear:both}.large-block-grid-10>li{list-style:none;width:10%}.large-block-grid-10>li:nth-of-type(1n){clear:none}.large-block-grid-10>li:nth-of-type(10n+1){clear:both}.large-block-grid-11>li{list-style:none;width:9.09091%}.large-block-grid-11>li:nth-of-type(1n){clear:none}.large-block-grid-11>li:nth-of-type(11n+1){clear:both}.large-block-grid-12>li{list-style:none;width:8.33333%}.large-block-grid-12>li:nth-of-type(1n){clear:none}.large-block-grid-12>li:nth-of-type(12n+1){clear:both}}.breadcrumbs{border-style:solid;border-width:1px;display:block;list-style:none;margin-left:0;overflow:hidden;padding:0.5625rem 0.875rem 0.5625rem;background-color:#ffd1a1;border-color:#ffbd77;border-radius:5px}.breadcrumbs>*{color:#22b8eb;float:left;font-size:0.6875rem;line-height:0.6875rem;margin:0;text-transform:uppercase}.breadcrumbs>*:hover a,.breadcrumbs>*:focus a{text-decoration:underline}.breadcrumbs>* a{color:#22b8eb}.breadcrumbs>*.current{color:#333;cursor:default}.breadcrumbs>*.current a{color:#333;cursor:default}.breadcrumbs>*.current:hover,.breadcrumbs>*.current:hover a,.breadcrumbs>*.current:focus,.breadcrumbs>*.current:focus a{text-decoration:none}.breadcrumbs>*.unavailable{color:#999}.breadcrumbs>*.unavailable a{color:#999}.breadcrumbs>*.unavailable:hover,.breadcrumbs>*.unavailable:hover a,.breadcrumbs>*.unavailable:focus,.breadcrumbs>*.unavailable a:focus{color:#999;cursor:not-allowed;text-decoration:none}.breadcrumbs>*:before{color:#aaa;content:"/";margin:0 0.75rem;position:relative;top:1px}.breadcrumbs>*:first-child:before{content:" ";margin:0}[aria-label="breadcrumbs"] [aria-hidden="true"]:after{content:"/"}button,.button{-webkit-appearance:none;-moz-appearance:none;border-radius:0;border-style:solid;border-width:0;cursor:pointer;font-family:"Helvetica Neue",Helvetica,Roboto,Arial,sans-serif;font-weight:normal;line-height:normal;margin:0 0 1.25rem;position:relative;text-align:center;text-decoration:none;display:inline-block;padding:1rem 2rem 1.0625rem 2rem;font-size:1rem;background-color:#22b8eb;border-color:#1298c5;color:#fff;transition:background-color 300ms ease-out}button:hover,button:focus,.button:hover,.button:focus{background-color:#1298c5}button:hover,button:focus,.button:hover,.button:focus{color:#fff}button.secondary,.button.secondary{background-color:#FF992E;border-color:#f17b00;color:#fff}button.secondary:hover,button.secondary:focus,.button.secondary:hover,.button.secondary:focus{background-color:#f17b00}button.secondary:hover,button.secondary:focus,.button.secondary:hover,.button.secondary:focus{color:#fff}button.success,.button.success{background-color:#43AC6A;border-color:#368a55;color:#fff}button.success:hover,button.success:focus,.button.success:hover,.button.success:focus{background-color:#368a55}button.success:hover,button.success:focus,.button.success:hover,.button.success:focus{color:#fff}button.alert,.button.alert{background-color:#f04124;border-color:#cf2a0e;color:#fff}button.alert:hover,button.alert:focus,.button.alert:hover,.button.alert:focus{background-color:#cf2a0e}button.alert:hover,button.alert:focus,.button.alert:hover,.button.alert:focus{color:#fff}button.warning,.button.warning{background-color:#f08a24;border-color:#cf6e0e;color:#fff}button.warning:hover,button.warning:focus,.button.warning:hover,.button.warning:focus{background-color:#cf6e0e}button.warning:hover,button.warning:focus,.button.warning:hover,.button.warning:focus{color:#fff}button.info,.button.info{background-color:#a0d3e8;border-color:#61b6d9;color:#333}button.info:hover,button.info:focus,.button.info:hover,.button.info:focus{background-color:#61b6d9}button.info:hover,button.info:focus,.button.info:hover,.button.info:focus{color:#fff}button.large,.button.large{padding:1.125rem 2.25rem 1.1875rem 2.25rem;font-size:1.25rem}button.small,.button.small{padding:0.875rem 1.75rem 0.9375rem 1.75rem;font-size:0.8125rem}button.tiny,.button.tiny{padding:0.625rem 1.25rem 0.6875rem 1.25rem;font-size:0.6875rem}button.expand,.button.expand{padding-left:0;padding-right:0;width:100%}button.left-align,.button.left-align{text-align:left;text-indent:0.75rem}button.right-align,.button.right-align{text-align:right;padding-right:0.75rem}button.radius,.button.radius{border-radius:5px}button.round,.button.round{border-radius:1000px}button.disabled,button[disabled],.button.disabled,.button[disabled]{background-color:#22b8eb;border-color:#1298c5;color:#fff;box-shadow:none;cursor:default;opacity:0.7}button.disabled:hover,button.disabled:focus,button[disabled]:hover,button[disabled]:focus,.button.disabled:hover,.button.disabled:focus,.button[disabled]:hover,.button[disabled]:focus{background-color:#1298c5}button.disabled:hover,button.disabled:focus,button[disabled]:hover,button[disabled]:focus,.button.disabled:hover,.button.disabled:focus,.button[disabled]:hover,.button[disabled]:focus{color:#fff}button.disabled:hover,button.disabled:focus,button[disabled]:hover,button[disabled]:focus,.button.disabled:hover,.button.disabled:focus,.button[disabled]:hover,.button[disabled]:focus{background-color:#22b8eb}button.disabled.secondary,button[disabled].secondary,.button.disabled.secondary,.button[disabled].secondary{background-color:#FF992E;border-color:#f17b00;color:#fff;box-shadow:none;cursor:default;opacity:0.7}button.disabled.secondary:hover,button.disabled.secondary:focus,button[disabled].secondary:hover,button[disabled].secondary:focus,.button.disabled.secondary:hover,.button.disabled.secondary:focus,.button[disabled].secondary:hover,.button[disabled].secondary:focus{background-color:#f17b00}button.disabled.secondary:hover,button.disabled.secondary:focus,button[disabled].secondary:hover,button[disabled].secondary:focus,.button.disabled.secondary:hover,.button.disabled.secondary:focus,.button[disabled].secondary:hover,.button[disabled].secondary:focus{color:#fff}button.disabled.secondary:hover,button.disabled.secondary:focus,button[disabled].secondary:hover,button[disabled].secondary:focus,.button.disabled.secondary:hover,.button.disabled.secondary:focus,.button[disabled].secondary:hover,.button[disabled].secondary:focus{background-color:#FF992E}button.disabled.success,button[disabled].success,.button.disabled.success,.button[disabled].success{background-color:#43AC6A;border-color:#368a55;color:#fff;box-shadow:none;cursor:default;opacity:0.7}button.disabled.success:hover,button.disabled.success:focus,button[disabled].success:hover,button[disabled].success:focus,.button.disabled.success:hover,.button.disabled.success:focus,.button[disabled].success:hover,.button[disabled].success:focus{background-color:#368a55}button.disabled.success:hover,button.disabled.success:focus,button[disabled].success:hover,button[disabled].success:focus,.button.disabled.success:hover,.button.disabled.success:focus,.button[disabled].success:hover,.button[disabled].success:focus{color:#fff}button.disabled.success:hover,button.disabled.success:focus,button[disabled].success:hover,button[disabled].success:focus,.button.disabled.success:hover,.button.disabled.success:focus,.button[disabled].success:hover,.button[disabled].success:focus{background-color:#43AC6A}button.disabled.alert,button[disabled].alert,.button.disabled.alert,.button[disabled].alert{background-color:#f04124;border-color:#cf2a0e;color:#fff;box-shadow:none;cursor:default;opacity:0.7}button.disabled.alert:hover,button.disabled.alert:focus,button[disabled].alert:hover,button[disabled].alert:focus,.button.disabled.alert:hover,.button.disabled.alert:focus,.button[disabled].alert:hover,.button[disabled].alert:focus{background-color:#cf2a0e}button.disabled.alert:hover,button.disabled.alert:focus,button[disabled].alert:hover,button[disabled].alert:focus,.button.disabled.alert:hover,.button.disabled.alert:focus,.button[disabled].alert:hover,.button[disabled].alert:focus{color:#fff}button.disabled.alert:hover,button.disabled.alert:focus,button[disabled].alert:hover,button[disabled].alert:focus,.button.disabled.alert:hover,.button.disabled.alert:focus,.button[disabled].alert:hover,.button[disabled].alert:focus{background-color:#f04124}button.disabled.warning,button[disabled].warning,.button.disabled.warning,.button[disabled].warning{background-color:#f08a24;border-color:#cf6e0e;color:#fff;box-shadow:none;cursor:default;opacity:0.7}button.disabled.warning:hover,button.disabled.warning:focus,button[disabled].warning:hover,button[disabled].warning:focus,.button.disabled.warning:hover,.button.disabled.warning:focus,.button[disabled].warning:hover,.button[disabled].warning:focus{background-color:#cf6e0e}button.disabled.warning:hover,button.disabled.warning:focus,button[disabled].warning:hover,button[disabled].warning:focus,.button.disabled.warning:hover,.button.disabled.warning:focus,.button[disabled].warning:hover,.button[disabled].warning:focus{color:#fff}button.disabled.warning:hover,button.disabled.warning:focus,button[disabled].warning:hover,button[disabled].warning:focus,.button.disabled.warning:hover,.button.disabled.warning:focus,.button[disabled].warning:hover,.button[disabled].warning:focus{background-color:#f08a24}button.disabled.info,button[disabled].info,.button.disabled.info,.button[disabled].info{background-color:#a0d3e8;border-color:#61b6d9;color:#333;box-shadow:none;cursor:default;opacity:0.7}button.disabled.info:hover,button.disabled.info:focus,button[disabled].info:hover,button[disabled].info:focus,.button.disabled.info:hover,.button.disabled.info:focus,.button[disabled].info:hover,.button[disabled].info:focus{background-color:#61b6d9}button.disabled.info:hover,button.disabled.info:focus,button[disabled].info:hover,button[disabled].info:focus,.button.disabled.info:hover,.button.disabled.info:focus,.button[disabled].info:hover,.button[disabled].info:focus{color:#fff}button.disabled.info:hover,button.disabled.info:focus,button[disabled].info:hover,button[disabled].info:focus,.button.disabled.info:hover,.button.disabled.info:focus,.button[disabled].info:hover,.button[disabled].info:focus{background-color:#a0d3e8}button::-moz-focus-inner{border:0;padding:0}@media only screen and (min-width: 40.0625em){button,.button{display:inline-block}}.button-group{list-style:none;margin:0;left:0}.button-group:before,.button-group:after{content:" ";display:table}.button-group:after{clear:both}.button-group.even-2 li{display:inline-block;margin:0 -2px;width:50%}.button-group.even-2 li>button,.button-group.even-2 li .button{border-left:1px solid;border-color:rgba(255,255,255,0.5)}.button-group.even-2 li:first-child button,.button-group.even-2 li:first-child .button{border-left:0}.button-group.even-2 li button,.button-group.even-2 li .button{width:100%}.button-group.even-3 li{display:inline-block;margin:0 -2px;width:33.33333%}.button-group.even-3 li>button,.button-group.even-3 li .button{border-left:1px solid;border-color:rgba(255,255,255,0.5)}.button-group.even-3 li:first-child button,.button-group.even-3 li:first-child .button{border-left:0}.button-group.even-3 li button,.button-group.even-3 li .button{width:100%}.button-group.even-4 li{display:inline-block;margin:0 -2px;width:25%}.button-group.even-4 li>button,.button-group.even-4 li .button{border-left:1px solid;border-color:rgba(255,255,255,0.5)}.button-group.even-4 li:first-child button,.button-group.even-4 li:first-child .button{border-left:0}.button-group.even-4 li button,.button-group.even-4 li .button{width:100%}.button-group.even-5 li{display:inline-block;margin:0 -2px;width:20%}.button-group.even-5 li>button,.button-group.even-5 li .button{border-left:1px solid;border-color:rgba(255,255,255,0.5)}.button-group.even-5 li:first-child button,.button-group.even-5 li:first-child .button{border-left:0}.button-group.even-5 li button,.button-group.even-5 li .button{width:100%}.button-group.even-6 li{display:inline-block;margin:0 -2px;width:16.66667%}.button-group.even-6 li>button,.button-group.even-6 li .button{border-left:1px solid;border-color:rgba(255,255,255,0.5)}.button-group.even-6 li:first-child button,.button-group.even-6 li:first-child .button{border-left:0}.button-group.even-6 li button,.button-group.even-6 li .button{width:100%}.button-group.even-7 li{display:inline-block;margin:0 -2px;width:14.28571%}.button-group.even-7 li>button,.button-group.even-7 li .button{border-left:1px solid;border-color:rgba(255,255,255,0.5)}.button-group.even-7 li:first-child button,.button-group.even-7 li:first-child .button{border-left:0}.button-group.even-7 li button,.button-group.even-7 li .button{width:100%}.button-group.even-8 li{display:inline-block;margin:0 -2px;width:12.5%}.button-group.even-8 li>button,.button-group.even-8 li .button{border-left:1px solid;border-color:rgba(255,255,255,0.5)}.button-group.even-8 li:first-child button,.button-group.even-8 li:first-child .button{border-left:0}.button-group.even-8 li button,.button-group.even-8 li .button{width:100%}.button-group>li{display:inline-block;margin:0 -2px}.button-group>li>button,.button-group>li .button{border-left:1px solid;border-color:rgba(255,255,255,0.5)}.button-group>li:first-child button,.button-group>li:first-child .button{border-left:0}.button-group.stack>li{display:block;margin:0;float:none}.button-group.stack>li>button,.button-group.stack>li .button{border-left:1px solid;border-color:rgba(255,255,255,0.5)}.button-group.stack>li:first-child button,.button-group.stack>li:first-child .button{border-left:0}.button-group.stack>li>button,.button-group.stack>li .button{border-color:rgba(255,255,255,0.5);border-left-width:0;border-top:1px solid;display:block;margin:0}.button-group.stack>li>button{width:100%}.button-group.stack>li:first-child button,.button-group.stack>li:first-child .button{border-top:0}.button-group.stack-for-small>li{display:inline-block;margin:0 -2px}.button-group.stack-for-small>li>button,.button-group.stack-for-small>li .button{border-left:1px solid;border-color:rgba(255,255,255,0.5)}.button-group.stack-for-small>li:first-child button,.button-group.stack-for-small>li:first-child .button{border-left:0}@media only screen and (max-width: 40em){.button-group.stack-for-small>li{display:block;margin:0}.button-group.stack-for-small>li>button,.button-group.stack-for-small>li .button{border-left:1px solid;border-color:rgba(255,255,255,0.5)}.button-group.stack-for-small>li:first-child button,.button-group.stack-for-small>li:first-child .button{border-left:0}.button-group.stack-for-small>li>button,.button-group.stack-for-small>li .button{border-color:rgba(255,255,255,0.5);border-left-width:0;border-top:1px solid;display:block;margin:0}.button-group.stack-for-small>li>button{width:100%}.button-group.stack-for-small>li:first-child button,.button-group.stack-for-small>li:first-child .button{border-top:0}}.button-group.radius>*{display:inline-block;margin:0 -2px}.button-group.radius>*>button,.button-group.radius>* .button{border-left:1px solid;border-color:rgba(255,255,255,0.5)}.button-group.radius>*:first-child button,.button-group.radius>*:first-child .button{border-left:0}.button-group.radius>*,.button-group.radius>*>a,.button-group.radius>*>button,.button-group.radius>*>.button{border-radius:0}.button-group.radius>*:first-child,.button-group.radius>*:first-child>a,.button-group.radius>*:first-child>button,.button-group.radius>*:first-child>.button{-webkit-border-bottom-left-radius:5px;-webkit-border-top-left-radius:5px;border-bottom-left-radius:5px;border-top-left-radius:5px}.button-group.radius>*:last-child,.button-group.radius>*:last-child>a,.button-group.radius>*:last-child>button,.button-group.radius>*:last-child>.button{-webkit-border-bottom-right-radius:5px;-webkit-border-top-right-radius:5px;border-bottom-right-radius:5px;border-top-right-radius:5px}.button-group.radius.stack>*{display:block;margin:0}.button-group.radius.stack>*>button,.button-group.radius.stack>* .button{border-left:1px solid;border-color:rgba(255,255,255,0.5)}.button-group.radius.stack>*:first-child button,.button-group.radius.stack>*:first-child .button{border-left:0}.button-group.radius.stack>*>button,.button-group.radius.stack>* .button{border-color:rgba(255,255,255,0.5);border-left-width:0;border-top:1px solid;display:block;margin:0}.button-group.radius.stack>*>button{width:100%}.button-group.radius.stack>*:first-child button,.button-group.radius.stack>*:first-child .button{border-top:0}.button-group.radius.stack>*,.button-group.radius.stack>*>a,.button-group.radius.stack>*>button,.button-group.radius.stack>*>.button{border-radius:0}.button-group.radius.stack>*:first-child,.button-group.radius.stack>*:first-child>a,.button-group.radius.stack>*:first-child>button,.button-group.radius.stack>*:first-child>.button{-webkit-top-left-radius:5px;-webkit-top-right-radius:5px;border-top-left-radius:5px;border-top-right-radius:5px}.button-group.radius.stack>*:last-child,.button-group.radius.stack>*:last-child>a,.button-group.radius.stack>*:last-child>button,.button-group.radius.stack>*:last-child>.button{-webkit-bottom-left-radius:5px;-webkit-bottom-right-radius:5px;border-bottom-left-radius:5px;border-bottom-right-radius:5px}@media only screen and (min-width: 40.0625em){.button-group.radius.stack-for-small>*{display:inline-block;margin:0 -2px}.button-group.radius.stack-for-small>*>button,.button-group.radius.stack-for-small>* .button{border-left:1px solid;border-color:rgba(255,255,255,0.5)}.button-group.radius.stack-for-small>*:first-child button,.button-group.radius.stack-for-small>*:first-child .button{border-left:0}.button-group.radius.stack-for-small>*,.button-group.radius.stack-for-small>*>a,.button-group.radius.stack-for-small>*>button,.button-group.radius.stack-for-small>*>.button{border-radius:0}.button-group.radius.stack-for-small>*:first-child,.button-group.radius.stack-for-small>*:first-child>a,.button-group.radius.stack-for-small>*:first-child>button,.button-group.radius.stack-for-small>*:first-child>.button{-webkit-border-bottom-left-radius:5px;-webkit-border-top-left-radius:5px;border-bottom-left-radius:5px;border-top-left-radius:5px}.button-group.radius.stack-for-small>*:last-child,.button-group.radius.stack-for-small>*:last-child>a,.button-group.radius.stack-for-small>*:last-child>button,.button-group.radius.stack-for-small>*:last-child>.button{-webkit-border-bottom-right-radius:5px;-webkit-border-top-right-radius:5px;border-bottom-right-radius:5px;border-top-right-radius:5px}}@media only screen and (max-width: 40em){.button-group.radius.stack-for-small>*{display:block;margin:0}.button-group.radius.stack-for-small>*>button,.button-group.radius.stack-for-small>* .button{border-left:1px solid;border-color:rgba(255,255,255,0.5)}.button-group.radius.stack-for-small>*:first-child button,.button-group.radius.stack-for-small>*:first-child .button{border-left:0}.button-group.radius.stack-for-small>*>button,.button-group.radius.stack-for-small>* .button{border-color:rgba(255,255,255,0.5);border-left-width:0;border-top:1px solid;display:block;margin:0}.button-group.radius.stack-for-small>*>button{width:100%}.button-group.radius.stack-for-small>*:first-child button,.button-group.radius.stack-for-small>*:first-child .button{border-top:0}.button-group.radius.stack-for-small>*,.button-group.radius.stack-for-small>*>a,.button-group.radius.stack-for-small>*>button,.button-group.radius.stack-for-small>*>.button{border-radius:0}.button-group.radius.stack-for-small>*:first-child,.button-group.radius.stack-for-small>*:first-child>a,.button-group.radius.stack-for-small>*:first-child>button,.button-group.radius.stack-for-small>*:first-child>.button{-webkit-top-left-radius:5px;-webkit-top-right-radius:5px;border-top-left-radius:5px;border-top-right-radius:5px}.button-group.radius.stack-for-small>*:last-child,.button-group.radius.stack-for-small>*:last-child>a,.button-group.radius.stack-for-small>*:last-child>button,.button-group.radius.stack-for-small>*:last-child>.button{-webkit-bottom-left-radius:5px;-webkit-bottom-right-radius:5px;border-bottom-left-radius:5px;border-bottom-right-radius:5px}}.button-group.round>*{display:inline-block;margin:0 -2px}.button-group.round>*>button,.button-group.round>* .button{border-left:1px solid;border-color:rgba(255,255,255,0.5)}.button-group.round>*:first-child button,.button-group.round>*:first-child .button{border-left:0}.button-group.round>*,.button-group.round>*>a,.button-group.round>*>button,.button-group.round>*>.button{border-radius:0}.button-group.round>*:first-child,.button-group.round>*:first-child>a,.button-group.round>*:first-child>button,.button-group.round>*:first-child>.button{-webkit-border-bottom-left-radius:1000px;-webkit-border-top-left-radius:1000px;border-bottom-left-radius:1000px;border-top-left-radius:1000px}.button-group.round>*:last-child,.button-group.round>*:last-child>a,.button-group.round>*:last-child>button,.button-group.round>*:last-child>.button{-webkit-border-bottom-right-radius:1000px;-webkit-border-top-right-radius:1000px;border-bottom-right-radius:1000px;border-top-right-radius:1000px}.button-group.round.stack>*{display:block;margin:0}.button-group.round.stack>*>button,.button-group.round.stack>* .button{border-left:1px solid;border-color:rgba(255,255,255,0.5)}.button-group.round.stack>*:first-child button,.button-group.round.stack>*:first-child .button{border-left:0}.button-group.round.stack>*>button,.button-group.round.stack>* .button{border-color:rgba(255,255,255,0.5);border-left-width:0;border-top:1px solid;display:block;margin:0}.button-group.round.stack>*>button{width:100%}.button-group.round.stack>*:first-child button,.button-group.round.stack>*:first-child .button{border-top:0}.button-group.round.stack>*,.button-group.round.stack>*>a,.button-group.round.stack>*>button,.button-group.round.stack>*>.button{border-radius:0}.button-group.round.stack>*:first-child,.button-group.round.stack>*:first-child>a,.button-group.round.stack>*:first-child>button,.button-group.round.stack>*:first-child>.button{-webkit-top-left-radius:1rem;-webkit-top-right-radius:1rem;border-top-left-radius:1rem;border-top-right-radius:1rem}.button-group.round.stack>*:last-child,.button-group.round.stack>*:last-child>a,.button-group.round.stack>*:last-child>button,.button-group.round.stack>*:last-child>.button{-webkit-bottom-left-radius:1rem;-webkit-bottom-right-radius:1rem;border-bottom-left-radius:1rem;border-bottom-right-radius:1rem}@media only screen and (min-width: 40.0625em){.button-group.round.stack-for-small>*{display:inline-block;margin:0 -2px}.button-group.round.stack-for-small>*>button,.button-group.round.stack-for-small>* .button{border-left:1px solid;border-color:rgba(255,255,255,0.5)}.button-group.round.stack-for-small>*:first-child button,.button-group.round.stack-for-small>*:first-child .button{border-left:0}.button-group.round.stack-for-small>*,.button-group.round.stack-for-small>*>a,.button-group.round.stack-for-small>*>button,.button-group.round.stack-for-small>*>.button{border-radius:0}.button-group.round.stack-for-small>*:first-child,.button-group.round.stack-for-small>*:first-child>a,.button-group.round.stack-for-small>*:first-child>button,.button-group.round.stack-for-small>*:first-child>.button{-webkit-border-bottom-left-radius:1000px;-webkit-border-top-left-radius:1000px;border-bottom-left-radius:1000px;border-top-left-radius:1000px}.button-group.round.stack-for-small>*:last-child,.button-group.round.stack-for-small>*:last-child>a,.button-group.round.stack-for-small>*:last-child>button,.button-group.round.stack-for-small>*:last-child>.button{-webkit-border-bottom-right-radius:1000px;-webkit-border-top-right-radius:1000px;border-bottom-right-radius:1000px;border-top-right-radius:1000px}}@media only screen and (max-width: 40em){.button-group.round.stack-for-small>*{display:block;margin:0}.button-group.round.stack-for-small>*>button,.button-group.round.stack-for-small>* .button{border-left:1px solid;border-color:rgba(255,255,255,0.5)}.button-group.round.stack-for-small>*:first-child button,.button-group.round.stack-for-small>*:first-child .button{border-left:0}.button-group.round.stack-for-small>*>button,.button-group.round.stack-for-small>* .button{border-color:rgba(255,255,255,0.5);border-left-width:0;border-top:1px solid;display:block;margin:0}.button-group.round.stack-for-small>*>button{width:100%}.button-group.round.stack-for-small>*:first-child button,.button-group.round.stack-for-small>*:first-child .button{border-top:0}.button-group.round.stack-for-small>*,.button-group.round.stack-for-small>*>a,.button-group.round.stack-for-small>*>button,.button-group.round.stack-for-small>*>.button{border-radius:0}.button-group.round.stack-for-small>*:first-child,.button-group.round.stack-for-small>*:first-child>a,.button-group.round.stack-for-small>*:first-child>button,.button-group.round.stack-for-small>*:first-child>.button{-webkit-top-left-radius:1rem;-webkit-top-right-radius:1rem;border-top-left-radius:1rem;border-top-right-radius:1rem}.button-group.round.stack-for-small>*:last-child,.button-group.round.stack-for-small>*:last-child>a,.button-group.round.stack-for-small>*:last-child>button,.button-group.round.stack-for-small>*:last-child>.button{-webkit-bottom-left-radius:1rem;-webkit-bottom-right-radius:1rem;border-bottom-left-radius:1rem;border-bottom-right-radius:1rem}}.button-bar:before,.button-bar:after{content:" ";display:table}.button-bar:after{clear:both}.button-bar .button-group{float:left;margin-right:0.625rem}.button-bar .button-group div{overflow:hidden}.clearing-thumbs,[data-clearing]{list-style:none;margin-left:0;margin-bottom:0}.clearing-thumbs:before,.clearing-thumbs:after,[data-clearing]:before,[data-clearing]:after{content:" ";display:table}.clearing-thumbs:after,[data-clearing]:after{clear:both}.clearing-thumbs li,[data-clearing] li{float:left;margin-right:10px}.clearing-thumbs[class*="block-grid-"] li,[data-clearing][class*="block-grid-"] li{margin-right:0}.clearing-blackout{background:#333;height:100%;position:fixed;top:0;width:100%;z-index:998;left:0}.clearing-blackout .clearing-close{display:block}.clearing-container{height:100%;margin:0;overflow:hidden;position:relative;z-index:998}.clearing-touch-label{color:#aaa;font-size:.6em;left:50%;position:absolute;top:50%}.visible-img{height:95%;position:relative}.visible-img img{position:absolute;left:50%;top:50%;-webkit-transform:translateY(-50%) translateX(-50%);-moz-transform:translateY(-50%) translateX(-50%);-ms-transform:translateY(-50%) translateX(-50%);-o-transform:translateY(-50%) translateX(-50%);transform:translateY(-50%) translateX(-50%);max-height:100%;max-width:100%}.clearing-caption{background:#333;bottom:0;color:#ccc;font-size:0.875em;line-height:1.3;margin-bottom:0;padding:10px 30px 20px;position:absolute;text-align:center;width:100%;left:0}.clearing-close{color:#ccc;display:none;font-size:30px;line-height:1;padding-left:20px;padding-top:10px;z-index:999}.clearing-close:hover,.clearing-close:focus{color:#ccc}.clearing-assembled .clearing-container{height:100%}.clearing-assembled .clearing-container .carousel>ul{display:none}.clearing-feature li{display:none}.clearing-feature li.clearing-featured-img{display:block}@media only screen and (min-width: 40.0625em){.clearing-main-prev,.clearing-main-next{height:100%;position:absolute;top:0;width:40px}.clearing-main-prev>span,.clearing-main-next>span{border:solid 12px;display:block;height:0;position:absolute;top:50%;width:0}.clearing-main-prev>span:hover,.clearing-main-next>span:hover{opacity:.8}.clearing-main-prev{left:0}.clearing-main-prev>span{left:5px;border-color:transparent;border-right-color:#ccc}.clearing-main-next{right:0}.clearing-main-next>span{border-color:transparent;border-left-color:#ccc}.clearing-main-prev.disabled,.clearing-main-next.disabled{opacity:.3}.clearing-assembled .clearing-container .carousel{background:rgba(51,51,51,0.8);height:120px;margin-top:10px;text-align:center}.clearing-assembled .clearing-container .carousel>ul{display:inline-block;z-index:999;height:100%;position:relative;float:none}.clearing-assembled .clearing-container .carousel>ul li{clear:none;cursor:pointer;display:block;float:left;margin-right:0;min-height:inherit;opacity:.4;overflow:hidden;padding:0;position:relative;width:120px}.clearing-assembled .clearing-container .carousel>ul li.fix-height img{height:100%;max-width:none}.clearing-assembled .clearing-container .carousel>ul li a.th{border:none;box-shadow:none;display:block}.clearing-assembled .clearing-container .carousel>ul li img{cursor:pointer !important;width:100% !important}.clearing-assembled .clearing-container .carousel>ul li.visible{opacity:1}.clearing-assembled .clearing-container .carousel>ul li:hover{opacity:.8}.clearing-assembled .clearing-container .visible-img{background:#333;height:85%;overflow:hidden}.clearing-close{padding-left:0;padding-top:0;position:absolute;top:10px;right:20px}}.f-dropdown{display:none;left:-9999px;list-style:none;margin-left:0;position:absolute;background:#fff;border:solid 1px #ccc;font-size:0.875rem;height:auto;max-height:none;width:100%;z-index:89;margin-top:2px;max-width:200px}.f-dropdown.open{display:block}.f-dropdown>*:first-child{margin-top:0}.f-dropdown>*:last-child{margin-bottom:0}.f-dropdown:before{border:inset 6px;content:"";display:block;height:0;width:0;border-color:transparent transparent #fff transparent;border-bottom-style:solid;position:absolute;top:-12px;left:10px;z-index:89}.f-dropdown:after{border:inset 7px;content:"";display:block;height:0;width:0;border-color:transparent transparent #ccc transparent;border-bottom-style:solid;position:absolute;top:-14px;left:9px;z-index:88}.f-dropdown.right:before{left:auto;right:10px}.f-dropdown.right:after{left:auto;right:9px}.f-dropdown.drop-right{display:none;left:-9999px;list-style:none;margin-left:0;position:absolute;background:#fff;border:solid 1px #ccc;font-size:0.875rem;height:auto;max-height:none;width:100%;z-index:89;margin-top:0;margin-left:2px;max-width:200px}.f-dropdown.drop-right.open{display:block}.f-dropdown.drop-right>*:first-child{margin-top:0}.f-dropdown.drop-right>*:last-child{margin-bottom:0}.f-dropdown.drop-right:before{border:inset 6px;content:"";display:block;height:0;width:0;border-color:transparent #fff transparent transparent;border-right-style:solid;position:absolute;top:10px;left:-12px;z-index:89}.f-dropdown.drop-right:after{border:inset 7px;content:"";display:block;height:0;width:0;border-color:transparent #ccc transparent transparent;border-right-style:solid;position:absolute;top:9px;left:-14px;z-index:88}.f-dropdown.drop-left{display:none;left:-9999px;list-style:none;margin-left:0;position:absolute;background:#fff;border:solid 1px #ccc;font-size:0.875rem;height:auto;max-height:none;width:100%;z-index:89;margin-top:0;margin-left:-2px;max-width:200px}.f-dropdown.drop-left.open{display:block}.f-dropdown.drop-left>*:first-child{margin-top:0}.f-dropdown.drop-left>*:last-child{margin-bottom:0}.f-dropdown.drop-left:before{border:inset 6px;content:"";display:block;height:0;width:0;border-color:transparent transparent transparent #fff;border-left-style:solid;position:absolute;top:10px;right:-12px;left:auto;z-index:89}.f-dropdown.drop-left:after{border:inset 7px;content:"";display:block;height:0;width:0;border-color:transparent transparent transparent #ccc;border-left-style:solid;position:absolute;top:9px;right:-14px;left:auto;z-index:88}.f-dropdown.drop-top{display:none;left:-9999px;list-style:none;margin-left:0;position:absolute;background:#fff;border:solid 1px #ccc;font-size:0.875rem;height:auto;max-height:none;width:100%;z-index:89;margin-left:0;margin-top:-2px;max-width:200px}.f-dropdown.drop-top.open{display:block}.f-dropdown.drop-top>*:first-child{margin-top:0}.f-dropdown.drop-top>*:last-child{margin-bottom:0}.f-dropdown.drop-top:before{border:inset 6px;content:"";display:block;height:0;width:0;border-color:#fff transparent transparent transparent;border-top-style:solid;bottom:-12px;position:absolute;top:auto;left:10px;right:auto;z-index:89}.f-dropdown.drop-top:after{border:inset 7px;content:"";display:block;height:0;width:0;border-color:#ccc transparent transparent transparent;border-top-style:solid;bottom:-14px;position:absolute;top:auto;left:9px;right:auto;z-index:88}.f-dropdown li{cursor:pointer;font-size:0.875rem;line-height:1.125rem;margin:0}.f-dropdown li:hover,.f-dropdown li:focus{background:#eee}.f-dropdown li.radius{border-radius:5px}.f-dropdown li a{display:block;padding:0.5rem;color:#555}.f-dropdown.content{display:none;left:-9999px;list-style:none;margin-left:0;position:absolute;background:#fff;border:solid 1px #ccc;font-size:0.875rem;height:auto;max-height:none;padding:1.25rem;width:100%;z-index:89;max-width:200px}.f-dropdown.content.open{display:block}.f-dropdown.content>*:first-child{margin-top:0}.f-dropdown.content>*:last-child{margin-bottom:0}.f-dropdown.tiny{max-width:200px}.f-dropdown.small{max-width:300px}.f-dropdown.medium{max-width:500px}.f-dropdown.large{max-width:800px}.f-dropdown.mega{width:100% !important;max-width:100% !important}.f-dropdown.mega.open{left:0 !important}.dropdown.button,button.dropdown{position:relative;padding-right:3.5625rem}.dropdown.button::after,button.dropdown::after{border-color:#fff transparent transparent transparent;border-style:solid;content:"";display:block;height:0;position:absolute;top:50%;width:0}.dropdown.button::after,button.dropdown::after{border-width:0.375rem;right:1.40625rem;margin-top:-0.15625rem}.dropdown.button::after,button.dropdown::after{border-color:#fff transparent transparent transparent}.dropdown.button.tiny,button.dropdown.tiny{padding-right:2.625rem}.dropdown.button.tiny:after,button.dropdown.tiny:after{border-width:0.375rem;right:1.125rem;margin-top:-0.125rem}.dropdown.button.tiny::after,button.dropdown.tiny::after{border-color:#fff transparent transparent transparent}.dropdown.button.small,button.dropdown.small{padding-right:3.0625rem}.dropdown.button.small::after,button.dropdown.small::after{border-width:0.4375rem;right:1.3125rem;margin-top:-0.15625rem}.dropdown.button.small::after,button.dropdown.small::after{border-color:#fff transparent transparent transparent}.dropdown.button.large,button.dropdown.large{padding-right:3.625rem}.dropdown.button.large::after,button.dropdown.large::after{border-width:0.3125rem;right:1.71875rem;margin-top:-0.15625rem}.dropdown.button.large::after,button.dropdown.large::after{border-color:#fff transparent transparent transparent}.dropdown.button.secondary:after,button.dropdown.secondary:after{border-color:#333 transparent transparent transparent}.flex-video{height:0;margin-bottom:1rem;overflow:hidden;padding-bottom:67.5%;padding-top:1.5625rem;position:relative}.flex-video.widescreen{padding-bottom:56.34%}.flex-video.vimeo{padding-top:0}.flex-video iframe,.flex-video object,.flex-video embed,.flex-video video{height:100%;position:absolute;top:0;width:100%;left:0}form{margin:0 0 1rem}form .row .row{margin:0 -0.5rem}form .row .row .column,form .row .row .columns{padding:0 0.5rem}form .row .row.collapse{margin:0}form .row .row.collapse .column,form .row .row.collapse .columns{padding:0}form .row .row.collapse input{-webkit-border-bottom-right-radius:0;-webkit-border-top-right-radius:0;border-bottom-right-radius:0;border-top-right-radius:0}form .row input.column,form .row input.columns,form .row textarea.column,form .row textarea.columns{padding-left:0.5rem}label{color:#4d4d4d;cursor:pointer;display:block;font-size:0.875rem;font-weight:100;line-height:2;margin-bottom:0}label.right{float:none !important;text-align:right}label.inline{margin:0 0 1rem 0;padding:0.5625rem 0}label small{text-transform:capitalize;color:#676767}.prefix,.postfix{border-style:solid;border-width:1px;display:block;font-size:0.875rem;height:2.375rem;line-height:2.375rem;overflow:visible;padding-bottom:0;padding-top:0;position:relative;text-align:center;width:100%;z-index:2}.postfix.button{border-color:true}.prefix.button{border:none;padding-left:0;padding-right:0;padding-bottom:0;padding-top:0;text-align:center}.prefix.button.radius{border-radius:0;-webkit-border-bottom-left-radius:5px;-webkit-border-top-left-radius:5px;border-bottom-left-radius:5px;border-top-left-radius:5px}.postfix.button.radius{border-radius:0;-webkit-border-bottom-right-radius:5px;-webkit-border-top-right-radius:5px;border-bottom-right-radius:5px;border-top-right-radius:5px}.prefix.button.round{border-radius:0;-webkit-border-bottom-left-radius:1000px;-webkit-border-top-left-radius:1000px;border-bottom-left-radius:1000px;border-top-left-radius:1000px}.postfix.button.round{border-radius:0;-webkit-border-bottom-right-radius:1000px;-webkit-border-top-right-radius:1000px;border-bottom-right-radius:1000px;border-top-right-radius:1000px}span.prefix,label.prefix{background:#f2f2f2;border-right:none;color:#333;border-color:#ccc}span.postfix,label.postfix{background:#f2f2f2;color:#333;border-color:#ccc}input[type="text"],input[type="password"],input[type="date"],input[type="datetime"],input[type="datetime-local"],input[type="month"],input[type="week"],input[type="email"],input[type="number"],input[type="search"],input[type="tel"],input[type="time"],input[type="url"],input[type="color"],textarea{-webkit-appearance:none;-moz-appearance:none;border-radius:0;background-color:#fff;border-style:solid;border-width:1px;border-color:#ccc;box-shadow:inset 0 0 0 rgba(0,0,0,0.1);color:rgba(0,0,0,0.75);display:block;font-family:inherit;font-size:0.9375rem;height:2.375rem;margin:0 0 1rem 0;padding:0.5rem;width:100%;-webkit-box-sizing:border-box;-moz-box-sizing:border-box;box-sizing:border-box;-webkit-transition:border-color 0.15s linear,background 0.15s linear;-moz-transition:border-color 0.15s linear,background 0.15s linear;-ms-transition:border-color 0.15s linear,background 0.15s linear;-o-transition:border-color 0.15s linear,background 0.15s linear;transition:border-color 0.15s linear,background 0.15s linear}input[type="text"]:focus,input[type="password"]:focus,input[type="date"]:focus,input[type="datetime"]:focus,input[type="datetime-local"]:focus,input[type="month"]:focus,input[type="week"]:focus,input[type="email"]:focus,input[type="number"]:focus,input[type="search"]:focus,input[type="tel"]:focus,input[type="time"]:focus,input[type="url"]:focus,input[type="color"]:focus,textarea:focus{background:#fafafa;border-color:#999;outline:none}input[type="text"]:disabled,input[type="password"]:disabled,input[type="date"]:disabled,input[type="datetime"]:disabled,input[type="datetime-local"]:disabled,input[type="month"]:disabled,input[type="week"]:disabled,input[type="email"]:disabled,input[type="number"]:disabled,input[type="search"]:disabled,input[type="tel"]:disabled,input[type="time"]:disabled,input[type="url"]:disabled,input[type="color"]:disabled,textarea:disabled{background-color:#ddd;cursor:default}input[type="text"][disabled],input[type="text"][readonly],fieldset[disabled] input[type="text"],input[type="password"][disabled],input[type="password"][readonly],fieldset[disabled] input[type="password"],input[type="date"][disabled],input[type="date"][readonly],fieldset[disabled] input[type="date"],input[type="datetime"][disabled],input[type="datetime"][readonly],fieldset[disabled] input[type="datetime"],input[type="datetime-local"][disabled],input[type="datetime-local"][readonly],fieldset[disabled] input[type="datetime-local"],input[type="month"][disabled],input[type="month"][readonly],fieldset[disabled] input[type="month"],input[type="week"][disabled],input[type="week"][readonly],fieldset[disabled] input[type="week"],input[type="email"][disabled],input[type="email"][readonly],fieldset[disabled] input[type="email"],input[type="number"][disabled],input[type="number"][readonly],fieldset[disabled] input[type="number"],input[type="search"][disabled],input[type="search"][readonly],fieldset[disabled] input[type="search"],input[type="tel"][disabled],input[type="tel"][readonly],fieldset[disabled] input[type="tel"],input[type="time"][disabled],input[type="time"][readonly],fieldset[disabled] input[type="time"],input[type="url"][disabled],input[type="url"][readonly],fieldset[disabled] input[type="url"],input[type="color"][disabled],input[type="color"][readonly],fieldset[disabled] input[type="color"],textarea[disabled],textarea[readonly],fieldset[disabled] textarea{background-color:#ddd;cursor:default}input[type="text"].radius,input[type="password"].radius,input[type="date"].radius,input[type="datetime"].radius,input[type="datetime-local"].radius,input[type="month"].radius,input[type="week"].radius,input[type="email"].radius,input[type="number"].radius,input[type="search"].radius,input[type="tel"].radius,input[type="time"].radius,input[type="url"].radius,input[type="color"].radius,textarea.radius{border-radius:5px}form .row .prefix-radius.row.collapse input,form .row .prefix-radius.row.collapse textarea,form .row .prefix-radius.row.collapse select,form .row .prefix-radius.row.collapse button{border-radius:0;-webkit-border-bottom-right-radius:5px;-webkit-border-top-right-radius:5px;border-bottom-right-radius:5px;border-top-right-radius:5px}form .row .prefix-radius.row.collapse .prefix{border-radius:0;-webkit-border-bottom-left-radius:5px;-webkit-border-top-left-radius:5px;border-bottom-left-radius:5px;border-top-left-radius:5px}form .row .postfix-radius.row.collapse input,form .row .postfix-radius.row.collapse textarea,form .row .postfix-radius.row.collapse select,form .row .postfix-radius.row.collapse button{border-radius:0;-webkit-border-bottom-left-radius:5px;-webkit-border-top-left-radius:5px;border-bottom-left-radius:5px;border-top-left-radius:5px}form .row .postfix-radius.row.collapse .postfix{border-radius:0;-webkit-border-bottom-right-radius:5px;-webkit-border-top-right-radius:5px;border-bottom-right-radius:5px;border-top-right-radius:5px}form .row .prefix-round.row.collapse input,form .row .prefix-round.row.collapse textarea,form .row .prefix-round.row.collapse select,form .row .prefix-round.row.collapse button{border-radius:0;-webkit-border-bottom-right-radius:1000px;-webkit-border-top-right-radius:1000px;border-bottom-right-radius:1000px;border-top-right-radius:1000px}form .row .prefix-round.row.collapse .prefix{border-radius:0;-webkit-border-bottom-left-radius:1000px;-webkit-border-top-left-radius:1000px;border-bottom-left-radius:1000px;border-top-left-radius:1000px}form .row .postfix-round.row.collapse input,form .row .postfix-round.row.collapse textarea,form .row .postfix-round.row.collapse select,form .row .postfix-round.row.collapse button{border-radius:0;-webkit-border-bottom-left-radius:1000px;-webkit-border-top-left-radius:1000px;border-bottom-left-radius:1000px;border-top-left-radius:1000px}form .row .postfix-round.row.collapse .postfix{border-radius:0;-webkit-border-bottom-right-radius:1000px;-webkit-border-top-right-radius:1000px;border-bottom-right-radius:1000px;border-top-right-radius:1000px}input[type="submit"]{-webkit-appearance:none;-moz-appearance:none;border-radius:0}textarea[rows]{height:auto}textarea{max-width:100%}::-webkit-input-placeholder{color:#ccc}:-moz-placeholder{color:#ccc}::-moz-placeholder{color:#ccc}:-ms-input-placeholder{color:#ccc}select{-webkit-appearance:none !important;-moz-appearance:none !important;background-color:#FAFAFA;border-radius:0;background-image:url(data:image/svg+xml;base64,PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHZlcnNpb249IjEuMSIgeD0iMTJweCIgeT0iMHB4IiB3aWR0aD0iMjRweCIgaGVpZ2h0PSIzcHgiIHZpZXdCb3g9IjAgMCA2IDMiIGVuYWJsZS1iYWNrZ3JvdW5kPSJuZXcgMCAwIDYgMyIgeG1sOnNwYWNlPSJwcmVzZXJ2ZSI+PHBvbHlnb24gcG9pbnRzPSI1Ljk5MiwwIDIuOTkyLDMgLTAuMDA4LDAgIi8+PC9zdmc+);background-position:100% center;background-repeat:no-repeat;border-style:solid;border-width:1px;border-color:#ccc;color:rgba(0,0,0,0.75);font-family:inherit;font-size:0.9375rem;line-height:normal;padding:0.5rem;border-radius:0;height:2.375rem}select::-ms-expand{display:none}select.radius{border-radius:5px}select:hover{background-color:#f3f3f3;border-color:#999}select:disabled{background-color:#ddd;cursor:default}select[multiple]{height:auto}input[type="file"],input[type="checkbox"],input[type="radio"],select{margin:0 0 1rem 0}input[type="checkbox"]+label,input[type="radio"]+label{display:inline-block;margin-left:0.5rem;margin-right:1rem;margin-bottom:0;vertical-align:baseline}input[type="file"]{width:100%}fieldset{border:1px solid #ddd;margin:1.125rem 0;padding:1.25rem}fieldset legend{background:#fff;font-weight:bold;margin-left:-0.1875rem;margin:0;padding:0 0.1875rem}[data-abide] .error small.error,[data-abide] .error span.error,[data-abide] span.error,[data-abide] small.error{display:block;font-size:0.75rem;font-style:italic;font-weight:normal;margin-bottom:1rem;margin-top:-1px;padding:0.375rem 0.5625rem 0.5625rem;background:#f04124;color:#fff}[data-abide] span.error,[data-abide] small.error{display:none}span.error,small.error{display:block;font-size:0.75rem;font-style:italic;font-weight:normal;margin-bottom:1rem;margin-top:-1px;padding:0.375rem 0.5625rem 0.5625rem;background:#f04124;color:#fff}.error input,.error textarea,.error select{margin-bottom:0}.error input[type="checkbox"],.error input[type="radio"]{margin-bottom:1rem}.error label,.error label.error{color:#f04124}.error small.error{display:block;font-size:0.75rem;font-style:italic;font-weight:normal;margin-bottom:1rem;margin-top:-1px;padding:0.375rem 0.5625rem 0.5625rem;background:#f04124;color:#fff}.error>label>small{background:transparent;color:#676767;display:inline;font-size:60%;font-style:normal;margin:0;padding:0;text-transform:capitalize}.error span.error-message{display:block}input.error,textarea.error,select.error{margin-bottom:0}label.error{color:#f04124}.icon-bar{display:inline-block;font-size:0;width:100%;background:#333}.icon-bar>*{display:block;float:left;font-size:1rem;margin:0 auto;padding:1.25rem;text-align:center;width:25%}.icon-bar>* i,.icon-bar>* img{display:block;margin:0 auto}.icon-bar>* i+label,.icon-bar>* img+label{margin-top:.0625rem}.icon-bar>* i{font-size:1.875rem;vertical-align:middle}.icon-bar>* img{height:1.875rem;width:1.875rem}.icon-bar.label-right>* i,.icon-bar.label-right>* img{display:inline-block;margin:0 .0625rem 0 0}.icon-bar.label-right>* i+label,.icon-bar.label-right>* img+label{margin-top:0}.icon-bar.label-right>* label{display:inline-block}.icon-bar.vertical.label-right>*{text-align:left}.icon-bar.vertical,.icon-bar.small-vertical{height:100%;width:auto}.icon-bar.vertical .item,.icon-bar.small-vertical .item{float:none;margin:auto;width:auto}@media only screen and (min-width: 40.0625em){.icon-bar.medium-vertical{height:100%;width:auto}.icon-bar.medium-vertical .item{float:none;margin:auto;width:auto}}@media only screen and (min-width: 58.8125em){.icon-bar.large-vertical{height:100%;width:auto}.icon-bar.large-vertical .item{float:none;margin:auto;width:auto}}.icon-bar>*{font-size:1rem;padding:1.25rem}.icon-bar>* i+label,.icon-bar>* img+label{margin-top:.0625rem;font-size:1rem}.icon-bar>* i{font-size:1.875rem}.icon-bar>* img{height:1.875rem;width:1.875rem}.icon-bar>* label{color:#fff}.icon-bar>* i{color:#fff}.icon-bar>a:hover{background:#22b8eb}.icon-bar>a:hover label{color:#fff}.icon-bar>a:hover i{color:#fff}.icon-bar>a.active{background:#22b8eb}.icon-bar>a.active label{color:#fff}.icon-bar>a.active i{color:#fff}.icon-bar .item.disabled{cursor:not-allowed;opacity:0.7;pointer-events:none}.icon-bar .item.disabled>*{opacity:0.7;cursor:not-allowed}.icon-bar.two-up .item{width:50%}.icon-bar.two-up.vertical .item,.icon-bar.two-up.small-vertical .item{width:auto}@media only screen and (min-width: 40.0625em){.icon-bar.two-up.medium-vertical .item{width:auto}}@media only screen and (min-width: 58.8125em){.icon-bar.two-up.large-vertical .item{width:auto}}.icon-bar.three-up .item{width:33.3333%}.icon-bar.three-up.vertical .item,.icon-bar.three-up.small-vertical .item{width:auto}@media only screen and (min-width: 40.0625em){.icon-bar.three-up.medium-vertical .item{width:auto}}@media only screen and (min-width: 58.8125em){.icon-bar.three-up.large-vertical .item{width:auto}}.icon-bar.four-up .item{width:25%}.icon-bar.four-up.vertical .item,.icon-bar.four-up.small-vertical .item{width:auto}@media only screen and (min-width: 40.0625em){.icon-bar.four-up.medium-vertical .item{width:auto}}@media only screen and (min-width: 58.8125em){.icon-bar.four-up.large-vertical .item{width:auto}}.icon-bar.five-up .item{width:20%}.icon-bar.five-up.vertical .item,.icon-bar.five-up.small-vertical .item{width:auto}@media only screen and (min-width: 40.0625em){.icon-bar.five-up.medium-vertical .item{width:auto}}@media only screen and (min-width: 58.8125em){.icon-bar.five-up.large-vertical .item{width:auto}}.icon-bar.six-up .item{width:16.66667%}.icon-bar.six-up.vertical .item,.icon-bar.six-up.small-vertical .item{width:auto}@media only screen and (min-width: 40.0625em){.icon-bar.six-up.medium-vertical .item{width:auto}}@media only screen and (min-width: 58.8125em){.icon-bar.six-up.large-vertical .item{width:auto}}.icon-bar.seven-up .item{width:14.28571%}.icon-bar.seven-up.vertical .item,.icon-bar.seven-up.small-vertical .item{width:auto}@media only screen and (min-width: 40.0625em){.icon-bar.seven-up.medium-vertical .item{width:auto}}@media only screen and (min-width: 58.8125em){.icon-bar.seven-up.large-vertical .item{width:auto}}.icon-bar.eight-up .item{width:12.5%}.icon-bar.eight-up.vertical .item,.icon-bar.eight-up.small-vertical .item{width:auto}@media only screen and (min-width: 40.0625em){.icon-bar.eight-up.medium-vertical .item{width:auto}}@media only screen and (min-width: 58.8125em){.icon-bar.eight-up.large-vertical .item{width:auto}}.icon-bar.two-up .item{width:50%}.icon-bar.two-up.vertical .item,.icon-bar.two-up.small-vertical .item{width:auto}@media only screen and (min-width: 40.0625em){.icon-bar.two-up.medium-vertical .item{width:auto}}@media only screen and (min-width: 58.8125em){.icon-bar.two-up.large-vertical .item{width:auto}}.icon-bar.three-up .item{width:33.3333%}.icon-bar.three-up.vertical .item,.icon-bar.three-up.small-vertical .item{width:auto}@media only screen and (min-width: 40.0625em){.icon-bar.three-up.medium-vertical .item{width:auto}}@media only screen and (min-width: 58.8125em){.icon-bar.three-up.large-vertical .item{width:auto}}.icon-bar.four-up .item{width:25%}.icon-bar.four-up.vertical .item,.icon-bar.four-up.small-vertical .item{width:auto}@media only screen and (min-width: 40.0625em){.icon-bar.four-up.medium-vertical .item{width:auto}}@media only screen and (min-width: 58.8125em){.icon-bar.four-up.large-vertical .item{width:auto}}.icon-bar.five-up .item{width:20%}.icon-bar.five-up.vertical .item,.icon-bar.five-up.small-vertical .item{width:auto}@media only screen and (min-width: 40.0625em){.icon-bar.five-up.medium-vertical .item{width:auto}}@media only screen and (min-width: 58.8125em){.icon-bar.five-up.large-vertical .item{width:auto}}.icon-bar.six-up .item{width:16.66667%}.icon-bar.six-up.vertical .item,.icon-bar.six-up.small-vertical .item{width:auto}@media only screen and (min-width: 40.0625em){.icon-bar.six-up.medium-vertical .item{width:auto}}@media only screen and (min-width: 58.8125em){.icon-bar.six-up.large-vertical .item{width:auto}}.icon-bar.seven-up .item{width:14.28571%}.icon-bar.seven-up.vertical .item,.icon-bar.seven-up.small-vertical .item{width:auto}@media only screen and (min-width: 40.0625em){.icon-bar.seven-up.medium-vertical .item{width:auto}}@media only screen and (min-width: 58.8125em){.icon-bar.seven-up.large-vertical .item{width:auto}}.icon-bar.eight-up .item{width:12.5%}.icon-bar.eight-up.vertical .item,.icon-bar.eight-up.small-vertical .item{width:auto}@media only screen and (min-width: 40.0625em){.icon-bar.eight-up.medium-vertical .item{width:auto}}@media only screen and (min-width: 58.8125em){.icon-bar.eight-up.large-vertical .item{width:auto}}.inline-list{list-style:none;margin-left:-1.375rem;margin-right:0;margin:0 auto 1.0625rem auto;overflow:hidden;padding:0}.inline-list>li{display:block;float:left;list-style:none;margin-left:1.375rem}.inline-list>li>*{display:block}.joyride-list{display:none}.joyride-tip-guide{background:#333;color:#fff;display:none;font-family:inherit;font-weight:normal;position:absolute;top:0;width:95%;z-index:101;left:2.5%}.lt-ie9 .joyride-tip-guide{margin-left:-400px;max-width:800px;left:50%}.joyride-content-wrapper{padding:1.125rem 1.25rem 1.5rem;width:100%}.joyride-content-wrapper .button{margin-bottom:0 !important}.joyride-content-wrapper .joyride-prev-tip{margin-right:10px}.joyride-tip-guide .joyride-nub{border:10px solid #333;display:block;height:0;position:absolute;width:0;left:22px}.joyride-tip-guide .joyride-nub.top{border-color:#333;border-top-color:transparent !important;border-top-style:solid;border-left-color:transparent !important;border-right-color:transparent !important;top:-20px}.joyride-tip-guide .joyride-nub.bottom{border-color:#333 !important;border-bottom-color:transparent !important;border-bottom-style:solid;border-left-color:transparent !important;border-right-color:transparent !important;bottom:-20px}.joyride-tip-guide .joyride-nub.right{right:-20px}.joyride-tip-guide .joyride-nub.left{left:-20px}.joyride-tip-guide h1,.joyride-tip-guide h2,.joyride-tip-guide h3,.joyride-tip-guide h4,.joyride-tip-guide h5,.joyride-tip-guide h6{color:#fff;font-weight:bold;line-height:1.25;margin:0}.joyride-tip-guide p{font-size:0.875rem;line-height:1.3;margin:0 0 1.125rem 0}.joyride-timer-indicator-wrap{border:solid 1px #555;bottom:1rem;height:3px;position:absolute;width:50px;right:1.0625rem}.joyride-timer-indicator{background:#666;display:block;height:inherit;width:0}.joyride-close-tip{color:#777 !important;font-size:24px;font-weight:normal;line-height:.5 !important;position:absolute;text-decoration:none;top:10px;right:12px}.joyride-close-tip:hover,.joyride-close-tip:focus{color:#eee !important}.joyride-modal-bg{background:rgba(0,0,0,0.5);cursor:pointer;display:none;height:100%;position:fixed;top:0;width:100%;z-index:100;left:0}.joyride-expose-wrapper{background-color:#fff;border-radius:3px;box-shadow:0 0 15px #fff;position:absolute;z-index:102}.joyride-expose-cover{background:transparent;border-radius:3px;left:0;position:absolute;top:0;z-index:9999}@media only screen and (min-width: 40.0625em){.joyride-tip-guide{width:300px;left:inherit}.joyride-tip-guide .joyride-nub.bottom{border-color:#333 !important;border-bottom-color:transparent !important;border-left-color:transparent !important;border-right-color:transparent !important;bottom:-20px}.joyride-tip-guide .joyride-nub.right{border-color:#333 !important;border-right-color:transparent !important;border-bottom-color:transparent !important;border-top-color:transparent !important;left:auto;right:-20px;top:22px}.joyride-tip-guide .joyride-nub.left{border-color:#333 !important;border-bottom-color:transparent !important;border-left-color:transparent !important;border-top-color:transparent !important;left:-20px;right:auto;top:22px}}.keystroke,kbd{background-color:#ededed;border-color:#ddd;color:#222;border-style:solid;border-width:1px;font-family:"Consolas","Menlo","Courier",monospace;font-size:inherit;margin:0;padding:0.125rem 0.25rem 0;border-radius:5px}.label{display:inline-block;font-family:"Helvetica Neue",Helvetica,Roboto,Arial,sans-serif;font-weight:normal;line-height:1;margin-bottom:auto;position:relative;text-align:center;text-decoration:none;white-space:nowrap;padding:0.25rem 0.5rem 0.25rem;font-size:0.6875rem;background-color:#22b8eb;color:#fff}.label.radius{border-radius:5px}.label.round{border-radius:1000px}.label.alert{background-color:#f04124;color:#fff}.label.warning{background-color:#f08a24;color:#fff}.label.success{background-color:#43AC6A;color:#fff}.label.secondary{background-color:#FF992E;color:#fff}.label.info{background-color:#a0d3e8;color:#333}"[data-magellan-expedition]",[data-magellan-expedition-clone]{background:#fff;min-width:100%;padding:10px;z-index:50}"[data-magellan-expedition]" .sub-nav,[data-magellan-expedition-clone] .sub-nav{margin-bottom:0}"[data-magellan-expedition]" .sub-nav dd,[data-magellan-expedition-clone] .sub-nav dd{margin-bottom:0}"[data-magellan-expedition]" .sub-nav a,[data-magellan-expedition-clone] .sub-nav a{line-height:1.8em}@-webkit-keyframes rotate{from{-webkit-transform:rotate(0deg);transform:rotate(0deg)}to{-webkit-transform:rotate(360deg);transform:rotate(360deg)}}@keyframes rotate{from{-webkit-transform:rotate(0deg);-moz-transform:rotate(0deg);-ms-transform:rotate(0deg);transform:rotate(0deg)}to{-webkit-transform:rotate(360deg);-moz-transform:rotate(360deg);-ms-transform:rotate(360deg);transform:rotate(360deg)}}.slideshow-wrapper{position:relative}.slideshow-wrapper ul{list-style-type:none;margin:0}.slideshow-wrapper ul li,.slideshow-wrapper ul li .orbit-caption{display:none}.slideshow-wrapper ul li:first-child{display:block}.slideshow-wrapper .orbit-container{background-color:transparent}.slideshow-wrapper .orbit-container li{display:block}.slideshow-wrapper .orbit-container li .orbit-caption{display:block}.slideshow-wrapper .orbit-container .orbit-bullets li{display:inline-block}.slideshow-wrapper .preloader{border-radius:1000px;animation-duration:1.5s;animation-iteration-count:infinite;animation-name:rotate;animation-timing-function:linear;border-color:#555 #fff;border:solid 3px;display:block;height:40px;left:50%;margin-left:-20px;margin-top:-20px;position:absolute;top:50%;width:40px}.orbit-container{background:none;overflow:hidden;position:relative;width:100%}.orbit-container .orbit-slides-container{list-style:none;margin:0;padding:0;position:relative;-webkit-transform:translateZ(0);-moz-transform:translateZ(0);-ms-transform:translateZ(0);-o-transform:translateZ(0);transform:translateZ(0)}.orbit-container .orbit-slides-container img{display:block;max-width:100%}.orbit-container .orbit-slides-container>*{position:absolute;top:0;width:100%;margin-left:100%}.orbit-container .orbit-slides-container>*:first-child{margin-left:0}.orbit-container .orbit-slides-container>* .orbit-caption{bottom:0;position:absolute;background-color:rgba(51,51,51,0.8);color:#fff;font-size:0.875rem;padding:0.625rem 0.875rem;width:100%}.orbit-container .orbit-slide-number{left:10px;background:transparent;color:#fff;font-size:12px;position:absolute;top:10px;z-index:10}.orbit-container .orbit-slide-number span{font-weight:700;padding:0.3125rem}.orbit-container .orbit-timer{position:absolute;top:12px;right:10px;height:6px;width:100px;z-index:10}.orbit-container .orbit-timer .orbit-progress{height:3px;background-color:rgba(255,255,255,0.3);display:block;width:0;position:relative;right:20px;top:5px}.orbit-container .orbit-timer>span{border:solid 4px #fff;border-bottom:none;border-top:none;display:none;height:14px;position:absolute;top:0;width:11px;right:0}.orbit-container .orbit-timer.paused>span{top:0;width:11px;height:14px;border:inset 8px;border-left-style:solid;border-color:transparent;border-left-color:#fff;right:-4px}.orbit-container .orbit-timer.paused>span.dark{border-left-color:#333}.orbit-container:hover .orbit-timer>span{display:block}.orbit-container .orbit-prev,.orbit-container .orbit-next{background-color:transparent;color:white;height:60px;line-height:50px;margin-top:-25px;position:absolute;text-indent:-9999px !important;top:45%;width:36px;z-index:10}.orbit-container .orbit-prev:hover,.orbit-container .orbit-next:hover{background-color:rgba(0,0,0,0.3)}.orbit-container .orbit-prev>span,.orbit-container .orbit-next>span{border:inset 10px;display:block;height:0;margin-top:-10px;position:absolute;top:50%;width:0}.orbit-container .orbit-prev{left:0}.orbit-container .orbit-prev>span{border-right-style:solid;border-color:transparent;border-right-color:#fff}.orbit-container .orbit-prev:hover>span{border-right-color:#fff}.orbit-container .orbit-next{right:0}.orbit-container .orbit-next>span{border-color:transparent;border-left-style:solid;border-left-color:#fff;left:50%;margin-left:-4px}.orbit-container .orbit-next:hover>span{border-left-color:#fff}.orbit-bullets-container{text-align:center}.orbit-bullets{display:block;float:none;margin:0 auto 30px auto;overflow:hidden;position:relative;text-align:center;top:10px}.orbit-bullets li{background:#ccc;cursor:pointer;display:inline-block;float:none;height:0.5625rem;margin-right:6px;width:0.5625rem;border-radius:1000px}.orbit-bullets li.active{background:#999}.orbit-bullets li:last-child{margin-right:0}.touch .orbit-container .orbit-prev,.touch .orbit-container .orbit-next{display:none}.touch .orbit-bullets{display:none}@media only screen and (min-width: 40.0625em){.touch .orbit-container .orbit-prev,.touch .orbit-container .orbit-next{display:inherit}.touch .orbit-bullets{display:block}}@media only screen and (max-width: 40em){.orbit-stack-on-small .orbit-slides-container{height:auto !important}.orbit-stack-on-small .orbit-slides-container>*{margin:0 !important;opacity:1 !important;position:relative}.orbit-stack-on-small .orbit-slide-number{display:none}.orbit-timer{display:none}.orbit-next,.orbit-prev{display:none}.orbit-bullets{display:none}}ul.pagination{display:block;margin-left:-0.3125rem;min-height:1.5rem}ul.pagination li{color:#222;font-size:0.875rem;height:1.5rem;margin-left:0.3125rem}ul.pagination li a,ul.pagination li button{border-radius:5px;transition:background-color 300ms ease-out;background:none;color:#999;display:block;font-size:1em;font-weight:normal;line-height:inherit;padding:0.0625rem 0.625rem 0.0625rem}ul.pagination li:hover a,ul.pagination li a:focus,ul.pagination li:hover button,ul.pagination li button:focus{background:#e6e6e6}ul.pagination li.unavailable a,ul.pagination li.unavailable button{cursor:default;color:#999}ul.pagination li.unavailable:hover a,ul.pagination li.unavailable a:focus,ul.pagination li.unavailable:hover button,ul.pagination li.unavailable button:focus{background:transparent}ul.pagination li.current a,ul.pagination li.current button{background:#22b8eb;color:#fff;cursor:default;font-weight:bold}ul.pagination li.current a:hover,ul.pagination li.current a:focus,ul.pagination li.current button:hover,ul.pagination li.current button:focus{background:#22b8eb}ul.pagination li{display:block;float:left}.pagination-centered{text-align:center}.pagination-centered ul.pagination li{display:inline-block;float:none}.panel{border-style:solid;border-width:1px;border-color:#d8d8d8;margin-bottom:1.25rem;padding:1.25rem;background:#f2f2f2;color:#333}.panel>:first-child{margin-top:0}.panel>:last-child{margin-bottom:0}.panel h1,.panel h2,.panel h3,.panel h4,.panel h5,.panel h6,.panel p,.panel li,.panel dl{color:#333}.panel h1,.panel h2,.panel h3,.panel h4,.panel h5,.panel h6{line-height:1;margin-bottom:0.625rem}.panel h1.subheader,.panel h2.subheader,.panel h3.subheader,.panel h4.subheader,.panel h5.subheader,.panel h6.subheader{line-height:1.4}.panel.callout{border-style:solid;border-width:1px;border-color:#d8d8d8;margin-bottom:1.25rem;padding:1.25rem;background:#f2fbfe;color:#333}.panel.callout>:first-child{margin-top:0}.panel.callout>:last-child{margin-bottom:0}.panel.callout h1,.panel.callout h2,.panel.callout h3,.panel.callout h4,.panel.callout h5,.panel.callout h6,.panel.callout p,.panel.callout li,.panel.callout dl{color:#333}.panel.callout h1,.panel.callout h2,.panel.callout h3,.panel.callout h4,.panel.callout h5,.panel.callout h6{line-height:1;margin-bottom:0.625rem}.panel.callout h1.subheader,.panel.callout h2.subheader,.panel.callout h3.subheader,.panel.callout h4.subheader,.panel.callout h5.subheader,.panel.callout h6.subheader{line-height:1.4}.panel.callout a:not(.button){color:#22b8eb}.panel.callout a:not(.button):hover,.panel.callout a:not(.button):focus{color:#13a3d4}.panel.radius{border-radius:5px}.pricing-table{border:solid 1px #ddd;margin-left:0;margin-bottom:1.25rem}.pricing-table *{list-style:none;line-height:1}.pricing-table .title{background-color:#333;color:#eee;font-family:"Helvetica Neue",Helvetica,Roboto,Arial,sans-serif;font-size:1rem;font-weight:normal;padding:0.9375rem 1.25rem;text-align:center}.pricing-table .price{background-color:#F6F6F6;color:#333;font-family:"Helvetica Neue",Helvetica,Roboto,Arial,sans-serif;font-size:2rem;font-weight:normal;padding:0.9375rem 1.25rem;text-align:center}.pricing-table .description{background-color:#fff;border-bottom:dotted 1px #ddd;color:#777;font-size:0.75rem;font-weight:normal;line-height:1.4;padding:0.9375rem;text-align:center}.pricing-table .bullet-item{background-color:#fff;border-bottom:dotted 1px #ddd;color:#333;font-size:0.875rem;font-weight:normal;padding:0.9375rem;text-align:center}.pricing-table .cta-button{background-color:#fff;padding:1.25rem 1.25rem 0;text-align:center}.progress{background-color:#F6F6F6;border:1px solid #fff;height:1.5625rem;margin-bottom:0.625rem;padding:0.125rem}.progress .meter{background:#22b8eb;display:block;height:100%}.progress.secondary .meter{background:#FF992E;display:block;height:100%}.progress.success .meter{background:#43AC6A;display:block;height:100%}.progress.alert .meter{background:#f04124;display:block;height:100%}.progress.radius{border-radius:5px}.progress.radius .meter{border-radius:4px}.progress.round{border-radius:1000px}.progress.round .meter{border-radius:999px}.range-slider{border:1px solid #ddd;margin:1.25rem 0;position:relative;-ms-touch-action:none;touch-action:none;display:block;height:1rem;width:100%;background:#FAFAFA}.range-slider.vertical-range{border:1px solid #ddd;margin:1.25rem 0;position:relative;-ms-touch-action:none;touch-action:none;display:inline-block;height:12.5rem;width:1rem}.range-slider.vertical-range .range-slider-handle{bottom:-10.5rem;margin-left:-0.5rem;margin-top:0;position:absolute}.range-slider.vertical-range .range-slider-active-segment{border-bottom-left-radius:inherit;border-bottom-right-radius:inherit;border-top-left-radius:initial;bottom:0;height:auto;width:0.875rem}.range-slider.radius{background:#FAFAFA;border-radius:5px}.range-slider.radius .range-slider-handle{background:#22b8eb;border-radius:5px}.range-slider.radius .range-slider-handle:hover{background:#14a7d9}.range-slider.round{background:#FAFAFA;border-radius:1000px}.range-slider.round .range-slider-handle{background:#22b8eb;border-radius:1000px}.range-slider.round .range-slider-handle:hover{background:#14a7d9}.range-slider.disabled,.range-slider[disabled]{background:#FAFAFA;cursor:not-allowed;opacity:0.7}.range-slider.disabled .range-slider-handle,.range-slider[disabled] .range-slider-handle{background:#22b8eb;cursor:default;opacity:0.7}.range-slider.disabled .range-slider-handle:hover,.range-slider[disabled] .range-slider-handle:hover{background:#14a7d9}.range-slider-active-segment{background:#ff982b;border-bottom-left-radius:inherit;border-top-left-radius:inherit;display:inline-block;height:0.875rem;position:absolute}.range-slider-handle{border:1px solid none;cursor:pointer;display:inline-block;height:1.375rem;position:absolute;top:-0.3125rem;width:2rem;z-index:1;-ms-touch-action:manipulation;touch-action:manipulation;background:#22b8eb}.range-slider-handle:hover{background:#14a7d9}.reveal-modal-bg{background:#000;background:rgba(0,0,0,0.45);bottom:0;display:none;left:0;position:fixed;right:0;top:0;z-index:1004;left:0}.reveal-modal{border-radius:5px;display:none;position:absolute;top:0;visibility:hidden;width:100%;z-index:1005;left:0;background-color:#fff;padding:1.875rem;border:solid 1px #666;box-shadow:0 0 10px rgba(0,0,0,0.4)}@media only screen and (max-width: 40em){.reveal-modal{min-height:100vh}}.reveal-modal .column,.reveal-modal .columns{min-width:0}.reveal-modal>:first-child{margin-top:0}.reveal-modal>:last-child{margin-bottom:0}@media only screen and (min-width: 40.0625em){.reveal-modal{left:0;margin:0 auto;max-width:75rem;right:0;width:80%}}@media only screen and (min-width: 40.0625em){.reveal-modal{top:6.25rem}}.reveal-modal.radius{border-radius:5px}.reveal-modal.round{border-radius:1000px}.reveal-modal.collapse{padding:0}@media only screen and (min-width: 40.0625em){.reveal-modal.tiny{left:0;margin:0 auto;max-width:75rem;right:0;width:30%}}@media only screen and (min-width: 40.0625em){.reveal-modal.small{left:0;margin:0 auto;max-width:75rem;right:0;width:40%}}@media only screen and (min-width: 40.0625em){.reveal-modal.medium{left:0;margin:0 auto;max-width:75rem;right:0;width:60%}}@media only screen and (min-width: 40.0625em){.reveal-modal.large{left:0;margin:0 auto;max-width:75rem;right:0;width:70%}}@media only screen and (min-width: 40.0625em){.reveal-modal.xlarge{left:0;margin:0 auto;max-width:75rem;right:0;width:95%}}.reveal-modal.full{height:100vh;height:100%;left:0;margin-left:0 !important;max-width:none !important;min-height:100vh;top:0}@media only screen and (min-width: 40.0625em){.reveal-modal.full{left:0;margin:0 auto;max-width:75rem;right:0;width:100%}}.reveal-modal.toback{z-index:1003}.reveal-modal .close-reveal-modal{color:#aaa;cursor:pointer;font-size:2.5rem;font-weight:bold;line-height:1;position:absolute;top:0.625rem;right:1.375rem}.side-nav{display:block;font-family:"Helvetica Neue",Helvetica,Roboto,Arial,sans-serif;list-style-position:outside;list-style-type:none;margin:0;padding:0.5rem 0}.side-nav li{font-size:0.875rem;font-weight:normal;margin:0 0 0.25rem 0}.side-nav li a:not(.button){color:#22b8eb;display:block;margin:0;padding:0.3125rem 0.625rem}.side-nav li a:not(.button):hover,.side-nav li a:not(.button):focus{background:rgba(0,0,0,0.025);color:#64cdf1}.side-nav li a:not(.button):active{color:#64cdf1}.side-nav li.active>a:first-child:not(.button){color:#64cdf1;font-family:"Helvetica Neue",Helvetica,Roboto,Arial,sans-serif;font-weight:normal}.side-nav li.divider{border-top:1px solid;height:0;list-style:none;padding:0;border-top-color:#e6e6e6}.side-nav li.heading{color:#22b8eb;font-size:0.875rem;font-weight:bold;text-transform:uppercase}.split.button{position:relative;padding-right:5.0625rem}.split.button span{display:block;height:100%;position:absolute;right:0;top:0;border-left:solid 1px}.split.button span:after{position:absolute;content:"";width:0;height:0;display:block;border-style:inset;top:50%;left:50%}.split.button span:active{background-color:rgba(0,0,0,0.1)}.split.button span{border-left-color:rgba(255,255,255,0.5)}.split.button span{width:3.09375rem}.split.button span:after{border-top-style:solid;border-width:0.375rem;margin-left:-0.375rem;top:48%}.split.button span:after{border-color:#fff transparent transparent transparent}.split.button.secondary span{border-left-color:rgba(255,255,255,0.5)}.split.button.secondary span:after{border-color:#fff transparent transparent transparent}.split.button.alert span{border-left-color:rgba(255,255,255,0.5)}.split.button.success span{border-left-color:rgba(255,255,255,0.5)}.split.button.tiny{padding-right:3.75rem}.split.button.tiny span{width:2.25rem}.split.button.tiny span:after{border-top-style:solid;border-width:0.375rem;margin-left:-0.375rem;top:48%}.split.button.small{padding-right:4.375rem}.split.button.small span{width:2.625rem}.split.button.small span:after{border-top-style:solid;border-width:0.4375rem;margin-left:-0.375rem;top:48%}.split.button.large{padding-right:5.5rem}.split.button.large span{width:3.4375rem}.split.button.large span:after{border-top-style:solid;border-width:0.3125rem;margin-left:-0.375rem;top:48%}.split.button.expand{padding-left:2rem}.split.button.secondary span:after{border-color:#333 transparent transparent transparent}.split.button.radius span{-webkit-border-bottom-right-radius:5px;-webkit-border-top-right-radius:5px;border-bottom-right-radius:5px;border-top-right-radius:5px}.split.button.round span{-webkit-border-bottom-right-radius:1000px;-webkit-border-top-right-radius:1000px;border-bottom-right-radius:1000px;border-top-right-radius:1000px}.split.button.no-pip span:before{border-style:none}.split.button.no-pip span:after{border-style:none}.split.button.no-pip span>i{display:block;left:50%;margin-left:-0.28889em;margin-top:-0.48889em;position:absolute;top:50%}.sub-nav{display:block;margin:-0.25rem 0 1.125rem;overflow:hidden;padding-top:0.25rem;width:auto}.sub-nav dt{text-transform:uppercase}.sub-nav dt,.sub-nav dd,.sub-nav li{color:#999;float:left;font-family:"Helvetica Neue",Helvetica,Roboto,Arial,sans-serif;font-size:0.875rem;font-weight:normal;margin-left:1rem;margin-bottom:0}.sub-nav dt a,.sub-nav dd a,.sub-nav li a{color:#999;padding:0.1875rem 1rem;text-decoration:none}.sub-nav dt a:hover,.sub-nav dd a:hover,.sub-nav li a:hover{color:#737373}.sub-nav dt.active a,.sub-nav dd.active a,.sub-nav li.active a{border-radius:3px;background:#22b8eb;color:#fff;cursor:default;font-weight:normal;padding:0.1875rem 1rem}.sub-nav dt.active a:hover,.sub-nav dd.active a:hover,.sub-nav li.active a:hover{background:#13a3d4}.switch{border:none;margin-bottom:1.5rem;outline:0;padding:0;position:relative;-webkit-user-select:none;-moz-user-select:none;-ms-user-select:none;user-select:none}.switch label{background:#ddd;color:transparent;cursor:pointer;display:block;margin-bottom:1rem;position:relative;text-indent:100%;width:4rem;height:2rem;transition:left 0.15s ease-out}.switch input{left:10px;opacity:0;padding:0;position:absolute;top:9px}.switch input+label{margin-left:0;margin-right:0}.switch label:after{background:#fff;content:"";display:block;height:1.5rem;left:.25rem;position:absolute;top:.25rem;width:1.5rem;-webkit-transition:left 0.15s ease-out;-moz-transition:left 0.15s ease-out;-o-transition:translate3d(0, 0, 0);transition:left 0.15s ease-out;-webkit-transform:translate3d(0, 0, 0);-moz-transform:translate3d(0, 0, 0);-ms-transform:translate3d(0, 0, 0);-o-transform:translate3d(0, 0, 0);transform:translate3d(0, 0, 0)}.switch input:checked+label{background:#22b8eb}.switch input:checked+label:after{left:2.25rem}.switch label{height:2rem;width:4rem}.switch label:after{height:1.5rem;width:1.5rem}.switch input:checked+label:after{left:2.25rem}.switch label{color:transparent;background:#ddd}.switch label:after{background:#fff}.switch input:checked+label{background:#22b8eb}.switch.large label{height:2.5rem;width:5rem}.switch.large label:after{height:2rem;width:2rem}.switch.large input:checked+label:after{left:2.75rem}.switch.small label{height:1.75rem;width:3.5rem}.switch.small label:after{height:1.25rem;width:1.25rem}.switch.small input:checked+label:after{left:2rem}.switch.tiny label{height:1.5rem;width:3rem}.switch.tiny label:after{height:1rem;width:1rem}.switch.tiny input:checked+label:after{left:1.75rem}.switch.radius label{border-radius:4px}.switch.radius label:after{border-radius:3px}.switch.round{border-radius:1000px}.switch.round label{border-radius:2rem}.switch.round label:after{border-radius:2rem}table{background:#fff;border:solid 1px #ddd;margin-bottom:1.25rem;table-layout:auto}table caption{background:transparent;color:#222;font-size:1rem;font-weight:bold}table thead{background:#f5f5f5}table thead tr th,table thead tr td{color:#222;font-size:0.875rem;font-weight:bold;padding:0.5rem 0.625rem 0.625rem}table tfoot{background:#f5f5f5}table tfoot tr th,table tfoot tr td{color:#222;font-size:0.875rem;font-weight:bold;padding:0.5rem 0.625rem 0.625rem}table tr th,table tr td{color:#222;font-size:0.875rem;padding:0.5625rem 0.625rem;text-align:left}table tr.even,table tr.alt,table tr:nth-of-type(even){background:#F9F9F9}table thead tr th,table tfoot tr th,table tfoot tr td,table tbody tr th,table tbody tr td,table tr td{display:table-cell;line-height:1.125rem}.tabs{margin-bottom:0 !important;margin-left:0}.tabs:before,.tabs:after{content:" ";display:table}.tabs:after{clear:both}.tabs dd,.tabs .tab-title{float:left;list-style:none;margin-bottom:0 !important;position:relative}.tabs dd>a,.tabs .tab-title>a{display:block;background-color:#EFEFEF;color:#222;font-family:"Helvetica Neue",Helvetica,Roboto,Arial,sans-serif;font-size:1rem;padding:1rem 2rem}.tabs dd>a:hover,.tabs .tab-title>a:hover{background-color:#e1e1e1}.tabs dd.active a,.tabs .tab-title.active a{background-color:#fff;color:#222}.tabs.radius dd:first-child a,.tabs.radius .tab:first-child a{-webkit-border-bottom-left-radius:5px;-webkit-border-top-left-radius:5px;border-bottom-left-radius:5px;border-top-left-radius:5px}.tabs.radius dd:last-child a,.tabs.radius .tab:last-child a{-webkit-border-bottom-right-radius:5px;-webkit-border-top-right-radius:5px;border-bottom-right-radius:5px;border-top-right-radius:5px}.tabs.vertical dd,.tabs.vertical .tab-title{position:inherit;float:none;display:block;top:auto}.tabs-content{margin-bottom:1.5rem;width:100%}.tabs-content:before,.tabs-content:after{content:" ";display:table}.tabs-content:after{clear:both}.tabs-content>.content{display:none;float:left;padding:0.9375rem 0;width:100%}.tabs-content>.content.active{display:block;float:none}.tabs-content>.content.contained{padding:0.9375rem}.tabs-content.vertical{display:block}.tabs-content.vertical>.content{padding:0 0.9375rem}@media only screen and (min-width: 40.0625em){.tabs.vertical{float:left;margin:0;margin-bottom:1.25rem !important;max-width:20%;width:20%}.tabs-content.vertical{float:left;margin-left:-1px;max-width:80%;padding-left:1rem;width:80%}}.no-js .tabs-content>.content{display:block;float:none}.th{border:solid 4px #fff;box-shadow:0 0 0 1px rgba(0,0,0,0.2);display:inline-block;line-height:0;max-width:100%;transition:all 200ms ease-out}.th:hover,.th:focus{box-shadow:0 0 6px 1px rgba(34,184,235,0.5)}.th.radius{border-radius:5px}.has-tip{border-bottom:dotted 1px #ccc;color:#333;cursor:help;font-weight:bold}.has-tip:hover,.has-tip:focus{border-bottom:dotted 1px #0a556f;color:#22b8eb}.has-tip.tip-left,.has-tip.tip-right{float:none !important}.tooltip{background:#333;color:#fff;display:none;font-size:0.875rem;font-weight:normal;line-height:1.3;max-width:300px;padding:0.75rem;position:absolute;width:100%;z-index:1006;left:50%}.tooltip>.nub{border-color:transparent transparent #333 transparent;border:solid 5px;display:block;height:0;pointer-events:none;position:absolute;top:-10px;width:0;left:5px}.tooltip>.nub.rtl{left:auto;right:5px}.tooltip.radius{border-radius:5px}.tooltip.round{border-radius:1000px}.tooltip.round>.nub{left:2rem}.tooltip.opened{border-bottom:dotted 1px #0a556f !important;color:#22b8eb !important}.tap-to-close{color:#777;display:block;font-size:0.625rem;font-weight:normal}@media only screen and (min-width: 40.0625em){.tooltip>.nub{border-color:transparent transparent #333 transparent;top:-10px}.tooltip.tip-top>.nub{border-color:#333 transparent transparent transparent;bottom:-10px;top:auto}.tooltip.tip-left,.tooltip.tip-right{float:none !important}.tooltip.tip-left>.nub{border-color:transparent transparent transparent #333;left:auto;margin-top:-5px;right:-10px;top:50%}.tooltip.tip-right>.nub{border-color:transparent #333 transparent transparent;left:-10px;margin-top:-5px;right:auto;top:50%}}meta.foundation-mq-topbar{font-family:"/only screen and (min-width:40.0625em)/";width:40.0625em}.contain-to-grid{width:100%;background:#333}.contain-to-grid .top-bar{margin-bottom:0}.fixed{position:fixed;top:0;width:100%;z-index:99;left:0}.fixed.expanded:not(.top-bar){height:auto;max-height:100%;overflow-y:auto;width:100%}.fixed.expanded:not(.top-bar) .title-area{position:fixed;width:100%;z-index:99}.fixed.expanded:not(.top-bar) .top-bar-section{margin-top:2.8125rem;z-index:98}.top-bar{background:#333;height:2.8125rem;line-height:2.8125rem;margin-bottom:0;overflow:hidden;position:relative}.top-bar ul{list-style:none;margin-bottom:0}.top-bar .row{max-width:none}.top-bar form,.top-bar input,.top-bar select{margin-bottom:0}.top-bar input,.top-bar select{font-size:0.75rem;height:1.75rem;padding-bottom:.35rem;padding-top:.35rem}.top-bar .button,.top-bar button{font-size:0.75rem;margin-bottom:0;padding-bottom:0.4125rem;padding-top:0.4125rem}@media only screen and (max-width: 40em){.top-bar .button,.top-bar button{position:relative;top:-1px}}.top-bar .title-area{margin:0;position:relative}.top-bar .name{font-size:16px;height:2.8125rem;margin:0}.top-bar .name h1,.top-bar .name h2,.top-bar .name h3,.top-bar .name h4,.top-bar .name p,.top-bar .name span{font-size:1.0625rem;line-height:2.8125rem;margin:0}.top-bar .name h1 a,.top-bar .name h2 a,.top-bar .name h3 a,.top-bar .name h4 a,.top-bar .name p a,.top-bar .name span a{color:#fff;display:block;font-weight:normal;padding:0 0.9375rem;width:75%}.top-bar .toggle-topbar{position:absolute;right:0;top:0}.top-bar .toggle-topbar a{color:#fff;display:block;font-size:0.8125rem;font-weight:bold;height:2.8125rem;line-height:2.8125rem;padding:0 0.9375rem;position:relative;text-transform:uppercase}.top-bar .toggle-topbar.menu-icon{margin-top:-16px;top:50%}.top-bar .toggle-topbar.menu-icon a{color:#fff;height:34px;line-height:33px;padding:0 2.5rem 0 0.9375rem;position:relative}.top-bar .toggle-topbar.menu-icon a span::after{content:"";display:block;height:0;position:absolute;margin-top:-8px;top:50%;right:0.9375rem;box-shadow:0 0 0 1px #fff,0 7px 0 1px #fff,0 14px 0 1px #fff;width:16px}.top-bar .toggle-topbar.menu-icon a span:hover:after{box-shadow:0 0 0 1px "",0 7px 0 1px "",0 14px 0 1px ""}.top-bar.expanded{background:transparent;height:auto}.top-bar.expanded .title-area{background:#333}.top-bar.expanded .toggle-topbar a{color:#888}.top-bar.expanded .toggle-topbar a span::after{box-shadow:0 0 0 1px #888,0 7px 0 1px #888,0 14px 0 1px #888}@media screen and (-webkit-min-device-pixel-ratio: 0){.top-bar.expanded .top-bar-section .has-dropdown.moved>.dropdown,.top-bar.expanded .top-bar-section .dropdown{clip:initial}.top-bar.expanded .top-bar-section .has-dropdown:not(.moved)>ul{padding:0}}.top-bar-section{left:0;position:relative;width:auto;transition:left 300ms ease-out}.top-bar-section ul{display:block;font-size:16px;height:auto;margin:0;padding:0;width:100%}.top-bar-section .divider,.top-bar-section [role="separator"]{border-top:solid 1px #1a1a1a;clear:both;height:1px;width:100%}.top-bar-section ul li{background:#333}.top-bar-section ul li>a{color:#fff;display:block;font-family:"Helvetica Neue",Helvetica,Roboto,Arial,sans-serif;font-size:0.8125rem;font-weight:normal;padding-left:0.9375rem;padding:12px 0 12px 0.9375rem;text-transform:none;width:100%}.top-bar-section ul li>a.button{font-size:0.8125rem;padding-left:0.9375rem;padding-right:0.9375rem;background-color:#22b8eb;border-color:#1298c5;color:#fff}.top-bar-section ul li>a.button:hover,.top-bar-section ul li>a.button:focus{background-color:#1298c5}.top-bar-section ul li>a.button:hover,.top-bar-section ul li>a.button:focus{color:#fff}.top-bar-section ul li>a.button.secondary{background-color:#FF992E;border-color:#f17b00;color:#fff}.top-bar-section ul li>a.button.secondary:hover,.top-bar-section ul li>a.button.secondary:focus{background-color:#f17b00}.top-bar-section ul li>a.button.secondary:hover,.top-bar-section ul li>a.button.secondary:focus{color:#fff}.top-bar-section ul li>a.button.success{background-color:#43AC6A;border-color:#368a55;color:#fff}.top-bar-section ul li>a.button.success:hover,.top-bar-section ul li>a.button.success:focus{background-color:#368a55}.top-bar-section ul li>a.button.success:hover,.top-bar-section ul li>a.button.success:focus{color:#fff}.top-bar-section ul li>a.button.alert{background-color:#f04124;border-color:#cf2a0e;color:#fff}.top-bar-section ul li>a.button.alert:hover,.top-bar-section ul li>a.button.alert:focus{background-color:#cf2a0e}.top-bar-section ul li>a.button.alert:hover,.top-bar-section ul li>a.button.alert:focus{color:#fff}.top-bar-section ul li>a.button.warning{background-color:#f08a24;border-color:#cf6e0e;color:#fff}.top-bar-section ul li>a.button.warning:hover,.top-bar-section ul li>a.button.warning:focus{background-color:#cf6e0e}.top-bar-section ul li>a.button.warning:hover,.top-bar-section ul li>a.button.warning:focus{color:#fff}.top-bar-section ul li>a.button.info{background-color:#a0d3e8;border-color:#61b6d9;color:#333}.top-bar-section ul li>a.button.info:hover,.top-bar-section ul li>a.button.info:focus{background-color:#61b6d9}.top-bar-section ul li>a.button.info:hover,.top-bar-section ul li>a.button.info:focus{color:#fff}.top-bar-section ul li>button{font-size:0.8125rem;padding-left:0.9375rem;padding-right:0.9375rem;background-color:#22b8eb;border-color:#1298c5;color:#fff}.top-bar-section ul li>button:hover,.top-bar-section ul li>button:focus{background-color:#1298c5}.top-bar-section ul li>button:hover,.top-bar-section ul li>button:focus{color:#fff}.top-bar-section ul li>button.secondary{background-color:#FF992E;border-color:#f17b00;color:#fff}.top-bar-section ul li>button.secondary:hover,.top-bar-section ul li>button.secondary:focus{background-color:#f17b00}.top-bar-section ul li>button.secondary:hover,.top-bar-section ul li>button.secondary:focus{color:#fff}.top-bar-section ul li>button.success{background-color:#43AC6A;border-color:#368a55;color:#fff}.top-bar-section ul li>button.success:hover,.top-bar-section ul li>button.success:focus{background-color:#368a55}.top-bar-section ul li>button.success:hover,.top-bar-section ul li>button.success:focus{color:#fff}.top-bar-section ul li>button.alert{background-color:#f04124;border-color:#cf2a0e;color:#fff}.top-bar-section ul li>button.alert:hover,.top-bar-section ul li>button.alert:focus{background-color:#cf2a0e}.top-bar-section ul li>button.alert:hover,.top-bar-section ul li>button.alert:focus{color:#fff}.top-bar-section ul li>button.warning{background-color:#f08a24;border-color:#cf6e0e;color:#fff}.top-bar-section ul li>button.warning:hover,.top-bar-section ul li>button.warning:focus{background-color:#cf6e0e}.top-bar-section ul li>button.warning:hover,.top-bar-section ul li>button.warning:focus{color:#fff}.top-bar-section ul li>button.info{background-color:#a0d3e8;border-color:#61b6d9;color:#333}.top-bar-section ul li>button.info:hover,.top-bar-section ul li>button.info:focus{background-color:#61b6d9}.top-bar-section ul li>button.info:hover,.top-bar-section ul li>button.info:focus{color:#fff}.top-bar-section ul li:hover:not(.has-form)>a{background-color:#555;color:#fff;background:#222}.top-bar-section ul li.active>a{background:#22b8eb;color:#fff}.top-bar-section ul li.active>a:hover{background:#13a3d4;color:#fff}.top-bar-section .has-form{padding:0.9375rem}.top-bar-section .has-dropdown{position:relative}.top-bar-section .has-dropdown>a:after{border:inset 5px;content:"";display:block;height:0;width:0;border-color:transparent transparent transparent rgba(255,255,255,0.4);border-left-style:solid;margin-right:0.9375rem;margin-top:-4.5px;position:absolute;top:50%;right:0}.top-bar-section .has-dropdown.moved{position:static}.top-bar-section .has-dropdown.moved>.dropdown{position:static !important;height:auto;width:auto;overflow:visible;clip:auto;display:block;position:absolute !important;width:100%}.top-bar-section .has-dropdown.moved>a:after{display:none}.top-bar-section .dropdown{clip:rect(1px, 1px, 1px, 1px);height:1px;overflow:hidden;position:absolute !important;width:1px;display:block;padding:0;position:absolute;top:0;z-index:99;left:100%}.top-bar-section .dropdown li{height:auto;width:100%}.top-bar-section .dropdown li a{font-weight:normal;padding:8px 0.9375rem}.top-bar-section .dropdown li a.parent-link{font-weight:normal}.top-bar-section .dropdown li.title h5,.top-bar-section .dropdown li.parent-link{margin-bottom:0;margin-top:0;font-size:1.125rem}.top-bar-section .dropdown li.title h5 a,.top-bar-section .dropdown li.parent-link a{color:#fff;display:block}.top-bar-section .dropdown li.title h5 a:hover,.top-bar-section .dropdown li.parent-link a:hover{background:none}.top-bar-section .dropdown li.has-form{padding:8px 0.9375rem}.top-bar-section .dropdown li .button,.top-bar-section .dropdown li button{top:auto}.top-bar-section .dropdown label{color:#777;font-size:0.625rem;font-weight:bold;margin-bottom:0;padding:8px 0.9375rem 2px;text-transform:uppercase}.js-generated{display:block}@media only screen and (min-width: 40.0625em){.top-bar{background:#333;overflow:visible}.top-bar:before,.top-bar:after{content:" ";display:table}.top-bar:after{clear:both}.top-bar .toggle-topbar{display:none}.top-bar .title-area{float:left}.top-bar .name h1 a,.top-bar .name h2 a,.top-bar .name h3 a,.top-bar .name h4 a,.top-bar .name h5 a,.top-bar .name h6 a{width:auto}.top-bar input,.top-bar select,.top-bar .button,.top-bar button{font-size:0.875rem;height:1.75rem;position:relative;top:0.53125rem}.top-bar.expanded{background:#333}.contain-to-grid .top-bar{margin-bottom:0;margin:0 auto;max-width:75rem}.top-bar-section{transition:none 0 0;left:0 !important}.top-bar-section ul{display:inline;height:auto !important;width:auto}.top-bar-section ul li{float:left}.top-bar-section ul li .js-generated{display:none}.top-bar-section li.hover>a:not(.button){background-color:#555;background:#222;color:#fff}.top-bar-section li:not(.has-form) a:not(.button){background:#333;line-height:2.8125rem;padding:0 0.9375rem}.top-bar-section li:not(.has-form) a:not(.button):hover{background-color:#555;background:#222}.top-bar-section li.active:not(.has-form) a:not(.button){background:#22b8eb;color:#fff;line-height:2.8125rem;padding:0 0.9375rem}.top-bar-section li.active:not(.has-form) a:not(.button):hover{background:#13a3d4;color:#fff}.top-bar-section .has-dropdown>a{padding-right:2.1875rem !important}.top-bar-section .has-dropdown>a:after{border:inset 5px;content:"";display:block;height:0;width:0;border-color:rgba(255,255,255,0.4) transparent transparent transparent;border-top-style:solid;margin-top:-2.5px;top:1.40625rem}.top-bar-section .has-dropdown.moved{position:relative}.top-bar-section .has-dropdown.moved>.dropdown{clip:rect(1px, 1px, 1px, 1px);height:1px;overflow:hidden;position:absolute !important;width:1px;display:block}.top-bar-section .has-dropdown.hover>.dropdown,.top-bar-section .has-dropdown.not-click:hover>.dropdown{position:static !important;height:auto;width:auto;overflow:visible;clip:auto;display:block;position:absolute !important}.top-bar-section .has-dropdown>a:focus+.dropdown{position:static !important;height:auto;width:auto;overflow:visible;clip:auto;display:block;position:absolute !important}.top-bar-section .has-dropdown .dropdown li.has-dropdown>a:after{border:none;content:"\00bb";top:0.1875rem;right:5px}.top-bar-section .dropdown{left:0;background:transparent;min-width:100%;top:auto}.top-bar-section .dropdown li a{background:#333;color:#fff;line-height:2.8125rem;padding:12px 0.9375rem;white-space:nowrap}.top-bar-section .dropdown li:not(.has-form):not(.active)>a:not(.button){background:#333;color:#fff}.top-bar-section .dropdown li:not(.has-form):not(.active):hover>a:not(.button){background-color:#555;color:#fff;background:#222}.top-bar-section .dropdown li label{background:#333;white-space:nowrap}.top-bar-section .dropdown li .dropdown{left:100%;top:0}.top-bar-section>ul>.divider,.top-bar-section>ul>[role="separator"]{border-right:solid 1px #4e4e4e;border-bottom:none;border-top:none;clear:none;height:2.8125rem;width:0}.top-bar-section .has-form{background:#333;height:2.8125rem;padding:0 0.9375rem}.top-bar-section .right li .dropdown{left:auto;right:0}.top-bar-section .right li .dropdown li .dropdown{right:100%}.top-bar-section .left li .dropdown{right:auto;left:0}.top-bar-section .left li .dropdown li .dropdown{left:100%}.no-js .top-bar-section ul li:hover>a{background-color:#555;background:#222;color:#fff}.no-js .top-bar-section ul li:active>a{background:#22b8eb;color:#fff}.no-js .top-bar-section .has-dropdown:hover>.dropdown{position:static !important;height:auto;width:auto;overflow:visible;clip:auto;display:block;position:absolute !important}.no-js .top-bar-section .has-dropdown>a:focus+.dropdown{position:static !important;height:auto;width:auto;overflow:visible;clip:auto;display:block;position:absolute !important}}.text-left{text-align:left !important}.text-right{text-align:right !important}.text-center{text-align:center !important}.text-justify{text-align:justify !important}@media only screen and (max-width: 40em){.small-only-text-left{text-align:left !important}.small-only-text-right{text-align:right !important}.small-only-text-center{text-align:center !important}.small-only-text-justify{text-align:justify !important}}@media only screen{.small-text-left{text-align:left !important}.small-text-right{text-align:right !important}.small-text-center{text-align:center !important}.small-text-justify{text-align:justify !important}}@media only screen and (min-width: 40.0625em) and (max-width: 58.75em){.medium-only-text-left{text-align:left !important}.medium-only-text-right{text-align:right !important}.medium-only-text-center{text-align:center !important}.medium-only-text-justify{text-align:justify !important}}@media only screen and (min-width: 40.0625em){.medium-text-left{text-align:left !important}.medium-text-right{text-align:right !important}.medium-text-center{text-align:center !important}.medium-text-justify{text-align:justify !important}}@media only screen and (min-width: 58.8125em) and (max-width: 90em){.large-only-text-left{text-align:left !important}.large-only-text-right{text-align:right !important}.large-only-text-center{text-align:center !important}.large-only-text-justify{text-align:justify !important}}@media only screen and (min-width: 58.8125em){.large-text-left{text-align:left !important}.large-text-right{text-align:right !important}.large-text-center{text-align:center !important}.large-text-justify{text-align:justify !important}}@media only screen and (min-width: 90.0625em) and (max-width: 120em){.xlarge-only-text-left{text-align:left !important}.xlarge-only-text-right{text-align:right !important}.xlarge-only-text-center{text-align:center !important}.xlarge-only-text-justify{text-align:justify !important}}@media only screen and (min-width: 90.0625em){.xlarge-text-left{text-align:left !important}.xlarge-text-right{text-align:right !important}.xlarge-text-center{text-align:center !important}.xlarge-text-justify{text-align:justify !important}}@media only screen and (min-width: 120.0625em) and (max-width: 6249999.9375em){.xxlarge-only-text-left{text-align:left !important}.xxlarge-only-text-right{text-align:right !important}.xxlarge-only-text-center{text-align:center !important}.xxlarge-only-text-justify{text-align:justify !important}}@media only screen and (min-width: 120.0625em){.xxlarge-text-left{text-align:left !important}.xxlarge-text-right{text-align:right !important}.xxlarge-text-center{text-align:center !important}.xxlarge-text-justify{text-align:justify !important}}div,dl,dt,dd,ul,ol,li,h1,h2,h3,h4,h5,h6,pre,form,p,blockquote,th,td{margin:0;padding:0}a{color:#FF992E;line-height:inherit;text-decoration:none}a:hover,a:focus{color:#ff8404}a img{border:none}p{font-family:inherit;font-size:1rem;font-weight:300;line-height:1.6;margin-bottom:1.25rem;text-rendering:optimizeLegibility}p.lead{font-size:1.21875rem;line-height:1.6}p aside{font-size:0.875rem;font-style:italic;line-height:1.35}h1,h2,h3,h4,h5,h6{color:#22b8eb;font-family:"Helvetica Neue",Helvetica,Roboto,Arial,sans-serif;font-style:normal;font-weight:100;line-height:1.4;margin-bottom:0.5rem;margin-top:0.2rem;text-rendering:optimizeLegibility}h1 small,h2 small,h3 small,h4 small,h5 small,h6 small{color:#6fd1f2;font-size:60%;line-height:0}h1{font-size:2.25rem}h2{font-size:1.8125rem}h3{font-size:1.5rem}h4{font-size:1.25rem}h5{font-size:1.125rem}h6{font-size:1rem}.subheader{line-height:1.4;color:#6fd1f2;font-weight:normal;margin-top:0.2rem;margin-bottom:0.5rem}hr{border:solid #efefef;border-width:1px 0 0;clear:both;height:0;margin:1.25rem 0 1.1875rem}em,i{font-style:italic;line-height:inherit}strong,b{font-weight:bold;line-height:inherit}small{font-size:60%;line-height:inherit}code{background-color:#ffe0c0;border-color:#ffcb94;border-style:solid;border-width:1px;color:#333;font-family:Consolas,"Liberation Mono",Courier,monospace;font-weight:normal;padding:0.125rem 0.3125rem 0.0625rem}ul,ol,dl{font-family:inherit;font-size:1rem;line-height:1.6;list-style-position:outside;margin-bottom:1.25rem}ul{margin-left:1.1rem}ul.no-bullet{margin-left:0}ul.no-bullet li ul,ul.no-bullet li ol{margin-left:1.25rem;margin-bottom:0;list-style:none}ul li ul,ul li ol{margin-left:1.25rem;margin-bottom:0}ul.square li ul,ul.circle li ul,ul.disc li ul{list-style:inherit}ul.square{list-style-type:square;margin-left:1.1rem}ul.circle{list-style-type:circle;margin-left:1.1rem}ul.disc{list-style-type:disc;margin-left:1.1rem}ul.no-bullet{list-style:none}ol{margin-left:1.4rem}ol li ul,ol li ol{margin-left:1.25rem;margin-bottom:0}dl dt{margin-bottom:0.3rem;font-weight:bold}dl dd{margin-bottom:0.75rem}abbr,acronym{text-transform:uppercase;font-size:90%;color:#7A8491;cursor:help}abbr{text-transform:none}abbr[title]{border-bottom:1px dotted #ddd}blockquote{margin:0 0 1.25rem;padding:0.5625rem 1.25rem 0 1.1875rem;border-left:0 solid #000}blockquote cite{display:block;font-size:0.8125rem;color:#55c8f0}blockquote cite:before{content:"\2014 \0020"}blockquote cite a,blockquote cite a:visited{color:#55c8f0}blockquote,blockquote p{line-height:1.6;color:#22b8eb}.vcard{display:inline-block;margin:0 0 1.25rem 0;border:1px solid #ddd;padding:0.625rem 0.75rem}.vcard li{margin:0;display:block}.vcard .fn{font-weight:bold;font-size:0.9375rem}.vevent .summary{font-weight:bold}.vevent abbr{cursor:default;text-decoration:none;font-weight:bold;border:none;padding:0 0.0625rem}@media only screen and (min-width: 40.0625em){h1,h2,h3,h4,h5,h6{line-height:1.4}h1{font-size:2.75rem}h2{font-size:2.3125rem}h3{font-size:1.6875rem}h4{font-size:1.4375rem}h5{font-size:1.125rem}h6{font-size:1rem}}.off-canvas-wrap{-webkit-backface-visibility:hidden;position:relative;width:100%;overflow:hidden}.off-canvas-wrap.move-right,.off-canvas-wrap.move-left{min-height:100%;-webkit-overflow-scrolling:touch}.inner-wrap{position:relative;width:100%;-webkit-transition:-webkit-transform 500ms ease;-moz-transition:-moz-transform 500ms ease;-ms-transition:-ms-transform 500ms ease;-o-transition:-o-transform 500ms ease;transition:transform 500ms ease}.inner-wrap:before,.inner-wrap:after{content:" ";display:table}.inner-wrap:after{clear:both}.tab-bar{-webkit-backface-visibility:hidden;background:#333;color:#fff;height:2.8125rem;line-height:2.8125rem;position:relative}.tab-bar h1,.tab-bar h2,.tab-bar h3,.tab-bar h4,.tab-bar h5,.tab-bar h6{color:#fff;font-weight:300;line-height:2.8125rem;margin:0}.tab-bar h1,.tab-bar h2,.tab-bar h3,.tab-bar h4{font-size:1.125rem}.left-small{height:2.8125rem;position:absolute;top:0;width:2.8125rem;border-right:solid 1px #1a1a1a;left:0}.right-small{height:2.8125rem;position:absolute;top:0;width:2.8125rem;border-left:solid 1px #1a1a1a;right:0}.tab-bar-section{height:2.8125rem;padding:0 0.625rem;position:absolute;text-align:center;top:0}.tab-bar-section.left{text-align:left}.tab-bar-section.right{text-align:right}.tab-bar-section.left{left:0;right:2.8125rem}.tab-bar-section.right{left:2.8125rem;right:0}.tab-bar-section.middle{left:2.8125rem;right:2.8125rem}.tab-bar .menu-icon{color:#fff;display:block;height:2.8125rem;padding:0;position:relative;text-indent:2.1875rem;transform:translate3d(0, 0, 0);width:2.8125rem}.tab-bar .menu-icon span::after{content:"";display:block;height:0;position:absolute;top:50%;margin-top:-0.5rem;left:0.90625rem;box-shadow:0 0 0 1px #fff,0 7px 0 1px #fff,0 14px 0 1px #fff;width:1rem}.tab-bar .menu-icon span:hover:after{box-shadow:0 0 0 1px #b3b3b3,0 7px 0 1px #b3b3b3,0 14px 0 1px #b3b3b3}.left-off-canvas-menu{-webkit-backface-visibility:hidden;background:#134a6a;bottom:0;box-sizing:content-box;-webkit-overflow-scrolling:touch;-ms-overflow-style:-ms-autohiding-scrollbar;overflow-x:hidden;overflow-y:auto;position:absolute;top:0;transition:transform 500ms ease 0s;width:15.625rem;z-index:1001;-webkit-transform:translate3d(-100%, 0, 0);-moz-transform:translate3d(-100%, 0, 0);-ms-transform:translate(-100%, 0);-ms-transform:translate3d(-100%, 0, 0);-o-transform:translate3d(-100%, 0, 0);transform:translate3d(-100%, 0, 0);left:0}.left-off-canvas-menu *{-webkit-backface-visibility:hidden}.right-off-canvas-menu{-webkit-backface-visibility:hidden;background:#134a6a;bottom:0;box-sizing:content-box;-webkit-overflow-scrolling:touch;-ms-overflow-style:-ms-autohiding-scrollbar;overflow-x:hidden;overflow-y:auto;position:absolute;top:0;transition:transform 500ms ease 0s;width:15.625rem;z-index:1001;-webkit-transform:translate3d(100%, 0, 0);-moz-transform:translate3d(100%, 0, 0);-ms-transform:translate(100%, 0);-ms-transform:translate3d(100%, 0, 0);-o-transform:translate3d(100%, 0, 0);transform:translate3d(100%, 0, 0);right:0}.right-off-canvas-menu *{-webkit-backface-visibility:hidden}ul.off-canvas-list{list-style-type:none;margin:0;padding:0}ul.off-canvas-list li label{background:#129ac8;border-bottom:none;border-top:1px solid #15aee3;color:#fff;display:block;font-size:0.75rem;font-weight:300;margin:0;padding:0.3rem 0.9375rem;text-transform:uppercase}ul.off-canvas-list li a{border-bottom:1px solid #103f5a;color:#fff;display:block;padding:0.4rem;transition:background 300ms ease}ul.off-canvas-list li a:hover{background:#242424}ul.off-canvas-list li a:active{background:#242424}.move-right>.inner-wrap{-webkit-transform:translate3d(15.625rem, 0, 0);-moz-transform:translate3d(15.625rem, 0, 0);-ms-transform:translate(15.625rem, 0);-ms-transform:translate3d(15.625rem, 0, 0);-o-transform:translate3d(15.625rem, 0, 0);transform:translate3d(15.625rem, 0, 0)}.move-right .exit-off-canvas{-webkit-backface-visibility:hidden;box-shadow:-2px 0 2px rgba(0,0,0,0.2),2px 0 2px rgba(0,0,0,0.2);cursor:pointer;transition:background 500ms ease;-webkit-tap-highlight-color:transparent;background:rgba(0,0,0,0.2);bottom:0;display:block;left:0;position:absolute;right:0;top:0;z-index:1002}@media only screen and (min-width: 40.0625em){.move-right .exit-off-canvas:hover{background:rgba(0,0,0,0.35)}}.move-left>.inner-wrap{-webkit-transform:translate3d(-15.625rem, 0, 0);-moz-transform:translate3d(-15.625rem, 0, 0);-ms-transform:translate(-15.625rem, 0);-ms-transform:translate3d(-15.625rem, 0, 0);-o-transform:translate3d(-15.625rem, 0, 0);transform:translate3d(-15.625rem, 0, 0)}.move-left .exit-off-canvas{-webkit-backface-visibility:hidden;box-shadow:-2px 0 2px rgba(0,0,0,0.2),2px 0 2px rgba(0,0,0,0.2);cursor:pointer;transition:background 500ms ease;-webkit-tap-highlight-color:transparent;background:rgba(0,0,0,0.2);bottom:0;display:block;left:0;position:absolute;right:0;top:0;z-index:1002}@media only screen and (min-width: 40.0625em){.move-left .exit-off-canvas:hover{background:rgba(0,0,0,0.35)}}.offcanvas-overlap .left-off-canvas-menu,.offcanvas-overlap .right-off-canvas-menu{-ms-transform:none;-webkit-transform:none;-moz-transform:none;-o-transform:none;transform:none;z-index:1003}.offcanvas-overlap .exit-off-canvas{-webkit-backface-visibility:hidden;box-shadow:-2px 0 2px rgba(0,0,0,0.2),2px 0 2px rgba(0,0,0,0.2);cursor:pointer;transition:background 500ms ease;-webkit-tap-highlight-color:transparent;background:rgba(0,0,0,0.2);bottom:0;display:block;left:0;position:absolute;right:0;top:0;z-index:1002}@media only screen and (min-width: 40.0625em){.offcanvas-overlap .exit-off-canvas:hover{background:rgba(0,0,0,0.35)}}.offcanvas-overlap-left .right-off-canvas-menu{-ms-transform:none;-webkit-transform:none;-moz-transform:none;-o-transform:none;transform:none;z-index:1003}.offcanvas-overlap-left .exit-off-canvas{-webkit-backface-visibility:hidden;box-shadow:-2px 0 2px rgba(0,0,0,0.2),2px 0 2px rgba(0,0,0,0.2);cursor:pointer;transition:background 500ms ease;-webkit-tap-highlight-color:transparent;background:rgba(0,0,0,0.2);bottom:0;display:block;left:0;position:absolute;right:0;top:0;z-index:1002}@media only screen and (min-width: 40.0625em){.offcanvas-overlap-left .exit-off-canvas:hover{background:rgba(0,0,0,0.35)}}.offcanvas-overlap-right .left-off-canvas-menu{-ms-transform:none;-webkit-transform:none;-moz-transform:none;-o-transform:none;transform:none;z-index:1003}.offcanvas-overlap-right .exit-off-canvas{-webkit-backface-visibility:hidden;box-shadow:-2px 0 2px rgba(0,0,0,0.2),2px 0 2px rgba(0,0,0,0.2);cursor:pointer;transition:background 500ms ease;-webkit-tap-highlight-color:transparent;background:rgba(0,0,0,0.2);bottom:0;display:block;left:0;position:absolute;right:0;top:0;z-index:1002}@media only screen and (min-width: 40.0625em){.offcanvas-overlap-right .exit-off-canvas:hover{background:rgba(0,0,0,0.35)}}.no-csstransforms .left-off-canvas-menu{left:-15.625rem}.no-csstransforms .right-off-canvas-menu{right:-15.625rem}.no-csstransforms .move-left>.inner-wrap{right:15.625rem}.no-csstransforms .move-right>.inner-wrap{left:15.625rem}.left-submenu{-webkit-backface-visibility:hidden;-webkit-overflow-scrolling:touch;background:#134a6a;bottom:0;box-sizing:content-box;margin:0;overflow-x:hidden;overflow-y:auto;position:absolute;top:0;width:15.625rem;z-index:1002;-webkit-transform:translate3d(-100%, 0, 0);-moz-transform:translate3d(-100%, 0, 0);-ms-transform:translate(-100%, 0);-ms-transform:translate3d(-100%, 0, 0);-o-transform:translate3d(-100%, 0, 0);transform:translate3d(-100%, 0, 0);left:0;-webkit-transition:-webkit-transform 500ms ease;-moz-transition:-moz-transform 500ms ease;-ms-transition:-ms-transform 500ms ease;-o-transition:-o-transform 500ms ease;transition:transform 500ms ease}.left-submenu *{-webkit-backface-visibility:hidden}.left-submenu .back>a{background:#129ac8;border-bottom:none;border-top:1px solid #15aee3;color:#fff;font-weight:300;padding:0.3rem 0.9375rem;text-transform:uppercase;margin:0}.left-submenu .back>a:hover{background:#29baec;border-bottom:none;border-top:1px solid #19b5ea}.left-submenu .back>a:before{content:"\AB";margin-right:.5rem;display:inline}.left-submenu.move-right,.left-submenu.offcanvas-overlap-right,.left-submenu.offcanvas-overlap{-webkit-transform:translate3d(0%, 0, 0);-moz-transform:translate3d(0%, 0, 0);-ms-transform:translate(0%, 0);-ms-transform:translate3d(0%, 0, 0);-o-transform:translate3d(0%, 0, 0);transform:translate3d(0%, 0, 0)}.right-submenu{-webkit-backface-visibility:hidden;-webkit-overflow-scrolling:touch;background:#134a6a;bottom:0;box-sizing:content-box;margin:0;overflow-x:hidden;overflow-y:auto;position:absolute;top:0;width:15.625rem;z-index:1002;-webkit-transform:translate3d(100%, 0, 0);-moz-transform:translate3d(100%, 0, 0);-ms-transform:translate(100%, 0);-ms-transform:translate3d(100%, 0, 0);-o-transform:translate3d(100%, 0, 0);transform:translate3d(100%, 0, 0);right:0;-webkit-transition:-webkit-transform 500ms ease;-moz-transition:-moz-transform 500ms ease;-ms-transition:-ms-transform 500ms ease;-o-transition:-o-transform 500ms ease;transition:transform 500ms ease}.right-submenu *{-webkit-backface-visibility:hidden}.right-submenu .back>a{background:#129ac8;border-bottom:none;border-top:1px solid #15aee3;color:#fff;font-weight:300;padding:0.3rem 0.9375rem;text-transform:uppercase;margin:0}.right-submenu .back>a:hover{background:#29baec;border-bottom:none;border-top:1px solid #19b5ea}.right-submenu .back>a:after{content:"\BB";margin-left:.5rem;display:inline}.right-submenu.move-left,.right-submenu.offcanvas-overlap-left,.right-submenu.offcanvas-overlap{-webkit-transform:translate3d(0%, 0, 0);-moz-transform:translate3d(0%, 0, 0);-ms-transform:translate(0%, 0);-ms-transform:translate3d(0%, 0, 0);-o-transform:translate3d(0%, 0, 0);transform:translate3d(0%, 0, 0)}.left-off-canvas-menu ul.off-canvas-list li.has-submenu>a:after{content:"\BB";margin-left:.5rem;display:inline}.right-off-canvas-menu ul.off-canvas-list li.has-submenu>a:before{content:"\AB";margin-right:.5rem;display:inline}@media only screen{.show-for-small-only,.show-for-small-up,.show-for-small,.show-for-small-down,.hide-for-medium-only,.hide-for-medium-up,.hide-for-medium,.show-for-medium-down,.hide-for-large-only,.hide-for-large-up,.hide-for-large,.show-for-large-down,.hide-for-xlarge-only,.hide-for-xlarge-up,.hide-for-xlarge,.show-for-xlarge-down,.hide-for-xxlarge-only,.hide-for-xxlarge-up,.hide-for-xxlarge,.show-for-xxlarge-down{display:inherit !important}.hide-for-small-only,.hide-for-small-up,.hide-for-small,.hide-for-small-down,.show-for-medium-only,.show-for-medium-up,.show-for-medium,.hide-for-medium-down,.show-for-large-only,.show-for-large-up,.show-for-large,.hide-for-large-down,.show-for-xlarge-only,.show-for-xlarge-up,.show-for-xlarge,.hide-for-xlarge-down,.show-for-xxlarge-only,.show-for-xxlarge-up,.show-for-xxlarge,.hide-for-xxlarge-down{display:none !important}.visible-for-small-only,.visible-for-small-up,.visible-for-small,.visible-for-small-down,.hidden-for-medium-only,.hidden-for-medium-up,.hidden-for-medium,.visible-for-medium-down,.hidden-for-large-only,.hidden-for-large-up,.hidden-for-large,.visible-for-large-down,.hidden-for-xlarge-only,.hidden-for-xlarge-up,.hidden-for-xlarge,.visible-for-xlarge-down,.hidden-for-xxlarge-only,.hidden-for-xxlarge-up,.hidden-for-xxlarge,.visible-for-xxlarge-down{position:static !important;height:auto;width:auto;overflow:visible;clip:auto}.hidden-for-small-only,.hidden-for-small-up,.hidden-for-small,.hidden-for-small-down,.visible-for-medium-only,.visible-for-medium-up,.visible-for-medium,.hidden-for-medium-down,.visible-for-large-only,.visible-for-large-up,.visible-for-large,.hidden-for-large-down,.visible-for-xlarge-only,.visible-for-xlarge-up,.visible-for-xlarge,.hidden-for-xlarge-down,.visible-for-xxlarge-only,.visible-for-xxlarge-up,.visible-for-xxlarge,.hidden-for-xxlarge-down{clip:rect(1px, 1px, 1px, 1px);height:1px;overflow:hidden;position:absolute !important;width:1px}table.show-for-small-only,table.show-for-small-up,table.show-for-small,table.show-for-small-down,table.hide-for-medium-only,table.hide-for-medium-up,table.hide-for-medium,table.show-for-medium-down,table.hide-for-large-only,table.hide-for-large-up,table.hide-for-large,table.show-for-large-down,table.hide-for-xlarge-only,table.hide-for-xlarge-up,table.hide-for-xlarge,table.show-for-xlarge-down,table.hide-for-xxlarge-only,table.hide-for-xxlarge-up,table.hide-for-xxlarge,table.show-for-xxlarge-down{display:table !important}thead.show-for-small-only,thead.show-for-small-up,thead.show-for-small,thead.show-for-small-down,thead.hide-for-medium-only,thead.hide-for-medium-up,thead.hide-for-medium,thead.show-for-medium-down,thead.hide-for-large-only,thead.hide-for-large-up,thead.hide-for-large,thead.show-for-large-down,thead.hide-for-xlarge-only,thead.hide-for-xlarge-up,thead.hide-for-xlarge,thead.show-for-xlarge-down,thead.hide-for-xxlarge-only,thead.hide-for-xxlarge-up,thead.hide-for-xxlarge,thead.show-for-xxlarge-down{display:table-header-group !important}tbody.show-for-small-only,tbody.show-for-small-up,tbody.show-for-small,tbody.show-for-small-down,tbody.hide-for-medium-only,tbody.hide-for-medium-up,tbody.hide-for-medium,tbody.show-for-medium-down,tbody.hide-for-large-only,tbody.hide-for-large-up,tbody.hide-for-large,tbody.show-for-large-down,tbody.hide-for-xlarge-only,tbody.hide-for-xlarge-up,tbody.hide-for-xlarge,tbody.show-for-xlarge-down,tbody.hide-for-xxlarge-only,tbody.hide-for-xxlarge-up,tbody.hide-for-xxlarge,tbody.show-for-xxlarge-down{display:table-row-group !important}tr.show-for-small-only,tr.show-for-small-up,tr.show-for-small,tr.show-for-small-down,tr.hide-for-medium-only,tr.hide-for-medium-up,tr.hide-for-medium,tr.show-for-medium-down,tr.hide-for-large-only,tr.hide-for-large-up,tr.hide-for-large,tr.show-for-large-down,tr.hide-for-xlarge-only,tr.hide-for-xlarge-up,tr.hide-for-xlarge,tr.show-for-xlarge-down,tr.hide-for-xxlarge-only,tr.hide-for-xxlarge-up,tr.hide-for-xxlarge,tr.show-for-xxlarge-down{display:table-row}th.show-for-small-only,td.show-for-small-only,th.show-for-small-up,td.show-for-small-up,th.show-for-small,td.show-for-small,th.show-for-small-down,td.show-for-small-down,th.hide-for-medium-only,td.hide-for-medium-only,th.hide-for-medium-up,td.hide-for-medium-up,th.hide-for-medium,td.hide-for-medium,th.show-for-medium-down,td.show-for-medium-down,th.hide-for-large-only,td.hide-for-large-only,th.hide-for-large-up,td.hide-for-large-up,th.hide-for-large,td.hide-for-large,th.show-for-large-down,td.show-for-large-down,th.hide-for-xlarge-only,td.hide-for-xlarge-only,th.hide-for-xlarge-up,td.hide-for-xlarge-up,th.hide-for-xlarge,td.hide-for-xlarge,th.show-for-xlarge-down,td.show-for-xlarge-down,th.hide-for-xxlarge-only,td.hide-for-xxlarge-only,th.hide-for-xxlarge-up,td.hide-for-xxlarge-up,th.hide-for-xxlarge,td.hide-for-xxlarge,th.show-for-xxlarge-down,td.show-for-xxlarge-down{display:table-cell !important}}@media only screen and (min-width: 40.0625em){.hide-for-small-only,.show-for-small-up,.hide-for-small,.hide-for-small-down,.show-for-medium-only,.show-for-medium-up,.show-for-medium,.show-for-medium-down,.hide-for-large-only,.hide-for-large-up,.hide-for-large,.show-for-large-down,.hide-for-xlarge-only,.hide-for-xlarge-up,.hide-for-xlarge,.show-for-xlarge-down,.hide-for-xxlarge-only,.hide-for-xxlarge-up,.hide-for-xxlarge,.show-for-xxlarge-down{display:inherit !important}.show-for-small-only,.hide-for-small-up,.show-for-small,.show-for-small-down,.hide-for-medium-only,.hide-for-medium-up,.hide-for-medium,.hide-for-medium-down,.show-for-large-only,.show-for-large-up,.show-for-large,.hide-for-large-down,.show-for-xlarge-only,.show-for-xlarge-up,.show-for-xlarge,.hide-for-xlarge-down,.show-for-xxlarge-only,.show-for-xxlarge-up,.show-for-xxlarge,.hide-for-xxlarge-down{display:none !important}.hidden-for-small-only,.visible-for-small-up,.hidden-for-small,.hidden-for-small-down,.visible-for-medium-only,.visible-for-medium-up,.visible-for-medium,.visible-for-medium-down,.hidden-for-large-only,.hidden-for-large-up,.hidden-for-large,.visible-for-large-down,.hidden-for-xlarge-only,.hidden-for-xlarge-up,.hidden-for-xlarge,.visible-for-xlarge-down,.hidden-for-xxlarge-only,.hidden-for-xxlarge-up,.hidden-for-xxlarge,.visible-for-xxlarge-down{position:static !important;height:auto;width:auto;overflow:visible;clip:auto}.visible-for-small-only,.hidden-for-small-up,.visible-for-small,.visible-for-small-down,.hidden-for-medium-only,.hidden-for-medium-up,.hidden-for-medium,.hidden-for-medium-down,.visible-for-large-only,.visible-for-large-up,.visible-for-large,.hidden-for-large-down,.visible-for-xlarge-only,.visible-for-xlarge-up,.visible-for-xlarge,.hidden-for-xlarge-down,.visible-for-xxlarge-only,.visible-for-xxlarge-up,.visible-for-xxlarge,.hidden-for-xxlarge-down{clip:rect(1px, 1px, 1px, 1px);height:1px;overflow:hidden;position:absolute !important;width:1px}table.hide-for-small-only,table.show-for-small-up,table.hide-for-small,table.hide-for-small-down,table.show-for-medium-only,table.show-for-medium-up,table.show-for-medium,table.show-for-medium-down,table.hide-for-large-only,table.hide-for-large-up,table.hide-for-large,table.show-for-large-down,table.hide-for-xlarge-only,table.hide-for-xlarge-up,table.hide-for-xlarge,table.show-for-xlarge-down,table.hide-for-xxlarge-only,table.hide-for-xxlarge-up,table.hide-for-xxlarge,table.show-for-xxlarge-down{display:table !important}thead.hide-for-small-only,thead.show-for-small-up,thead.hide-for-small,thead.hide-for-small-down,thead.show-for-medium-only,thead.show-for-medium-up,thead.show-for-medium,thead.show-for-medium-down,thead.hide-for-large-only,thead.hide-for-large-up,thead.hide-for-large,thead.show-for-large-down,thead.hide-for-xlarge-only,thead.hide-for-xlarge-up,thead.hide-for-xlarge,thead.show-for-xlarge-down,thead.hide-for-xxlarge-only,thead.hide-for-xxlarge-up,thead.hide-for-xxlarge,thead.show-for-xxlarge-down{display:table-header-group !important}tbody.hide-for-small-only,tbody.show-for-small-up,tbody.hide-for-small,tbody.hide-for-small-down,tbody.show-for-medium-only,tbody.show-for-medium-up,tbody.show-for-medium,tbody.show-for-medium-down,tbody.hide-for-large-only,tbody.hide-for-large-up,tbody.hide-for-large,tbody.show-for-large-down,tbody.hide-for-xlarge-only,tbody.hide-for-xlarge-up,tbody.hide-for-xlarge,tbody.show-for-xlarge-down,tbody.hide-for-xxlarge-only,tbody.hide-for-xxlarge-up,tbody.hide-for-xxlarge,tbody.show-for-xxlarge-down{display:table-row-group !important}tr.hide-for-small-only,tr.show-for-small-up,tr.hide-for-small,tr.hide-for-small-down,tr.show-for-medium-only,tr.show-for-medium-up,tr.show-for-medium,tr.show-for-medium-down,tr.hide-for-large-only,tr.hide-for-large-up,tr.hide-for-large,tr.show-for-large-down,tr.hide-for-xlarge-only,tr.hide-for-xlarge-up,tr.hide-for-xlarge,tr.show-for-xlarge-down,tr.hide-for-xxlarge-only,tr.hide-for-xxlarge-up,tr.hide-for-xxlarge,tr.show-for-xxlarge-down{display:table-row}th.hide-for-small-only,td.hide-for-small-only,th.show-for-small-up,td.show-for-small-up,th.hide-for-small,td.hide-for-small,th.hide-for-small-down,td.hide-for-small-down,th.show-for-medium-only,td.show-for-medium-only,th.show-for-medium-up,td.show-for-medium-up,th.show-for-medium,td.show-for-medium,th.show-for-medium-down,td.show-for-medium-down,th.hide-for-large-only,td.hide-for-large-only,th.hide-for-large-up,td.hide-for-large-up,th.hide-for-large,td.hide-for-large,th.show-for-large-down,td.show-for-large-down,th.hide-for-xlarge-only,td.hide-for-xlarge-only,th.hide-for-xlarge-up,td.hide-for-xlarge-up,th.hide-for-xlarge,td.hide-for-xlarge,th.show-for-xlarge-down,td.show-for-xlarge-down,th.hide-for-xxlarge-only,td.hide-for-xxlarge-only,th.hide-for-xxlarge-up,td.hide-for-xxlarge-up,th.hide-for-xxlarge,td.hide-for-xxlarge,th.show-for-xxlarge-down,td.show-for-xxlarge-down{display:table-cell !important}}@media only screen and (min-width: 58.8125em){.hide-for-small-only,.show-for-small-up,.hide-for-small,.hide-for-small-down,.hide-for-medium-only,.show-for-medium-up,.hide-for-medium,.hide-for-medium-down,.show-for-large-only,.show-for-large-up,.show-for-large,.show-for-large-down,.hide-for-xlarge-only,.hide-for-xlarge-up,.hide-for-xlarge,.show-for-xlarge-down,.hide-for-xxlarge-only,.hide-for-xxlarge-up,.hide-for-xxlarge,.show-for-xxlarge-down{display:inherit !important}.show-for-small-only,.hide-for-small-up,.show-for-small,.show-for-small-down,.show-for-medium-only,.hide-for-medium-up,.show-for-medium,.show-for-medium-down,.hide-for-large-only,.hide-for-large-up,.hide-for-large,.hide-for-large-down,.show-for-xlarge-only,.show-for-xlarge-up,.show-for-xlarge,.hide-for-xlarge-down,.show-for-xxlarge-only,.show-for-xxlarge-up,.show-for-xxlarge,.hide-for-xxlarge-down{display:none !important}.hidden-for-small-only,.visible-for-small-up,.hidden-for-small,.hidden-for-small-down,.hidden-for-medium-only,.visible-for-medium-up,.hidden-for-medium,.hidden-for-medium-down,.visible-for-large-only,.visible-for-large-up,.visible-for-large,.visible-for-large-down,.hidden-for-xlarge-only,.hidden-for-xlarge-up,.hidden-for-xlarge,.visible-for-xlarge-down,.hidden-for-xxlarge-only,.hidden-for-xxlarge-up,.hidden-for-xxlarge,.visible-for-xxlarge-down{position:static !important;height:auto;width:auto;overflow:visible;clip:auto}.visible-for-small-only,.hidden-for-small-up,.visible-for-small,.visible-for-small-down,.visible-for-medium-only,.hidden-for-medium-up,.visible-for-medium,.visible-for-medium-down,.hidden-for-large-only,.hidden-for-large-up,.hidden-for-large,.hidden-for-large-down,.visible-for-xlarge-only,.visible-for-xlarge-up,.visible-for-xlarge,.hidden-for-xlarge-down,.visible-for-xxlarge-only,.visible-for-xxlarge-up,.visible-for-xxlarge,.hidden-for-xxlarge-down{clip:rect(1px, 1px, 1px, 1px);height:1px;overflow:hidden;position:absolute !important;width:1px}table.hide-for-small-only,table.show-for-small-up,table.hide-for-small,table.hide-for-small-down,table.hide-for-medium-only,table.show-for-medium-up,table.hide-for-medium,table.hide-for-medium-down,table.show-for-large-only,table.show-for-large-up,table.show-for-large,table.show-for-large-down,table.hide-for-xlarge-only,table.hide-for-xlarge-up,table.hide-for-xlarge,table.show-for-xlarge-down,table.hide-for-xxlarge-only,table.hide-for-xxlarge-up,table.hide-for-xxlarge,table.show-for-xxlarge-down{display:table !important}thead.hide-for-small-only,thead.show-for-small-up,thead.hide-for-small,thead.hide-for-small-down,thead.hide-for-medium-only,thead.show-for-medium-up,thead.hide-for-medium,thead.hide-for-medium-down,thead.show-for-large-only,thead.show-for-large-up,thead.show-for-large,thead.show-for-large-down,thead.hide-for-xlarge-only,thead.hide-for-xlarge-up,thead.hide-for-xlarge,thead.show-for-xlarge-down,thead.hide-for-xxlarge-only,thead.hide-for-xxlarge-up,thead.hide-for-xxlarge,thead.show-for-xxlarge-down{display:table-header-group !important}tbody.hide-for-small-only,tbody.show-for-small-up,tbody.hide-for-small,tbody.hide-for-small-down,tbody.hide-for-medium-only,tbody.show-for-medium-up,tbody.hide-for-medium,tbody.hide-for-medium-down,tbody.show-for-large-only,tbody.show-for-large-up,tbody.show-for-large,tbody.show-for-large-down,tbody.hide-for-xlarge-only,tbody.hide-for-xlarge-up,tbody.hide-for-xlarge,tbody.show-for-xlarge-down,tbody.hide-for-xxlarge-only,tbody.hide-for-xxlarge-up,tbody.hide-for-xxlarge,tbody.show-for-xxlarge-down{display:table-row-group !important}tr.hide-for-small-only,tr.show-for-small-up,tr.hide-for-small,tr.hide-for-small-down,tr.hide-for-medium-only,tr.show-for-medium-up,tr.hide-for-medium,tr.hide-for-medium-down,tr.show-for-large-only,tr.show-for-large-up,tr.show-for-large,tr.show-for-large-down,tr.hide-for-xlarge-only,tr.hide-for-xlarge-up,tr.hide-for-xlarge,tr.show-for-xlarge-down,tr.hide-for-xxlarge-only,tr.hide-for-xxlarge-up,tr.hide-for-xxlarge,tr.show-for-xxlarge-down{display:table-row}th.hide-for-small-only,td.hide-for-small-only,th.show-for-small-up,td.show-for-small-up,th.hide-for-small,td.hide-for-small,th.hide-for-small-down,td.hide-for-small-down,th.hide-for-medium-only,td.hide-for-medium-only,th.show-for-medium-up,td.show-for-medium-up,th.hide-for-medium,td.hide-for-medium,th.hide-for-medium-down,td.hide-for-medium-down,th.show-for-large-only,td.show-for-large-only,th.show-for-large-up,td.show-for-large-up,th.show-for-large,td.show-for-large,th.show-for-large-down,td.show-for-large-down,th.hide-for-xlarge-only,td.hide-for-xlarge-only,th.hide-for-xlarge-up,td.hide-for-xlarge-up,th.hide-for-xlarge,td.hide-for-xlarge,th.show-for-xlarge-down,td.show-for-xlarge-down,th.hide-for-xxlarge-only,td.hide-for-xxlarge-only,th.hide-for-xxlarge-up,td.hide-for-xxlarge-up,th.hide-for-xxlarge,td.hide-for-xxlarge,th.show-for-xxlarge-down,td.show-for-xxlarge-down{display:table-cell !important}}@media only screen and (min-width: 90.0625em){.hide-for-small-only,.show-for-small-up,.hide-for-small,.hide-for-small-down,.hide-for-medium-only,.show-for-medium-up,.hide-for-medium,.hide-for-medium-down,.hide-for-large-only,.show-for-large-up,.hide-for-large,.hide-for-large-down,.show-for-xlarge-only,.show-for-xlarge-up,.show-for-xlarge,.show-for-xlarge-down,.hide-for-xxlarge-only,.hide-for-xxlarge-up,.hide-for-xxlarge,.show-for-xxlarge-down{display:inherit !important}.show-for-small-only,.hide-for-small-up,.show-for-small,.show-for-small-down,.show-for-medium-only,.hide-for-medium-up,.show-for-medium,.show-for-medium-down,.show-for-large-only,.hide-for-large-up,.show-for-large,.show-for-large-down,.hide-for-xlarge-only,.hide-for-xlarge-up,.hide-for-xlarge,.hide-for-xlarge-down,.show-for-xxlarge-only,.show-for-xxlarge-up,.show-for-xxlarge,.hide-for-xxlarge-down{display:none !important}.hidden-for-small-only,.visible-for-small-up,.hidden-for-small,.hidden-for-small-down,.hidden-for-medium-only,.visible-for-medium-up,.hidden-for-medium,.hidden-for-medium-down,.hidden-for-large-only,.visible-for-large-up,.hidden-for-large,.hidden-for-large-down,.visible-for-xlarge-only,.visible-for-xlarge-up,.visible-for-xlarge,.visible-for-xlarge-down,.hidden-for-xxlarge-only,.hidden-for-xxlarge-up,.hidden-for-xxlarge,.visible-for-xxlarge-down{position:static !important;height:auto;width:auto;overflow:visible;clip:auto}.visible-for-small-only,.hidden-for-small-up,.visible-for-small,.visible-for-small-down,.visible-for-medium-only,.hidden-for-medium-up,.visible-for-medium,.visible-for-medium-down,.visible-for-large-only,.hidden-for-large-up,.visible-for-large,.visible-for-large-down,.hidden-for-xlarge-only,.hidden-for-xlarge-up,.hidden-for-xlarge,.hidden-for-xlarge-down,.visible-for-xxlarge-only,.visible-for-xxlarge-up,.visible-for-xxlarge,.hidden-for-xxlarge-down{clip:rect(1px, 1px, 1px, 1px);height:1px;overflow:hidden;position:absolute !important;width:1px}table.hide-for-small-only,table.show-for-small-up,table.hide-for-small,table.hide-for-small-down,table.hide-for-medium-only,table.show-for-medium-up,table.hide-for-medium,table.hide-for-medium-down,table.hide-for-large-only,table.show-for-large-up,table.hide-for-large,table.hide-for-large-down,table.show-for-xlarge-only,table.show-for-xlarge-up,table.show-for-xlarge,table.show-for-xlarge-down,table.hide-for-xxlarge-only,table.hide-for-xxlarge-up,table.hide-for-xxlarge,table.show-for-xxlarge-down{display:table !important}thead.hide-for-small-only,thead.show-for-small-up,thead.hide-for-small,thead.hide-for-small-down,thead.hide-for-medium-only,thead.show-for-medium-up,thead.hide-for-medium,thead.hide-for-medium-down,thead.hide-for-large-only,thead.show-for-large-up,thead.hide-for-large,thead.hide-for-large-down,thead.show-for-xlarge-only,thead.show-for-xlarge-up,thead.show-for-xlarge,thead.show-for-xlarge-down,thead.hide-for-xxlarge-only,thead.hide-for-xxlarge-up,thead.hide-for-xxlarge,thead.show-for-xxlarge-down{display:table-header-group !important}tbody.hide-for-small-only,tbody.show-for-small-up,tbody.hide-for-small,tbody.hide-for-small-down,tbody.hide-for-medium-only,tbody.show-for-medium-up,tbody.hide-for-medium,tbody.hide-for-medium-down,tbody.hide-for-large-only,tbody.show-for-large-up,tbody.hide-for-large,tbody.hide-for-large-down,tbody.show-for-xlarge-only,tbody.show-for-xlarge-up,tbody.show-for-xlarge,tbody.show-for-xlarge-down,tbody.hide-for-xxlarge-only,tbody.hide-for-xxlarge-up,tbody.hide-for-xxlarge,tbody.show-for-xxlarge-down{display:table-row-group !important}tr.hide-for-small-only,tr.show-for-small-up,tr.hide-for-small,tr.hide-for-small-down,tr.hide-for-medium-only,tr.show-for-medium-up,tr.hide-for-medium,tr.hide-for-medium-down,tr.hide-for-large-only,tr.show-for-large-up,tr.hide-for-large,tr.hide-for-large-down,tr.show-for-xlarge-only,tr.show-for-xlarge-up,tr.show-for-xlarge,tr.show-for-xlarge-down,tr.hide-for-xxlarge-only,tr.hide-for-xxlarge-up,tr.hide-for-xxlarge,tr.show-for-xxlarge-down{display:table-row}th.hide-for-small-only,td.hide-for-small-only,th.show-for-small-up,td.show-for-small-up,th.hide-for-small,td.hide-for-small,th.hide-for-small-down,td.hide-for-small-down,th.hide-for-medium-only,td.hide-for-medium-only,th.show-for-medium-up,td.show-for-medium-up,th.hide-for-medium,td.hide-for-medium,th.hide-for-medium-down,td.hide-for-medium-down,th.hide-for-large-only,td.hide-for-large-only,th.show-for-large-up,td.show-for-large-up,th.hide-for-large,td.hide-for-large,th.hide-for-large-down,td.hide-for-large-down,th.show-for-xlarge-only,td.show-for-xlarge-only,th.show-for-xlarge-up,td.show-for-xlarge-up,th.show-for-xlarge,td.show-for-xlarge,th.show-for-xlarge-down,td.show-for-xlarge-down,th.hide-for-xxlarge-only,td.hide-for-xxlarge-only,th.hide-for-xxlarge-up,td.hide-for-xxlarge-up,th.hide-for-xxlarge,td.hide-for-xxlarge,th.show-for-xxlarge-down,td.show-for-xxlarge-down{display:table-cell !important}}@media only screen and (min-width: 120.0625em){.hide-for-small-only,.show-for-small-up,.hide-for-small,.hide-for-small-down,.hide-for-medium-only,.show-for-medium-up,.hide-for-medium,.hide-for-medium-down,.hide-for-large-only,.show-for-large-up,.hide-for-large,.hide-for-large-down,.hide-for-xlarge-only,.show-for-xlarge-up,.hide-for-xlarge,.hide-for-xlarge-down,.show-for-xxlarge-only,.show-for-xxlarge-up,.show-for-xxlarge,.show-for-xxlarge-down{display:inherit !important}.show-for-small-only,.hide-for-small-up,.show-for-small,.show-for-small-down,.show-for-medium-only,.hide-for-medium-up,.show-for-medium,.show-for-medium-down,.show-for-large-only,.hide-for-large-up,.show-for-large,.show-for-large-down,.show-for-xlarge-only,.hide-for-xlarge-up,.show-for-xlarge,.show-for-xlarge-down,.hide-for-xxlarge-only,.hide-for-xxlarge-up,.hide-for-xxlarge,.hide-for-xxlarge-down{display:none !important}.hidden-for-small-only,.visible-for-small-up,.hidden-for-small,.hidden-for-small-down,.hidden-for-medium-only,.visible-for-medium-up,.hidden-for-medium,.hidden-for-medium-down,.hidden-for-large-only,.visible-for-large-up,.hidden-for-large,.hidden-for-large-down,.hidden-for-xlarge-only,.visible-for-xlarge-up,.hidden-for-xlarge,.hidden-for-xlarge-down,.visible-for-xxlarge-only,.visible-for-xxlarge-up,.visible-for-xxlarge,.visible-for-xxlarge-down{position:static !important;height:auto;width:auto;overflow:visible;clip:auto}.visible-for-small-only,.hidden-for-small-up,.visible-for-small,.visible-for-small-down,.visible-for-medium-only,.hidden-for-medium-up,.visible-for-medium,.visible-for-medium-down,.visible-for-large-only,.hidden-for-large-up,.visible-for-large,.visible-for-large-down,.visible-for-xlarge-only,.hidden-for-xlarge-up,.visible-for-xlarge,.visible-for-xlarge-down,.hidden-for-xxlarge-only,.hidden-for-xxlarge-up,.hidden-for-xxlarge,.hidden-for-xxlarge-down{clip:rect(1px, 1px, 1px, 1px);height:1px;overflow:hidden;position:absolute !important;width:1px}table.hide-for-small-only,table.show-for-small-up,table.hide-for-small,table.hide-for-small-down,table.hide-for-medium-only,table.show-for-medium-up,table.hide-for-medium,table.hide-for-medium-down,table.hide-for-large-only,table.show-for-large-up,table.hide-for-large,table.hide-for-large-down,table.hide-for-xlarge-only,table.show-for-xlarge-up,table.hide-for-xlarge,table.hide-for-xlarge-down,table.show-for-xxlarge-only,table.show-for-xxlarge-up,table.show-for-xxlarge,table.show-for-xxlarge-down{display:table !important}thead.hide-for-small-only,thead.show-for-small-up,thead.hide-for-small,thead.hide-for-small-down,thead.hide-for-medium-only,thead.show-for-medium-up,thead.hide-for-medium,thead.hide-for-medium-down,thead.hide-for-large-only,thead.show-for-large-up,thead.hide-for-large,thead.hide-for-large-down,thead.hide-for-xlarge-only,thead.show-for-xlarge-up,thead.hide-for-xlarge,thead.hide-for-xlarge-down,thead.show-for-xxlarge-only,thead.show-for-xxlarge-up,thead.show-for-xxlarge,thead.show-for-xxlarge-down{display:table-header-group !important}tbody.hide-for-small-only,tbody.show-for-small-up,tbody.hide-for-small,tbody.hide-for-small-down,tbody.hide-for-medium-only,tbody.show-for-medium-up,tbody.hide-for-medium,tbody.hide-for-medium-down,tbody.hide-for-large-only,tbody.show-for-large-up,tbody.hide-for-large,tbody.hide-for-large-down,tbody.hide-for-xlarge-only,tbody.show-for-xlarge-up,tbody.hide-for-xlarge,tbody.hide-for-xlarge-down,tbody.show-for-xxlarge-only,tbody.show-for-xxlarge-up,tbody.show-for-xxlarge,tbody.show-for-xxlarge-down{display:table-row-group !important}tr.hide-for-small-only,tr.show-for-small-up,tr.hide-for-small,tr.hide-for-small-down,tr.hide-for-medium-only,tr.show-for-medium-up,tr.hide-for-medium,tr.hide-for-medium-down,tr.hide-for-large-only,tr.show-for-large-up,tr.hide-for-large,tr.hide-for-large-down,tr.hide-for-xlarge-only,tr.show-for-xlarge-up,tr.hide-for-xlarge,tr.hide-for-xlarge-down,tr.show-for-xxlarge-only,tr.show-for-xxlarge-up,tr.show-for-xxlarge,tr.show-for-xxlarge-down{display:table-row}th.hide-for-small-only,td.hide-for-small-only,th.show-for-small-up,td.show-for-small-up,th.hide-for-small,td.hide-for-small,th.hide-for-small-down,td.hide-for-small-down,th.hide-for-medium-only,td.hide-for-medium-only,th.show-for-medium-up,td.show-for-medium-up,th.hide-for-medium,td.hide-for-medium,th.hide-for-medium-down,td.hide-for-medium-down,th.hide-for-large-only,td.hide-for-large-only,th.show-for-large-up,td.show-for-large-up,th.hide-for-large,td.hide-for-large,th.hide-for-large-down,td.hide-for-large-down,th.hide-for-xlarge-only,td.hide-for-xlarge-only,th.show-for-xlarge-up,td.show-for-xlarge-up,th.hide-for-xlarge,td.hide-for-xlarge,th.hide-for-xlarge-down,td.hide-for-xlarge-down,th.show-for-xxlarge-only,td.show-for-xxlarge-only,th.show-for-xxlarge-up,td.show-for-xxlarge-up,th.show-for-xxlarge,td.show-for-xxlarge,th.show-for-xxlarge-down,td.show-for-xxlarge-down{display:table-cell !important}}.show-for-landscape,.hide-for-portrait{display:inherit !important}.hide-for-landscape,.show-for-portrait{display:none !important}table.hide-for-landscape,table.show-for-portrait{display:table !important}thead.hide-for-landscape,thead.show-for-portrait{display:table-header-group !important}tbody.hide-for-landscape,tbody.show-for-portrait{display:table-row-group !important}tr.hide-for-landscape,tr.show-for-portrait{display:table-row !important}td.hide-for-landscape,td.show-for-portrait,th.hide-for-landscape,th.show-for-portrait{display:table-cell !important}@media only screen and (orientation: landscape){.show-for-landscape,.hide-for-portrait{display:inherit !important}.hide-for-landscape,.show-for-portrait{display:none !important}table.show-for-landscape,table.hide-for-portrait{display:table !important}thead.show-for-landscape,thead.hide-for-portrait{display:table-header-group !important}tbody.show-for-landscape,tbody.hide-for-portrait{display:table-row-group !important}tr.show-for-landscape,tr.hide-for-portrait{display:table-row !important}td.show-for-landscape,td.hide-for-portrait,th.show-for-landscape,th.hide-for-portrait{display:table-cell !important}}@media only screen and (orientation: portrait){.show-for-portrait,.hide-for-landscape{display:inherit !important}.hide-for-portrait,.show-for-landscape{display:none !important}table.show-for-portrait,table.hide-for-landscape{display:table !important}thead.show-for-portrait,thead.hide-for-landscape{display:table-header-group !important}tbody.show-for-portrait,tbody.hide-for-landscape{display:table-row-group !important}tr.show-for-portrait,tr.hide-for-landscape{display:table-row !important}td.show-for-portrait,td.hide-for-landscape,th.show-for-portrait,th.hide-for-landscape{display:table-cell !important}}.show-for-touch{display:none !important}.hide-for-touch{display:inherit !important}.touch .show-for-touch{display:inherit !important}.touch .hide-for-touch{display:none !important}table.hide-for-touch{display:table !important}.touch table.show-for-touch{display:table !important}thead.hide-for-touch{display:table-header-group !important}.touch thead.show-for-touch{display:table-header-group !important}tbody.hide-for-touch{display:table-row-group !important}.touch tbody.show-for-touch{display:table-row-group !important}tr.hide-for-touch{display:table-row !important}.touch tr.show-for-touch{display:table-row !important}td.hide-for-touch{display:table-cell !important}.touch td.show-for-touch{display:table-cell !important}th.hide-for-touch{display:table-cell !important}.touch th.show-for-touch{display:table-cell !important}.show-for-sr{clip:rect(1px, 1px, 1px, 1px);height:1px;overflow:hidden;position:absolute !important;width:1px}.show-on-focus{clip:rect(1px, 1px, 1px, 1px);height:1px;overflow:hidden;position:absolute !important;width:1px}.show-on-focus:focus,.show-on-focus:active{position:static !important;height:auto;width:auto;overflow:visible;clip:auto}.print-only{display:none !important}@media print{*{background:transparent !important;box-shadow:none !important;color:#000 !important;text-shadow:none !important}.show-for-print{display:block}.hide-for-print{display:none}table.show-for-print{display:table !important}thead.show-for-print{display:table-header-group !important}tbody.show-for-print{display:table-row-group !important}tr.show-for-print{display:table-row !important}td.show-for-print{display:table-cell !important}th.show-for-print{display:table-cell !important}a,a:visited{text-decoration:underline}a[href]:after{content:" (" attr(href) ")"}abbr[title]:after{content:" (" attr(title) ")"}.ir a:after,a[href^="javascript:"]:after,a[href^="#"]:after{content:""}pre,blockquote{border:1px solid #999;page-break-inside:avoid}thead{display:table-header-group}tr,img{page-break-inside:avoid}img{max-width:100% !important}@page{margin:.5cm}p,h2,h3{orphans:3;widows:3}h2,h3{page-break-after:avoid}.hide-on-print{display:none !important}.print-only{display:block !important}.hide-for-print{display:none !important}.show-for-print{display:inherit !important}}@media print{.show-for-print{display:block}.hide-for-print{display:none}table.show-for-print{display:table !important}thead.show-for-print{display:table-header-group !important}tbody.show-for-print{display:table-row-group !important}tr.show-for-print{display:table-row !important}td.show-for-print{display:table-cell !important}th.show-for-print{display:table-cell !important}}@media not print{.show-for-print{display:none !important}}h1,h2,h3,h4,h5,h6,p,li{letter-spacing:0.02rem;font-weight:200}li{line-height:2}p>sub{font-size:.8rem;line-height:1.3rem;display:block}header .nav-global{list-style:none;margin-left:-1.375rem;margin-right:0;margin:0 auto 1.0625rem auto;overflow:hidden;padding:0;float:right;margin-bottom:0}header .nav-global>li{display:block;float:left;list-style:none;margin-left:1.375rem}header .nav-global>li>*{display:block}header .nav-global li{margin-left:1rem}header .nav-global a{font-size:0.875rem;font-weight:300;color:#7A8491;padding:0.625rem 0.3125rem}header .nav-global a:hover{color:#FF992E}header .nav-global a.button{background:#86D801;padding:0.625rem 1.875rem;color:#fff;margin-bottom:0;position:relative;bottom:-5px}header .nav-global a.button:hover{background:#fa8000}@media only screen and (max-width: 40em){header .nav-global{display:none}}@media only screen and (min-width: 40.0625em) and (max-width: 58.75em){header .nav-global{display:none}}.main-header div>.nav-main{list-style:none;margin-left:-1.375rem;margin-right:0;margin:0 auto 1.0625rem auto;overflow:hidden;padding:0;float:right;margin-bottom:0;overflow:visible}.main-header div>.nav-main>li{display:block;float:left;list-style:none;margin-left:1.375rem}.main-header div>.nav-main>li>*{display:block}@media only screen and (max-width: 40em){.main-header div>.nav-main{display:none}}@media only screen and (min-width: 40.0625em) and (max-width: 58.75em){.main-header div>.nav-main{display:none}}.main-header div>.nav-main>li{position:relative;margin-left:.8rem}.main-header div>.nav-main>li ul{position:absolute;margin:0;list-style:none;border:1px solid #ddd;min-width:175px;transition:all .5s ease;border-radius:5px;overflow:hidden;float:left;display:none}.main-header div>.nav-main>li ul>li:first-child{display:none}.main-header div>.nav-main>li ul a{display:block;font-size:0.8125rem;background:#fff;border-bottom:1px solid #ddd;padding:6px 8px}.main-header div>.nav-main>li ul a:hover{background:#fafafa}.main-header div>.nav-main>li ul a:last-child{border-bottom:0 solid #ddd}.main-header div>.nav-main>li:hover ul{display:block}.main-header div>.nav-main a{font-size:1.0625rem;font-weight:500;color:#394d54}@media only screen and (min-width: 1150px){.main-header div>.nav-main a{padding:0 0.3125rem}}.main-header div>.nav-main a:hover{color:#22b8eb}.nav-sub{list-style:none;margin-left:-1.375rem;margin-right:0;margin:0 auto 1.0625rem auto;overflow:hidden;padding:0;display:block;margin:1.875rem 0 0 0;text-align:center}.nav-sub>li{display:block;float:left;list-style:none;margin-left:1.375rem}.nav-sub>li>*{display:block}@media only screen and (max-width: 40em){.nav-sub{display:none}}.nav-sub li{margin-left:10px;display:inline-block;float:none}.nav-sub a{font-size:0.9375rem;font-weight:100;color:#fff;padding:0.625rem 1.25rem;background:#1088b1;border-radius:5px 5px 0 0}.nav-sub a:hover{background:#084053}.nav-sub a.active-trail{background:#fff;color:#1088b1}@media only screen and (min-width: 40.0625em) and (max-width: 58.75em){.nav-sub a{font-size:0.8125rem}}.left-off-canvas-menu .button{display:block;margin:10px;font-size:0.875rem;padding:14px}.nav-global-off-canvas{list-style:none;padding:12px 10px;margin-left:0}.nav-global-off-canvas a{color:#fff;font-weight:100}.off-canvas-list li.left-submenu>ul>li:nth-child(2){display:none}.side-nav li a:not(.button){padding:0.3125rem 0}.side-nav li a:not(.button):hover{background:#f1f1f1;padding:0.3125rem 0.625rem;color:#129ac8}.side-nav li.active a:not(.button){background:#f1f1f1;padding:0.3125rem 0.625rem;color:#129ac8}.side-nav li.active>a:first-child:not(.button){color:#129ac8}.security-post strong.date{font-size:.9rem;margin-top:-13px;margin-bottom:8px;display:block}.path-partners .page-content{padding-bottom:2rem}.path-partners .page-content h2{clear:left;margin-top:-30px;padding-top:30px}.path-partners .page-content p{clear:left;padding-left:14rem;overflow:hidden}.path-partners .page-content h2+p{padding-left:0}.path-partners .page-content img{float:left;clear:left;max-width:12rem;height:auto !important;margin-left:-14rem}.path-partners .page-content .large-3 ul{-webkit-transform:translate3d(0, 0, 0)}.path-partners .page-content .large-3 li{list-style:none}.path-partners .page-content .fixed-bar{position:fixed;top:30px}.embed-wrapper{position:relative;padding-bottom:56.25%;padding-top:25px;height:0}.embed-wrapper iframe{position:absolute;top:0;left:0;width:100%;height:100%}.management .team-bios{margin:2.5rem 0}.management .team-bios li{padding:0 3% 1.25rem;position:relative}.management .team-bios li.selected:after{content:'';display:block;width:0;height:0;border-left:10px solid transparent;border-right:10px solid transparent;border-bottom:10px solid #22b8eb;position:absolute;bottom:0;left:50%;transform:translateX(-50%)}.management .bio-image img{width:100%;margin-bottom:.4rem}.management .bio-content{display:block}.management .bio-content h2,.management .bio-content h3{font-size:1.2rem;margin:0}.management .bio-content h2{font-weight:bold}.management .bio-content .linkedin{float:right}.management .bio-details{display:none}.management ul.team-bios>.bio-details{display:block;clear:both;margin-bottom:30px}@media only screen and (max-width: 58.8125em){.management ul.team-bios>.bio-details{margin-left:0;margin-right:0}}.management ul.team-bios>.bio-details .bio-description{margin-bottom:2rem}.management ul.team-bios>.bio-details .inner{background:#22b8eb;margin:0 -1rem;color:white;overflow:hidden;padding:40px 0 40px}.management ul.team-bios>.bio-details .inner h2{color:white;text-align:center;margin-bottom:40px}.management ul.team-bios>.bio-details .inner h2 a{color:white}.management ul.team-bios>.bio-details .inner h3{display:none}.team{margin-top:2rem;margin-bottom:2rem}.primary-team-image{float:left;width:59.4%;height:auto;margin-right:3%}.secondary-team-image{float:left;width:37.6%;height:auto;margin-bottom:3%}#grnhse_iframe{margin-bottom:5rem}.path-work-at-docker .bubbles,.path-work-at-docker .flip{margin-top:-5rem;margin-bottom:-5rem}table td{vertical-align:top}@media only screen and (min-width: 40.0625em){.divided-content li{border-right:1px solid #eee;padding:0 2rem}.divided-content li:nth-child(2n+2){border-right:0;padding-right:.625rem}.divided-content li:nth-child(2n-1){padding-left:.625rem}}@media only screen and (max-width: 40em){.divided-content li{border-right:none}}.half-centered.columns{margin:0 auto;float:none !important;clear:both;padding-top:2.5rem}.half-centered.columns a{float:right}.repo-card-wrapper iframe{max-width:100%}.open-source-event{padding-bottom:1.5rem}.open-source-event strong.date{margin-top:.5rem;display:block}.repos{list-style:none;margin:0}.repos li{list-style:none;float:left;margin:0 1.5%;width:30.3%;background:url("../images/ajax-loader.gif") no-repeat center 100px}.repos li iframe{max-width:100%;height:240px}@media only screen and (max-width: 40em){.repos li{width:100%;margin:0}}.featured-content iframe{max-width:100%;max-height:350px}.featured-content img{max-width:100%}section.row.featured-primary,section.row.featured-secondary{max-width:62rem}.around-the-web{margin-top:3rem}.around-the-web .image_wrapper{max-width:160px;margin:0 auto}.around-the-web li{margin-bottom:2rem}.around-the-web img{max-width:100%}.featured-community .featured-content img{height:auto !important}.featured-customers .customer{min-height:25rem;position:relative}.featured-customers .customer h4{position:absolute;bottom:0;left:1rem}.secondary-customers{margin-top:2rem}.secondary-customers .customer{min-height:15.625rem;position:relative}.secondary-customers .customer h4{position:absolute;bottom:0;left:1rem}div.share-story-outer{height:21.875rem;background-color:#E75A24}div.share-story-outer div{position:absolute;bottom:0;margin-right:1rem;padding:1rem}div.share-story-outer div h3{color:#F4F9FB;font-weight:normal}div.share-story-outer div p{color:#F4F9FB}.customers h1{margin:3.125rem 0;text-align:center}.customers .customer{min-height:11.25rem;width:25%;float:left;background-position:center center;background-repeat:no-repeat;background-size:70%;cursor:pointer}.customers .customer-details{display:none;clear:both;background-color:#efefef;padding:2rem 2rem 1rem 2rem;position:relative}.customers .customer-details:before{content:' ';position:absolute;top:-2.2rem;left:10%;width:0;height:0;border:1.2rem solid #efefef;border-color:transparent transparent #efefef transparent}.customers .customer-details.nth-1:before{left:35.5%}.customers .customer-details.nth-2:before{left:60.5%}.customers .customer-details.nth-3:before{left:85.5%}.customers .customer-details.open{display:block}.customers .customer-details h1{margin-top:0;margin-bottom:2rem;text-align:center}.customers .customer-details .customer-benefits{margin-top:1rem}.customers .customer-details blockquote{padding-left:5rem;position:relative}.customers .customer-details blockquote img{position:absolute;top:0;left:0}.path-meetups .body{margin-bottom:2rem}.meetup a{display:block;margin-bottom:5px}.page-content>section:last-of-type{margin-bottom:5rem}.page-content .below-content{margin-bottom:5rem}.featured-event .image{height:10rem;background-position:center center;background-size:cover}.event{margin-bottom:1rem}.event.dynamic{display:none}.search-results.loaded .event.dynamic{display:block}.event-search{padding:5rem 0}.path-open-source .event-search{padding:0}.contextual-links-wrapper{display:none}.administration-quick-links{position:fixed;left:0;top:33%;z-index:100}.administration-quick-links a{padding:8px 20px;text-align:center;background-color:#FF992E;border-bottom-right-radius:5px;border-top-right-radius:5px;color:#fff;box-shadow:-1px 1px 10px #272727;display:block;margin:1rem 0}.administration-quick-links a:hover{background-color:#f17b00}.page-import footer.main-footer{padding:0}.button{border-radius:5px}.button.white{color:#22b8eb;background:#fff}input[type="text"],input[type="password"],input[type="date"],input[type="datetime"],input[type="datetime-local"],input[type="month"],input[type="week"],input[type="email"],input[type="number"],input[type="search"],input[type="tel"],input[type="time"],input[type="url"],input[type="color"],textarea{border-radius:5px}input::-webkit-input-placeholder{color:#7A8491;font-weight:300}input::-moz-placeholder{color:#7A8491;font-weight:300}input:-moz-placeholder{color:#7A8491;font-weight:300}input:-ms-input-placeholder{color:#7A8491;font-weight:300}span.postfix{background:#FF992E;border-radius:0px 5px 5px 0px;border:none;color:#fff}input.with-postfix{border-radius:5px 0px 0px 5px}.hero{background-color:#22b8eb;padding:1.5625rem 0 2.875rem 0;position:relative;margin-bottom:2.5rem}@media only screen and (max-width: 40em){.hero{background-image:none !important}}@media only screen and (min-width: 40.0625em){.hero{padding:3.125rem 0 12.5rem 0;background-repeat:no-repeat;background-size:cover;background-position:center center}}.hero h1,.hero h2,.hero h3,.hero h4,.hero p,.hero a{color:#fff}.hero p{font-size:1.125rem;line-height:1.75}.hero button.secondary,.hero .button.secondary{background-color:#384d55;color:#fff;width:300px;display:block}.hero-full{margin-bottom:2.5rem;text-align:center}.hero-full .region-hero-sub{margin-top:-5.3rem}.path-docker-con .hero{padding:3.125rem 0 3.5rem 0}.path-docker-con img.con{margin-bottom:1rem}.hero-sub{background-color:#22b8eb;padding:1.5625rem 0 0 0;margin-bottom:2.5rem;text-align:center;min-height:9rem}@media only screen and (min-width: 40.0625em){.hero-sub{padding:4.6875rem 0 0 0}}.hero-sub h1,.hero-sub h2,.hero-sub h3,.hero-sub h4,.hero-sub p,.hero-sub a{color:#fff}@media only screen and (min-width: 40.0625em){.hero-sub .landing-hero-des{margin-bottom:5.9375rem}}.hero-sub iframe{max-width:100%}body{height:auto;min-height:100%;padding-bottom:540px}@media only screen and (min-width: 58.8125em){body{padding-bottom:270px}}@media only screen and (min-width: 40.0625em) and (max-width: 58.75em){body{padding-bottom:520px}}@media only screen and (max-width: 40em){body{padding-bottom:630px}}.main-footer{background:#243137;position:relative;padding:1.5rem .5rem .5rem .5rem;clear:both;position:absolute;bottom:0;width:100%}@media only screen and (min-width: 40.0625em){.main-footer{padding:2rem}}.main-footer::before{background:url("../images/footer-wave.svg") repeat-x;height:16px;width:100%;position:absolute;top:-16px;left:0;content:""}.main-footer h6{color:#fff;font-weight:300}.main-footer h6 a{color:#fff;font-weight:300}.main-footer h6 a:hover{color:#22b8eb}.main-footer p{color:#7A8491}.main-footer ul{list-style:none;margin-left:0}.main-footer li a{color:#7A8491;font-weight:300}.main-footer li a:hover{color:#969ea8}.main-footer div.newsletter form{font-size:0.9375rem !important;width:100% !important}.main-footer div.newsletter form .mktoOffset,.main-footer div.newsletter form .mktoGutter,.main-footer div.newsletter form label{display:none}.main-footer div.newsletter form .mktoFormCol,.main-footer div.newsletter form .mktoFieldWrap{width:100% !important}.main-footer div.newsletter form #Email{width:100% !important;border-top-right-radius:0;border-bottom-right-radius:0;padding-left:1rem;height:2.4rem}.main-footer div.newsletter form .mktoSimple{margin:0 !important}.main-footer div.newsletter form .mktoFormRow{float:left;width:75%}.main-footer div.newsletter form .mktoButtonRow{width:25%}.main-footer div.newsletter form .mktoButtonRow button{float:left;border-top-right-radius:5px;border-bottom-right-radius:5px;height:2.4rem;background:#FF992E !important;border:1px solid #FF992E !important;width:100%}.main-footer div.newsletter form .mktoButtonRow button:hover{background:#f17b00 !important}@media only screen and (max-width: 40em){.main-footer div.newsletter form .mktoButtonRow button{padding:0.4em 0.5em !important}}.main-footer ul.social-icons{min-height:0}.main-footer div>.nav-main>li{margin-left:0}.main-footer div>.nav-main>li ul{display:none}.main-footer div>.nav-main>li>a{color:#ffffff}.main-footer div>.nav-main>li>a:hover{color:#22b8eb}.main-footer div>.nav-main>li .first{display:none;margin-top:0.2rem;margin-bottom:0.5rem}.nav-global-footer .block-menu{float:left}@media only screen and (max-width: 40em){.nav-global-footer .block-menu{width:50%}}.nav-global-footer div>ul>li>a{color:#fff;font-weight:300}.nav-global-footer div>ul>li>a:hover{color:#22b8eb}img.wow{max-height:215px}@media only screen and (min-width: 40.0625em) and (max-width: 58.75em){img.wow{height:215px}}.social-icons{list-style:none;margin-left:-1.375rem;margin-right:0;margin:0 auto 1.0625rem auto;overflow:hidden;padding:0;position:relative}.social-icons>li{display:block;float:left;list-style:none;margin-left:1.375rem}.social-icons>li>*{display:block}.social-icons li{list-style:none;margin-left:0;padding-right:1.2rem}.social-icons li:last-child{padding-right:0}@media only screen and (max-width: 40em){.social-icons li{padding-right:0.7rem}}.main-header{padding:12px 0;overflow:visible;position:relative;z-index:90;background:#fff}.main-header .logo{margin-top:13px;max-width:200px}@media only screen and (max-width: 40em){.main-header .logo{display:block;margin:auto;margin-top:0;max-width:175px}}@media only screen and (min-width: 40.0625em) and (max-width: 58.75em){.main-header .logo{display:block;margin:auto;margin-top:0;max-width:175px}}@media only screen and (min-width: 58.8125em){.main-header .logo{margin-left:-14px}}.left-off-canvas-toggle{position:absolute;left:0.9375rem;top:17px;z-index:99}@media only screen and (min-width: 58.8125em){.left-off-canvas-toggle{display:none}}.get-started-cta{position:absolute;right:0.9375rem;top:22px;z-index:99}@media only screen and (min-width: 58.8125em){.get-started-cta{display:none}}@media only screen and (max-width: 40em){.get-started-cta{display:none}}.bsr-section{background:#134a6a;text-align:center;padding:3rem 0 0 0}@media only screen and (min-width: 40.0625em){.bsr-section{margin-bottom:6rem}}.bsr-section p{color:#fff;text-align:center}.bsr-item{padding:1rem 3rem 2rem 3rem;cursor:pointer;position:relative}@media only screen and (min-width: 40.0625em){.bsr-item{margin-top:1.25rem;min-height:400px}}.bsr-item:hover,.bsr-item.is-active{background:#0b2c3f;border-radius:5px}.bsr-item.is-active::before{content:'';position:absolute;left:50%;bottom:-17px;width:0;height:0;border-left:10px solid transparent;border-right:10px solid transparent;border-bottom:10px solid #22b8eb}.build-item{margin-bottom:1rem}.build{padding-bottom:1rem}.ship{padding-bottom:1rem}.run{padding-bottom:1rem}.bsr-item-detail{background:#22b8eb;padding:3rem 0;position:relative}.bsr-item-detail h3,.bsr-item-detail p,.bsr-item-detail li{color:#fff}.bsr-item-detail p,.bsr-item-detail li{text-align:left}.bsr-item-detail li{font-weight:300}.cta-section{background-color:#fff;text-align:center;padding:1rem 0}@media only screen and (min-width: 40.0625em){.cta-section{padding:2rem 0 4rem 0}}.cta-illustration{background-color:#22b8eb;background-size:cover;background-position:center center;text-align:center;margin-top:2rem;padding:2.5rem 0 2.875rem 0}@media only screen and (min-width: 40.0625em){.cta-illustration{margin-top:5rem;padding:4.6875rem 0 4.6875rem 0}}@media only screen and (min-width: 40.0625em){body.front .cta-illustration{margin-top:5rem;padding:4.6875rem 0 28.125rem 0}}.normal-links a{color:#fff}.landing-hero{margin:0 auto;max-width:75rem;width:100%}.landing-hero:before,.landing-hero:after{content:" ";display:table}.landing-hero:after{clear:both}.landing-hero-des{padding-left:0.9375rem;padding-right:0.9375rem;width:100%;float:left}.nav-landing{list-style:none;margin-left:-1.375rem;margin-right:0;margin:0 auto 1.0625rem auto;overflow:hidden;padding:0}.nav-landing>li{display:block;float:left;list-style:none;margin-left:1.375rem}.nav-landing>li>*{display:block}.benefits{padding:2rem 0}@media only screen and (min-width: 40.0625em){.benefits{padding:5rem 0}}@media only screen and (max-width: 40em){.benefits .row{padding-bottom:2rem}.benefits img{margin-bottom:1rem}}.bubbles{display:block;max-width:500px;margin:auto}@media only screen and (max-width: 40em){.bubbles{display:none}}.flip{-moz-transform:scaleX(-1);-webkit-transform:scaleX(-1);transform:scaleX(-1)}.bubbles.animated .b1,.bubbles.animated .b2,.bubbles.animated .b3,.bubbles.animated .b4,.bubbles.animated .b5,.bubbles.animated .b6,.bubbles.animated .b7,.bubbles.animated .b8,.bubbles.animated .b9,.bubbles.animated .b10,.bubbles.animated .b11,.bubbles.animated .b12,.bubbles.animated .b13{opacity:0;-webkit-animation-name:fadeInUp;-webkit-animation-duration:600ms;-webkit-animation-timing-function:ease-in-out;-webkit-animation-delay:0;-webkit-animation-fill-mode:both;-moz-animation-name:fadeInUp;-moz-animation-duration:600ms;-moz-animation-timing-function:ease-in-out;-moz-animation-delay:0;-moz-animation-fill-mode:both}.bubbles.animated .b2{-webkit-animation-delay:200ms;-moz-animation-delay:200ms}.bubbles.animated .b3{-webkit-animation-delay:300ms;-moz-animation-delay:300ms}.bubbles.animated .b4{-webkit-animation-delay:400ms;-moz-animation-delay:400ms}.bubbles.animated .b5{-webkit-animation-delay:500ms;-moz-animation-delay:500ms}.bubbles.animated .b6{-webkit-animation-delay:6000ms;-moz-animation-delay:600ms}.bubbles.animated .b7{-webkit-animation-delay:700ms;-moz-animation-delay:700ms}.bubbles.animated .b8{-webkit-animation-delay:800ms;-moz-animation-delay:800ms}.bubbles.animated .b9{-webkit-animation-delay:900ms;-moz-animation-delay:900ms}.bubbles.animated .b10{-webkit-animation-delay:1000ms;-moz-animation-delay:1000ms}.bubbles.animated .b11{-webkit-animation-delay:1200ms;-moz-animation-delay:1200ms}.bubbles.animated .b12{-webkit-animation-delay:1300ms;-moz-animation-delay:1300ms}.bubbles.animated .b13{-webkit-animation-delay:1400ms;-moz-animation-delay:1400ms}.ie9 .bubbles.animated{opacity:1}hr{border:none;height:1px;background-color:#ddd}@media only screen and (min-width: 40.0625em){hr{margin:3.125rem auto}}@media only screen and (min-width: 58.8125em){hr{max-width:73.125rem}}hr.moby{position:relative;padding:0;margin:1.5625rem auto;border:none;height:1px;background:#ddd}@media only screen and (min-width: 40.0625em){hr.moby{margin:3.125rem auto}}hr.moby::after{content:'';position:absolute;top:-26px;left:50%;margin-left:-26px;height:52px;width:52px;background:url("../images/moby-tiny.svg") no-repeat}hr.dark-bg{background-color:#384c56}.products{width:100%}.products .product-tab{text-align:center;cursor:pointer}.products .product-tab.selected h2{border-bottom:.3rem solid #eee}.products .product-details{position:absolute;right:-9999px}.products .product-details.open{display:block !important;border:.1rem solid #eee}.products .product-details.loaded{position:static;right:auto}.products .product-details>div ul{list-style-type:none;margin:0;text-align:center}.products .product-details>div ul li{margin:0}.products .product-details .product-tiers li .tier{position:relative;display:block;padding:2rem 2rem 5rem;margin-top:1rem;background-color:#F4F9FB;border:1px solid #d6e9f0;border-radius:5px;min-height:20rem}.products .product-details .product-tiers li .tier h2,.products .product-details .product-tiers li .tier h3{text-align:center}.products .product-details .product-tiers li .tier .button{position:absolute;bottom:1rem;text-align:center;display:block;left:15%;right:15%}.products-items{padding:1rem 0;display:block;padding:0;margin:0 -0.625rem}.products-items:before,.products-items:after{content:" ";display:table}.products-items:after{clear:both}.products-items>li{display:block;float:left;height:auto;padding:0 0.625rem 1.25rem}.products-items>li{list-style:none;padding:0 0.625rem 1.25rem;width:100%}.products-items>li:nth-of-type(1n){clear:none}.products-items>li:nth-of-type(1n+1){clear:both}@media only screen and (min-width: 40.0625em){.products-items{display:block;padding:0;margin:0 -0.625rem}.products-items:before,.products-items:after{content:" ";display:table}.products-items:after{clear:both}.products-items>li{display:block;float:left;height:auto;padding:0 0.625rem 1.25rem}.products-items>li{list-style:none;padding:0 0.625rem 1.25rem;width:50%}.products-items>li:nth-of-type(1n){clear:none}.products-items>li:nth-of-type(2n+1){clear:both}}@media only screen and (min-width: 58.8125em){.products-items{display:block;padding:0;margin:0 -0.625rem}.products-items:before,.products-items:after{content:" ";display:table}.products-items:after{clear:both}.products-items>li{display:block;float:left;height:auto;padding:0 0.625rem 1.25rem}.products-items>li{list-style:none;padding:0 0.625rem 1.25rem;width:25%}.products-items>li:nth-of-type(1n){clear:none}.products-items>li:nth-of-type(4n+1){clear:both}}.products-items li{margin-bottom:0.5rem;text-align:center}.products-items-card{display:block;padding:2rem 2rem;background-color:#F4F9FB;border:1px solid #d6e9f0;border-radius:5px}.products-items-card img{max-width:60%;max-height:43px}.products-items-card:hover{background-color:#edf5f8;border:1px solid #d6e9f0}.products-items-card p{color:#7A8491}.products-items-card .link{color:#FF992E}.sub-links ul{list-style:none;text-align:center}.sub-links li{display:inline-block;padding:1rem}.product-features{display:block;padding:0;margin:0 -0.625rem}.product-features:before,.product-features:after{content:" ";display:table}.product-features:after{clear:both}.product-features>li{display:block;float:left;height:auto;padding:0 0.625rem 1.25rem}.product-features>li{list-style:none;padding:0 0.625rem 1.25rem;width:100%}.product-features>li:nth-of-type(1n){clear:none}.product-features>li:nth-of-type(1n+1){clear:both}@media only screen and (min-width: 40.0625em){.product-features{display:block;padding:0;margin:0 -0.625rem}.product-features:before,.product-features:after{content:" ";display:table}.product-features:after{clear:both}.product-features>li{display:block;float:left;height:auto;padding:0 0.625rem 1.25rem}.product-features>li{list-style:none;padding:0 0.625rem 1.25rem;width:50%}.product-features>li:nth-of-type(1n){clear:none}.product-features>li:nth-of-type(2n+1){clear:both}}.timeline{position:relative}.timeline::before{left:5px;content:'';position:absolute;height:100%;width:1px;background:#e1e1e1}.timeline ul{list-style:none;z-index:1;padding:0}.timeline li{margin-bottom:2em;position:relative;display:block}.timeline li h5{color:#fff}.timeline li img{margin-bottom:1rem}.timeline li::before{content:'';top:0;background:#e1e1e1;width:18px;height:18px;border-radius:18px;position:absolute;left:-21px}@media only screen and (min-width: 40.0625em){.timeline{padding-bottom:4rem}.timeline::before{left:50%}.timeline ul{padding-left:0;margin:0 auto}.timeline li{width:50%}.timeline li{padding-left:45px;position:relative;margin-left:50%}.timeline li::before{left:-9px}.timeline li.featured{padding-left:0;padding-right:45px;margin-left:0}.timeline li.featured::before{right:-9px;top:18px;left:auto}.timeline li.featured>div{padding:1rem 1rem 0.15rem 1rem;background:#e1e1e1;border-radius:5px;position:relative}.timeline li.featured>div::after{content:'';position:absolute;right:-12px;top:20px;width:0;height:0;border-style:solid;border-width:8px 0 8px 12px;border-color:transparent transparent transparent #e1e1e1}.timeline li:first-child{margin-top:4em}.timeline li:nth-of-type(2n+1){clear:both}}.timeline li.featured>div{padding:1rem 1rem 0.15rem 1rem;background:#e1e1e1;border-radius:5px}.timeline li.featured.acquisition:before,.timeline li.featured.acquisition>div{background:#22b8eb;color:#fff}.timeline li.featured.acquisition>div::after{border-color:transparent transparent transparent #22b8eb}.timeline li.featured.launch:before,.timeline li.featured.launch>div{background:#86D800;color:#fff}.timeline li.featured.launch>div::after{border-color:transparent transparent transparent #86D800}.timeline li.featured.funding:before,.timeline li.featured.funding>div{background:#FFDE00;color:#fff}.timeline li.featured.funding>div::after{border-color:transparent transparent transparent #FFDE00}.callout{background:#134a6a;padding:1.5625rem 0;margin:4rem 0;position:relative}@media only screen and (min-width: 40.0625em){.callout{padding:4.6875rem 0}}.callout h1,.callout h2,.callout h3,.callout h4,.callout p,.callout a{color:#fff}.og-grid{list-style:none;padding:20px 0;margin:0 auto;text-align:center;width:100%}.og-grid li{display:inline-block;margin:10px 5px 0 5px;vertical-align:top;height:250px}.og-grid li>a,.og-grid li>a img{border:none;outline:none;display:block;position:relative}.og-grid li.og-expanded>a::after{top:auto;border:solid transparent;content:" ";height:0;width:0;position:absolute;pointer-events:none;border-bottom-color:#ddd;border-width:15px;left:50%;margin:-20px 0 0 -15px}.og-expander{position:absolute;background:#ddd;top:auto;left:0;width:100%;margin-top:10px;text-align:left;height:0;overflow:hidden}.og-expander-inner{padding:50px 30px;height:100%}.og-close{position:absolute;width:40px;height:40px;top:20px;right:20px;cursor:pointer}.og-close::before,.og-close::after{content:'';position:absolute;width:100%;top:50%;height:1px;background:#888;-webkit-transform:rotate(45deg);-moz-transform:rotate(45deg);transform:rotate(45deg)}.og-close::after{-webkit-transform:rotate(-45deg);-moz-transform:rotate(-45deg);transform:rotate(-45deg)}.og-close:hover::before,.og-close:hover::after{background:#333}.og-details a::before{content:'\2192';display:inline-block;margin-right:10px}.og-details a:hover{border-color:#999;color:#999}@media screen and (max-width: 830px){.og-expander h3{font-size:32px}.og-expander p{font-size:13px}.og-expander a{font-size:12px}}@media screen and (max-width: 650px){.og-fullimg{display:none}.og-details{float:none;width:100%}}.terminal-window{text-align:left;max-width:650px;border-radius:10px;position:relative;margin-bottom:2rem}.terminal-window header{background:#E0E8F0;height:30px;border-radius:5px 5px 0 0;padding-left:10px}.terminal-window header .btn{width:12px;height:12px;margin:10px 4px 0 0;display:inline-block;border-radius:8px}.terminal-window header .btn.green{background:#3BB662}.terminal-window header .btn.yellow{background:#E5C30F}.terminal-window header .btn.red{background:#E75448}.terminal-window section.terminal{color:white;font-family:Menlo, Monaco, "Consolas", "Courier New", "Courier";font-size:11pt;background:#30353A;padding:15px;width:100%;min-height:320px}.terminal-window section.terminal .typed-cursor{opacity:1;-webkit-animation:blink 1.2s infinite;-moz-animation:blink 1.2s infinite;animation:blink 1.2s infinite}@keyframes blink{0%{opacity:1}50%{opacity:0}100%{opacity:1}}@-webkit-keyframes blink{0%{opacity:1}50%{opacity:0}100%{opacity:1}}@-moz-keyframes blink{0%{opacity:1}50%{opacity:0}100%{opacity:1}}.terminal-window .gray{color:gray}.terminal-window .green{color:green}.terminal-window section.terminal.terminal-small{border-radius:5px;min-height:220px}.customer-and-news{padding:0 0 1.3rem 0}.news-item{margin-top:1.3rem;margin-bottom:3rem}.news-item.no-image{padding-top:4.2rem}.news-item.no-image.featured{padding-top:17.2rem}.news-item div.image{width:60%;margin-left:20%;height:3.5rem;margin-bottom:1rem;background-size:contain;background-position:center center;background-repeat:no-repeat}.news-item.featured div.image{height:25rem;width:100%;margin-left:0}.news-item.divider{border-left:1px solid #eee}.news-item h5{font-size:1rem}.news-item .news-item-title{font-size:1.5rem;color:#22b8eb}.news-item .news-item-description{font-size:0.9rem;color:#7A8491}.press .date{float:left;padding-right:1rem}article.press-item-listing{margin:1rem 0}article.press-item a.source{display:block;height:40px;background-size:contain;background-position:center center;background-repeat:no-repeat}article.press-item strong.date{margin-top:1.5rem;display:block;font-size:.9rem}article.press-item h5{margin:0;line-height:24px}article.press-item p{margin-bottom:0}article.press-item p a{color:#7A8491}.path-all-press article.press-item strong.date{margin-top:initial}.view-more-press{margin-top:2rem;display:block}blockquote{color:#97def6}blockquote.large{font-weight:100;color:#22b8eb;font-size:1.875rem;text-align:center;padding:1.5625rem 10%}@media only screen and (min-width: 58.8125em){blockquote.large{padding:4.6875rem 20% 3.125rem 20%}}blockquote.large cite{color:#666666;font-style:normal;font-size:0.875rem}@media only screen and (min-width: 40.0625em){blockquote.large cite{padding-left:75px}}.intro{padding:1.5625rem inherit;text-align:center}@media only screen and (min-width: 40.0625em){.intro{padding:1.25rem inherit 0.625rem inherit}}.intro li{text-align:center}.intro-header{padding:1.7rem 0 1.5rem 0;text-align:center}.intro-header p{font-size:1.25rem}.legal-content{margin-top:4rem}.stats-items{padding:1rem 0;display:block;padding:0;margin:0 -0.625rem}.stats-items:before,.stats-items:after{content:" ";display:table}.stats-items:after{clear:both}.stats-items>li{display:block;float:left;height:auto;padding:0 0.625rem 1.25rem}.stats-items>li{list-style:none;padding:0 0.625rem 1.25rem;width:100%}.stats-items>li:nth-of-type(1n){clear:none}.stats-items>li:nth-of-type(1n+1){clear:both}@media only screen and (min-width: 40.0625em){.stats-items{display:block;padding:0;margin:0 -0.625rem}.stats-items:before,.stats-items:after{content:" ";display:table}.stats-items:after{clear:both}.stats-items>li{display:block;float:left;height:auto;padding:0 0.625rem 1.25rem}.stats-items>li{list-style:none;padding:0 0.625rem 1.25rem;width:50%}.stats-items>li:nth-of-type(1n){clear:none}.stats-items>li:nth-of-type(2n+1){clear:both}}@media only screen and (min-width: 58.8125em){.stats-items{display:block;padding:0;margin:0 -0.625rem}.stats-items:before,.stats-items:after{content:" ";display:table}.stats-items:after{clear:both}.stats-items>li{display:block;float:left;height:auto;padding:0 0.625rem 1.25rem}.stats-items>li{list-style:none;padding:0 0.625rem 1.25rem;width:33.33333%}.stats-items>li:nth-of-type(1n){clear:none}.stats-items>li:nth-of-type(3n+1){clear:both}}.stats-items li{margin-bottom:0.5rem;text-align:center}.path-hackathon .panel{padding-bottom:1.5rem}.path-hackathon .panel hr{margin:1.125rem auto}.path-hackathon .panel .tags{margin-bottom:1rem}.path-hackathon .panel .tags .tag{font-size:.725rem;white-space:normal}.path-hackathon .steps p{padding-left:2rem}.path-hackathon .alert-box{background-image:none;overflow:hidden}.path-hackathon .alert-box .button{margin-bottom:0;float:right}.path-hackathon .alert-box.info{color:#31708f}.path-hackathon span.badge{display:inline-block;min-width:10px;padding:3px 7px;font-size:12px;font-weight:bold;line-height:1;color:#fff;text-align:center;white-space:nowrap;vertical-align:baseline;background-color:#777;border-radius:10px;background:none repeat scroll 0 0 #e9583a;float:left;position:relative;top:5px}.path-hackathon .contacts{margin-top:25px}.path-hackathon .social{position:absolute;bottom:1.25rem;left:50%;transform:translateX(-50%)}.path-hackathon a.button{background-color:#FF992E}.path-hackathon a.button.contact{background-color:#22b8eb}.path-hackathon .row.submit{margin-top:-3rem}.path-hackathon .row.well{background:#e8f6f9;padding-top:1rem;margin-top:9rem}.path-hackathon .social{text-align:center;margin-bottom:10px}.path-hackathon .social a{display:inline-block;color:white;padding:3px 10px}.path-hackathon .social a.twitter{background-color:#00a9f1}.path-hackathon .social a.google{background-color:#e0452c}.path-hackathon .social a.linkedin{background-color:#007bb6}.node-type-enterprise .page-content{text-align:center;-webkit-font-smoothing:antialiased;-moz-osx-font-smoothing:grayscale}.node-type-enterprise .page-content section{padding-top:60px;padding-bottom:60px}.node-type-enterprise .page-content section h1,.node-type-enterprise .page-content section h2{margin-bottom:25px}.node-type-enterprise .page-content section h2{font-size:44px}.node-type-enterprise .page-content section p{font-size:20px}.node-type-enterprise .page-content .why-docker .reason p,.node-type-enterprise .page-content .features .feature p,.node-type-enterprise .page-content .services p{font-size:16px}.node-type-enterprise .page-content section.dark-blue{background-color:#134a6a}.node-type-enterprise .page-content section.dark-blue h2,.node-type-enterprise .page-content section.dark-blue p{color:#dde7f7}.node-type-enterprise .page-content section.docker-grey{background-color:#243137}.node-type-enterprise .page-content section.docker-grey h2{color:#22b8eb}.node-type-enterprise .page-content section.docker-grey p{color:#dde7f7}.node-type-enterprise .page-content section.docker-bg{background-color:#F4F9FB}.node-type-enterprise .page-content section.docker-bg h2{color:#22b8eb}.node-type-enterprise .page-content .hero-sub{background-color:#243137;margin-bottom:0px}.node-type-enterprise .page-content .hero-sub .landing-hero-des{margin-bottom:0;padding:0}.node-type-enterprise .page-content .hero-sub .button{margin-top:40px}@media only screen and (max-width: 40em){.node-type-enterprise .page-content .hero-sub .button{width:100%;margin-top:20px}}.node-type-enterprise .page-content .hero-sub .button+.button{margin-left:30px}@media only screen and (max-width: 40em){.node-type-enterprise .page-content .hero-sub .button+.button{margin-left:0}}.node-type-enterprise .page-content .hero-sub p{font-size:20px;color:#dde7f7}.node-type-enterprise .page-content .hero-sub a{color:#dde7f7}.node-type-enterprise .page-content h1{color:#22b8eb}.node-type-enterprise .page-content .why-docker img,.node-type-enterprise .page-content .why-docker h3{margin-bottom:15px}.node-type-enterprise .page-content .why-docker .footer .button{margin-top:50px}@media only screen and (max-width: 40em){.node-type-enterprise .page-content .docker-solution .sidebar{margin-bottom:50px}}.node-type-enterprise .page-content .docker-solution .feature{text-align:left;margin-bottom:50px}@media only screen and (min-width: 40.0625em) and (max-width: 58.75em){.node-type-enterprise .page-content .docker-solution .feature{text-align:center}}@media only screen and (max-width: 40em){.node-type-enterprise .page-content .docker-solution .feature{text-align:center}}.node-type-enterprise .page-content .docker-solution .graphic{text-align:center;margin-bottom:1.25rem}.node-type-enterprise .page-content .docker-solution .button+.button{margin-left:30px}@media only screen and (max-width: 40em){.node-type-enterprise .page-content .docker-solution .button+.button{margin-left:0px}}@media only screen and (max-width: 40em){.node-type-enterprise .page-content .docker-solution .button{width:100%;margin-top:20px}}.node-type-enterprise .page-content .docker-solution h3{line-height:1;margin-top:0px;margin-bottom:1.25rem}.node-type-enterprise .page-content .deploy-docker .item{display:inline-block;vertical-align:middle;float:none;padding-top:20px;margin-left:2.5rem;margin-right:2.5rem}@media only screen and (min-width: 40.0625em) and (max-width: 58.75em){.node-type-enterprise .page-content .deploy-docker .item{margin-left:1.5rem;margin-right:1.5rem}}@media only screen and (max-width: 40em){.node-type-enterprise .page-content .deploy-docker .item{margin:0 auto;display:block}}.node-type-enterprise .page-content .deploy-docker .item:first-child{margin-left:0px}@media only screen and (max-width: 40em){.node-type-enterprise .page-content .deploy-docker .item:first-child{margin-left:auto}}.node-type-enterprise .page-content .deploy-docker .item:last-child{margin-right:0px}@media only screen and (max-width: 40em){.node-type-enterprise .page-content .deploy-docker .item:last-child{margin-right:auto}}.node-type-enterprise .page-content .deploy-docker .columns+.columns:last-child{float:none;width:23%}@media only screen and (max-width: 40em){.node-type-enterprise .page-content .deploy-docker .columns+.columns:last-child{width:80%}}.node-type-enterprise .page-content .services-support .header,.node-type-enterprise .page-content .transforming-business .header,.node-type-enterprise .page-content .why-docker .header{margin-bottom:50px}.node-type-enterprise .page-content .services-support img{margin-bottom:1.25rem}@media only screen and (max-width: 40em){.node-type-enterprise .page-content .services-support .services>div{margin-bottom:50px}}.node-type-enterprise .page-content .transforming-business .businesses-logos{text-align:center;margin-bottom:40px}.node-type-enterprise .page-content .transforming-business .businesses-logos img{padding:20px 20px 0px 20px;display:inline-block;vertical-align:middle}@media only screen and (max-width: 40em){.node-type-enterprise .page-content .transforming-business .businesses-logos img{padding:20px}}.node-type-enterprise .page-content .resources{text-align:left}@media only screen and (max-width: 40em){.node-type-enterprise .page-content .resources .sidebar{text-align:center;margin-bottom:50px}}.node-type-enterprise .page-content .resources .resource-items{background-color:#F4F9FB;border:1px solid #d8e2f1;-webkit-border-radius:3px;-moz-border-radius:3px;border-radius:3px;padding-left:30px;padding-right:30px}.node-type-enterprise .page-content .resources .resource-items .item{padding-top:25px;padding-bottom:25px;position:relative}.node-type-enterprise .page-content .resources .resource-items .item>a{width:96%;vertical-align:middle;display:inline-block}.node-type-enterprise .page-content .resources .resource-items .item:after{font-family:"FontAwesome";content:"\f105";display:inline-block;color:#FF992E;font-size:25px;right:0;width:2%;position:absolute;top:50%;-webkit-transform:translateY(-50%);-ms-transform:translateY(-50%);transform:translateY(-50%)}.node-type-enterprise .page-content .resources .resource-items .item+.item{border-top:1px solid #d8e2f1}.node-type-enterprise .page-content .resources .resource-items .item .heading{font-size:23px;display:block;margin-bottom:25px;line-height:1}.node-type-enterprise .page-content .resources .resource-items .item .description{display:block;font-size:16px;color:#7A8491;line-height:1}header .nav-global a,.main-header div>.nav-main a,.nav-sub a,.side-nav li a:not(.button),.bsr-item,.products-items-card{transition:all .3s ease}.hero::after,.callout::after{background:url("../images/hero-wave.svg") repeat-x;height:16px;width:100%;position:absolute;bottom:0;left:0;content:""}.ie9 img[src*=".svg"]{width:100%}@media screen and (-ms-high-contrast: active), (-ms-high-contrast: none){img[src*=".svg"]{width:100%}}[ng-cloak]{display:none} diff --git a/Webseiten/Docker - Build, Ship, and Run Any App, Anywhere_files/app.js b/Webseiten/Docker - Build, Ship, and Run Any App, Anywhere_files/app.js new file mode 100644 index 0000000..fa0aada --- /dev/null +++ b/Webseiten/Docker - Build, Ship, and Run Any App, Anywhere_files/app.js @@ -0,0 +1,610 @@ +jQuery(document).foundation({ + equalizer : { + equalize_on_stack: true + } +}); +wow = new WOW( + { + boxClass: 'wow', // default + animateClass: 'animated', // default + offset: 200, // default + mobile: false, // default + live: true // default + } +) +wow.init(); + + if ($('.heronav_section').length > 0) { + $('.heronav_section').affix({ + offset: { + top:$(".heronav_section").offset().top, + bottom: $('footer').outerHeight(true) + } + }); + } +jQuery.each( jQuery.browser, function( i, val ) { + $('html').addClass(i, val); +}); +$(document).on('click', 'a[href*="#"]:not(.noanchor , .find_a_partner_section .cbp-caption-defaultWrap, .strategic_alliances_tabs li a)', function() { + if ( this.hash && this.pathname === location.pathname ) { + $.bbq.pushState( '#/' + this.hash.slice(1) ); + return false; + } + }).ready(function() { + $(window).bind('hashchange', function(event) { + var tgt = location.hash.replace(/^#\/?/,''); + if ( document.getElementById(tgt) ) { + //$.smoothScroll.animateScroll( null,{scrollTarget: '#' + tgt }, { speed: 1000, easing: 'easeOutCubic' } ); + if ($('body').hasClass('node-type-products') || $('body').hasClass('node-type-product') || $('body').hasClass('node-type-use-cases') || $('body').hasClass('node-type-use-case') || $('body').hasClass('node-type-enterprise') || $('body').hasClass('node-type-government') || $('body').hasClass('node-type-partners') || $('body').hasClass('node-type-partner-programs')) { + if ($(window).width() > 991 ) { + $('html,body').animate({ scrollTop: $('#' + tgt).offset().top -69}, 'slow'); + } else if($(window).width() > 768 && $(window).width() < 991 ) { + $('html,body').animate({ scrollTop: $('#' + tgt).offset().top -59}, 'slow'); + } else { + $('html,body').animate({ scrollTop: $('#' + tgt).offset().top -59}, 'slow'); + } + } else { + $.smoothScroll({scrollTarget: '#' + tgt}); + } + //$.smoothScroll({scrollTarget: '#' + tgt}); + } + }); + $(window).trigger('hashchange'); + }); +(function($) { + $('.bsr-item-detail').hide(); + $('.bsr-item').on('click', function(e) { + e.preventDefault(); + // find the target of the clicked anchor tag + var targetBSR = $(this).find('a')[0].hash; + var parentBSR = $(this); + // hide detail containers, not the the current target + $('.bsr-item-detail').not(targetBSR).hide(); + // toggle current target detail container + $(targetBSR).slideToggle(); + + // toggle parent active class + if (parentBSR.hasClass('is-active')) { + parentBSR.removeClass('is-active'); + } + else { + // wipe out all other active classes + $('.bsr-item').each(function() { + $(this).removeClass('is-active'); + }); + // add active class to the current parent + parentBSR.addClass('is-active'); + } + }); + $('.quotes_slider').flexslider({ + animation: "slide", + directionNav: false + }); + $('.CTA_section').each(function() { + $(this).children('.mheight').matchHeight(); + }); + $('.CTA_section .row').each(function() { + $(this).children('.CTA_item').matchHeight(); + }); + $('.resources_items.row').each(function() { + $(this).children('.resources_link').matchHeight(); + }); + $('.mhp').each(function() { + $(this).children('.mhc').matchHeight(); + }); + $('a[target="_video"]').magnificPopup({ + midClick: true, + type: 'iframe', + mainClass: 'mfp-fade', + removalDelay: 160, + preloader: false, + disableOn: 280, + fixedContentPos: false + }); + $('a[rel="video"]').magnificPopup({ + midClick: true, + type: 'iframe', + mainClass: 'mfp-fade', + removalDelay: 160, + preloader: false, + disableOn: 280, + fixedContentPos: false + }); +$(window).load(function() { + $(window).trigger("resize"); +}); +$(window).resize(function() { + $('body>.off-canvas-wrap').css('min-height', $(window).height() - ($('.main-footer').outerHeight(true))); + $(".plan_name2 , .plan_name3").height($(".plan_name1").outerHeight(true)); + var maxHeight_title = -1; + maxHeight_title = maxHeight_title > $(".ibm_solutions .title").height() ? maxHeight_title : $(".ibm_solutions .title").height(); + $(".ibm_solutions .title").height(maxHeight_title); + var maxHeight_body = -1; + + maxHeight_body = maxHeight_body > $(".ibm_solutions .body").height() ? maxHeight_body : $(".ibm_solutions .body").height(); + $(".ibm_solutions .body").height(maxHeight_body); + + var maxHeight_productbox = -1; + $('.docker_solutions_section .media').each(function() { + maxHeight_productbox = maxHeight_productbox > $(this).height() ? maxHeight_productbox : $(this).height(); + }); + $('.docker_solutions_section .media').each(function() { + $(this).height(maxHeight_productbox); + }); + + var maxHeight_productboxul = -1; + $('.docker_solutions_section .body_box ul').each(function() { + maxHeight_productboxul = maxHeight_productboxul > $(this).height() ? maxHeight_productboxul : $(this).height(); + }); + $('.docker_solutions_section .body_box ul').each(function() { + $(this).height(maxHeight_productboxul); + }); + + var maxHeight_productpricing = -1; + $('section.pricing_product_section .plan_box .header').each(function() { + maxHeight_productpricing = maxHeight_productpricing > $(this).height() ? maxHeight_productpricing : $(this).height(); + }); + $('section.pricing_product_section .plan_box .header').each(function() { + $(this).height(maxHeight_productpricing); + }); + + var maxHeight_productdemo = -1; + $('section.demo_product_section .items li .mheight').each(function() { + maxHeight_productdemo = maxHeight_productdemo > $(this).height() ? maxHeight_productdemo : $(this).height(); + }); + $('section.demo_product_section .items li .mheight').each(function() { + $(this).height(maxHeight_productdemo); + }); + + var maxHeight_productuse = -1; + $('section.use_product_section .items li .mheight').each(function() { + maxHeight_productuse = maxHeight_productuse > $(this).height() ? maxHeight_productuse : $(this).height(); + }); + $('section.use_product_section .items li .mheight').each(function() { + $(this).height(maxHeight_productuse); + }); +}).trigger("resize"); + +$(window).load(function() { + var maxHeight_use_cases_overview_h3 = -1; + $('section.use_cases_section .items li .item-link').each(function() { + maxHeight_use_cases_overview_h3 = maxHeight_use_cases_overview_h3 > $(this).height() ? maxHeight_use_cases_overview_h3 : $(this).height(); + }); + $('section.use_cases_section .items li .item-link').each(function() { + $(this).height(maxHeight_use_cases_overview_h3 + 15); + }); + + var maxHeight_use_cases_overview_p = -1; + $('section.use_cases_section .items li p').each(function() { + maxHeight_use_cases_overview_p = maxHeight_use_cases_overview_p > $(this).height() ? maxHeight_use_cases_overview_p : $(this).height(); + }); + $('section.use_cases_section .items li p').each(function() { + $(this).height(maxHeight_use_cases_overview_p); + }); +}); +$(document).ready(loadRetina); +$(window).resize(loadRetina); +function loadRetina() { + if(window.devicePixelRatio > 1) { + $('html,body').addClass('retina-display'); + } else { + $('html,body').removeClass('retina-display'); + } +} +$(".plans_tabs ul a").click(function(event) { + event.preventDefault(); + var tab = $(this).attr("href"); + $(this).parent().addClass("current").siblings().removeClass("current"); + $(tab).addClass("current").fadeIn().siblings('.plans').removeClass("current").hide(); +}); +$('.faq-body').each(function() { + $(this).parent('.faq').addClass('collapsible'); +}); +$(".faqs-group").on( "click", ".faq-title", function(e) { + e.preventDefault(); + var $FAQ = $(this).parent(".faq"), $FAQz = $(".faq").not($FAQ); + $FAQ.toggleClass("active"); + $(".faq-body",$FAQ).slideToggle(300) + $FAQz.removeClass("active"); + $(".faq-body",$FAQz).slideUp(300); +}); +if ($(window).width() > 1199) { + $(".faqs_section .faqs-group").height($(".faqs-group .col-xs-12").outerHeight(true) + 120); + } else if ($(window).width() < 1200 && $(window).width() > 991) { + $(".faqs_section .faqs-group").height($(".faqs-group .col-xs-12").outerHeight(true) + 180); + } else if ($(window).width() < 992 && $(window).width() > 767) { + $(".faqs_section .faqs-group").height($(".faqs-group .col-xs-12").outerHeight(true) + 190); + } else { + $(".faqs_section .faqs-group").height($(".faqs-group .col-xs-12").outerHeight(true) + $(".faqs-group .col-xs-12").outerHeight(true) + 70); + } + + $('.serverplan_boxs').each(function() { + $(this).children('.col-sm-4').matchHeight(); + }); + $('.plans_section .cloud_plan_boxs').each(function() { + $(this).children('.col-xs-12').matchHeight(); + }); + +var sliderRepoMap = [1, 5, 10, 20, 50, 100, 250] +, RepoSlider = $( "#RepoSlider" ) +, CmSupport = $("#RepoCommercialSupport") +, CrSupport = $("#RepoCriticalSupport") +, BuyButtontxt +, BuyButtonURL +, Repos +, RepoPrice +, RepoPricing +, PricingInfo +, RepoSliderVal; + + RepoSlider.slider({ + value: 3, + min: 0, + max: sliderRepoMap.length-1, + slide: function( event, ui ) { + RepoPlans(ui.value) + CmSupport.prop('checked', false).prop('disabled', false); + CrSupport.prop('checked', false); + $.bbq.pushState( '#/repo-' + sliderRepoMap[ui.value] ); + }, + change :function( event, ui ) { + RepoPlans(RepoSlider.slider('value')) + $.bbq.pushState( '#/repo-' + sliderRepoMap[RepoSlider.slider('value')] ); + } + }).slider("pips", { + rest: "label", + labels: sliderRepoMap + }); +$("#RepoSlider.ui-slider-pips .ui-slider-label").on( "click", function(e) { + CmSupport.prop('checked', false).prop('disabled', false); + CrSupport.prop('checked', false); +}); +$(window).on('load', RepoPlans(RepoSlider.slider('value'))); +function RepoPlans(RepoSliderValue) { + RepoSliderVal = RepoSliderValue; + if(RepoSliderVal == 0){ + RepoPrice = 0; + RepoPricing = RepoPricing_free; + BuyButtontxt = buybuttontxt_signup; + } else if(RepoSliderVal < 4) { + RepoPrice = parseFloat(sliderRepoMap[RepoSliderVal]) + 2; + RepoPricing = '$ ' + RepoPrice + ' / month'; + BuyButtontxt = BuyButtontxt_buy; + } else { + RepoPrice = parseFloat(sliderRepoMap[RepoSliderVal]); + RepoPricing = '$ ' + RepoPrice + ' / month'; + BuyButtontxt = BuyButtontxt_buy; + } + if(RepoSliderVal == 0) { + BuyButtonURL = BuyButtonURL_0; + } else if(RepoSliderVal == 1) { + BuyButtonURL = BuyButtonURL_1; + } else if(RepoSliderVal == 2) { + BuyButtonURL = BuyButtonURL_2; + } else if(RepoSliderVal == 3) { + BuyButtonURL = BuyButtonURL_3; + } else if(RepoSliderVal == 4) { + BuyButtonURL = BuyButtonURL_4; + } else if(RepoSliderVal == 5) { + BuyButtonURL = BuyButtonURL_5; + } else if(RepoSliderVal == 6) { + BuyButtonURL = BuyButtonURL_6; + } else { + BuyButtonURL = BuyButtonURL_0; + } + Repos = sliderRepoMap[RepoSliderVal]; + if(RepoSliderVal == 0) { + PricingInfo = '
  • '+Repos+PricingInfo_freeText+'
    • '; + } else { + PricingInfo = '
  • '+Repos+PricingInfo_Text+'
    • '; + } + $('#PricingInfo').html(PricingInfo); + $('#RepoBuyButton').text(BuyButtontxt); + $('#RepoBuyButton').attr('href', BuyButtonURL); + $('#RepoPricing').html(RepoPricing); +} + +$(CmSupport).on('change', RepoCommercialSupport); +function RepoCommercialSupport() { + RepoSliderVal = RepoSlider.slider('value'); + RepoSlider.slider('value', 3); + if((CmSupport).is(':checked')) { + Repos = sliderRepoMap[RepoSliderVal]; + RepoPrice = 150; + RepoPricing = '$ ' + RepoPrice + ' / month'; + BuyButtontxt = BuyButtontxt_buy; + BuyButtonURL = BuyButtonURL_cloud_starter; + PricingInfo = '
  • '+Repos+PricingInfo_CommercialSupportText+'
    • '; + $('#PricingInfo').html(PricingInfo); + $('#RepoBuyButton').text(BuyButtontxt); + $('#RepoBuyButton').attr('href', BuyButtonURL); + $('#RepoPricing').html(RepoPricing); + $.bbq.pushState( '#/repo-commercial-support' ); + } else { + RepoPlans(RepoSlider.slider('value')); + RepoSlider.slider('enable'); + $.bbq.pushState( '#/repo-' + sliderRepoMap[RepoSlider.slider('value')] ); + } +} + +$(CrSupport).on('change', RepoCriticalSupport); +function RepoCriticalSupport() { + RepoSliderVal = RepoSlider.slider('value'); + RepoSlider.slider('value', 3); + if((CrSupport).is(':checked')) { + CmSupport.prop('checked', true).prop('disabled', true); + Repos = sliderRepoMap[RepoSliderVal]; + RepoPricing = RepoPricing_CriticalSupport; + BuyButtontxt = buybuttontxt_quote; + BuyButtonURL = BuyButtonURL_inquiry; + PricingInfo = '
  • '+Repos+PricingInfo_CriticalSupportText+'
    • '; + $('#PricingInfo').html(PricingInfo); + $('#RepoBuyButton').text(BuyButtontxt); + $('#RepoBuyButton').attr('href', BuyButtonURL); + $('#RepoPricing').html(RepoPricing); + $.bbq.pushState( '#/repo-critical-support' ); + } else { + CmSupport.prop('disabled', false); + RepoCommercialSupport(); + } +} +if(window.location.hash.match('repo-') != null) { + var repopkg = location.hash.replace(/^#\/repo-?/,''); +// alert(repopkg); + if(repopkg == 'commercial-support') { + $('a[href*="#tab-cloud"]').parent().addClass("current").siblings().removeClass("current"); + $('#tab-cloud').addClass("current").fadeIn().siblings('.plans').removeClass("current").hide(); + CmSupport.prop('checked', true); + RepoCommercialSupport(); + } else if (repopkg == 'critical-support') { + $('a[href*="#tab-cloud"]').parent().addClass("current").siblings().removeClass("current"); + $('#tab-cloud').addClass("current").fadeIn().siblings('.plans').removeClass("current").hide(); + CrSupport.prop('checked', true); + RepoCriticalSupport(); + } else { + repopkg = jQuery.inArray( parseFloat(repopkg), sliderRepoMap ); + $('a[href*="#tab-cloud"]').parent().addClass("current").siblings().removeClass("current"); + $('#tab-cloud').addClass("current").fadeIn().siblings('.plans').removeClass("current").hide(); + RepoSlider.slider('value', repopkg); + } +} + +if(window.location.hash === "#/forcloud" || window.location.hash === "#forcloud" || window.location.hash === "#/forserver" || window.location.hash === "#forserver") { + var tab = location.hash.replace(/^#\/for?/,'#tab-'); + $('a[href*="'+tab+'"]').parent().addClass("current").siblings().removeClass("current"); + $(tab).addClass("current").fadeIn().siblings('.plans').removeClass("current").hide(); +} + +$('.products-items').each(function() { + $(this).children('li').matchHeight(); + }); +$(".nolinkhere").on('click', function(e) { + e.preventDefault(); +}); +$('.ibm_solutions').each(function() { + $(this).children('.ibm_solution').matchHeight(); + }); + +var check_initfederal_item01 = true; +var check_initfederal_item02 = true; +var check_initfederal_item03 = true; +$(window).scroll(function() { + var visibilityfederal_item01 = $('#federal_item01.federal_item').css('visibility'); + if (visibilityfederal_item01 == 'visible'){ + if(check_initfederal_item01){ + initfederal_item01(); + check_initfederal_item01 = false; + } + } +}); +$(window).scroll(function() { + var visibilityfederal_item02 = $('#federal_item02.federal_item').css('visibility'); + if (visibilityfederal_item02 == 'visible'){ + if(check_initfederal_item02){ + initfederal_item02(); + check_initfederal_item02 = false; + } + } +}); +$(window).scroll(function() { + var visibilityfederal_item03 = $('#federal_item03.federal_item').css('visibility'); + if (visibilityfederal_item03 == 'visible'){ + if(check_initfederal_item03){ + initfederal_item03(); + check_initfederal_item03 = false; + } + } +}); +$(window).load(function() { + if ($('body').hasClass('page-node-6439')){ + initfederal_all_item(); + } +}); +$(window).load(function() { + var isoOptions = { + itemSelector : '.events_region', + masonry: { + columnWidth: '.col-md-6' + } + }; + var $grid = $('.events_section .events_regions').isotope( isoOptions ); + $('.event-search input.ng-valid').on('keyup', function() { + if ($(".events_regions .events_region").siblings().size() > 1) { + $('.events_regions .events_region').removeClass('row'); + $('.events_regions .events_region').addClass('col-xs-12 col-sm-6 col-md-6'); + $('.events_regions .events_region .media.events_item').removeClass('col-xs-12 col-sm-6 col-md-6'); + $('.events_regions .events_region .events_region_name').removeClass('col-xs-12 col-md-12'); + $('.events_regions').removeClass('margintop55'); + $grid.isotope('destroy'); + // $grid.isotope('reloadItems') + $grid.isotope({ + itemSelector : '.events_region', + masonry: { + columnWidth: '.col-md-6' + } + }); + } else { + $('.events_regions .events_region').addClass('row'); + $('.events_regions .events_region').removeClass('col-xs-12 col-sm-6 col-md-6'); + $('.events_regions .events_region .media.events_item').addClass('col-xs-12 col-sm-6 col-md-6'); + $('.events_regions .events_region .events_region_name').addClass('col-xs-12 col-md-12'); + $('.events_regions').addClass('margintop55'); + $grid.isotope('destroy'); + $grid.isotope({ + itemSelector : '.events_region .events_item', + masonry: { + columnWidth: '.col-md-6' + } + }); + } + + setTimeout(function(){ $grid.isotope('layout'); }, 2000); + }); + $('.event-search select.ng-valid').on('change', function() { + if ($(".events_regions .events_region").siblings().size() > 1) { + $('.events_regions .events_region').removeClass('row'); + $('.events_regions .events_region').addClass('col-xs-12 col-sm-6 col-md-6'); + $('.events_regions .events_region .media.events_item').removeClass('col-xs-12 col-sm-6 col-md-6'); + $('.events_regions .events_region .events_region_name').removeClass('col-xs-12 col-md-12'); + $('.events_regions').removeClass('margintop55'); + $grid.isotope('destroy'); + $grid.isotope({ + itemSelector : '.events_region', + masonry: { + columnWidth: '.col-md-6' + } + }); + + } else { + $('.events_regions .events_region').addClass('row'); + $('.events_regions .events_region').removeClass('col-xs-12 col-sm-6 col-md-6'); + $('.events_regions .events_region .media.events_item').addClass('col-xs-12 col-sm-6 col-md-6'); + $('.events_regions .events_region .events_region_name').addClass('col-xs-12 col-md-12'); + $('.events_regions').addClass('margintop55'); + $grid.isotope('destroy'); + $grid.isotope({ + itemSelector : '.events_region .events_item', + masonry: { + columnWidth: '.col-md-6' + } + }); + + } + + setTimeout(function(){ $grid.isotope('layout'); }, 2000); + }); +}); +$('a[href="#toptop"]').click(function () { + $('body,html').animate({ + scrollTop: 0 + }, 800); + return false; + }); + +$(window).load(function() { + $('.resources_video_slider , .demo_product_section, .rest_apis_product_section, .customer_spotlight_section ').flexslider({ + selector: ".slides > .slide", + animation: "fade", + controlNav: true, + directionNav: false + }); + $('.technology_partners_section, .program_benefits_section').each(function() { + $(this).children('li').matchHeight(); + }); +}); +$('.products_items').each(function() { + $(this).children('li').matchHeight(); + }); +$('.product_features_product_section ul.items ').each(function() { + $(this).children('li').matchHeight(); + }); +$('.pricing_product_section .plan_boxes').each(function() { + $(this).children('.plan_box').matchHeight(); + }); +$('.GenericDev .items').each(function() { + $(this).children('li').matchHeight(); + }); +$('.quotes_use_cases_slider').flexslider({ + animation: "slide", + directionNav: true, + controlNav: false + }); +$('.quotes_2_slider').flexslider({ + animation: "slide", + directionNav: true, + controlNav: false + }); +$('.off-canvas-list li.has-submenu').prepend(''); + +$(".strategic_alliances_tabs ul a").click(function(event) { + event.preventDefault(); + var tab = $(this).attr("href"); + $(this).parent().addClass("current").siblings().removeClass("current"); + $(tab).addClass("current").fadeIn().siblings('.strategic_alliances').removeClass("current").hide(); + }); + /* ===================== 1 Mar =====================*/ +$(".find_a_partner_section ul.partners_list li.no_info a.cbp-singlePageInline.cbp-nocontent").click(function() { + var asdasd= $(this); + $(asdasd).parents('#grid-container').addClass('nomore').removeClass('nomore2'); + }); + $(".find_a_partner_section ul.partners_list li a.cbp-singlePageInline.cbp-hascontent").click(function() { + var qweqwe= $(this); + $(qweqwe).parents('#grid-container').addClass('nomore2').removeClass('nomore'); + }); + +})(jQuery); +(function ($, window, document, undefined) { + + var gridContainer = $('#grid-container,#grid-container2'); + + // init cubeportfolio + gridContainer.cubeportfolio({ + + animationType: 'rotateSides', + + gapHorizontal: 30, + + gapVertical: 30, + + gridAdjustment: 'responsive', + + caption: '', + + displayType: 'sequentially', + + displayTypeSpeed: 100, + + // lightbox + lightboxDelegate: '.cbp-lightbox', + lightboxGallery: true, + lightboxTitleSrc: 'data-title', + lightboxShowCounter: true, + + // singlePage popup + singlePageDelegate: '.cbp-singlePage', + singlePageDeeplinking: true, + singlePageStickyNavigation: true, + singlePageShowCounter: true, + singlePageCallback: function (url, element) { + // to update singlePage content use the following method: this.updateSinglePage(yourContent) + }, + + // singlePageInline + singlePageInlineDelegate: '.cbp-singlePageInline', + singlePageInlinePosition: 'below', + singlePageInlineShowCounter: true, + singlePageInlineCallback: function(url, element) { + + // to update singlePageInline content use the following method: this.updateSinglePageInline(yourContent) + var t = this; + if($(url).length == 0) { + return false; + } else { + var cont = $(url).html(); + t.updateSinglePageInline(cont); + } + + } + }); + +})(jQuery, window, document); \ No newline at end of file diff --git a/Webseiten/Docker - Build, Ship, and Run Any App, Anywhere_files/app1.css b/Webseiten/Docker - Build, Ship, and Run Any App, Anywhere_files/app1.css new file mode 100644 index 0000000..325f767 --- /dev/null +++ b/Webseiten/Docker - Build, Ship, and Run Any App, Anywhere_files/app1.css @@ -0,0 +1,5114 @@ +@media screen and (-ms-high-contrast:active), all and (-ms-high-contrast:none) { +img[src*='.svg'] { + width: 100%; + height: 100%; +} +} +section.section{ +padding:50px 0; +} +section.title_section{ + text-align: center; + padding: 26px 0 22px 0; + background-color: #27b8e8; + min-height: 104px; +} +section.title_section h1{ + color: #fff; + font-size: 44px; + line-height: 1.2; +} +section.title_section p{ + color: #fff; +} +section.banner_section{ + width: 100%; + display: table; + position: relative; +} +section.banner_section .left-banner,section.banner_section .right-banner{ + width: 50%; + background-color: #ced4d6; + display: table-cell; + text-align: center; +} +section.banner_section .left-banner{ +border-right: 3px solid #fff; +} +section.banner_section .right-banner{ +border-left: 3px solid #fff; +} +section.banner_section .video_box{ +position: relative; + max-height: 380px; + overflow: hidden; +} +section.banner_section .video_box img{ + height: auto; + width: auto; + display: block; + margin: auto; +} +.video_play{ + height: 89px; + width: 89px; + display: block; + position: absolute; + top: 50%; + left: 50%; + background-image: url(../images/play-btn.png); + background-repeat: no-repeat; + margin-left: -45px; + margin-top: -45px; +} +section.banner_section p{ + font-size: 19px; + color: #3a3f43; + margin: 25px; +} +a.btn-orange { + font-weight: bold; + color: #fff; + background-color: #fe9a3f; + font-size: 20px; + margin: 20px 0 25px 0; + padding: 12px 12px; + border-radius: 10px; + text-transform: uppercase; +} +.btn-orange:hover, .btn-orange:focus, .btn-orange.focus { + color: #fff; +} +section.feature_customers_section h2{ + color: #2cacd7; + font-size: 44px; + text-align: center; +} +section.feature_customers_section .container { + /* padding-right: 40px; */ +} +section.feature_customers_section .container .row { + margin-left: -40px; + margin-right: -40px; + width: auto; + max-width: none; +} +section.feature_customers_section .container .row .col-sm-4{ + padding-left: 40px; + padding-right: 40px; +} +section.feature_customers_section .feature_customers a.feature_customer{ +text-align: center; + display: block; + overflow: hidden; + position: relative; + margin: 30px 0; + height: 245px; + border: 1px solid #E1E6E9; +} +section.feature_customers_section a.feature_customer span.mask { + position: absolute; + opacity: 0; + overflow: visible; + -moz-box-sizing: border-box; + -webkit-box-sizing: border-box; + box-sizing: border-box; + -webkit-transition: all 0.2s ease-in-out; + -moz-transition: all 0.2s ease-in-out; + -o-transition: all 0.2s ease-in-out; + -ms-transition: all 0.2s ease-in-out; + transition: all 0.2s ease-in-out; + left: 0; + right: 0; + top: 0; + bottom: 0; + background-color: #29bbec; +} + +section.feature_customers_section a.feature_customer span.vcenter { + position: absolute; + display: table; + width: 100%; + color: white; + cursor: pointer; + left: 0; + top: 0; + padding: 0px 10px; + right: 0; + bottom: 0; + text-align: center; + margin: auto; + opacity: 0; + font-size: 22px; + font-weight: bold; + color: #fff; + text-transform: uppercase; +} +section.feature_customers_section a.feature_customer span.icon { + position: absolute; + height: 37px; + width: 37px; + bottom: 6px; + right: 6px; + background-image: url(../images/view_icon.png); + background-position: -37px 0; + background-repeat: no-repeat; +} +section.feature_customers_section a.feature_customer:hover span.mask { + opacity: 1; +} +section.feature_customers_section a.feature_customer:hover span.vcenter { + opacity: 1; +} +section.feature_customers_section a.feature_customer:hover span.icon { + background-image: url(../images/view_icon.png); + background-position: 0 0; +} +section.feature_customers_section a.feature_customer img { + width: auto; + max-width: 100%; + max-height: 100%; + height: auto; + margin: auto; + position: absolute; + cursor: pointer; + left: 0; + top: 0; + right: 0; + bottom: 0; +} +section.quotes_section { + background-color: #5f6a6e; +} +section.quotes_section .quotes_icon{ + background-image: url(../images/quotes_icon.png); + width: 83px; + height: 83px; + margin-bottom: 30px; + background-size: 100%; +} +section.quotes_section p{ + font-size: 30px; + color: #ffffff; + text-align: center; + margin: 0px 50px 30px; + line-height: 1.3; +} +section.quotes_section span{ + text-align: center; + margin: 0 auto; + display: block; + text-transform: uppercase; + color: #fff; + font-size: 16px; + line-height: normal; + margin-bottom: 30px; +} +section.quotes_section span strong{ + letter-spacing: 3px; + display: block; + font-size: 20px; + font-weight: 100; +} +section.quotes_section .quotes_slider ul li { + display:none; +} +section.quotes_section .flex-control-nav { + width: 97%; + position: absolute; + bottom: -25px; + text-align: center; +} +section.quotes_section .flex-control-paging li a { + width: 8px; + height: 8px; + background: #929da1; +} +section.quotes_section .flex-control-paging li a.flex-active { + background: #20cb70; +} +section.quotes_section .flex-control-paging li a:hover { + background: rgba(32, 203, 112, 0.5); +} +section.docker_story_section.blue{ +/*padding-bottom:80px;*/ +} +section.docker_story_section.blue{ +background-color:#0dabd8; +} +section.docker_story_section.green{ +background-color:#88d835; +} +section.docker_story_section h2{ + text-align: center; + color: #fff; + font-size: 52px; + padding: 0; + margin: 0; +} +section.docker_story_section h2 a{ + color: #fff; +} +section.docker_story_section h2 a:hover, section.docker_story_section h2 a:focus, section.docker_story_section h2 a:active, section.docker_story_section h2 a:visited{ + text-decoration: none; +} +section.docker_story_section h2 i{ +padding: 0px 28px; + background-image: url(../images/white_arrow.png); + background-repeat: no-repeat; + background-position: right 10px top 5px; + background-size: 50%; +} +section.banner_section.inside_page{ + min-height: 300px; + width: 100%; + background-repeat: no-repeat; + background-position: center; + background-size: cover; + padding: 30px 0; +} +section.banner_section.inside_page img{ + max-width: 30%; + width: auto; + max-height: 180px; + margin: 0 0 1.25rem; +} +section.banner_section.inside_page p{ + width: 50%; + margin: 0 0 1.25rem; +} + +section.CTA_section{ +/* height: 210px; */ +position: relative; +} +section.CTA_section .container{ +padding: 0; +} +section.CTA_section .CTA_item{ +/* height: 210px; */ +z-index: 2; + /* padding-bottom: 35px; */ +} +.darkblue{ +background-color: #144a68; +} +.lightgreen{ +background-color: #88d835; +} +.lightblue{ +background-color: #2cacd7; +} +section.CTA_section .CTA_item a{ + font-size: 29px; + color: #fff; + text-align: center; + margin: 40px 17%; + display: block; + text-transform: capitalize; +} +section.CTA_section>.background{ +position: absolute; + display: block; + width: 100%; + height: 100%; + top: 0; + z-index: 1; + display: table; +} +section.CTA_section>.background>.darkblue, section.CTA_section>.background>.lightgreen, section.CTA_section>.background>.lightblue{ + width: 50%; + height: 100%; + display: table-cell; +} +.main-footer{ + z-index: 9; +} +section.shopify_section h2{ + font-size: 29px; + font-weight: bold; + color: #2cacd7; +} +section.shopify_section p,section.shopify_section ul{ + color: #243137; +} +@media (max-width:1199px){ +section.feature_customers_section .container .row { + margin-left: -20px; + margin-right: -20px; +} +section.feature_customers_section .container .row .col-sm-4 { + padding-left: 20px; + padding-right: 20px; +} +section.feature_customers_section .feature_customers a.feature_customer { + margin: 20px 0; +} +} +@media (max-width:480px) {.col-xxs-1,.col-xxs-10,.col-xxs-11,.col-xxs-12,.col-xxs-2,.col-xxs-3,.col-xxs-4,.col-xxs-5,.col-xxs-6,.col-xxs-7,.col-xxs-8,.col-xxs-9{float:left;position:relative;min-height:1px;padding-right:15px;padding-left:15px}.col-xxs-12{width:100%}.col-xxs-11{width:91.66666667%}.col-xxs-10{width:83.33333333%}.col-xxs-9{width:75%}.col-xxs-8{width:66.66666667%}.col-xxs-7{width:58.33333333%}.col-xxs-6{width:50%}.col-xxs-5{width:41.66666667%}.col-xxs-4{width:33.33333333%}.col-xxs-3{width:25%}.col-xxs-2{width:16.66666667%}.col-xxs-1{width:8.33333333%}.col-xxs-pull-12{right:100%}.col-xxs-pull-11{right:91.66666667%}.col-xxs-pull-10{right:83.33333333%}.col-xxs-pull-9{right:75%}.col-xxs-pull-8{right:66.66666667%}.col-xxs-pull-7{right:58.33333333%}.col-xxs-pull-6{right:50%}.col-xxs-pull-5{right:41.66666667%}.col-xxs-pull-4{right:33.33333333%}.col-xxs-pull-3{right:25%}.col-xxs-pull-2{right:16.66666667%}.col-xxs-pull-1{right:8.33333333%}.col-xxs-pull-0{right:auto}.col-xxs-push-12{left:100%}.col-xxs-push-11{left:91.66666667%}.col-xxs-push-10{left:83.33333333%}.col-xxs-push-9{left:75%}.col-xxs-push-8{left:66.66666667%}.col-xxs-push-7{left:58.33333333%}.col-xxs-push-6{left:50%}.col-xxs-push-5{left:41.66666667%}.col-xxs-push-4{left:33.33333333%}.col-xxs-push-3{left:25%}.col-xxs-push-2{left:16.66666667%}.col-xxs-push-1{left:8.33333333%}.col-xxs-push-0{left:auto}.col-xxs-offset-12{margin-left:100%}.col-xxs-offset-11{margin-left:91.66666667%}.col-xxs-offset-10{margin-left:83.33333333%}.col-xxs-offset-9{margin-left:75%}.col-xxs-offset-8{margin-left:66.66666667%}.col-xxs-offset-7{margin-left:58.33333333%}.col-xxs-offset-6{margin-left:50%}.col-xxs-offset-5{margin-left:41.66666667%}.col-xxs-offset-4{margin-left:33.33333333%}.col-xxs-offset-3{margin-left:25%}.col-xxs-offset-2{margin-left:16.66666667%}.col-xxs-offset-1{margin-left:8.33333333%}.col-xxs-offset-0{margin-left:0} +} +.mfp-iframe-scaler button:hover, .mfp-iframe-scaler button:focus, .mfp-iframe-scaler .button:hover, .mfp-iframe-scaler .button:focus { + background-color: inherit; +} +@media (max-width:767px) { +section.quotes_section p { + margin: 0px 10px 35px; +} +footer.main-footer {padding: 3rem 0.5rem 2rem 0.5rem;/*footer responsive*/} +section.banner_section.inside_page {background-position: right -279px bottom 0px;} +.video_play { + height: 50px; + width: 50px; + background-size: cover; + margin-left: -26px; + margin-top: -26px; +} + +} +@media (max-width:480px) { +section.banner_section { +display: block; +} +section.banner_section .left-banner, section.banner_section .right-banner { + width: 100%; +display: block; +} +section.banner_section .right-banner { +border: 0; +} +section.banner_section .left-banner { +border: 0; +} + +} +section.content.section { + padding: 50px 0 90px 0; +} + +/*========== END Customers ==========*/ +/*========== Resources ==========*/ +section.nav_section { + text-align: center; + padding: 26px 0 0 0; + background-color: #27b8e8; + height: 70px; +} +section.nav_section ul { + padding: 0; + list-style: none; + margin: 0; +} +section.nav_section ul li { + display: inline-block; + margin: 0 5px; +} +section.nav_section ul li a{ + font-size: 0.9375rem; + font-weight: 100; + color: #fff; + padding: 20px; + background: #1088b1; + border-radius: 5px 5px 0 0; + transition: all 0.3s ease; +} +section.nav_section ul li a:hover{ + background: #084053; + text-decoration: none; +} +section.feature_resources_section{ + padding: 30px 0 100px 0; +} +section.feature_resources_section img.thumbnail_border{ + border: 1px solid #B8B8B8; +} +section.feature_resources_section h2{ + color: #2cacd7; + font-size: 44px; +} +.resources_left_sidebar ul { +padding: 0; +list-style: none; +margin-top: 10px; +} +.resources_left_sidebar ul li { + margin: 6px 0; +} +.resources_left_sidebar ul li a{ + padding: 6px 10px; + font-size: 16px; + color: #2cacd7; + display: block; +} +.resources_left_sidebar ul li a.active{ + text-decoration: none; + background-color: #f1f1f1; + color: #2687ae; +} +.resources_left_sidebar ul li a:hover{ +text-decoration: none; +color: #2687ae; +} +.resources_left_sidebar ul li:hover{ +text-decoration: none; +background-color: #f1f1f1; +} +.resources_page_banner a { + float: right; + color: #fff; + background-color: #2cacd7; + padding: 12px 44px 12px 13px; + border-radius: 5px; + background-image: url(../images/arrow-btn.png); + background-repeat: no-repeat; + background-size: 23px; + background-position: right 10px top 12px; +} +.resources_page_banner p span { + display: block; + max-width: 100%; + font-size: 14px; +} +.resources_page_banner p { +color: #243137; +} +.resources_page_banner { + background-color: #f4f9fa; + border: 1px solid #d7e9f0; + padding: 20px 22px 0px 16px; +} +.resources_page_banner h3 { + margin-bottom: 15px; +} +.resources_link { + margin: 40px 0 0 0; +} +.resources_link a { + font-size: 18px; + font-weight: normal; + line-height: 23px; + display: block; + margin-bottom: 10px; + color: #243137; +} +.resources_link span { + color: #243137; + font-size: 14px; + margin-top: 10px; + display: block; +} +a.resources_play { + height: 55px; + width: 55px; + background-image: url(../images/resources-play-btn.png); + position: absolute; + top: 50%; + left: 50%; + margin: -27px 0 0 -27px; + z-index: 999; +} +.resources_video { + position: relative; +} +.resources_right_sidebar { + display: block; + padding: 15px 20px 20px 5px; + background-color: #38b8e8; + border-radius: 5px; + overflow: hidden; +} +.resources_right_sidebar a { + padding: 15px 10px; + display: block; + color: #fff; + font-size: 16px; +} +.resources_right_sidebar a img { + float: right; + margin: 10px -10px 0 0; +} + +@media (max-width:767px) { +.resources_link { + text-align: center; +} +.resources_link img { +width: 100%; +} +.resources_right_sidebar { + margin-top: 40px; +} +} + + +@media (max-width:480px) { +.resources_page_banner a { + clear: both; + float: none; + margin: 0 auto 7px; + display: block; + max-width: 215px; +} +section.feature_resources_section h2 { +font-size: 34px; +} + +.resources_link img { +width: 90%; +margin: 0 auto; +} +} +.page-taxonomy-term-4949 .region-content .item-list, .page-taxonomy-term-4950 .region-content .item-list, .page-taxonomy-term-4951 .region-content .item-list, .page-taxonomy-term-4952 .region-content .item-list, .page-taxonomy-term-4953 .region-content .item-list, .page-taxonomy-term-4954 .region-content .item-list{ + display: none; +} +.resources_left_sidebar ul { + margin: 0; + margin-top: 10px; +} +.resources_left_sidebar ul li a{ + padding: 6px 0 6px 10px; +} +@media (min-width: 991px) and (max-width: 1199px) { +.resources_left_sidebar ul li a{ + font-size: 14px; +} +} +/*========== Resources ==========*/ +/*========== Career ==========*/ + +.career_section h2{ + font-size: 30px; + color: #555555; + text-transform: capitalize; +} +.career_section .career_video{ + margin: 0 50px; + margin-bottom: 50px; +} +.career_section .career_customers{ +} +.career_section .career_customers ul{ + padding: 0; + list-style: none; + margin: 0; +} +.career_section .career_customers ul li{ + width: 23%; + display: inline-table; + margin: auto; + padding: 0; + margin-left: 1%; + margin-bottom: 10px; +} +.career_section .career_customers p{ + color: #999999; + font-style: italic; + text-align: center; + margin: 0; +} +.career-image{ + background-image: url(../images/career_image.jpg); + background-repeat: no-repeat; + background-position: top center; + display: block; + margin: auto; + height: 350px; + text-align: center; +} +.career_section ul{} +.career_section ul li{ + margin: 20px 0; + line-height: 1.4; +} +.career-mask{ + background-image: url(../images/career_mask.png); + background-size: contain; + background-repeat: no-repeat; + background-position: top center; + display: block; + margin: auto; + height: 150px; +} +section.job_openings_section{ + padding: 30px 0 100px 0; +} +.job_openings_section h2{ + font-size: 30px; + color: #555555; + margin-bottom: 40px; + text-align: center; + text-transform: capitalize; +} +.job_openings_section .row{ + margin-left: -40px; + margin-right: -40px; + width: auto; +} +.job_openings_section .row .col-md-6{ + padding-left: 40px; + padding-right: 40px; + margin-bottom: 40px; +} +.job_openings_section a{ + display: block; + border: 1px solid #979797; + border-radius: 6px; +} +.job_openings_section a:hover{ + text-decoration: none; + border: 1px solid #22b8eb; +} +.job_openings_section a i{ +font-size: 40px; + margin: 20px; + float: left; + color: #999999; +} +.job_openings_section a i.fa.fa-angle-double-right{ + float: right; + display:none; + margin-left: 0; +} +.job_openings_section a:hover i.fa.fa-angle-double-right{ + display:block; +} +.job_openings_section a h3{ + display: block; + font-size: 20px; + color: #555555; + margin: 20px 0px 0 0; + line-height: 28px; + padding-right: 48px; +} +.job_openings_section a:hover h3{ + color: #22b8eb; +} +.job_openings_section a span{ + color: #999999; + font-size: 14px; + margin: 0 0 20px 0; + display: block; +} +@media (max-width:1199px) { +} +@media (max-width:991px) { +.career_section .career_video { + margin: 0; + margin-bottom: 50px; +} +.career-mask{ + background-image: url(../images/career_mask2.png); +} +} +.jobs_section .breadcrumb { + background-color: transparent; + margin: 0; + padding-left: 0; +} +.jobs_section .breadcrumb>li { +font-size: 14px; +} +.jobs_section .breadcrumb>li.active { + color: #555555; + background: transparent; +} +.jobs_section .breadcrumb>li a { + color: #555555; +} +.jobs_section .breadcrumb>li+li:before { + content: "\003e"; +} +.jobs_section .jobs { + margin: 0; + list-style: none; + padding: 30px 0 100px 0; +} +.jobs_section .jobs li { + margin-bottom: 30px; +} +.jobs_section .jobs li a { + font-size: 20px; + color: #22b8eb; + text-decoration: underline; +} +.jobs_section .jobs li span { + display: block; + font-size: 16px; + color: #999999; + line-height: 18px; +} +/*========== Career ==========*/ + +/*========== Footer ==========*/ +body { + padding-bottom: 0 !important; +} +.cta-illustration { + background-position: bottom; +} +.main-footer { + position: relative; +} +.hero::after, .callout::after{ + background-position: bottom; + height: 17px; +} +.main-footer::before{ + height: 17px; + top: -17px; + background-position: bottom; +} +@media (min-width: 2550px){ +body.front .cta-illustration { + padding: 4.6875rem 0 32.125rem 0; +} +} +@media (min-width: 3300px){ +body.front .cta-illustration { + padding: 4.6875rem 0 38.125rem 0; +} +} +.row.collapse{ + display:block; +} +/*========== Footer ==========*/ +/*========== Pricing ==========*/ +section.plans_section { + background-color: #F1F7FD; +} +section.plans_section .plans_tabs { + text-align: center; + margin-bottom: 50px; +} +section.plans_section .plans_tabs ul { + list-style: none; + display: inline-block; + padding: 0; + margin: 0; +} +section.plans_section .plans_tabs ul li { + float: left; + color: #22B8EB; + border: 1px solid #22B8EB; + background-color: #FFF; +} +section.plans_section .plans_tabs ul li:first-child { +border-radius: 6px 0 0 6px; +} +section.plans_section .plans_tabs ul li:last-child { +border-radius: 0 6px 6px 0; +} +section.plans_section .plans_tabs ul li +li { + border-left: none; +} +section.plans_section .plans_tabs ul li a{ + color: #22B8EB; + padding: 10px 50px; + display: block; + text-decoration:none; +} +section.plans_section .plans_tabs ul li.current{ + background-color: #1080A7; +} +section.plans_section .plans_tabs ul li.current a{ + color: #fff; + text-decoration:none; +} + +section.plans_section .row.plans{ + margin-left: -20px; + margin-right: -20px; + text-align: center; +} +section.plans_section .row.plans .col-md-4{ + padding-left: 20px; + padding-right: 20px; +} +section.plans_section .plans .server_plan_box { + background-color: #fff; + border: 1px solid #C4CDDA; + border-radius: 6px; + text-align: center; + padding: 30px; + height: 100%; +} +section.plans_section .plans .server_plan_box .plan_name { + min-height: 110px; + padding: 0 10px; + line-height: normal; +} +section.plans_section .plans .server_plan_box h3 { + font-size: 27px; + color: #147698; +} +section.plans_section .plans .server_plan_box p { + font-size: 14px; + color: #070B10; + line-height: 20px; + margin-bottom: 0; + padding-bottom: 1.25rem; +} +section.plans_section .plans .cloud_plan_box2 p#RepoPricing { + min-height: 23px; + display: block; +} +section.plans_section .plans .server_plan_box p span { + font-size: 38px; +} +section.plans_section .cloudplan_boxs div.col-md-4 p span{ + font-size: 33px; + font-weight: bold; +} +section.plans_section .plans .server_plan_box p span.dollar, section.plans_section .plans .cloud_plan_box2 p span.dollar { + font-size: 27px; + position: relative; + top: -12px; + left: -2px; +} +section.plans_section .plans .server_plan_box .plan_buttons .orange-btn, section.plans_section .plans .cloud_plan_box2 .plan_buttons .orange-btn { +background-color: #fe9a3f; +} +section.plans_section .plans .server_plan_box .plan_buttons .orange-btn:hover,section.plans_section .plans .server_plan_box .plan_buttons .orange-btn:focus, section.plans_section .plans .cloud_plan_box2 .plan_buttons .orange-btn:hover,section.plans_section .plans .cloud_plan_box2 .plan_buttons .orange-btn:focus { +background-color: #F17B00; +} +section.plans_section .plans .server_plan_box .plan_buttons .button, section.plans_section .plans .plan_buttons .button{ + width: 45%; + margin: 0 2%; + padding: 15px 0; +} +section.plans_section .plans .server_plan_box .plan_buttons .button.full-width, section.plans_section .plans .cloud_plan_box2 .plan_buttons .button.full-width{ + width: 98%; + margin: 0; +} +section.plans_section .plans .server_plan_box ul, section.plans_section .plans .cloud_plan_box2 ul{ + list-style: none; + padding: 20px 0; + margin: 0; + margin-top: 20px; +} +section.plans_section .plans .server_plan_box ul { + padding: 20px 10px; +} +section.plans_section .plans .server_plan_box ul li, section.plans_section .plans .cloud_plan_box2 ul li{ + color: #546473; + line-height: 20px; + margin-bottom: 20px; + font-size: 14px; +} + +section.plans_section .cloudplan_boxs .cloud_plan_box2>div{ + margin-top: 20px; +} +section.plans_section .cloudplan_boxs .cloud_plan_box1 div.col-md-4{ + margin-top: 30px; +} +section.plans_section .cloudplan_boxs .cloud_plan_boxs .cloud_plan_box2 ul{ + padding:0; + padding-top: 20px; +} +section.plans_section .cloudplan_boxs .cloud_plan_boxs .cloud_plan_box2 ul li{ + color: #3E4D54; + margin-bottom: 14px; + font-size: 16px; +} +section.plans_section .cloudplan_boxs .plan_buttons{ + margin-top: 30px; +} +section.plans_section .cloudplan_boxs div.col-md-4 p { + font-size: 18px; + color: #24B6E9; /* #232C37; */ + line-height: 16px; + margin-bottom: 12px; +} +section.plans_section .plan_tab_content { display:none; } +section.plans_section .plan_tab_content.current { display:block; } +section.our_customers_section{ + text-align: center; + border-bottom: 2px solid #C4CDDA; +} +section.our_customers_section ul{ + list-style: none; + margin: 0; + padding: 0; + display: table; + width: 100%; + margin-top: 50px; +} +section.our_customers_section ul li{ +display: table-cell; + width: 20%; +} +section.our_customers_section ul li img{ + display: block; + text-align: center; + margin: 0 auto; + height: 80px; +} +section.faqs_section{ + text-align: center; + padding-bottom:10px; +} +section.faqs_section:last-of-type{ + margin-bottom:0px; +} +section.faqs_section .faq { + text-align: left; + padding: 20px 0; + margin: 0 20px; + border-bottom: 1px solid #C4CDDA; +} + +section.faqs_section .faq .clickme { + position: absolute; + right: 40px; + display: inline-block; + font: normal normal normal 14px/1 FontAwesome; + font-size: inherit; + text-rendering: auto; + -webkit-font-smoothing: antialiased; + -moz-osx-font-smoothing: grayscale; + font-size: 20px; + color: #C4CDDA; +} +section.faqs_section .faq .clickme:before { + content: "\f067"; +} +section.faqs_section .faq.active .clickme:before { + content: "\f068"; +} +section.faqs_section .faq.active .clickme { + background-position: -16px 0px; +} +section.faqs_section .faq h3{ + color: #232C37; + font-size: 14px; + font-weight: bold; + margin: 0; + margin-right: 50px; +} + +section.faqs_section .faq .faq-title { +cursor: pointer; +} +section.faqs_section .faq .faq-title:hover , +section.faqs_section .faq .faq-title:hover h3, +section.faqs_section .faq .faq-title:hover .clickme { +color: #137597; +} +section.faqs_section .faq .faq-body { + display:none; + padding: 20px 40px 0px 0; +} +section.faqs_section .faq .faq-body p { +margin-bottom:0px; +} +section.plans_section .cloud_plan_boxs{ + background-color: #fff; + border: 1px solid #C4CDDA; + border-radius: 6px; + height: 100%; + float: none; + display: inline-block; + padding-left: 30px; + padding-right: 30px; +} +.cloud_plan_box1, .cloud_plan_box2{ + width: 100%!important; + display: inline-block; + margin: 0!important; + padding: 40px 0 30px 0; +} +section.plans_section .cloud_plan_boxs h4 { + color: #3E4D54; + font-size: 18px; + font-weight: bold; + margin-bottom: 20px; +} +section.plans_section .cloud_plan_boxs .cloud_plan_box2 h4 { + margin-bottom: 50px; +} +section.plans_section .cloud_plan_boxs .cloud_plan_box1{ + border-bottom: 1px solid #3E4D54; +} +section.plans_section .cloud_plan_boxs .cloud_plan_box1 ul.info{ + list-style: none; + padding: 0; + margin: 0; + margin-bottom: 35px; +} +section.plans_section .cloud_plan_boxs .cloud_plan_box1 ul.info li{ + color: #3E4D54; + font-size: 17px; + line-height: 24px; + margin-bottom: 30px; + position: relative; + margin-left: 20px; +} +section.plans_section .cloud_plan_boxs .cloud_plan_box1 ul.info li:before { + content: "• "; + color: #24B6E9; + margin-right: 10px; + position: absolute; + left: -20px; +} +section.plans_section .cloud_plan_boxs .cloud_plan_box2{ + +} +.ui-widget { + font-family: "Helvetica Neue",Helvetica,Roboto,Arial,sans-serif; +} +#RepoSlider.ui-state-disabled { + opacity: 1; +} +.RepoSliderContainer { + background-color: #C4CDDA; + border-radius: 10px; + border-color: #C4CDDA; + max-width: 500px; + padding-left: 6px; + padding-right: 6px; + margin-bottom: 85px; +} +#RepoSlider { + background: #fff; +} +#RepoSlider.ui-slider-horizontal.ui-slider-pips { + background-color: #C4CDDA; + border-radius: 10px; + border-color: #C4CDDA; + max-width: 500px; +} +#RepoSlider .ui-state-active, #RepoSlider.ui-widget-content .ui-state-active, +#RepoSlider .ui-state-default, #RepoSlider.ui-widget-content .ui-state-default { + border: 0px !important; + outline: none !important; + background-position: top center; + background-size: 95%; + background-image: url("../images/sliderhandle-wshadow.png"); + background-repeat: no-repeat; + background-color: transparent; + width: 32px; + height: 37px; + top: -12px; + margin-left: -16px; +} + +#RepoSlider .ui-state-default, #RepoSlider.ui-widget-content .ui-state-default { + cursor: move; /* fallback if grab cursor is unsupported */ + cursor: grab; + cursor: -moz-grab; + cursor: -webkit-grab; +} +#RepoSlider.ui-slider-horizontal.ui-slider-pips:active, +#RepoSlider .ui-state-active, #RepoSlider.ui-widget-content .ui-state-active { + cursor: grabbing; + cursor: -moz-grabbing; + cursor: -webkit-grabbing; +} + +#RepoSlider.ui-slider-pips .ui-slider-pip { + top: 24px; + color: #7A8491; + font-weight: normal; + font-size: 10px; +} +#RepoSlider.ui-slider-pips .ui-slider-pip-selected .ui-slider-line, +#RepoSlider.ui-slider-pips .ui-slider-line { + height: 7px; + width: 2px; + margin-left: -1px; + background: #7A8491; +} + +#RepoSlider.ui-slider-pips .ui-slider-label { + top: 8px; + color: inherit; +} + + +#RepoSlider.ui-slider-pips [class*=ui-slider-pip-selected] { + color: #232C37; + font-weight: normal; + font-size: 27px; +} +#RepoSlider.ui-slider-pips .ui-slider-pip-selected .ui-slider-label { + color: #232C37; +} +#RepoSlider.ui-slider-pips:not(.ui-slider-disabled) .ui-slider-pip:hover .ui-slider-label { + font-weight: normal; +} + + +.support-checkboxs .checkbox { + overflow: hidden; + margin-bottom: 20px; +} +.support-checkboxs .checkbox label { + padding-left: 35px; + font-size: 14px; + color: #22B8EB; +} +.support-checkboxs input[type="checkbox"]{ + width: 0px; + height: 0px; + margin: 0px; + -webkit-appearance: none; +} +.support-checkboxs input[type="checkbox"] + i { + display: inline-block; + width: 25px; + height: 25px; + left: 0; + top: 2px; + position: absolute; + border: 2px solid #C4CDDA; + border-radius: 5px; + font: normal normal normal 14px/1 FontAwesome; + font-size: inherit; + text-rendering: auto; + -webkit-font-smoothing: antialiased; + -moz-osx-font-smoothing: grayscale; + color: #FFF; + font-size: 16px; + padding: 2px; +} +.support-checkboxs input[type="checkbox"]:checked + i:before { + content: "\f00c"; +} +.support-checkboxs input[type="checkbox"]:checked + i { + background-color:#22B8EB; +} +.cloud_plan_box1 .info-text { + color: #232C37; + margin-top: 145px; + font-size: 14px; +} +.cloud_plan_box1 .info-text a { + color:#22B8EB; +} +.cloud_plan_box1 .has-tip { + color: #C4CDDA; + margin-left: 5px; + border-bottom: none; +} +.tooltip { + opacity: 1; +} +.path-pricing .title_section.hero_section { + padding: 26px 0 22px 0; +} +.path-pricing .region.region-hero-sub .nav-sub, +.region.region-hero-sub .nav-sub .pricing-menu-item , +.region.region-hero-sub .nav-sub .removetab-menu-item{ + display:none; +} +.path-enterprise .region.region-hero-sub .nav-sub{ + display:none; +} +@media (max-width: 940px){ +section.plans_section .plans .server_plan_box .plan_buttons .button, section.plans_section .plans .plan_buttons .button { + width: 46%; + margin: 0 1%; +} +section.plans_section .plans .server_plan_box { + padding: 30px 10px; +} +} +@media (max-width: 767px){ +section.plans_section .plans .server_plan_box{ + margin-bottom: 20px; +} +section.plans_section .plans .server_plan_box .plan_buttons .button, section.plans_section .plans .plan_buttons .button { + width: 42%; + margin: 0 2%; +} +.cloud_plan_box1 .info-text { + margin-top: 25px; +} +} +@media (max-width: 600px){ +section.our_customers_section ul { + display: block; +} +section.our_customers_section ul li { + width: 50%; + float: left; + display: block; + margin-bottom: 21px; +} +} +@media (max-width: 320px){ +section.our_customers_section ul li { + width: 100%; +} +} +/*========== End Pricing ==========*/ +/*========== Product ==========*/ +.backproduct_link{ + background-image: url(../images/backproduct_icon.png); + background-repeat: no-repeat; + background-position: left center; + color: #05b7ed; + padding-left: 20px; +} +.backproduct_link:focus, .backproduct_link:hover , .backproduct_link:active{ + color: #05b7ed; + +} +.region.region-sidebar .heading_product{ + background-color: #fff; + color: #000; + cursor: context-menu; + font-weight:bold; +} +.region.region-sidebar .heading_product a{ + color: #000; + transition: none; + margin: 0; + padding: 0; + text-decoration: none; + cursor: context-menu; +} +.region.region-sidebar .side-nav li.heading_product a:not(.button):hover,.region.region-sidebar .side-nav li.heading_product a:not(.button):active,.region.region-sidebar .side-nav li.heading_product a:not(.button):focus{ + background: rgba(241, 241, 241, 0); + padding: 0; + color: #000; + cursor: context-menu; +} +.node-type-product .page-content article img { + margin-bottom: 20px; + max-width: 100%; + height: auto !important; +} +.terminal .terminal-data{ + word-wrap: break-word; +} +.node-type-product .page-content .row .columns .columns + hr { + float: left; + width: 100%; +} +.node-type-product .page-content .row .columns hr.noborder { + margin: 20px; + background-color: rgba(221, 221, 221, 0); +} +.node-type-product .row.cta_section { + overflow: hidden; + float: left; + width: 100%; +} +.cta_section .orange_bottom_link{ + text-align:center; +} +@media (max-width: 1150px){ +.node-type-product article iframe{ + width: 100%; + height: 300px; +} +} +@media (min-width: 767px) and (max-width: 1150px){ +.node-type-product ul.product-features li iframe{ + width: 100%; +} +.node-type-product .page-content article img { + width: 100% !important; +} +} +@media (max-width: 767px){ +.node-type-product ul.product-features li { + width: 100%; +} +} +@media (max-width: 480px){ +.node-type-product ul.product-features li iframe{ + width: 100%; +} +} +.cta_section .medium-12 { + padding: 0 15px; +} +.cta_section .medium-6 { + width: 50%; + float: left; + padding: 0 15px; +} +@media only screen and (max-width: 40.0625em){ +.cta_section .medium-6 { + width: 100%; + float:none; +} +} + +.cta_section .medium-6 .button, .cta_section .medium-12 .button { + width: 100%; + border: 2px solid #22b8eb; +} +.cta_section .medium-6 .button.white-btn, .cta_section .medium-12 .button.white-btn { + width: 100%; + background-color: #fff; + color: #22b8eb; +} +.cta_section .medium-6 .button.white-btn:hover, .cta_section .medium-6 .button.white-btn:focus { + background-color: rgba(245, 252, 255, 0.59); +} +/*========== Product ==========*/ +/*========== IBM Page ==========*/ +section.ibm_description_section { + padding-bottom: 0; +} +section.ibm_description_section .row { + margin-left: -15px; + margin-right: -15px; + width: auto; +} +section.ibm_description_section .row + .row{ + margin-top: 25px; +} +section.ibm_description_section img{ + margin-bottom: 20px; +} +section.ibm_description_section h2{ + font-size: 50px; + color: #2cacd7; + margin-bottom: 30px; +} +section.ibm_description_section p{ + font-size: 16px; + color: #7a8491; + margin-bottom: 30px; +} +section.ibm_description_section .button.full-width{ + width: 100%; + margin-top: 10px; +} +section.ibm_description_section p a{ + color: #27b7e8; +} +section.ibm_description_section p a:hover, section.ibm_subscription_section p a:focus{ + color: #27b7e8; +} +section.ibm_description_section ul li{ + padding-left: 20px; +} +section.ibm_description_section ul li + li{ + margin-top: 20px; +} +section.ibm_description_section ul li span{ + color:#27b7e8; +} + +section.ibm_subscription_section { + padding-top: 0; +} +section.ibm_subscription_section .row { + margin-left: -15px; + margin-right: -15px; + width: auto; +} +section.ibm_subscription_section .row + .row{ + margin-top: 50px; +} +section.ibm_subscription_section h2{ + font-size: 29px; + color: #2cacd7; + margin-bottom: 30px; +} +section.ibm_subscription_section p{ + color: #3f5166; +} +section.ibm_subscription_section ul{ + color: #3f5166; +} +section.ibm_subscription_section ul li{ + padding-left: 20px; +} +section.ibm_subscription_section .button.full-width{ + width: 100%; + margin-top: 10px; +} +section.ibm_subscription_section p a{ + color: #27b7e8; +} +section.ibm_subscription_section p a:hover, section.ibm_subscription_section p a:focus{ + color: #27b7e8; +} +.video_iframe{ +} +.video_iframe iframe{ +max-width: 100%; +} +section.ibm_customers_section{ +} +section.ibm_customers_section h2{ + font-size: 29px; + color: #2cacd7; + margin-bottom: 30px; +} +section.ibm_customers_section ul{ + list-style: none; + margin: 0; + padding: 0; + display: table; + width: 100%; + margin-top: 50px; +} +section.ibm_customers_section ul li{ +display: table-cell; + width: 25%; +} +section.ibm_customers_section ul li img{ + display: block; + text-align: center; + margin: 0 auto; + height: 90px; +} +section.ibm_solution_overview_section { + padding-top: 10px; +} +section.ibm_solution_overview_section h2{ + font-size: 29px; + color: #2cacd7; + margin-bottom: 30px; +} +section.ibm_solution_overview_section .ibm_solutions{ + margin-left: -15px; + margin-right: -15px; + width: auto; +} +section.ibm_solution_overview_section .ibm_solution .title { + text-align: center; + background-color: #27b7e8; + padding: 20px 38px; +} +section.ibm_solution_overview_section .ibm_solution .title h3{ + color: #fff; +} +section.ibm_solution_overview_section .ibm_solution .body { + background-color: #ebebeb; + padding-bottom: 50px; + margin-top: 4px; +} +section.ibm_solution_overview_section .ibm_solution .body h4 { + color: #2cacd7; + text-align: center; + font-size: 25px; + border-bottom: 1px solid #fff; + margin: 0 32px; + padding: 15px 0; +} +section.ibm_solution_overview_section .ibm_solution .body ul { + margin-left: 44px; + margin-right: 25px; + margin-top: 15px; + display: block; +} +section.ibm_solution_overview_section .ibm_solution .body ul li { + color: #7a8491; + font-size: 16px; + padding-left: 12px; +} +section.ibm_video_section{ + padding-top: 10px; +} +section.ibm_video_section h2{ + font-size: 29px; + color: #2cacd7; + margin-bottom: 30px; +} +section.ibm_video_section .ibm_videos{ + list-style: none; + clear: both; + overflow: overlay; + padding: 0; + margin: 0; + margin-bottom: 25px; + margin-right: -50px; +} +section.ibm_video_section .ibm_videos li{ + float: left; + margin-right: 50px; + margin-bottom: 20px; + width: 280px; +} +section.ibm_video_section .ibm_videos li a:hover, section.ibm_video_section .ibm_videos li a:focus{ + color: inherit; + text-decoration: none; +} +section.ibm_video_section .ibm_videos li img{ +} +section.ibm_video_section .ibm_videos li span{ + font-size: 16px; + color: #7a8491; + line-height: 20px; + padding: 8px 0; + display: block; +} +.ibm_additional_resources{ + margin-left: -15px; + margin-right: -15px; + width:auto; +} +.ibm_additional_resources ul{ + list-style: none; + padding: 0; + margin: 0; +} +.ibm_additional_resources ul li{ + font-size: 16px; + color: #27b7e8; + line-height: 18px; + margin-bottom: 18px; +} +.ibm_additional_resources ul li a{ + font-size: 16px; + color: #27b7e8; +} +.ibm_additional_resources ul li a:hover, .ibm_additional_resources ul li a:focus{ + color: inherit; + text-decoration: none; +} +section.ibm_faqs_section{ + padding-top: 10px; +} +section.ibm_faqs_section .row { + margin-left: -15px; + margin-right: -15px; + width:auto; +} +section.ibm_faqs_section h2{ + font-size: 29px; + color: #2cacd7; + margin-bottom: 30px; +} +section.ibm_faqs_section .faq { + text-align: left; + margin: 0; + border: 1px solid #e5e5e5; + margin-bottom: 10px; +} + +section.ibm_faqs_section .faq .clickme { + position: absolute; + left: 22px; + display: inline-block; + font: normal normal normal 14px/1 FontAwesome; + font-size: inherit; + text-rendering: auto; + -webkit-font-smoothing: antialiased; + -moz-osx-font-smoothing: grayscale; + font-size: 16px; + color: #27b7e8; + font-weight: lighter; +} +section.ibm_faqs_section .faq .clickme:before { + content: "\f067"; +} +section.ibm_faqs_section .faq.active .clickme:before { + content: "\f068"; +} +section.ibm_faqs_section .faq h3{ + color: #27b7e8; + font-size: 14px; + margin: 0; + margin-left: 50px; +} +section.ibm_faqs_section .faq .faq-title { + cursor: pointer; + background-color: #ebebeb; + padding: 20px 0; + padding-right: 20px; + position: relative; +} +section.ibm_faqs_section .faq .faq-body { + display:none; + margin-left: 30px; + padding: 20px; +} +section.ibm_faqs_section .faq .faq-body p { + margin-bottom: 10px; + font-size: 15px; + color: #7a8491; +} + +section.ibm_questions_section { + background-color: #0dabd8; + text-align: center; +} +section.ibm_questions_section h2 { + font-size: 29px; + color: #fff; + font-weight: bold; + margin-bottom: 15px; +} +section.ibm_questions_section .button { + display: block; + max-width: 276px; + margin: 18px auto; +} +section.ibm_questions_section .orange-btn{ +background-color: #fe9a3f; +} +section.ibm_questions_section .orange-btn:focus, section.ibm_questions_section .orange-btn:hover{ +background-color: #F17B00; +} + +@media (max-width:991px){ +section.ibm_description_section h2 { + font-size: 45px; + margin: 0; + line-height: 48px; +} +} +@media (max-width:767px){ +section.ibm_solution_overview_section .ibm_solution{ + margin-bottom: 30px; +} +} +@media (max-width: 600px){ +section.ibm_customers_section ul { + display: block; +} +section.ibm_customers_section ul li { + width: 50%; + float: left; + display: block; + margin-bottom: 21px; +} +} +@media (max-width: 320px){ +section.ibm_customers_section ul li { + width: 100%; +} +} +/*========== END IBM Page ==========*/ +/*========== Events ==========*/ +section.title_section.hero_section{ + padding-bottom: 0; +} +.featured_events_section{ + padding-bottom: 30px; + border-bottom: 1px solid #d8dbdc; +} +.featured_events_section a,.events_section a{ + color: #27b8e8; + font-weight:normal; +} +.featured_events_section h2, .events_region h2{ + font-size: 17px; + color: #FF992E; + text-transform: uppercase; + font-weight:bold; +} + +.featured_events_item { + margin: 28px 0; + margin-right: 40px; +} +.featured_events_item .featured_events_thumbnail,.events_item .events_thumbnail { + padding-right: 20px; + padding-top: 6px; +} +.featured_events_item .featured_events_thumbnail a img ,.events_item .events_thumbnail a img { + max-width: 135px; + height: auto; + border: 1px solid #C1C1C1; +} +.featured_events_item h3 , .events_item h3{ + font-size: 17px; + color: #27b8e8; + font-weight:bold; + margin: 0; +} +.featured_events_item p ,.events_item p{ + font-size: 15px; + color: #39576a; + margin:0; + margin-top: 12px; +} +.featured_events_item span, .events_item span { + font-size: 15px; + color: #39576a; + font-weight:normal; +} +.events_section .events_region, .events_region h2 { + margin-bottom: 30px; +} +.events_section .events_item { + margin-bottom: 30px; +} +.event-search{ + padding: 0; + padding-top: 15px; +} +.events_section .row .row { + margin: 0; +} +.events_section .events_region .events_region_name { + display:block; +} +.events_section .events_regions.margintop55 { + margin-top: 42px; +} +.events_section .events_regions.margintop55 .events_region { + margin-top: -42px; +} + +/*========== Events ==========*/ +/*========== Main Page ==========*/ +body.front .cta-illustration { + margin-top: 0; +} +.page-node-1 section#docker-solution,.page-node-1 section.why-docker { + padding-top: 60px; + padding-bottom: 60px; + text-align: center; + -webkit-font-smoothing: antialiased; +} +.page-node-1 section#docker-solution h2{ + font-size: 44px; +} +.page-node-1 section.why-docker h2 { + font-size: 44px; +} +#docker-solution h1, #docker-solution h2{ + margin-bottom: 25px; +} +.page-node-1 section.why-docker h1, .page-node-1 section.why-docker h2 { + margin-bottom: 25px; +} +.docker-solution p{ + font-size: 20px; +} +.page-node-1 section.why-docker p { + font-size: 20px; +} +.page-node-1 section#docker-solution.dark-blue { + background-color: #134a6a; +} +.page-node-1 section#docker-solution.dark-blue h2, .page-node-1 section#docker-solution.dark-blue p { + color: #dde7f7; +} +.page-node-1 .why-docker img, .page-node-1 .why-docker h3 { + margin-bottom: 15px; +} +.page-node-1 .why-docker img, .page-node-1 .why-docker h3 { + margin-bottom: 15px; +} +.page-node-1 .why-docker .reason p, .page-node-1 .features .feature p, .page-node-1 .services p { + font-size: 16px !important; +} +.page-node-1 .why-docker .footer .button { + margin-top: 50px; +} +.page-node-1 .docker-solution .feature { + text-align: left; + margin-bottom: 50px; +} +.page-node-1 .docker-solution .graphic { + text-align: center; + margin-bottom: 1.25rem; +} +.page-node-1 .docker-solution h3 { + line-height: 1; + margin-top: 0px; + margin-bottom: 1.25rem; +} +.page-node-1 .why-docker .reason p, .page-node-1 .features .feature p, .page-node-1 .services p { + font-size: 16px; +} +.page-node-1 .docker-solution .button+.button { + margin-left: 30px; +} +@media (min-width:1500px){ +.page-node-1 .hero.loaded { + width: 100%; + left: -600px; + padding-left: 600px !important; + background-position: bottom center !important; + -webkit-box-sizing: content-box; + -moz-box-sizing: content-box; + box-sizing: content-box; +} +} +/*========== End Main Page ==========*/ +/*========== Main Nav ==========*/ +.main-header { + padding-bottom: 0; +} +.main-header div>.nav-main a{ + padding-bottom: 12px; +} +.main-header div>.nav-main>li.octopus-navstyle{ + +} +.main-header div>.nav-main>li.octopus-navstyle>ul{ + background-color: #363f44; + width: 570px; + padding: 30px; + border: none; + border-radius: 0; + border-bottom-left-radius: 8px; + border-bottom-right-radius: 8px; + background-position: right 30px bottom 30px; + background-repeat: no-repeat; + left: -50px; + background-image: none; +} +.main-header div>.nav-main>li.octopus-navstyle:hover>ul{ + background-image: url(../images/octopus_productpage_icon.gif); +} +.main-header div>.nav-main>li.octopus-navstyle.new-navstyle>ul{ + background-image: none; + width: initial; +} +.main-header div>.nav-main>li.octopus-navstyle.new-navstyle>ul>li{ +} +.main-header div>.nav-main>li.octopus-navstyle:hover>ul:before { + content: ""; + position: absolute; + left: 80px; + top: 0; + border: 11px solid transparent; + border-top-width: 11px; + border-top-color: #fff; + border-bottom: 0; +} +.main-header div>.nav-main>li.octopus-navstyle>ul>li{ + width: 215px; + display: inline-block; + margin: 10px 10px; +} +.main-header div>.nav-main>li.octopus-navstyle.new-navstyle >ul>li{ + width: 155px; + margin: 3px 10px; +} +.main-header div>.nav-main>li.octopus-navstyle ul li:first-child { + display: inherit; +} +.main-header div>.nav-main>li.octopus-navstyle>ul>li:first-child { + display: none; +} +.left-submenu li.heading_product { + display: none; +} +.main-header div>.nav-main>li.octopus-navstyle>ul li.navleft{ + float: left; + clear: left; + width: 235px; +} +.main-header div>.nav-main>li.octopus-navstyle>ul>li>a{ + background: transparent; + color: #fff; + font-size: 18px; + border: none; + line-height: 22px; +} +.main-header div>.nav-main>li.octopus-navstyle.new-navstyle>ul>li>a{ + font-size: 16px; +} +.main-header div>.nav-main>li.octopus-navstyle.new-navstyle>ul>li>a:hover { + color: #22b8eb; +} +.main-header div>.nav-main>li.octopus-navstyle>ul ul{ + position: relative; + display: block; + float: none; + border: none; +} +.main-header div>.nav-main>li.octopus-navstyle>ul ul a{ + border: none; + background: transparent; + font-size: 16px; + color: #57b5e5; + line-height: 18px; + padding: 4px 8px; +} +/*========== Main Nav ==========*/ +/*========== products ==========*/ +.widthcol1>li{width: 100%;} +.widthcol2>li{width: 50%;} +.widthcol3>li{width: 33.33%;} +.widthcol4>li{width: 25%;} +.widthcol5>li{width: 20%;} +.node-type-use-cases section.section, .node-type-use-case section.section { + padding: 60px 0 60px 0; +} +.node-type-use-cases section a,.node-type-use-case section a { + color: inherit; + line-height: inherit; + text-decoration: none; +} +.node-type-use-cases section a:hover,.node-type-use-cases section a:focus,.node-type-use-case section a:hover,.node-type-use-case section a:focus { + color: inherit; +} +.node-type-use-cases a.button,.node-type-use-case a.button { + font-size: 17px; + border-radius: 10px; + color: #ffffff; + margin-left: 20px; + margin-right: 20px; + padding: 14px 35px; +} +.node-type-use-cases .button:hover, .node-type-use-cases .button:focus , .node-type-use-case .button:hover, .node-type-use-case .button:focus { + color: #ffffff; +} +.node-type-use-cases .orange-btn, .node-type-use-case .orange-btn{ +background-color: #FF992E; +color:#fff; +} +.node-type-use-cases .orange-btn:focus, .node-type-use-cases .orange-btn:hover, .node-type-use-case .orange-btn:focus, .node-type-use-case .orange-btn:hover{ +background-color: #f17b00; +} +.node-type-use-cases .blue-btn, .node-type-use-case .blue-btn{ +background-color: #22B8EB; +color:#dde7f7; +} +.node-type-use-cases .blue-btn:focus, .node-type-use-cases .blue-btn:hover, .node-type-use-case .blue-btn:focus, .node-type-use-case .blue-btn:hover{ +background-color: #1497C3; +} +.node-type-use-cases section h1, .node-type-use-case section h1{ + font-size: 44px; +} +.node-type-use-cases section h2, .node-type-use-case section h2{ + color: #22B8EB; + font-size: 44px; + line-height: 50px; + margin-bottom: 20px; +} +.node-type-use-cases section .container p, .node-type-use-case section .container p{ + color: #808284; +} +.node-type-use-cases section .container>p, .node-type-use-case section .container>p{ + font-size: 20px; + line-height: 29px; + margin-bottom: 50px; + color: #808284; +} +/* ============ node-type-government ============ */ +.node-type-government section.section { + padding: 60px 0 60px 0; +} +.node-type-government section a { + color: inherit; + line-height: inherit; + text-decoration: none; +} +.node-type-government section a:hover,.node-type-government section a:focus { + color: inherit; +} +.node-type-government a.button { + font-size: 17px; + border-radius: 10px; + color: #ffffff; + margin-left: 20px; + margin-right: 20px; + padding: 14px 35px; +} +.node-type-government .button:hover, .node-type-government .button:focus { + color: #ffffff; +} +.node-type-government .orange-btn{ +background-color: #FF992E; +color:#fff; +} +.node-type-government .orange-btn:focus, .node-type-government .orange-btn:hover{ +/*background-color: #f29c3a;*/ +background-color: #f17b00; +} +.node-type-government .blue-btn{ +background-color: #22B8EB; +color:#dde7f7; +} +.node-type-government .blue-btn:focus, .node-type-government .blue-btn:hover{ +background-color: #1497C3; +} +.node-type-government section h1{ + font-size: 44px; +} +.node-type-government section h2{ + color: #22B8EB; + font-size: 44px; + line-height: 50px; + margin-bottom: 20px; +} +.node-type-government section .container p{ + color: #808284; +} +.node-type-government section .container>p{ + font-size: 20px; + line-height: 29px; + margin-bottom: 50px; + color: #808284; +} +/* ============ End node-type-government ============ */ +/* ============ node-type-partners ============ */ +.node-type-partners section.section { + padding: 50px 0 50px 0; +} +.node-type-partners section a { + color: inherit; + line-height: inherit; + text-decoration: none; +} +.node-type-partners section a:hover,.node-type-partners section a:focus { + color: inherit; +} +.node-type-partners a.button { + font-size: 17px; + border-radius: 10px; + color: #ffffff; + margin-left: 20px; + margin-right: 20px; + padding: 14px 35px; +} +.node-type-partners .button:hover, .node-type-partners .button:focus { + color: #ffffff; +} +.node-type-partners .orange-btn{ +background-color: #FF992E; +color:#fff; +} +.node-type-partners .orange-btn:focus, .node-type-partners .orange-btn:hover{ +/*background-color: #f29c3a;*/ +background-color: #f17b00; +} +.node-type-partners .blue-btn{ +background-color: #22B8EB; +color:#dde7f7; +} +.node-type-partners .blue-btn:focus, .node-type-partners .blue-btn:hover{ +background-color: #1497C3; +} +.node-type-partners section h1{ + font-size: 44px; +} +.node-type-partners section h2{ + color: #22B8EB; + font-size: 44px; + line-height: 50px; + margin-bottom: 20px; +} +.node-type-partners section .container p{ + color: #808284; +} +.node-type-partners section .container>p{ + font-size: 20px; + line-height: 29px; + margin-bottom: 50px; + color: #808284; +} +/* ============ End node-type-partners ============ */ +/* ============ node-type-partner-programs ============ */ +.node-type-partner-programs section.section { + padding: 60px 0 60px 0; +} +.node-type-partner-programs section a { + color: inherit; + line-height: inherit; + text-decoration: none; +} +.node-type-partner-programs section a:hover,.node-type-partner-programs section a:focus { + color: inherit; +} +.node-type-partner-programs a.button { + font-size: 17px; + border-radius: 10px; + color: #ffffff; + margin-left: 20px; + margin-right: 20px; + padding: 14px 35px; + +} +.node-type-partner-programs .button:hover, .node-type-partner-programs .button:focus { + color: #ffffff; +} +.node-type-partner-programs .orange-btn{ +background-color: #FF992E; +color:#fff; +} +.node-type-partner-programs .orange-btn:focus, .node-type-partner-programs .orange-btn:hover{ +/*background-color: #f29c3a;*/ +background-color: #f17b00; +} +.node-type-partner-programs .blue-btn{ +background-color: #22B8EB; +color:#dde7f7; +} +.node-type-partner-programs .blue-btn:focus, .node-type-partner-programs .blue-btn:hover{ +background-color: #1497C3; +} +.node-type-partner-programs section h1{ + font-size: 44px; +} +.node-type-partner-programs section h2{ + color: #22B8EB; + font-size: 44px; + line-height: 50px; + margin-bottom: 20px; +} +.node-type-partner-programs section .container p{ + color: #808284; +} +.node-type-partner-programs section .container>p{ + font-size: 20px; + line-height: 29px; + margin-bottom: 50px; + color: #808284; +} +/* ============ End node-type-partner-programs ============ */ +.node-type-products section.section , .node-type-product section.section{ + padding: 60px 0 60px 0; +} +.node-type-products section a,.node-type-product section a { + color: inherit; + line-height: inherit; + text-decoration: none; +} +.node-type-products section a:hover,.node-type-products section a:focus ,.node-type-product section a:hover,.node-type-product section a:focus{ + color: inherit; +} +.node-type-products a.button ,.node-type-product a.button{ + font-size: 17px; + border-radius: 10px; + color: #ffffff; + margin-left: 20px; + margin-right: 20px; + padding: 14px 35px; +} +.node-type-products .button:hover, .node-type-products .button:focus , .node-type-product .button:hover, .node-type-product .button:focus { + color: #ffffff; +} +.node-type-products .orange-btn, .node-type-product .orange-btn{ +background-color: #FF992E; +color:#fff; +} +.node-type-products .orange-btn:focus, .node-type-products .orange-btn:hover, .node-type-product .orange-btn:focus, .node-type-product .orange-btn:hover{ +background-color: #f29c3a; +background-color: #f17b00; +} +.node-type-products .blue-btn, .node-type-product .blue-btn{ +background-color: #22B8EB; +color:#dde7f7; +} +.node-type-products .blue-btn:focus, .node-type-products .blue-btn:hover, .node-type-product .blue-btn:focus, .node-type-product .blue-btn:hover{ +background-color: #1497C3; +} +.node-type-products section h1, .node-type-product section h1{ + font-size: 44px; +} +.node-type-products section h2, .node-type-product section h2{ + color: #22B8EB; + font-size: 44px; + line-height: 50px; + margin-bottom: 20px; +} +.node-type-products section .container p, .node-type-product section .container p { + color: #808284; +} +.node-type-products section .container>p, .node-type-product section .container>p{ + font-size: 20px; + line-height: 29px; + margin-bottom: 50px; + color: #808284; +} +.max-width500{ + max-width: 500px; + margin: auto; +} +.max-width600{ + max-width: 600px; + margin: auto; +} +.max-width700{ + max-width: 700px; + margin: auto; +} +.max-width800{ + max-width: 800px; + margin: auto; +} +.max-width900{ + max-width: 900px; + margin: auto; +} +.max-width1000{ + max-width: 900px; + margin: auto; +} +.textalign-left{ +text-align:left; +} +.textalign-right{ +text-align:right; +} +.terminal-window header .btn { + margin: 2px 4px 0 0; +} +i.icon-apple{ + background-image: url(../images/apple_button_icon.svg); + background-repeat: no-repeat; + background-size: 22px 27px; + width: 22px; + height: 27px; + position: relative; + display: inline-block; + float: left; + margin-right: 25px; + margin-left: -10px; + margin-top: -2px; +} +i.icon-win{ + background-image: url(../images/win_button_icon.svg); + background-repeat: no-repeat; + background-size: 26px 30px; + width: 26px; + height: 30px; + position: relative; + display: inline-block; + float: left; + margin-right: 25px; + margin-left: -10px; + margin-top: -2px; +} +i.icon-file{ + background-image: url(../images/file_button_icon.svg); + background-repeat: no-repeat; + background-size: 22px 28px; + width: 22px; + height: 28px; + position: relative; + display: inline-block; + float: right; + margin-left: 20px; + margin-right: -10px; + margin-top: -2px; +} +div.heronav_section{ + height: 70px; + background-color: #3e4d54; + position:relative; + top: 0; + width: 100%; +} +div.heronav_section.affix{ + position: fixed; + z-index: 9999; +} +div.heronav_section.affix+section{ +margin-top:70px; +} +div.heronav_section .container{ +/* display: table; + table-layout: fixed; */ +} +div.heronav_section ul{ + list-style: none; + margin: 0; + display: table; + flex-direction: row; + display: -webkit-box; /* OLD - iOS 6-, Safari 3.1-6 */ + display: -moz-box; /* OLD - Firefox 19- (buggy but mostly works) */ + display: -ms-flexbox; /* TWEENER - IE 10 */ + display: -webkit-flex; /* NEW - Chrome */ + display: flex; /* NEW, Spec - Opera 12.1, Firefox 20+ */ +} +div.heronav_section ul li{ + display: inline-block; + font-size: 17px; + color: #fff; + text-transform: uppercase; + margin: 5px 3px; + flex-grow: 1; + text-align: center; +} +div.heronav_section ul li a{ + color: #fff; + display: block; + padding: 12px; + padding-left: 30px; + padding-right: 30px; + text-decoration: none; +} +div.heronav_section ul li.active{ + background-color: #55b6e9; +} +div.heronav_section ul li:hover{ + background-color: #55b6e9; +} +section.darkblue{ + background-color: #243137; + margin-bottom: 0px; + padding: 50px 0; + text-align: center; +} +section.title_section.darkblue .padding-div{ + margin: 0 140px; +} +section.title_section.darkblue h1{ + margin-bottom: 25px; + color: #22b8eb; + margin-top: 20px; +} +section.title_section.darkblue p{ + color: #fff; + font-size: 20px; +} +section.title_section.darkblue img{ + margin-top: 18px; +} +section.title_section.darkblue .button { + margin-top: 30px; +} +section.title_section.darkblue .button { + background-color: transparent; + padding: 12px 33px; +} +section.title_section.darkblue .blue-btn { + border: 2px solid #22B8EB; +} +section.title_section.darkblue .orange-btn { + border: 2px solid #F79733; + +} +section.title_section.darkblue .button+.button { + margin-left: 30px; +} +section.title_section.darkblue span.after_button { + display:block; + margin-bottom: 20px; +} +section.GenericDev{ + text-align: center; +} +section.GenericDev h2 { +} +section.GenericDev .container>p { +} +section.GenericDev p a { + color: #24B6E9; + cursor: pointer; +} +section.GenericDev .items{ + list-style: none; + display: block; + padding: 0; + margin: 0; + overflow: hidden; + margin-bottom: 20px; +} +section.GenericDev .items>li{ + margin-bottom: 20px; + text-align: center; + clear: none !important; + padding: 20px 30px 20px; + display: block; + float: left; +} + +section.GenericDev .items>li h3{ + margin-top: 20px; + color: #22B8EB; + font-size: 24px; + margin-bottom: 20px; +} +section.GenericDev .items>li p{ + font-size: 18px; + color: #808284; + line-height: 24px; +} +section.GenericDev .items>li a.button{ + line-height: 24px; + font-size: 17px; + margin: 0; + border-radius: 0; + color: #fff; + padding: 10px 30px; +} +section.GenericDev .items>li ul{ + list-style: initial; +} +section.GenericDev .items>li ul li { + line-height: 22px; + font-size: 18px; + letter-spacing: normal; + color: #808284; + text-align: left; + margin-bottom: 20px; +} +section.docker_solutions_section { + text-align:center; +} +.solution_box { + margin-bottom: 30px; +} +.solution_box .header_box { + padding: 8px; + border-top-right-radius: 15px; + border-top-left-radius: 15px; + background-color: #55b6e9; + border: none; + height: 100px; + margin-bottom: 10px; +} +.solution_box .header_box img{ + display: inline-block; + vertical-align: middle; + padding-bottom: 25px; +} +.solution_box .header_box h3 { + color: #ffffff; + display: inline-block; + font-size: 28px; + padding: 0 20px; + padding-top: 26px; +} +.solution_box .body_box { + background-color: #f1f2f2; + border-bottom-right-radius: 15px; + border-bottom-left-radius: 15px; +} +.solution_box .body_box ul{ + list-style: none; + padding: 30px 30px; + margin:0px +} +.solution_box .body_box ul li { + margin: 0 0 2px 0; + display: block; +} +.solution_box .body_box .media-left { + padding-right: 20px; + padding-top: 8px; + width: 110px; + float: left; +} +.solution_box .body_box ul li img { + +} +.solution_box .body_box ul li h3 { + text-align: left; + font-size: 28px; + color: #55b6e9; + line-height: 30px; +} +.solution_box .body_box ul li h3 small{ + font-size: 18px; + color: #959798; + display: block; + margin-top: 5px; + line-height: 26px; + text-transform: uppercase; +} +.solution_box .body_box ul li p{ + text-align: left; + margin-top: 22px; + color: #808284; + font-size: 17px; +} +section.docker_solutions_section .button { + margin-bottom: 50px; +} +section.docker_toolbox_section{ + text-align:center; + background-color: #164c6a; + background-color: #134a6a; +} +section.docker_toolbox_section .container>p { + color: #e6e7e8; +} +section.docker_toolbox_section .products_items{ + list-style: none; + display: block; + padding: 0; + margin: 0; + overflow: hidden; +} +section.docker_toolbox_section .products_items li{ + margin-bottom: 20px; + text-align: center; + clear: none !important; + padding: 20px 55px 20px; + display: block; + float: left; +} +section.docker_toolbox_section .products_items li img{ + max-height: 42px; + max-width: 80%; +} +section.docker_toolbox_section .products_items li h3{ + margin-top: 16px; + color: #55b6e9; + font-size: 24px; +} +section.docker_toolbox_section .products_items li p{ + font-size: 20px; + color: #e6e7e8; + line-height: 24px; +} +section.software_infrastructure_section{ + text-align:center; +} +section.software_infrastructure_section .products_items{ + list-style: none; + display: block; + padding: 0; + margin: 0 -5px; + overflow: hidden; + margin-bottom: 40px; +} +section.software_infrastructure_section .products_items li{ + margin-bottom: 20px; + text-align: center; + clear: none !important; + padding: 0 5px; + display: block; + float: left; +} +section.software_infrastructure_section .products_items li a{ + padding: 20px 40px 20px; + display: block; + width: 100%; + background-color: #55b6e9; + height: 100%; +} +section.software_infrastructure_section .products_items li h3{ + margin-top: 20px; + color: #fff; + font-size: 24px; +} +section.software_infrastructure_section .products_items li p{ + font-size: 20px; + color: #fff; + line-height: 24px; +} +section.open_standards_section{ + text-align: center; + background-image: url(../images/open_standards_image.png); + background-repeat: no-repeat; + background-size: cover; + background-color: #444c51; +} +section.open_standards_section .container>p { + color: #ffffff; +} +section.open_standards_section .products_items{ + list-style: none; + display: block; + padding: 0; + margin: 0; + overflow: hidden; +} +section.open_standards_section .products_items li{ + margin-bottom: 20px; + text-align: center; + clear: none !important; + padding: 20px 10px 20px; + display: block; + float: left; +} +section.open_standards_section .products_items li a.products_items-card{ +} +section.open_standards_section .products_items li h3{ + margin-top: 20px; + color: #55b6e9; + font-size: 24px; +} +section.open_standards_section .products_items li p{ + font-size: 20px; + color: #e6e7e8; + line-height: 24px; +} +section.bottom_cta_section { + text-align:center; + padding: 100px 0; +} +section.bottom_cta_section.blue { + background-color: #55b6e9; +} +section.bottom_cta_section.gary { + background-color: #3E4D54; +} +section.bottom_cta_section.blue h3 { + color: #fff; + font-size: 44px; + margin-bottom: 25px; +} +@media (max-width:1199px){ +div.heronav_section ul li { + font-size: 17px; + margin: 5px 0px; +} +div.heronav_section ul li a { + padding-left: 15px; + padding-right: 15px; +} +.solution_box .body_box ul { + padding: 30px 20px; +} +.solution_box .body_box .media-left { + padding-right: 15px; + width: 100px; +} +section.docker_toolbox_section .products_items li { + padding: 20px 30px 20px; +} +section.software_infrastructure_section .products_items li a { + padding: 20px 20px 20px; +} +} +@media (max-width:991px){ +.widthcol3>li { + width: 50%; +} +.widthcol4>li { + width: 50%; +} +.widthcol5>li { + width: 33.33%; +} +section.title_section.darkblue .padding-div{ + margin: 0 50px; +} +div.heronav_section { + height: 60px; +} +div.heronav_section ul li { + font-size: 13px; + margin: 5px 0px; +} +div.heronav_section ul li a { + padding-left: 12px; + padding-right: 12px; +} +div.heronav_section.affix+section{ +margin-top:60px; +} +.solution_box .body_box .media-left { + float: none; + display: inline-block; + text-align: center; +} +.solution_box .body_box ul li h3 { + text-align: center; +} +.solution_box .body_box ul li h3 small { + font-size: 22px; + line-height: 22px; +} +.solution_box .body_box ul li p { + text-align: center; +} +} +@media (max-width:940px){ +.main-header { + padding-bottom: 12px; +} +} +@media (max-width:767px){ +.widthcol5>li { + width: 50%; +} +section.title_section.darkblue .padding-div { + margin: 0 15px; +} +section.title_section.darkblue .button+.button { + margin-left: 0px; +} +section.title_section.darkblue img{ + float:left; +} +div.heronav_section { + height: 100%; +} +div.heronav_section.affix{ + height: inherit; +} +div.heronav_section .container{ + overflow-y: hidden; + display: block; + visibility: visible; + white-space: nowrap; + padding: 0px; +} +div.heronav_section ul{ + display: inline-block; + clear: none; + float: none; + overflow: hidden; +} +div.heronav_section ul li { + float: none; + display: inline-block; +} +.solution_box .body_box ul li { + height: auto!important; + margin-bottom: 20px; +} +} +@media (max-width:680px){ +.node-type-use-cases .button, .node-type-use-case .button { + margin-left: 15px; + margin-right: 15px; +} +.node-type-products .button, .node-type-product .button { + margin-left: 15px; + margin-right: 15px; +} +} +@media (max-width:600px){ +.widthcol2>li { + width: 100%; + height: auto!important; +} +.widthcol3>li { + width: 100%; + height: auto!important; +} +.widthcol4>li { + width: 100%; + height: auto!important; +} +} +@media (max-width:480px){ +.widthcol5>li { + width: 100%; +} +} +/*========== End products ==========*/ +/*========== product Sub Pages ==========*/ +section.product_overview_product_section.section { + background-color: #E3E4E6; + padding-bottom:0; +} +section.product_overview_product_section .container>p{ + margin-bottom: 20px; +} +section.product_overview_product_section .container>p:last-of-type{ + margin-bottom: 80px; +} +section.product_overview_product_section .img_container{ + margin: 60px 0; +} +section.product_overview_product_section .tab_container{ + background-repeat: no-repeat; + background-size: contain; + background-position: center bottom; + background-color: #E3E4E6; + padding-top: 60px; + padding-bottom: 0; + max-width: 595px; + margin: auto; + margin-top: 60px; +} +section.product_overview_product_section .tab_container.tab1{ + background-image: url(../images/resources_tab.png); +} +section.product_overview_product_section .tab_container.tab2{ + background-image: url(../images/resources_tab2.png); +} +section.product_overview_product_section .tab_container.tab3{ + background-image: url(../images/resources_tab3.png); + max-width: 780px; +} +section.product_overview_product_section .tab_container.tab4{ + background-image: url(../images/resources_tab4.png); + max-width: 920px; + padding: 70px; + padding-top: 93px; + padding-bottom: 0; +} +section.product_overview_product_section .tab_container.lcd2{ + background-image: url(../images/resources_tab7.png); + max-width: 790px; + padding-bottom: 108px; +} +section.product_overview_product_section .video_container { + position: relative; + background-repeat: no-repeat; + background-size: contain; + background-position: center; +} +section.product_overview_product_section .video_container.lab1,section.product_overview_product_section .video_container.lab2 { + margin: 30px 0 60px 0; + background-image: url(../images/products_demo_laptop.png); +} +section.product_overview_product_section .video_container.lab1 .terminal-window { + margin: auto; + height: 410px; + width: 656px; + padding: 23px 48px 58px 49px; +} +section.product_overview_product_section .video_container.lab1 .terminal-window .terminal { + height: 97%; + width: 100%; + min-height: Inherit; +} +section.product_overview_product_section .video_container.lab2 .terminal-window { + margin: auto; + height: 310px; + width: 656px; + padding: 20px 48px 18px 49px; + max-width: 95%; +} +section.product_overview_product_section .video_container.lab2 .terminal-window .terminal { + height: 84%; + width: 100%; + min-height: Inherit; +} +section.product_overview_product_section .video_container.lcd1 { + margin: 0px 0 80px 0; + background-image: url(../images/resources_lap6.png); +} +section.product_overview_product_section .video_container.lcd1 img { + overflow: hidden; + margin: auto; + padding: 43px 25px 172px 25px; + height: auto; + width: auto; + max-height: inherit; +} + +section.product_overview_product_section .video_container a.play_btn { + position: absolute; + content: 'play'; + display: block; + width: 222px; + height: 140px; + text-align: left; + text-indent: -9999px; + background-image: url(../images/play_button_products.png); + background-repeat: no-repeat; + background-size: cover; + top: 39%; + left: 50%; + margin-top: -70px; + margin-left: -111px; +} +section.toolbox_overview_section { +} +section.toolbox_overview_section .container>p { + margin-bottom: 10px; +} +section.toolbox_overview_section .items>li ul { + list-style: none; + text-align: center; + margin-bottom: 40px; +} +section.toolbox_overview_section .items>li ul li{ + text-align: center; + margin-bottom: 5px; +} +section.toolbox_overview_section .items>li a.button{ + padding: 14px 35px; + margin-left: 20px; + margin-right: 20px; + border-radius: 10px; +} +section.use_product_section { +background-color:#114A6A; +} +section.use_product_section .container>p { +color:#fff; +margin-bottom: 30px; +} +section.use_product_section .items>li{ + padding: 0px 30px; +} +section.use_product_section .items>li h3{ + margin-bottom: 10px; +} +section.use_product_section .items>li p{ + color:#fff; +} +section.use_product_section .items>li .terminal-window{ + margin: 42px; + margin-bottom: 0; +} +section.rest_apis_product_section.section { + background-color: #243138; + position: relative; +} +section.rest_apis_product_section .container>p { + color: #fff; + margin-bottom: 0; +} +section.rest_apis_product_section .items{ + margin-bottom:0; +} +section.rest_apis_product_section .items li{ + margin-bottom:0; +} +section.rest_apis_product_section .items li h3{ + font-size: 28px; +} +section.rest_apis_product_section .items li p{ + color: #fff; + font-size: 20px; +} +section.rest_apis_product_section .items li .video_container { + position: relative; + margin: 30px 0 0 0; + background-image: url(../images/products_demo_laptop.png); + background-repeat: no-repeat; + background-size: contain; + background-position: center; +} +section.rest_apis_product_section .items li .video_container .terminal-window{ + margin: auto; + max-width: 812px; + height: 486px; + padding: 28px 78px 54px 78px; +} +section.rest_apis_product_section .items li .video_container .terminal-window .terminal{ + height: 94%; +} +section.rest_apis_product_section .items li .video_container img { + overflow: hidden; + margin: auto; + padding: 28px 80px 45px 78px; + height: auto; + width: auto; + max-height: inherit; +} +section.rest_apis_product_section .items li .video_container a.play_btn { + position: absolute; + content: 'play'; + display: block; + width: 222px; + height: 140px; + text-align: left; + text-indent: -9999px; + background-image: url(../images/play_button_products.png); + background-repeat: no-repeat; + background-size: cover; + top: 50%; + left: 50%; + margin-top: -70px; + margin-left: -111px; +} +section.rest_apis_product_section .flex-control-nav.flex-control-paging { + bottom: -30px; + height: 35px; + display: block; + position:relative; +} +section.rest_apis_product_section .flex-control-nav.flex-control-paging li a { + background: #D1D3D4; +} +section.rest_apis_product_section .flex-control-nav.flex-control-paging li a:hover { + background: #D1D3D4; +} +section.rest_apis_product_section .flex-control-nav.flex-control-paging li a.flex-active { + background: #24B6E9; +} +section.create_hosts_product_section.section { + background-color:#114A6A; +} +section.create_hosts_product_section .container>p { + color: #fff; +} +section.create_hosts_product_section .items>li .terminal-window{ + margin:auto; +} +section.product_features_product_section { +} +section.product_features_product_section .items hr{ + float: left; + width: 100%; + margin: 18px 0; +} +section.product_features_product_section .items li{ + margin-bottom: 20px; + /*position: relative;*/ +} +section.product_features_product_section .items li h3{ + text-align: left; + font-size: 18px; + font-weight: bold; + margin-bottom: 5px; + margin-top: 0; +} +section.product_features_product_section .items li p{ + text-align: left; +} +section.product_features_product_section .items li a.button { + margin: auto; + margin-top: 18px; + border-radius: 10px; + display: table; + max-width: 100%; + min-width: 300px; +} +section.product_features_product_section .items li .mhe { + /* position: relative; + margin: auto; + bottom: 22px; + width: 86%; */ + margin: 10px 0 0 0; + display: block; + width: 100%; + +} +section.product_features_product_section .items li .video_container { + position: relative; + margin: 30px 0 0 0; +} +section.product_features_product_section .items li .video_container img { + overflow: hidden; + max-height: 100%; + margin: auto; + display: block; +} +section.product_features_product_section .items li .video_container a.play_btn { + position: absolute; + content: 'play'; + display: block; + width: 164px; + height: 104px; + text-align: left; + text-indent: -9999px; + background-image: url(../images/play_button_products.png); + background-repeat: no-repeat; + background-size: cover; + top: 50%; + left: 50%; + margin-top: -52px; + margin-left: -82px; +} +section.product_steps_product_section.section { +background-color: #114A6A; +} +section.product_steps_product_section .container p { + color: #fff; +} +section.product_steps_product_section .items li i { + font-size: 79px; + font-style: normal; + color: #24B6E9; + border: 5px solid #24B6E9; + border-radius: 100px; + padding: 0 25px; +} +section.product_steps_product_section .items li p{ + color: #fff; +} +section.product_steps_product_section .items li .video_container { + position: relative; + margin: 50px 0 0 0; + background-image: url(../images/products_laptop.png); + background-repeat: no-repeat; + background-size: contain; + background-position: center; +} +section.product_steps_product_section .items li .video_container img { + overflow: hidden; + margin: auto; + padding: 15px 50px 25px 50px; + height: auto; + width: auto; + max-height: inherit; +} + +section.product_steps_product_section .items li .video_container a.play_btn { + position: absolute; + content: 'play'; + display: block; + width: 222px; + height: 140px; + text-align: left; + text-indent: -9999px; + background-image: url(../images/play_button_products.png); + background-repeat: no-repeat; + background-size: cover; + top: 50%; + left: 50%; + margin-top: -70px; + margin-left: -111px; +} +section.product_steps_product_section .items.oneli li .video_container img { + padding: 15px 75px 25px 75px; +} +section.product_steps_product_section .items.oneli li .video_container img { + padding: 15px 75px 25px 75px; +} +section.product_steps_product_section .items li .terminal-window{ + margin: 42px; + margin-bottom: 0; +} +section.product_steps_product_section .items li .terminal-window .terminal-data{ + line-height: 24px; + display: inherit; +} +section.signup_product_section.section { +background-color: #E3E4E6; +} +section.resources_product_section.section { +background-color: #24B6E9; +} +section.resources_product_section h2 { +color: #fff; +} +section.resources_product_section .container>p { +color: #fff; +} +section.resources_product_section .resources_files, section.resources_product_section .resources_videos { +color: #fff; +} +section.resources_product_section .resources_files ul, section.resources_product_section .resources_videos ul { + margin: auto; + list-style: none; + width: 80%; +} +section.resources_product_section .resources_files ul li, section.resources_product_section .resources_videos ul li{ + height:100% !important; +} +section.resources_product_section .resources_files li a, section.resources_product_section .resources_videos li a{ + background-color: #fff; + width: 100%; + height: 100%; + display: block; + position: relative; +} +section.resources_product_section .resources_files li a img, section.resources_product_section .resources_videos li a img{ + margin: 30px 10px; +} +section.resources_product_section .resources_files li a div.text-can, section.resources_product_section .resources_videos li a div.text-can{ + display: block; + background-color: #134A6A; + padding: 18px 8px; + bottom: 0; + width: 100%; +} +section.resources_product_section .resources_files li a .category , section.resources_product_section .resources_videos li a .category{ + display: block; + color: #fff; + font-size: 17px; + line-height: 20px; +} +section.resources_product_section .resources_files li a .name, section.resources_product_section .resources_videos li a .name{ + color: #22B8EB; + display: block; + font-size: 18px; + line-height: 20px; + margin-top: 8px; +} +section.pricing_product_section.section { +background-color: #F1F7FD; +} +section.pricing_product_section .plan_box { + margin-bottom: 30px; +} +section.pricing_product_section .plan_box .header h3{ + color: #fff; + padding: 25px 10px 60px 10px; + background-image: url(../images/pricing_product_header_image.png); + background-repeat: no-repeat; + background-size: contain; + background-position: bottom; + margin-bottom: 20px; +} +section.pricing_product_section .plan_box1, section.pricing_product_section .plan_box2, section.pricing_product_section .plan_box3 { +background-color: #fff; +height: 100%; +} +section.pricing_product_section .plan_box1 .header h3{ + background-color: #24B6E9; +} +section.pricing_product_section .plan_box2 .header h3{ + background-color: #114A6A; +} +section.pricing_product_section .plan_box3 .header h3{ + background-color: #3E4D54; +} +section.pricing_product_section .plan_box .header p{ + font-size: 18px; + color: #3E4D54; +} +section.pricing_product_section .plan_box .header span{ + color: #24B6E9; + font-size: 18px; +} +section.pricing_product_section .plan_box .header span i{ + font-size: 33px; + color: #24B6E9; + font-style: normal; + margin-right: 15px; + display: inline-block; +} +section.pricing_product_section .plan_box .body{ + padding-bottom: 30px; + overflow: hidden; +} +section.pricing_product_section .plan_box .body .plan_buttons{ + margin: 20px; +} +section.pricing_product_section .plan_box .body .plan_buttons a.button{ + width: 45%; + margin: 0 2%; + padding: 12px 0; + font-size: 17px; +} +section.pricing_product_section .plan_box .body .plan_buttons a.button.full-width{ + width: 98%; + margin: 0 ; +} +section.pricing_product_section .plan_box .body ul{ + list-style: none; + margin: 45px 20px; + margin-bottom:10px; + text-align: left; +} +section.pricing_product_section .plan_box .body ul li:before{ + content: ""; + background-image: url(../images/pricing_product_li_bullet.svg); + background-repeat: no-repeat; + position: absolute; + width: 17px; + height: 12px; + top: 50%; + margin-top: -6px; + margin-left: -30px; +} +section.pricing_product_section .plan_box .body ul li{ + border-top: 1px solid #CFD0D4; + padding: 12px 0px 12px 35px; + position: relative; + line-height: 20px; + color: #3E4D54; +} +section.pricing_product_section .plan_box .body ul li strong{ + color: #24B6E9; + font-weight: 100; +} +section.cta_product_section.section h2{ + margin-bottom: 50px; +} +section.cta_product_section a.button{ + display: block; + margin: 25px auto; + padding: 14px 20px 14px 20px; + max-width: 400px; +} +section.cta_product_section a.button+a.button{ + padding: 14px 20px 14px 20px; +} +section.cta_product_section a.button.w450{ + max-width: 450px; + width: 100%; +} +section.cta_product_section a.button.w300{ + max-width: 300px; + width: 100%; +} +section.cta_product_section a.button.w200{ + max-width: 200px; + width: 100%; +} +section.demo_product_section.section{ +background-color: #114A6A; +position: relative; +} +section.demo_product_section.section.gray { +background-color: #243138; +} +section.demo_product_section h2 { + color: #fff; +} +section.demo_product_section .container>p { + color: #fff; +} +section.demo_product_section .items{ + margin-bottom:0; +} +section.demo_product_section .items li{ + margin-bottom:0; +} +section.demo_product_section .items li h3{ + color: #fff; + margin-top:0; + font-size: 24px; +} +section.demo_product_section .items li p{ + color: #fff; + font-size: 18px; +} +section.demo_product_section .items li span{ + color: #fff; + font-size: 18px; + line-height: 24px; + display: block; + position: relative; + bottom: -16px; +} +section.demo_product_section .items li span.blue{ + color: #24B6E9; +} +section.demo_product_section .items li .video_container { + position: relative; + margin: 30px 0 0 0; + background-image: url(../images/products_demo_laptop.png); + background-repeat: no-repeat; + background-size: contain; + background-position: center; +} +section.demo_product_section .items li .video_container img { + overflow: hidden; + margin: auto; + padding: 28px 80px 45px 78px; + height: auto; + width: auto; + max-height: inherit; +} + +section.demo_product_section .items li .video_container a.play_btn { + position: absolute; + content: 'play'; + display: block; + width: 222px; + height: 140px; + text-align: left; + text-indent: -9999px; + background-image: url(../images/play_button_products.png); + background-repeat: no-repeat; + background-size: cover; + top: 50%; + left: 50%; + margin-top: -70px; + margin-left: -111px; +} +section.demo_product_section .flex-control-nav.flex-control-paging { + bottom: -30px; + height: 35px; + display: block; + position:relative; +} +section.demo_product_section .flex-control-nav.flex-control-paging li a { + background: #D1D3D4; +} +section.demo_product_section .flex-control-nav.flex-control-paging li a:hover { + background: #D1D3D4; +} +section.demo_product_section .flex-control-nav.flex-control-paging li a.flex-active { + background: #24B6E9; +} +@media (max-width:1199px){ +section.use_product_section .items>li .terminal-window{ + margin: 0; + margin-top: 40px; +} +section.product_steps_product_section .items li .terminal-window{ + margin: 0; + margin-top: 40px; +} +section.product_overview_product_section .video_container.lab2 .terminal-window { + height: 250px; + padding: 12px 40px 18px 40px; +} +} +@media (max-width:991px){ +section.product_overview_product_section .tab_container.lcd2{ + padding: 3.5% 11% 11.5%; +} +section.use_product_section .items.widthcol3>li { + padding: 0 10px; + width: 33.33%; +} +section.product_steps_product_section .items li.videoli { + width:100%; +} +section.product_steps_product_section .items.widthcol3>li { + padding: 0 10px; + width: 33.33%; +} +section.product_overview_product_section .video_container.lcd1 img{ + padding: 35px 25px 145px 25px; +} +section.product_overview_product_section .video_container.lab1 .terminal-window { + padding: 28px 48px 65px 49px; + max-width: 91%; +} +section.product_overview_product_section .video_container.lab1 .terminal-window .terminal { + font-size: 12px; +} +section.product_overview_product_section .video_container.lab2 .terminal-window { + padding: 28px 48px 65px 49px; + max-width: 91%; + height: 410px; +} +section.product_overview_product_section .video_container.lab2 .terminal-window .terminal { + font-size: 12px; + height: 96%; +} +section.rest_apis_product_section .items li .video_container .terminal-window{ + margin: auto; + max-width: 812px; + padding: 60px 80px 56px 80px; + font-size: 12px; + margin-top: 0px; + max-height: 460px; +} + +section.rest_apis_product_section .items li .video_container .terminal-window .terminal{ + font-size: 12px; + min-height: auto; + height: auto; +} +section.demo_product_section .items li .video_container img{ + padding: 3% 11% 5% 11%; +} +section.resources_product_section .resources_files ul, section.resources_product_section .resources_videos ul{ + width: 100%; +} +section.resources_product_section .resources_files .items>li, section.resources_product_section .resources_videos .items>li{ + width: 33.3%; + padding: 20px 15px 20px; +} +} +@media (max-width:767px){ +section.product_overview_product_section .video_container.lcd1 img{ + padding: 38px 25px 142px 25px; +} +section.product_overview_product_section .video_container.lab1 { + background-image: none; + margin-top:0; +} +section.product_overview_product_section .video_container.lab1 .terminal-window { + padding: 0; + width: auto; + height: initial; +} +section.product_overview_product_section .video_container.lab1 .terminal-window .terminal { + height: initial; + font-size: 15px; + padding-bottom: 75px; +} +section.product_overview_product_section .video_container.lab2 { + background-image: none; +} +section.product_overview_product_section .video_container.lab2 .terminal-window { + padding: 0; + width: auto; + height: initial; +} +section.product_overview_product_section .video_container.lab2 .terminal-window .terminal { + height: initial; + font-size: 15px; + padding-bottom: 75px; +} +section.rest_apis_product_section .items li .video_container{ + background-image: none; +} +section.rest_apis_product_section .items li .video_container .terminal-window{ + padding: 0; +} +section.rest_apis_product_section .items li .video_container .terminal-window .terminal{ + height: 100%; + font-size: 15px; +} +.product_overview_product_section .tab_container{ + padding: 60px 11%; + padding-bottom: 0; +} +.product_overview_product_section .tab_container.tab4{ + padding: 60px 10%; + padding-bottom: 0; +} +section.use_product_section .items.widthcol3>li { + width: 100%; +} +section.product_steps_product_section .items.widthcol3>li { + width: 100%; +} +section.use_product_section .items.widthcol3>li .terminal-small { + min-height: 200px; +} +} +@media (max-width:680px){ +section.resources_product_section .resources_files .items>li, section.resources_product_section .resources_videos .items>li { +width: 100%; +} +} +@media (max-width:600px){ +section.product_overview_product_section .video_container.lcd1 img { + padding: 23px 20px 98px 20px; +} +section.demo_product_section .items li .video_container a.play_btn{ + width: 112px; + height: 70px; + margin-top: -35px; + margin-left: -56px; +} +} +/*========== End product Sub Pages ==========*/ +/*========== Use Cases ==========*/ + +section.summary_use_cases_section.section{ + padding-top: 0; + text-align: center; +} +section.summary_use_cases_section .summary_icon{ + width: 104px; + height: 86px; + display: block; + text-align: center; + padding: 14px; + position: relative; + margin: auto; + background-color:#22B8EB; + margin-bottom: 50px; +} +section.summary_use_cases_section .summary_icon:before{ + content: ""; + position: absolute; + left: 50%; + top: 86px; + margin-left: -17px; + border: 17px solid #fff; + border-top-width: 17px; + border-top-color: #22B8EB; + border-bottom: 0; +} +section.summary_use_cases_section .summary_icon img{ + height: 60px; +} +section.resources_use_cases_section.section{ + text-align:center; + padding: 0 +} +section.resources_use_cases_section .resources_video_slider{ + padding: 50px 0 100px 0; + background-image: url(../images/resources_use_cases_image.png); + background-repeat: no-repeat; + background-size: cover; + position: relative; +} +section.resources_use_cases_section .resources_video_slider.white-text h2{ + color: #fff; +} +section.resources_use_cases_section .resources_video_slider.white-text h3{ + color: #fff; +} +section.resources_use_cases_section .resources_video_slider.gray-text p{ + color: #808284; +} +section.resources_use_cases_section .resources_video_slider .slides .slide{ + display:none; +} +section.resources_use_cases_section .resources_video_slider .flex-control-nav.flex-control-paging{ + bottom: 55px; +} +section.resources_use_cases_section .resources_video_slider .flex-control-nav.flex-control-paging li a { + background: #D1D3D4; +} +section.resources_use_cases_section .resources_video_slider .flex-control-nav.flex-control-paging li a:hover { + background: #D1D3D4; +} +section.resources_use_cases_section .resources_video_slider .flex-control-nav.flex-control-paging li a.flex-active { + background: #22B8EB; +} +section.resources_use_cases_section .resources_video_slider .video_container{ + position: relative; + margin: 50px 0; + background-image: url(../images/resources_laptop.png); + background-repeat: no-repeat; + background-size: contain; + background-position: center; +} +section.resources_use_cases_section .resources_video_slider .laptop_image{ + max-width: 900px; + width: 100%; +} +section.resources_use_cases_section .resources_video_slider .inside_laptop_image{ + overflow: hidden; + margin: auto; + padding: 25px 82px 45px 82px; +} +section.resources_use_cases_section .resources_video_slider .play_btn { + position: absolute; + content: 'play'; + display: block; + width: 222px; + height: 140px; + text-align: left; + text-indent: -9999px; + background-image: url(../images/play_button_use_cases.svg); + background-repeat: no-repeat; + background-size: cover; + top: 50%; + left: 50%; + margin-top: -70px; + margin-left: -111px; +} +section.resources_use_cases_section .resources_video_slider h3{ + font-size: 28px; + line-height: 29px; + color: #22B8EB; + margin-top: 30px; + margin-bottom: 30px; +} +section.resources_use_cases_section .resources_video_slider p{ + color: #fff; + margin: auto; + max-width: 560px; + font-size: 20px; +} +section.resources_use_cases_section .resources_files{ + background-color: #243137; + padding: 80px 0; +} +section.resources_use_cases_section .resources_files ul{ + margin: auto; + list-style: none; + width: 80%; +} +section.resources_use_cases_section .resources_files ul li{ + margin-bottom: 20px; + text-align: center; + clear: none !important; + padding: 0px 30px; + display: block; + float: left; +} + +section.resources_use_cases_section .resources_files ul li{ + height:100% !important; +} +section.resources_use_cases_section .resources_files ul li a{ + background-color: #fff; + width: 100%; + height: 100%; + display: block; + position: relative; +} +section.resources_use_cases_section .resources_files ul li a img{ + margin: 30px 10px; +} +section.resources_use_cases_section .resources_files ul li a div.text-can{ + display: block; + background-color: #134A6A; + padding: 18px 8px; + bottom: 0; + width: 100%; +} +section.resources_use_cases_section .resources_files ul li a .category{ + display: block; + color: #fff; + font-size: 17px; + line-height: 20px; +} +section.resources_use_cases_section .resources_files ul li a .name{ + color: #22B8EB; + display: block; + font-size: 18px; + line-height: 20px; + margin-top: 8px; +} +section.quotes_use_cases_section { + background-color: #22B8EB; +} +section.quotes_use_cases_section .quotes_icon { + background-image: url(../images/quotes_icon_use_cases.svg); + width: 60px; + height: 60px; + margin: auto; + margin-bottom: 30px; + background-size: 99%; + background-repeat: no-repeat; + display: block; +} +section.quotes_use_cases_section .quotes_use_cases_slider{ +padding: 0 30px; +} +section.quotes_use_cases_section .quotes_use_cases_slider ul.slides { +} +section.quotes_use_cases_section .quotes_use_cases_slider ul.slides li { + display: none; +} +section.quotes_use_cases_section .quotes_use_cases_slider ul.slides li p { + font-size: 24px; + color: #F1F2F2; + text-align: center; + margin: 0px 50px 30px; + line-height: 1.3; +} +section.quotes_use_cases_section .quotes_use_cases_slider ul.slides li span{ + font-size: 24px; + color: #fff; + text-align: center; + display: block; +} +section.quotes_use_cases_section .quotes_use_cases_slider ul.flex-direction-nav a { + text-decoration: none; + width: 28px; + height: 58px; + margin: -20px 0 0; + position: absolute; + top: 50%; + z-index: 10; + overflow: hidden; + opacity: 1; + cursor: pointer; + text-shadow: none; + -webkit-transition: none; + -moz-transition: none; + transition: none; +} +section.quotes_use_cases_section .quotes_use_cases_slider ul.flex-direction-nav .flex-prev { + left: 0px; + text-align: left; + background-image: url(../images/quotes_arrow_use_cases.svg); + text-indent: -9999px; + background-position: 0 0; +} +section.quotes_use_cases_section .quotes_use_cases_slider ul.flex-direction-nav .flex-next { + right: 0px; + text-align: right; + background-image: url(../images/quotes_arrow_use_cases.svg); + text-indent: 9999px !important; + background-position: -32px 0px; +} +/*========== End Use Cases ==========*/ +/*========== Use Cases Main ==========*/ +section.use_cases_section .items li a.item-link{ + display: block; + /* min-height: 175px; */ + margin-bottom: 10px; +} +section.use_cases_section .items li p{ + font-size: 16px; + line-height: 20px; +} +section.use_cases_section .items li img{ + max-height: 85px; + max-width: 100%; +} +section.use_cases_item_section.section { + text-align: center; + padding: 50px 0 50px 0; + background-image: url(../images/resources_use_cases_image.png); + background-repeat: no-repeat; + background-size: cover; + position: relative; + padding-top: 0; +} +section.use_cases_item_section.section .use_cases_item_icon { + width: 91px; + height: 77px; + display: block; + text-align: center; + padding: 14px; + position: relative; + margin: auto; + background-color: #fff; + margin-bottom: 50px; +} +section.use_cases_item_section.section .use_cases_item_icon:before { + content: ""; + position: absolute; + left: 50%; + top: 77px; + margin-left: -17px; + border: 17px solid rgba(0, 0, 0, 0); + border-top-width: 17px; + border-top-color: #fff; + border-bottom: 0; +} +section.use_cases_item_section.section .use_cases_item_icon img { + height: 50px; +} +section.use_cases_item_section .container>p { + color: #fff; +} +section.use_cases_item_section .quote_container { + max-width: 700px; + margin: auto; +} +section.use_cases_item_section .quote_container .quotes_icon { + background-image: url(../images/quotes_blue_icon_use_cases.svg); + width: 52px; + height: 52px; + margin: auto; + margin-bottom: 20px; + background-size: 99%; + background-repeat: no-repeat; + display: block; +} +section.use_cases_item_section .quote_container p { + font-size: 20px; + color: #F1F2F2; +} +section.use_cases_item_section .quote_container span.author{ + font-size: 21px; + color: #22B8EB; + margin-bottom: 30px; + display: block; +} + +section.use_cases_item_section.section.white-text h2 { + color: #fff; +} +section.use_cases_item_section.white-text .quote_container .quotes_icon { + background-image: url(../images/quotes_white_icon_use_cases.svg); +} +section.use_cases_item_section.white-text .quote_container span.author { + color: #fff; +} +section.use_cases_item_section.gray-text .container>p { + color: #808284; +} +section.use_cases_item_section.gray-text .quote_container p { + color: #808284; +} +/*========== End Use Cases Main ==========*/ +/*========== Home Page - Use Cases ==========*/ +.node-type-front-page .use_cases_section { + text-align: center; + background-image: url(../images/open_standards_image.png); + background-repeat: no-repeat; + background-size: cover; + background-color: #444c51; +} +.node-type-front-page .use_cases_section h2{ + color: #22B8EB; + font-size: 44px; + line-height: 50px; + margin-bottom: 20px; +} +.node-type-front-page .use_cases_section .container>p{ + font-size: 20px; + line-height: 29px; + margin-bottom: 50px; + color: #fff; +} +.node-type-front-page .use_cases_section .items li p { + color: #e6e7e8; +} +.node-type-front-page .use_cases_section .items li p { + color: #e6e7e8; +} +.node-type-front-page .use_cases_section a:hover, .node-type-front-page .use_cases_section a:focus{ + color: inherit; + text-decoration: none; +} +/*========== Home Page - End Use Cases ==========*/ +/*========== New Footer Style Start ==========*/ +footer.main-footer>.row{ + padding-top: 50px; + padding-bottom: 50px; + padding-left: 80px; + padding-right: 80px; +} +.field-type-field-collection .form-wrapper>legend>span.fieldset-legend { + font-size: 25px; +} +.nav-global-footer div>ul>li { + margin-bottom: 12px; + line-height: 18px; +} +.nav-global-footer div>ul>li>a { + color: #7A8491; + font-size: 0.857rem; + text-decoration: none; +} +.nav-global-footer div>ul>li>a:hover { + text-decoration: none; + color: #22b8eb; +} +.nav-global-footer ul>li { + margin-bottom: 12px; + line-height: 18px; +} +.nav-global-footer ul>li>a { + color: #7A8491; + font-size: 0.857rem; +} +.nav-global-footer ul>li>a:hover { + text-decoration: none; + color: #22b8eb; +} + +.main-footer .nav-global-footer .columns+.columns:last-child { + float: left; + padding-right: 40px; +} +.main-footer .columns+.columns:last-child img.wow{ + margin-left: 15px; +} +.main-footer p { +font-size: 0.857rem; +line-height: 18px; +} +.footer-copyright p{ + font-size: 1rem; + line-height: 1.6; +} +.footer-copyright { + background-color: #1B2529; + padding: 12px 10px; +} +.primary-footer-sub-copyright { + float: left; + margin:0px; +} +.primary-footer-sub-nav { +} +.footer-copyright .primary-footer-sub-nav { + padding: 0 100px 0 0; +} +.footer-copyright .row>p{ + padding: 0 0 0 95px; + padding-top: 4px; +} +.primary-footer-sub-nav ul { + float: right; + margin: 0px; +} +.primary-footer-sub-nav ul li { + float: left; + margin-left: 45px; +} +.primary-footer-sub-nav ul li a { +} +.primary-footer-sub-nav ul li a:hover{ + text-decoration: none; + color: #22b8eb; +} +.main-footer div.newsletter form .mktoFormRow { +width: 60%; +} +.columns+.nav-global-footer.columns:last-child { + float: left; +} +.main-footer ul.social-icons { + min-height: 0; + margin-right: 40px; +} +.social-icons li { + width: 25%; + height: 45px; + margin: 5px 0; +} +.social-icons li a img{ + height: 34px; + width: 34px; +} +.social-icons li a{ + color: #fff; + font-size: 24px; + display:inline-block; +} +.social-icons li a:hover{ + color: #fff; +} +.main-footer h6 { + margin-bottom: 30px; + font-size: 20px; +} +@media (max-width:991px){ +footer.main-footer>.row{ + padding-left: 20px; + padding-right: 20px; +} +.footer-copyright .row>p { + padding: 0 0 0 25px; + padding-top: 4px; +} +.footer-copyright .primary-footer-sub-nav { + padding: 0 20px 0 0; +} +} +/*========== New Footer Style End ==========*/ +/*========== New Enterprise Style ==========*/ +.node-type-enterprise a.orange-border-btn{ +color:#fff !important; +background-color: transparent; + padding: 12px 33px; +border: 2px solid #F79733; +font-size: 17px; +border-radius: 10px; +margin-left: 20px; +margin-right: 20px; + line-height: inherit; +} +.node-type-enterprise a.blue-border-btn{ +color:#fff !important; +background-color: transparent; + padding: 12px 33px; +border: 2px solid #22B8EB; +font-size: 17px; +border-radius: 10px; +margin-left: 20px; +margin-right: 20px; + line-height: inherit; +} +.node-type-enterprise a.orange-border-btn:hover ,.node-type-enterprise a.orange-border-btn:focus{ +color:#fff; +background-color: transparent; + text-decoration: none; +} +.node-type-enterprise a.blue-border-btn:hover, .node-type-enterprise a.blue-border-btn:focus{ +color:#fff; +background-color: transparent; + text-decoration: none; +} +.node-type-enterprise section .title_section { +padding:0; +} +.node-type-enterprise div.heronav_section ul li { +font-size: 15px; +} +.node-type-enterprise div.heronav_section ul li a{ + padding: 15px 10px; +} +@media (max-width:1199px){ +.node-type-enterprise div.heronav_section ul li { + font-size: 13px; +} +} +@media (max-width:991px){ +.node-type-enterprise div.heronav_section ul li { + font-size: 11px; +} +.node-type-enterprise div.heronav_section ul li a { + padding: 13px 10px; +} +} +@media (max-width:767px){ +.node-type-enterprise div.heronav_section ul li { + font-size: 13px; + margin: 5px 0px; +} +.node-type-enterprise div.heronav_section ul li a { + padding: 12px; +} +} +/*========== New Enterprise Style End ==========*/ +/*========== Pricing Pages ==========*/ +section.plans_section .plans .server_plan_box:hover { + box-shadow: 0 0 20px #A0A0A0; +} +section.plans_section .plans .server_plan_box:hover { + background-color:#F9F9F9; +} +section.plans_section .plans .serverplan_boxs>p{ + text-align: center; + margin-bottom: 20px; + font-size: 16px; + line-height: 1.6; +} +section.plans_section .plans .server_plan_box ul.feature{ + padding-bottom: 10px; +} +section.plans_section .plans .server_plan_box ul.feature li{ + font-size: 16px; + color: #147698; + margin-bottom: 22px; + color: #546473; +} +section.plans_section .plans .server_plan_box ul.feature li span{ + display:block; + color: #FFC828; + font-size: 15px; + color: #546473; +} +section.plans_section .plans .server_plan_box ul.feature li strong{ +color: #111; + color: #546473; +} +section.plans_section .plans .server_plan_box ul.feature li strong+span{ + display: block; + color: #111; + font-size: 12px; + line-height: 15px; + margin-top: 16px; + color: #546473; +} +section.plans_section .plans_tabs { + margin-bottom: 35px; +} +/*========== End Pricing Pages ==========*/ +/*========== Products Pages ==========*/ +.main-header div>.nav-main>li.octopus-navstyle>ul ul ul{ + margin-left: 20px; +} +section.product_overview_product_section.overview_button{ + padding-bottom: 60px; +} +section.product_overview_product_section.overview_button .container>p:last-of-type{ + margin-bottom: 40px; +} +section.product_overview_product_section .button{ + margin: auto; + margin-top: 30px; + border-radius: 10px; + display: table; + max-width: 100%; + min-width: 300px; +} +section.product_steps_product_section .items li a.button{ + margin: auto; + margin-top: 30px; + border-radius: 10px; + display: table; + max-width: 100%; + min-width: 300px; +} +section.included_product_section h2{ + margin-bottom: 40px; +} +section.included_product_section .container .includedstyle p{ + font-size: 20px; + text-align: center; + max-width: 200px; + margin: auto; + margin-bottom: 20px; + transform: translateY(70%); + -moz-transform: translateY(70%); + -ms-transform: translateY(70%); + -o-transform: translateY(70%); + -webkit-transform: translateY(70%); +} +section.included_product_section span{ + position: relative; +} +section.included_product_section span:after{ + content: ""; + position: absolute; + top: 50%; + right: -129px; + margin-top: -80px; + border: 80px solid transparent; + border-left-width: 50px; + border-left-color: #BFBFBF; + z-index: 99; +} +@media (max-width:991px){ +section.included_product_section span{ + display:block; +} +section.included_product_section span:after{ + content: ""; + position: absolute; + left: 50%; + bottom: -129px; + margin-left: -80px; + border: 80px solid transparent; + border-top-width: 50px; + border-top-color: #BFBFBF; + z-index: 99; + top: inherit; + right: inherit; +} +section.included_product_section .container .includedstyle p:last-child{ + margin-bottom: 60px; +} +} +@media (max-width:767px){ +section.product_steps_product_section .items li a.button { + max-width: inherit; + min-width: inherit; +} +} +/*========== End Products Pages ==========*/ +/*========== Mobile Nav ==========*/ +.left-off-canvas-menu ul.off-canvas-list li.has-submenu>span.asd { + height: 20px; + margin-top: -7px; + position: relative; + float: right; + display: block; + cursor:pointer; + z-index:99; +} +.left-off-canvas-menu ul.off-canvas-list li.has-submenu>span.asd:after { + content: "\BB"; + font-size: 30px; + color: #eee; + width: 45px; + display: block; + text-align: center; +} +.left-off-canvas-menu ul.off-canvas-list li.has-submenu>a:after { + content: ""; +} +.left-submenu .back>a:before { + content: "\AB"; + margin-right: .5rem; + display: inline-block; + font-size: 30px; + line-height: 26px; + float: left; +} +/*========== End Mobile Nav ==========*/ +/*========== Government Pages ==========*/ +html.safari .node-type-government div.heronav_section ul { + display:block; +} +html.safari .node-type-government div.heronav_section ul li { + width: 32%; +} +section.government_state_and_federal_section.section{ + +} +section.government_state_and_federal_section .max-width{ + max-width: 950px; + margin: auto; + float: none; +} +section.government_state_and_federal_section h2{ + margin-bottom: 50px; +} +section.government_state_and_federal_section p{ + font-size: 18px; + line-height: 1.6; + margin-bottom: 30px; + color: #808284; + +} +section.government_state_and_federal_section .federal_item{ + display: table; + margin: auto; + margin-bottom: 50px; + margin-top: 20px; + margin-bottom: 20px; + width: 32%; + display: inline-block; + text-align: center; + overflow: hidden; +} +section.government_state_and_federal_section .federal_item canvas{ + width: 90%; + margin-left: -45px; +} +section.government_state_and_federal_section .federal_item img{ + max-width: 100px; + max-height: 82px; +} +section.government_state_and_federal_section .federal_item h3{ + color: #22B8EB; + font-size: 38px; + line-height: 50px; + float: right; + margin: 16px 0 0 50px; +} +section.blue_quotes_section { + background-color: #22B8EB; +} +section.blue_quotes_section .quotes_icon { + background-image: url(../images/quotes_white_icon_use_cases.svg); + width: 52px; + height: 52px; + margin: auto; + margin-bottom: 20px; + background-size: 99%; + background-repeat: no-repeat; + display: block; +} +section.blue_quotes_section .quotes_2_slider{ +padding: 0 30px; +} +section.blue_quotes_section .quotes_2_slider ul.slides { +} +section.blue_quotes_section .quotes_2_slider ul.slides li { + display: none; +} +section.blue_quotes_section .quotes_2_slider ul.slides li p { + font-size: 24px; + color: #fff; + text-align: center; + margin: 0px auto 30px; + line-height: 1.3; + max-width: 700px; + font-style:italic; +} +section.blue_quotes_section .quotes_2_slider ul.slides li span{ + font-size: 24px; + color: #fff; + text-align: center; + display: block; + line-height: 28px; + margin: auto; + max-width: 550px; +} +section.blue_quotes_section .quotes_2_slider ul.flex-direction-nav a { + text-decoration: none; + width: 28px; + height: 58px; + margin: -20px 0 0; + position: absolute; + top: 50%; + z-index: 10; + overflow: hidden; + opacity: 1; + cursor: pointer; + text-shadow: none; + -webkit-transition: none; + -moz-transition: none; + transition: none; +} +section.blue_quotes_section .quotes_2_slider ul.flex-direction-nav .flex-prev { + left: 0px; + text-align: left; + background-image: url(../images/quotes_arrow_use_cases.svg); + text-indent: -9999px; + background-position: 0 0; +} +section.blue_quotes_section .quotes_2_slider ul.flex-direction-nav .flex-next { + right: 0px; + text-align: right; + background-image: url(../images/quotes_arrow_use_cases.svg); + text-indent: 9999px !important; + background-position: -32px 0px; +} +section.customer_spotlight_section.section{ +background-color: #114A6A; +position: relative; +} +section.customer_spotlight_section.section.gray { +background-color: #243138; +} +section.customer_spotlight_section h2 { + color: #29B5E5; +} +section.customer_spotlight_section .container>p { + color: #fff; +} +section.customer_spotlight_section .items{ + margin-bottom:0; +} +section.customer_spotlight_section .items li{ + margin-bottom:0; +} +section.customer_spotlight_section .items li h3{ + color: #fff; + margin-top:0; + font-size: 24px; +} +section.customer_spotlight_section .items li p{ + color: #fff; + font-size: 18px; +} +section.customer_spotlight_section .items li span{ + color: #fff; + font-size: 18px; + line-height: 24px; + display: block; + position: relative; + bottom: -16px; +} +section.customer_spotlight_section .items li span.blue{ + color: #24B6E9; +} +section.customer_spotlight_section .items li .video_container { + position: relative; + margin: 0 0 0 0; + background-image: url(../images/products_demo_laptop.png); + background-repeat: no-repeat; + background-size: contain; + background-position: center; +} +section.customer_spotlight_section .items li .video_container img { + overflow: hidden; + margin: auto; + padding: 28px 80px 45px 78px; + height: auto; + width: auto; + max-height: inherit; +} + +section.customer_spotlight_section .items li .video_container a.play_btn { + position: absolute; + content: 'play'; + display: block; + width: 222px; + height: 140px; + text-align: left; + text-indent: -9999px; + background-image: url(../images/play_button_products.png); + background-repeat: no-repeat; + background-size: cover; + top: 50%; + left: 50%; + margin-top: -70px; + margin-left: -111px; +} +section.customer_spotlight_section .flex-control-nav.flex-control-paging { + bottom: -30px; + height: 35px; + display: block; + position:relative; +} +section.customer_spotlight_section .flex-control-nav.flex-control-paging li a { + background: #D1D3D4; +} +section.customer_spotlight_section .flex-control-nav.flex-control-paging li a:hover { + background: #D1D3D4; +} +section.customer_spotlight_section .flex-control-nav.flex-control-paging li a.flex-active { + background: #24B6E9; +} +section.government_state_and_local_section.section{ + +} +section.government_state_and_local_section h2{ + margin-bottom: 50px; +} +section.government_state_and_local_section p{ + font-size: 18px; + line-height: 1.6; + margin-bottom: 30px; + color: #808284; +} +section.government_state_and_local_section img{ + margin-top: 10%; + margin-bottom: 20px; +} +section.government_education_section.section{ + background-color:#F0F6FC; +} +section.government_education_section h2{ + margin-bottom: 50px; +} +section.government_education_section p{ + font-size: 18px; + line-height: 1.6; + margin-bottom: 30px; + color: #808284; +} +section.government_education_section img{ + margin-top: 10%; + margin-bottom: 30px; +} +section.government_education_section a.button{ + min-width: 300px; + width: auto; + margin-top: 30px; +} +@media (max-width:991px){ +section.government_state_and_federal_section .federal_item canvas { + width: 100%; +} +section.customer_spotlight_section .items li .video_container img{ + padding: 3% 11% 5% 11%; +} +} +@media (max-width:767px){ +section.government_state_and_federal_section .federal_item { + display: block; +} +section.government_state_and_federal_section .federal_item { + display: block; + max-width: 350px; + width: 100%; +} +} +@media (max-width:600px){ +section.customer_spotlight_section .items li .video_container a.play_btn{ + width: 112px; + height: 70px; + margin-top: -35px; + margin-left: -56px; +} +.node-type-products section.title_section.darkblue .button, .node-type-product section.title_section.darkblue .button ,.node-type-use-cases section.title_section.darkblue .button, .node-type-use-case section.title_section.darkblue .button,.node-type-enterprise section.title_section.darkblue .button, .node-type-government section.title_section.darkblue .button { + min-width: 300px; + margin: auto; + width: auto; + margin-top: 30px; +} +} +/*========== End Government Pages ==========*/ +/*========== End Partner Pages ==========*/ +section.title_section.darkblue .white-btn { + border: 2px solid #fff; + border-radius:10px; +} +section.title_section.darkblue .white-btn .fa-play { + font-size: 10px; + margin: 8px -10px 0px 20px; + color: #F79733; + float: right; +} +.team_info_list , +.team_info{ + display:none !important; +} +.cbp .cbp-item { + width: 260px; + height: 260px; +} +.find_a_partner_section#technology{ + padding-bottom: 0px; +} +.find_a_partner_section#logging{ + padding-top: 0px; +} +.find_a_partner_section h2+.cbp-l-grid-gallery{ + margin-top: 50px; +} +.find_a_partner_section h2{} +.find_a_partner_section p{} +.find_a_partner_section a.button.blue-btn{ + background-color: transparent; + padding: 12px 33px; + border: 2px solid #22B8EB; + color: #22B8EB; + margin-top:20px; +} +.find_a_partner_section ul.partners_list{} +.find_a_partner_section ul.partners_list li{} +.find_a_partner_section ul.partners_list li a.cbp-singlePageInline{ + display: table; +} +.find_a_partner_section ul.partners_list li.cbp-singlePageInline-active{ + opacity: 1!important; +} +.find_a_partner_section ul.partners_list li .helper{ + width: 100%; + height: 100%; + padding: 15px 15px; + text-align: center; + vertical-align: middle; + display: table-cell; + border: 1px solid #848484; +} +.find_a_partner_section ul.partners_list li a.cbp-singlePageInline{ + background-color: #fff; +} +/*.find_a_partner_section ul.partners_list li a.cbp-singlePageInline:hover{ + background-color:#24B6E9; +} +.find_a_partner_section ul.partners_list li.cbp-singlePageInline-active a.cbp-singlePageInline{ + background-color:#24B6E9; +}*/ +.find_a_partner_section ul.partners_list li img{ + max-height: 140px; + margin: auto; + max-width: 160px; +} +.find_a_partner_section ul.partners_list .cbp-popup-content{ + background-color: #114A6A; + padding: 30px 50px; + color: #fff; + margin-bottom: 30px; + height: 1px; + min-height: 1px; + max-height: 1px; + padding: 0; + margin: 0; + margin-top: 0; +} +.find_a_partner_section .nomore2 ul.partners_list .cbp-popup-content{ + height: initial; + min-height: 200px; + max-height: initial; + padding: 30px 50px; + margin-bottom: 30px; +} +.find_a_partner_section ul.partners_list .cbp-popup-content span.name{ + font-size: 20px; + font-weight: bold; + display: block; + border-bottom: 1px solid #eee; + padding-bottom: 10px; +} +.find_a_partner_section ul.partners_list .cbp-popup-content p{ + color: #fff; + margin: 20px 0; +} +.find_a_partner_section ul.partners_list .cbp-popup-content a.view_website{ + color: #24B6E9; + margin-bottom: 25px; + display: inline-block; +} +.cbp-popup-singlePageInline .cbp-popup-close { + background: url(../images/cbp-popup-close.png) no-repeat scroll 0px 0px transparent; + height: 24px; + width: 24px; + right: 24px; + top: 24px; +} +.cbp-popup-singlePageInline .cbp-popup-close:focus { + outline: none; +} +.partners_list .cbp-singlePageInline-active .cbp-caption .overlay { + opacity: 0.8; +} +.partners_list .cbp-caption:hover .overlay { + opacity: 0.8; +} +.partners_list .cbp-caption .overlay { + position: absolute; + z-index: 2; + width: 100%; + height: 100%; + opacity: 0; + overflow: hidden; + background-color: #24B6E9; + -webkit-transition: all 0.0s ease-in-out; + -moz-transition: all 0.0s ease-in-out; + -o-transition: all 0.0s ease-in-out; + -ms-transition: all 0.0s ease-in-out; + transition: all 0.0s ease-in-out; + left: 0px; + right: 0px; + top: 0px; + bottom: 0px; +} +.cbp .partners_list .cbp-item , .cbp-wrapper{ + overflow: inherit; +} +.partners_list .cbp-singlePageInline-active:after { + content: ""; + position: absolute; + left: 50%; + bottom: -30px; + margin-left: -18px; + border: 18px solid transparent; + border-bottom-width: 18px; + border-bottom-color: #114A6A; +} +.node-type-partners div.heronav_section ul li { +font-size: 15px; +} +.node-type-partners div.heronav_section ul li a{ + padding: 15px 10px; +} +@media (max-width:1199px){ +.node-type-partners div.heronav_section ul li { + font-size: 13px; +} +} +@media (max-width:991px){ +.node-type-partners div.heronav_section ul li { + font-size: 11px; +} +.node-type-partners div.heronav_section ul li a { + padding: 13px 10px; +} +} +@media (max-width:767px){ +.node-type-partners div.heronav_section ul li { + font-size: 13px; + margin: 5px 0px; +} +.node-type-partners div.heronav_section ul li a { + padding: 12px; +} +} +.partners_list .cbp-singlePageInline-active.no_info:after{ + display:none; +} +.partners_list .cbp-singlePageInline-active.no_info .cbp-caption .overlay { + opacity: 0; +} +/*========== End Partner Pages ==========*/ +/*========== Partner Programs Pages ==========*/ +section.partner_program_section{ + text-align: center; + background-image: url(../images/partner_program_bg_image.png); + background-repeat: no-repeat; + background-size: cover; + background-color: #879297; +} +section.partner_program_section h2{ + color:#fff; +} +section.partner_program_section .container p{ + color:#fff; + margin-bottom: 30px; +} +section.partner_program_section ul.items{ + margin-top: 50px; +} +section.partner_program_section ul.items li{ + background-color: rgba(255, 255, 255, 0.7); + border-radius: 800px; + width: 500px; + display:inline-block; + float:none; + padding: 50px 56px 50px; + height:initial!important; +} +section.partner_program_section ul.items li:first-child{ + padding-right: 120px; +} +section.partner_program_section ul.items li:first-child img{ + margin-left: 30px; +} +section.partner_program_section ul.items li:last-child{ + margin-left: -100px; + padding-left: 120px; +} +section.partner_program_section ul.items li:last-child img{ + margin-left: -30px; +} +section.partner_program_section ul.items li h3{ + margin-top: 10px; + color: #114A6A; + font-size: 24px; + margin-bottom: 10px; + padding: 0 35px; +} +section.partner_program_section ul.items li p{ + color:#3E4D54; +} +section.partner_program_section ul.items li .button { + margin-bottom: 20px; + border-radius: 10px; +} +section.program_benefits_section.section { + background-color:#114A6A; +} +section.program_benefits_section h2{ + color:#fff; +} +section.program_benefits_section .container p{ + color:#fff; +} +section.program_benefits_section p small{ + display: block; +} +section.program_benefits_section ul.items li { + padding: 20px 15px 20px; +} +section.program_benefits_section ul.items li h3{ + font-size: 22px; + color:#fff; +} +section.program_benefits_section ul.items li p{ + font-size: 16px; + color:#fff; +} +section.program_benefits_section .program_benefits_footer h4 { + font-size: 22px; + margin-bottom: 20px; +} +section.program_benefits_section .program_benefits_footer p { + font-size: 18px; + margin-bottom: 30px; +} +section.authorized_partners_section h2{ + margin-bottom: 40px; +} +section.authorized_partners_section h3{ + font-size: 24px; + margin-bottom: 10px; +} +section.authorized_partners_section .container>p{ + margin-bottom: 30px; +} +section.authorized_partners_section img { + display: block; + margin: auto; + margin-bottom: 30px; +} +section.authorized_partners_section span { + font-size: 24px; + display: block; + color: #22b8eb; + margin-bottom: 10px; +} +section.technology_partners_section.section { + background-color:#f4f4f4; +} +section.technology_partners_section {} +section.technology_partners_section .container>p{ + margin-bottom: 20px; +} +section.technology_partners_section .email_icon { + background-image: url(../images/technology_partners_email_icon.png); + width: 50px; + height: 34px; + margin-left: 15px; + background-size: 100%; + display: inline-block; + position: relative; + top: 4px; +} +section.technology_partners_section a:hover, section.technology_partners_section a:focus , section.technology_partners_section a:active { +color:#24B6E9; +} +section.technology_partners_section ul.items li{ + +} +section.technology_partners_section ul.items img{ + margin-bottom: 50px; +} +section.technology_partners_section ul.items>li a.button{ + font-size: 17px; + border-radius: 10px; + color: #ffffff; + margin-left: 20px; + margin-right: 20px; + padding: 14px 35px; +} +section.strategic_alliances_section.section { + +} +section.strategic_alliances_section .strategic_alliances_tabs{ + +} +section.strategic_alliances_section .strategic_alliances_tabs ul{ + list-style: none; + margin: 0; + padding: 0; +} +section.strategic_alliances_section .strategic_alliances_tabs ul li{ + display: inline-block; + font-size: 62px; + position: relative; + width: 280px; + height: 280px; + max-width: 30%; + margin: 10px; +} +section.strategic_alliances_section .strategic_alliances_tabs ul li a{ + display: table; + width: 100%; + height: 100%; + overflow: hidden; +} +section.strategic_alliances_section .strategic_alliances_tabs ul li .helper{ + width: 100%; + height: 100%; + padding: 15px 15px; + text-align: center; + vertical-align: middle; + display: table-cell; + background-color: #adb8bc; +} +section.strategic_alliances_section .strategic_alliances_tabs ul li.current .helper{ + background-color: #24B6E9; +} +section.strategic_alliances_section .strategic_alliances_tabs ul li.current:after{ + content: ""; + position: absolute; + left: 50%; + bottom: -36px; + margin-left: -18px; + border: 18px solid transparent; + border-top-width: 18px; + border-top-color: #24B6E9; + z-index: 99; +} +section.strategic_alliances_section .strategic_alliances_tabs ul li .helper img{ + max-height: 140px; + margin: auto; + max-width: 200px; +} +section.strategic_alliances_section .strategic_alliances_content{ + margin-top: 50px; + display:none; +} +section.strategic_alliances_section .strategic_alliances_content h3{ + font-size: 20px; + font-weight: bold; + margin-bottom: 20px; +} +section.strategic_alliances_section .strategic_alliances_content p{ + color:#114A6A; +} +span.learnmore{ + color:#24B6E9; +} +span.learnmore:after{ + content: "\BB"; + font-size: 30px; + color: #24B6E9; + position: relative; + text-align: center; + top: 5px; + margin-left: 8px; +} +section.strategic_alliances_section .strategic_alliances_content .video_container{ + position: relative; + margin: 50px 0 0 0; + background-image: url(../images/products_laptop.png); + background-repeat: no-repeat; + background-size: contain; + background-position: center; + max-width: 500px; + margin: auto; +} +section.strategic_alliances_section .strategic_alliances_content .video_container img{ + overflow: hidden; + margin: auto; + padding: 15px 50px 25px 50px; + padding: 3% 12% 5% 12%; + height: auto; + width: auto; + max-height: inherit; +} +section.strategic_alliances_section .strategic_alliances_content .video_container .play_btn{ + position: absolute; + content: 'play'; + display: block; + width: 132px; + height: 84px; + text-align: left; + text-indent: -9999px; + background-image: url(../images/play_button_products.png); + background-repeat: no-repeat; + background-size: 100%; + top: 50%; + left: 50%; + margin-top: -42px; + margin-left: -66px; +} +section.partner_announcements_section.section{ + background-color:#243137; +} +section.partner_announcements_section h2{ + color:#fff; + margin-bottom: 30px; +} +section.partner_announcements_section ul.items li{ + padding: 0 30px 0; + margin: 20px 0; +} +section.partner_announcements_section ul.items li+li{ + border-left:1px solid #B7B7B7; +} +section.partner_announcements_section ul.items li h3{ + font-size: 20px; + color: #fff; + margin-top: 5px; +} +section.partner_announcements_section ul.items li p{ + color: #fff; +} +section.become_partner_section { + text-align: center; + background-image: url(../images/become_partner_bg_image.png); + background-repeat: no-repeat; + background-size: cover; + background-color: #a3b9c6; + padding: 80px 0 80px 0!important; +} +section.become_partner_section h2 { + color: #fff; +} +section.become_partner_section .container>p { + color: #fff; +} +.node-type-partner-programs div.heronav_section ul li { +font-size: 15px; +} +.node-type-partner-programs div.heronav_section ul li a{ + padding: 15px 10px; +} +@media (max-width:1199px){ +.node-type-partner-programs div.heronav_section ul li { + font-size: 13px; +} +} +@media (max-width:991px){ +section.partner_program_section ul.items li:first-child { + padding: 35px 35px 35px; + padding-right: 60px; + width: 383px; +} +section.partner_program_section ul.items li:last-child { + margin-left: -52px; + padding: 35px 35px 35px; + padding-left: 60px; + width: 383px; +} +section.strategic_alliances_section .strategic_alliances_tabs ul li { + height: 210px; +} +section.partner_announcements_section ul.items li{ + width: 33.33%; +} +.node-type-partner-programs div.heronav_section ul li { + font-size: 11px; +} +.node-type-partner-programs div.heronav_section ul li a { + padding: 13px 10px; +} +} +@media (max-width:767px){ +.node-type-partner-programs a.button { + white-space: normal; +} +section.partner_program_section ul.items li { + padding: 50px 56px 50px !important; + width: 450px !important; + margin-left: 0 !important; +} +section.partner_announcements_section ul.items li { + width: 100%; + margin: 20px 0 0 0; + padding: 20px 0 0 0; +} +section.partner_announcements_section ul.items li+li { + border-left: none; + border-top: 1px solid #B7B7B7; +} +section.strategic_alliances_section .strategic_alliances_tabs ul li { + display: inline-block; + max-width: 50%; + display: inline-block; + margin: -3.5px; +} +.node-type-partner-programs div.heronav_section ul li { + font-size: 13px; + margin: 5px 0px; +} +.node-type-partner-programs div.heronav_section ul li a { + padding: 12px; +} +} +@media (max-width:510px){ +section.partner_program_section ul.items li{ + width: 100% !important; + padding: 30px 20px 30px !important; +} +section.strategic_alliances_section .strategic_alliances_tabs ul li { + max-width: 100%; +} +} +/*========== End Partner Programs Pages ==========*/ +/*========== curated_snippet Pages ==========*/ +.curated_snippet_section{ + padding-top: 60px; + padding-bottom: 60px; + text-align: center; + -webkit-font-smoothing: antialiased; +} +.curated_snippet_section h2{ + margin-bottom: 25px; + font-size: 44px; +} +.curated_snippet_section .container>p{ + font-size: 20px; + margin-bottom: 30px; +} +.curated_snippet_section ul{ + list-style: none; + display: block; + padding: 0; + margin: 0; + overflow: hidden; +} +.curated_snippet_section ul li{ + text-align: center; + clear: none !important; + padding: 20px 15px 20px; + display: block; + float: left; +} +.curated_snippet_section ul li h3{ + margin-bottom: 15px; + line-height: 24px; + text-transform: capitalize; +} +.curated_snippet_section ul li h3 small{ + font-size: 18px; + color: #959798; + display: block; + margin-top: 5px; + line-height: 26px; +} +.curated_snippet_section ul li p{ + font-size: 16px; +} +/*========== End curated_snippet Pages ==========*/ \ No newline at end of file diff --git a/Webseiten/Docker - Build, Ship, and Run Any App, Anywhere_files/big_data_blue_icon.svg b/Webseiten/Docker - Build, Ship, and Run Any App, Anywhere_files/big_data_blue_icon.svg new file mode 100644 index 0000000..b89508a --- /dev/null +++ b/Webseiten/Docker - Build, Ship, and Run Any App, Anywhere_files/big_data_blue_icon.svg @@ -0,0 +1,27 @@ + + + + + + diff --git a/Webseiten/Docker - Build, Ship, and Run Any App, Anywhere_files/bootstrap.min.css b/Webseiten/Docker - Build, Ship, and Run Any App, Anywhere_files/bootstrap.min.css new file mode 100644 index 0000000..99f3fc0 --- /dev/null +++ b/Webseiten/Docker - Build, Ship, and Run Any App, Anywhere_files/bootstrap.min.css @@ -0,0 +1,14 @@ +/*! + * Bootstrap v3.3.5 (http://getbootstrap.com) + * Copyright 2011-2015 Twitter, Inc. + * Licensed under MIT (https://github.com/twbs/bootstrap/blob/master/LICENSE) + */ + +/*! + * Generated using the Bootstrap Customizer (http://getbootstrap.com/customize/?id=16e68b741b5a0f146a4d) + * Config saved to config.json and https://gist.github.com/16e68b741b5a0f146a4d + *//*! + * Bootstrap v3.3.5 (http://getbootstrap.com) + * Copyright 2011-2015 Twitter, Inc. + * Licensed under MIT (https://github.com/twbs/bootstrap/blob/master/LICENSE) + *//*! normalize.css v3.0.3 | MIT License | github.com/necolas/normalize.css */html{font-family:sans-serif;-ms-text-size-adjust:100%;-webkit-text-size-adjust:100%}body{margin:0}article,aside,details,figcaption,figure,footer,header,hgroup,main,menu,nav,section,summary{display:block}audio,canvas,progress,video{display:inline-block;vertical-align:baseline}audio:not([controls]){display:none;height:0}[hidden],template{display:none}a{background-color:transparent}a:active,a:hover{outline:0}abbr[title]{border-bottom:1px dotted}b,strong{font-weight:bold}dfn{font-style:italic}h1{font-size:2em;margin:0.67em 0}mark{background:#ff0;color:#000}small{font-size:80%}sub,sup{font-size:75%;line-height:0;position:relative;vertical-align:baseline}sup{top:-0.5em}sub{bottom:-0.25em}img{border:0}svg:not(:root){overflow:hidden}figure{margin:1em 40px}hr{-webkit-box-sizing:content-box;-moz-box-sizing:content-box;box-sizing:content-box;height:0}pre{overflow:auto}code,kbd,pre,samp{font-family:monospace, monospace;font-size:1em}button,input,optgroup,select,textarea{color:inherit;font:inherit;margin:0}button{overflow:visible}button,select{text-transform:none}button,html input[type="button"],input[type="reset"],input[type="submit"]{-webkit-appearance:button;cursor:pointer}button[disabled],html input[disabled]{cursor:default}button::-moz-focus-inner,input::-moz-focus-inner{border:0;padding:0}input{line-height:normal}input[type="checkbox"],input[type="radio"]{-webkit-box-sizing:border-box;-moz-box-sizing:border-box;box-sizing:border-box;padding:0}input[type="number"]::-webkit-inner-spin-button,input[type="number"]::-webkit-outer-spin-button{height:auto}input[type="search"]{-webkit-appearance:textfield;-webkit-box-sizing:content-box;-moz-box-sizing:content-box;box-sizing:content-box}input[type="search"]::-webkit-search-cancel-button,input[type="search"]::-webkit-search-decoration{-webkit-appearance:none}fieldset{border:1px solid #c0c0c0;margin:0 2px;padding:0.35em 0.625em 0.75em}legend{border:0;padding:0}textarea{overflow:auto}optgroup{font-weight:bold}table{border-collapse:collapse;border-spacing:0}td,th{padding:0}/*! Source: https://github.com/h5bp/html5-boilerplate/blob/master/src/css/main.css */@media print{*,*:before,*:after{background:transparent !important;color:#000 !important;-webkit-box-shadow:none !important;box-shadow:none !important;text-shadow:none !important}a,a:visited{text-decoration:underline}a[href]:after{content:" (" attr(href) ")"}abbr[title]:after{content:" (" attr(title) ")"}a[href^="#"]:after,a[href^="javascript:"]:after{content:""}pre,blockquote{border:1px solid #999;page-break-inside:avoid}thead{display:table-header-group}tr,img{page-break-inside:avoid}img{max-width:100% !important}p,h2,h3{orphans:3;widows:3}h2,h3{page-break-after:avoid}.navbar{display:none}.btn>.caret,.dropup>.btn>.caret{border-top-color:#000 !important}.label{border:1px solid #000}.table{border-collapse:collapse !important}.table td,.table th{background-color:#fff !important}.table-bordered th,.table-bordered td{border:1px solid #ddd !important}}@font-face{font-family:'Glyphicons Halflings';src:url('../fonts/glyphicons-halflings-regular.eot');src:url('../fonts/glyphicons-halflings-regular.eot?#iefix') format('embedded-opentype'),url('../fonts/glyphicons-halflings-regular.woff2') format('woff2'),url('../fonts/glyphicons-halflings-regular.woff') format('woff'),url('../fonts/glyphicons-halflings-regular.ttf') format('truetype'),url('../fonts/glyphicons-halflings-regular.svg#glyphicons_halflingsregular') format('svg')}.glyphicon{position:relative;top:1px;display:inline-block;font-family:'Glyphicons Halflings';font-style:normal;font-weight:normal;line-height:1;-webkit-font-smoothing:antialiased;-moz-osx-font-smoothing:grayscale}.glyphicon-asterisk:before{content:"\2a"}.glyphicon-plus:before{content:"\2b"}.glyphicon-euro:before,.glyphicon-eur:before{content:"\20ac"}.glyphicon-minus:before{content:"\2212"}.glyphicon-cloud:before{content:"\2601"}.glyphicon-envelope:before{content:"\2709"}.glyphicon-pencil:before{content:"\270f"}.glyphicon-glass:before{content:"\e001"}.glyphicon-music:before{content:"\e002"}.glyphicon-search:before{content:"\e003"}.glyphicon-heart:before{content:"\e005"}.glyphicon-star:before{content:"\e006"}.glyphicon-star-empty:before{content:"\e007"}.glyphicon-user:before{content:"\e008"}.glyphicon-film:before{content:"\e009"}.glyphicon-th-large:before{content:"\e010"}.glyphicon-th:before{content:"\e011"}.glyphicon-th-list:before{content:"\e012"}.glyphicon-ok:before{content:"\e013"}.glyphicon-remove:before{content:"\e014"}.glyphicon-zoom-in:before{content:"\e015"}.glyphicon-zoom-out:before{content:"\e016"}.glyphicon-off:before{content:"\e017"}.glyphicon-signal:before{content:"\e018"}.glyphicon-cog:before{content:"\e019"}.glyphicon-trash:before{content:"\e020"}.glyphicon-home:before{content:"\e021"}.glyphicon-file:before{content:"\e022"}.glyphicon-time:before{content:"\e023"}.glyphicon-road:before{content:"\e024"}.glyphicon-download-alt:before{content:"\e025"}.glyphicon-download:before{content:"\e026"}.glyphicon-upload:before{content:"\e027"}.glyphicon-inbox:before{content:"\e028"}.glyphicon-play-circle:before{content:"\e029"}.glyphicon-repeat:before{content:"\e030"}.glyphicon-refresh:before{content:"\e031"}.glyphicon-list-alt:before{content:"\e032"}.glyphicon-lock:before{content:"\e033"}.glyphicon-flag:before{content:"\e034"}.glyphicon-headphones:before{content:"\e035"}.glyphicon-volume-off:before{content:"\e036"}.glyphicon-volume-down:before{content:"\e037"}.glyphicon-volume-up:before{content:"\e038"}.glyphicon-qrcode:before{content:"\e039"}.glyphicon-barcode:before{content:"\e040"}.glyphicon-tag:before{content:"\e041"}.glyphicon-tags:before{content:"\e042"}.glyphicon-book:before{content:"\e043"}.glyphicon-bookmark:before{content:"\e044"}.glyphicon-print:before{content:"\e045"}.glyphicon-camera:before{content:"\e046"}.glyphicon-font:before{content:"\e047"}.glyphicon-bold:before{content:"\e048"}.glyphicon-italic:before{content:"\e049"}.glyphicon-text-height:before{content:"\e050"}.glyphicon-text-width:before{content:"\e051"}.glyphicon-align-left:before{content:"\e052"}.glyphicon-align-center:before{content:"\e053"}.glyphicon-align-right:before{content:"\e054"}.glyphicon-align-justify:before{content:"\e055"}.glyphicon-list:before{content:"\e056"}.glyphicon-indent-left:before{content:"\e057"}.glyphicon-indent-right:before{content:"\e058"}.glyphicon-facetime-video:before{content:"\e059"}.glyphicon-picture:before{content:"\e060"}.glyphicon-map-marker:before{content:"\e062"}.glyphicon-adjust:before{content:"\e063"}.glyphicon-tint:before{content:"\e064"}.glyphicon-edit:before{content:"\e065"}.glyphicon-share:before{content:"\e066"}.glyphicon-check:before{content:"\e067"}.glyphicon-move:before{content:"\e068"}.glyphicon-step-backward:before{content:"\e069"}.glyphicon-fast-backward:before{content:"\e070"}.glyphicon-backward:before{content:"\e071"}.glyphicon-play:before{content:"\e072"}.glyphicon-pause:before{content:"\e073"}.glyphicon-stop:before{content:"\e074"}.glyphicon-forward:before{content:"\e075"}.glyphicon-fast-forward:before{content:"\e076"}.glyphicon-step-forward:before{content:"\e077"}.glyphicon-eject:before{content:"\e078"}.glyphicon-chevron-left:before{content:"\e079"}.glyphicon-chevron-right:before{content:"\e080"}.glyphicon-plus-sign:before{content:"\e081"}.glyphicon-minus-sign:before{content:"\e082"}.glyphicon-remove-sign:before{content:"\e083"}.glyphicon-ok-sign:before{content:"\e084"}.glyphicon-question-sign:before{content:"\e085"}.glyphicon-info-sign:before{content:"\e086"}.glyphicon-screenshot:before{content:"\e087"}.glyphicon-remove-circle:before{content:"\e088"}.glyphicon-ok-circle:before{content:"\e089"}.glyphicon-ban-circle:before{content:"\e090"}.glyphicon-arrow-left:before{content:"\e091"}.glyphicon-arrow-right:before{content:"\e092"}.glyphicon-arrow-up:before{content:"\e093"}.glyphicon-arrow-down:before{content:"\e094"}.glyphicon-share-alt:before{content:"\e095"}.glyphicon-resize-full:before{content:"\e096"}.glyphicon-resize-small:before{content:"\e097"}.glyphicon-exclamation-sign:before{content:"\e101"}.glyphicon-gift:before{content:"\e102"}.glyphicon-leaf:before{content:"\e103"}.glyphicon-fire:before{content:"\e104"}.glyphicon-eye-open:before{content:"\e105"}.glyphicon-eye-close:before{content:"\e106"}.glyphicon-warning-sign:before{content:"\e107"}.glyphicon-plane:before{content:"\e108"}.glyphicon-calendar:before{content:"\e109"}.glyphicon-random:before{content:"\e110"}.glyphicon-comment:before{content:"\e111"}.glyphicon-magnet:before{content:"\e112"}.glyphicon-chevron-up:before{content:"\e113"}.glyphicon-chevron-down:before{content:"\e114"}.glyphicon-retweet:before{content:"\e115"}.glyphicon-shopping-cart:before{content:"\e116"}.glyphicon-folder-close:before{content:"\e117"}.glyphicon-folder-open:before{content:"\e118"}.glyphicon-resize-vertical:before{content:"\e119"}.glyphicon-resize-horizontal:before{content:"\e120"}.glyphicon-hdd:before{content:"\e121"}.glyphicon-bullhorn:before{content:"\e122"}.glyphicon-bell:before{content:"\e123"}.glyphicon-certificate:before{content:"\e124"}.glyphicon-thumbs-up:before{content:"\e125"}.glyphicon-thumbs-down:before{content:"\e126"}.glyphicon-hand-right:before{content:"\e127"}.glyphicon-hand-left:before{content:"\e128"}.glyphicon-hand-up:before{content:"\e129"}.glyphicon-hand-down:before{content:"\e130"}.glyphicon-circle-arrow-right:before{content:"\e131"}.glyphicon-circle-arrow-left:before{content:"\e132"}.glyphicon-circle-arrow-up:before{content:"\e133"}.glyphicon-circle-arrow-down:before{content:"\e134"}.glyphicon-globe:before{content:"\e135"}.glyphicon-wrench:before{content:"\e136"}.glyphicon-tasks:before{content:"\e137"}.glyphicon-filter:before{content:"\e138"}.glyphicon-briefcase:before{content:"\e139"}.glyphicon-fullscreen:before{content:"\e140"}.glyphicon-dashboard:before{content:"\e141"}.glyphicon-paperclip:before{content:"\e142"}.glyphicon-heart-empty:before{content:"\e143"}.glyphicon-link:before{content:"\e144"}.glyphicon-phone:before{content:"\e145"}.glyphicon-pushpin:before{content:"\e146"}.glyphicon-usd:before{content:"\e148"}.glyphicon-gbp:before{content:"\e149"}.glyphicon-sort:before{content:"\e150"}.glyphicon-sort-by-alphabet:before{content:"\e151"}.glyphicon-sort-by-alphabet-alt:before{content:"\e152"}.glyphicon-sort-by-order:before{content:"\e153"}.glyphicon-sort-by-order-alt:before{content:"\e154"}.glyphicon-sort-by-attributes:before{content:"\e155"}.glyphicon-sort-by-attributes-alt:before{content:"\e156"}.glyphicon-unchecked:before{content:"\e157"}.glyphicon-expand:before{content:"\e158"}.glyphicon-collapse-down:before{content:"\e159"}.glyphicon-collapse-up:before{content:"\e160"}.glyphicon-log-in:before{content:"\e161"}.glyphicon-flash:before{content:"\e162"}.glyphicon-log-out:before{content:"\e163"}.glyphicon-new-window:before{content:"\e164"}.glyphicon-record:before{content:"\e165"}.glyphicon-save:before{content:"\e166"}.glyphicon-open:before{content:"\e167"}.glyphicon-saved:before{content:"\e168"}.glyphicon-import:before{content:"\e169"}.glyphicon-export:before{content:"\e170"}.glyphicon-send:before{content:"\e171"}.glyphicon-floppy-disk:before{content:"\e172"}.glyphicon-floppy-saved:before{content:"\e173"}.glyphicon-floppy-remove:before{content:"\e174"}.glyphicon-floppy-save:before{content:"\e175"}.glyphicon-floppy-open:before{content:"\e176"}.glyphicon-credit-card:before{content:"\e177"}.glyphicon-transfer:before{content:"\e178"}.glyphicon-cutlery:before{content:"\e179"}.glyphicon-header:before{content:"\e180"}.glyphicon-compressed:before{content:"\e181"}.glyphicon-earphone:before{content:"\e182"}.glyphicon-phone-alt:before{content:"\e183"}.glyphicon-tower:before{content:"\e184"}.glyphicon-stats:before{content:"\e185"}.glyphicon-sd-video:before{content:"\e186"}.glyphicon-hd-video:before{content:"\e187"}.glyphicon-subtitles:before{content:"\e188"}.glyphicon-sound-stereo:before{content:"\e189"}.glyphicon-sound-dolby:before{content:"\e190"}.glyphicon-sound-5-1:before{content:"\e191"}.glyphicon-sound-6-1:before{content:"\e192"}.glyphicon-sound-7-1:before{content:"\e193"}.glyphicon-copyright-mark:before{content:"\e194"}.glyphicon-registration-mark:before{content:"\e195"}.glyphicon-cloud-download:before{content:"\e197"}.glyphicon-cloud-upload:before{content:"\e198"}.glyphicon-tree-conifer:before{content:"\e199"}.glyphicon-tree-deciduous:before{content:"\e200"}.glyphicon-cd:before{content:"\e201"}.glyphicon-save-file:before{content:"\e202"}.glyphicon-open-file:before{content:"\e203"}.glyphicon-level-up:before{content:"\e204"}.glyphicon-copy:before{content:"\e205"}.glyphicon-paste:before{content:"\e206"}.glyphicon-alert:before{content:"\e209"}.glyphicon-equalizer:before{content:"\e210"}.glyphicon-king:before{content:"\e211"}.glyphicon-queen:before{content:"\e212"}.glyphicon-pawn:before{content:"\e213"}.glyphicon-bishop:before{content:"\e214"}.glyphicon-knight:before{content:"\e215"}.glyphicon-baby-formula:before{content:"\e216"}.glyphicon-tent:before{content:"\26fa"}.glyphicon-blackboard:before{content:"\e218"}.glyphicon-bed:before{content:"\e219"}.glyphicon-apple:before{content:"\f8ff"}.glyphicon-erase:before{content:"\e221"}.glyphicon-hourglass:before{content:"\231b"}.glyphicon-lamp:before{content:"\e223"}.glyphicon-duplicate:before{content:"\e224"}.glyphicon-piggy-bank:before{content:"\e225"}.glyphicon-scissors:before{content:"\e226"}.glyphicon-bitcoin:before{content:"\e227"}.glyphicon-btc:before{content:"\e227"}.glyphicon-xbt:before{content:"\e227"}.glyphicon-yen:before{content:"\00a5"}.glyphicon-jpy:before{content:"\00a5"}.glyphicon-ruble:before{content:"\20bd"}.glyphicon-rub:before{content:"\20bd"}.glyphicon-scale:before{content:"\e230"}.glyphicon-ice-lolly:before{content:"\e231"}.glyphicon-ice-lolly-tasted:before{content:"\e232"}.glyphicon-education:before{content:"\e233"}.glyphicon-option-horizontal:before{content:"\e234"}.glyphicon-option-vertical:before{content:"\e235"}.glyphicon-menu-hamburger:before{content:"\e236"}.glyphicon-modal-window:before{content:"\e237"}.glyphicon-oil:before{content:"\e238"}.glyphicon-grain:before{content:"\e239"}.glyphicon-sunglasses:before{content:"\e240"}.glyphicon-text-size:before{content:"\e241"}.glyphicon-text-color:before{content:"\e242"}.glyphicon-text-background:before{content:"\e243"}.glyphicon-object-align-top:before{content:"\e244"}.glyphicon-object-align-bottom:before{content:"\e245"}.glyphicon-object-align-horizontal:before{content:"\e246"}.glyphicon-object-align-left:before{content:"\e247"}.glyphicon-object-align-vertical:before{content:"\e248"}.glyphicon-object-align-right:before{content:"\e249"}.glyphicon-triangle-right:before{content:"\e250"}.glyphicon-triangle-left:before{content:"\e251"}.glyphicon-triangle-bottom:before{content:"\e252"}.glyphicon-triangle-top:before{content:"\e253"}.glyphicon-console:before{content:"\e254"}.glyphicon-superscript:before{content:"\e255"}.glyphicon-subscript:before{content:"\e256"}.glyphicon-menu-left:before{content:"\e257"}.glyphicon-menu-right:before{content:"\e258"}.glyphicon-menu-down:before{content:"\e259"}.glyphicon-menu-up:before{content:"\e260"}*{-webkit-box-sizing:border-box;-moz-box-sizing:border-box;box-sizing:border-box}*:before,*:after{-webkit-box-sizing:border-box;-moz-box-sizing:border-box;box-sizing:border-box}html{font-size:10px;-webkit-tap-highlight-color:rgba(0,0,0,0)}body{font-family:"Helvetica Neue",Helvetica,Arial,sans-serif;font-size:14px;line-height:1.42857143;color:#333;background-color:#fff}input,button,select,textarea{font-family:inherit;font-size:inherit;line-height:inherit}a{color:#337ab7;text-decoration:none}a:hover,a:focus{color:#23527c;text-decoration:underline}a:focus{outline:thin dotted;outline:5px auto -webkit-focus-ring-color;outline-offset:-2px}figure{margin:0}img{vertical-align:middle}.img-responsive,.thumbnail>img,.thumbnail a>img,.carousel-inner>.item>img,.carousel-inner>.item>a>img{display:block;max-width:100%;height:auto}.img-rounded{border-radius:6px}.img-thumbnail{padding:4px;line-height:1.42857143;background-color:#fff;border:1px solid #ddd;border-radius:4px;-webkit-transition:all .2s ease-in-out;-o-transition:all .2s ease-in-out;transition:all .2s ease-in-out;display:inline-block;max-width:100%;height:auto}.img-circle{border-radius:50%}hr{margin-top:20px;margin-bottom:20px;border:0;border-top:1px solid #eee}.sr-only{position:absolute;width:1px;height:1px;margin:-1px;padding:0;overflow:hidden;clip:rect(0, 0, 0, 0);border:0}.sr-only-focusable:active,.sr-only-focusable:focus{position:static;width:auto;height:auto;margin:0;overflow:visible;clip:auto}[role="button"]{cursor:pointer}h1,h2,h3,h4,h5,h6,.h1,.h2,.h3,.h4,.h5,.h6{font-family:inherit;font-weight:500;line-height:1.1;color:inherit}h1 small,h2 small,h3 small,h4 small,h5 small,h6 small,.h1 small,.h2 small,.h3 small,.h4 small,.h5 small,.h6 small,h1 .small,h2 .small,h3 .small,h4 .small,h5 .small,h6 .small,.h1 .small,.h2 .small,.h3 .small,.h4 .small,.h5 .small,.h6 .small{font-weight:normal;line-height:1;color:#777}h1,.h1,h2,.h2,h3,.h3{margin-top:20px;margin-bottom:10px}h1 small,.h1 small,h2 small,.h2 small,h3 small,.h3 small,h1 .small,.h1 .small,h2 .small,.h2 .small,h3 .small,.h3 .small{font-size:65%}h4,.h4,h5,.h5,h6,.h6{margin-top:10px;margin-bottom:10px}h4 small,.h4 small,h5 small,.h5 small,h6 small,.h6 small,h4 .small,.h4 .small,h5 .small,.h5 .small,h6 .small,.h6 .small{font-size:75%}h1,.h1{font-size:36px}h2,.h2{font-size:30px}h3,.h3{font-size:24px}h4,.h4{font-size:18px}h5,.h5{font-size:14px}h6,.h6{font-size:12px}p{margin:0 0 10px}.lead{margin-bottom:20px;font-size:16px;font-weight:300;line-height:1.4}@media (min-width:768px){.lead{font-size:21px}}small,.small{font-size:85%}mark,.mark{background-color:#fcf8e3;padding:.2em}.text-left{text-align:left}.text-right{text-align:right}.text-center{text-align:center}.text-justify{text-align:justify}.text-nowrap{white-space:nowrap}.text-lowercase{text-transform:lowercase}.text-uppercase{text-transform:uppercase}.text-capitalize{text-transform:capitalize}.text-muted{color:#777}.text-primary{color:#337ab7}a.text-primary:hover,a.text-primary:focus{color:#286090}.text-success{color:#3c763d}a.text-success:hover,a.text-success:focus{color:#2b542c}.text-info{color:#31708f}a.text-info:hover,a.text-info:focus{color:#245269}.text-warning{color:#8a6d3b}a.text-warning:hover,a.text-warning:focus{color:#66512c}.text-danger{color:#a94442}a.text-danger:hover,a.text-danger:focus{color:#843534}.bg-primary{color:#fff;background-color:#337ab7}a.bg-primary:hover,a.bg-primary:focus{background-color:#286090}.bg-success{background-color:#dff0d8}a.bg-success:hover,a.bg-success:focus{background-color:#c1e2b3}.bg-info{background-color:#d9edf7}a.bg-info:hover,a.bg-info:focus{background-color:#afd9ee}.bg-warning{background-color:#fcf8e3}a.bg-warning:hover,a.bg-warning:focus{background-color:#f7ecb5}.bg-danger{background-color:#f2dede}a.bg-danger:hover,a.bg-danger:focus{background-color:#e4b9b9}.page-header{padding-bottom:9px;margin:40px 0 20px;border-bottom:1px solid #eee}ul,ol{margin-top:0;margin-bottom:10px}ul ul,ol ul,ul ol,ol ol{margin-bottom:0}.list-unstyled{padding-left:0;list-style:none}.list-inline{padding-left:0;list-style:none;margin-left:-5px}.list-inline>li{display:inline-block;padding-left:5px;padding-right:5px}dl{margin-top:0;margin-bottom:20px}dt,dd{line-height:1.42857143}dt{font-weight:bold}dd{margin-left:0}@media (min-width:768px){.dl-horizontal dt{float:left;width:160px;clear:left;text-align:right;overflow:hidden;text-overflow:ellipsis;white-space:nowrap}.dl-horizontal dd{margin-left:180px}}abbr[title],abbr[data-original-title]{cursor:help;border-bottom:1px dotted #777}.initialism{font-size:90%;text-transform:uppercase}blockquote{padding:10px 20px;margin:0 0 20px;font-size:17.5px;border-left:5px solid #eee}blockquote p:last-child,blockquote ul:last-child,blockquote ol:last-child{margin-bottom:0}blockquote footer,blockquote small,blockquote .small{display:block;font-size:80%;line-height:1.42857143;color:#777}blockquote footer:before,blockquote small:before,blockquote .small:before{content:'\2014 \00A0'}.blockquote-reverse,blockquote.pull-right{padding-right:15px;padding-left:0;border-right:5px solid #eee;border-left:0;text-align:right}.blockquote-reverse footer:before,blockquote.pull-right footer:before,.blockquote-reverse small:before,blockquote.pull-right small:before,.blockquote-reverse .small:before,blockquote.pull-right .small:before{content:''}.blockquote-reverse footer:after,blockquote.pull-right footer:after,.blockquote-reverse small:after,blockquote.pull-right small:after,.blockquote-reverse .small:after,blockquote.pull-right .small:after{content:'\00A0 \2014'}address{margin-bottom:20px;font-style:normal;line-height:1.42857143}code,kbd,pre,samp{font-family:Menlo,Monaco,Consolas,"Courier New",monospace}code{padding:2px 4px;font-size:90%;color:#c7254e;background-color:#f9f2f4;border-radius:4px}kbd{padding:2px 4px;font-size:90%;color:#fff;background-color:#333;border-radius:3px;-webkit-box-shadow:inset 0 -1px 0 rgba(0,0,0,0.25);box-shadow:inset 0 -1px 0 rgba(0,0,0,0.25)}kbd kbd{padding:0;font-size:100%;font-weight:bold;-webkit-box-shadow:none;box-shadow:none}pre{display:block;padding:9.5px;margin:0 0 10px;font-size:13px;line-height:1.42857143;word-break:break-all;word-wrap:break-word;color:#333;background-color:#f5f5f5;border:1px solid #ccc;border-radius:4px}pre code{padding:0;font-size:inherit;color:inherit;white-space:pre-wrap;background-color:transparent;border-radius:0}.pre-scrollable{max-height:340px;overflow-y:scroll}.container{margin-right:auto;margin-left:auto;padding-left:15px;padding-right:15px}@media (min-width:768px){.container{width:750px}}@media (min-width:992px){.container{width:970px}}@media (min-width:1200px){.container{width:1170px}}.container-fluid{margin-right:auto;margin-left:auto;padding-left:15px;padding-right:15px}.row{margin-left:-15px;margin-right:-15px}.col-xs-1, .col-sm-1, .col-md-1, .col-lg-1, .col-xs-2, .col-sm-2, .col-md-2, .col-lg-2, .col-xs-3, .col-sm-3, .col-md-3, .col-lg-3, .col-xs-4, .col-sm-4, .col-md-4, .col-lg-4, .col-xs-5, .col-sm-5, .col-md-5, .col-lg-5, .col-xs-6, .col-sm-6, .col-md-6, .col-lg-6, .col-xs-7, .col-sm-7, .col-md-7, .col-lg-7, .col-xs-8, .col-sm-8, .col-md-8, .col-lg-8, .col-xs-9, .col-sm-9, .col-md-9, .col-lg-9, .col-xs-10, .col-sm-10, .col-md-10, .col-lg-10, .col-xs-11, .col-sm-11, .col-md-11, .col-lg-11, .col-xs-12, .col-sm-12, .col-md-12, .col-lg-12{position:relative;min-height:1px;padding-left:15px;padding-right:15px}.col-xs-1, .col-xs-2, .col-xs-3, .col-xs-4, .col-xs-5, .col-xs-6, .col-xs-7, .col-xs-8, .col-xs-9, .col-xs-10, .col-xs-11, .col-xs-12{float:left}.col-xs-12{width:100%}.col-xs-11{width:91.66666667%}.col-xs-10{width:83.33333333%}.col-xs-9{width:75%}.col-xs-8{width:66.66666667%}.col-xs-7{width:58.33333333%}.col-xs-6{width:50%}.col-xs-5{width:41.66666667%}.col-xs-4{width:33.33333333%}.col-xs-3{width:25%}.col-xs-2{width:16.66666667%}.col-xs-1{width:8.33333333%}.col-xs-pull-12{right:100%}.col-xs-pull-11{right:91.66666667%}.col-xs-pull-10{right:83.33333333%}.col-xs-pull-9{right:75%}.col-xs-pull-8{right:66.66666667%}.col-xs-pull-7{right:58.33333333%}.col-xs-pull-6{right:50%}.col-xs-pull-5{right:41.66666667%}.col-xs-pull-4{right:33.33333333%}.col-xs-pull-3{right:25%}.col-xs-pull-2{right:16.66666667%}.col-xs-pull-1{right:8.33333333%}.col-xs-pull-0{right:auto}.col-xs-push-12{left:100%}.col-xs-push-11{left:91.66666667%}.col-xs-push-10{left:83.33333333%}.col-xs-push-9{left:75%}.col-xs-push-8{left:66.66666667%}.col-xs-push-7{left:58.33333333%}.col-xs-push-6{left:50%}.col-xs-push-5{left:41.66666667%}.col-xs-push-4{left:33.33333333%}.col-xs-push-3{left:25%}.col-xs-push-2{left:16.66666667%}.col-xs-push-1{left:8.33333333%}.col-xs-push-0{left:auto}.col-xs-offset-12{margin-left:100%}.col-xs-offset-11{margin-left:91.66666667%}.col-xs-offset-10{margin-left:83.33333333%}.col-xs-offset-9{margin-left:75%}.col-xs-offset-8{margin-left:66.66666667%}.col-xs-offset-7{margin-left:58.33333333%}.col-xs-offset-6{margin-left:50%}.col-xs-offset-5{margin-left:41.66666667%}.col-xs-offset-4{margin-left:33.33333333%}.col-xs-offset-3{margin-left:25%}.col-xs-offset-2{margin-left:16.66666667%}.col-xs-offset-1{margin-left:8.33333333%}.col-xs-offset-0{margin-left:0}@media (min-width:768px){.col-sm-1, .col-sm-2, .col-sm-3, .col-sm-4, .col-sm-5, .col-sm-6, .col-sm-7, .col-sm-8, .col-sm-9, .col-sm-10, .col-sm-11, .col-sm-12{float:left}.col-sm-12{width:100%}.col-sm-11{width:91.66666667%}.col-sm-10{width:83.33333333%}.col-sm-9{width:75%}.col-sm-8{width:66.66666667%}.col-sm-7{width:58.33333333%}.col-sm-6{width:50%}.col-sm-5{width:41.66666667%}.col-sm-4{width:33.33333333%}.col-sm-3{width:25%}.col-sm-2{width:16.66666667%}.col-sm-1{width:8.33333333%}.col-sm-pull-12{right:100%}.col-sm-pull-11{right:91.66666667%}.col-sm-pull-10{right:83.33333333%}.col-sm-pull-9{right:75%}.col-sm-pull-8{right:66.66666667%}.col-sm-pull-7{right:58.33333333%}.col-sm-pull-6{right:50%}.col-sm-pull-5{right:41.66666667%}.col-sm-pull-4{right:33.33333333%}.col-sm-pull-3{right:25%}.col-sm-pull-2{right:16.66666667%}.col-sm-pull-1{right:8.33333333%}.col-sm-pull-0{right:auto}.col-sm-push-12{left:100%}.col-sm-push-11{left:91.66666667%}.col-sm-push-10{left:83.33333333%}.col-sm-push-9{left:75%}.col-sm-push-8{left:66.66666667%}.col-sm-push-7{left:58.33333333%}.col-sm-push-6{left:50%}.col-sm-push-5{left:41.66666667%}.col-sm-push-4{left:33.33333333%}.col-sm-push-3{left:25%}.col-sm-push-2{left:16.66666667%}.col-sm-push-1{left:8.33333333%}.col-sm-push-0{left:auto}.col-sm-offset-12{margin-left:100%}.col-sm-offset-11{margin-left:91.66666667%}.col-sm-offset-10{margin-left:83.33333333%}.col-sm-offset-9{margin-left:75%}.col-sm-offset-8{margin-left:66.66666667%}.col-sm-offset-7{margin-left:58.33333333%}.col-sm-offset-6{margin-left:50%}.col-sm-offset-5{margin-left:41.66666667%}.col-sm-offset-4{margin-left:33.33333333%}.col-sm-offset-3{margin-left:25%}.col-sm-offset-2{margin-left:16.66666667%}.col-sm-offset-1{margin-left:8.33333333%}.col-sm-offset-0{margin-left:0}}@media (min-width:992px){.col-md-1, .col-md-2, .col-md-3, .col-md-4, .col-md-5, .col-md-6, .col-md-7, .col-md-8, .col-md-9, .col-md-10, .col-md-11, .col-md-12{float:left}.col-md-12{width:100%}.col-md-11{width:91.66666667%}.col-md-10{width:83.33333333%}.col-md-9{width:75%}.col-md-8{width:66.66666667%}.col-md-7{width:58.33333333%}.col-md-6{width:50%}.col-md-5{width:41.66666667%}.col-md-4{width:33.33333333%}.col-md-3{width:25%}.col-md-2{width:16.66666667%}.col-md-1{width:8.33333333%}.col-md-pull-12{right:100%}.col-md-pull-11{right:91.66666667%}.col-md-pull-10{right:83.33333333%}.col-md-pull-9{right:75%}.col-md-pull-8{right:66.66666667%}.col-md-pull-7{right:58.33333333%}.col-md-pull-6{right:50%}.col-md-pull-5{right:41.66666667%}.col-md-pull-4{right:33.33333333%}.col-md-pull-3{right:25%}.col-md-pull-2{right:16.66666667%}.col-md-pull-1{right:8.33333333%}.col-md-pull-0{right:auto}.col-md-push-12{left:100%}.col-md-push-11{left:91.66666667%}.col-md-push-10{left:83.33333333%}.col-md-push-9{left:75%}.col-md-push-8{left:66.66666667%}.col-md-push-7{left:58.33333333%}.col-md-push-6{left:50%}.col-md-push-5{left:41.66666667%}.col-md-push-4{left:33.33333333%}.col-md-push-3{left:25%}.col-md-push-2{left:16.66666667%}.col-md-push-1{left:8.33333333%}.col-md-push-0{left:auto}.col-md-offset-12{margin-left:100%}.col-md-offset-11{margin-left:91.66666667%}.col-md-offset-10{margin-left:83.33333333%}.col-md-offset-9{margin-left:75%}.col-md-offset-8{margin-left:66.66666667%}.col-md-offset-7{margin-left:58.33333333%}.col-md-offset-6{margin-left:50%}.col-md-offset-5{margin-left:41.66666667%}.col-md-offset-4{margin-left:33.33333333%}.col-md-offset-3{margin-left:25%}.col-md-offset-2{margin-left:16.66666667%}.col-md-offset-1{margin-left:8.33333333%}.col-md-offset-0{margin-left:0}}@media (min-width:1200px){.col-lg-1, .col-lg-2, .col-lg-3, .col-lg-4, .col-lg-5, .col-lg-6, .col-lg-7, .col-lg-8, .col-lg-9, .col-lg-10, .col-lg-11, .col-lg-12{float:left}.col-lg-12{width:100%}.col-lg-11{width:91.66666667%}.col-lg-10{width:83.33333333%}.col-lg-9{width:75%}.col-lg-8{width:66.66666667%}.col-lg-7{width:58.33333333%}.col-lg-6{width:50%}.col-lg-5{width:41.66666667%}.col-lg-4{width:33.33333333%}.col-lg-3{width:25%}.col-lg-2{width:16.66666667%}.col-lg-1{width:8.33333333%}.col-lg-pull-12{right:100%}.col-lg-pull-11{right:91.66666667%}.col-lg-pull-10{right:83.33333333%}.col-lg-pull-9{right:75%}.col-lg-pull-8{right:66.66666667%}.col-lg-pull-7{right:58.33333333%}.col-lg-pull-6{right:50%}.col-lg-pull-5{right:41.66666667%}.col-lg-pull-4{right:33.33333333%}.col-lg-pull-3{right:25%}.col-lg-pull-2{right:16.66666667%}.col-lg-pull-1{right:8.33333333%}.col-lg-pull-0{right:auto}.col-lg-push-12{left:100%}.col-lg-push-11{left:91.66666667%}.col-lg-push-10{left:83.33333333%}.col-lg-push-9{left:75%}.col-lg-push-8{left:66.66666667%}.col-lg-push-7{left:58.33333333%}.col-lg-push-6{left:50%}.col-lg-push-5{left:41.66666667%}.col-lg-push-4{left:33.33333333%}.col-lg-push-3{left:25%}.col-lg-push-2{left:16.66666667%}.col-lg-push-1{left:8.33333333%}.col-lg-push-0{left:auto}.col-lg-offset-12{margin-left:100%}.col-lg-offset-11{margin-left:91.66666667%}.col-lg-offset-10{margin-left:83.33333333%}.col-lg-offset-9{margin-left:75%}.col-lg-offset-8{margin-left:66.66666667%}.col-lg-offset-7{margin-left:58.33333333%}.col-lg-offset-6{margin-left:50%}.col-lg-offset-5{margin-left:41.66666667%}.col-lg-offset-4{margin-left:33.33333333%}.col-lg-offset-3{margin-left:25%}.col-lg-offset-2{margin-left:16.66666667%}.col-lg-offset-1{margin-left:8.33333333%}.col-lg-offset-0{margin-left:0}}table{background-color:transparent}caption{padding-top:8px;padding-bottom:8px;color:#777;text-align:left}th{text-align:left}.table{width:100%;max-width:100%;margin-bottom:20px}.table>thead>tr>th,.table>tbody>tr>th,.table>tfoot>tr>th,.table>thead>tr>td,.table>tbody>tr>td,.table>tfoot>tr>td{padding:8px;line-height:1.42857143;vertical-align:top;border-top:1px solid #ddd}.table>thead>tr>th{vertical-align:bottom;border-bottom:2px solid #ddd}.table>caption+thead>tr:first-child>th,.table>colgroup+thead>tr:first-child>th,.table>thead:first-child>tr:first-child>th,.table>caption+thead>tr:first-child>td,.table>colgroup+thead>tr:first-child>td,.table>thead:first-child>tr:first-child>td{border-top:0}.table>tbody+tbody{border-top:2px solid #ddd}.table .table{background-color:#fff}.table-condensed>thead>tr>th,.table-condensed>tbody>tr>th,.table-condensed>tfoot>tr>th,.table-condensed>thead>tr>td,.table-condensed>tbody>tr>td,.table-condensed>tfoot>tr>td{padding:5px}.table-bordered{border:1px solid #ddd}.table-bordered>thead>tr>th,.table-bordered>tbody>tr>th,.table-bordered>tfoot>tr>th,.table-bordered>thead>tr>td,.table-bordered>tbody>tr>td,.table-bordered>tfoot>tr>td{border:1px solid #ddd}.table-bordered>thead>tr>th,.table-bordered>thead>tr>td{border-bottom-width:2px}.table-striped>tbody>tr:nth-of-type(odd){background-color:#f9f9f9}.table-hover>tbody>tr:hover{background-color:#f5f5f5}table col[class*="col-"]{position:static;float:none;display:table-column}table td[class*="col-"],table th[class*="col-"]{position:static;float:none;display:table-cell}.table>thead>tr>td.active,.table>tbody>tr>td.active,.table>tfoot>tr>td.active,.table>thead>tr>th.active,.table>tbody>tr>th.active,.table>tfoot>tr>th.active,.table>thead>tr.active>td,.table>tbody>tr.active>td,.table>tfoot>tr.active>td,.table>thead>tr.active>th,.table>tbody>tr.active>th,.table>tfoot>tr.active>th{background-color:#f5f5f5}.table-hover>tbody>tr>td.active:hover,.table-hover>tbody>tr>th.active:hover,.table-hover>tbody>tr.active:hover>td,.table-hover>tbody>tr:hover>.active,.table-hover>tbody>tr.active:hover>th{background-color:#e8e8e8}.table>thead>tr>td.success,.table>tbody>tr>td.success,.table>tfoot>tr>td.success,.table>thead>tr>th.success,.table>tbody>tr>th.success,.table>tfoot>tr>th.success,.table>thead>tr.success>td,.table>tbody>tr.success>td,.table>tfoot>tr.success>td,.table>thead>tr.success>th,.table>tbody>tr.success>th,.table>tfoot>tr.success>th{background-color:#dff0d8}.table-hover>tbody>tr>td.success:hover,.table-hover>tbody>tr>th.success:hover,.table-hover>tbody>tr.success:hover>td,.table-hover>tbody>tr:hover>.success,.table-hover>tbody>tr.success:hover>th{background-color:#d0e9c6}.table>thead>tr>td.info,.table>tbody>tr>td.info,.table>tfoot>tr>td.info,.table>thead>tr>th.info,.table>tbody>tr>th.info,.table>tfoot>tr>th.info,.table>thead>tr.info>td,.table>tbody>tr.info>td,.table>tfoot>tr.info>td,.table>thead>tr.info>th,.table>tbody>tr.info>th,.table>tfoot>tr.info>th{background-color:#d9edf7}.table-hover>tbody>tr>td.info:hover,.table-hover>tbody>tr>th.info:hover,.table-hover>tbody>tr.info:hover>td,.table-hover>tbody>tr:hover>.info,.table-hover>tbody>tr.info:hover>th{background-color:#c4e3f3}.table>thead>tr>td.warning,.table>tbody>tr>td.warning,.table>tfoot>tr>td.warning,.table>thead>tr>th.warning,.table>tbody>tr>th.warning,.table>tfoot>tr>th.warning,.table>thead>tr.warning>td,.table>tbody>tr.warning>td,.table>tfoot>tr.warning>td,.table>thead>tr.warning>th,.table>tbody>tr.warning>th,.table>tfoot>tr.warning>th{background-color:#fcf8e3}.table-hover>tbody>tr>td.warning:hover,.table-hover>tbody>tr>th.warning:hover,.table-hover>tbody>tr.warning:hover>td,.table-hover>tbody>tr:hover>.warning,.table-hover>tbody>tr.warning:hover>th{background-color:#faf2cc}.table>thead>tr>td.danger,.table>tbody>tr>td.danger,.table>tfoot>tr>td.danger,.table>thead>tr>th.danger,.table>tbody>tr>th.danger,.table>tfoot>tr>th.danger,.table>thead>tr.danger>td,.table>tbody>tr.danger>td,.table>tfoot>tr.danger>td,.table>thead>tr.danger>th,.table>tbody>tr.danger>th,.table>tfoot>tr.danger>th{background-color:#f2dede}.table-hover>tbody>tr>td.danger:hover,.table-hover>tbody>tr>th.danger:hover,.table-hover>tbody>tr.danger:hover>td,.table-hover>tbody>tr:hover>.danger,.table-hover>tbody>tr.danger:hover>th{background-color:#ebcccc}.table-responsive{overflow-x:auto;min-height:0.01%}@media screen and (max-width:767px){.table-responsive{width:100%;margin-bottom:15px;overflow-y:hidden;-ms-overflow-style:-ms-autohiding-scrollbar;border:1px solid #ddd}.table-responsive>.table{margin-bottom:0}.table-responsive>.table>thead>tr>th,.table-responsive>.table>tbody>tr>th,.table-responsive>.table>tfoot>tr>th,.table-responsive>.table>thead>tr>td,.table-responsive>.table>tbody>tr>td,.table-responsive>.table>tfoot>tr>td{white-space:nowrap}.table-responsive>.table-bordered{border:0}.table-responsive>.table-bordered>thead>tr>th:first-child,.table-responsive>.table-bordered>tbody>tr>th:first-child,.table-responsive>.table-bordered>tfoot>tr>th:first-child,.table-responsive>.table-bordered>thead>tr>td:first-child,.table-responsive>.table-bordered>tbody>tr>td:first-child,.table-responsive>.table-bordered>tfoot>tr>td:first-child{border-left:0}.table-responsive>.table-bordered>thead>tr>th:last-child,.table-responsive>.table-bordered>tbody>tr>th:last-child,.table-responsive>.table-bordered>tfoot>tr>th:last-child,.table-responsive>.table-bordered>thead>tr>td:last-child,.table-responsive>.table-bordered>tbody>tr>td:last-child,.table-responsive>.table-bordered>tfoot>tr>td:last-child{border-right:0}.table-responsive>.table-bordered>tbody>tr:last-child>th,.table-responsive>.table-bordered>tfoot>tr:last-child>th,.table-responsive>.table-bordered>tbody>tr:last-child>td,.table-responsive>.table-bordered>tfoot>tr:last-child>td{border-bottom:0}}fieldset{padding:0;margin:0;border:0;min-width:0}legend{display:block;width:100%;padding:0;margin-bottom:20px;font-size:21px;line-height:inherit;color:#333;border:0;border-bottom:1px solid #e5e5e5}label{display:inline-block;max-width:100%;margin-bottom:5px;font-weight:bold}input[type="search"]{-webkit-box-sizing:border-box;-moz-box-sizing:border-box;box-sizing:border-box}input[type="radio"],input[type="checkbox"]{margin:4px 0 0;margin-top:1px \9;line-height:normal}input[type="file"]{display:block}input[type="range"]{display:block;width:100%}select[multiple],select[size]{height:auto}input[type="file"]:focus,input[type="radio"]:focus,input[type="checkbox"]:focus{outline:thin dotted;outline:5px auto -webkit-focus-ring-color;outline-offset:-2px}output{display:block;padding-top:7px;font-size:14px;line-height:1.42857143;color:#555}.form-control{display:block;width:100%;height:34px;padding:6px 12px;font-size:14px;line-height:1.42857143;color:#555;background-color:#fff;background-image:none;border:1px solid #ccc;border-radius:4px;-webkit-box-shadow:inset 0 1px 1px rgba(0,0,0,0.075);box-shadow:inset 0 1px 1px rgba(0,0,0,0.075);-webkit-transition:border-color ease-in-out .15s, -webkit-box-shadow ease-in-out .15s;-o-transition:border-color ease-in-out .15s, box-shadow ease-in-out .15s;transition:border-color ease-in-out .15s, box-shadow ease-in-out .15s}.form-control:focus{border-color:#66afe9;outline:0;-webkit-box-shadow:inset 0 1px 1px rgba(0,0,0,.075), 0 0 8px rgba(102, 175, 233, 0.6);box-shadow:inset 0 1px 1px rgba(0,0,0,.075), 0 0 8px rgba(102, 175, 233, 0.6)}.form-control::-moz-placeholder{color:#999;opacity:1}.form-control:-ms-input-placeholder{color:#999}.form-control::-webkit-input-placeholder{color:#999}.form-control[disabled],.form-control[readonly],fieldset[disabled] .form-control{background-color:#eee;opacity:1}.form-control[disabled],fieldset[disabled] .form-control{cursor:not-allowed}textarea.form-control{height:auto}input[type="search"]{-webkit-appearance:none}@media screen and (-webkit-min-device-pixel-ratio:0){input[type="date"].form-control,input[type="time"].form-control,input[type="datetime-local"].form-control,input[type="month"].form-control{line-height:34px}input[type="date"].input-sm,input[type="time"].input-sm,input[type="datetime-local"].input-sm,input[type="month"].input-sm,.input-group-sm input[type="date"],.input-group-sm input[type="time"],.input-group-sm input[type="datetime-local"],.input-group-sm input[type="month"]{line-height:30px}input[type="date"].input-lg,input[type="time"].input-lg,input[type="datetime-local"].input-lg,input[type="month"].input-lg,.input-group-lg input[type="date"],.input-group-lg input[type="time"],.input-group-lg input[type="datetime-local"],.input-group-lg input[type="month"]{line-height:46px}}.form-group{margin-bottom:15px}.radio,.checkbox{position:relative;display:block;margin-top:10px;margin-bottom:10px}.radio label,.checkbox label{min-height:20px;padding-left:20px;margin-bottom:0;font-weight:normal;cursor:pointer}.radio input[type="radio"],.radio-inline input[type="radio"],.checkbox input[type="checkbox"],.checkbox-inline input[type="checkbox"]{position:absolute;margin-left:-20px;margin-top:4px \9}.radio+.radio,.checkbox+.checkbox{margin-top:-5px}.radio-inline,.checkbox-inline{position:relative;display:inline-block;padding-left:20px;margin-bottom:0;vertical-align:middle;font-weight:normal;cursor:pointer}.radio-inline+.radio-inline,.checkbox-inline+.checkbox-inline{margin-top:0;margin-left:10px}input[type="radio"][disabled],input[type="checkbox"][disabled],input[type="radio"].disabled,input[type="checkbox"].disabled,fieldset[disabled] input[type="radio"],fieldset[disabled] input[type="checkbox"]{cursor:not-allowed}.radio-inline.disabled,.checkbox-inline.disabled,fieldset[disabled] .radio-inline,fieldset[disabled] .checkbox-inline{cursor:not-allowed}.radio.disabled label,.checkbox.disabled label,fieldset[disabled] .radio label,fieldset[disabled] .checkbox label{cursor:not-allowed}.form-control-static{padding-top:7px;padding-bottom:7px;margin-bottom:0;min-height:34px}.form-control-static.input-lg,.form-control-static.input-sm{padding-left:0;padding-right:0}.input-sm{height:30px;padding:5px 10px;font-size:12px;line-height:1.5;border-radius:3px}select.input-sm{height:30px;line-height:30px}textarea.input-sm,select[multiple].input-sm{height:auto}.form-group-sm .form-control{height:30px;padding:5px 10px;font-size:12px;line-height:1.5;border-radius:3px}.form-group-sm select.form-control{height:30px;line-height:30px}.form-group-sm textarea.form-control,.form-group-sm select[multiple].form-control{height:auto}.form-group-sm .form-control-static{height:30px;min-height:32px;padding:6px 10px;font-size:12px;line-height:1.5}.input-lg{height:46px;padding:10px 16px;font-size:18px;line-height:1.3333333;border-radius:6px}select.input-lg{height:46px;line-height:46px}textarea.input-lg,select[multiple].input-lg{height:auto}.form-group-lg .form-control{height:46px;padding:10px 16px;font-size:18px;line-height:1.3333333;border-radius:6px}.form-group-lg select.form-control{height:46px;line-height:46px}.form-group-lg textarea.form-control,.form-group-lg select[multiple].form-control{height:auto}.form-group-lg .form-control-static{height:46px;min-height:38px;padding:11px 16px;font-size:18px;line-height:1.3333333}.has-feedback{position:relative}.has-feedback .form-control{padding-right:42.5px}.form-control-feedback{position:absolute;top:0;right:0;z-index:2;display:block;width:34px;height:34px;line-height:34px;text-align:center;pointer-events:none}.input-lg+.form-control-feedback,.input-group-lg+.form-control-feedback,.form-group-lg .form-control+.form-control-feedback{width:46px;height:46px;line-height:46px}.input-sm+.form-control-feedback,.input-group-sm+.form-control-feedback,.form-group-sm .form-control+.form-control-feedback{width:30px;height:30px;line-height:30px}.has-success .help-block,.has-success .control-label,.has-success .radio,.has-success .checkbox,.has-success .radio-inline,.has-success .checkbox-inline,.has-success.radio label,.has-success.checkbox label,.has-success.radio-inline label,.has-success.checkbox-inline label{color:#3c763d}.has-success .form-control{border-color:#3c763d;-webkit-box-shadow:inset 0 1px 1px rgba(0,0,0,0.075);box-shadow:inset 0 1px 1px rgba(0,0,0,0.075)}.has-success .form-control:focus{border-color:#2b542c;-webkit-box-shadow:inset 0 1px 1px rgba(0,0,0,0.075),0 0 6px #67b168;box-shadow:inset 0 1px 1px rgba(0,0,0,0.075),0 0 6px #67b168}.has-success .input-group-addon{color:#3c763d;border-color:#3c763d;background-color:#dff0d8}.has-success .form-control-feedback{color:#3c763d}.has-warning .help-block,.has-warning .control-label,.has-warning .radio,.has-warning .checkbox,.has-warning .radio-inline,.has-warning .checkbox-inline,.has-warning.radio label,.has-warning.checkbox label,.has-warning.radio-inline label,.has-warning.checkbox-inline label{color:#8a6d3b}.has-warning .form-control{border-color:#8a6d3b;-webkit-box-shadow:inset 0 1px 1px rgba(0,0,0,0.075);box-shadow:inset 0 1px 1px rgba(0,0,0,0.075)}.has-warning .form-control:focus{border-color:#66512c;-webkit-box-shadow:inset 0 1px 1px rgba(0,0,0,0.075),0 0 6px #c0a16b;box-shadow:inset 0 1px 1px rgba(0,0,0,0.075),0 0 6px #c0a16b}.has-warning .input-group-addon{color:#8a6d3b;border-color:#8a6d3b;background-color:#fcf8e3}.has-warning .form-control-feedback{color:#8a6d3b}.has-error .help-block,.has-error .control-label,.has-error .radio,.has-error .checkbox,.has-error .radio-inline,.has-error .checkbox-inline,.has-error.radio label,.has-error.checkbox label,.has-error.radio-inline label,.has-error.checkbox-inline label{color:#a94442}.has-error .form-control{border-color:#a94442;-webkit-box-shadow:inset 0 1px 1px rgba(0,0,0,0.075);box-shadow:inset 0 1px 1px rgba(0,0,0,0.075)}.has-error .form-control:focus{border-color:#843534;-webkit-box-shadow:inset 0 1px 1px rgba(0,0,0,0.075),0 0 6px #ce8483;box-shadow:inset 0 1px 1px rgba(0,0,0,0.075),0 0 6px #ce8483}.has-error .input-group-addon{color:#a94442;border-color:#a94442;background-color:#f2dede}.has-error .form-control-feedback{color:#a94442}.has-feedback label~.form-control-feedback{top:25px}.has-feedback label.sr-only~.form-control-feedback{top:0}.help-block{display:block;margin-top:5px;margin-bottom:10px;color:#737373}@media (min-width:768px){.form-inline .form-group{display:inline-block;margin-bottom:0;vertical-align:middle}.form-inline .form-control{display:inline-block;width:auto;vertical-align:middle}.form-inline .form-control-static{display:inline-block}.form-inline .input-group{display:inline-table;vertical-align:middle}.form-inline .input-group .input-group-addon,.form-inline .input-group .input-group-btn,.form-inline .input-group .form-control{width:auto}.form-inline .input-group>.form-control{width:100%}.form-inline .control-label{margin-bottom:0;vertical-align:middle}.form-inline .radio,.form-inline .checkbox{display:inline-block;margin-top:0;margin-bottom:0;vertical-align:middle}.form-inline .radio label,.form-inline .checkbox label{padding-left:0}.form-inline .radio input[type="radio"],.form-inline .checkbox input[type="checkbox"]{position:relative;margin-left:0}.form-inline .has-feedback .form-control-feedback{top:0}}.form-horizontal .radio,.form-horizontal .checkbox,.form-horizontal .radio-inline,.form-horizontal .checkbox-inline{margin-top:0;margin-bottom:0;padding-top:7px}.form-horizontal .radio,.form-horizontal .checkbox{min-height:27px}.form-horizontal .form-group{margin-left:-15px;margin-right:-15px}@media (min-width:768px){.form-horizontal .control-label{text-align:right;margin-bottom:0;padding-top:7px}}.form-horizontal .has-feedback .form-control-feedback{right:15px}@media (min-width:768px){.form-horizontal .form-group-lg .control-label{padding-top:14.333333px;font-size:18px}}@media (min-width:768px){.form-horizontal .form-group-sm .control-label{padding-top:6px;font-size:12px}}.btn{display:inline-block;margin-bottom:0;font-weight:normal;text-align:center;vertical-align:middle;-ms-touch-action:manipulation;touch-action:manipulation;cursor:pointer;background-image:none;border:1px solid transparent;white-space:nowrap;padding:6px 12px;font-size:14px;line-height:1.42857143;border-radius:4px;-webkit-user-select:none;-moz-user-select:none;-ms-user-select:none;user-select:none}.btn:focus,.btn:active:focus,.btn.active:focus,.btn.focus,.btn:active.focus,.btn.active.focus{outline:thin dotted;outline:5px auto -webkit-focus-ring-color;outline-offset:-2px}.btn:hover,.btn:focus,.btn.focus{color:#333;text-decoration:none}.btn:active,.btn.active{outline:0;background-image:none;-webkit-box-shadow:inset 0 3px 5px rgba(0,0,0,0.125);box-shadow:inset 0 3px 5px rgba(0,0,0,0.125)}.btn.disabled,.btn[disabled],fieldset[disabled] .btn{cursor:not-allowed;opacity:.65;filter:alpha(opacity=65);-webkit-box-shadow:none;box-shadow:none}a.btn.disabled,fieldset[disabled] a.btn{pointer-events:none}.btn-default{color:#333;background-color:#fff;border-color:#ccc}.btn-default:focus,.btn-default.focus{color:#333;background-color:#e6e6e6;border-color:#8c8c8c}.btn-default:hover{color:#333;background-color:#e6e6e6;border-color:#adadad}.btn-default:active,.btn-default.active,.open>.dropdown-toggle.btn-default{color:#333;background-color:#e6e6e6;border-color:#adadad}.btn-default:active:hover,.btn-default.active:hover,.open>.dropdown-toggle.btn-default:hover,.btn-default:active:focus,.btn-default.active:focus,.open>.dropdown-toggle.btn-default:focus,.btn-default:active.focus,.btn-default.active.focus,.open>.dropdown-toggle.btn-default.focus{color:#333;background-color:#d4d4d4;border-color:#8c8c8c}.btn-default:active,.btn-default.active,.open>.dropdown-toggle.btn-default{background-image:none}.btn-default.disabled,.btn-default[disabled],fieldset[disabled] .btn-default,.btn-default.disabled:hover,.btn-default[disabled]:hover,fieldset[disabled] .btn-default:hover,.btn-default.disabled:focus,.btn-default[disabled]:focus,fieldset[disabled] .btn-default:focus,.btn-default.disabled.focus,.btn-default[disabled].focus,fieldset[disabled] .btn-default.focus,.btn-default.disabled:active,.btn-default[disabled]:active,fieldset[disabled] .btn-default:active,.btn-default.disabled.active,.btn-default[disabled].active,fieldset[disabled] .btn-default.active{background-color:#fff;border-color:#ccc}.btn-default .badge{color:#fff;background-color:#333}.btn-primary{color:#fff;background-color:#337ab7;border-color:#2e6da4}.btn-primary:focus,.btn-primary.focus{color:#fff;background-color:#286090;border-color:#122b40}.btn-primary:hover{color:#fff;background-color:#286090;border-color:#204d74}.btn-primary:active,.btn-primary.active,.open>.dropdown-toggle.btn-primary{color:#fff;background-color:#286090;border-color:#204d74}.btn-primary:active:hover,.btn-primary.active:hover,.open>.dropdown-toggle.btn-primary:hover,.btn-primary:active:focus,.btn-primary.active:focus,.open>.dropdown-toggle.btn-primary:focus,.btn-primary:active.focus,.btn-primary.active.focus,.open>.dropdown-toggle.btn-primary.focus{color:#fff;background-color:#204d74;border-color:#122b40}.btn-primary:active,.btn-primary.active,.open>.dropdown-toggle.btn-primary{background-image:none}.btn-primary.disabled,.btn-primary[disabled],fieldset[disabled] .btn-primary,.btn-primary.disabled:hover,.btn-primary[disabled]:hover,fieldset[disabled] .btn-primary:hover,.btn-primary.disabled:focus,.btn-primary[disabled]:focus,fieldset[disabled] .btn-primary:focus,.btn-primary.disabled.focus,.btn-primary[disabled].focus,fieldset[disabled] .btn-primary.focus,.btn-primary.disabled:active,.btn-primary[disabled]:active,fieldset[disabled] .btn-primary:active,.btn-primary.disabled.active,.btn-primary[disabled].active,fieldset[disabled] .btn-primary.active{background-color:#337ab7;border-color:#2e6da4}.btn-primary .badge{color:#337ab7;background-color:#fff}.btn-success{color:#fff;background-color:#5cb85c;border-color:#4cae4c}.btn-success:focus,.btn-success.focus{color:#fff;background-color:#449d44;border-color:#255625}.btn-success:hover{color:#fff;background-color:#449d44;border-color:#398439}.btn-success:active,.btn-success.active,.open>.dropdown-toggle.btn-success{color:#fff;background-color:#449d44;border-color:#398439}.btn-success:active:hover,.btn-success.active:hover,.open>.dropdown-toggle.btn-success:hover,.btn-success:active:focus,.btn-success.active:focus,.open>.dropdown-toggle.btn-success:focus,.btn-success:active.focus,.btn-success.active.focus,.open>.dropdown-toggle.btn-success.focus{color:#fff;background-color:#398439;border-color:#255625}.btn-success:active,.btn-success.active,.open>.dropdown-toggle.btn-success{background-image:none}.btn-success.disabled,.btn-success[disabled],fieldset[disabled] .btn-success,.btn-success.disabled:hover,.btn-success[disabled]:hover,fieldset[disabled] .btn-success:hover,.btn-success.disabled:focus,.btn-success[disabled]:focus,fieldset[disabled] .btn-success:focus,.btn-success.disabled.focus,.btn-success[disabled].focus,fieldset[disabled] .btn-success.focus,.btn-success.disabled:active,.btn-success[disabled]:active,fieldset[disabled] .btn-success:active,.btn-success.disabled.active,.btn-success[disabled].active,fieldset[disabled] .btn-success.active{background-color:#5cb85c;border-color:#4cae4c}.btn-success .badge{color:#5cb85c;background-color:#fff}.btn-info{color:#fff;background-color:#5bc0de;border-color:#46b8da}.btn-info:focus,.btn-info.focus{color:#fff;background-color:#31b0d5;border-color:#1b6d85}.btn-info:hover{color:#fff;background-color:#31b0d5;border-color:#269abc}.btn-info:active,.btn-info.active,.open>.dropdown-toggle.btn-info{color:#fff;background-color:#31b0d5;border-color:#269abc}.btn-info:active:hover,.btn-info.active:hover,.open>.dropdown-toggle.btn-info:hover,.btn-info:active:focus,.btn-info.active:focus,.open>.dropdown-toggle.btn-info:focus,.btn-info:active.focus,.btn-info.active.focus,.open>.dropdown-toggle.btn-info.focus{color:#fff;background-color:#269abc;border-color:#1b6d85}.btn-info:active,.btn-info.active,.open>.dropdown-toggle.btn-info{background-image:none}.btn-info.disabled,.btn-info[disabled],fieldset[disabled] .btn-info,.btn-info.disabled:hover,.btn-info[disabled]:hover,fieldset[disabled] .btn-info:hover,.btn-info.disabled:focus,.btn-info[disabled]:focus,fieldset[disabled] .btn-info:focus,.btn-info.disabled.focus,.btn-info[disabled].focus,fieldset[disabled] .btn-info.focus,.btn-info.disabled:active,.btn-info[disabled]:active,fieldset[disabled] .btn-info:active,.btn-info.disabled.active,.btn-info[disabled].active,fieldset[disabled] .btn-info.active{background-color:#5bc0de;border-color:#46b8da}.btn-info .badge{color:#5bc0de;background-color:#fff}.btn-warning{color:#fff;background-color:#f0ad4e;border-color:#eea236}.btn-warning:focus,.btn-warning.focus{color:#fff;background-color:#ec971f;border-color:#985f0d}.btn-warning:hover{color:#fff;background-color:#ec971f;border-color:#d58512}.btn-warning:active,.btn-warning.active,.open>.dropdown-toggle.btn-warning{color:#fff;background-color:#ec971f;border-color:#d58512}.btn-warning:active:hover,.btn-warning.active:hover,.open>.dropdown-toggle.btn-warning:hover,.btn-warning:active:focus,.btn-warning.active:focus,.open>.dropdown-toggle.btn-warning:focus,.btn-warning:active.focus,.btn-warning.active.focus,.open>.dropdown-toggle.btn-warning.focus{color:#fff;background-color:#d58512;border-color:#985f0d}.btn-warning:active,.btn-warning.active,.open>.dropdown-toggle.btn-warning{background-image:none}.btn-warning.disabled,.btn-warning[disabled],fieldset[disabled] .btn-warning,.btn-warning.disabled:hover,.btn-warning[disabled]:hover,fieldset[disabled] .btn-warning:hover,.btn-warning.disabled:focus,.btn-warning[disabled]:focus,fieldset[disabled] .btn-warning:focus,.btn-warning.disabled.focus,.btn-warning[disabled].focus,fieldset[disabled] .btn-warning.focus,.btn-warning.disabled:active,.btn-warning[disabled]:active,fieldset[disabled] .btn-warning:active,.btn-warning.disabled.active,.btn-warning[disabled].active,fieldset[disabled] .btn-warning.active{background-color:#f0ad4e;border-color:#eea236}.btn-warning .badge{color:#f0ad4e;background-color:#fff}.btn-danger{color:#fff;background-color:#d9534f;border-color:#d43f3a}.btn-danger:focus,.btn-danger.focus{color:#fff;background-color:#c9302c;border-color:#761c19}.btn-danger:hover{color:#fff;background-color:#c9302c;border-color:#ac2925}.btn-danger:active,.btn-danger.active,.open>.dropdown-toggle.btn-danger{color:#fff;background-color:#c9302c;border-color:#ac2925}.btn-danger:active:hover,.btn-danger.active:hover,.open>.dropdown-toggle.btn-danger:hover,.btn-danger:active:focus,.btn-danger.active:focus,.open>.dropdown-toggle.btn-danger:focus,.btn-danger:active.focus,.btn-danger.active.focus,.open>.dropdown-toggle.btn-danger.focus{color:#fff;background-color:#ac2925;border-color:#761c19}.btn-danger:active,.btn-danger.active,.open>.dropdown-toggle.btn-danger{background-image:none}.btn-danger.disabled,.btn-danger[disabled],fieldset[disabled] .btn-danger,.btn-danger.disabled:hover,.btn-danger[disabled]:hover,fieldset[disabled] .btn-danger:hover,.btn-danger.disabled:focus,.btn-danger[disabled]:focus,fieldset[disabled] .btn-danger:focus,.btn-danger.disabled.focus,.btn-danger[disabled].focus,fieldset[disabled] .btn-danger.focus,.btn-danger.disabled:active,.btn-danger[disabled]:active,fieldset[disabled] .btn-danger:active,.btn-danger.disabled.active,.btn-danger[disabled].active,fieldset[disabled] .btn-danger.active{background-color:#d9534f;border-color:#d43f3a}.btn-danger .badge{color:#d9534f;background-color:#fff}.btn-link{color:#337ab7;font-weight:normal;border-radius:0}.btn-link,.btn-link:active,.btn-link.active,.btn-link[disabled],fieldset[disabled] .btn-link{background-color:transparent;-webkit-box-shadow:none;box-shadow:none}.btn-link,.btn-link:hover,.btn-link:focus,.btn-link:active{border-color:transparent}.btn-link:hover,.btn-link:focus{color:#23527c;text-decoration:underline;background-color:transparent}.btn-link[disabled]:hover,fieldset[disabled] .btn-link:hover,.btn-link[disabled]:focus,fieldset[disabled] .btn-link:focus{color:#777;text-decoration:none}.btn-lg,.btn-group-lg>.btn{padding:10px 16px;font-size:18px;line-height:1.3333333;border-radius:6px}.btn-sm,.btn-group-sm>.btn{padding:5px 10px;font-size:12px;line-height:1.5;border-radius:3px}.btn-xs,.btn-group-xs>.btn{padding:1px 5px;font-size:12px;line-height:1.5;border-radius:3px}.btn-block{display:block;width:100%}.btn-block+.btn-block{margin-top:5px}input[type="submit"].btn-block,input[type="reset"].btn-block,input[type="button"].btn-block{width:100%}.fade{opacity:0;-webkit-transition:opacity .15s linear;-o-transition:opacity .15s linear;transition:opacity .15s linear}.fade.in{opacity:1}.collapse{display:none}.collapse.in{display:block}tr.collapse.in{display:table-row}tbody.collapse.in{display:table-row-group}.collapsing{position:relative;height:0;overflow:hidden;-webkit-transition-property:height, visibility;-o-transition-property:height, visibility;transition-property:height, visibility;-webkit-transition-duration:.35s;-o-transition-duration:.35s;transition-duration:.35s;-webkit-transition-timing-function:ease;-o-transition-timing-function:ease;transition-timing-function:ease}.caret{display:inline-block;width:0;height:0;margin-left:2px;vertical-align:middle;border-top:4px dashed;border-top:4px solid \9;border-right:4px solid transparent;border-left:4px solid transparent}.dropup,.dropdown{position:relative}.dropdown-toggle:focus{outline:0}.dropdown-menu{position:absolute;top:100%;left:0;z-index:1000;display:none;float:left;min-width:160px;padding:5px 0;margin:2px 0 0;list-style:none;font-size:14px;text-align:left;background-color:#fff;border:1px solid #ccc;border:1px solid rgba(0,0,0,0.15);border-radius:4px;-webkit-box-shadow:0 6px 12px rgba(0,0,0,0.175);box-shadow:0 6px 12px rgba(0,0,0,0.175);-webkit-background-clip:padding-box;background-clip:padding-box}.dropdown-menu.pull-right{right:0;left:auto}.dropdown-menu .divider{height:1px;margin:9px 0;overflow:hidden;background-color:#e5e5e5}.dropdown-menu>li>a{display:block;padding:3px 20px;clear:both;font-weight:normal;line-height:1.42857143;color:#333;white-space:nowrap}.dropdown-menu>li>a:hover,.dropdown-menu>li>a:focus{text-decoration:none;color:#262626;background-color:#f5f5f5}.dropdown-menu>.active>a,.dropdown-menu>.active>a:hover,.dropdown-menu>.active>a:focus{color:#fff;text-decoration:none;outline:0;background-color:#337ab7}.dropdown-menu>.disabled>a,.dropdown-menu>.disabled>a:hover,.dropdown-menu>.disabled>a:focus{color:#777}.dropdown-menu>.disabled>a:hover,.dropdown-menu>.disabled>a:focus{text-decoration:none;background-color:transparent;background-image:none;filter:progid:DXImageTransform.Microsoft.gradient(enabled = false);cursor:not-allowed}.open>.dropdown-menu{display:block}.open>a{outline:0}.dropdown-menu-right{left:auto;right:0}.dropdown-menu-left{left:0;right:auto}.dropdown-header{display:block;padding:3px 20px;font-size:12px;line-height:1.42857143;color:#777;white-space:nowrap}.dropdown-backdrop{position:fixed;left:0;right:0;bottom:0;top:0;z-index:990}.pull-right>.dropdown-menu{right:0;left:auto}.dropup .caret,.navbar-fixed-bottom .dropdown .caret{border-top:0;border-bottom:4px dashed;border-bottom:4px solid \9;content:""}.dropup .dropdown-menu,.navbar-fixed-bottom .dropdown .dropdown-menu{top:auto;bottom:100%;margin-bottom:2px}@media (min-width:768px){.navbar-right .dropdown-menu{left:auto;right:0}.navbar-right .dropdown-menu-left{left:0;right:auto}}.btn-group,.btn-group-vertical{position:relative;display:inline-block;vertical-align:middle}.btn-group>.btn,.btn-group-vertical>.btn{position:relative;float:left}.btn-group>.btn:hover,.btn-group-vertical>.btn:hover,.btn-group>.btn:focus,.btn-group-vertical>.btn:focus,.btn-group>.btn:active,.btn-group-vertical>.btn:active,.btn-group>.btn.active,.btn-group-vertical>.btn.active{z-index:2}.btn-group .btn+.btn,.btn-group .btn+.btn-group,.btn-group .btn-group+.btn,.btn-group .btn-group+.btn-group{margin-left:-1px}.btn-toolbar{margin-left:-5px}.btn-toolbar .btn,.btn-toolbar .btn-group,.btn-toolbar .input-group{float:left}.btn-toolbar>.btn,.btn-toolbar>.btn-group,.btn-toolbar>.input-group{margin-left:5px}.btn-group>.btn:not(:first-child):not(:last-child):not(.dropdown-toggle){border-radius:0}.btn-group>.btn:first-child{margin-left:0}.btn-group>.btn:first-child:not(:last-child):not(.dropdown-toggle){border-bottom-right-radius:0;border-top-right-radius:0}.btn-group>.btn:last-child:not(:first-child),.btn-group>.dropdown-toggle:not(:first-child){border-bottom-left-radius:0;border-top-left-radius:0}.btn-group>.btn-group{float:left}.btn-group>.btn-group:not(:first-child):not(:last-child)>.btn{border-radius:0}.btn-group>.btn-group:first-child:not(:last-child)>.btn:last-child,.btn-group>.btn-group:first-child:not(:last-child)>.dropdown-toggle{border-bottom-right-radius:0;border-top-right-radius:0}.btn-group>.btn-group:last-child:not(:first-child)>.btn:first-child{border-bottom-left-radius:0;border-top-left-radius:0}.btn-group .dropdown-toggle:active,.btn-group.open .dropdown-toggle{outline:0}.btn-group>.btn+.dropdown-toggle{padding-left:8px;padding-right:8px}.btn-group>.btn-lg+.dropdown-toggle{padding-left:12px;padding-right:12px}.btn-group.open .dropdown-toggle{-webkit-box-shadow:inset 0 3px 5px rgba(0,0,0,0.125);box-shadow:inset 0 3px 5px rgba(0,0,0,0.125)}.btn-group.open .dropdown-toggle.btn-link{-webkit-box-shadow:none;box-shadow:none}.btn .caret{margin-left:0}.btn-lg .caret{border-width:5px 5px 0;border-bottom-width:0}.dropup .btn-lg .caret{border-width:0 5px 5px}.btn-group-vertical>.btn,.btn-group-vertical>.btn-group,.btn-group-vertical>.btn-group>.btn{display:block;float:none;width:100%;max-width:100%}.btn-group-vertical>.btn-group>.btn{float:none}.btn-group-vertical>.btn+.btn,.btn-group-vertical>.btn+.btn-group,.btn-group-vertical>.btn-group+.btn,.btn-group-vertical>.btn-group+.btn-group{margin-top:-1px;margin-left:0}.btn-group-vertical>.btn:not(:first-child):not(:last-child){border-radius:0}.btn-group-vertical>.btn:first-child:not(:last-child){border-top-right-radius:4px;border-bottom-right-radius:0;border-bottom-left-radius:0}.btn-group-vertical>.btn:last-child:not(:first-child){border-bottom-left-radius:4px;border-top-right-radius:0;border-top-left-radius:0}.btn-group-vertical>.btn-group:not(:first-child):not(:last-child)>.btn{border-radius:0}.btn-group-vertical>.btn-group:first-child:not(:last-child)>.btn:last-child,.btn-group-vertical>.btn-group:first-child:not(:last-child)>.dropdown-toggle{border-bottom-right-radius:0;border-bottom-left-radius:0}.btn-group-vertical>.btn-group:last-child:not(:first-child)>.btn:first-child{border-top-right-radius:0;border-top-left-radius:0}.btn-group-justified{display:table;width:100%;table-layout:fixed;border-collapse:separate}.btn-group-justified>.btn,.btn-group-justified>.btn-group{float:none;display:table-cell;width:1%}.btn-group-justified>.btn-group .btn{width:100%}.btn-group-justified>.btn-group .dropdown-menu{left:auto}[data-toggle="buttons"]>.btn input[type="radio"],[data-toggle="buttons"]>.btn-group>.btn input[type="radio"],[data-toggle="buttons"]>.btn input[type="checkbox"],[data-toggle="buttons"]>.btn-group>.btn input[type="checkbox"]{position:absolute;clip:rect(0, 0, 0, 0);pointer-events:none}.input-group{position:relative;display:table;border-collapse:separate}.input-group[class*="col-"]{float:none;padding-left:0;padding-right:0}.input-group .form-control{position:relative;z-index:2;float:left;width:100%;margin-bottom:0}.input-group-lg>.form-control,.input-group-lg>.input-group-addon,.input-group-lg>.input-group-btn>.btn{height:46px;padding:10px 16px;font-size:18px;line-height:1.3333333;border-radius:6px}select.input-group-lg>.form-control,select.input-group-lg>.input-group-addon,select.input-group-lg>.input-group-btn>.btn{height:46px;line-height:46px}textarea.input-group-lg>.form-control,textarea.input-group-lg>.input-group-addon,textarea.input-group-lg>.input-group-btn>.btn,select[multiple].input-group-lg>.form-control,select[multiple].input-group-lg>.input-group-addon,select[multiple].input-group-lg>.input-group-btn>.btn{height:auto}.input-group-sm>.form-control,.input-group-sm>.input-group-addon,.input-group-sm>.input-group-btn>.btn{height:30px;padding:5px 10px;font-size:12px;line-height:1.5;border-radius:3px}select.input-group-sm>.form-control,select.input-group-sm>.input-group-addon,select.input-group-sm>.input-group-btn>.btn{height:30px;line-height:30px}textarea.input-group-sm>.form-control,textarea.input-group-sm>.input-group-addon,textarea.input-group-sm>.input-group-btn>.btn,select[multiple].input-group-sm>.form-control,select[multiple].input-group-sm>.input-group-addon,select[multiple].input-group-sm>.input-group-btn>.btn{height:auto}.input-group-addon,.input-group-btn,.input-group .form-control{display:table-cell}.input-group-addon:not(:first-child):not(:last-child),.input-group-btn:not(:first-child):not(:last-child),.input-group .form-control:not(:first-child):not(:last-child){border-radius:0}.input-group-addon,.input-group-btn{width:1%;white-space:nowrap;vertical-align:middle}.input-group-addon{padding:6px 12px;font-size:14px;font-weight:normal;line-height:1;color:#555;text-align:center;background-color:#eee;border:1px solid #ccc;border-radius:4px}.input-group-addon.input-sm{padding:5px 10px;font-size:12px;border-radius:3px}.input-group-addon.input-lg{padding:10px 16px;font-size:18px;border-radius:6px}.input-group-addon input[type="radio"],.input-group-addon input[type="checkbox"]{margin-top:0}.input-group .form-control:first-child,.input-group-addon:first-child,.input-group-btn:first-child>.btn,.input-group-btn:first-child>.btn-group>.btn,.input-group-btn:first-child>.dropdown-toggle,.input-group-btn:last-child>.btn:not(:last-child):not(.dropdown-toggle),.input-group-btn:last-child>.btn-group:not(:last-child)>.btn{border-bottom-right-radius:0;border-top-right-radius:0}.input-group-addon:first-child{border-right:0}.input-group .form-control:last-child,.input-group-addon:last-child,.input-group-btn:last-child>.btn,.input-group-btn:last-child>.btn-group>.btn,.input-group-btn:last-child>.dropdown-toggle,.input-group-btn:first-child>.btn:not(:first-child),.input-group-btn:first-child>.btn-group:not(:first-child)>.btn{border-bottom-left-radius:0;border-top-left-radius:0}.input-group-addon:last-child{border-left:0}.input-group-btn{position:relative;font-size:0;white-space:nowrap}.input-group-btn>.btn{position:relative}.input-group-btn>.btn+.btn{margin-left:-1px}.input-group-btn>.btn:hover,.input-group-btn>.btn:focus,.input-group-btn>.btn:active{z-index:2}.input-group-btn:first-child>.btn,.input-group-btn:first-child>.btn-group{margin-right:-1px}.input-group-btn:last-child>.btn,.input-group-btn:last-child>.btn-group{z-index:2;margin-left:-1px}.nav{margin-bottom:0;padding-left:0;list-style:none}.nav>li{position:relative;display:block}.nav>li>a{position:relative;display:block;padding:10px 15px}.nav>li>a:hover,.nav>li>a:focus{text-decoration:none;background-color:#eee}.nav>li.disabled>a{color:#777}.nav>li.disabled>a:hover,.nav>li.disabled>a:focus{color:#777;text-decoration:none;background-color:transparent;cursor:not-allowed}.nav .open>a,.nav .open>a:hover,.nav .open>a:focus{background-color:#eee;border-color:#337ab7}.nav .nav-divider{height:1px;margin:9px 0;overflow:hidden;background-color:#e5e5e5}.nav>li>a>img{max-width:none}.nav-tabs{border-bottom:1px solid #ddd}.nav-tabs>li{float:left;margin-bottom:-1px}.nav-tabs>li>a{margin-right:2px;line-height:1.42857143;border:1px solid transparent;border-radius:4px 4px 0 0}.nav-tabs>li>a:hover{border-color:#eee #eee #ddd}.nav-tabs>li.active>a,.nav-tabs>li.active>a:hover,.nav-tabs>li.active>a:focus{color:#555;background-color:#fff;border:1px solid #ddd;border-bottom-color:transparent;cursor:default}.nav-tabs.nav-justified{width:100%;border-bottom:0}.nav-tabs.nav-justified>li{float:none}.nav-tabs.nav-justified>li>a{text-align:center;margin-bottom:5px}.nav-tabs.nav-justified>.dropdown .dropdown-menu{top:auto;left:auto}@media (min-width:768px){.nav-tabs.nav-justified>li{display:table-cell;width:1%}.nav-tabs.nav-justified>li>a{margin-bottom:0}}.nav-tabs.nav-justified>li>a{margin-right:0;border-radius:4px}.nav-tabs.nav-justified>.active>a,.nav-tabs.nav-justified>.active>a:hover,.nav-tabs.nav-justified>.active>a:focus{border:1px solid #ddd}@media (min-width:768px){.nav-tabs.nav-justified>li>a{border-bottom:1px solid #ddd;border-radius:4px 4px 0 0}.nav-tabs.nav-justified>.active>a,.nav-tabs.nav-justified>.active>a:hover,.nav-tabs.nav-justified>.active>a:focus{border-bottom-color:#fff}}.nav-pills>li{float:left}.nav-pills>li>a{border-radius:4px}.nav-pills>li+li{margin-left:2px}.nav-pills>li.active>a,.nav-pills>li.active>a:hover,.nav-pills>li.active>a:focus{color:#fff;background-color:#337ab7}.nav-stacked>li{float:none}.nav-stacked>li+li{margin-top:2px;margin-left:0}.nav-justified{width:100%}.nav-justified>li{float:none}.nav-justified>li>a{text-align:center;margin-bottom:5px}.nav-justified>.dropdown .dropdown-menu{top:auto;left:auto}@media (min-width:768px){.nav-justified>li{display:table-cell;width:1%}.nav-justified>li>a{margin-bottom:0}}.nav-tabs-justified{border-bottom:0}.nav-tabs-justified>li>a{margin-right:0;border-radius:4px}.nav-tabs-justified>.active>a,.nav-tabs-justified>.active>a:hover,.nav-tabs-justified>.active>a:focus{border:1px solid #ddd}@media (min-width:768px){.nav-tabs-justified>li>a{border-bottom:1px solid #ddd;border-radius:4px 4px 0 0}.nav-tabs-justified>.active>a,.nav-tabs-justified>.active>a:hover,.nav-tabs-justified>.active>a:focus{border-bottom-color:#fff}}.tab-content>.tab-pane{display:none}.tab-content>.active{display:block}.nav-tabs .dropdown-menu{margin-top:-1px;border-top-right-radius:0;border-top-left-radius:0}.navbar{position:relative;min-height:50px;margin-bottom:20px;border:1px solid transparent}@media (min-width:768px){.navbar{border-radius:4px}}@media (min-width:768px){.navbar-header{float:left}}.navbar-collapse{overflow-x:visible;padding-right:15px;padding-left:15px;border-top:1px solid transparent;-webkit-box-shadow:inset 0 1px 0 rgba(255,255,255,0.1);box-shadow:inset 0 1px 0 rgba(255,255,255,0.1);-webkit-overflow-scrolling:touch}.navbar-collapse.in{overflow-y:auto}@media (min-width:768px){.navbar-collapse{width:auto;border-top:0;-webkit-box-shadow:none;box-shadow:none}.navbar-collapse.collapse{display:block !important;height:auto !important;padding-bottom:0;overflow:visible !important}.navbar-collapse.in{overflow-y:visible}.navbar-fixed-top .navbar-collapse,.navbar-static-top .navbar-collapse,.navbar-fixed-bottom .navbar-collapse{padding-left:0;padding-right:0}}.navbar-fixed-top .navbar-collapse,.navbar-fixed-bottom .navbar-collapse{max-height:340px}@media (max-device-width:480px) and (orientation:landscape){.navbar-fixed-top .navbar-collapse,.navbar-fixed-bottom .navbar-collapse{max-height:200px}}.container>.navbar-header,.container-fluid>.navbar-header,.container>.navbar-collapse,.container-fluid>.navbar-collapse{margin-right:-15px;margin-left:-15px}@media (min-width:768px){.container>.navbar-header,.container-fluid>.navbar-header,.container>.navbar-collapse,.container-fluid>.navbar-collapse{margin-right:0;margin-left:0}}.navbar-static-top{z-index:1000;border-width:0 0 1px}@media (min-width:768px){.navbar-static-top{border-radius:0}}.navbar-fixed-top,.navbar-fixed-bottom{position:fixed;right:0;left:0;z-index:1030}@media (min-width:768px){.navbar-fixed-top,.navbar-fixed-bottom{border-radius:0}}.navbar-fixed-top{top:0;border-width:0 0 1px}.navbar-fixed-bottom{bottom:0;margin-bottom:0;border-width:1px 0 0}.navbar-brand{float:left;padding:15px 15px;font-size:18px;line-height:20px;height:50px}.navbar-brand:hover,.navbar-brand:focus{text-decoration:none}.navbar-brand>img{display:block}@media (min-width:768px){.navbar>.container .navbar-brand,.navbar>.container-fluid .navbar-brand{margin-left:-15px}}.navbar-toggle{position:relative;float:right;margin-right:15px;padding:9px 10px;margin-top:8px;margin-bottom:8px;background-color:transparent;background-image:none;border:1px solid transparent;border-radius:4px}.navbar-toggle:focus{outline:0}.navbar-toggle .icon-bar{display:block;width:22px;height:2px;border-radius:1px}.navbar-toggle .icon-bar+.icon-bar{margin-top:4px}@media (min-width:768px){.navbar-toggle{display:none}}.navbar-nav{margin:7.5px -15px}.navbar-nav>li>a{padding-top:10px;padding-bottom:10px;line-height:20px}@media (max-width:767px){.navbar-nav .open .dropdown-menu{position:static;float:none;width:auto;margin-top:0;background-color:transparent;border:0;-webkit-box-shadow:none;box-shadow:none}.navbar-nav .open .dropdown-menu>li>a,.navbar-nav .open .dropdown-menu .dropdown-header{padding:5px 15px 5px 25px}.navbar-nav .open .dropdown-menu>li>a{line-height:20px}.navbar-nav .open .dropdown-menu>li>a:hover,.navbar-nav .open .dropdown-menu>li>a:focus{background-image:none}}@media (min-width:768px){.navbar-nav{float:left;margin:0}.navbar-nav>li{float:left}.navbar-nav>li>a{padding-top:15px;padding-bottom:15px}}.navbar-form{margin-left:-15px;margin-right:-15px;padding:10px 15px;border-top:1px solid transparent;border-bottom:1px solid transparent;-webkit-box-shadow:inset 0 1px 0 rgba(255,255,255,0.1),0 1px 0 rgba(255,255,255,0.1);box-shadow:inset 0 1px 0 rgba(255,255,255,0.1),0 1px 0 rgba(255,255,255,0.1);margin-top:8px;margin-bottom:8px}@media (min-width:768px){.navbar-form .form-group{display:inline-block;margin-bottom:0;vertical-align:middle}.navbar-form .form-control{display:inline-block;width:auto;vertical-align:middle}.navbar-form .form-control-static{display:inline-block}.navbar-form .input-group{display:inline-table;vertical-align:middle}.navbar-form .input-group .input-group-addon,.navbar-form .input-group .input-group-btn,.navbar-form .input-group .form-control{width:auto}.navbar-form .input-group>.form-control{width:100%}.navbar-form .control-label{margin-bottom:0;vertical-align:middle}.navbar-form .radio,.navbar-form .checkbox{display:inline-block;margin-top:0;margin-bottom:0;vertical-align:middle}.navbar-form .radio label,.navbar-form .checkbox label{padding-left:0}.navbar-form .radio input[type="radio"],.navbar-form .checkbox input[type="checkbox"]{position:relative;margin-left:0}.navbar-form .has-feedback .form-control-feedback{top:0}}@media (max-width:767px){.navbar-form .form-group{margin-bottom:5px}.navbar-form .form-group:last-child{margin-bottom:0}}@media (min-width:768px){.navbar-form{width:auto;border:0;margin-left:0;margin-right:0;padding-top:0;padding-bottom:0;-webkit-box-shadow:none;box-shadow:none}}.navbar-nav>li>.dropdown-menu{margin-top:0;border-top-right-radius:0;border-top-left-radius:0}.navbar-fixed-bottom .navbar-nav>li>.dropdown-menu{margin-bottom:0;border-top-right-radius:4px;border-top-left-radius:4px;border-bottom-right-radius:0;border-bottom-left-radius:0}.navbar-btn{margin-top:8px;margin-bottom:8px}.navbar-btn.btn-sm{margin-top:10px;margin-bottom:10px}.navbar-btn.btn-xs{margin-top:14px;margin-bottom:14px}.navbar-text{margin-top:15px;margin-bottom:15px}@media (min-width:768px){.navbar-text{float:left;margin-left:15px;margin-right:15px}}@media (min-width:768px){.navbar-left{float:left !important}.navbar-right{float:right !important;margin-right:-15px}.navbar-right~.navbar-right{margin-right:0}}.navbar-default{background-color:#f8f8f8;border-color:#e7e7e7}.navbar-default .navbar-brand{color:#777}.navbar-default .navbar-brand:hover,.navbar-default .navbar-brand:focus{color:#5e5e5e;background-color:transparent}.navbar-default .navbar-text{color:#777}.navbar-default .navbar-nav>li>a{color:#777}.navbar-default .navbar-nav>li>a:hover,.navbar-default .navbar-nav>li>a:focus{color:#333;background-color:transparent}.navbar-default .navbar-nav>.active>a,.navbar-default .navbar-nav>.active>a:hover,.navbar-default .navbar-nav>.active>a:focus{color:#555;background-color:#e7e7e7}.navbar-default .navbar-nav>.disabled>a,.navbar-default .navbar-nav>.disabled>a:hover,.navbar-default .navbar-nav>.disabled>a:focus{color:#ccc;background-color:transparent}.navbar-default .navbar-toggle{border-color:#ddd}.navbar-default .navbar-toggle:hover,.navbar-default .navbar-toggle:focus{background-color:#ddd}.navbar-default .navbar-toggle .icon-bar{background-color:#888}.navbar-default .navbar-collapse,.navbar-default .navbar-form{border-color:#e7e7e7}.navbar-default .navbar-nav>.open>a,.navbar-default .navbar-nav>.open>a:hover,.navbar-default .navbar-nav>.open>a:focus{background-color:#e7e7e7;color:#555}@media (max-width:767px){.navbar-default .navbar-nav .open .dropdown-menu>li>a{color:#777}.navbar-default .navbar-nav .open .dropdown-menu>li>a:hover,.navbar-default .navbar-nav .open .dropdown-menu>li>a:focus{color:#333;background-color:transparent}.navbar-default .navbar-nav .open .dropdown-menu>.active>a,.navbar-default .navbar-nav .open .dropdown-menu>.active>a:hover,.navbar-default .navbar-nav .open .dropdown-menu>.active>a:focus{color:#555;background-color:#e7e7e7}.navbar-default .navbar-nav .open .dropdown-menu>.disabled>a,.navbar-default .navbar-nav .open .dropdown-menu>.disabled>a:hover,.navbar-default .navbar-nav .open .dropdown-menu>.disabled>a:focus{color:#ccc;background-color:transparent}}.navbar-default .navbar-link{color:#777}.navbar-default .navbar-link:hover{color:#333}.navbar-default .btn-link{color:#777}.navbar-default .btn-link:hover,.navbar-default .btn-link:focus{color:#333}.navbar-default .btn-link[disabled]:hover,fieldset[disabled] .navbar-default .btn-link:hover,.navbar-default .btn-link[disabled]:focus,fieldset[disabled] .navbar-default .btn-link:focus{color:#ccc}.navbar-inverse{background-color:#222;border-color:#080808}.navbar-inverse .navbar-brand{color:#9d9d9d}.navbar-inverse .navbar-brand:hover,.navbar-inverse .navbar-brand:focus{color:#fff;background-color:transparent}.navbar-inverse .navbar-text{color:#9d9d9d}.navbar-inverse .navbar-nav>li>a{color:#9d9d9d}.navbar-inverse .navbar-nav>li>a:hover,.navbar-inverse .navbar-nav>li>a:focus{color:#fff;background-color:transparent}.navbar-inverse .navbar-nav>.active>a,.navbar-inverse .navbar-nav>.active>a:hover,.navbar-inverse .navbar-nav>.active>a:focus{color:#fff;background-color:#080808}.navbar-inverse .navbar-nav>.disabled>a,.navbar-inverse .navbar-nav>.disabled>a:hover,.navbar-inverse .navbar-nav>.disabled>a:focus{color:#444;background-color:transparent}.navbar-inverse .navbar-toggle{border-color:#333}.navbar-inverse .navbar-toggle:hover,.navbar-inverse .navbar-toggle:focus{background-color:#333}.navbar-inverse .navbar-toggle .icon-bar{background-color:#fff}.navbar-inverse .navbar-collapse,.navbar-inverse .navbar-form{border-color:#101010}.navbar-inverse .navbar-nav>.open>a,.navbar-inverse .navbar-nav>.open>a:hover,.navbar-inverse .navbar-nav>.open>a:focus{background-color:#080808;color:#fff}@media (max-width:767px){.navbar-inverse .navbar-nav .open .dropdown-menu>.dropdown-header{border-color:#080808}.navbar-inverse .navbar-nav .open .dropdown-menu .divider{background-color:#080808}.navbar-inverse .navbar-nav .open .dropdown-menu>li>a{color:#9d9d9d}.navbar-inverse .navbar-nav .open .dropdown-menu>li>a:hover,.navbar-inverse .navbar-nav .open .dropdown-menu>li>a:focus{color:#fff;background-color:transparent}.navbar-inverse .navbar-nav .open .dropdown-menu>.active>a,.navbar-inverse .navbar-nav .open .dropdown-menu>.active>a:hover,.navbar-inverse .navbar-nav .open .dropdown-menu>.active>a:focus{color:#fff;background-color:#080808}.navbar-inverse .navbar-nav .open .dropdown-menu>.disabled>a,.navbar-inverse .navbar-nav .open .dropdown-menu>.disabled>a:hover,.navbar-inverse .navbar-nav .open .dropdown-menu>.disabled>a:focus{color:#444;background-color:transparent}}.navbar-inverse .navbar-link{color:#9d9d9d}.navbar-inverse .navbar-link:hover{color:#fff}.navbar-inverse .btn-link{color:#9d9d9d}.navbar-inverse .btn-link:hover,.navbar-inverse .btn-link:focus{color:#fff}.navbar-inverse .btn-link[disabled]:hover,fieldset[disabled] .navbar-inverse .btn-link:hover,.navbar-inverse .btn-link[disabled]:focus,fieldset[disabled] .navbar-inverse .btn-link:focus{color:#444}.breadcrumb{padding:8px 15px;margin-bottom:20px;list-style:none;background-color:#f5f5f5;border-radius:4px}.breadcrumb>li{display:inline-block}.breadcrumb>li+li:before{content:"/\00a0";padding:0 5px;color:#ccc}.breadcrumb>.active{color:#777}.pagination{display:inline-block;padding-left:0;margin:20px 0;border-radius:4px}.pagination>li{display:inline}.pagination>li>a,.pagination>li>span{position:relative;float:left;padding:6px 12px;line-height:1.42857143;text-decoration:none;color:#337ab7;background-color:#fff;border:1px solid #ddd;margin-left:-1px}.pagination>li:first-child>a,.pagination>li:first-child>span{margin-left:0;border-bottom-left-radius:4px;border-top-left-radius:4px}.pagination>li:last-child>a,.pagination>li:last-child>span{border-bottom-right-radius:4px;border-top-right-radius:4px}.pagination>li>a:hover,.pagination>li>span:hover,.pagination>li>a:focus,.pagination>li>span:focus{z-index:3;color:#23527c;background-color:#eee;border-color:#ddd}.pagination>.active>a,.pagination>.active>span,.pagination>.active>a:hover,.pagination>.active>span:hover,.pagination>.active>a:focus,.pagination>.active>span:focus{z-index:2;color:#fff;background-color:#337ab7;border-color:#337ab7;cursor:default}.pagination>.disabled>span,.pagination>.disabled>span:hover,.pagination>.disabled>span:focus,.pagination>.disabled>a,.pagination>.disabled>a:hover,.pagination>.disabled>a:focus{color:#777;background-color:#fff;border-color:#ddd;cursor:not-allowed}.pagination-lg>li>a,.pagination-lg>li>span{padding:10px 16px;font-size:18px;line-height:1.3333333}.pagination-lg>li:first-child>a,.pagination-lg>li:first-child>span{border-bottom-left-radius:6px;border-top-left-radius:6px}.pagination-lg>li:last-child>a,.pagination-lg>li:last-child>span{border-bottom-right-radius:6px;border-top-right-radius:6px}.pagination-sm>li>a,.pagination-sm>li>span{padding:5px 10px;font-size:12px;line-height:1.5}.pagination-sm>li:first-child>a,.pagination-sm>li:first-child>span{border-bottom-left-radius:3px;border-top-left-radius:3px}.pagination-sm>li:last-child>a,.pagination-sm>li:last-child>span{border-bottom-right-radius:3px;border-top-right-radius:3px}.pager{padding-left:0;margin:20px 0;list-style:none;text-align:center}.pager li{display:inline}.pager li>a,.pager li>span{display:inline-block;padding:5px 14px;background-color:#fff;border:1px solid #ddd;border-radius:15px}.pager li>a:hover,.pager li>a:focus{text-decoration:none;background-color:#eee}.pager .next>a,.pager .next>span{float:right}.pager .previous>a,.pager .previous>span{float:left}.pager .disabled>a,.pager .disabled>a:hover,.pager .disabled>a:focus,.pager .disabled>span{color:#777;background-color:#fff;cursor:not-allowed}.label{display:inline;padding:.2em .6em .3em;font-size:75%;font-weight:bold;line-height:1;color:#fff;text-align:center;white-space:nowrap;vertical-align:baseline;border-radius:.25em}a.label:hover,a.label:focus{color:#fff;text-decoration:none;cursor:pointer}.label:empty{display:none}.btn .label{position:relative;top:-1px}.label-default{background-color:#777}.label-default[href]:hover,.label-default[href]:focus{background-color:#5e5e5e}.label-primary{background-color:#337ab7}.label-primary[href]:hover,.label-primary[href]:focus{background-color:#286090}.label-success{background-color:#5cb85c}.label-success[href]:hover,.label-success[href]:focus{background-color:#449d44}.label-info{background-color:#5bc0de}.label-info[href]:hover,.label-info[href]:focus{background-color:#31b0d5}.label-warning{background-color:#f0ad4e}.label-warning[href]:hover,.label-warning[href]:focus{background-color:#ec971f}.label-danger{background-color:#d9534f}.label-danger[href]:hover,.label-danger[href]:focus{background-color:#c9302c}.badge{display:inline-block;min-width:10px;padding:3px 7px;font-size:12px;font-weight:bold;color:#fff;line-height:1;vertical-align:middle;white-space:nowrap;text-align:center;background-color:#777;border-radius:10px}.badge:empty{display:none}.btn .badge{position:relative;top:-1px}.btn-xs .badge,.btn-group-xs>.btn .badge{top:0;padding:1px 5px}a.badge:hover,a.badge:focus{color:#fff;text-decoration:none;cursor:pointer}.list-group-item.active>.badge,.nav-pills>.active>a>.badge{color:#337ab7;background-color:#fff}.list-group-item>.badge{float:right}.list-group-item>.badge+.badge{margin-right:5px}.nav-pills>li>a>.badge{margin-left:3px}.jumbotron{padding-top:30px;padding-bottom:30px;margin-bottom:30px;color:inherit;background-color:#eee}.jumbotron h1,.jumbotron .h1{color:inherit}.jumbotron p{margin-bottom:15px;font-size:21px;font-weight:200}.jumbotron>hr{border-top-color:#d5d5d5}.container .jumbotron,.container-fluid .jumbotron{border-radius:6px}.jumbotron .container{max-width:100%}@media screen and (min-width:768px){.jumbotron{padding-top:48px;padding-bottom:48px}.container .jumbotron,.container-fluid .jumbotron{padding-left:60px;padding-right:60px}.jumbotron h1,.jumbotron .h1{font-size:63px}}.thumbnail{display:block;padding:4px;margin-bottom:20px;line-height:1.42857143;background-color:#fff;border:1px solid #ddd;border-radius:4px;-webkit-transition:border .2s ease-in-out;-o-transition:border .2s ease-in-out;transition:border .2s ease-in-out}.thumbnail>img,.thumbnail a>img{margin-left:auto;margin-right:auto}a.thumbnail:hover,a.thumbnail:focus,a.thumbnail.active{border-color:#337ab7}.thumbnail .caption{padding:9px;color:#333}.alert{padding:15px;margin-bottom:20px;border:1px solid transparent;border-radius:4px}.alert h4{margin-top:0;color:inherit}.alert .alert-link{font-weight:bold}.alert>p,.alert>ul{margin-bottom:0}.alert>p+p{margin-top:5px}.alert-dismissable,.alert-dismissible{padding-right:35px}.alert-dismissable .close,.alert-dismissible .close{position:relative;top:-2px;right:-21px;color:inherit}.alert-success{background-color:#dff0d8;border-color:#d6e9c6;color:#3c763d}.alert-success hr{border-top-color:#c9e2b3}.alert-success .alert-link{color:#2b542c}.alert-info{background-color:#d9edf7;border-color:#bce8f1;color:#31708f}.alert-info hr{border-top-color:#a6e1ec}.alert-info .alert-link{color:#245269}.alert-warning{background-color:#fcf8e3;border-color:#faebcc;color:#8a6d3b}.alert-warning hr{border-top-color:#f7e1b5}.alert-warning .alert-link{color:#66512c}.alert-danger{background-color:#f2dede;border-color:#ebccd1;color:#a94442}.alert-danger hr{border-top-color:#e4b9c0}.alert-danger .alert-link{color:#843534}@-webkit-keyframes progress-bar-stripes{from{background-position:40px 0}to{background-position:0 0}}@-o-keyframes progress-bar-stripes{from{background-position:40px 0}to{background-position:0 0}}@keyframes progress-bar-stripes{from{background-position:40px 0}to{background-position:0 0}}.progress{overflow:hidden;height:20px;margin-bottom:20px;background-color:#f5f5f5;border-radius:4px;-webkit-box-shadow:inset 0 1px 2px rgba(0,0,0,0.1);box-shadow:inset 0 1px 2px rgba(0,0,0,0.1)}.progress-bar{float:left;width:0%;height:100%;font-size:12px;line-height:20px;color:#fff;text-align:center;background-color:#337ab7;-webkit-box-shadow:inset 0 -1px 0 rgba(0,0,0,0.15);box-shadow:inset 0 -1px 0 rgba(0,0,0,0.15);-webkit-transition:width .6s ease;-o-transition:width .6s ease;transition:width .6s ease}.progress-striped .progress-bar,.progress-bar-striped{background-image:-webkit-linear-gradient(45deg, rgba(255,255,255,0.15) 25%, transparent 25%, transparent 50%, rgba(255,255,255,0.15) 50%, rgba(255,255,255,0.15) 75%, transparent 75%, transparent);background-image:-o-linear-gradient(45deg, rgba(255,255,255,0.15) 25%, transparent 25%, transparent 50%, rgba(255,255,255,0.15) 50%, rgba(255,255,255,0.15) 75%, transparent 75%, transparent);background-image:linear-gradient(45deg, rgba(255,255,255,0.15) 25%, transparent 25%, transparent 50%, rgba(255,255,255,0.15) 50%, rgba(255,255,255,0.15) 75%, transparent 75%, transparent);-webkit-background-size:40px 40px;background-size:40px 40px}.progress.active .progress-bar,.progress-bar.active{-webkit-animation:progress-bar-stripes 2s linear infinite;-o-animation:progress-bar-stripes 2s linear infinite;animation:progress-bar-stripes 2s linear infinite}.progress-bar-success{background-color:#5cb85c}.progress-striped .progress-bar-success{background-image:-webkit-linear-gradient(45deg, rgba(255,255,255,0.15) 25%, transparent 25%, transparent 50%, rgba(255,255,255,0.15) 50%, rgba(255,255,255,0.15) 75%, transparent 75%, transparent);background-image:-o-linear-gradient(45deg, rgba(255,255,255,0.15) 25%, transparent 25%, transparent 50%, rgba(255,255,255,0.15) 50%, rgba(255,255,255,0.15) 75%, transparent 75%, transparent);background-image:linear-gradient(45deg, rgba(255,255,255,0.15) 25%, transparent 25%, transparent 50%, rgba(255,255,255,0.15) 50%, rgba(255,255,255,0.15) 75%, transparent 75%, transparent)}.progress-bar-info{background-color:#5bc0de}.progress-striped .progress-bar-info{background-image:-webkit-linear-gradient(45deg, rgba(255,255,255,0.15) 25%, transparent 25%, transparent 50%, rgba(255,255,255,0.15) 50%, rgba(255,255,255,0.15) 75%, transparent 75%, transparent);background-image:-o-linear-gradient(45deg, rgba(255,255,255,0.15) 25%, transparent 25%, transparent 50%, rgba(255,255,255,0.15) 50%, rgba(255,255,255,0.15) 75%, transparent 75%, transparent);background-image:linear-gradient(45deg, rgba(255,255,255,0.15) 25%, transparent 25%, transparent 50%, rgba(255,255,255,0.15) 50%, rgba(255,255,255,0.15) 75%, transparent 75%, transparent)}.progress-bar-warning{background-color:#f0ad4e}.progress-striped .progress-bar-warning{background-image:-webkit-linear-gradient(45deg, rgba(255,255,255,0.15) 25%, transparent 25%, transparent 50%, rgba(255,255,255,0.15) 50%, rgba(255,255,255,0.15) 75%, transparent 75%, transparent);background-image:-o-linear-gradient(45deg, rgba(255,255,255,0.15) 25%, transparent 25%, transparent 50%, rgba(255,255,255,0.15) 50%, rgba(255,255,255,0.15) 75%, transparent 75%, transparent);background-image:linear-gradient(45deg, rgba(255,255,255,0.15) 25%, transparent 25%, transparent 50%, rgba(255,255,255,0.15) 50%, rgba(255,255,255,0.15) 75%, transparent 75%, transparent)}.progress-bar-danger{background-color:#d9534f}.progress-striped .progress-bar-danger{background-image:-webkit-linear-gradient(45deg, rgba(255,255,255,0.15) 25%, transparent 25%, transparent 50%, rgba(255,255,255,0.15) 50%, rgba(255,255,255,0.15) 75%, transparent 75%, transparent);background-image:-o-linear-gradient(45deg, rgba(255,255,255,0.15) 25%, transparent 25%, transparent 50%, rgba(255,255,255,0.15) 50%, rgba(255,255,255,0.15) 75%, transparent 75%, transparent);background-image:linear-gradient(45deg, rgba(255,255,255,0.15) 25%, transparent 25%, transparent 50%, rgba(255,255,255,0.15) 50%, rgba(255,255,255,0.15) 75%, transparent 75%, transparent)}.media{margin-top:15px}.media:first-child{margin-top:0}.media,.media-body{zoom:1;overflow:hidden}.media-body{width:10000px}.media-object{display:block}.media-object.img-thumbnail{max-width:none}.media-right,.media>.pull-right{padding-left:10px}.media-left,.media>.pull-left{padding-right:10px}.media-left,.media-right,.media-body{display:table-cell;vertical-align:top}.media-middle{vertical-align:middle}.media-bottom{vertical-align:bottom}.media-heading{margin-top:0;margin-bottom:5px}.media-list{padding-left:0;list-style:none}.list-group{margin-bottom:20px;padding-left:0}.list-group-item{position:relative;display:block;padding:10px 15px;margin-bottom:-1px;background-color:#fff;border:1px solid #ddd}.list-group-item:first-child{border-top-right-radius:4px;border-top-left-radius:4px}.list-group-item:last-child{margin-bottom:0;border-bottom-right-radius:4px;border-bottom-left-radius:4px}a.list-group-item,button.list-group-item{color:#555}a.list-group-item .list-group-item-heading,button.list-group-item .list-group-item-heading{color:#333}a.list-group-item:hover,button.list-group-item:hover,a.list-group-item:focus,button.list-group-item:focus{text-decoration:none;color:#555;background-color:#f5f5f5}button.list-group-item{width:100%;text-align:left}.list-group-item.disabled,.list-group-item.disabled:hover,.list-group-item.disabled:focus{background-color:#eee;color:#777;cursor:not-allowed}.list-group-item.disabled .list-group-item-heading,.list-group-item.disabled:hover .list-group-item-heading,.list-group-item.disabled:focus .list-group-item-heading{color:inherit}.list-group-item.disabled .list-group-item-text,.list-group-item.disabled:hover .list-group-item-text,.list-group-item.disabled:focus .list-group-item-text{color:#777}.list-group-item.active,.list-group-item.active:hover,.list-group-item.active:focus{z-index:2;color:#fff;background-color:#337ab7;border-color:#337ab7}.list-group-item.active .list-group-item-heading,.list-group-item.active:hover .list-group-item-heading,.list-group-item.active:focus .list-group-item-heading,.list-group-item.active .list-group-item-heading>small,.list-group-item.active:hover .list-group-item-heading>small,.list-group-item.active:focus .list-group-item-heading>small,.list-group-item.active .list-group-item-heading>.small,.list-group-item.active:hover .list-group-item-heading>.small,.list-group-item.active:focus .list-group-item-heading>.small{color:inherit}.list-group-item.active .list-group-item-text,.list-group-item.active:hover .list-group-item-text,.list-group-item.active:focus .list-group-item-text{color:#c7ddef}.list-group-item-success{color:#3c763d;background-color:#dff0d8}a.list-group-item-success,button.list-group-item-success{color:#3c763d}a.list-group-item-success .list-group-item-heading,button.list-group-item-success .list-group-item-heading{color:inherit}a.list-group-item-success:hover,button.list-group-item-success:hover,a.list-group-item-success:focus,button.list-group-item-success:focus{color:#3c763d;background-color:#d0e9c6}a.list-group-item-success.active,button.list-group-item-success.active,a.list-group-item-success.active:hover,button.list-group-item-success.active:hover,a.list-group-item-success.active:focus,button.list-group-item-success.active:focus{color:#fff;background-color:#3c763d;border-color:#3c763d}.list-group-item-info{color:#31708f;background-color:#d9edf7}a.list-group-item-info,button.list-group-item-info{color:#31708f}a.list-group-item-info .list-group-item-heading,button.list-group-item-info .list-group-item-heading{color:inherit}a.list-group-item-info:hover,button.list-group-item-info:hover,a.list-group-item-info:focus,button.list-group-item-info:focus{color:#31708f;background-color:#c4e3f3}a.list-group-item-info.active,button.list-group-item-info.active,a.list-group-item-info.active:hover,button.list-group-item-info.active:hover,a.list-group-item-info.active:focus,button.list-group-item-info.active:focus{color:#fff;background-color:#31708f;border-color:#31708f}.list-group-item-warning{color:#8a6d3b;background-color:#fcf8e3}a.list-group-item-warning,button.list-group-item-warning{color:#8a6d3b}a.list-group-item-warning .list-group-item-heading,button.list-group-item-warning .list-group-item-heading{color:inherit}a.list-group-item-warning:hover,button.list-group-item-warning:hover,a.list-group-item-warning:focus,button.list-group-item-warning:focus{color:#8a6d3b;background-color:#faf2cc}a.list-group-item-warning.active,button.list-group-item-warning.active,a.list-group-item-warning.active:hover,button.list-group-item-warning.active:hover,a.list-group-item-warning.active:focus,button.list-group-item-warning.active:focus{color:#fff;background-color:#8a6d3b;border-color:#8a6d3b}.list-group-item-danger{color:#a94442;background-color:#f2dede}a.list-group-item-danger,button.list-group-item-danger{color:#a94442}a.list-group-item-danger .list-group-item-heading,button.list-group-item-danger .list-group-item-heading{color:inherit}a.list-group-item-danger:hover,button.list-group-item-danger:hover,a.list-group-item-danger:focus,button.list-group-item-danger:focus{color:#a94442;background-color:#ebcccc}a.list-group-item-danger.active,button.list-group-item-danger.active,a.list-group-item-danger.active:hover,button.list-group-item-danger.active:hover,a.list-group-item-danger.active:focus,button.list-group-item-danger.active:focus{color:#fff;background-color:#a94442;border-color:#a94442}.list-group-item-heading{margin-top:0;margin-bottom:5px}.list-group-item-text{margin-bottom:0;line-height:1.3}.panel{margin-bottom:20px;background-color:#fff;border:1px solid transparent;border-radius:4px;-webkit-box-shadow:0 1px 1px rgba(0,0,0,0.05);box-shadow:0 1px 1px rgba(0,0,0,0.05)}.panel-body{padding:15px}.panel-heading{padding:10px 15px;border-bottom:1px solid transparent;border-top-right-radius:3px;border-top-left-radius:3px}.panel-heading>.dropdown .dropdown-toggle{color:inherit}.panel-title{margin-top:0;margin-bottom:0;font-size:16px;color:inherit}.panel-title>a,.panel-title>small,.panel-title>.small,.panel-title>small>a,.panel-title>.small>a{color:inherit}.panel-footer{padding:10px 15px;background-color:#f5f5f5;border-top:1px solid #ddd;border-bottom-right-radius:3px;border-bottom-left-radius:3px}.panel>.list-group,.panel>.panel-collapse>.list-group{margin-bottom:0}.panel>.list-group .list-group-item,.panel>.panel-collapse>.list-group .list-group-item{border-width:1px 0;border-radius:0}.panel>.list-group:first-child .list-group-item:first-child,.panel>.panel-collapse>.list-group:first-child .list-group-item:first-child{border-top:0;border-top-right-radius:3px;border-top-left-radius:3px}.panel>.list-group:last-child .list-group-item:last-child,.panel>.panel-collapse>.list-group:last-child .list-group-item:last-child{border-bottom:0;border-bottom-right-radius:3px;border-bottom-left-radius:3px}.panel>.panel-heading+.panel-collapse>.list-group .list-group-item:first-child{border-top-right-radius:0;border-top-left-radius:0}.panel-heading+.list-group .list-group-item:first-child{border-top-width:0}.list-group+.panel-footer{border-top-width:0}.panel>.table,.panel>.table-responsive>.table,.panel>.panel-collapse>.table{margin-bottom:0}.panel>.table caption,.panel>.table-responsive>.table caption,.panel>.panel-collapse>.table caption{padding-left:15px;padding-right:15px}.panel>.table:first-child,.panel>.table-responsive:first-child>.table:first-child{border-top-right-radius:3px;border-top-left-radius:3px}.panel>.table:first-child>thead:first-child>tr:first-child,.panel>.table-responsive:first-child>.table:first-child>thead:first-child>tr:first-child,.panel>.table:first-child>tbody:first-child>tr:first-child,.panel>.table-responsive:first-child>.table:first-child>tbody:first-child>tr:first-child{border-top-left-radius:3px;border-top-right-radius:3px}.panel>.table:first-child>thead:first-child>tr:first-child td:first-child,.panel>.table-responsive:first-child>.table:first-child>thead:first-child>tr:first-child td:first-child,.panel>.table:first-child>tbody:first-child>tr:first-child td:first-child,.panel>.table-responsive:first-child>.table:first-child>tbody:first-child>tr:first-child td:first-child,.panel>.table:first-child>thead:first-child>tr:first-child th:first-child,.panel>.table-responsive:first-child>.table:first-child>thead:first-child>tr:first-child th:first-child,.panel>.table:first-child>tbody:first-child>tr:first-child th:first-child,.panel>.table-responsive:first-child>.table:first-child>tbody:first-child>tr:first-child th:first-child{border-top-left-radius:3px}.panel>.table:first-child>thead:first-child>tr:first-child td:last-child,.panel>.table-responsive:first-child>.table:first-child>thead:first-child>tr:first-child td:last-child,.panel>.table:first-child>tbody:first-child>tr:first-child td:last-child,.panel>.table-responsive:first-child>.table:first-child>tbody:first-child>tr:first-child td:last-child,.panel>.table:first-child>thead:first-child>tr:first-child th:last-child,.panel>.table-responsive:first-child>.table:first-child>thead:first-child>tr:first-child th:last-child,.panel>.table:first-child>tbody:first-child>tr:first-child th:last-child,.panel>.table-responsive:first-child>.table:first-child>tbody:first-child>tr:first-child th:last-child{border-top-right-radius:3px}.panel>.table:last-child,.panel>.table-responsive:last-child>.table:last-child{border-bottom-right-radius:3px;border-bottom-left-radius:3px}.panel>.table:last-child>tbody:last-child>tr:last-child,.panel>.table-responsive:last-child>.table:last-child>tbody:last-child>tr:last-child,.panel>.table:last-child>tfoot:last-child>tr:last-child,.panel>.table-responsive:last-child>.table:last-child>tfoot:last-child>tr:last-child{border-bottom-left-radius:3px;border-bottom-right-radius:3px}.panel>.table:last-child>tbody:last-child>tr:last-child td:first-child,.panel>.table-responsive:last-child>.table:last-child>tbody:last-child>tr:last-child td:first-child,.panel>.table:last-child>tfoot:last-child>tr:last-child td:first-child,.panel>.table-responsive:last-child>.table:last-child>tfoot:last-child>tr:last-child td:first-child,.panel>.table:last-child>tbody:last-child>tr:last-child th:first-child,.panel>.table-responsive:last-child>.table:last-child>tbody:last-child>tr:last-child th:first-child,.panel>.table:last-child>tfoot:last-child>tr:last-child th:first-child,.panel>.table-responsive:last-child>.table:last-child>tfoot:last-child>tr:last-child th:first-child{border-bottom-left-radius:3px}.panel>.table:last-child>tbody:last-child>tr:last-child td:last-child,.panel>.table-responsive:last-child>.table:last-child>tbody:last-child>tr:last-child td:last-child,.panel>.table:last-child>tfoot:last-child>tr:last-child td:last-child,.panel>.table-responsive:last-child>.table:last-child>tfoot:last-child>tr:last-child td:last-child,.panel>.table:last-child>tbody:last-child>tr:last-child th:last-child,.panel>.table-responsive:last-child>.table:last-child>tbody:last-child>tr:last-child th:last-child,.panel>.table:last-child>tfoot:last-child>tr:last-child th:last-child,.panel>.table-responsive:last-child>.table:last-child>tfoot:last-child>tr:last-child th:last-child{border-bottom-right-radius:3px}.panel>.panel-body+.table,.panel>.panel-body+.table-responsive,.panel>.table+.panel-body,.panel>.table-responsive+.panel-body{border-top:1px solid #ddd}.panel>.table>tbody:first-child>tr:first-child th,.panel>.table>tbody:first-child>tr:first-child td{border-top:0}.panel>.table-bordered,.panel>.table-responsive>.table-bordered{border:0}.panel>.table-bordered>thead>tr>th:first-child,.panel>.table-responsive>.table-bordered>thead>tr>th:first-child,.panel>.table-bordered>tbody>tr>th:first-child,.panel>.table-responsive>.table-bordered>tbody>tr>th:first-child,.panel>.table-bordered>tfoot>tr>th:first-child,.panel>.table-responsive>.table-bordered>tfoot>tr>th:first-child,.panel>.table-bordered>thead>tr>td:first-child,.panel>.table-responsive>.table-bordered>thead>tr>td:first-child,.panel>.table-bordered>tbody>tr>td:first-child,.panel>.table-responsive>.table-bordered>tbody>tr>td:first-child,.panel>.table-bordered>tfoot>tr>td:first-child,.panel>.table-responsive>.table-bordered>tfoot>tr>td:first-child{border-left:0}.panel>.table-bordered>thead>tr>th:last-child,.panel>.table-responsive>.table-bordered>thead>tr>th:last-child,.panel>.table-bordered>tbody>tr>th:last-child,.panel>.table-responsive>.table-bordered>tbody>tr>th:last-child,.panel>.table-bordered>tfoot>tr>th:last-child,.panel>.table-responsive>.table-bordered>tfoot>tr>th:last-child,.panel>.table-bordered>thead>tr>td:last-child,.panel>.table-responsive>.table-bordered>thead>tr>td:last-child,.panel>.table-bordered>tbody>tr>td:last-child,.panel>.table-responsive>.table-bordered>tbody>tr>td:last-child,.panel>.table-bordered>tfoot>tr>td:last-child,.panel>.table-responsive>.table-bordered>tfoot>tr>td:last-child{border-right:0}.panel>.table-bordered>thead>tr:first-child>td,.panel>.table-responsive>.table-bordered>thead>tr:first-child>td,.panel>.table-bordered>tbody>tr:first-child>td,.panel>.table-responsive>.table-bordered>tbody>tr:first-child>td,.panel>.table-bordered>thead>tr:first-child>th,.panel>.table-responsive>.table-bordered>thead>tr:first-child>th,.panel>.table-bordered>tbody>tr:first-child>th,.panel>.table-responsive>.table-bordered>tbody>tr:first-child>th{border-bottom:0}.panel>.table-bordered>tbody>tr:last-child>td,.panel>.table-responsive>.table-bordered>tbody>tr:last-child>td,.panel>.table-bordered>tfoot>tr:last-child>td,.panel>.table-responsive>.table-bordered>tfoot>tr:last-child>td,.panel>.table-bordered>tbody>tr:last-child>th,.panel>.table-responsive>.table-bordered>tbody>tr:last-child>th,.panel>.table-bordered>tfoot>tr:last-child>th,.panel>.table-responsive>.table-bordered>tfoot>tr:last-child>th{border-bottom:0}.panel>.table-responsive{border:0;margin-bottom:0}.panel-group{margin-bottom:20px}.panel-group .panel{margin-bottom:0;border-radius:4px}.panel-group .panel+.panel{margin-top:5px}.panel-group .panel-heading{border-bottom:0}.panel-group .panel-heading+.panel-collapse>.panel-body,.panel-group .panel-heading+.panel-collapse>.list-group{border-top:1px solid #ddd}.panel-group .panel-footer{border-top:0}.panel-group .panel-footer+.panel-collapse .panel-body{border-bottom:1px solid #ddd}.panel-default{border-color:#ddd}.panel-default>.panel-heading{color:#333;background-color:#f5f5f5;border-color:#ddd}.panel-default>.panel-heading+.panel-collapse>.panel-body{border-top-color:#ddd}.panel-default>.panel-heading .badge{color:#f5f5f5;background-color:#333}.panel-default>.panel-footer+.panel-collapse>.panel-body{border-bottom-color:#ddd}.panel-primary{border-color:#337ab7}.panel-primary>.panel-heading{color:#fff;background-color:#337ab7;border-color:#337ab7}.panel-primary>.panel-heading+.panel-collapse>.panel-body{border-top-color:#337ab7}.panel-primary>.panel-heading .badge{color:#337ab7;background-color:#fff}.panel-primary>.panel-footer+.panel-collapse>.panel-body{border-bottom-color:#337ab7}.panel-success{border-color:#d6e9c6}.panel-success>.panel-heading{color:#3c763d;background-color:#dff0d8;border-color:#d6e9c6}.panel-success>.panel-heading+.panel-collapse>.panel-body{border-top-color:#d6e9c6}.panel-success>.panel-heading .badge{color:#dff0d8;background-color:#3c763d}.panel-success>.panel-footer+.panel-collapse>.panel-body{border-bottom-color:#d6e9c6}.panel-info{border-color:#bce8f1}.panel-info>.panel-heading{color:#31708f;background-color:#d9edf7;border-color:#bce8f1}.panel-info>.panel-heading+.panel-collapse>.panel-body{border-top-color:#bce8f1}.panel-info>.panel-heading .badge{color:#d9edf7;background-color:#31708f}.panel-info>.panel-footer+.panel-collapse>.panel-body{border-bottom-color:#bce8f1}.panel-warning{border-color:#faebcc}.panel-warning>.panel-heading{color:#8a6d3b;background-color:#fcf8e3;border-color:#faebcc}.panel-warning>.panel-heading+.panel-collapse>.panel-body{border-top-color:#faebcc}.panel-warning>.panel-heading .badge{color:#fcf8e3;background-color:#8a6d3b}.panel-warning>.panel-footer+.panel-collapse>.panel-body{border-bottom-color:#faebcc}.panel-danger{border-color:#ebccd1}.panel-danger>.panel-heading{color:#a94442;background-color:#f2dede;border-color:#ebccd1}.panel-danger>.panel-heading+.panel-collapse>.panel-body{border-top-color:#ebccd1}.panel-danger>.panel-heading .badge{color:#f2dede;background-color:#a94442}.panel-danger>.panel-footer+.panel-collapse>.panel-body{border-bottom-color:#ebccd1}.embed-responsive{position:relative;display:block;height:0;padding:0;overflow:hidden}.embed-responsive .embed-responsive-item,.embed-responsive iframe,.embed-responsive embed,.embed-responsive object,.embed-responsive video{position:absolute;top:0;left:0;bottom:0;height:100%;width:100%;border:0}.embed-responsive-16by9{padding-bottom:56.25%}.embed-responsive-4by3{padding-bottom:75%}.well{min-height:20px;padding:19px;margin-bottom:20px;background-color:#f5f5f5;border:1px solid #e3e3e3;border-radius:4px;-webkit-box-shadow:inset 0 1px 1px rgba(0,0,0,0.05);box-shadow:inset 0 1px 1px rgba(0,0,0,0.05)}.well blockquote{border-color:#ddd;border-color:rgba(0,0,0,0.15)}.well-lg{padding:24px;border-radius:6px}.well-sm{padding:9px;border-radius:3px}.close{float:right;font-size:21px;font-weight:bold;line-height:1;color:#000;text-shadow:0 1px 0 #fff;opacity:.2;filter:alpha(opacity=20)}.close:hover,.close:focus{color:#000;text-decoration:none;cursor:pointer;opacity:.5;filter:alpha(opacity=50)}button.close{padding:0;cursor:pointer;background:transparent;border:0;-webkit-appearance:none}.modal-open{overflow:hidden}.modal{display:none;overflow:hidden;position:fixed;top:0;right:0;bottom:0;left:0;z-index:1050;-webkit-overflow-scrolling:touch;outline:0}.modal.fade .modal-dialog{-webkit-transform:translate(0, -25%);-ms-transform:translate(0, -25%);-o-transform:translate(0, -25%);transform:translate(0, -25%);-webkit-transition:-webkit-transform 0.3s ease-out;-o-transition:-o-transform 0.3s ease-out;transition:transform 0.3s ease-out}.modal.in .modal-dialog{-webkit-transform:translate(0, 0);-ms-transform:translate(0, 0);-o-transform:translate(0, 0);transform:translate(0, 0)}.modal-open .modal{overflow-x:hidden;overflow-y:auto}.modal-dialog{position:relative;width:auto;margin:10px}.modal-content{position:relative;background-color:#fff;border:1px solid #999;border:1px solid rgba(0,0,0,0.2);border-radius:6px;-webkit-box-shadow:0 3px 9px rgba(0,0,0,0.5);box-shadow:0 3px 9px rgba(0,0,0,0.5);-webkit-background-clip:padding-box;background-clip:padding-box;outline:0}.modal-backdrop{position:fixed;top:0;right:0;bottom:0;left:0;z-index:1040;background-color:#000}.modal-backdrop.fade{opacity:0;filter:alpha(opacity=0)}.modal-backdrop.in{opacity:.5;filter:alpha(opacity=50)}.modal-header{padding:15px;border-bottom:1px solid #e5e5e5;min-height:16.42857143px}.modal-header .close{margin-top:-2px}.modal-title{margin:0;line-height:1.42857143}.modal-body{position:relative;padding:15px}.modal-footer{padding:15px;text-align:right;border-top:1px solid #e5e5e5}.modal-footer .btn+.btn{margin-left:5px;margin-bottom:0}.modal-footer .btn-group .btn+.btn{margin-left:-1px}.modal-footer .btn-block+.btn-block{margin-left:0}.modal-scrollbar-measure{position:absolute;top:-9999px;width:50px;height:50px;overflow:scroll}@media (min-width:768px){.modal-dialog{width:600px;margin:30px auto}.modal-content{-webkit-box-shadow:0 5px 15px rgba(0,0,0,0.5);box-shadow:0 5px 15px rgba(0,0,0,0.5)}.modal-sm{width:300px}}@media (min-width:992px){.modal-lg{width:900px}}.tooltip{position:absolute;z-index:1070;display:block;font-family:"Helvetica Neue",Helvetica,Arial,sans-serif;font-style:normal;font-weight:normal;letter-spacing:normal;line-break:auto;line-height:1.42857143;text-align:left;text-align:start;text-decoration:none;text-shadow:none;text-transform:none;white-space:normal;word-break:normal;word-spacing:normal;word-wrap:normal;font-size:12px;opacity:0;filter:alpha(opacity=0)}.tooltip.in{opacity:.9;filter:alpha(opacity=90)}.tooltip.top{margin-top:-3px;padding:5px 0}.tooltip.right{margin-left:3px;padding:0 5px}.tooltip.bottom{margin-top:3px;padding:5px 0}.tooltip.left{margin-left:-3px;padding:0 5px}.tooltip-inner{max-width:200px;padding:3px 8px;color:#fff;text-align:center;background-color:#000;border-radius:4px}.tooltip-arrow{position:absolute;width:0;height:0;border-color:transparent;border-style:solid}.tooltip.top .tooltip-arrow{bottom:0;left:50%;margin-left:-5px;border-width:5px 5px 0;border-top-color:#000}.tooltip.top-left .tooltip-arrow{bottom:0;right:5px;margin-bottom:-5px;border-width:5px 5px 0;border-top-color:#000}.tooltip.top-right .tooltip-arrow{bottom:0;left:5px;margin-bottom:-5px;border-width:5px 5px 0;border-top-color:#000}.tooltip.right .tooltip-arrow{top:50%;left:0;margin-top:-5px;border-width:5px 5px 5px 0;border-right-color:#000}.tooltip.left .tooltip-arrow{top:50%;right:0;margin-top:-5px;border-width:5px 0 5px 5px;border-left-color:#000}.tooltip.bottom .tooltip-arrow{top:0;left:50%;margin-left:-5px;border-width:0 5px 5px;border-bottom-color:#000}.tooltip.bottom-left .tooltip-arrow{top:0;right:5px;margin-top:-5px;border-width:0 5px 5px;border-bottom-color:#000}.tooltip.bottom-right .tooltip-arrow{top:0;left:5px;margin-top:-5px;border-width:0 5px 5px;border-bottom-color:#000}.popover{position:absolute;top:0;left:0;z-index:1060;display:none;max-width:276px;padding:1px;font-family:"Helvetica Neue",Helvetica,Arial,sans-serif;font-style:normal;font-weight:normal;letter-spacing:normal;line-break:auto;line-height:1.42857143;text-align:left;text-align:start;text-decoration:none;text-shadow:none;text-transform:none;white-space:normal;word-break:normal;word-spacing:normal;word-wrap:normal;font-size:14px;background-color:#fff;-webkit-background-clip:padding-box;background-clip:padding-box;border:1px solid #ccc;border:1px solid rgba(0,0,0,0.2);border-radius:6px;-webkit-box-shadow:0 5px 10px rgba(0,0,0,0.2);box-shadow:0 5px 10px rgba(0,0,0,0.2)}.popover.top{margin-top:-10px}.popover.right{margin-left:10px}.popover.bottom{margin-top:10px}.popover.left{margin-left:-10px}.popover-title{margin:0;padding:8px 14px;font-size:14px;background-color:#f7f7f7;border-bottom:1px solid #ebebeb;border-radius:5px 5px 0 0}.popover-content{padding:9px 14px}.popover>.arrow,.popover>.arrow:after{position:absolute;display:block;width:0;height:0;border-color:transparent;border-style:solid}.popover>.arrow{border-width:11px}.popover>.arrow:after{border-width:10px;content:""}.popover.top>.arrow{left:50%;margin-left:-11px;border-bottom-width:0;border-top-color:#999;border-top-color:rgba(0,0,0,0.25);bottom:-11px}.popover.top>.arrow:after{content:" ";bottom:1px;margin-left:-10px;border-bottom-width:0;border-top-color:#fff}.popover.right>.arrow{top:50%;left:-11px;margin-top:-11px;border-left-width:0;border-right-color:#999;border-right-color:rgba(0,0,0,0.25)}.popover.right>.arrow:after{content:" ";left:1px;bottom:-10px;border-left-width:0;border-right-color:#fff}.popover.bottom>.arrow{left:50%;margin-left:-11px;border-top-width:0;border-bottom-color:#999;border-bottom-color:rgba(0,0,0,0.25);top:-11px}.popover.bottom>.arrow:after{content:" ";top:1px;margin-left:-10px;border-top-width:0;border-bottom-color:#fff}.popover.left>.arrow{top:50%;right:-11px;margin-top:-11px;border-right-width:0;border-left-color:#999;border-left-color:rgba(0,0,0,0.25)}.popover.left>.arrow:after{content:" ";right:1px;border-right-width:0;border-left-color:#fff;bottom:-10px}.carousel{position:relative}.carousel-inner{position:relative;overflow:hidden;width:100%}.carousel-inner>.item{display:none;position:relative;-webkit-transition:.6s ease-in-out left;-o-transition:.6s ease-in-out left;transition:.6s ease-in-out left}.carousel-inner>.item>img,.carousel-inner>.item>a>img{line-height:1}@media all and (transform-3d),(-webkit-transform-3d){.carousel-inner>.item{-webkit-transition:-webkit-transform 0.6s ease-in-out;-o-transition:-o-transform 0.6s ease-in-out;transition:transform 0.6s ease-in-out;-webkit-backface-visibility:hidden;backface-visibility:hidden;-webkit-perspective:1000px;perspective:1000px}.carousel-inner>.item.next,.carousel-inner>.item.active.right{-webkit-transform:translate3d(100%, 0, 0);transform:translate3d(100%, 0, 0);left:0}.carousel-inner>.item.prev,.carousel-inner>.item.active.left{-webkit-transform:translate3d(-100%, 0, 0);transform:translate3d(-100%, 0, 0);left:0}.carousel-inner>.item.next.left,.carousel-inner>.item.prev.right,.carousel-inner>.item.active{-webkit-transform:translate3d(0, 0, 0);transform:translate3d(0, 0, 0);left:0}}.carousel-inner>.active,.carousel-inner>.next,.carousel-inner>.prev{display:block}.carousel-inner>.active{left:0}.carousel-inner>.next,.carousel-inner>.prev{position:absolute;top:0;width:100%}.carousel-inner>.next{left:100%}.carousel-inner>.prev{left:-100%}.carousel-inner>.next.left,.carousel-inner>.prev.right{left:0}.carousel-inner>.active.left{left:-100%}.carousel-inner>.active.right{left:100%}.carousel-control{position:absolute;top:0;left:0;bottom:0;width:15%;opacity:.5;filter:alpha(opacity=50);font-size:20px;color:#fff;text-align:center;text-shadow:0 1px 2px rgba(0,0,0,0.6)}.carousel-control.left{background-image:-webkit-linear-gradient(left, rgba(0,0,0,0.5) 0, rgba(0,0,0,0.0001) 100%);background-image:-o-linear-gradient(left, rgba(0,0,0,0.5) 0, rgba(0,0,0,0.0001) 100%);background-image:-webkit-gradient(linear, left top, right top, color-stop(0, rgba(0,0,0,0.5)), to(rgba(0,0,0,0.0001)));background-image:linear-gradient(to right, rgba(0,0,0,0.5) 0, rgba(0,0,0,0.0001) 100%);background-repeat:repeat-x;filter:progid:DXImageTransform.Microsoft.gradient(startColorstr='#80000000', endColorstr='#00000000', GradientType=1)}.carousel-control.right{left:auto;right:0;background-image:-webkit-linear-gradient(left, rgba(0,0,0,0.0001) 0, rgba(0,0,0,0.5) 100%);background-image:-o-linear-gradient(left, rgba(0,0,0,0.0001) 0, rgba(0,0,0,0.5) 100%);background-image:-webkit-gradient(linear, left top, right top, color-stop(0, rgba(0,0,0,0.0001)), to(rgba(0,0,0,0.5)));background-image:linear-gradient(to right, rgba(0,0,0,0.0001) 0, rgba(0,0,0,0.5) 100%);background-repeat:repeat-x;filter:progid:DXImageTransform.Microsoft.gradient(startColorstr='#00000000', endColorstr='#80000000', GradientType=1)}.carousel-control:hover,.carousel-control:focus{outline:0;color:#fff;text-decoration:none;opacity:.9;filter:alpha(opacity=90)}.carousel-control .icon-prev,.carousel-control .icon-next,.carousel-control .glyphicon-chevron-left,.carousel-control .glyphicon-chevron-right{position:absolute;top:50%;margin-top:-10px;z-index:5;display:inline-block}.carousel-control .icon-prev,.carousel-control .glyphicon-chevron-left{left:50%;margin-left:-10px}.carousel-control .icon-next,.carousel-control .glyphicon-chevron-right{right:50%;margin-right:-10px}.carousel-control .icon-prev,.carousel-control .icon-next{width:20px;height:20px;line-height:1;font-family:serif}.carousel-control .icon-prev:before{content:'\2039'}.carousel-control .icon-next:before{content:'\203a'}.carousel-indicators{position:absolute;bottom:10px;left:50%;z-index:15;width:60%;margin-left:-30%;padding-left:0;list-style:none;text-align:center}.carousel-indicators li{display:inline-block;width:10px;height:10px;margin:1px;text-indent:-999px;border:1px solid #fff;border-radius:10px;cursor:pointer;background-color:#000 \9;background-color:rgba(0,0,0,0)}.carousel-indicators .active{margin:0;width:12px;height:12px;background-color:#fff}.carousel-caption{position:absolute;left:15%;right:15%;bottom:20px;z-index:10;padding-top:20px;padding-bottom:20px;color:#fff;text-align:center;text-shadow:0 1px 2px rgba(0,0,0,0.6)}.carousel-caption .btn{text-shadow:none}@media screen and (min-width:768px){.carousel-control .glyphicon-chevron-left,.carousel-control .glyphicon-chevron-right,.carousel-control .icon-prev,.carousel-control .icon-next{width:30px;height:30px;margin-top:-15px;font-size:30px}.carousel-control .glyphicon-chevron-left,.carousel-control .icon-prev{margin-left:-15px}.carousel-control .glyphicon-chevron-right,.carousel-control .icon-next{margin-right:-15px}.carousel-caption{left:20%;right:20%;padding-bottom:30px}.carousel-indicators{bottom:20px}}.clearfix:before,.clearfix:after,.dl-horizontal dd:before,.dl-horizontal dd:after,.container:before,.container:after,.container-fluid:before,.container-fluid:after,.row:before,.row:after,.form-horizontal .form-group:before,.form-horizontal .form-group:after,.btn-toolbar:before,.btn-toolbar:after,.btn-group-vertical>.btn-group:before,.btn-group-vertical>.btn-group:after,.nav:before,.nav:after,.navbar:before,.navbar:after,.navbar-header:before,.navbar-header:after,.navbar-collapse:before,.navbar-collapse:after,.pager:before,.pager:after,.panel-body:before,.panel-body:after,.modal-footer:before,.modal-footer:after{content:" ";display:table}.clearfix:after,.dl-horizontal dd:after,.container:after,.container-fluid:after,.row:after,.form-horizontal .form-group:after,.btn-toolbar:after,.btn-group-vertical>.btn-group:after,.nav:after,.navbar:after,.navbar-header:after,.navbar-collapse:after,.pager:after,.panel-body:after,.modal-footer:after{clear:both}.center-block{display:block;margin-left:auto;margin-right:auto}.pull-right{float:right !important}.pull-left{float:left !important}.hide{display:none !important}.show{display:block !important}.invisible{visibility:hidden}.text-hide{font:0/0 a;color:transparent;text-shadow:none;background-color:transparent;border:0}.hidden{display:none !important}.affix{position:fixed}@-ms-viewport{width:device-width}.visible-xs,.visible-sm,.visible-md,.visible-lg{display:none !important}.visible-xs-block,.visible-xs-inline,.visible-xs-inline-block,.visible-sm-block,.visible-sm-inline,.visible-sm-inline-block,.visible-md-block,.visible-md-inline,.visible-md-inline-block,.visible-lg-block,.visible-lg-inline,.visible-lg-inline-block{display:none !important}@media (max-width:767px){.visible-xs{display:block !important}table.visible-xs{display:table !important}tr.visible-xs{display:table-row !important}th.visible-xs,td.visible-xs{display:table-cell !important}}@media (max-width:767px){.visible-xs-block{display:block !important}}@media (max-width:767px){.visible-xs-inline{display:inline !important}}@media (max-width:767px){.visible-xs-inline-block{display:inline-block !important}}@media (min-width:768px) and (max-width:991px){.visible-sm{display:block !important}table.visible-sm{display:table !important}tr.visible-sm{display:table-row !important}th.visible-sm,td.visible-sm{display:table-cell !important}}@media (min-width:768px) and (max-width:991px){.visible-sm-block{display:block !important}}@media (min-width:768px) and (max-width:991px){.visible-sm-inline{display:inline !important}}@media (min-width:768px) and (max-width:991px){.visible-sm-inline-block{display:inline-block !important}}@media (min-width:992px) and (max-width:1199px){.visible-md{display:block !important}table.visible-md{display:table !important}tr.visible-md{display:table-row !important}th.visible-md,td.visible-md{display:table-cell !important}}@media (min-width:992px) and (max-width:1199px){.visible-md-block{display:block !important}}@media (min-width:992px) and (max-width:1199px){.visible-md-inline{display:inline !important}}@media (min-width:992px) and (max-width:1199px){.visible-md-inline-block{display:inline-block !important}}@media (min-width:1200px){.visible-lg{display:block !important}table.visible-lg{display:table !important}tr.visible-lg{display:table-row !important}th.visible-lg,td.visible-lg{display:table-cell !important}}@media (min-width:1200px){.visible-lg-block{display:block !important}}@media (min-width:1200px){.visible-lg-inline{display:inline !important}}@media (min-width:1200px){.visible-lg-inline-block{display:inline-block !important}}@media (max-width:767px){.hidden-xs{display:none !important}}@media (min-width:768px) and (max-width:991px){.hidden-sm{display:none !important}}@media (min-width:992px) and (max-width:1199px){.hidden-md{display:none !important}}@media (min-width:1200px){.hidden-lg{display:none !important}}.visible-print{display:none !important}@media print{.visible-print{display:block !important}table.visible-print{display:table !important}tr.visible-print{display:table-row !important}th.visible-print,td.visible-print{display:table-cell !important}}.visible-print-block{display:none !important}@media print{.visible-print-block{display:block !important}}.visible-print-inline{display:none !important}@media print{.visible-print-inline{display:inline !important}}.visible-print-inline-block{display:none !important}@media print{.visible-print-inline-block{display:inline-block !important}}@media print{.hidden-print{display:none !important}} \ No newline at end of file diff --git a/Webseiten/Docker - Build, Ship, and Run Any App, Anywhere_files/build.png b/Webseiten/Docker - Build, Ship, and Run Any App, Anywhere_files/build.png new file mode 100644 index 0000000000000000000000000000000000000000..b3004204b66fb5fb642a1e392e0ab2f6f27d930e GIT binary patch literal 16172 zcmeI3X;>528po$#MR6@kaY2m%L_nA<1V{*bSfVBPQ4!SZf>k11tqV}BfD#p@Qna^#dMAJ|B6e=?(~pzqN%H2L|NDQ>{LYg3 zGHFZLz7q^*7y{@aKihr<>rfu@b)!832r%qI-V^WaUf)04Gxc zCs-cLT1?}Kg?3!NI1I8=2_>)^0O)Qi36~cM$#G#&gh1qi?>Jk9#|ii@_#g_4z>;`D zYXp9AQfOHmo5PEXyyYMUGN^d zg1BJT5}cP<3gIYr6k8sFXpeKG+7T&4dne)o9Em_Ag9I{2B-;{6Gy;`Iq~Hc#cvnL> zqD%SVv;c@BB+wkVrPb4yFjIxDt?PM*v4k;`0V` zBnoL%-_ZCx5Q>6?kVr0r^N1tnN!EzvV%Zw;CrS=>f3h$8#Cdt)<_8Hxe6dnyMF)qgho*YS2x4&MkSn|t9c&3i zcpY+xR2qpyvnSXPC^P~AVbZT0=D`y41>vzHc{tI?RHO$&Iot!@I()92`#-rLwFn8#Dka& zSGd7WAmG!85ZN)DXwSFhal;{7f}=gvHjDs;*%HFY_T;cIDvwKW>VwE)A=5vyW{7zT z-9{O(=Kn=&MEXb8{!#&a$Z?|(8r|ssYKakSJ}TuWkiknc7O`aEh1++GErX&zY<=Gm zCFnbjBwVQs(rq>u{QKQDczz8YPr97GO-tkQbO)I$Pq!B!J{|m^b!b?FnFDEp|91lW z{SoP(uAy85iT-Ru^;`9+K5Zfshs%{*DdZ6WuL+cG-f#F}#&Bmks5|qc1Ru^pf9r=+ z^M0{@Je73aQAUH80X!sbAATYo{HSfHa=$)UH=R+6KD{G}0KY(@?sFg&**!cp!vd7m@~QjNw8>gcM-7kTg(Z3>PXQqyWQ(q=6b^xKI%x1sEr@|6;{bbh;Cxteq^@%5x9SJ7* zl(LeLir;%mToq4ttn|^8yl%Q#^SRy8TW3_Mzc$_UWc=FHqq(u(r8wQ8W}V@xD$4Q1 z)9fEw!YIbYj`qTzDa8JVI?zM%@uVOfhrzfP0Dq2_U*aeMM=M^_tp2-Xkr#@=%` zXs}wEnaAS?&-ljM>`&H1&bEa$0N zno?Oo@xhMeDbs>Hjg&FH3uJb5MSG5RkxkqA*@gM8cTbz_CB?A2cG`6EE!LTP&M8&> zG{(62k{@1}qaV3DfK#z{+T9{`vneMn+9I8lsb{pa{fh;w(wNQr)uG1RL$%F;W`6$1 zeP;Xi?skbYzCEd}k$ji!S=@g5^iB7Ra&2J9wo|Uv7WUs$lWgJcd9UPgy5>k$&12Wa8Fp+GEr8 z`7fDdI;|}xr^3Ih229ox^nZ;HK3m|UncH(8w4Wo0i>q0%sH-X7pOsPWlvz`;7bO+iYtG_(60!imZ$=|K}NdlZy*q{vopp@x$XyC`$4Kj>lVuE zl(%cSOw;V@UHoP77VOX4&Lc3)i?}T-`&bZo|E?0{uuYr_`*xs)ZKY_CLp?{pJoc)!dG^k)PITV!C0U`O$yd*OeJx>6DBL z@SW7gU~P8R>khDzWyXD-=N?gOmNsRt_D84GUhSd-H|j2xx9kJUNWK)ep9>nMclk9Z zTQ1L@rd+bVEO2hxb=AB(;oXOwV`mDp()0Y!T?%cTyk*Zj6W?I(tD|<2`HxIjTr@bT zefA&s(CZKOIPbd{VS8<6w@LJ*@e@l&my9ZrXZZNZD%g*z zdL!gYqc(y~Y(8y0h3&R$X=PuRhB_5=ICjcXT^khG$$0*JtXHVX6!R9-!p)VNWrQw; ztw(*p z)0PvO9`aTm8fQ)3srjW`2_(6wnhsf)&8mH7`@nvEqxhdqKV7e`)K^i?Ca%3&GS6Rg g+Te%=0NzaiWcjj?n(USEKNkQnz1fVTo~t+h7v8esP5=M^ literal 0 HcmV?d00001 diff --git a/Webseiten/Docker - Build, Ship, and Run Any App, Anywhere_files/control_0.png b/Webseiten/Docker - Build, Ship, and Run Any App, Anywhere_files/control_0.png new file mode 100644 index 0000000000000000000000000000000000000000..9519474ac24d11e9d21f0c3e8ef43ed9b29f164d GIT binary patch literal 484 zcmV!P+O_3gi;BS>GU{OXmuSE`ow45XRA3T3KEx8$08f)jVnBk7TW%=RMEN zDkTsI1e|bj_x7n%ATonkr9z~Eg{YWvSU~8ONY&nWf0#FN+k4~;L=N{YMHcX`g-@ix z+B>)Ix_0MV4rbq{BrWZNz1d6fK*5oK^N6`jr6A5a?C#-kgSdVTN~pc{V`|zGo_*~l z0(e38N(tdhI%e%En347?HEa<`n6pXCOLu`_QgcMMx_E-fjwM0`eVxQ(Oh%|+HB?%Y z;`aLL5Fvc;{?z7cN1w>Y&+j3|FgrD01ZxmwB054^l}HO2gX@TPGYacEvP2%R>{;rF z-%YZvBd(1`?S8v`-I!*dvimJhl_j?`w6g^HJszFxYxxgWI7QS#b14`|dswtrFOc&y_$R5D1X* aFTemB%ZeR9);6U80000 + + + + + + + + + + + + + diff --git a/Webseiten/Docker - Build, Ship, and Run Any App, Anywhere_files/docker.js b/Webseiten/Docker - Build, Ship, and Run Any App, Anywhere_files/docker.js new file mode 100644 index 0000000..c5ad6e7 --- /dev/null +++ b/Webseiten/Docker - Build, Ship, and Run Any App, Anywhere_files/docker.js @@ -0,0 +1,944 @@ +window.$body = $('body'); + +window.$window = $(window); + +window.WAITING = 0; + +window.READY = 1; + +window.BEGUN = 2; + +window.BREAK_SMALL = 640; + +window.BREAK_MEDIUM = 1024; + +window.THEME_URL = ''; + +window.BASE_URL = '/cache.php?request='; + +window.NO_CACHE_BASE_URL = ''; + +var init_root; + +init_root = function($scope, $rootScope) { + var _all_finished_triggered, _all_images_loaded, _all_requests_finished, all_finished, all_requests_finished, execute_lazy_load, outstanding_requests, scheduled_to_load, watch_all_finished, watch_request_finished, watch_requests_finished, watch_window_load, watch_window_resize, watch_window_scroll; + $rootScope.lazy_load_state = WAITING; + $rootScope.theme_url = THEME_URL; + scheduled_to_load = []; + outstanding_requests = 0; + watch_request_finished = {}; + watch_requests_finished = []; + watch_all_finished = []; + _all_requests_finished = true; + _all_images_loaded = true; + _all_finished_triggered = false; + watch_window_resize = []; + watch_window_load = []; + watch_window_scroll = []; + $rootScope.window_properties = {}; + $rootScope.schedule_lazy_load = function(callback) { + _all_images_loaded = false; + scheduled_to_load.push(callback); + if ($rootScope.lazy_load_state === READY) { + return execute_lazy_load(); + } + }; + execute_lazy_load = function() { + var callback; + callback = scheduled_to_load.shift(); + if (callback) { + $rootScope.lazy_load_state = BEGUN; + return callback(function() { + return execute_lazy_load(); + }); + } else { + $rootScope.lazy_load_state = READY; + _all_images_loaded = true; + return all_finished(); + } + }; + $rootScope.clear_lazy_load = function() { + scheduled_to_load = []; + return $rootScope.lazy_load_state = READY; + }; + $rootScope.on_window_load = function(callback) { + if ($rootScope.loaded) { + return callback(); + } else { + return watch_window_load.push(callback); + } + }; + $rootScope.on_window_scroll = function(callback, trigger_immediately) { + watch_window_scroll.push(callback); + if (trigger_immediately) { + return callback(); + } + }; + $rootScope.on_window_resize = function(callback, trigger_immediately) { + watch_window_resize.push(callback); + if (trigger_immediately) { + return callback(); + } + }; + $rootScope.on_request_finished = function(request_path, callback) { + return watch_request_finished[request_path] = callback; + }; + $rootScope.on_requests_finished = function(callback) { + _all_requests_finished = false; + return watch_requests_finished.push(callback); + }; + $rootScope.on_all_finished = function(callback) { + return watch_all_finished.push(callback); + }; + all_requests_finished = function() { + angular.forEach(watch_requests_finished, function(callback) { + return callback(); + }); + _all_requests_finished = true; + return all_finished(); + }; + all_finished = function() { + if (_all_finished_triggered) { + return; + } + if (_all_requests_finished && _all_images_loaded) { + _all_finished_triggered = true; + return angular.forEach(watch_all_finished, function(callback) { + return callback(); + }); + } + }; + $rootScope.on_window_resize(function() { + var mobile; + mobile = $rootScope.window_properties.width < BREAK_SMALL ? true : false; + if ($rootScope.mobile !== mobile) { + $rootScope.mobile_state_change = true; + } else { + $rootScope.mobile_state_change = false; + } + return $rootScope.mobile = mobile; + }); + $rootScope.on_all_finished(function() { + return $body.addClass('all_loaded'); + }); + $rootScope.on_window_load(function() { + $rootScope.loaded = true; + $rootScope.lazy_load_state = READY; + if (!$rootScope.$$phase) { + $rootScope.$digest(); + } + return execute_lazy_load(); + }); + $(window).scroll(function() { + return angular.forEach(watch_window_scroll, function(value) { + return value(); + }); + }); + $(window).load(function() { + return angular.forEach(watch_window_load, function(value) { + return value(); + }); + }); + $(window).resize(function() { + $rootScope.window_properties.height = $(this).height(); + $rootScope.window_properties.width = $(this).width(); + angular.forEach(watch_window_resize, function(value) { + return value(); + }); + if (!$rootScope.$$phase) { + return $rootScope.$apply(); + } + }).trigger('resize'); + $scope.$on('$locationChangeSuccess', function(event) { + return $rootScope.new_page(); + }); + $rootScope.new_page = function() { + _all_finished_triggered = false; + _all_images_loaded = true; + _all_requests_finished = true; + return $body.removeClass('all_loaded'); + }; + return $rootScope.request = function(base_url, path, menu_path, callback) { + outstanding_requests += 1; + if (!menu_path) { + menu_path = ''; + } + return $.get(base_url + path + menu_path, function(response) { + outstanding_requests -= 1; + callback(response); + if (watch_request_finished[path]) { + watch_request_finished[path](); + delete watch_request_finished[path]; + } + if (outstanding_requests === 0) { + return all_requests_finished(); + } + }); + }; +}; + +var SimpleHelpers, json_action; + +SimpleHelpers = angular.module('SimpleHelpers', []); + +SimpleHelpers.directive("lazyBackground", function($rootScope) { + return { + restrict: "A", + link: function(scope, element, attrs) { + return $rootScope.schedule_lazy_load(function(done) { + var image, loaded, timeout, url; + if ($rootScope.window_properties.width <= BREAK_SMALL) { + url = attrs.smallLazyBackground; + } else { + url = attrs.lazyBackground; + } + if (!url) { + return done(); + } + image = $(''); + timeout = null; + loaded = function() { + clearTimeout(timeout); + element.css('background-image', 'url("' + url + '")'); + setTimeout(function() { + element.addClass('loaded'); + return element.trigger('loaded'); + }, parseInt(attrs.lazyDelay) || 0); + image.unbind('load'); + image.remove(); + return done(); + }; + timeout = setTimeout(loaded, 1000); + image.load(loaded); + return image.attr('src', url); + }); + } + }; +}); + +SimpleHelpers.directive("lazyImage", function($rootScope) { + return { + restrict: "A", + link: function(scope, element, attrs) { + return $rootScope.schedule_lazy_load(function(done) { + var loaded, timeout, url; + url = attrs.lazyImage; + timeout = null; + loaded = function(e) { + clearTimeout(timeout); + element.attr('src', url); + element.addClass('loaded'); + element.unbind('load'); + element.trigger('loaded'); + return done(); + }; + element.load(loaded); + return element.attr('src', url); + }); + } + }; +}); + +SimpleHelpers.directive("matchWindowHeight", function($rootScope) { + return { + restrict: "A", + link: function(scope, element, attrs) { + var match_height, mobile_offset, normal_offset, offsets, only_once, ref; + only_once = (ref = attrs.matchOnlyOnce !== void 0) != null ? ref : { + "true": false + }; + if (attrs.matchWindowHeight.match(/^-?[0-9|-]+$/)) { + offsets = attrs.matchWindowHeight.split('|'); + normal_offset = parseInt(offsets[0]); + if (offsets[1]) { + mobile_offset = parseInt(offsets[1]); + } + } else { + normal_offset = -$(attrs.matchWindowHeight).height(); + } + match_height = function(window_properties) { + var offset; + if ($rootScope.mobile && mobile_offset) { + offset = mobile_offset; + } else { + offset = normal_offset; + } + return element.css('height', window_properties.height + offset); + }; + if (only_once) { + return match_height($rootScope.window_properties); + } else { + return $rootScope.$watch('window_properties', function(new_value, old_value) { + return match_height(new_value); + }, true); + } + } + }; +}); + +SimpleHelpers.directive("centerHorizontally", function($rootScope, $timeout) { + return { + restrict: "A", + link: function(scope, element, attrs) { + var set_margin; + set_margin = function() { + if (!$rootScope.window_properties.width) { + return; + } + if (element.width() > $rootScope.window_properties.width) { + return element.css('margin-left', -(element.width() - $rootScope.window_properties.width) / 2); + } else { + return element.css('margin-left', -element.width() / 2); + } + }; + $rootScope.on_window_resize(set_margin); + return $timeout(set_margin); + } + }; +}); + +SimpleHelpers.directive("centerVertically", function($rootScope, $timeout) { + return { + restrict: "A", + link: function(scope, element, attrs) { + var set_margin; + set_margin = function() { + return element.css('marginTop', -element.height() / 2); + }; + element.addClass('center-vertically'); + $rootScope.on_window_resize(set_margin); + return $timeout(set_margin); + } + }; +}); + +SimpleHelpers.directive("parallax", function($rootScope) { + return { + restrict: "A", + link: function(scope, element, attrs) { + var base, scroll_element, travel, wh; + if (!$rootScope.mobile) { + travel = parseInt(attrs.parallax); + base = parseInt(attrs.parallaxBase); + scroll_element = element; + if (attrs.parallaxContainer) { + scroll_element = $(attrs.parallaxContainer); + } + wh = $rootScope.window_properties.height; + return $rootScope.on_window_scroll(function() { + var current_travel, option, parallax_end, parallax_percent, parallax_start; + parallax_start = Math.max(scroll_element.offset().top - wh, 0); + parallax_end = parallax_start + wh + scroll_element.height(); + parallax_percent = Math.max($window.scrollTop() - parallax_start, 0) / parallax_end; + current_travel = base + (travel * parallax_percent - travel / 2); + option = current_travel + 'px'; + return element.css('top', option); + }); + } + } + }; +}); + +SimpleHelpers.directive("onLoaded", function($rootScope) { + return { + restrict: "A", + link: function(scope, element, attrs) { + return element.on('loaded', function() { + return json_action(eval('(' + attrs.onLoaded + ')'), element); + }); + } + }; +}); + +SimpleHelpers.directive("onOtherLoaded", function($rootScope) { + return { + restrict: "A", + link: function(scope, element, attrs) { + return $(attrs.onOtherLoadedSelector).on('loaded', function() { + return json_action(eval('(' + attrs.onOtherLoaded + ')'), element); + }); + } + }; +}); + +SimpleHelpers.directive("onWindowLoad", function($rootScope) { + return { + restrict: "A", + link: function(scope, element, attrs) { + return $rootScope.on_window_load(function() { + return json_action(eval('(' + attrs.onWindowLoad + ')'), element); + }); + } + }; +}); + +SimpleHelpers.directive("onRequestFinished", function($rootScope) { + return { + restrict: "A", + link: function(scope, element, attrs) { + return $rootScope.on_request_finished(attrs.onRequestFinished, function() { + return json_action(eval('(' + attrs.onRequestFinishedAction + ')'), element); + }); + } + }; +}); + +SimpleHelpers.directive("onRequestsFinished", function($rootScope) { + return { + restrict: "A", + link: function(scope, element, attrs) { + return $rootScope.on_requests_finished(function() { + return json_action(eval('(' + attrs.onRequestsFinished + ')'), element); + }); + } + }; +}); + +SimpleHelpers.directive("onAllFinished", function($rootScope) { + return { + restrict: "A", + link: function(scope, element, attrs) { + return $rootScope.on_all_finished(function() { + return json_action(eval('(' + attrs.onAllFinished + ')'), element); + }); + } + }; +}); + +SimpleHelpers.directive("onVisible", function($rootScope) { + return { + restrict: "A", + link: function(scope, element, attrs) { + return setTimeout(function() { + var becomes_visible, offset, on_scroll, wh; + if (attrs.onVisibleOffset) { + if (attrs.onVisibleOffset.indexOf('%') > -1) { + offset = $window.height() * (parseInt(attrs.onVisibleOffset) / 100); + } else { + offset = parseInt(attrs.onVisibleOffset); + } + } + offset = offset || 0; + wh = $rootScope.window_properties.height; + becomes_visible = element.offset().top - wh + offset; + on_scroll = function() { + if ($window.scrollTop() > becomes_visible) { + json_action(eval('(' + attrs.onVisible + ')'), element); + return $window.unbind('scroll', on_scroll); + } + }; + $window.scroll(on_scroll); + return $window.trigger('scroll'); + }, 100); + } + }; +}); + +SimpleHelpers.directive("loadBlock", function($rootScope, $location) { + return { + restrict: "AE", + link: function(scope, element, attrs) { + var menu_path; + menu_path = attrs.menuPath || ''; + if (!menu_path && attrs.includePath) { + menu_path = $location.path(); + } + return $rootScope.request(BASE_URL, '/load/blocks/' + attrs.loadBlock, menu_path, function(response) { + element.html(response); + return element.trigger('loaded'); + }); + } + }; +}); + +SimpleHelpers.directive("loadJson", function($rootScope) { + return { + restrict: "AE", + link: function(scope, element, attrs) { + return $rootScope.request(BASE_URL, attrs.loadJson, '', function(response) { + scope.data = JSON.parse(response); + scope.$apply(); + return element.trigger('loaded'); + }); + }, + template: function(tElement, tAttrs) { + return tElement.html(); + } + }; +}); + +SimpleHelpers.directive("loadBlockRegion", function($rootScope, $compile, $location) { + return { + restrict: "AE", + link: function(scope, element, attrs) { + var menu_path; + menu_path = attrs.menuPath || ''; + if (!menu_path && attrs.includePath) { + menu_path = $location.path(); + } + return $rootScope.request(BASE_URL, '/load/block_region/' + attrs.loadBlockRegion, menu_path, function(response) { + var template; + template = $(response); + element.append(template); + $compile(template)(scope); + element.trigger('loaded'); + if (attrs.jsScrollbar !== void 0) { + if (!$rootScope.mobile) { + return element.parent().nanoScroller({ + preventPageScrolling: true + }); + } + } + }); + } + }; +}); + +SimpleHelpers.directive("loadHtml", function($rootScope, $compile) { + return { + restrict: "AE", + link: function(scope, element, attrs) { + return $rootScope.request(BASE_URL, attrs.loadHtml, false, function(response) { + var template; + template = $(response); + element.append(template); + $compile(template)(scope); + return element.trigger('loaded'); + }); + } + }; +}); + +SimpleHelpers.directive("prependTo", function() { + return { + restrict: "A", + link: function(scope, element, attrs) { + return element.prependTo(attrs.prependTo); + } + }; +}); + +SimpleHelpers.filter('classify', function() { + return function(input) { + if (input) { + return input.toLowerCase().replace(/[^a-z]+/g, '_'); + } + return ''; + }; +}); + +SimpleHelpers.directive("portraitOrLandscape", function($rootScope) { + return { + restrict: "A", + link: function(scope, element, attrs) { + var detect, only_once, ref; + only_once = (ref = attrs.setOnlyOnce !== void 0) != null ? ref : { + "true": false + }; + detect = function() { + if ($window.height() > $window.width()) { + element.addClass('portrait'); + return element.removeClass('landscape'); + } else { + element.addClass('landscape'); + return element.removeClass('portrait'); + } + }; + if (only_once) { + detect($rootScope.window_properties); + } else { + $rootScope.on_window_resize = function() { + return detect(); + }; + } + return detect(); + } + }; +}); + +SimpleHelpers.directive("activeTrail", function($location) { + return { + restrict: "A", + link: function(scope, element, attrs) { + var links, set_active_trail; + links = element.find('a'); + set_active_trail = function() { + return angular.forEach(links, function(link) { + var uri; + link = $(link); + uri = URI(); + if (link.attr('href') === uri.path()) { + return link.addClass('active'); + } else { + return link.removeClass('active'); + } + }); + }; + set_active_trail(); + return scope.$on('$routeChangeSuccess', function(current) { + return set_active_trail(); + }); + } + }; +}); + +SimpleHelpers.directive("cycleChildren", function() { + return { + restrict: "A", + link: function(scope, element, attrs) { + var autoPlay, children, cycleNav, i, navButtons, showSlide, timeout; + autoPlay = parseInt(attrs.autoPlay); + children = element.find('> *'); + timeout = null; + i = 0; + if (children.length > 1) { + cycleNav = $('
      '); + angular.forEach(children, function() { + return cycleNav.append('
    • '); + }); + cycleNav.appendTo(element); + cycleNav.on('click', 'li', function() { + return showSlide($(this).index()); + }); + navButtons = cycleNav.find('li'); + } + showSlide = function(i) { + if (i > children.length - 1) { + i = 0; + } + clearTimeout(timeout); + if (navButtons) { + navButtons.removeClass('active').eq(i).addClass('active'); + } + children.removeClass('active').eq(i).addClass('active'); + if (autoPlay && children.length > 1) { + return timeout = setTimeout(function() { + return showSlide(i + 1); + }, autoPlay); + } + }; + return children.eq(0).on('loaded', function() { + showSlide(i); + return element.addClass('active'); + }); + } + }; +}); + +SimpleHelpers.directive("tabbedContent", function() { + return { + restrict: "A", + link: function(scope, element, attrs) { + var links, panels; + links = element.find('a'); + panels = $(attrs.tabbedContent + ' [panel]'); + links.click(function() { + links.removeClass('active'); + $(this).addClass('active'); + panels.removeClass('active').filter('[panel=' + $(this).attr('panel') + ']').addClass('active'); + $window.trigger('resize'); + return false; + }); + return links.eq(0).trigger('click'); + } + }; +}); + +SimpleHelpers.directive("osSpecificLink", function() { + return { + restrict: "A", + link: function(scope, element, attrs) { + return $window.load(function() { + var href, os, re; + os = platform.os.family.toLowerCase(); + re = new RegExp("windows|mac|linux", "g"); + href = element.attr('href'); + if (os.indexOf('windows') > -1) { + element.attr('href', href.replace(re, 'windows')); + } + if (os.indexOf('mac') > -1) { + return element.attr('href', href.replace(re, 'mac')); + } else if (os.indexOf('linux centos debian fedora gentoo gnewsense kubuntu mandriva mageia mandriva red hat slackware suse turbolinux ubuntu limo') > -1) { + return element.attr('href', href.replace(re, 'linux')); + } + }); + } + }; +}); + +json_action = function(actions, element) { + var delay, speed, transition; + transition = actions.animate; + delay = actions.delay || 0; + if (transition) { + speed = transition.speed || 700; + delete transition.speed; + setTimeout(function() { + return element.velocity(transition, speed); + }, delay); + } + if (actions["class"]) { + element.addClass(actions["class"]); + } + if (actions.play_video) { + return element.get(0).play(); + } +}; + +var Docker; + +window.Docker = Docker = angular.module('Docker', ['SimpleHelpers', 'ngSanitize', 'ngAnimate', 'ngTouch']); + +Docker.controller('DockerController', function($rootScope, $scope) { + var getCookie, userName; + init_root($scope, $rootScope); + $rootScope.on_window_resize(function() { + if ($('#content').height() + $('footer').height() + 20 < $window.height()) { + return $body.addClass('short'); + } else { + return $body.removeClass('short'); + } + }, true); + getCookie = function(cname) { + var c, ca, cookie, i, len, name; + name = cname + "="; + ca = document.cookie.split(';'); + for (i = 0, len = ca.length; i < len; i++) { + cookie = ca[i]; + c = cookie.trim(); + if (c.indexOf(name) === 0) { + return c.substring(name.length, c.length); + } + } + return ""; + }; + userName = getCookie('docker_sso_username'); + if (userName) { + $('a[href="/support"]').attr('href', 'http://support.docker.com'); + $('ul.nav-global a[href="https://hub.docker.com/account/signup/"]').text('Logout').attr('href', 'https://hub.docker.com/account/logout/?next=/'); + return $('ul.nav-global a.button').text('Go to Hub').attr('href', 'https://hub.docker.com/'); + } +}); + +Docker.controller('EventsController', function($scope, $rootScope, $timeout) { + $scope.events = $.parseJSON($('#event_data').html()); + $scope.searchType = 'upcoming'; + $scope.searchRegion = 'any'; + $scope.searchMeetupType = 'any'; + $timeout(function() { + $('.event.static').remove(); + return $('.search-results').addClass('loaded'); + }); + $scope.filterEvents = function() { + if (!$scope.searchString && !$scope.searchMeetupType && !$scope.searchRegion) { + $scope.filtered = $scope.events.slice(0, 50); + return; + } + $scope.filtered = []; + angular.forEach($scope.events, function(ev) { + var include; + include = true; + if (!ev.field_meetup_type) { + ev.field_meetup_type = ''; + } + if (!ev.upcoming) { + include = false; + } + if (!ev.field_region) { + return; + } + if ($scope.searchString) { + if (!ev.searchableText.includes($scope.searchString.toLowerCase())) { + include = false; + } + } + if ($scope.searchMeetupType !== 'any' && $scope.searchMeetupType.toLowerCase().trim() !== ev.field_meetup_type.toLowerCase().trim()) { + include = false; + } + if ($scope.searchRegion !== 'any' && $scope.searchRegion.toLowerCase() !== ev.field_region.toLowerCase()) { + include = false; + } + if (include) { + return $scope.filtered.push(ev); + } + }); + return $scope.filtered = $scope.filtered.slice(0, 100); + }; + return $scope.filterEvents(); +}); + +Docker.controller('CustomersController', function($scope, $rootScope, $timeout) { + $scope.customers = $('.customers .customer'); + $scope.details = $('.customers .customer-details'); + return $scope.showDetails = function(i) { + var details; + $scope.details.removeClass('open'); + $scope.customers.eq(i); + details = $scope.details.eq(i); + details.insertAfter($scope.customers.eq(i + 3 - i % 4)); + details.addClass('open'); + }; +}); + +Docker.controller('ContributeController', function($scope, $rootScope, $timeout) { + var connections, fuzzyMatch, i, loadIframe, repos; + repos = $('ul.repos li'); + connections = 0; + i = 0; + loadIframe = function() { + var iframe; + iframe = repos.eq(i).find('iframe'); + iframe.attr('src', iframe.attr('_src')); + connections += 1; + i += 1; + if (repos.length > i && connections <= 3) { + loadIframe(); + } + return iframe.load(function() { + connections -= 1; + if (repos.length > i && connections <= 3) { + return loadIframe(); + } + }); + }; + loadIframe(); + fuzzyMatch = function(str, pattern) { + pattern = pattern.split("").reduce(function(a, b) { + return a + ".* " + b; + }); + return (new RegExp(pattern)).test(str); + }; + return $scope.filterRepos = function() { + repos.each(function() { + if ($(this).attr('name').score($scope.searchString) > .2 || !$scope.searchString) { + return $(this).show(); + } else { + return $(this).hide(); + } + }); + }; +}); + +Docker.controller('SelectContentController', function($scope, $rootScope, $element, $timeout) { + $scope.$watch('selectData', function(newValue, oldValue) { + if (newValue) { + $scope.selectOptions = newValue.split(','); + $scope.displayedContent = $scope.selectOptions[0]; + return $scope.ChangeContent(); + } + }); + return $scope.ChangeContent = function() { + var i; + i = $('option[label="' + this.displayedContent + '"]').index(); + if ($('option[label="' + this.displayedContent + '"]').index() == -1) { i = 0; } + $element.find('.select-content').hide().eq(i).show(); + //console.log(i); + //console.log($('option[label="' + this.displayedContent + '"]').index()); + }; + +}); + +Docker.controller('TeamController', function($scope, $rootScope, $element, $timeout) { + var links, select; + links = $element.find('a[href^="#"]'); + select = null; + $('#grnhse_iframe').load(function() { + return select = $('#grnhse_iframe').contents().find('#departments-select'); + }); + return links.click(function() { + var evt, team, val; + $('html, body').animate({ + scrollTop: $("#grnhse_iframe").offset().top - 100 + }, 750); + if (select) { + team = $(this).attr('href').replace('#', ''); + val = select.find('option:contains("' + team + '")').attr('value'); + select.val(val); + if (document.createEvent != null) { + evt = document.createEvent("HTMLEvents"); + evt.initEvent("change", false, true); + select.get(0).dispatchEvent(evt); + } else { + select.get(0).fireEvent("onchange"); + } + } + return false; + }); +}); + +Docker.controller('ManagementController', function($scope, $rootScope, $element, $timeout) { + $(window).on('load resize', function() { + if (Modernizr.mq('only screen and (min-width: 58.8125em)')) { + return $scope.columns = 4; + } else if (Modernizr.mq('only screen and (min-width: 40.0625em)')) { + return $scope.columns = 3; + } else { + return $scope.columns = 2; + } + }); + return $('a.more').click(function() { + var columns, details, n, parent_li, parent_ul, row; + $('.current').remove(); + $('.selected').removeClass('selected'); + parent_ul = $(this).parents('ul'); + parent_li = $(this).parents('li'); + details = parent_li.find('.bio-details').clone(); + n = parent_li.index(); + columns = $scope.columns; + row = Math.floor(n / $scope.columns) + 1; + $(this).parents('li').addClass('selected'); + if ((parent_ul.find('li').eq(row * columns - 1)[0])) { + return details.insertAfter(parent_ul.find('li').eq(row * columns - 1)).addClass('current'); + } else { + return details.insertAfter(parent_ul.find('li:last-child')).addClass('current'); + } + }); +}); + +Docker.controller('PartnersController', function($scope, $rootScope, $element, $timeout) { + var content; + content = $('.page-content > .row').offset().top - 30; + return $(window).scroll(function() { + if (content < $(window).scrollTop() && Modernizr.mq('only screen and (min-width: 58.8125em)')) { + return $('.page-content .large-3 ul').addClass('fixed-bar'); + } else { + return $('.page-content .large-3 ul').removeClass('fixed-bar'); + } + }); +}); + +Docker.controller('NewsController', function($scope, $rootScope, $timeout) { + var newsPage; + $scope.moreNews = true; + newsPage = 1; + $scope.news = []; + return $scope.loadMore = function(type) { + return $.get('/api/news-and-press?type=' + type + '&page=' + newsPage, function(response) { + if (response) { + newsPage += 1; + response = $.parseJSON(response); + $scope.moreNews = response.more; + $scope.news = $scope.news.concat(response.news); + return $scope.$apply(); + } + }); + }; +}); + +Docker.controller('SocialCountController', function($scope, $rootScope, $timeout) { + return $(window).load(function() { + return $('.social a').click(function(e) { + window.social = $(this).attr('class'); + window.project = $(this).parents('.hack_idea').attr('id'); + return $.ajax({ + type: "POST", + url: '/count/' + window.project + '/' + window.social, + async: true, + cache: false, + success: function(response) { + return window.project = window.social = ''; + } + }); + }); + }); +}); diff --git a/Webseiten/Docker - Build, Ship, and Run Any App, Anywhere_files/docker_datacenter_banner_image_1.png b/Webseiten/Docker - Build, Ship, and Run Any App, Anywhere_files/docker_datacenter_banner_image_1.png new file mode 100644 index 0000000000000000000000000000000000000000..787948bbdab225dc5af2acddb0ab4d51cc2d11fd GIT binary patch literal 13618 zcmeHuc{tSV+xLi~JCW+PWSL5|N62m{#hsGWT}TWg+_IB>7E&QJbxX+Fsv=85wi($b zOcWYq88rqq_AwZSd9Q2g_x$-D&tK1bJjd~N9I5a3doAbnIX~xeo!2Gq>>2Zoe{A~$ zfk13L`PcDt2!!w$_^T?m4!m(YnztSNBX{kD?X~m1Zr4Jb16&bDulQnIx1aQOc6UAJ z>U<^4zuDCgfzawYdHm?#pm0S-qwq@^JGX1y|RONywE(teui4XuR1}w~jEToXj;G9k%97?29_~CO>VAD`Jfz!ijB-zwdj8J)?n4vghq? z72{wp-wr~E=p$#JLIIyaA)FI3AHOGKK8B0^14vmfZvcl~;LcOtc0h00Ro`Ae}Z zQG=tl+449w-po+~XSe{BCGgpk-v&GjI&TFYGz(S(3lCiExO zg{;;_eJH)`iBy{(ezcT$fyCT$Fw$n3k!~uv*4_BSc%oj(3)3P-YJ-;)~CMu3@v3!gO)BfufW<+ zF9fB@SEG|%uZG-^5pHjnQMp#CRqny+)c!T9fF1#UK&IfA) z_>3Qd5@--uECCn$(TpqGonn60aoFVn@gyp1 zl%cDah|U)V-<%|!9bezz+SXl5BbKBe(;%K~Sc>1wO16m;D5zGu9{VrJo2M;pi8?g- z=5v}Yz2{v>F-c1S%J)w+``wK&qsK8u`<+RlLp?#oN-jDxS1VIOB@Q*}gXKmRn}uam zDmmjHn!O`o<#*UVSf`NUB*VfeLgkYaK6tz#VPzNxzhT zv_F7sJC)Ub^Bbg|U#v5V#$ieYSW0FSeLUU=7UO+eyC%idXhHxAh2yDKor|;-^Hj7# z%a2bOhkRj31)uxo(=`?hd-R|;FF0tZ-JxbP%iQs^K!DnBjSk6QduM;dDg`Hn7m={> z?LUfb34Zw$&*2q^0)I)kf@QPI4t3Q^pX;-pWfiE&uxkEvzexSHIB$_YEju)dHi`;n z5UepZvz^-oqKu=cO_e0Wf@mE61K=c}I*?vHK`efHTi?=b&kzgq0x(yB6@*eX8+I%n zJf3g>)g0OX zTYr)D2~YG(tBQ$x6Y{~zOr_C=4!@@PcHz8F&ibSl+*~v=4h0QBJKLfRJU){HQ zjTu{?=(6G@s>81Hxkvp)LLR>L0BA{6#u_WD(I(0nP zHzb9NE;VNuU&XBj%AMc3<3ikQY#^)k+emg2WAiv>1#cV(olbUD#W!dlSfoNwT%tg~ z`D*6*Q}!9JHDp*ottOWfLU7!honF0|eB+ahucxi^qXAx%a#AjiXjI9Jya7+oz6L8V zkZU?b{cn$_zz;-|66u>*qKYibhRSSLuq?kZ|FgONfU@drGb@)G$2gAilK^*Mb%1&j z2SvWu^IL&=&aI68oo{@AhPJO<13oM*I+G2O=K*yjFgU~Sx5a(Mp(T#hi!R5`cwBX- zzE+E==cnB{RaUd7*ir7DeO&L{mMKvnwNp0odsQO6>2Wi~b#)Vp{f9|@iRy!L!#{t( zk15C=3ZPwG^$d7VSn17{z2|v^i~Ii48A8#=a}rq3hzu>IUUF*vg)pno9W;WIr9POu z=WEQg$2R)XtPevc_tkYugbiVQ4a+g2R)0v?s0J9=vuO8W_!!_A8G*Z-rOIj*DkhyQWG}Z?xFf+>{qw@?JS`H3 znZngACn?M?4W2J-SUO85jBs%ylI^-cj>X;>#=b;fT-fF8#k!?{F=j-^jET#DN;l+w zBJw&5c4u!MNwh)421P-X=U1Xa1Qt=pqb>#Ljx7|tyV3_7Sj^(8%BQ0_!jT*%EhXAk zW(*=kM`9S!c^qb~ET*Q7ay+L#l-Icl;kO-W%ZR>8eL(zisUCnM#?0m}p7XIDTz)l6 zT6jEKEa4R?cMY+mGy=k&%aW7+DO!rKF$p<;koGYLtk!84@>o^x?A2Y82DJO=U98rq zs>Y?Hw`9$D5s2+NUX-SG#Ik0hCyuL8TEf&UL<|W{W#*;$Zh=A#y+^7WKcC5Hfu>=& zTpQI?X(AdW5vgnZPYK{oQThT+=Vi^$nB&N3m0rJ-v>{ysQ81n4?e{^s-NyeL#P zvTNEtnb~M@p=eI!1s&yy^ar$R$6Uprp&=kf2)JwnL<0Q$@4STG`gcnx!>{iDV=rqn zSAZdy@Qno7;FlKu+eO~^=j3}rQ1)@v7Av-Y2JwmKD!&yQc#jx%hx1HI7=H57rn0c? zoybl!FHdTk&~%TV9!A2UF#}Y6NS+}fXC+Oh8rz!AFg89!={rOVe9@k;Pw*+&8vl2l z{u$Ro?Q7*|7bAKIwIHMzrSlbH7RjpTfh>qhESsY=tejzdAPioJHKd!7CkY^jxs~zmxSGeE(2AnB;(|_{A!OLZd-pg-4W`E{g z@)kc_bc(Mof|zzlrT8$BY-9Y^QF#vMUvKUr-H#Of@ z+Go;GcIZL(3s>8{#xN@vdM%MYx999gY2JICvihahugnBexo>j+H_O(jI@GxV1$(v>ajeIbD8+7f*ZZp}wZVowx^RdCRLQ1^vMe zOBzUbS7{|UvveHWSzo}bwbCjb%I~aZSvzUZx?irG8*TndmPY^NC4W^5rKZA6&?yN* zk$*Eh#1&Dv7TWH3D$o?P&~OD->t+_%1w^7s;tde$*PynbPEDpT1Fn6LD79@XR#yu* zdOyiWT3*DgIH0~?TU4%J0}WLBQ1F{Otwbh+m~88tK$RppzB!2G_cd1T5OV7F+ANBw zk}*hV2i}kxEX`uJXC`-6DqEnR2CJq`xxmqT^fZBoG-$49w@*Sn@fy*~0lOr1>U0VyMl1&U5XOj} zL9t$=<@Uuzx?bgPGZPd*5(n8n9^kajf#OPvLxq=XFf8H}+{C z9#NO?f7U2b~=^@*cshQimpC)Rx%Y93OG3Qx=0uyIkg-?N9ot zMeinzj(#h(UJG!EnLWCAVST})n6Mk?0f$RIcSmDts+z*99q%+QNxm9><1NVvjxKx| zs)Vw;1wGo5!ibbqaY5k2TjUvgD#o#=%ac(|x*X5(*hY~t3P}t~@viENIA6YlZWe7! z_hrQE0RTUhOOk`)Ui=VK@+nt+H$$D;MWZ)Z7Zk5PKK{U#-{jioGkR^qLhr$&x;oVW zgB(d`rQ)rc0uT@hrwGg9%n~ua-Bv$UFXV4Gdm1C0X66m6b@x zyq>C%YaVP``gvyB+-!6iIIJ=<1!Mop_V%}U1K5(aXG$Ai^|3Ts(gE9p(p(PRRE$y+ z3g1a9WWMp}*vAgq7GA{QFxOT`fUgIm7~Kpj-8^DS|2yyG zM0j7CdzOZQLJCD+hNT020HE5PI_v>?a!}Ppovbjhs{+y{*|sybOvx8|KNSPsBQ#V{ z?}#$)nhZGSPWv1{u|?N3Roe2c6Y8rBwTq7rHwY>YlY;col$hYdC=c{>>phkqVspeV zku!hJ`{YxYclgLKrKJ4jp2>J9$dfbekgX3~j4)aS#ia1wvcr_{<4c6u9+27#0dI5} zIU>b4+^J*9=vkZqX>YIss~C$RNwYfdNl-kzw%d?uVS0A94*LeIP3P1^lkek5$A<7# zZbar+IgXDT?)3Ls_+J3oQ+2t;5*R8RJE|M6|0RxlVkB4?Yg22B0ot-$29DOti`QPGlYeO%T2?A^u# zE?#9pZi@SrZ*z3~?{8E>-_K^ZjKL7H^yf(DY*dZXqG{q^6;w(Ehnb*DV_X%1jtrPl zB>s3(jW;MEDd4xU@(kV^+*AN+EQ(eq%4R>G@!|!$;q?0V(a4T2M#$Y5SY;|& zQ8zy5kGclaZLfW_To1!;K`qMb2o<`FTIALIy;B9~LsaL$V$>;mK{5V-pcWJ&$@aKv z<&rJVdt{c7&2#~Kr=F`XDDBcxiR!6=`eI36s z&x^NCbQ6o|m33Zu4g9ugWI+6a(R9o<W2C~PAC?<3POl^-ZK|MSus z6hWjlM@-S^!Kd?D^G%wP0#G-PfMlzc*r}_H2e3irfMkZ%)%E}>$$QlFa5f$Q0~7o) zyHu<55sKf!ha`hQwFpbS`Rnzm`;?c!kDzWP(jRvD@U$1G!cZBc8(|HLT8S=#uX59p~om*_RZuP7Tj16Hl zA=niC*pPNV1bX6c+5pWkMw%!L&bamLSI5H|xU#?WE?B@`>hAr{s4K09`@CNR!jdYmP*0^(64&en$-R7C=_79Oh!_o@NJ(9clcWxUUEh|3!_(;(^sb{sXqQ!yN(rm>Ydnl)ns)gEW(2Ai!^(!*NkCf+=(QvkBH)m2+ecyX@*lYq`~ zK}gp3X-HL3`$fDAjfpJGxUg0rpAymxQ^pG&k}N$rA^w3{B2l~X^PntDLzl&1-4|%_ z=K;MVQUYZiXmP^eqgrASBjDHvIg}U+O^oV935xW zUTc&haEj{2|7i*e!(Edf1ei1*@el%LVj>B$y1MFZi>8?>0B8879oiGQg%YpDOQct_ zQZ@t%n3WEEC9!w*9iID12XD|y>2LBC%wy&3m>XP%)rTfCzr@sR*AL;zy*#(v_=Sya zFpC?Iv5gPF&Q`7g?3}(k7CRKH*b7MuXxLQJrie%FYyh5|*u0Vd^{GN9Z;GGx6(`=7 zs055Ns_(ctm3Jal62~al4Z>x4@tOwks7kxpB_(6zObN%GM2uZBuAYP_@D5M`RY13v9x|A!gF8oQB~xT9N3%#WxOf1)~SQ77%-#qV$NBx z@Zak57*BN1%;p)M?pR2#o;Y@VsS3-Rl#6^%rX0V|Pn!&uJ|luFKQPiDrvqmEhW{(H zqF$^w1yoToviS$PR6Ybzcvd)&tHl?Z|Ckg_Ad^&m{NcSJQT@d|0T+;_bj3T)L-e;-o%x z(%hc6B99*9u84whizG!U!tw09&7inQFP_~t)fYZ1dZJQtKwXw18cqkxDjRN(GQ1Nz z(|U!Wb9AunuOMqj$z3gL^~F1r4w8}jA3>$X&t!+DWenLq;LLmAeX&9U09Vo`ns3pwglicwbFi z6vokahgw*36X*U(mg-Fvn`!OJssyJ&a2zM24=yWVn$FkuPC2&|yeauB+s z+EQy$_|HntaQc>#;p~5Zzub6~RGC#R&6E!;l?LMoB0BPM^`-a#ZI?8nYALIE6x1Gp zf4wZjOiJEU-rP5Gz~Vmol9eDA@VPxJCcvUEcDD73ksytEx8p+^=?6K z(QO835Hvi{#_}>NZ%*e73j}Qfg6<)D3fi`A{?Gi`W?>=~K+Z3(cl#dyHRj%yDu?dZ zyXpBpMqw^VIuKYthr1!^)pk}SJD?9Mpbx=_xAqiTBmm^>S`W2&&kAxSASCE@utjGd z?QTfQv63u7YIa$kIq;Gt#f0#?skEg0T4laySa}xj^4nj7_HShdEd}p=+Y;+_`o^N`o8NCY4Hx6FM_PdV8HKq8 zyIIWwN?SeVg{rjlCgdgWfy)Gn1C+?y%aF->)77bBaRkh1_N{ zHjnlXXdo@Gb|Ln(zV~}fl*j+lCur64mVzXmPHN3v zIURxnk_lwLSfeFE|DhcQ!GtDlW*6ZzUp+8<5YrzX07Wj6;lv^%%CoAa1hLhL-c)w@ zGI%WhCAm`wAfkYTJ-jJdFv9efUkX!SqKo!j3EK(`#Aoqtm%|?)MO6{UGK`K4&@xBq zI*B_#HdJ(S=G*tVNdBb5eKn(GM1EY!i$R|m64)LU>CH^=8Iows#(^DP(jk!2t3uNy zbblLeNdEzEcj=WnF;K+nxwUxrbGO}`Pg3~;;JlxtJ6HEi`pV8q|8RpMNl+hD$8t@Z z(z^;1eI9Ui+bL7rsd;0ruGA=^pB-|UcP6aneN}?m9lrXTT2$)Mm>Jz>3gs>N`~YLa zb%7P66X$w?6yK4^N+qN3yq78$Ye}#jHZ;xzU&AmCb|lHh+RdgOG?p1fcweaBMEC*F%r^^ez~I2o1h2!)Zjzy zh9wV@bA#O%Y!=?dFRFJ!jO7taOUs8yCS~jQf<}Xcf8ykBb?bF8HhXnq4Xq{))LVWR zZp*y_Ef09ri^q&G%a(fQB<7bM61<&(-9wLG{vKpv2tq;sKsWeMi=7{}E(^{`v=tcUDos_Vc3F0O?AAg#a;Gq+^&47`KvE$V zHq3Hl3n#;Dq*xU0svCE{R4xdTx%T5>lwJHxv-E1JN5AiC$(ewsY6<$#r^-eo*mxdx zoSG&Qji($|4R|0A0Rkfu_BIhO?&R69nnF}a+e1@`xmi2lNa|hN3s2qPKOjvM44Mb6 zR-G|6j?iM~L(w8li8IZY609V~cVvv1=G5!b$*<;CWMVh8Is(~hci>VT20px2s;z&8 zX`(Z`owiOn7r%9TNF3FvAutKM*BBjYT||-9sEONvTw|@Gy*>k>ItF;HPciaD%bfZm zdgtJ9dP;dHlC=~6ke}{KGMZVd1e*46V!HKl1{ZMlDY~q@-Ht-)Jqu-Glf(tARo-{< z#|8f^<(1OUBA__dw^*wWUjlw&*sgoRL-C-f6w<- zy@go!V_+SD!~lW50~Y==uUDU;(-JA7oh>hT9UYr$hXyy~da&I^Yd$XY_56SbHkTKK zuDy|FxLseX|4DzK4i_x{AyeKFfR&8&;zr$7P`Y)Y>S`$A2wb@@eQ}2hF z7aZ8dAcuqErs)>zr-rPevZAsjAnX)fD4uUB^3@3S(}L@lnTI-`rPK4ZYI`PTeKk?o${}+yS@H zwW}^z08Xj3-2J>{Szn90efI=Ji?}nh4@dUtS82PIdy?LMM{VPJ$jf;k-%^>6A*Nbm zU-TQ>cz;g{JQDg8Et{R+2oS4(bKvl*4Qd;!2@d{=C|gLwRBMB#l|ESO>;0Af0w=52 zM6`&s*FjyjT*3!qJ^m8-S^jo3ai-;kcnjuW(`$Jcn@l8sgBjymv5nEJ(gxdoivO=M zNl-k&yJ%VCOL2Z+$uCdR-6#&<#UX4)>t`#EFZ!yq?0=%Mr*-qNLxRpN5%^){_N)vy zbz9=mic4`bs&+as1Be>D6_)X8RU1h$bJ?`B?w0_yQH^04O{<6WZmyg?*s+lN%Kled z;RJT zI;J7B(j7gqsyJf)J%drf`Z-hsCYLf16dCFKKc0_l|hEE!7*7(bRo z%2q^&gNutGH6Kgv{Ygg>7H74+@v6Arn1BKBQa^X=b-1`M7Y}W1d(uA#CJ85T?=1=81b8jA)KJAw!%-48r%k+J7P}K6r7v_{(~RD5&U0{ zU!ArTlwtXTpo~E9zM}0({AVyi!v}2qLJc_mya(+YJX=VNowzagU~;tsMqqIMJLR=u zLC&+!{gyPG!|zmfw$bg*ejQLdKS`qRhx;sW>g;kh_haTy{KdxrRB%e{aKCpl_s6%C z6A_tHtVAhzM1U~d-oci-x2iv|vNR?&56-g*KD&V5Kp@iBb7IFSFO4Q}pwvt}|J_}M z%J?TismPbFC4xYRALyuZ=y4z5&o9=eoFwVBP&zmt1^t%e=WkjAlR+4M0-F0dOB@jI zAzYU5E-GT0ZOKuF;&;P!REKDCb;LmXC%H%vHu z4EH_78=x~8FWqIJ3g&iHR}DFCobaJV1gTj#h>{h z<*O0njwAjLE9MWwFYl~EL*6S^iXmI`7oInU)=(*)zpf)(WK^a1IwnrD0;NzTD^~Z1`Ws51| zNw}}^nTbKg?iwPY#hlIUebV#~sB1atAU{>6O?>$@x%0IJ-K|bYwrLq(U6}nmm>!q? zl0k3fuWHa8E4L~GIVbr-UPs~>Dj*vSK1a7dV1@h_gHi0I{kKgqez?JJj4xSPg+ zB?T|NS9Mdm(>V}aebZD^Cqg3nZx9NJ8`X+DVQTqRmyqO($_*YlnxT26_;7!mbL7$R zH%xkR>5g^5&EonAYE<&%*>uwD9WgsRXJ;s*?!*G|wc_VWnakO`aw~xGY#N>3E;S6U zqtIpl7!t~GUI&sd&jvjgF}AHIeq>t{H0SV_`Fb*=;+E%q7)v7?`k2LGgnL5+tA(4dV9do7zLegI`8T^0kz%EWiKcUSKN!WJlH5ZJ7 z44mGJ38pYfAJ6U88cC+8?Jg6-D~)Roc?@}*#Z!D?dIxQ ztn_`Uv0D%HD@bd5T7uqYqgJO?f`bU9(Z&I3)Np~r^bzND>vb@e#)?&INTUN<`=wU1 z-h_Ox`pdKQ!ud1hGB}?uSTu$voX6{Gdk>FL}7oI&5cL%$r1;?w&&{sAMj}dH~O>#s)4s3nJo1U(HJw!AAaILfXSggZ=anie}XlrQ0-Et z%5dqP3DSVvsN-SSf5MW9U`wU3Q{i1Wv$W>)gjWx>sCLZM=veh$QIjdVXbDCFo3Ysc zFY&y88{z^tG#x$4Z=-kp{arER0Wi6Y7Yy97Rc?qFLU zmYsXg>FK@6_`OiUHO@79F4}wD?+VyOXt^`-{YJ6D5fRvTexhfS$*cSm@ZMRGua&qE zRs}Es?5{7liq*CYoPCZOUh`Mmm)auJ$@}G?7(IDSn`&)r!2K;?YefWt+!{F3@>_M0 z=`S6d1TA)#-1>C&SCtL-aJQ$g^9)poAT2J^(X%M9cv_$8AS>vHo7PV|;a-iI$GXWv zlNonNJ7IiybHd$j6!Zv#CzdY1P_NS^JVY-ST!E{|3Au-gcRG1Ur*ZmVgP?*&G7nGk z#kW(^&bsF~of|uZ2$}bQskF)K!QOZ@jv-eA&0La;zs~(hf6RMLdd=x0h=1D zjly1czAF#L_0 k|NrNIEdt_Qd>JRiL5 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Docker Cloud +Docker Hub + diff --git a/Webseiten/Docker - Build, Ship, and Run Any App, Anywhere_files/fa-reddit-alien.png b/Webseiten/Docker - Build, Ship, and Run Any App, Anywhere_files/fa-reddit-alien.png new file mode 100644 index 0000000000000000000000000000000000000000..46a71b6018bce819305ec7f787e5934a022011a6 GIT binary patch literal 5943 zcma)Ah^vOE(fqgOnfwvNVdMbW4YX)FS!% z{0HxcnR~y^opa{gJF(AnR0(itaRC4zP*+pZ|A&bG3LEoZ@0GP4{s%Z7YNp-*fJgRU zfq>k6Y5>61b%Md3J%hXZxO>ChJ($#CFeVQ#cL%3e_5cvDP+;I_Xs|~qgI+mT)I=iE zHQn_ou$lA~;}PU3?A**a#2QHE;&}?aZW3i>47#BrBqS*bkwBrxgCB=GhqcLEk`!5r zjQf7`E4b8UrUSh_a{p;ocBkg7plJ*Xg^i!7Cafolz^_zfBw33b>>K#C$tNF<%jy9T zV>j6`d*88ufU7WR=_gPW)>i-&@DmRkKxyZp1n6TPi1rn8EI^1iAe2vvgeEqE9FPx6 zQY-`HRX~V>Y<2^n2m`Phwzb&+p78=!9Iv;30*HdEoL~@Op3Y1GDoO#E$n23y0Q@OX zGxj`A888t5$Q?BMB!M|zKtSEtK@F&H1yG~Jc#QxyJ|LinjN$??f&r@`7M1|uO%6b= za%wF7=Sdy$4);H$avG)ESS6Li&9Qksv5bxR7&%APsh*IFS%a-}<@tI7b7+LZMTpkU zegHsG3dO%^&+Y<73F}5j#gbYGU-IsEVLm`@Y&Pz<#;QH!0pOQU*u*^#e-ka@DJH`8 zzJ%=v18#{|+i;)_l`X;QO0+# z{)S24qA%9IuCs;K|jm^?_vg&Os-oq`!PiUXIO`8cf`Gy{; zXOdEG!kN$qXslu?S3le2gWdWn&kaO&RTQXqmIVc;@K(IAg;ql^j=n6H4%!O(IfQ?+*bTk@(dy4{y|ynZo}BYpW2aeWOx>H*V)6n43&llsE3xOe>Qh zR=hJ_4JTSimW2%ppmwRTg!^6z@D21THc0T`q}dKPKx^=;2Wab`*Ff51FKove{4q$w zl~Fii82*Y(){F{jCR!#sb7~b#^sFKz3pnC9kT-fg9MH51&1Uv5B!By;ZG;44Ow@Q- zW=NCC_=$s&us(5C(pZ=fN84Mldc%9eNzzG`NjH6#J)X)u5j9$tv~LS`E{#}{={!tN zhN3nLHhVXPH|aK+Pt9=)Y~(%PUm2`(>VJ3EpxGkc64}DE&lXZJD$Uhjt|&Gn5luEz ztSxTQ|EL#JK_=pxD>)KLsjm5xEu0FDcKW#M^MzzNgHb1I+<0<$PjxqI7jo{8 zPY_KJIf!)Rq{*YkqIRV5r~a6&RYvnOo@UTcKwR)3dnbn|$KA+;yM;T1BIP@7hDHW^ z1|2uQVP#cW)k+nf(V5Y(VREIVL1>+dk+8u=CC*f4wNX{UvjYP<1INmz6){zg74C*| z@54;*Vlhp7wR&}7@AZlrUT$;@FyYzKGzIW5yAV`I`-Y45u{Vs&hxl=~XWucj$IDbz z7E8i}HH3|u^v}{AqV^%L~dnmD^2k!U+`yH8?CdR2`E?9~JBv%o{A1mkJ;2&K4 zqX&D@D-Zi%onf8z>rG1Agmme&N}>u;g42M-2J43Ffa^dhJ0?3byQcQO_EE0Bc3T-& z*;B2jT7x4$MoLCzazyiF1ZRbI@^98!cqR zTzyUj26;bK9jP4Kyd%$$@v)i_!+cq?e0g*O%R`-;8a@}EFMb70UKHdt<@Fp^EPgx^ zJ90XTS$g+Fj(cT zwDmES?4_*NyA9b5Y4H`I71NhL#8It7t;4##?u9R-R$;GM9_${19wvZt1RKZ^5*w}% zZVtY=3JPKFN|KXWw7+beKU7F4YEz(4NRFtD*y^rjh7bLITg!~z$sSD^bs~&<7PdPx zj%B@V9p4*<&k+?9WgIP+ z5dR|bMQ(u4!Su(pNr8#_D@}SyKJGd(w^v_RZx7F6)(h70HiD_L`G;P31Qw6>oJW;Y zR`QYZNM*`vA$26uPZWr`D<~7#PRab)l5hii71v}8n<>(>hF{e z(LmOI;SW4pZErX#-*#vbXf5YS6;kHBJKvoqbJeNF>9nh$F*>~PU}`58fVpo zb+QL(yM$YIe~;+?1adjRGs4}93O!hwJ$#{S!f(3z$@)6FfKHYoHm;6*kt&Pg^&IC? zz!qJM`}eM#rS#^?>b^F+F^5Tqz3mm=LUY2*s;uoSLN|i>g=T`)=go%~m&%L$StFc_ z?U608w$d)?&mH#V-$qBC${D^lJU6^H6g!$+{$xFSwcwW!T=NU-=VLzxM+Sap#oW_el{|yo z8*>};FSWvCpqb<%js4ryWm6ElxlCoHj0Qkr{tB&iyF$(skcwU-~}nr|w{TetT|R zn}ti;QBdcnUu zL$~AQx%{ERJZw2;TF(4_Y3_LGwKK}U=xkz16^$7cId-3NkxT@8l$?`198C~?P$(fQ zDY-7^b+>n04jZ!@V=tt-FS#GCqoU*wyP7_j9i7OYD9$>~O6zhB`Ea+7I-vQuIM6e| z`1MQ(yM0006#?x{`unz{2l>*KdvN zX$Iv`eD$B9e0@Z(nUNYeD!90`lCVlG8@RKBK@!E5$z(;2gOh3Tv_z(piou9TW^U|r zVIAj0o3dhSC^SOunfx33c@NLf?X=%t&lj>ku#Uxgh_jyiWbb~=vH z(#L1AT`OVGh*GbK)piulng>`SA0XsF^!~pzl3N@mP6?Lt4RIk6NTa>$ZRgjmMzuyV@38 ziWBa7oQl?NCyl^6GQ?uIfk7cUc+DKOsDt=Sjk!dSKi%(chM4^wzz{$dF#Nth$jZO) zYyeCIN{jDkRYpk{&EpUgZG>;3!nwv=FlG*6(TOO!%Lh@hK{@P@#=aYKU}+5lSx)>8 zPnvi)C{g7N0ZMGm8&qdX^h4~96}u{A=^lac@oLoORo#@_(O$EE2kx;>ADLIzSeOK6-NB3y z_RYWdHf!`vkSUa0y!*r z)dj@vzuO%pMaqiUwi6A7KswCxe}7s*$mx!O zu@aqkW_0m{=KF`=tH`)>0LK!y>Cria*-2x>+gDsaFfwW&KkQzc2Ul~wX2_Vt$zTFq z&wF30E`Pn#8yq7EoLSI(7H@GQtGaraFH1=#F}MAb_Nht<`ikIs>hS1Y|u4SkQzOtWUZC@fEQ0Y;| zkp$tQm@C?SzyiyeUTML*mbBXO4_GJQU|4Sf5H8raa^!^CLpfcVwpqt=rHtjKSNMa| zqyJQ7y(+s4R^tzBSU?QwMNX!ny7GZNtb4E(pFnBWfvI~*_q%wcyEP9UI6)P{qmnn! z$)H^k0upugi;@zNJfpXAer)bptK1ogwHT_zo&@w4K2Tnw4|O4Y$`C~&m`sK!-0+mpJh$%A zy%y(j5i&g}fjlKx`Mm-ztQ0BD3LRYdYoNTTM>5Zx5$Q)_$_?EyeLNL6!~kvliaKkJ zAKHKl)lU6+Vg%MwY%(t+_dLQi*L>$jT1q-$r#VC`@>rnODNOieTAEb!np}WHJ4333 z95gl9A4)lg6GC~VnTbIiq4H()}kT^wm8ONy~q8#2v>d}tmnR; z(M(U%qVrQH<>$H>?2~l$ik_6o;3-`t_V}R|#*?B>D0D-A>EIQK6T#G_D^#cg<%bnN z#2+*?98jF7*KM2oyqL`P?|MQ`C)r4;dER%GZeNefQn9DO9yjafo| zT44Bo#1`{UW7Z4_=R7MpXdg+(B!r(Bp#C)A4ALAbW(G(RltG%H=)qktsJy7B_XQ^S zr6LOwuYU_3pPEW(I*Wf^afJ_6a7-vq&vwI{q!O0PLuF z)C+i-jxjaXEjyc@re2b!N(C-+o78oKAms>B5;7tX6!h+xus-RbBlK|)dQ1{N65c-k zBVSyKD}<^jM|;qIoQStLGrL&7S7i>Buj)5vr#X&(_07l@EeQ2$Z-4gDd{opjs;oPa z`98Brk_YAudY%=J0WUtV84~osmPzBYgxzLG9@P_wCTArQjw`O!7^!9j#LEZc#55b$ zeu(&9eZho5pqAprf>Md|&zHbeg@6*>m~l=p!~L5)SZyfG{K|e~*JEk>t{mEu6CA?l zW=FkPfii5qOV7BfTVCA2?s1H{grm^KRO|9{yNoB_t`7OxrML{hR^oqsq8Yq7_Rr_j zt@CQ(*fYK~sYRef4MMG7lP(x+3_EdZ2AF#FU8E_+GuuwkMu|wVm!v82mw_|YN_M)K zhbz>!H8vzx&oGN8@W>QD4K5&R;>RtUkV~x4G}1!!hE67XGC`7c6!{GWV=ZV4eJ}Z6AYi- z1eCdOKKbFpdWQ!VR(lgUwRah1FW^Hrl;$owcn5WuUz1e0665ClX8}3;cx+^bAhV8)l*E>asD&Z)+ z_P$=5NK^a$v4DYZFqL150^CQB@Ax4^1fMrP*bNkhe~V0LtP3i!xXl?ju@!RjXQS1) ziyOHxcTGALsPw7lswUG4EYN7lb9M!XVc$v*>+DtDfeDqx4GQD4@Z|J!ADqbivAp>sn~COxlkEmW6x7X0w!;%V>deaywuQCW#i89SF$?ycSf@8dj z{i~;))wybu4UwvNYW|~;>{m5D>T@G2wYHC82A^_=FIk0iypu fsOrn^2TVYT*D^xnPPJT1EU1bEFIO literal 0 HcmV?d00001 diff --git a/Webseiten/Docker - Build, Ship, and Run Any App, Anywhere_files/flexslider.css b/Webseiten/Docker - Build, Ship, and Run Any App, Anywhere_files/flexslider.css new file mode 100644 index 0000000..fa25f9d --- /dev/null +++ b/Webseiten/Docker - Build, Ship, and Run Any App, Anywhere_files/flexslider.css @@ -0,0 +1,96 @@ +/* + * jQuery FlexSlider v2.2.0 + * http://www.woothemes.com/flexslider/ + * + * Copyright 2012 WooThemes + * Free to use under the GPLv2 license. + * http://www.gnu.org/licenses/gpl-2.0.html + * + * Contributing author: Tyler Smith (@mbmufffin) + */ + + +/* Browser Resets +*********************************/ +.flex-container a:active, +.flexslider a:active, +.flex-container a:focus, +.flexslider a:focus {outline: none;} +.slides, +.flex-control-nav, +.flex-direction-nav {margin: 0; padding: 0; list-style: none;} + +/* Icon Fonts +*********************************/ +/* Font-face Icons */ +@font-face { + font-family: 'flexslider-icon'; + src:url('fonts/flexslider-icon.eot'); + src:url('fonts/flexslider-icon.eot?#iefix') format('embedded-opentype'), + url('fonts/flexslider-icon.woff') format('woff'), + url('fonts/flexslider-icon.ttf') format('truetype'), + url('fonts/flexslider-icon.svg#flexslider-icon') format('svg'); + font-weight: normal; + font-style: normal; +} + +/* FlexSlider Necessary Styles +*********************************/ +.flexslider {margin: 0; padding: 0;} +.flexslider .slides > li {display: none; -webkit-backface-visibility: hidden;} /* Hide the slides before the JS is loaded. Avoids image jumping */ +.flexslider .slides img {width: 100%; display: block;} +.flex-pauseplay span {text-transform: capitalize;} + +/* Clearfix for the .slides element */ +.slides:after {content: "\0020"; display: block; clear: both; visibility: hidden; line-height: 0; height: 0;} +html[xmlns] .slides {display: block;} +* html .slides {height: 1%;} + +/* No JavaScript Fallback */ +/* If you are not using another script, such as Modernizr, make sure you + * include js that eliminates this class on page load */ +.no-js .slides > li:first-child {display: block;} + +/* FlexSlider Default Theme +*********************************/ +.flexslider { margin: 0 0 60px; background: #fff; border: 4px solid #fff; position: relative; -webkit-border-radius: 4px; -moz-border-radius: 4px; -o-border-radius: 4px; border-radius: 4px; -webkit-box-shadow: 0 1px 4px rgba(0,0,0,.2); -moz-box-shadow: 0 1px 4px rgba(0,0,0,.2); -o-box-shadow: 0 1px 4px rgba(0,0,0,.2); box-shadow: 0 1px 4px rgba(0,0,0,.2); zoom: 1; } +.flex-viewport { max-height: 2000px; -webkit-transition: all 1s ease; -moz-transition: all 1s ease; -o-transition: all 1s ease; transition: all 1s ease; } +.loading .flex-viewport { max-height: 300px; } +.flexslider .slides { zoom: 1; } +.carousel li { margin-right: 5px; } + +/* Direction Nav */ +.flex-direction-nav {*height: 0;} +.flex-direction-nav a { text-decoration:none; display: block; width: 40px; height: 40px; margin: -20px 0 0; position: absolute; top: 50%; z-index: 10; overflow: hidden; opacity: 0; cursor: pointer; color: rgba(0,0,0,0.8); text-shadow: 1px 1px 0 rgba(255,255,255,0.3); -webkit-transition: all .3s ease; -moz-transition: all .3s ease; transition: all .3s ease; } +.flex-direction-nav .flex-prev { left: -50px; } +.flex-direction-nav .flex-next { right: -50px; text-align: right; } +.flexslider:hover .flex-prev { opacity: 0.7; left: 10px; } +.flexslider:hover .flex-next { opacity: 0.7; right: 10px; } +.flexslider:hover .flex-next:hover, .flexslider:hover .flex-prev:hover { opacity: 1; } +.flex-direction-nav .flex-disabled { opacity: 0!important; filter:alpha(opacity=0); cursor: default; } +.flex-direction-nav a:before { font-family: "flexslider-icon"; font-size: 40px; display: inline-block; content: '\f001'; } +.flex-direction-nav a.flex-next:before { content: '\f002'; } + +/* Pause/Play */ +.flex-pauseplay a { display: block; width: 20px; height: 20px; position: absolute; bottom: 5px; left: 10px; opacity: 0.8; z-index: 10; overflow: hidden; cursor: pointer; color: #000; } +.flex-pauseplay a:before { font-family: "flexslider-icon"; font-size: 20px; display: inline-block; content: '\f004'; } +.flex-pauseplay a:hover { opacity: 1; } +.flex-pauseplay a.flex-play:before { content: '\f003'; } + +/* Control Nav */ +.flex-control-nav {width: 100%; position: absolute; bottom: -40px; text-align: center;} +.flex-control-nav li {margin: 0 6px; display: inline-block; zoom: 1; *display: inline;} +.flex-control-paging li a {width: 11px; height: 11px; display: block; background: #666; background: rgba(0,0,0,0.5); cursor: pointer; text-indent: -9999px; -webkit-border-radius: 20px; -moz-border-radius: 20px; -o-border-radius: 20px; border-radius: 20px; -webkit-box-shadow: inset 0 0 3px rgba(0,0,0,0.3); -moz-box-shadow: inset 0 0 3px rgba(0,0,0,0.3); -o-box-shadow: inset 0 0 3px rgba(0,0,0,0.3); box-shadow: inset 0 0 3px rgba(0,0,0,0.3); } +.flex-control-paging li a:hover { background: #333; background: rgba(0,0,0,0.7); } +.flex-control-paging li a.flex-active { background: #000; background: rgba(0,0,0,0.9); cursor: default; } + +.flex-control-thumbs {margin: 5px 0 0; position: static; overflow: hidden;} +.flex-control-thumbs li {width: 25%; float: left; margin: 0;} +.flex-control-thumbs img {width: 100%; display: block; opacity: .7; cursor: pointer;} +.flex-control-thumbs img:hover {opacity: 1;} +.flex-control-thumbs .flex-active {opacity: 1; cursor: default;} + +@media screen and (max-width: 860px) { + .flex-direction-nav .flex-prev { opacity: 1; left: 10px;} + .flex-direction-nav .flex-next { opacity: 1; right: 10px;} +} diff --git a/Webseiten/Docker - Build, Ship, and Run Any App, Anywhere_files/font-awesome.min.css b/Webseiten/Docker - Build, Ship, and Run Any App, Anywhere_files/font-awesome.min.css new file mode 100644 index 0000000..ee4e978 --- /dev/null +++ b/Webseiten/Docker - Build, Ship, and Run Any App, Anywhere_files/font-awesome.min.css @@ -0,0 +1,4 @@ +/*! + * Font Awesome 4.4.0 by @davegandy - http://fontawesome.io - @fontawesome + * License - http://fontawesome.io/license (Font: SIL OFL 1.1, CSS: MIT License) + */@font-face{font-family:'FontAwesome';src:url('../fonts/fontawesome-webfont.eot?v=4.4.0');src:url('../fonts/fontawesome-webfont.eot?#iefix&v=4.4.0') format('embedded-opentype'),url('../fonts/fontawesome-webfont.woff2?v=4.4.0') format('woff2'),url('../fonts/fontawesome-webfont.woff?v=4.4.0') format('woff'),url('../fonts/fontawesome-webfont.ttf?v=4.4.0') format('truetype'),url('../fonts/fontawesome-webfont.svg?v=4.4.0#fontawesomeregular') format('svg');font-weight:normal;font-style:normal}.fa{display:inline-block;font:normal normal normal 14px/1 FontAwesome;font-size:inherit;text-rendering:auto;-webkit-font-smoothing:antialiased;-moz-osx-font-smoothing:grayscale}.fa-lg{font-size:1.33333333em;line-height:.75em;vertical-align:-15%}.fa-2x{font-size:2em}.fa-3x{font-size:3em}.fa-4x{font-size:4em}.fa-5x{font-size:5em}.fa-fw{width:1.28571429em;text-align:center}.fa-ul{padding-left:0;margin-left:2.14285714em;list-style-type:none}.fa-ul>li{position:relative}.fa-li{position:absolute;left:-2.14285714em;width:2.14285714em;top:.14285714em;text-align:center}.fa-li.fa-lg{left:-1.85714286em}.fa-border{padding:.2em .25em .15em;border:solid .08em #eee;border-radius:.1em}.fa-pull-left{float:left}.fa-pull-right{float:right}.fa.fa-pull-left{margin-right:.3em}.fa.fa-pull-right{margin-left:.3em}.pull-right{float:right}.pull-left{float:left}.fa.pull-left{margin-right:.3em}.fa.pull-right{margin-left:.3em}.fa-spin{-webkit-animation:fa-spin 2s infinite linear;animation:fa-spin 2s infinite linear}.fa-pulse{-webkit-animation:fa-spin 1s infinite steps(8);animation:fa-spin 1s infinite steps(8)}@-webkit-keyframes fa-spin{0%{-webkit-transform:rotate(0deg);transform:rotate(0deg)}100%{-webkit-transform:rotate(359deg);transform:rotate(359deg)}}@keyframes fa-spin{0%{-webkit-transform:rotate(0deg);transform:rotate(0deg)}100%{-webkit-transform:rotate(359deg);transform:rotate(359deg)}}.fa-rotate-90{filter:progid:DXImageTransform.Microsoft.BasicImage(rotation=1);-webkit-transform:rotate(90deg);-ms-transform:rotate(90deg);transform:rotate(90deg)}.fa-rotate-180{filter:progid:DXImageTransform.Microsoft.BasicImage(rotation=2);-webkit-transform:rotate(180deg);-ms-transform:rotate(180deg);transform:rotate(180deg)}.fa-rotate-270{filter:progid:DXImageTransform.Microsoft.BasicImage(rotation=3);-webkit-transform:rotate(270deg);-ms-transform:rotate(270deg);transform:rotate(270deg)}.fa-flip-horizontal{filter:progid:DXImageTransform.Microsoft.BasicImage(rotation=0, mirror=1);-webkit-transform:scale(-1, 1);-ms-transform:scale(-1, 1);transform:scale(-1, 1)}.fa-flip-vertical{filter:progid:DXImageTransform.Microsoft.BasicImage(rotation=2, mirror=1);-webkit-transform:scale(1, -1);-ms-transform:scale(1, -1);transform:scale(1, -1)}:root .fa-rotate-90,:root .fa-rotate-180,:root .fa-rotate-270,:root .fa-flip-horizontal,:root .fa-flip-vertical{filter:none}.fa-stack{position:relative;display:inline-block;width:2em;height:2em;line-height:2em;vertical-align:middle}.fa-stack-1x,.fa-stack-2x{position:absolute;left:0;width:100%;text-align:center}.fa-stack-1x{line-height:inherit}.fa-stack-2x{font-size:2em}.fa-inverse{color:#fff}.fa-glass:before{content:"\f000"}.fa-music:before{content:"\f001"}.fa-search:before{content:"\f002"}.fa-envelope-o:before{content:"\f003"}.fa-heart:before{content:"\f004"}.fa-star:before{content:"\f005"}.fa-star-o:before{content:"\f006"}.fa-user:before{content:"\f007"}.fa-film:before{content:"\f008"}.fa-th-large:before{content:"\f009"}.fa-th:before{content:"\f00a"}.fa-th-list:before{content:"\f00b"}.fa-check:before{content:"\f00c"}.fa-remove:before,.fa-close:before,.fa-times:before{content:"\f00d"}.fa-search-plus:before{content:"\f00e"}.fa-search-minus:before{content:"\f010"}.fa-power-off:before{content:"\f011"}.fa-signal:before{content:"\f012"}.fa-gear:before,.fa-cog:before{content:"\f013"}.fa-trash-o:before{content:"\f014"}.fa-home:before{content:"\f015"}.fa-file-o:before{content:"\f016"}.fa-clock-o:before{content:"\f017"}.fa-road:before{content:"\f018"}.fa-download:before{content:"\f019"}.fa-arrow-circle-o-down:before{content:"\f01a"}.fa-arrow-circle-o-up:before{content:"\f01b"}.fa-inbox:before{content:"\f01c"}.fa-play-circle-o:before{content:"\f01d"}.fa-rotate-right:before,.fa-repeat:before{content:"\f01e"}.fa-refresh:before{content:"\f021"}.fa-list-alt:before{content:"\f022"}.fa-lock:before{content:"\f023"}.fa-flag:before{content:"\f024"}.fa-headphones:before{content:"\f025"}.fa-volume-off:before{content:"\f026"}.fa-volume-down:before{content:"\f027"}.fa-volume-up:before{content:"\f028"}.fa-qrcode:before{content:"\f029"}.fa-barcode:before{content:"\f02a"}.fa-tag:before{content:"\f02b"}.fa-tags:before{content:"\f02c"}.fa-book:before{content:"\f02d"}.fa-bookmark:before{content:"\f02e"}.fa-print:before{content:"\f02f"}.fa-camera:before{content:"\f030"}.fa-font:before{content:"\f031"}.fa-bold:before{content:"\f032"}.fa-italic:before{content:"\f033"}.fa-text-height:before{content:"\f034"}.fa-text-width:before{content:"\f035"}.fa-align-left:before{content:"\f036"}.fa-align-center:before{content:"\f037"}.fa-align-right:before{content:"\f038"}.fa-align-justify:before{content:"\f039"}.fa-list:before{content:"\f03a"}.fa-dedent:before,.fa-outdent:before{content:"\f03b"}.fa-indent:before{content:"\f03c"}.fa-video-camera:before{content:"\f03d"}.fa-photo:before,.fa-image:before,.fa-picture-o:before{content:"\f03e"}.fa-pencil:before{content:"\f040"}.fa-map-marker:before{content:"\f041"}.fa-adjust:before{content:"\f042"}.fa-tint:before{content:"\f043"}.fa-edit:before,.fa-pencil-square-o:before{content:"\f044"}.fa-share-square-o:before{content:"\f045"}.fa-check-square-o:before{content:"\f046"}.fa-arrows:before{content:"\f047"}.fa-step-backward:before{content:"\f048"}.fa-fast-backward:before{content:"\f049"}.fa-backward:before{content:"\f04a"}.fa-play:before{content:"\f04b"}.fa-pause:before{content:"\f04c"}.fa-stop:before{content:"\f04d"}.fa-forward:before{content:"\f04e"}.fa-fast-forward:before{content:"\f050"}.fa-step-forward:before{content:"\f051"}.fa-eject:before{content:"\f052"}.fa-chevron-left:before{content:"\f053"}.fa-chevron-right:before{content:"\f054"}.fa-plus-circle:before{content:"\f055"}.fa-minus-circle:before{content:"\f056"}.fa-times-circle:before{content:"\f057"}.fa-check-circle:before{content:"\f058"}.fa-question-circle:before{content:"\f059"}.fa-info-circle:before{content:"\f05a"}.fa-crosshairs:before{content:"\f05b"}.fa-times-circle-o:before{content:"\f05c"}.fa-check-circle-o:before{content:"\f05d"}.fa-ban:before{content:"\f05e"}.fa-arrow-left:before{content:"\f060"}.fa-arrow-right:before{content:"\f061"}.fa-arrow-up:before{content:"\f062"}.fa-arrow-down:before{content:"\f063"}.fa-mail-forward:before,.fa-share:before{content:"\f064"}.fa-expand:before{content:"\f065"}.fa-compress:before{content:"\f066"}.fa-plus:before{content:"\f067"}.fa-minus:before{content:"\f068"}.fa-asterisk:before{content:"\f069"}.fa-exclamation-circle:before{content:"\f06a"}.fa-gift:before{content:"\f06b"}.fa-leaf:before{content:"\f06c"}.fa-fire:before{content:"\f06d"}.fa-eye:before{content:"\f06e"}.fa-eye-slash:before{content:"\f070"}.fa-warning:before,.fa-exclamation-triangle:before{content:"\f071"}.fa-plane:before{content:"\f072"}.fa-calendar:before{content:"\f073"}.fa-random:before{content:"\f074"}.fa-comment:before{content:"\f075"}.fa-magnet:before{content:"\f076"}.fa-chevron-up:before{content:"\f077"}.fa-chevron-down:before{content:"\f078"}.fa-retweet:before{content:"\f079"}.fa-shopping-cart:before{content:"\f07a"}.fa-folder:before{content:"\f07b"}.fa-folder-open:before{content:"\f07c"}.fa-arrows-v:before{content:"\f07d"}.fa-arrows-h:before{content:"\f07e"}.fa-bar-chart-o:before,.fa-bar-chart:before{content:"\f080"}.fa-twitter-square:before{content:"\f081"}.fa-facebook-square:before{content:"\f082"}.fa-camera-retro:before{content:"\f083"}.fa-key:before{content:"\f084"}.fa-gears:before,.fa-cogs:before{content:"\f085"}.fa-comments:before{content:"\f086"}.fa-thumbs-o-up:before{content:"\f087"}.fa-thumbs-o-down:before{content:"\f088"}.fa-star-half:before{content:"\f089"}.fa-heart-o:before{content:"\f08a"}.fa-sign-out:before{content:"\f08b"}.fa-linkedin-square:before{content:"\f08c"}.fa-thumb-tack:before{content:"\f08d"}.fa-external-link:before{content:"\f08e"}.fa-sign-in:before{content:"\f090"}.fa-trophy:before{content:"\f091"}.fa-github-square:before{content:"\f092"}.fa-upload:before{content:"\f093"}.fa-lemon-o:before{content:"\f094"}.fa-phone:before{content:"\f095"}.fa-square-o:before{content:"\f096"}.fa-bookmark-o:before{content:"\f097"}.fa-phone-square:before{content:"\f098"}.fa-twitter:before{content:"\f099"}.fa-facebook-f:before,.fa-facebook:before{content:"\f09a"}.fa-github:before{content:"\f09b"}.fa-unlock:before{content:"\f09c"}.fa-credit-card:before{content:"\f09d"}.fa-feed:before,.fa-rss:before{content:"\f09e"}.fa-hdd-o:before{content:"\f0a0"}.fa-bullhorn:before{content:"\f0a1"}.fa-bell:before{content:"\f0f3"}.fa-certificate:before{content:"\f0a3"}.fa-hand-o-right:before{content:"\f0a4"}.fa-hand-o-left:before{content:"\f0a5"}.fa-hand-o-up:before{content:"\f0a6"}.fa-hand-o-down:before{content:"\f0a7"}.fa-arrow-circle-left:before{content:"\f0a8"}.fa-arrow-circle-right:before{content:"\f0a9"}.fa-arrow-circle-up:before{content:"\f0aa"}.fa-arrow-circle-down:before{content:"\f0ab"}.fa-globe:before{content:"\f0ac"}.fa-wrench:before{content:"\f0ad"}.fa-tasks:before{content:"\f0ae"}.fa-filter:before{content:"\f0b0"}.fa-briefcase:before{content:"\f0b1"}.fa-arrows-alt:before{content:"\f0b2"}.fa-group:before,.fa-users:before{content:"\f0c0"}.fa-chain:before,.fa-link:before{content:"\f0c1"}.fa-cloud:before{content:"\f0c2"}.fa-flask:before{content:"\f0c3"}.fa-cut:before,.fa-scissors:before{content:"\f0c4"}.fa-copy:before,.fa-files-o:before{content:"\f0c5"}.fa-paperclip:before{content:"\f0c6"}.fa-save:before,.fa-floppy-o:before{content:"\f0c7"}.fa-square:before{content:"\f0c8"}.fa-navicon:before,.fa-reorder:before,.fa-bars:before{content:"\f0c9"}.fa-list-ul:before{content:"\f0ca"}.fa-list-ol:before{content:"\f0cb"}.fa-strikethrough:before{content:"\f0cc"}.fa-underline:before{content:"\f0cd"}.fa-table:before{content:"\f0ce"}.fa-magic:before{content:"\f0d0"}.fa-truck:before{content:"\f0d1"}.fa-pinterest:before{content:"\f0d2"}.fa-pinterest-square:before{content:"\f0d3"}.fa-google-plus-square:before{content:"\f0d4"}.fa-google-plus:before{content:"\f0d5"}.fa-money:before{content:"\f0d6"}.fa-caret-down:before{content:"\f0d7"}.fa-caret-up:before{content:"\f0d8"}.fa-caret-left:before{content:"\f0d9"}.fa-caret-right:before{content:"\f0da"}.fa-columns:before{content:"\f0db"}.fa-unsorted:before,.fa-sort:before{content:"\f0dc"}.fa-sort-down:before,.fa-sort-desc:before{content:"\f0dd"}.fa-sort-up:before,.fa-sort-asc:before{content:"\f0de"}.fa-envelope:before{content:"\f0e0"}.fa-linkedin:before{content:"\f0e1"}.fa-rotate-left:before,.fa-undo:before{content:"\f0e2"}.fa-legal:before,.fa-gavel:before{content:"\f0e3"}.fa-dashboard:before,.fa-tachometer:before{content:"\f0e4"}.fa-comment-o:before{content:"\f0e5"}.fa-comments-o:before{content:"\f0e6"}.fa-flash:before,.fa-bolt:before{content:"\f0e7"}.fa-sitemap:before{content:"\f0e8"}.fa-umbrella:before{content:"\f0e9"}.fa-paste:before,.fa-clipboard:before{content:"\f0ea"}.fa-lightbulb-o:before{content:"\f0eb"}.fa-exchange:before{content:"\f0ec"}.fa-cloud-download:before{content:"\f0ed"}.fa-cloud-upload:before{content:"\f0ee"}.fa-user-md:before{content:"\f0f0"}.fa-stethoscope:before{content:"\f0f1"}.fa-suitcase:before{content:"\f0f2"}.fa-bell-o:before{content:"\f0a2"}.fa-coffee:before{content:"\f0f4"}.fa-cutlery:before{content:"\f0f5"}.fa-file-text-o:before{content:"\f0f6"}.fa-building-o:before{content:"\f0f7"}.fa-hospital-o:before{content:"\f0f8"}.fa-ambulance:before{content:"\f0f9"}.fa-medkit:before{content:"\f0fa"}.fa-fighter-jet:before{content:"\f0fb"}.fa-beer:before{content:"\f0fc"}.fa-h-square:before{content:"\f0fd"}.fa-plus-square:before{content:"\f0fe"}.fa-angle-double-left:before{content:"\f100"}.fa-angle-double-right:before{content:"\f101"}.fa-angle-double-up:before{content:"\f102"}.fa-angle-double-down:before{content:"\f103"}.fa-angle-left:before{content:"\f104"}.fa-angle-right:before{content:"\f105"}.fa-angle-up:before{content:"\f106"}.fa-angle-down:before{content:"\f107"}.fa-desktop:before{content:"\f108"}.fa-laptop:before{content:"\f109"}.fa-tablet:before{content:"\f10a"}.fa-mobile-phone:before,.fa-mobile:before{content:"\f10b"}.fa-circle-o:before{content:"\f10c"}.fa-quote-left:before{content:"\f10d"}.fa-quote-right:before{content:"\f10e"}.fa-spinner:before{content:"\f110"}.fa-circle:before{content:"\f111"}.fa-mail-reply:before,.fa-reply:before{content:"\f112"}.fa-github-alt:before{content:"\f113"}.fa-folder-o:before{content:"\f114"}.fa-folder-open-o:before{content:"\f115"}.fa-smile-o:before{content:"\f118"}.fa-frown-o:before{content:"\f119"}.fa-meh-o:before{content:"\f11a"}.fa-gamepad:before{content:"\f11b"}.fa-keyboard-o:before{content:"\f11c"}.fa-flag-o:before{content:"\f11d"}.fa-flag-checkered:before{content:"\f11e"}.fa-terminal:before{content:"\f120"}.fa-code:before{content:"\f121"}.fa-mail-reply-all:before,.fa-reply-all:before{content:"\f122"}.fa-star-half-empty:before,.fa-star-half-full:before,.fa-star-half-o:before{content:"\f123"}.fa-location-arrow:before{content:"\f124"}.fa-crop:before{content:"\f125"}.fa-code-fork:before{content:"\f126"}.fa-unlink:before,.fa-chain-broken:before{content:"\f127"}.fa-question:before{content:"\f128"}.fa-info:before{content:"\f129"}.fa-exclamation:before{content:"\f12a"}.fa-superscript:before{content:"\f12b"}.fa-subscript:before{content:"\f12c"}.fa-eraser:before{content:"\f12d"}.fa-puzzle-piece:before{content:"\f12e"}.fa-microphone:before{content:"\f130"}.fa-microphone-slash:before{content:"\f131"}.fa-shield:before{content:"\f132"}.fa-calendar-o:before{content:"\f133"}.fa-fire-extinguisher:before{content:"\f134"}.fa-rocket:before{content:"\f135"}.fa-maxcdn:before{content:"\f136"}.fa-chevron-circle-left:before{content:"\f137"}.fa-chevron-circle-right:before{content:"\f138"}.fa-chevron-circle-up:before{content:"\f139"}.fa-chevron-circle-down:before{content:"\f13a"}.fa-html5:before{content:"\f13b"}.fa-css3:before{content:"\f13c"}.fa-anchor:before{content:"\f13d"}.fa-unlock-alt:before{content:"\f13e"}.fa-bullseye:before{content:"\f140"}.fa-ellipsis-h:before{content:"\f141"}.fa-ellipsis-v:before{content:"\f142"}.fa-rss-square:before{content:"\f143"}.fa-play-circle:before{content:"\f144"}.fa-ticket:before{content:"\f145"}.fa-minus-square:before{content:"\f146"}.fa-minus-square-o:before{content:"\f147"}.fa-level-up:before{content:"\f148"}.fa-level-down:before{content:"\f149"}.fa-check-square:before{content:"\f14a"}.fa-pencil-square:before{content:"\f14b"}.fa-external-link-square:before{content:"\f14c"}.fa-share-square:before{content:"\f14d"}.fa-compass:before{content:"\f14e"}.fa-toggle-down:before,.fa-caret-square-o-down:before{content:"\f150"}.fa-toggle-up:before,.fa-caret-square-o-up:before{content:"\f151"}.fa-toggle-right:before,.fa-caret-square-o-right:before{content:"\f152"}.fa-euro:before,.fa-eur:before{content:"\f153"}.fa-gbp:before{content:"\f154"}.fa-dollar:before,.fa-usd:before{content:"\f155"}.fa-rupee:before,.fa-inr:before{content:"\f156"}.fa-cny:before,.fa-rmb:before,.fa-yen:before,.fa-jpy:before{content:"\f157"}.fa-ruble:before,.fa-rouble:before,.fa-rub:before{content:"\f158"}.fa-won:before,.fa-krw:before{content:"\f159"}.fa-bitcoin:before,.fa-btc:before{content:"\f15a"}.fa-file:before{content:"\f15b"}.fa-file-text:before{content:"\f15c"}.fa-sort-alpha-asc:before{content:"\f15d"}.fa-sort-alpha-desc:before{content:"\f15e"}.fa-sort-amount-asc:before{content:"\f160"}.fa-sort-amount-desc:before{content:"\f161"}.fa-sort-numeric-asc:before{content:"\f162"}.fa-sort-numeric-desc:before{content:"\f163"}.fa-thumbs-up:before{content:"\f164"}.fa-thumbs-down:before{content:"\f165"}.fa-youtube-square:before{content:"\f166"}.fa-youtube:before{content:"\f167"}.fa-xing:before{content:"\f168"}.fa-xing-square:before{content:"\f169"}.fa-youtube-play:before{content:"\f16a"}.fa-dropbox:before{content:"\f16b"}.fa-stack-overflow:before{content:"\f16c"}.fa-instagram:before{content:"\f16d"}.fa-flickr:before{content:"\f16e"}.fa-adn:before{content:"\f170"}.fa-bitbucket:before{content:"\f171"}.fa-bitbucket-square:before{content:"\f172"}.fa-tumblr:before{content:"\f173"}.fa-tumblr-square:before{content:"\f174"}.fa-long-arrow-down:before{content:"\f175"}.fa-long-arrow-up:before{content:"\f176"}.fa-long-arrow-left:before{content:"\f177"}.fa-long-arrow-right:before{content:"\f178"}.fa-apple:before{content:"\f179"}.fa-windows:before{content:"\f17a"}.fa-android:before{content:"\f17b"}.fa-linux:before{content:"\f17c"}.fa-dribbble:before{content:"\f17d"}.fa-skype:before{content:"\f17e"}.fa-foursquare:before{content:"\f180"}.fa-trello:before{content:"\f181"}.fa-female:before{content:"\f182"}.fa-male:before{content:"\f183"}.fa-gittip:before,.fa-gratipay:before{content:"\f184"}.fa-sun-o:before{content:"\f185"}.fa-moon-o:before{content:"\f186"}.fa-archive:before{content:"\f187"}.fa-bug:before{content:"\f188"}.fa-vk:before{content:"\f189"}.fa-weibo:before{content:"\f18a"}.fa-renren:before{content:"\f18b"}.fa-pagelines:before{content:"\f18c"}.fa-stack-exchange:before{content:"\f18d"}.fa-arrow-circle-o-right:before{content:"\f18e"}.fa-arrow-circle-o-left:before{content:"\f190"}.fa-toggle-left:before,.fa-caret-square-o-left:before{content:"\f191"}.fa-dot-circle-o:before{content:"\f192"}.fa-wheelchair:before{content:"\f193"}.fa-vimeo-square:before{content:"\f194"}.fa-turkish-lira:before,.fa-try:before{content:"\f195"}.fa-plus-square-o:before{content:"\f196"}.fa-space-shuttle:before{content:"\f197"}.fa-slack:before{content:"\f198"}.fa-envelope-square:before{content:"\f199"}.fa-wordpress:before{content:"\f19a"}.fa-openid:before{content:"\f19b"}.fa-institution:before,.fa-bank:before,.fa-university:before{content:"\f19c"}.fa-mortar-board:before,.fa-graduation-cap:before{content:"\f19d"}.fa-yahoo:before{content:"\f19e"}.fa-google:before{content:"\f1a0"}.fa-reddit:before{content:"\f1a1"}.fa-reddit-square:before{content:"\f1a2"}.fa-stumbleupon-circle:before{content:"\f1a3"}.fa-stumbleupon:before{content:"\f1a4"}.fa-delicious:before{content:"\f1a5"}.fa-digg:before{content:"\f1a6"}.fa-pied-piper:before{content:"\f1a7"}.fa-pied-piper-alt:before{content:"\f1a8"}.fa-drupal:before{content:"\f1a9"}.fa-joomla:before{content:"\f1aa"}.fa-language:before{content:"\f1ab"}.fa-fax:before{content:"\f1ac"}.fa-building:before{content:"\f1ad"}.fa-child:before{content:"\f1ae"}.fa-paw:before{content:"\f1b0"}.fa-spoon:before{content:"\f1b1"}.fa-cube:before{content:"\f1b2"}.fa-cubes:before{content:"\f1b3"}.fa-behance:before{content:"\f1b4"}.fa-behance-square:before{content:"\f1b5"}.fa-steam:before{content:"\f1b6"}.fa-steam-square:before{content:"\f1b7"}.fa-recycle:before{content:"\f1b8"}.fa-automobile:before,.fa-car:before{content:"\f1b9"}.fa-cab:before,.fa-taxi:before{content:"\f1ba"}.fa-tree:before{content:"\f1bb"}.fa-spotify:before{content:"\f1bc"}.fa-deviantart:before{content:"\f1bd"}.fa-soundcloud:before{content:"\f1be"}.fa-database:before{content:"\f1c0"}.fa-file-pdf-o:before{content:"\f1c1"}.fa-file-word-o:before{content:"\f1c2"}.fa-file-excel-o:before{content:"\f1c3"}.fa-file-powerpoint-o:before{content:"\f1c4"}.fa-file-photo-o:before,.fa-file-picture-o:before,.fa-file-image-o:before{content:"\f1c5"}.fa-file-zip-o:before,.fa-file-archive-o:before{content:"\f1c6"}.fa-file-sound-o:before,.fa-file-audio-o:before{content:"\f1c7"}.fa-file-movie-o:before,.fa-file-video-o:before{content:"\f1c8"}.fa-file-code-o:before{content:"\f1c9"}.fa-vine:before{content:"\f1ca"}.fa-codepen:before{content:"\f1cb"}.fa-jsfiddle:before{content:"\f1cc"}.fa-life-bouy:before,.fa-life-buoy:before,.fa-life-saver:before,.fa-support:before,.fa-life-ring:before{content:"\f1cd"}.fa-circle-o-notch:before{content:"\f1ce"}.fa-ra:before,.fa-rebel:before{content:"\f1d0"}.fa-ge:before,.fa-empire:before{content:"\f1d1"}.fa-git-square:before{content:"\f1d2"}.fa-git:before{content:"\f1d3"}.fa-y-combinator-square:before,.fa-yc-square:before,.fa-hacker-news:before{content:"\f1d4"}.fa-tencent-weibo:before{content:"\f1d5"}.fa-qq:before{content:"\f1d6"}.fa-wechat:before,.fa-weixin:before{content:"\f1d7"}.fa-send:before,.fa-paper-plane:before{content:"\f1d8"}.fa-send-o:before,.fa-paper-plane-o:before{content:"\f1d9"}.fa-history:before{content:"\f1da"}.fa-circle-thin:before{content:"\f1db"}.fa-header:before{content:"\f1dc"}.fa-paragraph:before{content:"\f1dd"}.fa-sliders:before{content:"\f1de"}.fa-share-alt:before{content:"\f1e0"}.fa-share-alt-square:before{content:"\f1e1"}.fa-bomb:before{content:"\f1e2"}.fa-soccer-ball-o:before,.fa-futbol-o:before{content:"\f1e3"}.fa-tty:before{content:"\f1e4"}.fa-binoculars:before{content:"\f1e5"}.fa-plug:before{content:"\f1e6"}.fa-slideshare:before{content:"\f1e7"}.fa-twitch:before{content:"\f1e8"}.fa-yelp:before{content:"\f1e9"}.fa-newspaper-o:before{content:"\f1ea"}.fa-wifi:before{content:"\f1eb"}.fa-calculator:before{content:"\f1ec"}.fa-paypal:before{content:"\f1ed"}.fa-google-wallet:before{content:"\f1ee"}.fa-cc-visa:before{content:"\f1f0"}.fa-cc-mastercard:before{content:"\f1f1"}.fa-cc-discover:before{content:"\f1f2"}.fa-cc-amex:before{content:"\f1f3"}.fa-cc-paypal:before{content:"\f1f4"}.fa-cc-stripe:before{content:"\f1f5"}.fa-bell-slash:before{content:"\f1f6"}.fa-bell-slash-o:before{content:"\f1f7"}.fa-trash:before{content:"\f1f8"}.fa-copyright:before{content:"\f1f9"}.fa-at:before{content:"\f1fa"}.fa-eyedropper:before{content:"\f1fb"}.fa-paint-brush:before{content:"\f1fc"}.fa-birthday-cake:before{content:"\f1fd"}.fa-area-chart:before{content:"\f1fe"}.fa-pie-chart:before{content:"\f200"}.fa-line-chart:before{content:"\f201"}.fa-lastfm:before{content:"\f202"}.fa-lastfm-square:before{content:"\f203"}.fa-toggle-off:before{content:"\f204"}.fa-toggle-on:before{content:"\f205"}.fa-bicycle:before{content:"\f206"}.fa-bus:before{content:"\f207"}.fa-ioxhost:before{content:"\f208"}.fa-angellist:before{content:"\f209"}.fa-cc:before{content:"\f20a"}.fa-shekel:before,.fa-sheqel:before,.fa-ils:before{content:"\f20b"}.fa-meanpath:before{content:"\f20c"}.fa-buysellads:before{content:"\f20d"}.fa-connectdevelop:before{content:"\f20e"}.fa-dashcube:before{content:"\f210"}.fa-forumbee:before{content:"\f211"}.fa-leanpub:before{content:"\f212"}.fa-sellsy:before{content:"\f213"}.fa-shirtsinbulk:before{content:"\f214"}.fa-simplybuilt:before{content:"\f215"}.fa-skyatlas:before{content:"\f216"}.fa-cart-plus:before{content:"\f217"}.fa-cart-arrow-down:before{content:"\f218"}.fa-diamond:before{content:"\f219"}.fa-ship:before{content:"\f21a"}.fa-user-secret:before{content:"\f21b"}.fa-motorcycle:before{content:"\f21c"}.fa-street-view:before{content:"\f21d"}.fa-heartbeat:before{content:"\f21e"}.fa-venus:before{content:"\f221"}.fa-mars:before{content:"\f222"}.fa-mercury:before{content:"\f223"}.fa-intersex:before,.fa-transgender:before{content:"\f224"}.fa-transgender-alt:before{content:"\f225"}.fa-venus-double:before{content:"\f226"}.fa-mars-double:before{content:"\f227"}.fa-venus-mars:before{content:"\f228"}.fa-mars-stroke:before{content:"\f229"}.fa-mars-stroke-v:before{content:"\f22a"}.fa-mars-stroke-h:before{content:"\f22b"}.fa-neuter:before{content:"\f22c"}.fa-genderless:before{content:"\f22d"}.fa-facebook-official:before{content:"\f230"}.fa-pinterest-p:before{content:"\f231"}.fa-whatsapp:before{content:"\f232"}.fa-server:before{content:"\f233"}.fa-user-plus:before{content:"\f234"}.fa-user-times:before{content:"\f235"}.fa-hotel:before,.fa-bed:before{content:"\f236"}.fa-viacoin:before{content:"\f237"}.fa-train:before{content:"\f238"}.fa-subway:before{content:"\f239"}.fa-medium:before{content:"\f23a"}.fa-yc:before,.fa-y-combinator:before{content:"\f23b"}.fa-optin-monster:before{content:"\f23c"}.fa-opencart:before{content:"\f23d"}.fa-expeditedssl:before{content:"\f23e"}.fa-battery-4:before,.fa-battery-full:before{content:"\f240"}.fa-battery-3:before,.fa-battery-three-quarters:before{content:"\f241"}.fa-battery-2:before,.fa-battery-half:before{content:"\f242"}.fa-battery-1:before,.fa-battery-quarter:before{content:"\f243"}.fa-battery-0:before,.fa-battery-empty:before{content:"\f244"}.fa-mouse-pointer:before{content:"\f245"}.fa-i-cursor:before{content:"\f246"}.fa-object-group:before{content:"\f247"}.fa-object-ungroup:before{content:"\f248"}.fa-sticky-note:before{content:"\f249"}.fa-sticky-note-o:before{content:"\f24a"}.fa-cc-jcb:before{content:"\f24b"}.fa-cc-diners-club:before{content:"\f24c"}.fa-clone:before{content:"\f24d"}.fa-balance-scale:before{content:"\f24e"}.fa-hourglass-o:before{content:"\f250"}.fa-hourglass-1:before,.fa-hourglass-start:before{content:"\f251"}.fa-hourglass-2:before,.fa-hourglass-half:before{content:"\f252"}.fa-hourglass-3:before,.fa-hourglass-end:before{content:"\f253"}.fa-hourglass:before{content:"\f254"}.fa-hand-grab-o:before,.fa-hand-rock-o:before{content:"\f255"}.fa-hand-stop-o:before,.fa-hand-paper-o:before{content:"\f256"}.fa-hand-scissors-o:before{content:"\f257"}.fa-hand-lizard-o:before{content:"\f258"}.fa-hand-spock-o:before{content:"\f259"}.fa-hand-pointer-o:before{content:"\f25a"}.fa-hand-peace-o:before{content:"\f25b"}.fa-trademark:before{content:"\f25c"}.fa-registered:before{content:"\f25d"}.fa-creative-commons:before{content:"\f25e"}.fa-gg:before{content:"\f260"}.fa-gg-circle:before{content:"\f261"}.fa-tripadvisor:before{content:"\f262"}.fa-odnoklassniki:before{content:"\f263"}.fa-odnoklassniki-square:before{content:"\f264"}.fa-get-pocket:before{content:"\f265"}.fa-wikipedia-w:before{content:"\f266"}.fa-safari:before{content:"\f267"}.fa-chrome:before{content:"\f268"}.fa-firefox:before{content:"\f269"}.fa-opera:before{content:"\f26a"}.fa-internet-explorer:before{content:"\f26b"}.fa-tv:before,.fa-television:before{content:"\f26c"}.fa-contao:before{content:"\f26d"}.fa-500px:before{content:"\f26e"}.fa-amazon:before{content:"\f270"}.fa-calendar-plus-o:before{content:"\f271"}.fa-calendar-minus-o:before{content:"\f272"}.fa-calendar-times-o:before{content:"\f273"}.fa-calendar-check-o:before{content:"\f274"}.fa-industry:before{content:"\f275"}.fa-map-pin:before{content:"\f276"}.fa-map-signs:before{content:"\f277"}.fa-map-o:before{content:"\f278"}.fa-map:before{content:"\f279"}.fa-commenting:before{content:"\f27a"}.fa-commenting-o:before{content:"\f27b"}.fa-houzz:before{content:"\f27c"}.fa-vimeo:before{content:"\f27d"}.fa-black-tie:before{content:"\f27e"}.fa-fonticons:before{content:"\f280"} diff --git a/Webseiten/Docker - Build, Ship, and Run Any App, Anywhere_files/forms2-theme-simple.css b/Webseiten/Docker - Build, Ship, and Run Any App, Anywhere_files/forms2-theme-simple.css new file mode 100644 index 0000000..ce53dd2 --- /dev/null +++ b/Webseiten/Docker - Build, Ship, and Run Any App, Anywhere_files/forms2-theme-simple.css @@ -0,0 +1,32 @@ +#mktoStyleLoaded { + /* css load detection, do not remove */ + color:#123456; +} +.mktoForm fieldset {} +.mktoForm fieldset legend{} +.mktoForm input[type=text], +.mktoForm input[type=url], +.mktoForm input[type=email], +.mktoForm input[type=tel], +.mktoForm input[type=number], +.mktoForm input[type=date]{} + +.mktoForm input[type=text], +.mktoForm input[type=url], +.mktoForm input[type=email], +.mktoForm input[type=tel], +.mktoForm input[type=number], +.mktoForm input[type=date], +.mktoForm textarea.mktoField, +.mktoForm select.mktoField { + padding:2px 3px; +} + +.mktoForm input[type=text]:focus, +.mktoForm input[type=url]:focus, +.mktoForm input[type=email]:focus, +.mktoForm input[type=tel]:focus, +.mktoForm input[type=number]:focus, +.mktoForm input[type=date]:focus, +.mktoForm select.mktoField:focus, +.mktoForm textarea.mktoField:focus{} \ No newline at end of file diff --git a/Webseiten/Docker - Build, Ship, and Run Any App, Anywhere_files/forms2.css b/Webseiten/Docker - Build, Ship, and Run Any App, Anywhere_files/forms2.css new file mode 100644 index 0000000..bccdb62 --- /dev/null +++ b/Webseiten/Docker - Build, Ship, and Run Any App, Anywhere_files/forms2.css @@ -0,0 +1,562 @@ +/* This is used to test if the stylesheet has been loaded yet*/ +#mktoStyleLoaded { + background-color: #123456; + display: none; +} +.mktoForm { + text-align: left; +} +.mktoForm .mktoClear { + clear: both; + float: none; +} +.mktoForm div, +.mktoForm span, +.mktoForm label, +.mktoForm p { + text-align: left; + margin: 0; + padding: 0; +} +.mktoForm input, +.mktoForm select, +.mktoForm textarea { + margin: 0; +} +.mktoForm * { + font-family: inherit; +} +.mktoForm .mktoOffset { + float: left; + height: 1.2em; +} +.mktoForm .mktoGutter { + float: left; + height: 1.2em; +} +.mktoForm .mktoFieldWrap { + float: left; +} +.mktoForm .mktoLabel { + float: left; + line-height: 1.2em; + padding-top: 0.3em; +} +.mktoForm .mktoField { + line-height: 1.2em; + font-size: 1em; + float: left; +} +.mktoForm .mktoPlaceholder { + float: left; +} +.mktoForm .mktoLogicalField { + float: left; +} +.mktoForm fieldset { + padding: 0; + margin: 0; +} +.mktoForm fieldset legend { + margin: 0 1em 0.5em; + color: inherit; +} +.mktoForm a.mktoNotYou { + cursor: pointer; + color: #4692f3; +} +.mktoForm a.mktoNotYou:hover { + text-decoration: underline; +} +.mktoForm .mktoAsterix { + float: right; + color: #bf0000; + padding-left: 5px; + display: none; +} +.mktoForm .mktoRadioList, +.mktoForm .mktoCheckboxList { + padding: 0.3em; + float: left; +} +.mktoForm .mktoRadioList > label, +.mktoForm .mktoCheckboxList > label { + margin-left: 1.5em; + margin-top: 0.1em; + margin-bottom: 0.3em; + line-height: 1.2em; + display: block; + min-height: 12px; +} +.mktoForm.ie7 .mktoRadioList > label, +.mktoForm.ie7 .mktoCheckboxList > label { + padding: 0.2em 0 0; +} +.mktoForm .mktoRadioList > label > input, +.mktoForm .mktoCheckboxList > label > input { + float: left; + margin: 0; + margin-left: -1.5em; +} +.mktoForm .mktoRadioList > input, +.mktoForm .mktoCheckboxList > input { + padding: 0; +} +.mktoForm .mktoLabelToLeft > label { + text-align: right; + margin-left: 0; + margin-right: 1.5em; +} +.mktoForm .mktoLabelToLeft input[type=checkbox], +.mktoForm .mktoLabelToLeft input[type=radio] { + position: absolute; + right: 0.3em; +} +.mktoForm.mktoLayoutAbove .mktoRequiredField .mktoAsterix { + float: left; + padding-left: 0; + padding-right: 5px; +} +.mktoForm .mktoRequiredField .mktoAsterix { + display: block; +} +.mktoForm .mktoRequiredField label.mktoLabel { + font-weight: bold; +} +.mktoForm input[type=text], +.mktoForm input[type=url], +.mktoForm input[type=email], +.mktoForm input[type=tel], +.mktoForm input[type=number], +.mktoForm input[type=date] { + padding: 0.1em 0.2em; + line-height: 1.2em; + margin: 0; +} +.mktoForm input[type=range] { + padding: 0.25em 0; + margin: 0; +} +.mktoForm input[type=range]::-ms-tooltip { + display: none; +} +.mktoForm input[type=url], +.mktoForm input[type=text], +.mktoForm input[type=date], +.mktoForm input[type=tel], +.mktoForm input[type=email], +.mktoForm input[type=number], +.mktoForm textarea.mktoField, +.mktoForm select.mktoField { + -moz-box-sizing: border-box; + -webkit-box-sizing: border-box; + -webkit-box-sizing: border-box; + -moz-box-sizing: border-box; + box-sizing: border-box; +} +.mktoForm .mktoFormRow { + clear: both; +} +.mktoForm .mktoFormCol { + float: left; + position: relative; + min-height: 2em; +} +.mktoButtonRow { + display: inline-block; + position: relative; +} +.mktoForm textarea.mktoField { + display: inline-block; + padding: 0.2em; + margin: 0; + line-height: 1.2em; + overflow: auto; + resize: none; + float: none; +} +/* Firefox computes row height wrong for the last 13 years... https://bugzilla.mozilla.org/show_bug.cgi?id=33654 */ +.mktoForm textarea[rows="1"] { + height: 2em; +} +.mktoForm textarea[rows="2"] { + height: 3.4em; +} +.mktoForm textarea[rows="3"] { + height: 4.6em; +} +.mktoForm textarea[rows="4"] { + height: 5.8em; +} +.mktoForm textarea[rows="5"] { + height: 7em; +} +.mktoForm textarea[rows="6"] { + height: 8.2em; +} +.mktoForm textarea[rows="7"] { + height: 9.4em; +} +.mktoForm textarea[rows="8"] { + height: 10.6em; +} +.mktoForm.mktoLayoutCenter .mktoLabel { + text-align: right; +} +.mktoForm.mktoLayoutAbove .mktoGutter { + display: none; +} +.mktoForm.mktoLayoutAbove .mktoLabel { + text-align: left; +} +.mktoForm.mktoLayoutAbove .mktoRadioList, +.mktoForm.mktoLayoutAbove .mktoCheckboxList { + float: none; + clear: left; +} +.mktoForm.mktoLayoutAbove .mktoField, +.mktoForm.mktoLayoutAbove .mktoLogicalField { + clear: left; +} +.mktoForm.mktoLayoutAbove textarea.mktoField { + float: left; +} +.mktoForm .mktoError { + position: absolute; + z-index: 99; + color: #bf0000; +} +.mktoForm .mktoError .mktoErrorArrowWrap { + width: 16px; + height: 8px; + overflow: hidden; + position: absolute; + top: 0; + left: 5px; + z-index: 100; +} +.mktoForm.ie7 .mktoError .mktoErrorArrowWrap { + top: -8px; +} +.mktoForm .mktoError .mktoErrorArrow { + background-color: #e51b00; + border: 1px solid #9f1300; + border-right: none; + border-bottom: none; + display: inline-block; + height: 16px; + -webkit-transform: rotate(45deg); + -moz-transform: rotate(45deg); + transform: rotate(45deg); + -ms-transform: rotate(45deg); + width: 16px; + margin-top: 5px; +} +/** These two styles are for browsers that don't support css transforms */ +.mktoForm .mktoError .mktoErrorArrowWrap.mktoArrowImage { + background: transparent url("../images/callout-arrow-up-red.png") top center no-repeat; + bottom: -7px; +} +.mktoForm .mktoError .mktoErrorArrowWrap.mktoArrowImage .mktoErrorArrow { + display: none; +} +.mktoForm .mktoError .mktoErrorMsg { + display: block; + margin-top: 7px; + background-color: #e51b00; + background-image: -webkit-linear-gradient(#e51b00 43%, #ba1600 100%); + background-image: -moz-linear-gradient(#e51b00 43%, #ba1600 100%); + background-image: linear-gradient(#e51b00 43%, #ba1600 100%); + background-image: -ms-linear-gradient(#e51b00 43%, #ba1600 100%); + border: 1px solid #9f1300; + -webkit-border-radius: 6px; + border-radius: 6px; + -webkit-box-shadow: rgba(0,0,0,0.65) 0 2px 7px, inset #ff3c3c 0 1px 0px; + box-shadow: rgba(0,0,0,0.65) 0 2px 7px, inset #ff3c3c 0 1px 0px; + color: #f3f3f3; + font-size: 1em; + line-height: 1.2em; + max-width: 16em; + padding: 0.4em 0.6em; + text-shadow: #901100 0 -1px 0; +} +.mktoForm .mktoError .mktoErrorMsg .mktoErrorDetail { + display: block; +} +.mktoForm button.mktoButton { + cursor: pointer; + margin: 0; +} +.mktoForm button.mktoButton:disabled { + opacity: 0.5; + -ms-filter: "progid:DXImageTransform.Microsoft.Alpha(Opacity=50)"; + filter: alpha(opacity=50); + cursor: default; +} +.mktoNoJS .mktoLabel { + display: block; + padding-right: 10px; + width: 110px; + text-align: right; +} +.mktoNoJS input[type=text] { + width: 150px; +} +.mktoForm .cf_widget_socialsignon .cf_sign_on { + margin-bottom: 1.5em; +} +.mktoForm .mktoRangeField .mktoRangeValue { + zoom: 1; + float: left; + display: none; + text-align: center; + position: absolute; + z-index: 99; + color: #000; +} +.mktoForm.ie7 .mktoRangeField .mktoRangeValue, +.mktoForm.ie6 .mktoRangeField .mktoRangeValue { + position: relative; +} +.mktoForm .mktoRangeField.mktoHover .mktoRangeValue { + display: block; +} +.mktoForm .mktoRangeField .mktoRangeValueArrowWrap { + width: 16px; + height: 8px; + overflow: hidden; + position: absolute; + bottom: -7px; + z-index: 100; +} +.mktoForm .mktoRangeField .mktoRangeValueArrow { + background-color: #028d05; + border: 1px solid #005602; + height: 16px; + -webkit-transform: rotate(45deg); + -moz-transform: rotate(45deg); + transform: rotate(45deg); + -ms-transform: rotate(45deg); + width: 16px; + background-color: #007d04; + border-left: none; + border-top: none; + margin-top: 5px; + position: absolute; + bottom: 5px; +} +/** These two styles are for browsers that don't support css transforms */ +.mktoForm .mktoRangeField .mktoRangeValueArrowWrap.mktoArrowImage { + background: transparent url("../images/callout-arrow-down-green.png") top center no-repeat; + bottom: -7px; +} +.mktoForm .mktoRangeField .mktoRangeValueArrowWrap.mktoArrowImage .mktoRangeValueArrow { + display: none; +} +.mktoForm .mktoRangeField .mktoRangeValueText { + display: block; + background-color: #028d05; + background-image: -webkit-linear-gradient(#028d05 43%, #007d04 100%); + background-image: -moz-linear-gradient(#028d05 43%, #007d04 100%); + background-image: linear-gradient(#028d05 43%, #007d04 100%); + background-image: -ms-linear-gradient(#028d05 43%, #007d04 100%); + border: 1px solid #005602; + -webkit-border-radius: 6px; + border-radius: 6px; + -webkit-box-shadow: rgba(0,0,0,0.65) 0 2px 7px, inset #00a500 0 1px 0px; + box-shadow: rgba(0,0,0,0.65) 0 2px 7px, inset #00a500 0 1px 0px; + color: #f3f3f3; + font-size: 1em; + line-height: 1.2em; + padding: 0.4em 0.6em; + text-shadow: #005602 0 -1px 0; + text-align: center; +} +.mktoModal { + position: absolute; + top: 0; + left: 0; + right: 0; +} +.mktoModal .mktoModalMask { + position: absolute; + z-index: 10000; + top: 0; + left: 0; + right: 0; + zoom: 1; + background: rgba(0,0,0,0.5); + filter: progid:DXImageTransform.Microsoft.gradient(startColorstr=#80000000, endColorstr=#80000000); + -ms-filter: "progid:DXImageTransform.Microsoft.gradient(startColorstr=#80000000, endColorstr=#80000000)"; +} +.mktoModal .mktoModalContent { + position: absolute; + z-index: 10001; + background: #fff; + padding: 10px; +} +.mktoModal .mktoModalClose { + position: absolute; + cursor: pointer; + top: -10px; + right: -10px; + background: #000; + color: #fff; + width: 19px; + height: 19px; + font-family: Arial, Helvetica, sans-serif; + font-size: 13px; + line-height: 19px; + -webkit-border-radius: 19px; + border-radius: 19px; + text-align: center; + border: 2px solid #ccc; +} +/* This part of the stylesheet is overrides for mobile browsers with screen width restrictions. + It should always be at the end of the document. */ +@media only screen and (max-width: 480px) { + .mktoForm, + .mktoForm * { + -webkit-box-sizing: border-box; + -moz-box-sizing: border-box; + box-sizing: border-box; + -moz-box-sizing: border-box; + padding: 10px; + } + .mktoForm .mktoGutter, + .mktoForm .mktoOffset { + display: none; + } + .mktoForm .mktoFormCol .mktoLabel { + text-align: left; + width: 100%; + } + .mktoForm .mktoFormCol { + float: none; + } + .mktoForm .mktoFieldWrap { + float: none; + } + .mktoForm fieldset { + padding: 0 10px; + } + .mktoForm input[type=url], + .mktoForm input[type=text], + .mktoForm input[type=date], + .mktoForm input[type=tel], + .mktoForm input[type=email], + .mktoForm input[type=number], + .mktoForm textarea.mktoField, + .mktoForm select.mktoField { + width: 100%; + height: 1.5em; + line-height: 1.5em; + font-size: 18px; + } + .mktoForm select.mktoField { + height: auto; + } + .mktoForm .mktoFormRow .mktoField { + clear: left; + } + .mktoForm .mktoFormRow .mktoFormCol { + clear: both; + } + .mktoForm .mktoRadioList, + .mktoForm .mktoCheckboxList { + width: 100%; + } + .mktoForm .mktoFormRow .mktoRequiredField .mktoAsterix { + float: left; + padding-left: 0; + padding-right: 5px; + } + .mktoModal .mktoModalContent { + padding: 10px 0; + } + .mktoModal .mktoModalClose { + right: 0; + } + .mktoForm .cf_widget_socialsignon { + display: block; + } + .mktoForm .cf_widget_socialsignon .cf_sign_on { + width: 100%; + } + .mktoForm .cf_widget_socialsignon .cf_sign_on_button { + width: auto; + } +} +@media only screen and (max-width: 480px), only screen and (max-device-width: 480px), only screen and (max-device-height: 480px) { + .mktoMobileShow .mktoForm, + .mktoForm * { + -webkit-box-sizing: border-box; + -moz-box-sizing: border-box; + box-sizing: border-box; + -moz-box-sizing: border-box; + padding: 10px; + } + .mktoMobileShow .mktoForm .mktoGutter, + .mktoMobileShow .mktoForm .mktoOffset { + display: none; + } + .mktoMobileShow .mktoForm .mktoFormCol .mktoLabel { + text-align: left; + width: 100%; + } + .mktoMobileShow .mktoForm .mktoFormCol { + float: none; + } + .mktoMobileShow .mktoForm .mktoFieldWrap { + float: none; + } + .mktoMobileShow .mktoForm fieldset { + padding: 0 10px; + } + .mktoMobileShow .mktoForm input[type=url], + .mktoMobileShow .mktoForm input[type=text], + .mktoMobileShow .mktoForm input[type=date], + .mktoMobileShow .mktoForm input[type=tel], + .mktoMobileShow .mktoForm input[type=email], + .mktoMobileShow .mktoForm input[type=number], + .mktoMobileShow .mktoForm textarea.mktoField, + .mktoMobileShow .mktoForm select.mktoField { + width: 100%; + height: 1.5em; + line-height: 1.5em; + font-size: 18px; + } + .mktoMobileShow .mktoForm select.mktoField { + height: auto; + } + .mktoMobileShow .mktoForm .mktoFormRow .mktoField { + clear: left; + } + .mktoMobileShow .mktoForm .mktoFormRow .mktoFormCol { + clear: both; + } + .mktoMobileShow .mktoForm .mktoRadioList, + .mktoMobileShow .mktoForm .mktoCheckboxList { + width: 100%; + } + .mktoMobileShow .mktoForm .mktoFormRow .mktoRequiredField .mktoAsterix { + float: left; + padding-left: 0; + padding-right: 5px; + } + .mktoMobileShow .mktoModal .mktoModalContent { + padding: 10px 0; + } + .mktoMobileShow .mktoModal .mktoModalClose { + right: 0; + } + .mktoMobileShow .mktoForm .cf_widget_socialsignon { + display: block; + } + .mktoMobileShow .mktoForm .cf_widget_socialsignon .cf_sign_on { + width: 100%; + } + .mktoMobileShow .mktoForm .cf_widget_socialsignon .cf_sign_on_button { + width: auto; + } +} diff --git a/Webseiten/Docker - Build, Ship, and Run Any App, Anywhere_files/forms2.min.js b/Webseiten/Docker - Build, Ship, and Run Any App, Anywhere_files/forms2.min.js new file mode 100644 index 0000000..8a6160e --- /dev/null +++ b/Webseiten/Docker - Build, Ship, and Run Any App, Anywhere_files/forms2.min.js @@ -0,0 +1,7 @@ +/*! forms2 2016-03-08 See forms2.js for license info */ +!function a(b,c,d){function e(g,h){if(!c[g]){if(!b[g]){var i="function"==typeof require&&require;if(!h&&i)return i(g,!0);if(f)return f(g,!0);var j=new Error("Cannot find module '"+g+"'");throw j.code="MODULE_NOT_FOUND",j}var k=c[g]={exports:{}};b[g][0].call(k.exports,function(a){var c=b[g][1][a];return e(c?c:a)},k,k.exports,a,b,c,d)}return c[g].exports}for(var f="function"==typeof require&&require,g=0;ga||isNaN(a))throw TypeError("n must be a positive number");return this._maxListeners=a,this},c.prototype.emit=function(a){var b,c,e,h,i,j;if(this._events||(this._events={}),"error"===a&&(!this._events.error||f(this._events.error)&&!this._events.error.length)){if(b=arguments[1],b instanceof Error)throw b;throw TypeError('Uncaught, unspecified "error" event.')}if(c=this._events[a],g(c))return!1;if(d(c))switch(arguments.length){case 1:c.call(this);break;case 2:c.call(this,arguments[1]);break;case 3:c.call(this,arguments[1],arguments[2]);break;default:for(e=arguments.length,h=new Array(e-1),i=1;e>i;i++)h[i-1]=arguments[i];c.apply(this,h)}else if(f(c)){for(e=arguments.length,h=new Array(e-1),i=1;e>i;i++)h[i-1]=arguments[i];for(j=c.slice(),e=j.length,i=0;e>i;i++)j[i].apply(this,h)}return!0},c.prototype.addListener=function(a,b){var e;if(!d(b))throw TypeError("listener must be a function");if(this._events||(this._events={}),this._events.newListener&&this.emit("newListener",a,d(b.listener)?b.listener:b),this._events[a]?f(this._events[a])?this._events[a].push(b):this._events[a]=[this._events[a],b]:this._events[a]=b,f(this._events[a])&&!this._events[a].warned){var e;e=g(this._maxListeners)?c.defaultMaxListeners:this._maxListeners,e&&e>0&&this._events[a].length>e&&(this._events[a].warned=!0,console.error("(node) warning: possible EventEmitter memory leak detected. %d listeners added. Use emitter.setMaxListeners() to increase limit.",this._events[a].length),"function"==typeof console.trace&&console.trace())}return this},c.prototype.on=c.prototype.addListener,c.prototype.once=function(a,b){function c(){this.removeListener(a,c),e||(e=!0,b.apply(this,arguments))}if(!d(b))throw TypeError("listener must be a function");var e=!1;return c.listener=b,this.on(a,c),this},c.prototype.removeListener=function(a,b){var c,e,g,h;if(!d(b))throw TypeError("listener must be a function");if(!this._events||!this._events[a])return this;if(c=this._events[a],g=c.length,e=-1,c===b||d(c.listener)&&c.listener===b)delete this._events[a],this._events.removeListener&&this.emit("removeListener",a,b);else if(f(c)){for(h=g;h-->0;)if(c[h]===b||c[h].listener&&c[h].listener===b){e=h;break}if(0>e)return this;1===c.length?(c.length=0,delete this._events[a]):c.splice(e,1),this._events.removeListener&&this.emit("removeListener",a,b)}return this},c.prototype.removeAllListeners=function(a){var b,c;if(!this._events)return this;if(!this._events.removeListener)return 0===arguments.length?this._events={}:this._events[a]&&delete this._events[a],this;if(0===arguments.length){for(b in this._events)"removeListener"!==b&&this.removeAllListeners(b);return this.removeAllListeners("removeListener"),this._events={},this}if(c=this._events[a],d(c))this.removeListener(a,c);else for(;c.length;)this.removeListener(a,c[c.length-1]);return delete this._events[a],this},c.prototype.listeners=function(a){var b;return b=this._events&&this._events[a]?d(this._events[a])?[this._events[a]]:this._events[a].slice():[]},c.listenerCount=function(a,b){var c;return c=a._events&&a._events[b]?d(a._events[b])?1:a._events[b].length:0}},{}],2:[function(a,b,c){(function(a){!function(d){function e(a){throw RangeError(H[a])}function f(a,b){for(var c=a.length;c--;)a[c]=b(a[c]);return a}function g(a,b){return f(a.split(G),b).join(".")}function h(a){for(var b,c,d=[],e=0,f=a.length;f>e;)b=a.charCodeAt(e++),b>=55296&&56319>=b&&f>e?(c=a.charCodeAt(e++),56320==(64512&c)?d.push(((1023&b)<<10)+(1023&c)+65536):(d.push(b),e--)):d.push(b);return d}function i(a){return f(a,function(a){var b="";return a>65535&&(a-=65536,b+=K(a>>>10&1023|55296),a=56320|1023&a),b+=K(a)}).join("")}function j(a){return 10>a-48?a-22:26>a-65?a-65:26>a-97?a-97:w}function k(a,b){return a+22+75*(26>a)-((0!=b)<<5)}function l(a,b,c){var d=0;for(a=c?J(a/A):a>>1,a+=J(a/b);a>I*y>>1;d+=w)a=J(a/I);return J(d+(I+1)*a/(a+z))}function m(a){var b,c,d,f,g,h,k,m,n,o,p=[],q=a.length,r=0,s=C,t=B;for(c=a.lastIndexOf(D),0>c&&(c=0),d=0;c>d;++d)a.charCodeAt(d)>=128&&e("not-basic"),p.push(a.charCodeAt(d));for(f=c>0?c+1:0;q>f;){for(g=r,h=1,k=w;f>=q&&e("invalid-input"),m=j(a.charCodeAt(f++)),(m>=w||m>J((v-r)/h))&&e("overflow"),r+=m*h,n=t>=k?x:k>=t+y?y:k-t,!(n>m);k+=w)o=w-n,h>J(v/o)&&e("overflow"),h*=o;b=p.length+1,t=l(r-g,b,0==g),J(r/b)>v-s&&e("overflow"),s+=J(r/b),r%=b,p.splice(r++,0,s)}return i(p)}function n(a){var b,c,d,f,g,i,j,m,n,o,p,q,r,s,t,u=[];for(a=h(a),q=a.length,b=C,c=0,g=B,i=0;q>i;++i)p=a[i],128>p&&u.push(K(p));for(d=f=u.length,f&&u.push(D);q>d;){for(j=v,i=0;q>i;++i)p=a[i],p>=b&&j>p&&(j=p);for(r=d+1,j-b>J((v-c)/r)&&e("overflow"),c+=(j-b)*r,b=j,i=0;q>i;++i)if(p=a[i],b>p&&++c>v&&e("overflow"),p==b){for(m=c,n=w;o=g>=n?x:n>=g+y?y:n-g,!(o>m);n+=w)t=m-o,s=w-o,u.push(K(k(o+t%s,0))),m=J(t/s);u.push(K(k(m,0))),g=l(c,r,d==f),c=0,++d}++c,++b}return u.join("")}function o(a){return g(a,function(a){return E.test(a)?m(a.slice(4).toLowerCase()):a})}function p(a){return g(a,function(a){return F.test(a)?"xn--"+n(a):a})}var q="object"==typeof c&&c,r="object"==typeof b&&b&&b.exports==q&&b,s="object"==typeof a&&a;(s.global===s||s.window===s)&&(d=s);var t,u,v=2147483647,w=36,x=1,y=26,z=38,A=700,B=72,C=128,D="-",E=/^xn--/,F=/[^ -~]/,G=/\x2E|\u3002|\uFF0E|\uFF61/g,H={overflow:"Overflow: input needs wider integers to process","not-basic":"Illegal input >= 0x80 (not a basic code point)","invalid-input":"Invalid input"},I=w-x,J=Math.floor,K=String.fromCharCode;if(t={version:"1.2.4",ucs2:{decode:h,encode:i},decode:m,encode:n,toASCII:p,toUnicode:o},"function"==typeof define&&"object"==typeof define.amd&&define.amd)define("punycode",function(){return t});else if(q&&!q.nodeType)if(r)r.exports=t;else for(u in t)t.hasOwnProperty(u)&&(q[u]=t[u]);else d.punycode=t}(this)}).call(this,"undefined"!=typeof global?global:"undefined"!=typeof self?self:"undefined"!=typeof window?window:{})},{}],3:[function(a,b){"use strict";function c(a,b){return Object.prototype.hasOwnProperty.call(a,b)}b.exports=function(a,b,e,f){b=b||"&",e=e||"=";var g={};if("string"!=typeof a||0===a.length)return g;var h=/\+/g;a=a.split(b);var i=1e3;f&&"number"==typeof f.maxKeys&&(i=f.maxKeys);var j=a.length;i>0&&j>i&&(j=i);for(var k=0;j>k;++k){var l,m,n,o,p=a[k].replace(h,"%20"),q=p.indexOf(e);q>=0?(l=p.substr(0,q),m=p.substr(q+1)):(l=p,m=""),n=decodeURIComponent(l),o=decodeURIComponent(m),c(g,n)?d(g[n])?g[n].push(o):g[n]=[g[n],o]:g[n]=o}return g};var d=Array.isArray||function(a){return"[object Array]"===Object.prototype.toString.call(a)}},{}],4:[function(a,b){"use strict";function c(a,b){if(a.map)return a.map(b);for(var c=[],d=0;d",'"',"`"," ","\r","\n"," "],q=["{","}","|","\\","^","`"].concat(p),r=["'"].concat(q),s=["%","/","?",";","#"].concat(r),t=["/","?","#"],u=255,v=/^[a-z0-9A-Z_-]{0,63}$/,w=/^([a-z0-9A-Z_-]{0,63})(.*)$/,x={javascript:!0,"javascript:":!0},y={javascript:!0,"javascript:":!0},z={http:!0,https:!0,ftp:!0,gopher:!0,file:!0,"http:":!0,"https:":!0,"ftp:":!0,"gopher:":!0,"file:":!0},A=a("querystring");d.prototype.parse=function(a,b,c){if(!i(a))throw new TypeError("Parameter 'url' must be a string, not "+typeof a);var d=a;d=d.trim();var e=n.exec(d);if(e){e=e[0];var f=e.toLowerCase();this.protocol=f,d=d.substr(e.length)}if(c||e||d.match(/^\/\/[^@\/]+@[^@\/]+/)){var g="//"===d.substr(0,2);!g||e&&y[e]||(d=d.substr(2),this.slashes=!0)}if(!y[e]&&(g||e&&!z[e])){for(var h=-1,j=0;jk)&&(h=k)}var l,o;o=-1===h?d.lastIndexOf("@"):d.lastIndexOf("@",h),-1!==o&&(l=d.slice(0,o),d=d.slice(o+1),this.auth=decodeURIComponent(l)),h=-1;for(var j=0;jk)&&(h=k)}-1===h&&(h=d.length),this.host=d.slice(0,h),d=d.slice(h),this.parseHost(),this.hostname=this.hostname||"";var p="["===this.hostname[0]&&"]"===this.hostname[this.hostname.length-1];if(!p)for(var q=this.hostname.split(/\./),j=0,B=q.length;B>j;j++){var C=q[j];if(C&&!C.match(v)){for(var D="",E=0,F=C.length;F>E;E++)D+=C.charCodeAt(E)>127?"x":C[E];if(!D.match(v)){var G=q.slice(0,j),H=q.slice(j+1),I=C.match(w);I&&(G.push(I[1]),H.unshift(I[2])),H.length&&(d="/"+H.join(".")+d),this.hostname=G.join(".");break}}}if(this.hostname=this.hostname.length>u?"":this.hostname.toLowerCase(),!p){for(var J=this.hostname.split("."),K=[],j=0;jj;j++){var O=r[j],P=encodeURIComponent(O);P===O&&(P=escape(O)),d=d.split(O).join(P)}var Q=d.indexOf("#");-1!==Q&&(this.hash=d.substr(Q),d=d.slice(0,Q));var R=d.indexOf("?");if(-1!==R?(this.search=d.substr(R),this.query=d.substr(R+1),b&&(this.query=A.parse(this.query)),d=d.slice(0,R)):b&&(this.search="",this.query={}),d&&(this.pathname=d),z[f]&&this.hostname&&!this.pathname&&(this.pathname="/"),this.pathname||this.search){var M=this.pathname||"",L=this.search||"";this.path=M+L}return this.href=this.format(),this},d.prototype.format=function(){var a=this.auth||"";a&&(a=encodeURIComponent(a),a=a.replace(/%3A/i,":"),a+="@");var b=this.protocol||"",c=this.pathname||"",d=this.hash||"",e=!1,f="";this.host?e=a+this.host:this.hostname&&(e=a+(-1===this.hostname.indexOf(":")?this.hostname:"["+this.hostname+"]"),this.port&&(e+=":"+this.port)),this.query&&j(this.query)&&Object.keys(this.query).length&&(f=A.stringify(this.query));var g=this.search||f&&"?"+f||"";return b&&":"!==b.substr(-1)&&(b+=":"),this.slashes||(!b||z[b])&&e!==!1?(e="//"+(e||""),c&&"/"!==c.charAt(0)&&(c="/"+c)):e||(e=""),d&&"#"!==d.charAt(0)&&(d="#"+d),g&&"?"!==g.charAt(0)&&(g="?"+g),c=c.replace(/[?#]/g,function(a){return encodeURIComponent(a)}),g=g.replace("#","%23"),b+e+c+g+d},d.prototype.resolve=function(a){return this.resolveObject(e(a,!1,!0)).format()},d.prototype.resolveObject=function(a){if(i(a)){var b=new d;b.parse(a,!1,!0),a=b}var c=new d;if(Object.keys(this).forEach(function(a){c[a]=this[a]},this),c.hash=a.hash,""===a.href)return c.href=c.format(),c;if(a.slashes&&!a.protocol)return Object.keys(a).forEach(function(b){"protocol"!==b&&(c[b]=a[b])}),z[c.protocol]&&c.hostname&&!c.pathname&&(c.path=c.pathname="/"),c.href=c.format(),c;if(a.protocol&&a.protocol!==c.protocol){if(!z[a.protocol])return Object.keys(a).forEach(function(b){c[b]=a[b]}),c.href=c.format(),c;if(c.protocol=a.protocol,a.host||y[a.protocol])c.pathname=a.pathname;else{for(var e=(a.pathname||"").split("/");e.length&&!(a.host=e.shift()););a.host||(a.host=""),a.hostname||(a.hostname=""),""!==e[0]&&e.unshift(""),e.length<2&&e.unshift(""),c.pathname=e.join("/")}if(c.search=a.search,c.query=a.query,c.host=a.host||"",c.auth=a.auth,c.hostname=a.hostname||a.host,c.port=a.port,c.pathname||c.search){var f=c.pathname||"",g=c.search||"";c.path=f+g}return c.slashes=c.slashes||a.slashes,c.href=c.format(),c}var h=c.pathname&&"/"===c.pathname.charAt(0),j=a.host||a.pathname&&"/"===a.pathname.charAt(0),m=j||h||c.host&&a.pathname,n=m,o=c.pathname&&c.pathname.split("/")||[],e=a.pathname&&a.pathname.split("/")||[],p=c.protocol&&!z[c.protocol];if(p&&(c.hostname="",c.port=null,c.host&&(""===o[0]?o[0]=c.host:o.unshift(c.host)),c.host="",a.protocol&&(a.hostname=null,a.port=null,a.host&&(""===e[0]?e[0]=a.host:e.unshift(a.host)),a.host=null),m=m&&(""===e[0]||""===o[0])),j)c.host=a.host||""===a.host?a.host:c.host,c.hostname=a.hostname||""===a.hostname?a.hostname:c.hostname,c.search=a.search,c.query=a.query,o=e;else if(e.length)o||(o=[]),o.pop(),o=o.concat(e),c.search=a.search,c.query=a.query;else if(!l(a.search)){if(p){c.hostname=c.host=o.shift();var q=c.host&&c.host.indexOf("@")>0?c.host.split("@"):!1;q&&(c.auth=q.shift(),c.host=c.hostname=q.shift())}return c.search=a.search,c.query=a.query,k(c.pathname)&&k(c.search)||(c.path=(c.pathname?c.pathname:"")+(c.search?c.search:"")),c.href=c.format(),c}if(!o.length)return c.pathname=null,c.path=c.search?"/"+c.search:null,c.href=c.format(),c;for(var r=o.slice(-1)[0],s=(c.host||a.host)&&("."===r||".."===r)||""===r,t=0,u=o.length;u>=0;u--)r=o[u],"."==r?o.splice(u,1):".."===r?(o.splice(u,1),t++):t&&(o.splice(u,1),t--);if(!m&&!n)for(;t--;t)o.unshift("..");!m||""===o[0]||o[0]&&"/"===o[0].charAt(0)||o.unshift(""),s&&"/"!==o.join("/").substr(-1)&&o.push("");var v=""===o[0]||o[0]&&"/"===o[0].charAt(0);if(p){c.hostname=c.host=v?"":o.length?o.shift():"";var q=c.host&&c.host.indexOf("@")>0?c.host.split("@"):!1;q&&(c.auth=q.shift(),c.host=c.hostname=q.shift())}return m=m||c.host&&o.length,m&&!v&&o.unshift(""),o.length?c.pathname=o.join("/"):(c.pathname=null,c.path=null),k(c.pathname)&&k(c.search)||(c.path=(c.pathname?c.pathname:"")+(c.search?c.search:"")),c.auth=a.auth||c.auth,c.slashes=c.slashes||a.slashes,c.href=c.format(),c},d.prototype.parseHost=function(){var a=this.host,b=o.exec(a);b&&(b=b[0],":"!==b&&(this.port=b.substr(1)),a=a.substr(0,a.length-b.length)),a&&(this.hostname=a)}},{punycode:2,querystring:5}],7:[function(a,b){var c=function(a,b,c){c=c||{};var d=c.encode||g,e=[a+"="+d(b)];return c.maxAge&&e.push("Max-Age="+c.maxAge),c.domain&&e.push("Domain="+c.domain),c.path&&e.push("Path="+c.path),c.expires&&e.push("Expires="+c.expires.toUTCString()),c.httpOnly&&e.push("HttpOnly"),c.secure&&e.push("Secure"),e.join("; ")},d=/^[\s\uFEFF\xA0]+|[\s\uFEFF\xA0]+$/g,e=function(a){return a.trim?a.trim():a.replace(d,"")},f=function(a,b){b=b||{};for(var c={},d=a.split(/[;,] */),f=b.decode||h,g=d.length,i=0;g>i;i++){var j=d[i],k=j.indexOf("=");if(!(0>k)){var l=e(j.substr(0,k)),m=e(j.substr(++k,j.length));if('"'==m[0]&&(m=m.slice(1,-1)),void 0==c[l])try{c[l]=f(m)}catch(n){c[l]=m}}}return c},g=encodeURIComponent,h=decodeURIComponent;b.exports.serialize=c,b.exports.parse=f},{}],8:[function(a,b){b.exports=a("./jquery.build.js")},{"./jquery.build.js":9}],9:[function(a,b){!function(){var a=function(a,b){var c=!0;try{var d=b.createElement("button");d.type="button"}catch(e){c=!1}var f=b.createElement("style");f.type="text/css";var g=f.styleSheet&&"cssText"in f.styleSheet,h=b.createElement("div");h.innerHTML=" s ";var i=h.childNodes[0].nodeValue,j=0!=i.indexOf(" "),k=2!=i.lastIndexOf(" "),l=/'/g,m=/^((?:[\w\u00c0-\uFFFF\*_-]|\\.)+)/,n=/#((?:[\w\u00c0-\uFFFF_-]|\\.)+)/,o=/\.((?:[\w\u00c0-\uFFFF_-]|\\.)+)/g,p=/\[\s*((?:[\w\u00c0-\uFFFF_-]|\\.)+)\s*(?:(\S?=)\s*(['"]*)(.*?)\3|)\s*\]/g,q=/[\[\]]/g,r=function(a,c){j&&" "===c.charAt(0)&&a.appendChild(b.createTextNode(" ")),a.appendChild(b.createTextNode(c)),k&&" "===c.charAt(c.length-1)&&a.appendChild(b.createTextNode(" "))},s=function(b,c){if(c)if(c.jquery)b.appendChild(c.get(0));else if(1==c.nodeType||3==c.nodeType||11==c.nodeType)b.appendChild(c);else if(a.isArray(c)){var d=0,e=c.length;for(d=0;e>d;d++)s(b,c[d])}else r(b,c.toString())},t=function(c){var d=b.createDocumentFragment();if(c)if(a.isArray(c)){var e=0,f=c.length;for(e=0;f>e;e++)s(d,c[e])}else s(d,c);return d},u=function(a){var c=b.createDocumentFragment();if(a)if("undefined"!=typeof c.innerHTML)c.innerHTML=a;else{var d=b.createElement("div");for(d.innerHTML=a.replace(l,"'"),j&&0==a.indexOf(" ")&&c.appendChild(b.createTextNode(" "));d.hasChildNodes();)c.appendChild(d.firstChild);k&&a.lastIndexOf(" ")==a.length-1&&c.appendChild(b.createTextNode(" "))}return c};return a.build=function(d,e,f){2==arguments.length&&null!=e&&("string"==typeof e||a.isArray(e)||e.nodeType||e.jquery)&&(f=e,e=null),d=d||"";var h;h=d.match(m),h&&(h=h[0]);var i=null;if(-1!=d.indexOf("#")){var i=d.match(n);i=i?i[1]:null}var j;-1!=d.indexOf(".")&&(j=d.match(o));var k;-1!=d.indexOf("[")&&(k=d.match(p)),h=h||"div",k&&(e=e||{},a.each(k,function(a,b){var c=b.replace(q,"").split("=");c&&2==c.length&&(e[c[0]]=c[1])})),e=e||{};var l;if(c||"input"!==h&&"button"!==h)l=b.createElement(h);else{var r=e.type?'type="'+e.type+'"':"",s=e.name?'name="'+e.name+'"':"";l=b.createElement("<"+h+" "+r+" "+s+">"),delete e.type,delete e.name}var u=a(l);if(e&&u.attr(e),i&&(l.id=i),"img"===h&&(e.width||u.removeAttr("width"),e.height||u.removeAttr("height")),j){var v="";a.each(j,function(a,b){v+=b.replace(".","")+" "}),l.className=a.trim(l.className+" "+v)}return g&&"style"==h&&"string"==typeof f?(u.attr("type")||u.attr("type","text/css"),l.styleSheet.cssText=f):f&&l.appendChild(11==f.nodeType?f:t(f)),u},a.build.docFrag=t,a.build.html=u,a.build};"undefined"!=typeof b&&b.exports&&(b.exports=a),"undefined"!=typeof window&&window.jQuery&&window.document&&a(window.jQuery,window.document)}()},{}],10:[function(a,b){function c(a,b){var c={};return g.each(a,function(a,d){if("hidden"!=d.Datatype&&"profiling"!=d.Datatype){var e=d.VisibilityRule;if(e){if("fieldset"==d.Datatype){var f=i.flatten(b.fieldsetRows[""+d.Id]),h=c[d.Name];h||(h=[]),h=h.concat(g.map(f,function(a){return a.Name})),c[d.Name]=h}var j=e.rules||[e];g.each(j,function(a,b){if("string"!=typeof b){var e=c[b.subjectField];e||(e=[]),-1===g.inArray(d.Name,e)&&e.push(d.Name),c[b.subjectField]=e}})}}}),c}function d(a,b){for(var c=a.length,d=0;c>d;d++){var e=a[d];if(b(e))return e}return void 0}function e(a,b){if(b&&(a.PicklistValues||b.picklistKeys||b.altLabel)){if(a=g.extend(!0,{},a),a.PicklistValues)if(b.picklistFilterValues){var c={};g.each(b.picklistFilterValues,function(a,b){c.hasOwnProperty(b.value)||(c[b.value]=[]),c[b.value].push(b.label)}),a.PicklistValues=g.map(a.PicklistValues,function(a){return c.hasOwnProperty(a.value)&&-1!=g.inArray(a.label,c[a.value])?a:void 0})}else b.picklistKeys&&(a.PicklistValues=g.map(a.PicklistValues,function(a){return-1!=g.inArray(a.value,b.picklistKeys)?a:void 0}));b.altLabel&&(a.InputLabel=b.altLabel)}return a}function f(a,b){if(!a)return{show:!0};var c="show"==a.defaultVisibility,e=a.rules||[a],f=g.map(e,function(a){if("string"!=typeof a){var c=b[a.subjectField];g.isArray(c)||(c=c?[c]:[]);var d=h[a.operator],e=d(c,a.values);return e?a:null}}),i=d(f,function(a){return null!==a});return c?{show:!i,rule:i}:{show:!!i,rule:i}}var g=a("./jquery.js"),h=a("./comparators.js"),i=a("./fields/fieldhelpers.js");b.exports={getChangeMap:c,fieldChangeChecker:f,applyPicklistAlterations:e}},{"./comparators.js":12,"./fields/fieldhelpers.js":16,"./jquery.js":31}],11:[function(a,b){function c(a){var b,c=parseInt;return a=(a||"").replace(/\s\s*/g,""),(b=/^#([\da-f]{2})([\da-f]{2})([\da-f]{2})/i.exec(a))?[c(b[1],16),c(b[2],16),c(b[3],16),1]:(b=/^#([\da-f])([\da-f])([\da-f])/i.exec(a))?[17*c(b[1],16),17*c(b[2],16),17*c(b[3],16),1]:(b=/^rgba\(([\d]+),([\d]+),([\d]+),([\d]+|[\d]*.[\d]+)\)/i.exec(a))?[+b[1],+b[2],+b[3],+b[4]]:(b=/^rgb\(([\d]+),([\d]+),([\d]+)\)/i.exec(a))?[+b[1],+b[2],+b[3],1]:null}function d(a,b){var d=c(a),e=c(b);if(!d||!e)return!1;for(var f=0;4>f;f++)if(d[f]!==e[f])return!1;return!0}b.exports={parseColor:c,compareColor:d}},{}],12:[function(a,b){var c=function(a,b,c){for(var d=[],e=0;e0},notEqual:function(a,b){var d=function(a,b){return a===b};return 0===c(a,b,d).length},empty:function(a){return 0===a.length},notEmpty:function(a){return a.length>0},any:function(a){return a.length>0},startsWith:function(a,b){var d=function(a,b){return 0===a.indexOf(b)};return c(a,b,d).length>0},notStartsWith:function(a,b){var d=function(a,b){return 0===a.indexOf(b)};return 0===c(a,b,d).length},endsWith:function(a,b){var d=function(a,b){return a.lastIndexOf(b)===a.length-b.length};return c(a,b,d).length>0},notEndsWith:function(a,b){var d=function(a,b){return a.lastIndexOf(b)===a.length-b.length};return 0===c(a,b,d).length},contains:function(a,b){var d=function(a,b){return a.match(new RegExp(b,"g"))};return c(a,b,d).length>0},notContains:function(a,b){var d=function(a,b){return a.match(new RegExp(b,"g"))};return 0===c(a,b,d).length},atLeast:function(a,b){return a[0]>=b[0]},atMost:function(a,b){return a[0]<=b[0]},greaterThan:function(a,b){return a[0]>b[0]},lessThan:function(a,b){return a[0]b[0]&&a[0]b[1]},inTimeFrame:function(a,b){return new Date(a[0])>new Date(b[0])&&new Date(a[0])new Date(b[1])},inPast:function(a){return new Date(a[0])=new Date},before:function(a,b){return new Date(a[0])new Date(b[0])},onOrBefore:function(a,b){return new Date(a[0])<=new Date(b[0])},onOrAfter:function(a,b){return new Date(a[0])>=new Date(b[0])}};b.exports=d},{}],13:[function(a,b){function c(a,b){b=b||location.hostname;var c=new Date;c.setFullYear(c.getFullYear()-1);var e=[];document.cookie=d.serialize(a,"",{expires:c,path:"/"}),e.push("");for(var f=b.split(".");f.length>1;){var g="."+f.join(".");document.cookie=d.serialize(a,"",{expires:c,path:"/",domain:g}),e.push(g),f.shift()}return e}var d=a("cookie");b.exports.removeCookieAllDomains=c},{cookie:7}],14:[function(a,b){var c=a("../jquery.js"),d=(c.build,a("./fieldHelpers.js")),e={};b.exports=e,e.fieldType="currency";var f=/[0-9]+/g,g=function(a){return a?a.match(f):!0};e.newField=function(a,b){var e=d.renderInput("text",a,b);return{name:a.Name,elem:d.formatStandardField(e,a,b),val:c.proxy(e.val,e),required:a.IsRequired,validator:g,validatorElem:e,onChange:function(a){e.on("change",a)}}}},{"../jquery.js":31,"./fieldHelpers.js":15}],15:[function(a,b){var c=a("../jquery.js"),d=c.build,e={};e.splitSemis=function(a){return a=""+a,a.split(/\s?;\s?/)},e.cap=function(a){return a.charAt(0).toUpperCase()+a.slice(1)},e.first=function(){for(var a=0;aa?!1:g.isSet(c)&&a>c?!1:!0)}function e(a){return function(b){if(0===arguments.length){var c=a.val();if(g.isSet(c)){var d=parseFloat(c);return isNaN(d)?"":d}return null}a.val(b)}}var f=a("../jquery.js"),g=(f.build,a("./fieldHelpers.js")),f=a("../jquery.js"),g=(f.build,a("./fieldHelpers.js")),h={};b.exports=h,h.fieldType="number",h.newField=function(a,b){{var f=g.renderInput("number",a,b);f.attr({min:c(a.MinimumNumber),max:c(a.MaximumNumber),step:c(a.StepNumber)})}return{name:a.Name,val:e(f,a.MinimumNumber,a.MaximumNumber),elem:g.formatStandardField(f,a,b),required:a.IsRequired,validator:function(b){return d(b,a.MinimumNumber,a.MaximumNumber)},validatorElem:f,onChange:function(a){f.on("change",a)}}}},{"../jquery.js":31,"./fieldHelpers.js":15}],21:[function(a,b){var c=a("../jquery.js"),d=c.build,e=a("./fieldHelpers.js"),f={};b.exports=f,f.fieldType="radio";var g=function(a){return function(b){if(0===arguments.length){var d=a.find("input:checked").val();return d}a.find("input").prop("checked",!1),""!==b?a.find("input[value='"+b+"']").prop("checked",!0):a.find("input").each(function(a,b){b=c(b),""===b.val()&&b.prop("checked",!0)})}};f.newField=function(a,b){var f=d(".mktoRadioList",{title:a.Description},[c.map(a.PicklistValues||[],function(b,c){var e="mktoRadio_"+a.Id+"_"+c;return c||(firstVal=b.value),d.docFrag([d("input[type=radio].mktoField",{name:a.Name,id:e,value:b.value}),d("label",{"for":e},[d.html(b.label||b.name)])])})]);a.IsLabelToLeft&&f.addClass("mktoLabelToLeft");var h=g(f);return{name:a.Name,elem:e.formatStandardField(f,a,b),val:h,required:a.IsRequired,validatorElem:f,validatorFocusElem:f.find("input:eq(0)"),onChange:function(a){f.on("change",a)}}}},{"../jquery.js":31,"./fieldHelpers.js":15}],22:[function(a,b){var c=a("../jquery.js"),d=c.build,e=a("./fieldHelpers.js"),f=a("../modernizr.js"),g={};b.exports=g,g.fieldType="range";var h=function(a,b,c){var d=a.get(0);if(d.validity&&!d.validity.valid)return!1;var e=a.val();return e?i(e,b,c):!0},i=function(a,b,c){return a=parseFloat(a,10),isNaN(a)?!1:e.isSet(b)&&b>a?!1:e.isSet(c)&&a>c?!1:!0},j=function(a,b,c){return function(d){if(0===arguments.length){var f=a.val();if(e.isSet(f)){var g=parseFloat(f,10);return isNaN(g)?null:g}return null}null!==d&&void 0!==d&&""!==d&&i(d,b,c)&&(a.val(parseFloat(d,10)),a.trigger("change"))}};g.newField=function(a,b){var g,i,k,l,m=a.MinimumNumber||0,n=a.MaximumNumber||100,o=d(".mktoLogicalField.mktoRangeField",[k=d(".mktoRangeValue",[l=d(".mktoRangeValueArrowWrap",d(".mktoRangeValueArrow")),i=d(".mktoRangeValueText",""+a.MinimumNumber||0)]),g=d("input[type=range].mktoField",{id:a.Name,name:a.Name,min:m,max:n,step:a.StepNumber||1,title:a.Description}).addClass("mktoHasWidth").css({width:e.first(a.FieldWidth,b.FieldWidth,0)})]).hover(function(){o.addClass("mktoHover"),p()},function(){o.removeClass("mktoHover")});f.csstransforms||l.addClass("mktoArrowImage");var p=function(){var a=g.val()||0;i.html(""+a);var b=12,c=g.data("mktoNoCubicEase"),d=g.data("mktoPxAboveSlider")||0,e=(a-m)/(n-m),f=g.width()*e,h=0;c||(.5>e&&(h=Math.pow(1-e,3)*(b/2)),e>.5&&(h=-1*Math.pow(e,3)*(b/2)),f+=Math.floor(h));var j=f-k.outerWidth()/2,o=i.outerWidth()/2-l.outerWidth()/2;k.css("margin-left",j),k.css("margin-top",-1*(l.outerHeight()+i.outerHeight()+d)),l.css("margin-left",o)};return g.on("change",p),g.on("input",p),g.data("mktoRangeUpdate",p),c("body").on("mktoRender",p),{name:a.Name,val:j(g,a.MinimumNumber,a.MaximumNumber),elem:e.formatStandardField(o,a,b),required:a.IsRequired,validator:function(){return h(g,m,n) +},validatorElem:g,onChange:function(a){g.on("change",a)}}}},{"../jquery.js":31,"../modernizr.js":34,"./fieldHelpers.js":15}],23:[function(a,b){var c=a("../jquery.js"),d=(c.build,a("./fieldHelpers.js")),e=/^([0-9()+. \t-])+(\s?(x|ext|extension)\s?([0-9()])+)?$/,f={};b.exports=f,f.fieldType="phone";var g=function(a){var b=a.val()||"";return b?b.match(e):!0};f.newField=function(a,b){var e=d.renderInput("tel",a,b);return{name:a.Name,elem:d.formatStandardField(e,a,b),val:c.proxy(e.val,e),required:a.IsRequired,validator:function(){return g(e)},validatorElem:e,onChange:function(a){e.on("change",a)}}}},{"../jquery.js":31,"./fieldHelpers.js":15}],24:[function(a,b){var c=a("../jquery.js"),d=(c.build,a("./fieldHelpers.js")),e={};b.exports=e,e.fieldType="string",e.newField=function(a,b){var c=a.Maxlength||255,e=d.renderInput("text",a,b);return a.FieldMask&&e.addClass("mktoInputMask").data("mktoInputMask",a.FieldMask),{name:a.Name,elem:d.formatStandardField(e,a,b),val:function(a){return 0===arguments.length?e.val():(a&&a.length>c&&(a=a.substring(0,c)),e.val(a))},required:a.IsRequired,validatorElem:e,onChange:function(a){e.on("change",a)}}}},{"../jquery.js":31,"./fieldHelpers.js":15}],25:[function(a,b){var c=a("../jquery.js"),d=(c.build,a("./fieldHelpers.js")),e={};b.exports=e,e.fieldType="url";var f=/^[a-zA-z0-9\.\-_~:/\?#\[\]@!$&\'\(\)\*\+,;=%]*$/,g=function(a){if(!a)return!0;var b=a.indexOf("://");return 1>b?!1:a.match(f)};e.newField=function(a,b){var e=d.renderInput("url",a,b);return{name:a.Name,elem:d.formatStandardField(e,a,b),val:c.proxy(e.val,e),required:a.IsRequired,validatorElem:e,validator:g,onChange:function(a){e.on("change",a)}}}},{"../jquery.js":31,"./fieldHelpers.js":15}],26:[function(a,b){var c=a("../jquery.js"),d=c.build,e=a("./fieldHelpers.js"),f=function(a,b){return function(d){return 0===arguments.length?a.val():(b&&d&&!c.isArray(d)&&(d=e.splitSemis(d)),a.val(d))}},g={};b.exports=g,g.fieldType="picklist",g.newField=function(a,b){var g=d("select.mktoField",{id:a.Name,name:a.Name,title:a.Description},[c.map(a.PicklistValues||[],function(a){return!a.isDefault||a.selected?d("option",{value:a.value},a.label||a.name):void 0})]);return a.IsMultiselect&&(g.attr("multiple","multiple"),g.attr("size",a.VisibleRows||5)),{name:a.Name,elem:e.formatStandardField(g,a,b),val:f(g,a.IsMultiselect),required:a.IsRequired,validatorElem:g,onChange:function(a){g.on("change",a)}}}},{"../jquery.js":31,"./fieldHelpers.js":15}],27:[function(a,b){var c=a("../jquery.js"),d=c.build,e=a("./fieldHelpers.js"),f={};b.exports=f,f.fieldType="textarea",f.newField=function(a,b){var c=a.Maxlength||2e3,f=d("textarea.mktoField",{id:a.Name,name:a.Name,placeholder:a.PlaceholderText,rows:Math.max(2,a.VisibleRows||2),title:a.Description});try{f.attr("maxlength",c)}catch(g){f.get(0).setAttribute("maxlength",""+c)}return{name:a.Name,elem:e.formatStandardField(f,a,b),val:function(a){return 0===arguments.length?f.val():(a&&a.length>c&&(a=a.substring(0,c)),f.val(a))},required:a.IsRequired,validatorElem:f,onChange:function(a){f.on("change",a)}}}},{"../jquery.js":31,"./fieldHelpers.js":15}],28:[function(a,b){var c=a("./jquery.js"),d=c.build,e=a("./validation.js"),f=a("./measure.js"),g=a("./fields/fieldhelpers.js"),h=g.cap,i=g.isSet,j=g.first,k=a("querystring"),l=a("url"),m=a("cookie"),n=a("./cookiehelper.js"),o=a("./tokenTemplate.js"),p=a("./changeManager.js"),q=a("./urlhelper.js"),r=a("./prefillcoercer.js"),s=a("./iframeproxy.js"),t=a("./safelog.js"),u=[a("./fields/inputRadio.js"),a("./fields/inputDate.js"),a("./fields/inputEmail.js"),a("./fields/inputCheckbox.js"),a("./fields/select.js"),a("./fields/inputRange.js"),a("./fields/inputText.js"),a("./fields/inputUrl.js"),a("./fields/inputTel.js"),a("./fields/inputNumber.js"),a("./fields/textarea.js"),a("./fields/currency.js")],v={};c.each(u,function(a,b){v[b.fieldType]=b}),v["int"]=v.number,v["double"]=v.number,v.single_checkbox=v.checkbox;var w=(a("./comparators.js"),navigator.userAgent.match(/msie ([6789])/i)),x=w?"ie"+w[1]:"",y=function(a,b,u){var w={},y={};y.hiddenFields={formid:a.Id},y.onSuccess=[],y.onSubmit=[],y.onValidate=[],y.values={},y.fieldsByName=g.getFieldsByName(g.getFlattenedFields(a)),y.changeMap=p.getChangeMap(y.fieldsByName,a),y.fieldElemsByName={},y.canSubmit="draft"!=a.Status;var z=function(a){var b=y.changeMap[a]||[],e=!1,f={defaultValuesToSet:{},fieldsToCheck:[]};c.each(b,function(a,b){var g=y.fieldElemsByName[b];if(g&&g[0]&&c.contains(y.formElem[0],g[0])){var h,i,j=!g.hasClass("mktoPlaceholder"),k=y.fieldsByName[b],l=p.fieldChangeChecker(k.VisibilityRule,w.getValues()),m=l.show,n=function(a,b){var c=A(a,f),d=C(c),e=d.elem;return e.hide(),b.replaceWith(e),G()&&H(e),e},o=function(a,b){var c=d(".mktoPlaceholder.mktoPlaceholder"+a.Name);return b.replaceWith(c),c};j&&m&&(h=p.applyPicklistAlterations(k,l.rule),h!==k&&(i=n(h,g),i.show(),e=!0)),j&&!m&&(i=o(k,g),y.fieldElemsByName[b]=i,f.fieldsToCheck.push(k)),!j&&m&&(h=p.applyPicklistAlterations(k,l.rule),i=n(h,g),i.show(),f.fieldsToCheck.push(k),e=!0),i&&(y.fieldElemsByName[b]=i),"fieldset"==k.Datatype&&z(k.Name),e&&i&&y.validation&&y.validation.initScoped(i)}}),w.setValues(f.defaultValuesToSet),c.each(f.fieldsToCheck,function(a,b){z(b.Name)}),e&&c("body").data("mktoRendered")&&c("body").trigger("mktoRender",w)},A=function(b,e){var f=y.values[b.Name]||b.DefaultValue||b.InputInitialValue;if(v[b.Datatype]){var g=v[b.Datatype].newField(b,a);if(g.validationMessage=g.validationMessage||b.ValidationMessage,g.requiredMessage=g.requiredMessage||b.RequiredMessage,g.required){if(!g.validatorElem)throw new Error("Required fields must have a validatorElem");g.validatorElem.addClass("mktoRequired")}y.changeMap[b.Name]&&g.onChange(function(){z(b.Name)}),i(f)&&(e.defaultValuesToSet[b.Name]=f);var h=d(".mktoFieldDescriptor",g.elem);return h.data("mktoFieldDescriptor",g),h}if("htmltext"==b.Datatype||"richtext"==b.Datatype)return d.docFrag([d(".mktoOffset.mktoHasWidth").css({width:j(b.OffsetWidth,a.OffsetWidth,0)}),d(".mktoFieldWrap",[d(".mktoHtmlText.mktoHasWidth",[d.html(b.Htmltext||b.InputLabel)]).css({width:j(b.LabelWidth,a.LabelWidth,0)}),d(".mktoClear")]),d(".mktoClear")]);if("hidden"==b.Datatype){var n=b.InputSourceChannel,o=b.InputSourceSelector,p=b.Name,q="";if("url"==n&&o){var r=k.parse(location.search.replace("?",""));q=r[o]||""}else if("cookie"==n&&o){var s=m.parse(document.cookie);q=s[o]}else if("referrer"==n&&o){var u=l.parse(document.referrer,!0);q=u.query[o]}return!q&&f&&(q=f),e.defaultValuesToSet[p]=q,E(q,p)}if("fieldset"==b.Datatype){var w=a.fieldsetRows[b.Id.toString()]||[];if(!w.length)return null;var x=d("fieldset",[d("legend",d.html(b.InputLabel)),c.map(w,function(a,b){return D(a,b,e)})]);return w.length&&w[0].length&&x.css({"padding-right":j(w[0][0].OffsetWidth,a.OffsetWidth,0)}),x}"profiling"!=b.Datatype&&t("invalid data type: "+b.Datatype)},B=function(b,e){var f=a.ProcessOptions,g=0;f&&f.profiling&&f.profiling.numberOfProfilingFields&&(g=f.profiling.numberOfProfilingFields);var h=b.ProfilingFieldNumber||g,j=a.fieldsetRows[b.Id.toString()]||[],k=[],l=0;return c.each(j,function(b,d){var e=[],f=[];a.filledFields&&(f=a.filledFields),c.each(d,function(a,b){!i(y.values[b.Name])&&-1==c.inArray(b.Name,f)&&h>l&&(e.push(b),l++)}),e.length>0&&k.push(e)}),d.docFrag(c.map(k,function(a,b){return D(a,b,e)}))},C=function(b){var c,e=0;return c=11==b.nodeType?d(".mktoFormCol",b):b.addClass("mktoFormCol"),e+=f.measure(c).w,c.css("margin-bottom",a.LineMargin||0),{elem:c,width:e}},D=function(a,b,e){var f=0;if(1==a.length&&"profiling"==a[0].Datatype)return B(a[0],e);var g=c.map(a,function(a){var b=A(a,e);if(!b)return null;var c=C(b);return f+=c.width,a.VisibilityRule&&"hidden"!=a.Datatype&&e.fieldsToCheck.push(a),y.fieldElemsByName[a.Name]=c.elem,c.elem});if(0===g.length)return null;var h=d(".mktoFormRow",[g,d(".mktoClear")]);return f>y.formWidth&&(y.formWidth=f),h},E=function(a,b){var e=d("input.mktoField.mktoFieldDescriptor",{type:"hidden",name:b}),f={name:b,val:c.proxy(e.val,e),onChange:function(a){e.on("change",a)}};return y.changeMap[b]&&f.onChange(function(){z(field.Name)}),e.data("mktoFieldDescriptor",f),e},F=function(a,b){var e={},f=function(a,b){e[a]=b};w.setValues(b,f);var g=c.map(e,E);a.append(d.docFrag(g)),w.setValues(b)},G=function(){return window.matchMedia&&c("body.mktoMobileShow").length?window.matchMedia("only screen and (max-width:480px), only screen and (max-device-width:480px), only screen and (max-device-height:480px)").matches:c(window).width()<=480},H=function(a){var b=a.find(".mktoHasWidth").andSelf();b.each(function(){var a=c(this);a.data("mktoFixedWidth",a.css("width")),a.css("width","")})},I=function(){if(y.formElem){{c(window).width()}y.hasRemovedWidths?G()||(y.formElem.find(".mktoHasWidth").andSelf().each(function(){var a=c(this);a.css("width",a.data("mktoFixedWidth"))}),y.hasRemovedWidths=!1):G()&&(H(y.formElem),y.hasRemovedWidths=!0)}},J=function(){var b=a.ButtonStyle||{className:""},c=a.ButtonText||a.SubmitLabel||"Submit",e=a.ButtonLocation||"",f=parseInt(e,10)||0,g=d("span.mktoButtonWrap",[d("button.mktoButton",{type:"submit"},[c])]).addClass(b.className).css({"margin-left":f+"px"});return g},K=function(){var b=a.ProcessOptions;if(!(b&&b.socialSignOn&&b.socialSignOn.isEnabled&&b.socialSignOn.enabledNetworks.length))return"";var c=b.socialSignOn.cfId+"_SocialSignOn",e=d(".cf_widgetLoader.cf_w_"+c);return window.cf_scripts&&window.CF?(setTimeout(function(){CF.widget.restart(c)},10),e):d.docFrag([d("script",{src:a.loaderJsUrl,type:"text/javascript"}),e])},L=function(c){c.addClass("mktoForm mktoHasWidth mktoLayout"+h(a.Layout||"left")+(b.csschecked?"":" mktoNoCheckedSupport")),x&&c.addClass(x)},M=function(a,b){var d=!0;return c.each(y.onSuccess,function(c,e){e(a,b)===!1&&(d=!1)}),d},N=function(a){var b,c=a.__cdrop;return c&&(b=c.split("."),3==b.length)?b[2]:null},O=function(a){var b={};return c.each(a,function(a,d){c.isArray(d)&&d.length>1?b[a+"[]"]=d:b[a]=d}),b},P=function(){var a=location;return-1!=a.hostname.indexOf(u.fbTabDomain)&&-1!=a.search.indexOf("fbTab=1")},Q=function(b){var c=P(),d="";return b&&("string"==typeof a.FormFollowup?(d=a.FormFollowup,c&&0!==d.indexOf("https://")&&(d=q.remapLandingPageUrl(d,location.href),d=q.addQueryParams(d,{fbTab:"1"}))):b.followUpUrl&&"string"==typeof b.followUpUrl?d=b.followUpUrl:b.followUpUrl&&b.followUpUrl.url&&(c&&b.followUpUrl.isLandingPage?(d=q.remapLandingPageUrl(b.followUpUrl.url,location.href),d=q.addQueryParams(d,{fbTab:"1"})):d=b.followUpUrl.url)),d=d||location.href,b.aliId&&(d=q.addQueryParams(d,{aliId:b.aliId})),d},R=function(){var d=w.getValues();if(window.Munchkin)try{window.Munchkin.createTrackingCookie(!0)}catch(e){}{var f=l.parse(location.href,!0).query,g=m.parse(document.cookie),h=l.parse(a.action).hostname,i=(h?"//"+h:"")+u.formSubmitPath;window.location}P()&&(i=u.formSubmitPath,h=location.hostname);var j="json",o="POST";void 0===d._mkt_trk&&(d._mkt_trk=g._mkto_trk),d.formVid=a.Vid,f.mkt_tok&&void 0===d.mkt_tok&&(d.mkt_tok=f.mkt_tok);var p=N(g);p&&(d.MarketoSocialSyndicationId=p),d._mktoReferrer=location.href;var q=k.stringify(O(d)),r=function(a){if(a.error)v(a);else if(a.formId){var b=Q(a);if(!1===M(d,b))return;n.removeCookieAllDomains("_mkto_purl"),location.href=b}},v=function(){if(t(arguments),y.submitButton){var b=y.submitButton.find("button");b.removeAttr("disabled"),b.html(a.ButtonText||a.SubmitLabel||"Submit")}},x={type:o,data:q,dataType:j,url:i,success:r,error:v};h&&h!=location.hostname?b.postmessage&&b.json?s.send(x):(x.dataType="jsonp",x.submitUrl+="?callback=?",x.type="GET",c.ajax(x)):c.ajax(x)},S=function(b){var d=w.validate();if(y.canSubmit&&d&&y.onSubmit&&c.each(y.onSubmit,function(a,b){b(w)}),b.preventDefault(),y.canSubmit&&d){var e=y.submitButton.find("button");return e.attr("disabled","disabled"),a.ButtonSubmissionText&&e.html(a.ButtonSubmissionText),R(),!1}return b.stopPropagation(),!1},T=function(b){var c=a.ButtonStyle||{className:""},e=d("span.mktoButtonWrap",[d("button.mktoButton",{type:"submit"},[b["default"]||""])]).addClass(c.className);return e.click(function(a){a.preventDefault(),R()}),e},U=function(a){return d("a.mktoNotYou",[a["default"]||"Not You?"]).click(function(){n.removeCookieAllDomains("_mkto_trk"),location.href=q.removeQueryParams(location.href,["mkt_tok","aliId"])})},V=function(){var b=a.ProcessOptions.knownLead.template;b=b.replace(/\{\[\((.*?)\)\]\}/g,"{{$1}}");var e={},f=0,g=function(a){return function(){var b=a.apply(null,arguments);if(b.jquery||b.nodeType){var c="__tempSwap"+f;return f++,e[c]=b,""}return b}},h={lead:a.knownLead,form:{Button:g(T),NotYou:g(U)}},i=d("div.mktoTemplateBox",d.html(o(b,h)));return c.each(e,function(a,b){i.find("#"+a).replaceWith(b)}),i};w.render=function(b){y.id=a.Vid||a.Id||1,b||(b=c("form#mktoForm_"+(a.Vid||a.Id))),b.length||(b=d("form#mktoForm_"+(a.Vid||a.Id))),y.formElem=b,b.attr({novalidate:"novalidate"}),b.css({"font-family":a.FontFamily||"","font-size":a.FontSize||"",color:a.FontColor||""}),L(b),f.init(y.formElem),y.formWidth=0;var g={defaultValuesToSet:{},fieldsToCheck:[]},h=c.map(a.rows,function(a,b){return D(a,b,g)}),i=K();c.each(g.fieldsToCheck,function(a,b){if(!p.fieldChangeChecker(b.VisibilityRule,g.defaultValuesToSet).show){var c=d(".mktoPlaceholder.mktoPlaceholder"+b.Name),e=y.fieldElemsByName[b.Name];e&&(e.replaceWith(c),y.fieldElemsByName[b.Name]=c)}});var j="",k=a.ButtonStyle;return k&&(k.css&&(j+=k.css),k.buttonColor&&(j+="\n.mktoForm .mktoButtonWrap."+k.className+" button.mktoButton {background:"+k.buttonColor+";}\n")),b.append(d("style",{type:"text/css"},j)),b.append(a.knownLead&&a.ProcessOptions&&a.ProcessOptions.knownLead&&"custom"==a.ProcessOptions.knownLead.type?V():d.docFrag([i,h,d(".mktoButtonRow",[y.submitButton=J(b)])])),F(b,y.hiddenFields),w.setValues(g.defaultValuesToSet),b.css({width:Math.max(y.submitButton?y.submitButton.outerWidth():0,y.formWidth+1)}),b.on("submit",S),y.validation=e(b),y.validation.init(),setTimeout(function(){c("body").trigger("mktoRender",w).data("mktoRendered",!0)},0),c(window).on("resize",I),I(),"ie7"==x&&W(b),b};var W=function(a){var b=a.find(".mktoFormRow, .mktoFormCol"),d=b.length;b.each(function(){c(this).css("z-index",d--)}),a.css("z-index",b.length+1)};w.getId=function(){return y.id},w.getFormElem=function(){return y.formElem},w.getElem=w.getFormElem(),w.validate=function(){var a=y.validation.check();return c.each(y.onValidate,function(b,c){c(a)}),a},w.onValidate=function(a){return a?y.onValidate.push(a):y.onValidate=[],w},w.offValidate=function(a){return y.onValidate=y.onValidate.filter(function(b){return b!==a}),w},w.submit=function(a){if(a&&"function"==typeof a){var b=function(){w.offSuccess(b),a.apply(null,arguments)};y.onSuccess.push(b)}return y.formElem.trigger("submit"),w},w.onSubmit=function(a){return a?y.onSubmit.push(a):y.onSubmit=[],w},w.offSubmit=function(a){return y.onSubmit=y.onSubmit.filter(function(b){return b!==a}),w},w.onSuccess=function(a){return a?y.onSuccess.push(a):y.onSuccess=[],w},w.offSuccess=function(a){return y.onSuccess=y.onSuccess.filter(function(b){return b!==a}),w},w.submitable=function(a){return arguments.length?(y.canSubmit=a,w):y.canSubmit},w.submittable=w.submitable,w.allFieldsFilled=function(){var a=w.getValues(),b=!0;return c.each(a,function(a,d){c.isArray(d)&&0===d.length?b=!1:(void 0===d||null===d||""===d)&&(b=!1)}),b};var X=function(){var a={};return y.formElem.find(".mktoFieldDescriptor").each(function(b,d){var e=c(d),f=e.data("mktoFieldDescriptor");a[f.name]=f.val}),a};return w.setValuesCoerced=function(b){var c=r.coerceTypes(b,a);w.setValues(c)},w.setValues=function(a,b){if(y.formElem){var d=[],e=X();c.each(a,function(a,c){e[a]?e[a](c):b&&b(a,c),y.changeMap[a]&&d.push(a)}),c.each(d,function(b,d){z(d);var e=X();c.each(y.changeMap[d],function(b,c){e[c]&&void 0!==a[c]&&e[c](a[c])})})}else y.values=a;return w},w.addHiddenFields=function(a){y.formElem?F(y.formElem,a):c.extend(y.hiddenFields,a)},w.getValues=function(){if(y.formElem){var a={},b=X();return c.each(b,function(b,c){var d=c();a[b]=d}),a}return y.values},w.vals=function(){return 0===arguments.length?w.getValues():w.setValues.apply(null,arguments)},w.showErrorMessage=function(a,b){return y.validation&&(b||(b=y.submitButton),y.validation.showError(b,a)),w},w.setErrorMessages=function(a){c.each(a,function(a,b){if(y.fieldsByName[a].ValidationMessage=b,y.formElem){var c=y.fieldElemsByName[a];if(c){var d=c.data("mktoFieldDescriptor");d&&(d.validationMessage=b,c.data("mktoFieldDescriptor",d))}}})},w};b.exports=y},{"./changeManager.js":10,"./comparators.js":12,"./cookiehelper.js":13,"./fields/currency.js":14,"./fields/fieldhelpers.js":16,"./fields/inputCheckbox.js":17,"./fields/inputDate.js":18,"./fields/inputEmail.js":19,"./fields/inputNumber.js":20,"./fields/inputRadio.js":21,"./fields/inputRange.js":22,"./fields/inputTel.js":23,"./fields/inputText.js":24,"./fields/inputUrl.js":25,"./fields/select.js":26,"./fields/textarea.js":27,"./iframeproxy.js":30,"./jquery.js":31,"./measure.js":32,"./prefillcoercer.js":35,"./safelog.js":36,"./tokenTemplate.js":38,"./urlhelper.js":39,"./validation.js":40,cookie:7,querystring:5,url:6}],29:[function(a,b){if("undefined"!=typeof window&&window.MktoForms2)return void(b.exports=window.MktoForms2);var c=a("./jquery.js"),d=a("jquery.build")(c,document),e=a("./form.js");a("./shimsham.js");var f={};f.$=c,f.$b=d,f.Modernizr=a("./modernizr.js");var g=f.Modernizr,h=a("querystring"),i=a("./fields/fieldhelpers.js"),j=a("cookie"),k=a("events"),l=new k.EventEmitter,m=a("url"),n=a("./iframeproxy.js"),o=a("./color.js"),p=a("./safelog.js"),q={rootUrl:"",baseUrl:"/js/forms2/",skipPolyfills:!1,formSubmitPath:"/index.php/leadCapture/save2",formXDPath:"/index.php/form/XDFrame",fbTabDomain:"marketo.com"},r=[];f.setOptions=function(a){c.extend(q,a)};var s=function(a){var b=d("#mktoStyleLoaded").css({display:"none","border-top-color":"#123456"}).appendTo(c("body")),e=0,f=1500,g=25,h=function(){var c=b.css("color"),d=b.css("background-color"),i=b.css("border-top-color");e>f/g?(p("Timeout loading CSS. #mktoStyleLoaded missing color #123456 for one of color, background-color, or border-top-color.",c,d,i),a()):o.compareColor(i,d)&&o.compareColor(i,c)?x(a):(e++,setTimeout(h,g))};h()},t=function(a,b){0===b.indexOf("//")&&(b=location.protocol+b);var e=d("link",{id:a,rel:"stylesheet",type:"text/css",href:b});c("head").append(e),document.createStyleSheet&&document.createStyleSheet(b)},u=function(a,b){window.console&&console.log("Error loading form:",a),b&&b(null)},v=function(a){return 0===a.indexOf("/")&&0!==a.indexOf("//")},w=function(a,b){var d="json";v(a)||(d="jsonp",a+="&callback=?"),c.ajax({dataType:d,url:a,success:b,error:function(a,c,d){u(d,b)}})};f.loadForm=function(a,b,c,d){f.setOptions({rootUrl:a,baseUrl:a+"/js/forms2/"});var e=function(c){c.action=(0===a.indexOf("http")?a:location.protocol+a)+q.formSubmitPath,f.newForm(c,function(a){a.addHiddenFields({munchkinId:b}),a.render(),d&&d(a)})},g=location.href.split("?")[0].split("#")[0];g.length>255&&(g=g.substring(0,255));var h=a+"/index.php/form/getForm?munchkinId="+b+"&form="+c+"&url="+encodeURIComponent(g);return w(h,function(a){a.error?u(a,d):e(a)}),f},f.lightbox=function(b,c){var d,e;return c=c||{},b.getFormElem?(b.getFormElem()||b.render(),d=b.getFormElem(),b.onSuccess(c.onSuccess||function(a,b){return e.hide(),b?void 0:!1})):d=b,e=a("./modal.js")(d,c)};var x=function(a){setTimeout(a,0)},y=function(a,b,d,e){if(window.mktoPreFillFields&&mktoPreFillFields.FirstName&&mktoPreFillFields.LastName)return void x(function(){e(mktoPreFillFields)});var f=j.parse(document.cookie);if(f._mkto_trk){var g=q.rootUrl+"/index.php/form/getKnownLead?_mkt_trk="+encodeURIComponent(f._mkto_trk)+"&form="+a+"&munchkinId="+b+"&filledFields="+d;return void w(g,function(a){a&&a.error?u(a,e):(window.mktoPreFillFields&&(a=c.extend({},window.mktoPrefillFields,a)),e(a))})}x(e)};f.newForm=function(a,b){if(0===c("#mktoForms2BaseStyle").length){var h=q.baseUrl+"css/forms2.css";t("mktoForms2BaseStyle",h)}0===c("#mktoForms2ThemeStyle").length&&a.ThemeStyle&&a.ThemeStyle.href?t("mktoForms2ThemeStyle",q.baseUrl+a.ThemeStyle.href):c("head").append(d("style","#mktoStyleLoaded {color:#123456;}")),a.FontUrl&&t("mktoFontUrl",a.FontUrl),a.ThemeStyleOverride&&c("head").append(d("style",a.ThemeStyleOverride)),f._polyfillsLoaded||(A(a),f._polyfillsLoaded=!0);var i=a.ProcessOptions,j=0,k=function(){var a=location;return-1!=a.hostname.indexOf(q.fbTabDomain)&&-1!=a.search.indexOf("fbTab=1")},o=function(){return-1!=location.hostname.indexOf(".marketodesigner.com")},p=function(){if(j--,0>=j){var c=e(a,g,q);r.push(c),b&&b(c),x(function(){if(a.action&&!k()&&!o()){var b=m.parse(a.action).hostname;b&&b!=location.hostname&&g.postmessage&&g.json&&n.init("//"+b+q.formXDPath)}}),x(function(){l.emit("mktoFormReady",c)})}},u=i&&i.profiling&&i.profiling.isEnabled,v=i&&i.knownLead&&"custom"==i.knownLead.type&&a.munchkinId;(v||u)&&(j++,y(a.Vid,a.munchkinId,u,function(b){b&&(a.filledFields=b.filledFields,b.FirstName&&b.LastName&&(a.knownLead=b)),p()})),j++,s(p)},f.getForm=function(a){for(var b=0;b0&&b-1 in a)}function e(a){var b=Ab[a]={};return lb.each(a.match(nb)||[],function(a,c){b[c]=!0}),b}function f(a,b,d,e){if(lb.acceptData(a)){var f,g,h=lb.expando,i=a.nodeType,j=i?lb.cache:a,k=i?a[h]:a[h]&&h;if(k&&j[k]&&(e||j[k].data)||d!==c||"string"!=typeof b)return k||(k=i?a[h]=cb.pop()||lb.guid++:h),j[k]||(j[k]=i?{}:{toJSON:lb.noop}),("object"==typeof b||"function"==typeof b)&&(e?j[k]=lb.extend(j[k],b):j[k].data=lb.extend(j[k].data,b)),g=j[k],e||(g.data||(g.data={}),g=g.data),d!==c&&(g[lb.camelCase(b)]=d),"string"==typeof b?(f=g[b],null==f&&(f=g[lb.camelCase(b)])):f=g,f}}function g(a,b,c){if(lb.acceptData(a)){var d,e,f=a.nodeType,g=f?lb.cache:a,h=f?a[lb.expando]:lb.expando;if(g[h]){if(b&&(d=c?g[h]:g[h].data)){lb.isArray(b)?b=b.concat(lb.map(b,lb.camelCase)):b in d?b=[b]:(b=lb.camelCase(b),b=b in d?[b]:b.split(" ")),e=b.length;for(;e--;)delete d[b[e]];if(c?!i(d):!lb.isEmptyObject(d))return}(c||(delete g[h].data,i(g[h])))&&(f?lb.cleanData([a],!0):lb.support.deleteExpando||g!=g.window?delete g[h]:g[h]=null)}}}function h(a,b,d){if(d===c&&1===a.nodeType){var e="data-"+b.replace(Cb,"-$1").toLowerCase();if(d=a.getAttribute(e),"string"==typeof d){try{d="true"===d?!0:"false"===d?!1:"null"===d?null:+d+""===d?+d:Bb.test(d)?lb.parseJSON(d):d}catch(f){}lb.data(a,b,d)}else d=c}return d}function i(a){var b;for(b in a)if(("data"!==b||!lb.isEmptyObject(a[b]))&&"toJSON"!==b)return!1;return!0}function j(){return!0}function k(){return!1}function l(){try{return Z.activeElement}catch(a){}}function m(a,b){do a=a[b];while(a&&1!==a.nodeType);return a}function n(a,b,c){if(lb.isFunction(b))return lb.grep(a,function(a,d){return!!b.call(a,d,a)!==c});if(b.nodeType)return lb.grep(a,function(a){return a===b!==c});if("string"==typeof b){if(Rb.test(b))return lb.filter(b,a,c);b=lb.filter(b,a)}return lb.grep(a,function(a){return lb.inArray(a,b)>=0!==c})}function o(a){var b=Vb.split("|"),c=a.createDocumentFragment();if(c.createElement)for(;b.length;)c.createElement(b.pop());return c}function p(a,b){return lb.nodeName(a,"table")&&lb.nodeName(1===b.nodeType?b:b.firstChild,"tr")?a.getElementsByTagName("tbody")[0]||a.appendChild(a.ownerDocument.createElement("tbody")):a}function q(a){return a.type=(null!==lb.find.attr(a,"type"))+"/"+a.type,a}function r(a){var b=fc.exec(a.type);return b?a.type=b[1]:a.removeAttribute("type"),a}function s(a,b){for(var c,d=0;null!=(c=a[d]);d++)lb._data(c,"globalEval",!b||lb._data(b[d],"globalEval"))}function t(a,b){if(1===b.nodeType&&lb.hasData(a)){var c,d,e,f=lb._data(a),g=lb._data(b,f),h=f.events;if(h){delete g.handle,g.events={};for(c in h)for(d=0,e=h[c].length;e>d;d++)lb.event.add(b,c,h[c][d])}g.data&&(g.data=lb.extend({},g.data))}}function u(a,b){var c,d,e;if(1===b.nodeType){if(c=b.nodeName.toLowerCase(),!lb.support.noCloneEvent&&b[lb.expando]){e=lb._data(b);for(d in e.events)lb.removeEvent(b,d,e.handle);b.removeAttribute(lb.expando)}"script"===c&&b.text!==a.text?(q(b).text=a.text,r(b)):"object"===c?(b.parentNode&&(b.outerHTML=a.outerHTML),lb.support.html5Clone&&a.innerHTML&&!lb.trim(b.innerHTML)&&(b.innerHTML=a.innerHTML)):"input"===c&&cc.test(a.type)?(b.defaultChecked=b.checked=a.checked,b.value!==a.value&&(b.value=a.value)):"option"===c?b.defaultSelected=b.selected=a.defaultSelected:("input"===c||"textarea"===c)&&(b.defaultValue=a.defaultValue)}}function v(a,b){var d,e,f=0,g=typeof a.getElementsByTagName!==X?a.getElementsByTagName(b||"*"):typeof a.querySelectorAll!==X?a.querySelectorAll(b||"*"):c;if(!g)for(g=[],d=a.childNodes||a;null!=(e=d[f]);f++)!b||lb.nodeName(e,b)?g.push(e):lb.merge(g,v(e,b));return b===c||b&&lb.nodeName(a,b)?lb.merge([a],g):g}function w(a){cc.test(a.type)&&(a.defaultChecked=a.checked)}function x(a,b){if(b in a)return b;for(var c=b.charAt(0).toUpperCase()+b.slice(1),d=b,e=zc.length;e--;)if(b=zc[e]+c,b in a)return b;return d}function y(a,b){return a=b||a,"none"===lb.css(a,"display")||!lb.contains(a.ownerDocument,a)}function z(a,b){for(var c,d,e,f=[],g=0,h=a.length;h>g;g++)d=a[g],d.style&&(f[g]=lb._data(d,"olddisplay"),c=d.style.display,b?(f[g]||"none"!==c||(d.style.display=""),""===d.style.display&&y(d)&&(f[g]=lb._data(d,"olddisplay",D(d.nodeName)))):f[g]||(e=y(d),(c&&"none"!==c||!e)&&lb._data(d,"olddisplay",e?c:lb.css(d,"display"))));for(g=0;h>g;g++)d=a[g],d.style&&(b&&"none"!==d.style.display&&""!==d.style.display||(d.style.display=b?f[g]||"":"none"));return a}function A(a,b,c){var d=sc.exec(b);return d?Math.max(0,d[1]-(c||0))+(d[2]||"px"):b}function B(a,b,c,d,e){for(var f=c===(d?"border":"content")?4:"width"===b?1:0,g=0;4>f;f+=2)"margin"===c&&(g+=lb.css(a,c+yc[f],!0,e)),d?("content"===c&&(g-=lb.css(a,"padding"+yc[f],!0,e)),"margin"!==c&&(g-=lb.css(a,"border"+yc[f]+"Width",!0,e))):(g+=lb.css(a,"padding"+yc[f],!0,e),"padding"!==c&&(g+=lb.css(a,"border"+yc[f]+"Width",!0,e)));return g}function C(a,b,c){var d=!0,e="width"===b?a.offsetWidth:a.offsetHeight,f=lc(a),g=lb.support.boxSizing&&"border-box"===lb.css(a,"boxSizing",!1,f);if(0>=e||null==e){if(e=mc(a,b,f),(0>e||null==e)&&(e=a.style[b]),tc.test(e))return e;d=g&&(lb.support.boxSizingReliable||e===a.style[b]),e=parseFloat(e)||0}return e+B(a,b,c||(g?"border":"content"),d,f)+"px"}function D(a){var b=Z,c=vc[a];return c||(c=E(a,b),"none"!==c&&c||(kc=(kc||lb("'+'
      '+(t?'
      '+t+"
      ":"")+(r.options.lightboxShowCounter?'
      '+n+"
      ":"")+"
      "+"";r.content.html(i);r.wrap.addClass("cbp-popup-ready");r.preloadNearbyImages()},updateImagesMarkup:function(e,t,n){var r=this;r.wrap.removeClass("cbp-popup-lightbox-isIframe");var i='
      '+'"+'
      '+(t?'
      '+t+"
      ":"")+(r.options.lightboxShowCounter?'
      '+n+"
      ":"")+"
      "+"
      ";r.content.html(i);r.wrap.addClass("cbp-popup-ready");r.resizeImage();r.preloadNearbyImages()},next:function(){var e=this;e[e.type+"JumpTo"](1)},prev:function(){var e=this;e[e.type+"JumpTo"](-1)},lightboxJumpTo:function(e){var t=this,n;t.current=t.getIndex(t.current+e);n=t.dataArray[t.current];t[n.type](n)},singlePageJumpTo:function(t){var n=this;n.current=n.getIndex(n.current+t);if(e.isFunction(n.options.singlePageCallback)){n.resetWrap();n.stopScroll=true;n.wrap.scrollTop(0);if(n.options.singlePageStickyNavigation){n.navigationWrap.width("100%");n.wrap.removeClass("cbp-popup-singlePage-sticky")}n.wrap.addClass("cbp-popup-loading");n.options.singlePageCallback.call(n,n.dataArray[n.current].url,n.dataArray[n.current].element);if(n.options.singlePageDeeplinking){location.href=n.url+"#cbp="+n.dataArray[n.current].url}}},resetWrap:function(){var e=this;if(e.type==="singlePage"&&e.options.singlePageDeeplinking){location.href=e.url+"#"}},getIndex:function(e){var t=this;e=e%t.counterTotal;if(e<0){e=t.counterTotal+e}return e},close:function(n,r){var i=this;i.isOpen=false;if(i.type==="singlePageInline"){if(n==="open"){i.wrap.addClass("cbp-popup-loading");e(i.dataArray[i.current].element).parents(".cbp-item").removeClass("cbp-singlePageInline-active");i.openSinglePageInline(r.blocks,r.currentBlock,r.fromOpen)}else{i.matrice=[-1,-1];i.cubeportfolio._layout();i.cubeportfolio._processStyle(i.cubeportfolio.transition);i.cubeportfolio._resizeMainContainer(i.cubeportfolio.transition);i.wrap.css({height:0});e(i.dataArray[i.current].element).parents(".cbp-item").removeClass("cbp-singlePageInline-active");if(i.cubeportfolio.browser==="ie8"||i.cubeportfolio.browser==="ie9"){i.content.html("");i.wrap.detach();i.cubeportfolio.$obj.removeClass("cbp-popup-isOpening");if(n==="promise"){if(e.isFunction(r.callback)){r.callback.call(i.cubeportfolio)}}}else{i.wrap.one(i.cubeportfolio.transitionEnd,function(){i.content.html("");i.wrap.detach();i.cubeportfolio.$obj.removeClass("cbp-popup-isOpening");if(n==="promise"){if(e.isFunction(r.callback)){r.callback.call(i.cubeportfolio)}}})}}}else{i.wrap.removeClass("cbp-popup-singlePage-open cbp-popup-singlePage-sticky");i.resetWrap();e("html").css({overflow:"","padding-right":""});e(t).scrollTop(i.scrollTop);i.content.html("");i.wrap.detach()}},tooggleLoading:function(e){var t=this;t.stopEvents=e;t.wrap[e?"addClass":"removeClass"]("cbp-popup-loading")},resizeImage:function(){if(!this.isOpen)return;var n=e(t).height(),r=e(".cbp-popup-content").find("img"),i=parseInt(r.css("margin-top"),10)+parseInt(r.css("margin-bottom"),10);r.css("max-height",n-i+"px")},preloadNearbyImages:function(){var t=[],n,r=this,i;t.push(r.getIndex(r.current+1));t.push(r.getIndex(r.current+2));t.push(r.getIndex(r.current+3));t.push(r.getIndex(r.current-1));t.push(r.getIndex(r.current-2));t.push(r.getIndex(r.current-3));for(var s=t.length-1;s>=0;s--){if(r.dataArray[t[s]].type==="isImage"){i=r.dataArray[t[s]].src;n=new Image;if(e('').is("img:uncached")){n.src=i}}}}};var u={_main:function(t,n,r){var i=this;i.styleQueue=[];i.isAnimating=false;i.defaultFilter="*";i.registeredEvents=[];if(e.isFunction(r)){i._registerEvent("initFinish",r,true)}i.options=e.extend({},e.fn.cubeportfolio.options,n);i.obj=t;i.$obj=e(t);i.width=i.$obj.width();i.$obj.addClass("cbp cbp-loading");i.$ul=i.$obj.children();i.$ul.addClass("cbp-wrapper");if(i.options.displayType==="lazyLoading"||i.options.displayType==="fadeIn"){i.$ul.css({opacity:0})}if(i.options.displayType==="fadeInToTop"){i.$ul.css({opacity:0,marginTop:30})}i._browserInfo();i._initCSSandEvents();i._prepareBlocks();if(i.options.displayType==="lazyLoading"||i.options.displayType==="sequentially"||i.options.displayType==="bottomToTop"||i.options.displayType==="fadeInToTop"){i._load()}else{i._display()}},_browserInfo:function(){var e=this,t=navigator.appVersion,n,r;if(t.indexOf("MSIE 8.")!==-1){e.browser="ie8"}else if(t.indexOf("MSIE 9.")!==-1){e.browser="ie9"}else if(t.indexOf("MSIE 10.")!==-1){e.browser="ie10"}else if(/android/gi.test(t)){e.browser="android"}else if(/iphone|ipad|ipod/gi.test(t)){e.browser="ios"}else{e.browser=""}if(e.browser){e.$obj.addClass("cbp-"+e.browser)}n=e._styleSupport("transition");r=e._styleSupport("animation");e.transition=e.transitionByFilter=n?"css":"animate";if(e.transition=="animate")return;e.transitionEnd={WebkitTransition:"webkitTransitionEnd",MozTransition:"transitionend",OTransition:"oTransitionEnd otransitionend",transition:"transitionend"}[n];e.animationEnd={WebkitAnimation:"webkitAnimationEnd",MozAnimation:"Animationend",OAnimation:"oAnimationEnd oanimationend",animation:"animationend"}[r];e.supportCSSTransform=e._styleSupport("transform");if(e.supportCSSTransform){e._cssHooks()}},_styleSupport:function(e){var t,r,i,s=e.charAt(0).toUpperCase()+e.slice(1),o=["Moz","Webkit","O","ms"],u=n.createElement("div");if(e in u.style){r=e}else{for(i=o.length-1;i>=0;i--){t=o[i]+s;if(t in u.style){r=t;break}}}u=null;return r},_cssHooks:function(){function r(r,i,s){var o=e(r),u=o.data("transformFn")||{},a={},f,l={},c,h,p,d,v;a[s]=i;e.extend(u,a);for(f in u){c=u[f];l[f]=n[f](c)}h=l.translate||"";p=l.scale||"";v=l.skew||"";d=h+p+v;o.data("transformFn",u);r.style[t.supportCSSTransform]=d}var t=this,n;if(t._has3d()){n={translate:function(e){return"translate3d("+e[0]+"px, "+e[1]+"px, 0) "},scale:function(e){return"scale3d("+e+", "+e+", 1) "},skew:function(e){return"skew("+e[0]+"deg, "+e[1]+"deg) "}}}else{n={translate:function(e){return"translate("+e[0]+"px, "+e[1]+"px) "},scale:function(e){return"scale("+e+") "},skew:function(e){return"skew("+e[0]+"deg, "+e[1]+"deg) "}}}e.cssNumber.scale=true;e.cssHooks.scale={set:function(e,t){if(typeof t==="string"){t=parseFloat(t)}r(e,t,"scale")},get:function(t,n){var r=e.data(t,"transformFn");return r&&r.scale?r.scale:1}};e.fx.step.scale=function(t){e.cssHooks.scale.set(t.elem,t.now+t.unit)};e.cssNumber.translate=true;e.cssHooks.translate={set:function(e,t){r(e,t,"translate")},get:function(t,n){var r=e.data(t,"transformFn");return r&&r.translate?r.translate:[0,0]}};e.cssNumber.skew=true;e.cssHooks.skew={set:function(e,t){r(e,t,"skew")},get:function(t,n){var r=e.data(t,"transformFn");return r&&r.skew?r.skew:[0,0]}}},_has3d:function(){var e=n.createElement("p"),i,s={webkitTransform:"-webkit-transform",OTransform:"-o-transform",msTransform:"-ms-transform",MozTransform:"-moz-transform",transform:"transform"};n.body.insertBefore(e,null);for(var o in s){if(e.style[o]!==r){e.style[o]="translate3d(1px,1px,1px)";i=t.getComputedStyle(e).getPropertyValue(s[o])}}n.body.removeChild(e);return i!==r&&i.length>0&&i!=="none"},_prepareBlocks:function(){var e=this,t;e.blocks=e.$ul.children(".cbp-item");e.blocksAvailable=e.blocks;e.blocks.wrapInner('
      ');if(e.options.caption){e._captionInit()}},_captionInit:function(){var e=this;e.$obj.addClass("cbp-caption-"+e.options.caption);e["_"+e.options.caption+"Caption"]()},_captionDestroy:function(){var e=this;e.$obj.removeClass("cbp-caption-"+e.options.caption);e["_"+e.options.caption+"CaptionDestroy"]()},_pushTopCaption:function(){var t=this;if(t.browser==="ie8"||t.browser==="ie9"){e(".cbp-caption").on("mouseenter"+s,function(){var t=e(this),n=t.find(".cbp-caption-defaultWrap"),r=t.find(".cbp-caption-activeWrap");n.animate({bottom:"100%"},"fast");r.animate({bottom:0},"fast")}).on("mouseleave"+s,function(t){var n=e(this),r=n.find(".cbp-caption-defaultWrap"),i=n.find(".cbp-caption-activeWrap");r.animate({bottom:0},"fast");i.animate({bottom:"-100%"},"fast")})}},_pushTopCaptionDestroy:function(){var t=this;if(t.browser==="ie8"||t.browser==="ie9"){e(".cbp-caption").off("mouseenter"+s+" mouseleave"+s);e(".cbp-caption").find(".cbp-caption-defaultWrap").removeAttr("style");e(".cbp-caption").find(".cbp-caption-activeWrap").removeAttr("style")}},_pushDownCaption:function(){var t=this;if(t.browser==="ie8"||t.browser==="ie9"){e(".cbp-caption").on("mouseenter"+s,function(){var t=e(this),n=t.find(".cbp-caption-defaultWrap"),r=t.find(".cbp-caption-activeWrap");n.animate({bottom:"-100%"},"fast");r.animate({bottom:0},"fast")}).on("mouseleave"+s,function(t){var n=e(this),r=n.find(".cbp-caption-defaultWrap"),i=n.find(".cbp-caption-activeWrap");r.animate({bottom:0},"fast");i.animate({bottom:"100%"},"fast")})}},_pushDownCaptionDestroy:function(){var t=this;if(t.browser==="ie8"||t.browser==="ie9"){e(".cbp-caption").off("mouseenter"+s+" mouseleave"+s);e(".cbp-caption").find(".cbp-caption-defaultWrap").removeAttr("style");e(".cbp-caption").find(".cbp-caption-activeWrap").removeAttr("style")}},_revealBottomCaption:function(){var t=this;if(t.browser==="ie8"||t.browser==="ie9"){e(".cbp-caption").on("mouseenter"+s,function(){var t=e(this),n=t.find(".cbp-caption-defaultWrap");n.animate({bottom:"100%"},"fast")}).on("mouseleave"+s,function(t){var n=e(this),r=n.find(".cbp-caption-defaultWrap");r.animate({bottom:0},"fast")})}},_revealBottomCaptionDestroy:function(){var t=this;if(t.browser==="ie8"||t.browser==="ie9"){e(".cbp-caption").off("mouseenter"+s+" mouseleave"+s);e(".cbp-caption").find(".cbp-caption-defaultWrap").removeAttr("style")}},_revealTopCaption:function(){var t=this;if(t.browser==="ie8"||t.browser==="ie9"){e(".cbp-caption").on("mouseenter"+s,function(){var t=e(this),n=t.find(".cbp-caption-defaultWrap");n.animate({bottom:"-100%"},"fast")}).on("mouseleave"+s,function(t){var n=e(this),r=n.find(".cbp-caption-defaultWrap");r.animate({bottom:0},"fast")})}},_revealTopCaptionDestroy:function(){var t=this;if(t.browser==="ie8"||t.browser==="ie9"){e(".cbp-caption").off("mouseenter"+s+" mouseleave"+s);e(".cbp-caption").find(".cbp-caption-defaultWrap").removeAttr("style")}},_overlayBottomRevealCaption:function(){var t=this;if(t.browser==="ie8"||t.browser==="ie9"){e(".cbp-caption").on("mouseenter"+s,function(){var t=e(this),n=t.find(".cbp-caption-defaultWrap"),r=t.find(".cbp-caption-activeWrap").height();n.animate({bottom:r},"fast")}).on("mouseleave"+s,function(t){var n=e(this),r=n.find(".cbp-caption-defaultWrap");r.animate({bottom:0},"fast")})}},_overlayBottomRevealCaptionDestroy:function(){var t=this;if(t.browser==="ie8"||t.browser==="ie9"){e(".cbp-caption").off("mouseenter"+s+" mouseleave"+s);e(".cbp-caption").find(".cbp-caption-defaultWrap").removeAttr("style")}},_overlayBottomPushCaption:function(){var t=this;if(t.browser==="ie8"||t.browser==="ie9"){e(".cbp-caption").on("mouseenter"+s,function(){var t=e(this),n=t.find(".cbp-caption-defaultWrap"),r=t.find(".cbp-caption-activeWrap"),i=r.height();n.animate({bottom:i},"fast");r.animate({bottom:0},"fast")}).on("mouseleave"+s,function(t){var n=e(this),r=n.find(".cbp-caption-defaultWrap"),i=n.find(".cbp-caption-activeWrap"),s=i.height();r.animate({bottom:0},"fast");i.animate({bottom:-s},"fast")})}},_overlayBottomPushCaptionDestroy:function(){var t=this;if(t.browser==="ie8"||t.browser==="ie9"){e(".cbp-caption").off("mouseenter"+s+" mouseleave"+s);e(".cbp-caption").find(".cbp-caption-defaultWrap").removeAttr("style");e(".cbp-caption").find(".cbp-caption-activeWrap").removeAttr("style")}},_overlayBottomCaption:function(){var t=this;if(t.browser==="ie8"||t.browser==="ie9"){e(".cbp-caption").on("mouseenter"+s,function(){e(this).find(".cbp-caption-activeWrap").animate({bottom:0},"fast")}).on("mouseleave"+s,function(t){var n=e(this).find(".cbp-caption-activeWrap");n.animate({bottom:-n.height()},"fast")})}},_overlayBottomCaptionDestroy:function(){var t=this;if(t.browser==="ie8"||t.browser==="ie9"){e(".cbp-caption").off("mouseenter"+s+" mouseleave"+s);e(".cbp-caption").find(".cbp-caption-activeWrap").removeAttr("style")}},_moveRightCaption:function(){var t=this;if(t.browser==="ie8"||t.browser==="ie9"){e(".cbp-caption").on("mouseenter"+s,function(){e(this).find(".cbp-caption-activeWrap").animate({left:0},"fast")}).on("mouseleave"+s,function(){var t=e(this).find(".cbp-caption-activeWrap");t.animate({left:-t.width()},"fast")})}},_moveRightCaptionDestroy:function(){var t=this;if(t.browser==="ie8"||t.browser==="ie9"){e(".cbp-caption").off("mouseenter"+s+" mouseleave"+s);e(".cbp-caption").find(".cbp-caption-activeWrap").removeAttr("style")}},_revealLeftCaption:function(){var t=this;if(t.browser==="ie8"||t.browser==="ie9"){e(".cbp-caption").on("mouseenter"+s,function(){e(this).find(".cbp-caption-activeWrap").animate({left:0},"fast")}).on("mouseleave"+s,function(){var t=e(this).find(".cbp-caption-activeWrap");t.animate({left:t.width()},"fast")})}},_revealLeftCaptionDestroy:function(){var t=this;if(t.browser==="ie8"||t.browser==="ie9"){e(".cbp-caption").off("mouseenter"+s+" mouseleave"+s);e(".cbp-caption").find(".cbp-caption-activeWrap").removeAttr("style")}},_minimalCaption:function(){var e=this},_minimalCaptionDestroy:function(){var e=this},_fadeInCaption:function(){var t=this,n;if(t.browser==="ie8"||t.browser==="ie9"){n=t.browser==="ie9"?1:.8;e(".cbp-caption").on("mouseenter"+s,function(){e(this).find(".cbp-caption-activeWrap").animate({opacity:n},"fast")}).on("mouseleave"+s,function(){e(this).find(".cbp-caption-activeWrap").animate({opacity:0},"fast")})}},_fadeInCaptionDestroy:function(){var t=this;if(t.browser==="ie8"||t.browser==="ie9"){e(".cbp-caption").off("mouseenter"+s+" mouseleave"+s);e(".cbp-caption").find(".cbp-caption-activeWrap").removeAttr("style")}},_overlayRightAlongCaption:function(){var t=this;if(t.browser==="ie8"||t.browser==="ie9"){e(".cbp-caption").on("mouseenter"+s,function(){var t=e(this),n=t.find(".cbp-caption-defaultWrap"),r=t.find(".cbp-caption-activeWrap");n.animate({left:r.width()/2},"fast");r.animate({left:0},"fast")}).on("mouseleave"+s,function(t){var n=e(this),r=n.find(".cbp-caption-defaultWrap"),i=n.find(".cbp-caption-activeWrap");r.animate({left:0},"fast");i.animate({left:-i.width()},"fast")})}},_overlayRightAlongCaptionDestroy:function(){var t=this;if(t.browser==="ie8"||t.browser==="ie9"){e(".cbp-caption").off("mouseenter"+s+" mouseleave"+s);e(".cbp-caption").find(".cbp-caption-defaultWrap").removeAttr("style");e(".cbp-caption").find(".cbp-caption-activeWrap").removeAttr("style")}},_overlayBottomAlongCaption:function(){var t=this;if(t.browser==="ie8"||t.browser==="ie9"){e(".cbp-caption").on("mouseenter"+s,function(){var t=e(this),n=t.find(".cbp-caption-defaultWrap"),r=t.find(".cbp-caption-activeWrap");n.animate({bottom:r.height()/2},"fast");r.animate({bottom:0},"fast")}).on("mouseleave"+s,function(t){var n=e(this),r=n.find(".cbp-caption-defaultWrap"),i=n.find(".cbp-caption-activeWrap");r.animate({bottom:0},"fast");i.animate({bottom:-i.height()},"fast")})}},_overlayBottomAlongCaptionDestroy:function(){var t=this;if(t.browser==="ie8"||t.browser==="ie9"){e(".cbp-caption").off("mouseenter"+s+" mouseleave"+s);e(".cbp-caption").find(".cbp-caption-defaultWrap").removeAttr("style");e(".cbp-caption").find(".cbp-caption-activeWrap").removeAttr("style")}},_zoomCaption:function(){var t=this,n;if(t.browser==="ie8"||t.browser==="ie9"){n=t.browser==="ie9"?1:.8;e(".cbp-caption").on("mouseenter"+s,function(){e(this).find(".cbp-caption-activeWrap").animate({opacity:n},"fast")}).on("mouseleave"+s,function(){e(this).find(".cbp-caption-activeWrap").animate({opacity:0},"fast")})}},_zoomCaptionDestroy:function(){var t=this;if(t.browser==="ie8"||t.browser==="ie9"){e(".cbp-caption").off("mouseenter"+s+" mouseleave"+s);e(".cbp-caption").find(".cbp-caption-activeWrap").removeAttr("style")}},_initCSSandEvents:function(){var n=this,i,o,u,a;e(t).on("resize"+s,function(){if(i){clearTimeout(i)}i=setTimeout(function(){if(n.browser==="ie8"){a=e(t).width();if(u===r||u!=a){u=a}else{return}}n.$obj.removeClass("cbp-no-transition cbp-appendItems-loading");if(n.options.gridAdjustment==="responsive"){n._responsiveLayout()}n._layout();n._processStyle(n.transition);n._resizeMainContainer(n.transition);if(n.lightbox){n.lightbox.resizeImage()}if(n.singlePage){if(n.singlePage.options.singlePageStickyNavigation){o=n.singlePage.wrap[0].clientWidth;if(o>0){n.singlePage.navigationWrap.width(n.singlePage.wrap[0].clientWidth);n.singlePage.navigation.width(n.singlePage.wrap[0].clientWidth)}}}},50)})},_load:function(){var t=this,n=[],r,i,o,u,a=/url\((['"]?)(.*?)\1\)/g;o=t.$obj.children().css("backgroundImage");if(o){var f;while(f=a.exec(o)){n.push({src:f[2]})}}t.$obj.find("*").each(function(){var t=e(this);if(t.is("img:uncached")){n.push({src:t.attr("src"),element:t[0]})}o=t.css("backgroundImage");if(o){var r;while(r=a.exec(o)){n.push({src:r[2],element:t[0]})}}});var l=n.length,c=0;if(l===0){t._display()}var h=function(){c++;if(c==l){t._display();return false}};for(r=0;r=t.singlePageInline.matrice[0]&&n<=t.singlePageInline.matrice[1]){o=t.singlePageInline.height}if(s===1){t._placeBlocks(i,t.colVert,o)}else{var u=t.cols+1-s,a=[],f,l;for(l=0;l.5){t.localColumnWidth=t.localColumnWidth-(t.localColumnWidth-r)/(t.cols+1)}else{t.localColumnWidth=t.localColumnWidth+r/t.cols}t.localColumnWidth=parseInt(t.localColumnWidth,10);n=t.localColumnWidth/t.columnWidthCache;t.blocks.each(function(r,i){var s=e(this),o=e.data(this,"cbp-wxh");if(!o){o=e.data(this,"cbp-wxh",{width:s.outerWidth(),height:s.outerHeight()})}s.css("width",t.localColumnWidth-t.options.gapVertical);s.css("height",Math.floor(o.height*n))});if(t.blocksClone){t.blocksClone.each(function(r,i){var s=e(this),o=e.data(this,"cbp-wxh");if(!o){o=e.data(this,"cbp-wxh",{width:s.outerWidth(),height:s.outerHeight()})}s.css("width",t.localColumnWidth-t.options.gapVertical);s.css("height",Math.floor(o.height*n))})}},_resizeMainContainer:function(e,t){var n=this;t=t||0;n.height=Math.max.apply(Math,n.colVert)+t;n.$obj[e]({height:n.height-n.options.gapHorizontal},400)},_processStyle:function(e){var t=this;for(var n=t.styleQueue.length-1;n>=0;n--){t.styleQueue[n].$el[e](t.styleQueue[n].style)}t.styleQueue=[]},_placeBlocks:function(e,t,n){var r=this,i=Math.min.apply(Math,t),s=0,o,u,a,f,l,c;for(l=0,c=t.length;l')}},_boxShadowFilter:function(e,t,n){var r=this;if(n!=="*"){t=t.filter(n);e=r.blocks.not(".cbp-item-hidden").not(n).addClass("cbp-item-hidden")}t.removeClass("cbp-item-hidden");var i=r.blocks.find(".cbp-animation-boxShadowMask");i.addClass("cbp-animation-boxShadowShow");i.removeClass("cbp-animation-boxShadowActive cbp-animation-boxShadowInactive");r.blocksAvailable=r.blocks.filter(n);var s={};if(e.length){e.find(".cbp-animation-boxShadowMask").addClass("cbp-animation-boxShadowActive");r.styleQueue.push({$el:e,style:{opacity:0}});s=e.last()}if(t.length){t.find(".cbp-animation-boxShadowMask").addClass("cbp-animation-boxShadowInactive");r.styleQueue.push({$el:t,style:{opacity:1}});s=t.last()}r._layout();if(s.length){s.one(r.transitionEnd,function(){i.removeClass("cbp-animation-boxShadowShow");r._filterFinish()})}else{i.removeClass("cbp-animation-boxShadowShow");r._filterFinish()}r._processStyle(r.transitionByFilter);r._resizeMainContainer(r.transition)},_bounceLeftInit:function(){var e=this;e._duplicateContent({left:"-100%",opacity:0});e.transitionByFilter="css";e.$ul.addClass("cbp-wrapper-front")},_bounceLeftFilter:function(e,t,n){var r=this,i,s,o;r.$obj.addClass("cbp-no-transition");if(r.ulHidden==="clone"){r.ulHidden="first";i=r.$ulClone;o=r.$ul;s=r.blocksClone}else{r.ulHidden="clone";i=r.$ul;o=r.$ulClone;s=r.blocks}t=s.filter(".cbp-item-hidden");if(n!=="*"){t=t.filter(n);s.not(".cbp-item-hidden").not(n).addClass("cbp-item-hidden")}t.removeClass("cbp-item-hidden");r.blocksAvailable=s.filter(n);r._layout();o[r.transition]({left:"-100%",opacity:0}).removeClass("cbp-wrapper-front").addClass("cbp-wrapper-back");i[r.transition]({left:0,opacity:1}).addClass("cbp-wrapper-front").removeClass("cbp-wrapper-back");r._processStyle(r.transitionByFilter);r._resizeMainContainer(r.transition);setTimeout(function(){r._filterFinish()},400)},_bounceTopInit:function(){var e=this;e._duplicateContent({top:"-100%",opacity:0});e.transitionByFilter="css";e.$ul.addClass("cbp-wrapper-front")},_bounceTopFilter:function(e,t,n){var r=this,i,s,o;r.$obj.addClass("cbp-no-transition");if(r.ulHidden==="clone"){r.ulHidden="first";i=r.$ulClone;o=r.$ul;s=r.blocksClone}else{r.ulHidden="clone";i=r.$ul;o=r.$ulClone;s=r.blocks}t=s.filter(".cbp-item-hidden");if(n!=="*"){t=t.filter(n);s.not(".cbp-item-hidden").not(n).addClass("cbp-item-hidden")}t.removeClass("cbp-item-hidden");r.blocksAvailable=s.filter(n);r._layout();o[r.transition]({top:"-100%",opacity:0}).removeClass("cbp-wrapper-front").addClass("cbp-wrapper-back");i[r.transition]({top:0,opacity:1}).addClass("cbp-wrapper-front").removeClass("cbp-wrapper-back");r._processStyle(r.transitionByFilter);r._resizeMainContainer(r.transition);setTimeout(function(){r._filterFinish()},400)},_bounceBottomInit:function(){var e=this;e._duplicateContent({top:"100%",opacity:0});e.transitionByFilter="css"},_bounceBottomFilter:function(e,t,n){var r=this,i,s,o;r.$obj.addClass("cbp-no-transition");if(r.ulHidden==="clone"){r.ulHidden="first";i=r.$ulClone;o=r.$ul;s=r.blocksClone}else{r.ulHidden="clone";i=r.$ul;o=r.$ulClone;s=r.blocks}t=s.filter(".cbp-item-hidden");if(n!=="*"){t=t.filter(n);s.not(".cbp-item-hidden").not(n).addClass("cbp-item-hidden")}t.removeClass("cbp-item-hidden");r.blocksAvailable=s.filter(n);r._layout();o[r.transition]({top:"100%",opacity:0}).removeClass("cbp-wrapper-front").addClass("cbp-wrapper-back");i[r.transition]({top:0,opacity:1}).addClass("cbp-wrapper-front").removeClass("cbp-wrapper-back");r._processStyle(r.transitionByFilter);r._resizeMainContainer(r.transition);setTimeout(function(){r._filterFinish()},400)},_moveLeftInit:function(){var e=this;e._duplicateContent({left:"100%",opacity:0});e.$ulClone.addClass("no-trans");e.transitionByFilter="css"},_moveLeftFilter:function(e,t,n){var r=this,i,s,o;if(n!=="*"){t=t.filter(n);e=r.blocks.not(".cbp-item-hidden").not(n).addClass("cbp-item-hidden")}t.removeClass("cbp-item-hidden");r.$obj.addClass("cbp-no-transition");if(r.ulHidden==="clone"){r.ulHidden="first";i=r.$ulClone;o=r.$ul;s=r.blocksClone}else{r.ulHidden="clone";i=r.$ul;o=r.$ulClone;s=r.blocks}s.css("opacity",0);s.addClass("cbp-item-hidden");r.blocksAvailable=s.filter(n);r.blocksAvailable.css("opacity",1);r.blocksAvailable.removeClass("cbp-item-hidden");r._layout();o[r.transition]({left:"-100%",opacity:0});i.removeClass("no-trans");if(r.transition==="css"){i[r.transition]({left:0,opacity:1});o.one(r.transitionEnd,function(){o.addClass("no-trans").css({left:"100%",opacity:0});r._filterFinish()})}else{i[r.transition]({left:0,opacity:1},function(){o.addClass("no-trans").css({left:"100%",opacity:0});r._filterFinish()})}r._processStyle(r.transitionByFilter);r._resizeMainContainer(r.transition)},_slideLeftInit:function(){var e=this;e._duplicateContent({});e.$ul.addClass("cbp-wrapper-front");e.$ulClone.css("opacity",0);e.transitionByFilter="css"},_slideLeftFilter:function(e,t,n){var r=this,i,s,o,u,a,f;r.blocks.show();r.blocksClone.show();if(n!=="*"){t=t.filter(n);e=r.blocks.not(".cbp-item-hidden").not(n).addClass("cbp-item-hidden")}t.removeClass("cbp-item-hidden");r.$obj.addClass("cbp-no-transition");r.blocks.find(".cbp-item-wrapper").removeClass("cbp-animation-slideLeft-out cbp-animation-slideLeft-in");r.blocksClone.find(".cbp-item-wrapper").removeClass("cbp-animation-slideLeft-out cbp-animation-slideLeft-in");r.$ul.css({opacity:1});r.$ulClone.css({opacity:1});if(r.ulHidden==="clone"){r.ulHidden="first";u=r.blocks;a=r.blocksClone;s=r.blocksClone;r.$ul.removeClass("cbp-wrapper-front");r.$ulClone.addClass("cbp-wrapper-front")}else{r.ulHidden="clone";u=r.blocksClone;a=r.blocks;s=r.blocks;r.$ul.addClass("cbp-wrapper-front");r.$ulClone.removeClass("cbp-wrapper-front")}s.css("opacity",0);s.addClass("cbp-item-hidden");r.blocksAvailable=s.filter(n);r.blocksAvailable.css({opacity:1});r.blocksAvailable.removeClass("cbp-item-hidden");r._layout();if(r.transition==="css"){u.find(".cbp-item-wrapper").addClass("cbp-animation-slideLeft-out");a.find(".cbp-item-wrapper").addClass("cbp-animation-slideLeft-in");f=u.find(".cbp-item-wrapper").last();if(f.length){f.one(r.animationEnd,function(){r._filterFinish()})}else{r._filterFinish()}}else{u.find(".cbp-item-wrapper").animate({left:"-100%"},400,function(){r._filterFinish()});a.find(".cbp-item-wrapper").css("left","100%");a.find(".cbp-item-wrapper").animate({left:0},400)}r._processStyle(r.transitionByFilter);r._resizeMainContainer("animate")},_slideDelayInit:function(){this._wrapperFilterInit()},_slideDelayFilter:function(e,t,n){this._wrapperFilter(e,t,n,"slideDelay",true)},_3dflipInit:function(){this._wrapperFilterInit()},_3dflipFilter:function(e,t,n){this._wrapperFilter(e,t,n,"3dflip",true)},_rotateSidesInit:function(){this._wrapperFilterInit()},_rotateSidesFilter:function(e,t,n){this._wrapperFilter(e,t,n,"rotateSides",true)},_flipOutDelayInit:function(){this._wrapperFilterInit()},_flipOutDelayFilter:function(e,t,n){this._wrapperFilter(e,t,n,"flipOutDelay",false)},_foldLeftInit:function(){this._wrapperFilterInit()},_foldLeftFilter:function(e,t,n){this._wrapperFilter(e,t,n,"foldLeft",true)},_unfoldInit:function(){this._wrapperFilterInit()},_unfoldFilter:function(e,t,n){this._wrapperFilter(e,t,n,"unfold",true)},_scaleDownInit:function(){this._wrapperFilterInit()},_scaleDownFilter:function(e,t,n){this._wrapperFilter(e,t,n,"scaleDown",true)},_frontRowInit:function(){this._wrapperFilterInit()},_frontRowFilter:function(e,t,n){this._wrapperFilter(e,t,n,"frontRow",true)},_rotateRoomInit:function(){this._wrapperFilterInit()},_rotateRoomFilter:function(e,t,n){this._wrapperFilter(e,t,n,"rotateRoom",true)},_wrapperFilterInit:function(){var e=this;e._duplicateContent({});e.$ul.addClass("cbp-wrapper-front");e.$ulClone.css("opacity",0);e.transitionByFilter="css"},_wrapperFilter:function(t,n,r,i,s){var o=this,u,a,f,l,c,h;o.blocks.show();o.blocksClone.show();if(r!=="*"){n=n.filter(r);t=o.blocks.not(".cbp-item-hidden").not(r).addClass("cbp-item-hidden")}n.removeClass("cbp-item-hidden");o.$obj.addClass("cbp-no-transition");o.blocks.find(".cbp-item-wrapper").removeClass("cbp-animation-"+i+"-out cbp-animation-"+i+"-in cbp-animation-"+i+"-fadeOut").css("style","");o.blocksClone.find(".cbp-item-wrapper").removeClass("cbp-animation-"+i+"-out cbp-animation-"+i+"-in cbp-animation-"+i+"-fadeOut").css("style","");o.$ul.css({opacity:1});o.$ulClone.css({opacity:1});if(o.ulHidden==="clone"){o.ulHidden="first";l=o.blocks;c=o.blocksClone;a=o.blocksClone;o.$ul.removeClass("cbp-wrapper-front");o.$ulClone.addClass("cbp-wrapper-front")}else{o.ulHidden="clone";l=o.blocksClone;c=o.blocks;a=o.blocks;o.$ul.addClass("cbp-wrapper-front");o.$ulClone.removeClass("cbp-wrapper-front")}l=o.blocksAvailable;a.css("opacity",0);a.addClass("cbp-item-hidden");o.blocksAvailable=a.filter(r);o.blocksAvailable.css({opacity:1});o.blocksAvailable.removeClass("cbp-item-hidden");c=o.blocksAvailable;o._layout();if(o.transition==="css"){var p=0,d=0;c.each(function(t,n){e(n).find(".cbp-item-wrapper").addClass("cbp-animation-"+i+"-in").css("animation-delay",d/20+"s");d++});l.each(function(t,n){if(d<=p&&s){e(n).find(".cbp-item-wrapper").addClass("cbp-animation-"+i+"-fadeOut")}else{e(n).find(".cbp-item-wrapper").addClass("cbp-animation-"+i+"-out").css("animation-delay",p/20+"s")}p++});h=l.find(".cbp-item-wrapper").first();if(h.length){h.one(o.animationEnd,function(){o._filterFinish()})}else{o._filterFinish()}}else{l.find(".cbp-item-wrapper").animate({left:"-100%"},400,function(){o._filterFinish()});c.find(".cbp-item-wrapper").css("left","100%");c.find(".cbp-item-wrapper").animate({left:0},400)}o._processStyle(o.transitionByFilter);o._resizeMainContainer("animate")},_filterFinish:function(){var e=this;e.isAnimating=false;e._triggerEvent("filterFinish");e.$obj.trigger("filterComplete")},_registerEvent:function(e,t,n){var r=this;if(!r.registeredEvents[e]){r.registeredEvents[e]=[];r.registeredEvents.push(e)}r.registeredEvents[e].push({func:t,oneTime:n||false})},_triggerEvent:function(e){var t=this;if(t.registeredEvents[e]){for(var n=t.registeredEvents[e].length-1;n>=0;n--){t.registeredEvents[e][n].func.call(t);if(t.registeredEvents[e][n].oneTime){t.registeredEvents[e].splice(n,1)}}}},init:function(t,n){var r=e.data(this,"cubeportfolio");if(r){throw new Error("cubeportfolio is already initialized. Please destroy it before initialize again!")}r=e.data(this,"cubeportfolio",Object.create(u));r._main(this,t,n)},destroy:function(n){var r=e.data(this,"cubeportfolio");if(!r){throw new Error("cubeportfolio is not initialized. Please initialize before calling destroy method!")}if(e.isFunction(n)){r._registerEvent("destroyFinish",n,true)}e.removeData(this,"cubeportfolio");e.each(r.blocks,function(t,n){e.removeData(this,"transformFn");e.removeData(this,"cbp-wxh")});r.$obj.removeClass("cbp cbp-loading cbp-ready cbp-no-transition");r.$ul.removeClass("cbp-wrapper-front cbp-wrapper-back cbp-wrapper no-trans").removeAttr("style");r.$obj.removeAttr("style");if(r.$ulClone){r.$ulClone.remove()}if(r.browser){r.$obj.removeClass("cbp-"+r.browser)}e(t).off("resize"+s);if(r.lightbox){r.lightbox.destroy()}if(r.singlePage){r.singlePage.destroy()}if(r.singlePageInline){r.singlePageInline.destroy()}r.blocks.removeClass("cbp-item-hidden").removeAttr("style");r.blocks.find(".cbp-item-wrapper").children().unwrap();if(r.options.caption){r._captionDestroy()}if(r.options.animationType){if(r.options.animationType==="boxShadow"){e(".cbp-animation-boxShadowMask").remove()}r.$obj.removeClass("cbp-animation-"+r.options.animationType)}r._triggerEvent("destroyFinish")},filter:function(t,n){var r=e.data(this,"cubeportfolio"),i,s;if(!r){throw new Error("cubeportfolio is not initialized. Please initialize before calling filter method!")}t=t==="*"||t===""?"*":t;if(r.isAnimating||r.defaultFilter==t){return}if(r.browser==="ie8"||r.browser==="ie9"){r.$obj.removeClass("cbp-no-transition cbp-appendItems-loading")}else{r.obj.classList.remove("cbp-no-transition");r.obj.classList.remove("cbp-appendItems-loading")}r.defaultFilter=t;r.isAnimating=true;if(e.isFunction(n)){r._registerEvent("filterFinish",n,true)}i=r.blocks.filter(".cbp-item-hidden");s=[];if(r.singlePageInline&&r.singlePageInline.isOpen){r.singlePageInline.close("promise",{callback:function(){r["_"+r.options.animationType+"Filter"](s,i,t)}})}else{r["_"+r.options.animationType+"Filter"](s,i,t)}},showCounter:function(t){var n=e.data(this,"cubeportfolio");if(!n){throw new Error("cubeportfolio is not initialized. Please initialize before calling showCounter method!")}n.elems=t;e.each(t,function(t,r){var i=e(this),s=i.data("filter"),o=0;s=s==="*"||s===""?"*":s;o=n.blocks.filter(s).length;i.find(".cbp-filter-counter").text(o)})},appendItems:function(t,n){var r=this,i=e.data(r,"cubeportfolio"),s,o,a,f;if(!i){throw new Error("cubeportfolio is not initialized. Please initialize before calling appendItems method!")}if(i.singlePageInline&&i.singlePageInline.isOpen){i.singlePageInline.close("promise",{callback:function(){u._addItems.call(r,t,n)}})}else{u._addItems.call(r,t,n)}},_addItems:function(t,n){var r=e.data(this,"cubeportfolio"),i,s,o,a;if(e.isFunction(n)){r._registerEvent("appendItemsFinish",n,true)}r.$obj.addClass("cbp-no-transition cbp-appendItems-loading");t=e(t).css("opacity",0);t.filter(".cbp-item").wrapInner('
      ');a=t.filter(r.defaultFilter);if(r.ulHidden){if(r.ulHidden==="first"){t.appendTo(r.$ulClone);r.blocksClone=r.$ulClone.children();s=r.blocksClone;o=t.clone();o.appendTo(r.$ul);r.blocks=r.$ul.children()}else{t.appendTo(r.$ul);r.blocks=r.$ul.children();s=r.blocks;o=t.clone();o.appendTo(r.$ulClone);r.blocksClone=r.$ulClone.children()}}else{t.appendTo(r.$ul);r.blocks=r.$ul.children();s=r.blocks}if(r.options.caption){r._captionDestroy();r._captionInit()}i=r.defaultFilter;r.blocksAvailable=s.filter(i);s.not(".cbp-item-hidden").not(i).addClass("cbp-item-hidden");if(r.options.gridAdjustment==="responsive"){r._responsiveLayout()}r._layout();r._processStyle(r.transitionByFilter);r._resizeMainContainer("animate");a.animate({opacity:1},800,function(){switch(r.options.animationType){case"bounceLeft":case"bounceTop":case"bounceBottom":r.blocks.css("opacity",1);r.blocksClone.css("opacity",1);break}});if(r.elems){u.showCounter.call(this,r.elems)}setTimeout(function(){r._triggerEvent("appendItemsFinish")},900)}};e.fn.cubeportfolio=function(e){var t=arguments;return this.each(function(){if(u[e]){return u[e].apply(this,Array.prototype.slice.call(t,1))}else if(typeof e==="object"||!e){return u.init.apply(this,t)}else{throw new Error("Method "+e+" does not exist on jQuery.cubeportfolio.js")}})};e.fn.cubeportfolio.options={animationType:"fadeOut",gridAdjustment:"default",gapHorizontal:10,gapVertical:10,caption:"pushTop",displayType:"default",displayTypeSpeed:400,lightboxDelegate:".cbp-lightbox",lightboxGallery:true,lightboxTitleSrc:"data-title",lightboxShowCounter:true,singlePageDelegate:".cbp-singlePage",singlePageDeeplinking:true,singlePageStickyNavigation:true,singlePageShowCounter:true,singlePageCallback:function(e,t){},singlePageInlineDelegate:".cbp-singlePageInline",singlePageInlinePosition:"top",singlePageInlineCallback:function(e,t){}}})(jQuery,window,document) diff --git a/Webseiten/Docker - Build, Ship, and Run Any App, Anywhere_files/jquery.flexslider.js b/Webseiten/Docker - Build, Ship, and Run Any App, Anywhere_files/jquery.flexslider.js new file mode 100644 index 0000000..1184d86 --- /dev/null +++ b/Webseiten/Docker - Build, Ship, and Run Any App, Anywhere_files/jquery.flexslider.js @@ -0,0 +1,1191 @@ +/* + * jQuery FlexSlider v2.5.0 + * Copyright 2012 WooThemes + * Contributing Author: Tyler Smith + */ +; +(function ($) { + + //FlexSlider: Object Instance + $.flexslider = function(el, options) { + var slider = $(el); + + // making variables public + slider.vars = $.extend({}, $.flexslider.defaults, options); + + var namespace = slider.vars.namespace, + msGesture = window.navigator && window.navigator.msPointerEnabled && window.MSGesture, + touch = (( "ontouchstart" in window ) || msGesture || window.DocumentTouch && document instanceof DocumentTouch) && slider.vars.touch, + // depricating this idea, as devices are being released with both of these events + //eventType = (touch) ? "touchend" : "click", + eventType = "click touchend MSPointerUp keyup", + watchedEvent = "", + watchedEventClearTimer, + vertical = slider.vars.direction === "vertical", + reverse = slider.vars.reverse, + carousel = (slider.vars.itemWidth > 0), + fade = slider.vars.animation === "fade", + asNav = slider.vars.asNavFor !== "", + methods = {}, + focused = true; + + // Store a reference to the slider object + $.data(el, "flexslider", slider); + + // Private slider methods + methods = { + init: function() { + slider.animating = false; + // Get current slide and make sure it is a number + slider.currentSlide = parseInt( ( slider.vars.startAt ? slider.vars.startAt : 0), 10 ); + if ( isNaN( slider.currentSlide ) ) { slider.currentSlide = 0; } + slider.animatingTo = slider.currentSlide; + slider.atEnd = (slider.currentSlide === 0 || slider.currentSlide === slider.last); + slider.containerSelector = slider.vars.selector.substr(0,slider.vars.selector.search(' ')); + slider.slides = $(slider.vars.selector, slider); + slider.container = $(slider.containerSelector, slider); + slider.count = slider.slides.length; + // SYNC: + slider.syncExists = $(slider.vars.sync).length > 0; + // SLIDE: + if (slider.vars.animation === "slide") { slider.vars.animation = "swing"; } + slider.prop = (vertical) ? "top" : "marginLeft"; + slider.args = {}; + // SLIDESHOW: + slider.manualPause = false; + slider.stopped = false; + //PAUSE WHEN INVISIBLE + slider.started = false; + slider.startTimeout = null; + // TOUCH/USECSS: + slider.transitions = !slider.vars.video && !fade && slider.vars.useCSS && (function() { + var obj = document.createElement('div'), + props = ['perspectiveProperty', 'WebkitPerspective', 'MozPerspective', 'OPerspective', 'msPerspective']; + for (var i in props) { + if ( obj.style[ props[i] ] !== undefined ) { + slider.pfx = props[i].replace('Perspective','').toLowerCase(); + slider.prop = "-" + slider.pfx + "-transform"; + return true; + } + } + return false; + }()); + slider.ensureAnimationEnd = ''; + // CONTROLSCONTAINER: + if (slider.vars.controlsContainer !== "") slider.controlsContainer = $(slider.vars.controlsContainer).length > 0 && $(slider.vars.controlsContainer); + // MANUAL: + if (slider.vars.manualControls !== "") slider.manualControls = $(slider.vars.manualControls).length > 0 && $(slider.vars.manualControls); + + // CUSTOM DIRECTION NAV: + if (slider.vars.customDirectionNav !== "") slider.customDirectionNav = $(slider.vars.customDirectionNav).length === 2 && $(slider.vars.customDirectionNav); + + // RANDOMIZE: + if (slider.vars.randomize) { + slider.slides.sort(function() { return (Math.round(Math.random())-0.5); }); + slider.container.empty().append(slider.slides); + } + + slider.doMath(); + + // INIT + slider.setup("init"); + + // CONTROLNAV: + if (slider.vars.controlNav) { methods.controlNav.setup(); } + + // DIRECTIONNAV: + if (slider.vars.directionNav) { methods.directionNav.setup(); } + + // KEYBOARD: + if (slider.vars.keyboard && ($(slider.containerSelector).length === 1 || slider.vars.multipleKeyboard)) { + $(document).bind('keyup', function(event) { + var keycode = event.keyCode; + if (!slider.animating && (keycode === 39 || keycode === 37)) { + var target = (keycode === 39) ? slider.getTarget('next') : + (keycode === 37) ? slider.getTarget('prev') : false; + slider.flexAnimate(target, slider.vars.pauseOnAction); + } + }); + } + // MOUSEWHEEL: + if (slider.vars.mousewheel) { + slider.bind('mousewheel', function(event, delta, deltaX, deltaY) { + event.preventDefault(); + var target = (delta < 0) ? slider.getTarget('next') : slider.getTarget('prev'); + slider.flexAnimate(target, slider.vars.pauseOnAction); + }); + } + + // PAUSEPLAY + if (slider.vars.pausePlay) { methods.pausePlay.setup(); } + + //PAUSE WHEN INVISIBLE + if (slider.vars.slideshow && slider.vars.pauseInvisible) { methods.pauseInvisible.init(); } + + // SLIDSESHOW + if (slider.vars.slideshow) { + if (slider.vars.pauseOnHover) { + slider.hover(function() { + if (!slider.manualPlay && !slider.manualPause) { slider.pause(); } + }, function() { + if (!slider.manualPause && !slider.manualPlay && !slider.stopped) { slider.play(); } + }); + } + // initialize animation + //If we're visible, or we don't use PageVisibility API + if(!slider.vars.pauseInvisible || !methods.pauseInvisible.isHidden()) { + (slider.vars.initDelay > 0) ? slider.startTimeout = setTimeout(slider.play, slider.vars.initDelay) : slider.play(); + } + } + + // ASNAV: + if (asNav) { methods.asNav.setup(); } + + // TOUCH + if (touch && slider.vars.touch) { methods.touch(); } + + // FADE&&SMOOTHHEIGHT || SLIDE: + if (!fade || (fade && slider.vars.smoothHeight)) { $(window).bind("resize orientationchange focus", methods.resize); } + + slider.find("img").attr("draggable", "false"); + + // API: start() Callback + setTimeout(function(){ + slider.vars.start(slider); + }, 200); + }, + asNav: { + setup: function() { + slider.asNav = true; + slider.animatingTo = Math.floor(slider.currentSlide/slider.move); + slider.currentItem = slider.currentSlide; + slider.slides.removeClass(namespace + "active-slide").eq(slider.currentItem).addClass(namespace + "active-slide"); + if(!msGesture){ + slider.slides.on(eventType, function(e){ + e.preventDefault(); + var $slide = $(this), + target = $slide.index(); + var posFromLeft = $slide.offset().left - $(slider).scrollLeft(); // Find position of slide relative to left of slider container + if( posFromLeft <= 0 && $slide.hasClass( namespace + 'active-slide' ) ) { + slider.flexAnimate(slider.getTarget("prev"), true); + } else if (!$(slider.vars.asNavFor).data('flexslider').animating && !$slide.hasClass(namespace + "active-slide")) { + slider.direction = (slider.currentItem < target) ? "next" : "prev"; + slider.flexAnimate(target, slider.vars.pauseOnAction, false, true, true); + } + }); + }else{ + el._slider = slider; + slider.slides.each(function (){ + var that = this; + that._gesture = new MSGesture(); + that._gesture.target = that; + that.addEventListener("MSPointerDown", function (e){ + e.preventDefault(); + if(e.currentTarget._gesture) { + e.currentTarget._gesture.addPointer(e.pointerId); + } + }, false); + that.addEventListener("MSGestureTap", function (e){ + e.preventDefault(); + var $slide = $(this), + target = $slide.index(); + if (!$(slider.vars.asNavFor).data('flexslider').animating && !$slide.hasClass('active')) { + slider.direction = (slider.currentItem < target) ? "next" : "prev"; + slider.flexAnimate(target, slider.vars.pauseOnAction, false, true, true); + } + }); + }); + } + } + }, + controlNav: { + setup: function() { + if (!slider.manualControls) { + methods.controlNav.setupPaging(); + } else { // MANUALCONTROLS: + methods.controlNav.setupManual(); + } + }, + setupPaging: function() { + var type = (slider.vars.controlNav === "thumbnails") ? 'control-thumbs' : 'control-paging', + j = 1, + item, + slide; + + slider.controlNavScaffold = $('
        '); + + if (slider.pagingCount > 1) { + for (var i = 0; i < slider.pagingCount; i++) { + slide = slider.slides.eq(i); + item = (slider.vars.controlNav === "thumbnails") ? '' : '        ' + j + ''; + if ( 'thumbnails' === slider.vars.controlNav && true === slider.vars.thumbCaptions ) { + var captn = slide.attr( 'data-thumbcaption' ); + if ( '' !== captn && undefined !== captn ) { item += '' + captn + ''; } + } + slider.controlNavScaffold.append('
      1. ' + item + '
        2. '); + j++; + } + } + + // CONTROLSCONTAINER: + (slider.controlsContainer) ? $(slider.controlsContainer).append(slider.controlNavScaffold) : slider.append(slider.controlNavScaffold); + methods.controlNav.set(); + + methods.controlNav.active(); + + slider.controlNavScaffold.delegate('a, img', eventType, function(event) { + event.preventDefault(); + + if (watchedEvent === "" || watchedEvent === event.type) { + var $this = $(this), + target = slider.controlNav.index($this); + + if (!$this.hasClass(namespace + 'active')) { + slider.direction = (target > slider.currentSlide) ? "next" : "prev"; + slider.flexAnimate(target, slider.vars.pauseOnAction); + } + } + + // setup flags to prevent event duplication + if (watchedEvent === "") { + watchedEvent = event.type; + } + methods.setToClearWatchedEvent(); + + }); + }, + setupManual: function() { + slider.controlNav = slider.manualControls; + methods.controlNav.active(); + + slider.controlNav.bind(eventType, function(event) { + event.preventDefault(); + + if (watchedEvent === "" || watchedEvent === event.type) { + var $this = $(this), + target = slider.controlNav.index($this); + + if (!$this.hasClass(namespace + 'active')) { + (target > slider.currentSlide) ? slider.direction = "next" : slider.direction = "prev"; + slider.flexAnimate(target, slider.vars.pauseOnAction); + } + } + + // setup flags to prevent event duplication + if (watchedEvent === "") { + watchedEvent = event.type; + } + methods.setToClearWatchedEvent(); + }); + }, + set: function() { + var selector = (slider.vars.controlNav === "thumbnails") ? 'img' : 'a'; + slider.controlNav = $('.' + namespace + 'control-nav li ' + selector, (slider.controlsContainer) ? slider.controlsContainer : slider); + }, + active: function() { + slider.controlNav.removeClass(namespace + "active").eq(slider.animatingTo).addClass(namespace + "active"); + }, + update: function(action, pos) { + if (slider.pagingCount > 1 && action === "add") { + slider.controlNavScaffold.append($('
      2. ' + slider.count + '
        3. ')); + } else if (slider.pagingCount === 1) { + slider.controlNavScaffold.find('li').remove(); + } else { + slider.controlNav.eq(pos).closest('li').remove(); + } + methods.controlNav.set(); + (slider.pagingCount > 1 && slider.pagingCount !== slider.controlNav.length) ? slider.update(pos, action) : methods.controlNav.active(); + } + }, + directionNav: { + setup: function() { + var directionNavScaffold = $(''); + + // CUSTOM DIRECTION NAV: + if (slider.customDirectionNav) { + slider.directionNav = slider.customDirectionNav; + // CONTROLSCONTAINER: + } else if (slider.controlsContainer) { + $(slider.controlsContainer).append(directionNavScaffold); + slider.directionNav = $('.' + namespace + 'direction-nav li a', slider.controlsContainer); + } else { + slider.append(directionNavScaffold); + slider.directionNav = $('.' + namespace + 'direction-nav li a', slider); + } + + methods.directionNav.update(); + + slider.directionNav.bind(eventType, function(event) { + event.preventDefault(); + var target; + + if (watchedEvent === "" || watchedEvent === event.type) { + target = ($(this).hasClass(namespace + 'next')) ? slider.getTarget('next') : slider.getTarget('prev'); + slider.flexAnimate(target, slider.vars.pauseOnAction); + } + + // setup flags to prevent event duplication + if (watchedEvent === "") { + watchedEvent = event.type; + } + methods.setToClearWatchedEvent(); + }); + }, + update: function() { + var disabledClass = namespace + 'disabled'; + if (slider.pagingCount === 1) { + slider.directionNav.addClass(disabledClass).attr('tabindex', '-1'); + } else if (!slider.vars.animationLoop) { + if (slider.animatingTo === 0) { + slider.directionNav.removeClass(disabledClass).filter('.' + namespace + "prev").addClass(disabledClass).attr('tabindex', '-1'); + } else if (slider.animatingTo === slider.last) { + slider.directionNav.removeClass(disabledClass).filter('.' + namespace + "next").addClass(disabledClass).attr('tabindex', '-1'); + } else { + slider.directionNav.removeClass(disabledClass).removeAttr('tabindex'); + } + } else { + slider.directionNav.removeClass(disabledClass).removeAttr('tabindex'); + } + } + }, + pausePlay: { + setup: function() { + var pausePlayScaffold = $('
        '); + + // CONTROLSCONTAINER: + if (slider.controlsContainer) { + slider.controlsContainer.append(pausePlayScaffold); + slider.pausePlay = $('.' + namespace + 'pauseplay a', slider.controlsContainer); + } else { + slider.append(pausePlayScaffold); + slider.pausePlay = $('.' + namespace + 'pauseplay a', slider); + } + + methods.pausePlay.update((slider.vars.slideshow) ? namespace + 'pause' : namespace + 'play'); + + slider.pausePlay.bind(eventType, function(event) { + event.preventDefault(); + + if (watchedEvent === "" || watchedEvent === event.type) { + if ($(this).hasClass(namespace + 'pause')) { + slider.manualPause = true; + slider.manualPlay = false; + slider.pause(); + } else { + slider.manualPause = false; + slider.manualPlay = true; + slider.play(); + } + } + + // setup flags to prevent event duplication + if (watchedEvent === "") { + watchedEvent = event.type; + } + methods.setToClearWatchedEvent(); + }); + }, + update: function(state) { + (state === "play") ? slider.pausePlay.removeClass(namespace + 'pause').addClass(namespace + 'play').html(slider.vars.playText) : slider.pausePlay.removeClass(namespace + 'play').addClass(namespace + 'pause').html(slider.vars.pauseText); + } + }, + touch: function() { + var startX, + startY, + offset, + cwidth, + dx, + startT, + onTouchStart, + onTouchMove, + onTouchEnd, + scrolling = false, + localX = 0, + localY = 0, + accDx = 0; + + if(!msGesture){ + onTouchStart = function(e) { + if (slider.animating) { + e.preventDefault(); + } else if ( ( window.navigator.msPointerEnabled ) || e.touches.length === 1 ) { + slider.pause(); + // CAROUSEL: + cwidth = (vertical) ? slider.h : slider. w; + startT = Number(new Date()); + // CAROUSEL: + + // Local vars for X and Y points. + localX = e.touches[0].pageX; + localY = e.touches[0].pageY; + + offset = (carousel && reverse && slider.animatingTo === slider.last) ? 0 : + (carousel && reverse) ? slider.limit - (((slider.itemW + slider.vars.itemMargin) * slider.move) * slider.animatingTo) : + (carousel && slider.currentSlide === slider.last) ? slider.limit : + (carousel) ? ((slider.itemW + slider.vars.itemMargin) * slider.move) * slider.currentSlide : + (reverse) ? (slider.last - slider.currentSlide + slider.cloneOffset) * cwidth : (slider.currentSlide + slider.cloneOffset) * cwidth; + startX = (vertical) ? localY : localX; + startY = (vertical) ? localX : localY; + + el.addEventListener('touchmove', onTouchMove, false); + el.addEventListener('touchend', onTouchEnd, false); + } + }; + + onTouchMove = function(e) { + // Local vars for X and Y points. + + localX = e.touches[0].pageX; + localY = e.touches[0].pageY; + + dx = (vertical) ? startX - localY : startX - localX; + scrolling = (vertical) ? (Math.abs(dx) < Math.abs(localX - startY)) : (Math.abs(dx) < Math.abs(localY - startY)); + + var fxms = 500; + + if ( ! scrolling || Number( new Date() ) - startT > fxms ) { + e.preventDefault(); + if (!fade && slider.transitions) { + if (!slider.vars.animationLoop) { + dx = dx/((slider.currentSlide === 0 && dx < 0 || slider.currentSlide === slider.last && dx > 0) ? (Math.abs(dx)/cwidth+2) : 1); + } + slider.setProps(offset + dx, "setTouch"); + } + } + }; + + onTouchEnd = function(e) { + // finish the touch by undoing the touch session + el.removeEventListener('touchmove', onTouchMove, false); + + if (slider.animatingTo === slider.currentSlide && !scrolling && !(dx === null)) { + var updateDx = (reverse) ? -dx : dx, + target = (updateDx > 0) ? slider.getTarget('next') : slider.getTarget('prev'); + + if (slider.canAdvance(target) && (Number(new Date()) - startT < 550 && Math.abs(updateDx) > 50 || Math.abs(updateDx) > cwidth/2)) { + slider.flexAnimate(target, slider.vars.pauseOnAction); + } else { + if (!fade) { slider.flexAnimate(slider.currentSlide, slider.vars.pauseOnAction, true); } + } + } + el.removeEventListener('touchend', onTouchEnd, false); + + startX = null; + startY = null; + dx = null; + offset = null; + }; + + el.addEventListener('touchstart', onTouchStart, false); + }else{ + el.style.msTouchAction = "none"; + el._gesture = new MSGesture(); + el._gesture.target = el; + el.addEventListener("MSPointerDown", onMSPointerDown, false); + el._slider = slider; + el.addEventListener("MSGestureChange", onMSGestureChange, false); + el.addEventListener("MSGestureEnd", onMSGestureEnd, false); + + function onMSPointerDown(e){ + e.stopPropagation(); + if (slider.animating) { + e.preventDefault(); + }else{ + slider.pause(); + el._gesture.addPointer(e.pointerId); + accDx = 0; + cwidth = (vertical) ? slider.h : slider. w; + startT = Number(new Date()); + // CAROUSEL: + + offset = (carousel && reverse && slider.animatingTo === slider.last) ? 0 : + (carousel && reverse) ? slider.limit - (((slider.itemW + slider.vars.itemMargin) * slider.move) * slider.animatingTo) : + (carousel && slider.currentSlide === slider.last) ? slider.limit : + (carousel) ? ((slider.itemW + slider.vars.itemMargin) * slider.move) * slider.currentSlide : + (reverse) ? (slider.last - slider.currentSlide + slider.cloneOffset) * cwidth : (slider.currentSlide + slider.cloneOffset) * cwidth; + } + } + + function onMSGestureChange(e) { + e.stopPropagation(); + var slider = e.target._slider; + if(!slider){ + return; + } + var transX = -e.translationX, + transY = -e.translationY; + + //Accumulate translations. + accDx = accDx + ((vertical) ? transY : transX); + dx = accDx; + scrolling = (vertical) ? (Math.abs(accDx) < Math.abs(-transX)) : (Math.abs(accDx) < Math.abs(-transY)); + + if(e.detail === e.MSGESTURE_FLAG_INERTIA){ + setImmediate(function (){ + el._gesture.stop(); + }); + + return; + } + + if (!scrolling || Number(new Date()) - startT > 500) { + e.preventDefault(); + if (!fade && slider.transitions) { + if (!slider.vars.animationLoop) { + dx = accDx / ((slider.currentSlide === 0 && accDx < 0 || slider.currentSlide === slider.last && accDx > 0) ? (Math.abs(accDx) / cwidth + 2) : 1); + } + slider.setProps(offset + dx, "setTouch"); + } + } + } + + function onMSGestureEnd(e) { + e.stopPropagation(); + var slider = e.target._slider; + if(!slider){ + return; + } + if (slider.animatingTo === slider.currentSlide && !scrolling && !(dx === null)) { + var updateDx = (reverse) ? -dx : dx, + target = (updateDx > 0) ? slider.getTarget('next') : slider.getTarget('prev'); + + if (slider.canAdvance(target) && (Number(new Date()) - startT < 550 && Math.abs(updateDx) > 50 || Math.abs(updateDx) > cwidth/2)) { + slider.flexAnimate(target, slider.vars.pauseOnAction); + } else { + if (!fade) { slider.flexAnimate(slider.currentSlide, slider.vars.pauseOnAction, true); } + } + } + + startX = null; + startY = null; + dx = null; + offset = null; + accDx = 0; + } + } + }, + resize: function() { + if (!slider.animating && slider.is(':visible')) { + if (!carousel) { slider.doMath(); } + + if (fade) { + // SMOOTH HEIGHT: + methods.smoothHeight(); + } else if (carousel) { //CAROUSEL: + slider.slides.width(slider.computedW); + slider.update(slider.pagingCount); + slider.setProps(); + } + else if (vertical) { //VERTICAL: + slider.viewport.height(slider.h); + slider.setProps(slider.h, "setTotal"); + } else { + // SMOOTH HEIGHT: + if (slider.vars.smoothHeight) { methods.smoothHeight(); } + slider.newSlides.width(slider.computedW); + slider.setProps(slider.computedW, "setTotal"); + } + } + }, + smoothHeight: function(dur) { + if (!vertical || fade) { + var $obj = (fade) ? slider : slider.viewport; + (dur) ? $obj.animate({"height": slider.slides.eq(slider.animatingTo).height()}, dur) : $obj.height(slider.slides.eq(slider.animatingTo).height()); + } + }, + sync: function(action) { + var $obj = $(slider.vars.sync).data("flexslider"), + target = slider.animatingTo; + + switch (action) { + case "animate": $obj.flexAnimate(target, slider.vars.pauseOnAction, false, true); break; + case "play": if (!$obj.playing && !$obj.asNav) { $obj.play(); } break; + case "pause": $obj.pause(); break; + } + }, + uniqueID: function($clone) { + // Append _clone to current level and children elements with id attributes + $clone.filter( '[id]' ).add($clone.find( '[id]' )).each(function() { + var $this = $(this); + $this.attr( 'id', $this.attr( 'id' ) + '_clone' ); + }); + return $clone; + }, + pauseInvisible: { + visProp: null, + init: function() { + var visProp = methods.pauseInvisible.getHiddenProp(); + if (visProp) { + var evtname = visProp.replace(/[H|h]idden/,'') + 'visibilitychange'; + document.addEventListener(evtname, function() { + if (methods.pauseInvisible.isHidden()) { + if(slider.startTimeout) { + clearTimeout(slider.startTimeout); //If clock is ticking, stop timer and prevent from starting while invisible + } else { + slider.pause(); //Or just pause + } + } + else { + if(slider.started) { + slider.play(); //Initiated before, just play + } else { + if (slider.vars.initDelay > 0) { + setTimeout(slider.play, slider.vars.initDelay); + } else { + slider.play(); //Didn't init before: simply init or wait for it + } + } + } + }); + } + }, + isHidden: function() { + var prop = methods.pauseInvisible.getHiddenProp(); + if (!prop) { + return false; + } + return document[prop]; + }, + getHiddenProp: function() { + var prefixes = ['webkit','moz','ms','o']; + // if 'hidden' is natively supported just return it + if ('hidden' in document) { + return 'hidden'; + } + // otherwise loop over all the known prefixes until we find one + for ( var i = 0; i < prefixes.length; i++ ) { + if ((prefixes[i] + 'Hidden') in document) { + return prefixes[i] + 'Hidden'; + } + } + // otherwise it's not supported + return null; + } + }, + setToClearWatchedEvent: function() { + clearTimeout(watchedEventClearTimer); + watchedEventClearTimer = setTimeout(function() { + watchedEvent = ""; + }, 3000); + } + }; + + // public methods + slider.flexAnimate = function(target, pause, override, withSync, fromNav) { + if (!slider.vars.animationLoop && target !== slider.currentSlide) { + slider.direction = (target > slider.currentSlide) ? "next" : "prev"; + } + + if (asNav && slider.pagingCount === 1) slider.direction = (slider.currentItem < target) ? "next" : "prev"; + + if (!slider.animating && (slider.canAdvance(target, fromNav) || override) && slider.is(":visible")) { + if (asNav && withSync) { + var master = $(slider.vars.asNavFor).data('flexslider'); + slider.atEnd = target === 0 || target === slider.count - 1; + master.flexAnimate(target, true, false, true, fromNav); + slider.direction = (slider.currentItem < target) ? "next" : "prev"; + master.direction = slider.direction; + + if (Math.ceil((target + 1)/slider.visible) - 1 !== slider.currentSlide && target !== 0) { + slider.currentItem = target; + slider.slides.removeClass(namespace + "active-slide").eq(target).addClass(namespace + "active-slide"); + target = Math.floor(target/slider.visible); + } else { + slider.currentItem = target; + slider.slides.removeClass(namespace + "active-slide").eq(target).addClass(namespace + "active-slide"); + return false; + } + } + + slider.animating = true; + slider.animatingTo = target; + + // SLIDESHOW: + if (pause) { slider.pause(); } + + // API: before() animation Callback + slider.vars.before(slider); + + // SYNC: + if (slider.syncExists && !fromNav) { methods.sync("animate"); } + + // CONTROLNAV + if (slider.vars.controlNav) { methods.controlNav.active(); } + + // !CAROUSEL: + // CANDIDATE: slide active class (for add/remove slide) + if (!carousel) { slider.slides.removeClass(namespace + 'active-slide').eq(target).addClass(namespace + 'active-slide'); } + + // INFINITE LOOP: + // CANDIDATE: atEnd + slider.atEnd = target === 0 || target === slider.last; + + // DIRECTIONNAV: + if (slider.vars.directionNav) { methods.directionNav.update(); } + + if (target === slider.last) { + // API: end() of cycle Callback + slider.vars.end(slider); + // SLIDESHOW && !INFINITE LOOP: + if (!slider.vars.animationLoop) { slider.pause(); } + } + + // SLIDE: + if (!fade) { + var dimension = (vertical) ? slider.slides.filter(':first').height() : slider.computedW, + margin, slideString, calcNext; + + // INFINITE LOOP / REVERSE: + if (carousel) { + //margin = (slider.vars.itemWidth > slider.w) ? slider.vars.itemMargin * 2 : slider.vars.itemMargin; + margin = slider.vars.itemMargin; + calcNext = ((slider.itemW + margin) * slider.move) * slider.animatingTo; + slideString = (calcNext > slider.limit && slider.visible !== 1) ? slider.limit : calcNext; + } else if (slider.currentSlide === 0 && target === slider.count - 1 && slider.vars.animationLoop && slider.direction !== "next") { + slideString = (reverse) ? (slider.count + slider.cloneOffset) * dimension : 0; + } else if (slider.currentSlide === slider.last && target === 0 && slider.vars.animationLoop && slider.direction !== "prev") { + slideString = (reverse) ? 0 : (slider.count + 1) * dimension; + } else { + slideString = (reverse) ? ((slider.count - 1) - target + slider.cloneOffset) * dimension : (target + slider.cloneOffset) * dimension; + } + slider.setProps(slideString, "", slider.vars.animationSpeed); + if (slider.transitions) { + if (!slider.vars.animationLoop || !slider.atEnd) { + slider.animating = false; + slider.currentSlide = slider.animatingTo; + } + + // Unbind previous transitionEnd events and re-bind new transitionEnd event + slider.container.unbind("webkitTransitionEnd transitionend"); + slider.container.bind("webkitTransitionEnd transitionend", function() { + clearTimeout(slider.ensureAnimationEnd); + slider.wrapup(dimension); + }); + + // Insurance for the ever-so-fickle transitionEnd event + clearTimeout(slider.ensureAnimationEnd); + slider.ensureAnimationEnd = setTimeout(function() { + slider.wrapup(dimension); + }, slider.vars.animationSpeed + 100); + + } else { + slider.container.animate(slider.args, slider.vars.animationSpeed, slider.vars.easing, function(){ + slider.wrapup(dimension); + }); + } + } else { // FADE: + if (!touch) { + //slider.slides.eq(slider.currentSlide).fadeOut(slider.vars.animationSpeed, slider.vars.easing); + //slider.slides.eq(target).fadeIn(slider.vars.animationSpeed, slider.vars.easing, slider.wrapup); + + slider.slides.eq(slider.currentSlide).css({"zIndex": 1}).animate({"opacity": 0}, slider.vars.animationSpeed, slider.vars.easing); + slider.slides.eq(target).css({"zIndex": 2}).animate({"opacity": 1}, slider.vars.animationSpeed, slider.vars.easing, slider.wrapup); + + } else { + slider.slides.eq(slider.currentSlide).css({ "opacity": 0, "zIndex": 1 }); + slider.slides.eq(target).css({ "opacity": 1, "zIndex": 2 }); + slider.wrapup(dimension); + } + } + // SMOOTH HEIGHT: + if (slider.vars.smoothHeight) { methods.smoothHeight(slider.vars.animationSpeed); } + } + }; + slider.wrapup = function(dimension) { + // SLIDE: + if (!fade && !carousel) { + if (slider.currentSlide === 0 && slider.animatingTo === slider.last && slider.vars.animationLoop) { + slider.setProps(dimension, "jumpEnd"); + } else if (slider.currentSlide === slider.last && slider.animatingTo === 0 && slider.vars.animationLoop) { + slider.setProps(dimension, "jumpStart"); + } + } + slider.animating = false; + slider.currentSlide = slider.animatingTo; + // API: after() animation Callback + slider.vars.after(slider); + }; + + // SLIDESHOW: + slider.animateSlides = function() { + if (!slider.animating && focused ) { slider.flexAnimate(slider.getTarget("next")); } + }; + // SLIDESHOW: + slider.pause = function() { + clearInterval(slider.animatedSlides); + slider.animatedSlides = null; + slider.playing = false; + // PAUSEPLAY: + if (slider.vars.pausePlay) { methods.pausePlay.update("play"); } + // SYNC: + if (slider.syncExists) { methods.sync("pause"); } + }; + // SLIDESHOW: + slider.play = function() { + if (slider.playing) { clearInterval(slider.animatedSlides); } + slider.animatedSlides = slider.animatedSlides || setInterval(slider.animateSlides, slider.vars.slideshowSpeed); + slider.started = slider.playing = true; + // PAUSEPLAY: + if (slider.vars.pausePlay) { methods.pausePlay.update("pause"); } + // SYNC: + if (slider.syncExists) { methods.sync("play"); } + }; + // STOP: + slider.stop = function () { + slider.pause(); + slider.stopped = true; + }; + slider.canAdvance = function(target, fromNav) { + // ASNAV: + var last = (asNav) ? slider.pagingCount - 1 : slider.last; + return (fromNav) ? true : + (asNav && slider.currentItem === slider.count - 1 && target === 0 && slider.direction === "prev") ? true : + (asNav && slider.currentItem === 0 && target === slider.pagingCount - 1 && slider.direction !== "next") ? false : + (target === slider.currentSlide && !asNav) ? false : + (slider.vars.animationLoop) ? true : + (slider.atEnd && slider.currentSlide === 0 && target === last && slider.direction !== "next") ? false : + (slider.atEnd && slider.currentSlide === last && target === 0 && slider.direction === "next") ? false : + true; + }; + slider.getTarget = function(dir) { + slider.direction = dir; + if (dir === "next") { + return (slider.currentSlide === slider.last) ? 0 : slider.currentSlide + 1; + } else { + return (slider.currentSlide === 0) ? slider.last : slider.currentSlide - 1; + } + }; + + // SLIDE: + slider.setProps = function(pos, special, dur) { + var target = (function() { + var posCheck = (pos) ? pos : ((slider.itemW + slider.vars.itemMargin) * slider.move) * slider.animatingTo, + posCalc = (function() { + if (carousel) { + return (special === "setTouch") ? pos : + (reverse && slider.animatingTo === slider.last) ? 0 : + (reverse) ? slider.limit - (((slider.itemW + slider.vars.itemMargin) * slider.move) * slider.animatingTo) : + (slider.animatingTo === slider.last) ? slider.limit : posCheck; + } else { + switch (special) { + case "setTotal": return (reverse) ? ((slider.count - 1) - slider.currentSlide + slider.cloneOffset) * pos : (slider.currentSlide + slider.cloneOffset) * pos; + case "setTouch": return (reverse) ? pos : pos; + case "jumpEnd": return (reverse) ? pos : slider.count * pos; + case "jumpStart": return (reverse) ? slider.count * pos : pos; + default: return pos; + } + } + }()); + + return (posCalc * -1) + "px"; + }()); + + if (slider.transitions) { + target = (vertical) ? "translate3d(0," + target + ",0)" : "translate3d(" + target + ",0,0)"; + dur = (dur !== undefined) ? (dur/1000) + "s" : "0s"; + slider.container.css("-" + slider.pfx + "-transition-duration", dur); + slider.container.css("transition-duration", dur); + } + + slider.args[slider.prop] = target; + if (slider.transitions || dur === undefined) { slider.container.css(slider.args); } + + slider.container.css('transform',target); + }; + + slider.setup = function(type) { + // SLIDE: + if (!fade) { + var sliderOffset, arr; + + if (type === "init") { + slider.viewport = $('
        ').css({"overflow": "hidden", "position": "relative"}).appendTo(slider).append(slider.container); + // INFINITE LOOP: + slider.cloneCount = 0; + slider.cloneOffset = 0; + // REVERSE: + if (reverse) { + arr = $.makeArray(slider.slides).reverse(); + slider.slides = $(arr); + slider.container.empty().append(slider.slides); + } + } + // INFINITE LOOP && !CAROUSEL: + if (slider.vars.animationLoop && !carousel) { + slider.cloneCount = 2; + slider.cloneOffset = 1; + // clear out old clones + if (type !== "init") { slider.container.find('.clone').remove(); } + slider.container.append(methods.uniqueID(slider.slides.first().clone().addClass('clone')).attr('aria-hidden', 'true')) + .prepend(methods.uniqueID(slider.slides.last().clone().addClass('clone')).attr('aria-hidden', 'true')); + } + slider.newSlides = $(slider.vars.selector, slider); + + sliderOffset = (reverse) ? slider.count - 1 - slider.currentSlide + slider.cloneOffset : slider.currentSlide + slider.cloneOffset; + // VERTICAL: + if (vertical && !carousel) { + slider.container.height((slider.count + slider.cloneCount) * 200 + "%").css("position", "absolute").width("100%"); + setTimeout(function(){ + slider.newSlides.css({"display": "block"}); + slider.doMath(); + slider.viewport.height(slider.h); + slider.setProps(sliderOffset * slider.h, "init"); + }, (type === "init") ? 100 : 0); + } else { + slider.container.width((slider.count + slider.cloneCount) * 200 + "%"); + slider.setProps(sliderOffset * slider.computedW, "init"); + setTimeout(function(){ + slider.doMath(); + slider.newSlides.css({"width": slider.computedW, "float": "left", "display": "block"}); + // SMOOTH HEIGHT: + if (slider.vars.smoothHeight) { methods.smoothHeight(); } + }, (type === "init") ? 100 : 0); + } + } else { // FADE: + slider.slides.css({"width": "100%", "float": "left", "marginRight": "-100%", "position": "relative"}); + if (type === "init") { + if (!touch) { + //slider.slides.eq(slider.currentSlide).fadeIn(slider.vars.animationSpeed, slider.vars.easing); + if (slider.vars.fadeFirstSlide == false) { + slider.slides.css({ "opacity": 0, "display": "block", "zIndex": 1 }).eq(slider.currentSlide).css({"zIndex": 2}).css({"opacity": 1}); + } else { + slider.slides.css({ "opacity": 0, "display": "block", "zIndex": 1 }).eq(slider.currentSlide).css({"zIndex": 2}).animate({"opacity": 1},slider.vars.animationSpeed,slider.vars.easing); + } + } else { + slider.slides.css({ "opacity": 0, "display": "block", "webkitTransition": "opacity " + slider.vars.animationSpeed / 1000 + "s ease", "zIndex": 1 }).eq(slider.currentSlide).css({ "opacity": 1, "zIndex": 2}); + } + } + // SMOOTH HEIGHT: + if (slider.vars.smoothHeight) { methods.smoothHeight(); } + } + // !CAROUSEL: + // CANDIDATE: active slide + if (!carousel) { slider.slides.removeClass(namespace + "active-slide").eq(slider.currentSlide).addClass(namespace + "active-slide"); } + + //FlexSlider: init() Callback + slider.vars.init(slider); + }; + + slider.doMath = function() { + var slide = slider.slides.first(), + slideMargin = slider.vars.itemMargin, + minItems = slider.vars.minItems, + maxItems = slider.vars.maxItems; + + slider.w = (slider.viewport===undefined) ? slider.width() : slider.viewport.width(); + slider.h = slide.height(); + slider.boxPadding = slide.outerWidth() - slide.width(); + + // CAROUSEL: + if (carousel) { + slider.itemT = slider.vars.itemWidth + slideMargin; + slider.minW = (minItems) ? minItems * slider.itemT : slider.w; + slider.maxW = (maxItems) ? (maxItems * slider.itemT) - slideMargin : slider.w; + slider.itemW = (slider.minW > slider.w) ? (slider.w - (slideMargin * (minItems - 1)))/minItems : + (slider.maxW < slider.w) ? (slider.w - (slideMargin * (maxItems - 1)))/maxItems : + (slider.vars.itemWidth > slider.w) ? slider.w : slider.vars.itemWidth; + + slider.visible = Math.floor(slider.w/(slider.itemW)); + slider.move = (slider.vars.move > 0 && slider.vars.move < slider.visible ) ? slider.vars.move : slider.visible; + slider.pagingCount = Math.ceil(((slider.count - slider.visible)/slider.move) + 1); + slider.last = slider.pagingCount - 1; + slider.limit = (slider.pagingCount === 1) ? 0 : + (slider.vars.itemWidth > slider.w) ? (slider.itemW * (slider.count - 1)) + (slideMargin * (slider.count - 1)) : ((slider.itemW + slideMargin) * slider.count) - slider.w - slideMargin; + } else { + slider.itemW = slider.w; + slider.pagingCount = slider.count; + slider.last = slider.count - 1; + } + slider.computedW = slider.itemW - slider.boxPadding; + }; + + slider.update = function(pos, action) { + slider.doMath(); + + // update currentSlide and slider.animatingTo if necessary + if (!carousel) { + if (pos < slider.currentSlide) { + slider.currentSlide += 1; + } else if (pos <= slider.currentSlide && pos !== 0) { + slider.currentSlide -= 1; + } + slider.animatingTo = slider.currentSlide; + } + + // update controlNav + if (slider.vars.controlNav && !slider.manualControls) { + if ((action === "add" && !carousel) || slider.pagingCount > slider.controlNav.length) { + methods.controlNav.update("add"); + } else if ((action === "remove" && !carousel) || slider.pagingCount < slider.controlNav.length) { + if (carousel && slider.currentSlide > slider.last) { + slider.currentSlide -= 1; + slider.animatingTo -= 1; + } + methods.controlNav.update("remove", slider.last); + } + } + // update directionNav + if (slider.vars.directionNav) { methods.directionNav.update(); } + + }; + + slider.addSlide = function(obj, pos) { + var $obj = $(obj); + + slider.count += 1; + slider.last = slider.count - 1; + + // append new slide + if (vertical && reverse) { + (pos !== undefined) ? slider.slides.eq(slider.count - pos).after($obj) : slider.container.prepend($obj); + } else { + (pos !== undefined) ? slider.slides.eq(pos).before($obj) : slider.container.append($obj); + } + + // update currentSlide, animatingTo, controlNav, and directionNav + slider.update(pos, "add"); + + // update slider.slides + slider.slides = $(slider.vars.selector + ':not(.clone)', slider); + // re-setup the slider to accomdate new slide + slider.setup(); + + //FlexSlider: added() Callback + slider.vars.added(slider); + }; + slider.removeSlide = function(obj) { + var pos = (isNaN(obj)) ? slider.slides.index($(obj)) : obj; + + // update count + slider.count -= 1; + slider.last = slider.count - 1; + + // remove slide + if (isNaN(obj)) { + $(obj, slider.slides).remove(); + } else { + (vertical && reverse) ? slider.slides.eq(slider.last).remove() : slider.slides.eq(obj).remove(); + } + + // update currentSlide, animatingTo, controlNav, and directionNav + slider.doMath(); + slider.update(pos, "remove"); + + // update slider.slides + slider.slides = $(slider.vars.selector + ':not(.clone)', slider); + // re-setup the slider to accomdate new slide + slider.setup(); + + // FlexSlider: removed() Callback + slider.vars.removed(slider); + }; + + //FlexSlider: Initialize + methods.init(); + }; + + // Ensure the slider isn't focussed if the window loses focus. + $( window ).blur( function ( e ) { + focused = false; + }).focus( function ( e ) { + focused = true; + }); + + //FlexSlider: Default Settings + $.flexslider.defaults = { + namespace: "flex-", //{NEW} String: Prefix string attached to the class of every element generated by the plugin + selector: ".slides > li", //{NEW} Selector: Must match a simple pattern. '{container} > {slide}' -- Ignore pattern at your own peril + animation: "fade", //String: Select your animation type, "fade" or "slide" + easing: "swing", //{NEW} String: Determines the easing method used in jQuery transitions. jQuery easing plugin is supported! + direction: "horizontal", //String: Select the sliding direction, "horizontal" or "vertical" + reverse: false, //{NEW} Boolean: Reverse the animation direction + animationLoop: true, //Boolean: Should the animation loop? If false, directionNav will received "disable" classes at either end + smoothHeight: false, //{NEW} Boolean: Allow height of the slider to animate smoothly in horizontal mode + startAt: 0, //Integer: The slide that the slider should start on. Array notation (0 = first slide) + slideshow: true, //Boolean: Animate slider automatically + slideshowSpeed: 7000, //Integer: Set the speed of the slideshow cycling, in milliseconds + animationSpeed: 600, //Integer: Set the speed of animations, in milliseconds + initDelay: 0, //{NEW} Integer: Set an initialization delay, in milliseconds + randomize: false, //Boolean: Randomize slide order + fadeFirstSlide: true, //Boolean: Fade in the first slide when animation type is "fade" + thumbCaptions: false, //Boolean: Whether or not to put captions on thumbnails when using the "thumbnails" controlNav. + + // Usability features + pauseOnAction: true, //Boolean: Pause the slideshow when interacting with control elements, highly recommended. + pauseOnHover: false, //Boolean: Pause the slideshow when hovering over slider, then resume when no longer hovering + pauseInvisible: true, //{NEW} Boolean: Pause the slideshow when tab is invisible, resume when visible. Provides better UX, lower CPU usage. + useCSS: true, //{NEW} Boolean: Slider will use CSS3 transitions if available + touch: true, //{NEW} Boolean: Allow touch swipe navigation of the slider on touch-enabled devices + video: false, //{NEW} Boolean: If using video in the slider, will prevent CSS3 3D Transforms to avoid graphical glitches + + // Primary Controls + controlNav: true, //Boolean: Create navigation for paging control of each slide? Note: Leave true for manualControls usage + directionNav: true, //Boolean: Create navigation for previous/next navigation? (true/false) + prevText: "Previous", //String: Set the text for the "previous" directionNav item + nextText: "Next", //String: Set the text for the "next" directionNav item + + // Secondary Navigation + keyboard: true, //Boolean: Allow slider navigating via keyboard left/right keys + multipleKeyboard: false, //{NEW} Boolean: Allow keyboard navigation to affect multiple sliders. Default behavior cuts out keyboard navigation with more than one slider present. + mousewheel: false, //{UPDATED} Boolean: Requires jquery.mousewheel.js (https://github.com/brandonaaron/jquery-mousewheel) - Allows slider navigating via mousewheel + pausePlay: false, //Boolean: Create pause/play dynamic element + pauseText: "Pause", //String: Set the text for the "pause" pausePlay item + playText: "Play", //String: Set the text for the "play" pausePlay item + + // Special properties + controlsContainer: "", //{UPDATED} jQuery Object/Selector: Declare which container the navigation elements should be appended too. Default container is the FlexSlider element. Example use would be $(".flexslider-container"). Property is ignored if given element is not found. + manualControls: "", //{UPDATED} jQuery Object/Selector: Declare custom control navigation. Examples would be $(".flex-control-nav li") or "#tabs-nav li img", etc. The number of elements in your controlNav should match the number of slides/tabs. + customDirectionNav: "", //{NEW} jQuery Object/Selector: Custom prev / next button. Must be two jQuery elements. In order to make the events work they have to have the classes "prev" and "next" (plus namespace) + sync: "", //{NEW} Selector: Mirror the actions performed on this slider with another slider. Use with care. + asNavFor: "", //{NEW} Selector: Internal property exposed for turning the slider into a thumbnail navigation for another slider + + // Carousel Options + itemWidth: 0, //{NEW} Integer: Box-model width of individual carousel items, including horizontal borders and padding. + itemMargin: 0, //{NEW} Integer: Margin between carousel items. + minItems: 1, //{NEW} Integer: Minimum number of carousel items that should be visible. Items will resize fluidly when below this. + maxItems: 0, //{NEW} Integer: Maxmimum number of carousel items that should be visible. Items will resize fluidly when above this limit. + move: 0, //{NEW} Integer: Number of carousel items that should move on animation. If 0, slider will move all visible items. + allowOneSlide: true, //{NEW} Boolean: Whether or not to allow a slider comprised of a single slide + + // Callback API + start: function(){}, //Callback: function(slider) - Fires when the slider loads the first slide + before: function(){}, //Callback: function(slider) - Fires asynchronously with each slider animation + after: function(){}, //Callback: function(slider) - Fires after each slider animation completes + end: function(){}, //Callback: function(slider) - Fires when the slider reaches the last slide (asynchronous) + added: function(){}, //{NEW} Callback: function(slider) - Fires after a slide is added + removed: function(){}, //{NEW} Callback: function(slider) - Fires after a slide is removed + init: function() {} //{NEW} Callback: function(slider) - Fires after the slider is initially setup + }; + + //FlexSlider: Plugin Function + $.fn.flexslider = function(options) { + if (options === undefined) { options = {}; } + + if (typeof options === "object") { + return this.each(function() { + var $this = $(this), + selector = (options.selector) ? options.selector : ".slides > li", + $slides = $this.find(selector); + + if ( ( $slides.length === 1 && options.allowOneSlide === true ) || $slides.length === 0 ) { + $slides.fadeIn(400); + if (options.start) { options.start($this); } + } else if ($this.data('flexslider') === undefined) { + new $.flexslider(this, options); + } + }); + } else { + // Helper strings to quickly perform functions on the slider + var $slider = $(this).data('flexslider'); + switch (options) { + case "play": $slider.play(); break; + case "pause": $slider.pause(); break; + case "stop": $slider.stop(); break; + case "next": $slider.flexAnimate($slider.getTarget("next"), true); break; + case "prev": + case "previous": $slider.flexAnimate($slider.getTarget("prev"), true); break; + default: if (typeof options === "number") { $slider.flexAnimate(options, true); } + } + } + }; +})(jQuery); diff --git a/Webseiten/Docker - Build, Ship, and Run Any App, Anywhere_files/jquery.magnific-popup.min.js b/Webseiten/Docker - Build, Ship, and Run Any App, Anywhere_files/jquery.magnific-popup.min.js new file mode 100644 index 0000000..ad353b9 --- /dev/null +++ b/Webseiten/Docker - Build, Ship, and Run Any App, Anywhere_files/jquery.magnific-popup.min.js @@ -0,0 +1,4 @@ +/*! Magnific Popup - v1.0.0 - 2015-01-03 +* http://dimsemenov.com/plugins/magnific-popup/ +* Copyright (c) 2015 Dmitry Semenov; */ +!function(a){"function"==typeof define&&define.amd?define(["jquery"],a):a("object"==typeof exports?require("jquery"):window.jQuery||window.Zepto)}(function(a){var b,c,d,e,f,g,h="Close",i="BeforeClose",j="AfterClose",k="BeforeAppend",l="MarkupParse",m="Open",n="Change",o="mfp",p="."+o,q="mfp-ready",r="mfp-removing",s="mfp-prevent-close",t=function(){},u=!!window.jQuery,v=a(window),w=function(a,c){b.ev.on(o+a+p,c)},x=function(b,c,d,e){var f=document.createElement("div");return f.className="mfp-"+b,d&&(f.innerHTML=d),e?c&&c.appendChild(f):(f=a(f),c&&f.appendTo(c)),f},y=function(c,d){b.ev.triggerHandler(o+c,d),b.st.callbacks&&(c=c.charAt(0).toLowerCase()+c.slice(1),b.st.callbacks[c]&&b.st.callbacks[c].apply(b,a.isArray(d)?d:[d]))},z=function(c){return c===g&&b.currTemplate.closeBtn||(b.currTemplate.closeBtn=a(b.st.closeMarkup.replace("%title%",b.st.tClose)),g=c),b.currTemplate.closeBtn},A=function(){a.magnificPopup.instance||(b=new t,b.init(),a.magnificPopup.instance=b)},B=function(){var a=document.createElement("p").style,b=["ms","O","Moz","Webkit"];if(void 0!==a.transition)return!0;for(;b.length;)if(b.pop()+"Transition"in a)return!0;return!1};t.prototype={constructor:t,init:function(){var c=navigator.appVersion;b.isIE7=-1!==c.indexOf("MSIE 7."),b.isIE8=-1!==c.indexOf("MSIE 8."),b.isLowIE=b.isIE7||b.isIE8,b.isAndroid=/android/gi.test(c),b.isIOS=/iphone|ipad|ipod/gi.test(c),b.supportsTransition=B(),b.probablyMobile=b.isAndroid||b.isIOS||/(Opera Mini)|Kindle|webOS|BlackBerry|(Opera Mobi)|(Windows Phone)|IEMobile/i.test(navigator.userAgent),d=a(document),b.popupsCache={}},open:function(c){var e;if(c.isObj===!1){b.items=c.items.toArray(),b.index=0;var g,h=c.items;for(e=0;e(a||v.height())},_setFocus:function(){(b.st.focus?b.content.find(b.st.focus).eq(0):b.wrap).focus()},_onFocusIn:function(c){return c.target===b.wrap[0]||a.contains(b.wrap[0],c.target)?void 0:(b._setFocus(),!1)},_parseMarkup:function(b,c,d){var e;d.data&&(c=a.extend(d.data,c)),y(l,[b,c,d]),a.each(c,function(a,c){if(void 0===c||c===!1)return!0;if(e=a.split("_"),e.length>1){var d=b.find(p+"-"+e[0]);if(d.length>0){var f=e[1];"replaceWith"===f?d[0]!==c[0]&&d.replaceWith(c):"img"===f?d.is("img")?d.attr("src",c):d.replaceWith(''):d.attr(e[1],c)}}else b.find(p+"-"+a).html(c)})},_getScrollbarSize:function(){if(void 0===b.scrollbarSize){var a=document.createElement("div");a.style.cssText="width: 99px; height: 99px; overflow: scroll; position: absolute; top: -9999px;",document.body.appendChild(a),b.scrollbarSize=a.offsetWidth-a.clientWidth,document.body.removeChild(a)}return b.scrollbarSize}},a.magnificPopup={instance:null,proto:t.prototype,modules:[],open:function(b,c){return A(),b=b?a.extend(!0,{},b):{},b.isObj=!0,b.index=c||0,this.instance.open(b)},close:function(){return a.magnificPopup.instance&&a.magnificPopup.instance.close()},registerModule:function(b,c){c.options&&(a.magnificPopup.defaults[b]=c.options),a.extend(this.proto,c.proto),this.modules.push(b)},defaults:{disableOn:0,key:null,midClick:!1,mainClass:"",preloader:!0,focus:"",closeOnContentClick:!1,closeOnBgClick:!0,closeBtnInside:!0,showCloseBtn:!0,enableEscapeKey:!0,modal:!1,alignTop:!1,removalDelay:0,prependTo:null,fixedContentPos:"auto",fixedBgPos:"auto",overflowY:"auto",closeMarkup:'',tClose:"Close (Esc)",tLoading:"Loading..."}},a.fn.magnificPopup=function(c){A();var d=a(this);if("string"==typeof c)if("open"===c){var e,f=u?d.data("magnificPopup"):d[0].magnificPopup,g=parseInt(arguments[1],10)||0;f.items?e=f.items[g]:(e=d,f.delegate&&(e=e.find(f.delegate)),e=e.eq(g)),b._openClick({mfpEl:e},d,f)}else b.isOpen&&b[c].apply(b,Array.prototype.slice.call(arguments,1));else c=a.extend(!0,{},c),u?d.data("magnificPopup",c):d[0].magnificPopup=c,b.addGroup(d,c);return d};var C,D,E,F="inline",G=function(){E&&(D.after(E.addClass(C)).detach(),E=null)};a.magnificPopup.registerModule(F,{options:{hiddenClass:"hide",markup:"",tNotFound:"Content not found"},proto:{initInline:function(){b.types.push(F),w(h+"."+F,function(){G()})},getInline:function(c,d){if(G(),c.src){var e=b.st.inline,f=a(c.src);if(f.length){var g=f[0].parentNode;g&&g.tagName&&(D||(C=e.hiddenClass,D=x(C),C="mfp-"+C),E=f.after(D).detach().removeClass(C)),b.updateStatus("ready")}else b.updateStatus("error",e.tNotFound),f=a("
        ");return c.inlineElement=f,f}return b.updateStatus("ready"),b._parseMarkup(d,{},c),d}}});var H,I="ajax",J=function(){H&&a(document.body).removeClass(H)},K=function(){J(),b.req&&b.req.abort()};a.magnificPopup.registerModule(I,{options:{settings:null,cursor:"mfp-ajax-cur",tError:'The content could not be loaded.'},proto:{initAjax:function(){b.types.push(I),H=b.st.ajax.cursor,w(h+"."+I,K),w("BeforeChange."+I,K)},getAjax:function(c){H&&a(document.body).addClass(H),b.updateStatus("loading");var d=a.extend({url:c.src,success:function(d,e,f){var g={data:d,xhr:f};y("ParseAjax",g),b.appendContent(a(g.data),I),c.finished=!0,J(),b._setFocus(),setTimeout(function(){b.wrap.addClass(q)},16),b.updateStatus("ready"),y("AjaxContentAdded")},error:function(){J(),c.finished=c.loadError=!0,b.updateStatus("error",b.st.ajax.tError.replace("%url%",c.src))}},b.st.ajax.settings);return b.req=a.ajax(d),""}}});var L,M=function(c){if(c.data&&void 0!==c.data.title)return c.data.title;var d=b.st.image.titleSrc;if(d){if(a.isFunction(d))return d.call(b,c);if(c.el)return c.el.attr(d)||""}return""};a.magnificPopup.registerModule("image",{options:{markup:'
        ',cursor:"mfp-zoom-out-cur",titleSrc:"title",verticalFit:!0,tError:'The image could not be loaded.'},proto:{initImage:function(){var c=b.st.image,d=".image";b.types.push("image"),w(m+d,function(){"image"===b.currItem.type&&c.cursor&&a(document.body).addClass(c.cursor)}),w(h+d,function(){c.cursor&&a(document.body).removeClass(c.cursor),v.off("resize"+p)}),w("Resize"+d,b.resizeImage),b.isLowIE&&w("AfterChange",b.resizeImage)},resizeImage:function(){var a=b.currItem;if(a&&a.img&&b.st.image.verticalFit){var c=0;b.isLowIE&&(c=parseInt(a.img.css("padding-top"),10)+parseInt(a.img.css("padding-bottom"),10)),a.img.css("max-height",b.wH-c)}},_onImageHasSize:function(a){a.img&&(a.hasSize=!0,L&&clearInterval(L),a.isCheckingImgSize=!1,y("ImageHasSize",a),a.imgHidden&&(b.content&&b.content.removeClass("mfp-loading"),a.imgHidden=!1))},findImageSize:function(a){var c=0,d=a.img[0],e=function(f){L&&clearInterval(L),L=setInterval(function(){return d.naturalWidth>0?void b._onImageHasSize(a):(c>200&&clearInterval(L),c++,void(3===c?e(10):40===c?e(50):100===c&&e(500)))},f)};e(1)},getImage:function(c,d){var e=0,f=function(){c&&(c.img[0].complete?(c.img.off(".mfploader"),c===b.currItem&&(b._onImageHasSize(c),b.updateStatus("ready")),c.hasSize=!0,c.loaded=!0,y("ImageLoadComplete")):(e++,200>e?setTimeout(f,100):g()))},g=function(){c&&(c.img.off(".mfploader"),c===b.currItem&&(b._onImageHasSize(c),b.updateStatus("error",h.tError.replace("%url%",c.src))),c.hasSize=!0,c.loaded=!0,c.loadError=!0)},h=b.st.image,i=d.find(".mfp-img");if(i.length){var j=document.createElement("img");j.className="mfp-img",c.el&&c.el.find("img").length&&(j.alt=c.el.find("img").attr("alt")),c.img=a(j).on("load.mfploader",f).on("error.mfploader",g),j.src=c.src,i.is("img")&&(c.img=c.img.clone()),j=c.img[0],j.naturalWidth>0?c.hasSize=!0:j.width||(c.hasSize=!1)}return b._parseMarkup(d,{title:M(c),img_replaceWith:c.img},c),b.resizeImage(),c.hasSize?(L&&clearInterval(L),c.loadError?(d.addClass("mfp-loading"),b.updateStatus("error",h.tError.replace("%url%",c.src))):(d.removeClass("mfp-loading"),b.updateStatus("ready")),d):(b.updateStatus("loading"),c.loading=!0,c.hasSize||(c.imgHidden=!0,d.addClass("mfp-loading"),b.findImageSize(c)),d)}}});var N,O=function(){return void 0===N&&(N=void 0!==document.createElement("p").style.MozTransform),N};a.magnificPopup.registerModule("zoom",{options:{enabled:!1,easing:"ease-in-out",duration:300,opener:function(a){return a.is("img")?a:a.find("img")}},proto:{initZoom:function(){var a,c=b.st.zoom,d=".zoom";if(c.enabled&&b.supportsTransition){var e,f,g=c.duration,j=function(a){var b=a.clone().removeAttr("style").removeAttr("class").addClass("mfp-animated-image"),d="all "+c.duration/1e3+"s "+c.easing,e={position:"fixed",zIndex:9999,left:0,top:0,"-webkit-backface-visibility":"hidden"},f="transition";return e["-webkit-"+f]=e["-moz-"+f]=e["-o-"+f]=e[f]=d,b.css(e),b},k=function(){b.content.css("visibility","visible")};w("BuildControls"+d,function(){if(b._allowZoom()){if(clearTimeout(e),b.content.css("visibility","hidden"),a=b._getItemToZoom(),!a)return void k();f=j(a),f.css(b._getOffset()),b.wrap.append(f),e=setTimeout(function(){f.css(b._getOffset(!0)),e=setTimeout(function(){k(),setTimeout(function(){f.remove(),a=f=null,y("ZoomAnimationEnded")},16)},g)},16)}}),w(i+d,function(){if(b._allowZoom()){if(clearTimeout(e),b.st.removalDelay=g,!a){if(a=b._getItemToZoom(),!a)return;f=j(a)}f.css(b._getOffset(!0)),b.wrap.append(f),b.content.css("visibility","hidden"),setTimeout(function(){f.css(b._getOffset())},16)}}),w(h+d,function(){b._allowZoom()&&(k(),f&&f.remove(),a=null)})}},_allowZoom:function(){return"image"===b.currItem.type},_getItemToZoom:function(){return b.currItem.hasSize?b.currItem.img:!1},_getOffset:function(c){var d;d=c?b.currItem.img:b.st.zoom.opener(b.currItem.el||b.currItem);var e=d.offset(),f=parseInt(d.css("padding-top"),10),g=parseInt(d.css("padding-bottom"),10);e.top-=a(window).scrollTop()-f;var h={width:d.width(),height:(u?d.innerHeight():d[0].offsetHeight)-g-f};return O()?h["-moz-transform"]=h.transform="translate("+e.left+"px,"+e.top+"px)":(h.left=e.left,h.top=e.top),h}}});var P="iframe",Q="//about:blank",R=function(a){if(b.currTemplate[P]){var c=b.currTemplate[P].find("iframe");c.length&&(a||(c[0].src=Q),b.isIE8&&c.css("display",a?"block":"none"))}};a.magnificPopup.registerModule(P,{options:{markup:'
        ',srcAction:"iframe_src",patterns:{youtube:{index:"youtube.com",id:"v=",src:"//www.youtube.com/embed/%id%?autoplay=1"},vimeo:{index:"vimeo.com/",id:"/",src:"//player.vimeo.com/video/%id%?autoplay=1"},gmaps:{index:"//maps.google.",src:"%id%&output=embed"}}},proto:{initIframe:function(){b.types.push(P),w("BeforeChange",function(a,b,c){b!==c&&(b===P?R():c===P&&R(!0))}),w(h+"."+P,function(){R()})},getIframe:function(c,d){var e=c.src,f=b.st.iframe;a.each(f.patterns,function(){return e.indexOf(this.index)>-1?(this.id&&(e="string"==typeof this.id?e.substr(e.lastIndexOf(this.id)+this.id.length,e.length):this.id.call(this,e)),e=this.src.replace("%id%",e),!1):void 0});var g={};return f.srcAction&&(g[f.srcAction]=e),b._parseMarkup(d,g,c),b.updateStatus("ready"),d}}});var S=function(a){var c=b.items.length;return a>c-1?a-c:0>a?c+a:a},T=function(a,b,c){return a.replace(/%curr%/gi,b+1).replace(/%total%/gi,c)};a.magnificPopup.registerModule("gallery",{options:{enabled:!1,arrowMarkup:'',preload:[0,2],navigateByImgClick:!0,arrows:!0,tPrev:"Previous (Left arrow key)",tNext:"Next (Right arrow key)",tCounter:"%curr% of %total%"},proto:{initGallery:function(){var c=b.st.gallery,e=".mfp-gallery",g=Boolean(a.fn.mfpFastClick);return b.direction=!0,c&&c.enabled?(f+=" mfp-gallery",w(m+e,function(){c.navigateByImgClick&&b.wrap.on("click"+e,".mfp-img",function(){return b.items.length>1?(b.next(),!1):void 0}),d.on("keydown"+e,function(a){37===a.keyCode?b.prev():39===a.keyCode&&b.next()})}),w("UpdateStatus"+e,function(a,c){c.text&&(c.text=T(c.text,b.currItem.index,b.items.length))}),w(l+e,function(a,d,e,f){var g=b.items.length;e.counter=g>1?T(c.tCounter,f.index,g):""}),w("BuildControls"+e,function(){if(b.items.length>1&&c.arrows&&!b.arrowLeft){var d=c.arrowMarkup,e=b.arrowLeft=a(d.replace(/%title%/gi,c.tPrev).replace(/%dir%/gi,"left")).addClass(s),f=b.arrowRight=a(d.replace(/%title%/gi,c.tNext).replace(/%dir%/gi,"right")).addClass(s),h=g?"mfpFastClick":"click";e[h](function(){b.prev()}),f[h](function(){b.next()}),b.isIE7&&(x("b",e[0],!1,!0),x("a",e[0],!1,!0),x("b",f[0],!1,!0),x("a",f[0],!1,!0)),b.container.append(e.add(f))}}),w(n+e,function(){b._preloadTimeout&&clearTimeout(b._preloadTimeout),b._preloadTimeout=setTimeout(function(){b.preloadNearbyImages(),b._preloadTimeout=null},16)}),void w(h+e,function(){d.off(e),b.wrap.off("click"+e),b.arrowLeft&&g&&b.arrowLeft.add(b.arrowRight).destroyMfpFastClick(),b.arrowRight=b.arrowLeft=null})):!1},next:function(){b.direction=!0,b.index=S(b.index+1),b.updateItemHTML()},prev:function(){b.direction=!1,b.index=S(b.index-1),b.updateItemHTML()},goTo:function(a){b.direction=a>=b.index,b.index=a,b.updateItemHTML()},preloadNearbyImages:function(){var a,c=b.st.gallery.preload,d=Math.min(c[0],b.items.length),e=Math.min(c[1],b.items.length);for(a=1;a<=(b.direction?e:d);a++)b._preloadItem(b.index+a);for(a=1;a<=(b.direction?d:e);a++)b._preloadItem(b.index-a)},_preloadItem:function(c){if(c=S(c),!b.items[c].preloaded){var d=b.items[c];d.parsed||(d=b.parseEl(c)),y("LazyLoad",d),"image"===d.type&&(d.img=a('').on("load.mfploader",function(){d.hasSize=!0}).on("error.mfploader",function(){d.hasSize=!0,d.loadError=!0,y("LazyLoadError",d)}).attr("src",d.src)),d.preloaded=!0}}}});var U="retina";a.magnificPopup.registerModule(U,{options:{replaceSrc:function(a){return a.src.replace(/\.\w+$/,function(a){return"@2x"+a})},ratio:1},proto:{initRetina:function(){if(window.devicePixelRatio>1){var a=b.st.retina,c=a.ratio;c=isNaN(c)?c():c,c>1&&(w("ImageHasSize."+U,function(a,b){b.img.css({"max-width":b.img[0].naturalWidth/c,width:"100%"})}),w("ElementParse."+U,function(b,d){d.src=a.replaceSrc(d,c)}))}}}}),function(){var b=1e3,c="ontouchstart"in window,d=function(){v.off("touchmove"+f+" touchend"+f)},e="mfpFastClick",f="."+e;a.fn.mfpFastClick=function(e){return a(this).each(function(){var g,h=a(this);if(c){var i,j,k,l,m,n;h.on("touchstart"+f,function(a){l=!1,n=1,m=a.originalEvent?a.originalEvent.touches[0]:a.touches[0],j=m.clientX,k=m.clientY,v.on("touchmove"+f,function(a){m=a.originalEvent?a.originalEvent.touches:a.touches,n=m.length,m=m[0],(Math.abs(m.clientX-j)>10||Math.abs(m.clientY-k)>10)&&(l=!0,d())}).on("touchend"+f,function(a){d(),l||n>1||(g=!0,a.preventDefault(),clearTimeout(i),i=setTimeout(function(){g=!1},b),e())})})}h.on("click"+f,function(){g||e()})})},a.fn.destroyMfpFastClick=function(){a(this).off("touchstart"+f+" click"+f),c&&v.off("touchmove"+f+" touchend"+f)}}(),A()}); \ No newline at end of file diff --git a/Webseiten/Docker - Build, Ship, and Run Any App, Anywhere_files/jquery.matchHeight.min.js b/Webseiten/Docker - Build, Ship, and Run Any App, Anywhere_files/jquery.matchHeight.min.js new file mode 100644 index 0000000..3d5fd6d --- /dev/null +++ b/Webseiten/Docker - Build, Ship, and Run Any App, Anywhere_files/jquery.matchHeight.min.js @@ -0,0 +1,10 @@ +/** +* jquery.matchHeight-min.js v0.5.2 +* http://brm.io/jquery-match-height/ +* License: MIT +*/ +(function(d){var g=-1,e=-1,n=function(a){var b=null,c=[];d(a).each(function(){var a=d(this),k=a.offset().top-h(a.css("margin-top")),l=0=Math.floor(Math.abs(b-k))?c[c.length-1]=l.add(a):c.push(a);b=k});return c},h=function(a){return parseFloat(a)||0},b=d.fn.matchHeight=function(a){if("remove"===a){var f=this;this.css("height","");d.each(b._groups,function(a,b){b.elements=b.elements.not(f)});return this}if(1>=this.length)return this;a="undefined"!== +typeof a?a:!0;b._groups.push({elements:this,byRow:a});b._apply(this,a);return this};b._groups=[];b._throttle=80;b._maintainScroll=!1;b._beforeUpdate=null;b._afterUpdate=null;b._apply=function(a,f){var c=d(a),e=[c],k=d(window).scrollTop(),l=d("html").outerHeight(!0),g=c.parents().filter(":hidden");g.css("display","block");f&&(c.each(function(){var a=d(this),b="inline-block"===a.css("display")?"inline-block":"block";a.data("style-cache",a.attr("style"));a.css({display:b,"padding-top":"0","padding-bottom":"0", +"margin-top":"0","margin-bottom":"0","border-top-width":"0","border-bottom-width":"0",height:"100px"})}),e=n(c),c.each(function(){var a=d(this);a.attr("style",a.data("style-cache")||"").css("height","")}));d.each(e,function(a,b){var c=d(b),e=0;f&&1>=c.length||(c.each(function(){var a=d(this),b="inline-block"===a.css("display")?"inline-block":"block";a.css({display:b,height:""});a.outerHeight(!1)>e&&(e=a.outerHeight(!1));a.css("display","")}),c.each(function(){var a=d(this),b=0;"border-box"!==a.css("box-sizing")&& +(b+=h(a.css("border-top-width"))+h(a.css("border-bottom-width")),b+=h(a.css("padding-top"))+h(a.css("padding-bottom")));a.css("height",e-b)}))});g.css("display","");b._maintainScroll&&d(window).scrollTop(k/l*d("html").outerHeight(!0));return this};b._applyDataApi=function(){var a={};d("[data-match-height], [data-mh]").each(function(){var b=d(this),c=b.attr("data-match-height")||b.attr("data-mh");a[c]=c in a?a[c].add(b):b});d.each(a,function(){this.matchHeight(!0)})};var m=function(a){b._beforeUpdate&& +b._beforeUpdate(a,b._groups);d.each(b._groups,function(){b._apply(this.elements,this.byRow)});b._afterUpdate&&b._afterUpdate(a,b._groups)};b._update=function(a,f){if(f&&"resize"===f.type){var c=d(window).width();if(c===g)return;g=c}a?-1===e&&(e=setTimeout(function(){m(f);e=-1},b._throttle)):m(f)};d(b._applyDataApi);d(window).bind("load",function(a){b._update(!1,a)});d(window).bind("resize orientationchange",function(a){b._update(!0,a)})})(jQuery); \ No newline at end of file diff --git a/Webseiten/Docker - Build, Ship, and Run Any App, Anywhere_files/jquery.smooth-scroll.min.js b/Webseiten/Docker - Build, Ship, and Run Any App, Anywhere_files/jquery.smooth-scroll.min.js new file mode 100644 index 0000000..d483db5 --- /dev/null +++ b/Webseiten/Docker - Build, Ship, and Run Any App, Anywhere_files/jquery.smooth-scroll.min.js @@ -0,0 +1,7 @@ +/*! + * jQuery Smooth Scroll - v1.5.4 - 2014-11-17 + * https://github.com/kswedberg/jquery-smooth-scroll + * Copyright (c) 2014 Karl Swedberg + * Licensed MIT (https://github.com/kswedberg/jquery-smooth-scroll/blob/master/LICENSE-MIT) + */ +(function(t){"function"==typeof define&&define.amd?define(["jquery"],t):t(jQuery)})(function(t){function e(t){return t.replace(/(:|\.|\/)/g,"\\$1")}var l="1.5.4",o={},n={exclude:[],excludeWithin:[],offset:0,direction:"top",scrollElement:null,scrollTarget:null,beforeScroll:function(){},afterScroll:function(){},easing:"swing",speed:400,autoCoefficient:2,preventDefault:!0},s=function(e){var l=[],o=!1,n=e.dir&&"left"===e.dir?"scrollLeft":"scrollTop";return this.each(function(){if(this!==document&&this!==window){var e=t(this);e[n]()>0?l.push(this):(e[n](1),o=e[n]()>0,o&&l.push(this),e[n](0))}}),l.length||this.each(function(){"BODY"===this.nodeName&&(l=[this])}),"first"===e.el&&l.length>1&&(l=[l[0]]),l};t.fn.extend({scrollable:function(t){var e=s.call(this,{dir:t});return this.pushStack(e)},firstScrollable:function(t){var e=s.call(this,{el:"first",dir:t});return this.pushStack(e)},smoothScroll:function(l,o){if(l=l||{},"options"===l)return o?this.each(function(){var e=t(this),l=t.extend(e.data("ssOpts")||{},o);t(this).data("ssOpts",l)}):this.first().data("ssOpts");var n=t.extend({},t.fn.smoothScroll.defaults,l),s=t.smoothScroll.filterPath(location.pathname);return this.unbind("click.smoothscroll").bind("click.smoothscroll",function(l){var o=this,r=t(this),i=t.extend({},n,r.data("ssOpts")||{}),c=n.exclude,a=i.excludeWithin,f=0,h=0,u=!0,d={},p=location.hostname===o.hostname||!o.hostname,m=i.scrollTarget||t.smoothScroll.filterPath(o.pathname)===s,S=e(o.hash);if(i.scrollTarget||p&&m&&S){for(;u&&c.length>f;)r.is(e(c[f++]))&&(u=!1);for(;u&&a.length>h;)r.closest(a[h++]).length&&(u=!1)}else u=!1;u&&(i.preventDefault&&l.preventDefault(),t.extend(d,i,{scrollTarget:i.scrollTarget||S,link:o}),t.smoothScroll(d))}),this}}),t.smoothScroll=function(e,l){if("options"===e&&"object"==typeof l)return t.extend(o,l);var n,s,r,i,c,a=0,f="offset",h="scrollTop",u={},d={};"number"==typeof e?(n=t.extend({link:null},t.fn.smoothScroll.defaults,o),r=e):(n=t.extend({link:null},t.fn.smoothScroll.defaults,e||{},o),n.scrollElement&&(f="position","static"===n.scrollElement.css("position")&&n.scrollElement.css("position","relative"))),h="left"===n.direction?"scrollLeft":h,n.scrollElement?(s=n.scrollElement,/^(?:HTML|BODY)$/.test(s[0].nodeName)||(a=s[h]())):s=t("html, body").firstScrollable(n.direction),n.beforeScroll.call(s,n),r="number"==typeof e?e:l||t(n.scrollTarget)[f]()&&t(n.scrollTarget)[f]()[n.direction]||0,u[h]=r+a+n.offset,i=n.speed,"auto"===i&&(c=u[h]-s.scrollTop(),0>c&&(c*=-1),i=c/n.autoCoefficient),d={duration:i,easing:n.easing,complete:function(){n.afterScroll.call(n.link,n)}},n.step&&(d.step=n.step),s.length?s.stop().animate(u,d):n.afterScroll.call(n.link,n)},t.smoothScroll.version=l,t.smoothScroll.filterPath=function(t){return t=t||"",t.replace(/^\//,"").replace(/(?:index|default).[a-zA-Z]{3,4}$/,"").replace(/\/$/,"")},t.fn.smoothScroll.defaults=n}); \ No newline at end of file diff --git a/Webseiten/Docker - Build, Ship, and Run Any App, Anywhere_files/jquery.ui.touch-punch.min.js b/Webseiten/Docker - Build, Ship, and Run Any App, Anywhere_files/jquery.ui.touch-punch.min.js new file mode 100644 index 0000000..31272ce --- /dev/null +++ b/Webseiten/Docker - Build, Ship, and Run Any App, Anywhere_files/jquery.ui.touch-punch.min.js @@ -0,0 +1,11 @@ +/*! + * jQuery UI Touch Punch 0.2.3 + * + * Copyright 2011–2014, Dave Furfero + * Dual licensed under the MIT or GPL Version 2 licenses. + * + * Depends: + * jquery.ui.widget.js + * jquery.ui.mouse.js + */ +!function(a){function f(a,b){if(!(a.originalEvent.touches.length>1)){a.preventDefault();var c=a.originalEvent.changedTouches[0],d=document.createEvent("MouseEvents");d.initMouseEvent(b,!0,!0,window,1,c.screenX,c.screenY,c.clientX,c.clientY,!1,!1,!1,!1,0,null),a.target.dispatchEvent(d)}}if(a.support.touch="ontouchend"in document,a.support.touch){var e,b=a.ui.mouse.prototype,c=b._mouseInit,d=b._mouseDestroy;b._touchStart=function(a){var b=this;!e&&b._mouseCapture(a.originalEvent.changedTouches[0])&&(e=!0,b._touchMoved=!1,f(a,"mouseover"),f(a,"mousemove"),f(a,"mousedown"))},b._touchMove=function(a){e&&(this._touchMoved=!0,f(a,"mousemove"))},b._touchEnd=function(a){e&&(f(a,"mouseup"),f(a,"mouseout"),this._touchMoved||f(a,"click"),e=!1)},b._mouseInit=function(){var b=this;b.element.bind({touchstart:a.proxy(b,"_touchStart"),touchmove:a.proxy(b,"_touchMove"),touchend:a.proxy(b,"_touchEnd")}),c.call(b)},b._mouseDestroy=function(){var b=this;b.element.unbind({touchstart:a.proxy(b,"_touchStart"),touchmove:a.proxy(b,"_touchMove"),touchend:a.proxy(b,"_touchEnd")}),d.call(b)}}}(jQuery); \ No newline at end of file diff --git a/Webseiten/Docker - Build, Ship, and Run Any App, Anywhere_files/magnific-popup.css b/Webseiten/Docker - Build, Ship, and Run Any App, Anywhere_files/magnific-popup.css new file mode 100644 index 0000000..a530c65 --- /dev/null +++ b/Webseiten/Docker - Build, Ship, and Run Any App, Anywhere_files/magnific-popup.css @@ -0,0 +1,374 @@ +/* Magnific Popup CSS */ +.mfp-bg { + top: 0; + left: 0; + width: 100%; + height: 100%; + z-index: 1042; + overflow: hidden; + position: fixed; + background: #0b0b0b; + opacity: 0.8; + filter: alpha(opacity=80); } + +.mfp-wrap { + top: 0; + left: 0; + width: 100%; + height: 100%; + z-index: 1043; + position: fixed; + outline: none !important; + -webkit-backface-visibility: hidden; } + +.mfp-container { + text-align: center; + position: absolute; + width: 100%; + height: 100%; + left: 0; + top: 0; + padding: 0 8px; + -webkit-box-sizing: border-box; + -moz-box-sizing: border-box; + box-sizing: border-box; } + +.mfp-container:before { + content: ''; + display: inline-block; + height: 100%; + vertical-align: middle; } + +.mfp-align-top .mfp-container:before { + display: none; } + +.mfp-content { + position: relative; + display: inline-block; + vertical-align: middle; + margin: 0 auto; + text-align: left; + z-index: 1045; } + +.mfp-inline-holder .mfp-content, .mfp-ajax-holder .mfp-content { + width: 100%; + cursor: auto; } + +.mfp-ajax-cur { + cursor: progress; } + +.mfp-zoom-out-cur, .mfp-zoom-out-cur .mfp-image-holder .mfp-close { + cursor: -moz-zoom-out; + cursor: -webkit-zoom-out; + cursor: zoom-out; } + +.mfp-zoom { + cursor: pointer; + cursor: -webkit-zoom-in; + cursor: -moz-zoom-in; + cursor: zoom-in; } + +.mfp-auto-cursor .mfp-content { + cursor: auto; } + +.mfp-close, .mfp-arrow, .mfp-preloader, .mfp-counter { + -webkit-user-select: none; + -moz-user-select: none; + user-select: none; } + +.mfp-loading.mfp-figure { + display: none; } + +.mfp-hide { + display: none !important; } + +.mfp-preloader { + color: #CCC; + position: absolute; + top: 50%; + width: auto; + text-align: center; + margin-top: -0.8em; + left: 8px; + right: 8px; + z-index: 1044; } + .mfp-preloader a { + color: #CCC; } + .mfp-preloader a:hover { + color: #FFF; } + +.mfp-s-ready .mfp-preloader { + display: none; } + +.mfp-s-error .mfp-content { + display: none; } + +button.mfp-close, button.mfp-arrow { + overflow: visible; + cursor: pointer; + background: transparent; + border: 0; + -webkit-appearance: none; + display: block; + outline: none; + padding: 0; + z-index: 1046; + -webkit-box-shadow: none; + box-shadow: none; } +button::-moz-focus-inner { + padding: 0; + border: 0; } + +.mfp-close { + width: 44px; + height: 44px; + line-height: 44px; + position: absolute; + right: 0; + top: 0; + text-decoration: none; + text-align: center; + opacity: 0.65; + filter: alpha(opacity=65); + padding: 0 0 18px 10px; + color: #FFF; + font-style: normal; + font-size: 28px; + font-family: Arial, Baskerville, monospace; } + .mfp-close:hover, .mfp-close:focus { + opacity: 1; + filter: alpha(opacity=100); } + .mfp-close:active { + top: 1px; } + +.mfp-close-btn-in .mfp-close { + color: #333; } + +.mfp-image-holder .mfp-close, .mfp-iframe-holder .mfp-close { + color: #FFF; + right: -6px; + text-align: right; + padding-right: 6px; + width: 100%; } + +.mfp-counter { + position: absolute; + top: 0; + right: 0; + color: #CCC; + font-size: 12px; + line-height: 18px; + white-space: nowrap; } + +.mfp-arrow { + position: absolute; + opacity: 0.65; + filter: alpha(opacity=65); + margin: 0; + top: 50%; + margin-top: -55px; + padding: 0; + width: 90px; + height: 110px; + -webkit-tap-highlight-color: rgba(0, 0, 0, 0); } + .mfp-arrow:active { + margin-top: -54px; } + .mfp-arrow:hover, .mfp-arrow:focus { + opacity: 1; + filter: alpha(opacity=100); } + .mfp-arrow:before, .mfp-arrow:after, .mfp-arrow .mfp-b, .mfp-arrow .mfp-a { + content: ''; + display: block; + width: 0; + height: 0; + position: absolute; + left: 0; + top: 0; + margin-top: 35px; + margin-left: 35px; + border: medium inset transparent; } + .mfp-arrow:after, .mfp-arrow .mfp-a { + border-top-width: 13px; + border-bottom-width: 13px; + top: 8px; } + .mfp-arrow:before, .mfp-arrow .mfp-b { + border-top-width: 21px; + border-bottom-width: 21px; + opacity: 0.7; } + +.mfp-arrow-left { + left: 0; } + .mfp-arrow-left:after, .mfp-arrow-left .mfp-a { + border-right: 17px solid #FFF; + margin-left: 31px; } + .mfp-arrow-left:before, .mfp-arrow-left .mfp-b { + margin-left: 25px; + border-right: 27px solid #3F3F3F; } + +.mfp-arrow-right { + right: 0; } + .mfp-arrow-right:after, .mfp-arrow-right .mfp-a { + border-left: 17px solid #FFF; + margin-left: 39px; } + .mfp-arrow-right:before, .mfp-arrow-right .mfp-b { + border-left: 27px solid #3F3F3F; } + +.mfp-iframe-holder { + padding-top: 40px; + padding-bottom: 40px; } + .mfp-iframe-holder .mfp-content { + line-height: 0; + width: 100%; + max-width: 900px; } + .mfp-iframe-holder .mfp-close { + top: -40px; } + +.mfp-iframe-scaler { + width: 100%; + height: 0; + overflow: hidden; + padding-top: 56.25%; } + .mfp-iframe-scaler iframe { + position: absolute; + display: block; + top: 0; + left: 0; + width: 100%; + height: 100%; + box-shadow: 0 0 8px rgba(0, 0, 0, 0.6); + background: #000; } + +/* Main image in popup */ +img.mfp-img { + width: auto; + max-width: 100%; + height: auto; + display: block; + line-height: 0; + -webkit-box-sizing: border-box; + -moz-box-sizing: border-box; + box-sizing: border-box; + padding: 40px 0 40px; + margin: 0 auto; } + +/* The shadow behind the image */ +.mfp-figure { + line-height: 0; } + .mfp-figure:after { + content: ''; + position: absolute; + left: 0; + top: 40px; + bottom: 40px; + display: block; + right: 0; + width: auto; + height: auto; + z-index: -1; + box-shadow: 0 0 8px rgba(0, 0, 0, 0.6); + background: #444; } + .mfp-figure small { + color: #BDBDBD; + display: block; + font-size: 12px; + line-height: 14px; } + .mfp-figure figure { + margin: 0; } + +.mfp-bottom-bar { + margin-top: -36px; + position: absolute; + top: 100%; + left: 0; + width: 100%; + cursor: auto; } + +.mfp-title { + text-align: left; + line-height: 18px; + color: #F3F3F3; + word-wrap: break-word; + padding-right: 36px; } + +.mfp-image-holder .mfp-content { + max-width: 100%; } + +.mfp-gallery .mfp-image-holder .mfp-figure { + cursor: pointer; } + +@media screen and (max-width: 800px) and (orientation: landscape), screen and (max-height: 300px) { + /** + * Remove all paddings around the image on small screen + */ + .mfp-img-mobile .mfp-image-holder { + padding-left: 0; + padding-right: 0; } + .mfp-img-mobile img.mfp-img { + padding: 0; } + .mfp-img-mobile .mfp-figure:after { + top: 0; + bottom: 0; } + .mfp-img-mobile .mfp-figure small { + display: inline; + margin-left: 5px; } + .mfp-img-mobile .mfp-bottom-bar { + background: rgba(0, 0, 0, 0.6); + bottom: 0; + margin: 0; + top: auto; + padding: 3px 5px; + position: fixed; + -webkit-box-sizing: border-box; + -moz-box-sizing: border-box; + box-sizing: border-box; } + .mfp-img-mobile .mfp-bottom-bar:empty { + padding: 0; } + .mfp-img-mobile .mfp-counter { + right: 5px; + top: 3px; } + .mfp-img-mobile .mfp-close { + top: 0; + right: 0; + width: 35px; + height: 35px; + line-height: 35px; + background: rgba(0, 0, 0, 0.6); + position: fixed; + text-align: center; + padding: 0; } + } + +@media all and (max-width: 900px) { + .mfp-arrow { + -webkit-transform: scale(0.75); + transform: scale(0.75); } + + .mfp-arrow-left { + -webkit-transform-origin: 0; + transform-origin: 0; } + + .mfp-arrow-right { + -webkit-transform-origin: 100%; + transform-origin: 100%; } + + .mfp-container { + padding-left: 6px; + padding-right: 6px; } + } + +.mfp-ie7 .mfp-img { + padding: 0; } +.mfp-ie7 .mfp-bottom-bar { + width: 600px; + left: 50%; + margin-left: -300px; + margin-top: 5px; + padding-bottom: 5px; } +.mfp-ie7 .mfp-container { + padding: 0; } +.mfp-ie7 .mfp-content { + padding-top: 44px; } +.mfp-ie7 .mfp-close { + top: 0; + right: 0; + padding-top: 0; } diff --git a/Webseiten/Docker - Build, Ship, and Run Any App, Anywhere_files/modernizr.min.js b/Webseiten/Docker - Build, Ship, and Run Any App, Anywhere_files/modernizr.min.js new file mode 100644 index 0000000..40dd2a9 --- /dev/null +++ b/Webseiten/Docker - Build, Ship, and Run Any App, Anywhere_files/modernizr.min.js @@ -0,0 +1 @@ +window.Modernizr=function(e,t,n){function r(e){b.cssText=e}function o(e,t){return r(S.join(e+";")+(t||""))}function a(e,t){return typeof e===t}function i(e,t){return!!~(""+e).indexOf(t)}function c(e,t){for(var r in e){var o=e[r];if(!i(o,"-")&&b[o]!==n)return"pfx"==t?o:!0}return!1}function s(e,t,r){for(var o in e){var i=t[e[o]];if(i!==n)return r===!1?e[o]:a(i,"function")?i.bind(r||t):i}return!1}function u(e,t,n){var r=e.charAt(0).toUpperCase()+e.slice(1),o=(e+" "+k.join(r+" ")+r).split(" ");return a(t,"string")||a(t,"undefined")?c(o,t):(o=(e+" "+T.join(r+" ")+r).split(" "),s(o,t,n))}function l(){p.input=function(n){for(var r=0,o=n.length;o>r;r++)j[n[r]]=!!(n[r]in E);return j.list&&(j.list=!(!t.createElement("datalist")||!e.HTMLDataListElement)),j}("autocomplete autofocus list placeholder max min multiple pattern required step".split(" ")),p.inputtypes=function(e){for(var r,o,a,i=0,c=e.length;c>i;i++)E.setAttribute("type",o=e[i]),r="text"!==E.type,r&&(E.value=x,E.style.cssText="position:absolute;visibility:hidden;",/^range$/.test(o)&&E.style.WebkitAppearance!==n?(g.appendChild(E),a=t.defaultView,r=a.getComputedStyle&&"textfield"!==a.getComputedStyle(E,null).WebkitAppearance&&0!==E.offsetHeight,g.removeChild(E)):/^(search|tel)$/.test(o)||(r=/^(url|email)$/.test(o)?E.checkValidity&&E.checkValidity()===!1:E.value!=x)),P[e[i]]=!!r;return P}("search tel url email datetime date month week time datetime-local number range color".split(" "))}var d,f,m="2.8.3",p={},h=!0,g=t.documentElement,v="modernizr",y=t.createElement(v),b=y.style,E=t.createElement("input"),x=":)",w={}.toString,S=" -webkit- -moz- -o- -ms- ".split(" "),C="Webkit Moz O ms",k=C.split(" "),T=C.toLowerCase().split(" "),N={svg:"http://www.w3.org/2000/svg"},M={},P={},j={},$=[],D=$.slice,F=function(e,n,r,o){var a,i,c,s,u=t.createElement("div"),l=t.body,d=l||t.createElement("body");if(parseInt(r,10))for(;r--;)c=t.createElement("div"),c.id=o?o[r]:v+(r+1),u.appendChild(c);return a=["­",'"].join(""),u.id=v,(l?u:d).innerHTML+=a,d.appendChild(u),l||(d.style.background="",d.style.overflow="hidden",s=g.style.overflow,g.style.overflow="hidden",g.appendChild(d)),i=n(u,e),l?u.parentNode.removeChild(u):(d.parentNode.removeChild(d),g.style.overflow=s),!!i},z=function(t){var n=e.matchMedia||e.msMatchMedia;if(n)return n(t)&&n(t).matches||!1;var r;return F("@media "+t+" { #"+v+" { position: absolute; } }",function(t){r="absolute"==(e.getComputedStyle?getComputedStyle(t,null):t.currentStyle).position}),r},A=function(){function e(e,o){o=o||t.createElement(r[e]||"div"),e="on"+e;var i=e in o;return i||(o.setAttribute||(o=t.createElement("div")),o.setAttribute&&o.removeAttribute&&(o.setAttribute(e,""),i=a(o[e],"function"),a(o[e],"undefined")||(o[e]=n),o.removeAttribute(e))),o=null,i}var r={select:"input",change:"input",submit:"form",reset:"form",error:"img",load:"img",abort:"img"};return e}(),L={}.hasOwnProperty;f=a(L,"undefined")||a(L.call,"undefined")?function(e,t){return t in e&&a(e.constructor.prototype[t],"undefined")}:function(e,t){return L.call(e,t)},Function.prototype.bind||(Function.prototype.bind=function(e){var t=this;if("function"!=typeof t)throw new TypeError;var n=D.call(arguments,1),r=function(){if(this instanceof r){var o=function(){};o.prototype=t.prototype;var a=new o,i=t.apply(a,n.concat(D.call(arguments)));return Object(i)===i?i:a}return t.apply(e,n.concat(D.call(arguments)))};return r}),M.flexbox=function(){return u("flexWrap")},M.flexboxlegacy=function(){return u("boxDirection")},M.canvas=function(){var e=t.createElement("canvas");return!(!e.getContext||!e.getContext("2d"))},M.canvastext=function(){return!(!p.canvas||!a(t.createElement("canvas").getContext("2d").fillText,"function"))},M.webgl=function(){return!!e.WebGLRenderingContext},M.touch=function(){var n;return"ontouchstart"in e||e.DocumentTouch&&t instanceof DocumentTouch?n=!0:F(["@media (",S.join("touch-enabled),("),v,")","{#modernizr{top:9px;position:absolute}}"].join(""),function(e){n=9===e.offsetTop}),n},M.geolocation=function(){return"geolocation"in navigator},M.postmessage=function(){return!!e.postMessage},M.websqldatabase=function(){return!!e.openDatabase},M.indexedDB=function(){return!!u("indexedDB",e)},M.hashchange=function(){return A("hashchange",e)&&(t.documentMode===n||t.documentMode>7)},M.history=function(){return!(!e.history||!history.pushState)},M.draganddrop=function(){var e=t.createElement("div");return"draggable"in e||"ondragstart"in e&&"ondrop"in e},M.websockets=function(){return"WebSocket"in e||"MozWebSocket"in e},M.rgba=function(){return r("background-color:rgba(150,255,150,.5)"),i(b.backgroundColor,"rgba")},M.hsla=function(){return r("background-color:hsla(120,40%,100%,.5)"),i(b.backgroundColor,"rgba")||i(b.backgroundColor,"hsla")},M.multiplebgs=function(){return r("background:url(https://),url(https://),red url(https://)"),/(url\s*\(.*?){3}/.test(b.background)},M.backgroundsize=function(){return u("backgroundSize")},M.borderimage=function(){return u("borderImage")},M.borderradius=function(){return u("borderRadius")},M.boxshadow=function(){return u("boxShadow")},M.textshadow=function(){return""===t.createElement("div").style.textShadow},M.opacity=function(){return o("opacity:.55"),/^0.55$/.test(b.opacity)},M.cssanimations=function(){return u("animationName")},M.csscolumns=function(){return u("columnCount")},M.cssgradients=function(){var e="background-image:",t="gradient(linear,left top,right bottom,from(#9f9),to(white));",n="linear-gradient(left top,#9f9, white);";return r((e+"-webkit- ".split(" ").join(t+e)+S.join(n+e)).slice(0,-e.length)),i(b.backgroundImage,"gradient")},M.cssreflections=function(){return u("boxReflect")},M.csstransforms=function(){return!!u("transform")},M.csstransforms3d=function(){var e=!!u("perspective");return e&&"webkitPerspective"in g.style&&F("@media (transform-3d),(-webkit-transform-3d){#modernizr{left:9px;position:absolute;height:3px;}}",function(t){e=9===t.offsetLeft&&3===t.offsetHeight}),e},M.csstransitions=function(){return u("transition")},M.fontface=function(){var e;return F('@font-face {font-family:"font";src:url("https://")}',function(n,r){var o=t.getElementById("smodernizr"),a=o.sheet||o.styleSheet,i=a?a.cssRules&&a.cssRules[0]?a.cssRules[0].cssText:a.cssText||"":"";e=/src/i.test(i)&&0===i.indexOf(r.split(" ")[0])}),e},M.generatedcontent=function(){var e;return F(["#",v,"{font:0/0 a}#",v,':after{content:"',x,'";visibility:hidden;font:3px/1 a}'].join(""),function(t){e=t.offsetHeight>=3}),e},M.video=function(){var e=t.createElement("video"),n=!1;try{(n=!!e.canPlayType)&&(n=new Boolean(n),n.ogg=e.canPlayType('video/ogg; codecs="theora"').replace(/^no$/,""),n.h264=e.canPlayType('video/mp4; codecs="avc1.42E01E"').replace(/^no$/,""),n.webm=e.canPlayType('video/webm; codecs="vp8, vorbis"').replace(/^no$/,""))}catch(r){}return n},M.audio=function(){var e=t.createElement("audio"),n=!1;try{(n=!!e.canPlayType)&&(n=new Boolean(n),n.ogg=e.canPlayType('audio/ogg; codecs="vorbis"').replace(/^no$/,""),n.mp3=e.canPlayType("audio/mpeg;").replace(/^no$/,""),n.wav=e.canPlayType('audio/wav; codecs="1"').replace(/^no$/,""),n.m4a=(e.canPlayType("audio/x-m4a;")||e.canPlayType("audio/aac;")).replace(/^no$/,""))}catch(r){}return n},M.localstorage=function(){try{return localStorage.setItem(v,v),localStorage.removeItem(v),!0}catch(e){return!1}},M.sessionstorage=function(){try{return sessionStorage.setItem(v,v),sessionStorage.removeItem(v),!0}catch(e){return!1}},M.webworkers=function(){return!!e.Worker},M.applicationcache=function(){return!!e.applicationCache},M.svg=function(){return!!t.createElementNS&&!!t.createElementNS(N.svg,"svg").createSVGRect},M.inlinesvg=function(){var e=t.createElement("div");return e.innerHTML="",(e.firstChild&&e.firstChild.namespaceURI)==N.svg},M.smil=function(){return!!t.createElementNS&&/SVGAnimate/.test(w.call(t.createElementNS(N.svg,"animate")))},M.svgclippaths=function(){return!!t.createElementNS&&/SVGClipPath/.test(w.call(t.createElementNS(N.svg,"clipPath")))};for(var H in M)f(M,H)&&(d=H.toLowerCase(),p[d]=M[H](),$.push((p[d]?"":"no-")+d));return p.input||l(),p.addTest=function(e,t){if("object"==typeof e)for(var r in e)f(e,r)&&p.addTest(r,e[r]);else{if(e=e.toLowerCase(),p[e]!==n)return p;t="function"==typeof t?t():t,"undefined"!=typeof h&&h&&(g.className+=" "+(t?"":"no-")+e),p[e]=t}return p},r(""),y=E=null,function(e,t){function n(e,t){var n=e.createElement("p"),r=e.getElementsByTagName("head")[0]||e.documentElement;return n.innerHTML="x",r.insertBefore(n.lastChild,r.firstChild)}function r(){var e=y.elements;return"string"==typeof e?e.split(" "):e}function o(e){var t=v[e[h]];return t||(t={},g++,e[h]=g,v[g]=t),t}function a(e,n,r){if(n||(n=t),l)return n.createElement(e);r||(r=o(n));var a;return a=r.cache[e]?r.cache[e].cloneNode():p.test(e)?(r.cache[e]=r.createElem(e)).cloneNode():r.createElem(e),!a.canHaveChildren||m.test(e)||a.tagUrn?a:r.frag.appendChild(a)}function i(e,n){if(e||(e=t),l)return e.createDocumentFragment();n=n||o(e);for(var a=n.frag.cloneNode(),i=0,c=r(),s=c.length;s>i;i++)a.createElement(c[i]);return a}function c(e,t){t.cache||(t.cache={},t.createElem=e.createElement,t.createFrag=e.createDocumentFragment,t.frag=t.createFrag()),e.createElement=function(n){return y.shivMethods?a(n,e,t):t.createElem(n)},e.createDocumentFragment=Function("h,f","return function(){var n=f.cloneNode(),c=n.createElement;h.shivMethods&&("+r().join().replace(/[\w\-]+/g,function(e){return t.createElem(e),t.frag.createElement(e),'c("'+e+'")'})+");return n}")(y,t.frag)}function s(e){e||(e=t);var r=o(e);return!y.shivCSS||u||r.hasCSS||(r.hasCSS=!!n(e,"article,aside,dialog,figcaption,figure,footer,header,hgroup,main,nav,section{display:block}mark{background:#FF0;color:#000}template{display:none}")),l||c(e,r),e}var u,l,d="3.7.0",f=e.html5||{},m=/^<|^(?:button|map|select|textarea|object|iframe|option|optgroup)$/i,p=/^(?:a|b|code|div|fieldset|h1|h2|h3|h4|h5|h6|i|label|li|ol|p|q|span|strong|style|table|tbody|td|th|tr|ul)$/i,h="_html5shiv",g=0,v={};!function(){try{var e=t.createElement("a");e.innerHTML="",u="hidden"in e,l=1==e.childNodes.length||function(){t.createElement("a");var e=t.createDocumentFragment();return"undefined"==typeof e.cloneNode||"undefined"==typeof e.createDocumentFragment||"undefined"==typeof e.createElement}()}catch(n){u=!0,l=!0}}();var y={elements:f.elements||"abbr article aside audio bdi canvas data datalist details dialog figcaption figure footer header hgroup main mark meter nav output progress section summary template time video",version:d,shivCSS:f.shivCSS!==!1,supportsUnknownElements:l,shivMethods:f.shivMethods!==!1,type:"default",shivDocument:s,createElement:a,createDocumentFragment:i};e.html5=y,s(t)}(this,t),p._version=m,p._prefixes=S,p._domPrefixes=T,p._cssomPrefixes=k,p.mq=z,p.hasEvent=A,p.testProp=function(e){return c([e])},p.testAllProps=u,p.testStyles=F,p.prefixed=function(e,t,n){return t?u(e,t,n):u(e,"pfx")},g.className=g.className.replace(/(^|\s)no-js(\s|$)/,"$1$2")+(h?" js "+$.join(" "):""),p}(this,this.document); \ No newline at end of file diff --git a/Webseiten/Docker - Build, Ship, and Run Any App, Anywhere_files/portability_0.png b/Webseiten/Docker - Build, Ship, and Run Any App, Anywhere_files/portability_0.png new file mode 100644 index 0000000000000000000000000000000000000000..c0f5b7fe9df6d66476ce15ce29b3b15e0417d003 GIT binary patch literal 1404 zcmV-?1%vvDP)m%jqSDVkNBwnRkn*raBho6&_09ie8M;fQDNkfzX#11>b4f(V<}=&-mViE> zqfFE^or#n8XEFzK8$6dam$HZKbrg-*g>UT7l_OP=UPWVs!ApY6)b?-kj~&-@-V2i> zwGR+Jhc>m{Vh^)7BQWGO40x*n7tes(Qkk&tCwTs^GU8)a$2oR)LmJ;<_*Kxdiwf~i z#Du`(%)`Wxn5dx%Z?ki!1hcW7d+oem0d_j(nFi33t`SUJ6W*sjBZS5_kf4FB7<#{> z5qiEM0gV`<0WBMhtD`kSa4H<%?`sT$NkU8*VciS{?(=drjd`XiFzzKI0VbZME(XsF z0aA+hTc1>0AZ7@HB|8$?1I}gRxN)Ve8(NNcnnEf|f`I{k7kEB|132?(BLppaza~#5 zTKWLt6y#i{>Y7PtvmhgouyT9{!_;?IaF0IKii^As5Zc9vc&Ud#DzgC5#^dpJ?8;^2 z37mT+3|PrRA3af7V~foFO8>7(+M0u%V!kiv$^3g}AmCUU1mImp91k&R%X{F_HnefM zXRgI-1hwnY;MS9}vCmbC5y{(ysvlB$1Briv{ZynKhKfGF!`KO>HkGq>$VsedtkRsF z5SLqtL`ZN7LzS(Y3^yj`qf*W{U+^%PizrUeVgWo((=?azU6!(Io~Ljo;=Y@ ze9smW(+Y-`N$}fl&UK8YF8*sma5g!)uy=_8>);x63JWn_RB5jBl>7z(%OoUrscjGt zTG#kT)`;ZxWr9}T9T8TYjDXgXHBxy}^q36w7#i6^C89pYv{pGLXiEGsA%!RoY4Fau zC?+9QTBUw$a_6L1Mx@Ub*~!HLwK4W+y)Az1oKjEpKyP1aC1V~Tkrm29(r1w70B}2{ zO$N02H^RM^j4FcB2ReCn9q{IKhFbls<)9Z;#F%o>p$l|c?3VtIBR#Fo`~gjsfi)VO z$M0TMpmTGVEUjcJH%klOQMoPGBEj4QgtFjbU3AG5gS(2@>QxqCY>@3&#C{+{pQ46v z>BN&M_6ZiTbB|Y=kx?$Q-D|fBmBA5gXhw&it5>+(F)<+sP!#kjB&aqt6DQ{~pe^oT1&FxJgp$N5je7{)D0$jLwtKB- z0%cEifkP{;>0?i-~=*88N~Qu}Heg-pBX5sy4j@JkPWJKNz^CxDxfjKwEH3X2gjzODB+N0F&gc z@qFFDcl7*x1SpO@0k(nNL{~F^n~!S#-=8@JY-pJMzz@&<6JP)>^~@FT)vr$g0000< KMNUMnLSTX)=$O6$ literal 0 HcmV?d00001 diff --git a/Webseiten/Docker - Build, Ship, and Run Any App, Anywhere_files/run.png b/Webseiten/Docker - Build, Ship, and Run Any App, Anywhere_files/run.png new file mode 100644 index 0000000000000000000000000000000000000000..72e94979a5ee02f00bd049f9f61c93cc87e5b2e8 GIT binary patch literal 2230 zcmaJ@X;@Qd7QO`HgjE(1t%+WO%7BoC5J)nK&B`K%!9ZjY#gJSeKo)K;5I{sIRS@E& zRjf-DVqH)yAc`wc2bHZAq|_o*t+FVT#ky3dbkJTb*m>p|=icYu?>pyt-}jvFob%%= z4hs#mwfevc007(IAfW_Zi_lMwn}`0n%pfOpS&WFHkZ?@`k|~2BfTz&JLtwBa{X?3WR|1P@+=JAwIeC6%kY_ zIK)W0m?G8+pd@8bHVlPlhepV=Q{+qq@x#?1ThBrTR1hKq^{Q00j-}@i-|Di^{fwJT z1m8lC6b|u^q@u)Opg;pdAe}__mQ$#{pg)sDrBi(wR4>qnLZy)@G%}UuP4!_>m@FzC zoPCIBG+2?qk_ZE4W1$v@n1mo&7MYxxnMul|ku-23naX4`$rK;5kB>Ks@YZFi5t-gw zt#g}G5JEaRtkfb(jT)R$l*Mb(5e^Z}^p7K`wC`lqy4fLMGPi|=EIod3N`X{6{JSyxQaiye(&YZOoB>_MixS_G6PZsz#0|!_QWjZ`*Wea zS8tZ9cz-Uw@8y!wWXLmp{f|D+xzOR6*}j`v)Oa`dkQyC!7@g{kBwHZ>U{?hTc@g^l z@k7&T0~Grk|J1!H|639IUOfpOE!bz(EVY-IU9tk5uS&Ot^MbJd^28Cej;EUsQ#P0W zdqt!FVE0hZ`4@u|)n2>{gZumr8psEXO?$p9AMA2W?!BkZ9F^py698AoR_}cK#Z#|5 z2u}u#SG}+d4?wwkL2ma8Tp?wLTN`gW=h2U^zZqqCOvhP@9Pjuk9Gw^6PYktk*MtpR#vKwD~WK)}1}XInp^y@IFLLZU3d!!l$=@@2s%58C`k? zGC5Q%7zrZSRI%1=-)9qMpA9!PuaDX45WVHA=!#Me}d&rW=Hre~VJcPjs4j^DCDwGT4fBF`9%E2?)HPH?Ic*p<~Z zAUD3#HEmsz?Am(a>B_7oYD;aLGu(8#J){k_9OM@bL+Xhg!jH^<4PfT>Ulaj#Cz^)2aCWB0~Z=pu(>LVv1l-5Kic;yQh5RgIIOV2~HvitkLzs*gCo&^GvW z$mrOz6|v7xlODI-I(K%%%gF6RobNXoieD3IkA3DdewUsxoZIK?qBX8-hY~03;Oq5< zo4fTZ-E~oH{KfNmM-yE7E~h762#Y)kI5kc_Ofj>+9tF z{Km(j)Yy6+kua3sR4Qgapgja>b@b>-Tguvc!KXz5W%nY<<1ed`e^6_pC~QOikkr@n zo385iz=l;1j9IP5VM21ND*c0O!Z^WM1!lDTGT#=;z&Qa;G+w_sH)Saxh!e@5D zBi7r$=nk&>pqyV~XuwQ5q`zEp%pvB${PxPT<;(W(u`5~_<7mT6dFJ4peB@iebaD(Z z9V;_ElIG+e#1^i+et6_-m%_c@kA8gItsrFOEmE2>ai`oeA!Ngb+m)8*9yeH4W#;Ex zFBMiEGOqRD7_~MAGybG2T@;@zZl2oHD(b{wUe$JrhOF7`W5g_c;g!Ihr1L9fH;0K! z?_P^`iGGy!iO%lGUAO$4s1rYSh^)+-7dAI@ylRp{C#smkU~XN-g0hk;BslqpYrCKY4F(#3I(@k^tXC5fbrvHA5+ zS45nAWg1y>yuQO$EIsUg>H)jNvFi-W@BXG1a@7!GI9AvhWO$x?*uJOdHLfmBa~kGY z2gQ|$jng_}h@ZP70bA(TXMrP!dbV59E`KEKCkrN}v~CaXq{F7qGmXZ)pDgeelB~7^ zh8zUIg@j7jm(tfi`R;xKv#1}t%YQ3xUvV8Us$9UERG!?A#apo21d_wBmW!EMvAk0I ziRRkR=PaBj&2l9<*9gMfjrw!*2`rqsg{9}71T(m5+8*{_C$$^Uakl`NQ4(?4{p^_H z61>Ggz{59>LH%#3LE#Tf^DAr`^URxo2tGS_hl?dJaCz1VxPh40PMd-4 WuS(B%gzHE%H;G_TsIZ#9x!`wHVr=mM literal 0 HcmV?d00001 diff --git a/Webseiten/Docker - Build, Ship, and Run Any App, Anywhere_files/scrollspy.min.js b/Webseiten/Docker - Build, Ship, and Run Any App, Anywhere_files/scrollspy.min.js new file mode 100644 index 0000000..efd42ae --- /dev/null +++ b/Webseiten/Docker - Build, Ship, and Run Any App, Anywhere_files/scrollspy.min.js @@ -0,0 +1 @@ +!function(t,e){t.fn.extend({scrollspy:function(n){var a={namespace:"scrollspy",activeClass:"active",animate:!1,offset:0,container:e};n=t.extend({},a,n);var o=function(t,e){return parseInt(t,10)+parseInt(e,10)},r=function(e){for(var n=[],a=0;a0){var s=Math.floor(f.offset().top),i=s+Math.floor(f.outerHeight());n.push({element:f,hash:r,top:s,bottom:i})}}return n},f=function(e,n){for(var a=0;a0){var s=o(f.offset().top,n.offset);n.animate?t("html, body").animate({scrollTop:s},1e3):e.scrollTo(0,s),a.preventDefault()}})}var v=r(l);i.bind("scroll."+n.namespace,function(){for(var e,r={top:o(t(this).scrollTop(),Math.abs(n.offset)),left:t(this).scrollLeft()},i=0;i=c.top&&r.top^EHC>FoFKbJL&P5hYJ#v%j08EpMpQ|+=#>J6y7SE+=txN@)Xg?K zX=kultd>gaLgLK2vI@SghPMd1iMC8@garnEQRT>p-xpBWNTDw3%Ys;IrgUUfqSh4Z zinM}crL&wYmO~gd5H=a)ke6aC77IliDWg#j6nbT0K;dRY?wznlI;;Yt=%XPAimn#jndBOcV+zadvV$dL%cZUA#f?9(p|kOd6JXU%}ML&b?jn9>LpFoSXRCRKylSZPQQ$-tCiurn)0qd}Wv9LxXYi4q3GfUHu zNlcmI;gki*voM`U0c$qG9*{EC18g0EQ@MZT0&5{3foDB($j_-Z$lq;l9CDlw(rBaquO-sh z^e9y-DPUGah`_2Z2+ zcu|b@8Bc|~Q&X$1oCCluhK4ot*dAY(qf6{q;{lDtm-Wh>WC-CrV9EKkIrPQ72G0#yAvvLd(wT96MNt) z2gxhC%EquAE&|g)#uyh85iG#CU>e96<3b{W1sE4h0~upnNJOvzK*kss5)mxG zxL_K{7~?`Bf&~~COamEXTu4N)0ONvbAY+URi3k>8Trdq}jBz0m!2*m6rh$wxE+isY zfN{YzkTJ%EL<9>kE|>-~#<-A(U;)Mj(?G@;7ZMRHz_?%<$Qa{7B7y}N7fb^gV_Zl? zumIzNX&~b(;>t`u@FxbqQ+{FaINzDPS>J+30ZG2p^g!NCO6D&DItiy9*4cCBJ$A_Q%dM_?|yXftr9Yy99&CADE?`nLTwk|!9k##($U*AqOr{9Rp?O7djrfsRA5s>CyMPT7R$lq=9YR zeq?vJw868t?O>nb`v`%|SiL-JQhy^6{lVYjKG~EVoO}J!hJDAqmX>!e=&IX6Wvk`uE@R_EY)~DIhb3FUt}LSwE`Lv9a~yo_FV* zn)X;m#?ym-Yj~&O)&Xaphz#5IGCTHCUi;eh=Vt65aQh=oHICcNmp4x?I9PJ{we|i# vhyM25j;(Eft(^76Po+N`cy+?jZ(50?>~l9Tm&RDMCsiF&%Iw=G&s*^i1XHmf literal 0 HcmV?d00001 diff --git a/Webseiten/Docker - Build, Ship, and Run Any App, Anywhere_files/track.js b/Webseiten/Docker - Build, Ship, and Run Any App, Anywhere_files/track.js new file mode 100644 index 0000000..bc5d9ec --- /dev/null +++ b/Webseiten/Docker - Build, Ship, and Run Any App, Anywhere_files/track.js @@ -0,0 +1,40 @@ +/*! + * Shim for MutationObserver interface + * Author: Graeme Yeates (github.com/megawac) + * Repository: https://github.com/megawac/MutationObserver.js + * License: WTFPL V2, 2004 (wtfpl.net). + * Though credit and staring the repo will make me feel pretty, you can modify and redistribute as you please. + * Attempts to follow spec (http:// www.w3.org/TR/dom/#mutation-observers) as closely as possible for native javascript + * See https://github.com/WebKit/webkit/blob/master/Source/WebCore/dom/MutationObserver.cpp for current webkit source c++ implementation + */ +window.MutationObserver=window.MutationObserver||window.WebKitMutationObserver||function(e){"use strict";function t(e){this._watched=[],this._listener=e}function i(e){!function i(){var r=e.takeRecords();r.length&&e._listener(r,e),e._timeout=setTimeout(i,t._period)}()}function r(t){var i={type:null,target:null,addedNodes:[],removedNodes:[],previousSibling:null,nextSibling:null,attributeName:null,attributeNamespace:null,oldValue:null};for(var r in t)p(i,r)&&t[r]!==e&&(i[r]=t[r]);return i}function n(e,t){var i=s(e,t);return function(r){var n,l=r.length;t.attr&&i.attr&&o(r,e,i.attr,t.afilter),(t.kids||t.descendents)&&(n=a(r,e,i,t)),(n||r.length!==l)&&(i=s(e,t))}}function o(e,t,i,n){for(var o,a,s={},l=t.attributes,u=l.length;u--;)o=l[u],a=o.name,(!n||p(n,a))&&(o.value!==i[a]&&e.push(r({type:"attributes",target:t,attributeName:a,oldValue:i[a],attributeNamespace:o.namespaceURI})),s[a]=!0);for(a in i)s[a]||e.push(r({target:t,type:"attributes",attributeName:a,oldValue:i[a]}))}function a(t,i,n,a){function s(e,i,n,s,l){for(var u,d,f,p=e.length-1,g=-~((p-l)/2);f=e.pop();)u=n[f.i],d=s[f.j],a.kids&&g&&Math.abs(f.i-f.j)>=p&&(t.push(r({type:"childList",target:i,addedNodes:[u],removedNodes:[u],nextSibling:u.nextSibling,previousSibling:u.previousSibling})),g--),a.attr&&d.attr&&o(t,u,d.attr,a.afilter),a.charData&&3===u.nodeType&&u.nodeValue!==d.charData&&t.push(r({type:"characterData",target:u})),a.descendents&&c(u,d)}function c(i,n){for(var p,g,h,m,C,v,y,k=i.childNodes,E=n.kids,P=k.length,_=E?E.length:0,b=0,F=0,x=0;P>F||_>x;)v=k[F],C=E[x],y=C&&C.node,v===y?(a.attr&&C.attr&&o(t,v,C.attr,a.afilter),a.charData&&C.charData!==e&&v.nodeValue!==C.charData&&t.push(r({type:"characterData",target:v})),g&&s(g,i,k,E,b),a.descendents&&(v.childNodes.length||C.kids&&C.kids.length)&&c(v,C),F++,x++):(d=!0,p||(p={},g=[]),v&&(p[h=u(v)]||(p[h]=!0,-1===(m=l(E,v,x))?a.kids&&(t.push(r({type:"childList",target:i,addedNodes:[v],nextSibling:v.nextSibling,previousSibling:v.previousSibling})),b++):g.push({i:F,j:m})),F++),y&&y!==k[F]&&(p[h=u(y)]||(p[h]=!0,-1===(m=f(k,y,F))?a.kids&&(t.push(r({type:"childList",target:n.node,removedNodes:[y],nextSibling:E[x+1],previousSibling:E[x-1]})),b--):g.push({i:m,j:x})),x++));g&&s(g,i,k,E,b)}var d;return c(i,n),d}function s(e,t){var i=!0;return function r(e){var n={node:e};return!t.charData||3!==e.nodeType&&8!==e.nodeType?(t.attr&&i&&1===e.nodeType&&(n.attr=d(e.attributes,function(e,i){return(!t.afilter||t.afilter[i.name])&&(e[i.name]=i.value),e},{})),i&&(t.kids||t.charData||t.attr&&t.descendents)&&(n.kids=c(e.childNodes,r)),i=t.descendents):n.charData=e.nodeValue,n}(e)}function l(e,t,i){return f(e,t,i,g("node"))}function u(e){try{return e.id||(e[m]=e[m]||h++)}catch(t){try{return e.nodeValue}catch(i){return h++}}}function c(e,t){for(var i=[],r=0;ri;i++)e[i]=decodeURIComponent(e[i]);return e},e}();e.DocCookieUtility=t}(t=e.doc_cookies||(e.doc_cookies={}))}(e||(e={}));var e,t=this&&this.__extends||function(e,t){function i(){this.constructor=e}for(var r in t)t.hasOwnProperty(r)&&(e[r]=t[r]);e.prototype=null===t?Object.create(t):(i.prototype=t.prototype,new i)};!function(e){var i;!function(e){var i=function(e){function i(t){e.call(this),this.cookieDomain=t}return t(i,e),i.prototype.setCookie=function(e,t){return this.setItem(e,t,1/0,"/",this.cookieDomain),this.getItem(e)},i.prototype.removeCookie=function(e){var t=this.getItem(e);return t?(this.removeItem(e,"/",this.cookieDomain),t):""},i}(e.DocCookieUtility);e.CaptoraDocCookieUtility=i}(i=e.doc_cookies||(e.doc_cookies={}))}(e||(e={}));var e;!function(e){var t=function(){function e(){}return e.COOKIE_NAMES={attribUrlCookieName:"colodin_attrib_url",attributableFlagCookieName:"colodin_attributable",oldCookieName:"_EXT_TRACKER_COOKIE_",origReferrerCookieName:"colodin_orig_referrer",thankYouPageReferrer:"colodin_thank_you_page_referrer",thankYouPageUrl:"colodin_thank_you_page_url",uuidCookieName:"colodin_id"},e.HIDDEN_FIELD_NAMES={attribUrl:"cpcampaign",attributable:"cpfirstentry",origReferrer:"cpreferrer"},e.PIXEL_SRC="pixel.captora.com/img/pix.gif",e.PIXEL_CALLS=["capture_card_id","capture_card_cta_id","cta_title","config_id","segment_id"],e}();e.PixelConstants=t}(e||(e={}));var e;!function(e){var t;!function(e){var t=function(){function t(e){this.pagegroups=[],this.thankYouPagePatterns=[],"undefined"!=typeof e&&("undefined"!=typeof e.domain&&this.setDomain(e.domain),"undefined"!=typeof e.fieldFilterConfig&&this.setFieldFilterConfig(e.fieldFilterConfig),"undefined"!=typeof e.formFieldMappings&&this.setFormFieldMappings(e.formFieldMappings),"undefined"!=typeof e.pagegroups&&this.setPagegroups(e.pagegroups),"undefined"!=typeof e.thankYouPagePatterns&&this.setThankYouPagePatterns(e.thankYouPagePatterns),"undefined"!=typeof e.uuid&&this.setUuid(e.uuid))}return t.prototype.setDomain=function(e){return this.domain=e,this},t.prototype.setFieldFilterConfig=function(e){return this.fieldFilterConfig=e,this},t.prototype.setFormFieldMappings=function(e){return this.formFieldMappings=e,this},t.prototype.setPagegroups=function(e){return this.pagegroups=e,this},t.prototype.setThankYouPagePatterns=function(e){return this.thankYouPagePatterns=e,this},t.prototype.setUuid=function(e){return this.uuid=e,this},t.prototype.getDomain=function(){return this.domain},t.prototype.getFieldFilterConfig=function(){return this.fieldFilterConfig},t.prototype.getFormFieldMappings=function(){return this.formFieldMappings},t.prototype.getPagegroups=function(){return this.pagegroups},t.prototype.getThankYouPagePatterns=function(){return this.thankYouPagePatterns},t.prototype.getUuid=function(){return this.uuid},t.prototype.build=function(){return new e.PixelConfig(this)},t}();e.PixelConfigBuilder=t}(t=e.pixel_config||(e.pixel_config={}))}(e||(e={}));var e;!function(e){var t;!function(e){var t=function(){function e(e){this.domain=e.getDomain(),this.fieldFilterConfig=e.getFieldFilterConfig(),this.formFieldMappings=e.getFormFieldMappings(),this.pagegroups=e.getPagegroups(),this.thankYouPagePatterns=e.getThankYouPagePatterns(),this.uuid=e.getUuid()}return e.prototype.getDomain=function(){return this.domain},e.prototype.getFieldFilterConfig=function(){return this.fieldFilterConfig},e.prototype.getFormFieldMappings=function(){return this.formFieldMappings},e.prototype.getPagegroups=function(){return this.pagegroups},e.prototype.getThankYouPagePatterns=function(){return this.thankYouPagePatterns},e.prototype.getUuid=function(){return this.uuid},e}();e.PixelConfig=t}(t=e.pixel_config||(e.pixel_config={}))}(e||(e={}));var e;!function(e){var t;!function(e){var t=function(){function t(){}return t.newElement=function(t,i){return new e.ElementApi(t,i)},t}();e.ElementApiFactory=t}(t=e.element_api||(e.element_api={}))}(e||(e={}));var e;!function(e){var t;!function(e){var t=function(){function t(e,t){this.element=e,this.trackerClient=t}return t.prototype.getAttributes=function(){for(var e={},t=0;t-1&&t.length<=1)return!0;for(var n=0;n-1&&t.length<=1)return!0}return!1},t.prototype.addEventListenerPolyfill=function(e){if(e)for(var t=e.split(","),i=0;i-1)return!0;return!1},e.handleOldCookie=function(e,i){var r=i.split("__SEP__");e.setCookie(t.COOKIE_NAMES.uuidCookieName,r[0].split("=")[1]);var n=r[1].substr(r[1].indexOf("=")+1,r[1].length-1).split(",");n[0]&&e.setCookie(t.COOKIE_NAMES.origReferrerCookieName,n[0]),"Captora"===n[1]&&e.setCookie(t.COOKIE_NAMES.attributableFlagCookieName,String(!0)),n[2]&&e.setCookie(t.COOKIE_NAMES.attribUrlCookieName,n[2]),e.removeCookie(t.COOKIE_NAMES.oldCookieName)},e.getTrackingElements=function(){return e.HTMLCollectionToArray(document.querySelectorAll("input")).concat(e.HTMLCollectionToArray(document.querySelectorAll("select"))).concat(e.HTMLCollectionToArray(document.querySelectorAll("textarea"))).concat(e.HTMLCollectionToArray(document.querySelectorAll(".cp_element a"))).concat(e.HTMLCollectionToArray(document.querySelectorAll(".cp_element img")))},e.findHiddenFieldNameKey=function(e){var i="__c"===e.substr(-3)?e.substring(0,e.length-3):e;if("cpreferer"===i)return"origReferrer";for(var r in t.HIDDEN_FIELD_NAMES)if(t.HIDDEN_FIELD_NAMES.hasOwnProperty(r)&&i===t.HIDDEN_FIELD_NAMES[r])return r;return null},e.HTMLCollectionToArray=function(e){for(var t=[],i=e.length,r=0;i>r;r++)t.push(e[r]);return t},e.getMergedObject=function(e,t){var i={};for(var r in e)e.hasOwnProperty(r)&&(i[r]=e[r]);for(var n in t)t.hasOwnProperty(n)&&(i[n]=t[n]);return i},e.extractRootDomain=function(e){var t=e.match(/^https?\:\/\/([^\/?#]+)(?:[\/?#]|$)/i)[1],i=-2;return t.indexOf(".co.uk")>-1&&(i=-3),t.split(".").slice(i).join(".")},e.getJSONFile=function(e,t){var i;window.XDomainRequest&&"function"==typeof window.XDomainRequest?(i=new window.XDomainRequest,i.onload=function(){var e=JSON.parse(i.responseText);t&&t(e)},i.open("GET",e,!0),i.send()):(i=new XMLHttpRequest,i.onreadystatechange=function(){if(4===i.readyState&&200===i.status){var e=JSON.parse(i.responseText);t&&t(e)}},i.open("GET",e),i.send())},e}();e.TrackerUtility=i}(e||(e={}));var e;!function(e){var t;!function(t){var i=e.element_api.ElementApiFactory,r=function(){function t(t){var i=this;this.eventDelegateHandler=function(t){t=t||window.event;var r=t.target,n=t.currentTarget,o={};if(t&&t.type)switch(r.tagName){case"INPUT":case"SELECT":case"TEXTAREA":if("ALL"===i.pixelConfig.getFieldFilterConfig().filterMode||"password"===r.type)return;if(n.type&&"password"===n.type.toLowerCase())return;if("focus"===t.type||"blur"===t.type||"change"===t.type)if(r.form)for(var a=e.TrackerUtility.HTMLCollectionToArray(r.form.getElementsByTagName("INPUT")).concat(e.TrackerUtility.HTMLCollectionToArray(r.form.getElementsByTagName("SELECT"))).concat(e.TrackerUtility.HTMLCollectionToArray(r.form.getElementsByTagName("TEXTAREA"))),s=0;sn;n++){var o=i[n].name.replace("data-",""),a=i[n].value;if(e.PixelConstants.PIXEL_CALLS.indexOf(o)>-1){var s={};s["GOAL_"+o]=a,this.firePixel(s)}}},t.prototype.firePixel=function(t,i){void 0===i&&(i=!1);var r=t?e.TrackerUtility.getMergedObject(this.defaultPixelParams,t):this.defaultPixelParams;r.rand=Math.random();var n="";for(var o in r)r.hasOwnProperty(o)&&(n+=o+"="+encodeURIComponent(r[o])+"&");n+="timestamp="+(new Date).getTime();var a=document.location.protocol+"//"+e.PixelConstants.PIXEL_SRC+"?"+n,s=new Image;if(a.length>8500&&(a=a.substr(0,8500)),s.src=a,i===!0)for(var l=new Date,u=l.getTime()+500;l.getTime()<=u;)l=new Date},t.prototype.mutationObserverCallback=function(t){for(var r=0;r1){var o=t.elements[i.name][0];return void(o!==i&&(o.parentNode.removeChild(o),i.value=this.progressiveProfile[r]))}}for(var a in e.PixelConstants.HIDDEN_FIELD_NAMES)e.PixelConstants.HIDDEN_FIELD_NAMES.hasOwnProperty(a)&&this.progressiveProfile.hasOwnProperty(a)&&(e.TrackerFormUtility.updateOrInjectHiddenField(t,t.elements[e.PixelConstants.HIDDEN_FIELD_NAMES[a]],e.PixelConstants.HIDDEN_FIELD_NAMES[a],this.progressiveProfile[a]),e.TrackerFormUtility.updateOrInjectHiddenField(t,t.elements[e.PixelConstants.HIDDEN_FIELD_NAMES[a]+"__c"],e.PixelConstants.HIDDEN_FIELD_NAMES[a]+"__c",this.progressiveProfile[a]),"origReferrer"===a&&(e.TrackerFormUtility.updateOrInjectHiddenField(t,t.elements.cpreferer,"cpreferer",this.progressiveProfile.origReferrer),e.TrackerFormUtility.updateOrInjectHiddenField(t,t.elements.cpreferer__c,"cpreferer__c",this.progressiveProfile.origReferrer)))}},t.prototype.addSubmitEventListener=function(e){i.newElement(e,this).addEventListenerPolyfill("submit")},t.prototype.handleRuntimeFormInjection=function(t){var r=e.TrackerUtility.getTrackingElements();this.addHiddenFieldsToForm(t),this.addSubmitEventListener(t);for(var n=0;n-1&&""!==e[t].trim()){this.defaultPixelParams.url=this.progressiveProfile.stateUrl,this.defaultPixelParams.referrer=this.progressiveProfile.stateReferrer,this.firePixel({GOAL_TRACKURL:this.progressiveProfile.attribUrl});break}},t}();t.TrackerClient=r}(t=e.tracker_client||(e.tracker_client={}))}(e||(e={}));/*! + * @copyright Captora, Inc. 2015. + * Any modifications to this code will not be supported by Captora and its APIs. + */ +var i;!function(t){var i=e.tracker_client.TrackerClient,r=e.TrackerUtility,n=e.element_api.ElementApiFactory,o=e.pixel_config.PixelConfigBuilder,a=null,s=[],l=[],u=null;if("undefined"==typeof window.fireColodinPixel){window.docReady(function(){var e=document.getElementsByTagName("BODY")[0];u=new MutationObserver(function(e){l.push(e)}),u.observe(e,{childList:!0,subtree:!0})}),window.fireColodinPixel=function(e){s.push(e)};var c="function"==typeof window.cpTrackingClientConfig?window.cpTrackingClientConfig:null;window.cpTrackingClientConfig=function(e){for(a=new i(new o(e).build());s.length;)a.firePixel.call(a,s.shift());window.fireColodinPixel=function(e){a.firePixel.call(a,e)};var t=function(){for(var e=document.getElementsByTagName("BODY")[0],t=r.getTrackingElements(),i=0;ia?this[a+this.length]:this[a]:d.call(this)},pushStack:function(a){var b=n.merge(this.constructor(),a);return b.prevObject=this,b.context=this.context,b},each:function(a,b){return n.each(this,a,b)},map:function(a){return this.pushStack(n.map(this,function(b,c){return a.call(b,c,b)}))},slice:function(){return this.pushStack(d.apply(this,arguments))},first:function(){return this.eq(0)},last:function(){return this.eq(-1)},eq:function(a){var b=this.length,c=+a+(0>a?b:0);return this.pushStack(c>=0&&b>c?[this[c]]:[])},end:function(){return this.prevObject||this.constructor(null)},push:f,sort:c.sort,splice:c.splice},n.extend=n.fn.extend=function(){var a,b,c,d,e,f,g=arguments[0]||{},h=1,i=arguments.length,j=!1;for("boolean"==typeof g&&(j=g,g=arguments[h]||{},h++),"object"==typeof g||n.isFunction(g)||(g={}),h===i&&(g=this,h--);i>h;h++)if(null!=(a=arguments[h]))for(b in a)c=g[b],d=a[b],g!==d&&(j&&d&&(n.isPlainObject(d)||(e=n.isArray(d)))?(e?(e=!1,f=c&&n.isArray(c)?c:[]):f=c&&n.isPlainObject(c)?c:{},g[b]=n.extend(j,f,d)):void 0!==d&&(g[b]=d));return g},n.extend({expando:"jQuery"+(m+Math.random()).replace(/\D/g,""),isReady:!0,error:function(a){throw new Error(a)},noop:function(){},isFunction:function(a){return"function"===n.type(a)},isArray:Array.isArray,isWindow:function(a){return null!=a&&a===a.window},isNumeric:function(a){return!n.isArray(a)&&a-parseFloat(a)+1>=0},isPlainObject:function(a){return"object"!==n.type(a)||a.nodeType||n.isWindow(a)?!1:a.constructor&&!j.call(a.constructor.prototype,"isPrototypeOf")?!1:!0},isEmptyObject:function(a){var b;for(b in a)return!1;return!0},type:function(a){return null==a?a+"":"object"==typeof a||"function"==typeof a?h[i.call(a)]||"object":typeof a},globalEval:function(a){var b,c=eval;a=n.trim(a),a&&(1===a.indexOf("use strict")?(b=l.createElement("script"),b.text=a,l.head.appendChild(b).parentNode.removeChild(b)):c(a))},camelCase:function(a){return a.replace(p,"ms-").replace(q,r)},nodeName:function(a,b){return a.nodeName&&a.nodeName.toLowerCase()===b.toLowerCase()},each:function(a,b,c){var d,e=0,f=a.length,g=s(a);if(c){if(g){for(;f>e;e++)if(d=b.apply(a[e],c),d===!1)break}else for(e in a)if(d=b.apply(a[e],c),d===!1)break}else if(g){for(;f>e;e++)if(d=b.call(a[e],e,a[e]),d===!1)break}else for(e in a)if(d=b.call(a[e],e,a[e]),d===!1)break;return a},trim:function(a){return null==a?"":(a+"").replace(o,"")},makeArray:function(a,b){var c=b||[];return null!=a&&(s(Object(a))?n.merge(c,"string"==typeof a?[a]:a):f.call(c,a)),c},inArray:function(a,b,c){return null==b?-1:g.call(b,a,c)},merge:function(a,b){for(var c=+b.length,d=0,e=a.length;c>d;d++)a[e++]=b[d];return a.length=e,a},grep:function(a,b,c){for(var d,e=[],f=0,g=a.length,h=!c;g>f;f++)d=!b(a[f],f),d!==h&&e.push(a[f]);return e},map:function(a,b,c){var d,f=0,g=a.length,h=s(a),i=[];if(h)for(;g>f;f++)d=b(a[f],f,c),null!=d&&i.push(d);else for(f in a)d=b(a[f],f,c),null!=d&&i.push(d);return e.apply([],i)},guid:1,proxy:function(a,b){var c,e,f;return"string"==typeof b&&(c=a[b],b=a,a=c),n.isFunction(a)?(e=d.call(arguments,2),f=function(){return a.apply(b||this,e.concat(d.call(arguments)))},f.guid=a.guid=a.guid||n.guid++,f):void 0},now:Date.now,support:k}),n.each("Boolean Number String Function Array Date RegExp Object Error".split(" "),function(a,b){h["[object "+b+"]"]=b.toLowerCase()});function s(a){var b=a.length,c=n.type(a);return"function"===c||n.isWindow(a)?!1:1===a.nodeType&&b?!0:"array"===c||0===b||"number"==typeof b&&b>0&&b-1 in a}var t=function(a){var b,c,d,e,f,g,h,i,j,k,l,m,n,o,p,q,r,s,t,u="sizzle"+1*new Date,v=a.document,w=0,x=0,y=hb(),z=hb(),A=hb(),B=function(a,b){return a===b&&(l=!0),0},C=1<<31,D={}.hasOwnProperty,E=[],F=E.pop,G=E.push,H=E.push,I=E.slice,J=function(a,b){for(var c=0,d=a.length;d>c;c++)if(a[c]===b)return c;return-1},K="checked|selected|async|autofocus|autoplay|controls|defer|disabled|hidden|ismap|loop|multiple|open|readonly|required|scoped",L="[\\x20\\t\\r\\n\\f]",M="(?:\\\\.|[\\w-]|[^\\x00-\\xa0])+",N=M.replace("w","w#"),O="\\["+L+"*("+M+")(?:"+L+"*([*^$|!~]?=)"+L+"*(?:'((?:\\\\.|[^\\\\'])*)'|\"((?:\\\\.|[^\\\\\"])*)\"|("+N+"))|)"+L+"*\\]",P=":("+M+")(?:\\((('((?:\\\\.|[^\\\\'])*)'|\"((?:\\\\.|[^\\\\\"])*)\")|((?:\\\\.|[^\\\\()[\\]]|"+O+")*)|.*)\\)|)",Q=new RegExp(L+"+","g"),R=new RegExp("^"+L+"+|((?:^|[^\\\\])(?:\\\\.)*)"+L+"+$","g"),S=new RegExp("^"+L+"*,"+L+"*"),T=new RegExp("^"+L+"*([>+~]|"+L+")"+L+"*"),U=new RegExp("="+L+"*([^\\]'\"]*?)"+L+"*\\]","g"),V=new RegExp(P),W=new RegExp("^"+N+"$"),X={ID:new RegExp("^#("+M+")"),CLASS:new RegExp("^\\.("+M+")"),TAG:new RegExp("^("+M.replace("w","w*")+")"),ATTR:new RegExp("^"+O),PSEUDO:new RegExp("^"+P),CHILD:new RegExp("^:(only|first|last|nth|nth-last)-(child|of-type)(?:\\("+L+"*(even|odd|(([+-]|)(\\d*)n|)"+L+"*(?:([+-]|)"+L+"*(\\d+)|))"+L+"*\\)|)","i"),bool:new RegExp("^(?:"+K+")$","i"),needsContext:new RegExp("^"+L+"*[>+~]|:(even|odd|eq|gt|lt|nth|first|last)(?:\\("+L+"*((?:-\\d)?\\d*)"+L+"*\\)|)(?=[^-]|$)","i")},Y=/^(?:input|select|textarea|button)$/i,Z=/^h\d$/i,$=/^[^{]+\{\s*\[native \w/,_=/^(?:#([\w-]+)|(\w+)|\.([\w-]+))$/,ab=/[+~]/,bb=/'|\\/g,cb=new RegExp("\\\\([\\da-f]{1,6}"+L+"?|("+L+")|.)","ig"),db=function(a,b,c){var d="0x"+b-65536;return d!==d||c?b:0>d?String.fromCharCode(d+65536):String.fromCharCode(d>>10|55296,1023&d|56320)},eb=function(){m()};try{H.apply(E=I.call(v.childNodes),v.childNodes),E[v.childNodes.length].nodeType}catch(fb){H={apply:E.length?function(a,b){G.apply(a,I.call(b))}:function(a,b){var c=a.length,d=0;while(a[c++]=b[d++]);a.length=c-1}}}function gb(a,b,d,e){var f,h,j,k,l,o,r,s,w,x;if((b?b.ownerDocument||b:v)!==n&&m(b),b=b||n,d=d||[],k=b.nodeType,"string"!=typeof a||!a||1!==k&&9!==k&&11!==k)return d;if(!e&&p){if(11!==k&&(f=_.exec(a)))if(j=f[1]){if(9===k){if(h=b.getElementById(j),!h||!h.parentNode)return d;if(h.id===j)return d.push(h),d}else if(b.ownerDocument&&(h=b.ownerDocument.getElementById(j))&&t(b,h)&&h.id===j)return d.push(h),d}else{if(f[2])return H.apply(d,b.getElementsByTagName(a)),d;if((j=f[3])&&c.getElementsByClassName)return H.apply(d,b.getElementsByClassName(j)),d}if(c.qsa&&(!q||!q.test(a))){if(s=r=u,w=b,x=1!==k&&a,1===k&&"object"!==b.nodeName.toLowerCase()){o=g(a),(r=b.getAttribute("id"))?s=r.replace(bb,"\\$&"):b.setAttribute("id",s),s="[id='"+s+"'] ",l=o.length;while(l--)o[l]=s+rb(o[l]);w=ab.test(a)&&pb(b.parentNode)||b,x=o.join(",")}if(x)try{return H.apply(d,w.querySelectorAll(x)),d}catch(y){}finally{r||b.removeAttribute("id")}}}return i(a.replace(R,"$1"),b,d,e)}function hb(){var a=[];function b(c,e){return a.push(c+" ")>d.cacheLength&&delete b[a.shift()],b[c+" "]=e}return b}function ib(a){return a[u]=!0,a}function jb(a){var b=n.createElement("div");try{return!!a(b)}catch(c){return!1}finally{b.parentNode&&b.parentNode.removeChild(b),b=null}}function kb(a,b){var c=a.split("|"),e=a.length;while(e--)d.attrHandle[c[e]]=b}function lb(a,b){var c=b&&a,d=c&&1===a.nodeType&&1===b.nodeType&&(~b.sourceIndex||C)-(~a.sourceIndex||C);if(d)return d;if(c)while(c=c.nextSibling)if(c===b)return-1;return a?1:-1}function mb(a){return function(b){var c=b.nodeName.toLowerCase();return"input"===c&&b.type===a}}function nb(a){return function(b){var c=b.nodeName.toLowerCase();return("input"===c||"button"===c)&&b.type===a}}function ob(a){return ib(function(b){return b=+b,ib(function(c,d){var e,f=a([],c.length,b),g=f.length;while(g--)c[e=f[g]]&&(c[e]=!(d[e]=c[e]))})})}function pb(a){return a&&"undefined"!=typeof a.getElementsByTagName&&a}c=gb.support={},f=gb.isXML=function(a){var b=a&&(a.ownerDocument||a).documentElement;return b?"HTML"!==b.nodeName:!1},m=gb.setDocument=function(a){var b,e,g=a?a.ownerDocument||a:v;return g!==n&&9===g.nodeType&&g.documentElement?(n=g,o=g.documentElement,e=g.defaultView,e&&e!==e.top&&(e.addEventListener?e.addEventListener("unload",eb,!1):e.attachEvent&&e.attachEvent("onunload",eb)),p=!f(g),c.attributes=jb(function(a){return a.className="i",!a.getAttribute("className")}),c.getElementsByTagName=jb(function(a){return a.appendChild(g.createComment("")),!a.getElementsByTagName("*").length}),c.getElementsByClassName=$.test(g.getElementsByClassName),c.getById=jb(function(a){return o.appendChild(a).id=u,!g.getElementsByName||!g.getElementsByName(u).length}),c.getById?(d.find.ID=function(a,b){if("undefined"!=typeof b.getElementById&&p){var c=b.getElementById(a);return c&&c.parentNode?[c]:[]}},d.filter.ID=function(a){var b=a.replace(cb,db);return function(a){return a.getAttribute("id")===b}}):(delete d.find.ID,d.filter.ID=function(a){var b=a.replace(cb,db);return function(a){var c="undefined"!=typeof a.getAttributeNode&&a.getAttributeNode("id");return c&&c.value===b}}),d.find.TAG=c.getElementsByTagName?function(a,b){return"undefined"!=typeof b.getElementsByTagName?b.getElementsByTagName(a):c.qsa?b.querySelectorAll(a):void 0}:function(a,b){var c,d=[],e=0,f=b.getElementsByTagName(a);if("*"===a){while(c=f[e++])1===c.nodeType&&d.push(c);return d}return f},d.find.CLASS=c.getElementsByClassName&&function(a,b){return p?b.getElementsByClassName(a):void 0},r=[],q=[],(c.qsa=$.test(g.querySelectorAll))&&(jb(function(a){o.appendChild(a).innerHTML="",a.querySelectorAll("[msallowcapture^='']").length&&q.push("[*^$]="+L+"*(?:''|\"\")"),a.querySelectorAll("[selected]").length||q.push("\\["+L+"*(?:value|"+K+")"),a.querySelectorAll("[id~="+u+"-]").length||q.push("~="),a.querySelectorAll(":checked").length||q.push(":checked"),a.querySelectorAll("a#"+u+"+*").length||q.push(".#.+[+~]")}),jb(function(a){var b=g.createElement("input");b.setAttribute("type","hidden"),a.appendChild(b).setAttribute("name","D"),a.querySelectorAll("[name=d]").length&&q.push("name"+L+"*[*^$|!~]?="),a.querySelectorAll(":enabled").length||q.push(":enabled",":disabled"),a.querySelectorAll("*,:x"),q.push(",.*:")})),(c.matchesSelector=$.test(s=o.matches||o.webkitMatchesSelector||o.mozMatchesSelector||o.oMatchesSelector||o.msMatchesSelector))&&jb(function(a){c.disconnectedMatch=s.call(a,"div"),s.call(a,"[s!='']:x"),r.push("!=",P)}),q=q.length&&new RegExp(q.join("|")),r=r.length&&new RegExp(r.join("|")),b=$.test(o.compareDocumentPosition),t=b||$.test(o.contains)?function(a,b){var c=9===a.nodeType?a.documentElement:a,d=b&&b.parentNode;return a===d||!(!d||1!==d.nodeType||!(c.contains?c.contains(d):a.compareDocumentPosition&&16&a.compareDocumentPosition(d)))}:function(a,b){if(b)while(b=b.parentNode)if(b===a)return!0;return!1},B=b?function(a,b){if(a===b)return l=!0,0;var d=!a.compareDocumentPosition-!b.compareDocumentPosition;return d?d:(d=(a.ownerDocument||a)===(b.ownerDocument||b)?a.compareDocumentPosition(b):1,1&d||!c.sortDetached&&b.compareDocumentPosition(a)===d?a===g||a.ownerDocument===v&&t(v,a)?-1:b===g||b.ownerDocument===v&&t(v,b)?1:k?J(k,a)-J(k,b):0:4&d?-1:1)}:function(a,b){if(a===b)return l=!0,0;var c,d=0,e=a.parentNode,f=b.parentNode,h=[a],i=[b];if(!e||!f)return a===g?-1:b===g?1:e?-1:f?1:k?J(k,a)-J(k,b):0;if(e===f)return lb(a,b);c=a;while(c=c.parentNode)h.unshift(c);c=b;while(c=c.parentNode)i.unshift(c);while(h[d]===i[d])d++;return d?lb(h[d],i[d]):h[d]===v?-1:i[d]===v?1:0},g):n},gb.matches=function(a,b){return gb(a,null,null,b)},gb.matchesSelector=function(a,b){if((a.ownerDocument||a)!==n&&m(a),b=b.replace(U,"='$1']"),!(!c.matchesSelector||!p||r&&r.test(b)||q&&q.test(b)))try{var d=s.call(a,b);if(d||c.disconnectedMatch||a.document&&11!==a.document.nodeType)return d}catch(e){}return gb(b,n,null,[a]).length>0},gb.contains=function(a,b){return(a.ownerDocument||a)!==n&&m(a),t(a,b)},gb.attr=function(a,b){(a.ownerDocument||a)!==n&&m(a);var e=d.attrHandle[b.toLowerCase()],f=e&&D.call(d.attrHandle,b.toLowerCase())?e(a,b,!p):void 0;return void 0!==f?f:c.attributes||!p?a.getAttribute(b):(f=a.getAttributeNode(b))&&f.specified?f.value:null},gb.error=function(a){throw new Error("Syntax error, unrecognized expression: "+a)},gb.uniqueSort=function(a){var b,d=[],e=0,f=0;if(l=!c.detectDuplicates,k=!c.sortStable&&a.slice(0),a.sort(B),l){while(b=a[f++])b===a[f]&&(e=d.push(f));while(e--)a.splice(d[e],1)}return k=null,a},e=gb.getText=function(a){var b,c="",d=0,f=a.nodeType;if(f){if(1===f||9===f||11===f){if("string"==typeof a.textContent)return a.textContent;for(a=a.firstChild;a;a=a.nextSibling)c+=e(a)}else if(3===f||4===f)return a.nodeValue}else while(b=a[d++])c+=e(b);return c},d=gb.selectors={cacheLength:50,createPseudo:ib,match:X,attrHandle:{},find:{},relative:{">":{dir:"parentNode",first:!0}," ":{dir:"parentNode"},"+":{dir:"previousSibling",first:!0},"~":{dir:"previousSibling"}},preFilter:{ATTR:function(a){return a[1]=a[1].replace(cb,db),a[3]=(a[3]||a[4]||a[5]||"").replace(cb,db),"~="===a[2]&&(a[3]=" "+a[3]+" "),a.slice(0,4)},CHILD:function(a){return a[1]=a[1].toLowerCase(),"nth"===a[1].slice(0,3)?(a[3]||gb.error(a[0]),a[4]=+(a[4]?a[5]+(a[6]||1):2*("even"===a[3]||"odd"===a[3])),a[5]=+(a[7]+a[8]||"odd"===a[3])):a[3]&&gb.error(a[0]),a},PSEUDO:function(a){var b,c=!a[6]&&a[2];return X.CHILD.test(a[0])?null:(a[3]?a[2]=a[4]||a[5]||"":c&&V.test(c)&&(b=g(c,!0))&&(b=c.indexOf(")",c.length-b)-c.length)&&(a[0]=a[0].slice(0,b),a[2]=c.slice(0,b)),a.slice(0,3))}},filter:{TAG:function(a){var b=a.replace(cb,db).toLowerCase();return"*"===a?function(){return!0}:function(a){return a.nodeName&&a.nodeName.toLowerCase()===b}},CLASS:function(a){var b=y[a+" "];return b||(b=new RegExp("(^|"+L+")"+a+"("+L+"|$)"))&&y(a,function(a){return b.test("string"==typeof a.className&&a.className||"undefined"!=typeof a.getAttribute&&a.getAttribute("class")||"")})},ATTR:function(a,b,c){return function(d){var e=gb.attr(d,a);return null==e?"!="===b:b?(e+="","="===b?e===c:"!="===b?e!==c:"^="===b?c&&0===e.indexOf(c):"*="===b?c&&e.indexOf(c)>-1:"$="===b?c&&e.slice(-c.length)===c:"~="===b?(" "+e.replace(Q," ")+" ").indexOf(c)>-1:"|="===b?e===c||e.slice(0,c.length+1)===c+"-":!1):!0}},CHILD:function(a,b,c,d,e){var f="nth"!==a.slice(0,3),g="last"!==a.slice(-4),h="of-type"===b;return 1===d&&0===e?function(a){return!!a.parentNode}:function(b,c,i){var j,k,l,m,n,o,p=f!==g?"nextSibling":"previousSibling",q=b.parentNode,r=h&&b.nodeName.toLowerCase(),s=!i&&!h;if(q){if(f){while(p){l=b;while(l=l[p])if(h?l.nodeName.toLowerCase()===r:1===l.nodeType)return!1;o=p="only"===a&&!o&&"nextSibling"}return!0}if(o=[g?q.firstChild:q.lastChild],g&&s){k=q[u]||(q[u]={}),j=k[a]||[],n=j[0]===w&&j[1],m=j[0]===w&&j[2],l=n&&q.childNodes[n];while(l=++n&&l&&l[p]||(m=n=0)||o.pop())if(1===l.nodeType&&++m&&l===b){k[a]=[w,n,m];break}}else if(s&&(j=(b[u]||(b[u]={}))[a])&&j[0]===w)m=j[1];else while(l=++n&&l&&l[p]||(m=n=0)||o.pop())if((h?l.nodeName.toLowerCase()===r:1===l.nodeType)&&++m&&(s&&((l[u]||(l[u]={}))[a]=[w,m]),l===b))break;return m-=e,m===d||m%d===0&&m/d>=0}}},PSEUDO:function(a,b){var c,e=d.pseudos[a]||d.setFilters[a.toLowerCase()]||gb.error("unsupported pseudo: "+a);return e[u]?e(b):e.length>1?(c=[a,a,"",b],d.setFilters.hasOwnProperty(a.toLowerCase())?ib(function(a,c){var d,f=e(a,b),g=f.length;while(g--)d=J(a,f[g]),a[d]=!(c[d]=f[g])}):function(a){return e(a,0,c)}):e}},pseudos:{not:ib(function(a){var b=[],c=[],d=h(a.replace(R,"$1"));return d[u]?ib(function(a,b,c,e){var f,g=d(a,null,e,[]),h=a.length;while(h--)(f=g[h])&&(a[h]=!(b[h]=f))}):function(a,e,f){return b[0]=a,d(b,null,f,c),b[0]=null,!c.pop()}}),has:ib(function(a){return function(b){return gb(a,b).length>0}}),contains:ib(function(a){return a=a.replace(cb,db),function(b){return(b.textContent||b.innerText||e(b)).indexOf(a)>-1}}),lang:ib(function(a){return W.test(a||"")||gb.error("unsupported lang: "+a),a=a.replace(cb,db).toLowerCase(),function(b){var c;do if(c=p?b.lang:b.getAttribute("xml:lang")||b.getAttribute("lang"))return c=c.toLowerCase(),c===a||0===c.indexOf(a+"-");while((b=b.parentNode)&&1===b.nodeType);return!1}}),target:function(b){var c=a.location&&a.location.hash;return c&&c.slice(1)===b.id},root:function(a){return a===o},focus:function(a){return a===n.activeElement&&(!n.hasFocus||n.hasFocus())&&!!(a.type||a.href||~a.tabIndex)},enabled:function(a){return a.disabled===!1},disabled:function(a){return a.disabled===!0},checked:function(a){var b=a.nodeName.toLowerCase();return"input"===b&&!!a.checked||"option"===b&&!!a.selected},selected:function(a){return a.parentNode&&a.parentNode.selectedIndex,a.selected===!0},empty:function(a){for(a=a.firstChild;a;a=a.nextSibling)if(a.nodeType<6)return!1;return!0},parent:function(a){return!d.pseudos.empty(a)},header:function(a){return Z.test(a.nodeName)},input:function(a){return Y.test(a.nodeName)},button:function(a){var b=a.nodeName.toLowerCase();return"input"===b&&"button"===a.type||"button"===b},text:function(a){var b;return"input"===a.nodeName.toLowerCase()&&"text"===a.type&&(null==(b=a.getAttribute("type"))||"text"===b.toLowerCase())},first:ob(function(){return[0]}),last:ob(function(a,b){return[b-1]}),eq:ob(function(a,b,c){return[0>c?c+b:c]}),even:ob(function(a,b){for(var c=0;b>c;c+=2)a.push(c);return a}),odd:ob(function(a,b){for(var c=1;b>c;c+=2)a.push(c);return a}),lt:ob(function(a,b,c){for(var d=0>c?c+b:c;--d>=0;)a.push(d);return a}),gt:ob(function(a,b,c){for(var d=0>c?c+b:c;++db;b++)d+=a[b].value;return d}function sb(a,b,c){var d=b.dir,e=c&&"parentNode"===d,f=x++;return b.first?function(b,c,f){while(b=b[d])if(1===b.nodeType||e)return a(b,c,f)}:function(b,c,g){var h,i,j=[w,f];if(g){while(b=b[d])if((1===b.nodeType||e)&&a(b,c,g))return!0}else while(b=b[d])if(1===b.nodeType||e){if(i=b[u]||(b[u]={}),(h=i[d])&&h[0]===w&&h[1]===f)return j[2]=h[2];if(i[d]=j,j[2]=a(b,c,g))return!0}}}function tb(a){return a.length>1?function(b,c,d){var e=a.length;while(e--)if(!a[e](b,c,d))return!1;return!0}:a[0]}function ub(a,b,c){for(var d=0,e=b.length;e>d;d++)gb(a,b[d],c);return c}function vb(a,b,c,d,e){for(var f,g=[],h=0,i=a.length,j=null!=b;i>h;h++)(f=a[h])&&(!c||c(f,d,e))&&(g.push(f),j&&b.push(h));return g}function wb(a,b,c,d,e,f){return d&&!d[u]&&(d=wb(d)),e&&!e[u]&&(e=wb(e,f)),ib(function(f,g,h,i){var j,k,l,m=[],n=[],o=g.length,p=f||ub(b||"*",h.nodeType?[h]:h,[]),q=!a||!f&&b?p:vb(p,m,a,h,i),r=c?e||(f?a:o||d)?[]:g:q;if(c&&c(q,r,h,i),d){j=vb(r,n),d(j,[],h,i),k=j.length;while(k--)(l=j[k])&&(r[n[k]]=!(q[n[k]]=l))}if(f){if(e||a){if(e){j=[],k=r.length;while(k--)(l=r[k])&&j.push(q[k]=l);e(null,r=[],j,i)}k=r.length;while(k--)(l=r[k])&&(j=e?J(f,l):m[k])>-1&&(f[j]=!(g[j]=l))}}else r=vb(r===g?r.splice(o,r.length):r),e?e(null,g,r,i):H.apply(g,r)})}function xb(a){for(var b,c,e,f=a.length,g=d.relative[a[0].type],h=g||d.relative[" "],i=g?1:0,k=sb(function(a){return a===b},h,!0),l=sb(function(a){return J(b,a)>-1},h,!0),m=[function(a,c,d){var e=!g&&(d||c!==j)||((b=c).nodeType?k(a,c,d):l(a,c,d));return b=null,e}];f>i;i++)if(c=d.relative[a[i].type])m=[sb(tb(m),c)];else{if(c=d.filter[a[i].type].apply(null,a[i].matches),c[u]){for(e=++i;f>e;e++)if(d.relative[a[e].type])break;return wb(i>1&&tb(m),i>1&&rb(a.slice(0,i-1).concat({value:" "===a[i-2].type?"*":""})).replace(R,"$1"),c,e>i&&xb(a.slice(i,e)),f>e&&xb(a=a.slice(e)),f>e&&rb(a))}m.push(c)}return tb(m)}function yb(a,b){var c=b.length>0,e=a.length>0,f=function(f,g,h,i,k){var l,m,o,p=0,q="0",r=f&&[],s=[],t=j,u=f||e&&d.find.TAG("*",k),v=w+=null==t?1:Math.random()||.1,x=u.length;for(k&&(j=g!==n&&g);q!==x&&null!=(l=u[q]);q++){if(e&&l){m=0;while(o=a[m++])if(o(l,g,h)){i.push(l);break}k&&(w=v)}c&&((l=!o&&l)&&p--,f&&r.push(l))}if(p+=q,c&&q!==p){m=0;while(o=b[m++])o(r,s,g,h);if(f){if(p>0)while(q--)r[q]||s[q]||(s[q]=F.call(i));s=vb(s)}H.apply(i,s),k&&!f&&s.length>0&&p+b.length>1&&gb.uniqueSort(i)}return k&&(w=v,j=t),r};return c?ib(f):f}return h=gb.compile=function(a,b){var c,d=[],e=[],f=A[a+" "];if(!f){b||(b=g(a)),c=b.length;while(c--)f=xb(b[c]),f[u]?d.push(f):e.push(f);f=A(a,yb(e,d)),f.selector=a}return f},i=gb.select=function(a,b,e,f){var i,j,k,l,m,n="function"==typeof a&&a,o=!f&&g(a=n.selector||a);if(e=e||[],1===o.length){if(j=o[0]=o[0].slice(0),j.length>2&&"ID"===(k=j[0]).type&&c.getById&&9===b.nodeType&&p&&d.relative[j[1].type]){if(b=(d.find.ID(k.matches[0].replace(cb,db),b)||[])[0],!b)return e;n&&(b=b.parentNode),a=a.slice(j.shift().value.length)}i=X.needsContext.test(a)?0:j.length;while(i--){if(k=j[i],d.relative[l=k.type])break;if((m=d.find[l])&&(f=m(k.matches[0].replace(cb,db),ab.test(j[0].type)&&pb(b.parentNode)||b))){if(j.splice(i,1),a=f.length&&rb(j),!a)return H.apply(e,f),e;break}}}return(n||h(a,o))(f,b,!p,e,ab.test(a)&&pb(b.parentNode)||b),e},c.sortStable=u.split("").sort(B).join("")===u,c.detectDuplicates=!!l,m(),c.sortDetached=jb(function(a){return 1&a.compareDocumentPosition(n.createElement("div"))}),jb(function(a){return a.innerHTML="","#"===a.firstChild.getAttribute("href")})||kb("type|href|height|width",function(a,b,c){return c?void 0:a.getAttribute(b,"type"===b.toLowerCase()?1:2)}),c.attributes&&jb(function(a){return a.innerHTML="",a.firstChild.setAttribute("value",""),""===a.firstChild.getAttribute("value")})||kb("value",function(a,b,c){return c||"input"!==a.nodeName.toLowerCase()?void 0:a.defaultValue}),jb(function(a){return null==a.getAttribute("disabled")})||kb(K,function(a,b,c){var d;return c?void 0:a[b]===!0?b.toLowerCase():(d=a.getAttributeNode(b))&&d.specified?d.value:null}),gb}(a);n.find=t,n.expr=t.selectors,n.expr[":"]=n.expr.pseudos,n.unique=t.uniqueSort,n.text=t.getText,n.isXMLDoc=t.isXML,n.contains=t.contains;var u=n.expr.match.needsContext,v=/^<(\w+)\s*\/?>(?:<\/\1>|)$/,w=/^.[^:#\[\.,]*$/;function x(a,b,c){if(n.isFunction(b))return n.grep(a,function(a,d){return!!b.call(a,d,a)!==c});if(b.nodeType)return n.grep(a,function(a){return a===b!==c});if("string"==typeof b){if(w.test(b))return n.filter(b,a,c);b=n.filter(b,a)}return n.grep(a,function(a){return g.call(b,a)>=0!==c})}n.filter=function(a,b,c){var d=b[0];return c&&(a=":not("+a+")"),1===b.length&&1===d.nodeType?n.find.matchesSelector(d,a)?[d]:[]:n.find.matches(a,n.grep(b,function(a){return 1===a.nodeType}))},n.fn.extend({find:function(a){var b,c=this.length,d=[],e=this;if("string"!=typeof a)return this.pushStack(n(a).filter(function(){for(b=0;c>b;b++)if(n.contains(e[b],this))return!0}));for(b=0;c>b;b++)n.find(a,e[b],d);return d=this.pushStack(c>1?n.unique(d):d),d.selector=this.selector?this.selector+" "+a:a,d},filter:function(a){return this.pushStack(x(this,a||[],!1))},not:function(a){return this.pushStack(x(this,a||[],!0))},is:function(a){return!!x(this,"string"==typeof a&&u.test(a)?n(a):a||[],!1).length}});var y,z=/^(?:\s*(<[\w\W]+>)[^>]*|#([\w-]*))$/,A=n.fn.init=function(a,b){var c,d;if(!a)return this;if("string"==typeof a){if(c="<"===a[0]&&">"===a[a.length-1]&&a.length>=3?[null,a,null]:z.exec(a),!c||!c[1]&&b)return!b||b.jquery?(b||y).find(a):this.constructor(b).find(a);if(c[1]){if(b=b instanceof n?b[0]:b,n.merge(this,n.parseHTML(c[1],b&&b.nodeType?b.ownerDocument||b:l,!0)),v.test(c[1])&&n.isPlainObject(b))for(c in b)n.isFunction(this[c])?this[c](b[c]):this.attr(c,b[c]);return this}return d=l.getElementById(c[2]),d&&d.parentNode&&(this.length=1,this[0]=d),this.context=l,this.selector=a,this}return a.nodeType?(this.context=this[0]=a,this.length=1,this):n.isFunction(a)?"undefined"!=typeof y.ready?y.ready(a):a(n):(void 0!==a.selector&&(this.selector=a.selector,this.context=a.context),n.makeArray(a,this))};A.prototype=n.fn,y=n(l);var B=/^(?:parents|prev(?:Until|All))/,C={children:!0,contents:!0,next:!0,prev:!0};n.extend({dir:function(a,b,c){var d=[],e=void 0!==c;while((a=a[b])&&9!==a.nodeType)if(1===a.nodeType){if(e&&n(a).is(c))break;d.push(a)}return d},sibling:function(a,b){for(var c=[];a;a=a.nextSibling)1===a.nodeType&&a!==b&&c.push(a);return c}}),n.fn.extend({has:function(a){var b=n(a,this),c=b.length;return this.filter(function(){for(var a=0;c>a;a++)if(n.contains(this,b[a]))return!0})},closest:function(a,b){for(var c,d=0,e=this.length,f=[],g=u.test(a)||"string"!=typeof a?n(a,b||this.context):0;e>d;d++)for(c=this[d];c&&c!==b;c=c.parentNode)if(c.nodeType<11&&(g?g.index(c)>-1:1===c.nodeType&&n.find.matchesSelector(c,a))){f.push(c);break}return this.pushStack(f.length>1?n.unique(f):f)},index:function(a){return a?"string"==typeof a?g.call(n(a),this[0]):g.call(this,a.jquery?a[0]:a):this[0]&&this[0].parentNode?this.first().prevAll().length:-1},add:function(a,b){return this.pushStack(n.unique(n.merge(this.get(),n(a,b))))},addBack:function(a){return this.add(null==a?this.prevObject:this.prevObject.filter(a))}});function D(a,b){while((a=a[b])&&1!==a.nodeType);return a}n.each({parent:function(a){var b=a.parentNode;return b&&11!==b.nodeType?b:null},parents:function(a){return n.dir(a,"parentNode")},parentsUntil:function(a,b,c){return n.dir(a,"parentNode",c)},next:function(a){return D(a,"nextSibling")},prev:function(a){return D(a,"previousSibling")},nextAll:function(a){return n.dir(a,"nextSibling")},prevAll:function(a){return n.dir(a,"previousSibling")},nextUntil:function(a,b,c){return n.dir(a,"nextSibling",c)},prevUntil:function(a,b,c){return n.dir(a,"previousSibling",c)},siblings:function(a){return n.sibling((a.parentNode||{}).firstChild,a)},children:function(a){return n.sibling(a.firstChild)},contents:function(a){return a.contentDocument||n.merge([],a.childNodes)}},function(a,b){n.fn[a]=function(c,d){var e=n.map(this,b,c);return"Until"!==a.slice(-5)&&(d=c),d&&"string"==typeof d&&(e=n.filter(d,e)),this.length>1&&(C[a]||n.unique(e),B.test(a)&&e.reverse()),this.pushStack(e)}});var E=/\S+/g,F={};function G(a){var b=F[a]={};return n.each(a.match(E)||[],function(a,c){b[c]=!0}),b}n.Callbacks=function(a){a="string"==typeof a?F[a]||G(a):n.extend({},a);var b,c,d,e,f,g,h=[],i=!a.once&&[],j=function(l){for(b=a.memory&&l,c=!0,g=e||0,e=0,f=h.length,d=!0;h&&f>g;g++)if(h[g].apply(l[0],l[1])===!1&&a.stopOnFalse){b=!1;break}d=!1,h&&(i?i.length&&j(i.shift()):b?h=[]:k.disable())},k={add:function(){if(h){var c=h.length;!function g(b){n.each(b,function(b,c){var d=n.type(c);"function"===d?a.unique&&k.has(c)||h.push(c):c&&c.length&&"string"!==d&&g(c)})}(arguments),d?f=h.length:b&&(e=c,j(b))}return this},remove:function(){return h&&n.each(arguments,function(a,b){var c;while((c=n.inArray(b,h,c))>-1)h.splice(c,1),d&&(f>=c&&f--,g>=c&&g--)}),this},has:function(a){return a?n.inArray(a,h)>-1:!(!h||!h.length)},empty:function(){return h=[],f=0,this},disable:function(){return h=i=b=void 0,this},disabled:function(){return!h},lock:function(){return i=void 0,b||k.disable(),this},locked:function(){return!i},fireWith:function(a,b){return!h||c&&!i||(b=b||[],b=[a,b.slice?b.slice():b],d?i.push(b):j(b)),this},fire:function(){return k.fireWith(this,arguments),this},fired:function(){return!!c}};return k},n.extend({Deferred:function(a){var b=[["resolve","done",n.Callbacks("once memory"),"resolved"],["reject","fail",n.Callbacks("once memory"),"rejected"],["notify","progress",n.Callbacks("memory")]],c="pending",d={state:function(){return c},always:function(){return e.done(arguments).fail(arguments),this},then:function(){var a=arguments;return n.Deferred(function(c){n.each(b,function(b,f){var g=n.isFunction(a[b])&&a[b];e[f[1]](function(){var a=g&&g.apply(this,arguments);a&&n.isFunction(a.promise)?a.promise().done(c.resolve).fail(c.reject).progress(c.notify):c[f[0]+"With"](this===d?c.promise():this,g?[a]:arguments)})}),a=null}).promise()},promise:function(a){return null!=a?n.extend(a,d):d}},e={};return d.pipe=d.then,n.each(b,function(a,f){var g=f[2],h=f[3];d[f[1]]=g.add,h&&g.add(function(){c=h},b[1^a][2].disable,b[2][2].lock),e[f[0]]=function(){return e[f[0]+"With"](this===e?d:this,arguments),this},e[f[0]+"With"]=g.fireWith}),d.promise(e),a&&a.call(e,e),e},when:function(a){var b=0,c=d.call(arguments),e=c.length,f=1!==e||a&&n.isFunction(a.promise)?e:0,g=1===f?a:n.Deferred(),h=function(a,b,c){return function(e){b[a]=this,c[a]=arguments.length>1?d.call(arguments):e,c===i?g.notifyWith(b,c):--f||g.resolveWith(b,c)}},i,j,k;if(e>1)for(i=new Array(e),j=new Array(e),k=new Array(e);e>b;b++)c[b]&&n.isFunction(c[b].promise)?c[b].promise().done(h(b,k,c)).fail(g.reject).progress(h(b,j,i)):--f;return f||g.resolveWith(k,c),g.promise()}});var H;n.fn.ready=function(a){return n.ready.promise().done(a),this},n.extend({isReady:!1,readyWait:1,holdReady:function(a){a?n.readyWait++:n.ready(!0)},ready:function(a){(a===!0?--n.readyWait:n.isReady)||(n.isReady=!0,a!==!0&&--n.readyWait>0||(H.resolveWith(l,[n]),n.fn.triggerHandler&&(n(l).triggerHandler("ready"),n(l).off("ready"))))}});function I(){l.removeEventListener("DOMContentLoaded",I,!1),a.removeEventListener("load",I,!1),n.ready()}n.ready.promise=function(b){return H||(H=n.Deferred(),"complete"===l.readyState?setTimeout(n.ready):(l.addEventListener("DOMContentLoaded",I,!1),a.addEventListener("load",I,!1))),H.promise(b)},n.ready.promise();var J=n.access=function(a,b,c,d,e,f,g){var h=0,i=a.length,j=null==c;if("object"===n.type(c)){e=!0;for(h in c)n.access(a,b,h,c[h],!0,f,g)}else if(void 0!==d&&(e=!0,n.isFunction(d)||(g=!0),j&&(g?(b.call(a,d),b=null):(j=b,b=function(a,b,c){return j.call(n(a),c)})),b))for(;i>h;h++)b(a[h],c,g?d:d.call(a[h],h,b(a[h],c)));return e?a:j?b.call(a):i?b(a[0],c):f};n.acceptData=function(a){return 1===a.nodeType||9===a.nodeType||!+a.nodeType};function K(){Object.defineProperty(this.cache={},0,{get:function(){return{}}}),this.expando=n.expando+K.uid++}K.uid=1,K.accepts=n.acceptData,K.prototype={key:function(a){if(!K.accepts(a))return 0;var b={},c=a[this.expando];if(!c){c=K.uid++;try{b[this.expando]={value:c},Object.defineProperties(a,b)}catch(d){b[this.expando]=c,n.extend(a,b)}}return this.cache[c]||(this.cache[c]={}),c},set:function(a,b,c){var d,e=this.key(a),f=this.cache[e];if("string"==typeof b)f[b]=c;else if(n.isEmptyObject(f))n.extend(this.cache[e],b);else for(d in b)f[d]=b[d];return f},get:function(a,b){var c=this.cache[this.key(a)];return void 0===b?c:c[b]},access:function(a,b,c){var d;return void 0===b||b&&"string"==typeof b&&void 0===c?(d=this.get(a,b),void 0!==d?d:this.get(a,n.camelCase(b))):(this.set(a,b,c),void 0!==c?c:b)},remove:function(a,b){var c,d,e,f=this.key(a),g=this.cache[f];if(void 0===b)this.cache[f]={};else{n.isArray(b)?d=b.concat(b.map(n.camelCase)):(e=n.camelCase(b),b in g?d=[b,e]:(d=e,d=d in g?[d]:d.match(E)||[])),c=d.length;while(c--)delete g[d[c]]}},hasData:function(a){return!n.isEmptyObject(this.cache[a[this.expando]]||{})},discard:function(a){a[this.expando]&&delete this.cache[a[this.expando]]}};var L=new K,M=new K,N=/^(?:\{[\w\W]*\}|\[[\w\W]*\])$/,O=/([A-Z])/g;function P(a,b,c){var d;if(void 0===c&&1===a.nodeType)if(d="data-"+b.replace(O,"-$1").toLowerCase(),c=a.getAttribute(d),"string"==typeof c){try{c="true"===c?!0:"false"===c?!1:"null"===c?null:+c+""===c?+c:N.test(c)?n.parseJSON(c):c}catch(e){}M.set(a,b,c)}else c=void 0;return c}n.extend({hasData:function(a){return M.hasData(a)||L.hasData(a)},data:function(a,b,c){return M.access(a,b,c) +},removeData:function(a,b){M.remove(a,b)},_data:function(a,b,c){return L.access(a,b,c)},_removeData:function(a,b){L.remove(a,b)}}),n.fn.extend({data:function(a,b){var c,d,e,f=this[0],g=f&&f.attributes;if(void 0===a){if(this.length&&(e=M.get(f),1===f.nodeType&&!L.get(f,"hasDataAttrs"))){c=g.length;while(c--)g[c]&&(d=g[c].name,0===d.indexOf("data-")&&(d=n.camelCase(d.slice(5)),P(f,d,e[d])));L.set(f,"hasDataAttrs",!0)}return e}return"object"==typeof a?this.each(function(){M.set(this,a)}):J(this,function(b){var c,d=n.camelCase(a);if(f&&void 0===b){if(c=M.get(f,a),void 0!==c)return c;if(c=M.get(f,d),void 0!==c)return c;if(c=P(f,d,void 0),void 0!==c)return c}else this.each(function(){var c=M.get(this,d);M.set(this,d,b),-1!==a.indexOf("-")&&void 0!==c&&M.set(this,a,b)})},null,b,arguments.length>1,null,!0)},removeData:function(a){return this.each(function(){M.remove(this,a)})}}),n.extend({queue:function(a,b,c){var d;return a?(b=(b||"fx")+"queue",d=L.get(a,b),c&&(!d||n.isArray(c)?d=L.access(a,b,n.makeArray(c)):d.push(c)),d||[]):void 0},dequeue:function(a,b){b=b||"fx";var c=n.queue(a,b),d=c.length,e=c.shift(),f=n._queueHooks(a,b),g=function(){n.dequeue(a,b)};"inprogress"===e&&(e=c.shift(),d--),e&&("fx"===b&&c.unshift("inprogress"),delete f.stop,e.call(a,g,f)),!d&&f&&f.empty.fire()},_queueHooks:function(a,b){var c=b+"queueHooks";return L.get(a,c)||L.access(a,c,{empty:n.Callbacks("once memory").add(function(){L.remove(a,[b+"queue",c])})})}}),n.fn.extend({queue:function(a,b){var c=2;return"string"!=typeof a&&(b=a,a="fx",c--),arguments.lengthx",k.noCloneChecked=!!b.cloneNode(!0).lastChild.defaultValue}();var U="undefined";k.focusinBubbles="onfocusin"in a;var V=/^key/,W=/^(?:mouse|pointer|contextmenu)|click/,X=/^(?:focusinfocus|focusoutblur)$/,Y=/^([^.]*)(?:\.(.+)|)$/;function Z(){return!0}function $(){return!1}function _(){try{return l.activeElement}catch(a){}}n.event={global:{},add:function(a,b,c,d,e){var f,g,h,i,j,k,l,m,o,p,q,r=L.get(a);if(r){c.handler&&(f=c,c=f.handler,e=f.selector),c.guid||(c.guid=n.guid++),(i=r.events)||(i=r.events={}),(g=r.handle)||(g=r.handle=function(b){return typeof n!==U&&n.event.triggered!==b.type?n.event.dispatch.apply(a,arguments):void 0}),b=(b||"").match(E)||[""],j=b.length;while(j--)h=Y.exec(b[j])||[],o=q=h[1],p=(h[2]||"").split(".").sort(),o&&(l=n.event.special[o]||{},o=(e?l.delegateType:l.bindType)||o,l=n.event.special[o]||{},k=n.extend({type:o,origType:q,data:d,handler:c,guid:c.guid,selector:e,needsContext:e&&n.expr.match.needsContext.test(e),namespace:p.join(".")},f),(m=i[o])||(m=i[o]=[],m.delegateCount=0,l.setup&&l.setup.call(a,d,p,g)!==!1||a.addEventListener&&a.addEventListener(o,g,!1)),l.add&&(l.add.call(a,k),k.handler.guid||(k.handler.guid=c.guid)),e?m.splice(m.delegateCount++,0,k):m.push(k),n.event.global[o]=!0)}},remove:function(a,b,c,d,e){var f,g,h,i,j,k,l,m,o,p,q,r=L.hasData(a)&&L.get(a);if(r&&(i=r.events)){b=(b||"").match(E)||[""],j=b.length;while(j--)if(h=Y.exec(b[j])||[],o=q=h[1],p=(h[2]||"").split(".").sort(),o){l=n.event.special[o]||{},o=(d?l.delegateType:l.bindType)||o,m=i[o]||[],h=h[2]&&new RegExp("(^|\\.)"+p.join("\\.(?:.*\\.|)")+"(\\.|$)"),g=f=m.length;while(f--)k=m[f],!e&&q!==k.origType||c&&c.guid!==k.guid||h&&!h.test(k.namespace)||d&&d!==k.selector&&("**"!==d||!k.selector)||(m.splice(f,1),k.selector&&m.delegateCount--,l.remove&&l.remove.call(a,k));g&&!m.length&&(l.teardown&&l.teardown.call(a,p,r.handle)!==!1||n.removeEvent(a,o,r.handle),delete i[o])}else for(o in i)n.event.remove(a,o+b[j],c,d,!0);n.isEmptyObject(i)&&(delete r.handle,L.remove(a,"events"))}},trigger:function(b,c,d,e){var f,g,h,i,k,m,o,p=[d||l],q=j.call(b,"type")?b.type:b,r=j.call(b,"namespace")?b.namespace.split("."):[];if(g=h=d=d||l,3!==d.nodeType&&8!==d.nodeType&&!X.test(q+n.event.triggered)&&(q.indexOf(".")>=0&&(r=q.split("."),q=r.shift(),r.sort()),k=q.indexOf(":")<0&&"on"+q,b=b[n.expando]?b:new n.Event(q,"object"==typeof b&&b),b.isTrigger=e?2:3,b.namespace=r.join("."),b.namespace_re=b.namespace?new RegExp("(^|\\.)"+r.join("\\.(?:.*\\.|)")+"(\\.|$)"):null,b.result=void 0,b.target||(b.target=d),c=null==c?[b]:n.makeArray(c,[b]),o=n.event.special[q]||{},e||!o.trigger||o.trigger.apply(d,c)!==!1)){if(!e&&!o.noBubble&&!n.isWindow(d)){for(i=o.delegateType||q,X.test(i+q)||(g=g.parentNode);g;g=g.parentNode)p.push(g),h=g;h===(d.ownerDocument||l)&&p.push(h.defaultView||h.parentWindow||a)}f=0;while((g=p[f++])&&!b.isPropagationStopped())b.type=f>1?i:o.bindType||q,m=(L.get(g,"events")||{})[b.type]&&L.get(g,"handle"),m&&m.apply(g,c),m=k&&g[k],m&&m.apply&&n.acceptData(g)&&(b.result=m.apply(g,c),b.result===!1&&b.preventDefault());return b.type=q,e||b.isDefaultPrevented()||o._default&&o._default.apply(p.pop(),c)!==!1||!n.acceptData(d)||k&&n.isFunction(d[q])&&!n.isWindow(d)&&(h=d[k],h&&(d[k]=null),n.event.triggered=q,d[q](),n.event.triggered=void 0,h&&(d[k]=h)),b.result}},dispatch:function(a){a=n.event.fix(a);var b,c,e,f,g,h=[],i=d.call(arguments),j=(L.get(this,"events")||{})[a.type]||[],k=n.event.special[a.type]||{};if(i[0]=a,a.delegateTarget=this,!k.preDispatch||k.preDispatch.call(this,a)!==!1){h=n.event.handlers.call(this,a,j),b=0;while((f=h[b++])&&!a.isPropagationStopped()){a.currentTarget=f.elem,c=0;while((g=f.handlers[c++])&&!a.isImmediatePropagationStopped())(!a.namespace_re||a.namespace_re.test(g.namespace))&&(a.handleObj=g,a.data=g.data,e=((n.event.special[g.origType]||{}).handle||g.handler).apply(f.elem,i),void 0!==e&&(a.result=e)===!1&&(a.preventDefault(),a.stopPropagation()))}return k.postDispatch&&k.postDispatch.call(this,a),a.result}},handlers:function(a,b){var c,d,e,f,g=[],h=b.delegateCount,i=a.target;if(h&&i.nodeType&&(!a.button||"click"!==a.type))for(;i!==this;i=i.parentNode||this)if(i.disabled!==!0||"click"!==a.type){for(d=[],c=0;h>c;c++)f=b[c],e=f.selector+" ",void 0===d[e]&&(d[e]=f.needsContext?n(e,this).index(i)>=0:n.find(e,this,null,[i]).length),d[e]&&d.push(f);d.length&&g.push({elem:i,handlers:d})}return h]*)\/>/gi,bb=/<([\w:]+)/,cb=/<|&#?\w+;/,db=/<(?:script|style|link)/i,eb=/checked\s*(?:[^=]|=\s*.checked.)/i,fb=/^$|\/(?:java|ecma)script/i,gb=/^true\/(.*)/,hb=/^\s*\s*$/g,ib={option:[1,""],thead:[1,"","
        "],col:[2,"","
        "],tr:[2,"","
        "],td:[3,"","
        "],_default:[0,"",""]};ib.optgroup=ib.option,ib.tbody=ib.tfoot=ib.colgroup=ib.caption=ib.thead,ib.th=ib.td;function jb(a,b){return n.nodeName(a,"table")&&n.nodeName(11!==b.nodeType?b:b.firstChild,"tr")?a.getElementsByTagName("tbody")[0]||a.appendChild(a.ownerDocument.createElement("tbody")):a}function kb(a){return a.type=(null!==a.getAttribute("type"))+"/"+a.type,a}function lb(a){var b=gb.exec(a.type);return b?a.type=b[1]:a.removeAttribute("type"),a}function mb(a,b){for(var c=0,d=a.length;d>c;c++)L.set(a[c],"globalEval",!b||L.get(b[c],"globalEval"))}function nb(a,b){var c,d,e,f,g,h,i,j;if(1===b.nodeType){if(L.hasData(a)&&(f=L.access(a),g=L.set(b,f),j=f.events)){delete g.handle,g.events={};for(e in j)for(c=0,d=j[e].length;d>c;c++)n.event.add(b,e,j[e][c])}M.hasData(a)&&(h=M.access(a),i=n.extend({},h),M.set(b,i))}}function ob(a,b){var c=a.getElementsByTagName?a.getElementsByTagName(b||"*"):a.querySelectorAll?a.querySelectorAll(b||"*"):[];return void 0===b||b&&n.nodeName(a,b)?n.merge([a],c):c}function pb(a,b){var c=b.nodeName.toLowerCase();"input"===c&&T.test(a.type)?b.checked=a.checked:("input"===c||"textarea"===c)&&(b.defaultValue=a.defaultValue)}n.extend({clone:function(a,b,c){var d,e,f,g,h=a.cloneNode(!0),i=n.contains(a.ownerDocument,a);if(!(k.noCloneChecked||1!==a.nodeType&&11!==a.nodeType||n.isXMLDoc(a)))for(g=ob(h),f=ob(a),d=0,e=f.length;e>d;d++)pb(f[d],g[d]);if(b)if(c)for(f=f||ob(a),g=g||ob(h),d=0,e=f.length;e>d;d++)nb(f[d],g[d]);else nb(a,h);return g=ob(h,"script"),g.length>0&&mb(g,!i&&ob(a,"script")),h},buildFragment:function(a,b,c,d){for(var e,f,g,h,i,j,k=b.createDocumentFragment(),l=[],m=0,o=a.length;o>m;m++)if(e=a[m],e||0===e)if("object"===n.type(e))n.merge(l,e.nodeType?[e]:e);else if(cb.test(e)){f=f||k.appendChild(b.createElement("div")),g=(bb.exec(e)||["",""])[1].toLowerCase(),h=ib[g]||ib._default,f.innerHTML=h[1]+e.replace(ab,"<$1>")+h[2],j=h[0];while(j--)f=f.lastChild;n.merge(l,f.childNodes),f=k.firstChild,f.textContent=""}else l.push(b.createTextNode(e));k.textContent="",m=0;while(e=l[m++])if((!d||-1===n.inArray(e,d))&&(i=n.contains(e.ownerDocument,e),f=ob(k.appendChild(e),"script"),i&&mb(f),c)){j=0;while(e=f[j++])fb.test(e.type||"")&&c.push(e)}return k},cleanData:function(a){for(var b,c,d,e,f=n.event.special,g=0;void 0!==(c=a[g]);g++){if(n.acceptData(c)&&(e=c[L.expando],e&&(b=L.cache[e]))){if(b.events)for(d in b.events)f[d]?n.event.remove(c,d):n.removeEvent(c,d,b.handle);L.cache[e]&&delete L.cache[e]}delete M.cache[c[M.expando]]}}}),n.fn.extend({text:function(a){return J(this,function(a){return void 0===a?n.text(this):this.empty().each(function(){(1===this.nodeType||11===this.nodeType||9===this.nodeType)&&(this.textContent=a)})},null,a,arguments.length)},append:function(){return this.domManip(arguments,function(a){if(1===this.nodeType||11===this.nodeType||9===this.nodeType){var b=jb(this,a);b.appendChild(a)}})},prepend:function(){return this.domManip(arguments,function(a){if(1===this.nodeType||11===this.nodeType||9===this.nodeType){var b=jb(this,a);b.insertBefore(a,b.firstChild)}})},before:function(){return this.domManip(arguments,function(a){this.parentNode&&this.parentNode.insertBefore(a,this)})},after:function(){return this.domManip(arguments,function(a){this.parentNode&&this.parentNode.insertBefore(a,this.nextSibling)})},remove:function(a,b){for(var c,d=a?n.filter(a,this):this,e=0;null!=(c=d[e]);e++)b||1!==c.nodeType||n.cleanData(ob(c)),c.parentNode&&(b&&n.contains(c.ownerDocument,c)&&mb(ob(c,"script")),c.parentNode.removeChild(c));return this},empty:function(){for(var a,b=0;null!=(a=this[b]);b++)1===a.nodeType&&(n.cleanData(ob(a,!1)),a.textContent="");return this},clone:function(a,b){return a=null==a?!1:a,b=null==b?a:b,this.map(function(){return n.clone(this,a,b)})},html:function(a){return J(this,function(a){var b=this[0]||{},c=0,d=this.length;if(void 0===a&&1===b.nodeType)return b.innerHTML;if("string"==typeof a&&!db.test(a)&&!ib[(bb.exec(a)||["",""])[1].toLowerCase()]){a=a.replace(ab,"<$1>");try{for(;d>c;c++)b=this[c]||{},1===b.nodeType&&(n.cleanData(ob(b,!1)),b.innerHTML=a);b=0}catch(e){}}b&&this.empty().append(a)},null,a,arguments.length)},replaceWith:function(){var a=arguments[0];return this.domManip(arguments,function(b){a=this.parentNode,n.cleanData(ob(this)),a&&a.replaceChild(b,this)}),a&&(a.length||a.nodeType)?this:this.remove()},detach:function(a){return this.remove(a,!0)},domManip:function(a,b){a=e.apply([],a);var c,d,f,g,h,i,j=0,l=this.length,m=this,o=l-1,p=a[0],q=n.isFunction(p);if(q||l>1&&"string"==typeof p&&!k.checkClone&&eb.test(p))return this.each(function(c){var d=m.eq(c);q&&(a[0]=p.call(this,c,d.html())),d.domManip(a,b)});if(l&&(c=n.buildFragment(a,this[0].ownerDocument,!1,this),d=c.firstChild,1===c.childNodes.length&&(c=d),d)){for(f=n.map(ob(c,"script"),kb),g=f.length;l>j;j++)h=c,j!==o&&(h=n.clone(h,!0,!0),g&&n.merge(f,ob(h,"script"))),b.call(this[j],h,j);if(g)for(i=f[f.length-1].ownerDocument,n.map(f,lb),j=0;g>j;j++)h=f[j],fb.test(h.type||"")&&!L.access(h,"globalEval")&&n.contains(i,h)&&(h.src?n._evalUrl&&n._evalUrl(h.src):n.globalEval(h.textContent.replace(hb,"")))}return this}}),n.each({appendTo:"append",prependTo:"prepend",insertBefore:"before",insertAfter:"after",replaceAll:"replaceWith"},function(a,b){n.fn[a]=function(a){for(var c,d=[],e=n(a),g=e.length-1,h=0;g>=h;h++)c=h===g?this:this.clone(!0),n(e[h])[b](c),f.apply(d,c.get());return this.pushStack(d)}});var qb,rb={};function sb(b,c){var d,e=n(c.createElement(b)).appendTo(c.body),f=a.getDefaultComputedStyle&&(d=a.getDefaultComputedStyle(e[0]))?d.display:n.css(e[0],"display");return e.detach(),f}function tb(a){var b=l,c=rb[a];return c||(c=sb(a,b),"none"!==c&&c||(qb=(qb||n("')}catch(i){r=Te[V]("iframe"),t(r,e)}r.height="0",r.width="0",r.style.display="none",r.style.visibility="hidden";var s=Te[Q],s=He()+"/analytics_iframe.html#"+H(s[ne]+"//"+s[X]+"/favicon.ico"),o=function(){r.src="",r[we]&&r[we].removeChild(r)};Se(Ae,"beforeunload",o);var a=!1,c=0,u=function(){if(!a){try{if(c>9||r.contentWindow[Q][X]==Te[Q][X])return a=!0,o(),Le(Ae,"beforeunload",o),void n()}catch(e){}c++,O(u,200)}};return Se(r,"load",u),Te.body.appendChild(r),r.src=s,!0},Ye=function(){this.t=[]};Ye[pe].add=function(e){this.t[oe](e)},Ye[pe].D=function(e){try{for(var t=0;t=n)&&(n={},zn(n)||Bn(n))){var r=n[Mt];void 0==r||1/0==r||isNaN(r)||(r>0?(Un(n,Ht),Un(n,Ft),Un(n,Ot),Un(n,Rt),Un(n,Nt),Un(n,zt),Un(n,Bt),t(n)):Se(Ae,"load",function(){Fn(e,t)},!1))}},zn=function(e){var t=Ae.performance||Ae.webkitPerformance,t=t&&t.timing;if(!t)return!1;var n=t.navigationStart;return 0==n?!1:(e[Mt]=t.loadEventStart-n,e[Ht]=t.domainLookupEnd-t.domainLookupStart,e[Ft]=t.connectEnd-t.connectStart,e[Ot]=t.responseStart-t.requestStart,e[Rt]=t.responseEnd-t.responseStart,e[Nt]=t.fetchStart-n,e[zt]=t.domInteractive-n,e[Bt]=t.domContentLoadedEventStart-n,!0)},Bn=function(e){if(Ae.top!=Ae)return!1;var t=Ae.external,n=t&&t.onloadT;return t&&!t.isValidLoadTime&&(n=void 0),n>2147483648&&(n=void 0),n>0&&t.setPageReadyTime(),void 0==n?!1:(e[Mt]=n,!0)},Un=function(e,t){var n=e[t];(isNaN(n)||1/0==n||0>n)&&(e[t]=void 0)},Wn=function(e){return function(t){"pageview"!=t.get(mt)||e.I||(e.I=!0,Fn(t,function(t){e[W]("timing",t)}))}},Yn=!1,Vn=function(e){if("cookie"==Ze(e,Tn)){var t=Ze(e,kn),r=Xn(e),i=er(Ze(e,Sn)),s=Qn(Ze(e,Cn)),o=1e3*et(e,Ln),a=Ze(e,xn);if("auto"!=s)Pe(t,r,i,s,a,o)&&(Yn=!0);else{n(32);var c;if(r=[],s=p()[K]("."),4!=s[me]||(c=s[s[me]-1],parseInt(c,10)!=c)){for(c=s[me]-2;c>=0;c--)r[oe](s[ue](c)[xe]("."));r[oe]("none"),c=r}else c=["none"];for(var u=0;u1&&(n+="-"+e),["GA1",n,t][xe](".")},Kn=function(e,t,n){for(var r,i=[],s=[],o=0;o0;){if(a[re]&&a.nodeName[U](/^a(?:rea)?$/i)){s=a;break e}a=a[we],i--}s={}}("http:"==s[ne]||"https:"==s[ne])&&P(t,s[ee]||"")&&s[re]&&e(s,sr(o,s[re],r))}catch(c){n(26)}}var o=this;if(this.T||(this.T=!0,Se(Te,"mousedown",s,!1),Se(Te,"touchstart",s,!1),Se(Te,"keyup",s,!1)),i){i=function(e){if(e=e||Ae.event,(e=e[ve]||e.srcElement)&&e[ie]){var n=e[ie][U](nr);n&&P(t,n[1])&&or(o,e)}};for(var a=0;ai[me])){r=[];for(var s=0;s=c[0]||0>=c[1]?"":c[xe]("x"),e.set(St,r),e.set(qt,A()),e.set(xt,Te.characterSet||Te.charset),e.set(Lt,t&&"function"==typeof t.javaEnabled&&t.javaEnabled()||!1),e.set(wt,(t&&(t.language||t.browserLanguage)||"")[ke]()),i&&e.get(En)&&(t=Te[Q][ae])){for(t=t[K](/[?&#]+/),i=[],r=0;rarguments[me])){var t,r;"string"==typeof arguments[0]?(t=arguments[0],r=[][ue][be](arguments,1)):(t=arguments[0]&&arguments[0][mt],r=arguments),t&&(r=v(wr[t]||[],r),r[mt]=t,this.b.set(r,void 0,!0),this.filters.D(this.b),this.b[B].m={},n(44))}};var xr,kr,Cr,Sr=function(e){return"prerender"==Te.visibilityState?!1:(e(),!0)},Lr=/^(?:(\w+)\.)?(?:(\w+):)?(\w+)$/,qr=function(e){if(r(e[0]))this.u=e[0];else{var t=Lr.exec(e[0]);if(null!=t&&4==t[me]&&(this.c=t[1]||"t0",this.e=t[2]||"",this.d=t[3],this.a=[][ue][be](e,1),this.e||(this.A="create"==this.d,this.i="require"==this.d,this.g="provide"==this.d,this.ba="remove"==this.d),this.i&&(3<=this.a[me]?(this.X=this.a[1],this.W=this.a[2]):this.a[1]&&(s(this.a[1])?this.X=this.a[1]:this.W=this.a[1]))),t=e[1],e=e[2],!this.d)throw"abort";if(this.i&&(!s(t)||""==t))throw"abort";if(this.g&&(!s(t)||""==t||!r(e)))throw"abort";if(M(this.c)||M(this.e))throw"abort";if(this.g&&"t0"!=this.c)throw"abort"}};xr=new qe,Cr=new qe,kr={ec:45,ecommerce:46,linkid:47};var Ar=function(e,t,i){t==Er?n(35):t.get(jn);var s=xr.get(e);return r(s)?(t.plugins_=t.plugins_||new qe,t.plugins_.get(e)?!0:(t.plugins_.set(e,new s(t,i||{})),!0)):!1},Tr=function(t){function n(e){var t=(e[ee]||"")[K](":")[0][ke](),n=(e[ne]||"")[ke](),n=1*e[Y]||("http:"==n?80:"https:"==n?443:"");return e=e.pathname||"",o(e,"/")||(e="/"+e),[t,""+n,e]}var r=Te[V]("a");e(r,Te[Q][re]);var i=(r[ne]||"")[ke](),s=n(r),a=r[te]||"",c=i+"//"+s[0]+(s[1]?":"+s[1]:"");return o(t,"//")?t=i+t:o(t,"/")?t=c+t:!t||o(t,"?")?t=c+s[2]+(t||a):0>t[K]("/")[0][de](":")&&(t=c+s[2][je](0,s[2].lastIndexOf("/"))+"/"+t),e(r,t),i=n(r),{protocol:(r[ne]||"")[ke](),host:i[0],port:i[1],path:i[2],G:r[te]||"",url:t||""}},_r={ga:function(){_r.f=[]}};_r.ga(),_r.D=function(e){var t=_r.J[se](_r,arguments),t=_r.f.concat(t);for(_r.f=[];0n;n++)s=o[n],window.ga("set",s.name,s.content)},n=function(){var n;return n={title:t(),path:e()},window.ga("send","pageview",n)},r=function(){return i(),n()},function(){var e;if(e=document.querySelector("meta[name=google-analytics]"))return window.ga("create",e.content,"github.com"),i()}(),$(function(){return n()}),document.addEventListener("pjax:complete",function(){return setTimeout(r,20)})}.call(this),function(){var e,t,n,r,i=function(e,t){function n(){this.constructor=e}for(var r in t)s.call(t,r)&&(e[r]=t[r]);return n.prototype=t.prototype,e.prototype=new n,e.__super__=t.prototype,e},s={}.hasOwnProperty;e=function(e){function t(e){this.name="InvalidGAEventValueError",this.message="The event value in '"+JSON.stringify(e)+"' has to be an integer."}return i(t,e),t}(Error),n=function(t,n){var r;if(null==n&&(n=!0),t=t.trim().split(/\s*,\s*/),t[3])if(/^\d+$/.test(t[3]))t[3]=Number(t[3]);else if($(document.documentElement).hasClass("is-preview-features"))return r=new e(t),void setImmediate(function(){throw r});t.unshift("send","event"),t.push({useBeacon:!0,nonInteraction:!n}),window.ga.apply(null,t)},t=function(e){var t;t=$(e.target).closest("[data-ga-click]").attr("data-ga-click"),t&&n(t)},r=function(e){window.ga("send","pageview",e)},$.observe("[data-ga-load]",function(){n(this.getAttribute("data-ga-load"),!1)}),$.observe("meta[name=analytics-event]",function(){n(this.content,!1)}),$.observe("meta[name=analytics-virtual-pageview]",function(){r(this.content)}),window.addEventListener("click",t,!0)}.call(this),$.observe(".js-in-app-popup",function(e){setTimeout(function(e){return function(){return $(e).submit()}}(this),15e3)}),function(){$.pageFocused=function(){return new Promise(function(e){var t;return t=function(){document.hasFocus()&&(e(),document.removeEventListener("visibilitychange",t),window.removeEventListener("focus",t),window.removeEventListener("blur",t))},document.addEventListener("visibilitychange",t),window.addEventListener("focus",t),window.addEventListener("blur",t),t()})}}.call(this),function(){var e,t,n,r,i,s,o;i=0,n=-1,t=function(e){var t,n,r,i;return t=e.getBoundingClientRect(),r=$(window).height(),i=$(window).width(),0===t.height?!1:t.height=0&&t.left>=0&&t.bottom<=r&&t.right<=i:(n=Math.ceil(r/2),t.top>=0&&t.top+nr;r++)n=s[r],t(n)?c.push(null!=(o=e["in"])?o.call(n,n,e):void 0):c.push(null!=(a=e.out)?a.call(n,n,e):void 0);return c},o=function(t){return document.hasFocus()&&window.scrollY!==n&&(n=window.scrollY,!t.checkPending)?(t.checkPending=!0,window.requestAnimationFrame(function(){return t.checkPending=!1,e(t)})):void 0},r=function(t,n){return 0===n.elements.length&&(window.addEventListener("scroll",n.scrollHandler),$.pageFocused().then(function(){return e(n)})),n.elements.push(t)},s=function(e,t){var n;return n=t.elements.indexOf(e),-1!==n&&t.elements.splice(n,1),0===t.elements.length?window.removeEventListener("scroll",t.scrollHandler):void 0},$.inViewport=function(e,t){var n;return null!=t.call&&(t={"in":t}),n={id:i++,selector:e,"in":t["in"],out:t.out,elements:[],checkPending:!1},n.scrollHandler=function(){return o(n)},$.observe(e,{add:function(e){return r(e,n)},remove:function(e){return s(e,n)}}),n}}.call(this),$.interactiveElement=function(){var e,t,n;return document.activeElement!==document.body?e=document.activeElement:(t=document.querySelectorAll(":hover"),(n=t.length)&&(e=t[n-1])),$(e)},function(){var e,t,n;e=require("github/fetch").fetchJSON,t=function(){var t,r,i,s,o,a,c,u,l;if(l=this.getAttribute("data-url")){for(u=e(l),a=this.getAttribute("data-id"),i=document.querySelectorAll(".js-issue-link[data-id='"+a+"']"),o=0,c=i.length;c>o;o++)r=i[o],r.removeAttribute("data-url");return t=function(e){return n(i,e.title)},s=function(e){return function(t){var r,s,o;return o=(null!=(s=t.response)?s.status:void 0)||500,r=function(){switch(o){case 404:return this.getAttribute("data-permission-text");default:return this.getAttribute("data-error-text")}}.call(e),n(i,r)}}(this),u.then(t,s)}},n=function(e,t){var n,r,i,s;for(s=[],r=0,i=e.length;i>r;r++)n=e[r],s.push(n.setAttribute("title",t));return s},$.observe(".js-issue-link",function(){this.addEventListener("mouseenter",t)})}.call(this),$(document).on("ajaxSuccess",".js-immediate-updates",function(e,t,n,r){var i,s,o;if(this===e.target){s=r.updateContent;for(o in s)i=s[o],$(o).updateContent(i)}}),function(){$.observe(".labeled-button:checked",{add:function(){return $(this).parent("label").addClass("selected")},remove:function(){return $(this).parent("label").removeClass("selected")}})}.call(this),function(){var e;e="is-last-changed",$(document).on("change","form.js-form-last-changed",function(t){var n,r;n=t.target,null!=(r=this.querySelector("."+e))&&r.classList.remove(e),n.classList.add(e)})}.call(this),function(){var e,t,n,r,i,s=[].indexOf||function(e){for(var t=0,n=this.length;n>t;t++)if(t in this&&this[t]===e)return t;return-1};t=null,e=function(e){t&&n(t),$(e).fire("menu:activate",function(){return $(document).on("keydown.menu",i),$(document).on("click.menu",r),t=e,$(e).performTransition(function(){return e.classList.add("active"),$(e).find(".js-menu-content[aria-hidden]").attr("aria-hidden","false")}),$(e).fire("menu:activated",{async:!0})})},n=function(e){$(e).fire("menu:deactivate",function(){return $(document).off(".menu"),t=null,$(e).performTransition(function(){return e.classList.remove("active"),$(e).find(".js-menu-content[aria-hidden]").attr("aria-hidden","true")}),$(e).fire("menu:deactivated",{async:!0})})},r=function(e){t&&($(e.target).closest(t)[0]||(e.preventDefault(),n(t)))},i=function(e){t&&"esc"===e.hotkey&&(s.call($(document.activeElement).parents(),t)>=0&&document.activeElement.blur(),e.preventDefault(),n(t))},$(document).on("click",".js-menu-container",function(r){var i,s,o;i=this,(o=$(r.target).closest(".js-menu-target")[0])?(r.preventDefault(),i===t?n(i):e(i)):(s=$(r.target).closest(".js-menu-content")[0])||i===t&&(r.preventDefault(),n(i))}),$(document).on("click",".js-menu-container .js-menu-close",function(e){n($(this).closest(".js-menu-container")[0]),e.preventDefault()}),$.fn.menu=function(t){var r,i;return(r=$(this).closest(".js-menu-container")[0])?(i={activate:function(){return e(r)},deactivate:function(){return n(r)}},"function"==typeof i[t]?i[t]():void 0):void 0},$.observe(".js-menu-container.active",{add:function(){return document.body.classList.add("menu-active")},remove:function(){return document.body.classList.remove("menu-active")}})}.call(this),function(){function e(e){"enter"===e.hotkey&&($(this).click(),e.preventDefault())}$(document).on("focus","div.btn-sm, span.btn-sm",function(){$(this).on("keydown",e)}),$(document).on("blur","div.btn-sm, span.btn-sm",function(){$(this).off("keydown",e)})}.call(this),$(document).on("submit",".js-mobile-preference-form",function(e){var t;return t=$(this).find(".js-mobile-preference-anchor-field"),t.val(window.location.hash.substr(1)),!0}),function(){var e,t,n;e=require("github/debounce")["default"],$.fn.notScrolling=function(){return new Promise(function(e){return function(t,r){return 1===e.length?n(e[0],t):t()}}(this))},t=0,window.addEventListener("scroll",function(e){t=e.timeStamp||(new Date).getTime()},!0),n=function(n,r){var i;return n===window&&t<(new Date).getTime()-500?void setImmediate(r):(i=e(function(){return n.removeEventListener("scroll",i,!1), +r()},500),n.addEventListener("scroll",i,!1),void i())}}.call(this),function(){$(document).on("ajaxSuccess",".js-notice-dismiss",function(){return $(this).closest(".js-notice").fadeOut()}),$(document).on("click",".js-notice-dismiss-action",function(){return $(this).closest(".js-notice").find(".js-notice-dismiss").submit()})}.call(this),function(){$.observeLast=function(e,t){var n,r;null==t&&(t="last"),n=r=function(){$(e).removeClass(t).last().addClass(t)},$.observe(e,{add:n,remove:r})}}.call(this),function(){$(document).on("click",".js-permalink-shortcut",function(){return window.location=this.href+window.location.hash,!1})}.call(this),function(){document.addEventListener("pjax:start",function(e){var t;(t=e.relatedTarget)&&($(t).addClass("pjax-active"),$(t).parents(".js-pjax-active").addClass("pjax-active"))}),document.addEventListener("pjax:end",function(){$(".pjax-active").removeClass("pjax-active")})}.call(this),function(){document.addEventListener("pjax:click",function(e){return window.onbeforeunload?e.preventDefault():void 0})}.call(this),function(){var e,t;e=require("delegated-events"),t=function(){var e,t;return t=function(){var t,n,r;for(r=[],t=0,n=arguments.length;n>t;t++)e=arguments[t],r.push(e.split("/",3).join("/"));return r}.apply(this,arguments),t[0]===t[1]},e.on("pjax:click","#js-repo-pjax-container a[href]",function(e){return t(this.pathname,location.pathname)?void 0:e.preventDefault()}),e.on("pjax:click",".js-comment-body",function(e){return"files"===e.target.pathname.split("/")[3]?e.preventDefault():void 0})}.call(this),function(){var e,t;t={},$(e=function(){return t[document.location.pathname]=$("head [data-pjax-transient]")}),document.addEventListener("pjax:beforeReplace",function(e){var n,r,i,s,o;for(n=e.detail.contents,i=s=0,o=n.length;o>s;i=++s)r=n[i],r&&("pjax-head"===r.id?(t[document.location.pathname]=$(r).children(),n[i]=null):"js-flash-container"===r.id&&($("#js-flash-container").replaceWith(r),n[i]=null))}),document.addEventListener("pjax:end",function(){var e,n,r;return e=t[document.location.pathname],e?($("head [data-pjax-transient]").remove(),r=$(e).not("title, script, link[rel='stylesheet']"),n=$(e).filter("link[rel='stylesheet']"),$(document.head).append(r.attr("data-pjax-transient",!0)),$(document.head).append(n)):void 0})}.call(this),function(){var e,t,n;t=require("github/pjax"),n=function(e){return null!=e.getAttribute("data-pjax-preserve-scroll")?!1:0},e=function(e){var t,n,r;return t=$(e),n=t.add(t.parents("[data-pjax]")).map(function(){var e;return e=this.getAttribute("data-pjax"),null!=e&&"true"!==e?e:void 0}),(r=n[0])?document.querySelector(r):$(e).closest("[data-pjax-container]")[0]},$(document).on("click","[data-pjax] a, a[data-pjax]",function(r){var i,s;return s=this,null==s.getAttribute("data-skip-pjax")&&null==s.getAttribute("data-remote")&&(i=e(s))?t.click(r,{container:i,scrollTo:n(s)}):void 0}),$(document).on("submit","form[data-pjax]",function(r){var i,s;return s=this,(i=e(s))?t.submit(r,{container:i,scrollTo:n(s)}):void 0})}.call(this),function(){var e,t,n,r,i,s,o,a;o=require("github/stats")["default"],t=null,i="last_pjax_request",s="pjax_start",r="pjax_end",n=function(e){var n,r;(r=null!=(n=e.relatedTarget)?n.href:void 0)&&(window.performance.mark(s),t=r)},a=function(){setImmediate(function(){var n,a,c;if(window.performance.getEntriesByName(s).length&&(window.performance.mark(r),window.performance.measure(i,s,r),a=window.performance.getEntriesByName(i),n=null!=(c=a.pop())?c.duration:void 0))return o({pjax:{url:t,ms:Math.round(n)}}),e()})},e=function(){window.performance.clearMarks(s),window.performance.clearMarks(r),window.performance.clearMeasures(i)},document.addEventListener("pjax:start",n),document.addEventListener("pjax:end",a)}.call(this),function(){function e(e){var t,n,r,i;for(n=[];e;)r=e.getBoundingClientRect(),i=r.top,t=r.left,n.push({element:e,top:i,left:t}),e=e.parentElement;return n}function t(e){var t,n,r;for(t=0,n=e.length;n>t;t++)if(r=e[t],$.contains(document,r.element))return r}$.fn.preservingScrollPosition=function(e){return $.preservingScrollPosition(this[0],e),this},$.preservingScrollPosition=function(n,r){var i,s,o,a,c,u,l,d;return n?(o=e(n),l=r.call(n),(s=t(o))?(n=s.element,c=s.top,a=s.left,u=n.getBoundingClientRect(),d=u.top,i=u.left,$(n).cumulativeScrollBy(i-a,d-c),l):void 0):r()}}.call(this),$.preserveInteractivePosition=function(e){return $(window).notScrolling().then(function(){var t;return t=$.interactiveElement()[0],$.preservingScrollPosition(t,e)})},$(function(){document.body.classList.contains("js-print-popup")&&(window.print(),setTimeout(window.close,1e3))}),function(){var e;e=require("github/failbot").errorContext,$(function(){var t,n;return document.documentElement.classList.contains("is-employee")?(t=function(){return"qi:"+document.location},n=[],$(document).on("submit",".js-quick-issue-form",function(){var e;$(".facebox-content > *").hide(),$(".facebox-content .js-quick-issue-thanks").show(),e=t();try{localStorage.removeItem(e)}catch(n){}return!0}),$(document).onFocusedInput(".js-quick-issue-body",function(){return function(){var e,n;e=t(),n=$(this).val();try{return localStorage.setItem(e,n)}catch(r){}}}),document.addEventListener("facebox:reveal",function(){var e,n,r;return $(".facebox-content .quick-issue-link").remove(),r=$(".facebox-content .js-quick-issue-body"),r.length?(n=t(),e=function(){try{return localStorage.getItem(n)}catch(e){}}(),e&&r.val(e),r.focus()):void 0}),$(window).on("error",function(t){return n.push(e(t.originalEvent.error)),$(".js-captured-errors").val(JSON.stringify(n))}),$(document).on("ajaxSuccess",".js-quick-issue-form",function(e,t,n){return $(".js-quick-issue-thanks").append(t.responseText)})):void 0})}.call(this),$(document).onFocusedKeydown(".js-quick-submit",function(){return function(e){var t,n;return"ctrl+enter"===e.hotkey||"meta+enter"===e.hotkey?(n=$(this).closest("form"),t=n.find("input[type=submit], button[type=submit]").first(),t.prop("disabled")||n.submit(),!1):void 0}}),function(){var e,t,n,r=function(e,t){return function(){return e.apply(t,arguments)}};t=require("github/sliding-promise-queue")["default"],n=require("github/fetch").fetchText,e=function(){function e(e){this.resultsChanged=r(this.resultsChanged,this),this.fetchResults=r(this.fetchResults,this),this.onFieldInput=r(this.onFieldInput,this),this.onNavigationKeyDown=r(this.onNavigationKeyDown,this),this.teardown=r(this.teardown,this),this.$field=$(e),this.$form=$(e.form),this.fetchQueue=new t,this.$field.on("input.results",this.onFieldInput),this.$field.on("focusout:delayed.results",this.teardown),this.$form.on("submit.results",this.teardown),this.$results=$(".js-quicksearch-results"),this.$results.navigation("push"),this.$results.on("navigation:keydown.results",this.onNavigationKeyDown)}return e.prototype.teardown=function(){return this.$field.off(".results"),this.$form.off(".results"),this.$results.off(".results"),this.$results.removeClass("active"),this.$results.navigation("pop")},e.prototype.onNavigationKeyDown=function(e){return"esc"===e.hotkey?this.$results.removeClass("active").navigation("clear"):"enter"!==e.hotkey||e.target.classList.contains("js-navigation-item")?void 0:(this.$form.submit(),!1)},e.prototype.onFieldInput=function(){return this.fetchResults(this.$field.val())},e.prototype.fetchResults=function(e){var t,r,i;return(i=this.$results.attr("data-quicksearch-url"))?(r=e.trim()?(i+=~i.indexOf("?")?"&":"?",i+=this.$form.serialize(),this.$form.addClass("is-sending"),n(i)):Promise.resolve(""),t=function(e){return function(){return e.$form.removeClass("is-sending")}}(this),this.fetchQueue.push(r).then(function(e){return function(t){return e.$results.html(t),e.resultsChanged()}}(this)).then(t,t)):void 0},e.prototype.resultsChanged=function(){var e;return e=""!==this.$field.val(),this.$results.toggleClass("active",e)},e}(),$(document).on("focusin:delayed",".js-quicksearch-field",function(){new e(this)})}.call(this),function(){var e,t,n,r,i,s,o,a,c,u,l,d=[].slice;for(a=function(){var e,t,n,r,i;for(e=arguments[0],i=2<=arguments.length?d.call(arguments,1):[],t=0,r=i.length;r>t;t++)if(n=i[t],e.classList.contains(n))return!0;return!1},r=function(e){var t,n,r,i,s;for(s=e.parentNode.children,t=r=0,i=s.length;i>r;t=++r)if(n=s[t],n===e)return t},n=function(e){return"IMG"===e.nodeName||null!=e.firstChild},o=0,c=function(e){var t,n;return t=e.childNodes[0],n=e.childNodes[1],t&&e.childNodes.length<3?!("OL"!==t.nodeName&&"UL"!==t.nodeName||n&&(n.nodeType!==Node.TEXT_NODE||n.textContent.trim())):void 0},t={CODE:function(e){var t;return t=e.textContent,"PRE"===e.parentNode.nodeName?e.textContent=t.replace(/^/gm," "):t.indexOf("`")>=0?"`` "+t+" ``":"`"+t+"`"},PRE:function(e){var t;return t=e.parentNode,"DIV"===t.nodeName&&t.classList.contains("highlight")&&(e.textContent=e.textContent.replace(/^/gm," "),e.append("\n\n")),e},STRONG:function(e){return"**"+e.textContent+"**"},EM:function(e){return"_"+e.textContent+"_"},BLOCKQUOTE:function(e){var t,n;return n=e.textContent.trim().replace(/^/gm,"> "),t=document.createElement("pre"),t.textContent=n+"\n\n",t},A:function(e){var t;return t=e.textContent,a(e,"issue-link","user-mention","team-mention")?t:/^https?:/.test(t)&&t===e.getAttribute("href")?t:"["+t+"]("+e.getAttribute("href")+")"},IMG:function(e){var t;return t=e.getAttribute("alt"),a(e,"emoji")?t:"!["+t+"]("+e.getAttribute("src")+")"},LI:function(e){var t,n;if(!c(e))switch(t=e.parentNode,t.nodeName){case"UL":e.prepend("* ");break;case"OL":o>0&&!t.previousSibling?(n=r(e)+o+1,e.prepend(n+"\\. ")):e.prepend(r(e)+1+". ")}return e},OL:function(e){var t;return t=document.createElement("li"),t.append(document.createElement("br")),e.append(t),e},H1:function(e){var t;return t=parseInt(e.nodeName.slice(1)),e.prepend(Array(t+1).join("#")+" "),e}},t.UL=t.OL,s=i=2;6>=i;s=++i)t["H"+s]=t.H1;e=function(e,r){var i,s,o,a,c,u;a=document.createNodeIterator(e,NodeFilter.SHOW_ELEMENT,{acceptNode:function(e){return e.nodeName in t&&n(e)?NodeFilter.FILTER_ACCEPT:void 0}}),c=[];for(;o=a.nextNode();)c.push(o);for(c.reverse(),u=[],i=0,s=c.length;s>i;i++)o=c[i],u.push(r(o));return u},u=function(e,t){var n,r,i;n=document.createElement("div"),n.appendChild(t),n.style.cssText="position:absolute;left:-9999px;",document.body.appendChild(n);try{r=document.createRange(),r.selectNodeContents(n),e.removeAllRanges(),e.addRange(r),i=e.toString(),e.removeAllRanges()}finally{document.body.removeChild(n)}return i},l=function(n){var i,s,a,c;return i=n.getRangeAt(0).cloneContents(),o=0,(a=n.anchorNode.parentNode.closest("li"))&&("OL"===a.parentNode.nodeName&&(o=r(a)),i.querySelector("li")||(c=document.createElement(a.parentNode.nodeName),s=document.createElement("li"),s.append(i),c.append(s),i=document.createDocumentFragment(),i.appendChild(c))),e(i,function(e){var n;return n=t[e.nodeName](e),e.replaceWith(n)}),u(n,i)},$(document).on("quote:selection",".js-quote-markdown",function(e){var t,n,r,i;r=e.detail.selection;try{return i=l(r),e.detail.selectionText=i.replace(/^\n+/,"").replace(/\s+$/,"")}catch(n){return t=n,setImmediate(function(){throw t})}})}.call(this),function(){$(document).on("keydown",function(e){var t,n,r,i,s,o,a,c,u;if("r"===e.hotkey&&!e.isDefaultPrevented()&&!e.isFormInteraction()&&(c=window.getSelection(),r=$(c.focusNode),(u=$.trim(c.toString()))&&(t=r.closest(".js-quote-selection-container"),t.length))){if(s=$.Event("quote:selection",{detail:{selection:c,selectionText:u}}),t.trigger(s),s.isDefaultPrevented())return!1;if(u=s.detail.selectionText,n=t.find(".js-quote-selection-target").visible().first(),o=n[0])return a="> "+u.replace(/\n/g,"\n> ")+"\n\n",(i=o.value)&&(a=i+"\n\n"+a),o.value=a,n.trigger("change"),n.scrollTo({duration:300},function(){return o.focus(),o.selectionStart=o.value.length,n.scrollTop(o.scrollHeight)}),e.preventDefault()}})}.call(this),$(document).on("ajaxSuccess",".js-pick-reaction",function(e,t,n,r){$(this.closest(".js-menu-container")).menu("deactivate");var i=this.closest(".js-comment");if(i){var s,o,a=$.parseHTML(r.reactions_container.trim()),c=$.parseHTML(r.comment_header_reaction_button.trim());(s=i.querySelector(".js-reactions-container")).replaceWith.apply(s,_toConsumableArray(a)),(o=i.querySelector(".js-comment-header-reaction-button")).replaceWith.apply(o,_toConsumableArray(c))}});var showReactionContent=function(){var e=this.getAttribute("data-reaction-label");this.closest(".js-add-reaction-popover").querySelector(".js-reaction-description").textContent=e},hideReactionContent=function(){this.closest(".js-add-reaction-popover").querySelector(".js-reaction-description").textContent="Pick your reaction"};$(document).on("menu:activated",".js-reaction-popover-container",function(){$(this).on("mouseenter",".js-reaction-option-item",showReactionContent),$(this).on("mouseleave",".js-reaction-option-item",hideReactionContent)}),$(document).on("menu:deactivated",".js-reaction-popover-container",function(){$(this).off("mouseenter",".js-reaction-option-item",showReactionContent),$(this).off("mouseleave",".js-reaction-option-item",hideReactionContent)}),function(){$.observe(".has-removed-contents",function(){var e,t,n;return e=$(this).contents(),t=function(){return e.detach()},n=function(){return $(this).html(e)},{add:t,remove:n}})}.call(this),function(){var e,t;e=require("github/fetch").fetchText,$(document).on("focusin",".js-repo-filter .js-filterable-field",function(){var e;(e=this.closest(".js-repo-filter").querySelector(".js-more-repos-link"))&&t(e)}),$(document).on("click",".js-repo-filter .js-repo-filter-tab",function(e){var n,r,i,s,o,a;for(n=this.closest(".js-repo-filter"),(o=n.querySelector(".js-more-repos-link"))&&t(o),a=n.querySelectorAll(".js-repo-filter-tab"),i=0,s=a.length;s>i;i++)r=a[i],r.classList.toggle("filter-selected",r===this);$(n.querySelector(".js-filterable-field")).fire("filterable:change"),e.preventDefault()}),$(document).on("filterable:change",".js-repo-filter .js-repo-list",function(){var e,t,n;e=this.closest(".js-repo-filter"),(n=null!=(t=e.querySelector(".js-repo-filter-tab.filter-selected"))?t.getAttribute("data-filter"):void 0)&&$(this).children().not(n).hide()}),t=function(t){var n,r;if(!t.classList.contains("is-loading"))return t.classList.add("is-loading"),r=function(e){var n;return n=t.closest(".js-repo-filter"),n.querySelector(".js-repo-list").innerHTML=e,$(n.querySelector(".js-filterable-field")).fire("filterable:change"),t.remove()},n=function(){return t.classList.remove("is-loading")},e(t.href).then(r).then(n,n)},$(document).on("click",".js-more-repos-link",function(e){e.preventDefault(),t(this)})}.call(this),$(document).on("ajaxSuccess",".js-select-menu:not([data-multiple])",function(){return $(this).menu("deactivate")}),$(document).on("ajaxSend",".js-select-menu:not([data-multiple])",function(){return $(this).addClass("is-loading")}),$(document).on("ajaxComplete",".js-select-menu",function(){return $(this).removeClass("is-loading")}),$(document).on("ajaxError",".js-select-menu",function(){return $(this).addClass("has-error")}),$(document).on("menu:deactivate",".js-select-menu",function(){return $(this).removeClass("is-loading has-error")}),function(){var e;e=require("delegated-events").fire,$(document).on("navigation:open",".js-select-menu:not([data-multiple]) .js-navigation-item",function(){var t,n;return n=$(this),t=n.closest(".js-select-menu"),t.find(".js-navigation-item.selected").removeClass("selected"),n.addClass("selected"),n.removeClass("indeterminate"),n.find("input[type=radio], input[type=checkbox]").prop("checked",!0).change(),e(this,"selectmenu:selected"),t.hasClass("is-loading")?void 0:t.menu("deactivate")}),$(document).on("navigation:open",".js-select-menu[data-multiple] .js-navigation-item",function(){var t,n;return t=$(this),n=t.hasClass("selected"),t.toggleClass("selected",!n),t.removeClass("indeterminate"),t.find("input[type=radio], input[type=checkbox]").prop("checked",!n).change(),e(this,"selectmenu:selected")})}.call(this),$(document).on("selectmenu:selected",".js-select-menu .js-navigation-item",function(){var e,t,n;return e=$(this).closest(".js-select-menu"),n=$(this).find(".js-select-button-text"),n[0]&&e.find(".js-select-button").html(n.html()),t=$(this).find(".js-select-menu-item-gravatar"),n[0]?e.find(".js-select-button-gravatar").html(t.html()):void 0}),$(document).on("selectmenu:change",".js-select-menu .select-menu-list",function(e){var t,n;t=$(this).find(".js-navigation-item"),t.removeClass("last-visible"),t.visible().last().addClass("last-visible"),$(this).is("[data-filterable-for]")||(n=$(e.target).hasClass("filterable-empty"),$(this).toggleClass("filterable-empty",n))}),$(document).on("menu:activated selectmenu:load",".js-select-menu",function(){return $(this).find(".js-filterable-field").focus()}),$(document).on("menu:deactivate",".js-select-menu",function(){var e,t,n,r,i,s;for($(this).find(".js-filterable-field").val("").trigger("filterable:change"),i=this.querySelectorAll(".js-navigation-item.selected"),s=[],e=0,r=i.length;r>e;e++)n=i[e],(t=n.querySelector("input[type=radio], input[type=checkbox]"))?s.push(n.classList.toggle("selected",t.checked)):s.push(void 0);return s}),function(){var e,t;e=require("delegated-events").fire,t=function(t){var n,r,i,s,o;return i=t.currentTarget,n=$(i),n.removeClass("js-load-contents"),n.addClass("is-loading"),n.removeClass("has-error"),s=n.attr("data-contents-url"),r=n.data("contents-data"),o=$.ajax({url:s,data:r}),o.then(function(t){n.removeClass("is-loading"),n.find(".js-select-menu-deferred-content").html(t),n.hasClass("active")&&e(i,"selectmenu:load")},function(){n.removeClass("is-loading"),n.addClass("has-error")})},$.observe(".js-select-menu.js-load-contents",{add:function(){$(this).on("mouseenter",t),$(this).on("menu:activate",t)},remove:function(){$(this).off("mouseenter",t),$(this).off("menu:activate",t)}})}.call(this),$(document).on("menu:activate",".js-select-menu",function(){$(this).find(":focus").blur(),$(this).find(".js-menu-target").addClass("selected"),$(this).find(".js-navigation-container").navigation("push")}),$(document).on("menu:deactivate",".js-select-menu",function(){$(this).find(".js-menu-target").removeClass("selected"),$(this).find(".js-navigation-container").navigation("pop")}),$(document).on("filterable:change selectmenu:tabchange",".js-select-menu .select-menu-list",function(){$(this).navigation("refocus")}),function(){var e,t;e=require("delegated-events").fire,$(document).on("filterable:change",".js-select-menu .select-menu-list",function(n){var r,i,s,o;(i=this.querySelector(".js-new-item-form"))&&(r=n.relatedTarget.value,""===r||t(this,r)?$(this).removeClass("is-showing-new-item-form"):($(this).addClass("is-showing-new-item-form"),o=i.querySelector(".js-new-item-name"),"innerText"in o?o.innerText=r:o.textContent=r,null!=(s=i.querySelector(".js-new-item-value"))&&(s.value=r))),e(n.target,"selectmenu:change")}),t=function(e,t){var n,r,i,s,o;for(s=e.querySelectorAll(".js-select-button-text, .js-select-menu-filter-text"),n=0,i=s.length;i>n;n++)if(r=s[n],o=r.textContent.toLowerCase().trim(),o===t.toLowerCase())return!0;return!1}}.call(this),function(){var e,t;e=require("delegated-events").fire,$(document).on("menu:activate selectmenu:load",".js-select-menu",function(){var e;return e=$(this).find(".js-select-menu-tab"),e.attr("aria-selected","false").removeClass("selected"),e.first().attr("aria-selected","true").addClass("selected")}),$(document).on("click",".js-select-menu .js-select-menu-tab",function(e){var t,n,r,i;return n=this.closest(".js-select-menu"),(i=n.querySelector(".js-select-menu-tab.selected"))&&(i.classList.remove("selected"),i.setAttribute("aria-selected",!1)),this.classList.add("selected"),this.setAttribute("aria-selected",!0),(t=n.querySelector(".js-filterable-field"))&&((r=this.getAttribute("data-filter-placeholder"))&&t.setAttribute("placeholder",r),t.focus()),!1}),t=function(t,n){var r,i,s;s=t.getAttribute("data-tab-filter"),i=$(t).closest(".js-select-menu").find(".js-select-menu-tab-bucket"),r=i.filter(function(){return this.getAttribute("data-tab-filter")===s}),r.toggleClass("selected",n),n&&e(r[0],"selectmenu:tabchange")},$.observe(".js-select-menu .js-select-menu-tab.selected",{add:function(){return t(this,!0)},remove:function(){return t(this,!1)}})}.call(this),function(){var e,t,n,r;e=function(e){var t;return null==e&&(e=window.location),(t=document.querySelector("meta[name=session-resume-id]"))?t.content:e.pathname},r=null,$(window).on("submit:prepare",function(e){r=e.target,setImmediate(function(){return e.isDefaultPrevented()?r=null:void 0})}),t=function(e){var t,n,i,s;if(i="session-resume:"+e,s=function(e){return e.id&&e.value!==e.defaultValue&&e.form!==r},n=function(){var e,n,r,i;for(r=$(".js-session-resumable"),i=[],e=0,n=r.length;n>e;e++)t=r[e],s(t)&&i.push([t.id,t.value]);return i}(),n.length)try{sessionStorage.setItem(i,JSON.stringify(n))}catch(o){}},n=function(e){var t,n,r,i,s,o,a,c;if(i="session-resume:"+e,n=function(){try{return sessionStorage.getItem(i)}catch(e){}}()){try{sessionStorage.removeItem(i)}catch(u){}for(t=[],o=JSON.parse(n),r=0,s=o.length;s>r;r++)a=o[r],e=a[0],c=a[1],$(document).fire("session:resume",{targetId:e,targetValue:c},function(){var n;n=document.getElementById(e),n&&n.value===n.defaultValue&&(n.value=c,t.push(n))});setImmediate(function(){return $(t).trigger("change")})}},$(window).on("pageshow pjax:end",function(){n(e())}),$(window).on("pagehide",function(){t(e())}),window.addEventListener("pjax:beforeReplace",function(n){var r,i,s,o;(o=null!=(s=n.detail.previousState)?s.url:void 0)?(i=e(new URL(o)),t(i)):(r=new Error("pjax:beforeReplace event.detail.previousState.url is undefined"),setImmediate(function(){throw r}))})}.call(this),function(){var e,t,n;e=require("github/debounce")["default"],t=function(){var t,n,r;t=null,r=e(function(){return t=null},200),n={x:0,y:0},$(this).on("mousemove.userResize",function(e){var i;(n.x!==e.clientX||n.y!==e.clientY)&&(i=this.style.height,t&&t!==i&&$(this).trigger("user:resize"),t=i,r()),n={x:e.clientX,y:e.clientY}})},n=function(){$(this).off("mousemove.userResize")},$.event.special["user:resize"]={setup:t,teardown:n}}.call(this),function(){var e,t,n,r,i=require("github/dimensions"),s=i.overflowOffset;n=function(e){return $(e).on("user:resize.trackUserResize",function(){return $(e).addClass("is-user-resized"),$(e).css({"max-height":""})})},r=function(e){return $(e).off("user:resize.trackUserResize")},$(document).on("reset","form",function(){var e;e=$(this).find("textarea.js-size-to-fit"),e.removeClass("is-user-resized"),e.css({height:"","max-height":""})}),$.observe("textarea.js-size-to-fit",{add:n,remove:r}),e=function(e){var t,n,r;t=$(e),n=null,r=function(r){var i,o,a,c;e.value!==n&&t.is($.visible)&&(c=s(t[0]),c.top<0||c.bottom<0||(a=t.outerHeight()+c.bottom,e.style.maxHeight=a-100+"px",i=e.parentNode,o=i.style.height,i.style.height=$(i).css("height"),e.style.height="auto",t.innerHeight(e.scrollHeight),i.style.height=o,n=e.value))},t.on("change.sizeToFit",function(){return r()}),t.on("input.sizeToFit",function(){return r()}),e.value&&r()},t=function(e){$(e).off(".sizeToFit")},$.observe("textarea.js-size-to-fit:not(.is-user-resized)",{add:e,remove:t})}.call(this),function(){$(document).on("ajaxSuccess",".js-social-container",function(e,t,n,r){return $(this).find(".js-social-count").text(r.count)})}.call(this),define.amd="reconnectingwebsocket",function(e,t){"function"==typeof define&&define.amd?define([],t):"undefined"!=typeof module&&module.exports?module.exports=t():e.ReconnectingWebSocket=t()}(this,function(){function e(t,n,r){function i(e,t){var n=document.createEvent("CustomEvent");return n.initCustomEvent(e,!1,!1,t),n}var s={debug:!1,automaticOpen:!0,reconnectInterval:1e3,maxReconnectInterval:3e4,reconnectDecay:1.5,timeoutInterval:2e3,maxReconnectAttempts:null};r||(r={});for(var o in s)"undefined"!=typeof r[o]?this[o]=r[o]:this[o]=s[o];this.url=t,this.reconnectAttempts=0,this.readyState=WebSocket.CONNECTING,this.protocol=null;var a,c=this,u=!1,l=!1,d=document.createElement("div");d.addEventListener("open",function(e){c.onopen(e)}),d.addEventListener("close",function(e){c.onclose(e)}),d.addEventListener("connecting",function(e){c.onconnecting(e)}),d.addEventListener("message",function(e){c.onmessage(e)}),d.addEventListener("error",function(e){c.onerror(e)}),this.addEventListener=d.addEventListener.bind(d),this.removeEventListener=d.removeEventListener.bind(d),this.dispatchEvent=d.dispatchEvent.bind(d),this.open=function(t){if(a=new WebSocket(c.url,n||[]),t){if(this.maxReconnectAttempts&&this.reconnectAttempts>this.maxReconnectAttempts)return}else d.dispatchEvent(i("connecting")),this.reconnectAttempts=0;(c.debug||e.debugAll)&&console.debug("ReconnectingWebSocket","attempt-connect",c.url);var r=a,s=setTimeout(function(){(c.debug||e.debugAll)&&console.debug("ReconnectingWebSocket","connection-timeout",c.url),l=!0,r.close(),l=!1},c.timeoutInterval);a.onopen=function(n){clearTimeout(s),(c.debug||e.debugAll)&&console.debug("ReconnectingWebSocket","onopen",c.url),c.protocol=a.protocol,c.readyState=WebSocket.OPEN,c.reconnectAttempts=0;var r=i("open");r.isReconnect=t,t=!1,d.dispatchEvent(r)},a.onclose=function(n){if(clearTimeout(s),a=null,u)c.readyState=WebSocket.CLOSED,d.dispatchEvent(i("close"));else{c.readyState=WebSocket.CONNECTING;var r=i("connecting");r.code=n.code,r.reason=n.reason,r.wasClean=n.wasClean,d.dispatchEvent(r),t||l||((c.debug||e.debugAll)&&console.debug("ReconnectingWebSocket","onclose",c.url),d.dispatchEvent(i("close")));var s=c.reconnectInterval*Math.pow(c.reconnectDecay,c.reconnectAttempts);setTimeout(function(){c.reconnectAttempts++,c.open(!0)},s>c.maxReconnectInterval?c.maxReconnectInterval:s)}},a.onmessage=function(t){(c.debug||e.debugAll)&&console.debug("ReconnectingWebSocket","onmessage",c.url,t.data);var n=i("message");n.data=t.data,d.dispatchEvent(n)},a.onerror=function(t){(c.debug||e.debugAll)&&console.debug("ReconnectingWebSocket","onerror",c.url,t),d.dispatchEvent(i("error"))}},1==this.automaticOpen&&this.open(!1),this.send=function(t){if(a)return(c.debug||e.debugAll)&&console.debug("ReconnectingWebSocket","send",c.url,t),a.send(t);throw"INVALID_STATE_ERR : Pausing to reconnect websocket"},this.close=function(e,t){"undefined"==typeof e&&(e=1e3),u=!0,a&&a.close(e,t)},this.refresh=function(){a&&a.close()}}if("WebSocket"in window)return e.prototype.onopen=function(e){},e.prototype.onclose=function(e){},e.prototype.onconnecting=function(e){},e.prototype.onmessage=function(e){},e.prototype.onerror=function(e){},e.debugAll=!1,e.CONNECTING=WebSocket.CONNECTING,e.OPEN=WebSocket.OPEN,e.CLOSING=WebSocket.CLOSING,e.CLOSED=WebSocket.CLOSED,e}),delete define.amd,function(){var e,t,n,r,i,s,o,a;"undefined"!=typeof WebSocket&&null!==WebSocket&&(e=require("reconnectingwebsocket"),o={},n={},t=null,i=function(t){var r,i;if(r=document.head.querySelector("link[rel=web-socket]"))return i=new e(r.href),i.reconnectInterval=2e3*Math.random()+1e3,i.reconnectDecay=2,i.maxReconnectAttempts=5,i.addEventListener("open",function(){var e,t,n;n=[];for(t in o)e=o[t],n.push(i.send("subscribe:"+t));return n}),i.addEventListener("message",function(e){var t,r,i;i=JSON.parse(e.data),r=i[0],t=i[1],r&&t&&$(n[r]).trigger("socket:message",[t,r])}),i},r=function(e){var t,n;return null!=(t=null!=(n=e.getAttribute("data-channel"))?n.split(/\s+/):void 0)?t:[]},s=function(e){var s,a,c,u,l;if(null!=t?t:t=i())for(l=t,u=r(e),s=0,a=u.length;a>s;s++)c=u[s],l.readyState!==WebSocket.OPEN||o[c]||l.send("subscribe:"+c),o[c]=!0,null==n[c]&&(n[c]=[]),n[c].push(e)},a=function(e){var t,i,s,o;for(o=r(e),t=0,i=o.length;i>t;t++)s=o[t],n[s]=$(n[s]).not(e).slice(0)},$.observe(".js-socket-channel[data-channel]",{add:s,remove:a}))}.call(this),function(){var e,t,n;if(n=null!=(t=document.querySelector("meta[name=user-login]"))?t.content:void 0,null!=n){e=String(!!n.length);try{localStorage.setItem("logged-in",e)}catch(r){return}window.addEventListener("storage",function(t){var n;if(t.storageArea===localStorage&&"logged-in"===t.key&&t.newValue!==e)return e=t.newValue,n=document.querySelector(".js-stale-session-flash"),n.classList.toggle("is-signed-in","true"===e),n.classList.toggle("is-signed-out","false"===e),n.classList.remove("hidden"),$(window).on("popstate",function(e){return null!=e.state.container?location.reload():void 0}),$(document).on("submit","form",function(e){return e.preventDefault()})})}}.call(this),function(){var e,t,n;t=["position:absolute;","overflow:auto;","word-wrap:break-word;","top:0px;","left:-9999px;"],n=["box-sizing","font-family","font-size","font-style","font-variant","font-weight","height","letter-spacing","line-height","max-height","min-height","padding-bottom","padding-left","padding-right","padding-top","border-bottom","border-left","border-right","border-top","text-decoration","text-indent","text-transform","width","word-spacing"],e=new WeakMap,$.fn.textFieldMirror=function(r){var i,s,o,a,c,u,l,d,h,f,m,p;if((p=this[0])&&(d=p.nodeName.toLowerCase(),"textarea"===d||"input"===d)){if(u=e.get(p),u&&u.parentElement===p.parentElement)u.innerHTML="";else{for(u=document.createElement("div"),e.set(p,u),f=window.getComputedStyle(p),h=t.slice(0),"textarea"===d?h.push("white-space:pre-wrap;"):h.push("white-space:nowrap;"),o=0,a=n.length;a>o;o++)l=n[o],h.push(l+":"+f.getPropertyValue(l)+";");u.style.cssText=h.join(" ")}return r!==!1&&(c=document.createElement("span"),c.style.cssText="position: absolute;",c.className="text-field-mirror-marker",c.innerHTML=" "),"number"==typeof r?((m=p.value.substring(0,r))&&(s=document.createTextNode(m)),(m=p.value.substring(r))&&(i=document.createTextNode(m))):(m=p.value)&&(s=document.createTextNode(m)),s&&u.appendChild(s),c&&u.appendChild(c),i&&u.appendChild(i),u.parentElement||p.parentElement.insertBefore(u,p),u.scrollTop=p.scrollTop,u.scrollLeft=p.scrollLeft,u}}}.call(this),$.fn.textFieldSelectionPosition=function(e){var t,n,r;if((r=this[0])&&(null==e&&(e=r.selectionEnd),t=$(r).textFieldMirror(e)))return n=$(t).find(".text-field-mirror-marker").position(),n.top+=parseInt($(t).css("border-top-width"),10),n.left+=parseInt($(t).css("border-left-width"),10),setTimeout(function(){return $(t).remove()},5e3),n},define("github/suggester",["exports","jquery","./fetch","./hotkey"],function(e,t,n,r){function i(e){return e&&e.__esModule?e:{"default":e}}function s(e,t){if(!(e instanceof t))throw new TypeError("Cannot call a class as a function")}Object.defineProperty(e,"__esModule",{value:!0});var o=i(t),a=i(r),c=function(){function e(e,t){var n=[],r=!0,i=!1,s=void 0;try{for(var o,a=e[Symbol.iterator]();!(r=(o=a.next()).done)&&(n.push(o.value),!t||n.length!==t);r=!0);}catch(c){i=!0,s=c}finally{try{!r&&a["return"]&&a["return"]()}finally{if(i)throw s}}return n}return function(t,n){if(Array.isArray(t))return t;if(Symbol.iterator in Object(t))return e(t,n);throw new TypeError("Invalid attempt to destructure non-iterable instance")}}(),u=function(){function e(e,t){for(var n=0;n0){var s=r[0].cloneNode(!0);return n.suggester.innerHTML="",n.suggester.appendChild(s),o["default"](s).show(),o["default"](n.suggester).navigation("focus"),!0}return!1})}},{key:"searchQuery",value:function(){var e=this.textarea.selectionEnd,t=this.textarea.value.substring(0,e);if(!this.disableSuggestions(t))for(var n in this.types){var r=this.types[n],i=t.match(r.match);if(i)return r.normalizeMatch?r.normalizeMatch(r,e,i):this.normalizeMatch(r,e,i)}}},{key:"normalizeMatch",value:function(e,t,n){var r=n[2],i=n[3],s=t-r.length,o=t;return{type:e,text:r,query:i,startIndex:s,endIndex:o}}},{key:"loadSuggestions",value:function(){var e=this;if(!this.fragment.hasChildNodes()){var t=this.suggester.getAttribute("data-url");if(t){var r=l[t]||(l[t]=n.fetchText(t));return r.then(function(t){return e.onSuggestionsLoaded(t)})}}}},{key:"onSuggestionsLoaded",value:function(e){var t=this;return o["default"].parseHTML(e).forEach(function(e){return t.fragment.appendChild(e)}),document.activeElement===this.textarea?(this.currentSearch=null,this.checkQuery()):void 0}},{key:"stripCodeFencing",value:function(e){return e.replace(/`{3,}[^`]*\n(.+)?\n`{3,}/g,"")}},{key:"disableSuggestions",value:function(e){var t=e.match(/`{3,}/g);return t=t||this.stripCodeFencing(e).match(/`/g),t?t.length%2:void 0}}]),e}();e["default"]=d}),function(){var e,t,n,r,i,s,o,a,c,u,l,d,h,f;o=require("github/feature-detection")["default"],e=require("github/suggester")["default"],d=function(e,t,n){var r,i,s,o;return o=n[3],i=n[4],s=t-i.length,r=t,{type:e,text:o,query:i,startIndex:s,endIndex:r}},f={mention:{match:/(^|\s)(@([a-z0-9\-_\/]*))$/i,replace:"$1@$value ",search:function(e,t){var r,i,s;return s=c(t),r=$(e).find("ul.mention-suggestions"),i=r.fuzzyFilterSortList(t,{limit:5,text:n,score:s.score}),Promise.resolve([r,i])}},auditLogUser:{match:/(^|\s)((\-?actor:|\-?user:)([a-z0-9\-\+_]*))$/i,replace:"$1$3$value ",search:function(e,t){var n,r;return n=$(e).find("ul.user-suggestions"),r=n.fuzzyFilterSortList(t,{limit:5}),Promise.resolve([n,r])},normalizeMatch:d},auditLogOrg:{match:/(^|\s)((\-?org:)([a-z0-9\-\+_]*))$/i,replace:"$1$3$value ",search:function(e,t){var n,r;return n=$(e).find("ul.org-suggestions"),r=n.fuzzyFilterSortList(t,{limit:5}),Promise.resolve([n,r])},normalizeMatch:d},auditLogAction:{match:/(^|\s)((\-?action:)([a-z0-9\.\-\+_]*))$/i,replace:"$1$3$value ",search:function(e,t){var n,r;return n=$(e).find("ul.action-suggestions"),r=n.fuzzyFilterSortList(t,{limit:5}),Promise.resolve([n,r])},normalizeMatch:d},auditLogRepo:{match:/(^|\s)((\-?repo:)([a-z0-9\/\-\+_]*))$/i,replace:"$1$3$value ",search:function(e,t){var n,r;return n=$(e).find("ul.repo-suggestions"),r=n.fuzzyFilterSortList(t,{limit:5}),Promise.resolve([n,r])},normalizeMatch:d},auditLogCountry:{match:/(^|\s)((\-?country:)([a-z0-9\-\+_]*))$/i,replace:"$1$3$value ",search:function(e,t){var n,r;return n=$(e).find("ul.country-suggestions"),r=n.fuzzyFilterSortList(t,{limit:5}),Promise.resolve([n,r])},normalizeMatch:d},emoji:{match:/(^|\s)(:([a-z0-9\-\+_]*))$/i,replace:"$1$value ",getValue:function(e){return o.emoji&&e.getAttribute("data-raw-value")||e.getAttribute("data-value")},search:function(e,t){var n,r;return n=$(e).find("ul.emoji-suggestions"),t=" "+t.toLowerCase().replace(/_/g," "),r=n.fuzzyFilterSortList(t,{limit:5,text:s,score:i}),Promise.resolve([n,r])}},hashed:{match:/(^|\s)(\#([a-z0-9\-_\/]*))$/i,replace:"$1#$value ",search:function(e,t){var r,i,s,o;return r=$(e).find("ul.hashed-suggestions"),i=/^\d+$/.test(t)?(s=new RegExp("\\b"+t),function(e){return l(e,s)}):c(t).score,o=r.fuzzyFilterSortList(t,{limit:5,text:n,score:i}),Promise.resolve([r,o])}}},r={},s=function(e){var t;return t=e.getAttribute("data-emoji-name"),r[t]=" "+n(e).replace(/_/g," "),t},n=function(e){return e.getAttribute("data-text").trim().toLowerCase()},i=function(e,t){var n;return n=r[e].indexOf(t),n>-1?1e3-n:0},l=function(e,t){var n;return n=e.search(t),n>-1?1e3-n:0},h=function(e,n){var r,i,s,o,a,c,l;if(l=t(e,n[0]),0!==l.length){if(1===n.length)return[l[0],1,[]];for(a=null,i=0,s=l.length;s>i;i++)c=l[i],(r=u(e,n,c+1))&&(o=r[r.length-1]-c,(!a||o-1;)r.push(n++);return r},u=function(e,t,n){var r,i,s,o;for(i=[],r=s=1,o=t.length;o>=1?o>s:s>o;r=o>=1?++s:--s){if(n=e.indexOf(t[r],n),-1===n)return;i.push(n++)}return i},a=function(){return 2},c=function(e){var t,n;return e?(t=e.toLowerCase().split(""),n=function(n){var r,i;return n&&(r=h(n,t))?(i=e.length/r[1],i/=r[0]/2+1):0}):n=a,{score:n}},$(document).on("focusin:delayed",".js-suggester-field",function(){new e(this,{types:f})})}.call(this),function(){function e(){return"survey-"+document.querySelector(".js-survey").getAttribute("data-survey-slug")}function t(){return parseInt(l(e()))||0}function n(){var n=arguments.length<=0||void 0===arguments[0]?1:arguments[0];d(e(),t()+n)}function r(){return"github.dev"===location.hostname||location.search.match(/show-survey=1/)?!0:t()0||(o=i.find(".js-task-list-field").attr("name").split("[")[0],s=$("",{type:"hidden",name:"task_list_key",value:o}),i.append(s)),n=n?"1":"0",r=$("",{type:"hidden",name:"task_list_checked",value:n}),i.append(r),i.one("ajaxComplete",function(e,t){return r.remove(),200!==t.status||/^\s*e.members.length&&e.members.push(e.total-e.members.length+" more"),r(o,n(e.members))},i=function(e){return function(t){var n,i,s;return s=(null!=(i=t.response)?i.status:void 0)||500,n=function(){switch(s){case 404:return this.getAttribute("data-permission-text");default:return this.getAttribute("data-error-text")}}.call(e),r(o,n)}}(this),a.then(t,i)},r=function(e,t){return e.attr("aria-label",t),e.addClass("tooltipped tooltipped-s tooltipped-multiline")},n=function(e){var t;return 0===e.length?"":1===e.length?e[0]:2===e.length?e.join(" and "):([].splice.apply(e,[-1,9e9].concat(t="and "+e.slice(-1))),e.join(", "))},$.observe(".js-team-mention",function(){$(this).on("mouseenter",t)})}.call(this),function(){var e,t;t=function(e,t,n){var r,i;return r=e.value.substring(0,e.selectionEnd),i=e.value.substring(e.selectionEnd),r=r.replace(t,n),i=i.replace(t,n),e.value=r+i,e.selectionStart=r.length,e.selectionEnd=r.length},e=function(e,t){var n,r,i,s;return i=e.selectionEnd,n=e.value.substring(0,i),s=e.value.substring(i),r=""===e.value||n.match(/\n$/)?"":"\n",e.value=n+r+t+s,e.selectionStart=i+t.length,e.selectionEnd=i+t.length},$.fn.replaceText=function(e,n){var r,i,s;for(i=0,s=this.length;s>i;i++)r=this[i],t(r,e,n);return this},$.fn.insertText=function(t){var n,r,i;for(r=0,i=this.length;i>r;r++)n=this[r],e(n,t);return this}}.call(this),function(){$(document).on("ajaxBeforeSend",function(e,t,n){var r;n.crossDomain||(r=$(".js-timeline-marker"),r.length&&t.setRequestHeader("X-Timeline-Last-Modified",r.attr("data-last-modified")))})}.call(this),function(){var e,t,n,r,i=require("github/dimensions"),s=i.overflowOffset;$(document).on("click",".js-timeline-progressive-disclosure-button",function(){var e;return e=this.closest(".js-timeline-progressive-disclosure-container"),e.src=this.getAttribute("data-url"),!0}),t=null,$.observe(".js-timeline-progressive-disclosure-container",function(){return{add:function(e){return e.addEventListener("loadstart",function(){return this.classList.add("is-loading"),!0}),e.addEventListener("loadend",function(){return this.classList.remove("is-loading"),!0}),e.addEventListener("load",function(){var n,r,i,o,a,c;return e===t&&(t=null,i=window.location.hash.slice(1),(r=document.getElementById(i))&&(null!=(o=r.closest(".js-details-container"))&&o.classList.add("open"),a=s(r),c=a.top,n=a.bottom,(0>c||0>n)&&r.scrollIntoView())),!0}),e.addEventListener("error",function(){return this.src="",!0})}}}),e=/^(?:commits-pushed-([0-9a-f]{7})|discussion-diff-(\d+)(?:[LR]-?\d+)?|discussion_r(\d+)|event-(\d+)|issuecomment-(\d+)|ref-issue-(\d+)|ref-pullrequest-(\d+))$/,r=function(t){var n,r,i,s,o,a,c,u,l,d,h,f;return c=e.exec(t),null!=c?(n=c[0],r=c[1],s=c[2],i=c[3],o=c[4],h=c[5],f=c[6],a=null!=(u=null!=(l=null!=(d=null!=s?s:i)?d:o)?l:h)?u:f,null!=a?{timeline_item_id:a}:null!=r?{commit_sha:r}:void 0):void 0},(n=function(){var e,n,i,s,o;return n=window.location.hash.slice(1),!document.getElementById(n)&&(e=document.querySelector(".js-timeline-progressive-disclosure-container"),e&&(i=r(n)))?(o=e.getAttribute("data-fragment-url"),s=o.indexOf("?")?"&":"?",e.src=o+s+$.param(i),t=e):void 0})()}.call(this),function(e){var t=function(){"use strict";var e="s",n=function(e){var t=-e.getTimezoneOffset();return null!==t?t:0},r=function(e,t,n){var r=new Date;return void 0!==e&&r.setFullYear(e),r.setMonth(t),r.setDate(n),r},i=function(e){return n(r(e,0,2))},s=function(e){return n(r(e,5,2))},o=function(e){var t=e.getMonth()>7,r=t?s(e.getFullYear()):i(e.getFullYear()),o=n(e),a=0>r,c=r-o;return a||t?0!==c:0>c},a=function(){var t=i(),n=s(),r=t-n;return 0>r?t+",1":r>0?n+",1,"+e:t+",0"},c=function(){var e=a();return new t.TimeZone(t.olson.timezones[e])},u=function(e){var t=new Date(2010,6,15,1,0,0,0),n={"America/Denver":new Date(2011,2,13,3,0,0,0),"America/Mazatlan":new Date(2011,3,3,3,0,0,0),"America/Chicago":new Date(2011,2,13,3,0,0,0),"America/Mexico_City":new Date(2011,3,3,3,0,0,0),"America/Asuncion":new Date(2012,9,7,3,0,0,0),"America/Santiago":new Date(2012,9,3,3,0,0,0),"America/Campo_Grande":new Date(2012,9,21,5,0,0,0),"America/Montevideo":new Date(2011,9,2,3,0,0,0),"America/Sao_Paulo":new Date(2011,9,16,5,0,0,0),"America/Los_Angeles":new Date(2011,2,13,8,0,0,0),"America/Santa_Isabel":new Date(2011,3,5,8,0,0,0),"America/Havana":new Date(2012,2,10,2,0,0,0),"America/New_York":new Date(2012,2,10,7,0,0,0),"Europe/Helsinki":new Date(2013,2,31,5,0,0,0),"Pacific/Auckland":new Date(2011,8,26,7,0,0,0),"America/Halifax":new Date(2011,2,13,6,0,0,0),"America/Goose_Bay":new Date(2011,2,13,2,1,0,0),"America/Miquelon":new Date(2011,2,13,5,0,0,0),"America/Godthab":new Date(2011,2,27,1,0,0,0),"Europe/Moscow":t,"Asia/Amman":new Date(2013,2,29,1,0,0,0),"Asia/Beirut":new Date(2013,2,31,2,0,0,0),"Asia/Damascus":new Date(2013,3,6,2,0,0,0),"Asia/Jerusalem":new Date(2013,2,29,5,0,0,0),"Asia/Yekaterinburg":t,"Asia/Omsk":t,"Asia/Krasnoyarsk":t,"Asia/Irkutsk":t,"Asia/Yakutsk":t,"Asia/Vladivostok":t,"Asia/Baku":new Date(2013,2,31,4,0,0),"Asia/Yerevan":new Date(2013,2,31,3,0,0),"Asia/Kamchatka":t,"Asia/Gaza":new Date(2010,2,27,4,0,0),"Africa/Cairo":new Date(2010,4,1,3,0,0),"Europe/Minsk":t,"Pacific/Apia":new Date(2010,10,1,1,0,0,0),"Pacific/Fiji":new Date(2010,11,1,0,0,0),"Australia/Perth":new Date(2008,10,1,1,0,0,0)};return n[e]};return{determine:c,date_is_dst:o,dst_start_for:u}}();t.TimeZone=function(e){"use strict";var n={"America/Denver":["America/Denver","America/Mazatlan"],"America/Chicago":["America/Chicago","America/Mexico_City"],"America/Santiago":["America/Santiago","America/Asuncion","America/Campo_Grande"],"America/Montevideo":["America/Montevideo","America/Sao_Paulo"],"Asia/Beirut":["Asia/Amman","Asia/Jerusalem","Asia/Beirut","Europe/Helsinki","Asia/Damascus"],"Pacific/Auckland":["Pacific/Auckland","Pacific/Fiji"],"America/Los_Angeles":["America/Los_Angeles","America/Santa_Isabel"],"America/New_York":["America/Havana","America/New_York"],"America/Halifax":["America/Goose_Bay","America/Halifax"],"America/Godthab":["America/Miquelon","America/Godthab"],"Asia/Dubai":["Europe/Moscow"],"Asia/Dhaka":["Asia/Yekaterinburg"],"Asia/Jakarta":["Asia/Omsk"],"Asia/Shanghai":["Asia/Krasnoyarsk","Australia/Perth"],"Asia/Tokyo":["Asia/Irkutsk"],"Australia/Brisbane":["Asia/Yakutsk"],"Pacific/Noumea":["Asia/Vladivostok"],"Pacific/Tarawa":["Asia/Kamchatka","Pacific/Fiji"],"Pacific/Tongatapu":["Pacific/Apia"],"Asia/Baghdad":["Europe/Minsk"],"Asia/Baku":["Asia/Yerevan","Asia/Baku"],"Africa/Johannesburg":["Asia/Gaza","Africa/Cairo"]},r=e,i=function(){for(var e=n[r],i=e.length,s=0,o=e[0];i>s;s+=1)if(o=e[s],t.date_is_dst(t.dst_start_for(o)))return void(r=o)},s=function(){return"undefined"!=typeof n[r]};return s()&&i(),{name:function(){return r}}},t.olson={},t.olson.timezones={"-720,0":"Pacific/Majuro","-660,0":"Pacific/Pago_Pago","-600,1":"America/Adak","-600,0":"Pacific/Honolulu","-570,0":"Pacific/Marquesas","-540,0":"Pacific/Gambier","-540,1":"America/Anchorage","-480,1":"America/Los_Angeles","-480,0":"Pacific/Pitcairn","-420,0":"America/Phoenix","-420,1":"America/Denver","-360,0":"America/Guatemala","-360,1":"America/Chicago","-360,1,s":"Pacific/Easter","-300,0":"America/Bogota","-300,1":"America/New_York","-270,0":"America/Caracas","-240,1":"America/Halifax","-240,0":"America/Santo_Domingo","-240,1,s":"America/Santiago","-210,1":"America/St_Johns","-180,1":"America/Godthab","-180,0":"America/Argentina/Buenos_Aires","-180,1,s":"America/Montevideo","-120,0":"America/Noronha","-120,1":"America/Noronha","-60,1":"Atlantic/Azores","-60,0":"Atlantic/Cape_Verde","0,0":"UTC","0,1":"Europe/London","60,1":"Europe/Berlin","60,0":"Africa/Lagos","60,1,s":"Africa/Windhoek","120,1":"Asia/Beirut","120,0":"Africa/Johannesburg","180,0":"Asia/Baghdad","180,1":"Europe/Moscow","210,1":"Asia/Tehran","240,0":"Asia/Dubai","240,1":"Asia/Baku","270,0":"Asia/Kabul","300,1":"Asia/Yekaterinburg","300,0":"Asia/Karachi","330,0":"Asia/Kolkata","345,0":"Asia/Kathmandu","360,0":"Asia/Dhaka","360,1":"Asia/Omsk","390,0":"Asia/Rangoon","420,1":"Asia/Krasnoyarsk","420,0":"Asia/Jakarta","480,0":"Asia/Shanghai","480,1":"Asia/Irkutsk","525,0":"Australia/Eucla","525,1,s":"Australia/Eucla","540,1":"Asia/Yakutsk","540,0":"Asia/Tokyo","570,0":"Australia/Darwin","570,1,s":"Australia/Adelaide","600,0":"Australia/Brisbane","600,1":"Asia/Vladivostok","600,1,s":"Australia/Sydney","630,1,s":"Australia/Lord_Howe","660,1":"Asia/Kamchatka","660,0":"Pacific/Noumea","690,0":"Pacific/Norfolk","720,1,s":"Pacific/Auckland","720,0":"Pacific/Tarawa","765,1,s":"Pacific/Chatham","780,0":"Pacific/Tongatapu","780,1,s":"Pacific/Apia","840,0":"Pacific/Kiritimati"},"undefined"!=typeof exports?exports.jstz=t:e.jstz=t}(this),function(){var e,t;t=jstz.determine().name(),"https:"===location.protocol&&(e="secure"),document.cookie="tz="+encodeURIComponent(t)+"; path=/; "+e}.call(this),function(){var e,t,n;n=require("github/stats")["default"],t=function(){if(!window.performance.timing)try{return sessionStorage.setItem("navigationStart",Date.now())}catch(e){}},e=function(){return setTimeout(function(){var e,t,r,i,s,o,a,c,u,l,d,h;if(d={},d.crossBrowserLoadEvent=Date.now(),window.performance.timing){o=window.performance.timing;for(r in o)h=o[r],"number"==typeof h&&(d[r]=h);(e=null!=(a=window.chrome)&&"function"==typeof a.loadTimes&&null!=(c=a.loadTimes())?c.firstPaintTime:void 0)&&(d.chromeFirstPaintTime=Math.round(1e3*e))}else s=function(){try{return sessionStorage.getItem("navigationStart")}catch(e){}}(),s&&(d.simulatedNavigationStart=parseInt(s,10));for(l=function(){var e,t,n,r;for(n=window.performance.getEntriesByType("resource"),r=[],e=0,t=n.length;t>e;e++)u=n[e],r.push($.extend({},u));return r}(),t=0,i=l.length;i>t;t++)u=l[t],delete u.toJSON;return Object.keys(d).length>1||l.length?n({timing:d,resources:l}):void 0},0)},$(window).on("pagehide",t),$(window).on("load",e)}.call(this),function(){$(document).on("click",".js-toggler-container .js-toggler-target",function(e){return 1===e.which?($(e.target).trigger("toggler:toggle"),0===$(this).parent(".js-toggler-form").length?!1:void 0):void 0}),$(document).on("ajaxSend",".js-toggler-container",function(e){return this.classList.remove("success","error"),this.classList.add("loading")}),$(document).on("ajaxComplete",".js-toggler-container",function(e){return this.classList.remove("loading")}),$(document).on("ajaxSuccess",".js-toggler-container",function(e){return this.classList.add("success")}),$(document).on("ajaxError",".js-toggler-container",function(e){return this.classList.add("error")}),$(document).on("toggler:toggle",".js-toggler-container",function(e){return this.classList.toggle("on")})}.call(this),function(){var e,t,n;n=0,t=function(e){var t;if(document.hasFocus()&&(t=document.querySelector(".js-timeline-marker-form")))return $(t).submit()},$.inViewport(".js-unread-item",{"in":function(){e(this)}}),$.observe(".js-unread-item",{add:function(){return n++},remove:function(){return n--,0===n?t(this):void 0}}),e=function(e){return e.classList.remove("js-unread-item","unread-item")},$(document).on("socket:message",".js-discussion",function(t){var n,r,i,s;if(this===t.target)for(s=document.querySelectorAll(".js-unread-item"),r=0,i=s.length;i>r;r++)n=s[r],e(n)})}.call(this),function(){function e(){var e;return e=n?"("+n+") ":"",document.title.match(t)?document.title=document.title.replace(t,e):document.title=""+e+document.title}var t,n;n=0,t=/^\(\d+\)\s+/,$.observe(".js-unread-item",{add:function(){return n++,e()},remove:function(){return n--,e()}})}.call(this),function(){var e,t,n,r,i=require("github/has-interactions"),s=i.hasInteractions;e=new WeakMap,$.fn.updateContent=function(n){var r,i;return r=this[0],null!=(i=e.get(r))&&i.abort(),t(r,n)},$(document).on("socket:message",".js-updatable-content",function(t,i,s){var o;this===t.target&&(e.get(this)||(o=new XMLHttpRequest,o.open("GET",this.getAttribute("data-url")),o.setRequestHeader("Accept","text/html"),o.setRequestHeader("X-Requested-With","XMLHttpRequest"),e.set(this,o),r(o).then(function(t){return function(r){return e["delete"](t),n(t,r)}}(this))["catch"](function(t){return function(n){e["delete"](t),"XMLHttpRequest abort"!==n.message&&console.warn("Failed to update content",t,n)}}(this))))}),r=function(e){return new Promise(function(t,n){return e.onload=function(){return 200===e.status?t(e.responseText):n(new Error("XMLHttpRequest "+e.statusText))},e.onerror=n,e.send()})},t=function(e,t){return $.preserveInteractivePosition(function(){var n;return n=$($.parseHTML($.trim(t))),$(e).replaceWith(n),n})},n=function(e,n){if(s(e))throw new Error("element had interactions");return t(e,n)}}.call(this),function(){var e,t;e=require("delegated-events"),t=require("github/fetch").fetchText,e.on("upload:setup",".js-upload-avatar-image",function(e){var t,n,r,i;return i=e.detail.policyRequest,t=this.getAttribute("data-alambic-organization"),r=this.getAttribute("data-alambic-owner-type"),n=this.getAttribute("data-alambic-owner-id"),t&&i.body.append("organization_id",t),r&&i.body.append("owner_type",r),n?i.body.append("owner_id",n):void 0}),e.on("upload:complete",".js-upload-avatar-image",function(e){var n,r;return n=e.detail.result,r="/settings/avatars/"+n.id,$.facebox(function(){return t(r).then($.facebox)})})}.call(this),function(){var e,t,n,r,i,s,o;r=require("github/image-dimensions")["default"],n=require("delegated-events"),s=function(e){return e.toLowerCase().replace(/[^a-z0-9\-_]+/gi,".").replace(/\.{2,}/g,".").replace(/^\.|\.$/gi,"")},o=function(e){var t;return t=i(e)?"!":"",t+("[Uploading "+e.name+"\u2026]()")},t=function(e){return s(e).replace(/\.[^.]+$/,"").replace(/\./g," ")},i=function(e){var t;return"image/gif"===(t=e.type)||"image/png"===t||"image/jpg"===t||"image/jpeg"===t},e=144,n.on("upload:setup",".js-upload-markdown-image",function(e){var t;return t=this.querySelector(".js-comment-field"),$(t).insertText(o(e.detail.file)+"\n"),$(this).trigger("validation:change",!1)}),n.on("upload:complete",".js-upload-markdown-image",function(n){var s,a,c,u,l;return l=n.detail,s=this,a=s.querySelector(".js-comment-field"),c=o(l.file),u=function(n){var r,o,u,d;return o=i(l.file)?(r=t(l.policy.asset.name),u=l.policy.asset.href,(null!=n?n.ppi:void 0)===e?(d=Math.round(n.width/2),''+r+''):"!["+r+"]("+u+")"):"["+l.file.name+"]("+l.policy.asset.href+")",$(a).replaceText(c,o),$(s).trigger("validation:field:change")},r(l.file).then(u,function(e){return u(),setImmediate(function(){throw e})})}),n.on("upload:error",".js-upload-markdown-image",function(e){var t,n;return t=this.querySelector(".js-comment-field"),n=o(e.detail.file),$(t).replaceText(n,""),$(this).trigger("validation:field:change")}),n.on("upload:invalid",".js-upload-markdown-image",function(e){var t,n;return t=this.querySelector(".js-comment-field"),n=o(e.detail.file),$(t).replaceText(n,""),$(this).trigger("validation:field:change")})}.call(this),function(){var e;e=require("delegated-events"),e.on("upload:complete",".js-upload-oauth-logo",function(e){var t;return t=e.detail,this.querySelector(".js-image-field").src=t.policy.asset.href,this.classList.add("has-uploaded-logo")}),e.on("upload:setup",".js-upload-oauth-logo",function(e){var t,n;return n=e.detail.policyRequest,t=this.getAttribute("data-oauth-application-id"),t?n.body.append("application_id",t):void 0})}.call(this),function(){var e,t,n,r,i,s,o,a,c,u,l,d,h,f,m,p,g,v,b,y,j,w,x,k,C,S,L,q,A,T,_,E,D,P,I,M,R,H,N,O,F,z,B,U,W,Y=[].indexOf||function(e){for(var t=0,n=this.length;n>t;t++)if(t in this&&this[t]===e)return t;return-1};j=require("github/inspect")["default"],m=require("delegated-events").fire,h=require("github/fetch").fetchJSON,H=function(e){var t;return(null!=(t=e.closest("form").elements.authenticity_token)?t.value:void 0)||function(){throw new Error(j(e)+" is missing authenticity_token")}()},t=function(){function e(){this.uploads=[],this.busy=!1}return e.prototype.upload=function(e,t){var n;return n=function(){},this.uploads.push({file:e,to:t.to,sameOrigin:t.sameOrigin,csrf:t.csrf,form:t.form||{},header:t.header||{},start:t.start||n,progress:t.progress||n,complete:t.complete||n,error:t.error||n}),this.process()},e.prototype.process=function(){var e,t,n,r,i,s,o;if(!this.busy&&0!==this.uploads.length){i=this.uploads.shift(),this.busy=!0,o=new XMLHttpRequest,o.open("POST",i.to,!0),n=i.header;for(t in n)s=n[t],o.setRequestHeader(t,s);o.onloadstart=function(){return i.start()},o.onload=function(e){return function(){return 204===o.status?i.complete({}):201===o.status?i.complete(JSON.parse(o.responseText)):i.error({status:o.status,body:o.responseText}),e.busy=!1,e.process()}}(this),o.onerror=function(){return i.error({status:0,body:""})},o.upload.onprogress=function(e){var t;return e.lengthComputable?(t=Math.round(e.loaded/e.total*100),i.progress(t)):void 0},e=new FormData,i.sameOrigin&&e.append("authenticity_token",i.csrf),r=i.form;for(t in r)s=r[t],e.append(t,s);return e.append("file",i.file),o.send(e)}},e}(),I=["is-default","is-uploading","is-bad-file","is-duplicate-filename","is-too-big","is-too-many","is-failed","is-bad-dimensions","is-empty","is-bad-permissions","is-repository-required"],R=function(e,t){var n;return(n=e.classList).remove.apply(n,I),e.classList.add(t)},U=new t,e=function(){function e(e){var t;this.files=function(){var n,r,i;for(i=[],n=0,r=e.length;r>n;n++)t=e[n],i.push(t);return i}(),this.percentages=function(){var n,r,i;for(i=[],n=0,r=e.length;r>n;n++)t=e[n],i.push(0);return i}(),this.size=this.files.length,this.total=this.files.reduce(function(e,t){return e+t.size},0),this.uploaded=0}return e.prototype.percent=function(){var e,t,n;return e=function(){var e,r,i,s;for(i=this.files,s=[],n=e=0,r=i.length;r>e;n=++e)t=i[n],s.push(t.size*this.percentages[n]/100);return s}.call(this).reduce(function(e,t){return e+t}),Math.round(e/this.total*100)},e.prototype.progress=function(e,t){var n;return n=this.files.indexOf(e),this.percentages[n]=t},e.prototype.completed=function(e){return this.uploaded+=1},e.prototype.isFinished=function(){return this.uploaded===this.files.length},e}(),M=function(e,t){var n,r,i,s,o;for(s=e.files,o=[],r=0,i=s.length;i>r;r++)n=s[r],o.push(function(n){var r,i;return r=c(n,t),i=[],m(t,"upload:setup",{batch:e,file:n,policyRequest:r,preprocess:i})?Promise.all(i).then(function(){return h(r.url,r)}).then(function(r){var i;return i=u(e,n,r,t),U.upload(n,i)})["catch"](function(r){var i;return m(t,"upload:invalid",{batch:e,file:n,error:r}),null!=r.response?r.response.text().then(function(e){var i,s;return s=r.response.status,i=P({status:s,body:e},n),R(t,i)}):(i=P({status:0}),R(t,i))}):void 0}(n));return o},c=function(e,t){var n,r,i;return i=t.getAttribute("data-upload-policy-url"),r=t.getAttribute("data-upload-repository-id"),n=new FormData,n.append("name",e.name),n.append("size",e.size),n.append("content_type",e.type),n.append("authenticity_token",H(t)),r&&n.append("repository_id",r),e._path&&n.append("directory",e._path),{url:i,method:"post",body:n,headers:{}}},P=function(e,t){var n,r,i,s,o,a;if(400===e.status)return"is-bad-file";if(422!==e.status)return"is-failed";if(r=JSON.parse(e.body),null==(null!=r?r.errors:void 0))return"is-failed";for(o=r.errors,i=0,s=o.length;s>i;i++)switch(n=o[i],n.field){case"size":return a=null!=t?t.size:void 0,null!=a&&0===parseInt(a)?"is-empty":"is-too-big";case"file_count":return"is-too-many";case"width":case"height":return"is-bad-dimensions";case"name":return"already_exists"===n.code?"is-duplicate-filename":"is-bad-file";case"content_type":return"is-bad-file";case"uploader_id":return"is-bad-permissions";case"repository_id":return"is-repository-required"}return"is-failed"},u=function(e,t,n,r){var i,s,o,a;return i=n.form,a=r.getAttribute("data-alambic-owner-type"),o=r.getAttribute("data-alambic-owner-id"),a&&(i.owner_type=a),o&&(i.owner_id=o),s={to:n.upload_url,form:i,header:n.header,sameOrigin:n.same_origin,csrf:H(r),start:function(){return R(r,"is-uploading"),m(r,"upload:start",{batch:e,file:t,policy:n})},progress:function(n){return e.progress(t,n),m(r,"upload:progress",{batch:e,file:t,percent:n})},complete:function(s){var o;return e.completed(t),null!=(null!=s?s.href:void 0)&&(n.asset||(n.asset={}),n.asset.href=s.href),(null!=(o=n.asset_upload_url)?o.length:void 0)>0&&(i=new FormData,i.append("authenticity_token",H(r)),h(n.asset_upload_url,{method:"put",body:i})),m(r,"upload:complete",{batch:e,file:t,policy:n,result:s}),R(r,"is-default")},error:function(i){var s;return m(r,"upload:error",{batch:e,file:t,policy:n}),s=P(i),R(r,s)}}},N=function(e){return e.types?Y.call(e.types,"Files")>=0:!1},O=function(e){return e.types?Y.call(e.types,"text/uri-list")>=0:!1},F=function(e){return e.types?Y.call(e.types,"text/plain")>=0:!1},p=function(e){var t,n,r,i;for(r=[],t=0,n=e.length;n>t;t++)i=e[t],Array.isArray(i)?r=r.concat(p(i)):r.push(i);return r},b=function(e){return e.name.startsWith(".")},W=function(e){var t,n,r,i;for(i=[],n=0,r=e.length;r>n;n++)t=e[n],b(t)||i.push(t);return i},z=function(e,t){return t.getFilesAndDirectories?t.getFilesAndDirectories().then(function(e){var n,r;return r=function(){var r,i,s,o;for(s=W(e), +o=[],r=0,i=s.length;i>r;r++)n=s[r],o.push(z(t.path,n));return o}(),Promise.all(r)}):(t._path=e,t)},s=function(e){return z("",e).then(p)},v=function(e){return new Promise(function(t,n){return e.file(t,n)})},g=function(e){return new Promise(function(t,n){return e.createReader().readEntries(t,n)})},B=function(e,t){return t.isDirectory?g(t).then(function(e){var n,r;return r=function(){var r,i,s,o;for(s=W(e),o=[],r=0,i=s.length;i>r;r++)n=s[r],o.push(B(t.fullPath,n));return o}(),Promise.all(r)}):v(t).then(function(t){return t._path=e,t})},x=function(e){var t,n,r,i;if(!e.items)return!1;for(i=e.items,t=0,r=i.length;r>t;t++)if(n=i[t],n.webkitGetAsEntry&&n.webkitGetAsEntry().isDirectory)return!0;return!1},o=function(e){var t,n,r,i;return t=function(){var t,n,i,s;for(i=e.items,s=[],t=0,n=i.length;n>t;t++)r=i[t],s.push(r.webkitGetAsEntry());return s}(),i=function(){var e,r,i,s;for(i=W(t),s=[],e=0,r=i.length;r>e;e++)n=i[e],s.push(B("",n));return s}(),Promise.all(i).then(p)},n=function(t,n){var r;return r=new e(t),M(r,n)},r=function(e,t){var n,r,i,s,o,a,c;if(e){for(n=t.querySelector(".js-comment-field"),o=e.split("\r\n"),a=[],r=0,i=o.length;i>r;r++)s=o[r],c=w(s)?"\n![]("+s+")\n":s,a.push($(n).insertText(c));return a}},i=function(e,t){var n;return n=t.querySelector(".js-comment-field"),$(n).insertText(e)},w=function(e){var t;return t=e.split(".").pop(),"gif"===t||"png"===t||"jpg"===t||"jpeg"===t},l=function(e){return N(e)?"copy":O(e)?"link":F(e)?"copy":"none"},f=function(e){switch(e){case"image/gif":return"image.gif";case"image/png":return"image.png";case"image/jpeg":return"image.jpg"}},L=function(e){return e.preventDefault()},S=function(e){return e.dataTransfer.dropEffect="none",e.preventDefault()},d=null,A=function(e){var t,n;if(!y)return clearTimeout(d),t=function(e){return function(){return e.classList.remove("dragover")}}(this),d=setTimeout(t,200),n=l(e.dataTransfer),e.dataTransfer.dropEffect=n,this.classList.add("dragover"),e.stopPropagation(),e.preventDefault()},T=function(e){return e.dataTransfer.dropEffect="none",this.classList.remove("dragover"),e.stopPropagation(),e.preventDefault()},k=function(e){var t;return(null!=(t=e.target.classList)?t.contains("js-document-dropzone"):void 0)?this.classList.remove("dragover"):void 0},E=function(e){var t,a,c;return this.classList.remove("dragover"),document.body.classList.remove("dragover"),c=e.dataTransfer,c.types?N(c)?(a=this.hasAttribute("data-directory-upload")&&c.getFilesAndDirectories?s(c):this.hasAttribute("data-directory-upload")&&x(c)?o(c):Promise.resolve(W(c.files)),t=this,a.then(function(e){var r,i;return i=n.bind(null,e),r=!m(t,"upload:drop:setup",{upload:i,files:e}),r?void 0:n(e,t)})):O(c)?r(c.getData("text/uri-list"),this):F(c)&&i(c.getData("text/plain"),this):R(this,"is-bad-browser"),e.stopPropagation(),e.preventDefault()},D=function(e){var t,r,i,s,o,a,c;if(null!=(null!=(a=e.clipboardData)?a.items:void 0)){for(c=e.clipboardData.items,i=0,o=c.length;o>i&&(s=c[i],!(r=f(s.type)));i++);if(r)return t=s.getAsFile(),t.name=r,n([t],this),e.preventDefault()}},C=function(e){return e.target.classList.contains("js-manual-file-chooser")?(e.target.files?n(e.target.files,this):R(this,"is-bad-browser"),e.target.value=""):void 0},a=0,y=!1,_=function(){return y=!0},q=function(){return y=!1},$.observe(".js-document-dropzone",{add:function(){return document.body.addEventListener("dragstart",_),document.body.addEventListener("dragend",q),document.body.addEventListener("dragenter",A),document.body.addEventListener("dragover",A),document.body.addEventListener("dragleave",k),this.addEventListener("drop",E)},remove:function(){return document.body.removeEventListener("dragstart",_),document.body.removeEventListener("dragend",q),document.body.removeEventListener("dragenter",A),document.body.removeEventListener("dragover",A),document.body.removeEventListener("dragleave",k),this.removeEventListener("drop",E)}}),$.observe(".js-uploadable-container",{add:function(){return 0===a++&&(document.addEventListener("drop",L),document.addEventListener("dragover",S)),this.addEventListener("dragenter",A),this.addEventListener("dragover",A),this.addEventListener("dragleave",T),this.addEventListener("drop",E),this.addEventListener("paste",D),this.addEventListener("change",C)},remove:function(){return 0===--a&&(document.removeEventListener("drop",L),document.removeEventListener("dragover",S)),this.removeEventListener("dragenter",A),this.removeEventListener("dragover",A),this.removeEventListener("dragleave",T),this.removeEventListener("drop",E),this.removeEventListener("paste",D),this.removeEventListener("change",C)}}),("undefined"==typeof FormData||null===FormData)&&document.documentElement.classList.add("no-dnd-uploads")}.call(this),function(){var e,t,n;t=require("delegated-events"),t.on("click",".js-release-remove-file",function(){var e;return e=this.closest(".js-release-file"),e.classList.add("delete"),e.querySelector("input.destroy").value="true"}),t.on("click",".js-release-undo-remove-file",function(){var e;return e=this.closest(".js-release-file"),e.classList.remove("delete"),e.querySelector("input.destroy").value=""}),n=function(e){return e.closest("form").querySelector("#release_id").value},e=[],t.on("release:saved",".js-release-form",function(){var t,n,r,i,s,o;for(setImmediate(function(){var t,n,r;for(t=0,n=e.length;n>t;t++)(r=e[t])();return e.length=0}),o=0,s=this.querySelectorAll(".js-releases-field .js-release-file"),r=0,i=s.length;i>r;r++)t=s[r],t.classList.contains("delete")?t.remove():t.classList.contains("js-template")||o++;return n=this.querySelector(".js-releases-field"),n.classList.toggle("not-populated",!o),n.classList.toggle("is-populated",o)}),t.on("upload:setup",".js-upload-release-file",function(t){var r,i,s,o,a;return a=t.detail,s=a.policyRequest,o=a.preprocess,i=this,r=function(){var e,t,r;return s.body.append("release_id",n(i)),r=document.querySelectorAll(".js-releases-field .js-release-file.delete .id"),r.length?(t=function(){var t,n,i;for(i=[],t=0,n=r.length;n>t;t++)e=r[t],i.push(e.value);return i}(),s.body.append("deletion_candidates",t.join(","))):void 0},n(i)?r():(o.push(new Promise(function(t){return e.push(t)}).then(r)),1===e.length?$("button.js-save-draft").click():void 0)}),t.on("upload:start",".js-upload-release-file",function(e){var t,n,r,i,s,o,a;if(i=e.detail.policy,this.querySelector(".js-upload-meter").classList.remove("hidden"),o=i.asset.replaced_asset){for(s=document.querySelectorAll(".js-releases-field .js-release-file .id"),a=[],n=0,r=s.length;r>n;n++)t=s[n],Number(t.value)===o?a.push(t.closest(".js-release-file").remove()):a.push(void 0);return a}}),t.on("upload:complete",".js-upload-release-file",function(e){var t,n,r,i,s,o,a,c,u,l;for(l=e.detail,a=l.policy,n=document.querySelector(".js-releases-field"),u=n.querySelector(".js-template").cloneNode(!0),u.classList.remove("template","js-template"),u.querySelector("input.id").value=a.asset.id||l.result.id,o=a.asset.name||a.asset.href.split("/").pop(),c=u.querySelectorAll(".filename"),i=0,s=c.length;s>i;i++)t=c[i],"INPUT"===t.tagName?t.value=o:t.textContent=o;return r="",a.asset.size&&(r="("+(a.asset.size/1048576).toFixed(2)+" MB)"),u.querySelector(".filesize").textContent=r,n.appendChild(u),n.classList.remove("not-populated"),n.classList.add("is-populated"),this.querySelector(".js-upload-meter").classList.add("hidden")}),t.on("upload:progress",".js-upload-release-file",function(e){var t;return t=this.querySelector(".js-upload-meter"),t.style.width=e.detail.percent+"%"})}.call(this),function(){var e,t,n,r,i,s,o,a,c,u,l;t=require("delegated-events"),u=require("github/fetch"),n=u.fetchJSON,r=u.fetchPoll,c=require("github/pjax"),e=[],o=new WeakMap,l=function(e,t){var n,r,i;n=e.closest(".js-upload-manifest-file-container"),r=n.querySelector(".js-upload-progress"),r.classList.add("active"),e.classList.add("is-progress-bar"),i=r.querySelector(".js-upload-meter-text"),i.querySelector(".js-upload-meter-range-start").textContent=t.batch.uploaded+1,i.querySelector(".js-upload-meter-range-end").textContent=t.batch.size},s=function(e){var t,n,r;return e.classList.remove("is-progress-bar"),t=e.closest(".js-upload-manifest-file-container"),n=t.querySelector(".js-upload-progress"),n.classList.remove("active"),r=t.querySelector(".js-upload-meter-text"),r.querySelector(".js-upload-meter-filename").textContent=""},t.on("upload:drop:setup",".js-upload-manifest-file",function(e){var t,n;t=e.detail.files,n=parseInt(this.getAttribute("data-directory-upload-max-files"),10),t.length>n&&(e.preventDefault(),this.classList.add("is-too-many"))}),t.on("upload:drop:setup",".js-upload-manifest-tree-view",function(e){var t,n;return e.preventDefault(),t=e.detail.upload,$(document).one("pjax:success","#js-repo-pjax-container",function(){return t(this.querySelector(".js-uploadable-container"))}),n=this.getAttribute("data-drop-url"),c["default"]({url:n,container:"#js-repo-pjax-container"})}),t.on("upload:setup",".js-upload-manifest-file",function(t){var r,i,s,a,c,u;return u=t.detail,a=u.policyRequest,c=u.preprocess,l(this,t.detail),i=this,r=function(){return a.body.append("upload_manifest_id",o.get(i))},o.get(i)?r():c.push(new Promise(function(t){return e.push(t)}).then(r)),e.length>1||o.get(i)?void 0:(s=this.closest(".js-upload-manifest-file-container").querySelector(".js-upload-manifest-form"),n(s.action,{method:s.method,body:new FormData(s)}).then(function(t){var n,r,s,a;for(n=document.querySelector(".js-manifest-commit-form"),n.elements.manifest_id.value=t.upload_manifest.id,o.set(i,t.upload_manifest.id),r=0,s=e.length;s>r;r++)(a=e[r])();return e.length=0}))}),i=function(e){return e._path?e._path+"/"+e.name:e.name},t.on("upload:start",".js-upload-manifest-file",function(e){var t,n,r,s;return s=e.detail,t=this.closest(".js-upload-manifest-file-container"),n=t.querySelector(".js-upload-progress"),r=n.querySelector(".js-upload-meter-text"),r.querySelector(".js-upload-meter-range-start").textContent=s.batch.uploaded+1,r.querySelector(".js-upload-meter-filename").textContent=i(s.file)}),t.on("upload:complete",".js-upload-manifest-file",function(e){var t,n,r,o,a,c;return c=e.detail,a=document.querySelector(".js-manifest-commit-file-template"),o=a.rows[0].cloneNode(!0),o.querySelector(".name").textContent=i(c.file),o.querySelector(".js-remove-manifest-file-form").elements.file_id.value=c.policy.asset.id,t=document.querySelector(".js-manifest-file-list"),t.classList.remove("hidden"),this.classList.add("is-file-list"),n=document.querySelector(".js-upload-progress"),n.classList.add("is-file-list"),r=t.querySelector(".js-manifest-file-list-root"),r.appendChild(o),c.batch.isFinished()?s(this):void 0}),t.on("upload:progress",".js-upload-manifest-file",function(e){var t,n,r;return r=e.detail,t=this.closest(".js-upload-manifest-file-container"),n=t.querySelector(".js-upload-meter"),n.style.width=r.batch.percent()+"%"}),a=function(){return s(this)},t.on("upload:error",".js-upload-manifest-file",a),t.on("upload:invalid",".js-upload-manifest-file",a),$(document).on("ajaxSuccess",".js-remove-manifest-file-form",function(){var e,t,n,r;r=this.closest(".js-manifest-file-list-root"),this.closest(".js-manifest-file-entry").remove(),r.hasChildNodes()||(t=r.closest(".js-manifest-file-list"),t.classList.add("hidden"),e=document.querySelector(".js-upload-manifest-file"),e.classList.remove("is-file-list"),n=document.querySelector(".js-upload-progress"),n.classList.remove("is-file-list"))}),$.observe(".js-manifest-ready-check",function(){var e;e=this.getAttribute("data-redirect-url"),r(this.getAttribute("data-poll-url")).then(function(){return window.location=e})["catch"](function(){return document.querySelector(".js-manifest-ready-check").classList.add("hidden"),document.querySelector(".js-manifest-ready-check-failed").classList.remove("hidden")})})}.call(this),function(){var e;e=function(){var e,t,n;if(location.hash&&!document.querySelector(":target")){try{e=decodeURIComponent(location.hash.slice(1))}catch(r){return}t="user-content-"+e,n=document.getElementById(t)||document.getElementsByName(t)[0],null!=n&&n.scrollIntoView()}},window.addEventListener("hashchange",e),$(e),document.addEventListener("pjax:success",e)}.call(this),function(){var e,t,n,r,i,s,o;o=document.createElement("input"),"checkValidity"in o?(o.required=!0,o.value="hi",s=o.cloneNode().checkValidity()):s=!1,o=null,n=function(r){var i,o,a,c,u;if(s)return r.checkValidity();if(i=$(r),i.is("[required]")&&!t(r))return!1;if(i.is("[pattern]")&&!e(r))return!1;if(i.is("form"))for(u=r.elements,a=0,c=u.length;c>a;a++)if(o=u[a],!n(o))return!1;return!0},t=function(e){return!!e.value.trim()},e=function(e){var t;return t=new RegExp("^(?:"+$(e).attr("pattern")+")$"),0===e.value.search(t)},r=function(){var e;return e=n(this),e&&$(this).trigger("validation:field:change"),function(){var t;t=n(this),t!==e&&$(this).trigger("validation:field:change"),e=t}},i=["input[pattern]","input[required]","textarea[required]","select[required]"].join(","),$(document).onFocusedInput(i,r),$(document).on("change",i,r),$.observe(i,function(){$(this).trigger("validation:field:change")}),$(document).on("validation:field:change","form",function(){var e;return e=n(this),$(this).trigger("validation:change",[e])}),$(document).on("validation:change","form",function(e,t){return $(this).find("button[data-disable-invalid]").prop("disabled",!t)}),$(document).on("submit",".js-normalize-submit",function(e){return n(this)?void 0:e.preventDefault()})}.call(this),function(){var e;$.observe(".will-transition-once",{add:function(){this.addEventListener("transitionend",e)},remove:function(){this.removeEventListener("transitionend",e)}}),e=function(e){return e.target.classList.remove("will-transition-once")}}.call(this),function(){$(document).on("ajaxSuccess",function(e,t){var n;(n=t.getResponseHeader("X-XHR-Location"))&&(document.location.href=n,e.stopImmediatePropagation())})}.call(this),function(){$(function(){return $(".js-signup-form").one("input","input[type=text]",function(){var e;e=this.form.querySelector(".js-signup-source"),window.ga("send","event","Signup","Attempt",e.value)})})}.call(this),function(){var e;e=require("github/fetch").fetchText,$(document).on("click",".js-new-user-contrib-example",function(t){var n,r,i;return t.preventDefault(),n=document.querySelector(".js-calendar-graph"),n.classList.contains("sample-graph")?void 0:(n.classList.add("sample-graph"),r=function(e){var t;return t=n.querySelector(".js-calendar-graph-svg"),$(t).replaceWith(e)},i=function(){return n.classList.remove("sample-graph")},e(this.getAttribute("href")).then(r,i))})}.call(this),define("github/d3/format-symbol",["exports"],function(e){function t(e,t){if(t&&(e=Math.abs(e)),1e3>e)return e;var n=d3.formatPrefix(e);return""+n.scale(e)+n.symbol}Object.defineProperty(e,"__esModule",{value:!0}),e["default"]=t}),function(){var e,t;t=require("github/d3/format-symbol")["default"],e=require("delegated-events"),e.on("graph:load",".js-graph-code-frequency",function(e){var n,r,i,s,o,a,c,u,l,d,h,f,m,p,g,v,b,y,j,w;return i=e.detail.data,v=$(this).width(),o=500,f=[10,10,20,40],h=f[0],d=f[1],u=f[2],l=f[3],i=i.map(function(e,t){return[new Date(1e3*e[0]),e[1],e[2]]}).sort(function(e,t){return d3.ascending(e[0],t[0])}),n=i.map(function(e){return[e[0],e[1]]}),s=i.map(function(e){return[e[0],e[2]]}),a=d3.max(n,function(e){return e[1]}),c=d3.min(s,function(e){return e[1]}),g=i[0][0],p=i[i.length-1][0],b=d3.time.scale().domain([g,p]).range([0,v-l-d]),j=d3.scale.linear().domain([c,a]).range([o-u-h,0]),y=d3.svg.axis().scale(b).tickFormat(function(e){return g.getFullYear()!==p.getFullYear()?d3.time.format("%m/%y")(e):d3.time.format("%m/%d")(e)}),w=d3.svg.axis().scale(j).orient("left").tickPadding(5).tickSize(v).tickFormat(function(e){return t(e,!0)}),r=d3.svg.area().x(function(e){return b(e[0])}).y0(function(e){return j(e[1])}).y1(function(e){return j(0)}),m=d3.select(this).data(i).append("svg").attr("width",v).attr("height",o).attr("class","viz code-frequency").append("g").attr("transform","translate("+l+","+h+")"),m.append("g").attr("class","x axis").attr("transform","translate(0, "+(o-h-u)+")").call(y),m.append("g").attr("class","y axis").attr("transform","translate("+v+", 0)").call(w),m.selectAll("path.area").data([n,s]).enter().append("path").attr("class",function(e,t){return 0===t?"addition":"deletion"}).attr("d",r)})}.call(this),define("github/locale",["exports"],function(e){Object.defineProperty(e,"__esModule",{value:!0});e.weekdays=["Sunday","Monday","Tuesday","Wednesday","Thursday","Friday","Saturday"],e.months=["January","February","March","April","May","June","July","August","September","October","November","December"]}),function(){var e,t,n,r,i,s,o;t=require("github/d3/format-symbol")["default"],s=require("github/locale"),r=s.months,o=s.weekdays,i=require("github/inflector").pluralize,e=require("delegated-events"),n=require("github/hotkey")["default"],e.on("graph:load",".js-commit-activity-graph",function(e){var s,a,c,u,l,d,h,f,m,p,g,v,b,y,j,w,x,k,C,S,L,q,A;return a=e.detail.data,f=$("#commit-activity-master"),c=$("#commit-activity-detail"),d=260,k=c.width(),C=0,w=null,function(){var e,t,r,i,s,l,h,f,m,p,g,v,b,y,j,x,S,L,q,A;for(h=0,s=l=0,f=a.length;f>l;s=++l)e=a[s],0!==e.total&&(h=s);return C=h,j=[20,30,30,40],b=j[0],g=j[1],v=j[2],p=j[3],r=a[C].days,m=d3.max(a,function(e){return d3.max(e.days)}),S=d3.scale.linear().domain([0,r.length-1]).range([0,k-g-v]),q=d3.scale.linear().domain([0,m]).range([d,0]),A=d3.svg.axis().scale(q).orient("left").ticks(5).tickSize(-k+v+g),$(this).on("hotkey:activate",function(e){var t,r;return t=C,r=n(e.originalEvent),"left"===r||"right"===r?(C>0&&"left"===r&&(t-=1),C=52||e.index<0))return C=e.index,r=a[e.index].days,m=d3.max(r),S.domain([0,r.length-1]),i=d3.selectAll(".bar.mini").attr("class","bar mini"),t=d3.select(i[0][C]).attr("class","bar mini active"),n=d3.transform(t.attr("transform")),u.transition().ease("back-out").duration(300).attr("transform","translate("+(n.translate[0]+8)+", 105)"),x.selectAll(".path").data([r]).transition().duration(500).attr("d",y),x.selectAll("g.dot").data(r).transition().duration(300).attr("transform",function(e,t){return"translate("+S(t)+", "+q(e)+")"}),x.selectAll("text.tip").data(r).text(function(e){return e})}}(),b=[10,30,20,30],v=b[0],p=b[1],g=b[2],m=b[3],d=100,j=a.map(function(e){return e.total}),h=d3.max(j),l=d3.time.format.utc("%m/%d"),S=d3.scale.ordinal().domain(d3.range(j.length)).rangeRoundBands([0,k-p-g],.1),q=d3.scale.linear().domain([0,h]).range([d,0]),A=d3.svg.axis().scale(q).orient("left").ticks(3).tickSize(-k+p+g).tickFormat(t),L=d3.svg.axis().scale(S).ticks(d3.time.weeks).tickFormat(function(e,t){var n;return n=new Date(1e3*a[t].week),l(n)}),y=d3.tip().attr("class","svg-tip").offset([-10,0]).html(function(e,t){var n,s;return n=new Date(1e3*a[t].week),s=r[n.getUTCMonth()].slice(0,3)+" "+n.getUTCDate(),""+e+" "+i(e,"commit")+" the week of "+s}),x=d3.select(f[0]).style("width",k+"px").append("svg").attr("width",k+(p+g)).attr("height",d+v+m).attr("class","viz").append("g").attr("transform","translate("+p+","+v+")").call(y),x.append("g").attr("class","y axis").call(A),s=x.selectAll("g.mini").data(j).enter().append("g").attr("class",function(e,t){return t===C?"bar mini active":"bar mini"}).attr("transform",function(e,t){return"translate("+S(t)+", 0)"}).on("click",function(e,t){return w({node:this,index:t,data:e})}),s.append("rect").attr("width",S.rangeBand()).attr("height",function(e){return d-q(e)}).attr("y",function(e){return q(e)}).on("mouseover",y.show).on("mouseout",y.hide),x.append("g").attr("class","x axis").attr("transform","translate(0,"+d+")").call(L).selectAll(".tick").style("display",function(e,t){return t%3!==0?"none":"block"}),u=x.append("circle").attr("class","focus").attr("r",8).attr("transform","translate("+(S(C)+S.rangeBand()/2)+", "+-d+")"),u.transition().ease("elastic-in").duration(1e3).attr("r",2).attr("transform","translate("+(S(C)+S.rangeBand()/2)+", "+(d+5)+")")})}.call(this),function(){var e,t,n,r,i,s,o,a,c,u,l;n=require("github/d3/format-symbol")["default"],a=require("github/pjax"),t=require("github/number-helpers").formatNumber,i=require("github/locale").months,c=require("github/inflector").pluralize,u=require("github/history").pushState,e=require("delegated-events"),o=function(){var e,t,n,r,i,s,o,a;for(i={},s=document.location.search.substr(1).split("&"),e=0,n=s.length;n>e;e++)r=s[e],o=r.split("="),t=o[0],a=o[1],i[t]=a;return i},r=function(e){return e=new Date(e),i[e.getUTCMonth()].slice(0,3)+" "+e.getUTCDate()+", "+e.getUTCFullYear()},l=function(e,t){var n,i;return i=r(e),n=r(t),$(".js-date-range").html(i+" – "+n)},s=function(e){var t,n;return t=e[0].weeks[0].date,n=new Date(t.getTime()-6048e5),e.forEach(function(e){return e.weeks.unshift({a:0,c:0,d:0,date:n,w:n/1e3})})},e.on("graph:load","#contributors",function(r){var i,a,d,h,f,m,p,g,v,b,y,j,w,x,k,C,S,L,q,A;return f=r.detail.data,i=$(this),d=[],b=o(),A=null,q=null,null!=b.from&&(C=new Date(b.from)),null!=b.to&&(m=new Date(b.to)),h=(null!=b?b.type:void 0)||"c",g=d3.time.format.utc("%Y-%m-%d"),y=function(e){return new Date(1e3*~~e)},i[0].addEventListener("range.selection.end",function(e){var t;return t=e.detail.range,C=t[0],m=t[1],g(C)===g(m)&&(C=A,m=q),L(),l(C,m),x()}),w=function(e){var t,n;return 1===e[0].weeks.length&&s(e),n=a(e),A=y(n[0].key),q=y(~~n[n.length-1].key+518400),t=new Date,q>t&&(q=new Date(Date.UTC(t.getFullYear(),t.getMonth(),t.getDate()))),null==C&&(C=A),null==m&&(m=q),l(C,m),k(n,A,q),x(e,A,q),$(".js-contribution-container").on("change","input[type=radio]",v)},j=function(e){var t,n,r,i,s,o,a;for(n=0,i=e.length;i>n;n++)for(t=e[n],o=t.weeks,r=0,s=o.length;s>r;r++)a=o[r],a.date=new Date(1e3*a.w);return e},p=function(e,t){return e.map(function(e){var n;return n=$.extend(!0,{},e),n.weeks=n.weeks.filter(function(e){return e.date>=t[0]&&e.date<=t[1]}),n})},a=function(e){var t,n,r,i,s,o,a,c,u;for(c={},n=0,i=e.length;i>n;n++)for(t=e[n],a=t.weeks,r=0,s=a.length;s>r;r++)u=a[r],null==c[o=u.w]&&(c[o]={c:0,a:0,d:0}),c[u.w].c+=u.c,c[u.w].a+=u.a,c[u.w].d+=u.d;return d3.entries(c)},S=function(e){return e=p(e,[C,m]),e.forEach(function(e){var t,n,r,i,s,o,a;for(n=0,t=0,r=0,o=e.weeks,i=0,s=o.length;s>i;i++)a=o[i],n+=a.c,t+=a.a,r+=a.d;return e.c=n,e.a=t,e.d=r}),e.sort(function(e,t){return d3.descending(e[h],t[h])})},k=function(t,r,s){var o,a,c,u,l,d,f,p,v,b,j,$,w,x,k,S,L,q;return v=[20,50,20,30],p=v[0],d=v[1],f=v[2],l=v[3],x=i.width(),c=125,u=d3.max(t,function(e){return e.value[h]}),k=d3.time.scale().domain([r,s]).range([0,x-d-f]),L=d3.scale.linear().domain([0,u]).range([c,0]),q=d3.svg.axis().scale(L).orient("left").ticks(4).tickSize(-x+d+f).tickPadding(10).tickFormat(n),S=d3.svg.axis().scale(k),t.length<5&&S.ticks(t.length),o=d3.svg.area().interpolate("basis").x(function(e){return k(y(e.key))}).y0(function(e){return c}).y1(function(e){return L(e.value[h])}),d3.select("#contributors-master svg").remove(),w=d3.select("#contributors-master").data([t]).append("svg").attr("height",c+p+l).attr("width",x).attr("class","viz").append("g").attr("transform","translate("+d+","+p+")"),w.append("g").attr("class","x axis").attr("transform","translate(0, "+c+")").call(S),w.append("g").attr("class","y axis").call(q),w.append("path").attr("class","area").attr("d",o),$=function(){var t;return w.classed("selecting",!0),t=d3.event.target.extent(),e.fire(i[0],"range.selection.start",{data:arguments[0],range:t})},b=function(){var t;return t=d3.event.target.extent(),e.fire(i[0],"range.selection.selected",{data:arguments[0],range:t})},j=function(){var t;return w.classed("selecting",!d3.event.target.empty()),t=d3.event.target.extent(),e.fire(i[0],"range.selection.end",{data:arguments[0],range:t})},a=d3.svg.brush().x(k).on("brushstart",$).on("brush",b).on("brushend",j),(g(C)!==g(r)||g(m)!==g(s))&&a.extent([C,m]),w.append("g").attr("class","selection").call(a).selectAll("rect").attr("height",c)},x=function(){var e,r,s,o,a,u,l,p,g,v,b,y,j,w,x,k,L,q,A,T,_,E;return y=[10,10,10,20],v=y[0],p=y[1],g=y[2],l=y[3],L=parseInt(i.attr("data-graph-width")),s=100,$("#contributors ol").remove(),f=S(d),w=document.createElement("ol"),k=d3.select(w).attr("class","contrib-data capped-cards clearfix"),a=d3.max(f,function(e){return d3.max(e.weeks,function(e){return e[h]})}),q=d3.time.scale().domain([C,m]).range([0,L]),T=d3.scale.linear().domain([0,a]).range([s-l-v,0]),r=d3.svg.area().interpolate("basis").x(function(e){return q(e.date)}).y0(function(e){return s-l-v}).y1(function(e){return T(e[h])}),_=d3.svg.axis().scale(T).orient("left").ticks(2).tickSize(-L).tickPadding(10).tickFormat(n),A=d3.svg.axis().scale(q),f[0].weeks.length<5&&A.ticks(f[0].weeks.length).tickFormat(d3.time.format("%x")),$("li.capped-card").remove(),b=k.selectAll("li.capped-card").data(f).enter().append("li").attr("class","capped-card").style("display",function(e){return e[h]<1?"none":"block"}),o=b.append("h3"),o.append("img").attr("src",function(e){return e.author.avatar}).attr("class","avatar").attr("alt",""),o.append("span").attr("class","rank").text(function(e,t){return"#"+(t+1)}),o.append("a").attr("class","aname").attr("href",function(e){return"/"+e.author.login}).text(function(e){return e.author.login}),e=o.append("span").attr("class","ameta"),j=$(".graphs").attr("data-repo-url"),e.append("span").attr("class","cmeta").html(function(e){var n,r,i,s,o,a;return n=j+"/commits?author="+e.author.login,a=t(e.c)+" "+c(e.c,"commit"),o=$("",{href:n,"class":"cmt",text:a}),i=$("",{"class":"a",text:t(e.a)+" ++"}),s=$("",{"class":"d",text:t(e.d)+" --"}),r=" / ",$("
        ").append([o,r,i,r,s]).html()}),x=b.append("svg").attr("width",L+(p+g)).attr("height",s+v+l).attr("class","capped-card-content").append("g").attr("transform","translate("+p+","+v+")"),u=A.ticks()[0],x.append("g").attr("class","x axis").classed("dense",u>=10).attr("transform","translate(0, "+(s-v-l)+")").call(A).selectAll(".tick text").style("display",function(e,t){return t%2!==0?"none":"block"}),x.select(".x.dense text").attr("dx",7),E=x.append("g").attr("class","y axis").call(_).selectAll(".y.axis g text").attr("dx",L/2).style("display",function(e,t){return 0===t?"none":"block"}).classed("midlabel",!0),x.append("path").attr("d",function(e){return r(e.weeks)}),document.querySelector("#contributors").appendChild(w)},L=function(){var e,t;return e=document.location,h=$("input[name=ctype]:checked").prop("value").toLowerCase(),t=e.pathname+"?from="+g(C)+"&to="+g(m)+"&type="+h,u(null,null,t)},v=function(e){return h!==$(this).val()?(L(),w(d)):void 0},d=j(f),w(f)})}.call(this),function(){var e,t,n,r,i,s,o,a,c;t=require("github/d3/format-symbol")["default"],e=require("delegated-events"),i=function(e){var t;return(t=d3.format(","))(e)},r={top:20,right:40,bottom:30,left:40},c=980-r.left-r.right,n=150-r.top-r.bottom,a=function(e,t){return 0>e?t.classList.add("is-decrease"):e>0&&t.classList.add("is-increase"),t.querySelector(".js-change-num").textContent=i(Math.abs(e))},s=function(e,t){return 0>e?(t.classList.add("is-decrease"),t.querySelector(".js-change-num").textContent=i(Math.abs(e))+"% decrease"):e>0?(t.classList.add("is-increase"),t.querySelector(".js-change-num").textContent=i(Math.abs(e))+"% increase"):0===e?t.querySelector(".js-change-num").textContent=i(Math.abs(e))+"% increase":void 0},o=function(e){var o,u,l,d,h,f,m,p,g,v,b,y,j,$,w,x,k,C,S,L,q,A,T,_,E,D,P,I,M;if(f=e.detail.data,f&&null==f.error){for(h=f.counts,d=f.summary.columns,L=new Date(1e3*f.summary.starting),p=new Date(1e3*f.summary.ending),k=f.summary.model,C=f.summary.period,x=d3.max(d3.merge(d3.values(h)),function(e){return e.count}),w=d3.time.format("%A, %B %-d, %Y"),g=d3.time.format("%-I%p"),u=d3.bisector(function(e){return e.date}).left,v=0,y=d.length;y>v;v++)l=d[v],document.querySelector(".js-"+k+"-"+l+" .js-total").textContent=i(f.summary.totals[l]),a(f.summary.total_changes[l],document.querySelector(".js-"+k+"-"+l+" .js-total-change")),s(f.summary.percent_changes[l],document.querySelector(".js-"+k+"-"+l+" .js-percentage-change"));if(0===d3.values(f.summary.totals).filter(function(e){return 0!==e}).length)return this.closest(".js-dashboards-overview-card").classList.add("is-no-activity");for(T=d3.tip().attr("class","svg-tip total-unique comparison").offset([-10,0]).html(function(e){var t,n,r,s,o,a;for(a="",t=function(){switch(C){case"year":return"Week of "+w(e.date);case"week":return w(e.date)+" starting at "+g(e.date);default:return w(e.date)}}(),o=270/f.summary.columns.length,s=f.summary.columns,n=0,r=s.length;r>n;n++)l=s[n],a+="
      3. "+i(e[l])+" "+l.split("_at")[0]+"
        4. ";return""+t+"
          "+a+"
        "}),S=function(){var e,t,n,r,i,s,o,a,c,f;for(c={},f=E.invert(d3.mouse(this)[0]),i=d[0],s=u(h[i],f,1),t=h[i][s-1],n=h[i][s],e=n&&f-t.date>n.date-f?s:s-1,c.date=h[i][e].date,o=0,a=d.length;a>o;o++)l=d[o],c[l]=h[l][e].count;return r=_.selectAll("g.dots circle").filter(function(e){return e.date===c.date}),T.show.call(this,c,r[0][0])},b=0,j=d.length;j>b;b++)l=d[b],h[l].forEach(function(e){return e.date=new Date(1e3*e.bucket)}),h[l]=h[l].filter(function(e){return e.datet;c=++t)o=i[c],s.push(new e(c,o));return s}(),this.users={},d=r.users,a=0,l=d.length;l>a;a++)h=d[a],this.users[h.name]=h;return this.chrome=new i(this,this.ctx,this.width,this.height,this.focus,this.commits,this.userBlocks,this.users),this.graph=new s(this,this.ctx,this.width,this.height,this.focus,this.commits,this.users,this.spaceMap,this.userBlocks,this.nethash),this.mouseDriver=new n(this.container,this.chrome,this.graph),this.keyDriver=new t(this.chrome,this.graph),this.stopLoader(),this.graph.drawBackground(),this.chrome.draw(),this.graph.requestInitialChunk()}},r.prototype.initError=function(){return this.stopLoader(),this.ctx.clearRect(0,0,this.width,this.height),this.startLoader("Graph could not be drawn due to a network problem.")},r}(),e=function(){function e(e,t){this.time=e,this.date=new Date(t),this.requested=null,this.populated=null}return e.prototype.populate=function(e,t,n){return this.user=t,this.author=e.author,this.date=new Date(e.date.replace(" ","T")),this.gravatar=e.gravatar,this.id=e.id,this.login=e.login,this.message=e.message,this.space=e.space,this.time=e.time,this.parents=this.populateParents(e.parents,n),this.requested=!0,this.populated=new Date},e.prototype.populateParents=function(e,t){var n,r,i;return i=function(){var i,s,o;for(o=[],i=0,s=e.length;s>i;i++)n=e[i],r=t[n[1]],r.id=n[0],r.space=n[2],o.push(r);return o}()},e}(),i=function(){function e(e,t,n,r,i,s,o,a){this.network=e,this.ctx=t,this.width=n,this.height=r,this.focus=i,this.commits=s,this.userBlocks=o,this.users=a,this.namesWidth=120,this.months=["Jan","Feb","Mar","Apr","May","Jun","Jul","Aug","Sep","Oct","Nov","Dec"],this.userBgColors=["#fff","#f7f7f7"],this.headerColor="#f7f7f7",this.dividerColor="#ddd",this.headerHeight=40,this.dateRowHeight=30,this.graphTopOffset=10+this.headerHeight+this.dateRowHeight,this.nameLineHeight=24,this.offsetX=this.namesWidth+(this.width-this.namesWidth)/2-this.focus*this.nameLineHeight,this.offsetY=0,this.contentHeight=this.calcContentHeight(),this.graphMidpoint=this.namesWidth+(this.width-this.namesWidth)/2,this.activeUser=null}return e.prototype.moveX=function(e){return this.offsetX+=e,this.offsetX>this.graphMidpoint?this.offsetX=this.graphMidpoint:this.offsetX0||this.contentHeightn;n++)e=i[n],t+=e.count;return t*this.nameLineHeight},e.prototype.hover=function(e,t){var n,r,i,s;for(s=this.userBlocks,r=0,i=s.length;i>r;r++)if(n=s[r],e>0&&ethis.graphTopOffset+this.offsetY+n.start*this.nameLineHeight&&tu&&(u=0),c=u+parseInt(this.width/(this.nameLineHeight-1)),c>this.commits.length&&(c=this.commits.length),e.save(),e.translate(this.offsetX,0),a=null,o=null,s=i=h=u,f=c;f>=h?f>i:i>f;s=f>=h?++i:--i)t=this.commits[s],l=this.months[t.date.getMonth()],l!==a&&(e.font="bold 12px 'Helvetica Neue', Arial, sans-serif",e.fillStyle="#555",d=this.ctx.measureText(l).width,e.fillText(l,s*this.nameLineHeight-d/2,this.headerHeight/2+4),a=l),r=t.date.getDate(),r!==o&&(e.font="12px 'Helvetica Neue', Arial, sans-serif",e.fillStyle="#555",n=this.ctx.measureText(r).width,e.fillText(r,s*this.nameLineHeight-n/2,this.headerHeight+this.dateRowHeight/2+3),o=r,e.fillStyle="#ddd",e.fillRect(s*this.nameLineHeight,this.headerHeight,1,6));return e.restore()},e.prototype.drawUsers=function(e){var t,n,r,i,s,o,a;for(e.fillStyle="#fff",e.fillRect(0,0,this.namesWidth,this.height),e.save(),e.translate(0,this.headerHeight+this.dateRowHeight+this.offsetY),o=this.userBlocks,r=n=0,i=o.length;i>n;r=++n)t=o[r],e.fillStyle=this.userBgColors[r%2],e.fillRect(0,t.start*this.nameLineHeight,this.namesWidth,t.count*this.nameLineHeight),this.activeUser&&this.activeUser.name===t.name&&(e.fillStyle="rgba(0, 0, 0, 0.05)",e.fillRect(0,t.start*this.nameLineHeight,this.namesWidth,t.count*this.nameLineHeight)),s=(t.start+t.count/2)*this.nameLineHeight+3,e.fillStyle="rgba(0, 0, 0, 0.1)",e.fillRect(0,t.start*this.nameLineHeight+t.count*this.nameLineHeight-1,this.namesWidth,1),e.fillStyle="#333",e.font="13px 'Helvetica Neue', Arial, sans-serif",e.textAlign="center",e.fillText(t.name,this.namesWidth/2,s,96);return e.restore(),e.fillStyle=this.headerColor,e.fillRect(0,0,this.namesWidth,this.headerHeight),e.fillStyle="#777",e.font="12px 'Helvetica Neue', Arial, sans-serif",e.fillText("Owners",40,this.headerHeight/2+3),a=10,e.fillStyle=this.dividerColor,e.fillRect(this.namesWidth-1,a,1,this.headerHeight-2*a),e.fillStyle=this.dividerColor,e.fillRect(0,this.headerHeight-1,this.namesWidth,1),e.fillStyle=this.dividerColor,e.fillRect(this.namesWidth-1,this.headerHeight,1,this.height-this.headerHeight)},e}(),s=function(){function e(e,t,n,r,i,s,o,a,c,u){var l,d,h,f,m,p,g,v,b,y,j,$,w,x,k,C,S;for(this.network=e,this.ctx=t,this.width=n,this.height=r,this.focus=i,this.commits=s,this.users=o,this.spaceMap=a,this.userBlocks=c,this.nethash=u,this.namesWidth=120,this.headerHeight=40,this.dateRowHeight=30,this.graphTopOffset=10+this.headerHeight+this.dateRowHeight,this.bgColors=["#fff","#f9f9f9"],this.nameLineHeight=24,this.spaceColors=["#c0392b","#3498db","#2ecc71","#8e44ad","#f1c40f","#e67e22","#34495e","#e74c3c","#2980b9","#1abc9c","#9b59b6","#f39c12","#7f8c8d","#2c3e50","#d35400","#e74c3c","#95a5a6","#bdc3c7","#16a085","#27ae60"],this.offsetX=this.namesWidth+(this.width-this.namesWidth)/2-this.focus*this.nameLineHeight,this.offsetY=0,this.bgCycle=0,this.marginMap={},this.gravatars={},this.activeCommit=null,this.contentHeight=this.calcContentHeight(),this.graphMidpoint=this.namesWidth+(this.width-this.namesWidth)/2,this.showRefs=!0,this.lastHotLoadCenterIndex=null,this.connectionMap={},this.spaceUserMap={},$=this.userBlocks,f=0,g=$.length;g>f;f++)for(l=$[f],m=p=w=l.start,x=l.start+l.count;x>=w?x>p:p>x;m=x>=w?++p:--p)this.spaceUserMap[m]=this.users[l.name];for(this.headsMap={},k=this.userBlocks,y=0,v=k.length;v>y;y++)for(l=k[y],S=this.users[l.name],C=S.heads,j=0,b=C.length;b>j;j++)d=C[j],this.headsMap[d.id]||(this.headsMap[d.id]=[]),h={name:S.name,head:d},this.headsMap[d.id].push(h)}return e.prototype.moveX=function(e){return this.offsetX+=e,this.offsetX>this.graphMidpoint?this.offsetX=this.graphMidpoint:this.offsetX0||this.contentHeightn;n++)e=i[n],t+=e.count;return t*this.nameLineHeight},e.prototype.hover=function(e,t){var n,r,i,s,o,a,c,u;for(u=this.timeWindow(),i=r=s=u.min,o=u.max;o>=s?o>=r:r>=o;i=o>=s?++r:--r)if(n=this.commits[i],a=this.offsetX+n.time*this.nameLineHeight,c=this.offsetY+this.graphTopOffset+n.space*this.nameLineHeight,e>a-5&&a+5>e&&t>c-5&&c+5>t)return n;return null},e.prototype.hotLoadCommits=function(){var e,t,n,r,i,s;return i=200,t=parseInt((-this.offsetX+this.graphMidpoint)/this.nameLineHeight),0>t&&(t=0),t>this.commits.length-1&&(t=this.commits.length-1),this.lastHotLoadCenterIndex&&Math.abs(this.lastHotLoadCenterIndex-t)<10?void 0:(this.lastHotLoadCenterIndex=t,e=this.backSpan(t,i),r=this.frontSpan(t,i),e||r?(s=e?e[0]:r[0],n=r?r[1]:e[1],this.requestChunk(s,n)):void 0)},e.prototype.backSpan=function(e,t){var n,r,i,s,o,a,c,u;for(s=null,r=n=c=e;(0>=c?0>=n:n>=0)&&r>e-t;r=0>=c?++n:--n)if(!this.commits[r].requested){s=r;break}if(null!==s){for(o=null,a=null,r=i=u=s;(0>=u?0>=i:i>=0)&&r>s-t;r=0>=u?++i:--i)if(this.commits[r].requested){o=r;break}return o?a=o+1:(a=s-t,0>a&&(a=0)),[a,s]}return null},e.prototype.frontSpan=function(e,t){var n,r,i,s,o,a,c,u,l,d;for(u=null,r=n=s=e,o=this.commits.length;(o>=s?o>n:n>o)&&e+t>r;r=o>=s?++n:--n)if(!this.commits[r].requested){u=r;break}if(null!==u){for(l=null,d=null,r=i=a=u,c=this.commits.length;(c>=a?c>i:i>c)&&u+t>r;r=c>=a?++i:--i)if(this.commits[r].requested){l=r;break}return d=l?l-1:u+t>=this.commits.length?this.commits.length-1:u+t,[u,d]}return null},e.prototype.chunkUrl=function(){return document.querySelector(".js-network-graph-container").getAttribute("data-network-graph-chunk-url")},e.prototype.requestInitialChunk=function(){var e;if(u)return e=this.chunkUrl()+"?"+$.param({nethash:this.nethash}),o(e).then(function(e){return function(t){return e.importChunk(t),e.draw(),e.network.chrome.draw()}}(this))},e.prototype.requestChunk=function(e,t){var n,r,i,s,a;if(u){for(r=n=i=e,s=t;s>=i?s>=n:n>=s;r=s>=i?++n:--n)this.commits[r].requested=new Date;return a=this.chunkUrl()+"?"+$.param({nethash:this.nethash,start:e,end:t}),o(a).then(function(e){return function(t){return e.importChunk(t),e.draw(),e.network.chrome.draw(),e.lastHotLoadCenterIndex=e.focus}}(this))}},e.prototype.importChunk=function(e){var t,n,r,i,s,o,a,c,u;if(e.commits){for(a=e.commits,c=[],r=0,s=a.length;s>r;r++)t=a[r],u=this.spaceUserMap[t.space],n=this.commits[t.time],n.populate(t,u,this.commits),c.push(function(){var e,t,r,s;for(r=n.parents,s=[],e=0,t=r.length;t>e;e++)o=r[e],s.push(function(){var e,t,r,s;for(s=[],i=e=t=o.time+1,r=n.time;r>=t?r>e:e>r;i=r>=t?++e:--e)this.connectionMap[i]=this.connectionMap[i]||[],s.push(this.connectionMap[i].push(n));return s}.call(this));return s}.call(this));return c}},e.prototype.timeWindow=function(){var e,t;return t=parseInt((this.namesWidth-this.offsetX+this.nameLineHeight)/this.nameLineHeight),0>t&&(t=0),e=t+parseInt((this.width-this.namesWidth)/this.nameLineHeight),e>this.commits.length-1&&(e=this.commits.length-1),{min:t,max:e}},e.prototype.draw=function(){var e,t,n,r,i,s,o,a,c,u,l,d,h,f,m,p,g,v,b,y,j,$,w,x,k,C,S,L,q,A,T,_,E,D,P,I;for(this.drawBackground(),I=this.timeWindow(),g=I.min,p=I.max,this.ctx.save(),this.ctx.translate(this.offsetX,this.offsetY+this.graphTopOffset),r={},x=this.spaceMap,a=o=0,l=x.length;l>o;a=++o)for(e=x[a],D=this.spaceMap.length-a-1,c=u=C=g,S=p;S>=C?S>=u:u>=S;c=S>=C?++u:--u)t=this.commits[c],t.populated&&t.space===D&&(this.drawConnection(t),r[t.id]=!0);for(a=m=L=g,q=p;q>=L?q>=m:m>=q;a=q>=L?++m:--m)if(n=this.connectionMap[a])for(v=0,d=n.length;d>v;v++)t=n[v],r[t.id]||(this.drawConnection(t),r[t.id]=!0);for(A=this.spaceMap,a=y=0,h=A.length;h>y;a=++y)for(e=A[a],D=this.spaceMap.length-a-1,c=$=T=g,_=p;_>=T?_>=$:$>=_;c=_>=T?++$:--$)t=this.commits[c],t.populated&&t.space===D&&(t===this.activeCommit?this.drawActiveCommit(t):this.drawCommit(t));if(this.showRefs)for(c=w=E=g,k=p;k>=E?k>=w:w>=k;c=k>=E?++w:--w)if(t=this.commits[c],t.populated&&(s=this.headsMap[t.id]))for(j=0,P=0,f=s.length;f>P;P++)i=s[P],this.spaceUserMap[t.space].name===i.name&&(b=this.drawHead(t,i.head,j),j+=b);return this.ctx.restore(),this.activeCommit?this.drawCommitInfo(this.activeCommit):void 0},e.prototype.drawBackground=function(){var e,t,n,r,i;for(this.ctx.clearRect(0,0,this.width,this.height),this.ctx.save(),this.ctx.translate(0,this.offsetY+this.graphTopOffset),this.ctx.clearRect(0,-10,this.width,this.height),i=this.userBlocks,n=t=0,r=i.length;r>t;n=++t)e=i[n],this.ctx.fillStyle=this.bgColors[n%2],this.ctx.fillRect(0,e.start*this.nameLineHeight-10,this.width,e.count*this.nameLineHeight),this.ctx.fillStyle="#DDDDDD",this.ctx.fillRect(0,(e.start+e.count)*this.nameLineHeight-11,this.width,1);return this.ctx.restore()},e.prototype.drawCommit=function(e){var t,n;return t=e.time*this.nameLineHeight,n=e.space*this.nameLineHeight,this.ctx.beginPath(),this.ctx.arc(t,n,3,0,2*Math.PI,!1),this.ctx.fillStyle=this.spaceColor(e.space),this.ctx.fill()},e.prototype.drawActiveCommit=function(e){var t,n;return t=e.time*this.nameLineHeight,n=e.space*this.nameLineHeight,this.ctx.beginPath(),this.ctx.arc(t,n,6,0,2*Math.PI,!1),this.ctx.fillStyle=this.spaceColor(e.space),this.ctx.fill()},e.prototype.drawCommitInfo=function(e){var t,n,r,i,s,o,a,c,u,l;return t=3,n=340,l=56,u=e.message?this.splitLines(e.message,48):[],o=Math.max(l,38+16*u.length),r=this.offsetX+e.time*this.nameLineHeight,i=this.graphTopOffset+this.offsetY+e.space*this.nameLineHeight,a=0,c=0,a=rr;i=++r)o=e[i],a.push(this.ctx.fillText(o,t,n+16*i));return a},e.prototype.splitLines=function(e,t){var n,r,i,s,o,a;for(a=e.split(" "),s=[],i="",n=0,r=a.length;r>n;n++)o=a[n],i.length+1+o.lengtht;n=++t)i=s[n],0===n?i.space===e.space?o.push(this.drawBasicConnection(i,e)):o.push(this.drawBranchConnection(i,e)):o.push(this.drawMergeConnection(i,e));return o},e.prototype.drawBasicConnection=function(e,t){var n;return n=this.spaceColor(t.space),this.ctx.strokeStyle=n,this.ctx.lineWidth=2,this.ctx.beginPath(),this.ctx.moveTo(e.time*this.nameLineHeight,t.space*this.nameLineHeight),this.ctx.lineTo(t.time*this.nameLineHeight,t.space*this.nameLineHeight),this.ctx.stroke()},e.prototype.drawBranchConnection=function(e,t){var n;return n=this.spaceColor(t.space),this.ctx.strokeStyle=n,this.ctx.lineWidth=2,this.ctx.beginPath(),this.ctx.moveTo(e.time*this.nameLineHeight,e.space*this.nameLineHeight),this.ctx.lineTo(e.time*this.nameLineHeight,t.space*this.nameLineHeight),this.ctx.lineTo(t.time*this.nameLineHeight-10,t.space*this.nameLineHeight),this.ctx.stroke(),this.threeClockArrow(n,t.time*this.nameLineHeight,t.space*this.nameLineHeight)},e.prototype.drawMergeConnection=function(e,t){var n,r,i;return n=this.spaceColor(e.space),this.ctx.strokeStyle=n,this.ctx.lineWidth=2,this.ctx.beginPath(),e.space>t.space?(this.ctx.moveTo(e.time*this.nameLineHeight,e.space*this.nameLineHeight),i=this.safePath(e.time,t.time,e.space),i?(this.ctx.lineTo(t.time*this.nameLineHeight-10,e.space*this.nameLineHeight),this.ctx.lineTo(t.time*this.nameLineHeight-10,t.space*this.nameLineHeight+15),this.ctx.lineTo(t.time*this.nameLineHeight-5.7,t.space*this.nameLineHeight+7.5),this.ctx.stroke(),this.oneClockArrow(n,t.time*this.nameLineHeight,t.space*this.nameLineHeight)):(r=this.closestMargin(e.time,t.time,e.space,-1),e.space===t.space+1&&e.space===r+1?(this.ctx.lineTo(e.time*this.nameLineHeight,r*this.nameLineHeight+10),this.ctx.lineTo(t.time*this.nameLineHeight-15,r*this.nameLineHeight+10),this.ctx.lineTo(t.time*this.nameLineHeight-9.5,r*this.nameLineHeight+7.7),this.ctx.stroke(),this.twoClockArrow(n,t.time*this.nameLineHeight,r*this.nameLineHeight),this.addMargin(e.time,t.time,r)):e.time+1===t.time?(r=this.closestMargin(e.time,t.time,t.space,0),this.ctx.lineTo(e.time*this.nameLineHeight,r*this.nameLineHeight+10),this.ctx.lineTo(t.time*this.nameLineHeight-15,r*this.nameLineHeight+10),this.ctx.lineTo(t.time*this.nameLineHeight-15,t.space*this.nameLineHeight+10),this.ctx.lineTo(t.time*this.nameLineHeight-9.5,t.space*this.nameLineHeight+7.7),this.ctx.stroke(),this.twoClockArrow(n,t.time*this.nameLineHeight,t.space*this.nameLineHeight),this.addMargin(e.time,t.time,r)):(this.ctx.lineTo(e.time*this.nameLineHeight+10,e.space*this.nameLineHeight-10),this.ctx.lineTo(e.time*this.nameLineHeight+10,r*this.nameLineHeight+10),this.ctx.lineTo(t.time*this.nameLineHeight-10,r*this.nameLineHeight+10),this.ctx.lineTo(t.time*this.nameLineHeight-10,t.space*this.nameLineHeight+15),this.ctx.lineTo(t.time*this.nameLineHeight-5.7,t.space*this.nameLineHeight+7.5),this.ctx.stroke(),this.oneClockArrow(n,t.time*this.nameLineHeight,t.space*this.nameLineHeight),this.addMargin(e.time,t.time,r)))):(r=this.closestMargin(e.time,t.time,t.space,-1),rr;r++)if(s=o[r],this.timeInPath(e,s))return s[1]===t;return!1},e.prototype.closestMargin=function(e,t,n,r){var i,s,o,a,c;for(a=this.spaceMap.length,o=r,s=!1,i=!1,c=!1;!i||!s;){if(n+o>=0&&this.safeMargin(e,t,n+o))return n+o;0>n+o&&(s=!0),n+o>a&&(i=!0),c===!1&&0===o?(o=-1,c=!0):o=0>o?-o-1:-o-2}return n>0?n-1:0},e.prototype.safeMargin=function(e,t,n){var r,i,s,o;if(!this.marginMap[n])return!0;for(o=this.marginMap[n],r=0,i=o.length;i>r;r++)if(s=o[r],this.pathsCollide([e,t],s))return!1;return!0},e.prototype.pathsCollide=function(e,t){return this.timeWithinPath(e[0],t)||this.timeWithinPath(e[1],t)||this.timeWithinPath(t[0],e)||this.timeWithinPath(t[1],e)},e.prototype.timeInPath=function(e,t){return e>=t[0]&&e<=t[1]},e.prototype.timeWithinPath=function(e,t){return e>t[0]&&ee?e:d3.format(",s")(e)}),a=d3.tip().attr("class","svg-tip").offset([-10,0]).html(function(e){var n;return""+e.commits+" "+t(e.commits,"commit")+" by "+(null!=(n=e.login)?n:e.name)+""}),c=d3.select(this).append("svg").attr("width",u+o.left+o.right).attr("height",s+o.top+o.bottom).append("g").attr("transform","translate("+o.left+", "+o.top+")").call(a),c.append("g").attr("class","y axis").call(h),r=c.selectAll(".bar").data(i).enter().append("g").attr("class","bar").attr("transform",function(e,t){return"translate("+l(t)+", 0)"}),r.append("rect").attr("width",l.rangeBand()).attr("height",function(e,t){return s-d(e.commits)}).attr("y",function(e){return d(e.commits)}).on("mouseover",a.show).on("mouseout",a.hide),r.append("a").attr("xlink:href",function(e){return null!=e.login?"/"+e.login:void 0}).append("image").attr("y",s+5).attr("xlink:href",function(e){return e.gravatar}).attr("width",l.rangeBand()).attr("height",l.rangeBand())})}.call(this),function(){var e,t,n;t=require("github/inflector").pluralize,n=require("github/locale").weekdays,e=require("delegated-events"),e.on("graph:load",".js-graph-punchcard",function(e){var r,i,s,o,a,c,u,l,d,h,f,m,p,g,v,b,y,j,w,x,k,C;return i=e.detail.data,c=500,x=$(this).width(),f={},i.forEach(function(e){var t,r,i;return i=n[e[0]],t=null!=f[i]?f[i]:f[i]=[],r=e[1],null==t[r]&&(t[r]=0),t[r]+=e[2]}),i=d3.entries(f).reverse(),y=[0,0,0,20],v=y[0],p=y[1],g=y[2],m=y[3],l=100,s=d3.range(7),u=d3.range(24),h=d3.min(i,function(e){return d3.min(e.value)}),d=d3.max(i,function(e){return d3.max(e.value)}),k=d3.scale.ordinal().domain(u).rangeRoundBands([0,x-l-p-g],.1),C=d3.scale.ordinal().domain(s).rangeRoundBands([c-v-m,0],.1),b=d3.scale.sqrt().domain([0,d]).range([0,k.rangeBand()/2]),j=d3.tip().attr("class","svg-tip").offset([-10,0]).html(function(e){return""+e+" "+t(e,"commit")}),w=d3.select(this).data(i).attr("width",x+"px").append("svg").attr("width",x+(p+g)).attr("height",c+v+m).attr("class","viz").append("g").attr("transform","translate("+p+","+v+")").call(j),o=w.selectAll("g.day").data(i).enter().append("g").attr("class","day").attr("transform",function(e,t){return"translate(0, "+C(t)+")"}),o.append("line").attr("x1",0).attr("y1",C.rangeBand()).attr("x2",x-p-g).attr("y2",C.rangeBand()).attr("class","axis"),o.append("text").attr("class","day-name").text(function(e,t){return e.key}).attr("dy",C.rangeBand()/2),w.append("g").selectAll("text.hour").data(u).enter().append("text").attr("text-anchor","middle").attr("transform",function(e,t){return"translate("+(k(t)+l)+", "+c+")"}).attr("class","label").text(function(e){var t;return t=e%12||12,0===e||12>e?t+"a":t+"p"}),a=o.selectAll(".hour").data(function(e){return e.value}).enter().append("g").attr("class","hour").attr("transform",function(e,t){return"translate("+(k(t)+l)+", 0)"}).attr("width",k.rangeBand()),a.append("line").attr("x1",0).attr("y1",function(e,t){return C.rangeBand()-(t%2===0?15:10)}).attr("x2",0).attr("y2",C.rangeBand()).attr("class",function(e,t){return t%2===0?"axis even":"axis odd"}),r=a.append("circle").attr("r",0).attr("cy",C.rangeBand()/2-5).attr("class",function(e){ +return"day"}).on("mouseover",j.show).on("mouseout",j.hide),r.transition().attr("r",b)})}.call(this),function(){var e,t,n,r,i,s,o,a;n=require("github/d3/format-symbol")["default"],t=require("delegated-events"),s=function(e){var t;return(t=d3.format(","))(e)},i={top:20,right:40,bottom:30,left:40},a=980-i.left-i.right,r=170-i.top-i.bottom,e=function(e,t){var n;return n=d3.time.format.utc("%A, %B %-d, %Y"),d3.tip().attr("class","svg-tip web-views comparison").offset([-10,0]).html(function(r){return""+n(r.date)+"
        • "+s(r.total)+" "+e+"
        • "+s(r.unique)+" "+t+"
        "})},o=function(e,t){var o,c,u,l,d,h,f,m,p,g,v,b,y,j,w,x,k,C,S,L,q,A,T,_,E,D;if(e&&null==e.error){for(A=d3.time.scale.utc().range([0,a]),_=d3.scale.linear().range([r,0]),E=d3.scale.linear().range([r,0]),b=d3.time.format.utc("%m/%d"),T=d3.svg.axis().scale(A).ticks(e.counts.length).tickSize(r+5).tickPadding(10).tickFormat(b).orient("bottom"),D=d3.svg.axis().scale(_).ticks(3).tickFormat(n).orient("left"),m=d3.svg.line().x(function(e){return A(e.key)}).y(function(e){return _(e.value)}),S=d3.select(this).select(".js-graph").append("svg").attr("width",a+i.left+i.right).attr("height",r+i.top+i.bottom).attr("class","vis").append("g").attr("transform","translate("+i.left+","+i.top+")").call(t),c=e.counts,c.forEach(function(e){return e.date=new Date(1e3*e.bucket)}),c.sort(function(e,t){return d3.ascending(e.date,t.date)}),o=d3.bisector(function(e){return e.date}).left,y=function(){var e,n,r,i,s,a;return a=A.invert(d3.mouse(this)[0]),s=o(c,a,1),n=c[s-1],r=c[s],n&&r?(e=a-n.date>r.date-a?r:n,i=S.selectAll("g.dots circle").filter(function(t){return t.key===e.date}),i=i[0],i.sort(function(e,t){return $(e).attr("cy")-$(t).attr("cy")}),t.show.call(this,e,i[0])):void 0},w=[],C=[],h=0,f=c.length;f>h;h++)d=c[h],w.push({key:d.date,value:d.total}),C.push({key:d.date,value:d.unique});return v=[w,C],p=d3.extent(c,function(e){return e.date}),j=p[0],l=p[1],g=d3.extent(w,function(e){return e.value}),q=g[0],L=g[1],x=d3.max(C,function(e){return e.value}),k=x+d3.median(C,function(e){return e.value}),A.domain([j,l]),_.domain([0,L]),E.domain([0,k]),$(this).find(".js-traffic-total").text(s(e.summary.total)),$(this).find(".js-traffic-uniques").text(s(e.summary.unique)),S.append("g").attr("class","x axis").call(T),S.append("g").attr("class","y axis views").call(D),S.selectAll("path.path").data(v).enter().append("path").attr("class",function(e,t){return"path "+(0===t?"total":"unique")}).attr("d",function(e,t){return 0===t?m(e):m.y(function(e){return E(e.value)})(e)}),u=S.selectAll("g.dots").data(v).enter().append("g").attr("class",function(e,t){return 0===t?"dots totals":"dots uniques"}),u.each(function(e,t){var n;return n=d3.select(this),1===t&&(_=E),n.selectAll("circle").data(function(e,t){return e}).enter().append("circle").attr("cx",function(e){return A(e.key)}).attr("cy",function(e){return _(e.value)}).attr("r",4)}),D.scale(E).orient("right"),S.append("g").attr("class","y axis unique").attr("transform","translate("+a+", 0)").call(D),S.append("rect").attr("class","overlay").attr("width",a).attr("height",r).on("mousemove",y).on("mouseout",function(e){return setTimeout(t.hide,500)})}},t.on("graph:load","#js-visitors-graph",function(t){var n;return n=e("views","unique visitors"),$.observe("#js-visitors-graph .js-graph",{remove:n.hide}),o.apply(this,[t.detail.data,n])}),t.on("graph:load","#js-clones-graph",function(t){var n;return n=e("clones","unique cloners"),$.observe("#js-clones-graph .js-graph",{remove:n.hide}),o.apply(this,[t.detail.data,n])})}.call(this),function(){var e;e=function(){var e,t;t=$(this),e=t.find(":selected"),e.attr("data-already-member")?($(".js-account-membership-form").addClass("is-member"),$(".js-account-membership-form").removeClass("is-not-member")):($(".js-account-membership-form").removeClass("is-member"),$(".js-account-membership-form").addClass("is-not-member"))},$.observe(".js-account-membership",e),$(document).on("change",".js-account-membership",e)}.call(this),function(){var e,t,n,r,i,s,o,a,c,u;n=require("github/fetch").fetchPoll,c=null,o=300,a=[".",".","."],s=0,t=function(){return $(".js-audit-log-export-button").removeClass("disabled")},e=function(){return $(".js-audit-log-export-button").addClass("disabled")},i=function(){var t,n;return t=$(".js-audit-log-export-status"),t.data("oldText",t.text()),n=function(){var e;return e=a.slice(0,s).join(""),t.text("Exporting"+e),s>=3?s=0:s+=1},c=setInterval(n,o),e()},u=function(){var e;return t(),e=$(".js-audit-log-export-status"),e.text(e.data("oldText")),clearInterval(c),s=0},r=function(){return u(),$("#ajax-error-message").show(function(){return this.classList.add("visible")})},$(document).on("ajaxSend",".js-audit-log-export",i),$(document).on("ajaxError",".js-audit-log-export",r),$(document).on("ajaxSuccess",".js-audit-log-export",function(e,t,i,s){var o,a;return a=this,o=function(){return u(),window.location=s.export_url},n(s.job_url).then(o,r)}),$(document).on("navigation:open",".audit-search-form .js-suggester",function(e){return $(this).closest("form").submit()})}.call(this),function(){var e,t;$(document).on("submit",".js-find-coupon-form",function(e){var t,n;return t=e.target.action,n=$("#code").val(),window.location=t+"/"+encodeURIComponent(n),e.stopPropagation(),e.preventDefault()}),$(document).on("click",".js-choose-account",function(t){return $(".js-plan-row, .js-choose-plan").removeClass("selected"),$(".js-plan").val(""),$(".js-billing-section").addClass("has-removed-contents"),e($(this).closest(".js-account-row")),t.stopPropagation(),t.preventDefault()}),$(document).on("click",".js-choose-plan",function(e){return t($(this).closest(".js-plan-row")),e.stopPropagation(),e.preventDefault()}),$.observe(".js-plan-row.selected",{add:function(){return $(this).closest("form").find(".js-redeem-button").prop("disabled",$(this).hasClass("free-plan"))}}),e=function(e){var n,r,i,s;if(e.length)return i=e.attr("data-login"),s=e.attr("data-plan"),$(".js-account-row, .js-choose-account").removeClass("selected"),e.addClass("selected"),e.find(".js-choose-account").addClass("selected"),$(".js-account").val(i),$(".js-plan-section").removeClass("is-hidden"),$(".js-billing-plans").addClass("is-hidden"),r=$(".js-plans-for-"+i),r.removeClass("is-hidden"),n=$(".js-plan-row",r),t(1===n.length?n:$("[data-name='"+s+"']",r))},t=function(e){var t,n,r,i,s;if(e.length)return i=e.attr("data-name"),n=parseInt(e.attr("data-cost"),10),s=e.closest(".js-billing-plans"),r="true"===s.attr("data-has-billing"),t=s.attr("data-login"),$(".js-plan-row, .js-choose-plan").removeClass("selected"),e.addClass("selected"),e.find(".js-choose-plan").addClass("selected"),$(".js-plan").val(i),0===n||r?$(".js-billing-section").addClass("has-removed-contents"):$(".js-billing-section[data-login='"+t+"']").removeClass("has-removed-contents")},$(function(){return e($(".js-account-row.selected")),t($(".js-plan-row.selected"))})}.call(this),function(){$(document).on("change",".js-survey-select",function(){var e,t,n,r;return n=$(this)[0],t=$(this).closest(".js-survey-question-form"),e=t.find(".js-survey-other-text"),r=n.options[n.selectedIndex],r.classList.contains("js-survey-option-other")?(t.addClass("is-other-selected"),e.attr("required","required"),e.focus()):(e.removeAttr("required"),t.removeClass("is-other-selected"))}),$(document).on("change",".js-survey-radio",function(){var e,t,n;return e=$(this)[0],n=$(this).closest(".js-survey-question-form"),t=n.find(".js-survey-other-text"),e.classList.contains("js-survey-radio-other")?(n.addClass("is-other-selected"),t.attr("required","required"),t.focus()):(t.removeAttr("required"),n.removeClass("is-other-selected")),$(this).trigger("validation:field:change")})}.call(this),function(){var e,t,n,r,i,s,o,a,c,u,l=require("delegated-events"),d=l.fire;i=function(e){var t,n,r,i,s;if(i=e.match(/\#?(?:L)(\d+)/gi)){for(s=[],t=0,n=i.length;n>t;t++)r=i[t],s.push(parseInt(r.replace(/\D/g,"")));return s}return[]},n=function(e){var t;return(t=e.match(/(file-.+?-)L\d+?/i))?t[1]:""},r=function(e){return{lineRange:i(e),anchorPrefix:n(e)}},e=function(e){var t,n;switch(n=e.lineRange,t=e.anchorPrefix,n.sort(c),n.length){case 1:return"#"+t+"L"+n[0];case 2:return"#"+t+"L"+n[0]+"-L"+n[1];default:return"#"}},c=function(e,t){return e-t},a=!1,t=function(e){var t,n,r,i,s;if(i=e.lineRange,t=e.anchorPrefix,r=$(".js-file-line"),r.length){if(r.css("background-color",""),1===i.length)return $("#"+t+"LC"+i[0]).css("background-color","#f8eec7");if(i.length>1){for(n=i[0],s=[];n<=i[1];)$("#"+t+"LC"+n).css("background-color","#f8eec7"),s.push(n++);return s}}},o=function(e){var n,i,s;return null==e&&(e=r(window.location.hash)),s=e.lineRange,n=e.anchorPrefix,t(e),!a&&(i=$("#"+n+"LC"+s[0])).length&&$(window).scrollTop(i.offset().top-.33*$(window).height()),a=!1},u=function(e,t){var n,r,i;return i="FORM"===e.nodeName?"action":"href",n=e.getAttribute(i),(r=n.indexOf("#"))>=0&&(n=n.substr(0,r)),n+=t,e.setAttribute(i,n)},$.hashChange(function(){var e,t,n,r,i,s;if(document.querySelector(".js-file-line-container")){for(setTimeout(o,0),t=window.location.hash,i=document.querySelectorAll(".js-update-url-with-hash"),s=[],n=0,r=i.length;r>n;n++)e=i[n],s.push(u(e,t));return s}}),s=function(e){var t,n;return a=!0,n=null!=(t=$(window).scrollTop())?t:0,e(),$(window).scrollTop(n)},$(document).on("mousedown",".js-line-number",function(t){var n,o;return n=r(this.id),t.shiftKey&&(o=i(window.location.hash),n.lineRange.unshift(o[0])),s(function(){return window.location.hash=e(n)}),!1}),$(document).on("submit",".js-jump-to-line-form",function(){var e,t;return e=this.querySelector(".js-jump-to-line-field"),(t=e.value.replace(/[^\d\-]/g,""))&&(window.location.hash="L"+t),d(document,"facebox:close"),!1})}.call(this),function(){var e,t,n,r,i,s,o,a,c,u,l,d,h,f,m,p,g,v,b,y;i=require("github/fetch").fetchText,c=function(e){var t,n,r;return n=e[0],t=n.querySelector(".js-blob-filename"),t?"."===(r=t.value)||".."===r||".git"===r?!1:/\S/.test(t.value):!0},e=function(e){var t;return t=e.querySelector(".js-blob-contents"),t?"true"===t.getAttribute("data-allow-unchanged")?!0:s(t):!0},d=function(e){var t;return t=e.querySelector(".js-new-filename-field"),s(t)},t=function(t){var n;return t=$(".js-blob-form"),n=t[0],t.find(".js-check-for-fork").is($.visible)?!1:c(t)?e(n)||d(n):!1},g=function(e){var t;return t=e.find(".js-blob-contents")[0],t?$(t).attr("data-allow-unchanged")?!0:s(t):!1},u=function(e){var t,n;return n=e[0],t=n.querySelector(".js-blob-contents"),s(t)||d(n)},n=null,r=function(e){var t;return t=$(e).attr("data-github-confirm-unload"),("yes"===t||"true"===t)&&(t=""),null==t&&(t="false"),"no"===t||"false"===t?null:function(){return t}},h=function(){var e;return e=$(".js-blob-form"),e[0]?(e.find(".js-blob-submit").prop("disabled",!t(e)),e.find(".js-blob-contents-changed").val(g(e)),n?u(e)?window.onbeforeunload=n:window.onbeforeunload=null:void 0):void 0},f=function(e){var t,n,r,i,s;for(i=e.querySelectorAll("input"),s=[],n=0,r=i.length;r>n;n++)t=i[n],"hidden"===t.getAttribute("type")&&t.getAttribute("class")&&(null==t.getAttribute("data-default-value")?s.push(t.setAttribute("data-default-value",t.value)):s.push(void 0));return s},s=function(e){return null==e?!0:"hidden"===e.type?e.value!==e.getAttribute("data-default-value"):e.value!==e.defaultValue},m=function(e){var t,n,r,i;return t=e.querySelector(".js-blob-contents"),r=e.querySelector(".js-new-filename-field"),n=e.querySelector(".js-blob-filename"),t&&r&&n&&(null!=(i=n.defaultValue)?i.length:void 0)?$(t).data("old-filename",r.value):void 0},$.observe(".js-blob-form",function(){f(this),m(this),h(),n=r(this),$(this).on("submit",function(){return window.onbeforeunload=null})}),$(document).on("change",".js-blob-contents",function(){return p($(".js-blob-filename")),h()}),$(document).onFocusedInput(".js-blob-filename",function(){return function(){return $(".js-blob-contents").attr("data-filename",$(this).val()),l($(this).val()),p($(this))}}),$(document).onFocusedInput(".js-breadcrumb-nav",function(){return function(){return y($(this)),p($(this))}}),$(document).onFocusedKeydown(".js-breadcrumb-nav",function(){return function(e){var t,n,r;return n=$(this).caretSelection(),r=[0,0],t=0===$(n).not(r).length&&0===$(r).not(n).length,t&&8===e.keyCode&&1!==$(this).parent().children(".separator").length&&(a($(this),!0),e.preventDefault()),p($(this))}}),p=function(e){return null!=e[0]&&(b(e),v(e)),h()},y=function(e){var t,n,r,i,s,c;for(r=[];e.val().split("/").length>1;)t=e.val(),i=t.split("/"),n=i[0],c=i.slice(1).join("/"),""===n||"."===n||".git"===n?(e.val(c),s=function(){return e.caret(0)},r.push(window.setTimeout(s,1))):".."===n?r.push(a(e)):r.push(o(e,n,c));return r},l=function(e){var t,n;return t=$(".js-gitignore-template"),n=$(".js-license-template"),/^(.+\/)?\.gitignore$/.test(e)?t.addClass("is-visible"):/^(.+\/)?(licen[sc]e|copying)($|\.)/i.test(e)?n.addClass("is-visible"):(t.removeClass("is-visible"),n.removeClass("is-visible"))},v=function(e){var t,n,r,i,o,a,c,u,l,d,h,f;return r=e.closest("form"),n=$(".js-blob-contents"),t=r.find(".js-new-blob-commit-summary"),c=e.val()?"Create "+e.val():"Create new file",h=n.data("old-filename"),u=$(".js-new-filename-field").val(),n.removeData("new-filename"),c=(null!=h?h.length:void 0)&&u!==h&&null!=e[0]?(n.data("new-filename",!0),o=s(n[0]),i=o?"Update and rename":"Rename",e.val().length&&u.length?(f=h.split("/"),l=u.split("/"),d=!0,a=f.length-1,f.forEach(function(e,t){return t!==a&&e!==l[t]?d=!1:void 0}),f.length===l.length&&d?i+" "+f[a]+" to "+l[a]:i+" "+h+" to "+u):i+" "+h):(null!=h?h.length:void 0)&&u===h?"Update "+e.val():c,t.attr("placeholder",c),$(".js-commit-message-fallback").val(c)},b=function(e){var t,n;return t=$(".breadcrumb").children(".js-path-segment"),n="",t.each(function(){var e;return e=$(this),n=n+e.text()+"/"}),n+=e.val(),$(".js-new-filename-field").val(n)},a=function(e,t){var n,r;return null==t&&(t=!1),t||e.val(e.val().replace("../","")),r=function(){return e.caret(0)},1!==e.parent().children(".separator").length&&(e.prev().remove(),n=e.prev().children().children().html(),e.prev().remove(),t&&(e.val(""+n+e.val()),r=function(){return t?e.caret(n.length):void 0})),l(e.val()),window.setTimeout(r,1)},o=function(e,t,n){var r,i,s,o,a,c,u;return null==n&&(n=""),t=t.replace(/[^-.a-z_0-9]+/gi,"-"),t=t.replace(/^-+|-+$/g,""),t.length>0&&(u=e.parent().children(".js-repo-root, [itemtype]").children("a").last().attr("href"),u||(r=e.parent().children(".js-repo-root, [itemtype]").children("span").children("a").last(),i=r.attr("data-branch"),a=r.attr("href"),u=a+"/tree/"+i),s=$(".js-crumb-template").clone().removeClass("js-crumb-template"),s.find("a[itemscope]").attr("href",u+"/"+t),s.find("span").text(t),o=$(".js-crumb-separator").clone().removeClass("js-crumb-separator"),e.before(s,o)),e.val(n),l(e.val()),c=function(){return e.caret(0)},window.setTimeout(c,1)},$(document).onFocusedInput(".js-new-blob-commit-summary",function(){var e;return e=$(this).closest(".js-file-commit-form"),function(){return e.toggleClass("is-too-long-error",$(this).val().length>50)}}),$.observe(".js-check-for-fork",function(){this.addEventListener("load",function(){return h()})}),$(document).on("change",".js-gitignore-template input[type=radio]",function(){var e;return e=$(this).closest(".js-blob-form").find(".js-code-editor").data("code-editor"),i(this.getAttribute("data-template-url")).then(function(t){return e.setCode(t)})}),$(document).on("change",".js-license-template input[type=radio]",function(){var e,t;return e=$(this).closest(".js-blob-form").find(".js-code-editor").data("code-editor"),t=$(this).attr("data-template-contents"),e.setCode(t)}),$(document).onFocusedKeydown(".js-new-blob-commit-description",function(){return function(e){return"ctrl+enter"===e.hotkey||"meta+enter"===e.hotkey?($(this).closest("form").submit(),!1):void 0}})}.call(this),function(){var e,t;e=function(e){var t,n,r,i,s,o;for(e=e.toLowerCase(),t=$(".js-csv-data tbody tr"),i=[],n=0,r=t.length;r>n;n++)s=t[n],o=$(s).text().toLowerCase(),-1===o.indexOf(e)?i.push($(s).hide()):i.push($(s).show());return i},t=function(t){var n;n=t.target.value,null!=n&&e(n),t.preventDefault()},$(document).on("focus",".js-csv-filter-field",function(){return $(this).on("keyup",t)}),$(document).on("blur",".js-csv-filter-field",function(){return $(this).off("keyup",t)})}.call(this),function(){var e,t,n;t=require("github/pjax"),n=require("github/history").replaceState,e=null,$.observe(".js-branch-search-field",function(){var t,r,i,s,o,a,c,u,l,d,h,f,m,p;r=$(this),i=r.closest(".js-branch-search"),t=i.closest(".js-branches"),s=t.find(".js-branches-subnav .js-subnav-item"),m=i.prop("action"),f=i.attr("data-reset-url"),p=i.attr("data-results-container"),l=/\S/,c=function(){return l.test(r.val())},d=function(e,t){var r;return n(null,"",t),r=document.getElementById(p),$(r).html(e)},a=null,o=function(e){return a&&a.readyState<4&&a.abort(),a=$.ajax(e)},u=function(){var n,r;return null===e&&(e=s.filter(".selected")),n=c(),r=n?m+"?"+i.serialize():f,o({url:r,context:i}).always(function(){return t.removeClass("is-loading")}).done(function(e){return d(e,r)}),t.toggleClass("is-search-mode",n),t.addClass("is-loading"),s.removeClass("selected"),n?s.filter(".js-branches-all").addClass("selected"):(e.addClass("selected"),e=null)},h=function(){var e;return e=c(),r.val(""),e?u():void 0},r.on("throttled:input",u),r.on("keyup",function(e){return"esc"===e.hotkey?(h(),this.blur()):void 0})}),$(document).on("submit",".js-branch-search",!1),$(document).on("click",".js-clear-branch-search",function(e){var t;if(1===e.which)return t=$(this).closest(".js-branch-search").find(".js-branch-search-field"),t.focus().val("").trigger("input"),e.preventDefault()}),$(document).on("ajaxSend",".js-branch-destroy, .js-branch-restore",function(e,t){var n,r,i,s,o;return r=$(this),o=r.is(".js-branch-destroy"),s=r.closest(".js-branch-row").attr("data-branch-name"),n=r.closest(".js-branches").find(".js-branch-row").filter(function(){return this.getAttribute("data-branch-name")===s}),i=r.find("button[type=submit]"),i.blur().removeClass("tooltipped"),n.addClass("loading"),t.done(function(){return n.toggleClass("is-deleted",o)}).always(function(){return n.removeClass("loading"),i.addClass("tooltipped")})})}.call(this),function(){var e,t;e=function(){var e,n,r,i,s,o;return s=[],n=$(".js-advanced-search-input").val(),o={Repositories:0,Users:0,Code:0},e=$("input[type=text].js-advanced-search-prefix, select.js-advanced-search-prefix"),s=t(e,function(e,t,n){return""===e?"":(""!==t&&o[n]++,""!==t?""+e+t:void 0)}),$.merge(s,t($("input[type=checkbox].js-advanced-search-prefix"),function(e,t,n){var r;return r=$(this).prop("checked"),r!==!1&&o[n]++,r!==!1?""+e+r:void 0})),r=function(e){return e.Users>e.Code&&e.Users>e.Repositories?"Users":e.Code>e.Users&&e.Code>e.Repositories?"Code":"Repositories"},i=$.trim(s.join(" ")),$(".js-type-value").val(r(o)),$(".js-search-query").val($.trim(n+" "+i)),$(".js-advanced-query").empty(),$(".js-advanced-query").text(""+i),$(".js-advanced-query").prepend($("").text($.trim(n))," ")},t=function(e,t){return $.map(e,function(e,n){var r,i,s,o;return s=$.trim($(e).val()),r=$(e).attr("data-search-prefix"),i=$(e).attr("data-search-type"),o=function(e){return-1!==e.search(/\s/g)?'"'+e+'"':e},""===r?t.call(e,r,s,i):-1!==s.search(/\,/g)&&"location"!==r?s.split(/\,/).map(function(n,s){return t.call(e,r,o($.trim(n)),i)}):t.call(e,r,o(s),i)})},$(document).onFocusedInput(".js-advanced-search-prefix",function(){return function(){return e()}}),$(document).on("change",".js-advanced-search-prefix",e),$(document).on("focusin",".js-advanced-search-input",function(){return $(this).closest(".js-advanced-search-label").addClass("focus")}),$(document).on("focusout",".js-advanced-search-input",function(){return $(this).closest(".js-advanced-search-label").removeClass("focus")}),$(document).on("click",".js-see-all-search-cheatsheet",function(){return $(".js-more-cheatsheet-info").removeClass("hidden"),!1}),$(function(){return $(".js-advanced-search-input").length?e():void 0})}.call(this),function(){$(document).on("navigation:keyopen",".commits-list-item",function(){return $(this).find(".commit-title > a").first().click(),!1}),$(document).on("navigation:keydown",".commits-list-item",function(e){return"c"===e.hotkey?($(this).find(".commit-title > a").first().click(),!1):void 0})}.call(this),function(){var e;e=require("delegated-events"),$(document).on("click",".js-compare-tabs a",function(){return $(this).closest(".js-compare-tabs").find("a").removeClass("selected"),$(this).addClass("selected"),$("#commits_bucket, #files_bucket, #commit_comments_bucket").hide(),$(this.hash).show(),!1}),$.hashChange(function(){return $(this).closest("#files_bucket")[0]&&!$(this).is($.visible)?$('a.tabnav-tab[href="#files_bucket"]').click():void 0}),$(document).on("click",".js-toggle-range-editor-cross-repo",function(){return $(".js-range-editor").toggleClass("is-cross-repo"),!1}),e.on("pjax:click",".js-range-editor",function(e){var t;t=e.detail.options,$(".js-compare-pr").hasClass("open")&&!t.url.match(/expand=1/)&&(null==t.data&&(t.data={}),t.data.expand="1")}),$(document).on("navigation:open","form.js-commitish-form",function(){var e,t,n;return t=$(this),n=t.find(".js-new-item-name").text(),e=$("",{type:"hidden",name:"new_compare_ref",value:n}),t.append(e),t.submit()}),$.observe(".js-compare-pr.open",{add:function(){return document.body.classList.add("is-pr-composer-expanded")},remove:function(){return document.body.classList.remove("is-pr-composer-expanded")}})}.call(this),function(){var e,t,n,r,i,s,o;t=require("github/fetch").fetchText,o=require("github/dimensions").overflowOffset,$.hashChange(i=function(){var t,i,a,c,u,l,d,h,f;return c=window.location.hash,c&&(l=s(c))&&(t=l[0],i=l[1],f=l[2],u=l[3],!r(c.slice(1)))?(h=0,d=1,(a=function(){var t,s;if((s=$(r(i)).next()[0])&&(t=n(s,f,u)))return $(t).parents(".js-details-container").addClass("open"),e(t).then(function(){var e,t,n,i;if(t=r(c.slice(1))){if(n=o(t),i=n.top,e=n.bottom,0>i||0>e)return t.scrollIntoView()}else if(d>h)return h++,a()})})()):void 0}),$(document).on("click",".js-expand",function(){return e(this),!1}),e=function(e){var n;return n=e.getAttribute("data-url"),n+="&anchor="+encodeURIComponent(e.hash.slice(1)),n=n.replace(/[?&]/,"?"),new Promise(function(r,i){return t(n).then(function(t){var n,i;return n=$(e).closest(".js-expandable-line"),i=n.next(".file-diff-line"),i.preservingScrollPosition(function(){return n.replaceWith(t)}),r()},i)})},r=function(e){return document.getElementById(e)||document.getElementsByName(e)[0]},s=function(e){var t,n;return t=e.match(/\#(diff\-[a-f0-9]+)([L|R])(\d+)$/i),null!=t&&4===t.length?t:(n=e.match(/\#(discussion\-diff\-[0-9]+)([L|R])(\d+)$/i),null!=n&&4===n.length?n:null)},n=function(e,t,n){var r,i,s,o,a,c,u,l;for(n=parseInt(n,10),c=$(e).find(".js-expand"),o=0,a=c.length;a>o;o++)if(i=c[o],r="R"===t?"data-right-range":"data-left-range",u=i.getAttribute(r).split("-"),l=u[0],s=u[1],parseInt(l,10)<=n&&n<=parseInt(s,10))return i;return null}}.call(this),function(){var e,t,n,r,i,s,o,a,c;$(document).on("click",".js-add-single-line-comment",function(){var e,t,n,i,s,c;r($(this).closest(".file")[0]),s=this.getAttribute("data-path"),e=this.getAttribute("data-anchor"),c=this.getAttribute("data-position"),t=this.getAttribute("data-line"),i=a($(this).closest("tr")[0],{path:s,anchor:e,position:c,line:t}),n=$(i).find(".js-line-comments")[0],n.classList.contains("is-resolved")?n.classList.toggle("is-collapsed"):o(n)}),$(document).on("click",".js-add-split-line-comment",function(){var e,t,n,s,a,u,l,d;r($(this).closest(".file")[0]),d=this.getAttribute("data-type"),u=this.getAttribute("data-path"),e=this.getAttribute("data-anchor"),l=this.getAttribute("data-position"),n=this.getAttribute("data-line"),t=function(){switch(d){case"addition":return"js-addition";case"deletion":return"js-deletion"}}(),a=c($(this).closest("tr")[0]),s=i(a,t,{type:d,anchor:e,path:u,position:l,line:n}),s.classList.contains("is-resolved")?s.classList.toggle("is-collapsed"):o(s)}),$(document).on("click",".js-toggle-inline-comment-form",function(){return o($(this).closest(".js-line-comments")[0]),!1}),$(document).on("quote:selection",".js-line-comments",function(){o(this)}),$(document).onFocusedKeydown(".js-inline-comment-form .js-comment-field",function(){return function(t){return $(this).hasClass("js-navigation-enable")?void 0:"esc"===t.hotkey&&0===this.value.length?(e($(this).closest(".js-inline-comment-form")[0]),!1):void 0}}),$(document).on("click",".js-hide-inline-comment-form",function(){return e($(this).closest(".js-inline-comment-form")[0]),!1}),$(document).on("ajaxSuccess",".js-inline-comment-form",function(t,n,r,i){var s;this===t.target&&(s=$(this).closest(".js-line-comments"),s.find(".js-comments-holder").append(i.inline_comment),e(this))}),$(document).on("session:resume",function(e){var t;(t=e.targetId.match(/^new_inline_comment_diff_([\w-]+)_(\d+)$/))&&$(".js-add-line-comment[data-anchor="+t[1]+"][data-position="+t[2]+"]").click()}),o=function(e){return $(e).find(".js-inline-comment-form-container").addClass("open"),$(e).find(".js-write-tab").click(),$(e).find(".js-comment-field").focus()},e=function(e){return e.reset(),$(e).closest(".js-inline-comment-form-container").removeClass("open"),t()},r=function(e){return $(e).find(".js-toggle-file-notes").prop("checked",!0).trigger("change")},t=function(){var e,t,n,r,i,s,o;for(o=$(".file .js-inline-comments-container"),i=0,s=o.length;s>i;i++)t=o[i],e=$(t).find(".js-comments-holder > *"),r=e.length>0,n=$(t).find(".js-inline-comment-form-container").hasClass("open"),r||n||$(t).remove()},n=function(e){var t,n;return n=document.querySelector(e),t=n.firstElementChild.cloneNode(!0),t.querySelector("textarea").value="",t},$.observe(".js-comment",{remove:t}),a=function(e,t){var r,i;return null==t&&(t={}),(i=$(e).next(".js-inline-comments-container")[0])?i:(i=n("#js-inline-comments-single-container-template"),(r=i.querySelector(".js-inline-comment-form"))&&s(r,t),e.after(i),i)},i=function(e,t,r){var i,o,a;return null==r&&(r={}),(a=$(e).find(".js-line-comments."+t)[0])?a:(a=n("#js-inline-comments-split-form-container-template"),a.classList.add(t),(o=a.querySelector(".js-inline-comment-form"))&&s(o,r),i=$(e).find("."+t),i.last().after(a),i.remove(),a)},c=function(e){var t;return(t=$(e).next(".js-inline-comments-container")[0])?t:(t=$("#js-inline-comments-split-container-template").clone().children()[0],$(e).after(t),t)},s=function(e,t){var n,r,i,s,o;for(s=e.elements,r=0,i=s.length;i>r;r++)n=s[r],n.name in t&&(n.value=t[n.name]);o=e.querySelector(".js-comment-field"),o.id=o.id.replace(/^r\d+ /,"").replace("${anchor}",t.anchor).replace("${position}",t.position)}}.call(this),function(){var e,t;e=function(e,t,n){return $.observe(e,function(e){var r,i,s,o,a,c;return c=null,i=s=function(){c&&n(c,!1),c=null},o=function(e){c&&n(c,!1),c=$(e.target).closest(t)[0],c&&n(c,!0)},r=function(){return e.addEventListener("mouseenter",i),e.addEventListener("mouseleave",s),e.addEventListener("mouseover",o)},a=function(){return e.removeEventListener("mouseenter",i),e.removeEventListener("mouseleave",s),e.removeEventListener("mouseover",o)},{add:r,remove:a}})},t=function(e){return Math.floor(e/2)},e(".diff-table","td.blob-code, td.blob-num",function(e,n){var r,i,s,o,a,c,u,l,d,h;if(h=e.parentNode,r=h.children,4===r.length)for(o=a=0,u=r.length;u>a;o=++a)s=r[o],s===e&&(i=t(o));for(d=[],o=c=0,l=r.length;l>c;o=++c)s=r[o],(null==i||t(o)===i)&&d.push(s.classList.toggle("is-hovered",n));return d})}.call(this),function(){var e,t,n;$(document).on("click",".js-linkable-line-number",function(){return window.location.hash=this.id,!1}),e=null,n=function(e){return Math.floor(e/2)},t=function(){var t,r,i,s,o,a,c,u,l,d,h;if(e){for(a=0,u=e.length;u>a;a++)i=e[a],i.classList.remove("selected-line");e=null}if(o=window.location.hash.substring(1),o&&(h=document.getElementById(o)),h&&h.classList.contains("js-linkable-line-number")){if(d=h.parentNode,t=d.children,4===t.length)for(s=c=0,l=t.length;l>c;s=++c)i=t[s],i===h&&(r=n(s));e=function(){var e,o,a;for(a=[],s=e=0,o=t.length;o>e;s=++e)i=t[s],(null==r||n(s)===r)&&(i.classList.toggle("selected-line"),a.push(i));return a}()}},$.hashChange(t),$.observe(".blob-expanded",t)}.call(this),$(document).on("click",".js-rich-diff.collapsed .js-expandable",function(e){e.preventDefault(),$(e.target).closest(".js-rich-diff").removeClass("collapsed")}),$(document).on("click",".js-show-rich-diff",function(e){e.preventDefault(),$(this).closest(".js-warn-no-visible-changes").addClass("hidden").hide().siblings(".js-no-rich-changes").removeClass("hidden").show()}),function(){var e;e=function(){var e;return e="split"===$("meta[name=diff-view]").prop("content")&&$(".file-diff-split").is(":visible"),document.body.classList.toggle("split-diff",e)},$.observe("meta[name=diff-view]",{add:e,remove:e}),$.observe(".file-diff-split",{add:e,remove:e}),$.observe(".js-pull-request-tab.selected",{add:e,remove:e}),$.observe(".js-compare-tabs .tabnav-tab.selected",{add:e,remove:e})}.call(this),function(){$(document).on("change",".js-toggle-file-notes",function(){return $(this).closest(".file").toggleClass("show-inline-notes",this.checked)}),$(document).on("click",".js-toggle-all-file-notes",function(){var e,t;return e=$(".js-toggle-file-notes"),t=0===e.filter(":checked").length,e.prop("checked",t).trigger("change"),!1}),$.observe(".js-inline-comments-container",function(){var e,t,n;return(t=$(this).closest(".file")[0])?(e=n=function(){var e;e=null!=t.querySelector(".js-inline-comments-container"),t.classList.toggle("has-inline-notes",e)},{add:e,remove:n}):void 0})}.call(this),function(){function e(e){var t,n,r;r=e.parentElement,n=r.querySelectorAll("td.js-line-comments").length,t=r.querySelectorAll("td.js-line-comments.is-collapsed").length,r.classList.toggle("is-collapsed",t>0&&n===t)}$.observe("td.js-line-comments.is-collapsed",{add:function(t){e(t)},remove:function(t){e(t)}})}.call(this),function(){$(document).on("focusin",".js-url-field",function(){var e;return e=this,setTimeout(function(){return $(e).select()},0)})}.call(this),function(){document.querySelector(".js-account-membership-form")&&($(document).one("change.early-access-tracking",".js-account-membership-form",function(){return window.ga("send","event","Large File Storage","attempt","location: early access form")}),$(document).on("submit.early-access-tracking",".js-account-membership-form",function(e){return window.ga("send","event","Large File Storage","submit","location: early access form")}))}.call(this),function(){var e,t;t=require("github/fetch").fetchText,e=function(){return $(".js-repo-toggle-team:checked").visible()},$(document).onFocusedInput(".js-repository-name",function(){var e,t,n;return n=/[^0-9A-Za-z_\-.]/g,t=$(".js-form-note"),e=$(".js-rename-repository-button"),function(){t.html("Will be renamed as "+this.value.replace(n,"-")+""),n.test(this.value)?t.show():t.hide(),this.value&&this.value!==$(this).attr("data-original-name")?e.prop("disabled",!1):e.prop("disabled",!0)}}),$(document).on("click",".js-repo-team-suggestions-view-all",function(){return t(this.href).then(function(t){return function(n){var r,i;return i=e().map(function(){return this.value}),r=$(t).closest("ul"),r.html(n),i.each(function(){return r.find(".js-repo-toggle-team[value="+this+"]").prop("checked",!0)})}}(this)),!1})}.call(this),function(){var e,t,n,r,i,s;s=function(e,t){var n;return n=t.querySelector(".js-repo-access-error"),n.textContent=e,n.classList.remove("hidden")},r=function(){var e,t,n,r,i;for(r=document.querySelectorAll(".js-repo-access-error"),i=[],t=0,n=r.length;n>t;t++)e=r[t],e.textContent="",i.push(e.classList.add("hidden"));return i},e=function(e){return e.classList.toggle("is-empty",!e.querySelector(".js-repo-access-entry"))},i=function(){ +var e;(e=document.getElementById("collaborators"))&&(e.querySelector(".js-add-new-collab").disabled=!0,$(e.querySelector(".js-add-repo-access-field")).data("autocompleted"))},$.observe(".js-add-new-collab",i),t=function(e){var t,n,r,i,s,o,a;if(o=document.querySelector(".js-repo-access-team-select")){for(a=0,s=o.querySelectorAll(".js-repo-access-team-select-option"),t=0,i=s.length;i>t;t++)n=s[t],r=n.classList,e===n.getAttribute("data-team-id")&&(r.add("has-access"),r.remove("selected")),r.contains("has-access")||a++;if(0===a)return o.closest(".js-repo-access-group").classList.add("no-form")}},n=function(e){var t,n;return(n=document.querySelector(".js-repo-access-team-select"))?(null!=(t=n.querySelector("[data-team-id='"+e+"']"))&&t.classList.remove("has-access"),n.closest(".js-repo-access-group").classList.remove("no-form")):void 0},$(document).on("autocomplete:autocompleted:changed",".js-add-repo-access-field",function(){return $(this).data("autocompleted")?this.form.querySelector(".js-add-new-collab").disabled=!1:i()}),$(document).on("selectmenu:selected",".js-repo-access-team-select",function(){var e,t;return e=this.querySelector(".js-repo-access-team-select-option.selected").getAttribute("data-team-id"),t=this.closest(".js-repo-access-group").querySelector(".js-add-repo-access-field"),t.value=e,$(t.form).submit()}),$(document).on("ajaxSend",".js-add-repo-access-form",function(){r()}),$(document).on("ajaxSuccess",".js-add-repo-access-form",function(n,r,o,a){var c,u,l,d;return u=this.closest(".js-repo-access-group"),c=this.querySelector(".js-add-repo-access-field"),l=u.querySelector(".js-repo-access-list"),d=c.value,c.value="",a.error?s(a.error,u):(i(),l.insertAdjacentHTML("beforeend",a.html),e(u),"teams"===u.id?t(d):void 0)}),$(document).on("ajaxSuccess",".js-remove-repo-access-form",function(){var t,i;return r(),t=this.closest(".js-repo-access-entry"),i=this.closest(".js-repo-access-group"),"teams"===i.id&&n(t.getAttribute("data-team-id")),t.remove(),e(i)}),$(document).on("ajaxError",".js-remove-repo-access-form",function(){return s(this.getAttribute("data-error-message"),this.closest(".js-repo-access-group")),!1})}.call(this),function(){var e,t;e=require("github/fetch").fetchText,$(document).on("change",".js-default-branch",function(){var e,t;return t=document.querySelector(".js-default-branch-confirmation"),e=document.querySelector(".js-change-default-branch-button"),e.disabled=this.value===t.getAttribute("data-original-value"),t.value=this.value}),$(document).on("change",".js-repo-features-form input[type=checkbox]",function(){var e;return e=this.closest(".js-repo-option").querySelector(".js-status-indicator"),e.classList.remove("status-indicator-success","status-indicator-failed"),e.classList.add("status-indicator-loading")}),$(document).on("ajaxSuccess",".js-repo-features-form",function(e,t,n,r){var i,s,o,a;for(a=this.querySelectorAll(".status-indicator-loading"),s=0,o=a.length;o>s;s++)i=a[s],i.classList.remove("status-indicator-loading"),i.classList.add("status-indicator-success");return/^\s*n;n++)t=i[n],t.classList.remove("status-indicator-loading"),t.classList.add("status-indicator-failed"),e=t.closest(".js-repo-option").querySelector("input[type=checkbox]"),s.push(e.checked=!e.checked);return s}),$(document).on("change",".js-protect-branch",function(){var e,t,n,r,i,s,o,a,c,u;for(a=this.closest(".js-protected-branch-settings"),e=this.checked,c=a.querySelectorAll(".js-protected-branch-options"),n=0,s=c.length;s>n;n++)t=c[n],t.classList.toggle("active",e);for(u=a.querySelectorAll(".js-protected-branch-option"),i=0,o=u.length;o>i;i++)r=u[i],e?r.removeAttribute("disabled"):r.setAttribute("disabled","disabled")}),$(document).on("change",".js-required-status-toggle",function(){var e;e=this.closest(".js-protected-branch-settings").querySelector(".js-required-statuses"),e.classList.toggle("hidden",!this.checked)}),$(document).on("change",".js-required-status-checkbox",function(){var e;e=this.closest(".js-protected-branches-item"),e.querySelector(".js-required-status-badge").classList.toggle("hidden",!this.checked)}),$(document).on("change",".js-authorized-branch-pushers-toggle",function(){var e;e=this.closest(".js-protected-branch-settings").querySelector(".js-authorized-pushers"),e.classList.toggle("hidden",!this.checked),e.querySelector(".js-autocomplete-field").focus()}),$(document).on("change",".js-protected-branch-include-admin-toggle",function(){var e,t,n,r;for(r=this.closest(".js-protected-branch-settings").querySelectorAll(".js-protected-branch-admin-permission"),t=0,n=r.length;n>t;t++)e=r[t],e.classList.toggle("hidden"),e.classList.toggle("active",!e.classList.contains("hidden"))}),t=function(e){var t,n,r;return t=e.querySelector(".js-authorized-pushers"),r=parseInt(t.getAttribute("data-limit")),n=t.querySelectorAll(".js-authorized-user-or-team").length,t.classList.toggle("at-limit",n>=r)},$(document).on("autocomplete:result",".js-add-protected-branch-user-or-team",function(n,r){var i,s,o;s=this.closest(".js-protected-branch-options"),i=this.closest(".js-autocomplete-container"),o=i.getAttribute("data-url")+"&"+$.param({item:r}),e(o,{method:"GET",headers:{"Content-Type":"application/x-www-form-urlencoded; charset=UTF-8"}}).then(function(e){return i.querySelector(".js-autocomplete-field").value="",s.querySelector(".js-authorized-users-and-teams").insertAdjacentHTML("beforeend",e),t(s)})}),$(document).on("click",".js-remove-authorized-user-or-team",function(){var e;return e=this.closest(".js-protected-branch-options"),this.closest(".js-authorized-user-or-team").remove(),t(e)})}.call(this),function(){var e,t,n,r,i,s,o,a,c;a=["is-render-pending","is-render-ready","is-render-loading","is-render-loaded"].reduce(function(e,t){return e+" "+t}),o=function(e){var t;return t=e.data("timing"),null!=t?(t.load=t.hello=null,t.helloTimer&&(clearTimeout(t.helloTimer),t.helloTimer=null),t.loadTimer?(clearTimeout(t.loadTimer),t.loadTimer=null):void 0):void 0},r=function(e){var t,n,r;if(!e.data("timing"))return t=10,n=45,r={load:null,hello:null,helloTimer:null,loadTimer:null},r.load=Date.now(),r.helloTimer=setTimeout(c(e,function(){return!r.hello}),1e3*t),r.loadTimer=setTimeout(c(e),1e3*n),e.data("timing",r)},s=function(e){return e.addClass("is-render-requested")},i=function(e){return e.removeClass(a),e.addClass("is-render-failed"),o(e)},c=function(e,t){return null==t&&(t=function(){return!0}),function(){var n,r;return n=function(){try{return e.is($.visible)}catch(t){return e.visible().length>0}}(),!n||e.hasClass("is-render-ready")||e.hasClass("is-render-failed")||e.hasClass("is-render-failed-fatally")||!t()?void 0:(r=e.data("timing"))?(console.error("Render timeout: "+JSON.stringify(r)+" Now: "+Date.now()),i(e)):console.error("No timing data on $:",e)}},e=function(e){var t,n;t=$(e||this),(null!=(n=t.data("timing"))?n.load:0)||(o(t),r(t),t.addClass("is-render-automatic"),s(t))},null!=$.observe?$.observe(".js-render-target",e):$(function(){return $.each($(".js-render-target"),function(t,n){return e(n)})}),t=function(e){var t;return t=".js-render-target",e?$(t+"[data-identity='"+e+"']"):$(t)},$(window).on("message",function(e){var r,i,s,o,a,c,u,l,d,h;return l=null!=(u=e.originalEvent)?u:e,s=l.data,a=l.origin,s&&a&&(d=function(){var t;try{return JSON.parse(s)}catch(t){return e=t,s}}(),h=d.type,o=d.identity,i=d.body,c=d.payload,h&&i&&1===(r=t(o)).length&&a===r.attr("data-host")&&"render"===h)?n(r,h,o,i,c):void 0}),n=function(e,t,n,r,s){var o,c,u,l,d,h;switch(r){case"hello":if(d=e.data("timing")||{untimed:!0},d.hello=Date.now(),o={type:"render:cmd",body:{cmd:"ack",ack:!0}},u={type:"render:cmd",body:{cmd:"branding",branding:!1}},h=null!=(l=e.find("iframe").get(0))?l.contentWindow:void 0,"function"==typeof h.postMessage&&h.postMessage(JSON.stringify(o),"*"),"function"==typeof h.postMessage&&h.postMessage(JSON.stringify(u),"*"),e.hasClass("is-local"))return c=e.parents(".js-code-editor").data("code-editor"),u={type:"render:data",body:c.code()},"function"==typeof h.postMessage?h.postMessage(JSON.stringify(u),"*"):void 0;break;case"error":return i(e);case"error:fatal":return i(e),e.addClass("is-render-failed-fatal");case"error:invalid":return i(e,"invalid"),e.addClass("is-render-failed-invalid");case"loading":return e.removeClass(a),e.addClass("is-render-loading");case"loaded":return e.removeClass(a),e.addClass("is-render-loaded");case"ready":if(e.removeClass(a),e.addClass("is-render-ready"),null!=(null!=s?s.height:void 0))return e.height(s.height);break;case"resize":return null!=(null!=s?s.height:void 0)&&e.hasClass("is-render-ready")?e.height(s.height):console.error("Resize event sent without height or before ready");default:return console.error("Unknown message ["+t+"]=>'"+r+"'")}}}.call(this),function(){$(function(){var e,t;return e=$(".js-newsletter-frequency-choice"),e.length?(t=function(){var t;return e.find(".selected").removeClass("selected"),t=e.find("input[type=radio]:enabled:checked"),t.closest(".choice").addClass("selected")},e.on("change","input[type=radio]",function(){return t()}),t()):void 0}),$(document).on("ajaxSuccess",".js-subscription-toggle",function(e,t,n){var r;return r=$(this).find(".selected .notice"),r.addClass("visible"),setTimeout(function(){return r.removeClass("visible")},2e3)}),$(document).on("ajaxSuccess",".js-explore-newsletter-subscription-container",function(e,t,n){return $(this).replaceWith(t.responseText)})}.call(this),$(document).on("selectmenu:selected",".js-set-user-protocol-preference",function(){$(this).submit()}),$(document).on("navigation:open",".js-create-branch",function(){return $(this).submit(),!1}),function(){$(document).on("click",".js-toggle-lang-stats",function(e){var t,n;return n=document.querySelector(".js-stats-switcher-viewport"),t=0!==n.scrollTop?"is-revealing-overview":"is-revealing-lang-stats",n.classList.toggle(t),e.preventDefault()}),$(document).on("click",".js-toggle-lang-stats-new",function(e){var t;return t=document.querySelector(".js-file-navigation-new"),t.classList.toggle("is-revealing-stats"),e.preventDefault()})}.call(this),function(){var e,t,n=function(e,t){return function(){return e.apply(t,arguments)}};e=function(){function e(e){var t;t=$(e),this.name=t.attr("data-theme-name"),this.slug=t.attr("data-theme-slug"),this.baseHref=t.attr("href")}return e.prototype.wrappedKey=function(e,t){return null==t&&(t=null),t?t+"["+e+"]":e},e.prototype.params=function(e){var t;return null==e&&(e=null),t={},t[this.wrappedKey("theme_slug",e)]=this.slug,t},e.prototype.previewSrc=function(){return[this.baseHref,$.param(this.params())].join("&")},e}(),t=function(){function t(){this.updateScrollLinks=n(this.updateScrollLinks,this),this.scrollThemeLinksContainer=n(this.scrollThemeLinksContainer,this),this.onPublishClick=n(this.onPublishClick,this),this.onHideClick=n(this.onHideClick,this),this.onThemeLinkClick=n(this.onThemeLinkClick,this),this.onThemeNavNextClick=n(this.onThemeNavNextClick,this),this.onThemeNavPrevClick=n(this.onThemeNavPrevClick,this),this.onScrollForwardsClick=n(this.onScrollForwardsClick,this),this.onScrollBackwardsClick=n(this.onScrollBackwardsClick,this),this.onPagePreviewLoad=n(this.onPagePreviewLoad,this),this.$pagePreview=$("#page-preview"),this.$contextLoader=$(".theme-picker-spinner"),this.$fullPicker=$(".theme-picker-thumbs"),this.$miniPicker=$(".theme-picker-controls"),this.$scrollBackwardsLinks=$(".theme-toggle-full-left"),this.$scrollForwardsLinks=$(".theme-toggle-full-right"),this.$prevLinks=$(".theme-picker-prev"),this.$nextLinks=$(".theme-picker-next"),this.themeLinksContainer=this.$fullPicker.find(".js-theme-selector"),this.themeLinks=this.themeLinksContainer.find(".theme-selector-thumbnail"),this.themes=[],this.themeLinks.each(function(t){return function(n,r){return t.themes.push(new e(r))}}(this)),this.selectedTheme=this.themes[0],this.$pagePreview.load(this.onPagePreviewLoad),this.$scrollBackwardsLinks.click(this.onScrollBackwardsClick),this.$scrollForwardsLinks.click(this.onScrollForwardsClick),this.$prevLinks.click(this.onThemeNavPrevClick),this.$nextLinks.click(this.onThemeNavNextClick),this.themeLinks.click(this.onThemeLinkClick),$(".theme-picker-view-toggle").click(this.onHideClick),$("#page-edit").click(this.onEditClick),$("#page-publish").click(this.onPublishClick),this.theme(this.selectedTheme),this.updateScrollLinks()}return t.prototype.onPagePreviewLoad=function(e){var t,n;return this.$contextLoader.removeClass("visible"),t=this.$pagePreview[0].contentDocument?this.$pagePreview[0].contentDocument:this.$pagePreview[0].contentWindow.document,n=this.getDocHeight(t)+"px",this.$pagePreview.css("visibility","hidden"),this.$pagePreview.height("10px"),this.$pagePreview.height(n),this.$pagePreview.css("visibility","visible")},t.prototype.onScrollBackwardsClick=function(e){return this.scrollThemeLinksContainer(-1)},t.prototype.onScrollForwardsClick=function(e){return this.scrollThemeLinksContainer(1)},t.prototype.onThemeNavPrevClick=function(e){return this.theme(this.prevTheme())},t.prototype.onThemeNavNextClick=function(e){return this.theme(this.nextTheme())},t.prototype.onThemeLinkClick=function(e){return this.theme(this.themeForLink(e.currentTarget)),!1},t.prototype.onHideClick=function(e){var t;return this.$fullPicker.toggle(),this.$miniPicker.toggle(),this.scrollToTheme(this.theme(),!1),t=$(e.currentTarget),t.toggleClass("open")},t.prototype.onEditClick=function(e){return $("#page-edit-form").submit(),!1},t.prototype.onPublishClick=function(e){var t;return t=$("#page-publish-form"),t.find('input[name="page[theme_slug]"]').val(this.theme().slug),$("#page-publish-form").submit(),!1},t.prototype.scrollThemeLinksContainer=function(e){var t,n,r;return n=this.themeLinksContainer.scrollLeft(),r=this.themeLinksContainer.outerWidth(!0),t=n+r*e,this.themeLinksContainer.animate({scrollLeft:t},400,function(e){return function(){return e.updateScrollLinks()}}(this)),!1},t.prototype.updateScrollLinks=function(){var e,t,n;return e=this.themeLinksContainer.scrollLeft(),0>=e?(this.$scrollBackwardsLinks.addClass("disabled"),this.$scrollForwardsLinks.removeClass("disabled")):(this.$scrollBackwardsLinks.removeClass("disabled"),n=this.themeLinksContainer[0].scrollWidth,t=n-this.themeLinksContainer.outerWidth(!0),e>=t?this.$scrollForwardsLinks.addClass("disabled"):this.$scrollForwardsLinks.removeClass("disabled"))},t.prototype.selectedThemeIndex=function(){return this.themes.indexOf(this.selectedTheme)},t.prototype.prevTheme=function(){var e;return e=(this.selectedThemeIndex()-1)%this.themes.length,0>e&&(e+=this.themes.length),this.themes[e]},t.prototype.nextTheme=function(){return this.themes[(this.selectedThemeIndex()+1)%this.themes.length]},t.prototype.themeForLink=function(e){return this.themes[this.themeLinks.index($(e))]},t.prototype.linkForTheme=function(e){return $(this.themeLinks[this.themes.indexOf(e)])},t.prototype.scrollToTheme=function(e,t){var n,r,i,s,o,a;return null==t&&(t=!0),n=this.linkForTheme(e),a=this.themes.indexOf(e),s=n.outerWidth(!0),i=a*s,r=this.themeLinksContainer.scrollLeft(),o=r+this.themeLinksContainer.outerWidth(!0),r>i||i+s>o?t?this.themeLinksContainer.animate({scrollLeft:i},500):this.themeLinksContainer.scrollLeft(i):void 0},t.prototype.theme=function(e){return null==e&&(e=null),e?(this.selectedTheme=e,this.showPreviewFor(e),this.themeLinks.removeClass("selected"),this.linkForTheme(e).addClass("selected"),this.scrollToTheme(e),this.$miniPicker.find(".js-theme-name").text(e.name),!1):this.selectedTheme},t.prototype.showPreviewFor=function(e){var t;return this.$contextLoader.addClass("visible"),t=this.$fullPicker.find("form"),t.find('input[name="theme_slug"]').val(e.slug),t.submit()},t.prototype.getDocHeight=function(e){var t,n;return this.$pagePreview.height("auto"),t=e.body,n=e.documentElement,Math.max(t.scrollHeight,t.offsetHeight,n.clientHeight,n.scrollHeight,n.offsetHeight)},t}(),$(function(){return document.getElementById("theme-picker-wrap")?new t:void 0})}.call(this),$(document).on("click",".email-hidden-toggle > a",function(){return $(this).parent().siblings(".email-hidden-reply").toggle(),!1}),function(){function e(e){document.querySelector(".js-gist-dropzone").classList.remove("hidden"),e.stopPropagation(),e.preventDefault()}function t(e){var t;(null!=(t=e.target.classList)?t.contains("js-gist-dropzone"):void 0)&&e.target.classList.add("hidden")}function n(e){var t,n,i,s,o,a;for(a=e.dataTransfer.files,s=0,o=a.length;o>s;s++)i=a[s],window.ga("send","event","Interaction","File Drop",i.type,{useBeacon:!0}),t=function(t){var n;return i=t.file,n=t.data,e.target.dispatchEvent(new CustomEvent("gist:filedrop",{bubbles:!0,cancelable:!0,detail:{file:i,text:n}}))},n=function(){},r(i).then(t,n);document.querySelector(".js-gist-dropzone").classList.add("hidden"),e.stopPropagation(),e.preventDefault()}function r(e){return new Promise(function(t,n){var r;return r=new FileReader,r.onload=function(){var i;return i=r.result,i&&!/\0/.test(i)?t({file:e,data:i}):n(new Error("invalid file"))},r.readAsText(e)})}$.observe(".js-gist-dropzone",{add:function(){document.body.addEventListener("dragenter",e),document.body.addEventListener("dragleave",t),document.body.addEventListener("dragover",e),document.body.addEventListener("drop",n)},remove:function(){document.body.removeEventListener("dragenter",e),document.body.removeEventListener("dragleave",t),document.body.removeEventListener("dragover",e),document.body.removeEventListener("drop",n)}})}.call(this),function(){var e,t,n,r,i,s,o,a;n=require("github/fetch").fetchJSON,t=function(e){var t,n,r,i,s,o,a,c,u,l,d;for(r=e.querySelector(".js-gist-files"),d=document.getElementById("js-gist-file-template"),t=document.createElement("div"),t.innerHTML=d.textContent,u=t.querySelectorAll("[id]"),i=0,o=u.length;o>i;i++)n=u[i],n.removeAttribute("id");for(c=t.querySelector(".js-code-textarea"),null!=c&&c.setAttribute("id","blob_contents_"+Date.now()),l=t.children,s=0,a=l.length;a>s;s++)n=l[s],r.append(n);return r.lastElementChild},a=function(e){var n,r,i,s,o,a;for(o=e.querySelectorAll(".js-gist-file"),i=0,s=o.length;s>i;i++)if(n=o[i],r=n.querySelector(".js-gist-filename"),a=n.querySelector(".js-blob-contents"),!r.value&&!a.value)return n;return t(e)},o=function(e){var t;return t=e.closest(".js-code-editor"),new Promise(function(e){var n;return(n=$(t).data("code-editor"))?e(n):$(t).one("codeEditor:ready",function(){return e($(this).data("code-editor"))})})},e=function(e){var t,n,r,i;for(r=e.querySelectorAll(".js-code-textarea"),t=0,n=r.length;n>t;t++)if(i=r[t],i.value.trim().length>0)return!0;return!1},i=function(){var t,n,r,i,s;for(i=document.querySelectorAll(".js-gist-create"),s=[],n=0,r=i.length;r>n;n++)t=i[n],s.push(t.disabled=!e(t.form));return s},$(document).on("change",".js-code-textarea",function(){return i()}),r=function(){var e,t;return t=this,(e=t.getAttribute("data-language-detection-url"))?n(e+"?filename="+encodeURIComponent(t.value)).then(function(e){return o(t).then(function(t){return t.setMode(e.language)})}):void 0},$(document).onFocusedInput(".js-gist-filename",function(e){var t,n;return n=this,t=n.closest(".js-code-editor"),o(t).then(function(t){return null==t.ace?!1:$(n).on("throttled:input."+e,r)}),!1}),$(document).on("click",".js-add-gist-file",function(){var e;return e=this.closest(".js-blob-form"),t(e).scrollIntoView(),!1}),$(document).on("gist:filedrop",".js-blob-form",function(e){var t,n,i,s,c;return s=e.originalEvent.detail,t=s.file,c=s.text,n=a(this),i=n.querySelector(".js-gist-filename"),i.value=t.name,r.call(i),o(i).then(function(e){return e.setCode(c)}),n.scrollIntoView()}),$(document).on("click",".js-remove-gist-file",function(){var e,t,n,r,i;for(e=this.closest(".js-gist-file"),i=e.querySelectorAll(".js-gist-deleted input"),t=0,r=i.length;r>t;t++)n=i[t],n.disabled=!1;return e.querySelector(".js-code-editor").remove(),!1}),$(function(){return i()}),s=function(e){var t,n,r,i,s;for(n=e.querySelectorAll(".js-remove-gist-file"),s=[],r=0,i=n.length;i>r;r++)t=n[r],s.push(t.classList.toggle("hidden",n.length<2));return s},$.observe(".js-remove-gist-file",function(){var e;return e=this.closest(".js-gist-files"),{add:function(){return s(e)},remove:function(){return s(e)}}})}.call(this),$(document).on("ajaxComplete",".js-gist-file-update-container .js-comment-update",function(e,t){var n;200===t.status&&(n=JSON.parse(t.responseText),this.action=n.url)}),$(document).on("click",".js-skip-to-content",function(){return $("#start-of-content").next().attr("tabindex","-1").focus(),!1});var _this=this,_require=require("github/fetch"),fetchText=_require.fetchText;$(document).ready(function(){var e=function(){var e=$(".js-job-search-input").val(),n=$("input[type=text].js-job-search-prefix, select.js-job-search-prefix, input[type=hidden].js-job-search-prefix"),r=t(n,function(e,t){return""===e?"":""!==t?e+t:void 0}),i="input[type=checkbox].js-job-search-prefix";$.merge(r,t($(i),function(e,t){return"true"===t?e+t:void 0}));var s=$.trim(r.join(" "));$(".js-hidden-job-query").val($.trim(e+" "+s))},t=function(e,t){return $.map(e,function(e){var n=null;n=$(e).is("[type=checkbox]")?$(e).prop("checked")?"true":"false":$.trim($(e).val());var r=$(e).attr("data-search-prefix"),i=function(e){return-1!==e.search(/\s/g)?'"'+e+'"':e};return""===r?t.call(e,r,n):-1!==n.search(/\,/g)&&"location"!==r?n.split(/\,/).map(function(n){return t.call(e,r,i($.trim(n)))}):t.call(e,r,i(n))})};$(document).on("focusin",".js-job-search-prefix",function(){return function(){e()}}),$(document).on("focusin",".js-job-search-input",function(){$(_this).closest(".js-advanced-search-label").addClass("focus")}),$(document).on("change",".js-job-search-prefix",e),$(document).on("ajaxSuccess",".js-job-search-unwatch",function(e){var t=$(e.target),n=t.closest(".menu");t.closest(".menu-item").remove(),n.find(".menu-item").length<1&&($(".search-job-postings-watched, .js-job-search-watch").removeClass("hidden"),$(".js-watched-orgs").addClass("hidden"))}),$(document).on("ajaxSuccess",".js-org-job-search-unwatch",function(){$(".js-org-job-search-watch").removeClass("hidden")}),$(document).on("ajaxSuccess",".js-job-search-watch",function(e,t,n,r){$(".js-job-search-watch").addClass("hidden"),$(".js-job-search-watches").empty().append($(r))}),$(document).on("ajaxSuccess",".js-org-job-search-watch",function(e,t,n,r){$(".js-org-job-search-watch").addClass("hidden"),$(".js-org-job-search-unwatch").removeClass("hidden"),$(".js-org-job-search-id").attr("value",r.saved_search.id)});var n=".js-select-menu.js-job-search-watch, .js-select-menu.js-org-job-search-watch";$(n).on("menu:activated",function(e){$(e.target).find(".js-job-search-title").focus()}),$(".js-job-search-unwatch, .js-org-job-search-unwatch").on("submit",function(e){$(e.target).addClass("hidden")});var r=function(e){var t=e.attr("data-value"),n=e.closest(".js-suggester-container").find(".js-job-search-input");n.val(t).change(),e.closest(".js-suggester").empty().hide()},i=function(e,t){var n=e.find(".js-navigation-item");if(!(n.length<1)){var r=e.find(".js-navigation-item.navigation-focus"),i=null;if(r.length>0){var s=r.next(),o=r.prev();r.removeClass("navigation-focus"),i=1===t?s.length>0?s:n.first():o.length>0?o:n.last()}else i=1===t?n.first():n.last();i.addClass("navigation-focus")}},s=function(e,t){var n=$.trim(e.val()),r=e.closest(".js-suggester-container").find(".js-suggester");if(r.empty().hide(),!(n.length<1)){var i=t.indexOf("?")>-1?"&":"?";t+=i+'q=title:"'+encodeURIComponent(n)+'"',fetchText(t).then(function(e){var t=$(e);t.find("li").length>0&&r.append(t).show()})}},o=null,a=function(e){var t=$(e.target),n=t.closest(".js-suggester-container"),a=n.find(".js-suggester");if(o&&clearTimeout(o),38===e.keyCode)return void i(a,-1);if(40===e.keyCode)return void i(a,1);if(27===e.keyCode)return void a.empty().hide();if(13===e.keyCode){var c=a.find(".js-navigation-item.navigation-focus");return void(c.length>0&&(e.preventDefault(),r(c)))}var u=n.find(".js-navigation-container").attr("data-url");o=setTimeout(function(){s(t,u)},1e3)};$(".js-job-search-input").on("keydown",a);var c=function(e){var t=$(e.target);t.closest(".js-job-search-suggester").find(".navigation-focus").removeClass("navigation-focus"),t.addClass("navigation-focus")},u=function(e){$(e.target).removeClass("navigation-focus")},l=function(e){var t=$(e.target);t.is(".js-navigation-item")||(t=t.closest(".js-navigation-item")),r(t)},d=".js-job-search-suggester .js-navigation-item";$(document).on("mouseover",d,c).on("mouseout",d,u).on("click",d,l),($(".js-job-search-input").length||$(".js-job-search-hidden").length)&&e()}),function(){var e,t,n,r,i,s,o;s=require("github/fetch"),n=s.fetch,r=s.fetchText,i=require("delegated-events").fire,e={isHttpFragment:function(e){return 0==="http://".indexOf(e)||0==="https://".indexOf(e)},isValidHttpUrl:function(e){var t,n,r;return e=e.trim(),r=function(){try{return new URL(e)}catch(t){}}(),null==r?!1:(t=/^https?/.test(r.protocol),n=r.href===e||r.href===e+"/",t&&n)}},$.observe(".js-hook-url-field",function(t){var n,r,i;n=$(t),r=function(e){var t,n;return t=$(e).closest("form"),n=/^https:\/\/.+/.test(e.val()),t.toggleClass("is-ssl",n)},i=function(t){var n,r;return n=t.val(),r=e.isHttpFragment(n)||e.isValidHttpUrl(n),t.closest("form").toggleClass("is-invalid-url",!r)},n.on("keyup",function(){return r(n)}),n.on("throttled:input",function(){return i(n)}),r(n),i(n)}),$(document).on("click",".js-hook-toggle-ssl-verification",function(e){return e.preventDefault(),$(".js-ssl-hook-fields").toggleClass("is-not-verifying-ssl"),$(".js-ssl-hook-fields").hasClass("is-not-verifying-ssl")?($(".js-hook-ssl-verification-field").val("1"),i(document,"facebox:close")):$(".js-hook-ssl-verification-field").val("0")}),t=function(e){var t;return t=$(".js-hook-event-checkbox"),t.prop("checked",!1),null!=e?t.filter(e).prop("checked",!0):void 0},$(document).on("change",".js-hook-event-choice",function(){var e;return e="custom"===$(this).val(),$(".js-hook-events-field").toggleClass("is-custom",e),!0}),$(document).on("submit",".js-hook-form",function(){var e,n;return e=$(this),n=e.find(".js-hook-event-choice:checked").val(),"custom"===n&&$(".js-hook-wildcard-event").prop("checked",!1),"push"===n&&t('[value="push"]'),"all"===n&&t(".js-hook-wildcard-event"),!0}),$(document).on("details:toggled",".js-hook-secret",function(){var e,t;return e=$(this),t=e.find("input[type=password]"),e.hasClass("open")?t.removeAttr("disabled").focus():t.attr("disabled","disabled")}),$(document).on("details:toggle",".js-hook-delivery-item",function(){var e,t;return e=$(this),t=this.querySelector(".js-hook-delivery-details"),e.data("details-load-initiated")?void 0:$.sudo().then(function(){var n,i;return e.data("details-load-initiated",!0),t.classList.add("is-loading"),n=function(e){return $(t).replaceWith(e),t.classList.remove("is-loading")},i=function(){return t.classList.add("has-error"),t.classList.remove("is-loading")},r(t.getAttribute("data-url")).then(n,i)})}),$(document).on("click",".js-hook-delivery-details .js-tabnav-tab",function(){var e,t,n;return t=$(this),e=t.closest(".js-hook-delivery-details"),e.find(".js-tabnav-tab").removeClass("selected"),n=e.find(".js-tabnav-tabcontent").removeClass("selected"),t.addClass("selected"),n.filter(function(){return this.getAttribute("data-tab-name")===t.attr("data-tab-target")}).addClass("selected")}),$(document).on("click",".js-hook-deliveries-pagination-button",function(e){var t,n;return e.preventDefault(),n=this,t=$(this).parent(),$.sudo().then(function(){return t.addClass("loading"),r(n.getAttribute("href")).then(function(e){return t.replaceWith(e)})})}),$(document).on("click",".js-redeliver-hook-delivery-init-button",function(e){var t;return e.preventDefault(),t=this.getAttribute("href"),$.sudo().then(function(){return $.facebox({div:t})})}),$(document).on("ajaxSuccess",".js-redeliver-hook-form",function(e,t){var n,r,s,o;return o=this.getAttribute("data-delivery-guid"),n=$(".js-hook-delivery-details").filter(function(){return this.getAttribute("data-delivery-guid")===o}),s=n.closest(".js-hook-delivery-item"),i(document,"facebox:close"),r=$(t.responseText),n.replaceWith(r),r.on("load",function(){return n=s.find(".js-hook-delivery-details"),s.find(".js-item-status").removeClass("success pending failure").addClass(n.attr("data-status-class")),s.find(".js-item-status-tooltip").attr("aria-label",n.attr("data-status-message"))})}),$(document).on("ajaxError",".js-redeliver-hook-form",function(){return $(this).siblings(".js-redelivery-dialog").addClass("failed")}),$(document).on("submit",".js-test-hook-form",function(e){var t;return e.preventDefault(),t=this,$.sudo().then(function(){var e,r,i,s;return s=document.querySelector(".js-test-hook-message"),s.classList.remove("error","success"),e=function(){return t.dispatchEvent(new CustomEvent("ajaxComplete",{bubbles:!0}))},r=function(){return s.classList.add("success")},i=function(e){var t;return s.classList.add("error"),t=s.querySelector(".js-test-hook-message-errors"),null!=e.response?e.response.json().then(function(e){return t.textContent=e.errors}):t.textContent="Network request failed"},n(t.action,{method:t.method,body:$(t).serialize(),headers:{"Content-Type":"application/x-www-form-urlencoded; charset=UTF-8"}}).then(r,i).then(e,e)})}),o=function(){var e,t,n,r;return n=$(this),r=n.find(".js-value"),e=n.closest("form"),t=e.find(".js-item-value")[0],t.value=r.text(),e.submit()},$(document).on("click",".js-hook-enforcement-select .js-navigation-item",o),$(document).on("click",".js-hook-final-input",function(){return $(this).closest("form").submit()})}.call(this),function(){var e,t,n,r,i,s,o;o=require("github/fetch"),n=o.fetchText,e=o.fetchJSON,t=o.fetchPoll,s=require("github/inflector").pluralizeNode,$(document).on("change",".js-triage-list-check",function(e){return $(".js-triage-toolbar").toggleClass("triage-mode",$(".js-triage-list-check:checked").length>0)}),$(document).on("change",".js-triage-list-check",function(){var e;e=$(".js-triage-list-check:checked"),$(".js-triage-item").data("contents-data",e).addClass("js-load-contents")}),$(document).on("selectmenu:selected",".js-triage-toolbar .js-navigation-item",function(){var e,t,n,r,i,s;n=$(this).closest(".js-menu-container").hasClass("js-select-menu-multiple"),e=$(this).closest("form"),i=$(this).hasClass("selected"),r=$(this).attr("data-name"),s=$(this).attr("data-value"),t=n?$("",{type:"hidden",name:r+"["+s+"]",value:i?"1":"0"}):$("",{type:"hidden",name:r,value:i?s:""}),setImmediate(function(e){return function(){return $(e).menu("deactivate")}}(this)),e.find(".js-bulk-triage-fields").append(t),e.addClass("will-submit")}),$(document).on("menu:deactivate",".js-triage-toolbar .js-menu-container",function(n){var r,i;(r=this.querySelector("form.will-submit"))&&(this.classList.add("is-loading"),i=e(r.getAttribute("action"),{method:"put",body:$.param($(r).serializeArray()),headers:{"Content-Type":"application/x-www-form-urlencoded; charset=UTF-8"}}),i.then(function(e){return function(n){var r,i,s;return s=t(n.job.url,{headers:{accept:"application/json"}}),r=function(){return $(e).menu("deactivate"),location.reload()},i=function(){return e.classList.add("has-error")},s.then(r,i)}}(this)),r.classList.remove("will-submit"),n.preventDefault())}),i=function(e){return $(e).closest(".js-check-all-container")[0]||document.body},$(document).on("change","input.js-orgs-org-toggle",function(e){var t,n,r;t=$(i(this)),n=t.find(".js-check-all-count"),n.length&&(r=t.find("input.js-check-all-item:checked").length,s(r,document.querySelector(".js-orgs")))}),$(document).on("submit",".js-delete-orgs-form",function(n){var r,i,s,o,a;n.preventDefault(),s=$(".facebox"),s.addClass("is-loading"),o=this,r=$(".js-triage-list-check:checked"),i=r.length?"&"+$.param(r):"",a=e(o.getAttribute("action"),{ +method:"put",body:$.param($(o).serializeArray())+i,headers:{"Content-Type":"application/x-www-form-urlencoded; charset=UTF-8"}}),a.then(function(e){var n,r,i;return i=t(e.job.url,{headers:{accept:"application/json"}}),n=function(){return location.reload()},r=function(){return o.classList.add("has-error")},i.then(n,r)})}),r=function(){var e,t,n;return e=$(".js-orgs-grid"),t=e.find(".js-orgs-org").has(".js-orgs-org-toggle:checked"),function(){var e,r,i;for(i=[],e=0,r=t.length;r>e;e++)n=t[e],i.push(n.getAttribute("data-id"));return i}().sort()},$(document).on("click",".js-orgs-delete-confirm-button",function(e){return e.preventDefault(),$.facebox(function(){var t;return t=n($(e.target).attr("data-url")+"?organization_ids="+r().join(","),{headers:{"Content-Type":"application/x-www-form-urlencoded; charset=UTF-8"}}),t.then(function(e){return $.facebox(e)})})}),$(document).on("change",".js-hosted-admin-auth-switcher",function(e){var t;return t=$(".js-hosted-admin-saml-settings"),t.toggleClass("hidden")}),$(document).on("click",".js-preview-sign-in-message",function(e){var t,n;return n=$("#customizations_sign_in_message").val(),t=encodeURIComponent(n),window.open("/preview_sign_in_message?sign_in_message="+t,"_blank")}),$(document).on("click",".js-preview-suspended-message",function(e){var t,n;return n=$("#customizations_suspended_message").val(),t=encodeURIComponent(n),window.open("/preview_suspended_message?suspended_message="+t,"_blank")}),$(document).on("focus",".js-toggle-pre-receive-repo-list",function(e){return $(".select-menu-modal-holder.pre-receive-repo-list").addClass("visible")}),$(document).on("blur",".js-toggle-pre-receive-repo-list",function(e){return $(".js-navigation-container .navigation-focus").mousedown(),$(".select-menu-modal-holder.pre-receive-repo-list").removeClass("visible")}),$(document).on("mousedown",".js-select-repo-for-pre-receive-hook",function(e){var t,n;return n=$(e.target).find(".repo-and-owner").length>0?$(e.target).find(".repo-and-owner").first():$(e.target).closest(".repo-and-owner").first(),$("#repo-pre-receive-filter-field").val(n.text().trim()),t=$(e.target).closest(".js-select-repo-for-pre-receive-hook"),$("#pre_receive_hook_target_hook_attributes_repository_id").val(t.data("repo-id"))}),$(document).on("click",".js-select-repo-for-pre-receive-hook",function(e){return $(".js-toggle-pre-receive-repo-list").blur()}),$(document).on("selectmenu:selected",".js-select-environment",function(e){var t;return t=$(this).attr("data-env-id"),$("#pre_receive_hook_target_hook_attributes_environment_id").val(t)})}.call(this),function(){$(document).on("navigation:open",".js-issues-custom-filter",function(){var e,t,n,r;return t=$(this),r=t.find(".js-new-item-name").text(),n=t.attr("data-name"),e=$("",{type:"hidden",name:n,value:r}),t.append(e),t.submit()})}.call(this),function(){var e,t,n;t=function(t,n){return t.closest(".js-label-editor").find(".js-color-editor-bg").css("background-color",n),t.css("color",e(n,-.5)),t.css("border-color",n)},n=function(e){var t,n;return n="#c00",t=$(e).closest(".js-color-editor"),t.find(".js-color-editor-bg").css("background-color",n),e.css("color","#c00"),e.css("border-color",n)},e=function(e,t){var n,r,i;for(e=String(e).toLowerCase().replace(/[^0-9a-f]/g,""),e.length<6&&(e=e[0]+e[0]+e[1]+e[1]+e[2]+e[2]),t=t||0,i="#",n=void 0,r=0;3>r;)n=parseInt(e.substr(2*r,2),16),n=Math.round(Math.min(Math.max(0,n+n*t),255)).toString(16),i+=("00"+n).substr(n.length),r++;return i},$(document).on("focusin",".js-color-editor-input",function(){var e,r;return r=$(this),e=$(this).closest(".js-label-editor"),r.on("throttled:input.colorEditor",function(i){var s;return"#"!==r.val().charAt(0)&&r.val("#"+r.val()),e.removeClass("is-valid is-not-valid"),s=/(^#[0-9A-F]{6}$)|(^#[0-9A-F]{3}$)/i.test(r.val()),s?(e.addClass("is-valid"),t(r,r.val())):(e.addClass("is-not-valid"),n(r))}),r.on("blur.colorEditor",function(){return r.off(".colorEditor")})}),$(document).on("mousedown",".js-color-chooser-color",function(e){var n,r,i;return $(this).closest(".js-color-editor").removeClass("open"),n=$(this).closest(".js-label-editor"),r="#"+$(this).attr("data-hex-color"),i=n.find(".js-color-editor-input"),n.removeClass("is-valid is-not-valid"),i.val(r),t(i,r)}),$(document).on("submit",".js-label-editor form",function(){var e,t;return e=$(this).find(".js-color-editor-input"),t=e.val(),t.length<6&&(t=t[1]+t[1]+t[2]+t[2]+t[3]+t[3]),e.val(t.replace("#",""))}),$(document).on("focusin",".js-label-editor",function(){return $(this).closest(".js-label-editor").addClass("open")}),$(document).on("reset",".js-create-label",function(){var e,n,r;return e=$(this).find(".color-chooser span").removeAttr("data-selected"),r=e.eq(Math.floor(Math.random()*e.length)),n="#"+r.attr("data-selected","").attr("data-hex-color"),setImmediate(function(e){return function(){var r;return r=$(e).find(".js-color-editor-input"),r.attr("data-original-color",n).attr("value",n),t(r,r.val())}}(this))})}.call(this),function(){var e,t,n,r,i,s;n=require("github/inflector").pluralizeNode,r=require("github/number-helpers"),e=r.formatNumber,t=r.parseFormattedNumber,i=function(e,t){return e.closest("div.js-details-container").classList.toggle("is-empty",t)},s=function(r){var i,s,o;return i=document.querySelector(".js-labels-count"),o=t(i.textContent),s=o+r,i.textContent=e(s),n(s,document.querySelector(".js-labels-label")),s},$(document).on("click",".js-edit-label",function(){return $(this).closest(".labels-list-item").addClass("edit")}),$(document).on("click",".js-edit-label-cancel",function(){return this.form.reset(),$(this).closest(".labels-list-item").removeClass("edit")}),$(document).on("ajaxSuccess",".js-create-label",function(e,t,n,r){return this.reset(),$(this).nextAll(".table-list").prepend(r),s(1),i(this,!1)}),$(document).on("ajaxSuccess",".js-update-label",function(e,t,n,r){return $(this).closest(".labels-list-item").replaceWith(r)}),$(document).on("ajaxSend",".js-update-label, .js-create-label",function(){return $(this).find(".error").text("")}),$(document).on("ajaxError",".js-update-label, .js-create-label",function(e,t){return $(this).find(".error").text(t.responseText),!1}),$(document).on("ajaxSuccess",".js-delete-label",function(){var e;return e=s(-1),i(this,0===e),$(this).closest(".labels-list-item").fadeOut()})}.call(this),function(){$.hashChange(function(e){var t,n,r,i;return i=e.newURL,(r=i.match(/\/issues#issue\/(\d+)$/))?(t=r[0],n=r[1],window.location=i.replace(/\/?#issue\/.+/,"/"+n)):void 0}),$.hashChange(function(e){var t,n,r,i,s;return s=e.newURL,(i=s.match(/\/issues#issue\/(\d+)\/comment\/(\d+)$/))?(t=i[0],r=i[1],n=i[2],window.location=s.replace(/\/?#issue\/.+/,"/"+r+"#issuecomment-"+n)):void 0})}.call(this),function(){var e;$.observe(".js-issues-list-check:checked",{add:function(){return $(this).closest(".js-issue-row").addClass("selected")},remove:function(){return $(this).closest(".js-issue-row").removeClass("selected")}}),$(document).on("navigation:keydown",".js-issue-row",function(t){return"x"===t.hotkey?(e(this),!1):void 0}),$("#js-issues-search").focus(function(e){return this.value=this.value}),e=function(e){var t;(t=$(e).find(".js-issues-list-check")[0])&&(t.checked=!t.checked,$(t).trigger("change"))}}.call(this),function(){var e=require("delegated-events"),t=e.on;t("selectmenu:selected",".js-saved-reply-container",function(e){var t=e.target.querySelector(".js-saved-reply-body").textContent.trim(),n=this.closest(".js-previewable-comment-form"),r=n.querySelector(".js-comment-field");r.value=t})}(),function(){var e,t,n,r,i;e=require("github/fetch").fetchText,$(document).on("selectmenu:selected",".js-issue-sidebar-form",function(e){var t,r,i,s,o;return r=e.target,r.hasAttribute("data-assignee-value")&&(i=r.closest(".js-menu-content"),t=i.querySelector(".js-assignee-field"),t.value=r.getAttribute("data-assignee-value"),t.disabled=!1),o=function(e){return function(){return e.matches("form")?$(e).submit():n(e)}}(this),s=r.closest(".js-select-menu").hasAttribute("data-multiple"),s?($(this).off(".deferredSubmit"),$(this).one("menu:deactivate.deferredSubmit",o)):o()}),i=function(e,t){var n;e.replaceWith.apply(e,$.parseHTML(t)),n=document.querySelector(".js-discussion-sidebar-item .js-assignee-field"),n&&n.value&&(n.disabled=!1)},$(document).on("ajaxSuccess",".js-discussion-sidebar-item",function(e,t,n,r){var s;s=e.target.classList,s.contains("js-issue-sidebar-form")&&i(this,r)}),$(document).on("click","div.js-issue-sidebar-form .js-issue-assign-self",function(e){var t;t=this.closest(".js-issue-sidebar-form"),n(t,{name:this.name,value:this.value}),e.preventDefault()}),n=function(t,n){var s;s=r(t),n&&s.push(n),s.push({name:"authenticity_token",value:t.closest("form").elements.authenticity_token.value}),e(t.getAttribute("data-url"),{method:"post",body:$.param(s),headers:{"Content-Type":"application/x-www-form-urlencoded; charset=UTF-8"}}).then(function(e){return i(t.closest(".js-discussion-sidebar-item"),e)})},r=function(e){var n,r,i,s,o,a;for(n=e.closest("form"),o=$(n).serializeArray(),a=[],r=0,i=o.length;i>r;r++)s=o[r],$.contains(e,t(n,s))&&a.push(s);return a},t=function(e,t){var n,r,i,s;for(s=e.elements,r=0,i=s.length;i>r;r++)if(n=s[r],n.name===t.name&&n.value===t.value)return n}}.call(this),function(){var e,t,n;n=require("github/fetch"),e=n.fetchJSON,t=n.fetchPoll,$(document).on("change",".js-issues-list-check",function(){$("#js-issues-toolbar").toggleClass("triage-mode",$(".js-issues-list-check:checked").length>0)}),$(document).on("change",".js-issues-list-check",function(){var e;e=$(".js-issues-list-check:checked"),$("#js-issues-toolbar .js-issues-toolbar-triage .js-select-menu").data("contents-data",e).addClass("js-load-contents")}),$(document).on("selectmenu:selected",".js-issues-toolbar-triage .js-navigation-item",function(){var e,t,n,r,i,s;n=$(this).closest(".js-menu-container").hasClass("js-label-select-menu"),e=$(this).closest("form"),i=$(this).hasClass("selected"),r=$(this).attr("data-name"),s=$(this).attr("data-value"),t=n?$("",{type:"hidden",name:r+"["+s+"]",value:i?"1":"0"}):$("",{type:"hidden",name:r,value:i?s:""}),setImmediate(function(e){return function(){return $(e).menu("deactivate")}}(this)),e.find(".js-issues-triage-fields").append(t),e.addClass("will-submit")}),$(document).on("menu:deactivate",".js-issues-toolbar-triage .js-menu-container",function(n){var r,i;(r=this.querySelector("form.will-submit"))&&(this.classList.add("is-loading"),i=e(r.getAttribute("action"),{method:r.getAttribute("method"),body:$.param($(r).serializeArray()),headers:{"Content-Type":"application/x-www-form-urlencoded; charset=UTF-8"}}),i.then(function(e){return function(n){var r,i,s;return s=t(n.job.url,{headers:{accept:"application/json"}}),r=function(){return $(e).menu("deactivate"),location.reload()},i=function(){return e.classList.add("has-error")},s.then(r,i)}}(this)),r.classList.remove("will-submit"),n.preventDefault())})}.call(this),DateInput=function(e){function t(n,r){"object"!=typeof r&&(r={}),e.extend(this,t.DEFAULT_OPTS,r),this.input=e(n),this.bindMethodsToObj("show","hide","hideIfClickOutside","keydownHandler","selectDate"),this.build(),this.selectDate(),this.show(),this.input.hide(),this.input.data("datePicker",this)}return t.DEFAULT_OPTS={month_names:["January","February","March","April","May","June","July","August","September","October","November","December"],short_month_names:["Jan","Feb","Mar","Apr","May","Jun","Jul","Aug","Sep","Oct","Nov","Dec"],short_day_names:["Sun","Mon","Tue","Wed","Thu","Fri","Sat"],start_of_week:1},t.prototype={build:function(){var t=e('

        \u25c0 \u25b6

        ');this.monthNameSpan=e(".month-name",t),e(".prev",t).click(this.bindToObj(function(){this.moveMonthBy(-1)})),e(".next",t).click(this.bindToObj(function(){this.moveMonthBy(1)}));var n=e('

        \u25c0 \u25b6

        ');this.yearNameSpan=e(".year-name",n),e(".prev",n).click(this.bindToObj(function(){this.moveMonthBy(-12)})),e(".next",n).click(this.bindToObj(function(){this.moveMonthBy(12)}));var r=e("
        ").append(t,n),i="";e(this.adjustDays(this.short_day_names)).each(function(){i+=""}),i+="
        "+this+"
        ",this.dateSelector=this.rootLayers=e('
        ').append(r,i).insertAfter(this.input),this.tbody=e("tbody",this.dateSelector),this.input.change(this.bindToObj(function(){this.selectDate()})),this.selectDate()},selectMonth:function(t){var n=new Date(t.getFullYear(),t.getMonth(),1);if(!this.currentMonth||this.currentMonth.getFullYear()!=n.getFullYear()||this.currentMonth.getMonth()!=n.getMonth()){this.currentMonth=n;for(var r=this.rangeStart(t),i=this.rangeEnd(t),s=this.daysBetween(r,i),o="",a=0;s>=a;a++){var c=new Date(r.getFullYear(),r.getMonth(),r.getDate()+a,12,0);this.isFirstDayOfWeek(c)&&(o+=""),o+=c.getMonth()==t.getMonth()?''+c.getDate()+"":''+c.getDate()+"",this.isLastDayOfWeek(c)&&(o+="")}this.tbody.empty().append(o),this.monthNameSpan.empty().append(this.monthName(t)),this.yearNameSpan.empty().append(this.currentMonth.getFullYear()),e(".selectable_day",this.tbody).mousedown(this.bindToObj(function(t){this.changeInput(e(t.target).attr("date"))})),e("td[date='"+this.dateToString(new Date)+"']",this.tbody).addClass("today"),e("td.selectable_day",this.tbody).mouseover(function(){e(this).addClass("hover")}),e("td.selectable_day",this.tbody).mouseout(function(){e(this).removeClass("hover")})}e(".selected",this.tbody).removeClass("selected"),e('td[date="'+this.selectedDateString+'"]',this.tbody).addClass("selected")},selectDate:function(e){"undefined"==typeof e&&(e=this.stringToDate(this.input.val())),e||(e=new Date),this.selectedDate=e,this.selectedDateString=this.dateToString(this.selectedDate),this.selectMonth(this.selectedDate)},resetDate:function(){e(".selected",this.tbody).removeClass("selected"),this.changeInput("")},changeInput:function(e){this.input.val(e).change(),this.hide()},show:function(){this.rootLayers.css("display","block"),e([window,document.body]).click(this.hideIfClickOutside),this.input.unbind("focus",this.show),this.rootLayers.keydown(this.keydownHandler),this.setPosition()},hide:function(){},hideIfClickOutside:function(e){e.target==this.input[0]||this.insideSelector(e)||this.hide()},insideSelector:function(t){return $target=e(t.target),$target.parents(".date_selector").length||$target.is(".date_selector")},keydownHandler:function(e){switch(e.keyCode){case 9:case 27:return void this.hide();case 13:this.changeInput(this.selectedDateString);break;case 33:this.moveDateMonthBy(e.ctrlKey?-12:-1);break;case 34:this.moveDateMonthBy(e.ctrlKey?12:1);break;case 38:this.moveDateBy(-7);break;case 40:this.moveDateBy(7);break;case 37:this.moveDateBy(-1);break;case 39:this.moveDateBy(1);break;default:return}e.preventDefault()},stringToDate:function(e){var t;return(t=e.match(/^(\d{1,2}) ([^\s]+) (\d{4,4})$/))?new Date(t[3],this.shortMonthNum(t[2]),t[1],12,0):null},dateToString:function(e){return e.getDate()+" "+this.short_month_names[e.getMonth()]+" "+e.getFullYear()},setPosition:function(){var e=this.input.offset();this.rootLayers.css({top:e.top+this.input.outerHeight(),left:e.left}),this.ieframe&&this.ieframe.css({width:this.dateSelector.outerWidth(),height:this.dateSelector.outerHeight()})},moveDateBy:function(e){var t=new Date(this.selectedDate.getFullYear(),this.selectedDate.getMonth(),this.selectedDate.getDate()+e);this.selectDate(t)},moveDateMonthBy:function(e){var t=new Date(this.selectedDate.getFullYear(),this.selectedDate.getMonth()+e,this.selectedDate.getDate());t.getMonth()==this.selectedDate.getMonth()+e+1&&t.setDate(0),this.selectDate(t)},moveMonthBy:function(e){var t=new Date(this.currentMonth.getFullYear(),this.currentMonth.getMonth()+e,this.currentMonth.getDate());this.selectMonth(t)},monthName:function(e){return this.month_names[e.getMonth()]},bindToObj:function(e){var t=this;return function(){return e.apply(t,arguments)}},bindMethodsToObj:function(){for(var e=0;e1?void 0:e(this.closest(".js-notification"))}),$(document).on("ajaxSuccess",".js-delete-notification",function(){return e(this.closest(".js-notification"))}),$(document).on("ajaxSuccess",".js-mute-notification",function(){var t;return e(this.closest(".js-notification")),t=this.closest(".js-notification"),t.classList.contains("muted")?this.action=this.action.replace("unmute","mute"):this.action=this.action.replace("mute","unmute"),t.classList.toggle("muted")}),$(document).on("ajaxSuccess",".js-unmute-notification",function(){var e;return e=this.closest(".js-notification"),e.classList.contains("muted")?this.action=this.action.replace("unmute","mute"):this.action=this.action.replace("mute","unmute"),e.classList.toggle("muted")}),$(document).on("ajaxSuccess",".js-mark-visible-as-read",function(){var e,t,n,r,i,s,o;for(e=this.closest(".js-notifications-browser"),i=e.querySelectorAll(".unread"),n=0,r=i.length;r>n;n++)t=i[n],t.classList.remove("unread"),t.classList.add("read");return null!=(s=e.querySelector(".js-mark-visible-as-read"))&&s.classList.add("mark-all-as-read-confirmed"),null!=(o=e.querySelector(".js-mark-as-read-confirmation"))?o.classList.add("mark-all-as-read-confirmed"):void 0}),$(document).on("ajaxSuccess",".js-mark-remaining-as-read",function(){var e,t,n;return e=this.closest(".js-notifications-browser"),null!=(t=e.querySelector(".js-mark-remaining-as-read"))&&t.classList.add("hidden"),null!=(n=e.querySelector(".js-mark-remaining-as-read-confirmation"))?n.classList.remove("hidden"):void 0}),$(document).on("navigation:keydown",".js-notification",function(e){switch(e.hotkey){case"I":case"e":case"y":return $(this).find(".js-delete-notification").submit(),!1;case"M":case"m":return $(this).find(".js-mute-notification").submit(),!1}}),$(document).on("navigation:keyopen",".js-notification",function(t){return e(this)}),$(document).on("ajaxSend",".js-notifications-subscription",function(){return this.querySelector(".js-spinner").classList.remove("hidden")}),$(document).on("ajaxComplete",".js-notifications-subscription",function(){return this.querySelector(".js-spinner").classList.add("hidden")})}.call(this),function(){$(document).on("ajaxSend",".js-auto-subscribe-toggle",function(){return $(this).find(".js-status-indicator").removeClass("status-indicator-success").removeClass("status-indicator-loading").addClass("status-indicator-loading")}),$(document).on("ajaxError",".js-auto-subscribe-toggle",function(){return $(this).find(".js-status-indicator").removeClass("status-indicator-loading").addClass("status-indicator-failed")}),$(document).on("ajaxSuccess",".js-auto-subscribe-toggle",function(){return $(this).find(".js-status-indicator").removeClass("status-indicator-loading").addClass("status-indicator-success")}),$(document).on("ajaxSend",".js-unignore-form, .js-ignore-form",function(){return $(this).closest(".js-subscription-row").addClass("loading")}),$(document).on("ajaxError",".js-unignore-form, .js-ignore-form",function(){return $(this).closest(".js-subscription-row").removeClass("loading"),$(this).find(".btn-sm").addClass("btn-danger").attr("title","There was a problem unignoring this repo.")}),$(document).on("ajaxSuccess",".js-unignore-form",function(){return $(this).closest(".js-subscription-row").removeClass("loading").addClass("unsubscribed")}),$(document).on("ajaxSuccess",".js-ignore-form",function(){return $(this).closest(".js-subscription-row").removeClass("loading unsubscribed")}),$(document).on("ajaxSend",".js-unsubscribe-form, .js-subscribe-form",function(){return $(this).closest(".js-subscription-row").addClass("loading")}),$(document).on("ajaxError",".js-unsubscribe-form, .js-subscribe-form",function(){return $(this).closest(".js-subscription-row").removeClass("loading"),$(this).find(".btn-sm").addClass("btn-danger").attr("title","There was a problem with unsubscribing :(")}),$(document).on("ajaxSuccess",".js-unsubscribe-form",function(){return $(this).closest(".js-subscription-row").removeClass("loading").addClass("unsubscribed")}),$(document).on("ajaxSuccess",".js-subscribe-form",function(){return $(this).closest(".js-subscription-row").removeClass("loading unsubscribed")}),$(document).on("ajaxSuccess",".js-thread-subscription-status",function(e,t,n,r){return $(".js-thread-subscription-status").updateContent(r)})}.call(this),function(){var e,t,n,r,i;t=require("delegated-events").fire,$(document).on("ajaxSend",".js-toggler-container .js-set-approval-state",function(){return this.closest(".js-toggler-container").classList.add("loading")}),$(document).on("ajaxComplete",".js-toggler-container .js-set-approval-state",function(){return this.closest(".js-toggler-container").classList.remove("loading")}),$(document).on("ajaxSuccess",".js-toggler-container .js-set-approval-state",function(){return this.closest(".js-toggler-container").classList.add("on")}),$(document).on("ajaxSuccess",".js-request-approval-facebox-form",function(){var e;return e=this.getAttribute("data-container-id"),document.getElementById(e).classList.add("on"),t(document,"facebox:close")}),i=function(e){return e.querySelectorAll(".js-integrations-install-repo-picked .js-repository-picker-result").length},e=function(e){return i(e)>0},r=function(e){var t;return(t=+e.getAttribute("data-max-repos"))?i(e)>=t:void 0},n=function(t){var n;return n=t.querySelector(".js-all-repositories-radio"),n.checked||e(t)},$.observe(".js-integrations-install-form",function(){var e,t,i,s,o,a;o=this,s=o.querySelector(".js-integrations-install-form-submit"),e=o.querySelector(".js-autocomplete"),i=e.getAttribute("data-search-url"),t=o.querySelector(".js-autocomplete-field"),a=function(){return s.disabled=!n(this),t.disabled=r(this),o.querySelector(".flash").classList.toggle("hidden",!r(this))},this.addEventListener("change",a),a.call(this),$(document).on("click",".js-repository-picker-remove",function(){var e;return e=this.closest(".js-repository-picker-result"),e.remove(),a.call(o)}),$(document).on("focus",".js-integrations-install-repo-picker .js-autocomplete-field",function(){return document.querySelector(".js-select-repositories-radio").checked=!0,a.call(o)}),$(document).on("autocomplete:autocompleted:changed",".js-integrations-install-repo-picker",function(){var t,n,r,s,o;for(o=i,s=document.querySelectorAll(".js-integrations-install-repo-picked .js-selected-repository-field"),n=0,r=s.length;r>n;n++)t=s[n],o+=~o.indexOf("?")?"&":"?",o+=t.name+"="+encodeURIComponent(t.value);return e.setAttribute("data-search-url",o)}),$(document).on("autocomplete:result",".js-integrations-install-repo-picker",function(e,n){var r,i;return i=this.querySelector("#repo-result-"+n),r=o.querySelector(".js-integrations-install-repo-picked"),i.classList.remove("hidden"),r.insertBefore(i,r.firstChild),t.value="",o.querySelector(".js-autocomplete-results").innerHTML="",a.call(o)})})}.call(this),function(){$(document).on("submit",".org form[data-results-container]",function(){return!1})}.call(this),function(){var e,t;t=require("github/fetch").fetchText,e=function(){return $(".js-invitation-toggle-team:checked").visible()},$(document).on("click",".js-invitations-team-suggestions-view-all",function(){return t(this.href).then(function(t){return function(n){var r,i;return i=e().map(function(){return this.value}),r=$(t).closest("ul"),r.html(n),i.each(function(){return r.find(".js-invitation-toggle-team[value="+this+"]").prop("checked",!0)})}}(this)),!1})}.call(this),define("github/org-sidebar-stats",["exports","./number-helpers","./inflector"],function(e,t,n){function r(e){var r=arguments.length<=1||void 0===arguments[1]?"+":arguments[1],s=document.querySelector("."+e),o=s.parentNode.querySelector(".js-stat-label"),a=t.parseFormattedNumber(s.textContent),c=i(a,r);s.textContent=c,n.pluralizeNode(c,o)}function i(e,t){switch(t){case"+":return e+1;case"-":return e-1;default:return e}}Object.defineProperty(e,"__esModule",{value:!0}),e.updateStat=r}),function(){var e,t,n,r,i;i=require("github/org-sidebar-stats").updateStat,e=[],t=function(){var e,t,n;return e=$(".js-person-grid"),t=e.find(".js-org-person").has(".js-org-person-toggle:checked"),function(){var e,r,i;for(i=[],e=0,r=t.length;r>e;e++)n=t[e],i.push($(n).attr("data-id"));return i}().sort()},r=null,$(document).on("change",".js-org-person-toggle",function(n){var i,s,o,a;return i=$(".js-org-toolbar"),s=i.find(".js-member-selected-actions"),o=t(),a=o.length>0,JSON.stringify(o)!==JSON.stringify(e)?(e=o,i.find(".js-org-toolbar-select-all-label").toggleClass("has-selected-members",a),$(".js-member-not-selected-actions").toggleClass("hidden",a),s.toggleClass("hidden",!a),i.addClass("disabled"),null!=r&&r.abort(),r=$.ajax({url:s.attr("data-toolbar-actions-url"),data:{member_ids:o}}),r.done(function(e,t,n){return s.html(e)}),r.always(function(){return i.removeClass("disabled")})):void 0}),$(document).on("click",".js-member-remove-confirm-button",function(e){return e.preventDefault(),$.facebox(function(){var n;return n=$.ajax({url:$(e.target).attr("data-url"),data:{member_ids:t()}}),n.done(function(e){return $.facebox(e)})})}),$(document).on("click",".js-member-search-filter",function(){var e,t;return t=$(this).attr("data-filter"),e=$(".js-member-filter-field"),e.val(t+" "),e.focus(),e.trigger("throttled:input"),!1}),$(document).on("ajaxSend ajaxComplete",".js-add-team-member-or-repo-form",function(e){return this===e.target?this.classList.toggle("is-sending","ajaxSend"===e.type):void 0}),n=navigator.userAgent.match(/Macintosh/)?"meta":"ctrl",$(document).onFocusedKeydown(".js-add-team-member-or-repo-form .js-autocomplete-field",function(){return function(e){return"enter"===e.hotkey||e.hotkey===n+"+enter"?e.preventDefault():void 0}}),$(document).on("autocomplete:result",".js-bulk-add-team-form .js-autocomplete-field",function(e){var t,n;return n=$(this).data("autocompleted"),n.indexOf("/")>0?(t=this.form.action,$.sudo().then(function(){return $.facebox(function(){var e;return e=$.ajax({url:t,method:"post",data:{member:n}}),e.done(function(e){return $.facebox(e)})})}),e.stopPropagation()):void 0}),$(document).on("autocomplete:result",".js-add-team-member-or-repo-form",function(){return setImmediate(function(e){return function(){return $(e).submit()}}(this))}),$(document).on("ajaxSuccess",".js-add-team-member-or-repo-form",function(e,t){var n,r,s,o,a,c,u,l,d;try{l=JSON.parse(t.responseText)}catch(h){}if(l?(n=$(l.list_item_html),l.stat_count_class&&i(l.stat_count_class,"+")):n=$(t.responseText),r=$(".js-member-list"),this.querySelector(".js-autocomplete-field").value="",d=n.attr("data-login"))for(u=r.children(),s=0,a=u.length;a>s;s++)if(o=u[s],o.getAttribute("data-login")===d)return;return r.prepend(n),c=!r.children().length,r.closest(".js-org-section").toggleClass("is-empty",c),r.siblings(".js-subnav").addClass("subnav-bordered")}),$(document).on("ajaxSuccess",".js-remove-team-repository",function(e,t,n,r){var s,o,a,c;return o=$(this),s=o.closest(".js-org-section"),a=s.find(".js-org-list"),o.closest(".js-org-repo").remove(),c=!a.children().length,s.toggleClass("is-empty",c),c&&(a.removeClass("table-list-bordered"),a.siblings(".js-subnav").removeClass("subnav-bordered")),i("js-repositories-count","-")}),$(document).on("ajaxError",".js-add-team-member-or-repo-form, .js-remove-team-repository",function(e,t){var n,r,i;if(!/=l?(a.style.position="fixed",a.style.top=u+"px",a.style.left=s+"px",a.style.width="250px"):(a.style.position=n,a.style.top=r,a.style.left=e,a.style.width=i)},5),window.addEventListener("scroll",o),window.addEventListener("resize",o),s()):void 0})}.call(this),function(){var e,t;e=require("github/fetch").fetchText,$.observe(".js-rename-owners-team-input",function(){$(this).on("throttled:input",function(){var n,r,i;return n=this.form,r=this.value.trim().toLowerCase(),"owners"===r||""===r?t(!1,""):(n.classList.add("is-sending"),i=new URL(this.getAttribute("data-check-url"),window.location.origin).toString(),i+=-1===i.indexOf("?")?"?":"&",i+="name="+encodeURIComponent(r),e(i).then(function(e){var r;return e=e.trim(),r=""===e,n.classList.remove("is-sending"),t(r,e)}))})}),t=function(e,t){return document.querySelector(".js-rename-owners-team-button").classList.toggle("disabled",!e),document.querySelector(".js-rename-owners-team-errors").innerHTML=t,document.querySelector(".js-rename-owners-team-note").classList.toggle("hidden",""!==t)}}.call(this),function(){$(document).onFocusedInput(".js-new-organization-name",function(){var e;return(e=this.closest("dd").querySelector(".js-field-hint-name"))?function(){return"innerText"in e?e.innerText=this.value:e.textContent=this.value}:void 0}),$(document).on("ajaxSend",".js-org-list-item .js-org-remove-item",function(){return this.closest(".js-org-list-item").classList.add("hidden")}),$(document).on("ajaxSuccess",".js-org-list-item .js-org-remove-item",function(){return this.closest(".js-org-list-item").remove()}),$(document).on("ajaxError",".js-org-list-item .js-org-remove-item",function(){var e;return this.closest(".js-org-list-item").classList.remove("hidden"),(e=this.getAttribute("data-error-message"))?alert(e):void 0})}.call(this),function(){var e,t;$(document).on("click",".js-org-billing-plans .js-choose-plan",function(t){return e($(this).closest(".js-plan-row")),!1}),e=function(e){var n,r,i,s;return i=e.attr("data-name"),r=parseInt(e.attr("data-cost"),10),n=parseInt(null!=(s=e.attr("data-balance"))?s:"0",10),$(".js-org-billing-plans").find(".js-plan-row, .js-choose-plan").removeClass("selected"),e.find(".js-choose-plan").addClass("selected"),e.addClass("selected"),$(".js-plan").val(i),0===r&&0===n?$(".js-billing-section").addClass("has-removed-contents"):($(".js-billing-section").removeClass("has-removed-contents"),null!=e.attr("data-balance")?t(i):void 0)},t=function(e){return $(".js-plan-change-message").addClass("is-hidden"),$('.js-plan-change-message[data-name="'+e+'"]').removeClass("is-hidden")},$(function(){return $(".selected .js-choose-plan").click()})}.call(this),function(){var e;e=function(e){var t,n,r,i;n=e.selectors;for(r in n)i=n[r],$(r).text(i);return t=100===e.filled_seats_percent,$(".js-live-update-seats-percent").css("width",e.filled_seats_percent+"%"),$(".js-need-more-seats").toggleClass("hidden",!t),$(".js-add-team-member-or-repo-form").toggleClass("hidden",t)},$(document).on("ajaxSuccess",".js-per-seat-invite-field, .js-per-seat-invite .js-org-remove-item",function(t,n){return e(JSON.parse(n.responseText))})}.call(this),function(){$(document).on("click",".js-repo-search-filter",function(){var e,t,n,r,i;return t=$(this).attr("data-filter"),n=$(this).attr("data-negate"),e=$(".js-repo-filter-field"),r=e.val(),r.indexOf(n)>-1&&(r=r.replace(n,""),r=r.replace(/^\s*/,"")),-1===r.indexOf(t)&&(i=r&&r.match(/\s$/)?"":" ",e.val(r+(""+i+t+" ")),e.focus(),e.trigger("throttled:input")),$("body").removeClass("menu-active"),!1}),$.observe(".js-repository-fallback-search",function(){$(this).on("keypress",function(e){var t,n,r,i;if(13===e.which)return t=$(this),n=t.attr("data-host"),r=t.attr("data-org"),i=t.val(),document.location="http://"+n+"/search?q=user%3A"+r+"+"+i+"&type=Repositories"})}),$(document).on("click",".js-team-repo-higher-access",function(e){return e.preventDefault(),$.facebox(function(){var t;return t=$.ajax({url:$(e.target).attr("data-url")}),t.done(function(e){return $.facebox(e)})})})}.call(this),$(document).on("selectmenu:selected",".js-select-repo-permission",function(){return $(this).submit()}),$(document).on("ajaxSend",".js-select-repo-permission",function(){return this.classList.remove("was-successful")}),$(document).on("ajaxSuccess",".js-select-repo-permission",function(e,t,n,r){var i;return this.classList.add("was-successful"),null!=(i=this.closest(".js-org-repo"))?i.classList.toggle("with-higher-access",r.members_with_higher_access):void 0}),function(){$(document).on("click",".js-change-default-repository-permission-confirm",function(e){e.preventDefault(),$(document).find(".js-change-default-repository-permission-form").submit()})}.call(this),function(){$(document).on("autocomplete:autocompleted:changed",".js-team-add-user-name",function(e){var t;return t=$(".js-team-add-user-button")[0],t.disabled=!$(this).data("autocompleted")}),$(document).on("click",".js-team-remove-user",function(e){var t,n;return e.preventDefault(),$(".js-team-add-user-form").removeClass("hidden"),$(".js-team-add-user-name").focus(),t=$(this).closest("li").remove(),n=t.attr("data-login")}),$(document).on("click",".js-team-add-user-button",function(e){var t,n,r,i,s,o;if(e.preventDefault(),n=$(".js-team-add-user-name"),o=n.val(),o&&n.data("autocompleted")){for(n.val(""),s=$(".js-team-user-logins li"),t=0,r=s.length;r>t;t++)if(i=s[t],$(i).attr("data-login")===o)return;return $.sudo().then(function(){return $.ajax({url:$(".js-team-add-user-form").attr("data-template-url"),data:{member:o},success:function(e){return $(".js-team-user-logins").append(e),$(".js-login-field").prop("disabled",!1),$(".js-team-add-user-form").addClass("hidden")}}),$(".js-team-add-user-name").focus()})}})}.call(this),function(){$(document).on("ajaxSend",".js-ldap-import-groups-container",function(e,t,n){return t.setRequestHeader("X-Context","import")}),$(document).on("autocomplete:autocompleted:changed",".js-team-ldap-group-field",function(e){var t;(t=this.closest(".js-ldap-group-adder"))&&(t.classList.remove("is-exists"),t.querySelector(".js-ldap-group-adder-button").disabled=!$(this).data("autocompleted"))}),$(document).on("navigation:open",".js-team-ldap-group-autocomplete-results .js-navigation-item",function(){var e,t;return e=$(this).closest(".js-ldap-group-adder"),t=$(this).attr("data-dn"),e.find(".js-team-ldap-dn-field").val(t),$(this).closest(".js-ldap-import-groups-container").find(".js-ldap-group-dn").map(function(n,r){$(r).text()===t&&(e.addClass("is-exists"),e[0].querySelector(".js-ldap-group-adder-button").disabled=!0)})}),$(document).on("ajaxSend",".js-import-container",function(e,t,n){this.classList.add("is-importing"),this.querySelector(".js-ldap-group-adder-button").disabled=!0}),$(document).on("ajaxComplete",".js-import-container",function(e,t,n){return $(this).removeClass("is-importing")}),$(document).on("ajaxSuccess",".js-ldap-group-adder",function(e,t,n,r){return $(this).closest(".js-ldap-import-groups-container").removeClass("is-empty").find(".js-ldap-imported-groups").prepend($(r)),this.reset(),$(this).find(".js-team-ldap-group-field").focus(),this.querySelector(".js-ldap-group-adder-button").disabled=!0,$(".js-import-form-actions").removeClass("hidden")}),$(document).on("submit",".js-team-remove-group",function(e){this.closest(".js-team").classList.add("is-removing"),document.querySelector(".js-team-ldap-group-field").focus()}),$(document).on("ajaxSuccess",".js-team-remove-group",function(){this.closest(".js-team").remove(),document.querySelector(".js-team:not(.is-removing)")||(document.querySelector(".js-ldap-import-groups-container").classList.add("is-empty"),document.querySelector(".js-import-form-actions").classList.add("hidden"))}),$(document).on("ajaxError",".js-team-remove-group",function(){this.closest(".js-team").classList.remove("is-removing")}),$(document).on("click",".js-edit-team",function(e){return $(this).closest(".js-team").hasClass("is-removing")?!1:(e.preventDefault(),$(this).closest(".js-team").addClass("is-editing"),$(this).closest(".js-team").find(".js-team-name-field").focus())}),$(document).on("click",".js-save-button",function(){return $(this).hasClass("disabled")?!1:$(this).closest(".js-team").addClass("is-sending")}),$(document).on("click",".js-cancel-team-edit",function(e){var t,n;return e.preventDefault(),n=$(this).closest(".js-team").removeClass("is-editing"),t=n.find(".js-team-form").removeClass("is-exists"),t.find(".js-slug").text(t.find(".js-slug").attr("data-original-slug")),t[0].reset()}),$(document).on("ajaxSuccess",".js-team-form:not(.is-checking)",function(e,t,n,r){return t.nameCheck?void 0:$(this).closest(".js-team").removeClass("is-editing").replaceWith($(r))}),$(document).on("ajaxSuccess",".js-team-form.is-checking",function(e,t,n,r){var i,s;return i=$(this).removeClass("is-checking"),"function"==typeof(s=i.find(".js-team-name-field")).removeData&&s.removeData("autocheck-xhr"),r.error?(i.find(".js-save-button").addClass("disabled"),"exists"===r.error?(i.addClass("is-exists"),i.find(".js-slug").html(r.slug)):void 0):(i.find(".js-slug").html(r.slug),i.find(".js-save-button").removeClass("disabled"))}),$(document).on("ajaxError",".js-team-form",function(e,t,n,r){return t.nameCheck&&"abort"===t.statusText?!1:void 0}),$.observe(".js-team-name-field",function(){$(this).on("throttled:input",function(){var e,t,n,r;return t=$(this),e=t.closest(".js-team-form"),null!=(n=t.data("autocheck-xhr"))&&n.abort(),e.removeClass("is-exists").addClass("is-checking"),e.find(".js-save-button").addClass("disabled"),r=$.ajax({url:t.attr("data-check-url"),type:"GET",context:this,data:{name:this.value}}),r.nameCheck=!0,t.data("autocheck-xhr",r)})})}.call(this),function(){$(document).on("click",".js-show-own-teams",function(){var e,t,n,r;return e=$(".js-team-search-field"),r=e.val(),n=$(this).attr("data-me"),-1===r.indexOf("@"+n)&&(t=r?" ":"",e.val(""+r+t+"@"+n),e.focus(),e.trigger("throttled:input")),!1})}.call(this),function(){var e,t;t=require("github/fetch").fetchText,e=function(e){var n,r,i;r=e.value.trim(),n=e.form,n.classList.add("is-sending"),n.classList.remove("is-name-check-fail"),n.classList.remove("is-name-check-success"),i=new URL(e.getAttribute("data-check-url"),window.location.origin).toString(),i+=-1===i.indexOf("?")?"?":"&",i+="name="+encodeURIComponent(r),t(i).then(function(t){var i,s,o,a,c;return n.classList.remove("is-sending"),n.querySelector(".js-team-name-errors").innerHTML=t||"",o=null!=(a=e.getAttribute("data-original"))?a.trim():void 0,s=o&&r===o,i=!!n.querySelector(".js-error"),c=(i||!r)&&!s,n.querySelector(".js-create-team-button").disabled=c,n.classList.toggle("is-name-check-fail",i),n.classList.toggle("is-name-check-success",!i&&r)})},$.observe(".js-new-team",function(){$(this).on("throttled:input",function(){return e(this)})}),$.observe(".js-new-org-team",function(){var t;t=this.querySelector(".js-new-team"),t.value&&e(t)})}.call(this),function(){var e,t,n;e=require("github/fetch").fetch,n=require("github/org-sidebar-stats").updateStat,t=require("delegated-events").fire,$(document).on("submit",".js-remove-team-members-form",function(){return $.sudo().then(function(t){return function(){var r;return r=$(t),e(r.attr("action"),{method:"post",body:r.serialize(),headers:{"Content-Type":"application/x-www-form-urlencoded; charset=UTF-8"}}).then(function(){var e;return e=r.closest(".js-org-section"),r.closest(".js-edit-team-member").remove(),e.toggleClass("is-empty",!e.find(".js-org-list").children().length),n("js-members-count","-")})}}(this)),!1}),$(document).on("click",".js-team-description-toggle",function(){return $(".js-description-toggler").toggleClass("on")}),$(document).on("ajaxComplete",".js-team-description-form",function(){var e;return e=$(".js-team-description-field").val(),$(".js-description-toggler").toggleClass("on"),e.trim()?$(".js-team-description .description").text(e):$(".js-team-description .description").html("This team has no description")}),$(document).on("ajaxSuccess",".js-add-team-members-form",function(e,n,r,i){var s;return s=$(document).find(".js-member-listings-container"),t(document,"facebox:close"),s.html(n.responseText)}),$(document).on("click",".js-rename-owners-team-next-btn",function(){return document.querySelector(".js-rename-owners-team-about-content").classList.toggle("migrate-owners-content-hidden"),document.querySelector(".js-rename-owners-team-rename-form").classList.toggle("migrate-owners-content-hidden")})}.call(this),function(){$.observe(".js-org-transform-poller",function(){var e;e=this.getAttribute("data-redirect-url"),this.addEventListener("load",function(){return window.location.href=e})})}.call(this),function(){$(function(){var e;return $("#load-readme").click(function(){var t,n,r,i,s,o;return n=$("#gollum-editor-body"),t=$("#editor-body-buffer"),i=$("#undo-load-readme"),o=t.text(),e(n,t),r=$(this),r.prop("disabled",!0),r.text(r.attr("data-readme-name")+" loaded"),i.show(),s=function(){return $(this).val()!==o&&i.hide(),n.off("change keyup",s)},n.on("change keyup",s),!1}),$("#undo-load-readme").click(function(){var t;return e($("#gollum-editor-body"),$("#editor-body-buffer")),t=$("#load-readme"),t.prop("disabled",!1),t.text("Load "+t.attr("data-readme-name")),$(this).hide(),!1}),e=function(e,t){var n,r,i;return n=$(e),r=$(t),i=n.val(),n.val(r.text()),r.text(i)}})}.call(this),function(){function e(e,t){var n=e.querySelector("table.timeline-commits > tbody"),r=t.querySelectorAll("table.timeline-commits > tbody > tr.commit");Array.from(r).forEach(function(e){n.appendChild(e)}),t.remove()}var t=".discussion-item.discussion-commits + .discussion-item.discussion-commits";$.observe(".discussion-item.discussion-commits",{add:function(){var n=document.querySelectorAll(t);Array.from(n).forEach(function(t){t.querySelector(".discussion-item-header")||e(t.previousElementSibling,t)})}})}(),$(document).on("click",".js-merge-branch-action",function(e){var t,n;n=$(this),t=n.closest(".js-merge-pr"),n.fire("details:toggle",{relatedTarget:e.target},function(){}),t.performTransition(function(){this.toggleClass("open"),this.fire("details:toggled",{relatedTarget:e.target,async:!0})}),e.preventDefault()}),function(){$(document).on("details:toggled",".js-pull-merging",function(){var e;return e=$(this).find(".js-merge-pull-request"),e.toggleClass("is-dirty",e.is($.visible))}),$(document).on("ajaxSuccess",".js-merge-pull-request",function(e,t,n,r){var i,s,o;this.reset(),$(this).removeClass("is-dirty"),s=r.updateContent;for(o in s)i=s[o],$(o).updateContent(i)}),$(document).on("session:resume",function(e){var t,n;return(n=document.getElementById(e.targetId))?(t=$(n).closest(".js-merge-pull-request"),t.closest(".js-details-container").addClass("open")):void 0}),$(document).on("change",".js-merge-button-toggle",function(){var e,t,n;return t=this.closest(".js-merge-pr"),n=!this.checked,e=t.querySelector(".js-merge-commit-button"),e.disabled=n})}.call(this),function(){var e;e=require("github/fetch").fetchText,$(document).on("ajaxError",".js-handle-pull-merging-errors",function(e,t){var n,r,i;return n=this.closest(".js-pull-merging"),n.classList.add("is-error"),422===t.status&&(i=t.responseText)&&(r=n.querySelector(".js-pull-merging-error"),$(r).replaceWith(i)),!1}),$(document).on("click",".js-pull-merging-refresh",function(){var t,n;return t=this.closest(".js-pull-merging"),n=t.getAttribute("data-url"),e(n).then(function(e){return $(t).replaceWith(e)}),!1})}.call(this),function(){var e;$.observeLast(".pull-request-ref-restore","last"),e=function(){var e;return e=$("#js-pull-restorable").length,$(".js-pull-discussion-timeline").toggleClass("is-pull-restorable",e)},$.observe("#js-pull-restorable",{add:e,remove:e})}.call(this),function(){var e,t,n,r,i;t=require("delegated-events"),n=require("github/fetch").fetchText,i=require("github/history").replaceState,r=require("github/pjax"),e=function(e){var t;return t=e.getAttribute("data-container-id"),document.getElementById(t)},t.on("pjax:click",".js-pull-request-tab",function(t){var n;return n=t.detail.options,e(this)?t.preventDefault():(n.push=!1,n.replace=!0)}),$(document).on("click",".js-pull-request-tab",function(t){var n,s,o,a,c,u;if(1===t.which&&!t.metaKey&&!t.ctrlKey&&(n=e(this))){for(c=$(".js-pull-request-tab.selected"),o=0,a=c.length;a>o;o++)u=c[o],$(u).removeClass("selected"),$(e(u)).removeClass("is-visible");return $(n).addClass("is-visible"),$(this).addClass("selected").blur(),s=$(this).attr("data-tab"),$(".js-pull-request-tab-container").attr("data-tab",s),i(r.getState(),"",this.href),!1}}),$(document).on("ajaxSuccess","#discussion_bucket .js-inline-comment-form, #discussion_bucket .js-pull-request-review-comment-form",function(){return $("#files_bucket").remove()}),$(document).on("ajaxSuccess","#files_bucket .js-inline-comment-form, #files_bucket .js-pull-request-review-comment-form",function(){return $("#discussion_bucket").remove()}),$(document).on("socket:message",".js-pull-request-tabs",function(){n(this.getAttribute("data-url")).then(function(e){return function(t){var n,r,i,s,o,a,c,u,l,d,h;for(c=document.createDocumentFragment(),u=$.parseHTML(t),r=0,o=u.length;o>r;r++)n=u[r],c.appendChild(n);for(l=["#commits_tab_counter","#files_tab_counter","#diffstat"],h=[],s=0,a=l.length;a>s;s++)i=l[s],h.push(null!=(d=e.querySelector(i))?d.replaceWith(c.querySelector(i)):void 0);return h}}(this))})}.call(this),function(){var e,t,n,r,i,s,o,a,c;t=require("github/fetch").fetchJSON,i=require("github/history").replaceState,n=require("github/pjax"),$(document).on("click",".js-timeline-tags-expander",function(){return $(this).closest(".js-timeline-tags").removeClass("is-collapsed")}),s=["is-default","is-saving","is-saved","is-failed"],o=function(e,t){var n;return(n=e.classList).remove.apply(n,s),e.classList.add(t),e.disabled="is-saving"===t},$(document).on("click",".js-save-draft",function(){var e,n,r,i;return e=this,i=e.closest("form"),i.querySelector("#release_draft").value="1",n=function(t){return o(e,"is-saved"),setTimeout(function(){return o(e,"is-default")},5e3),i.dispatchEvent(new CustomEvent("release:saved",{bubbles:!0,cancelable:!1,detail:{release:t}}))},r=function(){return o(e,"is-failed")},t(i.action,{method:i.method,body:$(i).serialize(),headers:{"Content-Type":"application/x-www-form-urlencoded; charset=UTF-8"}}).then(n,r),o(e,"is-saving"),!1}),$(document).on("release:saved",".js-release-form",function(e){var t,s,o,a,c,u,l;return a=e.originalEvent.detail.release,o=this,u=o.getAttribute("data-repo-url"),l=r("tag",u,a.tag_name),s=r("edit",u,a.tag_name),o.setAttribute("action",l),i(n.getState(),document.title,s),(t=document.querySelector("#delete_release_confirm form"))&&t.setAttribute("action",l),c=o.querySelector("#release_id"),c.value?void 0:(c.value=a.id,$(o).append(''))}),$(document).on("click",".js-publish-release",function(e){return $("#release_draft").val("0")}),c=["is-loading","is-empty","is-valid","is-invalid","is-duplicate","is-pending"],a=function(e){var t;switch(e){case"is-valid":$(".release-target-wrapper").addClass("hidden");break;case"is-loading":break;default:$(".release-target-wrapper").removeClass("hidden")}return t=$(".js-release-tag"),t.removeClass(c.join(" ")),t.addClass(e)},e=function(e){return e.val()&&e.val()!==e.data("last-checked")?(a("is-loading"),$.ajax({url:e.attr("data-url"),type:"GET",data:{tag_name:e.val()},dataType:"json",success:function(t){return"duplicate"===t.status&&parseInt(e.attr("data-existing-id"))===parseInt(t.release_id)?void a("is-valid"):($(".js-release-tag .js-edit-release-link").attr("href",t.url),a("is-"+t.status))},error:function(e){return a("is-invalid")},complete:function(){return e.data("last-checked",e.val())}})):void 0},r=function(e,t,n){return t+"/releases/"+e+"/"+n},$(document).on("blur",".js-release-tag-field",function(t){return e($(this))}),$.observe(".js-release-tag-field",function(){e($(this))}),$(document).on("change",".js-release-tag",function(){var e,t,n,r,i,s,o,a,c;if(n=$(this),e=n.closest("form"),t=e.find(".js-previewable-comment-form"),t.length){for(r=t.data("base-preview-url"),r||(r=t.attr("data-preview-url"),r+=r.indexOf("?")>=0?"&":"?",t.data("base-preview-url",r)),i=[],c=n.find('input[name="release[tag_name]"], input[name="release[target_commitish]"]:checked'),s=0,a=c.length;a>s;s++)o=c[s],o.value&&i.push({name:o.name,value:o.value});return t.attr("data-preview-url",r+$.param(i))}}),$.observe(".js-release-form .js-previewable-comment-form",function(){$(this).closest("form").find(".js-release-tag").trigger("change")})}.call(this),function(){document.addEventListener("facebox:reveal",function(){var e;e=document.querySelector("#facebox .js-fork-select-fragment"),e&&e.setAttribute("src",e.getAttribute("data-url"))})}.call(this),function(){var e;e=require("github/pjax"),$(document).on("change",".js-pulse-period",function(t){var n;return n=$(t.target).attr("data-url"),e["default"]({url:n,container:"#js-repo-pjax-container"})})}.call(this),function(){var e,t,n=function(e,t){return function(){return e.apply(t,arguments)}};t=require("delegated-events"),e=function(){function e(){this.validate=n(this.validate,this),this.updateUpsell=n(this.updateUpsell,this),this.selectedPrivacyToggleElement=n(this.selectedPrivacyToggleElement,this),this.handlePrivacyChange=n(this.handlePrivacyChange,this),this.handleOwnerChange=n(this.handleOwnerChange,this),this.elements={ownerContainer:$(".js-owner-container"),iconPreviewPublic:$(".js-icon-preview-public"),iconPreviewPrivate:$(".js-icon-preview-private"),upgradeUpsell:$("#js-upgrade-container").hide(),upgradeConfirmationCheckbox:$(".js-confirm-upgrade"),upsells:$(".js-upgrade"),privacyToggles:$(".js-privacy-toggle"),privateRadio:$(".js-privacy-toggle[value=false]"),publicRadio:$(".js-privacy-toggle[value=true]"),repoNameField:$("input[type=text].js-repo-name"),form:$("#new_repository"),licenseContainer:$(".js-license-container"),suggestion:$(".js-reponame-suggestion")},this.current_login=$("input[name=owner]:checked").prop("value"),this.privateRepo=!1,this.changedPrivacyManually=!1,this.elements.ownerContainer.on("change","input[type=radio]",this.handleOwnerChange),this.elements.privacyToggles.on("change",function(e){return function(t){return e.handlePrivacyChange(t.targetElement,t)}}(this)),this.elements.upgradeUpsell.on("change input","input",this.validate),this.elements.form.on("repoform:validate",this.validate),this.elements.suggestion.on("click",function(e){return function(t){var n;return n=e.elements.repoNameField,n.val($(t.target).text()),n.trigger("change")}}(this)),this.handleOwnerChange(),this.validate()}return e.prototype.handleOwnerChange=function(){var e;return this.current_login=$("input[name=owner]:checked").prop("value"),this.elements.repoNameField.trigger("change"),e=this.elements.ownerContainer.find(".select-menu-item.selected"),this.changedPrivacyManually||("private"===e.attr("data-default")?this.elements.privateRadio.prop("checked","checked").change():this.elements.publicRadio.prop("checked","checked").change()),"yes"===e.attr("data-permission")?($(".with-permission-fields").show(),$(".without-permission-fields").hide(),$(".errored").show(),$("dl.warn").show()):($(".with-permission-fields").hide(),$(".without-permission-fields").show(),$(".errored").hide(),$("dl.warn").hide()),this.updateUpsell(),this.handlePrivacyChange()},e.prototype.handlePrivacyChange=function(e,t){var n;return null==e&&(e=this.selectedPrivacyToggleElement()),null==t&&(t=null),t&&!t.isTrigger&&(this.changedPrivacyManually=!0),n=this.elements.upgradeUpsell.find(".js-billing-section"),"false"===e.val()?(this.privateRepo=!0,this.elements.upgradeUpsell.show(),n.removeClass("has-removed-contents"),this.elements.upgradeUpsell.find("input[type=checkbox]").prop("checked","checked"),this.elements.iconPreviewPublic.hide(),this.elements.iconPreviewPrivate.show()):(this.privateRepo=!1,this.elements.upgradeUpsell.hide(),n.addClass("has-removed-contents"),this.elements.upgradeUpsell.find("input[type=checkbox]").prop("checked",null),this.elements.form.attr("action",this.elements.form.attr("data-url")),this.elements.iconPreviewPrivate.hide(),this.elements.iconPreviewPublic.show()),this.validate()},e.prototype.selectedPrivacyToggleElement=function(){return this.elements.privateRadio.is(":checked")?this.elements.privateRadio:this.elements.publicRadio},e.prototype.updateUpsell=function(){var e;return e=this.elements.upsells.filter("[data-login="+this.current_login+"]"),this.elements.upgradeUpsell.html(e)},e.prototype.validate=function(){var e,t;return t=!0,this.elements.repoNameField.is(".is-autocheck-successful")||(t=!1),e=this.elements.upgradeUpsell.find("input[type=checkbox]"),this.privateRepo&&e.length&&!e.is(":checked")&&(t=!1),this.elements.form.find("button.primary").prop("disabled",!t)},e}(),$(function(){return $(".page-new-repo").length?new e:void 0}),t.on("autocheck:send","#repository_name",function(e){var t,n,r;n=e.detail,t=$(this),r=t.closest("form").find("input[name=owner]:checked").val(),n.owner=r,t.trigger("repoform:validate")}),t.on("autocheck:complete","#repository_name",function(){return $(this).trigger("repoform:validate")}),t.on("autocheck:success","#repository_name",function(e){var t,n,r,i;(i=null!=(n=e.detail)?n.trim():void 0)&&(t=this.closest("dl.form"),t.classList.add("warn"),r=document.createElement("dd"),r.classList.add("warning"),r.innerHTML=i,t.append(r))})}.call(this),function(){document.addEventListener("pjax:end",function(){var e,t,n,r,i,s,o,a,c,u,l;if(l=$(document.head).find("meta[name='selected-link']").attr("value"),null!=l)for(n=$(".js-sidenav-container-pjax .js-selected-navigation-item").removeClass("selected"),e=0,i=n.length;i>e;e++)for(t=n[e],a=null!=(c=$(t).attr("data-selected-links"))?c:"",u=a.split(" "),r=0,s=u.length;s>r;r++)o=u[r],o===l&&$(t).addClass("selected")})}.call(this),$(document).on("socket:message",".js-repository-import-channel",function(e,t){$(e.target).text(JSON.stringify(t,void 0,2))}),function(){var e,t,n,r;e=require("github/fetch").fetch,n=function(){return document.body.classList.add("is-sending"),document.body.classList.remove("is-sent","is-not-sent")},r=function(){return document.body.classList.add("is-sent"),document.body.classList.remove("is-sending")},t=function(e){return e&&(document.querySelector(".js-sms-error").textContent=e),document.body.classList.add("is-not-sent"),document.body.classList.remove("is-sending")},$(document).on("ajaxSend",".js-send-auth-code",function(){n()}),$(document).on("ajaxSuccess",".js-send-auth-code",function(){r()}),$(document).on("ajaxError",".js-send-auth-code",function(e,n){t(n.responseText)}),$(document).on("click",".js-send-two-factor-code",function(){var i,s,o,a,c,u;o=this.form,i=o.querySelector(".js-country-code-select").value,c=o.querySelector(".js-sms-number").value,a=i+" "+c,u=o.querySelector(".js-two-factor-secret").value,n(),s=new FormData,s.append("number",a),s.append("two_factor_secret",u),s.append("authenticity_token",o.elements.authenticity_token.value),e(this.getAttribute("data-url"),{method:"post",body:s}).then(function(){var e,t,n,i;for(r(),i=o.querySelectorAll(".js-2fa-enable"),t=0,n=i.length;n>t;t++)e=i[t],e.disabled=!1;return o.querySelector(".js-2fa-otp").focus()})["catch"](function(e){var n,r,i,s,a,c;for(null!=(s=e.response)&&s.text().then(t),a=o.querySelectorAll(".js-2fa-enable"),c=[],r=0,i=a.length;i>r;r++)n=a[r],c.push(n.disabled=!0);return c})}),document.addEventListener("facebox:loading",function(){"/settings/two_factor_authentication/configure"===window.location.pathname&&($(".js-configure-sms-fallback .facebox-alert").text("").hide(),$(".js-configure-sms-fallback").show(),$(".js-verify-sms-fallback").hide())}),$(document).on("ajaxSuccess",".js-two-factor-set-sms-fallback",function(e,t){switch(t.status){case 200:case 201:return window.location.reload();case 202:return $(".js-configure-sms-fallback").hide(),$(".js-verify-sms-fallback").show(),$(".js-fallback-otp").focus()}}),$(document).on("ajaxError",".js-two-factor-set-sms-fallback",function(e,t){switch(t.status){case 422:return window.location.reload();case 429:return $(".js-configure-sms-fallback .facebox-alert").text(t.responseText).show(),!1}})}.call(this),function(){if(!("u2f"in window)&&"chrome"in window){var e,t=window.u2f={};t.EXTENSION_ID="kmendfapggjehodndflmmgagdbamhnfd",t.MessageTypes={U2F_REGISTER_REQUEST:"u2f_register_request",U2F_REGISTER_RESPONSE:"u2f_register_response",U2F_SIGN_REQUEST:"u2f_sign_request",U2F_SIGN_RESPONSE:"u2f_sign_response",U2F_GET_API_VERSION_REQUEST:"u2f_get_api_version_request",U2F_GET_API_VERSION_RESPONSE:"u2f_get_api_version_response"},t.ErrorCodes={OK:0,OTHER_ERROR:1,BAD_REQUEST:2,CONFIGURATION_UNSUPPORTED:3,DEVICE_INELIGIBLE:4,TIMEOUT:5},t.U2fRequest,t.U2fResponse,t.Error,t.Transport,t.Transports,t.SignRequest,t.SignResponse,t.RegisterRequest,t.RegisterResponse,t.RegisteredKey,t.GetJsApiVersionResponse,t.getMessagePort=function(e){if("undefined"!=typeof chrome&&chrome.runtime){var n={type:t.MessageTypes.U2F_SIGN_REQUEST,signRequests:[]};chrome.runtime.sendMessage(t.EXTENSION_ID,n,function(){chrome.runtime.lastError?t.getIframePort_(e):t.getChromeRuntimePort_(e)})}else t.isAndroidChrome_()?t.getAuthenticatorPort_(e):t.isIosChrome_()?t.getIosPort_(e):t.getIframePort_(e)},t.isAndroidChrome_=function(){var e=navigator.userAgent;return-1!=e.indexOf("Chrome")&&-1!=e.indexOf("Android")},t.isIosChrome_=function(){return $.inArray(navigator.platform,["iPhone","iPad","iPod"])>-1},t.getChromeRuntimePort_=function(e){var n=chrome.runtime.connect(t.EXTENSION_ID,{includeTlsChannelId:!0});setTimeout(function(){e(new t.WrappedChromeRuntimePort_(n))},0)},t.getAuthenticatorPort_=function(e){setTimeout(function(){e(new t.WrappedAuthenticatorPort_)},0)},t.getIosPort_=function(e){setTimeout(function(){e(new t.WrappedIosPort_)},0)},t.WrappedChromeRuntimePort_=function(e){this.port_=e},t.formatSignRequest_=function(n,r,i,s,o){if(void 0===e||1.1>e){for(var a=[],c=0;ce){for(var a=0;as;s++)r=a[s],r.classList.add("hidden");return document.querySelector(".js-u2f-login-waiting").classList.remove("hidden"),i=document.querySelector(".js-u2f-auth-form"),c=i.querySelector(".js-u2f-auth-response"),e=i.getAttribute("data-app-id"),t=i.getAttribute("data-challenge"),u=JSON.parse(i.getAttribute("data-sign-requests")),n(e,t,u).then(function(e){return c.value=JSON.stringify(e),i.submit()})["catch"](function(e){var t;return t=function(){switch(e.code){case 4:return".js-u2f-auth-not-registered-error";case 5:return".js-u2f-auth-timeout";default:return".js-u2f-auth-error"}}(),document.querySelector(t).classList.remove("hidden"),document.querySelector(".js-u2f-login-waiting").classList.add("hidden")})},$(document).on("click",".js-u2f-auth-retry",function(){r()}),$.observe(".js-u2f-auth-form",function(){r()})))}.call(this),function(){var e;e=function(e){var t;return t=$(".js-hosted-account-linker-hosted"),t.toggleClass("hidden","tenant"!==e.value)},$(document).on("change",".js-hosted-account-linker",function(){return e(this)}),$(function(){var t;return(t=$(".js-hosted-account-linker:checked")[0])?e(t):void 0})}.call(this),function(){var e;e=require("delegated-events").fire,$.observe(".js-email-global-unsubscribe-form",function(){this.querySelector(".js-email-global-unsubscribe-submit").disabled=!0}),$(document).on("change",".js-email-global-unsubscribe-form",function(){var e,t;return e=function(){var e,n,r,i;for(r=this.querySelectorAll(".js-email-global-unsubscribe"),i=[],e=0,n=r.length;n>e;e++)t=r[e],t.checked&&i.push(t);return i}.call(this),this.querySelector(".js-email-global-unsubscribe-submit").disabled=e[0].defaultChecked}),$(document).on("ajaxSend",".js-remove-key",function(e){return $(this).addClass("disabled").find("span").text("Deleting\u2026")}),$(document).on("ajaxError",".js-remove-key",function(e){return $(this).removeClass("disabled").find("span").text("Error. Try again.")}),$(document).on("ajaxSuccess",".js-remove-key",function(e){return $(this).parents("li").remove(),0===$(".js-ssh-keys-box li").length?$(".js-no-ssh-keys").show():void 0}),$(document).on("ajaxSend",".js-verify-key",function(e){return $(this).addClass("disabled").find("span").text("Verifying\u2026")}),$(document).on("ajaxError",".js-verify-key",function(e){return $(this).removeClass("disabled").find("span").text("Error. Try again.")}),$(document).on("ajaxSuccess",".js-verify-key",function(e){var t;return t=$(this).closest("li"),t.find(".ssh-key-verification-status").remove(),t.find(".ssh-key-state-indicator").removeClass("unverified").addClass("not-recent"),$(this).remove()}),$(document).on("ajaxSuccess",".js-leave-collaborated-repo",function(e){var t,n;t=e.target.getAttribute("data-repo-id"),n=document.querySelector(".js-collab-repo[data-repo-id='"+t+"']"),n.remove(),$.facebox.close()}),$(document).on("ajaxSuccess",".js-newsletter-unsubscribe-form",function(){var e,t,n,r,i;for(r=document.querySelectorAll(".js-newsletter-unsubscribe-message"),i=[],t=0,n=r.length;n>t;t++)e=r[t],i.push(e.classList.toggle("hidden"));return i}),$(document).on("click",".js-show-new-ssh-key-form",function(){return $(".js-new-ssh-key-box").toggle().find(".js-ssh-key-title").focus(),!1}),$(document).on("ajaxSuccess",".js-revoke-access-form",function(){var e,t,n;e=this.getAttribute("data-id"),n=this.getAttribute("data-type-name"),t=document.querySelector(".js-revoke-item[data-type='"+n+"'][data-id='"+e+"']"),$.facebox.close(),t.remove(),t.classList.contains("new-token")&&document.querySelector(".js-flash-new-token").remove()}),$(document).on("click",".js-delete-oauth-application-image",function(){var e,t;return e=$(this).closest(".js-uploadable-container"),t=e.closest("form"),t.append(''),t.append(''),t.submit(),!1}),$(document).on("click",".js-new-callback",function(e){var t,n;return e.preventDefault(),t=$(e.currentTarget).closest(".js-callback-urls"),n=t.find(".js-callback-url").first().clone(),n.removeClass("is-default-callback"),n.find("input").val(""),t.addClass("has-many"),$(e.currentTarget).before(n)}),$(document).on("click",".js-delete-callback",function(e){var t,n;return e.preventDefault(),t=$(e.currentTarget).closest(".js-callback-urls"),$(e.currentTarget).closest(".js-callback-url").remove(),n=t.find(".js-callback-url"),n.length<=1?t.removeClass("has-many"):void 0}),$(document).on("click",".js-oauth-application-whitelist .js-deny-this-request",function(e){return $(e.currentTarget).siblings("#state").val("denied"),$(e.currentTarget).closest(".js-org-application-access-form").submit()}),$(document).on("ajaxSuccess",".js-org-application-access-form",function(e,t,n,r){return window.location.reload()}),$(document).on("click",".js-user-rename-warning-continue",function(){var e,t,n,r,i;for(r=document.querySelectorAll(".js-user-rename-warning, .js-user-rename-form"),i=[],t=0,n=r.length;n>t;t++)e=r[t],i.push(e.classList.toggle("hidden"));return i}),$(document).on("change",".js-checkbox-scope",function(){var e,t,n,r,i,s;for(r=this.closest(".js-check-scope-container"),i=r.querySelectorAll(".js-checkbox-scope"),s=[],t=0,n=i.length;n>t;t++)e=i[t],e!==this?(e.checked=this.checked,s.push(e.disabled=this.checked)):s.push(void 0);return s}),$(document).on("click",".js-generate-integration-key",function(){var t;return e(document,"facebox:close"),t=document.querySelector(".js-integration-key-management-wrapper"),t.classList.add("downloading")})}.call(this),function(){var e,t,n,r,i,s,o,a,c,u,l,d,h,f,m,p=[].slice;i=require("github/feature-detection")["default"],s=require("github/fetch").fetchJSON,h=function(){var e;return e=1<=arguments.length?p.call(arguments,0):[],new Promise(function(t,n){return u2f.register.apply(u2f,p.call(e).concat([function(e){var r;return null!=e.errorCode&&0!==e.errorCode?(r=new Error("Device registration failed"),r.code=e.errorCode,n(r)):t(e)}]))})},(n=document.querySelector(".js-u2f-box"))&&(n.classList.toggle("available",i.u2f),a=function(e,t,n){return null!=n?e.setAttribute(t,JSON.stringify(n)):JSON.parse(e.getAttribute(t))},d=function(e){var t;return t=document.querySelector(".js-add-u2f-registration-form"),a(t,"data-sign-requests",e)},c=function(e){var t;return t=document.querySelector(".js-add-u2f-registration-form"),a(t,"data-register-requests",e)},o=document.querySelector(".js-add-u2f-registration-form"),e=o.getAttribute("data-app-id"),f=function(e){return e.register_requests&&c(e.register_requests),e.sign_requests?d(e.sign_requests):void 0},$(document).on("ajaxSend",".js-u2f-registration-delete",function(){return this.closest(".js-u2f-registration").classList.add("is-sending")}),$(document).on("ajaxSuccess",".js-u2f-registration-delete",function(e,t){return f(t.responseJSON),this.closest(".js-u2f-registration").remove()}),$(document).on("click",".js-add-u2f-registration-link",function(e){var t,n;return t=document.querySelector(".js-new-u2f-registration"),t.classList.add("is-active"),t.classList.remove("is-showing-error"),n=document.querySelector(".js-u2f-registration-nickname-field"),n.focus()}),t=function(e){var t;return n=document.createElement("div"),n.innerHTML=e,t=n.firstChild,document.querySelector(".js-u2f-registrations").appendChild(t)},r=function(e,t){var n,r,i,s,o;for(s=document.querySelector(".js-new-u2f-registration"),s.classList.add("is-showing-error"),s.classList.remove("is-sending"),o=s.querySelectorAll(".js-u2f-error"),r=0,i=o.length;i>r;r++)n=o[r],n.classList.add("hidden");return n=s.querySelector(e),null!=t&&(n.textContent=t),n.classList.remove("hidden")},u=function(){var e;return e=document.querySelector(".js-new-u2f-registration"),e.classList.remove("is-sending","is-active"),document.querySelector(".js-u2f-registration-nickname-field").value=""},l=function(e){return o=document.querySelector(".js-add-u2f-registration-form"),o.elements.response.value=JSON.stringify(e),s(o.action,{method:o.method,body:new FormData(o)}).then(function(e){return f(e),u(),t(e.registration)})["catch"](function(e){return null!=e.response?e.response.json().then(function(e){return f(e),r(".js-u2f-server-error",e.error)}):r(".js-u2f-network-error")})},m=function(){var t;return t=document.querySelector(".js-new-u2f-registration"),t.classList.add("is-sending"),t.classList.remove("is-showing-error"),h(e,c(),d()).then(l)["catch"](function(e){var t;return t=function(){switch(e.code){case 4:return".js-u2f-registered-error";case 5:return".js-u2f-timeout-error";default:return".js-u2f-other-error"}}(),r(t)})},$(document).on("click",".js-u2f-register-retry",function(){m()}),$(document).on("submit",".js-add-u2f-registration-form",function(e){return e.preventDefault(),m()}))}.call(this),$(document).on("ajaxSuccess",".js-user-sessions-revoke",function(){this.closest("li").remove()}),function(){$(function(){return $(".js-email-notice-trigger").focus(function(){return $(".js-email-notice").addClass("notice-highlight")}),$(".js-email-notice-trigger").blur(function(){return $(".js-email-notice").removeClass("notice-highlight")})}),$.observe(".js-plan-choice:checked",{add:function(){return $(this).closest(".plan-row").addClass("selected")},remove:function(){return $(this).closest(".plan-row").removeClass("selected")}}),$.observe(".js-plan-row.selected",{add:function(){var e;return e=$(this).find(".js-choose-button"),e.text(e.attr("data-selected-text"))},remove:function(){var e;return e=$(this).find(".js-choose-button"),e.text(e.attr("data-default-text"))}}),$.observe(".js-plan-row.free-plan.selected, .js-plan-choice-label.plan-choice-free.open",{add:function(){return $("#js-signup-billing-fields").addClass("has-removed-contents")},remove:function(){return $("#js-signup-billing-fields").removeClass("has-removed-contents")}}),$.observe(".js-setup-organization:checked",{add:function(){var e;return e=$(".js-choose-plan-submit"),e.attr("data-default-text")||e.attr("data-default-text",e.text()),e.text(e.attr("data-org-text"))},remove:function(){var e;return e=$(".js-choose-plan-submit"),e.text(e.attr("data-default-text"))}})}.call(this),function(){var e,t,n;e=function(e){var t;return t=$(".js-site-search-form")[0],t.setAttribute("action",t.getAttribute("data-global-search-url")),$(".js-site-search").removeClass("repo-scope"),e.setAttribute("placeholder",e.getAttribute("data-global-scope-placeholder"))},n=function(e){var t;return t=$(".js-site-search-form")[0],t.setAttribute("action",t.getAttribute("data-repo-search-url")),$(".js-site-search").addClass("repo-scope"),e.setAttribute("placeholder",e.getAttribute("data-repo-scope-placeholder"))},t=function(t){var r,i;r=t.target,i=r.value,""===i&&"backspace"===t.hotkey&&r.classList.contains("is-clearable")&&e(r),""===i&&"esc"===t.hotkey&&n(r),r.classList.toggle("is-clearable",""===i)},$(document).on("focus",".js-site-search-field",function(){return $(this).on("keyup",t)}),$(document).on("blur",".js-site-search-field",function(){return $(this).off("keyup",t)}),$(document).on("focusout",".js-site-search-focus",function(){this.closest(".js-chromeless-input-container").classList.remove("focus"),""===this.value&&this.classList.contains("js-site-search-field")&&n(this)}),$(document).on("focusin",".js-site-search-focus",function(){this.closest(".js-chromeless-input-container").classList.add("focus")})}.call(this),$.observe(".js-contact-javascript-flag",function(e){e.value="true"}),function(){var e,t;e=function(){var e;return e=$("#js-features-branch-diagram"),e.removeClass("preload"),e.find("path").each(function(e){var t,n,r;return $(this).is("#js-branch-diagram-branch")?r="stroke-dashoffset 3.5s linear 0.25s":$(this).is("#js-branch-diagram-master")?r="stroke-dashoffset 4.1s linear 0s":$(this).is("#js-branch-diagram-arrow")&&(r="stroke-dashoffset 0.2s linear 4.3s"),n=$(this).get(0),t=n.getTotalLength(),n.style.transition=n.style.WebkitTransition="none",n.style.strokeDasharray=t+" "+t,n.style.strokeDashoffset=t,n.getBoundingClientRect(),n.style.transition=n.style.WebkitTransition=r,n.style.strokeDashoffset="0"})},$(document).on("click",".js-segmented-nav-button",function(e){var t,n;return n=$(this).attr("data-selected-tab"),t=$(this).closest(".js-segmented-nav"),t.find(".js-segmented-nav-button").removeClass("selected"),t.siblings(".js-selected-nav-tab").removeClass("active"),$(this).addClass("selected"),$("."+n).addClass("active"),e.preventDefault()}),t=function(){return $(document).scrollTop()>=$("#js-features-branch-diagram").offset().top-700?e():void 0},$.observe("#js-features-branch-diagram.preload",{add:function(){return $(window).on("scroll",t)},remove:function(){return $(window).off("scroll",t)}})}.call(this),function(){$(document).on("socket:message",".js-notification-indicator",function(e,t){$(this).attr({"aria-label":t.aria_label,"data-ga-click":t.ga_click}),$("span",this).attr("class",t.span_class)})}(),function(){var e,t;e=require("github/fetch").fetchText,t=function(){var t;return t="/site/keyboard_shortcuts?url="+window.location.pathname,$.facebox(function(){return e(t).then(function(e){return $.facebox(e,"shortcuts")})})},$(document).on("click",".js-keyboard-shortcuts",function(){return t(),!1}),$(document).on("click",".js-see-all-keyboard-shortcuts",function(){return this.remove(),$(".facebox .js-hidden-pane").css("display","table-row-group"),!1}),$(document).on("keypress",function(e){return e.target===document.body&&63===e.which?($(".facebox").is($.visible)?$.facebox.close():t(),!1):void 0})}.call(this),function(){$.observe(".js-site-status-container",function(){var e,t,n,r,i;i=this,t=i.querySelector(".js-site-status-message"),n=i.querySelector(".js-site-status-time"),e=i.querySelector(".flash"),r=document.querySelector("meta[name=site-status-api-url]").content,window.fetch(r).then(function(e){return e.json()}).then(function(r){var s;return null!=r.status&&"good"!==r.status?(t.textContent=r.body,n.setAttribute("datetime",r.created_on),s="major"===r.status?"error":"warn",e.classList.add("flash-"+s),i.classList.remove("hidden")):void 0})})}.call(this),function(){$(document).on("ajaxSend",".js-action-ldap-create",function(){return $(this).find(".btn-sm").addClass("disabled")}),$(document).on("ajaxError",".js-action-ldap-create",function(e,t,n,r){return!1}),$(document).on("ajaxComplete",".js-action-ldap-create",function(e,t){var n,r;return n=$(this),r=500===t.status?"Oops, something went wrong.":t.responseText,n.find(".js-message").show().html(" – "+r),200===t.status&&n.find(".btn").hide(),!1})}.call(this),function(){var e;e=require("github/history").replaceState,location.search||location.hash||$(function(){var t,n,r;return t=null!=(n=document.getElementById("issues-dashboard"))?n:document.getElementById("issues_list"),(r=$(t).attr("data-url"))?e(null,document.title,r):void 0})}.call(this),function(){var e,t,n,r,i,s,o,a,c,u,l,d;r=require("delegated-events"),i=require("github/fetch").fetchJSON,u=require("github/fuzzy-filter"),c=u.fuzzySort,a=u.fuzzyRegexp,o=u.fuzzyHighlightElement,l=function(e){return setTimeout(function(){var t,n,r,i,s;for(i=document.querySelectorAll(".js-tree-finder-field"),s=[],n=0,r=i.length;r>n;n++)t=i[n],t.value=e,s.push(d(t));return s},0)},s=null,e=new WeakMap,d=function(t,n){var r,u,l,h,f,m,p,g,v,b,y,j,w,x;if(w=document.getElementById(t.getAttribute("data-results"))){if(!(m=e.get(w)))return void(null==s&&(s=i(w.getAttribute("data-url")).then(function(n){return e.set(w,n.paths),d(t),s=null})["catch"](function(){return s=null})));for(x=w.querySelector(".js-tree-browser-result-template").firstElementChild,b=w.querySelector(".js-tree-finder-results"),null==n&&(n=t.value),n?(p=a(n),j=c(m,n)):j=m,w.classList.toggle("filterable-empty",!j.length),l=document.createDocumentFragment(),g=j.slice(0,50),r=0,u=g.length;u>r;r++)y=g[r],v=x.cloneNode(!0),h=v.getElementsByClassName("js-tree-finder-path")[0],f=new URL(h.href),f.pathname=f.pathname+"/"+y,h.href=f.href,h.textContent=y,o(h,n,p),l.appendChild(v);b.innerHTML="",b.appendChild(l),$(b).navigation("focus")}},$(document).onFocusedKeydown(".js-tree-finder-field",function(e){return d(this),$(this).on("throttled:input."+e,function(){return d(this)}),function(e){return"esc"===e.hotkey?(history.back(),e.preventDefault()):void 0}}),t=function(){var e;return e=$("