Re: problems with TVD_SPACE_RATIO
Karsten Bräckelmann a écrit : On Tue, 2009-05-26 at 22:12 +0200, mouss wrote: Karsten Bräckelmann a écrit : Bug 6119 has been opened already. Please attach additional samples there, rather than opening a new bug for every sample. Thanks! https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6119 I've attached a few. If more is needed, just ask... No more auto-generated content, please. :) Real, human written samples on the other hand... 4454 and 4455 are human written. (if people who spend a lot of time in front of a terminal are still considered human ;) and 4454 is a one line message, but the signature causes the hit. See comment 7. guenther
Re: problems with TVD_SPACE_RATIO
Karsten Bräckelmann a écrit : On Wed, 2009-05-27 at 09:21 +0200, Michael Monnerie wrote: On Mittwoch 27 Mai 2009 mouss wrote: and 4454 is a one line message, but the signature causes the hit. The fact that mailing-list footer is forced onto the message with no newline causes it. And the second hardly counts as human generated. ;) true, the guy replied without adding any personal comments. but these are things that happen: - I have a problem with foobar - what does /sbin/joe show - $joe_output now, the question is: what should really be caught? If I can suggest anything, I would like to propose the following: when a rule is designed: - document what it should catch - give examples of things it catches and things it shouldn't catch (so that if someone modifies the rule, he has some hints on what he can do) of course, if there's work to do, count me in (well, subject to my availability...). And my messages are just one-liners without .sig that should never hit this rule at all. Checked those samples from both of you. Lots more analysis of this eval function added to the bug report. See comment 12. Smells kinda fishy to me, and probably broke at some point since its original introduction. :/ I don't have other examples in original format, but just a few days ago got a FP report where this rule hit a normal, german, human-typed mail. I'll restore the original score now to see if I get more reports. Hmm, I'd love to see that one. Any *human-typed* mail featuring a real sentence should not trigger this. Unless it's followed directly by a huge machine-generated paste or something, without an empty line... I'm not sure. but I'll have to dig in my mail before I can see anything real.
Re: RBL triggered?
Charles Gregory a écrit : Hello! Quick question: Does Spamassassin's RCVD tests also check headers labelled X-Originating-IP? yes. In particular, I received the below message from hotmail with hits on RCVD_IN_BL_SPAMCOP_NET and RCVD_IN_SORBS_WEB. Neither of the hotmail IP's is found in *any* RBL listed at mailabuse.org's multi-check. The X-originating-IP shows up in the sorbs RBL but not the spamcop one. Is this a case where hotmail got a FP corrected in 12 hours? Or is there something else going on to trigger these tests? 66.110.6.119 is listed in CBL, SORBS, BRBL (Barracuda), ... so this IP is owned or whatever, and in any case, it sends spam. thus any mail that was sent from or via this IP is suspicious and deserves some points. Return-Path: __...@sympatico.ca Received: by barton.hwcn.org (Postfix, from userid 110) id A4B4EF3EF8; Tue, 26 May 2009 17:04:28 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on barton.hwcn.org X-Spam-Level: * X-Spam-Status: No, hits=5.6 required=10.0 autolearn=disabled tests=HTML_MESSAGE=0.001,RCVD_IN_BL_SPAMCOP_NET=4.5,RCVD_IN_SORBS_WEB=1.117 Received: from col0-omc2-s17.col0.hotmail.com (col0-omc2-s17.col0.hotmail.com [65.55.34.91]) by barton.hwcn.org with SMTP id 2nv8k5uzsjhw4rtthhp9guzsha; for off...@hwcn.org; Tue, 26 May 2009 17:04:21 -0400 (EDT) (envelope-from culs...@sympatico.ca) Received-SPF: Pass; receiver=barton.hwcn.org; client-ip=65.55.34.91; envelope-from=culs...@sympatico.ca; helo=col0-omc2-s17.col0.hotmail.com; mechanism=include:hotmail.com (include:spf-a.hotmail.com (ip4:65.52.0.0/14 - pass) - pass) X-Avenger: version=0.7.9; receiver=barton.hwcn.org; client-ip=65.55.34.91; client-port=25067; syn-fingerprint=65535:112:1:48:M1460,N,N,S Windows 2000 SP4, XP SP1; data-bytes=0; network-path=208.65.246.17 208.72.120.5 74.205.221.2 38.104.159.125 38.20.41.73 154.54.28.33 154.54.27.165 154.54.7.30 207.46.33.29 154.54.27.206 207.46.33.29 207.46.43.153 207.46.43.153 10.22.12.134 10.22.12.134 207.46.41.209; network-path-time=1243371861 Received: from COL104-W8 ([65.55.34.72]) by col0-omc2-s17.col0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 26 May 2009 14:04:38 -0700 Message-ID: col104-w8d40e0023b93e83b4ffcbc6...@phx.gbl Content-Type: multipart/alternative; boundary=_be3ff754-56a4-49ca-a500-6d9290a4f246_ X-Originating-IP: [66.110.6.119] From: ___...@sympatico.ca To: off...@hwcn.org Date: Tue, 26 May 2009 21:04:38 + Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 26 May 2009 21:04:39.0020 (UTC) FILETIME=[94F89AC0:01C9DE45] Subject: DSL rates (body snipped) --
Re: RBL triggered?
Charles Gregory a écrit : Excuse if threading breaks, but I have to copy and paste from the archives. I'm not getting deliveries from the list (due to a bounce somehow disabling deliveries). Currently contacting list owner to resolve this odd issue. Well, at least I can still post :) mouss mo...@ml.netoyen.net said: Quick question: Does Spamassassin's RCVD tests also check headers labelled X-Originating-IP? yes. (nod) Certainly makes sense of the unexpected scores. But I am wondering if I have made some wrong presumptions about the behaviour of tests for dynamic IP's? Or perhaps dynamic IP's should *not* be scored if they appear in 'Originating IP'? Or scored lower than if they appear in the first RCVD header (or any RCVD header). if you mean checks against PBL and the like, these are only done for the last external Received header. unless you have an old version of SA (initially, there were only trusted vs untrusted networks. then internal networks were added). The issue, of course, is not with actual 'dynamic' tests, but with BL_SPAMCOP_NET having listed the dynamic IP. This is a different issue. unfortunately, there is not much to do unless spamcop (and other DNSBLs) have a full list of dynamic IPs. note that spamcop listings expire automatically. if this is really a problem for you, change the rule to use last-external (take a look at the PBL rule and you'll see what I mean). I realize this is another 'flavor' of an ages old problem - what happens when an 'innocent' user 'inherits' a dynamic IP blocked for spammy activity. If the ISP blocks port 25, the dynamic IPs won't be listed. otherwise, some will argue that it is the ISP fault. unfortunately, it is hard to deal with this problem in an effective manner (avoid FPs but still stop junk from owned boxes...). But I'm wondering if there is just a way to recognize when this 'new' user makes proper use, goes through their legitimate SMTP server, or uses webmail? Yes, I realize that technically SPF is supposed to help with this, not at all. but I am not an spf fan, so take this as a biased opinion... but I get too many false negatives to rely on 'SPF PASS'... - Charles
Re: Barracuda Blacklist
Neil Schwartzman a écrit : On 28/05/09 9:35 AM, Matt lm7...@gmail.com wrote: Is there a reason the Barracuda blacklist is not in the official checks by Spamassassin yet? I keep thinking sometime sa-update -D will add it but have yet to see it. I would like to add some perspective to potential use of the BRBL. Three weeks ago, I began requesting de-listings of any IP (active or suspended) on Certified that was listed on the Barracuda BRBL. When I started on April 29 there were 431 such IPs, as of today there are 22, of those there are 5 repeat listings. it seems to me that they do list based on reporting (automated or any silly user click here to report spam button). they once listed my old-chool forwarder, which does forward spam because it forwards every mail for those who activate the forwarding (and even if they run a good SA setup, I want to check my messages on my own SA). the IP was delisted after it was added to DNSWL, but the event was enough for me not to use BRBL at smtp time. That said, I use it in SA with a high score (actually more than 5. but I do check my junk folder...). I also use it at smtp time for some sender patterns. In either case, it catches many snowshoe spammers (I also have a local DNSBL, but I prefer to avoid maintenance work as much as possible). to summarize: BRBL is good, but it's still a new list... [snip]
Re: Filtering through mailing lists
Garik a écrit : I have a situation where by mail passes through a mailing list and then goes on to the destination mailbox that's subscribed in the mailing list. Here's my problem: SpamAssasin checks the emails going through the mailing list for SPAM and adds the subject [**SPAM**] to the email, and then when it's going to the mailbox it checks the email again and adds the [**SPAM**] header a second time. So my emails end up looking like: [**SPAM**] [**SPAM**] My_email_subject Is there anything that can be done so there's only one instance of [**SPAM**] in the subject? Have postfix strip out the spam headers from the subject, or is there another solution? Someone would have run across this problem before me. I'm running SpamAssasin 3.1.7, MailMan using Postfix. configure mailman to resubmit mail to a port that is unfiltered. no point to filter mail twice. $ cat mm_cfg.py ... SMTPHOST = '127.0.0.1' SMTPPORT = 10025 ... Any help would be welcome, Garik
LET'S KILL THIS THREAD (Was: whitelists (was Re: Barracuda Blacklist)
ANTICOM-STINGER a écrit : On Fri, 2009-05-29 at 12:16 -0600, J.D. Falk wrote: Rob McEwen wrote: Additionally, I'd like to ask, other than being a superb cash-generating machine, what good is a whitelist built upon pay-to-enter and NOT based on editorial decisions made by non-biased e-mail administrators? Those two aren't necessarily exclusive. The standards for inclusion in a whitelist can (and in many cases do) include the same performance metrics that help e-mail administrators stay non-biased, such as user complaint rate, spamtrap hits, and so forth. (I don't know whether Barracuda's whitelist includes those metrics.) The additional value to admins is that they don't have to keep watch over the whitelisted IPs -- the whitelist operator handles that. The fees cover that monitoring, and consulting on improving practices where necessary. And, of course, if the whitelist operator is lying or slow or otherwise not living up to expectations, the admin simply stops using that whitelist. Lists that nobody uses don't get much business, so there's a direct incentive for the whitelist operator to keep their list squeaky-clean. The Barracuda white list is an 'exclusive' club and I suspect money has changed hands. It includes eBay, Amazon, Microsoft etc along with some very big 'marketing' companies that Micheal Perone (former alleged spammer now part of Barracuda) may have some involvement in. For the ordinary 'mongs' there is email.reg which is a 'pay to spam' service :-) I guess everyone knows that the Barracuda is basically SpamAssasin on a cheap Linux box. It's full of great open source software glued together with some very flaky scripts. I cannot believe people pay the money they do for it. I don't think Barracuda can believe it either. I personally think this is non sense, but let's admit this is my personal opinion and that it would take us too far to debate this. so let's please kill this thread. PS. I am not affiliated with Barracuda, nor with anything affiliated with them. I do use their list in SA and I subscribed for access to their list, and that's all.
Re: New method to bypass SA?
fchan a écrit : I recently was checking on servers that were sending out spam and found one of them had the hostname called localhost which I think is a attempt to bypass SA. The IP address is 222.252.188.181 which maps back to Vietnam. SA will not use localhost unless your MTA is borked. with postfix and others, the hostname will be unknown (for a PTR to be used, IP - PTR - A should return the original IP). Also I found that a large percentage of my spam comes from Brazil and I checking of anyone noticed this also. Frank Block these at MTA level. with (a recent) postfix: smtpd_recipient_restrictions = ... reject_unauth_destination ... check_reverse_client_hostname_access hash:/etc/postfix/access_host check_helo_hostname hash:/etc/postfix/access_host ... == access_host localhost REJECT invalid name unreachable REJECT invalid name .localhost REJECT invalid name .localdomainREJECT invalid name .lanREJECT invalid name .local REJECT invalid name .lokaal REJECT invalid name .arpa REJECT invalid name .localdomainREJECT invalid name .invalidREJECT invalid name .invREJECT invalid name .reverseREJECT invalid name .home REJECT invalid name .privateREJECT invalid name .firewall REJECT invalid name .adsl REJECT invalid name .belkin REJECT invalid name .kornet REJECT invalid name .speedportw700v REJECT invalid name .test REJECT invalid name .root REJECT invalid name .domain REJECT invalid name
Re: FCrDNS and localhost
Adam Katz a écrit : Matus UHLAR - fantomas wrote: 181.188.252.222.in-addr.arpa domain name pointer localhost. That is why FcRDNS is being used everywhere... localhost has address 127.0.0.1 = fail. Actually, localhost doesn't resolve via DNS; I don't know where you're taking this from: $ host localhost 127.0.0.1 Using domain server: Name: 127.0.0.1 Address: 127.0.0.1#53 Aliases: localhost.netoyen.net has address 127.0.0.1 it has no A record, nor any other record type. It resolves locally without using DNS; see your /etc/hosts file. Similarly, 1.0.0.127.in-addr.arpa. has no PTR record indicating it should be called localhost. It does here. we BSD users love DNS ;-p if anyone uses reverse DNS name without forward-confirming it, it's their own fault and they can take all consequencies from such stupid setup. afaik some reverse-checking services are more strict about invalid than about nonexisting hostnames. And I recommend to behave like that. SA (usually) uses hostname passed by MTA, so if an MTA is affected by this bug, blame MTA, not SA. And I'm not sure if the hostname is used by any checks that would cause positive (oor lower negative) score. Sadly, too many servers are set up improperly in this context, so I doubt I'm in the minority when I say that I don't use this metric to single-handedly block mail. My khop-general.sa.khopesh.com channel contains: # Sendmail's FCrDNS, see http://www.sendmail.org/faq/section3#3.38 header KHOP_MAYBE_FORGED Received =~ /\(may be forged\)/ describe KHOP_MAYBE_FORGED Relay IP's reverse DNS does not resolve to IP scoreKHOP_MAYBE_FORGED 0.8 # 20050802, raised 0.15-0.8 20090603 # Violates rfc2821? See http://en.wikipedia.org/wiki/FCrDNS#Uses headerKHOP_HELO_FCRDNS X-Spam-Relays-Untrusted =~ /^[^\]]+ rdns=(\S+) helo=(?!\1)\S/ describe KHOP_HELO_FCRDNS Relay HELO differs from its IP's reverse DNS score KHOP_HELO_FCRDNS 0.4 # 20090603 Maybe SPF, I expect someone to comment on this... Same problem as above: localhost is not actually a domain. it _is_. $ host -t TXT localhost. localhost has no TXT record $ host -t TXT localhost.localdomain. localhost.localdomain has no TXT record In contrast, localdomain is not a valid TLD. I suppose I could place such an entry in my local DNS server... Actually, I like that idea. Don't forget to also create an A record! You'll want TXT record v=spf1 ip4:127.0.0.0/8 -all for both localhost. and localhost.localdomain. why bother yourself with SPF since nobody remote should call himself localhost. localhost is a reserved domain.
Re: FCrDNS and localhost
Adam Katz a écrit : John Hardin wrote: So that data comes from /etc/hosts. How does that materially affect the FCrDNS sanity test? By definition, FCrDNS uses DNS lookups. Unless you're using dnsmasq, the entries in /etc/hosts are ignored during DNS lookups. This is wrong. FCrDNS lookup uses a DNS resolver, which could use whatever you setup on your system, including /etc/hosts. for example, postfix uses the system resolver, which can be configured via nsswitch.conf to query /etc/hosts and/or DNS. Unless I'm mistaken, no FCrDNS implementation ever queries /etc/hosts (nor should it). Are you saying that all those widely used servers that do this are wrong? This means FCrDNS will conclude that localhost does not resolve I don't know why you say that localhost doesn't resolve. It resolves on all systems I have ever used. my basic DNS template files include resolution for reserved domains and IP blocks (so that resolving private IPs doesn't go over the network uselessly...). and that 127.0.0.1 has no rDNS (excepting cases where the admins have manually placed such entries into the local DNS). which is the default in *BSD and other distributions.
Re: FCrDNS and localhost
Matus UHLAR - fantomas a écrit : On 05.06.09 23:55, mouss wrote: localhost.netoyen.net has address 127.0.0.1 oh, I didn't even realize it was the .$domain one! old habit to avoid nslookup barking and then lusers asking what's the problem... Actually, I think this is not good. localhost. should resolve, but putting localhost to other domains even with 127.0.0.1 address is something that should be imho avoided ;) why? if it's because of xss and the like, it doesn't apply here, because attacker can use http://localhost/ as well (or even http://127.0.0.1/). or am I missing something?
List headers and footers [Re: Unsubscribe]
David Gibbs a écrit : LuKreme wrote: The unsubscribe link is right there in plain sight. Whether Gmail conceals it from you has nothing to do with it. Few consumer mail clients (Gmail, Yahoo, Thunderbird, OE, Outlook, Lotus/Domino, etc) show the user headers by default. This means they are clearly NOT in plain sight. No. this is a bad idea. If you can't figure out how to look at mail headers, then you have no business on this list. The point is, you shouldn't HAVE to look at the mail headers. Putting the unsubscribe info in the footer is a good idea no mater what. I am not as convinced as you: - this modifies the body, thus breaking signatures. when mail gets back to the same domain (sender and final recipient in same domain), this may cause problems. I agree that many lists do break signatures so the receiving site should cope with this, but I am not sure they really do. - the code is not trivial because of the MIME structure. - because of the points above and may be other issues, consensus is hard to reach. This is what I do for all the lists I run. Yes, some people are too dumb to read that far ... but MOST people aren't. those who send these unsubscribe posts do not really look at the list messages when they do. I am convinced that an unsubscribe option should be implemented in MUAs. david
Re: List headers and footers [Re: Unsubscribe]
David Gibbs a écrit : mouss wrote: - this modifies the body, thus breaking signatures. when mail gets back to the same domain (sender and final recipient in same domain), this may cause problems. I agree that many lists do break signatures so the receiving site should cope with this, but I am not sure they really do. Signatures ... as in DKIM / DomainKeys? Or GPG signatures? any (cryptographic) signature method that is invalidated if text is added to the body. here is an example: - mail admin at example.com configures his mail system to sign all outbound mail with DKIM - he rejects any mail with a From: in his domain if it doesn't have a valid DKIM signature - j...@example.com posts to a list that appends a footer (or munges the Reply-To header, assuming this is used in the signature). - list resends the message to mx.example.com. - mail is From: j...@example.com, but it is either not signed (list removed the signature) or the sig is not valid (message altered by list). - the code is not trivial because of the MIME structure. BTW. dspam once had a bug (dunno if it was fixed): when you enabled the signature in body option, it appended text to the body, which obviously won't work for html mail for example! Ah, this may be the case ... I'm unfamiliar with the exact configuration of the SA lists. On my own list server I convert everything to plain text to avoid problems with incompatible mail clients. yes, that usually works (in text only lists such as this one where we don't exchange images...). but even this is a hard game because you need to take a decision when the message is broken (incorrect html, ... etc). this is somewhat similar to the problem of browsers trying to fix incorrect html, but each browser has its heuristics, and you're never sure what the browser guessed is what the page author intended! that said, I agree that in a text only list, it should work correctly, and even if it does not, the fault is in the sender side ;-p This is what I do for all the lists I run. Yes, some people are too dumb to read that far ... but MOST people aren't. those who send these unsubscribe posts do not really look at the list messages when they do. True enough. Add to those the people who think the best way to get unsubscribed from a list is to simply report it as spam. BTW, in .fr, most MUAs (including webmail) translate spam as Messages undesirables, which most users naturally understand as a way to report mail they don't want. so even if you send them mail regularly, but there is one they didn't like, they'll hit the This Is Spam button. The fault is shared between the luser and the UI designer/translater! I am convinced that an unsubscribe option should be implemented in MUAs. I completely concur. It's not rocket science. I *THINK* I saw a tbird add in that implements this kind of functionality, but it would be better as part of the core. yep. david
Re: some URIBL accidentally listed .org?
Yet Another Ninja a écrit : On 6/14/2009 10:48 PM, Justin Mason wrote: http://log.perl.org/2009/06/email-issues-org-blocked-now-fixed.html anyone know what URIBL provider this was? --j. Wouldn't we all have noticed if this would have been the case? not if they use some unknown uri blacklist. or if they use a forwarder that decided to return a customized IP for any domain containing .org.
Re: backscatter from dnswl
a...@ibcsolutions.de a écrit : Excerpts from Charles Gregory's message of Thu Jun 11 07:13:02 -0700 2009: How many accounts are we talking about here? If it is just one or two addresses, and the user(s) being 'spoofed' have distinctive *names* on their genuine 'From' headers, then you can test for quoted messages in the body that contain a From line withthe correct address but a *wrong* 'name' in front of it. To use your address as an example: body LOC_NOTARVIS /^[ ]*From: ?([^A]|A[^r]|Ar[^v])[^@]+a...@exys\.org/ So any junk 'returned' to you as faked sender, containing, for example: Returned From: Bob smith a...@exys.org would trip over this rule. Also note that if somehow your name is *stripped*, and only the address appears, this rule will *not* trigger. It only works on *wrong* names in front of your address. The use of [^@] keeps the rule from triggering if someone has specified multiple addresses. You might not want this on a body 'From' test, but I also use this as a header 'To' rule for some of my clients to stop dictionary spam attacks :) - Charles Thanks! This looks very useful. We temporarily have blocked some networks which exhaust our relays. This is indeed caused by only a few domains all from the same customer group (trading stuff), and I think some spammers are using those addresses as From: mainly because 1) it looks trustworthy 2) we allow sender callins. Interestingly the backscatter is _only_ caused by domains within Russia with almost identical format (well, all qmail ), so I'm looking into triggering that. That forged Name/Address relationship is a pretty good find. I'll look into applying that rule system wide. I wouldn't recommend this. my friends use many variants of my name/nick/... that I can't do that even for my own address. only use as a cure.
Re: [sa] Re: BOTNET timeouts?
Bill Landry a écrit : Res wrote: On Sat, 13 Jun 2009, Charles Gregory wrote: On Sun, 14 Jun 2009, Res wrote: Though now its Sunday, I have socialising to do, and none of that includes sitting on mailing lists listening to cry babies who expect people involved in OSSP's to drop everything and be their servants. So we'll just all pretend you didn't send this message. .and the one after it. :) That's perfectly acceptable, if you need help with setting me in a killfile, I'll be more than happy to assist :) Maybe you could add your email address to your outbound mail server's killfile. I know that would deprive the world of your comic relief, but it would also allow the rest of us to focus on real list related issues without unnecessary distractions, and it would give you ample time to focus on improving your grammar, spelling and people skills. Sounds like a real win/win situation to me... Bill, I think you'll agree with me that it is time to stop feeding censored/
Re: List headers and footers [Re: Unsubscribe]
David Gibbs a écrit : Bill Landry wrote: This may be true if the sender were adding the footer before signing and sending the message to the list. However, not true if it's the mailing list that is adding the footer after the original sender has already signed the message. As I understand it, in order for the signatures to be valid, the message has to be signed by the sender ... because most mailing list software adds headers. Mailman has specific functionality to remove signature headers so that the message can be resigned as it's sent out. which doesn't help, because if I get mail claiming to come From: mo...@netoyen.net, yet it doesn't have a sig of mine, I don't really care if some fancy mailman owner has added his own. if all it takes is to claim to be a mailman, then I can fake all signatures of the whole internet by adding mailman headers.
Re: List headers and footers [Re: Unsubscribe]
RW a écrit : On Sun, 14 Jun 2009 13:20:21 +0200 mouss mo...@ml.netoyen.net wrote: I am not as convinced as you: - this modifies the body, thus breaking signatures. when mail gets back to the same domain (sender and final recipient in same domain), this may cause problems. I agree that many lists do break signatures so the receiving site should cope with this, but I am not sure they really do. Some lists only add the footer to single part text/plain emails. given that the most widely used MUAs show the html part, this means such footers are useless because only few people see them, and these people can see headers. (and anyway, whatever part you alter, the sig is broken). Most people don't sign mailing list messages anyway. Most people have no way to chose which mail to dkim-sign, since this is done at MTA level. are you confusing this pgp?
Re: [sa] Re: BOTNET timeouts?
Bill Landry a écrit : Bill Landry a écrit : Res wrote: On Sat, 13 Jun 2009, Charles Gregory wrote: On Sun, 14 Jun 2009, Res wrote: Though now its Sunday, I have socialising to do, and none of that includes sitting on mailing lists listening to cry babies who expect people involved in OSSP's to drop everything and be their servants. So we'll just all pretend you didn't send this message. .and the one after it. :) That's perfectly acceptable, if you need help with setting me in a killfile, I'll be more than happy to assist :) Maybe you could add your email address to your outbound mail server's killfile. I know that would deprive the world of your comic relief, but it would also allow the rest of us to focus on real list related issues without unnecessary distractions, and it would give you ample time to focus on improving your grammar, spelling and people skills. Sounds like a real win/win situation to me... Bill, I think you'll agree with me that it is time to stop feeding censored/ Yes, I agree - I'm done now. just to avoid Res taking this too bad: there is nothing personal. this is strictly related to _this_ thread.
Re: Hostkarma whitelist problem
Bowie Bailey a écrit : I couldn't find any place on junkmailfilter website to report this, so I'll put it here. I received a 419 scam email with this whitelist hit: so what? I keep getting 419 from google, yahoo, ... but they are still whitelisted. and anyway, fighting 419 is not easy. That said, JM_SOUGHT_* gets many of these. many thanks to JM, JH, KB, ...etc (which reminds me that I should make my corpus available, argh). * -3.0 RCVD_IN_JMF_W RBL: Sender listed in JMF-WHITE * [213.4.129.18 listed in hostkarma.junkemailfilter.com]
Re: interesting phish for yahoo credentials or stupid spammer
Michael Scheidell a écrit : spam, with a url link in it that opens up a yahoo.com web mail page and asks for yahoo.com credentials. don't know how that can help spammer, unless spammer is looking to only get email from yahoo.com users. see line 119 (highighted) http://pastebin.com/m6bb65f86 so, interesting phish or stupid spammer with yahoo.com gooplet installed? this is not a phish. it's a 419 (AFF). spammer is asking the user to reply, and being helpful, spammer provides a ready-to-compose yahoo link. spammer probably did a cutpaste of a link that works for yahoo users and thinks it is generic. unless he only targets yahoo users...
Re: New www.medsXX.net spam
John Hardin a écrit :
On Fri, 2009-06-19 at 09:24 -0700, John Hardin wrote:
On Fri, 2009-06-19 at 16:21 +0200, Paweł Tęcza wrote:
body AE_MEDS35 /w{2,4}\s{0,4}meds\d{1,4}\s{0,4}(?:net|com|org)/
I've just noticed missing 'i' switch for your rule regexp. Is it a bug
or a feature? :)
That depends. If the URIs are always lowercasein the spams, making the
RE case-insensitive doesn't help and may hurt.
BTW, probably \s+ will be better than \s{0,4}. Similarly with w{2,4} and
\d{1,4}.
No, it's not. In SA, unbounded matches are hazardous and should be
avoided. {0,20} is safer than * and {1,20} is safer than +.
This is not a general rule, it only applies where the text being scanned
is from an untrusted (and possibly actively hostile) source.
Another improvement: add word boundaries at the beginning and end:
/\bw{2,4}\s{0,10}meds\d{1,4}\s{0,10}(?:net|com|org)\b/
If the parentheses in the original example are actually in the message,
including them will help to. Are they actually in the message?
D'oh, /me checks pastebins from first message...
Also, body rules match cleaned-up text with runs of spaces collapsed, so
you don't need to use + or {1,...}
Try this:
/\(\s?w{2,4}\smeds\d{1,4}\s(?:net|com|org)\s?\)/
you can replace meds by (meds|shop) to catch the www shop95 net
variants.
Re: SORBS bites the dust
Charles Gregory a écrit : On Mon, 22 Jun 2009, rich...@buzzhost.co.uk wrote: Really? Personally I find the PBL just kicks its ass. When I did my research for setting up RBL's, I found old comparisons between RBL's that seemed to indicate that the spamhaus PBL and the spamcop lists had slightly higher levels of flase postives. stop spreading FUD. if you know of false positives, show us so that we see what you exactly mean. a lot of people, including $self, use the PBL at smtp time. Not 'bad', but just poor enough that I prefer to give PBL a weighted score in SA rather than run it as a poison pill in the MTA. Though with everything I've been seeing lately, I'm darned tempted to ramp it up. Especially if sorbs DUL list is going to go bye-bye Perhaps it is time to do some new comparisons? Does anyone have some stats on the effectiveness of various RBL's versus the FP rate? at this time, zen is _the_ list. Presumably the scoring defaults in SA are somehow based on this, but I wouldn't mind being able to decide for myself. Unfortunately, the privacy regs prevent me from keeping a good corpus here and doing my own tests. despite the privacy regs here (and not only because of regs. I am extremely attached to privacy), I have no problem keeping a corpus of spam from one hand, and a list of IPs that sent other mail.
Re: SORBS bites the dust
Gary Smith a écrit : If you follow the unlisting proceedure and meet all of the requirements, then you get unlisted. As with all things, it just takes a little patients. After converting my IP's over from my ISP to my DNS servers, I was listed (because the ISP no longer listed us a static). We were able to resolve it in a fairly resonable amount of time. I don't recall even paying a dime. payment were only needed for spam, not for dul anyway, this is getting way off topic. whatever you I think of how sorbs should have been run (and thinking != running), its death, if confirmed, is sad news.
Re: SORBS bites the dust
Res a écrit : On Tue, 23 Jun 2009, mouss wrote: payment were only needed for spam, not for dul not really :) despite what their site said/says.. its kind of a detterent i think sunno we never paid This is wrong. if you have evidence, show it. if not, stop spreading rumours. I have delisted an IP in the past, and I have been watching people trying to delist a block but without clues on how to do it... anyway, this is getting way off topic. whatever you I think of how sorbs should have been run (and thinking != running), its death, if confirmed, is sad news. If it is confirmed it wil indeed be sad times, SORBS catches the most of the crap that comes in here
Re: [sa] Re: SORBS bites the dust
Charles Gregory a écrit : On Wed, 24 Jun 2009, Matus UHLAR - fantomas wrote: somewhat hesitant to use spamcop as our own servers once had a brief listing with them (and it wasn't due to spam). Got more info? Sadly, we're dealing with my aging memory. :) While I cannot remember precisely, categorically it was a situation like: 1) A piece of junk that one of our users had forwarded to another server and then THE USER 'reported' the spam (which naturally had *our* IP at the top), or, 2) Someone 'reported as spam' a bounce from our server that had their address forged as sender (for some condition like 'full mailbox' which even now still sometimes generates a DSN rather than being rejected at the SMTP gateway). neither of these will et you listed on zen. zen is composed of - pbl: these are IPs that are not supposed to send mail. this is either decided by the ISP (then if you're listed, you know to whom to complain) or by spamhaus (this is when the ISP doesn't want to tell which IPs are dynamic/residential/...). - sbl: these are confirmed spammers. you don't end up here as a result of a misconfiguration. - xbl (cbl, njabl-proxy): these are infected boxes. you may get listed on spamcop though, but such a listing expires automatically unless the conditions are repeated. and I don't consider such a listing to be an FP. Admittedly we've made massive improvements to our systems since that time. We now filter at SMTP time, rather than have the filter in procmail which is bypassed by .forward, and I've put in extra mechanisms to catch as many of the 'full mailbox' type of conditions as possible at SMTP time. But whichever the case was, it still bothered me that this major blocklist seemed to have added our IP for a singular incident/report. I would expect there to be a minimal threshold for accidental or false reporting. if you talk about spamcop or cbl, you really need to reread how they work. it is good even for you that they list you if they detect bad behaviour. this gives you a chance to fix the problem. (I had this with one IP, that I finally decided to block myself). Mind you, there is every chance that spamcop has upgraded their systems in the intervening years. All I have to go on is my experience. :) spamcop has changed few years ago (3 years?). so if you're talking about an old incident, then it's no more relevant. Anyways, there's what 'info' I have. I won't be surprised if it's not 'good enough' for anyone. If someone knows something improvements to their spam reporting, I would be interested. Thanks. I don't use spamcop at smtp level, because I know they block some networks I want mail from, but the block is understandable (large university where one of the internal dept has its own relay, which can't be disabled for now, and which has a bogus list mgmt software that can't yet be kicked off. in short, the block is bad for the university in the short run, but it gives an argument to disable those old setups, which is the way to go).
Re: SORBS bites the dust
James Wilkinson a écrit : mouss wrote (about the PBL): stop spreading FUD. if you know of false positives, show us so that we see what you exactly mean. a lot of people, including $self, use the PBL at smtp time. As usual, it depends on your definition of “false positive”. fully agreed. I personally find it bad to block any non spamming network. but sometimes, the only reasonable way to do this is via whitelists, and unfortunatley, you can't whitelist unknown senders. so yes, I do block some networks because I think they are too spammy (they may contain legitimate IPs). If you mean “IP address that should not have been in the PBL but was”, that’s one thing. It’s a consistent definition, but not very useful for stopping spam. If you mean “solicited and/or non-bulk email that would have been stopped by the PBL”, then I’ve seen a number of small Indian and Chinese companies who are unaware of a lot of things, including the existence of the PBL and that it’s a Good Thing to send email through a smart host with a consistent IP address and reverse DNS.¹ yes, the PBL may list blocks that contain networks which want to send mail directly, and which in principle, should be able to do so. but whatever decision you taéke here is difficult. if you say, I will only block those who I am certain are criminals, then some criminals will get in. whether you use them or not, lists that put some pressure on ISPs, networks, .. are good, and are necessary. some time ago, open relay was ok. now, you won't here much people saying but I want the freedom to relay... . yes, spammers are making us crazy ;-p Obviously, everyone’s email stream is different. Mine includes a commercially-significant amount of email from small companies in those two countries, and probably doesn’t include email from other countries where this takes place. just to make things clear. while I do use zen, my setup is not what one would call aggressive (I do complain about some networks, but I don't block them. but I do block snowshoe spammers too easily). I do get alien mail from some networks (and not even from Asia!), and while I have thought of comibing checks (x AND y AND z), I found solicited mail that matches every bad thing I wanted to mix in the rule! But by this definition, false positives do occur, and my company’s SpamAssassin installation has to try to handle them. James. ¹ Fortunately, they’re also unaware that signatures should be removed when replying. That, a standard corporate signature including company registration data, a standard domain in each Message-ID that doesn’t appear in public DNS, a few negatively-scored custom rules to detect these, and the AWL mean that once someone has responded to one of our emails, they get automatically whitelisted. So at least existing correspondents don’t get blocked.
Re: SA RegEx Rules
Cory Hawkless a écrit : Hi all, Been doing some reading on RegEx and even coming from a programming background it is a bit intimidating, my problem is I haven’t been able to find a good source of information on exactly what\how SpamAssassin matches the RegEx rules when scanning and what variant of RegEx is being used?(I.E what syntax is and is not allowed?) spamassassin written in perl, so it uses perl syntax. I’d like to be able to make my own simple rules but it’s proving quite difficult, Maybe a tool that I can use the build Regular Expressions would help? IMHO, the best tool is to learn perl syntax. you can for example look at chapter 6 in the Perl Cookbook. here are a few links returned by google: http://www.perlfect.com/articles/regextutor.shtml http://www.anaesthetist.com/mnm/perl/Findex.htm#regex.htm http://www.cs.tut.fi/~jkorpela/perl/regexp.html http://www.troubleshooters.com/codecorn/littperl/perlreg.htm I’m sure there are PELNTY of other out ther that are rather bamboozled by this also and would benefit greatly from any assistance. Thanks in advance Cory
Re: trusted_networks and internal_networks
MrGibbage a écrit : I have read the help pages for those two settings over and over, and I guess I'm just not smart enough. I can't figure out what I should put for those two settings. Can one of you give me a hand by looking at the headers from an email? I can tell you that my SA installation is on ps11651.dreamhostps.com and the way I receive email is I my email is sent to my public email address, s...@pelorus.org and I have an auto-forwarder which sends the mail to my SA box via email, at skip-mor...@psoneonesixfiveone.dreamhostps.com (mangled here). I never receive mail directly to skip-mor...@psoneonesixfiveone.dreamhostps.com. If I did, it would have to be spam because they scraped the address from somewhere. pelorus.org and ps11651.dreamhostps.com are the same box. All the appriver stuff below is done on the sending side of my company's exchange server. Anyway, maybe I got it, but these two settings seemed too important to get wrong, so I just want to be sure. #ps11651.dreamhostps.com and pelorus.org internal_networks 75.119.219.171 trusted_networks 75.119.219.171 #I think this is wrong no, it is not wrong. the documentation says: Every entry in internal_networks must appear in trusted_net- works; so whenever you put an internal_network line, you should add the same line with trusted instead of internal. So is the idea that I could add more trusted_networks to the list, sort of like a whitelist. Perhaps adding my work ip addresses below? Isn't that trusted_networks setting above saying **ALL** mail is trusted to not be spam since **ALL** mail comes in on that IP address? And what about the Received: from homiemail-mx7.g.dreamhost.com (balanced.mail.policyd.dreamhost.com [208.97.132.119])? I have checked and I do receive all mail from one of 208.97.132.* Should that be on my internal_networks? [snip] here, trusted mostly means the relay does not forge Received headers. it can relay spam, but it is not controlled by spammers (directly or via trojans/open proxies/...). to summarise: for those relays that you trust not to be operated by spammers (directly or not): - if they receive mail from residential/dynamic IPs (without authentication), then list them in trusted_networks only - else, list them in both internal_networks and trusted_networks If this is too theoritical, consider the practical side: When SA looks up PBL, SORBS_DUL, ..., it will not look up IPs listed in internal_networks. in general, your own relays will be listed in both internal_networks and trusted_networks. but if you have a forwarder that is not under your control, and that may be used to relay mail for residential IPs, then you don't want to put it in internal_networks (otherwise, mail from the residential IPs may be caught by PBL, SORBS_DUL, ... evethough it is relayedvia a smarthost, as is generally recommended).
Re: trusted_networks and internal_networks
Jari Fredriksson a écrit :
MrGibbage a écrit :
#ps11651.dreamhostps.com and pelorus.org
internal_networks 75.119.219.171
trusted_networks 75.119.219.171 #I think this is wrong
no, it is not wrong. the documentation says:
Every entry in internal_networks must appear in
trusted_net-
works;
so whenever you put an internal_network line, you should
add the same line with trusted instead of internal.
If that is indeed true,
As of 3.2.5, Received.pm contains this:
if (!$relay-{auth} !$trusted-contains_ip($relay-{ip})) {
$in_trusted = 0;
$in_internal = 0; # if it's not trusted it's not internal
}
so as soon as an untrusted relay is found, it is considered as
external.
it is a BUG IMO.
not really a bug. just a configuration annoyance . I mean, since
internal_networks is a subset of trusted_networks, then any internal
relay should automatically be considered as trusted, without the need
to duplicate information.
Brain dead requirement!
the requirement is reasonable. an internal relay that wouldn't be
trusted is irrelevant. why would you want to skip PBL/DUL lookup for
an IP that may be forged?
Re: trusted_networks and internal_networks
Jari Fredriksson a écrit : I tried with this: -(local.cf)--- internal_networks 10.0.0.0/8 trusted_networks 10.0.0.0/8 127.0.0.1 trusted_networks 212.16.98.0/24 212.16.100.0/24 62.142.0.0/16 195.197.172.98 trusted_networks 195.74.0.0/16 213.192.189.2/24 217.30.188.0/24 65.54.0.0/16 trusted_networks 83.145.211.136 217.30.180.104 trusted_networks 64.233.183.0/24 209.85.199.0/24 72.14.247.27/24 64.233.163.27 trusted_networks 213.157.94.92 -- Here, internal is a subset of trusted, is that how it should go? $ spamassassin -D --lint [7594] warn: netset: cannot include 127.0.0.1/32 as it has already been included remove 127.0.0.1/32 [7594] warn: netset: cannot include 10.0.0.0/8 as it has already been included which version of SA is this? also grep for 10.0 in your .cf files. when I put your lines in my config, I only seethe 127.0.0.1/32 warning. It looks like SA itself configured the trusted.
Re: trusted_networks and internal_networks
Jari Fredriksson a écrit : [snip] when I put your lines in my config, I only seethe 127.0.0.1/32 warning. It looks like SA itself configured the trusted. I removed both the 127.0.0.1 AND 10/8 and this is happy again. It seems to configure the internal networks as trusted automagically. As it should be IMO. It may be as it should be for you. so it's a good default. but here, internal != trusted (strict subset), because I trust relays that are not under my control and which may accept mail from residential users.
Re: copy spam mail to separate mailbox
Evan Platt a écrit : At 11:22 AM 7/16/2009, you wrote: I have a postfix/SA setup and I was wondering if anyone knew how to COPY an email marked as spam instead of redirecting. Not this: /^X-Spam-Flag: YES/ REDIRECT spam...@example.com if you use amavisd-new, configure it to add a +spam extension. then in postfix, use recipient_bcc_maps: /^(.*)\+s...@example\.com$/ somebox...@example.net I am assuming you use '+' as an extension delimiter. if you don't want to use amavisd-new, then it's easier to do this in your delivery agent (dovecot+sieve, maildrop, ... etc). otherwise, you can use FILTER instead of REDIRECT to pass the message to a script (which will need to resubmit mail. beware of infinite loops here). As that's really a postfix question, not a SpamAssassin question, if you don't get an answer here you may want to try on a postfix mailing list. indeed.
Re: Spamassassin rules in a mysql database
Martin Gregorie a écrit : put any custom rules in the database, and modify the spamd? start scripts to write the custom rules to flat files. modify your update program to signal a spamd reload every time you modify the rules, or, use unison. we use unison (not for our VPS spam clusters) but for syncing flat files used on our redundant web servers (any downloaded pdf's can be up to 15 mins behind the 'master') which is why we don't do that on our anti-spam clusters. However you slice it, you'll need to introduce a cron job to pull down any SA configuration updates and restart spamd if any are found. Alternatively, you might want to modify the SA daemon start script to pull down updates to your configuration before starting spamd. Consequently this exercise boils down to finding the easiest way to graft update retrievals onto the cron job. I think there are a number of ways to do this that are simpler than using an SQL database. For starters, none of the following require text-SQL-text conversions. Try using one of these: - CVS, or whatever version control system is favored at your site. CVS is simple to set up, works entirely with text files and can sync multiple local copies to a central repository regardless of where the copies are on the network. It only distributes changed files and its trivial to discover if any changes were distributed. - rsync can be used to distribute a flat file repository. Like CVS, it will automatically distribute just the changed files, so its fast and its fairly easy to find out if it pulled down any changes. - wget can retrieve updates from a repository that's distributed by an internal web server, Apache for instance. and as an extension (clarification?) of the latter: - sa-update. convert your rules to a channel and use sa-update.
Re: Avoid processing of email with specific headers
Pietro a écrit : In my installation, SA is called by Postfix. Any idea? Thanks in advance. This is really a postfix question. Follow up on the postfix-users list if needed. you can skip filtering using header_checks. for example /^X-Spam-Status: Yes/ FILTER smtp:[127.0.0.1]:10025 assuming you have an smtpd listening on port 10025 (with filtering disabled). but make sure not to give spammers a free ride: don't skip filtering just because you see X-Spam-Status: No While I am in, using amavisd-new is preferred over running SA directly from postfix.
Re: anchor forgery
Mike Cardwell a écrit : Just checking through my Spam folder and I came across a message that contained this in the html: a target=_blank href=http://www.kanotiser.se/images/logo.html;https://www.paypal.co/us/webscr.php?cmd=_login-runcmd=_secure /a Yet, there was no mention of this obvious forgery in the spamassassin rules which caught the email. How would you create a rule which matched when the anchor text is a url which uses a different domain to the anchor href? this has been discussed a (very) long time ago. the outcome is that a mismatch also happens in legitimate mail. you can do the check for selected domains such as paypal. but then I'd simply look for the presence of paypal (or variant) in the message then look for patterns that confirm it is from paypal, otherwise tag as spam.
Re: Avoid processing of email with specific headers
Jari Fredriksson a écrit : snip did you see this: This is really a postfix question. Follow up on the postfix-users list if needed. did you see that? [snip] Got the following error, when tried that. I'm using stock postfix on Debian Lenny w/ backports. postfix/cleanup[1602]: fatal: dict_open: unsupported dictionary type: pcre: Is the postfix-pcre package installed? # apt-get install postfix-pcre Please move this to the postfix-users list. This is my last response here.
Re: United-MAP spam flood
Paweł Tęcza a écrit : Hello Folks, Did you also get many spams from United-MAP, a dynamic company with rapid development, with a united team of professionals in its core.? :) Or maybe this new spam flood is only Poland targeted? or maybe we don't see them because they come from clients that are in spamhaus PBL? Here are a few spam samples: http://pastebin.com/m178f4a58 The client is listed in the PBL (+ISP maintained, so the isitng is probably old), and in the CBL. http://pastebin.com/m6d07f79d at this time, 62.33.94.189 is listed in PBL and CBL. http://pastebin.com/m477546b9 at this time, 92.230.188.145 is listed in PBL, CBL and SORBS_DUL consider blocking .adsl.alicedsl.de in MTA (or add corresponding rule in SA). My best regards, Pawel
Re: Catch-22 unsubscribing from this list.
Steven W. Orr a écrit : On 07/26/09 20:01, quoth RW: On Sat, 25 Jul 2009 18:07:12 -0400 Michael W. Cocke cocke.mich...@gmail.com wrote: There doesn't seem to be a web interface to subscribe/unscribe from this list. The email address users-unsubscr...@spamassassin.apache.org complains that my IP address is dynamic (which is why I use dyndns.org, thank you very much.) Presumably it's complaining that you are sending direct to mx from a dynamic IP address. If you run a mail server on an dynamic address, you should send your outgoing mail through a smarthost. I'd be curious to hear more on this. I have a server running at home. My ISP gives me a so-called static address that I pay extra for. It's really just an IP address from their pool of dynamic addresses so it registers as really coming from a dynamic address. Somehow I got lucky and got a reverse dns record so if you look my ip up you'll see me and not my ISP. The rest is done through zoneedit.com which does a fabulous job. if your IP is static (doesn't get allocated to others) and you have a meaningful reverse DNS, then it's (almost) ok. you will only have problems with sites that list your whole ISP ranges. but such sites may also block your ISP relays. I've seen sites block all of free.fr ranges because they used MAPS/TrendMicro lists. sigh... on the other hand: - if your IP is dyanmic (it gets allocated to other people), then it is good for you that we know that. otherwise, your IP may be listed in cbl/sorbs_web/..., and your mail may be tagged as spam even if you relay via your ISP. - if your reverse dns is generic, then it is a sign that you are nobody. so we can't give you a reputation based on your name. if we get spam from clients with similar generic names, then it is reasonable to block all such names. I do have a substantial list of people who will not accept email if it is sent to them directly. substantial? really? I would have thought these are a minority. would you share a list of those (offlist)? For each of them I have an entry in my sendmail mailertable. So if you see a domain that is not accepting from you because you're a dynamic address then it's up to you to reroute your email. I would like to state that apache.org is *not* in my mailertable; I deliver direct and have not had a rejection.
Re: Any one interested in using a proper forum?
snowweb a écrit :
I don't know about anyone else, but I'm getting a bit hacked of with this
1980's style forum. I'm trying to get to the bottom of an SA issue and this
list/forum thing is giving me a bigger headache than SA!
Spamassassin has more than one or two users now and I personally think that
it should have a support forum to match the class of software, which is now
world class.
I know it's free and all that, but even so, if this is the only form of
support they provide, I'm thinking that I'll just start an alternative
support forum, using standard, full featured forum software (like SMF).
If you can code a forum that gives people the ability to
- set their preferences the way they now do on their mailers,
- reply as easily as they can now do on their mailers,
then I would applaud. I am even ready to send you money.
Is there any support for this (I already know there will be opposition from
those who are 'resident' here. Sorry guys, I just want do something to help
those who just dive in when they have an urgent problem. No hard feelings I
hope.)
I am not going to debate ML vs news vs forum vs wiki vs blog
vs drupal vs wordpress vs joomal vs php vs ajax vs java vs
vs iphone vs blackberry vs nokia ... etc
Just going to tell you something: people who know SA are on this list.
you can create whatever ${something} elsewhere, but if you can't get
these guys there, you'll only lose your time.
for what matters, many of us prefer the old news. but life is life.
lala la la la...
Re: [OT] Re: Any one interested in using a proper forum?
Mike Cardwell a écrit : Henrik K wrote: Good for you. I've signed up for many mailing lists AND forums. There is nothing inherently better or worse in either of them, No that's wrong, they're quite different and both have advantages and disadvantages. so, it's YES, not NO. Henrik said nothing [snip] better or worse, which is what you said. [snip] If someone set up a proper SA forum, I'd be happy to stop by. But it might be hard to get all the developers and other active participants join there, which is what makes all the difference. Set up the forum. It might work. I'm not anti-forum, I just think mailing lists are generally better. I too prefer mailing lists. but I think it's because I am used to. and firefox eats too much memory... (don't tell me about flash).
Re: Reply to:
twofers a écrit : So what makes a spammer want to use a valid email address as a return or reply-to address to catch all the undeliverable, failure and bounced email that occures when sending UBE spam. this is to beat those who use sender verification/sender callout/(whatever you name it). Is there some legitimacy with spam detection on an email that contains a valid reply-to email address? To me, spam is one thing, but loading a mailbox with literally several thousands of bounced emails is abusive. I'm lucky as I have the option to click one button and remove them all on the server, but for a user to have to delete individually or as a group after downloading them all is just wrong. Any ideas on preventing or minimizing this type of spam? you mean the stupid bounces? well, the solution is to have sites fix their broken setup and not return a bounce if the recipient doesn't exist (they should validate recipients at smtp time) nor if the message is detected as undesired (spam, malware, whatever). until then, the only thing you can do is limit the impact. SA has vbounce.pm. depending on your MTA, you can also block some the outscatter at smtp time. google for backscatter.
Re: blacklisting a forger
Terry Carmen a écrit : On Sat, 1 Aug 2009 19:33:40 -0400 Terry Carmen te...@cnysupport.com wrote: The backscatter would not have been received, since the sender is on a number of RBLs. It's the IP address of the botnet PC that's on the RBLs, the backscatter doesn't come from there, it comes from the recipients of the spam. See: http://en.wikipedia.org/wiki/Backscatter_(e-mail) Regardless of whether or not the message was backscatter, The sending system (triband-mum-59.184.51.13.mtnl.net.in) is blacklisted, - bot at triband-* sent junk to silly.server.example. - silly.server.example didn't reject it. instead it bounced it to OP - the bounce includes infos about which host sent the original junk to silly.server.example, and this is triband-* so for OP, this is backscatter, and RBL/DNSBL is of no help.
Re: received-header: unparseable:
Chris a écrit : I keep seeing this when running some messages throught spamassassin -D -t. Is this having an effect on whether or not short circuit works? received-header: unparseable: from spam01.embarq.synacor.com (LHLO smtpout01.embarq.synacor.com) (10.50.1.1) by md29.embarq.synacor.com with LMTP; the format is not recognized. not really an issue since this is a local relay line. What software generateds this line? can you show the full header? Should this be in my trusted_networks in local.cf: no. this won't change anything. if SA says the line is not parsable, then the IP in the line isn't parsed. 10.50.1/24
Re: received-header: unparseable:
LuKreme a écrit : On 16-Aug-2009, at 18:03, Chris wrote: Received: from spam05.embarq.synacor.com (LHLO smtpout01.embarq.synacor.com) (10.50.1.5) by md29.embarq.synacor.com with LMTP; Sun, 16 Aug 2009 19:19:56 -0400 (EDT) LMTP? Seriously? Does anyone use that? Well, yes, evidently. of course. LMTP is a standard. Anyway, the line is not parsed, so it's not relevant to SA and not used by SA. In fact, you can consider it to be invisible to SA. It will trigger UNPARSEABLE_RELAY, which default score is 0.001.
Re: HELO_DYNAMIC_IPADDR false positive
Bob Proulx a écrit :
The following header line:
Received: from static-96-254-126-11.tampfl.fios.verizon.net [96.254.126.11]
by
windows12.uvault.com with SMTP; Wed, 12 Aug 2009 08:26:40 -0400
Hits the HELO_DYNAMIC_IPADDR rule. I tested it this way:
$ perl -le 'if (static-96-254-126-11.tampfl.fios.verizon.net =~
/[a-z]\S*\d+[^\d\s]\d+[^\d\s]\d+[^\d\s]\d+[^\d\s][^\.]*\.\S+\.\S+[^\]]+/) {
print Yes } else { print No };'
Yes
But the address doesn't appear to be in a dynamic block. And it
doesn't look like a dynamic address pattern to me.
Bob
The name of the rule is worng, but the result is ok. Instead of
dynamic, I suggest: UMO for Unidentifiable Mailing Object. whether
static-ip- is static or not doesn't matter. a lot of junk comes from
such hosts, and we can't report/complain to a domain, since the domain
is that of the SP (and getting SPs to block abuse sources have proven
vain).
Re: Barracuda RBL in first place
Marc Perkel a écrit : http://www.sdsc.edu/~jeff/spam/cbc.html It appears from Jeff's Blacklists Compared list the Barracuda has overtaken spamhaus for the #1 position. Not sure about the accuracy of the list as compared to spamhaus but seams reasonably good to me. I don't really count apews myself since they are extremely bad, but my hostkarma list is next beating out abuseat, sorbs, and uceprotect. Thanks to everyone who is helping me with my tarbaby project to catch virus bots. http://wiki.junkemailfilter.com/index.php/Project_tarbaby Congrats to Barracuda! The deadly difference is: trust. I have never noticed a zen FP. I have found barracuda FPs few days after I started testing it. and the first FP I found suggests they use(d?) some automatic filter-then-list procedure, which is a fundamentally borked approach: the host in question does relay spam, because it is a forwarder, that recipients (such as myself) chose to use. so listing it based on content filtering or on stupid user hit this is spam button may be good for a score based filtering strategy, but isn't good for smtp time rejection. in short, whatever jeff says, spamhaus is the one. the fundamental concept is not how many spam it blocks, but how much do I trust it. note that since few days, reject_non_fqdn_sender rejects a lot of transactions (and shows many bot-clients to block).
Re: HELO_DYNAMIC_IPADDR false positive
Matus UHLAR - fantomas a écrit :
Bob Proulx a écrit :
The following header line:
Received: from static-96-254-126-11.tampfl.fios.verizon.net
[96.254.126.11] by
windows12.uvault.com with SMTP; Wed, 12 Aug 2009 08:26:40 -0400
Hits the HELO_DYNAMIC_IPADDR rule. I tested it this way:
$ perl -le 'if (static-96-254-126-11.tampfl.fios.verizon.net =~
/[a-z]\S*\d+[^\d\s]\d+[^\d\s]\d+[^\d\s]\d+[^\d\s][^\.]*\.\S+\.\S+[^\]]+/) {
print Yes } else { print No };'
Yes
But the address doesn't appear to be in a dynamic block. And it
doesn't look like a dynamic address pattern to me.
On 19.08.09 00:48, mouss wrote:
The name of the rule is worng, but the result is ok. Instead of
dynamic, I suggest: UMO for Unidentifiable Mailing Object. whether
static-ip- is static or not doesn't matter. a lot of junk comes from
such hosts, and we can't report/complain to a domain, since the domain
is that of the SP (and getting SPs to block abuse sources have proven
vain).
I'd be glad to see if there's any difference in percentage of spam from
dynamic and static (generic) IP addresses.
http://enemieslist.com/news/archives/2009/07/why_we_suspect.html
There's also __RDNS_STATIC rule which excludes those static from being
considered as dynamic. There should be one for HELO rules too -
It would make me angry if I got scored more just because my server is
properly configured and uses proper helo which is the same as RDNS
(some helo checks have higher score than RCVD_HELO_IP_MISMATCH)
if your PTR is generic, then it is better to set the HELO to a
non-generic value. just make it resolve to the same IP. while it is
not always possible to set a custom rdns, there is no excuse for not
setting a meaningful HELO.
Re: HELO_DYNAMIC_IPADDR false positive
Matus UHLAR - fantomas a écrit : On 19.08.09 00:48, mouss wrote: The name of the rule is worng, but the result is ok. Instead of dynamic, I suggest: UMO for Unidentifiable Mailing Object. whether static-ip- is static or not doesn't matter. a lot of junk comes from such hosts, and we can't report/complain to a domain, since the domain is that of the SP (and getting SPs to block abuse sources have proven vain). Matus UHLAR - fantomas a écrit : I'd be glad to see if there's any difference in percentage of spam from dynamic and static (generic) IP addresses. http://enemieslist.com/news/archives/2009/07/why_we_suspect.html it says something very close to nothing. from SA point of view, the ham/spam ratio is important and that is what I am curious about... There's also __RDNS_STATIC rule which excludes those static from being considered as dynamic. There should be one for HELO rules too - It would make me angry if I got scored more just because my server is properly configured and uses proper helo which is the same as RDNS (some helo checks have higher score than RCVD_HELO_IP_MISMATCH) On 19.08.09 09:55, mouss wrote: if your PTR is generic, then it is better to set the HELO to a non-generic value. just make it resolve to the same IP. while it is not always possible to set a custom rdns, there is no excuse for not setting a meaningful HELO. I wouldn't say so. Automatic helo string is much easier to configure and requires less work than manual... Then helo is useless. but that's not what we are about: if you are smtp.google.com, then I don't care about your helo. but if your PTR is joe-192-1-2-3.example.com, then I am not very open to accept your transaction. if you do an effrot and helo with flower.example.net, then I'll give you a better treatment. said otherwise: if I reject your mail because you helo with a generic name, don't ever try to complain. first, if you can't get a custom rdns, it is _your_ problem. I might listen to you blaming your provider. but if you can't set a custom helo, then I won't listen to you at all. for the same reasons, I reject mail hosts helo-ing as localhost, *.localdomain, *.arpa, *.firewall, *.myfirwall, ... etc. It's more effective to get them fix their helo than ask the whole world to accept the junk. and this is no different than any rule in SA. I find it easier to ask an admin to fix his helo than to tell someone that the message was tagged because the subject is all caps and foo is bar and bar is foo. Yes, with current SA setting it may be true. But since we are complaining about this, this ain't an answer... I block such stuff at smtp transaction. if I get junk from joe-1-2-3-4.domain.tld, I add a rule to block this in helo check. if helo check is not enough, the rule is applied to the PTR.
Re: i need your indulgence
Dan Schaefer a écrit : Karsten Bräckelmann wrote: On Fri, 2009-08-21 at 08:06 -0400, Dan Schaefer wrote: Any ideas about this one, besides adding a score to match the subject? Probably not a smart idea, since you insist on re-using that very subject for your list post... That is incorrect. I put double spaces in the subject, because I knew someone would bring that up. :-) at a time where we search for complex obfuscations, you think we are silly to use rules that only match 1 space? anyway, the sample you showed has a score of 4.9. so adding a 0.2 rule for mail from VE would make it spam.
Re: sare channels
Gary Smith a écrit : Read the top of the rulesemporium site: http://www.rulesemporium.com/ SARE rules aren't being updated. Hence, sa-updating them is pointless. Is it still recommended to run the SARE rules? you should use 90_2tld_cf_sare_sa-update_dostech_net to avoid querying uribl for domains that will never be listed. other than that, I have stopped using the other rules after noticing that they bring nothing to my setup. now, my mail flow isn't yours and vice versa. so check for yourself.
Re: Rule PTR != localhost
Clunk Werclick a écrit : On Thu, 2009-09-03 at 01:36 -0400, Sahil Tandon wrote: On Thu, 03 Sep 2009, Clunk Werclick wrote: I'm starting to see plenty of these and they are new to us: zgrep address not listed /var/log/mail.info Sep 3 05:26:59 : warning: 222.252.239.56: address not listed for hostname localhost dig -x 222.252.239.56 ... ;; QUESTION SECTION: ;56.239.252.222.in-addr.arpa. IN PTR ;; ANSWER SECTION: 56.239.252.222.in-addr.arpa. 83651 IN PTR localhost. ... Taking to one side the various RBL's which are catching these, and not going the whole 'PTR must match' route - would it be practical to craft a 10 point rule based on PTR = localhost? Is it even possible to build a rule based upon DNS returns? Forgive the stupidity of the question, but I'm not sure how to, or even if it can be implemented? If you reject mail that scores = 10, then you could accomplish this before mail even gets to SA. Since you appear to be using Postfix, you could experiment with check_reverse_client_hostname_access, which is available in Postfix 2.6 and later. Thank you Sahil. It's a job for Postfix (when I get around to 2.6) because.. For a general primer on what you can (and cannot) do with respect to SA rules, the following page might be useful: http://wiki.apache.org/spamassassin/WritingRules this gives no hint to crafting rules on DNS status - which is as I thought, hence the question in the first instance. -- I think I have posted something on this not too long ago on the postfix list. check_helo_hostname_access hash:/etc/postfix/access_host check_reverse_client_hostname_accesshash:/etc/postfix/access_host == access_host: localhost REJECT Bogus PTR localdomain REJECT Bogus PTR .localdomainREJECT Bogus PTR .lanREJECT Bogus PTR
Re: Rule PTR != localhost
LuKreme a écrit : On 3-Sep-2009, at 15:33, mouss wrote: check_helo_hostname_access hash:/etc/postfix/access_host If but this in my smtpd_helo_restrictions (with a warn_if_reject for right now), but where in the smtpd_recipient_restrictions do you recommend putting this? check_reverse_client_hostname_access hash:/etc/postfix/access_host I was thinking about right after premit_sasl_authenticated? to avoid annoying others, it is preferable to move postfix questions to the postfix-users list. anyway: - many people (including $self) put all anti-spam checks under smtpd_recipient_restrictions. - put your restrictions after reject_unauth_destination. there is no point checking helo or other if it is a relay attempt.
Re: antispam comparison by virus bulletin
Justin Mason a écrit : In fairness, they got in touch to ask for help in setting up a more recent SA, but none of us (ie the PMC) had the spare cycles to help out. Comparative third-party tests like this always take a lot of hand-holding. We don't have the same kind of marketing budget as the commercial companies, needless to say. OTOH, I think that McAfee's Email Web Security Appliance runs on SpamAssassin, or at least it did when I worked there ;) they acquired Secure Computing. so I'd say the test involved what was called Ironmail. Did Ironmail use SA?
Re: DNSWL and JMF White false positives, what to do exactly?
Warren Togami wrote: I scanned my spam folders and found a few false positives that hit on either DNSWL FP with DNSWL? FP = False Positive = legitimaite mail tagged as spam DNSWL = Whitelist if your system adds points because of dnswl, you have a serious problem. .. or do you mean FN (false negative)? or JMF (HOSTKARMA? See how confusing it is not knowing what to call it?) Is there an easy automated way we can forward FP's to DNSWL and JMF so their maintainers can decide what to do about the offending senders? offending? then you probably mean FN. yes, you can report offending IPs, if that makes sense. for example, if the offending IP is that of an ISP relay, then don't report it: ISPs do relay spam. if on the other hand you see FNs from paypal or bank of blahblah, then do submit. I'd attach it to mail but it might get caught in the spam filter... post the s(p)ample on a web site instead. you can use pastebin for example.
Re: DNSWL and JMF White false positives, what to do exactly?
Karsten Bräckelmann wrote: On Wed, 2009-09-30 at 23:35 +0200, mouss wrote: Warren Togami wrote: I scanned my spam folders and found a few false positives that hit on either DNSWL FP with DNSWL? FP = False Positive = legitimaite mail tagged as spam DNSWL = Whitelist False positive. Something, that matches (positive) the criterion for a certain test, but should not (false). if your system adds points because of dnswl, you have a serious problem. .. or do you mean FN (false negative)? Granted, the wording (FPs that hit ham rules) could need some polish, but I believe Warren was talking about spam that falsely hits ham rules. you can certainly devise a system to detect alpha(foo) where alpha is a function mapping a Banach space to a Hilbert Space, and define what FP, FN, FX mean in the context you consider. you can also say let PI=69, ... . but conventions are here for a reason. they allow us to understand each others more easily. the fact that children of today can solve computation problems that great scientists of the old times couldn't handle is thanks to conventions (think of a/b * c/d = (a*c)/(b*d), which looks trivial today, but wasn't before). when talking about spam or intrusion detection, FN means missing and FP means false alarm. if we allow defining FN and FP differently, then we'll need to rewrite a lot of books, reports, articles, ...
Re: DNSWL and JMF White false positives, what to do exactly?
RW wrote: On Wed, 30 Sep 2009 23:35:31 +0200 mouss mo...@ml.netoyen.net wrote: Warren Togami wrote: I scanned my spam folders and found a few false positives that hit on either DNSWL FP with DNSWL? FP = False Positive = legitimaite mail tagged as spam DNSWL = Whitelist The term false-positive can apply to any test. A test for ham that matches a spam is a false-positive, it's a matter of context. spam too can be (re)defined. and actually any term. but it is assumed here that we talk about spam detection. so false negative means miss and false positive means false alarm. this is the common terminology inherited from intrusion detection. I used to have a clock that was anti-clockwise. but it was for fun. I always understood what clockwise meant.
Re: DNSWL and JMF White false positives, what to do exactly?
RW wrote: On Fri, 02 Oct 2009 00:14:52 +0200 mouss mo...@ml.netoyen.net wrote: RW wrote: The term false-positive can apply to any test. A test for ham that matches a spam is a false-positive, it's a matter of context. spam too can be (re)defined. and actually any term. but it is assumed here that we talk about spam detection. so false negative means miss and false positive means false alarm. this is the common terminology inherited from intrusion detection. The term comes from statistics, not intrusion detection. I don't know much about the latter, perhaps people in that field are a little sloppy in their usage, more likely all the tests are expressed as tests for intrusion, so the same kind of issue doesn't arise. The source of your confusion is that you are mixing-up the terminology of the overall classification and individual test results. Think of this way, in a fingerprint comparison the meanings of TP, TN, FP and FN are obvious and intrinsic to the test, it would be absurd to switch them around depending on whether it's evidence for the defence or prosecution. let's take it more easily: Please explain to me what was an FP in this thread.
Re: DNSWL and JMF White false positives, what to do exactly?
Karsten Bräckelmann wrote: On Fri, 2009-10-02 at 00:08 +0200, mouss wrote: Karsten Bräckelmann wrote: False positive. Something, that matches (positive) the criterion for a certain test, but should not (false). I stand to what I said. I'm not surprised:) you can certainly devise a system to detect alpha(foo) where alpha is a function mapping a Banach space to a Hilbert Space, and define what FP, FN, FX mean in the context you consider. you can also say let PI=69, ... . but conventions are here for a reason. they allow us to understand each others more easily. the fact that children of today can solve computation problems that great scientists of the old times couldn't handle is thanks to conventions (think of a/b * c/d = (a*c)/(b*d), which looks trivial today, but wasn't before). when talking about spam or intrusion detection, FN means missing and FP means false alarm. if we allow defining FN and FP differently, then we'll need to rewrite a lot of books, reports, articles, ... IFF you are talking about the black box that spam detection is, that is true. If you are talking about a rule like FORGED_MUA_OUTLOOK, it appears to be that simple. However, it is not. You are looking at a single test, which -- if positive -- either is correct or wrong. I understand the rationale, but I find this too abstract for common discussions. Same for RCVD_IN_DNSWL. If it positively matches, it either it is correct, or wrong. A false positive is a match, that is wrong. No matter the score you assign the test. except that it depends what the test really means. dnswl doesn't mean the listed hosts never send spam. I am happy that it lists debian list servers, Orange, ... etc. This concept is NOT specific to spam detection, or even computer science. As a matter of fact, when I first really grasped the concept, a medical scientist explained it to me. now that you say it, this is true. I too believ that medical science has precedence in this area. Yes, a FP for a rule that identifies *ham* actually evaluated positive on a spam. It only appears to be spam centric on this list, cause it is mainly dedicated to identifying spam, not ham. You might want to ask wikipedia as well. And don't focus on the spam filtering *example*, which again exclusively talks about a rule identifying spam. Not ham. my point was that in a spam oriented forum, the meaning of some words is what most of us (yes, this is hard to define) think they mean. the principle of least astonishment. anyway, I'm sorry for bringing the discussion to this sand. so I will stop here (of course, offlist is ok for any discussion, including garbage without collection:)
Re: New spamhaus list not included
RW a écrit : On Sun, 04 Oct 2009 15:53:34 +0200 Yet Another Ninja sa-l...@alexb.ch wrote: why lastexternal ? would you expect ham traffic from those IPs? and want to loose deeper header parsing? Right, although I doubt this list is going to be much use for SpamAssassin. With zen being so popular, I think everything that can be caught with it will get caught at the smtp level . well, - some people pull mail (fetchmail, getmail, ...) from servers that don't implement zen at smtp time. - some people receive mail via external relays/forwarders that don't implement zen at smtp time. - some people add some mailing list servers to their trusted net, so they may be in the situation above (relay/forwarder) With SBL you get additional deep hits from spammers hiding behind open-relays and other exploited servers, but that seems unlikely with CSS. true. they send directly, from what I've looked at.
Re: OT bad news
Thomas Mullins a écrit : We have been running Spamassassin for maybe eight years now. But, my coworkers do not like OpenSource. So they have finally complained enough that my boss is going to replace our reliable FreeBSD/Spamassassin boxes. They are planning on purchasing something that runs ON Exchange. What a bummer. and the problem is? if they want exchange, give them exchange. don't fight (directly), watch instead. take pleasure of the situation, get fun as you can. I personally took fun all day long in windows-only (and believe it or not, in linux-only) environments. that said, you can still try to explain that exchange should not be exposed to the internet. you still need a relay (such as freebsd/postfix).
Re: OT bad news
Quanah Gibson-Mount a écrit : --On Monday, October 05, 2009 11:50 PM +0200 mouss mo...@ml.netoyen.net wrote: Thomas Mullins a écrit : We have been running Spamassassin for maybe eight years now. But, my coworkers do not like OpenSource. So they have finally complained enough that my boss is going to replace our reliable FreeBSD/Spamassassin boxes. They are planning on purchasing something that runs ON Exchange. What a bummer. and the problem is? if they want exchange, give them exchange. don't fight (directly), watch instead. take pleasure of the situation, get fun as you can. I personally took fun all day long in windows-only (and believe it or not, in linux-only) environments. that said, you can still try to explain that exchange should not be exposed to the internet. you still need a relay (such as freebsd/postfix). And once exchange falls over, show them Zimbra. ;) Which uses postfix/SA/amavis, etc, and looks a lot like exchange... only better. ;) I have to chose between zimbra and exchange, I'll go for exchange. but I don't need to chose between the two. I want different components for different tasks. and for many things, I go for web oriented solutions.
Re: spam from noave.net 74.63.109.*
Steve Prior a écrit : I started getting spam that was distinctive for having two boxes - one Email Security Information and one Privacy Policy and viewing source indicated the mails came from a server at noave.net 74.63.109.*. I blocked 74.63.109.* and the spam stopped for a while, but I just got my first spam from 74.63.113.30 so it looks like they've got another block of addresses. Is anyone familiar with this outfit? Does this ISP have any legit traffic and what address ranges are assigned to them? snowshoe. block both - the domain (*.noave.net) BTW, noeave.net is listed on uribl. and - the network: 74.63.64.0/18 (74.63.64.0 - 74.63.127.255).
Re: Postfix Received header FP's and masscheck
Warren Togami a écrit : I am trying to reconfigure my postfix server to get rid of false positives in the masschecks. * I run my own postfix server at example.com. * Several of my users have IMAP accounts on my server. They send their outgoing mail via my server with SMTP-after-IMAP. This has been working fine except this causes trouble for the masschecks in cases where they sent mail to other users on my server. Their legitimate mail is triggering rules like RCVD_IN_SORBS_DUL, RDNS_DYNAMIC, and occasionally RCVD_IN_PBL because the only Received header is the delivery directly from their home IP address. * I enabled TLS with SASL authentication. This is working, but the following Received header is still triggering these rules. Received: from [XX.XX.XX.XX] (XX-XX-XX-XX.isp.example.com [XX.XX.XX.XX])(using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits))(No client certificate requested)by mail.example.com (Postfix) with ESMTP id DEADBEEF47for u...@example.com; Sun, 11 Oct 2009 02:01:37 -0400 (EDT) this header doesn't show the user was authenticated. use SASL authenticatoin instead of smtp-after-foo. if that's not possible, you'll need to cheat by altering the above header to make it look like ESMTPA. ... No, score=0.6 required=5.0 tests=BAYES_00,RCVD_IN_SORBS_DUL, RDNS_DYNAMIC,TVD_SPACE_RATIO autolearn=no version=3.3.0-alpha3-r816412 Is it possible to configure postfix to write some kind of auth message in the Received line if you had authenticated? postfix does so if you authenticated and you have smtpd_sasl_authenticated_header = yes but smtp-after-* is not authentication as far as postfix is concerned. (smtp-after-* is a hack). That said, you can add a header of your choice (with PREPEND) if you can change the map that your smtp-after-* mechanism updates for postfix. Does spamassassin and masscheck have any way to recognize such headers to know to skip that line for rule checks?
Re: Good reasons to dont use RBLs
Luis Daniel Lucio Quiroz a écrit : Hi all, Again me, Well, in the security scope i use a principle that states that you souldnt use a lower layer solution to fix a higher one. So SPAM is a Layer 7 problem that is used to fixed with a Layer 3 solution (RBL). I'd like a brainstorm to convince that a RBL solution is not the best stoping SPAM, and we should look for L7 solution such as Bayes. If someone tries to guess a working login:pass on your server and does this a thousand times in a short period, you will still let him continue because passwords are L7 and the IP address is at L3? if you want talking about principles, then defence in depth suggests using all your levels to block attacks. In short, segment your zones, your diagrams, your reports, but do not segment your defences. When you hear divide and conquer, divide the problem, not your army. you still want to coordinate your defences so as to increase their efficiency. Besides, spam is at Layer PI (3.1415) ;-p
Re: emailreg.org - pretty good white list
jdow a écrit :
[snip]
Per a discussion off the list the $20 is, as mentioned, pretty much a
captcha and as the web site declares, an inoculation against domain
tasting or 10 for a dollar .cn domains. The thousands of names
registration isn't going to get through either ReturnPath or emailreg.org.
It takes time to run through the hoops in either case. And $20k is a whole
different ballpark for dollar expense than $200.
It's not bulletproof. But it's probably worth a small negative score to
allow legitimate emails a tiny bump. Their oddball DNS poll also may be
an inoculation against emails originating from a site's hacked systems.
In as much as one Aw Shit seems to wipe out 100 Brownie Points this may
provide legitimate small businesses a quick way out of the blocked status
once they clear up their infections, sort of like awarding Brownie Points
10 or more at a time.
{^_^}
head
Can all the guys who think 20 isn't much send me 10$ each? I promise to
write a song for you.
/head
body
the problem with the 20 isn't much is if 1000 guys/groups decide to
run their whitelists and ask for 20$ (on each). then I need to pay
20*1000 = 20K USD. that's a captchoom. now, what if one million guys
start their lists...
/body
footer
and of course, for each 20$, I'll need to add the fees (unless they have
employees who can ring my bell :). and I also need to check they are a
legitimate organization, because giving money to mafia/terrorists/... is
prohibited (at least over here). etc etc etc...
/footer
Re: emailreg.org - tainted white list
Bill Landry a écrit : Christian Brel, AKA rich...@buzzhost.co.uk (among other aliases), is back... Bill he switched MUA, but forgot to switch helo and get a different IP range... Received-SPF: softfail (nike.apache.org: transitioning domain of brel.spamassassin091...@copperproductions.co.uk does not designate 82.70.24.237 as permitted sender) Received: from [82.70.24.237] (HELO styone.spampig.org.uk) (82.70.24.237) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 14 Dec 2009 16:09:40 + From: Christian Brel brel.spamassassin091...@copperproductions.co.uk Received: from [82.70.24.238] (HELO stytwo.spampig.org.uk) (82.70.24.238) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 07 Dec 2009 14:42:42 + Subject: Interesting low scoring phish From: rich...@buzzhost.co.uk rich...@buzzhost.co.uk
Re: The other side of whitelists - arbitrary blacklists
jdow a écrit : http://isc.sans.org/diary.html?storyid=7780 It can be quite frustrating to run an ISP and comply with the often arbitrary, strange, and I suspect contradictory demands of the likes of SORBS and Trend Micro. An ISP Abuse handler vents in this article. from the text, there is no way to see whether the guy is right or wrong. there is no evidence. I doubt Trend Micro _require_ smtp/mail/ they may recommend it. but they certainly accept mail from a lot of servers whose name has no smtp/mail/... in it. as for sorbs, my experience is that they will easily unlist any host that was listed by error. (I am talking about duhl). so in my opinion, this is just blah blah blah blah. and yers, it is reasonable to block ad\d+\.$domain, because ad generally means active directory, which has no business sending mail. sure, one should be free to name his mail server, but we are free to block what looks like a ratnet. this includes things like 2.3.4.5.static.example.com,however static it is. if you want to send mai in these spam days, the least we ask you is to name your server.
Re: The other side of whitelists - arbitrary blacklists
jdow a écrit : At least one well respected ninja sort from this list is also a volunteer SANS Internet Storm Cellar operator. These folks do not seem to be in the least inexperienced in the ways of malware and malware delivery. That is why I take that diary entry at face value. maybe I'm wrong, but I don't think writing on sans pages erquires much more than getting the article accepted, and those guys are good at internet security, not necessarily at internet collaboration policies. I agree he could have included more information than he did without giving away names involved. One piece of wording suggests he is an admin at a box or rack rental place such as rackspace rather than a wire rental place; and, it's customers are meeting with the problems he's expected to clear up. the problem is that he only says he is right and they are wrong, without giving us a chance to judge by ourseleves. as one of my favourite math teachers used to say toute proposition non justifée est sans valeur (translation attempt: unproven propositions have no value). I personally dislike Trend and if asked, I could spend many paragraphs insulting their stupidity. but the article seems to suggest that they require smtp/mail/... in hostnames. This is simply not realistic. they do accept mail from a lot of hosts which are not named smtp/mail/ so the author lies (by omission or whatever, but that's it). and regarding sorbs, wev'e seen a lot of attacks... the fact that the article is published at SANS says nothing to me. I personally have no idea of SANS publishing policy and process. I've seen many less than perfect SANS articles (and I'm polite not to say stupid, ...).
Re: How to tell if sa-update is actually running
clem...@dwf.com a écrit : How do I tell if sa-update is actually running? I mean, yes, I can run it by hand and get no error messages, and with -D I dont see any problems, still I feel that my stuff isnt current, and that there should be an update. Should I be getting a message in /var/log/messages? or /var/log/maillog? or /var/log/sa-update.log ??? After running, I see nothing in any of these locations, and as such, feel that something is wrong (like missing perl modules...) you can query DNS to get the version of the rules. for example: $ host -t txt *.2.3.updates.spamassassin.org *.2.3.updates.spamassassin.org descriptive text 895075 (2.3 is the reverse of 3.2, which corresponds to the SA version you use). then $ head -1 /var/db/spamassassin/3.002005/updates_spamassassin_org.cf # UPDATE version 895075
Re: How to tell if sa-update is actually running
R P Herrold a écrit :
On Fri, 8 Jan 2010, mouss wrote:
you can query DNS to get the version of the rules. for example:
$ host -t txt *.2.3.updates.spamassassin.org
*.2.3.updates.spamassassin.org descriptive text 895075
(2.3 is the reverse of 3.2, which corresponds to the SA version you
use).
Looks like 3.3 is not so behaving
[herr...@new .procmail]$ host -t txt *.2.3.updates.spamassassin.org
*.2.3.updates.spamassassin.org descriptive text 895075
[herr...@new .procmail]$ host -t txt *.3.3.updates.spamassassin.org
Host *.3.3.updates.spamassassin.org not found: 3(NXDOMAIN)
[herr...@new .procmail]$ rpm -q spamassassin
spamassassin-3.3.0-0.29.rc1
[herr...@new .procmail]$
As Kai said, use the exact version (no wildcard):
host -t txt 0.3.3.updates.spamassassin.org
you could do something like:
CHANNEL=updates.spamassassin.org
SA_VERSION=`spamassassin -V | grep -i spamassassin|head -1 |awk '{print
$3}'`
SA_VERSION_REV=`echo ${SA_VERSION} |awk -F. '{print $3 . $2 . $1}'`
REMOTE_VERSION=`host -t txt ${SA_VERSION_REV}.${CHANNEL} | grep
descriptive text|head -1|awk '{print $4}' | sed 's/\//g'`
...
although the shell isn't the best language for such tasks ;-p
note that sa-update will do all this for you. so you only need such
games if you suspect something...
Re: Faked _From_ field using our domain - how to filter/score?
Callum Millard a écrit : I'm sure there's a straight forward way of doing this, but after several of hours searching, I can't find it. The problem is spam with a faked 'From:' field. Spammers are sending e-mails to our domain with the 'From:' field set to a valid e-mail address from our domain. Here's an edited example: [snip] spammers aren't the only ones who send you mail with your address in the From: header. Mailing lists do that too. look at your email as resent to you by this list. so stop focusing on the From: header. it looks like your AWL db went mad. needs a cleanup! (I personally disable AWL).
Re: [Fwd: Delivery Status Notification (Failure)]
jdow a écrit : From: Christian Brel brel.spamassassin091...@copperproductions.co.uk Sent: Wednesday, 2010/January/13 07:40 On Wed, 13 Jan 2010 16:17:31 +0100 Matus UHLAR - fantomas uh...@fantomas.sk wrote: On Wed, 13 Jan 2010 09:39:34 -0500 Jason Bertoch ja...@i6ix.com wrote: Can a list admin disable the spamassas...@hundredacrewood.willspc.net account as we're still getting bounces? On 13.01.10 14:49, Christian Brel wrote: I found dropping the whole: 66.192.0.0/14 in iptables solved this for me :-) Seen lots of connection attempts, but hey ho I recomment not to drop whole IP ranges unless you know you need to. You can block important mail that way Not from that range I wont :-) Is it yours? Does my IP belong to your provider? it is amazing to see people complain about us droping traffic from noise sources, when they happily hide behind providers who drop mail using arbitrary measures... I did add 66.194.243.3 to my firewall config (I also added related domains to my postfix reject list). if I get more from the same range, I'll drop the whole range.
Re: [Fwd: Delivery Status Notification (Failure)]
David B Funk a écrit : On Wed, 13 Jan 2010, Jason Bertoch wrote: Can a list admin disable the spamassas...@hundredacrewood.willspc.net account as we're still getting bounces? Original Message Subject: Delivery Status Notification (Failure) Date: Wed, 13 Jan 2010 09:36:54 -0500 From: Administrator administra...@willspc.net To: Jason Bertoch ja...@i6ix.com Subject: Re: SA not picking up rules from /var/lib/spamassassin/ Sent:Wed, 13 Jan 2010 09:36:54 -0500 did not reach the following recipient(s): [snip..] Just added the following to my SA rules: # deal with borked administra...@willspc.net 1/14/10 header L_BORKED_WILLSPC From:raw =~ /Administrator administrat...@willspc\.net/ describe L_BORKED_WILLSPCBrain-Dead mail site score L_BORKED_WILLSPC 100.0 Since I run SA at my incoming MTA and SMTP reject anything with a score over 20, I don't see them anymore. ;) As far as I can tell, the major open source MTAs implement access control. so you don't really need calling SA for this. for example, with postfix: smtpd_client_restrictions = check_client_access cidr:/etc/postfix/kill_client.cidr check_sender_access cdb:/etc/postfix/killdom check_helo_access cdb:/etc/postfix/killdom check_reverse_client_hostname_access cdb:/etc/postfix/killdom == killdom willspc.net REJECT backscatter source .willspc.netREJECT backscatter source wnahosting.com REJECT backscatter source .wnahosting.com REJECT backscatter source == kill_client.cidr 66.194.243.3REJECT backscatter source yes, you can add 66.194.243.3 to your firewall kill list
Re: [Fwd: Delivery Status Notification (Failure)]
Jason Bertoch a écrit : On 1/18/2010 6:38 PM, mouss wrote: David B Funk a écrit : On Wed, 13 Jan 2010, Jason Bertoch wrote: Can a list admin disable the spamassas...@hundredacrewood.willspc.net account as we're still getting bounces? Original Message Subject: Delivery Status Notification (Failure) Date: Wed, 13 Jan 2010 09:36:54 -0500 From: Administrator administra...@willspc.net To: Jason Bertoch ja...@i6ix.com Subject: Re: SA not picking up rules from /var/lib/spamassassin/ Sent:Wed, 13 Jan 2010 09:36:54 -0500 did not reach the following recipient(s): [snip..] As far as I can tell, the major open source MTAs implement access control. so you don't really need calling SA for this. This is an list administration problem, not something that every poster here should have to fix locally. Unfortunately, that's only partially true. - if the problem is at the MTA side, then it will show again and again, with many different subscribers. In this case, the MTA operator should fix the problem. and if this doesn't happen, then he should be considered as part of the problem: blacklist the operator. - if the problem is in the user config, then yes, unsubscribing him will help, until he subscribes again (possibly with a new address). That said, I agree that the user should be unsusbcribed. But that's not always easy: the bounce doesn't necessary tell the subscriber (when mail is forwarded, you get the bounce for the forwarded-to address...). and VERP doesn't help here since the borked setup sends the bounce to the From: header. (one solution is to send mail with a VERP FROM: header to detect which one causes the bounce)... sigh!
Re: MTX plugin functionally complete? Re: Spam filtering similar to SPF, less breakage
dar...@chaosreigns.com a écrit : On 02/13, Matus UHLAR - fantomas wrote: So the only effect of MTX should be confirmation that a machine may send mail? Yes. So why the complicated check for DNS record combining DNS name and IP? Why not simply requesting that machine has a mail or smtp in its DNS name? I answered that recently. (I need to state that such a method would require a full circle DNS check. Not a problem) 1) I am not comfortable requiring people to modify existing host names to participate. fully agreed. an IP is not necessarily dedicated to mail, so there is no reason to force people to put mail in it. and snow shoe spammers already use names that people want... 2) Probably more importantly, I am concerned about the possibility of spammers tricking DNS maintainers into giving them such host names. These two problems are handled by http://tools.ietf.org/draft/draft-stumpf-dns-mtamark/draft-stumpf-dns-mtamark-04.txt which was recently mentioned by Justin Mason. The advantage MTX has over mtamark, which I believe is important, is that MTX ties the spam to a domain name, which is tied to a registrar, which can be subpoenaed for the identity of the spammer. mtamark leaves the spam still only tied to the transmitting IP, which I believe is less convenient to track. Especially given IP hijacking via BGP. Nasty. did you take a look at CSA http://mipassoc.org/csv/draft-ietf-marid-csv-csa-02.txt it uses an SRV record instead of the so-much-abused reverse dns hack. Anyway, such approaches are only helpful if widely adopted. otherwise, the overhead is not worth the pain. At this time, just register your IP in DNSWL.
Re: Rewriting header fields help please
Brian S. Meehan wrote: Hi, There's the option rewrite_header Subject in the local.cf file, however, I've been observing when looking through the spam folder that sorting by subject is more helpful when looking for incorrectly caught emails since many emails often have the same subject and different from fields, including the display name and the email address. Upon seeing that, I decided it might be more beneficial and easier to read if the From display name were to be rewritten so I changed it to: rewrite_header From ***SPAM(_SCORE_)*** While this works, it only works when there is no display name: examples: header field from email in spamfolder that shows Gary A. Gray: From: (***SPAM[36.1]***) Gary A. Gray [EMAIL PROTECTED] header field from email in spamfolder that shows ***SPAM[36.1]***: From: (***SPAM[36.1]***) [EMAIL PROTECTED] The difference is obviously the quoted name. I tried using: rewrite_header From ***SPAM(_SCORE_)*** (note the quotation before the asterisks) but that didn't yield different results nor did using an ending quotation. On ones that work, it shows up while reading the email as: From: ***SPAM[36.1]*** [EMAIL PROTECTED] Is there any way I can rewrite the From field to display the spam score while keeping the sending email address as in the one that works just above? It is ill advised to alter headers in general, and address headers (from, to, ...) in particular. rfc822 address parsing is not trivial. you'd better not touch it. I personally don't like subject tagging, and prefer using a Junk folder instead.
Re: Q about mail proxy servers and setups
Michael Scheidell wrote: Sometimes a large company will have a proxy server set up in the DMZ and then send it to their internal mail server. I understand that ideally, the proxy server would be replaces with a SpamAssassin/MTA setup. However, sometimes, client, security and company policy needs outweigh logic. You are free to do whatever your policy dictates, as long as this introduces no nuisance for others. your freedom stops where that of others starts. I can think of several things this might break, depending on if you count that proxy server as an internal/trusted server. #1, SPF. SPF helo, SENDERID The proxy will be adding a received header, and announcing 'HELO/EHLO' using its own name, not the senders. (please no bitching about SPF) #2, many blacklists that depend on the last received header (the proxy will normally put on in) These are easily solved by correctly configuring trusted_networks. For Amavisd/others that use p0f, all we get is signature of the proxy. Smtp ratelimiting, greyisting, even recipient verification break. You can't drop the SMTP session when the sender sends you an email with a bad address, the proxy has already accepted it. You can't use 4xx errors in your policy server to do greylisting on policy blacklisting because you are sending the 4xx error to the proxy. If mail is accepted at the edge of the network, it can no more be bounced. backscatter is no more acceptable. if you can't block invalid mail at the edge, then you have a choice between: 1- deliver to someone that will check whether the message is legitimate, and the sender was not forged. inform the company/customer/... that when someone mistypes the boss address, the possibly sensitive message is read by an employee. 2- silently discard. inform the company/customer/whomever that their mail system is not reliable and may discard mail without notice. and BTW, tell the boss to buy more hardware to cope with a queue of invalid recipients mail... a better alternative is to tell all users to open an account at gmail, yahoo, ... This may not look professional, but it will at least avoid polluting the mailboxes of the rest of us. On amavis, if we use MY_NETS policy, and we put the proxy ip in the 'localnets', it will spam the spam and virus contact address on every email from the 'local network'. If you don't put it in there, it breaks some of the things I mentioned above. Anything else I missed? Any solutions other then take the proxy server out and replace it with the SpamAssassin/MTA combo?
Re: Forwarding and spamassassin...
James Lay wrote: On 9/23/07 8:53 AM, mel goldberg [EMAIL PROTECTED] wrote: I¹m new to the list, apologize in advance if I should be posting this somewhere else. I am attempting to SPAM filter and forward from my server to another. Spamassassin filters but the server will not forward. Has anyone found a way to do this? Sounds like you¹ll need to determine what MTA you¹re using (postifix, This one is not yet available. but you can use (the excellent) postfix in the meantime:) sendmail, etc..), read some docs and post to that group. Hope that helps. James
Re: OT - massive newsletter
mizzio wrote: hello everybody, I apologize to ask an off-topic question, and feel free to point me to any other resources on the net. I'm setting up an SMTP server (centos + qmail) on a dell quad core machine for sending out a periodic newsletter (10 millions a month). In order to avoid any possible blacklisting problem, I'm looking for all the best practices. Right now I've set up: - Dedicated public IP address - Dedicated domain and MX record with correct reverse resolution. I'm looking into in SPF but I have no experience on this. 1- do not subscribe an address unless it is verified: you must send a message to the address, and the owner must reply. the confirmation message must contain something unique so that nobody can guess and send a forged reply. The thing is that: you must _guarantee_ that the _owner_ of the mailbox wants to get your mail. 2- you must remove addresses that bounce (after some number of bounces for instance). 3- you should re-ask for confirmation after some time (people do quit jobs and get replaced). once a year should be a minimum. 4- users must be able to unsubscribe via mail _and_ via the web, whatever they prefer (the reason is that if an address is no more used as sender, the user will find it hard to unsubscribe via email). 5- the web unsubscription form should not result in an error. This may happen, but if it happens too often, it is a sign of a fake form. same goes for unsubscription by email. 6- accept all valid email addresses. For example, '+' is a valid character in the local-part (actually, almost all characters are valid if escaped). 7- accept mail to postmaster and abuse. and accept mail from the null sender address. 8- use a valid address in the From and Reply-To headers. don't use [EMAIL PROTECTED] 9- send valid mail. This includes correctly encoded headers (all headers are ascii. no accented letters unless encoded according to the MIME specification). 10- the machine that sends mail should have a meangful reverse DNS, and it must match (IP - name - ip should return the original IP). the helo name should match this IP (helo - ip should yield the IP of the machine). Ideally, use the same domain for: sender, reverse dns and helo. This will help you get a reputation. at gmail, this is enough to get you a best-guess SPF. 11- implement SPF (only allow very few addresses). while I don't care for SPF for general use, I think it is good in the case of mass mailers. otherwise, miscreants may nuke your reputation. and if you send mail to hotmail, you'd better have SPF. SPF is trivial. see the wizard at openspf.org. 12- implement DKIM. exceptionally if you deliver to gmail and yahoo. with postfix, look for the dkim milter. 13- fill in the forms at large mail providers (yahoo, ...).
Re: OT - massive newsletter
Kris Deugau wrote: Ralf Hildebrandt wrote: * Randal, Phil [EMAIL PROTECTED]: If you don't want to annoy a lot of people your spamming (oops, newsletter sending) software needs to deal with NDRs back from recipient's domains and either put their subscription on hold after a small number of failures or automatically cancel them. There's nothing worse than mailing lists which keep sending to non-existent recipients. amen to that! Thirded. There's a newsletter that some of my spamfilter customers want to get, and others want blacklisted, that doesn't *accept* mail from the SMTP null sender. Period. I may start bouncing the postmaster notices *I* get to deal with to their postmaster@ along with a complaint about their RFC-violating behaviour. with postfix, you can use check_recipient_access with smtpd_restriction_classes to implement per recipient access controls. This may allow you to accept the newsletter (client ip and/or sender) only for those customers who want it. ... I'd drop them in a deep dark hole (/dev/null feels about right) if there weren't customers that actually *want* to receive their glop. :/
Re: Q about mail proxy servers and setups
Michael Scheidell wrote: -Original Message- From: David B Funk [mailto:[EMAIL PROTECTED] Sent: Monday, September 24, 2007 12:07 AM To: Michael Scheidell Cc: users@spamassassin.apache.org; Amavis-Users Subject: RE: Q about mail proxy servers and setups On Sun, 23 Sep 2007, Michael Scheidell wrote: For the purposes of this discussion, the biggest reason I can't be on the edge where Id like to be is that there is a massive proxy/load balancer/failover device that does more than email. Many firewalls 'proxy' the email also, so its not like you can take it out. Is there any chance you can talk them into running a -transparent- SMTP proxy rather than a SMTP relay? It acts more like an ISO layer 2 bridge (but specific to SMTP traffic) so not to disturb the contents. As you might suspect, one of the IT people at this company who has been there 20 years wrote the thing. I tried. That was my first suggestion. That would fix graylisting (which I don't do), not important. but see below. fix SPF an SPF HELO, and SENDER ID, if the proxy adds the righht Received headers (the same way postfix and sendmail would do), there should be no problem if you configure trusted_networks and internal_networks (thanks to matus for the reminder). blacklisting, tarpitting, etc. MIGHT fix p0f, but don't know. I am going to write up a whitepaper on why NOT to put an anti-spam/MTA behind a proxy, cite all relevant, good suggestions and send it to them. it really depends on whether you can add a box before the proxy to implement blacklisting and other things. (but if the proxy needs the client IP, some work is needed. so it's a budget question).
Re: Marc: use SPF to prevent backscatter? Was RE: [AMaViS-user] Q about mail proxy servers and setups
Michael Scheidell wrote: One thing I would like to see (and this is a different subject: Marc: take note: Id like to NOT BOUNCE an email back to the victim of backscatter if they bothered to publish SPF or SENDER ID records that don't match the incoming. It's the other way around. you should only bounce if you can be sure the sender was not forged. So, if there is no SPF record, or if the SPD record allows the whole universe (or a significant part of it:), then you must not bounce. anyway, SPF penetration is too low to change anything to the problem here. same for DKIM for now. (and, yes, this would NOT work behind a proxy) I would like the proxy to at LEAST have a copy of the valid userlist, This would be a good start. NOT muck with the headers. MAYBE do its load balancing via bridging rather than store forward. this is not easy to do: - most IP stacks do not allow you to bind to an external IP. so you would need adding dynamic NAT routes (and even this is not that simple, because you need different NAT rules for different connections, so you the proxy needs to bind to a port before adding the NAT rule and before doing a connect()). - in any case, the proxy needs to be modified (in a modified stack, it would just bind to the client IP. in a standard stack, it should do the above). - the final server must route back packets through the proxy machine, probably with a default route. but then you must ensure no host that is not routed this way will not connect to the proxy (there's no conference in TCP). - any intermediary routers/gateways/... should keep this traffic going between the proxy and the final server. it would certainly be easier to modify the proxy to fix the real problem than try to convert it into a bridging proxy (I don't like transparent proxy term: there are many levels of transparency). That might fix a lot. But then again, it would be easier to replace the proxy than fix it. yes. fixing problems introduced by legacy applications is often harder than solving the real problems (and getting rid of the legacy apps)... Unfortunately, there's much feeling and confidence issues when trying to convince the customer to take another road (and sometimes, the customer representative will resist the change because he did not suggest it, or because he can no more justify a lost budget).
Re: Discarding RBL-Mails, forwarding others
Dietmar Braun wrote: DJM http://www.postfix.org/postconf.5.html#always_bcc Hm, I tried that, but it doesn't work, because it the configuration should be dependent of the recipient domain... [please ask on the postfix users list, instead of here] then you should say what exactly you want to achieve. we could spend a month at guess games. consider using recipient_bcc_maps. if by forwarding, you mean redirecting (and not sending a copy), then use virtual_alias_maps. Tuesday, September 25, 2007, 2:15:54 PM, you wrote: DJM http://www.postfix.org/uce.html#smtpd_client_restrictions Additionally, this rejects RBL listed mails - but I want to discard them to /dev/null... This is a _bad_ idea. not only will you be wasting resources reading data that you want handle, but you run the risk of discarding legitmate mail. (note that reject != bounce). you can use rbl_reply_maps to set the reply code to 421 so that postfix closes the connection. only use this for those RBL that list zombes (spamhaus pbl). otherwise, you'll need to watch your logs for retries from MTAs and explicitely reject them. Please understand that this is not SA related. so followup on the postfix users list.
Re: looking into spamassassin mail proxy solution
tuxbeagle wrote: Thanks, Knowing what to search for helps. The first document I started reading has an installation where spam is filtered to a specific user 'spammy'. I hope that there is a way to just tag the spam in the header and let the user filter locally. visit the postfix and amavisd-new sites and start slowly, one step at a time. those big bang howtos available won't do you good if you have no idea what they are for. when configuring amavisd-new, look in the config file, and make sure D_PASS is used for spam (not for viruses. you don't want to deliver viruses, whether tagged or not, because MUAs may execute them anyway). setting postfix is not difficult, but you need to have some understanding of how email works (this is true whatever MTA you use). some level of discipline (call it process if you prefer buzzwords): change things incrementally, test, commit (a backup is enough, or just document the changes and things you discover), move to the next step, ... etc. In any case, big bang approaches sometimes work, but not always as intended...
Re: A belly laugh is a *good* way to start the day
John D. Hardin wrote: Has somebody subscribed paypal customer support to the SA list? This highly amusing form letter just dropped into my mailbox... (Yes, it *was* received from a paypal MTA.) either that, or somebody is forwarding mail to them. yet another broken auto-responder: it doesn't show headers so we know what they got. in its absence, I'll just believe they auto-respond to the From header address (instead of envelope sender). sigh...
Re: Discarding RBL-Mails, forwarding others
Dietmar Braun wrote: Wednesday, September 26, 2007, 12:12:13 PM, you wrote: m then you should say what exactly you want to achieve. we could spend a month at guess games. I think I said all you have to know - the one missing was just the domain dependent thing. Additionally, this rejects RBL listed mails - but I want to discard them to /dev/null... m This is a _bad_ idea. not only will you be wasting resources reading m data that you want handle, but you run the risk of discarding legitmate m mail. m (note that reject != bounce). I know that. In this case, it's ok because it is a 100% spamtrap domain. I'm not sure I understand your goal. do you really want to not reject (421 or other) such mail at smtp time for some reason, or you don't care if it's a reject or a discard? do you want to discard so that client thinks the message was delivered (so it won't retry)? m you can use rbl_reply_maps to set the reply code to 421 so that postfix m closes the connection. only use this for those RBL that list zombes m (spamhaus pbl). otherwise, you'll need to watch your logs for retries m from MTAs and explicitely reject them. m Please understand that this is not SA related. so followup on the m postfix users list. Since I know Postfix quite good, I think this cannot be done with Postfix features - you will need to expand it with SA and perhaps procmail. postfix has DISCARD action that you can use after SA. you can for example let SA add its headers, and in the after-the-filter postfix, use header_checks to looks for SA headers and discard mail if a match is found.
Re: New domains
Jonas Eckerman wrote: (The idea below is not mine, someone else (I'm sorry, but I forgot who) wrote about it here (I think) before.) Giampaolo Tomassoni wrote: brand-new domains, Something that could work for this without the problems inherent in using whois or registry databases is to simply check how long ago a domain was first seen beeing used for sending mail or in URIs in mail. (People might allready be doing this locally, but doing it centralized could work better.) A specialized DNS server could be done for this. It'd work something like this: 1: It receives a query. 2: It checks in it's database. 3.a, found in database: * Return result indicating how long ago domain was added. 3.b: not found: * Adds the domain to the database. * Return result indicating new domain. (It might be a good idea to also save last queried time for each domain (meaning 2.a will need to update the database) in order to be able to clean out domains that hasn't been seen for a long time.) In order to be effective, such a DNS list must be used by a lot of different systems spread all over the world and used by different type of organizations. It will also take time time until it can be used in an effective manner, so enough people would have to be using it for some time with very low scores just to seed it. Wouldn't this be reinventing /etc/hosts? I mean, if you list all domains, you end up with a huge database... or am I missing something? I could probably throw together a proof-of-concept DNS thingy in perl for this, but I don't have the hardware to host it for production use, nor the time to do it properly (perl would probably not be the best language to do it in). The best way might be to actually implement this in an existing DNS-list server, so it could be seeded thorugh queries fopr that list. If, just as an example, SURBL did this, the list would be seeded by all systems allready using SURBL lists, and the results could be included in multi.surbl.org. (Please not, I have no idea if implementing this in SURBLs DNS system is feasible in any way (wr to software, hardware, lunch breaks, or whatever), it was just an example.) Regards /Jonas
Re: SSO's RHSBL
Giampaolo Tomassoni wrote: -Original Message- From: Micah Anderson [mailto:[EMAIL PROTECTED] Sent: Monday, October 08, 2007 6:30 PM Well, it may be, but I believe it is not more than a week I'm getting these log entries. This is right, these error only started showing up last week in the logcheck logs of a system that was still setup to use that rhsbl. Does anyone have a legitimate reference about it being closed down? Since I'm one who really knows what I'm doing, I *guess* it is [EMAIL PROTECTED] (I got it here: http://www.aboutus.org/SecuritySage.com), but it could even be a spamtrap... It's not a trap. see http://posluns.ca/ Their (his?) official site www.securitysage.com doesn't even report an e-mail address. The corporate site http://www.sso.ca/resources/rhsbl.html doesn't give answers either.. Should I go to risk my mailbox blacklisted by BLs? :) Or someone of us got a better securitysage's contact e-mail? Giampaolo Micah
Re: Advice on MTA blacklist
Chris Edwards wrote: On Tue, 9 Oct 2007, Jo Rhett wrote: | Both Crackberry and Verizon force you to use their mail servers. Some other | data providers are now doing transparent proxy on outbound e-mail. In short, | the user can't always control that. True, to an extent. I don't know about the *berry, but imagine/hope that verizon allow encrypted SMTP-AUTH out on the appropriate alternate port (465/587). Do they ? mobiles are special (and *berry servers can be whitelisted if you need that). but in the desktop domain, blocking 587 is plain silly. and even if done, nothing prevents you from using an other port, say 10587. an no, there is no universal proxy (people find it hard to proxy known multi-channel protocols. how about proprietary ones ;-p). However, even assuming your user *is* using the *berry server or the verizon transparent proxy, then mails they send will in the main emerge from a legit mail server run by grown-ups, which is far far less likely to be blacklisted then a user sending direct from a hotel connection or mobile dynamic IP etc etc. agreed. I would also add that putting mail in a quarantine (be that a Junk folder) doesn't help much if the said quarantine is so full of junk that the recipient doesn't check it. and in this case, it is worst because mail just disappeared (with an smtp reject, the sender has a chance to notice, and maybe do something). So rejecting some spam at SMTP time helps keeping the quarantine/Junk_folder usable.
Re: Advice on MTA blacklist
R.Smits wrote: Jeff Chan wrote: Quoting Richard Smits [EMAIL PROTECTED]: Thanks for all the advice.. I think we will be using spamhaus. I am running a test and it blocks a lot of spam. Currently I use the sbl.spamhaus and pbl.spamhaus Is this wise, or should I also use the xbl and switch to zen.spamhaus? Please do not use the individual Spamhaus lists at the MTA level. Please use zen.spamhaus.org Cheers, Jeff C. Hello, Why not ? We use : sbl-xbl.spamhaus.org now. It does not include the PBL (policy Block List) We serve a big university and we cannot afford False Positives. I can imagine that someone one the PBL (home user) runs a small mailserver and cannot connect to our server ? do you consider it an FP if their ISP blocks port 25? If they really run a normal MTA, and if that is authorized by their ISP, then they should ask to be unlisted. (They should also get a meaningful reverse DNS so that they can be identified). Otherwise, they should relay via their ISP... Or am I seeing trouble that is not there :-) I do not know the PBL as good... but I like the idea. Greetings... Richard
Re: Advice on MTA blacklist
Leon Kolchinsky wrote: Hello, Which spam blacklists do you use in your MTA config. (postfix) smptd_client_restrictions Currently we only use : reject_rbl_client list.dsbl.org We let spamassassin fight the rest of the spam. But the load of spam is getting to high for our organisation. Wich list is safe enough to block senders at MTA level ? Spamhaus, or spamcop ? I would like to hear some advice or maybe your current setup ? Thank you for any advice we can use . Greetings Richard I'm using reject_rbl_client zen.spamhaus.org, reject_rbl_client safe.dnsbl.sorbs.net, reject_rbl_client list.dsbl.org, and zen.spamhaus.org filtering about 98% of all rbl rejects. You can't count like this. because what is rejected by zen is not checked against the other two. changing the order of the checks will give you different numbers. the only way to get real numbers is to put warn_if_reject reject_rbl_client $list1 warn_if_reject reject_rbl_client $list2 warn_if_reject reject_rbl_client $list3 before the actual rejects. This way you can count the reject_warning log lines. now this means more lookups (you will lookup all the DNSBLs, instead of stopping at first listing).
Re: Advice on MTA blacklist
David B Funk wrote: Jo you didn't read Chris's statement closely. A conscientious mail server administrator will configure the SERVER to -ONLY- accept encrypted connections for SMTP-AUTH transactions; the server should enforce the encryption requirements. This is a religious war declaration or what? ok, let me see what I can say ;-p grin A conscien-something admin knows that as is always the case with encryption, security depends on the implementation (code, environment, random number generation, ...) and not on the specification. For example, a conscien-something admin knows about thing like this: http://www.henlich.de/moz-smtp/ A conscien-something knows that linking a large library like openssl in an otherwise quite safe MTA adds more opportunities for system compromise. A conscien-somthing admin prefers to be an open relay than a zombie. A conscien-somthing admin knows that it is possible to protect logins without TLS (if data protection is needed, PGP and S/MIME provide this end-to-end, something that no server $thing can provide). sure, not all clients support (secure) authentication methods. but same goes for STARTTLS (and don't tell me about the obsolete smtps, because conscien-seomthing admins don't implement obsolete things). A conscien-something admin knows that unless client certificates are used, starttls doesn't help against dictionary attacks performed from botnets (so you can't just block one IP). the same admin knows that deploying client certificates and/or assisting their users does not come from free, unless they work in a givernment organization financed by public taxes (but even then, a conscien-* admin won't spend people's money so frivoulously). A conscien-something admin knows that the private key is somewhere on the system, and that protecting it does not come for free. And of course, a conscien-something admin can setup an IPSec/ssh/* tunnel and not care about STARTTLS at all, ... and still feel consciencious. but maybe not. maybe he should still enforce STARTTLS? Come on... /grin TLS is nice, but... Thus it does not matter what the client wants to do, the server should not let the client continue the SMTP-AUTH transaction until it has completed the STARTTLS operation (or in the case of SMTPS, it's already encrypted). Back to Skip's question, possibly the easiest way to solve his problem would be to run two SMTP servers, one on port 25 with full spam/AV scanning for regular mail traffic, one on ports 587 645 with SMTP-AUTH/TLS for his users' clients to submit messages, on that one have AV scanning and possibly limited spam scanning. Fully agreed.
Re: 8bit encoding in mail header by SpamAssassin
Mark Martinec wrote: This is not a default behaviour, normally such errors in header are only flagged/logged as a warning, but a message is delivered nevertheless. There is no particularly good reason to block such messages, but you can if you want to. In countries like here, that would block some mail (subject not encoded), mostly from broken webmail implementations (Roundcube used to have this bug). I guess similar problems are seen in other countries with accented letters...
Re: Deleting Spam (Linux Procmail)
Matus UHLAR - fantomas wrote: On Thursday 11 October 2007, Mark wrote: I'm new to the list, so I hope this is the right place. I am running my mail through procmail and separating my spamassassin into 3 groups depending on score: X-Spam-Status: Yes, score=[2-9][0-9] X-Spam-Status: Yes, score=[0-9][0-9] X-Spam-Status: Yes I reason that this must be in order of confidence. I have found that the first group (score=20) contains more than half of my spam. The last group (score10) contains about 1/10 of the spam. Would others agree that I can safely get procmail to trash the scores higher than 10? On 11.10.07 05:23, Gene Heskett wrote: I've been sending that stuff to /dev/null at 7, no false hits so far according to the procmail.log. My bayes is fairly well trained. We (ISP I work for) had complaints when the messages scored over 7 were refused. I have even seen some messages that could be taken as false positives scoring a 11. However I take refusal with score over 10 as safe. Some people just have to fix their submission agents (usually PHP scripts who don't care about proper encoding and splitting lines) refusal (at smtp time) is ok. but OP is about discarding. This is generally less acceptable. If it's one's mail, then one is free to do whatever he wants. but if it's other people's mail, he should ask them (after explaining the risks).
Re: Can't locate Net/DNS/RR/PTR.pm in @INC
Jose Mario Pires wrote: Hi, Please excuse me if this isn't the appropriate place to report this issue and asking for help. I have installed the last available version of Qmailtoaster and things apparently are all OK. It has some hundred email accounts and processes thousands of emails daily, rejecting many of them of spam and marking others as such. However, the logs os SA (in /var/log/qmail/spamd) show plenty of the following error: error: Can't locate Net/DNS/RR/PTR.pm in @INC (@INC contains: ../lib /usr/lib/perl5/vendor_perl/5.8.8/x86_64-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.8 /usr/lib/perl5/ 5.8.8/x86_64-linux-thread-multi /usr/lib/perl5/5.8.8 /usr/lib/perl5/site_perl/5.8.8/x86_64-linux-thread-mul ti /usr/lib/perl5/site_perl/5.8.8 /usr/lib/perl5/site_perl /usr/lib/perl5/vendor_perl) at (eval 1273) line 3, GEN400 line 89 (the number sufix of GEN* has a couple of variants, like 402,404, 408, 22, etc.) I have checked that Net/DNS/RR/PTR.pm exists in /usr/lib/perl5/site_perl/5.8.8/x86_64-linux-thread-multi (one of the directories in @INC), so I can't figure out what is happening. maybe a chroot problem? I am using OpenSuse 10.2 and I have compiled the CPAN libraries from the sources that I downloaded from http://www.cpan.org/ back in early July-2007. Any input is welcome. Regards, Jose Mario Pires
Re: unsubscribed
Rob Sterenborg wrote: Steve Ingraham wrote: I cannot help but comment on this post. Neither can I. I am one of those ignorant people that is subscribed to this list (along with several others) for the purpose of asking questions of you experts out there because I do not fully understand how it is working. By all accounts everyone of you out there would label me as a novice. The truth of the matter is I am a novice. As the saying goes; I know enough about this stuff to be dangerous. Sorry, but this is the SpamAssassin list and the subject has nothing to do with how it's working. If the OP had a question about how it's working, he'd get an answer - I'm quite sure of that and I think you know that. This specific thread has become a rant because the OP did not show that he searched for himself first on how to do something simple: unsubscribe from this list. If he put the least effort in finding information on how to do that (how hard can it be to just go to the SA website and click Lists to find the info?), he wouldn't have sent the email that started all this. A lot of people don't see the difference between [EMAIL PROTECTED] and [EMAIL PROTECTED] (replace owner by unsubscribe, admin', 'request, ... depending on the list). They think these are the same addresses. you can't blame them, really. nasty idea for someone to post, he must subscribe, then unsubscribe, then resubscribe. only then can he post a message. Unfortunately, even this won't work (besides annoying us with an N steps procedure) as people will anyway forget... /nasty I have already seen message saying Please help me unsubscribe from your group...blah blah, and this was a reply to to group message, which signature contains the procedure to unsubscribe! (so if the guy just read the message before hitting the send button...). In short, he quoted a message that responds to his question. but if people were to search for information effectively, they wouldn't buy from spammers, and that alone would reduce spam! What I would like to say by posting this is; why don't all you experts out there relax a bit? I, for one, acknowledge your superiority over me in this spam stuff. I don't think this has anything to do with anyones superiority in this spam stuff (certainly not mine as I'm not). This has something to do with willing to take the effort and finding things out for yourself instead of just doing something and bother others with it (well, in this case it would be bother I suppose). Grts, Rob
Re: spam scores for reverse DNS
YMGT wrote: Hi Guys, I am sending two emails from the same system. One of these emails is giving me extra spam penalty scores for failed reverse DNS tests. The header of that email is: I have no idea what these REVDNS_* rules come from. can you grep your config files to find them? === Return-Path: [EMAIL PROTECTED] Received: from gate9.gate.sat.mlsrvr.com (gate9.gate.sat.mlsrvr.com [192.168.1.34]) by mail7a.mail.sat.mlsrvr.com (SMTP Server) with ESMTP id ECE301B4002 for [EMAIL PROTECTED]; Thu, 18 Oct 2007 02:05:55 -0400 (EDT) Received: from gate12.r4.iad.mlsrvr.com (iad3.emailsrvr.com [207.97.227.217]) by gate9.gate.sat.mlsrvr.com (SMTP Server) with ESMTP id DE6E1590007 for [EMAIL PROTECTED]; Thu, 18 Oct 2007 02:05:55 -0400 (EDT) X-Virus-Scanned: OK X-Spam-Flag: YES X-Spam-Score: 8.112 X-Spam-Level: X-Spam-Status: Yes, score=8.112 tagged_above=-100 required=6 tests=[BACKUP_MX=2.801, HTML_MESSAGE=0, HTML_MIME_NO_HTML_TAG=1.052, MIME_HEADER_CTYPE_ONLY=0.856, MIME_HTML_ONLY=0, RDNS_NONE=0.1, REVDNS_1=1.801, REVDNS_2=0.501, URIBL_DNSBL_BLAGR3=1.001] X-Connected-To: mx2 X-Originating-Ip: [IP Address] Received: from 120400-www.myDomain.com (myDomain.com [IP Address]) by gate12.r4.iad.mlsrvr.com (SMTP Server) with ESMTP id 51BC8528221 for [EMAIL PROTECTED]; Thu, 18 Oct 2007 02:05:55 -0400 (EDT) Received: from 120400-www.myDomain.com (localhost [127.0.0.1]) by 120400-www.myDomain.com (Postfix) with ESMTP id 57EBF9C4FE for [EMAIL PROTECTED]; Thu, 18 Oct 2007 01:05:10 -0500 (CDT) DomainKey-Signature: a=rsa-sha1; h=Received:To:Subject:From:X-Sender:Content-Type:Message-Id:Date; b=Bfv4c7y2sMiczJdFcpTHnHTMff26yM18Ua2IE1BKjimaUCA+6CBaBL69uQfH93/cYVRQVuRLYP6Zm++BrYaOFJ8XZB2Mmp8aGzN8vJxZ2ozFsw7kRbe3Byjb7IpOD8UggLPgyr6zh3g1uL5OLKFruzOkY/I5PdtEkwbNO35mKSg=; c=nofws; d=myDomain.com; q=dns; s=private Received: by 120400-www.myDomain.com (Postfix, from userid 48) id 556929C4FF; Thu, 18 Oct 2007 01:05:10 -0500 (CDT) To: [EMAIL PROTECTED] Subject: [SPAM] Your MyDomain.com Account Information From: MyDomain.com [EMAIL PROTECTED] X-Sender: [EMAIL PROTECTED] Content-Type: text/html; charset=iso-8859-1 Message-Id: [EMAIL PROTECTED] Date: Thu, 18 Oct 2007 01:05:10 -0500 (CDT) === However, the other email is passing the tests with no issues, and the header of that email is: === Return-Path: [EMAIL PROTECTED] Received: from gate4.gate.sat.mlsrvr.com (gate4.gate.sat.mlsrvr.com [192.168.1.29]) by mail7a.mail.sat.mlsrvr.com (SMTP Server) with ESMTP id 39C6B1B4002 for [EMAIL PROTECTED]; Thu, 18 Oct 2007 02:55:24 -0400 (EDT) X-Virus-Scanned: OK X-Spam-Flag: NO X-Spam-Score: 2.909 X-Spam-Level: ** X-Spam-Status: No, score=2.909 tagged_above=-100 required=6 tests=[HTML_MESSAGE=0, HTML_MIME_NO_HTML_TAG=1.052, MIME_HEADER_CTYPE_ONLY=0.856, MIME_HTML_ONLY=0, URIBL_DNSBL_BLAGR3=1.001] X-Originating-Ip: [IP Address] Received: from 120400-www.myDomain.com (myDomain.com [IP Address]) by gate4.gate.sat.mlsrvr.com (SMTP Server) with ESMTP id A34CA590007 for [EMAIL PROTECTED]; Thu, 18 Oct 2007 02:55:23 -0400 (EDT) Received: from 120400-www.myDomain.com (localhost [127.0.0.1]) by 120400-www.myDomain.com (Postfix) with ESMTP id 7AE6F9C5D9 for [EMAIL PROTECTED]; Thu, 18 Oct 2007 01:55:23 -0500 (CDT) DomainKey-Signature: a=rsa-sha1; h=Received:To:Subject:From:X-Sender:Content-Type:Message-Id:Date; b=LH1gaqzjo4BhTm/1Sem4cWDvP7MXYnBStPc5vn5zet4A6jwLDKruEvZ5byPJF3PgY4QEcKoxjZf+blbzQm0v/8ZfOIu79MDn6cDAEvYlKYxmYDiPLb8597uaCPE374P8BQ3Ex5GDoRGvEI1Zlin6KD6evzpAdlc5N+v8p5EEI94=; c=nofws; d=myDomain.com; q=dns; s=private Received: by 120400-www.myDomain.com (Postfix, from userid 48) id 792609C5DC; Thu, 18 Oct 2007 01:55:23 -0500 (CDT) To: [EMAIL PROTECTED] Subject: Your Employer Account on MyDomain.com From: Yasmin Musmar [EMAIL PROTECTED] X-Sender: [EMAIL PROTECTED] Content-Type: text/html; charset=iso-8859-1 Message-Id: [EMAIL PROTECTED] Date: Thu, 18 Oct 2007 01:55:23 -0500 (CDT) === Both emails are sent from the same server with the same reverse DNS settings. Would you know why we are facing this problem with one of the emails and not the other? And how can we solve that and pass the reverse DNS tests?
Re: Disabling URIDNSBL plugin
Micah Anderson wrote: * Daryl C. W. O'Shea [EMAIL PROTECTED] [071019 14:59]: Justin Kim wrote: I don't know what is causing my postfix server to defer messages couple of times daily. By looking at the logs, I can only tell there is something that keeps one spam checking process running for 5~10 mins. Likely bayes auto expiry. Disable bayes_auto_expiry and do the expiries via a cron job instead. Do you think running a bayes expire via cronjob is necessary if you are running a INNOdb based bayes DB (with this patch[1])? Also, if you postpone the bayes expire to instead run it via cron aren't you just making the expiration stack up and instead are delaying this condition until later (when the cron job runs) and for longer (because the expiration hasn't been run in a while)? doing it once a day at 3 AM is not like doing it when delivering mail. Micah 1. http://issues.apache.org/SpamAssassin/show_bug.cgi?id=5661
Re: Disabling URIDNSBL plugin
Micah Anderson wrote: * mouss [EMAIL PROTECTED] [071020 09:38]: Micah Anderson wrote: Do you think running a bayes expire via cronjob is necessary if you are running a INNOdb based bayes DB (with this patch[1])? Also, if you postpone the bayes expire to instead run it via cron aren't you just making the expiration stack up and instead are delaying this condition until later (when the cron job runs) and for longer (because the expiration hasn't been run in a while)? doing it once a day at 3 AM is not like doing it when delivering mail. Unless you deliver mail 24 hours a day for people all over the world. Then 3am in one place is noon in another. Then run it at a different hour each day... but as Daryl says, the point is to separate the cleanup and the delivery processes.
