(12) TŁUMACZENIE PATENTU EUROPEJSKIEGO (19) PL (11) PL/EP (96) Data i numer zgłoszenia patentu europejskiego:

Podobne dokumenty
Sieci komputerowe i bazy danych

Konfiguracja programu pocztowego Outlook Express i toŝsamości.

MODEL WARSTWOWY PROTOKOŁY TCP/IP

Lab5 - Badanie protokołów pocztowych

Bezpieczeństwo poczty elektronicznej

TCP/IP. Warstwa aplikacji. mgr inż. Krzysztof Szałajko

Konfiguracja poczty IMO w programach Microsoft Outlook oraz Mozilla Thunderbird

Instrukcja do panelu administracyjnego. do zarządzania kontem FTP WebAs.

Wykład 3 / Wykład 4. Na podstawie CCNA Exploration Moduł 3 streszczenie Dr inż. Robert Banasiak

Laboratorium 3.4.3: Usługi i protokoły

Internetowy moduł prezentacji WIZYT KLIENTA PUP do wykorzystania np. na stronie WWW. Wstęp

Sieci VPN SSL czy IPSec?

Komunikator internetowy w C#

ZESTAW PLATINUM. - instrukcja pobrania i instalacji certyfikatu niekwalifikowanego wersja 1.2

Instrukcja uŝytkownika narzędzia Skaner SMTP TP. Uruchamianie aplikacji

Obsługa poczty elektronicznej w domenie emeritus.ue.poznan.pl

Model sieci OSI, protokoły sieciowe, adresy IP

Klient poczty elektronicznej - Thunderbird

Manual konfiguracji konta dla fax2mail

Teoretyczne wprowadzenie do programu pocztowego Microsoft Outlook 2007

Instrukcja konfiguracji funkcji skanowania

Instrukcja konfigurowania poczty Exchange dla klienta pocztowego użytkowanego poza siecią uczelnianą SGH.

(12) TŁUMACZENIE PATENTU EUROPEJSKIEGO (19) PL (11) PL/EP (96) Data i numer zgłoszenia patentu europejskiego:

Protokoły sieciowe - TCP/IP

(12) TŁUMACZENIE PATENTU EUROPEJSKIEGO (19) PL (11) PL/EP (96) Data i numer zgłoszenia patentu europejskiego:

Instrukcja pobrania i instalacji. certyfikatu niekwalifikowanego na komputerze lub karcie kryptograficznej wersja 1.2

Java wybrane technologie

Instrukcja Instalacji i konfiguracji CELINA (e-podpis)

INSTRUKCJA KONFIGURACJI KLIENTA POCZTOWEGO

9. Internet. Konfiguracja połączenia z Internetem

Pomoc dla r.

Protokoły zdalnego logowania Telnet i SSH

1. Instalacja systemu Integra 7

systemów intra- i internetowych Platformy softwarowe dla rozwoju Architektura Internetu (2) Plan prezentacji: Architektura Internetu (1)

Certyfikat niekwalifikowany zaufany Certum Silver. Instrukcja dla uŝytkowników Windows Vista. wersja 1.1 UNIZETO TECHNOLOGIES SA

Konfiguracja programu MS Outlook 2007 dla poczty w hostingu Sprint Data Center

Instalacja programu Ozon.

Adres IP

System operacyjny UNIX Internet. mgr Michał Popławski, WFAiIS

REGULAMIN KORZYSTANIA Z INTERNETOWEGO SYSTEMU OBSŁUGI KLIENTÓW

Rys Rejestracja certyfikatu kwalifikowanego w programie Płatnik

Sieci komputerowe. Wykład dr inż. Łukasz Graczykowski

(12) TŁUMACZENIE PATENTU EUROPEJSKIEGO (19) PL (11) PL/EP (96) Data i numer zgłoszenia patentu europejskiego:

Manual konfiguracji konta dla fax2mail

ActiveXperts SMS Messaging Server

Internetowy serwis Era mail Aplikacja sieci Web

Konfiguracja programu pocztowego dla kont w domenie spcsk.pl

1 IMAP czy POP3? 2 Instalacja programu Mozilla Thunderbird

Program do obsługi ubezpieczeń minifort

Elektroniczna Skrzynka Podawcza

(12) TŁUMACZENIE PATENTU EUROPEJSKIEGO (19) PL (11) PL/EP (96) Data i numer zgłoszenia patentu europejskiego:

Wykład 5: Najważniejsze usługi sieciowe: DNS, SSH, HTTP, . A. Kisiel,Protokoły DNS, SSH, HTTP,

Konfiguracja poczty IMO dla urządzeń mobilnych z systemem ios oraz Android.

INSTRUKCJE UŻYTKOWNIKÓW

(12) TŁUMACZENIE PATENTU EUROPEJSKIEGO (19) PL (11) PL/EP (96) Data i numer zgłoszenia patentu europejskiego:

(12) TŁUMACZENIE PATENTU EUROPEJSKIEGO (19) PL (11) PL/EP (96) Data i numer zgłoszenia patentu europejskiego:

Poniżej znajduje się instrukcja konfiguracji najpopularniejszych programów do obsługi poczty.

Dr Michał Tanaś(

Wydział Informatyki, Elektroniki i Telekomunikacji Katedra Telekomunikacji

Wykład 2: Budowanie sieci lokalnych. A. Kisiel, Budowanie sieci lokalnych

Procedura uzyskania certyfikatu kwalifikowanego. Krok 3. Pobieranie certyfikatu kwalifikowanego wersja 1.5

Zdalna obsługa transcievera. H A M R A D I O D E L U X E R e m o t e S e r v e r C o n f i g u r a t i o n

Serwer SSH. Wprowadzenie do serwera SSH Instalacja i konfiguracja Zarządzanie kluczami

Przykładowa konfiguracja konta pocztowego w programie Outlook Express z wykorzystaniem MKS 2k7 (MS Windows 2000 Proessional)

Procedura uzyskania certyfikatu kwalifikowanego. Krok 3. Pobieranie certyfikatu kwalifikowanego wersja 1.8

INSTRUKCJA obsługi certyfikatów

Przykładowa konfiguracja konta pocztowego w programie Thunderbird z wykorzystaniem MKS 2k7 (MS Windows Vista Busissnes)

Wykorzystanie protokołu SCEP do zarządzania certyfikatami cyfrowymi w systemie zabezpieczeń Check Point NGX

Referencyjny model OSI. 3 listopada 2014 Mirosław Juszczak 37

SYSTEM Artur Maliszewski

Bezpieczny system poczty elektronicznej

SERWERY WIRTUALNE Stabilność, szybkość i bezpieczeństwo danych...

KONFIGURACJA KONTA POCZTOWEGO DO POBRANIA WIADOMOŚCI Z OBECNEGO SERWERA POCZTOWEGO. Zespół Systemów Sieciowych

IIIIIIIIIIIIIIIMMIMMIII

DESlock+ szybki start

Bazy Danych i Usługi Sieciowe

Współpraca z platformą Emp@tia. dokumentacja techniczna

Zdalne logowanie do serwerów

Połączenie VPN Host-LAN SSL z wykorzystaniem przeglądarki. 1. Konfiguracja serwera VPN 1.1. Ustawienia ogólne 1.2. Konto SSL 1.3. Grupa użytkowników

Zadanie1: Odszukaj w serwisie internetowym Wikipedii informacje na temat protokołu http.

Stos TCP/IP. Warstwa aplikacji cz.2

ZiMSK. Konsola, TELNET, SSH 1

1. FTP 2. SMTP 3. POP3

Konfiguracja programów pocztowych dla studenckiej poczty elektronicznej

Instrukcja obsługi certyfikatów w programie pocztowym MS Outlook Express 5.x/6.x

INSTRUKCJA OBSŁUGI KLIENTA POCZTY WWW

Teoria sieci komputerowych

INSTRUKCJA OBSŁUGI USTAWIEŃ DYNAMICZNIE PRZEDZIELANYCH ADRESÓW IP W URZĄDZENIACH SYSTEMU IP-PRO ORAZ REJESTRATORACH MY-DVR

Konfigurowanie konta pocztowego w programie Netscape (wersja 7.2)

Wszystkie parametry pracy serwera konfigurujemy w poszczególnych zakładkach aplikacji, podzielonych wg zakresu funkcjonalnego.

Podstawy Secure Sockets Layer

Manual konfiguracji aplikacji softphone dla usługi Biznes Pakiet

Tytuł: Instrukcja obsługi Modułu Komunikacji internetowej MKi-sm TK / 3001 / 016 / 002. Wersja wykonania : wersja oprogramowania v.1.

BeamYourScreen Bezpieczeństwo

Exchange Konfiguracja protokołu SSL/TLS w serwerze pocztowym Exchange wersja 1.0

Tomasz Greszata - Koszalin

Bramka IP 1 szybki start.

Bezpieczne strony WWW dla edukacji, organizacji non-profit i uŝytkowników indywidualnych.

Instrukcja instalacji usługi Sygnity Service

Uwaga!!! Autentykacja LDAP/AD zaimplementowana w Vigor wspiera tylko proste uwierzytelnianie (hasło przesyłane jest jawnym tekstem).

Transkrypt:

RZECZPOSPOLITA POLSKA (12) TŁUMACZE PATENTU EUROPEJSKIEGO (19) PL (11) PL/EP 217446 (96) Data i numer zgłoszenia patentu europejskiego: 24.07.08 0879396.8 (13) (1) T3 Int.Cl. H04L 12/8 (06.01) Urząd Patentowy Rzeczypospolitej Polskiej (97) O udzieleniu patentu europejskiego ogłoszono: 2.0.11 Europejski Biuletyn Patentowy 11/21 EP 217446 B1 (4) Tytuł wynalazku: Sposób i system przesyłania wiadomości elektronicznych () Pierwszeństwo: 2.07.07 PL 38299807.04.08 PL 3807608 (43) Zgłoszenie ogłoszono: 14.04. w Europejskim Biuletynie Patentowym nr /1 (4) O złożeniu tłumaczenia patentu ogłoszono: 31..11 Wiadomości Urzędu Patentowego 11/ (73) Uprawniony z patentu: Łukaszyk, Szymon, Katowice, PL PL/EP 217446 T3 (72) Twórca(y) wynalazku: SZYMON ŁUKASZYK, Katowice, PL DAWID JABŁOŃSKI, Siemianowice Śląskie, PL (74) Pełnomocnik: rzecz. pat. Szymon ŁUKASZYK Ul. Słonimskiego 1/ 40-133 Katowice Uwaga: W ciągu dziewięciu miesięcy od publikacji informacji o udzieleniu patentu europejskiego, każda osoba może wnieść do Europejskiego Urzędu Patentowego sprzeciw dotyczący udzielonego patentu europejskiego. Sprzeciw wnosi się w formie uzasadnionego na piśmie oświadczenia. Uważa się go za wniesiony dopiero z chwilą wniesienia opłaty za sprzeciw (Art. 99 (1) Konwencji o udzielaniu patentów europejskich).

- 1 - EP 2 174 46 B1 SPOSÓB I SYSTEM PRZESYŁANIA WIADOMOŚCI ELEKTRONICZNYCH 1 2 [0001] Przedmiotem wynalazku jest sposób i system przesyłania wiadomości elektronicznych za pośrednictwem sieci telekomunikacyjnej, a zwłaszcza sposób i system przesyłania internetowych wiadomości elektronicznych (e-mail) obejmujący etap utworzenia wiadomości przez nadawcę oraz etap autoryzacji nadawcy przez serwer autoryzacji nadawcy. [0002] Stosowane w niniejszym opisie terminy mają zdefiniowane bądź powszechnie przyjęte, podane poniŝej znaczenia: serwer oznacza program, komputer bądź urządzenie, połączone elektronicznie z innymi serwerami i przyjmujący komunikaty dla świadczenia określonych usług poprzez wysyłanie komunikatów zwrotnych, taki jak serwer plików, serwer baz danych, a zwłaszcza serwer pocztowy. serwer pocztowy (ang. Mail Transfer Agent - MTA) - serwer świadczący usługi przesyłania wiadomości elektronicznych. Przykładowe serwery pocztowe to programy Sendmail, Postfix, bądź MS Exchange Server. SMTP (ang. Simple Mail Transfer Protocol) - protokół komunikacyjny opisujący sposób przekazywania poczty elektronicznej w Internecie. POP3 (ang. Post Office Protocol version 3) - protokół komunikacyjny opisujący sposób odbioru poczty elektronicznej z serwera zdalnego do lokalnego. IMAP (ang. Internet Message Access Protocol) - internetowy protokół pocztowy zaprojektowany jako następca protokołu POP3. program pocztowy (ang. Mail User Agent - MUA) - program słuŝący uŝytkownikowi do wysyłania i/lub nadawania poczty elektronicznej. W przypadku wysyłania poczty program ten protokołem SMTP łączy się z serwerem pocztowym i przesyła mu wiadomości. W przypadku odbierania poczty program pocztowy łączy się z serwerem pocztowym i odbiera wiadomości korzystając na przykład z protokołu POP3 lub IMAP. Przykładowe programy pocztowe to aplikacje lokalne takie jak Mozilla Thunderbird, bądź MS Outlook Express, aplikacje serwerowe takie jak Berkeley Mail, Heirloom mailx, bądź pine, czy teŝ aplikacje obsługiwane za pomocą przeglądarek internetowych (np.: MS Explorer, Mozilla Firefox ), takie jak Hotmail, bądź Gmail określane ogólne jako webmail. DNS (ang. Domain Name System) - system serwerów oraz protokół komunikacyjny

- 2 - EP 2 174 46 B1 zapewniający zamianę internetowych adresów internetowych z postaci mnemonicznej (np. www.uprp.pl) na postać numeryczną (IP) wykorzystywaną przez serwery internetowe (np. 217.17.4.3). System DNS przechowuje takŝe informacje o serwerach pocztowych dla danej domeny internetowej (np. uprp.pl). FQDA (ang. Fully Qualified Domain Address) adres internetowej poczty elektronicznej składający się z części lokalnej, zwykle określającej uŝytkownika, symbolu @ i części domenowej, zwykle określającej domenę internetową w której uŝytkownik ma konto poczty elektronicznej. Stan techniki 1 2 [0003] Dawniej serwery do których wysyłana była poczta elektroniczna przyjmowały ją od dowolnego serwera nadającego, co było istotne w czasach kiedy połączenia sieciowe były niepewne. JeŜeli dany serwer nadający nie mógł połączyć się z serwerem odbiorcy, był przynajmniej w stanie przekazać wiadomość dalej do dowolnego serwera przekazującego (ang. relay server), który znajdował się bliŝej serwera odbiorcy. Sposób ten wykorzystują jednak obecnie podmioty rozsyłające wiadomości niechciane (tzw. SPAM) takie jak zakazane przez prawodawstwo wielu krajów niezamawiane oferty handlowe (ang. Unsolicited Commercial Email - UCE), bądź niezamawiane wiadomości wysyłane masowo do wielu odbiorców (ang. Unsolicited Bulk Email - UBE). [0004] Odbiór wiadomości o charakterze SPAMu pozostaje poza kontrolą odbiorcy, który w najlepszym wypadku (np. jeŝeli ma oprogramowanie filtrujące) ponosi koszty doręczania spamu, zwłaszcza jeśli korzysta z sieci za pośrednictwem telekomunikacyjnych łącz komutowanych. Przesyłanie SPAMu zuŝywa takŝe zasoby pośredniczących serwerów pocztowych. Serwery przyjmujące wiadomości od dowolnego serwera nadającego określa się terminem open relay i zwykle nie są one obsługiwane przez inne serwery, poniewaŝ z duŝym prawdopodobieństwem moŝna załoŝyć, Ŝe rozsyłają SPAM. Kiedy serwer taki usiłuje przesłać wiadomość, serwer odbiorcy moŝe określić jego adres i sprawdzić, czy figuruje on na publicznej liście serwerów open relay ". Listy takie są zarządzane na przykład przez organizacje MAPS (http://www.mail-abuse.com), która prowadzi takŝe ewidencje serwerów RBL (Realtime Blackhole List - serwerów rozsyłających spam) i serwerów

- 3 - EP 2 174 46 B1 DUL (Dial-Up User List serwerów powiązanych z łączami komutowanymi, z których SPAM wysyłany jest na serwery odbiorców). 1 2 [000] Powszechnie stosowaną techniką obrony przed SPAMem jest skonfigurowanie serwera nadającego tak, aby wymagał on autoryzacji nadawcy przed wysłaniem poczty. Dzięki temu jedynie wiadomości od nadawców, którzy zalogowali się na serwer nadający i których toŝsamość została tym samym przez ten serwer potwierdzona, będą przez ten serwer przekazywane dalej na wskazane w wiadomości adresy serwerów odbierających. W przypadku internetowej poczty elektronicznej usługa ta nosi nazwę SMTP AUTH i została zdefiniowana w RFC 24 (ang. Request For Comment - zbiór technicznych oraz organizacyjnych dokumentów mających formę memorandum związanych z Internetem oraz sieciami komputerowymi). [0006] Dodatkowym sposobem stosowanym w połączeniu ze sposobem omówionym powyŝej jest przyjmowanie przez serwer odbierający jedynie wiadomości, w których adres nadawcy odpowiada adresowi serwera nadającego. Nadawca moŝe więc wysłać wiadomość jedynie przez serwer, który moŝe autoryzować jego toŝsamość. W praktyce serwerem autoryzacji nadawcy jest serwer obsługujący skrzynkę pocztową nadawcy bądź serwer powiązany z tym serwerem, a porównanie adresu nadawcy z adresem serwera nadającego moŝe polegać na sprawdzeniu czy część domenowa adresu FQDA nadawcy odpowiada części domenowej adresu serwera nadającego. [0007] Poszczególne etapy typowego sposobu przesyłania wiadomości pomiędzy lokalnym programem pocztowym nadawcy a lokalnym programem pocztowym odbiorcy, wykorzystującego oba przedstawione powyŝej sposoby omówiono poniŝej w odniesieniu do fig. 1 i fig. 4. Fig. 1 ilustruje schematycznie typowy system do przesyłania wiadomości pomiędzy lokalnym komputerem nadawcy 1, a lokalnym komputerem odbiorcy 4, przez serwer nadawcy 2 i serwer odbiorcy 3, zaś fig. 4, poszczególne etapy przesyłania wiadomości. Zwykle poszczególne komputery 1-4 są od siebie odległe i połączone ze sobą siecią wykorzystującą protokół TCP/IP. Na lokalnym komputerze nadawcy 1 (takim jak jego komputer osobisty bądź przenośny) zainstalowany jest lokalny program pocztowy 11, natomiast komputery 4 obsługuje lokalny program pocztowy 41.

- 4 - EP 2 174 46 B1 1 2 [0008] Jak pokazano na fig. 4a pierwszym krokiem jest utworzenie wiadomości pocztowej przez nadawcę za pomocą programu pocztowego 11. Wiadomość zawiera poza swoją treścią między innymi adres FQDA co najmniej jednego odbiorcy oraz adres FQDA nadawcy. Następnie lokalny program pocztowy nadawcy 11 loguje się na serwer nadawcy 2, na którym nadawca ma swoje konto pocztowe. Logowanie to odbywa się przy wykorzystaniu mechanizmu SMTP AUTH oraz nazwy uŝytkownika i hasła jakimi posługuje się nadawca, które to dane są zwykle przechowywane w postaci zaszyfrowanej przez lokalny program pocztowy nadawcy 11. JeŜeli logowanie jest poprawne, lokalny program pocztowy 11 przesyła utworzoną wiadomość do serwera nadawcy 2 i, jeŝeli nie ma więcej wiadomości do wysłania, kończy połączenie z serwerem nadawcy. [0009] W kolejnym kroku, niepokazanym na fig. 4, serwer nadawcy 2 dokonuje translacji adresów FQDA kaŝdego z odbiorców wskazanych w przesyłanej wiadomości, a następnie w systemie DNS określa serwer odbiorcy 3. Jak pokazano na fig. 4b serwer nadawcy 2 łączy się następnie z serwerem danego odbiorcy 3 podając swój własny adres. Dla serwera odbiorcy 3 na obecnym etapie przesyłania wiadomości kaŝdy serwer łączący się z serwerem odbiorcy 3 jest raczej serwerem nadającym niŝ serwerem nadawcy, poniewaŝ jego toŝsamość nie została jeszcze zweryfikowana. Po połączeniu serwer nadający 2 wskazuje (np. za pomocą komendy MAIL FROM ) nadawcę wiadomości. JeŜeli część domenowa adresu FQDA nadawcy nie zgadza się z częścią domenową adresu serwera nadającego 2 serwer odbiorcy 3 zwraca komunikat o błędzie odmawiając przyjęcia wiadomości. W przeciwnym przypadku serwer odbiorcy 3 zwraca komunikat pozytywny umoŝliwiający serwerowi nadającemu 2 na poinformowanie (np. za pomocą komendy RCPT TO ) kto będzie odbiorcą wiadomości i, jeŝeli dany serwer odbierający 3 jest właściwy dla danego odbiorcy, na przesłanie wiadomości i zakończenie połączenia. [00] Przykładowa sesja połączenia pomiędzy serwerem nadającym 2 a serwerem odbiorcy 3 przedstawiona na fig. 4b została przedstawiona poniŝej, gdzie O oznacza serwer odbiorcy a N oznacza serwer nadający: krok serwer polecenie (1) O: 2 BBN-UNIX.ARPA Simple Mail Transfer Service Ready

- - EP 2 174 46 B1 1 2 (2) N: HELO HOST1.USC-ISIF.ARPA (3) O: BBN-UNIX.ARPA (4) N: MAIL FROM:<Smith@USC-ISIF.ARPA> () O: OK (6) N: RCPT TO:<Jones@BBN-UNIX.ARPA> (7) O: OK (8) N: DATA (9) O: 34 Start mail input; end with <CRLF>.<CRLF> () N: To jest mail testowy... N: Bla bla bla... N:. (11) O: OK (12) N: QUIT (13) O: 221 BBN-UNIX.ARPA Service closing transmission channel Jak widać serwer nadający zidentyfikował się w kroku (2), a jego część domenowa (USC-ISIF.ARPA) zgadza się z częścią domenową adresu nadawcy podanego w kroku (4). Jest to oczywiście najprostsza weryfikacja serwera nadawcy i nadawcy wiadomości. W sposobach przesyłania stosowanych obecnie informacje identyfikujące nadawcę i/lub odbiorcę i/lub adres serwera nadającego znajdują się najczęściej w samej wiadomości i wynikają z faktycznego adresu IP serwera nadającego bądź dotychczasowej transmisji wiadomości. [0011] Ostatnim etapem przesyłania jest dostarczenie wiadomości do lokalnego programu pocztowego odbiorcy 41, na jego komputerze 4. Jak pokazano na fig. 4c lokalny program pocztowy odbiorcy 41 loguje się do serwera odbiorcy 3 i jeŝeli logowanie jest poprawne pobiera przechowywane na serwerze odbiorcy wiadomości pocztowe. Omówione powyŝej i w nawiązaniu do fig. 4a i fig. 4b etapy przesyłania wiadomości odbywają się z wykorzystaniem protokołu SMTP, natomiast w etapach zilustrowanych na fig. 4c wykorzystuje się protokoły POP3 bądź IMAP. [0012] Z europejskiego opisu patentowego EP 1 7 228 znany jest sposób i urządzenie do redukcji wiadomości niepoŝądanych i dystrybucji wirusów komputerowych w sieci telekomunikacyjnej poprzez uwierzytelnianie pochodzenia wiadomości. Przedstawiony tam sposób obejmuje otrzymanie przez serwer nadawcy

- 6 - EP 2 174 46 B1 zapytania dla określenia czy dana wiadomość została wysłana przez wskazanego (w niej) uŝytkownika; sprawdzenie zarejestrowanych przez serwer nadawcy danych dla określenia, czy ta wiadomość odpowiada wiadomości wysłanej przez serwer nadawcy; i odpowiedź na zapytanie dla uwierzytelniania pochodzenia tej wiadomości. [0013] Stosowany w opisie termin znany sposób bądź znany sposób wysyłania wiadomości oznacza wysyłanie wiadomości dowolnym sposobem znanym ze stanu techniki, a w szczególności sposobem zilustrowanym na fig. 1 i fig. 4. 1 2 [0014] Ze stanu technik znanych jest równieŝ wiele innych ulepszeń transmisji e-mail. Zgłoszenie US 03/0236847 ujawnia system autoryzacji komunikacji i sposób, który uniemoŝliwia między innymi dotarcie wiadomości do skrzynki pocztowej odbiorcy dzięki kodom osadzonym w wiadomości, weryfikacji zastosowania właściwych kodów w kaŝdej otrzymanej wiadomości, ograniczeniu dostępu do wiadomości otrzymanych bez właściwego kodu i informacji nadawców o ich braku. Zgłoszenie US 03/01400 ujawnia sposób i system blokowana niepoŝądanych wiadomości po ich otrzymaniu, który obejmuje otrzymanie wiadomości od nadawcy, określenie czy nadawca jest autoryzowany do wysyłania wiadomości do danego odbiorcy i, jeŝeli nie jest, wysłanie do nadawcy wiadomości autoryzacyjnej z Ŝądaniem podania informacji od nadawcy, aby określić czy powinien być on autoryzowany do wysyłania wiadomości do danego odbiorcy. Zaproponowane w zgłoszeniu US 04/02216 ulepszenie znanego protokołu przesyłania wiadomości celem zapobieŝenia transmisji wiadomości niepoŝądanych obejmuje etap wysłania przez serwer komendy rozłączenia do nadawcy, zanim miał on moŝliwość przesłania wiadomości, jeŝeli jego FQDA nie znajduje się na liście odpowiadającej FQDA odbiorcy. Zgłoszenie US 06/003279 ujawnia sposób osłaniania odbiorcy przed SPAMem, według którego: 1) nadawca, który zamierza wysłać wiadomość winien zapisać się do filtra określonego przez certyfikujący podmiot zewnętrzny lub przez odbiorcę lub 2) odbiorca, który zamierza przejrzeć wiadomość od autoryzowanego nadawcy winien zapisać się do filtra określonego przez certyfikujący podmiot zewnętrzny. Opis patentowy US 6,691,16 B1 ujawnia sposób ograniczania transmisji niepoŝądanych wiadomości e-mail, gdzie e-mail jest akceptowany dla dostarczenia

- 7 - EP 2 174 46 B1 1 2 do klientów poczty przez serwer e-mail, jedynie jeŝeli pochodzi z adresu, który został zweryfikowany przez serwer e-mail i/lub dopuszczony przez odbiorcę. Kiedy wiadomość z określonego adresu e-mail jest odbierana na serwerze e-mail po raz pierwszy, wysyła on automatyczny e-mail do tego adresu, aby nadawca potwierdził autentyczność pierwotnej wiadomości. JeŜeli potwierdzenie jest otrzymane w zadanym czasie, e-mail jest uznawany za autentyczny i dostarczany do odbiorcy. Powtórna weryfikacji wiadomości z danych adresów nie jest konieczna. Sposób ten redukuje zatem SPAM poniewaŝ komputery rozsyłające SPAM zwykle nie odbierają e-maili i nie odpowiedzą na taki automatyczny e-mail wysyłany przez serwer pocztowy. Zgłoszenie US 03/00267 ujawnia serwer pocztowy do zarządzania wiadomościami e-mail. Po otrzymaniu wiadomości od nadawcy, która zawiera adres docelowy klienta e-mail oraz kod, serwer sprawdza czy kod jest właściwym kodem autoryzacyjnym i, jeŝeli tak dostarcza wiadomość klientowi e-mail. W przeciwnym razie serwer pocztowy Ŝąda od nadawcy podania kodu autoryzacyjnego. JeŜeli serwer otrzyma wiadomość zawierającą kod Ŝądania od nadawcy, moŝe równieŝ dostarczyć część wiadomości klientowi, aby określić czy dostarczać kod autoryzacyjny nadawcy. Międzynarodowa publikacja WO 06/123328 ujawnia system i sposób przesyłania plików załączników wiadomości w sieci telekomunikacyjnej z wykorzystaniem połączenia typu peer-to-peer (P2P), według którego wiadomość e-mail jest przesyłana w tradycyjny sposób, zaś jej załączniki (jeŝeli są) dostarczane są połączeniem bezpośrednim pomiędzy co najmniej jednym węzłem IP przechowującym co najmniej część pliku załącznika a odbiorcą, zaś wymagane informacje dla zestawienia bezpośredniego połączenia znajdują się w samej wiadomości. Oddzielając wiadomość od załączników sposób ten zmniejsza objętość danych przesyłanych przez serwery pocztowe, pozwalając im jedynie na obsługę tekstu wiadomości. Publikacja WO 01/93 ujawnia między innymi sposób pozwalający na natychmiastową komunikację P2P (ang. instant messaging - IM) wśród uŝytkowników połączonych do róŝnych systemów IM przy uŝyciu nowego protokołu SNIP (ang. Single Name Instant Messaging Protocol) (SNIP) oraz serwera SNIP, który korzysta z uniwersalnej przestrzeni adresów e-mail ułatwiając bezpośrednią komunikację IM wśród uŝytkowników połączonych do róŝnych sieci.

- 8 - EP 2 174 46 B1 Ulepszenia transmisji e-mail znane są równieŝ z opisów US 0/02699 i US 07/000976. 1 2 [001] Znane sposoby przesyłania wymagają zatem trzykrotnego przesłania wiadomości: pierwszego pomiędzy lokalnym programem pocztowym nadawcy 11 pracującym na jego komputerze osobistym 1 a serwerem nadawcy 2; drugiego pomiędzy serwerem nadającym 2 a serwerem odbiorcy 3; i trzeciego pomiędzy serwerem odbiorcy 3 a lokalnym programem pocztowym odbiorcy 41. Z drugiej strony przesyłane obecnie wiadomości elektroniczne staja się coraz obszerniejsze w sensie wielkości przesyłanego zbioru, co wynika między innymi z formatu wiadomości (np. HTML, bądź tekst formatowany), czy teŝ wielkości i liczby dodatkowych plików dołączanych do wiadomości (tzw. załączników). W przypadku, kiedy nadawca znajduje się w miejscu bliskim serwera odbiorcy, natomiast jego serwer pocztowy jest odległy, konieczność przesłania wiadomości najpierw na ten serwer, a dopiero później do serwera odbiorcy, i dalej do lokalnego programu pocztowego odbiorcy generuje znaczne obciąŝenie w ruchu sieciowym. Przykładowo nadawca mający konto pocztowe obsługiwane przez serwer w Polsce znajduje się w podróŝy słuŝbowej w Pekinie, skąd za pomocą programu pocztowego zainstalowanego na swoim komputerze przenośnym zamierza wysłać wiadomość do kontrahenta, którego serwer, jak i on sam przebywa w Pekinie. Wiadomość zostanie zatem przesłana najpierw do serwera nadawcy w Polsce, a następnie od serwera nadawcy ponownie do serwera odbiorcy w Pekinie. [0016] Celem wynalazku jest dostarczenie sposobu i systemu przesyłania wiadomości elektronicznych za pośrednictwem sieci komputerowej, a zwłaszcza sposobu i systemu dostarczania internetowych wiadomości elektronicznych (e-mail), który znacznie zmniejszyłby ruch sieciowy i pozwalałby na jego stopniową implementację w istniejących środowiskach przesyłania wiadomości, cechując się wsteczną kompatybilnością wobec systemów istniejących. Celem wynalazku jest takŝe dostarczenie sposobu i systemu przesyłania wiadomości, który ograniczyłby działalność podmiotów odpowiedzialnych za przesyłanie SPAMu. Istota wynalazku

- 9 - EP 2 174 46 B1 1 2 [0017] Istotą wynalazku jest sposób przesyłania wiadomości elektronicznych, który charakteryzuje się tym, Ŝe obejmuje kolejne etapy: a) wysłania do serwera autoryzacji nadawcy Ŝądania autoryzacji zamiaru wysyłania wiadomości do określonego co najmniej jednego odbiorcy; b) autoryzacji przez serwer autoryzacji nadawcy zamiaru wysyłania wiadomości do określonego co najmniej jednego odbiorcy; i c) przyjęcia wiadomości do określonego co najmniej jednego odbiorcy przez serwer tego odbiorcy, jeŝeli zamiar wysyłania wiadomości dla tego odbiorcy został autoryzowany przez serwer autoryzacji nadawcy. [0018] Serwerem autoryzacji nadawcy jest korzystnie serwer obsługujący skrzynkę pocztową nadawcy. Pozwala to na wykorzystanie znanych rozwiązań, na przykład typu POP before SMTP bądź omawianej wcześniej usługi SMTP AUTH. MoŜliwe jest oczywiście wykorzystanie innych serwerów sieciowych mających moŝliwość potwierdzenia toŝsamości zdalnego nadawcy. [0019] Korzystnie etap (b) autoryzacji przez serwer autoryzacji nadawcy rzeczonego Ŝądania autoryzacji zamiaru wysyłania wiadomości do określonego co najmniej jednego odbiorcy obejmuje rejestrację rzeczonego Ŝądania autoryzacji. Rejestracja ta moŝe zostać zapisana w rejestrach bądź bazie danych serwera autoryzacyjnego lub dowolnego innego serwera zarządzanego przez serwer autoryzacji nadawcy, bądź teŝ nawet serwera odbiorcy. [00] śądanie autoryzacji zamiaru wysyłania wiadomości zawiera korzystnie co najmniej adres co najmniej jednego odbiorcy oraz opcjonalnie co najmniej jeden inny parametr dodatkowy. Parametrem dodatkowym moŝe być na przykład adres nadawcy, sygnatura bądź temat wiadomości, data i czas utworzenia bądź wysłania wiadomości, i/lub lista załączników wiadomości. [0021] Przeprowadzana w etapie (b) autoryzacja zamiaru wysyłania wiadomości do określonego co najmniej jednego odbiorcy jest korzystnie waŝna prze określony okres czasu i/lub uniewaŝniana po etapie (c). [0022] Korzystne, aby po etapie b) zachodził dodatkowy etap wysłania przez serwer autoryzacji nadawcy do nadawcy potwierdzenia autoryzacji zamiaru wysyłania wiadomości do określonego co najmniej jednego odbiorcy. UmoŜliwia to nadawcy

- - EP 2 174 46 B1 1 2 wysłanie wiadomości w znany sposób, jeŝeli serwer autoryzacji nadawcy nie potwierdził autoryzacji, na przykład dlatego, Ŝe nie obsługuje sposobu według wynalazku. Ponadto przed etapem c) moŝe korzystnie zachodzić dodatkowy etap wysłania przez serwer danego odbiorcy do serwera autoryzacji nadawcy zapytania o autoryzację zamiaru wysyłania wiadomości dla tego odbiorcy. Zapytanie takie moŝe być wysyłane do serwera właściwego do autoryzacji danego nadawcy na przykład przy próbie przesłania na serwer odbiorcy wiadomości z serwera typu open relay bądź serwera zarejestrowanego na liście DUL. Ponadto, po etapie (b) sposób moŝe obejmować dodatkowy etap wysłania przez serwer autoryzacji nadawcy na co najmniej jeden serwer określonego co najmniej jednego odbiorcy komunikatu o autoryzacji zamiaru wysyłania wiadomości dla tego odbiorcy. Po otrzymaniu takiego komunikatu serwer odbiorcy jest gotowy na przyjęcie wiadomości od określonego nadawcy. [0023] Korzystny jest równieŝ dodatkowy etap przesyłania przez lokalny serwer pocztowy odbiorcy do serwera autoryzacji odbiorcy komunikatu informującego o adresie lokalnego serwera odbiorcy. Dzięki temu serwer autoryzacji odbiorcy, to jest serwer z którym łączą się serwery nadające celem przesłania wiadomości adresowanej dla danego odbiorcy, moŝe przekazać tą wiadomość wprost do lokalnego serwera pocztowego odbiorcy zainstalowanego na przykład na jego lokalnym komputerze. Korzystne jest zwłaszcza, aby komunikat ten był wysyłany po kaŝdorazowej zmianie adresu lokalnego serwera odbiorcy. W przypadku kiedy lokalny serwer odbiorcy jest wyłączony bądź z innych powodów niedostępny serwer autoryzacji odbiorcy moŝe oczywiście przyjmować wiadomości pełniąc funkcje zdalnego serwera pocztowego odbiorcy. [0024] Zwłaszcza w takim przypadku przed etapem c) korzystny jest dodatkowy etap przesłania przez serwer autoryzacji odbiorcy do serwera autoryzacji nadawcy bądź lokalnego serwera nadawcy komunikatu informującego o adresie lokalnego serwera odbiorcy. Dzięki temu wcześniej autoryzowana wiadomość moŝe być przesłana wprost do lokalnego serwera odbiorcy. [002] ToŜsamość serwera autoryzacji nadawcy i/lub serwera autoryzacji odbiorcy moŝe być korzystnie potwierdzona odpowiednim certyfikatem. Certyfikaty jakie

- 11 - EP 2 174 46 B1 moŝna tu zastosować to na przykłąd certyfikaty wydawane przez firmę VeriSign (http://www.verisign.com) bądź Thawte (http://www.thawte.com). 1 2 [0026] śądanie autoryzacji zamiaru wysyłania wiadomości do określonego co najmniej jednego odbiorcy jest równieŝ korzystnie wiadomością elektroniczną. Pozwala to na zastosowanie sposobu w istniejących systemach przesyłania wiadomości bez konieczności ich znaczącej modyfikacji. Gdyby modyfikacja była konieczna to mogłaby polegać na przykład na rozszerzeniu protokołu SMTP o dodatkowe polecenia (np. AUTR dla Ŝądania autoryzacji, RCAD dla podania adresu lokalnego serwera odbiorcy, etc.), bądź teŝ obejmować odpowiednią konfigurację serwerów pocztowych. [0027] W szczególności istotą wynalazku jest sposób przesyłania internetowych wiadomości elektronicznych (e-mail) obejmujący etap utworzenia pierwszej wiadomości przez nadawcę i autoryzacji nadawcy serwer pocztowy nadawcy, który obejmuje ponadto etapy (a) utworzenia i wysłania do serwera autoryzacji nadawcy drugiej wiadomości elektronicznej zawierającej Ŝądanie autoryzacji zamiaru wysłania wiadomości do określonego co najmniej jednego odbiorcy (b) autoryzacji rzeczonego Ŝądania autoryzacji przez serwer autoryzacji nadawcy; i (c) przyjęcia pierwszej wiadomości adresowanej do określonego co najmniej jednego odbiorcy przez serwer tego odbiorcy, jeŝeli Ŝądanie autoryzacji zostało autoryzowane przez serwer autoryzacji nadawcy, przy czym serwerem autoryzacji nadawcy jest lokalny serwer pocztowy odbiorcy; Ŝądanie autoryzacji zawarte w drugiej wiadomości elektronicznej zawiera co najmniej adres IP lokalnego systemu komputerowego nadawcy i adres e-mail odbiorcy oraz opcjonalnie co najmniej jeden dodatkowy parametr, a druga wiadomość jest przesyłana przez lokalny serwer pocztowy nadawcy do zdalnego serwera pocztowego nadawcy, następnie do co najmniej jednego serwera pocztowego określonego co najmniej jednego odbiorcy i ostatecznie trafia na lokalny serwer pocztowy odbiorcy; zaś autoryzacja przez serwer autoryzacji nadawcy tego Ŝądania autoryzacji zamiaru wysłania wiadomości do określonego co najmniej jednego odbiorcy obejmuje utworzenie i wysłanie przez lokalny serwer pocztowy odbiorcy do lokalnego serwera pocztowego nadawcy Ŝądania autoryzacyjnego, które zawiera co

- 12 - EP 2 174 46 B1 najmniej adres protokołu internetowego (IPS) dla komputera odbiorcy i opcjonalnie co najmniej jeden parametr dodatkowy, a sposób obejmuje dodatkowy etap wysłania pierwszej wiadomości przez lokalny serwer pocztowy nadawcy do co najmniej jednego lokalnego serwera pocztowego określonego co najmniej jednego odbiorcy. 1 2 [0028] W znanych systemach przesyłania poczty elektronicznej, pomiędzy serwerami jest ona przesyłana wykorzystującymi architekturę równy z równym (P2P), natomiast pomiędzy serwerami MTA a lokalnymi komputerami uŝytkowników poczty elektronicznej opiera się o architekturę typu klient-serwer. Niniejszy wynalazek pozwala nas uzupełnienie o bądź nałoŝenie na cały znany system przesyłania poczty elektronicznej architektury P2P, zwiększając prywatność i bezpieczeństwo transmisji e-mail i zmniejszając obciąŝenie sieci o dystrybucje SPAMu, co zostanie dalej wyjaśnione. Dodatkowo wynalazek cechuje się wsteczną kompatybilnością względem znanego systemu przesyłania oraz transparentnością uŝytkowania z punktu widzenia uŝytkowników końcowych. ChociaŜ poniŝej rozwaŝany jest głównie transfer e-maili pomiędzy lokalnym serwerem pocztowym nadawcy a lokalnym serwerem pocztowym odbiorcy, oczywistym jest, Ŝe taka notacja zaleŝy jedynie od funkcji (wysyłanie lub odbieranie) danego serwera podczas transmisji, zaś oba te serwery będą korzystnie pełnić obie te funkcje. [0029] Korzystnie potwierdzenie Ŝądania autoryzacyjnego jest samo w sobie wiadomością elektroniczną i jest przesyłane przez lokalny serwer pocztowy odbiorcy do lokalnego serwera pocztowego nadawcy poprzez serwer poczty wychodzącej określonego odbiorcy i serwer poczty przychodzącej nadawcy. Dzięki temu weryfikowany jest nie tylko nadawca wysyłający Ŝądanie autoryzacyjne ale równieŝ odbiorca wysyłający potwierdzenie Ŝądania autoryzacyjnego z powrotem do nadawcy. Pozwala to na zmniejszenie dystrybucji SPAMu poniewaŝ serwery rozsyłające SPAM (np. tzw. komputery zombie) mają zwykle wyłączony odbiór wiadomości (w przeciwnym razie mogłyby zostać zablokowane połączeniami z serwerów organizacji zwalczających SPAM). [00] Alternatywnie potwierdzenie Ŝądania autoryzacyjnego jest przesyłane przez lokalny serwer pocztowy odbiorcy wprost do lokalnego serwera pocztowego. Kanał P2P dla wysyłania i odbierania wiadomości moŝe być więc zestawiony

- 13 - EP 2 174 46 B1 1 2 natychmiastowo w oparciu o adres protokołu internetowego dla komputera nadawcy znajdujący się w e-mailu potwierdzającym Ŝądanie autoryzacyjne. Kanał ten moŝe być aktywny tak długo, jak te adresy pozwalają na jednoznaczną identyfikację komputerów nadawcy i odbiorcy. JeŜeli nie, lokalny serwer pocztowy nadawcy moŝe automatycznie wysłać kolejne Ŝądanie autoryzacyjne przez serwer pocztowy nadawcy do serwera pocztowego odbiorcy, skąd zostanie odebrany przez lokalny serwer pocztowy odbiorcy aby ponownie zestawić kanał P2P. [0031] Korzystne jest jednak kiedy lokalny serwer pocztowy odbiorcy informuje lokalny serwer pocztowy nadawcy potwierdzeniem Ŝądania autoryzacyjnego o kaŝdorazowej zmianie adresu lokalnego serwera pocztowego odbiorcy. Dzięki temu pocztowy kanał P2P pomiędzy lokalnymi serwerami pocztowymi jest stale utrzymywany, poniewaŝ znają one wzajemnie swoje adresy. JeŜeli tylko jeden z nich zmieni swój adres, np. w wyniku przerwania połączenia i przydziału nowego adresu z dostępnej puli dynamicznych adresów IP, zmiany lokalizacji, dostawcy usług (ISP), etc., wówczas lokalny serwer pocztowy niezwłocznie poinformuje o tym fakcie drugą stronę ponownie zestawiając kanał P2P. Kanał ten zostałby zerwany jedynie w przypadku gdyby oba komputery zmieniły swoje adresy IPS w tej samej chwili, bądź oba pozostawały poza siecią przez dłuŝszy okres czasu. [0032] Dodatkowe parametry Ŝądania autoryzacji opisane powyŝej są korzystnie wybrane spośród publicznego klucza kryptograficznego nadawcy (szyfrowanie), informacji promujących transfer P2P i/lub tekstu rzeczonej pierwszej wiadomości, zaś parametry dodatkowe rzeczonego potwierdzenia Ŝądania autoryzacji są wybrane spośród publicznego klucza kryptograficznego odbiorcy (szyfrowanie), dopuszczalnych typów i rozmiarów załączników, dopuszczalnego rozmiaru i/lub innych parametrów pierwszej wiadomości jakie są akceptowalne przez odbiorcę. Klucze szyfrujące i deszyfrujące pozwalają na szyfrowane połączenie P2P pomiędzy lokalnymi komputerami nadawcy i odbiorcy, takie jak symetryczny bądź korzystniej asymetryczny kanał TLS (ang. Transport Layer Security) w warstwie TCP, w którym do kodowania strumieni danych stosuje się z dwa klucze publicznych a do dekodowanie klucze prywatne, z których kaŝdy znany jest jedynie nadawcy lub odbiorcy. MoŜna takŝe wysyłać np. tekst pierwszej wiadomości od nadawcy wraz z Ŝądaniem

- 14 - EP 2 174 46 B1 1 2 autoryzacyjnym znanym sposobem przesyłania wiadomości, podczas gdy załączniki tej wiadomości zostaną przesłane później po zestawieniu łącza P2P. JeŜeli odbiorca nie obsługuje przesyłania P2P według wynalazku, dodatkowa informacja moŝe zachęcać do jego stosowania poprzez zainstalowanie odpowiedniego lokalnego serwera pocztowego lub programu pocztowego implementującego taki sposób. [0033] Korzystnie przed przesłaniem pierwszej wiadomości sposób obejmuje ponad jedną wymianę Ŝądania autoryzacji i odpowiadającego mu potwierdzenia Ŝądania autoryzacji pomiędzy lokalnym serwerem pocztowym nadawcy a serwerem pocztowym odbiorcy dla wynegocjowania formy pierwszej wiadomości jaka jest akceptowalna przez serwer pocztowy odbiorcy. [0034] lokalny serwer pocztowy nadawcy i/lub odbiorcy moŝe mieć korzystnie formę aplikacji pośredniczącej w transmisji pomiędzy klientem poczty a zdalnym serwerem pocztowym. Aplikacja ta moŝe działać np. jako serwer SMTP nasłuchujący na porcie 23 i serwer POP3 nasłuchujący na porcie 80 lokalnego komputera nadawcy/odbiorcy (localhost, IP 127.0.0.1). Po odpowiedniej konfiguracji klienta poczty wskazującej na localhost a jako serwer poczty wychodzącej i przychodzącej oraz po odpowiedniej konfiguracji samej tej aplikacji wskazującej na publiczne adresy zdalnych serwerów e-maili wychodzących i przychodzących, aplikacja ta moŝe przechwytywać wiadomości wysyłane lub odbierane. W szczególności aplikacja ta moŝe w sposób niewidoczny dla uŝytkownika uzupełniać pierwszą wiadomość tworzoną przez nadawcę o Ŝądanie autoryzacji lub teŝ czasowo zapisywać pierwszą wiadomość tworząc nowe Ŝądanie autoryzacji, a następnie wysyłać je jako e-mail do odbiorcy mającego podobną aplikacje, która zinterpretuje to Ŝądanie autoryzacji i prześle potwierdzenie autoryzacyjne z powrotem do nadawcy. Aplikacja ta moŝe teŝ nasłuchiwać na innym porcie (np. 272) i wykorzystywać dedykowany protokół (inny niŝ SMTP) dla transmisji for P2P według wynalazku. [003] Alternatywnie bądź dodatkowo lokalny serwer pocztowy nadawcy i/lub lokalny serwer pocztowy odbiorcy mogą być zintegrowane w lokalnym programie pocztowym. W takim przypadku klient poczty (MUA) będzie wyposaŝony w mechanizmy wysyłania i odbierania Ŝądań i potwierdzeń autoryzacyjnych oraz nawiązywania połączeń P2P zaraz po instalacji.

- 1 - EP 2 174 46 B1 1 2 [0036] W jeszcze innej realizacji klient poczty moŝe być jest obsługiwany z poziomu przeglądarki internetowej a lokalny serwer pocztowy nadawcy i/lub odbiorcy moŝe mieć formę apletu zainstalowanego na komputerach nadawcy i/lub odbiorcy i zarządzanego za pośrednictwem przeglądarki internetowej i/lub za pośrednictwem lokalnego programu pocztowego. UmoŜliwia to wykorzystanie wynalazku w systemach typu webmail Aplety działające jako lokalne serwery pocztowe moŝna zaimplementować n.p w technologii Java dla zapewnienia bezpośredniego połączenia pomiędzy lokalnymi komputerami nadawcy i odbiorcy. [0037] Korzystne jest, aby etapy (a) do (c) były przeprowadzane, jeŝeli wielkość wiadomości przekracza predefiniowany próg. Dzięki temu niewielkie wiadomości (np. mniejsze niŝ 4 MB) mogą być nadal wysyłane z wykorzystaniem znanego sposobu przesyłania. [0038] Istotą wynalazku jest równieŝ system przesyłania wiadomości elektronicznych (e-mail) za pośrednictwem sieci telekomunikacyjnej, który działa według dowolnego wariantu sposobu zdefiniowanego powyŝej. [0039] Istotą wynalazku jest w końcu nośnik danych zawierający instrukcje wykonywalne dla systemu przesyłania wiadomości w sieci telekomunikacyjnej, a zwłaszcza dla przesyłania internetowych wiadomości elektronicznych (e-mail), gdzie rzeczone instrukcje wykonywalne obejmują przeprowadzenie etapów dowolnego wariantu sposobu opisanego powyŝej. [0040] Wynalazek przedstawiono poniŝej w nawiązaniu do jego korzystnych, przykładowych realizacji i na rysunku, którego poszczególne figury ilustrują: fig. 1: typowy, znany system przesyłania wiadomości w sieci komputerowej; fig. 2: znany system przesyłania wiadomości w sieci komputerowej, w którym zastosowano sposób według wynalazku; fig. 3: inny przykładowy system przesyłania wiadomości według wynalazku; fig. 4: poszczególne etapy znanego sposobu przesyłania wiadomości; fig. : poszczególne etapy przykładowego sposobu przesyłania wiadomości według wynalazku; a fig. 6: poszczególne etapy kolejnego przykładowego sposobu przesyłania wiadomości według wynalazku.

- 16 - EP 2 174 46 B1 1 2 fig. 7: kolejny przykładowy system przesyłania wiadomości według wynalazku; fig. 8: jeszcze jeden przykładowy system przesyłania wiadomości według wynalazku w zastosowaniu do pocztowych aplikacji webowych (webmail); fig. 9 poszczególne etapy przykładowego sposobu przesyłania wiadomości według wynalazku odpowiadającego zasadniczo systemowi z fig. 7; a fig. ilustruje poszczególne etapy kolejnego przykładowego sposobu przesyłania wiadomości według wynalazku odpowiadającego zasadniczo systemowi z fig. 8. [0041] W pokazanych na fig. 1-3, 7 i 8 systemach przesyłania wiadomości, poszczególne etapy przesyłania wiadomości pomiędzy poszczególnymi systemami komputerowymi i serwerami zaznaczono za pomocą strzałek pogrubionych przedstawiających przekazywanie wiadomości elektronicznej i cienkich strzałek wygiętych przedstawiających przekazywanie pomocniczych komunikatów kontrolnych (poleceń, zapytań, etc.). NaleŜy jednak rozumieć, Ŝe kaŝdy etap przesyłania wiadomości zwykle stanowi swego rodzaju dialog wzajemnej wymiany komunikatów pomiędzy serwerami. Choć w opisie stosowana jest terminologia uproszczona (np. serwer wysyła Ŝądanie, serwer wysyła zapytanie, serwer odpowiada ) dla znawców dziedziny oczywistym jest, Ŝe serwery komputerowe, a zwłaszcza internetowe serwery pocztowe komunikują się właśnie w ten sposób, jak zostało to zdefiniowane dla protokołu SMTP między innymi w RFC 821, RFC 2821 i RFC 1869, które włączone są do niniejszego opisu poprzez odniesienie. Komunikację z serwerem pocztowym moŝna teŝ przeprowadzić ręcznie korzystając np. z programu telnet. [0042] Fig. 2 i ilustruje schematycznie przykładową implementacje wynalazku. Podobnie jak w przypadku znanego sposobu (porównaj fig. 1 i 4 wraz z opisem w części opisu dotyczącej stanu techniki) pierwszym krokiem sesji połączenia pokazanej na fig. a jest utworzenie wiadomości pocztowej przez nadawcę. Następnie lokalny program pocztowy 11 loguje się na serwer nadawcy 2, na którym nadawca ma swoje konto pocztowe. [0043] JeŜeli logowanie jest poprawne, lokalny program pocztowy 11 zamiast utworzonej wiadomości przesyła jednak do serwera nadawcy 2 Ŝądanie rejestracji zamierzonej operacji wysyłania zawierające adres nadawcy, adres odbiorcy i wielkość wiadomości. śądanie rejestracji moŝe oczywiście zawierać równieŝ inne

- 17 - EP 2 174 46 B1 1 2 parametry takie jak datę i czas, temat wiadomości, listę załączników, etc. W odpowiedzi lokalny program pocztowy 11 otrzymuje komunikat potwierdzający rejestrację Ŝądania w rejestrze (logu) serwera 2 i kończy połączenie. Oczywistym jest, Ŝe w przypadku jeŝeli serwer nadawcy 2 nie obsługuje wynalazku, odrzuci on komunikat Ŝądania rejestracji zamierzonej operacji wysyłania, a lokalny program pocztowy 11 prześle wiadomość znanym sposobem przedstawionym na fig. 1 i 4. [0044] W kolejnej sesji połączenia pokazanej na fig. b lokalny program pocztowy 11 łączy się z serwerem odbiorcy 3 i wysyła komunikat (w przypadku protokołu SMTP będzie to MAIL FROM ) identyfikujący nadawcę wiadomości. PoniewaŜ adres serwera nadającego to jest komputera 1, na którym pracuje lokalny program pocztowy 11 nie zgodzi się z adresem nadawcy, serwer odbiorcy 3 odmówi przyjęcia wiadomości, jeŝeli nie obsługuje wynalazku, bądź teŝ wyśle do serwera pocztowego 2 odpowiadającego adresowi nadawcy zapytanie o rejestrację zamierzonej operacji wysyłania. JeŜeli serwer nadawcy 2 nie obsługuje mechanizmu rejestracji według wynalazku, w odpowiedzi na to zapytanie wygeneruje on komunikat błędu. Brak rejestracji zamierzonej operacji wysyłania w rejestrze serwera 2 oznaczał będzie natomiast próbę anonimowego wysłania wiadomości lub próbę wysłania wiadomości po określonym, wynoszącym na przykład 1 minutę czasokresie przechowywania rejestracji rejestrze serwera 2. W kaŝdym z tych przypadków serwer odbiorcy 3 odmówi przyjęcia wiadomości. [004] Wiadomość zostanie przyjęta przez serwer odbiorcy 3 jedynie wówczas, gdy zamiar wysyłania wiadomości dla odbiorcy, dla którego ten serwer jest właściwy został zarejestrowany przez serwer nadawcy 2. Po odbiorze wiadomości serwer odbiorcy 3 moŝe teŝ uniewaŝnić rejestrację rejestrze serwera nadawcy 2, zapobiegając tym samym moŝliwości omyłkowego, powtórnego przyjęcia tej samej wiadomości. Po wysłaniu wszystkich wiadomości do danego serwera odbiorcy 3 lokalny program pocztowy nadawcy 1 kończy połączenie. Przesłanie wiadomości do lokalnego programu pocztowego odbiorcy zachodzi tu analogicznie jak na fig. 4c [0046] Dzięki zastosowaniu sposobu opisanego powyŝej konieczne jest zatem jedynie dwukrotne przesłanie wiadomości: pierwsze pomiędzy lokalnym programem pocztowym nadawcy 11 a serwerem odbiorcy 3 i drugie pomiędzy serwerem odbiorcy 3 a lokalnym programem pocztowym odbiorcy 41.

- 18 - EP 2 174 46 B1 1 2 [0047] Jeszcze inną implementacje wynalazku zilustrowano schematycznie na fig. 3 i 6. W tym przykładzie wykonania programy pocztowe nadawcy 11 i odbiorcy 41 są jednak tak skonfigurowane, Ŝe w obu przypadkach zarówno serwerami poczty przychodzącej (POP3), jak i poczty wychodzącej (SMTP) są lokalne komputery nadawcy 1 i odbiorcy 4 (np. o adresie IP 127.0.0.1, tzw. localhosty). Na komputerze 1 nadawcy pracuje w tle program 12 pełniący usługi lokalnego serwera nadawcy, który wysyła i odbiera pocztę przekazywaną z i do programu pocztowego 11. Podobnie na komputerze 4 odbiorcy pracuje w tle program 42 pełniący usługi lokalnego serwera odbiorcy, który wysyła i odbiera pocztę przekazywaną z i do programu pocztowego 41. [0048] Ponadto lokalny serwer odbiorcy 42 odpowiada za wysyłanie do serwera autoryzacji odbiorcy 3a komunikatów informujących o swoim faktycznym adresie internetowym IP. PoniewaŜ zwykle komputer odbiorcy 4 jest połączony z Internetem poprzez połączenie dynamiczne bądź czasowego (np. połączenie typu Dial UP), adres ten moŝe ulegać częstym zmianom. [0049] Po utworzeniu wiadomości za pomocą lokalnego programu pocztowego 11 nadawca wykonuje polecenie Wyślij z paska narzędziowego programu pocztowego 11, a wiadomość zostaje przesłana na lokalny serwer nadawcy 12, który loguje się następnie do serwera autoryzacji nadawcy 2a. JeŜeli logowanie jest poprawne, lokalny serwer nadawcy 12 wysyła do serwera autoryzacji nadawcy 2a Ŝądanie autoryzacji zamierzonej operacji wysłania wiadomości. Serwer autoryzacji nadawcy 2a łączy się następnie z serwerem autoryzacji odbiorcy wiadomości 3a. JeŜeli adres nadawcy nie odpowiada adresowi serwera autoryzacji nadawcy 2a lub serwer autoryzacji nadawcy nie jest w inny sposób uprawniony do wysyłania wiadomości od nadawców, których część domenowa adresu FQDA odpowiada adresowi serwera 2a serwer autoryzacji odbiorcy 3 przerywa połączenie. [000] W przeciwnym przypadku serwer autoryzacji odbiorcy 3a informuje serwer autoryzacji nadawcy 2a o adresie lokalnego serwera odbiorcy 4, a serwer autoryzacji nadawcy 2a przekazuje tą informację do lokalnego serwera nadawcy 12. [001] Ostatnim etapem jest przesłanie wiadomości przez lokalny serwer nadawcy 12 do lokalnego serwera odbiorcy 42 i zakończenie połączenia.

- 19 - EP 2 174 46 B1 1 2 Wiadomość moŝe być oczywiście przesyłana pomiędzy lokalnym serwerem nadawcy 12 a lokalnym serwerem odbiorcy 42 fragmentarycznie w zaleŝności od moŝliwości zestawienia połączenia pomiędzy nimi. Z lokalnego serwera odbiorcy 42 wiadomość jest przekazywana do lokalnego programu pocztowego odbiorcy 41 bezpośrednio bądź tez po wykonaniu przez odbiorcę polecenia Odbierz z paska narzędziowego programu pocztowego 41. Do przesłania wiadomości według tej implementacji wynalazku konieczna jest więc jedynie tylko jedna sesja połączenia. [002] Oczywiście w tym przypadku występują niejako dwa serwery nadawcy: lokalny serwer nadawcy 12 i serwer autoryzacji nadawcy 2a oraz dwa serwery odbiorcy: serwer autoryzacji odbiorcy 3a i lokalny serwer odbiorcy 42. Ostatecznym serwerem odbiorcy będzie oczywiście lokalny serwer odbiorcy 42. W przypadku kiedy lokalny serwer odbiorcy 42 byłby niedostępny serwer autoryzacji odbiorcy moŝe oczywiście przyjmować wiadomości pełniąc wówczas funkcje końcowego serwera odbiorcy (podobnie jak opisano w odniesieniu do fig.2 i ). [003] Fig. 7 i 9 schematycznie ilustruje inną implementację wynalazku, w której ustawienia klientów poczty nadawcy 11 i odbiorcy 41 wskazują na lokalne komputery (localhost) nadawcy 1 i odbiorcy 4 jako serwery poczty przychodzącej (POP3) i wychodzącej (SMTP). Na lokalnym komputerze 1 nadawcy pracuje w tle program 12, przypisany do portów 23 (SMTP), 80 (POP3) i 272 (MAILP2P) adresu IP komputera lokalnego i pełniący usługi lokalnego serwera pocztowego nadawcy, poprzez wysyłanie (SMTP) i odbieranie (POP3/IMAP) poczty przekazywanej z i do programu pocztowego 11. Podobnie, na komputerze 4 odbiorcy pracuje w tle program 42 pełniący usługi lokalnego serwera pocztowego odbiorcy, który wysyła i odbiera pocztę przekazywaną z i do programu pocztowego 41. W konfiguracjach lokalnych serwerów pocztowych 12 i 42 wskazano z kolei serwery poczty wychodzącej i przychodzącej dla kont pocztowych nadawcy i odbiorcy. Bardzo często komputery nadawcy 1 i odbiorcy 4 są połączone z Internetem połączeniem dynamicznym bądź czasowym (np. typu Dial UP), a ich adresy IP mogą ulegać częstym zmianom. [004] Podobnie jak w przypadku znanego sposobu transmisji pierwszym krokiem sesji połączenia pokazanym na fig. 9 jest utworzenie właściwej, pierwszej wiadomości elektronicznej przez nadawcę w programie pocztowym 11 obejmujące wprowadzenie jej treści, wskazanie adresu e-mail jej odbiorcy bądź odbiorców,

- - EP 2 174 46 B1 1 2 podanie tematu wiadomości, załączenie dodatkowych plików, etc. Po utworzeniu wiadomości nadawca wykonuje polecenie Wyślij z paska narzędziowego programu pocztowego 11, który wysyła pierwszą wiadomość niejako sam do siebie a ściślej do lokalnego serwera pocztowego 12. Lokalny serwer pocztowy 12 zapisuje pierwszą wiadomość dla jej późniejszego wykorzystania. [00] W kolejnym kroku lokalny serwer pocztowy 12 sprawdza w swoich rejestrach czy znany mu jest adres komputera 4 odpowiadający adresowi e-mail odbiorcy i czy odbiorca obsługuje sposób według wynalazku. Adres ten będzie znajdował się w rejestrach, jeŝeli wcześniej pomyślnie zestawiono kanał połączenia P2P pomiędzy nadawcą a odbiorcą, bądź teŝ mógł zostać wprowadzony do tych rejestrów na przykład ręcznie przez nadawcę. [006] JeŜeli adres IPS odbiorcy i opcjonalnie inne parametry identyfikujące odbiorcę są znane, lokalny serwer pocztowy nadawcy 12 wysyła pierwszą wiadomość połączeniem P2P przez port 272 (w szczególności połączeniem szyfrowanym) wprost do lokalnego serwera pocztowego odbiorcy 42. JeŜeli adres IPS systemu komputerowego odbiorcy nie jest znany bądź, choć jest znany, pierwszej wiadomości nie udało się wysłać, lokalny serwer pocztowy nadawcy 12 tworzy drugą wiadomość zawierającą Ŝądanie autoryzacji zamiaru wysyłania wiadomości do danego odbiorcy. śądanie to zawiera adres IPS komputera nadawcy 1, adres nadawcy, adres e-mail odbiorcy, treść pierwszej wiadomości i opcjonalnie inne parametry, takie jak lista typów i wielkości załączników jakie będą wysyłane wraz z pierwszą wiadomością. [007] W kolejnym kroku lokalny serwer pocztowy nadawcy 12 wysyła drugą wiadomość autoryzacyjną do serwera poczty wychodzącej 2, na którym nadawca ma swoje konto pocztowe. Przed przesłaniem wiadomości nadawca jest autoryzowany przez swój serwer nadawcy 2 na przykład z wykorzystaniem mechanizmu SMTP_AUTH albo POP3 przed SMTP i jeŝeli autoryzacja jest niepomyślna serwer nadawcy odmawia połączenia. W kolejnym kroku serwer nadawcy 2 przesyła protokołem SMTP (fig. 7) wiadomość autoryzacyjną do serwera pocztowego odbiorcy 3, na którym odbiorca ma swoje konto pocztowe. Z serwera odbiorcy 3 wiadomość ta zostanie z kolei odebrana przez lokalny serwer pocztowy odbiorcy 42 protokołem POP3 albo IMAP. W tym pierwszym przypadku (POP3) lokalny serwer pocztowy odbiorcy 42 moŝe łączyć się periodycznie na przykład co 2 minuty (w zaleŝności od

- 21 - EP 2 174 46 B1 swoich ustawień konfiguracyjnych) z serwerem odbiorcy 3 celem określenia czy znajdują się na nim nowe wiadomości, a w szczególności nowe wiadomości autoryzacyjne. 1 2 [008] Oczywiście jeŝeli odbiorca nie ma lokalnego serwera pocztowego, wiadomość autoryzacyjna zostanie odebrana z serwera 3 przez jego program pocztowy 41 tak, jak zwykły e-mail. W takim przypadku potwierdzenie autoryzacyjne nie zostanie wysłane, a lokalny serwer nadawcy 12 wyśle po czasie określonym ustawieniach konfiguracyjnych pierwszy, właściwy e-mail znanym sposobem transmisji. JeŜeli jednak serwer pocztowy odbiorcy 42 obsługuje sposób według wynalazku w kolejnym kroku moŝe on określić czy parametry pierwszej wiadomości są zgodne z jego ustawieniami domyślnymi lub podanymi przez odbiorcę. MoŜe na przykład określić czy załączniki jakie zamierza wysłać nadawca zgadzają się z typem załączników jakie akceptuje odbiorca, etc. [009] W następnym kroku lokalny serwer pocztowy odbiorcy wysyła kanałem P2P (w szczególności szyfrowanym) wprost do lokalnego serwera pocztowego nadawcy potwierdzenie otrzymania Ŝądania autoryzacyjnego, wraz z akceptowalnymi parametrami pierwszej wiadomości. JeŜeli nie są one akceptowalne przez nadawcę, ma on moŝliwość negocjacji polegających na wysłaniu kolejnej, trzeciej i ewentualnie dalszych wiadomości zawierających Ŝądania autoryzacyjne, aŝ do zaakceptowania formy pierwszej wiadomości przez lokalny serwer pocztowy odbiorcy. [0060] Ostatnim etapem jest przesłanie pierwszej wiadomości przez lokalny serwer nadawcy 12 kanałem P2P (w szczególności szyfrowanym) wprost do lokalnego serwera odbiorcy 42 i zakończenie połączenia. Wiadomość moŝe teŝ być oczywiście przesyłana pomiędzy lokalnym serwerem nadawcy 12 a lokalnym serwerem odbiorcy 42 fragmentarycznie w zaleŝności od moŝliwości zestawienia połączenia pomiędzy nimi. Z lokalnego serwera odbiorcy 42 wiadomość jest przekazywana do programu pocztowego odbiorcy 41 wprostbądź tez po wykonaniu przez odbiorcę polecenia Odbierz z paska narzędziowego programu pocztowego 41. [0061] Do przesłania pierwszej, właściwej wiadomości według tej implementacji wynalazku konieczna jest więc jedynie tylko jedna sesja połączenia.

- 22 - EP 2 174 46 B1 1 2 [0062] Fig. 8 i ilustrują kolejną implementację wynalazku do zastosowania w programach pocztowych obsługiwanych za pomocą przeglądarek internetowych, takich jak Hotmail, bądź Gmail określanych ogólnie jako webmail. W pierwszym kroku nadawca łączy się za pośrednictwem przeglądarki internetowej 13 ze swoim serwerem pocztowym 3, korzystając z protokołu HTTP lub szyfrowanego, bezpiecznego protokołu HTTPS i po zalogowaniu ma dostęp do swojego programu pocztowego 11a, pracującego jako skrypt server-side na serwerze pocztowym nadawcy. Kontrolowany lokalnie przez przeglądarkę internetową 13 program pocztowy 11a, przy pierwszym uruchomieniu instaluje za zgodą nadawcy na jego komputerze 1 aplet 12a, który pełnić będzie funkcję lokalnego serwera pocztowego zintegrowanego funkcjonalnie z programem pocztowym 11a. Podobny aplet 42a zainstalowany jest na komputerze odbiorcy 4. [0063] Nadawca tworzy następnie pierwszą wiadomość i potwierdza zamiar jej wysłania do określonego odbiorcy bądź odbiorców. Program pocztowy 11a sprawdza czy odbiorca o danym adresie e-mail obsługuje sposób transmisji według wynalazku i czy znany jest adres IP lokalnego komputera odbiorcy 4. JeŜeli tak, program pocztowy 11a wysyła do lokalnego serwera pocztowego nadawcy 12a polecenie wysłania pierwszej wiadomość kanałem P2P do lokalnego serwera pocztowego odbiorcy 42a. JeŜeli brak takich informacji dla odbiorcy, program pocztowy 11a tworzy i wysyła Ŝądanie autoryzacyjne do serwera pocztowego odbiorcy 3. JeŜeli serwer pocztowy odbiorcy 3 nie obsługuje transmisji P2P według wynalazku Ŝądanie autoryzacyjne nie zostanie odpowiednio zinterpretowane. MoŜe być ono jednak obsłuŝone dalej przez lokalny serwer pocztowy odbiorcy 42 (por. fig. 7 i 9). JeŜeli nie zostanie ono obsłuŝone, program pocztowy nadawcy 11a moŝe wysłać do odbiorcy pierwszą wiadomość w znany sposób po pewnym czasie. [0064] W rozwiązaniu pokazanym fig. 8 i fig. z serwerem pocztowym odbiorcy 3 współpracuje jednak program pocztowy odbiorcy 41a. Po kolejnym zalogowaniu się odbiorcy na swoim serwerze pocztowym 3, jego program pocztowy 41a, sterowany lokalnie przez przeglądarkę internetową odbiorcy 43 uzyska informacje o adresie komputera odbiorcy 4, którą będzie mógł przekazać wraz potwierdzeniem otrzymania Ŝądania autoryzacyjnego do programu pocztowego nadawcy 11a, celem zestawienia