Let me see if I can paraphrase what you're saying. gmail's outbound server forces the from address to be the same as the address which was used to authenticate the submission. Is that correct?

While this would eliminated forged headers, I fail to see what it would accomplish. I don't see how it would keep a server's IP address from being listed in an RBL.

In addition, I suspect that it would go against the RFCs for handling of email. I'm not certain of this though. Would someone care to look it up?

As Jake mentioned, this would require some customized programming to accomplish. This is not something we typically do.

I haven't yet read and thought about Rajesh's writing. I apologize for that. It certainly deserves some careful deliberation.

--
-Eric 'shubes'

karpaha vinayaham wrote:
Hi
Regarding the spam mail generated through a authenticated user, today i have send a test mail and checked with gmail account for spamming, i changed the from address as a...@xyz.com <mailto:a...@xyz.com> and i used the authentication through a valid gmail account x...@gmail.com <mailto:x...@gmail.com>. The beauty is that the FROM address has changed to x...@gmail.com <mailto:x...@gmail.com> instead of a...@xyz.com <mailto:a...@xyz.com> and the message is properly delivered to the mentioned recipient.


NOTE

Eventhough i changed the from address and tried to do spamming, gmail server changes the from address as a authentiacted user email id, so their IP will not be listed in RBL. Is it possible in qmailtoaster to implement like this. As per Rajesh suggestion, we can limit the number of connections later.

I think, by doing this we can prevent our server IP from rbl list.


Jake and Eric i am looking forward for your comments on this.


Best Regards
Vinay

On 12/12/09, *Rajesh M* <24x7ser...@24x7server.net <mailto:24x7ser...@24x7server.net>> wrote:

    hi

    we run qmail toaster on our all our email servers. qmailtoaster provided
    great protection against external spam but to date i am quite helpless
    against spam coming from within the server or the misuse of the same by
    own customers

    i am quoting below my experiences

    1) authenticated sender spamming
    qmailtoaster smtp is built in such a way that once authenticated it
    allows
    sending out emails immaterial of whether the envelope sender is a domain
    on the server or not.

    example in my outlook express i create a dummy email id ;
    x...@yahoo.com <mailto:x...@yahoo.com> as
    the mail from and reply to. for authentication i use some
    use...@domain_on_server.com <mailto:use...@domain_on_server.com> and
    password ... and thats it i can send any
    no of emails with the mailfrom as a dummy yahoo account. this is how
    spamming has been taking place thru my server since some smart hacker
    picks up the smtp auth userid and password of some client of mine and
    misuses it.


    2) clients misusing the system
    my own clients can misuse the system. they purchase email service
    for one
    single domain and use the smtp auth information for sending out emails
    with the mailfrom as their other domains

    3) at present there is no check on the number of emails per hour /
    per day
    been implemented, there is no such restrictions in qmail ...

    work around solutions that i am looking at is as such

    i have created absolutely non-standard ports for my clients

    i have analysed smtp traffic during different times of day example
    during
    night time the traffic is very low and during day time from 10 am to
    6 pm
    it is at the peak

    i used simple iptables rules to block ips which trespass the limits

    one rule for daytime and one rule for night time which are added /
    removed
    automtically by a cron job.

    #### RULE BETWEEN 10 AM AND 6 PM
    iptables -I INPUT -p tcp --dport 25 -i eth0 -m state --state NEW -m
    recent
    --set
    iptables -I INPUT -p tcp --dport 25 -i eth0 -m state --state NEW -m
    recent
    --update --seconds 120 --hitcount 90 -j DROP

    ####  RULE BETWEEN 6 PM UPTO 10 AM
    iptables -I INPUT -p tcp --dport 5225 -i eth0 -m state --state NEW -m
    recent --set
    iptables -I INPUT -p tcp --dport 5225 -i eth0 -m state --state NEW -m
    recent --update --seconds 120 --hitcount 30 -j DROP

    also building a queue monitoring tool -- checking the queue and if
    the no
    of emails exceed a specified limit, the tool will pickup ips from the
    emails in the queue and block them


    thanks
    rajesh





    
---------------------------------------------------------------------------------
    Qmailtoaster is sponsored by Vickers Consulting Group
    (www.vickersconsulting.com <http://www.vickersconsulting.com>)
       Vickers Consulting Group offers Qmailtoaster support and
    installations.
         If you need professional help with your setup, contact them today!
    
---------------------------------------------------------------------------------
        Please visit qmailtoaster.com <http://qmailtoaster.com> for the
    latest news, updates, and packages.

         To unsubscribe, e-mail:
    qmailtoaster-list-unsubscr...@qmailtoaster.com
    <mailto:qmailtoaster-list-unsubscr...@qmailtoaster.com>
        For additional commands, e-mail:
    qmailtoaster-list-h...@qmailtoaster.com
    <mailto:qmailtoaster-list-h...@qmailtoaster.com>







--
-Eric 'shubes'


---------------------------------------------------------------------------------
Qmailtoaster is sponsored by Vickers Consulting Group 
(www.vickersconsulting.com)
   Vickers Consulting Group offers Qmailtoaster support and installations.
     If you need professional help with your setup, contact them today!
---------------------------------------------------------------------------------
    Please visit qmailtoaster.com for the latest news, updates, and packages.
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
    For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com


Reply via email to