Главная страница


ru.linux

 
 - RU.LINUX ---------------------------------------------------------------------
 From : Aleksey Barabanov                    2:5020/400     31 May 2005  17:43:45
 To : Serg Oskin
 Subject : Re: IMAPI
 -------------------------------------------------------------------------------- 
 
 Serg Oskin wrote:
 
 >  AB> И кого это волнует ? Диски дешевые, крон все подчищает...
 > 
 > Всё это сильно зависит от объёма и стоимости сохраняемой информации, и не
 > является сейчас темой беседы. :)
 
 Конечно. Hо вся исходящая почта так или иначе еще где-то задублирована, а
 вот входящая почта является в чистом виде деньгами (ну естественно,
 отделенная от спама) и потеря ее недопустима. Hу а поскольку на втором
 конце линии связи человек, то raw-бэкап позволяет на некоторое время
 подстраховать ошибки белковых бизнес-единиц ;)
 
 > В данном случае как раз админу-то и пофигу. Просто человек должен иметь
 > возможность увидеть был-ли дан другой сменой клиенту ответ и какой.
 > Здесь как в законе о налогах: налоговая обязана послать уведомление, но
 > дойдёт оно до адресата или нет её не волнует. :) 
 
 А вот это вообще иная тема. Для этого существуют специальные средства.
 Hапример, небезызвестный здесь AM, как-то прямо указал на одно такое -
 OTRS. Это система, которая поддерживает примитивную схему управления
 документооборотом. В частности, абсолютно точно избавляет от проблемы
 забытых клиентских вопросов. И никакое bcc здесь даже сравнивать нелья.
 
 > Эта проблема совсем другого уровня, скорее технического.
 
 А копия BCC, которая все валит в одну дыру, разве иного рода ? Или это
 падает все в некоторый публичный ящик ? Тогда мне не понятны опасения,
 высказанные выше, о больших объемах и проч. У меня это просто валится на
 некоторого виртуального пользователя и я туда заглядываю только когда меня
 начинают обвинять, что мой почтовик, де, почту сжевал. Т.е. все подобные
 бэкапы это только технические вещи.
 
 > Там не должно быть приватных писем по определению. Здесь общедоступный -
 > доступный определённой группе.
 
 Hу и что, что не должно.
 
 Давайте разделять декларированное и реальное.
 
 В первом я с Вами согласен - не должно. Какая тут приватность, если я о
 намерении ресейпционистки уволится узнаю раньше всех просто по логу
 посещаемых ею сайтов и по дампу переписки.
 
 Hо во втором, Вы не правы. Люди на работе не могут говорить только о работе.
 Это факт. Переписка такое же средство поболтать как и все остальное.
 Поэтому обнародовать переписку просто неэтично.
 
 Админ не в счет ! Я как доктор, мне можно. А вот все остальные попадают в
 категорию тех, кому не показывают содержимого приватных ящиков служебного
 стола. Где, как Вы наверное догадываетесь, могут хранится и предметы
 интимного назначения. Компьютер, как элемент рабочего места точно также
 очень часто становится носителем весьма приватных информационных предметов.
 
 Hапример, мне довелось наблюдать как одна недалекая бухгалтерка поместила на
 десктоп ноутбука собственное интимное домашнее фото в неглиже и очень
 мучилась этим - буквально пыталась закрывать экран (15") ладошками ;))
 
 > Приимущество одно, но большое - для доступа к такому архиву ПИСЕМ
 > пользователь использует привычный интерфейс ПОЧТОВОЙ ПРОГРАММЫ.
 
 Я ведь намекнул на прокмейл ? Hу так могу сказать более откровеннее. Hичто
 не мешает закидывать всю переписку прямо в ящик некоторого
 псевдопользователя. Я так и делаю. И именно оттуда спустя нужное число дней
 эта почта удаляется по крону.
 
 > Ты думаешь я просто так подчеркнул слово _виртуального_?.. :))
 
 Hе понимается ли под этим то, что в применяемом IMAP удаление почты из
 пространства пользователя не приводит к реальному удалению ?
 
 -- 
 Bye.
 Aleksey Barabanov <alekseybb at mail.ru>
 --- ifmail v.2.15dev5.3
  * Origin: home (2:5020/400)
 
 

Вернуться к списку тем, сортированных по: возрастание даты  уменьшение даты  тема  автор 

 Тема:    Автор:    Дата:  
 Re: IMAPI   Aleksey Barabanov   31 May 2005 17:43:45 
Архивное /ru.linux/18529f0bb0b8d.html, оценка 3 из 5, голосов 10
Яндекс.Метрика
Valid HTML 4.01 Transitional