----- Original Message ----- From: "Jason R. Mastaler" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, March 06, 2003 3:56 PM Subject: Re: network IP based whitelisting
> Jesse Guardiani <[EMAIL PROTECTED]> writes: > > > I was wondering if anyone can think of a way that I could explicitly > > ALLOW mail from my network IPs? > > The basic problem though is that TMDA isn't at the right level to > detect network connections like this. This is really an MTA level > task. OK. I think I've done my homework on this now, and I agree. This has to be performed at the MTA level. Do you use qmail + TMDA? I do. And I think I have a theoretical solution to the problem when using the Qmail + TMDA combination. I propose the creation (not by the TMDA crew necessarily, but just in general) of an SMTP proxy daemon, similar to rblsmtpd (by DJB). This proxy will read a file similar to 'badmailfrom', but this new file will contain ALL of our internal domains that we wish to harden against FROM forgeries. We'll call this file "internaldomains". Everything in the qmail system will function as usual, unpatched, including tcpserver. Our new SMTP proxy will sit between tcpserver and qmail (or between rblsmtpd and qmail if you use rblsmtpd). Let's name the SMTP proxy: "denyforgedfromsmtpd" (I couldn't think of a good name!) Now, "denyforgedfromsmtpd", as I wrote above, will function very similar to rblsmtpd. It will carry on an SMTP conversation with the sender, looking for the from address (envelope from? or header from?). When it finds the from address, it will compare it against the "internaldomains" file, and the following logic will occur: 1.) If the message's "from" matches a record in "internaldomains", and RELAYCLIENT (set by tcpserver) is NOT set, the message is rejected (because we only want to allow clients on OUR network to send mail from OUR domains TO our domains). 2.) If the message's "from" matches a record in "internaldomains", and RELAYCLIENT _IS_ set, then the message is proxied on to qmail-smtpd (because we WANT _OUR_ domains to be able to relay and send email amongst themselves) 3.) If the message's "from" does NOT match a record in "internaldomains", then we proxy the message on to qmail-smtpd. (because we want our domains to recieve mail from everyone else in the world. The purpose of "denyforgedfromsmtpd" is to thwart attempts to forge mail from our internal domains addressed TO ANY of our internal domains. This allows us to open up the internal network and allow all of our internal domains to freely email each other without having to confirm and without fear of spam. TMDA takes care of spam from any external domains.) How does this logic sound? Are there any special bounces or special conditions that this system would dissallow or munge? I have limited knowledge of various MTAs and their capabilities. It sounds like it would work to me. What do you think? Thanks for reading! Jesse > > Right off the bat, you could use 'headers' to parse Received headers, > but this seems expensive and potentially unreliable. > > Here are a few ideas: > > You probably are already controlling who can relay messages through > your SMTP server. Could this be used as a signal to TMDA that the > message should be allowed through? i.e, if the message was relayed > through your network, it can be trusted. > > In a qmail/tcpserver environment, I believe RELAYCLIENT is set in the > environment if the client is cleared to relay. Unfortunately, this > variable doesn't appear to be available to .qmail files. > > Another option would be to add a header to the message if it > originated locally, which could later be detected by TMDA. > > Anyone have any other ideas (qmail or not)? > _____________________________________________ > tmda-users mailing list ([EMAIL PROTECTED]) > http://tmda.net/lists/listinfo/tmda-users > _____________________________________________ tmda-users mailing list ([EMAIL PROTECTED]) http://tmda.net/lists/listinfo/tmda-users
