Jump to content

Sigfrido

Members
  • Content Count

    19
  • Joined

  • Last visited

  1. Sono d'accordo che come collaborative suite sia decisamente "completa"; ma paragonando i vari servizi hosted, economicamente parlando siamo lì (almeno tra Google Apps Premiere/Biz e Zimbra il prezzo è allineato).
  2. Dal momento che sto valutando anche io la cosa, di Zimbra che ne dite? Versione managed, ad esempio qui. Alternativamente Lotus, ma soprattutto Rackspace. Pareri?
  3. Sigfrido

    Amazon SES

    Ed è appunto questo che non condivido: lo script sviluppato internamente non ti permette di fare ciò che fa MailChimp o un competitor allineato. La riprova è che lo stesso Mailchimp ha implementato SES per il servizio STS che è ben diverso dalla gestione di una newsletter. ma il costo dello sviluppo e dell'integrazione dello script di invio sviluppato internamente?Se mi parli di bulk/transactional mail sono d'accordo, ma per queste non si sarebbe mai usato Mailchimp. E anche prima io avrei optato per altri servizi, senza usare "Strutturadiinviocomplicataecostosa". JangoSMTP, SendGrid, SocketLabs, Postmarkapp, ... . Sui prezzi c'è da discutere quanto vuoi, ma ovviamente loro non offrono solo il semplice routing della mail.
  4. Sigfrido

    Amazon SES

    Ma vedi, continuo a non cogliere la rivoluzione. Se mi dici: significa che non ci sono attori sul mercato in grado di competere, e questo non è necessariamente vero. Se confrontiamo il solo invio, è possibile quanto affermi. Tuttavia esistevano (ed esistono) servizi che consentono l'invio di mail, e anche con il modello pay per use fra l'altro, che hanno un prezzo interessante e feature maggiori. Se invece valutiamo l'invio e alcuni parametri deliverability e trackback, già così forse SES non è la scelta ideale. Se poi consideriamo l'invio per le newsletter (e quindi anche riscontro/report analitico), SES non è la scelta idonea. Sono segmenti di mercato differenti, per applicativi diversi. Se l'affermazione fosse stata "è arrivato SES, è più conveniente di un mta in produzione per inviare mail" allora non avrei avuto nulla da obiettare.
  5. Sigfrido

    Amazon SES

    Ok, ma cosa c'entra il paragone con Mailchimp? E' un altro tipo di servizio. Imho, è come se paragonassi il motore ad una macchina; entrambi si accendono, ma solo una ti porta in giro. Anche prima si poteva usare una routine sendmail per inviare mail da un host ad un altro, il rischio era ovviamente, in contesto pro, il bl e altre simpatiche problematiche. Personalmente, trovandomi peraltro proprio recentemente a dover valutare una serie di servizi, non userei mai Amazon SES per l'invio di ML.
  6. Sigfrido

    Amazon SES

    Se il problema è la risorsa hardware (ip, struttura, banda) per inviare delle e-mail, posso convenire. MA Nella gestione delle newsletter "serie" (e non del tipo send & forget) c'è un'analisi della penetrazione delle stesse, per le quali le esigenze primarie sono: deliverability tackback (bounce ed informazioni) analisi (click/link/...) e questo Amazon SES non lo offre, ovviamente. Ecco perchè esistono servizi come Mailchimp, JangoMail, Newsberry o i nostrani ContactLab, Mailup, Voxmail e simili. Se invece mi paragoni Amazon SES ad altri servizi "bulk", fermo restando che alcuni per policy addirittura impediscono l'impiego per newsletter e campagne (quindi "permettono" solo mail transazionali), allora può essere estremamente conveniente a patto che non ti interessino garanzie di deliverability e statistiche base di invio/ricezione/discard.
  7. Sigfrido

    Amazon SES

    Come proclama lo trovo un bel pò impreciso. In primis è un servizio beta. In secondo luogo, si tratta di un engine (sostanzialmente solo la parte di smtp) che ha delle limitazioni evidenti (analisi in primis) e dei punti oscuri (deliverability, compreso il lecito sospetto dei pool di ip disponibili per l'invio, dato che quelli di EC2 sono spesso e volentieri in bl). Infine, non è un servizio che ha come target le campagne, per cui è necessaria analisi di ritorno, bensì equiparabile all'invio di bulk/transactional e-mail, pertanto i competitor diretti potrebbero essere SendGrid e simili. Non a caso Mailchimp ha integrato Amazon SES in Mailchimp STS, servizio sperimentale dedicato all'invio di mail non "massive".
  8. non ci siamo capiti. Il primo step è importarle, e ovviamente non posso usare una soluzione imap2imap ma devo affidarmi ad un loro tool (lavora con mbox? csv? eml?); pertanto mi chiedevo se qualcuno avesse avuto esperienza diretta di eventuali problemi di codifica, bad import e simili.
  9. Non mi riferivo alla sincronizzazione tramite imap ma all'importer che dovrebbe essere eseguito per spostare le attuali e-mail dal mio client al server.
  10. riuppo questa discussione per un'informazione da richiedere a voi che sicuramente avete analizzato l'offerta di Rackspace (o anche l'omologo Google Apps). Attualmente gestisco la mia posta elettronica (8 account) sul mio client, senza lasciare alcunchè sul server (tutto via pop, niente imap); pertanto mi trovo oltre 10 GB di dati e migliaia di messaggi regolarmente splamati sui diversi account/identità gestiti tramite Thunderbird. Ora, sarei interessato a portare tutto sul provider americano, ma sono un pò scettico. Se non ho capito male, devo reimportare tutti i miei dati sul loro server tramite un tool di sincronizzazione, e da quel momento, a seconda del device utilizzato ogni messaggio in invio/ricezione transita sul loro server riducendo il client di posta (iMail, Tb, ...) ad una mera interfaccia che riflette l'organizzazione della mail che verrà gestita dal ESP prescelto. Ne derivano alcune domande: 1) Il processo di sincronizzazione è fedele o può danneggiare l'importazione dei dati/e-mail? (problemi di codifica, layout, perdita messaggi) 2) Il processo di importazione, se un domani dovessi volere tornare ai metodi tradizionali, è reversibile senza incorrere nelle problematiche di cui al punto precedente? 3) La durata dell'archiviazione è indefinita o c'è un limite in anni? Mi sembra che per Google Apps sia così. 4) La dimensione di archiviazione è limitata e dipendente dalla policy del provider? Ad ora, se trovo problemi di spazio, cambio un disco, mentre dopo potrei rischiare di non poter seguire la naturale crescita dei messaggi. Grazie!
  11. l'avevo scritto! :) Ma questo comunque non risolve il problema che ho segnalato, ahimé, perchè l'owner è identico dovunque il php venga usato.
  12. Ciao a tutti, Sono di fronte ad un problema piuttosto particolare. Sistema FreeBSD 8.0 Apache22 Php 5.2.x PureFTP (per la gestione degli ftp, quindi master uid/gid reale e virtual user per gli utenti) Ora, tecnicamente vorrei limitare i privilegi di esecuzione degli script php contenuti negli account ftp per evitare attacchi dall'interno dal momento che un codice lesivo potenzialmente potrebbe stealare informazioni o risalire in esecuzione al filesystem. Sarebbe quindi sensato implementare fastcgi e suExec, ma qui nascono i problemi. Trattandosi di account ftp virtuali, se implementassi i port di cui sopra, al massimo otterrei che gli script php vengano eseguiti da pureftp:pureftp (uid/gid di PureFTP), il che esclude la possibilità di risalire, in rwx, al di sopra dei path owned by PureFTP (il che metterebbe in "sicurezza" la macchina) ma non evita che uno script .php possa stealare informazioni da un altro path dedicato ad un utente ftp virtuale. Es. Path utente virtuale 1 \home\www\dominio1\informazioni (pureftp:pureftp) Path utente virtuale 2 \home\www\dominio2\script_malevolo.php (pureftp:pureftp) Gli utenti che possono accedere ai due path sono differenti, PureFTP emula una specie di chroot che evita si possa risalire alla radice ma, poichè l'owner è identico (uid/gid unico reale nel sistema), teoricamente l'utente ftp virtuale 2 potrebbe eseguire codice e "accedere" alle informazioni dell'utente ftp virtuale 1. Come potrei risolvere? Eccetto ovviamente usare ftp uid/gid reali e/o cambiare gestore ftp. :) Una prima soluzione (parziale) potrebbe essere quella di disabilitare via php.ini, alcune funzioni (disable_functions) poichè il safe_mode è deprecato, non efficiente e comunque verrà rimosso. (ovviamente nei vhosts verrebbe specificata la restrizione open_basedir) Diciamo: disable_functions = exec,passthru,shell_exec,system,proc_open,popen,curl_exec,curl_multi_exec,parse_ini_file,show_source Però ovviamente questa soluzione è limitata/limitante. Altre idee?
  13. Sigfrido

    [Firewall]: consigli per gli acquisti

    Ho ridotto la scelta a Zyxel Zywall USG200, Fortigate 60b o 80c. A parte valori di concurrent session e throughput, lo Zywall mi sembra più completo.
  14. Sigfrido

    [Firewall]: consigli per gli acquisti

    Intendi che un USG (100 o 200 o 300, a seconda del throughput/sessioni) potrebbe essere una valida scelta immagino. Altrimenti anche un Fortigate 60x o 80x (dovrei aver trovato i 60B a metà prezzo).
  15. Sigfrido

    [Firewall]: consigli per gli acquisti

    Beh, un celeron con un raid1 e due dischi low profile 40gb (o i 160) presumo sforino. Non è tassativo sia rackmountable, al massimo inserisco una mensola. Comunque mi sto informando su tutto...poi decido.
×