Re: [milter-greylist] new spam engines
2006-04-07 by Matt Kettler
... Duh.. this is exactly what SPF is intended to do.. Force spammers to create their own domains instead of abusing existing ones. Anyone who thinks SPF is
Messages
Browse messages
Page 104 of 144 · 7199 messages matched
Re: [milter-greylist] new spam engines
2006-04-07 by Matthias Scheler
... SPF is quickly becoming worthless because spammers register new domains, create fine looking SPF records for their spam bot networks and start delivering
Re: [milter-greylist] new spam engines
2006-04-07 by Michael Menge
... Hi, I think SPF (see www.openspf.org) may be a googd idea to use. Whitelist if SPF returns Pass , reject if SPF returns Fail and in the other cases
Retain tuples vs auto-whitelisting?
2006-04-06 by Sysadmin
Tere. I m confused, what s the difference between tuples vs auto-whitelist, rihgt now I have set: # How long will the greylist database retain tuples. timeout
Re: [milter-greylist] "Dark-grey"listing dynamic IP address
2006-04-06 by Matt Kettler
... And you can easily match the lack of RDNS with a milter-greylist ACL, provided you use extendedregex: acl greylist domain
Re: [milter-greylist] "Dark-grey"listing dynamic IP addresses
2006-04-06 by Bill Levering
... oh, this sounds like what Verizon does. It s amazing what traffic I get when I had verizon blocked, then tried to send them an email. I swear, I must of
Re[2]: [milter-greylist] "Dark-grey"listing dynamic IP address
2006-04-06 by Denis Solovyov
... G If they don t use this scheme, they should certainly use another one (more G or less recognizable), as I can t imagine them inventing a nice name for
Re: [milter-greylist] "Dark-grey"listing dynamic IP address
2006-04-06 by Gingko
... From: Kai Schaetzl To: Sent: Thursday, April 06, 2006 2:31 AM Subject: Re: [milter-greylist]
Re: [milter-greylist] "Dark-grey"listing dynamic IP addresses
2006-04-06 by Gingko
... From: To: Sent: Wednesday, April 05, 2006 11:58 PM Subject: [milter-greylist] Dark-grey listing
Re: "Dark-grey"listing dynamic IP address
2006-04-06 by bmj1227
... Instead of trying to parse all the formats used in reverse DNS yourself, how about querying a blackhole list. There are several that specificly list dialup
Re: [milter-greylist] "Dark-grey"listing dynamic IP address
2006-04-06 by Kai Schaetzl
... Very shortly you will see that there is *lots* of dynamic IP space which will not fit that scheme at all. Or they don t have PTR records at all. Also,
Re: [milter-greylist] "Dark-grey"listing dynamic IP address
2006-04-06 by Bill Levering
That is really cool! I d be interested in combining the extendedregex with variable greylisting times. say... 1 hr for some hosts that are more likely to be
Re: [milter-greylist] "Dark-grey"listing dynamic IP address
2006-04-05 by Matt Kettler
... I use a similar tactic, but with the twist that I ONLY greylist dynamic hosts, and whitelist everything else. However, it would be nice to deep grey some
[milter-greylist] "Dark-grey"listing dynamic IP address
2006-04-05 by manu@netbsd.org
... I just realized that the reverse DNS is something out of control of the botnet spammer. Filtering on reverse DNS name with three 0-255 numbers sounds
"Dark-grey"listing dynamic IP address
2006-04-05 by Gingko
Hello everybody, I would like to make another suggestion ... I know that most spammers use now relays on dynamic IP addresses. I know also that it is difficult
Re: [milter-greylist] [RFC] distributed spam traps, improved
2006-04-05 by Kai Schaetzl
... Ahm, one more aspect on this. There are spammers which use zombies and what-not to flush out their crap. But there are also spammers that use normal SMTP
Re: [milter-greylist] [RFC] distributed spam traps, improved
2006-04-04 by Kai Schaetzl
... yes, that was to be expected. ... Isn t that very similar to existing blacklists, either RBLs for sending hosts, URIBLs for advertised URLs in emails or
Re: [milter-greylist] new spam engines
2006-04-04 by Kai Schaetzl
... And on top of this it might be interesting to randomize this a bit. F.i. if your base timeout is 10min you may actually choose a time from 5 - 15min for
Re: [RFC] distributed spam traps, improved
2006-04-04 by Alan Clifford
On Tue, 4 Apr 2006, Emmanuel Dreyfus wrote: ED ED The spam traps would be e-mail addresses released in web pages. The ED DSTnet would work by exchanging
[RFC] distributed spam traps, improved
2006-04-04 by Emmanuel Dreyfus
Hello I thought about the next anti spam tool and I d like some feedback about my ideas. Please try to find a weak point. If there is none, we have our
RE: [milter-greylist] Distributed spam honeypots again?
2006-04-04 by fredrik.pettai@vattenfall.com
... to ... should ... Spamcop, (a DNSBL) uses the same idea with honeypots (at least, they did use em...). They added IPs of MTAs to there blacklist
Distributed spam honeypots again?
2006-04-04 by manu@netbsd.org
... We have a old counter measure that we now have to deploy: distributed honeypots. That will catch botnet members between resends. I wrote some software to
RE: [milter-greylist] new spam engines
2006-04-04 by attila.bruncsak@itu.int
... Yes, it is 5 minutes and some seconds for me too. I had on one minute greylist time, increased now it to 6 minutes. (by the way, would be nice to specify
Re: [milter-greylist] new spam engines
2006-04-04 by Michael Menge
... Many normal MTA dont read the string with the delay time and retry after less then one minute. I think ther is a high risk that you blacklist normal MTA.
Re: [milter-greylist] new spam engines
2006-04-04 by Emmanuel Dreyfus
... Yes, I will try this if I see just one retry after my new greylisting delay (30 mn). If the spam engine reads that message, this make new counter measures
Re: [milter-greylist] new spam engines
2006-04-04 by Oliver Fromme
... A quick and simple fix would be not to include the information in the SMTP reply, don t you think? For example, just say please come back later .
RE: [milter-greylist] new spam engines
2006-04-04 by fredrik.pettai@vattenfall.com
... it s ... one ... 00:05:00 . ... You may also try removing the polite and helpful ...in 00:05:00 and just say Greylisting in progress, please come back
new spam engines
2006-04-04 by Emmanuel Dreyfus
Hi Recently I saw a new kind of spam. The messages contain a text part with nonsense that are obviosuly here to ruin bayesian filtering. The words are non-spam
Re: [milter-greylist] hash table acceleration breaks lazyaw
2006-03-30 by Ranko Zivojnovic
... Some tests I ve done show that the current hash function does pretty good job distributing records across buckets. Originally, before I have published any
Re: [milter-greylist] hash table acceleration breaks lazyaw
2006-03-30 by Ranko Zivojnovic
... Would that be really necessary? `s6_addr used by the equation is defined by RFC and having redundant checks and #if s would IMHO only clutter the code. R.
RE: [milter-greylist] Problem with AF_INET recognition on Tru64
2006-03-30 by attila.bruncsak@itu.int
... Surely my patch does not solve your problem, but at least gives more precise error message so it is worth to apply to the source code. I found this small
Re: [milter-greylist] hash table acceleration breaks lazyaw
2006-03-29 by manu@netbsd.org
... We already have a configure test to check if we can have __RCSID twice in a .c file :-) -- Emmanuel Dreyfus Un bouquin en français sur BSD:
RE: [milter-greylist] Problem with AF_INET recognition on Tru64
2006-03-29 by Daniel Clar
I ve looked inside the source code and I ve found that the problem was coming from the dump_dirty variable initialized to 0. So dump_perform was not executed,
RE: [milter-greylist] Problem with AF_INET recognition on Tru64
2006-03-29 by attila.bruncsak@itu.int
... The attached patch removes some code asymmetry in the IPv4 - IPv6 relation. There is no functionality changes. The most important part that it may produce
Re: [milter-greylist] Compile problem on CentOS 4.2
2006-03-29 by Kai Schaetzl
... Not sure what exactly euid is? uid? effective uid? After all the explanations I think it is simply the init script which is wrong. It s wrong to put the
Re: [milter-greylist] Re: Compile problem on CentOS 4.2
2006-03-29 by Emmanuel Dreyfus
... Ok, that explains everything. Maybe we should just check if euid == 0 and skip any setuid/setgid/initgroups if it s not the case? -- Emmanuel Dreyfus
Re: [milter-greylist] Re: Compile problem on CentOS 4.2
2006-03-29 by Enrico Scholz
... No; daemon --user=smmsp milter-greylist ... executes something like ... Therefore, milter-greylist will be started as non-privileged user smmsp who
Re: [milter-greylist] Re: Compile problem on CentOS 4.2
2006-03-29 by Oliver Fromme
... No, it isn t. The init.d script starts milter-greylist as root (using the daemon tool). Then milter-greylist itself switches its user ID to smmsp as
Re: [milter-greylist] hash table acceleration breaks lazyaw
2006-03-29 by Hajimu UMEMOTO
Hi, ... manu Make a configure check for s6_addr32, and define it if it does not manu exist? I think it is overkill. :-) Sincerely, -- Hajimu UMEMOTO @
Re: [milter-greylist] Compile problem on CentOS 4.2
2006-03-29 by manu@netbsd.org
... Well it s not nescessary, since it s ifdef ed. You can tweak config.h to remove HAVE_INITGROUPS. For a right fix, I m tempted to turn it into a warking,
Re: [milter-greylist] hash table acceleration breaks lazyaw
2006-03-29 by manu@netbsd.org
... Make a configure check for s6_addr32, and define it if it does not exist? -- Emmanuel Dreyfus Le cahier de l admin BSD 2eme ed. est dans toutes les bonnes
Re: [milter-greylist] hash table acceleration breaks lazyaw
2006-03-29 by Hajimu UMEMOTO
Hi, ... ranko True - the mistake was in the typecast, but I still want to use 32 bit ranko values in the hash calculus in order to allow for the large hash
Re: [milter-greylist] Compile problem on CentOS 4.2
2006-03-29 by Kai Schaetzl
... Ah, uh, oh, great! I didn t ever consider this is in milter-greylist code. I thought that is a general Linux message and something must be misconfigured.
Re: [milter-greylist] hash table acceleration breaks lazyaw
2006-03-28 by Matthias Scheler
... Run a standard byte string hash function over the full IPv6 address. Your assumption that the last 32bit of an IPv6 address provide a good hash key is not
Re: [milter-greylist] Re: Compile problem on CentOS 4.2
2006-03-28 by manu@netbsd.org
... This is the offending code (milter-greylist.c): #ifdef HAVE_INITGROUPS if (initgroups(conf.c_user, pw- pw_gid) != 0) { syslog(LOG_ERR, %s: cannot change
Re: [milter-greylist] hash table acceleration breaks lazyaw
2006-03-28 by Ranko Zivojnovic
... Hopefully not too much ... ... True - the mistake was in the typecast, but I still want to use 32 bit values in the hash calculus in order to allow for the
Re: Compile problem on CentOS 4.2
2006-03-28 by Kai Schaetzl
... I wanted to revisit this problem today and fix it. milter-greylist had been running as root for the last days. At least that is what I thought. from
Re: [milter-greylist] Problem with AF_INET recognition on Tru64
2006-03-28 by Kai Schaetzl
... I can confirm this now. As long as incoming messages are whitelisted by greylist.conf or SPF, there s no need to write to greylist.db and it doesn t exist.
Re: [milter-greylist] hash table acceleration breaks lazyaw
2006-03-28 by Ranko Zivojnovic
... Well - then I m really not sure where the problem is - anybody else with the same problem out there? Maybe a patch in a different format would help? Try
Re: [milter-greylist] hash table acceleration breaks lazyaw
2006-03-28 by Hajimu UMEMOTO
Hi, ... ranko ! #define BUCKET_HASH_V6(sa, from, rcpt, bucket_count) ranko ! (((((uint32_t)(SADDR6(sa)- s6_addr)[0] & ranko !