Re: how to stop SPF checks from going past trusted host?
Matus UHLAR - fantomas wrote: ... and I thought I explained it in the sentence before. Since DNS lookup is not made by MTA and SA expects it to be, the case where the RDNS is not in Received: is taken as there is not rdns. Since there is verison's HELO but not RDNS, it's FM_FAKE_HELO_VERIZON... As another Qmail user I can tell you this did indeed use to work and SA was changed in 3.2.1 (see archives from July 2007) so that it stopped doing it's own DNS lookups for data from the Received: headers and started relying on what was written in there instead. I don't use qsmtpd myself, but assuming it's like qmail-smtpd, you should find that if you enable DNS lookups in tcpserver (ie the -H option), then that information will show up and SA will start playing nice again. -- Cheers Jason Haar Information Security Manager, Trimble Navigation Ltd. Phone: +64 3 9635 377 Fax: +64 3 9635 417 PGP Fingerprint: 7A2E 0407 C9A6 CAF6 2B9F 8422 C063 5EBB FE1D 66D1
Re: how to stop SPF checks from going past trusted host?
Matus UHLAR - fantomas wrote: [snip] IIRC there was already case provided when MTA didn' dns lookup so it was made to be done via SA (and afaik SA did it before). If my memory is correct, this would be just another case (sorry, no time to search archives/bugs/google by now) yes, it is probably better to make rules that need rDNS to work than disable them or change them. but 1- if the goal is to check helo, then we could try to resolve it. it it resolves and matches, it's good. I admit that this adds a DNS lookup, but SPF (among other things) already does more... 2- in the case under discussion, does it really matter if helo is forged when a verizon user sends from a verizon authorized host according to SPF? and anyway, there's no reason to believe helo is forged since $ host vms173003pub.verizon.net vms173003pub.verizon.net has address 206.46.173.3 sice there's no DNS name in received and SA doesn't translate IP, it assumes that there is no DNS so the helo is forged. I don't know why Benny got FM_FAKE_HELO_VERIZON. ... and I thought I explained it in the sentence before. I was unclear. let me restate. I don't know if Benny disables rDNS on his server (in which case he can enable it and the problem is fixed) or if he gets mail from a remote server that is not under his control (be that relay or fetchmail). Since DNS lookup is not made by MTA and SA expects it to be, the case where the RDNS is not in Received: is taken as there is not rdns. Since there is verison's HELO but not RDNS, it's FM_FAKE_HELO_VERIZON...
Re: how to stop SPF checks from going past trusted host?
Matus UHLAR - fantomas wrote: IIRC there was already case provided when MTA didn' dns lookup so it was made to be done via SA (and afaik SA did it before). If my memory is correct, this would be just another case (sorry, no time to search archives/bugs/google by now) On 29.06.08 16:04, mouss wrote: yes, it is probably better to make rules that need rDNS to work than disable them or change them. but 1- if the goal is to check helo, then we could try to resolve it. it it resolves and matches, it's good. I admit that this adds a DNS lookup, but SPF (among other things) already does more... we do not resolve HELO, but the reverse DNS. and as I already said, this feature in SA was deactivated and in the SMTP server it's not working. Of course I know it would be good but since I am not SA developer, and since I think that MTA should do that... 2- in the case under discussion, does it really matter if helo is forged when a verizon user sends from a verizon authorized host according to SPF? you can send a wishlist report... I don't know why Benny got FM_FAKE_HELO_VERIZON. ... and I thought I explained it in the sentence before. I was unclear. let me restate. I don't know if Benny disables rDNS on his server (in which case he can enable it and the problem is fixed) or if he gets mail from a remote server that is not under his control (be that relay or fetchmail). I guess its' the former one... see other post in this thread :) -- Matus UHLAR - fantomas, [EMAIL PROTECTED] ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. How does cat play with mouse? cat /dev/mouse
Re: how to stop SPF checks from going past trusted host?
Matt Kettler wrote: [snip] if so that fake helo should not be fake :=) Well, it shouldn't be fake, because 206.46.173.3 really is vms173003pub.verizon.net. However, it would appear that athena.apache.orgdidn't get an answer to its PTR querry.. either that or the headers generated by athena.apache.org are just broken. On 27.06.08 14:45, mouss wrote: qpsmtpd headers do not show rDNS. Matus UHLAR - fantomas wrote: bad. SA afaik doesn't resolve IPS in headers, it expectd MTA to use it. iirs there was some discussion about MTA's not doing that, Maybe it could do that for such MTAs (check list archive) On 27.06.08 16:00, mouss wrote: This would indeed fix the problem. but I'm not sure if it won't cause trouble for those who use fetchmail (given that many rDNS setups are borked, I mean). IIRC there was already case provided when MTA didn' dns lookup so it was made to be done via SA (and afaik SA did it before). If my memory is correct, this would be just another case (sorry, no time to search archives/bugs/google by now) and anyway, there's no reason to believe helo is forged since $ host vms173003pub.verizon.net vms173003pub.verizon.net has address 206.46.173.3 sice there's no DNS name in received and SA doesn't translate IP, it assumes that there is no DNS so the helo is forged. I don't know why Benny got FM_FAKE_HELO_VERIZON. ... and I thought I explained it in the sentence before. Since DNS lookup is not made by MTA and SA expects it to be, the case where the RDNS is not in Received: is taken as there is not rdns. Since there is verison's HELO but not RDNS, it's FM_FAKE_HELO_VERIZON... -- Matus UHLAR - fantomas, [EMAIL PROTECTED] ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Spam = (S)tupid (P)eople's (A)dvertising (M)ethod
Re: how to stop SPF checks from going past trusted host?
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/
Re: how to stop SPF checks from going past trusted host?
Matt Kettler wrote: [snip] if so that fake helo should not be fake :=) Well, it shouldn't be fake, because 206.46.173.3 really is vms173003pub.verizon.net. However, it would appear that athena.apache.orgdidn't get an answer to its PTR querry.. either that or the headers generated by athena.apache.org are just broken. qpsmtpd headers do not show rDNS. and anyway, there's no reason to believe helo is forged since $ host vms173003pub.verizon.net vms173003pub.verizon.net has address 206.46.173.3
Re: how to stop SPF checks from going past trusted host?
Matt Kettler wrote: [snip] if so that fake helo should not be fake :=) Well, it shouldn't be fake, because 206.46.173.3 really is vms173003pub.verizon.net. However, it would appear that athena.apache.orgdidn't get an answer to its PTR querry.. either that or the headers generated by athena.apache.org are just broken. On 27.06.08 14:45, mouss wrote: qpsmtpd headers do not show rDNS. bad. SA afaik doesn't resolve IPS in headers, it expectd MTA to use it. iirs there was some discussion about MTA's not doing that, Maybe it could do that for such MTAs (check list archive) and anyway, there's no reason to believe helo is forged since $ host vms173003pub.verizon.net vms173003pub.verizon.net has address 206.46.173.3 sice there's no DNS name in received and SA doesn't translate IP, it assumes that there is no DNS so the helo is forged. -- Matus UHLAR - fantomas, [EMAIL PROTECTED] ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Quantum mechanics: The dreams stuff is made of.
Re: how to stop SPF checks from going past trusted host?
Matus UHLAR - fantomas wrote: Matt Kettler wrote: [snip] if so that fake helo should not be fake :=) Well, it shouldn't be fake, because 206.46.173.3 really is vms173003pub.verizon.net. However, it would appear that athena.apache.orgdidn't get an answer to its PTR querry.. either that or the headers generated by athena.apache.org are just broken. On 27.06.08 14:45, mouss wrote: qpsmtpd headers do not show rDNS. bad. SA afaik doesn't resolve IPS in headers, it expectd MTA to use it. iirs there was some discussion about MTA's not doing that, Maybe it could do that for such MTAs (check list archive) This would indeed fix the problem. but I'm not sure if it won't cause trouble for those who use fetchmail (given that many rDNS setups are borked, I mean). and anyway, there's no reason to believe helo is forged since $ host vms173003pub.verizon.net vms173003pub.verizon.net has address 206.46.173.3 sice there's no DNS name in received and SA doesn't translate IP, it assumes that there is no DNS so the helo is forged. I don't know why Benny got FM_FAKE_HELO_VERIZON. Whan I get direct mail from Matt, it does not trigger this rule, because my postfix does rDNS lookup. When I get his mail via the list, I don't go deep past the list server. so it's ok in both cases. but maybe he is using fetchmail or similar?
Re: how to stop SPF checks from going past trusted host?
Benny Pedersen wrote: On Fredag, 20/6 2008, 10:04, Henrik K 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. Matt, you should know better. ;) It's first _external_ host. and is most of the time olso first untrusted ? :) both is imho correct On 25.06.08 20:54, Matt Kettler wrote: Generally yes, although there are some odd cases where these differ odd? :) they are two settings just so they could differ (so we could trust some host while not taking them as internal). (only happens when you set it this way manually for various not-typical network reasons, like those who accept mail from authenticated users on dialup IPs.). Not only. We trust our dialup users until we'll force them to SMTP AUTH. But we may trust some other mailservers (freemails) that relay mail, so we won't check for blacklists them, but machines they are relaying from (which may be bad if they whitelisted their dialups, but that's different story) -- Matus UHLAR - fantomas, [EMAIL PROTECTED] ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Windows 2000: 640 MB ought to be enough for anybody
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
Re: how to stop SPF checks from going past trusted host?
On Fri, June 27, 2008 02:08, Jo Rhett wrote: I'm sorry, but you're a constant source of backscatter, Benny. and you are a constant ignorant sending me cc get a life -- Benny Pedersen Need more webspace ? http://www.servage.net/?coupon=cust37098
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: how to stop SPF checks from going past trusted host?
Benny Pedersen wrote: On Thu, June 26, 2008 04:40, Matt Kettler wrote: I'll attempt to do so. Didn't realize you disliked it. its like asking 2 times for the same answer and wonder why no answer Well then set a Reply-to header to point to the list when you post here... That's what the header's for, and your MUA is the only RFC compliant spot that header should be generated. I'm SA interpreted the Received header as meaning that athena.apache.org found no reverse-lookup the host, and that 206.46.173.3 is a host with no reverse DNS claiming to be vms173003pub.verizon.net. At least, that's how I'd read that header.. the FM_FAKE_HELO_VERIZON is likely an early rule trying to detect hosts using verizon helo's that aren't really verizon hosts. well i asked if you know reverse dns patterns olso for verizon net or if verizon olso know there trouble ?, few years i have seen spam from verizon but not more then from others, it could nice to know atleast for me if thay use smtp auth and or what there outgoing host is for this if any, maybe you use smtp auth now on this msg here ? if so that fake helo should not be fake :=) Well, it shouldn't be fake, because 206.46.173.3 really is vms173003pub.verizon.net. However, it would appear that athena.apache.orgdidn't get an answer to its PTR querry.. either that or the headers generated by athena.apache.org are just broken.
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: how to stop SPF checks from going past trusted host?
On Wed, Jun 25, 2008 at 02:18:01AM -0700, Jo Rhett wrote: NOW, let's return to securing SA properly. This is getting out of hand and offtopic.. You have already your options: - Add all hosts to internal_networks. - Don't call SA at all Why is this getting on and on?
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. On 25.06.08 02:18, Jo Rhett wrote: 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?) Well, I remember the time in 90's when telnet to 192.168.* address from 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... NOW, let's return to securing SA properly. 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? -- Matus UHLAR - fantomas, [EMAIL PROTECTED] ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. (R)etry, (A)bort, (C)ancer
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 Wed, Jun 25, 2008 at 03:00:47AM -0700, Jo Rhett wrote: 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? It's fine to do that. This is all documented on wiki etc. I don't know why it's still not clear.
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: how to stop SPF checks from going past trusted host?
Jo Rhett 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. Yes that was my assumption. If you haven't got your own border router, then the router(s) your provider(s) uses to route packets between your public network and the Internet is/are the border router(s). Wich of course makes everything different since you can't make sure those routers are configured correctly. :-/ So please disregard my comment about your border router. Because again, why should the host trust an IP address which should never reach it? I don't know, and I never suggested you do. Then again, the trust setting in SA is about trusting Received headers and not only about trusting hosts that connect directly to the system. So in order to have a working unbroken trust path that correctly mirrors reality it *might* be neccessary to include hosts that relays mail but never connects directly to the server running SA. Whether this applies to your system or not is something I'm currently not qualified to have an opinion about. Regards /Jonas -- Jonas Eckerman, FSDB Fruktträdet http://whatever.frukt.org/ http://www.fsdb.org/ http://www.frukt.org/
Re: how to stop SPF checks from going past trusted host?
On Wed, Jun 25, 2008 at 03:08:48AM -0700, Jo Rhett wrote: 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 agree fully. At the moment even some SA rules have it wrong (using trusted instead of external). IMO it should be forced for users to configure internal_networks also, instead of just setting trusted_networks, which then translates to it. It all comes to the fact that internal_networks is your MX border. All SPF, HELO, RBL etc checks are done on that. Feel free to make it more clear on the wiki. Instead of How can I optimize the trusted_networks setting? it should be How you MUST set *_networks. I'm bad at documenting, so count me out. ;-)
Re: how to stop SPF checks from going past trusted host?
Jo Rhett wrote: 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? Fair enough. I mis-read your post to assume that nobody was filtering such bogus packets. You were merely talking about your ISP not filtering them, which apparently is a non-issue since you filter them yourself. I'm not quite so sure why you raised it as a problem of concern, but fair enough. My apologies. So if your border is filtering such bogus packets, why are you still worried about an outsider convincing your mailserver is delivering mail from a 10.* ip? Are you concerned about this attack from within your network somewhere that isn't subject to filtering? Or are you concerned they're going to bypass your filtering in some manner? Again, this is about an outsider delivering mail to your mailserver an convincing it that 10.x.x.x, an internal subnet, is delivering mail to it. Right? 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. Actually I do. I know about the TCP window based enhancement of the attack, etc. I also know a lot of those papers are highly theoretical, and don't work in reality across a broad internet. Again, if it really worked so well, you'd see a *LOT* of spam forging IPs. I've never seen one in the real world. 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. Ok, can you actually do it? Can you deliver mail to an outside network's SMTP with a spoofed source IP that doesn't route back to you? I'm not saying blind spoofing is wholesale impossible. However, doing it long enough to deliver mail, and across an internet, and communicating with any sort of reasonable host with decent ISN generation, isn't practical. Add a reasonable firewall that's dropping packets from the source IP you're using and it becomes difficult beyond then realm of realistic attacks that a spammer would ever employ. (nobody's going to take the time to exploit your firewall just to deliver spam with a spoofed source address to your mailserver). 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) My OS wouldn't. I suspect the Cisco ASA would log these as Deny TCP (no connection), due to their ISN not matching any established connection, but I'd have to check if this logging occurs on ISN mismatch. But logs, while nice, won't really help you if an attacker is successful here. 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. True, but if you assume IPs can be spoofed, then SA can't trust anything at all. If they can spoof one IP, they can spoof anything. That's of great concern to SA, because it would break *many* things about SpamAssassin's fundamental design. Personally, I have yet to see evidence this attack can be successfully carried out over the internet well enough to deliver mail to a SMTP server on a blind basis.
Re: how to stop SPF checks from going past trusted host?
On Jun 25, 2008, at 2:34 AM, Henrik K wrote: You have already your options: - Add all hosts to internal_networks. - Don't call SA at all Why is this getting on and on? On 25.06.08 03:00, Jo Rhett wrote: 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? no. and if it will solve your problem, jusst do so. -- Matus UHLAR - fantomas, [EMAIL PROTECTED] ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. It's now safe to throw off your computer.
Re: how to stop SPF checks from going past trusted host?
Benny Pedersen wrote: On Fredag, 20/6 2008, 10:04, Henrik K 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. Matt, you should know better. ;) It's first _external_ host. and is most of the time olso first untrusted ? :) both is imho correct Generally yes, although there are some odd cases where these differ (only happens when you set it this way manually for various not-typical network reasons, like those who accept mail from authenticated users on dialup IPs.). It's a fine distinction, but one that does matter to some folks who are set up this way. In most cases the two are equal, but that doesn't excuse me from confusing the two. I should know better. :)
Re: how to stop SPF checks from going past trusted host?
On Thu, June 26, 2008 02:54, Matt Kettler wrote: It's a fine distinction, but one that does matter to some folks who are set up this way. In most cases the two are equal, but that doesn't excuse me from confusing the two. I should know better. :) 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 + fake helo ??? -- Benny Pedersen Need more webspace ? http://www.servage.net/?coupon=cust37098
Re: how to stop SPF checks from going past trusted host?
Benny Pedersen wrote: On Thu, June 26, 2008 02:54, Matt Kettler wrote: It's a fine distinction, but one that does matter to some folks who are set up this way. In most cases the two are equal, but that doesn't excuse me from confusing the two. I should know better. :) then stop cc me I'll attempt to do so. Didn't realize you disliked it. 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 + fake helo ??? I'm SA interpreted the Received header as meaning that athena.apache.org found no reverse-lookup the host, and that 206.46.173.3 is a host with no reverse DNS claiming to be vms173003pub.verizon.net. At least, that's how I'd read that header.. the FM_FAKE_HELO_VERIZON is likely an early rule trying to detect hosts using verizon helo's that aren't really verizon hosts.
Re: how to stop SPF checks from going past trusted host?
On Thu, June 26, 2008 04:40, Matt Kettler wrote: I'll attempt to do so. Didn't realize you disliked it. its like asking 2 times for the same answer and wonder why no answer I'm SA interpreted the Received header as meaning that athena.apache.org found no reverse-lookup the host, and that 206.46.173.3 is a host with no reverse DNS claiming to be vms173003pub.verizon.net. At least, that's how I'd read that header.. the FM_FAKE_HELO_VERIZON is likely an early rule trying to detect hosts using verizon helo's that aren't really verizon hosts. well i asked if you know reverse dns patterns olso for verizon net or if verizon olso know there trouble ?, few years i have seen spam from verizon but not more then from others, it could nice to know atleast for me if thay use smtp auth and or what there outgoing host is for this if any, maybe you use smtp auth now on this msg here ? if so that fake helo should not be fake :=) -- Benny Pedersen Need more webspace ? http://www.servage.net/?coupon=cust37098
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. On 20.06.08 11:57, Jo Rhett wrote: 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? 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. -- Matus UHLAR - fantomas, [EMAIL PROTECTED] ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Support bacteria - they're the only culture some people have.
Re: how to stop SPF checks from going past trusted host?
Jo Rhett 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? ;-) 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. Since yor mail system can't acknowledge the TCP connection attempt, the external system using the unroutable address will not be able to correctly initiate a SMTP session. So, AFA your mail system is concerned, mail transfers from an unroutable address should not occur even if packets from unroutable addresses do reach the host it runs on. Regards /Jonas -- Jonas Eckerman, FSDB Fruktträdet http://whatever.frukt.org/ http://www.fsdb.org/ http://www.frukt.org/
Re: how to stop SPF checks from going past trusted host?
Jo Rhett wrote: 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? 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.) SMTP travels over TCP. TCP requires a three way handshake. In order to successfully open a connection to a TCP port, you need to know what initial sequence number (ISN) the other side chose. Normally, a client gets that in the SYN-ACK packet generated by the server. However, In the case of a bogon, the client will never get that packet back, so they're going to have to guess the ISN. This is called a blind spoofing attack. Provided your OS is sufficiently good about choosing random ISN's, ie: most modern OSes, even Windows of XP and newer heritage, pulling off a blind spoofing attack is actually rather difficult to do in the real world. If blind spoofing attacks were actually practical, you'd also be seeing a *lot* of connections with forged source IPs on your mailserver. It's equally difficult. When's the last time you got a message and didn't trust the IP your MTA reported as being the actual host delivering the mail? Spammers would aggressively use this technology to hide the IPs of their infected hosts if they could. So go ahead and belt-and-suspenders, but do realize that if they can establish a connection from a 10.* that you don't route back to, they can establish a connection using *ANY* IP address of their choosing. Inside, outside, microsoft, google, any IP address is fair game. Were I a spammer, my first target would be to forge mail as coming from the mailservers of large companies with bondedsender and high-ranking DNSWL listings. I've not seen such mass IP forgery going on. Have you? Of course not, because it pretty much can't be done.
Re: how to stop SPF checks from going past trusted host?
John Hardin wrote: On Thu, 2008-06-19 at 20:54 -0700, John Hardin wrote: header XX Received =~ /from \S+\.svcolo\.com (\S+ \[10\.\d\.\d\.\d\]) by arran\.svcolo\.com (/ score XX -5 Oops. Need some plusses in there... /from \S+\.svcolo\.com (\S+ \[10\.\d+\.\d+\.\d+\]) by arran\.svcolo\.com (/ What happens if such header was forged?
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. Matt, you should know better. ;) It's first _external_ host.
Re: how to stop SPF checks from going past trusted host?
Matt Kettler wrote: 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) Is there some detail that's missing here? ie: do you have a compelling reason to not trust your internal hosts using 10/8? Side note: There is no risk of trusting everyone's email when you add 10/8 to your trusted_networks. This is because trust in spamassassin is a chain that must be unbroken to work. Once an message has been handled by an untrusted host, you can't trust any earlier Recieved: headers. Take an example where email comes from the outside (headers simplified, it's an example...): Received from trusted_host.jrhett.com [64.13.143.10] by sa_box.jrett.com; 12:02:00 + Received from example.somoutsidedomain.com[1.1.1.1] by trusted_host.jrhett.com; 12:01:00 + Received from insideclient.someoutsidedomain [10.1.1.1] by example.somoutsidedomain.com; 12:00:00 + Here, spamassassin will trust trusted_host.jrhett.com [64.13.143.10], because it's been configured to do so. However, it does not trust example.somoutsidedomain.com[1.1.1.1]. Because example.somoutsidedomain.com[1.1.1.1] is untrusted, insideclient.someoutsidedomain [10.1.1.1] is also untrusted, even though 10/8 is in trusted_networks.
Re: how to stop SPF checks from going past trusted host?
On Fri, 20 Jun 2008, mouss wrote: John Hardin wrote: On Thu, 2008-06-19 at 20:54 -0700, John Hardin wrote: header XX Received =~ /from \S+\.svcolo\.com (\S+ \[10\.\d\.\d\.\d\]) by arran\.svcolo\.com (/ score XX -5 Oops. Need some plusses in there... /from \S+\.svcolo\.com (\S+ \[10\.\d+\.\d+\.\d+\]) by arran\.svcolo\.com (/ What happens if such header was forged? Then the message gets -5 points added to it's score. How likely is a header forged with that particular data going to be sent in a message to that particular SA host? If that's a concern then add a rule to verify that the SA host received the message from the relay, use a meta to AND them, and score the meta rule at -5. -- John Hardin KA7OHZhttp://www.impsec.org/~jhardin/ [EMAIL PROTECTED]FALaholic #11174 pgpk -a [EMAIL PROTECTED] key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79 --- Efficiency can magnify good, but it magnifies evil just as well. So, we should not be surprised to find that modern electronic communication magnifies stupidity as *efficiently* as it magnifies intelligence. -- Robert A. Matern --- 14 days until the 232nd anniversary of the Declaration of Independence
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. 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 ? 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]) Benny Pedersen Need more webspace ? http://www.servage.net/?coupon=cust37098
Re: how to stop SPF checks from going past trusted host?
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. http://wiki.apache.org/spamassassin/TrustPath PS. https://issues.apache.org/SpamAssassin/show_bug.cgi?id=5856
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
Re: how to stop SPF checks from going past trusted host?
On Fredag, 20/6 2008, 10:04, Henrik K 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. Matt, you should know better. ;) It's first _external_ host. and is most of the time olso first untrusted ? :) both is imho correct Benny Pedersen Need more webspace ? http://www.servage.net/?coupon=cust37098
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 Fri, 20 Jun 2008, Jo Rhett wrote: 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. D'oh! See my other note about trusted_hosts breaking all forms of whitelisting, FYI. This kind of hackery (although appreciate the help) is kindof nonsense :-( Yeah. Trust and Internal properly set up and working is, of course, the optimal solution. Just wanted to point out it's not the _only_ solution. Also: 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 ;-) 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. -- John Hardin KA7OHZhttp://www.impsec.org/~jhardin/ [EMAIL PROTECTED]FALaholic #11174 pgpk -a [EMAIL PROTECTED] key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79 --- Perfect Security is unattainable; beware those who would try to sell it to you, regardless of the cost, for they are trying to sell you your own slavery. --- 14 days until the 232nd anniversary of the Declaration of Independence
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 Fredag, 20/6 2008, 19:59, Jo Rhett 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 ;-) added .17 to the domain you are sending from, but its not you so not your problem :) Benny Pedersen Need more webspace ? http://www.servage.net/?coupon=cust37098
Re: how to stop SPF checks from going past trusted host?
On Fri, Jun 20, 2008 at 11:01:40AM -0700, Jo Rhett wrote:
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.
I corrected Matt because when newbies read such claims, they don't learn to
separate the meanings. Also your comment makes no sense given what I said
already.
As the code says:
# dos: first external relay, not first untrusted
return $scanner-{relays_external}-[0];
SPF will be checked for first external (non internal_networks) host. Period.
This doesn't have anything to do with your case specifically, I'm just
explaining how things work.
Re: how to stop SPF checks from going past trusted host?
On Fredag, 20/6 2008, 20:49, 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. pppoe, but firewall it to be sure, rule is newer accept connections from non routable ips from outside, that olso explains confusing for spamassassin lets have ipv6 :) Benny Pedersen Need more webspace ? http://www.servage.net/?coupon=cust37098
Re: how to stop SPF checks from going past trusted host?
On Fri, Jun 20, 2008 at 11:57:38AM -0700, Jo Rhett wrote: 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, 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
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 Fri, Jun 20, 2008 at 12:31:06PM -0700, Jo Rhett wrote: 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. Don't take it personally. I just have the impression that threads started by you tend to get very long.. it might just be because we don't come through clear enough for you. Do notice the smiley. 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? What comes to your first post info, it would seem to me that you need: internal_networks hostA hostB hostC 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.
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: how to stop SPF checks from going past trusted host?
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. 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. 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? 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. 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.
Re: how to stop SPF checks from going past trusted host?
On Fri, 20 Jun 2008, Jo Rhett wrote: 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? ;-) I did say supposedly. :) -- John Hardin KA7OHZhttp://www.impsec.org/~jhardin/ [EMAIL PROTECTED]FALaholic #11174 pgpk -a [EMAIL PROTECTED] key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79 --- The fetters imposed on liberty at home have ever been forged out of the weapons provided for defense against real, pretended, or imaginary dangers from abroad. -- James Madison, 1799 --- 14 days until the 232nd anniversary of the Declaration of Independence
Re: how to stop SPF checks from going past trusted host?
Jo Rhett wrote: 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? 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.
Re: how to stop SPF checks from going past trusted host?
On Thu, 2008-06-19 at 20:37 -0700, Jo Rhett wrote: Example: host A: 10.0.0.1 generates e-mail, routes via HostB Host B: has outside IP 64.13.143.16 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? Do you *need* to get the SPF test to pass, or do you just want to lower the score? If the latter, how about: header XX Received =~ /from \S+\.svcolo\.com (\S+ \[10\.\d\.\d\.\d\]) by arran\.svcolo\.com (/ score XX -5 -- John Hardin KA7OHZhttp://www.impsec.org/~jhardin/ [EMAIL PROTECTED]FALaholic #11174 pgpk -a [EMAIL PROTECTED] key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79 --- Perfect Security is unattainable; beware those who would try to sell it to you, regardless of the cost, for they are trying to sell you your own slavery. --- 15 days until the 232nd anniversary of the Declaration of Independence
Re: how to stop SPF checks from going past trusted host?
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. 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. 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? 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) 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. 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) Is there some detail that's missing here? ie: do you have a compelling reason to not trust your internal hosts using 10/8? So... how can I say I trust Host B so much that I don't want to go any farther for SPF checks? Modify the SPF code. There's no such option at present.
Re: how to stop SPF checks from going past trusted host?
On Thu, 2008-06-19 at 20:54 -0700, John Hardin wrote: header XX Received =~ /from \S+\.svcolo\.com (\S+ \[10\.\d\.\d\.\d\]) by arran\.svcolo\.com (/ score XX -5 Oops. Need some plusses in there... /from \S+\.svcolo\.com (\S+ \[10\.\d+\.\d+\.\d+\]) by arran\.svcolo\.com (/ -- John Hardin KA7OHZhttp://www.impsec.org/~jhardin/ [EMAIL PROTECTED]FALaholic #11174 pgpk -a [EMAIL PROTECTED] key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79 --- Perfect Security is unattainable; beware those who would try to sell it to you, regardless of the cost, for they are trying to sell you your own slavery. --- 15 days until the 232nd anniversary of the Declaration of Independence
