29497 - Should refuse to send mail when address ends in tld ".invalid"

Status: NEW

(MailNews Core :: Networking, enhancement, P3)

Description

[John Moreno]

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.

Comment 1

[John G. Myers]

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?

Comment 2

[Dawn Endico]

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.

Comment 3

[John Moreno]

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 [e-mail], 
they might normally munge that as [e-mail], 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.

Comment 4

[fenella]

Closing an old bug. Mark it verified.

Comment 5

[John Moreno]

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).

Comment 6

[Daniel Wang]

reopen. etiquette issue

Comment 7

[Daniel Wang]

sorry, dupe

*** This bug has been marked as a duplicate of 3744 ***

Comment 8

[Ben Bucksch (:BenB)]

What? No, this is not a dup. <[e-mail]> is syntactically (per RFC822,
IIRC) valid. It will not work, though, because .invalid won't be delegated.

REOPEN. Different issues.

Comment 9

[Ben Bucksch (:BenB)]

rubber-stamp confirming John Moreno's bug.

Comment 10

[John Moreno]

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: "[e-mail]" should be considered equivalent to "".

Comment 11

[Stewart Gordon]

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.)