Come configuro SPF per più domini su un server? (anche consentire a gmail come mittente)


9

SPF (Sender Policy Framework) sembra un buon modo per combattere gli spammer / spoofing.

Tuttavia, nonostante abbia letto più volte le spiegazioni, non capisco bene come configurarlo correttamente.


Diciamo che ho il mio assistente a a.x.comquali host www.x.come b.x.comed c.x.come così via.

Ho anche a.co.uk b.net c.infoe così via, ognuno di questi con un assortimento di sottodomini, tutti ospitati sux.com

Per tutti questi domini e sottodomini, desidero consentire l'invio della posta a.x.com

Vorrei anche che tutti consentissero la posta inviata da Gmail per tutti questi domini.

Come lo configuro con SPF?

Posso impostare un record SPF per x.com(o a.x.com) e poi per tutto il resto ho solo un semplice include / pointer al x.comrecord, o dovrebbe essere fatto diversamente?

Qualcuno può fornire alcuni record SPF per l'esempio sopra?


Nota: alla seconda parte della mia domanda è stata data risposta (usa " v=spf1 include:x.com -all" per includere / punto nel x.comrecord), ma la parte chiave di cosa impostare x.comrimane senza risposta ...


In realtà si è rivelato un modo irrimediabilmente inefficace per ridurre lo spam. In realtà, probabilmente, è destinato solo a indirizzare lo spoofing dell'indirizzo del mittente comunque.
Christopher Edwards,

2
"serve solo per indirizzare lo spoofing dell'indirizzo del mittente", esattamente per impedire agli spammer di inviare posta che sembra provenire da domini altrui.
Peter Boughton,

Risposte:


7

Non puoi evitare di dover modificare i file di zona per i domini diversi da x.com, ma puoi evitare molti problemi definendo criteri comuni ospitati su un dominio e utilizzando la redirectparola chiave SPF sugli altri domini. Esempio:

  • Nel file zone per il x.comdominio:
_policy1 IN TXT "v = spf1 a: axcom -all"
_policy2 IN TXT "v = spf1 include: _spf.google.com a: axcom -all"

_spf.google.comè il record che contiene il record SPF di Gmail. Non sono sicuro che sia documentato. Teoricamente dovresti include:gmail.comma è un reindirizzamento a _spf.google.come c'è stata almeno una patch SPF ampiamente usata per qmail che non l'ha seguita correttamente (è stata riparata nell'agosto 2008 ma potrebbe comunque essere distribuita). Le due politiche sono esempi, ovviamente - avere più di uno con vari livelli di rigore è estremamente utile durante il debug poiché devi solo modificare un nome breve nel dominio di destinazione invece del copypasting soggetto a errori.

  • Nei file di zona per gli altri domini:
@ IN TXT "v = reindirizzamento spf1 = _policy1.x.com"

o

@ IN TXT "v = reindirizzamento spf1 = _policy2.x.com"

ecc. non sto usando redirect, includeper fare in modo che il controllo SPF sostituisca completamente il record attualmente valutato con quello a cui sto reindirizzando. includenon lo fa - per esempio, un -allalla fine di un includenon provoca l'interruzione della valutazione ( includeè un termine improprio). Dovresti evitare di usare includequando vuoi "alias" un record SPF da un altro dominio, poiché è piuttosto fragile - se dimentichi accidentalmente il trailing -all potresti rendere inefficace l'intero SPF su quel dominio.

Modifica: tieni presente, tuttavia, che devi essere in guardia se desideri consentire i server di Gmail come mittenti. Il chaptcha di Gmail è stato crackato, il che significa che è possibile automatizzare le registrazioni degli account, il che significa che Gmail può essere (indirettamente) utilizzato come relay aperto (ricevo decine di richieste di iscrizione spambot a settimana per il forum di discussione della mia azienda, tutto usando indirizzi e-mail di gmail.com - e quegli indirizzi sono attivi, ne ho concessi alcuni a scopo di verifica.) Inoltre, chiunque abbia un account Gmail può ignorare il controllo SPF se ha familiarità con le parti uwsername degli indirizzi e-mail nei tuoi domini .


Grazie, questa è una risposta utile. L'ultima volta che ho verificato, Gmail richiede la convalida dell'e-mail prima di poter inviare e-mail da altri indirizzi, quindi una volta che la posta in arrivo per quell'indirizzo è sicura, le cose vanno bene? Quanto è importante / non è presente anche la riga "www" come nella risposta di bortzmeyer?
Peter Boughton,

1
È vero, ma una volta che appare una crepa nel foudation, sono sicuro che qualcuno troverà un modo per spremere mezzo fiume attraverso :) Non dicendo che non dovresti, sto solo raccomandando di essere in guardia e controllare periodicamente se Gmail è essere sfruttato, vale a dire, per favore, non abbandonare indefinitamente l'autorizzazione a Gmail. Mi fido di loro più di quanto mi fidi di più entità online, ma è solo un po 'di fiducia rispetto a nessuna fiducia.
Mihai Limbăşan,

Non ho idea del perché bortzmeyer includesse le voci www. Sono del tutto inutili a meno che tu non invii effettivamente posta da @ www.x.com che (a parte il fatto di non essere usato molto) sembra strano e induce confusione in persone meno esperte dal punto di vista tecnico.
Mihai Limbăşan,

2
Inoltre, NON utilizzerei i tipi di record SPF. Ti consiglio di restare con TXT. Il tipo di record SPF è supportato solo da BIND 9.4 e versioni successive, per RFC è necessario mantenere anche le repliche dei record TXT, vale a dire che è necessario copiare cose (non valide) e mantenerle sincronizzate (hard). Il guadagno è inesistente poiché TXT sarà il principale meccanismo di consegna SPF per il prossimo futuro, spiega openspf.org.
Mihai Limbăşan,

1
@Mihai Limbasan: ottima risposta, grazie per la condivisione. Nel caso in cui ritieni che sia necessario aggiornare la tua risposta, Google sembra preferire v=spf1 include:_spf.google.com ~allal posto di -all, supponendo che abbia capito bene, rif. google.com/support/a/bin/answer.py?answer=178723
Marco Demaio

4

Sì, puoi includere la configurazione di uno dei tuoi domini nei record SPF per tutti gli altri domini. L'impostazione del record SPF degli altri domini su quanto segue dovrebbe fare il trucco:

v=spf1 include:x.com -all

Questo "funzionerà" o richiede un sottodominio _spf o simile?
Peter Boughton,

Sono abbastanza sicuro che se inizialmente hai i record SPF definiti direttamente su x.com, l'inclusione per gli altri domini può puntare direttamente anche su x.com. Se definisci il tuo record SPF nel percorso _spf.x.com, allora sì, dovrai cambiare un po 'l'inclusione per puntare anche a quel nome FQDN.
womble

2

Hai provato a utilizzare lo strumento Web all'indirizzo http://www.openspf.org/ ? Potrebbe renderti un po 'più facile gestire questo ...

Inserisci il tuo dominio nella casella in alto a destra e fai clic sul pulsante Vai. Da lì, dovresti essere in grado di sistemare le cose in fretta.


1
Ho provato diverse volte con quello strumento, ma le spiegazioni non sono abbastanza chiare.
Peter Boughton,

2

Lo standard, RFC 4408 , fornisce alcuni esempi molto vicini a ciò che si desidera. Ecco un estratto del file di zona di x.com:

@ IN TXT "v = spf1 a: axcom -all"
      IN SPF "v = spf1 a: axcom -all"

www IN TXT "v = spf1 a: axcom -all"
      IN SPF "v = spf1 a: axcom -all"

Appunti:

  • Non ho aggiunto server di posta Gmail perché non li conosco, chiedi alle persone di Gmail
  • 'a' è di 'indirizzo' (è non è un record DNS A, comprende IPv6)
  • Ho aggiunto i record SPF, per RFC, sebbene quasi tutte le implementazioni utilizzino solo il record TXT

1

Sì, è necessario aggiungere il record SPF specifico a ciascun dominio singolarmente.

Il motivo è che l'unico (utile) tipo di record di aliasing nel DNS è il CNAMErecord. Tuttavia, il CNAMErecord fa sì che si verifichi l'aliasing per TUTTI i tipi di RR in un RRset - non c'è modo di dire " CNAMEil record SPF ma non i MXrecord "


Capisco che dovrò aggiungere un record SPF per ogni dominio, ma speravo semplicemente di memorizzare un semplice puntatore al dominio principale, dove possono vivere tutti i comandi più complessi. Womble suggerisce che posso usare include: {domain} per questo, ma non sono ancora chiaro se questo includa semplicemente / punti nei record SPF per l'altro dominio o se devo ospitare un sottodominio _spf.x.com?
Peter Boughton,

sì, vedi la risposta di Womble
Alnitak,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.