Per RFC 2606, the tld (top level domain) ".invalid" is reserved for "munging" and will never be part of a valid address. When someone attempts to send mail to an address that ends in the tld ".invalid", Mozilla should at the least, warn about this, and at best refuse to send the mail as long as any of the addresses end in that tld.

Why should Mozilla have special-case knowledge about this? Under what circumstances would an ordinary user encounter an address in .invalid? Why mailnews and not the rest of the browser?

marking unconfirmed bug WONTFIX since jgmyers seems to disagree with this and the reporter hasn't further justified the request after two months. Feel free to reopen this if you have more to add.

Sorry, I seem to have missed jgmyers comments. The tld ".invalid" is being used in news to indicate that the From address has been "munged" -- so if someone has an address of user@isp.com, they might normally munge that as user@spam.com, which is wrong for a couple of reasons (1) it may belong to someone else, (2) it creates unnecessary and unwanted network traffic, and finally (3) people that go to send them email have to guess whether or not the address is valid or not. If they ALSO append the tld ".invalid" then all of these things instantly go away -- ".invalid" doesn't belong to anyone, the mail/newsreader (in this case Mozilla) can tell the user that it is undeliverable without any network traffic at all, and because ".invalid" is guaranteed to not be deliverable, there doesn't need to be any doubt as to whether it is or not. As for why only mailnews -- why would someone give a URL that doesn't work? And even if for some weird reason they did, the browser can tell them that the domain can't be reached when it odes the dns lookup.

Closing an old bug. Mark it verified.

For what reason is this being changed to "WONTFIX"? It certainly hasn't gotten a lot of attention, but the problem still remains -- Mozilla will attempt to send mail to an address which it knows (or should know) doesn't exist. The use of ".invalid" to indicate an undeliverable address is both covered by the official standards (i.e. there's a RFC for it) and is fairly common practice among users (probably because it doesn't violate the Acceptable Use Policy of their ISP, unlike other forms of munging).

reopen. etiquette issue

sorry, dupe *** This bug has been marked as a duplicate of 3744 ***

What? No, this is not a dup. <me@whatever.invalid> is syntactically (per RFC822, IIRC) valid. It will not work, though, because .invalid won't be delegated. REOPEN. Different issues.

rubber-stamp confirming John Moreno's bug.

Thanks. Now that I'm commenting, I'd also like to say that this is *not* an etiquette issue -- it's a matter of verifying the input and not wasting the users time attempting to do something that can't succeed. You should no more attempt to send email to a mail address ending in ".invalid" than you should try to do so when there is no address -- because that is in fact the case: "name@isp.invalid" should be considered equivalent to "".

We ought to enable users to specify two email addresses for a news account: a real one for mail replies, and a munged or spam-container address for news posting. Then it would select the right address for the kind of reply being sent. (Simply stripping the .invalid when sending mail wouldn't do it justice, since people are likely to do more than just add .invalid if they really want to keep the spammers out.)