problema con postfix

[Joe Oblivian]

Il giorno 16/apr/05, alle 02:18, davide cavaliere ha scritto:

> Buona sera a tutti,
>

Ciao, questa e' una domanda tecnica, va postata sulla lista palermo, 
palermo@lists.linux.it. Sposto il thread li'

>
> Utilizzo Postfix cyrus-sasl e courier-imap-ssl

bene

> Fino a qualche tempo fa pensavo che la mia configurazione andava
> benissimo

Congiuntivo!

>  ma ultimamente ricevo spam inviato direttamente collegandosi
> al mio server. Provo a spiegarmi meglio: a guardare la voce Received:
> nell'header del msg trovo come primo server proprio il mio. Cosa 
> (penso)
> possa avvenire solo collegandosi direttamente al mio server con telnet
> (o con un altro server?)

non necessariamente. Uno spambot fa piu' o meno la stessa cosa.

>  l'indirizzo dal quale arriva il messaggio è un
> indirizzo telecom, non ha un mx record e nessun dns record;

Confermo che e' uno spambot allora, o un open relay (ma dagli header di 
cui parli, mi pare improbabile)

>  per lo meno
> il server non funziona da open-relay (almeno per questo funziona) 
> quindi
> solo gli utenti che si autenticano possono spedire mail all'esterno,
> però in questi tre giorni ho testato il mio server (munito di telnet ed
> anche shell esterna, in modo da non passare il controllo
> permit_mynetworks)

bene

>  e mi sono accorto che chiunque potrebbe spedire mail
> ai miei utenti spacciandosi per un'altro dei miei utenti o anche cosa
> ancora peggiore per un altro utente qualsiasi!

E su queesto _non_ puoi farci nulla. Nell'email (ma anche nella 
corrispondenza tradizionale) non c'e' uno stretto controllo sul 
mittente. L'unico modo accettabile di "firmare" un messaggio di posta 
e' firmarlo con gpg

> Lavorando sulla configurazione del server sono riuscito a diminuire il
> danno (vedere configurazione qui di seguito), quindi ho imposto la
> verifica dell'indirizzo prima di accettare MAIL FROM, e ho impostato
> alcune restrizioni per RCPT TO.
>

beh direi che e' il minimo per non trovarsi inondati di spam. Ma rcpt 
to? non capisco...

> Magari potrei accontentarmi dei risultati ma.... proprio non riesco a
> sopportare che qualcuno potrette inviare ai miei utenti mail
> spacciandosi per un altro utente, nella configurazione ho inserito gli
> opportuni paramentri ma è ancora possibile farlo (spacciarsi per un mio
> utente).

E su questo, per quanto ne so, c'e' davvero poco da fare se non 
adottare misure non standard. E poi se tu impedisci di spacciarsi per 
un tuo utente sul tuo server il rpoblema rimane: se io voglio mandare 
un'email a pope@vatican.va da damny@azita.homelinux.net basta che usi 
telnet sul server opportuno... qindi tu non hai un reale controllo su 
chi invia la posta a nome di chi, fermo restando che dagli headers uno 
un'idea se la fa.

>
> Alla luce di questa lunga premessa mi posto parte (penso che sia la
> parte rilevante a proposito di questi problemi) e spero che vi sia tra
> di voi un anima pia che conosca postfix quanto basta per potermi dare
> una mano.
>

ci provo

> smtpd_sasl_auth_enable = yes
> smtpd_sasl2_auth_enable = yes
> smtpd_sasl_security_options = noanonymous
> smtpd_sasl_local_domain = $mydomain
> broken_sasl_auth_clients = yes
> smtpd_client_restrictions = 
> permit_sasl_authenticated,permit_mynetworks,
> reject_rbl_client relays.ordb.org
>

uhm ecco il primo punto su cui interverrei:

_devi_ usare almeno reject_rbl_client sbl-xbl.spamhau
s.org. Io quando ragioni di causa maggiore (basilarmente la lemeness di 
chi manda posta da un host che non e' registrato come MX) avevo messo

smtpd_recipient_restrictions = 
reject_unauth_pipelining,permit_sasl_authenticate
d,permit_mynetworks,reject_unauth_destination, reject_rbl_client 
blackholes.easynet.nl,reject_rbl_client relays.ordb.org,rejec
t_rbl_client sbl-xbl.spamhaus.org,reject_rbl_client 
http.dnsbl.sorbs.net,reject_
rbl_client zombie.dnsbl.sorbs.net,reject_rbl_client 
bl.spamcop.net,reject_rbl_cl
ient dun.dnsrbl.net,reject_rbl_client relays.ordb.org,reject_rbl_client 
opm.blit
zed.org,reject_rbl_client sbl-xbl.spamhaus.org,reject_rbl_client 
korea.services.
net,reject_rbl_client opm.blitzed.org,reject_rbl_client 
dialups.visi.com,reject_
rbl_client relays.visi.com,reject_rbl_client 
list.dsbl.org,reject_rbl_client cn-
kr.blackholes.us,reject_rbl_client 
singapore.blackholes.us,reject_rbl_client tha
iland.blackholes.us,reject_rbl_client 
malaysia.blackholes.us,reject_rbl_client c
hina.blackholes.us,reject_rbl_client 
korea.blackholes.us,reject_rbl_client argen
tina.blackholes.us,reject_rbl_client 
brazil.blackholes.us,reject_rbl_client taiw
an.blackholes.us,reject_rbl_client 
nigeria.blackholes.us,reject_rbl_client cbl.a
buseat.org,permit


> smpt_helo_restrictions = reject_invalid_hostname
> #       permit
>
> smtpd_recipient_restrictions = permit_sasl_authenticated,
> permit_mynetworks, reject_non_fqdn_sender, reject_unauth_destination

se usi sasl, perche' metti permit_mynetworks? ha davvero senso?

> smtpd_use_tls = yes
> smtpd_tls_auth_only = no
> smtpd_tls_key_file = /etc/ssl/postfix/lazita.key.pem
> smtpd_tls_cert_file = /etc/ssl/postfix/lazita.crt.pem
> smtpd_tls_CAfile = /etc/ssl/postfix/root.pem
> smtpd_tls_loglevel = 3
> smtpd_tls_received_header = yes
> smtpd_tls_session_cache_timeout = 3600s
> tls_random_source = dev:/dev/urandom
> smtpd_sender_restrictions = warn_if_reject, check_sender_access

tutto ok

> hash:/etc/postfix/access, reject_authenticated_sender_login_mismatch,
> reject_unauthenticated_sender_login_mismatch, reject_unverified_sender,
> reject_sender_login_mismatch, reject_unknown_sender_domain

anche qui sarebbe bastato reject_authenticated_sender_login_mismatch

> # permit
>
> #relay-conf
> smtp_sasl_auth_enable = yes
> smtp_sasl_password_maps = hash:/etc/postfix/saslpass
> smtp_sasl_security_options = noanonymous
>
>
> #add configurations
> #smtpd_sasl_application_name = smtpd
> smtpd_reject_unlisted_sender = yes
> smtpd_sender_login_maps = hash:/etc/mail/users
>
>
> Grazie per l'aiuto
>

Prego. Come vedi,  il problema che ti assilla e' un problema generale 
di SMTP, e creddo che i suoi svaantaggi siano ben bilanciati dai 
vantaggi in termini di scarso overhead delle comunicazioni.

Joe

>
> http://lazita.homelinux.net
> Apache/2.0.50 (Gentoo/Linux)


Gentoo resta semrpe male ;-)