On Mon, Aug 19, 2013 at 04:42:36PM +0530, Abhijeet Rastogi wrote:
> On Mon, Aug 19, 2013 at 4:21 PM, Wietse Venema
> <wie...@porcupine.org> wrote:
> > Abhijeet Rastogi:
> > > a. There are two postfix instances on two different boxes.
> > > One (named Postfix-INT) has only 1 IP and the other (named
> > > Postfix-EXT) has 5 ips (to divide traffic among them by
> > > defining separate smtp services).
> >
> > Please describe the problem that you are trying to solve,
> > instead of one solution that you came up with. There may
> > be better solutions.
> >
> Issue is, earlier I had only 1 IP on the outgoing mail server.
> Due to compromised accounts, it got blocked on one of the RBLs.
Whilst it is reasonable to separate domains' outbounds to protect
others from the problems one has, I think your best bet here is
standard damage control for compromised accounts:
1. Strict separation of submission from MX stream
2. Strict rate limiting by SASL username on submission
3. Content filtering (specifically URIBL checks) of submission
A. Spammy content should trigger blockage in the pre-DATA
policy service which enforces the rate limits
The reasoning behind #1 should go without saying, but in a nutshell,
you have different filtering needs in each stream.
I have implemented #2 with cbpolicyd <http://www.policyd.org> and
rules to check SASL username. The exact rules are not entirely
settled, and will vary by site, depending on how much control over
your users that you have. If it's a SMB, you can probably enforce a
very strict burst limit.
I am unaware of any "relaying ratware" botnet which does not send
URIBL-listed content. This is the surest line of defense. But #3A is
necessary to protect your site against DoS which can easily occur as
the botnet floods your connection with as much as they are able to
send over all links that are involved. They can and will saturate
your bandwidth, as the compromised credentials are distributed over
many bots. Even with the best possible hardware, you'll have
difficulty with content filtering all of that. (You might not even
have enough bandwidth left over for the URIBL lookups.)
For that matter (I have not done this yet), time and source IP
address limits per SASL username would also trip up such ratware.
Suppose a user leaves a MUA running at home, at 1-2 offices, on a
personal laptop, and via 1-2 cell phones. That's up to six different
IP addresses at once. Let's further assume that some automated
processes might be sending legitimate mail from each client. Add 2
more to accomodate the worst possible email-using geeks. :) That's 8
maximum.
Connections from the 9th source IP address within, say, a 15-minute
window, should automatically be rejected.
> I've a anti-spam solution that categorises the mail as L1, L2
> and L3. (L1 being the sure-shot spam). Moreover, more than 1
> domain will use that outgoing server to send the mails.
>
> While sending mails, Idea is to use separate IP addresses for
> each domains
There's nothing wrong with this idea, but I think you should use
better protection before you get to the point of relaying spam.
> & also to send the L3 (suspect mails, ie there is a high
> probability for it to be spam) from a common suspect IP for all
> these domains.
Oh, no, this is very wrong. If you have reason to suspect spam, do
not relay it. At least hold it. I say reject it.
> So, if there are any compromised accounts, only the suspect IP
> (from which I send L3 mails) gets blocked. As mentioned earlier,
> L1 and L2 are rejected.
Oh, so it's not quite as wrong then, but I still would be very
squeamish about letting any of my IP addresses be seen as a spam
source.
--
http://rob0.nodns4.us/ -- system administration and consulting
Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
