dil: (Default)
dil ([personal profile] dil) wrote2008-11-24 01:59 pm

А постмастеров, у которых первичный релей сначала принимает письма на несуществующие адреса

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

Наглядный пример: relay.ciscom.ru. У них этот релей вообще единственный.

[identity profile] 3apa3a-b-ta3e.livejournal.com 2008-11-24 02:07 pm (UTC)(link)
я как-то по глупости и молодости так сделал. больше не буду.

[identity profile] dil.livejournal.com 2008-11-24 02:09 pm (UTC)(link)
ну по молодости и глупости у всех ляпы бывают. но чтобы это в production системе было..

[identity profile] 3apa3a-b-ta3e.livejournal.com 2008-11-24 02:26 pm (UTC)(link)
Было, было. Ибо так было в проекте написано.

[identity profile] dil.livejournal.com 2008-11-24 02:26 pm (UTC)(link)
тогда убивать авторов проекта

[identity profile] 3apa3a-b-ta3e.livejournal.com 2008-11-24 02:40 pm (UTC)(link)
ситуация была такая - mx в dmz, который принимает почту, а потом скидывает её на внутренний exchange. между exchange и mx`ом разрешён только DST 25 tcp. и откуда mx`у брать список внутренних реципиентов?

если бы над вопросом задумались - может что-нибудь и придумали бы. Но в данном случае никто не стал париться и просто придумали включить приём всех писем. малацы, фигли.

[identity profile] gvj.livejournal.com 2008-11-24 02:44 pm (UTC)(link)
Ну да, ну да.
Сделать telnet exch 25, MAIL FROM: postmaster@main.doma.in, RCPT TO: recipient@doma.in, read reply просто нереально

[identity profile] 3apa3a-b-ta3e.livejournal.com 2008-11-24 02:52 pm (UTC)(link)
на самом деле проще (и я думаю - правильнее) разрешить mx`у делать ldap-запросы к GC и уже оттуда плясать. у меня сейчас так и сделано.

[identity profile] dil.livejournal.com 2008-11-24 02:45 pm (UTC)(link)
синхронный режим доставки у релея - на ходу спрашивать у exchange, есть ли у него такой адресат

[identity profile] tullamoredew.livejournal.com 2008-11-24 02:57 pm (UTC)(link)
неэффективно
раз в полчаса обновлять список реципиентов кроном

[identity profile] dil.livejournal.com 2008-11-24 02:58 pm (UTC)(link)
чего это неэффективно? всё равно большинство писем туда отправлять, почему бы не прямо сразу?

[identity profile] tullamoredew.livejournal.com 2008-11-24 03:34 pm (UTC)(link)
потому что запросы о подтверждении адресата, и сессия смтп для передачи почты это разные сеансы, и так получится как минимум в два раза больше сеансов. если система достаточно загружена, то разговор идет о сотнях лишних запросов в минуту, причем нагрузка как на эксченж, так и на внешний МТА
зачем оно надо, когда можно или кроном апдейтить список, или вообще, при добавлении юзера прогонять на МТА скрипт который берет список из активдира

[identity profile] dil.livejournal.com 2008-11-24 04:53 pm (UTC)(link)
почему сессии разные? принимаемое письмо прямо сразу пытаемся скормить в exchange. если он ругнулся на адрес получателя - ругаемся в строну отправителя, не ругнулся - выполняем остальные проверки. если они успешно прошли, отправляем остаток письма в exchange, не выполнились - говорим exchange'у RSET, в клиента ругаемся соответствующей ошибкой.

а остальное - вопрос эффективности. иногда действительно проще скопить пачку писем на релее, а потом заслать их все в exchange за одну сессию.

[identity profile] tullamoredew.livejournal.com 2008-11-24 07:24 pm (UTC)(link)
а разве попытка скормить ксченджу нерелевантные письма не beats the whole purpose of a front end MTA?

[identity profile] dil.livejournal.com 2008-11-24 11:06 pm (UTC)(link)
зависит от этой самой purpose. если frontend relay только затем, чтобы не выставлять exchange в открытый интернет, то всё нормально.

[identity profile] tullamoredew.livejournal.com 2008-11-24 02:57 pm (UTC)(link)
http://thelowedown.wordpress.com/2008/02/16/postfix-gateway-to-exchange/

[identity profile] dil.livejournal.com 2008-11-24 02:58 pm (UTC)(link)
да не, ну понятно же, что если захотеть, то проблема решаема :)

[identity profile] tullamoredew.livejournal.com 2008-11-24 03:31 pm (UTC)(link)
как впрочем и любая проблема :)

[identity profile] 3apa3a-b-ta3e.livejournal.com 2008-11-24 08:25 pm (UTC)(link)
дык уже. сейчас. у меня лично.

[identity profile] dma.livejournal.com 2008-11-24 04:27 pm (UTC)(link)
класть на mx из внутренней сети файлик с реципиентами. Хоть раз в 5 минут, хоть раз в час - разницы нет. И волосы будут лёгкими и шелковистыми

[identity profile] dil.livejournal.com 2008-11-24 04:54 pm (UTC)(link)
в общем, тоже метод, но файлик иногда нетривиально сгенерировать. там же не только личные адреса должны быть, а еще и групповые, и алиасы..

[identity profile] dma.livejournal.com 2008-11-24 07:05 pm (UTC)(link)
Для эксченджа этот файлег генерируется тривиальнейшим образом. "Всё, что имеет смтп-адрес" есть в тамошнем лдапе.
Для всяких адванснутых юниксовых мультисервисных конфигов - тоже достаточно просто, потому что всё понятногде лежит.

[identity profile] zeleny.livejournal.com 2008-11-24 10:57 pm (UTC)(link)
имхо - крон тут лишний... access менять по факту изменения в AD надо (ручками, ага)...

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

[identity profile] dil.livejournal.com 2008-11-24 11:08 pm (UTC)(link)
ну там, сотрудники добавляются и удаляются пачками. для большой компании ситуация вполне обычная. пришел - зарегистрировали - посадили на рабочее место - пошел читать первую почту..

[identity profile] zeleny.livejournal.com 2008-11-25 06:13 am (UTC)(link)
точно так и есть... компания небольшая правда, но:
приходят обычно с утра (чаще всего - в понедельник)
список приходящей пачки известен заранее, и прислан админам тоже заранее (на то есть отдел по борьбе с персоналом)
но даже если нет - пока человеков водят оформлять всякие бумажки и пропуска, время у меня будет...
да и первая почта в 99% случаев будет внутренней рассылкой

[identity profile] dma.livejournal.com 2008-11-25 07:07 am (UTC)(link)
РУЧКАМИ????

Нененене, Дэвид блейн. Потом получится "адреса есть в эксче но нету на фронтенде", "адреса есть на фронтенде но нету в эксче" и прочие веселья.
Крон там не лишний, но если не хочется таскать всё слишком часто - ну, храни предыдущую версию транспортного файла, если нет изменений - не клади на мх.

[identity profile] zeleny.livejournal.com 2008-11-25 08:21 pm (UTC)(link)
ручками. по регламенту: "пользователь создан, ящик создался, в бэковые списки рассылки добавлен. на фронт добавлен. письмом снаружи проверен. на воркстейшне аутлук настроен. таск закрыт"

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

ну и само-собой хранение предыдущего файлика...

[identity profile] dma.livejournal.com 2008-11-25 11:27 pm (UTC)(link)
Ну, если есть задача задрочить почтового админа - тогда конечно ВСЁ ручками.
А если нет - лучше бы все неинтеллектуальные таски, просто скриптуемые - скриптовать.

[identity profile] zeleny.livejournal.com 2008-11-26 06:45 pm (UTC)(link)
гм.. переименовать постмастера в перлмастера? оверхед, помоему...
хотя, конечно, путь верный...

[identity profile] dma.livejournal.com 2008-11-26 10:52 pm (UTC)(link)
Ну... постмастер - он обязан иметь мозг.
А имеющий мозг админ - очень быстро понимает прелести скриптования.

[identity profile] dma.livejournal.com 2008-11-24 04:28 pm (UTC)(link)
Это не постмастеры, это постподмастерья.

а что ужасного?

[identity profile] mb4.livejournal.com 2008-11-24 08:16 pm (UTC)(link)
можно узнать, что такого ужасного в этом? (не очень умнО (хотя тот же Exchange 2000 просто не умел этого), на мой взгляд, но убивать то за что?)

Re: а что ужасного?

[identity profile] dil.livejournal.com 2008-11-24 09:54 pm (UTC)(link)
можно.
вместо того, чтобы сразу ответить спаммерскому хосту "пшел вон, нет у меня такого адреса", оно принимает письмо, а потом генерирует баунс. но не спаммеру, которого фиг вычислишь, а ни в чём не виноватому владельцу адреса, который спаммер указал в envelope-from.

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

Re: а что ужасного?

[identity profile] alz421.livejournal.com 2008-11-24 11:12 pm (UTC)(link)
Достаточно баунсы в /dev/null отправить. Бо проверять на лету не всегда получается, было такое в прошлой конторе: мыло оутсорсено на гмыл, а релей на продакшене. Отдавать mx на гмыл шеф не хотел ни в какую...

Re: а что ужасного?

[identity profile] dil.livejournal.com 2008-11-25 10:08 am (UTC)(link)
низя. это прямое нарушение RFC 2821:

"If an SMTP server has accepted the task of relaying the mail and
later finds that the destination is incorrect or that the mail cannot
be delivered for some other reason, then it MUST construct an
"undeliverable mail" notification message and send it to the
originator of the undeliverable mail (as indicated by the reverse-
path)."

Re: а что ужасного?

[identity profile] alz421.livejournal.com 2008-11-26 12:12 pm (UTC)(link)
Зато ты ругаться не будешь :-D

согласен в принципе

[identity profile] mb4.livejournal.com 2008-11-25 05:27 am (UTC)(link)
но что мешает (если спам отправляется через open relay) отправляющему серверу, если отлуп им получен сразу после rcpt to (т.е. в случае нормально настроенного relay-а), самому сгенерить баунс и отправить бедному юзеру? кроме того, предлагаю пользователю в своих проклятиях не забыть упомянуть и своего постмастера, не слишком удачно настроевшего спам-фильтр.
а вот зачем люди напрягают свои бэк-енд серверы такой ерундой, вместо того, чтобы отсекать их на первых же relay-ах я действительно не понимаю
интересно, а как правильно сочитать грейлистинг и проверку получателя? сначала отгрейлистить, а потом послать с user unknown? или сразу слать лесом?

Re: согласен в принципе

[identity profile] dil.livejournal.com 2008-11-25 10:15 am (UTC)(link)
речь не об отправке через открытые релеи, которых уже практически не осталось, а об отправке непосредственно с затрояненных хостов и через дырявые прокси. в этом случае отправляющий хост баунс сгенерировать не сможет, потому что не умеет.

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

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

Re: согласен в принципе

[identity profile] mb4.livejournal.com 2008-11-25 11:44 am (UTC)(link)
так баунсы могут содержать во вложении исходное сообщение. вот его можно бы и проанализировать спам-фильтром. и почему бы, кстати, при использовании затрояненых хостов не использовать, в том числе, и такую технику: формировать баунс и отправлять с вложенным спамом. хотя, конечно, использовать для этого какой-нибудь relay.ciscom.ru правильнее - у него и spf сойдется ;)

Re: согласен в принципе

[identity profile] dil.livejournal.com 2008-11-25 01:35 pm (UTC)(link)
это отдельный вопрос. мой поинт в том, что если можно избежать бессмысленных баунсов, их нужно избегать.

тогда пардон

[identity profile] mb4.livejournal.com 2008-11-25 01:52 pm (UTC)(link)
с этим согласен полностью. не согласен был только с п."н" ч.2 ст.105 УК РФ ;)