On 07/25/2012 12:28 PM, Sam Clippinger wrote: > Well, "enough information" in this case refers to the options you're used in > the configuration file. If spamdyke knows what domains it controls > (local-domains-file or local-domains-entry) and knows the relaying rules > (access-file), it has enough information to control relaying and it sets > RELAYCLIENT. > > Changing a process' environment variables after the process has started is > impossible. As for starting qmail-smtpd after authentication, I suppose > nothing is absolutely impossible, but it would be difficult. Very difficult, > given spamdyke's current code structure. > > In order to start qmail-smtpd after authentication, spamdyke would have to > cache the entire SMTP conversation until that point, then start qmail-smtpd > and replay it. That would mean spamdyke would have to fake two parts of the > conversation: it would have to send its own greeting banner and it would have > to send its own list of capabilities. The greeting banner isn't a big deal, > it's almost always ignored by mail clients as long it contains at least some > text. The capabilities list is important, however. That's how the server > tells the client whether it supports authentication (and what protocols it > uses), TLS, pipelining and other stuff. spamdyke wouldn't know what to say > except for authentication and TLS, if they were configured. That would > effectively remove features from the mail > server, since clients wouldn't know they were supported. > > Also, if this delay is added for authentication, I think it should probably > also be added for the other filters as well. For example, if the recipient > address could possibly be whitelisted, spamdyke should delay starting > qmail-smtpd until it knows for sure. If the address isn't on a whitelist, > there's no point in setting RELAYCLIENT. (The same is true of the sender > whitelist.) But that's even more problematic, because now spamdyke is > caching a huge part of the SMTP conversation without knowing what > qmail-smtpd's real responses will be. For example, if qmail-smtpd has been > patched to do recipient validation or quota enforcement, spamdyke might > accept a recipient address that qmail-smtpd will reject when the conversation > is replayed. Then the client thinks the address was accepted but > it wasn't -- what to do? > > One possible workaround would be to save the conversation AND run qmail-smtpd > (as it does now). Then if authentication succeeds or a whitelist is > triggered, spamdyke could kill qmail-smtpd, set the RELAYCLIENT variable, > restart qmail-smtpd and replay the conversation up to that point. That is, > unless qmail-smtpd has been patched to change its behavior after > authentication, which means some of its responses might change. > > Caching conversations also gets tricky due to memory usage -- if spamdyke > tries to use too much memory, the "softlimit" program (if in use) will cause > it to malfunction. Even without "softlimit", spamdyke needs to be very > careful about its memory footprint (busy servers, lots of connections, > limited RAM). The data can be cached to disk, but then there's a risk of > stale cache files, running out of disk space and exposing sensitive > information. > > spamdyke wasn't written with any of this in mind; it'd take a pretty big > overhaul of the codebase. So it's difficult.:) Patching simscan is much > easier. > > As for whitelisting vs. authentication, they're the same thing as far as > spamdyke is concerned. Either one turns off all of spamdyke's filters and > allows relaying. That's a holdover from the days before spamdyke supported > authentication -- when I added the authentication code I just made it set the > same flag as the whitelist code. FWIW, I disagree that whitelisting > shouldn't allow relaying -- I often use it for exactly this purpose, > especially when sending email from web servers. > > BTW, what does "BL" mean? > > -- Sam Clippinger
I'm beginning to see the difficulties presented with spamdyke handling authentication. I'm going to have to disagree with you though regarding the nature of authentication and relaying vs. whitelisting. I don't believe they're naturally the same, although spamdyke treats them as such. In a traditional setup, the ability to relay (more appropriately termed "submit" IMO) is controlled by authentication and by IP address via tcpserver, and nothing else. Whitelisting has had no effect on relay. This seems to me to be adequate and appropriate. From what you describe, when spamdyke is configured with access-file, whatever whitelist entries exist (regardless of their type) now become able to submit to external domains (relay), making the host more of an open relay than I would like. While whitelisting is something that's to be discouraged, its use becomes significantly more dangerous when access-file is used, given that anyone who can can spoof any one of the whitelisted entries can also use the host as a (semi-open) relay. This makes me very hesitant to use spamdyke's access-file configuration option as it's presently implemented. I don't mind whitelisting so much when its effects are limited to local domains, but when it can affect external domains and increase the risk of my IP address being blacklisted, I'm wary. Am I misunderstanding anything here? Of course I'm not about to throw the baby out with the bath water. :) I see what you mean regarding spamdyke having to fake the greeting and capabilities replies. The greeting is of course trivial, as the smtpgreeting file is already there, and could be an additional spamdyke parameter. Faking the capabilities is a little trickier, given that there's no persistence anywhere. They could be cached in a file somewhere, but that leaves the problem of knowing if and when they've changed. Two options here are to either start up a dummy qmail-smtpd and query it for its capabilities (fairly expensive to do for every session I would think), or manually set up a "capabilities" configuration for spamdyke to use. I think the later would be a better approach of the two, although neither is attractive. I don't think the "delay" (as you call it) should be added for or applied to any (other?) filters. As you pointed out, that gets to be a real mess, and I don't see any value or purpose in doing so. I'm not really comfortable using spamdyke's access-file parameter as it's presently implemented, which means that using spamdyke for authentication is a no go for me. That's unfortunate, as I was hoping that spamdyke might one day be able to enforce use of encrypted passwords. Might spamdyke be able to do so without handling authentication itself? That would seem to be fairly easy to do. Much easier than delaying qmail-smtpd at any rate. I'd like to conclude by looking at perhaps another way to let the scan controller (be it simscan or amavisd-new) know that authentication has taken place. It's not so tough as it turns out. Here's from a header of a message authenticated by qmail-smtpd: Received: from unknown (HELO ?192.168.70.31?) ([email protected]@192.168.70.31) by tacs-mail.shubes.net with ESMTPA; 26 Jul 2012 00:49:59 -0000 Here's from a header of a message authenticated by spamdyke: Received: from unknown (HELO ?192.168.70.31?) (192.168.70.31) by tacs-mail.shubes.net with SMTP; 26 Jul 2012 00:56:17 -0000 The scan controller (ie simscan) could conceivably tell from the message header whether or not this is a submission (authentication has taken place). Provided of course that the relevant information (authentication account) is there. When qmail-smtpd authenticates, it's there ([email protected] in this case). When spamdyke authenticates, it's not, simply because qmail-smtpd generates the Received: header, and the qmail-smtpd isn't aware of any authentication data when spamdyke does the authentication. Which begs the question, why doesn't spamdyke insert a Received: line in the message header? It could be done in the same way that qmail-smtpd does, and provide authentication data when it does the authentication. Then it could be left up to the scan controller to determine whether or not authentication has taken place based on the contents of the first 1 or 2 message header Received: lines. Of course simscan would need to be patched to do this. Even if spamdyke and simscan were made to play well together, I still have reservations about the way whitelisting is handled with spamdyke authentication. So the Bottom Line (BL) appears to me to be, if qmail-smtpd has the smtp-auth patch, use it. I see no advantage to using spamdyke's auth capability, while there are a couple disadvantages. I'd still like to have a way to enforce encrypted passwords though (TLS/SSL or cram-md5). That would be a very valuable feature regarding security. As always, thanks for the great work, Sam. I hope I haven't tested your patience with all this. ;) P.S. Not that it matters to me, but using spamdyke's authentication would also defeat the badmailfromnorelay and badmailtonorelay parameters. I don't expect they're used much, but I could see where badmailtonorelay might be useful in some situations. -- -Eric 'shubes' _______________________________________________ spamdyke-users mailing list [email protected] http://www.spamdyke.org/mailman/listinfo/spamdyke-users
