Newsgroup: it.comp.os.linux.sys
Titolo: Postfix + Domini Virtuali

Ciao a tutti,
ho un quesito da sottoporvi...
Ho un mail server con sopra postfix e con hostname 
mail.pippo.com
.
L'ho configurato per la gestione di più domini virtuali e tutto funziona 
regolarmente.
Il problema nasce dal fatto che inviando posta da un dominio virtuale 
(ad es. 
pluto.com
), nelle intestazioni della mail, appare sempre 
l'hostname 
mail.pippo.com
Ora, un cliente un pò più esigente potrebbe non volere che appaia il 
dominio 
pippo.com
 nelle sue email...
Il mio quesito perciò è il seguente:
esiste una qualche configurazione di postfix che permetta di 
differenziare l'hostname in base al dominio del mittente?
Ho cercato tra le varie opzioni di postfix, ma non ho trovato nulla che 
mi aiutasse.
Spero di essermi spiegato bene e ringrazio in anticipo per gli eventuali 
suggerimenti.
--
Gabriele

Gabriele <g.fra...@INVALIDgmail.com> wrote in news:fi6pcq$6vu$1
@
newsread.albacom.net
:

non so se l'opzione c'è, ma imho avrebbe comunque poco senso.
un cliente che guarda questi 'dettagli', non è un cliente esigente, è uno 
scassa palle...
se il cliente vuole vedere il nome dns del suo host nelle email che 
spedisce, paga l'hosting/housing di un server dedicato. punto.
anche perchè se fai riscrivere gli header per inserire in tutte le email il 
nome server del mittente, cosa succede se non esiste la entry dns?
se hai in gestione 500 domini crei anche 500 alias dns per il tuo server 
mail?
se non mantieni questo listone spropositato, se qualche blacklist verifica 
il reverse, sei bello che fregato.
e poi, dai in pasto a postfix una lista di domini per cui riscrivere e una 
dei domini per cui non riscrivere?
e il carico sul sistema per leggere tutti gli header di tutte le email e 
confrontarle con le due liste?
se il numero dei domini sale, la lista chi la mantiene?
e le entry dns?
io configurerei piuttosto il mail server 'generale' con un nome il più 
possibile generico, chiaramente riconducibile al fornitore del servizio, in 
modo che i clienti che per qualsiasi sfigato motivo lo leggono, lo trovino 
'familiare' (somiglia tanto a quello che leggo sulle fatture!) e non si 
facciano venire idee strampalate...
suggerimento?
se te l'hanno chiesto, inizia a parlare 'tennico' cercando di fargli capire 
che è una caxxata.
se t'è venuto in mente dopo una peperonata o un'impepata di cozze... un 
litro di digestivo e lascia perdere...
-- 
Paolo opg
BE AWARE that this post uses a fake reply-to address
to contact me write to:
janickg ( at ) hotmail ( dot ) com
--

Paolo opg ha scritto:


Innanzi tutto grazie per la risposta.
Devo dire che mi trovo perfettamente d'accordo con la tua analisi e 
fosse stato per me manco c'avrei mai pensato, ma siccome la questione mi 
è stata posta, non da un cliente, ma da un collega programmatore e un pò 
rompiscatole, a cui avevo risposto istintivamente "Ma chi cazzo si mette 
a vedere gli headers delle email?", volevo più che altro avere una 
conferma sulla difficoltà e sull'inutilità della cosa...
Ciao!

non č inutile, metti che vuoi fare da rivendita di domini, dove ti 
presenti con il tuo dominio "master" negli header. l'osservazione 
potrebbe avere dei suoi perchč.
prova a cercare se con procmail puoi riscrivere qeui campi, mi sembra 
tempo fa di aver trovato della documentazione in merito.
Il discorso economico sugli host dedicati non l' ho capito, qui stiamo 
parlando di un mailserver postfix autogestito, non di aruba.

 
non so cosa intendi per autogestito, ma nel post iniziale trovi sia 
'multidominio' che 'clienti'.
quindi, magari gabriele non lavora da aruba, ma fornisce il servizio di 
posta elettronica a dei clienti.
č quindi un provider.
o ho capito male?


 mi aiutasse.
Il parametro č smtp_helo_name, ma non sono sicuro che accetti una mappa.
Io in genere preferisco dare un nome host associato alla ditta che offre il
servizio
-- 
Flavio Visentin
Scientists have finally discovered what's wrong with the female brain:
On the left side, there is nothing right, and on the right side, there
is nothing left.

 gli scrive negli header una stringa a piacere per farlo contento...
Non è il tuo server che scrive una stringa a piacere, ma è il server che
riceve la mail che scrive il nome host contenuto nell'ehlo.
Il motivo per volerlo cambiare è per esempio quello di evitare di far sapere
al mondo intero la tua base clienti, o comunque per limitare la quantità di
informazioni inutili diffuse.


 
chi scrive l'header conta relativamente poco: il succo è che la soluzione che 
'tarocca' l'header la fornirebbe gabriele.
cmq, questo depone ulteriormente a sfavore della riscrittura.
io mail server del destinatario ricevo il tuo helo taroccato.
il reverse è inesistente.
se sono pignolo (non tutti i server fanno il check e di solito è 
disabilitato), la tua email finisce nel cestino.
il cliente di gabriele con chi se la prende?
potresti in teoria mantenere i record dns per tutti i clienti e il reverse 
andrebbe quindi a buon fine.
ma...
vale la pena di sobbarcarsi tutto sto lavoro?
è vero, il server del destinatario deve essere molto pignolo e non tutti lo 
sono, ma non vedo perchè andarsele a cercare...
imho, ci sono già abbastanza grane con blacklist, spam filters & co ^^
anche il voler limitare le info date all'esterno, mi sembra un pò debole come 
ragione.
gli header non sono informazioni correntemente utilizzate dall'utente finale.
chi li legge, di solito, conosce dig & co.
quanto ci impiega a trovare  il nome dell'intestatario del dominio con 
indirizzo e numero di telefono?
io sono comunque dell'idea (che tu stesso hai espresso nell'altro tuo post) 
che un nome generico associato al fornitore del servizio, sia la soluzione 
migliore.
opinione personale, eh, mica il vangelo...
;-P


 migliore.
Non è la soluzione migliore, ma è la soluzione più *pratica* che richiede il
minor dispendio di energie e rappresenta un compromesso solitamente accettabile.


 il reverse è inesistente.
Piccola esperienza personale con un cliente: buona parte dei mail server 
brasiliani controlla la corrispondenza tra helo e reverse. E non basta, 
come detto da te, creare 500 cname, ma deve corrispondere il record ptr.
Questo significa ad esempio che un classico server mail casalingo su 
ADSL Alice non riuscirà mai a mandare mail a questi mail server, a meno 
che nell'helo non scriva 
xxx-xxx-xxx.adsl.telecomitalia.it
 (o come 
diavolo è la reverse attuale di Alice).
Il consiglio quindi è che l'helo non si tarocchi, anzi ancora meglio che 
corrisponda al 100% al record PTR registrato dal fornitore dell'IP. I 
casi in cui questo controllo è effettuato sono rari, ma ci sono come 
detto mail server che rifiutano categoricamente la mail; altri che 
semplicemente con spamassassin rifilano un punteggio un po' piu' alto 
alla mail.
Angelo

 diavolo è la reverse attuale di Alice).
Che comunque è concettualmente errato e non richiesto da *nessuna* RFC.
Quel che è richiesto è che l'FQDN dell'HELO sia esistente, che l'IP del
server che si sta connettendo abbia un PTR per la risoluzione inversa e che
una volta risolto l'IP in un nome questo risolva nuovamente nell'IP.
Un server che richieda corrispondenza tra helo e ptr è un server configurato
male.


> diavolo è la reverse attuale di Alice).
Far imitare a un mailserver un comportamento mantenuto *solo* da milioni
di trojan: geniale, come misura per incrementare la deliverability... ;-)

 di trojan: geniale, come misura per incrementare la deliverability... ;-)
Una possibile soluzione intermedia e' quella di usare HELO=PTR solo per 
i domini di destinazione che presentano questo problema. Di solito sono 
pochi e si riescono a gestire tranquillamente a manina, in seguito alle 
segnalazioni degli utenti. Sempre che sia di interesse farlo, ovvio.
Fabio

 
io lo premetto sempre, cmq pare sia sfuggito: sono opinioni personali.
per me, il nome unico sempre costante è la soluzione migliore.
le alternative, sono secondo me complicazioni che non valgono lo sforzo 
che richiedono.
a parte, ovviamente, situazioni particolari o casi eccezionali.


 dalle tue.
No.
Tu hai parlato di verificare il reverse, ovvero verificare che la
risoluzione inversa dell'IP che si connette corrisponda al FQDN dell'helo.
Se non era quello che intendevi allora è un problema di comunicazione.


 
chiarito il tutto, stavolta?


 chiarito il tutto, stavolta?
OK.
