Re: [cobalt-users] Qube 3 - How to stop spam?

[John Lee <johnvero@xxxxxxxxxxxxxx>]

Paker:

I appreciate your suggestion but as you said it blocks the source not destination.
It can't fix the problem long-term.

I haven't configured the qube to be a relay.  But as one of the user group members,
Malcolm McLeary, suggested, is it possible the spammers used tricks to spoof IP
addresses.  Here are a portion of my maillog.

Nov 14 04:06:21 www sendmail[32468]: fA8JU6c16774: to=<anthony.apa@xxxxxxxxx>,
delay=5+00:36:13, xdelay=00:13:09, mailer=esmtp, pri=11924158,
relay=nomail.o0o.net. [192.168.10.1], dsn=4.0.0, stat=Deferred: Connection timed out
with nomail.o0o.net.
Nov 14 04:06:21 www sendmail[32468]: fA8JU6c16774: fADJcxl32468: sender notify:
Cannot send message within 5 days
Nov 14 04:06:25 www sendmail[32468]: fADJcxl32468: to=<george_orei@xxxxxxxxx>,
delay=00:00:04, xdelay=00:00:04, mailer=esmtp, pri=43969, relay
=mx1.mail.yahoo.com. [64.157.4.86], dsn=2.0.0, stat=Sent (ok dirdel)
Nov 14 04:38:59 www sendmail[3190]: fA8KjEc20869: to=<ronaldtse@xxxxxxxxxxxxxx>,
delay=4+23:53:43, xdelay=00:00:00, mailer=esmtp, pri=13662182
, relay=pop3.hknet.com. [202.67.240.165], dsn=4.0.0, stat=Deferred: Connection
refused by pop3.hknet.com.
Nov 14 04:52:08 www sendmail[3189]: fA8MS1c26246: to=<ejs@xxxxxxxx>,
delay=4+22:24:04, xdelay=00:13:09, mailer=esmtp, pri=11865867, relay=noma
il.usa1.com. [209.21.136.2], dsn=4.0.0, stat=Deferred: Connection timed out with
nomail.usa1.com.
Nov 14 04:52:08 www sendmail[3188]: fA8Lbec23631: to=<jlm@xxxxxxxx>,
delay=4+23:14:26, xdelay=00:13:09, mailer=esmtp, pri=11957753, relay=noma
il.usa1.com. [209.21.136.2], dsn=4.0.0, stat=Deferred: Connection timed out with
nomail.usa1.com.
Nov 14 04:52:08 www sendmail[3190]: fA8KjEc20869: to=<cats@xxxxxxxxxxxxxxx>,
delay=5+00:06:52, xdelay=00:13:09, mailer=esmtp, pri=13662182, re
lay=kompleks.nbi.dk. [130.225.212.54], dsn=4.0.0, stat=Deferred: Connection timed
out with kompleks.nbi.dk.
Nov 14 04:52:08 www sendmail[3190]: fA8KjEc20869: fADKcxl03190: sender notify:
Cannot send message within 5 days
Nov 14 04:52:12 www sendmail[3190]: fADKcxl03190: to=<george_orei@xxxxxxxxx>,
delay=00:00:04, xdelay=00:00:04, mailer=esmtp, pri=42009, relay=
mx2.mail.yahoo.com. [64.157.4.89], dsn=2.0.0, stat=Sent (ok dirdel)
Nov 14 04:52:12 www sendmail[3190]: fA8N0pc28044: to=<miracles@xxxxxxxxxxxxxx>,
delay=4+21:51:19, xdelay=00:00:00, mailer=esmtp, pri=14389879,
 relay=successful.net. [212.100.224.102], dsn=4.0.0, stat=Deferred: Connection
refused by successful.net.

For all those guys in the to=<xxxx@xxx>,  I have never sent them anything and I
don't even know them.  After looking at this code, can you think of any possible
cause for this.



Rgds
John


Parker Morse wrote:

> John says:
> >> I tried what you told me and the result is "System appeared to accept 1 relay
> >> attempts."
>
> >> Actually, my company do not use POP.  We all receive and send mails through
> >> the
> >> qube's webmail and do not need to relay anything through my qube.  Is there
> >> anything I can do to reject all mails going to my qube that are not sent to
> >> my
> >> domain?
>
> Despite helpful suggestions to use your firewall, it's not going to help.
> The Qube3's firewall will stop packets addressed to other ports than your
> SMTP port, but the spam being relayed will in fact be addressed to the
> correct port on your machine, so to a firewall it will appear to be
> legitimate incoming email for your users. It's only when it gets to your
> Mail Transfer Agent - sendmail on the Qubes - that it is recognized as
> addressed to another machine, and sent along.
>
> So you need to block this at sendmail.
>
> I'm going to walk through this in tedious detail (partly for my own sake) so
> those who aren't interested, delete now (or read and send me corrections,
> which are welcome.) Standard disclaimer: I could be wrong.
>
> First, let's shut off anything email related that you're NOT using. These
> probably aren't the problem, but for security's sake it's a good idea to
> turn off any services not in use anyway. Judging from what you wrote above,
> here's what you can safely turn off:
>
> Under "Email Services" and "Email servers", uncheck "POP Server" and "IMAP
> Server". You should probably leave SMPT server checked, because that's how
> your outgoing mail is processed.
>
> The next step is to edit sendmail's access file. YOU SHOULDN'T DO THIS
> UNLESS YOU'RE COMFORTBLE WITH THE SHELL. If you're not comfortable working
> outside the Cobalt web interface, this isn't for you; you should hire
> someone knowledgeable in sendmail to fix it for you.
>
> If I haven't scared you enough... log in to your Qube. Make yourself root.
> (If you don't know how to do this, reread the previous paragraph.) The file
> we're working with is /etc/mail/access. First, back it up: make a copy named
> access.date or something like that. Then open up the original with your
> preferred editor. You should see a section like this:
>
> #
> # /etc/mail/access
> #
>
> # This file is automatically generated
> # Please put custom changes at the end
> # Cobalt Networks 1999
>
> # Put custom additions below (Do not change/remove this line).
>
> # Cobalt Access Section Begin
>
> 11.11.111.50    RELAY
> 10.6.18 RELAY
> subdomain.domain.com    RELAY
> domain.com     RELAY
>
> # Cobalt Access Section End
>
> ...where the 11.11.111 bit is your IP number, the 10.6.18 is the first three
> dotted-quads of your subnet, if any, and domain.com is your domain (and the
> subdomain.domain.com is any other address you might use - we've got our
> Qube's name in there.) Those lines are the ones written by the Cobalt GUI
> when we did the relaying settings earlier.
>
> DON'T MAKE ANY CHANGES above the line "Cobalt Access Section End."
>
> BELOW that line, try adding lines like this:
>
> 66.163.35       ERROR:550 We don't accept email from spammers
>
> I have this actual line in our access file, from a "lose weight" spam we got
> last week. Replace the 66.163.35 line with the first three numbers of the IP
> addresses that are relaying spam through your box. Duplicate as many times
> as needed; then save the file and give this command:
>
> makemap hash /etc/mail/access < /etc/mail/access
>
> That should do the trick. If it doesn't work, rename your backup file to
> "access" and issue the "makemap" command above again to return everything to
> original settings.
>
> The limitation of working with the "access" file is that it blocks based on
> the source (not the destination) of the mail.
>
> If this doesn't work, you'll have to muck with the actual sendmail
> configuration file, which is big magic. I can't understand why you were set
> up to relay in the first place; Qube3s come with a new enough version of
> sendmail that the configuration should deny relaying (except from hosts
> listed in the GUI) by default.
>
> For more information visit <http://www.sendmail.org/tips/relaying.html>.
>
> Hope this helps,
>
> pjm
>
> _______________________________________________
> cobalt-users mailing list
> cobalt-users@xxxxxxxxxxxxxxx
> To Subscribe or Unsubscribe, please go to:
> http://list.cobalt.com/mailman/listinfo/cobalt-users