Re: No reason not to use reject_unverified sender (was Re: reject_unverified_sender vs greylisting)

From: mouss (no email)
Date: Tue Feb 10 2009 - 16:18:44 EST

  • Next message: JoĆ£o Miguel Neves: "Re: No reason not to use reject_unverified sender (was Re: reject_unverified_sender vs greylisting)"

    Joćo Miguel Neves a écrit :
    > Charles Marcus escreveu:
    >> Here's a link informing why indiscriminate use of SAV is bad, and what
    >> it should be used for:
    >>
    >> http://www.backscatterer.org/?target=sendercallouts
    > OK, I've finished reading and analyzing that text. My conclusion is that
    > there's no reason not to use reject_unverified sender.
    >
    > In this answer I'm assuming 1) the postfix implementation of SAV and
    > that any implementation and 2) that MTAs implement the RFCs (so they
    > have a configuration that matches, for instance, the Book of Postfix).
    >
    > There are 3 claims in that text:
    >
    > 1) That by disabling VRFY, a sysadmin has decided to disable all kind of
    > email address verification.
    >
    > Most people disabled VRFY to prevent spammer tests for email addresses,
    > nothing else. If you want to disable all tests for email addresses you
    > accept all email for all email addresses, even non-existing ones and
    > later discard the invalid ones.

    where did you get this? I disable VRFY because _I_ don't need it. you
    have no business validating addresses on my server unless you want to
    send me mail. my server is not here to help you filter your spam. I
    already have my share.

    I have no problem if the SAV client implements enough spam filtering
    before knocking on my door, but this is not your case: you do SAV even
    if the clien is listed in zen. you are free not to use zen, but you are
    not free to mirror zen listed connections on my server.

    > That's the only way to do it (and the
    > reason why some of my clients are using catch-all addresses that they
    > redirect to /dev/null).
    >
    > 2) That a spammer can create a DDOS using SAV.
    >
    > You'll get a connection per server to which those were sent (postfix
    > caches the request, so it will only validate an email adress once).
    >

    you are confused. they send junk to N different servers. these different
    servers have nothing to cache. they will then connect to my server to
    validate the address. That's N smtp connections to my server.

    > SAV actually helps reduce the effect of the DDOS attack. In the non-SAV
    > scenario, you get 30 million bounce messages.

    why? I don't do SAV and I don't send bounces.

    > In the SAV cenario, each
    > server does one check per email adress (that costs you less bandwidth
    > and disk space than a Bounce message) and that single check will avoid
    > several bounce messages.
    >

    you are inventing bounces.

    > 3) That SAV might create a loop.
    >
    > The SAV check in postfix is done with the postmaster address by default.
    > If the target server does the same check back, then the SAV server
    > replies that postmaster is valid (assuming it's well-configured and
    > RFC-compliant).
    >
    > Have I missed anything?
    >

    By using SAV, you want to filter _your_ spam using _my_ resources. If I
    accept that, then it is a favour I am doing you. and I will only do this
    favour if I think your are "nice":
    - the minimum is to do enough checks before knocking my server.
    - it must be easy to find who you are and how to contact you. This means
    that if I see a probe in my logs, I must be able to find a web page to
    know who you are and what you do, and you also must have a fully working
    abuse address.


  • Next message: JoĆ£o Miguel Neves: "Re: No reason not to use reject_unverified sender (was Re: reject_unverified_sender vs greylisting)"





    Hosted Email Solutions

    Invaluement Anti-Spam DNSBLs



    Powered By FreeBSD   Powered By FreeBSD