- One mobilszolgáltatások
- Milyen okostelefont vegyek?
- Amazfit Active 2 NFC - jó kör
- Fotók, videók mobillal
- Samsung Galaxy A36 5G - a középső testvér
- Samsung Galaxy Watch4 és Watch4 Classic - próbawearzió
- Apple iPhone 15 - a bevált módszer
- Android alkalmazások - szoftver kibeszélő topik
- Három Pixel 9 jött Magyarországra
- Xiaomi Mi 11 Ultra - Circus Maximus
Új hozzászólás Aktív témák
-
brd
nagyúr
válasz
jaszy91
#1358
üzenetére
Ha a DNS kezelőben nem találsz SPF néven futó rekordtípust, akkor TXT-t vegyél fel. Először próbáld meg a levelezőserver IP-jét hozzáadni jól, aztán próbálkozhatsz finomabb beállítással. Pl. valahogyan így kell kinéznie: IN TXT "v=spf1 ip4:15.15.15.15/32 -all" Ezzel azt mondod meg, hogy a 15.15.15.15-ös IP jogosult levelet küldeni az adott domain-nel végződő címekről. Az SPF hiánya egyébként nem minősül hibának, emiatt levelet nem igazán szoktak elutasítani. A logban milyen hibaüzenetet találsz, mit ír vissza a túloldali server?
-
brd
nagyúr
válasz
ielektros
#1347
üzenetére
Az e-mail fogadáshoz kell ugye egy ún. MX record, ezt a domain DNS opciói között lehet beállítani, de ez egy IP-re kell mutasson (pontosabban ma már az a javasolt, hogy egy "A" recordra, és az egy IP-re). Az a probléma, hogy ennek van egy ún. TTL-je, ennyi ideig van cache-elve más DNS servereken, így egy külső gép, ami levelet akar küldeni a te domain-edre, az lekérdezi az MX recordjait (és az aldomain "A" recordját) a domainnek, és megkapja a cache-elt változatot, ami legfeljebb egy TTL-nyivel régebbi információ lesz (ha közben változik az IP, akkor ugye ez rossz helyre fog mutatni). Ez a TTL ma olyan 1-4 óra szokott lenni, és a DNS server kezelője határozza meg. Ezt az "A" record kellene frissítgetni valahogyan, amikor változik a külső IP. Ha olyan a domain-ed, akkor ezt automatikussá is lehet tenni (pl. dyndns, vagy no-ip.org, náluk ráadásul a TTL is lehet valami fél perc, ha jól emlékszem). Így nagyjából működni fog, csak IP váltáskor lesz egy kis TTL időtartam körüli kiesés, ill. ha a régi IP-t valami más által üzemeltetett mailserver kapja meg (vagy olyan szolgáltatás, ami elhajtja a küldő servert a megfelelő hibával), akkor egyes levelek vissza is pattanhatnak.
-
brd
nagyúr
válasz
ielektros
#1345
üzenetére
A havonta az már használható, ha együtt tudtok élni a minimum TTL-nyi idejű levélfogadás-kieséssel (addig van ugye cache-elve, és ehhez még hozzájön az IP váltás, és a DNS bejegyzés átállítása közötti idő). Akkor sem lesz új IP, ha újracsatlakozik az eszköz?
Hogy milyen megoldást? Fix IP-t kell rendelni.
-
brd
nagyúr
válasz
ielektros
#1343
üzenetére
Nagyon ne küzdj vele, dinamikus IP-n nem fogsz mail servert üzemeltetni, legalábbis olyat, ami fogadni is kell tudjon tetszőleges időben. (Pontosabban lehet, de ahhoz olyan DNS szolgáltatás kell, ami egyrészt rövid időn belül automatikusan - a változott IP hatására - át tudja állítani a hostot, másrészt az MX-bejegyzés TTL-je megfelelően rövid is lehet, de még ekkor sem lesz teljesen problémamentes.)
-
brd
nagyúr
válasz
deminos
#1298
üzenetére
A SMTP Virtual Serveren nézd meg, hogy nincs-e véletlenül a Windows Integrated authentikáció bekapcsolva, mert az okozhat ilyen hibát (nyilván csak ott kapcsold ki, ahol nincsen rá szükség): properties/delivery tab/outbound security és ott windows integrated; vagy ugyanez esetleg a Connectoron: properties/advanced tab/outbound security.
-
brd
nagyúr
válasz
desolator
#1272
üzenetére
Igen, mert nem fut le az Exchange adatbázis mentése sikeresen. Csak akkor törlődnek a logok. Vagy esetleg beállíthatsz körkörös logolást (circular logging), akkor nem eszi meg a helyet, de azt inkább ne, ha ilyen gondok vannak, hogy nem ismeri fel a felelős, hogy hibás a mentés (vagy nincs is felelőse...?), mert talán jó mentés még soha sem készült, vagy nincs már meg. A logolásnak egyébként az az értelme, hogy ha megsérül az adatbázis, akkor az utolsó jó(!) mentés, és a tranzakciós logok segítségével vissza lehet állítani a mentés, és a sérülés közötti tartalmat is.
-
brd
nagyúr
A management process (online defrag) le tud futni? Nincs az időzítése idejére valami másik folyamat időzítve, pl. indexelés, vagy backup? Mert akkor szemérmesen háttérbe vonul, és esetleg emiatt sosem tud lefutni.
Ill. nem az a helyzet, hogy be van állítva, permanensen ne törlődjenek az elemek az adatbázis mentéséig, és mentés meg nincs, így sosem törlődnek? -
brd
nagyúr
Az internetszolgáltatót kell megkérni, hogy adjon ilyet. De valószínűleg van most is. Mindenesetre, ha majd lesz (vagy már most is van) Reverse DNS (pl. itt is meg tudod nézni, ha a parancssor annyira nem a haverod
), akkor ezt ajánlom olvasásra. A megoldás az lett, hogy a *.invitel.hu és *.invitel.net domainekhez készítettem egy Send Connectort, ez a mail.invitel.net smart hoston keresztül küldi a leveleket, a szolgáltató által megadott credentials használatával. -
brd
nagyúr
válasz
kraftxld
#604
üzenetére
A messageSizeLimit-re gondolsz? (Bár az alapból nincs beállítva, azonkívül erről a beállításról leírás sem nagyon van szerintem - az RGC vonatkozásában legalábbis -, mert van másik, a grafikus felületre is kivezetett méretkorlát-beállítási lehetőség a connectorokon, és inkább azt javasolják, így nem valószínű, hogy ott lenne beállítva.) -
#603
brd
nagyúr
macimeister
#602
brd
nagyúr
válasz
macimeister
#602
üzenetére
Csak az adott felhasználónál, vagy mindenkinél? Felhasználó, vagy public folder? Az ADUC-ban Properties a felhasználón, Exchange Feautres. Public Folder esetén magán a Public Folder Store-on is be tudsz ilyet állítani, ill. külön folderenként is. De lehet még a Connectorokon és a SMTP Virtual Servereken is méretkorlátot beállítani, továbbá az ESM-ben a Global Settings alatt is van méretkorlátozási beállítás. Ha jól emlékszem, máshol nincs.
-
brd
nagyúr
Elolvastad rendesen a hozzászólást?
Nem jó, én nem szeretem, hogy kell smart host, nem akarom, hogy egy másik gárda hozzáértésétől függjön a levelezés, de bizonyos helyekre (eddig konkrétan egyet találtam a jelen eset vonatkozásában) egy adott módon lehet csak levelet küldeni.
Hogy minek? Ott a példa.#599: Az Exchange kifelé NAT-olva jut ki, szal' a címe biztos nem okoz gondot, a külső IP-hez pedig van PTR. Vagy arra gondolsz, hogy az első Received sorban van belső hálós IP/gépnév?
-
brd
nagyúr
válasz
kraftxld
#596
üzenetére
Igen, a legtöbb (pontosabban eddig mindenhová) helyre itt is, viszont ha *@invitel.hu címre küldetnék így (DNS/MX alapján) levelet, akkor azt írja a serverük, hogy:
z.mx.invitel.net #554 5.7.1 <x.x.x.x.static.invitel.hu[x.x.x.x]>: Client host rejected: You have mass IP pool like reverse in DNS, fix it or use smtp relay from your provider. ##
(Mint látszik, fix IP van.)
Erre a szolgáltató azt mondta, hogy állítsam be smart hostnak a mail.invitel.hu-t, mert csak úgy engedélyezik a küldést. A vége az lesz, hogy az invitel.hu-hoz gyártok egy külön send connectort, látom már... -
-
brd
nagyúr
válasz
kraftxld
#590
üzenetére
Utóbbi, de aztán rájöttem, hogy SBS, és inkább visszaállítottam a kiindulási állapotot, mielőtt magába zuhan, és később majd szívhatok vele
(most az SBS konzolban minden ződ', és a smart hostot is ott állítottam aztán be). A send connector, ill. a transportserver beállításai között mindenesetre nem találtam erre vonatkozó opciót (EMS-ben sem), tehát még ha baj is lett volna a nekiesés, akkor sem látom, hol lehetne rosszul beállítani. -
brd
nagyúr
Valakinek van ötlete, hogy hogyan lehet lebeszélni a 2007-es Ex' HTS-ét arról (nincs Edge, és súlyosbító körülmény, hogy SBS), hogy ha smart host-on keresztül kellene tolnia kifelé a leveleket, akkor ott már ne próbálkozzon MX lekérdezéssel? Simán be kellene telnetelnie a smart hostra, ehelyett lekérdezi a smart host MX rekordját, és oda akar kapcsolódni.
WTF? Vajon mit szívhatnak az Ex'-es fiúk? Kérnék én is belőle asszem'. (Persze ha a smart host IP-jét írom be az FQDN helyett, akkor megfelelően működik, csak így ha változik az IP, akkor lehet átírni...). Esetleg valami speciális formában kell beírni az FQDN-t? Mondjuk B@m@g%#mail.isp.net#%@, amit sehol sem írnak le?
A másik kérdésem az lenne, hogy ennek a viselkedésnek mi értelme?
Vagy ez egy oltári nagy bug lehet? -
brd
nagyúr
Ilyenkor általában az szokott lenni a probléma, hogy egy olyan felhasználóval próbálja a kliens, amelynek egyébként van joga elérni a könyvtárat, de a helyi gépen más a jelszava, mint a megosztóoldalon. Pl. mindkét oldalon van rendszergazda, de más jelszóval. Ilyenkor nem kér felhasználónevet, mert azt látja, hogy a helyi gépen is van ilyen, viszont azt már nem tudja feldolgozni, hogy más a jelszava, és ezért azt írja, hogy nincs joga. Ez a megosztóoldalon, az eseménynaplóból (Biztonság/Security) kiderül, ha logoltatod a sikertelen bejelentkezéseket.
Egyébként ez a kérdés mit keres az Exchange topicban? -
brd
nagyúr
Ha magyar SBS-ről van szó, akkor elsőként arra hívnám fel a figyelmed, hogy egy registry kulccsal bajod lesz (valamilyen javítócsomag verzió rémlik, hogy azt nem fogja találni), ezt mindenképpen kézzel kell majd módosítani (létrehozni), mert nem tudsz továbblépni (azóta lehet, hogy javították az újabb 2008-ban). Ha jól emlékszem, ezzel kapcsolatban a SBS Best Practice Analyzer is, és a migrálóvarázsló is pontosan kiírja, hogy mi a baja. Egyebekben a SBS_Migration.doc teljesen jól használható. Ha Premium volt a 2003-as SBS, akkor azt is tudnod kell, hogy az SQL szolgáltatást is neked kell áthekkelni (ez sem túl bonyolult egyébként), figyelembe véve, hogy a Server 2008-cal egy időben 2008-as SQL-re kell átállni (a 2005 csak átmeneti megoldás, a kompatibilitás miatt került csak bele, mint lehetőség). No' és persze ISA sem lesz a 2008-ban. Az Exchange-es részéhez nem tudok hozzászólni, sosem használtak ott ilyen levelezést, ahol ilyen migrálást csináltam, de nem hiszem, hogy más lenne, mint domain-en belül, 2 server között, egy nem SBS-es Exchange migrálás; erre pedig pl. ezt a sorozatot olvasgathatod.
Hmm... mi van még, ami gond lehet...? Talán a filemegosztások. Mivel a server neve, és IP-címe kötelezően meg kell változzon, ezért ha nem DFS segítségével voltak megosztva a cuccok, akkor ezt is át kell valahogyan írogatni a klienseken, ez biztos egyértelmű, csak mondom, hogy oda kell rá figyelni, mert ez is idő.
A 21 nap egyébként nem kevés szerintem. Gyakorlatilag csak hétvégén tudtam több helyen ilyennel foglalkozni (hétköznap dolgoztak), de max. 3 hétvégéből (az meg ugye 16 nap, és ha nagy baj van, még mindig van 5 napod) mindig letudtam, de többnyire inkább 2 volt, ez is csak a sok adat, vagy a nagy SQL adatbázis miatt (meg hogy ugye vasárnap este úgy kellett otthagynom, hogy lehessen ugyanúgy dolgozni a rendszerrel, mint előtte), tehát lényegében a 2. nap végére már az új server-ről működött szinte az összes szolgáltatás, úgy, hogy a 2008 telepítését is helyben csináltam, beadagolva neki a válaszfile-t. Persze ez elsőre nem biztos, hogy ilyen simán fog menni, inkább azt mondanám, hogy 3-4 nap lesz, ha nem dolgoznának vele közben.
A legfontosabb: mielőtt bármit csinálsz, mentsd le a 2003-at (legalább egy System State, de inkább teljes backup), mert ha elindítottad a varázslást, nincs visszaút, csak ha backup-ból teszed vissza a 2003-at (le fog álldogálni a 2003, a 21 nap elteltével). -
-
brd
nagyúr
válasz
Panthera
#211
üzenetére
Igen, ha az Exchange-en be van állítva az IMAP elérés rendesen, akkor bármilyen, IMAP-képes levelezővel tudod használni, eléred az összes mappát, de az összes elem is sima levélnek fog látszódni (amiket írtam példát, tulajdonképpen az összes, csoportmunka/Outlook-specifikus elem), de levelezni lehet vele. Bár az Outlook Express IMAP-kezelésétől nem vagyok elájulva, kissé nyögvenyelős. Mindenesetre működik.
-
brd
nagyúr
válasz
kraftxld
#207
üzenetére
Azért IMAP-képes levelező használatával is működik (legyen ez akár Outlook Express), persze bizonyos dolgokról le kell mondani, ami Outlookspecifikus, pl. Naptár, találkozók szervezése, Feladatok, továbbá a címlista sem lesz elérhető (mondjuk az AD-ből lehet keresni címzettet). De a sima levelezésre teljesen jól működik, ha nagyon nincs Outlook.
-
brd
nagyúr
válasz
Panthera
#202
üzenetére
Nem. Ill. igen, mert maga az Exchange az AD-re/be épül rá/be, de szerintem te azt akarod tudni, hogy a gépnek, ahonnan bejelentkezel az Exchange-re, annak kell-e domainben lennie.
Vagy arra gondolsz, hogy másik domainben létező felhasználónak akarsz postafiókot csinálni? -
brd
nagyúr
-
brd
nagyúr
Köszi, de én is ezt linkeltem.
Az ESE buffer a max. javasoltra van állítva a doksi alapján. Az SQL sosem evett még 100 MB-nál többet, még virtuális címet sem foglalt annyit (de mivel Standard, amúgy is max. 2 GB-ot tudna, tehát a 3 GB fizikai RAM-ból még akkor is maradna az Exchange-nek, ha mindet elfoglalná). Mindenesetre leállítom 1-2 napra az SQL-t, hátha, de nem hiszem, hogy számítana. -
brd
nagyúr
Van egy fura gondom egy Ex2003-mal: nem igazán hajlandó több memóriát lefoglalni, mint kb. 600 MB (a store.exe). A win az 2003 Standard (SP2), az Ex az Enterprise (szintén SP2), 3 GB memória van a gépben, és ez a DC is egyben. A boot.ini-ben be van állítva a /3gb kapcsoló (mellé egy /userva=3000 is, a biztonság kedvéért), és életbe is lépett, a testlimit.exe kb. 2980 MB-nyi virtuális címet tud lefoglalni. Az Ex-et kb. 25 user használja, ebből 2-3-nak több GB-os postafiókja van, a teljes adatbázisok mérete kb. 57 GB (34 GB Mailbox, 23 GB Public). A HeapDeCommitFreeBlockThreshold és a msExchESEParamCacheSizeMax értékei a M$ ajánlásai alapján van beállítva. Ami talán lényeges lehet: fut még egy kisebb SQL (SQL 2000 Standard) adatbázis is a serveren, de alig van használva, talán ha 40-50 MB-ot eszik az sqlserv.exe; ill. itt fut a SPAM-filter is (ASSP; a perl.exe kb. 80-90 MB-ot foglal). A taskmanager szerint az össz' foglalt memória kb. 1.5 GB, és a system cache kb. 1.5 GB-nál jár.
Ez utóbbit (egy tetemes részét legalábbis) szeretném, ha az Ex zabálná meg. A server kb. 1 hete fut (a store.exe is), próbálgattam nagyobb public mappákba bemászkálni, a nagyobb leveleket nyitogatni, de így is max. 600 MB-ot hajlandó lefoglalni. Van valakinek ötlete, hogy mit lehetne még tenni? -
brd
nagyúr
A t-online mail serverén keresztül csak authentikációval tudsz küldeni. Saját maga a servered talán azért nem tud küldeni, mert a 25-ös port forgalmát a t-online tiltja. Ha így van, külön lehet kérni, hogy engedélyezzék. A microsoft.com mail exchanger-e pedig nem az általad próbált címen figyel, hanem az alábbi paranccsal tudod lekérdezni:
nslookup -querytype=mx microsoft.com
Persze a kapott cím, a mai trendeknek megfelelően csak akkor válaszol a 25-ös porton, ha a cím, ahonnan próbálod, maga is rendelkezik megfelelő mx record-dal (és/vagy nincs benne egy bizonyos adatbázisban, vagy épp az, ha benne van, ez most részletkérdés ); ez egyúttal egy tesztnek is megfelel. -
brd
nagyúr
Üdv. néktek' szakik!
A felállás: Exchange 2003 Ent. SP2, ASSP spamfilter, méretkorlát az internet-szolgáltató mailserverén.
Az ASSP tanítása ugye úgy működik, hogy egy bizonyos e-mail címre kell továbbítani a spam-nek minősülő, ill. egy másikra a spam-nek minősített, de nem spam e-mail-t. Emiatt az Exchange-ben smart host-nak az ASSP van beállítva, amelyben pedig smart host-nak az internet-szolgáltató mailservere. Ez így eddig remekül működött, azonban az internet-szolgáltató úgy gondolta, hogy 5 MB-nál nagyobb e-mail-t nem lehet a továbbiakban küldeni. Ezért szeretném azt megoldani, hogy az Exchange maga küldje a leveleket szerte a világba. Ha ugye simán átállítom, hogy ne az ASSP-re állított smart host-on keresztül küldje, akkor az ASSP-t nem lehet tanítani; az ASSP pedig nem képes maga, DNS alapján route-olva küldeni a leveleket (legalábbis, nem találtam benne ilyen beállítást).
Tehát valami olyan megoldás kellene, hogy az ASSP visszaküldje az Exchange-nek a kiküldött leveleket, ami aztán továbbnyomja. Lehet ilyet? Hogyan?
), akkor 
WTF? Vajon mit szívhatnak az Ex'-es fiúk? Kérnék én is belőle asszem'. (Persze ha a smart host IP-jét írom be az FQDN helyett, akkor megfelelően működik, csak így ha változik az IP, akkor lehet átírni...). Esetleg valami speciális formában kell beírni az FQDN-t? Mondjuk B@m@g%#mail.isp.net#%@, amit sehol sem írnak le?
Vagy ez egy oltári nagy bug lehet?
Úgy tűnik, többnyire kevésnek ítéli a terhelést az Exchange normál üzemben. Egyszerűen ilyen kis takarékos a memóriával. Új hozzászólás Aktív témák
Hirdetés
- Bambu Lab 3D nyomtatók
- LEGO klub
- NTFS, exFAT, FAT32 – Melyiket válaszd és miért?
- Kodi és kiegészítői magyar nyelvű online tartalmakhoz (Linux, Windows)
- Milyen légkondit a lakásba?
- Autós topik
- World of Tanks - MMO
- Több évig húzódó per várhat az Apple-re az iPhone-ok uralma miatt
- A fociról könnyedén, egy baráti társaságban
- E-roller topik
- További aktív témák...
- 27%-OS ÁFÁS SZÁMLA I Jogtiszta Microsoft digitális és fizikai termékek I DIGITALKEYZ.COM
- Windows 10 11 Pro Office 19 21 Pro Plus Retail kulcs 1 PC Mac AKCIÓ! Automatikus 0-24
- Bitdefender Total Security 3év/3eszköz! - Tökéletes védelem, Most kedvező áron!
- Windows 10/11 Home/Pro , Office 2024 kulcsok
- Eladó steam/ubisoft/EA/stb. kulcsok Bank/Revolut/Wise (EUR, USD, crypto OK)
- ÁRGARANCIA! Épített KomPhone i5 14400F 32/64GB RAM RTX 5060Ti 8GB GAMER PC termékbeszámítással
- ÁRGARANCIA!Épített KomPhone Ryzen 7 5800X 32/64GB RAM RX 7800 XT 16GB GAMER PC termékbeszámítással
- AKCIÓ! Gigabyte AORUS 16X (2024) Gamer notebook - i7 14650HX 16GB RAM 1TB SSD RTX 4070 8GBWin11
- BESZÁMÍTÁS! ASUS VivoBook X1504ZA notebook - i3 1215U 16GB DDR4 RAM 512GB SSD Intel UHD IGP WIN11
- Csere-Beszámítás! Custom vizes számítógép játékra! I7 12700KF / RTX 3090 / 32GB DDR5 / 1TB SSD
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft
Város: Budapest
Cég: Promenade Publishing House Kft.
Város: Budapest