----- Original Message ----- From: "Jonas Pasche" <[EMAIL PROTECTED]> To: "vpopmail" <[EMAIL PROTECTED]> Sent: Sunday, March 09, 2003 9:59 AM Subject: Re: [vchkpw] smtp filter proxy
> Hi Jesse, > > > I'd like to insert an SMTP filter proxy between tcpserver and qmail > > (or, in my case: rblsmtpd) that reads a file or cdb containing > > all of the domains in my rcpthosts file, and REJECTS messages that are > > addressed FROM one of those domains UNLESS the RELAYCLIENT > > environment variable is set (which would mean that it's legitimate > > email from one of my customers). > > Unlike rblsmtp, you'll have to let the SMTP session take place, because > you wouldn't have the envelope sender address. > > Thus, you need a filter between qmail-smtpd and qmail-queue. > > A generic filter is already available: > > http://untroubled.org/qmail-qfilter/ > > It's easy to implement, and there are a some simple examples in the > source tarball that show how you'd be able to write a filter that fits > your needs in any programming language you want. Will qmail-queue give me access to the RELAYCLIENT environment variable? If it WILL, then that's an excellent solution. If it WON'T, then it's coding time. > > > The idea seems relatively simple, and I can't immediately think of any > > problems with it. > > Let's say, I am [EMAIL PROTECTED] As I'm currently at home, I'm using > my local qmail server to relay mail to the outside. Though I don't use > the wingnet.net mail server, I have an identity called [EMAIL PROTECTED] > configured in my mail client. If you were a WingNET customer, and you were sending mail from home, you'd use our SMTP mail server to send mail. That's just the way it works. > > If I send some mail to your server (that is expected to be configured in > the way you said), it would not accept a mail from me to > [EMAIL PROTECTED], because I'm using wingnet.net (one of your domains) > as my From address, but I haven't authorized myself to relay, because I > don't relay through your server - I simply send a mail to you. Firstly, you could still send mail from [EMAIL PROTECTED] TO [EMAIL PROTECTED] as long as you use our SMTP server for your WingNET account and POPed before sending SMTP mail if you're not sending from an authorized IP address. That's why I need access to the RELAYCLIENT environment variable when I test for internal domains in FROM addresses. I will always let mail through if RELAYCLIENT is set, even if it contains an internal domain name in the FROM address. Second, let's say that you DON'T use WingNET's mail server, and that you relay through another company's internal mail server (like exchange or something). I would have no problem adding your SMTP server's IP address (or firewall IP address) to my /etc/tcp.smtp file so that RELAYCLIENT is set when your exchange server sends mail to my SMTP server. It's a web of trust, and I have no problem with that. Frankly, if you're sending from a large company that uses Exchange, I can probably use this opportunity to help you or your sys admin make your email network more secure. > > > And Implementing it would greatly reduce > > spam with forged headers claiming to be from one of my customers. > > No, even if you patch your mailserver, I'm still able to send out mail > appearing to be from [EMAIL PROTECTED] or [EMAIL PROTECTED] That's > simply not under your control. I wasn't talking about spam originating from my internal network. I'm talking about spam in my users inboxes. Spam originating from my internal network will be tracked down and eliminated quickly. > > Your idea has the following conclusions: > > 1) A wingnet.net user that isn't authorized to relay is able to send > mail to any local domain on your server, using any envelope sender > address he wants (but none from your domains!) Yes. And "authorized" here includes having an IP in /etc/tcp.smtp or having POPed before sending SMTP mail to my SMTP server. > > 2) A wingnet.net user that is authorized to relay is able to send mail > to any user in the world, using any envelope sender address he wants. Of coarse. > > 3) An outside user is authorized to send mail to you as long as he > doesn't use one of your domains that are managed by your server. Yes. Same as an "unauthorized" wingnet.net user. > > 4) You do not prohibit anybody in the world to send mail to anybody in > the world using one of your domains in his envelope sender address. Not sure what you mean by this. If you're an "authorized" wingnet.net user, and you send SMTP mail, it WILL be delivered. We won't place any restrictions on our customers as long as they are "authorized". > > I think, your idea simply isn't the right approach to your problem, > which I still don't completely understand. Please describe more > appropriatly what type of messages from whom to who you want to > disallow. Thanks for not calling me an idiot without first being sure that you totally understand (I've gotten a lot of that lately). I'm happy to clarify, and once you have an entirely accurate picture in your mind, I'm happy to THEN hear your comments on whether or not the idea is a good one. I'd like to note here that I see three possibilities for implementing this functionality: 1.) A "dumb" SMTP proxy that actively scans incoming SMTP traffic for internal domains in the FROM address (and possibly the envelope FROM address), while RELAYCLIENT is NOT set, and terminating the connection to the client and to qmail-smtpd if it detects an internal domain in the FROM address (again, this won't happen if RELAYCLIENT is set). 2.) A "smart" SMTP proxy that implements all of the functionality of qmail-smtpd (plus maybe SMTP AUTH and TLS/SSL) which sends all accepted messages(using the filtering techniques described above) via SMTP to the "Real" qmail-smtpd. This is almost like a full fledged MTA, except it only sends to one machine. 3.) A patch to qmail-smtpd that incorporates the desired functionality. All three choices have their advantages and disadvantages: #1 and #2 would greatly increase the CPU time necessary to recieve an SMTP message, but #1 would probably be relatively easy to code, and #2 could implement SSL/TLS/SMTP AUTH. #3 would likely be the easiest to code and place the least strain on the server's resources, but it's yet another qmail patch, and I dislike patches. However, I'm leaning toward #3 this morning. We'll see what I like in a few weeks... So, what are your thoughts, Jonas? Still think it's a bad idea? Thanks for reading. Jesse > > Jonas > > >
