IIS / SMTP – le mail sono bloccate in mailroot / coda

Sto cercando di submit e-mail tramite SMTP nella directory di pickup IIS. Purtroppo le e-mail stanno semplicemente entrando nella cartella di posta / coda e rimangono lì. Non vengono mai inviati.

Qualcuno sa perché questo accadere e una soluzione potenziale per il problema?

  • vuoto EHLO da tutto il web, è un bot?
  • Semplice, solo inoltro MTA?
  • Come scoprire che il server SMTP è in open relay?
  • Postfix SASL con Dovecot e Authenticated Smarthost
  • Il server virtuale SMTP si arresta al riavvio
  • Come configurare sendmail per rifiutare la posta elettronica con un'intestazione Data troppo lontana dal tempo reale?
  • Postfix non invia e-mail, riceve solo
  • Impostazione di chiavi di dominio di Yahoo, ottenendo dkim = permerror (nessun tasto)
  • 12 Solutions collect form web for “IIS / SMTP – le mail sono bloccate in mailroot / coda”

    Aveva un problema simile con File bloccati nella coda. In Gestione IIS, Server virtuale SMTP> Proprietà> Delievery> Connessioni in output. L'opzione per Limit number of connections to stata selezionata e il valore è stato 0 . Così è stato configurato per non fare mai nessuna connessione in output, causando che le email non lasciano mai il server. Ho annullato l'opzione e ho riavviato il server SMTP e tutto è andato bene.

    Ho avuto questo problema oggi.

    Dopo aver riavviato il servizio 'Simple Mail Transfer Protocol (SMTP)', esso ha ripreso a funzionare.

    Solo per il record: abbiamo avuto un caso in cui il server non poteva più risolvere i nomi a causa di una configuration DNS diversa. Il comportmento risultante era esattamente quello descritto.

    Nella mia esperienza, questo è di solito dovuto a IIS SMTP che cerca di submit e di incontrare un errore temporaneo (codice di risposta 4xx). Hai triggersto la logging per il servizio SMTP di IIS e ha esaminato il registro? Scusate se è tutto ovvio, ma è difficile conoscere la causa o la correzione senza sapere che cosa mostra il registro.

    Penso che il problema potrebbe essere che ci sia una confusione tra IPv4 e IPv6 sul sistema, quindi quando si specifica localhost, viene scelto il protocollo IPv6 predefinito. Oggi ho avuto lo stesso problema ed è stato risolto dopo che il riferimento localhost all'indirizzo IPv6 negli host è stato eliminato, anche se questo potrebbe essere stato una coincidenza (sto anche impostando SVN). Quindi ecco la mia configuration proprio nel caso in cui:

    1. In IIS7 ho l'opzione "Consegna al server SMTP" abilitata con localhost come mio server scelto.
    2. In IIS6 ho accesso impostato a solo 127.0.0.1, nessuna authentication per l'ingresso o l'output.

    Ho guardato le impostazioni tutto il giorno, quindi, per essere onesti, non so cosa altro avrebbe potuto influenzare il fatto che sta lavorando adesso. Spero che questo aiuti alless un po 'però.

    Il primo posto da guardare è il file di registro del server. Questo ti dirà se il tuo server ha problemi a submit a host specifici. La maggior parte del tempo questo accade (nelle mie esperienze) è solitamente DNS (sia sulla tua estremità che in remoto) che è il colpevole.

    Il server SMTP sta cercando un host / gateway SMTP per submit la posta.

    Se si sta tentando di submit a localhost, l'IP localhost sarebbe il gateway. Se si sta tentando di submit a un indirizzo di posta elettronica esterno come gmail o hotmail, è necessario aggiungere il gateway di posta elettronica dell'ISP come host intelligente.

    Per impostare un host intelligente:

    1. In Gestione IIS, fare clic con il button destro del mouse sul server virtuale SMTP e quindi scegliere Proprietà.
    2. Fai clic sulla scheda di consegna e fai clic su Avanzate.
    3. Nella casella host intelligente, digitare il nome del server host intelligente. È ansible digitare una string per rappresentare un nome o immettere un indirizzo IP.
    4. Se si desidera che il servizio SMTP tenti di submit i messaggi remoti direttamente prima di inoltrarli al server host intelligente, select la casella di controllo Invio diretto prima di submit alla casella di controllo intelligente. L'impostazione predefinita è submit tutti i messaggi remoti all'host smart, per non tentare la distribuzione diretta.

    Ho avuto lo stesso problema dopo aver commutato il servizio di posta elettronica da un host all'altro (nuovo è Office 365). Dopo un sacco di prove ed errori, finalmente ha iniziato a lavorare facendo questo:

    1. Aggiungere il dominio di posta elettronica a IIS 6 come un dominio "remoto". (Questo è il dominio ospitato in O365 e tutti gli account utente utilizzano.)
    2. In IIS 6, fare doppio clic su quel dominio; sotto "Dominio di path" select "Inoltra tutta la posta a un host intelligente" e inserisci il tuo server (nel mio caso, "smtp.office365.com"). Inoltre, seleziona la casella "Consenti che la posta in arrivo venga inoltrata a questo dominio".
    3. In IIS 6, fare clic con il button destro del mouse sul server virtuale SMTP> Proprietà.
      • Scheda Generale: Fare clic su Avanzate e aggiungere l'IP del server locale e la port 587
      • Scheda Accesso: assicuratevi che "Richiedi la codifica TLS" sia selezionata. Ho dovuto creare un cert di dominio in IIS 7 con il nome del mio dominio email.
      • Scheda di accesso: aggiungere l'IP del server locale agli elenchi "Connessione" e "Relay".
      • Scheda di consegna: Protezione in output: select l'authentication di base, immettere credenziali di un utente autorizzato valido; select la casella per "crittografia TLS"
      • Scheda Consegna: Connessioni in output: Immettere 587 per la port TCP
      • Scheda consegna: Avanzate: Inserisci il dominio email come "Nome dominio completo" e il tuo server di posta elettronica come "Host intelligente" (ancora nel mio caso smtp.office365.com).

    Firewall: Ho letto che devi aprire la port 587 per l'output. (Non ho fatto perché questo è un server VOIP che ha bisogno del suo firewall.)

    Office 365: aggiungi un "connettore" in Amministrazione> Exchange per consentire l'IP statico locale. Microsoft fornisce queste istruzioni in linea.

    IISRESET ha fissato questo per me. Credo che sia simile alla soluzione di reimpostazione del servizio SMTP poiché questo servizio dipende da IIS. Dopo aver riavviato la posta all'interno di C: \ inetpub \ mailroot \ Queue ha iniziato a scomparire!

    Recentemente ha affrontato questo problema. Qualcuno aveva installato MalwareBytes sul server smtp e le cartelle smtp mailroot non sono state elenchiate in licenza. Il software ha trattato tutto nella coda come una potenziale campagna di spam e lasciò che tempo abbastanza tempo che si è trasferito in badmail. Tutti i domini sono stati colpiti. Mi avevo perplesso (operazione impeccabile da anni …) finché non guardavo i processi in esecuzione e notai l'exe di mbam.

    Recentemente ho incontrato questo problema. Nel mio caso, si è rivelato un problema con la definizione del server DNS in una scheda di networking (questo ha due per qualche motivo non conosciuto a me). Il server DNS designato è stato impostato su "127.0.0.1" invece del normale "8.8.8.8" normalmente utilizzato in questa networking. Ho cambiato questo valore al valore corretto, ho riavviato il mio server SMTP e le email in coda sono state distribuite immediatamente.

    Come ho capito che esaminare la questione della definizione DNS:

    • Usato nslookup per trovare un server mx da testare (testato 5 o 6 diversi)
    • Provato a telnet al server (each volta che si incontrava con un messaggio "non poteva connettere" che mi ha fatto inizialmente pensare ai problemi del firewall)
    • Provato a ping il valore per il server mx testato (each volta che si incontrava con un messaggio "non poteva connettersi all'host")

    Speriamo che questo aiuterà qualcun altro, non era qualcosa che avrei pensato a guardare inizialmente.

    Ho avuto la stessa questione. Come altri affermano che era relativo DNS. Ho una zona di ricerca avanzata nei nostri server DNS interni per il nostro nome di dominio pubblico (diverso dal nostro nome di dominio interno). Dovevo aggiungere i record MX in questa zona di ricerca interna per corrispondere ai record MX nei record DNS di dominio pubblico. Questo ha risolto il problema.

    Suggerimenti per Linux e Windows Server, quali Ubuntu, Centos, Apache, Nginx, Debian e argomenti di rete.