Newsgroup: it.comp.os.linux.sys
Titolo: Postfix e verifiche utenti

Ragazzi ho un problema con un mail server che mi fa il controllo sugli 
utenti prima di accettare la posta. 
Il problema nasce dal fatto che il mio mta non possiede realmente gli 
utenti, il server che li contiene è in lan, perciò nel momento in cui l'mta 
remoto esegue il controllo sull'esistenza degli utenti il mio mta gli dice 
picche e quello non mi prende dentro la posta.
Uso postfix 2, come posso aggirare il problema ? Non vorrei ricreare gli 
utenti interni sull'mta in dmz
Grazie in anticipo
-- 
So many women and so little time
Rizio

 Grazie in anticipo
Di solito in questi casi si posta come minimo l'errore fornito (sia del
postfix locale che del remoto) che, magari, il 
main.cf
, il virtual e robe
simili.
Che poi è da li che si parte, soprattutto per cercare su google.
Max

 utenti interni sull'mta in dmz
Certo, non devi.

 Max


 domain does not resolve (in 
reply to MAIL FROM command)
perchè di fatto non può verificare se l'utente esiste.


 perchè di fatto non può verificare se l'utente esiste.
No no, non può verificare che esiste IL DOMINIO!
Non l'utente, il dominio, domain does not resolve: 
pippo.it
 non esiste 
(qualunque dominio tu stia usando).
Saluti

  
Fai bene a leggerlo ma non credo che sia attinente col tuo problema.
Max

 (qualunque dominio tu stia usando).
Ragazzi scusate ma purtroppo fa la verifica proprio sull'utente.
Per capirlo ho provato ad iniziare una connessione smtp _verso_ il server 
incriminato e come campo "mail from" gli ho dato un utente realmente 
esistente su 
pippo.com
, in risposta ho ottenuto un ok e mi ha permesso di 
continuare. Se mettevo un nome utente esistente su 
pippo.it
 (e non su 
pippo.com
) mi dava il mesasggio di cui sopra.


 dei DNS da che parte sta.
Ripeto: non capisco come posso essere io il problema ?


 
pippo.com
) mi dava il mesasggio di cui sopra.
Hai mai pensato che un dominio it e com possono non esistere?
Facciamo csi, quali sono i due domini, che faccio io un controllo, 
oppure dimmi qual'è il server a cui vuoi spedire ch eti faccio vedere i log.

  
per forza!
pippo.com
 è il dominio esterno, registrato e riconosciuto/risolto dai 
server su internet.
fai una prova semplicissima: come FROM, imposta un utente che NON ESISTE su 
pippo.com
t accetta il mittente, perchè verifica il dominio e non l'utente.
-- 
+-------
| Paolo opg
|
| janickg ( at ) hotmail ( dot ) com
| (fake address in reply-to field!)
+-------

Paolo opg wrote:
scusatemi mi sono accorto adesso che ho ommesso una premessa fondamentale:
nei dns pubblici il record MX per i due domini puntano allo stesso IP.
pippo.it
 e 
pippo.com
 puntano entrambe alla macchina che gestisce 
pippo.com
 
(che sgestisce 
pippo.com
 direttamente e fa il forward per 
pippo.it
 alla 
macchina in lan)


 Hai mai pensato che un dominio it e com possono non esistere?
.... la risposta è quella sopra.
Scusate per l'ommissione, ha fuorviato il discorso.



550-unrouteable mail domain "
ircff.it
"
550 Sender verify failed
Come, visto che non mi dici quali sono i tuoi site ho fatto una prova 
con quelli di test, ch efanno esattamente quello che ti si va dicendo: 
lui controlla il dominino DI CHI INVIA, il sender è inteso in senso lato.
Saluti

 Scusate per l'ommissione, ha fuorviato il discorso.
La rispota è quella mia sotto, non cambia nulla...

 
hai fatto la prova con l'utente 
inesi...@pippo.com
?


 hai fatto la prova con l'utente 
inesi...@pippo.com
?
Si, e mi il messaggio da cui sono partito. Se invece lo faccio con 
esis...@pippo.com
 mi accetta.


 picche e quello non mi prende dentro la posta.
Probabilmente dall'altra parte stanno usando SAV, che pero' credo si 
trovi solo sulle versioni "experimental" di postfix (qualcosa di simile 
c'e' anche per Windows), per cui il client prima di accettare la mail 
verifica "anche" il sender mandando una richiesta di invio mail per 
ti...@mx.dominio (senza inviare nulla). Con uno script potresti popolare 
il file aliases del server in dmz e hai risolto il problema.
scusa se ho frainteso
Paolo

 
...
da qualche anno a questa parte, è molto difficile che un mail server 
consenta di fare il controllo di esistenza sulla singola casella.
prova a diabilitare il verify di postfix (disable_vrfy_command = yes) per 
vedere se cambia qualcosa, se cioè vengono accettate anche le email per 
destinatari inesistenti (mandando poi il messaggio d'erorre, 
ovviamente...).
se ti risolve il problema o almeno cambia messaggio d'errore, ok, 
altrimenti, è un problema dns o del server mail remoto.
se provi a collegarti via telnet a un mailserver di qualche grande provider 
e provi a chiedere la verifica di un indirizzo (VRFY), vedrai che ti viene 
risposto:
252 address verification is not available
(
mail.tin.it
, 
mail.libero.it
)
questo perchè si tratta di una feature che può essere utilizzata dagli 
spammer e quindi viene spesso disabilitata.


 Paolo
Grazie ancora.


 ovviamente...).
Ok, adesso provo. Grazie mille


 scusa se ho frainteso
Attenzione, facciamo a capirci.
Qui si stanno rpovando le soluzioni, perchè il nostro amico dic e enon 
dice e non si capisce.
Quello che tu descrivi è un metodo antispam, d'accordo, ma a parte al 
sua completa inutilità sui sistemi reali, è davvero un sovraccarico da 
panico.
I comandi EXPN e VRFY  NOn sono pi usati perchè erano facilmente usati 
appunto per rubare indirizzi.
Il caso di cui sopra poi non è il modo per sistemare, perchè un file 
aliases su bastion host non ha alcun senso se postfix è configurato da 
relay, perhè le mail el passa al mailhub in intranet, ed il controllo 
diventa una cosa del tutto inutile.
Io ho fatto uan domanda e non ho avuto risposta, credo che il discorso 
finisca qui.
Se lui mi dic equali sono i domini in questione mi prendo carico di 
farla io la prova e controllare di che si tratta, ma se lui dice e non 
dice, allora per me resta solo una errata configurazioen del postfix che 
non masqeura l'eventuael dominio correttamente, o del ricevente che ha 
il server malconfigurato.
Saluti

 Ci sono altri sistemi secondo te ? Tipo white list "*@
beghelli.it
 OK" ?
Ma cosa dici?
La white list per INVIARE?
Rizio, fermati, prenditi un giorno di pausa, e poi ricominciamo.
Saluti

 Rizio, fermati, prenditi un giorno di pausa, e poi ricominciamo.
Forse hai ragione, č meglio se seguo il tuo consiglio perchč oggi veramente 
non riesco a spiegarmi correttamente e vi sto facendo impazzire a forza di 
immaginazione.


 un db o un collegamento al db ldap interno su una macchina in dmz.
Mi spiace Rizio, ma io sono una capra e non ho mai usato ldap, piu' che 
altro pensavo che non dovrebbe essere laborioso ricavare una lista da 
una /home o da un mysql e aggiornare automaticamente il file aliases ed 
eventualmente il virtual. Se non vuoi collegare ldap al tuo postfix in 
dmz, per quel pochissimo che so, non vedo altra soluzione al problema.
SAV e' un ottimo strumento contro lo spam e non ha a che vedere con il 
verfy, tuttavia non e' molto usato se non nella forma "warn if" inoltre 
richiede di mettere nella whitelist tutte le mailing list usate dagli 
utenti.
ciao Paolo

 immaginazione.
Bene, occuapti di altro e stai tranquillo, fra qualche ora o giorno, 
posta i seguenti dati:
dominio ed indirizzo ip del server nella DMZ ed il suo 
main.cf
dominio ed indirizzp ip del server in intranet ed il suo 
main.cf
dominio a cui stai cercando di inviare.
Porzione dei log dei due server dove c'č il messaggio incriminato ed 
eventualmente il messaggio incriminato stesso che ricevi dal server.
Saluti, your helpdesk.

 diventa una cosa del tutto inutile.
Penso che tu abbia ragione, nel caso pero' si potrebbe usare aliases 
nella forma tizio: tizio@mailinterno@
dominio2.it
 al posto di transport.
Se all'interno c'e' solo 
dominio2.it
 non credo che le cose si vadano a 
complicare.
ciao... Paolo

 Ci sono altri sistemi secondo te ? Tipo white list "*@
beghelli.it
 OK" ?
Be' per la verita' ci sarebbe il RAV che forse e' quello che fa al caso 
tuo, di seguito l'introduzione del readme di postfix. Scaricati l'ultima 
versione
Postfix Address Verification Howto
-------------------------------------------------------------------------------
WARNING WARNING WARNING
The sender/recipient address verification feature described in this 
document is suitable only for low-traffic sites. It performs poorly 
under high load and may cause your site to be blacklisted by some 
providers. See the "Limitations" section below for details.
What Postfix address verification can do for you
Address verification is a feature that allows the Postfix SMTP server to 
block a sender (MAIL FROM) or recipient (RCPT TO) address until the 
address has been verified to be deliverable.
The technique has obvious uses in order to reject junk mail with an 
unreplyable sender address.
The technique may also be useful to block mail for undeliverable 
recipients, for example on a mail relay host that does not have a list 
of all the valid recipient addresses. This prevents undeliverable junk 
mail from entering the queue, so that Postfix doesn't have to waste 
resources trying to send MAILER-DAEMON messages back.
This feature is available in Postfix version 2.1 and later.

 complicare.
Non so di cosa parli, il bastion host non ha mydestination attivo, 
quindi prenderà tutte le mail per cui è legittimato, dal @righthand.
Il lefthand@ lo controlla il mailhub, dopo lo sgrossamento del bastion.
Saluti

 Postfix Address Verification Howto
Hai copiato la parte sbagliata!
Gia solo il punto uno ed il putno tre fanno capire che si tratta di cose 
accademiche...
Ma a parte tutto, NOI (io sicramente), non sappiamo di cosa si tratta 
poiche Rizio non ha dato le indicazioni di base necessarie.
Quindi fermiamoci qua, vediamo cosa mi ripodne e poi risolviamo anche 
questo problemone....
     *
       Postfix probes the nearest MTA for the address that is being 
verified, without actually sending mail to that address. If the nearest 
MTA accepts the address, then Postfix assumes that the address is 
deliverable, even when the address will bounce AFTER that MTA accepts it.
     *
       Sites like AOL may blacklist you when you are probing them too 
often (a probe is an SMTP session that does not deliver mail), or when 
you are probing them too often for a non-existent address.
     *
       Normally, address verification probe messages follow the same 
path as regular mail. However, some sites send mail to the Internet via 
an intermediate relayhost; this breaks address verification. See below, 
section "Controlling the routing of address verification probes", for 
how to override mail routing and for possible limitations when you have 
to do this.
     *
       Postfix assumes that an address is undeliverable when the nearest 
MTA for the address rejects the probe, regardless of the reason for 
rejection (client rejected, HELO rejected, MAIL FROM rejected, etc.). 
Thus, Postfix rejects mail when the sender's MTA rejects mail from your 
machine. This is a good thing.
     *
       Unfortunately, some major sites such as YAHOO do not reject 
unknown addresses in reply to the RCPT TO command, but report a delivery 
failure in response to end of DATA after a message is transferred. 
Postfix address verification does not work with such sites.
     *
       By default, Postfix probe messages have "postmaster@$myorigin" as 
the sender address. This is SAFE because the Postfix SMTP server does 
not reject mail for this address.
       You can change this into the null address ("address_verify_sender 
="). This is UNSAFE because address probes will fail with mis-configured 
sites that reject MAIL FROM: <>, while probes from 
"postmaster@$myorigin" would succeed.

 utenti interni sull'mta in dmz
Rizio, c'č qualcosa che non capisco (come altri, mi pare di capire,
seguendo il thread... ;-)
Hai il relay in dmz e il server in lan.
Come passano le mail dall'uno all'altro?
Hai una transport?
In questo caso, non capisco quale sia il problema: il primo server accetta
tutto il dominio, il secondo accetta solo gli utenti reali e torna 550 per
tutti gli altri.
Questo ha il problema che, anzichč avere le mail rifiutate durante l'smtp
direttamente, il relayer esterno si deve occupare dei bouce (occupando
code e creando bounce inutili e fastidiosi).
E' questo quello che stai cercando di evitare? Vuoi informare il relay in
modo da non generare bounce?

 code e creando bounce inutili e fastidiosi).
Qui mi sono perso Skull. Cioè ?


 questo problemone....
Tutto sta a vedere se la verifica del recipient puo' dialogare con ldap 
e in che modo, in questo caso postfix non rispondera' negativamente e la 
mail in uscita verra' accettata. Pero' siamo sempre al punto di 
partenza, qualcuno in un modo o nell'altro dovra' interrogare il db o il 
server interno che a sua volta passera' la richiesta a ldap. A me pare 
di capire che sia il secondo caso e questo salverebbe capra e cavoli.
----------------------------------
Recipient address verification
As mentioned earlier, recipient address verification may be useful to 
block mail for undeliverable recipients on a mail relay host that does 
not have a list of all valid recipient addresses. This can help to 
prevent the mail queue from filling up with MAILER-DAEMON messages.
Recipient address verification is relatively straightforward and there 
are no surprises. If a recipient probe fails, then Postfix rejects mail 
for the recipient address. If a recipient probe succeeds, then Postfix 
accepts mail for the recipient address.
Saluti anche a te.

 
Rizio, ma mi stai prendendo in giro?
Trying 212.103.204.82...
Connected to 
mail.pippo.it
.
Escape character is '^]'.
220 
pippo.it
  MailSite ESMTP Receiver Version 4.5.6.0 Ready
Pippo.it non è il tuo dominio (o non lo è 
pippo.com
), non puoi mandare 
mail con un dominio non tuo...

 Qui mi sono perso Skull. Cioè ?
...con il risultato che il reject avverrà solamente da parte del server
di destinazione.
Se la posta venisse consegnata direttamente a costui, questi
stroncherebbe le comunicazioni smtp dirette a utenti inesistenti,
quindi la generazione del bounce sarebbe a carico del server mittente.
Avendo invece questo doppio passaggio, la generazione del bounce sarà a
carico del tuo relay, creando code, sprecando banda (perchè accetti una
comunicazione inutile e poi la devi anche rimandare indietro) e dando
fastidio (non credo di essere l'unicao a ricevere tonnellate di bounce
dai server di libero per mail virulente dal mittente falsificato...).
Detto questo, gli svantaggi di avere il relay che non conosce gli utenti
reali son tutti qui.
Ci sono peraltro situazioni (come la mia, che ho degli MX che effettuano
transport verso server di miei clienti, dei quali non ho alcun modo di
conoscere gli utenti...) in cui è impossibile fare altrimenti.
Hola...
-- 
the Skull says:
+---------------------------------------------------------------------+
 We are Pentium of Borg. Division is futile. You will be approximated.

 Rizio, ma mi stai prendendo in giro?
Michele apprezzo davvero moltissimo l'aiuto che mi stai dando (tu e tutti 
gli altri) senza il quale _sicuramente_ non riuscirei a risolvere problemi 
reali che nelle varie doc non sono menzionati, o non lo sono nella loro 
manifestazione sui miei server. Detto questo, e proprio per non farti 
credere che ti voglio/sto prendendo in giro te lo dico esplicitamente:
non mi piace far girare i nomi pubblici dei server sui quali lavoro in un ng 
per una marea di motivi.
Di sicuro non per sfiducia/timore nei partecipanti alla discussione (per cui 
provo stima, almeno per la maggior parte) ma perchè il newsgroup è pubblico 
e leggibile dal mondo. E' vero che questo può non comportare niente ma 
secondo l'incofutabile legge del "se non c'è non si rompe" preferisco così.
Sono cosciente che questo limiterà l'aiuto che posso ricevere, e a volte, 
stizzirà anche qualcuno che, come te, tende semplicemente la mano, ma 
preferisco così.
Grazie mille per la pazienza.


 conoscere gli utenti...) in cui è impossibile fare altrimenti.
Perciò non c'è niente da fare no ? Ho capito bene ? In questa situazione o 
metto una lista utenti sul mail in dmz (tipo lista o query ldap sul DC - 
come diceva Kojak) o me lo tengo così, giusto ?


 per una marea di motivi.
Queste cose non mi fanno stizzire, ma solo sorridere.
Security by obscurity è dimostrato non portare alcuna *palese* maggiore 
sicurezza a nessun sistema informatico.
Saluti

 come diceva Kojak) o me lo tengo così, giusto ?
No.
Saluti

 No.
Ti pregherei di estendere ed esplicare, perchč la cosa mi interessa assai... ;-)

 No.
In che senso no ? Ipotizzo che sia un "no, non ha senso mettere una "lista" 
sul maildmz" (come hai già per altro detto) e "no, non devi per forza 
tenerlo così". In questo caso però mi mancano le altre opzioni (o le ho 
perse nel thread se me le hai già proposte).




Ok, ma pubblicare a disposizione di tutta internet che "il mio sistema è
configurato così e così, lo trovate su questo ip pubblico e ha questo e
questo problema che non riesco a risolvere" serve, IMHO, solo a dare una
mano a chi è in cerca di sistemi per fare danno/rompere i maroni; non
ritengo abbia molto a che vedere con il tema security through obscurity...
Tutto IMHO ;-)
Hola...

 perse nel thread se me le hai già proposte).
Esatto:
 >> Ci sono peraltro situazioni (come la mia, che ho degli MX che 
 >>effettuano transport verso server di miei clienti, dei quali non ho 
 >>alcun modo di conoscere gli utenti...) in cui è impossibile fare 
 >>altrimenti.
 >
 >Perciò non c'è niente da fare no ? Ho capito bene ? In questa 
 >situazione o
 >metto una lista utenti sul mail in dmz (tipo lista o query ldap sul DC 
 >come diceva Kojak) o me lo tengo così, giusto ?
Il server che fa realy verso chiunqe altro deve accettare al posta per 
tutto il dominio, senza verficare il lefthand@.
Nel caso in cui un RAV controlli l'utente 
cic...@pippo.it
 è chiaramente 
scorretto che il realy dica NON ESISTE.
Quindi c'è tutto da fare, ovvero settare il relay correttamente epr 
accettare la posta per 
qualsias...@pippo.it
 e 
pippo.com
.
Ma come ho già detto tante e tante altre volte non si capisce, o melgio, 
IO NON HO CAPITO se:
A) l'errore chi te lo dà
B) il server che fa realy manda via con l'indirizzo 
pippo.it
 o 
pippo.com
 
o entrabi o 
intra.pippo.it
Ed altre cose per le quali non vedo soluzione perchè non ho chairo di 
cosa parliamo.
Saluti
PS: esistono casi in cui chiaraemnte il realy potrebbe controllare il 
lefthand, ma dubito fortemente stiamo parlando di questo, il mio 
problema è che mi manca il quadro completo...

 Ti pregherei di estendere ed esplicare, perchè la cosa mi interessa assai... ;-)
Fatto!!
Io accetto la posta esattamente coem hai detto tu: realy prend eil 
dominio, e tutti i dfomini che volgio io, e poi inoltra al mailhub che 
fa il delivery alla casella.
NON ho MAI avuto un problema uguale o anche simile a quello di Rizio.
Saluti

 ritengo abbia molto a che vedere con il tema security through obscurity...
Come no!
Lui si sente più sicuro a non dirmi nulla, se non è questa una falsa 
sensazione di sicurezza..
Comunque, non voglio entrare in polemica con nessuno, ho affrontato 
molti problemi con postfix e potrei aiutarlo, essendo su usenet ed 
essendo noi tutti consci di cosa significa, non sarà difficile capire 
che più di cosi io non ho tempo e voglia di fare nulla.
Saluti

 
Capisco la tua reticenze, ma guarda che è inutile: a parte che in un 
precedente post ti è proprio scappato il dominio ****
elli.it
 (puoi fare 
un cancel, se vuoi rimuoverlo dai server), ma comunque stai postando 
dalla rete aziendale e non è difficile risalire al tuo server :-)
Ne ho approfittato per fare due verifiche e ho trovato una cosa che può 
essere utile:
mail.******.it è un CNAME di mail.*****.com. Questo è illegale ai sensi 
delle RFC, IIRC; ogni MX record deve corrispondere ad un A record e non 
ad un CNAME. E' possibile che alcuni MTA abbiano delle regole che 
seguono alla lettera questa limitazione e per questo hai difficoltà a 
spedirgli mail. (per documentazione, dai un'occhiata a questo capitolo 
del bat book: 
http://www.busan.edu/~nic/networking/sendmail/ch21_03.htm
)
bye!
-- 
Fabrizio "Hermooz" Ermini



Ah, ok.. pensavo avessi una soluzione tipo "come ti rifiuto le mail per
utenti inesistenti"..
In realtà una cosa di questo genere la sto facendo: ho fatto un demone
perl sulla macchina di log che estrae i 550 ottenuti in fase di delivery e
estrae gli indirizzi per realizzarne delle map da dare in pasto a postfix
retroattivamente.
Ha qualche effetto positivo, in effetti (non risolutivo in ogni caso,
specialmente nel caso di bruteforce nel guessing delle utenze, dove le
probabilità di collisione con utenze già in mappa sono irrisorie), ma:
- diventa complesso da gestire, per la necessità di rimuovere utenti di
nuova creazione dalle mappe così generate
- bisogna implementare meccanismi di timeout delle entry
- inizia ad avere qualche effetto solo per masse critiche di mail/die
piuttosto corpose
- dà vantaggi solamente per guessing del tipo "well known", se mi si
concede l'espressione fuori luogo
Nel totale, ha senso fino ad un certo punto, e solo se la struttura in cui
lo si fa è abbastanza grossa.
In particolare, da me permetterebbe di segare fuori un 2-3000 bounce al
giorno, secondo le mie stime, per cui lo faccio...
Per un server con pochi utenti potrebbe decisamente non valerne la pena...

 bye!
Grazie mille.....
Ad mojora
-- 
So many women and so little time
Rizio
(prendere nota per il futuro: stare attento ad Hermooz... è pericoloso) ;)

 utenti inesistenti"..
Se gli utenti sono virtualizzati, č facile 
http://www.postfix.org/LOCAL_RECIPIENT_README.html
Se non lo fossero, allora tutto sommato non saranno mai in numero cosi 
elevato da creare un grosso *problema*, IMHO.
Tu parli di 2/3000 bounce, ma su quanti utenti?

 Tu parli di 2/3000 bounce, ma su quanti utenti?
Difficile saperlo, per i motivi suddetti.
Dovendo fare una stima assolutamente spannometrica, direi tra i 5 e i 7
mila, per un totale, allo stato attuale delle cose, di circa 90K contatti
SMTP validi al giorno (esclusi spam probe che ottengono reject, intendo).
Hola...

: User unknown in local recipient table
rcpt to: 
in...@pippo.it
250 Ok
Devi togliere 
pippo.com
 dal mydestination....

 che più di cosi io non ho tempo e voglia di fare nulla.
Sicuro, e non è nemmeno difficile girarci attorno individuando lo stesso
da dove chiama... Tuttavia, non dare troppe info sulla propria rete
significa in ogni caso lasciare meno appigli...
Hola!

 rifiutando direttamente allo strato più esterno.
Ok, questo è un caso particolare!
Io lo faccio con una regola di procmail che mi intercetta i messaggi di 
bounce ed errore e popola un file di testo che esporto su altre macchine.

 che più di cosi io non ho tempo e voglia di fare nulla.
Hai ragione anche qui, non vorrei comunque che anche il tempo speso fino ad 
ora a rispondermi fosse contato come inutile, per me non lo è stato. Poi ho 
ammesso fin dal secondo post che avevo preso come presupposti delle info 
che voi non potevate sapere e ho cercato di fare chiarezza.
 
Ciao e grazie per la pazienza :)


 da dove chiama... 
Infatti ho eseguito dei test....

 Devi togliere 
pippo.com
 dal mydestination....
Ok, ma se tolgo uno dei due (.com o .it) dal mydestination come faccio a 
dire al server in dmz di prendere in carico la mail per quel determinato 
dominio ? Mi sfugge qualcosa ?


 Infatti ho eseguito dei test....
weh weh weh.... allora !!! Vi vedo che mi state sbirciando nelle mutandine 
vehh !!!
:))


 dominio ? Mi sfugge qualcosa ?
Da stralcio:
mydestination                   = $myhostname, localhost.$mydomain
default_transport               = smtp
transport_maps                  = hash:$config_directory/transport
relay_domains                   = $mydestination, $transport_maps

 (prendere nota per il futuro: stare attento ad Hermooz... è pericoloso) 
Moi? Sono un agnellino... :-)
bye!

 dominio ? Mi sfugge qualcosa ?
Si, è scritto a caratteri cubitali sulle docs che mydestination è la 
fine del tragitto, mydestination significa che qui c'è la mailbox e se 
fai relay mydestiantion deve essere vuoto.
  What domains to receive mail for
The mydestination parameter specifies what domains this machine will 
deliver locally, instead of forwarding to another machine. The default 
is to receive mail for the machine itself. See the VIRTUAL_README file 
for how to configure Postfix for hosted domains.
You can specify zero or more domain names, "/file/name" patterns and/or 
"type:table" lookup tables (such as hash:, btree:, nis:, ldap:, or 
mysql:), separated by whitespace and/or commas. A "/file/name" pattern 
is replaced by its contents; "type:table" requests that a table lookup 
is done and merely tests for existence: the lookup result is ignored.
IMPORTANT: If your machine is a mail server for its entire domain, you 
must list $mydomain as well.
Mentre postfix capisce o gli dici quali domini gestire con:
record MX e relay_domains coem ti ha già detto il teschio.
Saluti

 bye!
grazie ancora e
ad mjora


 fai relay mydestiantion deve essere vuoto.
Ok, ora mi rileggo eglio quella parte di doc perchè il dubbio è "ma 
lasciandolo solo nalla lista dei relay_domains (come da post di Skull) lui 
prenderà in carico tutte le mail per i domini descritti lì ?"
Adesso rileggo poi provvedo, anche se non so come questo risolva il 
problema. Nel senso che se l'MTA remoto effettua una connessione per 
verificare l'esistenza dell'utente anche configurando correttamente questo 
parametro (che comunque va fatto) non mi trova l'utente comunque no ?


 
da 
http://www.postfix.org/LOCAL_RECIPIENT_README.html
  To turn off unknown local recipient rejects by the SMTP server, specify:
/etc/postfix/
main.cf
:
     local_recipient_maps =
That is, an empty value. With this setting, the Postfix SMTP server will 
not reject mail with "User unknown in local recipient table".
pero' come nel caso di Skull sei nell'impossibilita' di risparmiare 
banda rifiutando il trasferimento direttamente dal relay esterno.
che non abbia senso avere una lista dei recipients validi su relay 
esterno a me non sembra, ci sono casi appunto in cui cio' e' 
impossibile, altri in cui forse non e' conveniente.
avevo pensato anch'io alla possibilita' di un errore tipo avere un MX in 
CNAME ma la consideravo troppo remota, tuttavia non saprei dirti quanto 
abbia a che fare con il tuo problema.
ciao... Paolo

 parametro (che comunque va fatto) non mi trova l'utente comunque no ?
Io mollo.
Saluti.

 ciao... Paolo
Grazie ancora.


 Io mollo.
Scusami Michele... non avevo letto fino alla fine (ok ok ... avete ragione. 
Fare più di una cosa alla volta porta male)
Scusami ancora
