forum.lissyara.su

Собственно, сабж, как концептуально сделать в принципе, знает кто?
В кач-ве MTA желательно чтобы был экзим.
Примерная схема: есть lan, некий dmz, маршрутизатор с двумя wan-ами.
В dmz торчит сабж, в DNS имеются все необходимые записи, почта принимается с любого канала, соответственно, падение одного из них не страшно.
Страшно для исходящей почты - допустим политика маршрутизации роутит всё что с MTA через wan-1, там всё совпадает - HELO/EHLO/PTR, но вот канал падает, клиенты из lan пошли через wan-2, переключить на wan-2 и SMTP трафик не вопрос, однако правильно настроенными серверами он будет отплюнут.
Допустим, есть даже и второй MTA, с более низким (для локалки) приоритетом, роутящийся через wan-2, но в этом случае письма просто будут откладываться в очередь на первом MTA и всё равно желаемого не наступит.
Как дать понять exim-у например через какой wan он ходит (не представляю как вообще) или как настроить роутеры что если доставка не удалась скажем по таймауту, то швырнуть на второй MTA?

а в чем проблема? Вписать в DNS оба адреса (из обоих WAN-ов) и вроде все должно работать, нет?
прописать в SPF оба адреса, прописать в обратный резолвинг с обоих адресов одно и тоже имя... его и выдавать в HELO/EHLO.

Проблема, очевидно, в том, что когда и если MTA поломится наружу через альтернативный WAN, то его HELO/EHLO перестанет соответствовать PTR, что вроде-как есть нарушение rfc2821 и многие это на своих серверах чтут.
Хотя, пролистав по диагонали указанный RFC, я там пока не обнаружил жёсткого требования соответствия именно "соответствия" того что отдаётся в EHLO PTR-у, зато точно знаю что у многих при этом несоответствии будет режект.
Да, заранее сообщаю что настроить одинаковый PTR на обоих концах не могу, потому как строго говоря WAN-ы принадлежат разным организациям, просто такая взаимопомощь предусмотрена.

Ну и, раз уж пошла речь о конкретной реализации, в данном случае пограничных MTA - две штуки в едином DMZ пространстве, каждый из них в норме обслуживает одну из организаций, но в резервном смысле обслуживает и вторую тоже. Соответственно, выход каждого MTA привязан жёстко к "своему" WAN в данный момент через политику маршрутизации. Поэтому когда "его" WAN падает. сообщения копятся в его очереди. Если бы была какая-то возможность внутри MTA настроить так чтобы он "увидел" падение своего канала и после этого начал релеить все письма в сторону второго MTA, а тот уже дальше через свой канал - это тоже был бы вариант.

брр... что-то задача меняется на ходу. То один МТА с двума каналами, то два МТА и каждый с одним каналом...

Ну таки да, если два МТА с одним каналом у каждого, то просто настраиваете каждый из них с указанием второго как backup relay. И никаких проблем не будет.
Только надо в SPF вписать оба сервера на всякий случай.

P.S. Как в exim-e настраивается relay я не знаю, но наверняка man поможет.

Как настраивается в экзиме отсылка на смартхост я знаю, и в постфиксе не тяжелее, но нигде пока не нашёл как сделать чтобы либо ретрай шёл через релей либо чтобы экзим ловил таймаут на роутинге (это не особо верно потому что таймаут в данном случае будет на транспорте SMTP, сама инфраструктура ДНС постоена так что резольвинг работать будет пока есть хоть один канал) и если его поймал, то пихал бы в следующий роутер.
Пока не нашёл как бы это сконфигурить.
Ваша словесная конструкция "backup relay" скорее относится к тому случаю когда релеи бы у меня стояли снаружи, тогда бы да - всё работало бы здорово и как положено - есть связь с релеем - шлём на него, нету - на следующий. В моём же случае с релеем связь есть у почтовика, и он радостно ему письма скормит, а вот у самого релея выхода в инет временно нету но он об этом как-бы "не знает", он всё сложит в очередь и не подумает даже другому релею передавать, потому что он сам смартхост и сам решает кому слать с помощью роутера dnslookup.

Честно скажу, я сам такое не настраивал, но по описанию таки в постфиксе параметр fallback_relay делает как раз то, что нужно -
List of IP addresses, hosts, or domains to receive messages when the normal destination is not found or is not reachable.

То есть постфикс сначала пытается доставить письмо напрямую получателю, а если не может, то отправляет на fallback_relay.

Хм, забавно, по вашей опции загуглил и нашёл аналогичную в экзиме - fallback_hosts там она называется, относится именно к SMTP транспорту, надо запробовать, странно что сам не нашёл.