"Please try again later" -problem

[valdiq]

Witam,
widze ze forum jeszcze "swieze" ale byc moze ktos kto go odwiedzi pomoze rozwiazac problem.

Mam nainstalowanego qmaila na linuxie jako relay dla Ex2K. Wszystko pracuje bez zarzutu do momentu, gdy maile do niektorych adresatow zostaja zamrozone w kolejce, a po odpowiednim time-oucie otrzymuje:
451 4.3.2 Please try again later

W trakcie doswiadczen stwierdzilem, ze bez zarzutu docieraja na ten sam adres proste maile tekstowe. Klopot jest przy wysylaniu zalacznikow powyzej 600k.
Smtpdiag nie wykrywa zadnych problemow, niestety jego komunikacja jest pewnie z polki tych prostych, niewielkorozmiarowych maili.

Czy ktos mail moze ten problem ? Moze ktos podpowie jak go rozwiazac.

Valdiq

[Krzysztof]

Podaj prosze wiecej szczegolow aby wyjasnic jak przekazujesz emaile, z jakich filtrow i zabezpieczen antyspamowych korzystasz, czy qmail jest zainstalowany goly, czy tez z patchami (jakimi?) badz dodatkowymi programami.

Nie jestem tez pewien o kierunku wiadomosci - zatrzymywane sa w kolejsce qmaila wiadomosci przychodzacymi z zewnatrz, ktore maja byc nastepnie przekazane do Ex2K?

Na pierwszy rzut oka problem wyglada na ograniczenie wielkosci zalacznikow (czy miejsze przechodza?) lub brakiem wystarczajacej ilosci pamieci na ich przeskanowanie np. spamassassin wymaga wiekszej ilosci pamieci (perl). Sprobuj poszukac logow programu qmail-send badz qmail-smtp, jesli chodzi o maile wysylane na zewnatrz. Moze tam beda konkretniejsze informacje o wystepujacym problemie.

[valdiq]

Przepraszam, rzeczywiscie troche moglo to byc nieczytelnie.
Poczta przychodzaca czyli Inet->qmail->Exchange dziala bez zarzutu. Poczta wychodzaca Ex->qmail->Inet rowniez w 99 % dziala poprawnie.
Niestety zdarzaja sie (ostatnio coraz czesciej) sytuacje w ktorych mail wysylany wisi w kolejce qmaila, a po odpowiednim czasie nadawca (klient Ex) dostaje standardowa "cofke" w brzmieniu "451 4.3.2 Please try again later". 
Z poczatku ignorowalem ta sytuacje, sadzac, ze klopot lezy po stronie odbiorcy - serwer jest obciazony lub cos podobnego.
Dodatkowo, kolega moj kontaktowal sie z adminami domen, do ktorych nie moge dostarczyc wiadomosci. Otrzymal odpowiedz, ze klopot tkwi w "niewlasciwych naglowkach" maili wysylanych z mojego serwera (??). Niestety bez zadnych detali. Poniewaz ta odpowiedz pochodziala - jak sadzilem - od "solidnego" operatora hostujacego poczte, przegladam cala konfiguracja w poszukiwaniu problemu, zakladajac, ze ta odpowiedz nie jest klamstwem. Na dodatek, przeslanie takiej "zlej" wiadomosci na inny qmali (przez smtproutes i zezwolenie na selektywne relayowanie od mojego na tamtym serwerze ) spowodowalo poprawne dostarczanie poczty. Rozpoczalem analize ...
Jedyny klopot jaki zauwazylem, to fakt iz wysylanie wiadomosci nastepowalo z ip, ktore nie jest mx-em mojej domeny (ten drugi qmail byl zapasowym mx-em). Choc RFC tego nie zabrania wiem ze czesc systemow antyspamowych odrzuca takie przesylki.
Nie rozumiem jednak dlaczego w tej samej konfiguracji odrzuca wylaznie maile z zal. wiekszym od kilkaset kilo, zas male maile dochodza, ale to moze byc konfiguracja docelowego systemu antyspamowego. Poprawilem jednak dns wstawiajac jako mx adres serwera wysylajacego poczte. NIc to nie dalo

Moja instalacja jest zupelnie standardowa,  nie korzystam z antyspamu na qmailu ani antywirusa (w kazdym razie do teraz, bo zamierzam to zmienic).
W logach qmaila tez nie ma niestety nic szczegolnego:
> Nov 20 18:09:52 leogate qmail: 1164046192.295731 new msg 3699224
> Nov 20 18:09:52 leogate qmail: 1164046192.295781 info msg 3699224: bytes 926882 from <moj adres> qp 28924 uid 387
> Nov 20 18:09:52 leogate qmail: 1164046192.587670 starting delivery 32719: msg 3699224 to remote test@docelowa.domena <-adres jes wlasciwy, male maile przechodza
> Nov 20 18:10:03 leogate qmail: 1164046203.751227 status: local 0/30 remote 24/50  <- bo to kolejna juz proba

i wisi..   Brak typowej w takiej sytuacji odpowiedzi "Remote host sad:" cokolwiek nie byloby w niej.
PO 4 godzinach mam odpowiedz: "Will keep trying until message is 5 days old", a potem "Sorry, I'll give up, .. this message has been in the queue too long" 

Nie wiem czy mozna zmusic qmaila do bardziej szczegolowych  informacji Jesli tak bede wdzieczny za podpowiedz.

Scenariusz ten dotyczy wszystkich maili obslugiwanych przez duzego hostujacego ISP. zalozylem wiec ( moze nieslusznie), ze maja poprawnie skonfigurowane sytstemy pocztowe. Zaczalem szukac na wszystkich forach, czy aby ktos nie ma/mial podobnego problemu. Stad ten post ...

Gdyby konieczne byly szczegolowe dane konfiguracji qmaila to oczywiscie moge podac.
Naturalnie poza poszukiwaniem rozwiazan technicznych ( jak ten wymuszony relay) szukam tez innych - organizacyjnych, ale to zupelnie inna sprawa ...

[Krzysztof]

Po tym co napisales to nie jestem pewien czy maile zatrzymywane sa w kolejce qmaila czy tez jeszcze w Ex-u. Proponuje zainstalowac maly programik qmHandle, ktory umozliwia podglad zawartosci kolejki qmaila.
Druga sprawa to przeszukanie logow qmaila i systemowych dot. maili - jesli problemem jest qmail (nie moze wyslac dalej wiadomosci) to musza byc komunikaty o przyczynie opoznienia. Proponuje tez zainstalowac programik qmailanalog do generowania prostych statystyk ilosci przeslanych maili, oraz powodow opoznien/niedostarczenia. Oba programiki opisane zostaly w ksiazce o qmailu, ale moze je rowniez latwo w google znalezc wraz z opisem instalacji i obslugi.

Co do fragmentu logow, ktore wkleiles - "starting delivery 32719: msg 3699224 to remote"  - po tym komunikacie pojawia sie nastepny (nie koniecznie w nastepnej linii, bo qmail obsluguje wiele wiadomosci rownoczesnie) zawierajacy ten sam numer id wiadomosci lub procesu (tu 3699224-id wiadomosci,  32719 -id procesu). Przeslij wiecej linii to moze z nich cos sie wyczyta.

pozdrawiam,
Krzysztof