> > From various address in that Class C or just from .225?
>
>They were from probably 8-10 IPs in that net.
That could still be a valid config for a listserver farm that uses
mutliple outgoing gateways in parallel to delivery the high volume
list traffic. Then again, it could be some very clever spoofing by a
DoS attacker.
> >>which I have routed to a null 0 at the router.
> >
> >In that router, have you blocked outside traffic coming from your
> >inside addresses?
>
>Not sure exactly what you mean here. I used an ip route to discard
>all packets in their network.
Since you are going to set Imail SMTP security to "relay for
addresses", ie, your Imail will "trust" and relay whatever is sent
from your inside addresses, then you must block all traffic arriving
on your outside router interface that says that its source address is
one of your inside addresses. ie, the packet arrives from Internet
constructed with one of your internal addreses you trust, so Imail
says "ok" and relays the mail. Farfetched? We hade a guy in here a
few months ago getting spammed badly, we said "relay for addresses",
so he did, he said 'still getting spammed' because the spammer was
spoofing the source address and he didn't know how to block ip
spoofing at his border router.
>Agreed. We converted from Post.Office which allowed relay from both
>not one or the other. What issues are there in simply changing over now?
Changing from PO to IM, or changing from open-relay to "relay for
addreses"? If the latter, your users who relay mail through Imail
but not from one of your "relay for addresses" ip's, will have to use
SMTP AUTH in their mail programs to authenticate themselves and be
"trusted as local user" for relaying. This is a tough because each
of them will have to click something in their mail pgms before they
can relay mail through you. They will not be happy if they can't send mail.
Also, in Imail SMTP security: UNcheck "Disable SMTP AUTH reporting"
so that Imail will announce its SMTP facilities like this when a
remote server connects to Imail:
250-SIZE 0
250-8BITMIME
250-DSN
250-ETRN
250-AUTH LOGIN PLAIN CRAM-MD5 <== "SMTP AUTH reporting"
250-AUTH=LOGIN <== "SMTP AUTH reporting"
250 EXPN
>I would think so too. But now I am getting the same type of message,
>not as many in quantity, but a significant number, from another
>source, bounce.onelist.com - addressed to a different user, but all
>mail to the same user.
What spammer would send mail to just one user?? This is a mailbomb.
globelist and onelist list factories must have sophisticated enough
list servers with automatic bounce management recognize bounce
messages with 5xx response codes and remove the user from the list
and stop sending mail.
If you block at ip level at your router, there's not SMTP reject.
>But now it looks like I have someone finding a valid user name in
>iMail, which has a full mailbox, and then the attacks begin.
Sending 1000's of msgs to one user is not spam, it's mail bomb DoS.
>And shy of filtering IPs, I do not know how to react,
mailbombs are a bitch. The best you can do is manually kill it at
the router so as to protect Imail.
Or f you had a mail hub like IMGate, you do global filtering on the
header or ip address, the result also being IMail never sees the junk
and doesn't get DoS'ed. The advantage of IMGate rejections over
router ip filtering is that the reject is at the SMTP level so the
sender sees the 5xx fatal reject msg.
>other than to reach an admin and change my relay to address only.
>But as this is not relay, what else can be done? The sender line
>changes slightly with each message.
Mailbombs, accidental or intentinal, to valid user accounts are bitch
to defend against in any automatic fashion. As you said, you could
manually filter the entire class C, but collateral damage is that
valid users don't get msgs from onelists.
Have you looked carefully at the full list of headers to see the
delivery path?
You could also set up an Imail delivery rule for the attacked user
that delivered those msgs to NUL or spambox account. But that puts a
ton of work on Imail. Better to stop it upstream from Imail.
Len
http://BIND8NT.MEIway.com: ISC BIND 8.2.2 p5 installable binary for NT4
http://IMGate.MEIway.com: Build free, hi-perf, anti-spam mail gateways
Please visit http://www.ipswitch.com/support/mailing-lists.html
to be removed from this list.
An Archive of this list is available at:
http://www.mail-archive.com/imail_forum%40list.ipswitch.com/
