Re: Deceiving phishing
I was considering, instead of plainly dropping the phishing emails, why not deceiving it: having automatic replys with invalid informations. I guess that people who launch phishing campaings get few answers, but the answers they get are correct, the username and password match. What would happen if they gey thousands of answers that are mostly incorrect? They would have to waste time and resources to check every answer. Phishing campaigns don't usually expect a reply, they want you to fill in your data into a web form on either a dedicated or exploted web site. By reply I don't mean mail reply, but automatically filling their web form with garbage. Bests, Olivier
Re: Deceiving phishing
On 02/07/2014 09:03 AM, Olivier Nicole wrote: I was considering, instead of plainly dropping the phishing emails, why not deceiving it: having automatic replys with invalid informations. I guess that people who launch phishing campaings get few answers, but the answers they get are correct, the username and password match. What would happen if they gey thousands of answers that are mostly incorrect? They would have to waste time and resources to check every answer. Phishing campaigns don't usually expect a reply, they want you to fill in your data into a web form on either a dedicated or exploted web site. By reply I don't mean mail reply, but automatically filling their web form with garbage. Don't underestimate the talent behind phishes. Although their msgs sometimes are so badly translated between languages they've become fun to read, the backend remains effective. Enough ppl still fall for them. They can easily discern from garbage and usefull data,programatically, and in the worst of cases, there's LOTS of cheap Cloud Based Manpower On Demand to do it for them.
Re: regexp for SMTP AUTH
header MY_AUTH ALL =~ /\(authenticated bits=\d+\)\s+by\s+myserver.mydomain.at/ On 31.01.14 16:58, Rainer Fügenstein wrote: thanks. looks plausible, but doesn't work, unfortunately. I figured out that rules matching the first line work, but rules for lines 2+ never match, regardless of \n \s etc. On Thu, 6 Feb 2014, Matus UHLAR - fantomas wrote: isn't this the first Received: header? spamd may not receive it when MTA first transfers message to SA and THEN adds the Received: header... e.g. milter behaves like this On 06.02.14 13:52, David B Funk wrote: Any worthwhile milter for SA needs to syntesize a Received: header to mimic what the MTA will add to the processed message. Problem can be with the accuracy of that syntesized header. If the milter author didn't know to check the auth status of the message s/he may not have added a representation of it to the header passed on to SA thus SA had no way to know that the message was authed. (seem to remember this exact issue with an early incarnation of 'spamass-milter' ). This was the point. If the line that should be matched with the rule is the first one, AND the check is done before MTA adds Received: line (which is case when the milter is used), this is an issue of the intermediate program that feeds mail to spamassassin. Now, Rainer, can you confirm this is the case? -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Support bacteria - they're the only culture some people have.
Re: Who wants to trade data?
On 2014-02-06 23:41, Marc Perkel wrote: I have 700,000 IP addresses of hackers trying to send email using stolen authentication. Anyone interested? http://ipadmin.junkemailfilter.com/auth-hack.txt q: how many is listed in spamhaus pbl ? q: is dnswl filtered out ? or is the list just auth fooled users ? if there dns service is unstable how can you verify its not stolen ? q: would you provide the list for xtables_addons geoip in csv formated list ? this could then be used to create A0 country codes or another that is not used in geoip the last question is here since it would be lowmem and not hard to do :=)
Re: Who wants to trade data?
On 2014-02-07 01:33, Noel Butler wrote: else we'd have seen a url in one of his posts advertising it, therefore can be considered UCE agree if its free to download its not spam, i just think its the grey zone here
Re: Who wants to trade data?
On Feb 7, 2014, at 6:08 AM, Benny Pedersen m...@junc.eu wrote: On 2014-02-07 01:33, Noel Butler wrote: else we'd have seen a url in one of his posts advertising it, therefore can be considered UCE agree if its free to download its not spam, i just think its the grey zone here Sorry, no. The cost of a payload isn’t relevant to the determination is something is spam. Spam is unsolicited and (generally) bulk. I am offered ‘free’ subscriptions to things all the time, by spam. That said, i think someone offering anti-spam data to an anti-spam list is *collegial*, not spam, and the fact that it is free is even more collegial.
Re: New expensive Regexps
Am 07.02.2014 07:09, schrieb Axb: On 02/07/2014 03:04 AM, Kevin A. McGrail wrote: On 2/6/2014 8:32 PM, Dave Warren wrote: On 2014-02-06 17:17, John Hardin wrote: On Thu, 6 Feb 2014, Kevin A. McGrail wrote: I've discussed it with Alex a bit but one of my next ideas for the Rules QA process is the following: - we measure and report on metrics for the rules that are promoted such as rank (existing), computational expense, time spent on rule. I assume meta rules would combine the expense of their components? Sounds interesting! How about if one or more components were called more by more than one meta-rule? It's perhaps not entirely fair to divide it evenly, since that might imply that removing the metarule would kill off that CPU usage. Without triple checking the code, my 99.9% belief is Rules are cached. Calling them multiple times does not trigger a re-check. duplicate rules only get loaded once, it only costs time/cpu cycles so the fewer duplicates we have the faster we start a spamd or load rules when running spamasassin. see begimning of output when during spamassassin --lint -D rules Hi list, I hope I triggered a constructive and useful discussion here. In between I realized my data was skewed and I wanted to apologize for that. The peak in load happened when I rolled out the rule-set which was running fine on one machine to the whole cluster of 4. I immediately blamed it on the upstream changes (sa-update) which I recklessly incorporated last minute. It turns out that I would have run into the same problems with the thoroughly tested ruleset without the updates. The reason is that the load-balancing used in this scenario is dynamic and not round-robin as I assumed, so the other servers took the load of the one being tested :( That being said, it would obviously be a great improvement if I could assess the impact of a specific ruleset before I start using it on live data (~40M/d). -- Torge Husfeldt Senior Anti-Abuse Engineer Zentrales Abuse-Department (11 GMX Web.de) 11 Internet AG | Brauerstraße 50 | 76135 Karlsruhe | Germany Phone: +49 721 91374-4795 | Fax: +49 721 91374-2982 E-Mail: torge.husfe...@1und1.de | Web: www.1und1.de Hauptsitz Montabaur, Amtsgericht Montabaur, HRB 6484 Vorstand: Ralph Dommermuth, Frank Einhellinger, Robert Hoffmann, Andreas Hofmann, Markus Huhn, Hans-Henning Kettler, Uwe Lamnek, Jan Oetjen, Christian Würst Aufsichtsratsvorsitzender: Michael Scheeren Member of United Internet Diese E-Mail kann vertrauliche und/oder gesetzlich geschützte Informationen enthalten. Wenn Sie nicht der bestimmungsgemäße Adressat sind oder diese E-Mail irrtümlich erhalten haben, unterrichten Sie bitte den Absender und vernichten Sie diese E-Mail. Anderen als dem bestimmungsgemäßen Adressaten ist untersagt, diese E-Mail zu speichern, weiterzuleiten oder ihren Inhalt auf welche Weise auch immer zu verwenden. This E-Mail may contain confidential and/or privileged information. If you are not the intended recipient of this E-Mail, you are hereby notified that saving, distribution or use of the content of this E-Mail in any way is prohibited. If you have received this E-Mail in error, please notify the sender and delete the E-Mail.
Re[2]: regexp for SMTP AUTH
MUf This was the point. If the line that should be matched with the rule is the MUf first one, AND the check is done before MTA adds Received: line (which is MUf case when the milter is used), this is an issue of the intermediate program MUf that feeds mail to spamassassin. MUf Now, Rainer, can you confirm this is the case? what I can tell is the following: - spamass-milter 0.3.1 is in use. this seems to be the most current version. - if I understand this conversation correctly: the line Received: from [192.168.5.238] (xyz.example.com [90.217.201.80]) has already been passed to spamassassin (or been virtually created when the regex rules are applied, but the following lines (authenticated bits=0) by myserver.mydomain.at (8.13.8/8.13.8) with ESMTP id s0VEsVIv028654 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) haven't. does this make sense? is this how SA is implemented? I'll enable spamass-milter debug output and see if I can make any sense of it. cu --- NOT sent from an iPhone
