Re: MTX public blacklist implemented Re: MTX plugin functionally complete?
On 02/16, Charles Gregory wrote: You got it. Exactly. And that's why I gave up on MTX. Because the author was insisting that exactly that should happen. I have never recommended that the majority of people penalize email just because it doesn't get an MTX Pass, before wide spread adoption. In my initial posts I did focus too much on my hope that MTX will eventually be sufficiently widely adopted that such mail *can* safely be penalized. I also apologized for that communication failure on my part. Perhaps if you read the current version of the web page, you will be more comfortable with my intentions. It has changed quite a lot since my first post: http://www.chaosreigns.com/mtx/ -- Blessed are the cracked, for they shall let in the light. http://www.ChaosReigns.com
Re: MTX public blacklist implemented Re: MTX plugin functionally complete?
dar...@chaosreigns.com wrote: In my initial posts I did focus too much on my hope that MTX will eventually be sufficiently widely adopted that such mail *can* safely be penalized. I also apologized for that communication failure on my part. I'm still waiting for RDNS to be widely adopted enough to penalize for that. There is a lot of good email that comes from misconfigured servers. If we can't get the world to do good RDNS I don't think we can get the world to do some other more complex scheme.
Re: MTX public blacklist implemented Re: MTX plugin functionally complete?
On 02/14, Jonas Eckerman wrote: 1: The participation record is optional, so you only use it if you want everything else to be rejected. On 14.02.10 14:48, dar...@chaosreigns.com wrote: Yeah. I'm thinking of using the 4th octet to indicate participation, and the third octet to indicate delegation. If you want to check participation, you should do it on different level, e.g. check chaosreigns.com before mail.chaosreigns.com. It of course requires more DNS lookups, but note that people who do not participate, will not set ANY record so checking 127.* won't help you. Check for the MTX record first, and if it is 127.0.0.1 or 127.0.0.0 you can skip this. 4th octet: 0 Not participating. 1 (or record not defined) Participating, everything not defined is valid (like SPF neutral). 2 Participating, other stuff might be valid (like SPF softfail). 3 Participating, everything else is invalid (SPF fail). 3rd octet: 1 All MTX records are at this level. 2 All MTX records are at a subdomain. 3 Check MTX records at this level and then the subdomain. If the value of the 4th octet changes when going to a subdomain, you could say to only check the 4th octet for participating or not if the 3rd octet is 2 (all delegated to subdomain). Or you could use the most restrictive of the two records. -- 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. Where do you want to go to die? [Microsoft]
Re: MTX public blacklist implemented Re: MTX plugin functionally complete?
On Sun, 14 Feb 2010, Jonas Eckerman wrote: 1: The participation record is optional, so you only use it if you want everything else to be rejected. This is why I would support mtamark... It permits the sysadmin to determine the default behaviour for his IP range, rather than defining a dangerous default in the client. And I quote: This subdomain MAY be inserted at any level in the DNS tree for IPv4 IN-ADDR.ARPA reverse zones. For IPv6, to limit the number of DNS queries, _srv is only queried at the /128 (host), /64 (subnet) and / 32 (site) level. That way it can either provide information for a specific IP address or for a whole network block. More specific information takes precedence over information found closer to the top of the tree. The beauty of this mechanism is that we can 'sell' large ISP's on it by saying you only need to create one 'allow' entry for each legitimate MTA and one 'deny' entry for each netblock. And for SA there is no need to give it 'starting' scores, like SPF, the mechanism is effective as soon as it is used, and ignorable if not... - C
Re: MTX public blacklist implemented Re: MTX plugin functionally complete?
On Sun, 14 Feb 2010, Jonas Eckerman wrote: 1: The participation record is optional, so you only use it if you want everything else to be rejected. On 15.02.10 09:04, Charles Gregory wrote: This is why I would support mtamark... It permits the sysadmin to determine the default behaviour for his IP range, rather than defining a dangerous default in the client. And I quote: This subdomain MAY be inserted at any level in the DNS tree for IPv4 IN-ADDR.ARPA reverse zones. For IPv6, to limit the number of DNS queries, _srv is only queried at the /128 (host), /64 (subnet) and / 32 (site) level. That way it can either provide information for a specific IP address or for a whole network block. More specific information takes precedence over information found closer to the top of the tree. The beauty of this mechanism is that we can 'sell' large ISP's on it by saying you only need to create one 'allow' entry for each legitimate MTA and one 'deny' entry for each netblock. well, the ipv6 addresses are (were?) expected to be allocated by /48 blocks, so we could need check on this level too, imho. -- 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. Silvester Stallone: Father of the RISC concept.
Re: MTX public blacklist implemented Re: MTX plugin functionally complete?
Matus UHLAR - fantomas wrote: well, the ipv6 addresses are (were?) expected to be allocated by /48 blocks, so we could need check on this level too, imho. We got an IPv6 range allocated late last year, it is a /48 block. /Per Jessen, Zürich
Re: MTX public blacklist implemented Re: MTX plugin functionally complete?
On 2010-02-15 15:04, Charles Gregory wrote: On Sun, 14 Feb 2010, Jonas Eckerman wrote: 1: The participation record is optional, so you only use it if you want everything else to be rejected. This is why I would support mtamark... It permits the sysadmin to determine the default behaviour for his IP range, rather than defining a dangerous default in the client. In what way does the above define a dangerous default? The default in the statement above is to consider a domain as *not* participating unless otherwise stated by whoever manages the DNS for the domain. If the domain does not participate it should not be punished when a MTX record isn't found. 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 public blacklist implemented Re: MTX plugin functionally complete?
On Tue, 16 Feb 2010, Jonas Eckerman wrote: 1: The participation record is optional, so you only use it if you want everything else to be rejected. This is why I would support mtamark... It permits the sysadmin to determine the default behaviour for his IP range, rather than defining a dangerous default in the client. In what way does the above define a dangerous default? It doesn't. My comment refers to early messages where the author of 'mtx' said that the 'standard' behaviour in the absence of any mtx record as being equivalent to a 'deny' condition. That is, the domain would be scored as 'spammish' if it did not participate. The default in the statement above is to consider a domain as *not* participating unless otherwise stated by whoever manages the DNS for the domain. Correct. And my comment was that this was a much better alternative to the 'dangerous default' of having 'not participating' mean 'spammy'. If the domain does not participate it should not be punished when a MTX record isn't found. You got it. Exactly. And that's why I gave up on MTX. Because the author was insisting that exactly that should happen. - C
MTX public blacklist implemented Re: MTX plugin functionally complete?
Very simple, via HTTP and a small perl script: http://www.chaosreigns.com/mtx/#blacklist It's currently empty. On 02/14, 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. 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. I remembered why (else) I didn't want to do that. It effectively says Everything else should be rejected. Which will discourage some people from using it. So you would at least need to provide a way to say Yes, I'm participating, but anything without an MTX record is valid too. Still needs further consideration. -- 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 public blacklist implemented Re: MTX plugin functionally complete?
On 2010-02-14 20:06, dar...@chaosreigns.com wrote: I remembered why (else) I didn't want to do that. It effectively says Everything else should be rejected. Which will discourage some people from using it. So you would at least need to provide a way to say Yes, I'm participating, but anything without an MTX record is valid too. The first two solutions for this that pops into my head: 1: The participation record is optional, so you only use it if you want everything else to be rejected. 2: Make it a policy record rather than a participation record, so you can specify more stuff. Either a TXT record or a bitmaped A record for example. Call it _policy._mtx.*. More on the other very valid concerns later about this... 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 public blacklist implemented Re: MTX plugin functionally complete?
On 02/14, Jonas Eckerman wrote: 1: The participation record is optional, so you only use it if you want everything else to be rejected. Yeah. I'm thinking of using the 4th octet to indicate participation, and the third octet to indicate delegation. Check for the MTX record first, and if it is 127.0.0.1 or 127.0.0.0 you can skip this. 4th octet: 0 Not participating. 1 (or record not defined) Participating, everything not defined is valid (like SPF neutral). 2 Participating, other stuff might be valid (like SPF softfail). 3 Participating, everything else is invalid (SPF fail). 3rd octet: 1 All MTX records are at this level. 2 All MTX records are at a subdomain. 3 Check MTX records at this level and then the subdomain. If the value of the 4th octet changes when going to a subdomain, you could say to only check the 4th octet for participating or not if the 3rd octet is 2 (all delegated to subdomain). Or you could use the most restrictive of the two records. Still not feeling like I swallowed a cat. I think it could cause slower adoption to ask people to Create this one record for all of your servers, and decide if you want to create this complicated hierarchical thing defining your participation. Perhaps spec out a version 2 including this to be implemented at a later time? 2: Make it a policy record rather than a participation record, so you can specify more stuff. Either a TXT record or a bitmaped A record for example. Call it _policy._mtx.*. That sounds likely to get complicated. Details? -- Whatever you do will be insignificant, but it is very important that you do it. - Mahatma Gandhi http://www.ChaosReigns.com
