Domanda

Quando sto creando un utente per la mia applicazione web, SMTP e-mail (utilizzando ASP.NET's SmtpClient) viene inviato all'utente con il password generata automaticamente.A volte, tuttavia, quello che ho notato è che va in time out e il nuovo utente semplicemente non ricevere la mail con la password.

Bene, quindi mi visualizza un messaggio che indica che la posta non passare attraverso, ma l'utente viene creato.

Pertanto, il sys admin ha 2 opzioni finora:

  1. Reimpostare la password per l'utente e la speranza di un altro SMTP mail viene inviata con la password generata automaticamente.
  2. Eliminare e ricreare l'utente.

Ho potuto eseguire il rollback di creazione dell'utente se l'smtp non viene inviato, ma che cosa è la pratica migliore per affrontare questo problema?

Sto pensando che dovrei riprovare a inviare l'e-mail per 3 volte con un periodo di timeout di 5 secondi ciascuno.Quindi 15 secondi sarebbe il peggiore scenario possibile.

È questa la strada da percorrere?

È stato utile?

Soluzione

Beh, a seconda della piattaforma, se si può solo consegnare la posta a un MTA locale, deve gestire i tentativi e così via.Il programma può solo queue la posta e andare avanti, di non preoccuparsi di trattare con i timeout e graylists etc.

Se il messaggio non può essere consegnato, si può sempre provare a inviare di nuovo (tramite una funzione di reimpostazione della password).Se non funziona così, probabilmente c'è stato un errore nell'indirizzo e-mail, e vorrei suggerire di eliminare l'account, causando l'utente a registrarsi nuovamente.

Questo, naturalmente, potrebbe non essere possibile in alcuni sistemi, a seconda di ciò che può essere fatto con un utente non confermato - che in realtà dipende da ciò che si permettono di fare prima di loro e-mail viene convalidato.

Altri suggerimenti

Sembra che la tua web app è parlare SMTP direttamente al tuo server di posta.[Web app è un MUA (Mail User Agent) parlando dell'utente MTA (Mail Transfer Agent).] Nulla dice che l'utente MTA deve essere raggiungibile o di lavoro al momento.È necessario eseguire il vostro proprio MTA modo si garantisce che qualcuno sta fornendo queueing, tentativi, etc.

Se si vuole veramente a piegarsi all'indietro, si potrebbe fare quello che stai facendo (solo un tentativo, però), di riserva in coda il messaggio e continuare a riprova più di pianificazione per almeno 24 ore, e di esporre incompiuto di stato per l'utente.

La risposta ufficiale su come la vostra app dovrebbe comportarsi può essere trovato in RFC1123 (Requisiti per l'Host di Internet - Applicazione e di Supporto):

5.3.1.1 L'Invio Di Strategia

Il modello generale di un mittente SMTP è uno o più processi che periodicamente tenta di trasmettere la posta in uscita.In un sistema tipico, il programma che compone un messaggio ha qualche metodo per la richiesta di l'attenzione immediata per un nuovo pezzo di per la posta in uscita, mentre la posta che non può immediatamente trasmessi DEVONO essere in coda e periodicamente ripetuta dal mittente.Una coda di posta di voce includono non solo il messaggio stesso ma anche le informazioni della busta.

Il mittente DEVE ritardo di ritentare un particolare destinazione dopo un il tentativo non è riuscito.In generale, il riprova intervallo DEVE essere di almeno 30 minuti;tuttavia, più sofisticato e variabile strategie utile quando il mittente SMTP può determinare il motivo per non la consegna.

Tentativi di continuare fino a quando il messaggio è trasmessi o il mittente dà;il tempo di give-up in genere ha bisogno di essere almeno 4-5 giorni.I parametri per l'algoritmo di ripetizione DEVE essere configurabile.

Se si sta utilizzando ASP.NET e il Sistema.Net.Posta le classi, si sono probabilmente l'invio di posta elettronica tramite l'istanza di IIS sul computer del server web (non so da quando non specificato).Non c'è un buon modo per sapere che cosa sta succedendo con il vostro Agente di Trasferimento della Posta (SMTP di IIS).Essa ha la sua propria logica di tentativi, e per impostazione predefinita, si può prendere un lungo periodo di tempo per il recapito del messaggio.

Come si rileva che la mail non è stata recapitata?Qual è il "timeout" provenienti da?

Si dovrebbe avere un processo in background che gestisce l'invio delle mail.Se la consegna all'agente di trasferimento messaggi di esito positivo, si deve presumere tutto bene.A meno che non sei nella lista nera per SPAM, più Mta verranno mantenere ripetizione fino a quando essi ottenere attraverso.Se si ottiene effettivamente un errore far cadere il messaggio con MTA, quindi sicuramente riprovare, o capire che cosa sta causando il fallimento e correggere i bug.Onestamente, questa parte dovrebbe mai mancare.

Si potrebbe desiderare di monitorare l'indirizzo di ritorno per mancato recapito dei messaggi, in modo che si può prendere qualche tipo di azione quando si sa con certezza quando il messaggio non è stato recapitato.Ma se l'utente non può ancora accedere al sistema, c'è un buon modo per far loro sapere che cosa è successo.Forse si potrebbe impostare un cookie con un valore che è associato con l'e-mail, e mettere qualcosa sul login/registrazione pagina, se non sono stati in grado di consegnare la posta.

IMHO si dovrebbe informare l'utente, chiedendogli di verificare l'email, senza tentativi.

Se l'utente non consente di verificare l'e-mail e lascia la pagina, è meglio ripristinare l'account in quanto l'utente non può accedere comunque.

La maggior parte dei casi di timeout potrebbe essere causato da invalid account di posta elettronica.Gli utenti sia fatto un errore o ti ha dato un inesistenti e-mail addressto evitare di essere spam.

Se possibile, non chiedere per gli utenti e-mail.L'regola numero uno della programmazione deve essere:NON infastidire l'utente.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top