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 On Jul 25, 2012, at 1:14 PM, Eric Shubert wrote: > On 07/25/2012 10:13 AM, Sam Clippinger wrote: >> As for not setting the RELAYCLIENT variable unless the user authenticates, >> unfortunately that isn't possible: >> http://www.spamdyke.org/documentation/FAQ.html#SUGGESTION8 > > Isn't possible, or isn't easy to do? Please pardon my ignorance. > > In the case where spamdyke is handling authentication, why is it not > possible to delay invoking qmail-smtpd until after authentication has > taken place (or not)? > > The FAQ says: > spamdyke must determine what environment variables to set before it > starts the qmail-smtpd process (because after qmail-smtpd has been > started, spamdyke can't change its environment). For that reason, > spamdyke always sets the RELAYCLIENT environment if it has enough > information to run its relaying filter. > > So I guess the key is what's considered to be "enough information". In > my mind, "enough information" would include whether the sender has > authenticated or not. > > The FAQ continues: > That way, qmail-smtpd will not prevent relaying if spamdyke determines > it is allowed (e.g. because the connection is whitelisted). > > Does whitelisting take precedence over authentication? I don't think it > should. Doing so would create an open relay for the whitelisted entry, > which I think creates an unnecessary security hole. When I whitelist > something, I only want to allow them to bypass the spam filters, not > allow them to relay to domains outside of my host. No? > > BL, I think if spamdyke is going to handle authentication processing > (and relay control) effectively, it's going to need to invoke > qmail-smtpd only after authentication has occurrred (or not). > > Thanks for your patience with me on this, Sam. > > -- > -Eric 'shubes' > > > > _______________________________________________ > spamdyke-users mailing list > [email protected] > http://www.spamdyke.org/mailman/listinfo/spamdyke-users _______________________________________________ spamdyke-users mailing list [email protected] http://www.spamdyke.org/mailman/listinfo/spamdyke-users
