DNSBL logging in Sun MTA
Hey,
I've configured a PORT_ACCESS rule in the mappings file as follows:
TCP|*|25|*|* $C$[/opt/sunapps/msg/lib/dns_verify.so,dns_verify_domain_port,$1,sbl-xbl.spamha us.org,Your$ host$ ($1)$ found$ on$ block$ list]$E
This appears to be working correctly (snooping DNS traffic I can verify it is doing appropriate lookups, however there is nothing in the logs indicating that this IP attempted to connect and was blocked. We'd really like to see a log entry for this, and I'm fairly sure when I've configured it on another server previously it was logging with an " X " code.
I have the following log options configured in option.dat
LOG_FORMAT=2
LOG_CONNECTION=7
LOG_FILTER=1
MM_DEBUG=5
Does anyone have any suggestions on how to make it log a drop due to RBL ?
Regards,
Michael Ward.
# 3
Hi,
I would highly recommend against using that rule. PORT_ACCESS rules operate at the dispatcher level which is currently single threaded.
What that basically boils down too is that you can only accept new SMTP connections one at a time and any dns_verify callout will result in delays. I ran into this exact problem when trying to achieve what you are doing.
A good exercise (in a test environment of course) would be to point the PORT_ACCESS rule from sbl-xbl.spamhaus.org to a host in your environment which is turned off (DNS requests sent to the address will therefore time out). Then try and send emails simultaneously from two systems, you will find they block.
A better place to put the rule is at the ORIG_SEND_ACCESS point (MAIL FROM). At this stage the email processing is multi-threaded so any delays in lookups won't unduly affect delivery performance for other emails.
Have a look at the following for example rules:
http://ims.balius.com/resources/downloads/files/mappings.txt
Cheers,
Shane.
# 4
I had only been using SA (which i think does some dsbl etc. checking) - but seeing the above thread, and the mappings file on balius.com - especially the parts which discriminate mail to reject, I began to use these parts (ORIG_MAIL_ACCESS-REJECT/DELAY, and BLACKLIST) in my mappings. I do see the lookups to spamcop, spamhaus, etc. working and dropping mail - and spamd seems to be working less - I am using a caching local dns - I cannot tell if the rate of Spam getting through has increased or decreased yet (seems about the same - pretty low for me)- I am not terribly concerned about using blacklists yet (e.g. false positives). Any insight into using them in conjunction with SA? Does it decrease overall Spam?
What do the other pieces do, e.g. virus, throttle, etc.
RATE_LIMIT
REJECT_IP
ALWAYS_ACCEPT
ALWAYS_ACCEPT_IP
ALWAYS_ACCEPT_SNDR
REJECT_FROM_USER_DOMAIN
REJECT_VIRUS
REJECT_FROM_USER
REJECT_FROM_DOMAIN
REJECT_TO_USER
REJECT_TO_USER_DOMAIN
DELAY_FROM_USER_DOMAIN
DELAY_FROM_USER
DELAY_TO_USER
DELAY_TO_USER_DOMAIN
DELAY_IP
Sometimes I see this "last J record for this session" in mail.log_current - apparently during mail address harvesting ... is that correct, or referring to something else?
Thanks,
s7
# 5
> I had only been using SA (which i think does some
> dsbl etc. checking) - but seeing the above thread,
> and the mappings file on balius.com - especially the
> parts which discriminate mail to reject, I began to
> use these parts (ORIG_MAIL_ACCESS-REJECT/DELAY, and
> BLACKLIST) in my mappings. I do see the lookups to
> spamcop, spamhaus, etc. working and dropping mail -
> and spamd seems to be working less - I am using a
> caching local dns - I cannot tell if the rate of Spam
> getting through has increased or decreased yet
> (seems about the same - pretty low for me)- I am
> not terribly concerned about using blacklists yet
> (e.g. false positives). Any insight into using them
> in conjunction with SA? Does it decrease overall
> Spam?
Blacklists are simply a list of addresses (or domains) you refuse to accept anything from. Depending on how you have SA setup, it can reduce spam, some, reduce the number of messages SA processes, or block some valid mail.
>
> What do the other pieces do, e.g. virus, throttle,
> etc.
>
> RATE_LIMIT
Limit how many messages from one ip address can be accepted in a certain time.
> REJECT_IP
blacklist that ip address.
> ALWAYS_ACCEPT
Whitelist that domain (accept anything from them)
> ALWAYS_ACCEPT_IP
Whitelist that ip address.
> ALWAYS_ACCEPT_SNDR
Whitelist that user
> REJECT_FROM_USER_DOMAIN
blacklist that domain
> REJECT_VIRUS
> REJECT_FROM_USER
> REJECT_FROM_DOMAIN
> REJECT_TO_USER
> REJECT_TO_USER_DOMAIN
various blacklist options.
> DELAY_FROM_USER_DOMAIN
> DELAY_FROM_USER
> DELAY_TO_USER
> DELAY_TO_USER_DOMAIN
> DELAY_IP
These slow down the accptance from these sources. This is often a very good method for dealing with spam generators, as they don't like to wait, and rarely retry.
>
>
> Sometimes I see this "last J record for this session"
> in mail.log_current - apparently during mail address
> harvesting ... is that correct, or referring to
> something else?
It could be harvesting
>
> Thanks,
> s7
