Ограничить пользователя числом получателей

[Jhareg]

Доброго времени суток!

Есть такая задача:
Нужно ограничить пользователя (х) числом получателей, т.е. от определенный пользователь (х) не должен отправлять всем. Он должен отправлять только тем, кто находиться в его отделе.
Это необходимо с точки зрения безопасности.

Как можно это реализовать?
Можно ли делать типа как захват писем пользователя (х) на почтовом серваке?
Или можно создать агент по событию на почтовой базе пользователя (х)?
Или сделать кнопку "Отправить" пользователя (х) специальной? Как это сделать?

Помогите пожалуйста.
Спасибо!

 

[Мыш]

Можно ли делать типа как захват писем пользователя (х) на почтовом серваке?

Да, можно купить спец. софт или написать hook самому. Стандартными почтовыми правилами, боюсь, замучаетесь решать.

Или можно создать агент по событию на почтовой базе пользователя (х)?

Хммм.. Допустим, можно у всех пользователей агентом по приходу новой почты удалять письма, которые они не хотят получать. Но это опять же туча агентов во всех почтовых базах, боюсь, будут траблы с производительностью.

Или сделать кнопку "Отправить" пользователя (х) специальной? Как это сделать?

В GUI-интерфейсе лучше не ограничивать, т.к. письмо можно отправить сторонней программой (через лотусовый COM-интерфейс, например). Там никакие кнопки не задействованы.
ЗЫ. Если пользователей много (скажем, десятки), то лучше 1-й вариант, ИМХО.

 

[divankin]

В GUI-интерфейсе лучше не ограничивать, т.к. письмо можно отправить сторонней программой (через лотусовый COM-интерфейс, например). Там никакие кнопки не задействованы.

Письмо отправить сторонней программой, конечно, можно. Но мало кто умеет делать, а еще меньше так делают. И этим людям та же безопасность объяснит, что так делать больше не надо.

Поскольку задача стоит в ограничении количества адресатов при отправке пользователем именно из своего почтового ящика, то и решать ее стоит правкой именно почтового ящика пользователя. Так не будет ограничиваться отправка всяких уведомлений скриптом от имени пользователя. При этом намного легче, чем в других способах раздавать разным пользователям разные ограничения.

Кстати, не забудьте про группы, перед расчетом количества адресатов вам нужно будет раскрыть все группы.

 

[Мыш]

Поскольку задача стоит в ограничении количества адресатов при отправке пользователем именно из своего почтового ящика

Неа, она так не ставилась. А если у него есть доступ к неск. ящикам? А если есть какие-нибудь прикладные базы (типа форумов), из которых могут отправляться уведомления?
Да, в самом примитивном варианте - обработка события QuerySend во всех формах (а их, кстати, немало)...

Но мало кто умеет делать

Да дело даже не в этом - "кривые ручки" смогут отправить "незаконное письмо" быстрее, чем злонамеренный хакер, проверено! :-D

 

[savl]

А если рассматривать решение в целом, а не code only ...
Можно ли как-то влиять на рассылку средствами администрирования?
Можно ли совместить программную часть с настройками сервера?

 

[erdi]

как вариант можно создать еще 1 почтовый сервер. а пользователям прописать что письма уходят на этот доп сервер
на том сервере создать правило что все письма перемещаются в некую базу
в базе агент, которые обрабатывает все эти письма - хорошие отправляет на основной сервер, плохие заворачивает с уведомлением автору

 

[Jhareg]

всем спасибо!
вижу тут скорее нужно будет создавать свой хук. Но как его создать?

А можно ли как-нибудь настроить с помощью "Mail journaling"?

 

[lmike]

всем спасибо!
вижу тут скорее нужно будет создавать свой хук. Но как его создать?

А можно ли как-нибудь настроить с помощью "Mail journaling"?

только настроить - низя, надо писать агент, дополняя настроить
о чем написал erdi

 

[Мыш]

как вариант можно создать еще 1 почтовый сервер. а пользователям прописать что письма уходят на этот доп сервер

Хммм, ТЕОРЕТИЧЕСКИ (не проверял) можно и 1-м сервером обойтись. Создаем правило для журналирования, при котором все письма помещаются в некую базу. В ней обрабатываем письма и "хорошие" копируем назад в mail.box. Поскольку поле $JournalResponsibility будет уже заполнено, правило, ПО ИДЕЕ, повторно не сработает. Главное, поле это не удалять.

 

[Jhareg]

Хммм, ТЕОРЕТИЧЕСКИ (не проверял) можно и 1-м сервером обойтись. Создаем правило для журналирования, при котором все письма помещаются в некую базу. В ней обрабатываем письма и "хорошие" копируем назад в mail.box. Поскольку поле $JournalResponsibility будет уже заполнено, правило, ПО ИДЕЕ, повторно не сработает. Главное, поле это не удалять.

идею может и хорошая. но в моем случае нужно будет обрабатывать письма более 1000 пользователей. это еще не считая документооборот.

а как создать хук?
что для этого требуется?

 

[ToxaRat]

задача стара как мир
делал такое когда в банке работал

создаёшь всего ОДНО правило: если в BCC НЕ "херня" то заворачивать в спец. базку

а там уже клепаешь агентика, который проверяет письмо по справочнику организации и заново ложит письмо в mail.box + в BCC добавляет "херня"

всё просто

единественное что агент будет создавать задержку в 5 мин. так как он моментально по приходу почты не запустится, но это даже лучше

 

[Jhareg]

задача стара как мир
делал такое когда в банке работал

создаёшь всего ОДНО правило: если в BCC НЕ "херня" то заворачивать в спец. базку

а там уже клепаешь агентика, который проверяет письмо по справочнику организации и заново ложит письмо в mail.box + в BCC добавляет "херня"

всё просто

единественное что агент будет создавать задержку в 5 мин. так как он моментально по приходу почты не запустится, но это даже лучше

где на серваке создать правило?
"заново ложит письмо в mail.box" - как это? вроде бы если подписать другим то агент отправит сообщение под подписанным пользователем

можно ли сделать так чтобы с помощью правил перенаправлять письмо пользователя в отдельную базу там обработать ее и положить обратно в mail.box?

 

[ToxaRat]

правило на сервере - move to database...

а заново ложить в mail.box - это стандартная лотусиная база, ну называется специфически и всё, стандартная команда doc.copytodatabase...

 

[yerke]

или можно так
если у вас все ящики ночью обновляется с шаблона на серваке

то на шаблоне делаете агент с типом Before new mail arrives

который будет проверять подразделение отправителя с подразделением владельца ящика
если они не равны - док удаляется с ящика получателя до того как он переместится в папку инбакс
если равны пропускаете док

плюсы
1) будете разбатывать только в одном месте --на шаблоне ящиков
2) можете заруливать профиль с именами сотрудников, кого нельзя проверять

 

[phantom76]

я всегда дорабатывал шаблон почтовой базы. Доработайте его , поставьте проверку при отправке, если больше 10 адресов, выдавать предупреждение. Соответственно юзеры не должны иметь права выше редактора на свой ящик. если нужно какие-то адреса скрыть от пользователя - скройте их в DD от лишних глаз. начиная с 7-ки если юзер не видет внутренний адрес в DD отправить на него ничего не сможет, даже если вобъет адрес руками в поле.

 

[Jhareg]

всем спасибо за ответы.

хороший вариант с обновлением шаблона на сервере. но я не очень хорошо знаком с администрированием и мало опыта в части программировании. вдруг что не так сделаю на серваке. потом наши админы будут вещаться.

скорее всего буду делать изменения в клиентской базе пользователя.
но куда вносить изменения?
Событие QuerySend в каких формах вносить?

 

[Мыш]

Событие QuerySend в каких формах вносить?

Хехе, а я же тебе говорил, я же предупреждал...Я ж тебе шанс давал... (с)
Сходу - Memo и Reply (не помню, Reply-To-Reply отменили как форму?). Если используете C&S - то не знаю, всякие там invitation'ы используются... Короче - если ДЕЙСТВИТЕЛЬНО надо для безопасности, ковыряйте серверные решения (их тут много накидали). Если так, для галочки - ковыряйте дизайн почтовых баз (вышеуказаннные формы). Трушной безопасности при последнем варианте не будет, я уже говорил.

 

[Jhareg]

Хехе, а я же тебе говорил, я же предупреждал...Я ж тебе шанс давал... (с)
Сходу - Memo и Reply (не помню, Reply-To-Reply отменили как форму?). Если используете C&S - то не знаю, всякие там invitation'ы используются... Короче - если ДЕЙСТВИТЕЛЬНО надо для безопасности, ковыряйте серверные решения (их тут много накидали). Если так, для галочки - ковыряйте дизайн почтовых баз (вышеуказаннные формы). Трушной безопасности при последнем варианте не будет, я уже говорил.

спасибо!

 

[ToxaRat]

всем спасибо за ответы.

хороший вариант с обновлением шаблона на сервере. но я не очень хорошо знаком с администрированием и мало опыта в части программировании. вдруг что не так сделаю на серваке. потом наши админы будут вещаться.

скорее всего буду делать изменения в клиентской базе пользователя.
но куда вносить изменения?
Событие QuerySend в каких формах вносить?

странный подход конечно

и там и там требуется программирование, где ты выиграешь?

у кого-то ПЯ будет по дизайну 5,6,7,8ки под всё будешь писать код?
а кто-то случайно отреплейсит локально, будешь за этим следить?

код должен быть в одном месте и проходить письма через одну точку

 

[Jhareg]

странный подход конечно

и там и там требуется программирование, где ты выиграешь?

у кого-то ПЯ будет по дизайну 5,6,7,8ки под всё будешь писать код?
а кто-то случайно отреплейсит локально, будешь за этим следить?

код должен быть в одном месте и проходить письма через одну точку

возможно вы правы.
спасибо.