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

Здравейте , несъм сигурен дали проблема е при мен или в отсрещната страна но всепак да попитам.
Проблема е ,че не се получават писмата от един хост. От всякаде другъде идват или поне несъм забелязал да има проблем.
Използвам qmail
В лог-а на qmail-smtpd виждам:
010-06-29 17:10:17.161125500 tcpserver: status: 5/40
2010-06-29 17:10:17.161273500 tcpserver: pid 27124 from 1.2.3.4
2010-06-29 17:10:17.163494500 tcpserver: ok 27124 mydomain.net:::ffff:4.3.2.1:25 mx.host.com:::ffff:1.2.3.4::36423
След известно време дава:
2010-06-29 17:25:58.163494500 qmail-smtpd: Connection to 1.2.3.4 timed out.
в логна на qmail-send нищо не се получава относно писмата от този хост.
при netstat -tupan |grep 1.2.3.4
виждам няколко
tcp        0      0 4.3.2.1:25         1.2.3.4:38087     ESTABLISHED 28783/qmail-smtpd

Когато аз изпращам писма към тях , писмата се получават.
Заместил съм ip-тата и хостовете с измислени.

Благодаря предварително

Пробвай да пратиш текстови маил от проблемият хост чрез telnet.

telnet your-qmail-server.com 25

и гледай как ще реагира едновременно и на проблемият хост и логовете на qmail-а
 

Ами на този хост, мейл сървър ли има ? Или от мейл-клиент се пращат ? И там (на проблемния хост) да не ползват нет от някой хоум акаунт на VivaCom ? С филтриран 25 изходящ порт.

Проблемния хост е извън България, и за съжаления няма как да пробвам варианта с telnet-a. Иначе там има мейл сървър. Хората от там твърдят ,че проблема им бил само към моя сървър.

OK. Ако искаш кажи им да погледнат пък и те техните логове на мейлера им. Правилно ли се ресолва твоя мейлер, има ли някаква комуникация, и евентуално каква грешка дава там. Защото не може да не идва мейла и да не им казва ЗАЩО.

Другото което забелязах е ,че ми увисват процеси:
/var/qmail/bin/qmail-smtpd /var/vpopmail/bin/vchkpw /bin/true

 Щом не полузаваш писма само от *едно* място - проблема е при тях.

Интересното е ,че те твърдят че всички останали им получават писмата  :)

Ами тогава може би се губи някъде по пътя...
И аз ползвам qmail, до сега не ми се е случвало от точно определено място да не получавам писма.
Пробвай да опишеш мражата в /etc/tcp.smtp

п.с.
Само не забравяй да го reload-неш с "qmailctl cdb" защото на мен ми се е случвало, и се чудя 'тва що не бачка' :)

Ами тогава може би се губи някъде по пътя...
И аз ползвам qmail, до сега не ми се е случвало от точно определено място да не получавам писма.
Пробвай да опишеш мражата в /etc/tcp.smtp

п.с.
Само не забравяй да го reload-неш с "qmailctl cdb" защото на мен ми се е случвало, и се чудя 'тва що не бачка' :)

Ако имаш в предвид , да им разреша RELAY неискам :)

Не се губят писмата по трасето , струва ми се ,че отрещния mailserver незнае да си говори с моя :)
Защото както казах имам ETABLISHED connections oт отрещния сървър към моя , ама така си строят и в един момент timeout-ват.

Проблемния хост е извън България, и за съжаления няма как да пробвам варианта с telnet-a. Иначе там има мейл сървър. Хората от там твърдят ,че проблема им бил само към моя сървър.

Каква връзка има това, че сървърът е извън България, с това, че не можеш да пробваш варианта с telnet? Или нямат връзка? Изясни защо не може да се пробва с telnet, защото аз не се сещам за читава причина за това, а пробата с telnet е важна стъпка в разрешаването на проблем от този сорт - можеш да получиш много информация за проблема. В момента си в позиция на хвърляне на боб. Особено при положение, че те получават твоите писма, а ти техните не. В този случай пробата с telnet трябва да бъде направена от отсрещната страна, а не от теб. Проблеми се изследват по посока на движение на проблема. Ти си крайната точка, би трябвало да си най-последната стъпка на дебъгването. Накарай ги да си прегледат какво пише в техните логове за писмото, което изпращат. Ако не намират някакъв проблем в тях, да ти ги пратят, след което можеш и да ни ги покажеш. Ако нямат логове за писмата, къде са тръгнали? След това да пробват да пратят писмо през telnet към теб и да гледат внимателно какво ще им отговаря telnet. Ако не виждат някакъв проблем в изписаното от telnet, да ти пратят резултата от целия опит, след което можеш да го покажеш и на нас. След това ще се мисли какво да се прави по-нататък. Постен отговор "проблемът не е при нас" е кух и безполезен. Нека да четем логове и изходи. Ако не могат да покажат тази информация, то дори и текущият проблем наистина да не е при тях, така или иначе явно има голям проблем при тях за решаване.
В момента си застанал в подобна ситуация - някой ти праща колет, но колетът не пристига, а ти се опитваш да разбереш защо не е пристигнал, съдейки единствено по празното място на бюрото ти. Изискай нужното от отсрещната страна, след което изследвайте междинните точки, и чак накрая съзерцавай празното място на бюрото ти ;)

Цитат на: Mitaka в Jun 29, 2010, 22:45

Ами тогава може би се губи някъде по пътя...
И аз ползвам qmail, до сега не ми се е случвало от точно определено място да не получавам писма.
Пробвай да опишеш мражата в /etc/tcp.smtp

п.с.
Само не забравяй да го reload-неш с "qmailctl cdb" защото на мен ми се е случвало, и се чудя 'тва що не бачка' :)

Ако имаш в предвид , да им разреша RELAY неискам :)

Не се губят писмата по трасето , струва ми се ,че отрещния mailserver незнае да си говори с моя :)
Защото както казах имам ETABLISHED connections oт отрещния сървър към моя , ама така си строят и в един момент timeout-ват.

Съвета ми е да пробваш по този начин.
Така, ако получиш писмото, ще знаеш, че става въпрос за няквки объркани правила...
Какви са те - в момента може само да се гадае.
Особено ако си инсталирал spamassassin, и qmailscanner (а едва ли не си ги сложил...), проблема може да е на много места.
Прегледа ли логовете от скенера, които по подразбиране са в  "/var/spool/qmailscan/"?
Добавяйки хоста в tcp.cdb писмата, пристигащи от него автоматично стават "доверени".

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

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

Обратен резолв имаш ли? То при него май проблема беше като изпращаш, ама де да знам .. сървери всякъкви...
Да не би пък те да нямат обратен резолв и затова твоят qmail да ги реже?
 

Защото както казах имам ETABLISHED connections oт отрещния сървър към моя , ама така си строят и в един момент timeout-ват.

Това ясно, но не казваш дали в началото върви някакъв трафик от тях към теб. Ако има някакво огромно писмо в опашката на техния сървър към теб, може да става това, което описваш. Като мине времето (3 или 5 дни или кой знае как им е конфига), това писмо ще бъде премахнато от опашката и проблемът ти ще се реши.

има какво да се направи и от отсамната страна... tcpdump или iptraf настроени да прихващат само връзките от дадения адрес... ако искаш графично - ethereal, wireshark или както се казва в момента че им изтървах вече прекръщаванията и там е с едно цъкане с мишката на даден адрес/връзка и Follow TCP/UDP etc. stream
Това ако както казваш имаш връзки от там "висящи" както твърдиш, обаче ако не "висят" бая време най-вероятно сървъра или някой друг демон по трасето ги отсява.. така на прима виста се сещам само за...
1. postgrey ...etc. greylist някакви - дето обаче връщат с правилното съобщение за отсяване на спамерите "опитайте след 300 сек. пак" та виж и в техните журнали какво пише (ако ползваш нещо подобно) и другият тип са дето проверяват в онлайн БД - провери да не са им влезли у БД и да се извадят ако не са спамери.
2. Обратният resolv да не работи ...техният и/ли твоят - провери ги.

От отсрешната страна твърдят , че при опит да се казачат с telnet на  около30сек ги дропело.
Пробвах да пусна отделен mail server със Sendmail към който да пренасоча само трафика от техния та там се вижда timeout пак:
Jun 30 11:45:54 TestSRV sendmail[3363]: o5U7jsAu003363: SYSERR(root): collect: read timeout on connection from srl.alvarion.com, from=<user@domain.com>
Jun 30 11:45:54 TestSRV sendmail[3363]: o5U7jsAu003363: from=<user@domain.com>, size=994, class=0, nrcpts=1, proto=ESMTP, daemon=MTA, relay=domain.com [1.2.3.4]

Dvbb, ами то и telnet ако не могат да направят твойте хора на 25 порт на сървъра ти (и то стабилен, без дропове и time-out-и), какви мейлове ще минават ? Интересна работа. Кой ще ги реже, и то само тяхното име/IP ? Сега пуснах и аз два telnet-и до мой мейлер, без да пиша нищо после като команди, само отворих сесии. Нарочно и с Linux-ки и с Windows-ки telnet. Да видя колко време ще стоят, преди да ме разкачи отсрещната страна. Над 5 минути чакам вече, никакъв проблем, конекциите са ОК. QUIT и прекъснах сесиите.

Топката е отсрешното блато. Като ми пращат писма през други техни Relay сървъри писмата минават без проблем.