Closed Bug 858540 Opened 13 years ago Closed 5 years ago

Syntactically invalid EHLO argument(s) when connecting via IPv6 interface

Categories

(MailNews Core :: Networking: SMTP, defect)

Product:
MailNews Core
Component:
Networking: SMTP
Platform:
x86_64
Windows 7
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(Not tracked)

Status:
RESOLVED INCOMPLETE

People

(Reporter: 3.14, Unassigned)

References

Details

(Keywords: regression, regressionwindow-wanted, Whiteboard: [workaround: comments #4, #15])

Attachments

(2 files)

SMTP log
683 bytes, text/plain
Details
SMTP log for 2.16.1
3.10 KB, text/plain
Details
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:20.0) Gecko/20100101 Firefox/20.0 SeaMonkey/2.17 After upgrading to 2.17 I am no longer able to send e-mail. I receive a windows saying: An error occurred sending mail: The server responded: Syntactically invalid EHLO argument(s) Contact your mail administrator for assistance. No other configuration changed. Total failure of function. pi
Component: MailNews: Backend → Networking: SMTP
Product: SeaMonkey → MailNews Core
Version: SeaMonkey 2.17 Branch → 20
Attached file SMTP log —
Attached file SMTP log for 2.16.1 —
After rolling back to Mozilla/5.0 (Windows NT 6.1; WOW64; rv:19.0) Gecko/20100101 Firefox/19.0 SeaMonkey/2.16.1 I can e-mail again. This proves that it was the upgrade which creates the error. Looking at the log the difference seems to be: EHLO [IPv6:::1] in 2.16 vs EHLO without any address in 2.17
Does toggling network.dns.disableIPv6 fix it?
Thanks, that helps. Yet still, there is a clear regression in 2.17. What caused it and why was it done that was?
Keywords: regression
Ok, so resolving IPv6 addresses fails for some reason. This sounds more like a Core issue than specific to MailNews. Do you see problems with other IPv6 connections, if any? (I'm not using it, IPv4 only, thus can't reproduce.)
Honestly, I would not know how to test it. I haven't seen any other problems by accident.
Looking around on bugzilla - yes, this affects other protocols as well: > Bug 653953 - https fails (blank page) when accessing IPv6 addressed servers > Bug 828873 - URL with https and IPv6 does not work Neil, is this somehow related to what you have fixed here for 21.0? > Bug 826455 - Want to be able to tell whether DNS returns an IPv4 mapped IPv6 address In this specific case, [IPv6:::1] is localhost, thus it will probably appear when IPv6 in general is enabled on a machine, thus not necessarily requiring actual IPv6 connections to be involved. You should only connect through the loopback though if the SMTP server is on your own machine, otherwise you'd see the interface address in the EHLO greeting (which, in turn, may be IPv6, thus triggering the issue).
One checkin matching the Gecko 20.0 time frame is bug 825492, fixing an issue on Windows where IPv6 addresses were not correctly resolved due to a buffer length issue. This didn't return an IPv6 address if both were available, thus the IPv4 address was used. With this fixed, the issue here might have been just exposed given that IPv6 addresses are now actually resolved (i.e., regression may have occurred earlier than the 20.0 cycle already).
(In reply to rsx11m from comment #8) > Neil, is this somehow related to what you have fixed here for 21.0? > > > Bug 826455 - Want to be able to tell whether DNS returns an IPv4 mapped IPv6 address I only created that so that the API would be usable from extensions and external components. Thunderbird was previously using the internal API for this purpose.
If you look in my bug 852301 report, when I downgrade to a working version of Thunderbird, a capture shows that the EHLO was going out with the IPv6 address (i.e. EHLO [IPv6:aaaa:bbbb:cccc:dddd:eeee:ffff:gggg:hhh]) not the IPv4 address, so it doesn't seem that it was failing back to IPv6 due to bug 825492.
I meant to say "it doesn't seem that it was failing back to *IPv4*"
Severity: blocker → major
Summary: Syntactically invalid EHLO argument(s) → Syntactically invalid EHLO argument(s) when connecting via IPv6 interface
Whiteboard: [workaround: comment #4]
You are correct, thus it's apparently a new problem now that using the IPv6 interface in general creates an issue at least with the EHLO greeting.
Keywords: regressionwindow-wanted
Another workaround (without disabling IPv6) is to set the mail.smtpserver.smtpX.hello_argument config setting to a non-null value (if the SMTP server is particularly picky, this might need to be the publicly-resolvable FQDN of the client).
Thanks. If the IPv6 address of the server still resolves fine that should be the preferable workaround, I agree.
Whiteboard: [workaround: comment #4] → [workaround: comments #4, #15]
[IPv6:::1] is no valid IPv6 address, correct would be [::1]. Why is there a leading IPv6: ?
It's correct. [IPv6:<address>] is the general form, ::1 the address part. http://tools.ietf.org/html/rfc5321#section-4.1.3
So it seems the function AppendHelloArgument at http://mxr.mozilla.org/comm-central/source/mailnews/compose/src/nsSmtpProtocol.cpp#324 should append the IP address string. It does not append anything if any of these fail: 1. nsISocketTransport::GetScriptableSelfAddr 2. nsINetAddr::GetAddress The failures are silently accepted and no ip is appended. As I do not have ipv6, can anybody debug it which of these fails?
Indeed my understanding is that the address is required in EHLO.
I wonder if AppendHelloArgument should not return an error if the IP getting functions fail so we avoid even contacting the server.
I think there are two different things to consider: One is the lookup of the remote IPv6 address (which is what comment #21 would address), the other the failed lookup of one's own interface's IPv6 address (here and bug 852301). In the latter case, it should never fail given that there should always be a valid address bound with the own interface, so that's the main issue. The other issue is comment #20. Thus, if the lookup fails, something else would have to fill in as the default (make it "undefined" or whatever string, it doesn't have to be a FQDN afaik) so that the receiving SMTP server doesn't get an invalid EHLO greeting.
I can confirm this same bug occurring in SeaMonkey 2.17 on Windows XP SP3 with IPv6 EHLO. A tcpdump capture shows that the client sends EHLO + space + CR + LF. The client is using stateless IPv6 autoconfiguration and an RFC 4941 privacy address so there is no reverse hostname. NXDOMAIN is returned by an authoritative name server for a reverse address lookup of the client address.
In my case, I received popup message with " Syntax: EHLO hostname". I also see 2.17 and 2.18 dropped IPv6-address-literal described in RFC5321 section4.1.3. In the Received: header, "IPv6:" is not appeared. This might be comply with the RFC. [IPv6:2001:200:16a:1010:9d48:8ad2:55d5:3b80] 2.17 and 2.18 simply put IPv6 address with "[" and "]", [2403:2000:1:3:1d6e:5210:74f1:9e35] -- my info Mozilla/5.0 (Windows NT 6.1; rv:21.0) Gecko/20100101 Firefox/21.0 SeaMonkey/2.18 Windows 7 Professional(32bit) with Service Pack1 IPv6 addresses are created by RA(windows specific autoconfigured one and temporary address, temporary address is used fast.)
Does this happen only on Windows?
What purpose does the IP address actually serve? Does the SMTP check it in any way? What if we just send [IPv6:::1] in case we couldn't determine the real one?
There are various degrees that SMTP servers can check. See for example this very interesting one, where Exchange did an extremely strict check on the IPv6 addresses enclosed in the literal. http://labs.apnic.net/blabs/?p=309 Postfix servers are often configured to reject unresolvable or even invalid HELO hostnames, but other than that blogposting above I haven't seen anyone doing that on MSA configurations. [IPv6:::1] would definitely be better than the broken string. At least our Exchange 2010 SP3 HBT seems to accept that.
(In reply to :aceman from comment #25) > Does this happen only on Windows? The IP address is indeed only used for the greeting on Windows platforms. Both Mac OSX and Linux use the local host name (as entered or resolved by DHCP) which isn't necessarily either a FQDN or an IP address. Special characters in those names (specifically on Mac OSX, in Linux to a lesser extent) have caused problems there. I don't know why which version to get the argument for the SMTP greeting was chosen for each platform, but it has been like that for quite a while.
In terms of using the loopback address or some other default, there are some gotchas as Bernhard points out in comment #27, but there are also potential issues with receiving SMTP servers that are following RFC recommendations for the sender policy framework (RFC 4408), which recommends checking that the submitted HELO/EHLO argument is allowed by the sender's domain's SPF record. In the ideal world, we would submit an FQDN which resolves to the IP address seen as the source of the SMTP connection by the SMTP server and corresponds to an allowed sender in the SPF record. But we can't accurately determine our "publicly visible" FQDN in many circumstances (and for IPv4, this is further complicated by NAT). Using the IPv6 literal is therefore a sensible compromise (the SPF record would need to have an ip6: entry). Situations where we get a genuine failure to obtain the interface address (as opposed to a failure to due a code issue as we seem to have here) and therefore need a fallback are probably extreme corner cases, in which case any choice of a fallback is going to be problematic in some situations if a particular receiving SMTP server is over-zealous in its implementation of anti-spamming/anti-spoofing (e.g. using the local hostname or the loopback address could fall foul of these checks fairly easily).
If I'm not mistaken, SPF records should be checked against the address/domain of the MSA rather than the MUA (i.e., the provider's server after accepting the message, not the user's location, assuming that the mail-submission server can accept connections from anywhere as long as the user is properly authenticated by the provider responsible for relaying that message). Thus, the IP address or domain name provided by the e-mail client in the EHLO greeting (and mostly unusable anyway if the client is within a local network, thus having obtained a private-network IP address, which in turn won't match the external provider's address as resolved by the receiving MSA) shouldn't be an issue as far as SPFs are concerned (but certainly may be used by spam-filtering software for other criteria).
(In reply to rsx11m from comment #30) > If I'm not mistaken, SPF records should be checked against the > address/domain of the MSA rather than the MUA (i.e., the provider's server > after accepting the message, not the user's location, assuming that the > mail-submission server can accept connections from anywhere as long as the > user is properly authenticated by the provider responsible for relaying that > message). That's correct of course, in most normal situations it will be irrelevant as far as SPF is concered. I had in my mind that it is conceivable within an enterprise environment that the SMTP server being used by the client could be the same server used for receiving inbound SMTP from the Internet and could be applying SPF checks to client connections. On reflection this is probably never going to be the case and anybody doing that would probably already have loads of problems, so I'll retract that part of my comment! As we don't seem to be getting far diagnosing the root cause of the problem as it seems a lot of guys don't have an IPv6 configuration to test with, I'll have a go at a build and see if I can at least point us in the direction of what is failing. It may take me a few days to get there as this will be a first build for me of a Mozilla application.
(In reply to Roberto Casula from comment #31) > As we don't seem to be getting far diagnosing the root cause of the problem > as it seems a lot of guys don't have an IPv6 configuration to test with, > I'll have a go at a build and see if I can at least point us in the > direction of what is failing. It may take me a few days to get there as this > will be a first build for me of a Mozilla application. As I can't create a Windows build myself (only linux), it would be great if you could instrument the code mentioned in comment 19 and find out which function is failing there and what is the rv value returned.
Hmmm. I don't get a failure from either of those functions and I have now built the current daily from comm-central and tested Thunderbird (now at v23.0) and the issue does not exist (it sends the expected EHLO argument with the IP6: literal just as it did in versions of Thunderbird prior to 21.0). So either something was changed between version 21.0 and 23.0 or something is different in my build process compared with the public build (I haven't done anything special, other than manually add the MAPI headers as I have platform SDK 8.0 which does not ship with the MAPI headers). How does one determine what version of nsSmtpProtocol.cpp was used in the public build of 21.0 so we can compare the code?

Version 91 has all new smtp backend code. If you can still reproduce this issue, please file a new bug report https://bugzilla.mozilla.org/enter_bug.cgi?product=MailNews%20Core&component=Networking%3A%20SMTP

Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: