Loading ...
Sorry, an error occurred while loading the content.

Re: Deciding transports based on milter headers

Expand Messages
  • /dev/rob0
    ... 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
    Message 1 of 8 , Aug 19 8:49 AM
    • 0 Attachment
      On Mon, Aug 19, 2013 at 04:42:36PM +0530, Abhijeet Rastogi wrote:
      > On Mon, Aug 19, 2013 at 4:21 PM, Wietse Venema
      > <wietse@...> 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

      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
      http://rob0.nodns4.us/ -- system administration and consulting
      Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
    Your message has been successfully submitted and would be delivered to recipients shortly.