795113 - ipv6 not working for mailserver address

Status: RESOLVED DUPLICATE of bug 551675

(MailNews Core :: Networking: SMTP, defect)

Description

[johann]

Attachment: Troubleshooting Information.xht

User Agent: Mozilla/5.0 (Windows NT 6.0; rv:15.0) Gecko/20120909 Firefox/15.0.1 SeaMonkey/2.12.1
Build ID: 20120909051100

Steps to reproduce:

added IPv6 addresses for MX in various domain zone files.



Actual results:

the server address that was working (host.domain.tld) for the IPv4 addresses stopped working.

somewhere a time back, i read that mozilla would prefer IPv6 over IPv4 if IPv6 was enabled. i do not understand the logic, but this seems to be the case.

to verify this, i entered an IPv4 address to circumvent the DNS for the mailserver and connections were made. i did the same with an IPv6 address and nothing worked.

i verified that the IPv6 was operating by using telnet to ports 25/465 (postfix) and 993 (dovecot) and everything was as it should be.



Expected results:

SM should have connected to the IPv6's for ports 465/993 as appropriate.

Comment 1

[Philip Chee]

There are two issues in this bug.

> the server address that was working (host.domain.tld) for the IPv4 addresses stopped
> working.

This is possibly Bug 551675 - No fallback from IPv6 to IPv4 for dual-homed SMTP servers.

> to verify this, i entered an IPv4 address to circumvent the DNS for the mailserver and
> connections were made. i did the same with an IPv6 address and nothing worked.

This is probably Bug 199391 - Add Account to ipv6 IMAP/POP/SMTP server fails IP address validation. See Bug 199391 Comment 16:

"IPv6 address input gets accepted, but Thunderbird mangles it so it doesn't work."

Since this is shared code with Thunderbird, I'll move this bug to a more appropriate component.

Comment 2

[johann]

(In reply to Philip Chee from comment #1)

> Since this is shared code with Thunderbird, I'll move this bug to a more appropriate component.

i have posted info on the referenced bugs and requested that they be consolidated here in the hopes that something can be done to resolve all the issues some time before the close of this decade (SEE: Bug 199391 and Bug 402594 for a little history lesson and reality-check on 'hopes').

frankly, i do not understand how mozilla can fall down on things like IPv6 and IMAP and still expect their commercial aspirations (vis-a-vis 'mozilla messenger' et cetera) to come to fruition.

thank you

Comment 3

[Jim Porter (:squib)]

This isn't a blocker. "Blocker" is only used for things which make it impossible to do development or testing.

Comment 4

[johann]

strange?! perhaps mr. porter does not know what is happening here.

i (together with most people) find something that does not work is "blocking". 

the subject bug is an IPv6 connectivity problem brought on by mozilla's option to prioritize v6 over v4 and this is well and good. however, mozilla's core (shared by both SM and TB) garbles v6 and cannot connect and this is plainly a failure. but there is more: mozilla does not fall-back to v4 when v6 fails.  yes, this is a two-fold problem. thus, one is *blocked* from using the standard industry practice of allowing DNS to be used to locate one's mailserver (if such is -- or will be -- offering IPv6 options). 

i am willing to bet that even some seasoned mailserver administrators are initially confused and then chagrined that SM/TB suddenly become broken when they move to bring their connectivity into the IPv6 world ... something that is happening thousands of times per month now. mozilla's intransigence in solving these problems is a guarantee that SM/TB are taking a short-cut to obsolescence.

i might point out that this "short-cut" will become instantaneous as soon as a major player such as gmail, hotmail, or yahoo add IPv6 to their zone files for IMAP/POP3. this will cause tens of thousands of individual user crashes and will severely tarnish mozilla's reputation when it becomes known that they knew about the problem and did nothing ... for years now. i have been a user since netscape/phoenix/mozilla-suite days and would hate for this to happen, but i am not a programmer and cannot directly rectify what is wrong here and in other IMAP problems equally ignored.

as to "development or testing", i eagerly await an explanation of how this is currently being done using a FQDN (offering IPv6) in the account field and, therefore, this bug is not a "blocker". i do agree that mozilla has been able to skate-by for some time now since most DNS for mailservers returned *only* IPv4, but this is not going to last much longer.

however, semantics and view-points aside, if mr. porter is going to fix these age-old problems he certainly may typify this bug in whatever manner he desires. otherwise, i do not understand why anyone would be actively taking exception to what is a reasonable person's assessment/expectations.

thank you

Comment 5

[Jim Porter (:squib)]

(In reply to johann from comment #4)
> however, semantics and view-points aside, if mr. porter is going to fix
> these age-old problems he certainly may typify this bug in whatever manner
> he desires. otherwise, i do not understand why anyone would be actively
> taking exception to what is a reasonable person's assessment/expectations.

"Blocking" bugs are flagged as such because they prevent other Thunderbird developers from doing any work on Thunderbird. An example would be if Thunderbird wasn't compiling properly on a platform. It's important to keep the list of blocking bugs accurate because it helps developers to know what bugs *must* be fixed immediately in order to allow other developers to continue working. This is not one of those bugs.

Comment 6

[Wayne Mery (:wsmwk)]

(we don't normally keep open multiple bugs describing the same issue)