On Fri, 8 Feb 2008 15:36:01 +0100, Raimo Niskanen wrote:
>On Fri, Feb 08, 2008 at 10:08:19PM +1100, Rod Whitworth wrote:
>> On Fri, 8 Feb 2008 11:07:15 +0100, Raimo Niskanen wrote:
>>
>:
>:
>> >
>> >* To make the greylist herustics validate the hosts
>> >by reverse DNS PTR lookup and then forward A lookup
>> >is apparetly a debatable issue according to the
>> >current thread "running mail server at home".
>> >But if it is (fairly) common practice it would
>> >be a simple thing to do, and certainly decrease
>> >spam volume. But would it be to narrow?
>>
>> Every so often we see a flood of connections trying to deliver bounce
>> messages to nonexisting mailboxes here where there are two domains
>> sharing a postfix/OpenBSD box running spamd in greylisting/trapping
>> mode.
>>
>> Mostly:
>> The sender domains are real and the mail is from valid MTAs for those
>> domains.
>> The admins of those senders are incompetent wankers who run MTAs that
>> accept mail for any address and later bounce it to the purported
>> sender.
>> but not 100%.
>>
>> My solution was to run a script from cron every four minutes that looks
>> like:
>> =========================
>> #!/bin/sh
>> spamdb|grep GREY|cut -d "|" -f2|tr -d "<"|tr -d ">"|tr "|" " "
>> >>/var/db/slice
>> s
>> while read villain; do
>> /usr/local/sbin/postmap -q $targ /etc/postfix/vmailbox
>
>Where did the $targ variable come from?
Aaargh! After a 0430 start yesterday I try to send helpful info at
2208.....
It might have been more helpful if I slept first. Sorry.
I was doing the script from memory so now here is the correct one cut
and pasted.
===
#!/bin/sh
spamdb|grep GREY|cut -d "|" -f2,5|tr -d "<"|tr -d ">"|tr "|" " "
>>/var/db/slices
while read villain targ; do
/usr/local/sbin/postmap -q $targ /etc/postfix/vmailbox
>/dev/null
if [ $? -ne 0 ] ; then
spamdb -ta $villain
fi
done < /var/db/slices
rm /var/db/slices
===
>I do not run postfix. What do you search for in
>what database?
The postconf line queries the valid recipients database.
>
>> >/dev/null
>> if [ $? -ne 0 ] ; then
>> spamdb -ta $villain
>> fi
>> done < /var/db/slices
>> rm /var/db/slices
>> ==========================
>>
>> Caveat: This script will tarpit otherwise innocent senders who have
>> clients who use a mailbox name with a tyop in it because it traps ALL
>> messages addressed to invalid mailboxes. Using another grep to select
>> on a match of <> will eliminate all but bounces to invalid addresses
>
>Does a sender (spamdb field 5 (starting at 1)) == <> indicate
>a bounce.
No. The sender field is 4 and 5 is the recipient (or target in my terms
for spammers, hence $targ in the script.)
> And you say it is OK to tarpit hosts that bounce to
>invalid addresses?
Well I <did> put a caveat in my message BUT the following
considerations apply:
We are not supposed to reject messages from the null sender because
they are supposed to be genuine bounce messages. So I don't reject
based on the null sender alone.
However nobody could be legitimally bouncing a message from a
non-existant sender.
In the nasty spammy email world we live in "accept and bounce" should
only apply to mail from authenticated MUAs talking to their own
outbound MTA. Otherwise spammers do what we are discussing and hope
their payload ends up being read by someone.
>
>> from the null sender. They would not have reached a mailbox anyway.
>>
>> I figure that maybe, just maybe, some admins will see the log message
>> repeating during all the trapitting and get a clue. It is easier than
>> sending an email complaining about their cluelessness.
>>
>> As to load: The box is a Celeron 1.3GHz with 256 MB RAM. It handles
>> lots of mail with reasonably large PDF and graphics attached and runs a
>> POP3 daemon as well that is polled regularly by about 70 "always on"
>> accounts. I cannot see any degradation of performance when these storms
>> are peaking. spamd rocks!
>> >
>
>What does "lsof -ni:spamd | wc -l" say during the peaks?
>On my machine spamd ran out of sockets (about 670).
I don't have a storm at the moment. Last one was about a month ago.
I have only seen an increased load prior to trapping these backscatter
senders. Running the script cut the load to normal performance. Not
that I measured it but it was just no longer noticeably slow.
Oh, and I haven't used lsof since I retired from teaching Linux stuff
for IBM a few years ago. It isn't part of OpenBSD tools.
Best regards,
Rod/
/earth: write failed, file system is full
cp: /earth/creatures: No space left on device
