Newsgroup: it.comp.www.php
Titolo: Mail() Vs SMTP Vs altri modi di invio email, qual'è il più veloce?

Ciao a tutti, devo inviare email da remoto e ho letto che vi sono altre 
possibilità oltre a Mail(), ossia SMTP, Sendmail etc.
Da locale uso SMTP tramite PHPMailer, ma -probabilmente per il tempo di 
accesso al server per autenticarsi- un secondo e mezzo di attesa se lo 
prende. Da remoto il sistema più rapido per l'invio qual'è?
Grazie mille.
Giorgio

 possibilità oltre a Mail(), ossia SMTP, Sendmail etc.
L'unico modo per inviare le mail è l'smtp; questo può essere realizzato 
da diversi server (sendmail, postfix, exim etc); il comando mail() di 
php devi vederlo come un client di posta. mail() si occupa di prendere 
la mail, aggiungere qualche header ed inviarla al server smtp impostato 
nel file php.ini. Se l'invio delle mail avviene tramite server 
autenticato, mail() non funziona e, per questo motivo, devi utilizzare 
classi (client) evoluti (phpmailer, pear::mail etc.) Con la classe puoi 
specificare un server particolare (smtp), oppure il server installato 
sulla macchina (sendmail[1])
La velocità per l'invio di una mail dipende dal server e non dal client 
(quindi phpmailer, pear::mail etc.). Se accetti un consiglio, scarta 
mail(), ottimo per inviare una mail di alert (subject + body) ma 
incapace di gestire (agevolmente) attach, mail in html, bcc, cc etc.....
[1] E' una convenzione, il comando sendmail c'e' sempre su linux (reale 
o alias ad altro server di posta)
	Francesco

Francesco F ha scritto:

Ti ringrazio Francesco, sei stato molto chiaro.
Un'ultima domanda sempre riferita alla 'velocità' di invio.
Se uso il server installato sulla macchina (sendmail) in remoto sperando 
il mio spazio web ne sfrutti una, l'invio è più rapido rispetto all'uso 
di un server smtp con autenticazione giusto?

 autenticazione giusto?
Usare un server SMTP sulla stessa macchina in cui gira lo script PHP e` 
(naturalmente) la cosa piu` veloce.
Ogni altra soluzione e` piu` lenta, perche` richiede collegamenti in 
rete, 6-7 ordini di grandezza piu` lenti dell'accesso alla RAM.
Questo in linea generale perche` non ho capito cosa hai chiesto, di 
preciso.
Bye.

Alessandro Pellizzari ha scritto:

perdonami la vagezza ma mi hai cmq risposto ^_^
Il problema è legato più alla sicurezza del sito e spiego il perchè.
Quando un utente si iscrive alla newsletter ho creato lo script che 
manda in auto all'indirizzo email registrato un link per l'attivazione.
Ecco, nell'invio di questa email la pagina che contiene lo script 
temporeggia di un secondo abbondante per aprirsi del tutto, sicuramente 
perchè deve loggarsi al server SMTP esterno e autenticarsi.
Mi chiedo se un malintenzionato non possa fare andare in tilt il tutto 
inserendo uno dopo l'altro una raffica di indirizzi email nel campo 
della newsletter. In questo modo la pagina che manda l'email dovrebbe 
essere caricata di continuo e loggarsi di continuo al server SMTP remoto 
fino a collassare o far andare in errore il server di posta.
Una sorta di mass mailing insomma.
Spero di essere stato chiaro.
Grazie a tutti.
Giorgio.

 errore il server di posta. Una sorta di mass mailing insomma.
Capisco cosa temi. Un DoS, in pratica.
Dubito che un hacker possa attaccarsi a una cosa del genere per 
provocarlo, semplicemente perche` il processo del server web che si sta 
collegando al server SMTP e` in attesa passiva, quindi non occupa la CPU.
Puo` capitare che mandando centinaia di richieste in quel secondo di 
attesa costringa entrambi i server ad avere centinaia di connessioni 
aperte, ma questo rischio ce l'hai con qualsiasi pagina dinamica. Inoltre 
centinaia di connessioni non sono molte per un server moderno, mentre 
mettono in crisi un comune router ADSL, quindi l'attaccante sarebbe 
costretto a un DDoS.
Se fossi un cracker, io piuttosto punterei su una pagina con una query 
che mi sembra complicata, in modo da "far sedere" sia il server web che 
il server DB.
Secondo me dovresti preoccuparti di altri aspetti e lasciare questo per 
ultimo.
Per esempio: controlla che da quella pagina non ci sia modo di mandare 
SPAM, per esempio se usi uno dei campi del form negli header della mail, 
prima sanitizzalo, rimuovi i ritorni a capo e roba simile.
Bye.

 prima sanitizzalo, rimuovi i ritorni a capo e roba simile.
l'unico campo richiesto nella pagina della newsletter oltre alla 
'spunta' obbligatoria sull'informativa relativa alla privacy è un <input 
type ...> contenente appunto l'indirizzo email.
Una volta inserita l'email e memorizzata nella variabile $nwem gli viene 
fatta una pulizia pesante di eventuali caratteri malevoli con:
$nwem=preg_replace("/[^a-z0-9 \@\.\-\_]+/i","§",$nwem);
$nwem=preg_replace("/(script|javascript|alert|insert|update|delete|drop|java|cmd|xor|php)+/i","*",$nwem);
$atem=count(explode('@',$nwem))-1;
senza riportare tutto il codice per non tediarvi, in seguito lo script 
controlla se è presente anche una sola volta il carattere '§' (v.prima 
riga). Se c'è dice all'utente che l'indirizzo è irregolare.
In seguito se ha superato questa prima verifica ne parte un'altra sulla 
lunghezza del contenuto:
 
if(($atem!=1)||(strlen($nwem)<=4)||(strlen($nwem)>=35)||(preg_match("/§+/i",$nwem))){ 
print "<span style='color: #BC0000;'>Indirizzo email non 
accettabile.</span>";
}else{
print "email inviata etc.etc."
}
sicuramente esisterà un modo più celere e snello per sintetizzare il 
tutto. Ma spero basti per uno spammer.
Sei/siete d'accordo?
Grazie ancora.

 $atem=count(explode('@',$nwem))-1;
Odio abbastanza le regexp da non mettermi nemmeno ad interpretare la tua, 
quindi non saprei dirti se e` valida o meno. :)
Ti faccio comunque presente che la tua regexp, essendo piu` corta di 2 
schermate del mio mailer, e` sbagliata. In giro per Internet dovresti 
trovare quella corretta per validare un indirizzo email. ;)
Io semplicemente "invalido" l'email (o qualsiasi campo che vada 
nell'header del messaggio) se contiene un ritorno a capo (\n o \r) perche` 
e` necessario per iniettare header aggiuntivi e quindi mandare spam.
Se devo infilarla in DB uso i soliti mysql_real_escape_string() e simili.
Poi se l'utente la scrive sbagliata sono 'zzi suoi. :)
 
Per gli altri campi mi regolo in base alla situazione, da un minimo di 
"nulla", passando per il controllo della lunghezza, la presenza di tag 
html ed eventualmente fino a filtri antispam interni o esterni.
Bye.