11 Feb, 2010, Scandum wrote in the 21st comment:
Votes: 0
elanthis said:
I had the thought today in the shower (yes, I was thinking of you while naked) about just using the same technique as MTA sender verification.

Sounds like a whole lot of trouble to validate pissoff@gmail.com.
11 Feb, 2010, elanthis wrote in the 22nd comment:
Votes: 0
Do you actually have a method that actually CAN validate pissoff@gmail.com (or, more accurately, identifies it as a bullshit address) ?

elanthis@stargrazer:~$ dig -t mx gmail.com

; <<>> DiG 9.7.0rc2-RedHat-9.7.0-0.13.rc2.fc13 <<>> -t mx gmail.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26827
;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;gmail.com. IN MX

;; ANSWER SECTION:
gmail.com. 240 IN MX 20 alt2.gmail-smtp-in.l.google.com.
gmail.com. 240 IN MX 40 alt4.gmail-smtp-in.l.google.com.
gmail.com. 240 IN MX 10 alt1.gmail-smtp-in.l.google.com.
gmail.com. 240 IN MX 5 gmail-smtp-in.l.google.com.
gmail.com. 240 IN MX 30 alt3.gmail-smtp-in.l.google.com.

;; Query time: 41 msec
;; SERVER: 8.8.4.4#53(8.8.4.4)
;; WHEN: Wed Feb 10 20:32:59 2010
;; MSG SIZE rcvd: 150

elanthis@stargrazer:~$ telnet alt2.gmail-smtp-in.l.google.com 25
Trying 209.85.221.7…
Connected to alt2.gmail-smtp-in.l.google.com.
Escape character is '^]'.
220 mx.google.com ESMTP 7si3294417qyk.114
HELO myhost.com
250 mx.google.com at your service
MAIL FROM: <test@myhost.com>
250 2.1.0 OK 7si3294417qyk.114
RCPT TO: <pissoff@gmail.com>
550-5.1.1 The email account that you tried to reach does not exist. Please try
550-5.1.1 double-checking the recipient's email address for typos or
550-5.1.1 unnecessary spaces. Learn more at
550 5.1.1 http://mail.google.com/support/bin/answe... 7si3294417qyk.114


Tada, email failed validation and is identified as bullshit. If only we had a way to do that for forum posts.
11 Feb, 2010, Scandum wrote in the 23rd comment:
Votes: 0
If pissoff fails, fuckoff@gmail.com will do the trick, or while at it, hotgirl@hotmail.com

It would work alright against typos, if that's the kind of user you cater to.
11 Feb, 2010, David Haley wrote in the 24th comment:
Votes: 0
Not sure what you're trying to argue, Scandum?
11 Feb, 2010, Koron wrote in the 25th comment:
Votes: 0
The problem is distinguishing between invalid email accounts, like pissoff@gmail.com, and email accounts that exist but don't belong to the person in question, such as the hypothetical mud@gmail.com, which I would be very surprised indeed were it unowned.
11 Feb, 2010, David Haley wrote in the 26th comment:
Votes: 0
Well, yes, we distinguished between syntax verification and "user-backed" email address validation a while ago. Elanthis gave a method for making sure (in very many cases) that an email address is recognized by a server. Scandum said it was an awful lot of work just to "validate" something. But Scandum's proposal doesn't do any validation; it's a syntax verifier. So I'm not sure point is being argued in post #23. And the bit about catering to certain users is a little unclear, too.
11 Feb, 2010, Kayle wrote in the 27th comment:
Votes: 0
I think the best solution is to do both.

Use Elanthis' suggestion to actually talk to the SMTP servers, and then if it passes that, inform the player, and send a verification code to the email supplied, and if it's not provided to the mud within X days, switch them over to a "limited" account, where they can only play the game in the simplest ways, if it's an RP heavy MUD, restrict their access to RP commands like emote or something until a valid, verified email is entered.

This way, Scandum can piss off and stop complaining. And we get to see a really bad ass approach to email validation transferred to our hobby.
11 Feb, 2010, KaVir wrote in the 28th comment:
Votes: 0
Kayle said:
Use Elanthis' suggestion to actually talk to the SMTP servers, and then if it passes that, inform the player, and send a verification code to the email supplied, and if it's not provided to the mud within X days, switch them over to a "limited" account, where they can only play the game in the simplest ways, if it's an RP heavy MUD, restrict their access to RP commands like emote or something until a valid, verified email is entered.

What's the advantage of doing that though? It's not hard to create multiple email addresses, but it's still another entry barrier for new players.
11 Feb, 2010, Kayle wrote in the 29th comment:
Votes: 0
I don't see the advantage to requiring a valid email in a MUD at all. Which is why adding an email or IM contact info is all optional for MW and SW:TSW.
11 Feb, 2010, Kline wrote in the 30th comment:
Votes: 0
Emails now are and will be optional*. This is mostly for password recovery and to allow immortals to send emails, if the player opts in.

*Meaning they are not even asked for in creation, and are just another command to enter your email at any point during gameplay.
11 Feb, 2010, Kayle wrote in the 31st comment:
Votes: 0
Well, that makes sense, and then the validation is for making sure the emails are vlaid and not just a waste of time for the Imms to send emails to.

Even so, Elanthis' method is fascinating and would make an excellent snippet. ;)
11 Feb, 2010, Kline wrote in the 32nd comment:
Votes: 0
I opted for the simpler "accept what I'm given and send an email with a validation code", which is now a snippet in fact. The MUD will just refuse to send mail (aside from the attempt at a validation code) to people who don't validate their address.
11 Feb, 2010, David Haley wrote in the 33rd comment:
Votes: 0
If you're already sending an email to say "are you real?" it seems that you don't need to do a first check to see "might you be real?", right? Sending emails is pretty cheap, so you might as well stick with that.

Were I to do this, I would probably ask them to confirm their email (e.g., "you typed this, is it what you meant") and then just do a validation code.
11 Feb, 2010, elanthis wrote in the 34th comment:
Votes: 0
Kline said:
I opted for the simpler "accept what I'm given and send an email with a validation code", which is now a snippet in fact. The MUD will just refuse to send mail (aside from the attempt at a validation code) to people who don't validate their address.


Which is a perfectly acceptable solution if that's all you want.

What I posted solved a particular problem. That isn't the problem you are trying to solve. Your solution is better for your problem. And there we go. :)

In particular, if you're going to be sending newsletters, you absolutely want to verify _ownership_ of an address, not just existence. Proving ownership unfortunately requires some kind of extra step on part of the user, no matter how you go about it.
11 Feb, 2010, Kline wrote in the 35th comment:
Votes: 0
Well hopefully having the user enter the code in game proves at least a small level of ownership of the account :)
11 Feb, 2010, elanthis wrote in the 36th comment:
Votes: 0
Yeah, that's the extra step I mentioned. :)

Proof of ownership of an identity requires some form of verification by the authoritative provider of the identity with the user himself. For a character on a MUD, that's the username/password the account was created with that is entered upon login. For an email address, that's the mail exchange the user's email account is hosted on and a secret code mailed to the account and read by the user (who must log in to the account). In a perfect world, there would be some standard unified protocol every website, email service, MUD, and whatever else would use that do a three-way auth between user and service. Which is precisely what services like Passport do (and any server using a protocol like OpenID or Kerberos), but they all have a series of limitations; Passport isn't even around anymore I think and it wasn't free/easy to use anyway, OpenID is only meant to work for HTTP+HTML (websites), and Kerberos solves a number of other problems as well which imposes a very strict and unforgiving security model. Basically all you need is a way for the user to tell the central identity server that it wants to login to a service, get a unique token for the session to send to the service, and then the service verifies the token with the central identity server. The user would then still need to do email validation and so on to get his account on the central identity server, but once the email is verified he won't ever have to do it again for any service that integrates with the central identity server. Great concept and that is how all sites and services _should_ work, because dear freaking god am I sick of creating new accounts and verifying email addresses. Pain in the rectum.

Creating a new service to do this is easy, but then there'd be maybe one or two sites using it and maybe one or two MUDs using it, and maybe one or two MUD clients using it, and the end result wouldn't be much better than the status quo. You could get around MUD client support requirements by requiring some other tool/app/site the user might manually run/access to get session codes, but that's not much of a usability improvement over email at all.

So yeah, send the user an email with a verification cookie if you need to make sure he owns the email address. :)
20.0/36