sziasztok,
exchange 2013 telepítés után minden működik, levelet küld/fogad, owa működik, stb, DE outlook klienssel nem tudok rácsatlakozni.
kapcsolódásnál próbáltam proxyt megadni, illetve az SSL proxyhoz megadtam az msstd:domain.tld-t, de nincs változás.
A hibaüzenet szerint "A Microsoft Outlook nem tud bejelentkezni. Ellenőrizze a hálózati kapcsolatot, valamint a kiszolgáló és a postaláda nevének helyességet. Nem érhető el a kapcsolat a Microsoft Exchange-kiszolgálóhoz. A művelet elvégzéséhez az Outlook programnak online, vagy csatlakozott állapotban kell lennie".
Az utolsó mondat fura, mert, ha fut az outlook, akkor exchange fiókot fel sem lehet venni :)
tippek hol nézelődjek? Exchange-nek melyik logjában láthatnám hol akad el a kapcsolódás?
köszi minden segítséget
- 18664 megtekintés
Hozzászólások
Szia!
Nézd meg, hogy a kliensen fent van-e a tanúsítvány amivel a CASt hitelesíti akár autodiscoverrel a postafiók felvételét az új profilhoz.
Kapcsolódási kísérletnél megnézed hogy a kliens IP melyik CASon kerül feldolgozásra, azon a CAS proxyn belül az alábbi logokat túrd meg:
c:\exchange mappa\V15\logging\httpProxy\RpcHttp
c:\exchange mappa\v15\logging\RpcHttp\w3svc1
Ugye a CU2 fel van rakva rá?
- A hozzászóláshoz be kell jelentkezni
szia!
Köszi a tippeket, arról hogyan tudok 100%-ra meggyőződni, hogy felraktam a megfelelő tanusítványt? Van valami howto erre esetleg? exportáljam ki az exchange-ből egy fájlba, húzzam át a kliens gépre és installáljam a legfelső szintű tárolóba? (melyiket kéne exportálni?)
a httpProxy logban ezt látom:
2013-09-23T13:04:31.068Z,baf6579d442c4faa93d6e1f83f8774dc,15,0,516,25,,RpcHttp,/rpc/rpcproxy.dll,,Basic,True,DOMAIN\teszt,,,MSRPC,89.134.155.81,EXCHANGE,404,,EndpointNotFound,RPC_IN_DATA,,,,,,,,1073741824,0,,,0,,,0,,0,,0,0,46.7862,1,,-1,41,0,43,42,?mail.domain.hu:6002,OnBeginRequest=0;,
ui: CU2 most települ, köszönöm ezt a tippet is!
- A hozzászóláshoz be kell jelentkezni
OWA alatt kaptál tanúsítványhibát a böngészőtől?
Az Outlook belső hálón van, vagy kívülről (exchange anywhere) akarsz csatlakozni? Ez utóbbi esetben az EX2k13 alatt ar rpc proxy-t jól állítottad be? 2010-nél sem ment magától, kellett vele bohóckodni egy kicsit exchange konzolon, mire hajlandó volt működni. 13-at nem ismerem, de gyanítom, hogy ezt is lökdösni kell.
Tűzfalon is nézz körül, meg a logokat se ártana átfutni.
--
PtY - www.onlinedemo.hu
- A hozzászóláshoz be kell jelentkezni
belső hálón tökéletesen működik, email fiók hozzáadásnak automatikusan kitölti a usernevet, stb. Kívülről vannak a problémák az outlook-kal, tanusítvány hibát nem kapok az OWA-tól, azt már telepítettem, jól működik.
rátaláltam a testexchangeconnectivity.com-ra, eszerint tényleg tanusítvány hiba lesz, most próbálom megoldani.
- A hozzászóláshoz be kell jelentkezni
már stimmel a CN is, egyetlen hibát ír a testexchangeconnectivity:
"Nem hozható létre tanúsítványlánc a tanúsítványhoz."
"A tanúsítványlánc nem megbízható főtanúsítványban végződik. Főtanúsítvány = CN=domain.hu"
- A hozzászóláshoz be kell jelentkezni
az nem gond, az a lényeg hogy adott gépen explorerben ha megnézed az owa-t akkor ne legyen tanúsítvány hiba.
testexchconnectivity ha nem rendes tanúsítványod van akkor nem fogja elfogadni.
- A hozzászóláshoz be kell jelentkezni
akkor ez nálam nem gond, mert telepítettem a legfelső szintű tanusítvány tárolóba. Ennek ellenére továbbra is azt írja, amit az elején.
logban továbbra is ezt látom:
2013-09-23T20:13:51.312Z,EXCHANGE,RpcHttp,"S:Stage=EndRequest;S:UserName=DOMAIN\teszt;S:OutlookSessionId=""{C23E94F2-387A-4957-9D50-0DCE126DC447}"";S:AuthType=Basic;S:Status=404 Not Found;S:HttpVerb=RPC_OUT_DATA;S:UriQueryString=?mail.domain.hu:6004;S:RequestId=7fd0d4c2-c515-4734-a606-69009d5dff66;S:AssociationGuid=ccf499a5-dbb9-4f1e-ba62-4ce9df533414;S:ClientIp=46.107.179.119"
2013-09-23T20:13:51.312Z,EXCHANGE,RpcHttp,"S:Stage=EndRequest;S:UserName=DOMAIN\teszt;S:OutlookSessionId=""{C23E94F2-387A-4957-9D50-0DCE126DC447}"";S:AuthType=Basic;S:Status=404 Not Found;S:HttpVerb=RPC_IN_DATA;S:UriQueryString=?mail.domain.hu:6004;S:RequestId=2a7dbd44-cfa6-4c8a-ad1c-2524e6a39ffc;S:ClientIp=46.107.179.119"
- A hozzászóláshoz be kell jelentkezni
Ettől még az rpc proxy-d lehet rossz...
--
PtY - www.onlinedemo.hu
- A hozzászóláshoz be kell jelentkezni
amikor rápróbálok a "https://mail.domain.hu/rpc/rpcproxy.dll" linkre, akkor autentikáció után le akarta tölteni a 0 bájtos fájlt, úgy tudom ez az elvárt működés.
- A hozzászóláshoz be kell jelentkezni
Nem tudom, mi az elvárt működés, és nem tudom - mert nem írtad -, hogy hogyan/milyen howto alapján állítottad be az rpcproxy-t, mert csupán engedélyezni nem elég (se 2003/2007/2010 alatt).
Mellesleg a post alatti hibalogot nézd már át, mert szemre egy csomó rpcproxy hiba van benne. :)
--
PtY - www.onlinedemo.hu
- A hozzászóláshoz be kell jelentkezni
nem találom a howto-t, de jogos, amit írsz. Irányba tudsz terelni? Mit kéne beállítanom/hol/hogy? Úgy sikerült megoldanom, hogy kiszolgálónak beírom a szerver belső címét, majd proxynál megadom a külsőt, de én szeretném ezt egyszerűbben megoldani.
köszönöm szépen előre is.
- A hozzászóláshoz be kell jelentkezni
Elviekben úgy kell, hogy a kiszolgáló a belső név, a proxy-nál meg a külső, mert ha az outlook bekerül a belső hálóra, akkor látnia kell közvetlenül is.
Csak akkor írhatod oda ugyanazt, ha belül is feloldható az a név, sőt, az AD-ban is az a neve az exchange-nek :)
Úgyhogy szerintem irányban vagy. :)
--
PtY - www.onlinedemo.hu
- A hozzászóláshoz be kell jelentkezni
épp most írt pár user, hogy nekik nem megy, pedig nekem a teszt userrel és a rendszergazdával ez a megoldás hibátlanul megy tizedszer próbálva is..
Nekik azt írja, hogy a postafiók nem oldható fel. Nem értem, ugyanarról a terminálszerverről próbáljuk..
azt látom, hogy ha ők próbálják az owa-t megnyitni, akkor nekik nincs bent a legfelsőbb szintű tanúsítványtárolóban az owa tanúsítványa, de nincs is lehetőség berakni. Egy mezei user hogy tudja ezt berakni?
- A hozzászóláshoz be kell jelentkezni
Szia!
Kérdezd le, hogy mik érhetőek el:
Get-ExchangeCertificate | Select Subject,IsSelfSigned,Services | ft -auto
Itt van leírás a tanúsítványokhoz. Alapból elfogadja a telepítéskor létrehozott és a tartománytagok klienseire terített saját aláírást. Kintről érdemes wildcard tanúsítvány venni, hogy a böngészők és mobilok is nyavalygás nélkül kapcsolódhassanak.
- A hozzászóláshoz be kell jelentkezni
Neked a tanúsítványtáradban megbízhatónak van jelölve a certificate, nekik nem.
Azt hittem, az elején már túllendültél ezen a hibaüzeneten :)
--
PtY - www.onlinedemo.hu
- A hozzászóláshoz be kell jelentkezni
igen, negyed órával később rájöttem, de már nem tudtam ide is írni :))
Köszönöm mindenkinek, hamarosan megveszik a wildcard tanúsítványt és akkor talán nem kapok agyvérzést a jövőben. Azt amúgy meg lehet oldani, hogy ne kelljen így proxyzni, hanem a kiszolgálónévhez egyből a külső nevet írhassam be?
- A hozzászóláshoz be kell jelentkezni
Persze. Kinyitod az exchange-et a nagyvilágba, és kész, de 5 perc alatt feltörik, és elviszik mindenedet.
Szóval ezt ne akard. Nem véletlenül találta ki a MS az Exchange Anywhere-t ;)
Amúgy meg az IMAP-SSL-t és az SMTP-SSL-t ki tudod engedni (persze csakis authentikációval, egyébként openrelay lesz), de akkor elbukod a naptárat, a címtárat, és a public foldereket - azaz minden olyat, amiért egyáltalán érdemes manapság Exchange-et tartani.
--
PtY - www.onlinedemo.hu
- A hozzászóláshoz be kell jelentkezni
meggyőztél, akkor jó így, ahogy van.
Köszönöm mindenkinek a segítséget!
- A hozzászóláshoz be kell jelentkezni
Örülök, hogy segíthettem. :)
Bár nem vagyok Exchange búvár, jobban érzem magam Linuxon :)
--
PtY - www.onlinedemo.hu
- A hozzászóláshoz be kell jelentkezni
httpproxy logban pedig ezt, ez már beszédesebb:
2013-09-23T19:48:21.065Z,f3495274-41c4-437f-91be-de1c651352b6,15,0,712,12,,RpcHttp,mail.domain.hu,/rpc/rpcproxy.dll,,Basic,True,DOMAIN\teszt,,,MSRPC,46.107.179.119,EXCHANGE,404,,EndpointNotFound,RPC_OUT_DATA,,,,,,,,,76,,,,0,,,0,,0,,0,0,0,1,,,,,,,,0,0,,1,1,1,1,?mail.domain.hu:6004,,OnBeginRequest=0;,HttpProxyException=Microsoft.Exchange.HttpProxy.HttpProxyException: Not allowed to proxy to: mail.domain.hu a következő helyen: Microsoft.Exchange.HttpProxy.RpcHttpProxyRequestHandler.ResolveAnchorMailbox() a következő helyen: Microsoft.Exchange.HttpProxy.ProxyRequestHandler.InternalBeginCalculateTargetBackEnd(AnchorMailbox& anchorMailbox) a következő helyen: Microsoft.Exchange.HttpProxy.ProxyRequestHandler.b__27();
2013-09-23T19:48:21.065Z,fd7c7b71-b0c9-4e22-80c8-8af0ca5a640f,15,0,712,12,,RpcHttp,mail.domain.hu,/rpc/rpcproxy.dll,,Basic,True,DOMAIN\teszt,,,MSRPC,46.107.179.119,EXCHANGE,404,,EndpointNotFound,RPC_IN_DATA,,,,,,,,,1073741824,,,,0,,,0,,0,,0,0,46.9634,0,,,,,,,,47,0,,48,48,48,48,?mail.domain.hu:6004,,OnBeginRequest=0;,HttpProxyException=Microsoft.Exchange.HttpProxy.HttpProxyException: Not allowed to proxy to: mail.domain.hu a következő helyen: Microsoft.Exchange.HttpProxy.RpcHttpProxyRequestHandler.ResolveAnchorMailbox() a következő helyen: Microsoft.Exchange.HttpProxy.ProxyRequestHandler.InternalBeginCalculateTargetBackEnd(AnchorMailbox& anchorMailbox) a következő helyen: Microsoft.Exchange.HttpProxy.ProxyRequestHandler.b__27();
- A hozzászóláshoz be kell jelentkezni
sub
- A hozzászóláshoz be kell jelentkezni
Sziasztok,
előjött még egy probléma, bár inkább kliens oldali, de hátha tudtok segíteni:
Adott egy terminálszerver, minden user outlook 2010-et használ, erre van felkonfigolva az összes mailbox, amit az exchange kiszolgál. A felhasználók egy része szeretné a cég egy másik domainjét is használni a levelezőben, IMAP-on, ami külső szerveren van. A levél leszedése kiválóan megy, azonban küldésnél bizonyos levelek (látszólag logika nélkül) beragadnak a kimenő sorban. Mitől lehet ez? A távoli szerveren, ahova csatlakoznak csak annyit látok a postfix logban, hogy "postfix/smtpd[50054]: lost connection after DATA (6 bytes) from domain.tld"
ui: exchange-nél amúgy azt be tudom állítani, hogy akik a belső hálón szeretnék használni, azoknak ne kelljen a proxyval szórakozni, hanem az outlook automatikusan be tudja állítani a sztenderd exchange protokollon a csatlakozást? Kizárólag belső hálóra..
köszi!
- A hozzászóláshoz be kell jelentkezni
"exchange-nél amúgy azt be tudom állítani, hogy akik a belső hálón szeretnék használni, azoknak ne kelljen a proxyval szórakozni, hanem az outlook automatikusan be tudja állítani a sztenderd exchange protokollon a csatlakozást? Kizárólag belső hálóra.."
Azoknál nem konfigurálsz proxy-t, a többi ugyanaz. That's it.
Teszteld a másik smtp kapcsolatot pl. telnettel (vagy openssl-lel, ha smtp-ssl). Valaki beleszól a kommunikációba, az biztos. Nézz tűzfal logot is.
--
PtY - www.onlinedemo.hu
- A hozzászóláshoz be kell jelentkezni
ha kiveszem a proxyt, akkor azt írja az outlook, hogy a kiszolgáló nem érhető el. Meg tudod mondani melyik logban nézelődjek, illetve milyen szolgáltatásnak kell ahhoz futni/EAC-ban beállítani, hogy így is működjön LAN-on?
én is erre jutottam, hogy a két szerver között (próbáltam másik külső szerverrel is) valami beleszólhat. Megoldottam azzal, hogy a belső exchange-en csináltam egy relay-t a terminálszervernek és ezen keresztül küldik ki a leveleket.
- A hozzászóláshoz be kell jelentkezni
Ha a kiszolgáló nem érhető el, akkor tudnod kéne, hogy mi a bajod:
névfeloldás
Feltéve, hogy az alábbi állítások, amiket eddig írtál, igazak:
- Szervernévnél a belső elérés van megadva, nem a külső (a külső csak a proxynál kell)
- A munkaállomások valóban a belső hálózaton vannak
--
PtY - www.onlinedemo.hu
- A hozzászóláshoz be kell jelentkezni
stimmel amit írtam, a kiszolgáló nevét fel is tudom oldani egy nslookup-pal, de kiszolgálónévhez beírva tényleg nem megy..
ha kiveszem a proxyt és leokézom, akkor ide visszalépve ugyanúgy be lesz írva a proxy, csak a címsorban a belső hálózatos szervernév van már.
- A hozzászóláshoz be kell jelentkezni
És az exchange-ed az a nevet fel tudja oldani?
--
PtY - www.onlinedemo.hu
- A hozzászóláshoz be kell jelentkezni
fel biza, a névszerver mindkét esetben a harmadik gép, a DC. Ahogy írtam most nem írja, hogy "a kiszolgáló nem érhető el", ha kiveszem a proxyt, egyszerűen leokézás után visszarakja a proxyt, de már az exchange belső hálózatos nevével (exchange.domain.local). Érdekes.. :)
- A hozzászóláshoz be kell jelentkezni
Ott valami nem kerek. Ha kiveszed a proxy-t nem rakhatja vissza. A kérdés, hogyan veszed ki a proxyt?
--
PtY - www.onlinedemo.hu
- A hozzászóláshoz be kell jelentkezni
A További beállítások/Kapcsolat/Kapcsolódás a Microsoft Exchange kiszolgálóhoz HTTP-n keresztül elől kiveszem a pipát, van más módja is? :)
- A hozzászóláshoz be kell jelentkezni
Nincs. Viszont nem teheti vissza. Ha mégis, ott OS szonten van problémád. Töröld az Outlook profilt, és nyiss újat.
--
PtY - www.onlinedemo.hu
- A hozzászóláshoz be kell jelentkezni
kiderült közben, hogy nincs összefüggés az SMTP szerver és a beakadt levelek között, exchange-nél is előjön annak a néhány felhasználónak. Egy részük sablon emailt használ, képekkel, ennek törlése azt hittem megoldja a problémát, de van olyan, aki nem használ sablont mégis megakadnak a levelek. Kikészít :)
- A hozzászóláshoz be kell jelentkezni
Két Exchange kérdés:
- Office Standard-ban levő Outlook valóban képtelen kezelni az Exch online archive-ot?
- Van arra lehetőség, hogy a userek contact-jait PowerShell-el igazgassam?
- A hozzászóláshoz be kell jelentkezni
Szia!
A standard 2013-as csomagban tudomásom szerint ugyan az az Outlook van, mint a pluszban.
Ha nem jelenik meg az usernél bekapcsolt in-place archive, akkor első körben jelentkezz be OWA-n. Ha ott megjelenik a felhasználónál, akkor hozz létre egy új profilt, ami újraszinkronizálja a helyi .ost fájlt is, és az autodiscover által leküldött xml-ben lévő alternativemailbox ként szereplő online archive fiók is megjelenik optimális esetben. Esetleg fel is teheted az Officehez kiadott augusztusi CU frissítést
- A hozzászóláshoz be kell jelentkezni
Jó lenne, ha ezt más is megerősítené, mielőtt nekiállok debuggolni. :)
OWA-n látszik, profilcserét próbáltam már.
- A hozzászóláshoz be kell jelentkezni
Ezt javaslom tanulmányozni: http://office.microsoft.com/en-us/buy/microsoft-office-volume-licensing…
Üdv,
Marci
- A hozzászóláshoz be kell jelentkezni
"A standard 2013-as csomagban tudomásom szerint ugyan az az Outlook van, mint a pluszban"
Más a Standard és a Pro Plus.
Üdv,
Marci
- A hozzászóláshoz be kell jelentkezni
2010-ről van szó, de gondolom ott is ez lesz felállás.
Marad a PST-k inkrementális mentése, erre valakinek ötlete?
- A hozzászóláshoz be kell jelentkezni
.
- A hozzászóláshoz be kell jelentkezni
sziasztok!
felmerült még olyan gond, hogy most teljesen random bekéri a fiókokhoz a jelszót az outlook, majd vagy elfogadja, vagy nem. Ezt akár megoldhatja az idő (akkor pár napig elő sem jön), akár egy outlook restart, de lehet, hogy 20x be kell ütni. Tudtok tippet adni merre induljak el a debuggolással?
köszi!
- A hozzászóláshoz be kell jelentkezni
Szia!
Én elsőre az AD felé keresgélnék, hiszen az végzi a hitelesítést.
- Exch2013 CU2 fent van?
- Kliensen autodiscover lefut jól?
- Új Outlook profil létrehozása után is jelentkezik a hiba?
- OWA -ba belépve nincs gond?
- Esetleg az októberi 2013 office hotfix telepítése, tesztelésre
- A hozzászóláshoz be kell jelentkezni
- CU2 fent van, igen, autodiscover nem megy, sose ment, nem tudom annak mibaja, de nem jöttem rá, ebben is örülnék tippeknek :)
- nem tudom, hogy új profil létrehozásához köthető-e, szerintem nem. Akkor jön elő, ha olyan mailboxokat is felvesz a felhasználó az outlookba, amik ilyen szervezet szintűek, pl penzugy@domain.tld. Ezt sima mailboxként kezelik, nem public folderként, agyrém :) okozhatja ez a gondot? nem tudom az exchange mennyire szereti, hogy 1 mailboxba többen belépnek outlook-kal
- owa-ban minden oké
- hotfix már fel van rakva
- A hozzászóláshoz be kell jelentkezni
Megjelent a 2013 CU3, hátha javít nálad pár dolgot.
Autodiscover beállítást AD DNS-nél kell nézni. Ha ez megy jól, akkor ha adsz hozzáférés jogot egy felhasználónak egy másik másik postafiókhoz, akkor automappinggal felcsatolja azt is az Outlook kliensbe, nem kell kézzel felvenni. Így, másodlagos postafiókként több ember is hozzáférhet egy postafiókhoz jól.
- A hozzászóláshoz be kell jelentkezni
Outlook kliens up-to-date? Én anno akkor láttam ilyet mikor nem volt fent minden patch (bár lehet, hogy windows patch volt a ludas). Bár jó rég voltam ilyen környezetben.
- A hozzászóláshoz be kell jelentkezni
up-to-date igen és mintha akkor kezdett volna jönni ez a probléma, miután végigment egy frissítés a terminálszerveren, ahonnan indítja a sok user az outlook-ot
- A hozzászóláshoz be kell jelentkezni
Én őszintén szólva minél többet tanulok Exchange-ről, annál inkább csodálkozom h. van olyan akinél minden működik flottul.
- A hozzászóláshoz be kell jelentkezni
Logokat olvasgass első körben, és ellenőrizd, hogy a rendszeridő milyen a kliens-szerver viszonylatában. Ez AD esetén szokott gond lenni.
--
PtY - www.onlinedemo.hu
- A hozzászóláshoz be kell jelentkezni
sub
- A hozzászóláshoz be kell jelentkezni
Nos nekem SBS2011 és Outlook 2010 64bites verzióval volt ugyanilyen problémám. LAN-on semmi gond, VPN-en keresztül bejelentkezve nem tud kapcsolódni. OWA megy.
Lecserélve az Outlook-ot 32-bites változatra megszűnt a probléma és minden működik megfelelően.
- A hozzászóláshoz be kell jelentkezni
Azért azt te is érzed, hogy ez nem megoldás, hanem 1 baromság...?
- A hozzászóláshoz be kell jelentkezni
Más,
Nagyon ritkán kapok olyan levelet, ahol csupán egyetlen címzettet jelenít meg az Outlook (és OWA-ban sem látszik senki rajta kívül más), holott a levélnek volt még jó pár címzettje.
Találkoztatok ilyennel?
smtp log-nál nem látok hibát:
13-12-03T16:46:46.844Z,MAILSRV\OpRelay belso halozatbol,08D0A5D74C52F5C6,17,10.31.7.101:25,10.31.7.102:52438,<,MAIL FROM: SIZE=3513,
2013-12-03T16:46:46.844Z,MAILSRV\OpRelay belso halozatbol,08D0A5D74C52F5C6,18,10.31.7.101:25,10.31.7.102:52438,*,08D0A5D74C52F5C6;2013-12-03T16:46:46.844Z;1,receiving message
2013-12-03T16:46:46.844Z,MAILSRV\OpRelay belso halozatbol,08D0A5D74C52F5C6,19,10.31.7.101:25,10.31.7.102:52438,<,RCPT TO: ORCPT=rfc822;xxxx@xxxx,
2013-12-03T16:46:46.844Z,MAILSRV\OpRelay belso halozatbol,08D0A5D74C52F5C6,20,10.31.7.101:25,10.31.7.102:52438,<,RCPT TO: ORCPT=rfc822;xxxx@xxxx,
2013-12-03T16:46:46.844Z,MAILSRV\OpRelay belso halozatbol,08D0A5D74C52F5C6,21,10.31.7.101:25,10.31.7.102:52438,<,RCPT TO: ORCPT=rfc822;xxxx@xxxx,
2013-12-03T16:46:46.844Z,MAILSRV\OpRelay belso halozatbol,08D0A5D74C52F5C6,22,10.31.7.101:25,10.31.7.102:52438,<,RCPT TO: ORCPT=rfc822;xxxx@xxxx,
2013-12-03T16:46:46.844Z,MAILSRV\OpRelay belso halozatbol,08D0A5D74C52F5C6,23,10.31.7.101:25,10.31.7.102:52438,<,RCPT TO: ORCPT=rfc822;xxxx@xxxx,
2013-12-03T16:46:46.859Z,MAILSRV\OpRelay belso halozatbol,08D0A5D74C52F5C6,24,10.31.7.101:25,10.31.7.102:52438,<,RCPT TO: ORCPT=rfc822;xxx@xxx,
2013-12-03T16:46:46.859Z,MAILSRV\OpRelay belso halozatbol,08D0A5D74C52F5C6,25,10.31.7.101:25,10.31.7.102:52438,<,DATA,
2013-12-03T16:46:46.859Z,MAILSRV\OpRelay belso halozatbol,08D0A5D74C52F5C6,26,10.31.7.101:25,10.31.7.102:52438,>,250 2.1.0 Sender OK,
2013-12-03T16:46:46.859Z,MAILSRV\OpRelay belso halozatbol,08D0A5D74C52F5C6,27,10.31.7.101:25,10.31.7.102:52438,>,250 2.1.5 Recipient OK,
2013-12-03T16:46:46.859Z,MAILSRV\OpRelay belso halozatbol,08D0A5D74C52F5C6,28,10.31.7.101:25,10.31.7.102:52438,>,250 2.1.5 Recipient OK,
2013-12-03T16:46:46.859Z,MAILSRV\OpRelay belso halozatbol,08D0A5D74C52F5C6,29,10.31.7.101:25,10.31.7.102:52438,>,250 2.1.5 Recipient OK,
2013-12-03T16:46:46.859Z,MAILSRV\OpRelay belso halozatbol,08D0A5D74C52F5C6,30,10.31.7.101:25,10.31.7.102:52438,>,250 2.1.5 Recipient OK,
2013-12-03T16:46:46.859Z,MAILSRV\OpRelay belso halozatbol,08D0A5D74C52F5C6,31,10.31.7.101:25,10.31.7.102:52438,>,250 2.1.5 Recipient OK,
2013-12-03T16:46:46.859Z,MAILSRV\OpRelay belso halozatbol,08D0A5D74C52F5C6,32,10.31.7.101:25,10.31.7.102:52438,>,250 2.1.5 Recipient OK,
2013-12-03T16:46:46.859Z,MAILSRV\OpRelay belso halozatbol,08D0A5D74C52F5C6,33,10.31.7.101:25,10.31.7.102:52438,>,354 Start mail input; end with .,
2013-12-03T16:46:48.984Z,MAILSRV\OpRelay belso halozatbol,08D0A5D74C52F5C6,34,10.31.7.101:25,10.31.7.102:52438,*,Tarpit for '0.00:00:02.250' due to 'DelayedAck',Delivered
2013-12-03T16:46:48.984Z,MAILSRV\OpRelay belso halozatbol,08D0A5D74C52F5C6,35,10.31.7.101:25,10.31.7.102:52438,>,250 2.6.0 [InternalId=5633236] Queued mail for delivery,
2013-12-03T16:46:48.984Z,MAILSRV\OpRelay belso halozatbol,08D0A5D74C52F5C6,36,10.31.7.101:25,10.31.7.102:52438,<,QUIT,
2013-12-03T16:46:48.984Z,MAILSRV\OpRelay belso halozatbol,08D0A5D74C52F5C6,37,10.31.7.101:25,10.31.7.102:52438,>,221 2.0.0 Service closing transmission channel,
2013-12-03T16:46:48.984Z,MAILSRV\OpRelay belso halozatbol,08D0A5D74C52F5C6,38,10.31.7.101:25,10.31.7.102:52438,-,,Local
2013-12-03T16:48:09.454Z,MAILSRV\OpRelay belso halozatbol,08D0A5D74C52F5D5,0,10.31.7.101:25,10.31.7.102:52441,+,,
2013-12-03T16:48:09.454Z,MAILSRV\OpRelay belso halozatbol,08D0A5D74C52F5D5,1,10.31.7.101:25,10.31.7.102:52441,*,None,Set Session Permissions
2013-12-03T16:48:09.454Z,MAILSRV\OpRelay belso halozatbol,08D0A5D74C52F5D5,2,10.31.7.101:25,10.31.7.102:52441,*,SMTPSubmit SMTPAcceptAnyRecipient SMTPAcceptAuthenticationFlag SMTPAcceptAnySender SMTPAcceptAuthoritativeDomainSender BypassAntiSpam BypassMessageSizeLimit SMTPAcceptEXCH50 AcceptRoutingHeaders,Set Session Permissions
2013-12-03T16:48:09.454Z,MAILSRV\OpRelay belso halozatbol,08D0A5D74C52F5D5,3,10.31.7.101:25,10.31.7.102:52441,>,"220 mailsrv.wtehu.local Microsoft ESMTP MAIL Service ready at Tue, 3 Dec 2013 17:48:08 +0100",
2013-12-03T16:48:09.454Z,MAILSRV\OpRelay belso halozatbol,08D0A5D74C52F5D5,4,10.31.7.101:25,10.31.7.102:52441,<,EHLO mailguard.wtehu.local,
- A hozzászóláshoz be kell jelentkezni