Newsgroup: it.comp.os.linux.sys
Titolo: Domanda su SMTP multi IP

Ciao a tutti,
ho una macchina con 4 siti ognuno con un IP pubblico dedicato.
Per capirci:
dominio1.cxm  -> xxx.xxx.xxx.xxx  ( Ip di esempio )
dominio2.cxm -> yyy.yyy.yyy.yyy
dominio3.cxm -> qqq.qqq.qqq.qqq
....
Vorrei che l' SMTP inviasse le mail di
dominio1.cxm con il suo ip xxx.xxx.xxx.xxx
le mail di
dominio2 con il suo ip: yyy.yyy.yyy.yyy
e cosě via ...
( il concetto dovrebbe essere che se un dominio finisce in qualche RBL .. 
spam list ..
gli altri non ne soffrano ).
Mi piacerebbe usare Qmail .. ma č OK anche Postfix
Grazie mille
                                    -- Yena --

                                     -- Yena --
la prima ipotesi è che secondo me non si può fare, a meno che con un
super mega iper accrocchio...
la seconda ipotesi è che si faccia in maniera abbastanza agevole e che
io sono un super mega iper ignorante....
più probabile la seconda :) :)
ciao!

                                     -- Yena --
la prima ipotesi è che secondo me non si può fare, a meno che con un


 Mi piacerebbe usare Qmail .. ma è OK anche Postfix


Scusate il post doppio di prima...
ma se invece di cercare di rimediare al fatto di  essere finiti in una
blacklist vi concentraste sui metodi per non finirci?
per esempio potreste usare l'smtp del vostro ISP come relay per spedire
la
posta fuori, oppure fare dei check sulle mail inviate dai vostri
clients...
dico...è un ipotesi...
Gandolfo "Infinity" Ivo ha scritto:


 Mi piacerebbe usare Qmail
http://www.digitaldaemon.com/FreeBSD/qmail/index.html
http://www.rno-consultores.com/mail/qmail/qmail-1.03_outgoingips.patch
La cosa interessa pure a me (anche se non mi e' ancora successo di avere 
utenti troppo scorretti). Comunque, se le provi, magari dicci se 
funzionano senza problemi :)
PS: Mi ricordavo di averle notate ma non ho mai avuto tempo di guardarle 
bene. Se ben ricordo, pero', entrambe le patch si *fidano* del dominio 
specificato nell'envelope sender (SMTP "MAIL FROM:") dell'email per poi 
fare il lookup dell'IP d'invio. Non e' il massimo... ma non credo vi 
siano altre 'semplici' alternative.
Ciao
-- 
Cybertoldo
Per rispondermi via email, sostituisci moc.liamg con 
gmail.com

 
non è saggio controllare gli ip dei vari received: e se io uso un server 
interno che inoltra la posta?
Ti ritrovi ip locali nell'header
-- 
Roberto Tagliaferri-Linux user #30785 <-> r.tagliaferri@(forse)
tosnet.it
Lui apre bocca solo quando non ha niente da dire.
		-- Spike Milligan

 e cosě via ...
Non ho idea se e come si possa fare, perň fossi in te userei VServer in
modo da avere ogni ip in un vserver diverso cosě gli utilizzatori di
dominio1 non possono fare casini nel dominio2, in questo modo anche i
mailserver essendo separati escono sui loro ip.
Ciao, Micky
-- 
What's this hash prompt on my terminal mean?
Micky Del Favero  -  System Manager  &  BOFH

 relay, l'IP del 'client' o del primo server usato rimane nell'header.
in blacklist ci finirebbe solo il server SMTP che ha inviato l'email 
'connettendosi' ai server di destinazione (e in questo caso specifico, 
quindi, si arrecherebbe anche un danno al proprio ISP).


 Ti ritrovi ip locali nell'header
Vero. Quando ricevi una mail, l'unici "Received:" affidabili sono quelli 
che ha scritto 'il tuo' server di posta in ricezione. Gli altri, per 
quanto poco ne sappiamo, potrebbero essere tutti falsificati (e quasi 
sempre e' cosi' nelle email di spam).


 E l'ip che riportano non e' quello del mio server di posta.
Probabilmente perche' dall'IP del tuo 'gateway' e' stata in passato 
inviata 'robaccia' :)
Pero' non credo che, al tempo, l'IP sia stato inserito in quella 
blacklist perche' l'hanno individuato su 'campi received non 
attendibili' (al vero perche' puoi risalire solo tu facendo un controllo 
su Spamhaus).
E' invece piu' sensato che un normale server di posta, a cui invii un 
email, possa controllare tutti gli IP negli headers al fine di 
verificarli in qualche RBL (il tuo esempio). In quest'ultimo caso 
saresti comunque tu (potenziale spammer) ad 'autodenunciarti' (magari 
falsificandoli pure).


 E l'ip che riportano non e' quello del mio server di posta.
E' forse un IP dinamico che hai assegnato al momento dell'invio?
E' il motivo per cui applicare XBL all'analisi degli header non è
consigliabile, cmq...

 Si... dillo a quei coglioni che si affidano SOLO a quello.
Applicare XBL o simili agli *headers*? non mi risulta ci sia molta gente
che lo fa...
E' comunque abbastanza errato concettualmente: si andrebbe a bloccare
una buona fetta della posta partita da netblock dinamici adibiti ad
utenza consumer, che è una buona fetta del tutto...
SBL, viceversa, può essere applicata praticamente senza falsi positivi...

 Tipo... non inviare posta?
tipo far filtrare da amavis/spamassassin anche le mail in uscita?
...

 consigliabile, cmq...
Gia'. Non avevo notato l'XBL in '
sbl-xbl.spamhaus.org
'. Quindi il server 
che ha fatto il reject dell'email e' pure configurato 'naif' :) (ma e' 
uno dei tanti).


 altre 'semplici' alternative.
Mi documento e la provo !
Grazie x la dritta
                                                            -- Yena -- 

 mailserver essendo separati escono sui loro ip.
Quella dei Vserver è una buona idea .. ma la terrei come ultima spiaggia ;-)
ritengo che sia può "laboriosa" sia da gestire che da manutenere .. e poi io
sarò all'antica ma i Vserver mi fanno na gran paura .. ( come stabilità e
data recovery in caso di disastri )


 -- Yena -- 
Io uso da svariato tempo i Vserver, e mi trovo benissimo, sia come uptime,
che come stabilità:
[root@C3P0 ~]# uptime && uname -a
 01:09:52 up 238 days, 22:36,  1 user,  load average: 1.99, 1.73, 1.05
Linux 
C3P0.server.int
 2.6.17.11-grsec2.1.9-vs2.0.2-rc31 #2 SMP Sun Sep 3
19:27:10 PDT 2006 x86_64 x86_64 x86_64 GNU/Linux
[root@C3P0 ~]#
(Pentium 4 dual proc. 64bit)
[root@R2D2 ~]# uptime && uname -a
 01:11:47 up 189 days, 11:09,  1 user,  load average: 2.56, 0.42, 5.00
Linux 
R2D2.server.int
 2.6.17.11-grsec2.1.9-vs2.0.2-rc31 #2 SMP Sun Sep 3
19:27:10 PDT 2006 x86_64 x86_64 x86_64 GNU/Linux
[root@R2D2 ~]#
(idem sopra)
E dentro suddetti server ci sono più di 300 vserver (dns autoritativi per
molti domini, mailserver, etc), e fino ad oggi mai avuto problemi. Se ti
servono consigli chiamami pure in privato. Li uso quotidianamente
(soprattutto li uso per i test, e da dare in mano a quei CL dei miei
colleghi che si spacciano per programmatori & company)
Il bello dei vserver è che il server padre ha pieno accesso al filesystem
usato dagli stessi vserver (quindi largo spazio a script banali come
tar -zcf etc etc fatto in ssh da un server di backup con relativo scp al
seguito oppure su una unità di backup, essa sia nastro oppure DVD-rw :).
Il lato gestione è quasi nullo, e se usi distro ad esempio come debian
(apt-get) o fedora (yum) non dovresti avere grossi problemi. Ma io sono
masochista (e ricordo che mia mamma diceva pure coglione) ed uso Gentoo :)
P.S. mi piacerebbe sapere cosa ne pensa un certo sistemista olandese di
questa soluzione :)
P.S.2 Lo stesso sistemista olandese dovrebbe preparare un nuovo HD per il
suo webserver, perchè stò per inviargli almeno un quintale di storie :)
Saluti
Gandolfo "Infinity" Ivo

 E la tua mail sarebbe valida?
Seguro

, 
l'inserimento in elenco dell'IP e' quasi sicuramente dovuto ad un PC 
'infetto' all'interno della LAN che sparava in giro robaccia. Il PC 
usciva in internet tramite NAT con l'IP del gateway... e questo c'e' 
finito. :)


 finito. :)
<mode evangelist on>
Questo insegna 2 cose:
1) chiudere l'uscita verso la 25 a tutti i client fuorchè al server
interno, al mimite abilitandolo per le sole destinazioni inevitabili
(ovvero relay autenticati che non supportino la corretta porta 587)
2) evitare come la peste di nattare il mailserver aziendale sullo stesso
IP ove è NATtata globalmente la LAN, a meno che non si sia provveduto
alla 1)
<mode evangelist off>
/me magari qui oramai san tutti, ma è una cosa che ripeto talmente
spesso e a talmente tanta gente che è un'automatismo...

 ritengo che sia può "laboriosa" sia da gestire che da manutenere ..
gestione semplicissima: li crei con newvserver nomeserver (almeno se usi
debian, se non la usi faresti meglio a cambiare distribuzione) in2
minuti, poi la gestione è la stessa di un server reale, con l'unica
differenza che se devi spostarlo su un'altra macchina basta copi una
directory.


 	(
fw-int.noisalviamoilmondopuntocom.com
 [212.19.219.186])
e cosě ora sappiamo per chi lavori :-)


     e quello esterno, ed e' quest'ultimo che e' "mappato".
YEAH, confermo l'analisi precedente.
Io lě ci metterei un punto di controllo, o bloccherei la 25 in uscita
dal firewall...

 Be', non e' che era molto difficile pure prima no?
perň ora abbiamo la certezza. :-) 


     e quello esterno, ed e' quest'ultimo che e' "mappato".
(al posto delle 'x' scrivi il rimanente degli ip)
[4] - 
http://www.dnsstuff.com/tools/ip4r.ch?ip=212.x.x.x
[3] - 
http://www.dnsstuff.com/tools/ip4r.ch?ip=62.x.x.x
Al controllo attuale, non mi sembra che il tuo gateway sia in qualche 
blacklist. Semmai il tuo server di posta ha un piccolo problema (ma su 
FIVETENSRC e probabilmente trascurabile).
Ciao


 Ciao, Micky
Ciao
Gandolfo "Infinity" Ivo
SysAdmin 


Cosa usi Xen o Vmware ?
                                                -- Yena -- 

                                                -- Yena -- 
Manco un pò. Uso Linux Vserver. 
www.linux-vserver.org
 c'è tutto ciò che ti 
può servire (una patch al kernel e via che si và, + tool di amministrazione, 
per la patch al kernel ti consiglio di usare quella GRSEC, non si sà mai ;), 
guardare il post precedente per il link alle immagini dei guest già 
configurati a dovere, e funzionanti.
Ciao
Gandolfo "Infinity" Ivo
Sysadmin 

 ha scritto nel messaggio 
news:6zcYg.3677$Fk1....@twister2.libero.it...

Come prestazioni come va.. quanto incide la virtualizzazione ?
                                                -- Yena --

                                                -- Yena --
Linux Vserver si può definire un banale chroot, con qualche marcia in più. 
Non c'è un emulatore tra server reale e le macchine virtuali.
Le prestazioni sono ottime, tramite i classici tool puoi limitare CPU e RAM, 
etc. I tempi di risposta sono come quelli della macchina reale (a differenza 
di UML o WMWARE non c'è un interfaccia emulata in bridge, ma un'alias sulla 
scheda di rete ad esempio eth0:1)
Ti consiglio di provarlo, perchè non riesci a renderti conto delle 
potenzialità finchè non lo vedi. Inoltre la sicurezza è già di per sè 
ottima, se ci aggiungi GRSEC direi che sei apposto.
Saluti
Gandolfo "Infinity" Ivo
Sysadmin

 ottima, se ci aggiungi GRSEC direi che sei apposto.
Grazie di tutto, veramente interessante !
Lo provo subito !
                                    -- Yena --