If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

auto-config probing doesn't set smtp user name correctly

RESOLVED FIXED in Thunderbird 3.3a1

Status

Thunderbird
Account Manager
RESOLVED FIXED
7 years ago
7 years ago

People

(Reporter: Bienvenu, Assigned: Bienvenu)

Tracking

Trunk
Thunderbird 3.3a1
x86
Mac OS X

Firefox Tracking Flags

(blocking-thunderbird3.1 rc2+, thunderbird3.1 rc2-fixed)

Details

Attachments

(1 attachment, 1 obsolete attachment)

(Assignee)

Description

7 years ago
On my dreamhost account, autoconfig is figuring out the user name correctly as being my e-mail address, but leaves the smtp server user name as just my name, so sending e-mail doesn't work. I suspect this is a regression, and it will cause a fair amount of support headache, since the user has to go change their smtp user name, which is very challenging for a lot of users.
(Assignee)

Comment 1

7 years ago
Nominating, since it would be a shame to ship with this, and we know we're respinning for a few other bugs.
blocking-thunderbird3.1: --- → ?
Could this be a similar problem as seen in bug 568153?
Assignee: nobody → bienvenu
blocking-thunderbird3.1: ? → needed
Whiteboard: [needed RC2]
(Assignee)

Comment 3

7 years ago
well, I didn't do an explicit retest, and I didn't notice this went wrong until the next day, because I didn't try to send a message from that profile until I was at the airport...I'll check.
(Assignee)

Comment 4

7 years ago
Fixing the issue in bug 568153 doesn't seem to have any effect on this bug. And I don't see anything on the error console when I recreate this bug. I've completely forgotten how this code works, and it's probably been rewritten a couple times since I was involved, so it'll take me a little while to figure out what's going on here.
(Assignee)

Comment 5

7 years ago
I verified that this is a regression from 3.0.4, just for a sanity check.
(Assignee)

Comment 6

7 years ago
patch in bug 534604 regressed this, by ignoring the probed incoming user name when setting the outgoing server username.
(Assignee)

Updated

7 years ago
Depends on: 534604
(Assignee)

Comment 7

7 years ago
I suspect the way out is to distinguish between auto-probed usernames for incoming servers, and usernames determined by ispdata, and in the former case, make sure the newly created outgoing server uses the auto-probed username. I don't know how this information is propagated, however.
I don't think that information is propagated, but we could set a flag on the config indicating where it came from, if that made sense to you.

(And by "we", I mean "you".  ;)

Thanks,
Blake.
(Assignee)

Comment 9

7 years ago
Created attachment 449486 [details] [diff] [review]
proposed fix

This fixes the bug for me. It shouldn't regress the regressing bug, because we shouldn't have to probe for ispdata configs. My one concern might be the case where the user has an existing smtp server configured, and is trying to set up a new incoming server, without a new smtp server. I'm not sure if that will cause us to crunch the existing smtp server. I rather doubt it, but I'll try it out.
Attachment #449486 - Flags: review?(bwinton)

Comment 10

7 years ago
bienvenu wrote:
> I suspect the way out is to distinguish between auto-probed usernames for
> incoming servers, and usernames determined by ispdata, and in the former case,
bwinton wrote:
> I don't think that information is propagated,

It is propagated, as config.source == AccountConfig.kSourceGuess or kSourceXML, see accountConfig.js.

r=BenB, without the first hunk. The first hunk is bug 568153.
(Assignee)

Comment 11

7 years ago
Created attachment 449521 [details] [diff] [review]
patch w/o extra patch

ok, thx, Ben. I'll land this
Attachment #449486 - Attachment is obsolete: true
Attachment #449521 - Flags: review+
Attachment #449486 - Flags: review?(bwinton)
(Assignee)

Updated

7 years ago
Attachment #449521 - Flags: approval-thunderbird3.1?
(Assignee)

Comment 12

7 years ago
fixed on trunk - http://hg.mozilla.org/comm-central/pushloghtml?changeset=ddd853fb7773
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED
Attachment #449521 - Flags: approval-thunderbird3.1? → approval-thunderbird3.1+
(Assignee)

Comment 13

7 years ago
fixed for comm-central 1.9.2
(Assignee)

Comment 14

7 years ago
fix pushed for rc2
blocking-thunderbird3.1: needed → rc2+
status-thunderbird3.1: --- → rc2-fixed
Whiteboard: [needed RC2]
Target Milestone: --- → Thunderbird 3.2a1
You need to log in before you can comment on or make changes to this bug.