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 the unskilled user. Feel free to call me an elitist bastard though. I anticipate this is one more point we'll have to agree to disagree on. > >> On the other hand, if the tcpserver daemon (or a replacement) sets an > >> environment variable that affects a child process, you may not realize > >> it also affects spamdyke. You could easily spend many hours trying to > >> understand why spamdyke is "malfunctioning", never realizing that a > >> setting intended for an unrelated filter was also affecting spamdyke. > > > > My response to a person in this situation would be that if they don't > > understand how their system works, they should make a better effort or > > change careers. :) > > That's pretty cold comfort when a server is down and mail is being lost! It's already too late then, of course; but nobody should be placed in charge of a critical system they are not equipped with the skills to fix. Anyway, we're veering off course here, so I'll just censor my further thoughts on this matter. > I myself have considered changing careers when faced with corrupted MS > Exchange data files in the middle of the night. Since Windows services > (especially Exchange services) communicate almost exclusively through > sockets and pipes, troubleshooting malfunctions is a nightmare. Since > Exchange relies almost exclusively on binary files written in secret > formats, repairing damage is nearly impossible. I know that's an extreme > example but my point is this: Understanding how a system works doesn't > always make it easy to fix. If the data and configuration passed between > processes is visible, less voodoo is required to troubleshoot problems. The issue here was that Exchange was uncooperative in providing you with the data needed to nail down the problem. Since you're writing spamdyke, you can make it arbitrarily cooperative without making it less perfect. Also, since it's open source, anyone can make it more cooperative for themselves (which is obviously not true for Exchange). > > Consider $RBLSMTPD: already, spamdyke isn't a drop-in replacement for > > rblsmtpd, because it doesn't support that variable. If I were to replace > > rblsmtpd with spamdyke configured to use the same DNSBLs and just expected > > it to work, I would see my existing whitelist settings being ignored, and I > > would have to configure them again, in a different place, in a different > > way, with no benefit. > > spamdyke was never designed or intended to be a drop-in replacement for > rblsmtpd. spamdyke contains features that supersede rblsmtpd's but they > don't work exactly the same way. That has never been a goal. Yet you also wrote: > > > A major part of spamdyke's appeal is its "drop-in" design -- system > > > administrators can try it quickly, see if it works and remove it just > > > as quickly. If you just try spamdyke quickly, it won't work, because it will refuse some mail based on RBL checks that rblsmtpd wouldn't even have performed because of tcpserver-based whitelisting using $RBLSMTPD. (Likewise, it will accept some mail that rblsmtpd would have dropped, but that's less of a problem.) > In your example, I don't see why you would need to duplicate your > whitelist settings for spamdyke. Instead, why wouldn't you move them? > Obviously they're stored somewhere/somehow for tcpserver to set the > RBLSMTPD variable, why would you expect to continue providing that > variable _and_ provide a whitelist file for spamdyke? The RBLSMTPD > variable isn't needed any more, so you should be left with one whitelist > configuration, not two. Why is it reasonable to reconfigure your DNS > RBLs for spamdyke but not the whitelists? You're right; $RBLSMTPD based whitelisting is not a good example for a case where configuration duplication necessarily results. The variable is just plainly more efficient than a whitelist, because it's set based on the contents of a cdb on a per-IP basis and there is no need to search a text file. It's also more flexible because an arbitrary mechanism can decide whether to set it (and to what value) or not. > > tcpserver can set arbitrary environment variables for its children based on > > the IP of the client (and other factors). RELAYCLIENT and RBLSMTPD are > > probably the most often used in qmail environments. I think you should > > re-use at least those, and indeed set RELAYCLIENT for qmail-smtpd yourself > > if spamdyke decides that the client is allowed to relay. > > spamdyke does use (and set) RELAYCLIENT. That's an example of spamdyke > supporting an environment variable because it is needed to interoperate > with existing software. But since I wasn't aware of RBLSMTPD until you > suggested it, I don't believe it's widely used. I certainly don't > remember seeing any mention of it in any of the qmail books or guides > I've read. That may be because rblsmtpd is not part of the qmail package but of the ucspi-tcp package. I don't know; I've read about it in http://cr.yp.to/ucspi-tcp/rblsmtpd.html (the official documentation). > > Patched versions of qmail rely on a plethora of other envvars to turn > > certain features on or off; for example, MFDNSCHECK controls whether qmail > > should check for the existence of the envelope from domain before accepting > > the mail. TARPITCOUNT determines how many different recipients a client may > > specify before responses to it start being delayed. DATABYTES can be used to > > set a per-client message size limit (useful for vendors who insist on > > sending 500k newsletters but who you don't want to block altogether :). > > I recall a thread on the QmailToaster list (just last month) where > someone had problems with their qmail server and they were advised to > add 'NOP0FCHECK="1"' to their /etc/tcp.smtp file. It fixed the problem > but no one knew why. No one (not even Google) could explain which > program used the variable or exactly what effect it had. One of QT's > authors finally had to do some research (in the code) to find an > explanation. > > If that doesn't convince you that environment variables are a bad way to > pass configuration information, nothing will. :) It convinces me that undocumented, obscure environment variables are bad, but I never disputed that. :) Andras -- Andras Korn <korn at chardonnay.math.bme.hu> <http://chardonnay.math.bme.hu/~korn/> QOTD: Bank error in your favor. Collect 200. _______________________________________________ spamdyke-users mailing list [email protected] http://www.spamdyke.org/mailman/listinfo/spamdyke-users
