Sam, Thanks so much for your very clear and thoughtful reply. I'll comment as we go this time so I don't need to establish context.
On 07/26/2012 02:12 PM, Sam Clippinger wrote: > You have not yet begun to try my patience. :) I'm certainly glad for that! :) I hope you'll not hesitate to let me know if and when I do. > I guess I just don't understand the full difference between the way you think > of whitelisting and authentication. Sometimes I don't either. ;) I guess I never thought of whitelisting having an effect on relaying, probably because it never did before. I've always thought that authentication and tcp.smtp rules were the only things that affected relaying. > Here's how I think of them: > When I have a machine (e.g. a web server) that needs to send mail using my > mail server without being blocked, > I whitelist it. > That bypasses all of the spam filters and allows the remote machine to send > email to remote recipients (relaying). > In the absence of spamdyke, I would add that machine's IP address to my > /etc/tcp.smtp file instead. I've typically done the later, as whitelisting with spamdyke to accomplish this only works when spamdyke is handling authentication (and thus relaying). I certainly would like to get rid of the need for the tcp.smtp file entries, and this would do it. Instead of whitelisting though, I would expect to add the IP to the access-file. In my mind, an access-file entry would whitelist (as well as allowing relay), but a whitelist entry would not allow relay (as it does now). > When I have a user who travels around with his laptop and needs to send email > through my server > to remote recipients, I ask him to authenticate. That bypasses the spam > filters and allows him to send > to remote recipients (relaying). In the absence of spamdyke, I would need a > patched version of qmail. All users, traveling or local, typically authenticate (of course). I think that we all probably used a version of qmail with the smtp-auth patch before spamdyke 4.0 (and I'm guessing many if not most still do), but it would indeed be nice to be able to run qmail w/out the smtp-auth patch. In fact, I'd like the stock QMT to have spamdyke do authentication, as it's more flexible (can use different authentication mechanisms via simple configuration). A potential problem just occurred to me though. QMT uses the (preferred default) submission port 587, and includes a qmail-smtpd patch which forces authentication (export REQUIRE_AUTH=1). While spamdyke wouldn't typically be used on the submission port (since all connections must authenticate, the filters are pointless), I would still consider putting spamdyke in the submission pipe for a) authentication and b) logging capabilities. Spamdyke would need an smtp-auth-level=required option (or some such) in order to do this though. I haven't asked for this enhancement yet, have I? I guess I'm asking now. ;) > When I have a legitimate sender who is trying to reach one of my users but is > being blocked by a filter, > I whitelist him. That bypasses all of the spam filters. > Depending on how I whitelisted him, it may allow him to send to remote > recipients. Ditto. Because I'm still using qmail to authenticate though, relaying is prohibited (with a global whitelist). > Perhaps the last scenario is the problem you're describing -- if I add the > sender to a global whitelist > (e.g. not using a configuration directory), this sender can now use my server > as a (nearly) open relay. > If I added him by IP or rDNS, he could use any sender address he wanted > (fully open relay). > If I added him by sender address or sender domain, he could only relay if he > used the whitelisted sender address. > If I added him by sender address using a configuration directory so it only > affects the recipient's domain, > he can't relay at all. Bingo. :) I must admit that in an effort to KISS, I've avoided configuration directories up 'til now, and all my whitelisting has thus been host wide (not exactly global). > I guess that could be considered a problem, except for a few considerations. > First, I don't (as I assume you don't) just whitelist anyone who asks -- one > of my users has to make the request. > Then I ask the sender to fix the problem that caused the rejection. > I often find that senders who are having trouble reaching my users are also > having problems reaching > lots of other people too -- i.e. they've been blacklisted somewhere or they > have no rDNS. I do the same, and attempt to keep whitelisting at an absolute minimum. > Second, I very rarely use the global whitelists. > I prefer to whitelist a sender's domain within a configuration directory for > the recipient's domain. > That effectively allows anyone in the sender domain to send to anyone in the > recipient domain. > It prevents relaying and it also prevents them from spamming anyone else on > the server (e.g. me). This is absolutely brilliant! By whitelisting only on a domain level, relaying becomes a non-issue. > Third, I have trouble picturing a spammer using this route to gain access to > a server. > They'd have to contact one of my users somehow, convince them they are > legitimate, > convince them they are being blocked and ask the user to ask me to whitelist > them. > If I used the global whitelist, they'd be able to relay until I caught them > and removed the whitelist entry. > Anything's possible of course, but that seems a little farfetched to me. I'm not going to disagree that the likelihood of actual exploit is small. I simply prefer eliminating the possibility in its entirety, so such speculation is moot. The point I've come to realize, which I think is important, is that when spamdyke handles authentication instead of qmail, the nature/effects of whitelisting changes. When spamdyke authentication is active, whitelists should be configured (applied) only to local-domains in order to be secure. While this isn't too imposing to me personally with only a handful of domains, this could be daunting for servers with 10s of domains. A seemingly simple remedy to this might be to have a "local-domains" configuration directory such as _recipient_/local-domains, where whitelist entries could be put which would be applied to all local domains. This would be consistent with spamdyke's treatment of whitelists when qmail's authentication is used (the behavior would be the same). Let's consider something though. When would anyone want or need to whitelist in such a way as to provide an open relay (iow, whitelist non-local-domains, or globally)? The case you identified first above (a web server) can be given this capability via the access-file option. This is equivalent a whitelist_ip entry, if I'm not mistaken. I can't think of any other situation where a whitelist entry would intentionally be used to give a client/sender relay capability. That doesn't of course mean there isn't one. The current spamdyke processing requires the administrator to change their whitelist configuration when changing from qmail auth to spamdyke auth in order to achieve the same behavior. In addition, the required change is cumbersome. Would it not be better if spamdyke were to apply whitelists only to local-domains? This would make spamdyke's whitelisting behavior consistent regardless of which authentication method is used, in addition to prohibiting administrators from inadvertently configuring spamdyke such that it creates a somewhat open relay, while providing adequate capability for allowing an open relay (by IP address only). In this sense, whitelists aren't 'global', they're 'host only', as they should be IMO. These are my latest thoughts on this aspect. I look forward to your reply. The remaining part here is a separate issue, having to do with the original subject. The crux of this matter concerns the question of how a scan controller (simscan/amavisd-new) is made aware that authentication has taken place, so that spamassassin can be bypassed. > As for adding headers to messages, I've often considered it. > I think it would be handy to have spamdyke insert a header that gave the real > envelope sender > and envelope recipient addresses, since sometimes that's hard to figure out. That's a fine idea. I'm confident that you'll come up with meaningful data to include, as spamdyke's log entries are great. I haven't really considered it, other than noticing (and liking) the fact that qmail's smtp-auth patch includes the auth account name in the Received: header. Another good reason to use strong passwords come to think of it. ;) > I've often thought it would be interesting to add a "would have been blocked > by" header > to show which filters /could/ have stopped the message but didn't. > This would be useful for administrators who are considering enabling a filter > but aren't sure how many messages it would block. That could be useful in the log as well, or is that the same as what's included at the verbose log-level? (I've only really used log-level=info) > spamdyke could also add a header if the message was accepted due to a > whitelist entry. > I haven't done anything with these ideas yet because I've always felt there > were bigger fish to fry. > But now that I've added the header blacklist, spamdyke understands how to > parse message headers. > Inserting new ones wouldn't be very hard. Sounds good to me. Please be sure that if you do, there's some indication of authentication. It might do well to mimick qmail's Received: header, then add whatever X-spamdyke-* headers you think are appropriate. Thanks for your time and great work, Sam. I have the absolute highest regards for spamdyke, and look forward to your continued improvements on it. -- -Eric 'shubes' _______________________________________________ spamdyke-users mailing list [email protected] http://www.spamdyke.org/mailman/listinfo/spamdyke-users
