Outgoing mail SPAM protection trough phpmail

Discussion in 'Feature Requests' started by Elfchen, Jul 1, 2007.

  1. Elfchen

    Elfchen New Member

    When sending mail to outside a few additions would be quite necessary:

    1.
    Insert inside header a X-remark like:

    This mail is sent from a webhosting server. If you receive any spam or unwanted mail please contact <adminmail> first before reporting to public SPAM lists.

    This can be done by using an SMTP proxy for outgoing mail which is able to add some information to the header.

    2.
    Insert inside header a X-remark like:

    X-Script: This mail is sent from script located at <path>

    This is helpful when user uses a buggy script to easily detect where the script is located.

    3.
    Block outgoing massmailing and bcc by default.

    Block outgoing mail by default to x mails / hour and/or max. x receivers (bcc/cc) per mail.

    This prevents the system from beeing used as spamrelay if a script is insecure.


    It happens quite often that webhosting customers uses insecure scripts and if you are not able to block these server will be listed on RBL very fast.

    This is to prevent your server from beeing listed as spam relay on RBL - because it's very hard to remove a listed server from the lists and when it's listed many other receivers can't receive mails sent by your listed server.
     
  2. till

    till Super Moderator Staff Member ISPConfig Developer

    As far as I know, you can configure this in your php.ini file by adding additional parameters when php calls the sendmail command. So this is not a feature that can / must be implemented in ISPConfig
     
  3. Elfchen

    Elfchen New Member

    Then you should tell the users how to do that ...

    you need to modify the php.ini (general php steering). inside php.ini you'll find the sendmail path for sending mail. These path you need to point to a script which did what I've requested or anything else. Maybe if you want to add something do it like this:

    Code:
    #!/usr/bin/perl
    
    open(MAIL, "| /usr/lib/sendmail -oi -t") or die "can't open sendmail";
    while () {
        print MAIL $_;
    }
    print MAIL qq(
    ---
    I add some text to the mail now ...
    );
    close MAIL;
    
     
  4. georgew

    georgew New Member

    Till is right, this is not an ISPconfig problem, but a generic php problem.

    And once a script for this purpose was found, it would "fix" every web server, regardless of control panel or os...

    What we need is a tool to detect the spammer, and to quarantine everything he does.

    Probably the easiest approach is to quarantine everything first.

    Then the admin browses the held mail, to identify patterns.

    Half of the patterns he finds are for mail to pass through, because it is form mail generated by predictable web pages.

    The other half of the patterns identify spam, and cause the mail to be deleted.

    If you get hit hard, and 2 million spams are in quarantine, you simply browse for things to delete, then you delete them, and go back for more untill done.
    In my experience the spammers don't often have more than 4 or 5 different spams, so this shouldn't take long (except that waiting for the deletions might take a while if there are a lot).

    Now I have been watching the web server spammers. At first, they sent as many spams as possible, but as time went on they found that sending smaller numbers of spams was better. Lately they are sending such small numbers of spams that the only way to stop them is to quarantine everything.

    Of course this won't work on a server with end-user email. But if you are
    reading this thread, you may have realized you can't put email end users
    on a web server... doing so is asking for a lot of hate and scorn from your customers, every time your server is blacklisted. My customers /love/ my email services, and web server mail is reserved for forms and feedback. I still get attacked and blacklisted, but I keep the server in the blacklists, and I encourage web users to not use email, use forms that populate a database instead, so you have something more useful than email.

    Of course this php script would have to be compatable with all the email systems common on web servers, not just sendmail... but that part is trivial.

    An alternative would be to put this in between the mail server and the outside world, and intercept everything from the mail server, just in case the spammers aren't using a php script.
     

Share This Page