Come leggere il rapporto antispam "MS ForeFront" nell'intestazione di posta elettronica?

Sto provando a diagnosticare perché i messaggi di posta elettronica che invio dalla cartella di pickup SMTP di IIS del server vengono rimandati occasionalmente.

Una tecnologia da una società di ricezione che non ha potuto ricevere le email ha detto:

The email would go through if you could configure your server to use <servername>.<domain>.<tld> instead of just <servername> 

Ho navigato al seguente posto in IIS:

  • Internet Information Services
    • myservername (computer locale)
      • Server virtuale SMTP predefinito
        • domini

Una volta lì, vedo che posso rinominare il nome di dominio per essere tutto ciò che voglio. Lo ho fatto, ma ora sto cercando di capire se è sufficiente.

Una volta inviato un'email di prova, ecco la relazione antispam che vedo da gmail, ad esempio:

 X-Forefront-Antispam-Report: CIP:<server ip>; KIP:(null); UIP:(null); IPVD:NLI; H:<server name>; RD:<server name>.<domain>.<tld>; EFVD:NLI 

Sto cercando di capire cosa significhi questo, quindi so di averlo configurato correttamente. Qual è la differenza tra H e RD ? C'è qualche tipo di documentazione di ForeFront Antispam che descrive quali significano i diversi codici?

  • La creazione di SMTP greylisting a) interrompere molto spam e b) fermare la posta legittima?
  • Windows 2003 Server IIS SMTP Invio di SPAM
  • Tutta la posta esterna a Office 365 non è SPF, contrassegnata come junk da EOP in una distribuzione ibrida
  • Come filtrare correttamente l'e-mail in output?
  • Come posso attirare più Spammers che colpiscono le mie trappole di Spam?
  • Firma di più domini con singola chiave di dominio (dk-filter)
  • Postfix limite totale inviato all'ora
  • Elimina da mailq where il sobject corrisponde
  • 2 Solutions collect form web for “Come leggere il rapporto antispam "MS ForeFront" nell'intestazione di posta elettronica?”

    • "H:" è il nome host – il nome assegnato al server
    • "RD:" sembra essere il nome dominio completamente qualificato (FQDN)

    Ciò è in realtà più di una situazione di configuration del server SMTP su come il server sta "annunciando" se stesso agli altri server quando trattano sessioni SMTP. Semplicemente è "ForeFront" il tuo sistema che in ultima analisi "collega" con i sisthemes esterni SMTP.

    Il problema principale che si sta verificando qui (con spam o SMTP bounceback) sarà che il server da cui stai inviando la posta non è un server SMTP Internet e quindi non dispone di alcuna logging corretta di posta registrata contro di essa qualcuno fa una ricerca DNS e ricerca inversa IP.

    Purtroppo, la maggior parte dei server SMTP riesce a ricomprendere tutti i server SMTP che l'e-mail è passata prima di averla ricevuta e se nessuno di essi non controlla come "legittimo", negerà e rilascerà o rimbalzerà l'email.

    Guarda qualcosa come SPF: http://www.google.co.nz/search?sourceid=chrome&ie=UTF-8&q=spf

    Oppure potrebbe essere una buona idea avere il server di origine non submit e-mail e utilizzare un server SMTP correttamente configurato nell'organizzazione come Exchange o un provider esterno SMTP che ti consente di submit.

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