This is from Dec 2003, but it does appear only syslog is supported:

http://www.linuxmagic.com/archives/m.../msg00176.html

If that's an issue for you, then I guess this is dead in the water, unless they add support for multilog.

Hmm.... Multilog is running. So, what's going on? magic-smtpd is using syslog instead? I don't know. I guess the time has come for me to learn about logging.

Hey, Donboy, can you point me to the syslog/multilog stuff on DJB's site. I've found this:

http://cr.yp.to/qmail/faq/admin.html (search for "syslog")

Is there more?

See what you've done. Opened a can of worms. Ah, it's all good.

Ok. It's pretty simple. I am running multilog, but it is only logging tcpserver and rblsmtpd entries in /var/log/qmail/qmail-smtpd/. Qmail's standard qmail-smtpd executable would log here also. However, when I dropped in the magic-smtpd executable (replacing the standard qmail-smtpd), it started logging the equivalent entries with syslog instead of multilog. Those logs now appear in /var/log/maillog.

Sounds like the issue is that multilog is way better and more efficient than syslog. Syslog can drop entries under heavy loads.

This probably has not been an issue for me yet, but good to know. Someone needs to modify magic-smtpd to log with multilog instead of syslog.

Thanks Donboy.

Damn dude... I can't believe this. I *KNOW* there is a webpage somewhere on his site that explains in detail the problems of syslog. I have seen it and read the whole thing. The link you provided gives the basic idea of the problems. I will post the link here if I manage to find it.

Once upon a time, I tried reading all of the links on his site and that's when I found it. Thing is.... the guy just doesn't organize his website very well. His site is begging for a site map or search engine or something.

Anyway, I guess I probably could go ahead and use it anyway, but I don't know if it will really benefit me that much. I'm pretty happy with my level of spam control I have now. RBL's are doing wonders for me all by themselves. So I don't know how down and dirty I want to get with replacing my SMTP daemon just for a few additional rejected spams.

I'll post that link about syslog if I find it. I may also search the magic-smtp website and see if they have somethign about multilog.

So what about your log files?? Can you tell if your /var/log/qmail/qmail-smtpd/current is still growing??? Is multilog still keeping tabs on it? Is your syslog getting new logs info about smtp connections???

If I understand this correctly, there are 3 processes that log to /var/log/qmail/qmail-smtpd/current and they can all be found in the "run" file. They are:

- tcpserver
- rblsmtpd
- qmail-smtpd

In my setup, /var/log/qmail/qmail-smtpd/current is still growing, but only with tcpserver and rblsmtpd log data. The rest of the smtp connection data (qmail-smtpd data) is being logged to /var/log/maillog by syslog. So, I'm not losing any log data, but I am annoyed that multilog is not being used for the latter.

I'm guessing these linuxmagic people will get their act together on this eventually. Why develop a drop-in for qmail-smtpd and not log with multilog? It makes no sense. The original qmail-smtpd uses multilog, so if you write a replacement it should also use multilog. Probably it's easier to code for syslog than multilog.

I am highly pleased my magic-smtpd setup that rejects invalid users at the smtp level. However, I hear ya. If I had know of this multilog issue when I installed magic-smtpd, I probably would not have proceeded. I'm happy with this setup anyways.

Ok man, I finally found it. Actually it isn't on DJB's site... but rather its shown in Dave Sill's book, "The Qmail Handbook".

Here's some of the quotes about syslog...

"... it's not unusual for the syslogd process to consume more processor cycles than the daemons providing the service."

"Syslog will completely fill the disk partition holding a log file if enough messages are logged. It contains no mechanism to limit the size of the logs. If it can't write to a log file, it will simply throw away new log messages!"

"multilog automatically limits the log's size by rotating the log files. It keeps a configurable number of old logs after rotating them letting the system administrator configure exactly how much disk space will be devoted to a given service. It optionally timestamps log entries with up to nanosecond precision -- compared to syslog's one-second resolution."

So clearly multilog is superior. Trouble is, it's not so easy to setup your processes to use multilog cause some processes inherently "want" to use syslog. <edit> in this case, I'm speaking of services OTHER than qmail</edit>

I will never recommend the use of SORBS in my case, many legitimate email were rejected, and that almost cost me the job, this SORBS people are including in to their lists anything. be aware.

This looks great, but my config seems to be a little different, I'm just not sure where to add the rblsmtpd -r sbl-xbl.spamhaus.org line. Any help would be great

#!/bin/sh
. /usr/share/qmail/run-function

# If rblsmtpd is installed, process rbltimeout rbldomains, and antirbldomains
if [ -x /usr/bin/rblsmtpd ]; then
readdefault domains antirbldomains ""
for domain in $domains; do
rblopts="$rblopts -a $domain"
done
readdefault domains rbldomains ""
for domain in $domains; do
rblopts="$rblopts -r $domain"
done
readdefault timeout rbltimeout 60
if [ -n "$rblopts" ]; then
rbl="/usr/bin/rblsmtpd -t $timeout $rblopts"
fi
fi

# Start daemons.
readdefault concurrency concurrencysmtpd 20
do_ulimits

exec envuidgid qmaild \
envdir /etc/relay-ctrl relay-ctrl-chdir tcpserver -DRUvX -c "$concurrency" -l "`head -1 /var/qmail/control/me`" \
-x /etc/tcpcontrol/smtp.cdb 0 smtp \
$rbl relay-ctrl-check qmail-smtpd /home/vpopmail/bin/qmail-smtpd/vchkpw /bin/true

For those of you stuck with a crappy script like mine above, here is my solution....

$rbl relay-ctrl-check rblsmtpd -r sbl-xbl.spamhaus.org qmail-smtpd /home/vpopmail/bin/qmail-smtpd/vchkpw /bin/true

I just couldn't figure out where $domains was defined so forgot about all that crap and added the suggusted line. Works great, thanks to everyone else that posted, my spam has already gone down! Absolutly amazing.

Regarding carlosruiz's message about SORBS ...

SORBS does appear to be quite aggressive. Twice now (only twice) I have had cases where email from legitimate sources was blocked by SORBS. In both cases I whitelisted the IP address to solve the problem. Not ideal, but I still prefer to use Sorbs. I am guessing there are fewer false positives with a service like Spamhaus, but Spamhaus rsync service costs money. So far Sorbs rsync is free. They recently warned that without more mirrors they may soon cut this free service. This just applies to rsync, not their normal service.

Here's a few little nuggets I learned recently about SORBS.

First, they are a listing of all the dynamic IPs on the net. So if you've got customers on your mailserver who are on dial-up, there's a good chance some of them wiill be listed. I've got one person who I discovered was listed.

Second, I tried using the -b switch with rblsmtpd. This issues a 553 error instead of the default 451 error to any IPs who are dsicovered to be listed at one of the RBL sites you're checking.

Well, much to my surprise, when I implimented the -b, I began blocking one of my customers was no longer able to send mail using my server! The message he got was a SORBS 553 error. Obviously the 553 error was happening because of the -b switch. Taking off the -b switch, he was able to send mail just fine. This totally blew my mind.

To remedy this problem, I started using multiple instances of rblsmtpd in my run file, thusly...

/usr/local/bin/tcpserver -p -v -R -l falcon.servershak.com -x /home/vpopmail/etc/tcp.smtp.cdb \
-u98 -g98 -v -c100 0 25 rblsmtpd -b \
-r sbl-xbl.spamhaus.org \
-r bl.spamcop.net \
-r relays.ordb.org \
-r dnsbl.njabl.org \
-r cn-kr.blackholes.us \
-r brazil.blackholes.us \
-r japan.blackholes.us \
-r thailand.blackholes.us \
-r comcast.blackholes.us \
rblsmtpd -r dnsbl.sorbs.net \
/var/qmail/bin/qmail-smtpd \
/home/vpopmail/bin/vchkpw /bin/true 2>&1

Notice towards the beginning of the file, I'm invoking rblsmtpd with the -b switch for the majority of my RBL sites. Then later towards the end, I'm doing another rblsmtpd without the -b switch, so my customer (and anyone else discovered to be listed on SORBS) will still be able to relay mail through my server.

I'm still quite baffled as to why the user is unable to relay when that switch is added. My feeling is, when the user receives EITHER the temporary or permanent errors, they should still be stopped from sending mail. Boggles the mind.

I was initially annoyed that Sorbs and other blacklists were blocking dynamic IP addresses. It shuts out people on dynamic addresses from running email servers and using a service like dyndns to auto update dns when their ip address changes. However, I now accept this as a legitimate practice because it has one HUUUGGGE advantage. Most viruses that hijack a host computer and send out emails are on windoze PCs on cable and dsl connections with dynamic ip addresses. Sorbs is highly effective at blocking these virus generated emails. In fact, this accounts for the bulk of the mail that gets blocked by my server. These viruses often activate at a certain time. When this happens, I see a flurry of hundreds of blocked emails suddenly appear in the logs during a 2 or 3 minute window -- all from different dynamic ip addresses. Then this activity suddenly cuts off. That's a virus being sent to my server from many different virus infected windows PCs. Sorbs blocks this stuff beautifully.

Note: This is sometimes a source of confusion .... just because someone has a dynamic ip address does not mean they will be blocked by sorbs from sending email to my server. 99.9% of people are not running their own servers at that dynamic ip address. The norm is to use your ISP's email server which will not be at a dynamic ip address.

Donboy, [just for background for others ...] as you mention 451 is a temporary error, meaning the sending server will try again to deliver the email and then keep trying for a week or 2 weeks before bouncing the message (I forget, there is some standard schedule for this). However, 553 is a permanent error. 553 results in an immediate bounce of the message -- end of story -- no more delivery attempts. Not quite sure why that matter, but I bet the problem is related to that. That customer is probably on some dynamic and/or dialup service where the ip address changes very frequently. If they get a permanent error (because of your -b switch) then the email is blocked. However, with a 451 (temporary) they get blocked, but not yet bounced. Eventually, the message gets delivered because they eventually try from some address not listed on sorbs. Wow, that was long-winded and does not quite make sense because they are relaying through your server, right. Bah ... But it's something along those lines. It does boggle the mind.

Your script is interesting. You can mix blacklists with and without the -b switch. I never thought of that. Very interesting.

Actually, slight correction. If someone is using your server to relay from a dynamic ip address then, yes, they will be blocked by Sorbs. Annoying. What's the way around that? One way is to not use Sorbs. I have 2 better ways.

1. 90% of my customers access my server using Squirrelmail or Openwebmail both hosted by me. The webmail client is local, so their ip address is irrelevent because rblsmtpd thinks they are connecting from 127.0.0.1 . rblsmtpd does not block 127.0.0.1 .

2. For the other 10% who use their own mail clients I do this ... I require them to connect via SSL on port 2225. Non-local users must authenticate smtp connections if they want to relay (magic smtpd handles that). I have stunnel set up to accept smtp SSL connections on port 2225. Stunnel directs SSL smtp traffic on port 2225 to port 25 (using stunnel's non-transparent mode). rblsmtpd thinks the user is connecting from the address that stunnel gives it (local address 192.168.0.10), but rblsmtpd does not realize 192.168.0.10 is local. So connecting from anywhere to port 2225 effectively bypasses rblstmpd because Sorbs does not block 192.168.0.10. As long as the user authenticates, they can relay.

A bit complicated. I am tired as I type this. Hope it makes sense. Trust me, it's a cool solution.

>> (I forget, there is some standard schedule for this)

/var/qmail/control/queuelifetime, which may not exist, but you can create one and override the default of 1 week.

>> However, with a 451 (temporary) they get blocked, but not yet bounced. Eventually, the message gets delivered because they eventually try from some address not listed on sorbs.

Geez, I hope not. In that case, I could imagine where a spammer would be listed on one database but not in another, and just by subsequent retries of other databases, the spam would sneak through just because I'm checking against a crappy database last.

>> Eventually, the message gets delivered because they eventually try from some address not listed on sorbs.

Huh? Maybe I don't follow you. But I thought if my customer were to get a 451, the mail would still remain on his computer? If that happened he surely would have notified me, because he's the kinda guy who checks with me about everything.

Anyway, I may try your idea. I'm using stunnel for securing my pop3, so this should be easy.

wow this sounds really cool! the only problem is i cant find the run file where you added the spamhaus line
i have qmail running on a server with redhat 9 and virtual hosting. i cant seem to find the "run" file that you're referring to. the only file i could think of was /etc/init.d/qmail but i wouldnt know where in that file i should add the rules that you had highlighted in red in your original post. please advise. my server is getting pounded with tons of spam everyday. this would be a life saver. Thanks.