mail:constans 1 óra késés egyes domainek felöl érkező leveleknél

Sziasztok!

Adott egy régi postfix levelező szerver, debian alapokon, hamarosan le lesz cserélve exchange-re, jelenleg mindkettő működi, a debian-ra jönnek a levelek és amelyik exchange emailcím már kész van azt továbbítja az exchange-nek amelyik még nincs azt kiszolgálja ő.
A gond az, hogy van egy két domain ahonnan egy óra késéssel jönnek be a levelek, ennek szeretnék utána járni, már a debian-ra késve érkeznek meg a /log/mail.info szerint.
Most kaptam egy ilyen domaint, tudom tesztelni. Első körbe fejlécet néztem, amiből nem lettem okosabb, aztán nslookuppal ránéztem:
10.0.1.242 saját belső dns szerverünk, néztem a google 8.8.8.8 szerevrével és azzal is ugyan ez a jelenség.
nspa.nato.int innen jön a levél.

nslookup nspa.nato.int
Server: 10.0.1.242
Address: 10.0.1.242#53

Non-authoritative answer:
*** Can't find nspa.nato.int: No answer

debian:~# nslookup google.hu
Server: 10.0.1.242
Address: 10.0.1.242#53

Non-authoritative answer:
Name: google.hu
Address: 173.194.35.184
Name: google.hu
Address: 173.194.35.191
Name: google.hu
Address: 173.194.35.183

Segítségeteket szeretném kérni, hogy mitől lehet az 1óra késés egyes domaineknél.

szerk:
két levéllel próbálkoztak, itt vannak a fejlécek:
levél 1: http://pastebin.com/2EWR2UPW
levél 2: http://pastebin.com/2QimNAU4

Hozzászólások

"már a debian-ra késve érkeznek "

greylisting?
Esetleg nem is későn érkezik meg, csak eltérő időzónák miatt nem stimmel az idő a levélen?

Egyébként meg a küldő fél rendszergazdájánál érdemes érdeklődni.

a küldő fél rendszergazdája mindig más 2-3 havonta van egy-egy ilyen domain vagy legalább is ennyiszer szólnak :( mondtam próbálják ki gmail-re is, oda megérkezett ahhoz képest 1óra múlva esett be hozzánk, ez nem időzóna lesz :(

szerk.: ez a greylist érdekes, mert azt hiszem van rendelve 3. féltől(invitel?? ennek még utána nézek) spam szűrés de tudtommal úgy működik, hogy csak megjelöli spamnak az üzit ha olyan és továbbítja hozzánk, elvileg a spamszűrő nem dob(hat) el semmit.

Ahogy zeller is utalt rá, nem mindegy, hogy az időpontokat milyen időzóna alapján hasonlítod egymáshoz. Az egy óra utalhat pl. az UTC és UTC+0100 közötti különbségre is. Egy késett levél fejlécének Date: és Received: soraiból sokminden kiderülhet. Nézz meg egy ilyet, és vesd össze a Debian logjaival.

A DNS-es kérdésre pedig: a nato.int zónának a dnsmaster.nato.int (192.101.252.68) szervere úgy tűnik nem érhető el, viszont a többi NS válaszol:


# host -v -t any nspa.nato.int. ns.saclantc.nato.int.
Trying "nspa.nato.int"
Using domain server:
Name: ns.saclantc.nato.int.
Address: 192.106.197.1#53
Aliases:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62749
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 3, ADDITIONAL: 4

;; QUESTION SECTION:
;nspa.nato.int.                 IN      ANY

;; AUTHORITY SECTION:
nspa.nato.int.          86400   IN      NS      maxima.nra.nato.int.
nspa.nato.int.          86400   IN      NS      max.nra.nato.int.
nspa.nato.int.          86400   IN      NS      ns.namsa.nato.int.

;; ADDITIONAL SECTION:
ns.namsa.nato.int.      86400   IN      A       193.168.15.15
ns.namsa.nato.int.      86400   IN      A       193.168.11.15
max.nra.nato.int.       86400   IN      A       192.101.252.69
maxima.nra.nato.int.    86400   IN      A       193.110.130.68

Received 161 bytes from 192.106.197.1#53 in 53 ms
#

 
 

# host -v -t any nspa.nato.int. ns.namsa.nato.int.
Trying "nspa.nato.int"
Using domain server:
Name: ns.namsa.nato.int.
Address: 193.168.15.15#53
Aliases:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33365
;; flags: qr aa rd; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 4

;; QUESTION SECTION:
;nspa.nato.int.                 IN      ANY

;; ANSWER SECTION:
nspa.nato.int.          300     IN      MX      10 server2.namsa.nato.int.
nspa.nato.int.          300     IN      MX      100 server3.namsa.nato.int.
nspa.nato.int.          300     IN      SOA     ns.namsa.nato.int. dnsadmin.namsa.nato.int. 2012051336 7200 3600 2419200 300
nspa.nato.int.          300     IN      NS      ns.namsa.nato.int.
nspa.nato.int.          300     IN      NS      maxima.nra.nato.int.
nspa.nato.int.          300     IN      NS      max.nra.nato.int.

;; ADDITIONAL SECTION:
ns.namsa.nato.int.      300     IN      A       193.168.15.15
ns.namsa.nato.int.      300     IN      A       193.168.11.15
max.nra.nato.int.       86400   IN      A       192.101.252.69
maxima.nra.nato.int.    86400   IN      A       193.110.130.68

Received 254 bytes from 193.168.15.15#53 in 27 ms
#

ez az amit fent említettem:

Received: from server3.namsa.nato.int (server3.namsa.nato.int
[193.168.11.192]) by mail-gw1.sa.ew.hu (mu) with ESMTP id qAFAtgYb024317 for
; Thu, 15 Nov 2012 11:55:44 +0100
Received: from unknown (HELO SMTP2.namsa.nato.int) ([172.20.123.26]) by
server3.namsa.nato.int with ESMTP; 15 Nov 2012 11:23:55 +0100

itt jól látszik egy fél órás késés, hogyan tudnám kideríteni, hogy mégis mi a fenét csinált fél óráig ez a levél?

Ezt a elsődlegesen a server3.namsa.nato.int, utána pedig a mail-gw1.sa.ew.hu üzemeltetőjétől kérdezheted meg. Ilyenkor lehet írni a postmaster@-ra egy érdeklődő levelet.

De még mielőtt ezt tennéd, vedd figyelembe azt, hogy ha megpróbálod közvetlen a mail-gw1.sa.ew.hu-t (mx.euroweb.hu) SMTP-n megszólítani, látszik hogy van greylisting, egy szép "451 4.3.2 Temporary failure, try again" üzenettel újrapróbálkozásra szólít fel. A megadott időt kivárva viszont "250 2.1.5 <berda@xxxxxxx.xx>... Recipient ok" üzenettel honorálja a küldő kitartását, és elfogadja.

Tehát a greylisting beállításairól az Invitelnél érdeklődhetsz.

Szerintem is greylisting a mail-gw1.sa.ew.hu szerveren. A másodikként linkelt 11:23-as levelet elsőre nem volt hajlandó átvenni, emiatt az a server3.namsa.nato.int gépen várakozott újraküldésre. Nézd meg, mit naplózott a mail-gw1.sa.ew.hu 11:23 környékén a server3.namsa.nato.int gépre vonatkozóan.