Newsgroup: it.comp.os.linux.sys
Titolo: exim e cname come mx record

ho il seguente problema, un cliente ha come mx recordo un cname.
so che cio è MALE, ma non posso farglielo cambiare.
exim rifiuta di consegnare la posta a questo dominio.
c'è un modo per abilitarlo?
esempio di errore:
2006-12-15 11:17:48 1GvA8S-0006Vt-CQ ** 
an...@dominio.com
:
all relevant MX records point to non-existent hosts
dig -t mx 
dominio.com
;; ANSWER SECTION:
dominio.com
.          38400   IN      MX      10 
mail.dominio.com
.
dig 
mail.dominio.com
;; QUESTION SECTION:
;
mail.dominio.com
.            IN      A
;; ANSWER SECTION:
mail.dominio.com
.     38400   IN      CNAME   
fer.dominio.com
.
fer.dominio.com
.      38400   IN      A       172.x.x.x

 
non per polemica, ho capito che è male.
ma siccome tutti gli altri mail server vanno col suo indirizzo, non c'è
modo di far andare anche exim?
perchè è esattamente la risposta che mi darà se gli dico di cambiare gli
mx record...

 mx record...
Con exim non saprei, perchè non lo uso.
Tuttavia, non è che "è male", è che "è sbagliato", fine.
La configurazione corretta di un DNS prevede che qualsiasi record
diverso da CNAME (quindi i record NS, MX, ecc) *deve* puntare ad un
record A e non ad un CNAME.
Configurazioni diverse sono errate, e il comportamento di chi sta
dall'altra parte diviene aleatorio in quanto dipendente solamente
dall'implementazione utilizzata da chi ha sviluppato il software, sulla
quale si può fare affidamento solo relativamente agli standard (esistono
per quello).
Se si vuole stare fuori dagli standard, si accettano le conseguenze,
compresi i malfunzionamenti.
-- 
Skull & Bones (ER6n Silver)
Neo:  I know Sendmail!
Morpheus:  Show me.

 record A e non ad un CNAME.
grazie a tutti x le risposte.
ho già chiesto al cliente di conformarsi. 
il problema è che 
http://www.zytrax.com/books/dns/ch8/cname.html
While use of CNAME RRs with NS and MX records is widely implemented and
generates a working configuration it is theoretically not permitted
(RFC 1034 section 3.6.2) since it can result in lost names.
quindi benchè sia teoricamente errato, è prassi diffusa
e avrei voluto risolvere il problema a livello di mail server, in modo
che non mi ricapiti in futuro. non ho voglia di questionare con i
clienti ANCHE per questo! (già sono abbastanza piantagrane...)

 clienti ANCHE per questo! (già sono abbastanza piantagrane...)
Male che vada, se proprio devi, risolvi con una transport, che passa
sopra alla risoluzione degli MX...
Però fare configurazioni ad-hoc per risolvere guai causati da cazzari
altrui IMHO non è prassi che porta lontano...


Mandi! cits
  In chel d? si favelave...
c> c'è un modo per abilitarlo?
Debian? Se si, usa hubbed_hosts per impostare un route esplicito, come
primo hack.
Poi guardati con calma la documentazione dei transport, sicuramente c'è
una opzione di override...
-- 
  M.C.S.E: Minesweeper Consultant & Solitaire Expert

 
ok così funziona, grazie.

 all relevant MX records point to non-existent hosts
Non e' un problema con il CNAME, exim consegnerebbe anche con una zona
configurata come quella. Prova a guardare che in "ignore_target_hosts"
tu non abbia anche la subnet a cui appartiene 172.x.x.x, che a naso mi
sa di rfc1918.
Fabio

 sa di rfc1918.
in effetti c'era. l'avevo già commentato, ma non basta.
ho dovuto mettere in hubbed_hosts:
dominio.com
: 172.16.16.7
per farlo andare.
anche se sento di aver aggirato il problema, non risolto.
è come se exim usasse altri dns non quelli in resolv.conf
#  ignore_target_hosts = 0.0.0.0 : 
127.0.0.0/8
 : 
192.168.0.0/16
 :\
#                        
172.16.0.0/12
 : 
10.0.0.0/8
 : 
169.254.0.0/16
 :\
#                       255.255.255.255
  ignore_target_hosts = 0.0.0.0 : 
127.0.0.0/8
 : 
192.168.0.0/16
 :\
 
10.0.0.0/8
 : 
169.254.0.0/16
 :\
                        255.255.255.255

 anche se sento di aver aggirato il problema, non risolto.
Si', infatti, con il tuo ignore_target_hosts attuale exim dovrebbe
consegnare. Quello che hai fatto e' di usare il MX come smarthost,
se indovino bene, il quale poi consegna... a se stesso. Ovviamente
funziona, ma l'ideale IMHO sarebbe capire dov'e' il problema. Puoi
provare a levare quella riga da hubbed_hosts e a fare un:
$ exim -d -bt 
mail...@dominio.com
Fabio



mi piace questa opzione (-bt) non l'avevo vista sul manuale (RTFM!!!!)
riporto sotto l'output, e grazie a quello ora ho capito.
l'errore era proprio quello segnalato :
mail server interno con indirizzo privato 172.16.16.7
elencato in ignore_target_hosts
l'avevo tolto, ma è rimasto il file di backup, ed exim leggeva quindi
due file di configurazione, uno con e uno senza 
172.16.0.0/12
R: dnslookup for 
ute...@dominio.com
calling dnslookup router
dnslookup router called for 
ute...@dominio.com
  domain = 
dominio.com
DNS lookup of 
dominio.com
 (MX) succeeded
DNS lookup of 
fer.dominio.com
 (AAAA) gave NO_DATA
returning DNS_NODATA
DNS lookup of 
fer.dominio.com
 (A) succeeded
172.16.16.7 in "0.0.0.0 : 
127.0.0.0/8
 : 
192.168.0.0/16
 :
172.16.0.0/12
 :
10.0.0.0/8
 : 
169.254.0.0/16
 :255.255.255.255"? yes (matched
"
172.16.0.0/12
") ignored host 
fer.dominio.com
 [172.16.16.7] fully
qualified name = 
dominio.com
 host_find_bydns yield = HOST_FIND_FAILED
(0); returned hosts: 
fer.dominio.com
 <null> MX=10 *
dnslookup router declined for 
ute...@dominio.com
"more" is false: skipping remaining routers
no more routers
ute...@dominio.com
 is undeliverable:
  all relevant MX records point to non-existent hosts
search_tidyup called