Perché Postfix accetta MAIL FROM da un'email che non è responsabile

Sto testando un'installazione postfix. Ho notato che se cerco di submit la posta da un account fittizio in un altro dominio che non è mio ( unknown@NotMyDomain.com ), a uno dei miei utenti locali ( user@MyDomain.com ), l'email viene ancora consegnata al mio utente.

 MAIL FROM:<unknown@notmydomain.com> RCPT TO:<user@mydomain.com> 

Non sono sicuro se questo è un comportmento normale o se può causare problemi. Ad esempio, sono preoccupato che gli utenti potrebbero utilizzare il server per submit messaggi di posta elettronica spoofati che non sono realmente originati dagli account di posta elettronica che pnetworkingndono di essere originari.

  • Cosa mi dice postfix con questo errore: avviso: connetti #n al sottosistema privato / proxymap: connessione rifiutata
  • È necessario un record MX?
  • Come posso ridurre i danni dei conti di posta rubati?
  • Come posso distriggersre l'invio di posta tramite smtp postfix con out auth?
  • Che cosa succede di solito ad un messaggio quando il server restituisce l'errore SMTP 550?
  • Come posso impostare in sicurezza i parametri di configuration di Postfix * Restrictions con i whitelist e blacklist?
  • PS Sono ancora nelle prime fasi di apprendimento postfix, quindi non so se la mia domanda ha senso.


    Come per il commento di @ DerfK, ho testato un relay aperto (where entrambi MAIL FROM e RCPT TO non sono ospitati su questo server) e questo è quello che ottengo. Per qualche motivo accetta l' RCPT TO , quindi dice addio DOPO che ho digitato il sobject. Così è questo bene o male?

     HELO test.mydomain.com 250 mail MAIL FROM:<user@notmydomain1.com> 250 2.1.0 Ok RCPT TO:<user@notmydomain2.com> 250 2.1.5 Ok Subject: testing for open relay 221 2.7.0 Error: I can break rules, too. Goodbye. Connection closed by foreign host. 

    4 Solutions collect form web for “Perché Postfix accetta MAIL FROM da un'email che non è responsabile”

    Questo è un comportmento normale. Altri server SMTP si connettono ai tuoi clienti come client SMTP per consegnare la posta al dominio.

    Per aggirare questo problema di spoofing, ci sono SPF e DKIM. Dovresti controllarli.

    Per quanto riguarda la prima situazione: è normale che il server SMTP accetti la posta per gli account di cui è responsabile e fondamentalmente è come funziona, è sufficiente configurare il software per la verifica dello spam, come SpamAssassin (la soluzione più ampia, support il controllo SPF / DKIM).

    Per quanto riguarda probabilmente la tua domanda nella fase iniziale della configuration del server di posta, ecco alcuni suggerimenti relativi alla gestione di posta fittizia.

    Gli utenti normali non provano a diffondere le loro e-mail nella maggior parte dei casi. Più spesso questo è il comportmento dello spammer e per questo motivo è ansible filtrare tale posta in base al suo contenuto. Un setup più complesso può includere:

    1. Controllo RBL / DNSBL / RHSBL (può dare tanti falsi rifiuti perché molti dei mittenti di posta anche validi rompono alcuni RFC).
    2. Verifica indirizzo indirizzo (vedi Verifica indirizzo readme per Postfix). Questo potrebbe anche rifiutare alcune delle mail valide (fondamentalmente ancora una volta a causa di una configuration errata, ad esempio smettere di posta con MAIL FROM: <> ).
    3. Greylisting . Per quanto riguarda la mia esperienza personale, questo combatta fino al 90% delle mail spam a causa dell'impazienza degli spammer. Ma questo rallenta la consegna di posta valida un po 'tuttavia questo non è un problema nella maggior parte dei casi.
    4. Verifica SPF / DKIM (anche se non obbligatoria per sostenerla).
    5. Vari test di contenuti personalizzati (inclusi gli spamcheckers già citati).

    Se si parla di postfix, essa fornisce capacità piuttosto flessibili per limitare la posta accettata.

    Per quanto riguarda il tuo aggiornamento: il postfix di messaggio di errore ti dà solo l'indicazione che si rompono le specifiche SMTP (non esiste un command SMTP, vedere SMTP RFC ma l'intestazione di Subject si è probabilmente significato è parte del corpo del messaggio che deve essere fornito dopo il command DATA SMTP ). Dalla transcrizione che hai fornito, non posso affermare in modo affidabile se il tuo postfix funzioni come open relay perché non esiste alcuna informazione sul client che ha avuto la session SMTP.

    Con il postfix di base di installazione, per quanto mi ricordo, consente la trasmissione della posta (che significa che puoi specificare qualsiasi indirizzo email, non solo nel dominio per cui è responsabile il postfix) da:

    • localhost
    • reti affidabili (impostate tramite mynetworks)

    Quindi, se hai installato postfix dal server in esecuzione, questo potrebbe essere ok. Se da qualsiasi parte di Internet, le cose sono male.

    Inoltre si potrebbe desiderare di leggere attentamente SMTPD Relay e il controllo di accesso per approfondire le conoscenze esattamente in tema di accesso postfix relè.

    Spero che questo ti aiuti.

    Hai dimenticato i dati! Ho avuto esattamente questo problema. È necessario disporre di dati di command, quindi sobject. Così risolve i tuoi problemi. Assomiglia a questo:

     HELO test.mydomain.com 250 mail MAIL FROM:<user@notmydomain1.com> 250 2.1.0 Ok RCPT TO:<user@notmydomain2.com> 250 2.1.5 Ok Data 354 End data with <CR><LF>.<CR><LF> subject: hello i love you, oh my god! Why do i forget data . 250 2.0.0 Ok: queued as E10601E09B1 quit 

    Postfix deve accettare la posta da domini che non è responsabile. Altrimenti si avrebbe solo email locali.

    Un relè aperto accetta posta da domini che non è responsabile per indirizzi non è responsabile. Nella seguente tabella: Il locale rappresenta i domini che la sever è responsabile; Remote rappresenta i domini che il server non è responsabile; e None rappresenta un mittente vuoto:

     Source Destination Accepted ====== =========== ======== Local Local Yes Local Remote Yes Remote Local Yes Remote Remote NO None Local Yes None Remote NO 

    Esistono molti modi per verificare il dominio remoto, tra cui: callout, SPF, DMARC, whitelist e blacklists. Questi tutti dipendono dal DNS. Greylisting è una tecnica per assicurare che un vero e-mail server invia la posta piuttosto che uno spambot. Spam filtri come un Spamassassin utilizzano una combinazione di tecniche per validationre la posta che di solito include il punteggio dei test sopra citati, nonché dei contenuti e delle intestazioni.

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