Re: MTX plugin functionally complete? Re: Spam filtering similar to SPF, less breakage
On 02/15, Per Jessen wrote: > Hmm, there does seem to be some minor issue with the underscore in A > records, but I still think it would be the most appropriate way to go. Technically I agree. However, practically, I think it might be important to go without underscores purely due to implementation difficulties, mostly Bind's apparent default RFC violation. -- "every time I race I see god" - tsuwa, #motorcycles, EFNet, 7/19/06 http://www.ChaosReigns.com
Re: MTX plugin functionally complete? Re: Spam filtering similar to SPF, less breakage
dar...@chaosreigns.com wrote: > On 02/15, Per Jessen wrote: >> I checked my bind setup too, and I have the default for check-names - >> no >> complaints. It is however, perhaps, worth noting that my _sip and >> _domainkey names are for SRV records, not A records. > > Yup, no problems with SRV records - either with my secondary DNS > provider, or bind before I changed check-names to ignore. > Hmm, there does seem to be some minor issue with the underscore in A records, but I still think it would be the most appropriate way to go. /Per Jessen, Zürich
Re: MTX plugin functionally complete? Re: Spam filtering similar to SPF, less breakage
I'm about to post about MTX to the Anti-Spam Research Group's discussion mailing list: http://asrg.sp.am/about/lists.shtml This appears to be the best next step toward RFC. MTX HELO - need to comment on this On 02/15, Jonas Eckerman wrote: > * Or, make a MTX checker traverse domain from the one it checks towards > the registry boundary when checking for policy. This means more DNS > lookups but might be easier to administrate. (I have a vague > recollection that DKIM or ADSP works this way... Not sure though) Icky. > "policy" seems better than "participant" to me. Sounds good to me. It's shorter. On 02/14, Jonas Eckerman wrote: > If anyone connects from a host where reverse lookup or HELO puts it in > "frukt.org" domain, you know that your should reject or score high > unless it has FCDNS and a matching MTX record. How useful do you think it is to validate the HELO against MTX? I'm thinking I don't really care, and it adds extra complication. Sure, in the short term, it would catch some spam, but a spammer can set the HELO to anything they want, without consequence, and can just as easily set it to match the IP they're sending from. Also, SPF HELO covers it. -- "For gasoline vapor, the explosive range is from 1.3 to 6.0% vapor to air...useful against soft targets such as...armored vehicles...and bunkers." - http://www.fas.org/man/dod-101/sys/dumb/fae.htm http://www.ChaosReigns.com
Re: MTX plugin functionally complete? Re: Spam filtering similar to SPF, less breakage
On 02/15, Per Jessen wrote: > Change provider. There is absolutely nothing wrong with having an > underscore in DNS records. They're used for several things - _sip and > _domainkey for instance. Also see RFC2181. RFC 2181 section 11 does seem to agree. However, I still haven't found evidence of it ever being used in an A record. Also, I have SRV records with underscores that they accept just fine. And I'm not willing to change providers for this. If I need to change provider, it's too great a barrier to general adoption. On 02/15, Per Jessen wrote: > I checked my bind setup too, and I have the default for check-names - no > complaints. It is however, perhaps, worth noting that my _sip and > _domainkey names are for SRV records, not A records. Yup, no problems with SRV records - either with my secondary DNS provider, or bind before I changed check-names to ignore. On 02/15, Matus UHLAR - fantomas wrote: > In such case you should not compare MTX with SPF and or DKIM, instead > you should clearly state that MTX is designed to do something very > different than SPF and DKIM are trying to do. Good point. I did not ever intend to say that MTX is better than SPF or DKIM, just that MTX is better at what it is intended for which the others are not intended for. On 02/15, Justin Mason wrote: > I could vaguely recall it, then someone else reminded me of the exact > name. There have been a lot of MARID proposals in the past... "MTA Authorization Records in DNS." Good acronym for me to know, thanks. It was an IETF Working Group that was terminated in 2004: http://www.networkworld.com/news/2004/092704ietfspam.html -- "I'd rather be happy than right any day." - Slartiblartfast, The Hitchhiker's Guide to the Galaxy http://www.ChaosReigns.com
Re: HELO SPF + FCDNS (was: MTX plugin functionally complete? Re: Spam filtering similar to SPF, less breakage)
> On 2010-02-14 19:20, dar...@chaosreigns.com wrote: >> Possibly a lack of separate SPF records for HELO and MAIL FROM if >> they are the same. On 15.02.10 13:58, Jonas Eckerman wrote: > Agreed. I think they should have separated those records. I don't see any reason. Why should we allow someone to use given name in HELO if we won't allow them to send mail with this name in mail from (and vice versa)? > But then I also think they should have created an _spf subdomain from the > start instead of using the TXT record for the domain without any special > qualifier... -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. 2B|!2B, that's a question!
Re: MTX plugin functionally complete? Re: Spam filtering similar to SPF, less breakage
On 2010-02-14 19:20, dar...@chaosreigns.com wrote: On 02/14, Jonas Eckerman wrote: * I think there should be a way to tell the world wether you are using the scheme for a domain (not host) or not. This could easily be done in DNS. I need to think about this more, thanks for the suggestion. (More on registrar boundaries below.) * I think you should follow conventions in DNS naming, using an underscore to signify that the DNS record is a "special" type of record. This is quite common. That's probably a good idea, hmm. You could use SpamAssassins registrar boundaries stuff for getting the domain in a SA plugin, and score higher for missing MTX host record if there is an MTX domain record. How good is SA's registrar boundaries stuff? Not sure, but it's used in various places if you use SA, so if it isn't good that will have effects on SA anyway. I don't think "Use SpamAssassin's registrar boundaries" would be good in an RFC. I only meant that SA's Mail::SpamAssassin::Util::RegistrarBoundaries could be used for this in an SA plugin. In the RFC I'd suggest it be specified that domain policy's should be checked based on domain registry boundaries (but with better wording than mine). I don't even know where the record should be for wildlife.state.nh.us. www.state.nh.us exists, which would indicate mtx.state.nh.us. Mail::SpamAssassin::Util::RegistrarBoundaries::trim_domain returns "wildlife.state.nh.us" for "wildlife.state.nh.us" (and for "whatever."wildlife.state.nh.us"), suggesting that a policy record should be "policy._mtx.wildlife.state.nh.us" or similar. Wether that makes sense or not, I don't know. It does trim for example "mail.microsoft.us" to "microsoft.us", so I guess there's a special reason for it to trim the "state.nh.us" subdomains to more than two levels. Even if SA's registrar boundaries pointed to mtx.wildlife.state.nh.us, you'd still need to be able to delegate to another subdomain. Yes, you'd need that. As I see it, there are two simple ways to do this. * Make it possible to indicate plicy delegation in the policy record. I see you thought about this one allready. :-) * Or, make a MTX checker traverse domain from the one it checks towards the registry boundary when checking for policy. This means more DNS lookups but might be easier to administrate. (I have a vague recollection that DKIM or ADSP works this way... Not sure though) Or maybe participant._mtx.frukt.org. Giving an A record to the _mtx subdomain itself seems potentially problematic, Agreed. And seeing as a hostname should not contain underscore, that wasn't a very good idea of mine. Any suggestions other than "participant"? "policy" seems better than "participant" to me. Regards /Jonas -- Jonas Eckerman Fruktträdet & Förbundet Sveriges Dövblinda http://www.fsdb.org/ http://www.frukt.org/ http://whatever.frukt.org/
Re: MTX plugin functionally complete? Re: Spam filtering similar to SPF, less breakage
Matus UHLAR - fantomas wrote: >> > On 02/14, dar...@chaosreigns.com wrote: >> >> Now should I use _mtx, or MTAMark style _smtp._srv? > >> dar...@chaosreigns.com wrote: >> > DNS records containing underscores are apparently a pain. In my >> > Bind >> > config I had to add "check-names ignore;". My secondary DNS >> > provider is responding with "REFUSED" (I asked them to fix it). > > On 15.02.10 10:19, Per Jessen wrote: >> Change provider. There is absolutely nothing wrong with having an >> underscore in DNS records. They're used for several things - _sip >> and >> _domainkey for instance. Also see RFC2181. > > note that BIND does support such names for some time, without > problems. I have "check-namees reject" but my BIND accepts such names. I checked my bind setup too, and I have the default for check-names - no complaints. It is however, perhaps, worth noting that my _sip and _domainkey names are for SRV records, not A records. /Per Jessen, Zürich
HELO SPF + FCDNS (was: MTX plugin functionally complete? Re: Spam filtering similar to SPF, less breakage)
On 2010-02-14 19:20, dar...@chaosreigns.com wrote: On 02/14, Jonas Eckerman wrote: The SPF record above says that a host using "panic.chaosreigns.com" in HELO should not be allowed to send mail unless it has the IP address 64.71.152.40, regardless of the domain in the envelope from, From: header, etc.. You're right, I missed that, thank you. The complication, of course, is where a spammer owns the (forgable) HELO domain but not the IP (PTR). Full circle DNS handles that. Has the combination been implemented? I've no idea wether any software actually checks the combination of HELO SPF and FCDNS. It does seem a logical thing to do in software like SpamAssassin or MIMEDefang. Maybe I should implement it in my MIMEDefang filter just to log the results and see if it'd be a good idea to reject on it... Possibly a lack of separate SPF records for HELO and MAIL FROM if they are the same. Agreed. I think they should have separated those records. But then I also think they should have created an _spf subdomain from the start instead of using the TXT record for the domain without any special qualifier... Regards /Jonas -- Jonas Eckerman Fruktträdet & Förbundet Sveriges Dövblinda http://www.fsdb.org/ http://www.frukt.org/ http://whatever.frukt.org/
Re: MTX plugin functionally complete? Re: Spam filtering similar to SPF, less breakage
> > On 02/14, dar...@chaosreigns.com wrote: > >> Now should I use _mtx, or MTAMark style _smtp._srv? > dar...@chaosreigns.com wrote: > > DNS records containing underscores are apparently a pain. In my Bind > > config I had to add "check-names ignore;". My secondary DNS provider > > is responding with "REFUSED" (I asked them to fix it). On 15.02.10 10:19, Per Jessen wrote: > Change provider. There is absolutely nothing wrong with having an > underscore in DNS records. They're used for several things - _sip and > _domainkey for instance. Also see RFC2181. note that BIND does support such names for some time, without problems. I have "check-namees reject" but my BIND accepts such names. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. "The box said 'Requires Windows 95 or better', so I bought a Macintosh".
Re: MTX plugin created (Re: Spam filtering similar to SPF, less breakage)
On Sat, Feb 13, 2010 at 11:01, Per Jessen wrote: > Justin Mason wrote: > >> On Thu, Feb 11, 2010 at 03:00, wrote: >>> http://www.chaosreigns.com/mtx/ >> >> >> It might be useful to compare with MTA MARK and see what the status of >> that proposal currently is: >> >> http://tools.ietf.org/draft/draft-stumpf-dns-mtamark/ >>http://tools.ietf.org/draft/draft-stumpf-dns-mtamark/draft-stumpf-dns-mtamark-04.txt > > Amazing. Justin, you must have known about that one - you can't > possibly have just googled it? I could vaguely recall it, then someone else reminded me of the exact name. There have been a lot of MARID proposals in the past... --j. -- --j.
Re: MTX plugin functionally complete? Re: Spam filtering similar to SPF, less breakage
> On 02/13, Matus UHLAR - fantomas wrote: > > So the only effect of MTX should be confirmation that a machine may send > > mail? On 13.02.10 14:40, dar...@chaosreigns.com wrote: > Yes. In such case you should not compare MTX with SPF and or DKIM, instead you should clearly state that MTX is designed to do something very different than SPF and DKIM are trying to do. They both were designed to prevent address forging, which is different and often worse problem than spam itself. You can compare MTX to mtamark and CSA but just please don't say it's better than SPF/DKIM. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Micro$oft random number generator: 0, 0, 0, 4.33e+67, 0, 0, 0...
Re: MTX plugin functionally complete? Re: Spam filtering similar to SPF, less breakage
dar...@chaosreigns.com wrote: > On 02/14, dar...@chaosreigns.com wrote: >> Now should I use _mtx, or MTAMark style _smtp._srv? > > DNS records containing underscores are apparently a pain. In my Bind > config I had to add "check-names ignore;". My secondary DNS provider > is responding with "REFUSED" (I asked them to fix it). Change provider. There is absolutely nothing wrong with having an underscore in DNS records. They're used for several things - _sip and _domainkey for instance. Also see RFC2181. /Per Jessen, Zürich
Re: MTX plugin functionally complete? Re: Spam filtering similar to SPF, less breakage
On 02/14, dar...@chaosreigns.com wrote: > Now should I use _mtx, or MTAMark style _smtp._srv? DNS records containing underscores are apparently a pain. In my Bind config I had to add "check-names ignore;". My secondary DNS provider is responding with "REFUSED" (I asked them to fix it). Is it worth the hassle to have the underscore? -- "Every man, woman and child on the face of this earth is at the mercy of chaos." - a maxwell smart movie http://www.ChaosReigns.com
Re: MTX plugin functionally complete? Re: Spam filtering similar to SPF, less breakage
On 02/14, Jonas Eckerman wrote: > * I think you should follow conventions in DNS naming, using an > underscore to signify that the DNS record is a "special" type of record. > This is quite common. I didn't like this idea, but I have realized it's the right thing to do. Now should I use _mtx, or MTAMark style _smtp._srv? 40.152.71.64._mtx.panic.chaosreigns.com 40.152.71.64._smtp._srv.panic.chaosreigns.com _mtx is sexier - shorter. _smtp._srv is potentially useful for more things, but I can't think of anything. Maybe google wave. 6 characters longer. And I like that "mtx" explicitly indicates "transmitting", although not an extremely important distinction. Other protocols can create their own subdomain. On 02/14, dar...@chaosreigns.com wrote: > Yeah. I'm thinking of using the 4th octet to indicate participation, and > the third octet to indicate delegation. I screwed that up. Not participating is functionally identical to "neutral". 4th octet: 0 Neutral: Should not be penalized anymore than non-participating domains. 1 SoftFail: Subject to further scrutiny (greylisting, SA +1). 2 HardFail: Reject. The existing two scores: Pass: Obvious. Fail: Includes all of the other results: Neutral, SoftFail, and HardFail. 3rd octet indicates delegation of 4th octet value to subdomains: 0 Applies to this domain and all subdomains. 1 Applies to this domain, ask subdomains if they're participating. Also, I'm now less worried about domain boundaries. Worst case, you could check for the _mtx subdomain at the 3rd and 4th level (_mtx.chaosreigns.com, _mtx.state.nh.us, respectively). Are there any cases where you need to check the 5th? And you could use a list of known domains to skip some guessing. So: _participant._mtx.chaosreigns.com. IN A 127.0.0.2 Means HardFail anything from chaosreigns.com and any subdomain that doesn't have an MTX record. -- "The whole aim of practical politics is to keep the populace alarmed -- and hence clamorous to be led to safety -- by menacing it with an endless series of hobgoblins, all of them imaginary." - H. L. Mencken http://www.ChaosReigns.com
Re: MTX plugin functionally complete? Re: Spam filtering similar to SPF, less breakage
On 02/14, Jonas Eckerman wrote: > The SPF record above says that a host using "panic.chaosreigns.com" in > HELO should not be allowed to send mail unless it has the IP address > 64.71.152.40, regardless of the domain in the envelope from, From: > header, etc.. > > That's not exactly the same as your MTX scheme, but it has similar > results when combined with a FCDNS check on HELO (providing your scheme > is universally adopted). You're right, I missed that, thank you. The complication, of course, is where a spammer owns the (forgable) HELO domain but not the IP (PTR). Full circle DNS handles that. Has the combination been implemented? SPF HELO + FCDNS's disadvantages compared to MTX are minor: 1) Complication. 2) 3 DNS lookups (HELO, PTR, SPF, possibly more if the SPF record isn't all IPs) instead of 2 (PTR, A). 3) Association with SPF (MAIL FROM), which people are emotional about. Possibly a lack of separate SPF records for HELO and MAIL FROM if they are the same. > If you're serious about your proposal, you should explain (in your > documentation) in what important way it differs from SPF as used against > HELO and other similar schemes, and why it is better. I had not seen the need to specifically address SPF HELO until now, I'll do that. Have I missed other similar schemes? http://www.chaosreigns.com/mtx/#comparisons On 02/14, Jonas Eckerman wrote: > * I think there should be a way to tell the world wether you are using > the scheme for a domain (not host) or not. This could easily be done in > DNS. I need to think about this more, thanks for the suggestion. (More on registrar boundaries below.) > * I think you should follow conventions in DNS naming, using an > underscore to signify that the DNS record is a "special" type of record. > This is quite common. That's probably a good idea, hmm. > You could use SpamAssassins registrar boundaries stuff for getting the > domain in a SA plugin, and score higher for missing MTX host record if > there is an MTX domain record. How good is SA's registrar boundaries stuff? Sounds messy. I don't think "Use SpamAssassin's registrar boundaries" would be good in an RFC. I don't even know where the record should be for wildlife.state.nh.us. www.state.nh.us exists, which would indicate mtx.state.nh.us. But it would probably be significantly more useful at mtx.wildlife.state.nh.us. Icky. You could give mtx.state.nh.us a value that indicates that you should check the subdomain (mtx.wildlife.state.nh.us). Even if SA's registrar boundaries pointed to mtx.wildlife.state.nh.us, you'd still need to be able to delegate to another subdomain. Not giving me warm fuzzies. > To say that "marmaduke.frukt.org" [195.67.112.219] is allowed to send mail: > 219.112.67.195._mtx.marmaduke.frukt.org. IN A 127.0.0.1 > > To say that we're using your scheme for all hosts under "frukt.org": > _mtx.frukt.org. IN A 127.0.0.1 Yup. Or maybe participant._mtx.frukt.org. Giving an A record to the _mtx subdomain itself seems potentially problematic, although I'm not coming up with a specific reason at the moment. Any suggestions other than "participant"? That would probably be the most arbitrary part of the spec. > If anyone connects from a host where reverse lookup or HELO puts it in > "frukt.org" domain, you know that your should reject or score high unless > it has FCDNS and a matching MTX record. Yup. > (And of course, if this catches on, you'll have to provide RFC style > documentation.) Yup. On 02/14, Jonas Eckerman wrote: > On 2010-02-13 21:48, dar...@chaosreigns.com wrote: >>On 02/13, mouss wrote: >> >>> http://mipassoc.org/csv/draft-ietf-marid-csv-csa-02.txt >> Looks like it ties the helo domain to the delivering IP, breaking (broken) >> forwarding just like SPF? > > Tying the HELO domain to an IP has does not break forwarding. The host > name (including domain) used in HELO is independent from the domain used > in MAIL FROM. Yup, sorry. It looks like Client SMTP Authorization doesn't require ownership of the IP. So a spammer could send spam from any IP on the internet, as long as they use a HELO matching a domain they own and have created the CSA records for. > (It's not that use of SPF that breaks (borken) forwarding, it's the > limits connected to the domain used in MAIL FROM.) Right. -- "Forget not that the earth delights to feel your bare feet and the winds long to play with your hair." - Kahlil Gibran http://www.ChaosReigns.com
Re: MTX plugin functionally complete? Re: Spam filtering similar to SPF, less breakage
- "Per Jessen" wrote: > Jonas Eckerman wrote: > > > (And of course, if this catches on, you'll have to provide RFC > style > > documentation.) > > > > See Justins posting from two days back: > > http://tools.ietf.org/draft/draft-stumpf-dns-mtamark/ > http://tools.ietf.org/draft/draft-stumpf-dns-mtamark/draft-stumpf-dns-mtamark-04.txt > > That proposal does not appear to have caught a lot of interest in > 2004/2005, but perhaps it might now. > > > /Per Jessen, Zürich Personally I think it is a great idea and anything to help combat the spam is always a worthwhile effort. Is it possible to resurrect that proposal and worth with the original authors and perhaps combine the efforts ? Anybody who takes time to come up with ideas like this deserves the support of the community. I am all for helping, where I can, to take this forward. -- Thanks, Phil
Re: MTX plugin functionally complete? Re: Spam filtering similar to SPF, less breakage
Jonas Eckerman wrote: > (And of course, if this catches on, you'll have to provide RFC style > documentation.) > See Justins posting from two days back: http://tools.ietf.org/draft/draft-stumpf-dns-mtamark/ http://tools.ietf.org/draft/draft-stumpf-dns-mtamark/draft-stumpf-dns-mtamark-04.txt That proposal does not appear to have caught a lot of interest in 2004/2005, but perhaps it might now. /Per Jessen, Zürich
Re: MTX plugin functionally complete? Re: Spam filtering similar to SPF, less breakage
On 2010-02-13 21:48, dar...@chaosreigns.com wrote: Looks like it ties the helo domain to the delivering IP, breaking (broken) forwarding just like SPF? Tying the HELO domain to an IP has does not break forwarding. The host name (including domain) used in HELO is independent from the domain used in MAIL FROM. (It's not that use of SPF that breaks (borken) forwarding, it's the limits connected to the domain used in MAIL FROM.) Regards /Jonas -- Jonas Eckerman Fruktträdet & Förbundet Sveriges Dövblinda http://www.fsdb.org/ http://www.frukt.org/ http://whatever.frukt.org/
Re: MTX plugin functionally complete? Re: Spam filtering similar to SPF, less breakage
On 2010-02-13 04:24, dar...@chaosreigns.com wrote: Still http://www.chaosreigns.com/mtx/ I still have the following comments (wich you didn't answer previously): * I think there should be a way to tell the world wether you are using the scheme for a domain (not host) or not. This could easily be done in DNS. * I think you should follow conventions in DNS naming, using an underscore to signify that the DNS record is a "special" type of record. This is quite common. You could use SpamAssassins registrar boundaries stuff for getting the domain in a SA plugin, and score higher for missing MTX host record if there is an MTX domain record. An example (of the top of my head) could be: To say that "marmaduke.frukt.org" [195.67.112.219] is allowed to send mail: 219.112.67.195._mtx.marmaduke.frukt.org. IN A 127.0.0.1 To say that we're using your scheme for all hosts under "frukt.org": _mtx.frukt.org. IN A 127.0.0.1 If anyone connects from a host where reverse lookup or HELO puts it in "frukt.org" domain, you know that your should reject or score high unless it has FCDNS and a matching MTX record. (And of course, if this catches on, you'll have to provide RFC style documentation.) Regards /Jonas -- Jonas Eckerman Fruktträdet & Förbundet Sveriges Dövblinda http://www.fsdb.org/ http://www.frukt.org/ http://whatever.frukt.org/
Re: MTX plugin functionally complete? Re: Spam filtering similar to SPF, less breakage
On 2010-02-13 04:24, dar...@chaosreigns.com wrote: panic.chaosreigns.com. IN SPF "v=spf1 a:64.71.152.40 -all" No. MTX defines 64.71.152.40 as a legitimate transmitting mail server, regardless of the domain in the envelope from, From: header, etc.. Popular misconception, it seems. The SPF record above says that a host using "panic.chaosreigns.com" in HELO should not be allowed to send mail unless it has the IP address 64.71.152.40, regardless of the domain in the envelope from, From: header, etc.. That's not exactly the same as your MTX scheme, but it has similar results when combined with a FCDNS check on HELO (providing your scheme is universally adopted). If you're serious about your proposal, you should explain (in your documentation) in what important way it differs from SPF as used against HELO and other similar schemes, and why it is better. Regards /Jonas -- Jonas Eckerman Fruktträdet & Förbundet Sveriges Dövblinda http://www.fsdb.org/ http://www.frukt.org/ http://whatever.frukt.org/
Re: MTX plugin functionally complete? Re: Spam filtering similar to SPF, less breakage
On 02/13, mouss wrote: > dar...@chaosreigns.com a écrit : > did you take a look at CSA > > http://mipassoc.org/csv/draft-ietf-marid-csv-csa-02.txt I had not, thanks. Looks like it ties the helo domain to the delivering IP, breaking (broken) forwarding just like SPF? > Anyway, such approaches are only helpful if widely adopted. otherwise, > the overhead is not worth the pain. I disagree. But I think you have probably already read my reasons. > At this time, just register your IP in DNSWL. I have provided a server since 2007, and been an admin longer. And wrote some stuff. I have assigned a minor penalty to emails not matching DNSWL for years. A significant part of my motivation for creating MTX is the difficulty of maintaining that list. MTX is very much inspired by DNSWL - it's the same, except the domain that hosts the records (and omitting the host "category" in the third octet). SPF and DNSWL were the two things in my head at the time that MTX occurred to me. The bottom of my MTX page credits them. http://www.chaosreigns.com/mtx/background/ goes into detail. -- "I'd rather be happy than right any day." - Slartiblartfast, The Hitchhiker's Guide to the Galaxy http://www.ChaosReigns.com
Re: MTX plugin functionally complete? Re: Spam filtering similar to SPF, less breakage
dar...@chaosreigns.com a écrit : > On 02/13, Matus UHLAR - fantomas wrote: >> So the only effect of MTX should be confirmation that a machine may send >> mail? > > Yes. > >> So why the complicated check for DNS record combining DNS name and IP? >> Why not simply requesting that machine has a "mail" or "smtp" in its DNS >> name? > > I answered that recently. > > (I need to state that such a method would require a full circle DNS check. > Not a problem) > > 1) I am not comfortable requiring people to modify existing host names to >participate. > fully agreed. an IP is not necessarily dedicated to mail, so there is no reason to force people to put "mail" in it. and snow shoe spammers already use names "that people want"... > 2) Probably more importantly, I am concerned about the possibility of >spammers tricking DNS maintainers into giving them such host names. > > These two problems are handled by > http://tools.ietf.org/draft/draft-stumpf-dns-mtamark/draft-stumpf-dns-mtamark-04.txt > which was recently mentioned by Justin Mason. > > > The advantage MTX has over mtamark, which I believe is important, is that > MTX ties the spam to a domain name, which is tied to a registrar, which can > be subpoenaed for the identity of the spammer. mtamark leaves the spam > still only tied to the transmitting IP, which I believe is less convenient > to track. Especially given IP hijacking via BGP. Nasty. > did you take a look at CSA http://mipassoc.org/csv/draft-ietf-marid-csv-csa-02.txt it uses an SRV record instead of the "so-much-abused reverse dns hack". Anyway, such approaches are only helpful if widely adopted. otherwise, the overhead is not worth the pain. At this time, just register your IP in DNSWL.
Re: MTX plugin functionally complete? Re: Spam filtering similar to SPF, less breakage
On 02/13, Matus UHLAR - fantomas wrote: > So the only effect of MTX should be confirmation that a machine may send > mail? Yes. > So why the complicated check for DNS record combining DNS name and IP? > Why not simply requesting that machine has a "mail" or "smtp" in its DNS > name? I answered that recently. (I need to state that such a method would require a full circle DNS check. Not a problem) 1) I am not comfortable requiring people to modify existing host names to participate. 2) Probably more importantly, I am concerned about the possibility of spammers tricking DNS maintainers into giving them such host names. These two problems are handled by http://tools.ietf.org/draft/draft-stumpf-dns-mtamark/draft-stumpf-dns-mtamark-04.txt which was recently mentioned by Justin Mason. The advantage MTX has over mtamark, which I believe is important, is that MTX ties the spam to a domain name, which is tied to a registrar, which can be subpoenaed for the identity of the spammer. mtamark leaves the spam still only tied to the transmitting IP, which I believe is less convenient to track. Especially given IP hijacking via BGP. Nasty. -- "Of course there's strength in numbers. But there's strength in sharp weaponry too. Ironically, this lead to what we call 'civilization'." - spore http://www.ChaosReigns.com
Re: MTX plugin functionally complete? Re: Spam filtering similar to SPF, less breakage
> On 02/11, Matus UHLAR - fantomas wrote: > > So you define the IP 64.71.152.40 as OK when sending mail from > > @panic.chaosreigns.com. address. > > > > so it's the exactly same as > > > > panic.chaosreigns.com. IN SPF "v=spf1 a:64.71.152.40 -all" On 12.02.10 22:24, dar...@chaosreigns.com wrote: > No. MTX defines 64.71.152.40 as a legitimate transmitting mail server, > regardless of the domain in the envelope from, From: header, etc.. > Popular misconception, it seems. So the only effect of MTX should be confirmation that a machine may send mail? So why the complicated check for DNS record combining DNS name and IP? Why not simply requesting that machine has a "mail" or "smtp" in its DNS name? -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. I'm not interested in your website anymore. If you need cookies, bake them yourself.
Re: MTX plugin created (Re: Spam filtering similar to SPF, less breakage)
On Sat, 13 Feb 2010, Per Jessen wrote: Justin Mason wrote: It might be useful to compare with MTA MARK and see what the status of that proposal currently is: http://tools.ietf.org/draft/draft-stumpf-dns-mtamark/ Amazing. Justin, you must have known about that one - you can't possibly have just googled it? Well, I certainly had never heard of this one. And I think that with one minor variation in concept it could be useful to scoring systems like SA... Because of the threat of hacks, any system that 'favors' an MTA is simply giving spammers a target for exploitation. But an explicit 'disallow' record (MTA="0") created by the sysadmin would have a similar impact to deliberately naming PTR records as 'dynamic'. SA could 'detect' the explicit MTA="0" and add a score (or block outright at MTA level) The only thing I would *not* do, given the general laziness of the internet, is apply any default meaning to the absence of this TXT record. Only explicit identification of an IP or subnet as 'not permitted to send mail' would have significance to SA or a blocking MTA. H. Could work. No impact for non-implementation. Disables an unauthorized IP for any case where it is used. I like it... - C
Re: MTX plugin created (Re: Spam filtering similar to SPF, less breakage)
Justin Mason wrote: > On Thu, Feb 11, 2010 at 03:00, wrote: >> http://www.chaosreigns.com/mtx/ > > > It might be useful to compare with MTA MARK and see what the status of > that proposal currently is: > > http://tools.ietf.org/draft/draft-stumpf-dns-mtamark/ >http://tools.ietf.org/draft/draft-stumpf-dns-mtamark/draft-stumpf-dns-mtamark-04.txt Amazing. Justin, you must have known about that one - you can't possibly have just googled it? /Per Jessen, Zürich
MTX plugin functionally complete? Re: Spam filtering similar to SPF, less breakage
* Implemented blacklisting. * Clarified current recommendations and added content to the page. * Removed redirect for Microsoft Internet Explorer users and converted the page to HTML 4.01 Strict. Still http://www.chaosreigns.com/mtx/ I think the only thing left to do is to switch from send() to bgsend() for speed. Hopefully this weekend. I would obviously appreciate testing. How much has SpamAssassin broken backward compatibility for plugins since version 3.2.5? On 02/11, Matus UHLAR - fantomas wrote: > Imho, SPF does NOT break forwarding. It only causes the broken forwarding to > be rejected. If I forward your mail to other address from my No argument here. I encourage you to fix it. > So you define the IP 64.71.152.40 as OK when sending mail from > @panic.chaosreigns.com. address. > > so it's the exactly same as > > panic.chaosreigns.com. IN SPF "v=spf1 a:64.71.152.40 -all" No. MTX defines 64.71.152.40 as a legitimate transmitting mail server, regardless of the domain in the envelope from, From: header, etc.. Popular misconception, it seems. > > I'll define it slightly differently: > > 127.0.0.1 is a pass (negative SA score). > > not found is a fail (positive SA score). > > what means "not found"? $ host -t a fish.chaosreigns.com Host fish.chaosreigns.com not found: 3(NXDOMAIN) ^ Undefined. > "66.3.168.195.mtx.panic.chaosreigns.com not found" would mean I'm not > allowed to mail from "panic.chaosreigns.com" address? It would mean mail from that IP should get penalized. > Or will my server be allowed to mail from your domain? Because SPF above Yes. > defines this mail to be rejected and nonexistance of the mtx record would do > the same, even it it's your forwarded e-mail. No, as I clarified earlier. > So, since you don't believe SPF to be widely adopted, you expect your way to > be adopted? And all admins must adopt that? Even if they did not adopt > SPF/DKIM for a few years they exist? No, I would say SPF has been pretty widely adopted. But I believe SPF has not been *more* widely adopted due to the forwarding problem. So I created an alternative to eliminate that problem. So yes, I think it might get more widely adopted. Of course I can't expect anything. DKIM also has problems which MTX doesn't have. I mentioned the ones I'm aware of in the recently added Comparisons section of the MTX page. (Replay, content modification, CPU overhead, complexity.) > the correct question is "hwo is this better?". Creating not better system is > useless. Have I answered this sufficiently? > > .mtx. > > > > (And the IP needs to be reversed as in all other A records that list IPs.) > > that's what I call complicated. SPF designs the same by using much easier > way, using existing A/MX/PTR records, CIDR ranges, including other SPF > records... I find it bizarre that you can think MTX is more complicated than SPF. On 02/12, Matus UHLAR - fantomas wrote: > On 11.02.10 16:34, dar...@chaosreigns.com wrote: > > I am not suggesting that anyone block anything based on MTX at this time. > > you have been doing that, afaics. Communication failure on my part, I apologize. I hope I have made the web page clearer. My hope is that long term, all mail will be blocked when there is no MTX record. That would obviously be foolish in the short term. I *am* currently causing a very small number of false positives by increasing SpamAssassin score by 2 for any email without an MTX record. As you can imagine, this blocks more spam. Also, the senders of those false positives get notified without sending backscatter. This configuration is currently listed under "Aggressive Testing" on my site. > Read my last mail in this thread where I've asked you how exactly you > imagine the MTX not to "break" forwarding. I'm sorry I missed it earlier. I stopped looking for subjects with "SPF" after I posted one with "MTX". I thought that thread died. Thank you for mentioning it. -- "For every battle there is a price to pay. Now pick up your teeth and go home." - no fear http://www.ChaosReigns.com
Re: MTX plugin created (Re: Spam filtering similar to SPF, less breakage)
On Thu, Feb 11, 2010 at 03:00, wrote: > http://www.chaosreigns.com/mtx/ It might be useful to compare with MTA MARK and see what the status of that proposal currently is: http://tools.ietf.org/draft/draft-stumpf-dns-mtamark/ http://tools.ietf.org/draft/draft-stumpf-dns-mtamark/draft-stumpf-dns-mtamark-04.txt -- --j.
Re: MTX plugin created (Re: Spam filtering similar to SPF, less breakage)
> On 02/11, Henrik K wrote: > > method of whitelisting. You can't seriously expect to block on some > > attribute that not everyone can or bothers to change (DNS). None of this On 11.02.10 16:34, dar...@chaosreigns.com wrote: > I am not suggesting that anyone block anything based on MTX at this time. you have been doing that, afaics. > I suggest using it for whitelisting (small negative score, not absolute > whitelisting) alone until it is more broadly in use. You suggested rejecting everything that fails MTX check (everything that does not have the D.C.B.A.mtx. record). > Except for those who are willing to cause a small number of false > positives, like me. Most of them have implemented SPF checking long ago. > It's funny how, for just believing I may have come up with an idea that is > new and useful for dealing with spam, I am consistently attacked. Because > people often believe that, and they're almost always wrong. I can't > blame you, purely statistically speaking, I'm probably wrong. And I > assure you that fact has not slipped my mind. We are not attacking you, but your proposal. You are telling nice things about it but you have not explained how they would be impemented. Read my last mail in this thread where I've asked you how exactly you imagine the MTX not to "break" forwarding. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Fucking windows! Bring Bill Gates! (Southpark the movie)
Re: MTX plugin created (Re: Spam filtering similar to SPF, less breakage)
Bowie Bailey wrote: LuKreme wrote: On 11-Feb-2010, at 11:11, Charles Gregory wrote: It's a rant page telling the visitor that you cannot read the site using Internet Explorer, Good. Get a real browser. with major (large font) attitude that this is the fault of the browser. It is, and this is explained clearly. IE does not support (I believe has never supported and still does not support) Content-Type: application/xhtml+xml, and does not, has not, and will probably never suport SVG images (though there were no images on the original page). Who would you like to blame for this if not Microsoft IE? I would blame whoever set up the website. The page in question does not even attempt to use the features that the "fail" page refers to. IE may not be able to handle "xhtml+xml" or SVG images, but as long as it can render the page in question, who cares? That redirect should be limited to pages that actually use the features in question. The redirect states "...9 year old standard required by the web page..." so you obviously are blind, because the website developer couldn't possibly be lying. ;-) I would refer the redirect author to the section "The Myth of "HTML-compatible XHTML 1.0 documents" in the following document http://hixie.ch/advocacy/xhtml for an adult's understanding of why IE does not support it. The solution is HTML5 support in IE, and once the HTML5 people are finished wrangling amongst themselves, IE will support it. That is why Microsoft joined the SVG working group of w3c last month - because now with Adobe pulling their support of their SVG IE plugin last year, it looks like we finally might have some movement in that B.M. called HTML5. The fact is the 4.01 standard is over a decade old. If the HTML5 people had agreed on a set of standards 5 years ago then we would have support for SVG and XHTML it in IE today. The second fact is that if MS HAD supported SVG and XHTML then the W3C would have come under tremendous pressure to force out that HTML5 standard. I don't think they would have liked that any better. Ted
Re: MTX plugin created (Re: Spam filtering similar to SPF, less breakage)
On Thu, 11 Feb 2010, Bowie Bailey wrote: I would blame whoever set up the website. The page in question does not even attempt to use the features that the "fail" page refers to. (nod) I guess that really says it all Thanks for mentioning this. Now my 'vague feeling' is confirmed. - C
Re: MTX plugin created (Re: Spam filtering similar to SPF, less breakage)
On 02/11, Henrik K wrote: > method of whitelisting. You can't seriously expect to block on some > attribute that not everyone can or bothers to change (DNS). None of this Correct. I am not suggesting that anyone block anything based on MTX at this time. I suggest using it for whitelisting (small negative score, not absolute whitelisting) alone until it is more broadly in use. This is clearly stated in the Implementation Sequence: Conservative people use these new tests to reduce false positives: score MTX_BL 1 score MTX_PASS -1 # Only hit if MTX_BL wasn't. score MTX_FAIL 0.001 Except for those who are willing to cause a small number of false positives, like me. I can, and do, score more harshly those emails that do not have MTX records. And the senders get an error mentioning the option of MTX. All the emails that have been hit seemed likely to be spam. For example, this list gets through just fine with these settings: score MTX_PASS -100 score MTX_FAIL 2 As to the problem of freemail, sites that send both non-spam and spam, constantly, I think that necessitates a blacklist that allows you to define a score per domain (of the PTR record of the sending IP). So, for example, you could blacklist hotmail to only negate the benefit of them having an MTX record, so for hotmail, the net result would be 0. It's funny how, for just believing I may have come up with an idea that is new and useful for dealing with spam, I am consistently attacked. Because people often believe that, and they're almost always wrong. I can't blame you, purely statistically speaking, I'm probably wrong. And I assure you that fact has not slipped my mind. -- "Let's just say that if complete and utter chaos was lightning, then he'd be the sort to stand on a hilltop in a thunderstorm wearing wet copper armour and shouting 'All gods are bastards'." - The Color of Magic http://www.ChaosReigns.com
Re: [sa] Re: MTX plugin created (Re: Spam filtering similar to SPF, less breakage)
On Thu, 11 Feb 2010, LuKreme wrote: It's a rant page telling the visitor that you cannot read the site using Internet Explorer, Good. Get a real browser. Like I said, he (and you) can rant all you want about the evils of Microsoft, and frankly I wouldn't be inclined to argue with you. (grin) But the moment someone posts a link that purports to lead to *content* and replaces that content with (essentially) a political *rant*, and does so only on the basis of that same policitcal BS, then they are no better than the spammer who uses his latest clever trick to get political spam into my mailbox. Quiet ironic for a discussion on an anti-spam list. :) - C
Re: MTX plugin created (Re: Spam filtering similar to SPF, less breakage)
On Thu, 11 Feb 2010, LuKreme wrote: Erm.. The string "microsoft" doesn't even exist on that page. "No Microsoft browser supports this 9 year old standard." Obviously you are't using IE and so you weren't subjected to the arrogant refusal of his server to deliver the requested page. (shrug) - C
Re: MTX plugin created (Re: Spam filtering similar to SPF, less breakage)
LuKreme wrote: > On 11-Feb-2010, at 11:11, Charles Gregory wrote: > >> It's a rant page telling the visitor that you cannot read the site using >> Internet Explorer, >> > > Good. Get a real browser. > > >> with major (large font) attitude that this is the fault of the browser. >> > > It is, and this is explained clearly. IE does not support (I believe has > never supported and still does not support) Content-Type: > application/xhtml+xml, and does not, has not, and will probably never suport > SVG images (though there were no images on the original page). > > Who would you like to blame for this if not Microsoft IE? > I would blame whoever set up the website. The page in question does not even attempt to use the features that the "fail" page refers to. IE may not be able to handle "xhtml+xml" or SVG images, but as long as it can render the page in question, who cares? That redirect should be limited to pages that actually use the features in question. -- Bowie
Re: MTX plugin created (Re: Spam filtering similar to SPF, less breakage)
On 11-Feb-2010, at 11:11, Charles Gregory wrote: > > It's a rant page telling the visitor that you cannot read the site using > Internet Explorer, Good. Get a real browser. > with major (large font) attitude that this is the fault of the browser. It is, and this is explained clearly. IE does not support (I believe has never supported and still does not support) Content-Type: application/xhtml+xml, and does not, has not, and will probably never suport SVG images (though there were no images on the original page). Who would you like to blame for this if not Microsoft IE? -- I WILL NOT FAKE MY WAY THROUGH LIFE Bart chalkboard Ep. 7F03
Re: MTX plugin created (Re: Spam filtering similar to SPF, less breakage)
On 11-Feb-2010, at 09:55, Charles Gregory wrote: > > You are welcome to your opinions on browsers, and are free to whine about the > evils of microsoft all you want, but if you are going to post a link > with the intent for the 'average' person to read it, then you better make it > *accessible* to that average person. Erm.. The string "microsoft" doesn't even exist on that page. -- 'Have you lost your senses?' 'Yes, but I may have found some better ones.' --Interesting Times
Re: Spam filtering similar to SPF, less breakage
Matus UHLAR - fantomas wrote: >> Matus UHLAR - fantomas wrote: >> > Imho, SPF does NOT break forwarding. > > On 11.02.10 19:37, Per Jessen wrote: >> Hmm, the SRS people seem to disagree: >> >> http://www.openspf.org/SRS : SPF "breaks" email forwarding. > > I think those quotes say it all. SRS is a way to create correct and > trackable forwarding, SPF or not. Well, I'll just note that SRS was invented exclusively because of SPF, not because of any critical/actual problems in email forwarding. What is hindering SPF adoption is also a distinct lack of development on the SRS front, notably in getting a workable/performant setup for a major mailserver such as postfix. > The forwarding without changing sender is imho already broken, > however the breakage gets visible with SPF adoption. > Just my opinion, but I would tend to think that SPF broke it then. /Per Jessen, Zürich
Re: Spam filtering similar to SPF, less breakage
On 11/02/2010 18:52, Matus UHLAR - fantomas wrote: >>> Imho, SPF does NOT break forwarding. > > On 11.02.10 19:37, Per Jessen wrote: >> Hmm, the SRS people seem to disagree: >> >> http://www.openspf.org/SRS : SPF "breaks" email forwarding. > > I think those quotes say it all. SRS is a way to create correct and > trackable forwarding, SPF or not. > > The forwardind without changing sender is imho already broken, however the > breakage gets visible with SPF adoption. Yes. A more accurate statement than, "SPF breaks forwarding," would be, "Broken forwarding is incompatible with SPF." -- Mike Cardwell: UK based IT Consultant, Perl developer, Linux admin Cardwell IT Ltd. : UK Company - http://cardwellit.com/ #06920226 Technical Blog : Tech Blog - https://secure.grepular.com/ Spamalyser : Spam Tool - http://spamalyser.com/
Re: Spam filtering similar to SPF, less breakage
> Matus UHLAR - fantomas wrote: > > Imho, SPF does NOT break forwarding. On 11.02.10 19:37, Per Jessen wrote: > Hmm, the SRS people seem to disagree: > > http://www.openspf.org/SRS : SPF "breaks" email forwarding. I think those quotes say it all. SRS is a way to create correct and trackable forwarding, SPF or not. The forwardind without changing sender is imho already broken, however the breakage gets visible with SPF adoption. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Spam is for losers who can't get business any other way.
Re: Spam filtering similar to SPF, less breakage
Matus UHLAR - fantomas wrote: > On 09.02.10 11:42, dar...@chaosreigns.com wrote: >> I apparently need to clarify that I think this is a good idea because >> I am concerned about the number of people (who control DNS records) >> who are very strongly against creating SPF records specifically >> because of forwarding >> breakage. The email I got in response to my request for my employer >> to >> create an SPF record included the word "abomination". From a friend. >> I don't entirely agree, but it is a problem for adoption. >> >> This is entirely an attempt to replicate the functionality of SPF >> without breaking forwarding, and without causing other problems that >> might discourage adoption. > > Imho, SPF does NOT break forwarding. Hmm, the SRS people seem to disagree: http://www.openspf.org/SRS : SPF "breaks" email forwarding. /Per Jessen, Zürich
Re: [sa] Re: MTX plugin created (Re: Spam filtering similar to SPF, less breakage)
On Thu, 11 Feb 2010, Bowie Bailey wrote: What page were you looking at? All I see at that URL is a fairly straightforward description of how to implement his MTX system. The page 'redirects' to this one: http://www.chaosreigns.com/fail It's a rant page telling the visitor that you cannot read the site using Internet Explorer, with major (large font) attitude that this is the fault of the browser. - C
Re: MTX plugin created (Re: Spam filtering similar to SPF, less breakage)
On Thu, Feb 11, 2010 at 06:42:44PM +0100, Matus UHLAR - fantomas wrote: > > > > On Wed, Feb 10, 2010 at 10:00:05PM -0500, dar...@chaosreigns.com wrote: > > > > > http://www.chaosreigns.com/mtx/ > > > > On 11.02.10 16:06, Henrik K wrote: > > > > What a complex scheme you invented for a simple problem. All you have > > > > to do > > > > is to require legimate relays to have a FCrDNS entry with an actually > > > > identifiable name, like starting with "smtp". Much simpler to take > > > > advantage > > > > of that and it actually is somewhat used today. > > > On Thu, Feb 11, 2010 at 06:25:07PM +0100, Matus UHLAR - fantomas wrote: > > > ok, I should do an s/^ip-/smtp-/ on all our clients' ips... > > On 11.02.10 19:34, Henrik K wrote: > > I don't know if there's some joke included or whatever. If they are sending > > mail, then yes having a good PTR will result in less greylisting etc. > > of course > ip-212-081-019-000.static.nextra.sk. > > well, dynamic addresses are listed differently: > > dial-195-168-160-000.dynamic.nextra.sk. > adsl-195-168-244-000.dynamic.nextra.sk. > > so probably > s/^(dial|adsl|ip)-/smtp-/ > > there are _many_ mailservers not having name indicating they are used for > mail and I don't think any form of requiring them to have such name is a > good idea... If the "owner" of such IP wants, he will order the change (if possible). No one is _requiring_ them to have any name, but what name do you think will pass the most mail? If you are the ISP, it's not your job to start changing anything without notice.
Re: MTX plugin created (Re: Spam filtering similar to SPF, less breakage)
> > > On Wed, Feb 10, 2010 at 10:00:05PM -0500, dar...@chaosreigns.com wrote: > > > > http://www.chaosreigns.com/mtx/ > > On 11.02.10 16:06, Henrik K wrote: > > > What a complex scheme you invented for a simple problem. All you have to > > > do > > > is to require legimate relays to have a FCrDNS entry with an actually > > > identifiable name, like starting with "smtp". Much simpler to take > > > advantage > > > of that and it actually is somewhat used today. > On Thu, Feb 11, 2010 at 06:25:07PM +0100, Matus UHLAR - fantomas wrote: > > ok, I should do an s/^ip-/smtp-/ on all our clients' ips... On 11.02.10 19:34, Henrik K wrote: > I don't know if there's some joke included or whatever. If they are sending > mail, then yes having a good PTR will result in less greylisting etc. of course ip-212-081-019-000.static.nextra.sk. well, dynamic addresses are listed differently: dial-195-168-160-000.dynamic.nextra.sk. adsl-195-168-244-000.dynamic.nextra.sk. so probably s/^(dial|adsl|ip)-/smtp-/ there are _many_ mailservers not having name indicating they are used for mail and I don't think any form of requiring them to have such name is a good idea... -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Support bacteria - they're the only culture some people have.
Re: MTX plugin created (Re: Spam filtering similar to SPF, less breakage)
On Thu, Feb 11, 2010 at 06:25:07PM +0100, Matus UHLAR - fantomas wrote: > > On Wed, Feb 10, 2010 at 10:00:05PM -0500, dar...@chaosreigns.com wrote: > > > http://www.chaosreigns.com/mtx/ > > On 11.02.10 16:06, Henrik K wrote: > > What a complex scheme you invented for a simple problem. All you have to do > > is to require legimate relays to have a FCrDNS entry with an actually > > identifiable name, like starting with "smtp". Much simpler to take advantage > > of that and it actually is somewhat used today. > > ok, I should do an s/^ip-/smtp-/ on all our clients' ips... I don't know if there's some joke included or whatever. If they are sending mail, then yes having a good PTR will result in less greylisting etc.
Re: MTX plugin created (Re: Spam filtering similar to SPF, less breakage)
> On Wed, Feb 10, 2010 at 10:00:05PM -0500, dar...@chaosreigns.com wrote: > > http://www.chaosreigns.com/mtx/ On 11.02.10 16:06, Henrik K wrote: > What a complex scheme you invented for a simple problem. All you have to do > is to require legimate relays to have a FCrDNS entry with an actually > identifiable name, like starting with "smtp". Much simpler to take advantage > of that and it actually is somewhat used today. ok, I should do an s/^ip-/smtp-/ on all our clients' ips... -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Quantum mechanics: The dreams stuff is made of.
Re: MTX plugin created (Re: Spam filtering similar to SPF, less breakage)
From: Charles Gregory Date: Thu, 11 Feb 2010 11:55:10 -0500 (EST) On Wed, 10 Feb 2010, dar...@chaosreigns.com wrote: > http://www.chaosreigns.com/mtx/ You know, just for a moment I thought I would take a look, just for curiosity sake, and instead got this moronic jack-ass ATTITUDE page. Heh. Using IE 7.0 I get: Your browser cannot handle the 9 year old standard required by the web page you attempted to access. ... IE 7.0 displays the page fine, but you have to save the file out as a plain html file. -jeff
Re: Spam filtering similar to SPF, less breakage
On 09.02.10 11:42, dar...@chaosreigns.com wrote: > I apparently need to clarify that I think this is a good idea because I am > concerned about the number of people (who control DNS records) who are very > strongly against creating SPF records specifically because of forwarding > breakage. The email I got in response to my request for my employer to > create an SPF record included the word "abomination". From a friend. > I don't entirely agree, but it is a problem for adoption. > > This is entirely an attempt to replicate the functionality of SPF without > breaking forwarding, and without causing other problems that might > discourage adoption. Imho, SPF does NOT break forwarding. It only causes the broken forwarding to be rejected. If I forward your mail to other address from my aliases/virtuser/.forward/.procmailrc/whatever file, It is already not you who sent the mail (although the mail is from you and POSSIBLY not modified). Thus, I should rewrite the from address to indicate the mail is from me (nobody really needs to trust me the mail is from you, unless it's DKIM/PGP/SMIME signed). > I set this up for my mail server (using mtx instead of designatedsender): > > $ host -t PTR 64.71.152.40 > 40.152.71.64.in-addr.arpa domain name pointer panic.chaosreigns.com. > > $ host -t A 40.152.71.64.mtx.panic.chaosreigns.com > 40.152.71.64.mtx.panic.chaosreigns.com has address 127.0.0.1 So you define the IP 64.71.152.40 as OK when sending mail from @panic.chaosreigns.com. address. so it's the exactly same as panic.chaosreigns.com. IN SPF "v=spf1 a:64.71.152.40 -all" > I'll define it slightly differently: > 127.0.0.1 is a pass (negative SA score). > not found is a fail (positive SA score). what means "not found"? "66.3.168.195.mtx.panic.chaosreigns.com not found" would mean I'm not allowed to mail from "panic.chaosreigns.com" address? Or will my server be allowed to mail from your domain? Because SPF above defines this mail to be rejected and nonexistance of the mtx record would do the same, even it it's your forwarded e-mail. > 127.0.0.0 is a fail (positive SA score). > Anything else is undefined (0 SA score) for future options. > I'd still appreciate feedback on the format of the A record. ... > >> Is there any way this wouldn't be very useful? > > > > Is there any place where SPF does not do the same job, other than mail > > forwarding? > > No. But as I said, I am concerned about the potential for wide spread > adoption of SPF due to forwarding breakage enough that I think this would > be much more useful. So, since you don't believe SPF to be widely adopted, you expect your way to be adopted? And all admins must adopt that? Even if they did not adopt SPF/DKIM for a few years they exist? > > On 08.02.10 22:08, dar...@chaosreigns.com wrote: > > > So it's not tied to the SMTP MAIL FROM or anything. > > > Forwarding doesn't break. > On 02/09, Matus UHLAR - fantomas wrote: > > What do you mean by this? > > Do you want to implement new way of defining which hosts are permitted to > > send e-mail? > > Yes. > > There already are attempts to do this, with false positives and > > negatives. > > How is this not better than the other attempts? the correct question is "hwo is this better?". Creating not better system is useless. > > Yours is a bit complicated > > How is it complicated? You need to create 1 record per sending mail > server, in the form: > > .mtx. > > (And the IP needs to be reversed as in all other A records that list IPs.) that's what I call complicated. SPF designs the same by using much easier way, using existing A/MX/PTR records, CIDR ranges, including other SPF records... > > and new which means everyone would > > need to implement this (otherwise he'd get false positives on his outgoing > > mail). > > Yes. http://www.rhyolite.com/anti-spam/you-might-be.html#programmer http://www.rhyolite.com/anti-spam/you-might-be.html#senior-IETF-member-5 which one applies to you? :) > > Therefore I think it won't work this way. > > This is why I said SA scores for a fail should be small at first. > > > Do you see any reason this wouldn't be more quickly adopted than SPF? yes, I think this ain't any better than SPF. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. I intend to live forever - so far so good.
Re: MTX plugin created (Re: Spam filtering similar to SPF, less breakage)
On Thu, Feb 11, 2010 at 11:57:47AM -0500, Bowie Bailey wrote: > dar...@chaosreigns.com wrote: > > On 02/11, Henrik K wrote: > > > >> What a complex scheme you invented for a simple problem. All you have to do > >> is to require legimate relays to have a FCrDNS entry with an actually > >> identifiable name, like starting with "smtp". Much simpler to take > >> advantage > >> of that and it actually is somewhat used today. > >> > > > > I did consider this, but I didn't think it was reasonable to expect people > > to change the host names of their transmitting mail servers. MTX has > > the advantage of only listing mail servers that transmit legitimately, not > > including servers that only receive, although it might be a distinction > > worth losing in exchange for increased adoption. > > > > And you do think it is reasonable to expect people to create an entirely > new DNS subtree? > > Personally, I would rather change the server name. Yeah and lets not forget that what we are looking at is just "another" method of whitelisting. You can't seriously expect to block on some attribute that not everyone can or bothers to change (DNS). None of this allows skipping scanning completely anyway (freemails etc? hello?). So it's pointless given that there are already bunch of methods that are easier. Not to mention the proposed "blacklisting" that can and has been done without "MTX".
Re: MTX plugin created (Re: Spam filtering similar to SPF, less breakage)
Charles Gregory wrote: > On Wed, 10 Feb 2010, dar...@chaosreigns.com wrote: >> http://www.chaosreigns.com/mtx/ > > You know, just for a moment I thought I would take a look, just for > curiosity sake, and instead got this moronic jack-ass ATTITUDE page. What page were you looking at? All I see at that URL is a fairly straightforward description of how to implement his MTX system. > You are welcome to your opinions on browsers, and are free to whine > about the evils of microsoft all you want, but if you are going to > post a link > with the intent for the 'average' person to read it, then you better > make it *accessible* to that average person. The page renders fine for me on Linux/Firefox... -- Bowie
Re: MTX plugin created (Re: Spam filtering similar to SPF, less breakage)
On Wed, 10 Feb 2010, dar...@chaosreigns.com wrote: http://www.chaosreigns.com/mtx/ You know, just for a moment I thought I would take a look, just for curiosity sake, and instead got this moronic jack-ass ATTITUDE page. You are welcome to your opinions on browsers, and are free to whine about the evils of microsoft all you want, but if you are going to post a link with the intent for the 'average' person to read it, then you better make it *accessible* to that average person. Otherwise, you are just being arrogant and rude, and deserve nothing more than a hearty F__K YOU and blacklisting for wasting everyone's time. Don't bother replying to this post, you are officialy dev/nulled (I would delight in bouncing your sorry opinions back to you, but they wouldn't go back to you, they would go back to the list). - C
Re: MTX plugin created (Re: Spam filtering similar to SPF, less breakage)
dar...@chaosreigns.com wrote: > On 02/11, Henrik K wrote: > >> What a complex scheme you invented for a simple problem. All you have to do >> is to require legimate relays to have a FCrDNS entry with an actually >> identifiable name, like starting with "smtp". Much simpler to take advantage >> of that and it actually is somewhat used today. >> > > I did consider this, but I didn't think it was reasonable to expect people > to change the host names of their transmitting mail servers. MTX has > the advantage of only listing mail servers that transmit legitimately, not > including servers that only receive, although it might be a distinction > worth losing in exchange for increased adoption. > And you do think it is reasonable to expect people to create an entirely new DNS subtree? Personally, I would rather change the server name. > I encourage you to get your method standardized. It might work better. > In the mean time, I think mine has a better chance of adoption because > there is no reason not to create the records. > > Perhaps I should consider ".smtp." in a hostname a "pass" for MTX? > I'd prefer not to use that particular string since it's associated with > receiving servers more than transmitting. I'd be tempted to do ".mtx.", > except I'm concerned about administrators unaware of it allowing spammers > to have hostnames including it. Same for ".smtp.", actually. I like > the separate MTX record because it's very explicit identification of a > legitimate transmitting mail server. > "mail" and "mta" are also fairly common. And don't forget things like "smtp01", "smtp02", etc. -- Bowie
Re: MTX plugin created (Re: Spam filtering similar to SPF, less breakage)
On 02/11, Henrik K wrote: > What a complex scheme you invented for a simple problem. All you have to do > is to require legimate relays to have a FCrDNS entry with an actually > identifiable name, like starting with "smtp". Much simpler to take advantage > of that and it actually is somewhat used today. I did consider this, but I didn't think it was reasonable to expect people to change the host names of their transmitting mail servers. MTX has the advantage of only listing mail servers that transmit legitimately, not including servers that only receive, although it might be a distinction worth losing in exchange for increased adoption. I encourage you to get your method standardized. It might work better. In the mean time, I think mine has a better chance of adoption because there is no reason not to create the records. Perhaps I should consider ".smtp." in a hostname a "pass" for MTX? I'd prefer not to use that particular string since it's associated with receiving servers more than transmitting. I'd be tempted to do ".mtx.", except I'm concerned about administrators unaware of it allowing spammers to have hostnames including it. Same for ".smtp.", actually. I like the separate MTX record because it's very explicit identification of a legitimate transmitting mail server. -- "When in doubt, gas it. It may not solve the problem, But it ends the suspense." - Steve Moonitz, DoD #2319, 1994 http://www.ChaosReigns.com
Re: MTX plugin created (Re: Spam filtering similar to SPF, less breakage)
On Thu, Feb 11, 2010 at 03:45:32PM +0100, Per Jessen wrote: > Henrik K wrote: > > > On Wed, Feb 10, 2010 at 10:00:05PM -0500, dar...@chaosreigns.com > > wrote: > >> http://www.chaosreigns.com/mtx/ > > > > What a complex scheme you invented for a simple problem. All you have > > to do is to require legimate relays to have a FCrDNS entry with an > > actually identifiable name, like starting with "smtp". Much simpler to > > take advantage of that and it actually is somewhat used today. > > Hmm, yeah - > > Draxus' proposal: publish a DNS record identifying an IP-address as one > of your mail-servers. > > Henrik: name your mail-server such that is identifiable as a > mailserver. And yeah, I know: my method requires you to dedicate the possibly only PTR you have to some use (since multiple are discouraged and broken). But it's already a known good manner. The MTX proposal adds pretty much no value and has zero chance for widespread adoption.
Re: MTX plugin created (Re: Spam filtering similar to SPF, less breakage)
Henrik K wrote: > On Wed, Feb 10, 2010 at 10:00:05PM -0500, dar...@chaosreigns.com > wrote: >> http://www.chaosreigns.com/mtx/ > > What a complex scheme you invented for a simple problem. All you have > to do is to require legimate relays to have a FCrDNS entry with an > actually identifiable name, like starting with "smtp". Much simpler to > take advantage of that and it actually is somewhat used today. Hmm, yeah - Draxus' proposal: publish a DNS record identifying an IP-address as one of your mail-servers. Henrik: name your mail-server such that is identifiable as a mailserver. /Per Jessen, Zürich
Re: MTX plugin created (Re: Spam filtering similar to SPF, less breakage)
On Wed, Feb 10, 2010 at 10:00:05PM -0500, dar...@chaosreigns.com wrote: > http://www.chaosreigns.com/mtx/ What a complex scheme you invented for a simple problem. All you have to do is to require legimate relays to have a FCrDNS entry with an actually identifiable name, like starting with "smtp". Much simpler to take advantage of that and it actually is somewhat used today.
Re: MTX plugin created (Re: Spam filtering similar to SPF, less breakage)
On 02/11, --[ UxBoD ]-- wrote: > Like the simplicity and it does appear to be a great idea. Why do you > believe SPF or DKIM generate breakage ? Thank you. SPF breakage occurs where a user has configured one of their email addresses to automatically forward their mail to another of their email addresses, and this is (commonly) handled without rewriting the "envelope from". So it fails SPF checking because the forwarding server's IP does not match the "envelope from" domain's SPF record. Also, enough people seem to be offended by the solution to this problem of rewriting the envelope from that it is a significant barrier to adoption. At the moment I do not believe DKIM style solutions cause breakage. Honestly I have not looked into them enough. But as you said: Simplicity. At a brief glance, MTX does not have the problems listed here: http://en.wikipedia.org/wiki/DomainKeys_Identified_Mail#Weaknesses (message replay, arbitrary forwarding, breakage by (mailing list) modification of email, CPU overhead) -- "When we remember we are all mad, the mysteries of life disappear and life stands explained." - Mark Twain http://www.ChaosReigns.com
Re: MTX plugin created (Re: Spam filtering similar to SPF, less breakage)
- dar...@chaosreigns.com wrote: > http://www.chaosreigns.com/mtx/ > > -- > "Democracy is the theory that the common people know what they want, > and deserve to get it good and hard." - H. L. Mencken > http://www.ChaosReigns.com Like the simplicity and it does appear to be a great idea. Why do you believe SPF or DKIM generate breakage ? -- Thanks, Phil
MTX plugin created (Re: Spam filtering similar to SPF, less breakage)
http://www.chaosreigns.com/mtx/ -- "Democracy is the theory that the common people know what they want, and deserve to get it good and hard." - H. L. Mencken http://www.ChaosReigns.com
Re: Spam filtering similar to SPF, less breakage
On 2010-02-09 22:31, dar...@chaosreigns.com wrote: [Ideas for a new scheme similar to a subset of SPF.] I don't think the SpamAssassin users list is the right place to discuss a new generasl scheme like this, but here goes anyway. Please not that the comments below is just a first reaction. I haven't really thought this through. A general thought is: What does your current scheme give that HELO SPF + FCDNS doesn't? (SPF can be used with HELO as well as MAIL FROM). What format should this arbitrary A record be? I suggest you use a leading underscore for you magic subdomain (2.0.0.10._mtx.smallbusiness.com). I do this because I think your scheme need one more thing to be of any use at all. It needs a way for the domain owner to sopecify that they are using it. This could be done by creating a record for "_mtx.smallbusiness.com". Without a way to indicate wether the scheme is used or not, it'll be unusable for blocking until *all* major email providers as well as almost everyone else is using it. Using an underscore makes it less likely to collide with existing host names. It also makes it more apparent that it's not a regular hostname. A new record type might be even better. Regards /Jonas -- Jonas Eckerman Fruktträdet & Förbundet Sveriges Dövblinda http://www.fsdb.org/ http://www.frukt.org/ http://whatever.frukt.org/
Re: Spam filtering similar to SPF, less breakage
On Tue, 2010-02-09 at 11:42 -0500, dar...@chaosreigns.com wrote: > I apparently need to clarify that I think this is a good idea because I am > concerned about the number of people (who control DNS records) who are very > strongly against creating SPF records specifically because of forwarding > breakage. The email I got in response to my request for my employer to > create an SPF record included the word "abomination". From a friend. > I don't entirely agree, but it is a problem for adoption. > > This is entirely an attempt to replicate the functionality of SPF without > breaking forwarding, and without causing other problems that might > discourage adoption. > > How does this idea authenticate mail from domain ? SPF is aimed at doing that. IMHO the SPF-breaks-forwarding argument is misplaced What about SRS. If SRS implementation is not going to be easy because mailservers have been there too long for adopting anything new then can your be sure MailServer IP validation will be adopted ? Anyway I block spams from almost all non-mailservers by using RBL's I dont see any value add in implementing this Thanks Ram > I set this up for my mail server (using mtx instead of designatedsender): > > $ host -t PTR 64.71.152.40 > 40.152.71.64.in-addr.arpa domain name pointer panic.chaosreigns.com. > > $ host -t A 40.152.71.64.mtx.panic.chaosreigns.com > 40.152.71.64.mtx.panic.chaosreigns.com has address 127.0.0.1 > > All it took was creating a single record in bind: > > 40.152.71.64.mtx.panic.chaosreigns.com. IN A 127.0.0.1 > > > I'll define it slightly differently: > 127.0.0.1 is a pass (negative SA score). > not found is a fail (positive SA score). > 127.0.0.0 is a fail (positive SA score). > Anything else is undefined (0 SA score) for future options. > > > I'd still appreciate feedback on the format of the A record. > > > On 02/09, RW wrote: > > You've mixed-up A record and PTR record. > > Yes. Embarrassing. > > > Checking for full-circle DNS already does most of this. > > My home dynamic cablemodem address passes full-circle DNS. But not this. > So this is far more useful for checking if an IP is a legitimate sending > mail server. > > > What your > > scheme would do is check for otherwise legitimate servers that have > > been compromised and are delivering direct-to-mx. > > An otherwise legitimate but compromised mail server would not be detected > by this. I'm curious why you interpreted it differently. > > > On 02/09, Charles Gregory wrote: > > On Mon, 2010-02-08 at 22:08 -0500, dar...@chaosreigns.com wrote: > > > What you describe here is functionally similar to an SPF lookup with a > > 'pass' result. The server provides positive verification that the > > listed IP is a legitimate sender for that domain. > > Yes. > > > As long as 'otherwise' is a definitive 'fail' response from an SPF (or > > equivalent) server, and not merely an absence of SPF server > > Yes. Definitive "fail". > > > Your method would allow 'spoofing' so that a spammer who hacks a > > legitimate server can use a valid return address on a different domain, > > but still the mail would receive a 'passing' grade. At least, with SPF, > > the spammer must forge an address on the hacked domain, which increases > > the likelihood of detection > > Yes. I would blacklist domains that "pass" hacked servers. Just as IPs of > hacked servers are blacklisted. They're sending spam, and need to be > fixed. > > >> Forwarding doesn't break. > > > > Ah, so you want to allow 'legitimate' forwarding, but not allow spammers > > to 'forward' their mail? Good luck with that. The only way to make it > > work for the legitimate sender, but not for spammers is to have a > > mechanism built-in to the forwarding server that encapsulates or rewrites > > the envelope 'From' address. > > Encapsulating or rewriting the envelope 'From' address seems significantly > less likely to be adopted from what I've read. > > >> Obviously you'd need a blacklist of spammer domains that list spamming > >> IPs as legit senders. > > > > And you would be playing the same 'musical chairs' game with new domains > > created by spammers on a daily basis. All the same flaws of SPF, and no > > greater benefit. > > Same domain blacklisting issues as SPF, yes. > > I am not very concerned about the throw-away domains because > I'll reject all mail from domains not at least 10 days old. 10+ > day old domains are already listed as 127.0.2.3 records from > example.com.hostkarma.junkemailfilter.com. > > I believe the benefit of not breaking forwarding is sufficient to make it > much more useful than SPF for spam filtering. I've come across enough > people, personally, recently, in trying to block (some = positive SA > score) emails without an SPF "pass", who are not willing to ever implement > SPF due to breaking forwarding that I believe this would be useful. > > >> Is there any way this wouldn't be very u
Re: Spam filtering similar to SPF, less breakage
On Tue, 9 Feb 2010 18:02:09 -0500 dar...@chaosreigns.com wrote: > On 02/09, RW wrote: > > > And everything that it didn't block could be blocked by > > > blacklisting domains which have MTX records for spamming IPs. > > > > The same thing applies to full circle DNS > > So you want to blacklist all domains that have *any* PTR records for > IPs that send spam? Perhaps you should google full-circle dns if you don't understand what it means. Essentially there's little difference, unless you are happy to ignore spammers that get blacklisted and then remove the MTX record. If you are, then there's little point to listing them in the first place. > > > > Every thing else is either handled by full-circle and no DNS > > > > tests, > > > > > > Full circle DNS tests don't block spam from quite a lot of IPs. > > > > But how many of those are neither mail-servers, nor spammer > > controlled ip ranges. > > A lot? Spam bot nets. Spambots don't have full-circle DNS. > > The chief problem is that there is no way to use this scheme until > > it has *very* high adoption, below 95% it wouldn't even be worth > > scoring > > As I recently posted, it can be used for whitelisting (after > blacklisting) immediately. And that use could increase creation of > the relevant records gradually until they're wide spread. How could your scheme be used for whitelisting when a huge amount of spam comes through mail-servers that send a mixture of spam and ham? Would you really want to whitelist hotmail? This kind of argument was made about SPF - a pass still scores -0.001. SPF has a limited amount of enlightened self-interest about it. If you publish SPF records you get less backscatter - your scheme doesn't do that. There's nothing in your scheme to encourage anyone to use it. > > at 0.5 in Spamassassin. With SPF you at least know the difference > > between a fail and a non-adopter. Whilst you could identify > > compliant servers there's no way that that would warrant anthing > > more than a nominal negative score. SPF_PASS scores -0.001 > > Only with a domain blacklist. So why would anyone use it and risk being blacklisted, what's the point of it existing if you don't punish domains that don't join - any that get on the blacklist could just drop-out of the scheme.
Re: Spam filtering similar to SPF, less breakage
dar...@chaosreigns.com wrote: On 02/09, Kris Deugau wrote: I'm still not seeing the whole picture; maybe you can explain the difference between these two cases: 1) Legitimate sender, uses the NAT machine as the legitimate, designated (10.0.0.2) with a certain rDNS (exchange.smallbusiness.com). 2) Spam, from an infected machine on the same LAN, either via relay (10.0.0.2) with a certain rDNS (exchange.smallbusiness.com). The IP is sending spam, so it gets blacklisted (by a blacklist of domains which have MTX records for spamming IPs). ... So what incentive do I as: (pick any one or more hats below) ISP mail/DNS admin Colo/self-hosted domain admin Inbound mail admin have to either set up this extra A record, or check for it, that existing blacklists don't provide? Chicken<->egg. Where do you draw the lines for adding someone to a/the blacklist? 0.0001% spam? 0.01%? 1%? How would you publish the blacklist? Globally? Rely on individual local DNS operators running their own blacklist? (Good luck getting *off* ten million local blacklists...) Two options where smallbusiness.com doesn't have the ability to define its own PTR records. For example, the PTR record is defined by isp.com. 1) isp.com sets the PTR record to exchange.smallbusiness.isp.com, and creates the MTX record for it (2.0.0.10.mtx.smallbusiness.isp.com with a value of 127.0.0.1). If 10.0.0.2 sends spam, isp.com gets blacklisted. Immediately? Would you *really* blacklist eg AOL, Hotmail, or Gmail if you received *one* spam from any of their networks? If you have paying customers using your mail systems, you'd be out of business in a matter of months. 2) isp.com sets the PTR record to exchange.smallbusiness.com, and smallbusiness.com creates their own MTX record (2.0.0.10.mtx.smallbusiness.com = 127.0.0.1). If 10.0.0.2 sends spam, smallbusiness.com gets blacklisted. and some arbitrary (sub^n)domain A record based on the PTR. Yes. That's all. What format should this arbitrary A record be? Aside from considerations above, what you've posted is fine, structurally. From a pure "how to publish data" perspective, a new DNS RR type would be slightly better, but reversed IPs concatenated to a subdomain is a well-established way to publish this type of data. About all your scheme seems to do is identify IPs which may emit legitimate email, generally; it's certainly nothing I'd score at anything more than an advisory -0.001 in SA. Of course, unless you use a blacklist of domains which have MTX records for spamming domains. Well, aside from getting tougher on customers with infected systems, how do you propose to actually stop the spam from being generated? If you can't stop that, you-as-ISP *CAN NOT* fully prevent spam from being relayed through your servers unless you unplug the network and power cables... Consider the case of a legitimate ISP's outbound relay - most of the mail is perfectly legitimate, but sooner or later *someone* on an IP controlled by that ISP (and therefore allowed to relay through that outbound relay host) will have their machine infected or someone with an account with that ISP will have their password stolen, and then that infected machine will spew out junk via the relay, or a machine somewhere else will use that stolen password to send SMTP AUTH mail through that relay We regularly see both of those cases here (medium-sided ISP). It's an issue of blacklisting. What is involved in keeping your ISP off of IP blacklists? Blocking outbound connections to port 25 from residential IP blocks, responding to reports (cutting of residential customers found to be infected, warning and eventually cutting off static-IP business customers; notifying users whose passwords seem to have been cracked or stolen - among other standard measures). It helps, and we've signed up for the feedback loop widgets with a number of places (AOL, Comcast), but there is NO WAY we can absolutely stop all spam from emitting from IP space under our control, short of turning off our core routers. This is not exactly unusual. The more I think about it and the more I read of what you're describing, the more most of it seems like a reasonable component of any blacklist operation, not a whole FUSSP[1] in its own right. [1] http://www.claws-and-paws.com/fussp.html, among other references I have been directed to that url frequently in the last few days :) The form may be a bit tongue-in-cheek, but taking it at face value is helpful in seeing if you're really trying something new, or if you're just putting a new coat of paint on something that's already in practice as a small subset of a larger operation. (Or trying to resurrect a dead horse that was already beaten to a thin paste ten years ago. I don't think you've gotten *that* far yet.) TBH, what you seem to be trying to do seems far better suited to a local syste
Re: [sa] Re: Spam filtering similar to SPF, less breakage
On Tue, 9 Feb 2010, dar...@chaosreigns.com wrote: Charles: Thanks, I clearly need to lay out implementation sequence. Sorry to be wasting your time, but I am smart enough to have grasped it from your previous e-mails. You just WANT your solution to be magically adopted by everyone and you seem to be completely dismissing/ignoring the real and practical improbability of any widespread implementation Are you willing to, right now, create a .mtx. DNS record for all your transmitting mail servers? If not, why not? Because it does not benefit me or my users. You have failed to convince me that any significant widespread implementation will occur, and have not demonstrated any signficant new benefits that make your idea any more appealing than existing SPF and white/blacklists. For me, it is simpler to forward mail in an SPF-compatible fashion, and require SMTP Auth through one server designated with SPF-PASS. Haven't done that yet, for similar reasons. :) Any thoughts on the format of that record yet? Take a look at the format used by SPF. You are eliminating the cross-reference to sender address, but otherwise, all the subtle nuances are the same. Which still leads me back to 'why should I bother to participate in reinventing the wheel' Anyways, this is my fin du conversation - C
Re: Spam filtering similar to SPF, less breakage
On Tue, 9 Feb 2010 14:15:37 -0500 dar...@chaosreigns.com wrote: > On 02/09, RW wrote: > > A compromised webserver with full-circle DNS would be caught by > > this. My point is that is the only class of spam that this could > > help with > > Ah, sorry, I thought you meant mail server. > > Still, I don't understand why you're saying this. > > It would also block, for example, spam from a dynamic cablemodem IP. Aside from a few corner cases, I don't see any advantage over checking for full circle DNS > And everything that it didn't block could be blocked by blacklisting > domains which have MTX records for spamming IPs. The same thing applies to full circle DNS > > Every thing else is either handled by full-circle and no DNS tests, > > Full circle DNS tests don't block spam from quite a lot of IPs. But how many of those are neither mail-servers, nor spammer controlled ip ranges. My guess is that the kind of spam your scheme would identify is mostly caught by other means. The chief problem is that there is no way to use this scheme until it has *very* high adoption, below 95% it wouldn't even be worth scoring at 0.5 in Spamassassin. With SPF you at least know the difference between a fail and a non-adopter. Whilst you could identify compliant servers there's no way that that would warrant anthing more than a nominal negative score. SPF_PASS scores -0.001 > > or can be easily worked around by spammers setting their own dns. > > Spammers can't create DNS records for hostnames for IPs they don't own > (don't have PTR authority delegated to them for). I was referring to IP ranges that they do control
Re: Spam filtering similar to SPF, less breakage
dar...@chaosreigns.com wrote: > "For every complex problem, there is a solution that is simple, neat, > and wrong." - H. L. Mencken I think your auto-quote program is trying to tell you something... :) -- Bowie
Re: Spam filtering similar to SPF, less breakage
On 02/09, Kris Deugau wrote: > I'm still not seeing the whole picture; maybe you can explain the > difference between these two cases: > > 1) Legitimate sender, uses the NAT machine as the legitimate, designated > (10.0.0.2) with a certain rDNS (exchange.smallbusiness.com). > 2) Spam, from an infected machine on the same LAN, either via relay > (10.0.0.2) with a certain rDNS (exchange.smallbusiness.com). The IP is sending spam, so it gets blacklisted (by a blacklist of domains which have MTX records for spamming IPs). > Obviously I've missed *something* about what you've been trying to > describe, but I haven't seen any indication that you're working with > **ANYTHING** other than the PTR record Yes. > for the (apparent) originating IP Nothing apparent about it. The delivering IP (last untrusted relay) is the only thing in an email that can't be forged. > (which, for a small business on a single static-IP connection, may or > may not even have anything to do with the business's own domain(s) at > all), Indeed, so they would need to get whoever is delegated the authority to provide PTR records for that IP to create the necessary records. Two options where smallbusiness.com doesn't have the ability to define its own PTR records. For example, the PTR record is defined by isp.com. 1) isp.com sets the PTR record to exchange.smallbusiness.isp.com, and creates the MTX record for it (2.0.0.10.mtx.smallbusiness.isp.com with a value of 127.0.0.1). If 10.0.0.2 sends spam, isp.com gets blacklisted. 2) isp.com sets the PTR record to exchange.smallbusiness.com, and smallbusiness.com creates their own MTX record (2.0.0.10.mtx.smallbusiness.com = 127.0.0.1). If 10.0.0.2 sends spam, smallbusiness.com gets blacklisted. > and some arbitrary (sub^n)domain A record based on the PTR. Yes. That's all. What format should this arbitrary A record be? > About all your scheme seems to do is identify IPs which may emit > legitimate email, generally; it's certainly nothing I'd score at > anything more than an advisory -0.001 in SA. Of course, unless you use a blacklist of domains which have MTX records for spamming domains. > Consider the case of a legitimate ISP's outbound relay - most of the > mail is perfectly legitimate, but sooner or later *someone* on an IP > controlled by that ISP (and therefore allowed to relay through that > outbound relay host) will have their machine infected or someone with an > account with that ISP will have their password stolen, and then that > infected machine will spew out junk via the relay, or a machine > somewhere else will use that stolen password to send SMTP AUTH mail > through that relay > > We regularly see both of those cases here (medium-sided ISP). It's an issue of blacklisting. What is involved in keeping your ISP off of IP blacklists? > The more I think about it and the more I read of what you're describing, > the more most of it seems like a reasonable component of any blacklist > operation, not a whole FUSSP[1] in its own right. > > [1] http://www.claws-and-paws.com/fussp.html, among other references I have been directed to that url frequently in the last few days :) -- "For every complex problem, there is a solution that is simple, neat, and wrong." - H. L. Mencken http://www.ChaosReigns.com
Re: Spam filtering similar to SPF, less breakage
Charles: Thanks, I clearly need to lay out implementation sequence. 1) People who are sufficiently entertained by the subject create MTX records for our servers, and collect blacklists of domains which create MTX records for spamming IPs. 2) New SA capability is implemented: A) Blacklisting by the domain of the PTR record of the sending IP (MTX_BL). B) Verifying IPs against MTX records (MTX_PASS / MTX_FAIL). 3) Conservative people use these new tests to reduce false positives: score MTX_BL 1 score MTX_PASS -1# Only hit if MTX_BL wasn't. score MTX_FAIL 0.001 People with less need to be conservative, perhaps with SA configured to report false positives to non-forged senders, use more aggressive scores: score MTX_BL 2 score MTX_PASS -2 score MTX_FAIL 1 4) In order to reduce false positives, more people create MTX records. 5) Due to 4, MTX_FAIL scores can safely be increased slightly without increasing false positives. 6) Go to 4. One day, due to steps 4-6, enough people have created MTX records that all email without one can reasonably be rejected by the MTA. Are you willing to, right now, create a .mtx. DNS record for all your transmitting mail servers? If not, why not? Any thoughts on the format of that record yet? On 02/09, Charles Gregory wrote: > LOL Good luck with that. The first time that an important e-mail > correspondent (money!) is blocked by such a 'default' setting, the > sysadmins will be rushing to cripple this default action. You will never > succeed in introducing ANY spam filtering system that blocks mail based > upon an 'undecided' or 'neutral' status. This is a good point. This is also why I suggested starting out with a low score, for most people. Of course I'll use something around 4 to 4.5. >> I disagree. I can implement it now (in fact I expect to... > > For your own use, sure. But that's just like SPF. A bunch of people will > use it, and a bunch, including ones that you still *really* want to > communicate with, will NOT. Have you figured out how you are going to > sell 'hotmail' and 'gmail' on your idea? Or are you just going to block > all mail from them? Your choice. But if you have multiple users, well, > you had better choose conservatively. (grin) Did my implementation sequence above sufficiently cover this? Even with a MTX_FAIL score of 4.5, it still won't block the vast majority of email I get from gmail. And I certainly wouldn't switch to blocking all email without an MTX record without gmail adopting them. And I do think there is a decent possibility of gmail eventually adopting MTX records due to the sequence I described. > And every hotmail user will be writing to the you complaining they have > no way to talk hotmail into adopting your system, and begging you The vast majority of legit mail will still get through even with my high MTX_FAIL score. And if the complaints get annoying, I'll lower it. And really, everybody that's currently getting a score of 0.5+ score from SA, I'm happy to never hear from again. And even if nobody gives MTX_FAIL a positive score, I still expect MTX records to be adopted to reduce false positives, making it reasonable to gradually use slightly higher MTX_FAIL scores. >> I think you missed something important. Creating the records I suggest >> can create no false positives. That point is critical to this idea. > > The FP's would occur on the systems *looking* for those records, and > scoring positively in SA for simply not finding them. Your argument, and > all of mine here, are not about the simplistic task of creating a DNS > record, but about the battle to have the scoring/testing protocol > implemented to make those records 'useful'. No, actually, I was arguing for the simplicity of creating the DNS records. I realize it'll be a while before major email providers start giving MTX_FAIL significant positive values. The records are immediately useful for whitelisting to reduce false positives. -- "We will be dead soon. Is this how we want to live?" http://www.ChaosReigns.com
Re: Spam filtering similar to SPF, less breakage
dar...@chaosreigns.com wrote: On 02/09, Kris Deugau wrote: Spammer mail originates from 10.0.0.2 (static IP assigned by ISP). PTR record is 2.0.0.10.in-addr.arpa -> exchange.smallbusiness.com 2.0.0.10.mtx.exchange.smallbusiness.com -> 127.0.0.1 because this is the recognized designated outbound relay for Small Business's legitimate mail, and they've followed your proposal. How is the spam to be *not* considered a legitimate sender in this case? Even if the Exchange server isn't actually processing the email, its public IP will still be the originating IP of the message. Blacklist the validating domain smallbusiness.com. Reject all email that has a *.mtx.*.smallbusiness.com record. Just as you would blacklist the sending IP for spamming. As with SPF, I expect this to be quite a lot easier than maintaining a blacklist of spamming IPs. If I'm wrong on that one point, this is useless. I'm still not seeing the whole picture; maybe you can explain the difference between these two cases: 1) Legitimate sender, uses the NAT machine as the legitimate, designated relayhost. So far as a remote system is concerned, the mail originates from an IP (10.0.0.2) with a certain rDNS (exchange.smallbusiness.com). Remote system takes the IP, gets the PTR, and looks up 2.0.0.10.mtx.exchange.smallbusiness.com, and gets 127.0.0.1. Yay! Good mail, let's let it through! 2) Spam, from an infected machine on the same LAN, either via relay through the NAT box, or using its own SMTP engine to do direct-to-MX So far as a remote system is concerned, the mail originates from an IP (10.0.0.2) with a certain rDNS (exchange.smallbusiness.com). Remote system takes the IP, gets the PTR, and looks up 2.0.0.10.mtx.exchange.smallbusiness.com, and gets 127.0.0.1. Yay! Good mail, let's let it through! Would you still like more detail on what pieces of information I'm looking at, and where I'm getting them from? Obviously I've missed *something* about what you've been trying to describe, but I haven't seen any indication that you're working with **ANYTHING** other than the PTR record for the (apparent) originating IP (which, for a small business on a single static-IP connection, may or may not even have anything to do with the business's own domain(s) at all), and some arbitrary (sub^n)domain A record based on the PTR. About all your scheme seems to do is identify IPs which may emit legitimate email, generally; it's certainly nothing I'd score at anything more than an advisory -0.001 in SA. Consider the case of a legitimate ISP's outbound relay - most of the mail is perfectly legitimate, but sooner or later *someone* on an IP controlled by that ISP (and therefore allowed to relay through that outbound relay host) will have their machine infected or someone with an account with that ISP will have their password stolen, and then that infected machine will spew out junk via the relay, or a machine somewhere else will use that stolen password to send SMTP AUTH mail through that relay We regularly see both of those cases here (medium-sided ISP). The more I think about it and the more I read of what you're describing, the more most of it seems like a reasonable component of any blacklist operation, not a whole FUSSP[1] in its own right. [1] http://www.claws-and-paws.com/fussp.html, among other references -kgd
Re: Spam filtering similar to SPF, less breakage
On Tue, 9 Feb 2010, dar...@chaosreigns.com wrote: So rather than mimicing SPF, you want to mimic the effect of various IP-based blacklists to which an ISP can report all of its 'unauthorized' IP's (typicalyl dynamic IP blocks)? Basically, except of course that the default, when not participating, is effectively blacklisting (in the sense in which SA uses blacklists to increase the spammines score of an email). LOL Good luck with that. The first time that an important e-mail correspondent (money!) is blocked by such a 'default' setting, the sysadmins will be rushing to cripple this default action. You will never succeed in introducing ANY spam filtering system that blocks mail based upon an 'undecided' or 'neutral' status. . Large companies which frequently reorganize their IP blocks will shy away from such a system, and smaller companies will lack the time/resources to implement anything that isn't 'out of the box'. I disagree. I can implement it now (in fact I expect to... For your own use, sure. But that's just like SPF. A bunch of people will use it, and a bunch, including ones that you still *really* want to communicate with, will NOT. Have you figured out how you are going to sell 'hotmail' and 'gmail' on your idea? Or are you just going to block all mail from them? Your choice. But if you have multiple users, well, you had better choose conservatively. (grin) So I block some more spam, and I get some extra false positives, and the senders get notified. And every hotmail user will be writing to the you complaining they have no way to talk hotmail into adopting your system, and begging you to *remove* the 'block'. And if you stick to your guns, those are people who, by no choice of their own, you will not hear from again. And if you have users who stop hearing from good friends and relatives, they won't be yuour users much longer. As I said before, 'in a perfect world' your idea would work. But sadly, not in THIS one I think you missed something important. Creating the records I suggest can create no false positives. That point is critical to this idea. The FP's would occur on the systems *looking* for those records, and scoring positively in SA for simply not finding them. Your argument, and all of mine here, are not about the simplistic task of creating a DNS record, but about the battle to have the scoring/testing protocol implemented to make those records 'useful'. Either they participate, and get their sending IPs whitelisted, or they don't participate, and they don't get their IPs whitelisted and mail from those IPs is more likely to be flagged as spam. Expressed as a 'whitelist only' mechanism that at least opens the door to a possibility of avoiding the fears of implementation, but again, you face the same lethargy and fear that keeps SPF from benig widely adopted Good to know. It still doesn't concern me. This would still eliminate spams from the vast majority of IPs for which spammers aren't delegated to host PTR records. And if all spam has a verified paper trail (delivering IP -> domain -> registrar who can be subpoened), I think the sending of spam itself will be a lot easier to stop. If ISP's just blocked port 25 access for their DSL customers a great deal of spam would be stopped. And that is SO easy to do. Think about that. If you can't even talk ISP's into such a simple approach, truly free of any false positive, then how can you expect 'reason' regarding a system that you admit has to have a bigger chance of false postitives? Except that it causes me no problems if they don't implement my whitelisting. Then it will cuase you no problem at all if they just don't implement anything at all? Those administrators will say that they do not have control over DNS, because that's done at a higher organizational level, or that they don't want to do something that is not 'standard' and will tell their users to find another way to communicate with you. I'm comfortable with that possibility. As I said, I expect benefit even without people participating. Is this 'all about you'? If so, then just whitelist your own correspondents and save us all the trouble of debating a DNS PTR system that benefits no one but you. If you intend to introduce a new idea for broad adoption, then it needs to benefit everyone. And 'everyone' is not giong to be 'comfortable with that possibility' that you are :) - C
Re: Spam filtering similar to SPF, less breakage
On 02/09, RW wrote: > A compromised webserver with full-circle DNS would be caught by this. > My point is that is the only class of spam that this could help with Ah, sorry, I thought you meant mail server. Still, I don't understand why you're saying this. It would also block, for example, spam from a dynamic cablemodem IP. And everything that it didn't block could be blocked by blacklisting domains which have MTX records for spamming IPs. > Every thing else is either handled by full-circle and no DNS tests, Full circle DNS tests don't block spam from quite a lot of IPs. > or can be easily worked around by spammers setting their own dns. Spammers can't create DNS records for hostnames for IPs they don't own (don't have PTR authority delegated to them for). -- "Life is but a walking shadow, a poor player that struts and frets his hour upon the stage--and then is heard no more. It is a tale told by an idiot, full of sound and fury, signifying nothing." - William Shakespeare http://www.ChaosReigns.com
Re: Spam filtering similar to SPF, less breakage
On 02/09, dar...@chaosreigns.com wrote: > Anything else is undefined (0 SA score) for future options. This won't work. Everything lacking a 127.0.0.1 record needs to be a "fail", otherwise spammers can create undefined records to circumvent this. On 02/09, Charles Gregory wrote: > So rather than mimicing SPF, you want to mimic the effect of various > IP-based blacklists to which an ISP can report all of its 'unauthorized' > IP's (typicalyl dynamic IP blocks)? Basically, except of course that the default, when not participating, is effectively blacklisting (in the sense in which SA uses blacklists to increase the spammines score of an email). > The obvious drawback is the same for your system as the already existing > dynamic-ip blackilsts, which is that it only works when domains take the > time and trouble to register either their 'authorized' (in your case) or > 'unauthorized' (for the blacklist) ranges of IP's. Large companies which > frequently reorganize their IP blocks will shy away from such a system, > and smaller companies will lack the time/resources to implement anything > that isn't 'out of the box'. I disagree. I can implement it now (in fact I expect to, which is why I'd really like feedback on the A record format). So I block some more spam, and I get some extra false positives, and the senders get notified. And the senders can try to get the relevant MTX records created if they want. And maybe along the way these MTX records become a little more common, and I can increase the spam score of emails without MTX records and block some more spam without further increasing false positives. And maybe eventually, as a result of this iterative process, enough people create MTX records that I can reject all email without one. Having looked over the scores of my non-spams, I'm comfortable with the additional false positives up to an additional score of 4.5, as long as the sender is notified and has some possibility of eliminating that additional score. Others might be more comfortable with an additional score of 1. Still, you catch more spams, cause a few false positives, and the senders have the possibility of fixing the false positives. > Unlikely in many cases, but I would quibble over 'less'. Overall, most > corporate minds seem to think that they prefer false negatives to false > positives, so they are extremely reluctant to adopt any strategy that > increases the chance of a false positive, even under such strange I think you missed something important. Creating the records I suggest can create no false positives. That point is critical to this idea. Either they participate, and get their sending IPs whitelisted, or they don't participate, and they don't get their IPs whitelisted and mail from those IPs is more likely to be flagged as spam. Unless they send spam, in which case they'll get blacklisted. Which would be worse than not participating. So they should be really sure not to whitelist any IPs that send spam. And of course just as in existing IP blacklists, it is worth taking someone off a blacklist if they have corrected their spam problem. Not flawless, but still way easier than maintaining an IP blacklist. > Another feature already covered by a blacklist, and, already being > bypassed by numerous spammers who are smart enough to buy a domain name > months before they use it. (shrug) Good to know. It still doesn't concern me. This would still eliminate spams from the vast majority of IPs for which spammers aren't delegated to host PTR records. And if all spam has a verified paper trail (delivering IP -> domain -> registrar who can be subpoened), I think the sending of spam itself will be a lot easier to stop. > But *why* do they refuse to 'fix' their forwarding? I strongly suspect I don't know. > that the same reasoning would apply to their decision to not implement > SPF or your IP-based filter idea. Except that it causes me no problems if they don't implement my whitelisting. On 02/09, Charles Gregory wrote: > Those administrators will say that they do not have control over DNS, > because that's done at a higher organizational level, or that they don't > want to do something that is not 'standard' and will tell their users to > find another way to communicate with you. Same BS that is used to dodge I'm comfortable with that possibility. As I said, I expect benefit even without people participating. -- "The most merciful thing in the world, I think, is the inability of the human mind to correlate all its contents." http://www.ChaosReigns.com
Re: Spam filtering similar to SPF, less breakage
On Tue, 9 Feb 2010 11:42:07 -0500 dar...@chaosreigns.com wrote: > On 02/09, RW wrote: > > What your > > scheme would do is check for otherwise legitimate servers that have > > been compromised and are delivering direct-to-mx. > > An otherwise legitimate but compromised mail server would not be > detected by this. I'm curious why you interpreted it differently. A compromised webserver with full-circle DNS would be caught by this. My point is that is the only class of spam that this could help with Every thing else is either handled by full-circle and no DNS tests, or can be easily worked around by spammers setting their own dns.
Re: Spam filtering similar to SPF, less breakage
On Tue, 9 Feb 2010, dar...@chaosreigns.com wrote: When I implement this, senders will get an error asking them to ask their administrator to create the necessary record. Those administrators will say that they do not have control over DNS, because that's done at a higher organizational level, or that they don't want to do something that is not 'standard' and will tell their users to find another way to communicate with you. Same BS that is used to dodge SPF. It's not that your idea is 'bad', it's just not that much different from SPF in terms of the roadbblocks to its effective adoption. Don't blame you for trying. Actually wish it worked. :) - Charles
Re: Spam filtering similar to SPF, less breakage
On Tue, 9 Feb 2010, dar...@chaosreigns.com wrote: My home dynamic cablemodem address passes full-circle DNS. But not this. So this is far more useful for checking if an IP is a legitimate sending mail server. So rather than mimicing SPF, you want to mimic the effect of various IP-based blacklists to which an ISP can report all of its 'unauthorized' IP's (typicalyl dynamic IP blocks)? The obvious drawback is the same for your system as the already existing dynamic-ip blackilsts, which is that it only works when domains take the time and trouble to register either their 'authorized' (in your case) or 'unauthorized' (for the blacklist) ranges of IP's. Large companies which frequently reorganize their IP blocks will shy away from such a system, and smaller companies will lack the time/resources to implement anything that isn't 'out of the box'. Encapsulating or rewriting the envelope 'From' address seems significantly less likely to be adopted from what I've read. Unlikely in many cases, but I would quibble over 'less'. Overall, most corporate minds seem to think that they prefer false negatives to false positives, so they are extremely reluctant to adopt any strategy that increases the chance of a false positive, even under such strange conditions as a hack Indeed, given that there are no issues of false positives from rewriting the envelope sender, one could argue that it is the change *most* likely to be adopted, and therefore it has significance that it is not being adopted by everyone I am not very concerned about the throw-away domains because I'll reject all mail from domains not at least 10 days old. Another feature already covered by a blacklist, and, already being bypassed by numerous spammers who are smart enough to buy a domain name months before they use it. (shrug) I believe the benefit of not breaking forwarding is sufficient to make it much more useful than SPF for spam filtering. I've come across enough people, personally, recently, in trying to block (some = positive SA score) emails without an SPF "pass", who are not willing to ever implement SPF due to breaking forwarding that I believe this would be useful. But *why* do they refuse to 'fix' their forwarding? I strongly suspect that the same reasoning would apply to their decision to not implement SPF or your IP-based filter idea. - C
Re: Spam filtering similar to SPF, less breakage
On 02/09, Kris Deugau wrote: > Spammer mail originates from 10.0.0.2 (static IP assigned by ISP). > > PTR record is 2.0.0.10.in-addr.arpa -> exchange.smallbusiness.com > > 2.0.0.10.mtx.exchange.smallbusiness.com -> 127.0.0.1 because this is the > recognized designated outbound relay for Small Business's legitimate > mail, and they've followed your proposal. > > How is the spam to be *not* considered a legitimate sender in this case? > Even if the Exchange server isn't actually processing the email, its > public IP will still be the originating IP of the message. Blacklist the validating domain smallbusiness.com. Reject all email that has a *.mtx.*.smallbusiness.com record. Just as you would blacklist the sending IP for spamming. As with SPF, I expect this to be quite a lot easier than maintaining a blacklist of spamming IPs. If I'm wrong on that one point, this is useless. Would you still like more detail on what pieces of information I'm looking at, and where I'm getting them from? -- "Anarchy is based on the observation that since few are fit to rule themselves, even fewer are fit to rule others." -Edward Abbey http://www.ChaosReigns.com
Re: Spam filtering similar to SPF, less breakage
dar...@chaosreigns.com wrote: I apparently need to clarify that I think this is a good idea because I am concerned about the number of people (who control DNS records) who are very strongly against creating SPF records specifically because of forwarding breakage. The email I got in response to my request for my employer to create an SPF record included the word "abomination". From a friend. I don't entirely agree, but it is a problem for adoption. This is entirely an attempt to replicate the functionality of SPF without breaking forwarding, and without causing other problems that might discourage adoption. I set this up for my mail server (using mtx instead of designatedsender): $ host -t PTR 64.71.152.40 40.152.71.64.in-addr.arpa domain name pointer panic.chaosreigns.com. $ host -t A 40.152.71.64.mtx.panic.chaosreigns.com 40.152.71.64.mtx.panic.chaosreigns.com has address 127.0.0.1 All it took was creating a single record in bind: 40.152.71.64.mtx.panic.chaosreigns.com. IN A 127.0.0.1 I'll define it slightly differently: 127.0.0.1 is a pass (negative SA score). not found is a fail (positive SA score). 127.0.0.0 is a fail (positive SA score). Anything else is undefined (0 SA score) for future options. I'd still appreciate feedback on the format of the A record. Can you be a little more detailed on exactly which pieces of information you're looking at, and where you're getting them from? So far as I've been able to make out from your descriptions so far, this is a smallish subset of the functionality SPF provides, without the disadvantage of overloading TXT records. Consider: Spammer has control of a PC on a small(ish)-business LAN whose NAT gateway also handles their mail. (Exchange server, for instance - far too common a configuration IMO.) Spammer mail originates from 10.0.0.2 (static IP assigned by ISP). PTR record is 2.0.0.10.in-addr.arpa -> exchange.smallbusiness.com 2.0.0.10.mtx.exchange.smallbusiness.com -> 127.0.0.1 because this is the recognized designated outbound relay for Small Business's legitimate mail, and they've followed your proposal. How is the spam to be *not* considered a legitimate sender in this case? Even if the Exchange server isn't actually processing the email, its public IP will still be the originating IP of the message. SPF at least ties some aspect of the message itself to the relay IP in some way. (Whether that's good or bad I'll ignore for the moment.) -kgd
Re: Spam filtering similar to SPF, less breakage
Another point of clarification on why I think this will work: I'm running SA as a pre-queue content_filter from postfix, so when SA decides an email is spam, non-forged senders get an error, without sending backscatter to forged addresses. When I implement this, senders will get an error asking them to ask their administrator to create the necessary record. And I see no reason for that administrator not to create that record. The directions I followed to set up SA this way are half way down this page: http://wiki.apache.org/spamassassin/IntegratePostfixViaSpampd (Be sure to do the --sef and X-Envelope-From bits.) -- "I'd rather be happy than right any day." - Slartiblartfast, The Hitchhiker's Guide to the Galaxy http://www.ChaosReigns.com
Re: Spam filtering similar to SPF, less breakage
I apparently need to clarify that I think this is a good idea because I am concerned about the number of people (who control DNS records) who are very strongly against creating SPF records specifically because of forwarding breakage. The email I got in response to my request for my employer to create an SPF record included the word "abomination". From a friend. I don't entirely agree, but it is a problem for adoption. This is entirely an attempt to replicate the functionality of SPF without breaking forwarding, and without causing other problems that might discourage adoption. I set this up for my mail server (using mtx instead of designatedsender): $ host -t PTR 64.71.152.40 40.152.71.64.in-addr.arpa domain name pointer panic.chaosreigns.com. $ host -t A 40.152.71.64.mtx.panic.chaosreigns.com 40.152.71.64.mtx.panic.chaosreigns.com has address 127.0.0.1 All it took was creating a single record in bind: 40.152.71.64.mtx.panic.chaosreigns.com. IN A 127.0.0.1 I'll define it slightly differently: 127.0.0.1 is a pass (negative SA score). not found is a fail (positive SA score). 127.0.0.0 is a fail (positive SA score). Anything else is undefined (0 SA score) for future options. I'd still appreciate feedback on the format of the A record. On 02/09, RW wrote: > You've mixed-up A record and PTR record. Yes. Embarrassing. > Checking for full-circle DNS already does most of this. My home dynamic cablemodem address passes full-circle DNS. But not this. So this is far more useful for checking if an IP is a legitimate sending mail server. > What your > scheme would do is check for otherwise legitimate servers that have > been compromised and are delivering direct-to-mx. An otherwise legitimate but compromised mail server would not be detected by this. I'm curious why you interpreted it differently. On 02/09, Charles Gregory wrote: > On Mon, 2010-02-08 at 22:08 -0500, dar...@chaosreigns.com wrote: > What you describe here is functionally similar to an SPF lookup with a > 'pass' result. The server provides positive verification that the > listed IP is a legitimate sender for that domain. Yes. > As long as 'otherwise' is a definitive 'fail' response from an SPF (or > equivalent) server, and not merely an absence of SPF server Yes. Definitive "fail". > Your method would allow 'spoofing' so that a spammer who hacks a > legitimate server can use a valid return address on a different domain, > but still the mail would receive a 'passing' grade. At least, with SPF, > the spammer must forge an address on the hacked domain, which increases > the likelihood of detection Yes. I would blacklist domains that "pass" hacked servers. Just as IPs of hacked servers are blacklisted. They're sending spam, and need to be fixed. >> Forwarding doesn't break. > > Ah, so you want to allow 'legitimate' forwarding, but not allow spammers > to 'forward' their mail? Good luck with that. The only way to make it > work for the legitimate sender, but not for spammers is to have a > mechanism built-in to the forwarding server that encapsulates or rewrites > the envelope 'From' address. Encapsulating or rewriting the envelope 'From' address seems significantly less likely to be adopted from what I've read. >> Obviously you'd need a blacklist of spammer domains that list spamming >> IPs as legit senders. > > And you would be playing the same 'musical chairs' game with new domains > created by spammers on a daily basis. All the same flaws of SPF, and no > greater benefit. Same domain blacklisting issues as SPF, yes. I am not very concerned about the throw-away domains because I'll reject all mail from domains not at least 10 days old. 10+ day old domains are already listed as 127.0.2.3 records from example.com.hostkarma.junkemailfilter.com. I believe the benefit of not breaking forwarding is sufficient to make it much more useful than SPF for spam filtering. I've come across enough people, personally, recently, in trying to block (some = positive SA score) emails without an SPF "pass", who are not willing to ever implement SPF due to breaking forwarding that I believe this would be useful. >> Is there any way this wouldn't be very useful? > > Is there any place where SPF does not do the same job, other than mail > forwarding? No. But as I said, I am concerned about the potential for wide spread adoption of SPF due to forwarding breakage enough that I think this would be much more useful. On 02/09, Matus UHLAR - fantomas wrote: > On 08.02.10 22:08, dar...@chaosreigns.com wrote: > > So it's not tied to the SMTP MAIL FROM or anything. > > Forwarding doesn't break. > > What do you mean by this? > Do you want to implement new way of defining which hosts are permitted to > send e-mail? Yes. > There already are attempts to do this, with false positives and > negatives. How is this not better than the other attempts? > Yours is a bit complicated How is it complicat
Re: Spam filtering similar to SPF, less breakage
On Mon, 2010-02-08 at 22:08 -0500, dar...@chaosreigns.com wrote: You get an email delivered from 64.71.152.40 (last untrusted relay). You look up the DNS A record for that IP, and get mail.chaosreigns.com. That's a PTR lookup, but let's press on Then you look up the DNS PTR record of 40.152.71.64.designatedsender.mail.chaosreigns.com, and if it's 127.0.0.1, it's a legit email sender and gets some negative SA score. What you describe here is functionally similar to an SPF lookup with a 'pass' result. The server provides positive verification that the listed IP is a legitimate sender for that domain. Otherwise it's not, and gets some positive SA score (low at first until adoption spreads). As long as 'otherwise' is a definitive 'fail' response from an SPF (or equivalent) server, and not merely an absence of SPF server So it's not tied to the SMTP MAIL FROM or anything. Your method would allow 'spoofing' so that a spammer who hacks a legitimate server can use a valid return address on a different domain, but still the mail would receive a 'passing' grade. At least, with SPF, the spammer must forge an address on the hacked domain, which increases the likelihood of detection Forwarding doesn't break. Ah, so you want to allow 'legitimate' forwarding, but not allow spammers to 'forward' their mail? Good luck with that. The only way to make it work for the legitimate sender, but not for spammers is to have a mechanism built-in to the forwarding server that encapsulates or rewrites the envelope 'From' address. Eventually you reject all email from IPs without such records. In a perfect world. Obviously you'd need a blacklist of spammer domains that list spamming IPs as legit senders. And you would be playing the same 'musical chairs' game with new domains created by spammers on a daily basis. All the same flaws of SPF, and no greater benefit. Is there any way this wouldn't be very useful? Is there any place where SPF does not do the same job, other than mail forwarding? - Charles
Re: Spam filtering similar to SPF, less breakage
On Mon, 8 Feb 2010 22:08:10 -0500 dar...@chaosreigns.com wrote: > You get an email delivered from 64.71.152.40 (last untrusted > relay). You look up the DNS A record for that IP, and get > mail.chaosreigns.com. Then you look up the DNS PTR record of > 40.152.71.64.designatedsender.mail.chaosreigns.com, and if it's > 127.0.0.1, it's a legit email sender and gets some negative SA score. > Otherwise it's not, and gets some positive SA score (low at first > until adoption spreads). You've mixed-up A record and PTR record. Checking for full-circle DNS already does most of this. What your scheme would do is check for otherwise legitimate servers that have been compromised and are delivering direct-to-mx.
Re: Spam filtering similar to SPF, less breakage
On 08.02.10 22:08, dar...@chaosreigns.com wrote: > You get an email delivered from 64.71.152.40 (last untrusted > relay). You look up the DNS A record for that IP, and get You won't look up A records for an IP, IP address do NOT have A records. You can look up PTR (or any other record) for 40.152.71.64.in-addr.arpa. > mail.chaosreigns.com. Then you look up the DNS PTR record of > 40.152.71.64.designatedsender.mail.chaosreigns.com, and if it's > 127.0.0.1, it's a legit email sender and gets some negative SA score. Then I will look A record of mail.chaosreigns.com and see if it's 64.71.152.40. If you compare these two, you see that I need to control the same domains no matter which wsay I go. Just now I can do what you propose (and many spammers can too) but that doesn't mean my mail is legitimate. > Otherwise it's not, and gets some positive SA score (low at first until > adoption spreads). > > So it's not tied to the SMTP MAIL FROM or anything. > Forwarding doesn't break. What do you mean by this? Do you want to implement new way of defining which hosts are permitted to send e-mail? There already are attempts to do this, with false positives and negatives. Yours is a bit complicated and new which means everyone would need to implement this (otherwise he'd get false positives on his outgoing mail). Therefore I think it won't work this way. If you want to implement new way of defining which hosts are permitted to send e-mail from which domain, the same applies. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. "They say when you play that M$ CD backward you can hear satanic messages." "That's nothing. If you play it forward it will install Windows."
Re: Spam filtering similar to SPF, less breakage
ram wrote: > Apparently you want to check if non mail servers are sending mails .. > but what percentage of spams today come from non mail servers ? The vast majority, I would say. /Per Jessen, Zürich
Re: Spam filtering similar to SPF, less breakage
On Mon, 2010-02-08 at 22:08 -0500, dar...@chaosreigns.com wrote: > You get an email delivered from 64.71.152.40 (last untrusted > relay). You look up the DNS A record for that IP, and get > mail.chaosreigns.com. Then you look up the DNS PTR record of > 40.152.71.64.designatedsender.mail.chaosreigns.com, and if it's > 127.0.0.1, it's a legit email sender and gets some negative SA score. > Otherwise it's not, and gets some positive SA score (low at first until > adoption spreads). > > So it's not tied to the SMTP MAIL FROM or anything. > Forwarding doesn't break. > > Eventually you reject all email from IPs without such records. > > Obviously you'd need a blacklist of spammer domains that list spamming > IPs as legit senders. Not an RHSBL / MAIL FROM blacklist, but a blacklist > where, when the A record of a delivering IP is in a blacklisted domain, the > mail gets rejected. > > I am not at all attached to the format of the PTR record and would > like suggestions. > > > Is there any way this wouldn't be very useful? > Apparently you want to check if non mail servers are sending mails .. but what percentage of spams today come from non mail servers ?
