Newsgroup: it.comp.os.linux.sys
Titolo: postfix e from falso e bugiardo

Buongiorno a tutti,
deve essere una scemenza incredibile, almeno concettualmente, ma non
ho idea di come implementarla. Si tratta di riuscire a filtrare come
spam delle e-mail provenienti dall'esterno, in cui pero` il from del
messaggio risulta essere di un utente del mio dominio.
In pratica basterebbe riuscire a dirgli se la mail non arriva dalla
rete interna e il from del messaggio e` di un utente del dominio (o
MAILER...@mio.dominio.com
) marcalo come spam (o anche buttalo
via).
Riconoscente per qualsiasi suggerimento per il quale ringrazio fin
d'ora, saluto


La parola d'ordine � "restriction_classes".
In sostanza definisci una restriction class che � composta da una o pi�
mappe.
In smtpd_recipient_restrictions crei una access-list che matchi mail che
abbiano il tuo dominio come mittente e le dirigi a right part alla
restriction class opportuna.
Nota che se il mailserver � unico e la posta per quel dominio deve
essere instradata solamente attraverso quel medesimo mailserver, ottieni
la stessa cosa rigettando le mail che abbiano il tuo dominio a mittente
*dopo* essere transitato attraverso permit_mynetworks e
permit_sasl_authenticated, dato che i client che inviano a nome del tuo
dominio in modo lecito escono dal ruleset l�...
-- 
Professional System & Network Sarcazzer
http://bofhskull.wordpress.com/

 dominio in modo lecito escono dal ruleset lì...
Grazzissime!
Per verificare che abbia funzionato come posso fare, non conoscendo
spammer che possano accontentarmi?
Andrea

 spammer che possano accontentarmi?
Da una macchina su Internet (
p.es
. da casa tua) o da qualche tuo amico/cliente:
telnet <indirizzo ip pubblico> 25
helo <host-fqdn>
mail from: <utente-...@miodominio.mio>
rcpt to: <utente...@miodominio.mio>
data
Subject: Test
To: Utente Reale <utente...@miodominio.mio>
test
.
quit
-- 
Flavio Visentin
Ubuntu in Zulu significa "Non so usare Debian". (cit. CtRiX)

 quit
Grazissime anche a te! Devo aver preso una botta in testa, adesso
stavo pensando di dover installare un mail server (mentre avrei dovuto
sapere che esisteva questa soluzione, che avevo gia` usata -essendo
standard - e avendola ampiamente dimenticata).


o da un cellulare con Android:
A. da Linux collegato con USB:
$ adb shell
# bash   (giusto perch� � pi� bella)
# telnet <indirizzo ip pubblico> 25
B. dal terminale che installi su android:
# telnet <indirizzo ip pubblico> 25
-- 
echo onailimissaM | awk 'BEGIN { FS = "" }
{ for (i = NF; i >= 1; i-- )
   printf $i }'; echo

 quit
Il problema e` che succede:
mioPCdiCASA:~$ telnet 
mailserver.diLAVORO.it
 25
Trying X.Y.W.Z...
telnet: Unable to connect to remote host: No route to host
cazzo e`?!?
Al mailserver in ssh ci arrivo e i suoi log e la mia mailbox mi
mostrano che gli arriva posta.
nmap mi dice che la 25 e` filtered, ma da chi dove, perche' e come?
Uhm, me lo fa anche col mailserver di libero e quello di gmail.
Mi sto filtrando? Provo a verificare il router e il PC.
Saluti

 telnet: Unable to connect to remote host: No route to host
1. � "firewallato"?
2. ti stai veramente connettendo all'ip pubblico?
3. all'esterno io ho bloccato la 25 e uso la 465 (smtps)... anche se TLS 
si pu� usare sulla 25, uso pure il certificato SSL. Per� il telnet con 
TLS, si pu� fare, ma � complicatello... ma il telnet con il certificato 
SSL non avrei idea di come si pu� fare.
ma non chiederlo a noi. Devi saperlo tu.


 cazzo e`?!?
Il tuo provider filtra (giustamente) la 25 in uscita.
Prova da qualche altra parte, oppure fai un redirect temporaneo sul tuo 
firewall o sul tuo server di posta da una porta alta (
p.es
. 2525) alla 25.


 Per� il telnet con TLS, si pu� fare, ma � complicatello...
Poi sarei io l'hacker? Che dire di te che usi TLS via telnet?
f/u i.c.c.lamer


 firewall o sul tuo server di posta da una porta alta (
p.es
. 2525) alla 25.
Questa purtroppo non e` percorribile perche' a valle (o a monte, a
seconda del punto di osservazione) del mailserver c'e` un firewall non
in mia gestione che mi preclude l'accesso a porte diverse da quelle
necessarie al suo funzionamento.
Grazie e salute

 casa.
In realt� no: ti impedisce di avere un mailserver che faccia direct-to-MX.
Anche se fosse, comunque, � per quello che ci sono linee consumer e
linee professionali...


ma non chiederlo a noi. Devi saperlo tu.
Se magari mi dessi un attimino un accountino chrottatino con 1 comando
a disposizione, telnet, ti potrei dire piu` cose.
Saluti


confuso authlogin con tls.
ho rimosso tls da un po' e uso ssl.


 Linux/BSD in giro per il mondo (tipo free shell), di cui in questo
Mandami in pvt l'IP del server e il dominio e te la faccio io la prova.




dammi un attimo


 linee professionali...
Si`, pero` sarebbe carino che te lo dicessero prima, non che tu lo
scopra provando, dopo.
Salutazioni

 scopra provando, dopo.
Leggi le condizioni del contratto e ce lo troverai scritto, nero su bianco.


 connettivit� non business...
O anche business, quanto a quello....



ti ho scritto sulla mail --> te lo ri-raccomando: fai il bravo :-)


 ti ho scritto sulla mail --> te lo ri-raccomando: fai il bravo :-)
Sono stato bravinissimo e ho verificato che non funziona ancora come
vorrei.
Inoltre sono rientrato in posssesso almeno di uno degli account shell
dormienti in giro per il mondo per cui d'ora innanzi sono autonomo per
le prove.
Grazie ancora.

 Leggi le condizioni del contratto e ce lo troverai scritto, nero su bianco.
Ne dubito e per continuare a farlo non lo leggero`, diversamente non
potrei piu` dubitarne, in un caso o nell'altro sarei certo, anche
perche' non mi dici dove ho messo il contratto e in questo momento ho
qualche difficolta` a trovarlo.


nel frattempo mi sono attivato l'ambiente chroot.... potr� sempre servire.


 Di nuovo giustamente :-)
bh�, avresti altri problemi nel farti un mailserver a casa. range di ip 
dinamici, blacklist, impossibilit� a creare un PTR corretto, 
praticamente sarebbe inutilizzabile salvo per fare test come in questo caso.

 d'ora, saluto
io faccio cos�:
in smtpd_recipient_restriction alla FINE metto (cos� i tuoi host 
rientrano in permit mynetwork e authenticated):
check_helo_access pcre:/etc/postfix/helo-pcre
in helo-pcre
/^#/                             550 Block
/^
MIODOMINIO.NET
$/              550 Block
/^10.10.10.10$/   (l'indirizzo ip)              550 Block
/^test\d*$/                      550 Block
/^
mail.com
$/                     550 Block
etc etc
poi postmap /etc/postfix/helo-pcre
ovviamente va bene solo se il server � univoco, come ti � stato detto da 
altri, altrimenti riscontreresti altri problemi.

 wrote:
OK, funziona. Per la teoria rimando a skull qui sopra, mentre per la
pratica, ma che si riferisce solo alla prima parte della teoria, non
anche alla seconda, a
http://www.arschkrebs.de/postfix/postfix_restriction_classes3_en.shtml
che e` anche a sfondo nero con caratteri bianchi, quindi riposante per
gli occhi e per la mente, con l'accortezza di adeguare la sintassi a
quanto suggerisce postalias, di sostituire degli spazi con dei doppi
punti.

 altri, altrimenti riscontreresti altri problemi.
Grazie. Perfetto. Adesso ho risolto nell'altro modo, ma mancava questo
esempio per completare la discussione.

 ho rimosso tls da un po' e uso ssl.
Hai confuso anche TLS con SSL visto che TLS == SSL o meglio, il primo è 
il successore del secondo.
Usare terminologie adeguate spesso aiuta e di solito previene figure alla 
peracottaro/cioccolataio/sysadminwannabe.

 /^
mail.com
$/                     550 Block
Questo non fa quanto richiesto. Questo blocca alcuni helo (peraltro quasi 
tutti liberamente bloccabili con un classico reject_non_fqdn_hostname che su 
un server aziendale � utile e ben gestibile), quindi tutti quelli che si 
presentano con helo corretto ma con mittente del tuo dominio entrano 
comuqnue senza problemi. La soluzione sono le restriction classes come 
indicato da Skull


 il successore del secondo.
uhm uhm uhm.... c'è però una cosa che non capisco con postfix.
Quando usavo TLS, la porta era sempre la 25, il client faceva login, poi 
lanciava STARTTLS e la comunicazione diventava criptata.
Però, se non ricordo male, in quel caso postfix, *non* mi usava i 
certificati.
Appena ho abilitato la porta SMTPS il client mi ha chiesto di accettare 
il certificato.
why? problems with my configuration? oppure è normale che con TLS sulla 
25 lui non usi i certificati?



sembrerebbe normale in effetti, perché la 25 dovrebbe essere in chiaro, 
e quindi il client non inizia la comunicazione scambiando i certificati. 
Parte in chiaro, poi fa STARTTLS.... mmaaahhh? non sono sicuro ......


 Parte in chiaro, poi fa STARTTLS.... mmaaahhh? non sono sicuro ......
Stai dicendo che l'SMTP non è il tuo forte oppure stai dicendo
"non ci capisco nulla, datemi una mano a capire ?"


Mi pare chiaro, che la cosa non mi è chiara.
Mi pare come quando ho avuto l'incidente, io non riuscivo ad alzarmi e 
tutti mi stavano intorno a guardare.
Per fortuna che in quel caso nessuno mi ha detto: "vorresti dire che lo 
scooter non è il tuo forte" :-)
suvvia, spiegami di che si tratta.


 suvvia, spiegami di che si tratta.
Dato che hai tanto tempo libero (e che se leggi non scrivi :-) ) eccoti 
tutti i riferimenti per diventare un esperto di SMTP e di SSL/TLS.
http://en.wikipedia.org/wiki/STARTTLS
 (l'ho appena aggiornata perché faceva 
ancora riferimento alle vecchie RFC)
http://tools.ietf.org/html/rfc5321
http://tools.ietf.org/html/rfc3207
http://tools.ietf.org/html/rfc5246


 Parte in chiaro, poi fa STARTTLS.... mmaaahhh? non sono sicuro ......
TLS può usare dei certificati firmati così come può usare anche chiavi 
più o meno temporanee che permettono solo l'encryption e non 
l'autenticazione. Su SMTPS avevi entrambi per forza.
Evidentemente se non avevi configurato i certificati sul tuo MDA, usavi 
solo encryption e non l'authentication.
Chiaro ?
Max

 assegnata da IANA (587).
C'è un'imprecisione. Submission (tcp 587) è stato definito nella RFC4409 per 
l'utilizzo nella comunicazione client to server, non server to server.
Per le comunicazioni server to server si deve continuare ad utilizzare il 
classico SMTP (RFC5321), sul quale comunque si può (e si dovrebbe) usare TLS 
secondo quanto definito nella RFC3207.


 tutti i riferimenti per diventare un esperto di SMTP e di SSL/TLS.
beh grazie per questi.


 Allora...
grazie per la spiegazione, che è stata più che chiara.
Ho appena verificato e effettivamente, mi chiede il sertificato con TSL.
Una domanda sintetica:
Insieme a TLS (ma anche a SSL), thunderbird 3 mostra una ulteriore 
opzione che è possibile selezionare: "Use secure authentication"
What does it means? O come dicono a Oxford: what the fuck is that?



A proposito della wiki in inglese che hai citato:
http://en.wikipedia.org/wiki/STARTTLS
Oltre a IMAP, POP, NNTP (come viene riportato all'inizio, dici che non 
c'è pure una RFC per STARTTLS per LDAP ?


 dovrebbe) usare TLS secondo quanto definito nella RFC3207.
Si hai ragione, mi ero dimenricato di essere esplicito...
non ho il dono della chiarezza. 
Nel mio cervello l'avevo esplicitato quando ho parlato in merito alla 
compatibilità di SMTPS con RFC821

 What does it means? O come dicono a Oxford: what the fuck is that?
Intende l'autenticazione attraverso meccanismi CRAM in luogo di PLAIN o
LOGIN.
Solo che i meccanismi CRAM richiedono che il mailserver abbia accesso
alle password in chiaro, cosa per ovvie ragioni non sempre vera.


 c'è pure una RFC per STARTTLS per LDAP ?
rfc4513


 LOGIN.
quindi diventa superfluo usare CRAM passando attraverso TLS/SSL (almeno 
nello scenario che ho in mente, in cui lui usa PAM localmente).


 localmente).
Se deve autenticare sulle usuali credenziali di sistema (hashate, aka
"non conservate in chiaro") CRAM non è "superfluo": semplicemente non
funziona.


 funziona.
peraltro Postfix + SASL non supportano CRAM.


 peraltro Postfix + SASL non supportano CRAM.
Ma anche no.

 peraltro Postfix + SASL non supportano CRAM.
Non ne azzecchi una eh!


http://nonciclopedia.wikia.com/wiki/Ma_anche_no
 ?



http://www.postfix.org/SASL_README.html
Important
Do not specify any other mechanisms in mech_list than PLAIN or LOGIN 
when using saslauthd! It can only handle these two mechanisms, and 
authentication will fail if clients are allowed to choose other mechanisms.



Ma anche si... cioè: mi limito alla documentazione che mi passa sotto 
gli occhi.
http://www.postfix.org/SASL_README.html
Important
Do not specify any other mechanisms in mech_list than PLAIN or LOGIN 
when using saslauthd! It can only handle these two mechanisms, and 
authentication will fail if clients are allowed to choose other mechanisms.


 
http://nonciclopedia.wikia.com/wiki/Ma_anche_no
 ?
M-I-T-I-C-O :)
«Siamo vostri amici! Ma anche no...»
(Cortés sul popolo Maya)
 
«Siamo sulla buona strada per le Indie. Ma anche no...»
(Capitano della nave su Cristoforo Colombo)
 
«Risolverò tutti i problemi di questo paese! Ma anche no...»
(Berlusconi agli elettori)


 (Cortés sul popolo Maya)
mmmmmhhhhhh .... secondo me Cortes non vide il popolo Maya, ma gli 
aztechi.... va be: è pur sempre una nonciclopedia :)


 indicato da Skull
Quindi contro ogni evidenza sostieni che helo significhi helo, non ma
anche no.
Si`, l'avevo bevuta, cancello quanto sopra e per amore di conoscenza
provo a trovare un'implementazione
funzionante di quanto diceva Skull nella seconda parte del suo msg.
Andrea

 Andrea
A memoria (quindi verifica):
# In /etc/postfix/
main.cf
smtpd_restriction_classes = reject_my_domain
reject_my_domain = check_sender_address hash:/etc/postfix/reject_my_domain
smtpd_recipient_restrictions =
	...
	permit_mynetworks,
	permit_saslauthenticated,
	check_recipient_address = hash:/etc/postfix/access_recipient,
	...
# In /etc/postfix/reject_my_domain
miodominio.mio	REJECT Fake sender
# In /etc/postfix/access_recipient
miodominio.mio	reject_my_domain
Ovviamente ricordati i postmap.


 check_helo_access pcre:/etc/postfix/helo-pcre
Funziona anche se il client invia "ehlo" invece di "helo"?
da provare.


 
Per il resto � giusta, ma cos� viene rigettato tutto ci� che arriva da
miodominio.mio, � diretto a miodominio.mio e non arriva da mynetworks o
da una sessione SMTP-AUTH.
Dovessi farlo, preferirei lasciar perdere il destinatario, tanto che �
locale si sa gi�, o non supererebbe reject_unauth_destination.
Per quello dicevo che tantovale rigettare tutto il dominio mittente dopo
permit_mynetworks e permit_sasl_authenticated:
smtpd_recipient_restrictions =
    ...
    permit_mynetworks,
    permit_saslauthenticated,
    reject_unauth_destination,
    check_sender_access = hash:/etc/postfix/reject_my_domain,
    ...
# In /etc/postfix/reject_my_domain
miodominio.mio    REJECT Fake sender
Di fatto, ha lo stesso effetto, senza usare restriction_class.


 da provare.
Diamine, ovvio che s�.
Matcha la helo string, non il fatto che la sessione sia SMTP/ESMTP...
(anche se, come detto da altri, non ha alcuna intersezione con la
richiesta dell'OP)


 Matcha la helo string, non il fatto che la sessione sia SMTP/ESMTP...
probabilmente � cos�, ma potrebbe anche matchare l'input "helo"... lo 
hai provato, hai guardato il codice, hai una documentazione sotto mano?


 hai provato, hai guardato il codice, hai una documentazione sotto mano?
Fidati, non mi serve.


 Professional System & Network Sarcazzerhttp://
bofhskull.wordpress.com/
Grazie. Cosi` il cerchio e` completo e si puo` chiudere il thread,
almeno su questa parte.
Spero che questi messaggi vengano archiviati perche la serie potrebbe
essere assai utile in futuro a chiunque si trovi alle prese con questo
problema.

 Fidati, non mi serve.
fidati: l'ultimo che disse "ma anche no" non aveva letto la
documentazione di postfix.
Essendo il primo comando che lancia il client, come fai a capire in
anticipo se si sta collegando un client che parla smtp, o un client che
parla esmtp?
Probabilmente lo capisci subito tramite quella stringa.
Quindi il discrimine � quella stringa. E quindi � probabile che si
faccia un match su quella stringa.
Ovviamente, al 99%, tranne che quella direttiva non sia stravecchia,
sar� stato considerata l'ipotesi che il client dice anche ehlo.


 Fidati, non mi serve.
LOL.

 sar� stato considerata l'ipotesi che il client dice anche ehlo.
D� pure 100.


 gli occhi.
Dovresti prenderti la briga di leggerla _tutta_ e di _capirla_, oltre
che citarne il link.

 
http://nonciclopedia.wikia.com/wiki/Ma_anche_no
 ?
LOL.


dico pure 100 ma non cambia niente in questo ragionamento.



Non vi date le pacche sulle spalle: fate solo innervosire :)


 Non vi date le pacche sulle spalle: fate solo innervosire
E ben per quello che lo facciamo.

 oh cacchio: ma ti rendi conto che non ha nessun senso
Eddai, cazzo, ma ti ci diverti?
http://www.postfix.org/SMTPD_ACCESS_README.html
[...]Requiring that the client sends the HELO or EHLO[...]
[...]evaluated before Postfix replied to the HELO (EHLO)[...] 
and so on...
P.S.
Non so se sia un caso di omonimia, ma oggi ho visto un tuo messaggio
su una bacheca di facebook, quella del PV.
Se sei tu, beh, è un casino che non si può immaginare quel che sta
accadendo in realtà; se vuoi te lo spiego in privato...

 Non vi date le pacche sulle spalle: fate solo innervosire :)
Innervosisciti pure... d'altronde cosa si dovrebbe fare se non ridere quando 
si legge di qualcuno che non conosce quasi nulla dell'argomento mail (come 
hai ampiamente dimostrato) mettere in discussione le affermazioni di chi il 
prodotto lo usa da anni, ne ha una conoscenza non dico totale ma poco ci 
manca, ed è uno dei sistemisti più competenti in Italia per quanto riguarda 
questo argomento...
Poi ti lamenti se ti si manda con i lamer tuoi simili...
f/u


 accadendo in realtà; se vuoi te lo spiego in privato...
si che ero io :-) se mi vuoi aggiungere su facebook, quello sono io, 
altrimenti la mia mail è: maxadamo ..... su gmail.


 Italia per quanto riguarda questo argomento...
di chi stai parlando? Dov'è? Chi è?
Scherzo :-) Se tutta la vita cuci bottoni, dovrai pur essere un grande 
cucitore di bottoni. Certo, non sarai mai un sarto, sarai sempre poco 
flessibile: solo debian e basta :-)
scherzo ah.... ma forse chi scherza dice la verità.


 argomento...
Mo' non t'allargare.
Ma le restriction di postfix sì, le conosco piuttosto bene, ormai.


 
http://www.postfix.org/SASL_README.html
C.V.D. / Q.E.D.


Mica poco.
Già che ci sei, sappi che mi son stufato di lottare con ntpd.
Fallisce palesemente per via del socket su ::, ma ho rinunciato a capire
perchè.
Perlopiù per via del fatto che in 30 secondi openntpd si è scaricato,
compilato, installato e non ha rotto le balle... :-\
Aggiungi gli improperi del caso in direzione di chi sai già ;-)


 Mo' non t'allargare.
E' perché ancora non sai quel che ti chiederò :-PPPP
