Menu
▾
▴
sqlgrey-users — Users of SQLgrey
You can subscribe to this list here.
| 2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(10) |
Nov
(37) |
Dec
(66) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2005 |
Jan
(52) |
Feb
(136) |
Mar
(65) |
Apr
(38) |
May
(46) |
Jun
(143) |
Jul
(60) |
Aug
(33) |
Sep
(79) |
Oct
(29) |
Nov
(13) |
Dec
(14) |
| 2006 |
Jan
(25) |
Feb
(26) |
Mar
(4) |
Apr
(9) |
May
(29) |
Jun
|
Jul
(9) |
Aug
(11) |
Sep
(10) |
Oct
(9) |
Nov
(45) |
Dec
(8) |
| 2007 |
Jan
(82) |
Feb
(61) |
Mar
(39) |
Apr
(7) |
May
(9) |
Jun
(16) |
Jul
(2) |
Aug
(22) |
Sep
(2) |
Oct
|
Nov
(4) |
Dec
(5) |
| 2008 |
Jan
|
Feb
|
Mar
(5) |
Apr
(2) |
May
(8) |
Jun
|
Jul
(10) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2009 |
Jan
|
Feb
|
Mar
|
Apr
(32) |
May
|
Jun
(7) |
Jul
|
Aug
(38) |
Sep
(3) |
Oct
|
Nov
(4) |
Dec
|
| 2010 |
Jan
(36) |
Feb
(32) |
Mar
(2) |
Apr
(19) |
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
(6) |
Nov
(8) |
Dec
|
| 2011 |
Jan
(3) |
Feb
|
Mar
(5) |
Apr
|
May
(2) |
Jun
(1) |
Jul
|
Aug
(3) |
Sep
|
Oct
|
Nov
|
Dec
(6) |
| 2012 |
Jan
|
Feb
|
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(2) |
Oct
|
Nov
|
Dec
|
| 2013 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
(1) |
Sep
(1) |
Oct
|
Nov
(6) |
Dec
(10) |
| 2014 |
Jan
(8) |
Feb
|
Mar
|
Apr
|
May
|
Jun
(3) |
Jul
(34) |
Aug
(6) |
Sep
|
Oct
(1) |
Nov
|
Dec
|
| 2015 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(18) |
Jul
(13) |
Aug
(30) |
Sep
(4) |
Oct
(1) |
Nov
|
Dec
(4) |
| 2016 |
Jan
(2) |
Feb
(10) |
Mar
(3) |
Apr
|
May
|
Jun
(11) |
Jul
|
Aug
|
Sep
(2) |
Oct
|
Nov
|
Dec
|
| 2017 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2018 |
Jan
|
Feb
|
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2019 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Michel B. <mi...@bo...> - 2005-05-27 22:33:17
|
SQLgrey 1.5.6 + MySQL: In both AWLs, everytime last_seen is updated,=20 first_seen is updated as well, where it should not. Cheers. --=20 Michel Bouissou <mi...@bo...> OpenPGP ID 0xDDE8AC6E Appel de 200 Informaticiens pour le NON au Trait=E9 Constitutionnel Europ=E9en: http://www.200informaticiens.ras.eu.org |
|
From: Lionel B. <lio...@bo...> - 2005-05-20 14:24:34
|
Ray Booysen wrote the following on 20.05.2005 16:04 : > # 20/05/2005 > # public.wavexservices.com[83.217.101.34] > public.wavexservices.com > # Comment: Wavex Services Mail Server > # Reason: Does not retry > Thanks, the repository is updated and my tree in sync. Lionel |
|
From: Ray B. <rj_...@rj...> - 2005-05-20 14:04:18
|
# 20/05/2005 # public.wavexservices.com[83.217.101.34] public.wavexservices.com # Comment: Wavex Services Mail Server # Reason: Does not retry -- Ray Booysen rj_...@rj... |
|
From: Beast <be...@i6...> - 2005-05-20 03:34:17
|
Lionel Bouton wrote: > Beast wrote the following on 13.05.2005 11:17 : > > >> >>If I comment check_policy_service, then the response is quicker >>(arround 1 sec, with sqlgrey _always_ 15-20 sec). > > > > Could you set the log level to debug : > loglevel = 4 > in /etc/sqlgrey/sqlgrey.conf, send a couple of mails to your server and > send me the logs (postfix+sqlgrey) ? > Sorry for the delay, I was on leave. Unfortunately, the test machine has already formated, rebuild everything solves the problem. Thanks. -- --beast |
|
From: Ray B. <rj_...@rj...> - 2005-05-19 11:59:06
|
Klaus Alexander Seistrup wrote: >On 19/05/05 Ray Booysen wrote: > > =20 > >>Would you mind posting your scripts that pull the SQLGrey data into MRT= G? :) >> =20 >> > >Well, I'm using munin=B9 from Debian/Ubuntu which eases setup >substantially. All I had to do was write a munin plugin, then munin >handles the graph stuff. It uses Python and the pyPgSQL module. > >The script, which probably needs gentle changes in order to work >smoothly on other setups than mine, is available AS IS from > > <http://magnetic-ink.dk/pub/python/munin-sqlgrey> > >:-) > > // Klaus > >=B9) > <http://packages.ubuntu.com/munin> > <http://packages.ubuntu.com/munin-node> > =20 > Hi Klaus Thanks for the script. I will have a look at it :) Cheers Ray --=20 Ray Booysen rj_...@rj... |
|
From: Klaus A. S. <kse...@gm...> - 2005-05-19 10:04:13
|
On 19/05/05, Michel Bouissou wrote: >>> Mine almost doubled, but now seems to stabilize approximately at previo= us >>> level. >> >> The increase in from_awl is due to change of awl_age from 48 to 64 days. >=20 > I was talking of "connect", not "from_awl"... I know. The reason I mentioned the increase in from_awl is that I upped awl_age from 48 days to 64 days at the beginning of this month, and that graph is still increasing - but not due to SOBER. The connect graph did increase, as I also explained, but it seems to be decreasing now. Cheers, --=20 Klaus Alexander Seistrup Magnetic Ink =B7 Copenhagen =B7 Denmark http://magnetic-ink.dk/ |
|
From: Michel B. <mi...@bo...> - 2005-05-19 09:55:22
|
Le Jeudi 19 Mai 2005 10:35, Klaus Alexander Seistrup a =E9crit : > On 19/05/05, I wrote: > > Mine almost doubled, but now seems to stabilize approximately at prev= ious > > level. > > The increase in from_awl is due to change of awl_age from 48 to 64 days= . I was talking of "connect", not "from_awl"... --=20 Michel Bouissou <mi...@bo...> OpenPGP ID 0xDDE8AC6E Appel de 200 Informaticiens pour le NON au Trait=E9 Constitutionnel Europ=E9en: http://www.200informaticiens.ras.eu.org |
|
From: Klaus A. S. <kse...@gm...> - 2005-05-19 09:53:22
|
On 19/05/05 Ray Booysen wrote: > Would you mind posting your scripts that pull the SQLGrey data into MRTG?= :) Well, I'm using munin=B9 from Debian/Ubuntu which eases setup substantially. All I had to do was write a munin plugin, then munin handles the graph stuff. It uses Python and the pyPgSQL module. The script, which probably needs gentle changes in order to work smoothly on other setups than mine, is available AS IS from <http://magnetic-ink.dk/pub/python/munin-sqlgrey> :-) // Klaus =B9) <http://packages.ubuntu.com/munin> <http://packages.ubuntu.com/munin-node> --=20 Klaus Alexander Seistrup Magnetic Ink =B7 Copenhagen =B7 Denmark http://magnetic-ink.dk/ |
|
From: Ray B. <rj_...@rj...> - 2005-05-19 08:52:47
|
Klaus Alexander Seistrup wrote: >On 19/05/05, Michel Bouissou wrote: > > > >>One thought: With the new evolution of the Sober virus, my connect table's >>average size has been multiplied by a factor 10 during the last 4 days. And >>counting... >> >>Check yours... >> >> > >Mine almost doubled, but now seems to stabilize approximately at previous level. > >Cheers, > > > Hi Klaus Would you mind posting your scripts that pull the SQLGrey data into MRTG? :) Regards Ray -- Ray Booysen rj_...@rj... |
|
From: Klaus A. S. <kse...@gm...> - 2005-05-19 08:35:33
|
On 19/05/05, I wrote: > Mine almost doubled, but now seems to stabilize approximately at previous > level. The increase in from_awl is due to change of awl_age from 48 to 64 days. --=20 Klaus Alexander Seistrup Magnetic Ink =B7 Copenhagen =B7 Denmark http://magnetic-ink.dk/ |
|
From: Klaus A. S. <kse...@gm...> - 2005-05-19 08:33:10
|
On 19/05/05, Michel Bouissou wrote: > One thought: With the new evolution of the Sober virus, my connect table'= s > average size has been multiplied by a factor 10 during the last 4 days. A= nd > counting... >=20 > Check yours... Mine almost doubled, but now seems to stabilize approximately at previous l= evel. Cheers, --=20 Klaus Alexander Seistrup Magnetic Ink =B7 Copenhagen =B7 Denmark http://magnetic-ink.dk/ |
|
From: Michel B. <mi...@bo...> - 2005-05-18 22:20:43
|
Le Mardi 17 Mai 2005 09:54, Lionel Bouton a =E9crit : > Any thoughts? One thought: With the new evolution of the Sober virus, my connect table'= s=20 average size has been multiplied by a factor 10 during the last 4 days. A= nd=20 counting... Check yours... --=20 Michel Bouissou <mi...@bo...> OpenPGP ID 0xDDE8AC6E Appel de 200 Informaticiens pour le NON au Trait=E9 Constitutionnel Europ=E9en: http://www.200informaticiens.ras.eu.org |
|
From: Michel B. <mi...@bo...> - 2005-05-17 11:28:32
|
Lionel Bouton a =E9crit : > > We could refine the tarpiting [...] I was thinking of another way to make its decisions more "dynamic" : Suppose "n" is the limit of number of entries waiting in "connect" for a given IP, at which we stop accepting new entries (we start "tarpitting"). Now suppose we stop accepting new entries ONLY if there are more than "n" entries in connect for this IP, AND LESS than "n" entries for this IP in "from_awl", AND NO entry for this IP in "domain_awl". This will make sure that "big legitimate senders" don't get hurt by the system, because as soon as they can either make it to "domain_awl" or hav= e retransmitted properly at least one full set of "n" messages, then tarpitting stops for them, and "connect" will then accept any number of entries from them. Doesn't this look better ? Still rather simple, with little needed configuration, and should adapt fair enough to traffic characteristics by itself... --=20 Michel Bouissou <mi...@bo...> OpenPGP ID 0xDDE8AC6E Appel de 200 Informaticiens pour le NON au Trait=E9 Constitutionnel Europ=E9en: http://www.200informaticiens.ras.eu.org |
|
From: Michel B. <mi...@bo...> - 2005-05-17 09:49:22
|
Lionel Bouton a =E9crit : > > From the look of your results to this query, it seems the spambot reuse= s > the same source address quite often. Then check this one: +----------------+------------------------+----------------------------+ | src | sender_name | sender_domain | +----------------+------------------------+----------------------------+ | 84.161.144.202 | jef | acme.com | | 84.161.144.202 | jef | acme.com | | 84.161.144.202 | support | advertising.com | | 84.161.144.202 | support | advertising.com | | 84.161.144.202 | c0.28054cbd.2fafb54e | aol.com | | 84.161.144.202 | c0.28054cbd.2fafb54e | aol.com | | 84.161.144.202 | sternchen4521306 | aol.com | | 84.161.144.202 | sternchen4521306 | aol.com | | 84.161.144.202 | bma | baltmannsweiler.kdrs.de | | 84.161.144.202 | bma | baltmannsweiler.kdrs.de | | 84.161.144.202 | webmaster | erotikgeschichte-2000.de | | 84.161.144.202 | webmaster | erotikgeschichte-2000.de | | 84.161.144.202 | info-rabennest | freenet.de | | 84.161.144.202 | info-rabennest | freenet.de | | 84.161.144.202 | booking | germanwings.com | | 84.161.144.202 | booking | germanwings.com | | 84.161.144.202 | dfink1 | gmx.de | | 84.161.144.202 | dfink1 | gmx.de | | 84.161.144.202 | mail | gudman-gruppe.de | | 84.161.144.202 | mail | gudman-gruppe.de | | 84.161.144.202 | channing | infoschrift.de | | 84.161.144.202 | channing | infoschrift.de | | 84.161.144.202 | zzzzzzzzzzzz | jmason.org | | 84.161.144.202 | zzzzzzzzzzzz | jmason.org | | 84.161.144.202 | ips | mail.ips.es | | 84.161.144.202 | ips | mail.ips.es | | 84.161.144.202 | ann-smirnova | nsandg.com | | 84.161.144.202 | ann-smirnova | nsandg.com | | 84.161.144.202 | e_smtp | ottman.de | | 84.161.144.202 | e_smtp | ottman.de | | 84.161.144.202 | t6cbca7a68bc0a8956fc08 | sweeper-kwh-1.ww-intern.de | | 84.161.144.202 | t6cbca7a68bc0a8956fc08 | sweeper-kwh-1.ww-intern.de | | 84.161.144.202 | info | transformation.co.uk | | 84.161.144.202 | info | transformation.co.uk | | 84.161.144.202 | hofbauerd | web.de | | 84.161.144.202 | hofbauerd | web.de | | 84.161.144.202 | madmosesrulez | web.de | | 84.161.144.202 | madmosesrulez | web.de | | 84.161.144.202 | robert.gauger | wgv-online.de | | 84.161.144.202 | robert.gauger | wgv-online.de | | 84.161.144.202 | dnbvndvw | yahoo.com | | 84.161.144.202 | dnbvndvw | yahoo.com | +----------------+------------------------+----------------------------+ --=20 Michel Bouissou <mi...@bo...> OpenPGP ID 0xDDE8AC6E Appel de 200 Informaticiens pour le NON au Trait=E9 Constitutionnel Europ=E9en: http://www.200informaticiens.ras.eu.org |
|
From: Michel B. <mi...@bo...> - 2005-05-17 09:26:25
|
Lionel Bouton a =E9crit : > > You forget No I don't ;-) > 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. This really depends upon the quantity of legit traffic your own mailserve= r receives... If your mailserver has modest or moderate traffic, it will never receive "tons of legit mail" from any given server, and especially not tons of new unknown traffic from a single IP in a short period. > 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_a= wl > : 2400 mails only from ISPa to ISPb. First don't focus on the "10" number. It is an example, meant as representing a user-settable parameter. It could well be 50 or 100, depending upon the expected amount of incoming "new unknown traffic" at a given site. Then your calculation is false. It is _not_ "2400 mails only from ISPa to ISPb", it is "2400 NEW SENDERS from ISPa to ISPb". Once ONE message from = a given sender is accepted, the sender goes immediately to from_awl, and further messages from the same sender won't be delayed nor greylisted anymore. 2400 messages vs. 2400 NEW SENDERS make very different figures... (And I repeat the I suggest that this simple new feature should be optional. One who doesn't like it shouldn't have to use it...) > 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. ISPs with such traffics (what percentage of them among current SQLgrey users ?) would probably choose not to use this feature... Or maybe they would ;-) > The main problem is that you'd want the limit to be dynamic based on th= e > trafic you are accepting from this IP. I don't think a fixed limit will > do. I don't share this point of view, because of the difference between "new messages" and "new senders" explained above. >> I think that to determine whether or not this may cause problems, we >> have to try it out. > From the look of your results to this query, it seems the spambot reuse= s > the same source address quite often. We could refine the tarpiting wit= h > a check on the src and sender_* columns I think this would weaken the system and limit its interest... > that's unusual to have one sender sending more than a couple of mails t= o > the same MX in less than 20 minutes and I can't think of any sane perso= n > sending them by the dozens in the same amount of time... Take as example a legit mailing-list (or newsletter) that changes its source address (as DSPAM MLs recently did), and a big ISP can receive ton= s of simultaneous "new unknown" traffic from this ML for different recipients at the same time. (But the tarpitting system wouldn't hurt her= e anywaay: Once the first message retry comes back, the sender ML goes to from_awl, and the following messages get accepted without further delays)= . --=20 Michel Bouissou <mi...@bo...> OpenPGP ID 0xDDE8AC6E Appel de 200 Informaticiens pour le NON au Trait=E9 Constitutionnel Europ=E9en: http://www.200informaticiens.ras.eu.org |
|
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. |
|
From: Michel B. <mi...@bo...> - 2005-05-17 08:31:57
|
Lionel Bouton a =E9crit : > > 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? I don't think it will cause a problem, only a short transition phase. Wha= t 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 1= 0 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 source will probably not cause any problem). I think that to determine whether or not this may cause problems, we have to try it out. 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; +----------------+----------------------+---------------------+ | src | sender_name | sender_domain | +----------------+----------------------+---------------------+ | 68.116.107.206 | e1ad8f.a6d9d13e57f7 | aol.com | | 68.116.107.206 | e1ad8f.a6d9d13e57f7 | aol.com | | 68.116.107.206 | e1ad8f.a6d9d13e57f7 | aol.com | | 68.116.107.206 | e1ad8f.a6d9d13e57f7 | aol.com | | 68.116.107.206 | amiealexander79 | charterinternet.com | | 68.116.107.206 | amiealexander79 | charterinternet.com | | 68.116.107.206 | amiealexander79 | charterinternet.com | | 68.116.107.206 | amiealexander79 | charterinternet.com | | 68.116.107.206 | amiealexander79 | charterinternet.com | | 68.116.107.206 | amiealexander79 | charterinternet.com | | 68.116.107.206 | amiealexander79 | charterinternet.com | | 68.116.107.206 | amiealexander79 | charterinternet.com | | 68.116.107.206 | amiealexander79 | charterinternet.com | | 68.116.107.206 | amiealexander79 | charterinternet.com | | 68.116.107.206 | amiealexander79 | charterinternet.com | | 68.116.107.206 | amiealexander79 | charterinternet.com | | 68.116.107.206 | amiealexander79 | charterinternet.com | | 68.116.107.206 | amiealexander79 | charterinternet.com | | 68.116.107.206 | amiealexander79 | charterinternet.com | | 68.116.107.206 | amiealexander79 | charterinternet.com | | 68.116.107.206 | amiealexander79 | charterinternet.com | | 68.116.107.206 | amiealexander79 | charterinternet.com | | 68.116.107.206 | amiealexander79 | charterinternet.com | | 68.116.107.206 | amiealexander79 | charterinternet.com | | 68.116.107.206 | service | company.com | | 68.116.107.206 | service | company.com | | 68.116.107.206 | service | company.com | | 68.116.107.206 | service | company.com | | 68.116.107.206 | service | company.com | | 68.116.107.206 | service | company.com | | 68.116.107.206 | service | company.com | | 68.116.107.206 | service | company.com | | 68.116.107.206 | service | company.com | | 68.116.107.206 | service | company.com | | 68.116.107.206 | service | company.com | | 68.116.107.206 | service | company.com | | 68.116.107.206 | service | company.com | | 68.116.107.206 | service | company.com | | 68.116.107.206 | service | company.com | | 68.116.107.206 | service | company.com | | 68.116.107.206 | service | company.com | | 68.116.107.206 | service | company.com | | 68.116.107.206 | service | company.com | | 68.116.107.206 | service | company.com | | 68.116.107.206 | mhammond | cvs.pythonpros.com | | 68.116.107.206 | mhammond | cvs.pythonpros.com | | 68.116.107.206 | mhammond | cvs.pythonpros.com | | 68.116.107.206 | mhammond | cvs.pythonpros.com | | 68.116.107.206 | mhammond | cvs.pythonpros.com | | 68.116.107.206 | mhammond | cvs.pythonpros.com | | 68.116.107.206 | mhammond | cvs.pythonpros.com | | 68.116.107.206 | mhammond | cvs.pythonpros.com | | 68.116.107.206 | mhammond | cvs.pythonpros.com | | 68.116.107.206 | mhammond | cvs.pythonpros.com | | 68.116.107.206 | mhammond | cvs.pythonpros.com | | 68.116.107.206 | mhammond | cvs.pythonpros.com | | 68.116.107.206 | mhammond | cvs.pythonpros.com | | 68.116.107.206 | mhammond | cvs.pythonpros.com | | 68.116.107.206 | mhammond | cvs.pythonpros.com | | 68.116.107.206 | mhammond | cvs.pythonpros.com | | 68.116.107.206 | mhammond | cvs.pythonpros.com | | 68.116.107.206 | mhammond | cvs.pythonpros.com | | 68.116.107.206 | mhammond | cvs.pythonpros.com | | 68.116.107.206 | mhammond | cvs.pythonpros.com | | 68.116.107.206 | webmaster | havilandtelco.com | | 68.116.107.206 | webmaster | havilandtelco.com | | 68.116.107.206 | webmaster | havilandtelco.com | | 68.116.107.206 | webmaster | havilandtelco.com | | 68.116.107.206 | webmaster | havilandtelco.com | | 68.116.107.206 | webmaster | havilandtelco.com | | 68.116.107.206 | webmaster | havilandtelco.com | | 68.116.107.206 | webmaster | havilandtelco.com | | 68.116.107.206 | webmaster | havilandtelco.com | | 68.116.107.206 | webmaster | havilandtelco.com | | 68.116.107.206 | webmaster | havilandtelco.com | | 68.116.107.206 | webmaster | havilandtelco.com | | 68.116.107.206 | webmaster | havilandtelco.com | | 68.116.107.206 | webmaster | havilandtelco.com | | 68.116.107.206 | webmaster | havilandtelco.com | | 68.116.107.206 | webmaster | havilandtelco.com | | 68.116.107.206 | webmaster | havilandtelco.com | | 68.116.107.206 | webmaster | havilandtelco.com | | 68.116.107.206 | webmaster | havilandtelco.com | | 68.116.107.206 | webmaster | havilandtelco.com | | 68.116.107.206 | addressof | hotmail.com | | 68.116.107.206 | addressof | hotmail.com | | 68.116.107.206 | addressof | hotmail.com | | 68.116.107.206 | addressof | hotmail.com | | 68.116.107.206 | ef6d8.651bcdee71d | hotmail.com | | 68.116.107.206 | ef6d8.651bcdee71d | hotmail.com | | 68.116.107.206 | ef6d8.651bcdee71d | hotmail.com | | 68.116.107.206 | ef6d8.651bcdee71d | hotmail.com | | 68.116.107.206 | ef6d8.651bcdee71d | hotmail.com | | 68.116.107.206 | ef6d8.651bcdee71d | hotmail.com | | 68.116.107.206 | ef6d8.651bcdee71d | hotmail.com | | 68.116.107.206 | ef6d8.651bcdee71d | hotmail.com | | 68.116.107.206 | ef6d8.651bcdee71d | hotmail.com | | 68.116.107.206 | ef6d8.651bcdee71d | hotmail.com | | 68.116.107.206 | ef6d8.651bcdee71d | hotmail.com | | 68.116.107.206 | ef6d8.651bcdee71d | hotmail.com | | 68.116.107.206 | ef6d8.651bcdee71d | hotmail.com | | 68.116.107.206 | ef6d8.651bcdee71d | hotmail.com | | 68.116.107.206 | ef6d8.651bcdee71d | hotmail.com | | 68.116.107.206 | ef6d8.651bcdee71d | hotmail.com | | 68.116.107.206 | ef6d8.651bcdee71d | hotmail.com | | 68.116.107.206 | ef6d8.651bcdee71d | hotmail.com | | 68.116.107.206 | ef6d8.651bcdee71d | hotmail.com | | 68.116.107.206 | ef6d8.651bcdee71d | hotmail.com | | 68.116.107.206 | a666.35cddecb9f33 | incredimail.com | | 68.116.107.206 | a666.35cddecb9f33 | incredimail.com | | 68.116.107.206 | a666.35cddecb9f33 | incredimail.com | | 68.116.107.206 | a666.35cddecb9f33 | incredimail.com | | 68.116.107.206 | support | irislink.com | | 68.116.107.206 | support | irislink.com | | 68.116.107.206 | support | irislink.com | | 68.116.107.206 | support | irislink.com | | 68.116.107.206 | admin | let.rug.nl | | 68.116.107.206 | admin | let.rug.nl | | 68.116.107.206 | admin | let.rug.nl | | 68.116.107.206 | admin | let.rug.nl | | 68.116.107.206 | admin | let.rug.nl | | 68.116.107.206 | admin | let.rug.nl | | 68.116.107.206 | admin | let.rug.nl | | 68.116.107.206 | admin | let.rug.nl | | 68.116.107.206 | admin | let.rug.nl | | 68.116.107.206 | admin | let.rug.nl | | 68.116.107.206 | admin | let.rug.nl | | 68.116.107.206 | admin | let.rug.nl | | 68.116.107.206 | admin | let.rug.nl | | 68.116.107.206 | admin | let.rug.nl | | 68.116.107.206 | admin | let.rug.nl | | 68.116.107.206 | admin | let.rug.nl | | 68.116.107.206 | admin | let.rug.nl | | 68.116.107.206 | admin | let.rug.nl | | 68.116.107.206 | admin | let.rug.nl | | 68.116.107.206 | admin | let.rug.nl | | 68.116.107.206 | info | mediaplex.com | | 68.116.107.206 | info | mediaplex.com | | 68.116.107.206 | info | mediaplex.com | | 68.116.107.206 | info | mediaplex.com | | 68.116.107.206 | e-post | motive.com | | 68.116.107.206 | e-post | motive.com | | 68.116.107.206 | e-post | motive.com | | 68.116.107.206 | e-post | motive.com | | 68.116.107.206 | e-post | motive.com | | 68.116.107.206 | e-post | motive.com | | 68.116.107.206 | e-post | motive.com | | 68.116.107.206 | e-post | motive.com | | 68.116.107.206 | e-post | motive.com | | 68.116.107.206 | e-post | motive.com | | 68.116.107.206 | e-post | motive.com | | 68.116.107.206 | e-post | motive.com | | 68.116.107.206 | e-post | motive.com | | 68.116.107.206 | e-post | motive.com | | 68.116.107.206 | e-post | motive.com | | 68.116.107.206 | e-post | motive.com | | 68.116.107.206 | e-post | motive.com | | 68.116.107.206 | e-post | motive.com | | 68.116.107.206 | e-post | motive.com | | 68.116.107.206 | e-post | motive.com | | 68.116.107.206 | draheimcindy | msn.com | | 68.116.107.206 | draheimcindy | msn.com | | 68.116.107.206 | draheimcindy | msn.com | | 68.116.107.206 | draheimcindy | msn.com | | 68.116.107.206 | draheimcindy | msn.com | | 68.116.107.206 | draheimcindy | msn.com | | 68.116.107.206 | draheimcindy | msn.com | | 68.116.107.206 | draheimcindy | msn.com | | 68.116.107.206 | draheimcindy | msn.com | | 68.116.107.206 | draheimcindy | msn.com | | 68.116.107.206 | draheimcindy | msn.com | | 68.116.107.206 | draheimcindy | msn.com | | 68.116.107.206 | draheimcindy | msn.com | | 68.116.107.206 | draheimcindy | msn.com | | 68.116.107.206 | draheimcindy | msn.com | | 68.116.107.206 | draheimcindy | msn.com | | 68.116.107.206 | draheimcindy | msn.com | | 68.116.107.206 | draheimcindy | msn.com | | 68.116.107.206 | draheimcindy | msn.com | | 68.116.107.206 | draheimcindy | msn.com | | 68.116.107.206 | fcffbba.baeb8695fd9 | msn.com | | 68.116.107.206 | fcffbba.baeb8695fd9 | msn.com | | 68.116.107.206 | fcffbba.baeb8695fd9 | msn.com | | 68.116.107.206 | fcffbba.baeb8695fd9 | msn.com | | 68.116.107.206 | fcffbba.baeb8695fd9 | msn.com | | 68.116.107.206 | fcffbba.baeb8695fd9 | msn.com | | 68.116.107.206 | fcffbba.baeb8695fd9 | msn.com | | 68.116.107.206 | fcffbba.baeb8695fd9 | msn.com | | 68.116.107.206 | fcffbba.baeb8695fd9 | msn.com | | 68.116.107.206 | fcffbba.baeb8695fd9 | msn.com | | 68.116.107.206 | fcffbba.baeb8695fd9 | msn.com | | 68.116.107.206 | fcffbba.baeb8695fd9 | msn.com | | 68.116.107.206 | fcffbba.baeb8695fd9 | msn.com | | 68.116.107.206 | fcffbba.baeb8695fd9 | msn.com | | 68.116.107.206 | fcffbba.baeb8695fd9 | msn.com | | 68.116.107.206 | fcffbba.baeb8695fd9 | msn.com | | 68.116.107.206 | fcffbba.baeb8695fd9 | msn.com | | 68.116.107.206 | fcffbba.baeb8695fd9 | msn.com | | 68.116.107.206 | fcffbba.baeb8695fd9 | msn.com | | 68.116.107.206 | fcffbba.baeb8695fd9 | msn.com | | 68.116.107.206 | 3dadbc2ea4fc8bec | oochnblbm.com | | 68.116.107.206 | 3dadbc2ea4fc8bec | oochnblbm.com | | 68.116.107.206 | 3dadbc2ea4fc8bec | oochnblbm.com | | 68.116.107.206 | 3dadbc2ea4fc8bec | oochnblbm.com | | 68.116.107.206 | mailbox | regence.com | | 68.116.107.206 | mailbox | regence.com | | 68.116.107.206 | mailbox | regence.com | | 68.116.107.206 | mailbox | regence.com | | 68.116.107.206 | mailbox | regence.com | | 68.116.107.206 | mailbox | regence.com | | 68.116.107.206 | mailbox | regence.com | | 68.116.107.206 | mailbox | regence.com | | 68.116.107.206 | mailbox | regence.com | | 68.116.107.206 | mailbox | regence.com | | 68.116.107.206 | mailbox | regence.com | | 68.116.107.206 | mailbox | regence.com | | 68.116.107.206 | mailbox | regence.com | | 68.116.107.206 | mailbox | regence.com | | 68.116.107.206 | mailbox | regence.com | | 68.116.107.206 | mailbox | regence.com | | 68.116.107.206 | mailbox | regence.com | | 68.116.107.206 | mailbox | regence.com | | 68.116.107.206 | mailbox | regence.com | | 68.116.107.206 | mailbox | regence.com | | 68.116.107.206 | x-account | regence.com | | 68.116.107.206 | x-account | regence.com | | 68.116.107.206 | x-account | regence.com | | 68.116.107.206 | x-account | regence.com | | 68.116.107.206 | x-account | regence.com | | 68.116.107.206 | x-account | regence.com | | 68.116.107.206 | x-account | regence.com | | 68.116.107.206 | x-account | regence.com | | 68.116.107.206 | x-account | regence.com | | 68.116.107.206 | x-account | regence.com | | 68.116.107.206 | x-account | regence.com | | 68.116.107.206 | x-account | regence.com | | 68.116.107.206 | x-account | regence.com | | 68.116.107.206 | x-account | regence.com | | 68.116.107.206 | x-account | regence.com | | 68.116.107.206 | x-account | regence.com | | 68.116.107.206 | x-account | regence.com | | 68.116.107.206 | x-account | regence.com | | 68.116.107.206 | x-account | regence.com | | 68.116.107.206 | x-account | regence.com | | 68.116.107.206 | f3c7e9ff6d91.4fe2 | rogers.com | | 68.116.107.206 | f3c7e9ff6d91.4fe2 | rogers.com | | 68.116.107.206 | f3c7e9ff6d91.4fe2 | rogers.com | | 68.116.107.206 | f3c7e9ff6d91.4fe2 | rogers.com | | 68.116.107.206 | service | sun.com | | 68.116.107.206 | service | sun.com | | 68.116.107.206 | service | sun.com | | 68.116.107.206 | service | sun.com | | 68.116.107.206 | service | sun.com | | 68.116.107.206 | service | sun.com | | 68.116.107.206 | service | sun.com | | 68.116.107.206 | service | sun.com | | 68.116.107.206 | service | sun.com | | 68.116.107.206 | service | sun.com | | 68.116.107.206 | service | sun.com | | 68.116.107.206 | service | sun.com | | 68.116.107.206 | service | sun.com | | 68.116.107.206 | service | sun.com | | 68.116.107.206 | service | sun.com | | 68.116.107.206 | service | sun.com | | 68.116.107.206 | service | sun.com | | 68.116.107.206 | service | sun.com | | 68.116.107.206 | service | sun.com | | 68.116.107.206 | service | sun.com | | 68.116.107.206 | cf5feabbb.358d7dfdf2 | urth.org | | 68.116.107.206 | cf5feabbb.358d7dfdf2 | urth.org | | 68.116.107.206 | cf5feabbb.358d7dfdf2 | urth.org | | 68.116.107.206 | cf5feabbb.358d7dfdf2 | urth.org | | 68.116.107.206 | webteam | weeklyreader.com | | 68.116.107.206 | webteam | weeklyreader.com | | 68.116.107.206 | webteam | weeklyreader.com | | 68.116.107.206 | webteam | weeklyreader.com | | 68.116.107.206 | bullridin4ever | yahoo.com | | 68.116.107.206 | bullridin4ever | yahoo.com | | 68.116.107.206 | bullridin4ever | yahoo.com | | 68.116.107.206 | bullridin4ever | yahoo.com | | 68.116.107.206 | polloa | yahoo.com | | 68.116.107.206 | polloa | yahoo.com | | 68.116.107.206 | polloa | yahoo.com | | 68.116.107.206 | polloa | yahoo.com | | 68.116.107.206 | polloa | yahoo.com | | 68.116.107.206 | polloa | yahoo.com | | 68.116.107.206 | polloa | yahoo.com | | 68.116.107.206 | polloa | yahoo.com | | 68.116.107.206 | polloa | yahoo.com | | 68.116.107.206 | polloa | yahoo.com | | 68.116.107.206 | polloa | yahoo.com | | 68.116.107.206 | polloa | yahoo.com | | 68.116.107.206 | polloa | yahoo.com | | 68.116.107.206 | polloa | yahoo.com | | 68.116.107.206 | polloa | yahoo.com | | 68.116.107.206 | polloa | yahoo.com | | 68.116.107.206 | polloa | yahoo.com | | 68.116.107.206 | polloa | yahoo.com | | 68.116.107.206 | polloa | yahoo.com | | 68.116.107.206 | polloa | yahoo.com | +----------------+----------------------+---------------------+ 300 rows in set (0.00 sec) mysql> ...and I have quite a number of them... --=20 Michel Bouissou <mi...@bo...> OpenPGP ID 0xDDE8AC6E Appel de 200 Informaticiens pour le NON au Trait=E9 Constitutionnel Europ=E9en: http://www.200informaticiens.ras.eu.org |
|
From: Klaus A. S. <kse...@gm...> - 2005-05-17 08:04:57
|
On 17/05/05, Michel Bouissou <mi...@bo...> wrote: > I believe that problems are very unlilely to happen, but [...] Yeah, maybe you're right. At least I hope so. :-) --=20 Klaus Alexander Seistrup Magnetic Ink =B7 Copenhagen =B7 Denmark http://magnetic-ink.dk/ |
|
From: Lionel B. <lio...@bo...> - 2005-05-17 07:54:33
|
Klaus Alexander Seistrup wrote the following on 17.05.2005 09:29 : >On 17/05/05, Michel Bouissou <mi...@bo...> wrote: > > > >>>Then a culprit will be able to prevent legitimate email originating from >>>the same IP address, won't he? >>> >>> >>This won't happen if the considered IP only hosts one machine which is a >>"normal" mailserver which retries all the messages that it has in queue. >> >>This could possibly happen if this IP has a NATted LAN behind it, hosting >>both a legitimate mailserver and spam/virus sources, in which case it is >>this network's admin job to make sure that his network doesn't pollute the >>whole earth with junk. Even in this situation, already known "good" >>addresses that have already made it to from_awl or domain_awl wouldn't be >>blocked, only new connections. >> >> > >It could happen if the Good Sender and the Evil Sender are both using >the mail gateway of the same ISP. And if Good Sender is not already >in *_awl his mail could be blocked by Evil Sender's DoS'ing. > >I would like to be able to disable the feature in SQLgrey's config file. > > > 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? Lionel Lionel. |
|
From: Michel B. <mi...@bo...> - 2005-05-17 07:51:20
|
Klaus Alexander Seistrup a =E9crit : > On 17/05/05, Michel Bouissou <mi...@bo...> wrote: > >>> Then a culprit will be able to prevent legitimate email originating >>> from the same IP address, won't he? >> >> This won't happen if the considered IP only hosts one machine which is >> a "normal" mailserver which retries all the messages that it has in >> queue. >> >> This could possibly happen if this IP has a NATted LAN behind it, >> hosting both a legitimate mailserver and spam/virus sources, in which >> case it is this network's admin job to make sure that his network >> doesn't pollute the whole earth with junk. Even in this situation, >> already known "good" addresses that have already made it to from_awl o= r >> domain_awl wouldn't be blocked, only new connections. > > It could happen if the Good Sender and the Evil Sender are both using t= he > mail gateway of the same ISP. And if Good Sender is not already in *_a= wl > his mail could be blocked by Evil Sender's DoS'ing. > > I would like to be able to disable the feature in SQLgrey's config file= . I don't think so. Most of the times, the "legitimate" domains often comin= g from this ISP's mailserver will have reached the domain_awl long ago, so no messages coming from the couple IP/domain won't be greylisted anymore. If the "Evil Sender" abuses the ISP's mail gateway during a certain perio= d (and viruses and spambots usually don't work this way, they don't send thru ISP mailservers), then it may only cause a delay for other "unknow" messages coming from this ISP's mailserver (and not using the ISP main "from" domains), for the duration of the abuse. Anyway, as the ISP's mailserver is supposed to retry normally, the messages sent thru it, good or evil, will make it thru, only slower, whic= h has the advantage of leaving time for other anti-spam tools (blacklists, DSPAM, Razor, DCC...) to learn this spam and be able to block it with better chances. I believe that problems are very unlilely to happen, but anyway I agree that the feature should be optional (n=3D0: don't use). --=20 Michel Bouissou <mi...@bo...> OpenPGP ID 0xDDE8AC6E Appel de 200 Informaticiens pour le NON au Trait=E9 Constitutionnel Europ=E9en: http://www.200informaticiens.ras.eu.org |
|
From: Klaus A. S. <kse...@gm...> - 2005-05-17 07:29:14
|
On 17/05/05, Michel Bouissou <mi...@bo...> wrote: >> Then a culprit will be able to prevent legitimate email originating from >> the same IP address, won't he? >=20 > This won't happen if the considered IP only hosts one machine which is a > "normal" mailserver which retries all the messages that it has in queue. >=20 > This could possibly happen if this IP has a NATted LAN behind it, hosting > both a legitimate mailserver and spam/virus sources, in which case it is > this network's admin job to make sure that his network doesn't pollute th= e > whole earth with junk. Even in this situation, already known "good" > addresses that have already made it to from_awl or domain_awl wouldn't be > blocked, only new connections. It could happen if the Good Sender and the Evil Sender are both using the mail gateway of the same ISP. And if Good Sender is not already in *_awl his mail could be blocked by Evil Sender's DoS'ing. I would like to be able to disable the feature in SQLgrey's config file. --=20 Klaus Alexander Seistrup Magnetic Ink =B7 Copenhagen =B7 Denmark http://magnetic-ink.dk/ |
|
From: Michel B. <mi...@bo...> - 2005-05-17 07:15:58
|
Klaus Alexander Seistrup a =E9crit : > On 17/05/05, Michel Bouissou <mi...@bo...> wrote: > >> 1/ When a new entry should be added to the connect table; >> >> 2/ BUT there are already more than "n" (a configurable number, default >> 10 ?) entries in connect from the same SRC (messages that were not yet >> correctly resent); >> >> 3/ THEN do NOT add the new entry to connect, but instead reject with >> "450 Incoming rate too high, try again later". > > Then a culprit will be able to prevent legitimate email originating fro= m > the same IP address, won't he? This won't happen if the considered IP only hosts one machine which is a "normal" mailserver which retries all the messages that it has in queue. This could possibly happen if this IP has a NATted LAN behind it, hosting both a legitimate mailserver and spam/virus sources, in which case it is this network's admin job to make sure that his network doesn't pollute th= e whole earth with junk. Even in this situation, already known "good" addresses that have already made it to from_awl or domain_awl wouldn't be blocked, only new connections. I believe the idea is good ;-) and easy to implement (doesn't need supplementary tables, only one more SELECT count(*)), but as the threshol= d should be controlled by a user-settable parameter, the feature should be optional as well (parameter =3D0 ?). Cheers. --=20 Michel Bouissou <mi...@bo...> OpenPGP ID 0xDDE8AC6E Appel de 200 Informaticiens pour le NON au Trait=E9 Constitutionnel Europ=E9en: http://www.200informaticiens.ras.eu.org |
|
From: Klaus A. S. <kse...@gm...> - 2005-05-17 06:15:37
|
On 17/05/05, Michel Bouissou <mi...@bo...> wrote: > 1/ When a new entry should be added to the connect table; >=20 > 2/ BUT there are already more than "n" (a configurable number, default 10= ?) > entries in connect from the same SRC (messages that were not yet correctl= y > resent); >=20 > 3/ THEN do NOT add the new entry to connect, but instead reject with "450 > Incoming rate too high, try again later". Then a culprit will be able to prevent legitimate email originating from the same IP address, won't he? It's like locking your colleague's login account by entering a fake password three times. --=20 Klaus Alexander Seistrup Magnetic Ink =B7 Copenhagen =B7 Denmark http://magnetic-ink.dk/ |
|
From: Michel B. <mi...@bo...> - 2005-05-17 05:49:08
|
Hi there, I've seen these last days a growing number of spam attacks that use =20 dictionnaries or a high number of random addresses. This results in the connect table building several dozens of entries from= the=20 same IP address, with a lot of different RCPTS, and also different=20 sender_name and sender_domain (even though there are generally more recip= ient=20 addresses than senders addresses). This behaviour is very significative of spambots, and I was thinking that= a=20 feature such as the following would be helpful in avoiding polluting the=20 connect table: 1/ When a new entry should be added to the connect table; 2/ BUT there are already more than "n" (a configurable number, default 10= ?)=20 entries in connect from the same SRC (messages that were not yet correctl= y=20 resent); 3/ THEN do NOT add the new entry to connect, but instead reject with "450= =20 Incoming rate too high, try again later". With this, new messages will be accepted from this source only when messa= ges=20 already waiting to be re-presented have been ; if they are not, no new en= try=20 will be accepted from this source, and it will not uselessly pollute the=20 connect table. Such a system would also probabbly minimize the risk of seeing random att= acks=20 succeed in the end. Comments ? --=20 Michel Bouissou <mi...@bo...> OpenPGP ID 0xDDE8AC6E Appel de 200 Informaticiens pour le NON au Trait=E9 Constitutionnel Europ=E9en: http://www.200informaticiens.ras.eu.org |
|
From: Lionel B. <lio...@bo...> - 2005-05-14 18:13:00
|
Michel Bouissou wrote the following on 14.05.2005 17:20 : ># 14/05/2005 ># smtp.mandriva.org[212.85.150.170] >smtp.mandriva.org ># Comment: Legit Mandriva (previously MandrakeSoft) Newsletter server ># Reason: Does not retry > > Thanks, the repository is updated and my tree is in sync. Lionel |
18 messages has been excluded from this view by a project administrator.
