Newsgroup: it.news.net-abuse
Titolo: spamcannibal

Hola, mi ritrovo un server (appena "sballato"..) in spamcannibal.
Se faccio il lookup dell'ip  mi da una segnalazione strana:
Click for WhoisIP: 91.102.48.228  IT	
itinerari.itinerarintoscana.it
 
no reverse DNS, MX host should have rDNS - RFC1912 2.1
 
l'mx è 
91.102.48.12
:
 
dig -x 91.102.48.12 @
8.8.8.8
 
 
; <<>> DiG 9.7.0-P2-RedHat-9.7.0-17.P2.el5 <<>> -x 91.102.48.12 @
8.8.8.8
 
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46180
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
 
;; QUESTION SECTION:
;12.48.102.91.in-addr.arpa.     IN      PTR
 
;; ANSWER SECTION:
12.48.102.91.in-addr.arpa. 3380 IN      PTR     
smtp.tosnet.it
.
 
;; Query time: 30 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Wed Apr  3 11:41:53 2013
;; MSG SIZE  rcvd: 71
 
 
quindi c'è sia il ptr del server che invia (altrimenti non lo avrebbe 
risolto) sia quello dell'MX: che cosa vuole ancora?
 
-- 
Roberto Tagliaferri-Linux user #30785 <-> r.tagliaferri@(forse)
tosnet.it
 
www.robyt.eu
 
 

 dig -x 91.102.48.12 @
8.8.8.8
 
 
si vabbè ...
 
dig 
itinerarintoscana.it
 MX
 
;; QUESTION SECTION:
;
itinerarintoscana.it
.          IN      MX
 
;; ANSWER SECTION:
itinerarintoscana.it
.   3600    IN      MX      10
smtp.itinerarintoscana.it
.
 
;; AUTHORITY SECTION:
itinerarintoscana.it
.   3600    IN      NS      
ns2.tosnet.it
.
itinerarintoscana.it
.   3600    IN      NS      
dns.tosnet.it
.
 
;; ADDITIONAL SECTION:
smtp.itinerarintoscana.it
. 3600 IN      A       91.102.48.12
 
ora, fai il reverse del record MX di cui sopra e vedi cosa salta
fuori :P se vuoi risolvere il problema, riscrivi il record MX 
 
itinerarintoscana.it
.   3600 IN MX 10 
smtp.tosnet.it
.
 
e poi, se proprio ti serve, creati un
 
smtp.itinerarintoscana.it
. CNAME 
smtp.tosnet.it
.
 
così il cliente avrà comunque il proprio "smtp" <sigh>
 
/me che "il DNS, questo sconosciuto" :(
 


No, non sarò esperto ma non è proprio sconosciuto.
Mi era sembrato di capire che non era necessaria e obbligatoria la 
rispondenza biunivoca tra ip e nome del server, quindi non c'erano problemi 
se l'ip era assegnato a più fqdn.
Il messaggio di spamcannibal è chiaro: Manca l'rDns
Ma l'rDns per 91.102.48.12 esiste.
Quindi deve esserci relazione univoca?
Giusto petr capire


 No, non sarò esperto ma non è proprio sconosciuto.
 
Si ok... mi sono probabilmente espresso male, in qualsiasi caso ho come
la "vaga impressione" che se facessi come ti ho detto il problema con
"spamcannibal" si risolverebbe; la mia impressione è che i tizi
controllino i records MX e siccome il DNS risponde con un nome host
(
smtp.itinerarintoscana.it
) che non ha corrispondenza ... ripeto la
cosa da fare è modificare il record MX in
 
@   3600 IN MX 10 
smtp.tosnet.it
.
 
a quel punto inviando la mail, l'HELO, il record A, il PTR ed il record
MX avranno corrispondenza tra loro; se poi ti servisse avere comunque
un host di nome 
smtp.itinerarintoscana.it
. ti basterà creare un CNAME
(ma ovviamente NON userai il CNAME come MX :D)
 
ciao
 


ciao, non mi serve in questo caso avere 
smtp.itinerarintoscana.it
 (è uno 
script che fa la zona).
Ho modificato l'mx, dopo controllerò se a sc gli va bene così


 Ho modificato l'mx, dopo controllerò se a sc gli va bene così
 
Ciao... e scusa per l'altro post ma "mi giravano" (capita <sigh>); ad
ogni modo, sospettavo che il tutto fosse generato "in automatico" ed è
per quel motivo che ho suggerito la creazione del CNAME (sai, alle
volte c'è chi lo chiede ed in effetti... beh, ha ragione :D); a questo
punto direi che potresti (far) modificare lo script in modo da usare il
server corretto per quanto riguarda il record MX
 
Detto ciò, e senza voler esprimere giudizi su spamcannibal, ad occhio e
croce ho idea che i tizi di SC effettuino un controllo su MX/A/PTR; in
breve... inviando la mail da quel dominio vedrebbero una connex che
viene da "
smtp.tosnet.it
" con identico HELO, solo che, controllando il
dominio su DNS rilevano che MX=
smtp.itinerarintoscana.it
 ed in questo
caso il PTR non corrisponde; del resto c'è da dire che, a meno di non
pubblicare un record SPF (e non c'è), impostare un alias per MX non è
che sia una buona idea, specie se si considera che il server SMTP si
presenterà sempre (per l'invio) con il SUO nome reale :) quindi tanto
vale far puntare il record MX al server vero; non solo, in questo modo,
nel caso in cui modificassi l'IP di 
smtp.tosnet.it
, non dovresti
rimettere le mani su un tot di zone DNS :)
 
 
 

 rimettere le mani su un tot di zone DNS :)
 
mmm... non capisco: 
l'mx è il mail exchanger, quindi chi riceve l'email.. Non necessariamente il server che la invia.
Quindi non necessariamente avrò corrispondenza fra ip mx e ip dell'invio.
Anche perché (forse mi son spiegato male)
itinerari.itinerarintoscana è un server web con suo serverino (postfix) per inviare email (notrfiche, newsletter ecc).
Ha il suo helo:
 
itinerari.itinerarintoscana.it
[91.102.48.228]: EHLO 
itinerari.itinerarintoscana.it
 
La posta in ingresso viene gestita da un altro server di posta (giust'appunto 
smtp.tosnet.it
).
tra le altre cose è una situazione standard.. ho clienti che hanno il server web su un server e l'mx su un altro ma non avevo mai avuto problemi..
 anche perché l'MX ha il reverse e tutto.
Non capisco  perché si ostini a dire che non c'è...
 
Ho mandato una email con richiesta di dettagli, staremo a vedere
 
Bai bai 


 alerts nel caso in cui questo aumentasse all'improvviso ;)
 
 
ok.. ora è più chiaro.
Aspetto che mi risponda spamcannibal e poi comunque metterò un utente 
fittizio e farò smarthost.
Sarebbe anche intelligente chiudere la 25 in uscita (a parte per lo sh) in 
modo da inc... bloccare eventuali script del kaiser (non penso a questo 
server che ci metto le mani solo io, ma ad altri con wordpress et similia)


 Sarebbe anche intelligente chiudere la 25 in uscita (a parte per lo
 
quello è SICURO :) se qualcuno (qualcosa) vuole inviare emails, dovrà
passare obbligatoriamente dal server SMTP locale, non c'è verso :-)
anzi, se proprio volessimo essere pignoli, sarebbe opportuno che lo
smarthost usato da "web" sia diverso dal mailserver "normale" usato per
tutto il resto del traffico; mi rendo conto che questo significa dover
modificare le varie zone DNS; di contro, ti eviterebbe parecchie rogne
(potenziali); non solo, in quel caso, lo smarthost in questione
potrebbe essere configurato in modo da effettuare controlli (es.
clamav) sui messaggi in uscita e, comunque, in modo da avere un qualche
meccanismo di rate-limiting
 
 
 

 
scusa se abuso della tua pazienza ma continua a non tornarmi e voglio capire 
dove sbaglio:
A parte che questo è l'unico caso di reject da parte di spam cannibal che ho 
avuto (mentre di server ne ho altri in giro così configurati che mandano 
molte più email di questo), come configureresti un server web 
www.pippo.it
 
con mx su google?
fai comunque relay sui server di google?
Anche perché non tutti i domini sul server X hanno lo stesso MX (ne ho 2), 
quindi mi toccherebbe fare una tabella con i server di relay per ogni 
dominio (non ho le tabelle col db ma statiche).


 dominio (non ho le tabelle col db ma statiche).
 
Questo è altro problema ancora perchè usi un mailserver sul host www tu 
dici: se uso i relay e questi non coincidono per tutti i domini come 
minchia faccio ad utilizzare il relay giusto che ho dichiarato come mx 
per i vari domini?
bene. Con postfix ad esempio alterando la transport map con 
sender_dependent_relayhost_maps
 
sender_dependent_relayhost_maps = hash:/etc/postfix/relayhost_maps
 
cat /etc/postfix/relayhost_maps
user...@gerbil.org
 
smtp.gerbil.org
 
user...@xxxx.xxxx.com
 
smtp.xxxx.xxxx.com
 
user...@gmail.com
           [
smtp.gmail.com
]:587
 
poi nel caso, fornisci le pass sasl
cat /etc/postfix/sasl_passwd
smtp.xxxx.xxxx.xx      user...@xxxx.xxxx.xx:password
smtp.gerbil.org
	   user...@gerbil.org:password
[
smtp.gmail.com
]:587   user...@gmail.com:password
postmap /etc/postfix/sasl_passwd
 
per gli spf ti han già detto.
 
Per quanto a cannibal il reject è in effetti anomalo in quanto 
apparentemte non previsto dalla policy per questi casi.
Il controllo del reverse oltre a porre ste problemi è poi escluso dalla 
RFC2821 come sistema di reject (An SMTP server MAY verify that the 
domain name parameter in the EHLO  command actually corresponds to the 
IP address of the client. However, the server MUST NOT refuse to accept 
a message for this reason if the verification fails: the information 
about verification failure is for logging and tracing only.
Così non fosse sarebbe impossibile utilizzare, come invece è 
esplicitamente previsto, la literl form dell'IPv4 ricompreso in square 
bracket in alternativa al fqdn.
 
Quindi il dubbio è che la segnalazione sia stata aggiunta a mero 
livello inforativo, ma non sia la causa del blacklisting.
 
 
 

 livello inforativo, ma non sia la causa del blacklisting.
 
Non mi sembra comunque molto affidabile.
Stanotte ho avuto un reject ma da venerdì sera il sito di spamcannibal mi da 
un tranquillizzante
not in tarpit database
quindi è il cgi che fa il controllo canna oppure chi ha fatto il reject ha 
le zone in locale e non aggiornate.
Grazie delle info


 Non mi sembra comunque molto affidabile.
 
Tendo a concordare.
 
Secondo me quella è una lista gestita tecnicamente da cani, senza 
controlli ed il tuo problema dipendeva semplicemente da un loro problema 
temporaneo nelle lookups qualche giorno fa (e le ipotesi fatte 
precedentemente erano masturbazioni neuronali poco affidabili).
 

 quello?
 
Ok allora avevo capito male io. D'altronde è Obiwan che parlava di 
reverse :) 
Postifix implementa ad esempio  differenti tipi di reverse nelle 
smtpd_client_restrictions:
 
reject_unknown_reverse_client_hostname
che il classico reverse. E' una verifica più severa di:
reject_unknown_client_hostname 
che rigetta quando si verifica una delle tre:
1) fallisce il test di name mapping dell'IP (reverse)
2) fallisce l'address mapping del name (diretto)
3) indirizzo ottenuto risolvendo il l'hostname diverso IP del client
 
in quanto richiede che non solo che siano soddisfatte le due verifiche 
indirizzo A --> name 
name --> indirizzo client
 
ma che l'IP risolto sia quello del client.
Ip Client --> hostname --> IP 
deve essere Ip = Ip Client
 
Esistono tuttavia altri controlli possibli (2.7 in poi) fra cui:
 
check_client_mx_access
Search the specified access(5) database for the MX hosts for the client 
hostname, and execute the corresponding action. 
 
check_reverse_client_hostname_mx_access 
Search the specified access(5) database for the MX hosts for the 
unverified reverse client hostname, and execute the corresponding 
action. 
 
Questi avrebbero potuto produrre il reject nel tuo caso.
Comunque sia non sono previsti nella policy e quindi che ci azzeccano ?
 
 

 Comunque sia non sono previsti nella policy e quindi che ci azzeccano ?
eh.. la palla ï¿œ che se capita a un cliente vagli a spiegare che la lista 
(forse) si sbaglia


 reverse :) 
 
Alloooora; il discorso è semplice, se vuoi evitare di incasinarti
conviene sempre avere MX=A=PTR=HELO ossia, supponendo che il tuo server
sia ad IP 192.0.2.100 e che si presenti come "
mail.example.com
", per
evitare rogne dovresti avere
 
@       IN MX 10 
mail.example.com
.
mail    IN A     192.0.2.100
 
100.2.0.192.in-addr.arpa IN PTR 
mail.example.com
.
 
HELO 
mail.example.com
 
 
in questo modo all'invio di una mail, l'IP mittente avrà un PTR valido
e tale PTR corrisponderà al record MX ed a quanto specificato in HELO