The Community Forums

Interact with an entire community of cPanel & WHM users!
  1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

blackhole / fail revisited

Discussion in 'E-mail Discussions' started by hostricity, Jan 25, 2008.

  1. hostricity

    hostricity Active Member

    Joined:
    Jun 22, 2004
    Messages:
    39
    Likes Received:
    0
    Trophy Points:
    6
    I want to clarify something to make sure that we aren't causing ourselves a problem.

    I'm curious as to your thoughts on the following and the possibility of another solution - that doesn't send the bounce messages or selectively sends them if there's an spf record on the other end -- or something:

    As I understand it, :fail: rejects email with a system message instead of accepting it. Theoretically, this will reduce the load on the server because the email is never accepted.

    The problem is that spammers love to spuf our domains and email addresses when they send spam from their servers. When that happens, we can get 1000's of bounce emails in our mail queue.

    For example: spammer sends 1000's of spams to BOGUSaddresses@ourdomain.com, claiming to be from GOODaddress@ourdomain.com.

    As a result, we get huge numbers of bounce messages, which 1). Make our mail queue huge and 2). Make it impossible to look at the mail queue when we think we might actually have a spammer using our server because of all the real bounce messages.

    So, we're looking at changing our default from :fail: to :blackhole: -- because when a spammer sends to a bogus address as above, it stops right there.

    I understand that this means if someone sends an email to gooBaddress@ourdomain.com instead of gooDaddress@ourdomain.com, the sender will not know that they misaddressed the email. -- But, our assessment is that this is an easier thing to deal with than all of the bounce messsages.

    As of right now, we're going to proceed with this unless there's a show stopper or a better solution.

    G
     
  2. mtindor

    mtindor Well-Known Member

    Joined:
    Sep 14, 2004
    Messages:
    1,279
    Likes Received:
    36
    Trophy Points:
    48
    Location:
    inside a catfish
    cPanel Access Level:
    Root Administrator
    :fail: is what you want.

    :fail: rejects during SMTP phase - so there is no way for a message to a nonexistent recipient to make it on your server unless you have a 'Default Address' configured.

    Default Address - if you have a default address configured, then any mail for your domain is accepted, period.... if the mail is to a valid forwarder address or POP3 user, it is delivered there. If the mail is not to a valid pop3 user or forwarder, it is sent to the email address specified in the 'Default Address' area.

    1. Do NOT use default addresses. There isn't one good reason to use one that could not be countered with 100 bad reasons for using one.

    2. Use :fail: , not blackhole.

    If somebody is spoofing bogus from addresses in your domain when they send out spam AND you are receiving those emails in your mailboxes and queue, then you have a Default Address configured and need to disable it.

    Mike
     
  3. hostricity

    hostricity Active Member

    Joined:
    Jun 22, 2004
    Messages:
    39
    Likes Received:
    0
    Trophy Points:
    6
    That's not what's happening

    The issue isn't the email "making it onto the server". It is that the bounce messges get sent to us because they spufe valid email addresses as the sending addresses.

    fail sends out bounce messages. Our mail queue get filled up with them because the from address is a valid address on our server.

    good@mydomain.com is an actual address. They send out thousands of emails to bogus email addresses at mydomain.com, claiming to come from the good address. That means the address good@mydomain.com is flooded with rejection notices.

    I can't do anything about the one's that are generated by other servers, bu I can stop the one's generated by my server by using blackhole instead of fail.

    Fortunately, they seem to like to send these spam emails to bogus addresse on the server, so blackhole stops them dead.

    The bottom line is this: Using blackhole causes the email to fall off the face of the Earth and there is no more activity from that particular spam.
     
  4. sparek-3

    sparek-3 Well-Known Member

    Joined:
    Aug 10, 2002
    Messages:
    1,381
    Likes Received:
    23
    Trophy Points:
    38
    cPanel Access Level:
    Root Administrator
    Are all of these messages coming from one source? If so, or if it is a manageable number of IPs, I would just block those IPs with iptables or with the firewall software you have on the server.

    The messages themselves aren't being sent through your server. They are just addressed to fake (non-existent) addresses on your server. The sender-envelope is set to a valid e-mail address that is on your server. If they are all being sent by one IP or a group of IPs, just block that IP from connecting to your server. Let the server that is actually sending the messages deal with the backlog of messages in their queue. Perhaps then they will take action against the actual spammer.

    Of course if this is happening on 100 or 200 IPs, then this could be more difficult. But if it is just one IP or just a handful of IPs, it should be manageable.
     
  5. hostricity

    hostricity Active Member

    Joined:
    Jun 22, 2004
    Messages:
    39
    Likes Received:
    0
    Trophy Points:
    6
    None of this addresses my question

    Look.

    I know that the messages aen't being sent through my server. I keep saying that.

    We use several methods to block offending ip's. But, spammers, these days, do things like change their op address every 10 minutes while they are sending.

    Using blackhole has eliminated 95% of the garbage bounce messages.

    None of this addresses my question:

    Is there a gotcha that would make it undesirable to use blackhole.
     
  6. RickG

    RickG Well-Known Member

    Joined:
    Feb 28, 2005
    Messages:
    238
    Likes Received:
    2
    Trophy Points:
    18
    Location:
    North Carolina
    G: In a typical backscatter attack, which is sounds like you might be describing, the spammer randomly sets the return address to be from randomuser@yourdomain.com. In this type of attack (which I am watching happen to a client's account as I type this by tailing /var/log/exim_mainlog), there are hundreds of bounce messages coming in from all over the place addressed to randomuser@yourdomain.com (each one is different). The server is rejecting these at the SMTP phase because randomuser@yourdomain.com is not a valid account on the server. This is with the default address of :fail:. In the log file the entry looks like:
    Code:
    2008-01-26 06:49:15 H=mx00.placemark.com [216.39.69.170] F=<> rejected RCPT <randomuser@yourdomain.com>: User Unknown
    With :blackhole:, mail addressed to randomuser@yourdomain.com passes through almost the entire Exim process before getting sent to the bit bucket. Take a look at /etc/exim.conf and look for the "verify = recipient" line. The message goes through everything up to that point including spam and RBL checks (depending on how you have Exim configured) placing a huge load on server resources before if finally gets written to /dev/null. See http://www.configserver.com/free/fail.html if you need more of an explanation.

    However, in your backscatter scenario which we are all trying to understand, one thing sounds different. You are saying that the spammer is spoofing the mail envelope from anactualuser@yourdomain.com. So all these bounce messages are actually trying to be written to anactualuser@yourdomain.com's mailbox. Is that correct?

    If this is the scenario, something doesn't make sense / isn't configured correctly. How is changing from :fail: to :blackhole: going to help? The messages will still try to write to anactualuser@yourdomain.com's mailbox. If that is the case, sparek-3's suggestion (trying to block IPs) is the only solution.

    What are we missing? We all deal with this stuff everyday and are just trying to help.
     
    #6 RickG, Jan 26, 2008
    Last edited: Jan 26, 2008
  7. WendyH

    WendyH Registered

    Joined:
    Jan 10, 2007
    Messages:
    2
    Likes Received:
    0
    Trophy Points:
    1
    A simple solution is to set up an SPF record and do SPF checks on incoming email. If the record is set up correctly it would eliminate all the mail that is being spoofed.
     
  8. nickp666

    nickp666 Well-Known Member

    Joined:
    Jan 28, 2005
    Messages:
    770
    Likes Received:
    2
    Trophy Points:
    18
    Location:
    /dev/null
    mailscanner has helped us largely with combatting backscatter, when messages are sent from our servers, mailscanner leaves a watermark in the message.

    With this method, mailscanner spams out all bounce messages that dont have a watermark, therefore stopping them from entering the users mailbox in the first place and enables legitimate bounces through.
     
  9. Kent Brockman

    Kent Brockman Well-Known Member

    Joined:
    Jan 20, 2008
    Messages:
    1,130
    Likes Received:
    3
    Trophy Points:
    38
    Location:
    Buenos Aires, Argentina
    cPanel Access Level:
    Root Administrator
    Twitter:
    Hi, what kind of setup is more recommendable to use with SPF records in this case?
     
  10. nickp666

    nickp666 Well-Known Member

    Joined:
    Jan 28, 2005
    Messages:
    770
    Likes Received:
    2
    Trophy Points:
    18
    Location:
    /dev/null
    sorry but I fail to see how SPF will help in this case, largely because it still isnt that actively adopted by a large proportion of the hosts on the planet, and what if servers matching legitimate spf records are sending the mail? you still then have the same problem...
     
  11. Kent Brockman

    Kent Brockman Well-Known Member

    Joined:
    Jan 20, 2008
    Messages:
    1,130
    Likes Received:
    3
    Trophy Points:
    38
    Location:
    Buenos Aires, Argentina
    cPanel Access Level:
    Root Administrator
    Twitter:
    Nope, you can set your ip as the valid sender in an SPF record. You can define that if the mx of a sender from yourdomain.com doesn't resolve to 111.222.333.444 (your actual IP), that mail must be deleted.

    I use this record in the template for all of my customers, and no one is reporting problems:
    v=spf1 a ptr ~all

    In a backscatter scenario, the From address is spoofed, but they cannot spoof the IP from where the mail is coming. This way, the IP used cannot be traced to your server and is discarted :)
     
Loading...

Share This Page