Re: IETF-Blog comments (Was Re: setting a goal for an inclusive IETF)
On 2 Aug 2013, at 12:17, Rich Kulawiec r...@gsp.org wrote: On Tue, Jul 30, 2013 at 04:40:42PM +0200, Arturo Servin wrote: Captchas? Recaptchas? Captchas et.al. are completely worthless. They're defeated at will by the first adversary who comes along that's willing to expend the minimal resources required to overcome them. Yes, indeed, and in the meantime it excludes many people with limited or no vision, including me. There's a rant here, but you don't want to hear it right now. :) FYI I use the service from http://www.skipinput.com/ for my CAPTCHA-solving needs. Works very well, though you need to be aware that it uses a browser extension. The best methods for blog comment abuse control seem to be combinations of network/domain blocks and moderation. Both have their downsides, though; the former needs to be custom-crafted for each particular application and the latter can be time-intensive. The trick, if there is one, is to use layers of these so that each is conservative about what it blocks (thus keeping the FP rate down) but that each leaves less work for successive layers to handle (thus keeping the FN rate down). Without wishing to kill morale, it's not clear to me how important the IETF is to our friendly cockroach neighbourhood. I'll bet that a simple question and answer (whose answer is trivial to find on Google) is all that we really need to kill comment spam. There is the authentication database at Tools too, of course, and the IETF is quite versed in sending challenge emails, so at worst the combination of a QA and a valid email address should scare off the worst, while leaving guests the honour of commenting and leaving familiars almost no work to do at all. Cheers, Sabahattin
Re: Bonjour-dev Digest, Vol 10, Issue 19
(Because this was brought up very, very recently.) On 21 Feb 2013, at 20:28, Rick Mann rm...@latencyzero.com wrote: On Feb 21, 2013, at 12:24 , David Brower david.bro...@oracle.com wrote: It depends on the records. If you phrase it like you that, you will probably get the blank stare answer. When you start talking about the PTR, SRV and TXT records specifically, then you'll have a case -- but it isn't really Bonjour that is the proximate force, because those were issues against interpretations of the previous RFCs. Now, the legalistic point I'm debating at the moment is whether it is proper and/or legal to have the SRV record use as the target name the string version of an ip4 address, eg: 192.169.0.145. That's a perfectly legal and representable set of characters for a hostname, so maybe OK. How about for an ip6 address with colons, which aren't allowed in hostnames? All I know is that a couple years ago, I tried and failed with both DynDNS and DNSMadeEasy to get them to allow me to put spaces in TXT records. I cited all relevant material I could find, but they kept going back to the original DNS specifications saying those didn't allow spaces. RFC 1035, 2.3.1, wisely advises the use of compatible constraints on labels in host names. I am aware that DNS is binary transparent, and mDNS/DNS-SD make use of that feature to be useful, but I can well understand the scepticism of your DNS hosts. Perhaps this is a legitimate call to relax the restrictions, *if* the operator/user is aware of the potential consequences. Cheers, Sabahattin
Re: A Splendid Example Of A Renumbering Disaster
On 26 Nov 2012, at 20:41, Pete Resnick presn...@qti.qualcomm.com wrote: On 11/23/12 7:46 PM, Sabahattin Gucukoglu wrote: http://b.logme.in/2012/11/07/changes-to-hamachi-on-november-19th/ Yes, like Benson, I am at a loss for why they do not use RFC 6598 addresses. That's what someone should tell these goofballs to do. OK, I'm getting the idea. I've left a comment there. Hopefully somebody will find it. Cheers, Sabahattin
A Splendid Example Of A Renumbering Disaster
It's Friday. Time to plug IPv6 some more. :-) http://b.logme.in/2012/11/07/changes-to-hamachi-on-november-19th/ LogMeIn Hamachi is basically a NAT-traversing layer 2 VPN solution. They avoided conflicts with RFC 1918 space by hijacking IPv4 space in 5/8, now actively being allocated by LIRs in Europe. When that didn't work (see link above), they moved to 25/8, allocated to the UK MoD. While I'm almost sure that they haven't got it quite so wrong this time, following the comments says that the idea was not only a very bad one to start with, it's cost a lot of people a lot of grief that IPv6 was clearly going to mitigate in renumbering. Perhaps it is why they recommend it per default, if not for the number of applications that would be broken by it. By the way, is this an application that the new shared transition space might benefit? Cheers, Sabahattin
Re: mailing list memberships reminder - passwords in the clear
On 2 Nov 2012, at 21:51, John Levine jo...@taugh.com wrote: Only majordomo2, which has been unmaintained for a while now (and it's author calls it Dead holds much of a chance, but I doubt it ?would work for the IETF in its current condition. Actually, MJ2 works great, I've been using it in production for years, I completely agree that it's excellent software. but I agree that we'd need to locate a perl weenie willing to make tweaks, and it's probably not enough better than MM to be worth the pain of switching. I think it's the difference between night and day, personally. MJ2 is technically superior and emphasises the task of actually managing mailing lists in a very clean, black-box way. OTOH, it seems clear that Mailman has won over all the web hosters and whatnot because it's User-friendly. I guess Integrated with the web is an adequate sell, even if it practically means Has a simple, inflexible interface that's only accessible using a web browser from lynx up. Certainly, the IETF could benefit from MJ2's more techie features (not least, the means to do absolutely everything by email). Moderators, in particular. But it still boils down to having and using supported software. Sadly this isn't possible with mailman; you will always be mailed your password if you need it and can't remember it. If you use a high value password for your IETF list subscriptions, you have deeper security issues than a few tweaks to mail software can fix. Unfortunately though, it happens quite often. Users want all the benefits without any of the inconveniences. So they use their easy-to-remember/crack/used-everywhere-else passwords. Cheers, Sabahattin
Re: mailing list memberships reminder - passwords in the clear
On 1 Nov 2012, at 20:20, Paul Aitken pait...@cisco.com wrote: Why does the mailing list memberships reminder send passwords in the clear? Because mailman is brain-dead stupid. See: http://www.jwz.org/doc/mailman.html Sadly, and despite my best efforts to find alternative mailing list software, mailman wins on popularity (ugh) and hence support with practically no competition. Only majordomo2, which has been unmaintained for a while now (and it's author calls it Dead holds much of a chance, but I doubt it would work for the IETF in its current condition. But have hope! The IETF serves the mailman interface over TLS, and it is an option that you can exercise *not* to have passwords mailed to you. Go to your membership options page, and in the group containing the option to turn off the membership reminders, check the checkbox to make it global. Later, you can have the password mailed to you on demand, or unsubscribe without needing a password at all (email confirmation loop). For everything else I'm subscribed to, if I forget my details, one click sends a one-time password-reset link. Passwords are never mailed out, and never shown. Yes. Sadly this isn't possible with mailman; you will always be mailed your password if you need it and can't remember it. HTH. Cheers, Sabahattin
Re: the usual mail stuff, was IETF...the unconference of SDOs
Wo! There's a whole section of the conversation that ended up in Untidy that shouldn't've. On 9 Sep 2012, at 20:25, John Levine jo...@taugh.com wrote: I have to say that I'm baffled at the perverse pride that people seem to take in being so technically backward that they're unable to handle the mail that 99% of the world uses today. While not being a fan of overdecorated HTML and endless font changes, and strongly preferring a mail program that lets me keep my fingers on the keyboard, I can deal with it. (I use Alpine, keep meaning to take another look at mutt.) This sort of modernist attitude only really works while you're not recovering mail from mbox files using less. Or, in general, while you need to do as little work as possible to redisplay or process a message. Not to say you're point isn't essentially valid--we must, of course, be aware of the current trends--but popularity doesn't mean correct for the group of people genuinely preferring low-overhead or Technically backward MUAs, pagers, scripts, etc. Those people got there first and have a pretty good leverage for screaming at other people who got there later, and failed to regard those others not like themselves by flagrantly ignoring standards which would have guaranteed interoperability had they not done so, particularly when the primary motivation for doing so is ease of implementation with a fundamentally different UI paradigm. Keep using alpine. Move to mutt and you'll get pretty plus-signs in the left column of wrapped mail--that is, unless mutt has also worked around this type of breakage (doubtful, they're a pretty puritanical bunch :-) ). But mutt has maildir+ support where alpine doesn't without a load of controversial patching, and so while I'm using alpine now it's only because I go through Dovecot as intermediary or use external IMAP servers. (Yes, free email providers accessed through IMAP/SMTP in textmode as opposed to /usr/sbin/sendmail are cool when they come from Apple. They're … all shiny. :-) ) For the large majority of mail that is written in paragraphs rather than tables, line wrapping is a useful feature, regardless of the character set, particularly for those of us who sometimes read our mail on a tablet or phone while changing planes. For mail that is a table and stuff has to line up in columns, use HTML tables. That's what they're for. And Format=Flowed takes care of the first requirement. Multipart/alternative takes care of the latter (when inventive multi-line columns will not suffice) (and they don't, with small-screen devices). PS: Yes, this is top posted. You can deal with that, too. This message bottom-posted for your reading convenience, as opposed to my laziness. It'll render beautifully in alpine, I'm sure. :-) Cheers, Sabahattin
Re: Format=flowed quoting (was Re: IETF...the unconference of SDOs)
On 25 Oct 2012, at 01:25, Michael Richardson mcr+i...@sandelman.ca wrote: Sabahattin Gucukoglu listse...@me.com wrote: SG * text/paragraphs (or whatever), a completely different identity that violates the length limits SG Apple Mail and Microsoft use this text/paragraphs. Do you think it would be worth writing a specification for text/paragraphs? Only if we can get a whole bunch of defective code reading and writing it. There might be a case for that, given the laziness they've demonstrated in simply abusing text/plain, but it's also just possible that they might, just might implement format=flowed instead. But it's unlikely. :-( Heuristically, it's not that hard to identify, and a small patch for mailman would at least mark email as being in that format, so that at least, IETF lists could have email that complies to some standard. It would be easier and simpler and probably more participant-friendly (though not, see below, quite as good for changing the running code :-) ) to perform imperfect conversions from text/paragraphs to text/plain; format=flowed. All we've got to do is identify any line longer than 80 characters and, assuming that it runs to the end of a paragraph at all times, add a forced soft line break encoded using F=F's stuffing rules. Any line terminated before it's too long is assumed to be a manually inserted hard line break. Now that I come to think of it, now is the time to see if the Tcl MIME parser will help me out writing a quick and dirty proxy server for my own machine … (Whether or not we then drop email that doesn't have a text/plain part is a second conversation) You want to punish Apple and/or Microsoft? That's how to do it. :-) Cheers, Sabahattin
Re: Format=flowed quoting (was Re: IETF...the unconference of SDOs)
Warning: this message was generated by Apple Mail. I just can't stop my
insatiable appetite for shiny things. :-( [1]
On 16 Oct 2012, at 03:46, Randall Gellens ra...@qti.qualcomm.com wrote:
At 9:12 AM -0400 9/5/12, Michael Richardson {quigon} wrote:
Maybe I'm also concerned because many in the former elite have moved to
Apple Mail, and it seems that it is bug
compatible with Outlook in it's assumption that format=flowed is the
default, an act which destroys email quoting, and therefore discussion.
I just noticed this assertion, which is quite false. Format=flowed protects
and preserved quoting. It's the only way to avoid ludicrous and impossible
to read quoting (which happens after quoted passages get line-wrapped at odd
points). Also, as far as I know, Exchange does not support format=flowed at
all. My understanding is that it insists on HTML quoting, which is entirely
different.
You're right that this is the virtue of F/F, but that's not what Michael said.
Perhaps it was the context of the quoting, but the discussion refers to the
fact that both LookOut and Apple Mail have (as you can see, by looking at this
message) a nasty habit of *assuming* an F/F semantic by default. In other
words, they generate hugely long long long long long long long long long lines
that only another equally broken client can interpret correctly, but
dynamically reflowing those lines, by applying consistent quoting indicators to
the lines of such reflowed lines, and so forth. That, I believe, is a
legitimate complaint, because it effectively creates an island between those
who have support for Format/Flowed and those who do not. At least Apple has
the decency to use quoted-printable encoding to protect the actual transmitted
lines, but it means nothing if competent MIME readers reconstitute the
corruption at the other end, by reassembling long lines, and then failing to
reflow them. And it's worse yet if a news reader without MIME tries to quote
the lines, complete with Q-P line terminators. Or if a reply comes from
somebody whose editor wraps the lines, but using soft line breaks which are
never generated externally, resulting in whole paragraphs being quoted using a
single quoting indicator. And so on, and so on, and so on …
I filed bug 7989556 (Mail uses quoted-printable indiscriminately) with Apple on
16 May 2010. It was marked as duplicate of 7547565 on 25 May 2010. The system
is closed; you can only see your own bug reports. I therefore have no idea
what's going on with that. Meantime, I apologise for the inconvenience. No,
really. :-(
Cheers,
Sabahattin
[1] This isn't strictly true. I'm blind, and Apple are the only guys who have
stepped up to accessibility in anything approaching a serious manner, by
including the screen reader in the OS and ensuring accessibility across their
applications. For better or worse, they're the only choice for a smartphone,
and the only choice for a Windows convert (notwithstanding textmode Linux, of
course, which I still enjoy in VMs for braille support). I'm objective, so
this could change, but on both Windows and Mac OS the only really accessible
choices are the built-in MUAs (I used to use Pegasus Mail under Windows, when I
had the screen reader support for it, although I now understand that
Thunderbird has taken its place).
Re: Format=flowed quoting (was Re: IETF...the unconference of SDOs)
On 19 Oct 2012, at 17:45, Randall Gellens ra...@qti.qualcomm.com wrote:
At 11:42 AM +0100 10/19/12, Sabahattin Gucukoglu wrote:
Warning: this message was generated by Apple Mail.
But not using Format=Flowed.
Precisely.
On 16 Oct 2012, at 03:46, Randall Gellens ra...@qti.qualcomm.com wrote:
At 9:12 AM -0400 9/5/12, Michael Richardson {quigon} wrote:
Maybe I'm also concerned because many in the former elite have moved to
Apple Mail, and it seems that it is bug
compatible with Outlook in it's assumption that format=flowed is the
default, an act which destroys email quoting, and therefore discussion.
I just noticed this assertion, which is quite false. Format=flowed
protects and preserved quoting. It's the only way to avoid ludicrous and
impossible to read quoting (which happens after quoted passages get
line-wrapped at odd points). Also, as far as I know, Exchange does not
support format=flowed at all. My understanding is that it insists on HTML
quoting, which is entirely different.
You're right that this is the virtue of F/F, but that's not what Michael
said. Perhaps it was the context of the quoting, but the discussion refers
to the fact that both LookOut and Apple Mail have (as you can see, by
looking at this message) a nasty habit of *assuming* an F/F semantic by
default. In other words, they generate hugely long long long long long long
long long long lines that only another equally broken client can interpret
correctly, but dynamically reflowing those lines, by applying consistent
quoting indicators to the lines of such reflowed lines, and so forth. That,
I believe, is a legitimate complaint, because it e
This reflects a misunderstanding of Format=Flowed. Properly generated F=F
has lines of no more than 78 characters. One of the primary goals of F=F is
good interoperability between clients that support F=F and those that support
traditional pure plain text email. What you're describing is a symptom of
HTML quoting (or a surprisingly poor F=F implementation):
Yes, absolutely. We do not disagree.
Let's clear up the confusion. I made two mistakes, firstly by calling this
F/F semantics when what I mean is some sort of long-line-aware reflowing and
quoting. We'll have to find a name for it. The other mistake was to call
plain text plain text of any description, irrespective of the definition of
text/plain.
So we are talking about three formats:
* text/plain, 78 characters wide
* format=flowed, text/plain with soft breaks signalled by trailing whitespace,
78 characters
* text/paragraphs (or whatever), a completely different identity that violates
the length limits
Apple Mail and Microsoft use this text/paragraphs. It's not interoperable with
text/plain (because it *isn't* text/plain, as you very correctly note) and
therefore it gives everyone a really hard time. Unless you've not dealt with
plain text files from Windows or OS X, you may be sure that Plain text most
certainly doesn't conform to RFC 822, either.
We should now all be on the same page, I think. :-)
When generating Format=Flowed text, lines SHOULD be 78 characters or
shorter, including any trailing white space and also including any
space added as part of stuffing (see Section 4.4). As suggested
values, any paragraph longer than 78 characters in total length could
be wrapped using lines of 72 or fewer characters. While the specific
line length used is a matter of aesthetics and preference, longer
lines are more likely to require rewrapping and to encounter
difficulties with older mailers. (It has been suggested that 66
character lines are the most readable.)
The restriction to 78 or fewer characters between CRLFs on the wire
is to conform to [MSG-FMT].
At least Apple has the decency to use quoted-printable encoding to protect
the actual transmitted lines,
Again, this shows a fundamental misunderstanding of F=F. Properly generated
F=F does not use quoted-printable unless otherwise needed:
Yes. Apple Mail doesn't do this--it uses QP to keep the line lengths valid in
transmission only. Some mailers, or gateways, wouldn't do that, but would
instead spew out long lines that compliant SMTP servers would helpfully
corrupt, tail-drop, chop into pieces, etc (for lack of robustness or to protect
themselves).
but it means nothing if competent MIME readers reconstitute the corruption
at the other end, by reassembling long lines, and then failing to reflow
them. And it's worse yet if a news reader without MIME tries to quote the
lines, complete with Q-P line terminators. Or if a reply comes from
somebody whose editor wraps the lines, but using soft line breaks which are
never generated externally, resulting in whole paragraphs being quoted using
a single quoting indicator. And so on, and so on, and so on Š
All of these are part of the problem set that F=F was created to fix. Proper
F=F plays
Finally, It's The Year Of Linux^H^H^H^H^HIPv6
I really shouldn't, so soon after his last inflammatory rant, but here: http://www.theregister.co.uk/2012/05/08/ipv6_coming_next_month/ Quote One month from now, World IPv6 Launch Day with be upon us. Numerous online services will be enabling IPv6 and leaving it on. records will be published, and those of us with IPv6 enabled systems will start to use IPv6 preferentially to IPv4. But what does this all mean? For the short term at least, the truth is not much. … /quote Ignoring the obvious error with the preceding quote, on this occasion, he does at least appear to have one thing right: most people really aren't all that motivated, in the short term. The apathy continues a pace, and most of the industry is obliged to help in turn by doing almost nothing. Whether it will after June 6 is an open question, but I don't imagine he'll be far off there, either. What's important here, I think, is simply that the desire to have IPv6 deployed and running is outpaced by people's ongoing desire to ignore it. Networking nerds are happy because IPv6 at long last has a sporting chance. Everyone else just wants less of the hype. *Grumble* Cheers, Sabahattin
IPv6 Zone Identifiers Considered Hateful
I've obviously not been doing all my homework, and RFC 4007 slipped my attention. Worse, for all the communication my IPv6 nodes are doing amongst themselves using link-local addresses, it's never really been much more than a hastily-justified curiosity why, when I ping one from the other using link-local-scoped addresses, I have to put in this zone identifier (%ifname on BSD and Linux). Yesterday, I configured a DNS server to listen just using a link-local address, the one autoconfigured for an ethernet card accessible to all the nodes. It's a host, not a router, so I'm relying on that address not being routable and being filtered at the router. It didn't work. The server would not start until I specified the zone suffix. Now I am wondering why, given that there is no ambiguous link-local address anywhere around here, I need to do that. Can't it figure it out itself? What about the other problems with this suffix? It's host-specific, so it's unsafe to share it over the network (I need to share the DNS server using stateless DHCPv6). The format differs between OSes (Windows uses %n). It interferes with URLs, if Wikipedia is to be believed. It breaks expectations, essentially because it's the exception to the rule that the address bits (and hence the address format) conveys all the required information. So zone suffixes are considered hateful. Yes, it's true, I enjoy a good whinge and it's a shame I had to learn this on-demand, but really, their use should be limited to just those circs where it's actually necessary, and let's be honest, that ought to be very rare. Cheers, Sabahattin
Re: Consensus Call: draft-weil-shared-transition-space-request
On 29 Nov 2011, at 18:54, Ronald Bonica wrote: I think that our time would be used much more productively if we discussed whether to make the allocation or not. The proposed status of the document is a secondary issue. yes, it is, and yes, we should. I've slept on it, but it's no good. Ultimately, here is how it works: there are stupid people, organisations and ISPs who will resist all common sense and do the wrong thing no matter what. It is in our best interests if they do the wrong thing at the cost of the least inconvenience to everybody else involved when that is at all possible. IPv4 is now practically dead. Saving it is a waste of time. It has market value in its reduced form; let those of us who know how to exploit it to the last do so. It does not matter. It is seppuku to take no action on IPv6. Nobody here should be applying their principles to the contrary in standards. A lasting strategy to keep what's left of IPv4 is now purely transitional; no new entrants will want or need full IPv4 access, at the expense of every other legitimate user, even in reduced form, but especially not the grasshoppers who will no doubt foolishly try to create market differentiation. And when they do, they can make their case to the regional registries, using only the address space that is needed, and benefiting everybody. Wasting little drops of ARIN's resources with this allocation, by extension, is also no problem to the Hastening of IPv6 deployment; the space is used, whichever way, and to the same effect. Artificially created scarcity through non-prov ision of private space will still result in the creation of private spaces and lack of addresses. ISPs will be left communicating their incompetence in either case. Later, we can watch the live executions and tortures of management behind the IPv4 crisis. Just now, though, IPv4 is a market requirement for everybody. Simple as. We must provide. Cheers, Sabahattin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Consensus Call: draft-weil-shared-transition-space-request
On 1 Dec 2011, at 21:41, Noel Chiappa wrote: From: Sabahattin Gucukoglu m...@sabahattin-gucukoglu.com IPv4 is now practically dead. The logic here doesn't seem to follow. If it's basically dead, why do you care how the remaining address space is allocated? I don't. The marketeers do. For everybody who says, Don't worry, the IETF is there for us, IPv4 will not go away because there is always going to be a need for it, I am happy to oblige the loss of another /8, or /10, for use in some horrible NAT4 arrangement. However, it's true that I'd much rather we had botched, but available, IPv4 than full, but scarce, IPv4, because that provides the greatest benefit to everybody concerned in the current conditions, i.e., mostly IPv4. So, to the extent that people have *any* working IPv4, I care, otherwise, we can just start with the slate the IETF proposed over a decade ago now. Cheers, Sabahattin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Netfilter (Linux) Does IPv6 NAT
In case you didn't see this: http://www.h-online.com/open/news/item/Netfilter-developers-working-on-NAT-for-ip6tables-1385877.html It's a complete IPv6 NAT implementation with the functionality of the IPv4 one in the same stack. ALGs. Port translation. Connection tracking. You don't need me to tell you why I don't like this. Cheers, Sabahattin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Netfilter (Linux) Does IPv6 NAT
On 1 Dec 2011, at 01:20, Brian E Carpenter wrote: Does it support RFC 6296? That was done in a separate, non-official implementation here: http://lwn.net/Articles/451914/ With this one, you can NAT between ranges, and that's it, if I've got this right. Fragmentation is also an issue. I'm not a netfilter expert, though, so I can't say whether it's possible to implement RFC6296 with it. The checksum difference calculation is obviously going to pose a problem. Cheers, Sabahattin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-weil-shared-transition-space-request-03.txt (IANA Reserved IPv4 Prefix for Shared Transition Space) to Informational RFC
On 24 Sep 2011, at 02:20, Keith Moore wrote: To me it seems clear that the risks associated with this proposal are less than the other risks. Software that assumes that IPv4 space other than RFC 1918 space is unambiguous will break in either case. But at least with this proposal, there's a well-defined and easily-understood path to fix such software to minimize the breakage. +1, but I'm a little bit concerned about transition mechanisms which depend on exclusively upstream NAT functions rather than in addition to the CPE, i.e. DS-Lite. As it stands, the two cases can be distinguished, and it seems to me to be against this proposal, for that situation, since private addresses will probably provoke Find my public address semantics in existing software rather better than Public-seeming addresses on directly-attached hosts behind a DS-Lite gateway. Otherwise, yep, it's inevitable. Cheers, Sabahattin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: subject_prefix on IETF Discuss?
n 9 Aug 2011, at 21:56, Barry Leiba barryle...@computer.org wrote: On Tue, Aug 9, 2011 at 1:16 PM, Martin Rex m...@sap.com wrote: If one intends to actually *process* close to all of the Emails hitting one's inbox in near real time, then List-Id:, and any pre-sorting based on it, will _always_ slow down processing (unless the MUA or the processing is flawed). Whereas a subject prefix significantly facilitates tracking of stuff in a single large inbox. I'm getting 300+/day Emails and try to read 95% of it (my company internal Email is completely seperate at ~30/day, though). This makes no sense to me, Martin. Please explain why sorting based on a subject prefix will work, while sorting based on a List-ID header field will not. I think the idea is that having the Subject prefix will allow sorting by visual inspection of one folder - the Inbox - where List-id will not. I'm guilty of that habit, too, I won't deny it. But this is a red herring - of course, if you can sort matching messages into a folder, you can visually tag them, too. And you can sort them using headers not usually displayed as with those that are. Using an existing header that's already displayed in an index is just a hack, (from majordomo days, not surprisingly, and meant as an aid to broken or ineffectual mail software) and the trick is to upgrade your MUA and list software, or make do with list folders otherwise. Cheers, Sabahattin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: subject_prefix on IETF Discuss?
On 3 Aug 2011, at 21:21, John Levine wrote: happy to let those who prefer to not have such a prefix setup their procmail rules to remove it.-:) Gee, I was about to say I was happy for people who want a subject tag to add one using procmail or whatever. I'm not unalterably opposed to subject tags, but I believe that the IETF's dogfood is of the List-ID: flavor. Yes. It follows the same construction, and rationale, of not messing around with the Reply-To: field, when enough information is available in list software-specific headers to build whatever user indications or reply functionality is required. But I do understand people's desire of these sorts of tags, and I know for a fact that many commonly-used UAs simply have neither the filtering nor display capabilities to resist them. So I would not oppose a general motion to make this change. It's one less nice thing about the ietf list, though. -1 +/- 0.25 Cheers, Sabahattin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-ietf-v6ops-6to4-to-historic (yet again)
On 25 Jul 2011, at 17:30, Ronald Bonica wrote: draft-ietf-v6ops-6to4-to-historic will obsolete RFCs 3056 and 3068 and convert their status to HISTORIC. It will also contain a new section describing what it means for RFCs 3056 and 3068 to be classified as HISTORIC. The new section will say that: - 6-to-4 should not be configured by default on any implementation (hosts, cpe routers, other) - vendors will decide whether/when 6-to-4 will be removed from implementations. Likewise, operators will decide whether/when 6-to-4 relays will be removed from their networks. The status of RFCs 3056 and 3068 should not be interpreted as a recommendation to remove 6-to-4 at any particular time. draft-ietf-v6ops-6to4-to-historic will not update RFC 2026. While it clarifies the meaning of HISTORIC in this particular case, it does not set a precedent for any future case. This scares me. I was on the point of saying, But none of that stuff makes it historic! but you then change what Historic means, so that I can no longer be certain ... I'd like to see the text, but my feeling is that, no, I will not approve. That document is too loaded with dubious claims and 6to4 hate for my liking. And the advisory document is already perfect for expressing the _real_ problems, that really _do_ exist, for (current) 6to4 deployment. Once again, Historic (in whatever sense meant) is just too strong an applied label to something which _can_ be used. I have a very hard time seeing the sense in this document. But let's see the text. Perhaps you can redefine the word Historic in a new and interesting way. Cheers, Sabahattin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Another look at 6to4 (and other IPv6 transition issues)
On 17 Jul 2011, at 01:52, John C Klensin wrote: --On Saturday, July 16, 2011 16:03 -0400 Ronald Bonica rbon...@juniper.net wrote: A more likely interpretation is as follows: the IETF is not likely to invest effort in the technology in the future the IETF does not encourage (or discourage) new deployments of this technology. Noting in passing that these sorts of statements are quite close to the uses 2026 prescribes for Applicability Statements (and for which we have even more precedent and oral tradition), if the first of those is an adequate reason for identifying something as historic, I recommend that we immediately move RFC 791 to Historic. Certainly we are likely to invest more effort in the development of the technology. Now, some people would read such a move as either an indication, as you suggest above, that the IETF thought no one was using it any more, or that there were no remaining valid use cases, etc., immediately turning us into a laughingstock. But, by logic that suggests moving 6to4 to Historic on the grounds that the IETF is not going to invest effort in the technology. Quite so. And with that, you've just ruined the best April 1 gag the IETF could have hoped for, you. :-) I stopped to consider, and do again, what exactly would prevent us from taking such a radical course of action. Clearly, the view that making something historic when it's in active use is offensive. No standards body could seek to stand behind their specifications, or to give the impression of doing so, with such a position. On the other hand, as you've shown, case-by-case analysis is a good thing for document action on historic (or any other status), and there are a body of cases where the merits of documents have not shown to be sufficient for the IETF to consider it worthwhile improving. I wasn't about in the early days of the IETF so I don't know anything about these oral traditions you speak of, except to say that this is a case to be made for the force of the written word. BTW, I am among those not exactly thrilled about the idea of moving of 6to4 to historic. Cheers, Sabahattin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] Another look at 6to4 (and other IPv6 transition issues)
On 19 Jul 2011, at 02:26, Erik Kline wrote: Given that each of us reads something different into the definition of HISTORIC, is there any hope that this thread will ever converge? I don't see any progress. We may just have to blacklist any resolvers that have 6to4 clients behind them and leave it at that. Including Google's very own? Cheers, Sabahattin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Another look at 6to4 (and other IPv6 transition issues)
On 20 Jul 2011, at 00:34, Doug Barton wrote: On 07/19/2011 14:01, Sabahattin Gucukoglu wrote: Clearly, the view that making something historic when it's in active use is offensive. No standards body could seek to stand behind their specifications, or to give the impression of doing so, with such a position. Define active use. Actively being used. In production. So that taking it away would hurt the entity using it, threaten the entity's comfort and convenience, or just generally go against the stated goals of making the Internet a better place for everybody through the instrumentation and maintenance of standards. But none of us like IPv4 and that's a fact. Last one to sign the action to move it to historic's a yellow-belly. Cheers, Sabahattin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Another look at 6to4 (and other IPv6 transition issues)
On 20 Jul 2011, at 01:41, Joel Jaeggli wrote: On Jul 19, 2011, at 2:34 PM, Doug Barton wrote: On 07/19/2011 14:01, Sabahattin Gucukoglu wrote: Clearly, the view that making something historic when it's in active use is offensive. No standards body could seek to stand behind their specifications, or to give the impression of doing so, with such a position. That's a fairly odd position to take, if we do something which turns out to be a bad idea, should we stand behind it regardless of the validity of the criticism? No. But if it's in active use, we have something of an obligation to the users. The fact that it's in use is a fairly clear indication, regardless of technical quality (the review process being meant as an aid to identifying the more obvious problems before publication) that it is or can be made to be useful. That's an argument in favour. I don't dispute that protocols can turn out to be harmful, and there's a good vs bad benefit analysis to be made for lots of different reasons, but as has already been said before, the historic label is an *extremely* blunt instrument that is almost always reserved for specifications that have actually come to rest, following the logical English definition of Historic or Historical. Better for the community to be informed about the good and bad of protocols with troublesome aspects. The number of drafts, I've seen over the course of the last decade and a half with the title foo considered harmful woulkd tend to indicate otherwise. Define active use. If in fact no-one were using it there would be little point in engaging in the activity. Right, precisely. If the call weren't made, or it were made but happily ignored by everyone, I think we can take it as red that nobody minds too much. rfc 5095 and 4966 were not created to address issues that were due to protocols being dead to the world... Well, FWIW, NAT-PT is still implemented and in use, most recently for evil purposes. But once again, the designation means that the protocol has reached the end of its useful service life; there is no further use that can't be better served with our newer, shinier standards. That is something we explicitly indicate, so implementers can get on and implement the better solution. And in every case, we have Applicability statements or Reasons to move documents, so the community understands. Cheers, Sabahattin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Spurious MTU in IPv6 RAs Where WAN is PPPoE
On 6 Jul 2011, at 22:52, Sabahattin Gucukoglu wrote: On 6 Jul 2011, at 19:03, james woodyatt wrote: You're invited to file a report with http://bugreport.apple.com about this. Be sure to explain why fixing the broken path MTU discovery in the network is not an option and requiring the AirPort user to know enough about IPv6 router advertisement MTU options to set the value properly is an appropriate mitigation. Thank you, and what should the severity of the bug be? This is bug #9739722, Airport: Configurable IPv6 RA link-MTU or MSS Clamping. Severity 2. Hurricane Electric very generously lowered my tunnel's MTU to 1476 bytes IPv6 payload, so I'm now back on the IPv6 Internet again. (Yay!) There is still one important detail to clear up, though. My ISP, BT Infinity Business in the UK, seems to be ensuring that its links do not overflow by Clamping the MSS option in TCPv4 SYN packets to 1400, and no sight of ICMPv4 Datagram too large and DF set messages. Can I take it for granted that you didn't choose the same value, or do a similar terrible thing, in the Airport products? I don't have any other PPPoE servers to try it on. Cheers, Sabahattin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Why ask for IETF Consensus on a WG document?
On 24 Jun 2011, at 16:54, Keith Moore wrote: But one of the important attributes of consensus, one of the things that makes it so powerful, is that ideally, it's visible to everyone. Take the example where a bunch of people in a room are asked a question and asked to raise hands to indicate yea or nay. If only one or two people express a particular opinion, they can each see that for themselves, and that the rough consensus is clearly against them. Likewise, the other participants will be able to see that the rough consensus is on their side of things. Another aspect, one that perhaps isn't appreciated as much, is one of reconciliation. People, given the chance to understand, will wish to understand (or at least, the people in the IETF often will). They will wish to make up their differences. They will wish to make compromises. That is only possible when the consensus is in full public view, and not when it is somehow mediated by a potentially less able agent than oneself or ones other peers. In this case, anybody not in the WG got the short end. I don't say it's entirely my fault, but only because I'm wiser now than when the IESG decided to settle in favour of this document. Of course I don't have to be happy about it, but I'll understand, so long as the rationale against is for the good. A conclusion from the IESG would therefore be much appreciated, with details of how the decision was reached. From here, it looks like a bunch of objections were raised, in a place no IETF participant would expect to miss, and they were not satisfactorily addressed by the claimed supporters. Those, whoever they may be, have retreated to the shadows of some majority I can't see, in the v6ops WG which, naturally, I have no reason to be a part of because their interests are totally unaligned from mine, legitimately or otherwise. But certainly there must be some way, some definite way for people in the IETF to go to thrash out the last call period. It simply can't be all about majority, much less unseen majority. That isn't consensus, rough or not. Cheers, Sabahattin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC
On 14 Jun 2011, at 18:59, Lorenzo Colitti wrote: On Tue, Jun 14, 2011 at 10:30 AM, james woodyatt j...@apple.com wrote: Very few of the people using 6to4 in this way will show up in Google's user behavior analysis, of course, because Google doesn't run its own 6to4 return-path relay as I-D.ietf-v6ops-6to4-advisory recommends. We would not see these users even if we operated reverse path relays as recommended in the draft - from the point of view of the server, in both cases it's just a TCP connection to a 2002::/16 address, regardless of whether the relay is inside the Google network or outside it. Running the relay inside your network lets you correlate the failure rate you observe to the direction of the path the failures occur in, though. That data may be valuable to you. And since it's HTTP we're talking about, it might be a consolation to know that it's your side of the network generating the most traffic. Those users would become visible if we added records with 6to4 addresses, but that's a bad plan because it would likely lead to the double-digit connection failure rates that Geoff observes. It would also become visible if Google operated an open anycast relay, which we do not plan to do. Your (Google's) problem is the relays. So, if we take this thought a step further, by deploying (no, I'm not suggesting you do this, obviously) a 6to4-reachable presence you may actually reduce the total traffic by volume reaching you over native IPv6, if it transpires that 6to4 is a good portion of the majority of tunnel traffic, the vast majority of IPv6 traffic reaching you. That's not to speak of address selection algorithms which would do the right thing (in theory) given the choice of native or 6to4, of course. The way to find these people is to crawl the BitTorrent networks. What's that old maxim? You can't test what you don't measure. Do you measure the BitTorrent networks? No, we don't. The measurements we conduct have the purpose of determining the impact of adding records to web sites, so we don't measure the population of users that has 6to4 but does not use it to make HTTP connections to dual-stack websites. We do measure the impact of 6to4 on the reliability of websites indirectly, e.g., by observing the difference between OSes that prefer IPv4 over 6to4 and OSes that don't. That's a real shame, because the use of peer-to-peer applications is a solid reason to turn various tunnel techniques on. One popular Windows BitTorrent client makes it a single-button operation; others simply take the IPv6 connectivity for granted, when available. See: http://thepiratebay.org/blog/146 Also, is there a way we can put this debate to rest using real data? What if we asked someone like Hurricane Electric how much traffic on their network is native IPv6 vs. 6to4? I agree, this would be a good thing. That said, I would argue that most or all 6to4 traffic could just as well use IPv4, since both parties to the communication obviously have access to a public IPv4 address. What is the advantage of using 6to4 over IPv4 that makes it worth suffering an 80% failure rate? Others have beaten me to this one but I will say one thing in your favour: NAT traversal techniques are ubiquitous and, curse them, actually fairly transparent. This is probably a good thing and it does support your view that at least in the case of BitTorrent or other vanilla address-neutral protocols the end-user transparency really doesn't usually justify the added tunnels for v4-to-v4 communication, regardless of technical impropriety. However this does nothing to address other real concerns, most of them brought up by Keith already. Most importantly, new protocols or uses of the Internet shouldn't be sabotaged by the need for some sort of imaginary all-or-nothing transition to IPv6. One final thought: assuming we ever get to the stage of minority native IPv6 worth service providers' time to set up IPv6 reachability for, and not just the big ones either, what exactly do all the tunnel brokers of the world do about the sudden demand for their services? Cheers, Sabahattin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: one data point regarding native IPv6 support
The situation in the UK appears similar to the US, with the exception of some really tech-friendly, passionate and clueful ISPs: either flat-out denial that IPv6 is important, in the smaller and well-off case, or else complete cluelessness, in the larger case. For larger ISPs, especially the resident cable pigopolist, you have to go to their user support forums to read the staff opinion, i.e., IPv6 is alarmist tripe and it'll wait, no plans to support, etc. My personal opinion is that they are simply afraid; they have too much invested in a young market, and now they're overpowered by the changes required, but without progress made or anticipated, it's a vicious circle, with investors in the lead. Cheers, Sabahattin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC
Nothing to say here that Keith hasn't already said in so many fine words. In summary: +-1. Heck, no, -1000. I especially dislike the registry changes; those are deeply, *deeply* irresponsible. On 6 Jun 2011, at 18:22, Keith Moore wrote: I strongly object to the proposed reclassification of these documents as Historic. 6to4 still has many valid use cases, and there is not a suitable replacement for it that has been deployed. Until there is a suitable replacement, or until there is widespread ISP support for native IPv6, reclassification of this document to Historic is premature. (6rd is not a suitable replacement for 6to4, as it is intended for very different use cases than 6to4.) (It could be argued that reclassification of RFC 3068 (by itself) to Historic is appropriate, but that would require a separate document and last call.) In addition, this document is misleading and perhaps even vituperative. For instance: There would appear to be no evidence of any substantial deployment of the variant of 6to4 described in [RFC3056]. This statement is blatantly false. 6to4 is supported by every major desktop and server platfrom that is shipping today, and has been supported for several years. The IETF sees no evolutionary future for the mechanism and it is not recommended to include this mechanism in new implementations. 6to4 never was intended to have an evolutionary future. It was always intended as a near-term solution to allow consenting hosts and networks to interchange IPv6 traffic without prior support from the IPv4 networks that carry the traffic. It is premature to recommend that 6to4 be removed from implementations. We do not know how long it will take ISPs to universally deploy IPv6. Until they do, there will be a need for individuals and enterprises using IPv6-based applications to be able to exchange IPv6 traffic with hosts that only have IPv4 connectivity. All of the criticisms in section 3 have to do with the use of relays to exchange traffic between 6to4 and native IPv6. In many cases the criticisms are overbroad. Not all uses of 6to4 involve relays. For some of those that do need to use relays, it is not necessarily the case that the relay is operated by an unknown third-party. The fact that some firewalls block protocol 41 traffic causes problems for many tunneling solutions, not just 6to4; yet this document appears to recommend some tunneling solutions while trashing 6to4. The recommendations to treat 6to4 as a service of last resort will do harm to users and applications using it. A better recommendation is for hosts to disable 6to4 by default. This document appears to make the mistake of assuming that the purpose of applications using IPv6 is to interoperate with the existing Internet. I have maintained for many years that it is new applications, or existing applications that can't tolerate widespread deployment of IPv4 NAT, that will drive use of IPv6. I therefore believe that it is inappropriate to judge 6to4 merely by how well it works in scenarios where it is being used to talk to applications that work well over IPv4 NAT such as HTTP. The Internet is much more diverse than that, and will become even more diverse as IPv6 enjoys wider deployment. It is also premature to remove references to 6to4 from RFC 5156bis, for IANA to mark the prefix and DNS zones as deprecated. This will only cause confusion and difficulty for legitimate continued uses of 6to4. Keith On Jun 6, 2011, at 12:23 PM, The IESG wrote: The IESG has received a request from the IPv6 Operations WG (v6ops) to consider the following document: - 'Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status' draft-ietf-v6ops-6to4-to-historic-04.txt as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-06-20. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Experience with the Connection of IPv6 Domains via IPv4 Clouds (6to4) IPv6 transitioning mechanism has shown that the mechanism is unsuitable for widespread deployment and use in the Internet. This document requests that RFC3056 and the companion document An Anycast Prefix for 6to4 Relay Routers RFC3068 are moved to historic status. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-v6ops-6to4-to-historic/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-v6ops-6to4-to-historic/ No IPR declarations have been submitted directly on this I-D. ___ Ietf mailing list Ietf@ietf.org
Adventures in IPv6
This is just a blog posting, but I think it has valid illustrative points of the general frustration in it: http://bens.me.uk/2011/adventures-in-ipv6 Of course, I think the conclusion is basically wrong, *not* doing IPv6 is much worse than breaking the finger-pointing circle, and making it work by whatever means necessary. We won't make the situation better by not doing anything. And yes, I know how tired this all is, but it's starting to look like some people in this world just aren't going to be convinced until there's an actual, real crisis on top of us. Cheers, Sabahattin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Alternative to IPv6 in the Works
Hey, we do all the good gags! http://packetlife.net/blog/2011/apr/1/alternative-ipv6-works/ Well, it's good to know IDs make headlines before they've even made it into the repository directories, a sign of changing times no doubt ... Cheers, Sabahattin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
IPv6 on home routers and DSL/cable modems: FAIL
From Network World: http://www.networkworld.com/news/2011/030411-ipv6-home-routers.html Apple (except for their broken DHCPv6 client on OS X), DLink, and (although not listed in the fine article) Mikrotik RouterBoard and some models of the Fritz!Box are apparently the only contenders at the moment. Cheers, Sabahattin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: MHonArc mail archive line wrapping
On 17 Feb 2011, at 20:34, Stuart Cheshire wrote: On 15 Feb, 2011, at 13:32, Bjoern Hoehrmann wrote: That is the result of some clients and users violating netiquette and mail standards, for instance, RFC 1855, section 2.1.1: - Limit line length to fewer than 65 characters and end a line with a carriage return. I'm sure that was all wonderful back in the century of teletypes and (if you were very lucky) a 80-column VT100 terminal, but these days I read email on devices ranging from my phone at one end of the spectrum to my desktop computer with dual 30-inch displays at the other. On my 30-inch displays your hard-wrapped text appears as a thin narrow ribbon of text no matter how wide the window is, and on my phone your hard-wrapped lines are too long to fit so they get re-wrapped to that charming long/short/long/short pattern so characteristic of hard-wrapped text displayed on any device other than the one it was created on. Yes. So the people who send you messages without information in their messages for helping you to reflow the lines, in a way that does not interfere with email clients and netnews reading clients which do not support those notions, should be enticed to do so. And since you're sending such an email message, and using the same platform as I am, and since you are using all the right standards while I regularly get flamed to volcanic ash every time I dare to post to Usenet through a netnews-by-mail gateway, I wonder if perhaps you could help? Cheers, Sabahattin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
World IPv6 Day and Us
Noting the increasing length of the list at http://isoc.org/wp/worldipv6day/participants/ (now with many former staunch nay-sayers on it, pleasingly), and that the ISOC considers itself a member, I think it only right to point out that we (IETF, IRTF, IESG, IAB, ICANN, IANA, et al) are not listed. I don't suppose now is the time for an April 1 RFC discussing our commitment to the IPv6 protocol, and our intent to be present on World IPv6 day . is it? Yes, I think we probably deserve a small slice of that publicity pie, too. :-) Cheers, Sabahattin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: World IPv6 Day and Us
On 15 Feb 2011, at 18:56, Shumon Huque wrote: Maybe it's because IETF/IRTF already have their outward facing services available over IPv6 (Web, Mail, , DNS at least - I checked only for ietf.org and irtf.org). Perhaps, but the same is true for ISOC.org. Anyway, I'm not questioning ISOC's policy on the event, just making an observation. Cheers, Sabahattin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Final IPv4 Unicast Address Allocations
On 3 Feb 2011, at 19:44, IETF Chair wrote: There is no crisis, but there is a need for action so that the Internet can continue to grow. The transition to IPv6 requires the attention of many actors. However, our parents, spouses, and children will be largely unaware of the transition. They will continue to be amazed of the endless possibilities offered by the growing Internet. For them, this milestone will remain insignificant. Putting aside any bumps in the transition itself, and noting that I'm quite sure the IETF is capable of sensible decision-making in times of crisis and would wish the transition to be as transparent as possible, I think it's more often the case that reconciliation to those who do not immediately see our passions is sometimes difficult, but ultimately possible. I explained it to my social worker today, and he bookmarked the test IPv6 site, while connected to my home network with IPv6 enabled, and said he'd try it at work. I explained it to my brother and sister-in-law, and prepared them for IPv6 from their ISP. I urged every person who I was in contact with to give attention to the issues, and to be selective about who they did business with, as a precondition of acquiring new services and hardware, in order the better to further IPv6 wherever possible, and rightly so. You want to be able to explain why this milestone is such a great achievement - maybe not with any immediate effect, but an achievement nonetheless - and make your unfortunate hearer understand it. Perhaps then they'll understand what all the wasted time in revery of a great community of technical friends and colleagues is really all about. It isn't for nothing that IPv6 is such great news; it will mean a better and more fulfilling Internet for everybody who it t ouches, including every member of your circle, and will bring them even closer together. It is even quite surprising how many of them, inspired with that urgency, wish to understand it more completely than they might have otherwise, or try to imagine how a dotted-decimal address can actually be made longer. :-) Cheers, Sabahattin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Just Thinking (About the Nightmare Transition Ahead)
My thought right now is perhaps of an OS update that includes a background client which tries very hard to reduce the effect of breakage or delay caused by IPv6 routes that are dead, DNS queries that don't go anywhere, and delays caused by slow transition techniques. It couldn't be comprehensive, but I think it'd go a long way at this point. The software vendors could, for instance, provide the test sites that receive IPv6 probes and/or traffic, and respond to them. Not scalable? ... Cheers, Sabahattin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Just Thinking (About the Nightmare Transition Ahead)
On 22 Jan 2011, at 18:48, Brian E Carpenter wrote: What nightmare? I find IPv6 dual stack works just fine. It does, when your connectivity is working. Unfortunately, the 0.1% (or whatever it is) of users whose connectivity isn't working seem to be sufficient in number to prevent large sites from deploying, and a number of others to just turn IPv6 off. Not news, except I'd hate for this to be justification in keeping dual-stack from happening (the effects of which must be considerably worse than just losing 0.1% of users), especially since the publicity about World IPv6 Day has brought the whole issue to light. Of course, I'd also like Google to run IPv6 (on its main web servers) for longer than 24 hours at a time. :-) However, see draft-wing-v6ops-happy-eyeballs-ipv6 Yes. I'd love there to be some sort of consensus on it, or something like it. I'd focus more on testing connectivity, though, rather than optimal calculation of IPv6 reachability using one protocol/application to any given place at the time (i.e. rough and ready determination at OS boot whether we're on a broken network, EG). It would not be foolproof, but it would not need to be in order to be useful in the short-term. Perhaps Happy Eyeballs is the answer. Cheers, Sabahattin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Fwd: [Full-disclosure] IPv6 security myths
In the interest of fair and balanced discussion. Cheers, Sabahattin ---BeginMessage--- Folks, I thought you might enjoy the slides of a talk about IPv6 security I gave last week at LACNOG (http://www.lacnog.org). The slides are available at: http://www.gont.com.ar/talks/lacnog2010/fgont-lacnog2010-ipv6-security.pdf They are also available at the LACNOG 2010 web site (http://www.lacnog.org/en/meetings/lacnog-2010/agenda-lacnog-2010) Thanks! Kind regards, -- Fernando Gont e-mail: ferna...@gont.com.ar || fg...@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/ ---End Message--- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
test-ipv6.com: Test Your IPv6 Connectivity
Some content provider or other got busy. The tests are somewhat more real-world and exhaustive. The site doesn't merely list where you connect from, it actually gives you information (over an IPv4-only-accessible page) about the various ways you (well, your browser) can reach IPv6 resources. http://test-ipv6.com/ Requires javascript. It's too bad Windows+Teredo isn't enabled by default for resolved names. Enjoy. Cheers, Sabahattin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Fwd: iOS IMAP IDLE (Standard Push Email) Deficiency, Explanation?
Maybe my hubris got the better of me, but I didn't bargain for a complete surprise. Well, anyway, we know now why Apple does not implement IMAP IDLE in iOS. I've clearly been spending too much time around the IETF, to find Mr. Job's explanation to be completely incomprehensible. :-) (Please let me know if the Message/RFC822 part didn't come through right - thanks.) I want to ask anybody who feels strongly to the contrary to please not attack the sender (and the messenger either if you can help it :-) ). I guess I'm stuck waiting 15 minutes for new mail notifications, and running my battery down. I'm not forwarding my mail anywhere or running Exchange (or a clone). The latter, in particular, is a power-hungry option ... Cheers, Sabahattin ---BeginMessage--- Purely technical. IMAP IDLE is a power hungry standard that is not great for mobile devices. Sent from my iPhone On Oct 4, 2010, at 3:29 AM, Sabahattin Gucukoglu m...@sabahattin-gucukoglu.com wrote: If you can't tell me much, I'll understand, but please tell me at least one thing: is iOS's distinctive lack of support of IMAP IDLE (and future open push standards) driven mostly by business agenda, mostly by technical agenda, or both? I know Apple would hate to lower the bar for no good reason, and yet, somehow, this is the situation with push email notification on iOS devices, where the open standards have clear advantages. This cannot be right, and I would love to know there was a reason I've overlooked or just don't know about. Confidence assured upon request. Cheers, Sabahattin ---End Message--- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Fisking vs Top-Posting
On 22 Sep 2010, at 19:48, Tony Finch wrote: On Wed, 22 Sep 2010, Dave Cridland wrote: Possibly. It's worth noting that format-flowed, for instance, is well supported with the notable exception of Outlook. Apple's MUAs have stopped using format=flowed and now use really long lines instead, because that give better interop with the market leader. This is rather sad. It is very sad. So I wasn't mistaken - Apple Mail used to do the right thing, and now no longer does. Please file bug reports at http://bugreporter.apple.com/ . With enough Duplicates it's possible Apple will listen to reason, but ... Meantime I'll have to post to netnews using a newsreader in order to avoid being flamed to death by users of readers which decode the QP-encoding but then don't wrap the long lines, or don't do MIME. Just out of curiosity, where did you get confirmation that Apple Mail behaves the way it does for the reason it does? Cheers, Sabahattin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Fisking vs Top-Posting
On 21 Sep 2010, at 09:44, Nathaniel Borenstein wrote: On Sep 20, 2010, at 7:20 PM, Phillip Hallam-Baker wrote: One of the problems I have seen emerge on many IETF mailing lists is the habit of fisking. Please clarify what you mean by fisking. By fisking I mean responding to a post line by line *while reading it for the first time*. Thanks. And why is this a bad thing, in your view? [Snip the rest of this brilliant and audacious take.] You, sir, are owed a beer. And I am owed a new keyboard, because the coffee I was drinking is suddenly and mysteriously absent from both my cup and my stomach ... In all seriousness, forcing any particular approach is the real issue. I can't imagine how it would be accomplished. What I'd really like to force people to do is be more thoughtful and restrained; if they did that, it wouldn't much matter what approach they took to replies. -- Nathaniel +1. I do generally prefer an in-line style, and that because I wish to give full attention to the post and leave no chance of ambiguity - but I accept the utility of top-posting, on very, very rare occasions. In particular, high-volume blindness-only lists tend to prefer top-posting heavily because the readers can get quickly to the answers using linear top-down reading by speech synthesis. (No doubt it is not a coincidence that I am on very few such lists.) PS for the humor impaired -- only my last paragraph was intended to be serious. -- Oh, and now you've gone and ruined it. :-) Cheers, Sabahattin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: What does a privacy policy mean ?
On 7 Jul 2010, at 04:51, John Levine wrote: Then what happens? Is a privacy policy a contract, and if it is, what remedies do IETF participants have for non-performance? And if it's not, and there aren't remedies, what's the point? Trust? We've got to be honest and, even if it doesn't explicitly get stated in this BCP, say that there is uncertainty around what IETF participants expect to happen to their data. That's been true with particular emphasis on the meetings. Cheers, Sabahattin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
The IPv6 Transitional Preference Problem
Just in case someone here wants to take sides, have a look at this thread on the IPv6 discussion list at Apple: http://lists.apple.com/archives/ipv6-dev/2010/Jun/msg0.html (the thread actually goes back earlier than that, but I can't be bothered going looking for it because I can't stand that awful PiperMail interface) Summary: it is a problem for some people, notably content providers, that connectivity losses result from a preference to use (advertised) v6 routes. Mac OS X, in particular, has this habit of treating even the commonplace 6to4 routes, which of course fail occasionally for a number of reasons, just as native IPv6, and preferring them. It has no address selection table, so it will flunk even when IPv4 would have worked fine, i.e., will not treat common v4-NAT environment as global scope. My take: it's not their fault. Transition mechanisms must improve, because they're needed even into the IPv4 twilight. However, it's been noted before that an API for selection of the protocol based on application requirements is a solution to this particular paradox, and I agree with that. Cheers, Sabahattin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: The IPv6 Transitional Preference Problem
On 17 Jun 2010, at 13:30, Arnt Gulbrandsen wrote: On 06/17/2010 01:38 PM, Sabahattin Gucukoglu wrote: Just in case someone here wants to take sides, have a look at this thread on the IPv6 discussion list at Apple: http://lists.apple.com/archives/ipv6-dev/2010/Jun/msg0.html (the thread actually goes back earlier than that, but I can't be bothered going looking for it because I can't stand that awful PiperMail interface) What I've never understood is why (almost) everyone tries addresses in sequence instead of in parallel. Even applications that routinely open two or more concurrent connections to the server first try IPvX, then wait many seconds, then try IPvY. Why not try both in parallel and use whatever address answers first? It's Apple we're talking about here. Have a look at this for some nasty surprises: http://www.fix6.net/archives/2010/03/06/the-strange-behavior-of-apples-mdnsresponder/ Admittedly this is just for DNS, but I think it illustrates the general problem, you can't win, you can't break even, and you can't even quit the game with this one. Cheers, Sabahattin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IPv4 depletion makes CNN
On 31 May 2010, at 02:49, Phillip Hallam-Baker wrote: Or we could do what we did last time and pretend that nobody will deploy carrier grade NAT if we don't specify a way that it can work without pain. Well, I'd be interested to know what your plan is. Do you think we should use DNS for everything, SRV to specify the location of every service, and make port numbers insignificant? Do you think this is better than IPv6, or that it will take any more time to deploy IPv6? And, what do you think of the NAT scaling problem that you are proposing we mutely suffer in perpetuity? I don't like IPv4+NAT for sure (my favourite has got to be A+P) however I really don't see anything but good coming of (A) not delaying IPv6 deployment any further and (B) making every arrangement to avoid NAT in future. This seems to work for everybody except the end-users, for whom this whole thing is completely insignificant, who drag the market with them into a state of complacency. They don't care. Therefore, I think we must elongate IPv4's life as much as possible, so as to give the unfortunate time to transition, but no more. Then, content providers and end-users can continue enjoying the 'net (albeit more slowly than usual due to all that translation load for all the usual purposes) while the faster and more capable Internet gradually transitions into use. This is the best we can do given that the dual-stack opportunity passed over a decade ago, and even then it was important enough to commence work on what was, and I think is, the obvious (if a little imperfect) plan for the future. That's where we stand today, everybody capable of IPv6, and nobody connected, while the red alert signs all begin to flash. Cheers, Sabahattin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: The point is to change it: Was: IPv4 depletion makes CNN
On 1 Jun 2010, at 18:19, ned+i...@mauve.mrochek.com wrote: As I've stated previously, I believe the main piece that's missing is a SOHO-grade router that has full IPv6 support, 6to4 support, full IPv4/NAT/firewall support, plus a readonably intuitive GUI to administer it all. If such a product exists I continue to be unaware of it. I agree. With the exception (g) of a non-configurable packet filter (besides the NAT function and per-port-based IPv6), Apple's Airport Extreme and Time Capsule do IPv6 very nearly out of the box (it was disabled by default because a load of Security researchers took issue with exposing computers to the IPv6 Internet by default). In about ten clicks, and assuming your Internet connection is provided by ethernet to a global IPv4 address, these base stations will set up and advertise a 6to4 routed block for your network, and handle transparent v4/v6 DNS from one proxy. They're supposed to be able to handle custom tunnels, but bugs prevent it from working; it also works as a native router, a host on an existing v6 network, and link-local for configuration (no more slipping/forgotten netmasks). So all in all, I'm quite pleased with them, and they're the reason I decided IPv6 was no longer hard for anybody. No doubt there are others out there, or should be (IE, from ISPs) and of course there's Teredo or custom protocols if you want to stay behind an existing legacy NAT. And of course, if you want to, you can build your own with a Linux box, though I agree that sort of misses the deployability aspect, and is more toward the enthusiast, though that's how my original setup went for my DSL provider. Cheers, Sabahattin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IPv4 depletion makes CNN
On 28 May 2010, at 17:39, David Conrad wrote: On May 28, 2010, at 8:57 AM, Arnt Gulbrandsen wrote: Consider bittorrent. Bittorrent clients generally can run behind NAT, but in that case they have to be on the same ethernet as the NATbox, so it's a safe bet that the bittorrent USER has a real address. Am I stepping out on a limb if I state that most users can run bittorrent? No idea. No clue how popular bittorrent is. I was under the impression that the vast majority of folks on residential-level connections were sitting behind a NAT box. Perhaps my impression is wrong? BitTorrent is popular, yes. People at home *are* behind NAT boxes, with all the usual pain that implies *. It's just that BitTorrent, being a straightforward TCP protocol with no embedded payload addresses **, can operate behind NATs, and those NATs can be configured either manually or automatically by users or their client software ***. If the NAT should move to the ISP, it seems possible that this is no longer true. Cheers, Sabahattin * Subjective, I know, but people for whom NAT is not a problem are not full participants of the Internet, and do not use it to full potential. Most of them think the web is the Internet. I regret losing my public addresses to the cloud. ** Actually, BitTorrent does allow clients to tell trackers their addresses, for example to get around proxies; in such cases dynamic addresses are a problem, as are cases where tracker and client live on the same machine, as happens when publishing. This doesn't affect most users though, because trackers default to taking the public IP address of the connecting client as the peer address given to other clients. *** Of course, there's still a learning curve, in which users will sooner or later become acquainted with the mechanics of port forwarding and all that; it rarely Just works. I'm reluctant to admit everybody capable of comprehending this stuff at first blush; certainly there are many peers who are firewalled and thus get reduced speeds. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IPv4 depletion makes CNN
On 30 May 2010, at 16:02, Arnt Gulbrandsen wrote: On 05/30/2010 04:44 PM, Sabahattin Gucukoglu wrote: BitTorrent is popular, yes. People at home *are* behind NAT boxes, with all the usual pain that implies *. It's just that BitTorrent, being a straightforward TCP protocol with no embedded payload addresses **, can operate behind NATs, and those NATs can be configured either manually or automatically by users or their client software ***. If the NAT should move to the ISP, it seems possible that this is no longer true. Not quite. 1. Bittorrent clients connect to each other via TCP. Each connection is incoming at one end. Torrent clients mostly use UPNP to accept incoming connections. 2. UPNP is an ethernet-level protocol (it uses UDP/IP broadcasts), so it works only if the USER is on the public internet. Hence, NAT within the user's network is now very different from NAT within the ISP's network. That's why I said the wide popularity of bittorrent shows that USERS are on the public internet. Right, yes, I didn't see it from that standpoint. However UPnP can of course be substituted by NAT-PMP/PCP or something else that doesn't have the same discovery problem, and ISP-level NATs will no longer be a Problem for clients needing incoming connections even though they can no longer be said to be Public. Of course we're assuming that clients are in direct contact with their gateway here, I'm not sure how true that is, there may need to be added proxying to replicate requests otherwise. It certainly isn't impossible to do. Cheers, Sabahattin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: another document categorization suggestion
On 22 Apr 2010, at 01:55, james woodyatt wrote: After just now finding the root cause of yet another stupid interoperability problem to be an interaction between a client not choosing a sufficiently unique host/session identifier and a server being overly clever about using said identifiers for purposes other than intended in the protocol specification... WHEREAS the IETF has no document category for dealing with material that is unfit for Standards Track, that does not in any way describe Best Current Practice, provides Information of questionable utility, which is neither yet limited to Historical interest nor of merely Experimental nature... BE IT HEREBY RESOLVED that IETF should create a new document category for Disinformation, and that RFC 2516 should immediately and with extreme prejudice be reclassified as such without further discussion. I think what we're really looking for in cases like this is a document subset called RWD, or Real World Deployment. This subset comprises of notes stating the necessary information that couldn't possible be included in specifications for any number of good reasons, but which assist those implementing those specifications to avoid the next incoming arrow of misfortune that results from trying to interoperate with the incredible array of brain-dead implementations using the dubious interpretations that exist, perhaps just to the benefit of the IETF, for whom these concerns are perhaps greater than those of the vendor. As a concession to avoiding further bureaucracy, because we get enough of that as it is, and as an aid to IETF sponsorship, special offers should be made concerning vendor recognition in such documents. The hopeful consequence of this is that the subset should be modest in size, if not purpose, and will remain so for the foreseeable future. Cheers, Sabahattin smime.p7s Description: S/MIME cryptographic signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Public musing on the nature of IETF membership and employment status
On 6 Apr 2010, at 17:16, Mark Atwood wrote: Only individual people can be members of the IETF. And membership is mostly defined as who shows up on the mailing list and who shows up at the meetings. There have been many cases in the history of the IETF where well known members who are in the middle of writing standards or of chairing various important working groups, who have worked for well-known large companies, will change employers, to other companies, to startups, or to personal sabbaticals switch around between industry, academia, research, and government, and this will not, does not, and should not, affect their position inside the IETF at all. I don't see any meaningful relationship between employment status and IETF participation. That's all. As a student and as of now unemployed, I have never ceased to be a participant in the IETF, because I have wanted to be a participant in the IETF. And, as far as possible given the necessities of life, I think that's how it should be. We are all a bunch of socialists. :-) In the meantime my next job might well be decided by first my intrigue of networking, and the Internet, and next by my employer's appreciation of these same principles. Until then, my ongoing certification has a lot to do with networking. In any event, it is the IETF's wholly open nature that contributed to my involvement and interest in it, and all of the work and people that do it, so that it's very possible that these principles are why I'm in this field at all. Cheers, Sabahattin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Ok .. I want my IETF app for my iPad ..
On 4 Apr 2010, at 21:58, Tony Finch wrote: On Sun, 4 Apr 2010, Jorge Amodio wrote: On Sun, Apr 4, 2010 at 2:48 PM, Tim Bray tb...@textuality.com wrote: Anyhow, it has to be an iPad app, rather than iPhone/iPod-touch, because the smaller devices can't display 80-char-66-line ASCII properly. -T You have not seen iSSH in action then. Tim's complaint is that mobile Safari's rendering of text/plain is braindead. Compare http://tools.ietf.org/rfc/rfc5068 with http://tools.ietf.org/html/rfc5068 Does that tool reflow the indented lines to paragraphs? I am seeing each text section as what looks like one long pre element. Cheers, Sabahattin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Ok .. I want my IETF app for my iPad ..
On 4 Apr 2010, at 03:32, Dave CROCKER wrote: On 4/3/2010 6:51 PM, Jorge Amodio wrote: And what, pray tell, does an IETF app actually do? The 10 commandments of the IETF in a tablet sort to speak. One commandment for each layer? The layered model is obsolete, Dave. Everybody knows the future is web 2.0, and web 2.0 is now. Cheers, Sabahattin smime.p7s Description: S/MIME cryptographic signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: NAT Traversal With ICMP Replies
On 2 Apr 2010, at 17:18, Dan Wing wrote: -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Sabahattin Gucukoglu Sent: Wednesday, March 31, 2010 5:43 PM To: ietf@ietf.org Subject: NAT Traversal With ICMP Replies http://samy.pl/pwnat/ The idea is that NATs let back ICMP replies and send them to hosts behind them if they suspect them to be responses to messages sent from those hosts. So, by making the reply fixed and having a server behind a NAT continuously sending the ICMP query that would elicit it, a server can learn a client's IP address, and thus begin communication without a central rendezvous server. An interesting idea, for sure. Several drawbacks, though, including no provision for multiple PWNAT devices behind the same NAT. Varying the ICMP query address could resolve that, to some degree (modulo birthday collisions). It might not be super efficient, and there's the question of whose network gets all these ICMP messages. http://ws.arin.net/whois/?queryinput=3.0.0.0 Yes. We could solve the worst of both problems by assigning a *small* IANA block and arranging a blackhole for it. We only need to trigger NAT behaviour, and we get to control the ICMP payload that should be expected. Hamachi has nicked the 5/8 assignment, for its own use, to avoid overlapping private spaces (they aren't routed, of course, it's just for the communicating nodes on the UDP-encapsulated, NAT-traversing network). Although I'm absolutely no fan of NAT, I can't help thinking this little technique might just help some, considering the only alternative is peer-mediated communications. It should even work for DSLite deployment since the NATs are upstream. Cheers, Sabahattin smime.p7s Description: S/MIME cryptographic signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: NAT Traversal With ICMP Replies
On 2 Apr 2010, at 18:08, Dan Wing wrote: -Original Message- From: Sabahattin Gucukoglu [mailto:m...@sabahattin-gucukoglu.com] Sent: Friday, April 02, 2010 9:48 AM To: Dan Wing Cc: ietf@ietf.org Subject: Re: NAT Traversal With ICMP Replies On 2 Apr 2010, at 17:18, Dan Wing wrote: -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Sabahattin Gucukoglu Sent: Wednesday, March 31, 2010 5:43 PM To: ietf@ietf.org Subject: NAT Traversal With ICMP Replies http://samy.pl/pwnat/ The idea is that NATs let back ICMP replies and send them to hosts behind them if they suspect them to be responses to messages sent from those hosts. So, by making the reply fixed and having a server behind a NAT continuously sending the ICMP query that would elicit it, a server can learn a client's IP address, and thus begin communication without a central rendezvous server. An interesting idea, for sure. Several drawbacks, though, including no provision for multiple PWNAT devices behind the same NAT. Varying the ICMP query address could resolve that, to some degree (modulo birthday collisions). It might not be super efficient, and there's the question of whose network gets all these ICMP messages. http://ws.arin.net/whois/?queryinput=3.0.0.0 Yes. We could solve the worst of both problems by assigning a *small* IANA block and arranging a blackhole for it. We only need to trigger NAT behaviour, and we get to control the ICMP payload that should be expected. Hamachi has nicked the 5/8 assignment, for its own use, to avoid overlapping private spaces (they aren't routed, of course, it's just for the communicating nodes on the UDP-encapsulated, NAT-traversing network). Although I'm absolutely no fan of NAT, I can't help thinking this little technique might just help some, considering the only alternative is peer-mediated communications. Not sure what you mean by 'peer-mediated communications'. Communications mediated by a peer, like STUN or TURN. It should really be Third-party peer-mediated communications. It's nice to remove dependence on another peer is what I was trying to say. It should even work for DSLite deployment since the NATs are upstream. As written, pwnat won't work for a large shared NAT, because all of the pwnat 'servers' are sending ICMP queries using the same 3.3.3.3 address. To make pwnat work in such an environment, each pwnat 'server' would have to choose its own, non-colliding IP address to send its ICMP queries to, and the pwnat client would need to be told that IP address (and also the pwnat's publicly-visible IP address). Of course, yes, sorry. Friday-night brain flab. Somehow I got the idea we had the entire ICMP packet payload, but of course we only have the headers. Would unsolicited ICMP echo replies, containing payload, work? Cheers, Sabahattin smime.p7s Description: S/MIME cryptographic signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
NAT Traversal With ICMP Replies
http://samy.pl/pwnat/ The idea is that NATs let back ICMP replies and send them to hosts behind them if they suspect them to be responses to messages sent from those hosts. So, by making the reply fixed and having a server behind a NAT continuously sending the ICMP query that would elicit it, a server can learn a client's IP address, and thus begin communication without a central rendezvous server. An interesting idea, for sure. It might not be super efficient, and there's the question of whose network gets all these ICMP messages. Are we using it anywhere already? Cheers, Sabahattin smime.p7s Description: S/MIME cryptographic signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: What day is 2010-01-02
On 13 Mar 2010, at 14:51, Cullen Jennings wrote: I just got abused by someone reading the IESG web pages and pointing out dates like 2010-01-02 , are confusing. Is there a better way to do dates that we should be using on the ietf.org web pages? Incredible discussion so far notwithstanding, I have long since given up trying to coach people using any form of numeric date representations and now just use RFC 5322 format for everything (even when doing so is inconveniently verbose sometimes). It probably isn't suitable for an international audience for whom the non-use or partial-use of English is a genuine concern, but it by far beats trying to unify the great divide among for instance British and American notations. I am an email junky anyway. Otherwise, of course the -mm-dd makes the most sense, especially in scripts or directory listings. Cheers, Sabahattin smime.p7s Description: S/MIME cryptographic signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [rt.ietf.org #24364] mail.ietf.org. is ietf.org., Remove MX Records For Less Spam
On 26 Feb 2010, at 16:45, SM wrote: At 20:11 25-02-10, Sabahattin Gucukoglu wrote: Discussion, please. See below for my take; the IETF is one host, MX is really meaningless, and there are benefits to avoiding a ton of spambot zombie spam. While we are on this topic, which of the following methods would you recommend for a point of contact: 1. mailto [1] [2] [7] [8] [10] [12] [13] 2. email address without mailto [9] 3. AT [3] 4. at [4] [11] 5. [5] 6. email address as an image [6] The only one I object to strongly is 6, and that's because I can't see it and nor can anybody using a textmode browser. Other than that, it makes sense to avoid spam by not doing 1 or 2, although I would sooner not hide from spammers by breaking functionality, which 2-5 implies. Cheers, Sabahattin smime.p7s Description: S/MIME cryptographic signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [rt.ietf.org #24364] mail.ietf.org. is ietf.org., Remove MX Records For Less Spam
On 27 Feb 2010, at 13:49, John R. Levine wrote: there is an MX. Where did you get the idea that not having an MX offers protection from spambots? That's interesting, but not what I described. Well, OK. Let me rephrase my question: why do you believe that removing the IETF's MX record will a) decrease the amount of spam it receives? b) not damage its legitimate mail flow? Because, on inspection, both now and in the past, that is what it seems to do, for my personal domains. The difference in spam, and the apparent lack of lost mail, leads me to the conclusion that this small hack is worth the keeping, for now. Of course, I am more concerned about the lost mail, and I suspect that the IETF is more exposed to that possibility. In that case, it would be unwise. But it works for me, and given that it's in no way improper or non-standard, I don't see why it shouldn't for the IETF. Based on my experience and that of other people, neither is true. O.K. I must be very lucky indeed. Cheers, Sabahattin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [rt.ietf.org #24364] mail.ietf.org. is ietf.org., Remove MX Records For Less Spam
On 26 Feb 2010, at 05:19, Dean Anderson wrote: I get spam to hosts with MX records. I don't think removing MX records will have any effect on spam. Spambots, aren't fully autonomous agents I just transitioned my email host for a few small domains, and didn't trouble to bring along the MX records, because I didn't have to. I noticed the IETF didn't have to either, when it kept rejecting my IPv6 connections for not having Reverse DNS (fixed by preferring IPv4 for now). It's not the first time, and this technique is still damned effective. I added MX records just to reassure myself, and indeed I was being spammed at my usual 300/day level within almost half an hour of my name servers being updated. Now I'm waiting for the TTL to expire the record on caches. I'm convinced that is useful, anyway. Sure, it's a short-term hack (like all spam countermeasures), but it works. And why should we be afraid of standards compliance, in the very organisation that standardises? existing independently, they are programs written by people who want to conduct abuse for some purpose (annoyance, extortion, etc). The ones I'm talking about are distributed by viruses and trojan horses. They run on Windows, of course. They receive their instructions from the botmaster to spam a list of addresses with the spam content, and they do it directly using the MX resolution process. They barf when MX records fail to appear in a query result for MXs of a domain, for the most. Regarding the effect (if there even is one) of skipping domains without MX records, there are only two cases to analyze: Its either an oversight in the program, or its done on purpose. Even supposing their current programs skip domains without MX records by some oversight, the spambot programmers will easily fix that. Supposing the current programs skip domains without MX records on purpose, then do you really want to go along with whatever purpose that might be? I wouldn't. Spam is a social problem that cannot be solved by technical means to any degree of satisfaction; we only put up with the methods available because they're all we have. Every filtering technique other than manual inspection is subject to attacks, even the best ones, and as long as there's a gain in doing so that will continue to be the case. On that basis, even if there were something wrong with removing MX records for a single-host domain that just happens to be called ietf.org. and have aliases of mail and www, and I personally don't think there is apart from the possibility that it may lose some broken MTAs, it is a valid spam prevention technique until spammers take their dozy time (and, if we're honest, quite low cunning as well) to fix their agents, just as they do with every other kind of filtering out there. The IETF is one domain inhabited by a bunch of guys, so frankly I don't think it will be all that soon when so much of the world is happily being spammed to d eath on redundantly-hosted mail servers. And even if it isn't a silver bullet tomorrow, it's a useful metric nonetheless, just as graylisting was before it was totally failed and made blacklists the only way to use it conveniently. But I do find it noteworthy that the IETF doesn't even follow its own recommendations on email. The level of IETF spew, by which I mean telling other people what to do by issuing standards while not doing it themselves, grows more ever day. This incident is another discredit to the IETF, particularly to the leadership of the IETF or perhaps the IETF secretariat, that I will have to document at IETF watch. I want to say that I would *prefer* that MX records be published for host which *do not* receive mail. This is considerate since it allows mail originating from a host to be answered, or for postmaster to be reached. I also want to say that I am in support of the Purist point of view with regard to fallback since it allows any host with a name to be part of the SMTP infrastructure with no added configuration in DNS by properly using the semantics of addresses in DNS, before the use of MX muddied the waters sufficiently. There can therefore be no doubt that any software relying on the existence or not of MX records as license to *send* mail is broken since RFC 974. I don't want to start a debate on these points, at least outside of ietf-smtp, since in neither case does it wrong the secretariat with regard to the use or not of MX records, but I will say I have been a little bit surprised by the force of responses so far. I would be much obliged if the required work were done for clarifying any opposing view to current standards. Cheers, Sabahattin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [rt.ietf.org #24364] mail.ietf.org. is ietf.org., Remove MX Records For Less Spam
On 26 Feb 2010, at 15:42, John Levine wrote: mail.ietf.org. is ietf.org., so you can remove your MX records for ietf.org. This should cut down on spam since a lot of spambots will skip over domains whose MX list cannot be obtained. Real mailers will of course fall back to A/ as per RFC 2821/5321. A few hosts will have trouble, but very, very few indeed, and that isn't your (our?) fault. I checked with some people who run mail for a lot of domains, and they assure me that spambots will try to deliver to the A record even if there is an MX. Where did you get the idea that not having an MX offers protection from spambots? That's interesting, but not what I described. To answer your question, you'd have to try that for yourself. I am now getting mostly phishes and scams, but very few member enhancement, expensive watches, wonder cures or viral mails. A few, of course - but not many. And yes, some of them are originated from PBL-listed addresses. Oh, and an IPv6-enabled foreign language spam or three. Lovely. The spammers have got there first. Brief and superficial inspection shows that the scams and phishes are submitted mostly via webmails and legit relays. I'm not sure why that is, though I have read stories about hijacked Internet cafes. Cheers, Sabahattin smime.p7s Description: S/MIME cryptographic signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Stub DNSSec Resolution, Or Use DNSScurve
I'm thinking that maybe there's something in having DNSCurve be used for one leg of the journey, between customer and cache. Then the cache can use DNSSec to get the desired validity of data, withstanding all attempts to subvert it, and not needing to depend on any tricky key retrieval process that is out of band of the security mechanism. Will it work? Should it work? Is it reasonable? And why aren't stub resolvers being encouraged to do their own DNSSec validation? Cheers, Sabahattin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Stub DNSSec Resolution, Or Use DNSScurve
On 25 Feb 2010, at 14:14, Tony Finch wrote: On Thu, 25 Feb 2010, Sabahattin Gucukoglu wrote: I'm thinking that maybe there's something in having DNSCurve be used for one leg of the journey, between customer and cache. That won't work because DNScurve gets its key from the server name, but recursive servers are configured by IP address not by name. We would have to initialise clients, perhaps with a local DHCP option, giving the initial key. I don't see how you get full trust any other way. Cheers, Sabahattin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Fwd: [rt.ietf.org #24364] mail.ietf.org. is ietf.org., Remove MX Records For Less Spam
Discussion, please. See below for my take; the IETF is one host, MX is really meaningless, and there are benefits to avoiding a ton of spambot zombie spam. Begin forwarded message: From: Glen via RT ietf-act...@ietf.org Date: 25 February 2010 18:16:44 GMT To: m...@sabahattin-gucukoglu.com Subject: [rt.ietf.org #24364] mail.ietf.org. is ietf.org., Remove MX Records For Less Spam Reply-To: ietf-act...@ietf.org in-reply-to: 30d38818-daa2-4439-a168-3aed6b3e0...@sabahattin-gucukoglu.com references: rt-ticket-24...@rt.ietf.org 30d38818-daa2-4439-a168-3aed6b3e0...@sabahattin-gucukoglu.com message-id: rt-3.6.5-24276-1267121804-1766.24364-...@rt.ietf.org rt-ticket: rt.ietf.org #24364 rt-originator: g...@amsl.com Thank you! Regrettably, we got many MANY complaints in the past from IETF community members who objected strongly to the absence of MX records. So although I personally feel as you do, I cannot make the suggested change at this time. Perhaps the spirit of things has changed. You are welcome to bring this up on the IETF list if you want, and to quote this response. Having been beaten down once, I'm not prepared to fight that battle again just yet. :-) Glen On Thu Feb 25 06:08:22 2010, m...@sabahattin-gucukoglu.com wrote: In the spirit of abiding by the rules we strive so hard to write ... :-) mail.ietf.org. is ietf.org., so you can remove your MX records for ietf.org. This should cut down on spam since a lot of spambots will skip over domains whose MX list cannot be obtained. Real mailers will of course fall back to A/ as per RFC 2821/5321. A few hosts will have trouble, but very, very few indeed, and that isn't your (our?) fault. Cheers, Sabahattin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IAB statement on the RPKI.
On 17 Feb 2010, at 22:24, Masataka Ohta wrote: Martin Rex wrote: DNSsec, as far as I can see, does not use a PKI in the traditional sense. There are _NO_ persons involved in the process, FYI, zones are operated by people. I can forge a key of your zone. I can, then, ask a person operating a parent zone of yours to issue a valid signature over the forged key. Yeah, but at least now we know the difference between the subversion of the Chain of trust and some bloke with a packet sniffer. As soon as the Integrity of the Chain of trust becomes obviously broken, for whatever reason, it's totally within our power to do what we do now, and ignore it. The point here is, we now have a way to verify the technical functions we depend on today are working properly. It isn't about reputation or the trust of any given person or entity, any more than it is now. I can *still* find ingenious ways to bribe or subvert or otherwise make your registrar publish records of my control and design that pertain to your domains, with or without that verification function. Well, I could if I were sitting at the top with lots of money and nothing else to do. But when the data we receive is authentic from the intended, authenticated source, we have a chance to assign our own trust policies as we see fit (and it may be, though I doubt it, that I find the bloke with a packet sniffer a more reliable source than ICANN). The utility of online banking and shopping, as certified by some sort of certification authority about whom we know next to nothing, suggests that we prefer some - any - degree of accountability, and the result of some CA being s loppy has always (and will continue to be) grounds for distrust. And the same has applied as well to webs of trust, like those of PGP, where some degree of fuzzy logic is applied to make multiple vouches constitute more solid evidence of Trustworthiness. Single roots may present problems when there is no other root, but never to the extent of being an unchallenged authority, and certainly not to the degree that the Internet would experience an irreparable divide. The problems only really show up when people get involved, and that's why certification authorities are so rich. Cheers, Sabahattin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: rfc3848 (ESMTP and LMTP Transmission Types Registration) to Draft Standard
On 25 Nov 2009, at 19:34, The IESG wrote: The IESG has received a request from an individual submitter to consider the following document: - 'ESMTP and LMTP Transmission Types Registration ' RFC 3848 as a Draft Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. This is good. Sendmail's covered with the standard cf rules, except that LMTP only works without extensions (I haven't checked whether that's relevant for Sendmail, or indeed how one might change it without rewriting the header lines by hand, but I'll say it's probably possible). I still can't think what use the keywords are, actually, for receivers. Perhaps somebody could explain it to me? Cheers, Sabahattin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: RIM patents using a mime body in a message (and ignores IETF IPRrules)
On 19 Nov 2009, at 19:32, Dan Wing wrote: Rescinding RFCs-to-be only based on late disclosures may set a precedence for the future we may not like. Doing so would provide an incentive for the patent holder to delay disclosure until after the RFC is issued. IETF lacks a censure policy for such violations. Maybe we need one. I have a suspicion that part of the problem is that in cases like this one, the IETF has demonstrated a will to validate IPR all by itself, which is fine except that nowhere that I know of have we publicly expressed our dissatisfaction with the vast majority of what passes for Rescindable, preferring instead to do without at the time the disclosure is made. A BCP stating, Patents are a nuisance, be told, and we'd sooner be without them. would seem to suit us well in cases where outsiders might otherwise be tempted to play fast and loose with the rules, perhaps this would encourage more upfront disclosures and, thereby, acceptance of reasonable and non-discriminatory IPR. And can the IETF deny its preference for non-patented work? I take no sides myself, I just want us to live in peace and harmony. Cheers, Sabahattin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: OK, final NAT66 argument (Was: NAT Not Needed To Make Renumbering Easy
Sorry in advance for the length of the post and, in parts, the rudeness of my spleen. On 8 Nov 2009, at 17:55, Phillip Hallam-Baker wrote: I assert that regardless of whether NAT66 is a good or a bad thing, anything that layers on IPv6 must be NAT66 tolerant. In the whole of the foregoing discussion about NAT and IPv6, the question that I'm only really left with is whether or not we actually lost anything by doing NAT. I have never seen the link between the application layer and the network layer (or whatever you call these things, Layer being a highly inadequate term), and taking the effects of NAT and the resultant protocol drain by way of example, now no longer See what end-to-end connectivity is good for ... Until I remember FTP. And SIP. And IKE... And I question the quality expectations and degraded service the Internet's users have endured. The attitude is no longer that Address exhaust came, NAT pushes back the emergency but If it weren't for NAT, we'd have run out of addresses by now. You know, as if the botches we take for granted today are in any way good, as though the strategies we know and love to get around NAT are in any way acceptable, as though replacements for NAT-unfriendly protocols are somehow heavenly and divine. And whose idea was it to make the above protocols easily dependent on universal addressing, anyway? Was it necessary? It would only be fair to wonder how FTP and SIP would be, if designed today. It would be a shame not to mention WebDAV and, oh, Skype. And SIP, done today, would probably depend on connection reuse, fixed ports and no payload rewriting to get around NAT, those features being both desirable in NAT and of presumably great use in circumstances where realm translation happens, as with proxying where translating the IP or application header is absolutely the most you can do and where, presumably, NAT or similar can actually be justified for those who simply must have it. But one thing's damn certain, I will never, ever, ever configure a passive-mode FTP server behind a NAT ever again - not so long as the gateway supports FTP ALG but only if the behind-NAT FTP server pretends to be oblivious to the existence of NAT, while flopping completely if you try to be clever and set up ports and addresses to be given to clients. Worse yet, if it uses UPnP to open the needed holes. Do you care for a healthy Internet? I do. That sort of thing is beyond me, and I want somebody to tell me it's okay and it will all be over soon. And really, a lot of the excuses people give for keeping NAT are highly lame, in many instances suboptimal even for their intended purpose (source address spoofing behind NAT is my favourite argument against security held to be a value of NAT) and generally miss one or two points about the initial, healthy development of the 'net unencumbered by NAT. For a particularly aggressive take: http://www.fourmilab.ch/speakfree/ link And, of course, RFC 2993 is standard reading. So yes, I need to know why we put up with NAT, or why you think others should. I also need any justification you may have about why end-to- end is wrong or never held for the Internet's design, and if it did, why it did. While folk can postulate alternative universes in which enterprises will not demand or vendors refuse to implement NAT66, there is another area that is harder to wish away. Observation: Without NAT44 the internet would already have run out of address space. I don't think this can be seriously disputed. But see above. Observation: Without NAT46 and NAT64, we cannot transition from IPv4 to IPv6. Not now, no. It was the grand master plan though, back when. And, yes, capitalism and managers are to blame and, no, I don't feel the slightest sympathy for the slow movers who end in hot water because they didn't plan ahead. Really, it's a crisis whose only quandary is money and is entirely of their own making, and if they can't see beyond that point, it doesn't matter if they lose business. I don't know why the IETF keeps its hands out like that, when for years the clean start proposal was, while perhaps rather optimistic, perfectly adequate and, on the whole, of sound engineering. But now, vendors have begun pedalling the latest in CGN, and I'm tempted to imagine that if the transition had begun sooner there's a very real possibility the impetus and usefulness of IPv6 would have made the notion of CGN infeasible and unsellable. And don't get me started on the silly proposals to recycle unused IPv4 address space, they won't work longer than five minutes a time. Any market value those addresses may have is significantly outperformed by the real benefit of IPv6, when IPv6 is all there is to give. Still, FWIW, I see the transition this way: CGN (carrier-grade NAT) will happen now and in response to future demand on
Re: NAT Not Needed To Make Renumbering Easy
On 8 Nov 2009, at 16:22, Phillip Hallam-Baker wrote: There are two typical modes of deployment for IPSEC, the first is as a lousy remote access protocol where the lack of NAT support makes it far more effort than other solutions. SSL and SSH remote access just works, IPSEC VPN may or may not work depending on the phase of the moon. The third party clients are terrible, the built in support in the O/S is unusable because it does not have the tweaks necessary to get through the firewall. So we do not really have a standard for IPSEC remote access. There's at least one product making actual money in this space, Hamachi ( http://www.hamachi.cc/ ). Basically third-party-mediated IPSec-lite that goes over NAT. If you must use NAT, at least be aware of what can come back to your network due to NAT behaviour and internally initiated connections. I don't think NAT is providing the right kind of security here. But I must be careful not to start another flame war. But anyway, IPv6/Teredo does the same thing, and better; Microsoft is working on going that extra mile with IP over HTTPS, too, so soon we'll have peer-to-peer VPNs that really do Just work. In every case it is better than Hamachi's use of unassigned address space, and in no case better than fixing the trouble at the root, and shredding NAT. But, if NAT's your thing ... Cheers, Sabahattin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
NAT Not Needed To Make Renumbering Easy
Not in the IPv6 address space, anyway. And if it is, there's something wrong and we should put it right. Just been reading IAB's commentary on IPv6 NAT. It seems to me that we are perpetuating the worst technology in existence *simply* for one feature, network mobility, that is better served by proposing new techniques and technologies and, in particular: we need a simple way to express host relationships inside an organisation that is independent of external homing. I refuse to suffer because of NAT any longer and don't want to accommodate those that prefer it. If IPv6 does ever get wide enough deployment, and I truly hope it does, I might just *give up* things to accommodate the trouble-free life that is no NAT. What do we have right now, first? Cheers, Sabahattin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: NAT Not Needed To Make Renumbering Easy
On 25 Oct 2009, at 17:42, Noel Chiappa wrote: From: Sabahattin Gucukoglu m...@sabahattin-gucukoglu.com in particular: we need a simple way to express host relationships inside an organisation that is independent of external homing. Well, it would really help if we had more namespaces available to name things in. Oh, wait... It needn't be so bad. There are basically two solutions: 1. We rely on everybody to instantly fall in love with NND+SAC, taking care of the Network layer. We devise a language, syntax, rules or whatever it is to describe nodes inside a variable-length prefix assigned by an RIR, that people who ought to know better can write their firewall rules and their DHCP server configurations and their management tools and whatever with. This happens at the Application layer, and applies the simplicity of rehoming (or maybe even multihoming) to every situation where the primary prefix is the only variable. Since it performs its duties on a presumably infrequent basis, the implementation does not have to be at all low- level. Or: 2. We give up all hope of avoiding NAT, even point-to-point NAT, and either devise the ultimate NAT-PMP replacement to make the application layer know about the deception happening (or write an API overload that makes the same thing happen in sockets) or rewrite or adjust all protocols, or replacements for protocols, so that they don't have to know or care about translation. I'm for 1, though perhaps somebody could explain why the latter option in 2 is infeasible and/or principally violates good protocol design (encryption, performance loss and all that notwithstanding). Did FTP really need to be so damned inconvenient to run behind a NAT? Cheers, Sabahattin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: RFC archival format, was: Re: More liberal draft formatting standards required
I just *knew* it was a mistake to Leave this thread for later ... On 3 Jul 2009, at 18:04, Pete Resnick wrote: On 7/3/09 at 10:16 AM +0200, Iljitsch van Beijnum wrote: On 3 jul 2009, at 0:35, Pete Resnick wrote: A much better solution would be HTML, if it's sufficiently constrained. Or, gee, we could generalize to a very constrained XML format XML isn't a display format. And how is this responsive to what I said? Applications of XML (e.g., XHTML, xml2rfc with associated XSL files) provide perfectly good display info that are currently in use by all sorts of display platforms. The choice of a particular markup language is irrelevant to the overall issue: We need to have text and semantic markup, instead of text with spaces and control characters to do page formatting as our canonical format. Hmm. Generalisation is good. Semantic markup is also good. But ASCII has a good standing and a thoroughly good reason for being, and probably continuing to be, a canonical format. We are at nobody's mercy. Now, I'm not for disputing the usefulness of XML or whatever other format becomes popular. For HTML, for example, my screen reader has keystrokes to jump to the next heading, or to list them for me to select. I would want whatever we choose as the alternative markup stored in the same repository, and to have the same chances of being used as the ASCII by those who need preprocessed output, for whatever purpose, on whatever device. I think this is somewhat optimistic, though; either it creates more work for people who have quite enough to do already just writing this stuff, else it precludes many existing and perfectly good historical documents whose chance of conversion to other formats now are somewhat limited by, for example, wishwash in the current format variations. On the other hand, as a writer I am not exactly enamoured by the choices available. I just want to write. I'm blind; without my £5000 (sorry, l5000 :-) ) braille display on hand, and without brltty on Linux, I cannot feel my way around the document; get the indentations right, the line count right, the line width right. And even if I could, it's very tiresome. xml2rfc does peculiar things all of its own; even as a Tcl lover I'm not happy with its weird tendency to add extra whitespace where it shouldn't be, or to make bold assumptions about the author's ecstatic desire to write perfect XML, or the somewhat less semantic HTML it generates, or ... I just want to write, straight long lines, one a paragraph, with YAML-style section delimiters, no boilerplate. All that pretty-printing is someone else's problem, I just want to put an idea into a starting-point draft. So I'd be much gratified if somebody could, or could give me the encouragement to, write such a scheme up and then code it, probably in Tcl. As Dave put it, the current RFC format is unfriendly, unnecessary, possibly unethical and just plain wrong. I'd remove the possibly. Please elaborate; this statement goes far beyond the inconvenience of having fixed line and page breaks and the lack of non-7-bit- ASCII characters. You bet it goes further: The current format is a horror to anyone who has to read the document on anything that does not visually display 80 columns of fixed-width text. Try reading the text on a small handheld device. Try doing so with a text-to-speech application. Try magnifying it using apps meant for folks with limited vision. We have the ability to create text in a format that is easily interpreted by all of these devices and presented to the user with no loss of information. Using a page-layout format for our standards when page layout is completely unnecessary is at a minimum unfriendly to folks who want to use such devices, and (given that it is unnecessary to use page-layout) it is downright unethical and wrong to make it harder for folks who must use such devices. Wo! Brave assumptions! For me, ASCII is *why* I read IETF standards, almost in preference to other organisations. Clean, one-spec-a-file, consistent naming, can be further preprocessed if desired (as above: to an extent), 7-bit for display using all known braille codes on all braille displays. Truly, as I've said, ASCII is a splendid lowest-common-denominator choice of format. About the only hindrance for text-to-speech and braille alike is the headers and footers; they make no sense even on common textmode terminals, interrupt the perfect flow of speech for no reason, and are just annoyingly redundant. Remove those, and I think we have a perfect ASCII representation. Not being able to use characters in documents outside of the US- ASCII set is inconvenient (when they are part of the data stream of a protocol you wish to describe) and unfriendly (when the personal information about contributors cannot be properly provided). I'll leave off
ops.ietf.org Blacklisting Complications
ops.ietf.org is hosted at psg.com, which uses blacklists from the MAPS. I take no position on either MAPS or the external hosting, but I object to the use of RBLs for filtering IETF traffic. This seems to go against the IESG spam policy statement, which makes it quite clear that participants should not be disrupted (although not necessarily to the extent that it forbids RBL use). http://www.ietf.org/IESG/STATEMENTS/spam-control-policy.html My mail to ops.ietf.org itself isn't filtered, but my mail to psg.com is. I am using a Google smarthost with Google Apps. I do not consider myself a spammer and don't reflect my neighbours reputations, good or bad, upon myself, in order the better to assist the agenda of RBL operators. I don't know what Google's reputation is, but I am using their service because I find it reliable. There is simply no reason to block the legitimate traffic. But psg.com processes mailing list requests for ops.ietf.org, and every time I want to send mail to ops.ietf.org I have to carefully rewrite it. If nothing else, I want people to be aware of the situation. I would, of course, like ops.ietf.org to fall under proper IETF administration guidelines. Cheers, Sabahattin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Decentralising the DNS
Silly question, I'm sure - any chance of putting the DNS into a gigantic DHT and spreading the entry nodes liberally about the planet? Cheers, Sabahattin PS: No political agenda implied. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Decentralising the DNS
On 12 Jun 2009, at 16:43, Tschofenig, Hannes (NSN - FI/Espoo) wrote: The idea to put something into a DHT has been suggest for almost everything by now, including the DNS. If you search for DHT DNS then you can find a couple of papers. Thanks, but it actually occurred to me that it didn't solve the problem of authority, which is really the source of the DNSSec trouble. (Can't say I'm all bothered about the current situation; it's been this way for years, after all, and there's still a release mechanism.) The issue was trust, and the need for delegaters to control what they delegated, unless of course we change the whole registration model. Hmm - might be more than the 'net can stand just at the moment. Cheers, Sabahattin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNS Additional Section Processing Globally Wrong
On 4 Jun 2009, at 04:06, Mark Andrews wrote: In message aaab52ef-ad0a-4d3c-9b28-b864f342d...@sabahattin-gucukoglu.com , Sabahattin Gucukoglu writes: The problem is this: the authoritative servers for a domain can easily never be consulted for DNS data if the resource being looked up happens to be available at the parent zone. That is, bigbox.example.net's address and the RR's TTL can never be as specified by the zone master unless he or she has control over the parent zone's delegation to example.net if bigbox.example.net happens to be serving for example.net. (Registries give you address control, of course, but often they fix on large TTLs.) As far as I can tell, every public recursive server I can reach, dnscache and BIND9, and one Microsoft cache and one of whatever OpenDNS uses, all do the wrong thing (TM) and never look up true data from authoritative name servers. They hang on to additional section data from the delegating name server and pass this on as truth, the whole truth, and nothing but the truth to everybody who asks. Except they don't. What you may be seeing is parent servers returning glue as answers and that being accepted. Glue data, additional and non-authoritative by design, intent and specification, aren't what I want caches to keep. The data I spent my lunch hour putting into my zone file is. :-) As a matter of fact, it never occurred to me to wonder at this misbehaviour - it clearly wasn't that much of a big deal when I was running things myself - but the 2008 cache-poison attacks found me surprised that this is how it is. In particular, they only worked because the cache was happy to keep additional data for hosts that were pertinent to the query, but in which it had no business caching. If it had instead chased up the referal, the attacker would at least have had to run a nameserver to answer the Is it really you? query. Cheers, Sabahattin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
DNS Additional Section Processing Globally Wrong
... it's that, or my reading of RFC 2181 has gone horribly wrong. The problem is this: the authoritative servers for a domain can easily never be consulted for DNS data if the resource being looked up happens to be available at the parent zone. That is, bigbox.example.net's address and the RR's TTL can never be as specified by the zone master unless he or she has control over the parent zone's delegation to example.net if bigbox.example.net happens to be serving for example.net. (Registries give you address control, of course, but often they fix on large TTLs.) As far as I can tell, every public recursive server I can reach, dnscache and BIND9, and one Microsoft cache and one of whatever OpenDNS uses, all do the wrong thing (TM) and never look up true data from authoritative name servers. They hang on to additional section data from the delegating name server and pass this on as truth, the whole truth, and nothing but the truth to everybody who asks. This means that if my machine happens to be serving for my domain, I'll never be able to reduce the TTL to a reasonable value for my dynamic conditions. Even if, in all seriousness, going ahead with a dynamic address is a nuisance, is this use of additional data not fundamentally broken? If there is consensus on the wrong behaviour, I'd like it written somewhere, so I can feel happy about it just being the way it is by implementation, common sense, performance, or whatever. Then I can conform to reality by just using a separate name in delegations. Alternatively, if *I* wrote a DNS cache, I'd simply use non- authoritative data, and expect it, only when necessary: as soon as I've chased whatever referals are necessary, I can throw it away. I can rely on two things that make this reasonable: (I) that it's the requested RRs I'm interested in and not the delegation, and (II) that I can get, and will often get, better additional data from authoritative name servers that I have no reason not to hang on to and, as needed, to propagate. Besides, it's easier this way to detect discrepancies between the delegation and the zone master. Cheers, Sabahattin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Proposed IESG Statement Regarding RFC Errata for IETF Sream RFCs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, How does Joe Implementer become aware of RFC errata available? I don't recall seeing anything in the standard boilerplate to point them out. (And although I'm aware of them myself, I'd quite forgotten about them.) Cheers, Sabahattin - -- Sabahattin Gucukoglu mailatsabahattindashgucukogludotcom Address harvesters, snag this: [EMAIL PROTECTED] Phone: +44 20 88008915 Mobile: +44 7986 053399 http://sabahattin-gucukoglu.com/ -BEGIN PGP SIGNATURE- Version: PGP 8 Comment: QDPGP - http://community.wow.net/grt/qdpgp.html iQA/AwUBSAjy8CNEOmEWtR2TEQJsoACgr7hRHar3Z/gz3cs6eFR2YgDF70wAniY1 7xMsA13D57fMxZlERk2rcO3S =SM9g -END PGP SIGNATURE- ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Proposal For Token-Based Authentication In Mail Submission As Anti-Forgery Effort
On 6 Mar 2004 at 8:08, Vernon Schryver [EMAIL PROTECTED] spoke, thus: From: Sabahattin Gucukoglu ... and important catch in this proposal, that being a modification to all MUAs and MTAs to allow the acceptance and carrying of a password token which should persist throughout the entire mail delivery, ... My proposal is a scheme for anti-forgery, which makes use of a non-blank token, or password, which can be verified by a recipient system ... How does your scheme prevent forgery better than SMTP-AUTH, SMTP-TLS, S/MIME, or PGP? Most MTAs support SMTP-AUTH and SMTP-TLS. That should, you're right, be Sender forgery. SMTP Auth is not carried from host to host and only guarantees some privileged user his rights, such as relaying or submission, during any given transaction; it doesn't permit an end-to-end verification of sender across multiple hosts, necessary for normal mail delivery. It doesn't (or shouldn't) prevent any mail from being delivered at all to a domain if the destination host is an MX for that particular domain, regardless of any details of the mail. There are issues concerning today's worms/viruses that make port 25- blockage on all but the local smarthost more plausible and reasonable, too, and the submission port won't take long to follow when the next gen of worms flood the net. I don't like it, y'know, but I'm ready to *g* face it. It is, in summary, useless as a measure against sender forgery in short term, and I'm ready to bet long term as well, despite having its real uses as a trusted submitter/relay-permitted client authentication method. Good security practice to keep hackers from hopping your firewall and trying to relay through your system from a local vantage. PGP is strictly per-user, and isn't practical for mail delivery. Use of it for quality spam detection to any useful worth is akin to whitelisting, and PKI infrastructures and corporation-determined trust are a point of weakness (as you say, below). Same for StartTLS and S/MIME, even if TLS *were* encouraged to global use. If any of these were at all useful, they would either need to be updated and/or used and deployed almost immediately, which is obviously impractical. At least this means holds as much configuration and balanced (and uncontrolled) distribution as DNS itself, not to mention gentle backward compatibility. The difficulties in preventing spam sender forgery are not in defining token protocols but in - defining forgery in a way that excludes common, legitimate practices. This proposal attempts exactly that! Other proposals we've seen all depend on administrative configuration which predetermines some particular aspect of mail delivery, i.e. IP addresses from which any given mail should emerge for a particular domain, all of which harm - as you say - legitimate transactions. This scheme leaves that choice to the user. Admins simply maintain a list of user-chosen passwords, and it is the user who, by providing the correct password to his MUA when submitting mail through his work's MTA under his Hotmail address, guarantees its delivery when, at the other end, the user's password (not his domain name, not his IP address) is verified against the same password at the user's home domain - Hotmail - by a query from his mate's MTA a moment later. Why isn't sending mail with your Hotmail account as sender while sitting at your desk at work or with your work sender address while in a customer site, hotel room, or airplane forgery that would be prevented by the proposed sender-verifying mechanism? Again: only the password is verified! Forgery is now dependent only upon the misuse of the password. The administration of the domain referenced in the envelope sender is now soley responsible for any of its spamming users, case by case, and there is no opportunity for a domain to be misrepresented provided those passwords are the cause of the mail's acceptance. That is the whole point! I *do* hope you read my entire message ... but let's suppose you didn't. If you are suggesting that all those things really *are* forgery, then I'm afraid I'm addressing the wrong person for comments. I'm going to suppose - to hope - that you don't. I appreciate your need for good sense and conservatism, all the while encouraging good and useful inovations in SMTP, and I'm trying hard to strike that balance. The sacrifice, and there always is one, is an additional piece of user information, a token. Only difference between that and the SPF is that the token is supplied by a user, not an administrator, and goes wherever the user goes. I believe in the use of TLS for security, in SASL for avoiding problems with IPV4 (spammers hopping ACLs to get relaying permission), for guaranteeing relaying when you need it in the car on the way to visit Auntie Jane, or whatever. I don't, though, believe in sitting at a local cafe
Proposal For Token-Based Authentication In Mail Submission As Anti-Forgery Effort
creating his/her account with his/her ISP. MUA of user must add a submittal password field in its configuration. User must be permitted to change stok whenever he wants with his provider, perhaps using a provided protocol/service as in POP3PW. 3. Security depends on the protection and unguessability (sophistication) of passwords. Those tokens will contain no whitespace characters but may contain legally permitted characters in SMTP transactions. If a spammer gets hold of someone's password, we're back on square one. Thing is, the password tells us, without a doubt, who the abusing (or abused victim of identity theft) was. ISP disables that password, all is good again, and we can also trace abused/abuser with much greater ease. Naturally, we don't want to put the password out to the public. 4. MX policy decides whether stok is sufficient enough both to accept/reject/tag/whatever mail, and also whether it is now safe to lower open relay or other barriers. However, I personally advise caution - unless you can be sure that spam from other than forged domain envelopes will not in big part emerge through your server, perhaps because you bother to do the A-RR check and also check the existence of a given domain, don't do it. The short is that this is intended to be forgery protection to go hand in hand with other means of spam detection and help alleviate the awful blockage of loads of innocent hosts, and maintain your freedom to use any relay in your power, not to encourage open relays; I just hope one day the usefullness of such a system will make it plausible in the future to do so again. 5. A password query was picked rather than a password list because it does away with both too much complexity and the whole issue of how to keep the list away from one pair of eyes and available to another. 6. The insentive to move to this type of standard would be that final MXs will start refusing, or marking as spam, any unauthenticated submittals. 7. The use of the envelope is yet to be dreamed up by enthusiastic minds; needless to say we want an audience here and may not be able to depend easily on ESMTP (though this seems unlikely). 8. This won't stop all spam. If a spammer sets up shop, we're all in for, especially since standard domain name checks by most modern MTas won't work neither. Still, tracing these virmin suddenly becomes a bit easier. Right, I think that's everything. Any questions? What do you reckon? Cheers, Sabahattin -- Thought for the day: Bagpipes (n): an octopus wearing a kilt. Latest PGP Public key blocks? Send any mail to: [EMAIL PROTECTED] Sabahattin Gucukoglu Phone: +44 (0)20 7,502-1615 Mobile: +44 (0)7986 053399 http://www.sabahattin-gucukoglu.com/ Email/MSN: [EMAIL PROTECTED]
ESMTP Services Advertisement Requirements? RFC 821 Esoteric Commands Exclusion Permitted?
Hi people, For STD 10, RFC 1869, SMTP Service Extensions, it is not made clear, except possibly in a pair of examples provided by that memo, exactly whether or not the commands defined as optional and not required for a minimum implementation of SMTP (RFC 821), should or should not be advertised as described by the Service Extensions listings maintained by IANA in the manner described by RFC 1869. In fact, no mandates are set upon the specific advertisement of any service, be it supported or not, of RFC 821 origin or otherwise. Specifically, since the standard implementation of SMTP in RFC 821 makes no requirement for advertising optional commands that may be implemented (HELP, EXPN, SAML, SOML, etc), is it a violation of RFC 1869 that the server, despite supporting those features of RFC 821, does not advertise any or some of those supported commands in the ESMTP ehlo response, even if they are available for service in normal use of SMTP? Since they were defined as extensions only when the extensions framework was built, it seems unreasonable to expect implementations which may support the ESMTP framework to necessarily advertise those commands, rather than the few new ESMTP extensions such as Auth and StartTLS that the framework support was probably designed to cater for and for which developers have incorporated support into their mail transports. Not advertising features of SMTP will slightly decrease the transaction overhead without impact, in all probability, since the assumption can safely be made that those esoteric features of SMTP that are of any use to a specific client are called usually with prior knowledge of the features provided by the server, as in the use of turn or help in normal RFC 821 usage. Finally, many SMTP services out there exhibit this exact behaviour, not advertising supported features of SMTP in their ESMTP synopsis, so it is of interest to me to know whether, as part of the configurability of a mail transport, the option to advertise any, all, or all except RFC821 specific optional commands should be made available, or even whether or not the advertising of any service, of whatever origin, is required at all in any case. The help verb may then list all verbs which are supported, inclusive of those defined by RFC 821 or otherwise excluded for administrative reasons. What are your thoughts? Cheers, Sabahattin -- Thought for the day: A penny saved is ridiculous. Latest PGP Public key blocks? Send any mail to: [EMAIL PROTECTED] Sabahattin Gucukoglu Phone: +44 (0)20 7,502-1615 Mobile: +44 (0)7986 053399 http://www.sabahattin-gucukoglu.com/ Email/MSN: [EMAIL PROTECTED]
SMTP Minimum Retry Period - Proposal To Modify Mx
if we can bend the DNS without anyone noticing. Which, chances are, they will. RFC 2821 which replaced RFC 974 before it on this matter makes no reference to the exact way in which MX records should be parsed, so that it could be chancy. Still, what do you all think? Cheers, Sabahattin - -- Thought for the day: The only thing that hurts more than paying income tax is not having to pay income tax. Latest PGP Public key blocks? Send any mail to: [EMAIL PROTECTED] Sabahattin Gucukoglu Phone: +44 (0)20 7,502-1615 Mobile: +44 (0)7986 053399 http://www.sabahattin-gucukoglu.com/ Email/MSN: [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: PGP 8.0 -- QDPGP 2.70 Comment: Previous key for [EMAIL PROTECTED] revoked due to invalidated primary address. iQA/AwUBP/7X0CNEOmEWtR2TEQLbSQCfdgl36Ng3pnane8nV3Jbd+OMxuV4AoJC7 e7RPQCrDZHvLgNwqRC++nncs =ed5n -END PGP SIGNATURE-
SMTP Minimum Retry Period - Proposal To Modify Mx
if we can bend the DNS without anyone noticing. Which, chances are, they will. RFC 2821 which replaced RFC 974 before it on this matter makes no reference to the exact way in which MX records should be parsed, so that it could be chancy. Still, what do you all think? Cheers, Sabahattin - -- Thought for the day: Bagpipes (n): an octopus wearing a kilt. Latest PGP Public key blocks? Send any mail to: [EMAIL PROTECTED] Sabahattin Gucukoglu Phone: +44 (0)20 7,502-1615 Mobile: +44 (0)7986 053399 http://www.sabahattin-gucukoglu.com/ Email/MSN: [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: PGP 8.0 -- QDPGP 2.70 Comment: Previous key for [EMAIL PROTECTED] revoked due to invalidated primary address. iQA/AwUBP/7WniNEOmEWtR2TEQInAACgqw1sV1eESQ1bGri/5vRYH1oGaVsAoMpI eBN1NlE0QJBAhldfPkQpDnFW =VytL -END PGP SIGNATURE-
SMTP Minimum Retry Period - Proposal To Modify Mx
if we can bend the DNS without anyone noticing. Which, chances are, they will. RFC 2821 which replaced RFC 974 before it on this matter makes no reference to the exact way in which MX records should be parsed, so that it could be chancy. Still, what do you all think? Cheers, Sabahattin - -- Thought for the day: Book (n): a utensil used to pass time while waiting for the TV repairman. Latest PGP Public key blocks? Send any mail to: [EMAIL PROTECTED] Sabahattin Gucukoglu Phone: +44 (0)20 7,502-1615 Mobile: +44 (0)7986 053399 http://www.sabahattin-gucukoglu.com/ Email/MSN: [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: PGP 8.0 -- QDPGP 2.70 Comment: Previous key for [EMAIL PROTECTED] revoked due to invalidated primary address. iQA/AwUBP/7bXCNEOmEWtR2TEQJyuwCeIbafW2tUrQFEXF9UfJcU2yXmo8YAnj1G Ym/1XpLknxQbZeEclG8gzoiR =VDSt -END PGP SIGNATURE- -END PGP SIGNATURE-
Re: SMTP Minimum Retry Period - Proposal To Modify Mx
On 9 Jan 2004 at 9:18, Harald Tveit Alvestrand [EMAIL PROTECTED] spoke, thus: Why doesn't your friend use ETRN to trigger delivery of his queued mail from his mate whenever he gets online? He doesn't want his mate getting his mail while he's not available if he will be available shortly after. The idea is to restrain clients from passing onto the next MX, and thereby let his mail fall into his own responsibility when the unavailability of his host is either known to be temporary or is simply not long enough to justify any resulting policy differences between hosts. His mate could, if this were a dynamic DNS provider, be half-way across the world when the client only needed to wait a few minutes before it could deliver to the final destination. This is just an example. Also, etrn/similar don't solve the RBL problem. That way, the 4-hour delay is avoided without requiring global changes to the Internet infrastructure The unilateral thought of all of us, no doubt. :-) It is quite outrageous as far as requirements go for such a simple feature, but I honestly can't see a simple way otherwise that doesn't involve inter-host communication which, obviously, can't happen if the backed-up host is out, or other scheduled checking. If his mate could somehow know that he (my friend) were down, his mate could serve him, and when he returned his mate could, upon instruction by him, give an appropriate number and message to the effect that the primary was up, go and deliver to him, when all clients tried sending to my friend through his mate. Would implementation of such a system be worthwhile, even if it meant periodic checks by his mate that my friend was down? The MX concept is very good, but very heavy-handed and served a time long ago when it really was necessary. Also, the demand on the speed of mail delivery has gone up with the number of email users on the net and their expectations of it. In terms of saved bandwidth, there's a slight argument for the cost of a DNS query. I would be willing to implement it either way, though preferably the least destructive one. Cheers, Sabahattin -- Thought for the day: Dictatorship (n): a form of government under which everything which is not prohibited is compulsory. Latest PGP Public key blocks? Send any mail to: [EMAIL PROTECTED] Sabahattin Gucukoglu Phone: +44 (0)20 7,502-1615 Mobile: +44 (0)7986 053399 http://www.sabahattin-gucukoglu.com/ Email/MSN: [EMAIL PROTECTED]
Trouble Interpreting RFC 2142
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, I'm sure this has been raised before, and have done my fair share of searching - I think - on the matter. Trouble is, I can't seem to interpret RFC 2142 properly and reach a firm conclusion. I've seen variations on the interpretation of Suggestion Vs Compulsion for a while now, and no apparent clarification. Perhaps the author's view would be particularly helpful. The availability of the Abuse mailbox is the subject of exceptional debate. Part of the abstract runs thus: Additional mailbox names and aliases are not prohibited, but organizations which support email exchanges with the Internet are encouraged to support AT LEAST each mailbox name for which the associated function exists within the organization. Great. So, while I'm not prevented from inventing fab new mailboxes for the same or even more services, business roles, etc., I'm at least tentatively asked to support the listed mailboxes for services I run, with the implicitly understood exception that all services for which mailboxes are mandated in their respective standards must be available regardless. Right? Then, part of the Rationale says: However, if a given service is offerred, then the associated mailbox name(es) must be supported, resulting in delivery to a recipient appropriate for the referenced service or role. Okay, I'm confused at this point. I must support at least the addresses for services running at my domain, in contradiction to the mere encouragement we were getting earlier. This statement alone is not a suggestion, as seems to be commonly believed (see policy at http://www.rfc- ignorant.org/ 's Abuse list, for instance), and while no mention is made of a definition for Must or any further RFC in which the definition may be sought (and for which probable reason the word is therefore not in capital letters in the text of the RFC, as is often found in RFCs making such references), there seems to be a strong assumption that this resembles, quite understandably, a compulsion to support the minimal set of mailboxes, regardless (again, understood implicitly) of the definition of the protocol by its respective standard. So, please, can someone help me figure this out? To me, this is very, very shaky, and I wouldn't be willing to take sides without a better grasp on the situation and knowledge of the author's intentions in both pieces of the text. Perhaps an updating RFC might help the situation, especially in light of today's mail usage and needs (for example, heavily of the aforementioned Abuse mailbox)? Is some of my own understanding incorrect with regards to RFC precedence? Cheers, Sabahattin - -- Thought for the day: Communist (n): one who has given up all hope of becoming a Capitalist. Latest PGP Public key? Click: mailto:[EMAIL PROTECTED] and send that message as is. Sabahattin Gucukoglu Phone: +44 (0)20 7,502-1615 Mobile: +44 (0)7986 053399 http://www.sabahattin-gucukoglu.com/ E-mail or MSN Messenger: [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: PGP 8.0 -- QDPGP 2.70 Comment: Previous key for [EMAIL PROTECTED] revoked due to invalidated primary address. iQA/AwUBP3t6hiNEOmEWtR2TEQJOmwCePqmbCCbPm14c2sqcwg4JgcWJBqkAoLAP O+/Xc/L1otFdCpUjEdM4KVqj =rwyS -END PGP SIGNATURE-
