Re: problem dealing w/ ietf.org mail servers
On 8 jul 2008, at 20.41, Keith Moore wrote: 1) I do understand where the current last 64 bits are EUId comes from. 2) Someone (I think it was Keith Moore) said that if the scheme doesn't work for servers AND hosts (i.e no difference) it's a bad scheme. I sort of agree with that, but the reason it doesn't work for servers is simply lack of management tools, and the fact that a lot of protocols / implementations tend to use addresses rather than names. I disagree that it doesn't work for servers. (Or it would be better to say that I'd like to know why you think it doesn't work for servers.) Well, when I change that broken NIC in my server, it will receive a new address that needs to be reflected in the DNS. Sure, that can be automated or updated, but in general you want some stability in the server address. I have actually run my personal mail-server on an EUI-64 address for quite some time. The problem when the NIC failed was that it took until the cache expiry for some servers to contact it again. Like ietf.org. There are other addresses, like router interfaces where EUI64 addresses are simply a nightmare, as when you are doing network troubleshooting you need to keep 128 bits in HEX in memory - which I am too stupid to be able to...an alternative would be to have routing tables do DNS lookups for NEXT_HOPS - it's just a lot of DNS lookups Best regards, - kurtis - ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: problem dealing w/ ietf.org mail servers
Kurt Erik Lindqvist wrote: On 8 jul 2008, at 20.41, Keith Moore wrote: [..] I disagree that it doesn't work for servers. (Or it would be better to say that I'd like to know why you think it doesn't work for servers.) People have personal opinions, one likes this, the other likes that, maybe it works for you, maybe it works different for me. Well, when I change that broken NIC in my server, it will receive a new address that needs to be reflected in the DNS. Which is why EUI-64 is a great method on combination with RA to do autoconfiguration, but if somebody (for whatever reason they have) want to use those 64bits differently (eg using DHCP or static config) they should definitely do so, it is their network after all, and there is no meaning in those bits. EUI-64/RA is just to make some cases (the dental office one for instance) really simply, but it is not a solution for everything else. Pick and use what is useful... BTW: Most OS's allow overriding of the MAC address, next to of course just configing an automatic EUI-64 address as a static one on an interface ;) Your network, your rules, your problem if you peep it up. Greets, Jeroen signature.asc Description: OpenPGP digital signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: problem dealing w/ ietf.org mail servers
(Apologies for the late reply) On 4 jul 2008, at 15.10, John C Klensin wrote: --On Friday, 04 July, 2008 10:46 +0200 Kurt Erik Lindqvist [EMAIL PROTECTED] wrote: On 3 jul 2008, at 15.57, Jeroen Massar wrote: On Wed, Jul 02, 2008 at 10:47:53PM -0700, 'kent' wrote: [..] However, this last address, 2001:470:1:76:2c0:9fff:fe3e:4009, is not explicitly configured on the sending server; instead, it is being implicitly configured through ip6 autoconf stuff: Which (autoconfig) you should either not be using on servers, or you should be configuring your software properly to select the correct outbound address. (I prefer to use the autoconfig one for 'management' and using a 'service address' for the service). What a shame that's not what's in the RFCs..:-) Despite the :-), I think there is an important question here. Does it imply that this is a use case from which we should be learning... and then fixing the RFCs? Or that you believe that the RFCs are correct and Jeroen's analysis is incorrect? I hope it doesn't mean the RFCs ought to govern, even when reality and experience seem to contradict them. So, from my POV there are a few issues here. 1) I do understand where the current last 64 bits are EUId comes from. 2) Someone (I think it was Keith Moore) said that if the scheme doesn't work for servers AND hosts (i.e no difference) it's a bad scheme. I sort of agree with that, but the reason it doesn't work for servers is simply lack of management tools, and the fact that a lot of protocols / implementations tend to use addresses rather than names. 2) In operational reality, I have learnt that EUI64 for workstations and similar hosts in combination with non EUI64 numbers for servers works quite well and is how I work with deployments. And I have a lot of respect for operational experience and reality. So yes, I think this is worth considering. Do I believe such a rule can be written clearly and get IETF consensusthat is a different question. Best regards, - kurtis - ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: problem dealing w/ ietf.org mail servers
1) I do understand where the current last 64 bits are EUId comes from. 2) Someone (I think it was Keith Moore) said that if the scheme doesn't work for servers AND hosts (i.e no difference) it's a bad scheme. I sort of agree with that, but the reason it doesn't work for servers is simply lack of management tools, and the fact that a lot of protocols / implementations tend to use addresses rather than names. I disagree that it doesn't work for servers. (Or it would be better to say that I'd like to know why you think it doesn't work for servers.) Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: problem dealing w/ ietf.org mail servers
surely we in the IETF should be able to do better than to have our mail servers filter incoming mail based on completely irrelevant criteria like whether a PTR lookup succeeds! Spam filtering is sort of like chemotherapy, the difference between the good and the bad is pretty small, and the trick is to find measures that will kill the disease without killing the patient. It's entirely a matter of statistics, not fundamental design. And sort of not like it at all. For one thing, the mutation rate in the spam world is much higher. And that brings us to the real issue here: Whether or not a given technique, which was very effective indeed at one point, is effective enough now to continue using. I can assure you that in the outside world, the amount of legitimate mail that comes from no-PTR hosts these days is infinitesimal. And in my experience the amount of spam coming from such sources, while much greater, is now distinctly in the minority in terms of all incoming spam. More specifically, since rather than rejecting mail coming from IPs with no PTR entry I instead use this as a weighted factor in computing an overall spam score, I was able to examine today's spam to see to what extent this check is helping or hurting. Turns out it's doing neither - I could eliminate it entirely and my false negative rate would not go up by even a single message. And right now the weight is sufficiently low that it isn't causing any false positives either. This defense definitely was very effective once upon a time, but the world has adapted. In this particular case what seems to have happened is that because of various PTR record checks a lot of ISPs now unconditionally assign PTR records to every address, e.g., cpe-76-171-209-109.socal.res.rr.com and 173.sub-75-217-87.myvzw.com were associated with the last two dynamic IPs I've used. A few years ago it was common to get assigned IP with no PTR records at all, nowdays much less so. And this has now led to a new issue: We now have various systems out there that are now attempting to parse PTR results order to try and figure out the difference between static business addresses and dynamic residential addresses. And as you might expect, they often get it wrong. Now, of course one advantage of this check is that it can be done before you even accept the message. But the tradeoff then is that this is giving it infinite weight. It's one of the filtering rules with the lowest false positive rates. Other than temporary glitches like the 6-to-4 one, the only place where I see problems is from auld pharts like us whose mail systems have been working just fine since the 1980s, and who out of a weird sort of principle refuse to make changes to bring them in line with modern practice, even changes that are compatible with equally ancient STD documents. So, yeah, spam stinks, but it's not going away, and arguments that you shouldn't use a technique today because it didn't work in 1998 don't cut it. Nor does continuing to use a technique that has outlived it's usefulness. IMO the utility of this particular check peaked a few years ago and we're now on the down-slope in terms of utility. And in the specific case of the IETF, where we want to encourage people to use our servers to experiment with IPv6 and where there are bound to be a lot of PTR record issues, I think an absolute block on the basis of no PTR record is totally inappropriate unless it can be shown to be singularly effective in dealing with spam and that our spam would increase dramatically without the rule. I doubt very much this can be demonstrated. OTOH, using it as a component in computing an overall spam score may still make sense, especially if the use of IPv6 could also be factored in. Ned ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: problem dealing w/ ietf.org mail servers
Ned Freed wrote: Spam filtering is sort of like chemotherapy, the difference between the good and the bad is pretty small, and the trick is to find measures that will kill the disease without killing the patient. It's entirely a matter of statistics, not fundamental design. And sort of not like it at all. For one thing, the mutation rate in the spam world is much higher. And that brings us to the real issue here: Whether or not a given technique, which was very effective indeed at one point, is effective enough now to continue using. At base, this requires distinguishing between techniques that are heuristics, and therefore fickle, versus techniques that can be stable over the long term. The former are used to detect bad actors. The latter can apply for handling good actors. The bad actors are indeed bright, well organized, aggressive and very, very adaptable. Any use of heuristics must therefore be extremely agile. The diligence and expertise this requires is onerous. Typically, only the largest services can afford to do this in-house. By contrast, a trust overlay, based on prior assessment of good actors, ought to be much lower overhead and much more stable. However we have less experience with this side of the equation. This defense definitely was very effective once upon a time, but the world has adapted. Exactly. Nor does continuing to use a technique that has outlived it's usefulness. Exactly. And in the specific case of the IETF, where we want to encourage people to use our servers to experiment with IPv6 and where there are bound to be a lot of PTR record issues, I think an absolute block on the basis of no PTR record is totally inappropriate +1 d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: problem dealing w/ ietf.org mail servers
On 3 jul 2008, at 15:57, Jeroen Massar wrote: Which (autoconfig) you should either not be using on servers, or you should be configuring your software properly to select the correct outbound address. Is it the IETF's job to tell people how to run their networks? In my opinion, stateless autoconfig is a perfectly acceptable way to configure servers. SMTP shows that it is perfectly usable for these situations as it nicely rejects the message with a proper message automatically telling you on how to solve it. I ran into the issue with the non-existant IPv6 reverse mapping twice. I would prefered to have solved this by getting proper delegation from my ISP, but I haven't been able to get this done for years. Anyway, the first time I opened a ticket they told me it was fixed. Then the problem returned and they told me I was put on a whitelist. As this thread indicates, that's hardly a solution, especially since I was unable to get Sendmail to NOT use IPv6 without completely disabling the protocol on my system, making it completely impossible for me to deliver mail to the IETF servers. (Serves me right for running Sendmail I guess.) Those boxes are not set up correctly thus should not be sending email in the first place. For that matter you should actually be firewalling+logging port 25 outbound so you can monitor any host in your network doing illegal SMTP connects. In my opinion, filtering at layer 4 because a layer 7 protocol is broken is a bad idea. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: problem dealing w/ ietf.org mail servers
In your previous mail you wrote: Specifically, the problem Dave encountered earlier was that the ietf mail server was rejecting mail without reverse dns, and since the ietf mail server and the mipassoc.org/dkim.org/bbiw.net mail servers all had ip6 addresses, and ip6 is used preferentially, and I hadn't set up reverse dns, they were dropping all mail. I fixed that, and things started working. = I had the same problem (IPv6, no reverse, dropped messages), I asked the IETF postmaster to fix it and it was (quickly, thanks) fixed. But I still believe this is a bad idea to check IPv6 reverse DNS, I reverved this topics for the plenary at Dublin but as you open it... PS -- I'm not sure this will actually make it to the ietf list :-) ... = according to Glen via RT (RT is a well known bug ticket system): This check is in place at the direction of the IETF community, and has been discussed and debated at length. so as the IETF community voice is this list IMHO it is appropriate (until some authority delegates the issue to the v6ops WG?). Thanks [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: problem dealing w/ ietf.org mail servers
= according to Glen via RT (RT is a well known bug ticket system): This check is in place at the direction of the IETF community, and has been discussed and debated at length. I don't recall the Last Call on that question, nor even the I-D. seems like this calls into question the competence of the people running IETF's servers. they really ought to know better than to accept random rumors as technical advice. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: problem dealing w/ ietf.org mail servers
At 09:28 07-07-2008, Francis Dupont wrote: = according to Glen via RT (RT is a well known bug ticket system): This check is in place at the direction of the IETF community, and has been discussed and debated at length. I don't recall seeing any community debate before this check was implemented. Can someone point me to that thread? Regards, -sm ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: problem dealing w/ ietf.org mail servers
I think I could have been clearer with my message. It wasn't intended as either a criticism of the ietf list management (in fact, I use precisely the same anti-spam technique) or a request for help with configuration of my mailservers (I may not be the sharpest knife in the drawer, but usually I can figure these things out on my own). Instead, I was presenting what I thought was an interesting example of a subtle problem that can come up in ipv6 deployment. The mailserver in question uses a default redhat enterprise build (actually centos). ipv6 is either enabled by default, or just has a single check box, with no further information. The fact that ipv6 is enabled so trivially carries the implication that just enabling ipv6 won't actually damage anything. Now I know different. Just enabling ipv6 on an otherwise correctly configured and functioning ipv4 box *will* cause damage -- it will cause mail that would have been delivered to not be delivered. I could be wrong, but this strikes me as a trap that lots of people could fall into. As I mentioned, my servers actually do reject mail if they can't find a reverse dns for the senders IP. Some of those servers use ipv6; in light of all this I'm going to have to rethink that decision. For a server, the combination of enabling ipv6 and using this particular anti-spam technique may drastically increase the number of false positives -- especially as ipv6 gets more widely deployed. Best Regards Kent ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: problem dealing w/ ietf.org mail servers
On 3 jul 2008, at 15.57, Jeroen Massar wrote: On Wed, Jul 02, 2008 at 10:47:53PM -0700, 'kent' wrote: [..] However, this last address, 2001:470:1:76:2c0:9fff:fe3e:4009, is not explicitly configured on the sending server; instead, it is being implicitly configured through ip6 autoconf stuff: Which (autoconfig) you should either not be using on servers, or you should be configuring your software properly to select the correct outbound address. (I prefer to use the autoconfig one for 'management' and using a 'service address' for the service). What a shame that's not what's in the RFCs..:-) Best regards, - kurtis - ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: problem dealing w/ ietf.org mail servers
On 3 jul 2008, at 15.57, Jeroen Massar wrote: On Wed, Jul 02, 2008 at 10:47:53PM -0700, 'kent' wrote: [..] However, this last address, 2001:470:1:76:2c0:9fff:fe3e:4009, is not explicitly configured on the sending server; instead, it is being implicitly configured through ip6 autoconf stuff: Which (autoconfig) you should either not be using on servers, or you should be configuring your software properly to select the correct outbound address. (I prefer to use the autoconfig one for 'management' and using a 'service address' for the service). What a shame that's not what's in the RFCs..:-) Best regards, - kurtis - ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: problem dealing w/ ietf.org mail servers
--On Friday, 04 July, 2008 10:46 +0200 Kurt Erik Lindqvist [EMAIL PROTECTED] wrote: On 3 jul 2008, at 15.57, Jeroen Massar wrote: On Wed, Jul 02, 2008 at 10:47:53PM -0700, 'kent' wrote: [..] However, this last address, 2001:470:1:76:2c0:9fff:fe3e:4009, is not explicitly configured on the sending server; instead, it is being implicitly configured through ip6 autoconf stuff: Which (autoconfig) you should either not be using on servers, or you should be configuring your software properly to select the correct outbound address. (I prefer to use the autoconfig one for 'management' and using a 'service address' for the service). What a shame that's not what's in the RFCs..:-) Despite the :-), I think there is an important question here. Does it imply that this is a use case from which we should be learning... and then fixing the RFCs? Or that you believe that the RFCs are correct and Jeroen's analysis is incorrect? I hope it doesn't mean the RFCs ought to govern, even when reality and experience seem to contradict them. john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: problem dealing w/ ietf.org mail servers
John C Klensin wrote: --On Friday, 04 July, 2008 10:46 +0200 Kurt Erik Lindqvist [EMAIL PROTECTED] wrote: On 3 jul 2008, at 15.57, Jeroen Massar wrote: [..] Which (autoconfig) you should either not be using on servers, or you should be configuring your software properly to select the correct outbound address. (I prefer to use the autoconfig one for 'management' and using a 'service address' for the service). What a shame that's not what's in the RFCs..:-) Despite the :-), I think there is an important question here. Does it imply that this is a use case from which we should be learning... and then fixing the RFCs? Or that you believe that the RFCs are correct and Jeroen's analysis is incorrect? I guess/hope he is just teasing ;) As I privately replied to Kurt already, RFCs are Requests For Comments, as such what I am giving is definitely a comment, and the only way to solve it for real and to give some guidance is to move this problem to v6ops (which I think is the most appropriate WG) and document scenarios that guide people on how to possibly configure a network using IPv6. Of course people could also just get a good book and/or use common sense, unfortunately that is not always happening, especially the latter. I hope it doesn't mean the RFCs ought to govern, even when reality and experience seem to contradict them. See my message to ietf@ + v6ops@ titled: Draft on how to correctly configure servers and other hosts (IPv4+IPv6) (Was: problem dealing w/ ietf.org mail servers) As RFC's can be updated as much as we want and they definitely are not final. Greets, Jeroen signature.asc Description: OpenPGP digital signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: problem dealing w/ ietf.org mail servers
[EMAIL PROTECTED] wrote: I think I could have been clearer with my message. It wasn't intended as either a criticism of the ietf list management (in fact, I use precisely the same anti-spam technique) or a request for help with configuration of my mailservers (I may not be the sharpest knife in the drawer, but usually I can figure these things out on my own). Instead, I was presenting what I thought was an interesting example of a subtle problem that can come up in ipv6 deployment. The mailserver in question uses a default redhat enterprise build (actually centos). ipv6 is either enabled by default, or just has a single check box, with no further information. The fact that ipv6 is enabled so trivially carries the implication that just enabling ipv6 won't actually damage anything. Now I know different. Just enabling ipv6 on an otherwise correctly configured and functioning ipv4 box *will* cause damage -- it will cause mail that would have been delivered to not be delivered. I could be wrong, but this strikes me as a trap that lots of people could fall into. that's one way to look at it. another way to look at it is that poorly chosen spam filtering criteria *will* cause damage, because conditions in the Internet change over time. of course, IPv6 will often get blamed for the problem because it's something that the sender can control, whereas the spam filters are not accountable to anyone. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: problem dealing w/ ietf.org mail servers
On Fri, Jul 04, 2008 at 10:53:41AM -0400, Keith Moore wrote: Now I know different. Just enabling ipv6 on an otherwise correctly configured and functioning ipv4 box *will* cause damage -- it will cause mail that would have been delivered to not be delivered. I could be wrong, but this strikes me as a trap that lots of people could fall into. that's one way to look at it. another way to look at it is that poorly chosen spam filtering criteria *will* cause damage, because conditions in the Internet change over time. Can't disagree with that :-) In fact, I've never been very happy with this particular technique for dealing with spam. Reverse dns is not required for standards-compliant delivery of mail, and it is my personal opinion that the ietf in particular should not be using it as an absolute filtering criteria. [Also, in my experience it hasn't been particularly effective.] of course, IPv6 will often get blamed for the problem because it's something that the sender can control, whereas the spam filters are not accountable to anyone. That's a bit of an overstatement -- very frequently spam filters are accountable to the people receiving the email, and in my experience, most people would rather deal with some spam than lose important email. Kent ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: problem dealing w/ ietf.org mail servers
Hi Rich I'll cc this to the ietf list, as you suggested. I've found the problem. It may or may not be something that ietf want's to do something about -- I would think they would, since it seems to have global significance. But I can fix it from this end. Specifically, the problem Dave encountered earlier was that the ietf mail server was rejecting mail without reverse dns, and since the ietf mail server and the mipassoc.org/dkim.org/bbiw.net mail servers all had ip6 addresses, and ip6 is used preferentially, and I hadn't set up reverse dns, they were dropping all mail. I fixed that, and things started working. The only domains I control that had explicit ipv6 addresses were Dave's domains. For example, graybeards.net: # host graybeards.net graybeards.net has address 72.52.113.69 graybeards.net has IPv6 address 2001:470:1:76:0::4834:7145 graybeards.net mail is handled by 10 mail.graybeards.net. # host mail.graybeards.net mail.graybeards.net has address 72.52.113.69 mail.graybeards.net has IPv6 address 2001:470:1:76:0::4834:7145 # host 2001:470:1:76:0::4834:7145 5.4.1.7.4.3.8.4.f.f.f.f.0.0.0.0.6.7.0.0.1.0.0.0.0.7.4.0.1.0.0.2.ip6.arpa domain name pointer mail.graybeards.net. # Mail now works for this domain. But, it turns out, the ietf.org mail servers are rejecting mail from other domains as well. Here's a log entry for one of your messages: Jul 2 13:10:23 mail sendmail[31264]: STARTTLS=client, relay=mail.ietf.org., version=TLSv1/SSLv3, verify=FAIL, cipher=DHE-RSA-AES256-SHA, bits=256/256 Jul 2 13:10:29 mail sendmail[31264]: m62Hvfbm011799: to=[EMAIL PROTECTED], ctladdr=[EMAIL PROTECTED] (1023/1023), delay=02:12:32, xdelay=00:00:28 , mailer=esmtp, pri=662167, relay=mail.ietf.org. [IPv6:2001:1890:1112:1::20 ], dsn=4.7.1, stat=Deferred: 450 4.7.1 Client host rejected: cannot find your reverse h ostname, [2001:470:1:76:2c0:9fff:fe3e:4009] Rejecting when you can't find a reverse is, of course, a common anti-spam technique. And has false positives. However, this last address, 2001:470:1:76:2c0:9fff:fe3e:4009, is not explicitly configured on the sending server; instead, it is being implicitly configured through ip6 autoconf stuff: eth0 Link encap:Ethernet HWaddr 00:C0:9F:3E:40:09 inet addr:72.52.113.176 Bcast:72.52.113.255 Mask:255.255.255. 0 inet6 addr: fe80::2c0:9fff:fe3e:4009/64 Scope:Link inet6 addr: 2001:470:1:76:2c0:9fff:fe3e:4009/64 Scope:Global The 2 ip6 addresses, the link-local address, and the global address, are generated from the mac address (you can see the 0x4009 at the end) and configured autmomatically, merely because ipv6 is enabled on this box by default, and a global prefix is available. That is to say, it appears the ietf.org mail server is probably now rejecting mail from *any* box that is getting a default global ipv6 address, since those addresses will most likely not be in ip6.arpa. There may be a whole lot of boxes in this situation. Well Windows boxes will auto register their main address in the DNS so there won't be as many as you think. It's not hard to auto register in the reverse DNS. TCP is usually a strong enough authenticator to add a PTR record. 6to4 only requires a TCP connection to set up the reverse delegation. Mark Kent PS -- I'm not sure this will actually make it to the ietf list :-) ... ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: problem dealing w/ ietf.org mail servers
surely we in the IETF should be able to do better than to have our mail servers filter incoming mail based on completely irrelevant criteria like whether a PTR lookup succeeds! how can we expect the rest of the network to be sane if we can't even use reasonable criteria for our spam filtering on our own servers? (to those who would respond by saying that this is a common technique, I'd like to cite a sign that I saw many years ago which is totally apropos: mediocrity is excellence at pursuing the mean and there's no better way to pursue the mean that to do something just because it's common.) Keith 'kent' wrote: Hi Rich I'll cc this to the ietf list, as you suggested. I've found the problem. It may or may not be something that ietf want's to do something about -- I would think they would, since it seems to have global significance. But I can fix it from this end. Specifically, the problem Dave encountered earlier was that the ietf mail server was rejecting mail without reverse dns, and since the ietf mail server and the mipassoc.org/dkim.org/bbiw.net mail servers all had ip6 addresses, and ip6 is used preferentially, and I hadn't set up reverse dns, they were dropping all mail. I fixed that, and things started working. The only domains I control that had explicit ipv6 addresses were Dave's domains. For example, graybeards.net: # host graybeards.net graybeards.net has address 72.52.113.69 graybeards.net has IPv6 address 2001:470:1:76:0::4834:7145 graybeards.net mail is handled by 10 mail.graybeards.net. # host mail.graybeards.net mail.graybeards.net has address 72.52.113.69 mail.graybeards.net has IPv6 address 2001:470:1:76:0::4834:7145 # host 2001:470:1:76:0::4834:7145 5.4.1.7.4.3.8.4.f.f.f.f.0.0.0.0.6.7.0.0.1.0.0.0.0.7.4.0.1.0.0.2.ip6.arpa domain name pointer mail.graybeards.net. # Mail now works for this domain. But, it turns out, the ietf.org mail servers are rejecting mail from other domains as well. Here's a log entry for one of your messages: Jul 2 13:10:23 mail sendmail[31264]: STARTTLS=client, relay=mail.ietf.org., version=TLSv1/SSLv3, verify=FAIL, cipher=DHE-RSA-AES256-SHA, bits=256/256 Jul 2 13:10:29 mail sendmail[31264]: m62Hvfbm011799: to=[EMAIL PROTECTED], ctladdr=[EMAIL PROTECTED] (1023/1023), delay=02:12:32, xdelay=00:00:28, mailer=esmtp, pri=662167, relay=mail.ietf.org. [IPv6:2001:1890:1112:1::20], dsn=4.7.1, stat=Deferred: 450 4.7.1 Client host rejected: cannot find your reverse hostname, [2001:470:1:76:2c0:9fff:fe3e:4009] Rejecting when you can't find a reverse is, of course, a common anti-spam technique. However, this last address, 2001:470:1:76:2c0:9fff:fe3e:4009, is not explicitly configured on the sending server; instead, it is being implicitly configured through ip6 autoconf stuff: eth0 Link encap:Ethernet HWaddr 00:C0:9F:3E:40:09 inet addr:72.52.113.176 Bcast:72.52.113.255 Mask:255.255.255.0 inet6 addr: fe80::2c0:9fff:fe3e:4009/64 Scope:Link inet6 addr: 2001:470:1:76:2c0:9fff:fe3e:4009/64 Scope:Global The 2 ip6 addresses, the link-local address, and the global address, are generated from the mac address (you can see the 0x4009 at the end) and configured autmomatically, merely because ipv6 is enabled on this box by default, and a global prefix is available. That is to say, it appears the ietf.org mail server is probably now rejecting mail from *any* box that is getting a default global ipv6 address, since those addresses will most likely not be in ip6.arpa. There may be a whole lot of boxes in this situation. Kent PS -- I'm not sure this will actually make it to the ietf list :-) ... ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: problem dealing w/ ietf.org mail servers
you are not the first to report this problem. On Wed, Jul 02, 2008 at 10:47:53PM -0700, 'kent' wrote: Hi Rich I'll cc this to the ietf list, as you suggested. I've found the problem. It may or may not be something that ietf want's to do something about -- I would think they would, since it seems to have global significance. But I can fix it from this end. Specifically, the problem Dave encountered earlier was that the ietf mail server was rejecting mail without reverse dns, and since the ietf mail server and the mipassoc.org/dkim.org/bbiw.net mail servers all had ip6 addresses, and ip6 is used preferentially, and I hadn't set up reverse dns, they were dropping all mail. I fixed that, and things started working. The only domains I control that had explicit ipv6 addresses were Dave's domains. For example, graybeards.net: # host graybeards.net graybeards.net has address 72.52.113.69 graybeards.net has IPv6 address 2001:470:1:76:0::4834:7145 graybeards.net mail is handled by 10 mail.graybeards.net. # host mail.graybeards.net mail.graybeards.net has address 72.52.113.69 mail.graybeards.net has IPv6 address 2001:470:1:76:0::4834:7145 # host 2001:470:1:76:0::4834:7145 5.4.1.7.4.3.8.4.f.f.f.f.0.0.0.0.6.7.0.0.1.0.0.0.0.7.4.0.1.0.0.2.ip6.arpa domain name pointer mail.graybeards.net. # Mail now works for this domain. But, it turns out, the ietf.org mail servers are rejecting mail from other domains as well. Here's a log entry for one of your messages: Jul 2 13:10:23 mail sendmail[31264]: STARTTLS=client, relay=mail.ietf.org., version=TLSv1/SSLv3, verify=FAIL, cipher=DHE-RSA-AES256-SHA, bits=256/256 Jul 2 13:10:29 mail sendmail[31264]: m62Hvfbm011799: to=[EMAIL PROTECTED], ctladdr=[EMAIL PROTECTED] (1023/1023), delay=02:12:32, xdelay=00:00:28, mailer=esmtp, pri=662167, relay=mail.ietf.org. [IPv6:2001:1890:1112:1::20], dsn=4.7.1, stat=Deferred: 450 4.7.1 Client host rejected: cannot find your reverse hostname, [2001:470:1:76:2c0:9fff:fe3e:4009] Rejecting when you can't find a reverse is, of course, a common anti-spam technique. However, this last address, 2001:470:1:76:2c0:9fff:fe3e:4009, is not explicitly configured on the sending server; instead, it is being implicitly configured through ip6 autoconf stuff: eth0 Link encap:Ethernet HWaddr 00:C0:9F:3E:40:09 inet addr:72.52.113.176 Bcast:72.52.113.255 Mask:255.255.255.0 inet6 addr: fe80::2c0:9fff:fe3e:4009/64 Scope:Link inet6 addr: 2001:470:1:76:2c0:9fff:fe3e:4009/64 Scope:Global The 2 ip6 addresses, the link-local address, and the global address, are generated from the mac address (you can see the 0x4009 at the end) and configured autmomatically, merely because ipv6 is enabled on this box by default, and a global prefix is available. That is to say, it appears the ietf.org mail server is probably now rejecting mail from *any* box that is getting a default global ipv6 address, since those addresses will most likely not be in ip6.arpa. There may be a whole lot of boxes in this situation. Kent PS -- I'm not sure this will actually make it to the ietf list :-) ... ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- --bill Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise). ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: problem dealing w/ ietf.org mail servers
On Wed, Jul 02, 2008 at 10:47:53PM -0700, 'kent' wrote: [..] However, this last address, 2001:470:1:76:2c0:9fff:fe3e:4009, is not explicitly configured on the sending server; instead, it is being implicitly configured through ip6 autoconf stuff: Which (autoconfig) you should either not be using on servers, or you should be configuring your software properly to select the correct outbound address. (I prefer to use the autoconfig one for 'management' and using a 'service address' for the service). SMTP shows that it is perfectly usable for these situations as it nicely rejects the message with a proper message automatically telling you on how to solve it. That is to say, it appears the ietf.org mail server is probably now rejecting mail from *any* box that is getting a default global ipv6 address, since those addresses will most likely not be in ip6.arpa. There may be a whole lot of boxes in this situation. Those boxes are not set up correctly thus should not be sending email in the first place. For that matter you should actually be firewalling+logging port 25 outbound so you can monitor any host in your network doing illegal SMTP connects. Spam bots don't use IPv6 yet (afaik), but when they are aware how 'open' everything is and especially that RBL's don't exist yadda yadda, they might just switch over to that. Good that the mainstream spamreceivers (gmail/yahoo/etc) don't have IPv6 yet as that would change that scenario. Configure your mailservers correctly, it helps you send out mail, and it helps avoid others receiving crap from you. Greets, Jeroen -- For postfix folks: http://www.postfix.org/IPV6_README.html 8 /etc/postfix/main.cf: smtp_bind_address6 = 2001:240:587:0:250:56ff:fe89:1 8 Other SMTP servers have similar mechanisms. signature.asc Description: OpenPGP digital signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: problem dealing w/ ietf.org mail servers
surely we in the IETF should be able to do better than to have our mail servers filter incoming mail based on completely irrelevant criteria like whether a PTR lookup succeeds! Spam filtering is sort of like chemotherapy, the difference between the good and the bad is pretty small, and the trick is to find measures that will kill the disease without killing the patient. It's entirely a matter of statistics, not fundamental design. I can assure you that in the outside world, the amount of legitimate mail that comes from no-PTR hosts these days is infinitesimal. It's one of the filtering rules with the lowest false positive rates. Other than temporary glitches like the 6-to-4 one, the only place where I see problems is from auld pharts like us whose mail systems have been working just fine since the 1980s, and who out of a weird sort of principle refuse to make changes to bring them in line with modern practice, even changes that are compatible with equally ancient STD documents. So, yeah, spam stinks, but it's not going away, and arguments that you shouldn't use a technique today because it didn't work in 1998 don't cut it. Regards, John Levine, [EMAIL PROTECTED], Primary Perpetrator of The Internet for Dummies, Information Superhighwayman wanna-be, http://www.johnlevine.com, ex-Mayor More Wiener schnitzel, please, said Tom, revealingly. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: problem dealing w/ ietf.org mail servers
Bill Manning wrote: you are not the first to report this problem. 1. From what I can tell, the only way to know about the reporting form is to have seen it on the Announce list. I certainly cannot see anything from the ietf.org page that is relevant. I think the page needs some sort of IETF network admin link, pointing to such information. 2. I suspect it would be helpful for the page it points to to list open issues. Some sort of tracker. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: problem dealing w/ ietf.org mail servers
Jeroen Massar wrote: On Wed, Jul 02, 2008 at 10:47:53PM -0700, 'kent' wrote: [..] However, this last address, 2001:470:1:76:2c0:9fff:fe3e:4009, is not explicitly configured on the sending server; instead, it is being implicitly configured through ip6 autoconf stuff: Which (autoconfig) you should either not be using on servers, or you should be configuring your software properly to select the correct outbound address. that's a bizarre statement. the distinction between a client and a server is an artificial one. either autoconfig is useful for all kinds of machines, or it's almost useless. (I prefer to use the autoconfig one for 'management' and using a 'service address' for the service). SMTP shows that it is perfectly usable for these situations as it nicely rejects the message with a proper message automatically telling you on how to solve it. ... and the message almost always goes to someone who isn't in a position to fix the problem. That is to say, it appears the ietf.org mail server is probably now rejecting mail from *any* box that is getting a default global ipv6 address, since those addresses will most likely not be in ip6.arpa. There may be a whole lot of boxes in this situation. Those boxes are not set up correctly thus should not be sending email in the first place. people have strange ideas about what is correct setup. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: problem dealing w/ ietf.org mail servers
John Levine wrote: surely we in the IETF should be able to do better than to have our mail servers filter incoming mail based on completely irrelevant criteria like whether a PTR lookup succeeds! Spam filtering is sort of like chemotherapy, the difference between the good and the bad is pretty small, and the trick is to find measures that will kill the disease without killing the patient. the analogy falls apart because in most cases there's no recovery from a spam filter - if a message it's filtered inappropriately, it's killed. It's entirely a matter of statistics, not fundamental design. strongly disagree. stats can play a part, but there's no substitute for well-chosen criteria. (it would help immensely if spam filter writers actually understood statistics.) I can assure you that in the outside world, the amount of legitimate mail that comes from no-PTR hosts these days is infinitesimal. in large part that's because poorly chosen spam filters have "trained" mail senders (legitimate and spammer alike) to set up PTR records. basically the hoops become meaningless. and IPv6 is a different enough case that the old assumptions should not be presumed to be valid. So, yeah, spam stinks, but it's not going away, and arguments that you shouldn't use a technique today because it didn't work in 1998 don't cut it. that's hardly a justification for stupidity. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: problem dealing w/ ietf.org mail servers
that's hardly a justification for stupidity. I entirely agree. Where we evidently don't agree is about what's stupid. R's, John ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: problem dealing w/ ietf.org mail servers
Which (autoconfig) you should either not be using on servers, or you should be configuring your software properly to select the correct outbound address. that's a bizarre statement. the distinction between a client and a server is an artificial one. either autoconfig is useful for all kinds of machines, or it's almost useless. You are correct when talking about IP networks in general, however Jeroen is talking about the public Internet, not IP networks in general. Of course another way to make this less bizarre is to stop using the word server to refer to two different things. Jeroen is saying that an IPv6 devices that wishes to advertise its IPv6 address for the purposes of receiving SMTP connection requests, should not be configured in such a way that its IPv6 host ID is randomly assigned. Of course you could try to dynamically update your reverse DNS to match the random host IDs but that creates corner cases and race conditions which can be entirely avoided just by making the publicly visible IPv6 address a static one. Jeroen further pointed out that there is no reason for an interface, which has been assigned a random host ID, to suffer with only one address because IPv6 makes it straightforward to have multiple addresses on an interface. BTW, I do agree with your general viewpoint of Internet email architecture; it is horribly ugly and broken. --Michael Dillon ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: problem dealing w/ ietf.org mail servers
John Levine wrote: that's hardly a justification for stupidity. I entirely agree. Where we evidently don't agree is about what's stupid. in this case, what's stupid is filtering mail based on arbitrary and largely undocumented criteria, with little regard for the consequences.for instance, such criteria tend to favor large spammers over small legitimate users. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: problem dealing w/ ietf.org mail servers
On Wed, Jul 02, 2008 at 10:47:53PM -0700, 'kent' wrote: [..] However, this last address, 2001:470:1:76:2c0:9fff:fe3e:4009, is not explicitly configured on the sending server; instead, it is being impli= citly configured through ip6 autoconf stuff: Which (autoconfig) you should either not be using on servers, or you=20 should be configuring your software properly to select the correct=20 outbound address. (I prefer to use the autoconfig one for 'management'=20 and using a 'service address' for the service). And what is someone who doesn't have a permanent box with a static address to do that wants to use TLS to verify that one is actually talking to the remote party you are expecting to? A mobile machine can register its current addresses in the DNS regardless much more easily than it can register its reverse PTR records. Use the ISP's servers? I don't trust the ISP's servers to do the right job. I don't trust that there is not a copy of the correspondence being made and being sent somewhere else. I have NO idea if they are setup to use TLS or not outbound Lack of PTR should NEVER be the SOLE reason for rejecting email. I have not problem with is being a weighting into the decision of whether a piece of email is spam or not. Just don't make it map to 100%. SMTP shows that it is perfectly usable for these situations as it nicely = rejects the message with a proper message automatically telling you on=20 how to solve it. That is to say, it appears the ietf.org mail server is probably now rej= ecting mail from *any* box that is getting a default global ipv6 address, sinc= e those addresses will most likely not be in ip6.arpa. There may be a wh= ole lot of boxes in this situation.=20 Those boxes are not set up correctly thus should not be sending email in = the first place. A PTR is not a requirement for sending email. The IETF should live by it's own dog food and accept email from sites without PTR records. For that matter you should actually be=20 firewalling+logging port 25 outbound so you can monitor any host in your = network doing illegal SMTP connects. Spam bots don't use IPv6 yet=20 (afaik), but when they are aware how 'open' everything is and especially = that RBL's don't exist yadda yadda, they might just switch over to that. Good that the mainstream spamreceivers (gmail/yahoo/etc) don't have IPv6 = yet as that would change that scenario. Configure your mailservers correctly, it helps you send out mail, and it = helps avoid others receiving crap from you. If you want to demand PTR records then you need to make it a requirement of address allocations that control of the reverse DNS entry passes down to the actual user of the addresses. Mark Greets, Jeroen -- For postfix folks: http://www.postfix.org/IPV6_README.html 8 /etc/postfix/main.cf: smtp_bind_address6 =3D 2001:240:587:0:250:56ff:fe89:1 8 Other SMTP servers have similar mechanisms. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: problem dealing w/ ietf.org mail servers
On Fri, Jul 04, 2008 at 07:57:58AM +1000, Mark Andrews wrote: A mobile machine can register its current addresses in the DNS regardless much more easily than it can register its reverse PTR records. er... both are registering things in the DNS. manipulation of the farward map is occasionally easier than manipulation of the reverse map... which i think is what you are trying to say. and it is often true that those who manage the forward DNS map are -NOT- the same folks that manage the reverse DNS map. --bill Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise). ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: problem dealing w/ ietf.org mail servers
In fact many ISP's only allow their clients to update the forward maps since they don't want to set those blocks of addresses into SWIPPED mode. T. - Original Message - From: Bill Manning [EMAIL PROTECTED] To: Mark Andrews [EMAIL PROTECTED] Cc: Richard Shockey [EMAIL PROTECTED]; Dave Crocker [EMAIL PROTECTED]; Jeroen Massar [EMAIL PROTECTED]; ietf@ietf.org Sent: Thursday, July 03, 2008 2:05 PM Subject: Re: problem dealing w/ ietf.org mail servers On Fri, Jul 04, 2008 at 07:57:58AM +1000, Mark Andrews wrote: A mobile machine can register its current addresses in the DNS regardless much more easily than it can register its reverse PTR records. er... both are registering things in the DNS. manipulation of the farward map is occasionally easier than manipulation of the reverse map... which i think is what you are trying to say. and it is often true that those who manage the forward DNS map are -NOT- the same folks that manage the reverse DNS map. --bill Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise). ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf No virus found in this incoming message. Checked by AVG. Version: 8.0.134 / Virus Database: 270.4.4/1532 - Release Date: 7/3/2008 8:32 AM ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: problem dealing w/ ietf.org mail servers
In fact many ISP's only allow their clients to update the forward maps since they don't want to set those blocks of addresses into SWIPPED mode. T. It's quite possible to allow individual machines to update their reverse records without having to delegate the name space to the customer. TCP is a strong enough authenticator for this role. Mark - Original Message - From: Bill Manning [EMAIL PROTECTED] To: Mark Andrews [EMAIL PROTECTED] Cc: Richard Shockey [EMAIL PROTECTED]; Dave Crocker [EMAIL PROTECTED]; Jeroen Massar [EMAIL PROTECTED]; ietf@ietf.org Sent: Thursday, July 03, 2008 2:05 PM Subject: Re: problem dealing w/ ietf.org mail servers On Fri, Jul 04, 2008 at 07:57:58AM +1000, Mark Andrews wrote: A mobile machine can register its current addresses in the DNS regardless much more easily than it can register its reverse PTR records. er... both are registering things in the DNS. manipulation of the farward map is occasionally easier than manipulation of the reverse map... which i think is what you are trying to say. and it is often true that those who manage the forward DNS map are -NOT- the same folks that manage the reverse DNS map. --bill Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise). ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf - --- No virus found in this incoming message. Checked by AVG. Version: 8.0.134 / Virus Database: 270.4.4/1532 - Release Date: 7/3/2008 8:32 AM ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
