Hej,
Thomas Arildsen wrote:
> Jeg bruger heller ikke rblsmtpd (endnu) men har lige siddet og læst om
> den. Fordelen er, som jeg ser det, at mails fra åbne relays og hvad man
> ellers kan finde på at blokere (for at 'customize' den skal man AFAIK
> gøre det med en lokal DNS-server, som man sætter op som
> blackhole-server), bliver afvist 'helt ude ved gadedøren', og man
> behøver ikke engang at se det skidt. Ulempen er selvfølgelig, at den kun
> blokerer mails fra blacklistede servere og ikke f.eks. filtrerer på
> subject og hvad man ellers kunne finde på.
Man kan filtre på mange niveauer.
Og det ene udelukker ikke det andet ...
Med tcprules db:
================
Man bakser en file sammen (typisk f.eks. /etc/tcp.smtp) der guffet
igennem af tcprules direkte kan anvendes til accept/deny/reject en
connect med (rejct) eller uden (deny) error msg og styre Relay
funktionen.
En:
# TIS-cali
212.54.64.103-106:allow,RBLSMTPD=""
Giver f.eks. mails fra TIS-cali fri entre til at aflevere mails til
qmail-smtpd.
En:
#
61.128-143.:deny
vil blot uden vidre droppe forbindelsen, hvis en IP fra CHINANET i
adresse rummet 61.128.0.0 - 61.143.255.255 skulle forsøge sig med en
connect til port 25/TCP.
En :
#
200.207.5.:allow,RBLSMTPD="-Parse error, brain dumped. Sorry it didn't
work out ..."
Siger blot (med lidt omsvøb) til een eller anden Latin American Lover
source, at vi ikke gider ha' deres mail ;)
Sådan kan man sidde længe og fedte med /etc/tcp.smtp (eller hvad man nu
kalder den) og lige huske sluttelig at køre en
tcprules /etc/tcp.smtp.cdb /etc/tcp.smtp.tmp < /etc/tcp.smtp
Har man mange MTA's man føre tilsyn med (local eller remote), er det min
erfaring, at det ud over det basale /etc/tcp.smtp.cdb haløj er nemmest
at knalde en supplerende white og black list op på DNS'en, som de
enkelte rblsmtpd's så kan hive lidt i ørene efter behov.
Et eller andet sted i sin qmail.sh laver man f.eks. noget der minder i
omegnen af:
${TCPSERVER} -c ${MAXSMTPD} -x/etc/tcp.smtp.cdb ${REMOTE_LOOKUP} \
${LOCAL_LOOKUP} -R -v -u ${U_ID} -g ${G_ID} ${IF_2LISTEN2} ${SMTP_PORT}
\
${RBLSMTPD} \
-a dnswl.mitdomain \
-r dnsbl.mitdomain \
-r relays.ordb.org \
/var/qmail/bin/qmail-smtpd 2>&1 | /var/qmail/bin/splogger smtpd 3 &
Nu høvler valideringen så igennem det vi har stående i
1) /etc/tcp.smtp.cdb (accept/deny/reject)
2) dnswl.mitdomain (local DNS white list)
3) dnsbl.mitdomain (local DNS black list)
4) relays.ordb.org (extern DNS black list)
Det tager toppen af junket.
Har man brug for flere check, sætter man bare nogle flere black list
providers ind ...
I det øjeblik en regel mødes, sker der ikke yderlig validering, men
connect får enten accept/deny/reject og ryger direkte til qmail-smtpd
eller bliver smidt på gaden uden eller med en fejl-besked.
Hvis en IP er white listed, checker vi derfor aldrig pkt. 3 og 4 - der
er f.eks. (IMHO) ingen grund til om og om igen at checke alle de seriøse
danske ISP's MTA IP'er op imod f.eks. ORDB eller andre externe baser -
er der bøvl med spam igennem en dansk ISP MTA, løses det sikkert
relativt gnidningsfrit og hurtigt af ISP'en selv.
rblsmtpd skriver sine fangster via syslog - man kan så hygge sig med at
glo i logfiles og evt. lave lidt statistik eller hvad man nu synes er
sjowt.
qmail-smtpd på email adresse niveau:
====================================
Det mail der således er nået frem til en egentlig SMTP session, møder så
hos qmail-smtpd en validering imod en
5) Local badmailfrom & badrcptto (reject)
Det er mailadresser og domains, man ikke gider se mail fra (badmailfrom)
henholdsvis til (badrcptto, den sidste her kræver en patch AFAIR).
china9988(AT)21cn.com (eller hvad de nu hedder i denne uge) eller blot
(AT)21cn.com er f.eks. ikke nogen vi gider ha' mail fra eller til (det
er vist trafik fra en relay-probe-fætter set dukke op flere gange, der
formodentlig er ude med riven for at finde et sted at dumpe en halv
million junk mails).
Andet sjow:
===========
Og endelig kan man, hvis mailen når så langt, f.eks. efter behov opsætte
en
6) Wintendo Virus scanner (f.eks odeiavir + F-prot)
Local user filtrer:
===================
og nået så langt evt. et
7) Local user-filter (procmail/maildrop/bogofilter/andet)
så user selv kan frasortere resten direkte, eller i MUA'en alt efter
X-header eller hvad man nu bliver enig om at gøre i den situation.
Bogofilter <URL:
http://bogofilter.sourceforge.net/ > er interessant,
fordi det kan lære, hvad den enkelte user betragter som spam.
Er der f.eks. tale om en remote user, sætter man evt. noget ala en
.qmail-bogo-spam
og en
.qmail-bogo-nospam
op for den pgl. user og lader dem gøre et eller andet passende i
relation til Bogofilter, når useren indsender spam eller ikke spam
(typisk en falsk positiv der skal elimineres) til 1 af disse
administrations-adresser.
Man kan også lave noget confirm-haløj, der vedligeholder den enkelte
users database over white listede afsender-e-mail-adresser.
F.eks. <URL:
http://smarden.org/qconfirm/ >
Man kan med andre ord lave en del hundekunster enkeltvis eller i
kombination for at forsøge at komme de uønskede mails til livs
Man kan sikkert også komme på flere metoder og hitte-på-ting, der kan
gøre livet surt i een eller anden gradbøjning for indkommende spam, men
her er da lidt inspiration at starte ud med ;)
--
Med venlig hilsen / Best regards
Peder