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

Szeretnék egy web-böngészőt az alábbi paraméterekkel:

- Windowsra kellene :-/
- nem túrja a registry-t
- nem valamilyen skin a FF/IE/akármi elé hanem önálló böngésző
- több könyvtárból is el lehessen indítani, és a futó browser processeknek az égvilágon semmi közük se legyen egymáshoz
- ha készít is profilokat (pl. hogy tárolja a könyvjelzőket, beállításokat, cookie-kat valahol stb.) akkor ezek ne keveredjenek egymással

Végeredményben olyan böngészőt szeretnék ami több példányban elindítható és ezek a példányok semmilyen szinten ne is tudjanak egymásról.

Amiket próbáltam:
- sf.net túrása (a PornoBrowser, Pyjamas, Libretto, Duck Web Browser gyönyörűségeknél feladtam)
- Firefox portable (a példányok összeakadnak, amit az egyiken beállítok azt átveszi a másik)
- Dillo (nagyon nem stabil a Windows verzió)
- Amaya (sajnos egyáltalán nem jeleníti meg az adott oldalt)
- Flock (ez volt a legígéretesebb, de a beállítások itt is megjelennek a más könyvtárból indított böngészőben)

Szóval valami olyasmit szeretnék mint anno a DOS-os időkben volt, felmásolod és használod, ahány könyvtárban van az annyi külön program, minden tekintetben elszeparálva a többitől.

Üdv!

Kérdésem arra vonatkozik, hogy mely "restriction" -ra ad a postfix ilyen
választ?
Az a gond, hogy a saját hálózaton belülről (mynetworks) küldenének olyan
levelet, melynél a sender (küldő) nem a saját, általunk kezelt domain -ből
való.
Azt szeretném, hogy az ügyfél levele minél több smtpd_xxxx_restriction
ellenőrzésén menjen keresztül, mielőtt a permit_mynetwork -höz ér.

Jelenleg ez a sorrend:

smtpd_helo_restrictions =
smtpd_sender_restrictions =
smtpd_client_restrictions =
smtpd_recipient_restrictions =
check_sender_access hash:/etc/postfix/access_sender,
reject_invalid_helo_hostname,
reject_unknown_helo_hostname,
reject_non_fqdn_helo_hostname,
# warn_if_reject
reject_unauth_pipelining,
reject_unauth_destination,
reject_non_fqdn_recipient,
reject_unknown_recipient_domain,
permit_mynetworks,
reject_non_fqdn_sender,
reject_unknown_client_hostname,
reject_unknown_sender_domain,
reject_unverified_sender,
check_client_access hash:/etc/postfix/access_client,
check_recipient_access hash:/etc/postfix/access_recipient,

smtpd_data_restrictions =
smtpd_end_of_data_restrictions =
reject_multi_recipient_bounce,
permit

Ezek a paraméterek még, ami fontos lehet:

strict_rfc821_envelopes = yes
smtpd_delay_reject = yes
smtpd_helo_required = yes

Probaltam google-zni, de meg ide a targyat megfogalmazni sem tudtam teljesen jol:-)

Szituacio: felhasznalok idonkent adott levelet tobb cimzettnek akarjak kikuldeni (nem spam, a cimzettek a munkatarsak kisebb csoportja, akik valamilyen logika szerint egy csoportba tartoznak). Squirrelben siman megoldhato, hogy felvesz az address bookba egy uj elemet, az email mezobe pedig vesszovel elvalasztva beirja az adott par email cimet, igy ha kivalasztja ezt a nevet a cimtarbol, elmegy a level mindekinek.

Roundcube-ban erre tud valaki valami hasonlo egyszeru megoldast anelkul, hogy a forrast kellene megpatkolni? A vesszos listara sir, hogy nem ervenyes email cim, gondlom az elvalaszto karakter fennakad az email string ellenorzesen.

Koszi.

Sziasztok!

A Whitehouse Drupalt használ. Az Economist Drupalt használ. Felmerült bennem a kérdés, hogy vajon a Drupal ennyire jó, ennyire biztonságos, vagy ezek a cégek egy sereg programozót tartanak fenn, akik a felismerhetetlenségig újraírják az egész kódot, így teszik biztonságossá...

Vajon, ha egy céges honlapon csak annyit teszünk, hogy minden frissítést időben felteszünk, és nem használunk szedett-vedett modulokat, akkor (a weboldal szempontjából) biztonságosnak tekinthető az oldal?

Tudom, hogy bármit fel lehet törni, de mégis... Ti mit gondoltok a Drupal biztonságosságáról?

köszi a válaszokat!

Lenne egy kérdésem, hogy ezt ki, hogyan oldja meg?

Szerver oldalon mysql adatbázisban tárolás, utf8, courier szerver.

A gondom: korábbi RFC szerint a jelszavak 7bit-es ASCII kódolással mentek.

Úgy tűnik, Outlook az ékezetes jelszavakat úgy küldi el, hogy a spec karakterek mindegyikét kicseréli 0x2E-re.

8.04-es ubuntun squirrel ugyanezt tette, de 10.04-en ugyanazzal a config.php-val UTF-8-ban teszi.(még nem találtam, mi okozza a különbséget)

Roundcube küldésnél ISO-8895-1 -re konvertalja iconv-vel, ez majdnem ugyanaz, mint amit az Outlook csinál, de nem minden karatkert cserel 0x2E-re, van, amit kihagy teljesen, tehát nem lesz egyező az MS félével.
Roundcube-nál a csavar pluszban, hogy a password pluginja UTF-8-ban menti el az új jelszót, tehát ha Roundcube-bal megváltoztatom, akkor Roundcube már nem lép vissza többet, de Lucid-on Squirrel igen.
RC-ben a index.php-ban a jelszóküldésnél bedrótozott ISO-8895-1 -et UTF-8-ra cserélem, akkor ő is be tud lépni megint, de Outlook-kal így ugye nem megy.

Evo szintén UTF8-ban küldi.

Szóval mi lehet a megoldás, felhasználok ne használjanak ékezetet jelszóban? :-)

Hi!

Olyan megoldást keresek ahol 4 képet tudok egymástól függetlenül fadder effektel váltani. A 4 kép egymás melletti div-ekbe van.
Tegnap szórakoztam, kipróbáltam több lehetőséget is, de amint több képre (div-re) teszem az effektet nem működik.
Lehet hajnalba már én néztem be valamit....

Szal melyik jquery plugin tudja ezt megoldani?
Képenként 5-10 kép lenne ami változna.

pch

Van egy több éve jól működő postfix+courier levelező szerverem, virtuális felhasználók MySQL-ben vannak. Egyvalami róható fel hibának, a levelek tulajdonosa postfix.postfix , nincs külön vmail felhasználó erre.

Érkezett egy kérés, legyen levélválogatási lehetőség. Ezt procmail-lel szerettem volna megvalósítani, a következőképpen.
Felvettem egy vmail felhasználót:
vmail:x:5000:5000::/serve/vmail/:/bin/false

master.cf -be hozzáadtam a procmiailt:

procmail unix - n n - - pipe
  flags=DRO user=vmail argv=/usr/bin/procmail -t -m USER=${user} RECIPIENT=${recipient} /etc/postfix/procmailrc.common

A procmailrc.common a következő:

:0
* RECIPIENT ?? .*@\/.*$
{ DOMAIN = "$MATCH" }
#added RECIPIENT variable and we extract domain name
MAILDIR="/serve/vmail/$DOMAIN/$USER"
VERBOSE=YES
DEFAULT="$MAILDIR/"
#each user will set his own log file
NL="
"
WS=" "
SWITCHRC="/serve/vmail/$DOMAIN/$USER/.procmailrc"

Végül egyelőre csak saját magamnak beállítottam a procmail-t a transport-ban. Amikor levelet kapok, az nem kerül kézbesítésre:

(temporary failure. Command output: procmail: Couldn't chdir to "/serve/vmail/<domain>/gcs" procmail: [27899] Sat Jul 31 19:10:17 2010 procmail: Assigning "DEFAULT=./" procmail: Assigning "NL= " procmail: Assigning "WS= " procmail: Assigning "SWITCHRC=/serve/vmail/<domain>/gcs/.procmailrc" procmail: Couldn't read "/serve/vmail/<domain>/gcs/.procmailrc" procmail: Unable to treat as directory "./new" procmail: Skipped "."  Subject: vmail   Folder: **Requeued**             0)

Próbáltam már vmail.vmail tulajdonába átadni a maildir-emet, már 0777 jogokkal is próbálkoztam. Eredmény ugyanez. Az említett jegyzékek léteznek, akárcsak a .procmailrc . Miért nem tud akkor oda belépni és miért nem találja meg a saját konfigurációmat?

Tud valaki egyéb levélválogatási lehetőségről amit a felhasználók egy webes felületről saját maguk tudnának állítgatni?

Ha valamikor elerheto volt az oldal, de most nem az (es meg van nyitva egy fulon), akkor hogyan tudom a gepre lementett valtozatot betolteni cache-bol (ha tarolja egyaltalan a szoveges reszt, regen ugy emlekszem lehetett ilyet).

Üdv! Gondoltam egyet, szeretném igénybe venni a flickr szolgáltatásait. Ehhez azonban yahoo! ID-t kellett regisztrálnom. Szokásos felhasználónevemmel próbáltam (nem nehéz kitalálni...), de mint a yahoo.com-os, mint a ymail.com-os cím foglalt volt. Felkaptam a vizet, mi az, hogy más "ellopja" a júzernevem, megszoktam, hogy mindenhol ugyanazt használom. Hirtelen ötlettől vezérelve küldtem mindkét címre egy levelet, hogy adják vissza, ami nekem jár - az eredményen meglepődtem: mindkét levél visszapattant, először csak azt hittem, hogy egyszerűen nem létezik, de aztán rendesen elolvasva láttam, hogy a hibaüzenet szerint a fiókok "disabled or discontinued".
Most ilyenkor le is van foglalva a felhasználónév, meg nincs is? Hihetetlen, hogy ezért nem tudok regisztrálni...

Tudom hogy ez kell hozzá, és a gyakorlatban is végiglépkedtem a varázslóval a dolgokon. A megosztás a varázsló szerint megtörtént.
A hálókártya csatlakozva, a samba démon fut.
Linux oldalon egy mappát illetve esetlegesen behelyezett pendrivot, dvd-t kellene hogy lásson egy elvetemült windows 2000.
Az abban lévő teljes hálózati lehetőségek között a local area már nem visel piros x-t, tehát elvileg az is csatlakozott. De hová? Ugyanis a workgroup-ban nem látom a Mandriva által megosztott mappát.

Viszont még nem csináltam ilyet ennek előtte. A szabi-linuxon már olvasgattam a samba dolgairól, de fenntartásaim vannak annak régi dátuma miatt. Rengeteg smb.conf példafájl is kering a neten...
No de mégis merre induljak el? A bőség zavara. Aztán ki tudja hogy a sok példafájl közül melyek teljes hülyeség, és melyik a gyöngyszem?

Leginkább azt nem értem hogy mi kell a windowson ahhoz, hogy az lássa is a megosztásokat.

A linuxos gépen van a server ugye, mert oda települt. Beadott egy varázslót, melyen végiglépkedtem. Többnyire csak ok gombbal.
A windows 2000 mint kliens hogy jön a képbe, oda is kellene esetleg telepíteni valamit? Mert mint említettem jelenleg semmi.
A linuxos gépen a hálókártyán statikus IP-t adtam meg, Ha ez számít... Ugyanis ha jól értettem akkor a samba is tcp-ip-n alapul.
A windowsos gépen eddig semmit nem csináltam. Gondoltam mivel windows, úgyis megcsinálták már helyettem Redmondban.

Előre is köszi.