Closed Bug 29270 Opened 25 years ago Closed 23 years ago

Allow spambot-protected e-mail address in News

Categories

(SeaMonkey :: MailNews: Account Configuration, defect, P3)

defect

Tracking

(Not tracked)

VERIFIED WONTFIX

People

(Reporter: jdaly, Assigned: asa)

References

Details

right now the ui prevents me from using an invalid email address for news (like jdaly at ixl dot com). this is something that i would want to use, especially for newsgroups to prevent spam backlash! perhaps when the address is for news, prompt the user that the address is invalid, are they sure they want to use it?
no, we will not do this. You should pick a different method to avoid spam, like myname.nospam@blah.com. One of the GNKSA guidelines is that users be required to enter a "valid" email address in the form user@host... Entering an invalid e-mail address can break news servers, etc.
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → WONTFIX
actually, i found that after using the 'account wizard', when using the account configuration preferences normally, one is able to enter invalid email addresses (just like 'jdaly at ixl dot com') -- should this be prevented as well then?
yep, I have a bug against me somewhere on that.
that's the one! That's it, I'm not going to do to bugzilla queries anymore! I'm just going to ask you lisa, you're faster...:)
I will mark this verified won't fix. I've added this bug's case to the other bug report. And, I'm glad that I'm faster than a bugzilla query :-)
Status: RESOLVED → VERIFIED
Blocks: 11349
No longer blocks: 11349
Ridiculous. Reopening and marking my version of this bug a dup. GNKSA requirements are not more important than user satisfaction. If I can't use my spam-proofed e-mail in the Mozilla newsreader I'll go do it in Outlook, just like any other user would. This enforcement doesn't do anything except drive users away to other newsreaders.
Severity: enhancement → normal
Status: VERIFIED → REOPENED
Keywords: 4xp, nsCatFood
OS: Linux → All
Hardware: PC → All
Resolution: WONTFIX → ---
Summary: [feature] using an invalid email address for news → Allow spambot-protected e-mail address in News
*** Bug 88298 has been marked as a duplicate of this bug. ***
[Removing nsCatFood keyword, since Skewer isn't a Netscape employee] I agree this should be wontfix. See also bug 18344: you could set your e-mail address as `SkewerMZ@skewer100.invalid', then include human-readable instructions to replace `invalid' with `cjb.net'.
Keywords: nsCatFood
> GNKSA requirements are not more important than user satisfaction. GNKSA was not made by an industry giant. From bug 3744: > MailNews will never be able > to stop spammers from entering fake e-mail addresses - it just forces them to > format them properly. We don't try to stop spammers. I assume that their use their own, specialized tools anyway. Since - GNKSA-compliance is a major goal that most people (who are involved in the Mozilla development) agree with and - this bug contradicts bug 3744, which is a GNKSA requirement, marking WONTFIX ("Should not be fixed") again. If this is 4xp, then 4.x was wrong IMO. We don't need to reproduce 4.x bugs.
Status: REOPENED → RESOLVED
Closed: 25 years ago23 years ago
Resolution: --- → WONTFIX
I should be fair and argue with more than just "It's a SGNKSA-requirement." <http://www.xs4all.nl/~js/gnksa/gnksa.txt>, section 12 is relevant here. Some quotes: > When creating either a new article or a followup, the software MUST > initialize the "From: " header to a syntactically valid e-mail address [...] > If the software is unable to create such an address -- maybe because it > was built with incorrect configuration parameters, or some essential > parameter is unavailable at runtime -- then it MUST NOT allow posting at > all, unless it can obtain a syntactically valid e-mail address from the user. I am usually for giving the user the full control, not to regliment him. So, in this case, we could display a warning dialog, if we detect an invalid email address in the Account Manager/Wizard, as suggested in the dup bug. But GNKSA seems to disallow that specifically ("If [...] incorrect configuration [...] then it MUST NOT allow posting"). Considering the rationale they give, their position makes some sense: > Rationale: Mail and news transport systems and user agents, gateways and > processing software may choke on syntactically invalid headers. I think that many new users are not aware of what they are doing when they enter an invalid address. E.g. who knows what happens when a silly spambot tries to mail "you at example com". To summarize, I don't have sufficient arguments to break with GNKSA, so we should err on the side of GNKSA compliance. To reopen this, we will have to present solid reason why using an invalid address is better than, e.g., using <user.REMOVETHIS@example.com> (where both <user.REMOVETHIS@exmaple.com> and <user@example.com> are functional addresses, but the latter might be read more often).
This is NOT about meeting ANY requirement. This is about delivering a product which does NOT have limitations which aren't present in other products (e.g. Outlook Express)! No limitation is too small to cause someone to change their newsreader. Until you can provide something BETTER than a requirement, such as EVIDENCE of news servers breaking on an e-mail address such as <user at example dot com>, I won't be satisfied. This is a serious user satisfaction issue and cannot be ignored. <user.REMOVETHIS@example.com> is MUCH more invalid than <user at example dot com> and the latter should be encouraged at any cost. The goal of spam protection is to format your e-mail address in a way that only a human could use it. Humans won't know how to handle an address like <user.REMOVETHIS@example.com> while many e-mail collectors are programmed to handle addresses like this. Meanwhile, e-mail collectors cannot understand <user at example dot com> and humans can easily change this to a real e-mail address. Haven't you ever heard of, "The customer is always right"?
Status: RESOLVED → REOPENED
Keywords: nsCatFood
Resolution: WONTFIX → ---
> This is NOT about meeting ANY requirement. There are countless requirements a product must meet. For example, standards compliance is such a requirement, and one that Mozilla holds up (actually, it is probably the number one goal). GNKSA is the "standard" for etikette in newsreaders. > This is about delivering a product > which does NOT have limitations which aren't present in other products If MSIE implements "cool" HTML-feature A, say the <blink> tag, and the HTML standard explicitly disallows it, it probably won't get into Mozilla either (at most anyhow hidden). (You know that you can enter any address you like in prefs.js, don't you?) > Until you can provide something BETTER than a requirement, such as > EVIDENCE of news servers breaking on an e-mail address such as <user at > example dot com>, I won't be satisfied. GNKSA is well-respected. I has undergone a long process. If you are interested in the details of the rationale (beyond what I cited), lookup the relevant discussion at <http://www.xs4all.nl/~js/gnksa/#maillist>. One of the advantages of standards is that you donÄt have to argue about each point everywhere each time. *You* argue against the accepted standard. *You* have to provide proof that the standard is wrong. > <user.REMOVETHIS@example.com> is MUCH more invalid than <user > at example dot com> and the latter should be encouraged at any cost. Please cite a generally accepted Usenet FAQ (e.g. from <news:news.answers>) stating that. I know that in the normal German Usenet, faked addresses are likely to get you flamed. > Haven't you ever heard of, "The customer is always right"? But I am also a "customer", and I disagree with you, because <user at example dot com> - is completely invalid - is hard for me to reply to.
mpt: nsCatFood is a nomination keyword. Netscape's job is to agree (nsCatFood+) or disagree (nsCatFood-) with the keyword. >There are countless requirements a product must meet. For example, standards >compliance is such a requirement, and one that Mozilla holds up (actually, it >is probably the number one goal). Standards are not and never were a requirement. The last time I checked, software developers were free to write software in a way that pleases their customers and not necessarily satisfy the whims of these "standards" authors. When a standard is considered unreasonable and is expected to cause user satisfaction issues, a reasonable solution is to make in an option, either a pref or an "Are you sure?" box. In this case such a confirmation eliminates the accidental use of invalid e-mail addresses. I agree that Mozilla should make every attempt to meet some of these suggestions (such as displaying all header information, separating sigs properly, removing sigs from replies, and wrapping reasonably). However this one forces an unreasonable assumption on the user and prevents him from protecting his e-mail address from spambots in a logical manner. >If MSIE implements "cool" HTML-feature A, say the <blink> tag, and the HTML >standard explicitly disallows it, it probably won't get into Mozilla either (at >most anyhow hidden). Very bad example. I believe it is Netscape who invented BLINK, and bugs suggesting the removal of this irritating feature are being passed off as RFE's. So apparently user satisfaction is a low priority in both cases. >>Until you can provide something BETTER than a requirement, such as >>EVIDENCE of news servers breaking on an e-mail address such as <user at >>example dot com>, I won't be satisfied. >[No evidence was provided here.] >One of the advantages of standards is that you donÄt [sic] have to argue about >each point everywhere each time. Another case where you don't understand the consequences of blindly accepting any standard that comes flying along. >Please cite a generally accepted Usenet FAQ (e.g. from <news:news.answers>) >stating that. I know that in the normal German Usenet, faked addresses are >likely to get you flamed. Gladly (although you will probably pass off anything that doesn't support your argument as not being "generally accepted"): <http://www.ecofuture.org/jmnews.html#hide> > Haven't you ever heard of, "The customer is always right"? >But I am also a "customer", and I disagree with you, because ><user at example dot com> >- is completely invalid As formatted, yes (no different from <user.REMOVETHIS@example.com>. However anyone with a sense of logic and general literacy should be able to understand that this e-mail address should be changed to <user@example.com>. >- is hard for me to reply to. (no comment)
> > standards compliance is such a requirement, and one that Mozilla holds > > up (actually, it is probably the number one goal). > Standards are not and never were a requirement. Wrong, see above. Check newsgroups, early webpages on www.mozilla.org etc., ask people on IRC, if you don't believe me. > The last time I checked, > software developers were free to write software in a way that pleases their > customers and not necessarily satisfy the whims of these "standards" authors. Speaks for itself. > > Please cite a generally accepted Usenet FAQ (e.g. from <news:news.answers>) > > stating that. > Gladly (although you will probably pass off anything that doesn't support your > argument as not being "generally accepted"): > <http://www.ecofuture.org/jmnews.html#hide> Whereis the proof that it's generally accepted in the Usenet community? In fact, it makes some fatal errors, like suggesting to replace com with org. Search the newsgroup news.answers and/or ask in news.newusers.questions for a Usenet netiquette/FAQ. I found an "Address Munging FAQ" there. Note that it assumes that you want to mung your address, something that many people disagree with in the first place. From the "good" ways it mentions for munging, only one ("yourname(AT)example(DOT)com") would not be possible. All others are syntactically valid. Maybe, we could include the most important "DON'T"s in our error message. > >- is completely invalid > As formatted, yes (no different from <user.REMOVETHIS@example.com>. No. <user.REMOVETHIS@example.com> is a syntactically completely valid email address, and it could and *should* even exist.
Asa: this bug is for you to arbitrate. The suggestion is CLOSED WONTFIX. Alecf certainly has no need for this spam, but if he likes he can cc himself or reassign. Sorry to disturb you.
Assignee: alecf → asa
Status: REOPENED → NEW
I have no idea why I've been CCed, but: You can have syntactically valid spambot-protected email addresses, so this bug, as titled, is WORKSFORME. The fact that one particular way of spamproofing isn't allowed is not, or shouldn't be, a big deal. Gerv
QA Contact: lchiang → stephend
wontfix.
Status: NEW → RESOLVED
Closed: 23 years ago23 years ago
Resolution: --- → WONTFIX
wheeee!
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.