> > I agree. For me personally, this was not hypothetical. The
> > Pine mail user agent that I use began to intermittently fail
> > to connect to the IMAP server even when there was no evidence
> > of problems with network connectivity. The problem turned
> > out to be DNS fraud.
> >
> > I use ssh to connect over DSL service from Earthlink, and
> > port forwarding to get to the IMAP server. That means Pine
> > needs to connect to 127.0.0.1 on the forwarded port number.
> > I don't know why, but Pine does a DNS lookup on 127.0.0.1.
>
> Stop right there. You have a buggy application. You loose. Tough.
>
> If you have buggy applications you should fix them. You should not raise the
> buggy behavior at the IETF, ICANN or inter-ISP level as an urgent problem.
>
> There is limited bandwidth and much better things for all these bodies to be
> doing with their time.
>
> We have a real problem with Internet Crime that is causing rather more proble
> ms than your buggy mailer.
Actually if you had read the followup this was not a
application error but a operator error. Operator errors
are exactly what this misbehaviour depends on. This a
perfectly good example of unexpected consequences.
Note this also breaks the expectations of RFC 1123
If a dotted-decimal number can be entered without such
identifying delimiters, then a full syntactic check must be
made, because a segment of a host domain name is now allowed
to begin with a digit and could legally be entirely numeric
(see Section 6.1.2.4). However, a valid host name can never
have the dotted-decimal form #.#.#.#, since at least the
highest-level component label will be alphabetic.
This implies that entering a address query for #.#.#.# will
NOT return a RRset.
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@xxxxxxx
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf