|
From: Lionel B. <lio...@bo...> - 2005-05-17 08:58:28
|
Michel Bouissou wrote the following on 17.05.2005 10:31 : >Lionel Bouton a =E9crit : > =20 > >>I see another problem with this: >>when an ISP with which you have a lot of traffic will change a >>mailserver IP address, your local MTA will get a lot of new connections >>coming in. Having a ceiling for the number of connect entries with the >>same src will more or less control the rate of new senders/IP address. >>The problem is that you can't reliably detect which IP are legit MTAs >>and which are Windows zombies based on this rate alone. >>Any thoughts? >> =20 >> > >I don't think it will cause a problem, only a short transition phase. Wh= at >will happen is the following : > >1/ The ISP's mailserver changes IP and starts sending mail. The first 10 >(for example) messages go to "connect", the followings are tarpitted. > >2/ About 15-30 minutes later (usually), the mailserver retransmits. The = 10 >messages in connect are accepted and addresses go to from_awl (those won= 't >wait anymore). 10 new entries are available in connect for other new >messages now. > >3/ Quite probably, the main domains hosted by this ISP will very quicly >make it to domain_awl (assuming we receive a high mail traffic from this >ISP -- but if we don't, the limit of 10 waiting messages from this sourc= e >will probably not cause any problem). > =20 > You forget that big ISPs relay lots of mails with senders in more or less random domains (and there is legit mail in there). This is a very smal percentage but given the volumes, it amounts to lots of emails -> this can very well polute your connect table more than you want. If we assume that the domain_awl will kick in properly for the ISPs regular domains and an average 30 minutes retry, you will allow only 5 days * 48 retry period * 10 mails per ISP that won't match the domain_awl : 2400 mails only from ISPa to ISPb. If you put SQLgrey between two ISPs with 10-100 millions mail/day each, there are high chances that you will end up with mails that can't come through. The main problem is that you'd want the limit to be dynamic based on the trafic you are accepting from this IP. I don't think a fixed limit will d= o. >I think that to determine whether or not this may cause problems, we hav= e >to try it out. > > =20 > I will continue to think about it. I'm foreseeing problems with the above and I'll try to find a way to bring enough feedback on the amount of trafic accepted for a src to make an educated decision when we want to add an entry to connect. >For I'd love to eliminate from my connect table serie of entries such as= : > >mysql> select src, sender_name, sender_domain from connect where src =3D >'68.116.107.206' order by sender_domain; > > =20 > From the look of your results to this query, it seems the spambot reuses the same source address quite often. We could refine the tarpiting with a check on the src and sender_* columns : that's unusual to have one sender sending more than a couple of mails to the same MX in less than 20 minutes and I can't think of any sane person sending them by the dozens in the same amount of time... Lionel. |