ситуация была такая - mx в dmz, который принимает почту, а потом скидывает её на внутренний exchange. между exchange и mx`ом разрешён только DST 25 tcp. и откуда mx`у брать список внутренних реципиентов?
если бы над вопросом задумались - может что-нибудь и придумали бы. Но в данном случае никто не стал париться и просто придумали включить приём всех писем. малацы, фигли.
потому что запросы о подтверждении адресата, и сессия смтп для передачи почты это разные сеансы, и так получится как минимум в два раза больше сеансов. если система достаточно загружена, то разговор идет о сотнях лишних запросов в минуту, причем нагрузка как на эксченж, так и на внешний МТА зачем оно надо, когда можно или кроном апдейтить список, или вообще, при добавлении юзера прогонять на МТА скрипт который берет список из активдира
почему сессии разные? принимаемое письмо прямо сразу пытаемся скормить в exchange. если он ругнулся на адрес получателя - ругаемся в строну отправителя, не ругнулся - выполняем остальные проверки. если они успешно прошли, отправляем остаток письма в exchange, не выполнились - говорим exchange'у RSET, в клиента ругаемся соответствующей ошибкой.
а остальное - вопрос эффективности. иногда действительно проще скопить пачку писем на релее, а потом заслать их все в exchange за одну сессию.
Для эксченджа этот файлег генерируется тривиальнейшим образом. "Всё, что имеет смтп-адрес" есть в тамошнем лдапе. Для всяких адванснутых юниксовых мультисервисных конфигов - тоже достаточно просто, потому что всё понятногде лежит.
ну там, сотрудники добавляются и удаляются пачками. для большой компании ситуация вполне обычная. пришел - зарегистрировали - посадили на рабочее место - пошел читать первую почту..
точно так и есть... компания небольшая правда, но: приходят обычно с утра (чаще всего - в понедельник) список приходящей пачки известен заранее, и прислан админам тоже заранее (на то есть отдел по борьбе с персоналом) но даже если нет - пока человеков водят оформлять всякие бумажки и пропуска, время у меня будет... да и первая почта в 99% случаев будет внутренней рассылкой
Нененене, Дэвид блейн. Потом получится "адреса есть в эксче но нету на фронтенде", "адреса есть на фронтенде но нету в эксче" и прочие веселья. Крон там не лишний, но если не хочется таскать всё слишком часто - ну, храни предыдущую версию транспортного файла, если нет изменений - не клади на мх.
ручками. по регламенту: "пользователь создан, ящик создался, в бэковые списки рассылки добавлен. на фронт добавлен. письмом снаружи проверен. на воркстейшне аутлук настроен. таск закрыт"
ну и для меня плюс в том, чтоб иметь адрес внутри, недоступный снаружи
Ну, если есть задача задрочить почтового админа - тогда конечно ВСЁ ручками. А если нет - лучше бы все неинтеллектуальные таски, просто скриптуемые - скриптовать.
можно. вместо того, чтобы сразу ответить спаммерскому хосту "пшел вон, нет у меня такого адреса", оно принимает письмо, а потом генерирует баунс. но не спаммеру, которого фиг вычислишь, а ни в чём не виноватому владельцу адреса, который спаммер указал в envelope-from.
после массовой рассылки спама и последующего получения сотен баунсов желание убивать криворуких уродов появляется даже у самых мирных людей.
Достаточно баунсы в /dev/null отправить. Бо проверять на лету не всегда получается, было такое в прошлой конторе: мыло оутсорсено на гмыл, а релей на продакшене. Отдавать mx на гмыл шеф не хотел ни в какую...
"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)."
но что мешает (если спам отправляется через open relay) отправляющему серверу, если отлуп им получен сразу после rcpt to (т.е. в случае нормально настроенного relay-а), самому сгенерить баунс и отправить бедному юзеру? кроме того, предлагаю пользователю в своих проклятиях не забыть упомянуть и своего постмастера, не слишком удачно настроевшего спам-фильтр. а вот зачем люди напрягают свои бэк-енд серверы такой ерундой, вместо того, чтобы отсекать их на первых же relay-ах я действительно не понимаю интересно, а как правильно сочитать грейлистинг и проверку получателя? сначала отгрейлистить, а потом послать с user unknown? или сразу слать лесом?
речь не об отправке через открытые релеи, которых уже практически не осталось, а об отправке непосредственно с затрояненных хостов и через дырявые прокси. в этом случае отправляющий хост баунс сгенерировать не сможет, потому что не умеет.
при чём тут свой постмастер и его спам-фильтр, я вообще не понял. мой постмастер не виноват, что от моего имени рассылают спам, и что с криво настроенных серверов мне присылают баунсы. он их принимает, и правильно делает.
если вы хотите увеличить нагрузку на сервера, то можно сначала грейлистить, а потом уже посылать. но я не вижу причин это делать. грейлистинг предназначен для отсечения однократно отправляемого спама, он отсечётся и на 4xx, и на 5xx, а ваш сервер будет тратить свои ресурсы на запоминание попыток отправки писем на несуществующие адреса. а для валидных писем, по ошибке отправленных на несуществующий адрес, это только вызовет ненужную задержку перед получением квитанции.
так баунсы могут содержать во вложении исходное сообщение. вот его можно бы и проанализировать спам-фильтром. и почему бы, кстати, при использовании затрояненых хостов не использовать, в том числе, и такую технику: формировать баунс и отправлять с вложенным спамом. хотя, конечно, использовать для этого какой-нибудь relay.ciscom.ru правильнее - у него и spf сойдется ;)
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
no subject
no subject
no subject
no subject
если бы над вопросом задумались - может что-нибудь и придумали бы. Но в данном случае никто не стал париться и просто придумали включить приём всех писем. малацы, фигли.
no subject
Сделать telnet exch 25, MAIL FROM: postmaster@main.doma.in, RCPT TO: recipient@doma.in, read reply просто нереально
no subject
no subject
no subject
раз в полчаса обновлять список реципиентов кроном
no subject
no subject
зачем оно надо, когда можно или кроном апдейтить список, или вообще, при добавлении юзера прогонять на МТА скрипт который берет список из активдира
no subject
а остальное - вопрос эффективности. иногда действительно проще скопить пачку писем на релее, а потом заслать их все в exchange за одну сессию.
no subject
no subject
no subject
no subject
no subject
no subject
no subject
И волосы будут лёгкими и шелковистымиno subject
no subject
Для всяких адванснутых юниксовых мультисервисных конфигов - тоже достаточно просто, потому что всё понятногде лежит.
no subject
во всяком случае я плохо представляю размер бедствия при котором у меня бы в exch адреса появлялись или исчезали со скоростью "раз в пять минут"
no subject
no subject
приходят обычно с утра (чаще всего - в понедельник)
список приходящей пачки известен заранее, и прислан админам тоже заранее (на то есть отдел по борьбе с персоналом)
но даже если нет - пока человеков водят оформлять всякие бумажки и пропуска, время у меня будет...
да и первая почта в 99% случаев будет внутренней рассылкой
no subject
Нененене, Дэвид блейн. Потом получится "адреса есть в эксче но нету на фронтенде", "адреса есть на фронтенде но нету в эксче" и прочие веселья.
Крон там не лишний, но если не хочется таскать всё слишком часто - ну, храни предыдущую версию транспортного файла, если нет изменений - не клади на мх.
no subject
ну и для меня плюс в том, чтоб иметь адрес внутри, недоступный снаружи
ну и само-собой хранение предыдущего файлика...
no subject
А если нет - лучше бы все неинтеллектуальные таски, просто скриптуемые - скриптовать.
no subject
хотя, конечно, путь верный...
no subject
А имеющий мозг админ - очень быстро понимает прелести скриптования.
no subject
а что ужасного?
Re: а что ужасного?
вместо того, чтобы сразу ответить спаммерскому хосту "пшел вон, нет у меня такого адреса", оно принимает письмо, а потом генерирует баунс. но не спаммеру, которого фиг вычислишь, а ни в чём не виноватому владельцу адреса, который спаммер указал в envelope-from.
после массовой рассылки спама и последующего получения сотен баунсов желание убивать криворуких уродов появляется даже у самых мирных людей.
Re: а что ужасного?
Re: а что ужасного?
"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: а что ужасного?
согласен в принципе
а вот зачем люди напрягают свои бэк-енд серверы такой ерундой, вместо того, чтобы отсекать их на первых же relay-ах я действительно не понимаю
интересно, а как правильно сочитать грейлистинг и проверку получателя? сначала отгрейлистить, а потом послать с user unknown? или сразу слать лесом?
Re: согласен в принципе
при чём тут свой постмастер и его спам-фильтр, я вообще не понял. мой постмастер не виноват, что от моего имени рассылают спам, и что с криво настроенных серверов мне присылают баунсы. он их принимает, и правильно делает.
если вы хотите увеличить нагрузку на сервера, то можно сначала грейлистить, а потом уже посылать. но я не вижу причин это делать. грейлистинг предназначен для отсечения однократно отправляемого спама, он отсечётся и на 4xx, и на 5xx, а ваш сервер будет тратить свои ресурсы на запоминание попыток отправки писем на несуществующие адреса. а для валидных писем, по ошибке отправленных на несуществующий адрес, это только вызовет ненужную задержку перед получением квитанции.
Re: согласен в принципе
Re: согласен в принципе
тогда пардон