Newsgroup: it.comp.reti.ip-admin
Titolo: Codici errore SMTP

Sono un RFC ignorant, lo so, ma non capisco perchè gli MTA in giro per
Internet mi rispondano generalmente sempre con un 550 per errori diversi.
550 mailbox unavailable
550 quota exceeded
550: utente non attivo
soprattutto il primo caso, 550  mailbox unavailable di Hotmail...perchè non
mi ritorna un 554 come Yahoo?
o anche quelli che filtrano per spam (pochi ormai :P), sempre un 550...ci
sono 100 codici nel 5xx, perchè si utilizza solo il 550 nella stragrande
maggioranza dei casi??
C'è qualche motivo dietro che mi sfugge?
-- 
Vide
echo '[q]sa[ln0=aln256%Pln256/snlbx]sb3135071790101768542287578439snlbxq'|dc

 o anche quelli che filtrano per spam (pochi ormai :P), sempre un 550
E che ti doveva rispondere?
 >...ci sono 100 codici nel 5xx, perchè si utilizza solo il 550 nella 
 >stragrande
Non tutti implementati (vedi consiglio 1) ed il 550 è largamente 
utilizzato come errore generico accompagnato da una string esplicativa.
-- 
Fa freddo nello scriptorium, il pollice mi duole. Lascio questa 
scrittura, non so per chi, non so più intorno a che cosa...
U. Eco

 utilizzato come errore generico accompagnato da una string esplicativa.
Il codice genericamente ritenuto "corretto" dall'industria in relazione
a filtraggio dovuto a policy è 554, ma su questo punto ci sono
divergenze degli operatori, al riguardo, che fa sì che in giro ci siano
oggetti che si comportano in maniera difforme tra loro.
In generale, 550, 553, 554 sono ritenuti buoni, la cosa realmente
importante è la stringa informativa che accompagna il reject...
-- 
Skull & Bones (ER6n Silver)
Neo:  I know Sendmail!
Morpheus:  Show me.

 E che ti doveva rispondere?
55z: filtered for spam blablabla
e che tutti quelli che filtrano per spam blocchino con lo stesso 55z, almeno
posso saperlo a livello programmatico.
Da RFC-2821 mi pare di capire che i 55z non siano assolutamente usati tutti
e 10, per cui perchè non si utilizzano per definire meglio questi casi? C'è
qualche motivo che a me sfugge?


 qualche motivo che a me sfugge?
In realtà, come ti dicevo, non c'è una codifica esaustiva visto che in 
questi casi si restituisce la mail con un:
permanent delivery error
550 attacco termonucleare in corso
e si lascia all'utente la responsabilità delle azioni da intraprendere :)


 qualche motivo che a me sfugge?
Semplicemente, perchè molte eventualità sono diventate critiche ed
evidenti solo molto tempo dopo che quel set di codici è stato definito,
con il risultato che, negli anni, ogni
sviluppatore_di_SMTP/implementor/whatever ha applicato i codici come gli
sembrava più sensato farlo...


 sembrava più sensato farlo...
Ecco, questo era il succo che volevo sapere ;) so che è designed-by-comitee
però c'è almeno la "voglia" di voler differenziare meglio questi codici
almeno per i casi più eclatanti (quota, spam)...o sono l'unico che si
lamenta di questa cosa? perchè se sono l'unico mi metto il cuore in pace e
amen :P


 importante è la stringa informativa che accompagna il reject...
Non credo, almeno non a livello di integrazione con programmi, ad 
esempio php per dirne uno, dove si controlla con un substr l'occorrenza 
delle sole prime 3 cifre del codice di errore. I codici di errori sono 
stati definiti proprio perchè siano uno standard, mentre quello che ci 
scrivi dopo è a tua discrezione.
Io posso rifiutare con 554 Reject by 
x-privat.org
 by SpamHaus
e tu analogamente potresti rifiutare con 554 Reject by skull crunch :)
prova a pensare se un programmatore oltre a contemplare i vari 55X 
dovesse pensare anche alle fesserie che accompagnano i messaggi di 
errore :))
il 55X però dovrebbe essere una costante e se in RFC hanno assegnato 
diversi codici per diverse situazioni, un motivo vi sarà ...
mentre poi con il 250 siamo tutti d'accordo che sia ok, con i messaggi 
di rifiuto c'è non poca confusione, imho.
-- 
Ciao, Dmitry
I've a dream... bring usenet to every family 

 errore :))
Mi son spiegato male, credo...
Un conto è l'error code, il cui scopo è essere interpretato dal peer
SMTP [1].
Già su questo, SW diversi usano codici diversi, e nonostante in RFC ci
sian scritte alcune cose relativamente all'uso degli error code della
famiglia 55x in alcune specifiche situazioni, la realtà è che molti SW
usano i 55x come gli pare, trattandoli -circa- tutti alla stessa stregua.[2]
Questo perchè, nonostante le specifiche sull'uso in una condizione
anzichè nell'altra, il senso di tutti i 55x che posso rispondere, per il
peer che mi contattano, è sempre lo stesso: "'sta mail non passa,
rimandala indietro".
Per tale motivo, quando si parla di filtraggio per policy, nonostante
sia ritenuto consigliabile dai più usare il codice 554 (per mera
questione di correttezza formale: se usassi 550 o 553 il risultato
sarebbe assolutamente *identico*), la cosa che è ritenuta realmente
critica è il messaggio informativo che accompagna l'error-code, che deve
fornire informazioni il più precise possibile sulla esatta ragione del
rifiuto, in quanto questo è il punto di contatto iniziale che posso dare
al mittente per capire quale è il problema. Qui si va OT, comunque...
[1] Si tenga presente, da questo punto di vista, che scopo dell'error
code è questo: formalizzare con dei codici la comunicazione SMTP nel
corso della quale viene inviato.
Ci sono poi altre situazioni in cui si possa voler analizzare gli
error-code, ad esempio nel corso di analisi dei bounce generati da una
mailing-list, per individuare utenti da purgare dalla base dati...
In questo caso, si tenga ben presente che il formato del bounce che si
ottiene dipende solo dal software le l'ha generato, e alcuni server SMTP
generano i bounce senza riportare alcuna informazione su quale sia stata
la causa del problema, dicendo genericamente che "non riesce a
consegnare"...
[2] Quanto a quello, ci sono anche notevoli differenze più critiche: c'è
SW che in caso di over_quota rispondono con 55x, altri con 45x.
Addirittura c'è sw che risponde 45x anche per gli user_unknown...


 per capire quale è il problema. Qui si va OT, comunque... 
per me questo tuo discroso sul messaggio è validissimo lato utente, 
perchè è a questo alla fine che deve arrivare il messaggio o meglio
il relativo bounce.
Ad un peer smtp di quello che sta dopo il 55X gliene frega proprio poco 
tanto è che viene esaminata da qualsiasi software al mondo, solo
le prime tre cifre (ed alcuni immagino addirittura le prime due).
 
Quindi, ribadisco, non è una critica, avresti dovuto dire, imho: "è più 
importante per un *utente* il messaggio dopo il codice di errore" e non
generalizzare la cosa. Poi il thread era chiarificatore dei messaggi di
erroere e dei codici di ritorno non tanto filosofico sul fatto che un 
messaggio di errore debba essere il più possibile informativo.
Poi d'accordo con te che se il messaggio di errore, es 554, è 
accompagnato da un (esempio) 
http://www.x-privat.org/explanation/?id=554
è ancora meglio. L'utente legge il bounce e si fa un giro sul sito per 
capire meglio cosa è successo.
PS: quanti utenti leggono i messagi di ritorno degli SMTP? Nella mia 
esperienza solo gli addetti ai lavori e/o gli utenti smaliziati.


 esperienza solo gli addetti ai lavori e/o gli utenti smaliziati.
Beh il msg di ritorno arriva, c'č chi non lo legge e c'č chi lo legge e 
non lo capisce ma qui il discorso si allarga.
C'č anche chi non da nessuna spiegazione, esempio:
-----------
This is an automatically generated Delivery Status Notification.
Delivery to the following recipients failed.
 
xxxx...@hotmail.msn.com
-----------
E buonanotte ai suonatori...
-- 
Fa freddo nello scriptorium, il pollice mi duole. Lascio questa 
scrittura, non so per chi, non so piů intorno a che cosa...
U. Eco

 consegnare"...
Bingo. Se usassero codici di errori differenti per il generico "user not
found" e i "quota exceeded" e gli "spam filtered" io potrei prendere azioni
in maniera programmatica senza alcun problema. Non esiste più? fuori dalla
ML. quota? aspetta 4 invii e poi caccia fuori. spam? inviami una mail
ricopiando la spiegazione in calce che ci penso io a manina.



Vero concettualmente, ma in linea di massima per questi casi si cerca di
gestire tutto alla stessa stregua, dato che per le ragioni suddette
spesso non è possibile fare altrimenti.
Nel senso:
- se l'utente non esiste più, va rimosso.
- se l'utente dopo N invii (settimane? mesi?) ha sempre la mailbox
piena, presumibilmente non legge più quella mailbox. Va rimosso.
- se l'utente ha "comandato" il blocco dell'indirizzo da cui inviate, va
rimosso (non fosse altro che per l'implicita volontà di opt-out).
Potresti pensare che il tuo software di analisi dei bounce operi così in
modo che dopo N bounce consecutivi per l'utente, purghi l'utente dal
database di invio (quantomeno flaggandolo come non disponibile), e ti
invii notifica del fatto, riportandoti l'estratto del bounce con le
ragioni di blocco per tua interpretazione (eventualmente cacciando tutto
su un DB, in modo da rendere analisi e manipolazione di queste notifiche
più gestibile).
Se le ragioni di blocco sono del 3° tipo, valuti tu se contattare l'ESP
dove è applicato il blocco per avere dettagli.
Ai primi run di controllo bounce, probabilmente otterrai una sequela di
segnalazioni sulle quali dovrai indagare, ma una volta a regime il
numero di segnalazioni dovrebbe attestarsi a qualcosa di facilmente
gestibile...


 rimosso (non fosse altro che per l'implicita volontà di opt-out).
Qua invece non sono d'accordo. Se viene filtrata a livello SMTP (per spam) è
generalmente un servizio (o disservizio, vedi miei problemi con Hotmail su
INNA :P) del provider di cui l'utente può darsi che non sappia nulla. Qui
non c'è un solo caso, ci sono *molti* casi di clienti che si
lamentano "ehi, perchè non mi inviate più la newsletter?" dopo che erano
stati tolti dalla nostra lista per non far arrabbiare il provider sul tema
spam.


 INNA :P) del provider di cui l'utente può darsi che non sappia nulla.
Potrebbe anche essere un filtraggio ad SMTP-time comandato dall'utente e
relativo alla sua sola mailbox. Ci sono ESP che permettono
configurazioni di questo genere.
Chiaramente, se invece è un blocco applicato a tutti i destinatari sul
dominio/server destinazione, il discorso cambia.
Dal lato del bounce, però, non vi è nulla che ti permetta in modo
automatizzato di capire quale tra i due sia il caso che incontri, ecco
il perchè della notifica: poter indagare se qualcosa non torna...
Purtroppo, non vedo molte altre vie...
