Closed
Bug 525643
Opened 15 years ago
Closed 13 years ago
[autoconfig] Invalid EHLO command in SMTP dialog
Categories
(Thunderbird :: Account Manager, defect)
Tracking
(Not tracked)
RESOLVED
DUPLICATE
of bug 549040
People
(Reporter: webmaster, Unassigned)
References
(Blocks 1 open bug)
Details
Attachments
(1 file)
(deleted),
image/png
|
Details |
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.1.4) Gecko/20091016 Firefox/3.5.4 (.NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.1.4pre) Gecko/20090915 Thunderbird/3.0b4
I tried to setup a mail account using the new account manager in Thunderbird 3. The account manager detects that it can use IMAP with SSL on my server, but it fails to detect that it can use SMTP with STARTTLS.
Using Wireshark I saw that Thunderbird 3 does not use a hostname for the EHLO command as described in RFC 2821 (http://tools.ietf.org/html/rfc2821#section-4.1.1.1). See log under "Additional Information".
Reproducible: Always
Steps to Reproduce:
1. Setup a new account
2. Enter name, email address, passwort and continue
3.
Actual Results:
Thunderbird uses the EHLO command without a hostname, which Postfix answers with a 501 Syntax error.
Expected Results:
Thunderbird should use the EHLO command with a hostname as described in RFC 2821.
220 mail.example.com ESMTP
EHLO
QUIT
501 Syntax: EHLO hostname
221 2.0.0 Bye
Reporter | ||
Comment 1•15 years ago
|
||
Reporter | ||
Updated•15 years ago
|
Severity: normal → major
OS: Windows XP → All
Priority: -- → P3
Hardware: x86 → All
Version: unspecified → 3.0
Reporter | ||
Comment 2•15 years ago
|
||
Problem persists with 3.0 Final.
Comment 3•15 years ago
|
||
Resetting platform to Windows, as I see no confirmation of this on a non-windows platform (although I expect it is multi-platform).
OS: All → Windows XP
Priority: P3 → --
Hardware: All → x86
Reporter | ||
Comment 4•15 years ago
|
||
I originally tested it on Windows XP (32 Bit) with the Beta 3, but I can confirm it with the 3.0 Release on Windows 7 (32 Bit).
If I don't forget, I will check a 64-Bit Windows as well... however, I also expect this to be al multi-platform bug. Maybe a look at the source code would help...
Reporter | ||
Comment 5•15 years ago
|
||
I checked the Thunderbird Source-Code and found the commands written down in this file:
http://hg.mozilla.org/comm-central/file/393f7f54019e/mailnews/base/util/autoconfigUtils.jsm
Line 57 ff. says:
const IMAP4_CMDS = ["1 CAPABILITY\r\n", "2 LOGOUT\r\n"];
const POP3_CMDS = ["CAPA\r\n", "QUIT\r\n"];
const SMTP_CMDS = ["EHLO\r\n", "QUIT\r\n"];
I think this states clearly that the EHLO command is hardcoded, followed by the QUIT command. You can see that the EHLO command doesn't have a hostname argument as described as required in RFC 2821.
Referring to the source code, I reset this bug to concern all platforms.
OS: Windows XP → All
Hardware: x86 → All
Reporter | ||
Comment 6•15 years ago
|
||
Using Wireshark, I saw that Thunderbird uses EHLO 192.168.0.10 (my local IP) when sending emails via SMTP. That means Thunderbird fullfills the RFC when sending mails, but uses an ip address that doesn't tell anything out there in the real world.
Keeping that in mind I suggest to use EHLO localhost or EHLO 127.0.0.1 in the Account Manager. That would be fine according to the RFC, it is easy to implement and would not be worse than what Thunderbird uses when actually sending mails.
So
const SMTP_CMDS = ["EHLO\r\n", "QUIT\r\n"];
besomes
const SMTP_CMDS = ["EHLO 127.0.0.1\r\n", "QUIT\r\n"];
Comment 7•15 years ago
|
||
I can confirm that this also happens with the client running on Linux.
I'll advise against using 127.0.0.1 as the domain address, because some mail servers might wrongly assume this is a spamming attempt. Getting the real IP (if feasible) might be preferable (or making up a name that can't be confused with an IP: EHLO thunderbird-account-wizard.mozilla.org should work)
Confirming based on code review and several reports. This may still be merged with bug 538809 though if it's easier to do in a single patch.
Regarding comment #7, spam filters should only be an issue if a message was actually sent (which is not the case for the probing), but as you can see from the bug referenced above, the probing process indeed mimics the behavior of a spamming client and may be detected/rejected as such.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Reporter | ||
Comment 9•13 years ago
|
||
Any news on this one?
Comment 10•13 years ago
|
||
Ben, is this still applicable after the bug 549045 redesign?
Comment 11•13 years ago
|
||
I fixed this in bug 549040:
<http://hg.mozilla.org/comm-central/annotate/9f2029d7b5ff/mailnews/base/prefs/content/accountcreation/guessConfig.js#l761>
<http://hg.mozilla.org/comm-central/rev/34bf573fdf62>
Dennis, thanks for the report.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•