TEGU Wiki

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

Далее несколько комментариев:

Плахотный Олег писал(а):

• Нет вшитого антиспам решения, которое обучается по нажатию "Это спам" (есть антиспам только по спискам DNSBL и грейлистинг)

Это так и так оно и останется.
Фильтрация спама и вирусов - не задача почтовика. Этим должны заниматься специальные приложения, с которыми предусмотрена интеграция по Milter.

• Нет возможности импортировать/экспортировать список ФИО/почтовых ящиков в CSV или какой-либо другой формат

Увы, это ограничение бесплатной версии.

• Нет встроенной сортировки писем или пересылки, правила можно применять только на уровне почтового клиента

Обработка писем (включая все опции) есть.
Первый уровень это - глобальные правила, задаваемые администратором.
Второй уровень - пользовательские правила, настраиваемые в админке клиента. Адрес админки тот же, что и у администратора, а логин и пароль надо использовать пользовательский. Такой инструмент доступен КАЖДОМУ пользователю.

• Нет алиасов и пересылки на внешние почтовые ящики

Тоже есть. См. выше.

• Нет адресата all@domain.ru, который позволил бы отправить письмо на все созданные ящики сервера (как пример - уведомить пользователей о профилактических работах). Разработчики предлагают каждого пользователя добавлять в группы.

Адреса all нет и не будет. Мы считаем, что это вред т.к. на него будет сваливаться спам. Но вы можете сами создать такой ящик или группу рассылки (и назвать как захотите).

Если возникнут проблемы, обращайтесь, расскажем.
А главное - оставайтесь с нами. Впереди будет еще много интересного.

Второй уровень - пользовательские правила, настраиваемые в админке клиента. Адрес админки тот же, что и у администратора, а логин и пароль надо использовать пользовательский. Такой инструмент доступен КАЖДОМУ пользователю.@

Вот это не знал, спасибо :)

Адреса all нет и не будет. Мы считаем, что это вред@

Хотя бы сделайте переключаемый параметр с текстовым полем (который по умолчанию отключен), в котором можно прописать адрес для массовой рассылки.

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

Плахотный Олег писал(а) (RE: Опыт использования Tegu в организации на 500+ человек...):

Хотя бы сделайте переключаемый параметр с текстовым полем (который по умолчанию отключен), в котором можно прописать адрес для массовой рассылки.

Обещаем подумать над этим.

Спасибо за ответ! И за достойный продукт!

Второй уровень - пользовательские правила, настраиваемые в админке клиента. Адрес админки тот же, что и у администратора, а логин и пароль надо использовать пользовательский. Такой инструмент доступен КАЖДОМУ пользователю.

я так понял такой вход доступен только для локальных пользователей?
от учетных записей LDAP в админ-панель не пускает.

Нет, это доступно для всех пользователей.
Быть может вы неверно составили login?
Т.к. сервер обслуживает любое количество доменов, то логин - это email (с суффиксной частью).

Кальметов Игорь писал(а) (RE: Опыт использования Tegu в организации на 500+ человек...):

Нет, это доступно для всех пользователей.
Быть может вы неверно составили login?
Т.к. сервер обслуживает любое количество доменов, то логин - это email (с суффиксной частью).

с суффиксом @domain пустило! спасибо!

Да, пересылка на внешнии ящики есть.
Но есть одно НО, возможно только у нас)))

Если поставить просто перенаправление на внешний ящик, то не работает. Но если создать ящик как положено, потом сделать правило отправки копии письма на внешний ящик, то работает без проблем, даже с gmail

Виталий,

Вот тут совсем непонятно.

Если поставить просто перенаправление на внешний ящик, то не работает.
Но если создать ящик как положено, потом сделать правило отправки копии письма на внешний ящик, то работает без проблем, даже с gmail

Не понимаю в чем состоит первый и второй вариант? В чем разница? Нельзя ли на конкретном примере?

Кальметов Игорь писал(а) (RE: Опыт использования Tegu в организации на 500+ человек...):

Виталий,

Вот тут совсем непонятно.

Если поставить просто перенаправление на внешний ящик, то не работает.
Но если создать ящик как положено, потом сделать правило отправки копии письма на внешний ящик, то работает без проблем, даже с gmail

Не понимаю в чем состоит первый и второй вариант? В чем разница? Нельзя ли на конкретном примере?

да, конечно
есть домен.ру
потом в домене, в перенаправлении сделать условие 123@домен.ру на ящик 123@гмаил.ком ... то письмо будет висеть в очереди очень долго, и не уйдет...
если сделать ящик 123@домен.ру, потом сделать правило если получатель 123@домен.ру, то отправить копию на 123@гмаил.ком , все отлично уйдет.

Рассмотрим схему:

                       -------------------------------
                       |         Сервер TEGU         |
                       |                             |
ikalmetov@yandex.ru -> |    ikalmetov@mbk-lab.ru     | -> ikalmetov@gmail.com
                       |                             |
                       | Правило пересылки для ящика |
                       -------------------------------

Схема будет работать только в том случае, если ящик ikalmetov@mbk-lab.ru существует т.к. TEGU не является открытым релеем (что запрещено).

PS. Если я правильно понял задачу.

Кальметов Игорь писал(а) (RE: Опыт использования Tegu в организации на 500+ человек...):

Рассмотрим схему:

[...]

Схема будет работать только в том случае, если ящик ikalmetov@mbk-lab.ru существует т.к. TEGU не является открытым релеем (что запрещено).

PS. Если я правильно понял задачу.

да, существующий ящик + условие отправить копию письма
и ваша схема точно это описала.

а релей, как то можно разрешить? что бы по некоторым условиям он выполнялся (например если получатель такой то, то релеем отправить туда то)

а релей, как то можно разрешить? что бы по некоторым условиям он выполнялся (например если получатель такой то, то релеем отправить туда то)

TEGU релеем не является, но может использовать релей (смартхост) при отправке.
Для этого в настройке интернет-домена (хранилища) заполнить поле Смартхост (форматы: user:pass@host:port или host:port).

Смысл такой затеи существенен для серверов, которые "боятся" интернет (например MS Exchange), но для TEGU практический смысл такой схемы сомнителен. Представьте себе кластерный TEGU на несколько сотен тысяч пользователей. Каким для него должен быть релей? Мне кажется, просто не нужен.