Re: oh where oh where...
On Dec 19, 2009, at 9:23 AM, RobertH wrote: you know, with all the duking it out on the list over some methods and such, where is Jo Rhett when you need him? he was always short and to the point... :-) Eh? Whut? (in the manner of someone woken from sleep) -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness
Re: oh where oh where...
On Dec 20, 2009, at 10:12 PM, RobertH wrote: sometimes we just need some input from you... I'm sure that this isn't true of all participants ;-) overall though, i am guessing that you havent needed anything special from the list for a lllooonnn time Nope. It works. I'm looking at 3.3 carefully but nothing stands out. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness
Re: oh where oh where...
On Dec 21, 2009, at 9:55 AM, R-Elists wrote: do you have changes / hopes / ideas / suggestions for SA to make it better or more better or whatever? No. SA does (with amavisd-new) exactly what I want it to do, and does it well. There's lots of stuff I don't use, like marking spam and keeping scores, but that's because years of personal experience demonstrated near-zero value. As I have it configured today it works well without having to mark anything ;-) -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness
Re: [AMaViS-user] Q about mail proxy servers and setups
Every problem you've named here is solved by putting Amavis/SA on the proxy instead of the internal system. If the proxy doesn't do the spam-checking, and the internal system does I can name a dozen other problems that will occur, the most important of which will be backscatter. 2-step relay where the internal system doesn't trust the external system is a backscatter system, and will get blacklisted fairly quickly. 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. 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) 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. 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? -- Jo Rhett Net Consonance ... net philanthropy, open source and other randomness
Re: [AMaViS-user] Q about mail proxy servers and setups
On Sep 23, 2007, at 5:17 PM, Michael Scheidell wrote: Anyone have an answer that isn't obvious? I already said I can't put it on the proxy. No, you didn't. You mentioned that as an option. And stop being rude to people who answer the question you asked. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness
Re: [AMaViS-user] Marc: use SPF to prevent backscatter? Was RE: Q about mail proxy servers and setups
Marc, you shouldn't be bouncing e-mails back at all. Use D_REJECT and make sure you're doing it at the SMTP layer. SPF or DKIM is irrelevant in this situation. On Sep 23, 2007, at 5:31 PM, 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. (and, yes, this would NOT work behind a proxy) I would like the proxy to at LEAST have a copy of the valid userlist, NOT muck with the headers. MAYBE do its load balancing via bridging rather than store forward. That might fix a lot. But then again, it would be easier to replace the proxy than fix it. -- Michael Scheidell, CTO Office: 561-999-5000 x 1259 Direct: 561-939-7259 Real time security alerts: http://www.secnap.com/news __ ___ This email has been scanned and certified safe by SpammerTrap(tm). For Information please see http://www.spammertrap.com __ ___ -- --- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ AMaViS-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/amavis-user AMaViS-FAQ:http://www.amavis.org/amavis-faq.php3 AMaViS-HowTos:http://www.amavis.org/howto/ -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness
Re: Advice on MTA blacklist
On Oct 9, 2007, at 10:37 AM, James E. Pratt wrote: Well, in the real world, many of us who would have to scan over 150,000 inbound emails a day, of which about 85% are pure 100% spam simply don't have that luxury... Are you using a 486 to process inbound mail? My 1.4Ghz Athlon 2 system with Amavis/SA processes that much mail PER HOUR without breaking a sweat. No MTA-level RBLs. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness
Re: Advice on MTA blacklist
On Oct 9, 2007, at 11:31 AM, Chris Edwards wrote: Your travellers should be using one of: - Authenticated SMTP submission bypassing your DNSBL tests - VPN into your network - Your webmail service Thus it shouldn't matter if their hotel is blacklisted (many are). 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. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness
Re: Advice on MTA blacklist
On Oct 9, 2007, at 3:52 PM, Chris Edwards wrote: 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. Right, but transparent proxy of SMTP connections is available in even the lowest end firewalls now (like free ones you get with service). And very few clients will complain if they aren't required to do SMTP auth, which means that the user will never know that their session was intercepted. Yes, this means man-in-the-middle is trivial. No kidding. Beat up the mail client creators. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness
Re: Advice on MTA blacklist
On Oct 9, 2007, at 4:22 PM, Chris Edwards wrote: Of course the best solution is for clients to always submit on port 465/587, and hope that's allowed out by the hotels / mobile connectivity providers. Fairly often not. I've been lucky with T-Mobile, but Sprint and Verizon apparently block it randomly. East coast t-mobile users have had problems with blocking. Your server then enforces encryption and SMTP-AUTH, and the SSL will (hopefully) defeat any man-in-the-middle attacks by trans-proxies. That's exactly the problem I am reporting. A lot of mail clients don't enforce SSL connections, so man in the middle is silently accepted. Only T-bird can be configured to not work any other way, TTBOMK. And this is irrelevant for proprietary systems like Crackberry which use only their own servers, and Verizon which has modified software to use their own servers, etc etc. As more and more people do more and more of their e-mail from hand- held devices, this problem only gets worse. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness
can we make AWL ignore mail from self to self?
I send myself a lot of email from my phone. So AWL properly scores me well. I just got a piece of SPAM which should have scored 12.something that got a -6 from the AWL. I think that mail from self to self should be ignored by the AWL. (it's harder to forged mail from a regular correspondent, so this makes AWL more useful) -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness
Re: can we make AWL ignore mail from self to self?
On Mar 28, 2008, at 6:21 PM, Theo Van Dinter wrote: On Fri, Mar 28, 2008 at 06:09:03PM -0700, Jo Rhett wrote: I think that mail from self to self should be ignored by the AWL. (it's harder to forged mail from a regular correspondent, so this makes AWL more useful) If you know the mail is from you, don't waste the resources scanning the message at all. This was a spam I'm talking about. I'm not worried about mail from self to self. I'm annoying because AWL is decreasing forged spam score so far that the SPF failure doesn't catch. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness
Re: can we make AWL ignore mail from self to self?
Benn, you are missing the point. AWL is working very well for our needs. What I am pointing out is that AWL should not be used for mail from self to self, because this is an easy forgery. AWL counts on the spammer not being able to forge someone you correspond with normally. This is usually true, but forging your own address is trivial. On Mar 28, 2008, at 6:48 PM, Benny Pedersen wrote: On Sat, March 29, 2008 02:09, Jo Rhett wrote: I send myself a lot of email from my phone. So AWL properly scores me well. and the sender ip with a fuss of /16 I just got a piece of SPAM which should have scored 12.something that got a -6 from the AWL. ok I think that mail from self to self should be ignored by the AWL. (it's harder to forged mail from a regular correspondent, so this makes AWL more useful) better configure awl to weight scores better to what trustness you want from it perldoc Mail::SpamAssassin::Plugin::AWL see the factor setting in usersettings Benny Pedersen Need more webspace ? http://www.servage.net/?coupon=cust37098 -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness
Re: can we make AWL ignore mail from self to self?
On Mar 29, 2008, at 3:21 AM, Justin Mason wrote: the AWL is keyed on email address and /16 of the sending IP address, so this may warrant more investigation. could you post the Received hdrs from the spam that hit the AWL, and a ham that properly hits the AWL? I still believe that self-self would make a good exemption for AWL. Sorry, I don't the original messages any more. (I looked) But it wouldn't surprise me if the /16 matched. The mail I send myself is usually from Wifi or my phone carrier's GSM network, but accepted via SMTP AUTH on the local machine. So which address are you using? Here's an example. Return-Path: [EMAIL PROTECTED] Received: from mail.netconsonance.com ([unix socket]) by triceratops.netconsonance.com (Cyrus v2.3.9) with LMTPA; Tue, 01 Apr 2008 13:14:34 -0700 X-Sieve: CMU Sieve 2.3 Received: from [10.178.18.103] (m4a0e36d0.tmodns.net [208.54.14.74]) (authenticated bits=0) by mail.netconsonance.com (8.14.1/8.14.1) with ESMTP id m31KE4ui014296 for [EMAIL PROTECTED]; Tue, 1 Apr 2008 13:14:27 -0700 (PDT) (envelope-from [EMAIL PROTECTED]) X-Virus-Scanned: amavisd-new at netconsonance.com X-Spam-Flag: NO X-Spam-Score: -0.72 X-Spam-Level: X-Spam-Status: No, score=-0.72 tagged_above=-999 required=3.8 tests=[ALL_TRUSTED=-1.44, AWL=0.720] From: Jo Rhett [EMAIL PROTECTED] Subject: test awl Date: 01 Apr 2008 13:14:00 -0700 To: [EMAIL PROTECTED] X-Mailer: ChatterEmail+ for Treo 6xx/700p (3.0.8) Message-ID:[EMAIL PROTECTED] -- from the cell phone of Jo Rhett Network/Software Engineer Network Consonance -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness
Re: Spam abuse report plugin
On Mar 28, 2008, at 7:42 AM, Matus UHLAR - fantomas wrote: On 27.03.08 19:58, ram wrote: I personally dont like the traditional spamcop report method of forwarding Spamcop uses a double confirm method, and to confirm all mails is a pain. I will look at how to automate this. I trust spamcop should not mind. This is building spamcops database of spam originating machines I guess the main reason why SpamCop wants to confirm all submissions it to avoid automatic submissions. Unless you want to be refused by SpamCop, confirm everything manually or use other reporting site... With good reason. We regularly see people enable some sort of automation, and then start feeding us spamcop reports for all of their opt-in mail. We report them, and the spamcop account gets shut down. Please people: if you're going to try and automate it, then test your automation by sending all the reports to yourself first. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness
Re: can we make AWL ignore mail from self to self?
On Apr 1, 2008, at 3:00 PM, Bob Proulx wrote: I have never been fond of AWL because the information it relies upon, the mail headers, is very easy to forge. It depends too much upon Yes, but they have to know who to forge. Anyway, I'm not debating its merits. It works very, very well in our experience. Except for this one situation. What I am pointing out is that AWL should not be used for mail from self to self, because this is an easy forgery. It is all very easy to forge. But self to self is very easy for the recipient to spot as a forgery. (Unless they have a short memory and are very gullible. :-) Not guillable, but don't want to get an obvious spam in my mailbox. SA knew it was spammy, but the AWL discounted the score. I disagree with the premise that it is hard to forge mail from someone you correspond with frequently. It is equally easy to forge. Easy to forge, but who to forge? Hard for a spammer to know who I correspond with frequently. Myself is the only one a spammer could guess. Again, not debating its merits just the implementation. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness
Re: can we make AWL ignore mail from self to self?
On Apr 1, 2008, at 3:14 PM, Justin Mason wrote: Sorry, I don't the original messages any more. (I looked) But it wouldn't surprise me if the /16 matched. The mail I send myself is usually from Wifi or my phone carrier's GSM network, but accepted via SMTP AUTH on the local machine. So which address are you using? hmm, I'm not sure. It depends on your trusted_networks setting. try running spamassassin -D and see what it logs... I'm sorry -- feeling dense, how is this supposed to help? From the headers quoted below you know what spamassassin is seeing. There's nothing in trusted networks, I don't trust anything... Here's an example. Return-Path: [EMAIL PROTECTED] Received: from mail.netconsonance.com ([unix socket]) by triceratops.netconsonance.com (Cyrus v2.3.9) with LMTPA; Tue, 01 Apr 2008 13:14:34 -0700 X-Sieve: CMU Sieve 2.3 Received: from [10.178.18.103] (m4a0e36d0.tmodns.net [208.54.14.74]) (authenticated bits=0) by mail.netconsonance.com (8.14.1/8.14.1) with ESMTP id m31KE4ui014296 for [EMAIL PROTECTED]; Tue, 1 Apr 2008 13:14:27 -0700 (PDT) (envelope-from [EMAIL PROTECTED]) X-Virus-Scanned: amavisd-new at netconsonance.com X-Spam-Flag: NO X-Spam-Score: -0.72 X-Spam-Level: X-Spam-Status: No, score=-0.72 tagged_above=-999 required=3.8 tests=[ALL_TRUSTED=-1.44, AWL=0.720] From: Jo Rhett [EMAIL PROTECTED] Subject: test awl Date: 01 Apr 2008 13:14:00 -0700 To: [EMAIL PROTECTED] X-Mailer: ChatterEmail+ for Treo 6xx/700p (3.0.8) Message-ID:[EMAIL PROTECTED] -- from the cell phone of Jo Rhett Network/Software Engineer Network Consonance -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness
Re: can we make AWL ignore mail from self to self?
I'm not worried about mail from self to self. I'm annoying because
AWL is decreasing forged spam score so far that the SPF failure
doesn't catch.
On Apr 1, 2008, at 3:14 PM, Benny Pedersen wrote:
INSERT INTO `awl` VALUES('amavis', '[EMAIL PROTECTED]', '80.166', 4, -14,
'2008-04-02 00:02:15');
INSERT INTO `awl` VALUES('amavis', '[EMAIL PROTECTED]', 'none', 1, -8.5,
'2008-04-01
23:55:23');
it seems it works here, none is when its sent from localhost,
80.166 is when
sent outside localhost, so problem is ?
Sorry, I don't understand your question.
I also don't see the value in having every possible mail account need
a setting like this manually inserted. That's why I'm asking about a
fix in the module...
--
Jo Rhett
Net Consonance : consonant endings by net philanthropy, open source
and other randomness
Re: can we make AWL ignore mail from self to self?
On Apr 1, 2008, at 4:03 PM, John Hardin wrote: If you don't scan mails that you know originated from you, then they won't affect AWL for a forged message... Sorry, I'm not going to disable virus and bot protection just to avoid a mis-feature in another module. The right answer is a fix in the module. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness
Re: can we make AWL ignore mail from self to self?
On Apr 1, 2008, at 5:46 PM, Benny Pedersen wrote: What I am pointing out is that AWL should not be used for mail from self to self, because this is an easy forgery. explain why its a problem when awl logs ip AWL counts on the spammer not being able to forge someone you correspond with normally. so problem is that awl tracks /16 with is mostly to wide ? will problem be solved if it was /32 ? The answer to these questions is I don't know. It's not clear to me how spamassassin deals with SMTP AUTH messages from localhost. It appears that in some situations SA skips the first Received header and goes to the previous one. That's why I asked the question about which IP is used. This is usually true, but forging your own address is trivial. yep, but ip should still limit the problem very much I agree. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness
Re: Dramatic increase in bounce messages to forged addresses
On Apr 2, 2008, at 12:34 PM, mouss wrote: no tuning on your side will help solving problems at the other side. For example, I found that hotmail cache the value Yes, they cache the results of that DNS query for exactly how long you tell them to. If you want the SPF record cached less, reduce the TTL on that record. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness
Re: can we make AWL ignore mail from self to self?
Matt Kettler wrote: There's nothing in trusted networks, I don't trust anything... Jo, that's impossible in spamassasin. You cannot have an empty trust, it doesn't make any logical sense, and would cause spamassassin to fail miserably. I should rather have said trust is only localhost. If you don't declare a trusted_networks, SA will auto-guess for you. (And the auto-guesser is notorious for failing if your MX is NAT mapped) And please, understand that trust here means trusted to never forge a received header not trusted to never relay any spam. I know this. In spamassassin, under trusting is BAD. It is just as bad as over-trusting. SA needs at least one trustworthy received header to work with. How and why? Are you saying I *must* have a 2nd-level MX host for SA to work? That's not my experience, and 2-layer relays are backscatter sources. Milter from the local MTA works just fine. Also, to work properly, SA needs to be able to determine what is a part of your network, and what isn't. Unless you declare internal_networks separately, it bases internal vs external on the trust. There is no network. There is only a single host. I don't control any other host on the subnet. trust no-one is NOT a valid option, and would actually result in the problem you're suffering from. After all, if no headers are trusted, all email comes from no server, so SA would never be able to tell the difference between an email you really sent, vs a forgery from the outside. This statement parses as nonsense. SA can't parse an e-mail because it doesn't trust the source? Isn't that all e-mail? If your trust path is working properly, SA knows the difference. If it's not working, you get a broken AWL, broken RBLs, broken ALL_TRUSTED, and dozens of other broken things. Okay, seriously I think you're both underestimating my understanding of this and further confusing the matter by making all sorts of unclear claims that don't reflect in reality. I get trust paths. This issue I reported is not related to trust paths. It's not a broken trust path problem. The e-mail came from an untrusted source, but was given a negative AWL score based on the sender name. That has nothing to do with trust.
Re: can we make AWL ignore mail from self to self?
John Hardin wrote: I'm only suggesting bypassing SA for mail that originates on the local network and is destined to the local network. No. I don't trust every user who can authenticate to this host to run active anti-virus on their hosts. I scan all mail, everywhere. And again, this isn't about local mail marked as spam. It's about non-local mail being marked as ham.
Re: can we make AWL ignore mail from self to self?
Bob Proulx wrote: Who to forge? The answer is Everyone! Any address that can be obtained from a spam-virus infected PC and any address that can be harvested from a web page. Forge them all. They are (mostly) valid email addresses and will pass sender verification. Send To: and From: all of them. You're going out of your way to miss the point. That's hard work Yes, a spammer can forge anyone. Can they forge the exact e-mail addresses used by people I correspond with regularly? Not in my experience. Can they forge my e-mail to me? Easily.
Re: can we make AWL ignore mail from self to self?
Justin Mason wrote: hmm, I'm not sure. It depends on your trusted_networks setting. try running spamassassin -D and see what it logs... I'm sorry -- feeling dense, how is this supposed to help? From the headers quoted below you know what spamassassin is seeing. There's nothing in trusted networks, I don't trust anything... No, I don't know. I'd have to run SpamAssassin to find out. Since you're asking, you can run it ;) I would, but I can't find the exact situation that made this work nor the original message. My other testing doesn't reproduce anything near a -10 score. Is there any useful way to query the AWL database to find how this might have occurred? trusted networks is just localhost, which is what Darryl recommended for single hosts without any trusted hosts.
Re: can we make AWL ignore mail from self to self?
On Apr 21, 2008, at 10:01 PM, Theo Van Dinter wrote: Actually I don't think it's that hard, at least for conversations on public lists. Right now it seems to be more work than they bother with. As I've noted, I read all my spam looking at the latest techniques and I've never seen this. (I have a 20-year-old mail address which gets thousands per hour unfiltered which I use to test my ideas with) Also, I've had spammers forge my email address from work to mail my personal account. Do you have the same lhs? At least one of the botnets tries to match lhs for the forged sender. A few of my messages came from my other accounts, many others (in the same spam run) came from people I didn't know with the same lhs. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness
Re: can we make AWL ignore mail from self to self?
On Apr 21, 2008, at 10:46 PM, Bob Proulx wrote: Jo Rhett wrote: Bob Proulx wrote: Who to forge? The answer is Everyone! Any address that can be You're going out of your way to miss the point. That's hard work It is you who are missing the point. When spammers generate mail from and to every possible combination they will eventually hit a combination that you will see. The distributed spamming engines of the 'bot-nets are quite powerful and can generate this volume of traffic. Eventually is the big word. If we succeed in making spam eventually get through then we would have won this war. I'm saying that I've never seen this in the wild, and the AWL has been 99% or greater effective for me, so I'm not going to throw away a good tool because it is theoritically possible to fit another angel on that pinhead. It works today. Now please stop arguing that AWL is useless. It works for me. If it doesn't work for you, then you have no reason to reply on this thread. (not trying to be rude, but this conversation is pointless) -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness
Re: can we make AWL ignore mail from self to self?
On Apr 22, 2008, at 12:06 AM, Matus UHLAR - fantomas wrote: On 21.04.08 23:46, Bob Proulx wrote: It is you who are missing the point. When spammers generate mail from and to every possible combination they will eventually hit a combination that you will see. The distributed spamming engines of the 'bot-nets are quite powerful and can generate this volume of traffic. especially when they start collecting people's addressbooks to see who sends mail to whom. In which case I will know and inform my friend that their system has been compromised. And again, irrelevant to the topic. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness
Re: can we make AWL ignore mail from self to self?
On Apr 23, 2008, at 3:27 PM, Matt Kettler wrote: How and why? Are you saying I *must* have a 2nd-level MX host for SA to work? That's not my experience, and 2-layer relays are backscatter sources. Milter from the local MTA works just fine. No, you don't need a second-level MX. However, to work properly, SA must trust everything up to an including your MX, and all your trusted mailservers need to generate Received: headers that SA can then make sense of. I'm not repeating for the 5th time that there are no trusted mailservers. Only this host. This isn't about SA trusting the originating source of the message. it's about SA trusting that at least one trusted mailserver actually received the message. ie: the message has to have actually arrived at your server, and not been transplanted from nowhere by magic. If there's no trusted headers, then all messages are equally magic to SA, and it will never distinguish mail you sent as compared to mail an outsider forged as you. Yes, it knows the localhost received header is valid. Basics of SA setup 101. Now can we return to the topic? -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness
Re: can we make AWL ignore mail from self to self?
On Apr 29, 2008, at 7:40 PM, Matt Kettler wrote: I'm not repeating for the 5th time that there are no trusted mailservers. Only this host. That's a contradiction, because this host is a mailserver. Clearly you have a trusted mailserver. However, in the interest of moving the discussion forward, you have exactly one trusted mailserver, your MX, which is perfectly valid. Yes. I'm sorry but this is obvious. I don't know how to pick the words exactly as you want them, but most people understood what I meant 5 or 6 replies ago ;-) The question lies in why does the AWL seem to be confusing forged email with your own email. That's generally quite critically dependent on the trust path. No, that's not the question at all. (more below) Have you tried running one of the forged messages, and an actual legitimate message through SA manually with the -D flag to see what the trusted and untrusted hosts are, as SA sees it? Yes. Many times. That's not the point of this thread. The point of this thread is the obvious ease of forging e-mail from recipient to (same) recipient. It's one situation where the AWL wouldn't work very well. It would be fairly easy to forge, and worthwhile enough for botnets to just do this (which they are, in force, for the last month) I personally see no value in applying AWL to messages from self to self. I may be wrong, and I'm open to arguements against this, but I am suggesting that the AWL module should skip over self-self messages. It seems too easy to forge, and no gain in doing so. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness
Re: can we make AWL ignore mail from self to self?
On May 3, 2008, at 7:59 PM, Matt Kettler wrote: Have you tried running one of the forged messages, and an actual legitimate message through SA manually with the -D flag to see what the trusted and untrusted hosts are, as SA sees it? Yes. Many times. That's not the point of this thread. I still think it is. Matt, how can I possibly get you to move past this unfounded assumption that my trust path is broken and focus on the real problem? The trust path is not broken, it's just fine. If your AWL is applying the same history data to forged email as unforged email, either there's a *major* bug in the AWL code, or your trust path is broken. Period. The AWL is designed to be able to distinguish forged mail from nonforged mail. If that's not working, that's a major problem. I've read the code and I see nothing designed to determine forgeries. There is code to save data with an IP range, but that's not relevant to this issue. The point of this thread is the obvious ease of forging e-mail from recipient to (same) recipient. It's one situation where the AWL wouldn't work very well. Actually, it's very difficult to forge in a way that will confuse the AWL, if your trust path and the AWL code is working properly. After all, it looks at the combination of email address and first untrusted IP. Forged email will not be from the same IP as legitimate email, unless your trust path is broken and SA always sees all mail as entering your network from the same IP. Or that you receive e-mail from the very same public wireless and/or phone providers as everyone else does. My trust path doesn't have to be broken if the networks used to send the e-mail are public networks. (if you can laugh == welcome to the 21st century and the Crackberry/ Treo/iPhone) Not trying to be snide. It would be fairly easy to forge, and worthwhile enough for botnets to just do this (which they are, in force, for the last month) I personally see no value in applying AWL to messages from self to self. I agree, but I see no value in applying the exception. I'd rather try to fix the more general problem of your AWL not distinguishing message sources properly. I see no evidence of this. My trust path is just fine (ie nonexistent == all mail not from localhost isn't trusted) I may be wrong, and I'm open to arguements against this, but I am suggesting that the AWL module should skip over self-self messages. It seems too easy to forge, and no gain in doing so. You're overlooking how the AWL works. It's actually really hard to forge. However, I will agree with you there's limited value in self-to-self AWL records.. but there's also no harm in them if the AWL is working properly. Instead of making statements like this, please explain how the AWL deals the forgery. Because I have the code right in front of me and I see absolutely nothing in the AWL code that tries to identify forgeries. Instead of making unfounded statements, can you be specific about the issues?
Re: can we make AWL ignore mail from self to self?
Let's focus this on specific technical details: 1. How does AWL deal with forgery (other than by saving a /16 of the source IP) 2. How can I easily see the AWL database for a given destination address?
Re: MailChannels Traffic Control (fwd)
mouss, please do a little research before you go online attacking people. Your statements about what work and don't have no backup, and go against all existing evidence today, and yet you're blasting them for lack of serious study. Try to do some yourself. On May 19, 2008, at 11:46 AM, mouss wrote: but anyway. I don't see what mailchannel are bringing that deserves this debate. it looks to me like this: - they started trying to sell greeetpause. and it didn't work enough - they moved to slowdown and they're trying to talk about In both cases, they don't provide any serious study. they only show numbers that go with their claims. I don't know for others, but my logs don't seem to confirm theirs. and the slowdown thing is based on the theory that spammers have better things to do than wait. now that we know more about botnets, this theory doesn't stand. how long would it take to write an asynchronous smtp client?
Re: MailChannels Traffic Control (fwd)
On May 19, 2008, at 2:05 PM, Benny Pedersen wrote: On Mon, May 19, 2008 20:18, Ralf Hildebrandt wrote: To be fair (I'm testing it right now): It's easy to get running. Right now the Tarpit and slowdown features cannot be had in Postfix, so I'm giving it a spin. give longer greylist times will do without marketing :-) It will slow down real user's mail a lot too. Please take time to actually learn about what the product does before you make statements like this. Or at least put a tag on your e-mail that says I haven't read the first thing about how this product works, but it seems to me... NOTE: no affiliation with Mailchannels, just personally tired of seeing people make authoritative statements about products they haven't even read the basics about. It turns people off from doing their own research because they don't realize the poster is taking out of the wrong side.
Re: MailChannels Traffic Control (fwd)
On May 19, 2008, at 11:43 PM, Koopmann, Jan-Peter wrote: So yes: If their main benefit is tarpitting etc. then I agree it probably is not worth the money or discussion. Why is everyone willing to skip doing 5 minutes of research? Mailchannels idea may not work for you. But it's worth doing a bit of research. FYI: again, not affiliated and we're not using it either. But the product is very well designed and it's a lot more clever/useful than anything you're comparing it to.
Re: MailChannels Traffic Control (fwd)
May I suggest that you redo your research? BarricadeMX has no feature at all that even attempts to address the issue MailChannels is addressing, ie slowing down the TCP channel. On May 20, 2008, at 10:32 AM, Koopmann, Jan-Peter wrote: Why is everyone willing to skip doing 5 minutes of research? I did. Mailchannels idea may not work for you. But it's worth doing a bit of research. Oh the idea is nice. But there are others out there that - from my personal perspective - are doing this stuff much better, at least from what I can tell. See BarricadeMX from Fort Systems Ltd. FYI: again, not affiliated and we're not using it either. But the product is very well designed and it's a lot more clever/useful than anything you're comparing it to. I compare it to BarricadeMX and as I said, I think it is not so clever. Personal opinion. Regards, JP -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness
Re: MailChannels Traffic Control (fwd)
give longer greylist times will do without marketing :-) It will slow down real user's mail a lot too. On May 20, 2008, at 3:58 PM, Benny Pedersen wrote: real mail servers is 1: known 2: can be bypassed in greylist on that fact #1 Both of these are addressed by Mailchannels. But what to do when an unknown mail server contacts you is different in the approach. greylist effectiveness is down to less than 10% effective at this point, because the botnets know to retry now. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness
Re: MailChannels Traffic Control (fwd)
On May 20, 2008, at 10:51 AM, mouss wrote: Jo Rhett wrote: mouss, please do a little research I did. I may get things wrong, and would be pleased to get corrected. so please share your knowledge. All I'm saying is that you're comparing what they are doing to things which are not similar, then accusing them of doing no research. before you go online attacking people. if discussion is considered as an attack, ... Look at your posts and your wording and you'll see. There is no such statement in my post. or do you consider I don't see..., it looks to me..., I don't know for others, as statements? I confess that english is not my native language, but I try hard ;-p You didn't use those when you made the accusations in question. calm down. I apologize if I sounded like attacking your business or friends. That was not my intent. I'm calm, and I don't much care about this topic at all. But I spend a lot of time helping people disambiguate statements like these from well-researched opinions, so I try to flag them when I see them so that someone else reading the thread will know that this isn't the overall impression of the list -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness
Re: can we make AWL ignore mail from self to self?
On May 20, 2008, at 1:07 PM, Justin Mason wrote: 1. How does AWL deal with forgery (other than by saving a /16 of the source IP) No other way. What's wrong with saving a /16? In my experience it's worked pretty well for the past few years... Seems to. I can logically think of ways it would/should break (ie public wireless networks) but I haven't seen any real problems until now, and the problem is specific to self-self. My comment was only because Matt kept insisting that AWL prevents forgery... 2. How can I easily see the AWL database for a given destination address? tools/check_whitelist Where can I find this? It's not in the Mail-SpamAssassin tarfile... -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness
Re: can we make AWL ignore mail from self to self?
Jo Rhett wrote: Matt, how can I possibly get you to move past this unfounded assumption that my trust path is broken and focus on the real problem? The trust path is not broken, it's just fine. On May 20, 2008, at 5:47 PM, Matt Kettler wrote: Ok, then the AWL code is *SEVERELY* bugged. The question then becomes why isn't the source address part of the AWL working properly. I'm not sure I know this or can agree. I'm fairly sure its orthagonal, but I may be wrong. That IP range is what would detect the forgeries, or at least give the forgeries a different AWL entry than email you really sent yourself. I only send mail to myself from my wireless provider or open WiFi networks. e.g. note to self while I am on the road. The source IPs are different, so your real self-to-self should be handled independently, with a completely separate AWL entry, from the spammer forged self-to-self. You're assuming I use the same source IP when I send myself mail, and that just isn't true. Or that you receive e-mail from the very same public wireless and/ or phone providers as everyone else does. My trust path doesn't have to be broken if the networks used to send the e-mail are public networks. (if you can laugh == welcome to the 21st century and the Crackberry/Treo/iPhone) Not trying to be snide. If you're using any kind of forwarder, including crackberry, their servers should be trusted by you so that SA's checks get applied to the mailserver that dropped mail off at them. That's the purpose of the trust path, to allow you to trust the headers of those systems receiving mail on your behalf and forwarding it to you. I'm not -- my Treo delivers mail directly to my mail server. From DHCP-assigned addresses all over the world. I enjoy travel ;-) I'd also like to point out that no provider is willing to share their server lists openly and consistently enough for this to occur. We have to put crackberry users in their own domain because we use SPF on the main domains and crackberry keeps changing their servers. no provider == crackberry, verizon, sprint, etc... the wireless providers who intercept outbound mail. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness
Re: MailChannels Traffic Control (fwd)
On May 21, 2008, at 11:37 AM, John Hardin wrote: Also consider that greylisting will allow URIBLs time to update even if all spambots implement retry and thus negate the _original_ intent of greylisting... The negative effects of greylisting outweight the positive. As a provider who needs to receive timely problem reports from our customers, greylisting was impossible for us to use. Comparing spam catches for greylisting against my personal domains where I could use greylisting (but all other rulesets being equal) I found that less spam was caught by SA and the overall load was somewhat reduced, but the amount of spam reaching the mailbox remained the same. Over time the load difference reversed as the spambots started doing retries (often 5-10 within 2 minutes) and the amount of spam reaching the mailbox remained the same. Greylisting became a penalty, so I disabled it. Again, without changing the amount of spam reaching my mailbox. MailChannel's implementation solves all of the problems we had with greylisting, while also hitting the botnets where it hurts. It appears to be a great idea. I need to figure out how to implement it without breaking our internal auth schemes, but I will be doing so. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness
Re: Experimental - use my server for your high fake MX record
On May 7, 2008, at 9:17 AM, mouss wrote: what if he comes back later to the same MX, again and again (AFAIK, this is the case with qmail)? mail will be lost. snarky comment Good. Time for qmail to die ;-) /snarky comment -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness
Re: AW: Re: MailChannels Traffic Control (fwd)
On May 21, 2008, at 11:56 AM, Koopmann, Jan-Peter wrote: It sure can and we are using that feature. It adresses all (!) features MailChannel claims to address on the webpage and more. Sure it is I who has to do the researching? I read every document on their website, and saw zero mentions of this feature. I can't research it further without getting the product here to test, and I'm not suggesting that everyone do this -- just that everyone read the information available. Moreover BMX can do quite a lot of what you describe without having to slow down the TCP channel too much thereby freeing up ressources. But honestly I do not think this leads to anything. Look at testing results. Try it out. It's been 99% effective against the botnets on a test system I enabled. But please do not accuse me or others of not doing research if you are not sure. I did quite a bit of research and even asked for more information (which has not been provided yet). I have not said it lacks feature x while you incorrectly claim lacking features of other products. People said specifically that mailchannels was doing nothing more than qmail does which is clearly not true with even some basic reading. This clearly indicates a lack of research. I accept your accusation about my research IF you can please point me to a document on FSL's website which addresses slowing down TCP sessions. I can't find it. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness
Re: AW: Re: AW: Re: MailChannels Traffic Control (fwd)
On May 21, 2008, at 12:34 PM, Koopmann, Jan-Peter wrote: I read every document on their website, and saw zero mentions of this feature. I can't research it further without getting the product here to test, and I'm not suggesting that everyone do this -- just that everyone read the information available. http://www.snertsoft.com/smtp/smtpf/ Okay, this link wasn't available to me. I googled the term you provided and only found the FLS site. They had no links to this data. Next time you want to suggest that someone didn't research, you should be explicit with your links. Test results are nice to read but thats it. Moreover: how fast? How expensive? What about clustering? 99% effective with how many false positives etc. Does it fight backscatter? What I am saying is that there is more to it than this one figure. As afar as the slowdown is concerned, there aren't false positives. Read the text! People: maybe. I did not do so. So if you want to accuse them, go ahead but leave me out of this loop. Please provide a link which describes what exactly they are doing. The things I could find justify peoples statements a bit since most of what I read can indeed be done with standard MTAs. Then they use a reputation network (in the commercial version only?) so they do not have to do the interesting tests themselve on the box. If I failed to see the magic of the product please enlighten me and please apologize. Apologize for what? The top-level links on the website provided the information you claim isn't there. It's not stored on some other website nobody has named ... I accept your accusation about my research IF you can please point me to a document on FSL's website which addresses slowing down TCP sessions. I can't find it. See above. From memory. Detailed description of all tests, options, error messages etc. Your memory wasn't laid out to anyone else. Lacking your memory in my search pool, I used Google. I'm tired of wasting time with this pointless conversation. Just stop making authoritative statements about products you haven't researched. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness
Re: MailChannels Traffic Control (fwd)
On May 21, 2008, at 1:19 PM, mouss wrote: All I'm saying is that you're comparing what they are doing to things which are not similar, then accusing them of doing no research. you are confusing me with someone else. I never accused anyone of doing no research. http://www.gossamer-threads.com/lists/spamassassin/users/121113 5 message down is you. Look at your posts and your wording and you'll see. I did. still nothing. See above. You didn't use those when you made the accusations in question. do you actually read posts you reply to? Read your own mail folder, I quoted you at the time. It's also all on the thread above if you can't find it in your trash folder. I'm calm, and I don't much care about this topic at all. But I spend a lot of time helping people disambiguate statements like these from well-researched opinions, so I try to flag them when I see them so that someone else reading the thread will know that this isn't the overall impression of the list you'd better take time learning what research is. now we're down to insults. *plonk* -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness
Re: AW: Re: MailChannels Traffic Control (fwd)
On May 21, 2008, at 1:08 PM, mouss wrote: I read every document on their website, and saw zero mentions of this feature. if you can't find the docs that others have read, and still accuse them of lack of research, there is a word for this: ridiculous. There's nothing on that site. It's on another site nobody mentioned. It's not my job to find all references. And I'm not saying people should find *ALL* references, I'm saying that people should taking 1-2 minutes to read what the person is actually suggesting/implementing, rather than disregarding the product/idea/whatever publically without any clear understanding of what it does. before suggesting what others should do, try improving your search and navigation skills. (I am serious here. I am sure you will thank me in few years). *snip other insults* Lose the attitude. I was suggesting people actually read what's right in front of them, not even asking that they search around. Your insults are irrelevant to the topic here, and I won't put up with it. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness
Re: AW: Re: MailChannels Traffic Control (fwd)
On May 21, 2008, at 3:18 PM, mouss wrote: Can't you read? He said documentation on BarricadeMX, No problem, search for Slow Replies in the 2.0 release notes. And Mailchannels isn't implementing slow replies. That's what I'm trying to say. It is slowing the TCP session, not slowing the responses. Bots already deal with slow replies, it's non-effective. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness
Re: Experimental - use my server for your high fake MX record
On May 21, 2008, at 1:44 PM, mouss wrote: Good. Time for qmail to die ;-) start by updating the RFCs. The RFCs are, and have always been clear on how MX records are supposed to be used. Are you just a nonsense machine? The SA list's personal eliza run through the borker? -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness
Re: can we make AWL ignore mail from self to self?
On May 22, 2008, at 7:29 AM, Jonas Eckerman wrote: Jo Rhett wrote: I'm not -- my Treo delivers mail directly to my mail server. From DHCP-assigned addresses all over the world. I enjoy travel ;-) Then I guess you use authenticated SMTP for that. The easiest way to handle this probably is to simply avoid calling SA for authenticated mail. That's a hack with consequences. Like just disable the firewall. Uh, no ;-) Lots of users of this host have Windows PCs, and running SA on all outbound mail has both alerted them quickly to the problem and avoided nailing other people with spam and/or virus runs. Another way to do it would be to use different AWLs, or disabling AWL, for mail from your own users (either authenticated or locally submitted). This makes a lot of sense to me. Have no my own users except me ;-) And disabling AWL entirely is again a hack. Let's focus on a fix. A more involved change would be to have the AWL store the authentication state as well as mail address and relay IP/16. When scanning mail from your own users using the same AWL database as for for mail to your users, this seems necessary to me. Again, this seems to be a lot of work for no real gain. What I have proposed makes sense for widespread use. Why hack/slash/burn when a good fix would improve it for everyone? -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness
Re: can we make AWL ignore mail from self to self?
On May 22, 2008, at 12:42 PM, Rob McEwen wrote: First, even if this isn't what you meant, I must set the record straight... requiring SMTP password-authentication is NOT a hack. Instead, that is a security feature. I'm not sure if you meant that differently, but I state this just to be on the safe side. Second, you do require SMTP authentication, right? Because not doing so would likely open up your server as an open relay. Rob, please read what you reply to. I've been doing SMTP AUTH since before we got it standardized. I said that disabling running SA for SMTP-AUTH users is a hack much like disabling a firewall and I won't do it. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness
Re: can we make AWL ignore mail from self to self?
On May 22, 2008, at 1:23 PM, Dave Funk wrote: Lots of users of this host have Windows PCs, and running SA on all outbound mail has both alerted them quickly to the problem and avoided nailing other people with spam and/or virus runs. Genuine curiosity Jo, have you seen instances of viruses/trojans sending -authenticated- mail? Have they learned how to read users' passwords, etc? We require our PC users to authenticate when sending and I had assumed that would stop viruses/trojans. Am I being naive? Yes, you are. Most of the viri use the existing Outlook configuration, which includes the user's saved SMTP AUTH passwords. Like I said, SA has saved our butt each time it happened. I wouldn't say that without it having happened multiple times... -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness
Re: AW: Re: MailChannels Traffic Control (fwd)
On May 21, 2008, at 1:08 PM, mouss wrote: I read every document on their website, and saw zero mentions of this feature. if you can't find the docs that others have read, and still accuse them of lack of research, there is a word for this: ridiculous. Jo Rhett wrote: There's nothing on that site. It's on another site nobody mentioned. It's not my job to find all references. And I'm not saying people should find *ALL* references, I'm saying that people should taking 1-2 minutes to read what the person is actually suggesting/implementing, rather than disregarding the product/idea/ whatever publically without any clear understanding of what it does. On May 22, 2008, at 1:18 AM, mouss wrote: and who told you I did not check what they do? I may have got it wrong as I said before, but this is no reason for you to jump into insults. mouss, read your own words. You threw insults (there's a word for this). There isn't a single insult in what I said? I'm sorry, but you are effing nuts. Not an insult, a factual observation of your psychopathic behavior. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness
Re: can we make AWL ignore mail from self to self?
On May 23, 2008, at 3:45 AM, Jonas Eckerman wrote: 1: Just read it as of when I said your own users I meant the users of the host in question (the ones you mention above). More specifically, the users using your host as a MSA (authenticated or locally). I don't trust my users in this context. 2: I never suggested disabling the AWL entirely. I suggested disabling it for the above mentioned users. I also suggested (and this is prefferable to disabling it in my opinion) to separate the AWL so that you use one AWL for mail from the above mentioned users and another for unathenticated mail from external relays. Is there any specific reason you do not want to use two different AWLs for those two different types of traffic? Non-standard configuration/setup I would have to maintain *AND* A lot of work to hack around a simple problem. The AWL works just fine for mail from my users to other my users. In fact, it works exceedingly well for that. What value is there in separating them? A more involved change would be to have the AWL store the authentication state as well as mail address and relay IP/16. When scanning mail from your own users using the same AWL database as for for mail to your users, this seems necessary to me. Again, this seems to be a lot of work for no real gain. What I have proposed makes sense for widespread use. Why hack/slash/burn when a good fix would improve it for everyone? In case you haven't noticed it, your suggestion is not seen as a good fix for the problem by everyone. I was merely suggesting other ways to go about this. Actually, that's not true. Nobody has suggested that this fix would be bad. Matt was querying me thinking I had screwed up my trusted hosts, but not a single person has suggested that this change would be bad. If you wish other peoiple to implement/accept something that fixes your problem and you can't convince them that your own ideas are good, it may be that alternative means of fixing the problem are seen as better and therefore stand a bigger chance of being implemented/eccepted. What alternatives? So far I've only heard (a) disable the AWL (b) don't use AWL it sucks and (c) hack the system to use different AWLs. None of which really make any logical sense to solve the problem. If you do implement your fix and submit it, please make it an option. I for one would turn it off since it would not improve things here. You are the first person to say so. Can you explain why? -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness
Re: can we make AWL ignore mail from self to self?
On May 29, 2008, at 4:18 AM, Jonas Eckerman wrote: Please do remember that I am in no way trying to stop or hinder you in implementing your fix. The fact that I have other suggestions does not mean that I'm opposing you. Of course. This is normal discussion. A lot of work to hack around a simple problem. The AWL works just fine for mail from my users to other my users. In fact, it works exceedingly well for that. What value is there in separating them? It would create a difference (a regards the AWL) between self-self addressed mail sent from authenticated/local users ans similar mail from other systems. I understand the concept, I don't see the value. And considering that SpamAssassin doesn't (in many configurations) even know what recipient address a message has, it might actually be easier than having the AWL ignore mail from self-self. It has to, for the AWL to work. As long as the MSA adds authentication info in it's received header, this could be fetched from X-Spam-Relays-Trusted pseudo header. The changes to do this would not be more difficult or invlolved than the changes necessary to exempt self-self mail from the AWL AFAICS. Easy or not, I don't see the value just yet. Also, while the adressee of a mail is often available with PerMsgStatus all_to_addrs, this function is not very reliable. It actually extracts a whole bunch of addresses that might be the recipient from the mail header. There is no guarantee that any of the returned addresses really are the recipient of the mail. So, to implement exemption of self-self-mail you first have to implement a way for SpamAssassin to know what the recipient address is in order to know if a mail is self-self-addressed. The AWL wouldn't work if it didn't know the recipient. Since this is something it stores in the AWL database we know that the recipient information is there. I want the AWL to apply to mail that is addressed from self-self. Since the AWL also takes the IP address into account and since all mail from authenticated/local users here comes from 127.0.0.1 to the software calling SpamAssassin, I do not have your problem here and would not benefit from your fix. While most mail addressed self-self that comes from external systems is spam, every now and then ham addressed from self-self do come in from idiotic systems and sometimes from users who for some reason is not using our servers when sending mail. The AWL as it is now does distinguish between good and bad mail that are or pretends to be from our users, and I see no reason to remove possible benefits of that distinction for mail that happens to be addressed to the same user as it's addressed from. You've presented good logic for acceping mail from self to self. But you haven't explained by using the AWL for mail from self to self is better than not having it. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness
Re: can we make AWL ignore mail from self to self?
You've presented good logic for acceping mail from self to self. But you haven't explained by using the AWL for mail from self to self is better than not having it. On Jun 2, 2008, at 4:02 AM, Jonas Eckerman wrote: Because it can help discriminate between spam and ham addressed from self to self. Heres an example: StupidWebService send self-self addressed ham from relay 1.2.3.4 EvilSpammer send self-self addressed spam from relay 5.6.7.8 (wich, unfortunately, belongs to a big ISP so the relay doesn'ät get blocked). One day StupidWebService send a ham that triggered a bunch of positive hits (including BAYES_99). Since mail from [EMAIL PROTECTED] has a negative score in the AWL, the mail gets though all right. One day EvilSpammer manages to send a mail that doesnät hit any positive rules, but does hit BAYES_00. Since [EMAIL PROTECTED] has a high positive score in the AWL, the mail still gets flagged as spam. If the AWL ignore mail from self-self, the two mails in the above example would have been misclassified. Indeed. I submit you are right. FYI: I still haven't had another misclassification since the first, so I'm beginning to think that this was a lark. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness
how to stop SPF checks from going past trusted host?
I'm trying to figure out how to stop SPF_FAIL on messages generated on an internal rfc1918 network and routed through a trusted host. Host A: generates mail, origin IP 10.x.x.x Host B: relays mail for Host A, to Host C Host C: receives mail, marks SPF_FAIL Host B is both in the valid SPF record, and in trusted networks. Example: host A: 10.0.0.1 generates e-mail, routes via HostB Host B: has outside IP 64.13.143.16 Host C: sees message from Host B, sees Host B is valid SPF sender, sees Host B is trusted Host _APPARENTLY_ skips to the next Received header because B is trusted. Received: from arran.svcolo.com (arran.sc.svcolo.com [64.13.143.17]) by kininvie.sv.svcolo.com (8.14.1/8.14.1) with ESMTP id m5K2o3it016795 for [EMAIL PROTECTED]; Thu, 19 Jun 2008 19:50:03 -0700 (PDT) (envelope-from [EMAIL PROTECTED]) Received: from apc0.sv.svcolo.com (apc0.sv [10.0.0.1]) by arran.svcolo.com (8.13.8/8.13.4) with SMTP id m5K2o1sL002910 for [EMAIL PROTECTED] ; Thu, 19 Jun 2008 19:50:02 -0700 (PDT) (envelope-from [EMAIL PROTECTED] ) X-Spam-Status: Yes, score=4.157 tagged_above=-10 required=4 tests=[AWL=0.656, NORMAL_HTTP_TO_IP=0.001, SPF_FAIL=3.5 Obviously, putting 10/8 into the published SPF record makes no sense at all, nor does adding 10/8 to the trusted_networks. So... how can I say I trust Host B so much that I don't want to go any farther for SPF checks? -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness
Re: how to stop SPF checks from going past trusted host?
On Jun 19, 2008, at 9:12 PM, Matt Kettler wrote: That is correct, SPF checks are applied to the first untrusted host. The question here would be if 10.x.x.x is in fact an internal, and presumably trusted, network, why isn't it trusted? The mail server I'm receiving this on is in the outside world. If a 10.x address connects to it, I don't want that address to be trusted for any reason. Only 10.x addresses that came via a trusted host ;-) Also, presuming we're talking about your own domain, why aren't you using split DNS and declaring 10.x.x.x as a valid source in your internal SPF record (but not the one you expose to the outside world) Split DNS only applies if the mail is on the inside which it isn't. There actually isn't an inside network at all, except for this one non-routed private network used for monitoring physical gear. It does not route to the outside world, with the exception of mail relay. Obviously, putting 10/8 into the published SPF record makes no sense at all, nor does adding 10/8 to the trusted_networks. Why do neither of those options make sense? I do both in my network, albeit that version SPF is only in my internal view, and I actually use 10.xx.0.0/16 not 10/8. (I only use a /16, not the whole /8) No internal view, no internal DNS. Putting 10/8 into external DNS is nonsense ;-) Is there some detail that's missing here? ie: do you have a compelling reason to not trust your internal hosts using 10/8? Those internal hosts cannot connect to the mail server directly. Any 10.x address that does connect to the mailserver is guaranteed to be a spammer. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness
Re: how to stop SPF checks from going past trusted host?
On Fri, Jun 20, 2008 at 12:12:45AM -0400, Matt Kettler wrote: That is correct, SPF checks are applied to the first untrusted host Henrik K wrote: Matt, you should know better. ;) It's first _external_ host. On Jun 20, 2008, at 3:54 AM, Matt Kettler wrote: Doh.. my bad. Huh? How are you defining external in this context? What prevents me from trusting an external hosts? I don't actually have any internal hosts -- no NAT, no firewall, it's all outside. There's hosts I trust, but none that aren't external. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness
Re: how to stop SPF checks from going past trusted host?
On Fredag, 20/6 2008, 05:37, Jo Rhett wrote: I'm trying to figure out how to stop SPF_FAIL on messages generated on an internal rfc1918 network and routed through a trusted host. On Jun 20, 2008, at 10:37 AM, Benny Pedersen wrote: netconsonance.com. IN TXT v=spf1 ip4:64.13.134.178 ip4:64.13.143.17 ip4:209.157.140.144 mx ~all not you ? Nope ;-) -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness
Re: how to stop SPF checks from going past trusted host?
On Jun 20, 2008, at 10:44 AM, Henrik K wrote: On Fri, Jun 20, 2008 at 10:28:25AM -0700, Jo Rhett wrote: On Fri, Jun 20, 2008 at 12:12:45AM -0400, Matt Kettler wrote: That is correct, SPF checks are applied to the first untrusted host Henrik K wrote: Matt, you should know better. ;) It's first _external_ host. On Jun 20, 2008, at 3:54 AM, Matt Kettler wrote: Doh.. my bad. Huh? How are you defining external in this context? What prevents me from trusting an external hosts? Nothing prevents you from trusting external hosts, you should do it as necessary. Here we go again.. internal_networks = internal/external trusted_networks = trusted/untrusted Both define borders which things are checked against. Internal is your MX-border, against which SPF and RBL checks are made (all internal must be in trusted also). Trusted can expand further to prevent RBL checks against trusted hosts and allows kind of whitelisting with ALL_TRUSTED rule. Okay, so my understanding is correct. So why did you correct Matt? He said first untrusted host. You said first external host. If internal hosts must all be trusted, and some external hosts may be trusted, then the SPF check would be applied to the first untrusted host, not the first external host. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness
trusted_host breaks pretty much every form of whitelist
I just realized something re: the previous message about SPF failure. trusted_hosts is also apparently blocking whitelist_from_rcvd from working. This is getting out of control. I understand the original intent here, but basically what is happening is that by making a host trusted you are basically saying to ignore SPF whitelist_from_* etc... Everything that says any message from this host is good is compromised/broken. Honestly, I think we need two separate forms here: trusted_relays should be what trusted_hosts is today. We trust that this host won't add false headers to the e-mail. If you read the description of trusted hosts, that's clearly what the rule is meant to do. trusted_hosts should mean no, we really truly trust this host and want everything it gives us -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness
Re: how to stop SPF checks from going past trusted host?
On Jun 19, 2008, at 9:21 PM, John Hardin wrote: /from \S+\.svcolo\.com (\S+ \[10\.\d+\.\d+\.\d+\]) by arran\.svcolo \.com (/ You actually need some backslashes too, but I figured it out. Thanks. See my other note about trusted_hosts breaking all forms of whitelisting, FYI. This kind of hackery (although appreciate the help) is kindof nonsense :-( -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness
Re: how to stop SPF checks from going past trusted host?
On Jun 20, 2008, at 11:49 AM, John Hardin wrote: 10.x is (supposedly) not routable on the public internet. If you see 10.x (or other RFC-1918) traffic coming in from the world, your ISP is broken. You don't run packet sniffers on your hosts much, do you? ;-) Does your ISP filter egress packets on your interface? No, neither does mine ;-) (and in this case I control the border routing so I know it for sure) Most competent ISPs will filter customer interfaces to prevent bogons, and some will filter public peering ports for bogons, but even with both of those a surprising number of 10.x packets make their way to our hosts. belt-and-suspenders: Even if it's unlikely for a 10.x packet to reach the host, why should I trust it? -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness
Re: how to stop SPF checks from going past trusted host?
On Jun 20, 2008, at 12:23 PM, Henrik K wrote: Jo, you are unbelievable in a funny way. You always come up with dozens of posts seemingly with the attitude I must be right. You don't configure things like they should be, and then complain that things don't work. Just set up the friggin networks right and let's continue normal life. If you need help, post your detailed setup so we don't need to guess. :-) etc I'm really not sure what you are saying here, and it's very hard not to read this offensively. I certainly have never said I must be right in any form whatsoever, and I certainly don't think it. I also don't have the vaguest clue what you mean by suggesting that I don't configure things like they should be -- most of my configurations are very plain and generic. And exactly as they should be, per the documentation. The only things I can think you might have a problem with: 1. Not trusting that 10.x packets can't reach my host * I always do belt-suspenders, and assume that an outside layer of protection might fail 2. Not routing internal networks that don't need internet access directly to an outside host * Um... why should I? Minimal requirement, minimal risk... How exactly are these things not the way they should be? If you mean something else, please explain. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness
Re: how to stop SPF checks from going past trusted host?
On Jun 20, 2008, at 12:44 PM, Henrik K wrote: You _need_ to have everything internal, so there will be no SPF lookups. Your fear of IP spoofers makes no sense to me, how do you think someone could accomplish that? Just put the 10.something there. You could have said that a lot easier ;-) Unfortunately our hosts are public in a big datacenter, and on the honeypot machines in the same network I see lots of packets and even well designed (blind) TCP sessions from 10.x hosts. It just doesn't make sense to trust anything received from a 10.x host. Especially because my 10.x hosts can't talk to this machine. It would be one thing if I could say trust 10.x hosts that relay via these- other-hosts but I can't :-( Since the trust list is single layer, adding 10.x means trusting random-source packets. I'd rather use the meta rule I created looking for the relay hosts. 10.x blind TCP streams are uncommon, but someone guessing the exact IP ranges and hosts involved much less so. (I modified the rule quite extensively to limit only the hosts which send mail) So I can understand why you might feel that I'm being overly cautious, but I'm not sure how you would think I'm doing it wrong? -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness
Re: trusted_host breaks pretty much every form of whitelist
On Jun 20, 2008, at 12:10 PM, Henrik K wrote: whitelist_from_rcvd is checked on external (internal_networks) border. If you set up internal and trusted right, there are no problems. Why not allow me to say I trust everything from this host no matter what? I could possibly set internal_networks to be less than trusted hosts... that would likely fix it. But before I go configure it all wrong tell me why this would be bad. (no MX relays in our environment at all) -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness
Re: trusted_host breaks pretty much every form of whitelist
On Jun 22, 2008, at 10:12 AM, Matt Kettler wrote: The only case an unlimited trust would be useful is if you trust the mail, even if the host relays mail from untrusted hosts. But if the sources are untrusted, why are you trusting the mail just because it came through some super-trusted server? As described in previous e-mails, host A cannot talk to host C except to relay via host B. Host A is trusted if relayed by host B. (anything is trusted if relayed by host B) If Host A appears to be connecting to host C, then it's a forged IP and I don't trust it. That's the nature of the problem. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness
Re: trusted_host breaks pretty much every form of whitelist
On Jun 20, 2008, at 1:19 PM, Henrik K wrote: You should know by now what SA network settings do. I don't know how complex your setup really is for them not to work. It's not complex at all. Everything is external, there are no firewalls. All public IP space documented in the external DNS. One host is bastion host that is also connected to a private network with no routing to the internet. Several machines on this private network are configured to route mail via the bastion host. I trust anything from the private network relayed by the bastion host. I don't trust anything that appears to be from the private network that actually directly reaches my mail server. The mail server has no ability to actually route a packet to that private network, so this is clearly a forgery. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness
Re: how to stop SPF checks from going past trusted host?
On Jun 20, 2008, at 1:13 PM, Henrik K wrote: On Fri, Jun 20, 2008 at 12:58:55PM -0700, Jo Rhett wrote: On Jun 20, 2008, at 12:44 PM, Henrik K wrote: You _need_ to have everything internal, so there will be no SPF lookups. Your fear of IP spoofers makes no sense to me, how do you think someone could accomplish that? Just put the 10.something there. You could have said that a lot easier ;-) I try not to spoon-feed people, I get to the point and give facts that should be enought to solve things. No, I meant without the insults, then the kindof apology and restatement ;-) Doesn't matter, it was meant to be funny and I clearly failed ;-) There has been a lot of talk already about internal/trusted/borders, and it should be quite clear what you need to do to accomplish what you asked. Actually, not really. I totally understand the internal/trusted/ borders in the context of a normal environment with a DMZ, firewall, and especially with /24 networks. I keep finding that things get really wonky when everything is public and smaller, ARIN-acceptable / 27 and smaller networks are in use ;-) I understand the answer of what internal and trusted networks should do. I'm just not getting how I can use these properly in an all public (ie little trust) network. I'm beginning to think I should reduce the trusted networks to 127.0.0.1 - even though I do trust some hosts, it would actually reduce the score of mail I really need to get ;-) Well, even if you are doing things right, unfortunately it won't work for with SA. You know the documented and supported way, which works fine for 99% of people. Um, not really. The documented and supported way has no method of handling my problem :-( It should be no problem to limit hostB to accept mail only from hostA in 10.x. If you want to be sure, use TLS certificates to identify your servers or something similar. This doesn't have anything to do with SA anymore. hostB is the relay, right? It already has those limitations. I'm just trying to get hostC to accept the mail from hostA via hostB, without accepting mail that claims to be from hostA. Because hostA can't talk to hostC, and hostA's address is widely mis-used ;-) -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness
Re: how to stop SPF checks from going past trusted host?
On Jun 20, 2008, at 1:52 PM, mouss wrote: I've never had an ISP/hoster block bogons, but I've never let them in. it's part of the first rules in ipf/pf/iptables/router/$FW (and in both directions. so my networks never send packets with bogon IPs to the internet). if you don't partition the network correctly, you'll have a lot of problems trying to deal with such annoyances. There is no network to partition. Or rather, 99% of my hosts provide the network, and I have two - total 2 - that provide host services. I'm not going to build a firewall and move these two hosts behind the firewall. Sorry, it causes more problems than it solves. Yes, I could use a local firewall on both hosts. But belt and suspenders again says why should I trust something that should never reach me? (this appears to be diverging into a network design discussion and is thus irrelevant in scope) -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness
Re: how to stop SPF checks from going past trusted host?
On Jun 22, 2008, at 4:09 PM, Jonas Eckerman wrote: If you do get a connection attempt from a non routable address on your SMTP servers external interface, you should have no way to acknowladge the connection if your own border router is configured correctly. You are assuming that there is enough infrastructure to provide a border router. In this case I would buy a border router and connect a single host to the inside port and the outside port to my uplink. It's a waste of hardware, and provides no value in the configuration.Because again, why should the host trust an IP address which should never reach it? -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness
Re: how to stop SPF checks from going past trusted host?
On Jun 22, 2008, at 8:22 PM, Matt Kettler wrote: Just because a packet can get theredoesn't mean they can deliver mail. (by the way, IMO you're *insane* for not having a something in place that filters such things. A simple PIX firewall at your border with ip verify reverse-path enabled would do the job nicely. On a budget simple ACLs in your border routing would do. Step up to at least 1980's grade network security. seriously.) Matt, what exactly does insulting me gain you, me, or this list? Really? Better yet, what does insulting me from an incorrect assumption gain you? My border router is a Force10 E-series system with 10gig interfaces. We have full line-speed RPF on every interface (unlike most providers) and we do a lot of work to keep the network secure. This is significantly better than 1980s networking. And I was in the 1980s building networks (when 1mb/sec LAN was fast and 32k was a big wan link) and you were not, so I'm really not sure what point you are trying to make. I know from reading your posts that you're a smart, level-headed guy. Let's forget you said this and focus on real responses that elevate the conversation, rather than just piss both of us off, ok? Because this post didn't help anyone, but did make me think a lot less of you. FYI: I spent nearly 20 years as a consultant. And I've been to dozens of networks where someone pointed out to me that certain attacks weren't possible -- like IP spoofing against a PIX with reverse-path enabled. And in every case, the impossible was pretty darn easy. My favorite was a site that realized their firewall wasn't working when their internal Word documents were found indexed on Altavista. The site engineer and the firewall service provider claimed this must have been exported illegally, and showed me the configuration. Yes, it worked on paper ;-) I've not seen such mass IP forgery going on. Have you? Of course not, because it pretty much can't be done. With a statement such as this you demonstrate that you aren't in the security field, and don't read either security papers or security mailing lists ... so I'm really not sure how to respond to you, honestly. I'm not trying to be rude, but your statement has no basis in reality. Not only can it be done for given short-term purposes, but there are at least 3 toolkits which test systems and then generate entire forged TCP streams at the hosts. They are remarkably effective. I haven't found one which works 100% against modern FreeBSD, which is what we are running, but that doesn't mean it doesn't exist. And a toolkit which takes 100 or 200 attempts to succeed... is easy to accomplish on multi-gig networks without raising even the slightly alarm. Perhaps you want to show me the syslog message your system generates when it receives a TCP session id that isn't in use? No, my operating system doesn't generate one either. (however my IDS will notice this and log it, but that doesn't mean my mail server should trust it) NOW perhaps we can stop talking about networking? Because this isn't about networking, really. It's about SpamAssassin. I don't want my spamassassin to trust something it shouldn't receive. That's the nature of the question. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness
Re: how to stop SPF checks from going past trusted host?
On Jun 23, 2008, at 12:23 AM, Matus UHLAR - fantomas wrote: it one packet reaches your host, nothing happends. Fot the TCP/SMTP connections to be opened, (at least) three packets must be sent, in both directions. If you can trace to 10.x address that is not part of your network, it's a problem. Solve this problem by configuring of your network, firewalls, asking your ISP to do the same. Do not try to solve this problem at SA level. Trust me that I know a lot about IP networking, and your assumptions are incorrect. (why are people so willing to assume the worst and insult others based on their own assumptions?) Finally, nearly every major compromised network I've seen in my life was broken into because one layer assumed that a given other layer would prevent X Y or Z from happening. System crackers love it when security has implicit assumptions ;-) I'd love to say nothing I have ever built has ever been cracked, but that's not true. But nothing of mine that was ever cracked was due to incorrect assumptions in the design, just due to vulnerabilities in the applications put on the platform. But because I secured every layer as if it was the only layer, no compromise has ever extended farther in the environment, either on the compromised system itself or further into the network we were protecting. Yes, it's a PITA to think this way. But it's the only way to keep things truly secure. NOW, let's return to securing SA properly. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness
Re: trusted_host breaks pretty much every form of whitelist
On Jun 25, 2008, at 2:50 AM, Matus UHLAR - fantomas wrote: As described in previous e-mails, host A cannot talk to host C except to relay via host B. Host A is trusted if relayed by host B. (anything is trusted if relayed by host B) If Host A appears to be connecting to host C, then it's a forged IP and I don't trust it. why to accept connecctions from anything but host B ? Because it's a public mail server which gets legitimate mail connections from all over the world. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness
Re: how to stop SPF checks from going past trusted host?
On Jun 25, 2008, at 2:34 AM, Henrik K wrote: This is getting out of hand and offtopic.. Yes You have already your options: - Add all hosts to internal_networks. - Don't call SA at all Why is this getting on and on? Why is it getting offtopic, I don't know. Why is the conversation still going on? Because I asked a few questions still unanswered -- reading the code it implies that maybe I should make internal_networks explicitly defined (right now its implicit and thus == trusted_networks) to be smaller than trusted networks. This will probably solve my SPF problem. Is there a reason not to do this? -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness
Re: how to stop SPF checks from going past trusted host?
On Jun 25, 2008, at 2:49 AM, Matus UHLAR - fantomas wrote: slovakia ended on machine at german machine. I know that something can be broken at this level. I just think that SA should not take care about this... Hm. Not sure I agree. I'm not asking SA to prevent it from happening. I just don't want SA to believe it either ;-) what you want requires big change in SA code that would probably cause new versions incompatible with newer versions of SA. I don't think anyone here want to go this way, instead of securing the network. I mean, if we can't trust local network, why should we trust anything external like DNS, blacklists etc? DNS blacklists are remarkably easy to forge DNS responses to, but the effort of doing so is still greater than the value. That's not saying we haven't seen this approach (we have -- still have sniffer dumps of it) etc and such forth. DoS attacks against the DSBL hosts are actually more effective in slowing down SA worldwide than anything else at the moment ;-) Anyway, the short version is that we don't trust it all that much. SA learns to work without trusting it all that much. Mostly works pretty well that way ;-) This is why I want to avoid explicitly telling SA to trust something it shouldn't if I can. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness
Re: how to stop SPF checks from going past trusted host?
On Wed, Jun 25, 2008 at 03:00:47AM -0700, Jo Rhett wrote: reading the code it implies that maybe I should make internal_networks explicitly defined (right now its implicit and thus == trusted_networks) to be smaller than trusted networks. This will probably solve my SPF problem. Is there a reason not to do this? On Jun 25, 2008, at 3:03 AM, Henrik K wrote: It's fine to do that. This is all documented on wiki etc. I don't know why it's still not clear. As both someone who writes tech documentation, and as someone who really isn't all that stupid on this topic, I would suggest that the wiki isn't necessarily as clear as you hope it would be. It does not spell out things like how internal_networks and trusted_networks interact with SPF and whitelist_from_rcvd. It makes statements that when you look at them later you realize oh, that's what they meant by that (I call to witness the large number of posts on this list that have read the wiki and still misconfigured trusted_networks) I'm not trying to attack/criticize the wiki, fyi. I'm trying to say this is perhaps less clear than it should be. Once I have it straight in my head I may well try to improve the wiki if I can think of a better way to describe it. Right now I'm just trying to make sure I have it right. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness
Re: trusted_host breaks pretty much every form of whitelist
Because it's a public mail server which gets legitimate mail connections from all over the world. I mean, why to accept connections from anything other? I don't understand your question. My only answer you quoted above. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness
Re: dsn from this maillist users :(
On Jun 25, 2008, at 1:53 PM, Bob Proulx wrote: What did you do differently between this message and the one that was rejected? Somehow you routed the other message through an unauthorized route. It is specifically configured to be rejected by your own domain configuration. Routine mail through grupointercom.com makes it look like a forgery. I got one for each message I sent to the list this morning. I certainly didn't choose to route any mail via that system, and I imagine no one else on here (other than the perp) willing chose to. Some person is doing SPF checks against the header address instead of the envelope address. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness
Re: how to stop SPF checks from going past trusted host?
On Jun 25, 2008, at 6:34 PM, Benny Pedersen wrote: then stop cc me X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=FM_FAKE_HELO_VERIZON,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of [EMAIL PROTECTED] designates 206.46.173.3 as permitted sender) Received: from [206.46.173.3] (HELO vms173003pub.verizon.net) (206.46.173.3) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 26 Jun 2008 00:56:44 + What exactly does CCing someone have to do with bouncing back incorrect SPF failure messages? I'm sorry, but you're a constant source of backscatter, Benny. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness
MODERATION REQUEST: how to stop SPF checks from going past trusted host?
On Jun 26, 2008, at 5:43 PM, Benny Pedersen wrote: and you are a constant ignorant sending me cc get a life Personal attacks are not relevant to the topic. Sending someone a CC to a message they sent, and to which their mail headers sets reply-to, is only a problem in Bennys mind. But he sends backscatter because he doesn't like the behavior, even though he could easily configure his mailer so that when people hit reply it does what he wants it to. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness
Re: how to stop SPF checks from going past trusted host?
Dave, what are you complaining about? This thread went sideways without my involvement. I was replying to someone else's query about Benny's mail servers sending back random SPF failure backscatter messages. On Jun 26, 2008, at 5:22 PM, Dave Koontz wrote: Jo, didn't you get your answer several times now? I don't understand why this thread continues. Jo Rhett wrote: On Jun 25, 2008, at 6:34 PM, Benny Pedersen wrote: then stop cc me X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=FM_FAKE_HELO_VERIZON,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of [EMAIL PROTECTED] designates 206.46.173.3 as permitted sender) Received: from [206.46.173.3] (HELO vms173003pub.verizon.net) (206.46.173.3) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 26 Jun 2008 00:56:44 + What exactly does CCing someone have to do with bouncing back incorrect SPF failure messages? I'm sorry, but you're a constant source of backscatter, Benny. -- *Dave Koontz* (MCSE/GCIH) Associate Director Computer Information Services *Mary Baldwin College* Email: [EMAIL PROTECTED] Phone: (540) 887-7399 http://www.mbc.edu/ -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness
Re: bad rules that likely to result in more false positives
On Jul 3, 2008, at 12:14 AM, Matus UHLAR - fantomas wrote: Please, don't send private replies, I did not ask for them. On 02.07.08 21:32, Jari Fredriksson wrote: Its impossible to know who wants them, and who does not. my mail headers contain Mail-Followup-To: header that is only sent to the list. That means that replies should be sent to the list. I'm sorry, but what MUA recognizes those? Why don' t you set Reply- To: which will be honored by all MUAs? If anyone wants private copies, (s)he should ask for them. This is a mailing lists and all members receive all mail posted to it. Even non- members can read it all in archives. He is acted as is common and expected. Others who, like you, don't want private copies set Reply-To. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness
Re: Increase in Spam
Steve Lake wrote: Oh, this sounds spectacular. One question. Is there a port on Freebsd for this? I don't see one offhand. If there is, then that would assume that all the other necessary ports are present as well. If not, it'll be a royal b trying to get the nix versions installed instead if no freebsd ported versions are available. :( So go make one :-) It's easy enough. -- Jo Rhett Network/Software Engineer Net Consonance
Re: Any comments of the SpamHaus lawsuit?
Bill Horne wrote: If this company succeeds in cutting off spamhaus's domain, the Cartooney letters will start to be real. At that point, the options open to the army of private citizens who've been fighting spam ...etc I'm sorry, I've watched this thread go longer and longer about all the potential damage, and this is getting silly. All that SPEWS has to do if they *must* be compliant (which I doubt) is to create a separate domain for US users that is compliant with the lawsuit. Put up something saying this list is for US users in compliance with ... Nobody will use the US list, but they are compliant with the judgement for all US users, which is all the US court has authority for. -- Jo Rhett Network/Software Engineer Net Consonance
Re: A problem with AWL
Chuck Payne wrote: I got a problem with a lot spam coming thru and it looks like the main reason is that AWL is on every test and when that is no there it give the e-mail negative points. How can I turn of AWL? And if I turn it off will effect domain and users on my list that I have that are whitelisted? AWL has no relationship to the normal whitelist. But you really don't want it turned off, you want to fix the reasons why spam from these parties is getting good scores on the first attempt... FYI: PLEASE!! don't reply to a message and change the subject. Your message got threaded in with the previous topic. On most days, I ignore any such messages. The vast majority of other smart people do the same. To start a new thread, use Compose Mail To or whatever your client has... -- Jo Rhett Network/Software Engineer Net Consonance
Re: Any comments of the SpamHaus lawsuit?
Christopher Martin wrote: Really, the idea that a US courts can order an international organisation, like InterNIC (that's the Inter- bit of InterNIC), to deregister a domain is Sorry, you lost me right there. That's not where the name derived from originally. Unless you were kidding, and I missed a smiley somewhere that showed that you knew better. -- Jo Rhett Network/Software Engineer Net Consonance
Domain names (Was: Any comments of the SpamHaus lawsuit?)
Bookworm wrote: Just as a FYI, .com, .org, .edu, .mil, .gov, and .net were developed by the US when DNS was first being conceptualized. There were enough computers on the (D)ARPNET backbone that it was getting confusing to track hosts files. At that point, there wasn't a .us, .au, .gb, .de, or the others. Those came slightly later. (trimmed) Incorrect. .us has existed for nearly as long, but had really a fixed 3-layer structure that prevented most people from using it. The three layers only had structure for states, cities, etc. It meant to simplify, but it mostly confused non-techy people. Only recently was .us normalized so that it could be used by .us companies. -- Jo Rhett Network/Software Engineer Net Consonance
Re: Any suggestions for 'postmaster' spams?
Brian S. Meehan wrote: It appears that my email address is now being used as a from address in many spam emails to many addresses. Over the past week, I have gotten 150+ postmaster: mail delivery failure -each day-. Does anyone have suggestions on how to handle this? Yes. Implement SPF and DKIM policies to tell other sites how to interpret your mail. Right now, implementing both is good for 70% of the backscatter. -- Jo Rhett Network/Software Engineer Net Consonance
Re: Any suggestions for 'postmaster' spams?
jdow wrote: Not much you can do about it other than find a shotgun, go find the Please educate yourself before answering something like this. If you don't know the answer, perhaps it is best to sit quietly and wait for someone else to answer instead? The following two technologies greatly reduce the acceptance of forged spam, and thus reduce the backscatter too. http://www.openspf.org/ http://mipassoc.org/dkim/ There's also a ruleset for detecting forged bouncebacks, but it needs to be rewritten if you're hosting multiple domains. Hopefully the author will get to that, or I might submit a patch eventually :-) -- Jo Rhett Network/Software Engineer Net Consonance
Re: Any suggestions for 'postmaster' spams?
Benny Pedersen wrote: On Mon, October 16, 2006 00:16, Brian S. Meehan wrote: It appears that my email address is now being used as a from address in many spam emails to many addresses. Over the past week, I have gotten 150+ postmaster: mail delivery failure -each day-. is it with enveloppe from [EMAIL PROTECTED] ? if yes, make postfix reject FROM: postmaster will solve it nicely pcre_reject_no_real_user_map.pcre: /[EMAIL PROTECTED]/ REJECT Postmasters is nice main.cf: smtpd_sender_restrictions = ... check_sender_access pcre:/etc/postfix/pcre_reject_no_real_user_map.pcre ... do not make it to the recipient ! I'm not a postfix user, so clue me in. Doesn't this prevent local bounce messages from being delivered? I also believe that the original post was about backscatter, not forged postmaster mail. -- Jo Rhett Network/Software Engineer Net Consonance
Re: Any suggestions for 'postmaster' spams?
R Lists06 wrote: First suggestion, don't post to list with the email address you use for biz or personal use. Make another and use it for all lists. When you get spammed on it, change it slightly, unsub the other and sub the new to all the lists you are on. Uh. Yeah. Is it just me, or are all the dumb answers coming up today? Or, perhaps, run spamassassin and don't worry about changing your e-mail constantly? Duh? -- Jo Rhett Network/Software Engineer Net Consonance
Re: ALL_TRUSTED creating a problem
Magnus Holmgren wrote: A list search for ALL_TRUSTED would have given you tons of hits. You could also have gone to the FAQ page and from there to the FixingErrors wiki page, where you'd find a reference to ALL_TRUSTED. Magnus, to be fair - the search will tell you that autodetection should work unless you are behind a NAT. So a person who believes that without testing won't realize that they're looking at the problem. The autodetection is totally broken actually, and needs to be fixed. I've added a comment to the Wiki to let people know about this. -- Jo Rhett Network/Software Engineer Net Consonance
Vbounce (Was: Any suggestions for 'postmaster' spams?)
Justin Mason wrote: do you mean the one I posted about earlier, or the original? Sorry, I haven't looked at it in a while and wouldn't remember. Looking at yours - why don't use use the global parameters that specify trusted header hosts instead of adding your own? I can't think of a time I would trust the headers from a host, but wouldn't trust it for bounces... Also, I think (I don't have time to read the ruleset in detail right now) that it seems a bit harsh. The goal would be to identify only backscatter right? It seems likely to hit almost every bounce, yes? -- Jo Rhett Network/Software Engineer Net Consonance
Re: Concerned with scores for from rfc-ignorant.org
John Andersen wrote: On Thursday 12 October 2006 14:54, John Rudd wrote: That rule has a 3.2 value because the 3.2 value is accurate to differentiating spam vs ham in the corpus. Therefore, the score is appropriate. No, its not accurate. The rule is in-discriminant as to content. It flags ham with the same score as spam. Therefore by definition it is in-discriminant, and thus useless as in the prediction of ham vs spam. Zero that rule's score, and your false positives will fall, but your false negatives will not increase. The rule unfairly targets ham. That's completely untrue, comparing my ham and spam. Not just mostly untrue, but absolutely and completely untrue. I got two HAM messages with this set (but only this and not enough to filter on) and nearly every spam either had this or was picked up by SPF or DKIM rules (was a forged mail from a domain which had a postmaster) And John, there are metrics used to test this. Implement the testing environment for yourself, and come up with real metrics before saying this kind of absolute-statement-no-caveat nonsense. -- Jo Rhett Network/Software Engineer Net Consonance
Re: Vbounce (Was: Any suggestions for 'postmaster' spams?)
Justin Mason wrote: Jo Rhett writes: Justin Mason wrote: do you mean the one I posted about earlier, or the original? Sorry, I haven't looked at it in a while and wouldn't remember. Looking at yours - why don't use use the global parameters that specify trusted header hosts instead of adding your own? I can't think of a time I would trust the headers from a host, but wouldn't trust it for bounces... Tried, and it didn't work. :( Unfortunately, trusted_networks etc. is built on the IP address of trusted net ranges -- and that info doesn't appear reliably in most bounce DSNs. (I think there's a bugzilla item with more info.) Also, I think (I don't have time to read the ruleset in detail right now) that it seems a bit harsh. The goal would be to identify only backscatter right? It seems likely to hit almost every bounce, yes? it'll hit every bounce, and the MY_SERVERS_FOUND rule then rescues the legit bounces from that set. yeah, I thought so. It seems too simple for anything but single-domain servers. (or at least single-organization servers) I'll poke at it later and see if I can think up a better way to handle this. I'd include SPF results etc if I can reuse that information from the previous tests... -- Jo Rhett Network/Software Engineer Net Consonance
Re: Concerned with scores for from rfc-ignorant.org
On Monday 16 October 2006 10:11, Jo Rhett wrote: I got two HAM messages with this set (but only this and not enough to filter on) and nearly every spam either had this or was picked up by SPF or DKIM rules (was a forged mail from a domain which had a postmaster) John Andersen wrote: Thanks for proving my point. If the score for this rule was not enough to filter ham on it didn't contribute to the spam filtering materially either. None of the rules which triggered on any of my spam was enough by itself to catch it. That's not how spamassassin works. And I'm sure you know this. Sorry, I didn't realize you were trolling. -- Jo Rhett Network/Software Engineer Net Consonance
Re: Any suggestions for 'postmaster' spams?
John D. Hardin wrote: On Mon, 16 Oct 2006, Jo Rhett wrote: I am convinced that spam (in all its forms) will continue to be a problem until spammers start dying for what they are doing. That will change the risk/benefit analysis rather strongly towards the negative. So join WhackASpammer. You make a micropayment for each spam you receive from a spammer. When $50k has been reached for any given spammer, they are whacked. :-) NOTE: THIS IS A JOKE. I keep meaning to register the domain and put up a spoof site, but I haven't had the time to make sure I can't be sued for doing this -- Jo Rhett Network/Software Engineer Net Consonance
Re: Vbounce (Was: Any suggestions for 'postmaster' spams?)
Justin Mason wrote: why? Can you not simply list all the outgoing relays for the organizations/domains, or even a pattern that matches all of their names? How many outgoing relays do you have? (I'm not sure I understand the problem here.) Okay, let's go with my personal colo box. It's the simplest. I can't imagine trying this on a production mail server. There are 24 domains here. * 7 are mine or under my control and origin only here. No problem. * 12 or so I know enough about to make some reasonable guesses. * 5 domains I know nearly nothing about. And seriously, these are all domains of close personal friends. AND of those 24 domains, almost *EVERY* one of them has someone in the domain who is sending mail via their ISP either because they are forced to, they want to for some misguided reason, or they are just too inept to change their mail server settings. This makes source sending address information difficult to detect using manually configured host headers. I'd rather use SPF and/or DKIM information (or any other information we can determine dynamically) to determine if the message was originally a forgery. This has the dual added benefit of providing backscatter protection only for the domains who are protecting others against their forgeries. -- Jo Rhett Network/Software Engineer Net Consonance
Re: How to filter these spam messages
Logan Shaw wrote: I guess the problem with being an ISP is that there would be other ISPs who would be willing to not try to adjust their expectations and instead promise them super-speedy e-mail delivery in all cases. The fact that it isn't possible to deliver on that promise might not matter if they still manage to take away your customers. :-) Exactly so. At an ISP I did some work for, I used to argue this until people very reasonably pointed out that yahoo mail got delivered faster, and it was free. Yahoo averages ~2 minutes for mail delivery. That sets the bar for anyone who is trying to sell their mail services. -- Jo Rhett Network/Software Engineer Net Consonance
