Re: Qualitative Analysis of IETF and IESG trends (Re: Measuring IETF and IESG trends)
Ted, The big problem others have been pointing to is that DISCUSSes are not being used to say here is a technical issue, for which any solution acceptable to the community is fine, but are instead being used to say here is a technical issue, and here's what it would take to satisfy me that it is resolved. The second formulation shortens easily in the minds of listeners to satisfy me, and when there is text presented, it becomes add/change this as below to remove my hold on your document. Ack. I agree that this is a concern, and something that I forgot to put on my list. Of course, as Joel and Brian pointed out, identifying this problem is not always as simple as looking at whether text came from the AD. Also, *if* you assume the Discuss was appropriate, presumably the resolution, whatever it is, has to satisfy some criteria so that the original problem goes away. If an AD is not happy about a particular text proposal, is it because the criteria was not met, or was it because he or she insisted on particular text? Obviously the former is appropriate and the latter is not. And how well were the criteria described? Many debates about resolutions involve either unclear criteria or disagreements about whether all criteria need to be fulfilled, more than the actual words in the resolution. The statement above is offensive, Jari. Blaming working groups for exhaustion after a late surprise is insensitive I'm sorry you found it offensive. I did not mean to be insensitive. If it helps, this item was on a long list of reasons why WG involvement isn't being handled as well as it should be. Not the biggest reason, or very commonly occurring one. (But I think I've seen a few cases where the author/WG was not interested in the particular way to resolve an issue, as long as it was resolved. Can't speak about why they were in that state.) Many, if not most reasons on my list rest on the ADs and some on the shepherds. I blame myself for not doing a better job in involving the WGs and I plan to improve this for the documents that I sponsor. Jari ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Qualitative Analysis of IETF and IESG trends (Re: Measuring IETF and IESG trends)
Speaking as an individual who has also participated in the work of other standards organizations - In other SDOs, the IEEE 802 for example, suggesting a fix for a problem detected in the text at ballot time is not only welcome, but sometimes the recommended if not mandatory practice. Dan -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brian E Carpenter Sent: Wednesday, July 02, 2008 12:58 AM To: Joel M. Halpern Cc: ietf@ietf.org Subject: Re: Qualitative Analysis of IETF and IESG trends (Re: Measuring IETF and IESG trends) On 2008-07-02 09:07, Joel M. Halpern wrote: Of course, we also get complaints whenever anyone raises an issue without providing text. So, by a strict reading of the argument, the AD is hanged if he provides text (directing the working group) and hanged if he does not provide text (you didn't make clear what your problem is, and how to fix it.) There is, I think a big difference between an AD writing (a) Here is the fix for my problem and (b) Here is my proposal for one way to fix this issue; there may of course be other ways to do so, so please let me know what the WG prefers to do. But that takes time to type in, and an overloaded AD (or reviewer) will be very tempted just to write Suggested fix:. Maybe we should assign specific (b) semantics to SUGGESTION and use that as shorthand? Brian ___ 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: Update of RFC 2606 based on the recent ICANN changes ?
In a more sane world, no one rational would want to build a business or other activity around a TLD named local. But this is demonstrably not a sane world. Right. I can see the business case for this. :-( But at least in the first round, the barrier to entry is so high that I don't see that sort of thing as being viable. The figure $100K for a TLD application is what is floating around at the moment, though that number is not nailed down definitively. For much of the domain tasting related activities, a fundamental premise was that the cost of using a name was very low (i.e., zero, while the AGP was being leveraged). Thomas ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Update of RFC 2606 based on the recent ICANN changes ?
Which brings up a question can a TLD be used like a domain name? not just http://microsoft/ but [EMAIL PROTECTED] will likely to fail to. james 2008/7/2 Hallam-Baker, Phillip [EMAIL PROTECTED]: Another like restriction that might be investigated is whether http://microsoft/ or other similar corporate TLDs would work as intended with deployed legacy browsers. I suspect (but have not tried) that if you simply type 'Microsoft' into the address bar of some browsers you might have the keyword immediately interpreted as a search term, not an address to visit. I also suspect that if we actually read the technical specs being proposed we might find that some of these issues have already been anticipated in them and addressed. From: [EMAIL PROTECTED] on behalf of Dave Crocker Sent: Tue 7/1/2008 12:44 PM To: Tony Finch Cc: IETF Discussion Subject: Re: Update of RFC 2606 based on the recent ICANN changes ? Tony Finch wrote: Speaking technically, how would you distinguish the top-level domain 127.0.0.1 from the IP address 127.0.0.1? A word while passing here: is there a document (RFC, Posix standard, whatever) which says which is the right result in such a case? RFC 1123 section 2.1, especially the last sentence. Interesting. I hadn't noticed the implication of that, before, but it seems to be a pretty clear technical specification that a top-level domain is not allowed to be a decimal number. Ever. That's a concrete constraint on what ICANN is permitted to authorize. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ 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 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Update of RFC 2606 based on the recent ICANN changes?
blush Thanks! Steve On Jul 1, 2008, at 6:36 PM, John Levine wrote: This does not mean that ICANN won't listen to the IETF; it means that there will be voices more familiar to ICANN saying things different than we are. One of the few ICANN committees that actually works is the SSAC, the Security and Stability Advisory Committee. It includes a lot of people we know, starting with Steve Crocker, the chair. I cannot ever recall a time when ICANN acted contrary to the advice of the SSAC. So although I agree that there's a lot not to like about ICANN, the chances that they will do technically dangerous things are low. http://www.icann.org/committees/security/ R's, John ___ 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: Update of RFC 2606 based on the recent ICANN changes ?
(It's always a bummer when ietf-general turns into ICANN-general, but in this case it seems like a useful discussion because the IETF will probably be asked policy questions for various proposed TLDs.) At 10:17 AM -0400 7/2/08, Thomas Narten wrote: In a more sane world, no one rational would want to build a business or other activity around a TLD named local. But this is demonstrably not a sane world. Right. I can see the business case for this. :-( But at least in the first round, the barrier to entry is so high that I don't see that sort of thing as being viable. Then you're not being creative enough. The figure $100K for a TLD application is what is floating around at the moment, though that number is not nailed down definitively. ...nor justified financially... For much of the domain tasting related activities, a fundamental premise was that the cost of using a name was very low (i.e., zero, while the AGP was being leveraged). If that was true, then a domain that was popular but lost its name due to negligence in renewal should be able to buy it back from the taster for a few hundred bucks. Instead, the price I have heard more than once is tens of thousands of dollars. Without doing a lot of business research and probably some traffic capture, you can't estimate the value of .local or a TLD that is a typo but not really infringing of a popular search term. We scoff at people who say it would be easy to just add privacy to that protocol; they should scoff at us for making wild guesses about values in a huge, unregulated business that is less than ten years old. --Paul Hoffman, Director --VPN Consortium ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Update of RFC 2606 based on the recent ICANN changes ?
Paul, But it is still the case that an application for say .local would need to go through some review process (regardless of price) which would include input from the IETF ICANN rep. I see little reason why or how a TLD that would be damaging, confusing, or otherwise bad for the IETF would/could just slip through this process. What am I missing here? Ole Ole J. Jacobsen Editor and Publisher, The Internet Protocol Journal Cisco Systems Tel: +1 408-527-8972 Mobile: +1 415-370-4628 E-mail: [EMAIL PROTECTED] URL: http://www.cisco.com/ipj ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Update of RFC 2606 based on the recent ICANN changes ?
At 9:30 AM -0700 7/2/08, Ole Jacobsen wrote: But it is still the case that an application for say .local would need to go through some review process (regardless of price) which would include input from the IETF ICANN rep. I see little reason why or how a TLD that would be damaging, confusing, or otherwise bad for the IETF would/could just slip through this process. Fully agree. What am I missing here? That there could/would be others arguing that the IETF is over-stating the damage from a particular proposal. Anyone who is willing to pay the exorbitant^W application fee obviously is willing to defend their choice of name. On something like .local (and, I predict, .1), the counter-argument to anything the IETF says is that's possibly true, but not likely. We can't prove future harm, and they can belittle us for being too cautious. They have money behind them, and we have our reputation. ICANN gets to weigh those two against each other. This is somewhat parallel to the political process in most capitalist democracies. --Paul Hoffman, Director --VPN Consortium ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Update of RFC 2606 based on the recent ICANN changes ?
--On Tuesday, 01 July, 2008 09:58 -0700 Hallam-Baker, Phillip [EMAIL PROTECTED] wrote: Another like restriction that might be investigated is whether http://microsoft/ or other similar corporate TLDs would work as intended with deployed legacy browsers. I suspect (but have not tried) that if you simply type 'Microsoft' into the address bar of some browsers you might have the keyword immediately interpreted as a search term, not an address to visit. I suspect that, if Microsoft spent a hundred thousand dollars or more to secure microsoft. as a TLD, at least one of those browsers would be swiftly corrected in a way that they would find satisfactory. The issue with [EMAIL PROTECTED] is a little more complex. After extended discussions, rfc2821bis still does not permit RCPT TO:[EMAIL PROTECTED] (note trailing dot) and there are some other issues about trying to use TLDs as the only label in an email address. But none of that counts. There have been more than enough actors who have wanted TLDs that violate one rule or another, assuming that applications authors will sort things out as needed, maybe even with IETF help. And there have been more than enough who believe that, if some construction they want works with the world's most popular browser, then it is sufficient (non-web protocols be d**ned). john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
[ Re: [mpls] WG Review: Recharter of Multiprotocol Label Switching (mpls)]
Eric, Eric Rosen wrote: - Define requirements, mechanisms and protocol extensions for point-to-multipoint (P2MP) MPLS Should be P2MP and MP2MP (multipoint-to-multipoint) MPLS; we wouldn't want to suddenly find out that half of draft-ietf-mpls-ldp-p2mp is out of charter ;-) What I (with the wg chair hat on) think this is about is to add the piece about mpls-tp to the mpls wg charter. We've discussed in the wg and have wg consensus to do that. A couple of milestones are also being changed. Having said that, I'm also of the opinion that we need a major revision of the mpls wg charter, e.g. for the reasons Eric discusses above. However, that process needs to start in the working and have wg consensus when we ask the IESG for the update. I can see that it will be necessary to start process during the autumn. /Loa ___ mpls mailing list [EMAIL PROTECTED] https://www.ietf.org/mailman/listinfo/mpls -- Loa Andersson Principal Networking Architect Acreo AB phone: +46 8 632 77 14 Isafjordsgatan 22 mobile: +46 739 81 21 64 Kista, Sweden email: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Update of RFC 2606 based on the recent ICANN changes ?
While I appreciate the kind words and deference to SSAC, and while we would undoubtedly concur with recommendations to reserve names like .local, ICANN actually listens to the IETF more directly. Moreover, there is a specific slot on the Board of ICANN for a Liaison from the IETF. Thomas Narten does a great job in that role, as John Klensin did before him. Steve On Jul 2, 2008, at 12:53 PM, John Levine wrote: In article [EMAIL PROTECTED] you write: Paul, But it is still the case that an application for say .local would need to go through some review process (regardless of price) which would include input from the IETF ICANN rep. More likely from the SSAC, which would be even better. In any event, as I said before, although there's a lot not to like about ICANN, the chances of them doing anything technically destructive remains low. 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 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Update of RFC 2606 based on the recent ICANN changes ?
--On Wednesday, 02 July, 2008 10:45 -0700 Paul Hoffman [EMAIL PROTECTED] wrote: At 9:30 AM -0700 7/2/08, Ole Jacobsen wrote: But it is still the case that an application for say .local would need to go through some review process (regardless of price) which would include input from the IETF ICANN rep. I see little reason why or how a TLD that would be damaging, confusing, or otherwise bad for the IETF would/could just slip through this process. Fully agree. Ole, even those of us who are most skeptical about relying on ICANN are not concerned about something slipping through. The concern is about ICANN weighing the issues and deciding that what someone wants to do and on which they are willing to spend serious money (or, to put that differently, contribute serious money to ICANN). What am I missing here? That there could/would be others arguing that the IETF is over-stating the damage from a particular proposal. Anyone who is willing to pay the exorbitant^W application fee obviously is willing to defend their choice of name. On something like .local (and, I predict, .1), the counter-argument to anything the IETF says is that's possibly true, but not likely. We can't prove future harm, and they can belittle us for being too cautious. They have money behind them, and we have our reputation. ICANN gets to weigh those two against each other. This is somewhat parallel to the political process in most capitalist democracies. Exactly. And, in that regard, I draw no comfort from Thomas's comment about a likely $100K application fee. Assume we have organizations who are willing to put that sort of money into an application for a TLD they think would be profitable or beneficial to themselves... and probably to spend that much again on lawyers, consultants, etc., to prepare an application that will get through the system. If they see IETF-imposed restrictions as being in their way, they are likely to be willing to put significant energy and resources into sweeping those restrictions out of the way, using precisely the sort of those guys are too conservative argument Paul posits (or its relatives those guys are trying to make policy and disguise it as an inevitable technical choice or the risks are low and here is our large chunk of money to prove that we think there are overriding commercial considerations). Now, for example, I happen to believe that one-off typing error is guaranteed to yield a false positive, is a more than sufficient _technical_ basis to ban single-alphabetic-letter domains at either the top or second levels and to advise lower-level domains against their use. Those are technical grounds based on human interface design and information retrieval principles, not the network will break if that is done. But few of the recommendations or reservations we might make fall into that network-breaking latter category. Even some of those that fall closest to the line involve cases that we could fix by modifying our applications protocols to lexically distinguish between domain names and address literals (http://[10.0.0.6]/ anyone?). It is, of course, possible to argue the case for and against single-letter domains in other ways and reach the conclusion that the advantages of permitting one-character alphabetic TLDs far outweigh the possible risks, especially since the end users who can get hurt by this stuff don't have much practical voice in ICANN. To someone worried about ICANN's budget, or trying to make the staff-empire even larger, $2,600,000 or $3,600,000 (26 letters, or 26 letters plus ten digits, times $100K) might themselves be a powerful argument. But, should those of us who believe that single-letter domains are bad news refrain from advocating for that rule because those who oppose it could use it to discredit other IETF recommendations that might be more important?I don't know the answer to that question, but I do know that the IETF has a lot of trouble making clear decisions when those sorts of politics start to intrude. --On Tuesday, 01 July, 2008 09:44 -0700 Dave Crocker [EMAIL PROTECTED] wrote: RFC 1123 section 2.1, especially the last sentence. Interesting. I hadn't noticed the implication of that, before, but it seems to be a pretty clear technical specification that a top-level domain is not allowed to be a decimal number. Ever. That's a concrete constraint on what ICANN is permitted to authorize. The rather odd phrasing there has been the source of a lot of discussion in the past in both selected IETF and ICANN circles. Some of us read it as TLDs will be alphabetic only -- no digits, not just cannot be all digits. The former was certainly the IANA intent when we were discussing RFC 1591. But does it apply today? Can ICANN override it? I can assure you that there are groups within ICANN who believe that they can. --On Monday, 30 June, 2008 12:29 -0700 David Conrad [EMAIL PROTECTED] wrote: ... Sort of like the concerns
Re: Update of RFC 2606 based on the recent ICANN changes ?
Which brings up a question can a TLD be used like a domain name? not just http://microsoft/ but [EMAIL PROTECTED] will likely to fail to. james The Internet went to multi-label hostnames ~20 years ago. We added .ARPA to all the single label hostnames as part of that process. The only hold over is localhost and that is implemeted locally, not in the global DNS. No sane TLD operator can expect http://tld; or [EMAIL PROTECTED] to work reliably. I suspect there are still mail configuations around that will re-write [EMAIL PROTECTED] to [EMAIL PROTECTED]. Should we be writting a RFC which states that MX and address records SHOULD NOT be added to the apex of a TLD zone? Should we be writting a RFC which states that single label hostnames/mail domains SHOULD NOT be looked up as is in the DNS? Mark -- 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: Update of RFC 2606 based on the recent ICANN changes ?
Mark Andrews said: The Internet went to multi-label hostnames ~20 years ago.We added .ARPA to all the single label hostnames as partof that process. The only hold over is localhost andthat is implemeted locally, not in the global DNS. No sane TLD operator can expect http://tld; or [EMAIL PROTECTED]to work reliably. I suspect there are still mail configuationsaround that will re-write [EMAIL PROTECTED] to [EMAIL PROTECTED] we be writting a RFC which states that MX and addressrecords SHOULD NOT be added to the apex of a TLD zone? Should we be writting a RFC which states that single labelhostnames/mail domains SHOULD NOT be looked up as is inthe DNS? Both sound like good ideas to me. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Update of RFC 2606 based on the recent ICANN changes ?
At 15:40 02-07-2008, John C Klensin wrote: Now, for example, I happen to believe that one-off typing error is guaranteed to yield a false positive, is a more than sufficient _technical_ basis to ban single-alphabetic-letter domains at either the top or second levels and to advise lower-level domains against their use. Those are technical grounds based on human interface design and information retrieval principles, not the network will break if that is done. But few of the recommendations or reservations we might Some people may question a technical recommendation that is not based on the network will break. make fall into that network-breaking latter category. Even some of those that fall closest to the line involve cases that we could fix by modifying our applications protocols to lexically distinguish between domain names and address literals (http://[10.0.0.6]/ anyone?). Or wait for http://[2001:1890:1112:1::20]/ to catch up. But, should those of us who believe that single-letter domains are bad news refrain from advocating for that rule because those who oppose it could use it to discredit other IETF recommendations that might be more important?I don't know That's a question to consider before getting into any rule-making. The rather odd phrasing there has been the source of a lot of discussion in the past in both selected IETF and ICANN circles. Some of us read it as TLDs will be alphabetic only -- no digits, not just cannot be all digits. The former was certainly the IANA intent when we were discussing RFC 1591. But does it apply today? Can ICANN override it? I can assure you that there are groups within ICANN who believe that they can. RFC 1591 has been swept away by the changes that have taken placed since then. By making a few changes to RFC 5241, we could have a document relevant to this topic. :-) At 16:23 02-07-2008, Mark Andrews wrote: No sane TLD operator can expect http://tld; or [EMAIL PROTECTED] to work reliably. I suspect there are still mail configuations around that will re-write [EMAIL PROTECTED] to [EMAIL PROTECTED]. http://museum/ The key word word is reliably. http://museum/ can never be guarenteed to work. I can have museum.example.net with a search list containing example.net. Which one would you expect to match? Note changing the search order to try single labels as is first is not safe from a security perpective (see RFC 1535 for why not) as the introduction of a new TLD will break things. Getting rid of search lists is also a show stopper. Should we be writting a RFC which states that MX and address records SHOULD NOT be added to the apex of a TLD zone? The above TLD has an address record. It still does not make it a good thing. Should we be writting a RFC which states that single label hostnames/mail domains SHOULD NOT be looked up as is in the DNS? There was a ccTLD operator who expressed the wish for such mail domains. And I can wish for a million dollars to be added to my savings account. It doesn't mean I'll get it or that the ccTLD operator should get it. Mark Regards, -sm ___ 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: Update of RFC 2606 based on the recent ICANN changes ?
Mark Andrews wrote: The Internet went to multi-label hostnames ~20 years ago. As noted in RFC 2821 as one dot required syntax, also mentioned in RFC 3696. Recently *overruled* by 2821bis. No sane TLD operator can expect http://tld; or [EMAIL PROTECTED] to work reliably. Certainly not expect, but some gave it nevertheless a try. My bastard browser from hell let's me say http://museum./ (note trailing dot). I suspect there are still mail configuations around that will re-write [EMAIL PROTECTED] to [EMAIL PROTECTED]. They didn't note that RFC 2821 upgraded the 821 examples, sh*t happens... eg Should we be writting a RFC which states that MX and address records SHOULD NOT be added to the apex of a TLD zone? No, there are enough TLDs disagreeing with this idea... Should we be writting a RFC which states that single label hostnames/mail domains SHOULD NOT be looked up as is in the DNS? ...the 2821bis Last Call ended months ago, and one dot required was discussed long enough. Change this again, and I'll scream. Frank -- Repost, apparently my first attempt didn't make it. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
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 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
