Thanks for this. I am already using all of the suggested mechanisms as well as a weekly harvesting of domains flagged by by SA and/or obviously spammy LHS address parts into a Postfix Access block list. If I understand you correctly, TMDA may still be an option given that the number of addresses to be reviewed is relatively small and the successful ones would be forwarded to an account in an active domain. Something to tinker with.
-----Original Message----- From: Keith Dunnett [mailto:[EMAIL PROTECTED] Sent: March 6, 2006 3:44 PM To: Schlarb, Henry Cc: tmda-users@tmda.net Subject: Re: How to for Postfix Schlarb, Henry wrote: >I administer several email domains, many that are no longer in active >use, attract a lot of spam but must remain available for business >reasons. >Is there a how to available that would allow me to add the inactive >domains so that only these domains pass through TMDA? >Management is not in favor of a total TMDA solution but putting the >inactive ones through that scrutiny is fine. > > To the best of my knowledge, there is no such howto. It's not easily possible to set TMDA up as a postfix transport without scripting something to set environment variables per user, and you would need to achieve that in order to use Postfix access controls. We achieve the same effect via maildrop; postfix delivers to maildrop, which checks using a shell command for a per-user opt-in file and then runs TMDA if appropriate. This approach is a pig to set up (ask if interested) but has the advantage that you can manage mail any way you want. For example, we run both SpamAssassin and DSPAM first, and let TMDA get involved only when the message is not found to be spam or viral and at least *might* be legitimate. This reduces the number of unnecessary challenges sent to non-existent addresses or the victims of joe jobs. In my opinion, TMDA works better for those who use and maintain it daily than for a quarantine with occasional maintenance. If most of your mail is spam, most of your challenges will bounce while legitimate mail may wait some time for authorisation. While this might work in your situation, I am inclined to think that a greylisting and/or content-filtering solution is more appropriate. Options which come to mind are: - greylisting using gps or postgrey (using gps at least, you can combine with Postfix access controls to opt domains or addresses out of greylisting). - content filtering with spamassassin, although be aware that this will increase the load on your mail server in a big way. Useful with a very high threshold for discarding proven spam without human intervention; use it with a normal threshold and you *will* get false positives. - content filtering with DSPAM, perhaps involving shared groups. This is the best solution in my opinion, because it will be useful for active domains as much as for inactive ones, has an opt-in mechanism built in and backended to MySQL, and you can take the data of the users who train DSPAM and create a global corpus for those who don't. It will however take time and training to start working, whereas TMDA or SA will start working from day one. You could also combine some or all of the above for greater effectiveness, as we do, but if I had to choose one based on your requirements, it would be DSPAM. We use all of the above; if you decide to go the maildrop/tmda route, I can probably supply some maildroprc snippets to help with integration. Oh, and one trick you *can* do with postfix, for a start, is apply a bunch of DNSBLs to your inactive domains, which you might not wish to use on the active ones... /etc/postfix/main.cf: smtpd_restriction_classes = use_dnsbls use_dnsbls = check_client_access pcre:/etc/postfix/access/dnsbl_config smtpd_recipient_restrictions = *** other restrictions here, snipped for simplicity *** reject_unauth_destination, check_recipient_access pcre:/etc/postfix/access/dnsbl_recipients, permit /etc/postfix/access/dnsbl_recipients: /[EMAIL PROTECTED]/ DUNNO /[EMAIL PROTECTED]/ DUNNO /./ use_dnsbls Anything listed with DUNNO is exempted from what follows; you can exempt entire domains, specific addresses, or whatever. This is by recipient e-mail address, or any part of it. /etc/postfix/access/dnsbl_config: /.yahoo.com/ DUNNO /.gmail.com/ DUNNO /.googlegroups.com/ DUNNO /.groups.msn.com/ DUNNO /./ reject_rbl_client sbl-xbl.spamhaus.org, reject_rbl_client bl.spamcop.net, reject_rbl_client virbl.dnsbl.bit.nl, reject_rbl_client relays.ordb.org, reject_rbl_client list.dsbl.org, reject_rbl_client dnsbl.ahbl.org while here, we have exemptions for sending servers which are unjustly (or justly, but inconveniently) blacklisted... such as Yahoo groups. This is a client restriction, not an address restriction. Put that together, and what you've got is: - check whether recipient/domain should be exempted from DNSBLs - check whether sending server should be exempted from DNSBLs - if neither, check a fairly aggressive set of DNSBLs (you could add more) Sure, it's a long way from what you asked... but may reduce any reticence about using blacklists if you can control which domains you use them for. It also demonstrates postfix SMTP restriction classes, with which you can do other, similar things. If you do use it, I suggest you combine it with logwatch so you get a summary of what's being blocked... but with a sensible choice of DNSBLs it has not caused problems here. Hope that helps, Keith _____________________________________________ tmda-users mailing list (tmda-users@tmda.net) http://tmda.net/lists/listinfo/tmda-users
