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

Hello.

negyedéves gyakorisággal húzom le a mailboxom teljes tartalmát ,hogy utána magamnál tároljam.

Eddig,

Thunderbird -öt használtam aminek a profilját betömörítettem. Ami 2-4 mailbox-ot lefed.

Gmail - Takeout megoldva.

Tudtok valami könnyebb megoldást, gyorsabbat esetleg more secure? Max 2,5K HUF-ig játszanak a payd appok! :)

Nagyon köszönöm!

Sziasztok,

Elkezdtem használni az nginxproxymanager-t. Előtte egy vm-re telepített nginx-t használtam reverse proxynak, gond nélkül ment évekig.
Most ez a proxy manager azt csinálja, hogy a win-es laptopomon, a 20 proxyzott oldalból 2-3 elkezd chrombe-ba, és edge-be random timeoutolni. Internet Explorer és iOS megnyitja gond nélkül, mással nem próbáltam. Ha elkezd egy oldal timeoutolni, csak a laptop restartja segít. Próbáltam a böngésző kiegészítőket tiltani, flushdns, előzmények törlése, konténer restart stb. , de semmi sem segített.  
 

Szerintetek merre keressem a hibát?

Van egy intranetes szerver, aminek a hosztnevét a belső DNS kiszolgálók teljesértékűen feloldják, ebben a formában:

# dig +noall +answer hostname.domainname.intranet
hostname.domainname.intranet.    3600    IN    A    172.23.24.25

Korábban, ha beírtam egy webböngészőbe, hogy hostname.domainname.intranet, akkor a böngésző annak rendje és módja szerint megjelenítette a http://hostname.domainname.intranet/ címet.

Az újabb Firefox verziók azonban felteszik azt a kérdést, hogy:

"Did you mean to go to http://hostname.domainname.intranet/?" - és van egy "Yes, take me to hostname.domainname.intranet/" feliratú gomb, valamint egy "No thanks". A böngésző alapból a "No thanks" opciót csinálja, jelen esetben rákeres a címsorba beírt hosztnévre az alapértelmezett keresővel.

A Chrome szintén zenész, de az nem kérdez semmit, csak keres.

Magyarul: a korábbihoz hasonló működés érdekében, mindig be kell írni a címsorba a http:// vagy https:// előtagot.

Hogyan lehet ettől az újdonságtól megszabadulni?

[UPDATE]

Látszólag az újabb böngészők a public suffix list-en nem szereplő domainek esetében alapból keresést végeznek. A feature közvetlenül nem kapcsolható ki, de többféleképpen módosítható a viselkedése. Az egyedi domain (suffix) whitelist-elhető, vagy akár teljesen ki is lehet kapcsolni a címsorból való keresést, ha nem szükséges.

[UPDATE 2]

• a címsorban a hosztnevet ponttal terminálva jó,
• a címsor végére / jelet írva (azaz: a címet formailag kicsit jobban URL-szerűvé alakítva) szintén jó.

Alkalmazkodunk! Megszoksz vagy megszöksz...

Sziasztok! Tranzakciós emailek kiküldésére használjuk kb. másfél éve a mailjet.com hírlevélküldőt, ami eddig kiválóan működött.

Az utóbbi 1-2 hónapban elkezdte "soft-bounced"-ként megjelölni és több napos késéssel kézbesíteni bizonyos címekre (általában ugyanazokra) a leveleket, ami pl. egy regisztráció megerősítésénél így használhatatlan. Mivel cégünk office365-öt használ levelezésre, ezért állíthatom, hogy 99,9%-ban a Microsoftos office365 címekkel van gondja. Olyan, mintha a Microsoft nem akarná befogadni ezeket a levelet. Olyan is előfordult már, hogy ugyanazt a tranzakciós emailt kiküldve 3 egyazon cégen belüli címre csak az egyik fiók kapja meg. Ráadásul mindig ugyanaz az egy. Kb. 20-30 ilyen belsős esetünk volt már az elmúlt 2 hónapban. (kifelé nem tudjuk pontosan, hogy melyik cím Microsoftos) Előtte az 5000-6000/hó levél 0,7%-a esett ebbe a kategóriába, ami szerintem természetes. Most ez 2,2%, ami már sok.

Írtunk az ügyfélszolgálatnak, de 1 hét az átfutási idejük. És semmi érdemi dolgot nem tudtunk meg. Mire válaszoltak megjavult, de most 3-4 napja megint probléma van. SPF és DKIM jól van beállítva. A Microsoft admin oldalon semmi rendelleneset nem látni. Egyszerűen nem érkezik be, és nyomát se látni annak, hogy valamit akart-e egyáltalán kezdeni vele a Microsoft.

Használ-e itt valaki mailjetet? Tapasztalt-e ilyen problémát?

Egy webszerveren, ahol nincs más e-mail forgalom, csak a weboldalak által kiküldött levelek, ti hány naposra hagyjátok a queue-t?

Szívem szerint minimalizálnám a queue méretét, de azt mégsem tehetem meg, hogy ha valaki regisztrál valahova egy beteg e-mail címmel, és a regisztrációs levelét nem fogadja azonnal a fiók, akkor eldobjam. Tehát valameddig illik hagynom próbálkozni, de az egy hetet azért itt kicsit túlzónak érzem.

Gyakorlati tapasztalataitok szerint mi lehet a jó érték?

Valóban jó döntés volt a WebAssembly mellett letenni a garast? Bár már bő egy éves a cikk de jelentős változás azóta sincs. 

https://www.pdftron.com/blog/wasm/wasm-vs-pnacl/

Alapvetően az a problémám az insync toollal, hogy ha egy támadó kontrollt szerez a gdrive oldalon, ami ugyan kicsi valószínűségű de nem lehetetlen esemény, onnantól simán törölgethet a helyi PC-men. Hiába védi EncFs az adatokat felhő oldalon, értelmezni ugyan nem tudja a támadó az felhőbe szinkronizált adatokat, de letörölni igen. A jó insync pedig ekkor töröl lokálisan is. 

Amennyiben csak read only hozzáférése van lokálisan az insync-nek az szinkronizált könyvtárszerkezethez, akkor mi történik ha gdrive oldalon törölnek valamit, amit nem tud lokálisan szinkronizálni? Teljesen elszáll az egész, vagy ír egy warningot és működik rendben tovább az insync? 
Valaki próbált már ilyen beállításokat használni? 

Vodafone | Új e-számlád érkezett

Vodafone <e-szamla@vodafone.hu> to me Be careful with this message Gmail could not verify that it actually came from vodafone.hu. Avoid clicking links, downloading attachments, or replying with personal information. Report spamReport phishing

Na most tényleg ennyire lámer az Vodafone, vagy ez tényleg egy új spam hullám? 

Kockázat lehet benne, mert van egy link a fizetési oldalra, ami simán lehet mockolt kártyafizetőhely. 

Sziasztok!

Ábrákkal díszített, alapvetően mp3 alapú tananyagokat készítünk, irtózatos mennyiségben.
Szeretnénk, ha a keresők látnák, hogy mennyi minden cuki dolgunk van. Ehhez a HUP-os kollégák segítségével kiválasztottunk egy olyan szolgáltatást, ami elég jó minőségben leiratot készít a tananyagok mp3 fájljaiból.

A kérdés most az, hogy hogyan érdemes ezt a tartalmat elérhetővé tenni a keresők számára. Az ötleteink az alábbiak:

• Odatesszük a (JS által lejátszott mp3 és tartalmi elemeket is tartalmazó) tananyag alá a leiratot, és ebből a kereső tudni fogja, hogy mi ez
• Vagy mivel a fenti megoldás ronda, és a felhasználó úgysem olvassa ezt a szöveget, inkább belinkelve egy-egy külön oldalra tesszük
• Vagy külön oldalon HTML <audio> tagbe betesszük a hangot, hogy biztosan lássa és tudja értelmezni a crawler (csinál ilyet vajon?), alá pedig a leiratot.

Hirtelen több ötletem nincs. Mit gondoltok erről?

https://support.google.com/drive/answer/2375102

Ez gondolom senkinek nem bréking nyúz. Inkább az okok érdekelnének. Eddig lehetett tudni, hogy a Google előnyéhez a versenytársakkal szemben hozzájárult a saját fejlesztésű és soha senkinek ki nem adott GoogleFS. (ennyit a GPL kódot mindenkinek oda kell adni mítoszról :) Ennek a fájlrendszernek a lényege, hogy nem lehet rajta törölni a fájlokat. Meg lehet ugyan jelölni egy fájlt, hogy azt tekintse a rendszer töröltnek, de valójában ugyanúgy ott van, semmilyen más adat nem kerül a helyére. Ennek a nyilvánvaló előnye, hogy így nincs fregmentáció. Meg rossz nyelvek szerint az NSA is szereti. 

Ezért természetesen a gdrive kukája így lehetett "szimbolikus jellegű" ahol lényegében ugyanúgy megmaradnak a fájlok mint egy másik mappában, mivel az alatta levő GoogleFs miatt úgysem lett volna több szabad hely a felhőben akkor sem, ha valami automatikus eljárás törli az ottani állományokat. Most viszont ez megváltozott. 

Ennek oka lehet az, ha például a Google elkezdte SSD-re cserélni a merevlemezeket az adatközpontjaiban, amiken már okafogyott a GoogleFs használata, ott már lehet törölgetni és újra írni merevlemezeket lassívó fregmentációs következmény nélkül, bár wear leveling-ra még akár jótékony hatású is lehetne. Vagy egyszerűen csak találtak valami megoldást a törlésre, például a teljes merevlemeztartalmak új merevlemezekre másolásával, ahonnan már kimaradnak a törléssel megjelölt fájlok. 

Belső ügyeivel eléggé titokzatos Google indokairól a kuka mappával kapcsolatban tud valaki kiszivárgott infót?