Jump to content

guest

Members
  • Content Count

    6,967
  • Joined

  • Last visited

  • Days Won

    4

Everything posted by guest

  1. Giusto per curiosità, controllati in base a chi ed a che cosa? Se io, autore di un dato sito/applicativo per conto di un mio cliente, avessi venduto il tutto SENZA sorgenti ma con una sorta di canone d'uso (cosa che fanno il 99.999% delle webagency in italia), dopo questa operazione mi ritroverei con i (miei) sorgenti in mano al cliente (che non li ha pagati) solo perchè i file sono stati "meticolosamente controllati" ?
  2. guest

    Tessere le lodi di un provider

    Secondo me la domanda di GrG era: se il 13 Giugno eri in fase di trattativa presales con 2 aziende, oggi che è il 18, come puoi farne una recensione approfondita? Anche con tutta la buona volontà, hai, nella migliore delle ipotesi (ovvero un acquisto concluso il 13) non più di 5 giorni di servizio attivo.
  3. guest

    Te lo spiego con l'immagine

    Recursion, atari breakout e "conway's game of life" a me non fanno nulla. Cosa dovrei vedere?
  4. Ripartiamo da zero: cosa vuoi fare ? no, non puoi farlo se hai solo IPv6 altrimenti i destinatari solo IPv4 non riceverebbero posta e/o la riceverebbero dal tuo unico IPv4 non randomizzato.
  5. Continuo a non aver capito nulla di quello che vuoi fare. Come prima cosa: non esiste il "bind in roundrobin". O fai il bind su un dato IP, o non lo fai. Se fai il bind su 10 IP, sarai raggiungibile da tutti e 10, ma non in roundrobin. Semplicemente chi ti cerca su 1.2.3.4 ti raggiungerà su 1.2.3.4. Fine. Il roundrobin viene gestito a monte con protocolli diversi, ma è un problema che non ti riguarda nemmeno alla lontana. Se fai il bind sugli IPv4 e sugli IPv6 (cosa che normalmente si fa su un mailserver per poter gestire il dual-stack) la mail non transiterà per tutti gli IP ma solo per quello sul quale ti scrivono. Quindi, come già detto, se tu hai 2 (o più IPv6) ed 1 solo IPv4 e cerchi di inviare ad aruba, il tuo server farà solo UN tentativo, ovvero l'invio mediante IPv4 dato che il v6 aruba non c'è l'ha. Più che libro sulla matematica delle elementari suggerisco un libro sulle reti, sui gateway e cose simili. Forse da qui si può partire: Indirizzo IP - Wikipedia
  6. Hai un po di confusione in testa. Non esiste alcun fallback verso IPv4, sono due protocolli diversi, è come paragonare le mele con le pere. Un pera non diventerà mai una mela, anche aspettando 10 anni. Se il server di chi riceve è configurato solo in IPv6 e tu sei solo IPv4, non gli scriverai mai. Viceversa, se sei solo IPv6 e chi riceve riceve solo IPv4, non gli scriverai mai ugualmente. Se chi invia è in dualstack, ovvero sia IP4 che IPv6 e lo è anche chi riceve, quasi certamente gli scriverai tramite IPv6 (IPv6 ha priorità). Ad esempio tutte le nostre mail verso google transitano in IPv6. Nel caso l'MX associato al record IPv6 dovesse avere problemi, ed allo stesso tempo lo stesso dominio ha anche gli MX IPv4, gli scriverai in IPv4 ma grazia alla ridondanza degli MX, non al protocollo che fa una sorta di fallback.
  7. Se chi riceve non è configurato in IPv6, salvo palesi errori di configurazione, avrà gli MX che puntano solo ad IPv4 pertanto tu invierai in v4: IPv6: $ dig mx gmail.com +short 20 alt2.gmail-smtp-in.l.google.com. 5 gmail-smtp-in.l.google.com. 40 alt4.gmail-smtp-in.l.google.com. 30 alt3.gmail-smtp-in.l.google.com. 10 alt1.gmail-smtp-in.l.google.com. $ dig a alt2.gmail-smtp-in.l.google.com +short 74.125.25.26 $ dig aaaa alt2.gmail-smtp-in.l.google.com +short 2607:f8b0:400e:c03::1b IPv4-only: $ dig mx aruba.it +short 10 mailfree.aruba.it. $ dig aaaa mailfree.aruba.it +short $ dig a mailfree.aruba.it +short 62.149.128.10 62.149.128.135
  8. La domanda corretta da fare è: come mai non hai ancora configurato IPv6? E' vero, gli IP stan finendo, se non configuri IPv6, non sarai in grado di inviare posta a server ipv6-only.
  9. guest

    pannello di controllo https

    Vabbè, basta mandare un link di attivazione.
  10. guest

    pannello di controllo https

    Ma qui non si parla di una banca, ne di una base di centinaia di milioni di utenti. Già inviare via mail solo un link diretto per il cambio password anzichè la coppia di credenziali vere e proprie incrementa decisamente la sicurezza. Nessuno si mette a sniffare il tuo traffico se non ha motivo per farlo. E' complesso, richiede tempo e capacità. Se usi TLS/SSL per la posta (ed è cosa buona e giusta) diventa ancora più difficile. Il 99% dei problemi della posta è in merito all'SMTP, non al POP3/IMAP. Devo ancora vedere una singola compromissione della casella di posta, mentre dell'SMTP ne vedo almeno 20 al giorno causate da bruteforce e password assurde impostate dai clienti (123456 etc etc) oppure da keylogger. E comunque non è vero che google ti obbliga ad inserire un telefono, io non l'ho mai fatto e mi sono registrato tranquillamente. Altra soluzione sarebbe quella di far inserire le credenziali direttamente al cliente senza inviarle via mail. Il cliente in fase di registrazione le inserisce e li finisce la procedura.
  11. Oh beh, dipende di quanti ms si parla. Se anche fossero 50ms in più, io dubito che chiunque, non del settore possa notare una differenza alcuna. Facciamo anche 100ms e crepi l'avarizia. Del tipo: Amazon.com: Online Shopping for Electronics, Apparel, Computers, Books, DVDs & more punta su 205.251.242.54 e su 72.21.215.232 che dovrebbero essere in zona Virginia. Eppure io ci navigo più volte al giorno e solo ora ho scoperto che i due IP sono in america. (perchè non usano il loro stesso cloud?)
  12. guest

    pannello di controllo https

    Mandi via mai una password one-time che il cliente è obbligato a cambiare al primo accesso. Tale password potrà accedere solo e soltanto alla procedura di cambio password e non ad altro. Una volta cambiata (e lo deve fare per forza) la one-time diventa automaticamente non valida e quindi le credenziali reali non transiteranno mai via mail. In alternativa mandi via mail solo il link per il reset password con un luuuuuuuuuuuuungo codice, preferibilmente non in stile OVH
  13. Boh, io navigo moltissimo in HSDPA anche su siti americani che sicuramente non hanno CDN e non ho mai notato una lentezza così esasperante da dire: uff, mamma mia che latenza, domani non ci torno più. Navigo e basta. Ho in mano un dispositivo mobile, so già che la navigazione giocoforza sarà più lenta.
  14. Questo ti sarà certamente di aiuto nel caso avessi di bisogno di qualunque cosa non esplicitamente indicata dal contratto.
  15. guest

    pannello di controllo https

    Scusa, non avevo letto la parola "mail". Si parlava di pannelli ed ho fatto 2+2.
  16. Basta sviluppare a modo la pagina, ed evitare, come purtroppo va (andava?) di moda da parte di molti sviluppatori PHP, la disattivazione delle varie cache del browser indiscriminatamente. Ho visto più e più siti sviluppati con tutte le pagine in no-cache. Se poi aggiungi una corretta configurazione del webserver con mod_expire o equivalente, magari l'utilizzo degli sprites per le icone e/o mini-immagini, la minificazione dei JS/CSS, il gioco è fatto o quantomeno il problema largamente aggirato. Che poi sono tecniche base da adottare nello sviluppo di un sito web quando si pensa di avere a che fare con latenze importanti.
  17. guest

    pannello di controllo https

    Vero, ma non mi dirai che nel 2013 ci sono ancora dei pazzi che salvano le password delle email in chiaro......... Se le password sono criptate a modo (ovvero one-way) l'HTTPS non fornisce alcuna protezione in più. Se invece sono salvate in chiaro, l'HTTPS non ti protegge ugualmente da nulla.
  18. guest

    pannello di controllo https

    L'HTTPS non fornisce sicurezza ma solo la protezione (parziale) da intercettazioni di tipo MITM. Bisogna poi valutare la 'sensibilità' di tali informazioni, per una banca direi che è fondamentale, per il sito del salumiere invece del tutto superfluo. Devo ancora vedere il malintenzionato che perde del tempo contro il sito del salumiere dove potrà trovare, al massimo, il numero di fiorentine vendute ai propri clienti piuttosto che concentrarsi su una banca dove può trovare informazioni ben più interessanti. Gli authcode di solito vengono inviati via mail ai registranti del dominio (che non è necessariamente colui che ha accesso alle varie aree clienti, vedi ad esempio le webagency) e, salvo folli, salvati criptati sul DB del registrar.
  19. guest

    Il fascino dei datacenter

    Le immagini postate non hanno alcun valore, sono da brochure, paurosamente sovraesposte e tarate 'a modo'
  20. guest

    Il fascino dei datacenter

    Se lo riduci in un groviglio di fili ed hai più 3 (tre) server, ti sfido a risolvere eventuali problematiche quando deve identificare chi collega cosa e dove. Finchè tutto va bene, un groviglio di fili, purchè non ostruisca l'areazione, è indifferente, ma come sempre in questi casi, la qualità si vede in caso di problemi.
  21. Tieni presente che in caso di multidominio, quasi sempre, in caso di problemi (compromissioni, sospensioni, etc etc) tutto l'hosting ne risente. Se hai bisogno di tenere separati i clienti ma avere una gestione univoca, devi prendere un piano reseller (molto più costoso).
  22. Usa un htaccess almeno non scomodi PHP.
  23. Usare https significa cifrare la connessione. Non l'hai scritto ma dato che HTTPS fa solo quello, è implicito. Però non vedo in che modo l'https possa evitare lo spam.
  24. mi sfugge una cosa: per quale motivo cifrare la connessione per un hash di un dump?
×