Изпечатай

[Acho]

Еми това ти написах. Настройвам primary-то на всеки 15 минути да изисква от backup-а ако има нещо там. От много години си работи желязно.

Не мога да определя обаче едно нещо - питаш за да си обясниш нещо за себе си, или е просто някакво заяждане деа ?

[nslave]

Това с бекъп mail сървъра звучи добре по принцип. Но няколко неща ме тревожат. Изпращача ще сметне, че писмото е пристигнало, а то всъщност ще е в backup server-а. Така или иначе server-а на изпращача трябва да се опита да го достави няколко пъти. Второто тревожно са спамерите, най-вероятно основният сървър се доверява безрезервно на backup-а си и ако спамерите пращат на backup-а, то писмата ще си се излеят в основния. Всичко си е въпрос на конфигурация де, но е важно сякаш да се имат предвид тези възможности

[Acho]

Абсолютно е така. Но всеки си решава, кое му е по-важно. Загубата на някои мейлове, или после филтрирането на спам-а. Пълно щастие няма.

[Bogo]

OK тествам сега и бекъпа отказва да го вземе:
Unrouteable address

някакви идей ?

[Bogo]

Ок стигнах до там че бекъп сървъра приема пощата, и се опитва да я достави на главния сървър но:
Connection refused

защото аз съм го изключил

сега каво правя ?

[laskov]

.... си ги изисква от backup-а по ATRN или по ETRN. ...

ATRN и ETRN обикновено се забраняват в интерес на сигурността. Стандартно резервният сървър
- представлява MTA queue runner, с какъвто разполага всеки пощенски сървър и всеки пощенски сървър може да играе роля на резервен MX за който и да е домейн, стига да се договориш с администратора му;
- съхранява писмата там, където се съхраняват писмата за изпращане. В sendmail това е /var/spool/mqueue и с командата mailq можеш да видиш какво все още стои в опашката за изпращане, от кога стои и евентуално какъв му е проблема;
- при изтичане на зададените timeout-и за някое от недоставените писма се изпраща уведомително писмо на подателя. Напр. по подразбиране, sendmail изпраща първото уведомление за недоставяне на писмо след като изминат 4 часа от изпращането му от подателя, а след като изминат 5 дни изтрива писмото от опашката и изпраща уведомление за това на подателя. Дотогава на всеки 15 или 20 мин (или колкото е зададено) се правят опити писмото да бъде изпратено;
- в DNS зоната за домейна резервните MX са описани с по-голямо число за приоритет от това на основните MX. Може да се види с командата

Код:

dig -t MX domain.com

По-малките числа съответстват на по-висок приоритет.

Добре е ден преди да правите промени в DNS зоната, временно да намалите стойностите на TTL времената за съответните записи или за цялата зона, за да не чакате после два (примерно) дни да се обнови информацията по DNS-ите.

[Bogo]

ОК бекъп MX сървъра се оказа доста лесно с exim4
просто бекъпа трябва да може да relay всички домейни които по-принцип се събират от главния сървър
през 30 минути се опитва да се свърже с него, за да ги достави

на бекъпа, най лесно с тази команда
 dpkg-reconfigure exim4-config

после в полето на екрана въвеждате домейните за relay