Вышел postfix 2.1.0 релиз

И что все срочно обновляться или как?

Да здравствует realtime фильтрация и greylisting! Ура товарищи!

а толку? все-равно принимать. а там реалтайм или нет - уже не важно.

2hjugo:

Очень неправильное мнение. Если у меня _не_ realtime, я должен сказать 250 на DATA, а уж затем проверять письмо. А если я сказал 250, то у меня есть только 2 варианта: 1) доставить письмо в ящик 2) не доставить и сгенерить bounce. _Всё_. Третьего не дано. В 1) фильтрация теряет смысл. В 2) чревато тысячами отлупов в очереди и невинные юзеры, чей e-mail был использован спамером/вирусом получат отлуп. В случае realtime этих проблем нет - и если чьё-то легитимное письмо будет посчитано спамом/вирусом - получит bounce от _своего_ smtp c причиной.

a esli: content_filter = smtp-amavis:[127.0.0.1]:10024 ?

content_filter получает письмо _после_ ответа smtpd на DATA.

Это почему же 3-го не дано? Можно доставить, пометив, что это спам и в
особый ящик положить.

А кто потом всё это разбирать будет? Это ж отдельная ставка для этого нужна... ;)

можно конечно... Тут уже психологический фактор: если фильтр метит аккуратно и легитимные письма крайне редко туда попадают - юзер начинает "доверять" фильтру и либо не заглядывает в папку "спам", либо сносит не глядя... В таком вот случае нормальное письмо либо залежится, либо будет удалено. Можно сказать, конечно, что юзер ССЗБ, но мне лично симпатичнее вариант когда отправитель _сразу_ получит отлуп и сможет принять меры. Ну и червей конечно можно гасить без bounce и без realtime. Но не вирус.

народ, только у меня постфикс не может обрабатывать(не отсылает) письмо нескольким адресатам и по адресу в поле CC? может я че не так делаю? ;)

to abramoff:
не согласен вот почему: смысла отсылать боунсы на спам и вирусы бессмыссленно. имеет смысл только для unknown user. а для обработки контента письмо принимать надо. Так что фича полезная, будет прикручена, но чего-то дополнительного (типа экономии трафика не дает). А видусам и спамерам по большому счету не важно что там сервер ответил...

>отсылать боунсы на спам и вирусы бессмыссленно

Отсылать bounce - да. А вот сказать 555 Spam/virus message discarded - надо. У тебя что, спам-фильтр не ошибается никогда? Как отправитель узнает, что его письмо в мусорке, а не у получателя? Как отправитель узнает, что у него в .doc вирус и поэтому письмо не доставлено?

Вдогонку: надо различать червей и вирусы - на червей не надо bounce слать, а вот на вирусы очень даже надо слать.

Если почтовый сервер ответит 555 на не спамовское письмо,
будет гораздо хуже, чем если фильтром перебрасывать отмеченные письма
в спам-ящик и который чистится недели через 2. За это время ситуация
с потеряным письмом прояснится.

да... ждать 2 недели - это конечно здОрово... Ни отправитель, ни получатель ничего не знают о случившемся. Не лучше ли, чтобы отправитель _сразу_ узнал о проблеме и принял меры?

> Если у меня _не_ realtime, я должен сказать 250 на DATA, а уж затем проверять письмо. А если я сказал 250, то у меня есть только 2 варианта: 1) доставить письмо в ящик 2) не доставить и сгенерить bounce. _Всё_. Третьего не дано.

Может я чего не понял, но у меня постфикс уже давно отучен отвечать 250 на сообщения, содержащие, например, pif-ы с scr-ами во вложениях. Легко строится с помощью body_check-ов :)

Мне вот что интересно. Имеется внешний и внутренний почтовик. Вся почта скапливается на внутреннем. Если снаружи приходит письмо для "vasja_pupkin@mydomain.com", а не внутреннем этого пользователя нет, то внешний принимает письмо, отправляет на внутренний и получает отлуп.

Они год назад работали над реалтайм проверкой адресов доставки. Вроде бы в этой версии сделали. Так ли это ? Я правильно понял значение параметра reject_unverified_sender ?

>отучен отвечать 250 на сообщения, содержащие, например, pif-ы с scr-ами во вложениях.

да, лупить по расширениям - это, конечно, очень интеллектуально. Как быть быть с exe? Как быть с архивом, в котором pif?

>Имеется внешний и внутренний почтовик.

у меня тоже внутренний и внешний. Внешний спрашивает про юзеров по LDAP.

>то внешний принимает письмо, отправляет на внутренний и получает отлуп.

вот из-за таких деятелей весь Интернет хавает чужие bounce. Не пора ли заняться настройкой почты, админы?

2abramoff
>>отучен отвечать 250 на сообщения, содержащие, например, pif-ы 
>>с scr-ами во вложениях. 
>да, лупить по расширениям - это, конечно, очень интеллектуально.
зато эффективно

> Как быть быть с exe?
так же как с pif (imho)

> Как быть с архивом, в котором pif? 
На то антивирус
НО ! антивирь сработает ПОСЛЕ приема письма и его (антивир) не будут
перенапрячать аттаченые exe, pif, ....

P.S.
 Безусловно для провайдера фильтрация аттачей есть скользкая тема,
но для корпоративного уровня вполне пригодно IMHO.

2abramoff
>>то внешний принимает письмо, отправляет на внутренний и 
>>получает отлуп. 
>вот из-за таких деятелей весь Интернет хавает чужие bounce. 
>Не пора ли заняться настройкой почты, админы?
Зря ты так.
А если это "внешний" вообще чужой, который тебе позволили
прописать в твоей зоне как MX c бОльшим весом ?

>твоей зоне как MX c бОльшим весом

secondary mx давно пора ликвидировать как явление. Хочешь несколько mx - ldap/sql/etc тебе в руки. Я отказался от провайдерского secondary mx. Чего и всем желаю.

Провайдерский секондари МХ это не показатель А вот провайдеру иметь секондари МХ желательно. Можно и не один.

> Как быть быть с exe? Как быть с архивом, в котором pif?

exe туда же, куда и pif-ы С архивами хуже :)

> вот из-за таких деятелей весь Интернет хавает чужие bounce. Не пора ли заняться настройкой почты, админы?

Я вот всё ждал этой фичи. Интересно, дождался ли...

Кстати, зря вы так. У меня из левой корреспонденции всего десяток-другой в день прорывается до внутреннего сервера. Это меньше 1% от всей корреспонденции. Остальное "от лукавого" рубится rbl-ми, локальным черным списком, оставшимся в наследство от sendmail, и разноуровневыми правилами фильтрации.

Господа хорошие! Что порекомендуете почитать на тему электронной почты? Ну, кроме RFC, конечно. Интересует почти всё, кроме sendmail-specific информации.

Если бы еще TLS патч выпустили...

>Вдогонку: надо различать червей и вирусы - на червей не надо bounce
>слать, а вот на вирусы очень даже надо слать.
кому ты собираешься слать боунс на вирус? в mail-from? :)

а спам режется с помощью spam-assassin очень просто:
то, что набрало 15 балов грохается без суда и следствия.

то, что от 5 до 15, то помечается заголовком и фильтруется клиентами
в отдельный фолдер.

Ты знаешь, чем отличается вирус от червя? Bounce на вирус я буду слать отправителю. Про "отдельные фолдеры" я уже говорил. По сути, это не фильтрация - это сортировка. Юзер всё равно вынужден рыться в мусоре.

2abramoff
>>твоей зоне как MX c бОльшим весом 
>secondary mx давно пора ликвидировать как явление. Хочешь несколько
> mx - ldap/sql/etc тебе в руки. Я отказался от провайдерского
> secondary mx. Чего и всем желаю.

"Хочешь" ?
Да у меня даже виндузятники головы поотгрызают за smtp с одним MX.
И прааально сделают.
А везде проверку через ldap не настроешь, да те кто предоставит MX
вполне может не захотеть вставлять пальцами в свои настройки.

Да и где ты увидил у меня "провайдерский" secondary ?  ;-)

Ты можешь вменяемо объяснить зачем тебе secondary? Что он тебе даст? По пунктам.

2abramoff
>Ты можешь вменяемо объяснить зачем тебе secondary? 
>Что он тебе даст? По пунктам.
Затем же, зачем и всем.
На маловероятный случай проблем 
1)с hw/sw на primary,
2)каналом/резервным каналом,
3)питанием во всем здании дольше чем 5..6 часов
4)свичем/резервным свичем
5)fw/резервным fw

После устранения проблем, младший MX вывалит ВСЮ входящую почту на домены, как только сможет достучаться сам. Т.е. минимизируется задержка.
Когда это сделает "отправляющий", зависит от алгоритма
обработки исходящей очереди на серваке отправителе, а это ....

sda