Newsgroup: it.comp.os.linux.sys
Titolo: Controllo IP-dominio nei server di posta

Probabilmente non è il NG più adatto dato che la domanda non si riferisce
solo ai server sotto Linux ma a tutti i mail server in generale, ma non
saprei proprio su quale NG farla. Mettete il xpost e il f/up adeguato nel
caso voi lo sapeste.
In breve: qual'è secondo voi la percentuale di SMTP in giro che rifiutano
automaticamente tutte le mail provenienti da un dato dominio inviate però
da un IP che non risolve l'MX di quel dominio? Perchè qui in azienda
vorremmo affidarci al controllo antispam/antivirus di un fornitore esterno
(attualmente giriamo con SA e clamav), però epr far questo l'MX del dominio
deve passare necessariamente da loro. Il punto è però che ci sono delle
mail che non possiamo inviare attraverso di loro (mail automatiche a una
mailing list bella grande, si rifiutano di farle passare), per cui queste
mail le invieremmo direttamente noi, ma logicamente da una macchina della
nostra rete. Quali sono le possibilità che gli SMTP di destinazione
rifiutino le mail direttamente?
-- 
Vide

 ininfluente...
In effetti ci avevo pensato ma non ero sicuro al 100%...
-- 
Vide

 rifiutino le mail direttamente?
Con le modalità che descrivi, prossime allo 0... :-D
Per identificare la "validità" del server mittente, ci sono meccanismi
più complessi del semplice "vedi se è l'MX", per via di svariate ragioni.
Uno, ad esempio, è SPF (con tutti i pro e i contro del caso), che ti
invito ad approfondire, e che comunque va "tunato" per soddisfare le
esigenze cui deve ottemperare (ammesso lo si voglia davvero usare).
Piuttosto, se la vostra mail in uscita non è destinata a passare
attraverso il vostro fornitore ma ad andare direttamente ai destinatari,
assicuratevi di avere le cose configurate a modo:
- la macchina risolva con un nome "realistico" (tipo
miomailserver.dominio.tld, e non con roba fantasiosa tipo
hostxxyy.poolzzww.interbusiness.it
) sia in zona diretta che in zona
inversa (richiedendo la "sistemazione" di quest'ultima al tuo fornitore
di connettività)
- la macchina si presenti in HELO con lo stesso hostname con il quale
risolve, di cui al passo precedente
Inoltre, assicurati di usare per il mailserver un IP *diverso* da quello
usato per il NAT della rete interna (questo è piuttosto rilevante).
Se già vengono attuate queste banali pratiche (che sono comunque la base
di una configurazione appena decente), la probabilità di incorrere in
problemi di delivery è estremamente bassa.

 gli MX e quindi entrambi gli IP.
Rendendo pressochè completamente inutile qualsiasi filtraggio AS/AV
operato dal fornitore di cui sopra, dato che buona parte dello
spam/virus usa i record MX al contrario proprio per intortare chi usa
trucchi di questo genere...

 server li' ma inattivo.
Qualcuno li fa anche, questi giochini, anche se per altre ragioni: per
via della questione sopra descritta, aiuta ad "allentare" la pressione
dello spam sugli MX primari.
Tuttavia è una cosa che porta a qualche glitch nel caso di sistemi SMTP
mittenti scritti con le chiappe: in caso di difficoltà dell'MX primario
(per qualsiasi ragione) cercano di consegnare a questo secondario.
Poichè questo non risponde, reimmettono in coda, ma per le mail
reincodate riprovano in seguito, ma lo fanno solo in direzione del
secondario, senza tentare di ricontattare il primario.
Raro, ma visto accadere.
Francamente, la via più pulita rimane (IMHO) quella che dicevo prima...

 secondario, senza tentare di ricontattare il primario.
Io comunque il mio lo metterei come terzo: MX10 principale del provider
antispam, MX20 riserva dell'antispam e MX30 il mio.
-- 
Vide

 antispam, MX20 riserva dell'antispam e MX30 il mio.
Questo non sposta di molto il problema o la perplessità sollevata.
Se un host *non è destinato* a ricevere quanto destinato ad un dominio,
è scorretto elencarlo come record MX per lo stesso.
Se poi lo si vuol fare, si è comunque liberi di farlo, ma continuo a
ritenere la "soluzione" come minimo ininfluente per lo scenario che
disegni, e poco corretta dal punto di vista formale.

 disegni, e poco corretta dal punto di vista formale.
Ok però la soluzione che proponi (che l'SMTP che uso io per uscire
direttamente risolva bene e che faccia HELO con il nome con cui risolve)
presuppone solo aggiungere l'IP della macchina al campo NS (e non MX) del
DNS per il nome, chessò, 
mail.dominio.com
. Giusto?
-- 
Vide

 DNS per il nome, chessò, 
mail.dominio.com
. Giusto?
Credo che di 'sta frase non ho capito una mazza... ;-)
Se il server si chiama 
mail.dominio.com
, serve che sia definito un
adeguato record A per "mail" nella zona 
dominio.com
.
E serve che il provider (o chiunque detenga la zona inversa per
quell'IP) crei (o modifichi) il record PTR per quell'IP affinchè punti a
"
mail.dominio.com
".
Per fare un caso reale, ipotizzando si tratti del dominio 
bofhland.org
,
e che la macchina si chiami "mithrandir" (e quindi si presenti con HELO
pari a 
mithrandir.bofhland.org
), avrai:
$ dig a 
mithrandir.bofhland.org
; <<>> DiG 9.2.4 <<>> a 
mithrandir.bofhland.org
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30365
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 3
;; QUESTION SECTION:
;
mithrandir.bofhland.org
.       IN      A
;; ANSWER SECTION:
mithrandir.bofhland.org
. 86400  IN      A       147.123.72.14
[...]
nonchè:
$ dig ptr 14.72.123.147.in-addr.arpa
; <<>> DiG 9.2.4 <<>> ptr 14.72.123.147.in-addr.arpa
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4851
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 5, ADDITIONAL: 5
;; QUESTION SECTION:
;14.72.123.147.in-addr.arpa.    IN      PTR
;; ANSWER SECTION:
14.72.123.147.in-addr.arpa. 86400 IN    PTR     
mithrandir.bofhland.org
.
[...]

 adeguato record A per "mail" nella zona 
dominio.com
.
Scusa, mi son confuso e avevo scritto NS e non A. Allora avevo capito
giusto, a parte il PTR che non conoscevo. Grazie per le info, ora il DNS
comincia ad essermi un po' più chiaro :)
-- 
Vide