8.02.2007
Cofnij wysłanego emaila
Jakiś czas temu pisałem o przypadkowym wysłaniu emaila i o tym, jak można by sobie z tym poradzić. Chodziło o to, że czasem wyśle się maila do niewłaściwej osoby albo maila niedokończonego (skrót klawiaturowy), czy też maila bez załącznika. W dyskusji szukaliśmy rozwiązania wewnątrz samego programu pocztowego.
Jest jeszcze druga metoda. Można wbudować w protokół wysyłania poczty mechanizm “undo”!
Działa to tak: w chwili, gdy wysyłam email, mój program pocztowy dostaje od serwera pocztowego jednorazowy (losowy) token, który zostaje też przekazany dalej razem z samym listem w jakiejś postaci.
W programie pocztowym na liście wysłanych wiadomości mam możliwość cofnięcia danego listu. Gdy kliknę cofnij, następuje wysłanie tokena “dowodzącego”, że to ja wysłałem ten list, tj. mam prawo go cofnąć.
Ten sygnał anulowania listu zostaje dostarczony do serwera pocztowego odbiorcy. Jeśli tam list nie został jeszcze pobrany (serwer wie, czy list był czy nie był pobrany), serwer odbiorcy może być miły i przyjąć prośbę o anulowanie listu - w takiej sytuacji list zostaje skasowany. Odbiorca nigdy nie dowiaduje się, że coś takiego miało miejsce. Nadawca dostaje potwierdzenie, że list został anulowany (to ważne - chodzi w końcu o dobre samopoczucie nadawcy właśnie).
Jeśli odbiorca już pobrał list, nadawca dostaje informację, że niestety, odbiorca zdążył pobrać tę wiadomość.
Nie wiem, czy takie coś jest możliwe w tej chwili - nie znam dostatecznie dobrze konstrukcji serwerów pocztowych ani protokółu SMTP - ale podejrzewam, że da się to zrobić tak, aby tylko nadawca lub dowolny serwer “po drodze” mógł anulować list, a nie ktokolwiek inny. (Czyli ja nie mogę anulować cudzego listu - to podstawowe zabezpieczenie.) Dowolny serwer pocztowy “po drodze” i tak może zrobić to, co chce, z danym listem, więc nie ma problemu zaufania do serwera z powodu anulowania.
Implementujemy to i voila! Można cofać wysłane emaile. No to hop, gdzie jest problem, z powodu którego takiego mechanizmu do dzisiaj nie ma?
Problem jest w tym samym miejscu, co przy próbach anulowania nadanej audycji telewizyjnej. Ów mechanizm sprowadzałby się do apelu “nie czytaj a jak przeczytałeś to zapomnij a jak nie zapomniałeś to przynajmniej udawaj”.
Nie masz jakiejkolwiek kontroli nad cudzymi systemami i nigdy nie będziesz miał, kropka. Nigdy nie będziesz wiedział, czy otrzymane potwierdzenie nie jest podpuchą, a “anulowany” email nie został opatrzony wykrzyknikiem. Nigdy.
Chwileczkę, Tomku, dwie sprawy:
1. Jeśli system działa tak, jak opisałem, to odbiorca nie dostaje tego maila. (A jeśli go dostał, anulowanie nie następuje i nadawca wie, że nie nastąpiło.)
2. CAŁY system poczty działa na zasadzie zaufania. Cały Internet działa na zasadzie zaufania: dowolny serwer po drodze może nie przekazać pakietu, podglądnąć go, skopiować do archiwum, zmienić, przesłać gdzieś indziej.
Dlaczego miałbym nie ufać im z anulowaniem emaila?
Oczywiście, niektórzy będa mieli serwery pocztowe, które udają, że anulowały, a tak naprawdę te maile dojdą - ale co na tym zyskają konkretne osoby? Ot, kilka przypadkowych maili w ciągu roku i tyle…
Nie da się. W SMTP łączysz się ze swoim serwerem, a ten łączy się z innym, niekoniecznie docelowym, serwerem. Taki łańcuszek może być długi. \Problem w tym że nigdy nie będzie w 100% wiadomo czy serwer docelowy wspiera mechanizm “undo”. Brak pewności - pewna frustracja użytkowników.
Dodatkowym problemem są mechanizmy antyspamowe. Często dostęp do serwerów SMTP jest blokowany dla pewnych zakresów IP (np dynamicznie przydzielanych), bywa że na firewallu, w związku z czym serwer nawet nie wie że coś jest blokowane. Na odblokowanie raczej nikt się nie zgodzi, bo strasznie wzrośnie obciążenie serwerów.
AdamK: “Problem w tym że nigdy nie będzie w 100% wiadomo czy serwer docelowy wspiera mechanizm ?undo?.”
Hmm, z definicji jeśli ktoś czegoś nie wspiera, to u tego kogoś jakaś funkcja nie działa. Nie dotyczy to więc tylko tego pomysłu na undo emaila, tylko wszystkich pomysłów na świecie :)
Brak pewności: oczywiście. System nie ma być 100% skuteczny. Serwer może kłamać, że anulował wiadomość, a wcale tego nie zrobił: tak samo serwer poczty może kłamać, że wysłał wiadomość, mimo że jej nie wysłał. W otwartych protokołach tego typu nie ma nigdy pewności niczego :)
Nie o pewność mi chodzi, a o dodatkowe koło ratunkowe.
Teraz problem antyspamowy: nie do końca rozumiem, o co chodzi. Serwery SMTP pomiędzy sobą muszą się komunikować - jeśli nie ma między nimi żadnej komunikacji, to anulowanie jest po prostu niepotrzebne. Jeśli komunikacja jest, to można też anulować list.
Opisany mechanizm nie generuje spamu, ponieważ nie tworzy żadnej nowej wiadomości, a jeśli już, to dla nadawcy. Proszę bardzo, spamer może siebie sam spamować udawanymi komunikatami o anulowaniu wiadomości - do odbiorcy nic nie dociera.
Podsumowując: “pewność”, “100%”, “gwarancja” - obecnie w świecie email coś takiego nie istnieje. Nie musi więc, jak sądzę, istnieć w świecie emaila z anulowaniem. Chodzi mi o możliwość wysłania prośby o anulowanie, która powinna zostać spełniona przez serwer odbiorcy. Jeśli się nie uda, trudno.
Jednak dając taką możliwość nadawcy, wskazujemy, że ma jakąś możliwość naprawienia swojego błędu poprzez system, z którego korzysta. Obecnie nie ma takiej możliwości, co jest nieprzyjemne. Ludzie sie mylą: dajmy im szansę naprawić swój błąd. (Nawet jesli czasem - np. ze względu na “oszukujący” serwer albo jakieś problemy wynikające z antyspamów, choć tutaj nie widzę, na czym to miałoby polegać - to nie zadziała.)
Nie wiem czy wiesz, ale taką funkcję ma MS Outlook w połączeniu z kontem na serwerze Exchange …
Anonymous: nie wiedziałem, że istnieje taka możliwość. Super! Postaram się dotrzeć do jakiejś sieci korzystającej z Exchange, pogrzebie w sieci.
Właściwie to administratorzy sieci MS powinni o tym wiedzieć dużo.
Opis możliwości Exchange Server - polega to na opóźnionym wysłaniu wiadomości:
http://support.microsoft.com/kb/188696
W zasadzie jest to wystarczające rozwiązanie z punktu widzenia takiej osoby. Sprawdzę jeszcze, czy nie ma jakiejś wtyczki tego typu do innych klientów pocztowych.
“Jeśli system działa tak, jak opisałem, to odbiorca nie dostaje tego maila” - wprowadzasz nieuprawniony podział między “serwer pocztowy (maszynę)” a “odbiorcę (człowieka)” i szukasz rozwiązania, by “człowiek” nie dostał niepożądanej treści przetrzymywanej przez “serwer”.
Poczta elektroniczna jest przesyłana między nadawcą (abstrakcyjnym) a odbiorcą (abstrakcyjnym) i od konkretnego przypadku zależy, który z tych bytów jest człowiekiem, botem, webcamem czy automatem z colą.
Nie zakładam złej woli odbiorcy czy BOFHa, wystarczy jedynie, by maile forwardowały się na inne konto (rzecz nagminna), dawały o sobie znać przez SMSa czy BlackBerry (też często) czy robiły inne rzeczy, o których nadawca nic nie wie.
Twoje “koło ratunkowe” działałoby w tak nielicznych sytuacjach, że można powiedzieć “zgoła nigdy”. W systemach poczty korporacyjnej (Exchange, Lotus), owszem, taka możliwość z reguły istnieje, jest domyślnie wyłączono i nie słyszałem, żeby gdzieś była włączona. Bo to przynosi znacznie więcej problemów, niż rozwiązuje.
Tomek: zbierzmy to.
Innymi słowy, o ile rozumiem, problem polegałby wg Ciebie nie na zbudowaniu tego mechanizmu, tylko na tym, że jest wiele sytuacji, w których serwer odbiorcy po otrzymaniu emaila przekazuje go bardzo szybko dalej i nie da się maila już anulować.
Co za tym idzie, anulowanie (które samo w sobie reprezentuje, na przykład 1% wysłanych maili - pozostałe 99% wysyłamy tak, jak chcieliśmy, i do kogo chcieliśmy) będzie np. w 3/4 przypadków nieudane.
Bo nadawca za długo czekał i odbiorca zdążył odebrać maila, bo odbiorca dostał powiadomienie na sms, bo serwer pocztowy przekazał email dalej. (Ważne: w każdej z tych sytuacji serwer wie, że to przekazał. Innymi słowny, mechanim działa tak, jak trzeba, tylko nie spełnia swojej roli.)
OK. Trzeba by zbadać, jak wielu ludzi i jak często wykorzystuje istotnie mechanizmy przekierowań, powiadomień sms itp. Bo możliwe, że są olbrzymie grupy userów, którzy nigdy z tego nie korzystali i długo jeszcze nie będą korzystali, a ten mechanizm by im pomógł :)
Jeśli okazałoby się, że tych sytuacji, które uniemożliwiają anulowanie, jest dużo — może nie ma w ogóle sensu tego robić. Ale ja na przykład wiem, że w moim przypadku, oraz w przypadku kont na darmowych serwerach pocztowych w Polsce, nie ma żadnego z tych problemów - maile leżą sobie na zwykłym koncie odbiorcy, nie ma powiadomień, nie ma przekierowań. A to są miliony (!) kont pocztowych.
Teraz: firmy są miejscem, gdzie to miałoby zastosowanie. Tutaj już jest różnie. Przekierowania w ramach firmy powinny być rozwiązywane przezroczyście przez serwer. Czyli samo przekierowanie w ramach firmy nie powinno uniemożliwić anulowania (tutaj może być sporo komplikacji).
Nie wiem, jak wiele jest tych mechanizmów przeszkadzających w undo emaila; ale myślę, że nie jest to powszechne. Mam też wrażenie, że implementacja tego mechanizmu jest bardzo tania. (Wysiłek potrzebny do anulowania wiadomości jest porównywalny z wysłaniem 1-2 dodatkowych emaili, a ponieważ robiłoby się to bardzo rzadko, koszt jest żaden.)
Ja osobiście zrobiłbym to inaczej. Serwery pocztowe powinny posiadać dodatkową opcję “poczekaj z wysłaniem maila 30 minut od nadania” (możnaby ją włączać/wyłączać dla danego konta). W tym czasie możnaby anulować wiadomość.
Trochę podobnie działa cancelowanie postów na grupach dyskusyjnych, niestety jedne serwery przyjmują cancele, inne nie, nie ma pewnego sposobu by całkowicie usunąć jakiś post wysłany do usenetu.
Dodawanie takiej funkcjonalności do protokołów pocztowych wydaje mi się niepotrzebne, gdyż mechanizm “undo” jest zawsze potrzebą nadawcy. Dla odbiorcy, jeśli się pomylisz i wyślesz mu kosztorys bez narzutów - będzie to wspaniały prezent :-)
Dlatego rozwiązywałbym to po stronie nadawcy, a więc albo klienta pocztowego, albo klienta pocztowego i serwera smtp. Proste opóźnienie wysłania wszystkich maili o 5 minut może wystarczyć. Oczywiście gdy naciśniemy super-nietypową-kombinację klawiszy, mail można wysłać od razu. W przypadku serwerów, zgadzam się z pomysłem Belloisa.
w ogóle, gdyby programy pocztowe miały funkcję: “dla twojego bezpieczeństwa mail nie został jeszcze wysłany. zrób kilka głębokich wdechów przy otwartym oknie, usiądź, przeczytaj go na spokojnie i zastanów się, czy naprawdę chciałeś wysłać, to co napisałeś”, świat byłby lepszym miejscem :)
a pomysł jest fajny, tylko o jakieś 20 lat za późno wymyślony. absolutnie nierealizowalny.
ps. nie tylko exchange ma taką możliwość. to chyba standard w systemach korporacyjnych.
w Twoim pomyśle jest jeden podstawowy problem - częścią jego rozwiązania jest serwer odbiorcy, nad którym nie masz żadnej władzy, czyli nie musi skasować listu, po otrzymaniu prośby, może poinformować odbiorcę o próbie skasowania, może wysłać fałszywe potwierdzenie skasowania.
Tak więc pomysł bez przyszłości.
Czy tylko ja myślę, że anulowanie wysyłania listu jest… głupie? Bo co, przepraszam, nie umiemy panować nad interpunkcją i ortografią? Emocjami? Listą kontaktów, że nam się coś myli?
Może jeszcze telefony będą pokazywać Yes / No jak wybiorę kogoś z książki telefonicznej i nacisnę przycisk ze słuchawką?
Sorry, ja tego nie pojmuję, wy tu gadacie o technologiach, problemach z prywatnością, ale… po co?
Jakub: od strony technicznej wycofanie maila jest łatwe w realizacji jedynie w systemach poczty korporacyjnej, idealnie homogenicznych. Z podobnych powodów tylko tam da się wysłać mailem stumegowy załącznik setce osób, ale powstrzymajmy szarpiącą się dygresję. W prawdziwym życiu jeden program odbiera pocztę protokołem SMTP, inny program dostaje tę pocztę do zapisania w przechowalni, jeszcze inny przefiltruje antywirusowo, nierzadko dodatkowy program tę przechowalnię przeora w celu zindeksowania lub dowolnym innym a tak naprawdę, jak zajdzie potrzeba, to cała przechowalnia może być replikowana na innej maszynie, poddawana dalszym przekształceniom wskutek których gdzieś na szarym końcu łańcuszka użytkownik będzie mógł tę wiadomość odczytać. Dodajmy, że każdy z kroków może zostać zrealizowany na n różnych sposobów. Tego się po prostu nie da zrobić.
Jeśli ktoś ma problemy z emocjami, potrzebuje lokalnego proxy SMTP zatrzymującego maile przez zadany okres czasu. Albo niech lepiej w ogóle nie pisze maili, tylko dyktuje.
Riddle: też nie wiem :-]
Cieszę się, że Was to ruszyło. :)
Riddle: podniosłeś ciekawe zagadnienie - po co w ogóle coś takiego, jak anulowanie maila!
Ludzie popełniają błędy. Mechanizm “undo” w edytorze tekstu jest standardem i wydaje się naturalny, a mechanizm cofnięcia emaila - nie. Czemu?
Czemu nie miałbym anulować wysłania emaila? Albo wysłania smsa? Albo rozpoczętej przez przypadek rozmowy telefonicznej, żeby nie musieć płacić?
Czemu nie mogę anulować instalacji szkodliwego oprogramowania? Albo wiadomości wysłanej przez Skype?
Przycisk “Wstecz” w przeglądarkach jest chyba najpotężniejszym dowodem na to, że “undo” jest dobre. Pozwala na eksplorację z poczuciem pewności, że jak coś sknocę, mam szansę się z tego wycofać.
Tam, gdzie to poprawi komuś humor, zwiększy pewność siebie lub poprawi wydajność pracy mechanizm Undo ma dużą wartość. To dla mnie wystarczająca motywacja, by o tym myśleć. Nie twierdzę, że to bardzo ważne. Świat rozwija się super i bez tego.
Zastanawiająco często jednak ludzie wokół mnie, z różnych powodów, wysyłają emaile np. do klienta zamiast do kogoś w zespole, bo są przyzwyczajeni do używania podpowiedzi z klawiatury (wpisujesz “t” i widzisz osoby na literę “t” zapamiętane w książce adresowej), a nagle jakaś osoba wskakuje przed tą najczęściej wybieraną i leci sobie wewnętrzy mail do Klienta. Zdarza się. Stres. W ciągu kilku sekund mógłbyś kliknąć “anuluj” i na pewno byś zdążył :)
Może to być w programie pocztowym.
Mnie zdarza się przez przypadek wysłać SMS nie tam, gdzie chciałem. Gdyby moja Nokia miała przycisk “cancel last SMS”, nie byłbym nieszczęśliwy.
I tylko o to chodzi.
Jeśli jesteś supersprawny i nie popełniasz takich “głupich” błędów - wspaniale! :)
Widzieliście gdzieś jakieś nietypowe mechanizmy undo? Nietypowe, tzn. zachowujące się dziwnie lub anulujące rzadko spotykane czynności?
“Przycisk “Wstecz” w przeglądarkach jest chyba najpotężniejszym dowodem na to, że “undo” jest dobre. Pozwala na eksplorację z poczuciem pewności, że jak coś sknocę, mam szansę się z tego wycofać.”
a możesz mi wpłacić jakąś większą sumkę paypalem, a potem, proszę bardzo, nawet 100x naciskać sobie “wstecz”?
nie bez przyczyny POST i poczta mają wspólny źródłosłów.
Marcin: OK, ile potrzebujesz?
8h snu :) a jutro mi wytłumaczysz, w jaki sposób wycofuje się z różnych głupot zrobionych w sieci via klawisz back. mogę położyć na nim cegłę (kładąc uprzednio monitor)
czy cegła położona na monitorze naciska elementy gui? skoro “back” anuluje dane wysłane przez POST, we wszystko jestem skłonny uwierzyć :)
“Czemu nie miałbym anulować wysłania emaila? Albo wysłania smsa? Albo rozpoczętej przez przypadek rozmowy telefonicznej, żeby nie musieć płacić?”
Ty po prostu chciałbyś cofnąć czas. Ostatnie badania na ten temat prowadził Jańcio Wodnik, bez pozytywnych rezultatów niestety.
O ile z zasadnoscia istnienia takiego mechanizmu musze sie zgodzic, to z implementacja juz nie.
Pierwszy problem polega na zrzuceniu odpowiedzialnosci za sledzenie przesylki na “third party”. Zastanowmy sie jak bardzo wzrosnie zapotrzebowanie na zasoby.
Twoj serwer wychodzacy dostarcza przesylke wraz z tokenem do (znanego jemu, temu serweru ;) nastepnego serwera. W tym momencie musi zapisac skojarzenie tokena z wyslana wiadomoscia.
Po drodze moze byc kilka/kilkanascie serwerow. Wiec kazdy z nich musi przechowac wszystkie skojarzenia MSGID+token oraz odbierac dodatkowe polaczenia. Co zatem z zasobami potrzebnymi do przechowywania i sledzenia tych danych?
Tomek: OK, przyłapałeś mnie - chcę cofnąć czas. (Zgodziliśmy się jednak, że to wykonalne, tylko bardzo rzadko. To jednak coś, prawda? :P)
Marcin: wycofanie w sensie łatwego powrotu “tam, gdzie przed chwilą byłem”. Jeśli w edytorze tekstu nagle usuniesz cały akapit jakimś nieznanym Ci skrótem klawiaturowym, który przez przypadek został użyty, wracasz do stanu poprzedniego przez undo. Jeśli na stronie WWW klikniesz na jakiś link i on zaprowadzi zupełnie nie tam, gdzie oczekiwałeś, używasz “undo”, czyli “back”, żeby wrócić do bezpiecznego, poprzedniego stanu wyjściowego. Nie miałem na myśli transakcji. Oczywiste, że jeśli zawarłeś już transakcję, to z jakiegoś powodu jej cofnięcie drugiej stronie się nie opłaca, więc proste “nie, jednak tego pierścionka nie kupiłem” nie ma prawa pojawić się w sklepie internetowym. :)
zen: może jeśli rozwiązałoby się to przez ukrytą parę klucz prywatny i publiczny lub analogiczny mechanizm, to nie byłoby tego problemu - token jest wtedy podpisem elektronicznym wiadomości. Para kluczy może być generowana dla konta nadawcy “w tle” - użytkownik w ogóle nie musi mieć żadnego oprogramowania ani wiedzy, że coś takiego ma miejsce, więc nie ma problemu z edukacją użytkowników, koniecznością ręcznego generowania sobie kluczy itp. Token nie musi być wtedy przechowywany na całej ścieżce, bo wędruje razem z listem (to jest ten podpis), a w razie konieczności sprawdzenia, czy ktoś ma prawo z niego skorzystać, żeby anulować wiadomość, serwer nadawcy dysponuje kluczem prywatnym, którym może udowodnić, że “to moje”). Ale rzeczywiście, wymaga to czegoś po stronie nadawcy, czego teraz być nie musi.
Możliwe, że bardzo upraszczam, że jest tu dużo ukrytych barier i samo dodanie nowej komendy do oprogramowania przesyłającego pocztę nie wystarczyłoby i tak.
Czy mi się wydaje, czy wy próbujecie usunąć skutek, a nie przyczynę?
Spytam inaczej:
Elsindel, co byś wolał — wsadzić wszystkich morderców za kratki, czy dać żałobnikom przycisk UNDO? Spokojnie ginąłbyś cztery razy w tygodniu, a potem by cię wskrzeszali.
Problemem nie jest to, że nie da się cofnąć wysłanego listu, tylko to, że czasami zbyt prosto (dla ciebie) jest go wysłać.
Nie potrzebujemy większego otwieracza, tylko bardziej miękkiej konserwy.
Patrys: tak, próbujemy usunąć skutek.
Przyczynę próbowaliśmy usunąć w poprzednim tekście:
http://elsinterakcja.pl/2006/11/przypadkowe-wyslanie-emaila/
;)
Rozwinieciem tego pomyslu jest obsluga praw dostepu DRM przez Office. W tym momencie takze wyslanie dowolnego dokumentu do niewlasciwej osoby umozliwia zablokowanie jej dostepu juz po fakcie otrzymania pliku.
Kompletnie bezsensowna dyskusja.
Zamiast tworzyć ułomny mechanizm “undo” albo opóźnianie wysyłania listów, lepiej nie wysyłać listów, które trzeba by potem anulować. Innymi słowy myśleć co się robi przy kompie.
Chronienie użytkownika przed nim samym jest złym podejściem.
Poza tym, dlaczego chcesz skomplikować prosty mechanizm wysyłania poczty elektronicznej?
hig: Mechanizm wysłania emaila będzie tak samo prosty, jak dotąd (dla użytkownika). Chyba że chodzi Ci o stronę serwera - ale nie o tej stronie dyskutujemy. (Chyba że zahacza to o skuteczność mechanizmu.)
Dlaczego chronienie użytkownika przed nim samym jest złe? Czyli kosz do wykonania operacji UNDELETE jest zły? Operacja UNDO jest zła?
A ja w sumie rozważyłbym opcję undo w mailach.
Prowadzę korespondencję z, powiedzmy, 40 osobami. 10 mam wysłać 12 różnych propozycji projektów graficznych, reszcie mam odpisać na maile (tu o pomyłkę trudno), napisać parę zdań, nawiązać do jakiejś rozmowy telefonicznej, do tego ktoś dzwoni, coś się rozjeżdża, kogoś trzeba przypilnować, ktoś zagaduje i bam, wysyłam maila np z projektem do niewłaściwej osoby.
To nie jest coś nadzwyczaj niespotykanego.
Mogę oczywiście powiedzieć: sory, skasuj tego maila.
bardzo podoba mi sie Twoj pomysl. Sadze, ze zaimplementowanie czegos takiego spowodowalo by ze swiat bylby lepszym miejscem. O pomylke naprawde nie trudno i ludzie potrzebuja mechanizu zofania takze w mailach.
Czy ten akurat pomysl jest realizowalny to inna sprawa, ale dobrze jest czasami “odwrócić twarz w strone wiatru innowacji” i pomyslec do przodu zamiast do tylu
hehe. niesamowita dyskusja. naprawde, mozna usmiac sie do lez, zwlaszcza nad tymi analogia przycisku cofnij do cofania niechcianych rozmow telefonicznych czy smsow lub nad wszystkimi biednymi uzytkownikami, ktorzy korzystaja z milionow darmowych kont bez przekierowan ani powiadomien (latwo sprawdzic, ze nawet darmowe konta takie mozliwosci daja).
a tak naprawde imo dziala tu dokladnie taki sam mechanizm jak przy innych probach chronienia uzytkownika przed nim samym, te wszystkie denerwujace pytania o potwierdzenie (przy innej okazji tu krytykowane), ktore jesli tylko sie da, to n % uzytkownikow wylaczy (analogicznie jak w “super bezpiecznej”, acz denerwujacej viscie). to samo dotyczy wbudowanych opoznien, zwlaszcza jesli userzy sa zmuszeni dzialac w pospiechu (wtedy czesciej sie myla, ale wtedy tez opoznienia moge im utrudnic zycie).
coz, myslenie ponoc jest tworcze. myslenie przed wyslaniem maila rowniez ;-)
Właśnie wysłałem maila i po sekundzie zorientowałem sie ze przez przypadek w jednym z załączników znalazły się bardzo ważne prywatne informacje i czekają mnie teraz niepotrzebne komplikacje. Wiele bym dał za takie cofanie maila dziś :P Popieram pomysł całym sercem!!!!
Wbudowanie takiego mechanizmu to protokołu SMTP jest raczej nie możliwe, z prostego powodu, że jest on już niemal tradycją i zmiana w nim czegokolwiek byłaby łamaniem (nie najlepszego, ale ogólnie przyjętego) standardu. Istnieje nowocześniejszy protokój IMAP i kto wie, czy nie ma takigo bajeru. Jednak ten protokół jakoś się nie przyjął, więc nia ma co się zastanawiać.
Pozostają rozwiązania oparte na SMTP. Mi przychodzi tylko jedno rozwiązanie do głowy, bez ingerencji w protokół, ale wymagające zmian w programie pocztowym. Po kliknięciu “Undo” zostaje wysłany mail z informacją “aby nie czytać poprzedniej wiadomości” do tego samego adresata. Jak program pocztowy odbiorcy otrzymałby taką wiadomość to np. usunąłby nieszczęsny list, albo przynajmniej oznaczył jako pomyłka. Jeśli odbiorca miałby przekierowywania poczty, to wiadomość “undo” poszłaby tą samą drogą, więc dotarłaby do odbiorcy. Wymagamy jednak, aby odbiorca miał program, który obsługiwałby taką opcję.
Oczywiście to rozwiązanie jest oparte na zaufaniu. Nie uchroni nas przed wyciekiem poufnych danych, ale być może unikniemy zamieszania i tłumaczenia się z niepotrzebnej wiadomości.