Newsgroup: it.sport.ciclismo
Titolo: [OT] Hotmail merda

Scusate l'evidente OT ma mi girano troppo le scatole.
È a dir poco scandaloso il fatto che inviando delle email ad utenti 
Hotmail, queste non arrivino a destinazione ed il mittente non venga 
nemmeno avvisato della mancata ricezione da parte del destinatario.
A quanto pare non sono l'unico che ha avuto questo problema:
http://davesource.com/Bugs/hotmail.1.html
Mi raccomando, boicottate Hotmail.
-- 
http://modesta.biciticino.ch
Il sito dedicato alla giovane ciclista lituana Modesta Vzesniauskaite

 nemmeno avvisato della mancata ricezione da parte del destinatario.
La "mail delivery notification" in caso di errore è uno degli standard
dell'smtp (come da RFC),
Hotmail è della Microsoft... secondo te oltre a violare gli standard e
non funzionare, cosa ci si può aspettare?
-- 
Massimo Bacilieri AKA Crononauta 
ICQ:4005815

 non funzionare, cosa ci si può aspettare?
ma se un client di posta chiede al suo server "outcoming" di mandare una
mail ad un indirizzo di hotmail, per qualche motivo non riesce a trovare il
"recipient" di hotmail o a fare il "relayed" su un altro server, non
dovrebbe essere lui a generare il "mail delivery notification" ?
in altre parole, non credo che la notifica dello stato di consegna della
mail dipenda dal server che riceve, che potrebbe anche non esistere
-- 
Mardot

 mail dipenda dal server che riceve, che potrebbe anche non esistere
Facciamo un paio di esempi che sono emblematici.
Ipotizziamo l'utente tizio del provider 
caio.it
 (sia il suo indirizzo
ti...@caio.it
) che invia una mail a 
semp...@salcazzo.it
.
Possono sostanzialmente succedere 3 scenari:
1) 
salcazzo.it
 esiste ed accetta la mail;
2) 
salcazzo.it
 esiste ma rigetta la mail;
3) 
salcazzo.it
 non esiste.
Nel caso 1, la regola vuole che il server che accetta una mail per relay
o delivery poi la *deve* consegnare. Se 
salcazzo.it
 accetta la mail
senza errori, e poi però la "brucia" senza consegnarla, viola gli
standard. Nel frattempo, 
caio.it
 "pensa" che la mail sia andata a buon
fine perché è stata accettata e non genera nessun tipo di errore.
L'utente tizio è perciò indotto a credere che la mail sia stata
consegnata.
Nel caso 2, 
salcazzo.it
 rispetta gli standard e genera un errore.
Secondo le specifiche, 
caio.it
 deve notificare al suo utente dell'errore
avvenuto. Se non lo fa, viola gli standard.
Nel caso 3, l'errore lo riceve direttamente 
caio.it
 che non può
collegarsi al destinatario (che non esiste). Si ritorna quindi al caso
2.
Il tutto tenendo presente che il relay può essere multiplo, es. io ho
una rete aziendale con un smtp usato dai miei utenti. Il mio smtp
raccoglie le mail degli utenti, e fa relay verso l'smtp del provider che
mi da la connessione; il quale smtp fa a sua volta relay verso il server
di destinazione. O forse verso un altro server interno dopo aver fatto
controlli antispam e filtri antivirus, chi lo sa :-)
Al termine della catena, il messaggio viene infine consegnato al server
del provider di *destinazione* che si occupa del delivery nella mailbox
degli utenti.
Perciò non è sempre detto che la colpa sia del server "mittente",
dipende qual è il server della catena che viola gli standard: può essere
tanto uno dei server di relay che quello di delivery.


 supercut
I agree !
-- 
Mardot