Re: [spamdyke-users] feature requests :)
On Tue, Apr 08, 2008 at 11:40:48PM -0500, Sam Clippinger wrote: Andras Korn wrote: On Tue, Apr 08, 2008 at 12:38:38AM -0500, Sam Clippinger wrote: blacklist connections at the TCP level. tcpserver (or its replacement) should only set appropriate environment variables based on the tests it has carried out and leave blacklisting to the next program in the chain, which speaks the application layer protocol concerned (SMTP in this case). This way, spamdyke needn't duplicate the work of tcpserver and can still obtain envelope information before refusing the mail. I think we're just going to have to agree to disagree on this. I OK. :) way.) The fact that environment variables are not easily visible to external viewers is a show-stopper for me. I still think though that as long as their contents can be logged by the child process that is using them, this is a non-issue. That's certainly one possible conclusion, but if you look at it this way, you could just as well implement your own SSL support or C library. IMHO it is perfectly acceptable for some features to only be available on some systems. I think the Unix Way is to re-use as much of what already exists as possible in order to minimize duplication of effort and to better focus development. A single tool should do a well-defined set of related things, and do that exceptionally well, while providing the ability to combine effectively with other tools. I wouldn't want ls(1) to have the features of find(1) just to be self-sufficient. implement in a reasonable timeframe.) As for reimplementing the C library, I have no problem with writing new code when the existing library doesn't meet my needs. Sure; the point I was trying to make is that it's often not a good idea to write your own code just for the sake of doing so if there is existing code that would do the job. Some reasons: - you may introduce bugs that are not present in the existing implementation (because you're working with something you're not yet experienced in, this is arguably pretty likely); - fewer eyeballs will see your code than that of the existing standard implementation, which means that security problems will probably be noticed later; - you don't automatically benefit from the continued development of the standard implementation. (Interestingly, DJB reimplemented portions of the C library when he wrote qmail and its supporting tools. For example, most of the memory allocation routines and string functions used by qmail are DJB's code, not the system library's.) I know, and part of me hates DJB for that. It makes his code a nightmare to modify, and modifications very hard to get right. At least he did it for good reasons, but with blatant disregard to everyone else. It's one of the reasons why qmail and most other djbware isn't more open. Your description of The Unix Way could just as easily be described as The Reusable Way or The Library Way or even The Free Software Way. As True. well with it. As I get requests for changes to work with a project/patch I've never heard of, I try to determine if the changes will benefit a large enough audience to be worthwhile. So far, you are the first person to request that spamdyke support environment variables the way rblsmtpd does. If other people also request it, I'll reconsider my position. I understand. If I can find the time, I may write a patch that does what I want. I don't think of myself as a programmer and I teach Unix system administration at a university. I may just have been lucky so far, but most of my students know about strace and are able to use /proc even before they enrol for my course. I think you're being unfair to system administrators here, or are including untrained computer operators in the term. As I see it, the important thing however is that specialist software shouldn't be designed to meet the needs of laymen; it should be built to best support the trained expert while being as useful as possible to those with less than expert knowledge but a willingness to learn. [snip] I wouldn't put anyone to whom daemon processes are mysterious in charge of a critical service. I certainly mean no disrespect to you, your students or any other system administrator. I know, I was just amazed that you think of sysadmins as, let us say, less than well trained for their jobs. However, on the mailing lists and forums I read, I see many questions from administrators who are obviously not familiar with the tools you've mentioned. This is a pretty sad state of affairs, but I don't think it's reason enough to develop system software that meets the needs of laymen at the expense of experts. Spamdyke is not an end-user tool, after all. If someone doesn't have the skills necessary to use it, they should acquire them, and it shouldn't be the software that is made less efficient or dumber to accommodate
Re: [spamdyke-users] let qmail decide if it accepts a recipient before doing RHSBL?
The RHSBL filter checks rDNS names and sender addresses, not recipient addresses. It also produces permanent rejection codes, not temporary ones. If you're seeing the same sender rejected repeatedly, it's because the remote server is sending repeatedly. Also, spamdyke should be disconnecting (and killing) qmail as soon as the blacklisted sender is given (depending on your configuration -- if you're using a recipient whitelist, qmail is disconnected after the RCPT command). After that, all SMTP traffic is answered by spamdyke (with rejection codes). So at least for that short time, spamdyke is saving resources. However, with regard to blacklisted recipients, the reason spamdyke runs its filters before passing the RCPT command to qmail is because there may be multiple recipients. Once a recipient has been passed to qmail, it cannot be removed. Passing the RCPT command just to check the status code would effectively defeat spamdyke. For example, imagine an unpatched qmail server. The remote server names a blacklisted recipient, spamdyke passes it to qmail, checks the status code, then sends a rejection to the remote server. Then the remote server names a second recipient that is not blacklisted. spamdyke must allow the message to pass through because the second recipient is legitimate. However, because the first recipient was already sent to qmail, that recipient will also receive the message. -- Sam Clippinger Andras Korn wrote: Hi, since I installed spamdyke my logs are inundated with messages like this one: DENIED_RHSBL_MATCH from: [EMAIL PROTECTED] to: [EMAIL PROTECTED] origin_ip: 85.179.173.120 origin_rdns: e179173120.adsl.alicedsl.de auth: (unknown) The recipient address is bogus and my (patched) qmail-smtpd would reject it permanently. Apparently, since it matches a RHSBL, spamdyke rejects the message temporarily, and the same client keeps trying for a while, always costing me some resources. I think this is wasteful; it would be better to only do the RHSBL lookup after the backend qmail-smtpd accepted the recipient address. If the backend qmail-smtpd throws a permanent rejection, spamdyke could just pass it on to the client. Andras ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
Re: [spamdyke-users] let qmail decide if it accepts a recipient before doing RHSBL?
On Sat, Apr 12, 2008 at 06:10:04PM -0500, Sam Clippinger wrote: The RHSBL filter checks rDNS names and sender addresses, not recipient addresses. I know. It also produces permanent rejection codes, not temporary ones. OK, with RHSBL, that is probably justified. However, I hope RBL by default produces temporary rejects? If you're seeing the same sender rejected repeatedly, it's because the remote server is sending repeatedly. Strange that they didn't do it so far, but apparently this is the case. Also, spamdyke should be disconnecting (and killing) qmail as soon as the blacklisted sender is given (depending on your configuration -- if you're using a recipient whitelist, qmail is disconnected after the RCPT command). After that, all SMTP traffic is answered by spamdyke (with rejection codes). So at least for that short time, spamdyke is saving resources. However, with regard to blacklisted recipients, the reason spamdyke runs its filters before passing the RCPT command to qmail is because there may be multiple recipients. Once a recipient has been passed to qmail, it cannot be removed. Passing the RCPT command just to check the status code would effectively defeat spamdyke. For example, imagine an unpatched qmail server. The remote server names a blacklisted recipient, spamdyke passes it to qmail, checks the status code, then sends a rejection to the remote server. Then the remote server names a second recipient that is not blacklisted. spamdyke must allow the message to pass through because the second recipient is legitimate. However, because the first recipient was already sent to qmail, that recipient will also receive the message. I'm not sure I understand what you're saying. If a recipient is blacklisted in spamdyke, spamdyke should of course reject it. If it is blacklisted by qmail, qmail will reject it and spamdyke needn't worry about it. The SMTP conversation can continue, with each recipient specified by the client being treated as above. Finally, if any recipients were accepted by the backend qmail, spamdyke can check RBL and RHSBL, and if there is a match, reject the client temporarily (for RBL) or permanently (in the case of RHSBL), and send a QUIT to the backend qmail. The costly DNS lookups needn't be performed at all if qmail rejects all recipients. I see no situation where this scheme would result in mail being passed to recipients who would otherwise not receive it. I think all feasible local tests should be carried out before resorting to remote tests, because those can be (and typically are) much slower. Andras -- Andras Korn korn at chardonnay.math.bme.hu http://chardonnay.math.bme.hu/~korn/ QOTD: When I was your age, we had to walk ten miles to a node. ___ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
