Re: qmail is officially public domain. have at it lads!

[Hugo Monteiro <hugo.monteiro@xxxxxxxxxx>]

Hello Erwin,

Erwin Hoffmann wrote:
> Hi Hugo,
>
> At 00:09 07.12.2007 +0000, Hugo Monteiro wrote:
>   
> > Erwin Hoffmann wrote:
> >     
> > > Hi
> > >
> > > At 21:07 06.12.2007 +0100, Tino Reichardt wrote:
> > >   
> > >       
> > > > * Erwin Hoffmann <feh@xxxxxxxxx> wrote:
> > > >     
> > > >         
> > > > > Hi
> > > > >       
> > > > >           
> > > > And DKIM.
> > > >     
> > > >         
> > > Yes. I agree. But while preparing SPAMCONTROL 2.5 for now about 1 year, I
> > > think it simply not a good idea to put that much code into qmail.
> > > Rather, rblsmtpd (or whatever this might called) is the place where to
> > > place all those DNS lookups. 
> > >
> > > DKIM by itself is so compliated that it would infere with the design of
> > >       
> qmail.
>   
> > > Lets do qmail the SMTP/QMTP part. 
> > > Lets try to delegate TLS/Authentication/DKIM/SPF/Greylisting/Greetdelay to
> > > somewhere else. 
> > >
> > >   
> > >       
> > Correct me if i'm mistaken, but at least for TLS, Greylisting and 
> > Greetdelay, the last two in order to get them working properly, you HAVE 
> > to include code in qmail-smtpd. They all need to happen on the SMTP level.
> >
> > In the case of TLS, not to be mistaken for SSL (which can and should be 
> > supported in tcpserver/inetd/whatever), the server has to announce it's 
> > support through the 250-STARTTLS, amongst the other supported features.
> >     
>
> You are taking about STARTTLS support.
> The answer to that question is: Yes and No.
> As implemented in SPAMCONTROL 2.4 qmail-smtpd talks SSL/TLS thru sslserver.
> There is *no* OpenSSL lib included into qmail-smtpd, only the interface to
> sslserver -- and thats a big difference.
>
>
>   

I didn't, and still don't, know in detail the SPAMCONTROL set of 
patches, but i was able to take a peek at the docs regarding the 
starttls implementation. Having a tcp server embedding the starttls 
conversation for the smtpd is another, very valid, approach. I will have 
to try it myself on a close occasion.

> > Greylisting, as defined in http://projects.puremagic.com/greylisting, 
> > which i believe where all started (maybe i'm mistaken), states that you 
> > need 3 values to implement properly. An origin (connecting server IP 
> > address), a sender and a recipient. If the first one you can get the 
> > value right at the connection level, the last two you need an 
> > established SMTP conversation. And while were at it, and although not 
> > part of the greylisting itself, we can also perform HELO checking.
> > My sugestion on this matter would be integration with Policyd. I ported 
> > a patch by Anton Ludin to perform envelope scanning for qmail-ldap, but 
> > that patch was originally written for qmail. Somehow i cannot find the 
> > original link. I leave you with the qmail-ldap patch link. The relevant 
> > part refers to qmail-smtpd.c and qmail-smtpdpol.c.
> >     
>
> I haven't look at those patches and enhancements yet.
> Thus Greylisting *might* work for now, it is bullhshit by design.
>   

True, but while there isn't a better protocol for mail delivery being 
used as "the facto", we will have to try hard and catch up, if not be a 
step ahead, to the evil doers. I also see greylisting as an 
improvisation, but right now it just works and works very well, at least 
for me.
> Even to do it properly, needs a lot of attention. To pick up the ideas of
> Postfix (policy daemon) is - from my point of view - even worse. 
>   

Why is it worse? I provides me a way to do efective greylisting, 
blacklisting, whitelisting, by origin, by sender, by recipient. It also 
allows me HELO checking with auto blacklisting. All this with a very 
small change on the smtpd code. I can use it with the number of frontend 
MXs i want with the burden of one single install (1 = N) and make all 
those servers know "who the bad guys are". I can manage all this, which 
in the end is an SQL database in a centralized manner, without having to 
go around copying files from a server to another or setting up network 
filesystem mount points.
Of course, there are many ways to skin a cat, i like this one 
particularly and it's been a real joy to manage things like this. I 
brought up this solution just because i'm very pleased with the outcome 
and thought others might be interested in such approach.

> Greylisting *always* puts the effort (at least cleaning the DB) to the
> recipient MTA. It also puts the burden on regular MTA. It *assumes* that
> the BotNets PC has vanished after the Greylist period. 
>   

Yes, i have a cronjob that manages the database. It uses a tool that's 
part of policyd and takes care of the database from the definitions of 
the policyd server itself. Was a walk in the park to set up. It's a walk 
in the park to maintain. Runs every night in it's own server and doesn't 
bother anyone.

Also greylisting doesn't assume anything. It hopes that in the very 
least that the botnet pcs don't try to send the from the same origin, 
from the same sender, to the same recipient. From what i've watched so 
far its preys have been listened. The very small amount of spam that 
does get in is usually from open relays or spam hosts, i.e. true smtp 
servers.

> Punishing the innocent and hoping that the evil guys don't try it again is
> real good policy.
>
>
>   
> > http://pessoa.fct.unl.pt/hmmm/files/anti-spam/qmail-ldap/qmail-ldap-1.03-20
> >     
> 060201-envelope-scan-0.5.patch
>
>
>   
> > As for Greetdelay, maybe it could be implemented inside tcpserver or 
> > similiar. What shouldn't happen is simply putting a delay in the way 
> > between tcpserver and the smtpd. Will that delay prevent a bot from 
> > sending it's spam anyway, being buffered in any way and therefor treated 
> > by the smtpd? 
> >     
>
> rblsmtpd is the place where Greetdelay should live.
>
>   

Or even tcpserver or sslserver for that matter. My point was that for it 
to work you have to get until the DATA stage. You cannot perform 
greylisting based solely on the incoming ip address.

> > Even if that doesn't happen, with this approach you will 
> > exhaust your server resources since the connection will be there if the 
> > spammer is patient enough to see the outcome. 
> >     
>
> Pls quantify your statement. What resource? Are you talking about TCP
> buffers ? Todays hardware and OS (together with qmail) can easily setup to
> cope with > 4K incoming sessions. Thus, what are you taking about ? 
>
>   

The resource i was talking about was concurrencyincoming. Do you have 
any setup with concurrencyincoming >= 4000 ? If so, i would like to know 
the kind of hardware you are using and for how many user accounts.

> Of course, in the meantime (during Greetdelay) I use the remote's resources.
> Or course, the spammer can wait and send the mail anyway. 
>
> But Greylisting cost him nothing. Not even a waste of bandwidth.
>
>   

Why can't we have both greetdelay AND greylisting? I use them together i 
don't have complains. (greetdelay first, greylisting after, of course)

> > The correct approach would 
> > be to delay the SMTP talk and drop the connection if there isn't RFC 
> > compliance (client has to wait for server greeting before issuing any 
> > data). See John Simpson's greetdelay patch.
> >     
>
> Please give me any figures about the efficiency of the approach. 
> Why not implement this a general feature of qmail-smtpd, if you think this
> patch covers a protocol error ?
>
>
>   

The RFC doesn't say that the sender MUST wait for server greeting. It 
says SHOULD. There is a huge difference. I believe it should be part of 
qmail-smtpd yes, but on a configurable basis. Not a default behavior.

>   
> > My 2¢,
> >     
> My 1c in return
>
>   

Guess i just spent the money you sent back.



Hugo Monteiro.


--
ci.fct.unl.pt:~# cat .signature

Hugo Monteiro
Email	 : hugo.monteiro@xxxxxxxxxx
Telefone : +351 212948300 Ext.15307

Centro de Informática
Faculdade de Ciências e Tecnologia da
		   Universidade Nova de Lisboa
Quinta da Torre   2829-516 Caparica   Portugal
Telefone: +351 212948596   Fax: +351 212948548
www.ci.fct.unl.pt	      apoio@xxxxxxxxxx

ci.fct.unl.pt:~# _