Closed Bug 3744 Opened 22 years ago Closed 12 years ago

Must require email address to be syntactically valid

Categories

(MailNews Core :: Backend, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 422814

People

(Reporter: phil, Unassigned)

References

(Depends on 1 open bug, Blocks 1 open bug, )

Details

This is one of the "failing" items in the Good Netkeeping Seal of Approval (see
URL above). The user is allowed to enter a From address which is not
syntactically correct. We could fix this in preferences by preflighting the
email address the user typed. Or we could fix it at send-time in the "sanity
check" process for outgoing messages.
Assignee: ducarroz → alecf
Target Milestone: M6
I think this is best done as a prefs-validation thing, and since alecf has the
identity prefs for 5.0, reassigning to him for M6.
Status: NEW → ASSIGNED
Target Milestone: M6 → M8
minor, pushing to m8
Priority: P3 → P2
going on vacation, mass-moving these M8 bugs to M9
OS: Windows NT → All
Hardware: PC → All
correcting platform to All since this appears to be cross platform.
moving low priority, high risk, and time-intensive bugs to M10
Target Milestone: M10 → M12
This is a nice to have, but I don't think it needs to be fixed by PR1
*** Bug 12443 has been marked as a duplicate of this bug. ***
Blocks: gnksa
Target Milestone: M12 → M14
Component: Composition → Account Manager
Adding nbaca to Cc: list.
ok, I've fixed this in the wizard. I need to fix this in the account manager now
Build 2000010515M13: Linux/Redhat 6.0
I noticed that just entering "@" as the email address allowed me to progress.
Should the validation procedure be more rigorous?
ugh, yes, good catch :)
don't reopen this though, I'm checking in a fix right now.
oops, it's not marked fixed anyway
anyway, I fixed it so that you MUST have characters before and after the @.
There are still other non-rfc822 compliant e-mail addresses that can go here,b
ut this is good enough.
moving beacuse this isn't a beta blocker
Target Milestone: M14 → M15
QA Contact: lchiang → nbaca
another case found in the comments in bug 
http://bugzilla.mozilla.org/show_bug.cgi?id=29270.
The right way to fix this is propably to create a nsIURI with it and prepended
"mailto:". See bug 32442 for that.
Target Milestone: M15 → M17
Minor UI fixups to M18.  If this is incorrect, please adjust.
Target Milestone: M17 → M18
Adding dependency to bug 32442 "More checks for mailto URLs". Note, that
"syntactically correct" is a high bar (i.e. will take some time to implement
correctly). RFC822 knows *several* escape mechanisms.
Depends on: 32442
I recommend that we crawl, walk, run here. I definitely do not want to see us
put in something complicated which ends up having false hits (flagging addresses
as incorrect which are in fact correct). How about (strlen(address) > 2 &&
strchr('@',address) != nsnull).

If we decide to do something compicated, we'd better have some pretty good
tests, as we used to in addr.c/addrutil.cpp (I assume that still exists in
mozilla somewhere)
Phil, while I'd like to see a correct parser in Mozilla, I see, that there are

more important things to work on. As for the proposed algorithm, IIRC, the state

of bug 32442 is already better.



I suggest to fix this bug that way I suggested above (asking Necko via nsIURI,

which will take advantage for any code for 32442. The latter would block 12669 then.

Sorry, I should avoid suggesting specific algorithms. My real point is let's not
be overly aggressive and risk false hits. We did exactly that when we started
validating newsgroup names, and found that many people use newsgroup names which
are not strictly legal, so our well-intended code ended up breaking things which
used to work.
I like the idea of using necko for this though. Thanks for referencing that bug,
I didn't even realize there was mailto: validation going on.
This is a GNKSA MUST, adjusting SUMMARY.
Summary: Should validate user email address → Must validate user email address
Alec, do we need to fix more of this for this release, or do we have enough to 
be sufficient for our RTM?
I think it's sufficient for RTM... 
move to future milestone then.
Target Milestone: M18 → Future
*** Bug 57036 has been marked as a duplicate of this bug. ***
massive reassign of account manager bugs -> sspitzer
please feel free to put me back on the CC if you have any questions/comments
Assignee: alecf → sspitzer
Status: ASSIGNED → NEW
mass re-assign of account manager bugs to racham.
Assignee: sspitzer → racham
I was just wondering about "local" users' e-mail addresses - can't they be
specified without an "@" symbol?

So you want an e-mail address format to be:

Pre-@ RFC 822 allowable chars (minimum of 1)

or

Pre-@ RFC 822 allowable chars followed by an @ followed by Post-@ RFC 822
allowed chars (i.e. allowable chars for a domain name)
The From address must be fully qualified, since it most likely will get sent
outside the local network. Dunno, if any spec requires this, but using "From:
ben" doesn't make much sense to me.

But this is actually a good point wrt the dependance of bug 12699, since "ben"
is a completely legal email address. So we'd probably need to do additional
checks here (or have modes (for local addressed allowed or not) in the generic
code). Although strictly not being sufficient, as a first implementation,
checking for validity (see bug 12699) *and* existance of "@" should be enough.
Ok, please remove that validation on the prefs menu. It is annoying.
Sorry, I meant on add account.
BTW: I believe some pop servers don't require an @ in the address. (Don't quote 
me on this).
Removing address validation from our prefs (i.e. which would be used in the
From: header of an outgoing message) would be a mistake. This bug is for how
much, if at all, we improve on what's already there.
Agree with Phil. It is also a GNKSA requirement.

POP servers are irrelevant - they never see the address (apart from msg
contents, of course). It is only for From in outgoing msgs.

Why is it annoying?
Just when I feel like using MailNews the first time and don't feel like 
entering in an account.
I want to type in fdfjdklafjdsafl for everything.
It should be possible to use mozilla mail/news without creating a valid account.
Dunno if that's possible now, but if it's not, it's a separate bug. It should
not be possible to create a mail account, or send a message, without having a
valid email address, including the '@' sign.
Blocks: 76449
Summary: Must validate user email address → Must require email address to be syntactically valid
For contrast, see bug 88298, News requires a valid e-mail address.
I'm sorry, but this bug is the most ridiculous bug I've ever seen. The user
should be given the option to use whatever e-mail address he wants. Enforcing
valid e-mail addresses is up to the server handling the messages and any attempt
to control this in a browser will just make people switch to other mail/news
clients without these limitations. It is especially important that the
newsreader does not behave in this way (bug 29270). MailNews will never be able
to stop spammers from entering fake e-mail addresses - it just forces them to
format them properly.
> The user should be given the option to use whatever e-mail address he wants.

He has the option. He just has to enter an *email address*. ;-P

Other comments in bug 29270.
It should be possible to make a news account without an @ symbol for the email
address since the messages are posted to the news server regardless of emails.
It should also be possible to make an email account without the @ symbol if
there are any ways that people could send an email in an intranet, etc, without
a valid email address. I don't think that Mozilla should be a police force. One
simple warning with a little "Click here if you want to see this again" should
be sufficient.
The relevant internet standards (RFC 1036) require a From header with 
the contents of "the electronic mailing address of the person who sent the 
message, in the Internet syntax".  Which means that it needs a fully 
qualified domain name.

In this instance the GNKSA is simply checking/enforcing RFC compliance.
No longer blocks: gnksa
*** Bug 29497 has been marked as a duplicate of this bug. ***
mass re-assign.
Assignee: racham → sspitzer
If MailNews uses MAPI, sendmail, or equivalent, let them deal with validation. 
They know best, after all, since they are the core mail facilities. A "From:" 
of +17035551212 would be perfectly legal if the "To:" was +44567234523 and 
some provider for international faxing was installed. Actually, a 
syntactically valid RFC2822 address would be illegal in that case.

If MailNews does not use MAPI, then it should offer full RFC2822 support, 
including in-address comments not SMTP'd, and *optionally* require 
verification in the sanity check. Some option buried deep in preferences, 
mangled so that John Q. Spammer can't automagically turn it on, and must do so 
by hand, to say, "Yes I know my address isn't valid but let me send e-mail 
anyway" would be the ticket. But it still should be "crawl walk run" if it 
isn't in there yet.

And I would not recommend enforcing validation at first-run, as netdragon 
seems to have issues with, but at send time, as part of the sanity check, as 
PPeterson proposed.
Product: Browser → Seamonkey
Assignee: sspitzer → mail
Priority: P2 → --
QA Contact: nbaca
Target Milestone: Future → ---
Assignee: mail → nobody
Component: MailNews: Account Configuration → Backend
Product: SeaMonkey → MailNews Core
QA Contact: backend
<+44567234523@fax.example.com> or similar is legal and used by most services.

---

We're fixing this to some degree in the new account wizard, see bug 422814 comment 110.
Depends on: autoconfig
No longer blocks: 76449
The main avenue to create accounts has been fixed by bug 422814. The new mail account wizard requires syntactically valid email addresses as your own address.

There are still other ways to configure your email address, e.g. the Account Settings and Identity edit dialog, as well as the old account wizard which is used for Movemail accounts. But I think we can consider this FIXED.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: autoconfig
No longer depends on: autoconfig
Blocks: 76449
You need to log in before you can comment on or make changes to this bug.