Изпечатай

[snagles]

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

550 Client host rejected: cannot find your hostname.

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

[zarhi]

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

[rpetrov]

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

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

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

[laskov]

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

[snagles]

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

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

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

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

[zarhi]

Цитат (laskov @ Април 13 2005,17:45)

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

Reverse изобщо не е необходим за да изпратиш поща. Но има 2 минимални степени за защита от спам:

1. При инициране на smtp получаващия майл сървър прави реверс за ип-то което се конектва. След като получи hostname прави и прав ресолв за този хост. Резултата трябва да е конектналото се ип. Това е приложено в майл.бг и доколкото си спомням е стандартна екстра за qmail.

2. 1-вото + че домайна на получен от обратния ресолв трябва да има MX запис за този хост.

[snagles]

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

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

[zarhi]

Цитат (snagles @ Април 13 2005,22:18)

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

Достатъчно е правия и обратния ресолв да съвпадат и домайна на този ресолв да има МХ запис същия този ресолв. Пример:

zarhi:~ # dig +short dir.bg mx
1 mail.dir.bg.
zarhi:~ # dig +short mail.dir.bg
194.145.63.28
zarhi:~ # dig +short -x 194.145.63.28
mail.dir.bg.
zarhi:~ # telnet mail.dir.bg 25
Trying 194.145.63.28...
Escape character is '^]'.
220 dir.bg ESMTP CommuniGate Pro 4.2.8

Този майл сървър приема и изпраща поща и за доста други домайни. Но когато се прави проверката се почва само от ип-то което се е конектнало, в случая 194.145.63.28. Обратния ресолв на 194.145.63.28 отговаря с mail.dir.bg. Правия на mail.dir.bg отговаря с 194.145.63.28. Домайна dir.bg има МХ запис за mail.dir.bg. Значи всички условия са спазени: това е реален майл сървър и от него е ок да се получава поща, без значение дали FROM адреса на конкретния майл е @dir.bg или е @xyz.com.

Допълнително може да се прави всякаква СПАМ проверка, но тя евентуално ще маркира конкретния емайл.

[zarhi]

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

[snagles]

Цитат (zarhi @ Април 14 2005,09:28)

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

Използвах конфигуратора от тази страница. Между другото ако така заработи ще съм много щастлив '> хората са направили много добър скрипт. Предполагам че е необходимо да мине малко време за да се ресолвнат новите записи. Страницата е супер даже дава готов запис за BIND и djbdns което използвам.

с: dig +short -x ххх.ххх.ххх.ххх не ми дава никакъв отговор за момента. Надявам се да стане.

Благодаря за предложенията.

[snagles]

Ще се наложи да подновя тази тема, защото май нищо не може да стане и ако трябва да сме честни тези които са правили 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 в арпата да отговарят разични имена. То излиза че не трябва да пускаш меил сървър, защото няма как на различните домейни да им правиш имената в обратния резолв.
С голямо нетърпение чакам някакъв съвет и идея как може да се излезе от това положение.

[ray]

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

[n_antonov]

Просто изчакай да мине известно време, за да се обнови 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 освен това.

[snagles]

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

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