Linux за българи: Форуми

Имам два домейна .еу и .ком , а приятеля има един домейн .бг и трите в хост.бг. Трите домейна са пренасочени към 3 статични външни ИП-та към моя сървър с еднакви настройки. На трите ИП-та мейл сървъра е постфикс, зентиала дето съм писал в другите теми и настроен по еднакъв начин, защото единия домейн и ИП ги ползвам само за експерименти и това което ми хареса влиза в експлоатация за нашите си нужди. Еу и ком домейните полуват мейли, а бг домейна не получава! Изпраща, но не получава!

I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.

For further assistance, please send mail to postmaster.

If you do so, please include this problem report. You can
delete your own text from the attached returned message.

The mail system

<mail@---------.bg> (expanded from <------------@-----------.bg>): User unknown in
virtual alias table

Днес говорих техническия персонал на хост.бг и казаха, че нямам мх запис(аз не, че не знам), ама снощи имаше някакъв който изтрих и като го имаше пак не приемаше, а другите два домейна имат само А запис и няма проблем! Никога не са и имали МХ запис. На обяд вкараха МХ запис на бг домейна и още няма резултат, а на другите още като зададох мейл пренасочването и след не повече от половин час започнах да получавам!

Не би трябвало да има връзка с регистратора. Коректно е да си имаш описан MX запис, не че иначе няма да работи, просто ще гледа А записа и ще праща писмата на IP-то, което е записано за A DNS запис на домейна.

От грешката, която си пуснал ми се струва, че имаш проблем с конфигурацията на сървъра за този домейн. Не може да намери съответната кутия в списъка виртуални кутии. Съответно като не може да я намери, не може да я достави :)

Трите машини са виртуаки като малко преди да се създаде мейл сървъра, тази която е на ком и другата на бг са клонирани от тази която е на еу. Системата не се настройва с ръчно писане по конфигурационни файлове а е цяла специализирана система, нещо като линукс аналог мс бизнес солюшън. Казва се Zentyal(v3.2). Скоро писах в другата секция бърза и лесна инструкция за инсталиране, а преди това доста съм я ръчкал. Не приема грешни настройки. Проверява си и за дублирани записи където трябва. Абе, дуракоустойчива  :D !

User unknown in
virtual alias table

Както ти казаха няма такава кутия/alias. Провери ли дали имаш такава кутия/потребител? Опита ли се да направиш нова и да тестваш с нея?

Според мен просто си уцелил момента, когато DNS са се обновили. Това понякога отнема дори повече от 48 часа.

а как правиш порт форуардинг на порт 25 към три различни машини?!

Сървъра е с ЕSXi, трите различни виртуалки се свързват директно за едната лан карта и всяка си взема зададеното ИП. Тази на ком ми е и рутер и прехвърля на другата лан карта към домашната ми мрежа. Няма прехвърляне на портове! И трите са директно закачени за външното ИП.

Хубаво е да има и бакъп мейл сървър. Ако каталяса нещо по основния, втория да поеме временно пощата.

Ачо, от такива неща има смисъл за натоварени мейл сървъри с много кутии и постоянни кореспонденции, а ние сме далече от тази таргет група, но да не се измества въпроса.

Пощенските кутии се създават автоматично със създаването на юзера в системата с име на юзера и домейн, а не ръчно. Абе, по един и същи начин се правят нещата в трите виртуалки, а само тази с бг домейна не получава!
Възможно ли е да не е проблема у нас или в хост.бг, защото точно за това започнах да си мисля!!?

Ами все пак си дал три домейни, а доколкото разбирам ще работят на сходни линии (и захранване и интернет). Демек, ако каталяса нещо, и трите мейлери умират. И цялата поща спира. Нищо не пречи да си имат един и същи бакъп мейлер. Някъде на различно захранване и нет. Ако пък няма да са толкова важни мейлерите (с по 5 пикливи писма на ден), разбира се че няма да е целесъобразно това.

Здравей,
аз бих започнал с проверка на конфигурацията на ДНС'ите ето един примерен инструмент http://www.webdnstools.com/dnstools/domain_check ($2) . От опитът който имам с местене на майл сървъри и страници от едно ип на друго съм придобил следният похват. Ако кофигурацията е при теб намаляваш следните стойности:
3600  Refresh
600  Retry
1800  Expire
1000 Min TTL
за да може по бързо останалите по веригата ДНС'и да възприемат твоите промени така ще разбираш нещо дали работи или не работи доста по бързо. След като си подкарал всичко да работи както трябва ги връщаш в нормални стойности:
3600  Refresh
600  Retry
1209600  Expire
3600 Min TTL
Относно МХ записите са хубаво нещо да ги има но за тях ще трябва да направиш и СПФ записи за да гарантираш вярноста им след което ще ти пропоръчам да помолиш доставчика ти да направи и ПТР запис за даденият майл сървър.

Ачо, между другото, идеята ти е много добра и трябва да я обмисля, защото в периспектива на едната виртуалка може да има още няколко домейна с мейл домейни към тях.


Междувременно, бг домейна започна да приема вече мейли след вчерашното настройване на мх запис от техническия персонал на хост.бг и от тогава не съм пипал нищо нито по виртуалката, нито в панела на хост.бг.

Нищо не пречи да си имат един и същи бакъп мейлер.

Къде физически на бекъп сървъра, изчакват писмата, за да се върне онлайн главния сървър ?

Вероятно в някоя негова директория за такъв временен стор. Нито ги проверява за SPAM или за вируси, просто ги сторва до поискване от primary сървъра. Не знам как точно е имплементирано това при различните мейл сървъри. Но при мен на Communigate си работи желязно. Описани са MX записите в DNS-а, и това е.

А после като тръгне основния мейл сървър, си ги изисква от backup-а по ATRN или по ETRN. И вече си ги рутира по кутиите. Аз съм настроил моите мейлери на всеки 15 минути да проверяват има ли нещо на бекъп сървъра.

Разбира се за да сработи системата с primary и backup мейл сървър, трябва изпращащия сървър да провери в DNS-а всички MX записи, и ако primary е отпаднал, да започне да търси backup-а и да ги сендва там.

А после като тръгне основния мейл сървър, си ги изисква от backup-а по ATRN или по ETRN. И вече си ги рутира по кутиите.

Как ще изискваш нещо ако си спал и незнаеш какво си пропуснал за да си го искаш ?
Според мен бекъпа трябва да проверява през определен период от време да достави пощата.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

(http://www.linux-bg.org/forum/index.php?action=dlattach;topic=47107.0;attach=3054)