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
