[megoldva] Local service error ?

Web, mail, IRC, IM, hálózatok

Nehezen tudom értelmezni a "Local service error" hibaüzenetet. Imé a vonatkozó log:

2012-03-12 13:04:36 1S73MZ-0003Oi-IA == ***.***@volksbank.hu R=dnslookup T=remote_smtp defer (-44): SMTP error from remote mail server after RCPT TO:<***.***@volksbank.hu>: host svc0.volksbank.hu [195.228.178.1]: 450 <12.23.34.56.customer.hostoffice.hu[12.23.34.56]>: Client host rejected: Local service error

Az IP címeket kicseréltem. Az exim kissé bővebben ilyet ír: 

exim -v -M  1S73MZ-0003Oi-IA
delivering 1S73MZ-0003Oi-IA
R: dnslookup for ***.***@volksbank.hu
T: remote_smtp for ***.***@volksbank.hu
Connecting to svc0.volksbank.hu [195.228.178.1]:25 ... connected
  SMTP<< 220 SMTP
  SMTP>> EHLO 12.23.34.56.customer.hostoffice.hu
  SMTP<< 250-puma.volksbank.hu
         250-PIPELINING
         250-SIZE 104857600
         250-VRFY
         250-ETRN
         250 8BITMIME
  SMTP>> MAIL FROM:<*******@c3d.hu> SIZE=6231
  SMTP>> RCPT TO:<***.***@volksbank.hu>
  SMTP>> DATA
  SMTP<< 250 Ok
  SMTP<< 450 <12.23.34.56.customer.hostoffice.hu[12.23.34.56]>: Client host rejected: Local service error
  SMTP<< 554 Error: no valid recipients
  SMTP>> QUIT

Elsőnek arra gondoltam, hogy balga voltam, és az EHLO-ban megadott hostnév nem oldható fel rendesen. De mégis. Aztán arra gondoltam, hogy biztos az a baja, hogy más jön vissza a reverse után mint ami az ehlo-ban van, ezért azt is átállítottam, hogy most már végképp stimmel az ehlo oda-vissza, mindenképp, de az üzenet továbbra is így jön.

Most kértem, hogy a reverse a saját zónánkban lévő hostnévre oldódjon fel, az amúgy is egészségesebb lenne, de félek tőle, hogy nem ez lesz a probléma. Találkozott már valaki a "Local service error"-ral, és sikerült megoldania?

(A levél egy másik smtp szerveren keresztül - aminek jó az ehlo-ja oda vissza -, elment.)

Update: megoldottnak jelölöm, ha kis szerencsénk van, soha többé nem kell a volksbankkal leveleznünk, és nem várom ki, hogy az új levél is elmegy-e.

  • 3147 megtekintés

( zeller | 2012. 03. 12., h – 15:28 )

Az 554 elvileg szépen mutatja, hogy címzett ismeretlen, azonban a 450-nel együtt nekem az a halovány feltételezésem van, hogy biza nem sikerül a valid címzettek listáját lekérdeznie az MTA-nak, és emiatt mond bután 554-et.

Reszben, reszben hulye a log formazasa. Ugye a harom felso es a harom also sort parban kell olvasni. Kicsit atrendezve: 


  SMTP>> MAIL FROM:<*******@c3d.hu> SIZE=6231
  SMTP<< 250 Ok
  SMTP>> RCPT TO:<***.***@volksbank.hu>
  SMTP<< 450 <12.23.34.56.customer.hostoffice.hu[12.23.34.56]>: Client host rejected: Local service error
  SMTP>> DATA
  SMTP<< 554 Error: no valid recipients
  SMTP>> QUIT

Itt alapvetoen az egyik - szamomra erdekes - dolog, hogy az exim - ha mar egyszer kapott egy 450-et akkor - mi a francert eroskodik a DATA-val? Ez mintha konfig problemara utalna, nem (nem vagyok eximes)?

A fo problema a Local service error. Tippre az lehet, hogy a tavoli szero vagy MySQL gone away-t, vagy valami hasonlot kap (mindenesetre nem tudja elerni az adatforrasait), es keptelen eldonteni, hogy az RCPT to az valid-e. Mivel nem explicite invalid, ezert nem kuldhet vissza ilyen ertelmu problemat (vagyis, hat ez eppen igy van beallitva, hogy ne kuldjon explicite elutasito valaszt). Ha jol remlik, akkor a 450 az meg betriggerelheti a "probald kesobb" viselkedest. Az 554 az mar csak kovetkezmeny, mert elvben a protokoll megengedi, hogy tobbszor probalkozz az RCPT TO paranccsal (asszem ha tobb cimzett van u.a. szeron, akkor igy is lehet sporolni). Itt eppen egyik RCPT TO sem adott vissza rendes valaszt (mind az az 1), szoval coki.

Egyet jegyezz jol meg: nincs olyan SMTP parancs, amire ne jonne valasz (meg a DATA-ra is jon, ha le van zarva). Ha valahol azt latod, hogy csak mennek befele a parancsok, de semmi nem jon ra, akkor kezdd el keresni a valaszok listajat, ha nincs, akkor valami fekete lyukkal beszelgettel, de azt az SMTP kliensnek az elso kerdes utan timeouttal fel kell adnia. Ilyen szempontbol barati az SMTP protokoll, mert parbeszed-alapu.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Próbálkozott az újraküldéssel.

Nekem az jön le - de csak megérzés, semmi értelmes, szakmai okot nem látok rá(*) -, hogy van egy(?) külső smtp szerverük, ami vagy csinál valami alap ellenőrzést, vagy nem (vírus, rbl, bármi), ezen átmegy a levelünk, mert amúgy remek levél.

Miután átment az első védelmi vonalon, megkapja egy másik, belső smtp szerver, ami még egyszer, már jóval szigorúbban ellenőrzi a levelet, és undorodva visszalöki, hogy nincs érvényes címzett. Emiatt lehet a local service error, mert gondolom már a külső smtp szerver se fogad el levelet nem létező címre.

Persze ez az elmélet több helyen is sántít, pl. hogy ellenőrzi, hogy van-e megfelelő reverse a küldő gépre. Mert mi van, ha az első küldő gép címe pl. 10.12.31.33, vagy bármi más privát tartományba eső cím? HELO, EHLO-t nem tud ellenőrizni(?), szóval annyira mégse nagyon értem. Hacsak nem MX-et ellenőriz,
HELO/EHLO helyett.

Mindenesetre ha új levél esetén is működik, akkor átírom megoldottra a topikot.

*) Mármint a fenti logban.

Egyszerű, mint a faék: 450, mert az rcp to-ban megadott mailboxba per pill. nem tud kézbesíteni. Az, hogy miért, az nem rád, mint küldőre, hanem a helyi üzemeltetőkre tartozik elsősorban, de vélhetően tényleg az, hogy nem tudta ellenőrizni, hogy valid-e a címzett. A többi szutty (data meg rá az 554) már fölös szemét a kommunikációban.

Hát jahm, ez lenne a logikus magyarázat.Viszont a címzett ellenőrzése hiba űgy jött elő, hogy közben elment a levél ugyan annak a címzettnek egy másik szerveren keresztül, majd hirtelen erről is, amint átírták a reverse-t. Tehát a címzett az jó volt, csak a hibaüzenet kissé megtévesztő.

Nem "utána" próbálkozik a pipelineinggal, hanem ha pipelining módszert választ, akkor részére ezt írja elő az RFC:

3.1. Client use of pipelining
Client SMTP implementations that employ pipelining MUST check ALL statuses associated with each command in a group. For example, if none of the RCPT TO recipient addresses were accepted the client must then check the response to the DATA command -- the client cannot assume that the DATA command will be rejected just because none of the RCPT TO commands worked. If the DATA command was properly rejected the client SMTP can just issue RSET, but if the DATA command was accepted the client SMTP should send a single dot.

Hat gebedjek meg, en eddig ugy tanultam, hogy az SMTP kommunikacio az valami ilyesmi: 


C: HELO val.ahol.com
S: 250 orion.localdomain
C: MAIL FROM: izeke@val.ahol.com
S: 250 2.1.0 OK
C: RCPT TO: hron@orion.localdomain
S: 250 2.1.5 Ok
C: DATA
S: 354 End data with <CR><LF>.<CR><LF>
C: .
S: 250 2.0.0 Ok: queued as 4F4F02B2337
C: QUIT
S: 221 2.0.0 Bye

de ezek szerint akkor rosszul tudom? Merthogy ez a kronologiai sorrend, ennek igy kell zajlania, maskeppen nem SMTP kommunikaciorol beszelunk. De legyszives, mutasd meg, hogy nez ki egy SMTP kommunikacio a valosagban.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal