Vamsoft выпустил ORF Enterprise Edition 4.0

Расписывать не буду. Приведу текст из письма:

What's new in version 4.0?

* Log Improvements
Email subject logging, improved log filtering and search.

* Auto Sender Whitelist Automatic Response Detection
Prevents automatic responses (e.g. Out of Office autoresponses) from polluting the Auto Sender Whitelist.

* Combined Actions
Allows tagging and redirecting the email at the same time.

* Whitelist Test Exceptions:
This feature allows some blacklist tests to take precedence over
whitelists (Attachment Filtering, External Agents, Active
Directory Integration and the Recipient Blacklist), thus
malicious content can be filtered even when the email source
is whitelisted.

* External Databases
Use Microsoft SQL Server databases for storing the Auto Sender
Whitelist and Greylisting data.

* 64-bit Support
Now you can run ORF on 64-bit Windows Servers.
Learn more about the changes in the ORF Change Log:

http://www.vamsoft.com/orfee_changelog.asp

ORF Enterprise Edition 4.0 (Beta Version)

Компания Vamsoft выпустила бета версию известного фильтра ORF, который дополняет MS Exchange массой возможностей по фильтрации спама. О нововведениях читать здесь. Забавно, что версия является полностью рабочей и можно ее использовать до 1 августа 2007. По заявлению создателей проблем у текущей версии нет.

Из моего опыта, фильтр ORF очень хорош, работает надежно. Служба поддержки Vamsoft отвечает быстро. На мой взгляд обязателен к установке с MS Exchange.

Sender ID и RBL, как базовые средства защиты от спама.

Я уже неоднократно писал в блоге про то, что RBL существенно снижает уровень спама и вирусов из Интернет, хотя и очень скептически относился, как к RBL, так и к технологии Sender ID.

Работает Sender ID очень просто. Сервер получатель, при приеме письма, запрашивает в DNS отправителя IP адрес сервера для предъявляемого отправителем домена. Если IP совпадают, значит, отправитель честный и все хорошо. Если IP не совпадают, то возможно это подделка и в зависимости от настроек сервера получателя можно помечать письма, как спам или вообще не принимать.

Поэтому перед внедрением Sender ID мы проверили входящие запросы к DNS и обнаружили, что многие почтовые серверы запрашивают DNS на наличие Sender ID записей. Значит, эту технологию уже используют многие серверы в Интернете и будет лучше ее настроить. Настраивается она внесением специальных записей в ваш DNS. Чтобы не запутаться, рекомендую воспользоваться мастером для создания записей DNS.

Мастера для создания Sender ID записей: http://www.microsoft.com/mscorp/safety/content/technologies/senderid/wizard/ http://www.openspf.org/

После внедрения Sender ID заметно сократилось количество сообщений с сабжем: «Не удается доставить: Warning: could not send message for past 4 hours», да и вообще спама и вирусов.

Более подробно о том, как работает технология Sender ID или об этом же, но по-русски.
Wiki: http://ru.wikipedia.org/wiki/Sender_ID
http://sozinov.blogspot.com/2007/01/sender-policy-framework-spf.html

451 Could not complete sender verify callout или война RBL и Callback verification.

Сегодня возникла проблема. Пользователь отправляет письмо и получает в ответ «451 Could not complete sender verify callout». Оказывается, есть такой метод проверки Callback verification. Суть очень проста, проверить существование отправителя на сервере отправителя. Защищает этот способ от поддельных адресов. Недостатков – множество. Скажем если спаммер подставит любой существующий адрес , например e-mail из любого глянцевого журнала, то эта проверка подвоха не заметит. Мало того, что это очень ресурсоемкая ситуация и ее не используют.

Я же подумал, почему тот сервер не может проверить e-mail нашего пользователя. А вот почему – проверка RBL на нашем сервере. Сеть, где находится сервер получателя попала в RBL целиком и теперь они находятся в незавидном положении.

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

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

p.s.: Кстати, в последнее время спам стал очень редким явлением. RBL, SenderID и Kaspersky antispam хорошая связка. Раньше было по 30 - 40 сообщений приходило в мой Inbox ежедневно, теперь одно – два в день, а бывает и совсем нет.

Проблемный AOL или как не нужно защищаться от спама.

Вчера пользователи обратились с жалобой, что почта не идет в домен aol.com. Если кто не знает, то AOL – это один из старейших и крупнейших провайдеров Интернет сервисов в Штатах и каждый уважающий себя американец имеет там аккаунт(Мои наблюдения :-)).

Диагностика с сервера отправки показала следующее:

telnet mailin-01.mx.aol.com 25

Ответ:
554- (RTR:CH) http://postmaster.info.aol.com/errors/554rtrch.html
554 Connecting IP: IP нашего сервера
Connection to host lost.

По ссылке находится вот эта страничка:

Error 554 RTR:CH
554 RTR:CH
http://postmaster.info.aol.com/errors/554rtrch.html

• EXPLANATION:
  
  Your IP address has generated AOL member complaints and your mail system may be compromised due to a virus or other security related issue.
  
  SOLUTION:
  

  Complaints:
  
  When an AOL member clicks "this is spam" for a piece of email sent from one of your IPs, this is considered a "complaint". If you are having difficulty with the number of complaints you are receiving a feedback loop would benefit you. Once you have requested a feedback loop you will be notified when a member clicks "this is spam". See feedback loop for additional information.
  

  
  

  Security:
  
  Please contact your ISP or network administrator for assistance in securing your computer or network. Once you are confident the issue has been resolved please contact us to have the block removed.
  
  Защита, это конечно круто, а мне что делать то? Пользователям что сказать? В моем случае все решается просто, я настрою отправку писем для домена через другого провайдера. Дело 30-40 секунд. А потом займусь «выяснением отношений» с AOL. У них есть сайт для postmasterов и нормальный FAQ с требованиями к почте и что делать. Отправили им запрос о проблеме еще вчера, до сих пор молчат. Понятно, большая компания.
  
  Заполнили форму на регистрацию в их WhiteList. Автоматика отработала хорошо, теперь ждем Confirmation, когда добавят.
  
  Ну что же, как будут развиваться события – посмотрим, я еще напишу. Но пользователи не должны страдать из-за того, что кто-то нажал там кнопку и теперь письма не принимаются.
  
  Кстати, nettools.ru тоже не прошел проверку в АОЛ :-)
  

Проверка доступности E_Mail адреса: postmaster@aol.com

Домен: aol.com

Почтовые сервера домена aol.com

aol.com preference = 15, mail exchanger = mailin-01.mx.aol.com
aol.com preference = 15, mail exchanger = mailin-02.mx.aol.com
aol.com preference = 15, mail exchanger = mailin-03.mx.aol.com
aol.com preference = 15, mail exchanger = mailin-04.mx.aol.com

---------------Почтовый сервер: mailin-01.mx.aol.com(205.188.158.121) [приоритет 15] -
Подключение... OK
554- (RTR:CH) http://postmaster.info.aol.com/errors/554rtrch.html
***Пользователя с таким E_Mail не доступен на сервере***

---------------Почтовый сервер: mailin-02.mx.aol.com(205.188.157.25) [приоритет 15] ---
Подключение... OK
554- (RTR:CH) http://postmaster.info.aol.com/errors/554rtrch.html
***Пользователя с таким E_Mail не доступен на сервере***

---------------Почтовый сервер: mailin-03.mx.aol.com(205.188.159.57) [приоритет 15] --- Подключение... OK
554- (RTR:CH) http://postmaster.info.aol.com/errors/554rtrch.html
***Пользователя с таким E_Mail не доступен на сервере***

---------------Почтовый сервер: mailin-04.mx.aol.com(205.188.159.217) [приоритет 15] -
Подключение... OK
554- (RTR:CH) http://postmaster.info.aol.com/errors/554rtrch.html
***Пользователя с таким E_Mail не доступен на сервере***

А от Вас AOL почту принимает? :-)

Вот еще мнения :-)
http://www.boogybonbon.com/2006/06/23/emails-blocked-by-aol-error-554-rlyb1/