Re: Breaking up the Bot army - we need a plan
In article [EMAIL PROTECTED], John Rudd [EMAIL PROTECTED] writes I'm _highly_ skeptical that emailebay.com has anything to do with ebay.com. Registrant: eBay Inc. 2145 Hamilton Avenue San Jose, CA 95125 US Domain name: EMAILEBAY.COM Registrar of Record: TUCOWS, INC. Record last updated on 11-Sep-2006. Record expires on 04-May-2007. Record created on 04-May-2001. Domain servers in listed order: SJC-DNS2.EBAYDNS.COM 66.135.207.138 SMF-DNS1.EBAYDNS.COM 66.135.223.137 SJC-DNS1.EBAYDNS.COM 66.135.207.137 Now I've no idea what the chances of mail from eBay coming through there, but at first glance it looks plausible that it's an eBay owned/run domain. Kevin
RE: Breaking up the Bot army - we need a plan
You didn't read what I actually said. I didn't say the domain didn't look right. I said the IP address registration didn't look right. nslookup ebay.com Name: ebay.com Address: 66.135.192.87 whois 66.135.192.87 OrgName:eBay, Inc OrgID: EBAY Address:2145 Hamilton Ave City: San Jose StateProv: CA PostalCode: 95008 Country:US NetRange: 66.135.192.0 - 66.135.223.255 CIDR: 66.135.192.0/19 NetName:EBAY-1 NetHandle: NET-66-135-192-0-1 Parent: NET-66-0-0-0-0 NetType:Direct Assignment NameServer: SJC-DNS1.EBAYDNS.COM NameServer: SJC-DNS2.EBAYDNS.COM NameServer: SMF-DNS1.EBAYDNS.COM Comment: RegDate:2001-07-13 Updated:2003-02-20 OrgTechHandle: EBAYN-ARIN OrgTechName: eBay Network OrgTechPhone: +1-408-376-7400 OrgTechEmail: [EMAIL PROTECTED] # ARIN WHOIS database, last updated 2006-12-13 19:10 # Enter ? for additional hints on searching ARIN's WHOIS database. That part looks fine. Now, for emailebay.com: nslookup emailebay.com Name: emailebay.com Address: 216.33.156.118 whois 216.33.156.118 OrgName:Savvis OrgID: SAVVI-2 Address:3300 Regency Parkway City: Cary StateProv: NC PostalCode: 27511 Country:US ReferralServer: rwhois://rwhois.savvis.net:4321/ NetRange: 216.32.0.0 - 216.35.255.255 CIDR: 216.32.0.0/14 NetName:SAVVIS NetHandle: NET-216-32-0-0-1 Parent: NET-216-0-0-0-0 NetType:Direct Allocation NameServer: DNS01.SAVVIS.NET NameServer: DNS02.SAVVIS.NET NameServer: DNS03.SAVVIS.NET NameServer: DNS04.SAVVIS.NET Comment: RegDate:1998-07-30 Updated:2004-10-07 OrgAbuseHandle: ABUSE11-ARIN OrgAbuseName: Abuse OrgAbusePhone: +1-877-393-7878 OrgAbuseEmail: [EMAIL PROTECTED] OrgNOCHandle: NOC99-ARIN OrgNOCName: SAVVIS Support Center OrgNOCPhone: + 1-888-638-6771 OrgNOCEmail: [EMAIL PROTECTED] OrgTechHandle: UIAA-ARIN OrgTechName: US IP Address Administration OrgTechPhone: + 1-888-638-6771 OrgTechEmail: [EMAIL PROTECTED] # ARIN WHOIS database, last updated 2006-12-13 19:10 # Enter ? for additional hints on searching ARIN's WHOIS database. Looks quite a bit different to me. Not really Do a dig -x 216.33.156.118 then do a dig -x 216.33.157.1 notice my simple change and see that it appears that it just hasn't been swip'd yet - rh -- Robert - Abba Communications Computer Internet Services (509) 624-7159 - www.abbacomm.net
Re: Breaking up the Bot army - we need a plan
R Lists06 wrote: Looks quite a bit different to me. Not really Do a dig -x 216.33.156.118 then do a dig -x 216.33.157.1 notice my simple change and see that it appears that it just hasn't been swip'd yet I'm not sure what your point is. Yes, the latter tells you that the PTR record points to an ebay.com hostname. Which is somewhat better, but doesn't really mean anything about ownership, especially since that ebay.com hostname doesn't resolve. But the whois for 216.33.156.118, 216.33.156.1, 216.33.157.1 is all savvis.net. The ownership is still completely different than the ownership of the address blocks for ebay.com. That doesn't necessarily mean it's bad... it just isn't ... the same. Which leaves me rather skeptical.
Re: Breaking up the Bot army - we need a plan
Someone, quite probably John Rudd, once wrote: Kevin Golding wrote: In article [EMAIL PROTECTED], John Rudd [EMAIL PROTECTED] writes I'm _highly_ skeptical that emailebay.com has anything to do with ebay.com. Registrant: eBay Inc. 2145 Hamilton Avenue San Jose, CA 95125 US Domain name: EMAILEBAY.COM Registrar of Record: TUCOWS, INC. Record last updated on 11-Sep-2006. Record expires on 04-May-2007. Record created on 04-May-2001. Domain servers in listed order: SJC-DNS2.EBAYDNS.COM 66.135.207.138 SMF-DNS1.EBAYDNS.COM 66.135.223.137 SJC-DNS1.EBAYDNS.COM 66.135.207.137 Now I've no idea what the chances of mail from eBay coming through there, but at first glance it looks plausible that it's an eBay owned/run domain. You didn't read what I actually said. Well I'll admit I'm only skimming the rehashed arguments of SPF going on elsewhere but I think I'm missing your objection to the domain or something. I didn't say the domain didn't look right. I said the IP address registration didn't look right. Check. nslookup ebay.com Name: ebay.com Address: 66.135.192.87 whois 66.135.192.87 OrgName:eBay, Inc OrgID: EBAY Address:2145 Hamilton Ave Check. And I note: NameServer: SJC-DNS1.EBAYDNS.COM NameServer: SJC-DNS2.EBAYDNS.COM NameServer: SMF-DNS1.EBAYDNS.COM nslookup emailebay.com Name: emailebay.com Address: 216.33.156.118 whois 216.33.156.118 OrgName:Savvis OrgID: SAVVI-2 Check. Looks quite a bit different to me. Agreed, but if we go back to the whois for emailebay.com: SJC-DNS2.EBAYDNS.COM 66.135.207.138 SMF-DNS1.EBAYDNS.COM 66.135.223.137 SJC-DNS1.EBAYDNS.COM 66.135.207.137 Now I kind of figure that if eBay's nameservers are pointing the domain to that IP it doesn't really matter who the registered owner of the IP is. Now given Savvis turned up within the past week or so as a screwed up mail server for EasyJet I'm happy to believe that they're completely legitimate delegated server for sending mail for eBay. In other words, yes - the IP is registered to Savvis not eBay and that doesn't seem ideal/completely standard for eBay, but given the companies involved and the rest of the DNS entries I don't really understand why you say you're _highly_ skeptical that emailebay.com has anything to do with ebay.com. I can understand being highly sceptical that they send mail of any value for eBay, but they appear to have some kind of legit relationship from my quick checks. Kevin
RE: Filtering THIS list (Re: Breaking up the Bot army - we need a plan)
Maybe they're better suited to one of the other lists such as spam-l? Mr Michele Neylon Blacknight Solutions Hosting Colocation, Brand Protection http://www.blacknight.ie/ http://blog.blacknight.ie/ Tel. 1850 927 280 Intl. +353 (0) 59 9183072 UK: 0870 163 0607 Direct Dial: +353 (0)59 9183090 Fax. +353 (0) 59 9164239
Re: Filtering THIS list (Re: Breaking up the Bot army - we need a plan)
Michele Neylon :: Blacknight wrote: Maybe they're better suited to one of the other lists such as spam-l? May I suggest news.admin.net-abuse.email -- Andreas
Re: Breaking up the Bot army - we need a plan
Phil Barnett wrote: On Tuesday 12 December 2006 07:28, JamesDR wrote: There is nothing in SPF to keep a spammer with a botnet from putting 0.0.0.0/0 as their approved domain limit. Sounds like a good spam sign to me. Let the spammers put 0.0.0.0/0 in their spf records, I'll pop in 3 points for good measure. But, you are making some assumptions at this point and that is the crux of why SPF can't work very well. Say you give points for that one. So, where do you draw the line. Do you give points for (for example) 123.0.0.0/8? What if that is someone's legitimate domain space? Bot masters can easily set up SPF addresses that will encompass giant subnets of bots. You'll never know where to draw the line. Even better. If they give me a giant subnet of SPF records, I know exactly what IP's I don't want connecting to my mail server. If a spammer sends a spam from a subnet, passes SPF. I will and have gone, looked at their record and blocked what they say is 'allowed' to send me spam. In a way, they've done me a huge favor by block their entire bot net at the router. Quite effective at stopping spam indeed. This does have a huge issue with collateral damage, however what I would also do is contact the ISP and point them to the SPF record see, your network is owned by a spammer. Also makes it very handy for RBL lists to know where future spam will come from. I welcome spammers creating SPF records. Makes my job quite easy in stopping the bot army. -- Thanks, James
Re: Breaking up the Bot army - we need a plan
JamesDR wrote: Even better. If they give me a giant subnet of SPF records, I know exactly what IP's I don't want connecting to my mail server. If a spammer sends a spam from a subnet, passes SPF. I will and have gone, looked at their record and blocked what they say is 'allowed' to send me spam. So if a spammer sets 0.0.0.0/0 as the subnet allowed to send mail from their domain, you'd be happy to block that subnet from sending you mail? James
Re: Breaking up the Bot army - we need a plan
James Davis wrote: JamesDR wrote: Even better. If they give me a giant subnet of SPF records, I know exactly what IP's I don't want connecting to my mail server. If a spammer sends a spam from a subnet, passes SPF. I will and have gone, looked at their record and blocked what they say is 'allowed' to send me spam. So if a spammer sets 0.0.0.0/0 as the subnet allowed to send mail from their domain, you'd be happy to block that subnet from sending you mail? James You miss understood some parts... I'll happily block a large subnet if it is a valid subnet and not some odd number like 0.0.0.0/0 for which I'd add 3 points. The point I was tying to make (which you sniped out) is that when spammers say where they are sending spam from it actually helps to block them. I'm not saying everyone should do this because maybe you need to accept the mail from forged addresses, I don't know. I'm making the point that -- if a spammer says hey, these bots are allowed to send spam for my domain then you know right away who to block. Even if it is a temporary block. That being said -- I've already done this with a personal RBL. I've found this to be quite effective to block a large amount of spam from a spammer outside the US that operates their own domains (has a huge block of IP's.) That made the mistake of publishing their SPF records for their entire net block. Before doing this, the mails would just change servers, and when the domain was blocked, change domains. Blocking their entire subnet blocked all spam from them. The only way this could have been done is with SPF (the other domains also show different invalid whois info as well.) Like I said previously, I welcome spammers publishing SPF records. -- Thanks, James
Re: Breaking up the Bot army - we need a plan
On Wed, Dec 13, 2006 at 10:43:40AM -0500, JamesDR wrote: accept the mail from forged addresses, I don't know. I'm making the point that -- if a spammer says hey, these bots are allowed to send spam for my domain then you know right away who to block. Even if it is The issue is that SPF only specifies who's allowed to send mail from a given host/domain. You can't reverse engineer that information into a useful anti-spam rule. If you counter and say but this is working great for me right now, my answer is yes, for right now... Like a lot of anti-spam technology, things only work for as long as the spammers don't care about it. For instance, I (john q spammer) could start including random /24's in my record along with 4 bots that are going to send out my mails. Now you get spam from my domain ... and you end up blocking places you really don't want to. Much like not using a screwdriver to pound in a nail, don't use SPF for things it wasn't designed to do. -- Randomly Selected Tagline: I love every living creature. -Leela Even me? -Fry As a friend. -Leela pgpdRT1mvmg4Y.pgp Description: PGP signature
Re: Breaking up the Bot army - we need a plan
JamesDR wrote: Phil Barnett wrote: On Tuesday 12 December 2006 07:28, JamesDR wrote: There is nothing in SPF to keep a spammer with a botnet from putting 0.0.0.0/0 as their approved domain limit. Sounds like a good spam sign to me. Let the spammers put 0.0.0.0/0 in their spf records, I'll pop in 3 points for good measure. But, you are making some assumptions at this point and that is the crux of why SPF can't work very well. Say you give points for that one. So, where do you draw the line. Do you give points for (for example) 123.0.0.0/8? What if that is someone's legitimate domain space? Bot masters can easily set up SPF addresses that will encompass giant subnets of bots. You'll never know where to draw the line. Even better. If they give me a giant subnet of SPF records, I know exactly what IP's I don't want connecting to my mail server. If a spammer sends a spam from a subnet, passes SPF. I will and have gone, looked at their record and blocked what they say is 'allowed' to send me spam. In a way, they've done me a huge favor by block their entire bot net at the router. Quite effective at stopping spam indeed. This does have a huge issue with collateral damage, however what I would also do is contact the ISP and point them to the SPF record see, your network is owned by a spammer. Also makes it very handy for RBL lists to know where future spam will come from. I welcome spammers creating SPF records. Makes my job quite easy in stopping the bot army. What would stop a spammer from entering any IP they chose? That I know of there is no one auditing SPF records. So if I spammed a domain using a hole in your server, simply adding ip4:65.113.179.82 would allow the messages to pass SPF correct? I don't see how pointing to that SPF record would enable me to call you and say see, your network is owned by a spammer. If anything I would think you could engineer a way to make a mailserver DOS itself using SPF. My father always used to say about small locks, they keep honest people honest, but they never stopped a thief. SPF seems a lot like that to me. DAve -- Three years now I've asked Google why they don't have a logo change for Memorial Day. Why do they choose to do logos for other non-international holidays, but nothing for Veterans? Maybe they forgot who made that choice possible.
Re: Breaking up the Bot army - we need a plan
On Wed, 13 Dec 2006, JamesDR wrote: Bot masters can easily set up SPF addresses that will encompass giant subnets of bots. You'll never know where to draw the line. Even better. If they give me a giant subnet of SPF records, I know exactly what IP's I don't want connecting to my mail server. If a spammer sends a spam from a subnet, passes SPF. I will and have gone, looked at their record and blocked what they say is 'allowed' to send me spam. What if they include the subnet containing AOL's outbound MX hosts? Waitaminit, bad example... What if they include the subnet containing Apache's outbound MX hosts? As I said before, score on the total number of the hosts matched by the SPF record. Anything bigger than a class-C is suspicious. Anything bigger than a class-B is *very* suspicious. And if a big ISP SPFs their entire class-B, they are damned lazy. -- 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 question of whether people should be allowed to harm themselves is simple. They *must*. -- Charles Murray --- 2 days until Bill of Rights day
Re: Breaking up the Bot army - we need a plan
John D. Hardin wrote: What if they include the subnet containing AOL's outbound MX hosts? Waitaminit, bad example... :-D What if they include the subnet containing Apache's outbound MX hosts? As I said before, score on the total number of the hosts matched by the SPF record. Anything bigger than a class-C is suspicious. Anything bigger than a class-B is *very* suspicious. And if a big ISP SPFs their entire class-B, they are damned lazy. Like everything else, you can't go at it blindly. A lot of the suggestions here I'm sure weren't thought of on a whim. I can think of an example where an ISP blocked outbound port 25 for all its users. Good first step, but they didn't require auth and a spammer exploited this. As the subject said -- a plan is needed. And I 100% agree with this statement. What can be done now works for now. It won't always work for the future (gray listing is one example that is very effective -- but for how long) The bot army will always be. It is so effective at delivering spam that is would be stupid to abandon it (from a spammers view.) -- Thanks, James
Re: Breaking up the Bot army - we need a plan
Well, I have a simple plan. Spammers are inherently greedy, right? Why not offer a $25k-$25mil a head bounty on any spammer captured and brought to justice? Even if we can't convict them on crimes of spamming, we can certainly get them on fraud and other things. There's plenty of laws on the books that we could throw at them. The nice part about it would be that we wouldn't need to lift a finger. At least not initially. We just advertise it worldwide, create some high profile example cases, show people getting paid and let greed take over. Spammers would then go after each other like a pack of piranhas quickly thinning the herd to just a handful at most. The benefits they would see from this would be: 1. Reduced competition. 2. Easy money in their pockets. That system would probably work so well that it'd likely run out of money several times along the way. But man, imagine all the spammers that'd be taken out of circulation. :D Out of the hundreds of spammers, scammers and phishers out there now that spam, there'd likely only be 2-5 left worldwide once this went into effect. ;) Steven Lake Owner/Technical Writer Raiden's Realm www.raiden.net A friendly web community
Re: Breaking up the Bot army - we need a plan
Duncan Hill wrote: On Monday 11 December 2006 16:16, John Rudd wrote: Duncan Hill wrote: I just finished a very quick test of the Botnet tool, and the sheer number of FPs against eBy mail coming from eBay's servers was staggering - literally every single mail from eBay. It also, for my testing, hit on a lot of legitimate ham - mostly with BADDNS. I'll run another test later, but I've got to move on to other things now. The botnet_pass_domain entry for ebay, in the default Botnet.cf file, didn't exempt ebay messages from the Botnet rules? No, they send mail from servers that reverse to emailebay.com. You sure about that? email I get from ebay has hostnames like: mxpool22.ebay.com which is covered by the botnet_pass_domain entry for ebay. (before I added word boundary checking, the serverword for mx would have covered it too) I haven't seen anything from emailebay.com Further, the IP address that is resolved by emailebay.com doesn't appear to be allocated to ebay. It's allocated to savvis.net. The registration information is _completely_ different from what ebay.com's IP address registration says. I'm _highly_ skeptical that emailebay.com has anything to do with ebay.com.
Filtering THIS list (Re: Breaking up the Bot army - we need a plan)
Steve Thomas wrote: Once again, Perkel clutters the SpamAssassin list with a non-SpamAssassin discussion. One which, IIRC, he's just rehashing from a year or so ago (are we going to see a rehash of the the future of email storage is sql thread, too?). There are FAR more appropriate forums for these non-SA related things. Is anyone else getting tired of this? Forty eight messages on the SA list today that have nothing to do with SA. What's the point of having a topical mailing list if nobody cares that the discussion is off-topic? St- Make that 2 of us. I for one would like to filter out all mails/threads originated by perkel (yeah which would include this mail as well).. i too am tired of him trying to discuss things that don't belong to SA. - dhawal
Filtering THIS list (Re: Breaking up the Bot army - we need a plan)
Steve Thomas wrote: Once again, Perkel clutters the SpamAssassin list with a non-SpamAssassin discussion. ...Is anyone else getting tired of this? ...have nothing to do with SA. What's the point of having a topical mailing list if nobody cares that the discussion is off-topic? Dhawal wrote: Make that 2 of us. I for one would like to filter out all mails/threads originated by perkel (yeah which would include this mail as well).. I couldn't disagree with these two people more. It is just these types of discussions which led to things like SURBL and fuzzyOCR... and yet we get so many OTHER repetitive discussions about thinks like **basic** SA setup, rules update procedures, etc... therefore, this stuff complained about is a fairly small percentage of the whole (maybe not for today, but overall it is). Marc Perkel is a bit eccentric and he and I are about as polar opposite in our political and world-views as two people can get... but I think he has some great ideas about spam filtering and I like the way that he thinks outside the box. Rob McEwen PowerView Systems [EMAIL PROTECTED]
Re: Filtering THIS list (Re: Breaking up the Bot army - we need a plan)
On Tuesday, December 12, 2006, 12:29:26 AM, Rob McEwen wrote: It is just these types of discussions which led to things like SURBL and fuzzyOCR. In the interests of preserving some history, SURBLs were not created as a result of discussions here. We created SURBLs concurrently with Eric Kolve writing his SA plugin SpamCopURI to use them. Then we persuaded the SpamAssassin developers to look into supporting SURBLs directly, which they apparently did by modifying the uridnsbl command into urirhsbl. Some of the messages are at: http://mail-archives.apache.org/mod_mbox/spamassassin-users/200410.mbox/[EMAIL PROTECTED] Jeff C. -- Jeff Chan mailto:[EMAIL PROTECTED] http://www.surbl.org/
Re: Breaking up the Bot army - we need a plan
Phil Barnett wrote: On Monday 11 December 2006 16:50, JamesDR wrote: Would you care to elaborate on why SPF doesn't work for sender verification? Its pretty simple, doesn't get much more simple that what SPF does... If SPF doesn't work, nothing will. There is nothing in SPF to keep a spammer with a botnet from putting 0.0.0.0/0 as their approved domain limit. Sounds like a good spam sign to me. Let the spammers put 0.0.0.0/0 in their spf records, I'll pop in 3 points for good measure. Again, I said SPF doesn't stop bots. You will _never_ stop the bots. Why? Well over 99% of my spam comes from the far east. Are you going to convince all of those ISP's to change their ways, when they are making money off of their customers spamming you? I doubt you'll see much action happening quickly there. Graylisting now is a good solution. SPF helps with joe-jobs. RBL's block most of the crud upfront. All of the tools to 'break up the bot army' are there. No one bothers to use them all to stop the spam they get. So they throw up their hands and complain and yell for protocol changes, or to use some other method. My favorite, point the blame at someone else. I get 0 spam to the Inbox with nearly 1fp for every 1,000 mails passed through. We're small enough here to afford that 1fp as I check the marked spams. I block all mail that fails SPF upfront. This also stops quite a bit. If you get spam from one of my domains not from my mail server, its your own fault. Enjoy the spam, wasted bandwidth, and storing that mail for legal purposes. -- Thanks, James
RE: Filtering THIS list (Re: Breaking up the Bot army - we need a plan)
Jeff, I think you somewhat misinterpreted what I said. But I understand how I one might mistakenly get the impression that I was saying that discussions on the SA list led to SURBL so I understand your need to clear that potential misunderstanding up... but, to be clear, I stated: things **like** SURBL (emphasis added... and that word like dramatically changes the meaning of that sentence) But, in all fairness, in a search of the SA list archives, I spotted literally hundreds of SA list posts with SURBL in the subject line. I seem to recall much wisdom, some really good questions, and a few heads ups in some of those threads... stuff which I believe helped SURBL... and I think SURBL would have suffered had someone, early on, said, keep this off the SA list since it is off-topic... which further backs up my original point. Rob McEwen -Original Message- From: Jeff Chan [mailto:[EMAIL PROTECTED] Sent: Tuesday, December 12, 2006 6:49 AM To: Rob McEwen Cc: users@spamassassin.apache.org Subject: Re: Filtering THIS list (Re: Breaking up the Bot army - we need a plan) On Tuesday, December 12, 2006, 12:29:26 AM, Rob McEwen wrote: It is just these types of discussions which led to things like SURBL and fuzzyOCR. In the interests of preserving some history, SURBLs were not created as a result of discussions here. We created SURBLs concurrently with Eric Kolve writing his SA plugin SpamCopURI to use them. Then we persuaded the SpamAssassin developers to look into supporting SURBLs directly, which they apparently did by modifying the uridnsbl command into urirhsbl. Some of the messages are at: http://mail-archives.apache.org/mod_mbox/spamassassin-users/200410.mbox/%3C1 [EMAIL PROTECTED] Jeff C. -- Jeff Chan mailto:[EMAIL PROTECTED] http://www.surbl.org/
Re: Filtering THIS list (Re: Breaking up the Bot army - we need a plan)
Jeff Chan wrote: On Tuesday, December 12, 2006, 12:29:26 AM, Rob McEwen wrote: It is just these types of discussions which led to things like SURBL and fuzzyOCR. In the interests of preserving some history, SURBLs were not created as a result of discussions here. We created SURBLs concurrently with Eric Kolve writing his SA plugin SpamCopURI to use them. Then we persuaded the SpamAssassin developers to look into supporting SURBLs directly, which they apparently did by modifying the uridnsbl command into urirhsbl. Some of the messages are at: http://mail-archives.apache.org/mod_mbox/spamassassin-users/200410.mbox/[EMAIL PROTECTED] Jeff C. Also from my limited memory, a fuzzyocr like implementation existed on antispan.imp.ch long before it was discussed on the sa-users list. Someone can correct me if this is incorrect information. - dhawal
RE: Filtering THIS list (Re: Breaking up the Bot army - we need a plan)
Dhawal said: Also from my limited memory, a fuzzyocr like implementation existed on antispan.imp.ch long before it was discussed on the sa-users list. Someone can correct me if this is incorrect information. And, like SURBL, regardless of the official origin of the idea, I know for a fact that fuzzyocr benefited tremendously from discussions on the SA list and I'd bet money that the author would happily agree. I also recall the author of fuzzyocr at one point saying something like, hey guys, sorry I'm hogging your list... here is my new list especially devoted to fuzzyocr... (that wasn't an exact quote... but he said something to that effect)... and that was totally appropriate and polite for him to do that. Up to that point, I don't think anyone minded the frequent discussions of fuzzyocr... but it did make sense, like SURBL, for fuzzyocr to have out to its own list for detailed discussions. But I have recent memories of tremendously good feedback on the SA list regarding fuzzyocr which also benefited fuzzyocr... particularly before the official fuzzyocr list began. Like SURBL, fuzzyocr would have suffered had discussion about it on the SA list been clamped down with off-topic complaints. Rob McEwen
Re: Filtering THIS list (Re: Breaking up the Bot army - we need a plan)
Rob McEwen wrote: Dhawal said: Also from my limited memory, a fuzzyocr like implementation existed on antispan.imp.ch long before it was discussed on the sa-users list. Someone can correct me if this is incorrect information. And, like SURBL, regardless of the official origin of the idea, I know for a fact that fuzzyocr benefited tremendously from discussions on the SA list and I'd bet money that the author would happily agree. I also recall the author of fuzzyocr at one point saying something like, hey guys, sorry I'm hogging your list... here is my new list especially devoted to fuzzyocr... (that wasn't an exact quote... but he said something to that effect)... and that was totally appropriate and polite for him to do that. Up to that point, I don't think anyone minded the frequent discussions of fuzzyocr... but it did make sense, like SURBL, for fuzzyocr to have out to its own list for detailed discussions. But I have recent memories of tremendously good feedback on the SA list regarding fuzzyocr which also benefited fuzzyocr... particularly before the official fuzzyocr list began. Like SURBL, fuzzyocr would have suffered had discussion about it on the SA list been clamped down with off-topic complaints. Rob McEwen I am not against off-topic discussions (and also indulge in a few when appropriate), what i am tired of is 'Perkel', have a look at some of the threads started by him.. Breaking up the Bot army - we need a plan Who wants my spam - seriously! About the SpamHaus lawsuit? I'm thinking about suing Microsoft What's with UCEPROTECT List? Allowing IMAP/POP to Send Email What changes would you make to stop spam? - United Nations Paper SPF breaks email forwarding The best way to use Spamassassin is to not use Spamassassin The Future of Email is SQL Tricky DNS Question - Advanced Who wants my spam - seriously! Suing Spammers Fighting spam by public education? End of topic for me. Good day to you all. - dhawal
Re: Filtering THIS list (Re: Breaking up the Bot army - we need a plan)
Rob McEwen wrote: Steve Thomas wrote: Once again, Perkel clutters the SpamAssassin list with a non-SpamAssassin discussion. ...Is anyone else getting tired of this? ...have nothing to do with SA. What's the point of having a topical mailing list if nobody cares that the discussion is off-topic? Dhawal wrote: Make that 2 of us. I for one would like to filter out all mails/threads originated by perkel (yeah which would include this mail as well).. I couldn't disagree with these two people more. It is just these types of discussions which led to things like SURBL and fuzzyOCR... And a similar, slightly OT, discussion (though, it may have been on the mailscanner or mimedefang lists) lead to a mimedefang-filter that then later lead to the Botnet plugin for SA. and yet we get so many OTHER repetitive discussions about thinks like **basic** SA setup, rules update procedures, etc... therefore, this stuff complained about is a fairly small percentage of the whole (maybe not for today, but overall it is). And, the funny thing is, this thread wasn't THAT OT. Sure, the email storage in SQL discussion was rather OT... it had almost nothing to do with spam. But this discussion, about how to defeat spambots, is at least about fighting spam. That may not be literally about the nuts and bolts of being a spamassassin user, but it is generally relevant to the interests of this list. I don't have a problem with: a) things that are slightly OT (relate to the general purpose of the list), as long as they don't take over the list or drift way off topic b) things that are a bit more OT, but that don't clutter the list I think Breaking up the Bot army - we need a plan was done fine with (a).
Re: Breaking up the Bot army - we need a plan
JamesDR wrote: Phil Barnett wrote: On Monday 11 December 2006 16:50, JamesDR wrote: Would you care to elaborate on why SPF doesn't work for sender verification? Its pretty simple, doesn't get much more simple that what SPF does... If SPF doesn't work, nothing will. There is nothing in SPF to keep a spammer with a botnet from putting 0.0.0.0/0 as their approved domain limit. Sounds like a good spam sign to me. Let the spammers put 0.0.0.0/0 in their spf records, I'll pop in 3 points for good measure. Again, I said SPF doesn't stop bots. You will _never_ stop the bots. I've pretty much stopped getting email from bots. Sure, there's a trickle that gets passed Botnet, but it's pretty minor. About 1%. The main problem for Botnet right now is minimizing false positives.
Re: Breaking up the Bot army - we need a plan
On Tuesday 12 December 2006 07:28, JamesDR wrote: There is nothing in SPF to keep a spammer with a botnet from putting 0.0.0.0/0 as their approved domain limit. Sounds like a good spam sign to me. Let the spammers put 0.0.0.0/0 in their spf records, I'll pop in 3 points for good measure. But, you are making some assumptions at this point and that is the crux of why SPF can't work very well. Say you give points for that one. So, where do you draw the line. Do you give points for (for example) 123.0.0.0/8? What if that is someone's legitimate domain space? Bot masters can easily set up SPF addresses that will encompass giant subnets of bots. You'll never know where to draw the line. -- My other computer is your Windows machine
Re: Filtering THIS list (Re: Breaking up the Bot army - we need a plan)
On Tuesday, December 12, 2006, 5:52:33 AM, Dhawal Doshy wrote: I am not against off-topic discussions (and also indulge in a few when appropriate), what i am tired of is 'Perkel', have a look at some of the threads started by him.. Breaking up the Bot army - we need a plan Who wants my spam - seriously! About the SpamHaus lawsuit? I'm thinking about suing Microsoft What's with UCEPROTECT List? Allowing IMAP/POP to Send Email What changes would you make to stop spam? - United Nations Paper SPF breaks email forwarding The best way to use Spamassassin is to not use Spamassassin The Future of Email is SQL Tricky DNS Question - Advanced Who wants my spam - seriously! Suing Spammers Fighting spam by public education? All of which have almost nothing to do with SpamAssassin. They are very off-topic and therefore inappropriate. Jeff C. -- Jeff Chan mailto:[EMAIL PROTECTED] http://www.surbl.org/
Breaking up the Bot army - we need a plan
As spam keeps increasing in volume and complexity we will eventually lose the war on spam if we don't change the standards. I'd like to open a discussion about what needs to be done and how to go about doing that. So I'll start. Any changes to the standard needs to be evolutionary. If we add a new feature to the standard that is so compelling that people give up the old standard and it is phased out. First - I see bot nets as the biggest culprit. Not just as spammers but as sources for DDOS attacks. In the early days of email only the sharpest people had access to it. Now that consumers are using it they need some protection and we need protection from them. How do we isolate end users so that they can't get viruses as easily and spread them as easily? By default all consumers should be behind a NAT to protect them from the outside world. Like many of you. I'm someone who works from home and provides so service from home. So I would not want to be prohibited from running an email server from home. But if I had to got to a web panel that my ISP provided to open up ports that would be fine with me. All outgoing email from consumers should by default be required to use authenticated SMTP or some new authenticated protocol. At least force consumers to use the submission port and block off port 25 for outgoing SMTP by default. If consumers were forced by default to send mail on a different port then servers could determine if they were talking to a consumer or if they were talking to another server. And outgoing email would require a password to send, So the virus wouldn't know the password and the virus wouldn't be able to send email. You could also have the operating system register apps that are allowed to send email and block all apps that aren't specifically allowed. The idea here is that if you can reduce the mechanisms that allow viruses to spread then there comes a point where viruses go away. All we have to do is get the spreading down to that threshold. I believe that if we do it right that the bot army threat can be beaten. And if we got to that point the rest would be manageable. We can talk about other things but I'll stop here to focus on the bot army.
RE: Breaking up the Bot army - we need a plan
-Original Message- From: Marc Perkel [mailto:[EMAIL PROTECTED] Sent: Monday, December 11, 2006 8:49 AM To: users@spamassassin.apache.org Subject: Breaking up the Bot army - we need a plan We can talk about other things but I'll stop here to focus on the bot army. I think you are preaching to the wrong crowd. If you want to help lower your Spam from botnets look into the botnet plugin. Here is his last announcement to this list last week: For those who don't know what Botnet is, it's a plugin which tries to identify whether or not the message has been submitted by a botnet/spam-zombie type host by looking at its DNS characteristics (no reverse DNS, reverse DNS that doesn't resolve, or doesn't resolve back to the relay's IP, or reverse DNS that contains things that look like an ISP's client address). The places I've been using it, and the people I hear about who are using it, have seen a high degree of success. It can be downloaded from: http://people.ucsc.edu/~jrudd/spamassassin/Botnet.tar === CIRCULAR 230 DISCLOSURE: Pursuant to Regulations Governing Practice Before the Internal Revenue Service, any tax advice contained herein is not intended or written to be used and cannot be used by a taxpayer for the purpose of avoiding tax penalties that may be imposed on the taxpayer. === CONFIDENTIALITY NOTICE: This electronic mail message and any attached files contain information intended for the exclusive use of the individual or entity to whom it is addressed and may contain information that is proprietary, privileged, confidential and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any viewing, copying, disclosure or distribution of this information may be subject to legal restriction or sanction. Please notify the sender, by electronic mail or telephone, of any unintended recipients and delete the original message without making any copies. === NOTIFICATION: Katten Muchin Rosenman LLP is an Illinois limited liability partnership that has elected to be governed by the Illinois Uniform Partnership Act (1997). ===
Re: Breaking up the Bot army - we need a plan
On Monday 11 December 2006 15:57, Duncan, Brian M. wrote: ISP's client address). The places I've been using it, and the people I hear about who are using it, have seen a high degree of success. It can be downloaded from: http://people.ucsc.edu/~jrudd/spamassassin/Botnet.tar I just finished a very quick test of the Botnet tool, and the sheer number of FPs against eBy mail coming from eBay's servers was staggering - literally every single mail from eBay. It also, for my testing, hit on a lot of legitimate ham - mostly with BADDNS. I'll run another test later, but I've got to move on to other things now.
Re: Breaking up the Bot army - we need a plan
Duncan Hill wrote: On Monday 11 December 2006 15:57, Duncan, Brian M. wrote: ISP's client address). The places I've been using it, and the people I hear about who are using it, have seen a high degree of success. It can be downloaded from: http://people.ucsc.edu/~jrudd/spamassassin/Botnet.tar I just finished a very quick test of the Botnet tool, and the sheer number of FPs against eBy mail coming from eBay's servers was staggering - literally every single mail from eBay. It also, for my testing, hit on a lot of legitimate ham - mostly with BADDNS. I'll run another test later, but I've got to move on to other things now. The botnet_pass_domain entry for ebay, in the default Botnet.cf file, didn't exempt ebay messages from the Botnet rules? And, if you find that certain tests don't work for you, you can always set the score for that test to 0. (though, personally, I would rather tell people with bad DNS to fix their DNS, or use their ISP's mail server, than exempt them)
RE: Breaking up the Bot army - we need a plan
On Mon, 11 Dec 2006, Duncan, Brian M. wrote: From: Marc Perkel [mailto:[EMAIL PROTECTED] We can talk about other things but I'll stop here to focus on the bot army. I think you are preaching to the wrong crowd. If you want to help lower your Spam from botnets look into the botnet plugin. Please distinguish between filtering spam (a solution that keeps spam out of your mailbox) and changing the protocols and/or ISP behavior to make spamming more difficult (a solution which keeps spam off the wire in the first place). Solving the first problem makes life better for you. Solving the second makes life better for us all. Looking at the statistics stating that 80% of all email is spam (or whatever the figure du jour is) and saying that none of it reaches *my* mailbox is certainly gratifying to the ego (I know it is for me), but it does very little to reduce the tide of garbage that is inundating the Internet more deeply by the day. -- 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 --- 4 days until Bill of Rights day
Re: Breaking up the Bot army - we need a plan
On Monday 11 December 2006 16:16, John Rudd wrote: Duncan Hill wrote: I just finished a very quick test of the Botnet tool, and the sheer number of FPs against eBy mail coming from eBay's servers was staggering - literally every single mail from eBay. It also, for my testing, hit on a lot of legitimate ham - mostly with BADDNS. I'll run another test later, but I've got to move on to other things now. The botnet_pass_domain entry for ebay, in the default Botnet.cf file, didn't exempt ebay messages from the Botnet rules? No, they send mail from servers that reverse to emailebay.com. Added that and things were a bit happier. A mod to the BOTNET rule to check SPF_PASS got rid of a few other false positives (caveat being nothing stops a spammer from setting up SFP for pass). Yes, people should fix their DNS, but it's arguably easier to reconfigure a plug-in than to make hundreds of ISPs fix their damn DNS entries.
RE: Breaking up the Bot army - we need a plan
Again I think you are preaching to the wrong crowd. No offense meant. Please distinguish between filtering spam (a solution that keeps spam out of your mailbox) and changing the protocols and/or ISP behavior to make spamming more difficult (a solution which keeps spam off the wire in the first place). Solving the first problem makes life better for you. Solving the second makes life better for us all. Looking at the statistics stating that 80% of all email is spam (or whatever the figure du jour is) and saying that none of it reaches *my* mailbox is certainly gratifying to the ego (I know it is for me), but it does very little to reduce the tide of garbage that is inundating the Internet more deeply by the day. -- 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 === CIRCULAR 230 DISCLOSURE: Pursuant to Regulations Governing Practice Before the Internal Revenue Service, any tax advice contained herein is not intended or written to be used and cannot be used by a taxpayer for the purpose of avoiding tax penalties that may be imposed on the taxpayer. === CONFIDENTIALITY NOTICE: This electronic mail message and any attached files contain information intended for the exclusive use of the individual or entity to whom it is addressed and may contain information that is proprietary, privileged, confidential and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any viewing, copying, disclosure or distribution of this information may be subject to legal restriction or sanction. Please notify the sender, by electronic mail or telephone, of any unintended recipients and delete the original message without making any copies. === NOTIFICATION: Katten Muchin Rosenman LLP is an Illinois limited liability partnership that has elected to be governed by the Illinois Uniform Partnership Act (1997). ===
Re: Breaking up the Bot army - we need a plan
Duncan Hill wrote: On Monday 11 December 2006 16:16, John Rudd wrote: Duncan Hill wrote: I just finished a very quick test of the Botnet tool, and the sheer number of FPs against eBy mail coming from eBay's servers was staggering - literally every single mail from eBay. It also, for my testing, hit on a lot of legitimate ham - mostly with BADDNS. I'll run another test later, but I've got to move on to other things now. The botnet_pass_domain entry for ebay, in the default Botnet.cf file, didn't exempt ebay messages from the Botnet rules? No, they send mail from servers that reverse to emailebay.com. Added that and things were a bit happier. A mod to the BOTNET rule to check SPF_PASS got rid of a few other false positives (caveat being nothing stops a spammer from setting up SFP for pass). Yes, people should fix their DNS, but it's arguably easier to reconfigure a plug-in than to make hundreds of ISPs fix their damn DNS entries. On the other hand, that enables their stupidity, instead of being part of a group that might grow large enough to force them to behave responsibly. But, I do understand the practical trade-off. I'll add emailebay.com to the base cf file. I'm working on an alternative to SPF_PASS (directly checking the sender's mail domain's A record and/or MX record to see if it leads back to the IP addr). I'm not sure how soon I'll get that worked into the code though. I thought about trusting SPF, but, really, SPF isn't trustable.
Re: Breaking up the Bot army - we need a plan
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Marc Perkel wrote: How do we isolate end users so that they can't get viruses as easily and spread them as easily? That would seem to be the job of filters, either upstream from the end-users or installed on their computers. Upstream solutions are usually preferable, if only because they tend to be more robust and maintained by people with more computer security knowledge and expertise, but obviously this can't be the entire solution. Upstream solutions work well for things like mail filtering, but less so for screening content being downloaded or uploaded via HTTP, FTP, IM, etc. That said, /containing/ infected hosts is probably an easier first step to achieve. Applying mail filtering to outbound as well as inbound mail would catch a lot of this (i.e. a fence in vs. fence out philosophy). ISPs also need to look at ways to auto-detect symptoms of malware-like activity--bursts of particularly-shaped traffic that can help them heuristically identify IP addresses on their networks that need to be isolated (or safely proxied). I'm someone who works from home and provides so service from home. So I would not want to be prohibited from running an email server from home. Many broadband providers already offer a separate business class account for users who need static IP addresses, need higher bandwidth limits, rDNS entries, and want to host their own servers. Trying to do this sort of thing on a dynamic IP with some kind of dynamic DNS service is a kludgy solution that should be discouraged, provided that a business class alternative is available. By differentiating these types of broadband accounts, ISPs can use port-blocking more effectively. All outgoing email from consumers should by default be required to use authenticated SMTP or some new authenticated protocol. At least force consumers to use the submission port and block off port 25 for outgoing SMTP by default. If consumers were forced by default to send mail on a different port then servers could determine if they were talking to a consumer or if they were talking to another server. More specifically, it would allow your mail server to make stricter assumptions about what it receives on port 25. If it knows that all client-submitted mail arrives by other means, it can trust that whatever connections it receives on port 25 should be exclusively from other servers--hosts with MX records that can be verified. A connection attempt from a host without a MX record can be safely dropped in this case. In short, none of this advice is particularly new, and the archives of lists like SPAM-L will show that the anti-spam community has been clamoring for ISPs to adopt strategies like this for years now. In large part I think the reason for the slow adoption of these methods is inertia--larger networks run by larger companies need more hands and minds to maintain, much less modify, and so they go with what works until that ceases to be the case. When botnets become a large enough threat to their bottom line, they'll reexamine their priorities and we'll start to see action at long last. Unfortunately getting network admins to think in terms of fencing in rather than just fencing out involves something of a worldview-shift. Many of us are so busy worrying about blocking the bad stuff from /entering/ our networks that we don't think too hard about the fact that that stuff came /out/ of someone else's network. If we all did a competent job of watching our own networks to prevent our own users from harming networks outside our fences, the botnet problem would be all but dead overnight. Instead we spend most of our time worrying about putting up one-way walls to keep the invaders out, while our own users--often unknowingly--continue to spew outbound crud. - -- Robert LeBlanc [EMAIL PROTECTED] Renaissoft, Inc. Maia Mailguard http://www.maiamailguard.com/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFFfalEGmqOER2NHewRAv03AKCEBAwGr/KLZ+Xq9dUnRKNJQu5UywCeMjut v7eWWNXrjppR95WHzS6ni2c= =0EjI -END PGP SIGNATURE-
Re: Breaking up the Bot army - we need a plan
John Rudd wrote: Marc Perkel wrote: I'm someone who works from home and provides so service from home. So I would not want to be prohibited from running an email server from home. But if I had to got to a web panel that my ISP provided to open up ports that would be fine with me. I'm curious.. as someone who ALSO runs a home mail server... What's wrong with evolving best practices to require that our outgoing email be channeled through our ISP's mail server, instead of having our customer-assigned IP addresses directly connect to other people's mail servers? And forcing users to use their ISP's mail server efficively defeats SPF And just closing port 25 outgoing wont help for long as spammers just switch to submission port Matt
RE: Breaking up the Bot army - we need a plan
From: John Rudd [mailto:[EMAIL PROTECTED] Marc Perkel wrote: I'm someone who works from home and provides so service from home. So I would not want to be prohibited from running an email server from home. But if I had to got to a web panel that my ISP provided to open up ports that would be fine with me. I'm curious.. as someone who ALSO runs a home mail server... What's wrong with evolving best practices to require that our outgoing email be channeled through our ISP's mail server, instead of having our customer-assigned IP addresses directly connect to other people's mail servers? That your e-mail service will be at most as best as your provider's one is. That is, if your provider is sometime loosing outgoing mail or it accepts messages not greater than 2 MB, you have to stick with it if you use their (great?) service. Also, if you like to break some of the limits they impose, you may have to pay something to them. Ie: do you want a 30MB mailsize limit? Ok, pay € 50,00 / year / domain. Now, of course one can use its ISP's mail servers to forward mail, but this is going to have an impact mostly on the small companies which can't afford the costs to enter the market. Big companies can easily buy /26 IP address chunks and run their own rDNS zones. Small companies are forced to shrink they already small incomes thanks to the kind of policies you suggest. Please note that the 'evolving best practices' that you invoke are set by large ISPs, not by the voiceless small ones... Now, I know that this could sound weird to most of you, but I definitely would prefer to receive some more spam whether the alternative would be to have to deal with my ISP about every and each service I would like to run on my own server. --- Giampaolo Tomassoni - IT Consultant Piazza VIII Aprile 1948, 4 I-53044 Chiusi (SI) - Italy Ph: +39-0578-21100 MAI inviare una e-mail a: NEVER send an e-mail to: [EMAIL PROTECTED] That doesn't prohibit either of us from running an email server at home.
Re: Breaking up the Bot army - we need a plan
Matthias Keller wrote: John Rudd wrote: Marc Perkel wrote: I'm someone who works from home and provides so service from home. So I would not want to be prohibited from running an email server from home. But if I had to got to a web panel that my ISP provided to open up ports that would be fine with me. I'm curious.. as someone who ALSO runs a home mail server... What's wrong with evolving best practices to require that our outgoing email be channeled through our ISP's mail server, instead of having our customer-assigned IP addresses directly connect to other people's mail servers? And forcing users to use their ISP's mail server efficively defeats SPF a) they can/should include their ISP in their SPF record b) SPF defeats itself; preserving SPF is a non-reason for objecting to a new practice. And just closing port 25 outgoing wont help for long as spammers just switch to submission port I don't see your point here. If a spammer contacts my MSP port, they're going to have to know an account and password to authenticate as. Anyone who isn't requiring their clients to auth on their MSP port kind of deserves to have their MSP port inundated with spam. And if they allow those messages to route out, then they're acting as an open-relay of sorts, and deserve to have their mail server blacklisted. Spammers switching to the MSP port seems to me to be a non-issue.
Re: Breaking up the Bot army - we need a plan
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Matthias Keller wrote: And just closing port 25 outgoing wont help for long as spammers just switch to submission port Yes, but the point of using a submission port to segregate the traffic channels is not to obfuscate things for spammers, it's to allow a mail administrator to apply different acceptance criteria to the different channels. Connections arriving on port 25 can be assumed to come from servers with MX records, so that becomes a testable assumption and a precondition for connection. Connections arriving on the submission port can be assumed to come from clients, and those users presumably have local accounts they can authenticate with using SMTP auth. Spammers who simply redirect their traffic to the submission port won't get anywhere without also being able to defeat the SMTP auth component. - -- Robert LeBlanc [EMAIL PROTECTED] Renaissoft, Inc. Maia Mailguard http://www.maiamailguard.com/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFFfbQWGmqOER2NHewRAv3IAJ0fzy9zFSR2thYXUQ+LM5yJlsED2ACdFllI kRu9WJMt16ptSIJcIdbcYZg= =FU86 -END PGP SIGNATURE-
Re: Breaking up the Bot army - we need a plan
On Mon, 11 Dec 2006, John Rudd wrote: Marc Perkel wrote: I'm someone who works from home and provides so service from home. So I would not want to be prohibited from running an email server from home. But if I had to got to a web panel that my ISP provided to open up ports that would be fine with me. I'm curious.. as someone who ALSO runs a home mail server... What's wrong with evolving best practices to require that our outgoing email be channeled through our ISP's mail server, instead of having our customer-assigned IP addresses directly connect to other people's mail servers? One possible hurdle is the fact that your source domain will probably *not* be the ISP's domain, so your routing your domain email outbound via their servers would require special MTA rules on their part (except for the subcase where you're trying to send mail to another user at that ISP). Think open relay. The ISP mailserver should only be accepting mail *from* their domain or *to* their domain. Mail from and to domains they don't own should be blocked. You might have problems getting them to permit relay by a domain you own if you don't have a business-class account (and thus a higher level of support). -- 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 --- 4 days until Bill of Rights day
Re: Breaking up the Bot army - we need a plan
On Mon, 11 Dec 2006, Matthias Keller wrote: I'm curious.. as someone who ALSO runs a home mail server... What's wrong with evolving best practices to require that our outgoing email be channeled through our ISP's mail server, instead of having our customer-assigned IP addresses directly connect to other people's mail servers? And forcing users to use their ISP's mail server efficively defeats SPF How so? I'm assuming a home business owner owns and uses their own domain and has the ability to set up SPF records for that domain. If you are routing your outbound mail via your ISP's MTAs, just grab your ISP's SPF record and use it for your domain. If your ISP is doing SPF checks you might need to talk to their MTA via SMTP AUTH to bypass that test. -- 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 --- 4 days until Bill of Rights day
Re: Breaking up the Bot army - we need a plan
Robert LeBlanc wrote: Connections arriving on port 25 can be assumed to come from servers with MX records, so that becomes a testable assumption and a precondition for connection. Since when? If I rejected mail on that condition I would never have received your message. Daryl
Re: Breaking up the Bot army - we need a plan
John D. Hardin wrote: On Mon, 11 Dec 2006, Matthias Keller wrote: I'm curious.. as someone who ALSO runs a home mail server... What's wrong with evolving best practices to require that our outgoing email be channeled through our ISP's mail server, instead of having our customer-assigned IP addresses directly connect to other people's mail servers? And forcing users to use their ISP's mail server efficively defeats SPF How so? I'm assuming a home business owner owns and uses their own domain and has the ability to set up SPF records for that domain. If you are routing your outbound mail via your ISP's MTAs, just grab your ISP's SPF record and use it for your domain. If your ISP is doing SPF checks you might need to talk to their MTA via SMTP AUTH to bypass that test. a) an average user has no knowledge of SPF and cannot setup such a record correctly b) most providers (at least around here) dont allow users to freely modify their dns zones c) users using laptops might be using many different providers - the one at home, the one in the office, one on the road, an occasional wlan one - you just cant include all these provider's MTAs that you might ever be using I agree for (some) businesses this might be doable as long as their guys aren't travelling or home working too much but it's impossible for privately owned domains or when the users use their emails from all their private ISPs at home Matt
Re: Breaking up the Bot army - we need a plan
John D. Hardin wrote: On Mon, 11 Dec 2006, John Rudd wrote: Marc Perkel wrote: I'm someone who works from home and provides so service from home. So I would not want to be prohibited from running an email server from home. But if I had to got to a web panel that my ISP provided to open up ports that would be fine with me. I'm curious.. as someone who ALSO runs a home mail server... What's wrong with evolving best practices to require that our outgoing email be channeled through our ISP's mail server, instead of having our customer-assigned IP addresses directly connect to other people's mail servers? One possible hurdle is the fact that your source domain will probably *not* be the ISP's domain, so your routing your domain email outbound via their servers would require special MTA rules on their part (except for the subcase where you're trying to send mail to another user at that ISP). Think open relay. The ISP mailserver should only be accepting mail *from* their domain or *to* their domain. Mail from and to domains they don't own should be blocked. I think you're mis-stating this. 1) Being an open relay isn't about accepting mail, it's about routing mail. 2) They should only route mail to outside recipients if: a) it comes from their own IP address space b) it comes from an authenticated session I think you're mis-stating 2a. The traditional requirement is as I stated it: the mail must come from the ISP's address space, not from a sender in their mail domain. This works fine: my IP address is assigned to me by them, therefore I am within their routing domain, therefore they are not an open relay for routing my messages out to the world, even though the sender's email address is @mydomain.com instead of @myisp.net. But, even if you change 2a to be mail domain based instead of IP address based, then that still leaves 2b. I can use a sender address of [EMAIL PROTECTED], but authenticate with SMTP-AUTH to my ISP as [EMAIL PROTECTED] (there is no requirement that SMTP-AUTH match the sender address; nor should there be). I then satisfy 2b, and my email passes through their servers without a problem.
Re: Breaking up the Bot army - we need a plan
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Daryl C. W. O'Shea wrote: Robert LeBlanc wrote: Connections arriving on port 25 can be assumed to come from servers with MX records, so that becomes a testable assumption and a precondition for connection. Since when? If I rejected mail on that condition I would never have received your message. Are you suggesting that mail.apache.org does not have a MX record associated with it? My point (taken out of context in your quote above) was that /if/ you segregate your traffic between port 25 and a submission port, such that all of your client traffic connects and authenticates via the submission port, /then/ you can tighten the restrictions on your port 25 connections, because all you should be accepting on that port thereafter is MX-to-MX traffic. Any legitimate client-to-MX traffic should be going to your submission port. - -- Robert LeBlanc [EMAIL PROTECTED] Renaissoft, Inc. Maia Mailguard http://www.maiamailguard.com/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFFfbx/GmqOER2NHewRAhApAJ9Ntec/vkk6SlY8DmXkwHYovbM1rACgm/Nw KWfCIXmF0MRXPsoPjYZgOjw= =TmHw -END PGP SIGNATURE-
Re: Breaking up the Bot army - we need a plan
Robert LeBlanc wrote: Connections arriving on port 25 can be assumed to come from servers with MX records, so that becomes a testable assumption and a precondition for connection. There are two things that are wrong with that statement. 1) MX records are a good idea, not an absolute requirement. 2) MX records are for determining a domain's incoming mail servers. The problem at hand is determining whether you're correctly dealing with a domain's outgoing mail servers. For a SOHO mail server, you might be able to assume that the incoming and outgoing mail servers are the same. But, that isn't necessarily true, and it's an assumption that doesn't scale to large organizations.
Re: Breaking up the Bot army - we need a plan
Matthias Keller wrote: John D. Hardin wrote: On Mon, 11 Dec 2006, Matthias Keller wrote: I'm curious.. as someone who ALSO runs a home mail server... What's wrong with evolving best practices to require that our outgoing email be channeled through our ISP's mail server, instead of having our customer-assigned IP addresses directly connect to other people's mail servers? And forcing users to use their ISP's mail server efficively defeats SPF How so? I'm assuming a home business owner owns and uses their own domain and has the ability to set up SPF records for that domain. If you are routing your outbound mail via your ISP's MTAs, just grab your ISP's SPF record and use it for your domain. If your ISP is doing SPF checks you might need to talk to their MTA via SMTP AUTH to bypass that test. a) an average user has no knowledge of SPF and cannot setup such a record correctly How many average users are running SOHO mail servers? b) most providers (at least around here) dont allow users to freely modify their dns zones They don't need to modify their provider's DNS, they only need to modify their own mail domain's DNS. For example, I only need control of/access to rudd.cc's zone. I don't need access to sonic.net's zones. (those being my home domain and home ISP) c) users using laptops might be using many different providers - the one at home, the one in the office, one on the road, an occasional wlan one - you just cant include all these provider's MTAs that you might ever be using If they're running their own mail server on their own home system, why aren't they using SMTP-AUTH to connect to their home mail server (or SMTP-AUTH to their primary ISP's mail server), and route their mail through there? SMTP-AUTH handles the mobile workstation just fine.
Re: Breaking up the Bot army - we need a plan
so what is wrong with a MTA that - checks helo and just takes a note - accepts smtp auth, if provided (and erases bad notes from the helo in that case) - accepts an optional second helo after the auth and discards it - accepts mail from and rcpt to ... and at the first rcpt to issues a 5xx if the dialogue so far does not meet expectations, e.g. a non-auth transaction must go to one of the domains on that server, and any transaction mentioning one of the local domains in helo or mail from must be authenticated, and the mail from domain must exist I recall ebay mails got rejected when I first started this, and according to a recent discussion job monsters would also reject I hope enough admins rejecting that stuff would help to educate these sites Wolfgang Hamann Robert LeBlanc wrote: Matthias Keller wrote: And just closing port 25 outgoing wont help for long as spammers just switch to submission port Yes, but the point of using a submission port to segregate the traffic channels is not to obfuscate things for spammers, it's to allow a mail administrator to apply different acceptance criteria to the different channels. Connections arriving on port 25 can be assumed to come from servers with MX records, so that becomes a testable assumption and a precondition for connection. Connections arriving on the submission port can be assumed to come from clients, and those users presumably have local accounts they can authenticate with using SMTP auth. Spammers who simply redirect their traffic to the submission port won't get anywhere without also being able to defeat the SMTP auth component.
Re: Breaking up the Bot army - we need a plan
Robert LeBlanc wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Daryl C. W. O'Shea wrote: Robert LeBlanc wrote: Connections arriving on port 25 can be assumed to come from servers with MX records, so that becomes a testable assumption and a precondition for connection. Since when? If I rejected mail on that condition I would never have received your message. Are you suggesting that mail.apache.org does not have a MX record associated with it? Uh, yeah. [EMAIL PROTECTED] dos]$ dig mx mail.apache.org | grep ANSWER ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 My point (taken out of context in your quote above) was that /if/ you segregate your traffic between port 25 and a submission port, such that all of your client traffic connects and authenticates via the submission port, /then/ you can tighten the restrictions on your port 25 connections, because all you should be accepting on that port thereafter is MX-to-MX traffic. Any legitimate client-to-MX traffic should be going to your submission port. How was that out of context? You said that if you're only expecting mail from non-local domains (MX-to-MX) on port 25 you can reject hosts if they don't have an MX record. That's not true and that's what I said. Daryl
Re: Breaking up the Bot army - we need a plan
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 John Rudd wrote: Robert LeBlanc wrote: Connections arriving on port 25 can be assumed to come from servers with MX records, so that becomes a testable assumption and a precondition for connection. There are two things that are wrong with that statement. 1) MX records are a good idea, not an absolute requirement. 2) MX records are for determining a domain's incoming mail servers. The problem at hand is determining whether you're correctly dealing with a domain's outgoing mail servers. For a SOHO mail server, you might be able to assume that the incoming and outgoing mail servers are the same. But, that isn't necessarily true, and it's an assumption that doesn't scale to large organizations. My mistake, then; thanks for the clarification. I suppose what we need, then, is something like a TX record for helping to identify outbound mail servers. All of that said, though, my basic point remains--you can apply stricter assumptions to your port 25 connections once you separate out your client traffic to a submission port. Using MX records may not be the way to do this, but combinations of other tests should be possible to achieve this. - -- Robert LeBlanc [EMAIL PROTECTED] Renaissoft, Inc. Maia Mailguard http://www.maiamailguard.com/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFFfcAnGmqOER2NHewRAjZxAJ44h/nQ1SQQ/Vrt4NTPOjMLZrmTjACff18j VgnB4Pi1UxZJwvgBCp1LlhA= =cZ56 -END PGP SIGNATURE-
Re: Breaking up the Bot army - we need a plan
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Daryl C. W. O'Shea wrote: You said that if you're only expecting mail from non-local domains (MX-to-MX) on port 25 you can reject hosts if they don't have an MX record. That's not true and that's what I said. As I conceded in another post a few minutes ago, my understanding of MX records was flawed. Sorry for the confusion. - -- Robert LeBlanc [EMAIL PROTECTED] Renaissoft, Inc. Maia Mailguard http://www.maiamailguard.com/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFFfcC6GmqOER2NHewRApDpAKCn3SWdIH+r4PNa67Ddwt11bi5vvQCfS6yG IqXwsBxS7Vr8C4Bfz7pTORg= =vt0c -END PGP SIGNATURE-
Re: Breaking up the Bot army - we need a plan
Robert LeBlanc wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 John Rudd wrote: Robert LeBlanc wrote: Connections arriving on port 25 can be assumed to come from servers with MX records, so that becomes a testable assumption and a precondition for connection. There are two things that are wrong with that statement. 1) MX records are a good idea, not an absolute requirement. 2) MX records are for determining a domain's incoming mail servers. The problem at hand is determining whether you're correctly dealing with a domain's outgoing mail servers. For a SOHO mail server, you might be able to assume that the incoming and outgoing mail servers are the same. But, that isn't necessarily true, and it's an assumption that doesn't scale to large organizations. My mistake, then; thanks for the clarification. I suppose what we need, then, is something like a TX record for helping to identify outbound mail servers. All of that said, though, my basic point remains--you can apply stricter assumptions to your port 25 connections once you separate out your client traffic to a submission port. Using MX records may not be the way to do this, but combinations of other tests should be possible to achieve this. - -- Robert LeBlanc [EMAIL PROTECTED] Renaissoft, Inc. Maia Mailguard http://www.maiamailguard.com/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFFfcAnGmqOER2NHewRAjZxAJ44h/nQ1SQQ/Vrt4NTPOjMLZrmTjACff18j VgnB4Pi1UxZJwvgBCp1LlhA= =cZ56 -END PGP SIGNATURE- SPF already does this -- Thanks, James
Re: Breaking up the Bot army - we need a plan
JamesDR wrote: SPF already does this poorly. We need something that actually works.
RE: Breaking up the Bot army - we need a plan
Robert LeBlanc wrote: My mistake, then; thanks for the clarification. I suppose what we need, then, is something like a TX record for helping to identify outbound mail servers. That already exists. It's called SPF. -- Bowie
RE: Breaking up the Bot army - we need a plan
John Rudd wrote: JamesDR wrote: SPF already does this poorly. We need something that actually works. And what would you do differently? An SPF record is basically just a list of valid mail servers for a domain plus a bit of information about how strict the domain wants to be with that list. The main problem with SPF is that all valid mail for a domain does not necessarily come from that domain's mail servers. (Ignoring, for the moment, all of the sites with mis-configured or nonexistent SPF records) -- Bowie
Re: Breaking up the Bot army - we need a plan
On Mon, 11 Dec 2006, Matthias Keller wrote: John D. Hardin wrote: On Mon, 11 Dec 2006, Matthias Keller wrote: And forcing users to use their ISP's mail server efficively defeats SPF How so? I'm assuming a home business owner owns and uses their own domain and has the ability to set up SPF records for that domain. If you are routing your outbound mail via your ISP's MTAs, just grab your ISP's SPF record and use it for your domain. If your ISP is doing SPF checks you might need to talk to their MTA via SMTP AUTH to bypass that test. a) an average user has no knowledge of SPF and cannot setup such a record correctly If they can't set up the SPF record initially, then how does routing their email via their ISP defeat SPF? Bringing up that concern implies that the admin of this hypothetical mail system *is* able to set up an SPF record that mail routed via the ISP would break. b) most providers (at least around here) dont allow users to freely modify their dns zones So host your DNS somewhere that does allow control. DNS hosting is seperable from ISP connectivity, and again, we're assuming that the user is able to set up SPF in the first place. c) users using laptops might be using many different providers - the one at home, the one in the office, one on the road, an occasional wlan one - you just cant include all these provider's MTAs that you might ever be using ...how the heck would you set up SPF to cover a roaming mail source in the first place?? Dynamically-updating SPF records with short TTL? I agree for (some) businesses this might be doable as long as their guys aren't travelling or home working too much but it's impossible for privately owned domains or when the users use their emails from all their private ISPs at home I'm sorry, I assumed your original hypothetical was for a one- or two-person home-based business, not multiple roaming users having multiple ISPs. For the case where all of the users are at the same ISP, it *is* doable assuming the ISP will relay messages submitted via SMTP AUTH without performing SPF checks or verification that the FROM address is in a domain the ISP controls. Of course, SMTP AUTH + promiscuous relay does not prevent spamming with forged sender addresses. It might make it easier to track down the p0wned box, but it won't block the mail based on the domains in the envelope. -- 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 --- 4 days until Bill of Rights day
Re: Breaking up the Bot army - we need a plan
On Mon, 11 Dec 2006, John Rudd wrote: Think open relay. The ISP mailserver should only be accepting mail *from* their domain or *to* their domain. Mail from and to domains they don't own should be blocked. I think you're mis-stating this. 1) Being an open relay isn't about accepting mail, it's about routing mail. 2) They should only route mail to outside recipients if: a) it comes from their own IP address space b) it comes from an authenticated session I think you're mis-stating 2a. The traditional requirement is as I stated it: the mail must come from the ISP's address space, not from a sender in their mail domain. This works fine: my IP address is assigned to me by them, therefore I am within their routing domain, therefore they are not an open relay for routing my messages out to the world, even though the sender's email address is @mydomain.com instead of @myisp.net. But, even if you change 2a to be mail domain based instead of IP address based, then that still leaves 2b. I can use a sender address of [EMAIL PROTECTED], but authenticate with SMTP-AUTH to my ISP as [EMAIL PROTECTED] (there is no requirement that SMTP-AUTH match the sender address; nor should there be). I then satisfy 2b, and my email passes through their servers without a problem. I hope only corporate MTAs are using 2a. I don't like the idea that (for example) all Comcast Home users will be able to send forged mail via the Comcasst MTAs... And 2b still doesn't help if the spambot uses the locally-stored authentication information. But I only brought this up as an additional issue. If the ISP is doeing either 2a or 2b then all you need to worry about is including the ISP's SPF information in the SPF record for your domain. -- 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 --- 4 days until Bill of Rights day
Re: Breaking up the Bot army - we need a plan
On Mon, 11 Dec 2006, Robert LeBlanc wrote: My mistake, then; thanks for the clarification. I suppose what we need, then, is something like a TX record for helping to identify outbound mail servers. SPF -- 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 --- 4 days until Bill of Rights day
Re: Breaking up the Bot army - we need a plan
On Mon, 11 Dec 2006, Marc Perkel wrote: All outgoing email from consumers should by default be required to use authenticated SMTP or some new authenticated protocol. Unfortunately this is defeated by a Remember this password? option in the mail client. A bot can easily retrieve the authentication information from the mail client's configs on disk, and may be able to retrieve it from the mail client directly if it is executing. And if the mail client refuses to remember the user's password for them, it will probably experience declining popularity. -- 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 --- 4 days until Bill of Rights day
Re: Breaking up the Bot army - we need a plan
John Rudd wrote: JamesDR wrote: SPF already does this poorly. We need something that actually works. Would you care to elaborate on why SPF doesn't work for sender verification? Its pretty simple, doesn't get much more simple that what SPF does... If SPF doesn't work, nothing will. I can see why it works quite well... ServerA sends mail to ServerB from [EMAIL PROTECTED], ServerB queries JDoe.net's dns server for an SPF record. ServerB finds that ServerA is allowed to send mail, ServerB delivers mail (After suitable spam/virus filtering of course.) SpamerA sends mail to ServerB from [EMAIL PROTECTED], ServerB queries JDoe.net's dns server for an SPF record. ServerB finds that SpamerA isn't allowed to be sending mail. ServerB bins the mail. (All before DATA stage...) This doesn't stop the bot nets, but stops the Joe Jobs that are so common. If everyone used spf (and it doesn't break forwarding, if properly setup) then you would force the spamer in this case to setup his own addresses, own domain, and own dns server (or hijack some other poor person's) SPF doesn't prove hamyness, but can prove spamyness. -- Thanks, James
Re: Breaking up the Bot army - we need a plan
John D. Hardin wrote: On Mon, 11 Dec 2006, Marc Perkel wrote: All outgoing email from consumers should by default be required to use authenticated SMTP or some new authenticated protocol. Unfortunately this is defeated by a Remember this password? option in the mail client. A bot can easily retrieve the authentication information from the mail client's configs on disk, and may be able to retrieve it from the mail client directly if it is executing. That's not a problem. The ISP's MTA will put the user's authentication ID into a log or in to the Received header. a) the ISP then has the ability to track complaints, in bulk, back to customers who are causing problems, and require them to clean their machines, or switch to using something like webmail if they can't get their act together. Or, they can simply see it based on messages filling up their mail queues. b) the rest of us can look for those authentication fingerprints in received headers and block them (perhaps an auth-id RBL which lists suspects for 48-96 hours, or something). c) when we receive a flood of new spam, we can easily pick out which hosts are currently sending us the most traffic because the traffic is being aggregated at the ISP level. So, out of 1,000,000 messages per day, I may only have 1000-2000 relays that I need to scrutinize (which I can then sort by highest message count, and correlate to highest spam count). Whereas, now, out of 1,000,000 messages per day, I might have 900,000 relays I need to scrutinize, and only 1 or 2 spam messages per relay. Hard to sort them by message count to figure out who I need to report problems to, and/or temporarily block. Forcing the traffic to aggregate at the ISP/provider level makes MANY things easier to track.
Re: Breaking up the Bot army - we need a plan
Matthias Keller wrote: John D. Hardin wrote: On Mon, 11 Dec 2006, Matthias Keller wrote: I'm curious.. as someone who ALSO runs a home mail server... What's wrong with evolving best practices to require that our outgoing email be channeled through our ISP's mail server, instead of having our customer-assigned IP addresses directly connect to other people's mail servers? And forcing users to use their ISP's mail server efficively defeats SPF How so? I'm assuming a home business owner owns and uses their own domain and has the ability to set up SPF records for that domain. If you are routing your outbound mail via your ISP's MTAs, just grab your ISP's SPF record and use it for your domain. If your ISP is doing SPF checks you might need to talk to their MTA via SMTP AUTH to bypass that test. a) an average user has no knowledge of SPF and cannot setup such a record correctly Average users don't have a clue about security, so this is a non-point because they are unaware that they themselves are helping the spam problem. b) most providers (at least around here) dont allow users to freely modify their dns zones True, what stops those who know what they are doing from registering outside the ISP? I found this to be much more cost effective. Run your own DNS servers. The average user won't do this. They will be content with using what the ISP have given them (5 email addresses, 100MB of storage for example.) c) users using laptops might be using many different providers - the one at home, the one in the office, one on the road, an occasional wlan one - you just cant include all these provider's MTAs that you might ever be using True, however, there is still VPN for these sorts of things. I don't think I would trust another provider's MTA to deliver content sensitive mail. You can never know if the other person got it because you are not directly in control. I agree for (some) businesses this might be doable as long as their guys aren't travelling or home working too much but it's impossible for privately owned domains or when the users use their emails from all their private ISPs at home Matt Just for those who don't have the know how or the man power. -- Thanks, James
Re: Breaking up the Bot army - we need a plan
JamesDR wrote: John Rudd wrote: JamesDR wrote: SPF already does this poorly. We need something that actually works. Would you care to elaborate on why SPF doesn't work for sender verification? Its pretty simple, doesn't get much more simple that what SPF does... If SPF doesn't work, nothing will. I can see why it works quite well... I receive a message from relay W.X.Y.Z.res.isp.net (where w.x.y.z is the ip address of the relay). I want to know if this message is coming from a legitimate SOHO type mail server, or a spambot (the relevant discussion here being spambots). I look at the sender mail domain: foo.com. I look up the SPF record for foo.com. It says: +all So, I get an SPF-PASS, yet this SPF-PASS has done _nothing_ to help solve the problem. It has, if anything, made the problem MUCH more difficult to solve. This doesn't stop the bot nets, Uh.. I think, given the subject line, you've just argued against your own assertion in this discussion. SPF doesn't prove hamyness, but can prove spamyness. In my above example, SPF did nothing useful. And, my example shows exactly why SPF does not help at all with the spambot problem. If I'm a spambot wrangler, I create a group of throw-away domains, put in SPF records for them that say +all, and then send out my storm of spam. Then I abandon those domains, and create a new batch of them for the next go-round. IMO, SPF is a liability when fighting spambots.
Re: Breaking up the Bot army - we need a plan
On Mon, 11 Dec 2006, John Rudd wrote: I look up the SPF record for foo.com. It says: +all ...so the SPF spec has some holes that permit abuse. Tighten the spec my prohibiting +all and +0.0.0.0/1 +8.0.0.0/1 and similar nonsense, and/or modify SPF client implementations to place an upper limit on the number of hosts that can match the spec. This doesn't mean SPF is crap. -- 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 --- 4 days until Bill of Rights day
RE: Breaking up the Bot army - we need a plan
In my above example, SPF did nothing useful. And, my example shows exactly why SPF does not help at all with the spambot problem. If I'm a spambot wrangler, I create a group of throw-away domains, put in SPF records for them that say +all, and then send out my storm of spam. Then I abandon those domains, and create a new batch of them for the next go-round. IMO, SPF is a liability when fighting spambots. So perhaps SPF should consider removing +all as an option. Realisticly anyone that has to say my e-mail might come from anywhere is contributing to the problem and probably deserves to have e-mail bounced. OTOH, I can see where a spammer could easily register a bunch of domains, and then update the SPF records to include the specific spambots that are delivering e-mail from each domain. I'm not sure there IS a solution that works for fighting this. ISPs contribute to the problem by dinging businesses for everything from number of messages relayed, bytes relayed, reverse DNS setup, ... It took me almost 2 months to get all the issues straightened out after we moved and changed ISPs. Everything's an extra cost option. But I have a nice list now, so next time they all get negotiated as included before we sign the contract. Either that, or we find someone else. Then there's the wonderful ISPs that assign static Ips in the middle of dynamic IP blocks. I really hate confirmation-based antispam systems, but I don't really have a better solution to stopping this. If I have to manually approve every person/list I want to send to me, then at least I have control over it. Right now, our server's having trouble keeping up with the load. I honestly don't know how long before I decide it isn't worth the effort to host our own e-mail. Bret
RE: Breaking up the Bot army - we need a plan
On Mon, 2006-12-11 at 14:41 -0800, Bret Miller wrote: took me almost 2 months to get all the issues straightened out after we moved and changed ISPs. Everything's an extra cost option. But I have a nice list now, so next time they all get negotiated as included before we sign the contract. Either that, or we find someone else. Post the list! ;-) -- ~~~ Karl Auer ([EMAIL PROTECTED]) +61-2-64957160 (h) http://www.biplane.com.au/~kauer/ +61-428-957160 (mob)
Re: Breaking up the Bot army - we need a plan
John D. Hardin wrote: This doesn't mean SPF is crap. As SPF currently exists, it is crap.
Re: Breaking up the Bot army - we need a plan
On Monday 11 December 2006 16:50, JamesDR wrote: Would you care to elaborate on why SPF doesn't work for sender verification? Its pretty simple, doesn't get much more simple that what SPF does... If SPF doesn't work, nothing will. There is nothing in SPF to keep a spammer with a botnet from putting 0.0.0.0/0 as their approved domain limit. -- My other computer is your Windows machine
RE: Breaking up the Bot army - we need a plan
On Mon, 11 Dec 2006, Bret Miller wrote: OTOH, I can see where a spammer could easily register a bunch of domains, and then update the SPF records to include the specific spambots that are delivering e-mail from each domain. That's not a problem. That means you can with high confidence toss anything that comes from those domains and passes SPF, assuming you're aware of the domain quickly enough. Plus that would be pretty clear evidence linking the spambot owner to the domain owner. -- 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 --- 4 days until Bill of Rights day
Re: Breaking up the Bot army - we need a plan
John Rudd wrote: a) if you're big, have reverse DNS that works, looks like a server, and doesn't look like a client (ie. the things Botnet looks for). b) if you're small: i) try to get your ISP to do the right thing (above) with your reverse DNS, or ii) get a hosted service that does the right thing (above) with your reverse DNS, or iii) use your ISP's outgoing mail server for your outbound mail, or iv) don't have separate outgoing and incoming mail servers (ie. your outgoing mail server's IP address should be resolved by a hostname in either your mail domain's MX record, or your mail domain's A record) And then use some heuristics like Botnet* to get rid of the hosts that don't conform to the above. (* the next version of Botnet is going to have an option for exempting messages in case b-iv: if the sender's mail domain leads back to the relay's IP address, then ignore the fact that it has botnet-like DNS ... but I'll probably put a cap on the number of IP A records and MX records Botnet will look at, to prevent spammer abuse ... a SOHO shop probably wouldn't have more than a few) I've had Botnet 0.6 running for a few days now, with a spamassassin score of 1.0 for testing. I have only 25 users, and we get about 1000 messages per day, of which about 75% is spam. Botnet hits on a very large proportion of the spam. So far I've identified about a dozen of our regular correspondents that run afoul of botnet. Most of them have the IP address in the reverse DNS problem. For fun, I tried a few tests of your b-iv rule mentioned above and found that it would not fix the false positives. I think the false positives are coming almost entirely from small businesses running an in-house exchange server. I also think that a lot of them use a filtering service like postini in front of their exchange machine, which effectively makes it appear that their incoming and outgoing servers are different. I haven't decided yet if I will go on a crusade to notify all the problem domains (they are my clients, so I can't afford to annoy them) or if I will whitelist all of them or if I will back off on botnet. Mark
RE: Breaking up the Bot army - we need a plan
From: news [mailto:[EMAIL PROTECTED] Behalf Of Mark Nienberg I think the false positives are coming almost entirely from small businesses running an in-house exchange server. I also think that a lot of them use a filtering service like postini in front of their exchange machine, which effectively makes it appear that their incoming and outgoing servers are different. I haven't decided yet if I will go on a crusade to notify all the problem domains (they are my clients, so I can't afford to annoy them) or if I will whitelist all of them or if I will back off on botnet. Ah, thanks! I fell less alone, now. giampaolo Mark
Re: Breaking up the Bot army - we need a plan
Once again, Perkel clutters the SpamAssassin list with a non-SpamAssassin discussion. One which, IIRC, he's just rehashing from a year or so ago (are we going to see a rehash of the the future of email storage is sql thread, too?). There are FAR more appropriate forums for these non-SA related things. Is anyone else getting tired of this? Forty eight messages on the SA list today that have nothing to do with SA. What's the point of having a topical mailing list if nobody cares that the discussion is off-topic? St- As spam keeps increasing in volume and complexity we will eventually lose the war on spam if we don't change the standards. I'd like to open a discussion about what needs to be done and how to go about doing that. So I'll start. Any changes to the standard needs to be evolutionary. If we add a new feature to the standard that is so compelling that people give up the old standard and it is phased out. First - I see bot nets as the biggest culprit. Not just as spammers but as sources for DDOS attacks. In the early days of email only the sharpest people had access to it. Now that consumers are using it they need some protection and we need protection from them. How do we isolate end users so that they can't get viruses as easily and spread them as easily? By default all consumers should be behind a NAT to protect them from the outside world. Like many of you. I'm someone who works from home and provides so service from home. So I would not want to be prohibited from running an email server from home. But if I had to got to a web panel that my ISP provided to open up ports that would be fine with me. All outgoing email from consumers should by default be required to use authenticated SMTP or some new authenticated protocol. At least force consumers to use the submission port and block off port 25 for outgoing SMTP by default. If consumers were forced by default to send mail on a different port then servers could determine if they were talking to a consumer or if they were talking to another server. And outgoing email would require a password to send, So the virus wouldn't know the password and the virus wouldn't be able to send email. You could also have the operating system register apps that are allowed to send email and block all apps that aren't specifically allowed. The idea here is that if you can reduce the mechanisms that allow viruses to spread then there comes a point where viruses go away. All we have to do is get the spreading down to that threshold. I believe that if we do it right that the bot army threat can be beaten. And if we got to that point the rest would be manageable. We can talk about other things but I'll stop here to focus on the bot army.
Re: Breaking up the Bot army - we need a plan
Am Montag, 11. Dezember 2006 23:41 schrieb Bret Miller: So perhaps SPF should consider removing +all as an option. Realisticly anyone that has to say my e-mail might come from anywhere is contributing to the problem and probably deserves to have e-mail bounced. sounds like a possible SA rule... with a high score... bye, MH -- gpg key fingerprint: 5F64 4C92 9B77 DE37 D184 C5F9 B013 44E7 27BD 763C
Re: Breaking up the Bot army - we need a plan
Am Dienstag, 12. Dezember 2006 05:09 schrieb Steve Thomas: Is anyone else getting tired of this? Forty eight messages on the SA list today that have nothing to do with SA. What's the point of having a topical mailing list if nobody cares that the discussion is off-topic? if you're so opposed to having that discussion here, why did you quote it all? and TOFU, too... http://learn.to/quote bye, MH
