Closed Bug 101027 Opened 23 years ago Closed 23 years ago

Prefs: improve ftp password when "advanced.mailftp"=false

Categories

(Core Graveyard :: Networking: FTP, defect)

x86
Windows 2000
defect
Not set
major

Tracking

(Not tracked)

VERIFIED FIXED
mozilla0.9.5

People

(Reporter: stummala, Assigned: bbaetz)

References

()

Details

(Keywords: testcase)

Attachments

(2 files)

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.2)
Gecko/20010726 Netscape6/6.1
BuildID:    2001-09-12-05

"mozilla@" is passed as passwd when visiting the site ftp://ftp.CPAN.org
username - anonymous 
passwd - mozilla@ //causing it to break 
an alert is shown saying "mozilla@ is not a valid passwd"
works fine in Linux.


Reproducible: Always

Actual Results:  alert pops up. 

Expected Results:  show the directory listing of CPAN ftp site
darin
Assignee: neeti → darin
-> ftp (bbaetz)
Assignee: darin → bbaetz
Component: Networking → Networking: FTP
Confirming with 0.9.4.

We should send mozilla@example.com as the default, I guess.

dougt?
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9.5
Set "Prefs |Advanced | "Send this email address as anonymous FTP password".
If that works, this is a dupe of bug 57763.
benc: no.

This worked on and off for both me and darin. The problem is that mozilla@ is
not a valid email address, and some ftp servers are picky.

The default should be changed
No.  We can not specify a dummy domain.  

Instead we should check against this server response and ask the user for a
username/password.

(note that other ftp clients have the same problem)
Why not? example.com is a domain which is guaranteed to never really exist.

We could do mozilla@{myHostName} though, but that would leak info if there was a
firewall in the middle.
my experience regarding these anonymous ftp servers is they just check for 
@ followed by some text and a dot in the email address. most of the ftp servers
will let you in even if the email address is wrongly formated, but suggest to
use something like "abc@domain.com" when visiting next time. CPAN was picky. 
is it possible to check for the sanity of email address before sending so that
this problem will not occur and if it is not in rite format just format it
bbaetz:

-re: "no"... Uh, my point is: the user can fix the problem themselves. The
summary didn't say "the default value fails w/ some servers."

-re example.com: I guess it wouldn't hurt. what do IE and Comm do? (Does anyone
have a URL that guarentees that "example.com" will never be used for perpetuity?

I was just reading RFC 1630, which says:

FTP

   The ftp: prefix indicates that the FTP protocol is used, as defined
   in STD 9, RFC 959 or any successor.  The port number, if present,
   gives the port of the FTP server if not the FTP default.

   User name and password

      The syntax allows for the inclusion of a user name and even a
      password for those systems which do not use the anonymous FTP
      convention. The default, however, if no user or password is
      supplied, will be to use that convention, viz. that the user name
      is "anonymous" and the password the user's Internet-style mail
      address.

      Where possible, this mail address should correspond to a usable
      mail address for the user, and preferably give a DNS host name
      which resolves to the IP address of the client.  Note that servers
      currently vary in their treatment of the anonymous password.

In this light, it seems to me that we might want to have a radio button w/ more
sophisticated password settings (our default string, some address in an email
account you have configed, some reverse-lookup based address, or your custom string.

This might be yet another RFE, which I will create if you want to talk about
just editing this pref.

meanwhile, I've corrected the summary.
BTW, this pref name was not a great choice, can't we move it to "network.ftp.*"
before it is too late?

Summary: email address as password not set properly → Prefs: improve ftp password when "advanced.mailftp"=false
benc: Lets not get complicated. If we're going to send a bogus value by default,
lets send a semanticly valid bogus one.
ben,
i understand what u r saying, but people may not set the default value, in that
case browser has to set some value something like "profilename@mozilla.org" or
something like that
I'm not getting complicated, I'm just getting some standards advocacy in sideways :)

I didn't pick "mozilla@"... Heck, I never even thought it would work for a lot
of servers, but nobody ever objected until now...

What are our friends "IE and Comm" using?

re: <PROFILENAME> you pick that and mitchell probably have to get involved.

the default should be mozilla@example.com unless someone has large objections.

benc: nn4.77 for unix sends "mozilla@"
no problem as long as it is a semanticaly valid email address :)
Actually picking a domain brainlessly can get you in a lot of trouble. Look at
http://www.localhost.com.

I checked, and "example.com" is not in DNS. I'd prefer to know it's reserved as
bogus, but you get to decide, all I'm here to do is verify :)
how about using some busted dot com's :)
example.com is reserved. http://www.rfc-editor.org/rfc/rfc2606.txt

We could use mozilla@mozilla.example but I prefer the first.
Attached patch patchSplinter Review
I don't like this solution as much as i like what other clients do.  Why don't
we just pop up an dialog asking for the user for another username/password pair?
I think that it would be confusing to pop up the dialog. It doesn't have a
problem with anonymous login, just the bogus email address. why not give it a
'real' one which is invalid?
Comment on attachment 51372 [details] [diff] [review]
patch

please add a comment above this line that mentions the RFC which provides that example.com is valid/legal.
Attachment #51372 - Flags: review+
Comment on attachment 51372 [details] [diff] [review]
patch

sr=darin
Attachment #51372 - Flags: superreview+
I checked this in last night, but forgot to mark it fixed. Oops.
...and now I jsut forgot to mark it fixed.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
verified. works for me on linux build 10-10-04
Status: RESOLVED → VERIFIED
I send you a patch to correct ftp anonymous passwd.

There are three problems with the current approach:
- Some stupid servers try to check that what goes after @ exists
  and delay the login and could deny login if the example.com
  name goes down.
- Sending anything that's not anonymous@ as password is not anonymous
  by definition
- Spyware is not a good idea, most users don't like it.

As more and more ftp clients are moving to this anonymous@ password
(for example the kde kio ftp, qt3, gnome-xml)
I recommend you to apply the patch.
No, we have to send a hostname - if we don't, then some sites won't let us in,
because its not a valid addess, which is why this bug was filed in teh first place.

>- Some stupid servers try to check that what goes after @ exists
>  and delay the login and could deny login if the example.com
>  name goes down.

example.com doesn't have a DNS entry, and never will, which is why its used. If
the root namesevers are timing out looking up that, the net is having much
greater problems.

Can you give an url for a server which denies access because example.com does
not exist?

>- Sending anything that's not anonymous@ as password is not anonymous
>  by definition

this is the 'password', not the username. The username is 'anonymous', which is
the custom for this sort of thing (its not technically in any standard, but
people use it)

>- Spyware is not a good idea, most users don't like it.

How is this spyware?? The most it does is let another site know that you may be
using a mozilla based product, which is less that the useragent string or
navigator.appName gives you. We only send your real email address if you check
the box in preferences to do so.
> No, we have to send a hostname - if we don't, then some sites won't let us in,
> because its not a valid addess, which is why this bug was filed in teh first
place.

Can you give an url for a server which denies access because you don't
send a hostname?

It can't be invalid because IE sends "IEUser@". If a server denies access
when there isn't a hostname, it's denying access to half the requests !!!

> >- Some stupid servers try to check that what goes after @ exists
> >  and delay the login and could deny login if the example.com
> >  name goes down.
>
> example.com doesn't have a DNS entry, and never will, which is why its used.
If
> the root namesevers are timing out looking up that, the net is having much
> greater problems.
>
> Can you give an url for a server which denies access because example.com does
> not exist?

I know servers that check the hostname against DNS and delay login by
that amount of time.

> >- Sending anything that's not anonymous@ as password is not anonymous
> >  by definition
> >- Spyware is not a good idea, most users don't like it.
>
> How is this spyware?? The most it does is let another site know that you may
be
> using a mozilla based product, which is less that the useragent string or
> navigator.appName gives you. We only send your real email address if you check
> the box in preferences to do so.

Why do you think sending the useragent string is a good idea ? It isn't.
Do you know sites that deny http requests if you are not using IE ?
Monopoly tried to do so in its portal.

If you send "mozilla@example.com" instead of "anonymous@"
apart from being a privacy leak you are helping sites to
discriminate based on user agent and no user wants that.

Would you at least consider using "anonymous@example.com" ?
(I prefer using "anonymous@" as it's used by some ftp clients like
kde kio ftp, qt3, gnome-xml, libnet-perl)
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
*** Bug 117794 has been marked as a duplicate of this bug. ***
cpan does - see comment 0. Only one or two servers did it, and the dns entry
round robin's on where you are in the world, so you may not be able to reproduce
it. I managed from Montreal, though.

mozilla@ has been used for ages, and itcan be changed by the user.

Remarking as FIXED
Status: REOPENED → RESOLVED
Closed: 23 years ago23 years ago
Resolution: --- → FIXED
VERIFIED:
this is in the functional test.
Status: RESOLVED → VERIFIED
Keywords: testcase
advanced.ftp does NOT work in conjunction with network.ftp.anonymous_password!

only
(advanced.mailftp, true) works!

you should change
http://www.mozilla.org/quality/networking/docs/netprefs.html
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: