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

Имам проблем с конфигурирането на обратното запитване за хоста. Някакво изискване се оказа от mail.bg, което не бих коментирал дали е разумно или не. Предполагам че сървъри като yahoo са по глупави и нямат такива изисквания, но както и да е.
Проблема е че сървъра на mail.bg не иска да получава поща от моята машина. Грешката е:

550 Client host rejected: cannot find your hostname.

Това ясно използват RFC1912, както се изразиха. Проблема ми е че ползвам djbdns и там нямам представа как трябва да се направи този запис. Описана е цялата процедура как се прави с BIND, а това не ми решава проблема.

Reverse DNS може да насочи към теб само LIR-а, който е получил IP-тата от RIPE. За целта трябва да имаш цяла клас С мрежа. Кой DNS сървър в момента отговаря за твойто (твойте ) IP-та можеш да провериш с dig +trace -x <ip>

Мисля, че не ти е проблем в DNS.

С какво изпращаш пощата ? Програмата, която изпраща пощата трябва да използва име на хост (FQDN), което е валидно. Имена като localhost, блабла.localdomain не стават.

zarhi е прав - маил.бг искат ревърс ДНС така че питай доставчика си.

btw обратния резолв не е задължително да съвпада с правия, в смисъл: ако името на твоя хост е mail.firma.bg, в обратния резолв може да е adsl-212-212-212-212.isp.net и пак ще работи.
Добавено : След като прочетох малко по-надолу и проверих, се оказа, че при запитване за adsl-212-212-212-212.isp.net, получавам същото IP.

Доставчика ми е ако не се лъжа botevgrad.net ATLANTIS значи при него трябва да се направи този обратен запис до колкото съм разбрал. Предполагам че няма да има проблем. Иначе използвам qmail sever с всичките там неща които са кум него. АнтиСПАМ, АнтиВирус и .......... Много добра документация по която може да се инсталира системата е:

http://www.pipeline.com.au/staff/mbowe/isp/webmail-server.htm

Ако някой разбира се иска да се занимава. Предупреждавам че има известни трудности с Fedora Core 3 поне на такъв бокс го качвах. Не знам защо реших така. Предполагам че в BSD или Slackware няма да ги има тези проблеми. Предстоят тестове с други линукси. Имам в момента и продължавам да имам проблем с подкарването на webmail_a но ако съвсем не стане ще пусна пост в форума.

Благодаря за съвета.

За МХ запис съм сигурен че има понеже съм задал като @dominname.xxx и @mail.domainname.xxx

Възможно ли е да имам също проблеми, че тази машина поддържа повече от един домеин, а обратния ресолв да дава името на основния. Всъщност qmaila е конфигуриран да работи като smtp after pop3 тоест може човек да изпрати поща през тази машина след като се ауторизира през поп3 или трябва да е реален потребител на пощенския сървър. Но за стандартна опция ще се радвам да разбера каква е идеята. Иначе наистина не пречи доставчика да ми направи запис в неговия DNS

Препоръчвам да прочетеш и това: http://spf.pobox.com/

Ще се наложи да подновя тази тема, защото май нищо не може да стане и ако трябва да сме честни тези които са правили mail.bg колкото и да са пекани нищо не става от тях.

Значи доставчика, който ми дава интернет в момента ми е разписал IPто като името на хоста на машината и обратния резолв отговаря като хората. Направил съм и всички видове записи като SPF и т.н. имащи отношение към работата на един меил сървър. Даже в страницата на DNSreport.com имам само 3 забележки и то са маркирани като дребни проблеми и все пак отговора от mail.bg е следния:


193.201.172.114 does not like recipient.
Remote host said: 550 Client host rejected: cannot find your hostname, [212.36.28.106]
Giving up on 193.201.172.114.

Ако не получават такъв отговор:

snagles@karai:~$ host -a 212.36.28.106
Trying "106.28.36.212.in-addr.arpa"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32561
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;106.28.36.212.in-addr.arpa.    IN      PTR

;; ANSWER SECTION:
106.28.36.212.in-addr.arpa. 86365 IN    PTR     metizi-co.com.

Received 71 bytes from 10.0.0.29#53 in 2 ms

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

Здравей,
Имам подобен 'setup' и не съм се занимавал с ISP-то.
Сложил/експортнал съм една променлива от "bash"-а която е в средата на потребител които изпраща поща (може и глобално).
QMAILIDHOST=connection-004.ISP.net (в $HOME/.bash_profile).
Това при мен работи, когато се проверява обратният DNS той си отговаря, съвпада следователно минава.
Не съм пробвал с "mail.bg" само с "dir.bg".
Виж пак и препоръката на "zarhi" за записа на твоя DNS сървър.
При мен отговаря че IP-то е на същия domain който е в мейла.
Виж тук в сайта имаше някъде (май в "docs" или "books") едно Howto за qmail на български, там е описано (взето е оттам).
Успех.Румен

Просто изчакай да мине известно време, за да се обнови DNS кеша.

А сега да обобщим накратко за т. нар. "обратно преобразуване". Тази проверка изобщо не се интересува от адреса на подателя, т.е. подателят може да има адрес към домейн, който е еди къде си. Проверката се интересува от легитимацията на сървъра, който изпраща писмото. Да речем, че сървърът ви е с IP 1.2.3.4.

1. Необходимо е на IP-то сървъра ти да отговаря валидно име на хост (грижата за това има доставчикът, който  е LIR за съответната мрежа и най-често това е вашия ISP).

Проверката "host -t a 1.2.3.4." трябва да връща FQDN. Например приемаме, че връща mail.alabala.com.

2. Същото име на хост трябва да връща като отговор въпросното IP (грижата за това си е на собственика на домейна, т.е. ваша/наша или на доставчика).

Проверката "host -t a mail.alabala.com" да връща 1.2.3.4.. Ако връща друго или не връща нищо (няма прав резолв), проверката се проваля.

Често пъти някои доставчици правят само първото и пощенските сървъри като mail.bg или linux-bg.org ще отхвърлят отново писмата, идващи от такива източници.

Когато на един сървър се обслужват множество виртуални домейни, не е необходимо и те да се "разписват" в зоната in-addr.arpa. Не бъркайте адреса в реда FROM: на вашето писмо с адреса на сървъра, който се регистрира в пълните хедъри на писмото, от които пък може да се проследи точно откъде и през кои сървъри е минало. Въпросната проверка се прави, преди още проверяващият сървър да е разбрал кой е подател и кой - получател на писмото. Т.е. по протокола SMTP се прави при подаването на заявката "hello". Едва след нея идват "mail from" и т.н., до които може изобщо да не се стигне.

А mail.bg използват postfix, не qmail. Той има един параметър, който се слага в smtpd_recipient_restrictions, който гласи reject_unknown_hostname и връща точно съобщението за грешка, с което се сблъсквате: "Helo command rejected: Host not found". Тази директива кара сървъра да прави точно това - проверява дали IP-то има FQDN и дали този FQDN съответства на това IP. Това нещо блокира от само себе си доста голямо количество боклуци и източници на тонове спам.

Този тип проверки е добре да вървят и с още няколко, които проследяват дали домейнът на подателя е валиден и дали съответства на FQDN. Тази проверка се включва с параметъра reject_unknown_sender_domain. Досещате се, че тази проверка вече се прави при подаване на "mail from". Ако се окаже, че домейнът на подателя изобщо не съществува, писмото се отхвърля.

Postfix е доста благодарен на такива рестрикции, които според мен са много полезни. Електронната поща и без това е ужасно несигурна услуга. Срамота е да се правят сървъри, които да не съответстват на елементарни препоръки, които са си по RFC освен това.

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

Важното е, че се оказа при мен проблемът разбира се в доставчика. Оправи името на IP_то и всичко проработи от раз. Единственото за което много ме е яд е, че за това нещо говоря с него от 6 месеца и чак сега изгря идеята че може би от това е проблема. Важното е, че стана и благодаря за всички съвети които дадохте тук.