On Jul 28, 2012, at 12:09 AM, Eric Shubert wrote: > 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).
OK, I think I understand the difference now. I'll look into making that change. >> 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. ;) Here's yet another chance for me to say that I *still* don't understand the need for a whole separate port for authenticated connections. On my servers, I configure ports 25 and 587 exactly the same and mail clients can use whichever one makes them the happiest. If they authenticate they can send mail, if they don't they'll be subject to the spam filter, simple as that. Anyway, you can certainly use spamdyke on port 587 the way you describe. Just set it up to use a different configuration file than the one on port 25 -- the second configuration file would not activate all the filters and would also include the option "filter-level=require-auth". > >> 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. I see your point and you're right. I guess I had it the way it was because it's simpler for me to do all my server configuration through spamdyke and I didn't see the harm in allowing the whitelist to govern relaying. I'll get that changed. > 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) No, though that would be easy to add it there as well, once I've added the code to put that information in the headers. The "verbose" level currently logs information about what filter *did* match. So if the connection was rejected due to a DNS RBL, the log will contain the name of the one that matched (in case more than one is in use). If the connection was allowed due to a whitelist entry, the log will contain the entry from the configuration file or the filename and line number. The "verbose" level is largely unnecessary now -- that same information is now logged in the "info" log messages as well, in the "reason" field. >> 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. Thanks for your support and suggestions! I do honestly appreciate constructive feedback! > > > -- > -Eric 'shubes' -- Sam Clippinger _______________________________________________ spamdyke-users mailing list [email protected] http://www.spamdyke.org/mailman/listinfo/spamdyke-users
