MailChannels Traffic Control (fwd) - SpamAssassin

This is a discussion on MailChannels Traffic Control (fwd) - SpamAssassin ; ...

+ Reply to Thread
Page 1 of 2 1 2 LastLast
Results 1 to 20 of 25

Thread: MailChannels Traffic Control (fwd)

  1. Re: MailChannels Traffic Control (fwd)


  2. Re: MailChannels Traffic Control (fwd)


  3. Re: MailChannels Traffic Control (fwd)


  4. Re: MailChannels Traffic Control (fwd)


  5. Re: MailChannels Traffic Control (fwd)


  6. Re: MailChannels Traffic Control (fwd)


  7. MailChannels Traffic Control (fwd)

    Hey all --

    I'm on the technical advisory board for MailChannels, a company who make a
    commercial traffic-shaping antispam product, Traffic Control. Basically,
    you put it in front of your real MTA, and it applies "the easy stuff" --
    greet-pause, early-talker disconnection, lookup against front-line DNSBLs,
    etc. -- in a massively scalable fashion, handling thousands of SMTP
    connections on a single box. By taking care of 80% of the bad stuff
    upfront, it takes a massive load off of your backend -- and, key point,
    off your SpamAssassin setup.

    Until recently, the product was for-pay and (relatively) hard to get your
    hands on, but as of today, they're making it available as a download at
    http://mailchannels.com/download/ . Apparently: "it's free for low-volume
    use, but high volume users will need a license key."

    Anyway, take a look, if you're interested. I think it's pretty cool.
    (and I'm not just saying that because I'm on their tech advisory board.

    --j.


  8. Re: MailChannels Traffic Control (fwd)

    * mouss :

    > I respect you, but I feel sorry here. Tarpit and slowdown are know since
    > a long time, so mailchannel bring nothing here (except marketing). In
    > particular,"greet pause" has been implemented by some people. the fact
    > that this is not common is not due to an implementation difficulty, but
    > to the fact that the cost/benefit ratio is not very interesting.


    To be fair (I'm testing it right now): It's easy to get running.
    Right now the Tarpit and slowdown features cannot be had in Postfix,
    so I'm giving it a spin.

    --
    Ralf Hildebrandt (i.A. des IT-Zentrums) Ralf.Hildebrandt@charite.de
    Charite - Universitätsmedizin Berlin Tel. +49 (0)30-450 570-155
    Gemeinsame Einrichtung von FU- und HU-Berlin Fax. +49 (0)30-450 570-962
    IT-Zentrum Standort CBF send no mail to snickebo@charite.de


  9. Re: MailChannels Traffic Control


    > From: Ralf Hildebrandt
    > Date: Mon, 19 May 2008 20:18:26 +0200
    > To:
    > Subject: Re: MailChannels Traffic Control (fwd)
    >
    > * mouss :
    >
    >> I respect you, but I feel sorry here. Tarpit and slowdown are know since
    >> a long time, so mailchannel bring nothing here (except marketing). In
    >> particular,"greet pause" has been implemented by some people. the fact
    >> that this is not common is not due to an implementation difficulty, but
    >> to the fact that the cost/benefit ratio is not very interesting.

    >
    > To be fair (I'm testing it right now): It's easy to get running.
    > Right now the Tarpit and slowdown features cannot be had in Postfix,
    > so I'm giving it a spin.


    Tarpit in postfix for years, right?

    smtpd_soft_error_limit = 10
    smtpd_hard_error_limit = 20
    smtpd_error_sleep_time = 4m

    And if this box can't keep a valid/updated list of recipients, then it can
    contribute to the backscanner problem by sending DHA to the final MTA for it
    to bounce, right?


    --
    Michael Scheidell, CTO
    >|SECNAP Network Security

    Winner 2008 Network Products Guide Hot Companies
    FreeBSD SpamAssassin Ports maintainer


    __________________________________________________ _______________________
    This email has been scanned and certified safe by SpammerTrap(r).
    For Information please see http://www.spammertrap.com
    __________________________________________________ _______________________


  10. Re: MailChannels Traffic Control

    * Michael Scheidell :

    > > To be fair (I'm testing it right now): It's easy to get running.
    > > Right now the Tarpit and slowdown features cannot be had in Postfix,
    > > so I'm giving it a spin.

    >
    > Tarpit in postfix for years, right?


    Slowdown?

    > smtpd_soft_error_limit = 10
    > smtpd_hard_error_limit = 20
    > smtpd_error_sleep_time = 4m


    But this comes at the expense of one fat smtpd per tarpitted clients.

    > And if this box can't keep a valid/updated list of recipients, then it can
    > contribute to the backscanner problem by sending DHA to the final MTA for it
    > to bounce, right?


    No, it works as a proxy. They got that right.

    --
    Ralf Hildebrandt (i.A. des IT-Zentrums) Ralf.Hildebrandt@charite.de
    Charite - Universitätsmedizin Berlin Tel. +49 (0)30-450 570-155
    Gemeinsame Einrichtung von FU- und HU-Berlin Fax. +49 (0)30-450 570-962
    IT-Zentrum Standort CBF send no mail to snickebo@charite.de


  11. Re: MailChannels Traffic Control (fwd)

    * mouss :

    > you can use sleep. sure, it stops the process, but if your system is not
    > under heavy load, it may be acceptable...


    Yep.

    > but anyway. I don't see what mailchannel are bringing that deserves this
    > debate. it looks to me like this:
    >
    > - they started trying to sell greeetpause. and it didn't work enough
    > - they moved to "slowdown" and they're trying to talk about
    >
    > In both cases, they don't provide any serious study. they only show
    > numbers that go with their claims. I don't know for others, but my logs
    > don't seem to confirm theirs.


    I haven't checked yet. I need more time.

    --
    Ralf Hildebrandt (i.A. des IT-Zentrums) Ralf.Hildebrandt@charite.de
    Charite - Universitätsmedizin Berlin Tel. +49 (0)30-450 570-155
    Gemeinsame Einrichtung von FU- und HU-Berlin Fax. +49 (0)30-450 570-962
    IT-Zentrum Standort CBF send no mail to snickebo@charite.de


  12. Re: MailChannels Traffic Control (fwd)


    mouss writes:
    > Ralf Hildebrandt wrote:
    > > * mouss :
    > >
    > >> I respect you, but I feel sorry here. Tarpit and slowdown are know since
    > >> a long time, so mailchannel bring nothing here (except marketing). In
    > >> particular,"greet pause" has been implemented by some people. the fact
    > >> that this is not common is not due to an implementation difficulty, but
    > >> to the fact that the cost/benefit ratio is not very interesting.

    > >
    > > To be fair (I'm testing it right now): It's easy to get running.
    > > Right now the Tarpit and slowdown features cannot be had in Postfix,
    > > so I'm giving it a spin.

    >
    > you can use sleep. sure, it stops the process, but if your system is not
    > under heavy load, it may be acceptable...
    >
    > but anyway. I don't see what mailchannel are bringing that deserves this
    > debate. it looks to me like this:
    >
    > - they started trying to sell greeetpause. and it didn't work enough
    > - they moved to "slowdown" and they're trying to talk about


    For what it's worth, they've been talking about "slowdown" since 2006:
    http://www.onlamp.com/pub/a/onlamp/2...us_events.html

    > In both cases, they don't provide any serious study. they only show
    > numbers that go with their claims. I don't know for others, but my logs
    > don't seem to confirm theirs.


    OK, the main advantage over doing greet-pause/tarpitting with your "main"
    SMTP daemon is that TC is event-driven; thousands of concurrent
    connections are handled by one TC process. So it'll scale better -- I
    don't know of an MTA that can do that on low-end hardware (bar a custom,
    hand-tweaked qpsmtpd setup, and I've been having trouble doing that myself
    for our spamtraps). It also can cluster between multiple instances
    (apparently) if that's not scaling enough.

    > and the slowdown thing is based on the theory that spammers have better
    > things to do than wait. now that we know more about botnets, this theory
    > doesn't stand.
    >
    > how long would it take to write an asynchronous smtp client?


    You think spammers aren't already using them? too late I'm afraid; I know
    that one of the major ratwares is already written using libevent:
    http://www.monkey.org/~provos/libevent/ . And I'm sure there are more.

    Installing something like Traffic Control is simply keeping up. The
    spammers can already scale better than we can. We're spared the full
    flood, because they're simultaneously relaying spam to thousands of other
    servers while they're flooding ours... but they'll keep scaling up.

    --j.


  13. Re: MailChannels Traffic Control (fwd)


    On Mon, May 19, 2008 20:18, Ralf Hildebrandt wrote:

    > To be fair (I'm testing it right now): It's easy to get running.
    > Right now the Tarpit and slowdown features cannot be had in Postfix,
    > so I'm giving it a spin.


    give longer greylist times will do without marketing :-)


    Benny Pedersen
    Need more webspace ? http://www.servage.net/?coupon=cust37098


  14. Message-ID:Reply-To:References:MIME-Version:Content-Type:In-Reply-To; b=Yy9Ib3zQXoSvJSjceU6yTV4njdELuiLJY+Q7t32GUNaRDP20 tuqO8ri7w/2VSp+mJexO1UYuiWa0C+FUYwLK/+ecEWcjq8geczOj/Waww8eBMMCvmm50o04g95GLe/csJRNlgP9QZJjatSlnEmWWQYIevWmUra81ShpSJnZ+U/U=

    On Mon, May 19, 2008 at 10:46:23PM +0200, mouss wrote:
    >>
    >>> and the slowdown thing is based on the theory that spammers have
    >>> better things to do than wait. now that we know more about botnets,
    >>> this theory doesn't stand.
    >>>
    >>> how long would it take to write an asynchronous smtp client?
    >>>

    >>
    >> You think spammers aren't already using them? too late I'm afraid; I know
    >> that one of the major ratwares is already written using libevent:
    >> http://www.monkey.org/~provos/libevent/ . And I'm sure there are more.
    >>

    >
    > wasn't aware of that. do you know if this is already used on a "large"
    > botnet?


    I tend to overestimate spammers intelligence usually, but I'm surprised that
    someone wouldn't assume this has always been true? It's not exactly rocket
    science to write a polling SMTP client to answer a few responses. We all
    know they want to send as much as possible, without bogging down the users
    machine with hundreds of suspicious processes.


  15. Re: MailChannels Traffic Control (fwd)

    mouss, please do a little research before you go online attacking
    people. Your statements about what work and don't have no backup, and
    go against all existing evidence today, and yet you're blasting them
    for lack of serious study. Try to do some yourself.

    On May 19, 2008, at 11:46 AM, mouss wrote:
    > but anyway. I don't see what mailchannel are bringing that deserves
    > this debate. it looks to me like this:
    >
    > - they started trying to sell greeetpause. and it didn't work enough
    > - they moved to "slowdown" and they're trying to talk about
    >
    > In both cases, they don't provide any serious study. they only show
    > numbers that go with their claims. I don't know for others, but my
    > logs don't seem to confirm theirs.
    >
    > and the slowdown thing is based on the theory that spammers have
    > better things to do than wait. now that we know more about botnets,
    > this theory doesn't stand.
    >
    > how long would it take to write an asynchronous smtp client?
    >
    >



  16. Re: MailChannels Traffic Control (fwd)

    On May 19, 2008, at 2:05 PM, Benny Pedersen wrote:
    > On Mon, May 19, 2008 20:18, Ralf Hildebrandt wrote:
    >> To be fair (I'm testing it right now): It's easy to get running.
    >> Right now the Tarpit and slowdown features cannot be had in Postfix,
    >> so I'm giving it a spin.

    >
    > give longer greylist times will do without marketing :-)


    It will slow down real user's mail a lot too.

    Please take time to actually learn about what the product does before
    you make statements like this. Or at least put a tag on your e-mail
    that says "I haven't read the first thing about how this product
    works, but it seems to me..."

    NOTE: no affiliation with Mailchannels, just personally tired of
    seeing people make authoritative statements about products they
    haven't even read the basics about. It turns people off from doing
    their own research because they don't realize the poster is taking out
    of the wrong side.


  17. RE: MailChannels Traffic Control (fwd)


    > Why is everyone willing to skip doing 5 minutes of research?


    I did.

    > Mailchannels idea may not work for you. But it's worth doing a bit of


    > research.


    Oh the idea is nice. But there are others out there that - from my
    personal perspective - are doing this stuff much better, at least from
    what I can tell. See BarricadeMX from Fort Systems Ltd.

    > FYI: again, not affiliated and we're not using it either. But the
    > product is very well designed and it's a lot more clever/useful than
    > anything you're comparing it to.


    I compare it to BarricadeMX and as I said, I think it is not so clever.
    Personal opinion.

    Regards,
    JP


  18. Re: MailChannels Traffic Control (fwd)


    On Tue, May 20, 2008 19:23, Jo Rhett wrote:

    >> give longer greylist times will do without marketing :-)

    > It will slow down real user's mail a lot too.


    real mail servers is

    1: known
    2: can be bypassed in greylist on that fact #1


    Benny Pedersen
    Need more webspace ? http://www.servage.net/?coupon=cust37098


  19. Re: MailChannels Traffic Control (fwd)

    May I suggest that you redo your research? BarricadeMX has no feature
    at all that even attempts to address the issue MailChannels is
    addressing, ie slowing down the TCP channel.

    On May 20, 2008, at 10:32 AM, Koopmann, Jan-Peter wrote:
    >> Why is everyone willing to skip doing 5 minutes of research?

    >
    > I did.
    >
    >> Mailchannels idea may not work for you. But it's worth doing a bit
    >> of

    >
    >> research.

    >
    > Oh the idea is nice. But there are others out there that - from my
    > personal perspective - are doing this stuff much better, at least from
    > what I can tell. See BarricadeMX from Fort Systems Ltd.
    >
    >> FYI: again, not affiliated and we're not using it either. But the
    >> product is very well designed and it's a lot more clever/useful than
    >> anything you're comparing it to.

    >
    > I compare it to BarricadeMX and as I said, I think it is not so
    > clever.
    > Personal opinion.
    >
    > Regards,
    > JP


    --
    Jo Rhett
    Net Consonance : consonant endings by net philanthropy, open source
    and other randomness


  20. Re: MailChannels Traffic Control (fwd)

    >>> give longer greylist times will do without marketing :-)
    >> It will slow down real user's mail a lot too.


    > On May 20, 2008, at 3:58 PM, Benny Pedersen wrote:
    > real mail servers is
    >
    > 1: known
    > 2: can be bypassed in greylist on that fact #1


    Both of these are addressed by Mailchannels. But what to do when an
    "unknown mail server" contacts you is different in the approach.
    greylist effectiveness is down to less than 10% effective at this
    point, because the botnets know to retry now.

    --
    Jo Rhett
    Net Consonance : consonant endings by net philanthropy, open source
    and other randomness


+ Reply to Thread
Page 1 of 2 1 2 LastLast